Deep dive into Native Rollups - Spec & Implementation

Transcript

Thanks for having me up here. Today we will demystify native rollups both in spec and implementation. I'm Gajendra Singh and I run Zeem. And we'll basically look at native rollups in the context of current L2s and also look at the L1 L2 interrupt. And then a bit look a deeper dive into spec and EIP. And if we have time maybe a little bit of POC, but uh I'm not sure whether the video will work here or not, but if it doesn't we'll put it on our Twitter channel.

So Zeem is a team running out of India having uh people from all over the world working for it. And we are on a mission for linear Ethereum. And we are doing uh uh very great. We are doing very well. And uh now coming to the main topic. So that was a little bit of self-shilling. And uh we will now take a deeper dive into native rollups. So if you [clears throat] look at the straw map, you have native rollups at L* and uh but for that to happen, you need to have mandatory proofs and you need to have canonical gas which is happening a bit before.

And but even before that, we will quite uh soon have optional proofs which will basically enable all the experimentations that you can do on optional proofs to build native rollups. So uh for scaling Ethereum, we have gone from proof of work to proof of uh stake and now we are trying to transition to uh zero-knowledge based rails. But what we want to do it natively. And what I mean by that is that you already know we have three layers. We have execution, data, and consensus.

And what we want basically to achieve is we want 1 giga gas per second on execution. That means 10K uh transactions per second. On on the data layer, we want 1 tera gas per second which is 10 million transactions per second. This is where native rollups will sit in. And uh so what we want for native rollups, which is different from the current uh rollups, is we want them to get the security that Ethereum has, finality that Ethereum has, and the censorship resistance that Ethereum has in a very native way.

Which basically means that it has to inherit L1 consensus. And it will reuse L1 proofing infra. And it should uh compose with L1. So there should be synchronous composability. So just if if we just want to compare why native rollups uh is a bit better than the current design of rollups that we have, you can see that trustlessness and scaling are the two things where basically the two design collide. Uh but what is happening is that native rollups is a bit better at every other place like censorship resistance, decentralized governance, and node ops.

Apart from fancy execution, which is why you would not do native rollup and do your own rollup, composability and upgradeability, native rollup really wins. And we have the meme. So let's look at the interrupt between the two layers and then we basically get to see we come to come to the specs. So you know how L1 works. Producer creates a block. There are attestations. Uh so the next producer builds on top of that.

And for for a rollup basically, you have a sequencer that is creating blocks at this particular time and it is importing the messages that came from L1. And then it is batching up and committing its batch block to L1. So it has its own consensus going. Uh see it would be a little bit similar for native. Uh but there won't be a separate consensus. We want L1 to be the beacon for native rollup. So the way typical L1 to L2 anchoring happen is basically, you know, when you talk about rollups, all you are concerned about in essence is how you how you import

uh deposits from our from L1 and then how you uh send the withdrawals back. So for deposits basically, whatever uh there is a contract on L1 which basically generate the logs. Sequencer picks up the logs and then it creates a uh L2 block and this is the anchor that I've circled that you basically need to provide this as a public information because that is something that L2 consensus will not be able to import by itself. So you need that to come as a public input.

So uh just be just because of this particular design, I mean, L1 event shows up on L2 in 30 to 60 seconds. It is smart it is small, but uh it is not instantaneous. And uh what what happens is that going back is even more problematic because what generally L2 does is they batch, they proof generate, they wait for finality on L1, and then only uh the finally funds are transmitted. And so all other things can still be, you know, optimized that you won't batch or you can basically have an infra that is running uh on an awesome hardware and you don't batch anything. So you match up your batches with the with the L1 blocks, but you still have this problem

where you wait for L1 finality and that is a consensus problem because the two consensus of L1 and L2, they are running separately. And this is something that we want to eliminate with native rollups. So from why now we'll transition to how. So So if you look at the current design of how L1 operates, you have beacon layer which basically then uh sort of calls EVM through execution engine and you have deposits that are going in, you have execution requests that are coming out. And what you want to do is you want to make this recursive. So you want this rollup contract that is sitting over there and you want it to recursively call EVM by sending in the messages and taking

