Long-term L1 Proposal: Replacing the EVM with RISC-V

Okay, great, so today you'll be talking about replacing the EVM and why I think in the long term it's a good idea and the really important question which is if we're going to replace the EVM, then what do we replace the EVM with? So first of all, why do we not want to just stick with the EVM forever, right? And I think for me the answer is that one is scaling, one is going to be bottlenecked by several things, but one of the really big things that it's bottlenecked by is ZK Prover costs. And over here there's an analysis from the Succinct team which basically shows in the existing ZK EVMs, the ones that are proving like average Ethereum L1 blocks in real time, what percent of proving time actually goes into like different types of execution. And so over here, and actually we have like a lot of different parts, I think initialized witness DB and state root computation, or like actually both have to do with the witness.

So today that is the Merkle-Patricia tree and Ketchak, and in the future that'll be replaced by something much more optimal. Then you have recover senders, which is like ECDSA signatures on basic transactions, like deserialized inputs just means like put the inputs into the prover, verify the public inputs. And then the two really big ones that you can see, right, so one of them is kind of the massive initialized witness to be a state root computation, which is tree related stuff. And the other really big thing is block execution, which is like largely the EVM, right? And there's also pre compiles that are in there, but the EVM is a very big part of it, right?

Now, once we apply known optimizations to everything else, so we replace Ketchak with Poseidon or ITy or some even better hash function, once we take out RLP and replace it with SSZ, that's actually something that's a prover team's maker, finding frustrating RLP. And once we replace, I mean, make the tree binary instead of hexery, remove the 24 kilobyte code sizes and so on, then basically the largest cost by far becomes the EVM. And so once we get there, then the next 10x can only come from replacing the EVM with something else. So what do we replace the EVM with? So the ideal answer is actually whatever instruction set architecture the leading ZK EVMs are using, basically we expose that to developers directly, right?

So today, over here, we have basically all of the leading ZK EVM and even non-EVM ZK EVM implementations. And the way that all of them are written in is basically that they write the EVM in some high-level language, and then they compile that high-level language down to either RISC-V or something else. And then basically the ZK EVM is written as a ZK of an interpreter on top of some much simpler underlying VM. And so basically over half of them are using RISC-V. There's some that are using WASM or MIPS.

There's some that are using some kind of custom one that's ZK-optimized. So Cairo by Starkware and Kakarot is the most common example. And Lean-4 is optimized for formal verification, and so basically makes it much easier to have fully correct-like instruction and approvable implementations of a ZK EVM. So today it's RISC-V. And so the idea basically is that, well, if the way the ZK EVMs are implemented is by taking the EVM execution and then compiling it down into something that's eventually RISC-V code, then why not just expose the underlying RISC-V to smart contract developers directly?

And so basically you just get to completely remove an entire outer layer of virtual machine overhead, and potentially, I have seen numbers that this would get you a 100x increase in the amount of execution that can happen. So RISC-V, in addition to the ZK proving issue, it has other benefits. So one of them is that many existing languages, such as Rust, compile to it. So one thing that's appealing to some developers is that they already have off-chain code that's written in Rust, and so it's appealing to them to also write on-chain code written in Rust, and so they can share code bases between the two. So basically you get the equivalent of Node.

js and how it lets you write JavaScript on the client and the server, basically do the same thing with Rust or potentially other mainstream fast languages on and off-chain. Also RISC-V is increasingly standard in other areas, so open hardware, for example. When people make open-source hardware that tries to be a fully-featured computer, often the thing that they gravitate toward is RISC-V. So there's a lot of benefits to just replacing the EVM with RISC-V. But RISC-V is perhaps not optimal, right?

And so this is kind of the case for going in a different direction, right? So basically RISC-V is generally used in all of the ZK-EVM implementations, not because people are certain that this is the most efficient way to do things, but because it's the easiest way to do things, right? So EVM is a pretty big and complex piece of code. The easiest way to make an EVM is to compile an existing Ethereum client, and so the toolchains for that going down into RISC-V already exist. The toolchains for that going into Cairo, well, they don't really exist, or at least they don't really exist to nearly the same extent.

