docs: add CIP-48 lower block time to 3 seconds

cips/SUMMARY.md

@@ -50,6 +50,7 @@
   - [CIP-45](./cip-045.md)
   - [CIP-46](./cip-046.md)
   - [CIP-47](./cip-047.md)
+  - [CIP-48](./cip-048.md)
 
 - [Core Devs Call notes](./notes/README.md)
   - [CDC #14](./notes/cdc-14.md)

cips/cip-048.md

@@ -0,0 +1,105 @@
+| cip | 48 |
+| - | - |
+| title | Lower block time to 3 seconds |
+| description | Reduce the block time from 6 seconds to 3 seconds. |
+| author | Rootul Patel ([@rootulp](https://github.com/rootulp)) |
+| discussions-to | <https://github.com/celestiaorg/celestia-app/issues/6622> |
+| status | Draft |
+| type | Standards Track |
+| category | Core |
+| created | 2026-02-28 |
+| requires | [CIP-26](./cip-026.md), [CIP-37](./cip-037.md) |
+
+## 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 `TimeoutPrecommit`), doubling block-count-based parameters (`MaxAgeNumBlocks` and upgrade height delays) so they continue to represent the same wall-clock durations at the faster block rate, 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 4500 milliseconds.
+    1. `DelayedPrecommitTimeout` SHALL be reduced from 5850 milliseconds to 2790 milliseconds.
+    1. `TimeoutPrevote` SHALL be reduced from 3000 milliseconds to 1500 milliseconds.
+    1. `TimeoutPrecommit` SHALL be reduced from 3000 milliseconds to 1500 milliseconds.
+    1. All other timeout parameters (`TimeoutProposeDelta`, `TimeoutPrevoteDelta`, `TimeoutPrecommitDelta`, `TimeoutCommit`) remain unchanged.
+
+1. **Evidence parameter adjustment**: The `MaxAgeNumBlocks` parameter MUST be doubled from 242,640 to 485,280 blocks so that it continues to represent approximately the same wall-clock duration (~16.8 days) at the new 3-second block time. The `MaxAgeDuration` parameter (337 hours) remains unchanged as it is defined in wall-clock time rather than block count.
+
+1. **Upgrade height delay adjustments**: All upgrade height delay parameters MUST be doubled to maintain the same wall-clock durations at the new block rate:
+    1. `ArabicaUpgradeHeightDelay` SHALL be increased from 14,400 to 28,800 blocks (1 day at 3 seconds per block).
+    1. `MochaUpgradeHeightDelay` SHALL be increased from 28,800 to 57,600 blocks (2 days at 3 seconds per block).
+    1. `MainnetUpgradeHeightDelay` SHALL be increased from 100,800 to 201,600 blocks (7 days at 3 seconds per block).
+
+1. **IBC `MaxExpectedTimePerBlock` correction**: The IBC `ConnectionGenesis.Params.MaxExpectedTimePerBlock` parameter MUST be reduced from 75 seconds to 15 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 ~3-second block time, a value of 15 seconds (5x the block time) is appropriate. An on-chain migration via the v8 upgrade handler MUST update this parameter for existing chains.
+
+1. **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.
+
+1. **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:
+
+| Parameter | Current value | Proposed value | Description | Changeable via Governance |
+|-----------|---------------|----------------|-------------|---------------------------|
+| `TimeoutPropose` | 8500 ms | 4500 ms | Maximum time to wait for a block proposal before prevoting nil | No |
+| `DelayedPrecommitTimeout` | 5850 ms | 2790 ms | Time delay before sending a precommit vote | No |
+| `TimeoutPrevote` | 3000 ms | 1500 ms | Timeout for the prevote step before prevoting nil | No |
+| `TimeoutPrecommit` | 3000 ms | 1500 ms | Timeout for the precommit step before precommitting nil | No |
+| `consensus.evidence.MaxAgeNumBlocks` | 242,640 blocks | 485,280 blocks | Maximum number of blocks for which evidence can be submitted for slashing | No |
+| `ArabicaUpgradeHeightDelay` | 14,400 blocks | 28,800 blocks | Number of blocks Arabica waits after a MsgTryUpgrade to activate the next version (~1 day) | No |
+| `MochaUpgradeHeightDelay` | 28,800 blocks | 57,600 blocks | Number of blocks Mocha waits after a MsgTryUpgrade to activate the next version (~2 days) | No |
+| `MainnetUpgradeHeightDelay` | 100,800 blocks | 201,600 blocks | Number of blocks Mainnet waits after a MsgTryUpgrade to activate the next version (~7 days) | No |
+| `ibc.ConnectionGenesis.Params.MaxExpectedTimePerBlock` | 75 seconds | 15 seconds | Maximum expected time per block used by IBC connection verification (should be 3-5x block time) | Yes |
+| `GoalBlockTime` | 15 seconds | Removed | Deprecated constant that no longer reflects the actual target block time | No |
+
+## Rationale
+
+**Why 3 seconds?** The selection 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. 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 double 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 block time is halved, these parameters must be doubled 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 3 seconds per block this requires 201,600 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 15 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 ~3-second block time, 15 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 halve `TimeoutPrevote` and `TimeoutPrecommit`?** These round-based timeout parameters (both currently 3000 ms) determine how long the network waits during the prevote and precommit steps before voting nil. Halving them to 1500 ms ensures that when the network fails to reach consensus in the first round, subsequent rounds progress proportionally faster. Without this adjustment, a failed round would take disproportionately long relative to the new 3-second block time, delaying recovery.
+
+## 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 3-second 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](https://github.com/celestiaorg/celestia-app/pull/6643): Implements the consensus timeout and upgrade height delay changes.
+- [celestia-app#6661](https://github.com/celestiaorg/celestia-app/pull/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.
+
+1. **Evidence validity window**: Doubling `MaxAgeNumBlocks` to 485,280 ensures the evidence validity window remains approximately 16.8 days at the new block rate, 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.
+
+1. **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](https://github.com/celestiaorg/CIPs/blob/main/LICENSE).