Dencun Interop Testing #28

Transcript

thank you [Music] foreign

okay um we are live uh so this is our 28 or 28 44 call now morphed into the fall then testing calls um so uh there were a couple things people wanted to bring up today so one uh what we discussed on cordoves last week so all the proposed changes to four seven eight eight um and then the second big thing that came up was uh the issue around 868 uh interrupt um and the encoding of the transaction type there um and I see uh Alex

is not on the call and uh so I don't know if we we might want to wait for him to do the 4788 stuff um so instead I guess we should probably start with the 868 issue um and then can do 4788 after oh okay so Alex can't make the call uh okay let's just keep going with e68 and we can we can do 4788 after then I know Andrew you're the one who posted this on the agenda um so yeah you want to give some context on that um yeah sure so um I think it was not me who um

discovered this problem but base I think it was it was uh ethereum JS guys and basically the problem is that um how is 68 is implemented in most clients I think in all El clients except for ethereum JS is not in line with the spec um but uh because and the the difference is minor it's our announcement types for different transaction types are encoded uh and because uh or the majority of the clients already implemented in one

particular way the same way Geth implements it I just suggest to update the spec uh so we will minimize the necessary the necessary changes it's probably the easiest thing to do yeah it is a bit weird though like the reason why I wouldn't say it's necessarily the best idea to update this back to what it is now is that current encoding is kind of weird I mean it's basically an accident because in like the gold library for ROP if you put like like a like an array of bytes it's going to encode it as a byte array like kind of expected but then when you put

any other kind of red and it puts it as a like list which is also expected but it's kind of weird to have this like to have the TX types as a byte array because yeah it's just not I don't know like what if there's ever gonna be like I mean it's all hypothetical anyway I don't really know um it's maybe not the most elegant but I think it just if we do that updating update the spec then we just minimize the amount of busy work yeah that's true I mean there was this there was this that's true the idea was kind of to like I I was kind of curious why in the first place it was decided to put these things

in separate lists um I'm I actually and in the discussion nobody really knows does anyone remember to be honest I have a bit different uh things to say that we cannot really change ETA 68 and implement it properly because this is already in production uh yeah already running so we have to accept the d868 as is and we can only fix it and it is 69 for example yeah yeah there's no there's no plan right now to change the eth68 anymore

like it is what it is now my question is more like why was it already decided that I mean should we maybe like make another change for e69 first of all so anyone in favor of it no because I think you're just unnecessary we don't have a problem like the problem is that the problem can be easily addressed by changing the spec yeah I know but it looks pretty bad though I mean would it be okay for you guys if we basically leave it but then as when we make the I will make a note and then when we make the e69 for another reason we will include this

change as well like just improve this message somehow to like look better would you guys agree with that or do you think that's like you should never ever be changed again or no no no that's fair okay yeah I can I can be okay with that as well change the spec now but then like leave it for next time to clean it up so uh from I made a quick inquiry how we got to this point and we haven't uh found it at the beginning so um we actually I think wanted to implement it correctly but then um the the guys who are implementing

because it wasn't me actually um were confused by The Hive tests which didn't work with the proper schema so yeah it kind of like propagated from gef and that's not great yeah yeah that's true um like I said I I think even if somehow I mean the hive tests are not based on get in the in the like regular way it actually implements a protocol like by itself but it also implements it incorrectly because like I said this mistake is really too easy easy to make and go because of this byte array thing but my question was another one which is like if anyone maybe remembers why it was decided in that in each 68 um these announcements should contain

these like three separate lists for the types sizes and hashes it seems kind of kind of counter-intuitive maybe it would be better to somehow have it so that I don't know we have for example like like triples in a list or something but then you would have encoded to Triple separately right I don't know I mean it wouldn't I don't think I don't think it would make any difference to be honest I mean it was just kind of I just found it curious that somehow it was decided to have these like three separate lists for the separate items it's kind of a odd encoding I feel but I mean at the same time if you guys I mean nobody seems to have any issue with it it was more like

a question I remember the discussion but I don't remember the exact thing yeah right okay because I remember that I also like wasn't sure that this was the best idea to go with release yeah but it wasn't like too bad and yeah that seems to be how everyone feels about it that's which I find kind of funny to be honest like everyone I asked was like yeah you know it's not the best but it's also not the worst someone else ask Marius maybe he remembers yeah yeah yeah yeah he's I think he's on vacation but anyway um I mean we can just leave it now so I will make an uh I will basically make a note in this issue and in the death PW

