Workshop on Rollup Sequencer Economics: Open Questions, organized by Ben Fisch | a16z crypto

Transcript

so thanks everyone for for coming here so this is going to be a little bit different than your standard uh seminar series but we're trying to fit it into the 11 to 12 30 PM slot today and tomorrow this is going to be a little mini workshop on shared sequencing for Roll-Ups um and hosted by a16d thank you so much um I'm Ben Fish I'm the CEO and co-founder of espresso systems which is working on uh decentralized and shared sequencing for Roll-Ups I'm also an assistant professor at Yale University so let me first quickly just go over what the agenda is going to be today and uh and tomorrow so we're going to have uh guest speakers today just to

introduce the topic I'll start then we're going to have Josh Bowen who's here from Austria another company that's also working on shared sequencing for Roll-Ups we have quintus here from flashbots who will be talking about um some of the med aspects and tarun shitra as well uh who will be here should be here in like five minutes I think he's just running a bit late but uh we'll be giving the last talk uh to runes from gauntlet so uh tomorrow we're going to then convene here at 11 if if some of you can't be here that's fine but you can just come for the talks but it'll be wonderful to have as many people participate in the uh in the working group discussions as well we're

going to introduce the three open problems that we'll be discussing tomorrow today and then tomorrow it would be great to have split into three groups work for an hour discussing them whiteboarding whatever and then have someone from each group present for 10 minutes at the end okay so great um participants of course a16z research team we have the some roll-up teams who have are are joining remotely over um over Zoom so we have some people here from ZK Singh from optimism from Aztec and then additional guests in addition to the four speakers I mentioned including myself we also have

um Michael and John who just walked in from DVA uh and uh Uma who's in the back at succinct Labs right so great um let me first just start introducing the uh the problem space here so roll ups are horizontally scaling the application layer of blockchains um we can think of Roll-Ups as making it such that when you add new transactions for new application or even an application that itself hosts many other applications it doesn't computationally burden the layer one because you can have a designated set of servers that are even just run by that application

who do all the computation and just prove the results or report the results to the layer one so the key points of of a roll-up are that it enables charting of computation across applications and two that it's leveraging heterogeneity in the network so you can have very powerful nodes that are doing the computation help weaker nodes do less computation right if every single node participating in the blockchain at exactly the same computational power then you might get the benefit from sharding but roll ups are really taking advantage of this heterogeneity as well which is a natural feature of the realistic networks that we have today

um and so the the weaker nodes in the layer one can be very very decentralized whereas the powerful nodes which are doing the computation are typically less decentralized um today roll up servers control a lot so uh these roll up servers that are either app specific chains or more General platforms like optimism and ZK sync uh that host on top of them uh other applications they centralize the entire process of deciding which transactions to include and in what order so people are concerned with that undermines some of the point of running on blockchains in the first place because it gives these roll-up servers

the ability to perhaps censor it also leads back to monopolistic pricing and Mev unless of course these servers are trusted a lot of the mechanisms that have been designed like EIP 1559 that can achieve non-monopolistic pricing rely on the myopic behavior of miners or validators in the consensus protocol and that very much has to do with its decentralization um so we'll talk a bit more about economics so um with the roll up servers uh controlling this whole process it's as if the L1 is really just auditing the Integrity of web to Applications rather

than really leveraging the the layer one to to actually run web 3 infrastructure um so one solution is to sort of separate this ordering from execution entirely so that the roll up servers are not are only doing the the the the sharding of computation which is what rollups are supposed to do and we can still use the layer 1 infrastructure to just make data available and order it so the L1 would only order transactions make it available to Applications uh roloffs would be reading from this uh from from this from this layer one that's ordering the data and then just proving reporting what the state changes and proving the results

a ZK roll-up would prove the result in an optimistic rollup would of course just report the result and somebody could challenge it through a fraud proof um so this has also been called base role of architecture but I sort of see this is just using the L1 to to do the ordering and availability um and so again the architecture is that the rollup server would uh would would read a transaction stream from the from the L1 and then report to stay root and and produce proofs the users will be submitting the transactions directly to the uh to the L1 um there are some challenges but I'll get into some of the challenges later I won't develop on them right here uh something else to note is that we could

separate out this ordering layer into a layer what we might call layer one and a half so that it's actually separate from the from the layer one itself and why might we want to do that well first of all just protocol modularity so uh it's nice to have a separate logical protocol that's handling the ordering and availability even if ultimately it's run by the same physical nodes as the as as the layer one like ethereum but there's also an opportunity to make different design trade-offs from uh from the L1 so you could make design trade-offs that optimize for higher throughput perhaps lower latency but not the dynamic available availability that ethereum has and if you do so then it gives you the

ability to give pre-conformations a layer one and a half with fast finality can provide pre-confirmation that a transaction will be included in the execution tray case before it actually gets settled on the on the L1 okay so that could be those could be reasons to do a layer one and a half yes is there a reason that you keep grouping together the ordering and the availability you view those as fundamentally linked um I do view them as uh as as fundamentally linked but you uh because a service that provides ordering uh typically would also provide availability but you can view them as separate modular components of the same protocol yeah um you can be ordering references to

available data in some other data availability layer yeah um but typically a consensus protocol which would be used for creating finality on ordering would also be leveraged for availability because it availability is almost a step within consensus so but that that's a little in the weeds but logically they can be separate um speaking of which logically separate but same physical node so through through through the Advent of services like eigenlayer as well um we could even get the L1 validators to opt into running these other protocols um and then the only thing that is

changing from a user's perspective is the properties of the protocol not this not the physical set of nodes who they are trusting to run the service so the other issue with Roll-Ups and uh in general like app chains that are now through rollups scaling the horizontally scaling the the the the execution layer of ethereum is that it leads to um to to more isolation between applications so it compromises on liquidity and interoperability applications on different Roll-Ups are isolated from each other bridging across rollos becomes complex atomicity is limited you can't easily do a crossroad flash loan Etc um so one question that comes out of

this is can shared sequencing Health interoperability uh well there are some advantages okay they can partially simplify Crossroad bridging anatomicity this is a whole other discussion topic so I won't go into this too much I'm going to get to the open questions that we're going to be focusing on in the workshop um sharing a single consensus layer as opposed to having many many independent consensus layer can reduce systemic security risks that comes from bridging across diff many different consensus protocols um but and the one that I want to focus on the most is that it can support cross-roll-up building uh with economic bonding and uh and this Crossroad building is also what gets us to this

cross-domain Mev problem which leads to some of the main open questions that we're looking at today so let me just focus for a bit on what I'm talking about here in terms of cross-roller building so um a builder who tries to build blocks simultaneously for multiple Roll-Ups uh faces complications and and a high and oh uh well high high risk of failure rather than success you could say at high risk of success um but the if you're if you're trying to simultaneously win auctions for multiple Roll-Ups and you're making some economic uh you're making some guarantee to a user that or some promise to a user that you will only include their transaction

on one roll up if you include it on the on the other uh you're taking on a lot of risk because there's a possibility that you'll win one auction for one roll up and not the other right and so your transaction will end up being included on one roll-up but not the other um so if you're a builder who's trying to provide promises across multiple Roll-Ups at once it's much simpler if you only have one consensus protocol to talk to that can auction off wholesale a super block for all the Roll-Ups at once to you right so through proposer Builder separation a consensus leader can accept from a builder's simultaneous blocks for one or more Roll-Ups and now across row of Builders can promise any form of atomicity from flash loans to Arbitrage

um and the fact that they're that they're uh that they're up that they're only they only need to talk to this one consensus protocol makes that possible now this could either require the user's trust in the Builder or economic even better economic enforcement of promises so Builders could post slashable bonds such that if they violate their promises then they would get slashed there are fraud proof mechanisms for doing this Uma actually has a very nice post on uh on on how you can have a fraud proof mechanism for us for a special subset of the things that a builder could guarantee such as bridging and atomicity or across roll-up messaging um but in general the shared sequencing layer ensures that an honest Builder who

