Introduction We introduced the motivation, design principles and high-level requirements of the Espresso Network in an earlier note. In this post, we will dive deeper into understanding the design of the two key components of the Espresso Network: the HotShot consensus protocol and EspressoDA, our custom data availability (DA) layer. We will cover this in three sections: Part I: Understanding the constraints of a sequencer network, and how it is different from a state machine replication (SMR) system Part II: HotShot Consensus Part III: EspressoDA for Data Availability (For a more technical explanation of this design, read our academic paper, though note that it refers to EspressoDA as Tiramisu DA.)

This post reflects an earlier version of Espresso's product. For the latest information on Espresso, please refer to our docs. Layer 2 rollups are delivering on their promise to scale Ethereum and make it useful for a wider range of users and applications, but currently rely on centralized sequencers. Espresso Systems is developing the Espresso Sequencer to support rollups in decentralizing, without compromising on scale. The Espresso Sequencer is designed to offer rollups a means of achieving credible neutrality, enhanced interoperability, mitigation of negative effects of MEV, and long-term economic incentive alignment with L1 validators. In November, we shared our work on the Espresso Sequencer: a platform to support rollups in decentralizing. Rollup projects across the ecosystem are solving the problem of scaling Ethereum every day. Where we come in is in helping them decentralize their sequencer component to deliver on credible neutrality, security, reliability, and interoperability without sacrificing performance.

Written by Ben Fisch, CEO and Co-Founder at Espresso Systems, published 8 March 2024 Many thanks to Justin Drake and Brendan Farmer for thoughtful discussions, helpful comments, and review of this article. TLDR: Espresso has proposed creating a marketplace for shared sequencing through which layer-2 chains sell blockspace to shared proposers, including the proposer for the Ethereum mainnet EVM itself, who create surplus value by satisfying user intents across multiple chains. Our mission has always been to bring renewed unity to Ethereum layer-2 chains. Over the last few years, rollups and validiums have enriched the greater Ethereum ecosystem with horizontal scalability and a diversity of execution environments, but at the expense of fragmentation—apps across rollups do not have the same shared liquidity and interoperability as apps on the Ethereum L1. The value of Ethereum is in its unity, not fragmentation—this is the promise of trust-minimized infrastructure and what differentiates Web3 from Web2. Ultimately, end users want secure, convenient, and low-cost means to pay one another, buy and sell NFTs, provide DeFi liquidity, swap assets, etc. Users will seek out the optimal way to satisfy their intents even if it means interacting across multiple rollups and the Ethereum L1 at once. Wallets will naturally support this, abstracting the details away from users. Satisfying user intents will be most efficient across applications deployed to rollups with the greatest unity, not only with each other, but also with smart contracts on the Ethereum L1.

Authors: Benedikt Bünz, Ben Fisch, Ellie Davidson We thank Justin Drake, Maryam Bahrani, Tim Roughgarden, Scott Kominers, Davide Crapis, Christoph Schlegl, Bruno Mazorra, Philipp Strack, and others for helpful discussions and feedback on our design. Thanks to Ed Felten for pointing out a mistake in the analysis section of a previous version. Espresso proposes a marketplace for sequencing. For high-level motivation and background, please read our previous post Based Espresso: ad-hoc shared sequencing. In this post, we present the detailed marketplace design along with justifications for our design decisions. Overview Espresso can provide the following separate but complimentary services: A marketplace that enables rollups to sell sequencing timeslots to sequencers (also known as proposers). A sequencer that successfully purchases a timeslot has the right to propose blocks for the rollup during that timeslot.[^1] A sequencer can simultaneously purchase sequencing rights for multiple rollups, becoming a shared sequencer for these rollups. A confirmation layer (aka finality gadget) that notarizes proposed blocks through a non-executing, proof-of-stake consensus. After the finality gadget has notarized a sequence of rollup blocks, they cannot be changed or reordered.

L2s have enriched the Ethereum ecosystem by horizontally scaling throughput, enabling new execution environments, lowering transaction costs, and reducing transaction latency. But L2s today act as isolated systems, instead of one unified layer on top of Ethereum’s L1. In particular, this has resulted in liquidity fragmentation across chains. It is Espresso’s mission to fix this fragmentation — to build a future where applications across all L2 chains can interoperate as if they were a part of one unified chain, without compromising the benefits of having many unique chains. This post examines how L2 fragmentation can be addressed through faster bridging of native assets, fast message passing, or to a greater extent, through making chains synchronously composable. Whether asynchronous or synchronous, bridging tokens between chains must be both direct (rather than through third-party liquidity providers) and provide the canonical (as opposed to bridge-wrapped) version of the token on the destination chain. L2 fragmentation can also be addressed by redesigning applications to act upon cross-chain messages alone, operating on tokens that live on other chains, and eliminating the need for cross-chain movement of assets entirely. We also offer an original protocol, CIRC, for both fast asynchronous and synchronous composability among L2 chains. The Problems with L2 Bridging Today and Liquidity Fragmentation For most assets (like ETH or DAI), moving them between Ethereum L2 chains today — without ending up with a wrapped asset on the destination chain — is both costly and takes a long time. It requires first withdrawing the asset from one chain onto the L1 and then depositing it into the second chain. This takes several days for optimistic rollups and several hours for ZK rollups. Even for future chains that promise to have fast ZK settlement proofs this will take at least 12-15 minutes due to the latency of Ethereum finality. Exceptions are special tokens like USDC, WBTC, or Ethena, which have centralized asset issuers. However these issuers do not work with all L2 chains. Bridging USDC over CCTP still takes 12-15 minutes as it waits for L1 finality. The friction of moving assets between L2 chains pushes each chain to replicate the services offered by every other chain, leading to liquidity fragmentation among other consequences. One such basic function that most chains need to offer their users is the ability to swap assets (i.e., provide decentralized exchanges like AMMs).

Author: gets Espresso satisfies some of the most desirable criteria for bridges, both from a security and speed perspective. HotShot, besides providing consensus for Espresso’s sequencing marketplace, also acts as a shared finality layer for rollups, finalizing L2 transactions within seconds. Rollups use HotShot to provide a strong pre-confirmation that their transactions will eventually be finalized on the layer-1. HotShot can support all of Ethereum’s consensus participants through restaking, granting it a high level of decentralization and economic security. This means that the safety guarantees are expensive to break, and it helps mitigate regulatory and cybersecurity risks through decentralization. A safety guarantee refers to the conditions under which a determined state of a blockchain will not be changed. Today’s L2 bridging experiences demand a tradeoff between speed and security, but with HotShot speed and security go hand in hand. Even in the event of a safety violation, the shared finality gadget can be used to roll back all participating chains in unison, providing protection against cross-chain double spends. In the case that only the source chain of a bridge transaction uses Espresso, it will still be possible to quickly bridge out, owing to strong safety guarantees. For example, Circle’s CCTP doesn’t trust the pre-confirmations provided by centralized sequencers. However, if a rollup utilized the HotShot finality gadget, they could enable fast, native USDC bridging from their L2 to other chains. Espresso therefore makes rollups not only more well connected with chains that share the same finality gadget, but also with the broader ecosystem. We showcased fast bridging between rollups in a recent demo with Across, with the bridge transaction settling in seconds! Exploring how bridges work In order to unpack why exactly Espresso improves bridging for L2s, we will now explore bridges in a bit more detail. Bridges are primarily used to transfer and swap tokens between blockchains. Imagine that Alice wants to bridge DAI tokens from chain A to chain B. There are two approaches commonly used by bridges to achieve this. One way is for bridges to lock and mint tokens. In this system, Alice will lock DAI on chain A, and once chain B has confirmed the lock, Chain B will mint (wrapped) DAI tokens to Alice.

HotShot is a consensus protocol designed and developed by Espresso Systems, which will be used for our sequencing solution. Tendermint[^1] is a well-known, established consensus protocol used by projects such as Cosmos, Polygon, and others. Does one of these protocols subsume the other? Do we need both of these protocols to exist? The HotShot protocol is purpose-built for sequencing among a large number of nodes, and it is optimized for this task. We argue that such a solution has benefits that Tendermint does not provide. At the same time, Tendermint is a battle-tested solution. It is a protocol that works among tens or hundreds of nodes and is designed to work as a full-fledged SMR solution, tackling issues like state changes, which HotShot intentionally chooses not to support. Therefore, our answer to the two questions above is no and yes, respectively — one system does not subsume the other, and yes, there is a need for both solutions.

In a previous post, we introduced the Espresso Sequencer: a decentralized, highly-performant shared sequencing platform that reduces the complexity in achieving atomicity, composability, and interoperability between rollups. The Espresso Sequencer is an external, opt-in protocol run by L1 validators. As part of our protocol, the Espresso Sequencer natively offers BFT preconfirmations to rollup users. BFT preconfirmations are backed by the security and liveness guarantees of a BFT consensus algorithm such as Espresso’s HotShot. In this post we will analyze another external, opt-in preconfirmation protocol: proposer-promised (“PP”) preconfirmations. Architecture of Proposer-Promised Preconfirmations Proposer-promised preconfirmations were initially introduced as “based preconfirmations.” Unlike BFT preconfirmations that require agreement among the entire validator set, PP preconfirmations only require approval from individual validators (namely, from “proposers” of the underlying sequencing protocol). The protocol description below reflects our understanding of the PP preconfirmation paradigm, fleshing out many details necessary to address in order to materialize the original proposal. The only assumption made about the underlying sequencing protocol is that it operates via a rotation of proposers. Validators opting to offer PP preconfirmations are known as preconfers. By opting in, preconfers agree to participate in an externally-managed protocol where they can be slashed if they do not honor their preconfirmation promises. Each rollup can customize the PP preconfirmation ordering and slashing conditions to meet their individual needs. Preconfers are ordered by their next proposer slot in the sequencing protocol and can offer a spectrum of preconfirmation types, ranging from strict promises of transaction execution against a particular state root to weaker promises of transaction inclusion only. Certain types of preconfirmations, such as execution promises against a specified state root or intent-based execution promises, can only be offered by the very next preconfer since only they have control over the latest rollup state. Other forms of preconfirmations, such as ordering-only or inclusion promises, can be offered by any preconfer. Some rollups may decide to only allow certain types of preconfirmations. Otherwise, it is up to preconfers to decide which types of preconfirmations to offer[^1]. Exchange between users and preconfers Obtaining a PP preconfirmation is performed in three steps:

Introduction In previous posts, we described how the Espresso Sequencer can be used both to decentralize rollups while retaining many of the UX benefits of centralized sequencers, and to improve interoperability between rollups, helping to defragment liquidity in a world with many different L2s. With the recent public launch of our Cortado testnet, we have taken another step towards realizing this vision, by running two different rollups from two different stacks (OP Stack and Polygon zkEVM) on the same decentralized sequencer. With these two different stack integrations under our belt, we will begin sharing more details about the architecture of a typical integration between a rollup and the Espresso Sequencer. This post will focus on a crucial and under-discussed part of the architecture: the derivation pipeline, which connects the rollup execution layer to the sequencer. We will define the derivation pipeline and share how rollups can easily deploy on the Espresso Sequencer and customize their own derivation pipeline. We will then describe how the derivation pipeline can be used to add rollup features on top of the features provided natively by the Espresso Sequencer, more easily than by modifying the rollup’s execution layer. As an example, we describe how rollups can support powerful cross-chain atomic transaction bundles by modifying their derivation pipelines and leveraging the Espresso Sequencer’s atomic inclusion features. The Derivation Pipeline Let’s compare the architecture of a rollup running on the Espresso Sequencer with the typical centralized-sequencer architecture of today’s rollups, which looks like this:

A staker, acting as a proposer, in a proof-of-stake system, can earn revenue through four avenues: (i) as a block reward for proposing a block at a given slot, (ii) as a reward for identifying and reporting past malicious actions by other stakers, (iii) through fees paid with the transactions (iv) through block building by adding, deleting, or reordering transactions (also known as gains through miner extractable value or MEV). Earning revenue through the first three avenues is fairly straightforward and something that every staker can easily do by observing the state of the network and following the protocol. The last avenue of block building, on the other hand, can be sophisticated, due to which not all stakers may be able to maximize their revenue in an optimal manner. Having non-uniform revenue amongst different stakers is a risk, as it can lead to centralization. The approach of Proposer-Builder Separation (PBS) separates the task of block building from block proposing by creating a market of builders, each of which can perform the role of block building by optimizing for MEV. The proposer then proposes the block content of the builder that (generates and) bids the highest value. This process is touted to reduce the barrier to entry for stakers by obviating the need for a staker to own sophisticated infrastructure and still earn revenue closer to what it would if it did have the infrastructure (minus a small profit that the winning builder keeps for herself). The collected revenue through this bid can also perhaps be redistributed differently, e.g., paying the set of all stakers by burning the bid value, or somehow paying back the users. The PBS Fair Exchange Problem Separating the task of building and proposing so that it is performed by two different stakers brings inherent challenges that relate to the trust between the two. In particular, a key challenge relates to a fair exchange between the builder and proposer where deciding the builder block, as is, at the proposer’s slot is exchanged for fees bid by the builder and the builder’s block content[^1]. The fair-exchange problem has been studied extensively in the cryptography literature. It is known that even a mere fair-exchange of cryptographic strings among mistrusting parties cannot be solved deterministically[^2]. Therefore, below we will explore mechanisms for incentivizing participants to behave fairly in the PBS fair-exchange. To understand the concern better, observe that any party that makes the first move may be at a disadvantage. Builder’s concern: leaking block content and losing fee

As Ethereum has grown, its scalability worries have gone from theoretical to practical. Especially during periods of high network activity, many users have been priced out of sending transactions over the Ethereum blockchain. A solution to this problem is moving the execution of transactions off-chain through rollups. At a high level, rollups outsource a L1 blockchain’s computation to a single party, which in turn is tasked to prove to the L1 blockchain that the computation was performed correctly. There are at present two main methods by which this proof is performed. In optimistic rollups it is done through fault/fraud proofs, and in zk-rollups through validity proofs. The popularity of rollups as a scaling solution can’t be understated, with a proliferation of rollups being developed, ranging from ZK to optimistic rollups and EVM to app-specific VMs. This trend is likely to continue, supported by a host of new rollup-as-a-service startups, and Ethereum rolling out its rollup-centric roadmap. While rollups are an excellent solution for inheriting some form of economic security at scale, they introduce two key new problems: By relying on a single party for transaction ordering and inclusion in a rollup, they are prone to monopoly pricing and censorship. The proliferation of multiple rollup solutions breaks composability within the Ethereum ecosystem. Liquidity will fragment between rollups, and assets and other data will have a hard time moving across domains. Decentralizing the sequencer, which is the component of a rollup in charge of transaction ordering and inclusion, may help with (1), but does little to solve (2) on its own. The Espresso Sequencer, which is not only decentralized, but also shared between rollups, addresses both problems. In this post we focus on the benefits of shared sequencing and how it defragments the L2 ecosystem.