Skip to content
This repository has been archived by the owner on Mar 24, 2023. It is now read-only.

Initial evidence types #23

Open
adlerjohn opened this issue May 6, 2020 · 1 comment
Open

Initial evidence types #23

adlerjohn opened this issue May 6, 2020 · 1 comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@adlerjohn
Copy link
Member

adlerjohn commented May 6, 2020

Currently the only evidence type is double-signing. There should be additional types for anything slashable, i.e. anything that would trigger a fraud proof.

Upcoming new Tendermint evidence types: https://github.com/tendermint/tendermint/blob/proto-breakage/proto/types/evidence.proto

Also see: https://medium.com/tendermint/different-types-of-evidence-in-tendermint-5de4440fdd54

@adlerjohn adlerjohn added documentation Improvements or additions to documentation enhancement New feature or request labels May 6, 2020
@adlerjohn adlerjohn added this to the Pre-implementation draft milestone May 6, 2020
@adlerjohn adlerjohn self-assigned this May 6, 2020
@adlerjohn adlerjohn added the serialization Serialization definitions label May 11, 2020
@adlerjohn adlerjohn removed the serialization Serialization definitions label Jun 20, 2020
@adlerjohn adlerjohn mentioned this issue Nov 23, 2020
3 tasks
@liamsi
Copy link
Member

liamsi commented Apr 3, 2021

Additionally to defining the exact data structures of different fraud proofs / evidence types, the specification should also stipulate who (which node types) generates them under which circumstances and what happens with the evidence after construction (does get included in the next block, does it trigger a slashing event, is it "only" gossipped in the p2p network - if yes to which nodes) and why it is generated in the first place.
This is to actually guide the implementation.

In the context of erasure coding, for instance, this is needed to inform the APIs of the used libraries (e.g. see celestiaorg/rsmt2d#24 and github.com/celestiaorg/rsmt2d#12).

Ideally, the spec also defined properties or invariants (if any) that are achieved by dispersing the evidence (e.g. a proposer can not propose an incorrectly encoded block without getting caught and getting slashed for that, etc).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
No open projects
Status: No status
Development

No branches or pull requests

2 participants