them out. And that is what is being proposed will happen through execute precompile. So if we look at the EIP spec of the execute precompile, and I think it has evolved quite a bit, but it has not been updated on to uh on to the EIP repo. But what is really happening is uh you get basically get the data uh from from a transaction that we'll talk about a bit later and you provide this data and you pass it to get the chain block anchor.

You process the anchor to verify that the outputs, the inputs that are going to the state transition, they are correct. And then you do a state transition and with the output of the state transition are the outputs that you can return it back to L1 EVM. So So this particular function is being called by the L1 EVM. And at the state transition is where uh the new EVM is sort of instantiated and it executes and gives you back the input. And this particular uh uh spec that is currently in the EIP repo is based on that re-execution paradigm.

Because as we'll see later in the proof paradigm, things will change quite a bit. So in the re-execution, you can initiate uh initiate this particular execute precompile through an execute transaction. But this transaction doesn't look any much different from what other transactions are. All you need to do is all the builder of the L2 blocks, they need to pass of the native blocks the native L2 blocks, they need to pass stateless execution witness. And when this execute uh transaction hits the smart contract, you basically process it the way you want. So you can program whatever checks you want to do

on the top of all the data that you have got. You can add in your pre-state and then you can call call in the execute precompile. So you basically can make sure that the data the uh the uh data that you got is basically linked to the last point at which you call this precompile. So going from re-execution to proof where things become interesting and this is how most probably we will see this uh happening in this particular manner is that you don't need any of these inputs because they are the witnesses into the proof that the L2 block will generate to make sure the uh to when it's pass when it's posting uh the batching transaction,

which is basically the execute uh transaction. And what is happening over here is that uh so you won't even run the state transition. It will just the proof will just be verified not it and it won't even be available, you know, on the execution. It will be available and checked on the uh consensus layer itself like how it happens for the blocks. And what will pass on to the execution will be the input data root of all the inputs and the outputs. Even you know, you you won't be able to execute it. So you you won't even have the outputs. And that is where you will just get the input data root uh inside your EVM.

And since you are not running it, it just is a fixed gas. That is how basically you are scaling. You are with a fixed fixed amount of uh precompiled gas, you are able to run very big blocks. And the execute proof transactions will look something like this. You will have input proof root that will come into the transaction payload uh and then in the transaction payload body and in the network uh payload, you will have execution proof and that network payload never gets passed on to the execution layer for the peer. I mean, of course, the block builder will have it, but uh but it won't get passed on. And what you will get inside your L1 EVM is input

proof root. And what you will basically do is you will check this input proof root against all the data that has been all the outputs and the inputs that were supposed to go in and all the outputs that have been posted to you. So, you will basically verify it and then you will say that yes, this is a correct uh execute uh transition. And there is a POC by ZK EVM and Ether X team on it. But uh what we did uh we did the POC in the re-execution model because what we wanted to do were uh was basically check uh how the money was flowing. Uh so, if basically you you are So, the way we are running this is you have

an L1 uh that is basically uh hosting this stateless roll-up. And uh and and you you have transactions that are going over there, which basically you want to send to L2. Those are uh those logs are listened to again by native sequencer. It should be native builder over here because it's no more sequencing. So, it it basically listens to all those logs. It sends it It basically can then send it to the actual uh L2 instance that builds it for the native builder and then it basically sends it back to the execute transaction with witnesses and deposits.

And then the precompile gets called and when uh so so, the withdrawals that are coming out from L2, so uh this is actually being processed by your smart contract. So, you can define at your smart contract level what you want to do with the messages that are going that are coming out from the from this particular L2 in L1. I'm not sure whether this video will work. Okay, so you must already be aware of this particular news uh that has come out that there is going to be an Ethereum economic zone and basically it seems like that it could be

actually be powered by native roll-ups and this is totally speculation on my side. Uh but what can what what can happen is that all these roll-ups, they they they will come and they will participate in and get synchro- synchronously composable. And there is uh one other proposal that is trying to extend native roll-ups by saying that you should be able to run any can any uh host that you want. There shouldn't be a canonical uh uh L1 EVM host that is out there. You should be able to supply your own host. That means that Arbitrum uh and then uh Optimism, they can basically provide their own host uh own guest program and you will be able to do the same thing

