EOF Implementers Call #45

Transcript

compl call number 45 um uh we will not have a you may or may not have a call and meeting next week we'll decide that online um a lot of us are going to be um offsite um but we'll we'll make that call a bit later probably next Monday um the agenda is client updates compiler updates spec updates um one on address base expansion and TX create testing and then other items um there's any ests for things you want to talk about that are not on the agenda that Pua pasted into the meeting um please put them in the chat and we'll come to them as it comes to that subject uh first on client updates um

let's start let's see is Aragon on the call uh nope ethereum JS do we have any from ethereum JS nope Guth no one from gu all right nethermind I see amens from nethermind I like how he puts his client in his name uh yeah we are here can you give a cent update how's neine doing with eof uh we are reviewing our implementation we opened the pr I think on the eof spec Branch so we can indicate which eips we have already

implemented and which ones we are still re-reviewing uh so yeah that's mostly it we're most of the team is focused on deut zero and E was just reviewing our implementation catching some bugs here and there okay have you had a chance to look at the um code and stack validation code yet uh what so when I um went from Big E Mega eof um the places that took the most time were the stack validation and the code validation sections and um there's one of the op codes that um had some

significant changes um wasn't the XT calls um but that's probably where you're going to need to spend most of your time um that's also where we have most of the tests written for validation um so it should be pretty easy to figure out when you have all the features or not so that's probably one of the more heavily tested sections and reference tests okay we'll we'll try to run the tests again see how it goes okay all right um and let's see so Basu um I haven't had a chance to update the

implementation Matrix but the new column um the which column was it 7698 um we do have an implementation for that I just need to publish it in um there's no test for that yet we need to get tests written for it but it's fairly easy to test um and let's see Aragon ethereum evm one any updates yeah we have also creation transaction PR in progress and another one with new validation check for in container kind the that Charles sped out these are to in progress but I would

say close to completion some tests are needed to yeah yeah that's it okay um do we have anyone from gu on the call no they spent a week um they got some good progress but there's um I looked at their code and ran against the tests they need to get some of the and create code written as well as finishing up some of their validation so I think that accurately reflects their current state as all those in progress signs um revm no revm okay um that would be ref and uh so that's all the client

teams um no is anyone from solidity on the call nope and Viper um Charles already said in chat no imple updates from Viper okay um so that's a compiler and um client updates um Alex um I have a note here so we did um update the Readiness Matrix um and included a number of client and PRS uh from what has been discussed here so we included go ethereum and marked all of them working progress uh as much

as we could judge the do IPS are are being um addressed in the pr and the same applies to NE mind um so we found this one PR uh I think it was earlier this week and um yeah we we included all of these Zips as work in progress as far as you could tell um and then also on ethereum JS I think our assessment was that there is some support and there's a PR as well um but it seems to be very likely outdated um using probably early 2023 version of UF um therefore we included it in The

Matrix with um the marking stale and the same applies to to Viper um even though chars you said there's no implement mation for Viper but there seems to be a maybe it's an external contributor but there seems to be a PR uh for implementing um the first four I mean apart from function sections but static that there's no implementation it just said we don't have any updates yeah um but it wasn't marked in the Readiness Matrix so we added them uh but the since the pr was last touched in 2023 we marked it as still um so I think my conclusion here

is that I would um invite everyone to review uh this Readiness Matrix and maybe push updates if you disagree with some of these P yes hi um so radic from our team uh who is not on the call uh is also working on updating solidity implementation so he took over the the the implementation that was there um last year um so I think the progress is pretty

steady but the this code has been rebased on the recent solidity um some of the test were still working uh if you used previous Eos e version e implementation inm um I think that now is see some like bigger feature that is um we work all the all the creation that we we added um so mostly implementing eof create return contract and stuff like that this seems to be a rather big feature on the solit side yeah that makes sense um because you

would need to their code makes assumptions about flat space and uh moving stuff around for the init code it make sense out that take a bit of work to do any other uh people have information on clients or compilers before we move on all right um so the next

