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.

183 lines
7.8 KiB

  1. # ADR 012: ABCI `ProposeTx` Method
  2. ## Changelog
  3. 25-06-2018: Initial draft based on [#1776](https://github.com/tendermint/tendermint/issues/1776)
  4. ## Context
  5. [#1776](https://github.com/tendermint/tendermint/issues/1776) was
  6. opened in relation to implementation of a Plasma child chain using Tendermint
  7. Core as consensus/replication engine.
  8. Due to the requirements of [Minimal Viable Plasma (MVP)](https://ethresear.ch/t/minimal-viable-plasma/426) and [Plasma Cash](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298), it is necessary for ABCI apps to have a mechanism to handle the following cases (more may emerge in the near future):
  9. 1. `deposit` transactions on the Root Chain, which must consist of a block
  10. with a single transaction, where there are no inputs and only one output
  11. made in favour of the depositor. In this case, a `block` consists of
  12. a transaction with the following shape:
  13. ```
  14. [0, 0, 0, 0, #input1 - zeroed out
  15. 0, 0, 0, 0, #input2 - zeroed out
  16. <depositor_address>, <amount>, #output1 - in favour of depositor
  17. 0, 0, #output2 - zeroed out
  18. <fee>,
  19. ]
  20. ```
  21. `exit` transactions may also be treated in a similar manner, wherein the
  22. input is the UTXO being exited on the Root Chain, and the output belongs to
  23. a reserved "burn" address, e.g., `0x0`. In such cases, it is favourable for
  24. the containing block to only hold a single transaction that may receive
  25. special treatment.
  26. 2. Other "internal" transactions on the child chain, which may be initiated
  27. unilaterally. The most basic example of is a coinbase transaction
  28. implementing validator node incentives, but may also be app-specific. In
  29. these cases, it may be favourable for such transactions to
  30. be ordered in a specific manner, e.g., coinbase transactions will always be
  31. at index 0. In general, such strategies increase the determinism and
  32. predictability of blockchain applications.
  33. While it is possible to deal with the cases enumerated above using the
  34. existing ABCI, currently available result in suboptimal workarounds. Two are
  35. explained in greater detail below.
  36. ### Solution 1: App state-based Plasma chain
  37. In this work around, the app maintains a `PlasmaStore` with a corresponding
  38. `Keeper`. The PlasmaStore is responsible for maintaing a second, separate
  39. blockchain that complies with the MVP specification, including `deposit`
  40. blocks and other "internal" transactions. These "virtual" blocks are then broadcasted
  41. to the Root Chain.
  42. This naive approach is, however, fundamentally flawed, as it by definition
  43. diverges from the canonical chain maintained by Tendermint. This is further
  44. exacerbated if the business logic for generating such transactions is
  45. potentially non-deterministic, as this should not even be done in
  46. `Begin/EndBlock`, which may, as a result, break consensus guarantees.
  47. Additinoally, this has serious implications for "watchers" - independent third parties,
  48. or even an auxilliary blockchain, responsible for ensuring that blocks recorded
  49. on the Root Chain are consistent with the Plasma chain's. Since, in this case,
  50. the Plasma chain is inconsistent with the canonical one maintained by Tendermint
  51. Core, it seems that there exists no compact means of verifying the legitimacy of
  52. the Plasma chain without replaying every state transition from genesis (!).
  53. ### Solution 2: Broadcast to Tendermint Core from ABCI app
  54. This approach is inspired by `tendermint`, in which Ethereum transactions are
  55. relayed to Tendermint Core. It requires the app to maintain a client connection
  56. to the consensus engine.
  57. Whenever an "internal" transaction needs to be created, the proposer of the
  58. current block broadcasts the transaction or transactions to Tendermint as
  59. needed in order to ensure that the Tendermint chain and Plasma chain are
  60. completely consistent.
  61. This allows "internal" transactions to pass through the full consensus
  62. process, and can be validated in methods like `CheckTx`, i.e., signed by the
  63. proposer, is the semantically correct, etc. Note that this involves informing
  64. the ABCI app of the block proposer, which was temporarily hacked in as a means
  65. of conducting this experiment, although this should not be necessary when the
  66. current proposer is passed to `BeginBlock`.
  67. It is much easier to relay these transactions directly to the Root
  68. Chain smart contract and/or maintain a "compressed" auxiliary chain comprised
  69. of Plasma-friendly blocks that 100% reflect the canonical (Tendermint)
  70. blockchain. Unfortunately, this approach not idiomatic (i.e., utilises the
  71. Tendermint consensus engine in unintended ways). Additionally, it does not
  72. allow the application developer to:
  73. - Control the _ordering_ of transactions in the proposed block (e.g., index 0,
  74. or 0 to `n` for coinbase transactions)
  75. - Control the _number_ of transactions in the block (e.g., when a `deposit`
  76. block is required)
  77. Since determinism is of utmost importance in blockchain engineering, this approach,
  78. while more viable, should also not be considered as fit for production.
  79. ## Decision
  80. ### `ProposeTx`
  81. In order to address the difficulties described above, the ABCI interface must
  82. expose an additional method, tentatively named `ProposeTx`.
  83. It should have the following signature:
  84. ```
  85. ProposeTx(RequestProposeTx) ResponseProposeTx
  86. ```
  87. Where `RequestProposeTx` and `ResponseProposeTx` are `message`s with the
  88. following shapes:
  89. ```
  90. message RequestProposeTx {
  91. int64 next_block_height = 1; // height of the block the proposed tx would be part of
  92. Validator proposer = 2; // the proposer details
  93. }
  94. message ResponseProposeTx {
  95. int64 num_tx = 1; // the number of tx to include in proposed block
  96. repeated bytes txs = 2; // ordered transaction data to include in block
  97. bool exclusive = 3; // whether the block should include other transactions (from `mempool`)
  98. }
  99. ```
  100. `ProposeTx` would be called by before `mempool.Reap` at this
  101. [line](https://github.com/tendermint/tendermint/blob/9cd9f3338bc80a12590631632c23c8dbe3ff5c34/consensus/state.go#L935).
  102. Depending on whether `exclusive` is `true` or `false`, the proposed
  103. transactions are then pushed on top of the transactions received from
  104. `mempool.Reap`.
  105. ### `DeliverTx`
  106. Since the list of `tx` received from `ProposeTx` are _not_ passed through `CheckTx`,
  107. it is probably a good idea to provide a means of differentiatiating "internal" transactions
  108. from user-generated ones, in case the app developer needs/wants to take extra measures to
  109. ensure validity of the proposed transactions.
  110. Therefore, the `RequestDeliverTx` message should be changed to provide an additional flag, like so:
  111. ```
  112. message RequestDeliverTx {
  113. bytes tx = 1;
  114. bool internal = 2;
  115. }
  116. ```
  117. Alternatively, an additional method `DeliverProposeTx` may be added as an accompanient to
  118. `ProposeTx`. However, it is not clear at this stage if this additional overhead is necessary
  119. to preserve consensus guarantees given that a simple flag may suffice for now.
  120. ## Status
  121. Pending
  122. ## Consequences
  123. ### Positive
  124. - Tendermint ABCI apps will be able to function as minimally viable Plasma chains.
  125. - It will thereby become possible to add an extension to `cosmos-sdk` to enable
  126. ABCI apps to support both IBC and Plasma, maximising interop.
  127. - ABCI apps will have great control and flexibility in managing blockchain state,
  128. without having to resort to non-deterministic hacks and/or unsafe workarounds
  129. ### Negative
  130. - Maintenance overhead of exposing additional ABCI method
  131. - Potential security issues that may have been overlooked and must now be tested extensively
  132. ### Neutral
  133. - ABCI developers must deal with increased (albeit nominal) API surface area.
  134. ## References
  135. - [#1776 Plasma and "Internal" Transactions in ABCI Apps](https://github.com/tendermint/tendermint/issues/1776)
  136. - [Minimal Viable Plasma](https://ethresear.ch/t/minimal-viable-plasma/426)
  137. - [Plasma Cash: Plasma with much less per-user data checking](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298)