The home for Hyperlane core contracts, sdk packages, and other infrastructure
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
hyperlane-monorepo/solidity/test/message.test.ts

92 lines
2.7 KiB

import { expect } from 'chai';
import { utils } from 'ethers';
import {
addressToBytes32,
formatMessage,
messageId,
} from '@hyperlane-xyz/utils';
import testCases from '../../vectors/message.json' assert { type: 'json' };
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>
9 months ago
import { Mailbox__factory, TestMessage, TestMessage__factory } from '../types';
import { getSigner, getSigners } from './signer';
const remoteDomain = 1000;
const localDomain = 2000;
const nonce = 11;
describe('Message', async () => {
let messageLib: TestMessage;
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>
9 months ago
let version: number;
before(async () => {
const signer = await getSigner();
const Message = new TestMessage__factory(signer);
messageLib = await Message.deploy();
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>
9 months ago
// For consistency with the Mailbox version
const Mailbox = new Mailbox__factory(signer);
const mailbox = await Mailbox.deploy(localDomain);
version = await mailbox.VERSION();
});
it('Returns fields from a message', async () => {
const [sender, recipient] = await getSigners();
const body = utils.formatBytes32String('message');
const message = formatMessage(
version,
nonce,
remoteDomain,
sender.address,
localDomain,
recipient.address,
body,
);
expect(await messageLib.version(message)).to.equal(version);
expect(await messageLib.nonce(message)).to.equal(nonce);
expect(await messageLib.origin(message)).to.equal(remoteDomain);
expect(await messageLib.sender(message)).to.equal(
addressToBytes32(sender.address),
);
expect(await messageLib.destination(message)).to.equal(localDomain);
expect(await messageLib.recipient(message)).to.equal(
addressToBytes32(recipient.address),
);
expect(await messageLib.recipientAddress(message)).to.equal(
recipient.address,
);
expect(await messageLib.body(message)).to.equal(body);
});
it('Matches Rust-output HyperlaneMessage and leaf', async () => {
for (const test of testCases) {
const { origin, sender, destination, recipient, body, nonce, id } = test;
const hexBody = utils.hexlify(body);
const hyperlaneMessage = formatMessage(
version,
nonce,
origin,
sender,
destination,
recipient,
hexBody,
);
expect(await messageLib.origin(hyperlaneMessage)).to.equal(origin);
expect(await messageLib.sender(hyperlaneMessage)).to.equal(sender);
expect(await messageLib.destination(hyperlaneMessage)).to.equal(
destination,
);
expect(await messageLib.recipient(hyperlaneMessage)).to.equal(recipient);
expect(await messageLib.body(hyperlaneMessage)).to.equal(hexBody);
expect(messageId(hyperlaneMessage)).to.equal(id);
}
});
});