EOF Implementers Call #10

Transcript

okay hey guys welcome to the implementers call number 10. um yeah just to get started today let's go through some client updates see what people have been up to since we last spoke does anybody want to get started um I haven't done anything in the past two weeks I've been distracted with another issue at hedera so that's a pretty easy one that is an easy one never mind uh same for us we haven't added a lot of stuff besides the draft implementation

for eip6 206 or while the jump F AIP and yeah that's it great um evm1 yeah I can speak um we finally merged the EOS EIP uh which implements everything according to the state of the the eips um for Mega eof no the December December version of us um so that PR is fully emerged into evm1

and we think we did Implement a single piece um with the exception of the transaction format and defined in mega UF in evm1 and there's a handful of PRS for that I think there's four PR's um and those those aren't merged um but they do seem to work and yeah I mean outside of that is it was this spec work um which we did awesome uh any updates on your guys's go ethereum branch that you've been maintaining or not so much um I don't see Hugo on the call

I think Hugo updated the Indigo ethereum branch and changing everything to Cancun from Shanghai and I think he did refill every single test uh using that and there is a number of different PRS open on the test repo um with those refill tests um yeah I think that's it really okay cool and um the evm1 implementation is passing the field tests from that as well so not not exactly I think some bugs have been found I'm not sure maybe Reddit can talk about that yeah radic is on the call

um there may be some yeah so maybe some boxing go ethereum and maybe so today I actually I recently around the state just on the ev1 and I found a couple of actually there's six Stacks it's six tests failed but those that are related only to two different two different issues one is that probably get does not burn all the gas when the uh when the inevality you have construct is being deployed by the create instruction create op code and the second one

is related to call F and the plug that let me let me remind a minute uh it looks that okay I don't remember now it's it's in our chart described but one is related to that not burning all the gas and the second one is related to okay yeah I remember so so with colf for some reason um for a couple one test the get implementation throws the stack Overflow exception when it should not be from there so yeah and that's cool got it okay

um thanks for those updates guys any other clients or things to mention for client updates a compiler updates does anybody have anything to update on the solidity front um I think the only update is the they haven't been doing anything extra since then um they do have like the December version of UF fully implemented and now I think Daniel is waiting for a bit more confirmation on the direction

um before he will invest more time into implementing maybe new features see let's move into spec updates I know that you guys have prepared the mega eof in-game specification do you think you guys can take some time and share what's changed in the last few weeks yeah I can give a brief update um I think in the last call or maybe the the one before that we kind of agreed that we will make um a PR to the EIP to describe the changes to the eips to describe the

changes and we actually haven't done that instead we duplicated the unified spec and and added all the changes to it initially we did that just for for ourselves to have a record of all these um and now I mean we could do a diff compared to the unified spec and extract it but it seemed good enough for this conversation um and the background information is that we have spent the almost the entire last week in in a personal meeting to discuss these features and then to add it to this new document um and basically it does specification

includes all the changes we have been discussing including this UF 1.1 and EOS 2.0 um so it is the the final version we think we should be going towards which includes non-observability of code and gas which implies these new create instructions um we do have two different create instructions we have create three which I believe we already kind of extensively discussed and create four which is this new version uh taking init code from the transaction

and this transaction um the change we have in the transactions similarly to uh 4844 blobs we have a list of init codes and these list of init codes can be accessed only through the create four instruction in a transaction context um and with this it is possible to actually not having the need to introduce a specific create transaction and we also included in the appendix of this document a Creator contract um which would be using there to create four instruction on this Creator contract I mean basically anybody could deploy something like this but we could

also have a recommended version at the known address um besides this um yeah I think the only additions are the data op codes for data load data copy data size as well as the changes regarding the observability which means the xcode and there we chose the the version we kind of agreed to that style which means if the target is eof then we treat it as if it was ef00 and that includes the delegate call change

um there is one so with the delegate code change what was proposed um is to disallow delegate calling which direction I think eof to to Legacy um yeah that was proposed and and this version we chose to disable both directions um due to unknown unknowns but there's already a comment on the document that um maybe this is a bad idea because this would um this would make it impossible to have upgradeable contracts point to new EOS implementations so this definitely plays

a point which needs to be discussed um yeah I think that's like the quicker summary um is it the case that if I delegate call like before this restriction was in where it was just a one way that if I double get called elf that the El oh yeah okay it's the UF just can't ever though I'm trying to wonder if you could have a legacy contract that's like a front to an elf contract and sort of use that to get around some of the eof restrictions but I guess that's sort of why you're looking into Banning it both ways my concern that was my comment on there

