About "The way we treat data on the blockchain is wrong — this is how it’s supposed to work"

Tokenscript Design
1

The article is here

The feedbacks from Virgil "If you want to inspect DER encodeded data, you can use openssl like this: ? I Thought cbor.io is what we were supposed to use on-chain?"

@weiwu.zhang can you please comment on Virgil's feedbacks.

2

Whence did you get that Virgil comment? It wasn't found under that Medium article.

To answer that:

  1. Like JSON, CBOR isn't deterministic (needed for signing attestations)
  2. On-chain reuse of existing X.509 certificates (e.g. orgninational identity attestations like the one our company used to have in Singapore; former ATO-issued tax-payer attestations) encoded in DER.
  3. CBOR is schema-less, which grants flexibility at the cost of size + semantic. (e.g. when you add a new field to a ticket it's unclear if the ticket issuer signed the schema to expand the dataset or just someone did it. For seriousness, imagine the newly added field is a boolean "cancelled".)

If you hold the view that CBOR is JSON friendly:

  1. TokenScript already presents attestation data to developers using JER (JSON encoding rule).

Point 1 and 3 can be fixed with extra work. For 1, someone is already drafting deterministic CBOR (to be fair to the competitions, a deterministic Protocol Buffer is being made). For 3, we can add a schema on top of a schema-less design. I just feel like to do it prudently, e.g. introduce CBOR when its deterministic alternative finalised and stood the test of time (e.g. there has been hack in X.509 using deterministic weakness before; the format was amended since).

Since 1 and 3 can be fixed with extra work, all 3 points are not a principle objection of using CBOR. However, because it's a newcomer in cryptographic engineering, arguments should be made why CBOR should be used, not why older format should be kept. I just hope TokenScript not be the first project to use CBOR formatted attestations in a critical fashion. If changes have to happen, I'd argue that a merkalised attestation format (to disässociate transactions with attestations) or one that can enable relatively smaller zero-knowledge proof is the way to go. (Currently DER / CBOR don't support stripping off a Merkle branch without invalidating the signature.)

Nothing is set in the stone and this Thursday's meeting will touch this topic & you can dial in ₋₋ your participation would be extremely valuable!