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

zmanian · 2019-07-13T22:55:58Z

ADR for Lite Client with Weak Subjectivity ADR.

Implementation in #3577

with weak subjectivity ADR

codecov-io · 2019-07-13T23:01:44Z

Codecov Report

Merging #3795 into master will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #3795      +/-   ##
=========================================
- Coverage   65.65%   65.6%   -0.05%     
=========================================
  Files         217     217              
  Lines       18198   18202       +4     
=========================================
- Hits        11948   11942       -6     
- Misses       5382    5389       +7     
- Partials      868     871       +3

Impacted Files	Coverage Δ
privval/signer_server.go	`95.65% <0%> (-4.35%)`	⬇️
consensus/ticker.go	`91.66% <0%> (-4.17%)`	⬇️
consensus/metrics.go	`15.17% <0%> (-1.83%)`	⬇️
lite/dynamic_verifier.go	`66.96% <0%> (-1.37%)`	⬇️
blockchain/v0/pool.go	`80% <0%> (-0.99%)`	⬇️
consensus/reactor.go	`76.78% <0%> (-0.47%)`	⬇️
p2p/pex/pex_reactor.go	`83.76% <0%> (+1.73%)`	⬆️
privval/signer_listener_endpoint.go	`89.13% <0%> (+2.17%)`	⬆️
privval/signer_endpoint.go	`84% <0%> (+5.33%)`	⬆️

tac0turtle

Quick run through, will do another tomorrow.

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

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

melekes

Great post! However, the choice of the concrete data structures (Provider, UpdatingProvider, ConcurrentProvider, DBProvider, MultiProvider) is still not clear to me. Like why there are so many of them? Could not we just expose two? One for linear verification and one for bisecting verification OR even make this an option. Thanks!

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

cwgoes

Nice! Should we combine this / #3796 / #3710?

I think we can offload more work to the full node in the bisection algorithm.

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

cwgoes · 2019-07-15T10:26:30Z

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

+Changelog:
+- 13-07-2019: Initial Draft
+## 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.


Two things to note:

Light clients are expected to agree with full nodes on the canonical chain

Tendermint provides a somewhat different (stronger) light client model 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.

cwgoes · 2019-07-15T10:27:53Z

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

+
+Tendermint light clients allow light weight devices and other blockchains to efficiently verify the consensus of a Tendermint blockchain. This forms the basic of safe and efficient state synchronization for new network nodes and InterBlockchain Communication.
+
+In a network that is expected to reliably punish validators for misbehavior through punishments or where the validator set is largely trusted and changes infrequently, clients can take advantage of this assumption to safely synchronize a lite client without downloading the intervening headers.


"largely trusted" is a bit vague. I think both conditions are necessary - only if misbehaviour is punished and validator set changes are infrequent can a light client skip most of the headers. Note also that the state machine can enforce limits on validator set liquidity, which might be useful to provide tighter efficiency/safety bounds.

cwgoes · 2019-07-15T10:28:39Z

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

+
+In a network that is expected to reliably punish validators for misbehavior through punishments or where the validator set is largely trusted and 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 unbending window. This is called “weak subjectivity”


We should explain why one unbonding window (and I think it should be one unbonding window minus delta, where delta is a parameter set according to the expected synchrony bounds for the light client to be able to report evidence)

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

cwgoes · 2019-07-15T10:31:09Z

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

+```
+
+## Linear Verification
+The linear verification of the light client 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. 


Should we combine https://github.com/tendermint/tendermint/pull/3796/files here?

cwgoes · 2019-07-15T10:31:41Z

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

+
+## 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. 


It's a less bandwidth and compute-intensive mechanism, right?

We can bound the number of headers precisely if we make assumptions about validator set liquidity.

cwgoes · 2019-07-15T10:32:53Z

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

+
+The Bisection algorithm proceeds in the following fashion. The client downloads  and verifies the full block header for `TrustHeight` and then  fetches  `LastestHeight` blocker header.  The client then verifies the `LatestHeight` header.  Finally the client attempts to verify the `LatestHeight` header with voting powers taken from `NextValdiatorSet` in the `TrustHeight` header. This will verification will succeed if that 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 followed.
+
+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`. In the case the of failure, recursively perform the `MidPoint` verification until success then start over with an updated `NextValidatorSet` and `TrustHeight`.


