Ethereum Sequencing and Preconfirmations Call #2

Transcript

okay hi everyone uh welcome to the etherum sequencing and pron uh call uh number two uh this is our uh third call the previous calls focused on uh the the basics of uh the design of ethereum sequencing with preon uh with pre confirmations and we also did a round of intros uh to kind of gauge interest in in base sequencing in general and uh the focus of today's call is on potential downsides potential risks and concerns that people have uh with base sequencing and we have uh seven uh presenters who will each focus on on one separate risk or or concern we're going to try and uh

keep it quick uh because we don't have that much time the goal really here is to try and understand the concern not so much to solve the concern so if you have any questions uh please keep them around like clarification of what the concern is as opposed to trying to to solve it um the first presenter is uh Ellie Davidson from espresso Ellie the floor is yours um okay perfect let me just uh Quick Share my screen um okay so there should be some slides up now um so today what I want to

talk about is this uh fundamental trade-off we have between L1 L2 interoperability and um L2 pre-confirmation finality um so by L1 L2 interoperability I mean like we want to be able to do atomic swaps between the L1 and the L2 we want to be able to react to L1 State very quickly on the L2 um and then by pre-confirmation finality I mean as a user how confident am I that my pre-confirmation is going to actually mean that my transaction becomes Final on ethereum um and so we kind of have this spectrum and this trade-off where on one end we have slow interupt but we get really strong pre-com guarantees and on the other end we get weaker precom guarantees but uh really good interupt

with the L1 so uh the first like open question that I want to bring is uh what exactly are are pre-ms promising are they promising L1 finality or L1 inclusion so I think that they should um promise L1 finality because this is what the user cares about and this is um actually what l2s today are essentially promising is L L1 finality um but I think that we should be mindful about what we're actually promising so from there um I just want to introduce this idea of conditional finality which I think has been brought up in previous meetings but it's this finality that an L2 block is only going to become finalized if a particular L1 block becomes finalized and I think that this

is a useful way to look at any L2 so any L2 has conditional finality even non- based l2s um but the difference is that um non- based l2s can choose a already finalized ethereum block or some ethereum blocks that's like that's like sufficiently deep in the chain that it has a very low risk of being reordered so this is kind of represented by these like basketballs on this spectrum um a non- based sequencer a non- based L2 can choose anywhere on this spectrum but most of them tend to choose towards the left side um but the issue is that with based sequencing we kind of are forcing rollups to be on this right side because the um the L2 is being L2 data is being

proposed in the L1 block um they naturally have to be conditioned on the pre-con first block and not on some future or some previous block and this means that there's a higher chance of uh reorg so as a quick caveat to this you can say well in base sequencing um sure it's my user my user pre-confirmation is conditioned on the pre-con first block but what about includers includers could include the transaction in um their block before the pre-con first block um and to this I say yeah that is true um includers could do this but I think it's important that we understand that includers are not actually part of the

pre-confirmation promise we can incentivize includers to include um transactions earlier than you know prior to the precon first block but we can't force them and it's not part of the promise so I think that this is something we can like optimistically hope for but we can't guarantee um and so with that I want to say well then like what is the risk that I'm talking about to base sequencing and specifically the risk is that because of this conditional finality and because of the fact that based sequencers as we've been discussing them today um because they are forced to have weaker pre-m finality they have a worse experience experience than current l2s and they actually in a way have a worse experience than the current L1 so

current l2s like I said a lot of them are conditionally Final on a finalized ethereum block or some very deep ethereum block that's almost never going to reorg um and so because of this as a user once I get a pre-confirmation from a centralized sequencer or a decentralized sequencer I can be pretty much 100% sure that my transaction will become final so um this is a very big deviation uh from the current state and it's Al worse than the L1 State because like I said in the L1 state if I submit my transaction to the public ethereum mol and it shows up in the current block then okay I need to wait like 30 seconds 60 seconds to see that it's sufficiently deep um in the ethereum chain but with base sequencing it's not on the current

Block it's on the actually proposes their block maybe an includer includes my transaction before that but that's there's no guarantee that that happens so I wanted to keep this super quick so we can discuss um but basically here's kind of what I would say the takeaways and the open questions are so one I would say currently based rollups are forced to have weaker pre-m finality it's great that they get really good L1 L L1 L2 interoperability um but this might actually not matter to all users and a lot of us users are really going to

Value this like strong finality that um l2s offer today um second takeaway is I think that we should be very explicit about what we're promising with a pre-confirmation and I think what matters to a user is L1 finality and not L1 inclusion um and then finally um includers are not part of the pre-confirmation so I think that they're very valuable to um helping the the based sequencing experience but we need to be mindful about the incentives so that they're properly incentivized to actually include um pre-confirmation promise and so we cannot rely on that as a guarantee that they will include

transactions so and then really quickly I just wanted to go over some possible solutions and some thoughts so one is execution tickets you could say well with execution tickets we should have fewer missed blocks maybe fewer reorgs because we're going to have less timing Games Etc and so maybe if the ch of re oring is a lot less then maybe we're less worried worried about this you know maybe instead of having to wait for like five ethereum blocks deep I as a user feel comfortable waiting for like one block or something like that um another option is insurance or slashing for reorgs so this is based on the idea that a pre-confirmation should be promising L1 finality so even if the preon is promised we could optionally slash them if their block gets reorg and return

