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.

367 lines
15 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
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
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
  1. # ABCI Specification
  2. ### XXX
  3. DEPRECATED: Moved [here](../spec/abci/abci.md)
  4. ## Message Types
  5. ABCI requests/responses are defined as simple Protobuf messages in [this
  6. schema file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
  7. TendermintCore sends the requests, and the ABCI application sends the
  8. responses. Here, we provide an overview of the messages types and how
  9. they are used by Tendermint. Then we describe each request-response pair
  10. as a function with arguments and return values, and add some notes on
  11. usage.
  12. Some messages (`Echo, Info, InitChain, BeginBlock, EndBlock, Commit`),
  13. don't return errors because an error would indicate a critical failure
  14. in the application and there's nothing Tendermint can do. The problem
  15. should be addressed and both Tendermint and the application restarted.
  16. All other messages (`SetOption, Query, CheckTx, DeliverTx`) return an
  17. application-specific response `Code uint32`, where only `0` is reserved
  18. for `OK`.
  19. Some messages (`SetOption, Query, CheckTx, DeliverTx`) return
  20. non-deterministic data in the form of `Info` and `Log`. The `Log` is
  21. intended for the literal output from the application's logger, while the
  22. `Info` is any additional info that should be returned.
  23. The first time a new blockchain is started, Tendermint calls
  24. `InitChain`. From then on, the Block Execution Sequence that causes the
  25. committed state to be updated is as follows:
  26. `BeginBlock, [DeliverTx], EndBlock, Commit`
  27. where one `DeliverTx` is called for each transaction in the block.
  28. Cryptographic commitments to the results of DeliverTx, EndBlock, and
  29. Commit are included in the header of the next block.
  30. Tendermint opens three connections to the application to handle the
  31. different message types:
  32. - `Consensus Connection - InitChain, BeginBlock, DeliverTx, EndBlock, Commit`
  33. - `Mempool Connection - CheckTx`
  34. - `Info Connection - Info, SetOption, Query`
  35. The `Flush` message is used on every connection, and the `Echo` message
  36. is only used for debugging.
  37. Note that messages may be sent concurrently across all connections -a
  38. typical application will thus maintain a distinct state for each
  39. connection. They may be referred to as the `DeliverTx state`, the
  40. `CheckTx state`, and the `Commit state` respectively.
  41. See below for more details on the message types and how they are used.
  42. ## Request/Response Messages
  43. ### Echo
  44. - **Request**:
  45. - `Message (string)`: A string to echo back
  46. - **Response**:
  47. - `Message (string)`: The input string
  48. - **Usage**:
  49. - Echo a string to test an abci client/server implementation
  50. ### Flush
  51. - **Usage**:
  52. - Signals that messages queued on the client should be flushed to
  53. the server. It is called periodically by the client
  54. implementation to ensure asynchronous requests are actually
  55. sent, and is called immediately to make a synchronous request,
  56. which returns when the Flush response comes back.
  57. ### Info
  58. - **Request**:
  59. - `Version (string)`: The Tendermint version
  60. - **Response**:
  61. - `Data (string)`: Some arbitrary information
  62. - `Version (Version)`: Version information
  63. - `LastBlockHeight (int64)`: Latest block for which the app has
  64. called Commit
  65. - `LastBlockAppHash ([]byte)`: Latest result of Commit
  66. - **Usage**:
  67. - Return information about the application state.
  68. - Used to sync Tendermint with the application during a handshake
  69. that happens on startup.
  70. - Tendermint expects `LastBlockAppHash` and `LastBlockHeight` to
  71. be updated during `Commit`, ensuring that `Commit` is never
  72. called twice for the same block height.
  73. ### SetOption
  74. - **Request**:
  75. - `Key (string)`: Key to set
  76. - `Value (string)`: Value to set for key
  77. - **Response**:
  78. - `Code (uint32)`: Response code
  79. - `Log (string)`: The output of the application's logger. May
  80. be non-deterministic.
  81. - `Info (string)`: Additional information. May
  82. be non-deterministic.
  83. - **Usage**:
  84. - Set non-consensus critical application specific options.
  85. - e.g. Key="min-fee", Value="100fermion" could set the minimum fee
  86. required for CheckTx (but not DeliverTx - that would be
  87. consensus critical).
  88. ### InitChain
  89. - **Request**:
  90. - `Time (google.protobuf.Timestamp)`: Genesis time.
  91. - `ChainID (string)`: ID of the blockchain.
  92. - `ConsensusParams (ConsensusParams)`: Initial consensus-critical parameters.
  93. - `Validators ([]ValidatorUpdate)`: Initial genesis validators.
  94. - `AppStateBytes ([]byte)`: Serialized initial application state. Amino-encoded JSON bytes.
  95. - **Response**:
  96. - `ConsensusParams (ConsensusParams)`: Initial
  97. consensus-critical parameters.
  98. - `Validators ([]ValidatorUpdate)`: Initial validator set (if non empty).
  99. - **Usage**:
  100. - Called once upon genesis.
  101. - If ResponseInitChain.Validators is empty, the initial validator set will be the RequestInitChain.Validators
  102. - If ResponseInitChain.Validators is not empty, the initial validator set will be the
  103. ResponseInitChain.Validators (regardless of what is in RequestInitChain.Validators).
  104. - This allows the app to decide if it wants to accept the initial validator
  105. set proposed by tendermint (ie. in the genesis file), or if it wants to use
  106. a different one (perhaps computed based on some application specific
  107. information in the genesis file).
  108. ### Query
  109. - **Request**:
  110. - `Data ([]byte)`: Raw query bytes. Can be used with or in lieu
  111. of Path.
  112. - `Path (string)`: Path of request, like an HTTP GET path. Can be
  113. used with or in liue of Data.
  114. - Apps MUST interpret '/store' as a query by key on the
  115. underlying store. The key SHOULD be specified in the Data field.
  116. - Apps SHOULD allow queries over specific types like
  117. '/accounts/...' or '/votes/...'
  118. - `Height (int64)`: The block height for which you want the query
  119. (default=0 returns data for the latest committed block). Note
  120. that this is the height of the block containing the
  121. application's Merkle root hash, which represents the state as it
  122. was after committing the block at Height-1
  123. - `Prove (bool)`: Return Merkle proof with response if possible
  124. - **Response**:
  125. - `Code (uint32)`: Response code.
  126. - `Log (string)`: The output of the application's logger. May
  127. be non-deterministic.
  128. - `Info (string)`: Additional information. May
  129. be non-deterministic.
  130. - `Index (int64)`: The index of the key in the tree.
  131. - `Key ([]byte)`: The key of the matching data.
  132. - `Value ([]byte)`: The value of the matching data.
  133. - `Proof ([]byte)`: Proof for the data, if requested.
  134. - `Height (int64)`: The block height from which data was derived.
  135. Note that this is the height of the block containing the
  136. application's Merkle root hash, which represents the state as it
  137. was after committing the block at Height-1
  138. - **Usage**:
  139. - Query for data from the application at current or past height.
  140. - Optionally return Merkle proof.
  141. ### BeginBlock
  142. - **Request**:
  143. - `Hash ([]byte)`: The block's hash. This can be derived from the
  144. block header.
  145. - `Header (struct{})`: The block header.
  146. - `LastCommitInfo (LastCommitInfo)`: Info about the last commit, including the
  147. round, and the list of validators and which ones signed the last block.
  148. - `ByzantineValidators ([]Evidence)`: List of evidence of
  149. validators that acted maliciously.
  150. - **Response**:
  151. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  152. - **Usage**:
  153. - Signals the beginning of a new block. Called prior to
  154. any DeliverTxs.
  155. - The header contains the height, timestamp, and more - it exactly matches the
  156. Tendermint block header. We may seek to generalize this in the future.
  157. - The `LastCommitInfo` and `ByzantineValidators` can be used to determine
  158. rewards and punishments for the validators. NOTE validators here do not
  159. include pubkeys.
  160. ### CheckTx
  161. - **Request**:
  162. - `Tx ([]byte)`: The request transaction bytes
  163. - **Response**:
  164. - `Code (uint32)`: Response code
  165. - `Data ([]byte)`: Result bytes, if any.
  166. - `Log (string)`: The output of the application's logger. May
  167. be non-deterministic.
  168. - `Info (string)`: Additional information. May
  169. be non-deterministic.
  170. - `GasWanted (int64)`: Amount of gas request for transaction.
  171. - `GasUsed (int64)`: Amount of gas consumed by transaction.
  172. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  173. transactions (eg. by account).
  174. - **Usage**: Validate a mempool transaction, prior to broadcasting
  175. or proposing. CheckTx should perform stateful but light-weight
  176. checks of the validity of the transaction (like checking signatures
  177. and account balances), but need not execute in full (like running a
  178. smart contract).
  179. Tendermint runs CheckTx and DeliverTx concurrently with eachother,
  180. though on distinct ABCI connections - the mempool connection and the
  181. consensus connection, respectively.
  182. The application should maintain a separate state to support CheckTx.
  183. This state can be reset to the latest committed state during
  184. `Commit`. Before calling Commit, Tendermint will lock and flush the mempool,
  185. ensuring that all existing CheckTx are responded to and no new ones can
  186. begin. After `Commit`, the mempool will rerun
  187. CheckTx for all remaining transactions, throwing out any that are no longer valid.
  188. Then the mempool will unlock and start sending CheckTx again.
  189. Keys and values in Tags must be UTF-8 encoded strings (e.g.
  190. "account.owner": "Bob", "balance": "100.0", "date": "2018-01-02")
  191. ### DeliverTx
  192. - **Request**:
  193. - `Tx ([]byte)`: The request transaction bytes.
  194. - **Response**:
  195. - `Code (uint32)`: Response code.
  196. - `Data ([]byte)`: Result bytes, if any.
  197. - `Log (string)`: The output of the application's logger. May
  198. be non-deterministic.
  199. - `Info (string)`: Additional information. May
  200. be non-deterministic.
  201. - `GasWanted (int64)`: Amount of gas requested for transaction.
  202. - `GasUsed (int64)`: Amount of gas consumed by transaction.
  203. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  204. transactions (eg. by account).
  205. - **Usage**:
  206. - Deliver a transaction to be executed in full by the application.
  207. If the transaction is valid, returns CodeType.OK.
  208. - Keys and values in Tags must be UTF-8 encoded strings (e.g.
  209. "account.owner": "Bob", "balance": "100.0",
  210. "time": "2018-01-02T12:30:00Z")
  211. ### EndBlock
  212. - **Request**:
  213. - `Height (int64)`: Height of the block just executed.
  214. - **Response**:
  215. - `ValidatorUpdates ([]ValidatorUpdate)`: Changes to validator set (set
  216. voting power to 0 to remove).
  217. - `ConsensusParamUpdates (ConsensusParams)`: Changes to
  218. consensus-critical time, size, and other parameters.
  219. - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
  220. - **Usage**:
  221. - Signals the end of a block.
  222. - Called prior to each Commit, after all transactions.
  223. - Validator updates returned for block H:
  224. - apply to the NextValidatorsHash of block H+1
  225. - apply to the ValidatorsHash (and thus the validator set) for block H+2
  226. - apply to the RequestBeginBlock.LastCommitInfo (ie. the last validator set) for block H+3
  227. - Consensus params returned for block H apply for block H+1
  228. ### Commit
  229. - **Response**:
  230. - `Data ([]byte)`: The Merkle root hash
  231. - **Usage**:
  232. - Persist the application state.
  233. - Return a Merkle root hash of the application state.
  234. - It's critical that all application instances return the
  235. same hash. If not, they will not be able to agree on the next
  236. block, because the hash is included in the next block!
  237. ## Data Messages
  238. ### Header
  239. - **Fields**:
  240. - `ChainID (string)`: ID of the blockchain
  241. - `Height (int64)`: Height of the block in the chain
  242. - `Time (google.protobuf.Timestamp)`: Time of the block. It is the proposer's
  243. local time when block was created.
  244. - `NumTxs (int32)`: Number of transactions in the block
  245. - `TotalTxs (int64)`: Total number of transactions in the blockchain until
  246. now
  247. - `LastBlockID (BlockID)`: Hash of the previous (parent) block
  248. - `LastCommitHash ([]byte)`: Hash of the previous block's commit
  249. - `ValidatorsHash ([]byte)`: Hash of the validator set for this block
  250. - `NextValidatorsHash ([]byte)`: Hash of the validator set for the next block
  251. - `ConsensusHash ([]byte)`: Hash of the consensus parameters for this block
  252. - `AppHash ([]byte)`: Data returned by the last call to `Commit` - typically the
  253. Merkle root of the application state after executing the previous block's
  254. transactions
  255. - `LastResultsHash ([]byte)`: Hash of the ABCI results returned by the last block
  256. - `EvidenceHash ([]byte)`: Hash of the evidence included in this block
  257. - `ProposerAddress ([]byte)`: Original proposer for the block
  258. - **Usage**:
  259. - Provided in RequestBeginBlock
  260. - Provides important context about the current state of the blockchain -
  261. especially height and time.
  262. - Provides the proposer of the current block, for use in proposer-based
  263. reward mechanisms.
  264. ### Validator
  265. - **Fields**:
  266. - `Address ([]byte)`: Address of the validator (hash of the public key)
  267. - `Power (int64)`: Voting power of the validator
  268. - **Usage**:
  269. - Validator identified by address
  270. - Used in RequestBeginBlock as part of VoteInfo
  271. - Does not include PubKey to avoid sending potentially large quantum pubkeys
  272. over the ABCI
  273. ### ValidatorUpdate
  274. - **Fields**:
  275. - `PubKey (PubKey)`: Public key of the validator
  276. - `Power (int64)`: Voting power of the validator
  277. - **Usage**:
  278. - Validator identified by PubKey
  279. - Used to tell Tendermint to update the validator set
  280. ### VoteInfo
  281. - **Fields**:
  282. - `Validator (Validator)`: A validator
  283. - `SignedLastBlock (bool)`: Indicates whether or not the validator signed
  284. the last block
  285. - **Usage**:
  286. - Indicates whether a validator signed the last block, allowing for rewards
  287. based on validator availability
  288. ### PubKey
  289. - **Fields**:
  290. - `Type (string)`: Type of the public key. A simple string like `"ed25519"`.
  291. In the future, may indicate a serialization algorithm to parse the `Data`,
  292. for instance `"amino"`.
  293. - `Data ([]byte)`: Public key data. For a simple public key, it's just the
  294. raw bytes. If the `Type` indicates an encoding algorithm, this is the
  295. encoded public key.
  296. - **Usage**:
  297. - A generic and extensible typed public key
  298. ### Evidence
  299. - **Fields**:
  300. - `Type (string)`: Type of the evidence. A hierarchical path like
  301. "duplicate/vote".
  302. - `Validator (Validator`: The offending validator
  303. - `Height (int64)`: Height when the offense was committed
  304. - `Time (google.protobuf.Timestamp)`: Time of the block at height `Height`.
  305. It is the proposer's local time when block was created.
  306. - `TotalVotingPower (int64)`: Total voting power of the validator set at
  307. height `Height`
  308. ### LastCommitInfo
  309. - **Fields**:
  310. - `Round (int32)`: Commit round.
  311. - `Votes ([]VoteInfo)`: List of validators addresses in the last validator set
  312. with their voting power and whether or not they signed a vote.