Per conversations earlier today, we'll consider all proposed implementation changes part of the ADR process rather than the RFC process (which will remain, for now, on the spec; this may get incorporated instead into the burgeoning "CIPS" process).
This change renames RFC 1 to ADR 66, leaving space for the not-yet-merged ADR 65.
* add time warping lunatic attack test
* create too high and connecton refused errors and add to the light client provider
* add height check to provider
* introduce block lag
* add detection logic for processing forward lunatic attack
* add node-side verification logic
* clean up tests and formatting
* update adr's
* update testing
* fix fetching the latest block
* format
* update changelog
* implement suggestions
* modify ADR's
* format
* clean up node evidence verification
## Description
- separate docs related to running nodes into the nodes dir.
- keep old files but dont display them
- bring over debugging like a pro blog
Closes: #XXX
## Description
These changes are up for discussion.
The current ADR template leaves a lot of room for interpretation and we currently do not have implementation level specs. This change to the ADR template is meant to solve both of these pitfalls.
Thank you to @tessr for providing an amazing template to follow. I only took a few things from it but we can add more if people would like more detail.
Closes: #XXX
## Description
This pr adds missing adr numbers based on what is in #2313
This pr adds empty templates that should later be filled when the time comes to do the implementation.
there are still missing numbers, we can either fill them in when we write more ADRs or not backfill numbers and only go forwards.
Closes: #2313
## Description
This adr is meant to weight the pros and cons of gRPC and JSON-RPC. It is fairly incomplete on the JSON-RPC side.
EDIT: Thank you to erik on filling out the pros and cons!!
Work Towards: #3367
Closes: #4530
This PR contains logic for both submitting an evidence by the light client (lite2 package) and receiving it on the Tendermint side (/broadcast_evidence RPC and/or EvidenceReactor#Receive). Upon receiving the ConflictingHeadersEvidence (introduced by this PR), the Tendermint validates it, then breaks it down into smaller pieces (DuplicateVoteEvidence, LunaticValidatorEvidence, PhantomValidatorEvidence, PotentialAmnesiaEvidence). Afterwards, each piece of evidence is verified against the state of the full node and added to the pool, from which it's reaped upon block creation.
* rpc/client: do not pass height param if height ptr is nil
* rpc/core: validate incoming evidence!
* only accept ConflictingHeadersEvidence if one
of the headers is committed from this full node's perspective
This simplifies the code. Plus, if there are multiple forks, we'll
likely to receive multiple ConflictingHeadersEvidence anyway.
* swap CommitSig with Vote in LunaticValidatorEvidence
Vote is needed to validate signature
* no need to embed client
http is a provider and should not be used as a client
## Description
ADR to address the process for proving an amnesia attack (as a form of global evidence) from `PotentialAmnesiaEvidence` detected by light clients
______
For contributor use:
- [ ] Wrote tests
- [ ] Updated CHANGELOG_PENDING.md
- [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
- [ ] Updated relevant documentation (`docs/`) and code comments
- [ ] Re-reviewed `Files changed` in the Github PR explorer
Sam Kleinman
Marko
Callum Waters
JayT106
Aleksandr Bezobchuk
Tess Rinearson
Erik Grinaker
dongsam
John Adler
Anton Kaliaev