-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adr-002 lite client #54
Conversation
#### Commit | ||
|
||
A commit is a collection of votes that we will want to iterate over so we can | ||
verify each vote. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make the API s.t. we can upgrade to aggregate signatures w/o an API change in the lite client?
Essentially make one function that goes from validator index to boolean representing "has signed", and one aggregate signature struct. Verify checks that 2/3rds of stake has signed, and that aggregate signature.verify() verifies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thot about this a bit. I feel it might be a bit too early for that. This thing is already pretty abstract and I'm not sure it will pay yet to make it even more so.
Also, come to think of it, will aggregate sigs work with the skipping method? If I have an aggregate signature, can I check if +1/3 of some other validator set (not necessarily the validator set that produced the sig) signed it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a better impression of this than I do, but it feels to me like aggregate signatures shouldn't be too far out? Related projects are already using them (LibraBFT, Nervos (https://github.com/cryptape/overlord/) a TM fork)
To check an aggregate signature, you must have all the signing public keys. Is this 1/3rd check needed for checkSupport
? If so, I believe that it is fine, since you are provided the signing public keys in the validator set hash order to verify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so a number of things have come to my attention that suggest this abstraction isn't good enough:
- Doesn't support aggregate sigs
- Doesn't support batch verification (whoops!)
- Testing is actually not much easier than using the actual Tendermint data types.
So all this leads me to believe that the commit trait should be abstracted further to not expose individual signatures but only information about whether say X% signed. In the interest of making some progress in the short term though I think we'll move forward as is and open an issue to deal with this at a later date.
As for the +1/3 check, we have the following situation:
- I trust validator set V
- I get a commit C from validator set V', where V != V'
- I want to check if +1/3 of V is in V' and signed C
- the +1/3 from V may comprise an arbitrary percentage of V' (ie. they could be 1% or 99%, it doesn't matter).
Can this be done for an aggregate sig?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this can be done.
The aggregate signature will contain a list of who signed it, so you have the same situation as the non aggregate case. (The verifier has a set of signers, and has to check if 1/3 of V is in this set)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wohooo 🎉 Left some comments.
|
||
### Manager | ||
|
||
For lack of a better name. The Manager co-ordiantes the syncing and is the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the diagram, maybe the Manager should simply be named "lite client" or "lite node" as it is the point where everything else is used and put together (to form an actual lite client).
Looking at the subsections, this component seems more about syncing only (?). Then, it could be named Syncer (or Tracker).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted here #56
Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
will: | ||
- check that vals[H] and vals[H+1] are correctly reflected in the header | ||
- check that the commit is for the header | ||
- check that +2/3 of the validators correctly signed the header hash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everywhere else you specify which header we are talking about (by explicitly listing a height H
via header[H]
). I think it would be good be consistent in this listing, too. (same for validators)
Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com>
Ok I addressed all the feedback. Also updated it to match the latest version of the code and included some notes about that. Added a proper image too. |
a4d02bc
to
4dc0391
Compare
I don't understand why this is failing. The latest master has been merged in and it passes locally ... |
Ok we should update this per #105 ... removed the Validator trait! |
Ok thanks to @jibrown we actually have a really nice diagram of the data flow for the whole thing now! Might need a few updates to the text to align with the new image though. |
Pushed an ADR refactor. ADR002 is now an index into light client ADRs, and the core verification is ADR 003. Still going to do some cleanup/alignment on the new ADR 003 and just leave the others as WIPs to be done in future PRs. |
The clippy messages look somewhat familiar. I think they should be fixed in the latest master. |
Traits are good. Just want to go through the "implementing traits" part and then this is good to merge and I will work on the other two (CLI and fork detection) |
Codecov Report
@@ Coverage Diff @@
## master #54 +/- ##
=========================================
Coverage ? 36.08%
=========================================
Files ? 90
Lines ? 3140
Branches ? 490
=========================================
Hits ? 1133
Misses ? 1750
Partials ? 257
Continue to review full report at Codecov.
|
Ok, I think this is finally done. It's been realigned with the latest code and describes only what's already been implemented in the |
* adr-002 lite client (#54) * adr-002 lite client * finish adr * address Dev's comments * lite -> light * Apply suggestions from code review Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com> * updates from review * Apply suggestions from code review Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com> * update for better abstraction and latest changes * note about detection * update image. manager -> syncer * update image * update image * More detailed diagram of lite client data flow (#106) * refactor * refactor into more adrs * minor fixes from review * sync adr-003 with latest and call it * rust code blocks Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com> Co-authored-by: jibrown <jackie.ilana.brown@gmail.com> * working on adr-004 Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com> Co-authored-by: jibrown <jackie.ilana.brown@gmail.com>
* Boilerplate: Add lite-node crate - ran `abscissa new lite-node` - added deps (Cargo.toml) and minimal changes to README.md - add to root workspace * Added config options & copied code into new app crate - copied from tendermint-lite/src/main.rs to lite-node/src/command/start.rs * Delete tendermint-lite: replaced by lite-node * lite -> light * minor improvements to comments / docs minor improvements to comments / docs * Fix a few merge hicks (catch up with latest changes from master) rename some vars and more logical bisection in cmd * fix rebasing hicks * Bucky/abscissify adr (#148) * adr-002 lite client (#54) * adr-002 lite client * finish adr * address Dev's comments * lite -> light * Apply suggestions from code review Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com> * updates from review * Apply suggestions from code review Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com> * update for better abstraction and latest changes * note about detection * update image. manager -> syncer * update image * update image * More detailed diagram of lite client data flow (#106) * refactor * refactor into more adrs * minor fixes from review * sync adr-003 with latest and call it * rust code blocks Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com> Co-authored-by: jibrown <jackie.ilana.brown@gmail.com> * working on adr-004 Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com> Co-authored-by: jibrown <jackie.ilana.brown@gmail.com> * Dealing with the merging in master aftermath * merged in master * Fix merge master fallout (related to #169) * Use `abscissa_tokio` and resolve merge conflicts * New stable rust -> new clippy errs -> fixed Co-authored-by: Ethan Buchman <ethan@coinculture.info> Co-authored-by: jibrown <jackie.ilana.brown@gmail.com>
Lite client ADR. A bit backwards because we've already got WIPs for the implementation, but trying to get this written up before we make much more progress there.
Link for nicer reading: https://github.com/interchainio/tendermint-rs/blob/bucky/adr-lite/docs/architecture/adr-002-lite-client.md