EOF Implementers Call #67

Transcript

uh I'd like to welcome everyone to EMF eof implementers call number 67 19th of February 2025 um yeah so let's go ahead and start with the agenda not inter actually at the bottom so um we'll have testing updates um talk about client compiler updates and we'll talk about uh the dev nut um is the main feature I'd like to get devet one scope nailed down in this call if possible so we can get this um ideally at least some clients working before um pectra activates um in in April and then after we go through the

the post dev. one changes request add pay to the list of things going into um [Music] into uh the eos's bucket because of some things that the E does with it okay so notes yeah man in the other screen so let's start with testing updates um Mario well let's let's start with the. one um you know D one got it launch last week working with the devops team I got four clients on there with five different distributions um marius's a version is different from mine seems to be holding up just the same um so the only issue is he doesn't have the

tracing for the wasn't yet um otherwise I would have just completely pulled mine out of the cycle um we've got mine and mariuses we got nether mine re and Basu R um as far as the other exit criteria I think I am 8 hours over the um tracing run the diff run so now I need to run the transaction fuzzing step of it to and run that over the next 24 hours and um yeah and then I need to run the the East for all of them which I think I already did before I did the fuzzing because if they don't pass the East they won't fit past the fuzzing so I did that before the fuzzing and I think we could you know put a lid on eof devet one

after this um I think let me go back to see you have test yeah eel test they're staying in sync we got them staying in sync now um after got the fixes published one of the funni things was the um the RPC node was published with an older version of gu with a GN bug um they fell out of sync but still kept serving rpcs and serving up you had block cash serving those up um but after that if you um were to continue to use them they'd be just fine and yeah so it looks like we're about to hit the exit criteria for it uh we'll talk abouta one um and a little bit further down the discussion

uh Mario do you have any to talk about for East so the only thing is uh DPR uh it got merched yesterday it's uh the test state test generation for con validation tests so um yeah and basically this allows uh all of the EF container relation test to be uh deployed as a transaction uh through an init container in in satest and also in live Networks um so there's um there there was a a small issue that when we did container evalation for init code containers um we were wrapping into a factory container

but that was fixed and now we basically just send um so so if the container validation test is an init code container validation test we just send that uh right away as a transaction data um so yeah we with this we can basically just create um uh tests in in live networks and send them to theet um I have another idea that we could introduce that is on top of the container um testing

yeah any questions so these will show up in the transaction log the valid and invalid eof tests because of the way that the we don't validate when we execute the transa when we submit the transaction in the pool we validate the execution so a bad eof test will show up in the blockchain and just be a a transaction that's really short right exactly so now now it's basically in bed containers they they this the transactions should uh be accepted but there should be no container uh that is left in the in the in the blockchain is that is that what you were

asking or something yeah that's what I was asking all right so that way all so that way only one client has to read it and post it you could just have a network with one client and have everyone syn it and then all be the same it's not like this is the RPC only test exactly exactly so I mean if you want you can rerun the the same tests the same set of tests with all of the uh rpcs available at least one from each client and you can validate that they uh they can uh produce blocks uh with the with eof containers in it that's another option yeah they should get a chance typically in the rotation though I mean

yeah yeah I don't think I I don't see it that is completely necessary I mean if you like take one RPC at a time for each test you will get sufficient uh testing for each RPC I I I I think yeah and you can always manipulate like in cryosis I wanted the simulator Network where nethermind had the lead um so I had like give them like four times as many Stakes as any that not so there's ways to make it work if you need to go around just doing the generations okay yeah and for and for the extra transaction that I was mentioning this is not implemented yet this is just an idea so basically for

all valid containers that should deploy a container on the on the network it's possible to just send another transaction to the deploy container and see what happens not expecting something specifically but just expecting consensus on the execution if we say if if we see that as as uh valuable okay cool um great any other testing updates any updates from anyone else related to testing yeah I wanted to do the the

tracing um changes to to my cat um but I got sidetracked by this other P thing that talking about y That's it okay yeah tracing yeah that what what was written for the evm go lab really made tracing super easy so I'm glad we have it it's a great tool um name people out all right then how about you start

