Modular March EP 15: Where Espresso Fits In The Modular Thesis

1 Apr 2024 · 48:30

Ellie of Espresso Systems joins The Rollup hosts to explain how Espresso's shared sequencer enforces transaction ordering and finality across rollups. The discussion covers based sequencing, the auction and lottery mechanism used to allocate sequencing rights, and where Espresso fits into the broader modular thesis alongside other shared sequencer designs. The hosts push back on incentive design tradeoffs, including whether rollup operators would accept reduced sequencing revenue and how an actively validated service extends the system's security.

Speakers

Topics

Transcript

welcome to modular March I'm handy this is Robbie and we are the rollup modular March is an educational experience about all things Moder [Music] enjoy [Music] [Applause] [Music] welcome back to modular march today we

have the pleasure of speaking with Alie Davidson from espresso uh to learn about based espresso not the coffee in this case we talking about ad hoc shared sequencing Ally welcome and it's a pleasure to have you yeah thank you so much I'm I'm really excited to be here thanks let's dive in um all right yeah so I'm Ellie I am H the lead researcher and also an engineer at espresso systems and today uh we're going to talk about based espresso which is this uh recent evolution of the espresso design that I think is is really really neat so I'll I'll go ahead and jump in so to start off with um you know espresso is a shared sequencer um

and I just want to level level the field by saying you know what is shared sequencing well it has two parts um so the first is you have some sort of proposer assignment and this is basically just deciding who actually gets the rights to order transactions so in ethereum um you know the ethereum proposer is the one who actually gets to order transactions maybe they Outsource that to a builder or maybe not but this is like the same idea here um and then you have the second part which is some sort of finality Gadget and basically this finality Gadget just confirms that you know once the transactions are ordered uh the ordering cannot change so in ethereum this is ethereum finality which happens after like 15 minutes so

this is kind of uh the general gist and then today I'm going to kind of dive into each one and explain kind of how espresso is thinking about doing these um the majority of the of the discussion is going to be on the first one um but we'll touch on the second one as well so uh many I mean this is very familiar but kind of wanted to go over like what the problem space is so we have rollups and they're great they horizontally scale ethereum you know you can get more transactions per second um they're really good um they also allow different VMS so you know you can do custom things you can have Niche VMS that are maybe better suited for things than the

standard evm and this is all really great um but you have a couple of drawbacks and this is why we deciding the rollup block for each

rollup um there's a couple of other things that they can do so they can also maybe save users on gas cost by waiting to post data to ethereum that's a minor uh a minor Improvement but another big thing they can do is offer pre-confirmation which pre-confirmation uh that's like my favorite topic currently in the space and it could be its entire like own talk but pre-confirmation are really powerful because they give users a really good promise that their transaction is going to be final so when you think about ethereum I as a user don't really want to wait 15 minutes for every single transaction I do on ethereum so this is where pre-confirmation come in today

rollups give these really fast pre-confirmation and as a user if I'm interacting with a rollup today basically in a few 100 milliseconds or so I can get a pre-confirmation that's really strong and I know my transaction is very very likely going to be finalized on ethereum and here you know maybe the maybe the sequencer the proposer runs an auction um to decide the sequence of the block uh that's just kind of an added little little note but now let's dive into the shared sequencer architecture that's espresso so you the the most basic shared sequencer is actually ethereum itself and so this is what's called based

sequencing and this is where you use ethereum to sequence for rollups basically the way that this works is that users send their transactions directly to ethereum ethereum proposers put them into blobs and propose them this is really great because you get all of the security and decentralization of ethereum you can get really good interoperability so because one ethereum proposer can be sequencing for multiple rollups at once they can make sure that Atomic transactions across rollups work so this is quite good but you could actually go even further and you can do so this is what espresso is doing where you add this like layer 1.5 in the middle and it might not be

