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.

532 lines
21 KiB

6 years ago
abci: Refactor tagging events using list of lists (#3643) ## PR This PR introduces a fundamental breaking change to the structure of ABCI response and tx tags and the way they're processed. Namely, the SDK can support more complex and aggregated events for distribution and slashing. In addition, block responses can include duplicate keys in events. Implement new Event type. An event has a type and a list of KV pairs (ie. list-of-lists). Typical events may look like: "rewards": [{"amount": "5000uatom", "validator": "...", "recipient": "..."}] "sender": [{"address": "...", "balance": "100uatom"}] The events are indexed by {even.type}.{even.attribute[i].key}/.... In this case a client would subscribe or query for rewards.recipient='...' ABCI response types and related types now include Events []Event instead of Tags []cmn.KVPair. PubSub logic now publishes/matches against map[string][]string instead of map[string]string to support duplicate keys in response events (from #1385). A match is successful if the value is found in the slice of strings. closes: #1859 closes: #2905 ## Commits: * Implement Event ABCI type and updates responses to use events * Update messages_test.go * Update kvstore.go * Update event_bus.go * Update subscription.go * Update pubsub.go * Update kvstore.go * Update query logic to handle slice of strings in events * Update Empty#Matches and unit tests * Update pubsub logic * Update EventBus#Publish * Update kv tx indexer * Update godocs * Update ResultEvent to use slice of strings; update RPC * Update more tests * Update abci.md * Check for key in validateAndStringifyEvents * Fix KV indexer to skip empty keys * Fix linting errors * Update CHANGELOG_PENDING.md * Update docs/spec/abci/abci.md Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * Update abci/types/types.proto Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/abci/abci.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update libs/pubsub/query/query.go Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update match function to match if ANY value matches * Implement TestSubscribeDuplicateKeys * Update TestMatches to include multi-key test cases * Update events.go * Update Query interface godoc * Update match godoc * Add godoc for matchValue * DRY-up tx indexing * Return error from PublishWithEvents in EventBus#Publish * Update PublishEventNewBlockHeader to return an error * Fix build * Update events doc in ABCI * Update ABCI events godoc * Implement TestEventBusPublishEventTxDuplicateKeys * Update TestSubscribeDuplicateKeys to be table-driven * Remove mod file * Remove markdown from events godoc * Implement TestTxSearchDeprecatedIndexing test
6 years ago
abci: Refactor tagging events using list of lists (#3643) ## PR This PR introduces a fundamental breaking change to the structure of ABCI response and tx tags and the way they're processed. Namely, the SDK can support more complex and aggregated events for distribution and slashing. In addition, block responses can include duplicate keys in events. Implement new Event type. An event has a type and a list of KV pairs (ie. list-of-lists). Typical events may look like: "rewards": [{"amount": "5000uatom", "validator": "...", "recipient": "..."}] "sender": [{"address": "...", "balance": "100uatom"}] The events are indexed by {even.type}.{even.attribute[i].key}/.... In this case a client would subscribe or query for rewards.recipient='...' ABCI response types and related types now include Events []Event instead of Tags []cmn.KVPair. PubSub logic now publishes/matches against map[string][]string instead of map[string]string to support duplicate keys in response events (from #1385). A match is successful if the value is found in the slice of strings. closes: #1859 closes: #2905 ## Commits: * Implement Event ABCI type and updates responses to use events * Update messages_test.go * Update kvstore.go * Update event_bus.go * Update subscription.go * Update pubsub.go * Update kvstore.go * Update query logic to handle slice of strings in events * Update Empty#Matches and unit tests * Update pubsub logic * Update EventBus#Publish * Update kv tx indexer * Update godocs * Update ResultEvent to use slice of strings; update RPC * Update more tests * Update abci.md * Check for key in validateAndStringifyEvents * Fix KV indexer to skip empty keys * Fix linting errors * Update CHANGELOG_PENDING.md * Update docs/spec/abci/abci.md Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * Update abci/types/types.proto Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/abci/abci.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update libs/pubsub/query/query.go Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update match function to match if ANY value matches * Implement TestSubscribeDuplicateKeys * Update TestMatches to include multi-key test cases * Update events.go * Update Query interface godoc * Update match godoc * Add godoc for matchValue * DRY-up tx indexing * Return error from PublishWithEvents in EventBus#Publish * Update PublishEventNewBlockHeader to return an error * Fix build * Update events doc in ABCI * Update ABCI events godoc * Implement TestEventBusPublishEventTxDuplicateKeys * Update TestSubscribeDuplicateKeys to be table-driven * Remove mod file * Remove markdown from events godoc * Implement TestTxSearchDeprecatedIndexing test
6 years ago
abci: Refactor tagging events using list of lists (#3643) ## PR This PR introduces a fundamental breaking change to the structure of ABCI response and tx tags and the way they're processed. Namely, the SDK can support more complex and aggregated events for distribution and slashing. In addition, block responses can include duplicate keys in events. Implement new Event type. An event has a type and a list of KV pairs (ie. list-of-lists). Typical events may look like: "rewards": [{"amount": "5000uatom", "validator": "...", "recipient": "..."}] "sender": [{"address": "...", "balance": "100uatom"}] The events are indexed by {even.type}.{even.attribute[i].key}/.... In this case a client would subscribe or query for rewards.recipient='...' ABCI response types and related types now include Events []Event instead of Tags []cmn.KVPair. PubSub logic now publishes/matches against map[string][]string instead of map[string]string to support duplicate keys in response events (from #1385). A match is successful if the value is found in the slice of strings. closes: #1859 closes: #2905 ## Commits: * Implement Event ABCI type and updates responses to use events * Update messages_test.go * Update kvstore.go * Update event_bus.go * Update subscription.go * Update pubsub.go * Update kvstore.go * Update query logic to handle slice of strings in events * Update Empty#Matches and unit tests * Update pubsub logic * Update EventBus#Publish * Update kv tx indexer * Update godocs * Update ResultEvent to use slice of strings; update RPC * Update more tests * Update abci.md * Check for key in validateAndStringifyEvents * Fix KV indexer to skip empty keys * Fix linting errors * Update CHANGELOG_PENDING.md * Update docs/spec/abci/abci.md Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * Update abci/types/types.proto Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/abci/abci.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update libs/pubsub/query/query.go Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update match function to match if ANY value matches * Implement TestSubscribeDuplicateKeys * Update TestMatches to include multi-key test cases * Update events.go * Update Query interface godoc * Update match godoc * Add godoc for matchValue * DRY-up tx indexing * Return error from PublishWithEvents in EventBus#Publish * Update PublishEventNewBlockHeader to return an error * Fix build * Update events doc in ABCI * Update ABCI events godoc * Implement TestEventBusPublishEventTxDuplicateKeys * Update TestSubscribeDuplicateKeys to be table-driven * Remove mod file * Remove markdown from events godoc * Implement TestTxSearchDeprecatedIndexing test
6 years ago
abci: Refactor tagging events using list of lists (#3643) ## PR This PR introduces a fundamental breaking change to the structure of ABCI response and tx tags and the way they're processed. Namely, the SDK can support more complex and aggregated events for distribution and slashing. In addition, block responses can include duplicate keys in events. Implement new Event type. An event has a type and a list of KV pairs (ie. list-of-lists). Typical events may look like: "rewards": [{"amount": "5000uatom", "validator": "...", "recipient": "..."}] "sender": [{"address": "...", "balance": "100uatom"}] The events are indexed by {even.type}.{even.attribute[i].key}/.... In this case a client would subscribe or query for rewards.recipient='...' ABCI response types and related types now include Events []Event instead of Tags []cmn.KVPair. PubSub logic now publishes/matches against map[string][]string instead of map[string]string to support duplicate keys in response events (from #1385). A match is successful if the value is found in the slice of strings. closes: #1859 closes: #2905 ## Commits: * Implement Event ABCI type and updates responses to use events * Update messages_test.go * Update kvstore.go * Update event_bus.go * Update subscription.go * Update pubsub.go * Update kvstore.go * Update query logic to handle slice of strings in events * Update Empty#Matches and unit tests * Update pubsub logic * Update EventBus#Publish * Update kv tx indexer * Update godocs * Update ResultEvent to use slice of strings; update RPC * Update more tests * Update abci.md * Check for key in validateAndStringifyEvents * Fix KV indexer to skip empty keys * Fix linting errors * Update CHANGELOG_PENDING.md * Update docs/spec/abci/abci.md Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * Update abci/types/types.proto Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/abci/abci.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update libs/pubsub/query/query.go Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update match function to match if ANY value matches * Implement TestSubscribeDuplicateKeys * Update TestMatches to include multi-key test cases * Update events.go * Update Query interface godoc * Update match godoc * Add godoc for matchValue * DRY-up tx indexing * Return error from PublishWithEvents in EventBus#Publish * Update PublishEventNewBlockHeader to return an error * Fix build * Update events doc in ABCI * Update ABCI events godoc * Implement TestEventBusPublishEventTxDuplicateKeys * Update TestSubscribeDuplicateKeys to be table-driven * Remove mod file * Remove markdown from events godoc * Implement TestTxSearchDeprecatedIndexing test
6 years ago
abci: Refactor tagging events using list of lists (#3643) ## PR This PR introduces a fundamental breaking change to the structure of ABCI response and tx tags and the way they're processed. Namely, the SDK can support more complex and aggregated events for distribution and slashing. In addition, block responses can include duplicate keys in events. Implement new Event type. An event has a type and a list of KV pairs (ie. list-of-lists). Typical events may look like: "rewards": [{"amount": "5000uatom", "validator": "...", "recipient": "..."}] "sender": [{"address": "...", "balance": "100uatom"}] The events are indexed by {even.type}.{even.attribute[i].key}/.... In this case a client would subscribe or query for rewards.recipient='...' ABCI response types and related types now include Events []Event instead of Tags []cmn.KVPair. PubSub logic now publishes/matches against map[string][]string instead of map[string]string to support duplicate keys in response events (from #1385). A match is successful if the value is found in the slice of strings. closes: #1859 closes: #2905 ## Commits: * Implement Event ABCI type and updates responses to use events * Update messages_test.go * Update kvstore.go * Update event_bus.go * Update subscription.go * Update pubsub.go * Update kvstore.go * Update query logic to handle slice of strings in events * Update Empty#Matches and unit tests * Update pubsub logic * Update EventBus#Publish * Update kv tx indexer * Update godocs * Update ResultEvent to use slice of strings; update RPC * Update more tests * Update abci.md * Check for key in validateAndStringifyEvents * Fix KV indexer to skip empty keys * Fix linting errors * Update CHANGELOG_PENDING.md * Update docs/spec/abci/abci.md Co-Authored-By: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * Update abci/types/types.proto Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update docs/spec/abci/abci.md Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update libs/pubsub/query/query.go Co-Authored-By: Ethan Buchman <ethan@coinculture.info> * Update match function to match if ANY value matches * Implement TestSubscribeDuplicateKeys * Update TestMatches to include multi-key test cases * Update events.go * Update Query interface godoc * Update match godoc * Add godoc for matchValue * DRY-up tx indexing * Return error from PublishWithEvents in EventBus#Publish * Update PublishEventNewBlockHeader to return an error * Fix build * Update events doc in ABCI * Update ABCI events godoc * Implement TestEventBusPublishEventTxDuplicateKeys * Update TestSubscribeDuplicateKeys to be table-driven * Remove mod file * Remove markdown from events godoc * Implement TestTxSearchDeprecatedIndexing test
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/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 even type itself.
  43. Example:
  44. ```go
  45. abci.ResponseDeliverTx{
  46. // ...
  47. Events: []abci.Event{
  48. {
  49. Type: "validator.provisions",
  50. Attributes: cmn.KVPairs{
  51. cmn.KVPair{Key: []byte("address"), Value: []byte("...")},
  52. cmn.KVPair{Key: []byte("amount"), Value: []byte("...")},
  53. cmn.KVPair{Key: []byte("balance"), Value: []byte("...")},
  54. },
  55. },
  56. {
  57. Type: "validator.provisions",
  58. Attributes: cmn.KVPairs{
  59. cmn.KVPair{Key: []byte("address"), Value: []byte("...")},
  60. cmn.KVPair{Key: []byte("amount"), Value: []byte("...")},
  61. cmn.KVPair{Key: []byte("balance"), Value: []byte("...")},
  62. },
  63. },
  64. {
  65. Type: "validator.slashed",
  66. Attributes: cmn.KVPairs{
  67. cmn.KVPair{Key: []byte("address"), Value: []byte("...")},
  68. cmn.KVPair{Key: []byte("amount"), Value: []byte("...")},
  69. cmn.KVPair{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 ([]cmn.KVPair)`: 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 ([]cmn.KVPair)`: 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 ([]cmn.KVPair)`: 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 ([]cmn.KVPair)`: 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. - `NumTxs (int32)`: Number of transactions in the block
  342. - `TotalTxs (int64)`: Total number of transactions in the blockchain until
  343. now
  344. - `LastBlockID (BlockID)`: Hash of the previous (parent) block
  345. - `LastCommitHash ([]byte)`: Hash of the previous block's commit
  346. - `ValidatorsHash ([]byte)`: Hash of the validator set for this block
  347. - `NextValidatorsHash ([]byte)`: Hash of the validator set for the next block
  348. - `ConsensusHash ([]byte)`: Hash of the consensus parameters for this block
  349. - `AppHash ([]byte)`: Data returned by the last call to `Commit` - typically the
  350. Merkle root of the application state after executing the previous block's
  351. transactions
  352. - `LastResultsHash ([]byte)`: Hash of the ABCI results returned by the last block
  353. - `EvidenceHash ([]byte)`: Hash of the evidence included in this block
  354. - `ProposerAddress ([]byte)`: Original proposer for the block
  355. - **Usage**:
  356. - Provided in RequestBeginBlock
  357. - Provides important context about the current state of the blockchain -
  358. especially height and time.
  359. - Provides the proposer of the current block, for use in proposer-based
  360. reward mechanisms.
  361. ### Version
  362. - **Fields**:
  363. - `Block (uint64)`: Protocol version of the blockchain data structures.
  364. - `App (uint64)`: Protocol version of the application.
  365. - **Usage**:
  366. - Block version should be static in the life of a blockchain.
  367. - App version may be updated over time by the application.
  368. ### Validator
  369. - **Fields**:
  370. - `Address ([]byte)`: Address of the validator (hash of the public key)
  371. - `Power (int64)`: Voting power of the validator
  372. - **Usage**:
  373. - Validator identified by address
  374. - Used in RequestBeginBlock as part of VoteInfo
  375. - Does not include PubKey to avoid sending potentially large quantum pubkeys
  376. over the ABCI
  377. ### ValidatorUpdate
  378. - **Fields**:
  379. - `PubKey (PubKey)`: Public key of the validator
  380. - `Power (int64)`: Voting power of the validator
  381. - **Usage**:
  382. - Validator identified by PubKey
  383. - Used to tell Tendermint to update the validator set
  384. ### VoteInfo
  385. - **Fields**:
  386. - `Validator (Validator)`: A validator
  387. - `SignedLastBlock (bool)`: Indicates whether or not the validator signed
  388. the last block
  389. - **Usage**:
  390. - Indicates whether a validator signed the last block, allowing for rewards
  391. based on validator availability
  392. ### PubKey
  393. - **Fields**:
  394. - `Type (string)`: Type of the public key. A simple string like `"ed25519"`.
  395. In the future, may indicate a serialization algorithm to parse the `Data`,
  396. for instance `"amino"`.
  397. - `Data ([]byte)`: Public key data. For a simple public key, it's just the
  398. raw bytes. If the `Type` indicates an encoding algorithm, this is the
  399. encoded public key.
  400. - **Usage**:
  401. - A generic and extensible typed public key
  402. ### Evidence
  403. - **Fields**:
  404. - `Type (string)`: Type of the evidence. A hierarchical path like
  405. "duplicate/vote".
  406. - `Validator (Validator`: The offending validator
  407. - `Height (int64)`: Height when the offense was committed
  408. - `Time (google.protobuf.Timestamp)`: Time of the block at height `Height`.
  409. It is the proposer's local time when block was created.
  410. - `TotalVotingPower (int64)`: Total voting power of the validator set at
  411. height `Height`
  412. ### LastCommitInfo
  413. - **Fields**:
  414. - `Round (int32)`: Commit round.
  415. - `Votes ([]VoteInfo)`: List of validators addresses in the last validator set
  416. with their voting power and whether or not they signed a vote.
  417. ### ConsensusParams
  418. - **Fields**:
  419. - `Block (BlockParams)`: Parameters limiting the size of a block and time between consecutive blocks.
  420. - `Evidence (EvidenceParams)`: Parameters limiting the validity of
  421. evidence of byzantine behaviour.
  422. - `Validator (ValidatorParams)`: Parameters limitng the types of pubkeys validators can use.
  423. ### BlockParams
  424. - **Fields**:
  425. - `MaxBytes (int64)`: Max size of a block, in bytes.
  426. - `MaxGas (int64)`: Max sum of `GasWanted` in a proposed block.
  427. - NOTE: blocks that violate this may be committed if there are Byzantine proposers.
  428. It's the application's responsibility to handle this when processing a
  429. block!
  430. ### EvidenceParams
  431. - **Fields**:
  432. - `MaxAge (int64)`: Max age of evidence, in blocks. Evidence older than this
  433. is considered stale and ignored.
  434. - This should correspond with an app's "unbonding period" or other
  435. similar mechanism for handling Nothing-At-Stake attacks.
  436. - NOTE: this should change to time (instead of blocks)!
  437. ### ValidatorParams
  438. - **Fields**:
  439. - `PubKeyTypes ([]string)`: List of accepted pubkey types. Uses same
  440. naming as `PubKey.Type`.
  441. ### Proof
  442. - **Fields**:
  443. - `Ops ([]ProofOp)`: List of chained Merkle proofs, of possibly different types
  444. - The Merkle root of one op is the value being proven in the next op.
  445. - The Merkle root of the final op should equal the ultimate root hash being
  446. verified against.
  447. ### ProofOp
  448. - **Fields**:
  449. - `Type (string)`: Type of Merkle proof and how it's encoded.
  450. - `Key ([]byte)`: Key in the Merkle tree that this proof is for.
  451. - `Data ([]byte)`: Encoded Merkle proof for the key.