Lightning Talk: Native Rollups by Luca Donno, L2BEAT

Transcript

When we started this whole ETH Bruce experiment, um we would sort of use a very quick shorthand elevator pitch, I guess, to like uh uh paint the picture with people when we were onboarding and like having conversations and we'd always say, "Eat proofs, think L2B for ZK VMs." So it's really really cool to share the stage with a couple of main contributors to L2 beat. So first of two talks backtoback we've got Luca Dono talking about uh native rollups.

[applause] Um hey everyone so I want to talk about native rollups. uh I don't have enough time to uh discuss the technical details but I just want you to uh I just want to present why I think they make sense from two different perspectives. So the perspective number one is the perspective of uh we want to scale Ethereum right. So if you look you know at everything that has been said and if you're kind of familiar with roll-ups um you can see all this scaling effort uh with ZK on L1 as a way to basically turn um Ethereum into a rollup right um if

you look uh in the way that a Z rollup works today. What a zucchinoper does is this, you know, off-chain infrastructure that has its own state uh executes some transactions offchain. It proves those transactions and sends um a state route with a proof to um to L1 to an the execution layer of of Ethereum, right? And if you look uh on the other side at what L1 does is that you know we're taking the execution layer we make it an offchain components uh we execute transactions we create a proof we send the state route uh with the proof to the consensus layer. So um you know I haven't seen this uh narrative very much but in my opinion again the ZKL1 effort is a way to uh basically turn Ethereum into into a

rollup right so now uh if we do this uh what's the what's the limit of the scaling and um like probably with this effort we can get to uh the gigas uh but the thing is that you know why stopping at at the gigas maybe we want to get to uh teragas per second Okay. And the only way to do this is with horizontal scaling. And we've been discussing uh you know how rollups help with horizontal scaling. Uh how we can use ZK to vertically scale and and roll up to do the same. Now that L1 basically becomes a rollup. Uh a way that you could think about this is basically okay what if we run like multiple chains in parallel and then

like settle all these like ZK execution uh layers. uh you know we run them in parallel and we settle them on the consensus layer. So this is like a classic Zard approach. Uh it's kind of complicated in my opinion because now you need to think about a consensus layer that needs to coordinate multiple execution layers. Um how do they even communicate together? You know you need to figure out some messaging system. Uh some people might have some uh PTSD from uh sharding uh because of this. uh but like some blockchains actually work um do sharding already in production this might be viable but in my opinion it's complicated another way is instead to use uh the rollup infrastructure that we

have today so uh you have one single zk execution layer this is a one that gets snarkified and then you have uh on top of the execution layer the zik rollups and this is basically what is already happening today right um you might say okay but this is not really sharding because they need to provide their own infrastructure their own proving system they're a little different they don't upgrade at the same time and the solution to that is exactly uh uh introduced by native roll-ups. So the idea behind native roll-ups is okay let's take this zer infrastructure that one uses it one already uses and let's expose this uh [snorts] to the roll-ups to users. So instead of having to deploy your own proof system um you can just use uh the exact same and this can be

done by exposing the L1 state transition function to the execution layer uh through a pre-ompile uh which we'll call the execute pre-ompile um and in practice the way that this will work is you know uh on L1 you have an L1 block this L1 block contains transactions this transaction will call a roll of contracts the rollup contract will call the execute pre-ompile compile and inside the execute pre-ompile there will be this recursive call to the state transition function which is the same one that Ethereum uses and um what the L1 prover will do is that it will prove everything uh up until like even inside this execute pre-ompile up until this state transition function call and then

everything that happens uh afterwards and the transaction sender which is in this case like a roll-up operator um will um will provide a zika proof uh when when calling this uh when sending this transaction. Uh can I toggle this? Yes. Okay. Um the second perspective is a little bit different. So the first perspective was about uh scaling L1. The second perspectives comes from the rollup, right? Um so what are the issues that existing rollup face today? The first one is that they spend a huge effort in building the proof system and

maintaining this proof system versus you know uh like alter one competitors that don't don't do this. So if you need to decide today whether you want to deploy an L1 or L2 uh the problem that you might have if you want to deploy L2 is that you have all these additional infrastructure that you wouldn't have as an L1 and this you know uh it's a lot of effort that you are spending toward this that you would rather spend towards user and and products. Uh the second is that this increased complexity uh is a source of bugs and this doesn't allow you to get rid of security council. So a reason you might want to be an L2 is because you want to be more decentralized. You want to prove your state transition. You want to have a secure bridge. So all good intentions, but at the end of the