item is to uh talk about spec updates um the first item is one of mine it's one that I realized um is coming right close to the end before we do our offsite um EIP 7069 and that was some changes I was proposing [Music] um to let's see okay this is uh poll request number 86 uh is that on here um to work with that back updates um we'll do that as the third item but the first one is um 7069 exe calls so after

we had our discussion a couple weeks ago about not wanting to um change semantics of existing op codes um unless it was absolutely necessary um I retooled it and um uh there's a new balance op code but what I think survives out of it that I think we should bring into Mega eof um is the changes to the calls um EXT call the XT delegate call and the XT static call um I don't think it's written right now to trim the calls and I think the one change we should consider is adding in that it would um revert if it has any of the High bits set until such time as we

decide what we're going to do with those um any comments on that sounds good to me yeah oh 769 oh is yeah 769 in general okay my EIP number was something different but yeah 769 as the ASC changes to it okay so I'll post a PR um to get that ready into 7069 um and post that later today um write that down on my to-do list the

next spec change is to finalize removing TX create in a nit code transaction um any comments and this also needs to be accompanied with the new EIP um what number was it 7698 796 yeah so that needs to be companied with 7968 um to replace that all 7698 is is I would say it's confirmed because we have decided already to remove the Creator

contract okay so so we do have a way in to the system so let's go ahead and um finalize that one and Define an in code mode and require Vari uh validation of contract uh EIP not EIP um epr number 86 and this is going to trickle its way down into the validation eips um Basu does have this implemented um the error code is kind of weird because the way that I um I implemented I do top down so I don't say that this is uh actually in a nit code when you're calling uh return contract on it um I will say inside the um runtime I say you have an

invalid return contract um but it can be done top down single pass just requires a little bit of a finessing and I have um when we get to testing I do have a set of tests set up that will test for some of scenarios for validation any comments before we finalize okay um go ahead this is still about removing T create an init Cod transaction or have we uh because you said 86 or 76 um both so the changes is 7069 and then 7 and then eof PR number 76 and

then epr number 86 so there's three items right so the first item we are waiting for the pr to do to the which is basically exist but needs to be split out of the other one right good and um and then the removal of T ex create and un need code transaction do we have a final call on whether we want this or not I I don't see how it's related to the to the next one so TX create and an N code

transaction they could be done independently of the the return contract validation right it's just a question of whether we're going to do the return contract validation code in um code validation or whether we're going to bring that validation code into the operation and do it at runtime right and currently we do it in the rent right that's the way megas spec was initially test specified right and this change would be to bring it into code validation time right yeah to my understanding we going

into direction to to bring all of this to to validation time but maybe Andre can confirm because he's behind the implementation of this yeah yeah we have the implementation of this already it works I think it's a bit trick it complicates our code at least and I'm looking into how to simplify it maybe a bit so I I don't have objections to this I think in general it's a good goal to have everything in okay this at this point it seems like maybe it's worth it yeah okay so Basu

and evm one have it implemented because I think there was at one point a concern the feasibility um but if we have two imples with it I think that passes the feasibility question for um for Basu our mechanism um so we don't reject unused subsections right now um but what we do do is um we track what type of calls have gone into each sub not subsection subc container um whether it's been an eof create or a return contract and we record that as we recurse into it and validate it and use that to determine um what mode to accept return contract from or not runtime

rejects it and init code rejects return and stop so that's a flag that we put in validation to also reject those and that comes top down so you can still do the validation top down and the errors are going to occur in the subc container and there's another check that you have to do to make sure that you don't eof and return contract the same subc container um you just need a track more data as they go top down so this can to be done in the same level order of complexity as we have before it's a bit trickier you got to think about it a bit more um but it really removes a lot of runtime code from stop um return and return contract and eof create and um yeah it returns it removes a lot of a

