Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make pallet_contracts compatible with the Ethereum RPC. #111

Open
agryaznov opened this issue Apr 12, 2023 · 5 comments
Open

Make pallet_contracts compatible with the Ethereum RPC. #111

agryaznov opened this issue Apr 12, 2023 · 5 comments
Labels
D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. I5-enhancement An additional feature request.

Comments

@agryaznov
Copy link
Contributor

agryaznov commented Apr 12, 2023

This is a tracking issue for making it possible to interact with pallet_contracts 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 pallet_ethereum work with pallet_contracts.

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

@agryaznov agryaznov self-assigned this Apr 12, 2023
@agryaznov agryaznov changed the title Make _pallet_contracts_ compatible with the Ethereum RPC. Make pallet_contracts compatible with the Ethereum RPC. Apr 12, 2023
@xlc
Copy link
Contributor

xlc commented Apr 12, 2023

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
Copy link
Member

athei commented Apr 12, 2023

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
Copy link
Contributor

xlc commented Apr 12, 2023

We already have a pallet to manage account mapping https:/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
Copy link
Member

athei commented Apr 12, 2023

We already have a pallet to manage account mapping https:/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
Copy link

cmichi commented Apr 13, 2023

Related issue for ink!: use-ink/ink#1748.
Related issue for cargo-contract: use-ink/cargo-contract#1070.

@takahser takahser mentioned this issue Aug 11, 2023
10 tasks
@athei athei transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I5-enhancement An additional feature request. D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. and removed J0-enhancement labels Aug 25, 2023
@agryaznov agryaznov removed their assignment Nov 29, 2023
lexnv added a commit that referenced this issue Apr 3, 2024
chainHead/unpin: Explicit about unpin parameters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. I5-enhancement An additional feature request.
Projects
Status: Open
Status: Backlog 🗒
Development

No branches or pull requests

5 participants