with them. Yep. Thank you. >> [applause] >> Any questions? Yep. I mentioned I lost myself like 10 minutes ago. I don't get like what my Yeah, it's not like a question. I just don't get it like what we are proving there. So, there is L2, there is L1, right? There is something happening on L2 level and then transaction basically I'm submitting already the root, right? So, if I submit different root than like I

what happens? So, basically it's based on my input, right? Yeah, so basically all this now is like a witness when you generate a proof. A witness of execution on L2. Right. So, this is for example generated by the L2 builder itself. The native uh builder will generate this particular proof because it has all the data with it. Yeah, basically on L2 I have some transaction, right? There was some execution and what I'm providing is the proof that this execution happened, right? And how how this proof looks like? What it proves basically? It's state transition only uh in specific address or So, I mean, for the purpose of this particular thing,

this proof is just bytes that get verified on the CLR itself. They are They doesn't even It doesn't even get passed on to the exec- uh onto the execution. So, EVM won't even have this proof. It won't even verify this proof. This is like how it happens for the blobs. But what will come to the EVM is the input proof root. So, so you provided the inputs. That is the problem that you're saying that I can provide any inputs and how will I verify it? So, you provided it the inputs and then you have the input proof root, which is basically what ties to those inputs and your smart contract uh should basically verify that this is the correct input proof root. Basically, all the inputs that are going into uh the state transition function plus

outputs right? So, those those are the inputs into the proof. And you will also you will and this data will supply you the outputs that you need to be processing. And you basically will then say that okay, I will look at my anchor. I will look at uh I mean, anchor is not even required. For example, there you can just be running a message queue and collecting all the uh logs by yourself directly in the smart contract itself. You will just say that okay, you know, the does the input to the proof pops out first 10 elements? Okay. The Do they match or not? And if, for example, there are outputs, you will basically then process the outputs because that that are the things that

you need to process now. Those are the withdrawals from L2, but what will happen is that you will actually match. You will say that I will do I will do a uh root of those things and they should match. And this is where how you will validate whether the proof was correct or not. Um regarding this um like can you go back to the previous slide or I think that was a previous slide with the the execution proof execution like you have got a state transition transition, right? Uh what happens when any L2 or even the uh actually not just the L2 uh upgrades their state transition function? We're going to have to update every guest program. We're going to have to update every uh

potentially every ZK EVM. Do you have a hunch of how the upgrade process is going to work? So, I mean, you're talking about the model in which we also allow uh uh you know, other L2 clients, right? To L2 roll-ups to supply the host program, right? Yes, so you will have to update that. So, those that host program itself could come as an input and this could verify the root of the host program itself, right? Because that is finally you have to So, there is an input root as as one part of the input, you can have the host program bytes, which basically then get merklized and generate a root for you. And this is the root that the smart contract will need to maintain and update.

Yeah, so there is that trust element over there. If you if you want to extend it, but of course, the canonical uh canonical host program is the best way to go about it. Um sorry, I arrived late to the talk and maybe I missed this part, but what is the purpose of the precompile? Is it to re-execute and generate a proof? No, the purpose of precompile is to actually in in the re-execution, it's to actually re-execute using the witnesses, using the stateless witness, but in this particular model, the precompile will basically take this

data. You So, you will pass uh So, for example, you will pass uh the anchor that you have received the inputs that you have received and the outputs you have received into the precompile and that will basically generate this input data proof root and will match whether this was the proof root it got in the transaction. So, so this is how everything gets connected. I mean, there is a lot of hand-waving over here in my you know, uh so, the way I have basically shown it because the spec is not totally updated as well. So, this is like uh from the current spec that we have at the EIP repo, but I think uh as we go along, things will get updated and everything

will show up. So, we have a working implementation on this. I mean, not we as a ZK team, but we as a ecosystem and we also have as a ZK team working implementation on using stateless uh model and re-execution model. Thank you. >> [applause]