Methods

    Methods existing in ABCI

    Echo

    Flush

    Info

    Note: Semantic version is a reference to semantic versioning. Semantic versions in info will be displayed as X.X.x.

    InitChain

    Query

    CheckTx

    BeginBlock

    DeliverTx

    EndBlock

    Commit

    ListSnapshots

    LoadSnapshotChunk

    OfferSnapshot

    Result

      enum Result {
    UNKNOWN       = 0;  // Unknown result, abort all snapshot restoration
    ACCEPT        = 1;  // Snapshot is accepted, start applying chunks.
    ABORT         = 2;  // Abort snapshot restoration, and don't try any other snapshots.
    REJECT        = 3;  // Reject this specific snapshot, try others.
    REJECT_FORMAT = 4;  // Reject all snapshots with this `format`, try others.
    REJECT_SENDER = 5;  // Reject all snapshots from all senders of this snapshot, try others.
  }

    ApplySnapshotChunk

      enum Result {
    UNKNOWN         = 0;  // Unknown result, abort all snapshot restoration
    ACCEPT          = 1;  // The chunk was accepted.
    ABORT           = 2;  // Abort snapshot restoration, and don't try any other snapshots.
    RETRY           = 3;  // Reapply this chunk, combine with `RefetchChunks` and `RejectSenders` as appropriate.
    RETRY_SNAPSHOT  = 4;  // Restart this snapshot from `OfferSnapshot`, reusing chunks unless instructed otherwise.
    REJECT_SNAPSHOT = 5;  // Reject this snapshot, try a different one.
  }

    New methods introduced in ABCI 2.0

    PrepareProposal

    Parameters and Types

    When does CometBFT call PrepareProposal ?

    When a validator p enters consensus round r, height h, in which p is the proposer, and p’s validValue is nil:

    1. CometBFT collects outstanding transactions from p’s mempool
      • the transactions will be collected in order of priority
      • p’s CometBFT creates a block header.
    2. p’s CometBFT calls RequestPrepareProposal with the newly generated block, the local commit of the previous height (with vote extensions), and any outstanding evidence of misbehavior. The call is synchronous: CometBFT’s execution will block until the Application returns from the call.
    3. The Application uses the information received (transactions, commit info, misbehavior, time) to (potentially) modify the proposal.
      • the Application MAY fully execute the block and produce a candidate state (immediate execution)
      • the Application can manipulate transactions:
        • leave transactions untouched
        • add new transactions (not present initially) to the proposal
        • remove transactions from the proposal (but not from the mempool thus effectively delaying them) - the Application does not include the transaction in ResponsePrepareProposal.txs.
        • modify transactions (e.g. aggregate them). As explained above, this compromises client traceability, unless it is implemented at the Application level.
        • reorder transactions - the Application reorders transactions in the list
    4. The Application includes the transaction list (whether modified or not) in the return parameters (see the rules in section Usage), and returns from the call.
    5. p uses the (possibly) modified block as p’s proposal in round r, height h.

    Note that, if p has a non-nil validValue in round r, height h, the consensus algorithm will use it as proposal and will not call RequestPrepareProposal.

    ProcessProposal

    Parameters and Types

    When does CometBFT call ProcessProposal ?

    When a node p enters consensus round r, height h, in which q is the proposer (possibly p = q):

    1. p sets up timer ProposeTimeout.
    2. If p is the proposer, p executes steps 1-6 in PrepareProposal.
    3. Upon reception of Proposal message (which contains the header) for round r, height h from q, p verifies the block header.
    4. Upon reception of Proposal message, along with all the block parts, for round r, height h from q, p follows the validators’ algorithm to check whether it should prevote for the proposed block, or nil.
    5. If the validators’ consensus algorithm indicates p should prevote non-nil:
      1. CometBFT calls RequestProcessProposal with the block. The call is synchronous.
      2. The Application checks/processes the proposed block, which is read-only, and returns ACCEPT or REJECT in the ResponseProcessProposal.status field.
        • The Application, depending on its needs, may call ResponseProcessProposal
          • either after it has completely processed the block (immediate execution),
          • or after doing some basic checks, and process the block asynchronously. In this case the Application will not be able to reject the block, or force prevote/precommit nil afterwards.
          • or immediately, returning ACCEPT, if p is not a validator and the Application does not want non-validating nodes to handle ProcessProposal
      3. If p is a validator and the returned value is
        • ACCEPT: p prevotes on this proposal for round r, height h.
        • REJECT: p prevotes nil.

    Data Types existing in ABCI

    Most of the data structures used in ABCI are shared common data structures. In certain cases, ABCI uses different data structures which are documented here:

    Validator

    ValidatorUpdate

    Misbehavior

    MisbehaviorType

    ConsensusParams

    ProofOps

    ProofOp

    Snapshot

    Data types introduced or modified in ABCI++

    VoteInfo

    ExtendedVoteInfo

    CommitInfo

    ExtendedCommitInfo

    ProposalStatus

    enum ProposalStatus {
  UNKNOWN = 0; // Unknown status. Returning this from the application is always an error.
  ACCEPT  = 1; // Status that signals that the application finds the proposal valid.
  REJECT  = 2; // Status that signals that the application finds the proposal invalid.
}
    Decorative Orb