informalsystems/basecoin-rs

An example ABCI application making use of tendermint-rs and ibc-rs

basecoin-rs

At a high level, basecoin implements the application logic that sits between the Tendermint consensus layer and ibc-rs. It is a rudimentary Tendermint ABCI application that implements the following functionality in the form of modules -

• bank - keeps track of different accounts' balances and facilitates transactions between those accounts.
• ibc - enables support for IBC (clients, connections & channels)

Its main use-cases are serving as a testing ground and mock implementation for verifying the correctness and behaviour of the ibc-rs modules.

Requirements

So far this app has been tested with:

• Rust > v1.64
• CometBFT v0.37

How to integrate ibc-rs changes into basecoin

Since basecoin serves as a suite of integration tests against ibc-rs's functionality, each ibc-rs PR also requires an accompanying basecoin PR. The steps to do this are:

1. In a new branch in basecoin, update ibc revisions with the latest commit of the ibc-rs PR.
2. Implement the necessary changes in basecoin in order to get it working with the latest commit revision of ibc-rs.
3. Run cargo clippy --all-features and cargo clippy --no-default-features and fix any issues that clippy raises.
4. Open a PR in the basecoin-rs repository, making sure to the link to the associated ibc-rs PR.
5. Check to see if the integration tests pass.

Starting up an instance of basecoin

Step 1: Reset your local CometBFT node

$ cometbft init
$ cometbft unsafe-reset-all

Step 2: Modify CometBFT config

Edit the CometBFT config.toml file (default location ~/.cometbft/config/config.toml) to update the proxy_app and P2P laddr as follows.

proxy_app = "tcp://127.0.0.1:26358"
# ...
[p2p]
laddr = "tcp://0.0.0.0:26356"

Step 3: Module specific setup

See the module documentation for more details -

• Bank module
• Ibc module

Step 4: Run the basecoin app and CometBFT

# See all supported CLI options
$ cargo run -- --help
basecoin 0.1.0

USAGE:
    basecoin [FLAGS] [OPTIONS]

Commands:
    start
    query   Query a state of Basecoin application from the store
    help    Prints this message or the help of the given subcommand(s)

OPTIONS:
        --config <FILE>  The path to the configuration file [default: config.toml]
        --verbose        Increase output logging verbosity to DEBUG level
        --quiet          Suppress all output logging (overrides --verbose)
    -h  --help           Prints help information
    -V, --version        Prints version information

# Run the ABCI application (from this repo)
# The -v is to enable trace-level logging
$ cargo run -- -v

# In another terminal
$ cometbft node

UML diagrams

basecoin-rs's Issues

`ConnectionReader::host_consensus_state()` is not implemented

The ConnectionReader::host_consensus_state() impl is currently returning an empty mock result -> https://github.com/informalsystems/basecoin-rs/blob/main/src/app/modules/ibc.rs#L341-L350

fn host_consensus_state(
    &self,
    _height: IbcHeight,
) -> Result<AnyConsensusState, ConnectionError> {
    // FIXME: store host consensus state and return it here
    Ok(AnyConsensusState::Tendermint(ConsensusState::new(
        CommitmentRoot::from_bytes(&[]),
        Time::unix_epoch(),
        Hash::None,
    )))
}

