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.

129 lines
4.5 KiB

9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
9 years ago
  1. # Tendermint Socket Protocol (TMSP)
  2. Blockchains are a system for creating shared multi-master application state.
  3. **TMSP** is a socket protocol enabling a blockchain consensus engine, running in one process,
  4. to manage a blockchain application state, running in another.
  5. For more information on TMSP, motivations, and tutorials, please visit [our blog post](http://tendermint.com/posts/tendermint-socket-protocol/).
  6. Other implementations:
  7. * [cpp-tmsp](https://github.com/mdyring/cpp-tmsp) by Martin Dyring-Andersen
  8. * [js-tmsp](https://github.com/tendermint/js-tmsp)
  9. ## Message format
  10. Since this is a streaming protocol, all messages are encoded with a length-prefix followed by the message encoded in Protobuf3. Protobuf3 doesn't have an official length-prefix standard, so we use our own. The first byte represents the length of the big-endian encoded length.
  11. For example, if the Protobuf3 encoded TMSP message is `0xDEADBEEF` (4 bytes), the length-prefixed message is `0x0104DEADBEEF`. If the Protobuf3 encoded TMSP message is 65535 bytes long, the length-prefixed message would be like `0x02FFFF...`.
  12. ## Message types
  13. TMSP requests/responses are simple Protobuf messages. Check out the [schema file](https://github.com/tendermint/tmsp/blob/master/types/types.proto).
  14. #### AppendTx
  15. * __Arguments__:
  16. * `Data ([]byte)`: The request transaction bytes
  17. * __Returns__:
  18. * `Code (uint32)`: Response code
  19. * `Data ([]byte)`: Result bytes, if any
  20. * `Log (string)`: Debug or error message
  21. * __Usage__:<br/>
  22. Append and run a transaction. If the transaction is valid, returns CodeType.OK
  23. #### CheckTx
  24. * __Arguments__:
  25. * `Data ([]byte)`: The request transaction bytes
  26. * __Returns__:
  27. * `Code (uint32)`: Response code
  28. * `Data ([]byte)`: Result bytes, if any
  29. * `Log (string)`: Debug or error message
  30. * __Usage__:<br/>
  31. Validate a transaction. This message should not mutate the state.
  32. Transactions are first run through CheckTx before broadcast to peers in the mempool layer.
  33. You can make CheckTx semi-stateful and clear the state upon `Commit` or `BeginBlock`,
  34. to allow for dependent sequences of transactions in the same block.
  35. #### Commit
  36. * __Returns__:
  37. * `Data ([]byte)`: The Merkle root hash
  38. * `Log (string)`: Debug or error message
  39. * __Usage__:<br/>
  40. Return a Merkle root hash of the application state.
  41. #### Query
  42. * __Arguments__:
  43. * `Data ([]byte)`: The query request bytes
  44. * __Returns__:
  45. * `Code (uint32)`: Response code
  46. * `Data ([]byte)`: The query response bytes
  47. * `Log (string)`: Debug or error message
  48. #### Flush
  49. * __Usage__:<br/>
  50. Flush the response queue. Applications that implement `types.Application` need not implement this message -- it's handled by the project.
  51. #### Info
  52. * __Returns__:
  53. * `Data ([]byte)`: The info bytes
  54. * __Usage__:<br/>
  55. Return information about the application state. Application specific.
  56. #### SetOption
  57. * __Arguments__:
  58. * `Key (string)`: Key to set
  59. * `Value (string)`: Value to set for key
  60. * __Returns__:
  61. * `Log (string)`: Debug or error message
  62. * __Usage__:<br/>
  63. Set application options. E.g. Key="mode", Value="mempool" for a mempool connection, or Key="mode", Value="consensus" for a consensus connection.
  64. Other options are application specific.
  65. #### InitChain
  66. * __Arguments__:
  67. * `Validators ([]Validator)`: Initial genesis validators
  68. * __Usage__:<br/>
  69. Called once upon genesis
  70. #### BeginBlock
  71. * __Arguments__:
  72. * `Height (uint64)`: The block height that is starting
  73. * __Usage__:<br/>
  74. Signals the beginning of a new block. Called prior to any AppendTxs.
  75. #### EndBlock
  76. * __Arguments__:
  77. * `Height (uint64)`: The block height that ended
  78. * __Returns__:
  79. * `Validators ([]Validator)`: Changed validators with new voting powers (0 to remove)
  80. * __Usage__:<br/>
  81. Signals the end of a block. Called prior to each Commit after all transactions
  82. ## Changelog
  83. ##### Mar 26h, 2016
  84. * Introduce BeginBlock
  85. ##### Mar 6th, 2016
  86. * Added InitChain, EndBlock
  87. ##### Feb 14th, 2016
  88. * s/GetHash/Commit/g
  89. * Document Protobuf request/response fields
  90. ##### Jan 23th, 2016
  91. * Added CheckTx/Query TMSP message types
  92. * Added Result/Log fields to AppendTx/CheckTx/SetOption
  93. * Removed Listener messages
  94. * Removed Code from ResponseSetOption and ResponseGetHash
  95. * Made examples BigEndian
  96. ##### Jan 12th, 2016
  97. * Added "RetCodeBadNonce = 0x06" return code
  98. ##### Jan 8th, 2016
  99. * Tendermint/TMSP now comes to consensus on the order first before AppendTx.