Tier-2 Finality

In most rollups, after 1-3 minutes, the sequencer batches the transactions processed so far and pushes them to the underlying Layer 1 using calldata which essentially stays as on chain storage but is not part of the global account state of Layer 1 and hence cannot be accessed by other contracts. The Layer 2 transaction now has the same finality as the Layer 1 block that included it in a batch, and this is referred to as “hard finality”.

In addition to the transaction data, the sequencer also submits old (state prior to the batched transactions) and new (state after the batched transactions are executed) state roots, which are necessary to prove the correctness of state changes.

Once the sequencer submits the batch, the contract verifies that the pre-state root matches the existing state root. If the two match, the contract discards the old state root and stores the new state root proposed by the sequencer.

Note that at the stage, Layer 1 has all the transactions that the sequencer claims to produce the new state root. However, there is no guarantee that the sequencer's claim and its commitments on the state root are correct. This is exactly why optimistic rollups have a withdrawal period to allow anyone to contest the claims made by the sequencer.

AltLayer improves upon this in two ways. First, as the sequencing network is decentralized via SQUAD, the sequencers can potentially run a consensus protocol, it is unlikely that the sequencing network will generate invalid or incorrect state roots.

Second, and more importantly the sequencers rely on VITAL operators to verify the validity of the state transition via something called proof of validity. VITAL acts as an intermediate network to keep the sequencers accountable via a proof of validity.

Proof of Validity: A rollup’s state is stored in a Merkle tree. For example, a key could be an account ID and a value could be the number of tokens it controls.

In AltLayer, the rollup network generates a proof of valid state transition called proof of validity that allows the VITAL operators to verify a state transition for a rollup without having access to the entire state. In fact, they only need:

• The block (list of state transitions),

• The values in the state database that the block modifies, and

• The hashes of the unaffected points in the Merkle tree.

With these, the VITAL operators can generate the new state root and compare whether the state root claimed by the sequencers is the same as the one they generated themselves. As a result, VITAL acts as a decentralized network of stateless lightclients for the rollup.

The rollup network generates the validity proof and submits it to VITAL periodically (every 6 rollup blocks) in a special block called PoV block. In order to be able to verify a proof of validity produced by the rollup network, VITAL operators implement a state transition validation function (STVF), the Web assembly code for which is a part of the validator’s runtime. The STVF takes as an input the PoV block and outputs the validity of the block. If the proof is valid, VITAL will submit the transaction batch and the pre and post state roots to Layer 1. Note that in existing rollups, this is done directly by the sequencers, while in case of AltLayer, it is the responsibility of VITAL operators.

Note that VITAL detects any sequencer-level fraud at a much earlier stage and therefore reduces the chances of a dispute happening on the underlying Layer 1. In simple terms, VITAL acts as a lower-court for fraud adjudication while the underlying Layer 1 acts as the final supreme court. As a result, VITAL provides better finality guarantees compared to rollups with a sequencer. We refer to this as Tier 2 Finality.