EOF Implementers Call #22

Transcript

hey good morning everyone welcome to elf implementers call I think number 22. I missed the last call unfortunately sorry for not mentioning to anyone beforehand it's totally slipped my mind um yeah and I also made a PM issue for this call either but I think the agenda will be mostly the same so let's go ahead and get started with some client updates so anybody have some updates they would like to share um Facebook is the same spot they were two weeks ago still uh writing the test for our create three implementation uh none of it's merged yet um because the specs changed a lot before so we're keeping it on separate

um eof Branch Meg eof um I I had promised to write the EXT Co um code copy text um I didn't get to that I was distracted by uh number one back to school stuff in college and number two um another performance issue that I was working on um that consumes a lot of my time um I don't know if I can deliver that in the next two weeks because I also got to write on each Chicago um Talk for where I'm talking about eof so yeah oh nice have fun in Chicago and thanks for that update any other folks want to give an update from their client team

um I think we're still no update from our side uh focusing on other stuff honestly I don't believe we have anything new sounds good thanks for that update and yeah I guess that kind of leaves evm one you guys have anything to share we've merged one fix the four stack Overflow check in colif which was yeah a long standard PR and one from the emergency

and besides this there was um some PR's merged not quite related to Earth there was Trends in storage AP merged and in test we merge blockchain test support and also a small Improvement in ta-10 implementation to validate the deployed code which is useful for UF to make sure that there's no inverted code in pre-state and that's it great thanks for that update also

um anyone else want to mention anything for cloud updates cool any compiler updates uh no but I wanted to discuss about um the the call to spec all right great let's jump into spec questions and updates um I um kind of just posted on the ethereum Edition thread for for call to and I think in order for the the call to spec or the EIP to be completed

it should really have a return data load as well um because otherwise it leads to a code's performance regression or at least a code size regression uh when you're calculating the the output buffer so this would be a new op code um in addition to it let me um pull it up I'll make it easier

any comments about it is that for me or others I mean rather for others but uh if nobody's speaking that so mostly mean the case that you would alter in the current call you would just use output buffer and then yeah exactly I mean the the client kind of does that already it you know takes the the return data buffer and then slices

out whatever you need into the provided output buffer but in order to replicate this that semantics you would now need to kind of do that in evm code okay so previously you just use that and then output would go to memory as well and then you can use M load to to bring it to stack right that's the smallest the workflow obviously we like allocator buffer right and then do the call with the length of

the and and provide the length of the buffer to call but in in a call to land we need to do the call and then copy the men of the buffer size and return data size because returned it a copy of course has this out of bounds reversion so yeah so so interestingly I mean I was talking with ask about this and having the out of bound semantics for return data copy is kind of a good thing because then it like reduces some ABI decoding validation checks that we need to do that like the the output data

is a at least of a certain size like right now we have to check that like the output data is at least like some size um but with return data copy you just like get that for free because you get a reversion on the out of bounds but that's only like it turns out that's like only half the problem we still need to like calculate the size of the output buffer WMS but in the end you want this this data to be in a memory anyway right oh yeah

okay I'm not sure I take fully understand but I will read the the the comment you you've sent link to it so um like on the instruction side and it doesn't seem to be problematic because I think web number of instructors the other hand I think we can add this instruction separately as well um yeah so by the way adding return data load now

we do have like kind of symmetry to which kind of makes some things a little bit easier instead of having so like we would have so right now we have what M load code code [Music] yeah two two loads instructions one for memory one from call data uh there's no loads instruction from Return data right yeah and then I think UF currently is like

M load then we have M Copy coming in 15 whatever in in um Cancun mod M Copy um call data copy call data load and then eof has what data copy data load return data copy but no return data load and also the return data copy while we're on the topic like it's kind of interesting that return data copy has different out of bound semantics than everything else and I'm wondering if it makes sense to fix that or um make it more consistent in the UF

last time we talked about it with solidity they they were they were in favor of like make making it consistent uh which I guess means rather removing this requirement so behave as any other memory whatever yeah it's I think it's rather question how difficult is to roll it out uh I mean on the code size on the code on the implementation side I think it's easy

more or less uh it's it's I think for me it's rather question about additional point that confuses people or like yeah it's kind of gotcha you can expect to to step on right yeah I mean I think that call data copy and code copy from out of bounds or I guess it'll be data copy it's kind of like not generally something you want to do but actually we use call data copy for memory Zone and I think that um saluting might do it too

call data copy from past the end of call data that's a good trick yeah I get it I yeah I don't think I mean it's kind of like the symptom of something misdesigned and like a nice feature but okay yeah so maybe now that I think about it we can leave that out of bound semantics as it is it is confusing but like once you've learned it

it's you don't want to go back I mean this thing would be it would be nice to have some like I don't know like General overview uh I don't think we need to like have a specifically what exactly how evm behaves but rather what people think it's more desirable design for this uh not sure we can get it but I'm not really sure like which option is better like from evm I mean like the reason why you would this added this restriction for return data

was that we were around the times when this uh issues with not checking the input data was causing some security issuing contracts and that turned out to be problematic so there was there was ideas so we can fix it in the new stuff but yeah apparently like not everyone noticed that it actually is there so there was also I think some solidity issues at some point I might be wrong about it but I think yeah I think they somehow missed that this requirement is there and that causes some probably other issues not

sure that they're fully exploited but uh but I'm not sure how to fix it but at least if we've had some like ideal solution to this inconsistency you can at least look at it and see if we can change the Direction with the eof yeah I mean it's actually not super simple I think because like raising on an out of bounds thing kind of makes sense until you don't have until you have data that's like not 32

by the lined so I call data often just has four bytes in it so if you forced how to bounce things then all of a sudden instead of just call data load to get the first four bytes of call data now you need to start doing like call data copy and then like loading that from memory um and I think um if the ABI ever changes and contracts start returning less than 32 bytes of data

then the out of bounds semantics might actually be problematic so seems like the only possible consideration is to remove the Restriction from Return data let me think about this some more but I

think that adding return data load doesn't make does make sense at this point yeah I mean that's a bit new information I previously I thought like at least solidity was on the side that it's not needed and in just complicates some at least on the consistency level but if you say and if axic said that it's useful and like helps a bit then I think we are good as we are yeah because Viper allocates all buffers

statically um not based on return data size so in other words we do the memory allocation before the call so then fitting the return data into that buffer gets more complicated if we need to calculate the sum minimum of call of uh buffer size and return data size and other comments from others

seems like we can probably move on to the next topic unless there's anything else to say here yeah I guess like still on the spec any other spec questions or comments all right

I don't see the testing folks here so I don't know if there will be anything to update on testing I think they've been preoccupied with Duncan yeah I hear that's kind of all the rage right now yeah from from my side um the the pull request updating the tests uh to Prague yeah this PR has been has been merged already and yeah there is another PR which changes the um

details in order to Mark the non-returning functions this is also ready yeah I'm also sorry I just wanted to check was this for ethereum tests or execution spec test yes foreign tests okay thanks yeah and also I've been looking into execution inspectors in order to to see what is the Korean status there um because maybe the next eaps I think maybe we'll

be reading using execution inspectors right on thanks for that update yeah that's mostly it for the call I don't know if people have other things they want to talk about we could touch on like yeah Fork meta if you wanted to otherwise probably cut it called an end what do you mean by Fork meta just you know the usual discussion of how are we gonna put this in Prague yeah so a couple of weeks ago or a

couple meetings ago I mentioned the idea do we want to do a all core devs presentation like vertical tree did a couple weeks ago and I think we got sign up from the Epsilon team but we agreed on a date but I don't know that anything progressed on that does the date still reasonable do we want to do the discussion or not you know some some questions that might help broader acceptance of this amongst the people who don't call into this call and more comfort that this is suitable for Prague yeah I think uh I think our presentation would be good I will say the conversations that I've been a part of it seems that there's the Raging debate right now is Will vertical just be like the next big thing are we going to ship 4844 and then it's

going to be heads down on verkle for one year one and a half years or will we have a fairly quick Prague Fork um focused on like eof and these types of things and those conversations are starting to Bubble Up but I think if we present on all core devs it will accelerate it a bit and also yeah I don't know just not have eof on its back foot rather being proactive of precepting and showing that it's ready so I think right yeah sooner than later I think in September would be kind of be good so you mean two calls

I think yeah if possible the 28th and who's got the assignment for writing the slides and leading the discussion happy to do it um actually I can't do the 28th because I have a company off-site that would be kind of awkward for me to do during I'd love the excuse to duck out of the meetings but I don't think that would be good for my career or maybe it's the right thing to do I'm not sure understand understand um yeah we can figure this async if we need to I mean it's also like not the end of the world if we do it in October but I really don't know how the next few calls will unfold I know the like next call next CL call next El call it's

going to be a bit about Prague or sorry Cancun timing and I yeah I'm not really sure how that's going to shake out right now there's a bit of talk of trying to do this uh this fixed gas EIP in Cancun because of this whole press switch 1559 post so in general yeah there's uh some things to talk about fixed gas I must have missed that post um yeah he just posted this thing yesterday he made a cheeky PR to the flashbots relay basically he's pointing out that Builders kind of control what the gas limit and there's not that many of them and they're incentivized to just increase it and there's not much validators can do

to stop it so he says the relay should just take the bundle it gets from the Builder change the gas element to a million and then sent to the validator to sign so there might be uh I mean this is pretty aggressive almost an attack at least like some kind of meta attack so because some people think that gas limit floating they got rid of it as part of switching to the merge which they didn't just nobody's doing it because yeah yeah yeah I mean it is a pretty weird thing that we still have it

and you know 4844 we don't have this right it's fixed and should probably fix the other one it just hasn't been that high on the priority list but you know people are going to make PRS to relays and start proposing that they attack the network in this way then we need to respond anyway so yeah we're basically what we're saying is there's some stuff to talk about the next call or two the pro the product conversations are starting to Bubble Up externally from the call at least and I think if eof is presents an honor call sooner than later it's better okay yeah that's that's my thought too yeah I I think we we need to start preparing for that but yeah I would like

to have a light client and Nano on this as well uh so maybe let's let's decide on the date uh later maybe maybe tentatively try and Target that first meeting in October so that would be October 5th no wait October 12th is that 12th yeah 12. yeah yeah let's target that um if I say dumb things on Twitter I might be available on the 28th but that's not my plan let us know if anything changes that's happening this happens to the best of us

um one question is that will we have the spec finalized by that time well so there's there's finalizing the spec is the process and I think at that time I think I would be comfortable saying that we're closing the door to new features um so or there would be a last call for new features I think we're ready to close the door for large features you know we're talking about pushing out um jump I um not jump by uh and jump fi out to a future release um so I think I'm comfortable saying that the only doors would be open with

things that are required for functionality well this one goes out to a future release um call Fi and jump fi I think a couple weeks ago there was not sufficient um consensus to put it in the first release the preference put in a follow-on I mean maybe that's maybe that's a discussion we need to have but I think it's now is the time to start figuring out what's in what's Out close the door what's future release what's this release and I think involving ACD in the discussion because one of the big issues is size yeah there's many shades to finalize there's you know the size that comes into it but we need to you know figure out what's in and what's out because this happens all the time with hard Forks stuff you think is in

until literally two days before the first hard fork and they say no no celebrities for you so it's it's always a process but I think we're getting to the point where it's no longer additive it's only subtractive that wasn't my uh so yeah go ahead ask your question I kind of missed it no I mean that wasn't my understanding of the conclusion a couple weeks ago I think there were just not enough tips on um people on the call for like Quorum but yeah yeah so um I'm sorry I had some noise on my end

oh yeah no I was saying that I think that we should still have jump fi okay so those are those are this is the discussions is the finalized you know if it's not on the table it's not like jump F5 where we discussed it before I don't think there's room for anything new and we can divide we can have the discussion about what's in what's out and I think some of this will be informed by the alcore devs so I think probably for the next meeting we need to get a master list of what's possible and what's not um then we can have real discussions about what's needed and what's not I think that's jumpify qualify EXT data load and now the call data load or return return data load I

think those are the only bubble items um so we need to finalize whether they're in or out but I think we can probably close the door if it's not on the bubble it's not in I think it's the current state of this back who did we just lose that has to call in on their iPhone they're shy I was just afraid it's like someone loses their internet connection having to call it on their phone I've seen that happen before on these calls so I don't think it would say the phone

brand yeah it was a mistake they're calling in for the next meeting on this line I guess they're probably like oh man someone dropped a zoom link on Discord I gotta click on that okay yeah is there anything else that we wanted to chat about here um one thing one concern if we are gonna drop uh Mega oaf on the ACD you guys are are you guys concerned about like the size

of The Proposal because like there is now a lot of features inside Mega LF and if we drop all of that on ACD it is a possibility that they would think the other divs would think it's too big uh to be included in a single Fork um I'm more concerned with saying the spec is in Final I mean we can say the spec is final but we're open to reducing the scope a bit I think it would be more of a nail in the coffin if we brought it and said yeah we're still working a few things out that would that would basically be the death of it

but I think if it's big and we say hey we've like worked it all out this stuff makes sense there's some features that are nice to haves but they're not core pieces of eof and we could reduce it I think that would be the best framing Paul um yeah I I didn't want to like say in the topic I wanted something new uh which is uh the address address space extension was

mentioned recently again and I think originally I thought it's it's unrelated to to evm itself uh but I finally realized where it's actually matters so I think it's just like pieces of um instructions semantic that just truncates the values to 160 bits and yeah apparently people depend on it and also compiler kind of enforce it but that's like secondary thing and I wonder if we also want to um kind of try to track this in context of UF good call um totally forgot about that

because because vitalik mentioned it on the last awkward deaths call and we would need a dig at the talks the the discussion on it on Cuts but Pals totally write all the instructions cut and we could have eof not cut it and um whether it's it's a one-way door it either cuts it or it doesn't cut it because you really can't go back um this would allow for address space expansion inside UF this might be a hook to push eof if they you know as as could be one of the net assets to get it to to adoption it could also be a risk if a dress-based expansion never occurs and I think the biggest thing we need to specify in the absence of a specific

address-based expansion proposal is how would we deal with it does anything that has a high bit set in the first uh pass just the veil to load anything but an empty account does a revert I think that's the big question that would need to be resolved and how we would do this because no one's got a serious fixed address expansion proposed yeah I don't think we're going to keep pushing the can down the road or kicking the can down the road about address base expansion because it's a problem that needs a fix and if we don't address it now it's going to be

a bigger problem later so this is also going to be a high touch fix for maybe not high touch but a broad touch because any of the um op codes it takes an address in we would have to change our implementations to no longer trim those addresses it could be a fairly simple you know fix but there's a lot of operations that work off of addresses they kind of sneak in and you forget we actually Wonder like how many how many instructions actually operates on our dresses uh and how many we already changing can you know if it's

so we can start maybe with a list of this all instructions there is a reference test that covers this it's not off the top of my head because I crashed it later um I think it's like all the call instructions um EXT instructions and balance and anything that returns an address like but I that's a little different it's like address caller okay yeah that's kind of two groups yes um or you can I can prepare something

for next time if you want because there's a lot of them they tested in two places each one individual operation tends to have an address too big left filter and right filter filler um it's a big left to the right but there's one Master Test I can't find off the top of my head that had all of them in order um because I had experimentally turned this on and seen what broke when I when I changed it and um there was one that literally tested every operation it's a relatively recent one um from Ori who wrote it so there is a test to cover this that should help us with our scoping alrighty

is that all cool thanks a lot guys um yeah we'll see you again here in two weeks and we'll try and Target talking about eof October 12th on all cordoves have a good rest of the day a good day thank you have a good day