Ethereum Clients: What Comes Next? | Ethereum Korea One: Genesis

Transcript

Thank you. My name is Youngseok Yang, CEO of Nodeinfra and I'm going to ask a small question. Today's topic is what's next for Ethereum clients, how clients are evolving across research, research implementation environmental and global operations, peer-sharing, and I'm joined by my panelists here, Jun Song from Prysm, and Luca, a researcher and an alumnus of the Ethereum Foundation.

So I guess we can get started with a round of introductions. Questions: please tell us who you are, what is your team, what is your name, which part of the client stack are you working on? Hi everyone, I am Luca Zanolini, I am a distributed systems and blockchain researcher. I recently was part of the Ethereum Foundation Protocol Consensus team for the past four years. and was involved in protocol consensus research, specifically on short and long -term developments of the Ethereum consensus protocol such as faster finality, consensus and everything around it, like for example also the fast confirmation rule, more recently on ePBS, and specifically what I've been doing is working on a security

analysis of ePBS to guide and go together with developers to discover bugs and to be ready for Glamsterdam. Hi everyone, my name is Jun Song. I work at Offchain Labs, and Offchain Labs is supporting Prysm, which is one of the major consensus clients in Ethereum. So, recently I'm waiting for the Glamsterdam update. So there's a lot of consensus change in Glamsterdam. so I'm trying to make Prysm much safer in terms of all those recent upgrades.

So yeah, it's an honor to be here with the very wonderful panelists here, and I'm really looking forward to today's discussion. Thank you. Since the topic of ePBS came up, I have a question for you. So ePBS moves block building into the protocol and replaces the relays that everyone uses today. Curious to know your thoughts on what does Ethereum get out of this change and what is it?

That's a very great question because I think ePBS is one major component of these recent upgrades. Let me talk about some kind of complexity. Because of ePBS, the consensus client has more complexity. Consensus client mostly consists of two parts. First of all, the consensus client itself, and the other part is the validator client. For the validator client, each validator has one more duty called PTC, Payload Timeliness Committee.

and each validator in the PTC should report whether a payload or a block is available or not. So that's one kind of complexity added here. For the consensus client, fork choice has changed a lot. So pre-Gloas or pre-Glamsterdam, there's only two possibilities for one slot. First of all, a slot can be missed if a proposer is offline or something, and otherwise the proposer can propose a block And post-Glamsterdam we have three scenarios.

First of all, just like before, proposer can miss a slot. And even if proposer can propose a block, the block can contain payload or not. So there are three cases here. We need to modify our fork-choice code a lot. And that's the other complexity that we are facing at this moment. But I think that apart from this complexity, it brings a lot to Ethereum. I'd like to mention scalability.

So, pre-Gloas, the validator should cast a vote at the 4 seconds of the slot. So, you can think of there's a 4 seconds of room to execute and validate the block, but the reality is not that. that's not the reality. So in practice, there's only a couple of seconds to execute and validate the block at this moment.

And with ePBS, this kind of window is expanded at most five times. So it's quite a lot. And we are targeting the gas limit from 60 million to 200 million. So it's like more than 3x and I would say this is kind of a conservative result because we want to ship 300 million at first. So yeah, that's a lot of improvement. And the other thing I would like to mention is builder market change.

Because the auction can take place in the proposer. So today all this auction is happening in the relays and it is not transparent. So it is not possible to know all the mechanism and it's all under the hood. But with ePBS, this process becomes all transparent. So for example, we can now know the floor price of bids, because even a solo staker or a single node can submit a bid, and if the trustless bid has more payment than relays,

the relay bids will be rejected, so it's kind of transparency, and also, the proposer can be much more active, so it can play a much more active role and it can request to the relays or to builders multiple times in a slot. So yeah, I think the builder market is changing a lot. So yeah, I'm really looking forward to this upgrade. If I can quickly sum up to this great answer. So from a protocol researcher perspective, I believe that ePBS is bringing a lot of good things, in the sense that now what we were able to see and to prove is that now with ePBS we will be able to specifically prove theories about ePBS and we will be

able to understand exactly under which assumptions certain properties can be guaranteed, under which assumption we can say, for example, protect the builder, protect the proposer, and all of these things we couldn't, we cannot do that today because today there is no sort of accountability for builders, for example, because builders are outside entities, we rely on relays, and if the builder or relays misbehave somehow, there is no in-protocol mechanism that can force anything towards protecting the block, protecting the proposer, etc. With ePBS we remove the need for relays, we bring builders into the protocol, and because of that we are also able now to

