[ADR -44] Lite Client with Weak Subjectivity (#3795)

* Initiat commit of lite client with
with weak subjectivity ADR

* Apply suggestions from code review

Co-Authored-By: Marko <marbar3778@yahoo.com>

* Update docs/architecture/adr-044-lite-client-with-weak-subjectivity.md

Co-Authored-By: Christopher Goes <cwgoes@pluranimity.org>

* Apply suggestions from code review

Co-Authored-By: Christopher Goes <cwgoes@pluranimity.org>

* Apply suggestions from code review

Co-Authored-By: Anca Zamfir <ancazamfir@users.noreply.github.com>

* fix typo and format the code block

* address cwgoes comments

* add Positive/Negative points

* change status to accepted

* Apply suggestions from code review

Co-Authored-By: Christopher Goes <cwgoes@pluranimity.org>

* link the spec and explain headers caching

docs/architecture/adr-044-lite-client-with-weak-subjectivity.md

@@ -0,0 +1,141 @@
+# ADR 044: Lite Client with Weak Subjectivity
+
+## Changelog
+* 13-07-2019: Initial draft
+* 14-08-2019: Address cwgoes comments
+
+## Context
+
+The concept of light clients was introduced in the Bitcoin white paper. It
+describes a watcher of distributed consensus process that only validates the
+consensus algorithm and not the state machine transactions within.
+
+Tendermint light clients allow bandwidth & compute-constrained devices, such as smartphones, low-power embedded chips, or other blockchains to
+efficiently verify the consensus of a Tendermint blockchain. This forms the
+basis of safe and efficient state synchronization for new network nodes and
+inter-blockchain communication (where a light client of one Tendermint instance
+runs in another chain's state machine).
+
+In a network that is expected to reliably punish validators for misbehavior
+by slashing bonded stake and where the validator set changes
+infrequently, clients can take advantage of this assumption to safely
+synchronize a lite client without downloading the intervening headers.
+
+Light clients (and full nodes) operating in the Proof Of Stake context need a
+trusted block height from a trusted source that is no older than 1 unbonding
+window plus a configurable evidence submission synchrony bound. This is called “weak subjectivity”.
+
+Weak subjectivity is required in Proof of Stake blockchains because it is
+costless for an attacker to buy up voting keys that are no longer bonded and
+fork the network at some point in its prior history. See Vitalik’s post at
+[Proof of Stake: How I Learned to Love Weak
+Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/).
+
+Currently, Tendermint provides a lite client implementation in the
+[lite](https://github.com/tendermint/tendermint/tree/master/lite) package. This
+lite client implements a bisection algorithm that tries to use a binary search
+to find the minimum number of block headers where the validator set voting
+power changes are less than < 1/3rd. This interface does not support weak
+subjectivity at this time. The Cosmos SDK also does not support counterfactual
+slashing, nor does the lite client have any capacity to report evidence making
+these systems *theoretically unsafe*.
+
+NOTE: Tendermint provides a somewhat different (stronger) light client model
+than Bitcoin under eclipse, since the eclipsing node(s) can only fool the light
+client if they have two-thirds of the private keys from the last root-of-trust.
+
+## Decision
+
+### The Weak Subjectivity Interface
+
+Add the weak subjectivity interface for when a new light client connects to the
+network or when a light client that has been offline for longer than the
+unbonding period connects to the network. Specifically, the node needs to
+initialize the following structure before syncing from user input:
+
+```
+type TrustOptions struct {
+    // Required: only trust commits up to this old.
+    // Should be equal to the unbonding period minus some delta for evidence reporting.
+    TrustPeriod time.Duration `json:"trust-period"`
+
+    // Option 1: TrustHeight and TrustHash can both be provided
+    // to force the trusting of a particular height and hash.
+    // If the latest trusted height/hash is more recent, then this option is
+    // ignored.
+    TrustHeight int64  `json:"trust-height"`
+    TrustHash   []byte `json:"trust-hash"`
+
+    // Option 2: Callback can be set to implement a confirmation
+    // step if the trust store is uninitialized, or expired.
+    Callback func(height int64, hash []byte) error
+}
+```
+
+The expectation is the user will get this information from a trusted source
+like a validator, a friend, or a secure website. A more user friendly
+solution with trust tradeoffs is that we establish an https based protocol with
+a default end point that populates this information. Also an on-chain registry
+of roots-of-trust (e.g. on the Cosmos Hub) seems likely in the future.
+
+### Linear Verification
+
+The linear verification algorithm requires downloading all headers
+between the `TrustHeight` and the `LatestHeight`. The lite client downloads the
+full header for the provided `TrustHeight` and then proceeds to download `N+1`
+headers and applies the [Tendermint validation
+rules](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#validation)
+to each block.
+
+### Bisecting Verification
+
+Bisecting Verification is a more bandwidth and compute intensive mechanism that
+in the most optimistic case requires a light client to only download two block
+headers to come into synchronization.
+
+The bisection algorithm proceeds in the following fashion. The client downloads
+and verifies the full block header for `TrustHeight` and then  fetches
+`LatestHeight` blocker header. The client then verifies the `LatestHeight`
+header. Finally the client attempts to verify the `LatestHeight` header with
+voting powers taken from `NextValidatorSet` in the `TrustHeight` header. This
+verification will succeed if the validators from `TrustHeight` still have > 2/3
++1 of voting power in the `LatestHeight`. If this succeeds, the client is fully
+synchronized. If this fails, then following Bisection Algorithm should be
+executed.
+
+The Client tries to download the block at the mid-point block between
+`LatestHeight` and `TrustHeight` and attempts that same algorithm as above
+using `MidPointHeight` instead of `LatestHeight` and a different threshold -
+1/3 +1 of voting power for *non-adjacent headers*. In the case the of failure,
+recursively perform the `MidPoint` verification until success then start over
+with an updated `NextValidatorSet` and `TrustHeight`.
+
+If the client encounters a forged header, it should submit the header along
+with some other intermediate headers as the evidence of misbehavior to other
+full nodes. After that, it can retry the bisection using another full node. An
+optimal client will cache trusted headers from the previous run to minimize
+network usage.
+
+---
+
+Check out the formal specification
+[here](https://github.com/tendermint/tendermint/blob/master/docs/spec/consensus/light-client.md).
+
+## Status
+
+Accepted.
+
+## Consequences
+
+### Positive
+
+* light client which is safe to use (it can go offline, but not for too long)
+
+### Negative
+
+* complexity of bisection
+
+### Neutral
+
+* social consensus can be prone to errors (for cases where a new light client
+  joins a network or it has been offline for too long)