Changes to the L1 EVM versus L2s

All right. Can you guys hear me well? Perfect. Thank you so much for the introduction. And thanks for joining us today.

If you're watching the live stream, thanks for tuning in. So this will be essentially the last one of today's EVM-related sessions that were kind of structured like an EVM mini-summit here at DEF CON. Last year we had a full day of EVM summit during DEF CON Act, and a lot of aspects of today's topics were actually covered there, but we will see what's new and highlight some of the takeaways from last year's panels as well. So thank you for the panelists as well for joining us today. And I would like to first ask you to briefly introduce yourselves and your involvement with the topic and EVM.

Let's start with Alex. Yeah, it works. Okay, yeah. My name is Alex. I'm part of the Ypsilon team, which you may have heard here a couple of times today.

We do research focusing around the EVM and we also did research on WebAssembly. And obviously, because we focus on trying to improve the EVM, one of those big proposals is EOF. The other one is EVMX. I'm definitely very bullish on getting those out. And we have been working a lot on mainnet, so obviously I'm in favor of getting these improvements to L1s as well, not just L2s.

All right. My name is Daniel. I've been in the Solidity team since 2018, have been the lead of Solidity for, I don't even know how long, a few years now, I think. And yeah, so we are the ones that actually need to generate code for the EVM. So yeah, we also would be highly appreciative to have EUF everywhere, and including L1s, because, yeah, we will get into that.

But, yeah, we're in the Ethereum Foundation right now. We're spinning out of that in the Argo Collective. If anybody is interested in that, there was a recording of a talk the other day. But, yeah, that's it. Hey, guys, I'm Matt.

I go by like clients on the internet usually i work on the go ethereum team and i've been working on some of these evm ideas for a while worked with alex quite a bit on phase two for eth2 back in the day thinking about what new execution environments in ethereum could look like and also have just spent a lot of time since this concept of the rollup-centric roadmap was released thinking about what the interplay between L1 and L2 rollups would look like. Hey, my name is Mark, and I am a contributor to the Optimism Collective. We maintain the OP stack, which powers a bunch of different, you know, altitude networks. Our goal is to commoditize stage two roll-ups so that anybody can, you know, use our free software to deploy a stage two roll-up really easily. I've written a bunch of Solidity and I've worked a lot on upgrading smart contracts that are running in production that hold lots of money, have hit lots of different edge cases with doing upgrades.

And I worked on EIP-1153 a little bit, was able to upstream that into Geth, so have some experience working with the EVM, and yeah, I'm interested in just scaling Ethereum generally. Awesome. Thank you so much. So I will address most of the questions to one of you, but if anyone has any additional thoughts, feel free to just jump in after. So, right, so the EVM has been targeted for improvements pretty much since the early years of Ethereum, and there are several related elements in the roadmap as well.

But there were always some other priorities in previous hard works, so there hasn't been too many significant changes happened around the EVM so far. But there are a lot of progress was made when it comes to R&D. If you listen to Dano's talk on Tuesday, or even today, he gave a really good summary on that. He ended a bunch of new directions, and it's definitely gaining more attention recently. So, Alex, you've been involved with EVM R&D for a very long time.

What do you consider some major milestones when it comes to EVM improvement? Also, how do you see the future, the current roadmap elements? How do they build up on each other? Or how do they interact with other roadmap elements? And maybe also just touch a little bit on the ZK aspect, like how could these changes make the EVM a little bit more ZK friendly?

How much time do we have for this question? Well, I'll try to give a very brief summary. Yeah, I think some of these questions were addressed in like previous talks, especially the ZK element. I mean, as you said, EVM has been, has seen like different stages of development and sometimes it had more focus, other times less focus. I think generally, maybe the first year after Ethereum launched, there were more quicker changes like reverts were added.

There was like, you know, quite an important improvement and maybe shifts were added sometime later. But most of the development on EVM has been more reactive regarding state. So most changes were gas-related. How do we deal with the state? How do we improve costs around the state?

Or fixing something like the Shanghai attacks. Or making changes around the beacon chain integration, like the Shanghai attacks or making changes around like the beacon chain integration like the merge and focus was less so on improving the EVM itself there have been things I'm initial L2's some were more explorative people were always really curious at improving the EVM but there was one direction where people spend most time on is a pre-compiles they wanted these big features which you couldn't achieve in the EVM and so they opted for like maybe an easier way. It turned out to be not an easier way. In some sense it is, other sense it isn't. Some of these pre-compiles have a lot of complexity.

They seem simple. Turn out they have consensus bugs every year. Some of them have taken more than four years to get adoption. Like the BLS precompilates still being discussed. And so with all these in mind, we have been, in Epsilon, we took like a detour to see like wasm, would that be an option?

We came back to EVM that EVM is actually not that bad, but it does need a lot of help to make it better. And, you know, right now we have a lot of help to make it better. And right now we have a lot of adoption around EVM. So that's the reason we really want to improve the EVM. And to touch on the roadmap, as I mentioned, the EUF and EVM-X, I think is a good direction to go.

EUF gives you a baseline to build up on, but it also introduces you know a lot of like improvements if you look at some benchmarks there are some benchmarks regarding code size and gas usage there are improvements to be seen there and there have been some other benchmarks regarding zk just to touch on it quickly one issue in in zk VMs is they may need to translate the code. And if you translate the code, you need to keep access to the code. You cannot only use the new translated version. With EOF, you remove code inspection, code introspection, so this problem goes away. Another big issue is the gas cost.

The gas costs are really tuned to like regular computers and some of these things the EVM has they would translate really differently in terms of computational cost on ZK. Removing gas introspection in the EOF also removes this problem. So we've seen some good benchmarks that a ZK application of EOF reduces proof sizes, reduces proof generation time as well. So all of this seems to be positive, but yeah, of course, still a lot to be done going forward. I'm not sure if anybody has, I said a lot.

I'm not sure if you have any response to these. I mean, we definitely introduced bugs in our bridge because of gas introspection. So I'm a big fan of a lot of the simplifications that are coming with eof l2s also desperately need some sort of multi-dimensional 1559 so simplifying call i really like that um yeah i think the one major problem that we have is how do we upgrade our existing deployments to EOF. Thanks so much. Dania, what changes do you want to see happen on layer one EVM before potentially ossifying it?

How could this potentially interact with the vision you have for Solidity? I know there will be a talk on Solidity later, so hopefully no spoilers here. And also, maybe how could these changes impact others in the ecosystem positively? OK, I mean, I would say don't ossify the layer 1 in general. But yeah, if people want to ossify the layer 1 ABM, then yeah, I could enumerate a number of things that are wrong with it that make life harder for any compiler and developer and any tooling person.

EUF solves a lot of the issues. block that would in bulk reduce the complexity of compilers, reduce the complexity of tooling and formal verification on top of it. I mean, you also touched on quite a few points already. If L1 is to be ossified, please at least give us EOF in it first. Beyond EOF, there are still a number of things that would be nice.

I mean, we could have better memory pricing, memory pages even, maybe give us some registers or something like that. But yeah, at some point, okay, I would understand if you don't, but EOF at least, please. But yeah, I mean, effects on other people. I mean, I'm pretty sure that a few people have picked up on, for example, the Solar initiative of providing a new compiler to Solidity in Rust. They want to target EUF because they know that it actually is much simpler to build a compiler in a language in EUF.

So, I mean, that goes for every language. That goes for every language, every tooling will be much easier to implement for EUF because it's much easier to generate code for it. But you mean they would like to only target EUF if they can? I mean, we only briefly talked with Georges yesterday. I'm not entirely sure what their plans are.

And they only so far have a power source. I'm not sure. But yeah, he sounded like very bullish on having EUF and targeting EUF. but I can't speak for them further than that. And mainline solidity?

When do you drop legacy support? I mean, we would love to as soon as possible. It's a mess to generate code for the EVM, so I mean we do have for quite a while, I mean, I've spent quite some effort on the Shanghai version of EUF. We wanted it then. I mean, we have a delayed roadmap already because it didn't get in then.

We now are in the process of finalizing production support for the new EOF, but there has been prototypes for ages that were usable. Thanks to Radek also. Shout out to him. But, yeah, I mean, it would actually help us extremely in our roadmap for the backend side of the language to have UF. And as soon as UF was there, we would expect users to move to it immediately because of the advantages in gas cost and everything, and would like to drop legacy support as soon as possible, or at least.

So you would ask L2s to adopt it quickly, too? As soon as possible. I mean, yeah. We, of course, would need to have a transition period. I know that it would probably take a while for that time.

We would have to, but as soon as ever possible. All right, cool. How fast is soon? I mean, luckily, you know, due to the design decisions that we made with the OP stack architecture, it's just easy to rebase onto, you know, the latest geth release or the latest reth release and get all of the, you know, functionality into the L2 itself. Now, when it comes to the smart contracts for the OP stack on L1, that's going to be difficult to migrate to EOF.

I would definitely love to, but, you know, there's backwards compatibility concerns because applications may have hard-coded the address of the bridge today, and we would need to deploy a new bridge and, you know, figure out a migration pattern. And realistically, there's just other things that we consider higher priority than, you know, migrating to EOF for our L1 contracts. This is the specification you mentioned regarding the bridges, which I think we just need to understand a bit more. Maybe we don't have an answer for. But I'm curious about a different question.

The many users of the OP stack now, multiple chains, they diverge from the OP stack? Do they have some of their own changes or it's like vanilla OP stack always? Oh, that's a great question. So there's, it's free software. People are allowed to do whatever they want with it.

But there's this idea of just using the vanilla OP stack. And with that, you kind of inherit all the tooling that everyone in the community is building. So my personal philosophy is that you don't really need to make changes to the EVM. There's so many low-hanging fruits with user experience and go-to-market. And that's where the next leg of growth will come from.

And it's not the, you know, adding a new precompiler or something like that. So if that bridging problem would be solved then potentially all these OP stack users would be sorted. Yeah, I mean the bridging problem is like the legacy bridge that we have today that's written in pre-EOF is good enough. It's really like making the front end more usable and getting people to adopt smart contract wallets that's inhibiting more adoption. I mean, I was interested in the argument of importing tooling from the vanilla version of the OP stack.

I mean, I would say that's actually a nice argument also for EUF because EUF has nicer transpilation properties. from the vanilla version of the EOP stack. I mean, I would say that's actually a nice argument also for EOF because EOF has nicer transpilation properties. I mean, it's much easier without the gas introspection and whatever mess the EVM has to actually transpile EOF to a more modern system. So I think it would actually be smoother to have EOF and then actually build a more fancy version and import the entire tooling stack built for a plain EUF version by a transpilation process without having to carry legacy cost.

I think that's also for actually a future proof system actually a very nice property of effort you have to be a basis for something like that. Right so yeah there's been a lot of talk on EUF today as well and some other days. This panel is not particularly focusing on that, but it's the next planned EVM upgrade, and it's basically going to be the biggest change in EVM history. So definitely want to cover it a little bit. So since it's a core protocol upgrade, obviously it has to be well-tested, and I think concerns around security or even introducing some complexity on the client level maintaining both legacy EVM and EUF EVM, I think most people agree on these concerns and they want to make sure that this all happens the right way.

But I think what's interesting is that even though it's in the roadmap for a while, there seems to be a bit of a discrepancy when it comes to its impact. And I see two main perspectives here. Basically, that one saying is that EUF won't result in too much performance improvement and the future hard forks and a bridge should focus on other roadmap elements that would result in more settlement layer performance improvements. And the other one is that basically EUF is not really about performance, but it's just an absolutely crucial step to make the EVM to like a more mature virtual machine, even maybe help introduce endgame features and make it more SDK friendly. So Matt, maybe let's hear a different perspective here.

You used to be, you actually published about EUF after the merge and listing its benefits and mentioning that it hasn't happened because of these other priorities like the merge, that they were more urgent. Has your perspective changed on prioritizing the EOF implementation? Yeah. I was really and am really excited about EOF overall. I think what it provides is the things that EVM developers have been hoping for for five, six, seven, eight years.

But the thing that really changed my mind about where I placed it on the priority list personally is the thought that, is it something that Ethereum needs to have succeed in the next 10 years or 20 years? And I have felt since that revelation, which was a couple years ago now at this point, that there are things that we're still trying to do today with respect to the execution layer and the consensus layer, to me, seem much more closely addressing these existential risks of Ethereum not succeeding in the future. And I'm not saying that it's time to ossify the L1 EVM, but I do think that when we start talking about implementing changes to the EVM that are very complicated, I have to ask, if we do nothing, if we don't do these things, what is the worst case scenario? And as we're moving towards this roll-up centric roadmap, to me, it feels like that is the natural place for the evolution of the EVM. And if we're going to really lean into the vision that L1 is a place to settle roll-ups, I struggle to see the motivation for making all of those changes happen on the L1.

Is there anything that maybe could change your perspective? More community support, impact analysis, getting more people involved from the ecosystem. I think the thing, this is not a satisfying answer, but I think the thing that would change my mind is if we decide that the roll-up centric roadmap is wrong. Because as long as we are saying that L1 is a sediment layer, in my mind I feel that the clients should be the most robust pieces of that ecosystem. That is the thing that cannot fail.

And we can probably most likely do EOF in a safe way. We are good at testing the EVM. We are good at introducing changes to the EVM. It will probably be fine. But I just have to ask the question, we're adding hundreds of lines of code, if not several thousand lines of code to L1 clients.

That just statistically adds more surface area for attacks to happen, for issues to occur, not just today, but in the future implementing new clients. And I understand it's something that make compilers so much better. Then me, it's almost like saying you're taking compiler code compiler complexity and putting into l1 clients and when i have this thought i think i want l1 clients to be as thin as possible as simple as possible focused on providing one thing and right now that one thing is a settlement layer for roll-ups can i say something spicy? Yes, we like to add precompiles, which have tens or hundreds, hundred thousand lines of code and optimized assembly and all that. And different clients use different versions of these.

I don't like precompiles that much. I would love to have EVM Max. I think that to me, I would rather have EVM Max in the next hard fork than EOF I think. Yeah maybe you can go deep on kind of why it depends on EOF. Technically it doesn't depend on it.

You can do it without, but with EOF you get a significant performance improvements because you can remove a lot of the checks, runtime checks, and move them to deployment time checks. And in the end, this means whether it becomes competitive against pre-compile or not. And without EOF, it may not be competitive, and then it's kind of pointless. Do you have a comparison between EOF versus non-EOF EVMX? Or a factor, like an order of magnitude?

Is it within the same order of magnitude? For some of them, so the checks you have to do, I mean, there's also code size increase if you do it with FDUF. That may or may not be significant. But you do get, let's say, 30% code size improvement increase on every EVM max instruction if you do it with EF. You cannot, like, do any kind of optimizations around pre-allocation or anything like that.

But the key difference is the runtime checks you have to do at each instruction, which you wouldn't have to do with EF. I think there were some measurements for some of the instructions. Maybe it's negligible, but it's also implementation specific. For some instructions, it isn't negligible. But generally, no, I don't have a proper number to tell.

Right. I mean, yeah, I think that even with the EOF version of EVMX, there's been thoughts that it's not, it's never going to be as performant as a pre-compile itself. And so how much closer? Depends, actually. Radek's talk mentioned one case, libff, one of the BN254 implementations used by certain clients, client or clients.

It's actually less performant than EVMX. Now, I don't think Geth uses it. So there are much more performant implementations than LibFF. But even now, today, with the pre-compiles, different clients may have different performance. Yet we have a single gas cost for it, right?

And, you know, in some cases, EVMX would be faster. But yeah, if you look at like highly optimized code, just in the context of the pre-compile, highly optimized pre-compile would be cheaper. But there's another factor that in many cases, you have to use the pre-compiles multiple times to achieve something. You have to call like addition multiple times. You have to call multiplication different times.

And a pre-compile use a different form. You have to translate back and forth. With EVMX, you can skip all of this. You can create highly specific implementations for the use case. And so you may have better performance because you skip all of those overheads as well.

So would you say the biggest argument, like let's say the difference between EOF EVMX and non-EOF EVMX is fairly substantial. You would say that the most important reason to have EOF on mainnet is allowing people to implement whatever cryptographic primitives they want without being blocked on waiting for precompiles for those. Like what types of things are you hoping for? With EOF? I mean, EOF is great, but I'm thinking, like, why does it need to be on L1?

And, like, one thing I'm hearing is that there are precompiles, and I agree with you. We don't want to put that many more precompiles on L1. But then the question is, like, how many more precompiles do we need? recompile that all of the zero knowledge rollups will be able to use? Probably not.

So then to me, always one more. So then to me, the argument that makes more sense is that EOF gives you this ability to write any kind of cryptographic primitive that your rollup is going to need to verify it's zero knowledge proofs. Yeah. So I mean, with these precompiles, I think it's also like another aspect. There were, if you look at when they were proposed, there were like a hotspot.

I think 2020 was a hotspot where people were really, 2019, 2020, when they were like really feeling, okay, I can just propose this. It may happen. There was a lot of activity, you know, a lot of new curves and use cases and people kept proposing. And then as time went on and nothing was accepted, they slowed down. Why would I propose it?

Nobody's going to do anything about it. So there may be like this other aspect that if you open up the space, the ability to prototype new curves and new use cases, there may be, you know, a lot more stuff spawning up there as well. And like another thing which never has been, I think there may have been like discussions of pre precompile, but stark verification. That hasn't been covered, but this would be able to also help in that. But generally, EVM-MAC spun out, EUF spun out of EVM-MAC.

So the core idea still wasn't trying to remove the precompiles. And these are primitives you need for it. And we had EVM-MAC as some kind of idea specification. And it needed something like EOF to be really performant. So this was actually the progression how it came about.

But we ended up, those optimizations EOF provides, which are beneficial to EVMX, they're also beneficial to contracts. And gives like an upgrade path. One to mention is address space extension, which has been an interesting idea in order to do state expiry. EOF would also be providing a path forward like address space extension. Even the current version addresses it mostly.

And that could open the path to state expiry. Now, of course, we always have this question of legacy, and it's like a big kind of worms. Daniel did you want to add something? I mean yeah I mean I also find it always a bit surprising to hear this kind of like if L1 only is the settlement layer then why does it need any more changes I mean the settlement layer is very relevant the performance on this is relevant and the correctness of it is relevant and I mean if people knew what compilers have to do in comparison to non-UF code, they would probably scream in fear and run away from anything like that. So, I mean, these things, I mean, of course, for settlement layers, you have a few contracts that can be formally verified with large efforts.

But, I mean, still, I mean, all of that, this becomes easier. The settlement layer becomes faster. It becomes more robust and verifiable all the ways up the stack. And I mean, this complexity that, I mean, it's fair to argue that it's good to have not that much complexity in the clients, but I mean, avoiding this complexity in the clients produces an enormous amount of complexity up the stack the entire way. So I would at least be careful in weighing that.

Now you might ask, why doesn't an L2 just adopt EOF? So one thing is, you know, the L2 space, it's still really early. A lot of the projects are still kind of fighting for survival. And it's harder to make long-term decisions when you're worried about just being around for the next few years. So I think that we need to see more L2 ecosystems reach escape velocity before they'll be able to, you know, think longer term and do things like EOF.

