Composability Begins With a Fast Confirmation Layer | Ben Fisch - Espresso

[Music] all right is this on perfect okay great um I'll be talking about composability begins with a fast confirmation layer so this is a talk about composability of web 3 applications and uh sometimes when I get on stage and I give talks I wish I had one of those clickers from uh from like Men In Black where I erase your memory because there's so much noise about composability about interoperability and so I want you to forget everything that you know about interoperability and let's just go back to the basics for web 3 applications to compose they need to communicate and low latency is key to enable real-time interactions this equally applies to web 3 and web 2 interoperability so for example when coinbase receives a deposit of eth coinbase needs a message from ethereum indicating that and E transfer completed and a way to confirm the finality of this message right to avoid reversion and potential loss of funds speed matters but so does integrity communication must be both fast and reliable now of course the reliability of a message can can come from a variety of different sources or different assumptions and so a key question is always what constitutes a reasonable trust assumption when one application is verifying a message from another and this may be different or the minimum required assumption may be different when those two applications reside for example on the same chain uh versus different chains or whether they are on the same but they are on different El twos but on the same L1 Etc and we'll get into that how do you achieve trust minimization so the key advantage of intrachain messaging meaning messaging between applications that reside on the same chain is number one that you can achieve zero latency zero relative latency apps on the same chain or in other words virtual machine communicate via function calls between smart contracts an example would be an account on ethereum depositing eth into Unis swap which then triggers an action in usdc application which triggers a transfer of usdc to the account so single transactions trigger multiple app changes that all finalize at the same time which is why they have this messaging has zero relative latency the other aspect is that in chain messaging does not require any new trust assumptions beyond the assumptions that applications already make on those chains or more precisely that the users of those applications already make for the applications running on that chain specifically the safety of the chain the Integrity in fact of the messaging between applications is ensured by VM logic so even if the consensus fails even if there's a reorg the atomicity of messaging between the chains would still be preserved there would be a perfectly intact version of message history on either Fork so the only problem is when the app the social app behind Unis swap that users actually follow and the social app behind usdc that users actually follow where to to choose different canonical Forks in the event of a of a deep Fork uh say like ethereum like when ethereum turned into ethereum classic in ethereum right if that happened and Unis Swap and usdc chose different Forks that would be a problem but that is the only thing that can really break the Integrity of interchain messaging no new trust assumptions now the challenge of interchain messaging comes from a variety of different places first and foremost communication between apps on different chains like AC cross l1's requires each app to rely on some kind of new trust assumption example an app on ethereum reading a message from an app on salana must trust Solana's finality that is an additional assumption beyond the assumptions that application makes just by running on ethereum another example I look at exchanges as examples of chains they're just centralized chains right and so when an exchange like coinbase accepts a deposit from uh ethereum that is an example of a cross-chain messaging between ethereum and the coinbase uh system coinbase's system can't simply reorg its own state if an e deposit reverts due to a deep ethereum reorg for example a user may have already traded for US Dollars and cashed out using the Legacy Financial system so this is the key challenge of interchain messaging the introduction of some kind of new trust assumption what about inter rollup messaging L2 to L2 well it is actually possible for rollups to communicate through the shared L1 for example each rollup could have an outbox and an inbox the sequencer of that rollup can fill the inbox with new messages from the outbox of the other rollup once those messages have been reflected in a finalized state of that rollup on the L1 so this inbox on rollup a would verify some kind of Merkel proof against the Merkel root of roll up B finalized on the L1 this is totally possible it doesn't introduce new trust assumptions it is similar to apps on the same chain communicating however even though apps across l2s on a shared L1 can communicate via the L1 without new trust assumptions this has high latency for several reasons first of all infrequent checkpointing to the L1 rollups do not post to the L1 all the time they post infrequently to save on data publication costs or in the case of ZK rollups to amortise the cost of ZK proofs furthermore long settlement time s for optimistic rollups if optimistic rollups are settling up uh you know via fraud proof games then there could be a a long fraud prooof challenge window before the L1 actually reflects the finalized Merkel route of the L1 now this could be solved by fast offchain ZK proofs for all rollup Stacks which is possible today using ZK VMS like sp1 Risk zero jolt that can compile any rollup stack so going back to the previous slide when inbox a verifies a message it doesn't need to just read it from the L1 it can verify against some published data to the L1 that is finalized the L1 doesn't have to have verified the execution of roll up B it suffices for the inbox a to receive and verify ZK proof that was computed offchain and delivered directly to inbox a this is completely possible but it will still have a relatively High latency because of the long finalization time on chains like ethereum so it takes up to 15 minutes to even finalize just data that has been published even if you had a a uh a real-time proof right that was verified by by the L1 the role of State isn't final until after 15 minutes because that's how long it takes ethereum to finalize ethereum is a slow consensus protocol now l2s have a superpower fast soft finality this is something very unique to L2 applications that is not exhibited by L1 applications and this is due to the fact that only the sequencer is authorized to add new L2 transactions the rollup sequencer collects transactions and periodically posts transaction batches to the layer one with a claimed State update for validity rollups the L1 would verify a validity proof or optimistic rollups it would would enter a fraud proof challenge window uh those details don't matter but the point is that um the L2 transactions also only depend on finalized ethereum State and while users can force include L2 transactions VI the L1 they can only do so if the sequencer censors them for too long so the sequencer the L2 sequencer immediately knows that an L2 message is final assuming the L1 is safe I.E something like and if on something like ethereum that ethereum never experiences deep reorgs that break final ethereum blocks as a result wallets applications on other chains exchanges Etc they can trust L2 sequencer confirmations of an L2 message if they trust both that the sequencer is honest and won't get hacked and that the L1 is safe that final L1 blocks never reor this is a superpower that is not possible for applications that run directly on the L1 there is no equivalent party to the sequencer that a wallet Apper another chain exchange Etc May trust for a fast confirmation they have to wait the 15 minutes for the ethereum L1 confirmation so now obviously this introduces a new trust assumption but if you trust the sequencer you can get a fast confirmation an example that I want to make sure is clear is not a real example usdc cross-chain transfer protocol does not trust sequencers today but if they did they could enable one less than 1 second bridging of usdc between different l2s the way that cctp works is that you can have a usdc contract on one chain receive an instruction from a usdc contract on a different chain that had burned a certain amount of usdc and that is an instruction to Mint the equivalent amount of usdc on the destination chain if these messages just simply come from trusted sequencers then within the span of a few seconds you could Bridge from usdc from optimism to arbitrum to polygon and back Etc but sequencers can get hacked a trusted sequencer can still get hacked temporary hacks of any sequencer in the example I gave can cause extreme damage to usdc the hacker would be able to freely mint usdc on any of these chains even if just one of the three sequencers gets hacked devastating hacks of centralized servers happen all the time in crypto the Ronin Bridge a $625 million loss Harmony Horizon poly Network wintermute bitmart most recently bybit of $1.5 billion loss these are not sequencers but it doesn't matter the concept is the same all of these cases resulted from some form of compromising signing keys for a relatively small set of servers enabling the attackers to maliciously authorize something hacks occur when there is money to be made and centralized el2 sequencers are really no different the risk for cross-chain apps moreover compounds when trusting centralized confirmations let's assume that each sequencer has a small independent chance of getting hacked independent chance P of getting hacked in our hypothetical running cross chain transfer protocol example the chance of usdc failure grows like n * p with n connected chains so the risk of usdc getting compromised is now 100x higher if there are 100 chains in a cluster that are communicating because a single compromise of a single sequencer would allow for free minting of usdc on any of these chains now contrast this to consensus protocols if you use a consensus to protect sequencer reorgs and I'll demonstrate in this diagram how this can be done by even and introducing a separate consensus protocol that is faster than the layer one a so-called layer 1.5 this is how it works so the sequencer before it posts to the L1 to the layer one it streams its transaction batches to this separate consensus protocol an example of this that runs in production today is the espresso Network which can scale to thousands of validators like ethereum the sequencer streams his transaction batches and waits for a certificate from this consensus protocol before posting its batches to the layer one note the sequencer can still issue soft confirmations nothing has changed with regards to soft confirmations the key difference though is that when the layer one Bridge contract receives a state and receives a stream uh um a batch a new batch of trans actions for the L2 they check it checks not only that the sequencer has signed this batch but that the sequencer has a certificate that this separate consensus protocol also signed off on this batch what this prevents is that even if the sequencer gets hacked the sequencer cannot post something else later to the L1 that is inconsistent with the batch of transactions that it streamed to the L1 so unlike soft confirmation which can be violated when the sequencer gets hacked confirmations that come from transaction batches posted to this separate layer 1.5 cannot be compromised unless the layer 1.

