Celestia Improvement Proposals (CIPs)

Abstract

This CIP proposes reducing Celestia’s trusting period (or weak subjectivity period) to 7 days, consequently setting the light node sampling window to 7 days. The goals include optimizing light client resource usage, reducing rollup finality times, and potentially enabling a shorter validator unbonding period. This proposal explicitly decouples the trusting period and sampling window from the minimum pruning window. It supersedes aspects of CIP-004 regarding sampling window duration by clarifying the minimum pruning window’s independence.

Motivation

Reducing the trusting period to 7 days addresses longer sync times for rejoining nodes and aims to:

1. Optimize Resource Usage for Light Clients: Light clients will only need to sample data over a 7-day window cutting total bandwidth requirements by 76,66%. The total bandwidth saving is only during initial sync and not when syncing at the tip of the chain.
2. Optimize Resource Usage for Full Nodes: Full nodes will only need to store and distribute samples in blocks that were created in the last 7 days.
3. Reduce rollup finality time: A shorter trusting period allows optimistic rollups to have shorter fraud proof windows, leading to faster finality for rollup transactions.
4. Potentially reduce the unbonding period for validators: The unbonding period for validators could be reduced to be closer to the new trusting period of 7 days.

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.

0. Trusting Period Definition: The trusting period (also known as the weak subjectivity period) is defined as the maximum duration a node MAY safely remain offline and later rejoin the network by sampling historical data within this period without requiring an external trust assumption for the time it was offline.
1. Trusting Period Reduction: The trusting period for the Celestia network SHALL be set to 7 days.
2. Sampling Window Adjustment: Consequently, the data availability sampling window for light nodes SHALL be 7 days. Light nodes MUST sample data for this exact duration to verify the chain’s integrity after being offline. This adjusts the sampling window parameter discussed in CIP-004.
3. Unbonding Period Constraint: The unbonding period for validators MUST be greater than or equal to the new trusting period of 7 days. It is RECOMMENDED that the unbonding period be reviewed and potentially adjusted to align with this new, shorter trusting period, but it MUST NOT be less than 7 days.
4. Minimum Pruning Window Decoupling: The data minimum pruning window (how long full nodes retain block data) SHALL be decoupled from the trusting period. It MAY be set to a value different from 7 days (e.g., 14 days or longer), based on network data retention policies and storage considerations. This CIP does not mandate a specific minimum pruning window but clarifies its independence from the trusting period.

Parameters

The following parameter change is proposed for the Celestia network:

(Note: Exact parameter names may vary across implementations. The SamplingWindow from CIP-004 is superseded by the new TrustingPeriod which dictates the exact sampling duration.)

Rationale

Reducing the trusting period to 7 days balances accommodating typical node offline durations with improving node requirements.

• 7-Day Window: A 7-day period is considered sufficient for most routine node downtimes (e.g., maintenance, temporary outages) while being significantly shorter than a 14-day period.
• Equivalence of Sampling and Trusting Period: The sampling window must be equivalent to the trusting period. Sampling less would expose nodes to risks from attacks during their offline period. Sampling more is unnecessary and could lead to false positives if data has been (correctly) pruned by full nodes.
• Decoupling from Minimum Pruning Period: The minimum pruning window serves a different purpose: managing data retrieval service guarantees of full nodes. Decoupling it from the trusting period allows the network to set data retention policies (e.g., 14 days, 30 days, or more) based on economic incentives and data retrievability needs, without constraining security parameters related to the weak subjectivity period. This CIP clarifies this decoupling, ensuring changes to the trusting period do not inadvertently force changes to data retention strategies, and vice-versa.
• Impact on Unbonding Period: The unbonding period must be at least as long as the trusting period to prevent validators from unbonding and escaping slashing for misbehavior that is discovered within the trusting period. Lowering the trusting period to 7 days allows for a potential reduction in the unbonding period, which can improve capital efficiency for validators. However, this CIP only mandates the minimum constraint (>= 7 days).

Backwards Compatibility

This CIP introduces changes that require coordinated updates across the network:

1. Node Updates: All node types (light nodes, full nodes, validators) MUST be updated to recognize and operate with the new 7-day trusting period.

   • Light nodes configured with the old 14-day sampling window might attempt to sample data beyond the new 7-day window. If full nodes adopt a minimum pruningwindow shorter than 14 days (though still longer than 7 days, e.g., 10 days), these older light nodes could encounter issues or raise false alarms about data unavailability. However, the primary concern is ensuring all nodes operate on the same understanding of the trusting period.
   • Nodes that do not update will operate with outdated security assumptions, potentially leading to them following a minority fork if a long-range attack scenario were to occur that is preventable by nodes aware of the correct (shorter) trusting period.

2. IBC Light Clients and Bridges: IBC light clients and bridges connected to Celestia MUST update their trusting period configurations to align with Celestia’s new 7-day period. This is critical for maintaining their security, as detailed in the Security Considerations section.

Security Considerations

This CIP has several important security implications:

1. IBC Light Clients and Bridges:

   • Context: IBC connections use a Tendermint light client configured with a trusting period, defining how long it accepts headers from Celestia without a fresh checkpoint. If Celestia’s on-chain trusting period is reduced (e.g., to 7 days) while an IBC client’s configuration remains at an older, longer value (e.g., 14 days), a critical security mismatch occurs.
   • Risk: An IBC light client with an outdated (longer) trusting period will trust headers that Celestia full nodes would deem stale and insecure, leading to vulnerabilities such as:
     • Long-Range Fork Acceptance: The IBC client might follow a malicious fork older than Celestia’s 7-day trusting period (and rejected by Celestia nodes) but within its own outdated window, causing invalid cross-chain state and potential asset loss.
     • Exploitable Trust Window Mismatch: An outdated IBC client (e.g., 14-day trust) creates a window where it might accept a fraudulent history based on validator misbehavior (occurring >7 days but <14 days ago) that Celestia nodes, with their 7-day trust, would reject.
   • Mitigation:
     • It is CRITICAL that all IBC light clients and bridge modules connected to Celestia update their trusting period configuration to match Celestia’s new 7-day period. To account for potential network or processing latencies, this configured value SHOULD ideally be Celestia’s 7-day period or a slightly shorter duration.
     • This update REQUIRES updating the light client state on the counterparty chain or bridge module. The existing light client instance MUST be replaced with a new one configured with the correct 7-day trusting period.
     • All bridge operators and relayer teams MUST be proactively informed and MUST participate in this upgrade. Failure to update and coordinate risks client desynchronization, the processing of invalid headers, acceptance of rejected forks, and significant security vulnerabilities for connected chains and applications.

2. Uniform Adoption of Trusting Period:

   • Risk: If different nodes in the network operate with different trusting periods, it can lead to network fragmentation. Nodes with a longer trusting period might accept a chain that nodes with the correct, shorter trusting period would reject.
   • Mitigation: The change to a 7-day trusting period SHOULD be adopted uniformly by all Celestia node types (light, full, validator) through a coordinated network upgrade. While a phased rollout might be considered, all nodes SHOULD eventually adopt the new period to prevent network fragmentation.

3. Validator Unbonding Period:

   • Security Implication: The unbonding period MUST remain greater than or equal to the trusting period (7 days). Failure to adhere to this allows malicious validators to unbond and withdraw stake before misbehavior (e.g., involvement in creating a long-range attack fork) is detected by nodes that were offline and subsequently re-synced within the trusting period.

Copyright

Copyright and related rights waived via CC0.