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

Hey, everybody, welcome to the 24th EOF implementers call.

This I think is the last EOF call before the Alcourt.

So I'm sure there's a lot of things to talk about with respect to that.

In the meantime, maybe we just go through some updates from client teams really quickly and then move into that discussion.

So does anybody have an update they want to share from the last few weeks?

Guido's been working on a new fuzzing framework.

So I think there's going to be a lot of great fuzzing support for whatever we propose, because EF's paying for some really good stuff on it.

Do you have been to have the link to the interface he was proposing?

He's writing custom stuff into each client and running it that way.

He contacts you if he already has get working.

Basically the question is, do you have efficient APIs to get it just the EVM and not the entire data stack, so.

Anyone else, updates from the last couple of weeks on implementation?

Yeah, in the VM1, we've implemented grade 4.

So it doesn't depend on anywhere on for it for 4 anymore.

And It's a new kind of transactions that just based on 1559 transactions.

And so this soon is a bit more testing, but I think we'll be ready soon.

We've also merged the EC recovery implementation using either max primitives, which was a proof of concept work to, to see how either max primitives work in practice, which we did during its proclivity.

And I think that's mostly it regarding you have, we've also support will also support running blockchain tests.

Charles, do you have anything you wanna share from the Viper side updates from the last couple of weeks?

Cool, let's move on to spec updates and questions.

I was looking at the note that Andre put together.

And there's a couple of different variations of it.

Kind of, you want to think about, cause the most general 1 is like, requires kind of 4 medians actually, cause you're like swapping anywhere in the stack, any 2 items in the stack, but usually you don't really want to do that.

So I think that you can get better code size compression with a couple of different variants of swap.

Because there's 1024 addressable items in the stack.

But we limit the swap to 256 or 128, I think, max?

I think that, so like if you allow 1 byte immediate, that already allows you to address 16 items for 256 total combinations, which is like 1 nibble per item.

And then I think the most, I think actually like a lot of the swap operation, a lot of the swap and dupe operations can actually be dropped.

I think if you look at EVM code, most swap and dupe operations are like through 6 maybe.

So like you can drop dupe 7 and swap 7 up And then you can add like swap nm with, and then you can maybe add swap 2 3 as a specific instruction I think would be good.

And then swap, Sorry, these are just kind of off the top of my head, actually.

Swap 2, 3, and then the swap with 1 immediate byte, and then 1 with 2 immediate bytes, and I think that covers most cases.

I'm trying to think of swap 2m is useful.

Yeah, you could get rid of swap 2, 3 and give swap 2m instead.

But the easiest thing to do is just have swap nm with like 2 variants.

I've got a custom build of BASU that tracks live opcode usage, and there are some higher order swaps that are used by current contracts.

So I know that's all the way over to 16ers that are actually executed.

I know that they're used, but I think the frequency is, there's a code versus usage, versus opcode slot usage trade off, right?

Yeah, I mean, we're talking like, you know, 10, a hundred times less than some of them, but like Right now I'm looking at billions of operations and there's like 10 million calls to some of these high ones.

I mean, swap 16 is, you know, sub-million, but you get to swap, you know, 10 and 11 and they're still up in the tens of millions.

I mean, that's like 1% of all swaps, right?

Right, and that's, considering there's like almost 100 operations, that's not too bad.

I mean, they can be replaced with swap with 1 byte immediate.

Like, I think another way to think about it, Dano, is like, what if you were designing this from scratch, how

That's I think where the friction in my mind is coming is if we design it from scratch, we're going to get more resistance.

We've already tried that before and we got pushback.

So while you are right, if we design it from scratch, there's lots of great things we could do.

There is gonna be less likelihood we'll ship it.

The more this differs from legacy EOF, the more testing surface we create, and the more testing surface we create, people are gonna be less and less comfortable with these changes.

Okay, in that case, I think the minimal use of swap nm is like a single 1, which takes 1 byte immediate.

And you can address the top 16 items in the stack.

And if you wanted to add 1 more opcode, it would be swap nm with 2 by 2 immediate bytes.

What if we just had swap mn with 2 immediate bytes, and didn't have the 1 byte variant?

I think that the 1 byte variant is actually more useful than the 2 byte variant.

The way we keep swap in that has full depth as well, not full depth, 256 depth.

I think it's better to drop that 1 and add the 2 by immediate variant instead.

I mean, you had the dupin and swapin as the EIP forever.