This results in connection handhake verification failure (there are other problems with ibc-rs integration that I'm yet to figure out but this is one of them).

The reason this call was left unimplemented is because Tendermint doesn't provide a way for the ABCI app to query the consensus engine. (see tendermint/tendermint#5977)
The way the Cosmos-SDK gets around this is by having the staking module save consensus states (to private store) while handling the ABCI BeginBlock method. (see https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-017-historical-header-module.md)

I propose a slightly different approach for basecoin - which is to extend the modules trait to add a begin_block method that'll allow the ibc module to store consensus states in its private store.

Improve `ibc-integration` CI docker setup

The job takes 20 minutes to run. From running it locally, most of the time is spent running apt.

We should instead take a new docker image, which would have all the updates done already.

Upgrade `basecoin-rs` dependencies

Summary

Upgrade basecoin-rs dependencies with the goal of getting ready to apply changes that come from ongoing ADR05 and ADR06 implementations of cosmos/ibc-rs

connection with tendermint error

OS: Ubuntu
Rust: v1.59
Tendermint: v0.34.10
tendermint-basecoin 0.1.0

commends (terminal 1):
cargo run -- -v

commends (terminal 2):
tendermint node

After running tendermint node, basecoin-rs is panic with these error messages.

Mar 26 09:00:08.100 DEBUG tendermint_abci::application: Incoming request: Request { value: Some(Flush(RequestF
lush)) }
Mar 26 09:00:08.102 DEBUG tendermint_abci::application: Incoming request: Request { value: Some(InitChain(Requ
estInitChain { time: Some(Timestamp { seconds: 1648285161, nanos: 213154796 }), chain_id: "test-chain-FYTv7I",
consensus_params: Some(ConsensusParams { block: Some(BlockParams { max_bytes: 22020096, max_gas: -1 }), evide
nce: Some(EvidenceParams { max_age_num_blocks: 100000, max_age_duration: Some(Duration { seconds: 172800, nano
s: 0 }), max_bytes: 1048576 }), validator: Some(ValidatorParams { pub_key_types: ["ed25519"] }), version: None
}), validators: [ValidatorUpdate { pub_key: Some(PublicKey { sum: Some(Ed25519([139, 224, 140, 155, 35, 172,
242, 164, 111, 217, 124, 21, 50, 140, 31, 52, 86, 81, 28, 30, 1, 25, 89, 13, 121, 221, 206, 104, 47, 2, 154, 1
79])) }), power: 10 }], app_state_bytes: [], initial_height: 1 })) } Mar 26 09:00:08.103 DEBUG tendermint_basecoin::app: Got init chain request.
thread '' panicked at 'genesis state isn't valid JSON: Error("EOF while parsing a value", line: 1, co
lumn: 0)', src/app/mod.rs:150:10

Add acknowledgement relaying to CI tests

Our CI currently tests 2 things:

1. that we can open a channel
2. that we can send a token

(2) should additionally ensure that hermes is able to relay the acknowledgement back to the sending chain (which would catch issues such as this one)

ibc-rs integration requirements

This is an attempt to identify all ibc-rs issues that are required/relevant for a complete implementation of the various phases of the basecoin application as described in informalsystems/hermes#1.

Phase 3

• https://github.com/informalsystems/ibc-rs/issues/838
• https://github.com/informalsystems/ibc-rs/issues/1194
• https://github.com/informalsystems/ibc-rs/issues/102
• informalsystems/hermes#288
• informalsystems/hermes#722
• https://github.com/informalsystems/ibc-rs/issues/745

Phase 4

• informalsystems/hermes#1389
• https://github.com/informalsystems/ibc-rs/issues/1214
• https://github.com/informalsystems/ibc-rs/issues/726
• https://github.com/informalsystems/ibc-rs/issues/1561
• https://github.com/informalsystems/ibc-rs/issues/1532

Phase 5

• https://github.com/informalsystems/ibc-rs/issues/1745
• https://github.com/informalsystems/ibc-rs/issues/1696

Phase 6

• https://github.com/informalsystems/ibc-rs/issues/1758
• https://github.com/informalsystems/ibc-rs/issues/1759
• https://github.com/informalsystems/ibc-rs/issues/1696

Inter-module communication

Modules currently own their ModuleStores and are guaranteed exclusive (write-)access to them. But a module may depend on the services of another module. Such a service is usually providing some sort of validation and reading from or writing to the ModuleStore. We need a mechanism through which a module can define how other modules can interact with it and use its services.
This is a proposal for one such system of interfaces to enable inter-module communication heavily inspired by the Cosmos SDK's Keepers concept.

Module design

A module must define the following -

• A base type that owns the Store instance and optionally implements the Module trait.

pub struct Auth<S> {
    store: SharedStore<S>,
}

• Reader traits that provide read-only access to certain Paths in the ModuleStore. Modules may define multiple Reader traits depending on the granularity of access control required.

pub trait AccountReader {
    type Error;
    type Address;
    type Account: Account;

    fn get_account(&self, address: Self::Address) -> Result<Self::Account, Self::Error>;
}

• Keeper traits that provide write access to certain Paths in the ModuleStore.

pub trait AccountKeeper {
    type Error;
    type Account: Account;

    fn set_account(&mut self, account: Self::Account) -> Result<(), Self::Error>;

    fn remove_account(&mut self, account: Self::Account) -> Result<(), Self::Error>;
}

• Types that implement the Readers and Keepers that the module wants to expose. Ideally, these types are composed out of TypedStores so they only have access to specific store Paths.

pub struct AuthAccountReader<S> {
    account_store: ProtobufStore<SharedStore<S>, AccountsPath, AuthAccount, BaseAccount>,
}

impl<S: Store> AccountReader for AuthAccountReader<S> {
    type Error = ();
    type Address = AccountId;
    type Account = AuthAccount;

    fn get_account(&self, address: Self::Address) -> Result<Self::Account, Self::Error> {
        self.account_store
            .get(Height::Pending, &AccountsPath(address))
            .ok_or(())
    }
}

• Types that implement the gRPC query server. (this is optional)

pub struct AuthQuery<S> {
    account_reader: AuthAccountReader<S>,
}

• Public API to instantiate Readers & Keepers.

impl<S: 'static + ProvableStore> Auth<S> {
    pub fn new(store: SharedStore<S>) -> Self {
        Self { store }
    }

    pub fn query(&self) -> QueryServer<AuthQuery<S>> {
        QueryServer::new(AuthQuery {
            account_reader: self.account_reader(),
        })
    }

    pub fn account_reader(&self) -> AuthAccountReader<S> {
        AuthAccountReader {
            account_store: TypedStore::new(self.store.clone()),
        }
    }

    pub fn account_keeper(&self) -> AuthAccountKeeper<S> {
        AuthAccountKeeper {
            account_store: TypedStore::new(self.store.clone()),
        }
    }
}

Dependent modules

Modules that depend on other modules must provide a ctor that indicates this dependency and must not be constructible in any other way.

pub struct Bank<S, AR, AK> {
    store: SharedStore<S>,
    account_reader: AR,
    account_keeper: AK,
    // ...
}

impl<S: ProvableStore + Default, AR: AccountReader, AK: AccountKeeper> Bank<S, AR, AK> {
    pub fn new(store: SharedStore<S>, account_reader: AR, account_keeper: AK) -> Self {
        Self {
            store: store.clone(),
            account_reader,
            account_keeper,
            // ...
        }
    }
}

App initialization

// instantiate the application with a KV store implementation of choice
let app = BaseCoinApp::new(InMemoryStore::default()).expect("Failed to init app");

// instantiate modules and setup inter-module communication (if required)
let auth = Auth::new(app.module_store(&prefix::Auth {}.identifier()));
let bank = Bank::new(
    app.module_store(&prefix::Bank {}.identifier()),
    auth.account_reader(),
    auth.account_keeper(),
);
let ibc = Ibc::new(app.module_store(&prefix::Ibc {}.identifier()));
let staking = Staking::new(app.module_store(&prefix::Staking {}.identifier()));

// register modules with the app
let app = app
    .add_module(prefix::Bank {}.identifier(), bank)
    .add_module(prefix::Bank {}.identifier(), ibc.clone());

// run the blocking ABCI server on a separate thread
let server = ServerBuilder::new(opt.read_buf_size)
    .bind(format!("{}:{}", opt.host, opt.port), app.clone())
    .unwrap();
std::thread::spawn(move || {
    server.listen().unwrap();
});

// run the gRPC server
let grpc_server = Server::builder()
    .add_service(auth.query())
    .add_service(staking.query())
    // ...
    .serve(format!("{}:{}", opt.host, opt.grpc_port).parse().unwrap());
Runtime::new()
    .unwrap()
    .block_on(async { grpc_server.await.unwrap() });

Implement basic gas metering

• Define a new wrapper store type MeteredStore<S> that intercepts store ops and calculates gas costs.
• Copy Cosmos SDK's meter values -> https://github.com/cosmos/cosmos-sdk/blob/master/store/types/gas.go#L219

Refactor and separate lib from bin

Description

As we're trying to evaluate the UX of ibc-rs modules from a customer's perspective, it would make sense to separate the basecoin-rs app binary from the framework code. Another benefit of doing things this way would be that this project will serve as a reference implementation for other framework authors for integrating with ibc-rs modules.
This would mean that the library would be an ABCI framework for IBC enabled chains with the ability to choose which library-provided module (such as ibc, bank, etc.) to enable/include and add user-defined modules.

Acceptance criteria

The project is structured as a workspace with 2 crates - the framework and the app binary.

Add staking module

Description

Add a staking module that implements the cosmos::staking::v1beta1::query_server::Query gRPC service.

ICS20 module requirements

We're essentially looking for answers to these questions ->

• Is the ibc-rs ICS20 API readily usable?
  • eg. Router, app module?
• Are we missing any gRPC endpoints?
• What changes are required to the bank module?
• Can we make progress here before ICS20 is delivered on ibc-rs side?

Enable IBC client upgradability by featuring minimal governance & upgrade modules

Background

As of now, basecoin cannot process cometbft gov transactions, and hence cannot handle a client upgrade proposal.
Other comet-based chains can upgrade their clients on basecoin-rs, but basecoin is not capable of upgrading itself.
For this to happen, we need to add a minimal governance module.

As a result of cosmos/ibc-rs#420

Maybe enable working on cometbft v0.37.0

Main store proof key is hardcoded as ibc

We must return the module's prefix here as the key instead of hard-coding ibc. To fix this, we need a mechanism to extract a module's identifier from a Module (or more specifically from a ModuleStore).

Get config from config file

Description

There are a lot of params (eg. consensus params, etc.) that need to be user-configurable. e.g.

StakingQueryParamsResponse {
    params: Some(Params {
        unbonding_time: Some(Duration {
            seconds: 3 * 7 * 24 * 60 * 60,
            nanos: 0,
        }),
        max_validators: 0,
        max_entries: 0,
        historical_entries: 0,
        bond_denom: "".to_string(),
    }),
}

We could also move other CLI options to the config file. And allow for them to be overridden by the CLI.

Acceptance criteria

App is able to parse and validate config file.

Architecture Diagrams

Signatures aren't being verified

Basecoin doesn't verify signatures currently and we need to fix this as part of phase-8.

Rework `Key` vs `Path` nomenclature in the `Store` domain

Currently, in the context of Stores, we use Path and we use Key (here, K was chosen as a short for Key) both the signify the key to a value in the Store.

We either stick with one or the other, or clearly delineate where one should be used instead of the other (e.g. @hu55a1n1 suggested that key should be used at lower levels of abstraction as Path).

`hermes create channel ibc-0 basecoin-0 --port-a transfer --port-b transfer` fails

basecoin chain fails in ConnectionOpenTry part of the handshake:

IBC module error

Caused by:
ICS03 connection error

Caused by:
0: error verifying connnection state
1: tendermint error
2: ics23 commitment error
3: proof verification failed

backtrace:

thread '<unnamed>' panicked at 'not implemented: RevertibleStore doesn't support delete operations yet!', src/app/store/mod.rs:360:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
   2: <tendermint_basecoin::app::store::RevertibleStore<S> as tendermint_basecoin::app::store::Store>::delete
             at ./src/app/store/mod.rs:360:9
   3: <tendermint_basecoin::app::store::RevertibleStore<S> as tendermint_basecoin::app::store::Store>::reset
             at ./src/app/store/mod.rs:385:43
   4: <tendermint_basecoin::app::store::SharedStore<S> as tendermint_basecoin::app::store::Store>::reset
             at ./src/app/store/mod.rs:255:9
   5: <tendermint_basecoin::app::BaseCoinApp<S> as tendermint_abci::application::Application>::deliver_tx
             at ./src/app/mod.rs:259:25
   6: <A as tendermint_abci::application::RequestDispatcher>::handle
             at /Users/plafer/.cargo/registry/src/github.com-1ecc6299db9ec823/tendermint-abci-0.23.5/src/application.rs:132:69
   7: tendermint_abci::server::Server<App>::handle_client
             at /Users/plafer/.cargo/registry/src/github.com-1ecc6299db9ec823/tendermint-abci-0.23.5/src/server.rs:114:28
   8: tendermint_abci::server::Server<App>::spawn_client_handler::{{closure}}
             at /Users/plafer/.cargo/registry/src/github.com-1ecc6299db9ec823/tendermint-abci-0.23.5/src/server.rs:91:39

To reproduce

1. Set up basecoin chain & gaiad chain as indicated in README.md
2. run hermes create channel ibc-0 basecoin-0 --port-a transfer --port-b transfer

Investigate having the `Store` store rust types for well-known paths

Currently the Store stores objects of type Vec<u8>. This forces us to serialize/deserialize Rust types before putting them in a Store.

We should investigate supporting storing predefined Rust types for well-known paths, avoiding the serialization/deserialization cost.

Related: #40

Typed stores

With the current store implementation, users can write arbitrary data to any path. This can be problematic because we know that some paths are only meant to store a certain type of data. For example -> paths of the form "clients/{identifier}/clientState" will always store ClientState. Here are some properties that would be nice to have ->

