|
|
- # ADR 026: General Merkle Proof
-
- ## Context
-
- We are using raw `[]byte` for merkle proofs in `abci.ResponseQuery`. It makes hard to handle multilayer merkle proofs and general cases. Here, new interface `ProofOperator` is defined. The users can defines their own Merkle proof format and layer them easily.
-
- Goals:
- - Layer Merkle proofs without decoding/reencoding
- - Provide general way to chain proofs
- - Make the proof format extensible, allowing thirdparty proof types
-
- ## Decision
-
- ### ProofOperator
-
- `type ProofOperator` is an interface for Merkle proofs. The definition is:
-
- ```go
- type ProofOperator interface {
- Run([][]byte) ([][]byte, error)
- GetKey() []byte
- ProofOp() ProofOp
- }
- ```
-
- Since a proof can treat various data type, `Run()` takes `[][]byte` as the argument, not `[]byte`. For example, a range proof's `Run()` can take multiple key-values as its argument. It will then return the root of the tree for the further process, calculated with the input value.
-
- `ProofOperator` does not have to be a Merkle proof - it can be a function that transforms the argument for intermediate process e.g. prepending the length to the `[]byte`.
-
- ### ProofOp
-
- `type ProofOp` is a protobuf message which is a triple of `Type string`, `Key []byte`, and `Data []byte`. `ProofOperator` and `ProofOp`are interconvertible, using `ProofOperator.ProofOp()` and `OpDecoder()`, where `OpDecoder` is a function that each proof type can register for their own encoding scheme. For example, we can add an byte for encoding scheme before the serialized proof, supporting JSON decoding.
-
- ## Status
-
- Implemented
-
- ## Consequences
-
- ### Positive
-
- - Layering becomes easier (no encoding/decoding at each step)
- - Thirdparty proof format is available
-
- ### Negative
-
- - Larger size for abci.ResponseQuery
- - Unintuitive proof chaining(it is not clear what `Run()` is doing)
- - Additional codes for registering `OpDecoder`s
|