entirely clear why you want this layer but I'll explain as we go on why potentially having this layer 1.5 between the layer twos and the layer one uh can give you some really cool benefits so the the main so that was kind of an introduction to Shared sequencing and what it's trying to do so now I'm going to really dive into the big first big part of espresso's design which is um a lottery that allows us to redistribute revenue from sequencing back to rollups so the problem is that shared sequencing is great you get this really good interoperability but the person or the entity who's actually deciding the order of transactions is the one that gets all of the revenue

they get both you know transaction fees for sequencing but they also can get me and the idea is that interoperability is great but rollups aren't going to want to use any shared sequencer even you know ethereum L1 as a shared sequencer if they're losing all of their revenue so this is the idea espresso has to solve that problem so basically it's a lottery but first we're going to describe it as an auction and then we'll add on the lottery aspect a bit a bit later so the idea is that you have all of these different rollups and they're all being sequenced across this shared sequencing layer this could be espresso this could be another shared sequencer this could be the ethereum L1 any shared

sequencer and so what you're going to do is you run an auction to decide who gets the rights to propose so for example in ethereum today there it's just kind of a a randomly selected who's going to propose an ethereum but you may have heard of this idea called execution tickets and this is very similar to execution tickets in ethereum it's slightly different but but similar and the idea is that instead of having your validators of the network just randomly get proposing rights for free instead you have people bid for the right to become a proposer so this is what we're going to do here and the difference here is um compared to maybe what's happening

today is that instead of running an auction for only each single rollup you're going to run an auction for all of the rollups together so this allows the person that wins the auction they can have they can facilitate all of this interoperability so since they're sequencing for more than one rollup at a time they can make sure that the atomic transactions between rollups actually work and are valid so this is what we're going to do here um so one analogy or before I go into this maybe the question though is so we have this shared auction and that's really great but we but the main point of this is that we wanted to distribute revenue back to the rollups and the question is well how you do how do you decide how much roll each rollup

is worth um it what obviously wouldn't really make sense if you just give each rollup a flat you know you say okay I have 10 rollups I'm just going to split the revenue you know by 10 that doesn't really make sense because some rollups are going to generate more Revenue than others so this is kind of the big question um and an analogy to this is like bands playing at a music festival you have one music festival you have a lot of bands the different you know different bands are going to bring in more tickets versus other bands so how do you decide how much revenue you know to give to give back so this is the problem that we're trying to solve um is decide how much how do we decide how much revenue to give back to rollups so and how do you keep them all

happy yes exactly exactly um so we're gonna do a first a first attempt and then we'll kind of build we'll build on this so the first attempt is that you have two options is that you can either if I want to you know be the proposer for rollups I can either propose or bid to propose for all of them at once or only each one of them individually so obviously if you're only sequencing for each rollup individually you don't get any interoperability that's like the the case that it is today but you can also bu for all of them at once so this is really good um you the way the the key Point here is that you can take the bids

for the individual rollup so um and you can use that to calculate how much the rollup is worth so for example let's say someone bids $10 for rollup a $20 for rollup B to sequence them individually not together well then when you sequence them all together you can use those individual bids to say okay well B is worth generates more Revenue than a so I should give b a higher percentage of the revenue back this is the the first idea but you have this problem called shill bidding which is basically well the rollup wants to make as much money as possible obviously so it's just going to artificially inflate its bid so if it knows that someone is going to win the

right to sequence all of the rollups at once but that their revenue is based on how much people bid H for them individually a rollup is just going to say well I'm going to bid a huge amount for myself and then I get you know I can get a huge amount of me back and this is this is bad obviously because this isn't a efficiently reallocating the revenue back to rollups based on their true value so what do we do well what we're going to do is we're going to allow this combinatorial auction where instead of just having the option to buy the the sequencing rights for all of the rollups or only one individual run one you can buy the sequencing rights for any combination of rollups so for example here um in this

in this picture we have all of the rollups we have the Roll-Ups individually or we have this bundle to that only that only consists of three rollups and the idea here is that you're going to choose the combination of rollups um that has the highest bids among all of them so if someone bids $20 to sequence all of the rollups together and each rollup is only individually only individually gets a bid of $1 well then obviously sequencing them all together is going to win but you go back to this shill bidding problem and you say okay let's say rollups A B C D and E are each only actually worth $1 but rollup a says well I want a ton of Revenue so I'm going to bid $20 on

myself well now instead of everybody losing out you can now exclude rollup a from the shared from the shared bundle so basically you would end up with a bundle that has b c d and e and then roll of a is sequenced by itself so so we run this combin oh go ahead no I just have a got a quick question yeah you go ahead Rob so like uh one one of these rollups shill bidding um will increase the percent Revenue that they would generate from the sequencer choosing their bid but they would also be paying more so do those two things cancel

out yeah that's a good question so the the idea is that if if a rollup itself is sh bidding on itself it's not really paying anything because it's essentially just paying itself to sequence so they don't actually end up cancelling out got it okay and then I understand that we we wish that the whole world is good actors and that everyone's just going to do the right thing but unfortunately this is the uh cryptoeconomic incentive mechanisms which we have to design because frankly that is not the world which we existent as much as we'd hope but if we if if each of the rollups or if there was some collusion where there

was this continuous shill bidding across the entire bundle meaning every rollup basically had a a a shill bidder whether be themselves or a separate entity would that cancel out where it would just be this inflated amount across the board but the proportional revenues would this for each individual rollup would then effectively be the same percentage regardless of like the of the notional value or of the dollar value I see yeah so I think in the situation that you describe let's say you have rollups that are colluding to artificially inflate their bids well the thing is if they inflate their bids too much that they actually win the auction then they actually need to sequence um and they

actually need to pay that bid so let's say your rollup a and you're colluding with b and c and you're going to submit a really high bid for the bundle a b and see because you want more a higher Revenue but if you submit too high of a bundle you will actually win that and now you need to pay pay your amount like you need if I if I bid $20 I need to pay $20 and you might not actually make $20 from sequencing that so now you're out of money so that's kind of like the control I guess is that you you don't ever want to bid more than the money you can actually make from sequencing because then you're losing money all right so yeah we we have this basically this auction that we're running over any combination of bundles

and the idea is that um kind of like you were saying is if one rollup decides that they're going to Shi bid and artificially inflate their price then they're actually going to have to pay pay that price um and they may not actually make that much they may not make all of that back by sequencing so this is pretty good um but let's take it a step further um and actually say well maybe shill bidding isn't terrible so shill bidding isn't this isn't a perfect solution but why might rollups want to Shi bid on themselves well it might be because they want to make sure that they definitely make a specific amount of Revenue so let's say you know um they

they say I don't want to actually give anybody else the rights to sequence for my roll up unless I'm making like at least more than I make sequencing by myself so we can view Shield bidding is basically this reserve price um that rollups can set that basically ensures that they either get to sequence for themselves um or if they don't sequence for themselves then they're making more money than they would otherwise um so a couple of caveats on this whole idea is that well I said we're running a combinatorial auction and when you think about that that has like that can really easily explode into the number of bundles are possible it's manageable with like five rollups on the

system but if you have a thousand rollups you have way too many combinations to realistically deal with and the then the problem becomes well how do you actually do this optimization to find which combination of rollups gives you the the maximizing amount of Revenue well the solution to that is that you can just find a good one and then you can kind of have this like short challenge period of maybe um you know relatively short you know maybe within um 30 minutes or so and then someone can submit a better one if they find it so this is a way to make this combinatorial problem probably more tractable um the other part is that