I would note that it's safe to ask the full node to provide the specific headers that the client needs, given the root of trust height that it has. Should we do that instead? The full node has to track a bit more, but further reduces bandwidth / compute for the light client.

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

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

milosevic · 2019-07-15T18:28:23Z

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

+
+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  `LastestHeight` blocker header.  The client then verifies the `LatestHeight` header.  Finally the client attempts to verify the `LatestHeight` header with voting powers taken from `NextValdiatorSet` in the `TrustHeight` header. This will verification will succeed if that 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 followed.


Note that +2/3 in the new validator set is not sufficient to establish trust of the new validator set as total voting power of new validators and potential adversary set of the old set could be bigger than +1/3 of total voting power. See #3710.

So it seems like we should say that in order for bisection to take place, the total voting power of the new block must be greater or equal to the total voting power of the last trusted block to prevent this attack correct?

I think it's more complex than that. Total voting power of new validators together with 1/3 of voting power of old validators that are also present in new validator set must be in total at most 1/3 of voting power in the new val set.

Okay here is my proposed check.

After current checks for if LatestHeight is valid in it's own terms, if LatestHeight is valid in terms of TrustedHeight.NextValidatorSet we compute the following. Take the sum of the following, for each validator abs((LatestHeightVotingPower/LatestHeightTotalPower)-TrustedHeightVotingPower/TrustedHeightTotalPower)). if this value is greater than 1/3rd, fail for the height.

I'm still somewhat split if we want to have this check in the presence of counterfactual slashing.

It does confuse the incentive layers a bit, but counterfactual slashing does ensure that any attack using this kind of change of voting powers is still slashable.

I still have trouble to see link between counterfactual slashing and the checks about validator power change, i.e., how we can get rid of checks in the presence of counterfactual slashing.

So an attacker who wants to exploit this vulnerability needs signatures from 2/3rd from the TrustedSet. in attack these signatures are either equivocations or counterfactual signatures.

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

jaekwon · 2019-07-22T23:05:27Z

Great post! However, the choice of the concrete data structures (Provider, UpdatingProvider, ConcurrentProvider, DBProvider, MultiProvider) is still not clear to me. Like why there are so many of them? Could not we just expose two? One for linear verification and one for bisecting verification OR even make this an option. Thanks!

