CIP: Standardize data expiry time for pruned nodes #16
Conversation
cips/cip-pruning-window.md
Outdated
|
|
||
| On the Celestia data availability network, there is only one topic under which storage nodes can be discovered, where all nodes discovered under that topic are expected to be non-pruned nodes. | ||
|
|
||
| An additional new topic will be created for pruned nodes, so that nodes discovered under the existing topic will not unexpectedly have missing block data when being queried. |
There was a problem hiding this comment.
Should we name the exact topics here @Wondertan?
There was a problem hiding this comment.
You can name them full and archival
Where full is the default (pruned) and archival is historical
There was a problem hiding this comment.
As a side note, I was going to name them archival in this text, but then I saw that Ethereum refers to archival nodes as nodes that store all historical blocks but only prune state.
So I thought maybe it's better to be explicit and refer to them as block archival nodes; or non-pruned nodes. To avoid confusion.
But if you're saying full and archival are the actual topic names in libp2p, I don't think that matters.
cips/cip-pruning-window.md
Outdated
|
|
||
| On the Celestia data availability network, there is only one topic under which storage nodes can be discovered, where all nodes discovered under that topic are expected to be non-pruned nodes. | ||
|
|
||
| An additional new topic will be created for pruned nodes, so that nodes discovered under the existing topic will not unexpectedly have missing block data when being queried. |
There was a problem hiding this comment.
You can name them full and archival
Where full is the default (pruned) and archival is historical
cips/cip-pruning-window.md
Outdated
|
|
||
| On the Celestia data availability network, there is only one topic under which storage nodes can be discovered, where all nodes discovered under that topic are expected to be non-pruned nodes. | ||
|
|
||
| An additional new topic will be created for pruned nodes, so that nodes discovered under the existing topic will not unexpectedly have missing block data when being queried. |
There was a problem hiding this comment.
The pruned node topic will not be an additional topic but rather the current topic that we have which is full. The additional topic will be for archival nodes (archival).
We should call storage nodes archival to better indicate that they retain + serve historical blocks.
There was a problem hiding this comment.
IMO it should be the other way round: the existing topic should be for archival nodes, otherwise you will break backwards compatibility, because you will clutter the existing topic with non-archival nodes, which will not be backwards compatible with older nodes that are discovering nodes in the existing topic, and thinking they have all the historical blocks.
We could keep full for archival and introduce an additional topic such as pruned.
cips/cip-pruning-window.md
Outdated
| title: Standardize data expiry time for pruned nodes | ||
| description: Standardize default data expiry time for pruned nodes to 30 days. | ||
| author: Mustafa Al-Bassam (@musalbas) | ||
| discussions-to: URL |
There was a problem hiding this comment.
Needs a discussion link. Maybe open one in the forum
cips/cip-pruning-window.md
Outdated
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](../LICENSE). | ||
| <!-- markdownlint-disable MD013 --> |
There was a problem hiding this comment.
What's the implications of deleting that line? Should that also be removed from the template then?
There was a problem hiding this comment.
I will do so now. it's for markdown linters to ignore some rules.
There was a problem hiding this comment.
|
Moving discussion to https://forum.celestia.org/t/cip-standardize-data-expiry-time-for-pruned-nodes/1326 |
Rendered
Discussion: https://forum.celestia.org/t/cip-standardize-data-expiry-time-for-pruned-nodes/1326