EOF Implementers Call #13

Transcript

Okay. Hi everyone. Welcome to the EOF implementers call number 13. It looks like we are a little bit low on people today, but let's go ahead and just get started with some client updates. Does anybody want to share what they've been up to the last couple weeks? I hi. Can you hear me? Yep. Cool. Well, from the from Nethermite side, we kind of implemented the mega efc. We only we didn't we only left off the the part where we should introduce a replacement for delegate call and the oh and the other stuff. Well, because it's

still vague. And yeah, we're still waiting for a clarification about it. And once it's done, we're going to add it. Great. Thanks for that update. Anyone else? Yeah, go ahead, Dan. So, basically, we uh implemented tracing based on the immediate arguments. Um, I think we resolved it as discussion on Discord that when you're listing immediate arguments, you list all of them, even if it is a giant jump block because it's still going to be smaller than the memory that you're listing in the trace. Um, so that um, also there is a new test case that I think we should

put out in the validation that basically was actually failing, but all the fuzzing didn't find. It has to do with a backwards step um, into a conditional jump. It's it's it's kind of weird. I I'll post it on the Discord. Um, but I think that should be added to people's standard test loops to make sure that they don't uh, get burned by this one. Um, and uh, we haven't done the calls and the creates yet, but we've implemented I think most everything else on the spec. I'll go through again. Haven't written tests for them quite yet. Um, but the tracing is correct, so they work in some cases, but we haven't proven them all out or done extensive testing otherwise. Um, but I think I'm going to be putting the eof on the shelf

for a little bit while I get things ready for Cancun. Okay, cool. Thanks for that update and we'll be on the lookout for that bug that you mentioned on Discord or something. Um, Andre, do you happen to have any updates on EVM1? Um, can anybody hear Andre? If your mic is going, we cannot hear you.

Can you hear me now? Yep, I hear you now. Uh, yeah, we don't have much because many people are on holidays, but we did implement data op codes and um, grade three is still in progress. We're doing some fixes there and adding unit tests. Uh and there was EMC release uh for Shopify and EVM1 release will be coming soon. Um but that's not directly related to your uh I think that's it.

Okay, nice. Thanks a lot. Any uh client updates I missed? Okay, cool. Uh, compiler updates. Any anyone talked to the compiler teams recently? Okay, no worries. Uh, spec updates. Any topics to discuss regarding the specification?

Yeah, I mean it's uh again there was there was a discussion in discord about the call x of code the replacements for those delegates call and started call and call And I want to know what's the idea about it. Is it going to be added or it was just uh an effemereral discussion? So when I first saw the callex option um we only had the three calls. We had we were getting rid of call code but we had um call delegate call and data call. So the idea was to take three op codes, put

them into one op code with an immediate and we put all the things into the immediate argument to say what kind of a call it is. So all calls I mean I think all clients filter all their calls op codes to the same section of code anyway. Um they just come with different flags. We move those flags into the immediate. Um so that's where it came from. But that the complexity grows when you consider things. If you if you do the pure flag approach, um you get combinations even with just those three arguments that didn't exist before. You could do a delegate static call um in case that makes a difference. Um which it probably shouldn't because um if it's a static call you can't well actually it's pure call you can't read you can't write but you might you know static

state queries might be interesting um just that a space that's not available. Uh but then when you add other things like if we want to add non-contextual like what um 4337 needs to run its gas um pricing opt through the entry points when it asks a a contract if it wants to pay for gas for this. You're not supposed to use things like you know the block height and the gas price um to figure out if it's if it's acceptable. So you're supposed to take all block context out of it. So we could add a flag for that and that provides growth for those calls like that without growing other operations. The downside is we've gone from four possible combinations of the flags to eight possible combinations of the flags. Um if we add in a no context flag, we got

three bits we got to work through. Um so instead of testing four op codes, we're now testing eight op codes. Um and it could go up if we add another flag, we got to test 16. Or we need to add in logic that says only these combinations of of flags are acceptable. All others are going to result in uh an exceptional halt when executed. Um until suddenly we decide that they are valid and they don't generate an exceptional halt. So set them on a call please. Um so so that's that's the issue there um with going with call X is it provides a potential explosion while we're saving op code space. um we're significantly increasing the testing surface or the exception surface. So that's that's my

