The sov-modules-api
crate provides essential traits for the Module System. Here are the key traits defined by the
crate:
-
The
Module
trait: Defines how to initialize and change the state of a module. This is the main trait that module developers need to implement. The author of a module must specify:-
Configuration upon rollup deployment: This includes the
genesis()
method and theConfig
type, which determine how the module is set up initially. Note that the initialization for logic for modules is identical to theGenesis
trait (described below). We blanket implementGenesis
for allModule
s, but keep it as a separate trait since some other structs need to implement it as well. -
Interaction with user messages: The module must define the
call
method and theCallMessage
type, which handle user messages. These messages typically result in changes to the module's state.
-
-
The
ModuleInfo
trait: Provides additional information related to a module. This trait is automatically derived. -
The
Spec
trait: It defines all the types that modules are generic over. This separation allows the module logic to be independent of concerns such as the specific storage system or concrete signature schemes used for signing rollup transactions. Currently acceptable hashes forSpec
should fit into 32 bytes. -
The
Context
trait implements theSpec
and introduces additional methods accessible within modules. Currently, it includes thesender()
method, which returns the address of the transaction sender. This trait will be further extended with other useful methods, such asbatch_hash()
, and more. This crate defines also the default implementation for theContext
trait. -
The
Genesis
trait: Defines how the rollup is initialized during deployment phase. -
The
DispatchCall
trait: Defines how messages are forwarded to the appropriate module and how the call message is executed. The implementation of this trait can be generated automatically using a macro.