RollCall #3.1 Breakout: Shared Sequencing

Transcript

welcome to another roll call breakout call today um we have a very interesting episode we have Justin Drake here um to to host and lead the the call on um basically all things shed sequencing pre-confirmation based rollups basically this entire the theme complex that he's been thinking about quite extensively um I'm very looking forward to that and uh I'll just off I mean I don't think I have to introduce just much he's one of our star researchers at the the theum foundation has been doing a lot of work in this in the past and uh

yeah Justin do you just want to take it from here yes thank you Anar um so yeah today we have a lot of time an hour and a half so I I hope to make it very Interactive this talk is really for the rollups um so ethereum sequencing and shed sequencing more generally is all about rollups opting in to some sort of shared sequencer and I think there's a bunch of technical issues that we can discuss but I think the bulk of it is actually an education and a coordination and incentives problem uh more so than a technical one so I hope to go through a lot of content

and uh please interrupt me as the as the presentation goes along just just just may we can wait few more seconds because someone just mentioned that the zoom link was never actually shared in the telam group I just did that but it could be that a few people might need a few seconds to see that and come on okay perfect let me know when it's good to get started yeah you can you can probably goad now okay perfect thank you Anar so the talk will be uh split into three parts uh first I'll talk about uh

shed sequencing generally and in my opinion the killer feature of shed sequencing which is synchronous composability and then I'll talk about uh pre-confirmation specifically because I think pre confirmations is a feature that every single rap wants it's a feature that users demand and there's a question of how do we do pre-confirmation in a decentralized setting as opposed to having a centralized sequencer and then finally um I'm going to talk about base sequencing which is a special type of sequencer uh which also has these decentralized uh pre-confirmation so one of my I guess Visions is that uh we have these United chains of

ethereums um similar to an a union of States like the United States um where there's freedom of movement and freedom of Commerce um I'm hoping that on ethereum we're going to have this diversity of chains of rollups and validium but the friction from moving from one to another the friction of doing business with with one another is is extremely low and I think in order to achieve that uh we need shared sequencing so so what is the killer feature of shed sequencing in my opinion it's this idea of of synchronous composability so if right now what we have is independent rollups that are are

siloed um and what I want you to think about is basically time progressing from from top to bottom so execution roll up a is siloed from execution roll up B which is siloed from execution in RPC and one of the things that shed sequencing allows is for synchronous um composability meaning that for some period of time you actually have the rollups be synced with each other you can think of it as as locking from the perspective of of State basically if a user finds it valuable to have synchronous composition across multiple rollups what I call a super transaction then they have the option to pay for that privilege um and the shed

sequencer who has Monopoly to build blocks for all the rollups in in parallel uh can actually fulfill uh this this this demand from the user and so in some sense um shed sequencing is about going from asynchronous composition to synchronous composition and kind of capturing this Delta of of value Creation in the process um and you know the synchronous composition doesn't have to happen at the very top of the block it could happen you know mid way through the block and it doesn't have to be something that is permanently happening and actually almost by necessity can't we can't have every single rollup locking on every single other rollup

otherwise you know we would only have the scalability of a single rollup so what I expect will happen is that the vast majority of the time um you know the transactions will consume resources in one single rollup everything will be processed in a purely parallel way but then every once in a while when the some sort of an economic opportunity that mandates that there's actually additional value to synchronous composition then there's going to be these virtual locks that are basically placed by the the the Shar sequencer on these on these executions so if we if we zoom in to like this little section of the diagram so we have the two rollups rollup a and

roll B what do I mean by U synchronous composition so I'll basically give an example imagine a super transaction which is made of three subtransaction so you have a subtransaction a which kind of starts the super transaction and then you have this middle uh subtransaction on roll at B and then you have this final um transaction on subtransaction on on on Roll app a and the important feature here is that like there's these strong synchronous relationships between these subtransaction so for example you could have a withdrawal of asset here from A to B you could have a withdrawal of asset from

from B to a here you could also have um some action here on Roll app a which depends on the result of a call on r at B so for example here you could be reading some some State on roll at B and then you're basically passing some sort of state route to R up a and then depending on what's Happening Here you do an action action here and one of the things to to notice here is that in order to have these these synchronous um kind of calls between rollups uh in a totally trustless way meaning that rollup a shouldn't be able to to trust B and rollup B shouldn't need to trust rollup a you basically need ZK proofs so you this this

here produces some sort of of of proof it's settled immediately there's a withdrawal and then same thing here when this subtransaction here executes there's a corresponding ZK proof that allows for this withdrawal to happen immediately or if you're reading data same thing it happens immediately and then now they can have an action that depends on on this data and once you have this kind of really luxurious setting of synchronous composability which we enjoy today at layer one right any contract can synchronously call any other contract then you know in my opinion on locking uh value so yeah feel free to to to stop me

at any point in time if something is is confusing now um one of the one of the things that we need to ask ourselves is around around these these zero knowledge proofs that I talked about like it takes time to produce zero knowledge proofs and so let's let's look at a specific example let's say that we want to do synchronous compos ability at within these three rolls at the very top of the block so this is it turns out to be the the simplest case and the reason is that let's say um we have the the shed sequencer has has 12 seconds that's the the slot duration it doesn't have to be 12 seconds but let's assume it's 12 seconds um well if if this um you know

the computation here let's take say takes takes one second well basically you have 11 seconds to produce the proof so the for for settlement I mean the all the Zer noge proof for settlement so here you have a quite a lot of of time to produce the Z knowledge proof but on the other hand uh here at the very bottom if you want to do synchronous composability like very very close to the end of your slot then you have almost no time to produce the the the snar proof and so what I expect will happen is that initially the synchronous composability will be kind of more towards the top of the slot but then as we get faster and faster proving it will unlock value towards the end of the slot like notice

that the colored uh execution which kind of doesn't depend on execution from other other roll apps it's okay for the proof to come in the next slot it doesn't have to come in like immediately in in in the current slot now one of the things I want to highlight is that um I'm extremely bullish about low latency proving I think that within the next two three years go ahead can I can I interrupt and and ask yes for sure yes why it doesn't have to come in that slot uh right sorry I I need to configure my zoom so I can see who's asking a question but uh why doesn't it have to come in in that slot so the reason is that so just like today uh you

basically have a a decoupling of of U of you can have a decoupling of the the data and the proof so you can you can you know post the data on chain and then settlement can be delayed you know some number of slots uh and basically um if you have a rollup which is which is progressing independently meaning that it doesn't the execution doesn't depend on inputs from other rollups then it's it's actually okay for this settlement to be to be delayed um because because it's just that the same situation as today where you can put the data and then you can prove it later lat on

y thanks but as as soon as you start depending basically you're adding these dependencies between rollups well if you want things to stay trustless and you don't want to do like these massive reorgs and and roll backs then then you need this this real time proving to keep the the trustless I have one more question on on this uh trust so if we have hup A and H up B that have this cross chain um crossup transaction yeah but colp a did not finalize the block the blue blocks because one of the previous block uh is invalid and this we will learn like a while after block uh

