* Ignore generated/copied RPC docs Signed-off-by: Thane Thomson <connect@thanethomson.com> * Sync vuepress config with main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Sync docs package-lock.json with main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Sync docs redirects with main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Sync docs versions with main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update OpenAPI version to v0.34 Signed-off-by: Thane Thomson <connect@thanethomson.com> * Sync DOCS_README with main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update all v0.34.x docs references from master to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update v0.34 OpenAPI references from master to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update repo doc links from master to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update code comment references from master to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update repo root doc links from master to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update repo root doc links for docs.tendermint.com from master to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Build v0.34.x as "latest" Signed-off-by: Thane Thomson <connect@thanethomson.com> * Explicitly mark v0.34 docs as latest in version selector Signed-off-by: Thane Thomson <connect@thanethomson.com> * Add nav link to main and clearly mark as unstable Signed-off-by: Thane Thomson <connect@thanethomson.com> * Direct all docs.tendermint.com links to v0.34 on v0.34.x Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update all relevant links on v0.34.x branch to be v0.34-specific Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update changelog refs to docs.tendermint.com Signed-off-by: Thane Thomson <connect@thanethomson.com> * Update remaining GH master link to main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Sync docs build and nav config with main Signed-off-by: Thane Thomson <connect@thanethomson.com> * Migrate spec links to GitHub repo from docs site Signed-off-by: Thane Thomson <connect@thanethomson.com> Signed-off-by: Thane Thomson <connect@thanethomson.com>
2.9 KiB
order
| order |
|---|
| 3 |
Application Architecture Guide
Here we provide a brief guide on the recommended architecture of a Tendermint blockchain application.
The following diagram provides a superb example:
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 Lunie app, located at the bottom left. Lunie communicates with a REST API exposed by the application. The application 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 ABCI application except Tendermint via ABCI.
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 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 nearly all the security of a full node. It formats and broadcasts transactions, and verifies proofs of queries and transaction results. Note that it need not be a daemon - the Light-Client logic could instead 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 ABCI application process to anything besides Tendermint over ABCI requires extreme caution, as all transactions, and possibly all queries, should still pass through Tendermint.
See the following for more extensive documentation:
