Ethereum Sequencing and Preconfirmations Call #1

Transcript

okay uh welcome everyone uh to the first um sequencing and the pre-confirmation call I mean it's number one but it's technically the the second call um the agenda for today is uh to go through a quick presentation um where I hope to dive as as deep as possible with you today on the details of of Base sequencing and and Bas prec confirmations uh I hope to keep the presentation fairly short so that we have as much time as possible for for the discussion uh I'm going to try and keep the discussion um to one hour so we're going to we're going to end exactly at the hour uh but if you want to stay longer uh for the after discussion uh that will that's available

as well um the I'm going to record the the zoom conversation uh all the way to the end uh but the very last part part the after discussion will not be shed publicly on YouTube only this this first hour okay so let's get started with the presentation that I have uh prepared and welcome to everyone who uh just joined in okay um so eum sequencing with with pre-confirmation

I'm going to H give the part the talk in in in two parts uh part one is going to be trying to give context and motivation and then part two actually give technical details of of the construction so the way that I I think of the opportunity at at play here is uh is the United chains of ethereum this is a term that was coined by bankless um and the idea here is that we could have the various rollups the various chains all live together on on a shared land with with with low friction so I can think about it as um freedom of movement or or freedom of Commerce if you go from one state to another you

don't have to show your passport or have a Visa you don't need to pay import duties or or taxes or whatever it is there's uh there's very low friction and we've shared sequencing uh across the chains this is something that we can achieve especially once we have a real time proving with with SNS so at a high level uh etherum provides uh two services for rollups today it provides settlement and data availability uh but there's this new resource uh etherum sequencing which is uh going to be available very soon I mean new is may be a bit of a of a misnomer because it's been there since

the very beginning but people haven't realized that it's there to be tapped into and somewhat similarly to data availability right um people have abused core data in some sense and and used it for for a function that it was not initially uh intended for now in terms of sequencing problems which is a very big design space um there's some that are you know specific to to decentralized sequencing and in my opinion this is where the bulk of the the research is I think everyone agrees that we want to move to decentralized sequencing um but then within decentralized sequencings there's even more specialized sequences so there's the concept of a shared sequencer which

I guess is a special type of decentralized sequencer and then a base sequencer which is even more specialized and so when you study decentralized sequences you have to worry about many different things you have to worry about meols MV Builders intents you know how you do data compression how you do proving Etc and um again that's where I think most of the the research is when you move to shed sequencing now suddenly you have problems um like credible neutrality like me sharing deposit sharing and execution sharing so um just to highlight these three real quick me sharing is when you have rollups that generate me and you want to try and

identify the M that's been generated per rollup and rebates back so by default if you don't do anything me goes to a shared sequencer uh but espresso is working on on a mechanism to identify and rebate me deposit sharing is an idea by ZK sync which is very interesting whereby um instead of having each roll up have its own deposit contract where you can deposit assets like like if uh you have a shed contract and the advantage here is that if you want to withdraw assets from Roll app a and deposit them to roll app B you don't have to go through the layer one so you save on on gas fees there you have less friction and finally there's this idea from a polygon which

is the the aggregation layer very clever idea whereby rollups um can express constraints on block validity relative to the state of some other rollup so for example rollup a can say this block is only valid if um you know some some State on roller B happens to be X YZ uh and this allows you to do cross roll up bundles that cannot be uh un bundled so you kind of have safe atomicity uh in in the context of of multiple executions but all of this um are not uh things I want to talk about today because today I specifically want to focus on on based uh sequencing which is using the base

layer ethereum uh for for the shed and decentralized sequencing so so now on to the the details of the construction so because it's it's base sequencing we have to start with the layer one proposes those are the ones that are doing the sequencing of eum today and on the The Beacon chain we have this notion of a look ahead where we can see ahead of time who are the next 31 32 uh proposers actually it's between 32 and 64 so there's this look ahead and what we're going to do is we're going to invite some subset of the sequences to um step up as sequences some subset of the proposers to step up

as sequences and in order to to do that you have to post collateral and we'll talk about why this collateral is important later on I use the emoji one 1234 because it kind of shows this the sequencing of transactions in a specific order and then there's this other uh set of proposers which I call includers which don't have collateral they don't have sequencing rights but they they do have the right to include uh transactions on chain and um those can be either you know sequenced or unsequenced transactions that can go on chain okay now the the Big Technical Difficulty for which there's been an unlock recently is is how do you do

pre-confirmation at you know using using aerum uh proposes and it turns out you know in hindsight the design is extremely simple uh and and and here is it works so let's say that we're in slot n and we have this this user um who who's also at slot n and that user wants uh their transaction preconiran-food.com and then the the sequencer responds uh

with a promise a promise to have that transaction be executed in a certain way so for example if the transaction is a unisoft transaction the promise will be on the price that was paid and you know the exact amount of fees that was paid by by by by the user and um once the user Has This Promise then that transaction can actually be settled and included in the next slot in slot n so even though slot n is not a sequencer it is an includer and it can include uh and settle immediately uh transactions that have been that have been um and so if there was a promise and the

user was violated then we have slashing and there's two types of uh slashing there's slashing for safety faults and slashing for liveness faults uh safety faults just says that um a proposer um pre sorry a a a pre-confirmation of them um must not have occurred and therefore we can slash and if you're an honest pre-confirmation some punishment there even though it

could be a different amount uh than than the the safety faults Justin can I stop with a question yeah absolutely let's say take your example of somebody promising a Unis swap trade with some parameters and execution one failure and he's you know the promiser the promise came from slot n plus one now slot n includes it but the end result is different okay so some change the number take something out this is a different type of failure that the promise is fail but it's neither that you mentioned how do you think of that great question so one thing that I should have made maybe more explicit is that the

sequencer here as saw n plus one has Monopoly power to sequence transactions between the head and the end of their slot so let's say at n minus one the state has been you know fixed so all the rollups at a given state well for the next 24 seconds because there's two slots for 12 + 12 for the next 24 seconds the the sequencer has full control over the ordering of of transactions and so there's no one else who can advance the state of the rollups it has to be signed by the say the proposers of the L1 rather these

are Slots of the based rollup or which could be one and the same but only the sequencers in green have the right to sequence them and the gray includers can include them but only based on the sequencer of based on the sequence of the next sequencer did I get it right yeah that's exactly right so the rollups opt into giving sequencing rights to the subset of L1 proposes um and everyone else uh can only include and settle transactions they can't uh sequence them H great question thank you so we have the slashing we have the

the pre-confirmation uh requests and Promises all good now we let's have a look at Mev boost and how that changes the game uh with respect to to block building so right now we're in a position where the block Builders have Monopoly power to build you know blocks well they have not Monopoly power but they have they're un constrained in terms of what blocks they can build in any given slot they pass those blocks to relays and then the relays forward those blocks uh to to proposers but now we have this new actor the user who got a promise from the from the proposer who happens to be the sequencer and the and the need to be

communicated ultimately to the Builder but we can do that through the relays so we have this back back pressure this back Channel where every promise that's made uh to users gets communicated upstream and then the builders once they have all those uh uh pre-confirmation they are tasked to build the most valuable block that respects those constraints so more likely than not these pre-confirmation are going to constrain the top of block or the top of blobs in the case of rollups um and the the builders have to build the the best block possible and then the same flow happens through the relays and through the the the proposer and this is a very nice and and and and

and simple design especially in the context of execution tickets now what execution tickets uh give us is they basically make sure that the proposer is not a validator so the execution proposer is actually some other separate entity that's very sophisticated and the reason why execution tickets is very important here is because right now we're assuming that proposers are validators that are running on rasb pies and in order to be a to be a a precon and a sequencer you have to be extremely sophisticated you have to run a full node for every rollup you have to have very high bandwidth to you know be able to to have tens of thousands or hundreds of thousands of

transactions per second you need to have very high up time you need to have denal of service protection etc etc um and so with execution tickets we have a nice design but what about uh without execution tickets well without execution tickets like my proposal is to introduce a new role uh called the the is that they would ahead of time they would register saying you know this is my favorite uh preconferences the one Edge case that we

have to worry about is liveness faults and um what I'm suggesting is that basically the the proposer is on the hook for livess faults because ultimately they have to be online and and propose a block uh because they have monopo power to extend the R1 um but they're trusting the precon fer to be online uh if they've provided any pre- confirmations so if the pre-con fer has provided pre-confirmation they want to make sure that the proposer can propose a block that respects those prec confirmations and so what I think is a a reasonable um you know placeholder for this temporary

pre-conferences a little bit stronger and that that's pretty much it that's the end of the presentation and I guess we can open it up to to discussion and and questions um second yeah go ahead um so by the way love this this is pretty much in line with how we've designed the precom and Mev commit but one um one one consideration that comes into play is um the the the state of the the mempool which the Builder has visibility into so in this area where we enforce the Builder to um create a block with the preset transactions then I believe this

model is great however that might end up in situations where the block value is suboptimal for the validator uh and then when you have um the Builder kind of incorporate the the precom knowledge with the visibility into the mle that they have then you can kind of optimize the value for the validator however I'm not sure if this is a um a role that the protocol needs to own so I just wanted to bring that up right so one of the nice things is that a lot of the details of prec confirmations in some sense have nothing to do with uh with base sequencing like any sequencing mechanism with pre-confirmation will have to deal with these Integrity details now I guess one of the things I'll say is that um you're

right that any constraint on the block that's imposed to the Builder will mean that ultimately the block is less valuable uh because you're constrained so your your search space is smaller and um the way to to make it incentive compatible is basically to have a pre-confirmation tip so you have a tip that's paid for the privilege of constraining the the search space and this tip needs to me commensurate to the me impact that that transaction has so if it's a a transaction like a transfer that has no me impact then you know a 1-cent tip will be fine um that's rational to just collect the free 1 cent but if it's a trade for example on a DEX

and it's one that goes against the market that increases the Arbitrage opportunity the at the end of the slot then actually the it's actually rational for the the expected Arbitrage at the end of the slot they have to pay for the privilege of having their um Arbitrage transaction right the Builder does of what that Mev value should be or what the bid needs to be to to negate the Mev value aha right so one of the things that the pre-con fer needs to do is to price tips

appropriately and they shouldn't price them too high otherwise the the users won't be happy and they shouldn't price them too low otherwise the proposers won't be happy so it's a very delicate balance where they need to price tips uh properly and so the way that I Envision it is that basically the pre-con fer has some sort of um you know mechanism to price these tips this could be by working with with Searchers for example that act as advisers I guess uh or another mechanism and this is something that I believe cark from sella is investigating there could be a some sort of realtime auction where the searcher are build bidding against each other for for this tip and like buying the risk in some sense uh

which would provide more transparency more fairness and and be a market driven uh design uh Dan yes um question so in the setting where for like you know one proposer we have multiple pre confers um yeah I I believe that would be desired because if the user picks it then we would need multiple and so I think the complication there is like how they coordinate so that they can you know be sure of what state they're executing on right so I'm curious if you thought about that so and what I suggested um there's only one precon fer and you can tell it

by the the lack of s so Builders is plural relays plural users plural but proposer has Monopoly power over the next slot and the pre-con fer has Alo Monopoly so there's only one of them and in some sense you can only really have pre- confirmations is that if there's one of them and the reason is that we're doing pre- confirmations on state not just on transaction inclusion so if you're doing on transaction inclusion then sure you can just like merge the two sets but if you're doing pre-confirmation on state you could have two inconsistent transactions uh that can't Sim both simultaneously execute as promised and so in my opinion the best design is to have to extend the Monopoly power of the proposer to the and that's what we're going to have with

execution tickets anyway there just going to be this one proposer who has sequencing rights and it makes everything simpler and it's more powerful because you can do pre-confirmation on execution not just on inclusion okay that that makes it much more clear I guess my confusion was I I thought you said like users were picking the pre- confer and so no no no there's there's only one well defined and they have to connect to it so metamask as a wallet what they'll do is that they'll identify who who the next [Music] everyone can see like okay who deposited

collateral uh and therefore everyone can calculate okay who the next form price or value on the Block space so you can use the ticket um to get an implied value of like each each uh transaction or each unit of gas um in the block and you can use that to back out how much you'd want to charge for

I think that works for like inclusion tips but for me like each unit of gas is different right because depending on which piece of State you're reading or writing to yeah it gives it gives a floor it gives a reserve Flor then you would just run a simple auction over it yeah um to be fair I haven't like I don't have a fully baked auction in my mind and it's it's a bit of an open problem how to do that but if you assume the the precon sophisticated and can price it themselves as a black box then it just works uh Noah so I had two questions first of all what if the slot is full for that given slot do you just move ahead kind of like

if a airplane flight is booked up you just book the next flight down also our relay preconference incentivize not to gossip any of their transactions because for example if you're doing Arbitrage opportunities private order flow would be one of the main ways you can make more money because you know the information before anybody else knows it so wouldn't that be the same thing for a pre-conference SL a relay would be if they could give that to a builder that Builder would be able to price blocks at a better rate well a more profitable rate if they knew more information than everybody else so would that cause an issue of that right okay so uh first question what about four blocks so one of the things you have to be careful of as a if uh you know all your pre-firm

transactions go in slot n and then if they do then you have another 30 million gas specifically for your slot if you information request should be shared uh with with who again publicly did you say yep kind of like the public or yeah public information so the way I think about it is that um pre-confirmation should be shared at least I think it's

good practice to be shared immediately so as soon as some transactions problem is that as a user I'm willing to pay for pre-confirmation and I need to send a message a signed message by me but you know I want to receive the pre-confirmation because I want to get a little green check mark on on my wallet uh but there's nothing in some sense forcing the pre-confirmation are immediately gossiped then I can just check as a user

whether or not all the all the previously all the previous requests were fulfilled and and and properly shared it also helps I guess with uh you know with just basic transparency of the meol as you said um in terms of giving an advantage to to specific players um the thing is that all these pre-confirmation will eventually be given to the builders right so in order for the Builder to build a a valid block you know that respects all the prec confirmations they have to have a view of all the pre-confirmation so at the very least you know if it takes let's say 100 milliseconds to build a block they need to have all the information 100 milliseconds before the the the PBS

deadline okay Yuri um a few points and good that you're on the slide um on the last thing that you said there's actually an incentive to propagate as fast as you can the preons and it has to do with the gas limit so if you keep to yourself all the information then it might not be included by the includer before you or something like that so you're kind of like incentivized to push all the preons as you receive them so it gets included in the by the includer and then you have your own slot so may so you'll F the first 30 million it gets included and then you'll have more so I think forget

about best intentions or whatnot this is not incentive but the incentive is to use as much as possible so I don't think there is an advantage to keeping it to yourself and there is an advantage to propagating it to the Builder yes so at the very least like every slot you want to gossip towards the end of the slot all the preformation so far so that they can be included and settled so that you can do pre-confirmation for for the next slot now in this slide do you think like when I saw the slide my immedi thought was this is very similar to the latest like in inclusion list design basically have the proposer tell that like okay this needs to be includ are you thinking something along these lines yeah it's basic you can think of

an inclusion list as being a a constraint on the Builder some sort of proposer intent the proposer is intending for their block to have such and such constraints um uh normally inclusion lists originate from the proposer so the proposer kind of observes the menol and then build the inclusion list from that here it's slightly different the quote inclusion list is built uh from from from the users ultimately but okay but but it should like at least by this diagram kind like follow the same line like okay proposer somehow tell it to the Builder because it want it to get included yeah yeah yeah um and the last piece is on the economics and I'm probably going to argue against most of the people in this

call um you can't really price what's going to be the precon pricing what it would be and how would affect Mev at the end of the block 7 Seconds 12 second 5 Second into the future because because price fluctuate 10 times more during the slot than at the end of the slot so you can't really maximize it and any auction mechanism from my perspective actually destroys value and so you could do something if you want look how do we price it I think it's an entire sub problem to talk about it but if you charge some percentage on volume capture some take if flat fee for it it isn't a local maximum but you actually create more value in the surface so you'll get

more users for it Etc so those my point is only to argue it isn't clear how this would play out later in the block because nobody knows what the tries are going to be and so this would be best executed with charging a fee for that based on volume based on effect based on something right I mean the way I thing about it is that it's a future right an execution future and you know you can price it uh but yeah I agree it's a whole subtopic f a future you'll have an optionality you don't have to execute on it okay but like the special type of future where you have to execute