So basically it makes work easier for today's ZK-EVM developers, right? But is this really the right approach, and is this the approach that will be taken by the leading ZK-EVMs of tomorrow, right? So theoretically, RISC-V was not designed for proven friendliness. Something that was designed for proven friendliness will be more proven friendly. What was designed for proven friendliness, Cairo is one good example, basically some kind of VM that natively operates over the mathematical structures that are used inside of ZK Provers.

Now, on the flip side though, the question is, well, if we choose one of those, is the one that we choose going to be optimal, right? For example, today, lots of provers use 32-bit fields, so either M31 or Baby Bear or Koala Bear, these are just fancy names, don't worry, they're not bearish, for prime numbers that are somewhere close to two to the power of 31. But tomorrow, it might actually be the case that the BNES people are right, and slowly everyone starts migrating over proofs, over hypercubes, over F2 binary fields, basically everything, some kind of structure that's fully binary. And this offers a lot of theoretical benefits, like you can see how theoretically you can do things like 32-bit addition and multiplication natively over F2 operations, but it's not that easy to do it over primes, like you basically have to use lookup tables. Then, also another issue is that today we are thinking about Starks, tomorrow we might be thinking about FHE, we might be thinking about obfuscation, we might be thinking about what if the long-term future of Ethereum's privacy roadmap is actually obfuscated smart contracts, and even to just stick the entire Ethereum state inside of some kind of obfuscation gadget.

If we do this, then suddenly Poseidon doesn't actually look that optimal anymore, and maybe the ITI hash function actually might be the optimal thing, right? So realistically, this is a tough choice. I do not claim to have the expertise to be able to make it myself. I mean, I actually don't think anyone does quite yet, I think we need a proper process of really giving all of the different options a fair hearing, and hopefully coming up to a more clear answer at some point over the next one or two years, but these are the kinds of things that we want to be thinking about. So, isn't a virtual machine complex, right?

Basically, we already have the EVM, and considering introducing a whole other VM into the protocol, and didn't we just reject adding even an at most medium complexity set of extensions to the EVM into the protocol? Basically, just from a raw protocol complexity perspective, why are we sure this is the right idea? And I have two answers to this, and one of those answers is that I actually think there is a path to moving the EVM out of consensus critical code, and basically turning it into a formally verified implementation on top of whatever the new VM is, and the other is that actually, VMs don't have to be complex. So, on the left over here, I had ChadGPT make a Python implementation of a RISC-V interpreter, and the thing that you see on the screenshot over here is literally the first half of the code, right? So, it's actually literally small enough that if you wanted to, you would be able to basically set a RISC-V interpreter on screenshots over here.

Now, the thing on the right is the implementation of the ModX precompiling guess, and actually, it's only the first half of the implementation of the ModX precompiling guess, and actually, it's the first half of the part of the ModX precompile that's just doing wrapper logic and things like parsing the inputs and outputs and calculating guess costs. So, the actual ModX thing is done by a library. Oh, and then actually, actually, there's a guess calculation function that's also not part of the screenshot, right? And so, if you actually compare a RISC-V to some of the crazier precompiles we have, actually, RISC-V wins by a lot, right? And so, one of the arguments here is that, well, even if all we do is we say no new precompiles forever, and instead we add RISC-V and we force even the existing precompiles to be rewritten as RISC-V implementations, then actually, from a protocol complexity perspective, that's a very significant reduction.

So, this is, now, how would a transition from EVM to either RISC-V or to some other instruction set work, right? So, this is one of the challenging things to do, and I think this is something that's going to require a lot of thought. So, this is the approximate idea that, like, I would recommend right now, but this is something that I think, like, we should all look at much more seriously. We should do a lot more analysis on. We should write much more concrete proposals and eventually get towards some kind of more concrete plan.

So, step one is, well, step zero is, obviously, we decide on the VM, right? We say, okay, either we're doing RISC-V or we're doing Cairo or we're doing something else. It's chosen and forever hold your peace, right? That's step zero. Step one is, we start off by using the new VM in limited situations.