yeah okay uh just completed the first review of the branch um just a few minor changes nothing um algorithmic spr okay um I can go see who's next go ahead yeah so for us um as as Beno already said um I have a different branch than his and I've been slowly trying um to Port all of his changes over to that and um yeah so far it's been holding up well on the death net and so the only thing missing as I

already said is the tracing um but I want to get that done either today or tomorrow um yeah that's it all right um B anything leis um no so I think the devet zero is running fine right I Haven uh yeah it's running f hearing yeah so uh on the contract side on the system contract side um I did just a quick chat with folks here um it's uh I think on the

devet what um happened also for previous system contracts they they added them to the Genesis file when they started it off that might be what we want to do this case um not like the one the approach that was done for the block hash history where you need to you actually need to populate the the chain until you enable it um so yeah I'm not sure if that will be but I can poke around a bit more okay um ref from ref on I'm not seeing anyone from w

um and we don't have anyone from ethereum JS or Aragon or we have Aragon I'm Aron 3 um anyone from E want to talk about Aon or Aon 3 do they know much guess that's a no I did hear on chat that they have a branch that's getting close but they don't quite pass all of the EST EST tests and to get into fuzzing um the very first round is the E test as the seed so they won't get very far in fuzzing if they don't pass all of them so that's um what I use as a seed for the fuzzing that I

run um and there's no Nimbus okay um compilers uh communal solidity okay so two things on our side one we have a branch making use of D and and to elate T TOS finally on UF and the other think is that we're planning ear next week so that we includes that feature like all the previous work for U that's it okay so yeah this will be the the pre-release version of eof because we're looking at doing some changes in the next some

final changes last one we going to lock down um what we're going to talk about in this meeting yeah of course I mean is basically like experimental feature like prototype quality I already let people try to use it and like give us feedback cool um Charlie we don't have Charlie Viper on um do we have any other compilers or teams that want to give an update before we go to the main me of the meeting all right hearing none let's go to the main Mee of the meeting um so last week I presented a plan for

devet one that had CX create and the create contract in devet 2 um the big proposal that I have is to actually move that into Dev one and my reason for that has to do with um how things seem to be shaping up in all cor devs there seems to be a desire to ship Paz the moment it's ready um and so I want e to be in a position so that we're also able to ship in that moment when it's ready and I it's looking at the clan and the only thing that um we would really miss if we shipped at devet one not devet 2 would be TX create the reason there is because we can get rid of um the 7698 contract

creation uh transaction and we're able to keep the um the contract creation unchange for legacy and have that be the old Legacy path and lock that down so eof doesn't come in through there so we can keep a a cleaner separation between the two um and so then we would need to also deploy the system contract for the deployment contract for the for the so deployment contract as part of this as well so my big um reason for putting that in there is once we get that shipped then literally after devet one and devet two or if we do a three or a four um we will be able to ship the moment pias is ready and the moment pias is ready to go and um my my perspective

of this is that this could happen on very short notice we might be in the middle of a Dev net and peras comes at ACD and says we passed all the test let's get ready to go and because the amount of blob use that's coming on the net is going to be valuable enough that they're going to want to drop everything and ship so with that in mind uh my proposal for devet one um is to lock down any breaking changes after Dev net one and so we pull everything that might ever need to be a breaking change in here we could have shift zero we were going to Shi zero in Prague but we um wanted you know we could have that would have left us with the contract create transaction changes forever um we could have shipped TX create without with both of those in

place by moving into into devet one we um can leave contract creation alone and let it mean what it's always meant for the future um and there's a few other things that we were going to change um one was the eof create hashing that we went through over the meetings um to reduce it to um it was just the address in the hash was that correct Peter you're off mute but your microphone's not working the address and assault yeah okay and then change the backboard in

EXT call um change the data section from ox44 to Ox FF um and that's to ensure that the header order matches the body order um because in future when we add sections we're going to add them before the data the data needs to be at the end um there is minor spec change that create create two when they see stuff that starts with ef um The Proposal there is to go back to what it was preeo and treat the same if the create starts with eof and return contract just do a name change on some of the changing elements um that would leave for for per