prove properties about proposers, about ePBS in general, and we can collect a set of very clear assumptions that if they hold, then we are sure that certain properties can be guaranteed. So the proposer can be safe, for example, as mentioned before, that, for example, if the builder now misbehaves somehow or it withholds the payload regardless the payload now the protocol can enforce the builder to pay the proposer, and this is something that is very valuable.

Of course what we get back is a sort of additional complexity because of course now we have more in-protocol participants, we have more things to handle, there are more assumptions to sort out, for example, why is it required, why are being disabled etc. But what it gives us as researchers, as a community, is a mechanism that can be proven safe. So this is a great thing. Thanks for the very deep analysis.

Pretty interesting from an infrastructure point of view from where I stand. So the next question is something less specific but also very important, which is conversations around L2s versus scalable L1. So for the last years, the Ethereum community and its ecosystem has been telling builders that L2 is super important, but then recently there has been a little bit of shift in the narrative, putting more spotlight on scaling the L1 itself. So, curious to know, Jun, from your perspective,

how this is affecting the ecosystem and how should builders be reacting or adapting to the changes that are happening in the ecosystem? Yeah, so a few years ago Vitalik talked about the rollup-centric model or roadmap, and personally I think that it is quite successful at this moment. So most of the L2s are using their blob space on their premises, and there's a lot of use cases in L2 at this moment, including Robinhood these days.

And so I think that, so we, we are now scaling L1 because now L2 is quite scalable. I think the purpose of scaling is quite different. And also, due to brilliant code design, we are now able to improve L1 without losing some trade-offs. One good example is ePBS that we just discussed. So with ePBS, each node has a much longer window to validate.

So it's a lot of improvement in scaling. And I think that on scaling L1, I would say most of the applications can be deployed in L1 at this moment because nowadays gas fee is very cheap, and I think that for the L2, most of the L2s will shift to providing more specific blob space compared to the generic or general blob space that we provide.

So I think L2 will cooperate with other institutions and companies and try to solve their own problems in L2. Because financial institutions need much more scalability and reliability than we expect at L1. So, I think we are scaling in both ways and there are different purposes. All right.

I guess, yeah, same question to Felix, who just joined us. What is the question? We were discussing the conversations around L1s versus rollups, not versus rollups, but you know, for the last few years, the L2-centered model was sort of the main narrative in Ethereum, but then recently there's been a shift towards scaling L1 itself. So I just wanted to hear your perspectives on this.

I mean, in the grand scheme of things, I would have to say we always wanted to scale L1, but I don't think it's exclusive with the L2-centric roadmap, but I do see some value in the L2s, like myself. so I am not fully on board with this, just framing it as a shift. I can quickly add something. I have to say something about builders and institutions in general, is that do not focus too much on specific entries in a roadmap, in the sense that, as we saw and probably will see, this might change, right?

In the sense that we discover new things, especially now with AI helping researchers discover even more things. So the roadmap's specific entry points might vary over the years, but what doesn't change is the philosophy behind Ethereum and the philosophy underlying all of these changes, which is maximize trustlessness, keep as much decentralization as possible to build this neutral settlement layer. So if your military or institution wants to adopt Ethereum, just follow this principle, in the sense that you don't focus too much on specific entry points.

This might change. What will not change is the core practical principle of Ethereum. This settlement layer will always be maintained and optimized. My next question is related to protocols. Vitalik mentioned that ZK and PeerDAS essentially will resolve the trilemma problem. And where you guys sit as a researcher and a client developer, what's your perspective on this direction, and do you think this will be realized, or is it farther down the road to actually be implemented and be ready for production?

So maybe just to quickly restate this trilemma, common knowledge is that the conjecture that any blockchain cannot guarantee both decentralization, security, attacks are expensive to be placed, and scalability. And what happens is that if you increase the throughput, for example, increase the block gas and everything, what can happen is that currently, since all the nodes need to re -execute all the transactions in a block, it means that the higher the throughput, the more transactions or the more effort needs to be taken to get it done, so it might decrease a bit the decentralization.

So given that the L1 maximizes decentralization and security, a lot of effort has gone towards improving scalability, and that's what we discussed, for example, PeerDAS, data availability, and ZK proofs, etc. So I think from a theoretical perspective it seems that the trilemma is solved. From an engineering perspective, what happens from my point of view as a protocol researcher is that we're just moving around assumptions, in the sense that now, yes, in the future with and everything and PeerDAS now it's true that we can have a lot of throughput, but we remain with the same

