From 2d726a620ba1e8e64ee21d7d686e7a594567f806 Mon Sep 17 00:00:00 2001
From: Joon <torecursedivine@gmail.com>
Date: Sat, 6 Oct 2018 12:44:53 +0900
Subject: [PATCH] add adr (#2553)

---
 .../adr-026-general-merkle-proof.md           | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 docs/architecture/adr-026-general-merkle-proof.md

diff --git a/docs/architecture/adr-026-general-merkle-proof.md b/docs/architecture/adr-026-general-merkle-proof.md
new file mode 100644
index 000000000..af81947cb
--- /dev/null
+++ b/docs/architecture/adr-026-general-merkle-proof.md
@@ -0,0 +1,47 @@
+# 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
+
+## 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