per for here it as EF DEET one the metadata section um post one two metadata sections TX code address and TX code type and these are all strictly additive um we can add these without breaking any backward compatibility these are all forward compatible changes and once we ship devet one we move into the area where only forward compatible changes happen so that if you have tooling that produced a contract that was devet one compatible um it will be compatible going forward so that also is an important demarcation line for tooling they can generate it there without having to put the experimental flag on there um that this is what it's going to look like when it gets activated um any comments on my proposal any concerns any any

discussion um I mean I agree with it my main concern was um being in the uh having a backwards incompatible change plating but that's that's solved by bringing the transaction create for so I'm all for this yeah I like this separation about um like for yeah backwards in compatible changes first and then have forward compatible

whatever um and also it does it look like we'll have more resources to work on this so yeah I would I would appreciate if we can pause any of these three eips mentioned in the definite one or like post definite one changes right um yeah I really didn't have any time to look at this how they look like now okay quick question is adding metadata

section truly backwards compatible yes it is because it's optional right because it's optional right so that's the way it would be going forward any new header and body sections would have to be optional you need to be able to work fine without the header code being in the header and um once the header code is in the header you can require in the body um I could imagine there's going to be some changes proposed in the future possibly used on layer twos and other places where it's just a header code um like maybe they're putting in a marker that says this uses arbitrum special feature X and it only works on arbitrum and they could do that just fine um or if if yeah can't think of any other header specific features

other than you're doing like a minor format change or you're saying that we disable these op codes or something um or you enable certain op codes you know maybe there might be a header that says actually we're going to allow all the Legacy op codes YOLO have fun um but that would be something you could do just the header so that's why it's back RIS compatible so if you the philosophy I have on backwards compatibility um is you take the entire set of valid contracts if there are if this change results in no contracts being taken out of that set of valid contracts and only add contracts to that set of valid contracts um then it's forward compatible um po yeah um so I think what is missing

here is this uh is this like initial Factory contract right that will deploy with TX create instruction yeah is it part of the TX create AP AP or it's a separate thing um let me it's part of it's part of the pr right now but we should call out explicitly yeah um I don't know if did we get any feedback about visibility of this not on the call yeah not not on ACD last week um discussion went a different direction um we were asked people to do AC feedback and I receiv received know

such asynchronous feedback as well um so I'm probably I should probably post another request for a synchronous contract in the ACD thread in the ACD chat room and start a thread for it yeah that's that's one risk I see and second is that how much it I if what is what are the chances that um it will significantly like pause testing because we don't have it fully figured out I guess East test will kind of work still right because we don't really

depend on the create transaction very much but uh so unless it it goes to like like T10 tools I'm not sure but uh yeah probably not um okay yeah it seems like quite a quite a step to make and I so yeah it sounds like there's two steps TX create and then to hold contract only um oh also we need the this includes the init code trans transaction type this is the biggest change I think

more so than CX gr support is the init code transaction type um as Mary has pointed out during Petra there's a lot of testing that needs to go along with to go on around this um it's not just something you throw in willy-nilly um so there's there's going to be some some things that be looked at it impacts it just as you just mentioned it impacts the tooling the toolings have to start um just the testx create will have to support the transaction typ and that's before we do everything through the greater contract oh I missed one I was reading off the wrong spec

we'll discuss that when we're done with TX create Mario so what do you mean um this will affect uh UF test type I don't think so right it doesn't affect the container validation tests but you're referring that it will affect the state test generator from it or somethingest it'll also impact execute remote and execute Hive um because in order to put these on to U in the transaction you would not use the Creator contract format anymore you need to use a new transaction type where you would put these instead of putting them in the payload you would put them in the init code and you would Target the whatever address that I think it's going to be a or b the whatever

pre-compile address that the toold contract will land so it would change the type of a create transaction that you would send um for for execute and also for test for weest the creation of the transaction I see I see but the the I mean the good thing is that if we make this change in the so we have this conversion um method that converts the E of container test into status so I think that should be the only thing that we should change and on top of that maybe uh so we have also EF state test uh format which is basically just creates a um a state test from from a transaction and but those are like very minimal the

amount of test is not that not that many so may so manually um updating those I don't think that's going to be a big deal but I think yeah it should be analyzed anyway um um right yeah and I think we'll be able to figure them about if we um disable if if we do a check for EF code and the create transactions we make um than been um if we see eof create in the create transactions we can throw an error in the tests there's also going to be a small smattering of transactions were explicitly trigging triggering the create transaction at least in the um in the 70 76 98 tests we have a few of those being tested those

