Welcome to ELF implementers call, I think, number 22.

Sorry for not mentioning to anyone beforehand.

Yeah, and I also haven't 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.

Does anybody have some updates they would like to share?

Basically, it was the same spot they were 2 weeks ago, still writing the test for our Create 3 implementation.

None of it's merged yet because the specs changed a lot before, so we're keeping it on a separate EOF branch, Meg EOF.

I had promised to write the ext code copy text.

I was distracted by number 1, back to school stuff in college.

And number 2, another performance issue that I was working on that consumed a lot of my time.

I don't know if I can deliver that in the next 2 weeks because I also got to write an ETH Chicago talk for where I'm talking about EOF, so yeah.

Any other folks wanna give an update from their client team?

I think we're still no update from our side focusing on other stuff.

Honestly, I don't believe we have anything new.

You're related to you, if we merged 1 fix for stack overflow check in CoF which was a long standing PR and we merged it and besides this there were some some

PRs merged, not quite related to EOF, there was trends in storage AP merged, and in testing we merged blockchain test support,

and also a small improvement in TA10 implementation to validate the deployed code which is useful for EOF to make sure that there's no invalid code in pre-state.

Anyone else want to mention anything for client updates?

No, but I wanted to discuss about the call to spec.

Let's jump into spec questions and updates.

I kind of just posted on the Ethereum additions thread for call 2.

And I think in order for the call to spec or the IP to be completed, it should really have a return data load as well because otherwise it leads to a performance regression or at least a code size regression when you're calculating the output buffer.

So this would be a new opcode in addition to it?

Rather for others, but if nobody's speaking.

So mostly in the case that you would alter In the current call, you would just use output buffer and then...

I mean, the client kind of does that already.

It takes the return data buffer and then slices out whatever you need into the provided output buffer.

But in order to replicate that semantics, you would not 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 bring it to stack, right?

You'll see, we like to allocate a buffer, right?

And then do the call with the length of the, and provide the length of the buffer to call.

But in call to land, we need to do the call and then copy the min of the buffer size and return data size because return data copy, of course, has this out of bounds reversion.

So, interestingly, I mean, I was talking with Akshika about this and having the out of bounds semantics for return data copy is kind of a good thing because that like reduces some ABI decoding validation checks that we need to do that.

Like the output data is at least of a certain size.

Like right now we have to check that, like the output data is at least like some size.

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 to be in this.

But in the end, you want this data to be in memory anyway, right?

I'm not sure I fully understand, but I will read the comment you've sent, link to it.

So, like on the instruction side, It doesn't seem to be problematic to think.

With number of instructions, on the other hand, I think we can add this instruction separately as well.

Yeah, so by the way, adding return data load, now we would have like kind of symmetry too, which kind of makes some things a little bit easier instead of having, so like we would have, so right Now we have what?

MLOAD, code copy, call data copy, call data load, return data copy.

There's no loads instruction from return data.

And then I think EOF currently is like M load.

Then we have M copy coming in 15, whatever, in Cancun.

M load, M copy, 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, it's kind of interesting that return data copy has different out-of-bounds semantics than everything else.

fix that or make it more consistent in the ORF?

Last time we talked about it with Solidity, they were in favor of like making it consistent, which I guess means rather removing this requirement.

Yeah, it's, I think it's rather question how difficult is to roll it out.

I mean, on the code size, on the code, on the implementation side, I think it's easy, more or less.

I think for me, it's rather a question about additional points that confuses people or like, Yeah, it's kind of gotcha you can expect 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 is kind of like not generally something you want to do, but actually we use call data copy for memory 0.

And I think that, solution might do it too.

Call data copy from past the end of call data.

I don't think, I mean, it's kind of like the symptom of something misdesigned and like a nice feature, but okay.

So maybe now that I think about it, we can leave the out of bounds semantics as

It is confusing, But like once you've learned it, you don't want to go back.

I mean, I think it would be nice to have some like, I don't know, like general overview.

I don't think we need to have specifically what exactly how EVM behaves, but rather what people think it's more desirable design for this.

Not sure we can get it, but I'm not really sure which option is better.

From EVM, I mean, the reason why we added this restriction for return data was that we were around the times when this issues with not checking the input data was causing some security issue in contracts.

And Yeah, so that turned out to be problematic So there was those 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 I'm not sure how to fix it.

But at least if we had some like ideal solution to this inconsistency, we can at least look at it and see if we can change 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 byte aligned.

So I call data often just has 4 bytes in it.

So if you forced an out of bounds thing, then all of a sudden, instead of just call data load to get the first 4 bytes of call data, now you need to start doing like call data copy and then like loading that from memory.

And I think 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.

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 just complicates some, at least on the consistency level.

But if you say, and if Aksic said that it's useful and like helps a bit, then I think we are good as we are.

Yeah, because Vypr allocates all buffers statically, 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 this minimum of call, of buffer size and return data size.

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?

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 my side, the pull request updating the tests to Prague And yeah, this PR has been merged already.

And yeah, there is another PR which changes the test in order to mark the non-returning functions.

I just wanted to check, was this for Ethereum tests or execution spec tests?

Yeah, and also I've been looking into execution inspectors in order to see what is the current status there because maybe the next EIPs, I think maybe we'll be reading using execution inspectors.

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, call it an end.

Just you know, the usual discussion of how are we going to 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 Berkle tree did a couple of weeks ago?

And I think we got signup from the Ipsilon team, but we agreed on a date, but I don't know that anything progressed on that.

You know, 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 a 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 Verkle just be like the next big thing?

Are we going to ship 4844 and then it's gonna be heads down on Verkle for 1 year, 1 and a half years?

Or will we have a fairly quick prog fork focused on like EOF and these types of things.

And those conversations are starting to bubble up.

And 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 presenting it and showing that it's ready.

So I think, yeah, sooner than later, I think in September would be kind of be good.

And who's got the assignment for writing the slides and leading the discussion?

Actually, I can't do the 20th because I have a company offsite.

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.

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 next call, next CL call, next EL call, it's gonna be a bit about Prague, or sorry, Cancun timing.

And I'm not really sure how that's gonna shake out.

Right now there's a bit of talk of trying to do this fixed gas EIP in Cancun because of this whole press switch 1559 post.

So in general, yeah, there's some things to talk about.

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 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 to a million and then send it to the validator to sign.

So there might be a, I mean, this is pretty aggressive, almost an attack, at least like some kind of meta attack.

So it's some people think that gas limit floating, they got rid of it as part of switching to the merge, which they didn't.

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 we should probably fix the other 1.

It just hasn't been that high on the priority list.

But you know, if people are gonna make PRs to relays and start proposing that they attack the network in this way, then we need to respond.

Anyway, so yeah, basically what we're saying is there's some stuff to talk about the next call or 2, but the Prague conversations are starting to bubble up externally from the call at least.

And I think if EOF is presented on a call sooner than later, it's better.

I think we need to start preparing for that, But yeah, I would like to have light client and dano on this as well.

Maybe tentatively try and target that first meeting in October.

If I say dumb things on Twitter, I might be available on the 28th, but that's not my plan.

1 question is that will we have the spec finalized by that time?

Well, so there's finalizing the spec is a process.

And I think at that time, I think I would be comfortable saying that we're closing the door to new features.

Or there would be a last call for new features.

I think we're ready to close the door for large features.

We're talking about pushing out Jump I, not Jump I, call FI and jump FI out to a future release.

So I think I'm comfortable saying that the only doors will be open with things that are required for functionality.

this when it goes out to a future release?

Call FI and Jump FI, I think a couple weeks ago, there was not sufficient consensus to put it in the first release.

I mean, 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 1 of the big issues is size.

Yeah, there's many shades of finalizers, 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 fork stuff you think is in Until literally 2 days before the first hard fork and they say nope no subroutines 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.

No, I mean, that wasn't my understanding of the conclusion a couple weeks ago.

I think there were just not enough people on the call for like quorum.

See all Ethereum transcripts on Youtube

EOF Implementers Call 22