Execution Sharding Through Native Rollups | Luca Donno - L2BEAT

[music]

All right, guys. We are back. Up next, we're going to be talking about execution sharding through native rollups with a real heartbreaker from L2 Beat, Luca.

Thank you. Um So, hey everyone. Uh I'm Luca. I'm head of research at L2 Beat, and I'm also leading the native rollups effort. Um And I want to talk today about execution sharding.

I'm sure that some of you uh might have some PTSD uh when they hear the word sharding. Uh but, you know, it's interesting stuff, and it might be time to to talk about that uh in the Ethereum uh space. So, I already gave a couple of presentation about native rollups in the past. Uh one at Bankless Summit in Buenos Aires, which was kind of high-level and motivational on why we're doing this. I gave another one at Devconnect uh in Buenos Aires.

Uh at EthPrague's Day was a bit more technical. So, I already talked uh about native rollups um quite a bit. So, today I wanted to try something a little bit different. I wanted to uh kind of explain uh native rollups through the lens of execution sharding by presenting a comparison between the sharding approaches of uh two other uh ecosystems. Uh in this case, in NEAR and Polkadot.

Uh because these are two blockchains that on production already have sharding. And Ethereum doesn't, right? So, in particular, I've analyzed uh Nightshade uh 2.0, which is the sharding protocol by NEAR. I've been reading uh quite a bit the wiki from Polkadot.

And now, from the Ethereum side, we have the rollups and the and the native rollups, which I'm which I'm working on. And also, one reason I'm doing this is because I feel like uh we should spend more time uh as an ecosystem looking at other ecosystems instead of you know just seeing them as competitors because they're building cool stuff and this stuff is cool. And disclaimer, I'm very familiar with Ethereum, I'm very familiar with L2s, I'm less familiar about this ecosystem. So I spent some time reading about them. I'm sure I will say something wrong, but hopefully it's not too far.

And also one motivation on why I'm giving this speech is because when I made this tweet about the native roles of CAP, Polkadot retweeted saying "Hello Polkadot 2020." So I kind of felt like this talk is a bit unfair because I'm talking about Ethereum like future stuff that we'll implement while comparing it to stuff that's already in production. But since Polkadot made this tweet, I kind of feel justified to do it anyway. So what is sharding? Sharding, at least in the blockchain context, is born from the idea that nodes should not all perform the same tasks.

But with guarantees as close as possible as if they do. So today in blockchains all nodes do the same thing. Why do they Why do they do the same thing? For good reason because we want to give them all the same security, right? We want all of them to keep up with the chain, execute transaction, maintain the state, and so on.

But the thing is that of course this is inefficient. So if you can do better, if you can shard these roles so that some nodes can do less with the same guarantees, that would be better. Um There are three main tasks that nodes perform in a blockchain. They execute transactions. And they execute transactions because they know they need to validate other blocks are valid, right?

Um Nodes maintain the state because if a transaction touches a piece of state, they need to know what is the state, what are the values, so they need to be be to read the state, and they participate in consensus. So, the you know, we might think about sharding these three things, but consensus in particular is the thing that you don't want to shard. Like consensus is one of those things that the more nodes you have that participate, the more economic security you have within a single network, the better. And all these three blockchains, Near, Polkadot, uh and Ethereum and others do agree on this. Um in the sense we want to have multiple execution environments where we want them to share the same consensus.

The stronger the consensus is, the better. There is actually one ecosystem that disagrees with this, uh which is Cosmos. Uh they have, you know, all different uh chains with their own consensus, uh which, you know, arguably is bad because um it becomes easier to compromise one single chain. Because again, everyone has his own consensus. There is this famous famous example of Chihuahua chain in Cosmos that has like a few tens of thousands of economic security, which is supposedly easy to compromise, uh if you want to try.

Um But yeah, consensus is the thing that you don't want to shard. One thing that you can shard is state. Um and this is uh feasible. Like both the Near and Polkadot already uh do this. Not every node maintains the state uh because they have stateless execution.

Uh we tried to do this uh in Ethereum, we're still trying. Uh it's difficult for many reasons. Uh there is a conference in ECC in Cannes, uh if you want to attend uh regarding uh stateless in Ethereum. Um but like this is possible. And the idea here is uh a node doesn't maintain its own state.

Uh if it wants to execute a transaction, I will also give the node uh the information about the state. And the node can verify that the state is correct with a Merkle proof or a Merkle proof or whatever against the a Uh so, this is feasible. Sharding transaction execution is the difficult part. Like, both in NEAR and Polkadot uh nodes um either execute transactions or don't. And the ones that don't do not have uh validity guarantees of those transactions.

But, I'm going to talk about this. But, the the thing I want to keep in mind is that um sharding execution is hard. So, what happens in NEAR? NEAR has nine shards. They call them chunks.

And they call them chunks because uh they're all synchronized. Uh they all have the same block times. They're all identical. They have uh the same state transition function. They do all the same things.

Block producer Block producers are chosen among validators, which means uh they're picked, they're elected. They have some time to download the state because if you're a block producer, you need to have the state. And then they they produce the state transition with the uh stateless uh execution. They send it around. And nodes need to re-execute.

Uh but, the thing is that not all nodes re-execute. So, NEAR today has 384 validators. And in each chunk, uh there are 105 mandates. And a mandate um is a certain amount of NEAR token tokens. And if you have if you're a validator and you have more stakes uh more stake, you will get more mandates.

So, for example, one mandate is this 500K NEAR. The top of validator usually gets 55 mandates. And for each chunk, um you need 71 mandates to sign that the block is valid. If you reach uh 71, the block is considered valid by everyone uh in the network, right? So, if you get uh 71 mandates that are malicious, like validators that uh you know, they're malicious that reach this threshold, the network will finalize an invalid block.

And the other will not notice even because they're not executing, right? Uh I did some math uh given the current distribution uh to reach 71 mandates, the median uh is 24 validators. So, if you have 24 validators uh in the same committee, uh you might be compromised. Uh the chain might be compromised. They do some math and they say, "Look, uh if we take the 1/3 threshold for, you know, BFT tolerance and these are malicious, the chance that you get these malicious nodes within the same committee is like super low.

Uh they did the math with 800 validators and four shards. They have less validators and more shards. If you actually do the math with the current distribution, um the math is worse. Like they say, "You will compromise the blockchain in 1 trillion billion years." If you do the math with the actual numbers, it's much worse.

And the thing is that it it is exponentially worse the more centralized stake is. Next is Polkadot. Polkadot has parachains. These are not all identical. This can be custom.

You can uh have your own state transition. Um that you can you can publish. Uh this is very similar to rollups. If you go to Wiki, the Polkadot Wiki, they're trying to rename parachains to rollups, which is funny, uh but it is uh correct. Uh they have custom governance.

Uh they have custom block production. You can define uh within the state transition function who can sequence. They call them the sequencer are called collators in Polkadot, but they are sequencers. Um and they do something very similar to NEAR. So, instead of having these 105 mandates, they do a first pass with very very few validators, just a two out of five validators check.

This is the first pass. So, these five validators are elected. If two of them say the block is correct, uh then it goes uh through. Um so, this is like super small set, but um they are an improvement over NEAR in the sense that uh they have a dispute mechanism. So, you can think about parachains in the same way that in Ethereum land we think about optimistic rollups.

If there is someone that noticed that something is wrong, it can raise a dispute. And if there is a dispute, all nodes in the network need to re-execute to check whether the thing was correct or not. In practice, what happens in the happy case is that uh there's this first pass with a 2/3 of 5, then you need these checkers um that are um you need the 30 confirmations. Like you pick at random 30 validators, they need to re-execute using stateless execution. And if they confirm, the block gets included and it gets finalized.

Um so, also here you have a risk whether these, you know, 30 validators that are elected are malicious and they all confirm uh even though the block is invalid. But, again, uh it is an improvement over NEAR in the form of we have a dispute mechanism so that if someone noticed that something is wrong, they can raise the dispute on chain, everyone sees the dispute, and everyone needs to re-execute. Actually, in the NEAR white paper, they mentioned this approach and they say, "We know that this approach exists, and we decided not to implement this because it adds a lot of complexity and it might not be worth it." Um which is understandable. Also, because these disputes created problems in Polkadot.

So, in 2023, uh they had what is called the dispute storm. Basically, they had an upgrade and a node didn't upgrade, or at least they did upgrade their node, but they didn't restart the node. So, they were using the old state transition function, and it started um launching disputes at all the blocks because for its perspective all the blocks were invalid. And this caused, like, loss of finality. It took, if you read, 12 hours to recover the network.

Uh, the network was overloaded. So, like, this happened again in 2025, uh, for the same reason, more or less. Uh, some nodes didn't upgrade. But, what I'm trying to say is, you know, in blockchains, um, regarding validity, uh, and, you know, even in NEAR, right? Like, they did the math saying, "We use the, uh, BFT threshold, which is 1/3, and we say, okay, what is the probability that, uh, validity is compromised if this amount of validators are compromised."

Usually, like, today on Ethereum, the property that we get is that even if all validators in the network are compromised or malicious, a node cannot be convinced that an invalid block is valid because the node will re-execute. So, even if 100 validators are malicious, you will not fool a node with an invalid state transition. And Polkadot understands this, I'm sure, and that's why they introduced disputes. Uh, because they don't want to have this issue that potentially NEAR has, where a minority can compromise validity of a network. Uh, but if the thing is, you know, they want to to get the same guarantees, but given the dispute mechanism, if just one node, a few nodes don't upgrade, you get these issues, right?

Uh, they did some improvements, of course. Um, so, I'm sure that this is not such a big deal. Uh, but in any case, you know, um, this stuff that adds complexity, and we know also optimistic rollups are, have a lot of, um, problems. I gave a talk in the past in Bangkok, uh, about this. What about Ethereum?

So, Ethereum, they call them rollups. They're custom. We have many roll ups. You can do whatever you want with them. They have custom block production.

Everyone has its own sequences and they can be they can either use custom or native governance. So custom is what happens today. Everyone can upgrade. They have some doubts or some multi six that can upgrade. Native governance is what native roll ups would introduce.

And the idea here is we have L1 with Sony VM and the L1 will move to ZK and we can convince like we can expose the ZK's infrastructure to the roll ups themselves so that they use the same state transition function. If L1 upgrades, the L2 will also upgrade automatically without having to have a custom governance. So that's kind of what native roll up means. And the difference between like what Ethereum is trying to achieve with these roll ups and native roll ups compared to the others is that we want to maintain the feature that everyone validates all the transactions in all the roll ups in all these shards. While the others, you know, all these certain nodes are convinced about the validity of the network.

We want everyone to do so and we have over 900,000 validators. So this is a really big task. What is the trade off? The trade off is ZK proofs are super complicated. They're very complicated.

They're buggy. And that's also yeah, like it's a it's a it's a trade off that we need to be careful about. But it's super exciting. We would need we would be able to maintain the property of you will never be able to convince a node about a malicious state transition function. I don't have time for this slide.

This is the work that I'm doing on native roll ups. Scan the QR code if you're interested in in what's coming. Thank you.

[music]