So, for example, to replace precompiles, right? We can say, once the VM is chosen or even today, basically, you have a moratorium on all new precompiles. I mean, I actually think we should just have a moratorium on any new precompiles starting today. And what we do instead is we add the new VM and if people want to do new precompiles, then instead, basically, what they would do is they would, like, whitelist specific byte codes in the new VM that could be run. And this would still give you a very significant acceleration over doing it in raw EVM code.

So, that would be step one. Step two would be to make this new VM directly available to users. So, you would let people have contracts that are written in RISC-V or that are written in Cairo or whatever we choose instead of being written in the EVM. And actually, the two types of contracts would be able to call each other, right? So, basically, the way that these VMs work is that they always have some kind of opcode or some kind of feature to do a syscall.

And if they do a syscall, that basically, like, temporarily exits VM execution and it goes back into the system. And then when it goes into the system, like, basically, you could use that for SLOAD, SSTORE, sending ETH, and then the equivalent of a call operation. And then the Ethereum execution layer would interpret that and then it would interpret a particular type of syscall as being a call into another contract. It would actually run the call, would get back the response, and then pass it back in. So, you would be able to have contracts in the new VM and in the EVM be able to actually seamlessly interoperate with each other.

So, this is step two. And then finally, step three, if we want to get the EVM out of the consensus-critical code pathway, which basically means that someone would be able to write an Ethereum implementation that would be sufficient for participating in consensus that does not include any EVM libraries, then we make the EVM an implementation inside of the new VM. Right? So, this would be, like, how I generally think of the three steps, right? And there's a lot of the existing changes in programming languages that we can look to for inspiration, right?

So, I think the two extremes are basically, there's the Python 2 to Python 3 transition, which is very backwards incompatible, put a lot of work on developers, and that a lot of people ended up being highly critical of, even though I think at the end, Python 3 is definitely better than Python 2, and I'm, like, glad that it happened. Then, over on the other side, you have kind of Microsoft Windows total backwards compatibility dystopia, where basically the complexity of the code just keeps on ballooning up, up and up, because you have to support everything forever. And then in the middle, there's, like, the Apple Rosetta kind of approach, where you support older versions through emulation. And so, it might become less efficient because there's somewhat more indirection, but you still get support for older things that keeps going forever. And this is probably most similar to that kind of intermediate Rosetta-style approach.

So, what does this all mean for smart contract developers, right? You might ask, well, if we're going to replace the VM, does that mean we have to throw out literally everybody's work, right? And I think the answer is no, and I think the answer is no for a couple of reasons. One is, if you're lazy, you will be able to keep on writing EVM code quite possibly forever. I mean, it might be less efficient, but you'll be able to do it.

Two is that it's not too hard to repoint existing Solidity and Viper compiler backends to something like RISC-V. So, increasingly, these compilers are working through intermediate representations, and compilers from those intermediate representations to different kinds of backends are something that's becoming more and more possible to do. And then, I'm expecting that we're going to see more and more shared tool chains for different pieces over time. So, this is something that you would be able to make a version of Solidity or a new version of Viper that just compiles to the new VM. And then, one day after the new VM becomes available, a new version of the compiler gets released.

The same code works the same way, but it's magically three to 100 times more gas efficient, right? This is something that's possible. Also, once this becomes possible, then developers also become able to write contracts in Rust, and both of these options start to coexist with each other. I mean, I actually predict that Solidity and Viper will continue to be popular for a long time. Like, if you look at other blockchains that let you write code in Rust, it's the sort of thing that's beautiful in theory, but then you look at the actual code, and it's friggin' ugly, right?

Solidity and Viper contracts are actually very beautiful by programming standards, right? It's like, you don't need any of the stupid include std colon colon blah blah blah. You don't need basically any boilerplate code. You just go straight into the contract, right? So, basically, both options will become available, the existing way and the new way.

