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.

458 lines
18 KiB

6 years ago
  1. # Methods and Types
  2. ## Overview
  3. The ABCI message types are defined in a [protobuf
  4. file](https://github.com/tendermint/tendermint/blob/develop/abci/types/types.proto).
  5. ABCI methods are split across 3 separate ABCI *connections*:
  6. - `Consensus Connection`: `InitChain, BeginBlock, DeliverTx, EndBlock, Commit`
  7. - `Mempool Connection`: `CheckTx`
  8. - `Info Connection`: `Info, SetOption, Query`
  9. The `Consensus Connection` is driven by a consensus protocol and is responsible
  10. for block execution.
  11. The `Mempool Connection` is for validating new transactions, before they're
  12. shared or included in a block.
  13. The `Info Connection` is for initialization and for queries from the user.
  14. Additionally, there is a `Flush` method that is called on every connection,
  15. and an `Echo` method that is just for debugging.
  16. More details on managing state across connections can be found in the section on
  17. [ABCI Applications](apps.md).
  18. ## Errors
  19. Some methods (`Echo, Info, InitChain, BeginBlock, EndBlock, Commit`),
  20. don't return errors because an error would indicate a critical failure
  21. in the application and there's nothing Tendermint can do. The problem
  22. should be addressed and both Tendermint and the application restarted.
  23. All other methods (`SetOption, Query, CheckTx, DeliverTx`) return an
  24. application-specific response `Code uint32`, where only `0` is reserved
  25. for `OK`.
  26. ## Tags
  27. Some methods (`CheckTx, BeginBlock, DeliverTx, EndBlock`)
  28. include a `Tags` field in their `Response*`. Each tag is key-value pair denoting
  29. something about what happened during the methods execution.
  30. Tags can be used to index transactions and blocks according to what happened
  31. during their execution.
  32. Keys and values in tags must be UTF-8 encoded strings (e.g.
  33. "account.owner": "Bob", "balance": "100.0",
  34. "time": "2018-01-02T12:30:00Z")
  35. ## Determinism
  36. ABCI applications must implement deterministic finite-state machines to be
  37. securely replicated by the Tendermint consensus. This means block execution
  38. over the Consensus Connection must be strictly deterministic: given the same
  39. ordered set of requests, all nodes will compute identical responses, for all
  40. BeginBlock, DeliverTx, EndBlock, and Commit. This is critical, because the
  41. responses are included in the header of the next block, either via a Merkle root
  42. or directly, so all nodes must agree on exactly what they are.
  43. For this reason, it is recommended that applications not be exposed to any
  44. external user or process except via the ABCI connections to a consensus engine
  45. like Tendermint Core. The application must only change its state based on input
  46. from block execution (BeginBlock, DeliverTx, EndBlock, Commit), and not through
  47. any other kind of request. This is the only way to ensure all nodes see the same
  48. transactions and compute the same results.
  49. If there is some non-determinism in the state machine, consensus will eventually
  50. fail as nodes disagree over the correct values for the block header. The
  51. non-determinism must be fixed and the nodes restarted.
  52. Sources of non-determinism in applications may include:
  53. - Hardware failures
  54. - Cosmic rays, overheating, etc.
  55. - Node-dependent state
  56. - Random numbers
  57. - Time
  58. - Underspecification
  59. - Library version changes
  60. - Race conditions
  61. - Floating point numbers
  62. - JSON serialization
  63. - Iterating through hash-tables/maps/dictionaries
  64. - External Sources
  65. - Filesystem
  66. - Network calls (eg. some external REST API service)
  67. See [#56](https://github.com/tendermint/abci/issues/56) for original discussion.
  68. Note that some methods (`SetOption, Query, CheckTx, DeliverTx`) return
  69. explicitly non-deterministic data in the form of `Info` and `Log` fields. The `Log` is
  70. intended for the literal output from the application's logger, while the
  71. `Info` is any additional info that should be returned. These are the only fields
  72. that are not included in block header computations, so we don't need agreement
  73. on them. All other fields in the `Response*` must be strictly deterministic.
  74. ## Block Execution
  75. The first time a new blockchain is started, Tendermint calls
  76. `InitChain`. From then on, the follow sequence of methods is executed for each
  77. block:
  78. `BeginBlock, [DeliverTx], EndBlock, Commit`
  79. where one `DeliverTx` is called for each transaction in the block.
  80. The result is an updated application state.
  81. Cryptographic commitments to the results of DeliverTx, EndBlock, and
  82. Commit are included in the header of the next block.
  83. ## Messages
  84. ### Echo
  85. - **Request**:
  86. - `Message (string)`: A string to echo back
  87. - **Response**:
  88. - `Message (string)`: The input string
  89. - **Usage**:
  90. - Echo a string to test an abci client/server implementation
  91. ### Flush
  92. - **Usage**:
  93. - Signals that messages queued on the client should be flushed to
  94. the server. It is called periodically by the client
  95. implementation to ensure asynchronous requests are actually
  96. sent, and is called immediately to make a synchronous request,
  97. which returns when the Flush response comes back.
  98. ### Info
  99. - **Request**:
  100. - `Version (string)`: The Tendermint version
  101. - **Response**:
  102. - `Data (string)`: Some arbitrary information
  103. - `Version (Version)`: Version information
  104. - `LastBlockHeight (int64)`: Latest block for which the app has
  105. called Commit
  106. - `LastBlockAppHash ([]byte)`: Latest result of Commit
  107. - **Usage**:
  108. - Return information about the application state.
  109. - Used to sync Tendermint with the application during a handshake
  110. that happens on startup.
  111. - Tendermint expects `LastBlockAppHash` and `LastBlockHeight` to
  112. be updated during `Commit`, ensuring that `Commit` is never
  113. called twice for the same block height.
  114. ### SetOption
  115. - **Request**:
  116. - `Key (string)`: Key to set
  117. - `Value (string)`: Value to set for key
  118. - **Response**:
  119. - `Code (uint32)`: Response code
  120. - `Log (string)`: The output of the application's logger. May
  121. be non-deterministic.
  122. - `Info (string)`: Additional information. May
  123. be non-deterministic.
  124. - **Usage**:
  125. - Set non-consensus critical application specific options.
  126. - e.g. Key="min-fee", Value="100fermion" could set the minimum fee
  127. required for CheckTx (but not DeliverTx - that would be
  128. consensus critical).
  129. ### InitChain
  130. - **Request**:
  131. - `Time (google.protobuf.Timestamp)`: Genesis time.
  132. - `ChainID (string)`: ID of the blockchain.
  133. - `ConsensusParams (ConsensusParams)`: Initial consensus-critical parameters.
  134. - `Validators ([]ValidatorUpdate)`: Initial genesis validators.
  135. - `AppStateBytes ([]byte)`: Serialized initial application state. Amino-encoded JSON bytes.
  136. - **Response**:
  137. - `ConsensusParams (ConsensusParams)`: Initial
  138. consensus-critical parameters.
  139. - `Validators ([]ValidatorUpdate)`: Initial validator set (if non empty).
  140. - **Usage**:
  141. - Called once upon genesis.
  142. - If ResponseInitChain.Validators is empty, the initial validator set will be the RequestInitChain.Validators
  143. - If ResponseInitChain.Validators is not empty, the initial validator set will be the
  144. ResponseInitChain.Validators (regardless of what is in RequestInitChain.Validators).
  145. - This allows the app to decide if it wants to accept the initial validator
  146. set proposed by tendermint (ie. in the genesis file), or if it wants to use
  147. a different one (perhaps computed based on some application specific
  148. information in the genesis file).
  149. ### Query
  150. - **Request**:
  151. - `Data ([]byte)`: Raw query bytes. Can be used with or in lieu
  152. of Path.
  153. - `Path (string)`: Path of request, like an HTTP GET path. Can be
  154. used with or in liue of Data.
  155. - Apps MUST interpret '/store' as a query by key on the
  156. underlying store. The key SHOULD be specified in the Data field.
  157. - Apps SHOULD allow queries over specific types like
  158. '/accounts/...' or '/votes/...'
  159. - `Height (int64)`: The block height for which you want the query
  160. (default=0 returns data for the latest committed block). Note
  161. that this is the height of the block containing the
  162. application's Merkle root hash, which represents the state as it
  163. was after committing the block at Height-1
  164. - `Prove (bool)`: Return Merkle proof with response if possible
  165. - **Response**:
  166. - `Code (uint32)`: Response code.
  167. - `Log (string)`: The output of the application's logger. May
  168. be non-deterministic.
  169. - `Info (string)`: Additional information. May
  170. be non-deterministic.
  171. - `Index (int64)`: The index of the key in the tree.
  172. - `Key ([]byte)`: The key of the matching data.
  173. - `Value ([]byte)`: The value of the matching data.
  174. - `Proof (Proof)`: Serialized proof for the value data, if requested, to be
  175. verified against the `AppHash` for the given Height.
  176. - `Height (int64)`: The block height from which data was derived.
  177. Note that this is the height of the block containing the
  178. application's Merkle root hash, which represents the state as it
  179. was after committing the block at Height-1
  180. - **Usage**:
  181. - Query for data from the application at current or past height.
  182. - Optionally return Merkle proof.
  183. - Merkle proof includes self-describing `type` field to support many types
  184. of Merkle trees and encoding formats.
  185. ### BeginBlock
  186. - **Request**:
  187. - `Hash ([]byte)`: The block's hash. This can be derived from the
  188. block header.
  189. - `Header (struct{})`: The block header.
  190. - `LastCommitInfo (LastCommitInfo)`: Info about the last commit, including the
  191. round, and the list of validators and which ones signed the last block.
  192. - `ByzantineValidators ([]Evidence)`: List of evidence of
  193. validators that acted maliciously.
  194. - **Response**:
  195. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  196. - **Usage**:
  197. - Signals the beginning of a new block. Called prior to
  198. any DeliverTxs.
  199. - The header contains the height, timestamp, and more - it exactly matches the
  200. Tendermint block header. We may seek to generalize this in the future.
  201. - The `LastCommitInfo` and `ByzantineValidators` can be used to determine
  202. rewards and punishments for the validators. NOTE validators here do not
  203. include pubkeys.
  204. ### CheckTx
  205. - **Request**:
  206. - `Tx ([]byte)`: The request transaction bytes
  207. - **Response**:
  208. - `Code (uint32)`: Response code
  209. - `Data ([]byte)`: Result bytes, if any.
  210. - `Log (string)`: The output of the application's logger. May
  211. be non-deterministic.
  212. - `Info (string)`: Additional information. May
  213. be non-deterministic.
  214. - `GasWanted (int64)`: Amount of gas requested for transaction.
  215. - `GasUsed (int64)`: Amount of gas consumed by transaction.
  216. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  217. transactions (eg. by account).
  218. - **Usage**:
  219. - Technically optional - not involved in processing blocks.
  220. - Guardian of the mempool: every node runs CheckTx before letting a
  221. transaction into its local mempool.
  222. - The transaction may come from an external user or another node
  223. - CheckTx need not execute the transaction in full, but rather a light-weight
  224. yet stateful validation, like checking signatures and account balances, but
  225. not running code in a virtual machine.
  226. - Transactions where `ResponseCheckTx.Code != 0` will be rejected - they will not be broadcast to
  227. other nodes or included in a proposal block.
  228. - Tendermint attributes no other value to the response code
  229. ### DeliverTx
  230. - **Request**:
  231. - `Tx ([]byte)`: The request transaction bytes.
  232. - **Response**:
  233. - `Code (uint32)`: Response code.
  234. - `Data ([]byte)`: Result bytes, if any.
  235. - `Log (string)`: The output of the application's logger. May
  236. be non-deterministic.
  237. - `Info (string)`: Additional information. May
  238. be non-deterministic.
  239. - `GasWanted (int64)`: Amount of gas requested for transaction.
  240. - `GasUsed (int64)`: Amount of gas consumed by transaction.
  241. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  242. transactions (eg. by account).
  243. - **Usage**:
  244. - The workhorse of the application - non-optional.
  245. - Execute the transaction in full.
  246. - `ResponseDeliverTx.Code == 0` only if the transaction is fully valid.
  247. ### EndBlock
  248. - **Request**:
  249. - `Height (int64)`: Height of the block just executed.
  250. - **Response**:
  251. - `ValidatorUpdates ([]ValidatorUpdate)`: Changes to validator set (set
  252. voting power to 0 to remove).
  253. - `ConsensusParamUpdates (ConsensusParams)`: Changes to
  254. consensus-critical time, size, and other parameters.
  255. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  256. - **Usage**:
  257. - Signals the end of a block.
  258. - Called after all transactions, prior to each Commit.
  259. - Validator updates returned by block `H` impact blocks `H+1`, `H+2`, and
  260. `H+3`, but only effects changes on the validator set of `H+2`:
  261. - `H+1`: NextValidatorsHash
  262. - `H+2`: ValidatorsHash (and thus the validator set)
  263. - `H+3`: LastCommitInfo (ie. the last validator set)
  264. - Consensus params returned for block `H` apply for block `H+1`
  265. ### Commit
  266. - **Response**:
  267. - `Data ([]byte)`: The Merkle root hash of the application state
  268. - **Usage**:
  269. - Persist the application state.
  270. - Return an (optional) Merkle root hash of the application state
  271. - `ResponseCommit.Data` is included as the `Header.AppHash` in the next block
  272. - it may be empty
  273. - Later calls to `Query` can return proofs about the application state anchored
  274. in this Merkle root hash
  275. - Note developers can return whatever they want here (could be nothing, or a
  276. constant string, etc.), so long as it is deterministic - it must not be a
  277. function of anything that did not come from the
  278. BeginBlock/DeliverTx/EndBlock methods.
  279. ## Data Types
  280. ### Header
  281. - **Fields**:
  282. - `ChainID (string)`: ID of the blockchain
  283. - `Height (int64)`: Height of the block in the chain
  284. - `Time (google.protobuf.Timestamp)`: Time of the block. It is the proposer's
  285. local time when block was created.
  286. - `NumTxs (int32)`: Number of transactions in the block
  287. - `TotalTxs (int64)`: Total number of transactions in the blockchain until
  288. now
  289. - `LastBlockID (BlockID)`: Hash of the previous (parent) block
  290. - `LastCommitHash ([]byte)`: Hash of the previous block's commit
  291. - `ValidatorsHash ([]byte)`: Hash of the validator set for this block
  292. - `NextValidatorsHash ([]byte)`: Hash of the validator set for the next block
  293. - `ConsensusHash ([]byte)`: Hash of the consensus parameters for this block
  294. - `AppHash ([]byte)`: Data returned by the last call to `Commit` - typically the
  295. Merkle root of the application state after executing the previous block's
  296. transactions
  297. - `LastResultsHash ([]byte)`: Hash of the ABCI results returned by the last block
  298. - `EvidenceHash ([]byte)`: Hash of the evidence included in this block
  299. - `ProposerAddress ([]byte)`: Original proposer for the block
  300. - **Usage**:
  301. - Provided in RequestBeginBlock
  302. - Provides important context about the current state of the blockchain -
  303. especially height and time.
  304. - Provides the proposer of the current block, for use in proposer-based
  305. reward mechanisms.
  306. ### Validator
  307. - **Fields**:
  308. - `Address ([]byte)`: Address of the validator (hash of the public key)
  309. - `Power (int64)`: Voting power of the validator
  310. - **Usage**:
  311. - Validator identified by address
  312. - Used in RequestBeginBlock as part of VoteInfo
  313. - Does not include PubKey to avoid sending potentially large quantum pubkeys
  314. over the ABCI
  315. ### ValidatorUpdate
  316. - **Fields**:
  317. - `PubKey (PubKey)`: Public key of the validator
  318. - `Power (int64)`: Voting power of the validator
  319. - **Usage**:
  320. - Validator identified by PubKey
  321. - Used to tell Tendermint to update the validator set
  322. ### VoteInfo
  323. - **Fields**:
  324. - `Validator (Validator)`: A validator
  325. - `SignedLastBlock (bool)`: Indicates whether or not the validator signed
  326. the last block
  327. - **Usage**:
  328. - Indicates whether a validator signed the last block, allowing for rewards
  329. based on validator availability
  330. ### PubKey
  331. - **Fields**:
  332. - `Type (string)`: Type of the public key. A simple string like `"ed25519"`.
  333. In the future, may indicate a serialization algorithm to parse the `Data`,
  334. for instance `"amino"`.
  335. - `Data ([]byte)`: Public key data. For a simple public key, it's just the
  336. raw bytes. If the `Type` indicates an encoding algorithm, this is the
  337. encoded public key.
  338. - **Usage**:
  339. - A generic and extensible typed public key
  340. ### Evidence
  341. - **Fields**:
  342. - `Type (string)`: Type of the evidence. A hierarchical path like
  343. "duplicate/vote".
  344. - `Validator (Validator`: The offending validator
  345. - `Height (int64)`: Height when the offense was committed
  346. - `Time (google.protobuf.Timestamp)`: Time of the block at height `Height`.
  347. It is the proposer's local time when block was created.
  348. - `TotalVotingPower (int64)`: Total voting power of the validator set at
  349. height `Height`
  350. ### LastCommitInfo
  351. - **Fields**:
  352. - `Round (int32)`: Commit round.
  353. - `Votes ([]VoteInfo)`: List of validators addresses in the last validator set
  354. with their voting power and whether or not they signed a vote.
  355. ### ConsensusParams
  356. - **Fields**:
  357. - `BlockSize (BlockSize)`: Parameters limiting the size of a block.
  358. - `EvidenceParams (EvidenceParams)`: Parameters limiting the validity of
  359. evidence of byzantine behaviour.
  360. ### BlockSize
  361. - **Fields**:
  362. - `MaxBytes (int64)`: Max size of a block, in bytes.
  363. - `MaxGas (int64)`: Max sum of `GasWanted` in a proposed block.
  364. - NOTE: blocks that violate this may be committed if there are Byzantine proposers.
  365. It's the application's responsibility to handle this when processing a
  366. block!
  367. ### EvidenceParams
  368. - **Fields**:
  369. - `MaxAge (int64)`: Max age of evidence, in blocks. Evidence older than this
  370. is considered stale and ignored.
  371. - This should correspond with an app's "unbonding period" or other
  372. similar mechanism for handling Nothing-At-Stake attacks.
  373. - NOTE: this should change to time (instead of blocks)!
  374. ### Proof
  375. - **Fields**:
  376. - `Ops ([]ProofOp)`: List of chained Merkle proofs, of possibly different types
  377. - The Merkle root of one op is the value being proven in the next op.
  378. - The Merkle root of the final op should equal the ultimate root hash being
  379. verified against.
  380. ### ProofOp
  381. - **Fields**:
  382. - `Type (string)`: Type of Merkle proof and how it's encoded.
  383. - `Key ([]byte)`: Key in the Merkle tree that this proof is for.
  384. - `Data ([]byte)`: Encoded Merkle proof for the key.