lot of those okay so there's no other comments uh let's move on to the testing updates goet sorry so I think we're we're kind of supportive of the return contract validation but what about the T create and unit code transactions removal like do we want to I guess maybe it's time to make a final call on this one yeah I think the final call is anyone think it should stay in for Mega EOS okay anyone feel it should be I

personally support taking it out and it can return but I want to hear other people's opinion I don't want to be the only one speaking on it I I guess we we know that we are losing some some features by taking it away but we also are reducing the scope all together and we moving the new transaction type is also of high value if if we want to consider y to be going into prag I guess this is a pragmatic decision yeah that's the way I I see it how much go ahead how much features do you lose because like basically you have

to do you can't have like a really generic um create thing where you can like call a contract and then that contract deploys from from transaction data yeah but that's like the only use case right and like that's like fairly straightforward to doing just two transactions correct yeah I I think this is this is the only feature that really um is at play here which we currently know about right um smart contract wallets can't create contracts without this I think is

the other side effect I think this is this is what Charles described right but that's you need to deploy a SE separate Factory contract so then the code is like onchain instead of in the transaction data which by the way if we want to discuss EIP 7702 that's like the same thing um right um and it well so so there pragmatic it reduces testing uh surface and the risk is we do use that lose that feature but I think it's important that um know Alex mentioned he wants us to consider things like copy contract and now they're

7702 so pulling it out serves a PR pragmatic scoping issue and it also preserves space to discuss Alternatives and make sure that we're not this we're not locking out of other design possibilities and what I like about taking it out is if we do all the discussions and we come back full loop and decide decide the exact design is what we had was correct we can always bring a right back as is um because it can be done as a compatible forward change so this is not an irreversible decision taking it out um there's a possibility it's just a delay until a future release um when more people are more comfortable that this is the correct decision um mostly people not on this call um so we give them the opportunity to

discuss it in a venue of their choice and there's also the possibility that alternative designs may replace this so I think that's that's why I think pulling it out is an important concession to critics of eof um because it it gives them the opportunity to let their Alternatives develop in we can decide which one is the correct one I think there was another kind of objection that was raised by Alex um which is that it's it's not like something that we can completely back out of because we're locked into the other transaction sorry the creation method like forever because the the uh TR create contract yeah we are we do need to

support that forever at least for the for the for the for forever enshrined in the in the transaction semantics when the call data starts with like EF mhm right for the forks it's active and which means for all the historical people reading the chain that is correct which like I mean I'm personally fine with but it should be yeah I don't want to like talk for Alex either all right let's let Alex talk then go ahead Alex just to add some flavor um so like I think two weeks ago um we had a a meeting with ipsilon iners meeting and you know that's when

we created the the create contract um version of the EIP and I think that version with those specific U workarounds or like semantics for the call data at least is forward compatible so at least given the current um TX create design that would be unchanged um the the code generated by the compilers will be compatible with both options and even though you know in the past I did say that I I prefer the Creator contract I still think that's a much more elegant solution compared to what we have now um but given the the sheer amount of

complexity V command here I do feel now that this version of create contract is probably a good enough concession just to get this over the finish line and still opens up the door to have something like TX create I suppose we won't really have a Creator contract um even in those designs in the future if there's a there isn't much appetite for it um but I'm not that much concerned having this Legacy uh you know create contract rule um because I do think it could be deprecated in the future even though we haven't seen transaction types being

deprecated they're kind of like self deprecated with you know new features making the newer versions much more popular um so maybe you know they it won't be used in the future um the only case where I could see that it could become enshrined if um the nonprotocol account abstraction um designs rely on it I think that's the only only risk um with making this create contract non-deprecated um maybe this was a long blur but that's all my opinions on the topic yeah thanks for that that color um

I think that really helps people out um and yeah it is a concession that says the Engineering Process we aren't being able to get our P designs in like we want to anymore and I appreciate that um from We'll add that personally from the compile perspective like the current way that's being proposed which is uh somebody else separates the container from the call data it's really nice for compilers because once you're in the compiler you have like a single code path and you don't have to do something special okay so I suppose this is a yes

