Investigate removing the dependency on `tendermint-rs`

[plafer]

Ideally, we wouldn't need to depend on tendermint-rs, as tendermint is only one of many possible host consensus protocols. Non-tendermint hosts who don't plan on interacting with tendermint chains shouldn't need to pull in the tendermint-rs crates.

The main areas we use tendermint are

1. tests
   • Note that we can keep depending on tendermint-rs in dev-dependencies.
2. events
   • We implement a conversion to ABCI events
3. time
   • Our Timestamp internally uses tendermint's notion of time
4. Host helpers
5. the Tendermint light client

Removing our dependency on tendermint would also make downstream users' life easier.

[erwanor]

Originally posted in #444, re-posting here since this is relevant :)

Re: tendermint-rs, it might be good to have lower coupling mid/long-term, but speaking for penumbra and probably a few others (looking around namada, and orga for examples) we would always have that feature on anyway (e.g. for the ics07 client, among other things), so for us that doesn't make a huge difference either.

I don't know if there's another way to work around breaking changes happening across the crate tree, but cutting frequent granular releases, in particular following a tendermint-rs release, would help us both with velocity and reducing the lift of upgrading, at least some of the time, rather than making dealing with breaking changes in both ibc-rs and tendermint-rs the default.

I've opened https://github.com/cosmos/ibc-rs/issues/463 and https://github.com/cosmos/ibc-rs/pull/462 which brings over CI improvements that @thanethomson worked on in tendermint-rs

[hdevalence]

Removing the dependency on tendermint-rs wouldn't make our life easier, because we'd still need to use the Tendermint light client to speak IBC to Tendermint chains. Although Tendermint is only one of many possible host consensus protocols, it is the only one actually deployed in practice.

A better way to make downstream users' lives easier would be to have more frequent, granular releases.

[plafer]

Reposting this comment here for better visibility:

I think the difference is that only this other crate would need to be upgraded quickly after tendermint-rs, and that would make it easier for ibc-rs, as we are not always ready to release whenever tendermint-rs releases.

So removing our dependency on tendermint-rs is one strategy to easily release simultaneously with tendermint-rs. In other words, we isolate our dependency on tendermint-rs in this other crate; which we only ever need to update when tendermint-rs releases. Or, ibc-rs will not need to make a release for tendermint-rs's new version to be fully propagated.

[thanethomson]

@plafer could you please elaborate in more detail as to how one would remove the dependency on tendermint-rs? It's not clear from the descriptions here.

[plafer]

Hmm, only now realizing I never actually described what I had in mind. The idea is to pull the light client (and our "host helpers") in a new crate (say ibc-tendermint), which would depend on ibc-rs. The one unresolved issue for me is the conversion to ABCI events.

In any case, assuming we figure that out the details, the dependency graph would look like:

     +-----------------------------------------+
     |                                         |
     |                                         |
     +                                         v
tendermint-rs+---->ibc-tendermint+------------>penumbra
                        ^                      ^
                        |                      |
ibc-rs+-----------------+----------------------+

Note that when tendermint-rs releases, we can easily release a new version of ibc-tendermint, without needing to release a new version of ibc-rs as well.

[DaviRain-Su]

Yet, This requires separating ICS07 Tendermint from the protocol.