The context
is a data structure intended to be passed from function to function that carries information about the current state of the application. It holds a cached copy of the entire state as well as useful objects and information like gasMeter
, block height
, consensus parameters
and more. {synopsis}
- Anatomy of an SDK Application {prereq}
- Lifecycle of a Transaction {prereq}
The SDK Context
is a custom data structure that contains Go's stdlib context
as its base, and has many additional types within its definition that are specific to the Cosmos SDK. he Context
is integral to transaction processing in that it allows modules to easily access their respective store in the multistore
and retrieve transactional context such as the block header and gas meter.
type Context struct {
ctx context.Context
ms MultiStore
header tmproto.Header
chainID string
txBytes []byte
logger log.Logger
voteInfo []abci.VoteInfo
gasMeter GasMeter
blockGasMeter GasMeter
checkTx bool
minGasPrice DecCoins
consParams *abci.ConsensusParams
eventManager *EventManager
}
- Context: The base type is a Go Context, which is explained further in the Go Context Package section below.
- Multistore: Every application's
BaseApp
contains aCommitMultiStore
which is provided when aContext
is created. Calling theKVStore()
andTransientStore()
methods allows modules to fetch their respectiveKVStore
using their uniqueStoreKey
. - ABCI Header: The header is an ABCI type. It carries important information about the state of the blockchain, such as block height and proposer of the current block.
- Chain ID: The unique identification number of the blockchain a block pertains to.
- Transaction Bytes: The
[]byte
representation of a transaction being processed using the context. Every transaction is processed by various parts of the SDK and consensus engine (e.g. Tendermint) throughout its lifecycle, some of which to not have any understanding of transaction types. Thus, transactions are marshaled into the generic[]byte
type using some kind of encoding format such as Amino. - Logger: A
logger
from the Tendermint libraries. Learn more about logs here. Modules call this method to create their own unique module-specific logger. - VoteInfo: A list of the ABCI type
VoteInfo
, which includes the name of a validator and a boolean indicating whether they have signed the block. - Gas Meters: Specifically, a
gasMeter
for the transaction currently being processed using the context and ablockGasMeter
for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much gas has been used in the transaction or block so far. If the gas meter runs out, execution halts. - CheckTx Mode: A boolean value indicating whether a transaction should be processed in
CheckTx
orDeliverTx
mode. - Min Gas Price: The minimum gas price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore not be used in any functions used in sequences leading to state-transitions.
- Consensus Params: The ABCI type Consensus Parameters, which specify certain limits for the blockchain, such as maximum gas for a block.
- Event Manager: The event manager allows any caller with access to a
Context
to emitEvents
. Modules may define module specificEvents
by defining variousTypes
andAttributes
or use the common definitions found intypes/
. Clients can subscribe or query for theseEvents
. TheseEvents
are collected throughoutDeliverTx
,BeginBlock
, andEndBlock
and are returned to Tendermint for indexing. For example:
ctx.EventManager().EmitEvent(sdk.NewEvent(
sdk.EventTypeMessage,
sdk.NewAttribute(sdk.AttributeKeyModule, types.AttributeValueCategory)),
)
A basic Context
is defined in the Golang Context Package. A Context
is an immutable data structure that carries request-scoped data across APIs and processes. Contexts
are also designed to enable concurrency and to be used in goroutines.
Contexts are intended to be immutable; they should never be edited. Instead, the convention is
to create a child context from its parent using a With
function. For example:
childCtx = parentCtx.WithBlockHeader(header)
The Golang Context Package documentation instructs developers to
explicitly pass a context ctx
as the first argument of a process.
The Context
contains a MultiStore
, which allows for cache-wrapping functionality: a CacheMultiStore
where each KVStore
is is wrapped with an ephemeral cache. Processes are free to write changes to
the CacheMultiStore
, then write the changes back to the original state or disregard them if something
goes wrong. The pattern of usage for a Context is as follows:
- A process receives a Context
ctx
from its parent process, which provides information needed to perform the process. - The
ctx.ms
is cache wrapped, i.e. a cached copy of the multistore is made so that the process can make changes to the state as it executes, without changing the originalctx.ms
. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. - The process may read and write from
ctx
as it is executing. It may call a subprocess and passctx
to it as needed. - When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing
needs to be done - the cache wrapped
ctx
is simply discarded. If successful, the changes made to the cache-wrappedMultiStore
can be committed to the originalctx.ms
viaWrite()
.
For example, here is a snippet from the runTx
function in
baseapp
:
runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes)
result = app.runMsgs(runMsgCtx, msgs, mode)
result.GasWanted = gasWanted
if mode != runTxModeDeliver {
return result
}
if result.IsOK() {
msCache.Write()
}
Here is the process:
- Prior to calling
runMsgs
on the message(s) in the transaction, it usesapp.cacheTxContext()
to cache-wrap the context and multistore. - The cache-wrapped context,
runMsgCtx
, is used inrunMsgs
to return a result. - If the process is running in
checkTxMode
, there is no need to write the changes - the result is returned immediately. - If the process is running in
deliverTxMode
and the result indicates a successful run over all the messages, the cached multistore is written back to the original.
Learn about the node client {hide}