thought. I could go either way on it. I just think the worst thing we can do is to override the F-S series calls and give them new operations with um with less arguments in case we decide we're wrong on gas observability and need to restore those. So I'm I'm you know either a new series of three call operations that take less gas or the one with the flags. Only the other problem with the flag is then we have the value variance. There are some that pass a value and some that don't. So we'd have multiple call depths. Um call takes a value argument static and delegate don't. So it it I think the com call was an interesting idea but I think the realities of the uh of all of the possible implementations make it less palatable. So I'm personally in favor of

three new op codes. Um but if there's support behind call X I'd totally be behind it. But I don't, you know, I think the the three new out codes is the most sensible path to victory. So that means you're kind of against ropex. I wouldn't say I'm against it. Or sorry, I said rop. I meant callex. Yeah, I wouldn't say I'm against it. I think the three calls is the better solution. But if you know I'm, you know, it's it's my number two option. So if people want it, I'd go for it. I wouldn't fight it at all. But I think in a vacuum, I would pick the three the three new operations option.

I hate to see anything that increases the exception surface. We're trying to reduce it, not increase Increasing the exceptions. In which case you've got parameters to call X. Um Dano just explained. Yeah. So like the call X where if we would reduce to say instead of these eight combinations you can only do these four combinations. If you pass in the four combinations do not approve. We throw an exception uh which basically turns it into an extended two byte op code anyway.

Um there's new ways to fail and really we should fail though as a validation not a runtime. Yeah that makes sense. Uh yeah I don't know. I'm not super involved in this conversation, but I do like the idea of having some more flexibility with things. Um, but yeah, the flags sound a bit a bit complicated, a bit um more than we necessarily need. I do like the idea of of having uh the ability to like not um to like have a static call but not access environmental variables. So, I think that's a pretty important thing that we should consider.

Um, yeah, I guess whether or not we do it with the call X or not, I don't really have a good I don't follow any direction because I mean with with the no context calls, you might want it static, you might want it non-static. I could see people who want, you know, no context calls um where they could still write to their state values, although you know because state would be static. So I can see there's there's some argument there. So it opens up new possibilities. That's true. If we did do if we did do call X we would have to put validation rules that say only this set of immediate arguments is acceptable but then you have the issue of the stack height changes but depending upon the number of arguments depending upon the immediate argument but then you know we're just getting into what other CPU

systems do where you you do call you just go into a different you functionally go into a different operation pane plane and um you have an entirely you know new set of 256 op codes in the call is one way to look at Right. Yeah. This this would be the only op code that takes a variable number of arguments. I think there is there's other ones. Is there jump? Yeah. Jump V. I think takes a It does. It's a jump table.

I don't mean on the stack. Oh, yeah. Oh, okay. Well again when we think about it we are not having an op code with an immediate we are having a multib code. So they are different op codes. So each one of them has a specific number of items in the stack. It just seems like it has a a variable number in the st. At least that's how I see it or how I understand.

What other multi op codes do we have? None. So, we're introducing a whole new concept just to spare some op codes. I think we'll get there. I don't think we're there yet. I guess. Well, well, either ways, I think this is just the suggestions that uh uh I forgot the name of the guy who said it. Sorry. The having two new codes seems seems logical. If we are not expecting for for like for to are not expecting expected to add extra

limitations or contexts for the op codes at least that's how I understand it. If we are going to add a lot of other contexts, probably call X makes sense. But if we are only going to have the placements for call and delegate call and static call, then having three new up codes is better. Keeping the old up codes with different different behaviors sounds like the worst option. So yeah, that's my take on it.

So, one thing that crossed my mind, um, if we do go if we do need that new context recall, um, you could still stack them and still get the same effect as the, uh, as the call with both flags flipped, you would do a static call into a redirect method that would then do a context recall. So now in your frame, you'd have both flags set that it can't do static and it can't do uh, can't access context variables. So the frame could have the flags um and you just stack your your restrictions.

Um so you could even well delegate would be the the one complication because you'd have to you can combine a delegate with a static and a delegate with a context spree which um no you just have to do the delegate last. So yeah um I think we can if those are needed spaces I think they're solutions. I'm not certain those are needed spaces yet. So yeah, I think I think everyone here is mostly agreeing with the three new up codes. What are the uh numbers? E 0 E1 E2 E uh CDE E