is trying to fulfill the promises to the to these users will not get slashed if it doesn't violate those promises and that would not be the case without a shared sequencing layer uh here's just a diagram of how this all fits in this is a diagram from from espresso but it would look similar for other uh project architectures as well okay so now I want to uh quickly introduce the three open problems that we'll be focusing on okay so um first is revenue sharing how is revenue shared among roll-ups or applications even that are sharing

the same sequencing layer in fact you you could even look at this problem of how Roll-Ups utilizing the same sequencing layer share Revenue as a problem that we would already have should already have today on ethereum uh it's just that applications on ethereum are not demanding a share of Mev but if you view Mev as the revenue which is being generated by ethereum that's not being shared with the applications that are generating it so uniflap could say well look I'm contributing a lot of Mev why don't we get to share of the Mev it's all going to the validators um Roll-Ups have raised this as more of a concern perhaps because um you know Roll-Ups are also layers as opposed to just applications but in any

case I just want to point out that this this problem has already existed before the Advent of Roll-Ups because all applications share an underlying consensus protocol or sequencing protocol and we could try to solve that problem for applications on ethereum as well um so for basic fees right it's it's straightforward because you can see um okay all the transactions for this roll-up or all the transactions for this app are paying this much we can give some of that amount that they're paying back to those users where this becomes a lot more complicated is when the revenue that's being generated by an individual transaction or or a set of transactions from it from a from an application or a

rollup are not so transparent uh and this is uh the case for Mev so the marginal contribution of each roll-up to the overall mov is not transparent in fact nav can be dependent on private information available to various agents in the system it could be information on some exchange somewhere that they that they know about um and in general we only discover the total Mev by running an auction and it's very hard to uh to truthfully simulate an auction for each roll up independently to see what they would get if they were running if they were running the sequencing layer themselves so how do you figure out if we were to

isolate this roll-up what its overall contribution to the Mev is right that's that's the problem and that's one of the main uh open problems we'll be discussing tomorrow so if this problem appeals to you um you should come join that group um it's connected to this order flow auction problem where the goal um is okay so we have users users are submitting transactions you can think of Roll-Ups as just special types of users um so in this order flow auction problem uh uh the goal is to design a mechanism which will allocate to each user some rebate for some fixed percent of their marginal contribution to the Mev uh there could be very variations of this uh where so users are submitting

their transaction to some trusted party or ideal functionality that we Implement somehow that's running the auction uh the the auction uh is taking bids from Searchers that bundle these user transactions in different way and then ultimately this this results in some bundle or block with a payment to the sequencing layer and some rebate to the user um so the goal here of and I'm being intentionally vague here because I personally don't fully understand if there's a single definition of an order flow auction so it's describing it in a very general way here but in terms of this goal uh you know variations could include ensuring that users get a certain percent of the Searcher and

sequencer profit and as I was discussing with Tim yesterday that could actually be quite hard even for an individual transaction if you have um if you're running for example a second price auction where one party is bidding much it values the transaction much higher than the other then we only discover what the second price is we don't discover from just looking at the blockchain what uh what what the what the complete what the total value of the Mev is to the Searcher so the rebate would not necessarily capture that overall Mev it would just be capturing the percent of the sequencer profit or only the winning bid which could be perfectly fine I'm just pointing out that there could be different variations of this goal here

so what exactly is the goal with um with Roll-Ups sharing a common sequencing layer so I would say that one way of looking at it is comparing two different worlds one in which users or Roll-Ups would directly run the auction with Searchers so they would directly auction off their order flow to searchers um this corresponds to every role of running its own sequencer right because then see then the Searchers are going to talk to each roll up individually and every robe is running its own auction uh compare that with the users or Roll-Ups sending their transactions to a sequencing layer which then runs the auction with the Searchers and gives some rebate to the users so the question

is can we design a mechanism in this world over here which ends up giving roughly the same rebate to users as users would get in this first world over here other people may have different ways of looking at this problem so if this isn't helpful that's fine the overall problem is just how do how do we make rollup sharing the same sequencing layer happy that they're getting their fair share of the overall Revenue um so too quick very quickly and then I'll pass it off to Josh so another open question is whether a shared sequencing layer can be agnostic to uh to to to choices around how different roles want to approach the

Mev mitigation problem uh so there's many different approaches to addressing Mev right from optimizing it to preventing it entirely and there are many examples there's different types of auctions there's also first come first serve ordering policies there are approaches where we try to keep the transactions hidden until after they're committed using threshold encryption mechanisms to um so to try to achieve some kind of content oblivious ordering policy there's various Things based on time delayed permutations the the design space is very large some involve various assumptions others do not so some some of these ordering policies can only be implemented

assuming an honest majority of of validators so the ultimately the question is if we have one sequencing layer that all these different roll ups are sharing um to what degree can this sequencing layer be agnostic to the the Mev mechanism favored by each roll up right could you have one roll up which is actually implementing a first come first serve ordering policy could you have another which is threshold encrypting um intuitively for threshold encryption it wouldn't be too hard because you could just have all the transactions for one specific roll-up be threshold encrypted they're all still being processed by the same sequencing layer but those are threshold encrypted the um the key could be shared among a set of

servers that are designated to that roll up it wouldn't need to necessarily be uh be part of the the common infrastructure and you could do the same for first come first serve perhaps so this is an open question it's one of the open questions we'll be discussing tomorrow if this appeals to you please come tomorrow and join that group and finally a sequencing layer also needs to charge something uh for transactions to control for congestion and spam but since the sequencing layer is not actually executing each of the Roll-Ups this statelessness leads to some challenges so first of all the sequencing layer while it can easily charge based on the size of transaction data that it's processing

it can't easily charge for the gas being consumed because it's not executing on each of these Roll-Ups it doesn't exactly know how much gas is being consumed perhaps there's a perhaps the data size could be a proxy for the number of constraints that you're creating for a ZK proof system but I don't know exactly so this is a this is an open question um can you bound that right uh the other um the other issue is how how does the sequencing layer even verify the correctness of these fees if you want the sequencing layer to be stateless but you're asking it to verify the fees that isn't exactly compatible so it requires keeping some minimal State perhaps this could be a separate roll-up that's just for the sequencer fees or it's tracked

by the sequencer consensus protocol itself perhaps it involves a separate fee token um and and that can also use lead to ux challenges because users don't want to make fee payments in two different uh uh okay so those are the three open problems and I'm going to pass it off next to uh Josh from Austria to go a little bit uh deeper on shared sequencing layers thanks Ben um so I'm Josh I'm the founder CEO at Austria we're working on a very similar thing to Espresso uh shared sequencing layer for Roll-Ups I'm going to go over I'm not going to answer any of these questions I'm going to kind of like restate some of them and by and large

the goal of this talk is to cover some potential architectures and generally just come to some shared understanding of like what is the even design space that we're working within such that we can have more productive kind of workshops you know tomorrow where we say okay we're at least all speaking somewhat of the same language on the assumptions um so you know it's been stated some of the open problems you know in shared sequencing really the top three are going to be these Revenue allocation the Mev mechanism is not agnosticism and the transaction fees um and so I think I'm going to start at like a very low level and kind of work up so we'll say like what is the sequencer when we use this word I think there's different definitions used by different projects um for kind of the point of this

discussion this is the very simple architecture I'm going to use for a sequencer and what I'll say like is a centralized roll-up today you have a user they're going to submit transactions those transactions are going to go to the roll up sequencer that roll-up sequencer is going to give a soft commitment to the user saying hey I saw your transaction I received your transaction I give you a promise that I'm going to include it in my next block and then the rollup sequencer is responsible for generating a batch of transactions a block there technically doesn't need to be like a one-to-one thing there but they are going to be responsible for posting the data to a data availability layer in the centralized sequencing design and there's some flexibility here we're going to assume there is like a separate data availability layer that is like the

