Skip to content
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

Merged
merged 37 commits into from
Feb 22, 2023
Merged

Conversation

MavenRain
Copy link
Contributor

No description provided.

@MavenRain MavenRain requested review from hansl and fmorency January 3, 2023 15:31
@MavenRain MavenRain marked this pull request as ready for review January 3, 2023 16:15
@@ -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.
Copy link
Contributor

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.

Copy link
Contributor Author

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


; 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
Copy link
Contributor

@hansl hansl Jan 3, 2023

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.

Copy link
Contributor Author

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

Copy link
Contributor

@fmorency fmorency left a 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?

@@ -0,0 +1,32 @@
= Proof Attribute (#11)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This attribute number is already taken in #73, and @hansl has taken #73 in #86.

You should probably use 14!

Comment on lines 27 to 32
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.
Copy link
Contributor

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
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add EOF EOL

attribute = attribute-id / [attribute-id, * attribute-arg]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EOL EOF

Copy link
Contributor

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.

@@ -0,0 +1,32 @@
= Proof Attribute (#11)
Copy link
Contributor

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.

node-hash = [2, bstr]

; The key-value pair of a proof
key-value-pair = [3, (0 => bstr, 1 => bstr)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
key-value-pair = [3, (0 => bstr, 1 => bstr)]
key-value-pair = [3, bstr, bstr]

@MavenRain MavenRain requested review from fmorency and hansl January 5, 2023 01:59

This is a uint representing the hasher to be used in constructing proofs.

* 0 - merk default hash (currently blake3)
Copy link
Contributor

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.


* 0 - merk default hash (currently blake3)

* 1 - TBD
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need.


* 1 - TBD

== Hash Scheme
Copy link
Contributor

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.

Copy link
Contributor Author

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)?

attribute = attribute-id / [attribute-id, * attribute-arg]
Copy link
Contributor

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.

Copy link
Contributor

@fmorency fmorency left a 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 Show resolved Hide resolved
Comment on lines 9 to 13
This is a uint representing the hasher to be used in constructing proofs.

* 0 - merk default hash (currently blake3)

* 1 - TBD
Copy link
Contributor

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 Show resolved Hide resolved
attributes/network/14_proof.adoc Outdated Show resolved Hide resolved

This is a uint representing the hasher to be used in constructing proofs.

* 0 - merk default hash (see xref:../../spec/proof_hash_scheme.adoc.)
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmorency I believe this contradicts what @hansl just requested.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hansl WDTY?

attributes/network/cddl/14_proof.cddl Outdated Show resolved Hide resolved
Comment on lines 4 to 10
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)
```
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmorency My understanding is that we're to use the attribute-arg to allow for the ability to change the implementation, and this describes the default implementation. Also, I believe @hansl intends for us to incorporate the prefix changes that are currently in the upstream repo.

@MavenRain MavenRain requested a review from hansl January 6, 2023 18:20
@MavenRain MavenRain requested a review from fmorency January 10, 2023 16:45
Copy link
Contributor

@fmorency fmorency left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments/suggestions!

@@ -0,0 +1,17 @@
= Proof Attribute (#3)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
= Proof Attribute (#3)
= Proof Response Attribute (#3)


== Attribute Argument

This is a uint representing the hasher to be used in constructing proofs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.


This is a uint representing the hasher to be used in constructing proofs.

* 0 - merk default hash (see xref:../../spec/proof_hash_scheme.adoc.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 0 - merk default hash (see xref:../../spec/proof_hash_scheme.adoc.)
* 0 - `merk` default hash (see xref:../../spec/proof_hash_scheme.adoc.)

attributes/network/cddl/14_proof.cddl Outdated Show resolved Hide resolved
@@ -0,0 +1,7 @@
= Proof Request Attribute (#3)
Copy link
Contributor

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 ) ]
Copy link
Contributor

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:

  1. the root hash, and
  2. the proof itself.

Add an optional block height for now, but make it a attribute-related-index.

Suggested change
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
}

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)
Copy link
Contributor

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:

Suggested change
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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Contributor Author

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.

@MavenRain MavenRain requested a review from hansl January 14, 2023 00:58
attributes/network/14_proof.adoc Outdated Show resolved Hide resolved
attributes/network/14_proof.adoc Outdated Show resolved Hide resolved
attributes/network/14_proof.adoc Outdated Show resolved Hide resolved
MavenRain and others added 3 commits February 22, 2023 12:28
Co-authored-by: Hans Larsen <hans@larsen.online>
Co-authored-by: Hans Larsen <hans@larsen.online>
Co-authored-by: Hans Larsen <hans@larsen.online>
@MavenRain MavenRain requested a review from hansl February 22, 2023 20:29
@MavenRain MavenRain merged commit 9f670fb into many-protocol:main Feb 22, 2023
@MavenRain MavenRain deleted the proof-request-response branch February 22, 2023 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants