Notes and insights from the following blog posts:

The Espresso Sequencer - HackMD

Analyzing BFT & Proposer-Promised Preconfirmations - HackMD

The Derivation Pipeline - HackMD

• General Architectural considerations

  • In sovereign rollups nodes directly execute transactions based on the ordered list defined by the sequencer. They compute a state change and provide proofs, which are then verified by light clients. Unlike traditional rollups, sovereign rollups do not rely on a contract on the L1 to define the virtual machine .

  • This process works in a similar way for optimistic rollups, regardless of whether they use a smart contract to record a proposed state change and adjudicate fraud proofs, or if they are "sovereign" and require fraud proofs to be shared among all light clients.

  • The objective is to replace the centralized sequencer with a decentralized consensus protocol that, at least under best-case conditions, provides higher throughput and faster confirmation of transaction inclusion than Ethereum natively does on its own.

  • Separating out execution from ordering and availability can have immense benefits for throughput if integrated with an appropriately-designed consensus protocol.

  • Espresso is A decentralized sequencing network for rollups that is designed to provide secure, high throughput, low latency transaction ordering and availability.

  • Not only allow rollups to decentralize, but will also introduce to rollups the interoperability advantages of a shared sequencing layer (ie atomic execution).

  • Mitigating “superlinearity” of cross-domain staking and centralization: if nodes control a p fraction of stake in two different domains (rollups) then the probability they are elected to both simultaneously in a given slot is p^2, and thus their return on staking is superlinear.

  • The ideal non-native sequencing layer should complement the trade-offs inherent to Ethereum’s consensus, which prioritizes liveness under pessimistic conditions rather than responsiveness under optimistic conditions.

  • Fast finality, or optimistic responsiveness, is the ability of the protocol to confirm transactions as fast as the network will allow (like Carnot).

  • Security in the presence of bribery

    • Bribery attacks can thus be used to indefinitely stall liveness, even when leader selection is unpredictable.
    • The standard requirement to disseminate all transaction data among every node participating in consensus before a decision can be reached presents a fundamental bottleneck in the throughput of sequencing (i.e., consensus) protocols. Some designs therefore make a performance/security tradeoff by outsourcing data availability to a smaller set of trusted nodes. This set of nodes, called a DA committee, may also be randomly sampled from the larger staking set and rotated every epoch or even every block. The committees can continue to propagate data so that all nodes eventually catch up, but off the critical path of consensus progress.
    • An alternative solution is VID, which verifiably distributes erasure code shares of the data among all nodes participating in consensus such that any subset of nodes owning a sufficiently high fraction of the stake would be able to cooperatively recover the data.
    • Committee-based DA solutions are not an acceptable performance/security tradeoff. The small committee initially responsible for availability of data at the moment a block is finalized can be bribed at relatively low cost. On the other hand, relying on VID solely for DA is far from pragmatic. Espressos’ approach thus composes these two methods to achieve security and pragmatism. VID is used to provide a backup path.

  • Engaging the entire Ethereum validator set: If none (or relatively little) of the value generated by a rollup is shared with the L1 validators, then this risks destabilizing the security of the rollup.

  • HotShot: A consensus protocol that decentralizes participation in the sequencer network, offers high throughput and fast finality in optimistic conditions (responsiveness), while maintaining safety and liveness guarantees under pessimistic assumptions. Our consensus protocol is called HotShot and is based on the HotStuff protocol. While the original HotStuff protocol was described for only a fixed set of validators, HotShot is open and permissionless. Differences include a new Pacemaker (view-synchronization method), a VDF-based random beacon for leader rotation, a dynamic stake table, and distributed signature aggregation. The design of each of these HotShot components are constrained by the goals of maintaining strong adaptive/bribery-resistant security (e.g., ruling out committee-based approaches), while still scaling to support a massively larger operator set than what the HotStuff protocol was originally intended to run on.

  • Protocol diagram:

    

