mirror of
https://github.com/serai-dex/serai.git
synced 2024-12-23 20:19:24 +00:00
aea6ac104f
Updates to polkadot-v0.9.40, with a variety of dependency updates accordingly. Substrate thankfully now uses k256 0.13, pathing the way for #256. We couldn't upgrade to polkadot-v0.9.40 without this due to polkadot-v0.9.40 having fundamental changes to syncing. While we could've updated tendermint, it's not worth the continued development effort given its inability to work with multiple validator sets. Purges sc-tendermint. Keeps tendermint-machine for #163. Closes #137, #148, #157, #171. #96 and #99 should be re-scoped/clarified. #134 and #159 also should be clarified. #169 is also no longer a priority since we're only considering temporal deployments of tendermint. #170 also isn't since we're looking at effectively sharded validator sets, so there should be no singular large set needing high performance.
61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
# 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](https://arxiv.org/pdf/1807.04938.pdf).
|
|
|
|
### 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 `sleep` implementation.
|
|
Ideally, the runtime choice will be moved to a feature in the future.
|
|
|
|
- It is possible for `add_block` to 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.
|
|
|
|
1) Serai needing this functionality.
|
|
2) 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](https://arxiv.org/abs/1807.04938) 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.
|