realistically people aren't going to be bidding on every single combination possible there's going to be combinations that just don't make a lot of sense so you're um so your number of of practical bids that you're getting in the system will be much smaller than the Total Space of all possible rollup combinations um so the second big part of this is that you have to run this ahead of time so this is different than like proposer Builder separation today where the auction is run just in time uh right before the block has to be submitted to the network this is run far ahead in advance and this is um for good reason so there's a few reasons you might want to do this uh a big one is

that it can kind of smooth the the expected value so when you look at PBS today the me is like really spiky and if you run the auction far ahead of time then you then people who bid have to bid on the expected value which is much flatter so this is kind of in the execution tickets post that on eth Research they kind of discussed like why this might be a good thing to have people bid on expected value rather than this very spiky me value um whoops real quick if you don't mind um so that auction would basically begin as soon as the pre-confirmation of each of those rollups were you know hit the hit the networker or hit the sequencer

effectively or as soon as those transactions hit like like when would that auction begin yeah yeah that's a good question it would actually happen before that so the so if I'm a user and I'm submitting a transaction at that point the person who's sequencing my transaction should already be known so this basically would be run practically probably like a half an hour in advance of when it's your turn to propose um so in in terms of ethereum this would be like you're running it several Epoch in advance um and yeah the whole point of it is that when someone bids to propose a block the whole point is that they have no idea which transactions are going to be included in it so yeah

that's a really good question this happens quite far in advance like 30 minutes or more in advance um so so yeah oh yeah go ahead sorry was just one one quick followup there uh how do they uh efficiently how do they price their bid that they're going to make to sequence that block if they don't have an idea of which transactions are going to be included yeah that's a good question so I imagine that there's probably a lot more uh research that could be done into this but the the guess or the what I think will happen is that these people who are bidding would be similar to like Builders and PBS

today so they kind of know roughly what they make over time so even though they won't know what they make in that specific block that they're sequencing for they can say well on average every week I make x amount being a builder for PBS so I'll bid proportionally to that of what I expect to make uh but the kind of the whole point of it though is that they don't know exactly what they'll make uh but you could say then this goes into my next point where if you don't know exactly how much you're going to make and you're bidding on this expected value that expected value doesn't change so you're just going to bid the same thing for every single slot and what's going to end up is that then you just have the same person who wins every single slot and then we have really

centralized block building in this whole problem that we're trying to avoid so this is why we're actually going to run a lottery instead of an auction and this introduces amount some amount of Randomness into the system to help decentralize this so we don't end up with the same person proposing for all of the blocks and the rough idea of with the lottery is basically it's the same thing as execution tickets in ethereum you sell these tickets their tickets are priced accordingly if all of the tickets get sold for some slot then you raise the price the next round if very few tickets get sold you lower the price and once people

bid they you know they submit their bid their their bid is associated with these lottery tickets so instead of bidding an exact amount you essentially just buy however many lottery tickets you you want so let's say I think that I can make $20 by sequencing for some combination of rollup so I'm going to buy lottery tickets that are worth $19 let's say and then then that gives me like a $1 profit margin and then these lottery tickets as the name implies are just randomly selected so the whole point of this is that this forces decentralization among the people who actually win win the rights to to sequence um yeah yeah nice just have a

question on on the graphic is his Builder with most tickets has only like blank percent chance to win I assume that that there's some sort of like mechanism in which I I mean there's a cap on the total it's available right um but what about H how does the Builder is that how the Builder is gonna have a limited percent or like yeah how does that work like what does that mean uh yeah so the percentage is like you were saying it's the amount of tickets that you buy so if each ticket you have the same chance to win so if there's 100 tickets and I buy 20 of them then I have like a 20% chance to win this auction well then you ask well why why would you

decide to buy only 20 versus buying all 100 or you know 50 and that depends on your expected value so the basically what will happen is that if I think if I think that I can make $100 or like actually a better example would be let's say I can make $50 sequencing for a block I one of my options could be I could buy 50 tickets then and out of a 100 tickets and this gives me a 50% chance of winning but this actually means I'll lose money because I'm only going to win every other time and so that so if you average it out I'm actually only making $25 per slot because I'm losing every other slot so

