You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

80 lines
4.2 KiB

7 years ago
7 years ago
7 years ago
7 years ago
  1. # Tendermint Specification
  2. This is a markdown specification of the Tendermint blockchain.
  3. It defines the base data structures, how they are validated,
  4. and how they are communicated over the network.
  5. If you find discrepancies between the spec and the code that
  6. do not have an associated issue or pull request on github,
  7. please submit them to our [bug bounty](https://tendermint.com/security)!
  8. ## Contents
  9. - [Overview](#overview)
  10. ### Data Structures
  11. - [Encoding and Digests](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/encoding.md)
  12. - [Blockchain](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md)
  13. - [State](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/state.md)
  14. ### Consensus Protocol
  15. - [Consensus Algorithm](/docs/spec/consensus/consensus.md)
  16. - [Time](/docs/spec/consensus/bft-time.md)
  17. - [Light-Client](/docs/spec/consensus/light-client.md)
  18. ### P2P and Network Protocols
  19. - [The Base P2P Layer](https://github.com/tendermint/tendermint/tree/master/docs/spec/p2p): multiplex the protocols ("reactors") on authenticated and encrypted TCP connections
  20. - [Peer Exchange (PEX)](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/pex): gossip known peer addresses so peers can find each other
  21. - [Block Sync](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/block_sync): gossip blocks so peers can catch up quickly
  22. - [Consensus](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/consensus): gossip votes and block parts so new blocks can be committed
  23. - [Mempool](https://github.com/tendermint/tendermint/tree/master/docs/spec/reactors/mempool): gossip transactions so they get included in blocks
  24. - Evidence: TODO
  25. ### Software
  26. - [ABCI](/docs/spec/software/abci.md): Details about interactions between the
  27. application and consensus engine over ABCI
  28. - [Write-Ahead Log](/docs/spec/software/wal.md): Details about how the consensus
  29. engine preserves data and recovers from crash failures
  30. ## Overview
  31. Tendermint provides Byzantine Fault Tolerant State Machine Replication using
  32. hash-linked batches of transactions. Such transaction batches are called "blocks".
  33. Hence, Tendermint defines a "blockchain".
  34. Each block in Tendermint has a unique index - its Height.
  35. Height's in the blockchain are monotonic.
  36. Each block is committed by a known set of weighted Validators.
  37. Membership and weighting within this validator set may change over time.
  38. Tendermint guarantees the safety and liveness of the blockchain
  39. so long as less than 1/3 of the total weight of the Validator set
  40. is malicious or faulty.
  41. A commit in Tendermint is a set of signed messages from more than 2/3 of
  42. the total weight of the current Validator set. Validators take turns proposing
  43. blocks and voting on them. Once enough votes are received, the block is considered
  44. committed. These votes are included in the *next* block as proof that the previous block
  45. was committed - they cannot be included in the current block, as that block has already been
  46. created.
  47. Once a block is committed, it can be executed against an application.
  48. The application returns results for each of the transactions in the block.
  49. The application can also return changes to be made to the validator set,
  50. as well as a cryptographic digest of its latest state.
  51. Tendermint is designed to enable efficient verification and authentication
  52. of the latest state of the blockchain. To achieve this, it embeds
  53. cryptographic commitments to certain information in the block "header".
  54. This information includes the contents of the block (eg. the transactions),
  55. the validator set committing the block, as well as the various results returned by the application.
  56. Note, however, that block execution only occurs *after* a block is committed.
  57. Thus, application results can only be included in the *next* block.
  58. Also note that information like the transaction results and the validator set are never
  59. directly included in the block - only their cryptographic digests (Merkle roots) are.
  60. Hence, verification of a block requires a separate data structure to store this information.
  61. We call this the `State`. Block verification also requires access to the previous block.