# EOF Breakout Room #5

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 43:56
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-Q-sUTwCvm6M
- YouTube: https://www.youtube.com/watch?v=Q-sUTwCvm6M

## Description

Agenda: https://github.com/ethereum/pm/issues/692

## Transcript

not sure this is okay thanks all right I forgot to start recording this at the beginning of the call um yeah if you want to oh almond yeah I have uh also one question regarding the spec that I would like to ask is that I think what we should do with the data section is not clear uh in the IPS and uh that should be also included in the specs so it is clear what you should do with the data section what do you mean do with the data section so as from my understanding the data section is sometimes used to call the Constructor of the newly created contract as a parameter to call the Constructor of the newly created contract or as my understanding incorrect uh I think it's still an open question of what how the Constructor arguments will be passed into the init code a complaint that the solidity team was having was that if they are going to generate the Constructor arguments in you know the contract of the deploys that submits the contract deployment then they would need to recalculate the data protection size of the container in evm code before the create is called and so for that reason they preferred that there was just extra data at the end of the contract for the init code so as far as we know right now you're saying data section is useless it's just to submit data to the blockchain not used in the AVM I mean in any case no it can be used with uh code data load and you can manipulate it within your evm code right I I think the original inspiration for the data section was that people were creating contracts that they were using as data and we wanted to give developers that functionality natively in a way where that data couldn't potentially be executed sorry just a question um code did you say code data load I don't know maybe I got the uh the op code name wrong but there's one where you load it from your current uh by code code code copy so but code copy does that so does that operate on the whole container or what what's the setup right now guys it operates on the entire container I think all of the Ops in that family that operate on code overall right now are you know continue to operate on the container level rather than would that localized perception wouldn't that be more useful to have op codes that operate on the data section only then we would have the New Hope codes for that yeah I think that's probably what's going to happen at some point but Vitality wanted that metallic wanted the code copies only to work on data sections to create a potential future where we translate the code in the code section but I think that that brought up too late to be integrated into this current round of spec you got it thank you can I add something to this please so I think yeah I'm kind of going around this like I think this is the core issue is that how create works so create doesn't like when you're creating a contract you don't have like call data as in like regular execution it's always empty uh and like the The Constructor the the the the the contract gets um is taken from from just yeah uh adding the data to the the actual code so it lands The Constructor arguments actually lands in data section in in eof case and yeah I think it will be simple if that's kind of separated and there's like separate stream of data for for the the call data in the create instruction but it's not the current situation and uh and because of that like traditionally you just upend this data to the like init code and and then the code running inside the init code just knows where the data is and so on but like the kind of ugly ugly aspect of that is that now the contract that creates another contract needs to kind of reprocess dlf and usually patch the the data size the data section size in the UF container so it means that it needs to manipulate the aif format somehow I think it's not super difficult but there are cases with this is like super almost impractical I think to my understanding especially when you consider the cases that sometimes solidity sometimes contracts wants to like pre-compute the return address of some like future creation and then like it's getting complicated so like like kind of ugly fix as well and that's my kind of um uh yeah scoring of this of this approach is to like allow external data or something like that in this init code situation that we kind of discussed a bit I'm sure this is great but uh maybe it's not worth the trouble and like have this Limited availability of of doing this like previous like use cases um what else I like kind of I see it like if we kind of redesign the create of it maybe that's like we can find like better solution but that's definitely not something we can hope to include right now foreign next steps are for resolving this because it seems like there's two main pause for dealing with the construction arguments and one is like as you describe manipulating the data size and adding The Constructor in the data section and the other it's I guess there's three then the other one is appending the constructed DNA code and then the last one is changing how create works and the last one's sort of out because it's too large of a change and so the question is how do we decide if we want to allow this extra data after uh you know just for the init code purpose um my understanding solidity can handle this uh this thing right now it just like this additional code that will do the patching and so on and that works I think most of the cases the things that probably don't work is to pre-computing create two addresses with some like not look starting size arguments so for example if the Constructor of the create two takes an array it's really complicated or maybe it's it's impractical to like pre-compute it but I I might be wrong about some details so I think I would just keep it as it is if we don't plan to to include new trainers or there's no time for it uh which I think that's the current status and we might lose some use cases uh so but I think that's a bit better than trying to kind of quickly patch it okay Diana um I'm afraid those use cases are gonna be pretty big and it's gonna be a pretty big limitation to require all of your init code to fit inside the container we need to find the size of the container dynamically this is I think this is an important thing we need to get fixed before we ship it um we needed I think we my opinion is we should do it we need to do to get it fixed um whether we allow create a knit code to not have a size limitation or we change the size limitations to The Container must be at least the same or larger than the data section would apply or or something we need to do something create would be another way to do it but that is that that even would even go beyond Cancun I don't think they have the time to Define that well and get people on board with it that's like a one two year out solution there but I don't think that I think we need to get it fixed so we can have arbitrary array data for a Constructor oh um yeah I think I I don't like have fact foreignty should be like better team to comment on this I think the Constructor Works what doesn't work if you want to pre-compute the address inside some other contract like but okay I think I think I agree this like this like some issues with it and we might not even know like what exactly kind of issues we will have with that and uh one more thing um which is kind of related is also the fact that we now expect um The Return of the of the init code execution to be also eof format right which means the the like returning empty empty code it's not it's not valid in this case and I think someone commented that that is kind of use case when you actually have an Indian code that inside the unit code creates another contracts and in the end it just like returns nothing and then this this contract like the main one will not be created because empty code means empty account and this account kind of successfully was created but also will not be like reflected in the state and plus this use case that we also kind of break because you need to return mtof which is this has some bytes and this bytes will be deployed although they will be pretty useless I think I've seen that used before where people just want to execute a string of evm code and I'll leave a contract to wrap a new transaction so I think it's I don't know if we need to support it through eof but if we're going to make features that are eof only then we might need to start considering how to handle an empty uh create from that we require eof or an empty code I think might be a one solution there I guess this is something that we can later allow empty code to be able to deployed this is backwards compatible with the changes that we have so I don't think it's something that we need to come to consensus on right now I I think there's enough of a consensus there's it's always good to have a null value in any system like this so you're saying that you feel we need to allow empty contracts to be deployed from Elf yeah it's something that people already do it's perfectly logical um it's just the null value for that algebra because it deploys with nodes zero right so if there's no money no storage no notes it will be a wash yeah but no no um it deploys with a with a bounce one button no notice one so it does get garbage around okay yeah so it took it I mean it's totally useless thing to deploy a contract with the Norms of one leaving it forever unable to you know handle any any inputs or yeah I thought the idea is an unwanted side effect but I thought the idea was you leave less behind in just running that evm code than if you're you know forced to to have a bit of actual contract code there and yeah I mean that's yes but you still have an imprint on state right yeah because reducing well I think the imprint on state of having Code Zero versus and quote-unquote empty eof container is negligible because we're only going to store one version of the code hash so as long as most people are deploying in the UF containers after they run their code then it's you know not really going to be any overhead right but with no Swan You're Gonna Leave something in the account tree right but that would happen already if we allowed uh people to deploy you'll have contracts with size zero so that behavior doesn't go away it's just that we're not going to be storing a whole bunch of you know 10 20 byte eof containers that do nothing we're just going to distort it once and then we'll have the code hash for them so I think it's at a scope of eof but I think we should consider a change that zero code doesn't create an account but that's out of scope of this discussion I agree with both of those yeah I think I might have like presented it wrongly uh because I think the original use case was using self-destruct in the end uh but I saw a comment that like returning cavities like equivalent but I think yeah I missed the known the nouns thing so mostly the daily people is that this init code that creates another contracts or do other stuff and in the end of that it served the tracks so then the contract is not created I see but the effects they were applied on the way uh will still hold yeah I think we should continue debating this question of if we should allow zero code contracts to be deployed offline uh I do want to try and resolve this question about what to do with Constructor values for the init code it doesn't seem like it's very good consensus I'm like currently leaning towards making no change unless we could present like a really clear example that's going to make things much harder if we have to put the Constructor in the data section we can always do a change in the future to allow extra data after the init code container like we were discussing but we can't easily in the future say that's no longer allowed so unless there is a good example right now of like this is going to not be possible by putting the Constructor in the data section I think that we should leave it as is and then decide again in the future does anybody oppose that okay uh I will document that oh Ahmed yeah just about the uh data copy uh op code uh does anyone feel strongly against adding it into 3 5 40. foreign [Music] adding a new OP code so another outcode yeah just an opcode to copy the data section to make it easier to manipulate it exists ox35 called Data load what do you mean cold cold it though he wants he wants an OP code like code copy but that operates only on the data section got it uh I in theory I'm not I'm not opposed to the idea per se but yes I I would be opposed to doing like to just throwing you new uh instructions at this point um because I think we should try to just get your finalized no yeah that's the problem how I feel right now the problem of not having adding it right now is that in the case that we want to add it later it will be a totally different POF version no it wouldn't be a new year version we can um yep it doesn't change any previous Behavior so we can just add it in in a fork true true okay the set of invalid code reduces but we don't take stuff that was an evalid set move it's the invalid set so it's a compatible change if we just add an OP code looks like yeah the only cost is that people who are deploying contracts in that time period between will have to pay to calculate what offset they're going to load start loading data from and I think that's okay would that be paired with deprecating call data load inside copying the code sections as well to go with this vision yeah code copy well not call yeah code code copy yeah sorry 39 I'm looking it's too early for me um would that be paired with with deprecating code copy inside of eof so it can't copy code code but only data section I think it could be that's something that's going to be a larger debate I think so right maybe we should put a warning like going out with self-destruct that this may not work in the future when we roll it out on day one so we don't get surprising I depend on this well the problem is is that if we're going to have people using the data section to put the Constructor their Constructors in that I think it's going to be difficult to fully deprecate code copy in EOS in which case we would need to probably do another UL section or a new another if they're making a coin and copying code that exists um we could we could make a scarier sounding warning and scale it back if we need but I think if we're gonna do the talent's vision we might might need to uh put something in there yeah yeah like I think like yeah code copy is heavy used like one is this like Constructor arguments and secondly the the immutable uh immutable variables in solidity are used this way so like every contract you should assume like every context uses this anyway right yeah so warning wouldn't like not help at all so yeah I'm like my I I know my view is like I would like to spend a bit more time on it like thinking about how the contracts are created and limit the like observability of the code which I think the current current situations kind of go a bit into the other direction so like the fact that salinity like the evm code needs to understand eof format I think that's that's a bit like yeah the opposite what I would like to see somewhere but this is like this is the different set of features so maybe for future maybe never I don't know but yeah if you'll be going for Shanghai definitely we can't touch it at all foreign but they could put their constants and everything in the data section and we just warned that code copy may not copy code from a code section or the euf header in the future yeah I guess that that could be possible yeah yeah so that's like cool like we'll end up with like this weird instruction then that kind of only like allows you to access the data but the offsets are something else but you still need to know what the offsets are right so like even though it only allows you to copy data it assumes like the cons like the the structure of the of the container doesn't change at all because you need to exactly know where the data section is right that's usually the last leaking step of a compiler once it lays everything out it can rewrite the numbers up yeah yeah but that's that's like that leaks some information about the code you're having right so I guess ideally like true VM cannot like snip anything out of that uh I'll accept data which which for for the other word is just like stream of bytes and we never assume will actually modify data because why would you but the rest at least you would yeah I guess that's like this this italic idea that you can't expect it so yeah you can modify somehow upgraded externally to something else and I think that's really interesting but we don't have a proper design for it as of now I feel like we should put this conversation on pause here now I think we're going to talk about these ideas with the italics proposal a lot on Thursday and maybe in the coming days and I do want to talk about testing and test Nets and stuff so if there aren't any other other uh stack related questions or comments then we should move on to testing okay uh uh I know that the Epsilon team has been putting a lot of work in and writing some cross-client tests in ethereum slash test to someone from the team want to get an update on what's going on there yeah I'll have several PRS open uh to one the most tradies 35 what it does I think your client teams can already tried others are not so ready I would say yeah I've run the fillers they're the fill tests for 3540 on my range of guests and I passed them except for about 14 of them and half of those were ones against Berlin so I'll look into it so it should be possible for other clients to to run those tests foreign do we have any idea when we might be able to release those well at least 35 40 does just need the review from the testing team I guess okay others I'm not sure still in progress the others being like individual Focus tests for each of the other eaps yes currently there is a PR for 36.70 for 4200 and 4752 yeah okay um one thing to note about this 35 40 tests uh 3860 limited meter reading code is not activated in that uh and yeah we will regenerate this test as soon as guess the emerges to read 60. so for now it's without 360. okay thanks for that update um other tasks Mario has written quite a few EOS tests maybe three weeks one month ago and over the past week I was trying to get them updated to the latest spec changes and things now they are syllable so I've been able to fill them with the the guest branch and um yeah we're going to try and get that merged pretty soon I don't know Mario if you have one in a comments at all and plans for those tests yeah not yet I'm I'm still going to take a look over the changes and yeah I think I will prioritize that to finish today have a have a review ready for you great so I think with respect to testing overall we really need to at least get some test Suite published and released so that all the clients can run them and we at least sort of have like a baseline of what everyone is targeting and implemented Etc so that we can try and do a past net in the next you know couple days I think we should really have something some sort of test net before all core devs because that was part of the stipulation that January plus all the clients to implemented elf and obviously you know we're still going to be working on testing and differential fuzzing and improving all these things over the next couple weeks but as a like a good faith effort I think it would be great to get a test Suite released and start a test net does that seem like something that is doable to clients all right wait before this all cardets or before the next one uh before this awkward devs so the problem with the test net could be that if we didn't run any tests we will end up with some consensus issues uh and so we will spend lots of time on the bugging the issues instead of just running tests yeah I agree that's why I'm saying that I think we need to initially have a test Suite released so that we are all on the same page at least do Cloud I mean what clients prefer to like focus on doing a test net Wednesday of next week or something rather than trying to do it before all cortos this week and just focus on it's similar to find across clientos um before all quarters might be hard because if we notice that something is failing on this test we will have no time to fix issues but next week sounds better in my opinion I think we're going to spend most of our time the next few days doing the the fuzz testing rather than the test net I think we'll get more signal out of that than a than a devnet yeah that that seems fine I I don't know Tim if you have any thoughts on this but I think if we if we do come with a test Suite before all Court doves and we have like a pretty good idea of clients you know our passing 90x percent of this test Suite then yeah I think I I would agree that's the most probably valuable signal um and then also the test net bits there might be like it might be worth discussing do we want to have just one broader test snap for client teams to join versus like an eof only one and I feel like yeah if we have that conversation on all core devs it'll inform what what we do here okay that sounds good let's let's focus on that let's focus on getting a test Suite before all core devs so we can get an idea of like where clients teams are and then you know ourselves right now we can say we're sort of planning on doing a test now next week but that's going to depend depending on the conversation that happens on Thursday at awkward dose Andrew uh yeah so um I'd like to double check that eof is based on Shanghai core right so we are not like doing some weird thing where we don't have some bits of Shanghai core but we have some bits of aof things like that because in for instance in Geth I know that um like there is one particular point I know that um if uh 3860 is not merged into gas yet and there has been recently in a changed to if 3860 so I would like to like to finalize the change to 3860 uh finalize 3860 merch ships 3860 and like enable all like all Shanghai core reaps in in Shanghai and like So to avoid situations where yeah some bits of uif are enabled some builds of Shanghai or are not enabled and so on yep I am agreement in agreement with that I mean yeah as the 3860 finalized the pr I think it's not merged yet is there any strong proponents to merging it merging it into gas or merging the change into the Eep into Eep I think everybody is on board with making that OG so I yeah I think we can just assume that that change is going to be made okay so that this this Suite that is currently the pr that Epsilon team right now had prepared does not include that change as far as I know as far as you guys know yeah the EOS tests don't have 3860 is what Andre said uh Paul um so you think it's fine I merged the train so we just like present on all core devs that the change has been made or we should wait for like for the call on Thursday yeah um I feel like we can go ahead and make the changes in clients and talk about it on all chords ups and if for some reason something comes up where people have a problem with changing it we can revert but I think optimistically accepting it has changed is probably fine I mean I mean the spec change mostly oh I see yeah I think that's fine I think that yeah in terms of client teams we can just optimistically accept the change and we'll merge it officially after awkward those okay thanks wow okay I just have a question for the Epsilon team um do you guys are getting a review on the tests PR from Dimitri or is there anything that you need from me that I can help with I mean I think he reviews it but you can also take a look of course if you want okay cool yeah I I can take a look I it's just that we have two sweets right now for for tests um so I think ideally I can take a look at uh the tests on the on the python test for review and then that is Dimitri can take a look on the tests but I will I will also take a look if I have some time uh two days left okay great uh I also put on the agenda just to mention the cof parse tool I think unfortunately Martin has had to go but Martin has been doing some fuzzling with the eof parse tool found a handful of Errors I think Danica you've also been doing some differential fuzzing I don't know if you want to make a comment on how that's been going so I think it's been going well but I think it exposes that we might want to add a new type of test to the reference tests we have the um General state test the blockchain test and the transaction test the transaction test their goal is to say is this transaction valid or not I think we use similar things to the transaction tests for eof contracts because the only question we have for you know a very large Corpus is is this accepted or not and the Alternatives make a very large Corpus of blockchain tests or a general State tests which are very heavy to calculate when the only question we want is are they getting the stack validation correct so I'm wondering if we should use our findings from submerging to create a new you know transaction test type set that is just for the eof foreign to show what I'm thinking here but I'm thinking that's the signal we're getting from eof parse is very strong and very valuable just in the validation and we could focus the General State tests on The Operators not on the container format yeah I think that makes sense to me it seems to fit pretty nicely in line with the new transaction test that Martin had worked on sometime last year and this does seem like it to me that would be a pretty good fit I don't think this is something that we're going to make happen for Shanghai I think yeah it's something that we should aspire to after Shanghai I don't know if you think differently on that it's assembling the test and getting all the clients to use the test is is the Shanghai part but I think we could get a corpus together relatively you know shortly with him before we head off to Austria I think and we could grow it as we find bugs so I think yeah I can I can get a proposal out by the end of the week yeah if you want to make a proposal I think that we can definitely get something going I don't know how like the integration will be with some of the official test repos but we can definitely do something ad hoc by Austria and then talk about it there and decide how to you know merge it officially into like the testing Suites that we have so one question about that is that what do you have in mind do you mind do you mean that just verifying the container execution no execution just to continue look at the container we would run code validation we'd run stack validation and the question is is it valid or is it invalid is the real only output and we might need to put it against different Forks if we change this we might need to put against different use cases like is it a net code we'll want a comment saying why we expect this one to fail or what's interesting about it right and this follows very closely to like how the transaction the T9 and Tool Works basically you give it the transaction by code and it outputs like was that transaction valid or not so I think that that makes sense yep that's my model yeah just a comment so we want to check in the transaction test that's the eof container standard right yeah transaction test but instead targeting eof containers not transactions okay but uh like if you have container is invalid then the transaction itself is still valid no it's not a transaction the input is going to be the raw eof data not a transaction creating an eof uh okay yeah sure it's just a simplified book into that logic that's doing the container validation okay seven minutes left of the call we're kind of coming to the end of the agenda were there any last comments on testing that people wanted to make I think this this kind of testing like this eof validation can be really simple even you can have like like one valid directory one invalid directory and just place the the byte codes there respectfully right okay um yeah that's pretty much everything that was on the agenda are there any other questions or comments people wanted to discuss regarding eof um yeah and I think it's expected uh on the all core devs from our side like in general like the the group that this involved in your life like should there be like any report or like um I think that we just need to get this get a testing Suite released and figure out what the client test pass rate is for each of them so we can basically come on and say you know this is how clients are doing with eof testing so people will sort of get an idea of what the status of that is and I'm guessing like the other main thing that people want to talk about is they'll want to talk about the college proposal so it might be good to revisit it a bit and think a little bit about the impacts great uh do we want to schedule a sixth year of breakout room or should we wait until after all core dubs I kind of feel like thank you okay make the call after on Cortez sounds good to me that's it uh for me if anyone has less final comments if not I think we can just go ahead and call it right here cool thanks a lot everybody Happy New Year uh let's just keep chatting in the evm channel about the testing things that we find and yeah let's get a test Suite release the next couple days thank you yeah thanks guys cheers thanks bye