my concern is if we ban Legacy from calling eof delegate call is it anything that operates through a proxy an upgradable proxy will be locked out of eof they will have to continue to use Legacy and that puts a barrier in the idea of getting as many people to let to migrate to eof as possible um so that's that's my concern with blocking it from going into eof leaving eof it's demonstrated because you could leave eof and do self-destruct through a little proxy you know a little nothing but a self-destruct contract and get away with it but I'm not seeing you know since we're taking away features from eof and not adding them um you know if there's an attack scenario it's got to be pretty creative to go from a um a legacy proxy into uh

eof contract representing that proxy right because it's also a one-way door and they can't come back out once the proxy goes in the eof land to leave it they'd have to do a regular call not a delegate call yeah I'm generally in favor of trying to avoid unknown unknowns but it seems like in this case because this is a pretty strong use case being able to have your upgradable contract plan to eof and maybe we should

consider relaxing that restriction unless we find some more concrete evidence that it's not a safe thing to do yeah we had no clear case um we just started on the side of caution but yeah I mean this coming from Deno is is definitely important cool yeah I mean we should think more about this scenario but I do think Daniel's comments are pretty valid yeah this is a lot of stuff awesome job

assembling this the specification with everything are there any outstanding questions still I think on the agenda you said you wanted to talk about whether it was still an idea that these things should be rolled out separately as in like an elf one first and then uf2 adding a bunch of the Banning of it code introspection or doing just all of the eof features that you spec'd out in one go should we talk about that um yeah so even even

um before that big a bigger question we do have like two three smaller um questions regarding the the spec okay um we don't need to we don't need to come to a decision on those but I just wanted to highlight what these questions are so one is uh obviously you know what was discussed is delegate call so I think we're a good track on that um another question is regarding the this init code list on the transaction um we need to decide on the limits and the cost of that I have some ideas how to determine the

limit um you know based on whole data repricing eips and 4844 but yeah we haven't done the work on that yet so that's like one bigger piece missing um determining the the limits and cost of the Senate code list there was another one is uh the init code is valid is the init code expected to be validated as part of the transaction validity or is the initial only validated whenever it's invoked okay yeah I mean I think last time we just decided that the

um the create transaction you know regarding the nonce and we always include the the transaction even if it's it has invalid the UF code and following that uh we don't want to validate this right that the transaction level we only want to validate that the time it's used otherwise the cost would be also insane yeah so for the cost would it probably just have to do with the data cost of the inner code or is there another okay yeah I think it's the question slightly closer to call data

yeah I mean I guess the question is like where does it sit on the spectrum between call data and blob data probably a much closer to call data yeah I think so I mean the only difference is that you cannot freely copy it into memory um so it may be cheaper for that reason but it's still accessible right in its entirety yeah and it's because it's accessible as part of the block execution has to be propagated with the block whereas The Blob data the reason it can be cheaper is because it's only receiving like the hash of the data I mean I guess the nodes have to propagate it anyways so

there could be a debate on why the Bob gas is going to be that much cheaper but okay it's a fair point well aren't there design issues like there's only one blob per block um I know now typically for a really large contract there would only be a few tops two contracts per blocks that it cost six million to deploy at 24K contract um but if we put in the blob I'm concerned um well break layers that they're trying to separate with this use case so that's I'm in favor of call data treatment too sorry I'm saying I'm just I'm just talking about the pricing of the blog pricing it definitely has to be in like close to call data it may not be called

call data but it has to be in the whereas The Blob only has like the blob transactions would just have the kcg Commandments okay so if it's in transaction data I think we charge the same payload rates as uh as input data we just don't make it accessible via call data copy that seems like the safe route and if there is an argument later on that we can reduce the cost of that because of X or Y then we can make that happen foreign yeah so it is one of the discussion points and I think more importantly the hashing basically the address generation of

create three and three at four that is a big question mark uh we discussed this heavily at Edelweiss but I think that needs to be Revisited because currently it takes takes the sender the salt and the um basically the index code including the auxiliary data and which is the same as create two but I think there were other ideas had to do hashing I'm yeah I'm not sure we can reach to an agreement today on that

I mean were people wanting to like take out sender or something what's the differences on those layouts what are the hot issues so I don't fully remember the discussions but um there is at least one implication if you look at this Creator contract idea that means the sender would be the same you know if you used the Creator right which would break uh unislap versus Sushi swap assumptions yeah I mean you could still um

have factories right where the init code is is already in the state where this is not a problem right because that's a sender was there one I mean basically it's just the last question the the Creator contract but this kind of in conjunction conjunction with the the hashing question yeah I don't think we can I think that you know the cost of of the net codes in the transaction that that is something we can

research async and come up with some price and agree on it but this hashing probably requires more brainstorming and coordination hashing at the Creator makes sense anything else on the spec small things to discussed before we talk about scope a little bit more I think nothing from my side but Andre or Reddick do you guys have anything

but I had some questions about um if they don't uh what we're doing with call and the 60 getting rid of gas is there a need to keep the 63 64th rule when sending all gas to the next call or it would be just getting rid of stipends yeah I mean I responded to this I don't think there's a need to keep it um but if you keep it the code um you know the implementation it wouldn't be Like A New Path um I mean not necessarily and as we discussed in in Edelweiss this could be the 6364 tool could be removed later

without a breaking change to eof and maybe for that reason it's it's fine just to keep it to reduce the scope but I don't have a strong opinion okay so but we're not letting specify the gas which prevents the lockout so we still have the feature that if they run out of gas it's sending more gas will always fix that it just changes the math on it okay that's that's the one feature I want out of getting rid of gases to to solve an out of gas problem that's setting more gas always fixes it it might be an absurd amount of gas but more gas will fix it should we talk about scoping if you walk

now cool uh okay on the issue you guys laid out this question kind of trying to understand does it still make sense to think about eof in these two parts or should we be pushing to have Mega elf go in as one complete unit curious to hear what your current thinking is on those two approaches you meant me I mean I do have an opinion

but I didn't want it to sway anyone so maybe yeah not from Epsilon wants to share an opinion for your control of them Mike oh sorry go ahead no no just just just go ahead you actually raised your hand I think you should go first okay thanks uh well from from the from another mind this sentiment is that we do want UF to go in one unit without any intermediate steps or separated steps just one big eof

got it there now so for me it's a scheduling thing it's a question of when 4844 is actually going to ship if it's looking at a Q4 minute activation um you know I think we could conceivably get mega ready by then if we push hard but I think another option we want to consider is if um 4844 is looking at the Q3 banded activation particularly early Q3 as in we start talking finalizing tests and closing out scope just as soon as the current hard Fork uh not Cancun yeah

um as soon as Shanghai ships if they're going to start closing down scope um do we have an appetite for being the lead feature in Prague in a q1 of 24. I think is one thing we should consider um I am open to all these options and possibilities I don't particularly have a favorite but I think what's happening in 4844 I think is going to determine our time frame more than anything yeah that's a fair point and I mean to be honest I mean we'll see how things play out with the scope of Cancun but right now we're talking about doing a lot of changes to the block structure to make SSE and I think if we end up doing those changes changing the remarkable routes

in the block and stuff that's going to be a pretty large for completing 40.4 so it in My Views probably going to be difficult to push Mega 11 at Fork but if eof is going well then I think it seems pretty reasonable it could become the lead for Prague because vertical trees it's unclear where things are at with that the last that I've heard from some people is that the numbers the performance is still like two to three x too far away from where it needs to be so it's something that we could like realistically be looking at doing early to next year as the leading thing the

leading part of the fork but yeah I guess like generally I also like the idea of doing eof all in one go my biggest fear is the test surface of that it already felt whenever we were trying to close down to the original eel of one for Shanghai that testing scope was starting to reach the limits of what was feasible and now we're at age 50 on top of that it's probably just a function of how much time we can put into testing but it's something that I do worry about a little bit so I wonder if we could still notionally

have it split into Infinity war and end game um where we would do um we would not do creates we would not mess too much up with the call um we wouldn't do the big outside ebm but we would focus on getting something that's December plus that gets adds all the features and turns everything off that would be needed in endgame and get testing and working on that and get solidity validating some of our assumptions because I think we would need to put in the um um I mean the problem there is I mean the whole in how you introduce eof into it into into the entire system we wouldn't want to have the old Legacy pass I mean I like the idea of being

able to get multiple steps to get at least testing written against it while we progress to the next future steps I don't I'm I'm rope I'm working at my mind I'm not seeing how it necessarily works out well doing anything other than just doing it all in one go and because we can't test everything until it's complete you know you can test parts of it but the infrastructure we're gonna need to test it's going to change as we bring in the other parts later on I mean there's a question of how much you know testing infrastructure we want to put in place and tear down as we get the final end yeah yeah I I feel like generally it seems more efficient even if it takes longer to get to testing to just do all