day uh because of risk of bugs, you might need to have a security council uh that actually make you uh less decentralized. That's what you want to be, right? even less decentralized that alt once potentially and this is you know something that alter ones love to say you know that L2s are bad because of security council I've been talking also with some of the roll-up teams here uh and they telling me like stage two may be too realistic um because again it's might be too unsafe to remove the security council I feel like this is super sad uh it's super sad also because I might agree with it uh so uh and and the third problem is now you want to be in an EVM equivalent chain And you need to upgrade every time Ethereum upgrades.

You also want to to do the same upgrades. And this requires dedicated governance systems uh just to maintain feature priority. And then uh you know these governance systems can arbitrarily diverge from L1 potentially rugging funds, right? Uh so this also adds complexity and and trust issues. So again the idea is um what if instead of doing all of this uh you could uh reuse the same infrastructure that one uses um some rollups might uh object because you know uh instead of having to reuse uh the same infrastructure they might like actually building proof system and having their own stuff. Um what I argue is what if instead you know

instead of uh everyone that does its own thing we all converge into you know making Ethereum better and you know proving Ethereum blocks and then afterwards uh we let everyone reuse this infrastructure. Um so again the solution is the same right you take the infrastructure that is on one this is the same slide as before you take this zification uh stack and you expose it to the roll-ups to use as a pre-ompile and this would for example allow uh rollups to have uh client diversity uh multiproof systems uh automatically right so again the first issue is solved by reusing L1 components you don't need to maintain your own dedicated stuff uh you don't need security council because uh Again,

this is a dependency that you already have on L1 and if there is a bug, uh L1 is going to fix it and you get automatic upgrades with L1. And this is uh an example of how much simpler uh rollup is a native rollup is compared to like for example LP stack 64 lines of code instead of 10,000. Um I finished my time. Um but if you're interested uh on the details uh there is this native develops book explaining all the details how this work uh customization that is possible and yeah thank you very much.

[applause] All right got a couple questions here. So what security concerns are you mo most attentive to by introducing the execute pre-ompile? So the the good news about the pre-ompile is that uh it is possible to reuse the exact same infrastructure that L1 uses at even at the level of the same verification keys. So same verification keys the same the state transition function that the L2s would use is exactly the same uh same exact proven networks. So in principle you know if we implement this correctly uh there wouldn't be um much additional risks

compared to 121 itself. So I wouldn't say there are uh many. >> And then uh how does this how does the introduction introduction of native roll-ups reconcile with the fact that roll-up teams are looking to introduce more features that deviate from EVM execution. >> Amazing. So this is the slide that I skipped. Um so the trade-off is for native rollups you cannot add new op codes. You cannot add new pre-ompiles because again we you we would be using the same statization function that one uses. Uh but on the other side everything that is outside of the core EVM uh statization function can be personalized. So you could it is possible to support custom sequencing.

It is possible even to support custom guest tokens. It is even possible to collect the base fee like there is an easy way uh to because you know L1 burns the base fee. L2s actually want to collect it. There is an easy solution to do this even without modifying the state transition function which is super interesting. Uh so there is some form of customization that is possible. Uh but of course there is a trade-off. >> Uh and then finally how confident are you in getting native rollups implemented into a hard fork. >> Um I'm pretty confident. The only issue is like timelines. I need L1 to be aware of Zika proofs because I need to reuse the same infrastructure. Ideally, I need L1 to use blobs for its blocks because again L2s use uh blobs. Uh so there are

a lot of open questions around for example uh gas metering when you're using blobs instead of cold data and uh all this stuff. The good news is uh basically I'm just uh a native rollup would just steal or like reuse the same infrastructure L1 users. So, uh, I'm just dependent on the ZKL1 timelines. >> Awesome. Thank you very much. And if you guys haven't had a chance, check out Ethof's call number five where Luca does a very dense, deep, I think 60-minute long deep dive into the technical details of native roll-ups.

>> Thank you. >> [applause] >> Okay.