So, when could this happen, right? So, first of all, not in 18 months, right? And I think the reason why I would oppose doing it in 18 months is basically because the priority right now is in more certain forms of L1 scaling, so in forms of L1 scaling that deliver very significant gains, and in ways that we already understand, in ways that we've already spent many months thinking about. So, this includes things like block level access lists. This includes delayed execution.

This includes gas repricings. And also, we need time to evaluate the choice of the virtual machine. I think the choice that we make a year from now is going to be wiser than the choice that we're able to make today. But also, we can't wait too long either, right? I think in the long term, we want the Ethereum protocol to be simpler, and one very natural way to do that is to have one ISA to rule them all, right?

And basically, whatever we use at the execution layer is also the thing that we should use at the consensus layer. So, for example, to implement something like a Stark-based signature aggregation, and potentially you could even extend that into use cases like client-side proving. Also, if we're going to have a total moratorium on pre-compiles, which I think we should, then developers are going to want some solution for new forms of complex computations that come up, right? So, examples. So, one is Starkware for the Starks on Ethereum.

They have always been wanting to have lower, more gas-efficient ways of running the Poseidon pre-compile or the Poseidon hashes because they want to have Poseidon hashes on-chain. And actually, this is a big reason why so far they've only been able to do 64-bit instead of 32-bit, because with 32-bit, you just have to do more math. And then, you need to do more numbers, but because all numbers in the EVM are 256-bit, you don't actually get any savings from each individual number, and so the complexity blows up by a factor of somewhere between two and four. And so, if we have some kind of SIMD that would solve it, but also another way of solving it is to just expose some kind of 32-bit or 64-bit VM directly, right? So, there are use cases right now that want faster forms of computation, and I expect as lattice-based things become more popular, I expect as some of these highly-optimized hash functions become more mature, as everyone starts doing 32-bit things, there will be a need for some kind of solution for complex cryptographic computations, and a more optimized VM is just a natural solution, right?

And so, we don't want to do it too fast, we don't want to wait too long, and so, realistically, this is a medium-term thing, right? But I think it's a medium-term thing that once all of the short-term opportunities for optimization are taken, is going to be something that's really important to get right and to improve if we really want to unlock the next step in Ethereum scaling and the next step in Ethereum developer-friendliness from that point forward. So, thank you. Thank you. Thank you, Vitalik.

We have a good amount of time for questions, so we can turn it into a discussion around this topic. So, as a reminder, you can post your questions here, scanning the QR code, you can upload the questions, and we can dive into them now. So, the first one that is most popular is, what are your thoughts on PVM and PocoVM? I actually don't have many thoughts on PVM and PocoVM, I'm sorry, guys. That was quick.

Next one. What are your thoughts on eWASM? What happened there? Yeah, I mean, eWASM is definitely one of the other natural choices, right? So, there was this whole project to try to make WASM be the virtual machine 2.

0 for Ethereum for a long time. I think also one of the impetuses there was that WASM was being standardized as the fast VM for browsers, and a lot of it was a very similar emphasis, right? It's like, we want the world to have one optimal VM to rule them all, because that just makes everyone's developer experience simpler, and WASM was looking like it's it. I think now, realistically, if you just compare WASM versus something like RISC-V, RISC-V is significantly simpler. It doesn't have a lot of things in WASM, like a lot of its explicit features for functions, a lot of its built-in more complicated data structures for code, just various different things, right?

So, I think for me, greater simplicity of RISC-V is probably the primary reason to go, and also the other reason is that if we re-answer again the question of what is the leading VM in the context outside of Ethereum, it's actually working like RISC-V is the answer now. The next one? Do you think your early suggestion to ban code gas introspection may have unintentionally led EOF devs down the wrong path, since they adapted quickly, but EOF later lost their support to RISC-V? That's a challenging question. I think it definitely is, like what I just proposed is definitely a very different approach to long-term EVM evolution than the EOF or the EVM approach that I was envisioning, right?

