May 29, 2025 · 7 min read
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.
Providing users with fast off-chain finality presents inherent challenges:
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.
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:
2. Greater security:
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'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.
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.