the block is produced because the finality in the H is not instantaneous it means that the the block is reverted so for h b we will have a dependency on R A for its own finalization uh right so what that's a good point like you need um basically fast settlement so what I'm claiming is that um either you need real time settlement meaning that you have settlement in the current block or you know you can delay it to the next block so basically if if you if you if you're the shed sequencer in slot n then you can mandate that the shed sequencer in

slot n plus one needs to provide the the proofs for the execution that hasn't been proved in slot uh uh n but yeah you're right like we don't want to be building on top of of unsettled um uh rollup execution and so like at most you want the the the the proof to to be delayed by by one slot but you know one slot today seems like very very short right because these Zer knowledge rollups uh sometimes take minutes or sometimes hours to produce a proof uh but we're we're getting that a very very fast pace so I guess there's two types of realtime proving There's real time proving on the order of one slot and then there's like the super

super fast real-time proving on the order of milliseconds and I think we're going to see this first type of proving happen relatively quickly like maybe you know this year even okay thank you now why are there like reasons to be optimistic about realtime proving I one of them for me is this this notion of folding schemes so Nova which is a public paper published in 2021 and which largely ignored for a couple years um is kind of in some sense revolution in my opinion because it allows for maximally parallel and maximally efficient uh SN proving um and it kind of led to this

whole uh you know class of literature around f schemes and in my opinion today if you're working with elliptic curves then like it's almost a no-brainer if have if you're starting from a fresh code base it's almost a no-brainer to to start with uh with folding schemes given like how how mature they are and like and and how efficient uh they are um they they seem to be efficient not just aseptically but down to the constant so basically if it's roughly speaking the the the Prov cost is is one MSM of the size of of your statement that's it just one MSM um so the constant is one you can't you can't improve it and there's

there's no ffts and it's a a really nice approving scheme um and then the other reason to be kind of bullish on on low latency proving is that we're we're starting to finally see uh proving as6 so the first one uh was released this year uh this month actually by axal but there's two other teams uh size Asic and fabric that are also working on on as6 that should come this year so so basically what these A6 will unlock is like this really like super low latency like 100 milliseconds or less and so you could you can have synchronous composability very very close to the end of the slot here okay uh part two unless there are

questions uh regarding regarding part one so yeah I have a questions of 100 milliseconds you mentioned per block or per transactions or per super transactions yeah so um basically what I expect will happen is that these proving schemes will operate on the order of like one cycle or one up code like some very small amount of of uh of computation and then basically use this this recursive technique to to process one cycle at a time and what we what what we need is that uh the the the the proving latency is on the order of 100 millisecond so the proving will happen in real time so

as the sequencer kind of chooses which which transactions to sequence and as execution happens basically and sequencing happens in parallel the proving also happens so actually as a consequence of this I think it's relatively likely that we're going to see a merging of the sequencer and the prover so that you you have minimal latency uh between these these two things um and what you want is the proof system to to have very low latency so from a Frid perspective obviously you need to have the the proving capacity to to to prove you know 12 seconds worth of execution within 12 seconds like every single rollup does that otherwise the prover would start falling behind

but um now that we that we can catch up in terms of of frut and we need to kind of optimize latency and uh I think there's already like massive strides that are being done on on that front uh but I'm expecting way more in the months and years to come thanks okay great now one of the um open problems you know a couple years ago was how do we de decentralize pre- confirmations um oh Muhammad do you want to ask a question sorry yeah

yeah uh yeah I was wondering why you need this proofs really real time like suppose you have a super transaction and it calls into the other roll up and it expects something back why we can't provide this you know like intermediate state or like value of the call back or whatever optimistically and only at the end of of the whole is slot we prove the whole thing yeah so um a few things here like one of them is that um you do want to provide like one proof at at the very end just just because like imagine that you're

processing thousands of transactions per second like you don't want to have one zero knowledge proof every time you make a deposit and withdraw so what I expect will happen is that uh for each roll up there's going to be one proof and it's going to be a an aggregation of all the sub proofs that you need in order to have all the execution and um from a from a computational standpoint this this proof will arrive at the end of the slot but what the what the sequencer can do is that they can basically stuff it at the very beginning so once they've computed it like and they they they you know build the actual block that goes on chain they put it at the very beginning

and they they verify it first so up front they verify they kind of make a claim that you know this execution is is is is correct kind of pre-state a pre-state one postate one pre-state two postate two pre-state three postate three so it's a proof about all these pre-state and proat one per roll up um and then um nothing has to happen optim optimistically uh because it's all kind of proven proven up front so does that answer your question yeah it's can answer but like

basically I was wondering so the way I understood your uh scheme is that when a super transaction happens we are going to have this micro snark proofs that assured you about what happened on the other rollup yes yeah exactly yeah yes so the Green Arrow back I expect is carrying a a snar proof or like so I was wondering why this is necessary uh yeah I understand if you want to be really real time like doing execution and proving at the same time this is what you want especially with Nova and fing this yeah so the sequencer has full control over what the sequence will be

for rollup A's a rollups a b and c so you're right like they can work optimistically because they trust themselves right so um you know let's say that the proof latency is is 2 seconds well then you know for for for two seconds they're kind of going to optimistically sequence things without the zero knowledge proof and then the zero knowledge proof only comes at the very end but if the if the latency is let's say two seconds what it means is that in these last two seconds there can't be any synchronous transactions like the synchronous transactions have to be in the first first 10 seconds um great you have the th thumbs up which means that you're liking this answer um makes sense I guess one one

thing that I'll I'll mention which is really cool here is that um we're actually using me to incentivize low latency proving right because one of the problems that ZK Wes have is like how do we incentivize proving um and the really cool thing here is that in some sense you have to do nothing like me does a job for you um because the more latency the faster you are the less latency you have the more synchronous um composability you are going to be able to sell to users um and so that's that's kind of a nice property to have uh Lisa sure I understood if uh this shared block will happen at the same uh Time

Each slot or it's kind of on demand um yeah so it's it's it's on demand um and what I expect will happen is because there is an overhead to locking uh the the user kind of has to explicitly opt in to pay for it or it can happen implicitly if you have an Arbitrage or whatever now one of the things I uh that's interesting is is how how much do we expect users to have to pay so let's say that um here um you know while this transac on rollup a is executing you see nothing's happening in rollup B it's like this this black stuff so rollup B is basically blocking on roll up a and here

vice versa you have this transaction HP this transaction happening on R up B and roll up a is just twilling its FS it's just is waiting it can't progress and so what will happen is that let's say this corresponds to you know 100,000 gas and that this is also corresponds to 100 F guest then at at a minimum the user will have to pay 100,000 gas on WAP B and 100,000 gas on WAP a uh so basically pay on both of them simultaneously plus you know potential overhead for even just creating the lock in the first place um and so economically speaking um you know if you're going to be consuming

