EOF Implementers Call #61

Transcript

good morning and welcome to UF implementers call number 61 on 30th of October um tends looks to be a little lighter I think there's a conflicting pile going on right now because daylight savings time is really messing with everyone right now um America will be back with the rest of the world next week so hopefully it won't be a problem next week going forward um today's agenda uh huh that's last poli's call no that's Old Post of it there we go so we have testing update client update compiler update spec update and others if you have anything else um that's not on the agenda please post it in the meeting

chat um one thing before we get to the end um before we go through it should we cancel the 13th call that is the week of Devcon cancel it and just pick up after Devcon um that would be two weeks after Devcon like we are not disturbing schedule okay perfect right okay so there's any objections to that let me know but I'll come back through the end of the meeting um that we'll skip the meeting on the 13th um so let's start with testing update um Mario you got anything just thumb up um not not really that much import ah sorry thumbs up for was for the consell of the call um but

from testing I've been reviewing PRS for the execution specs I'm a little bit behind still because I was out uh uh one week but I'm getting back to it and I will probably pick it up today also to to review and merch what it's possible to do okay y um as far as trying to get Osaka devet zero out the door the uh creation of prog devet 4 I think it slowed everyone down um I've got as I mentioned on the chat I've got everyone's local stuff running against e tests um in Osaka um the question is um how many are based against what's going into Prague 3

and Prague devet 4 [Music] um let's see uh I guess we'll do that in client updates but that's the issue there is to make sure that we're going against the correct Prague backing for oaka um yeah yeah for from what I can tell evm 1 is not is not uh in De 4 state yet but um I think I if I remember correctly I filled with Bess and I'm not but but still I'm not sure I need to double check if that's deid 4 uh up to date because de 4 is pretty new so I I'm I'm I'm sure there going to be some

discrepancies um yeah there were there were three last I checked I don't know if they've done um the 77 42 changes I think those are mostly orthagonal I mean it's going to be critical for like a a live network but I think most of them are orthagonal to anything that the evm can see yeah definitely except well if you do get more than six blobs um and you transition to seventh blob there might be a test we might want to see if seven blobs can get there but that's yeah we'll figure that out um so I guess we should move on on to client updates uh Ben anything from nethermind uh no all good as far asere

other than the um tracing okay the pricing uh tracing uh changes tracing okay um so your features evm eof is backed off of the current frog another minded shipping uh it's not it's not in prog oh sorry yes it's rebased on it okay so it's off of Main uh great um dragon how about re and revm um there's one bug found by by you basically for external delegate call

when it's pointing to the pre compile we would call Pre compile and that shouldn't happen other than that uh I think red added Osaka heart F so we should be ready to go okay I think like two or three clients got hit by the EXT delegate call on a pre-compile so yeah that was really great find yeah um someone from I think it was was it Powell that wrote that bill up or did was that a port over from Powell um I did the one that no that mine was related to to data

load uh okay if I recall correctly I mean at least this this was the the test you pointed to so it was just loading unaligned data from data storage uh like some pieces are from data stories some were outside but maybe I I misunderstood okay yeah I think it was code copy but there's also another one where you do es delegate called any of the pre- compiles and um they're all supposed to fail because none of them are eof that that change went in a few weeks ago that test okay um so nothing is that so that's it for

ref y okay um Powell how about evm one um so we we are the in the facee of transitioning to Osaka I mean to moving UF to Osaka um I think the the change itself is not complicated um but this affects a lot of testing around it and uh yeah so this is the issue that Mario mentioned um I think we can get it we need to update some tooling as well to to be able to handle some Json that is related to prag and maybe Osaka

as well so that's what's like uh it's ongoing work and we still don't have all the pr APS in so I think when we test eof in isolation that's kind of okay but as soon as we get to testing some interaction with other eaps I think we might be at trouble um so yeah I think it would be good that other client can also fill the tests if that's needed and um finally going back to test a bit um I I migrated all of the execution tests

from the old repo to execution SP I think there's one more request that is in the review but it should be the last one and so we can consider that there is no more any execution tests in in AUM test repo that are targeting EOS actually there's actually no more execution tests that targets PR and anything above so I think that's kind of an milestone in terms of clarity what the tests are there are still a plenty of uh validation tests why they behave a bit statically so I think they're easy to

easier to manage if we need to okay and just for the notes that was all of ethereum tests that was migrated over or all all execution tests which are State tests that's something that the actual execute code not only validate that's what I mean by execution test yeah but state test is probably better term Ben you raise your hand uh yeah I'm testing out a question related to the Readiness Matrix I'm not sure entirely what half of it is okay I'm worried Miss missing

something so we we have the um uh yeah the where down um the bottom half the exported ones yeah so um let's see if you see opening test yeah if you can download these and put them in um your basically your test director you need you need to extend your ethereum tests again to accept a new source yeah so so so the the archive that is

called av1 SL no dash tests I think the last one from the release it's it's just a package Json test that we generate from evm one uh that are like originally internal test of evm one but we we have kind of tool that can just export them to J so that's what is it uh if you never actually use that I mean they should be similar to execution spec test archive but uh there might be some differences in terms of directory structure I don't remember exactly and there also might be some

like false positives because not everything works very precisely but um if you want to test use this as a like confirmation that corrects um in this Matrix there are different versions so just use the last one and you can skip like the previous versions uh they're still in the matx because some some clients reported that they pass these so we keep it there but I think it's enough to just use the version 03 and yeah and if you have some um like failures but

they' they look suspicious to you you can just report what's what's wrong yeah no one's updated the Matrix on this I've run locally I've run Basu evm one death nethermind and revm off of raw e EST and right now they're all running clean so I don't expect any surprises here I haven't run Aragon or ethereum JS locally or eels I don't have scripts set up to run those easily um yeah okay

um I'll take the field for Basu um and we are um we have Osaka in place um and we're based off of whatever main is so wherever Basu is on the Prague 34 process um it's there and this is off the main line okay any other I don't see any other

clients on the call compiler team okay any other updates on clients and testing that we should over go over before we go to the next section okay so I probably should have put return codes in the same category as hash Cod XT Dev call um because we went through that pry well in the last meeting um and possibly uh the EF create hashing do we have any updates on that from evm one

from not evm one from isilon I just a tiny bit I I think the main issue with this idea is that um yeah yeah you can you can create another init init code context out of previous init code context in other words during init code execution you can invoke can another create right so it creates this nested nested init code context and I

think in this in this scenario it's pretty unclear what is the address of the code so we want to put the address of the code where the container is in this function that computes the the final address of the created account and it works for like the basic you have create but if you n these uh it's get it's getting messy because originally I thought I would put I don't know actually so the number of options what exactly put there but none of them

seems good this is if it's test it but or this can be the address of the of this init code like the the upper init code context because this this contract will be created finally and the code will be deployed but the deployed code will have sub some some subcontainers possibly and there will be different subcontainers

that you actually refer referred to when you computed the address so that's kind of like fake fake derivation that you computed something that points you to some subc container but it's actually not the subc container that was used it's something that will deployed later and finally if you consider create transaction uh so this this one this the hcky one that that we introduced as the way to deploy contract so when you start executing this transaction you you immediately create this init code context and if you if you have EF create in this

context it would point you to the I don't know to the center of the transaction but it has no code so this address has no code but you're you're the like the the nested create address will be somehow related to this something fakey code that never existed and it seems to me it's kind of pretty difficult to Define what to do with this field in this function I guess yeah you can you can put a flag maybe you should put a like you can in this context you maybe you want to Omit your address or like put n

address like all F address with number of options and uh I don't see this this super I guess it's not always possible to to point you to the to the physical address where the where someone can look it up the subc container so maybe it's to actually indicate that by omitting the code address somehow and so that's that's more less the status when I when I stopped so I think we need to handle this case somehow and yeah I I considered number of options but uh nothing is really

settled so there something from omitting the address in some way uh maybe actually hashing the sub container in this context when we cannot actually prove where it come from but this means the cost of computing the address will be different into two these two scenarios and that seems also not great uh so I don't know but I think that's the main issue with this with this idea that in this in this context we need to behave differently that we would do for like