B's Now I need to pull up the list of updates. The eB block is empty. Um cuz I'll be honest, I could see people wanting these gas recalls in Legacy. Yeah.

Yeah. The E block looks pretty good. Although there are still quite a few in the F block is available. We could do F block as well. Is there space for three more? Yeah, it looks like F678. Let's do six, seven, eight.

Yeah, that's probably nice. Okay, let's let's tentatively say those three new op codes. Does that sound good, everyone? And then what's the order? Call, delegate, call, static call. Uh, yeah, that looks good. And then it leaves F8, F9, F. Why was F8 picked for static call?

That's a good question. [Laughter] Yeah, I was just looking at that. Um 214 because nine would be call with a with a separate with with a binary. Yeah, F9 is just so random.

F8 is so random. Let's go. 678 call delegate call stat call and we've got call two delegate call two static call two um there's also create three create four and return contract that should be close in the F range I guess too um I think we should have those in the E range because the E range or or the B range the B range seems to be composed of entirely EOF related calls Let me go back to my um switch back to um so I if if we have a a block that is for

eof only, I would want it to go if those are eof only codes. where's my branches? You have let's see B 0, B1, B2 are called, return, call F, return up, jump F. Um, what were three and four? Those I don't have on here.

B5 is dupend. B6 is swap in. 7 8 9 is data load. I'm looking on the wrong branch. I had B3 and B4 down before. Bring your ass back where there's T store or B3 and B4 T

store and T load. yeah, B3 B4 is Tar Clo Tor. Okay, so we got some non EF stuff leaking in. We can still change it. I think we should pitch it. I mean, everyone's got the T store implemented. Um, but it's once we got the reference specs, everyone will get it right. If we were to move it out of V, where would we move it?

Yeah, that's true. Cuz the fives are full, the fours are context ones, basically. Threes are full. Two is crypto, one is math, and zero is math. Then let's see, six and seven are push. Eight is dupe, nine is swap, eight is log.

Six, seven. So create three is six and seven. Those are empty. No, create three is tagged at F6 and create four is tagged at F7. Uh 89B A is call, nine is delegate call, and B is data call. So the call twos follow the original calls which is kind of cute. That is nice. Should we do that?

That sounds good to me. And it leaves FC open for I don't know what. Some future thing. Okay, let's do that. Anything else on these op codes? Okay, cool. Other spec questions, [Music]

We should probably we should probably discuss this when Epsilon comes out. But um I wonder if we should get some project plan and deadlines in mind. Not deadlines, but like shipping goals for milestones. Um, for people who weren't paying attention, this got moved out of Cancun uh last Thursday. Um, and I I would want it to be in the best place to say this is the headliner for Prague. And I think the best way to do that is to have it basically ready to go while uh um while Cancun is moving through the test net cycle. Um so we can come and say, "Hey, it's ready. It's tested. It's here." So when the discussion starts up, we can say EOF is ready to ship. Um it's

been we've we've worked with people. We we've got compilers working. We've got the test cases. Um so we can we can go and we can see who else wants to go on this tour with us. So I don't know, you know, I don't know how easy that's going to be, what the other roadblocks are, what other team's appetite for work is. Um, but that way we could do Prague as ideally a Q1 um, mainet ship in 24. Yeah, that sounds like a good idea to me. Seems pretty attainable given that we're still, I don't know, five, four, five months

out at least from 444. Probably more because we're looking at Q3 or Q4 for Cancun. like right on the edge. Maybe okay, probably more likely to push into Q4 at this rate. So, we'll we'll start the test net cycle like probably September, October. Yeah, I think that's what I'm thinking right now. definitely that gives us a summer to finalize it. Then we can start the test net cycle in January for Prague if things go well.

Okay. Yeah, that sounds good to me. Other spec things. How about testing updates? We've merged several PRs in the consensus test and those are all UF according to the server spec

uh and it's targeted at Cancun. Uh so this is still going to change at some point soon. And yeah, no tests yet for all the megaspec new stuff. Great. Anything else on testing guys? Not for my side. We still um focusing on 44. Um but I have the question regarding um this uh how do you guys see the finalized version of the spec um yeah in general is is this u is a long way to go or or how do you guys see this