mental model like Astra uses rather than necessarily coupling the sequencing layer and the data availability layer um together and and then this data availability layer will give a firm commitment of inclusion the reason for a lot of this you know if we look at ethereum today um a lot of this is for like speed reasons and and ux reasons that like an end user prefers right you know we can go look at you know all of Google's research they built on from like stuff from the 90s on like what does a user prefer when using a website they generally like to click a button and have a response in this one to four second window anything longer than that can start getting concerned we look at um ethereum and ethereum is going to have 12 second block times um so that's a little bit slower than a user would

like a confirmation um if we look at you know what I'll turn like the Next Generation da layers you know specifically Celestia is one I'm obviously most familiar with data 15 second block times right now so again these base d a layers are giving us block timings that are slightly slower than what an end user might prefer so one of the benefits of the sequencing is giving this faster user experience um what's a shared sequencer um I'm going to use a relatively again simplistic model here we're going to assume that we have a user and we have these roll up RPC nodes I'm not going to go into too many details on those in this talk but we're going to assume that a user to submit a transaction has some server that they are using a wallet or like a app that is talking to you know

this server and that allows them to actually construct a what I'll say like a stateful transaction that corresponds to a specific roll-up right so the users are not going straight from you know themselves to like the shared sequencer which in our model is kind of taking opaque bytes and it says hey look I'm just ordering blocks and these blocks consist of opaque bytes and it is the job of a roll up somewhere to choose to interpret these bytes as a transaction within its kind of state machine but the user is presumably going to interact with his roll up our PC um and then that RPC is somehow going to communicate these transactions in some serialized kind of opaque format to the shared sequencer and then it is the responsibility of this shared sequencer to then give the soft commitments to the

user and the benefit here right is that we have um you know one shared sequencer for many Roll-Ups and therefore we can get you know as Ben discussed right you know consensus over this we can get different design trade-offs um for kind of the strengths of these commitments something I'm not focusing on here but I think it's like well known right is existing you know centralized sequencers that are run for a single roll-up are generally like one node and they're not like one node in practicality I'm assuming optimism is running like a high availability cluster but from like a logical actor perspective right there's a single entity responsible for running nodes in this case the shared sequencer has kind of represented by the three boxes um it is assumed to be like multiple actors in kind of a decentralized network mechanism similar to like an L1

blockchain and then again the shared sequencer this is some Nuance here but there is some mechanism by which batches are being posted a DA layer one of the open questions that we can cover tomorrow if it's interesting is is it beneficial for the shared sequencer to be at a consensus level responsible for posting these batches essentially is it a slashable offense if a shared sequencer who gave you a soft commitment does not do the additional labor of relaying that block to a DA layer of your choosing and giving you a firm commitment later that's actually like an open design question I think but this is what I'll use for a simplistic model here um to go through I'm going to throw like a what I view as like a transaction life cycle here right so we'll assume that transactions or you know intense if we

want to go down that rabbit hole um start in this what I'm saying like unordered transaction space in a standard L1 this would be a mempool that would connect to a peer-to-peer layer I specifically don't label this a mempool because as I think quintus will go over there's a pretty broad design space of where transactions come from I will generically refer to this as order flow wherein transactions start and there is kind of this moment of a user signs a thing and that says the user essentially giving authority to say someone is allowed to like debit my you know account account on a given State machine but how that kind of flows from here is like a pretty broad design space but then the transactions become ordered in a block and then they eventually become

executed and so specifically for this discussion I guess it's useful to go to the more labeled one we're going to say sequencing is the act of ordering it is specifically not the act of executing wherein executing actually generates an update to a state database as well as like a resultant state route we're just going to assume Merkel Roots now we can talk about vertical trees or whatever but we're gonna assume that there's like a you know deterministic state route from a given State DB and then there's an additional stage that we're also not going to cover that is like proving where you know we view proving in this kind of linear fashion as like you know the actor who is doing execution improving probably the same person but strictly you could do execution and not proving um but there is like this this is like

the linear flow we're going to assume of this talk you can disagree with this but this is what the premise I'm going to base the rest of this on um the important thing as it relates to kind of this yeah him so in the last slide you kind of said oh it's a shared sequencer of course it's sort of decentralized and is that because once you've decoupled the sequencer from the roll up you're worried about censorship for example or why did you make that jump there I guess so yeah I'll go that one right so I guess this is a little bit of like a personal premise to some point of like what is one of the root problems of kind of the sequencers within Roll-Ups right now and there is this concern about censorship resistance and centralization in general right you know we can get into Mev and we can have

however much kind of fear-mongering you want right but there's like strictly like you don't know if like you are being censored by like a given sequencer right like it's like not visible because you don't know right they could reject it like it's like a you know I'm not like a distributed systems like research PhD but like there is like you know some general understanding of like it's hard to prove whether you're being like censored or whether there's just like a latency thing like you just get a 500 when you submit a transaction like ah is that malicious or is that just like the system's not working right um decentralization here gives some benefits in that censorship resistance and generally what we view to the idea of like why do we have a sequencer versus posting data to the DA layer directly or to the L1 directly right is

generally to get this speed and generally this liveness property right you want to have a faster response time so you want to have some like useful commitment going to a decentralization probably applies like a consensus algorithm because now you want consensus over that you're in like a less trusted system um but yeah it's an assumption that like that is like a fundamentally like that's the useful thing we actually want out of that one of the things kind of shared sequencing from at least the asteroid perspective kind of evolved out of as like a thing that we wanted to create was because in what I'll say like the the celestial realm of sovereign Roll-Ups there was at least an assumption that the naive design does not necessarily give what I'll call like an inbox model or like a fourth transaction inclusion from a base layer

and if you assume you don't have that there are obviously designs that could have that but if we assume you don't have that you've dramatically increased the importance of the censorship resistance of your sequencing layer and so for us it was kind of necessary to say that must be decentralized because if you don't have forced transaction inclusion then you know you're just done if you get censored there I see so you envisioning so if you just think about a single World running its own sequencer you kind of also have in mind like today's designs where you do have the forced inclusion and so part of your vision here that's the Roll-Ups is like they actually are a little more they're not they don't directly ever interact with el1 perhaps yes exactly and without that escape hatch you need to hold the sequencer accountable is that fair

summary yeah that's kind of the past dependency of like how we got to like our origin of like oh we need this decentralization as like a top priority you know we obviously see all the existing Roll-Ups having you know roadmap items for decentralizing their sequencers but it's strictly like lower priority for them because they can say look if it crashes or if you think you're being censored you do have today a mechanism by which you can get around that whereas our initial design said well we don't have that so that bumps the priority of that I think Tim's point is that decentralization of the sequencer and sharing of a common sequencer are still two orthogonal things yep it's hard to imagine all Roll-Ups sharing a centralized sequencer for but they are still yeah and I think one of the things about you know we use

the word like shared sequencer like in Astro Express I think we use in a very similar way but the kind of implied you know actual like all the adjectives are it is a shared decentralized lazy sequencer is kind of the set of adjectives that we would Define the whole thing but we generally assume that's like a shared sequencer whereas you know Uma has had like a post on I think you caught like a like a validating sequencer or like a validity sequence thing right so there's other designs but we're using you know two like this assumption right where the sequencer is doing this step it is not doing this step it is not doing this step right we could proceed all right yeah so going back right order flow here we're going to say that's kind of generic I'm not going to go and do

too much depth in that but it's very relevant right where are the transactions coming from I'll have like a final slide that'll post some like kind of chaotic option for how this can happen and how it might have implications on Mev and various Revenue sharing sequencing is the one we're really focusing on going from a set of unordered transactions to an ordered block and then we're going to assume execution improving is done kind of beyond the scope of this right and the important point that Mev is occurring at The Ordering of the block right we are also assuming um again this is like again this very broad design space but we are going to assume that the execution layer is not reordering the block based off of the sequencer's order because you know yes that is within the realm of possibility but there becomes a question of why are

you using a shared sequencer that you are presumably paying some you know Network fee to do ordering for you if you then choose to also do ordering yourself it's a little bit of a question of what are you getting here um not that there's nothing you can get like liveness you can get like availability right but generally we're going to simplify the problem and assume that we're not reordering and thus Mev occurs at the sequencing step right so this is like a slightly modified form of like the kind of standard Mev supply chain flow um and we're going to explain like this similar to the transaction life cycle we're showing like who the actors in the system are and so for this diagram like I've used like a shared sequencer mempool that can be abstracted and I think I have like other slides that abstract this to make it a slightly

simpler picture right but this is I think I'm assuming we're like generally familiar with like the Mev supply chain space right you're gonna have a user they're gonna go to an RPC they're going to sign a transaction that's going to go to a mempool in like a normal you know sequencing roll up or even an L1 that's going to go to like you know the specific mempool of that L1 and then Searchers are going to look at that mempool we can expand this to say you know where are Searchers acquiring their order flow more generically right it could be from something like Suave it could be from like off chain whether those are auctions whether it's you know a payment for order flow style system them whether it's through any of these kind of like Mev shielding like RPC nodes but Searchers are somehow acquiring that those Searchers are

building bundles that then Builders will build in the blocks and the shared sequencer proposer is the thing that is actually receiving a block you know on ethereum like L1 today I think we're sitting at I don't know quintus you have more recent numbers but like what it was like 90 or something of blocks are still going through like Mev boost and we're looking at about four Builders and as I understand its Searchers and Builders are not as separate of entities as they may often be modeled there's a bit of like kind of consolidation but this is you know useful conduct to have here's a more simple model we're going to say a user sends an intent an intent could be a transaction execution Trace whatever but you have order flow that order flow is going go to Searchers and Builders which assumes these are kind of Mev

actors off chain within the system again the shared sequencer proposer is going to receive that um the kind of key thing here right and tying back to like where does Mev happen what are the things if we assume that the shared sequencer is a thing responsible for doing the ordering and the roll-up node if not reordering the transaction after that then this shared sequencer proposer is the entity in the system that has Monopoly on The Ordering of a block and as I'm sure everyone is aware from like an economic principle right the actor that has a monopoly in the system is going to presumably be able to extract the most rent out of the system I believe on each we're looking at somewhere in the 90 range of Mev you know profit is going to proposers right now that's like back of the envelope that like I've you know seen on Twitter

um so this is going to be a similar situation but we've pushed this to Shared sequencer proposer right and obviously the implications from this right to all this is well okay I'm a roll-up right and I'm using this why do I want to inject a third party that has Monopoly on ordering to extract you know essentially the you know transaction you know revenue of which Mev is essentially like you know you can think of it broadly as like the real market rate of you know transaction inclusion um so this is kind of a useful framing thing um I want to touch on briefly to kind of get to like a definitional thing about think about this um the word and kind of the history of like Asteria is originally ruined what we're calling a settlement layer and we've referred to l1s as settlement layers before this term is going around

it settlement is like probably a relatively poorly defined or at least agreed upon term within crypto I actually like Nick Carter's definition he gave from his post on like it's the settlement Assurance is stupid from 2019 I think um you know it says that settlement Assurance is referred to a system's ability to Grant recipients confidence in an inbound transaction will not be reversed I think this is useful when we say a soft commitment this is kind of the actual guarantee that an end user is expecting to get right they're saying you told me that you accepted my transaction and I'm going to not worry about that transaction anymore we generally have a kind of two-phase thing of this soft commitment and what we call a firm or a hard commitment wherein you get a soft commitment from the shared

sequencer you get a firm commitment from a DA layer but it's all kind of these settlement assurances and then we can go into fraud proof and fraud proof windows and ZK proofs and whatever but that's what I'm going to use it's like the definition of like settlement here so then if we ask at like a higher level like what is a shared sequencer um we can hear that a c-shirts there's a single domain where multiple Roll-Ups are being settled right and again we can get into definitions of like tiers of finality here right where like well what happens at the Shared sequencer gives you a commitment and then that data never shows up on a DA layer or proof is never generated for that data right but fundamentally the expectation that Roll-Ups using a shared sequence are getting is giving some sense of settlement in that transactions which go

are paid to be included in that and get put into a block by the shared sequencer are settled for some definition of settled here um so now I'm just going to cover kind of the open problems and restate them a little bit again we have Revenue allocation Mev mechanism agnosticism and transaction fees um again going back to this this is a useful kind of set of assumptions we're making that the shared sequencer has a monopoly on ordering and if we think about this one again right Mev occurs here so ordered block Mev right uh Monopoly on ordering in this like Mev supply chain thing if we think about Revenue allocation I'm just going to State kind of the problem and some potential kind of like sub questions here right you know the top level question is how is revenue shared between multiple Roll-Ups using

um a single shared sequencer um you know and there's kind of two components of that there's you know the the how of the what is the you know fair or deserved portion of the total revenue that a given single roll-up should receive there's also like a what I'll say like a like an architectural like an engineering level question like what is the method by which this revenue is shared so let's say we have some magic mechanism where we say we know a priori which percent of all the sum Revenue should be given to which Roll-Ups where are we sending that Revenue right who is the roll-up in this case right like What entity is responsible for receiving that um what state machine would a rebate even exist on right this ties into the transaction fee question is we are we

collecting the revenue on the shared sequencer which might have a minimal State machine for transaction inclusion and then we're paying the roll up on the shared sequencer how is the shared sequencer aware of who the receiving party for a given roll-up is is there some registration phase to say I am this roll-up do we have some kind of governance mechanism by which you say well there is a set of namespaces that may represent individual Roll-Ups and you have to have some mechanism of claiming a namespace ahead of time prior to using the shared sequencer so I think beyond the kind of you know question that is beyond kind of my you know specialty of how do you kind of economically calculate like a deserved amount it's literally even if you you knew that how are you choosing to pay

what is an entity that is a roll-up using the shared sequencer again I don't have an answer I'm just you know adding questions here um we think about Mev mechanism and gnosticism I'm not going to go too in depth here obviously but it's fundamentally right like can a shared sequencer be agnostic to a given specific Mev mechanism favored by a specific roll-up right so Ben covered right you know we can think about like first come first serve we see like arbitrum has a very strong kind of like desire for that threshold encryption has been proposed by like the shutter guys as well as I think the fair block guys and the radius guys are doing some kind of threshold encryption thing I think as well that makes a little bit more sense because you can again just say well the transactions that are going into the

shared sequence there are just opaque bytes and they are encrypted and then the roll-up is the entity that knows how to decrypt those right it can kind of work through this we have on ordered transactions we get an ordered block and then their execution and at the execution phase is where the threshold decryption Could Happen um but then fundamentally right the kind of driving question we're thinking about here is like to be like a useful whole thing right what are the constraints that a shared sequencer must inherently place on a roll up to just exist right if anyone's used like in a web 2 world right you can use an API and they can often be very generic but fundamentally to Define an interface it can't be perfectly generic you have to pick some level of kind of definitions and say you have to satisfy this interface

um and then touching on transaction fees right so this is kind of I'll generalize today like what inputs does the shared sequencer proposer accept right and so if we go back to that kind of like Mev supply chain style right where we could have Searchers and Builders or off-chain actors in the system right you know what is that shared sequence or actually accepting is it accepting like a full block where this block may be what we've called like a mega super meta block of one block that represents many many um you know potential roll-up things is it accepting bundles that may be bundles for one Roll-Ups um you know set of transactions it could be a block that a roll-up would prefer to be the entire block for that roll up in one go and so we could have a layering of this Searcher Builder mov

supply chain um a lot of options I have like a slide that kind of shows the kind of like chaotic level of like optionality in this space there's all the who pays fees to include transactions on the shared sequencers like Ben mentioned right there's like a ux question I'm a user I use my evm or my Zora roll up right I want to pay transaction for or pay a fee for a transaction on Zora okay but Zora says yeah but someone has to put this in my shared sequencer is the Zora RPC node responsible for submitting that is the user responsible for signing a transaction for the Zora specific State machine then wrapping that transaction into a shared sequence of transactions signing that and now you have to account for balances on multiple chains that's like obviously like a problematic user

