mirror of
https://github.com/fluencelabs/tendermint
synced 2025-04-28 00:02:14 +00:00
28 lines
1.0 KiB
ReStructuredText
28 lines
1.0 KiB
ReStructuredText
|
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.
|