# BaseApp

The BaseApp defines the foundational implementation for a basic ABCI application so that your Cosmos-SDK application can communicate with an underlying Tendermint node.

The BaseApp is composed of many internal components. Some of the most important include the CommitMultiStore and its internal state. The internal state is essentially two sub-states, both of which are used for transaction execution during different phases, CheckTx and DeliverTx respectively. During block commitment, only the DeliverTx is persisted.

The BaseApp requires stores to be mounted via capabilities keys - handlers can only access stores they're given the key to. The baseApp ensures all stores are properly loaded, cached, and committed. One mounted store is considered the "main" (baseApp.MainStoreKey) - it holds the latest block header, from which we can find and load the most recent state.

The BaseApp distinguishes between two handler types - the AnteHandler and the MsgHandler. The former is a global validity check (checking nonces, sigs and sufficient balances to pay fees, e.g. things that apply to all transaction from all modules), the later is the full state transition function.

During CheckTx the state transition function is only applied to the checkTxState and should return before any expensive state transitions are run (this is up to each developer). It also needs to return the estimated gas cost.

During DeliverTx the state transition function is applied to the blockchain state and the transactions need to be fully executed.

The BaseApp is responsible for managing the context passed into handlers - it makes the block header available and provides the right stores for CheckTx and DeliverTx. BaseApp is completely agnostic to serialization formats.

# Transaction Life Cycle

During the execution of a transaction, it may pass through both CheckTx and DeliverTx as defined in the ABCI specification. CheckTx is executed by the proposing validator and is used for the Tendermint mempool for all full nodes.

Both CheckTx and DeliverTx execute the application's AnteHandler (if defined), where the AnteHandler is responsible for pre-message validation checks such as account and signature validation, fee deduction and collection, and incrementing sequence numbers.

# CheckTx

During the execution of CheckTx, only the AnteHandler is executed.

State transitions due to the AnteHandler are persisted between subsequent calls of CheckTx in the check-tx state, unless the AnteHandler fails and aborts.

# DeliverTx

During the execution of DeliverTx, the AnteHandler and Handler is executed.

The transaction execution during DeliverTx operates in a similar fashion to CheckTx. However, state transitions that occur during the AnteHandler are persisted even when the following Handler processing logic fails.

It is possible that a malicious proposer may include a transaction in a block that fails the AnteHandler. In this case, all state transitions for the offending transaction are discarded.

# Other ABCI Messages

Besides CheckTx and DeliverTx, BaseApp handles the following ABCI messages.

# Info

TODO complete description

# SetOption

TODO complete description

# Query

TODO complete description

# InitChain

TODO complete description

During chain initialization InitChain runs the initialization logic directly on the CommitMultiStore. The deliver and check states are initialized with the ChainID.

Note that we do not commit after InitChain, so BeginBlock for block 1 starts from the deliver state as initialized by InitChain.

# BeginBlock

TODO complete description

# EndBlock

TODO complete description

# Commit

TODO complete description

# Gas Management

# Gas: InitChain

During InitChain, the block gas meter is initialized with an infinite amount of gas to run any genesis transactions.

Additionally, the InitChain request message includes ConsensusParams as declared in the genesis.json file.

# Gas: BeginBlock

The block gas meter is reset during BeginBlock for the deliver state. If no maximum block gas is set within baseapp then an infinite gas meter is set, otherwise a gas meter with ConsensusParam.BlockSize.MaxGas is initialized.

# Gas: DeliverTx

Before the transaction logic is run, the BlockGasMeter is first checked to see if any gas remains. If no gas remains, then DeliverTx immediately returns an error.

After the transaction has been processed, the used gas (up to the transaction gas limit) is deducted from the BlockGasMeter. If the remaining gas exceeds the meter's limits, then DeliverTx returns an error and the transaction is not committed.