• Enforce this at the type level
• Disallow creation of multiple stores that point to the same path
• Provide a way for users to define the (de)serialization at the type level.

ci: Bake Hermes binary into integration test

From #35 (comment), we should, by default, bake in a specific version of Hermes in the CI Docker image by using the layering approach employed in #35.

We should still offer the option, however, to override this baked-in Hermes binary with one built from ibc-rs sources.

Reuse ibc-proto's generated server code

informalsystems/hermes#2278 adds the server feature to enable server code generation in the ibc-proto crate. This will allow us to reuse ibc-proto code and we will no longer have to maintain the prostgen code ourselves separately in basecoin.

Rough Project Plan

Goal

Objective: Fully complete IBC handlers in rust that can easily be integrated into any Rust blockchain framework, including Orga, Penumbra, Anoma, Substrate, Near, Solana, etc.

Major Milestone: simple ABCI app ("basecoin") that supports IBC token transfer. We want to be able to run two instances of this chain and use hermes to transfer tokens between them.

Future major milestones include having our IBC handlers connect to the Cosmos Hub, having a more robust "baseapp" framework (whether Orga or something else), and integrating smart contracting languages like CosmWasm or even Makina

Draft Plan

Here's a draft plan broken into phases.

Phases 0-2: simplest ABCI app possible to be able to support IBC

• Phase 0: dummy basecoin

  • in memory state map: account address (string) -> balance (int)
  • single tx type json encoded with three fields: sender, receiver, amount

• Phase 1: Same as Phase 0 but with protobuf based txs using Cosmos SDK Tx structure

  • use the Cosmos-SDK tx/v1beta1/tx.proto message Tx, but ignore all auth/signatures (just get the Msg out)
  • use the bank/v1beta1/tx.proto MsgSend to get the from/to/amount
  • use the same in memory state map as Phase 0
  • should be able to use gaiad tx bank send --offline whatever to send txs

• Phase 2: Add support for multiple coins

  • state map is now map [ address (string) -> map[ denom (string) -> amount (int) ] ]
  • everything else should be the same !

---

Phases 3-6: IBC integration into the ABCI app

• Phase 3: Add support for IBC CreateClient and UpdateClient msgs
  • complete/import the ics02/ics07 machinery from ibc-rs
  • state will now need to be able to store clients (may need more generic state mechanism ? )
  • allow sending MsgCreateClient to create client on the chain and MsgUpdateClient to update it with latest headers
  • should be able to use hermes tx raw create/update-client and/or gaiad tx ibc ...
  • should be able to run two chains, manually create a client on each, and manually update them

NOTE: at some point we need to add GRPC support to get hermes working properly and not have to do commands manually - probably should do this sooner than later.

• Phase 4: Add support for IBC Connection machinery

  • complete/import the ics03 machinery from ibc-rs
  • state will now need to be able to store connection ends
  • should now be able to manually complete connection handshake between two chains

• Phase 5: Add support IBC Channel machinery

  • complete/import the ics04 machinery from ibc-rs
  • state will now need to be able to store channel ends and packet data
  • should now be able to manually complete channel handshakes between two chains and send packets

• Phase 6: Add support for IBC Token Transfer

  • complete/import the ics20 machinery from ibc-rs
  • should now be able to transfer tokens from one chain to the other

TADA!

---

• Phase 7: Get it working with the Cosmos Hub ....

• Phase 8: use a real app framework and make everything secure ...

OPEN QUESTION:

• what parts of ibc-rs are still incomplete and need to be filled in to get this working?
• are there parts we can still punt on ? eg. merkle tree verification
• what do we need the state to look like to make this work ?
• what do we need to expose to enable hermes to run against these two chains and do everything automatically (ie. grpc ? )

Partial reads due to lacking rollback atomicity

This is a subtle bug in our RevertibleStore impl that may result in partial reads. The problem is that the current RevertibleStore's apply() impl is essentially a no-op (just clears the log) while the reset() is actually applying the revert operations and this is not done atomically (it is done in a MT-safe manner but not atomically). That means that the gRPC query endpoints will be able to access the store mid-way through a rollback and see inconsistent data.

Exception safety guarantees

basecoin-rs doesn't provide any exception safety guarantees as of now. The reason for this is that we only provide a volatile in-memory data store currently. But this is definitely something we should address.

Proposal

One way to provide strong guarantees and the ability to recover from crash failures would be to record pending data-store changes on failure. This can be done in a couple of ways ->

