Celestia Improvement Proposals (CIPs)

Abstract

This CIP proposes reducing the Celestia block time from 6 seconds to 3 seconds. This is achieved by adjusting the consensus timeout parameters (TimeoutPropose, DelayedPrecommitTimeout, TimeoutPrevote, and TimeoutCommit), scaling block-count-based parameters (MaxAgeNumBlocks and upgrade height delays) to account for the ~2.6-second effective block time so they continue to represent the same wall-clock durations, and correcting the IBC MaxExpectedTimePerBlock parameter. The GoalBlockTime constant is deprecated and removed as it is no longer accurate or necessary.

Motivation

Lower block times directly improve the user experience on Celestia by reducing transaction confirmation latency. With 3-second blocks, users and rollups submitting blob transactions receive confirmations in roughly half the time compared to the current 6-second block time.

Faster block production also benefits rollups built on Celestia. Rollups that post data to Celestia can achieve faster data availability confirmations, reducing the end-to-end latency for rollup users. This is especially important for rollups that require prompt data availability to advance their own chain state.

Additionally, halving the block time doubles the number of blocks produced per unit of time. Combined with appropriate block size limits, this increases the overall data throughput capacity of the network without requiring changes to the maximum block size.

CIP-26 previously reduced the block time from 12 seconds to 6 seconds and demonstrated that the network can operate reliably at faster block intervals. This proposal continues that progression.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

1. Consensus timeout adjustments: The following consensus timeout parameters MUST be updated to target a ~3-second block time:

   1. TimeoutPropose SHALL be reduced from 8500 milliseconds to 3000 milliseconds.
   2. DelayedPrecommitTimeout SHALL be reduced from 5850 milliseconds to 2100 milliseconds.
   3. TimeoutPrevote SHALL be reduced from 3000 milliseconds to 2000 milliseconds.
   4. TimeoutCommit SHALL be increased from 1 millisecond to 500 milliseconds.
   5. All other timeout parameters (TimeoutProposeDelta, TimeoutPrevoteDelta, TimeoutPrecommitDelta, TimeoutPrecommit) remain unchanged.

2. Evidence parameter adjustment: The MaxAgeNumBlocks parameter MUST be increased from 242,640 to 559,940 blocks so that it continues to represent approximately the same wall-clock duration (~16.8 days) at the ~2.6-second effective block time. The MaxAgeDuration parameter (337 hours) remains unchanged as it is defined in wall-clock time rather than block count.

3. Upgrade height delay adjustments: All upgrade height delay parameters MUST be scaled to maintain the same wall-clock durations at the ~2.6-second effective block time:

   1. ArabicaUpgradeHeightDelay SHALL be increased from 14,400 to 33,231 blocks (~1 day at ~2.6 seconds per block).
   2. MochaUpgradeHeightDelay SHALL be increased from 28,800 to 66,462 blocks (~2 days at ~2.6 seconds per block).
   3. MainnetUpgradeHeightDelay SHALL be increased from 100,800 to 232,616 blocks (~7 days at ~2.6 seconds per block).

4. IBC MaxExpectedTimePerBlock correction: The IBC ConnectionGenesis.Params.MaxExpectedTimePerBlock parameter MUST be reduced from 75 seconds to 13 seconds. Per IBC documentation, this value should be 3-5x the expected block time. The previous value of 75 seconds was based on the outdated GoalBlockTime of 15 seconds. With a ~2.6-second effective block time, a value of 13 seconds (5x the block time) is appropriate. An on-chain migration via the v9 upgrade handler MUST update this parameter for existing chains.

5. Deprecation of GoalBlockTime: The GoalBlockTime constant (currently set to 15 seconds) is inaccurate and SHOULD be deprecated and removed. The actual target block time is determined by the consensus timeout parameters listed above rather than by this constant.

6. Network upgrade: These changes are state-breaking and MUST be deployed as part of a coordinated network upgrade. Celestia consensus nodes MUST update their software prior to the activation height.

Parameters

The following parameter changes are proposed:

Rationale

