From 837357a1aa8e705fb11aff72c3b6ace03b225382 Mon Sep 17 00:00:00 2001 From: jcstein <46639943+jcstein@users.noreply.github.com> Date: Wed, 16 Oct 2024 10:49:54 -0400 Subject: [PATCH] docs: clarify upgrade path and why params moved --- cips/cip-26.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/cips/cip-26.md b/cips/cip-26.md index c11df11..4542d5f 100644 --- a/cips/cip-26.md +++ b/cips/cip-26.md @@ -20,22 +20,18 @@ The motivation for this CIP stems from a discussion in Core Devs Call 17, where ## Specification 1. The block time in celestia-app SHOULD be reduced from 12 seconds to 6 seconds. Concretely, this implies decreasing `TimeoutCommit` to 4.2 seconds and `TimeoutPropose` to 3.5 seconds. - -1. The change in block time MUST be implemented at a specific block height, which SHALL be determined and agreed upon by the Celestia community via on-chain signaling by validators. - -1. Celestia consensus nodes SHOULD update their software to accommodate this change prior to the agreed-upon block height. - -1. Client applications interacting with the Celestia network SHOULD be updated to account for the faster block time, particularly in areas related to transaction confirmation and block finality. + 1. The `TimeoutCommit` and `TimeoutPropose` parameters were moved from local config parameters into versioned parameters controlled by the state machine to ensure consistency and correctness across different protocol versions. This change allows the system to adapt dynamically to version-specific requirements, improving overall stability and interoperability during upgrades. + 1. The change in block time MUST be implemented at a specific block height, which SHALL be determined and agreed upon by the Celestia community via on-chain signaling by validators. + 1. Celestia consensus nodes SHOULD update their software to accommodate this change prior to the agreed-upon block height. + 1. Client applications interacting with the Celestia network SHOULD be updated to account for the faster block time, particularly in areas related to transaction confirmation and block finality. 1. Documentation and APIs related to block time and block production MUST be updated to reflect this change. 1. The default `ttl-num-blocks` parameter in the mempool configuration SHALL be increased from 5 to 12. This change is necessary to maintain consistency with the new block time and ensure that transactions remain in the mempool for a similar duration as before. 1. Current default: `ttl-num-blocks = 5` 1. New default: `ttl-num-blocks = 12` - -1. This change SHALL be implemented alongside the block time reduction to ensure consistent behavior of the mempool across the network upgrade. - -1. All validator nodes MUST update their configuration files to reflect this new `ttl-num-blocks` value before the agreed-upon implementation block height. + 1. This change SHALL NOT be implemented alongside the block time reduction. The default increase from 5 to 12 will occur when users upgrade to v3.0.0 and regenerate their config files. The block time reduction will happen one week later when the v2 to v3 activation height occurs. This approach ensures consistent behavior of the mempool across the network upgrade. + 1. All validator nodes MUST update their configuration files to reflect this new `ttl-num-blocks` value before the agreed-upon implementation block height. ## Rationale