Basically the EOF-based approach that I had in mind basically said, okay, we're going to extend the EVM and we're going to make it kind of more, like basically add more guards against introspection that makes static analysis easier, that makes compiling easier, and then at some point that actually makes it much simpler to make interpreters, provers, and so on. You have like very natural compilations down to either RISC-V or other types of VMs. And I feel like in general, we have seen over time that that entire approach had a lot of limits to it, right? I think one of them was the various reasons why other people ended up being unhappy with EOF. I think another is like from a backwards compatibility perspective, there's like this whole gaping hole of like, well, what do you actually do with the existing EVM?

And I mean, I actually do think that it's super important to not just think about like simplifying the changes to the protocol, but actually think about simplifying the protocol and even removing existing points of complexity. And like one of the examples why this is important is I remember there was this bug that happened in 7.7.0.2 where actually L1 ended up being immune to the bug.

And the reason why L1 is immune to the bug is because on L1, we went through this long painstaking process of making sure we removed the concept of an empty but existent accounts from the EVM. And that simplification actually basically made like the bug, the issue that caused the potential consensus failures on L2s just did not happen on L1. So I think for these kinds of reasons, it's actually good to address the complexity of historical decisions as well. And like the EOF path and EVM hardening path did not have very good answers to that. And so, I mean, I definitely admit I made mistakes in how I was thinking about this and probably was not sufficiently willing to take the more radical approach.

But no, I mean, I think if I just look at the problem freshly right now, my view is that this kind of more radical approach is actually better both for efficiency and better for having a path for backwards compatibility. Thank you. The next one is about PolkaVM. PolkaVM is based on RISC-V with compilers for Rust and soldered down to the VM. Are we likely to see some compatibility between the mid-level abstractions of the EVM and of PolkaVM?

OK, so the way that VMs work, right, is like they have the ISA, which is the instruction set architecture, which is like basically a list of opcodes, you know, like add, mull, XOR, jump, like whatever. Right. And then on top of that, you have scaffolding, which basically represents like what is the VM actually allowed to do? How does it interact with the surrounding environment? Right.

And so if PolkaVM is based on RISC-V and then if a future EVM is based on RISC-V, then they're likely to have either very similar or the exact same ISA. But then the surrounding like things that they're allowed to do might end up being different in some situations. Right. I think for the EVM, the surrounding things that the VM is able to do like that has to be based on the existing constraints of the Ethereum state model, the Ethereum cross-accounts calling model, the Ethereum accounts creation model. Basically, all of these things have to be backwards compatible with the way that the EVM works.

I mean, maybe I have like maybe there is a way to make that kind of maximally compatible with Polkadot as well. And so be able to maximize code sharing. I mean, but maybe there's a limit to that. I think that's something that I'd have to look into and research much more. OK, favorite cat breed?

Can I answer like Nyan cats? That's an answer. The next one, can we please have the Poseidon state tree? It would be it would make VK wormholes possible and privacy cheaper. OK, so I'm a huge fan of moving the state tree to Poseidon and like I personally actually think this should probably be the first thing that we do after we're done short term L1 scaling.

And then after we're done, let's say account abstraction and fossil. And at the same time as that, Eton's EIP to move a lot of things over to SSZ, like basically, I think after we do this round of aggressive L1 scaling that people want to do over the next one and a half years, like taking a breather and doing those kinds of simplifications is like I think exactly the right time for it. But I actually so the VK wormhole EIP right at the time, I think 7503, I don't know if so there's this new version that the author proposed. And like one thing that I really like is that it actually moves away from relying on the state tree and it instead moves on moves toward relying on receipts. And I think this is a much better solution.

And the reason is that with receipts, like actually the verification logic becomes much simpler, right? Because in a state tree, like because it's the size to the 256, it has to have dynamic depth. Like there has to be just like inevitably more clauses to handle like key value nodes and like intermediary intermediate things and so on. Right. But with a receipt, it's just literally a simple like high school OG Merkle tree.

Right. And so you just have to like do a loop where you do hashes and then and if and if statements for where you put the previous hash and that's it. Right. And this can be this gets combined with the EIP, I believe it's 7708, it might be 7706. But there is an EIP that I wrote that makes a default ETH transfers emits a log by default.

And that was like that actually ended up having a nice synergy. I guess that like that's what enabled the wormhole author to change it over to that. Right. But that will basically get doing things with receipts, I think, is actually generally nicer than doing things with state. But at the same time, we should make the state better presiding binary trees are the way to do that.

And at the same time, we should make receipts better. And ETH's SSZification of everything EIP is the way to do that. If privacy is taken into consideration, is RISC-V a good choice? Hmm. OK, so for privacy, the thing that we just are looking at is client side proving.

Right. And client side proving is challenging. Right. So right now, we've over like basically literally a decade of developments. We've managed to get ZK-SNARKS to the point where proving a Merkle branch is something that can be done in like within a second on a laptop and a few seconds on a phone.

Right. Which is like an amazing accomplishment. So round of applause to every ZK dev here who helps with that. But if we want to enable more complicated ZK applications, then we have to move to a world where the developer experiences that you can just write code and then that code can operate over private state. For that to happen, we like actually having a good client side VMs is a very natural thing to do.

Right. And also, actually, if you want private applications that also interact with the blockchain. So, for example, if you want like a ZK proof that you have a Pope or a ZK proof that you have an Ethereum account that satisfies certain properties, then you will need to make like potentially like proving that you have is something that might actually require doing proofs over EVM code. Right. And so replacing the EVM with either RISC-V or with a much better ISA is like something that is going to be very critical for improving that.

But one of the challenges is that like proving is very expensive. Right. And client side proving for ZK like VMs, even much better ZK VMs, is something that will still take some time and that we still have to optimize. But then even at the end of the optimization, like the types of proofs that are the process are Starks, right. Hash based and hash based proofs.

They are over 100 kilobytes in size. And if you have a proof that's over 100 kilobytes in size, that's not going to go on chain. And so you need to have a wrapping layer that like basically turns it into a smaller proof. And like there is a couple of solutions here. Right.

One of them is outsourcing. Outsourcing is kind of ugly, but, you know, it is an approach. And the other thing that we can do is like actually like really, really optimize the code for making some kind of like blanket noir proof on top of a Stark, like actually be fast enough that someone can do it on their clients, at least on like a fast phone within four or five seconds. So that's option two. So like that piece also also needs to be figured out.

Right. So there's like a lot of engineering challenges in making client side proofing work, but I think absolutely we should be putting a lot of effort into it. Next one's on precompiles. Why do you believe that with RISC-V we wouldn't need precompiles? Existing ZKVMs have them too.

So I think like if I had to add one precompile, it would probably be like SIMD, like being able to do a math over vectors at the same time. And that's actually enough to heavily accelerate the kinds of cryptography that we're going to be doing in the future. Right. It's enough to accelerate Poseidon hashes. It's enough to accelerate lattice based math.

And actually, like it would make Bignum multiply like it does. It accelerates like maybe the 90 percent of the hard work of Bignum and the multiplications. I mean, going beyond that, like the challenge is basically that, you know, we just want these like we want code complexity and we want especially consensus code complexity to be minimized. And I mean, look, there's definitely a trade off. Like if there's something that really, really requires it to achieve very high efficiency gains, then it could be worth it.

But I think if we look at EVM history, like we've honestly been way too trigger happy on adding precompiles. Right. Like there's lots of precompiles that are being just barely used at all. And they're the things that have been responsible for some of our worst near misses in terms of consensus failures. The next one, how do we avoid making the same mistakes as Polkadot?

I don't know if you have the context, though. Yeah. What mistakes has Polkadot made? Does anyone come to come and come here and tell us about it? I guess you don't have context.

No, maybe. Can you maybe I'll ask, like, how do how do you like making the same mistakes as you have or it wasn't like previous proposals? Yeah, I mean, I think my view for why some of the previous proposals were rejected is like one, like total complexity of the protocol ended up ballooning quite a bit. And there wasn't like any kind of remotely realistic, realistic path for like ever removing the old thing. And so the bloat like required that and the amounts of effort required to create a new client would just keep going up and up.