• std::panic::set_hook() and panic_any!() to pass the app state to the panic handler and printing pending writes from the RevertibleStore.
• Using RevertibleStore's Drop to write the pending writes to stderr.

Make `app` module more maintainable by reorganizing the code

Summary

By doing so and breaking down different ABCI implementations, we can make it easier to manage and update the app in the future

Document proto update procedure

• How should the SDK and IBC proto versions be determined?
• Changes that need to be made to ibc-rs's proto-compiler.
• Patching prost generated files.

Move all `impl` block for `Path` into the same file

Currently, From and TryFrom implementations for app::store::Path are found in multiple files (ibc.rs, auth.rs, etc).

All these should be moved in src/app/store/mod.rs next to the definition of Path, as it makes it easier to know how Path can be used by having all its trait implementations in one place.

Current `Store` API prevents us from properly upgrading to the upcoming ibc v0.20.0

The current Store API only allows us to set serialized values.

This is incompatible with the upcoming ibc v0.20.0 which implemented ADR 4. Specifically, we would like to store Box<dyn ClientState> for the client_state_store, and Box<dyn ConsensusState> for the consensus_state_store. We can't store the serialized version, because we don't know how to transform Vec<u8> -> Box<dyn ClientState> without additional information (e.g. the ClientId).

One solution is to create an enum of all types stored in the IBC store (Sequence, PacketCommitment, Box<dyn ClientState>, etc), and have that enum be the type of the value for the IBC store. Proofs will work just fine as well; we just need to ensure that the values in the store are properly serialized before they're fed to the proof algorithm, which I believe is already the case (here and here for example).

hermes cannot parse basecoin's config

hermes fails with the following error when trying to parse basecoin's config ->

$ hermes -c ./config.toml config validate
The Hermes configuration file at path './config.toml' is invalid, reason: parse error: invalid type: sequence, expected a string at line 8 column 16 for key `chains.proof_specs` at line 255 column 15
Please see the example configuration for detailed information about the supported configuration options: https://github.com/informalsystems/ibc-rs/blob/master/config.toml

The last hermes version known to work with basecoin is v0.13.0-rc.0.

ci: Implement ibc-test-framework-based integration test for basecoin-rs

We want to eventually upgrade the current integration tests in CI to make use of ibc-test-framework for integration testing as opposed to our current BASH script-based approach.

Acceptance Criteria

When we have an integration test in CI that makes use of ibc-test-framework instead of the current BASH script-based approach. This must test at least one kind of meaningful set of functionality, like ft-transfer, between a gaiad chain and a basecoin-rs chain.

error[E0034]: multiple applicable items in scope

When running cargo build i encountered an error:

error[E0034]: multiple applicable items in scope
   --> /home/ai/.cargo/registry/src/github.com-1ecc6299db9ec823/prost-derive-0.7.0/src/lib.rs:109:14
    |
109 |             .intersperse(quote!(|));
    |              ^^^^^^^^^^^ multiple `intersperse` found
    |
    = note: candidate #1 is defined in an impl of the trait `Iterator` for the type `Map<I, F>`
    = note: candidate #2 is defined in an impl of the trait `Itertools` for the type `T`
help: disambiguate the associated function for candidate #1
    |
