hyperlane-monorepo

The home for Hyperlane core contracts, sdk packages, and other infrastructure

blockchain hyperlane interchain monorepo

History

Trevor Porter 0cad4f7407 Support cosmos contract byte lengths other than 32 (#3147 ) ### Description fixes #3143 Initially went down a path that would use protocol-specific types for addresses as suggested by #3143. I had made a `HyperlaneConnectionConf` enum with protocol-specific variants whose values were `addresses: CoreContractAddresses<ProtocolSpecificAddressType>` and `connection: ProtocolSpecificConnectionConf`. This worked pretty well until I hit the ISM logic. Because hyperlane-core is where the Mailbox trait is defined, the return type of `recipient_ism` in the trait cannot involve protocol specific types. It can't be moved to hyperlane-base because hyperlane-base imports the chain crates, so we'd have a cyclic dependency. I experimented with moving away from H256 to something like a Vec<u8> or string, but this felt a bit weird. In the end we decided to keep H256s as the global representation for contract addresses for now, with the intent of eventually changing this, and to support the varying length situation in a cosmos config ### Drive-by changes - Added some cosmos specific agent configurations into the sdk - Moved to bech32_prefix in the agents for consistency with what the SDK's chain metadata already does - I guess no one's ran cargo test in a while so vectors/message.json got a new v3 message lol ### Related issues Fixes #3143 ### Backward compatibility Changes prefix to bech32_prefix in the agent config, and now requires `contractAddressBytes` ### Testing Tested merged with #3144 and all worked --------- Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>	11 months ago
..
src	Support cosmos contract byte lengths other than 32 (#3147 )	11 months ago
Cargo.toml	Injective-specific account info protobuf (#3144 )	11 months ago

Support cosmos contract byte lengths other than 32 (#3147 )

### Description

fixes #3143 

Initially went down a path that would use protocol-specific types for
addresses as suggested by #3143. I had made a `HyperlaneConnectionConf`
enum with protocol-specific variants whose values were `addresses:
CoreContractAddresses<ProtocolSpecificAddressType>` and `connection:
ProtocolSpecificConnectionConf`. This worked pretty well until I hit the
ISM logic.

Because hyperlane-core is where the Mailbox trait is defined, the return
type of `recipient_ism` in the trait cannot involve protocol specific
types. It can't be moved to hyperlane-base because hyperlane-base
imports the chain crates, so we'd have a cyclic dependency. I
experimented with moving away from H256 to something like a Vec<u8> or
string, but this felt a bit weird.

In the end we decided to keep H256s as the global representation for
contract addresses for now, with the intent of eventually changing this,
and to support the varying length situation in a cosmos config

### Drive-by changes

- Added some cosmos specific agent configurations into the sdk
- Moved to bech32_prefix in the agents for consistency with what the
SDK's chain metadata already does
- I guess no one's ran cargo test in a while so vectors/message.json got
a new v3 message lol

### Related issues

Fixes #3143 

### Backward compatibility

Changes prefix to bech32_prefix in the agent config, and now requires
`contractAddressBytes`

### Testing

Tested merged with #3144 and all worked

---------

Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>

11 months ago

src

Support cosmos contract byte lengths other than 32 (#3147 )

11 months ago

Cargo.toml

Injective-specific account info protobuf (#3144 )

11 months ago