of The Upfront development and then Focus hard on testing rather than having this back and forth where you implement some stuff the price of tests influence more stuff rights and tests I think that ends up taking longer I don't know if Mario has any anything to add to that perspective or maybe a different perspective oh well I haven't been looking at the Earth recently but yes uh so far my thoughts are that it's already quite uh complex to make an effective test case for UF um so adding more stuff

um I think it definitely is gonna complicated testing a lot but uh I mean I haven't seen the most recent changes to the eof so I might be wrong but yeah from my past experience writing tests on yeah it was complex already okay uh that's I guess kind of some of the perspective of the non-exilon people do you guys want to share what you guys have been thinking since Super Heads down on this the last week well I can share my opinion it's not

like uh a combined opinion of the team but yeah I was personally leaning towards to introduce it at the same time otherwise otherwise they just let me make it complicated but definitely concerned about the size of this um because even the December version was uh quite Hefty and unfortunately this would go outside of the boundary of the evm with the transaction change which I think is the biggest worry for

me I think every single other change just staying within the evm however big the changes are I think it's more reasonable but once we cross this boundary it becomes um maybe not only just technically more challenging but um you know coordination wise and getting it into the the system um even just thinking about all these discussions on how many resources are allocated to any of these changes on the client teams and uh you know so far because we were within the evm the people working on evm and each of the client teams were kind of separate so there was little overlap

in other changes and once you get to like changing transaction types maybe there's like a bigger argument that this takes away resources from um you know other proposals which you know maybe people think are more important than UF if we do end up splitting however then I would still include um the data of codes in the first rowlet because those are relatively simple and I would try to include most of the um you know regarding observability

uh like the X well yeah I mean that's the hard part but with including the data upcodes and removing the xcode and x and opcodes um it is possible to create these immutables because you can read them with the data um and so the only change which would move to the second rollout is create three create four and the transaction however even if we split this into tutorial rollouts uh I think we we have to have the implementation of all of it ready and tested

um and understanding the implications of these later changes and I think that's why it's good that we have this combined spec because we can we can understand how all of this uh operates together and it seems it's easier to split after being sure that all of this is going to work together well um yeah so that's the the answer and non-answer what you're saying sorry I I've never found the hand icon on this interface um what you're saying makes a lot of sense to me Alex and I've said before

and I'll say it again um anything that doesn't go in now there's no telling when there might be another chance I mean our history is that that it can take us years to get to a new release a new upgrade um this solid I'd be married very motivated to see that I'll go in soon so if we do the two-step I do like the idea that we do everything but to create op codes and um so we have a fully functional within the system um and the transaction changes because I

can see that the full SSD transaction changes would slip out of um Cancun just to get 4844 in it might be a major focus of Prague so that would slip strip in very well because then we could activate create four in fact we could probably even ship create three with it um there's a possibility we could do you know deploying because I mean what we really lose by not shipping create is to have things like uniswap migrate over and the ones that depend on deploying contracts and maybe some some Dows that that deploy worker contracts and I think that's a huge use case that we need to be able to to get to but I think there's enough use case without those huge use cases

um that we could you know put it out there and show that you know these last pieces coming in and the next release um because it you know requires integration with the with the transaction formats but that it will be you know fully functional there um and it can get people who are really interested in doing things like like saving gas size and saving contract size I mean getting rid of jump dust um some of the stats they brought up from from the solidity team as you say 20 space just getting rid of jump desk alone which increases in effect the amount of data you could put into a single Mega contract so if you could delegate into those contracts you would have you know less need for the diamond pattern without having to increase the sizes I still think there's even without create I still think there's there's

value to be shipped in two halves but at the same time I'm not you know I would support either approach I'm not opposed to to going Mega eof but I think you know honestly the the scheduling that's going to come up in the next ACD I think is really going to drive more of it than anything that makes sense I think I generally agree so it seems like the takeaway for the most part here is to focus on Mega eof try and see if it's possible to make this change happen all is one unit and I guess in the back of our minds

keep an eye out for things that we might be able to push into like a later release if it comes to that point if we're you know realizing maybe later on down the line that the scope is quite large then we could cut off create for or create three and you know propose them for a Future Ford or something does that seem reasonable uh okay guys what else should we talk

about what other things do we need to consider to move you up forward it seems like for the most part you you know the Epsilon team has been working really hard on this specification and it's getting into shape and so the most likely thing seems is that we just need to start making sure that we have implementations and that's going to reveal places where things might be less specified or things that we might want to change or are there other things that need to be done before we get there um I would emphasize the need for um test cases right because

