这里简要介绍 CometBFT 区块链应用的推荐架构。 这里我们区分两种“应用”。第一种是终端用户应用，例如用户下载的桌面钱包应用，用户实际是在这里与系统交互。另一种是 ABCI 应用，也就是实际运行在区块链上的逻辑。终端用户应用发送的交易，最终会在由 CometBFT 提交后，由 ABCI 应用进行处理。 终端用户应用通过应用暴露的 REST API 进行通信。该应用运行 CometBFT 节点，并通过 CometBFT RPC 验证 CometBFT 轻客户端证明。CometBFT 进程与本地 ABCI 应用通信，用户的查询或交易实际上就是在那里被处理的。 ABCI 应用必须是 CometBFT 共识的确定性结果；任何未经过 CometBFT 而对应用状态施加的外部影响，都可能导致共识失败。因此，除了 CometBFT 通过 ABCI 与其通信之外，任何东西 都不应直接与 ABCI 应用通信。 如果 ABCI 应用使用 Go 编写，它可以被编译进 CometBFT 二进制文件。否则，它应当使用 Unix socket 与 CometBFT 通信。如果必须使用 TCP，则需要格外注意对连接进行加密和身份认证。 所有对 ABCI 应用的读取都通过 CometBFT 的 /abci_query 端点进行。所有对 ABCI 应用的写入都通过 CometBFT 的 /broadcast_tx_* 端点进行。 轻客户端守护进程为轻客户端（终端用户）提供了接近全节点的大部分安全性。它负责格式化并广播交易，同时验证查询结果和交易结果的证明。需要注意的是，它不一定必须是守护进程；轻客户端逻辑也可以直接实现为终端用户应用所在的同一进程。 对于安全要求较弱的 ABCI 应用，轻客户端守护进程的功能也可以移动到 ABCI 应用进程本身。不过，即便如此，若要让除 CometBFT 通过 ABCI 之外的其他对象接触 ABCI 应用进程，仍需极其谨慎，因为所有交易，甚至可能所有查询，仍然都应经过 CometBFT。 更多详细文档请参阅：
Here we provide a brief guide on the recommended architecture of a CometBFT blockchain application. 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 CometBFT. The end-user application communicates with a REST API exposed by the application. The application runs CometBFT nodes and verifies CometBFT light-client proofs through the CometBFT RPC. The CometBFT 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 CometBFT consensus - any external influence on the application state that didn’t come through CometBFT could cause a consensus failure. Thus nothing should communicate with the ABCI application except CometBFT via ABCI. If the ABCI application is written in Go, it can be compiled into the CometBFT binary. Otherwise, it should use a Unix socket to communicate with CometBFT. 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 CometBFT /abci_query endpoint. All writes to the ABCI application happen through the CometBFT /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 CometBFT over ABCI requires extreme caution, as all transactions, and possibly all queries, should still pass through CometBFT. See the following for more extensive documentation: