Skip to content

Improve documentation of CheckTx and DeliverTx #2249

@ttmc

Description

@ttmc

This docs request is based on the discussion in issues #2162 and #2175. The docs about CheckTx and DeliverTx could use some extension and clarification. Here are some ideas of things that could be added:

  • CheckTx is like a guard on a node's local mempool in the following sense: Every node runs CheckTx before letting a transaction into its local mempool. That transaction might have come from an external user or from another node.

  • Every time a block is committed, CheckTx is run again on all transactions in the node's local mempool, unless recheck is turned off using the configuration setting mempool.recheck=false

  • CheckTx doesn't have to check everything that affects transaction validity; the expensive things can be skipped. In fact, CheckTx doesn't have to check anything; it might say that any transaction is a valid transaction. DeliverTx must check transaction validity for real, and in full. CheckTx is just there as a sort of weak filter to keep invalid transactions out of the blockchain. It's weak, because a Byzantine node doesn't care about CheckTx; it can propose a block full of invalid transactions if it wants.

  • DeliverTx is not optional.

  • DeliverTx must check if a transaction is valid, assuming an app state equal to the state at the end of the last block, plus all valid transactions seen so far in the current block-under-construction.

  • If the transaction isn't valid, the node should ignore the transaction (i.e. not use it to update the state later on) and respond to DeliverTx with a response Code that is not CodeType.OK.

  • The app state shouldn't actually be updated (and written to disk) until Tendermint sends the Commit request.

  • What state should a node assume when answering CheckTx? In some sense, it doesn't matter, as noted above, but if you want your CheckTx to be consistent with DeliverTx, then use the state at the end of the last block plus all mempool transactions checked by CheckTx before this one (i.e. the same state as if the transaction were in a proposed block).

  • What does Tendermint Core do when the DeliverTx response Code is not CodeType.OK?

  • What does the CheckTx response part called Data ([]byte) mean?

  • What does the DeliverTx response part called Data ([]byte) mean?

If I'm wrong about any of the above, then please correct me.

You might have noticed that the last few bullet points are questions. They should also be answered.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions