Make pallet_contracts compatible with the Ethereum RPC.

[agryaznov]

This is a tracking issue for making it possible to interact with _palletcontracts through the Ethereum RPC. We want this so that contract authors and users could use their contracts with well-known tooling like e.g. Truffle and Metamask.

We will try to achieve that by making Frontier's _palletethereum work with _palletcontracts.

In order for this RPCs to be useful we need to support Eth ABI in ink!:

• https://github.com/paritytech/ink/issues/1748.
• https://github.com/paritytech/cargo-contract/issues/1070.

[xlc]

how are you plan to handle the different address format?

how compatible do you intent to make them be? 100% or 98% (like Acala EVM+) or 50% (because people won’t be able to deploy and run evm contracts)?

what’s the status of this issue? pending research? design completed? poc ready?

[athei]

how are you plan to handle the different address format?

There will just be a mapping scheme between the 20bit addresses and whatever the chain uses. Just as this is the case for chains that use pallet-evm without using 20bit natively.

how compatible do you intent to make them be? 100% or 98% (like Acala EVM+) or 50% (because people won’t be able to deploy and run evm contracts)?

At first, we just aim for end user compatibility: A Dapp deployed on pallet-contracts can be used with Metamask. Developers will still need to be aware. But they can target the Metamask userbase.

what’s the status of this issue? pending research? design completed? poc ready?

Pending research. But I am at a point where I am convinced that it will work. The only big work item is supporting Eth ABI in ink! (in addition to our native SCALE based Abi).

[xlc]

We already have a pallet to manage account mapping https://github.com/AcalaNetwork/Acala/blob/master/modules/evm-accounts/src/lib.rs

It is possible to make Substrate chain use H160 as address (e.g. Moonbeam). Is it possible to make ink contract use H160 as address? If that's possible, then things will be a bit easier.

[athei]

We already have a pallet to manage account mapping https://github.com/AcalaNetwork/Acala/blob/master/modules/evm-accounts/src/lib.rs

I know. This is why I didn't spend too much thoughts on this. It is a solved problem.

It is possible to make Substrate chain use H160 as address (e.g. Moonbeam). Is it possible to make ink contract use H160 as address? If that's possible, then things will be a bit easier.

pallet-contracts and hence ink! is generic over the account id. So it will use whatever you use on your chain. So whatever approach your chain is using (mapping vs native H160) will work.

[cmichi]

Related issue for ink!: https://github.com/paritytech/ink/issues/1748. Related issue for cargo-contract: https://github.com/paritytech/cargo-contract/issues/1070.