MIP-34: Fast Finality Settlement

Description: Establish the scope and components that are part of the Fast Finality Settlement mechanism.
Authors: Franck Cassez, Andreas Penzkofer

Abstract

Fast Finality Settlement (FFS) is a mechanism that allows for fast confirmation of transactions backed by crypto-economic security. Moreover it capitalizes on the economic security from the L1. This MIP outlines the high-level specifications and architecture of FFS.

FFS is divided into

Postconfirmation: a mechanism to confirm the validity of a block on L1
Fastconfirmation: a mechanism to confirm the validity of a block on L2

Definitions

We make a note for the following terms:

Batch (not recommended) Less clean, but more common term for sequencer batch. May be mixed up with the batch of transactions sent to the sequencer, or with the batch of L2Blocks (superBlocks) that should be processed for postconfirmations. Use with care.

Attester (not recommended) The term attester has been deprecated in favor of validator.

Quorum certificate (not recommended) The term quorum certificate has been deprecated in favor of fastconfirmation certificate.

Motivation

Two chains are present in our architecture: a base chain (or L1) and a second chain (or L2). We refer to L2 as a chain that is not the base chain.Rollups and other types of chains may publish or secure transaction data in a data availability (DA) layer or at Ethereum mainnet (L1).

Validity and optimistic rollups can finalize transactions within approximately 30 minutes and ~1 week, respectively. Until a transaction is finalized, there is no assurance about its validity and result (success or failure). This can be a limiting factor for certain types of DeFi applications.

Our objective is to enable transaction issuers to quickly get some guarantees that their transactions are correctly and successfully included in a block. The crypto-economic security is provided by a Proof-of-Stake (PoS) protocol. This mechanism can be deployed independently for a chain, or used in combination with existing settlement mechanisms, such as ZK and optimistic settlements.

As a result, users can rely and trust the fastconfirmation (sometimes also described as L2-finality) to use as confirmation, or if the chain is configured to do so, wait for L1-finality, such as through postconfirmation, end of challenge window for fraud proofs (optimistic rollup), or verification of a ZK-proof (validity rollup).

A introduction to FFS can be found in this blog post on Fast Finality Settlement. A more detailed description of a (partial) implementation of the mechanism is available at this blog post on postconfirmations.

This MIP provides an overview of an architecture of FFS, and its main components.

Specification

Overview

FFS. The objective of Fast Finality Settlement (FFS) is to confirm that transactions are processed correctly and that the node has read the transactions in the correct order. It does not impact the already established order of transactions by the sequencer.

At an abstract level, the L2 chain increases by a new block in each (L2) round, and this block is the successor of the block in the previous round, the predecessor. Initially, there is a genesis block with no predecessor.

ProtoBlock. Each round corresponds to the processing of a batch of transactions, called protoBlock, which is proposed by the sequencer (can be centralized, decentralized, shared).

L2Block. A node with execution capability is in charge of validating the transactions in a protoBlock and calculates the new state. This results in a block with state commitments, and we call this block L2Block. For the vast majority of cases when we refer to blocks we mean L2Blocks, thus we will omit the “L2-” prefix. Since protoBlocks are provided by the sequencer, the new state and the state roots for a block are deterministic. For a protoBlock $b$ the state is $S_{b}$ and the state root is $H (S_{b})$ . From the protoBlock $b$ and the state $S_{b}$ the block $B$ is computed (which contains the information of the protoBlock and the state root).

SuperBlock. L2Blocks can be constructed and confirmed on L2 at a higher rate than is feasible for L1. We group L2Blocks into a superBlock that is confirmed together.

Local validation. Since a block is deterministically calculated we say that a block (and the associated new state) is validated locally once the execution engine calculates it from the protoBlock.

The validity judgement to be made is:

[!NOTE] Given a block $B$ (predecessor), a protoBlock of transactions $t x s$ and a successor block $B^{'}$ , is $B^{'}$ the^[the MoveVM is deterministic and there can be only valid successor.] correct successor of $B$ after executing the sequence of transactions $t x s$ ?

The term correct means that the successor block $B^{'}$ (and the state it represents) has been computed in accordance with the semantics of the MoveVM, which we denote $B t x s B^{'}$ .

Validator. A node that is responsible for validating transactions and confirming L2Blocks. To guarantee the validity of a new block $B^{'}$ , we use a set of validators who are in charge of verifying the transition $B t x s B^{'}$ .

