Add pallet-contracts support as a pallet-evm Runner #1283
Conversation
| let (code, init_data, salt): (Vec<u8>, Vec<u8>, Vec<u8>) = | ||
| scale_codec::Decode::decode(&mut &init[..]).map_err(|_| RunnerError { | ||
| error: Error::<T>::Undefined, // TODO: pallet contracts specific error. | ||
| weight, | ||
| })?; |
There was a problem hiding this comment.
This will work but only when we provide some custom tooling, right? Otherwise when using web3.js init will contain init_args ++ code, right?
There was a problem hiding this comment.
This will need custom tooling no matter what simply because it's not EVM..
But it does fulfill the requirement that we can now use Ethereum RPCs to interact with pallet-contracts.
|
Question: Does this mean that the frontier can support ink contact with the Ethereum RPC layer? |
If this works, yes. :) |
|
Any updates here? |
|
This was only an experiment. We decided to go down a different route. Instead of adding support to frontier we are creating a solution more similar what Acala is doing: Having a stand alone proxy translation server that translates Eth RPC to Substrate unchecked extrinsics. This will allow it to work without adding support to each client. Please note that even with that it will not work with ink! out of the box. Ink needs support for Ethereum ABI to make this any useful. |
This adds basic
pallet-contractssupport by implementing it as a pallet-evmRunner.We implement
Runner::callandRunner::create, but notRunner::create2, because the latter is never directly called in an Ethereum transaction.The implementation of
Runner::callis straightforward. ForRunner::create, we "abused" theinitfield to hold a SCALE encoded tuple(code: Vec<u8>, init_data: Vec<u8>, salt: Vec<u8>), and implemented it that way.