Support for custom modules in Atomkraft

[dalmirel]

Currently Atomkraft is having implemented GRPC broadcasting only for Cosmos SDK modules and x/wasmd module trough terra_sdk. That is, the mechanism of easily creating tx and broadcasting them to the chain works only for modules covered in this package.

In audits, we will mostly have the need to audit and create and execute tests with Atomkraft for custom built modules and will need the fastest way to cover some module with tests. If an auditor could think only of parsing the traces and creating test assertions during the Atomkraft adaptation for a project, it would be great (we need to be as fast as possible).

Currently the audit team will use the CLI binary in order to create and execute tests for custom modules build for other chains, but it would be nice if there is a way to:

• easily define new Msg type or query and use the existing GRPC broadcasting or
• use CLI, but without the need to worry about details around building the commands that will be sent to the chain.

[rnbguy]

Cosmos GRPC supports reflections. One can leverage it to load proto files from live GRPC endpoints without access to source protobufs.

The following examples uses grpculrl on CLI. We need to find a library to do the same programmatically during Atomkraft runtime.

Describing a query

$ grpcurl -plaintext <GRPC_IP:PORT> describe cosmos.staking.v1beta1.Query.Validator
cosmos.staking.v1beta1.Query.Validator is a method:
rpc Validator ( .cosmos.staking.v1beta1.QueryValidatorRequest ) returns ( .cosmos.staking.v1beta1.QueryValidatorResponse ) {
  option (.google.api.http) = { get:"/cosmos/staking/v1beta1/validators/{validator_addr}"  };
}

Performing the query

$ grpcurl -plaintext -d '{"validator_addr": "cosmosvaloper16k579jk6yt2cwmqx9dz5xvq9fug2tekvlu9qdv"}' <GRPC_IP:PORT> cosmos.staking.v1beta1.Query.Validator
{
  "validator": {
    "operatorAddress": "cosmosvaloper16k579jk6yt2cwmqx9dz5xvq9fug2tekvlu9qdv",
    "consensusPubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"pTcg/QVBC+LzpR0BuynDpMkNh4tajyeKCOtmWMfkvFU="},
    "status": "BOND_STATUS_BONDED",
    "tokens": "3217496887306",
    "delegatorShares": "3217818666723387338143077808531",
    "description": {
      "moniker": "Informal Systems",
...

The type_urls and proto files for Msg types can be retrieved from cosmos.base.reflection.v1beta1.ReflectionService and cosmos.base.reflection.v2alpha1.ReflectionService.

Listing all tx msg types

$ grpcurl -plaintext <GRPC_IP:PORT> cosmos.base.reflection.v2alpha1.ReflectionService.GetTxDescriptor
{
  "tx": {
    "fullname": "cosmos.tx.v1beta1.Tx",
    "msgs": [
      {
        "msgTypeUrl": "/ibc.core.channel.v1.MsgChannelOpenInit"
      },
      {
        "msgTypeUrl": "/ibc.core.channel.v1.MsgChannelCloseConfirm"
...

Describing a tx msg type

$ grpcurl -plaintext <GRPC_IP:PORT> describe ibc.core.channel.v1.MsgChannelOpenInit
ibc.core.channel.v1.MsgChannelOpenInit is a message:
message MsgChannelOpenInit {
  option (.gogoproto.equal) = false;
  option (.gogoproto.goproto_getters) = false;
  string port_id = 1 [(.gogoproto.moretags) = "yaml:\port_id\"];
  .ibc.core.channel.v1.Channel channel = 2 [(.gogoproto.nullable) = false];
  string signer = 3;
}