fluencelabs/tendermint-demo
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint-demo synced 2025-03-15 15:50:51 +00:00
Code Issues Projects Releases Wiki Activity

Operations processing

Browse Source
This commit is contained in:
Alexander Demidko 2018-06-27 09:51:27 +03:00 committed by GitHub
parent a4b5b4db3f
commit 44a78c6f89
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
README.md
View File

@ -260,16 +260,17 @@ Here we can see that both (correct!) results correspond to the latest `app_hash`
## Implementation details ## Implementation details
### Operation processing in the cluster ### Operations processing
To initiate an operation the Client needs to connect only a single node of the cluster in normal conditions. To perform operations, a client normally connects to a single node of the cluster.
Reading `get` requests are processed on a single node entirely. The node State machine has all required information to process such query because the state with key-value tree and their proofs is fully replicated. The node TM Core also has everything to process `get` query because the blockchain is also fully replicated and contains all information not only about blocks but also about the blocks signatures of other nodes and therefore can prove to the client that the provided response is consistent with those nodes signed the blockchain data. Querying requests such as `get` are processed entirely by a single node. Single node state machine has all the required data to process queries because the state is fully replicated. The blockchain is fully replicated as well and each block contains signatures of the nodes accepted it, so the client can verify that the `app_hash` return by the node is not a bogus one.
Writing `run` and `put` requests implemented via Tendermint transactions, so a cluster-wide interaction is required in order to: Processing effectful requests requires multiple nodes to reach consensus, however the client still sends a transaction to a single node. Tendermint is responsible in spreading this transaction to other nodes and reaching consensus.
* TM Core spreads the transaction to other nodes.
* TM Cores reach consensus about including this transaction in a particular block. **Note**
* TM Cores request their local State machine to apply this transaction to the state. It's possible that a malicious node might silently drop incoming transactions so they will never get propagated over the cluster. The client could monitor the blockchain to see if transaction got finally included in an accepted block, and if it didn't – resend it to other nodes. This functionality is not implemented yet.
* TM Cores obtain the `app_hash` from their local State machines.
It is also possible that a malicious node might use a stale state and stale blockchain to serve queries. In this case the client has no way of knowing that the cluster state has advanced. Two approaches can be used, however – the first is to send a `no-op` transaction and wait for it to appear in the selected node blockchain. Because including a transaction into the blockchain means including and processing all transactions before it, the client will have a guarantee that the state has advanced. Another approach is to query multiple nodes at once about their last block height and compare it to the last block height of the selected node. This functionality is also not implemented yet.
### Transaction processing on the single node ### Transaction processing on the single node
A single transaction is processing primarily by 2 TM Core modules: **Mempool** and **Consensus**. A single transaction is processing primarily by 2 TM Core modules: **Mempool** and **Consensus**.