and we can move on unless there's an objection that's a yes and we'll move on all right any uh last call for spec updates before we go to testing all right uh testing I see we got Dan Sarah ataz am I pronouncing that right it's emphasis on The Dan so I'm Dan from testing you can say done ceratops ceratops okay yeah dinosaur exactly yeah

the Z through me all right so um I'll do my best here it's mainly been Dimitri who's been working on eof um so basically now for when we're filling eof fixtures We Now call eof pass um automatically on the on the generated fixture so that you actually get feedback on whether your test was implemented correctly or not so this is during the fill process so when you're actually writing tests um you then get can tell if it actually is like uh you're getting the exception you expected or whether it's like a legitimate um eoff test okay it's current it's currently hardcoded to be

evm 1's eof pass um but we'd like to make this configure all via command line switch to like enable other tools as they become available um then while we're on eof pass uh Demitri brought up the point of specking out um these tools a bit more concretely um while we're still in this stage so that we could try and avoid uh you know a mismatch of options and like so we have very clearly defined input and output um so we just wondered if you'd be open to that and I'm not sure if Demitri's been in discussion maybe with Pavel about that sorry for the

vagueness okay so this is um all this was discussing the new um execution spec tests uh repository not the uh ethereum tests that's right exactly so now Mario Mario um Spencer and I we we collaborate together with Dimitri on execution spec tests exactly yeah okay we're working together on that yeah so all new tests should come into execution spec tests and we should not be creating any more retest death fillers is that correct that's correct yeah okay um I mean there may be there may be some exceptions to that but for any new stuff we're basically putting all our

focus on execution spe test now okay so I do have one open question related to just the flow and not NE necessarily eof um sure those tests still create thejason fixtures and are those fixtures going to migrate over to the ethereum test repository at some point or are clients going to need to run ethereum um run the execution spec test themselves okay so as you know execution spec test is a relatively new repository compared to ethereum tests and the way we've been operating for um for State tests and blockchain tests is that we release a tble um on on our GitHub page and then um client teams can like that's available

for client teams to to uh to their cicd so going but you know this is as I say it's relatively new and this is not fixed in like it's not stay in stone um so if you have any requests like we're open and and open to discuss it but currently that would be the plan that basically um we would release for use eof tests um on execution spec tests on GitHub and this tball would be available for integration and cicd okay so clients need to start pulling the tarball in addition to using the test repository is the goal longterm to deprecate the test repository and get

everything into that tarball oh now you're asking questions um so I think at some point with so obviously we have a huge body in history of tests and ethereum tests and um at some point we may essentially freeze that and focus essentially on filling tests from the new repository and the the path forward here is not clearly defined it's we we'd love to Port all the tests to the new form but it's it's really a huge amount of work right um so I think um as most most clients have um ethereum tests as a subm

module and then run the test directly I think that's going to stay as is for the foreseeable future um probably ethereum test will be no longer supported as in test will be not filled for Forks post vehicle um because that had some complications and yeah we're we're still we're still trying Define the path forward but I think at the moment you you have to take your test from two sources yeah okay that's way that's how it is going forward yeah because I did see that um G wrote a script that'll take the fillers and convert them to python they're kind of ugly but they're functional so they could be you know put

into a a unliked corner and still used yeah I mean that's that's um a different topic um yeah we have looked at that but it it's not it's not it it does work in some cases but it's not a solution for for porting all these tests unfortunately yeah okay so yeah I think that's a topic for another day but yeah okay um Ahmad um had a question about versioning yeah it's not related to E though it's it's about versioning um okay I I'm not sure it's it's it's

the right place to mention it but I I would love to gauge uh the room if uh because like me and Dan we were working on this proposal to actually add virging to eips and um we haven't had the chance to present it in ACD yet we did present we did present it in an AIP IP uh in a with with poja was there and the editors uh but we were not uh able to suggest it to ACD yet um but yeah I would love to hear from you guys if you think the IP versioning would make sense

to you how would the client signal it how would the test signal it um so the idea is EIP uh uh the Ed the the authors of the EIP would whenever they make a change depending on the type of change if it's breaking or non-breaking with uh add uh virgin increase uh using semantic virging Etc um and uh like how to how would uh clients and testing signal it that's that's like not in not specified in the

EIP but will be like discussed and like um like spec some somewhere right after the EIP has been enshrined but the first step would be to have an EIP vering scheme and then move to how would we signal client implementations around which version of the IP is implemented in the client which version of the IP is implemented in test etc etc um Dan here shared a very uh useful link where he explains the background behind um so this would version it before it

goes into final once it's final versions irrelevant I guess is another question um once it's final um I think uh virsion like once it's final I think the changes to an EIP become very minimal where uh only vir like changes are like U I don't know how to call it I'm not that good at English uh but like it would be like superficial nothing with the implementation itself it would be like spelling fixes grammar mistakes Etc some extra explanation maximum maximally right uh whereas um whereas before its final uh changes to the spec itself could be made and this

is already how all eips are once they become final once they land on Main net basically you can just change the spec um unless it's something like we said um a small fixing fixing a small uh spilling mistake or grammar mistake Etc right um so the idea Builds on top of that and continues on okay that makes sense of course I I would not want an answer right now but I would love for you guys to read this document from Dan and read the IP um and let us know what you think that would be really helpful all right we'll put that on our to-do list um a

lot to contemplate there but I think yeah I think I think I generally support it um some mechanism I think we just need to figure out how clients and tests can signal this so when you see a test failure um you can say oh well that's because I have the wrong version rather than I have things horribly broken um which I think would solve a lot of problems one example I'm having it's real world right now um Bas has implemented the 6110 um deposit route changes um but the tests that are being Filled from execution specs don't have those so all of the blockchain tests fail for reasons unrelated to what they're testing um because they're looking for something that doesn't exist so the real world I could totally see where this would provide value right

that that's that's the main point um and the reason I wanted to mention it in this call uh of course I respect everyone's time here and I wouldn't want to waste it uh is because of the ever evolving spec changes in eof and because of that in my personal opinion it would eof would benefit the most from um having this kind of versioning uh whether it's from testing perspective with whether it's from client uh uh um client implementation perspective uh from EIP spec uh perspective from from all perspectives I think this would be beneficial uh to eof implementers and that's why I mentioned that of course I wouldn't have uh otherwise if uh out of

respect to everyone's time right and I think it it's better than to use the versions instead of saying small big mega mega final Mega post-final I yeah we're we're kind of adopting versioning already so cool um so let's review this um one thing I do want to mention from testing I do have um let me see if I can find it um I've been submitting a lot of execution specs um to cover a lot of the areas um and you know they're not always accepted on the first review but what I do have is I've been collecting them to one big

Omnibus um at least on my mind um of all of the possible execution specs you can see all the uh the commits I've been combining onto this one Omnibus Branch Fork that I have and I've been bringing in some of the Swap and tests and others um so yeah I will post my Omnibus link here and post it on Discord um this is not final um execution spec test is the authoritative um I do write mistakes in my test code which is why I validate against e evm one a lot so it's great to have multiple clients um as far as testing coverage um are there any major gaps we

should consider filling or any issues with testing um the current code base um we need tests for the new 79 68 whatever that number is D sorry just for regards to your last Point thanks for the branch and um I have seen your PRS in the in in the repo I must admit I haven't looked at them myself yet and I just wanted to but I did notice them I just wanted to ask in general uh are you okay going forward or do you need a bit more support there or um I think I understand it um just be direct with the reviews if you

want something change just directly ask for it I'm happy to do that um I think I'm understanding enough of the Python and I get enough subtleties um that it's not too confusing to me anymore it was a bit of a a a learning curve at first um like all new libraries but it seems reasonable okay good stuff thank you perhaps we can uh have a chat offline yeah will you be will you beat the offsite next week I will be yeah yeah okay okay great see you there perfect yeah sounds good okay any other testing there's been a an idea about testing uh two weeks ago

we had um but we could take uh I don't know how to best describe it take the existing tests that don't really have anything in common with you say in execution spec test and there be able to add a flag which will Say Hey I want to test run this test also with the code wrapped in the in an e container and then so that uh we could sort of duplicate the existing non eoff tests to to run or to be executed as e test just to ensure that we have this like massive coverage of all the existing code like we and like solidify the claim that we no the parts of the evm that don't change have not changed

changed yeah this is a great idea and I know we thought about um doing it the other way around but um this is a great idea we definitely have to have a look at that perhaps Mario's already thought about it surpris me way around would would you mean um taking um eof code and then putting them in blockchain tests so taking all the the different eof vectors and then wrapping it in a blockchain test uh I was thinking this meant take all the Legacy vectors and if they drop into an eof container construct a container and test that yeah yeah yeah yeah that's what I mean what D it yeah no I yeah I understand it's an excellent idea I'm

not I'm not sure I don't think it's being worked on um and I it's the first time you hear about it maybe Mario's heard about it before I'm not sure but um we should definitely do this so one thing that crosses my mind we're going to need stack validation and um code validation to make sure that they are going to be valid and that kind of dug Tails into what eels is going to need to prove eof so this may need to be blocked until eels has a functional eof or at least half functional eof container and then we can reuse the eels code um to build the containers from random streams and if the stream is acceptable put it in eof yeah okay and yes we should add eels

to the readiness but I think I think we can do this without yields just like filling via evm one um first off and we're going to play whacka all with validation rules because we'll need stack Heights OH we need stack Heights right yeah I didn't think about stocks but definitely it should be it should be as easy as adding a decorator in Python in my opinion or something like that for mhm just just just indicate you know it's probably the majority of tests will have the eof counterparts it's just a it's just a minority of tests which will not have one like ones that test

the upod that are removed in the and such okay yeah I'm not sure minority that's like a lot of test it only works for intersection of up codes of legacy and evm right and those are what arithmetic ones the least interesting ones so calls wouldn't be translated as easily jumps wouldn't creates neither no correct correct you know just I the majority I said it because we're still keeping most of the EPM but but because test can be contaminated with non eof stuff it might actually tend to turn out to not be a majority I don't know it's hard to judge so that's

I mean at least for the the tests and execution spec tests it's a very good point about different op codes um a lot of our tests are implemented using like a sort of mini language for evm bite code so without U or or without solidity for example and um we can analyze that stuff pretty easily and check that we only include like valid like U valid B code and like we can we can check this stuff and then generate the tests accordingly anything with jumps is going to be challenging yeah yeah I mean details to be to be worked on I have not looked at the execution spec test to to see about the feasibility of this in practice I mean

it's um yeah it'll be interesting to see how useful it'll be it might be worth having a discussion first before we do it a lot of our bite code is just very simple um very minimal um perhaps we can have a look at it together okay we've only got 12 minutes left and four quick items to discuss um maybe we should have this testing discussion um on another date um there's no outstanding requests no that's it for me yeah five if we had Charles's last request um Charles asked in chat should we ban dead subcontainers um that's something we could roll in with the unit code um I think let's go

ahead and merge 86 is it is and write a new B I'm writing this down so think that important but you mentioned it earlier when you were doing the implementation that like yeah it just like kind of makes sense though and we're doing the validation for it anyway so we may as well ban truly dead data yeah um of this as well all right so I'll write a PR for that um other items review updates to the true cost of EXT call with value let me share this um Buble