level of decentralization, because now in the future we might want to verify blocks, not to execute everything, but what happens is that we are moving around assumptions onto these layers, that we are moving assumptions to PeerDAS, meaning that there are enough custodians to hold data, we're moving assumptions towards the fact that there exists at least one prover that will be live and will prove something. So I believe these assumptions are much better compared to the assumptions of before this announcement. So the trilemma from that perspective seems to be improved in that sense.

What is really important from my perspective is to keep proving cheap, to not end up even centralizing potential proving. But of course I'm not like a ZK expert in that sense, so I don't know exactly how to make this happen in that sense, but if we end up in a place where we require more and more computational resources to create proofs, then it might create again centralization of provers. so that's why it's very important to proving but yeah, that's not important I don't know what to add.

Yeah, maybe on the topic of proving in general, it is still, I would say, a pretty complicated area, because the way it's implemented is that for many low-level operations in the block processing pipeline, custom circuits have to be built, or the zkVM platforms have to implement special logic to actually make it performant. And from the client-developer perspective, I was a bit disappointed seeing this, because when the initial announcements around zkVM happened, there was this assumption that they would just make a generic machine

that could run basically any RISC-V code and that would be provable. But very quickly it turned out that from a performance perspective this is not possible. So they can only really prove it fast if the guest program, that's the thing that's been proven, if it has special system calls for all the interesting operations. And so in practice there isn't a lot of generic logic left, but every time, for example, the client runs the SHA-3 hash function, it actually doesn't compute SHA-3, it just does a system call to the zkVM, which will then compute SHA-3 for it in the proof system, and there's many, many of such operations, and I think this makes

the whole thing a bit messy, because it's a bit like cheating, so it's not actually proving that all the computation happens as it does, but it's, it's just a lot messier under the hood than people think. Basically there's a lot of little details that I'm not so happy with, but in general sense, I mean, as long as they come up with some pipeline that is correct, then yeah, it has a lot of potential, this technology. Alex, do you want to add? Yeah, maybe I can add just one more sentence on ZK. So there's a recent proposal to include all this proving and proofs in mainnet.

So the EIP is called Optional Execution Proofs, and I think that can be a good starting point to integrate all the ZK proofs in protocol. So these days all the ZK proving is happening off-chain, so I'm personally supporting that idea. And for PeerDAS, I think it kind of solved the trilemma that you mentioned, But we still need to rely on super nodes, and super nodes should custody all those data columns. And without super nodes, it is very hard to reconstruct the blob.

So I think there's one point, some centralized point, on the PeerDAS implementation. So yeah. Yeah, I can also add to that on PeerDAS, that it's kind of the same thing when I see PeerDAS. I feel like a step on the way towards real data availability scaling. But from the start, PeerDAS wasn't supposed to be the ultimate solution to this problem, which is like a stepping stone. It just ended up being that we didn't really go too much further than that.

There were always plans to build, for example, full DAS implementation, which would be in some ways a more decentralized protocol for proving data availability, but it just ends up being that at the moment we are stuck with PeerDAS. However, it is expected that we will continue to improve this, and also outside of PeerDAS we have realized over time that there is a lot of value, specifically when it comes to proving the availability of block transactions in Ethereum, that these transactions end up being propagated in the mempool before they come into the consensus. So these days a lot of the efficiency of the peer-to-peer mechanism also comes from the

fact that we have already pre-propagated this data in the mempool, and this pre-propagation was utilized by the consensus layer clients, so they don't actually have to prove all of the data availability in real time. And I think with this we are pretty well covered. We feel like we have quite a bit of data bandwidth that we can improve. Awesome. I really like this talk, going into the very intricacies of the client. So my last question is on the future of Ethereum clients, right? I mean, we've covered ePBS, ZK, and then there are other interesting topics like post-quantum consensus,

Lean client rewrite. Right, so many things ahead for Ethereum clients going forward, and curious to know your… share your perspectives on how Ethereum clients will evolve in the long term, maybe like in five to ten years, and maybe the client that we call today might not exist in the long term, which can be seen as something completely different.

So I wanted to hear your thoughts on that. Maybe I can start first. So if I think of 2030, so it's like three years left. So ideally, we started targeting two hard forks per year, but I think it's not that practical, I guess. We can ship at least five hard forks until 2030. I think that we have a couple of big agendas here. First of all, it's post-quantum.

