Designing an End to End Solution for Based Preconfirmations | Devcon SEA

[Music] kind of I mean it's fine but since we okay yeah very good afternoon to all of you present here so have we have reached the final day of Devcon we have had like 10 different uh talks on pre-confirmation three full scale events and the only question that I've been getting is how do you make all of this like Fast transaction confirmations yeah yeah we get it but how do you make this so yeah now on the last day uh welcome to the workshop on designing an end2end system for based pre-confirmation a quick introduction of the speakers uh Ahmed go ahead yeah um so my name is ahed B I work as an ethereum core developer normally I'm also the product manager of Surge and the technical lead for our pre-confirmation solution and I'm Anu I am working as a blockchain engineer at nethermind and I joined this industry like 5 years ago mostly focused on dii but for the past 6 months uh my efforts have been mostly concentrated on Bas precon confirmations so today this session is a no code session so I won't be like writing a line of code and then asking you to copy it and repeat it like 100 times over I know most of you will leave in like half an hour if I do that so instead this is a session on design thinking where we'll build the whole concept from ground up and share exact what exactly we did during our research over the past 6 months but if you are interested in looking at the code then I have linked it below it's Tao precom AVS repository which you can find on the neine GitHub page so since we want to build it all up from ground up we have to start with the foundational knowledge which is rollups because the based in in based reconfirmations comes from based rollups just by show of hands how many of you do understand what a rollup is okay pretty much everyone that's great well rollup is a scaling solution and why do we need a scaling solution we need a scaling solution because the L1 is is really slow the throughput of L1 is not much and why exactly is that the case well in a blockchain blocks are basically a consensus on state transition that's the first section of the ethereum white paper you have state a you put a bunch of transactions and apply it to State a which is like a Delta and you get a state B but now imagine millions of nodes doing this every single Epoch now that's going to make this network really slow and that's a major problem so what's the rollup way of doing it well if processing State transitions is the biggest issue on the L1 what if we process these State transitions off chain or apply these Deltas off chain and that's exactly what a rollup does we have like you can have a one single rollup node or an L2 node since it becomes a lay to that applies applies this Delta of chain processes the state transition and the L1 is just an observer on the L1 you have a rollup inbox contract and you simply push this state transition and the Delta maybe as a form of a blob or in the call data in the image it's a blob and the L1 is just an observer and in the most basic form this is what a rollup is but is this enough well no because if it's just one note pushing the transition and the Delta how do we know whether it's actually correct correct or not and this is where the flavors of the rollups come in optimistic and ZK in the case of an optimistic rollup well you push the state transition and the Delta and then you just wait you just wait for someone to prove you incorrect if you're correct it's it's all good but someone can just come by and say oh hey it's a proof here's a proof this transition that you posted is not possible with the Delta that you posted and then you kind of get slashed if you have some stake in depends on uh what kind of process the rollup wants to do and arbitrum is an example of an optimistic rollup I guess most of you must have used arbitrum and then we have ZK rollups in the case of ZK rollups instead of waiting on for someone to prove you incorrect the moment you push the transition and the Delta you have to prove that this is correct so it's called a validity proof you're basically proving the validity of the transition but the point here is that what whatever time or computational effort it takes to verify this validity proof must be less than what it takes for the L1 itself to process all the data only then it actually makes sense right so these are the two variants for proving whether a transition is correct or not once again by sh fans how many of you have heard of centralized sequencing okay it's the most cursed concept right now and just to give a quick primer when you're making a transaction on arbitrum you're not directly sending the transaction to a public mempool like when you're doing when you are transacting on ethereum L1 instead it's going to an arbitrum sequencer and it's a private server what the sequencer does is it has complete control over arranging or ordering the transactions and they usually promise that they will arrange the transaction in a certain way we don't know whether they're actually doing it or not but in the case of arbitrium the promise is that it's a first come first serve if your transaction comes before that other person we'll put your transaction first in in the block but once again it's a promise we don't know whether that's actually happening or not so let's get based and talk about based rollups and pre confirmations well the based part is actually not a different variant of a rollup so it it doesn't stand beside a optimistic or ZK rollup instead based is a form of sequencing just like we have centralized sequencing we have base sequencing and in the case of Base sequencing the L1 proposer is the sequencer you don't have a centralized server sequencing the transactions instead it's the L1 proposal let's say we have Tao Tao is a based rollup and in the case of Tao the L1 proposal literally runs a tao software alongside the usual consensus and execution clients and whenever their block comes in they literally just put pull the blocks pull the L2 transactions from public Tao M Pool they order it in their L1 block and put it on the network so yeah you basically are inheriting the L1 security as well as the L1 liveness because the L1 itself is your sequencer so just a quick overview of how Tao actually is arranged well you have the rollups inbox contract that I have been talking about and although Tao doesn't really call it rollup inbox uh this is the colloquial term Tao has like a bunch of contracts that work together and they just call it Tao L1 contract so that's the L1 component now if you're running an ethereum validator you usually run an execution client and a consensus client right so in a similar way if you want to run or be a part of an L2 Network the proposer has to run an L2 execution client or an L2 and an L2 consensus client so in this case Tao get is the execution clant which is a modification of the standard go ethereum and this is where you have the mempool you have the actual L2 chain all the blocks are formalized and you also have the evm on the L2 Network and then we have the Tao client which has some subcomponents and this forms the consensus client and it deals with proving the blocks and proposing the blocks whenever required now today the most important thing for us are block proposals because that's where the whole concept of pre-confirmation will be built upon so how exactly block proposals work in Tao or in a based rollup so well when you're making a transaction using any kind of standard wallet it goes to the meol or the public me pool which is offered by Tao and every few seconds or depending upon what algorithm the proposer is using transactions are feted from the mempool and this transaction batch forms the actual Delta and when you're calling the RO up inbox contract you're basically calling a function which is proposed block and you're just passing this Delta along now you might be wondering well that's the Delta fine where's the transition so in Tao it's a two-step process the Delta is gone and now we have the Tao prover which comes in later on and just says okay remember that Delta that was pushed uh a few seconds ago or few minutes ago you see this is the transition that that Delta causes and since Tao is a ZK rollup it pushes a concise proof along with it like okay this is the transition and this is the proof that the Delta caused this transition now the most important aspect Tao driver so once these L2 blocks are put on L1 there is an block proposed event that is released which shows that hey okay this L2 block was put in the L1 contract and whenever that block proposed event is released Tao driver listens to it and advances the head in get advancing the head basically means you're formalizing and putting an L2 block within uh the L2 Network and this is when the wallets end up getting the transaction receipt or the confirmation so you see the catch here is that Tao driver only receives the block proposed event every 12 seconds that means when you're making a transaction on Tao you get a transaction receipt after 12 seconds which is huge that's not ideal for a rollup or a scaling solution and that's very evident from the DU analytics graph of Tao's block times it's average between 12 to 24 seconds which makes sense it's inheriting L1 block time that's not ideal at all so we need pre-confirmation and pre-confirmation is not something new we have already had it on arbitrum for a long while and several other rollups again show off hands how many of you have transacted on arbitrium and when you transact on arbitrium you basically get a transaction receipt like in a very small period of time like half a second 1 second sometimes 2 seconds but the point here is that arbitrum only posts blocks every 2 minutes on L1 so how are you getting this transaction receipt immediately it's because that's a pre-confirmation they're giving you a promise that hey see this is the receipt and we will be putting this on the L1 eventually in Tao you have to wait for it to put be put on the L1 but well this gives better ux for arbitrum and bad ux to Tao now what if we want to put pre-confirmation on Tao it's really tricky because in the case of arbitrum we have one server literally one server in one corner of the world just running except ordering transactions providing pre- confirmations easy in the case of based rollups the sequencer is changing every single slot the proposer changes every single slot so well the sequencer changes every single slot and then these days we don't have the proposer building the blocks the blocks are actually built via a PBS pipeline like me boost by flash Bots where Builders build the blocks for you or for you as the proposer and then you just propose the block which which whichever Builder gives you the highest bid you just take their block and propose it you don't even have any control over what's in the block so how exactly will you put in base prec confirmations with three layers of complexity well we have done it and let's start with the design principles maybe a quick round of questions if anyone has any questions no okay take it over all right great thank you um okay so the first thing we wanted to do do was we wanted to not introduce centralization again and the way we wanted the um the idea here is that if we wanted to do to introduce centralization we wouldn't have built it as a based rollup in the first place then how are we going to solve this complex problem so let me explain how gateways work first so gateways are basically centralized servers that expose an RPC for the user to be able to provide them the precom they the the user sends the transaction to the RPC and then it selects which uh which uh transactions wants to precom and then it it provides it to uh it proposes that block to L1 of course the confirmation receipt that goes to the user is given like in a matter of milliseconds between 100 and 200 milliseconds which is very fast of course the ux is very cool but the compromise is very high now also like there is a another concept here in pre-confirmation that is important which is not all validator has signed up to become pre- confirms and because of this you sometimes have some validators who have uh decided to register as a pre- comfor and some others that haven't registered so the Gateway can provide pre-confirmation for users and it should it could it not necessarily will push a block uh a propose a block for the L2 on this slot but it could potentially push it here and the way to do this will be explained in a later stage when we talk about um forc inclusion lists all right the other thing that we wanted to focus on which was important for us is that we wanted to use the the existing transaction structure the existing wallet we didn't want to invent a new um a new a new like complexity to the to the already existing situation when you are sending transactions through wallets um so some suggestions in the precon space were like oh we should potentially put an inclusion precom fee premium so like what are you going to pay P the promer to to to so he can provide you with this fast service or and the base fee per gas for that as well or for example an execution precom yeah it's it's basically very similar uh to to each other like they're all like the same so what we decided is no we're going to choose something that is basic so we're going to choose the same exact EIP 1559 fields which is the priority fee so the the priority fee pays for the pre-confirmation the proposing and the approving of that transaction and the user does not have to worry about all of these complex things other things okay it's not moving okay all right so I'll start now explaining what we we designed so in Tao like explained we have the in Tao we have that uh Tao client and we also have Tao G in Tao also we have before these before we come to these we have the contract that receives the block proposals and so so what we did is we added uh something we call a pre-c confing node and that sits between uh the proposal and the contracts and we added some contracts one contract is the pre-confirmation service contract that basically receives the blocks that are coming from the promer and also um we added a restake a reor staking contract that will basically uh allow the proposers to register uh as a preon and by this these proposers whichever they are any validator can basically just run this set of software as a site car to uh whatever they're running for the validator so alongside L1 you're just running these three uh basically uh these three um Docker Docker Docker images Docker containers and then you are able to precom transactions when your slot is up so what H how how does this exactly work so we have a loop that happens every 3 second when when when when you are chosen as the pre-c comer for the upcoming slot what happens is that you as a pre confing node will Fitch the transactions every 3 second from the tyo proposer which will basically fit them from Tao the user will have sent this transaction to the mle so there is no centralizing aspect here you don't have to connect to a specific AO to send that transaction and every 3 second the pre-con fer will sign this trans uh this batch of transactions that it has received from The Tao proposer and then broadcast it to other pre confers through P2P oops okay um okay permission okay so here we we we we we look at okay so how do we choose which of the registered prec confers are going to be used or have the right to propose these blocks and this is when we use the look ahead that is provided by the consensus layer to know which exactly uh is the proposer that has been registered in the upcoming 6 uh 64 uh or like in the in this Epoch and in the epoch after so in consensus layer and Beacon chain you can query the CL client for the existing uh Epoch the current Epoch which which which uh which proposer which validators have the right to propose and for the upcoming Epoch um so it provides you with a list 32 uh long list of after you specify the epoch that you want and so basically the what we did is that we made the pre precon node fix this list from the CL client and push it to the pre-confirmation service and this way we know for example that since this proposer is not registered this proposer is not registered we know that this this proposal is registered so then we choose this proposal to uh be the one who is precc coming those blocks this thing doesn't all always work let's just okay um so then there is like with with any system you have to have incentive to act correctly some systems depend on uh um on only rewarding uh good behavior some systems depend on uh punishing bad behavior most systems or a lot of systems depend on doing both so in this case the preon getes that pre-confirmation fees and the proposing fees in return he needs to precom and provide good information uh and honor the pre-confirmation that he gave to the users the way we check that is that in the case the pre-c confer node reveals the signed malicious pre-confirmation the way it's done is that so let's say I precom a batch of transaction and then I didn't end up pushing this batch of transactions on chain but I have already broadcasted that I have pre-comp this batch of transaction with my signature so what would happen is another promer that was listening on P2P would then pick this signature with uh with the with the batch of transactions and push that to the pre-confirmation service contract the pre-confirmation service contract would check if this is a valid signature for the pre-c confer of this slot and if it is then it will go and ask the reaking or staking contract to slash the signup and in this case um yeah the there is also the slashing for the incorrect uh look ahead because you fish the look ahead from the CL but how does the El know that this uh look ahead is correct there is you can use um 4788 uh EIP uh which uh basically provides you with the CL Beacon root um and using that you can push a proof if the look ahead is incorrect and the prec confer who sent an incorrect look ahead would be slashed okay so I before I move on if if you guys have any questions it's it's good to to have them now so yeah please go ahead I have two questions first one is based on I'm not familiar with 478 not only yeah so the thing about 4788 is that it provides you with the beacon route of the parent block and not the current block and because of this when the look ahead is pushed I cannot in that moment verify its correctness but after one single block I can with the proof using 4788 make sure that if it's not correct that it is not so this is why we opted for this in the case that it was possible to verify we would have potentially opted for um pushing the proof with the look ahead the problem with that normally entails that you would pay more because the proof needs to be verified on chain in every single submission whereas if you do it in a fraud prooof manner only when someone is acting maliciously that you need to do this so the cost drops dramatically and there is precautions to this so whoever is submitting the look ahead will get rewarded submitting the proof the fraud proof for the look ahead will get rewarded for this uh by uh the slashing of the other promer other questions yeah yeah you go back to the slide where was com to one okay uh let me try to make this work somehow okay work please Okay no Okay yeah over here sure um well not this was one where there was a SL I was wondering um I mean here this one is not opted in and this one is so for example if I take confirmations from someone who SLS reliable St St possi that okay so this is probably not mentioned in this presentation which is uh a problem but hey sorry um so basically what based rollups depend on giving the user the ability to always push transactions on the L1 with permission perm permission LLY okay and that means that there is no one who could prevent the user from pushing a transaction that could invalidate future transactions that have been precom that will be pushed later that have been pre-comp um and this leads to execution precom not being able to be provided and the only solution that we have to that is delayed inbox so pre comers are able to push directly to the Tao smart contract to propose block blocks whereas normal users who don't want to use the pre-c confing system that is built and want to push directly to avoid potentially censorship uh uh by the promer even though this is a decentralized solution it could potentially have some type of censorship so if they push their transaction to this delayed inbox what happens is that we wait for the pre-confirmation to land and then we include those uh transactions that have been pushed by the user so in this instance just to be clear uh any transactions that come in this slot uh will will go to the queue and will not be proposed no it will not be denied it will go to the Q yeah delayed yes it will be delayed till after the the pre confer has uh pushed his pre-confirmation and then it will be included what if my preon is dependent on one state which is like really nice component um yeah no um I could I could expect the pre conf with interacting with L1 yes so if we engage a composability in here then it could yes any state any L1 State change could potentially affect uh this uh L2 transaction that depends on it and this is not a problem that the solution is trying to solve unfortunately just like an yeah I don't think I don't think like um as of now there is potentially there's some people working on this but I'm not aware of any solution to this particular problem this is a very good question thank you sir any other questions yeah go ahead yeah so I think this might be talked about in a later stage so I'm not going to touch on it more but there is a way for choosing a random pre- Comer in the case that there isn't AE Comer available for the next 64 uh block slot any other questions y go ahead um could you touch on more about the so I'm doing PR Gateway as like a a subset of the P lay that's exclusive for pre that's how interact this immediately sounds like a Loosely coupled system to me off the bat do you feel like there's consensus required here to agree on preon state like what happens if the propos is to pull back to another like you unpack the gate the Gateway okay so the Gateway basically buys the right from the proposers that have registered at P confers to propose at a certain slot do I even agree on like for example us provide um I don't think so know like they can they can have varying tips between one one one one one gateway to another the problem is that with gateways is that the gate the gateways will have to compete in the beginning we might have a couple of gateways out there the problem with that is that it it normally con people normally end up converging into a couple of gateways that then would have a monopoly so like two or one Gateway that would then be dominating because the idea here is that if a gate way cannot secure uh uh verif uh validators or proposers that are willing to sell it to sell the Gateway their right to propose these uh Tao transactions the Gateway cannot uh operate would there ever be an inst where pre Builds on other pre fromal yeah so consensus um you do and that's why we have the P2P I'll explain that and in this slide so when we said here sorry this this thing is not that okay yeah so when when we said that the precom node every 3 second batches a transaction uh takes a batch of transaction and signs it and then it broadcasts the sign prec confirmation precon blocks on P2P this is important because anyone who's listening can do a bunch of things first they can advance the head of the uh of the Tao so people can keep up with these precon prec confirmation you moving to a safe head there sorry is it moving just to a safe head it's not a safe head no it's it's not even a safe head at this point because it's basically a soft head very soft head because as long as long as it hasn't been proposed on L1 it's not fully safe I mean there is financial precautions to to that proner if he doesn't obey or honor these prec confirmations but they can always software can always fail or um they they could potentially have other incentives so it's a very soft head but at least you get consistent block times which is a better user experience than what you get right now um I mean ano said that transactions normally take 12 seconds and on Tao sometimes they take 20 seconds so there is some kind of extra delay it's very long time um any other questions before moving on sorry I just wanted to understand the consensus at the P2P lay that you were describing um so what what do you mean the consensus so my original question was if you have um pre-confirmation being built upon by sorry new pre-confirmation being built upon the state of previous pre-confirmation mhm how does that like consensus is needed there for between two different so the the pre confer that comes so let's say that okay let's um let's say that all of these are pre-c confers and this one is a pre-c confer and has been pushing um it pushed basically four blocks it precom first one second one third one fourth one and then it basically just went and pushed it to L1 this one would be listening to these pre-confirmation batches on the P2P and would receive them and it would just wait for a confirm that they have landed on L1 and then it would start building on top of that would the middle one be accepting pre-confirmation before it's been posted to L1 no no because since its pre-confirmation um depends on uh the the state of what happens in the chain here so it can't do that or it will collect I mean it can but it to collect a bunch of potentially a bunch of um transactions that has been already included for example so it would potentially lose that space uh on the L1 side and yeah and also if it um it and if it does not if it sees if it for example precom a bunch of transactions that uh then already has landed the execution precom is not honored that doesn't mean that it will be slashed it won't be slashed in the system that because the inclusion precom is still there but it will lose that uh that and if it does not include them it will be slashed so in both cases it's kind of losing something of course non-inclusion makes it lose more so it would include them even though they're already processed and will be invalid if they're included again but it won't at least it won't be slashed yeah so this is this is the consensus um I mean this is a problem with also like varying types of precs because because you can always U that like if if so in in the system right now we're trying to build with prec confirmations is that trying to avoid a singular solution to dominate so there is multiple Solutions so there is the Gateway there is what we're building and there is multiple ones so if each one kind of like needs to build on the one other the other one it needs to wait for um the L1 the state of L1 to be updated to start building on top of it additionally to that that um if someone if a user pushes a transaction directly to L1 without um without pushing it through a proner then that also changes the state so it doesn't make any sense at all to start building pre-confirmation before knowing the exact state in the on the L1 yeah thank you okay let's hope this marker starts working okay uh yeah so we talked about slashing now so as we said the pre- confer needs to include and propose these batches of transactions on L1 but if this validator is selling his right to build the block to a through PBS to a builder it cannot accomplish that because it has no control over the content of that block and the solution we found to that is that we would modify the epbs pipeline um to accomplish this exact uh uh goal so the the the precom node would go until basically the the Mev poost that there is a constraint on the Builder and that the builder needs to include a bunch of L2 blocks which are basically a couple of L1 transactions or it could be one L1 transaction and their blobs and it could in it should include them and that's why the uh and and then the PBS relayer would return with okay yeah I can honor that and and they build a block including these transactions at the end and we propose the L1 block this is the way that um and currently we're using um bolt Smith boost because they have that constraint API already implemented so we we didn't want to implement reimplement the wheel but of course there is also commit boost which can have that bolt myth boost module built on it and you can have it for more details on those please search them on Google commit boost and bolt M boost both of them are they have open source GitHub repositories that you can um uh look at and yeah pre-conference selection I think Anu will take over here thank you sir thank you you want the mic mic just this one yeah okay so now you have a good idea of what the overall design looks like and let's talk about pre-con fer selection because we did speak about how we want the L1 proposer to be the only one who can precom and then propose the L2 blocks in a particular slot now this is actually a very hard problem even though it doesn't look like because at ethereum we love patching things up and in the process of patching things up we develop new problems so when eth moved from P to POS what happened was we introduced a new layer the consensus layer besides the existing execution so earlier it was merged into like one single thing and now we have it's separate we have a consensus layer which manages the POS part and we have the execution layer where which is what we developers usually handle when we are develop deploying smart contracts or interacting with ethereum using a wallet the problem is the consensus layer is where the proposer identity lives and that has a BLS signature scheme but the execution layer where all the inbox contracts are where all the transactions are made that has an ecdsa signature scheme and that's a big problem how do we make a connection between both of these there's no way to make a connection so what we need is we need a BLS to ecdsa mapping so let's say I'm an entity I have an ecdsa address and I run a thousand validators with thousand different BLS public keys I need a way that I can prove that I own those thousand validators I can show it to the registry contract so we have the pre-confirmation service contracts actually have three subcontracts the pre-confirmation registry which we'll be dealing with in this slide and two other contracts that we'll be taking up later on so this entity needs to prove that hey I own these validators and I actually have the right to propose an L2 Block in a particular slot and how exactly do you prove ownership of a key through signatures right so we have this signature format here which you can see it basically has the standard thing like having a chain ID and then validator op is basically either zero or one if it's zero you're removing a validator from your list one you're adding and then there is an experim and the actual precon fer so in here the pre- confer in the signature uh message is the ecdsa address that I'm claiming that is claiming the ownership of a BLS address so the ecdsa address just pushes a signature and the contract just verifies that yeah it's the signature is correct and this BLS public key actually belongs to this ecdsa key and inserts it into a simple map now the execution layer has no native way of verifying BLS signatures right now but very soon in the next upgrade the pectra upgrade a new pre-compile is being added via EIP 2537 that's where all the discussion uh has happened and this pre-compile or a set of pre- compiles three pre- compiles actually will help us verify BLS signatures now this is are really expensive because for verifying one signature we need to spend like three 100K units of gas that's really expensive so in our next alter in our next PC we are actually proposing an alternative where in the case of BLS there's a great feature and that's aggregation so if you have thousand validators what you can do is you can have thousand signatures offchain then add all of these signatures up it's basically elliptic curve addition you add these signatures up and then on the contract you just have to verify one signature so essentially you can add uh like you can put thousands of validators in your registry via just one signature and just a bit more than 300 gigas which is amazing and this is what we will potentially be putting in the next version but yeah right now it's one to one single address single signature every single time so how is this used to construct the look ahead because the BLS look ahead is absolutely useless on the consent that's on the consent layer we need an ecdsa look ahead on the execution layer so every every single time we know that only this ecdsa is supposed to propose no other ecdsa can propose an L2 block so in this case it's kind of simple the pre-comp node has the logic the pre-com node can take a look at the consensus layer because the pre-com node is has the view of both the execution layer and the consensus layer so the pre-com node pulls all the proposal from the consensus layer for the next Epoch then it fetches the associated ecds key from the pre-confirmation registry because we have the BLS to ecdsa mapping there and it just matches it okay this this BLS for for the next slot is belongs to this ecdsa This one belongs to this and it creates the entire look ahead now in our design we have assigned the duty to push the look ahead of pushing the look ahead to the first precon fer of every Epoch so the first prec confer of current Epoch will be pushing the the look ahead for the next Epoch and they are basically bounded by this Duty they must do it if they well it it kind of there's no option of not doing it because the contract expects you to provide that and this is what a simple look ahead like like one of the nodes in the look ahead array or mapping looks like I'll get to what the look ahead what data structure we actually use but in here the Tim stamp the second field and the fourth field makes sense the time stamp is the time stamp of the slot and the proner is whoever is supposed to be proning in that slot or proposing an L2 block we have another field fall back and previous timestamp now what are these well the previous timestamp is just a link to the last uh look ahead nodes Tim stamp what this allow us to do is um arrange the look ahead as a link list within the contract or sort of a link list within the so every look ahead structure is an item in a map and the previous timestamp just points to one of the other timestamps what this allows us to do is have advanced proposals because not every proposer will be opting in and also not every proposer will be registering and exposing an ecdsa address some are just not interested in preconfig right so in this case we cannot just have an entire Epoch be empty if there are no pre-con fers or if there are very few pre-con fers we need to do something in the empty slots and what we do is we allow the next chosen preuner to precom in advanced and because of this link we can do that with a simple check a a simple if condition that's why in here you can see that P2 pre- confer 2 can precom in the second and third slot already and P3 can precom in three slots in advanced that is made possible because of this linkless design finally if we have an Epoch where there are no prec confers at all and that's very much possible if no one none of the proposers in that uh Epoch has opted in we don't have anyone as a pre- confirm then we have to select someone randomly and that's a very simple selection like we need a source of Randomness and with apply like simp simple modulus to select one of the indices of who is exactly going to be the proner from the registry and the source of Randomness comes from the beacon root contract so we uh as far as as far as I remember we basically end up choosing the beacon route of the first block in the last Epoch because this gives us a pre a deterministic idea of who's going to be the random preuner in the next deok so we use that as a source of Randomness and we just use that to pick out a pre confir and this fallback pre- coner has an advantage and that is it can preon in every single slot of this Epoch because no one else is there to precom yeah uh notos you're not to in six months well but we won't be stopping for six stopping the system for six months right yeah so I can uh get in here I understand the question um so you're asking is since the pre comfor does not have the right to pre uh to propose a block in the next Epoch for example and we chose it at random um how will it be able to honor these preon and the answer to this question is that it might not be able to honor the pre-confirmation but uh it will not be slashed if it does not honor them in this case because it's a random picked pre confer and also we thought about this like okay maybe it shouldn't be providing pre-confirmation but this would be a very bad ux so we' provide the pre-confirmation we would send them in the P2P on on on um on the M Pool and potentially someone will pick them up and include them if the if the if the if the fee is right um and this was like the mechanism that we wanted to do in the be so um what Tao is doing also is that they're they're they're they're using this fullback mechanism to say okay if there is a no a promer registered in the next Epoch then we are going to propose just to keep the the the liveness of the of the chain um and of course this proposal will go to the mle and someone will pick it up but if someone intentionally is censoring uh these uh transactions and there is no mechanism to force the builders to include them then they will potentially not be embedded uh in time yeah thank you Ed and one thing to not is that throughout this POC we have never touched the Tao contracts although eventually we might to add that delayed inbox but in here we have tried to not mess around with The Tao contract and what our task manager does is it simply routes the blocks that are being proposed over to Tao contract so because of this the prover architecture doesn't have to change that's the best part nothing in the prover has to change and the proposer also needs very minor modifications because the original contract original contracts of Tao have barely been changed go ahead for the next step thank you thank thank you okay so now we're going to go back to the pre-confirmation loop that we discussed that every 3 second we go and um in a bit more details I hope this clicker works okay I'll just stand here um all right so first we start with the normal event Loop for Tao so what Tao does is that once every L1 slot it pulls the pending transactions from the men poool Tao proposer goes and forms the block and then pushes it through the blob to the rollup inbox contract through the proposed block function very simple straightforward what we have with the prec confing solution is the following so we have the pre-com node every 3 second requesting from The Tao proposal a batch of transaction Tao proposer goes and fitches those batch of transactions from Tao and forms a batch gives that batch to the precom node and the precom node then goes and then um uh pushes this transaction to the P2P like we said the batch of transactions to the P2P and of course the this also only happens after it made sure that it is the prec comfort for this specific uh for the up for this slot and or an upcoming slot that is very near so this is the the new uh loop okay all right so what do we sign when we provide the prec confirmations through P2P what's the signature so the the structure that we use is we use the block ID because we we need to commit to a specific block height or that uh pre confer could potentially sandwich transaction if it wanted to if we don't commit to a specific block height that it needs to to uh to propose this uh batch app also the chain ID in case we are we have like multiple uh chains and transaction list hash which is basically just a hash of the rlp encoded transaction list and I see there are some hands for questions yeah go ahead you you have the mic it's fine just raise your seconds yeah so 3 seconds was like a just a conservative um random number that we chose at this point because we weren't sure how fast the the system would be the latencies all of that um what we're going to be working on later as you we will see and one of the slides is is like getting that number lower and seeing how it's going to be behave and how will it work we will talk about that in in in later slides okay so this works here okay yeah so the the the pre-confirmation structure we saw it and then there is the pre-confirmation object that is sent on P2P because the pre-confirmation structure is the one that can be pushed as a proof for uh uh fraud proof but here we need to uh when we are pushing the precom batch on P2P we need more details that one is not enough so we have the block height and the pending transaction list the whole list and um and the pending transaction bytes I'm not entirely sure what that is for and the proof uh uh of the precom message and this is what ends up being sent exactly in the P2P and the reason we need the batch of transactions is because we need all the other uh pre- confers or all of the other participants in the network to be able to advance the head with this batch of transaction and we also um need them to be aware of this so when their role of pre- confing comes along they know that okay these transactions have been already precom and potentially will be proposed in the next and and in the in the previous L1 block before we start pre confing ourselves yeah so when um when a pre-com node receives the batch of transaction from the P2P once it's has been ProMed we currently the way it's it it works uh in Tao before the precom is that we get an event which is called block proposed from the one and that goes the Tao driver is basically subscribed to this specific event and advances the head uh uh once it receives this event which means that the user will get a transaction receipt every 12 to 24 seconds and this is the main point that prec confirmation our precon solution is trying to alleviate with this design so now the pre- confing node can once it receives the uh pre-comp message with the pending transaction list it can provide it to Tao driver and Tao driver can basically Advance the head of Tao in around 3 seconds given that we choose a 3sec uh confirmation Loop um time all right so the the nonpr so there is the precc confing node so this is the previous slide was about the pre-c confing node so once it pre-com the transaction list it does this and there is also the non- preconfig node receiving this message through P2P and then sending it to Tao priv driver to advance the head so the whole network advances together and not a single uh one of the nodes in the network yep so we already kind of discussed this so um we have two ways that the pre confer sends his transactions or that the L1 transactions that will basically push the uh L2 uh transaction batches so first we said okay let's say that we have a pre- confer in slot number five and this prec confer is on duty for slot number 1 2 3 4 and five that means that they need to precon a lot of batches on in these slots and then they can force include them in slot number five and that's not a problem that's easy to do by using the PBS software like we explained um the problem arises if there are sparse prec Comforts there isn't a lot of pre Comforts and that would mean that potentially one pre- Comfort could be in slot number 42 and he's responsible for slot uh I don't know five up until 40 to and this would mean that he needs to push a lot of transactions in in his slot if we follow this model so instead we said okay maybe we should just push all the precom transactions right away to the mol so we get batch a batch B and we just push them directly to the men pool and at the same time we put them in a Que in a cache and the idea of this cache is that once an L1 block comes and it has those uh batch transaction that has been pushed here in it then we can remove this batch from the cash if if that doesn't happen then the batch of trans if L2 transaction stays in the cash and then once it is yeah and so basically if it's if it's U if it's included we clear that batch from the from the cache okay so on the proposal slot we take the ones that hasn't been included uh that we pushed to the m pole and hasn't been included yet and we make sure that we push them through the constraints API of Bolt Smith boost to be forc included by the Builder and then once we receive the L1 block we have the guarantee from the relayer that these transaction uh uh L1 transactions that contain the L2 transaction batches are included then in the uh L1 proposed L1 block and she will talk about slashing and yeah got yeah okay so now comes the pre-confirmation service manager contract which we haven't spoken about yet and this is a very interesting contract because what we have tried to achieve with this PC is a really flexible interfacing because we have a number of reaking solutions right now out there in the in the market we have ananl we have kak we we might also have our own staking contract later on if a community decides on one which uh is actually going on a discussion is going on on having a unified registry and that calls for having some kind of a middleware contract so that later on the code logic doesn't have to be changed and the staking is just abstracted away to a different set of contracts and that's what we achieve with the service manager is essentially like a middle wear that ensures that only those proposers who have a required stake are allowed to precom or propose in in the upcoming blocks in the upcoming slots so what kind of slashings do we have or when exactly do we slash well one one time do we that we do slashes when the look ahead being posted is incorrect or the look ahead posted is incorrect a basic version of this is that when you have uh like let's say for a validator with BLS key BLS public key B5 uh in the look ahead mapping uh in in sorry in the BLS mapping you have E4 as the associated individual who owns the B5 key but the proposer who pushed the look ahead placed E2 as the associated ecdsa key which is factually incorrect now this might look like an easy way to just compare hey okay both of these are not really equal so why not we slash the the person who posted a look ahead but it's kind of tricky to prove this inequality because we have B and E4 from the pre-confirmation registry but in the task manager we don't have access to who exactly was the BLS the the validator and its Associated BLS key for the current slot or any slot that is incorrect we don't have that information in like s in a simple way and what we need to do is we basically need to have uh this kind of a match that okay B5 from the pre-confirmation registry and B 5 in the current slot both of them have different ecdsa keys and then B on the basis of that we slash the pre the poster of the look ahead so well there is a way to do that and I kind of have to make a correction on my previous uh statement that there is no connection between the consensus layer and execution layer well there is but it's kind of a complicated connection and that's through the beacon block route which I think Emma touched upon briefly so you see just like the consensus layer has blocks sorry the execution layer has blocks that we deal with the consensus layer also has Beacon blocks because it's the beacon chain and each beacon block has a state route and if you unravel like the entire state tree then you'll realize that in Beacon State we have the validators field which contains all the validators or the proposers uh and that includes the their unique index as well as their BLS key so what E7 4788 proposes is that we get this eventual Merkel route like if we meriz this entire Beacon State and then eventually the beacon block we eventually get a 132 by long Merkel route and we make this available within the execution layer so the thing here is that there's a problem and that's we only have access access to historical Roots we don't have access to the current slots proposer because well the consensus layer is yet to create the block so we can't have the we can't really know who the proposer is so we have to slash or prove that a look ahead is incorrect optimistically and the way we do it is we wait until the incorrect slot has passed and we have the route and once we have the route we can basically make a static call to this contract which is the beacon Roots contract and get that Beacon route and then just need to send two proves so first the proposer or sorry the Challenger posts the BLS key of whoever was supposed to be the validator of that slot as well as their validator index and along with this it sends two proofs first is the proof that in this case if you see we have a proposer index in the beacon block but in the beacon State well we basically end up having BLS keys of the validators at respective indices so whilea aoral proof we have to make this connection that hey this proposer index actually belongs to this particular BLS key or BLS public key and that's the step two and then in the next step the validator or once again not the validator the Challenger needs to prove that this is the proposal index that is present in the beacon block as you can see here the second field so very simply with two simple Merkel proofs you're able to get whoever was the BLS the BLS key of whoever was the validator in the current slot or the pre the slot that is being challenged and well once you get that you can just go ahead and make check if this inequality is actually satisfied if it is then well the look ahead slot is incorrect and you can slash whoever posted it along with that we have slashing of bad prec confirmations which I think was touched upon by ahmmed but in this case if we want to expand it we have execution pre- comps that could be bad and we could also have bad inclusion pre- comps in the case of execution proms well the proposer did push the eventual block that he pre-confirmation that was not actually preconiran-food.com that was on the P2P and in the case of inclusion pre comps that's a bit more simpler we end up getting different proposers for the same block ID because it might have happened that well he pre-confirmation no on the inclusion can happen that I do for I don't might turn five away but someone incl before and then the pre proposer would have really is that true yeah so in this case we actually have uh discovered a few issues so another variant a more simple variant of your issue would be I precom and I don't include it but then for a long period no one actually includes any block so what happens is we a long time passes and the dispute period gets over so even though that there is no pre-confirmation there is a pre-confirmation but there is no Associated block like the block ID has never really progressed on chain and and that's an issue but you can't really uh prove the incorrectness of this so we have a way of doing that and uh that is so we might have to go back to so let's say this is like the slots okay so whenever uh a pre-confirmation is being made we also include a look ahead pointer which basically points to Which slot in the look ahead am I prec coming for so in this way what we have to do is we have to make a connection between the uh pre-confirmation and the proposed block why are the look ahead I think now that answers your question because if we have that look Ahad pointer that basically states which look ahead slot have we made the pre-confirmation for and if it lands on at a different time on uh on the L1 we can make the inequality okay but but is it possible that I pre-confirmation prec confirmations I I don't know if that makes sense I mean not really because you are prec because the proposer is once again the I mean this is Advanced proposals I mean you just put it in you just release it in the public me pool and it might happen that the proposer does not included but then your slot will be coming in so if you go back to this slide that Ahmed uh presented in this case when your slot comes in you clear all those pending transactions that have never been included because the proposer didn't want to include but your slot has now arrived so you pick those transactions and you force includeed whilea the inclusion list through the uh PBS pipeline yeah the the other answer to this question is that the previous pre- Comer um cannot uh like that the previous slot and if if you're talking about if if this slot is for prec confer 2 to precom at the the precom one cannot then go and push transactions there every slot has an assigned pre-c Comer and only a specific pre-c Comer can uh push transactions or batches in those slots so the contract will just ignore any batches that arrive from pre- Comforts that are not assigned to these specific slots okay perfect any more questions no I think we can touch upon the future work now yeah um all right so first we start with soft blocks So currently what we do when we advance the head is that we push a whole full block to Tao and in this way what ends up happening is that it goes and lands in the canonical chain and this is normal and this is why those transactions are then removed from the mol so when you propose the next block they don't get included twice so that's one thing um the problem with this approach is um is that when you we are proposing these blocks at the end on L1 we need to propose multiple blocks so for example if I pre-confirmation this is costy proposal and verification of these blocks is costy for a block proposal it cost around 200 um 200 um 200,000 gas Anu right yeah give or take and um around 400 for verifying the ZK proof for a single block give or take as well uh could be a bit more than 400 more closer to 500 so every block that we end up proposing is is is adding a lot of cost for proposal and verification so what did we end up with is a solution where when you precom um you're going to add the batch to taoes push it and then when you push another batch what it ends up happening is that it gets added to the block instead of being so it gets appended in the block so what happens is that a new block is formed with the previous transactions that are in the block and um the new transaction batch and the previous block gets reorg out and then we include the new block and this keeps happening until the precom node sends end of end of pre-confirmation or uh and then this block becomes a standard block and gets pushed to L1 as a whole single proposal and this gives us the cost saving that we're looking for but it's still not finalized something that we're going to hopefully work on the next couple of months another thing like uh our friend here asked about before is the slot time uh for the L2 So currently we have a constant three block second block time and what we're looking for to accomplishing is one second walk time and it's not that this is not possible currently it just hasn't been tried yet and we're not sure what limitations we're going to hit with the P2P Etc yeah and then in the last one I think you will talk about it yeah so when I was talking about the pre-confirmation service manager contract I said we are trying to make it like a middleware so that as and when we want to change the reaking service or the staking service we can just swap it out and use a new one and in regards to that the community is planning to launch a universal pre-confirmation registry so chances are there will be many more based rollups down the line not just Tao and when you have so many based rollups it could be the case that one proposer wants to propose or pre-comp for multiple based rollups but it doesn't really want to register continuously because that will cost him a lot of gas and also it won't be that credibly neutral because might be the case that every rollup starts up its own staking service and and that's not reasonable for the proposer and that's a waste of eth not a good use of collateral so in this case there will be a universal pre-confirmation registry where any proposer who wants to become a pre- confer can go in register the BLS mapping instead of being in the protocol owned registry it will be here in the Universal pre-confirmation registry along with that so the slashing condition optin this is a very important aspect ECT so the uh rollup protocol like whether whoever makes another base rollup wants to have might want to have their own set of conditions based on which they want to slash so maybe they don't want to slash inclusion proms they want to just slash execution pre-s so they can Define their own slashing conditions and then only have those proposers who have opted into these slashing conditions be prec confers for their roll up so yeah this is still an ongoing discussion in the community and eventually there will be we will be specking it all out and releasing it but yeah that's it's going to be a while well that's it thank you so much okay there's a question here how do you see this integrating into existing kyc systems or rather the path to scale and adoption on the side of us users and institutions I'm not sure that's a question for the session yeah all right so any questions final how's how how do I evaluate the security of a say I I probably doesn't care if I send million I if they say right so what you're asking about is the fair exchange problem and this is something that our research team has been looking into for quite some time now um as of now we don't have a solution for the fair exchange problem um and I think most of the existing or proposed Solutions depend on a reputation system as of now where um if the pre-c confer or the Gateway providing the pre-confirmation um uh is acting maliciously they would this would affect the reputation in a bad way and they would potentially be uh cut out of pre confing for the specific protocol they're working on and this would potentially lead them for losses so they the reputation B system uh being proposed for now but we are working on a non- reputation based system where there is um some oversight over how the pre-c comers are acting and if they are actually pre confing in the correct time providing pre confirmations in a timely manner without like um delaying the pre-confirmation by the you from coming from the users or um um like reordering transactions uh with this delay to to to just generate more meev or or profit for themselves there's another question here what kind of slashing conditions do you see is it a penalty or more tougher so I think right now our slashing condition is very straightforward we just slash the entire stake which is not ideal and it's definitely not going to be this eventually I think there was one there is one proposal by the research team and that's we have let's say slash tickets so for every pre-confirmation that you provide and every validator that you register you have a a fixed amount of stake so for pre-confirmation let's say you are staking one eth for every pre confirmation that you provide and once the pre-confirmation is settled you can basically reuse those tickets but if you mess up that reconfirmation only that one e amount will be slashed and not your entire stake so this is open for discussion and one once again I think this is a part this will be a part of the community-led discussion of how seriously we want to slash a a a malicious prec confirm uh sorry how do you think uh distributed validator technology fits into your prec confirmation design do you think it could make it much more secure or have have you guys looked into that H so in DVT I'm not entirely sure about the block proposal and how it works exactly so uh I I know that for the attestation uh multiple uh like three out of four nodes they need to sign basically to get a proper signat a BLS signature and um I think it's kind of the same for the proposal but I'm not sure how they choose which one of the nodes is the one who is responsible for forming the block so honestly no uh we have not looked into how D DVT would interact with with this protocol at this moment uh because also DVT does not form a significant um like um share in the market of proposers as of now so it it it would it might not make sense for us to look into it in a serious um in a serious manner but potentially if it becomes more popular then yeah this would make sense you have any website for networ metri how many subscribed to this kind of stuff are you measuring life or I mean this is not yet on Main net because firstly we don't even have the pre- compiles yet we need to have the prra grade so it's it's running on testnet on Helder testnet uh have you heard of Helder testet it's a devnet which was released during each CC so Tao already has uh not the final version but one of the intermediate versions running on Helder providing pre confirmations but once again that's a devet so it's only the validators that Tao is running but yeah this this was tested using 300 validators and it worked great yeah okay thank you might if you can speak to the mic because I didn't hear half of what you said yeah how just how do you decide how much you pay for the pre-conference to post the roll up blocks because there might be multiple base rollups and for the slot and they might be compete for this pre same precom so for the payment we have we have lifted up for the market and because we decided that the priority fee will be used then basically the preconference will just not prec confirm transactions that are not profitable um so any transactions that are do not have a high priority fee that is paying the [Music] pre-conferences blob which is basically now free one way to to get a blob as of now um the the the more I can make money so we lift the pricing to the market to decide um there are some research that is going on in the space by Connor um and Lynn from nethermind and there's another guy I think called Finn Finn yeah uh I don't know their full name so I apologize for that about the economics of pre-confirmation and the pricing for pcoms ETC and this work um there is a lot of talks that Connor Finn and Lynn has been talking about pre-confirmation um I advise you to go check the recordings for these Talks by these people they're BL they're they touch exactly on what you asked about thank you how do you think of do you think it improves it uh is that a reason for concern um personally um like meev or not me um the the protocol works with local built blocks and also works with forced inclusion through PBS pipeline the only problem here that I see is that if relays and Builders decided that they're not going to adopt the constraint API that we talked about because it basically reduces their income because pre-confirmation are not profitable enough compared to what they can include other than these transactions um then we would have a problem but as of now and as we uh as we heard from our partners is that there's a lot of talk and the Rel layers and Builders are agreeing to add the constraint API um to their pipe to the epbs pipeline so they would be potentially uh including pre-confirmation to add to this we I think we also have plans for L2 meev extraction so when that is added to this I think the dynamic changes a bit Yeah so basically since we have like currently 3C and potentially 1 second uh uh block times for the L2 in this one second you can the the pre- comfor still at at well can re order these transaction but we would not expect every prec Comer which is basically just an L1 validator to have thetic the sophistication needed uh in the software and in the hardware to be able to support such ordering in one second and I think what's going to happen is that there will be an a PBS pipeline for L2 blocks if this uh protocol gets adoption that will that tries to extract M from these L2 blocks in this 1 second slot sorry last question uh what are the latency figures that you guys have regarding like the block transmission from the preconference we don't we don't have that yet because as of now we have only Dev Nets and Dev Nets are basically just U curtosis uh setup uh instances that are running on local machines I mean we have Helder but deployed a hybrid solution between Gateway precom and our solution so our smart contracts but Gateway software basically and um as of now that that's what no that's that's deployed in Hilder yeah okay yeah so that's what deployed in Hilder right now so it's not the same and we don't have that distribution of of site cars running so we can calculate this this latency we can do some simulations po potentially but yeah reality always is is different than simulations do we have more questions think not all right that's thank you everyone for having for for for attending