whatever it's called deliverable whatever um and and but yeah I agree with you we need like so much more analysis from from E economists but again like all this analysis around pre-confirmation in some sense is off is like separate from the based uh pre-confirmation discussion which is only opinionated about the the very end which is that the proposes are the shed sequences um kaido I think Ben can before me wait go ahead okay Ben it looks like you're up okay I'm up um can you can you go back uh one slide to the where you show the preconference

elected yes oh yes this one yeah right right so just to clarify you know the this proposal and I mean and you know I have a variation on this proposal but I want to make sure I understand all the details of this proposal so the um the the pre- confers they are anyone can so how do you become elected to be a pre-con fer it's not it's not synchronized with the proposer right it's just L1 validators are reaking and they they can they can become elected what is the election mechanism for for the pre-con originally it was that if you're if you're in the look ahead as a proposer then you are a precc confer but now you

were suggesting to have both a proposer and a pre-conference are like these are all different labels different roles for the same entity behind it and the entity happens to be an L1 proposer but um it can't be any L1 proposer it has to be specifically an L1 proposer that has opted in and that's in the look that's in the look ahead and has collateral right and so what's the point of this um the the relationship that you're describing between the pro proposer and the current um preuner in the look ahead um what would be maybe

just clarify what would be different if the rollup just designated the next preconference today maybe just clarify that yeah that's a great question and actually that's how the base rollup original design a year ago uh went ahead unfortunately that came with no no pre-confirmation so if you give the proposal at SL and the right to to sequence and they give promises then anyone you know they can just violate these promises and nothing will happen and so we need we need somehow the proposers to opt in to additional slashing conditions no no no that wasn't

the question so the question is now you have this mechanism where you have this look ahead of um yes of proposers that have opted in to be part of this pre-confirmation layer and you know the next proposer maybe it's not the proposer of the current L1 slot but it's the proposer of the next L1 slot and it's the next precon convert because the current L1 proposer has not opted into this layer right so why do you have to have any special interaction between the current L1 proposer and the current prec confer what if the rollup just designated the current precert as its sequencer just like rollups have

sequencers today that aren't the L1 proposer um why do you need to designate any special interaction between the proposer and the pre- confirm but that that's the question right so in order to provide pre- confirmations you have to have sequencing rights right if otherwise your pre- confirmations are are worthless um roll up would be designating the pre-con the sequencing rights not to L1 proposers but only to L1 proposers that are in this look ahead right only that the L1 proposers that are also prec yeah so this is the suggestion so those L1 proposers that are simultaneously in the look ahead and have collateral in

this case the green uh uh proposers those are the ones that have sequencing rights for the rollups okay so that is the proposal but then when you're on a few slides later when you show the relationship between a proposer are you doing anything special maybe one more slide uh when you show that there's a proposer and a precon Fert oh I see so this you're right like this label here should say it should say preconferences ah okay explain what this arrow means this is confusing okay I see okay so here the the proposer is the sequencer

like they have the sequencing right but they're not going to do the actual sequence quencing and pre- confirmations themselves there this is a delegation relationship so this entity here has the right and this entity is the one doing the heavy lifting and this is the proposer is the current Len proposer who may not be a pre confer and the proner may be the next no no no this is this proposer is is a proner and okay maybe I should maybe we need a different label here like this is some sort of delegate pre- confer it's some sort of preon help and why is that delegated what's the value of creating this entity the value here is that the proposer can remain on a

rasb pi and be a validator and that can be a very sophisticated entity it's basically proposer Builder separation but in this context it's like a new version of it it's just offload complexity so that the actual proposer itself doesn't need to handle this new Futures Market I feel like why why do we assume this has complexity if you're just promising this is one this is two this is three this is four at a minimum you need to be you need to price it you need to be running full nodes for these rollups so that you know what is a fee paying transaction but even more fundamentally you need the bandwidth to be able to process all the transactions on all the rollups simultaneously you know you also need to

be able to Shield your IP address you need to have collateral right because you're collateralized and you need to price it um yeah it would definitely be not something you can do on a Raspberry Pi uh Nathan I wanted to ask what the guarantees are for the user economically and through social consensus it seems like in the naive implementation the uh economic guarantees for the user end when the me from their transaction um exceeds the slashing risk so maybe you want to move um past that you probably want to have social consensus and trust and have like some trusted entities doing the as the pre- conert is there a way around that I guess you could have more like a higher collateral

requirement have you given any thinking to this right so that needs to be collateral either reputational or financial as you said um now if we're going to go with financial collateral one way to think about it is that the collateral needs if it's let's say a thousand e then that's actually okay and why did I pick a thousand e it's because it's the largest um you know amount of me in any single block and so if you reneg all your pre-confirmation you have full freedom to build a block and therefore extract the most amount of M but if the amount of M in any given block is bounded above by thousand e then then then you're good um now it turns out there's some use cases of prec

confirmations that don't really fit into this uh model uh of Arbitrage so for example let's say that I'm a merchant and I'm delivering some sort of physical good or digital good which is worth 2,000 if um now you know prec confirmations at least as described don't really work like you need something some sort of form of insurance where you know it could be a separate kind of pre-confirmation now one of the interesting things here is that espresso is working to potentially boost the amount of Economic Security from a thousand e to millions of e by using reaking and having the uh the attest Dual Purpose as pre-confirmation ATT testers as well

makes sense thanks quentis um so just going back to this delegation question so um I might have misheard but was your was the idea that the the the party that makes the most sense um to delegate to is a relay was that was that what you were saying or was there supposed to be some other third party that's that's delegated to yeah so we have this new abstractly we have this new role the we could call it pre- confer or something better um and one reason why the relay is well suited is because the proposer is already trusting the the relay for for being

online um you know for the get payload they needs to be online otherwise it's a mess block and they lose me um the relays you know also have a relationship with the builder so it's kind of convenient to pass to pass the pre confirmations directly to the Builders so you're kind of skipping this this this step here and also the relays they tend to be like these public goodsy you know High reputation entities um and so the it's easy for the for the users to trust them uh as well maybe right because we already have Builders trusting them proposers trusting them so might as well also have the users trust the relays but you know it's an open market and anyone can come in and and

provide this this pre-confirmation service yeah I guess I I had of two questions there one is you know aren't you somewhat uh what are your thoughts on how this influences the sort of rest of the relay roles um and the sort of PBS landscape and all those kinds of things because my understanding would be that if a proposer delegated to a relay then that relay would be the only relay that can produce blocks um and as we as as we've seen the of the relay's role has been uh evolving a lot and taking on a lot more responsibilties so you F this along it seems like it could be like a relatively powerful position for the Relay to be in especially if you know

people end up delegating most people end up delegating to one one or two relays ultrasound being the sort of obvious choice here they block sh as well right okay so let's let's assume let's say that um in a given slot the proposer has chosen some relay uh let's say ultrasound um this relay actually should send all the precon to you know to all the other relays um so even though yes there is the relay is like an extension of the Monopoly power of the proposer like you still have a purity of relays immediately after this um so the monop power kind of is for a minuscule amount of time

um so that's that's one thing another thing I'll mention is that the relays um actually now need to make sure the blocks uh respect the pre-confirmation and in the context of optimistic relaying that means that the builders need to be collateralized for the maximum penalty that can be caused from not respecting the pre-confirmation by the by the by the pre- confer right because let's say the builders build a block that doesn't respect the pre-confirmation the pre-con fer is on the hook and so they they need to be compensated by the bad Builder uh that built a bad block and so right now um on um on the ultrasound Relay For example

we have a a limit of 64 e of of collateral uh for for for the builders in terms of optimistic uh relaying um and uh this would have to be potentially increased to a thousand if or whatever the amount is yeah so okay that I think that there's a whole Rabbit Hole in of itself but it seems I I am skeptical of this uh sort of passing of pre-confirmation from the pre-c conert to relays given that there's a lot of sort of timing issues a lot of like trust that goes into that and the other relays obviously would be would be um yeah it seems like there's a lot of sort of

trusted uh relationships going on here here's the way to think about it the proposers okay first of all this is only a temporary thing until we have execution tickets so hopefully it won't last more than two three years uh but let's say that it is you know something that we we we are worried about like the proposer ultimately chooses the pre- confer now let's say that the preon The Proposal today is connected to three relays let's say flashboard block route and ultrasound well what they're going to want is the the the preon convert to just share with these three relays because that's the three relays that that they the proposer trusted so in some sense the proposer can impose their preferences on the pre- confererence proposer and if they don't