experience um and then you know expand if you're like what currency are these fees paid in so that ties into again the question of is it a roll-up specific you know currency is it a shared sequence or currency or all positive even you know what I've argued in a couple talks before like there is this like Cosmos problem of when you have many many tokens and to use a given chain you must have the native token of Any Given chain you start to run into kind of like fragmented liquidity issues you know I think the example I always use with like and I think I'm pulling this from the skip guys it's like stargaze you want to go buy an nft on stargaze okay you have to get the star token to do a transaction well the star token only trades on osmosis it has about 50 000

dollars of like annual volume so if I'm an end user I can't buy osmosis actually if I'm a usn user I can't buy osmosis tokens on coinbase I have to go to coinbase buy some atom Bridge some atom to osmosis to then go on osmosis swap that atom four star tokens to then Bridge those star tokens to Star now I can buy an nft that's just not gonna happen for like any like I'm not gonna do that and like I work in this space like someone is not going to be texted by their friend to be like oh my God there's a cool nft go buy this and then be like here is like a seven step process by which you have to pay fees to get tokens to literally make the purchase right so there's a question of what currency are these fees paid in

right and this expands not just to the inclusion on the shared sequencer but also from the roll-up sense I think we've punted on this or at least not had it kind of come up in the ethereum roll-up land because all the ethereum Roll-Ups use ease for gas right we've seen at least mantle propose that they will use like the mantle which is like I think like the shifting of like the bit Dow tokens say the fees would be paid on that roll up in like the mantle token well that's going to have a ux impact on what is the possibility of an end user requiring the mantle token that is adding friction to your ability to use this application for app specific Roll-Ups they might say I like to have my own currency there's benefit from that like a monetization sense but okay now you have to solve all the liquidity

problems right um so that's another thing I'll kind of add to the complication here um so yeah these would be kind of like the closing things right um what are the fundamental limitations imposed by a shared sequencer right you know with this design um and the Monopoly on ordering right um I'm gonna assume the shared sequencer proposer defines a canonical block ordering that is going to be like the bare minimum thing we're assuming here and that the shared sequencer must have some civil resistance mechanism like a transaction inclusion cost which has implications on the fee structure right and then this is the last kind of chaotic thing I'm not going to go into this but this is roughly a thing with like all the different ways in which a user could get a payload and submit that payload over to a shared sequencer proposer down here throw blocks there's

a lot of Pathways here um obviously it's a complicated design space do you support all of these do you support some of them presumably we're not going to have all of these with like an equivalent distribution but this is the broad space so sorry for going over hello everyone my name is quintus and I am from flashbots research I focus mostly on incentive related problems although I'm sort of all over the place sometimes and I guess today's presentation will be evidence of that I I did uh craft this presentation with a like a sort of a high context group in mind um so I'll try and give like sort of the background where necessary but just feel free to interrupt me I I left time for questions and I'll leave time at the end as well uh at least I hope to um and so

I'll be doing two things today I'll be addressing the first question that um Josh and Ben highlighted which is sort of this like auction Revenue sharing problem uh between different Roll-Ups or domains participating in the shared sequencer um and I at first I'll sort of set the scene explain my assumptions establish why the problem is hard and what the problems are and then maybe like split ball some possible solutions um and so I'm using espresso as an example here the pi level sort of like entities I'm thinking of here is this um amorphous cloud of block building and for those familiar it's like Suave and all sorts of other activities happening here I don't think it's necessary to go uh into too much depth

um but we sort of assume they're sophisticated actors who are receiving order flow and transactions and turning these into blocks and then we have the shared sequencer um which is like you know a one unit but consists of many smaller units and I'm treating this as a proposer Network right so for those familiar with PBS that's the basic idea um so it's not that espresso is necessarily or whichever shared sequence is necessarily producing blocks itself but it's sort of receiving blocks from an outside outside Market um and this interface between the outside market and the proposal network is complicated there are many questions you can ask whether you want what kind of

interface you want exactly um yeah a bunch of questions there and I'll sort of leave those for a different talk um I'll Focus specifically today on this question of oh so there's supposed to be some robots over here but it doesn't matter just you can imagine there's some robots and the question is there's some value flowing into this proposal network from the auction how do we divide between these different domains and this is quite a hard problem um and part of my explanation for why it's a hard problem is going to be hard to see without the robots but anyway um before I continue I'll just make the uh one assumption clear which is that I'm assuming the active governance of the sequencing of the sequence domains right

so you can imagine I don't know optimism using espresso um one we one would imagine that if optimism is willing to use espresso they sort of believe that they'll be able to Fork away or change the the way that their blocks are formed if ever something happens and they disagree with with how espresso is evolving it's not a super important um not a super important assumption but it might come up later so I just thought I'd make that clear and maybe that's an assumption I shouldn't be making and we can talk about that afterwards and so sort of the main point I one of the main points I want to communicate is that there's no obvious implementation for how this auction should happen and how the revenue should be shared um a paper just like one week ago came out and apart from that it's on a super

well studied problem most of the results you can find or many of the result results you can find in the setting and I'll go into the setting in more detail in a second or quite negative right um crypto poses a lot of challenges because we have these guarantees we try to provide permissionlessness etc etc and because of this a lot of the mechanisms we might want to rely on are not actually um that feasible or may not be feasible in the way we understand them um and so apart from not having not being able to enforce or like use the techniques which we might have traditionally like to use we have the additional problem that um you know dollar signs isn't the only way in which you want to divide some

things you can imagine two domains um opting into shared sequencing where one is some lending protocol and another is a sequencing like a a DEX is it it's not clear that just by Revenue again from any of the auction um that you can gauge exactly how much one domain is gaining versus another you know a blending protocol doesn't maybe generate a lot of Mev until one day it generates a huge amount because there's some big price movement and a lot of a series of liquidations they're gaining also from maybe a reduced risk and these kinds of things and so there's um it's not exactly clear how you want to chop that up um to give up a bit more color as to why

um without my robots why it's difficult to to solve this problem we have basically like two sides of a problem here one is like a combinatorial auction and the other is maybe you can think of like as a coalitional game theory problem we have to split things up um so the first problem is civil bidders and now there are multiple clones of the invisible robots over here which makes things hard the the second is that there might be collusion right so you can imagine that um a user example of optimism again optimism is participants participating in some auction and by somewhere the auction is defined some behavior of the bidders changes how much revenue goes to um optimism so they might submit bids in the auction themselves to try bump up

how much value there um getting out of the auction or their share of the auction similarly you could have one of the bidders just sort of having their own domain sort of inserted on the shared sequencer if the shared sequencing is is uh permissionless which would allow them to bid higher on you know basically like a a null item dud item and channel some of that revenue from the auction back to themselves allowing them to bid a naturally High I thought I would sort of lay out some possible solutions the kind of the kind of directions I outline here depend on the underlying um shared sequencer and and how that's defined um but yeah I'll

um lay these out so the sort of philosophy for my approach to this and I think a lot of people are flashbots have also been influenced by this comes from a paper in 2003 written by David parks and some of his co-authors which was I think remarkably prescient and what it all uses basically that um you know we're in this world with lots of infrastructure interacting lots of decentralized infrastructure operated by different interested parties um it all has to interact in some way and so we really should think about incentives we should be designing mechanisms that have all the like guarantees we like and mechanisms design is very important for this but at the same time mechanism design is very brittle in that it's assumptions

um it makes many assumptions and incentive to those assumptions holding so if um you make some assumptions and those turn out to not be true or not be true in a year's time your mechanism might just do the opposite of what you'd like it to do um similarly we can't this is it's not always easy to agree on what kind of guarantees we want the system to provide do you um optimize for efficiency or revenue or these kind of things and so what um David Parkinson's co-authors argue for is a market for mechanisms which is um we want to be able to choose which kind users should be able to choose whoever should be able to choose which mechanism works best for them and if we make have this Market satisfy you know properties which we like it's open it's