instead you would alter uh how many tickets you buy to take into account this Randomness percentage so you say okay if I can make $50 sequencing then I'm only going to buy as many tickets that allows me to make $50 including the CH es that I might lose like not win the right to actually sequence um so that's what that part means and and by there's a yeah I was just curious if there's there's a loss Associated by losing the auction or by losing the lottery you it says that the tickets are refunded slash canell does that mean that like what's the lot is it a loss or is it a re like

yeah yeah okay yeah so this is a good point so there's these different bundles that you're bidding on right so if you're bidding on a bundle that ends up winning so let's say the bundle for Rab's a b and c wins even if you don't win the lottery for that bundle you still have to pay for it so this is something that I don't think is clear from the slides but if you bid on a bundle say only A and B and that that combination never won then you get refunded um in practice you can you can actually get refunded in practice you just probably won't pay for it at all so in practice like you submit a bid promising or you submit a lottery ticket um maybe promising to pay in the

future um but then yeah if your combination doesn't win you get refunded so but that's a key important point is that if you s if you buy lottery tickets for a bundle that does win you you still have to pay which is how we get so you win and you still lose wa you were saying which is how we get to oh which is how we get to the true expected value so for example if a rollup is worth like let's say sequencing for rollups a b and c is worth $20 and someone who only bought 10 lottery tickets happens to win the lottery well you don't want to refund everybody else because then you only generated $10 worth of Revenue and how

can you give $20 back worth of Revenue when you only generated 10 so that's why if some someone buys lottery tickets for a winning bundle but they don't actually win the rights they still need to pay because you still need to capture the total value of of the bundle and and that would be if if someone else offers on a b and c but not as much as the person who offers the most on that combination um yeah right so the way it works in the lottery is basically all the lottery tickets are some price and the combination that has the most amount of tickets sold for it would be the

winning one okay and then all out of the people who submit on that combination of of rollups only one one person is going to bid the most for that combination so even though you picked the right combination you didn't bid enough on that combination so you would lose it's so yeah this is the difference between the auction and the lottery so in the auction model yes what you said is right in the lottery model instead of who bids the most it's just it's it's a random chance of drawing your ticket and if you want to bid the most you buy more tickets is models yeah okay okay and then and then what is the mechanism like what is

the randomized mechanism like in lotteries you know you have this a bunch of balls and a big like grate and then they're like spinning the thing and then someone like sticks their hand in and like that's the randomized function like what is like the element of Randomness that that chooses the winning ticket uh this is a really good question so this is something that we haven't set in stone yet in our design but likely we would be using a similar thing to ethereum so how ethereum randomly chooses who's going to propose they have some random Beacon we would probably use that as well um but adjust it accordingly so that it it works for this use case um but the important thing

about it is that it's a verifiable random Beacon so this is what is what ethereum has where it doesn't matter who actually runs the lottery and decides who wins as long as someone else can verify that it is actually the correct like Randomness randomization but yeah summary we' probably just use what ethereum uses got it yeah all right and then super quick wrapping up um there's a couple of things you know you could say oh what about censorship resistance you can actually argue that this is a really good design for censorship resistance because uh only people who actually value proposing for a rollup will buy

lottery tickets for it so for example if a proposer says I don't want to do I don't want to have anything to do with a privacy focused rollup because it might have sanctioned stuff on it they can they just won't buy the lottery ticket and this means that the people who do win the sequencing rights are totally okay with sequencing for something that might have sanctions on it so this actually helps censorship resistance because you're not saying all rollups have to be sequenced by one party or none at all you can allow parties that actually uh value each roll up the most so like parties that are okay sequencing for something with sanctions or maybe parties that are okay sequencing for a rollup that doesn't generate a lot of Revenue um so this is good for censorship resistance um and then