provide a good service and they don't connect to all the relays the proposer wants well guess what the proposer will just change pre-conference set something else yeah okay I don't want to take up all the time I would just say my understanding of this is the you're asking proposers to delegate block building rights to some offchain party and in this case you're asking them to do it in the first conf first of way uh but this ends up with like all blocks being produced by one or two parties which is you know may be fine but uh I think at least should be investigated I don't think it there's any degradation relative to the status quo but let's have this this conversation offline for sure uh Nathan Sorry kaido by the way you've been waiting um no sorry I just have from the

last question okay no worries kaido you're up yeah thank you for uh the the presentation and all the conversation around it I just have have a quick clarify clarifying question question so I want to make sure my assumption on how these things work uh like the prerequisite for these two work I think one of the key thing is just mechanism for posting collateral from the proposer side is that like a consistent theme okay the second thing is without execution ticket basically needs a way for the proposer to express delegation preferences to your external parties and when we have execution ticket sorry right okay I mean I I think of

these two things as being implementation details um now let's let's take the first one the collateral um you know the way I think about it is you need let's say on the order of a thousand e of of collateral um now reaking actually doesn't work too well in this context because you know each each validator only has 52 if if we if we have Max EB and we we lift the limit then it would it would reaking would actually work uh really well um another thing I'll mention is that the collateral efficiency can be extremely high especially for the large operators so let's say I'm coinbase and I have you know millions of E I actually only need this 1,000 e or you know some small

number of of thousands of e uh for all my validators and the reason is that I I you know if I haven't been slashed in slot n uh when I was a proposer then then you know I can start recycling this collateral over and over again so at the end of the day I don't expect that there's going to be that much collateral uh you know maybe maybe 100,000 e um you know which is much much much smaller than the 30 million e which is currently um mistaking in terms of how do you do the delegation that really is an implementation detail but uh the way I think like the naive way would be the proposer signs a message saying I'm giving my proposal rights to this uh to

this precon fer and it goes on Che on a SM contract and if they ever want to change the pre-con fer then they just sign and and a different transaction yeah and lastly with ET the uh the additional thing we need is a way to the for the user to communicate with the the precon proposer uh that like a fair assessment I'm just s like trying to understand how difficult it would be to implement these things um so you you talking about the communication here between the user and the proposer and so the The Proposal here would be the the ticket holder who won the the ticket lottery um the way it would work is that they would advertise themselves so they would say you know please

connect to this website and this is the RPC endpoint um you know very similar to a centralized sequencer so right now optimism for example arbitr they advertise a specific IP address for the centralized sequencer and instead of having a fixed IP address it's a rotating one that potentially changes every slot yeah my my second question should be straightforward just how slashing would be work I think how not slashing sorry how life slashing work I think it says you're guaranteeing both liess and safety and I wasn't sure how that work yeah um I mean it's very easy it's just a small contract and you you you provide the proof that your your pre-confirmation was not honored and

that there was a Miss slot and so that's that counts as a liess fault if your pre confirmation was not honored and um and there was a slot then that count there was no Miss slot then then that's the sa default um Ludwick um yeah just quick um question to clarify is this model assuming that the only person that we can consider for um inclusion of the the pre comps U basically the proposer to be the next one and why is that a requirement if the L2 is your sequencing based on when the pre-comp are signed because otherwise

you can arbitrarily choose the the pre-c confer within the look Ahad well the proposer soor separation between pre-com kind of generator and pre-com enabler which is the proposer right so in theory like you could have some like SE totally separate entity that does the the pre-confirmation but but the thing is that they they can't guarantee that the transactions will actually go on chain within a certain amount of time because the only entities that can guarantee that are literally the L1 proposers because they're they're the ones that have these rights and so if if you don't directly control you know these slots then you know you can make promises but it it's it's very hard to

honor them in a in a in a guaranteed way whereas if you invoke the1 proposers they literally have prop proposing right which means that they can guarantee if they're online and honest that those prec confirmations will go on chain I guess like um my my main question is let's say that there 32 proposal right and like 10 of them are offering pre- comps um we could have like the next one be the facto delegate but if the L2 is sequencing based on when the pre-com gets signed and released by The promer that is offering that service they can pick whichever proposer is competitive yeah that's an interesting point yeah like in theory you you could

