fluencelabs/tendermint
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint synced 2025-06-12 12:51:22 +00:00
Code Issues Projects Releases Wiki Activity

Minor docs cleanup (#2472)

Browse Source 
* docs: link consensus to blockchain spec. closes #2422

* docs: deprecate research section. closes #2401

* docs: fix some links

* docs: fix some markdown lists

* docs: fix more links
This commit is contained in:
Ethan Buchman
2018-09-23 02:25:33 -04:00
committed by GitHub
parent a8eee4ab28
commit 27ba6e8a42
8 changed files with 25 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/research/determinism.md
View File

@ -1,3 +1,3 @@
# On Determinism
Arguably, the most difficult part of blockchain programming is determinism - that is, ensuring that sources of indeterminism do not creep into the design of such systems.
See [Determinism](../spec/abci/abci.md#determinism).

24
docs/research/transactional-semantics.md
View File

@ -1,25 +1,5 @@
# Transactional Semantics
In [Using Tendermint](../tendermint-core/using-tendermint.md#broadcast-api) we
discussed different API endpoints for sending transactions and
differences between them.
See details of the [broadcast API](../tendermint-core/using-tendermint.md#broadcast-api)
and the [mempool WAL](../tendermint-core/running-in-production.md#mempool-wal).
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
[this issue](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) and/or 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.