Skip to content

Commit d79a80d

Browse files
committed
Merge branch 'develop' of https://github.com/initia-labs/docs-new into username-and-vip
2 parents 436ffbd + a8b85bb commit d79a80d

File tree

5 files changed

+987
-12
lines changed

5 files changed

+987
-12
lines changed
Lines changed: 293 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,293 @@
1+
---
2+
title: EVM IBC Hooks
3+
---
4+
5+
EVM hooks, implemented as IBC middleware, play a critical role in facilitating cross-chain contract calls that involve token transfers. This capability is particularly crucial for cross-chain swaps, providing a robust mechanism for decentralized trading across different blockchain networks. The key to this functionality is the `memo` field in the ICS20 and ICS721 transfer packets, as introduced in [IBC v3.4.0](https://medium.com/the-interchain-foundation/moving-beyond-simple-token-transfers-d42b2b1dc29b).
6+
7+
# EVM Contract Execution Format
8+
9+
Before we dive into the IBC metadata format, let's take a look at the hook data format and address which fields we need to be setting. The EVM `MsgCall` is defined [here](https://github.com/initia-labs/minievm/blob/main/x/evm/types/tx.pb.go) and other types are defined [here](https://github.com/initia-labs/minievm/blob/main/app/ibc-hooks/message.go).
10+
11+
```go
12+
// HookData defines a wrapper for evm execute message
13+
// and async callback.
14+
type HookData struct {
15+
// Message is a evm execute message which will be executed
16+
// at `OnRecvPacket` of receiver chain.
17+
Message evmtypes.MsgCall `json:"message"`
18+
19+
// AsyncCallback is a callback message which will be executed
20+
// at `OnTimeoutPacket` and `OnAcknowledgementPacket` of
21+
// sender chain.
22+
AsyncCallback *AsyncCallback `json:"async_callback,omitempty"`
23+
}
24+
25+
// AsyncCallback is data wrapper which is required
26+
// when we implement async callback.
27+
type AsyncCallback struct {
28+
// callback id should be issued form the executor contract
29+
Id uint64 `json:"id"`
30+
ContractAddr string `json:"contract_addr"`
31+
}
32+
33+
// MsgCall is a message to call an Ethereum contract.
34+
type MsgCall struct {
35+
// Sender is the that actor that signed the messages
36+
Sender string `protobuf:"bytes,1,opt,name=sender,proto3" json:"sender,omitempty"`
37+
// ContractAddr is the contract address to be executed.
38+
// It can be cosmos address or hex encoded address.
39+
ContractAddr string `protobuf:"bytes,2,opt,name=contract_addr,json=contractAddr,proto3" json:"contract_addr,omitempty"`
40+
// Hex encoded execution input bytes.
41+
Input string `protobuf:"bytes,3,opt,name=input,proto3" json:"input,omitempty"`
42+
}
43+
```
44+
45+
So we detail where we want to get each of these fields from:
46+
47+
- `Sender`: We cannot trust the sender of an IBC packet, the counter-party chain has full ability to lie about it. We cannot risk this sender being confused for a particular user or module address on Initia. So we replace the sender with an account to represent the sender prefixed by the channel and a evm module prefix. This is done by setting the sender to `Bech32(Hash(Hash("ibc-evm-hook-intermediary") + channelID/sender))`, where the channelId is the channel id on the local chain.
48+
- `ContractAddr`: This field should be directly obtained from the ICS-20 packet metadata
49+
- `Input`: This field should be directly obtained from the ICS-20 packet metadata.
50+
51+
So our constructed EVM call message that we execute will look like:
52+
53+
```go
54+
msg := MsgCall{
55+
// Sender is the that actor that signed the messages
56+
Sender: "init1-hash-of-channel-and-sender",
57+
// ContractAddr is the contract address to be executed.
58+
// It can be cosmos address or hex encoded address.
59+
ContractAddr: packet.data.memo["evm"]["message"]["contract_addr"],
60+
// Hex encoded execution input bytes.
61+
Input: packet.data.memo["evm"]["message"]["input"],
62+
}
63+
```
64+
65+
# ICS20 packet structure
66+
67+
So given the details above, we propagate the implied ICS20 packet data structure. ICS20 is JSON native, so we use JSON for the memo format.
68+
69+
```json
70+
{
71+
//... other ibc fields that we don't care about
72+
"data": {
73+
"denom": "denom on counterparty chain (e.g. uatom)", // will be transformed to the local denom (ibc/...)
74+
"amount": "1000",
75+
"sender": "addr on counterparty chain", // will be transformed
76+
"receiver": "ModuleAddr::ModuleName::FunctionName",
77+
"memo": {
78+
"evm": {
79+
// execute message on receive packet
80+
"message": {
81+
"contract_addr": "0x1",
82+
"input": "hex encoded byte string",
83+
},
84+
// optional field to get async callback (ack and timeout)
85+
"async_callback": {
86+
"id": 1,
87+
"contract_addr": "0x1"
88+
}
89+
}
90+
}
91+
}
92+
}
93+
```
94+
95+
An ICS20 packet is formatted correctly for evmhooks iff the following all hold:
96+
97+
- [x] `memo` is not blank
98+
- [x] `memo` is valid JSON
99+
- [x] `memo` has at least one key, with value `"evm"`
100+
- [x] `memo["evm"]["message"]` has exactly five entries, `"contract_addr"` and `"input"`
101+
- [x] `receiver` == "" || `receiver` == `"module_address::module_name::function_name"`
102+
103+
We consider an ICS20 packet as directed towards evmhooks iff all of the following hold:
104+
105+
- `memo` is not blank
106+
- `memo` is valid JSON
107+
- `memo` has at least one key, with name `"evm"`
108+
109+
If an ICS20 packet is not directed towards evmhooks, evmhooks doesn't do anything. If an ICS20 packet is directed towards evmhooks, and is formatted incorrectly, then evmhooks returns an error.
110+
111+
# Execution flow
112+
113+
Pre evm hooks:
114+
115+
- Ensure the incoming IBC packet is cryptogaphically valid
116+
- Ensure the incoming IBC packet is not timed out.
117+
118+
In evm hooks, pre packet execution:
119+
120+
- Ensure the packet is correctly formatted (as defined above)
121+
- Edit the receiver to be the hardcoded IBC module account
122+
123+
In evm hooks, post packet execution:
124+
125+
- Construct evm message as defined before
126+
- Execute evm message
127+
- if evm message has error, return ErrAck
128+
- otherwise continue through middleware
129+
130+
# Async Callback
131+
132+
A contract that sends an IBC transfer, may need to listen for the ACK from that packet. To allow contracts to listen on the ack of specific packets, we provide Ack callbacks. The contract, which wants to receive ack callback, have to implement two functions.
133+
134+
- ibc_ack
135+
- ibc_timeout
136+
137+
```go
138+
interface IIBCAsyncCallback {
139+
function ibc_ack(uint64 callback_id, bool success) external;
140+
function ibc_timeout(uint64 callback_id) external;
141+
}
142+
```
143+
144+
Also when a contract make IBC transfer request, it should provide async callback data through memo field.
145+
146+
- `memo['evm']['async_callback']['id']`: the async callback id is assigned from the contract. so later it will be passed as argument of `ibc_ack` and `ibc_timeout`.
147+
- `memo['evm']['async_callback']['contract_addr']`: The address of module which defines the callback function.
148+
149+
# Tutorials
150+
151+
This tutorial will guide you through the process of deploying a EVM contract and calling it from another chain using IBC hooks.
152+
We will use IBC hook from Initia chain to call a EVM contract on MiniEVM chain in this example.
153+
154+
## Step 1. Deploy a contract on MiniEVM chain
155+
156+
Write and deploy a simple [counter contract](https://github.com/initia-labs/minievm/blob/main/x/evm/contracts/counter/Counter.sol) to Initia.
157+
158+
```soliditiy
159+
contract Counter is IIBCAsyncCallback {
160+
uint256 public count;
161+
event increased(uint256 oldCount, uint256 newCount);
162+
constructor() payable {}
163+
function increase() external payable {
164+
count++;
165+
emit increased(count - 1, count);
166+
}
167+
function ibc_ack(uint64 callback_id, bool success) external {
168+
if (success) {
169+
count += callback_id;
170+
} else {
171+
count++;
172+
}
173+
}
174+
function ibc_timeout(uint64 callback_id) external {
175+
count += callback_id;
176+
}
177+
function query_cosmos(
178+
string memory path,
179+
string memory req
180+
) external returns (string memory result) {
181+
return COSMOS_CONTRACT.query_cosmos(path, req);
182+
}
183+
}
184+
```
185+
186+
## Step 2. Update IBC hook ACL for the contract
187+
188+
IBC hook has strong power to execute any functions in counterparty chain and this can be used for fishing easily.
189+
So, we need to set the ACL for the contract to prevent unauthorized access.
190+
To update MiniEVM ACL, you need to use `MsgExecuteMessages` in OPchild module.
191+
192+
```typescript
193+
const aclMsg = new MsgUpdateACL(
194+
'init10d07y265gmmuvt4z0w9aw880jnsr700j55nka3', // autority
195+
'init1436kxs0w2es6xlqpp9rd35e3d0cjnw4sv8j3a7483sgks29jqwgs9nxzw8', // contract address
196+
true // allow
197+
)
198+
199+
const msgs = [
200+
new MsgExecuteMessages(
201+
proposer.key.accAddress,
202+
[aclMsg]
203+
)
204+
]
205+
const signedTx = await proposer.createAndSignTx({ msgs })
206+
await proposer.lcd.tx.broadcast(signedTx).then(res => console.log(res))
207+
```
208+
209+
```bash
210+
curl -X GET "https://lcd.minievm-1.initia.xyz/initia/ibchooks/v1/acls" -H "accept: application/json"
211+
```
212+
213+
Response:
214+
215+
```json
216+
{
217+
"acls": [
218+
{
219+
"address": "init1fj6uuyhrhwznfpu350xafhp6tdurvfcwmq655f", // 0x4cb5cE12e3bB85348791A3cDd4dc3A5b7836270e
220+
"allowed": true
221+
}
222+
],
223+
"pagination": {
224+
"next_key": null,
225+
"total": "1"
226+
}
227+
}
228+
```
229+
230+
## Step 3. Execute IBC Hooks Message
231+
232+
233+
After the contract is deployed and the ACL is set, we can execute the IBC hooks message to call the contract.
234+
235+
236+
```typescript
237+
import { Coin, Height, LCDClient, MnemonicKey, MsgTransfer, Wallet } from "@initia/initia.js";
238+
import { ethers } from "ethers";
239+
import * as fs from 'fs'
240+
241+
function createHook(params: object) {
242+
const hook = { evm: { message: params } }
243+
return JSON.stringify(hook)
244+
}
245+
246+
async function main() {
247+
const l1lcd = new LCDClient('https://lcd.stone-16.initia.xyz', {
248+
gasAdjustment: '1.75',
249+
gasPrices: '0.15uinit'
250+
})
251+
252+
const sender = new Wallet(
253+
l1lcd,
254+
new MnemonicKey({
255+
mnemonic: 'power elder gather acoustic valid ... '
256+
})
257+
)
258+
259+
const amount = "1000"
260+
261+
const contractInfo = JSON.parse(
262+
fs.readFileSync('./bin/Counter.json').toString()
263+
)
264+
const abi = contractInfo.abi
265+
266+
const contractAddress = "0x4cb5cE12e3bB85348791A3cDd4dc3A5b7836270e"
267+
const contract = new ethers.Contract(contractAddress, abi);
268+
const methodName = "increase"
269+
const args: any[] = []
270+
271+
const encodedData = contract.interface.encodeFunctionData(methodName, args)
272+
const msgs = [
273+
new MsgTransfer(
274+
'transfer',
275+
'channel-10',
276+
new Coin("uinit", amount),
277+
sender.key.accAddress,
278+
contractAddress,
279+
new Height(0, 0),
280+
((new Date().valueOf() + 100000) * 1000000).toString(),
281+
createHook({
282+
contract_addr: contractAddress,
283+
input: encodedData
284+
})
285+
)
286+
]
287+
288+
const signedTx = await sender.createAndSignTx({ msgs });
289+
await l1lcd.tx.broadcastSync(signedTx).then(res => console.log(res));
290+
}
291+
292+
main()
293+
```

0 commit comments

Comments
 (0)