use any of the green ones you don't necessarily have to use this next one uh interesting point I hav't thought about that yeah worth thinking about gooda then the entire pricing model kind of becomes far more complex but yeah yes yeah it becomes messy but uh interesting nonetheless uh Ben uh yeah so I I wrote it in the chat but I I guess I I wanted to raise this because I think it addresses some of the concerns that are being discussed um including from quentis and and and and what we've been discussing in the last few minutes but if instead of electing the pre-c confers just based on the look

ahead um you ran a separate lottery or execution tickets as you're calling it um auction to decide who the pre-conference are and then the L1 proposer always has the option to either buy this pre-conference slot in a way that's just coord the whole point of involving the L1 proposer is so that you endow the preconferences these concerns

the the main reason why we were proposing to do it this way was for for there are other advantages that you can have when you have more control over the mechanism through which you elect precc confers one you can elect multiple prec comers over different rollups so it it's possible to have um one preer by the rights for proposing all the rollups maybe a subset of the rollups every rollup could post some reservation price at which it must be bought this gives this is what is driving this um me share uh design as you described it Justin but the second thing which is what you and I were talking about yesterday is that many teams are concerned that if you

have one uh Monopoly pre-c confer over all the rollups that some rollups may get EX in excluded if the precc confer is Citadel and it's you know censoring transactions that are I don't know on Aztec or something um well if you have a multi- preuner uh election design where you only get the rights to propose for a rollup If you bid on that and and there will be some rollups where Citadel won't bid and other people will bid on it then you also mitigate those concerns so I just wanted to sort of highlight that and if there's any right yeah thanks for highlighting that uh and I agree like

there's there's a whole design space in terms of extensions of or modifications and variations of of the the base sequencing um and maybe we should have a whole call dedicated to that um but I guess let's try and go through the the questions on on the the most basic design which I think is is this one or or something very similar um qby hey yeah um just had a quick question around um the execution guarantees around pre-confirmation gets pre-confirmation

intent like I want this price or if the one of the weakest intents could be I just want inclusion and I don't even want uh guaranteed execution okay because that has a significant impact on the sophistication of the pre yes for sure um but yeah like like all these different flavors of prec confirmations and intents in some senses orthogonal to to base sequencing specifically is like more just a a rapid hole within pre confirmation quentis sorry that's an old hand okay gotcha uh Yuri um did you consider having

sequencers precon their previous precon prec confers so basically the sequencer yes you have the sequencer and the next sequencer promised to also that and so you kind of get around the 30 million gas limit basically does continuous cross sequencer um um pre-confirmation and then you end up with my fairy tale of first Comer Ser real time PR confirmation which I like yeah so I think there is like some value in the user actually talking to multiple um sequencers or pre- confers and one of the reasons could be if there's a liveness failure so let's say this first green one let's say there's only two uh pre- confers in the Lo ahads

there's a possibility let say there's one in the 10,000 chance that that this one's going to be um missed because the sophisticated pre-con fer just happen to have an outage on AWS or whatever um then if you get a pre-confirmation from the next one in parallel then it's kind of you're hedging your bets and this second pre-confirmation so I I mean something else don't get it from both of them can we have if we have these two sequencers can slot and plus 31 promise I will sequence everything that slot n+1 promise so basically a collaboration of the sequencer to create like a continuous pre-confirmation soot plus yes you can do that yeah so

even before n n plus1 has been like settled and included you can have conditional pre-confirmation from this next precon on what's already been go beyond the 30 million gas and just basically have the sequencers promise whatever if that you again it goes to economics and where the money goes yes that's a good point so if this guy has consumed his whole full 30 million gas he can say okay I'm I'm full go talk to the next guy no again not what I'm saying I'm suggesting that all the sequencer promise in advance that they will accept all the promises from previous conf sequen but

then but then it becomes a bit complicated because if there's a fault like who do you attribute theault to it could be one of the two so if if if if like these two pre-confirmation um sorry lwig uh but there is the uh the post uh discussion if you want to if you want to hang out um thanks again to everyone and see you see you on the next

call thanks guys thank you thank you Justin Justin thank you thanks everybody