L2 EVM Common Core: A Path Beyond EVM Equivalence

Hey, everyone. Yeah, I'm here to talk about the L2 EVM Common Core. It's basically this initiative, that's a recent initiative that came out of the roll call process. If you've never heard of the roll call process, that's something we started earlier in the year. It's basically a L2 coordination effort.

We have a monthly call where many of the major L2s on Ethereum send representatives, and it's basically for now mostly used as both coordination across them, also trying to be a bit of a connective tissue to the L1. I'm personally spending most of my time in L1 core development. And then we also have what we call RIPs, roll-up improvement proposals. And the idea there is basically that they are similar to EIPs. EIPs, you might be familiar that they are proposals to add new features to the EVM on L1.

And so the IPs are the equivalent for the L2 side of things. And yeah, the process was originally kind of started, the roll call by Karl, who can't be here today, unfortunately, Joaf and me. And then more recently, Nico also started joining us more actively. And yeah, I want to basically talk a little bit about EVM equivalence in general and then kind of the specific kind of direction that we see the EVM equivalence go in the future. And I wanted to start a little bit with history.

It's going to be a bit more of like an easy kind of beginner-friendly talk, at least in the beginning. I like pictures, so I have some pictures. In principle, the way I always think about scalability for blockchains is basically as this fundamental trade-off between the cost to run a full node and the throughput you get, right? And so Bitcoin, Ethereum, two early examples. Ethereum has more throughput than Bitcoin, but it's also a bit harder to run an Ethereum full node than it is to run a Bitcoin full node, right?

And I call these kind of trustless chains because the important thing is everyone on earth who wants to can verify the chain. At least that is the goal. And we are sticking pretty close to that. And then there is the approach of just going further up the diagonal and just picking Solana as an example here of chains that basically just say we want higher throughput, and how do we get there? Well, we basically go up and we accept that now it is harder to run a full node, but we get more throughput.

And of course, the trade-off is that now you actually need to have a quite beefy machine to be able to still trustlessly participate, otherwise you have to trust the majority of nodes. Now, ideally, we want to go there, right? The ideal chains, they have very low cost to run full node. Everyone can verify, but they have high throughput. So how do we do this?

We basically, this is the key roll-up trick, right? We realize that actually what matters is the cost to verify the chain. And if there's a way to verify the chain cheaper than running a full node, that's sufficient. And that's basically how we get to rollups. Because rollups are basically a way to compress verification of a chain.

And so what you can do now is once you get to that place, you can do either, you know, basically the thing you could immediately think of is just, hey, take the high performance chain and just run it as a roll-up. There are some projects now on Ethereum that do this, that are Solana VM-based. It's a bit of a challenge, though, to adapt them for L2s. Then, of course, what you can do is, as well, you can just take the EVM and you can really scale it to a high throughput. People sometimes have this mistaken conception that the EVM is fundamentally not able to go to similar throughput levels as the SVM that's really not the case the reason why Ethereum runs on lower throughput is specifically because we want the straight off we want to be verifiable by everyone on earth in a trustless way right it's a choice it's not a technical constraint so once you go into the roll-up you can actually push the EVM to its limits but the variant of this that we've seen the most is actually what I would call, I don't know, the multi-rollup cluster, which is just many smaller, lower throughput individual rollups that basically together form a very high throughput system.

So that's kind of like the background of how the ecosystem evolved as Ethereum went through its roadmap. And if you zoom into the chain itself and then eventually the EVM, I have some more pictures. I call basically this, this is just like the execution chain. It's just a symbol that's representing chains where actual activity happens, right? Like chains that actually offer execution, where you can build apps on top.

And the most basic version of a chain is just like a self-contained chain. It's like an L1 with just normal apps on top. But now you want to turn it into a rollup. How do you turn it into a rollup? You need settlement and data availability.

And those two things can be provided in a combined way by a settlement chain. So then once you have a settlement chain you can take your chain there and just turn it into a roll up and the nice thing there is that now you inherit the security of the settlement chain but you can still now yourself run with much higher throughput, right? But because you have that security that you inherit from that low throughput but high security chain. That's kind of like how with much higher throughput, right? But because you have that security that you inherit from that low throughput but high security chain.

That's kind of like how this kind of this best of both worlds solution works. And that's kind of how you get to this world, right? Where you have a settlement chain and you have a bunch of rollups on top. Now this was basically the original vision for what people back then called ETH2. You might remember before the merge, people used to call kind of like the beacon chain ETH2.

And we moved away from the name, and that has a specific reason. Why? Because ETH2 was this vision that we would basically give this new chain some fancy new execution and settlement system, and you would take the old ETH1 chain and the old EVM on top, and you would retire it. Back in the day, there were a bunch of different thought experiments. You could turn it basically into some sort of roll-up on top of the new ETH2 chain.

You could just have it parked somewhere on the side with some, you know, either like proof of work forever with some bridges to the new system, or just even over time, deprecated or something. But then at some point, basically, as we moved closer to the merge and to these ideas, people realized that, hey, actually, the ETH1 chain is kind of good enough for what we need for the settlement chain. And so that's why then instead the plan became, let's merge the existing system into this new ETH2 chain. And that's why we kind of stopped calling it ETH1 and ETH2 and instead just call it Ethereum again. And so that's why today what we have on Ethereum is this hybrid settlement and execution chain.

So down there, that's what Ethereum is supposed to be. That's both the settlement thing, settlement and data availability, but we also still have execution. You can have your UA on L1, you can use Uniswap on L1, all of that still works on L1. And it's all still powered by the original EVM that we used to have on Ethereum from the early days. Right.

So that's basically like how the role of the EVM evolved and basically how for a long time the EVM was supposed to have an expiry date and then it turns out it actually didn't. Now how do L2s and their execution systems fit into this? Well, actually when we first pivoted from sharding to rollups, the idea was, well, this is going to be amazing because now all the L2s can go on this wild exploration and see what type of new fancy execution system works for them, works best for them. But then it turns out we have seen a little bit of that, and I said that earlier, we now see experimentation with the SVM and move VM and like more fancy throughput EVMs and whatnot. That happens a little bit, but the vast majority of L2s actually basically followed the network effects and they were like well there's already a lot of dApp developers for the existing EVM today so what we are going to do is we're going to just copy the EVM right we're going to copy the EVM and we're specifically not going to make changes to it because otherwise apps would not be compatible and it doesn't mean that the L2s were not innovative I would say quite the opposite I think we've had we've like three, four years of pretty rapid innovation in this space, but that was very much focused on the specific new challenges for us.

So that was focused on new functionality and fault-proof, ZK-proof. Of course, in the ZK space, the innovation has been amazing to see. And then when it touched the EVM, it was more like extension. So I'm not sure how many of you are familiar with Arbitrum Stylus. That's an example of an extension to the EVM that left the core of the EVM unchanged and just added something on top.

And then one more wrinkle to this, the consequence of the EVM equivalence was also that most L2s ended up just going with the dominant L1 EVM client, which at the time was Gath. Of course, Gath is still