were any of the problems we had in the devet came out of that transaction because they weren't I didn't have them tested very well and it doesn't really fuzz it does not fuzz well at all um so that was that was where we found all the uh where both of the um bugs prior to de. zero were found so so there are going to be a small amount we have we'll find so what do you guys uh think if uh we create the branch on evm one that implements TX create and we we just just to take a look of out how many tests are impacted by this yeah how hard it would be to to modify evm to to support this E1 used to support

xrete before so it's likely not as easy as a reverse but uh should not be terribly hard what do you think Pavo Andre yeah I mean we we had it with then we move it to Osaka then UF moved to Osaka so we actually removed that uh but yeah there this code for it in in the history so I think it should be relatively easy to bring it back yeah I think with this in hand it would be very easy to go to to check how many of the of the current test break and we can better estimate how much of a

rework is going to be in the testing side yeah I still see one issue here um and it's related to this Creator contract because is this is like strictly needed to to do any testing on devet so it means it has to go probably to the Genesis file of the devet because we need unless we implement the the fork transition with this and we don't have any of these so far I see so without the contract you can't do any on dev and and in case there's a issue with the contract itself you need to reboot the

I see so yeah um I mean on the testing side just putting it in the Genesis is not a big deal but the bigger deal I think is deploying it in in main because if it's going to be like a regular State transition that's that's a little bit harder to test but yeah we can we can we can discuss it uh when we when we when we decide the method of deployment y yeah this this transition is I think the bigger issue that's going to come up when we discuss it in ACD there is a world where we still support 7698 and the toold contract um if that's where it needs to go if we can't get it figured out before pias is ready um but I would really like to try and get to a world where we don't

have um the old 76 98 support to kind of deliver on the original vision of how we would do the EF contracts so basically we have contract abstraction you know go for abstraction abstraction while we're at it okay um TX create any other issues concerns comments so also if there if I understand correctly there's going to be a new transaction type is that is that correct yes because spear is right now trying to figure out if they need a another new transaction type so there's going to be like um need to coordinate

which transaction trap is going to be used for each feature yeah as as far as I understand P does not need new transaction type then only changing the format of the proof so that should be possible in the in the same transaction type that's discussion that I have on so so they're back to no transaction they're able to do it in a side car all right so I think probably the easiest

solution is that we get the first one since we're guaranteed to need one and peras can then decide if they need it later right now they're in a no but if they target the one after us then if they change your mind and go to a yes they still have room so that's probably what I'll propose right um so one thing I forgot to mention in my list of changes is a change I want to propose in the container size um for the container so right now um we were trying to be um consistent in all of our header sizes

and have everything either be two bytes or a two by link followed by list of two by items for containers I would like to propose a change just for the container number which is ox3 that it's a two byte length followed by a series of four byte numbers my motivation for that is without that we cannot deploy contracts larger than 64 kytes um because everything has to come in the container and be created out of the init code then um we have a limitation on work Con exit point on the network so we'll go from 24K to 64k which will be great for a while but I think we need to be in a position where we can um have contracts as large as people want

because people are also going to run test Nets and layer twos where they're going to want to go crazy with contract size despite any risks that are um brought up um so by putting it at four bytes that gives us um two or four giab bytes depending upon whether it's signed or unsigned and if we're that's for for at least JavaScript script in Java um those are at the limits of the arrays we have to do different ways to address contract sizes and for um 32bit go binaries in case anyone uses those they're also limited to that go support 64-bit indexes rough support 64bit indexes but for some of the clients it puts us at the limits of the implementation if we use that number so I think if we do that number it's going

to be big enough until we see language level changes um what do people think about that yep let's do it okay think it's kind of you opening the the header the header format again which kind of imagine it's like it's like lot of details you can change and tune there uh I I thought a bit about it and I think we kind of assuming this subcontainers will not be

like the most frequently used featur so it probably it's fine I slightly have concerns about this Heather in a sense because we've added so many so many kind of exceptions to how you parse it it kind of the original design is kind of not relevant anymore in a sense it tries to be have some like generic structure but like every every kind of section has its own quc already and maybe just it's not worth to to do it this way and like I mean there was there was a proposal to just make it