There's also the problems of, you know, there's like barely any stage one roll-ups in production today, right? Like most roll-ups, they're stage zero still. It's really, really hard to even get to stage one. It was way harder than I thought it would be. And, you know, we're not done.

We're still working to get towards stage two, and we need to make sure that all roll-ups can eventually get to stage two. And until that point, it's really difficult to think about, you know, pulling EOF into, you know, an L2 client. Yeah, and that perspective makes me wonder if we are getting ahead of ourselves and we're not letting the ecosystem develop and we're trying to force something that is going to happen naturally on the L2s and sort of top down dictate what it should look like by pushing onto the L1. I mean, anything that comes to L1, we automatically inherit as L2s. We learned that.

Yeah. I mean, you know, thank you for 7702. Super hyped about that one. Yeah. I mean, another concern is, you know, it's way less likely that all of the developer tooling will get built if one L2 ecosystem adopts it.

So when L1 adopts a change, there's basically a guarantee that all of the tooling will accommodate that change. So that's another risky reason as to why an L2 wouldn't want to adopt something before L1 does. I still feel like this is a very near-term focused thing. I think that if you take a very near-term focused thing. Like, I think that if you take a step back and you think in five or ten years, I don't really see a reason that everybody will still be locked in on EVM equivalents if we have reached stages two and we're comfortable.

Like, roll-ups are going to want to differentiate, and they're going to have more resources, and they're going to find applications that reach 100 million million users or a billion users and once you get to that point then the developers will come and you're going to be able to create totally different ecosystems i mean there's still the argument that the transpilation properties of euf compared to legacy avm make all of that easier i mean even if that eventually is the goal and will eventually happen, it's much better to have a basis of EUF for that. Sorry, what type of transpilation would you want to do in that? I mean, if you want to bootstrap a new set of ecosystem for a new EVM, then EUF can be transpiled to that new version and inherit all the tooling without building it from scratch. And then you can import all the tooling and extend from there. With legacy EVM, that's much harder.

I mean, are we just not overly focused on reusing things and not starting from scratch? I feel like we went, I feel like you went down this path with eWASM. You know, we were all having these ideas, like, let's just reuse the tooling around WASM. And then we got... Turned out to be, yeah, I mean, turned out that the time spent on that, like how many years, three, four years, during that time, EVM tooling caught up.

We had a, what was it, hot... Anyway, we had all these frameworks, we had debuggers, those were lacking. Taking maybe a step back to where you started, the answer to, I think, yeah, we started this question a while ago, and you had a long answer, you know, what changed your mind? And I think that was a reasonable answer, and I do agree with a lot of it. I think it just misses one point.

Several reasons are there why this ecosystem works and why the roadmap works as of today. I think one important aspect which you don't talk that much about is really the developer experience and that each of them have the same EVM. You write a project and application once, you can deploy it on any of them. You can optimize for whatever you're optimizing for, whether you're optimizing for the given user based on a chain or you're optimizing for the cost, for the speed, or you optimize for the longevity and you go for mainnet, you know, it's much more expensive. But you can deploy the same thing, not only the same Spark contract, but everything around it, you know, the RPC and everything is the same.

You can write once, deploy anywhere. I think that's very powerful. And if we start diverging in each of these, because we hope that one of them is going to do bigger EVM improvements, that can only realistically happen if one of them becomes dominating. Or they have some other incentives to get all of these developers and tools and everything around it. Do we want one of them to dominate?

Maybe we do. But I think this is going to really take some time before we get there. While at the same time, there are some maybe other L1s or other chains or other directions which focus more on developer experience. And there's certainly people, whatever you give to developers, they're going to work at the round. There's nothing stopping them.

So the EVM is not stopping developers, they find the workarounds. But, you know, if somebody comes around and they have a much better developer experience, you know, that can kickstart some changes. And I do think that we really keep forgetting about developer experience and we are not unlocking potential enough. If we would give, you know, slight improvements, I think we would unlock a lot more and we may be able to progress more rapidly. All right.

So let's maybe go back a little bit to that suggestion to move developer experience improvements to Layer 2s. And Mark, you kind of answered part of that question that a lot of layer twos and CKVMs are Currently basically focusing on performance improvements as well optimization. So developer experience is In the plans, but it's not necessarily in the near future I think in the last couple of days there were a lot of talks actually that surprisingly they had a lot of plans to improve developer experience as well. What do you think the timeline is here and also could things like standardization or these kind of initiatives maybe help with this to speed this up? Totally.

Yeah, I mean, I think that right now it's the developer tooling, the developer experience, and like the end user experience that is inhibiting the growth of the ecosystem as a whole. I think that at least, you know, we're really starting to get to a point where the actual L2 software is becoming stable enough and reliable enough. And there's still a long way to go. Like I said previously, you know, there's no stage two roll-ups, like, that are actually used a lot in production today. And getting there is the number one priority.

You know, we do want to improve developer experience along the way. And I think with regards to, you know, the ZK EVMs and the kind of, like, the fault-proof EVMs, those are definitely getting hardened. I know that there's a lot of great ZK EVMs that have come out that you can just take, say, Rust code and compile it and stick it in the ZK EVM and not need to implement all of the EVM changes by hand at a really low-level abstraction and interact more closely implement all of the EVM changes by hand at like a really low level abstraction and interact more closely to all the circuits and everything like that. So as these ZKVMs become, you know, more and more optimized, I've been being told that, you know, there's orders of magnitudes of optimizations coming over the next few years where I think it'll be a lot easier to just take any arbitrary L2 software and be able to create ZK proofs for it. I think the idea of ZK roll-up and optimistic roll-up is kind of fake.

There shouldn't be a distinction. It's just a roll-up. This idea of like optimistic or ZK, that's a property of the bridge and that's not a property of the roll-up, right? The roll-up is not the bridge. They're two different things.

I think this is like a really big misconception. And I think that, you know, we're going to get to a point where all the ZK VMs are good enough that the stacks that are based on optimistic roll-ups will be able to just adopt it. Okay, cool. So I would like to talk about this layer-2 focused EVM standardization initiative, which is actually an actual practical step towards layer-2 standardization. This was launched last year, introducing monthly roll calls and RIPs, or roll-up improvement proposals.

And they've been happening every month, and basically these are optional standards for layer 2s to adopt if they want to. Has your team been involved in any of those? Totally. Yeah, we have reviewed a bunch of them. And I've personally attended a couple of the calls.

And we also adopted the, I think it was maybe RIP 7272, the P256 pre-compile. I think the RIP process is really useful for kind of de-risking more fragmentation between all the different, you know, roll-up frameworks. I do think, though, it is still pretty early given that, you know, all of the most, there's no stage two roll-ups. So it's hard to focus on, you know, this standardization when everyone is still, you know, trying to actually build real roll-up software. Okay, right.

So on a recent roll call, there was also something you introduced, which is called, it's like a layer 2 EVM common core. Basically, I think the point is for layer 2s to be equivalent with each other, but not necessarily with layer 1 anymore. And also handling together future layer 1 EVM changes and make sure there are no conflicts with those changes. Daniel, what's your take on these, just generally on these coordinated layer two optimization initiatives? How could this unfold?

Yeah, I mean, that's great, of course. I mean, the only way that we could ever accommodate anything on layer two that's not layer one is if it's a coordinated effort. But I mean, the problem is that we're busy with working around the issues of the Layer 1 EVM. We also still don't have the time to actually really look into doing Layer 2 work, specifically because the Layer 1 work is an extremely huge mess. I mean, of course, I mean, Layer 2 standardization, definitely a good thing, and actually definitely necessary for having anything, any tooling support for Layer 2s in common.

But yeah, I still would say that there is more space to actually accommodate Layer 2 changes with a simpler Layer 1 at this point in time. Right. So we are running out of time a little bit, but if you would like to learn more about this initiative and SCAR, actually the quality of this initiative, we'll have a talk on this later on today at 5 40 I believe on stage one but make sure you check the schedule right so maybe just one more thing quickly Matt have you heard of the roll up get initiative maybe just share a few thoughts on that before we close yeah they've definitely heard of the roll of geth initiative so it's a very super interesting project i think that what they're trying to do is what needs to be happening right now because we're not going to be able to evolve l2s if there isn't some kind of coordinated effort and it feels like the best coordinated effort is by making their lives easier. And for better or worse, most L2s are based off of L1 clients. So providing them an L1 client that is maintained by a team focused on maintaining the coordinated, the accepted proposals and coordinating amongst the roll-ups to figure out what proposals to accept and for that team to implement, those things make a lot of sense.

PROPOSALS AND COORDINATING AMONGST THE ROLL-UPS TO FIGURE OUT WHAT PROPOSALS TO ACCEPT AND FOR THAT TEAM TO IMPLEMENT, THOSE THINGS MAKE A LOT OF SENSE. I AM JUST VERY CURIOUS TO SEE HOW IT ENDS UP EVOLVING OVER THE NEXT COUPLE OF YEARS. LIKE MARK SAID, YOU GUYS ARE SUPER BUSY GETTING TO STAGE TWO. but I think that the reality is going to be a lot more complicated than that as these things always are Totally having you know, this kind of neutral roll-up Geth is great, but it does add, you know some governance risk to the supply chain. So I Imagine that it will need to be relatively conservative with what actually ends up in it.

And yeah, like I think that in an ideal world, nobody needs to use a fork of Geth. And you can just import Geth as a library and kind of, you know, decorate it with extra functionality. This is like one thing that is kind of interesting about like the Reth project, where Reth is kind of looking at L2s as customers or users and tries to like build abstractions that make it easy for L2s to like build into Reth. But with Geth, it's important to be credibly neutral. So there's trade-offs here.

All right, cool. So we have three more minutes, actually. Anything you guys would like to highlight or any takeaways from this panel? All of you, maybe. Let's start with Alex.

I mean, I have questions. I'm not sure if we have time for those because we will have a bunch of um yeah maybe we have the q a as well yeah maybe some of this is covered but the evm common core um i mean even now the different l2s like they have uh uh differences between them mostly on the zk level because they cannot support like each of those, or, you know, there's gas differences. Are you, I'm not sure, maybe Mark, you're the closest. Yeah, well, how do you see like EVM Common Core? What is the first goal of it?

And maybe what is the medium term goal of it? Is it like making sure that even these differences don't exist? Or it's like introducing new stuff, or it's just too early to tell? Totally. To be honest, I don't know a ton of information about EVM Common Core, but at least what I would like to see out of it is introducing new things as there's desire to, you know, improve the EVM, then it's about doing it in a consistent way, right?

Like no L2 team. It's like we used to maintain a fork of the Solidity compiler. Very, very difficult. So like having one set of tooling that works across the whole ecosystem is really, really nice. Anyone else?

Any conclusions or things to add quickly? Because we are running out of time. No? I like the first question. Okay, questions are coming soon.

Alex, anything else? I could go on forever, but why don't we just look at the questions? Okay, so maybe I, okay, do you think that any of these layer 2 standardization initiatives could help with shipping some of these changes faster on layer 1? Like maybe some layer 2s adopt those and it works, and then maybe the guest team says, like, okay, fine, it works, it didn't break anything. Could this, do you think it could improve this?

I mean, my fear with this idea is that L1 teams love to touch the standards. They love to leave their little marks on them and modify them just a bit to fit L1 perfectly. And I struggle to see how we're going to do anything complex on the layer 2 first and then bring it exactly as it is on the L2 on the L1. Even just with the P256 precompile, the L1 devs say, maybe it's at the wrong address. Maybe we should move it to a different place.

BLS, we're trying to figure out, like, what are, where, what is the exact parameters that are going to go into these what are the addresses of these precompiles? Doing these things on the L2 is just going to constrain what the L1 devs are going to be able to do. So you're saying the level of nitpicking is a bit more on L1? It's extraordinarily high. Yeah, it needs to be high quality.

But on the other side, do you think there's a different need of like, EVM changes specifically, you think like L1 has different need of what EVM should look like versus L2s? I think L1 has different needs than L2s. And I also think that incremental changes are the best way to change the protocol. But on EVM, do you think it has different needs? On L1, I think there are different needs than L2.

Okay, cool. Thank you guys. Unfortunately, we don't have any more time, but there will be time to answer questions from the audience. So thank you so much for joining us for today's panel. Don't you have time for the questions?

Yes, they are coming up from, yeah, Can will... Hello, and thank you very much for our wonderful speakers. My name is Can, I will be your MC for the next three hours for this stage. Let's move on to questions before taking more time. I will start with the topmost one.

This question goes to Matt. Why do you consider compiler bugs less scary than execution client bugs? I have written both, and testing compilers is a lot harder than testing EVM implementations. They really, really wanted to ask this question. So the way that I see it, one, I'm a client developer.

I try to keep the L1 safe. That's my primary goal. I don't want to belittle the job of a compiler developer. It's thankless and it's very difficult, but similarly to keeping their code base safe and secure, I am trying to focus on keeping my code base safe and secure, I am trying to focus on keeping my code base safe and secure. I don't want to try and have blinders on and push all of the complexity on the L1 into other places.

But my perspective is, what does the L1 provide? What do blockchains provide that no other facility in the world provide? And that's a platform for unstoppable, trustless execution of code. And to me, what you need to have happen is you need to have a blockchain that works, doesn't have faults. And if you need to write applications on top of that, yes, it's great to have a great developer experience.

It's great to have a great compiler, a safe compiler. But we do know ways of writing code that's safe, formally verified, it's just extremely painful. So I know that in the absolute worst case, if we provide the L1, people will develop applications on it. Maybe those applications won't be as nice as people want them to be, or they won't be developed as fast as they want to be. But I believe that if we give them the platform to develop the applications, they will build the applications that actually use the platform in the way that the platform is trying to provide.

And why should they use the platform of any other competitor that does have a better layer one instead? Sorry, I see the first part. No, I mean, if you ask if, I mean, who's to stop starting a new layer one chain that actually has the better experience on that level as well, and then people moving to that because it has the same guarantees, just only in a nicer way. I mean, we'll have to see how these types of things play out. Like you can already see there is a bit of a, there is a comparison of Ethereum and Solana.