getting finalist? So we need to have a spec written for the new gas recall operations. Um, what else? What were the other holes? There's a couple of other holes. Um, I think the create three and create four I need a spec written. and the data op codes. So, we got three more EIPs we need to write. Um, and I think the rest of them look like they have EIPs published for them on the mega EOF specification.

yeah, that's I think that's what we're looking at. And you know, whole the whole writing the the EIPs, we just need to get a volunteer and uh start writing it, I guess. So I'd say like it's still another couple months out from finalizing the spec all the spec things. Yeah, sorry. And it was just simple question just to get a sense of how final the tests I mean can be with the

current state of the spec. Um just to avoid many rewrites of the of from the testing part. Yeah. Unless we re unless we rewrite the container code again. Um, which I hope we don't. You're probably safe writing tests for the the ones that we have EIP for. I don't see those changing too much. Code validation, static relative jumps, um, functions, static validation, jump f instruction, and a limited swap and do.

I really don't see those changing. So those are probably good ones to start working on until we get specs nailed down for grade three four um call 2 series and data. Yeah, you probably should not write tests for those quite yet unless you enjoy rewriting tests. I mean, uh, since we mentioned change and stuff like this, I have a question since I'm new here. Uh, how do we get notified with spec changes? Is there some hook or

should just or or do we do it manually just keep refreshing GitHub or the EIP page every time? seems counterproductive to be honest. Yeah, it's uh it's probably not the best. Um I mean I think this call is probably the fastest way to know about spec changes that are the EVM channel, but it's I mean it's a little bit harder with so many EAPs. usually it's a little bit easier to follow because you have one EIP you can sort of keep an eye on it maybe whereas this you really need to have

uh you know a call or someone posting on the EVM Discord like hey these things are changing out about the spec it might be nice to have like revisions of the spec like right now we're kind of basing things off this HackMD in some ways um does HackMD allow us to see the changes that happened because sometimes I go I assume that we are up to spec and suddenly I know there something different. Yeah, it there is a way. Um I'm trying to look at right now how do you do this? I think if you click the three dots in the top right it shows

versions and GitHub sync. I think that you can like this. I'm I'm looking at a note that I own. I think you can do this on anyone's note, but it will show all the edits to the note. And so if you wanted to take a look and see like what's been modified maybe since you last look, that would probably be a good way to do it on HackMD. Okay, thanks. I guess that's it. I was I was I was hoping there would be some box somewhere that you can subscribe to VIPs, but sadly it's not here.

Thanks for your answer. Yeah, it's not the greatest, but it's all that we have. Hello, Axic. We're kind of wrapping up here. We've gone through the sections. Are there any things that you want to share? Client updates, compiler updates, spec updates? I think there's no no real update um regarding the US. We did started to at least implement M copy which is I guess not strictly related to the US but since the US will not be in

Cancun and M copy was known on the last call um we did a bit of work on implementing it and creating tests and then regarding the EU I think there's two relevant discussions to be had given uh I guess the Cancun uh approved or cified for whatever EIP. Uh the first discussion is actually the OP code numbers because now there seems to be like a quite a bit of overlap between all these proposed up codes and also like the UF codes.

Um so maybe there's there needs to be a proper discussion in allocating these numbers. Um and on the channel we did had a number of discussions maybe we we should just put all the EF related codes in the E E0F range um and that would free up you know some of the like uh 0x range and all that. And the second discussion is uh you know with the SS transaction format um and like for for transaction formats in general.

I think it would be useful to get a confirmation on at least the design direction of the UF um with the you know the the contract blobs or init mode blobs on transactions. Um, and if there's a confirmation on that, then it would be nice to get at least that field into the transaction format for, you know, SSD transactions for for transactions, whatever it's going to be. But I think it would make sense to get that into Cancun and then roll out the rest of the US afterwards.

Okay. Yeah, that's definitely something to keep in mind. Um, right now there's kind of a debate with the 444 transactions like are they actually going to be SSD or not. Um, yeah. So, we have that whole debate raging. Uh and yeah, whether it's SSD or not, you know, there there needs to be a new transaction format of 444 and you know, in order to not keep adding new transaction formats, we could just add it, right?

Yeah, let's try and figure that out and talk to the 4844 implement some. And then about the op codes, we spend some time talking about how to lay out the op We were mainly talking about the the three these three call op codes though. So, I don't know if we also wanted those in the E range or if we wanted to keep them in the what was it the F range. Yeah. So, we're thinking about putting these three uh gasless op call op codes at F.

Did we say 678? Um it was like uh 89 B. Oh, A9B because six and seven are create three and create four. So, eight would be call, nine would be delegate call, A is already static call, so B would be the new static call. And one of the rationale for that um Alex wasn't here for this was that legacy could use these gasless calls.

There's no nothing tying it to eof. It's not like it's a series of immediate args. So I do like the idea of like rehoming all the EOS stuff into the E series that takes immediate arts and you know we'd have to move like we were thinking of doing the B series but T store took a couple spots in the B. Um but if we we make you know start going backwards from F the E series gets um all the eof calls that rely require immediate arguments um I think that would be some some nice design setup. Yeah, I guess you're correct at Col because they they're actually not strict related to ES. You could just add them anyway. And

gas golf the gas golfers will love it because you go from six stack items to two or three stack items. They'll be all over it. Okay. I I know. I mean, I listened to the recording. Um but when I jumped in, there was like a argument how good the heck is to to follow changes. Uh, and I know that uh I propose that we just going to keep working the hacks until there's like a really strict need for the EIPs, but maybe this is the point um with the callup codes, maybe we should we should indeed create like an AIP for them. Um, if nobody else is volunteering, I I volunteered to do that uh this week.

Okay, cool. That would be great. And then I think the only remaining instructions which don't have any IP are the data instructions and the creation. So create three, four and return contract. Um but at least it reduces the the amount a bit. Sounds good.

Any other final comments? How is my audio working? Yeah, we can hear you. Cool. I I just had a super quick question. I'm sorry I'm late to this call. Apologies if it was already in the topic of conversation, but uh high level question. Is there a conversation amongst like uh various EVM compatible rollups around uh also adopting the EOF format or like how do those things typically work? Um, right now the conversation seems to mostly be that they don't have the bandwidth to adopt eof on their own or

to spend time organizing amongst themselves. And so they're waiting for either things to settle down in their world, which from the estimates I've heard is like on the order of like 2 or 3 years to where they can start thinking about not to being 100% EVM compatible and start to like maybe create some like standard around L2 EVM format or they we just ship it on mainet L1 and they are forced to adopt to stay quote unquote EVM equivalent. Okay. Um, does it I mean does it sound like that's the more likely option if there's not the like the ladder is the more likely option if there's not the

bandwidth in the near term to do more custom uh rollup client work around this or am I misunderstanding? I didn't quite catch that question. But like is the does it sound like the likely outcome I don't know the probabilistic outcome here is that like they get forced to adopting it to maintain EVM compatibility because like veering from EVM compatibility in the near term is less likely because it requires more bandwidth on their side or am I my is the opposite? Uh, I mean, I think that they'll adopt it if L1 adopts it because L1 is a really strong shelling point.

And if you don't have that L1 shelling point, then it becomes very difficult for all of the roll-ups to make a decision on the exact spec that they're all going to target and having the bandwidth to do that is difficult. And I think right now, like you know, you know, if you just look at optimistic rolloffs, not all of them even really support fraud proofs. So they're kind of like more focused on supporting fraud proofs before they're focused on adding more features to their EVM. But if Ethereum ships it and it's like in the clients, it's a lot less work for them. They don't need to figure out the exact spec because the core developers already did. It's already implemented.

Um it's easier for them to support. Okay, cool. Yeah, that makes sense. Appreciate the the context there. Also, since some of the L2 structures are using execution engine for some of their block production, aside from the fraud proofs, they almost get it for free. Awesome. Thank you all. Yep. Thanks for joining. Uh yeah, if there's nothing else, then we can close about 18 minutes early.

Okay, let's close. Thanks a lot, guys. Uh, talk to you again in two weeks. We'll be on the lookout for more communication on Discord in the meantime. Cheers. Thank you.