Lowering Trustingperiod to 7 days#309
Conversation
rootulp
left a comment
There was a problem hiding this comment.
Thanks for the PR. My comments are mostly questions / nits, nothing blocking so can be addressed after this merges.
cips/cip-0xx.md
Outdated
|
|
||
| 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`. |
There was a problem hiding this comment.
[nit] clarify "full nodes" by specifying DA full node or consensus full node.
[question] why do validators need to be updated? Are they currently aware of the trusting period?
There was a problem hiding this comment.
I am pretty sure every node type is aware of this. And if there are not they should be, because every node type should have the same trusting period see https://forum.celestia.org/t/frame-by-frame-unpacking-celestia-s-windows-and-parameters/2001#p-3439-weak-subjectivity-is-uniform-across-node-types-8
There was a problem hiding this comment.
I would actually say every node type, no matter whether DA or not.
There was a problem hiding this comment.
Practically speaking consensus nodes aren't aware of a trusting period (unless state syncing) and I don't think we plan to make any changes there. Consensus nodes can still sync from genesis
There was a problem hiding this comment.
They sync from genesis without a trusted checkpoint?
cips/cip-0xx.md
Outdated
| - 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 `pruning window` 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. |
There was a problem hiding this comment.
[question] Is this only necessary if we decrease the validator unboding time?
There was a problem hiding this comment.
I am not sure and i wrote that to the best of my knowledge . We need someone with better IBC understanding to have a look at this in particular. cc @damiannolan
There was a problem hiding this comment.
IMO IBC light clients have different security assumptions to DA light nodes as they don't sample. IMO the TrustingPeriod for an IBC client can be different to what is decided here so long as it's still within the unbonding period (hence why we're only planning to drop the unbonding period to 14 days + 1 hour since most IBC light clients are 14 days).
The thing is, is that we can't really control whether counterparty chains will modify the trusting period of their light clients. At the moment, IBC, the protocol doesn't support this upgrade of a client so we would need modifications there. The only permissionless thing we can do is setup new clients and channels and encourage users to route through this new client instead
There was a problem hiding this comment.
Agree. The ibc trusting period is a fraction of the validator unbonding period, usually 2/3.
Given unbonding period of 21 days, the trusting period is normally 14 days. However, ibc tendermint clients only enforce that the trusting period be less than the unbonding period ref.
The IBC client upgrade mechanism previously only supported changing the unbonding period. So you could only actually decrease it by <1/3 (assuming the trusting period was set to 2/3 to begin with).
The client upgrade mechanism is a bit nuanced. It requires the chain who wishes to change its unbonding period to store an IBC client state representing itself in a verifiable path. Once the chain is upgraded, some ibc events are emitted, and all counterparties connected to that chain can then prove and verify the new parameters of the light client and take them onboard.
I have detailed more in this issue, and got a PR merged and backported to ibc-go/v10 which allows the trusting period to be scaled down proportionally to the change in the unbonding period.
cosmos/ibc-go#8184
There was a problem hiding this comment.
Isn't that a breaking change?
Nevertheless, iiuc, counterparty chains that have upgrade to v10 of IBC will have their trusting period changed when the unbonding period is updated?
cmwaters
left a comment
There was a problem hiding this comment.
Biggest point that is missing is making the change of the TrustingPeriod from a local subjective parameter to a network wide one more visible and with more rationale. I would like to understand the consequences if two light nodes for example had different values
cips/cip-0xx.md
Outdated
| 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`. |
There was a problem hiding this comment.
I think to be more precise, the UnbondingPeriod must be greater than the TrustingPeriod plus some delta which represents the global synchrony bound - essentially the upper limit it would take to propagate evidence and potentially slash the malicious nodes
| - 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. |
There was a problem hiding this comment.
Can you elaborate further on the necessity of making the TrustingPeriod which was hitherto local to the node some global constant to the network. What do you mean by fragmentation etc. Can you also make that clearer earlier in the specification of the CIP as I think this is an important point.
There was a problem hiding this comment.
I tried explaining this point here https://forum.celestia.org/t/frame-by-frame-unpacking-celestia-s-windows-and-parameters/2001#p-3439-weak-subjectivity-is-uniform-across-node-types-8
Does that makes sense ? Will add more to the CIP as well if we agree on it
|
@cmwaters asked that I assign a CIP number and merge so doing that. Apologies if this was still in draft but feel free to address any feedback via subsequent PRs. |
Overview
A CIP to lower the trusting period to 7 days, consequently setting the light node sampling window to 7 days as well.