github.com/pokt-network/tendermint@v0.32.11-0.20230426215212-59310158d3e9/docs/architecture/adr-044-lite-client-with-weak-subjectivity.md (about)

     1  # ADR 044: Lite Client with Weak Subjectivity
     2  
     3  ## Changelog
     4  * 13-07-2019: Initial draft
     5  * 14-08-2019: Address cwgoes comments
     6  
     7  ## Context
     8  
     9  The concept of light clients was introduced in the Bitcoin white paper. It
    10  describes a watcher of distributed consensus process that only validates the
    11  consensus algorithm and not the state machine transactions within.
    12  
    13  Tendermint light clients allow bandwidth & compute-constrained devices, such as smartphones, low-power embedded chips, or other blockchains to
    14  efficiently verify the consensus of a Tendermint blockchain. This forms the
    15  basis of safe and efficient state synchronization for new network nodes and
    16  inter-blockchain communication (where a light client of one Tendermint instance
    17  runs in another chain's state machine).
    18  
    19  In a network that is expected to reliably punish validators for misbehavior
    20  by slashing bonded stake and where the validator set changes
    21  infrequently, clients can take advantage of this assumption to safely
    22  synchronize a lite client without downloading the intervening headers.
    23  
    24  Light clients (and full nodes) operating in the Proof Of Stake context need a
    25  trusted block height from a trusted source that is no older than 1 unbonding
    26  window plus a configurable evidence submission synchrony bound. This is called “weak subjectivity”.
    27  
    28  Weak subjectivity is required in Proof of Stake blockchains because it is
    29  costless for an attacker to buy up voting keys that are no longer bonded and
    30  fork the network at some point in its prior history. See Vitalik’s post at
    31  [Proof of Stake: How I Learned to Love Weak
    32  Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/).
    33  
    34  Currently, Tendermint provides a lite client implementation in the
    35  [lite](https://github.com/tendermint/tendermint/tree/master/lite) package. This
    36  lite client implements a bisection algorithm that tries to use a binary search
    37  to find the minimum number of block headers where the validator set voting
    38  power changes are less than < 1/3rd. This interface does not support weak
    39  subjectivity at this time. The Cosmos SDK also does not support counterfactual
    40  slashing, nor does the lite client have any capacity to report evidence making
    41  these systems *theoretically unsafe*.
    42  
    43  NOTE: Tendermint provides a somewhat different (stronger) light client model
    44  than Bitcoin under eclipse, since the eclipsing node(s) can only fool the light
    45  client if they have two-thirds of the private keys from the last root-of-trust.
    46  
    47  ## Decision
    48  
    49  ### The Weak Subjectivity Interface
    50  
    51  Add the weak subjectivity interface for when a new light client connects to the
    52  network or when a light client that has been offline for longer than the
    53  unbonding period connects to the network. Specifically, the node needs to
    54  initialize the following structure before syncing from user input:
    55  
    56  ```
    57  type TrustOptions struct {
    58      // Required: only trust commits up to this old.
    59      // Should be equal to the unbonding period minus some delta for evidence reporting.
    60      TrustPeriod time.Duration `json:"trust-period"`
    61  
    62      // Option 1: TrustHeight and TrustHash can both be provided
    63      // to force the trusting of a particular height and hash.
    64      // If the latest trusted height/hash is more recent, then this option is
    65      // ignored.
    66      TrustHeight int64  `json:"trust-height"`
    67      TrustHash   []byte `json:"trust-hash"`
    68  
    69      // Option 2: Callback can be set to implement a confirmation
    70      // step if the trust store is uninitialized, or expired.
    71      Callback func(height int64, hash []byte) error
    72  }
    73  ```
    74  
    75  The expectation is the user will get this information from a trusted source
    76  like a validator, a friend, or a secure website. A more user friendly
    77  solution with trust tradeoffs is that we establish an https based protocol with
    78  a default end point that populates this information. Also an on-chain registry
    79  of roots-of-trust (e.g. on the Cosmos Hub) seems likely in the future.
    80  
    81  ### Linear Verification
    82  
    83  The linear verification algorithm requires downloading all headers
    84  between the `TrustHeight` and the `LatestHeight`. The lite client downloads the
    85  full header for the provided `TrustHeight` and then proceeds to download `N+1`
    86  headers and applies the [Tendermint validation
    87  rules](https://docs.tendermint.com/master/spec/blockchain/blockchain.html#validation)
    88  to each block.
    89  
    90  ### Bisecting Verification
    91  
    92  Bisecting Verification is a more bandwidth and compute intensive mechanism that
    93  in the most optimistic case requires a light client to only download two block
    94  headers to come into synchronization.
    95  
    96  The bisection algorithm proceeds in the following fashion. The client downloads
    97  and verifies the full block header for `TrustHeight` and then  fetches
    98  `LatestHeight` blocker header. The client then verifies the `LatestHeight`
    99  header. Finally the client attempts to verify the `LatestHeight` header with
   100  voting powers taken from `NextValidatorSet` in the `TrustHeight` header. This
   101  verification will succeed if the validators from `TrustHeight` still have > 2/3
   102  +1 of voting power in the `LatestHeight`. If this succeeds, the client is fully
   103  synchronized. If this fails, then following Bisection Algorithm should be
   104  executed.
   105  
   106  The Client tries to download the block at the mid-point block between
   107  `LatestHeight` and `TrustHeight` and attempts that same algorithm as above
   108  using `MidPointHeight` instead of `LatestHeight` and a different threshold -
   109  1/3 +1 of voting power for *non-adjacent headers*. In the case the of failure,
   110  recursively perform the `MidPoint` verification until success then start over
   111  with an updated `NextValidatorSet` and `TrustHeight`.
   112  
   113  If the client encounters a forged header, it should submit the header along
   114  with some other intermediate headers as the evidence of misbehavior to other
   115  full nodes. After that, it can retry the bisection using another full node. An
   116  optimal client will cache trusted headers from the previous run to minimize
   117  network usage.
   118  
   119  ---
   120  
   121  Check out the formal specification
   122  [here](https://docs.tendermint.com/master/spec/consensus/light-client.html).
   123  
   124  ## Status
   125  
   126  Accepted.
   127  
   128  ## Consequences
   129  
   130  ### Positive
   131  
   132  * light client which is safe to use (it can go offline, but not for too long)
   133  
   134  ### Negative
   135  
   136  * complexity of bisection
   137  
   138  ### Neutral
   139  
   140  * social consensus can be prone to errors (for cases where a new light client
   141    joins a network or it has been offline for too long)