github.com/badrootd/nibiru-cometbft@v0.37.5-0.20240307173500-2a75559eee9b/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  CometBFT blockchain application.
     9  
    10  We distinguish here between two forms of "application". The first is the
    11  end-user application, like a desktop-based wallet app that a user downloads,
    12  which is where the user actually interacts with the system. The other is the
    13  ABCI application, which is the logic that actually runs on the blockchain.
    14  Transactions sent by an end-user application are ultimately processed by the ABCI
    15  application after being committed by CometBFT.
    16  
    17  The end-user application communicates with a REST API exposed by the application.
    18  The application runs CometBFT nodes and verifies CometBFT light-client proofs
    19  through the CometBFT RPC. The CometBFT process communicates with
    20  a local ABCI application, where the user query or transaction is actually
    21  processed.
    22  
    23  The ABCI application must be a deterministic result of the CometBFT
    24  consensus - any external influence on the application state that didn't
    25  come through CometBFT could cause a consensus failure. Thus _nothing_
    26  should communicate with the ABCI application except CometBFT via ABCI.
    27  
    28  If the ABCI application is written in Go, it can be compiled into the
    29  CometBFT binary. Otherwise, it should use a unix socket to communicate
    30  with CometBFT. If it's necessary to use TCP, extra care must be taken
    31  to encrypt and authenticate the connection.
    32  
    33  All reads from the ABCI application happen through the CometBFT `/abci_query`
    34  endpoint. All writes to the ABCI application happen through the CometBFT
    35  `/broadcast_tx_*` endpoints.
    36  
    37  The Light-Client Daemon is what provides light clients (end users) with
    38  nearly all the security of a full node. It formats and broadcasts
    39  transactions, and verifies proofs of queries and transaction results.
    40  Note that it need not be a daemon - the Light-Client logic could instead
    41  be implemented in the same process as the end-user application.
    42  
    43  Note for those ABCI applications with weaker security requirements, the
    44  functionality of the Light-Client Daemon can be moved into the ABCI
    45  application process itself. That said, exposing the ABCI application process
    46  to anything besides CometBFT over ABCI requires extreme caution, as
    47  all transactions, and possibly all queries, should still pass through
    48  CometBFT.
    49  
    50  See the following for more extensive documentation:
    51  
    52  - [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1617) (legacy/deprecated)
    53  - [CometBFT RPC Docs](https://docs.cometbft.com/v0.37/rpc/)
    54  - [CometBFT in Production](../core/running-in-production.md)
    55  - [ABCI spec](https://github.com/cometbft/cometbft/tree/v0.37.x/spec/abci)