Lin Oshitani I Intro to Based Rollups & Preconfirmations with Nethermind I ETHGlobal Bangkok 2024

[Music] 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 Bas rollups and pre-confirmation what they are I'll give a quick intro and then I will talk about our Ty 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 rups 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 Easter research so it's only natural that it's being asked in the L2 context too okay so like let's see how most trups today work so most trups 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 Pipeline and eventually these L2 blocks will be included into L1 block like this and like SE like centralized sequences are very nice most notably they can provide pre-c 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 centralized 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 action C to the centralized sequencer the central sequ will immediately return this pre-confirmation and the user by looking at this pre confirmation they can EXA 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're like properly 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 pre confirmations okay centralized preon uh centralized sequencers are nice because they can provide fast uxx 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 bring us to the idea of based rollups okay so 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 blocks that also contains these L2 blocks okay so let's L1 block pipeline so the user has send their transaction out to the mle and then the what we call Searchers will like bundle these transaction so for example if you have a DEX trade the searer will insert an arbitral 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 it's not only for the L1 transactions that are like used blue here it's also used for the L2 transactions that are used in the red here okay be rollups have very nice properties like first they we inherit the L1 sensorship all we have is L1 actors so we inherit the L1 security another nice 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 the 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- confirmations in this base setup and one thing to notice here is okay can the Builder provide pre- confirmations and there answer is no the Builder cannot provide 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 a wooding block so the Builder is not sure is that a proposer does have the monoply 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 mplay sequence right and they can provide pre- confirmations so the idea based speak confirmation comes from this insight and the idea here is that let the L1 proposers opt to provide pre confirmations so now like you have the L1 like same old block building 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 pre affirmations 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 the one blocks salt time but the red part this pre-com part every 3 seconds the proposer will collect a bunch of trans actions and then pre- confirm pre- confirm them and then in the end like it's both of the L2 block transaction L1 blocks combined and it's built the L1 block is built okay so let's get into a little more detail so there sequence diagram that um illustrates how our tyo PC 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 O proposers and this side car will be responsible for the pre-confirmation duty 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 ABS node every 3 seconds will 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 so 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-confirmation 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 L2 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 two so like what are the transaction hashes that were proposed to L1 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 different things between the pre-com 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 call pre-confirmation PBS okay so like what we looked at the POC implementation and we expired so far is like this setup like the user submits a transaction directly to the proposer the proposer locally build 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 may be to like have a Gateway what we call to fully delegates the pre this Gateway guy this will do the pre-confirmation duty instead of me and then you'll delegate ahead of your 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 every 12 seconds and then you can provide L2 PR 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 free confirmations and yeah thanks for listening [Music]