Skip to main content
Version: v0.47

Module Manager

Synopsis

Cosmos SDK modules need to implement the AppModule interfaces, in order to be managed by the application's module manager. The module manager plays an important role in message and query routing, and allows application developers to set the order of execution of a variety of functions like BeginBlocker and EndBlocker.

note

Pre-requisite Readings​

Application Module Interfaces​

Application module interfaces exist to facilitate the composition of modules together to form a functional Cosmos SDK application. There are 4 main application module interfaces:

  • AppModuleBasic for independent module functionalities.
  • AppModule for inter-dependent module functionalities (except genesis-related functionalities).
  • AppModuleGenesis for inter-dependent genesis-related module functionalities.
  • GenesisOnlyAppModule: Defines an AppModule that only has import/export functionality

The above interfaces are mostly embedding smaller interfaces (extension interfaces), that defines specific functionalities:

  • HasName: Allows the module to provide its own name for legacy purposes.
  • HasGenesisBasics: The legacy interface for stateless genesis methods.
  • HasGenesis: The extension interface for stateful genesis methods.
  • HasInvariants: The extension interface for registering invariants.
  • HasServices: The extension interface for modules to register services.
  • HasConsensusVersion: The extension interface for declaring a module consensus version.
  • BeginBlockAppModule: The extension interface that contains information about the AppModule and BeginBlock.
  • EndBlockAppModule: The extension interface that contains information about the AppModule and EndBlock.
  • HasPrecommit: The extension interface that contains information about the AppModule and Precommit.
  • HasPrepareCheckState: The extension interface that contains information about the AppModule and PrepareCheckState.

The AppModuleBasic interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the init() function of the main application file.

The AppModule interface exists to define inter-dependent module methods. Many modules need to interact with other modules, typically through keepers, which means there is a need for an interface where modules list their keepers and other methods that require a reference to another module's object. AppModule interface extension, such as BeginBlockAppModule and EndBlockAppModule, also enables the module manager to set the order of execution between module's methods like BeginBlock and EndBlock, which is important in cases where the order of execution between modules matters in the context of the application.

The usage of extension interfaces allows modules to define only the functionalities they need. For example, a module that does not need an EndBlock does not need to define the EndBlockAppModule interface and thus the EndBlock method. AppModule and AppModuleGenesis are voluntarily small interfaces, that can take advantage of the Module patterns without having to define many placeholder functions.

AppModuleBasic​

The AppModuleBasic interface defines the independent methods modules need to implement.

types/module/module.go
loading...

Let us go through the methods:

  • RegisterLegacyAminoCodec(*codec.LegacyAmino): Registers the amino codec for the module, which is used to marshal and unmarshal structs to/from []byte in order to persist them in the module's KVStore.
  • RegisterInterfaces(codectypes.InterfaceRegistry): Registers a module's interface types and their concrete implementations as proto.Message.
  • RegisterGRPCGatewayRoutes(client.Context, *runtime.ServeMux): Registers gRPC routes for the module.
  • GetTxCmd(): Returns the root Tx command for the module. The subcommands of this root command are used by end-users to generate new transactions containing messages defined in the module.
  • GetQueryCmd(): Return the root query command for the module. The subcommands of this root command are used by end-users to generate new queries to the subset of the state defined by the module.

All the AppModuleBasic of an application are managed by the BasicManager.

HasName​

types/module/module.go
loading...
  • HasName is an interface that has a method Name(). This method returns the name of the module as a string.

HasGenesisBasics​

types/module/module.go
loading...

Let us go through the methods:

  • DefaultGenesis(codec.JSONCodec): Returns a default GenesisState for the module, marshalled to json.RawMessage. The default GenesisState need to be defined by the module developer and is primarily used for testing.
  • ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage): Used to validate the GenesisState defined by a module, given in its json.RawMessage form. It will usually unmarshall the json before running a custom ValidateGenesis function defined by the module developer.

AppModuleGenesis​

The AppModuleGenesis interface is a simple embedding of the AppModuleBasic and HasGenesis interfaces.

types/module/module.go
loading...

It does not have its own manager, and exists separately from AppModule only for modules that exist only to implement genesis functionalities, so that they can be managed without having to implement all of AppModule's methods.

HasGenesis​

The HasGenesis interface is an extension interface of HasGenesisBasics.

types/module/module.go
loading...

Let us go through the two added methods:

  • InitGenesis(sdk.Context, codec.JSONCodec, json.RawMessage): Initializes the subset of the state managed by the module. It is called at genesis (i.e. when the chain is first started).
  • ExportGenesis(sdk.Context, codec.JSONCodec): Exports the latest subset of the state managed by the module to be used in a new genesis file. ExportGenesis is called for each module when a new chain is started from the state of an existing chain.

AppModule​

The AppModule interface defines a module. Modules can declare their functionalities by implementing extensions interfaces.

