Skip to content
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

Merged
merged 22 commits into from
Feb 10, 2020
Merged

adr-002 lite client #54

merged 22 commits into from
Feb 10, 2020

Conversation

ebuchman
Copy link
Member

@ebuchman ebuchman commented Oct 30, 2019

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

@ebuchman ebuchman changed the title WIP: adr-002 lite client adr-002 lite client Nov 1, 2019
#### Commit

A commit is a collection of votes that we will want to iterate over so we can
verify each vote.

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.

Copy link
Member Author

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?

Copy link

@ValarDragon ValarDragon Nov 4, 2019

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.

Copy link
Member Author

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:

  1. Doesn't support aggregate sigs
  2. Doesn't support batch verification (whoops!)
  3. 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?

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)

Copy link
Member

@liamsi liamsi left a 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
Copy link
Member

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted here #56

docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
docs/architecture/adr-002-lite-client.md Outdated Show resolved Hide resolved
ebuchman and others added 2 commits November 6, 2019 16:12
Co-Authored-By: Ismail Khoffi <Ismail.Khoffi@gmail.com>
liamsi
liamsi previously approved these changes Nov 12, 2019
Copy link
Member

@liamsi liamsi left a 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
Copy link
Member

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>
@ebuchman
Copy link
Member Author

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.

@ebuchman
Copy link
Member Author

I don't understand why this is failing. The latest master has been merged in and it passes locally ...

@ebuchman
Copy link
Member Author

Ok we should update this per #105 ... removed the Validator trait!

@ebuchman
Copy link
Member Author

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.

@ebuchman
Copy link
Member Author

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.

@liamsi
Copy link
Member

liamsi commented Jan 22, 2020

The clippy messages look somewhat familiar. I think they should be fixed in the latest master.

@ebuchman
Copy link
Member Author

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-io
Copy link

codecov-io commented Feb 10, 2020

Codecov Report

❗ No coverage uploaded for pull request base (master@3018cf0). Click here to learn what that means.
The diff coverage is 54.73%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master      #54   +/-   ##
=========================================
  Coverage          ?   36.08%           
=========================================
  Files             ?       90           
  Lines             ?     3140           
  Branches          ?      490           
=========================================
  Hits              ?     1133           
  Misses            ?     1750           
  Partials          ?      257
Impacted Files Coverage Δ
tendermint/src/amino_types/block_id.rs 13.79% <ø> (ø)
tendermint/src/rpc/client.rs 0% <ø> (ø)
tendermint/src/amino_types/signature.rs 35.71% <ø> (ø)
tendermint/src/amino_types/remote_error.rs 0% <ø> (ø)
tendermint/src/amino_types/time.rs 35.29% <ø> (ø)
tendermint/src/block.rs 0% <ø> (ø)
tendermint/src/amino_types/version.rs 62.5% <ø> (ø)
tendermint/src/amino_types/message.rs 100% <ø> (ø)
tendermint/src/error.rs 12.3% <0%> (ø)
tendermint/src/amino_types.rs 0% <0%> (ø)
... and 19 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3018cf0...ce03b67. Read the comment docs.

@ebuchman
Copy link
Member Author

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 lite and lite_impl. Let's merge.

@ebuchman ebuchman merged commit f9287e0 into master Feb 10, 2020
@ebuchman ebuchman deleted the bucky/adr-lite branch February 10, 2020 04:50
liamsi added a commit that referenced this pull request Feb 12, 2020
* 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>
brapse pushed a commit that referenced this pull request Mar 14, 2020
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants