Verify all headers in order instead of bisect#3360
Conversation
- add method that fetches, verifies, and stores all headers in order from the latest trusted up to the requested height
Codecov Report
@@ Coverage Diff @@
## develop #3360 +/- ##
===========================================
- Coverage 64.42% 64.15% -0.27%
===========================================
Files 214 214
Lines 17514 17552 +38
===========================================
- Hits 11283 11261 -22
- Misses 5296 5350 +54
- Partials 935 941 +6
|
lite/dynamic_verifier.go
Outdated
| // Update height for height. | ||
| // TODO: do we want the lite client to store the intermediate commits, | ||
| // or only the latest/last one? | ||
| if err := dv.verifyAndSave(trustedFC, nextFC); err != nil { |
There was a problem hiding this comment.
How do we benefit from storing them? maybe only that if something fails, we'll start from the last saved commit, no?
There was a problem hiding this comment.
I think the only benefit would be that if the application constantly queries state of the past, we have more trusted (verified) full commits / signed headers stored locally which can be used as a starting point for this queries instead having to query them from dv.source. My intuition would be that storing the last header / full commit should be sufficient but this intuition is not based on any numbers/data.
There was a problem hiding this comment.
If we want to query past state, we need past Merkle roots (app hashes). I don't think we need the full commits though.
There was a problem hiding this comment.
Thanks Chris. Probably just storing the latest full commit should be enough. The full commit contains the AppHashes via the Header:
Lines 16 to 20 in 15f6211
Lines 689 to 690 in 15f6211
Line 376 in 15f6211
We could probably get rid of some (most?) of the fields here for the lite client.
For now, storing only the latest FullCommit sounds like the most reasonable thing to do.
lite/dynamic_verifier_test.go
Outdated
| // Souce doesn't have fcz[9] so cert.LastTrustedHeight wont' change. | ||
| // We do not jump forward using trusted full commits. | ||
| // Instead, we need to store the "gap" (height 7) in source s.t. | ||
| // Verfiy can retrieve it from somewhere. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
- only verify that valset for height SignedHeader.Height+1 is non-empty and matches the hash in the signed header (NextValidatorsHash) - all other checks were already done by the BaseVerifier - at least log mysteriously ignored error (for now)
lite/dynamic_verifier.go
Outdated
| // for height h, using repeated applications of bisection if necessary. | ||
| // | ||
| // Returns ErrCommitNotFound if source provider doesn't have the commit for h. | ||
| // TODO: bisection is disabled for now. |
There was a problem hiding this comment.
can you link the issue here too
| return FullCommit{}, err | ||
| } | ||
| // We already were at the requested height. | ||
| if trustedFC.Height() == h { |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
lite/dynamic_verifier.go
Outdated
| // Update height for height. | ||
| // TODO: do we want the lite client to store the intermediate commits, | ||
| // or only the latest/last one? | ||
| if err := dv.verifyAndSave(trustedFC, nextFC); err != nil { |
There was a problem hiding this comment.
How do we benefit from storing them? maybe only that if something fails, we'll start from the last saved commit, no?
- add sanity check for returned height and panic if violated - add issue to comment about bisecting
|
Instead of merging this in, I'll incorporate some fixes into a new branch I'm working on for weak subjectivity. |
…rovided by a seed node (backport tendermint#3360) (tendermint#3396) Closes tendermint#486. Commits: 1. Make `TestConnectionSpeedForPeerReceivedFromSeed` to fail, as it will make the node to connect to more than the configured `MaxNumOutboundPeers` 2. Solve the issue by introducing a channel to wake up `ensurePeersRoutine()`. In this way, the node will not to wait until the next `defaultEnsurePeersPeriod` (30s) before attempting again to connect to new peers (`ensurePeers()` method) whose addresses were provide by the seed node. --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request tendermint#3360 done by [Mergify](https://mergify.com). --------- Co-authored-by: Daniel <daniel.cason@informal.systems>
…rovided by a seed node (backport tendermint#3360) (tendermint#3397) Closes tendermint#486. Commits: 1. Make `TestConnectionSpeedForPeerReceivedFromSeed` to fail, as it will make the node to connect to more than the configured `MaxNumOutboundPeers` 2. Solve the issue by introducing a channel to wake up `ensurePeersRoutine()`. In this way, the node will not to wait until the next `defaultEnsurePeersPeriod` (30s) before attempting again to connect to new peers (`ensurePeers()` method) whose addresses were provide by the seed node. --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request tendermint#3360 done by [Mergify](https://mergify.com). --------- Co-authored-by: Daniel <daniel.cason@informal.systems>
resolves: #3259
ref: #3244
ref: #3174
Still need to address the TODOs below but this should be ready for review.