this to a user in the form of insurance so this is um you know this is definitely helps the user experience they get they get you know um rewarded if their transaction does not become final but obviously in this case we would be slashing pre-con fers for something that is not their fault um and then finally I just want to mention a quick solution that espresso has been working on um and this is well perhaps we can actually allow more customizable conditional finality so perhaps we can say um you know like based roll or non- based rollups today that can choose to be anywhere on the spectrum between you know strong finality and weak finality we can say based rollups can choose that as well and we could even go a step

further and say why don't we let users choose that on an individual transaction level um so that's also something that we've been working on an espresso but I'll end there open it up for discussion um but yeah key takeaways is that uh you have this fundamental trade-off between uh finality and L1 L2 interoperability and Bas rollups do not currently have a lot of flexibility to choose that tradeoff perfect thank you Ellie we have a couple minutes George you have your hand up hey thank you ell I think what you are plugging here is the risk is absolutely wonderful and you're absolutely spot on and u i I agree with you that having the gaps between bre

confirmers actually is something that going to cause uh probably worsening of the user experience and um I don't know about the rest of you but for me like the original concept by by Justin on world based Roll Up is was like kind of a Guiding Light rather than the s stone uh design and architecture and uh I love the suggestions that you have there especially the ones around execution tickets and I think that a solution that essentially draws from the validator set but does not necessarily have gaps between the validators so that you don't

need to wait like to to to find a validator that's willing to uh to be a pre confirmer but rather have a steady queue of prec confirmers is going to be a possible solution to to what you're are flagging there um yeah would love to see something like this I'm personally also working on something similar that I would love to share probably sometime over the next weeks thanks Ro looking forward to to your your write up um Noah about additional finality so let's say that I'm trading on Unis swap B2 I'm I have a transaction I put in a trade I'm swapping E3 usdc on let's say I'm on R up one and then let's say

Justin's trading right after me and I say that I'm doing conditional finality so I'm gon only wait for stronger finality guarantee it's just in traing off my state or a different state because that seems a little OD yeah so this is uh this is a really good question so um yeah so there is some interdependencies there um so if a so if you're using like a shared some sort of a shared contract like Unis swap if um so you actually could condition it off of different finalities so if Justin conditions his transaction off of one block and you condition your transaction afterwards off of a um deeper ethereum block then it's possible that your

transaction will be included and Justin will not even though yours came came later um but that might not be maybe what users want and so this is an open design question how we would do this is that we might want to say hey if you're interacting with something that interacts with the L1 then you know any future transaction of that is going to have to be conditioned on like the latest ethereum block that that is conditioned on um because obviously a lot of users like the user wants to you know as a user you probably don't don't want your transaction to be included if Justin isn't you want it to be included if Justin is so yeah this is an open design problem about how we kind of represent this like intent of what users are going to want to be conditioned on but it's a good

question thanks for the clarity sorry Roan Rohan uh we have to move to the the next topic um but we will have a a post call discussion um to discuss further uh the next uh presenter is uh Cooper uh from Aztec talking about layer one Builder censorship hey everyone hopefully you can see this okay um cool we're talking about the ethereum shade sequencer and pre- confirmations obviously I work at Aztec Labs uh L1 Builders are frequently censoring people I don't need to explain that I've right on this call shout out to Tony for his lovely websites and diagrams uh to give you some context I'm thinking specifically through the lens

of azex designs and how we would pivot to potentially use the ethereum shared sequence quencer so option one just the tldr is like give a proposal randomly elected s sequencer publishes a transaction ordering f one you have a separate phase where that uh proposer chooses a specific proving address they put up a bond um you know at some later Point uh that prover submits those proofs to L1 super high level handwavy click the link and I'll share it in the channel afterwards if you want to read more um and so mapping these kind of phase analoges to using the ethereum sh sequencer right phase one's super obvious Tex proposer becomes you know generally the ethereum proposer seems likely that we would need some customized Builders or dedicated actors for the azex ecosystem to kind of boot

strap it you know resulting in this kind of like Gap period before what I think is called the superb Builders come in um so at some point ethereum shared sequencer the people using the shared sequencer need confidence that they actually have the underlying block data so in Aztec because we're a privacy protocol these are clients that generated zero knowledge proofs you actually need most of those zero knowledge proofs in order to know that this block is going to to become valid and so I think that this is a largely unsolved problem uh likely all zero knowledge rollups are probably talking about this right now in one way or another as part of evaluating this design um I would say from our perspective uh the ethereum sh sequencers seems way easier to integrate into an optimistic rollup but maybe we're wrong about that uh and then phase

three you know someone submits the stuff to to that one so it's like pretty similar right in mental models we you know it's not a huge Divergence of of what we were previously thinking and so there's you know two specific concerns that I think are somewhat well articulated so you have weak censorship which is delaying transactions from phases 1 two and three from the previous slides or delaying blobs from one two and three from the previous slides uh blobs would probably be only uploaded in phase three or phase two depending on how strong of Da guarantees you need to provide to whatever proving Network your zero knowledge rollup ultimately decides on uh and then there's strong censorship and that's like Builder just flat out to you know refuse to touch Aztec transactions because it's too messy or complicated and uh depending on the S of

