Open mzabaluev opened 5 months ago
From a discussion on Slack, the best quick course of action is to bring all dependencies to Tendermint/CometBFT 0.38. But in case of ICS, it is blocked on https://github.com/cosmos/interchain-security/issues/1246.
https://github.com/cosmos/ibc-proto-rs/pull/190/commits/5bb2b45a0bb94398acd0ac0ca2553a7b0aae60bf (in #190) brings the cosmos-sdk checkout up to v0.50.4. In terms of the tendermint version, this gets the includes up to 0.38.
We're in luck with interchain-security: it uses tendermint.crypto.PublicKey
, tendermint.abci.Validator
, and tendermint.abci.ValidatorUpdate
, the definitions of which have not changed since 0.34. So we are able to hold up this house of cards for now.
The upstream proto revisions as currently pulled to build ibc-proto-rs are not consistent as per the revisions of
tendermint
files they expect to import:However, by the way the build process is set up in sync-protobuf.sh, all of these inputs to proto-compiler actually end up including the
tendermint/*
protobuf files found in the cosmos-sdk buf export (the proto-include directory). Which means ouribc::
generated types for this set of upstream revisions do not necessarily interoperate with the Go types generated in ibc-go as per the targeted commit.The proper way out of this mess is to convert the upstreams to produce buf modules and reuse buf.build/cometbft/cometbft as a common dependency. Then the build process in ibc-proto-rs could consume the buf modules to generate Rust bindings for them.
Meanwhile, it's possible to juggle the
src/*_COMMIT
files in ibc-proto-rs to arrive at a combination of proto upstreams that happens to use the same revision of thetendermint
protos, and then do theextern_path
trick on that. But it's a high-quality balancing act that needs developer's time and care. Which is precisely whatbuf
is meant to get rid of.Originally posted by @mzabaluev in https://github.com/cosmos/ibc-rs/issues/1073#issuecomment-1934724440