You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

141 lines
6.2 KiB

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