these concerns we might want to redesign our our this block production scheme in these phases to publish to1 eventually rather than trying to provide more real-time finality so if we're trying to get a bunch of blobs into blocks every three minutes or every seven minutes you know that could have much larger censorship implications than if we're happy just getting in every 24 hours and so we would need to potentially redesign to accommodate that that doesn't prevent strong censorship and uh we need to land a bunch of data on chain at some point and if that doesn't happen and you're privacy first roll up and you need to get included from the builders and they won't I don't know what happens do we pivot to becoming an L1 or something like that I I actually don't know what happens in that case uh and so this is just like a high

level list of things that we think what it would take to use the ethereum Shar sequencer I don't think all these are required in like an MVP or like a first iteration but you know these are the things that we see as important so like inclusion list inclusion list with blobs right now we have a Godly 32 kilobytes per transactions due to client side proof Pro uh we have some other options which is like you know invent a new fancy proof compression scream become a validium which is uh controversial as all are aware of uh for various reasons uh we have some more information on why this is the case uh we would have to have a pretty clear understanding of Builder compliance needs and concerns you know we don't have an enshrined or canonical bridg or portal so you know we do think that compliance challenges

should be implemented at the actual Bridge level rather than the message in boxes for our given rollup uh we would need have much better understanding of like the peer-to-peer Network and other networking considerations like privacy rollups have a shitload of data that honestly no one else realistically has to deal with and so that's probably why a lot of the other twos aren't really talking about it um and then yeah the back to phase two from the previous slide like we would need some mechanism for delegating proof rights uh we're currently in the fet designs have something that we're calling Pro boost which is just an option for the rights to prove a block but I think all ZK rollups need kind of clarity on what the ZK integration with the ethereum sh sequencer ultimately looks like um and they'll all take different design trade-offs right Aztec has different

concerns that you know potential other l2s um and then I would say outside of the ethereum shared sequencer we would love and are EXC very excited about blob and block Futures on inclusion specifically I would say from our design challenges we care more about inclusion than actual State results one of those seems much easier to engineer um and just knowing that let's say aset can Latin seven blobs within every four minutes is like a super nice guarantee uh to know or even just to know what the relative cost of that inclusion might be in the future um so these are things that would help us gain confidence and trying to articulate that even if we don't go at the ethereum Shared sequencer we see value in these inclusions and these pre-confirmation um if you want to help us out contact me on telegram or email if you could give

us a specific sense of your compliance requirements that would be incredible uh all of our research specifically on block Productions public on our Forum you can advocate for the prioritization of inclusion lists and uh I think every rollup is going to be saying this forever but increase the da limits um and yeah so that's that's my take on on Builder censorship thank you all for uh letting me present perfect thank you Cooper any clarifying questions from the audience um yes Cooper um what was it that you said about if people could clarify regarding the censorship or compliance requirements do you mean from the perspective of the validators uh

yes in terms of build across the board just getting a better sense of uh your compliance requirements would be super helpful okay we can chat about it like offline but like we have a lot of insight on it I would love your help there jri um uh Cooper it might be helpful for you to elaborate a bit on the um on the on the concern one of the concerns you highlighted about needing the proof data to be available and how this is different from I guess General data availability concerns like the unique unique aspects of this problem for Aztec yeah so in our case right now um if you propose a block and it has uh you

know that block is composed of clients side generated zero knowledge proofs at the time that you're proposing it you don't necessarily yet know if all those proofs are valid you haven't proven them yet and so you're subject to potentially like proof withholding tax or invalid proof attacks where they're putting up block proposals that contain proofs that could never be proven and so we either have to rearchitecturing stack in our execution environment to support like some type of like reverting zero knowledge proofs in some way uh or we have to make sure that at the time that they're actually being committed to there is sufficient data and sufficient confidence that they will eventually get proven um we're working on other ways where you can like kind of

optimistically verify them um but the current challenge fundamentally comes from you can't include a zero knowledge proof in a block that can't get proven in other words you you don't you want to make sure that something doesn't get preconiran-food.com on the Chain I mean is it fair to say that a block cannot be finalized without a proof yes

yeah okay one last question uh Yuri go ahead yeah I just want Cooper could you explain that last piece between you and Ben basically you want to precon approve but you you you don't want to commit to it yet because maybe it's wrong or it goes on forever Etc so you kind like want to buy the precon but the ability to back out of it if you don't want it like I I'm not sure I'm clear on what is it that ask in really bate our yeah I would bifurcate our interest in pre-ms from needing a proposal phase that says that this block proposal can eventually proven or we can filter out the proofs

in that block that will not make its way into the final proof does that make sense so I would think about it separately from the pre- confirmation perfect thank you Cooper um again we can discuss more after the call uh joonas uh is next talking about pre-con delegation and centralization concerns can everyone hear me and see my screen yep okay awesome so yeah I'm going to be exploring uh the pre-confirmation delegator model and specifically like these questions um which existing party

is most suited to take on the pre-conference role today and what are kind of the the risks associated with each party first some some quick definitions to make sure we're clear so the sequencer is a L1 proposer uh that is opted in to be a sequencer for a base rollup and for the purposes of this presentation is also deleg to a pre-c confer a pre-c confer is a sophisticated actor that can handle the requirements of giving pre- confirmations and he's also given full sequencing rights by the sequencer um aliveness fault is a violated pre-con commitment due to a Mis block which can be either the fault of the pre-c comer or the L1 proposer and a safety fault is a violated pre-com