Reg I've create that are coming from deployed contracts okay um Rio you have your hand raised yeah I just wanted to make sure I understand the the issue is a with regard to nested creates um right is that is it that if you use the address of the code and the index of the subc container that could refer either to the code uh once deployed or the init code is that the ambiguity well an eof could also an eof

could have nested eof could have an nested eof they could use chain creates like you create a um you deploy Unis Swap and you also deploy the the factory for the swap contracts so the eof could have an create could have an e create within it but that would change the address of the code in the nested levels wouldn't it um the physical address would be where the contract is at where the the root mode validated if if if we do anything other than the topmost code we're going to have to Hash the inner codes I think is the concern and we're trying to get away

from that uh sorry you have what the inner what so we trying to get some unique information about the address of the parents so the the root most container would have an address that we could use and if we use the root most address and some path to the subcontainers then we don't have to Hash the subcontainers because you have some some predictable address to create from it however um if we don't use the root most container um the concern is we would have to hatch each subc container uh to get a verifiable derivation of the address yeah there's a lot that that I'm not

understanding there um yeah so I'm gonna ask a yeah sorry are you gonna be at Devcon is there something which you do like a a corner on for eof issues or yeah that would be great I'll be there okay um um and regarding the the avoiding hashes which I understand is a mainly about ZK uh rollups wanting to avoid cck is it um is there an assumption that that you need to Hash the in container on every eof create or um what if it's cached like the when the root most container is deployed you

can cash the hashes of all of the subcontainers doesn't that you know reduce the the overhead by just doing it it could and that's yeah that's an implementation detail the ZK systems could bring their hashes in we still have to Hash it when the op code is called when they bring in their salts but we would want something that is um ready just to add the salts yeah so they'd have the preim is ready to go you add the salt and then you run the hash one last time and that's assuming the ZK systems don't just rip out KCK and use some different uh some different um hatching algorithm but everything is the same except for the hashing

algorithm okay because I I tried to make the argument in the in the issue that I see some value in keeping the current scheme um but I yeah if it's a matter of cost I I I understand that yeah I mean like my my main motivation was that it's somehow kind of awkward that you has in Need You has the subc container to get the address but the subc container can cannot ever change so you're kind of repeating hashing of like static data and every time you use that so this seems like something is

kind of misaligned in the design here that we yeah we hashing something that we know that there will be produced the same hash every time but this actually like not obvious Place how to work around it like where to where to store the hash of it I mean I think it would be different if we kind of address subcontainers by hashes right that would be kind of more natural way that you address it and then then but that's also like has some issues and so that's yeah that's what where it comes from in my mind but I I don't think it's like super super required but I think we wanted to explore this if you can make something

that replaces haset but it's also like difficult to describe all these like edge cases that we we are finding in this if you can write down the edge case um I don't know if it's the same one it's the same one that is written yeah I think it is but I think we can simplify and I I found a bit more new something new as well so yeah I will reite that and then well I will like notify you that I think it it it requires a bit different description that is more

readable because I think these were were my just like quick notes for myself and maybe there's a way to improve that description in a way that it's more clear what's going on yeah cuz I'd like to think about it I feel like it can be solved I mean and the only thing we need is just unambiguity right well in the lack of clashes I mean in the yes but I also thought that some way a proof that the address will come exactly from this code is something useful as well maybe it's the same the same property but yeah even so one of the

issues we have currently is that you can kind of fake with this nested creates so you can refer to the index of the subc container and later there will be index there will be subc container with this index at the given address but it will be actually different subc container because it was deployed later and this yeah so I think this is something we also want to avoid so you cannot fake it because that seems like a like new security area that you need to think when you create a contract that can can any any like external actor can actually like yeah maybe that's more for

the Collision so the Collision definitely want to avoid so nobody can claim the address by tricking your contract to do something that will actually deploy something different and then you will not be able to deploy what you plan to do right that's obviously something we want to avoid uh but maybe that's not very important right now but I remember that this like create two scheme was kind of created with this in mind that you can yeah you can pre yeah you can predict what the address will be and you can also put some guarantees how the address like what code would be used to to create it it's it's not like

perfect because you can work around some some some things there but at least that was something that I kind of keep in mind maybe it's not relevant anymore poly morphic addresses and contracts were kind of the pain in the neck when it came to analysis so the the value of making sure that the actual code bytes go into forming the addresses I see is very valuable so and I I view that as a subversion of create to and tent when they're able to do polymorphic code so um uh as a side note what had also come up in the issue was regarding

including or not the uh the call data is what's the prevailing opinion including call data in the hash yeah I don't remember right now I say called call data or init data I mean the the yeah the init data that goes to the create instruction yeah the input yeah input I mean I don't I don't think it it should be included or weekly i weekly feel that way but it seems like some of you were considering that I think with did

briefly and I can tell if if that's good or not I mean I know what what this can be used for right it's it's to also prove that you will use like specific Arguments for this creation right so that's yeah but it but that's easily defeated yeah defeated by in yeah out of the class yeah it doesn't doesn't like seal all the all the possibilities but maybe it's actually useful um for someone who actually has something so yeah it doesn't give give you like full guarantees but you

can by inspecting the code and and combining this I think you can improve situation but I maybe it's not written but what I what I found is that users can do that by hasing the init code and combining this with the Sal so you can kind of create a scheme that you will be able to prove the init arguments as well you just need to kind of code it yourself right so you can yeah before invoking UF code you can has

what you will pass to it and then combine it like a or I don't know what is the best combination of hes maybe it's just a Sal so there's a way to do that and you can always you can't really yeah but you can't really hash subc container because it's not readable so yeah I I I was thinking a bit about it but I definitely don't have like very very lot of experience with actually yeah working with smart contracts and level so definitely we welcome some feedback on this yeah my intuition is that what we have now is satisfies own requirements maybe it

needs just a little bit more work than car evm Legacy evm but it's sufficient to prove the inputs okay all right um put a time box on this um so we not at a resolution um so let's go ahead and move on to the next thing on the um potential change list is modifying Max stack ma Max stack Heights um I think the idea here was to change Max stack height in a call F jump F

section to not include the number of input just be the additional stack required Beyond inputs am I reading that right yes yes because um what what the r time actually needs is is subtraction of these two values so it actually needs Max height as defined today minus the number of inputs to check if the callink facture will cause a stack Overflow right so so what the run time does it actually reads these two values and subtracts them and then proceeds so like to to optimize the

runtime a bit and also um yeah you can you can just Define this like what is exactly the numbers in the header on in this type section in a way that that you just need to read one value of instead of two that's the main thing but it also I think it also removes some redundancy in the in the actual bits in the in the type header because if you think about it the max height cannot be lower than number of inputs right so you kind of keep these

two values in two two different places I mean the the number of inputs it's from like I don't know if that's proper thing but from like information Theory just put these values in actually two slots because Max height can never can cannot ever go below this value so yeah so like if you consider what the ranges are of the possible values in the header it's also like kind of redundancy so you can argue that's that's like better encoding as well and that's it from a fuzzing perspective that means those two values aren't related they can change independently which is I guess proves the information

Theory Point yeah yeah yeah I bet yes as well so but I wouldn't put it so so like yeah so it's kind of minor thing but I think it's like the change is relatively simple I'm not sure about yeah how much testing effort that needs to like like yeah change this in the test that that might be difficult if you have some like static test or like example test you will need to go in every such place and like change these numbers I think every place we specify Max Z height we would have to change it break half the

test but it might be worth the effort you know I think it's wor if you have time I I would do it if if we if we would ship like EF like next month that it's fine not to do it but if we have find like time load that we can improve that I think it's worth to do it it's minor Improvement but yeah it's kind of quality of life think will we rename the field I think the the the the the issue I remember someone proposed a name for