we depend on these test cases a lot to verify the implementations that we're working on and merging these implementations to our Master Branch so before we have a working test cases all these drafts that are we are working on or whatever um they are just drafts right and they remain drafts in our eyes till we pass certain Hive tests we we pass certain sorry we pass certain ethereum tests and and stuff like that so I think it it's worth thinking about that yeah no I agree it's just that to

generate those tests we need to have a reference implementation built essentially so that's yeah kind of the place that we need to get to I think that the implementation is the people been working on are emotionally targeted on eof 1.1 and you haven't really started working on the UF uh Mega eof yet but it seems like that's sort of The Next Step I feel like we sh we don't need to keep bigger EOS in place I think it's okay to ruin the current big UF or like you know

maybe make a copy of your Old Branch and leave it somewhere and start working on this future branch yeah I think the more annoying part is the the test thing um in regards to you know what uh yeah what four can have to to choose any of this I think what we're going towards is to Implement all of these or Cancun in the tests

and if during the process it turns out that we need to reduce the scope then we move like the create tests to a different Fork yeah um I'm not sure if doing anything else seems to be an Overkill I think I think that makes sense to me do you guys have an idea given the like let's say this back this sort of Frozen modulo Maybe sorting out some of the gas prices for these things like what will it take to get this implemented in evm1 so that's how like the test can be filled is it two months is it one month correct me because he's working on the

create tree and return contract and data of codes I did an implementation of the delegate call and the X code changes and the xcode change took me five minutes that I get home took me another five minutes uh without creating unit I think create three was a bit more a bit more work but all of these are kind of implemented already and I think these should not be too difficult to implement in any other client the the piece which may be a bit more

difficult especially for evm1 because uh it's really just concerned by the evm and not anything else outside of that is create four um and likely testing for that may be a bit more complicated but I think for everything outside of which should be in a good position to you know start filling tests um you know and next week what a week after so if any other team would be in a position to start implementing some of these and maybe collaborate on on test cases that that may be a Way Forward

um and I think lastly on tests we were looking into I think radic is looking into it to use the execution spec test um instead of just writing the the regular test cases by hand well would you want to set like a Target dates where you expect to have you know an initial set of test cases filled like is that something that we could say that this time next month like it doesn't have to be super comprehensive

and test every educates but this time next month we have the specification quote unquote Frozen so that we know what we're implementing and we have some tests filled that Target that specification so that client teams can start updating their implementations to support these new features or would it be something longer like maybe the first week of May or something yeah I don't know the answer personally but I really hope we should we should have some some basic tests uh soon um I would say the the priority now is to fix the current state test to to pass

the tvm1 and after that we can we can look into new test cases but this reminded me one more question mark regarding this spec which came up today is the header with the embedded containers and from a is packed wise it makes sense to make them optional uh from implementation wise I think Andre ran into a case where it would be so much simpler for the implementation to make the mandatory but that comes with of course an overhead for non-create uh contracts which I personally don't think is a good good way

but this goes back to you know the header discussions um in any case it would be nice to have at least another client implementation go through the create tree and see what it runs into um you know soon enough to to help us with stabilizing the the spec do we have the header format I didn't see that in the mega eof yeah because we forgot to edit on a weekend and it was added this morning by Andre um I mean that's where I would start if I got freed up from my hedera commitments I think I think we're gonna

be I'm gonna get more time to work on this definitely this week or I'm going to see to it so I'm sure there'll be more discussion as people they dig more deeply into the Maggie UF spec but it seems like right now everybody is relatively satisfied 10 minutes left any other things that we

want to discuss seems like we have somewhat of this clear path forward for the next two weeks yeah a question um who had the chance to to read uh yeah this Mega EV spec I think Zano because you commented you you likely read most of it um but did anybody else set a chance to read it yet sort of glazed over the most of it all right I haven't but I have a

question regarding of the differences between this and the previous version um and this is regardless because I have the um a draft for the execution spec tests but this is completely based on previous UF version so I have to pick up those those tests and just uh upgrade them to the mega iof so should I keep separate branches of the tests uh or between the the previous version and the mega UF or um how should we go about it uh I don't know I think it seems question

similar to how implementations should be organized like whether they replace the audio of information completely or uh or make a separate Branch I think this new spec is kind of an extension really and it can be separate so it's not difficult to have them separately and build the second one like the big one on top of the old one so I don't know it I think it's up to you regarding this okay great thanks any final comments guys

okay thanks a lot awesome work on the mega elf spec everybody on the Epsilon team it's also see all the things coming together uh we'll have another call in two weeks for people in North America and time zones that have already hit daylight savings it'll be an hour earlier but yeah it'll be the same UTC time thanks a lot thank you bye-bye thanks goodbye have a nice day bye have a great one