commitment due to just a different block being proposed and that is fully attributable to to the pre- confor uh so a delegation model schematically looks like this you have a sequencer that delegates like all of the uh pre-confirmation rights and sequencing rights to an operator which we call uh the promer in this scenario and the users interact directly with the promer and not with the sequencer uh scope so so focus is going to be based on proposer uh base proposer pre-confirmation so non L1 pre-confirmation and the role of block building strategies is kind of treated as a black box or we can just assume that the pre-c confer runs a first

confer Ser strategy uh so in terms of candidates like the first most obvious candidate is kind of the relay um and that is because the relay is trusted by the validators already or by most of them uh so there is kind of a small leap in terms of trust for pre-con delegation uh they're already a highly sophisticated entity so they they will be able to handle the requir requirements and they have this visibility into the execution payload and given some small changes to me boost also a way to to communicate constraints to builders um but there are also a couple of reasons why why relays are not maybe the ideal party uh so there there is kind of an increased dependency on a

thrusted third party uh that the road map is kind of moving away from with with like PBS and execution tickets at least as it is today um it's also pretty complex because sequencer sequencers need to be restated for liveness faults and there needs to be some sort of like Mutual slashing mechanism or at least a way to determine in in case of aous fault who was actually at fault uh and then I would also say like in terms of centralization pressures uh if there is a relay that's like a first mover and that that Garners delegations from like the most of the sequencers uh there's effectively like only one or one or two pre-con fors that are sequencing

L2 blocks uh which becomes like a single point of failure and then finally we do have a dependency on reaking again because of the The liveness Faults and because uh sequencers need to be able to to be held accountable um but aside from that I think that for solo stakers uh the relay is actually uh the relay as a pre-conference is actually a good idea uh but can we do better for like the largest part of our Economic Security namely node operators and staking pools uh and additionally can we can we move faster to approve of concept uh without needing like a restating and other dependencies uh so given these points I think that node operators are are also

in a very good position to to run pre-c confers um mainly because the sequencer and the pre-c confer in this case is the same entity so there is no delegation of trust which which then leads to more Capital efficiency like uh there's no additional stake that needs to be put up from the sequencer for liveness faults um because safety and liveness faults can can both result in in pre-c confort slashing uh it's also less complex so we don't need this Mutual slashing and reaking uh in case of aous fault and there is no Revenue sharing the sequencer uh doesn't need to share Revenue with a third party pre-c confer because it's all internal uh and also it's it's more I would argue that it's

more decentralized so there are more not node operators at this point than there are relay um so there will be this kind of forc rotation between uh between pre-com based on who the next sequencer is so I think like implementation wise it could resemble something like Solana's turbine um and so yeah this is something that I wanted to bring up like I think that in the short term I think node operators are probably a good way to to get to a proof of concept uh and also might reduce some of the centralized pressures of having like one or two relays become the de facto uh precom provider if that makes sense uh so yeah that was it uh and we're chainbound we we're looking

into building high performance precom infra if you're interested please reach out perfect thank you um Yuki you have your hand up I um have a quick question so you you mentioned on the uh first one that relay could be a a potential prec confers but uh and and you also mentioned the the res thinking could be one way to bring accountability to the livess port situation which is when there could be some sort of a Mis thought uh but uh don't don't you also think that uh uh try to bring accountability in the in the relays as a precc confers uh in the case that we when we don't know exactly the cause of

the Mis thoughts could be a bit um I guess like wrong mistakenly slashing the relays in that case like for example it's a if the if the Mis thoughts were potentially due to just like the proposers just simply not proposing the block or something uh like just they they gave up on calling the you know the gate payload for example then then there there was simply no block and that that would not be a problem of a relays in that case no exactly and that's that's why the L1 proposer or the sequencer in this scenario also needs to be St and there needs to be some mechanism of determining like who's at fault here is it the relay is it the pre- confer or is it the L1 proposer that just didn't

propose a block um so so you're saying like both the relays and the proposal would be like sort like a double double St or in the case like it's like both restake is that is that what you're saying well the relay as a pre-con would would put up like a large amount of stake enough to to to become a pre- confer and then the sequencer uh or the L1 proposer could could kind of restake uh a part of their state to to take on um penalties if they fail to to propose a block thanks so they they would both need to be St somehow yeah Ben yeah so what what do you mean though

when you say they need to stake enough to become a pre-con convert but what's the mechanism for elect for for electing them what's the mechanism through which they become elected um that are then you have to choose one to become a pre- confer so I didn't understand the proposal yeah I I see I think so a pre- confer could um like stake in some sort of of contract registry and then the the sequencers that want to uh delegate to that pre-c confort they would they would somehow signify by by signing a message that they want to be uh delegated be delegated to that specific pre Comer and then like uh as a client as a user you

would somehow read the onchain registry see like which which is the next uh sequencer in line and who is he delegated to and then kind of uh requests or send your preon requests to that specific uh pre-c confer I see so you're saying to allow the the L1 proposer to just delegate pre-con fer rights to someone and just there's an additional requirement that the only people they can delegate to are people who have staked in some contract exactly yeah and the the the last slide you had uh could you go to the last slide um so I didn't understand the point on this slide I I so can you expl this is can

can you re explain it that who who are the node operators you're talking about here and and what do you mean by no Revenue sharing also right yes so like I uh probably in a case of like a delegated pre confer um if if the the relationship between the sequencer and the and the pre confer is kind of untrusted um the pre-conference is taking on the these additional duties um in um on sorry let me it's taking on additional duties that it performs on on on behalf of the sequencer right so it needs to be paid somehow um but if the the the validator set or

