Core trait definitions for components of an ABCI application using
This crate defines two traits for use by “component crates”:
Component, which defines the internally driven behavior of a component, triggered at the beginning and end of blocks and at the ends of epochs;
ActionHandler, which defines the externally driven behavior of a component, triggered by actions in blockchain transactions.
Component crates should be structured as follows:
- Definitions of any transaction actions related to the component, and their corresponding plans and views;
crate::componentmodule, feature-gated by the
componentfeature, with the
ActionHandlerimplementations for any locally-defined actions, and any other code touching the chain state inside;
crate::state_keymodule defining the component’s state keys (which are a public API, like the rest of the chain state);
crate::eventmodule defining any events emitted by the component;
The structure of the feature-gated
component submodule allows reusing data
structures between client and server (fullnode) code.
For instance, the
penumbra_transaction crate depends on all of the
component crates without the
component feature, so it can assemble all of
the actions for each component into a top-level transaction type. This
means all async code should be confined to the
component module, so that
the transaction definitions don’t depend on
mio, etc and can be
used without problems in wasm or other non-async contexts.
On the other hand, the
penumbra_app crate depends on all of the component
crates with the
component feature enabled, so it can assemble all of the
ActionHandler implementations into a top-level
implementation and call each component’s
Component implementation at the
- Defines the interface for handling transaction actions.
- A component of a