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>pull/3180/head
parent
528a19022b
commit
0cad4f7407
@ -1 +1 @@ |
|||||||
[{"body":[18,52],"destination":2000,"id":"0x545b9ae16e93875efda786a09f3b78221d7f568f46a445fe4cd4a1e38096c576","nonce":0,"origin":1000,"recipient":"0x0000000000000000000000002222222222222222222222222222222222222222","sender":"0x0000000000000000000000001111111111111111111111111111111111111111","version":0}] |
[{"body":[18,52],"destination":2000,"id":"0xf8a66f8aadee751d842616fee0ed14a3ad6da1e13564920364ee0ad35a02703f","nonce":0,"origin":1000,"recipient":"0x0000000000000000000000002222222222222222222222222222222222222222","sender":"0x0000000000000000000000001111111111111111111111111111111111111111","version":3}] |
Loading…
Reference in new issue