the node operator and with node operator I mean like chorus one uh and these like the bigger node operators if they can internalize all of that uh then they don't need to share Revenue with some someone outside of of their organization because they are technically uh competent enough to run their own pre confer if that makes sense so the node operators are also the L1 proposers or yes yes so this is saying let's let the L1 proposers be pre confers yes and given that they can put up uh enough stake and and choose like one delegator to to uh accept all of the precs perfect thank you joonas um next

up we have uh Ben who will talk about um me misalignment uh between the the rollups and uh the proposes thank you Justin yeah I don't have slide but it's very very short and we can leave most of it for discussion uh so in the vanilla design of based sequencing we just give the L1 proposer the right to propose the next blocks for all the rollups that are involved and what this means is that it gives this elen proposer entire ability to capture um any form of sequencing Revenue that's not being charged within

the rollups itself so everything beyond the um the gas uh that's being charged within the rollup execution environments themselves and in particular that includes all forms of me um so all Arbitrage opportunities and you can even think of pre-confirmation and the tips that are being paid for pre-confirmation as also a form of me and all of this can be captured by the L1 proposer um and importantly the protocol is not even aware of how much is being captured right um because the L1 proposers are not selected in any smart way they're not selected through execution tickets they're not they're just selected

randomly um and so this creates a an incentive misalignment problem for rollups because uh great you're joining an ethereum shared sequencer but on the other hand you're as opposed to running your own sequencer now potentially giving up on a large portion of your Revenue um and so the question is how could this be designed in a way that does give um you know uh shared proposing rights to the L1 proposer so that we can increase the utility of the system for everyone but that does not um get you know all the value to

flow to this shared proposer there's a way for the protocol to capture this value and also redistribute it potentially to rollups um so that's I wanted to spend mostly just highlighting the concern um I've uh talked about before in these in these meetings how there we there is at least one alternative design the one that we've been um describing at espresso which is to run uh even if we can't make these changes to the one today you can still run an auction or a lottery mechanism basically execution tickets to uh to to select these pre-c confers so not to make the pre-c confers

just these parties that are can be delegated to but actually to elect them through smart mechanism um and then later give the L1 proposer the ability to decide to to buy those proposing rights from the pre-c confers so by default the pre-c confers actually have the right to produce the next blocks and instead of saying that it goes the right goes to the elen proposer and then it delegates rather the the elen proposer always has a right of first refusal it can always buy the proposing rights from the uh from from the uh you know auction selected prec confers and now we know inside the protocol uh how much the revenue is and where it's coming from and we can um by

designing the auction appropriately also uh figure out how to redistribute the marginal contribution of each rollup to the overall Revenue I think uie has a question so questions so basically you're saying that listen if we just give the rights to do that then all the me leaks to the L1 just like like like it just goes there and therefore none of the value actually stays with the rollups and like how could we find a better solution for that and what you're saying is if the shared sequencer which is not the L1 proposer like some mechanism kind in

between those have the right and the shared sequencer have sorry and the L1 proposers buy whether execution tickets whether some other mechanism they buy this right to do it then the value won't leak to the L1 proposers and instead it would share like go to that mechanism and then you make like a leap and from there it could go back and be redistributed Etc and I'm I want to put a question mark on that LE like it makes sense yeah don't let it leak all the way you stop it here okay now it's at the Shared sequencer so all the me is at the Shared sequencer layer how does that how is it easier to push it back to the rollups from them compared to getting it

from the L1 proposers or like do you have something in mind oh def it's concreted yeah it's uh also explained in the in hamd post I'll I'll I'll drop uh a link to again but it's not that there's a there's a this is an implementation of the mechanism through which precon are elected so the preon fers are elected through an auction rather than uh rather than just being assigned to the L1 proposer so so um the auction is uh is run in a way where rollups are effectively selling or auctioning off their block proposal rights to precc confers and the results it's kind of

like selling order flow really right it's like from that level very similar selling order flow and in fact a rup could set a reserve price that says the the the shared proposer is only going to be able to buy the right to propose my next block if it pays over this price otherwise I propose my own block so this also allows for it it doesn't force a situation where there's always one proposer for all rollups we could have situations where there are in in certain slots um there are multiple proposers to sort of partition the rollup space um as long as the shared proposer is creating an economic surplus then you know and if

the most economically efficient allocation is to have one uh you know shared the next block for everyone then the auction will find this solution um but um by basically allowing rollups to sell or auction off their block space in this mechanism you allow them to capture value interesting carc sorry we're out of time uh thanks Ben for the for the presentation uh next up we have Year from scroll uh talking about uh scaling bottleneck with uh shed sequences um okay sure thanks um sorry also like because R are very late so I also don't have time to prepare slides

so really sorry for that um but I want to bring a different view for like this share sequencer because people talk about pre-confirmation economic guarantee a lot uh I want to talk from a very very different view around like performance um because the way I think about Layer Two and layer one the relationship between like two two layers is that layer one actually solve this kind of dation like you know consensus all those the problem so all the things that you know because I think about layer to any blockchain like as a as a database like where and and also processor so basically like this processor receive transaction and can read and write into this kind of database and then like the because you want decentralize so you need consensus among those kind of database so you have layer one and but it's not efficient

