Enum filament_app::Component

pub enum Component {
    Accounts(Accounts),
    Assets(Assets),
    Staking(Staking),
}

Variants

Accounts(Accounts)

Assets(Assets)

Staking(Staking)

Trait Implementations

impl ABCIComponent for Component

fn init_chain<'life0, 'life1, 'life2, 'async_trait, S>( &'life0 self, state: &'life1 mut S, app_state: &'life2 AppState ) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>

where S: 'async_trait + StateWrite, Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait,

Called once upon genesis.If ResponseInitChain.Validators is empty, the initial validator set will be the RequestInitChain.ValidatorsIf ResponseInitChain.Validators is not empty, it will be the initial validator set (regardless of what is in RequestInitChain.Validators).This allows the app to decide if it wants to accept the initial validator set proposed by tendermint (ie. in the genesis file), or if it wants to use a different one (perhaps computed based on some application specific information in the genesis file).

fn begin_block<'life0, 'life1, 'life2, 'async_trait, S>( &'life0 self, state: &'life1 mut S, begin_block: &'life2 BeginBlock ) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>

where S: 'async_trait + StateWrite, Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait,

Signals the beginning of a new block.Called prior to any DeliverTx method calls.The header contains the height, timestamp, and more - it exactly matches the Tendermint block header. We may seek to generalize this in the future.The LastCommitInfo and ByzantineValidators can be used to determine rewards and punishments for the validators.

fn end_block<'life0, 'life1, 'life2, 'async_trait, S>( &'life0 self, state: &'life1 mut S, end_block: &'life2 EndBlock ) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>

where S: 'async_trait + StateWrite, Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait,

Signals the end of a block.Called after all the transactions for the current block have been delivered, prior to the block’s Commit message.Optional validator_updates triggered by block H. These updates affect validation for blocks H+1, H+2, and H+3.Heights following a validator update are affected in the following way:H+1: NextValidatorsHash includes the new validator_updates value.H+2: The validator set change takes effect and ValidatorsHash is updated.H+3: LastCommitInfo is changed to include the altered validator set.consensus_param_updates returned for block H apply to the consensus params for block H+1. For more information on the consensus parameters, see the application spec entry on consensus parameters.