:::info :bulb: This document provides a summary of the [cometBFT ABCI++ spec](https://github.com/cometbft/cometbft/tree/main/spec/abci) as well as draws comparisons to the ethereum consensus and execution layer. ::: <center> <img src="https://hackmd.io/_uploads/S1Ygcxko2.png" width="450" height="450"> </center> ***Table of Contents:*** [ToC] ## ABCI++ and CometBFT Cosmos' ABCI (Application BlockChain Interface) allows the consensus mechanism (e.g., Tendermint, and more recently CometBFT) and blockchain applications to work together while remaining agnostic to each other's specifics. The new ABCI++, compared to the original ABCI, provides the application with more opportunities to interact with the consensus algorithm, allowing it to influence proposal creation, proposal validation, and precommit voting. CometBFT is a recent adaptation of the Tendermint consensus algorithm, designed to protect safety under any network conditions, as long as less than 1/3 of validators' voting power is byzantine. The expected behavior of CometBFT in benign conditions and its interaction with the Application using ABCI++ is described in detail in the subsequent sections. ## Comparing ABCI++ and Ethereum A key differentiation between Ethereum and the Cosmos ecosystem lies in how applications interact with their consensus algorithm. In Ethereum’s context, ABCI++ would be equivalent to allowing a smart contract substantial influence over Ethereum’s fork choice rule. Applications on the EVM operate with uniform rules across all applications. ABCI++ and CometBFT, in contrast, offer a higher degree of flexibility and a more direct involvement of applications in consensus decisions. They allow applications to define how transactions are ordered and executed, a capability that underpins the "[Sovereign MEV](https://ideas.skip.money/t/the-sovereign-mev-toolkit/38)" approach prevalent in the Cosmos ecosystem. This ability empowers each application with greater control over its own consensus algorithm, essentially becoming a co-driver rather than a mere passenger in the process. Another key difference between the two ecosystems is where the definition of a "application" extends. In Ethereum it is byte code deployed to a chain, but in Cosmos the application and chain are tightly coupled, as in in applications such as [Osmosis](https://app.osmosis.zone/), allowing for greater innovation at the boundary between application and blockchain. ### Block Execution Methods Ethereum transactions are processed one at a time, in order, by the EVM. In contrast, ABCI++ and CometBFT allow applications to influence how transactions are included in blocks via the `PrepareProposal` method. They also enable the application to validate blocks via the `ProcessProposal` method. In Ethereum, all full nodes independently validate blocks and transactions. ABCI++ and CometBFT provide a similar functionality via the `FinalizeBlock` method, which instructs the application to execute transactions in a block and update its state accordingly. ABCI++ and CometBFT also include methods for extending and verifying vote extensions (`ExtendVote` and `VerifyVoteExtension`), which allow applications to include additional data in consensus messages. There is no direct equivalent in Ethereum, though one might consider Ethereum's ability to include extra data in a transaction somewhat similar. ### Mempool Methods Like Ethereum, Cosmos also validates transactions before they're added to the mempool. This is accomplished using the `CheckTx` method in ABCI++. While Ethereum validates each transaction according to a standard set of rules (checking the nonce, ensuring sufficient gas, verifying the signature, etc.), ABCI++ and CometBFT allow the application to specify custom validation logic. ### Info Methods ABCI++ and CometBFT provide the `Info` and `Query` methods for syncing and querying the application state. In Ethereum, similar functionality is provided by its JSON-RPC API, which allows external users to query node information and the state of the Ethereum blockchain. ### State-sync Methods State-sync methods in ABCI++ and CometBFT allow new nodes to rapidly join the network by fetching snapshots of the application state. Ethereum 2.0's weak subjectivity periods provide similar functionality in that new validators can sync more quickly by trusting a recent checkpoint. ### Deterministic State-Machine Replication Like in Ethereum, Cosmos applications using ABCI++ and CometBFT must be deterministic finite-state machines, and state changes must only be triggered by block execution (`FinalizeBlock` in ABCI++, and transaction execution in Ethereum). Both Ethereum and Cosmos avoid exposing application state to external users or processes except through their respective APIs. ### Valid Method Call Sequences in CometBFT A well-written Application design should consider any possible sequences of method calls in CometBFT. This includes considering cases of network asynchrony, byzantine proposers, and recovery runs, which can make the sequence of calls to ABCI++ methods more complex. A comprehensive grammar detailing all possible sequences of calls to ABCI++, taken by a correct process, across all heights from the genesis block, including recovery runs, from the point of view of the Application is described in the original text. In contrast to Ethereum, application developers do not need to consider anything related to network asychrony in their design, but of course it is always useful to think through the effects of momentary byzantine takeover on your application. ## Understanding Application Requirements for Cosmos Chain Apps ### State Management in Applications #### Maintaining Connection State CometBFT handles four independent ABCI++ connections, each with its own application state copy. These connections include Consensus, Mempool, Info/Query, and Snapshot Connections. Their states sync during `Commit` calls. This is a distinction from Ethereum where a node maintains a unified state. #### Managing Concurrency Unlike Ethereum where the EVM processes transactions one after another, each ABCI++ connection operates simultaneously, requiring thread-safe state access. Go applications typically use a global mutex across all connections, ensuring sequential message handling. #### Executing `FinalizeBlock` and `Commit` These two methods operate differently in ABCI++. `FinalizeBlock` initiates state transition, but the state is only saved when `Commit` is called. This provides a separation of state transition and persistence, not seen in Ethereum's EVM execution model. #### Working with Candidate States `PrepareProposal` and `ProcessProposal` get called when a proposed block is sent to the network and received, respectively. This immediate execution of proposed blocks allows for the rejection of invalid transactions and faster `FinalizeBlock` execution, offering a level of control absent in Ethereum. #### Understanding ABCI++ Connections and States - **Consensus Connection**: Uses `ExecuteTxState`, updated by `FinalizeBlock` and committed during `Commit`. - **Mempool Connection**: Uses `CheckTxState`, reset to the latest committed state post every `Commit`. - **Info/Query Connection**: Uses `QueryState`, a read-only version of `ExecuteTxState` after the last `Commit`. - **Snapshot Connection**: Handles serving and restoring state sync snapshots. Unlike Ethereum where a node maintains a unified state, each connection in ABCI++ maintains separate states. #### Handling Transaction Results In `ResponseFinalizeBlock`, the application returns an `ExecTxResult` list. Like Ethereum's concept of gas, CometBFT optionally uses gas for cost representation, with limits enforced when `MaxGas` > -1. #### Implementing Replay Protection Similar to Ethereum, the application must provide its own replay protection during `CheckTx` to prevent old transactions from being re-issued. #### Understanding `ResponseCheckTx` and `ExecTxResult` Transactions are rejected from the mempool when `Code` != 0. During `FinalizeBlock`, the `Data` in `ExecTxResult` must be deterministic. ### Validator Set Management Applications can update the validator set during `InitChain` and `FinalizeBlock`, similar to how Ethereum validators can be swapped out. ### Adjusting Consensus Parameters `ConsensusParams` are globally applied to all validators, enforcing limits similar to Ethereum's gas and block size limits. They can be set during `InitChain` and updated in `FinalizeBlock`. ### Leveraging Querying Queries on the application state can be made through CometBFT's Query method, similar to Ethereum's JSON-RPC API. These queries aren't replicated across nodes and might return stale reads. ### Implementing State Synchronization Like Ethereum's weak subjectivity period, State Sync allows new nodes to rapidly join the network by downloading snapshots of the application state. This can be quicker than replaying all historical blocks but results in a truncated block history. ## Example Scenarios This section provides an overview and sequence diagrams of [different scenarios described in the ABCI++ spec](https://github.com/cometbft/cometbft/blob/main/spec/abci/abci%2B%2B_example_scenarios.md) that can occur in the Tendermint consensus algorithm. Each scenario represents potential interactions between different processes. *The diagrams provide a simplified overview and do not capture every detail or possible condition that could occur during the protocol.* #### Scenario 1 This scenario represents a situation where Process P calls ProcessProposal many times with different values. ```mermaid sequenceDiagram participant P as Process P participant B as Byzantine Process participant C1 as Correct Process 1 participant C2 as Correct Process 2 Note over P, C1: Round 0 B-->P: Does not send proposal message P-->P: Timeout (no ProcessProposal call) Note over P, C1: Round 1 C1-->P: Proposes block Y P-->P: ProcessProposal for block Y Note over P, C1: Round 2 C2-->P: Proposes block Z P-->P: ProcessProposal for block Z P-->P: Keeps repeating until consensus reached ``` #### Scenario 2 This scenario shows Process P calling PrepareProposal many times with different values. ```mermaid sequenceDiagram participant P as Process P participant M as Mempool participant C as Correct Process Note over P, C: Round 0 P-->M: Asks for new block X M-->P: Returns block X P-->P: PrepareProposal for X, ProcessProposal for X Note over P, C: Further Rounds P-->P: PrepareProposal for multiple blocks as it's the proposer multiple times (without updating lockedBlock) ``` #### Scenario 3 In this scenario, Process P calls PrepareProposal and ProcessProposal for many values, but decides on a value for which it did not call PrepareProposal or ProcessProposal. ```mermaid sequenceDiagram participant P as Process P participant B as Byzantine Process participant C as Correct Process Note over P, C: Rounds before N P-->P: PrepareProposal and ProcessProposal for multiple blocks Note over P, C: Round N C-->P: Proposes block X P-->P: Does not call ProcessProposal due to asynchrony but receives sufficient prevote messages for X and updates lockedRound and lockedBlock P-->P: Receives sufficient precommit messages and decides on block X ``` #### Scenario 4 In this scenario, Process P does not call PrepareProposal and ProcessProposal at all, yet is still able to reach a decision on a block. ```mermaid sequenceDiagram participant P as Process P participant B as Byzantine Process participant C as Correct Process Note over P, C: Rounds before N P-->P: Does not call PrepareProposal or ProcessProposal (asynchrony or Byzantine proposer) Note over P, C: Round N C-->P: Proposes block X P-->P: Does not call ProcessProposal due to asynchrony but receives sufficient prevote messages for X and updates lockedRound and lockedBlock P-->P: Receives sufficient precommit messages and decides on block X ``` ## Summary Conceptually, applications are different in Ethereum and Cosmos. In Ethereum applications are viewed as bytecode deployed to the chain, but in Cosmos it is the bytecode associated with and run alongside the chain. The latter approach is often referred to as "app specific chains", although nothing about the Cosmos SDKs require this to be the specific case. Nonetheless this difference grants applications flexibility in how they interact with consensus. ABCI++, an enhanced version of the original ABCI in Cosmos, amplifies these interactions. It offers opportunities for applications to engage more deeply with the consensus algorithm, influencing aspects such as proposal creation, validation, and precommit voting, differing from Ethereum's approach. Furthermore, ABCI++ allows developers to control transaction ordering and execution. This feature introduces a new level of flexibility for applications in the Cosmos ecosystem, allowing them to exercise more control over their consensus algorithm. This interface creates the base layer with which an application can create MEV policies, within certain constraints.