enough so the way I look at about Layer Two is that okay so right now let's forget about dation just focus on performance first so it's like basically like a layer to is building a high performance like you know DP system with a processor and processing or transaction yeah maybe in a centralized way and then it can read and write into this database and process transaction really fast and then all the security dation is guaranteed by posting approv to layer one and now like if you want to have share sequencer especially if you have have this kind of automic compatibility between two kind of different lups so what you're assuming is that it's a distributed database system where you have two different database you have two processor and then like nor nor like they only read and

write into their own State and now you are basically allowing this kind of like atomicity between like two different like such system which is like this processor sometimes can write to the database of the other Rob and which actually cuse a big problem for like you know if you look at that from a view of just a distribut system or distribute high performance distribut data DB system because there are two like you know different like guarantees for for consistency between like because sometimes like you will have read and write conflict because the AR up will like you know when they maintaining their own State their own database they can write to some State and the other Rob up can sometimes also like write to the same state so you you kind of need some locking mechanism so if you have to

take some term from the the the field of distribute system there is like like two ways one is a weak consistency one is a strong consistency guarantee across multiple different replicas so and in blockchain we definitely need strong consistency like the requirement for strong consistency that all the kind of updates must be immediately propagated to all the copies so it has a very very strong requirement for like you know some Global synchronization mechanism and it's like in the literature of our distributed system is like it's very unfortunate that you know such mechanism are very very hard or even like impossible to implement in a very very scalable way because it's just fundamentally like very bad to enable such kind of like read and write into

like you know different system and uh especially with the possibility of revert so it will massively so imagine like you know you you are building one single system you only allow that to happen within your own system you can make make that super super performance like Solana or like some really really high performance chain but now once you enable the possibility for like you know cross read and write and enable this possibility for having conflicts then like the performance of each system will be massively decreased especially if that based because that need to be considered into part of your system design so that would cause like the performance of both Sid becomes seriously like like massively influenced so that's a problem uh like when I'm talking about this problem with Justin

like you know one immediate solution which from Justin and also like we have mam like researcher muhamed working on this is that okay so can you have now like you know if you have this kind of enable cross transaction and read and write into our own State that's a problem now can you kind of like you know maybe like you know if one is operating the both both Rob node can you have like design some mechan where like every 10 block there is a like super like a different like you know block that only contain like cross change transaction super transaction and as far as it's economically varable because some people want to pay more and then you can make this kind of only happen within a certain period of time so that in other time you only need to handle like transaction within your o system so

you can still design that in a very very high performance way but this design also require the same block time also has very very centralized assumption that that one enti they have to operate on both Sid and also it's a it's actually a tradeoff between livess and and economics because imagine like you know you have like one half of your time just producing like you know processing such block so which means like one rops live can also influence the other R Liv because one up once cross transaction can lock the state in the other R up which will influence at least like you know your performance will be like half decreased so there is a like tradeoff between like how much you know economically you want to kind of like makes this happen versus like in reality how much it influence the performance

and U so like eventually like we don't want to the under game where you know some people can send Atomic transaction to lock the state on both Sid with so basically influence the livess on both side with a very very cheap just one transaction and which will like make this kind of actually less scalable and especially like you know we are thinking about like a very very scalable future where you know the ethereum and plus is Aller too are really producing are really processing like 10 million transaction per second we really need to think from like not just economics not just like you know this kind of like blockchain perspective but actually from a way for how we build a like performance enough system to kind of handle this like imagine like if you

allow this compatibility happen between like 100 different CH each CH maybe maximum throughput might be like 1,000 and then you need like way more such kind of system to kind of like talk with each other like within like some block time which will massively like influence even like you add up all those kind of 100 chance what the performance will look like what the user experience will look like and is this kind of really designed for massive adoption um so it's a very it's a very tricky question um so yeah those are like some of and also like you know especially because this can only happen with Z proof and like realtime Z proof so there will be also some dependencies when you have this Atomic compatiability for like you know because basically like you know one imagine like I want to swap to on the

other R I need to send a transaction initiate on one chain swap on the other chain and send back to my my own chain and then the ZK proof also requir state that is like you know dependent like for for each transaction so you need like real time proving for each transaction it's not just block level if you want you want to ignore all the optim assumptions um so there will be a lot of like dependency issues um actually implementing such a system um but again like you know we we are still like working on research on this direction but I just want to bring a totally different view on like not just economics but actually from MTH adoption how you build a really really high performance system and what the future will really look like if you want the whole blockchain system you to handle

like 10 million transaction per second and is that like several like relatively high performance system and you really limit what the inability look like maybe just a thinking compatibility uh which is more practical or you want to enable this which will influence the design for each Roop um but yeah those are some of my concerns just bring a different view on like you know how we are thinking about that um but we are also working on Research to kind of help you know how we can solve this problem I think Muhammad might have some some right up um but yeah those are some of the concerns and uh yeah perfect thank you year um I guess years talk was the first talk that was not specific to base sequencing but applies to any shared sequencer um do you have any clar clarifying questions

from the audience uh Ben I feel like I'm speaking a lot so if somebody else has a question you should go first uh okay so um thanks for the the the the presentation so um I guess two related questions one uh you sort of presented as we should either decide to like limit interoperability for everyone and have better performance or not but couldn't you imagine uh that there this would be a there would be a design space for rollups and some rollups would choose to interoperate at the cost maybe of uh of of throughput and others maybe