So that was one weakness. The other thing was that like it didn't really like none of them really kind of hit the the sweet spot of providing good long term benefits and at the same time like providing good short term benefits to developers to really get them excited. Right. And I mean, I think like adding a new ISA like that actually is something that does provide very clear short term benefits, I think, because we'll be able to. Basically, make many more instances of something which is like maybe half as good as a precompile and then basically and then eventually like basically make it be is like almost full replacement for precompiles.

How would GAF accounting work on the RISC-V VM? Same way it works on the EVM. You know, you use step counting and then if particular steps do complicated things, the steps cost more. And if you do syscalls, then those syscalls get charged based on whatever formula. This one is also related to EOF.

It says one major reason EOF got scrapped was due to lack of backward compatibility requiring changes in Uniswap and other smart contracts already deployed. Is RISC-V backward compatible? Yeah, I mean, I would say like ironically enough, it's kind of it's more backwards compatible by being more extreme in the sense that like it opens up this other path, which is to say like you can just basically either recompile Solidity down to the new EVM and like there's just a lot of headroom to make it be equally efficient. Or the other thing that you can do is you can basically like turn the whole existing EVM into a contract on the new one. And then I mean, potentially developers would even be free to mix and match.

Right. Like you could even imagine like this is, I mean, a little bit of kind of riffing, as I know Georgios likes to say. But, you know, you could imagine something, some kind of design where contracts would have individual functions written in the EVM and individual functions written in RISC-V. And, you know, the EVM gets compiled down and the RISC-V gets interpreted as is. Right.

And so like developers would have more freedom to choose between sort of the backwards compatible way and the efficient way on a very fine grained basis. Did you consider dropping non-optimal solidity in favor of RISC-V compatible native languages to write smart contracts? So I just disagree with the idea that like mainstream languages like Rust are better than Solidity. And so we should switch to them. I think Solidity is good and I think Vypr is good.

And I think these languages are beautiful. They enable you to write very clean and simple code that looks nice and that looks much nicer than the more mainstream languages. And so I actually think that even after this kind of transition, they're going to stay. Are we going to ossify EVM, no EOF, etc.? I mean, I'm actually personally in favor of ossifying on something like a five year timeline.

I mean, I think basically once you do some of these short term scaling ideas and once you do some of the more radical like a lean Ethereum ideas around replacing the consensus layer, doing three slot finality, doing optimal signature aggregation, and then we replace the EVM with something that's like reasonably close to optimal. I mean, I would say, yeah, I mean, I actually think it does become practical to go in that direction. And where does this process most need help right now? The process of development? I mean, I think one is like really helping with the analysis in terms of choice of VM.

Like I think I mean, I know Starkware just did a lot of thinking already, like basically advocating for Cairo as the VM. And I mean, I think we can do similar things for other possible like minimal VMs, whether like risk or MIPS types of things or whether like the approved or optimized ones, you know, really have the debate between like small field and binary, then even critique some of the existing analysis that's been done both on by just Starkware and like basically get to the point where we have a good understanding of what the tradeoffs are and we can make a decision. So that's one thing. And then another thing, like having an explicit POC implementation of some of the things I talked about around like the step one, step two and step three. So we can actually see what that looks like.

I mean, even with one particular VM and trying to make that whole side of things more tractable. So I would say, yeah, start with those. OK, it's contentious. Image on air award, Google Gaga. OK, for some reason I don't see that, but yeah, I mark that as answered.

And we'll talk about the execute of code. Yeah, I mean, I think it's interesting. I think it's something we should definitely really explore. I mean, it is something that I think we should be careful about and we make sure that we're doing in the right way, because if you do it in the wrong way, then you've like added a lot to the EVM. And at the same time, like you might have built something that only a portion of L2s are actually willing to use.

Right. So build something that's like flexible enough to even cover, say, arbitrary stylus type use cases where they can have the EVM alongside their own VM that they might want their own proof system for, cover like various different EVM extensions that different people want to do. And I think it's definitely like worth it's definitely worth thinking about and figuring out the best version of. And we're moving to describe potentially unlock, improve execution on low end devices. And it depends what kind of execution I think in principle.