repo that it's like for the next time and I will change this back to have the byte array it's weird but we can accept it and move on and then there will be the least amount of changes oh sorry I was looking for your amusement and when you say leave it now it's basically we do the change to the current 868s back and uh as basically proposed and then um also move this change also have this change as part of 869 correct yeah we will change something in each 69 but it's not that important what it's going to be right now maybe we will go to the two to the triples after all in the next version

I will let's discuss it another time and let's just like ship Cancun okay um are you able to make that spec change Felix there you go okay awesome so okay we'll wait for your PR there um thank you anything else on the e68 issue so this is gonna be included not um does that understand it correctly this is one after a Duncan so each 69 would be after dencoon but we will make a fix so that all the clients uh basically have the same

implementation for Cancun as part of the 868 spec s does that mean so that should so that should come to definite already uh do do we want to have that and I guess do we like ideally we want to have everything definitely okay that's what we've been saying yeah yeah like four weeks now but uh we just keep adding stuff to it so that's why I'm I'm just curious uh what do we want because right now definitely seven is uh feel quite old and irrelevant so it would be very good if we could launch this week definitely even like

yeah wait um and then the question is though this is in the way it's more like a bug or like a disagreement and implementations like some clients are going to have to change it regardless to communicate with other clients right it mostly will be a novel change because like I think all all the El clients except for ethereum JS already Implement like like kind of the guess uh flavor so okay from like in fact it will there will be no difference between devnet 7 and devnet 8 but formally you can count as a as a difference as a kind of a change to the spec which brings this back uh in line with the reality actually

right so so ethereum JS would have to make a change basically that's the only one yes okay yes I think we should do that then so that's Market explicitly as included as part of that net eight but in practice the implementations don't like won't have to do anything yeah except ethereum Js yeah just chiming in we already have this I think okay nice nice yeah does that make sense at T Barnabas as well yep okay anything else on this okay so next up yeah the last big thing

and change uh to uh the the spec is uh what we agreed to with regards to four eight four four um so not four four sorry four seven eight eight on uh awkward devs last week uh basically to move from using uh pre-compile for the EIP to using uh just a normal smart contract and then the two biggest questions were which contract uh how do we deploy the contract do we assume it's deployed prior to the fork or do we have deployment mechanism as part of the fork and then what actual contract should we be using um like client you said uh you and Martin may have an update on one of

those um yeah okay yeah there's a PR to the 4788 spec I'm not sure if people have had a chance to look at that that was kind of The Proposal based on what I understood we discussed from all core devs and on those two questions about how to get the code there and what code to use the uh answer that I used in the pr was we would deploy the contract before the fork once we agree on the byte code and then set in clients that address as the address to make the system call to

and the byte code I wrote an assembly implementation with some help from Martin and welcome and that's the proposed by code for 4788 it's got a git and set functionality where you can get the root based on timestamp and then if you are calling as a system address you can set the timestamp so I guess they're the main question is how are we going to get the code there and how are we going to update the roots I know those are the two things that seem to be like debated right now well well uh if I could just add so I have there one more thing I think is

being debated is whether to have ABI encoding on the user facing loading part so there's the API encoding yes or no what what deployment method to use and then uh I think it was primarily who raised the question should we even have a path in the contract for the updating instead of because previous e version just did the update directly onto the storage of the contract and yeah I've already commented this on

on this comment if we have the path in the contract then it's still up to the client if the client implementer can still choose to do the update directly if they want to do that optimization and that's fair game they can do it if you want to have a a more simple client and you can just invoke a system call and let the evm do what the evm does yeah so that's kind of the argument for doing it that's the system call instead of instead of mandating it as a direct topic

that's all I had to add anyone else yeah have thoughts enough yeah I think regarding the ABI I I I if I remember correctly for gnosis chain and for all in general we do use ABI so it would be nice to also use API for consistency for uh for this contract so uh what I'm what are we talking about here is the user facing part so when you want to get the beacon route the

original it just said that you send uh 256 bit in to go to the pre-compile or none of the current gray compilers have API for requesting data thus they are a bit clumsy and and it's kind of hard to interact with most of them until the solidity compiler gets native support for them if they would have or if this new one does support a by encoding then nothing needs to be added in the in the whatever compiler you want to use you can just cast it to an API interface and then they like get bigger routes and

so I'm not talking about the system called here I'm talking about the user call so I just want to for consistent if you want to be consistent with the previous pre-composed then we would say no API because we don't do that for kicking bugs but if we want to be more like acknowledging the de facto standard of data exchange between contracts and ethereum then we might want to go with API that's kind of my impression foreign I guess my take is it feels like we're starting to blur the lines between

the application layer and the core layer so yeah right now the way that we do ABI encoding is very ubiquitous but it I know there are other compilers that want to do things differently and it just doesn't feel right to enshrine this Behavior into a system contract and also this is not a going to be a commonly used system contract like I think mostly liquid staking tokens want to use this so there's not going to be a huge rush of people doing the ugly raw call interpreters 32 bytes so I don't think that yeah I don't there's a lot of advantage

of just making it work nicely with solidity from day one a lot of people feel about it yeah I was currently be in favor of the using the Avi but I can also understand the clients to comment about it um Daniel there's also what's going on is there's a read mode and a write mode going on in

the same address um all the other smart contracts on the smart contracts all the other system contracts generally had one load going so we even split up the uh I was able to get the the BLS is split up into separate modes so if there's multiple modes either we need two contracts or we need um sort of standard way to split between the modes and that standard way is ABI I mean I really don't think we should be your muffled Martin I'm sorry in this particular case we are sitting

on the sender true but that's still two modes so you're splitting on a sender or you're splitting on the input data it's yours there's modes and yeah I mean it's it's the same as as changing the um the owner of a contract also splits on Center you either revert or you actually change the sender so what what is that what is what what do you think what did you I don't really understand what you're saying Donna I prefer the ABI method because we're going to the direction of smart contracts are behaving like so we should just embrace it and do the API

yeah I was I'm also curious what's the argument against using the Avi like what's in your mind for the this is more for the like non-avi camp like in your mind what's the most what's the thing that makes you not want it the most I think it's enshrining behavior that shouldn't be enshrined there are other compilers who want to have different ways of calling functions and I don't think that like forever in perpetuity we should say that the way that solidity chose a long time ago is the way to do it hmm this is a system contract

and we shouldn't be choosing standards like yeah but they never Viper uses the API um is it that fee and some of the others don't I know fee doesn't want to yeah do we have other arguments against the API uh I mean I think the ABI isn't good in the first place okay like yeah okay so but okay so these are the two things that you think is the most important is it's also more expensive hmm extra four bytes that aren't necessary because we're splitting on

so it's not really like semantically useful the only advantage of the ABI is that it works out of the box with solidity and I don't think that's a good reason to make a change like this okay so it seems you feel very strongly about not using the Avi and that's okay just wanted to know like what what your thoughts are uh if I could just one more thing so I agree that so I think you said that it works out of the box with selected with API and that's the only reason but I have the the counter argument to that is I found

that it is is very difficult to get it to work with solidity if you if you don't have the API um I might be wrong but you you need to pass input and you need to make the letter to expect output and it maybe it's possible but it's definitely not treatable and it's kind of uh not nice to force people to go into assembly mode to interact you you don't think you have to go into

assembly do you I think you can just do a rock call to the address I think the output might the factor returns data might be a bit problematic for the recall you can cast it to bytes32 it's not nice but you should be able to do without dropping to sell the compiler the size of the output yeah I'm not sure maybe maybe not I'm not I don't know sufficiently to really say yeah I'm also not sure but I wrote some tests with it and it wasn't terrible terrible Tim is asking if we can add the API

later uh the answer is no okay yeah the API means it has 36 bytes inputs uh no API is 32. got it yeah I don't know how we make that decision as I I would I would wonder something do you guys think this contract will ever be extended in any way I mean what do you think so what yeah well I mean we always think that but then in the next Fork it's like we want to add this field here that we just

invented and why not stuff it in the same I mean before I mean for sure I guess this also kind of touches on the point of like how to get the code into the state and I generally would rather we use the standard transaction deployment mechanism rather than doing a regular State transition to add it if we do in a regular State transition then I think it's more likely that in the future we just modify the code but if we deploy it as a transaction where it's you know just a regular part of the chain I think it's less likely well I mean we can't really upgrade it then yeah well I mean we could always but that's not true I mean this contract is kind of

like we could always if we want to make a change to it we could just create a new contract that is somehow better and then basically make it invoke the old for any query that goes like Beyond a certain block or something like it would always be possible to change it by the way just wanted to add uh I realize that you're correct uh like client that now that we have returned data it's not such a big problem anymore and I looked at this select example and

it's it's not actually that painful to do a call even if you don't have any so that's the support so I still prefer the API but not a strong level so Proto has an idea of the in the chat of having bindings for the contrast that I guess would be a separate contract that we can just write and have anyone deploy if they want the API is that is that what you're saying Proto it's kind of like an ABI wrapper yes basically so you could compare this to multi-call or some other popular permissionless contracts that do a thing for ux do not really change the behavior of the

virtual machine so you could have a contract that has a delicate column into the the pre compound or can we call pre-deploy anyway the the special contract of the storage route and provide the API that's there yeah but it's like it's questionable if this is gonna be used then because it literally it this will only serve to just drive up the gas cost for something that you can actually do way cheaper if you just call the the real one like this would just be like wait and gas for for the code to look good yeah

but yeah but then people can choose to do that right yeah I mean they could also just import like a solidity library that makes it possible to call the contract in in the in the normal way like that it expects I mean if you're worried about the solidity there will always be this it's not going to be that complicated to call it so it's literally just going to be this like snippet that you can use yeah now that we have returned I mean it was per month but I forgot that we now have return data so now it is actually not that difficult no

so has anyone shifted their view thinking um and I guess the reason I ask is it would be valuable to agree on this sooner rather than later because we're going to want to get the contract code audited and obviously we want to get this implemented in devnets but we we can we can change the specific contract a bit easier there yeah from my side it's okay to drop the API yeah from my side too it feels like the majority is

mildly in favor of ABI and now we have like science is stronger but I'm I'm fine with dropping a guy anyone else want to share their thoughts otherwise yeah I I would also link to drop it just also because of the fact that you know there can be a solidity library to interact with it there can be different contracts that interact with it oh Dano um I'll miss the API I'd rather have it

but I'm not gonna you know I'm not gonna be upset if it's not there okay so I'd say let's move forward uh without the API yeah this way we can once that PR is merged with the code um we can start getting Auditors to look at it um I guess my client do you feel like that the pr you wrote is um like at that level like this is the thing people should review as as as like the more or less final proposal well we've got the next problem to solve

which is how to get the code into the state correct but that's different than the code right so so yeah and I guess my question wasn't clear but I guess just in terms of like finalizing the contract code oh yeah Tim are you talking about the code now where you were talking about the E so no something if we want the audience that smart contract yeah do we feel comfortable that what's in like client's PR once it's reviewed yeah yeah um we're happy to say so I think we should give it a a day more aware of some finalized some there's some some maybe some uh comments about the stock uh but basically it's finished uh and it's a really trivial simplistic

contract it has like five flows two jumps or something like that for three uh so it's going it's it sounds like it's a big thing we're gonna get it audited uh but it's really not the big thing okay uh that sounds good and anyways like yeah I agree if we can merge into the next couple of days that's great mostly to move definite forward um there's no auditor that's gonna start working on something with a day's notice anyway so um yeah if if we have this merge in the next couple days and ready for that

eight then we should be in a good spot to just get a sanity check from an external auditor as well um okay anything else on the contract itself then we can discuss the deployment let's do the point okay so yeah other contentious issue uh so do we deploy this with a singular Trend like a normal transaction have the EIP assume that this is already on chain um and you know fail somewhere or another if it's not or do we have the entire logic sort of part of the EIP including the actual deployment of the contract um yeah

the people have strong opinions about or I guess okay no one has a very strong opinion does someone want to make the case for uh deploying yet in a just regular transaction yes oh yes please and then you'll come you can go after yeah so yeah okay so I was talking yeah yeah Martin then yoga okay I'll uh I'll make the case then for putting it in a regular transaction because that's what I just think is the easiest from several perspectives first of all we could just deploy it now

on mainnet on all of our testnets we could do testing of it it could be audited by whoever wants to to look at and then months from now we could just bless it to say yeah this is the I just think it would be a nice to do it that way yeah just as a note if we uh deploy it as a normal transaction then on our test Nets we will just have the case that we start without the contracts and we likely will immediately activate all the erps and then at some point we just deploy deploy the transaction so we

might have a few blocks where this contract is not yet there so this is another I thought that the devops team has said for the deposit contract they have a way to work around this anyways yeah we just said it in Genesis yeah we can start it in Genesis you could also and this is kind of cool you could actually set another contract in Genesis and you could set your allocation to do whatever you want yeah these specifications mandates that there's going to be a system called sending in a bigger route if you're going to do some experimental private Network where you do something else and you're free to do that yeah makes sense okay

would the address be the same across all contracts or we just accept what it does we do it create two off of a known address so the the and TMS if someone wants to make the case for a normal transaction so for a normative section the address would vary um and we would probably have to make sure that our our change specifications are taxable enough if we make it to create two off of a off the same account it should settle to the same address on all Chains No but we got to get to create two contract out there which yeah we need the requires created yeah yeah it would have been really nice

if we could achieve that but I don't think we can but is it that important actually to have it the same yeah make it easy because then we just have to activate it then we could hard code the address and we could our chain comp you could just have a number or timestamp as usual you know Cancun number and not just not also at Cancun Beacon free compile address uh it will simplify things because that would beg the question outside of test Nets and Main Nets where is it going to be used as they're not being able to lock it in a number such a bad thing because if this is truly just being used

in mainnet then we lock the number into the Genesis and any other alt chain or Layer Two wouldn't be using it anyway so we're fine yeah it's not definitely not required it it so one thing that they could do and this is totally uh on a tangent but if you're related to or if you're you're some other network you could actually use this and piggyback other features because you 30 minutes has given you a system call to an address and if you put something on an address and activate it then you can have some kind of feature

that you didn't have before where before blood pressure you know you can Implement things like that man switches and whatever but that's really beside the point yeah so that was a bit about the doing it in a transaction uh there are other ways to do it and maybe someone else wants to to make the case for for those and I know like science you wanted to do it uh something else right yeah I propose doing a synthetic transaction um I think that a synthetic transaction would give us a deterministic address across different

chains the only questionable part of it is making sure the fees work out where it's included in all the chains if you're not familiar with this idealist synthetic transaction is you kind of construct the transaction you want to deploy and then you arbitrarily pick a vrs value and then you recover the address from that so the idea is you don't have the private key for that address you just have this one time transactions that's signed by that address so we could publish that as part of the EIP and then if somebody wants to deploy the system contract on another chain they would just fund that account and then include that transaction on the chain right but they also might get a different

address unless they accept Legacy addresses yeah they would have to use a pre-155 but you know for other chains like I think it's up to them to how they want to get this contract in it we're not requiring as part of the EAP this is how you get the trend you get this contract into the state the eaps you know it's more written that you as a client just make a system call to this address and that can be configurable to the chain and if they want to do an irregular State transition if that's easier for them to do they totally can do that just wanted to say I think it's also

maybe not required for all chains because this is very specific to basically the mainnet at this point yeah so I mean even for example in some testines we might not need this contract it's not like always like whatever sorry guys sorry I want to emphasize that the beacon block route is not just the layer 1 feature like this is a information of every Layer Two every chain with one to expose just so that this like protocols around to be concerned like all this can interface with the states like it's very useful information to have just

like every layer one or every Layer Two exposes the layer one block roots or the the layer on blockage the big container information is just as useful right maybe could you explain I'm sorry I don't want to drag out the call but I'm really curious how is the beacon block route going to be installed into the layer 2 Chains I mean how is that different layer to Swift our own different system transaction options ah now if I speak for optimism as a protocol there we have a persistent transaction that's a lot like a layer one to Layer Two deposites so inside transaction

so that can insert things like this as any sender to any address if the hard Fork defines this transaction to be inserted right but um would you for example and then you would just you would just basically include some kind of Beacon route update as part of this operation or we already exposed the rundown information in layer 2. we also do expose the layer one look at our information the beacon block route would also be like part of the set of information we would want to expose and preferably just through the same standard interface the same address

rather than having to reinvent The View and expose it if a layer 2 specific endpoint okay but that might be arbitrary optimism and alert sense they all expose the layer on blockage in different places like different non-standard banks because there's no such thing as a standard blockage I mean in that case it might actually make sense to go for the ABR after all because I mean I mean it's easy for us to just say you know this contract for the mainnet is only for this particular block Beacon route but for example if if it was based on Avi then you could just put the beacon route in like another contract in in your layer 2 and

then have it as part of like some other interface or something but it would still respond to the same selector um I mean to the same four byte selector but maybe in a different way or something and this is not possible if if you have a basic non-abi contract because then it all it can only ever respond with the with with one thing so that might be an a big reason to go with the ABI I'm sorry to Circle back to that part maybe it will be more useful uh so there too we want to just stick as close to the layer one Behavior as possible if the Erp describes it as this is the layer one ethereum main nuts

beacon block roots and not specifically just the peak and block route of the local 10. then at least we can agree between all these chains that have you're trying to Source this information from Maynard and if there is like the local 10 to expose maybe that needs to be part of the the address like maybe the chain ID is combined into the inputs that creates the the contract address doesn't have to be part of the API no yeah I mean I mean something else I mean for example in some future way we might for example go ahead and and start I don't know deploying a standard block

hash contract or something yeah and then that would require some kind of interface as well and at that point it's going to be a bit City because in the layer twos there will be contracts already like having operations to get the block hash using ABI and then we'll come along and we'll have to deploy a custom contract with a custom interface and and and so we will never be able to agree with the layer tools so I was just trying to basically make a case that we should really reconsider this ABI thing because just for the interoperability with the layer tools because they are using API for everything and I think they might want to implement even this like Beacon route with some kind of API based hook in their existing system contract or

whatever yeah anyway sorry to derail again to the API but so we've covered two of the ways and the Third Way would be in the regular State transition at the four clock and I know some people prefer that I don't know if anyone is on the call we would like to make a case for that anyone want to

oh Danny and Alex are for the area State transition yeah then then Alex neither of them are on the call yeah they um that was the path I think yeah there's two sides to that one is the philosophical agreement argument that we don't want to do Etc stuff again um but I think the other side is that we're creating code that's going to be used once and disposed of that's inherently fragile so philosophically I'm more on that camp that I'd rather have just just use a regular transaction if we don't care about the address um and that just feels cleaner and less

code to write and less code to test I agree so uh one thing to say for doing in a regular state constitution is that we are if we do that we are at Liberty to places that for example ox F0 or something or Ox OB which is the asset it were a pre-compiled for something closer to a percentage you know something to designate that this is a system contract and it's somehow met

that is the biggest upside I guess and the other upside being that we are then fully in control of the deployment and when we when Cancun hits no matter what test Nets or network you are on we know that bam now this contracts exist and we are in charge so the argument is go ahead finish up to wrap up I think those are the two uh upsides so if we're putting an oxb but we're defining it in byte code we're still going into the evm so it's not truly

like the other nine pre-compiles we have where you never go into ebm code this is specified I don't like to break a pilot it's rather the opposite because we actually do care about the code on it but we could put it up for example Ox F0 or something that's still designated as somewhat magical yeah so yeah and then the produce point is like yeah it also avoids ever being on a network where the contract's not there well we can Define the system contract the system call step to say if there's no code there don't do it if there's code there make the call so a call to a non-existing contract so I think that's kind of implicit like

it's uh if the tree falls from the forest because if we do a system called um nothing is there then no one will ever know whether we did the system call or not but well you're executing Oxo by definition so so it's I mean but yeah it's it's uh oh pack it's not it's a black box whether we did that virtual stop code stop of program I wonder like is this something we need

to decide in the next eight minutes or is this something that figuring out before the CL call does not introduce like extra delays I assume that like like one it feels like we do need time for the conversation but I assume this is also a pretty big part of the implementation details or is it not I mean transaction versus a regular State transition I think is a relatively big part of the implementation still do you feel like we can make this call

no be I and I guess part of the reason is like if we if we decide one way or another now but then get on the ACD call this Thursday and like people feel that like there's there's like uh different consensus that forms are just like wasted everybody's time uh starting to implement this so I I feel like the extra is it yeah who is strong who feels strongly in any direction Danny Danny just showed up um Danny everyone there's I guess we've

made cases for having this be deployed uh with a regular transaction having yet be deployed um with a synthetic transaction and yeah we were now just talking about uh deploying this part of fork but you're gone let's give Daddy another minute to rejoin oh can you hear us now Danny hello yeah oh hey can you hear us um do you want to quickly argue for yeah

I'll just make the case uh I will preface it with it doesn't matter uh it's more of kind of an aesthetic thing obviously uh but I think the Aesthetics of having an EIP that is self-contained and has no like weird external human dependency to deploy is like natural and good and better than the alternative that has the leg okay well you know submit a transaction and set this configuration variable or whatever whatever method is being done you know and having contingencies for if somebody doesn't do that and then having people to have to think about it in devops configurations or having to think about

it when deploying in another environment it's just like this seems like a system operation that exists at a system address specified which can be specified in code r as we had it before it could be specified in logic just implemented uh specify specifying evm code doesn't all of a sudden make it like a dangerous irregular State transition it's literally just system code living in a system address and like conflating it with the notion of an irregular State change I think is just kind of like a weird inaccurate politically charged way to describe this thing

um so I again like it doesn't matter it's evm code it's going to live somewhere it's going to be deployed either out the fork or before because we're going to make sure it is on mainnet um but I just think it's really nice and self-contained to be like here's the byte code at the fork the fork deploys the byte code it lives exactly where we want it to live and we move on with our lives instead of having like an external dependency I think it's just nice to have it all wrapped up in a bow but I'm not gonna die on Phil I uh I'd like to just see this operation deployed so people have strong opinions and are unwilling to budge in my direction that's fine

sort of like you know if you just deploy it by default then this will also mean that there will be no variance like no possible variants across chains for this contract whereas what we were discussing earlier is also a little bit this possibility that maybe on some other chains they might want to expose like a different kind of system contract with like different functionality or something right but but that doesn't that doesn't seem to preclude like that that seems like an independent issue you have the configuration variable that says this system operation goes with this address and if you want to configure that to a different address in a different chain

it's just changing a configuration variable um or if you want to deploy code you just change that variable as well which is the code variable yeah look I I'm I'm the evm is is my friend but not my intimate domain um I don't need to make this decision yeah and I guess the question we had before you hopped on is do we need to make this decision now and now basically the next couple minutes or should we take a couple days to have people review it and think through it and at the latest do it this Thursday and does that slow down implementations from Pine team

significantly um so that that particular decision it does affect how the Eep is written and it does affect the implementation of the in the clients yeah and I guess maybe I mean it's not a huge thing yeah it does add a bit of time yes if we decide on Thursday I mean I mean we're obviously not going to decide it in in the next 45 seconds yeah I have a Barnabas I did something that maybe we should uh leave out of definitely I know I've been pushing to yeah everything as much as

possible and definitely but at this point uh we have definite seven which is using some very steel branches of uh clients and you would like to have a new devnet up and running that would be running the clients code so they can also check everything that they wrote since having so and but do all the clients have an implementation would that mean we use the pre-compile for 788 for devnet8 do our clients have an implementation of base it is not um death has one which contains global so uh and Daniel was that's why you had

your hand up no I was gonna say a different Counterpoint to um you know one of the arguments for having it as a as a state transition is that's gonna be less work for devops so we're just shifting over from devops to client devs to write single-use code for single transition so at some point we're just you know moving moving the work around it's not going to save work yeah I agreed my point would be that uh it becomes something that is just part of client logic if the feature is enabled rather than something that uh you know fooling other chains Etc have to make sure we were thinking about um but you're right it emerges them um yeah and Proto has an interesting

suggestion like do we just maybe skip the deployment part uh of the EIP put the contract in an address of Genesis for devnet8 and use this for devnet 8 give ourselves another at least three days maybe a bit more to figure out the right long-term approach and use that for devnet9 would that work that would be actually kind of smart if we don't then we don't have to yeah we just put it in the in the ad lock the Genesis airlock yeah and um that's something that doesn't work for a minute but it works perfectly for a test

in that case uh Barnabas or Perry uh can either of you just propose can neither of you just basically make that part of the devsnet8 Genesis file and like share the address with clients okay and then use that for Hive as well probably also for Hive yeah yeah yeah Alexa and can give you the code in like the next 24 hours or something yeah that sounds good uh we just want all the clients still to play Hive tests and uh it would be good to have that before uh relaunch any different hits okay so just to summarize before we quit uh so we agreed to not use the Avi uh for now we agreed to

uh like that we don't have time I think to talk about system calls wait let's just recap where we're at but okay no API for now we're gonna have the contract as part of the Genesis file use the same address as the pre-compile did zero XP and then okay if you want to talk about system calls we can do it in a minute I find oh are you still here yeah I think the last question was do we want to have the functionality in the byte code to set the relevant storage values so that

before the block happens you actually call the evm or did we want to not have that functionality in the bytecode at all and just in the EIP say clients will update these storage values it's right now it's written with the kind of conditional routing for the set as well as a note that clients could just update storage values that they felt like it right yep it seems fun anything else before we wrap up

okay sweet uh thanks everyone yeah yeah talk to you all on the ACB call Thursday thanks bye-bye see ya today

[Applause]