• Reducing confirmation latency: BFT and Proposer-Promised Preconfirmations

  • BFT preconfirmations are backed by the security and liveness guarantees of a BFT consensus algorithm.
  • Unlike BFT preconfirmations that require agreement among the entire validator set, PP preconfirmations only require approval from individual validators.
  • 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.
  • This system 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.
  • It is likely that just as PBS emerged in Ethereum, a similar preconfer builder separation will emerge.
  • Although users may potentially receive fast preconfirmations, they can experience increased delay on transaction execution. As mentioned above, preconfers are proposers of the sequencing protocol on average every blocks, meaning most transactions, preconfirmed or otherwise, will have to wait blocks for execution.
  • Both BFT rollup-sequencing and PP rollup-sequencing run external protocols that L1 validators can opt into, and both require an integration from rollups. However, they operate differently and provide rollups and users different tradeoffs.
    • So long as the single preconfer is honest, a user’s preconfirmation will be honored.
    • BFT sequencing, through which BFT preconfirmations are natively offered, leads to faster rollup pipelines. While the promises obtained through PP preconfirmations may potentially be faster than BFT preconfirmations (assuming the concerns we raised in our analysis are resolved), rollups using BFT sequencing may begin their derivation pipeline immediately after receiving the committed output of the consensus protocol. Rollups using PP preconfirmations, on the other hand, must wait until the preconfer’s block is both proposed (which may take several blocks) and made final on the sequencing protocol before starting the derivation pipeline. This can introduce a non-negligible delay in the rollup production flow, especially since not all validators opt-in as preconfers.
    • BFT preconfirmations and PP preconfirmations are entirely composable.

• The Derivation Pipeline

  • The sequencer generally cannot affect the correctness of the rollup state, since the computation of the state is verified by the L1. However, in practice, many users trust the sequencer with an additional responsibility: finality. However, the transaction is not really final until it has been received by the L1. This means the sequencer can lie about a transaction being finalized.
  • This both decentralizes the rollup and removes the ability of any coalition of nodes controlling less than ⅓ of the Espresso Sequencer staking power to equivocate on the rollup’s transaction ordering.
  • We need the rollup itself to enforce the constraint that the sequence of blocks it is executing is determined by the output of the consensus algorithm which ultimately means that the L1 will need to check this constraint.
  • Consensus Verification
    • The first thing the derivation pipeline must do is prove that the blocks in its input are the sequential outputs of the Espresso Sequencer. Luckily, the HotShot consensus protocol underlying the Espresso Sequencer produces verifiable artifacts proving the finality of each block it outputs. These artifacts are called quorum certificates, or QCs.
    • The most direct way of proving that a block is the next output of the sequencer is to incorporate a proof of correct signature for the appropriate QC into the proof of correct derivation that is sent to the L1. There is, however, an easier way: the Espresso Sequencer will include, as a public good, an L1 smart contract whose sole job is to verify QCs and provide a certified commitment to the Espresso block stream in L1 storage. The rollup’s L1 contract can read directly from this certified commitment.
  • Namespace Filtering
    • The next job of the derivation pipeline is to convert the Espresso block stream, which includes transactions from all the rollups using the Espresso Sequencer, into a rollup-specific block stream, which includes only transactions for this particular rollup, so the rollup can easily download just those transactions that belong to it.
  • Rollup-Specific Transformations
    • The derivation pipeline thus allows every individual rollup to identify and verify its unique blockstream among the entirety of data being processed by the Espresso Sequencer. Because the derivation pipeline is logically separated from the execution pipeline and other aspects of the rollups internal functioning, they can choose to interpret the Espresso blockstream however they want.

• Atomic Operations

  • While the derivation pipeline is used to split up the Espresso Sequencer’s blockstream into smaller blockstreams unique to each individual rollup, the sequencer is still including transactions from multiple rollups in the same block.
  • We can leverage the pipeline to provide atomicity for transactions originating from multiple rollups. An atomic cross-chain bundle is a set of transactions that is only valid when included on all rollups in the same block but not if it is split up.
  • The idea is that bundled transactions add an ephemeral bundle public key to the individual transactions themselves. This bundle public key is signed as part of the normal transaction signing. We do this by appending the public key to the call data of the transaction such that it doesn’t change the meaning of the transaction.
  • The bundle protocol:
    • Each bundle transaction adds the following string to the call data of the transaction
    • A sequencer block includes the bundle of transactions, the list of rollups for this bundle, and a signature under BUNDLE_PK on the hash of those fields
    • The block header contains a namespace table, which points to this bundle for each namespace involved in the bundle.
  • The derivation pipeline is changed as follows: For each transaction (or bundle) within the rollups namespace the rollup’s pipeline checks that
    • For a normal transaction there is no magic string in the calldata
    • There exists a signature under BUNDLE_PK on the hash of the transaction bundle, including all the namespaces
    • The pipeline checks that all the bundle transactions are included in all rollups.