here not anymore I think yeah um I know I need to rewrite the gas costing in the EXT call sections for Basu so um one thing I noticed is the 23 that comes in here um does have side effects on the 164th that gets retained um this is yeah this is a different formula oh G minus Max there's it it subtly impacts um and I think this is just a Basu issue only to be honest so I wouldn't worry about it for other clients I I think the the the 6,700 versus the 9 can you scroll down to the bottom cuz I remember oh there's

this table this this latter table it's kind of simpler and here the difference between the two stands out in the cell uh in the top left corner which is the 60 six 6700 versus 999,000 right and I think uh what I don't want to speak for him but I think this is this is the main point here um okay um as we get to implementation and gas testing I'm sure we'll see these

issues um the difference is 23 is returned versus 23 is not returned because we don't do the refund or do the retain section anyway any comments or hands on this is there any change required from this uh can you scroll up scroll back up because uh I think no so the final conclusion of B was to keep spec as is and he had the clarification to EIP which is which was merged today this one

oh okay all right cool so this is just information informational right in the agenda yeah and this will show up as we execute our tests when gather with gas differences we'll see this and see we need to rewrite it return data zero padding and three weeks ago I think there's still no consensus which way to go on this and I thought was um somebody was going to um submit an Al alternate po request with the the new OP

code instead of changing the behavior of the op code that would have been evm one if there if I think the decision was if there was going to be a change it would be a new OP code but I don't know that we're going to U it in mega because we're already high on the op code budget well we would ban the old ones or sorry right I mean person I I'm very skeptical that there is an issue go ahead Alex I think just wanted to to relate that but correct me if I'm wrong ipsilon I think our consensus was that we were

mostly leaning towards to to have the new specific op codes because that's more consistent with um you know with everything if if you make like return data copy one exception then why don't we make the others the exceptions as well yeah correct if we make the return data copy change then we were more in favor of having this as a return data copy to or whatever it's called do we want that in Mega or do we want to hold off until a future releasee to add that is the next question and do we want to change return data load oh I I would in mega we are removing the

Creator contract and all that so you know maybe we're in better spot why don't we why don't we just change the old op codes like I don't actually see a problem with it so we just discussed in testing I think is one reason not to do it we can take old tests put it in eof wrapper and expect it to behave in the same semantics so I think that's one argument for not changing old op codes is then we can't do that anymore but you can't do it with the old op codes that are deprecated anyways like call and friends are like banned so you can't just wrap any code with yeah that's good point uh

and like if you think about it from like the op code emission like now we have to like maintain two tables like one is one is a table of op codes for eof and then but they like but it's like just to do the same thing um I don't know that's just my perspective I I'm fine with it either way but it just I think it's fine to be honest we kind of have to maintain multiple tables anyway for like um different forks and what a lot of the code at least in Basu and get that I've seen is in addition to adding it to the op Code table when we do the switches we also put defensive code in there

checking for Forks in some cases say well if I'm before this Fork um treated as an invalid instruction and so it is the sort of logic that would need to support you know doing something slightly different in a new version of eof is already littered across client code already for the way that we do our um our Fork upgrades adding op I argue that it's like super way cleaner just to change op code semantics in the big breaking change because you just have a table of changed op codes and then like whenever you hit one of those you just like look it up if it's in the change table and you do the new Behavior okay um

but yeah I'm I'm fine with it either way uh if um I'm a little busy so if somebody else wants to submit the return data copy with the new OP code new allocated instruction go for it and then okay we can decide on which one okay I think we talked about tune oh in this last one increase men retain gas do we need to do this Paul's not here Alex I think p p made some analysis and

he I think this was kind of connected to the other one um probably if yeah I mean whatever update he made to the EIP um covers both of these I would say but I'm not 100% certain okay we'll keep these open unless there's changes but if there's changes we need to hear sooner rather than later I think um yes eof v0 in the last 3 minutes um