resources on multiple rollups at the same time you're going to have to to pay for it and if there's this blocking aspect uh then yeah you're definitely going to have to to pay for it um how then do rollups communicate with each other onree that this is the right moment for a super block so the the rollups are not in control of sequencing um the RS are in control of execution and they're basically delegating sequencing to some some shared sequencer and and the the shared sequencer for some for their slot they have Monopoly power to do whatever they want um and what they're going to do in my opinion is that they're going to act rationally

and so they're going to try and sequence blocks in such a way that they maximize the value of the block um and they're going to use signals from users saying you know I have such and such intent uh and I'm willing to pay for it and so they will honor these intents if that maximizes the value of the block but they're presumably they're maximizing their own Revenue not the value of the block right um yes they're maximizing their own Revenue but there's a very strong correlation between these two things uh but yeah happy to have this discussion offline for sure um uh got gotfried I think sorry Andreas you had your hand yeah

sorry thank you appreciate that um really quickly so when you lock let's say you you on the super transaction and B locks a right so then a has an opportunity cost of like to 10 seconds correct right because if you allow a to process any other transactions that one of those transaction might modify the target state of the super transaction right which can't be because I need to rely as an as an issuer of a super transaction that that that that my target state is not um um is not um modified isn't that isn't that isn't

that correct uh I didn't completely understand the question um you it so let's say I I'm I I want to to to I see I seen Arbitrage opportunity on like Unis swap on arbitrum right yeah um from and I'm on on ZK sync right just like let's let's make it really concrete a arbitrum and base yes arban base whatever yeah so so I want to move I want to move I want to put a put a swap on on on arbitrum with my funds from from from base right okay but if I if if um so I submit that transaction with a

commitment that it's going to be executed against the current state of of the of the unit swap liquidity pool at that at that point in point in in time because I'm like buying the buying the the now that means that that arbitrum needs to identify all the transactions that are going against that liquidity pool during the Locking period right and put them after the that that uh that uh um that uh super transaction because the super transaction paid for or is paying for the privilege of of of having of having having locked Target Target state if that Target state is modified by a by a

transaction that that happens during that lock period um then the the the user with the super trans transaction so me wanting to do the the swap on on Unis swap like gets a gets a worse price so you're basically doing doing you can do sandwiching attacks and and and front running um attacks um right oh if you if you if you if you if you see that because you have to have you know you have a shared meol at that point so it's like that that that gets that gets really tricky so you have to basically lock down the rollup for the super transaction for that for that for the period of time or they must

be able to identify the transactions that are coming in that Target the Target State otherwise um um otherwise you're basically telling the the yeah issuer of the super transaction why you know why you paid for a tough luck okay so um I still didn't completely understand the question but let me try and say something that hopefully is helpful and maybe we can talk about this more offline um one of the things I'll say is that um yes there is some sort of shed menol but that doesn't have to be a public menol so just like today when you have a centralized sequencer there's no public men pool right the the user and the shed sequencer are communicating directly with end to end deson and no one sees the the transaction and uh and

actually as the surfice the the centralized sequencers provide me protection the um and so one way that you can kind of replicate this uh well the end to end encryption with the sequencer is very easy right because we're going to know who the the shared sequencer is and so there's going to be an IP address that you can call as as a user or as a as a wallet the other thing I'll mention is that that um you can use account abstraction to make sure that your intent is properly expressed so let's say you have a super transaction when involve three legs uh you know leg one on rollup a leg two on roll up B leg three on rollup a again and you know you you might you might want uh like these

three things to happen either all together or none of them so basically you're creating some sort of of super bundle um that's the kind of thing that you you you you want to constrain as as a requirement so that you don't you don't get unbundled and one of the things that's that's really cool is this idea from uh from polygon called the aggregation layer where you can do exactly that uh yeah another thing I'll say is that like this super transaction should execute extremely quickly right on the order of you know micros um because you know each each each constituent transaction you know takes just a few

microseconds and so uh so that you shouldn't be there shouldn't be like multiple seconds of opportunity cost uh but yeah more than happy to continue this discussion offline uh got fre yeah maybe it's a stupid question but there is one thing that I'm wondering I mean in ethereum way basically where we have synchronous calls we have everything is on a single state basically and you have the opportunity to roll back in case of error here if you imagine the situation like one you have on the slides where basically roll up a does something passes appr proov over to roll up b roll up B does something depending on whatever the proof says then there's a proof going back from roll up B to roll up a but now imagine that in the third

transaction on rollup a here there is some kind of error happening and which would necessitate basically undoing whatever happened on roller B um is there any way that this can be sort of achieved without basically enshrining some kind of right chain roll backs right so you know as I said like with the polygon aggregation layer you can basically have these three sub transactions like either all execute or the whole thing is invalid like each each of these three are invalid now if let's say this the super transaction is invalid because the last leg happen to to be garbage then the sequencer is just paying for the data to get these these three sub transactions on chain but it's

not getting paid for anything because it will just be you know rolled back and so really what the shed sequencer should be doing is that at the execution and sequencing level they should build these optimal blocks and you know potentially reverting uh whenever the transaction fails um but then once it's it's like made the decision you know I'm actually going to sequence this and I have confidence that it's a value transaction it's fee paying then at that point you know does the the the proving process start um and again like you don't need the proof to come in real time here they the Bas the proof basically needs to come by the time the block is published for settlement so from a Time

perspective it only needs to be generated towards the end of the of the slot here Coman so just to make sure we are trying to enforce synchronicity on the protocal level and not just the economic Builder level right uh only the economic sequencer and Builder level not at the yeah okay thank you so each each rollup in some sense is just the same as it is today uh the rollups don't have to do uh at least the ZK rollups they don't have to do that much uh they stay you know Sovereign and independent there's no like polluting of security assumptions if you know if rollup a blows up and the

hacker withdraws everything then roll at B is is is completely isolated these are like totally trustless relationships okay decentralized pre-confirmation um so I was saying that yeah this two years ago I would have said this is an open problem but uh in some sense like there's there's this obvious solution which uh which which makes sense so the obvious solution is let's imagine that we have a decentralized sequencer what is the the definition of a decentralized sequencer it's one where at every slots you have some sort of rotation of who's doing the sequencing so in a centralized sequencer you know it's the same entity

every single slot doing the the shed sequencing decentralized sequencer just like at if you're layer one you have a rotation of the layer one proposer here you have a rotation of who's doing the sequencing but in any given slot it's the exact same situation there's a there's a one single well-defined actor who has Monopoly power to do the sequencing and so in some sense it's the same situation as a as a shed sequencer within those 12 seconds and so what a user can do is that they can say okay please you know see uh pre-confirmation and and sequence it and then whoever the the the the shed sequencer is for this this slot n well they can make a promise that they will

um execute this this transaction at a specific position and I use the emoji 1 12 3 4 here because uh it's kind of ordering the the transaction and you know you have this look ahead here which means that you know who will be the shed sequencer at any given future slot um but really you only need to you only need a look ahead of one slot right because the user slot n only needs to know who the shed sequencer slot n is in order to make this request and get a pre-confirmation promise now the way that shed sequencing is sorry pre confirmations is done today is using uh reputation as collateral so you might have some sort of entity uh