a centralized it's competitive then the best mechanism should rise to the fall and so embracing this kind of philosophy um I'll make the assumption that the shared sequencer has a smart contract layer um and um the reason this is necessary or interesting in this case is because we're moving this sort of opinionated decision of what should the auction look like uh into something which is in the control of um the domains which are being sequenced um and can be modified and so I'll give I'll give a couple of examples of what that could look like so the most basic example of what uh what this could look like is you can imagine just a single metablock with a fixed split so um the proposer at every round is

receiving um is running an auction basically for one block of blocks for all the possible for all the domains that are being sequenced and presumably the um in that cloud of block building I was showing earlier there's some mechanism for the the different economic actors to sort of aggregate their um aggregate their activities into one um metablock which is kind of already happens on ethereum today and it should be able to work um and you know a very basic way of dividing values just according to a fixed split and so your contract could imagine you can imagine your contract looks something like this um which is a nice in that it's explicit and and um if something needs to change you only

have to update the contract but still a fixed split's not very interesting conditions change um you know how you divide the value might not um you might not want to keep it the same you might want to vary with market conditions and these kinds of things so I should think of value as like the winning bid in yeah Builder or something like this so it depends on how you define the auction but let's say we can imagine running like a first price auction or something and that's the highest bid um right or whatever like Revenue right auction Revenue um a more interesting example is like a same metablock setting but with variable split so you can imagine that the the contracts are offered more inputs about the outside world right so

um in this example you're running I'm running three different auctions one for domain A and B together one for domain a and one for domain B you can imagine again like three first price auctions or whatever um and according to the input from these auctions we decide how the revenue should be split between the different domains and maybe even according to this you can decide which is the which block should be should be the sequence block um but here what we've done or like maybe to explain how I'm thinking about this in my head I said we say okay we have a problem that we don't know what auction mechanism we want then we say okay it's fine we'll we'll create some programmable auction layers so that the best auction mechanism for the occasion can rise to the fall and people can sort of choose

between that but now um we have a second problem which is that we don't know how to get the um any sort of like notion of ground Truth for these mechanisms right we need to get credible signal and to come back to this broken picture from earlier um one one uh sort of challenge I didn't list earlier is that this proposal could um okay these slides are completely messed up but anyway um this proposal um also has offers some challenges in that they could be either dumb or dishonest the dumb proposal case is a bit easier to deal with and that's just the case where um the shared sequencing layer doesn't want to maintain state for all of the

different um domains so if you wanted to do something like divide Revenue based on like volume on different domains um that might be a bit hard to do for the for the shared sequencing validator but I think we can get around that the harder question is a dishonest proposer right so um the basic example is auction revenue is three dollar signs they lie they say it's two dollar signs they take a dollar sign for themselves um and this this to me is like where the most uh interesting problem or yeah interesting questions come from and here's where I'll sort of like spitball some solutions and then leave everyone else to think about a little bit more deeply um one example is

um you could just leverage the active management from domains right so if optimism and all determine whoever being sequenced by these shared sequences then they could also be monitoring the public relays and cross-check whether um the the auction Revenue makes sense right so if you think about oh maybe I should say what relays are in the like proposable the separation design it um that we see in ethereum today there's um bids are public base that's about the most important partner so since these bids are public or at least the majority of them are um you can sort of keep track and see if there's some mumbo jumbo happening in the auction um a more interesting example is um

looking at Tex um which I will not explain now um but the mechanism for implementing private relays among other things and I think a lot can be done here so for example you can check a te proof I was just basically a signature um that um the the bit it's producing is the highest bidded scene or that it's um you know that because presumably the relay has maintains the state of the underlying domain you know that the um you can sign something about like the volume of the block uh the volume of Trades and the block and these kinds of things this there really has a lot of information and if you can rely on the te proof then you um you should have a lot of external signal um

this is mostly a response to the dumb proposal problem so you don't have to calculate rebates as the auction happens you can do it maybe later when um the sequence of transactions the block is being executed and information like the volume or whatever is available either in some L1 contract or or somewhere else um this is probably the solution I've thought about the least so I'd welcome more advanced people to think about this um then another idea is to make shared sequence of validators stake tokens according to um whatever like reward ratio you want and the idea here is that you can't make it might be hard to have a proposer or like anyone tell you exactly how much in

the auction earned how much revenue you brought in but you can um there should be a like knowing how much it'll bring them they should be willing to stake at least the appropriate amount to get the risk like Risk adjusted returns um and so this is a probably a way of getting a bit more credible signal and also to um gather value for the appropriate tokens an easy way of doing this would be having the shared sequence is just take a token which corresponds to an underlying treasury which is rebalanced according to whatever properties you want and the last point and then I'm done um is you can use a committee to determine the signals right so an example of this would be what uh they're trying to do

with meth burn and ethereum which is to establish what the like highest bid in the auction is by having a committee of validators or a testers agree roughly agree or at least a lower bound on what the the highest bid is and of course you still have problems um problems with this and that you can have collusion and as soon as the committee colludes you don't know what the um it's very hard to trust what the what that signal is but it's much better than having an individual be able to um yeah deviate unilaterally so that's basically all I have yeah any questions so for that that last bit was the focus

more on estimating Mev in a single roll-up or estimating it kind of at the Shared sequencer are you talking about the Lost point or the last slide last slide um or is it a mix yeah the the question is sort of like if we allow these um if we want to enable these like sort of smart contracts which Define the auction logic we need to give these these smart contracts some input which they can work off to compute what the reasonable output should be and so the question is like what what kind of input can we provide that's like like a reasonable it's not that easy to manipulate and that sort of exploration of this the third Point um is both a way of achieving like um

signal but you can see how much people are staking um but at the same time it directly does the redistribution as well um is this for though is this for a single roller or for a multiple yeah you can do it I guess who wasn't entirely clear to me here is that part of the issue is that if you're running if you're running an auction for one roll up then I mean there could still be challenges in figuring out because of because of gaming what the actual Mev is but it seems it seems like that the main challenge is that if there's multiple roll-ups um who are participating in an auction figuring out what is the actual marginal contribution of an individual how do you

simulate the auction for an individual Roll-Up yeah this is the point I was trying to make with the market for net for mechanisms point in that there's no obvious way to do this there's no like sharply value approximation which like Works under all conditions or not that I'm aware of right um and um but you can leave it up to the domain to sort of figure out or try something see if it works doesn't move on to the next thing but also maybe leave it up to the Roll-Ups themselves or yeah yeah so yeah when I say domains roll ups in this case really right how would you be leaving it up to a domain or a roll up to uh estimate its own Mev and Report not to estimate its own Mev but to come to

agreement with the other domains which are being sequenced with it on what the mechanism is for establishing it's it's a contribution right so in this case it's like a relatively like simple thing but if you if you know what the highest bid was for domain a the high high speed for what was for domain B and high speed was for both together um you can maybe use that information to like find some allocation that's in the core or like in this case I guess you can just find the sharply value presuming that searches are going to be bidding separately and then also together they'll be doing all yeah if you if you run them if you run the auctions and give them incentive too then then you could right um yeah Uma but what if two different Roll-Ups like never agree like they have to come to consensus and agree on like

this the auction mechanism for both of them so what if they're just like fundamentally not agreeing like yeah it's a resolution yeah I agree with that point but I think that that's an issue you have no matter what you do right if you enshrine it's like this is like we are espresso or Austria or whatever and we're going to have this specific allocation method it might still be that the the rollup's gone that doesn't work for me you know so here you have a bit more a bit more freedom and hopefully that means that people um domains can find something that actually does work for them and is a bit more reasonable than as opposed to having one specific thing and then having no choice outside of that and how do you allocate like even the voting power between the domains

yeah great question this is like a generic like we're going to pre-negotiate a contract and say there are five Roll-Ups and like enshrined into the auction mechanism of the shared sequencer State machine right it says I'm going to pay out my block rewards in this distribution and if you don't like that then you don't have to submit transactions like the shared like you have to use it right but like fundamentally we're saying we're pre-committing to something essentially it's so I think there's a separation here between the logic of the underlying shared sequencer and the like smart contract layer implemented on top which is what I'm suggesting right so I'm saying you have a layer on top which implements the auction logic

