-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add spec for proofs #89
Add spec for proofs #89
Conversation
spec/cddl/many.cddl
Outdated
@@ -39,6 +39,11 @@ request = COSE_Sign<{ | |||
; Attributes. An optional list of request attributes defined in the spec. See | |||
; the list of all attributes in this repo. | |||
? 8 => [ * attribute ], | |||
|
|||
; Flag. When set, a proof of what was requested will be given, if possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an attribute here would be better, as:
- Attributes are meant to be optionally implemented, with clear rules when implementation is missing (request handlers reject them, response handlers ignore them) which actually makes sense here,
- Adding fields to messages is a bit like releasing a new version of HTTP. Attributes are the mechanism to enhance them (similar to HTTP headers[1]),
- Servers can advertise which attributes they support, but with this ALL servers should implement proofs, which is unreasonable.
So I'd rather have a system similar to async
support; a request attribute, a response attribute and a server attribute that indicates support for those. This way servers can advertise they support proofs, clients can ignore proofs, and if proof is requested the server should bail out as it cannot provide it, and client can then re-request without the attribute if it chooses so.
[1] there is an argument that HTTP headers are different as they are optional while attributes require handling or fail, but in this specific case it is actually beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acknowledged . . . will refactor this into a proof attribute
spec/cddl/many.cddl
Outdated
|
||
; Proof. If requested, this is the set of steps constituting a proof of existence | ||
; of what was requested in the state of the Merkle tree. | ||
; See https://github.com/liftedinit/merk/blob/develop/docs/algorithms.md#binary-format for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to put the thoughts of this document into a separate specification document and not rely on implementation specific documentation.
Note that using specific implementations is not something the spec should recommend or even mention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I can put the binary structure into a separate adoc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks! Minor changes.
@hansl is there an issue somewhere tracking this feature?
attributes/network/11_proof.adoc
Outdated
@@ -0,0 +1,32 @@ | |||
= Proof Attribute (#11) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
attributes/network/11_proof.adoc
Outdated
Interpreting these operations as acting on a stack, the first three operations listed | ||
can be interpreted as pushing data onto the stack. In the parent operation, | ||
two items are popped from the stack, and a new item with the second item as the | ||
left child of the first item is pushed onto the stack. In the child operation, | ||
two items are popped from the stack, and a new item with the first item as the right child | ||
of the second item is pushed back onto the stack. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the way they present it in https://github.com/liftedinit/merk/blob/develop/docs/algorithms.md#binary-format
Their example makes everything very clear.
|
||
; The value | ||
1 => node-value | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add EOF EOL
spec/cddl/many.cddl
Outdated
attribute = attribute-id / [attribute-id, * attribute-arg] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EOL EOF
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to reiterate this. It's nicer for diffs to have a newline at the end of a file.
I'm also okay if you want to add an .editorconfig
or .env
file to this repo.
attributes/network/11_proof.adoc
Outdated
@@ -0,0 +1,32 @@ | |||
= Proof Attribute (#11) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a link to the CDDL file? See other .adoc
for examples.
…4, and proof variants fixed to be distinguishable according to tagged array convention
node-hash = [2, bstr] | ||
|
||
; The key-value pair of a proof | ||
key-value-pair = [3, (0 => bstr, 1 => bstr)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
key-value-pair = [3, (0 => bstr, 1 => bstr)] | |
key-value-pair = [3, bstr, bstr] |
attributes/network/14_proof.adoc
Outdated
|
||
This is a uint representing the hasher to be used in constructing proofs. | ||
|
||
* 0 - merk default hash (currently blake3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should point to the Hash Scheme
section of this document. I have a feeling we'll have more than one later too, so if you want to create a new document and point to it that'd be even better.
attributes/network/14_proof.adoc
Outdated
|
||
* 0 - merk default hash (currently blake3) | ||
|
||
* 1 - TBD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need.
attributes/network/14_proof.adoc
Outdated
|
||
* 1 - TBD | ||
|
||
== Hash Scheme |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Describing a Merkle tree and how to calculate the proof is fine, but we should separate the Merkle tree part from the description of the hashing itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hansl I've moved this part to a separate doc and referenced. To clarify, is it right that the attribute id says use the hash scheme, or does it say use what merk currently uses as the hash function (blake3)?
spec/cddl/many.cddl
Outdated
attribute = attribute-id / [attribute-id, * attribute-arg] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to reiterate this. It's nicer for diffs to have a newline at the end of a file.
I'm also okay if you want to add an .editorconfig
or .env
file to this repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @MavenRain!
attributes/network/14_proof.adoc
Outdated
This is a uint representing the hasher to be used in constructing proofs. | ||
|
||
* 0 - merk default hash (currently blake3) | ||
|
||
* 1 - TBD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the attribute mandatory?
attributes/network/14_proof.adoc
Outdated
|
||
This is a uint representing the hasher to be used in constructing proofs. | ||
|
||
* 0 - merk default hash (see xref:../../spec/proof_hash_scheme.adoc.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not put any implementation detail here.
We should be able to query the server and retrieve the hashes it supports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hansl WDTY?
spec/proof_hash_scheme.adoc
Outdated
Each node contains a "kv hash", which is the hash of a prefix concatenanted with the nodes key and its value. | ||
The hash of the node is the hash of a distinct prefix, the kv hash, and the hash of each of the left and right child nodes. | ||
|
||
``` | ||
kv_hash = H(0x00, key, value) | ||
node_hash = H(0x01, kv_hash, left_child_hash, right_child_hash) | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not exactly true, as our merk
fork doesn't implement the second preimage attack mitigation, i.e., it doesn't have the 0x00
and 0x01
prefixes.
I would try to keep the specification general. Some of our users might use other storage implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments/suggestions!
attributes/response/3_proof.adoc
Outdated
@@ -0,0 +1,17 @@ | |||
= Proof Attribute (#3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
= Proof Attribute (#3) | |
= Proof Response Attribute (#3) |
attributes/response/3_proof.adoc
Outdated
|
||
== Attribute Argument | ||
|
||
This is a uint representing the hasher to be used in constructing proofs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a uint representing the hasher to be used in constructing proofs. | |
This is a `uint` representing the hasher used in constructing the proofs. |
attributes/response/3_proof.adoc
Outdated
|
||
This is a uint representing the hasher to be used in constructing proofs. | ||
|
||
* 0 - merk default hash (see xref:../../spec/proof_hash_scheme.adoc.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* 0 - merk default hash (see xref:../../spec/proof_hash_scheme.adoc.) | |
* 0 - `merk` default hash (see xref:../../spec/proof_hash_scheme.adoc.) |
@@ -0,0 +1,7 @@ | |||
= Proof Request Attribute (#3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will go here?
@@ -0,0 +1,17 @@ | |||
; Proof. If requested, this is the set of steps constituting a proof of existence of what was requested in the state of the Merkle tree. | |||
proof@response-attribute-arg = [ + ( node-hash / key-value-hash / key-value-pair / parent / child ) ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The response attribute should be a map, it should contain at least 2 values:
- the root hash, and
- the proof itself.
Add an optional block height for now, but make it a attribute-related-index.
proof@response-attribute-arg = [ + ( node-hash / key-value-hash / key-value-pair / parent / child ) ] | |
proof@response-attribute-arg = { | |
; Root application hash. | |
0 => bstr, | |
; The proof operations. | |
1 => proof, | |
; Extensible attribute related indices for extra information (implementation specific) | |
* attribute-related-index => (), | |
} | |
proof = [ + ( node-hash / key-value-hash / key-value-pair / parent / child ) ] |
And then in a separate CDDL 3_proof/0_blockchain.cddl
file, get the following in:
proof@response-attribute-arg //= {
; Block height.
[3, [0, 0]] => uint
}
spec/proof_hash_scheme.adoc
Outdated
The hash of the node is the hash of a distinct prefix, the kv hash, and the hash of each of the left and right child nodes. | ||
|
||
``` | ||
kv_hash = H(0x00, key, value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing key and value length. This is closer:
kv_hash = H(0x00, key, value) | |
kv_hash = H(0x00, key.length, key, value.length, value) |
|
||
``` | ||
kv_hash = H(0x00, key, value) | ||
node_hash = H(0x01, kv_hash, left_child_hash, right_child_hash) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the node hash does not have the lengths in the hash.
…fined in response cddl
Co-authored-by: Hans Larsen <hans@larsen.online>
Co-authored-by: Hans Larsen <hans@larsen.online>
Co-authored-by: Hans Larsen <hans@larsen.online>
No description provided.