Deep dive into Lean Ethereum - Spec & Implementation

Transcript

Hello hello. Welcome everyone. So, this talk is about lean consensus spec and implementation, and I'm Gajendra Singh. I run Zeem. So, we'll look again a little bit of peeling process, right? We'll do some peeling. Why lean? We'll then look at the work that we have done so far. Then we'll take a deeper dive into the components that make up lean, and then we'll look at 2026 plan. Again, a bit of shilling. We are global team running out of India.

And we are on a mission, and the mission is the lean Ethereum, and we are fighting on all cylinders. So, now looking at the straw map and coming to the topic. So, if you look at El Star hard fork, this is where we want to get to post quantum uh security. We have post quantum attestations, we have lean VM aggregation, we want to reset some tech debt, and we want to start introducing what end game finality over here. But, that doesn't stop over here. Then, after that, we want to do one slot finality, and we want to go to 1 million attestations per slot.

And then, we also want to take the post quantum work benefits to the other layers, data layer and the execution layer. Even though execution layer is a bit tangent to lean Ethereum, but things basically tie up. But, things also start quite early because we will have post quantum pub key registry very soon, and then we will also have post quantum heartbeat that will m- uh that will help us in finality and consensus. So, now coming to lean Ethereum. So, it is Ethereum on ZK rails.

And as we know, we have three layers. We have consensus, data execution. And what we want is post-quantum security. We want verifiability. That you know, anyone in in the world with a very low-powered mobile device can verify the chain. And we want censorship resistance. And that that's the base setting. Now, what do we want to do on top? We want to be internet's settlement layer. So, far that we need 10k transactions per second on on the execution layer itself.

And we want 10 million transactions per second in the entire L2 ecosystem. So, that basically corresponds to 1 giga gas per second execution layer and 1 tera gas per sec on the L2 on the data layer. And we want faster finality and inclusion. And on the consensus layer, we want 1 million attestations per slot. And all the benefits that we basically get for post-quantum security on the consensus layer, we want to take it to other layers.

And this is sort of a value proposition diff between the current chain and the lean chain. So, we we basically want post-quantum again re-hashing what we already talked about, fast finality, censorship resistance. We want to reduce the node complexity. We want to make protocol simpler. This is trust and verifiable complexity, which we want low, not just trust last verifiability. Trust last verifiable complexity is low, that means that the trust and verifiability should be high.

And we also want decentralized block building. I mean, even today in theoretically it is high, but we only have very few builders. And that is a property that okay, we are saying that we can compromise a bit on it. So, coming to lean components. So, there are three pillars that make up lean. Post-quantum signatures and SNARKs around them. And fast consensus. And uh optimizations and improvements on P2P network.

And when we are doing all those things, we'll basically uh it will affect the entire way uh the consensus runs. So, there will be a tech debt reset. We want to make the protocol simpler. Okay, and coming to what we have done so far. So, we have done devnet zero, which was just a start between three clients. It was just a warm-up using three SF mini. Then, in devnet one, post-quantum XMSS SS signatures XMSS signatures came in. We jumped to five clients. Then, we did sig aggregation in devnet two. At devnet three, we uh in we introduced aggregators role.

And we are 10 plus clients, but okay, some of those clients are wipe go to AI, but And our spec work for devnet four is complete. Basically, which is recursive aggregation across the attestations that are there so that uh the that the block size only has block block size can be really low. So, we don't want that attestations which have same data to have different which are still across the subnets to basically, you know, be packed differently.

And in devnet five, what we are planning is recursive aggregation across block, which basically means that the block will have just a single signature. There won't be many signatures, for example, even today. Uh if you see if you look at the block, attestations have their own signatures. And then, there is a block signature and whatever if there are other signatures, if there are other objects packed. So now in Devnet 5 we'll just move to one single signature for the block. And Devnet 6 and 7 is something that we are yet to decide, but I'll talk about it towards the end.

Again look now let's look at post quantum. So for post quantum we have selected XMSS which is a one-time signature scheme. And what really happens is that you have these one-time keys and so each of these are one-time keys and you basically drive a public key for for all of these keys you basically generate a sequence of these keys till whatever you think is the lifetime of your validator. You get to the leaves of this tree and then you do a Merkle tree and basically the root of this Merkle tree is your public key for a valid validator.

And verification and so and aggregation of this will happen through SNARK. This is hash-based signatures. So BLS keys have a more elegant in terms of aggregation and verification, but that is not the case over here. And that is why we will basically do them through Lean VM. Something on Lean VM that will talk about that. One important thing to mention is that this signature scheme has been improved by some optimizations. And there is a paper top of the hypercube if you want to look deeper into it to make sure that we get a very secure post quantum scheme.

And coming to the aggregation part, so Lean VM is the VM that will aggregate these that that is actually aggregating all the signatures. It is a ultra ultra risk five that there are only five instructions that five instructions in the set and we are using Poseidon one. We are earlier we were using Poseidon two, but we shifted it back. And we'll be we are basically doing recursive aggregation on top of it. And the aim is to have this lean VM formally verified.

Dark and we don't want to basically say that okay, you know, if you are doing aggregation, you need GPUs. If you are an aggregator, you need GPUs to run. So, CPU is still the target. And we want the final size to be produced so that we can to be less than 1.5 KB so that, you know, we can just use a single packet to transmit them. And once we do all this for consensus, we take this to data and execution. So, looking at consensus, currently we have the consensus on beacon which has this which is basically Casper. Uh there is LMD ghost running and then there is a finality gadget. But, uh the

problem with this is that it is tightly coupled causing some of the issues and some of the ways we can't reason about edge cases. And uh it basically runs on epoch. So, if we want to do faster finality, we can't have epochs anymore. So, so here we basically want a two-layer fully decoupled consensus protocol. And this image is from Jan's presentation. But, attribution will come later.

Uh So, what what is happening is that you want an available protocol and that basically you you you and then you don't want to run a finality gadget on top of it. So, so you want fast available chain and decoupled finality mechanism with substantial stake security. And what about 3 SF what we are currently using? So, it has fast confirmation and KD confirmation. And it has 67% stake base finalization mechanism.

But, it is still coupled with block production and we want to do one slot finality, so it's not good enough. And here comes attribution uh to Jan. And so, what we actually want to do is we want an availability protocol uh called Goldfish, which is basically a heartbeat of uh randomly selected 512 validators who will basically do this uh do this heartbeat and those are uh selected every slot.

And then, uh we have a finality gadget running on top of it. So, Goldfish will be used to select the available chain. And finally, the votes will basically be counted and the finality gadget will give us finalization. Yep. So, this is the explanation of how Goldfish works and I suggest uh you you look at Jan's presentation for further further getting deep down into the how consensus is going to evolve.

And this is basically the basis for PQ heartbeat that we talked about in the straw map. And it doesn't need aggregation, so we don't really So, we want to eliminate the time between vote vote and fast confirm. We don't want to add an aggregation layer on top of it. But, it's just 512 votes, so that's fine. And then with LM LMD Ghost and finality gadget, you will have your consensus. Coming to uh P2P gossip, so so, let's look at the objects that are there uh in the lean consensus network. There is attestation and PQ heartbeat.

Basically, the objects are similarly sized. So, it's basically an XMSS XMSS signature, which is 3 kilobyte, but we can decouple it into two halves. You have You saw the tree. So, basically, if we send a signature separately, which is basically the leaf uh mapping onto Yeah. So, if if we basically send some message when it's signed, it gets mapped onto these hash chains. And if you basically send that only and you decouple this tree and send it separately, basically, you can fit it

in a single in a single network packet, which is basically uh what we want to go for. And all these attestations, they are uh they're happening at their logical subnets. And what we want to find is a fastest path to the aggregators. Coming to aggregate, so what what aggregators are producing, uh so, which basically are lean VM proof, and they are roughly 3 kilobytes. And uh we want to again target them uh to a proof of 1 kilobyte. And it is possible, researchers are working on it.

And then we want that they are So, so these aggregators, they are at minimum hops to every validator that is out there. And then we want uh so, then they are blobs, but blobs are already sort of being worked on the beacon layer, and that is something that we'll piggyback from them. And on the blocks, again, we there is a single aggregated proof for everything, so that we minimize this signature data. And eventually, we want block in blobs. Uh and this uh, this aggregated proof is basically 300 KB. When I talk about this aggregated proof, I not only mean the proof of signed attestations or the block

signature. I also mean that the proof of the validity of the block, for example, which ZK VMs will verify and produce the proof. So, that is why this is 300 KB because entire proof will be of this particular of this size, which will just validate your block. And which will which will just not only validate execution, but also the consensus and all the objects in it. So, again, the emphasis is trying to get to the single MTU unit. And you so that we can use datagrams and quick.

We are already using quick on the current uh, uh, libp2p layer. And should we transition to an app-aware eth p2p for the reasons that we can pipeline uh uh pipeline traffic per duties. We can do some source-aware peering so that um, aggregator can be, you know, very much connected to most of the validators. And uh, we want to remove the next slot bidding. So, if you don't know about next slot bidding, what happens is that gossip objects of the previous slot are still being distributed in the current slot.

So, that is uh, what is next slot bidding. And we want our NLC type encoding for big objects like uh, block and blobs. Eventually, block will also come in blobs, which is the long-term plan. So, in the end, everything is blobs. Now, coming to our plan, uh, so we are we basically have are at the devnet four uh, testing stage because the spec is done for that. And for devnet five, um, we are basically doing spec.

Looking at Devnet 6 and 7. Uh we want to uh do the consensus protocol that we talked about. And we want to do uh and we want to start introducing the P2P uh layer optimizations. And so this uh so the 2026 goal is to run 10,000 validators in a long-running Devnet. And the stretch goal is to basically have a public testnet. But that also means that we'll need to integrate deposit and execution integration. So this is sort of a stretch goal. But once we have that, we'll be able to launch a public testnet where people can come and they can start deposits they can do

deposits uh get their validators activated and just join in the network. Thank you. Questions? Yep please. So um I'm not 100% sure if you have mentioned it in this presentation, but um with current layer twos of Ethereum, you have like zero knowledge proof protocols, right? Um and they far of all facing the challenge that they have very slow finality.

Um how does lean Ethereum is going to tackle both problems of having zero knowledge proof and fast finality? You should have come to my yesterday's presentation which talked about native rollups. So where I just basically discussed the problem over there. So when you talk about L2s, so so there are objects going into the L2. And the problem over there is that, you know, for example, there is a block that is produced on L1, then uh it takes sequencer L2 sequencer a bit of time to detect those logs and build a transaction that they commit to the L2.

So, this layer is still fast. Like they take 60 seconds. But the reverse layer is extremely poor because not they batch for hours and then they generate batch proof for uh proof for hours and then they wait for finality on L1 for which might take 10 minutes, 15 minutes. And then they release, for example, the money. And this is for non-optimistic rollups, right? Optimistic rollups will wait for 7 days instead of finality for the fraud proof window to happen. So, if you if you want synchros synchronously composable uh rollups, basically you need to go to L2 L uh native rollups, which is which will happen, I think, around the

same time in L-star. Yeah. Yeah, thank you. How How do you do the signature aggregation? Is it same as post-quantum or Yeah, so basically there is Lean VM and a smart post-quantum SNARK is generated. So, if you want to get into details of Lean VM, you can basically go into Lean Ethereum GitHub uh organization on the GitHub and you will get Lean Sig. And then you will get Lean Multi Sig. Lean Multi Sig is the one that is doing

aggregation. So, you can look deeply into it and uh check how it's being done. I mean, it's totally out there. Mhm. Hi. Uh I'm wondering if we use native roll up, of course, it will make uh confirmation faster and actually give a better security guarantee. But uh will that also means uh like a validator on the Ethereum mainnet need to uh have the to do much more like data availability samplings uh before because now uh some layer tools they can use other data service, right? Uh but after the native roll up, actually all the data will be directly put into the blob

and the assume the validator will need to when they re-execute the uh layer tools state transfer, they also need to do the data availability sampling. Will that actually increase the cost? Data availability sampling uh is basically when you're posting your block right? So, you're posting your block because you want the data to be available. And that So, I mean when I say block we are posting your block, you're posting your L2 block, right? So, you have created a batch and you want when you post when you are basically confirming that batch on L1, you want to spread that data out we that is data

availability. At that point you can still say that, okay, you know, I can use any DA layer, but if you want to finally settle, which is basically providing the proof of your L2 batch execution, right? You can still uh do it directly uh directly through this particular particular layer, right? You don't need data availability to post your proof. I mean the proof itself is like could be 300 kilobytes, but if you just use call data, you can still do it.

And when native roll ups will come in, basically what will happen is again the proofs will be validated at CL level and those again might flow as blobs. So, all those things will be optimized as such for native roll ups, but if you are not already a roll up base, you need to take care of all these things. >> All right. Thank you.