Alex um yes so this is a proposal I think we made around December the naming is kind of confusing and you can ignore it um but the the whole point is uh to improve have oracal Tree store code and hopefully by improving that it will also have a good um positive effect on UF so the way workout trees currently store code is they do code chunking uh they split the evm code um by every 31 bytes um and then the they append a prefix bite which is the first instruction offset um which is the

offset of the first non data bite in that given 31 by chunk and this is needed a trees because you may not have access to the entire code you may only have certain chunks and you still need to be able to um tell whether a given by this part of data or whether it's an actual instruction and of course the reason uh for this is uh is Jump analysis um and so far workco trees are really just concerned with Legacy bite code um as everyone is aware there's some contention between euf and workl which should go first so this is the reason we looked into this um the the goal of the proposal is to change um

basically this code chunking and remove potentially remove code chunking and instead of uh having it uh store theel jump disc list um in the work tree so this was um there were a number of I think three different options proposed back in December um but they weren't really optimal uh the overhead they had were bigger than what the code chunking overhead is which is I think 3.1 or 3.2% um and then two weeks ago um and this initial version of the proposal has been merged um in the repository and the Epsilon UF repository um let me just briefly link to

it um and then two weeks ago we came up with the brand new version of this um okay so this is the merged version and then the new version is this PR so the new version um overcame all these limitations and uh we have a encoding scheme for jump tests so we turn this around we actually don't store the valid jump test uh list rather we store the invalid jump desks only and we employ a compression compression scheme to make sure that um um the data we store is the the least

amount uh we have to store in the past week pav has worked on um analyzing the top thousand contracts according to to Dune analytics and that confirmed our hunches um so two weeks ago we only measured uh un I think one of the unop contracts in one of the arbitrum contracts and the results were really encouraging because we got like 0.1% overhead um and this hunch was kind of confirmed with the top 1,000 contracts and we have tuned um the actual incuding values based on test analysis conducted this week um and the initial feedback from the work tram was team was positive um so

tldr uh hopefully this scheme will um will be maybe there needs to be some more refinement but if it gets adopted by work and then we going to have a number of benefits so number one benefit is the Legacy code overhead will be less so instead of the 3% fixed 3% um it could be 0% if there's no invalid jump test in the code or on the average case sub 1% but for EF uh code in veral the overhead will be zero because we don't need to store this so that's the the main positive outcome for UF and the the next positive out comes for both cases

is that by removing code chunking there doesn't need to be special handling of code size in any of those um cases uh the work tree currently because of code chunking has the code size and the code hash um in a specific field the code has still is very useful because you wouldn't need to download all the the code but the code size uh was added as a necessity um and the scheme basically simplifies a lot of these operations and paves the the way for um EF um and the last comment which um it's still kind of debatable what is the the best option but this invalid jump desk table could

be stored as a prefix to the code and then we get to this ufv Z territory um but the other alternative is instead of prefixing it to the code uh we dedicate um work leaves um for this uh data and we know what is the upper bound based on the code size limit so we know how many leaves to to dedicate and Reserve um so that's the tldr um I think the outcome would be very positive for U that's good to hear and I'm interested the veral leaves has possibilities for code sections um we can store those in separate Le too yeah

exactly so I just want to to maybe do an intro and um yeah hopefully um you can spend a bit more time um all of you on the call just to get a bit more familiar with this um you know in the coming weeks cool more more homework to read um we're out of time what was it there's something oh one concern I have with verl um are we really limited to 248k of contract size is that the current setup is there a limit to the size of contracts we could potentially ever do I guess that's a veral question yeah this is they have

discussions on changing the code size limit um okay so they they're looking at 65k as the limit um I'm not sure based on on what reasoning but that that's what we're looking at yeah that's we're just changing where we're going to have the problem this is a discussion we should have with them next week um okay um there's nothing else we're over time I'd like to thank everyone for showing up and participating this is great um probably not going to have a meeting in next week um formally announce that on Monday once we figure out what our bearings are um but we'll definitely have a meeting in two weeks all right thanks everyone for

coming thank you very much thank you byebye