Opens up acceptance of the changes we're doing.

So, I mean, that is the risk if we go too far from that old EIP?

You know, we got a certain credibility that says, hey, people have been asking us for literally years.

I think it's actually on this call, maybe he can chip in with his opinion on that.

If you and Asik go in with a combined front on this, I think that would help.

If you both agreed on that, we could dispense with the year ago.

It's like, well, we didn't even think of this years ago.

So I think that would be a good argument if you get, you know, say we want this instead of that.

I mean, I'm not in Ipsilon, so I can't even change any EIPs if I want.

Now, again, you can certainly push a PR to the EIP repo for review.

But specifically regarding swap-in, swap-in versus swap-mn.

I think The, yeah, I hear Dano's argument, but I think I would extend it that, I think at the time, you know, for many of those years, we didn't really have feedback from Vypr, what would be the preference from Vypr's perspective.

From Solidity's perspective, just a swap in was good enough.

They don't actually see, like, too big of a reason to have MN, but it doesn't, I mean, apart from using 1 more immediate, it doesn't seem to have a downside to solidity.

But regarding all these like other exotic variations of swaps and Removing some of them, I think that probably is something we don't want to attempt at this stage.

As Dano said, people are really afraid to take any changes, and the more we propose, the less likely it is.

But removing the highly specific ones, I guess, kind of goes against the codensity argument, right?

Because you already have these specific ones.

And if you remove them, then you're going to replace it with a larger instruction in terms of bytes.

And just 1 more note regarding all of this is we had some earlier discussions, had to handle opcode allocation in the sense that would we rename an opcode or change semantics, or would we rather retire the opcode and introduce a new 1?

And I think for most of these cases in EOF, we have chosen to do the second route, which means we disable opcodes and we introduce new ones to avoid confusion.

But I guess, even in this case, once EOF would go live, in the future after that, we could start reusing those old disabled opcodes if it would run out of space.

But I guess the current idea is that we don't try to repurpose opcodes.

And so just removing these old swaps seems to be not very useful.

And leaving the old opcodes, 1 of the advantages of retiring opcodes is if we get an assumption wrong, like cast observability is actually important, we could unretire the opcodes with a minimum of fuss.

So that's 1 argument for not reusing old opcodes.

I think that the specialized variants are probably actually more useful than like swap16, but I think it's not worth, like I said, important 1 is swap NM at all.

I think you mentioned actually 2 different pieces.

1 is, Yfer would definitely prefer the MN to have the ability to swap any 2 locations.

But the second you mentioned is you actually go above the 256 limit.

How strong are you feeling with the second case?

The, yeah, what, what is the, the usual stack layout and Viper?

You want to access the entire stack, not just the top 256 items.

And at some point we reduced it to the top 256 items to have a single byte immediate.

So I'm just wondering what is the stack layout of Vypr which would necessitate having access to the entire stack?

That's the 4 byte immediate 1 And I don't think that's super useful.

Like in any case, at some point you need to start spelling into memory and having more addressable stack just kind of pushes that out further the limit at which you need to do that but in terms of stack scheduling being able to swap arbitrary that being able to generally swap 2 items in the stack is useful.

But how deep does life typically need to go?

I think we're moving more things into the stack.

So I think, you know, within 128 items would be good.

But like I said, it's actually kind of not the issue is like how much stack needs to be addressed.

So I think that being able to address 256 items is plenty.

And barring that, I think that being able to address 16 items is actually quite good already.

Because most of the time that you're doing stack scheduling, you're doing things that are kind of local, things that are near, kind of near the top of the stack.

Yeah, I think generally our assumption was that maybe that's the reason why initially there was little feedback from Vypr.

The assumption was that Vypr is more memory heavy and uses the stack less and maybe it didn't occur to us.

But, you know, at this school, I guess we're, I'm just conscious of time.

Maybe we should move some of the swap discussion to the end, But probably we should also like discuss this more async just to understand the requirements better.

I personally don't really have any any strong opinion whether it's swap n or mn.

What I care about is that it becomes useful.

Yeah, My feedback is that the most useful thing, and I think Soliloquy may or may not find this out eventually, is that swap nm is the most useful thing to have just because of how stack scheduling works.

Like when you start to write a stack scheduling algorithm, it becomes very useful to be able to swap 2 things that are not at the top of the stack.

Andre, do you want to talk about the updated list of questions that you have, or is there something else you wanna talk about first?

Yeah, we can, I can, maybe let me share my screen?

