d0c3457343
* Doc: documentation of new p2p layer, first commit * Doc: p2p peer manager abstraction, first commit * Doc: life cycle of a peer, first part * Doc: life cycle of a p2p peer, picture added * typos * Doc: life cycle of a p2p peer picture updated * Doc: life cycle of a p2p peer section refactored * Doc: p2p connection policy and connection slots * Doc: peer manager defines the connection policy * Doc: peer manager connection slots upgrading * Doc: peer manager eviction procedure introduced * Doc: several corrections in peer manager documentation * Doc: peer ranking mechanism documented * Doc: EvictNext peer manager transition documented * Doc: concept of candidate peer added to peer manager * Doc: peer manager documentation, aesthetic changes * Apply suggestions from code review (again) Co-authored-by: Sergio Mena <sergio@informal.systems> * Spec of v0.35 p2p layer moved to spec/p2p/v0.35 * Spec: p2p markdown links fixed * Spec: addressing more issues on peer manager spec * Spec: p2p peer manager DialNext algorithm * Spec: p2p peer manager Dial and Accepted algorithms * Spec: p2p router dialing peers thread * Spec: p2p router accept peers threads * Spec: p2p router evict peers routine * Spec: p2p router routing messages routines * Spec: p2p v0.35 readme points to other documents * Spec: fixing markdown links * Apply suggestions from Josef's code review * They state that this is a work in progress, that has been interrupted to focus on the specification of the p2p layer adopted by Tendermint v0.34. Co-authored-by: Josef Widder <44643235+josef-widder@users.noreply.github.com> * Spc: p2p v0.35 spec mentions new p2p layer Co-authored-by: Jasmina Malicevic <jasmina.dustinac@gmail.com> Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Josef Widder <44643235+josef-widder@users.noreply.github.com> Co-authored-by: Daniel Cason <daniel.cason@informal.systems>
order, title, parent
| order | title | parent | ||||
|---|---|---|---|---|---|---|
| 1 | Overview |
|
Tendermint Specifications
This directory hosts the canonical Markdown specifications of the Tendermint Protocol.
It shall be used to describe protocol semantics, namely the BFT consensus engine, leader election, block propagation and light client verification. The specification includes encoding descriptions used in interprocess communication to comply with the protocol. It defines the interface between the application and Tendermint. The english specifications are often accompanies with a TLA+ specification.
Table of Contents
- Overview
- Application Blockchain Interface
- Encoding and Digests
- Core Data Structures
- State
- Consensus Algorithm
- Creating a proposal
- Time
- Light Client
- The Base P2P Layer
- Peer Exchange (PEX)
- Remote Procedure Calls
- Write-Ahead Log
- Ivy Proofs
Contibuting
Contributions are welcome.
Proposals at an early stage can first be drafted as Github issues. To progress, a proposal will often need to be written out and approved as a Request For Comment (RFC).
The standard language for coding blocks is Golang.
If you find discrepancies between the spec and the code that do not have an associated issue or pull request on github, please submit them to our bug bounty!
Overview
Tendermint provides Byzantine Fault Tolerant State Machine Replication using hash-linked batches of transactions. Such transaction batches are called "blocks". Hence, Tendermint defines a "blockchain".
Each block in Tendermint has a unique index - its Height. Height's in the blockchain are monotonic. Each block is committed by a known set of weighted Validators. Membership and weighting within this validator set may change over time. Tendermint guarantees the safety and liveness of the blockchain so long as less than 1/3 of the total weight of the Validator set is malicious or faulty.
A commit in Tendermint is a set of signed messages from more than 2/3 of the total weight of the current Validator set. Validators take turns proposing blocks and voting on them. Once enough votes are received, the block is considered committed. These votes are included in the next block as proof that the previous block was committed - they cannot be included in the current block, as that block has already been created.
Once a block is committed, it can be executed against an application. The application returns results for each of the transactions in the block. The application can also return changes to be made to the validator set, as well as a cryptographic digest of its latest state.
Tendermint is designed to enable efficient verification and authentication of the latest state of the blockchain. To achieve this, it embeds cryptographic commitments to certain information in the block "header". This information includes the contents of the block (eg. the transactions), the validator set committing the block, as well as the various results returned by the application. Note, however, that block execution only occurs after a block is committed. Thus, application results can only be included in the next block.
Also note that information like the transaction results and the validator set are never
directly included in the block - only their cryptographic digests (Merkle roots) are.
Hence, verification of a block requires a separate data structure to store this information.
We call this the State. Block verification also requires access to the previous block.