Browse Source

docs: adr-046 add bisection algorithm details (#4496)

* docs: adr-046 add bisection algorithm details

Closes #4329

* format fig. 1 title

* docs: adr-046 we no longer download headers in TrustedHeader

https://github.com/tendermint/tendermint/pull/4496#issuecomment-592446054
pull/4501/head
Anton Kaliaev 5 years ago
committed by GitHub
parent
commit
a122a555de
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 23 additions and 3 deletions
  1. +23
    -3
      docs/architecture/adr-046-light-client-implementation.md
  2. BIN
      docs/architecture/img/adr-046-fig1.png

+ 23
- 3
docs/architecture/adr-046-light-client-implementation.md View File

@ -3,6 +3,7 @@
## Changelog
* 13-02-2020: Initial draft
* 26-02-2020: Cross-checking the first header
* 28-02-2020: Bisection algorithm details
## Context
@ -67,9 +68,13 @@ required to respond: 1. Note the very first header (`TrustOptions.Hash`) is
also cross-checked with witnesses for additional security.
Due to bisection algorithm nature, some headers might be skipped. If the light
client does not have a header for height `X` and `TrustedHeader(X)` or
`TrustedValidatorSet(X)` methods are called, it will download the header from
primary provider and perform a backwards verification.
client does not have a header for height `X` and `VerifyHeaderAtHeight(X)` or
`VerifyHeader(H#X)` methods are called, it will perform a backwards
verification from the latest header back to the header at height `X`.
`TrustedHeader`, `TrustedValidatorSet` only communicate with the trusted store.
If some header is not there, an error will be returned indicating that
verification is required.
```go
type Provider interface {
@ -127,6 +132,21 @@ cases of adjacent and non-adjacent headers. In the former case, it compares the
hashes directly (2/3+ signed transition). Otherwise, it verifies 1/3+
(`trustLevel`) of trusted validators are still present in new validators.
### Bisection algorithm details
Non-recursive bisection algorithm was implemented despite the spec containing
the recursive version. There are two major reasons:
1) Constant memory consumption => no risk of getting OOM (Out-Of-Memory) exceptions;
2) Faster finality (see Fig. 1).
_Fig. 1: Differences between recursive and non-recursive bisections_
![Fig. 1](./img/adr-046-fig1.png)
Specification of the non-recursive bisection can be found
[here](https://github.com/tendermint/spec/blob/zm_non-recursive-verification/spec/consensus/light-client/non-recursive-verification.md).
## Status
Accepted.


BIN
docs/architecture/img/adr-046-fig1.png View File

Before After
Width: 404  |  Height: 223  |  Size: 13 KiB

Loading…
Cancel
Save