there's a couple of other caveats but um I'll I I kind of skip over those because I don't think they're quite as important um so the main point on this side is that so I basically I spent all of this time discussing this and this is just our proposer assignment mechanism but it's the biggest idea of this whole what we're calling based espresso but the second part I said is this finality Gadget um and so where does this whole finality Gadget fit in well this is the espresso Network and going back to this slide I said how you have this layer 1.5 and the the natural question is well why do you have this extra layer in there why don't you just use the layer one um so this is why

is remember that we want espresso to be based so specifically this design with espresso it doesn't Force rollups to be based it allows them to choose whether or not they want to be based so being based as kind of described in the in initial eth research post by Justin the definition is that you allow the L1 proposer to propose for your rollup that's what it is to be based so in espresso rollups can choose to be based and allow the L1 proposer to sequence for them or they can choose not to so that's the important part here is that espresso offers a lot of customization there's also the key Point

here which is there is a fundamental trade between L1 L2 interoperability and fast finality so the reason for this is that the L1 has slow finality and it can reorg so if you're trying to do an atomic transaction between an L the L1 and the L2 and the L1 reorgs well then your your transaction isn't Atomic so if you really want an atomic transaction with with uh ethereum you have to wait for ethereum finality to be sure that it's actually going to succeed this is different than a lot of l2s today who Cho who choose fast finality so they base their state off of some really old ethereum block that's already finalized

and will never reorg and because of this they can offer really fast finality so this is the fundamental tradeoff between being a based rollup and a non- based rollup but the good thing is that what espresso is doing which we're calling ad hoc shared sequencing because it allows a lot of custom customization for rollups is that it allows rollups to sit anywhere on this spectrum so a rollup can say I want to enable Atomic interoperability interoperability between ethereum and my rollup they can choose that and then another rollup also in the same espresso Network can say no I actually want fast finality and I don't care as much about uh interoperability with the L1 but there's

a really interesting thing you can do here which is you can actually take the customer ation and you can take it even further and you can allow it at the user level now this gets a lot more complicated and there's a lot more questions that need to be answered but the idea is that a user can say I have a transaction that I want to be Atomic with the L1 so I say you're okay to reorg this transaction if the L1 reorgs but another user on the same rollup can actually say well my transaction has nothing to do with the L1 and so I want fast finality and this is something that we're actively exploring at a espresso um it definitely makes things a lot more complicated because you know what happens if I have a transaction that relies on a

transaction that also ORS reorgs with the L1 well then mine kind of has to also re reorg with the L1 so it gets complicated but I think it's a really really interesting interesting open area of research that we're looking into um because basically it allows users to just have a lot of customization over what they do does this uh does this split the lottery into like two separate lotteries where you're like bidding on you're buying lottery tickets for specific transactions and not like the entire rollup bundle oh yeah that's a good question um it does not so I think well one key fact I actually forgot to mention is how does the L1 proposer actually end up in this whole like

Lottery um and there's a couple of ways you can do it one is you could they can just participate in the lottery as a regular proposer that doesn't currently work because ethereum doesn't if the ethereum proposers aren't known like far enough in advance so that doesn't work but basically the way we do it is that we allow the ethereum proposer the right of first refusal so whoever wins the lottery the ethereum proposer can say hey I'll pay you what you what you paid plus like some some extra fee um and then I can buy always buy that off of you so that's how we do it um but then back to your question uh no it doesn't so the the lottery is still on the per

rollup basis what this actually changes is just how the rollup executes transactions so the rollup will say oh this transaction is supposed to reorg with this L1 block this L1 block did in fact reorg out of the chain so I'll throw it away um whereas this transaction didn't so the the change to do this isn't at the the lottery level it's at like the you know reorg might be

something maybe like maybe you're taking advantage of some Arbitrage and that Arbitrage is with a centralized exchange and it only exists at a particular moment in time so in that case maybe you're okay with a reorg um because you need you need your transaction to happen within like a certain real time amount um let me think of some other examples I think I think bridging is probably the best example although with bridging going back to kind of this this uh this page right here there with espresso you can actually do something quite interesting which is