it some Max increas yeah something so there was there was the name for it yeah I think at the time we liked it because if we change the name it makes it easier to go to the code and update it Mario yeah so when you when you say that it's going to take a lot of rewrite in the testing do you mean in the unit tests of the clients or do you mean in East um both okay because I think in East there are a lot of instances where we automatically calculate this value so in those cases I think it's going to be

pretty easy just to take the input just substract and then just uh go ahead and and and change it um I don't know how is is going to be in the in the unit test for the client yeah it's just a afternoon running chests until they stop breaking I've done it before yeah it's not like the end of the world I think it's just it's it's like slightly painful piece of this work that you need to yeah but it's like kind of mechanical but it's not like you can you can always find some issues even like today I think not today but like in the recent weeks we

Hugo came and like found some issues in one examples that were kind of had incorrect incorrect like binary representation and yeah it's sometimes it remains unnoticed until you actually look at it for example because you either don't don't execute this or like the error is somewhere else and then like before you reach this point and then it's kind of another error later always something like that happens but uh I think we've been through this already so we more or less know how much work it is but if we had to like Q3 this is

worth doing yeah how how I was thinking about it is that at least for for my side the like like first step is to get UF in Osaka and update test and update tooling and make sure like everything works according to the current spec so okay yeah and then we can I would pack all of these proposed changes into like single shipment so right let's say like defet

zero is without it defet one is with yeah the buet of changes and and then we ship at once because they are minor changes I think okay um all right and I think the next one Falls in this bucket align e creates stack align with ar basically reordering stack arguments yes the same story I think that's even easier because probably not so many test it's not like every test has has this instruction right so it's I think it's easier to update in

the clients as well sounds like it's just swap two lines for even one for example yeah well each client is different because like um I know guests got littered all over their code assumptions about certain stack Heights when it comes to their calls and their creates um so if we could align those it would be great for them um as far as the depth but as far as EXT call versus call we're already breaking some of those stack hiide variations um so we'll see um but as far as tooling to have them you know just to look at the docs and have them in the same order would be huge in

call any other comments on it I I would say Beyond tooling it's also useful for um developers who are maybe manually debugging you know to just reuse their existing knowledge and not having to like swap the elements in their in their mind also this was brought up by someone on if mug a bit different context but the just that the order of the arguments is weird is the

same okay I think the last change is even easier than all of these rename return contract return code okay any other so I think that was the

last of the quality of life list that quick one posted yeah um so you mentioned exd code at the very beginning I don't want to bring it up just to mention that I I created an issue in this re in the eof repo I just invite people to read it for when we uh discuss this and the other one was exd Data copy um I imagine this is also for later but I just want to get a feel for what the appetite is for for that one yeah those have been mentioned

before and I think those were mostly cut due to complex arguments so adding it is is I think open discussion um yeah I'll mention in in the one one of the strongest arguments is why can't we just use sor2 so that's going to be where the a lot of the arguments can to come from but I think that's already mentioned in the uh bug report if not I'll add it so my my imagin solution for this x data was that you can write a contract that just Returns the data and I I planned yeah but I forgot I plan to actually

write it and see how many instruction it is uh so I I'll definitely try to do this as an example how you can get more or less the same behavior but maybe yeah that's not enough I don't know so the thought that crossed my mind the other night is what if we using Nick's Gadget created a standard set of all the op codes of contracts that just do the op code and return they pull the values off of the args they do the op code and they return and we just figure out you know a standard set of addresses to put them at using using Nick's um public signature

Gadget so I don't know so yeah um um the only differen is which kind of starts to bother me is that the data will come to different memory it will be in the return return data buffer not the memory so if you need it in memory later you will need to copy it so it's another copy um yeah kind of feeling that's return data as a separate memory is kind of the bad idea but so I'm not sure I understand why is sore 2 seen as an alternative because it me in my mind uh

so the point of EXT data copy would be I I I have an address for a contract and I know that it has a certain piece of data that I want um and so I want to use this to fetch it so where does sor2 fit one of the things sor2 fits in um right now without EXT data nobody can copy the data of a contract without the contract allowing it to be read and that even goes for legacy code too so if a contract from its internal data wants returns data it has to opt in and create an interface to send it so by not having EXT data copy we allow contracts to have a privacy

