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.

100 lines
3.5 KiB

  1. # ADR 037: Deliver Block
  2. Author: Daniil Lashin (@danil-lashin)
  3. ## Changelog
  4. 13-03-2019: Initial draft
  5. ## Context
  6. Initial conversation: https://github.com/tendermint/tendermint/issues/2901
  7. Some applications can handle transactions in parallel, or at least some
  8. part of tx processing can be parallelized. Now it is not possible for developer
  9. to execute txs in parallel because Tendermint delivers them consequentially.
  10. ## Decision
  11. Now Tendermint have `BeginBlock`, `EndBlock`, `Commit`, `DeliverTx` steps
  12. while executing block. This doc proposes merging this steps into one `DeliverBlock`
  13. step. It will allow developers of applications to decide how they want to
  14. execute transactions (in parallel or consequentially). Also it will simplify and
  15. speed up communications between application and Tendermint.
  16. As @jaekwon [mentioned](https://github.com/tendermint/tendermint/issues/2901#issuecomment-477746128)
  17. in discussion not all application will benefit from this solution. In some cases,
  18. when application handles transaction consequentially, it way slow down the blockchain,
  19. because it need to wait until full block is transmitted to application to start
  20. processing it. Also, in the case of complete change of ABCI, we need to force all the apps
  21. to change their implementation completely. That's why I propose to introduce one more ABCI
  22. type.
  23. # Implementation Changes
  24. In addition to default application interface which now have this structure
  25. ```go
  26. type Application interface {
  27. // Info and Mempool methods...
  28. // Consensus Connection
  29. InitChain(RequestInitChain) ResponseInitChain // Initialize blockchain with validators and other info from TendermintCore
  30. BeginBlock(RequestBeginBlock) ResponseBeginBlock // Signals the beginning of a block
  31. DeliverTx(tx []byte) ResponseDeliverTx // Deliver a tx for full processing
  32. EndBlock(RequestEndBlock) ResponseEndBlock // Signals the end of a block, returns changes to the validator set
  33. Commit() ResponseCommit // Commit the state and return the application Merkle root hash
  34. }
  35. ```
  36. this doc proposes to add one more:
  37. ```go
  38. type Application interface {
  39. // Info and Mempool methods...
  40. // Consensus Connection
  41. InitChain(RequestInitChain) ResponseInitChain // Initialize blockchain with validators and other info from TendermintCore
  42. DeliverBlock(RequestDeliverBlock) ResponseDeliverBlock // Deliver full block
  43. Commit() ResponseCommit // Commit the state and return the application Merkle root hash
  44. }
  45. type RequestDeliverBlock struct {
  46. Hash []byte
  47. Header Header
  48. Txs Txs
  49. LastCommitInfo LastCommitInfo
  50. ByzantineValidators []Evidence
  51. }
  52. type ResponseDeliverBlock struct {
  53. ValidatorUpdates []ValidatorUpdate
  54. ConsensusParamUpdates *ConsensusParams
  55. Tags []common.KVPair
  56. TxResults []ResponseDeliverTx
  57. }
  58. ```
  59. Also, we will need to add new config param, which will specify what kind of ABCI application uses.
  60. For example, it can be `abci_type`. Then we will have 2 types:
  61. - `advanced` - current ABCI
  62. - `simple` - proposed implementation
  63. ## Status
  64. In review
  65. ## Consequences
  66. ### Positive
  67. - much simpler introduction and tutorials for new developers (instead of implementing 5 methods whey
  68. will need to implement only 3)
  69. - txs can be handled in parallel
  70. - simpler interface
  71. - faster communications between Tendermint and application
  72. ### Negative
  73. - Tendermint should now support 2 kinds of ABCI