normally with bridging you would have to wait for ethereum finality which takes really long but because you with espresso you can have this the L1 proposer also proposing for the L2 the they can um enable this Atomic transaction so even if the L1 reorgs the uh espresso can actually say Okay L1 reorg so I'm going to throw out that transaction and what this does is that even if your Atomic transaction reorgs out you're guaranteed that it never the promise never gets broken so as an example let's say you have a transaction between an L1 and an

L2 the L1 transaction gets reorg and espresso will then make sure that the that L2 transaction is dropped so there's never a case where the L2 transaction succeeds and the L1 transaction doesn't and if the L1 transaction succeeds then due to the guarantees of espresso the L2 transaction will also always in be included so I think a key Point here is that you can sit at either end of this spectrum but you can still actually have a lot of safety because the safety comes from the safety comes from having the same party sequence the transaction so they know whether both are included or both aren't included and then the safety

also comes from the logic of espresso that it throws out transactions if they aren't included in the L1 I might not be explaining this in the most clear sense but the point is that even if you have even if the L1 reorgs with espresso you can do it in a way where the the worst you get is a wasted time okay you have to resubmit your transaction but you never get a case where one fails and one succeeds um that was kind of a tangent off of your question um makes sense but it's important because like I yeah also want to dive into kind of the the entire consensus mechanism of espresso itself um in terms of like how we're gonna

figure out the best way to to decentralize that and make sure that bad boy stays up 247 no full liveness uh but I'm sure that we can talk about that here shortly oh yeah I consensus is what I spend my most time on at espresso so really would love to talk about that yeah I just have like one more slide left which is basically um pre-confirmation so I mentioned this briefly at the beginning pre-confirmation there is two kinds of pre-confirmation generally speaking there's more but the two they mainly fall into two kinds and there are attester pre-com and proposer proms proposer proms are basically where the proposer says I promise to include this transaction when it's my term an attester pre-confirmation is when you

have a whole network of validators finalizing some transaction so for example when espresso finalizes a transaction on the espresso Network that's an a tester precom and that means that that transaction cannot get reordered unless you break the fundamental safety assumptions of the espresso network uh so this would be like you have to slash onethird of all stake if you ever wanted to reor this transaction and uh poser pre-confirmation can usually be they're usually faster because they're just one party offering them so you can get them in like a few milliseconds a tester pre-confirmation require going through consensus on the espresso network but once you have them they're incredibly incredibly strong so going back to the

bridging example if you wanted to bridge something you might not want to trust only a proposer pre-confirmation because that's only backed by so much collateral like 32 eth let's say whereas the the um espresso pre-confirmation has the weight of all of the testers in the espresso Network and has a lot of economic collateral behind it similarly like ethereum um and therefore it's really really strong so you might say okay I'm not going to wait for finality on ethereum but I can wait for finality on espresso which takes maybe one to two seconds and then I have this really really strong pre-confirmation guarantee so that's it uh basically the point of this whole whole talk is that uh

espresso can do two things we're running this Lottery that allows rollups to receive back revenue from sequencing so they get back their Mev Revenue they get back uh their sequencing revenue and the the whole idea is that rollups are never worse off participating in espresso than they would be on their own so they're either the same level they either get the same revenue or more um and then finally um also we have this what we're calling ad hoc shared sequencing which means that each Ro and some and potentially in the future each user can decide whether they want to be based or non- based and whether they want to reorg with the L1 um or not so yeah that's that's that's like the

gist um a long a long discussion but it's I think it's a really really exciting New New Direction for espresso it's awesome really really appreciate it um and thing will'll just we just pop you up here and um I feel like we talked a lot about what espresso can do uh in terms of uh this shared sequ shared sequencer network but I think for a lot of people still listening including myself and maybe Rob it kind espresso seems like this abstract magic box of like goodness that is just like this G this like all these really strong guarantees but like what is the consensus mechanism for expresso how does how does the that kind of

