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.

530 lines
21 KiB

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