And Ethereum is, as Josh said in his opening speech, the thing that does not go down. Many of the ETH competitors have the meme of like going down Solana goes down Iota goes down these other chains are not as resilient as aetherium and how do we maintain this property it's by being extremely thorough with the types of things that we put on mainnet that's not to say that we should get stuck in this mindset and totally ossified but I think that it's like something that we have to balance very carefully and what ends up happening is you have people who are farther on my side who tend to think that we should be more ossified. We have people who are trying to accelerate what's happening, and we end up somewhere in the middle. It's just not a fun process. Everybody on this panel is extremely reasonable and pleasant to be around.

But we just end up up here arguing about what the Ethereum VM should look like. There. So the next question is around incompatibility around the VMs. Our attendee asks that they don't understand why a bunch of incompatible modifications to the same VM across different L2 chains is considered beneficial. Isn't it good to have everyone on the same high-quality VM?

Anyone wants to take this? I think we all want the same high quality VM. Anyone wants to take this? I think we all want the same VM. I mean, we all want the same VM, but at the end of the day, it's a free market for, you know, scaling Ethereum.

That's kind of like what the L2-centric roadmap is all about. So, you know, any project has the right to modify the EVM in any way. But, you know, the reality is that there's a huge cost to modifying the EVM just because the tooling is so important. I think this goes back to what you said earlier, that if something goes to L1, it's inherently coming to L2. We haven't seen yet it happening that way around.

Maybe with the one precompile now, maybe that could be the first occurrence. But this basically, you know, this question is if you do get it on L1, the same high quality stuff, we ensure that everybody gets it. If some L2 adopts something, maybe another one adopts something else, it's unlikely to ever reach L1, so there's going to be a lot more diverse version of VMs. We have new questions coming in and the leaderboard changing. The next question is, what will be Epsilon's focus after EOF?

I guess I can take this. It's EVM Max. Thank you. The next one is, in what ways could alternative languages, i.e.

Move or others, bring new functionalities to Ethereum dApps that the current EVM lacks? I mean, I guess I can try to take that. But I mean, all the languages have the problems of the EVM as long as the EVM is the target. So I mean, there's only so much that the language level can do. I mean, you can try to have complex compilers to try to work around the issues of the EVM.

There can be languages that are designed in a way in which that's easier. But yeah, I don't think that the language level is the level to solve the issues that the EVM currently has. Adding an alt VM. At the end of the day, if we think about alt VMs, one of the big bottlenecks in the EVM is I.O.

, like reading and writing. And a new VM is not going to solve that. It's still going to be just as expensive to read and write from disk. So like adding an alt VM maybe where it's easier to, you know, build like a MIT native code that, you know, works off of, you know, 64 bits instead of 256-bit math. That's a way to optimize the execution, but it's only really useful for things that don't read and write from disk.

So the next one is around the EVM again. Is EVM going to stay overall the same throughout the next years, or is there any possibility for radical changes to update modern architecture targeting smart contract needs? I guess there is one change. Just listen to the panel. Yes, I guess there is one change upcoming.

I hope, at least. Yeah. Right, then the next one. Discussion here suggests the roll-up-centric roadmap reduces the complexity in L1, yet with the diversity it means compared to native homogeneous ETH2 shards isn't the opposite true. Whose complexity on L1 is not mine mine at least.

Moving on with the next question. Our attendee finds it funny that somehow L2 is going to innovate, but we just heard they need to be conservative about guest changes. Why do we think that L2s are going to innovate more than L2? You know, I think it really depends on the particular L2 ecosystem. You know, some L2s, like, you know, Fuel, StarkNet, like, they're very, very different.

So anybody has the right to build really any sort of L2 that you want. There's just some L2s that, you know, want to be more similar to L1 so that they can adopt all the tooling that exists and, you know, maybe contribute improvements to the same tooling so that L1 also gets the improvements. So yeah, I think that the reality is that the bottleneck for adoption today is based on user experience and go-to-market and not improvements to the EVM. I also think in general, like with L2s, you have the opportunity to try many different flavors or have different focuses, whereas the L1 is this singular thing. You can't really be super fast, super decentralized.

You have to sort of choose on the different axes that you want to focus on, whereas for L2s you could have something that's privacy focused only. You can have something that's extremely fast but might go down, something that has central points of failure go down something that is you know has central points of failure and I think that the L2s like have the opportunity to experiment on those different axes that the L1 just doesn't have. I think I can L1 specifically it's a bottleneck issue that you know there's only as many people there which are and they don't really have time for some of these proposals even including UF you know a couple of years ago nobody had the time to like dive deep but everybody had you know their views and opinions and it was really just information access issue nobody had a time to deep dive into it to have like a proper discussion and and you know get any of the opinions closer I do think that the EUF shouldn't have been this big of a debate and this big of a change and could have been done much earlier if there would have been more bandwidth. That's ultimately what we are fighting around. So we're running out of time.

That will be the all questions we'll be answering, but feel free to catch our speakers after the talk. Let's give a big round of applause for all of them. Our next session will be starting in a few minutes. Feel free to stretch, and we'll be back soon.