Introduction to Based Rollups and Based Preconfirmations - ETHGlobal Bangkok 2024

okay think I can start um hello uh this talk is about introduction to based rollups and pre-c confirmations my name is Leno shitani I'm from nethermind research okay so in this talk I will go over base rollups and pre-c confirmations what they are I'll give a quick intro and then I will talk about our Tyco pre-confirmation POC work to give like one example of an implementation of a base pre-confirmation solution so before starting let's think about what are rollups exactly so rollups is a technology that scales ethereum by posting transaction data to L1 but executing them in L2 so by not executing them in L1 you get the scale so in other words you can think of it RS at this so you put L1 blocks the L1 blocks contain the L1 blocks L2 blocks like this so in the L1 block you have a bunch of these L2 blocks within them so the big question in rollups becomes how do we build these L2 blocks and how we build the blocks is like a fundamental question in E research so it's only natural that it's being asked in the L2 context too okay so like let's see how most rups today work so most rups use centralized sequencer what they are is basically the user will send their transactions to a centralized sequencer like this and then the centralized sequencer will sequence the L2 transactions and then eventually build a bunch of L2 blocks and then submit the L2 blocks to the L1 block boom Pipeline and eventually these L2 blocks will be included in L1 block like this and like like centralized sequences are very nice most notably they can provide pre- confirmations so what are pre-c confirmations okay so pre-confirmation let's think of this like this user is submitting a transaction transaction C to a centralized sequencer now what this sequencer can do is that they can provide a pre-confirmation and what they're saying is that it's saying that I will promise you so like you send transaction C to the centralized sequencer Central sequence immediately return this pre-confirmation and the user by looking at this pre-confirmation they can ex know exactly what the state of or what the result of their Alto transaction will be ahead of time and then some time passes and then eventually the centralized sequence will actually post this L2 block to the L1 and in this case they like prop L like holding the promise but the key thing here is that the user did not have to wait until this L2 block to be posted to L1 to know the result because of prec confirmations okay centralized precon uh centralized sequencers are nice because they can provide fast ux however they are centralized you have this like single point of failure in the whole system so that is not great so the big question here is how do we decentralize the centralized C and this bring brings us to the idea of based rollups okay so the idea of based rollups is this let's use the L1 block blue pipeline to sequence not only the L1 transactions but also the L2 transactions so now the and construct an L1 block that also contains these L2 blocks okay so let's L1 block bling pipeline so the user has sent their transaction out to the me mle and then the we call Searchers will like bundle these transactions so for example if you have a DEX trade the Searcher will insert an Arbitrage transaction right after it and construct what's called a bundle and then these bundles are sent to the Builder and then the Builder will collect all these bundles and then construct a block and they notice that this much and then they're all going to send bids to the proposer and the proposer is going to select the highest valued block and then propose it is not only for the L1 transactions that are like used blue here it's also Al used for the L2 transactions that are used in the red here okay these rollups have very nice properties like first they we inherit the o1 censorship all we have is o1 actors so we inherit the o1 security another ni thing is that we can get L1 composability this is because L1 and L2 transactions are sequenced by the same entity so this Builder part this Builder is constructing L2 and provide like composability guarantees So based rollups are very nice however they're slow so because we need to wait the L1 slot times for any form of confirmation so like the user to know what the result of their transaction is they have to wait until the actual L1 block is built then they look at the L2 blocks within the L1 block and know what the result of their transaction is but this takes a lot of time because you have to wait until the open slot times so big question here is can we provide pre-confirmation in this based setup and one thing to notice here is okay can the Builder provide pre confirmations and the answer is no the Builder cannot Pride pre confirm because they do not know whether they're going to win the auction in the end because a proposer is the one who's going to run the auction and choose the wedding block so the Builder is not sure is that a proposer does have the monly sequence right because they are the ones who's doing the final sign off of this L1 block so they're choosing what L1 block is going to be published and they have the final say on that so they do have monopo sequence right and they can provide pre- confirmations so the idea based pre confirmation comes from this insight and the idea here is that let the L1 proposers opt to provide pre-c confirmations so now like you have the L1 like same old block bilding pipeline but for the L2 transactions you can say that hey the proposer let's have the proposer like collect these L2 transactions and provide pre confirmations and then in then they construct the final block okay so like this is how Bas break confirmations work and here let me give you a specific example or implementation that we are doing at nethermind in collaboration with Tao Tao is a based rollup and at nether mind we are is this so during the proposer thought time the L1 proposer will construct L2 blocks from the L2 mle and every 3 seconds and publish them so the idea here is that this blue part it's still running every 12 seconds so that one blocks s time but the red part this pre-com part every 3 seconds the proposer will collect a bunch of transactions and then pre- confirm pre-c confirm them and then in the end like it's both of the L2 block transaction L1 blocks combined and it's buil the L1 block is built okay so let's get into a little more in detail so the sequence diagram that um illustrates how our tyo POC works and okay the first thing here to note is this AVS node that I write here this is a side car running alongside the o1 proposers and this side card will be responsible for the pre-confirmation duties such as registering to be a pre-con doing the pre-con publication Etc this the AVS node or the L1 proposer will check whether they're registered and whether they are like the selected the next going to be repeated many times so this until here until like uh this part and this part is going to repeat it every 3 seconds during the 12 second window and what's going to happen is that the AVS the users are going to send b send a bunch of transactions to The Tao Network The Tao P2P The Tao has a L2 specific P2P for their mol and then the AVS node every 3 seconds with L2 block and then publish the signed L2 block to The Tao Network and then anyone who's listening to this P2P they can actually exit him because without waiting 12 seconds the user is I'll be able to know what the proposer is committing to yes okay a little more in detail like so okay so like what is actually published here what's published here is this it's a pre-confirmation first we have the pre-confirmation header and a transaction list and the pre-confirmation header what it contains is a block ID chain ID and the transaction list hash this is the most important part this is saying that hey I as a pre- confirmer I'm going to pre confirm these transaction list so I'm going to like okay now like later on in the uh the sequence okay yeah then like and then like one interest like very important thing here is that okay what if the submitted L2 blocks here contradict what was pre-confirmation only work if these two are actually the same so if they're not the same we're in in trouble because like the user trusted the pre-confirmation are going to be eventually included what if they're not included so for that we need slashing and for slashing is also done like automatically by the AVS nodes and the idea here is like uh like what if these signed del2 blocks they mismatch the sublate L2 blocks okay so here's like a some like pseudo code for like how this could work and the important thing here is like okay in the L1 contract we keep track of what was actually submitted to the actually like mapping to so like what are the transaction hashes that were proposed to L one basically and then we have this prove incorrect pre-confirmation thing that will like detect whether like the pre-confirmation header and actually submitted L2 block difference things between the precom L2 block and the submitted L2 block so like implementation wise the most important part is here you're just checking that what was posted actually posted to L one if it mismatches the header that was actually pre-confirmation space so and one thing is what I called pre-confirmation PBS okay so like what we look at the POC implementation and way expired so far is like this setup like the user submits the transaction directly to the proposer the proposer locally builds the L2 blocks and pre- confirm them but the proposer may want to eventually want to Outsource a pre-confirmation duty to external so we might want a pre-confirmation PBS because like right now the proposer building by themselves they want to Outsource the pre-confirmation duties okay how can this happen like one way maybe to like have a gateway way what we call to fully delegate the pre this Gateway guy this will do the pre-confirmation duty instead of me and then you'll delegate ahead of your slot to this like specific Gateway and the gateway to PBS so like what I explained for the L1 here you can have a L2 specific one but like have the L2 Pi one run in more frequently so the red part in this diagram it can run every 3 seconds while the L1 part the bottom part the blue part can run over 12 seconds and then you can provide L2 pre confirmation in this that we had for the base rollups run this whole thing every 3 seconds and this way you can get both L1 and L2 pre confirmations and thanks to that you can also get like good composability guarantees okay that's all and here are some references on our work on pre confirmations and yeah thanks for listening [Applause]