Sequencer Marketplace

Espresso allows applications to sell their sequencing rights through an open marketplace. The marketplace is run via a combinatorial lottery (a randomized analogue of a combinatorial auction). Lottery participants buy lottery tickets for (a combination of) L2s, and become the (shared) sequencer for chains they hold the winning ticket from in any given lottery round. These sequencers can help coordinate cross-chain atomicity and provide fast pre-confirmations for end users, increasing overall utility. L2s can choose to set a reserve price for their blockspace, which if not met allows the L2 to designate their own sequencer for that given round of the lottery. For example, this could be a default centralized sequencer, or a sequencer elected via an L2's own proof-of-stake protocol.

The L1 proposer on Ethereum has a right of first refusal (ROFR) for sequencing rights sold via the marketplace. This means that the Ethereum L1 proposer can choose to purchase L2 blockspace at the price set via the lottery. This grants L2s participating in Espresso the opportunity to function as based Ethereum L2s, which in turn enables improved composability with Ethereum.

For more details on the marketplace and based sequencing design, see: Based Espresso: ad-hoc shared sequencing for all L2s, from based rollups to validiums.

Simple sequencing marketplace

In upcoming versions of Espresso, a simple version of the L2 sequencing marketplace will be implemented through a combinatorial auction. The details of the auction run in the initial marketplace are as follows: There are 3 phases of the auction for some slot s: bidding phase, assignment phase, and sequencing phase. Each phase is denominated in a fixed number of views. Each phase overlaps with another phase for another slot. For example, while the bidding phase is taking place for slot s, the sequencing phase may be taking place for slot s - 5.

Each phase has differences, but the phases are mostly common among them. Namely, each phase consists of some party submitting special transactions to the network. These transactions, unlike normal data that is sequenced through HotShot, are sent to all nodes in the network instead of going through Tiramisu. These special transactions (bid_tx, auction_result_tx, etc.) are validated and maintained by all nodes. HotShot is unaware of these transaction types.

Bidding Phase

During this phase potential shared sequencers bid on bundles of rollups using bid_txs. Unlike normal data ordered through HotShot, bid_txs are sent as part of the QuorumProposal. All nodes in the network receive bid_txs. An auction solver service listens for finalized bid_txs. During this phase rollups may also submit update_reserve_price_txs to the L1. Such transactions must be signed by a designated rollup address. (Note: since the L1 is not in sync with HotShot, rollups should submit these transactions early to ensure HotShot sees them)

Assignment Phase

During this phase an auction solver produces a possible solution that assigns shared sequencers. The solution must respect reserve prices and only assign one sequencer per rollup. The auction solver does not guarantee it will find the most optimal solution. Once the solver has calcuated a solution it submits it to HotShot through an auction_result_tx. Like bid_txs, auction_result_txs are sent as part of the QuorumPropsoal to all nodes.

Sequencing Phase

During this phase the winning shared sequencers build their bundle payloads. The HotShot leader requests the auction winners from its sequencer module, and using this data requests the bundle payload from each shared sequencer. Shared sequencers have a small time window t to return their bundle payload so that it is included in the HotShot leader’s block. Along with the bundle payload, the HotShot leader also proposes bid_refund_txs. These transaction refund losing bidders from the bidding phase.