some some sort of labs um maybe the team that that built the rollup initially that that's that has a lot of reputation at stake like arguably like hundreds of M their reputation is worth hundreds of millions if not billions of dollars because if they were to start you know rugging users then all the users would leave and the the value of the token would would go down uh but in a decentralized sequencer that you don't have entities with reputation and so you kind of have to use uh you know economic direct economic incentives with slashing um so basically the the deal is that if as a as a shed sequencer I provide a pre-confirmation a promise of a pre-confirmation and the user is is

not happy because their pre-confirmation was not honored then there's going to lead to to slashing and there there there's two types of of slashing fults one is a safety fault meaning that as the shed sequencer I promise to sequence you know a transaction but instead I I sequenced another one so it's like completely different some what actually happened is completely different to what I I promised and then there's this more subtle Edge case um fault which is a liveness fault where the sequencer made a promise but then when it was time for them to honor their promise and to actually build a block they they went offline so they got really unlucky like it in within the the few seconds uh that they had this

responsibility they kind of went offline uh and and here they also have to to suffer a penalty but that's more of a edge case then this this first one should never happen the safety fult should never happen if you have an honest uh shed sequencer and preconiran-food.com Whoever has monary power to maximize the value of of of that slot um and uh that that leads to to to me boost and and and PBS being one of I think in my opinion like the most

natural outcome but uh various other people might might might disagree but I I I'd like to keep that for a separate discussion so what I in terms of okay how do we modify MF boost to make it work with pre-confirmation so the way that MEF boost works today is that we have um blocks kind of traveling in One Direction so the builders build the blocks they give them to relays and then the relays relay those blocks to the to the proposer but now we have this new entity in the picture we have the user and the user has made you know uh has received promises from the from the proposer and really we want the the blocks uh to to to respect these these

constraints from the users and so what needs to Happ happen is that these promises need to travel all the way from the user to the builders through through through the relays and so what I expect will happen is that s this should say sequence shed sequence and not proposer um what will happen is that like the shed sequencer really should be communicating every single promise that they make to the to the relays and to the builders and then at the end of of this of their slot they basically ask the builders given all these constraints build me the most valuable block possible so it's possible that at the very end there's some back running or something that extracts a little bit of me and the builders are the most uh uh you know natural players to do that and

you just need to modify M boost a little bit so again there's there's no need for you know any enshrining or hot Forks or anything you just need to do a simple modification uh to MEF boost so that Builders can can be aware of these pre-confirmation and build blocks that that adhere to them one kind of detail here is that if the sequencer is collateralized um let's say they have a thousand e of collateral uh you know that will that will back the the pre-confirmation while the builders also need to be equally collateralized and the reason is that the builders might build a block that doesn't respect these pre-confirmation

and the the sequencer will get slashed and now the needs to get compensated by the Builder because it's not their fault and so uh the the Builder would also get slashed but the slashing uh the money would the collateral would go to the proposer um and when the when the sorry the sequencer get slashed there's actually there's two possible things either you can just completely destroy the collateral or you you can have more of an insurance mechanism where you you give it back to the users uh that were that were affected by these uh violated precc confirmations okay so this is kind of my summary slide on centralized versus

decentralized prec confirmations the big difference is that on with a decentralized sequencer you have this rotating uh sequencer on a slot by slot basis uh the slashing is uh reputational for centralized sequences and I think it will become like purely Financial for in a decentralized setting and then um kind of one thing that kind of changes pretty dramatically is is how me is handled so right now we basically have a an encrypted meol which is you know potentially first come first serve um and uh you know because you you can rely on reputation you you can have these policies that that are

enforced but you know when you move to a decentralized setting you know it's possible that these policies can't be enforced so cleanly and so you fall back to to PBS at least as one of the one of the options here uh which ends part two any questions just could you clarify what it what is the promise that a pre-confirmation is making to the user include is it a promise that their transaction will be in an L proposed

block or is it a promise that their transaction will be in the canonical L2 chain right so the the sequencer has full control over the content of the blocks and so they can give the strongest possible promises available which is you know a promise on an exact State rout so basically uh you know I will execute your your transaction and when your transaction executes this is the postate route um of course the the the user might not need uh such a strong pre-confirmation they might only need uh some sort of intent to be satisfied so for example they want to know you know

what the they might play some sort of limit order like I'm willing to pay X for this Swap and I'm willing to pay why for fees and like so long as you can satisfy this intent then I'll be happy uh some users might might have something even weaker which is as you said just inclusion like if I'm doing a a transfer let's say a simple transfer of E from A to B then you know I care about getting the green check mark on my wallet but I don't I don't care what the postate route is because the my my transaction is totally independent from all all of transactions sure could could I clarify the question the question really is um is how can an l one proposer guarantee inclusion in

the L2 chain right um what if the L1 what if the L1 block that they propose which is consistent with their promises turns out not to be canonical on the L1 chain okay so at this point in time uh there's no L1 at this point in time um so the we talk about shed sequencing and it's like some abstract virtual shed sequencer there's not L1 like the L1 comes in in part three where where we talk about base sequencing but the the way that uh that it works is that basically every R La has given has opted in to give sequencing rights to this shared sequencer um and so by construction like they have mply power

to the individual proposer has the power to make a block canonical yes um yeah I I apologize it should not say proposer it should say sequencer so whoever whatever the sequencer is whatever blackbox uh has the rollups have opted in to for for sequencing that that entity here has Monopoly power to sequence I see so there's some kind of consensus protocol wrapped around this and the individual proposer promises that that consensus protocol will reach consensus on a block that contains this users result um Yes again I apologize for putting the word proposal here it

should really say that there's no propos forget proposers um this is typo um the proposers come in in in part three so imagine it's a sequencer uh like all the rollups have given you know through their settlement contract the the Priority Access for this this sequencer to to sequence transactions and and therefore that entity has monary power and therefore they can give pre- confirmations of the strongest form possible which is pre- confirmations on execution but if you have these rotating proposers or rotating entities how can one of those entity make a promise that anything will be canonical in the consensus right

um well okay um one of the things that they can do is they can give uh pre-confirmation that are conditional on some sort of parent uh so that's that's one possible outcome and like another possible outcome is that there's some sort of uh you know single thought finality uh you know fancy consensus um and this this is what espresso you know was was building initially where you have this offchain consensus with like Ultra fast finality and so um I as a as as a sequencer for slot N I have very strong confidence that slot n minus one will be canonical because it's been finalized in

very low latency um like these the yeah these two approaches are kind of complimentary so you want F finality uh because that gives you more confidence on what the parent is but you also as a sequencer only want to give pre-confirmation on on the things that you have power over like you don't have power over what is canonical um you have and so the the the pre-confirmation can be conditional on the parent now if you look at uh you know things in practice um you can design consensus algorithms that where you have very strong confidence on what the parent is meaning that with very high probability

there there won't be a reor and so there's basically two cases like the the case a the happy case will happen 99% of the time um and uh and you know the user will be completely happy and in the 1% of the case something weird happened there was a reor or Miss lot or or high latency or whatever and one of the services that the sequencer can provide is basically insurance against this 1% uh Edge case and so for example let's say the user wants to trade on Unis Swap and they want to know exactly how much they're paying uh both in terms of execution price and in terms of fees and they'll get that for 9% of the time and in the 1% of the time where

there was some strange event reor for example the the the sequencer can basically provide a a a a a second pre-confirmation on this other event where it says you know I will actually guarantee you the same price and if there's a Delta between the two uh I will pay it out of pocket so it it I think from a ux perspective it would be a bad outcome if um every time you ask for pre-confirmation there's these two cases like case one is is the parent block is kind on the call in case two the parent block kind of got reared and it's an empty slot uh and the good news is because one of the the events happens 99% of the

time and the one only happens 1% of the time you can kind of abstract away uh this Edge case with with insurance but uh one of the things I'll I'll say here is that um these are the kind of problems that need to be solved regardless of the the the shared sequence um now I have a very specific thesis which is that we should consider using the L1 as the shed sequencer but um and in some in some sense like all of these details around prec confirmations are are details uh implementation implementation details that are orthogonal to to the broader thesis I guess of of uh of Base

sequencing uh Connor you have your hand up hey so yeah just in this in this case specifically I guess in this there won't be any value to capture for the for the builders in this the shared sequencer case so so yeah I don't really see why you need the proposer the Builder or the relay ah right I see so basically what you're saying is that um if transactions are kind of handled almost first come first serve like they're kind of preconiran-food.com time then there's very little relevance for the builders and that might be the case um I

guess uh one one of the possibilities is that the the the promises that are made are kind of these weak and fluid uh promises so for example like I I promise you a certain price but I don't promise you a certain position in the block and so there could still be opportunities for Builders to reorder things and and like do some back running and do some Arbitrage or whatever it is um in order to just squeeze out a little little bit of drop of me but you're right like maybe maybe this is not worth it and we can just radically simplify and just remove the relays and remove the builders and only be left with this this sequencer sorry so so you're moving to a 10 based sh sequenc what

you're saying yes I mean no sorry a joke it's a joke I think intense yeah makes makes sense actually one thing I I'll say here is that if if you're providing promises on execution with a postate route then this is extremely non-scalable and the reason is that the user comes in with the requests it requests a specific postate route and that's blocking so if it takes 100 milliseconds just for the communication between the user and the sequencer then you can only process one transaction every 100 milliseconds which which is which is really bad and so at the minimum you want to you want you want access lists right so that every user er only cares about the little

piece of state that they read and write to uh but you can do even better where sometimes you don't care about the ex the exact value of the state you only care about some some intent some abstract intent being uh being satisfied uh payment hey uh could you please go to the next slide yes yeah in this one uh in the M1 I'm pretty confused about because like you mentioned that for centralized sequencing we have uh like encryption and for decentralized one we don't need encryption and like PBS works but to me like they're not really exclusive they solve different

problems with like I don't know encryption we have execution privacy and like PBS can work for both of them like uh yeah just wanted to hear your thought okay let me clarify you're right this is this is sloppy so in both cases the user is dealing with a a well-defined entity um for that one slot and they can use SSL to have endtoend communication um so I guess SSL should be there in both cases but the real difference is in terms of incentives so the the shared sequences so for examp the the centralized sequences I know of Labs or something like they they don't want to be rugging their users they

don't want to be sanding them they don't want to be exploiting them and so they've just decided you know as a policy uh that that they won't be uh they won't be extracting this type of of toxic meev um but in a decentralized setting it's it's much much harder to to to enforce that like in what tends to happen in decentralized settings is that like you have these this much more like local locally rational actors that you know in this one slot I want to maximize as much as possible because I I only get selected you know once in once every few months for example and I want to make the most of of the of the slot that I just that I just won um so in

some sense like we're playing different games like in the centralized case it's a repeated game because every single slot is the same entity and like there's there's these indirect incentives with like you know billions of dollars of of tokens where here in the decentralized setting like you can analyze the incentives on a kind of mic microeconomic level as opposed to to a macroeconomic level and as far as I can tell like if you want to maximize the value of your block then you you're going to you're going to invoke PPS in some way or another yeah I guess like my confusion was like you mentioned like encryption is for centralized and the other one is like for like de Central

but in centralized one as long as you are putting your trust in like arbitr sequencer you don't need like probably encryption with the like PBS uh but in decentralized setting like you can have encryption for preventing like toxic M because just PBS doesn't PR right and having like top of block auctions right for like good Arbitrage and like good maybe so basically both of them are for decentralized setting and for centralized you can have some kind of separation for the powers of the centralized sequencer but it's not like necessarily the the need right I mean the M protection here is provided using you know trust and reputation and if you

want the same kind of safety then yeah you want you might want a system where the the sequencer never sees the con the plain text of the uh of the transaction until after they've done the sequencing so you can have a threshold decryption or delay decryption or SX based decryption or whatever it is yeah uh yeah to to to totally agreed here uh but again like this this is a problem with decentralized sequencing in general in some sense it's not my problem even though I am uh you know happy to to to help solve it like any decentralized sequencer as far as I can tell has this has this issue uh

Lynn yeah I have a question question about the uh safety fault slashing so um when you I can see that you can slash like when you promise to be in like the third slot of a block and you can slash that but what happens when a pre- confirm lies about the state like how do you slash that onchain do you require some onchain fud proof or yeah for yeah I mean even even for the promise that the position is number three you still need some sort of unchain for proof so basically what will happen is that the when when the user received the promise they receive they cryptographically sign receipt and then the receipt is the fra

proof that they submit on chain yes but like for State you actually need knowledge about the BM to actually like verify the fraud proof so yes it sounds like for every single BM for every rollup you need a fraud proof system for and it sounds like pretty complex thing to implement um so no the the the the fruit the fraud proving and the pre-confirmation like uh collateral can be separate so you can have n rollups that have each opted into a Shar sequencer and then you have this this additional contract for pre-confirmation specifically and like this this contract can read State roots that are settled so let's say that the

promise was you know that this state rout is X on rollup a and then it turns out that rollup a settled State root uh you know y then now the user can submit on chain a receipt which is cryptographically signed by the sequencer saying that he promised that the the the state rout on roll up a would be X but it turned out to be Y and therefore he gets lashed well your transaction can be like between these settlements so like the state rout that the R up of the sequence or or the pre- confer signed can be like in the middle of this two commitments and yeah so you can unroll

the uh the state route so once you have right once you have the postate route for the whole block then you know that that fully deterministically gives you the whole chain of of of inmediate postate roots and then you you can you can match arbitrum St like fullblown um you can actually do it in a single single round so basically uh you could have the user say the user submits the the the the receipt as a fraud proof uh and then it's on the the sequencer is now challenged to prove consistency of