um does that make sense but we should require the shared signature to have its own VM yeah yeah I guess I I would assume it would be within the logic within the state machine over here yeah I I guess it doesn't it's like semantics how you chop it up yeah so I think we'll we'll switch to room is here right yep turns in the back okay turn um we'll be up in a second but I think that the source of uh source of disagreement is is due to the fact that I mean would would only be the case if there isn't an optimal solution like an optimal solution would give to each roll-up exactly what their marginal contribution is yeah so you're saying supposing that

we don't have one we're just going to have to come up with different heuristics or approximations then it becomes difficult to convince everyone to agree on what the heuristic or approximation should be yeah and I would contend that even if you had some notion of optimal that notion of optimal wouldn't EXT would be like restricted to okay this is how in the example we have one domain which is a like lending protocol where lots of liquidations happen in the other we have a decks it might be the case that according to just like pure Mev Revenue the sharply value says that this one should receive you know one third of the revenue that one should receive two-thirds but that might not be how the roll-up teams think about it because you know one is gaining a lot more because they have like reduced risk or whatever

because a liquidation liquidations are more efficient and so even if you could find like a numerical mathematical optimal solution I don't know if that's going to cut it could you can you define it though in terms of what they would get if they were running it on their own you can't simulate that but yeah if you ran multiple if you ran multiple auctions and you assume the yeah well the problem is because you can't run you can't you can't simulate it because it's not the reaction won't be run drill right the there's only one auction that's actually even that has payouts but well you could run multiple right well well but then you have to Define what the outcome would be so you could run if you're running multiple I mean how do you run every road runs its own auction and then you run an auction involving

all of them you still have to justify you still have to Define what the outcome will be yeah but that would be that would be the contract it's not the same as simulating each of those auctions but there could be a theoretical definition of what the definition of what a rollup would get on its own is perhaps well defined but the problem is we can't come up with a single mechanism that discovers what that value yeah cool well thank you uh let's go go to Turin uh hey so I'm gonna talk a little bit about sort of some of these issues somewhat more theoretically but uh nothing more than high school math so maybe Middle School depending on what

your background was but uh the main point that all these things have have sort of got at is all of this type of mechanism design has very different trade-offs than single chain mechanism design a lot of things don't make obvious sense and so we'll talk a little bit more about the uncertainty that you maybe have to lean into quantifying here so you know everyone you know any Mev is both attractive and unattractive uh research topic because it has such poor definitions um you know I think most of the papers I've proved any theoretical results about Mev acknowledge that their particular definition only encapsulates

some aspects of it and not everything I think Tim's recent paper has a whole paragraph dedicated to saying that statement uh and so I was just trying to preempt all the Twitter responses yeah yeah uh and so uh I think a better way to think about it at least from a statistical point of view versus sort of the optimal algorithm point of view is there's a lot of uncertainties in Europe on particular users uh usually unsophisticated users by more specific users so I like to think of these uncertainties as ordered in terms of certain types of payoff uncertainties so

what does a payoff uncertainty mean so we have some notion of a risk measure uh in this example like in the bottom right corner it's a variance conditional on some event sequence and we have a set of payoffs sort of a function class think like statistical learning theory basic type of stuff we take a supremum over that and we say this is sort of a Mini Max loss rate and my claim and this is heuristic is that as you go to the right you're actually increasing those payoff uncertainties for these different classes of uncertainty of uh issues that come from Mev and cross chain systems so ordering I actually put at the lowest end which is pure ordering not

censorship and this is reordering transactions increase particular user payoffs whether it's moving your sandwich attack to the back of a block because it gets higher Revenue because the other trades in front of you or moving around Oracle updates who can do a liquidation um inclusion is you know censorship of yeah alighting transactions to have certain things work or adding extra transactions uh to to change payoffs for other people I put that as high higher uncertainty uh the next one which I think is the one that shared sequencing in particular is kind of meant trying to deal with is is atomicity where you know a lot of

developers a lot of users are used to expecting some types of advocacy guarantees and blockchains and those out of Missy guarantees are stronger than their expected guarantees and normal Financial systems but obviously the lack of administic guarantees in yours passive participants a lot more um and so there's a sense in which the payoff payoff uncertainty goes up now again I I gave an example by just saying it's a variance of Health but choose any coherent risk measure whatever you want uh I I think like defining it is the hard part to compare across these so this is again meant more as a qualitative comparison um the next thing is the relay which is

Network layer attacks of where and how cross-chain execution is transactions are executed uh you could argue that these allocation problem for how auction Revenue gets distributed Falls in this category and I put the highest uncertainty it at the data availability layer so you might say why why would the highest uncertainty be there isn't it supposed to be reliable we have data availability sampling we have all these statistical guarantees the problem is imagine a fraud proof is executed how much is the user State worth after that and how much do the auction behaviors change how much do the valuations change for the end users that could be arbitrarily high and so that's sort of where I I consider that as like

extreme loss of stationarity in the expected valuations of users and so I put that highest is there a particular reason that like variance is more important than like the first moment in these cases like if you have to worry about data availability isn't like the first order issue not the variance just the fact that like you're like payoff is probably lower than if you don't have to worry about that particular thing yeah I think the the main reason I hesitate to use sort of like just pure expectations and is more that um for for a lot of these things they're extremely discontinuous functions also they're sort of they tend to have this

property where uh when they lose stationarity they have like extreme jumps to zero and I that's why I said like I don't think of variance as this fixed functional here I I'm saying like choose some functional think about like any statistical learning theory type thing right you you have a Mini Max loss but then you have a certain per instance loss metric I chose variance as an illustrative one but this is just you know what I would say again it heuristic you know the the the distance between these things is not is not linear in the spacing on the slide Okay so cross chain mechanism design you want to contr what's the real goal is to

construct mechanisms I reduce this uncertainty for users given a payoff class so you know to the the point that um quintus made uh earlier about a DEX roll-up generating regular Revenue stream uh but have small payoffs versus liquidations which are very irregular and have high payoffs you have this uncertainty partially because um in in some ways these these payoffs you can't really like optimize them Point wise I can't say at a given time here's exactly how you should allocate at all times right you can only kind of say over some long time interval over some learned interval I learned some

approximate allocation rule and this is this is kind of where I think a lot of the classical mechanism design kind of does fall over is that it other than sort of some of the recent learning and auctions literature is is that it kind of is not flexible in this way and one interesting thing about the cross chain world is there's much more complex trade-offs than a single chain so for instance reducing one type of uncertainty may increase another so you know depending on on your view on PBS You could argue that it reduces inclusion uncertainty now for the average user that might be true for the Searcher that might not be true so again the it's a little bit duplicitous but it does increase relay uncertainty you rely much more on the

relays than you did before um and optimal guarantees that might be possible and the single chain might actually have impossibility results in multi-chain and again this means that your problem is a lot more like Cisco learning understanding online optimization and less like classical here's an optimal allocation statically okay so um I thought I would go through the list of different types of mechanisms that people have and if it's not a comprehensive list includes a bunch of them and then categorize them by the level of rigor of understanding of them um and with a natural reference to Donald Rumsfeld by this little tree and uh the idea is that like a lot of

the things that people have proposed or talk about have no actual analysis of the economic uncertainty um and I think a lot of things that claim to have get around that like first come first serve things are usually quite duplicitous and how they represent them um and so but if you look at this we were talking about things like decentralized sequencers data availability sampling uh lifetime Bridges intense I put in quotes but they all have very different levels of understanding of this where they fall on this uncertainty diagram so you might say oh well auctions are great we understand them must be awesome like why don't we just use them for

everything well I'm going to go through some examples that show you that there's feedback in these auctions in Cross chain land that mean that a lot of the classical uh results don't work in a black box manner than in the way you might think so one thing maybe more from a historical standpoint is to talk about why auctions might be harder than you expect well historically centralized entities have enjoyed abusing multi-venue auctions a lot so this is from the Justice Department's case against Google in which Google actually manipulate auctions that weren't their own but also other auctions where there were people sort of building on Remnant Supply and

they added sort of fake bids on alternative auctions to make theirs more attractive um so you know historically this kind of abuse exists and is is a bit difficult to to manage second I think these kind of these properties that you really like in auction Theory like seller intensive compatibility or credibility buyer intensive compatibility communication complexity they become a lot more difficult in the open world of permissionlessness and having trouble with civil resistance um but so you have to end up using more complex mechanisms or you find some impossibility theorems that you know are

not fun okay so now we can go through through what I call the simplest non-trivial example of why uh cross chain auctions are actually sort of significantly more difficult to reason about uh and don't have the same sort of classical guarantees so the the get onken question is uh is it better to sort of bid in two cross chain auctions so I have two chains A and B um the idea of the setup is going to be these two chains have a DEX that's trading the same pair of assets so you could think of it as like X has X versus synthetic Y and Y has Y versus synthetic X and assume there's a one-to-one

Redemption of the synthetic tenderly so you know as I go across chain I have a way of redeeming um and consider an auction where you you have an Mev auction where you bid on each leg separately you bid on chain X separately from chain Y versus one where you bid atomically the atomically is the version of the shared sequencer right I go to the shared sequencer they run one auction and they give me some not full but partial guarantees that they execute the bundle is as specified Okay so we have the two chains we have the two prices uh and we're gonna assume without loss of generality that chain X has a higher price chain y you know there's some type of Arbitrage

so you know basically Buy Low sell High you you kind of do the execution and what happens is you end up you know you you change the price on chain X by the current price minus some slippage you change the price on chain y by the current price plus some slippage uh and you get a profit if the the units under that Loop are positive so now if we try to write out what that looks like we you know simply look at the no Arbitrage condition again I'm not telling you what the slippage function is just treated as some arbitrary thing for now um and you can write out what the profit

is where you also include the gas costs denominated in X terms so this is as if you paid atomically in units of x to buy the whole bundle um and then of course you can always convert it to Y based on the no Arbitrage price um and you can also compare that to bidding separately so bidding and x and bidding in y and you you split this into two legs and so you know one question and one important thing to note is that in the process of doing this Arbitrage you are changing the gas price on the remote chain so you're changing the bidding price that you're actually paying because the decks actually changing the

price of the thing you're bidding in so now you're not stationary there's feedback between the actual bidding in the auction and the the item you're buying which is the Dex trade and so now you might say okay let's compare the p l of the atomic so I'm bidding into the share sequencer for a single bundle versus the separate I'm bidding on the two chains separately and you'll find a condition that says hey actually depending on the price and the slippage functions and and the bids you'll find that in some cases the separate auction is better and in some cases the atomic auction is better and what this sort of says is like your optimal mechanism in a long-running process where there's stochastically

arriving trades where the auctions are interlaced by the fact that bidding in the auction changes the price on the other side uh is sort of the stochastic optimization problem it's no more the stationary I have a set of valuations I choose a Myerson reserve price dot dot whatever you learn in basic you know algorithmic Game Theory it becomes a lot more like this stochastic control type problem and so you know the answer is there's not really a sort of best unique auction format it's actually better in these cross chain environments to be usually good for most payoffs which is slightly different than hey I'm optimal in some some sense

and again I think in the auction Theory world there's there's actually a lot of recent you know efforts on studying this type of problem where you're sort of learning what the optimal Revenue should be learn what parameters should be optimally but the weird part in the Dex example is this feedback the idea that the item the purchase of the item changes the actual thing you're bidding in you have to incorporate that feedback process in the worst case right because like you know there's obviously things of like cross chain nft bidding where the nft doesn't impact the price on the other chain right but this Dex case is actually quite important because it's the largest source of Mev in general so understanding it is

actually key to understanding what these things are okay so now we have uncertainty we hopefully can agree that it exists it's kind of something we are going to have to Grapple with so how do we quantify it and this is where we just I you know kind of this again all of this is coming from from work I'm we're working on on kind of getting some types of bounds on these types of things but um the key thing is that users have a variety of non-stationary payoffs changing in time and um I think a really great example of why you have to assume non-stationarity is uh you know this active versus passive proposer paper that Tim put out recently

where effectively if there is non-stationary payoff you get a very different auction Behavior amongst users um and you could think of this these payoffs as taking in sets of transactions sets of blockchain history and some notion of metadata the metadata is something that is kind of different than the single chain environment the metadata includes things like what routes are you taking across chains how did you choose those routes it also could be mechanism parameters like do I bid separately or do I bid and atomically assuming you could do both and we have some sort of notion of welfare which is you know the the payoffs for the users minus some notion of Maintenance costs when I say

maintenance costs I mean things like paying the bridge things like sequence or fees things like excess fees that are not included in the single payoff world um and then you just try to optimize your your med data for some regret measure right again very simple classical type of stuff and so you know just as a walk through example of this kind of simple Dex Arab example you might say okay let's look at the best in hindsight uh regret for this Atomic for split bidding so go backwards so say I see a sequence of Trades I see how they would have been executed and I compare the was it better to do atomic versus split

and then try to learn a policy of like how do you choose one or the other over time and kind of these learned mechanisms can be more robust in some ways at least in for a large class of payoffs then uh uh you know a very fixed so you know that I kind of I hopefully it was relatively straightforward I think the the main ideas are cross-chain mechanisms add a lot more uncertainties and those uncertainties interact with each other and that changes the economic payoffs users mechanisms that are well understood in the classical setting whether it's do

the stationary valuations due to sort of some notion of how you should think about the the seller are very different when you have to think about D5 where the actual action being executed changes the valuation behavior of the users and it turns these static problems into these Dynamic problems and kind of a lot of the places where and you know future soon work will kind of show there's a lot of advantages to looking at the adversarial optimization literature for thinking about this uh and you know I think the open problems are really understanding how to quantify these uncertainties and their interactions with each other uh and with that uh questions

okay yeah so in the previous slide are you modeling this as like a bandit problem with the goal of like minimizing regret over time yeah exactly it it's basically like a simple relatively simple abandoned problem but the key thing is that you have to keep track of this feedback loop right like the idea that the trade interact interacts with your bid distribution means your bid distribution and valuation distribution implicitly is changing as a function of the Dex trades on both legs so you have to be somewhat more careful where a lot of times these kind of even in like context aware Bandit problems the numerator or like the the value

function units are stationary but but keeping track of that actually makes us like a lot more annoying and changes to problem quite a bit uh and I was thinking a lot about what are like traditional finance things or online auctions things that look like this and there's not that many that I could think of like the number one thing I could think of is the euro dollar auction opening on CME does impact the US Euro trade when it opens and so like okay yeah there is kind of this FX thing coming from like a large auction but it's very it's not as fundamental as it is here because the Dex trades are just constantly changing your numerator MJ

that was kind of my question which is in judicial markets we have uh this interactivity where you have wait and see differences between a leading Lively pricing of the same equity and so we use ISO orders right to have that like conditional between two venues and so is there some type of pre-trade metadata or conditional that you could attach and say like a nicer order to say I have context that this is going to execute in two domains yeah and I don't want interactivity I mean I do think that's what all all of the people who spoke before me are working on is like how to give some expressivity to those covenants uh I don't you know I I I think yeah the interesting thing

right is that the order types are programmable like the user can choose their own order type versus the traditional Finance version of like here's a set of order types you can only use those if that makes sense cool [Applause] okay so that concludes the talks for today um so tomorrow for those who are interested we'll be having the working group discussions on the three open questions that I spoke about that Josh spoke about that quintus and uh tarun maybe gave some direction or Insight on um they're all in the Google Doc that are attached to the invitation for this event so I do suggest taking a look at

the Google Doc um since it explains the the three problems um and okay so let's conclude today thank you so much to all our speakers [Applause]