Google announced that in 2029 December, we are considering that moment as a Q-day, so the quantum computer can be deployed and trying to hack or break all those things. And from the consensus layer perspective, BLS signature, which the current Ethereum validators use to sign the message, is vulnerable in a post-quantum era. So there's a couple of discussions about how to deal with this BLS. So one radical opinion is that we have to get

rid of all this BLS signature and move forward to the other signature scheme, including hash-based signature. And this will require all this infrastructure changes, because we have all this BLS-based infrastructure at this moment. and we have to suggest validators or node operators to change all of their private keys into a new scheme. And the other thing, which I like better, is that based on the assumption that quantum computers cannot break the BLS signature in 6 minutes,

we can just provide transient post-quantum safety through the BLS. So there's a recent paper from Offchain Labs about reusing this existing BLS to be post-quantum safe. And I think that at this moment it's kind of better, because we can reuse all this infrastructure, and we can just add on top of the BLS signatures, and yeah, that's one of my two cents. And the other part of the big agenda is, I guess, formal verification. So there's a lot of attempts using Lean, which is a proof assistant language, and if we want to use formal verification, I

would say the specification should be formally specified. I guess there's a lot of bridge or gap between current Ethereum specs and formal verification. So there are some popular opinions about this, that we need to formally verify not the full stack of Ethereum, but only the partial component of Ethereum. So for example, we can formally verify the STF, state transition function, or we can verify a new consensus mechanism.

So I guess Luca has more experience with decoupled consensus, and there's a lot of time to write Lean spec. Yeah, that's my two big things, and personally I'm studying a lot to adopt these kinds of changes. So maybe coming back, I think it's good to back up more towards the philosophical question of what is the future of clients, also the longer outlook.

So I think something to think about is that Ethereum and Bitcoin as well, I would say, have started out as this architecture where fundamentally users contribute resources by running nodes. And we still talk about running nodes today. So it's like for running blockchain. And kind of over the years, what we've come to realize is that this concept of the node, it sits… it's a bit of a local optimum, because it combines a lot of functions into one thing, and people often doubt this, and then you say, well, the node should be split up and there should be multiple things, because the blockchain node combines like multiple roles into one thing, and then you can say, yeah, well, if you want to be an

Ethereum RPC provider, maybe you need a specialized RPC node, or you want to be a block builder, you need a block builder node, or maybe you want to in the future be this FOCIL inclusion list builder, maybe you need the FOCIL inclusion list builder node, but in practice these things often end up using the same resources anyways, so it's kind of… from the technical level it isn't that much different between all of these different roles, and it comes down to the fundamental access to blockchain history and the state. And especially in the execution layer, these two things kind of coincide in the node.

And as long as there are things relying on the Ethereum state, people will somehow have to acquire that state. And basically the only way to do that is to run a node. I feel like there is a future for Ethereum nodes because it just always hinges on these fundamental concepts. And yeah, you could try to build other solutions to get to this, but then it just ends up being that, because the node as we have it today, and it sits on this local optimum, we first have to kind of get out of this, and then maybe you can find some other solution, but it's way harder.

So I feel like we might as well just stick with what we have now for the next 10 years and just make sure people run nodes like they used to. Maybe with more optimizations or different things. And this is happening over time as well. The protocol is becoming more friendly to nodes, especially towards the state-keeping nodes, I would say. So a couple of years ago we launched the Snap protocol in Geth, which is kind of the way the client can download the state when it starts up instead of re-executing all the blocks. At the time there was a huge performance boost, and it still is. And now the next part, that is hopefully going to go live very soon, we have the next version of that protocol built on some of the features that are now available inside of the consensus,

like the block access list, BALs. And so this means that I think over time we will just keep optimizing the protocol to make sure that people still can run nodes with somewhat reasonable hardware requirements, and this is for us, and I feel like it's going to be useful in the near future. Yeah, I don't have much to add. Also because I don't feel much authority discussing clients, because I've never properly worked on clients, and more on the research side, what you can see is a pattern of moving from re-execute everything towards verify everything.

So, you could imagine future clients could be just verifying things rather than enabling re-execution, like, for example, we saw in ZK proofs, and also there are discussions about post -1 2 3 4 5. So what I can see is this pattern is moving towards verification, verifying everything. So this is probably where I could imagine going towards. the bottom of the panel. Thank you.

I guess we are running out of time. Thank you all for the great discussion. From all players' point of view, I feel like the future of Ethereum clients is very bright. So thank you all for working on the clients, and I guess that's it for this panel. Thank you.