-
Notifications
You must be signed in to change notification settings - Fork 585
-
Proposal: Support EVM tx in interchain-account host chain
Current behavior:
In general, the EVM msg handler relies on a custom ante handler pipeline to work, but the ICA host module will run the msgs under the default ante handler, there'll be issues with that, specifically:
- Gas Meter Reset
EthereumTxexpects an infinite gas meter set in advance and reset the gas meter with the gas used calculated by EVM, that don't work well with the default msg executor of the interchain-account host module.
- Gas Fee Payment and relayer incentivization.
- we need to have some kind of relayer incentivization first because the cost of evm tx varies.
- JSON-RPCs
- it emits the same events, so it can be found by json-rpc apis similarly to the batch tx.
(削除) the current pending PR tries to move some events to the ante handler, we should keep a copy in the msg handler too then. (削除ここまで)
- it breaks client's assumption that the fee is always paid by the tx sender, it's relayer instead.
- it emits the same events, so it can be found by json-rpc apis similarly to the batch tx.
Desired behavior: make evm tx works smoothly with interchain-account
Use case: support interchain-account host role
Possible solutions:
- make a custom msg handler which is implemented with interchain-account in mind?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 5 comments
-
maybe one "manual" alternative is directly constructing those messages in precompile: crypto-org-chain/cronos#483 ? it won't be "smooth" though, I guess: EVM will see invocation via interchain accounts as from EOA, but taking IBC messages from a precompile and interpreting them would not leverage much of the ibc-go code and there'll be an indirection
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
maybe one "manual" alternative is directly constructing those messages in precompile: crypto-org-chain/cronos#483 ? it won't be "smooth" though, I guess: EVM will see invocation via interchain accounts as from EOA, but taking IBC messages from a precompile and interpreting them would not leverage much of the ibc-go code and there'll be an indirection
do you mean some custom evm to evm interchain-accounts implementation?
Beta Was this translation helpful? Give feedback.
All reactions
-
I'm thinking about making a cosmos-sdk friendly evm msg type, sth like:
message EvmMessage { sender string to string value *big.Int data []byte }
it'll leave the auth/fee stuff to cosmos-sdk, works just like a normal cosmos-sdk msg, under the default ante handler pipeline.
Beta Was this translation helpful? Give feedback.
All reactions
-
do you mean some custom evm to evm interchain-accounts implementation?
Yes... one potential advantage is that one may want to restrict contract addresses that it can interact with (similarly to how one can restrict SDK message types for ICA).
it'll leave the auth/fee stuff to cosmos-sdk, (...)
as long as it doesn't bypass gas accounting (i.e. being able to pay significantly less than when going through the Ethermint's ante handler), it looks feasible
Beta Was this translation helpful? Give feedback.
All reactions
-
@yihuang I'd also add the the limitation that currently the Interchain Account is only supported for BaseAccounts: cosmos/ibc-go#1298
Beta Was this translation helpful? Give feedback.
All reactions
-
👀 3