5 is compromised in our example the usdc bridge cctp could compute a message from transactions finalized on the layer 1.5 and have the protection of this consensus protocol instead of trusting individual sequencers wallets apps and other ch exchanges Etc could confirm an L2 message against the Merkel rout of the L 1.5 similarly to the L2 superpower of sequencers if they run a full node for the L2 to compute the message from transactions finalized by the L 1.5 or they receive a proof they trust like a zero knowledge proof or even a trusted execution environment attestation verified against the miracle route if they trust that the L 1.5 is safe meaning final L 1.

5 blocks never reorg and if they trust that the L1 is safe final L1 blocks never reorg it is a new trust assumption still above the just trusting the L1 is safe but it is a much much weaker assumption than trusting centralized sequencers and moreover the risk when many rollups share this does not compound so when you have when you're trusting clusters of sequencers cross to apps like we described you know um they can be compromised if any sequencer is hacked so the risk grows linearly with the cluster size with trusting a shared consensus layer like the L1 or the L1 plus espresso Network breaking the finality of any message from any chain requires compromising 33% of the validator running consensus independent of the number of l2s that are using that consensus the network is a live confirmation layer that can be leveraged by l2s it's been live on mainnet since November it runs the Hot Shot consensus protocol today on 100 distributed nodes but transitioning to proof of stake in June 20125 which will turn this into a permissionless network that can theoretically scale to the size of ethereum I'll end with a a joke trailer for my upcoming movie because I advertised that this would be the first screening of this on on Twitter so for those of you coming here I don't want you to think that I rugged you only lay then came the layer twos in Dres worn out of oops try one more time in the beginning there were only layer ones then came the layer twos Ines BN out of a pressing need to scale the layer two Wars left the universe fragmented disconnected and then in the 25th year of the thir Millennium in the 21st century approximately 4.54 billion years after the Earth's form a new era began with the arrival of theer 1. this marked a significant turning point in human history to so you can now generate trailers in under an hour using AI which is pretty cool thank you and uh that's my talk