github.com/franono/tendermint@v0.32.2-0.20200527150959-749313264ce9/docs/app-dev/app-architecture.md (about)

     1  ---
     2  order: 3
     3  ---
     4  
     5  # Application Architecture Guide
     6  
     7  Here we provide a brief guide on the recommended architecture of a
     8  Tendermint blockchain application.
     9  
    10  The following diagram provides a superb example:
    11  
    12  ![](../imgs/cosmos-tendermint-stack-4k.jpg)
    13  
    14  We distinguish here between two forms of "application". The first is the
    15  end-user application, like a desktop-based wallet app that a user downloads,
    16  which is where the user actually interacts with the system. The other is the
    17  ABCI application, which is the logic that actually runs on the blockchain.
    18  Transactions sent by an end-user application are ultimately processed by the ABCI
    19  application after being committed by the Tendermint consensus.
    20  
    21  The end-user application in this diagram is the Cosmos Voyager, at the bottom
    22  left. Voyager communicates with a REST API exposed by a local Light-Client
    23  Daemon. The Light-Client Daemon is an application specific program that
    24  communicates with Tendermint nodes and verifies Tendermint light-client proofs
    25  through the Tendermint Core RPC. The Tendermint Core process communicates with
    26  a local ABCI application, where the user query or transaction is actually
    27  processed.
    28  
    29  The ABCI application must be a deterministic result of the Tendermint
    30  consensus - any external influence on the application state that didn't
    31  come through Tendermint could cause a consensus failure. Thus _nothing_
    32  should communicate with the ABCI application except Tendermint via ABCI.
    33  
    34  If the ABCI application is written in Go, it can be compiled into the
    35  Tendermint binary. Otherwise, it should use a unix socket to communicate
    36  with Tendermint. If it's necessary to use TCP, extra care must be taken
    37  to encrypt and authenticate the connection.
    38  
    39  All reads from the ABCI application happen through the Tendermint `/abci_query`
    40  endpoint. All writes to the ABCI application happen through the Tendermint
    41  `/broadcast_tx_*` endpoints.
    42  
    43  The Light-Client Daemon is what provides light clients (end users) with
    44  nearly all the security of a full node. It formats and broadcasts
    45  transactions, and verifies proofs of queries and transaction results.
    46  Note that it need not be a daemon - the Light-Client logic could instead
    47  be implemented in the same process as the end-user application.
    48  
    49  Note for those ABCI applications with weaker security requirements, the
    50  functionality of the Light-Client Daemon can be moved into the ABCI
    51  application process itself. That said, exposing the ABCI application process
    52  to anything besides Tendermint over ABCI requires extreme caution, as
    53  all transactions, and possibly all queries, should still pass through
    54  Tendermint.
    55  
    56  See the following for more extensive documentation:
    57  
    58  - [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1028)
    59  - [Tendermint RPC Docs](https://docs.tendermint.com/master/rpc/)
    60  - [Tendermint in Production](../tendermint-core/running-in-production.md)
    61  - [ABCI spec](https://github.com/tendermint/spec/tree/95cf253b6df623066ff7cd4074a94e7a3f147c7a/spec/abci)