Yes. Also, I mean, it would probably be good for account abstraction, right? Because if you're going to have account code that has like more complicated and like arbitrary, unknown cryptographic algorithms and you want like ledgers to still be able to process it, then doing it in an optimized VM might actually be really important for that. I mean, in terms of like running Ethereum's full nodes on low end devices, I think that's less important because I think like nodes that fully re-execute Ethereum are not going to be viable on low end devices no matter what we do. But on the other hand, devices that verify Ethereum with zero knowledge proofs and devices that maintain parts of the state, that is going to be viable, but that is going to require much more.

But that's not going to depend much on the VM because the bottleneck is the ZK proof verification. OK, a longer one. ELI5, explain like I'm five, for a non-technical audience. If Ethereum replaces the EVM, how does that impact synergies with developer ecosystems that call themselves EVM compatible? So I think, actually, I'm optimistic that these other ecosystems are going to be able to follow along.

And I think my reason is that so far they have a good history of following along and implementing EIPs that Ethereum 01 has implemented. Like a lot of them have 7702 support. They have support for various precompiles. And then if we add RISC-V support or some other ISA supports, then like it's fundamentally not more complex than that. And so I expect that they'll add it.

And then at some of the later stages, I mean, I think for them to be willing to add it, it needs to be in their interest. And so they need to be confident that one, it's better and two, that there's good tooling for it. And so if that exists, then I mean, personally, yeah, I don't see why not. Your favorite programming language? I mean, probably Python for me.

Nice one. The next one, does adding contract calls, storage, gas metering and so on defeat the purpose of the simplicity of RISC-V? Wouldn't it be easier to add smaller work sizes to EVM? I would say no. I mean, I would say, yeah, contract calls are not complicated.

That's just syscalls. Like that's a piece that's outside of the VM that where the code can basically just be borrowed from the existing Ethereum implementations almost as is. For gas metering, the same thing. Like, honestly, OK, like back in 2014, I remember how people were afraid of metering and like, oh, my God, metering and metering is so hard. And like, can we please figure out how to make it work without metering?

Let's not do metering. Let's count milliseconds. And then like I remember saying, like, no, we're doing metering. And metering is the future. I envision a world where all computation in the world is metered.

And like, OK, maybe that last step didn't quite happen. But like I think in the end, like metering ended up working out very well. So and like the extra code that's involved is like actually not that much. What's going to happen to current ERC standards? Will they be reformed or can we continue to use them with RISC-V?

I think we'll be able to use them with RISC-V exactly as is. I think it might be pragmatic to reform some of them to take advantage of four byte fields and save on call data. But even if none of that happens, they will be able to work completely as is. Right. Because like basically, the VM and like the ISA only affects what happens inside of a call.

The ERCs, they only affect interactions between calls. And so you are able to write code in the new ISA that is fully compatible with all existing ERCs. The step zero is to agree to target ISA. Will this be the hardest part of the transition? Good question.

I don't know. I mean, it's it's I think it's your job to and like everyone's job to like really do the research work so that we like know what the best possible options are. And no, I mean, I think if there is the will for it, I'm I'm optimistic that an agreement can be made. OK, I think I'll take one last question. It's been a long Q&A.

PolkaVM, PolkaVM, PolkaVM. I mean, I'll also point out that I think like the Nervosa's VM I did, I guess also RISC-V based. Right. The last one. Could we standardize the interface design of VMs in order to easily switch if needed in the future?

I think yes. I mean, I think in a lot of cases it's standardized already in the sense that like I mean, the EVM is like actually kind of exceptional and that there's a lot of opcodes that kind of independently poke out into the environment. Right. You have call, balance, S-load, log and so on. And like RISC-V has a more like stripped down syscalling interface and like more of the a lot of the well-designed VMs do the same way.

And so if we just standardize on the concept that you have a syscall and that you bytes go in and bytes come out, then like everything outside of the VM should be able to be VM agnostic. OK, with this we will wrap up the session. Thanks, everyone.