types/module/module.go
loading...

AppModules are managed by the module manager, which checks which extension interfaces are implemented by the module.

note

Previously the AppModule interface was containing all the methods that are defined in the extensions interfaces. This was leading to much boilerplate for modules that did not need all the functionalities.

HasInvariants​

This interface defines one method. It allows to checks if a module can register invariants.

types/module/module.go
loading...
  • RegisterInvariants(sdk.InvariantRegistry): Registers the invariants of the module. If an invariant deviates from its predicted value, the InvariantRegistry triggers appropriate logic (most often the chain will be halted).

HasServices​

This interface defines one method. It allows to checks if a module can register invariants.

types/module/module.go
loading...
  • RegisterServices(Configurator): Allows a module to register services.

HasConsensusVersion​

This interface defines one method for checking a module consensus version.

types/module/module.go
loading...
  • ConsensusVersion() uint64: Returns the consensus version of the module.

BeginBlockAppModule​

The BeginBlockAppModule is an extension interface from AppModule. All modules that have an BeginBlock method implement this interface.

types/module/module.go
loading...
  • BeginBlock(sdk.Context, abci.RequestBeginBlock): This method gives module developers the option to implement logic that is automatically triggered at the beginning of each block. Implement empty if no logic needs to be triggered at the beginning of each block for this module.

EndBlockAppModule​

The EndBlockAppModule is an extension interface from AppModule. All modules that have an EndBlock method implement this interface.

types/module/module.go
loading...
  • EndBlock(sdk.Context, abci.RequestEndBlock): This method gives module developers the option to implement logic that is automatically triggered at the end of each block. This is also where the module can inform the underlying consensus engine of validator set changes (e.g. the staking module). Implement empty if no logic needs to be triggered at the end of each block for this module.

HasPrecommit​

HasPrecommit is an extension interface from AppModule. All modules that have a Precommit method implement this interface.

  • Precommit(sdk.Context): This method gives module developers the option to implement logic that is automatically triggered during `Commit' of each block using the deliverState of the block to be committed. Implement empty if no logic needs to be triggered during Commit of each block for this module.

HasPrepareCheckState​

HasPrepareCheckState is an extension interface from AppModule. All modules that have a PrepareCheckState method implement this interface.

  • PrepareCheckState(sdk.Context): This method gives module developers the option to implement logic that is automatically triggered during `Commit' of each block using the checkState of the next block. Implement empty if no logic needs to be triggered during Commit of each block for this module.

Implementing the Application Module Interfaces​

Typically, the various application module interfaces are implemented in a file called module.go, located in the module's folder (e.g. ./x/module/module.go).

Almost every module needs to implement the AppModuleBasic and AppModule interfaces. If the module is only used for genesis, it will implement AppModuleGenesis instead of AppModule. The concrete type that implements the interface can add parameters that are required for the implementation of the various methods of the interface. For example, the Route() function often calls a NewMsgServerImpl(k keeper) function defined in keeper/msg_server.go and therefore needs to pass the module's keeper as a parameter.

// example
type AppModule struct {
    AppModuleBasic
    keeper       Keeper
}

In the example above, you can see that the AppModule concrete type references an AppModuleBasic, and not an AppModuleGenesis. That is because AppModuleGenesis only needs to be implemented in modules that focus on genesis-related functionalities. In most modules, the concrete AppModule type will have a reference to an AppModuleBasic and implement the two added methods of AppModuleGenesis directly in the AppModule type.

If no parameter is required (which is often the case for AppModuleBasic), just declare an empty concrete type like so:

type AppModuleBasic struct{}

Module Managers​

Module managers are used to manage collections of AppModuleBasic and AppModule.

BasicManager​

The BasicManager is a structure that lists all the AppModuleBasic of an application:

types/module/module.go
loading...

It implements the following methods:

  • NewBasicManager(modules ...AppModuleBasic): Constructor function. It takes a list of the application's AppModuleBasic and builds a new BasicManager. This function is generally called in the init() function of app.go to quickly initialize the independent elements of the application's modules (click here to see an example).
  • RegisterLegacyAminoCodec(cdc *codec.LegacyAmino): Registers the codec.LegacyAminos of each of the application's AppModuleBasic. This function is usually called early on in the application's construction.
  • RegisterInterfaces(registry codectypes.InterfaceRegistry): Registers interface types and implementations of each of the application's AppModuleBasic.
  • DefaultGenesis(cdc codec.JSONCodec): Provides default genesis information for modules in the application by calling the DefaultGenesis(cdc codec.JSONCodec) function of each module. It only calls the modules that implements the HasGenesisBasics interfaces.
  • ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage): Validates the genesis information modules by calling the ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage) function of modules implementing the HasGenesisBasics interface.
  • RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux): Registers gRPC routes for modules.
  • AddTxCommands(rootTxCmd *cobra.Command): Adds modules' transaction commands to the application's rootTxCommand. This function is usually called function from the main.go function of the application's command-line interface.
  • AddQueryCommands(rootQueryCmd *cobra.Command): Adds modules' query commands to the application's rootQueryCommand. This function is usually called function from the main.go function of the application's command-line interface.