validation work who is who is is making sure that espresso stays up and yeah let's talk about that yeah no this is great uh consensus is my favorite part of espresso so we have a consensus protocol that we call Hot Shot and this is a protocol that it can achieve pretty fast finality so it's a bft Byzantine fault tolerant protocol and in our benchmarks we've been able to achieve finality you know between one to two seconds it depends on how geod distributed the network is and obviously the working conditions but that's generally uh how fast it can go and that's that's pretty fast actually compared to a lot of a lot of protocols um we are planning on using reaking to

secure the network so all of the validators in the espresso Network would also be etherum validators that are staked in ethereum and because of this we should be able to have quite a large amount of Economic Security even to start and then the idea is that over time you know that will grow and grow and we can our Network can have Economic Security that's very comparable to like the size of ethereum because obviously having really large Economic Security is really important um that's you know that's why people choose ethereum over you know say other other networks so uh yeah the validators are stakers in ethereum um our protocol uh also has a data availability um aspect to it as well so the reason is

that if you're doing consensus so to sequence transaction you have to do consensus that's like you know you need to have some way to have everybody decide that yes this is the sequence well if you're already doing consensus you actually can just get da for free because da is kind of a subset of doing consensus anyway so not only does the espresso uh protocol sequence transactions it also does data availability on them as well which is which is cool yeah underrated part of espresso yeah that that uh that follows real nicely from like where we left off on the slides uh from proposer um and a tester pre-c confirmations because you

mentioned how like uh if we were to kind of like use only proposer pre-confirmation we're only getting the economic security of one validator like only 32 eth but if we use these attester pre-confirmation we get the economic security of the entire espresso Network which sounds like it's going to be more it's going to be closer to like all of the restake ethereum that's like available in the economic security of ethereum and not just like a single 32 eth proposer right so like like let's say like I wanted to contribute to like the espresso node Network and I want to I want to be like a validator or an attestor on the

espresso protocol like what what are like how would I go about doing that and contribute my own like Economic Security to the espresso Network yeah yeah that's a really good question so I think the best way is that once we integrate with igen layer then you know you admittedly you do have to run your own ethereum Staker which you know requires 32 eth which might be a little bit of a high barrier of Entry um but we want to do that because we want to make sure that we have this really good Economic Security behind us um I think one also so so you can run your own home ethereum validator and then you can restake using igen layer into espresso um I think another thing which isn't something we're like actively this is kind of

tangential je espresso but is like distributed validator technology I'm personally quite quite interested in that so bullish and I think that that's like a great way too for people who don't have 32 eth but they still wanted to restake I think it'll be really interesting to see these uh dvts be able to restake on Ian layer and then someone you know with less than 32 e can also help secure the espresso the espresso Network work um so yeah those are my thoughts and I think it's super bullish to use like being in being in ABS means that you don't have to uh just inflate a potential token or in other example a token emissions to the max for Economic Security you can just you can just be

like yo we have good Tech we can use ethereum and and you know bang so yeah exactly I think yeah I mean we could talk for hours about how Ian layer is like the biggest thing since sliced bread in crypto um but Ellie I think that I just would like to say I really appreciate you coming on um learned quite a bit um was already Mega bullish on what you guys are building and and even more so now and um I would like to just keep learning and learning about just all these different options and man it's just it's just very exciting so thank you yeah thank you my closing thought here is like I can't wait to uh explain cross domain me to Larry because it seems like anyone

who's like running this Citadel level trafi operation is going to be so excited about cross domain me arbitr like essentially Arbitrage across all these rollups and like I I just see that as a path to to onboard like a new institutional wave and that's only possible through interoperability Solutions like shared sequencing yeah exactly exactly thanks thanks for coming on to the thank you