This is a living document, meant to give some pointers on how we add messages and queries to the system.
Slay3r uses it's own (unserialized) types to route messages and queries internally to the various modules. You can find these types here:
We only create these types internally, and notably they use AccountId, which is a parsed and validated bytes rather than the bech32 string (which this serializes as).
In layer_app::StateMachine, we route these at
StateMachine::process_message and
StateMachine::query to the proper module.
We define the set of modules at compile-time, rather than dynamic, extensible hooks,
so we can be very strictly types here and do exhaustive matches.
The modules then handle them, and return a strictly typed, deep enums: layer_std::MsgData and layer_std::QueryResponse
Notably you can already write internal tests here without worrying about auth logic, protobuf encodings or any nasty serialization and setup.
CosmWasm contracts return CosmosMsg and call cosmwasm_std::Query objects. These are not natively supported
by slay3r (as we want our API to be able to evolve independently from CosmWasm), but there is generally
a relatively simple mapping from these object to the equivalent slay3r::{Msg,Query} types and from
those reponses to the CosmWasm responses.
The location of this transition should probably be refactored sometime, but you can find the
query-related calls in layer_app::wasm::vm::backend:
The messages are dispatched in WasmKeeper::dispatch_response_messages and the calls are at:
This happens in slayer_cosmos but is rather complex and will be explained more later.
This commit is a nice example of how we handle queries. It includes attaching the grpc handler for the query, the abci handler, and adding a new internal query type, which is added to the wasm keeper. At the least it shows you all the places that need to be updated to add a query full-stack.
TODO: example with messages