provision now easily defeatable you go outside the evm go to your block Explorer read the in there you can get it but within the evm you can't go into other contracts so there is a bit of a a data privacy argument and encapsulation argument there and contracts that want to allow people to access their data can use the S SS store 2 interfaces to allow that to allow their contract to be done so the choice about ownership of data now belongs to the contract but again that's modulo leaving the evm um using a block Explorer reading the data and coming back to it um which is also presuming that these blockchains are fully public and fully fully uh um auditable on the outside um ethereum's

not ethereum mainnet is not going to be a situation where we're never going to make the blockchain fully public um so that's you know that's not something that we're too concerned about for main net use you know keeping the full privacy but that that is one feature that I see right now that not having it keeps so so SS store to it it's we just talking about like the interface so it's like the read function right oh okay cuz for me as a store 2 is more about uh even writing too it's just kind of a pattern to use Legacy contracts as data contracts um but anyway the point is can

we um yeah so okay now the question for me would be um is that equivalent probably yeah I me so yeah it it's not equivalent because when we require them to to opt into sharing their data um then there's no equivalent to you know it's the default secret and there's you know it's not even there's there's not even opt-in secrecy uh when we have EXT data copy but secrecy is probably a bad word because again you use the box score and just read it

publicly yeah sorry I meant is it equivalently good for the use cases that I've seen that's what I wanted to think about something to think ahe about this is the behavior when X data copy is the target is leg contract or a 7702 uh account and also will it be allowed in Legacy contracts just so I guess a proposition would need to come with those questions answered know the fault's necessarily a good

solution because that's yeah and also do we have X load for good measure do we have EXT code load right now though we don't it all goes to memory right EXT code load no okay that would be one argument for not having it's already expensive why make it cheaper

okay anything else we should put on the wish list to think about over Devcon well the one the other one that's been on my mind is the delegate call um to Legacy thing I've kind of already made so it's kind of tied to the EXT code discussion right I think if we get EXT code hash so that a contract can uh uh predict whether uh the delegate call Will Fail um that's pretty good that said to me would still be just a little

bit more ideal to get delegate call like unrestricted delegate call I understand the problem of self-destruct and I I agree the one the thing that I wonder is would would it what about something where if you trigger self-destruct in the context of an eof contract it doesn't do anything or rather it behaves like um the nerfed uh self-destruct that we have in with those exceptions um I don't know if you've already considered this um I understand that it adds some complexities like a different kind of static call context that the clients

would need to handle so it's not ideal but it would be something that I you know might be interesting to consider okay but I think the first one were safety detecting a legacy is kind of a needed feature I mean we we usually when they discuss it we buil down to saying that this is rather easily um workable by uh having because the problems with the Legacy with the update of the proxy Target to Legacy right that it would be solvable on the smart contract layer that the proxy before you

know it would R if it it could detect that it's not able to delegate called the new Target and revert in that uh if detected so there this fuse mechanism so this I mean this is different from the EXT EXT code side and uh yeah EXT code size case that this actually is workaround theable right right so you're saying that there is a way to detect the future the potential for failure uh without the need for ex EXT code right yes I mean it would be just like a

trial delegate call to the new to the new Target yeah that's right that that that seems to generally so I mean the issue is like I mean it is there but it it is of I say it's less severe because it can be worked around on the on the different layer yes okay okay okay okay um so we got about three minutes left

um I'm going to once I get uh the they're they say they're gonna have discussion Corners so I think we should probably try and set up a time um to do a discussion I'll coordinate on the Discord at least to get people together um and have a general open Community you know time gather just for eof without an agenda just um to talk about EOS so I'll try and get that corner set up at some point when I see the schedules um if anyone has any strong opinions as to what day and time it should be uh please post those in the Discord or send them to me um yeah so I'll it's getting time to do coordination for Devcon so maybe the next meeting's going to be a Devcon meet up so that's probably what we should aim for

cool um like to thank everyone for calling in um any last comments before we close all right um hope everyone has safe travels to Devcon