the receipt and what was settled and and that could be like a one-hot SN for um and so you you you don't need many rounds of interaction just just one one one round of challenging it could be simpler than that to if if the proof include medicalized you know commitment to the intermediate States then you just point at to one of those and provide a mer proof and say say this is my transaction but the preate is something yeah you could do it in like one shot like the user just provides a one shot proof of uh of Mal from the sequencer I see thanks uh

POTUS yeah I also had a question about the slashing uh I left it in the chat uh I don't understand the difference between uh safety and liess if I hold two different SL two consecutive slots and I gave a pre off for slot n and I just happen to go offline and I cost a safety p in N plus one how much do I pay yeah that's a great Point um um so in some sense from the point of the view of the user they don't care if it's a safety fault of life this like they got they got rugged either way um I think it's just a bit of a technical like distinction and maybe also a probabilistic one like this should never happen if you're honest uh this you know will happen but with with low

probability and so um yeah I mean one one of the things you could do if you want to be super fancy is um you could uh you could have some sort of consensus mechanism uh you know like espresso is trying to do where you know the slot n+ one uh you know is constrained by the pre-confirmation in slot n even if slot n happens to be reared um but yeah I I agree that from the point of view of the user like these are both equally bad um and like one way to size the collateral um is is to think of the maximum value of a block if uh there was no

constraints from pre-confirmation and actually we have historical data on this from from me boost which is that the maximum amount of me in any given slot is is is less than a thousand e so this is why I keep using the the Thousand e number uh because you know if if you reneg on all your pre-confirmation then uh you know you you you can make you know up to a th000 e in in in in in me um and you're right that if you have a Miss slot uh as slot n and now the proposal as slot n plus1 can do whatever they want then that's effectively the same as as as as a safety fault and so I what I would do is I

would also punish maybe the livess fault for thousand e uh but what I expect will happen is that these sequences will get sophisticated and they'll be able to to price this risk uh that's one but also they'll be able to minimize the risk of of of life this fault so on ethereum L1 like the reason why there's Miss Lots is because uh people submit too late that's that's that's basically the reason in some sense it's it's it's the fault of the of the of the proposer of operator like in theory you could have like these these periods of like very high asynchrony with the ATT testers but in practice that that basically doesn't happen it's it's it's all it's basically always the fault of the operator and so

if you have a lot of value at stake from missing a slot then you're going to be damn sure that that you're going to be off online and you're going to submit your block on time and we have Daniel with your I just wanted to hear a little bit of how you're thinking about the centralization of the builders because right now we have you know polygon zkc arbitrum in the future we're going to start having more and more of these hyper chains or cdk chains or op chains and and the sort of de facto situation starts being that any Builder should start running every single chain that exists in the entire ecosystem to maximize their me to maximize like the chance of them being

able to propose and I'm I'm just kind of curious of your thinking behind that because yeah like you can't sort of like with with me boost you can decentralize that or you can distrib that with open source with server resources you can't really distribute that so it just ends up being a few entities in the world that pay a ton to to be able to run these and I just wanted to hear your thinking on that right um so one of the observations is that you have extreme centralization even if you have to deal with one virtual like execution environment or one virtual machine so if you look at uh the evm L1 evm today there's extreme centralization at the Builder level you

have a beaver build with like 40 or 50% and then there's uh Titan and arn that have almost all of the rest um so basically three entities are controlling the vast majority of blocks U two of which are censoring by the way so it's it's not a a pretty situation um what I'll say is that what we're trying to do is to design the consensus layer in such a way that the Builders can't do harm so you know we can try and list like all the all the pieces of harm that they could do like they could censor they could go offline they could try and do all sorts of things and it turns out that for every single bad thing that I'm aware of

you know primarily censorship but there's other things that they could try to do we have solutions for uh so for example inclusion lists is um helps with helps with censorship and so one of the I guess the My Philosophy I guess is that we we've kind of accepted you know Bild decentralization as as a natural market outcome but we we've segregated it from the validator so we want to make sure that for example the centralization of the builders does not leak or pollute the the validator set so the validators can still be running on the Raspberry Pi on a smartwatch like they need almost no uh no computational

resources um now one of the questions we is very reasonable to ask is what if every chain has its own independent kind of PPS and so now the builders only have to run one full node well I actually think that's that's not that's not uh kind of e economically um to be expected and and and the reason that the amount of me that you can extract is a function of how much information you have about the world um and in some sense the builders you know they want to be maximally connected to centralized exchanges for example

because they have more and more price information but they also want to be maximally connected to all the other chains because there's going to be economic activity happening there and there's also going to be you know interactions with there's going to be you know Bridges and there's going to be asynchronous transactions and not only that um even if the rollups don't explicitly opt into a shared sequencer what we might see is a a market of that kind of naturally emerges kind of at higher level something like suav where the proposers can like trustless sell like the sequencers can trustless sell their sequencing slots to the highest bidder um and in some sense this this Mega Builder which builds all the rollup

simultaneously is an outcome that's going to happen either way whether or not the roll apps explicitly opt in uh to to to this so like My Philosophy is that you know I accept the build de centralization but I want to make sure that there's there's no negative uh externalities to to that centralization the one thing that I will say in ter that that remains in terms of negative externality is is mimetic right it's a really bad look that 90% of block is built blocks are built by three entities and I think the the best answer to to that is is education right right making people understand that actually is not so bad that because they can't cause livess failures they can't cause

safety failures they can't do front running they can't do censorship but yeah it's going to be an uphill battle um and in some sense it's similar to to the centralization of the mining pools in Bitcoin right there's like three mining pools that control everything it's really a bad look for Bitcoin but you know they moved on and uh whoever is interested in in Bitcoin understands that actually the mining pools don't have that much power in the grand scheme of things I guess the only concern is it removes the May it doesn't it removes the optionality of me being like a medium block Builder I understand the centralization I understand like if we can stop censorship through CR list if

we can like have um like threshold encrypted M Pools like I understand these Concepts but it removes me the option of me being an irrational economic actor not always accepting like so what is a medium-sized Builder it's a Searcher right what is a Searcher is one that specializes in a specific subset of the overall wealth State um now Searchers nowadays they specialize in individual contracts or individual strategies but they can they can specialize in individual rollups um and so in some sense you're just moving up the stack of abstraction and um you have you have the mega Builder but within the mega Builder the sub builders which you

could call like rollup Searchers and then Within These these uh rollup Searchers uh you have like contract Searchers that that work on the contract by contract basis for example so yeah I do expect that PBS extends further you know to search a SE propos Builder search a separation and and and and as you add more and more levels it is fine for like relatively less sophisticated entities to to specialize in one thing and be very good at that and and actually that's what we see uh in practice so um what tends to happen is that Searchers there there's no Searcher