the simplest possible version of the header to include all the information needed in the most most like simple and straightforward way instead of trying to have these sections and this stuff so I kind of imagine this kind of goes back to this idea so do you have an alternative that will get us to larger containers to propose no no I mean what I mean is that we have some kind of sections and and the think but I kind of try to be independent but you need to know what how to par each separately

like for example there's a type section that is has to be exactly the size of multiplication of the number of code sections and so you kind of uncode this information twice in the header and then you need to check if these actually numbers are equal to each other and this doesn't make so much sense um so so the the idea was just to put this sizes what we need in some simple form and that's it okay so for example number of code sections it's enough to encode the type section and all of the other things so we need one number and I don't know if we want to revisit that but seem we modifying this already and uh this

kind of idea this is somehow generic I think doesn't hold so much unless this is strictly did for this optional uh section so that reminds me of another way Miss extra type extra stack insites yeah but it might be it might be enough to go to the implementation and try to implement it and see like how many changes you actually need them to do and it probably affect this like this generic piece of code that try Loop over the section IDs and see what's there um so we can try to prototype that

and and see what is actually the difference in the implementation okay so evm will do a prototype and report back in two weeks yeah sure okay um and the one thing I put in there I mentioned um that we forgot is also changing the types there was a proposal don't know why I didn't list that did we drop it that we weren't going to change extra height instead of total height or did I just forget it no we want to do it still on the list yes okay all right so that's yeah that's just another

generation validation change that shouldn't be too bad that involve some changes to the um everyone's client including code generation but it should be fairly simple it changes from a validation to a generation rule cool any other um last call for uh changes to uh version one to the release version because I think after we Shi devet one is going to take something on the order of a security issue like we had a Constantinople to change

anything I have a question the point alter you of create hashing to just be address plus salt I think that should go together with the TX creat change which already uses that scheme so in a sense we don't want to we don't want to go we don't want them to go separately sorry I wasn't there what's the what's the benefit of the uh of just using address and and Sol it's the most flexible one it just puts the responsibility of including the right Sal in the on the on the application layer was argued in a

threat this also means that we cannot do counterfactual addresses contracts anymore right no we because we can have a a factor which includes the whatever it needs to include into the so okay so uh it can it can be you know um not trusted but you can be sure that if if Factory which is included in address um includes the init code hash for example in its uh in the Sal um then it can be contactual then okay there's a big discussion thre on GitHub which actually led us

to uh bring T Gren back because without it uh contrafactual deployments would be uh very hardol and there's also we can also deploy there's an earc I'm going to start pushing after devet one ships where we can have a standard set of uh create contracts that will provide all features that people depended on for like people people are going to want assault list deploys basically have a nobas deploy so we create a a standard ERC based contract and they can include that as a library and get their um know based deployments where they can deploy the same contract over and over to a new address um same thing if you want to include the address in your contract um

so there's I think those are the two not the address the um the init code if you want to include other hashes in there so those things that people might lose that would just need to write a smart contract around and we create a standard smart contract for those things they lose if they just want to come in and use them normally and because of what's what's most exciting for me about this is because we can use the init code transaction we don't have to rely on Nick's method anymore we can mine down the salt with the contract number and anyone can deploy it on any chain without having to sync money unrecoverable money into the contracts will be deploy so that's that's for for me personally that's exciting but um anything for devet one before we move

on to post devet one okay so so back to my question UF create is going to the UF create change is going to go together with the T create inclusion right we yes that's what the plan says yes okay so it's TX create um remove 7698 eof hashing changes EOS create stack order data section number create create two Behavior to be restored to Petra level rename return contract return code extra ST extra stack height in uh the code section and container

size becom four byes yes I mean that the that the E the first point is highest prior and we should you know make sure that it goes together in TX create yes more so than the next points which are just quity quality of life improvements right so I think these are roughly well I would put code a little higher okay thanks that was just something I want to make clear what are the requirements for something like the Creator contract like it's not going to have to be audited um what what is the process that this kind of thing usually goes

through we should get an audit yes that is something we will need is that a problem in terms of the timeline I don't know um I will bring that up with Tim and he knows he can get us the detail on that it should be a simple one but what's going to be tricky is the people auditing it are going to have to get their headp space inside of eof and what we're doing with with the hash changes and even with the hash changes I think getting an audit Lessing on it would be fine too we're probably G to have to spend some time back and forth saying no

