Message Contract
In a cross-chain bridge, the message contract (Messager) plays a very important role. It is mainly responsible for encoding, decoding, verifying, and sending cross-chain messages. Developers only need to focus on sending and consuming messages; other aspects such as replay protection and message authenticity verification are all ensured by the message contract.
1. Send Message Contract Interface
1.1. In the Endless chain, the Message
sending interface is defined as follows:
Message
sending interface is defined as follows:1.1.1. Function Description
The send_message
function is used to send a cross-chain message within a Move contract. This function allows the user (sender
) to send a message to a specified target chain and address through an executor (executor
).
1.1.2. Parameter Description
sender: &signer
- a reference to the signature of the sender of the message, used to verify the sender's identity and permissions and to pay gas fees.executor: &signer
- a reference to the signature of the executor, used to perform additional permission checks.excutor_account: &address
-the account address of the executor, used to perform additional permission checks.mtype: u8
- the message type, represented as an 8-bit unsigned integer.to_chain: vector<u8>
- the identifier of the target chain, represented as a byte vector.to_addr: vector<u8>
- the target address, represented as a byte vector.mbody: vector<u8>
-the message body, containing the actual data to be sent, represented as a byte vector.fee: u128
- the fee required to send the message, represented as a 128-bit unsigned integer.
1.2. The messages and ABI sent on the sepolia, bsc, and nile chains are as follows:
1.2.1. Parameter Description
msg_type:message type
to_chain:target chain information
receiver:receiver address (target chain execution contract address)
body_message:message body (defined by the developer)
upload_gas_fee:target chain gas fee (can be estimated before cross-chain)
1.3. The method definition and IDL for sending messages on the solana chain are as follows:
1.3.1. Parameter Description
ctx: Context<SendToOtherChain> Context object, containing all information related to the current transaction, including the status and permissions of the account. This parameter is used to ensure that the function is executed in the correct context.
to_chain: Chain Enumeration type of the target chain, specifying the chain to which the message is to be sent. It can be different blockchain networks, such as Ethereum, Binance Smart Chain, etc.
to_addr: [u8; 32] Byte array of the target address, with a length of 32 bytes. This parameter is used to specify the receiving address of the message.
mbody: Vec<u8> Byte vector of the message body, containing the actual data to be sent. It can be any type of data, such as transaction information, instructions, etc.
mtype: u8 Byte of the message type, indicating the classification or format of the message. It can be used to distinguish different types of messages, such as notifications, instructions, etc.
upload_fee: u64 Unsigned 64-bit integer of the upload fee, indicating the fee required to send the message. This parameter is used to ensure that the sender has enough balance when sending the message.
2. Consumer message contract interface
2.1. In the Endless chain, the consumption message interface is defined as follows:
2.1.1. Function Description
confirm_message
is a public function used to confirm a message in a multisignature contract.
The primary purpose of this function is to ensure that only authorized executors can confirm specific messages, thereby enhancing the security and reliability of the contract.
2.1.2. Parameter Description
executor:A reference to the signer's account executing the function, representing the account authorized to confirm the message.
multisig:The address of the multisignature contract, indicating the contract where the message will be confirmed.
accum_pk:The aggregated public key, representing the cumulative public key used in the multisignature verification process.
msg_header:The message header, containing metadata about the message.
msg_body:The message body, containing the actual content or payload of the message.
2.2. Consumption of Messages on Sepolia, BSC, and Nile Chains — Definition and ABI:
2.2.1. Parameter Description
messageDec
:Type isTypes.Message
,containing the following structure:msg_header
:Message header, type isTypes.MessageHeader
msg_type
:Message type(uint8)nonce
:Message sequence number(uint64)from_chain
:Source chain information(Types.Chain)chain_type
:Chain type(uint8)chain_id
:Chain ID(uint64)
sender
:Sender address(bytes32)to_chain
:Target chain information(Types.Chain)chain_type
:Chain type(uint8)chain_id
:Chain ID(uint64)
receiver
:Receiver address(bytes32)upload_gas_fee
:pload gas fee(uint128)msg_body
:Message body(bytes)
signature
:Message signature array(bytes[])
2.3.The definition and IDL of the message consumption method on the Solana chain are as follows:
2.3.1. Parameter Description
ctx: Context<ConfirmFromOtherChain> Context object, containing all information related to the current transaction, including the status and permissions of the account. This parameter is used to ensure that the function is executed in the correct context.
msg_header: MsgHeader The structure of the message header, containing metadata about the message, such as the sender address, timestamp, message type, etc. This parameter is used to provide basic information about the message.
msg_body: Vec<u8> The byte vector of the message body, containing the actual data to be confirmed. It can be any type of data, such as transaction information, instructions, etc.
_accum_pk: Vec<u8> The byte vector of the accumulated public key, which is usually used to verify the signature of the message. This parameter can contain multiple public keys to ensure the legitimacy of the message.
signatures: Vec<[u8; 65]> The byte array vector of the signature, with a length of 65 bytes. This parameter is used to store the signature of the message to verify the source and integrity of the message.
Last updated