-
Notifications
You must be signed in to change notification settings - Fork 140
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: Inbound Transaction Verification (#785)
* doc: added callout to axelar dest chain gmp msg * doc: add gmp verification tx docs * doc: added link to video for validateContractCall * chore: added reference to cosmos gmp doc, reworded based on team feedback * chore: rephrased integrations to axelar are set TO connections to Axleaxelar are initiated via gateway
- Loading branch information
1 parent
dc429a8
commit b46aecd
Showing
3 changed files
with
54 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
# GMP Message Verification | ||
|
||
Axelar enables messages to be sent between two different blockchains. When a message is sent from a source chain to a destination chain, Axelar verifies that the incoming message on the destination chain is the authentic message that was sent on the source chain, having passed through the Axelar blockchain and confirmed by Axelar's validators. | ||
|
||
## Ethereum Virtual Machine (EVM) | ||
|
||
On EVM based chains such as Ethereum or Avalanche, connections to Axelar are initiated via the [Gateway Contract](https://github.com/axelarnetwork/axelar-cgp-solidity/blob/main/contracts/AxelarGateway.sol). The Gateway is used on both the source and the destination chain. On the source chain it is used to trigger the interchain transaction, on the destination chain it is triggered by the [Axelar Executable](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/contracts/executable/AxelarExecutable.sol) to [validate](https://github.com/axelarnetwork/axelar-cgp-solidity/blob/2023fadee722c3896f1071c2a9d578436643c5a7/contracts/AxelarGateway.sol#L233) an incoming GMP message. | ||
|
||
#### Validate Contract Call | ||
The `validateContractCall()` function is called on every inbound GMP message to ensure that the incoming message is authentic. This function receives the relevant parameters of a GMP call including; | ||
1. `CommandId`: A unique id for interchain messages | ||
2. `SourceChain`: The source chain of the GMP message | ||
3. `SourceAddress`: The source address of the contract call | ||
4. `PayloadHash`: A hash of the GMP message that was sent with the call | ||
|
||
Using this information it confirms that the inbound call has indeed been verified by the Axelar network and that this data is the authentic data passed in from the source chain rather than a malicious execution with invalid data on the destination chain. | ||
|
||
Once this function has been called the transaction is marked as _Executed_ on the destination chain to avoid double execution. | ||
|
||
Please watch [here](https://www.youtube.com/watch?v=qF9cVhcD2CY) for more information on validating incoming messages. | ||
|
||
## Cosmos | ||
|
||
On Cosmos, [validation](/dev/cosmos-gmp#establishing-a-path-of-trust) is conducted on Axelar before calling a destination contract. | ||
|
||
### Evm -> Cosmos | ||
|
||
For messages coming from [EVM to Cosmos](https://github.com/axelarnetwork/evm-cosmos-gmp-sample/tree/main/cosmwasm-integration#authenticate-the-sender), Axelar users a unique sender to handle communication `axelar1dv4u5k73pzqrxlzujxg3qp8kvc3pje7jtdvu72npnt5zhq05ejcsn5qme5`. Then on the destination chain itself Axelar derives a unique caller to execute the transaction. On your contract you simply must ensure that the address triggering the transaction is the unique Axelar address to know that this is the authentic call coming from the Axelar network. The Axelar account is derived via the `DeriveIntermediateSender` sender function. | ||
|
||
``` | ||
func DeriveIntermediateSender(channel, originalSender, bech32Prefix string) (string, error) { | ||
senderStr := fmt.Sprintf("%s/%s", channel, originalSender) | ||
senderHash32 := address.Hash(types.SenderPrefix, []byte(senderStr)) | ||
sender := sdk.AccAddress(senderHash32[:]) | ||
return sdk.Bech32ifyAddressBytes(bech32Prefix, sender) | ||
} | ||
``` | ||
|
||
For the Neutron blockchain for example to derive the Axelar account you pass in `channel-2`, `axelar1dv4u5k73pzqrxlzujxg3qp8kvc3pje7jtdvu72npnt5zhq05ejcsn5qme5` , `neutron` to the `DeriveIntermediateSender` function. | ||
|
||
### IBC Hooks | ||
|
||
If you’re using [IBC hooks (iirc)](https://github.com/osmosis-labs/osmosis/tree/main/x/ibc-hooks#wasm-hooks) to trigger wasm contracts, it will derive the sender for the wasm call itself (rather than just the plain IBC sender). In this instance as well you can require the contract to expect this specific derived sender address. | ||
|
||
|