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.

507 lines
13 KiB

7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
6 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
  1. # Blockchain
  2. Here we describe the data structures in the Tendermint blockchain and the rules for validating them.
  3. ## Data Structures
  4. The Tendermint blockchains consists of a short list of basic data types:
  5. - `Block`
  6. - `Header`
  7. - `Version`
  8. - `BlockID`
  9. - `Time`
  10. - `Data` (for transactions)
  11. - `Commit` and `Vote`
  12. - `EvidenceData` and `Evidence`
  13. ## Block
  14. A block consists of a header, transactions, votes (the commit),
  15. and a list of evidence of malfeasance (ie. signing conflicting votes).
  16. ```go
  17. type Block struct {
  18. Header Header
  19. Txs Data
  20. Evidence EvidenceData
  21. LastCommit Commit
  22. }
  23. ```
  24. Note the `LastCommit` is the set of votes that committed the last block.
  25. ## Header
  26. A block header contains metadata about the block and about the consensus, as well as commitments to
  27. the data in the current block, the previous block, and the results returned by the application:
  28. ```go
  29. type Header struct {
  30. // basic block info
  31. Version Version
  32. ChainID string
  33. Height int64
  34. Time Time
  35. NumTxs int64
  36. TotalTxs int64
  37. // prev block info
  38. LastBlockID BlockID
  39. // hashes of block data
  40. LastCommitHash []byte // commit from validators from the last block
  41. DataHash []byte // MerkleRoot of transaction hashes
  42. // hashes from the app output from the prev block
  43. ValidatorsHash []byte // validators for the current block
  44. NextValidatorsHash []byte // validators for the next block
  45. ConsensusHash []byte // consensus params for current block
  46. AppHash []byte // state after txs from the previous block
  47. LastResultsHash []byte // root hash of all results from the txs from the previous block
  48. // consensus info
  49. EvidenceHash []byte // evidence included in the block
  50. ProposerAddress []byte // original proposer of the block
  51. ```
  52. Further details on each of these fields is described below.
  53. ## Version
  54. The `Version` contains the protocol version for the blockchain and the
  55. application as two `uint64` values:
  56. ```go
  57. type Version struct {
  58. Block uint64
  59. App uint64
  60. }
  61. ```
  62. ## BlockID
  63. The `BlockID` contains two distinct Merkle roots of the block.
  64. The first, used as the block's main hash, is the MerkleRoot
  65. of all the fields in the header (ie. `MerkleRoot(header)`.
  66. The second, used for secure gossipping of the block during consensus,
  67. is the MerkleRoot of the complete serialized block
  68. cut into parts (ie. `MerkleRoot(MakeParts(block))`).
  69. The `BlockID` includes these two hashes, as well as the number of
  70. parts (ie. `len(MakeParts(block))`)
  71. ```go
  72. type BlockID struct {
  73. Hash []byte
  74. PartsHeader PartSetHeader
  75. }
  76. type PartSetHeader struct {
  77. Total int32
  78. Hash []byte
  79. }
  80. ```
  81. See [MerkleRoot](./encoding.md#MerkleRoot) for details.
  82. ## Time
  83. Tendermint uses the
  84. [Google.Protobuf.WellKnownTypes.Timestamp](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/timestamp)
  85. format, which uses two integers, one for Seconds and for Nanoseconds.
  86. ## Data
  87. Data is just a wrapper for a list of transactions, where transactions are
  88. arbitrary byte arrays:
  89. ```
  90. type Data struct {
  91. Txs [][]byte
  92. }
  93. ```
  94. ## Commit
  95. Commit is a simple wrapper for a list of votes, with one vote for each
  96. validator. It also contains the relevant BlockID:
  97. ```
  98. type Commit struct {
  99. BlockID BlockID
  100. Precommits []Vote
  101. }
  102. ```
  103. NOTE: this will likely change to reduce the commit size by eliminating redundant
  104. information - see [issue #1648](https://github.com/tendermint/tendermint/issues/1648).
  105. ## Vote
  106. A vote is a signed message from a validator for a particular block.
  107. The vote includes information about the validator signing it.
  108. ```go
  109. type Vote struct {
  110. Type byte
  111. Height int64
  112. Round int
  113. BlockID BlockID
  114. Timestamp Time
  115. ValidatorAddress []byte
  116. ValidatorIndex int
  117. Signature []byte
  118. }
  119. ```
  120. There are two types of votes:
  121. a _prevote_ has `vote.Type == 1` and
  122. a _precommit_ has `vote.Type == 2`.
  123. ## Signature
  124. Signatures in Tendermint are raw bytes representing the underlying signature.
  125. See the [signature spec](./encoding.md#key-types) for more.
  126. ## EvidenceData
  127. EvidenceData is a simple wrapper for a list of evidence:
  128. ```
  129. type EvidenceData struct {
  130. Evidence []Evidence
  131. }
  132. ```
  133. ## Evidence
  134. Evidence in Tendermint is implemented as an interface.
  135. This means any evidence is encoded using its Amino prefix.
  136. There is currently only a single type, the `DuplicateVoteEvidence`.
  137. ```
  138. // amino name: "tendermint/DuplicateVoteEvidence"
  139. type DuplicateVoteEvidence struct {
  140. PubKey PubKey
  141. VoteA Vote
  142. VoteB Vote
  143. }
  144. ```
  145. See the [pubkey spec](./encoding.md#key-types) for more.
  146. ## Validation
  147. Here we describe the validation rules for every element in a block.
  148. Blocks which do not satisfy these rules are considered invalid.
  149. We abuse notation by using something that looks like Go, supplemented with English.
  150. A statement such as `x == y` is an assertion - if it fails, the item is invalid.
  151. We refer to certain globally available objects:
  152. `block` is the block under consideration,
  153. `prevBlock` is the `block` at the previous height,
  154. and `state` keeps track of the validator set, the consensus parameters
  155. and other results from the application. At the point when `block` is the block under consideration,
  156. the current version of the `state` corresponds to the state
  157. after executing transactions from the `prevBlock`.
  158. Elements of an object are accessed as expected,
  159. ie. `block.Header`.
  160. See the [definition of `State`](./state.md).
  161. ### Header
  162. A Header is valid if its corresponding fields are valid.
  163. ### Version
  164. ```
  165. block.Version.Block == state.Version.Block
  166. block.Version.App == state.Version.App
  167. ```
  168. The block version must match the state version.
  169. ### ChainID
  170. ```
  171. len(block.ChainID) < 50
  172. ```
  173. ChainID must be less than 50 bytes.
  174. ### Height
  175. ```go
  176. block.Header.Height > 0
  177. block.Header.Height == prevBlock.Header.Height + 1
  178. ```
  179. The height is an incrementing integer. The first block has `block.Header.Height == 1`.
  180. ### Time
  181. ```
  182. block.Header.Timestamp >= prevBlock.Header.Timestamp + state.consensusParams.Block.TimeIotaMs
  183. block.Header.Timestamp == MedianTime(block.LastCommit, state.LastValidators)
  184. ```
  185. The block timestamp must be monotonic.
  186. It must equal the weighted median of the timestamps of the valid votes in the block.LastCommit.
  187. Note: the timestamp of a vote must be greater by at least one millisecond than that of the
  188. block being voted on.
  189. The timestamp of the first block must be equal to the genesis time (since
  190. there's no votes to compute the median).
  191. ```
  192. if block.Header.Height == 1 {
  193. block.Header.Timestamp == genesisTime
  194. }
  195. ```
  196. See the section on [BFT time](../consensus/bft-time.md) for more details.
  197. ### NumTxs
  198. ```go
  199. block.Header.NumTxs == len(block.Txs.Txs)
  200. ```
  201. Number of transactions included in the block.
  202. ### TotalTxs
  203. ```go
  204. block.Header.TotalTxs == prevBlock.Header.TotalTxs + block.Header.NumTxs
  205. ```
  206. The cumulative sum of all transactions included in this blockchain.
  207. The first block has `block.Header.TotalTxs = block.Header.NumberTxs`.
  208. ### LastBlockID
  209. LastBlockID is the previous block's BlockID:
  210. ```go
  211. prevBlockParts := MakeParts(prevBlock)
  212. block.Header.LastBlockID == BlockID {
  213. Hash: MerkleRoot(prevBlock.Header),
  214. PartsHeader{
  215. Hash: MerkleRoot(prevBlockParts),
  216. Total: len(prevBlockParts),
  217. },
  218. }
  219. ```
  220. The first block has `block.Header.LastBlockID == BlockID{}`.
  221. ### LastCommitHash
  222. ```go
  223. block.Header.LastCommitHash == MerkleRoot(block.LastCommit.Precommits)
  224. ```
  225. MerkleRoot of the votes included in the block.
  226. These are the votes that committed the previous block.
  227. The first block has `block.Header.LastCommitHash == []byte{}`
  228. ### DataHash
  229. ```go
  230. block.Header.DataHash == MerkleRoot(Hashes(block.Txs.Txs))
  231. ```
  232. MerkleRoot of the hashes of transactions included in the block.
  233. Note the transactions are hashed before being included in the Merkle tree,
  234. so the leaves of the Merkle tree are the hashes, not the transactions
  235. themselves. This is because transaction hashes are regularly used as identifiers for
  236. transactions.
  237. ### ValidatorsHash
  238. ```go
  239. block.ValidatorsHash == MerkleRoot(state.Validators)
  240. ```
  241. MerkleRoot of the current validator set that is committing the block.
  242. This can be used to validate the `LastCommit` included in the next block.
  243. Note the validators are sorted by their address before computing the MerkleRoot.
  244. ### NextValidatorsHash
  245. ```go
  246. block.NextValidatorsHash == MerkleRoot(state.NextValidators)
  247. ```
  248. MerkleRoot of the next validator set that will be the validator set that commits the next block.
  249. This is included so that the current validator set gets a chance to sign the
  250. next validator sets Merkle root.
  251. Note the validators are sorted by their address before computing the MerkleRoot.
  252. ### ConsensusHash
  253. ```go
  254. block.ConsensusHash == state.ConsensusParams.Hash()
  255. ```
  256. Hash of the amino-encoding of a subset of the consensus parameters.
  257. ### AppHash
  258. ```go
  259. block.AppHash == state.AppHash
  260. ```
  261. Arbitrary byte array returned by the application after executing and commiting the previous block. It serves as the basis for validating any merkle proofs that comes from the ABCI application and represents the state of the actual application rather than the state of the blockchain itself.
  262. The first block has `block.Header.AppHash == []byte{}`.
  263. ### LastResultsHash
  264. ```go
  265. block.ResultsHash == MerkleRoot(state.LastResults)
  266. ```
  267. MerkleRoot of the results of the transactions in the previous block.
  268. The first block has `block.Header.ResultsHash == []byte{}`.
  269. ## EvidenceHash
  270. ```go
  271. block.EvidenceHash == MerkleRoot(block.Evidence)
  272. ```
  273. MerkleRoot of the evidence of Byzantine behaviour included in this block.
  274. ### ProposerAddress
  275. ```go
  276. block.Header.ProposerAddress in state.Validators
  277. ```
  278. Address of the original proposer of the block. Must be a current validator.
  279. ## Txs
  280. Arbitrary length array of arbitrary length byte-arrays.
  281. ## LastCommit
  282. The first height is an exception - it requires the LastCommit to be empty:
  283. ```go
  284. if block.Header.Height == 1 {
  285. len(b.LastCommit) == 0
  286. }
  287. ```
  288. Otherwise, we require:
  289. ```go
  290. len(block.LastCommit) == len(state.LastValidators)
  291. talliedVotingPower := 0
  292. for i, vote := range block.LastCommit{
  293. if vote == nil{
  294. continue
  295. }
  296. vote.Type == 2
  297. vote.Height == block.LastCommit.Height()
  298. vote.Round == block.LastCommit.Round()
  299. vote.BlockID == block.LastBlockID
  300. val := state.LastValidators[i]
  301. vote.Verify(block.ChainID, val.PubKey) == true
  302. talliedVotingPower += val.VotingPower
  303. }
  304. talliedVotingPower > (2/3) * TotalVotingPower(state.LastValidators)
  305. ```
  306. Includes one (possibly nil) vote for every current validator.
  307. Non-nil votes must be Precommits.
  308. All votes must be for the same height and round.
  309. All votes must be for the previous block.
  310. All votes must have a valid signature from the corresponding validator.
  311. The sum total of the voting power of the validators that voted
  312. must be greater than 2/3 of the total voting power of the complete validator set.
  313. The number of votes in a commit is limited to 10000 (see `types.MaxVotesCount`).
  314. ### Vote
  315. A vote is a signed message broadcast in the consensus for a particular block at a particular height and round.
  316. When stored in the blockchain or propagated over the network, votes are encoded in Amino.
  317. For signing, votes are represented via `CanonicalVote` and also encoded using amino (protobuf compatible) via
  318. `Vote.SignBytes` which includes the `ChainID`, and uses a different ordering of
  319. the fields.
  320. We define a method `Verify` that returns `true` if the signature verifies against the pubkey for the `SignBytes`
  321. using the given ChainID:
  322. ```go
  323. func (vote *Vote) Verify(chainID string, pubKey crypto.PubKey) error {
  324. if !bytes.Equal(pubKey.Address(), vote.ValidatorAddress) {
  325. return ErrVoteInvalidValidatorAddress
  326. }
  327. if !pubKey.VerifyBytes(vote.SignBytes(chainID), vote.Signature) {
  328. return ErrVoteInvalidSignature
  329. }
  330. return nil
  331. }
  332. ```
  333. where `pubKey.Verify` performs the appropriate digital signature verification of the `pubKey`
  334. against the given signature and message bytes.
  335. ## Evidence
  336. There is currently only one kind of evidence, `DuplicateVoteEvidence`.
  337. DuplicateVoteEvidence `ev` is valid if
  338. - `ev.VoteA` and `ev.VoteB` can be verified with `ev.PubKey`
  339. - `ev.VoteA` and `ev.VoteB` have the same `Height, Round, Address, Index, Type`
  340. - `ev.VoteA.BlockID != ev.VoteB.BlockID`
  341. - `(block.Height - ev.VoteA.Height) < MAX_EVIDENCE_AGE`
  342. # Execution
  343. Once a block is validated, it can be executed against the state.
  344. The state follows this recursive equation:
  345. ```go
  346. state(1) = InitialState
  347. state(h+1) <- Execute(state(h), ABCIApp, block(h))
  348. ```
  349. where `InitialState` includes the initial consensus parameters and validator set,
  350. and `ABCIApp` is an ABCI application that can return results and changes to the validator
  351. set (TODO). Execute is defined as:
  352. ```go
  353. Execute(s State, app ABCIApp, block Block) State {
  354. // Fuction ApplyBlock executes block of transactions against the app and returns the new root hash of the app state,
  355. // modifications to the validator set and the changes of the consensus parameters.
  356. AppHash, ValidatorChanges, ConsensusParamChanges := app.ApplyBlock(block)
  357. return State{
  358. LastResults: abciResponses.DeliverTxResults,
  359. AppHash: AppHash,
  360. LastValidators: state.Validators,
  361. Validators: state.NextValidators,
  362. NextValidators: UpdateValidators(state.NextValidators, ValidatorChanges),
  363. ConsensusParams: UpdateConsensusParams(state.ConsensusParams, ConsensusParamChanges),
  364. }
  365. }
  366. ```