Second 1 is deployed on validation of the subcontainers.

And in general, I like the idea if we can elegantly achieve this.

Like, originally we started with this before we realized data load-in problem.

And we were validating subcontainers recursively in the container during normal validation.

And so ideas there so far, Charles suggestion to drop data load then completely then we don't have a problem.

And we just validate that all argument at runtime.

And another idea that we had is somehow, or also Charles also mentioned this, somehow to provide the final deploy size to, to in the container, I guess, at, at, at factory deployment time, I guess.

So that we don't, we can't still validate it all then without having full data section.

So it can be either we somehow add full subcontainer expected size in the header maybe or data section expected size.

But yeah, no concrete proposals about this yet.

Has there been any thought of the security implications of recursive validation?

I think it should be fine because we just, we still validate every byte.

It's still linear time I think because it's still bound by full container size.

It will just call the validation recursively, but in the end, the size of the code being validated is bound by the outermost container.

And when you're deploying an inner container, would you then validate it again?

I think it's enough to validate that the size of the aux data is the same as expected or as declared?

Just my concern is that we're going to hit some performance issues and not just on exponential versus linear time.

But I think even linear time may be too expensive even though we're doing a 1 per byte, we're raising the constant of how much time we need to consider for each byte, potentially.

And yeah, there is a cap, but I mean, actually we're considering each byte multiple times because we have to step through it for each outer container and then come back and check it again.

I think there's an argument to just also dropping data load and like if we're looking for things to prune.

I mean, I just because it's kind of, it was already kind of causing this issue with recursive validation.

And so, And I'm not sure that it's that useful or merits that.

Right, we can totally work around it with a push-in data load.

It's just code size expansion, but I don't know that that's worth the issue with the other complications it causes.

So we already have container size encoded into the header for each subcontainer.

So I think we implicitly get the subcontainer size and we could presume that extensions were fine, but dropping data load in solves the whole problem right there.

We could presume that all data load ends are valid on subcontainer loads, but that's an extra validation node.

By the way, what is the behavior of data load on out-of-bounds data?

I think we opted for exceptional halt, similar to return data copy.

If you meant call data, then call data stays the same.

Because if data load just returned zeros, then I wouldn't have to validate data load n.

But return data copy ready respects the boundaries of exceptional faults.

Right, but Code copy right now does return the zeros.

So I'm just saying that if data load and return zeros, then it wouldn't need to.

Is return data copy, exceptional halting considered a plus or minus in the solidity and the smart contract community?

We discussed a couple weeks ago, or maybe 4 weeks ago now, that it's a good thing because it helps with ABI validation.

It's irregular and yeah, that's why you also have to take care of written data size and all that.

I mean, yeah, I originally thought it was a negative, but then after thinking about the alternative is actually good because you're always validating externally data that some other contract is giving back to you.

So you need to validate it anyways that it's within bounds.

But data is always something that you have control over.

Like right now, I think Solidity and Vypr both use call data loading zeros past the end as like a zeroing trick.

So, it's actually not a bad thing always to return zeros.

But if you still have it from call data copy, then you still have access to the zeroing trick.

I'm just saying that 1 kind is not necessarily better than the other.

And if data load N loads zeros, then first of all, you don't have to validate it.

And second of all, you get actually a very cheap way of loading a 0, loading 0 data, which is cheaper than the call data thing, the call data copy thing, and same with data copy.

And another thing is that the relative cost of code copy versus call data copy might change.

So I don't know which direction they would change, but it might be beneficial in the future to be able to choose between the 2.

Or we could just like add an M0 opcode and then we wouldn't have to think about it.

I think we actually did discuss M0 somewhere at some point.

I think generally it's nice to have tricks, but I think with these tricks we get just too entangled in the tricks, which then in the end puts us in a position where it's hard to change or even change any kind of instructions or just exactly what came up here.

Do you want to have tricks on an instruction or do we want the instruction to be more like pure?

So following that logic, maybe M0 would be the right approach.

You can't actually do it for call data size because like normally you're loading the first 4 bytes of call data.

Like the first thing every single contract does is like call data load 0 and then figure what to do with that.

You can also do call data copy with 4 bytes but that's more expensive.

So with the deploy size of the subcontainer, what are the main questions and the insights?

mean, would we error out if the auxiliary data plus the actual data doesn't end up matching the expected deploy size?

See all Ethereum transcripts on Youtube

EOF Implementers Call 24