CIP-0021: Canonical CBOR serialisation #101
Conversation
|
|
||
| The order of types is based on the CBOR major type’s 3 bit header identificator: | ||
|
|
||
| 1. unsigned integer - major type 0 |
There was a problem hiding this comment.
This ordering based on the 3 bit header would result in positive numbers being ordered before negative numbers which doesn't seem too intuitive and it might add unnecessary logic to the ordering. Perhaps the ordering should simply be something like: First come the number types ordered by their numerical values (regardless of their type) and then the byte strings and the text strings.
| 2. negative integer - major type 1 | ||
| 3. byte string - major type 2 | ||
| 4. text string - major type 3 | ||
| 5. floating-point numbers - major type 7 |
There was a problem hiding this comment.
Will there ever be a need for placing floating-point numbers into a map? Perhaps there's a general consensus to avoid floating-point numbers in CBOR? (see pool registration certificate margin)
|
|
||
| I.e. first come the uints, then the ints, byte strings, text strings and floating-point numbers. | ||
|
|
||
| Arrays, maps and tagged items are left out of this specification as including them might unnecessarily complicate the specification or its implementation. Also, these elements aren’t currently used as keys in maps and are unlikely to be used in the future. |
There was a problem hiding this comment.
We decided to leave arrays, maps and tagged items out of the spec, but there might a use case for them - especially tagged items. Is this perhaps somehow implemented in cardano-cli? How would cardano-cli handle serialising a map with tags as keys? Perhaps @dcoutts you might have some pointers on how to deal with this?
|
|
||
| ### Keys with mixed types | ||
|
|
||
| We mustn’t forget that the CBOR map keys can be of different types. The type ordering can be chosen arbitrarily but it seems most natural to choose the ordering based on the CBOR types’ 3 bit header identificator. |
There was a problem hiding this comment.
I don't really feel strongly about any of those arguments. Since there already exists a specification for producing canonical CBOR serialization, coming up with a new one does not sound to me like a good idea?
The main argument seems to be that it is "most natural to choose ordering based on the CBOR types". It certainly is appealing to the human brain but encoded data are processed by programs anyway. How does the proposal makes it simpler for many applications 🤔 ?
|
Closing this one as the revised version (#107) has changed significantly and is oriented more towards HW wallets. |
A CIP defining canonical CBOR serialisation for Cardano transactions. The resulting format is based on the needs of HW wallets and Slack discussions with @dcoutts.
Nothing is set in stone, this PR should mainly spark discussion on the topic of CBOR canonicalisation so we can agree on a format.
Open questions can be found in the comments.