CPS-???? | Node Behavior during Low Participation #982
Conversation
nfrisby
force-pushed
the
nfrisby/low-participation-CPS
branch
from
96c2a7f to
f04475d
Compare
|
I'd appreciate your review @nc6, since we've discussed this in the past. |
| This limit is a disjunction of Common Prefix and Chain Growth. | ||
|
|
||
| - *EnforceChainGrowth* (EnforceCG). | ||
| In addition to AssumeIA, the node rejects any chain that has less than 2160 blocks per 36 hr (even if selecting it wouldn't require rolling back any blocks). |
There was a problem hiding this comment.
It's not directly clear to the reader (or, this reader at least!) how these immediately relate to the question above, since they don't say "what does the node do if it has a sparse chain" but rather constrain some other operations. I would suggest moving the TwoThirdsInaccessible block up above the description of the options, in order to outline the things that the node could do, and then from there lead into the possibilities and how they relate to various security arguments
| Since the nodes and/or other Cardano community tooling might have been designed around the guarantee of at most 36 hrs for 2160 blocks, they could fail outright or become more vulnerable to possible DoS attacks during the outage. | ||
|
|
||
| - If the whole network implemented EnforceIA, then the nodes would not face increased risks. | ||
| The 2160 disjunct in the EnforceIA definition is an optimization for when the chain is growing faster than 2160 blocks per 36 hr. |
There was a problem hiding this comment.
I find the way that this is written to be slightly confusing. AIUI, the behaviour here would be identical to AssumeIA, since there's no rollback involved. So we'd still have the same concerns as under AssumeIA, right?
| The 2160 disjunct in the EnforceIA definition is an optimization for when the chain is growing faster than 2160 blocks per 36 hr. | ||
|
|
||
| - If the whole network implemented EnforceCG, then the Recovery Plan would be unavoidable (once the affected stake was back online). | ||
| The silver lining is that all nodes would be able to switch to the repaired chain automatically, without needing manual intervention. |
There was a problem hiding this comment.
Likewise, I would elaborate more on this case - would grow the chain up until the 36 hour point, when all nodes would stop growing the chain and we would need to effect disaster recovery. But since we hadn't grown more than 2160 blocks, each node would be happy to roll back and select the denser chain...
| --- | ||
| CPS: XXXX | ||
| Title: Node Behavior during Low Participation | ||
| Status: Draft |
There was a problem hiding this comment.
| Status: Draft | |
| Status: Open |
@nfrisby please note marking Draft review status on GitHub is enough to indicate this is a draft; while the CPS itself will be Open until considered solved. There is no Draft status for either CIPs or CPSs.
Likewise the CIP header of #974 should be changed to Proposed since that is most likely the way it would be reviewed (once emerging from Draft review status) and merged.
rphair
changed the title
A CPS for the community to elicit proposals for how the node should behave when the best chain it has access to is growing much slower than Cardano's Praos security argument anticipates when full participation is assumed.
The fact that this behavior is unspecified can obstruct node design and/or may be overlooked, such that nodes and community tooling may cause a failure cascade if the network ever does suffer low participation for some extended period (eg bug, solar flare, etc).
Rendered: https://github.com/nfrisby/CIPs/blob/nfrisby/low-participation-CPS/CPS-XXXX/README.md