they're they're only servicing some like very High three-pot games that don't need interoperability and and then they just choose not to yeah yeah yeah that's a good question so it's just cify so I think they are definitely like design space and to allow this happen if some opt into such system and allow economically like they can interpretate each other because if you really think about like long-term endgame for rup like what you know like how many rup will be there like there might be very general purpose and why people are using that it's because they are general purpose they have enough liquidity and then they can process enough transaction so I guess most of the will adopted like grow up in a very very longer term will be high performing enough so that they actually need more like a synchronous compatibility to that influence their

performance less influence their less less and then like there will be maybe some like smaller rups and then they can kind of allow this to happen but with totally different assumptions so I think that's totally fine like you know it's totally possible to have some robs like designing that but if you really think about longterm like you know what they kind of 10 million transaction per second like the whole system will look like how many general purpose will look like what's the requirement for each up and should we allow this to happen um so it's more from like very very long-term in the game for like large General proper thr up but also it seems to be it's a decision that rollups can can make to to allow cross train message processing even if they are part of the ethereum shared sequencer or not like

they could in other words some pre-confirmation don't have to do with cross-chain messaging they just have to do with making promises over Atomic uh guarantees I want my transaction execute on two different rollups I don't want to actually pass message confir do you see especially coming from a ZK rollup do you see like you talk about the um these you know concurrent systems as and and and parallel processing as as being very important for efficiency of processing you know tens of millions of transactions but what uh to to what degree is is this like concurrency uh really getting around the bottlenecks especially for for I guess ZK rollups where you have you're doing so much computation I mean so much

computation to produce a proof relative to this databased processing that I'm wondering how how you see when we have tens of millions in transactions and the ability and you know to produce proofs for all of them that the um the uh the interdependencies that will be caused by uh by by cross dependencies between these databases will create a bot neck yeah yeah yeah that's a good question so because like as as like it's definitely like you know for prover you require way more like computation but it's very easy to kind of out Outsource to like another like decentral Pro Marketplace and then making that highly parallel and then finalize later using optimistic like firstly you commute data and then like you later handle this but this is will actually definitely become like State

growth and all those stuff you know how you process your transactions those things will definitely become a bottleneck when you grow really like let's say like go over like 10,000 transaction per second or something like that so it's definitely become botton neck like you know at some point where we reach the level of massive adoption because you know everyone talk about like you know where come one billion people into ecosystem into ethereum but if you really think about like one billion people Everyone send one transaction per day it's already required over like 10, like you know through P just like for for for payment like only so it's like really like you know if you I imagine like blockchain is really getting massive adoption instead of just like playing like a toy where you have like you know 10 or like 100

that will become like a very like maybe just to guess if 99% of your work is in the proof H then it seems like proving is what needs to be distributed and if 1% of your work is in constructing the state changes that need to be proved then it doesn't seem necessarily hard to construct if there's single proposer who's proposing for multiple uh uh you know multiple rollups it could calculate for each of these rollups what the state changes that's 1% of the work and then 99% of the work needs to be distributed I guess that was the the point yeah yeah yeah I don't understand that but even that like you know basically the problem like you know even you allow like very complicated machine to run that like

allowing this kind of synchron compatiability in a distributed system is just very it's a bad design from like how you design high performance system and that's basically a conclusion from the liter of another like space and which you know like we are working on some Benchmark and looking to like some practical like evidence but yeah all that like yeah we can discuss offline perfect thank you yeah um next up we have Alex from ZK sync but I'm not sure he's on the call Alex are you here um I think Alex is on a flight oh okay that explains great so we have uh time for the last talk as well uh Alex Wat um on pre-confirmation based Market

manipulation hey everybody my name is Alex I am the founder of Fast Lane Labs were an me company uh focused on validator aligned me on polygon and app aligned me on uh pretty much everywhere else um I wanted to go over one of the potential attack vectors and I find this attack Vector to be particularly nefarious because it's it's not one of the most intuitive ones um the way the attack Vector comes about is when we start looking at pre- confirmations as including uh information on the uh result of the execution of a transaction and so if we look

at uh splitting the hold on I think Zoom is disrupting me a little so if we look at splitting the Val Val of a pre-confirmation in two components you're looking at the inclusion being one uh and the information being another um there is a lot of value in that second component um efficient users power users think you know statar teams Etc what they will try to do um if they want to be as efficient as possible is cram as much information requests into the return data uh of their pre-confirmation such that when they are getting back this you know low latency like very high-speed uh pre-confirmation

result they are going to have a lot of visibility on the new state net of a series of other pre-confirmation that would have been happening before which would also be you know very latency sensitive so what this does is it opens the door for a few different attack vectors uh the main one that I'm want to focus on today is the fact that people's actions uh especially for Bots and other automated Traders are often a result of other you know prior actions that happened before for example if a bot wanted to purchase a th000 JD coins on an amm uh then they may or may not then sell a th000 JD coins on a

centralized exchange based on the results of that pre-confirmation if an oracle updated successfully then because they know that the Oracle updated successfully then they won't do another update um if a swap reverted um BAS Bas on the pre-confirmation then they might initiate another swap on a different amm um if a balance increased if a balance threshold is met then maybe uh a offchain auction OFA mechanism might match an intent to this you know user whose balance increase because now they have enough of a balance to actually fulfill an intent and so what I want to focus on is the fact that pre-confirmation or SE in guarantees solely based off of

giving them incorrect information about what happened to their transaction um as an example let's take a user who wants to do a swap let's say this is a uh statar Team of some kind so they send in a transaction to do an Arbitrage Swap and as part of the return data they want to get the rates of the pools after the swap you know what was the price impact what was the success what's the current rate now and you know maybe they want to do another swap afterwards and so the pre-confirmation or the pre- confirmer uh could take this swap execute it exactly when they said they would like sequence it

correctly but then lie about the return data they could tell the bot hey uh your swap reverted sorry um but by the way these are the current rates based on the state requests that you put into your transaction knowing that the bot would then see the current rates and think oh my gosh there's an Arbitrage opportunity still I should submit another transaction but in fact the bot's transaction did go through so now they're being artificially tricked into doing a second transaction a second swap in the exact same pool that the preconiran-food.com Bots work and so the

preconiran-food.com then you start running into some issues with latency races such as how do you know that the return data is fake um one of the ways is you could actually have a P2P gossip uh Network you could have return data get gossiped among a set of

peers but keep in mind that this is you have to prove a positive rather than you know the absence of something and so in order to detect some sort of equivocation or fake return data even if the as the real data which they would presumably do so they don't get slashed they can even try to you know trick that they would send out real pre-confirmation data to all of the other nodes and they could send out the fake pre-confirmation data to the user which by the way uh in the M world it's fairly straightforward to identify the IP addresses of all the major players so I think we should assume that they can be detectable unless we're looking at the encrypted uh P2P which I know a lot of you guys are working on which is

pretty cool but anyway I S this to say that it does become a latency rate and it would be trivial for the precon to delay propagation of the real pre-confirmation uh result until after it knows that the target the victim fees the fake data and has time to respond to it with another real transaction um there's a lot of different potential attacks it's not just the sandwich um some of them are quite nefarious and importantly if the free confirmer knows that it's going to be slashed it can just stack these up um the lower the nodes in this uh P2P gossip Network the more vulnerable they're going to be and the majority of the solutions to this

problem have significant impact on scalability or throughput as Ben and Ellie have been uh talking about a lot so I'm going to skip that part of the uh slide deck because you guys hit pretty much every uh point that I was uh looking at the other like huge issue though is that if you did want to have a user like validate it in real time without having to rely on a gossip Network and you do have these that came before it that also has some scalability issues that has huge issues

and impacts for cross chain and interrupt and it kind of also it's like really really uh incentivizes vertical integration um because it's quite difficult to price this kind of thing uh otherwise uh the biggest issue is that you can calculate like whether or not something like this would be profitable before you even like do the attack and so when you're running into like insurance and insurability for something like this you generally want to make sure that you don't have like a a hugely adverse uh selection component where you know the attacker would only do the thing you're trying to sure if they know that they are profiting more than the you know insurance would cover so it it

it does make uh pricing Insurance quite difficult um collateral solution could also get reused excessively but um yeah that's that's the the general idea I know that there are some uh sequenc or specific mitigations that could be used I'm super excited to learn more about those but I think in general this is something that we should definitely keep an eye on as we dive deeper into this uh the validity of not just the sequencing but also the result perfect thank you Alex I guess Alex's talk was the first talk that was even more specific um uh I guess I should say even less specific because it applies to all sequences with these types of of pre-confirmation not just

base sequences or or shared sequences uh we have a couple hands up uh and then we'll close the call uh ktic and then Noah yeah thanks thard for presenting this um I didn't really think about this as an attack Vector but it definitely is um that being said a few things to push back on um one given your construction like your initial solution of just having them sign and then imposing slash ability conditions on if they sent the wrong data um which is easily traceable after the fact I don't think that the premise of um them only taking these opportunities when it is profitable necessarily holds Because the actual

pre-con for themselves is kind of doing like a statar in of itself right where they're sending incorrect data but they don't have confirmation that the actual me bot is going to act in this data in a way that's going to be profitable for them so I think the dominant strategy for the bot would be okay let's opt into um both the pre-conference signing whatever the post route is or like whatever transaction data I want after my Swap executes and then also wait to hear from X other nodes who have gotten this gossip to them if there's any disagreement that I can slash him if there's no disagreement then I can continue with my swap accordingly um and then that's just negative EV for the

actual pre-con fer uh in this in this setup so I would I would push back on on the the first part um I do think it would be very high conviction for the attacker to know ahead of time what the what the profit would um the way that you can calculate volume for Star like this is looking at the liquidity of the pool as well as the uh spread like you know the rate Delta between you know binance and Unis Swap and so like like there's not that much drawing outside the lines of all the major market makers if we're being honest and so I don't think it's on the actual pricing of it I think it's the the uncertainties is coming from is this

player going to execute how I think he's going to if he's running a naive bot that like immediately sees this and trusts it or is he going to whitle but get confirmation from another note that okay this is actually correct if it's not correct then he's going to slash if it is correct then he'll execute but if we're looking at like a first come first Ser thing then anyone who Waits will never win well I think this will just be the dominant strategy in that you know thing and then you're only waiting like one network hop which is minimal latency maybe like 10 milliseconds right but like there's be someone that doesn't want to wait and actually wants to get the money and like you wouldn't be able to know ahead of time sure I guess that'll just get priced

in maybe Alex thank you so much for your presentation um no if that's okay we'll move your question to the the post call uh discussion thanks everyone we're closing the call here and uh chat soon by