docs: ADR 14 Versioned Namespaces #1382
Conversation
rootulp
requested review from
liamsi,
adlerjohn,
MSevey and
evan-forbes
as code owners
There was a problem hiding this comment.
only remaining thing imo, otherwise LGTM and I think we should merge
ERROR: 2 dead links found!
[✖] https://proto.school/anatomy-of-a-cid → Status: 0
[✖] https://cid.ipfs.tech/#QmcRD4wkPPi6dig81r5sLj9Zm1gDCL4zgpEj9CfuRrGbzF → Status: 0
edit: shoot nvm these weren't working for me the other day, but they are now, idk what is wrong with the link checker.
| 1. Changes to the non-interactive default rules that don't break backwards compatibility with existing namespaces [celestia-app#1282](https://github.com/celestiaorg/celestia-app/issues/1282), [celestia-app#1161](https://github.com/celestiaorg/celestia-app/pull/1161) | ||
| - After mainnet launch, if we want to change the non-interactive default rules but retain the previous non-interactive default rules for backwards compatibility, it isn't possible to differentiate the namespaces that want to use the old rules vs the new rules. |
There was a problem hiding this comment.
Just to regurgitate this point for my own understanding: We want the rules that define the construction of a square (i.e. potentially the non-interactive default rules or any other algorithm) to be on a per namespace basis. Not per square (i.e. a version number that reflects the construction algorithm for the entire square - implying homogeneity for all txs in that square) and not per share (i.e. multiple shares for the same namespace could theoretically have different versions for interpreting where they should be placed in the square - this assumes that all messages are always tied to a namespace and are always ordered (ascending)).
There was a problem hiding this comment.
Yes I believe so.
this assumes that all messages are always tied to a namespace and are always ordered
messages => blobs ? If so, I agree.
There was a problem hiding this comment.
Well messages could also be an IBC transaction or a governance vote (they still have namespaces)
|
|
||
| 1. Changes to the non-interactive default rules that don't break backwards compatibility with existing namespaces [celestia-app#1282](https://github.com/celestiaorg/celestia-app/issues/1282), [celestia-app#1161](https://github.com/celestiaorg/celestia-app/pull/1161) | ||
| - After mainnet launch, if we want to change the non-interactive default rules but retain the previous non-interactive default rules for backwards compatibility, it isn't possible to differentiate the namespaces that want to use the old rules vs the new rules. | ||
| 1. Changes to the format of a padding share. |
There was a problem hiding this comment.
Because here we would not be allowed to change the namespace ID?
Why couldn't we use the version number of the share to reflect a change in the format. That would seem most intuitive for me
There was a problem hiding this comment.
Why couldn't we use the version number of the share to reflect a change in the format. That would seem most intuitive for me
I think we could also use the version number
|
|
||
| An approach that addresses these issues is to prefix the namespace ID with version metadata. | ||
|
|
||
| ### Option A: `Namespace Version | Namespace ID` |
There was a problem hiding this comment.
How are blobs ordered now? Do they include the namespace version or just the ID (and if it is including the version is it at the start or end)
There was a problem hiding this comment.
How are blobs ordered now?
In the current implementation? Shares are ordered by namespace ID. There is no namespace version in the current implementation. There is a share version in the current implementation and that is after the namespace ID.
Ref:
| - Option B is implementable at a later time if we adopt Option A. | ||
| - It isn't immediately clear how NMT can support variable length namespaces. | ||
|
|
||
| ### Option C: `Share Version | Namespace ID` |
There was a problem hiding this comment.
I'm still for this option. (I'm aware we've already decided. I just haven't yet been convinced that there is a specific need for namespace versioning that isn't covered by share versioning and square versioning).
I'm also a big fan for putting the version number in a fixed indexed position (like the first or last byte) as opposed to the 9th byte or 17th byte
There was a problem hiding this comment.
I'm also a big fan for putting the version number in a fixed indexed position (like the first or last byte) as opposed to the 9th byte or 17th byte
FWIW the accepted proposal has a namespace version at index 0 and a share version at index 33
ADR for #1282