Manager​

The Manager is a structure that holds all the AppModule of an application, and defines the order of execution between several key components of these modules:

types/module/module.go
loading...

The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods:

  • NewManager(modules ...AppModule): Constructor function. It takes a list of the application's AppModules and builds a new Manager. It is generally called from the application's main constructor function.
  • SetOrderInitGenesis(moduleNames ...string): Sets the order in which the InitGenesis function of each module will be called when the application is first started. This function is generally called from the application's main constructor function. To initialize modules successfully, module dependencies should be considered. For example, the genutil module must occur after staking module so that the pools are properly initialized with tokens from genesis accounts, the genutils module must also occur after auth so that it can access the params from auth, IBC's capability module should be initialized before all other modules so that it can initialize any capabilities.
  • SetOrderExportGenesis(moduleNames ...string): Sets the order in which the ExportGenesis function of each module will be called in case of an export. This function is generally called from the application's main constructor function.
  • SetOrderBeginBlockers(moduleNames ...string): Sets the order in which the BeginBlock() function of each module will be called at the beginning of each block. This function is generally called from the application's main constructor function.
  • SetOrderEndBlockers(moduleNames ...string): Sets the order in which the EndBlock() function of each module will be called at the end of each block. This function is generally called from the application's main constructor function.
  • SetOrderPrecommiters(moduleNames ...string): Sets the order in which the Precommit() function of each module will be called during commit of each block. This function is generally called from the application's main constructor function.
  • SetOrderPrepareCheckStaters(moduleNames ...string): Sets the order in which the PrepareCheckState() function of each module will be called during commit of each block. This function is generally called from the application's main constructor function.
  • SetOrderMigrations(moduleNames ...string): Sets the order of migrations to be run. If not set then migrations will be run with an order defined in DefaultMigrationsOrder.
  • RegisterInvariants(ir sdk.InvariantRegistry): Registers the invariants of module implementing the HasInvariants interface.
  • RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino): Registers legacy Msg and querier routes.
  • RegisterServices(cfg Configurator): Registers the services of modules implementing the HasServices interface.
  • InitGenesis(ctx sdk.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage): Calls the InitGenesis function of each module when the application is first started, in the order defined in OrderInitGenesis. Returns an abci.ResponseInitChain to the underlying consensus engine, which can contain validator updates.
  • ExportGenesis(ctx sdk.Context, cdc codec.JSONCodec): Calls the ExportGenesis function of each module, in the order defined in OrderExportGenesis. The export constructs a genesis file from a previously existing state, and is mainly used when a hard-fork upgrade of the chain is required.
  • ExportGenesisForModules(ctx sdk.Context, cdc codec.JSONCodec, modulesToExport []string): Behaves the same as ExportGenesis, except takes a list of modules to export.
  • BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock): At the beginning of each block, this function is called from BaseApp and, in turn, calls the BeginBlock function of each modules implementing the BeginBlockAppModule interface, in the order defined in OrderBeginBlockers. It creates a child context with an event manager to aggregate events emitted from all modules. The function returns an abci.ResponseBeginBlock which contains the aforementioned events.
  • EndBlock(ctx sdk.Context, req abci.RequestEndBlock): At the end of each block, this function is called from BaseApp and, in turn, calls the EndBlock function of each modules implementing the EndBlockAppModule interface, in the order defined in OrderEndBlockers. It creates a child context with an event manager to aggregate events emitted from all modules. The function returns an abci.ResponseEndBlock which contains the aforementioned events, as well as validator set updates (if any).
  • Precommit(ctx sdk.Context): During Commit, this function is called from BaseApp immediately before the deliverState is written to the underlying rootMultiStore and, in turn calls the Precommit function of each modules implementing the HasPrecommit interface, in the order defined in OrderPrecommiters. It creates a child context where the underlying CacheMultiStore is that of the newly committed block's deliverState.
  • PrepareCheckState(ctx sdk.Context): During Commit, this function is called from BaseApp immediately after the deliverState is written to the underlying rootMultiStore and, in turn calls the PrepareCheckState function of each module implementing the HasPrepareCheckState interface, in the order defined in OrderPrepareCheckStaters. It creates a child context where the underlying CacheMultiStore is that of the next block's checkState. Writes to this state will be present in the checkState of the next block, and therefore this method can be used to prepare the checkState for the next block.

Here's an example of a concrete integration within an simapp:

simapp/app.go
loading...

This is the same example from runtime (the package that powers app v2):

runtime/module.go
loading...
runtime/module.go
loading...