that's good at everything every Searcher tends to be good at one or two things and there's like 100 Searchers and then as a group uh they they they build optimal blocks okay we have about um 20 minutes um so I'll use that to um to talk about base sequencing which in some sense is like the the big finale of of this Vision so um we have part one and part two which in some sense um is is orthogonal to to to this last part so if you think from the point of view

of a of a rollup um there's kind of two resources that you're consuming from etherum there's etherum settlement and eum date availability and the the claim that I'm making today is that there's actually a third resource that you have the option to consume if you want to as a rollup and that is eum sequencing and the reason I put this little new Emoji is because you know it's kind of this mental unlock where you realize ah yes this is something I can go consume but actually it's been there from from Genesis it's been there all along and it's it's only now that we realize that you can consume it and in some sense this is similar to affirm data availability right there's call data and for the for many many years like half a

decade people didn't realize it could be consumed by rollups and then suddenly we realize ah yes uh you can you can raps can consume that for for for for data availability um now the question is like why would you want to consume ethereum sequencing and basically in some sense the the answer is very similar to why you would consume settlement and data availability so you get best-in-class security you get best-in-class credible neutrality credible neutrality is especially important with shed sequencing because you want some sort of sequencer where every rollup and that competitor feels comfortable opting in um so arbitrum and optimism and whatever base and scroll like um like for let's

take an example let's say that arbitrum uh launches a shared sequencer and they say okay sequencer is like credibly neutral well guess what like scroll is going to say well you built it that alone makes it non-red neutral and so the fact that we have this this this sequencer which you know has existed um since day one it has the same branding as ethereum it has the same security is is is is a big upside and then I think a really uh cool unlock is that um not only can can we have synchronous composability across the rollups but we can have synchronous composability with the L1 as well now if

you really zoom out and you look at the big picture of of tvl the vast majority of tvl is on the L1 so there's about um uh half a trillion 500 billion dollars of of tvl on L1 with e with ec2s and with nfts and if you look at the the next kind of largest sequencer by tvl that's the arbitrum sequencer uh I think they have on the order of of 10 10 billion or 20 billion so it's like orders of magnitude you know between one and two orders of magnitude less than than L1 and there's these Network effects that with with with tvl and and and and shed liquidity and so I think we're potentially going down this this

dangerous Direction Where where in order for the rollup to be successful they kind of need to start eating into the the tvl of of the L1 and and you start breaking these Network effects especially when you have these these like super linear um economic effects like um like the the the the the quadratic effect of um oh damn I forget the the law um uh Mel's law there you go so Mel's law is a very simple model saying that you know the the economic value grows quadratically um with with the number of nodes or the number of some some some size some notion of size anyway this is

why you know I claim that using FM sequencing is is is valuable and now the question is like can we actually do it concretely in practice and also can we do it without the hard fork and I think the answer is yes to both of these questions we can have rollups consume AUM sequencing as a shed sequencer and we can do it today without the hard fog so how do we do it well basically we have have a subset of the L1 proposers so this is where the L1 comes in that opt in to becoming Shar sequences and the way they do so is by exposing themselves to slashing conditions so they put forward collateral um and they become shared

sequences in this in this protocol and so if you look at the the look ahead there's 32 proposal in look ahead and only some subset of those 32 uh will be will be shared sequences so for examp Imagine The Proposal slot n plus one and the proposer n plus 31 have exposed themselves to these slashing conditions now those who have not expose themselves to sling conditions we're going to give them a different name we're going to call them includers and the sequencing rights are going to be given to to sequencers as as as as we'll see so let's say you have a user at slot n uh

who wants um to get a pre-confirmation from from this this new set of of of of from basically the the based sequence so so what they do is that they communicate with the first sequencer in the locco head so that would be the one that's n plus1 and they get the request and promise uh from from from them and then once they have this promise what they can do is that they can share it like any some party can share it with the includer as l n and the includer as SL n can immediately settle it so even though at SL n um none of the sequencing rights

are given to that proposer that proposer still has the option if they want to to immediately uh include and settle uh transactions so what I expect in practice is that you're going to get a 100 millisecond um pre-confirmation and with and basically next slot settlement which is which is optimal for for ethereum and yeah this is the the same picture that that we had like how do we modify MEF boost we basically have these uh these promises uh share upst shared Upstream to the builders that will constraint how the blocks are built and and one of the

things I want to highlight here is that when the sequencer is a proposer there's a bit of a potential problem which is that the L1 proposer is running on a raspber pi is like very very decentralized and has very small amount of resources like how can they be a sequencer because we we said that a sequencer you know they need to be running all these full nodes at the minimum they need to have enough bandwidth to support you know thousands tens of thousands hundreds of thousands of transactions per second they need to have very high up time very very low latency all of these things which goes against the them being running on a Raspberry Pi and so this is where the idea of execution tickets come comes in so there's this great write up by Mike

that I encourage you to to to look up um it's ET execution tickets hence why there's this alien and the idea of the execution ticket is that there's a a new entity called the execution propos proposer who explicitly opts in to buying these execution tickets and when they win the the execution ticket lottery they are the L1 execution proposer and they can be extremely sophisticated because they've actually opted in to buying buying these tickets and then the the validators can no longer be responsible for sequencing at L1 and everything is good uh but this requires a hard fork and so we need some sort of solution in

in the short term and the the solution that I'm proposing here is basically to introduce a a new entity uh called the gateway uh Matthew came up with this this name the the Gateway and I guess it's a distinguished name from from relay and the idea is that the the proposer who has sequencing rights here is delegating their sequencing rights to to to the Gateway so the the the Gateway has um um has the sequencing rights so for example the proposer ahead of time kind of signs a message saying I'm giving my sequencing rights to this Gateway and now the users when they want pre- confirmations they

go and interact directly with the Gateway and then again just just like before the Gateway kind of interacts with the relays and and then ultimately behind the scenes the builders and so now the Gateway is collateralized uh again against um safety faults um and there's this Edge case that we need to handle which is liveness faults because now there could be whenever there's a liveness fault we don't know who's who is at at fault is it the Gateway that's at fault or is it the proposer that's at fault because now there's like two entities that need to collaborate in order to honor the the the the pre-confirmation and it turns

out that this this can be solved with trust in the exact same way that there's a trusted relationship between the proposer and the relay so in Mev boost um the proposer is actually trusting the relay to be online for the get payload uh request so basically there's this potential Edge case where the relay responded to the header the proposer signs the header and then the relay goes offline you know in the the few like milliseconds and then they they can't respond with the with with with the header with the payload and it's the exact same thing here basically the Gateway provided signed all these pre-confirmation and then they kind of

they go offline just before the proposer is meant to build that to propose that block and so now um the the proposer can't honor these these pre-confirmation and basically what I'm what I'm suggesting is that we we have a a similar trust relationship between the proposer and the Gateway and actually maybe the the most natural way most natural solution here is to collapse these these two and have the Gateway be a some sort a a preferred relay by the proposer um so I believe that the the relays are already like um very well suited to be to be a Gateway here now I have one final slide but only

have 10 minutes so I'm happy to answer questions now uh or or go to the to to the to the final slide I guess my my final slide is a bit of a philosophical one which is that we have uh sequencing that we need to solve as as a community um and I think we all agree that we want to move to decentralized sequencing and the vast majority of uh you know open problems from a technical standpoint are specific to to to to to decentralize to to to decentral sequencing now within decentralized sequencing there's some problems that are specific to Shar sequencing right

Shar sequencing is a specific type of decentralized sequencing and then even more specific we have base sequencing which is a special type of shared sequencing and um I believe that most of the problems let's say 80% of the problems are specific to decentralized sequencing you have to handle me me pools intents ofas pre- confirmations data compression all of these things and then with shed sequencing like there's a few new problems that come up but most of them are are specific to decentralized sequencing so one very good example is me sharing when a rollup Ops in to a shared sequencer they are basically giving away me to the shared sequencer and one of

the things that espresso is working on identifying where the me originates from and kicking it back kind of giving it back to to the rollup that created it so with shed sequencing you have new problems like me sharing and that's something that's being tackled there's also something called deposit sharing which is this really cool idea by ZK sync which is that if you have um two rollups and you want to do you know withdrawals and deposits across these rollups well it's kind of wasteful to go through the L1 every single time and so so what if we had a shared deposit contract where all the assets were

deposited and now whenever you do a cross rollup transaction you don't touch the L1 it's all settled through the L2 and it's extremely cheap and efficient from a gas perspective and then there's this idea from polygon uh which I briefly mentioned ahead of time called the aggregation layer which gives you this this next this level of safety uh for for cross rollup bundles and then there's the the base sequencing which you know I kind of got went through the the design here and in some sense it's it's only opinionated on one thing it basically says that the very end of the me pipeline uh terminates with the L1 proposer and the

cool thing is that most of the problems are not at the base sequencing level they have to be solved at other layers and there's no Fork uh required and that's the the end of of my presentation a and we still have a few a few minutes for questions uh Lynn so I have a question about the includer that you mentioned yes so when you say the includer settles you mean that they settle as in like the L2 State rout correct yes okay so in that case if the pre confer lies about the position not only is the pre-com invalid but the

settlement will be invalid and or then in that case what would happen right so um the sequencing rights are given to slot n plus one and the sequencer says you know I'm going to promise to put transactions ABC in positions 1 2 3 and then these these promises are gossiped and so now it's perfectly safe for the includer to go settle transactions ABC at positions 1 two 3 because that's what the sequen said uh they wanted to to sequence now one of the things that is definitely possible is that the the sequence are equivocates right like they made

promises for transactions ABC um but then like it turns out they they they also sign off transactions a prime B Prime C Prime um and in that case they would get Slack for for a uh for a safety fault uh and and the includer would have the option if they're aware of of both of these they have the option to either settle ABC or a prime B Prime C Prime it's up to them what they want to settle in either case they're completely protected because the fault came from the sequencer not from them see Lisa do we have any constraint on how many blocks

uh from different rollups uh each uh Gateway can promise right so um let's say that we're in this situation we're in slot n and the next proposer is in slot n plus one then actually the the proposer can can make promises for two slots right they can make promises for slot n and for slot n plus one so in some sense they can cover 24 seconds worth of me and you know 60 million gas uh at at most now one of the things that you need to be careful of is making sure to not overpromise so uh because this this

sequencer only has 60 million gas to work with they shouldn't promise more than than 60 million if they were to promise 70 million then they're guaranteed to get slashed now another thing that they need to make sure is is uh um you know only start providing promises for 30 million gas and above um after the includer has included the the first batch of promises um so so yeah like what the what the sequencer needs to do is basically provide a small tip to incentivize the includer to settle the transactions so that now they can start uh providing um uh

pre-confirmation for 30 million gas and above between 30 and 60 million gas so we can end up like if there are not too many um gateways we can end up in the situation when there are a blocks ER from rollups who have to wait because we just don't have a um gateways in Within These 32 thata defined ah great question so are you saying that it's possible that in the look ahead which is 32 slots like there there's just zero uh shed sequences like

there's none of the proposers here have opted in and so basically there's there's there there's no sequence there um in which case like pre-confirmation break down um now one of the things I I do want to highlight is that the includers in addition to settling transactions that have been uh uh sequenced and and and and preconiran-food.com executed by slot n

plus1 now in terms of making sure that there's at least one uh pre confirmer in the look ahead you need about like 15% uh in order to have high probability that there will be at least one um preon pre-confirmation or 128 and that's just a constant that's a super easy hard Fork the other thing I'll mention is that there's actually an incentive uh in the very early days to become a a Shar sequencer and the reason is that you get

to control many slots and therefore you get lots of me for these for these rollups so for example here this shed sequencer would get two slots of MV and this one here assuming this is all gray would actually get 30 Slots of muv so in the very early days you making a ton of money from me uh because you're one of the few providing the service and another I guess piece of good news is that 15% you know potentially can be can be handled by one actor so if coinbase for example says you know we're from the goodness of our heart we're going to bootstrap this pre-confirmation infrastructure uh even if we're there's going to be very low fees or whatever like they can single-handedly do that or maybe Lio could uh could help out with

the initial bootstrap yeah makes sense thank you I still have a question about the includer um so when there's a transaction ABC and the prec confirmer pre confirms ABC but actually posts the data of a prime B Prime C Prime which one is the canal which one is correct the includer can only settle transactions if they've been signed off by the sequencer so if they they say please include a prime B Prime C Prime then they can force inclusion just similar to an inclusion list if there

censorship for example but they can't guarantee that a prime B Prime C Prime will be in position 1 2 three um that will be up to the sequencer to choose the positions of of transactions a prime B Prime C Prime so it's that if they don't do a prime B Prime C Prime then yeah then that that is a a slashing violation so that would be uh a livess fault because they wouldn't be able to to build a block which satisfies the inclusion list and and therefore it would have to be like some sort of empty slot you know from the point of view of the rollups and they would get slashed so the whole that patch will be invalidated in that case yes I mean there's there's a bit of

a design detail here which is that if the shed sequencer kind of has a liveness fault like do you do you execute the transactions uh in the inclusion list or or do you do you just trash them um there's reasons to do both well either um like one reason to do it is that you have more more more of a of a of a liveness Guaranty and better sensorship resistance but the reason to not do it is that now you're you having me with in the inclusion list itself um I mean maybe the best the best uh design is to keep them around but now put the the constraint on execution on

on this shed sequencer basically the next shed sequencer see that makes sense thanks okay amazing I think we're actually at time now um there is a dedicated call for Bas sequencing and pre- confirmations with about 100 people in it um that's happening every every couple weeks so do do let me know if you want to if you want to join these calls there's already three calls uh they're all recorded on YouTube there's also does and uh there's also a telegram group um if you if you want to join that

as well thank you so much for for your time and uh looking forward to to chatting more thanks you