Why ~3 seconds? The nominal target of a 3-second block time represents a practical halving of the current 6-second block time. This is the same approach taken in CIP-26 when block time was halved from 12 to 6 seconds. The actual effective block time from the proposed consensus parameters is ~2.6 seconds (DelayedPrecommitTimeout of 2100 ms + TimeoutCommit of 500 ms). A ~3-second block time is consistent with block times used by other modern L1 networks and provides a meaningful improvement in transaction latency without placing excessive demands on validator infrastructure.

Why scale block-count-based parameters? Parameters defined in terms of block counts (such as MaxAgeNumBlocks and the upgrade height delays) represent wall-clock durations implicitly. When the effective block time changes, these parameters must be scaled by the ratio of old to new block time (6 / 2.6) to preserve the same real-time durations. For example, MainnetUpgradeHeightDelay represents a 7-day waiting period: at 6 seconds per block this requires 100,800 blocks, and at ~2.6 seconds per block this requires 232,616 blocks.

Why remove GoalBlockTime? The GoalBlockTime constant is set to 15 seconds, which has been inaccurate since CIP-26 reduced the block time to 6 seconds. Rather than updating it to 3 seconds, it is cleaner to remove it entirely. The actual block time is governed by the consensus timeout parameters (TimeoutPropose, DelayedPrecommitTimeout, etc.), making GoalBlockTime redundant and potentially misleading.

Why reduce MaxExpectedTimePerBlock from 75 seconds to 13 seconds? The IBC MaxExpectedTimePerBlock parameter should be 3-5x the expected block time per IBC documentation. The previous value of 75 seconds was calculated as 5x the GoalBlockTime of 15 seconds, which was already stale. With a ~2.6-second effective block time, 13 seconds (5x) is the correct value. An incorrect MaxExpectedTimePerBlock can cause IBC connection verification to behave suboptimally, as it affects how IBC calculates the expected time elapsed between block heights during connection handshakes and packet verification.

Why reduce TimeoutPrevote and increase TimeoutCommit? TimeoutPrevote is reduced from 3000 ms to 2000 ms to ensure that when the network fails to reach consensus in the first round, subsequent rounds progress proportionally faster relative to the new block time. TimeoutPrecommit remains unchanged at 3000 ms to preserve sufficient time for precommit aggregation. TimeoutCommit is increased from 1 ms to 500 ms to allow a delay for transactions to be included in the next block, benefiting clients that wait for a transaction to be included before submitting a new one. Combined with DelayedPrecommitTimeout of 2100 ms, this produces an effective block time of ~2.6 seconds in the happy path.

Backwards Compatibility

This change is not backwards compatible. All consensus nodes must upgrade to the new software version before the activation height. Nodes running older software will be unable to keep up with the faster block production rate and will fall out of consensus.

Client applications and tooling that assume a 6-second block time (for example, when estimating confirmation times or computing block heights from timestamps) SHOULD be updated to reflect the new ~2.6-second effective block time.

Test Cases

These parameter changes will be tested on the Arabica devnet and Mocha testnet before activation on Celestia Mainnet.

Reference Implementation

• celestia-app#6643: Implements the consensus timeout and upgrade height delay changes.
• celestia-app#6661: Removes GoalBlockTime and corrects IBC MaxExpectedTimePerBlock.

Security Considerations

1. Validator infrastructure requirements: Faster block times place higher demands on validator hardware and network connectivity. Validators must ensure their systems can reliably propose and vote on blocks within the tighter time constraints. Validators with high-latency network connections may experience increased missed proposals or votes.

2. Evidence validity window: Increasing MaxAgeNumBlocks to 559,940 ensures the evidence validity window remains approximately 16.8 days at the ~2.6-second effective block time, preserving the security guarantee that misbehavior can be detected and punished within the unbonding period. This maintains consistency with the unbonding time of 337 hours (14 days + 1 hour) established in CIP-37.

3. Upgrade coordination: The simultaneous change of multiple consensus-critical parameters requires careful coordination. All parameters must be activated atomically as part of the same network upgrade to avoid inconsistent behavior.

Copyright

Copyright and related rights waived via CC0.