# Architecture ### ABCI The TransferChain Blockchain uses an interface called the ABCI to communicate with applications. The ABCI allows the blockchain to pass transactions to the application and receive feedback on whether the transactions were processed successfully. The most important messages of the ABCI are: * **CheckTx:** This message is used to check if a transaction meets a few basic requirements. If the checks are valid, the transaction is added to the mempool and relayed to other nodes. * **DeliverTx:** This message is used to process transactions that have been included in a block. It is during this stage that the state of the blockchain is updated. * **BeginBlock/EndBlock:** These messages are executed at the beginning and end of each block, regardless of whether the block contains transactions. They can be used to trigger automatic execution of logic. Any application built on the TransferChain Blockchain must implement the ABCI interface. However, you do not have to implement the interface yourself, as the TransferChain SDK provides an example implementation. Here is a more detailed explanation of each message: * **CheckTx:** The CheckTx message is used to check if a transaction meets a few basic requirements. These requirements are typically things like ensuring that the transaction has a valid signature and that it does not exceed the maximum gas limit. If the checks are valid, the transaction is added to the mempool and relayed to other nodes. * **DeliverTx:** The DeliverTx message is used to process transactions that have been included in a block. It is during this stage that the state of the blockchain is updated. The application can use this message to update its own state, as well as to perform any other necessary actions. * **BeginBlock/EndBlock:** The BeginBlock and EndBlock messages are executed at the beginning and end of each block, regardless of whether the block contains transactions. They can be used to trigger automatic execution of logic, such as updating statistics or performing maintenance tasks. ### BFT Consensus Mechanism BFT stands for Byzantine Fault Tolerance. It is a type of consensus algorithm that allows a distributed system to reach agreement even if some of the nodes in the system are faulty. The BFT algorithm works by having a set of validators, which are nodes that are responsible for proposing and voting on blocks. Each validator has a voting weight, which is determined by the amount of stake that they have in the network. To propose a block, a validator must first collect a certain number of votes from other validators. This is called a prevote. Once a validator has received enough prevotes, it can then propose a block. Once a block is proposed, all of the validators vote on whether to accept it. To be accepted, a block must receive more than two-thirds of the votes. If a block is not accepted, the process starts over with a new proposal. The BFT algorithm is designed to be Byzantine Fault Tolerant, which means that it can still reach agreement even if some of the validators are faulty. This is achieved by using a variety of techniques, such as double-voting detection and secure communication. Here are the steps in the TransferChain consensus algorithm implemented: 1. A validator is chosen to propose a block. 2. The validator broadcasts the proposal to all of the other validators. 3. The other validators vote on the proposal. 4. If the proposal receives more than two-thirds of the votes, it is committed to the blockchain. 5. If the proposal does not receive enough votes, the process starts over with a new proposal. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.transferchain.io/core-concepts/blockchain/architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.