that's exactly how it's supposed to happen um but yes we should get an audit that is I'm writing a sticky note I'm going to talk to Tim after this meeting yes and I think this should be like an I don't know want to say like like an audit that also takes into account whether the contract that we have written down allows for all the features that we uh are expecting it to deliver so all the all the modes of the deployments and all that the you know all the factories that we're going to create from out of this first contract that they will uh that you'll be able to you know control the addresses as you wish yes because right now I mean we you know we are uh expecting those all the

features like the contrafactual deterministic cross chain what not uh to be supported by what we have designed but we should we should have someone you know external F they these CLS and it's important to note that in the initial toold contract is going in for everyone the init code reference from the NIT code transaction is part of it so you're already changed the salt from what is provided in um so that's but you know that wouldn't stop people from deploying it CX create that doesn't have that requirement we'll probably want the Auditors to consider that um okay that's a good find that's I'll definitely talk to him about um devet one anything else sure we'll

think of something uh so just final comment on the previous thing should we consider this contract finalized in two weeks yes oh okay um yeah we need to finalize it I don't the notion that we needed to finalize for audit today is kind of surprise so let's consider it finalized in two weeks or if there's going to be Noti it's going to change we'll know in two weeks and I would think anything that would change from that would Strictly Come From audit findings at that point after two weeks do do we know any specific changes that we're going to have to do like anything in De one here will result in

changes no but I don't think anybody's thought deeply about it yet so that's why I want to give the two weeks I'm not anticipating any changes um but we need to wait for give people at least a couple of days to wake up the middle of night and say I forgot about that okay so we should like think about this it now is the moment to think deeply about this and make sure it's where we want it to be yes last call for Creator contract cool so post devet one changes um we'll discuss these when we get there what

currently is on the list is metadata TX code address TX code Type um if peras is not super early I think we'll have time to get into this um there was a request that came in on the chat room yesterday um noting something about the way the payop code Works um so what you could do in Legacy is you could zero gas your calls and guarantee that it'll serve as a pay or it will revert which um for some people they consider that a safety issue U to be able to pay someone so the solution that was proposed by WJ elements um long time um contributor to the forums was to

bring the payoff code back and that um is an existing there's an existing proposal for it people been pushing it for a while and this solves the problem in eof because you can say I just want to pay I don't want to call um so that's something to add to the backlog but where it sits whether it's in Osaka or Amsterdam or later is a game we play outside of the discussion of it going in so any thoughts on this brenio you're off

mute no no comments so let's think about this one for two weeks where it lands um I think is an issue secondary to getting uh devet one in place uh people may come in and advocate for it to be in Osaka some people may advocate for it to be in Amsterdam for scope um my initial guess is coming out of ACD is it's going to be immediately pushed to Amsterdam um because we're trying to limit the scope of Prague and anything that hasn't already been pitched but it's still open so it could go either way this one could show up in the in the Prague and Amsterdam discussions anything else anyone wants to discuss

while we're here when is uh um Daniel when is roughly your your point of view when we will be jumping off DEET zero to defet one roughly um so I think we're at DEET zero now I don't anticipate any changes I think we can lock in the versions that work um I would like to launch devnet one the moment we have three clients that are interoperating fine um I would really like that to be uh in the middle of April but I realized people got some busy things coming up in March um probably about a week or two per client

of work but then there's the testing that needs to pipeline around it so it might be not might not be available for a month um until we do it but I would I would really like to um when is wasaka act what do not usaka when does um when does pectra activate like it as close to that as possible um upgrade date April 8th

yeah sometime in April early April would be preferable but late April is fine um I basically want to be in a position that once we start going into the post pectra that we have something that we can ship in the event that P death says actually we're done let's go so that's that's my hopes and uh devet two and later we can take a more leisurely pace so it's going to be um heads down starting in March I think once we get the feedback from the e from the evm one um exploratory work all right any other

requests if not I'd like to thank everyone uh for the time they spent on this call and for the time they spend working on on eof um it's been great um we have uh the summon is INS sight uh thank you very much talk to you in two weeks