105 ~         let tags = Iterator::intersperse(field
106 +             .tags()
107 +             .into_iter()
108 +             .map(|tag| quote!(#tag)), {
109 +         let mut _s = $crate::__private::TokenStream::new();
110 +         $crate::quote_each_token!(_s $($tt)*);
  ...
help: disambiguate the associated function for candidate #2
    |
105 ~         let tags = Itertools::intersperse(field
106 +             .tags()
107 +             .into_iter()
108 +             .map(|tag| quote!(#tag)), {
109 +         let mut _s = $crate::__private::TokenStream::new();
110 +         $crate::quote_each_token!(_s $($tt)*);
  ...

rustc 1.57.0-nightly (0eabf25b9 2021-10-06)

Upgrade basecoin-rs to use ibc-rs's `val_exec_ctx` feature

Following #72, we should now upgrade basecoin-rs to use the new ValidationContext and ExecutionContext API that's behind the val_exec_ctx feature.

Enforce unique module identifiers

• Module identifiers must be valid ICS024 Identifiers.
• Module identifiers must be unique.
• Validate preferably at build time.
• Might be nice to have a derive macro for generating the Identifiable trait definitions for module objects (using just the struct name in snake_case as identifier).

Release a docker image with every release

As requested by @crodriguezvega, we should release docker images of basecoin so that ibc-go can add end-to-end tests with ibc-rs.

Ensure `hermes clear packets` works with basecoin

Add auth module

Description

• Add an auth module that implements the cosmos::auth::v1beta1::query_server::Query::account gRPC service.
• Extract account related code from bank module and move it to the auth module.
• Model accounts after BaseAccount, eg. add sequence number.
• Design storage paths. (Ethereum style?)

Account sequence isn't incremented on `deliverTx`

basecoin currently doesn't increment account sequences on deliverTx. We need to fix this to be able to integrate with Hermes.

Investigate: `Module::init()` should be type-safe

Currently, Module::init() takes a json object as input. We should investigate how to make this type-safe.

A rough sketch for a possibility would be:

trait Module {
    type InitData;

    fn init(&mut self, init_data: Self::InitData);
}

`Path` and `Identifier` validation and improvements

Description

• We must also define concretely what an Identifier is and validate it in accordance with ICS024.
• Path should ideally be a trait. Must provide methods for splitting into component Identifiers, append, etc.
• Replace basecoin-rs/src/app/store.rs:Identifier::is_valid() with ibc-rs/modules/src/ics24_host/validate.rs:validate_identifier().
• Reuse ibc-rs/modules/src/ics24_host/identifier.rs:{ChainId, ClientId, *} in basecoin-rs/src/app/modules/ibc.rs.
• Deserialize paths into concrete ibc-rs/modules/src/ics24_host/path.rs:29.
• Does it make sense to use const-generics? e.g.

pub struct Identifier<const N: usize>([char; N]);

CI and tests

• Import tests from phase2 for bank module
• Add integration tests - basecoin <> basecoin and basecoin <> gaiad
• Add unit tests for other modules and framework
• Import Tendermock tests for storage

Make `basecoin-rs` compatible with `ibc-rs` changes until v0.29.0

Summary

It is needed to reflect on the below changes for getting the basecoin-rs compatible with the IBC-rs v0.29.0:

• Discard the old reader/keeper traits and go only with the Validation/Execution APIs without the val_exec_ctx feature
• Apply changes due to refactoring *Path structs on IBC-rs
• Update the Tendermint-rs deps to v0.29.0
• Bump IBC-rs and IBC-proto-rs

Private store for modules isn't immutable

• Modules' private stores must be immutable.
• Private stores must also provide a reset/apply style API.
• Private stores must be reset when message delivery fails.

Reorganize repo as a lib with a `cli` bin

Summary

Having the crate reorganized as a lib with a cli bin to improve the usability and user-exp of the project

Reference: #69 (review)

Is there a more detailed local boot tutorial？

Run failed

tendermint v0.34.10, macOS
basecoin-rs output:

Oct 26 12:16:22.587  INFO tendermint_abci::server: Listening for incoming requests from 127.0.0.1:60438
Oct 26 12:16:22.662 ERROR tendermint_abci::server: Failed to read incoming request from client 127.0.0.1:60435: error encoding protocol buffer

Caused by:
    failed to decode Protobuf message: Request.value: buffer underflow

tendermint output:

I[2022-10-26|12:16:22.662] service start                                module=txindex msg="Starting IndexerService service" impl=IndexerService
E[2022-10-26|12:16:22.663] Stopping abci.socketClient for error: read message: EOF module=abci-client connection=query
I[2022-10-26|12:16:22.663] service stop                                 module=abci-client connection=query msg="Stopping socketClient service" impl=socketClient
E[2022-10-26|12:16:22.663] query connection terminated. Did the application crash? Please restart tendermint module=proxy err="read message: EOF"
ERROR: failed to create node: error during handshake: error calling Info: read message: EOF
[1]    11522 terminated  tendermint node

Add build.rs script

Description

• This would be useful for getting data related to GetNodeInfoResponse.
• Might be useful to generate protos based on config?

Add cargo features for modules

Description

Add features to enable conditional compilation for modules (eg. auth, staking, ibc, bank). This would allow apps using the framework to choose which modules to enable/install. In the future, there could be multiple implementations of the same module.

Acceptance criteria

Every module must have an associated feature and dependencies should be handled properly. Users must be able to opt-in to their modules of choice.

`ValidationContext::validate_self_client()` should have an implementation

Here. We only need to use the implementation in ibc-rs.