ICS 2: Consensus Verification

.gitignore

@@ -0,0 +1,2 @@
+*.swp
+*.swo

spec/ics-2-consensus-verification/README.md

@@ -0,0 +1,219 @@
+---
+
+ics: 2
+title: Consensus Verification
+stage: draft
+category: ibc-core
+requires: 23
+required-by: 3
+author: Juwoon Yun <joon@tendermint.com>, Christopher Goes <cwgoes@tendermint.com>
+created: 2019-02-25
+modified: 2019-04-02
+
+---
+
+## Synopsis
+
+This standard specifies the properties that consensus algorithms of chains implementing IBC are 
+expected to satisfy. The properties are needed for efficient and safe verification in the higher
+level protocol abstractions. The algorithm which uses these properties to verify substates of 
+another chain is referred to as a "light client".
+
+## Specification
+
+### Motivation
+
+`FullNode`s are procedures running a `Consensus`. Given a `([Transaction], Commit)`, a 
+`FullNode` can compute the result `RootOfTrust` that the `Consensus` is expected to commit on 
+with the same `[Transaction]`, if exists. 
+
+`Blockchain` defines required properties of the blockchain on the network. The implementors can 
+check whether the consensus that they are using is qualified to be connected to the network or 
+not. If not, they can modify the algorithm or wrap it with additional logic to make it 
+compatible with the specification. It also provides base layer for the protocol that the other 
+components can rely on.
+
+### Desired Properties
+
+This standard specification provides secure layer to verify other chains' canonical headers, 
+using the existing `RootOfTrust`. The higher level logics can be able to verify the substate 
+with the `AccumulatorRoot` stored in the `RootOfTrust`, which is guaranteed to be committed by 
+the other chain's consensus algorithm.
+
+* Blockchains, defined as an infinite list of `Header` starting from a genesis `RootOfTrust`, 
+are linear; no conflicting `Header`s can be both validated, thus no past accumulator roots can 
+be changed after they have been committed. Two `Header`s are conflicting when they both have the
+same height in a blockchain but are not equal.
+
+* Verifiers can verify future `Header`s using an existing `RootOfTrust`. When the verifier 
+validates it, the verified header is in the canonical blockchain.
+
+* `RootOfTrust`s contains an accumulator root (ICS23) that the downstream logic can use to 
+verify whether key-value pairs are present in the state or not.
+
+### Technical Specification
+
+#### Definitions
+
+##### Types
+
+* `RootOfTrust` is a blockchain commit which contains an accumulator root and the requisite 
+  state to verify future roots, stored in one blockchain to verify the state of the other.
+  Defined as 2-tuple `(base :: VerifierBase, root :: AccumulatorRoot)`, 
+  where
+    * `base` is a data used by `Consensus.Verifier` to verify `Header`s 
+    * `root` is the `AccumuatorRoot`, used to prove internal state
+
+* `Header` is a blockchain header which provides information to update `RootOfTrust`, 
+  submitted to one blockchain to update the stored `RootOfTrust`.
+  Defined as 3-tuple `(proof :: HeaderProof, base :: Maybe<VerifierBase>, root :: AccumulatorRoot)`,
+  where
+    * `proof` is the commit proof used by `Consensus.Verifier` to be verified
+    * `base` is the new verify, if needed to be updated
+    * `root` is the new `AccumulatorRoot` which will replace the existing one
+
+* `Consensus` is a blockchain consensus algorithm which generates valid `Header`s.
+  Defined as 2-tuple `(commit :: RootOfTrust -> [Message] -> Header, verify :: RootOfTrust -> 
+  Header -> Error|RootOfTrust)` where
+    * `commit` is the header generation function from the base `RootOfTrust` and arbitrary messages
+    * `verify` is the verifier, proves `Header.proof` and returns the updated `RootOfTrust`
+
+* `Blockchain` is defined as 3-tuple `(cons :: Consensus, genesis :: RootOfTrust, 
+  headers :: [Header])`, where
+    * `cons` is the Consensus algorithm that is running the blockchain
+    * `genesis` is the genesis `RootOfTrust`
+    * `headers` is the list of header generated by `c`, starting from the `gen`. In detail, 
+      `B.hs` is defined as `B.hs = fold(B.c, zip(B.gen:B.hs, msgs))` for arbitrary `msgs` 
+      in `[Message]` 
+      // XXX: make it readable
+
+* `update` is a helper function using `Consensus.verify` to update the existing 
+  `RootOfTrust`, defined as
+
+```
+function update(cons :: Consensus, rot :: RootOfTrust, h :: Header) returns (Error|RootOfTrust) {
+    if cons.verify(rot, h):
+        if h.base != Nothing:
+            return RootOfTrust(h.base, h.root)
+        else:
+            return RoofOfTrust(rot.base, h.root)
+    else:
+        return Error  
+
+}
+``` 
+
+##### Functions
+
+* `Height :: Blockchain -> Header -> Uint` returns the position of the header in the
+  Blockchain's header list.
+
+#### Requirements
+
+Consensus verification requires the following accumulator primitives with datastructures and
+properties as defined in ICS23:
+
+* `AccumulatorRoot`
+
+#### Subprotocols
+
+##### Verifier
+
+The verifier algorithm checks that new `Header`s were in fact generated by a blockchain. It is expected to verify a `Header` 
+efficiently; far more efficiently than replaying `Consensus` logic for the given parent `Header` and the
+list of network messages, idealy in O(1) time. `Header.p` provides the proof that the verifier can use. 
+Verifiers assume the following properties will be satisfied for the `Header`s:
+
+1. `Header`s have no more than one direct child
+
+* Satisfied if: deterministic safety
+* Possible violation scenario: validator double signing, chain reorganization (Nakamoto consensus)
+
+2. `Header`s eventually have at least one direct child
+
+* Satisfied if: liveness, light-client verifier continuity
+* Possible violation scenario: synchronized halt, incompatible hard fork
+
+3. `Header`s are generated from the `Consensus`, which ensures valid transition of the state
+
+* Satisfied if: correct block generation & state machine
+* Possible violation scenario: invariant break, validator cartel
+
+##### Accumulator Root
+
+`RootOfTrust` contains an accumulator root, which identifies the whole state of the 
+corresponding blockchain at the point of time that the commit is generated. It is expected that 
+the verifying inclusion or exclusion of certain data in the accumulator can be done efficiently. See 
+ICS23 for the details about the `AccumulatorRoot`s.
+
+##### Consensus 
+
+`Consensus` is a blockchain protocol which actually generates a list of `Header`s from the latest
+state and the incoming transactions. While the chains on the network does not directly proving the 
+consensus process, it is expected that the consensus algorithms will generate valid `Header`s.
+
+### Example Implementation
+
+An example blockchain `B` runs on a single operator consensus algorithm, called `Op`. If a 
+block is signed by the operator, then it is valid. The operator signing key can be changed while
+the chain is running. In that case, the new header stores the updated pubkey. 
+
+`H` contains `LogStore`, which is a list with type of `[bytes]`. The whole state is serialized 
+and stored as `AccumulatorRoot`
+
+#### Consensus
+
+`B` is defined as `(Op, Gen, [H])`. `B` satisfies `Blockchain`:
+
+```
+TX = Append(bytes) or ChangeOperator(Pubkey)
+
+function commit(h :: H, txs :: [TX]) returns C {
+    store := c.AccumulatorRoot
+    newpubkey := c.Pubkey
+
+    foreach tx in txs:
+        case Append(data): 
+            state = state + data
+        case ChangeOperator(pubkey): 
+            newpubkey = pubkey
+
+    result := H(newpubkey, store)
+    sig := Privkey.Sign(result)
+    return C(sig, result)
+}
+
+function verify(rot :: ROT, h :: H) returns rot.Pubkey.VerifySignature(h.Sig)
+
+Op = (commit, verify)
+
+Gen = ROT(InitialPubkey, EmptyLogStore)
+```
+
+The `[H]` is generated by `Op.commit`, recursivly applied on the genesis and its successors.
+The `[TX]` applied on the `Op.commit` can be any value, but when the `B` is instantiated 
+in the real world, the `[TX]` is fixed to a single value to satisfy consensus properties. In 
+this example, we assume that it is enforced by a legal authority.
+
+#### RootOfTrust
+
+Type `ROT` is defined as `(Pubkey, LogStore)`. `ROT` satisfies `RootOfTrust`:
+
+```
+function ROT.base() returns ROT.Pubkey
+function ROT.root() returns ROT.LogStore
+```
+
+#### Header
+
+Type `H` is defined as `(Sig, Maybe<Pubkey>, LogStore)`. `H` satisfies `Header`:
+
+```
+function H.proof() returns H.Sig
+function H.base() returns H.Pubkey
+function H.root() returns H.LogStore
+```
+
+## History 
+
+March 5th 2019: Initial ICS 2 draft finished and submitted as a PR