Attestation. A validator attests for a new block $B^{'}$ . This can be done, for example, by casting a vote :white_check_mark: (true) or :x: (false) for a proposal by a leader validator. Or by each validator sending the hash of the block they have validated.

Fastconfirmation certificate. When enough validators have attested for a new block $B^{'}$ , the block is L2-confirmed (sometimes referred to as L2-final). The accumulation of enough votes is aggregated in a fastconfirmation certificate. A naive implementation of the fastconfirmation certificate is a list of votes.

[!NOTE] Until a better definition arises we consider confirmation to be defined as L2-finality (i.e. fastconfirmation).

Fastconfirmation. FFS aims to confirm the validity of each produced L2Block, at every L2Block height.

[!IMPORTANT] If we confirm each successor block before adding it to the (confirmed) part of the ledger, there cannot be any fork, except if the sequencer would provide equivocating protoBlocks for a given height AND there is a sufficiently strong Byzantine attack on the confirmation process.

If the validators can attest blocks quickly and make their attestations available to third-parties, we have a fast confirmation mechanism supported by crypto-economic security, the level of which depends on what is at stake for the confirmation of a block.

Postconfirmation. At certain intervals confirmation will also be achieved on L1. The L1 contract will verify the satisfaction of the super-majority criteria. This provides an L1-protected postconfirmation that the block (or a batch of blocks, which we call block range) is confirmed. This additional anchoring mechanism increases the security of the fastconfirmation as it locks in the fastconfirmation, reduces the risk of long range attacks and provides a way to slash validators that have attested for invalid blocks.

Slashing. The security of the mechanism relies on a PoS protocol. Each validator has to stake some assets, and if they are malicious they should be slashed. The condition for slashing may be met by several criteria, and not all slashing conditions may be used:

equivocate (send a different vote to different validators or users)
vote for an invalid block
(if possible) vote against a valid block

Main challenges

Components

Staking for postconfirmations (addresses 1.)

For postconfirmation a staking mechanism is implemented in a contract on L1. This contract provides the following functionalities:

join: a new validator can join the set of validators by staking some assets
exit: a validator exits and get their stakes back

Handle postconfirmations (addresses 2.)

For postconfirmation, the following steps are implemented in a contract on L1:

vote: receive a vote or a set of votes, verify the integrity of the votes (signatures) and the minimum threshold (e.g. 2/3)
confirm: once the threshold is reached, confirm the block (or sequence of blocks) on L1

Staking for fastconfirmations (addresses 3.)

For fastconfirmation a staking mechanism is implemented in a contract on L2.

This contract provides the following functionalities:

join: a new validator can join the set of validators by staking some assets
exit: a validator exits and get their stakes back

Handle fastconfirmation (addresses 4.)

For fastconfirmation, the following steps are implemented in a contract on L2:

vote: receive a vote or a set of votes, verify the integrity of the votes (signatures) and the minimum threshold (e.g. 2/3)
confirm: once the threshold is reached, confirm the block (or sequence of blocks) on L2

Communication of fastconfirmation status (addresses 5.)

This step synchronizes the fastconfirmation with the postconfirmation. The postconfirmation is the final confirmation of the block on L1, and the fastconfirmation is the fast confirmation of the block on L2.

To ensure that the fastconfirmation status is made available to third-parties, we may publish our proof (2/3 of attestations) to a data availability layer and get a certificate that the proof is available.
This DA layer should offer a reliable mempool for example as described in this paper.

Implementation Details

To simplify we assume that each validator stakes the same amount. The set of validators is in charge of validating sequenced batches and producing blocks that also commit to the state root of the sequenced batch.

There may be different protocols for the postconfirmation and the fastconfirmation.

Postconfirmation with deterministic blocks

L2Blocks are deterministically derived from the protoBlock, and consequently the superBlock $B_{r}^{'}$ is deterministic. Validators then attest for the next transition directly: $B_{r} t x s B_{r}^{'}$ . E.g. by committing to the the hash of $B_{r}^{'}$ .

An additional actor - the acceptor - is introduced that initiates the postconfirmation process. This is necessary, as this step requires additional gas costs on L1 and thus this role requires additional rewards. We also don’t want to burden regular validators with additional gas costs, as we would like the gas costs for validators to be predictable. The acceptor serves for a specified period and is then replaced by another validator.

[!NOTE] Since the block derivation is deterministic, $f + 1$ may be sufficient to confirm the block. (However, we require $2 f + 1$ to cover potential edge cases, such as that the sequencer cannot be trusted.)

Direct L1 commitments. In the scenario where validators commit individually they send the block hashes of the calculated blocks directly to the L1 contract.

Acceptor collects commitments. In a more optimized scenario, the acceptor could also send the super-majority proof to the L1 contract.

Diagram 2 Figure 2: Postconfirmation: Leader-independent (deterministic) L2Block generation process.

Fastconfirmation with deterministic blocks

A p2p layer is established between validators. Validators communicate to aggregate a threshold of votes on each deterministically determined L2Block. This provides fastconfirmations in the order of seconds.

Since this approach already collects commitments off-L1, an acceptor could collect commitments and send the super-majority proof to the L1 contract. This would provide postconfirmations in the order of minutes.

Diagram 3 Figure 3: Postconfirmation + fastconfirmation: Leader-independent (deterministic) L2Block generation process. Validators co-operate to create a fastconfirmation certificate before L1 is involved.

Alternative Version (not implemented): Postconfirmation with leader-dependent blocks

A leader validator is elected for a certain interval. The leader proposes the next transition (superBlock $B_{r}^{'}$ ): $B_{r} t x s B_{r}^{'}$ . The leader can do so by sending a digest of $t x s$ (Merkle root) and a digest of $B_{r}^{'}$ (Merkle root hash of $B_{r}^{'}$ ), or a change set. The leader commits on L1 to $B_{r}^{'}$ . Every validator checks the validity of $B_{r}^{'}$ and prepares a vote message.

Direct L1 commitments. The vote messages of each validator are directly sent to the L1 contract. Once enough votes are available on L1, the leader initiates the postconfirmation process.

Leader collects votes. The vote messages of each validator are directly sent to the L1 contract. Once the votes reach the required threshold for $B_{r}^{'}$ , the leader initiates the postconfirmation process with the proof of the votes.

Version A Diagram Figure 1: Postconfirmation: Leader-dependent L2Block generation process.

Verification

Correctness and Security

A more detailed discussion on the correctness and security is discussed in this blog post on FFS.

The level of security depends on the total stake of the L2 validators. The higher the more secure.

The correctness of the mechanism relies on a few trust assumptions.

Byzantine assumption. We assume that at most $f$ of the total $n = 3 f + 1$ (L2) validators can be malicious. This implies that if more than $2 f + 1$ attest for a new block, at least $f + 1$ honest validators have attested, so at least one honest validator has attested to $B^{'}$ . Thus, we request that > $\frac{2}{3} n$ (super-majority) validators have attest for $B^{'}$ .

Postconfirmations. We assume that the contract that validates the proof of super-majority is correct (there are no bugs in the implementation of the contract). As a result, when the contract verification step is confirmed on L1 (L1-finality), the super-majority proof verification is L1-secure.

Combining the two results above we have: confirmation (L1 contract) that >2/3 of validators have attested to a certain superBlock and if >2/3 have attested then $B^{'}$ is valid. So overall, if the >2/3 super-majority is verified by the L1 contract, $B^{'}$ is valid.

Fastconfirmation. The same applies as for Postconfirmations.

In addition the L2 validators also publish the proofs to a DA layer and once the proof is available it cannot be tampered with. Thus, we can provide some guarantees about the irreversibility of transactions when the availability certificate (of the fastconfirmation certificate) is delivered, and before the actual proof is verified on L1. If validators misbehave, they will be slashed on L1, which provides strong incentives for validators not to act malicious.

This is conditional to:

ensuring that the validators send the same proof to the L1 staking contract and to the DA.
validators cannot exit too early (not before the proof they are committed to are confirmed on L1).

Optimizations

There are several aspects that could be optimized and refined:

super-majority proof: it can be a list of votes, but could also be a zk-proof (more compact). The super-majority proof is not a proof of correct execution (as in zkVM) but simply of super-majority and this is cheaper to compute.
signatures aggregation: we want to avoid sending large transactions to the L1 as it increases operational costs. How to aggregate signatures to send more compact messages/transactions?
delegation/weighted stakes: a mechanism for validators to delegate their voting power to other validators. Ability for validators to stake different amounts (and use weighted stakes super-majority).
commit to a sequence of L2Blocks. The fastconfirmation certificate could be per block. However, on L1 we want to commit to a sequence of blocks (a superBlock). This can be done by committing to the state root of the last block in the sequence or more complicated approaches using Merkle roots.
involvement of DA layer. Validators sent their votes or commitments to a DA layer off-L1. This ensures that votes remain available and can be used for potential slashing. This step should take O(1) second if we use a fast reliable mempool.

MIP