39ce819876
* add slash tx * ignore unsigned tx replays * verify that provided evidence is valid * fix clippy + fmt * move application tx handling to another module * partially handle the tendermint txs * fix pr comments * support unsigned app txs * add slash target to the votes * enforce provided, unsigned, signed tx ordering within a block * bug fixes * add unit test for tendermint txs * bug fixes * update tests for tendermint txs * add tx ordering test * tidy up tx ordering test * cargo +nightly fmt * Misc fixes from rebasing * Finish resolving clippy * Remove sha3 from tendermint-machine * Resolve a DoS in SlashEvidence's read Also moves Evidence from Vec<Message> to (Message, Option<Message>). That should meet all requirements while being a bit safer. * Make lazy_static a dev-depend for tributary * Various small tweaks One use of sort was inefficient, sorting unsigned || signed when unsigned was already properly sorted. Given how the unsigned TXs were given a nonce of 0, an unstable sort may swap places with an unsigned TX and a signed TX with a nonce of 0 (leading to a faulty block). The extra protection added here sorts signed, then concats. * Fix Tributary tests I broke, start review on tendermint/tx.rs * Finish reviewing everything outside tests and empty_signature * Remove empty_signature empty_signature led to corrupted local state histories. Unfortunately, the API is only sane with a signature. We now use the actual signature, which risks creating a signature over a malicious message if we have ever have an invariant producing malicious messages. Prior, we only signed the message after the local machine confirmed it was okay per the local view of consensus. This is tolerated/preferred over a corrupt state history since production of such messages is already an invariant. TODOs are added to make handling of this theoretical invariant further robust. * Remove async_sequential for tokio::test There was no competition for resources forcing them to be run sequentially. * Modify block order test to be statistically significant without multiple runs * Clean tests --------- Co-authored-by: Luke Parker <lukeparker5132@gmail.com> |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
Tendermint
An implementation of the Tendermint state machine in Rust.
This is solely the state machine, intended to be mapped to any arbitrary system. It supports an arbitrary signature scheme, weighting, and block definition accordingly. It is not intended to work with the Cosmos SDK, solely to be an implementation of the academic protocol.
Caveats
-
Only SCALE serialization is supported currently. Ideally, everything from SCALE to borsh to bincode would be supported. SCALE was chosen due to this being under Serai, which uses Substrate, which uses SCALE. Accordingly, when deciding which of the three (mutually incompatible) options to support...
-
The only supported runtime is tokio due to requiring a
sleepimplementation. Ideally, the runtime choice will be moved to a feature in the future. -
It is possible for
add_blockto be called on a block which failed (or never went through in the first place) validation. This is a break from the paper which is accepted here. This is for two reasons.- Serai needing this functionality.
- If a block is committed which is invalid, either there's a malicious majority now defining consensus OR the local node is malicious by virtue of being faulty. Considering how either represents a fatal circumstance, except with regards to system like Serai which have their own logic for pseudo-valid blocks, it is accepted as a possible behavior with the caveat any consumers must be aware of it. No machine will vote nor precommit to a block it considers invalid, so for a network with an honest majority, this is a non-issue.
Paper
The paper describes the algorithm with pseudocode on page 6. This pseudocode isn't directly implementable, nor does it specify faulty behavior. Instead, it's solely a series of conditions which trigger events in order to successfully achieve consensus.
The included pseudocode segments can be minimally described as follows:
01-09 Init
10-10 StartRound(0)
11-21 StartRound
22-27 Fresh proposal
28-33 Proposal building off a valid round with prevotes
34-35 2f+1 prevote -> schedule timeout prevote
36-43 First proposal with prevotes -> precommit Some
44-46 2f+1 nil prevote -> precommit nil
47-48 2f+1 precommit -> schedule timeout precommit
49-54 First proposal with precommits -> finalize
55-56 f+1 round > local round, jump
57-60 on timeout propose
61-64 on timeout prevote
65-67 on timeout precommit
The corresponding Rust code implementing these tasks are marked with their related line numbers.