mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-01-03 11:45:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update app-architecture.md (#4259)

Browse Source 
Address #4089 by clarifying the different uses of "application"
This commit is contained in:
Ethan Buchman
2019-12-18 02:57:59 -05:00
committed by Anton Kaliaev
parent eec9b2c9c8
commit bd77284d5b
1 changed files with 18 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/app-dev/app-architecture.md
View File

@@ -11,26 +11,33 @@ The following diagram provides a superb example:
![](../imgs/cosmos-tendermint-stack-4k.jpg)
The end-user application here is the Cosmos Voyager, at the bottom left.
Voyager communicates with a REST API exposed by a local Light-Client
We distinguish here between two forms of "application". The first is the
end-user application, like a desktop-based wallet app that a user downloads,
which is where the user actually interacts with the system. The other is the
ABCI application, which is the logic that actually runs on the blockchain.
Transactions sent by an end-user application are ultimately processed by the ABCI
application after being committed by the Tendermint consensus.
The end-user application in this diagram is the Cosmos Voyager, at the bottom
left. Voyager communicates with a REST API exposed by a local Light-Client
Daemon. The Light-Client Daemon is an application specific program that
communicates with Tendermint nodes and verifies Tendermint light-client
proofs through the Tendermint Core RPC. The Tendermint Core process
communicates with a local ABCI application, where the user query or
transaction is actually processed.
communicates with Tendermint nodes and verifies Tendermint light-client proofs
through the Tendermint Core RPC. The Tendermint Core process communicates with
a local ABCI application, where the user query or transaction is actually
processed.
The ABCI application must be a deterministic result of the Tendermint
consensus - any external influence on the application state that didn't
come through Tendermint could cause a consensus failure. Thus _nothing_
should communicate with the application except Tendermint via ABCI.
should communicate with the ABCI application except Tendermint via ABCI.
If the application is written in Go, it can be compiled into the
If the ABCI application is written in Go, it can be compiled into the
Tendermint binary. Otherwise, it should use a unix socket to communicate
with Tendermint. If it's necessary to use TCP, extra care must be taken
to encrypt and authenticate the connection.
All reads from the app happen through the Tendermint `/abci_query`
endpoint. All writes to the app happen through the Tendermint
All reads from the ABCI application happen through the Tendermint `/abci_query`
endpoint. All writes to the ABCI application happen through the Tendermint
`/broadcast_tx_*` endpoints.
The Light-Client Daemon is what provides light clients (end users) with
@@ -41,7 +48,7 @@ be implemented in the same process as the end-user application.
Note for those ABCI applications with weaker security requirements, the
functionality of the Light-Client Daemon can be moved into the ABCI
application process itself. That said, exposing the application process
application process itself. That said, exposing the ABCI application process
to anything besides Tendermint over ABCI requires extreme caution, as
all transactions, and possibly all queries, should still pass through
Tendermint.