Subcommitments: Off-Chain Finality — Fast, Secure, and Cheap

written by Alejandro Ranchal-Pedrosa.

We would like to thank Luca Donno and Jonas Theis for his thoughtful reviews and comments on an initial draft of this post.

Rollups like Scroll achieve incredible scalability by processing transactions off-chain and periodically submitting succinct proofs of correctness to Layer 1 (L1). While this guarantees fast on-chain finality—finality verifiable by L1 smart contracts, users increasingly demand fast off-chain finality—the confidence that transactions confirmed by the rollup sequencer will not be reverted, even before the data is fully committed and proven on the L1.

The Challenge of Fast Off-chain Finality

Providing users with fast off-chain finality presents inherent challenges:

Security concerns: Users relying on rapid confirmations risk double-spend attacks if trusting the sequencer before an irreversible commitment of transaction data is available on L1.
High data availability (DA) costs: Immediate commitment of transaction data to L1 ensures off-chain finality but significantly increases operational costs.

Thus, current designs couple off-chain finality directly to immediate DA publication, forcing a trade-off between latency, security, and cost: security comes at either a high DA cost or high latency.

Demand for blobs has been steadily increasing over time, as exemplified in the following chart of number of blobs per day (the recent spike has been motivated by the new 6 blobs target from the pectra upgrade).

Over time, along with greater demand for throughput in the Ethereum ecosystem, demand for blobs from multiple rollups will continue steadily increasing, and along with them, the price for blobs due to congestion, aggravating the trade-off between DA costs and off-chain finality.

Introducing Subcommitments

Subcommitments break this trade-off by providing fast off-chain finality without having to publish the DA on-chain. Subcommitments are posted additionally to regular, less frequent commitments (which do publish the DA on-chain). Subcommitments carry succinct representations of the L2 ledger, such that users who hold the data locally corresponding to L2 state transition can independently verify them, achieving rapid and secure off-chain finality.

There are two main benefits derived from subcommitments thanks to eliminating the trade-off between DA costs, security and latency:

1. Cheaper transaction fees:

Thanks to being able to obtain immediate off-chain finality without having to pay for blobs, DA is now only necessary for on-chain finality. As a result, the sequencer can have flexibility to decide when to commit full data at optimal times, leveraging cheaper blob prices and better data compression (i.e. more transactions in one blob at a time where blob fees are cheaper means cheaper fees per L2 transaction and/or greater margins for the rollup).
Compression efficiency over several minutes/hours is expected to grow superlinearly in the number of L2 transactions for full transaction data, even more so for most cases if the DA consists of submitting the State Diff.
This feature is important for zk rollups, as optimistic rollups are under pressure to commit full tx data as soon as possible to start the challenge period as soon as possible and not to further delay on-chain finality, a requirement that does not exist in zk rollups. Subcommitments are thus a new weapon that zk rollups can use to compete in terms of prices with optimistic rollups while obtaining the same latency for off-chain finality and significantly lower for on-chain finality.

2. Greater security:

Users can independently anchor verified states onto L1 (by submitting subcommitments themselves), mitigating reliance on the sequencer or being bound by the default's off-chain finality frequency of the L2 system. Though this can be done with the appropriate design by users submitting the DA directly, it is unreasonable to ask for this much extra cost on users interested in greater security at lower latency. Subcommitments effectively enable this feature at a reasonable, constant cost, irrespective of the associated DA size of the state transition being anchored.

How Subcommitments Work

Subcommitments are succinct metadata (typically a cryptographic hash) that uniquely represents an L2 state transition (e.g. the hash of a sequence of L2 blocks). The sequencer submits these subcommitments periodically (e.g., every 30 minutes), significantly more frequently than full DA commitments (e.g. every 12 hours).

Alternatively, the sequencer can also offer subcommitments-as-a-service: by signing to the metadata of a subcommitment and distributing the metadata and signature off-chain, users are free to submit subcommitments signed by the sequencer themselves and obtain even lower latency off-chain finality than offered by default by the system (e.g. an app moving a lot of funds and not trusting the sequencer, wanting to offer their users level of safety and latency they are used to, can decide to subcommit 10 minutes after the previous subcommitments, or 3x faster than the default subcommitment submitted by the sequencer).

Good case. As such, the protocol for subcommitments in the good case where the sequencer is honest is the following:

Sequencer submits subcommitments periodically, or users submit signed subcommitments distributed and signed off-chain by sequencer.
Users observing a subcommitment on L1 and verifying it against their local data can confidently trust the associated off-chain state.
Full transaction data commitments and proofs come later, optimized for lower blob fees and better compression.

Sequencer's misbehavior. Commitments can be used for off-chain finality because they provide guarantees of security even if the sequencer is faulty. As such, for subcommitments to provide off-chain finality, we need to account for the misbehavior of the sequencer. If the sequencer is faulty, it can corrupt the good case by either (i) not submitting subcommitments or (ii) submitting incorrect subcommitments (whose data is not available to anyone, or is only available to the sequencer)

If the sequencer does not submit subcommitments, then the rollup simply operates at its usual frequency for commitments. Similarly, the same mechanisms that are already known to prevent this misbehavior from the sequencer (enforced batches, decentralized commitments, etc.) can be used for subcommitments too.

If the sequencer submits incorrect subcommitments, the rollup faces a problem: these faulty subcommitments do not correspond to any transaction data known to anyone other than the sequencer. Because commitments and proofs must match the subcommitments, the rollup cannot proceed until the issue is resolved. This scenario leads to the critical edge case where subcommitments may need to be reverted.

Reverting subcommitments: To handle incorrect subcommitments, the protocol must define a clear timeout period. If the sequencer fails to commit and prove the state transition within this timeout, the problematic subcommitment can be safely reverted. Under normal conditions, this timeout isn't reached because proper commitments and proofs are provided promptly.

Preventing sequencer misuse: Allowing subcommitments to revert introduces a new risk—malicious sequencers (coordinating with malicious provers) could intentionally revert valid transactions, causing double-spending issues. To address this, the protocol includes a shorter timeout period within which anyone can submit valid commitments and/or proofs. This mechanism ensures that even if the sequencer misbehaves, the network remains secure, and transactions can still reach finality, if the subcommitment was correct. The sequencer may also get slashed an amount of stake if he fails to commit before the decentralized commitment period kicks in, which can be used to subsidize and even reward decentralized committers. Instead of decentralized commitment and proving, enforced mode can also serve as a protection against this attack.

This two-tier timeout structure—shorter timeouts for decentralized intervention and longer timeouts for reverting subcommitments—balances security and operational robustness.

Conclusion

Subcommitments represent a significant improvement in rollup technology by providing zk-rollups with a crucial competitive advantage: the decoupling of DA costs from fast off-chain finality. This innovation enables lower costs, enhanced security, and flexibility, positioning zk-rollups like Scroll favorably against optimistic alternatives. Ultimately, subcommitments allow users and applications to safely and efficiently leverage the full potential of Ethereum scaling.