I think it just needs a bit of documentation, but otherwise that the separation potentially makes things easier to maintain and understand. For example, it isn't necessary to know how a Provider works underneath the hood to understand how ConcurrentProvider works. Similarly, I like to add caching as a layer, as MultiProvider lets you do w/ DBProviders. Each is solving an orthogonal concern, and can get composed. Otherwise we'd eventually end up with two very-complicated struct implementations that would otherwise be hard to tease out (e.g. not-same-but-similar criticism as Tendermint's consensus state not being split out). But not all of these need to be exposed to the user... It would be sufficient to keep the internal unexposed implementation based on these components, but only expose things that external users need to know.

cwgoes

A few more minor suggestions, and I think it would be nice to link this to the formal bisection safety spec (once merged, or leave a pointer to be linked in the future).

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

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

melekes · 2019-08-14T18:43:02Z

@cwgoes: thanks for the thorough review 👍

Initiat commit of lite client with

3e0b211

with weak subjectivity ADR

zmanian requested review from ebuchman, melekes and xla as code owners July 13, 2019 22:55

zmanian requested review from ancazamfir, brapse, cwgoes, tac0turtle, mossid and jackzampolin July 13, 2019 22:56

tac0turtle changed the title ~~Lite Client with Weak Subjectivity ADR~~ [ADR -44] Lite Client with Weak Subjectivity Jul 14, 2019

tac0turtle reviewed Jul 14, 2019

View reviewed changes

Apply suggestions from code review

992b957

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

melekes approved these changes Jul 15, 2019

View reviewed changes

cwgoes suggested changes Jul 15, 2019

View reviewed changes

zmanian and others added 2 commits July 15, 2019 08:18

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

7a60ce0

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

Apply suggestions from code review

fdc2daa

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

ancazamfir reviewed Jul 15, 2019

View reviewed changes

docs/architecture/adr-044-lite-client-with-weak-subjectivity.md Outdated Show resolved Hide resolved

milosevic reviewed Jul 15, 2019

View reviewed changes

zmanian and others added 2 commits July 15, 2019 13:15

Apply suggestions from code review

65167f0

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

fix typo and format the code block

23d9f92

tac0turtle and others added 4 commits August 7, 2019 15:05

Merge branch 'master' into zaki/liteclientADR

4233c2e

address cwgoes comments

860c94d

add Positive/Negative points

d56b993

change status to accepted

8e9ec8c

melekes approved these changes Aug 14, 2019

View reviewed changes

cwgoes suggested changes Aug 14, 2019

View reviewed changes

Apply suggestions from code review

a565b6f

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

link the spec and explain headers caching

bfe3e73

melekes requested a review from cwgoes August 15, 2019 06:49

cwgoes approved these changes Aug 15, 2019

View reviewed changes

Merge branch 'master' into zaki/liteclientADR

f6ee735

tac0turtle merged commit 7b101ab into master Aug 15, 2019

tac0turtle deleted the zaki/liteclientADR branch August 15, 2019 09:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

zmanian commented Jul 13, 2019

codecov-io commented Jul 13, 2019 •

edited

tac0turtle left a comment

melekes left a comment

cwgoes left a comment

cwgoes Jul 15, 2019

cwgoes Jul 15, 2019

cwgoes Jul 15, 2019

cwgoes Jul 15, 2019

cwgoes Jul 15, 2019

cwgoes Jul 15, 2019

milosevic Jul 15, 2019

zmanian Jul 15, 2019

milosevic Jul 16, 2019

zmanian Jul 16, 2019

zmanian Jul 17, 2019

milosevic Jul 17, 2019

zmanian Jul 17, 2019

jaekwon commented Jul 22, 2019 •

edited

cwgoes left a comment •

edited

melekes commented Aug 14, 2019


		Tendermint light clients allow light weight devices and other blockchains to efficiently verify the consensus of a Tendermint blockchain. This forms the basic of safe and efficient state synchronization for new network nodes and InterBlockchain Communication.

		In a network that is expected to reliably punish validators for misbehavior through punishments or where the validator set is largely trusted and changes infrequently, clients can take advantage of this assumption to safely synchronize a lite client without downloading the intervening headers.


		In a network that is expected to reliably punish validators for misbehavior through punishments or where the validator set is largely trusted and 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 unbending window. This is called “weak subjectivity”


		## 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 `LastestHeight` blocker header. The client then verifies the `LatestHeight` header. Finally the client attempts to verify the `LatestHeight` header with voting powers taken from `NextValdiatorSet` in the `TrustHeight` header. This will verification will succeed if that 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 followed.

		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`. In the case the of failure, recursively perform the `MidPoint` verification until success then start over with an updated `NextValidatorSet` and `TrustHeight`.

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

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

Conversation

zmanian commented Jul 13, 2019

codecov-io commented Jul 13, 2019 • edited

Codecov Report

tac0turtle left a comment

Choose a reason for hiding this comment

melekes left a comment

Choose a reason for hiding this comment

cwgoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaekwon commented Jul 22, 2019 • edited

cwgoes left a comment • edited

Choose a reason for hiding this comment

melekes commented Aug 14, 2019

codecov-io commented Jul 13, 2019 •

edited

jaekwon commented Jul 22, 2019 •

edited

cwgoes left a comment •

edited