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.
27 lines
1.0 KiB
27 lines
1.0 KiB
Transactional Semantics
|
|
=======================
|
|
|
|
In `"Using
|
|
Tendermint"<./specification/using-tendermint.html#broadcast-api>`__ we
|
|
discussed different API endpoints for sending transactions and
|
|
differences between them.
|
|
|
|
What we have not yet covered is transactional semantics.
|
|
|
|
When you send a transaction using one of the available methods, it
|
|
first goes to the mempool. Currently, it does not provide strong
|
|
guarantees like "if the transaction were accepted, it would be
|
|
eventually included in a block (given CheckTx passes)."
|
|
|
|
For instance a tx could enter the mempool, but before it can be sent
|
|
to peers the node crashes.
|
|
|
|
We are planning to provide such guarantees by using a WAL and
|
|
replaying transactions (See
|
|
`GH#248<https://github.com/tendermint/tendermint/issues/248>`__), but
|
|
it's non-trivial to do this all efficiently.
|
|
|
|
The temporary solution is for clients to monitor the node and resubmit
|
|
transaction(s) or/and send them to more nodes at once, so the
|
|
probability of all of them crashing at the same time and losing the
|
|
msg decreases substantially.
|