-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add Substrate EVM Adapter application #2292
Conversation
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
0039147
to
b63c9ff
Compare
I have read and hereby sign the Contributor License Agreement. |
b63c9ff
to
07a3c82
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To my understanding this application tries to do what the Metamask snaps developed by Chainsafe try to do. I'm personally not fond of supporting another project with the same goal, especially as you are planning to completely discard a core piece of this grant application in the long run (adapter pallet). Other than that I left a few comments that should be addressed. Let's see what my colleagues will say.
|
||
## Future Plans | ||
|
||
In the future, we plan to explore if we can completely remove the adapter pallet and have the account mapping and transaction converting logic completely in the RPC adapter. This will allow us to have even more lightweight and generic solution, however could present more challenges. A minimal metamask snap that can share the keyring with the adapter could be one of the solutions, but needs more research. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the metamask snaps especially by Chainsafe are exactly what you are looking for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed it to more generic text about possibility of having evm compatibility without the pallet.
also, see my comment below for more context.
| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | ||
| **0e.** | Article | I will publish an article that explains the complete lifecycle and future plans of the project | | ||
| 1. | EVM Adapter Pallet | We will create a pallet that will be responsible for bridging the gap between the ETH RPC adapter and the Substrate chain. It will have the ability to dispatch FRAME calls, opt-in possibility to execute EVM bytecode, and handle account mapping. Another main responsibility of the pallet will be handling signature verification. Some parts of this pallet can be inspired from `frontier`'s pallet `pallet-ethereum` but needs refinement and some modification. | | ||
| 2. | Substrate Node | We will create a Substrate node that has two runtimes: with and without the `pallet-evm`. Both will contain `evm-adapter` pallet, but only the one with `pallet-evm` will be able to execute EVM bytecode. This will demonstrate two main use-cases of this pallet. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this Node different from existing EVM chains like Moonbeam?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moonbeam and many other EVM compatible chains built with Frontier have the ETH RPC baked in in the client. They also add a lot pallets, runtime APIs and other changes to the runtime to ensure full EVM compatibility. Integrated ETH RPC complicates the code, really slows down the node, tps takes a hit and makes it hard to benchmark etc.
This deliverable in comparison, will have the most minimal setup: normal Substrate client and runtime with stripped down, lightweight version of the pallet-evm
and pallet-evm-adapter
. rpc-adapter
is a standalone light client and does not have the problems of integrated rpc
thanks for the review! @PieWol In general, I described pros and cons for similar in the
I took a look at their snap as well, and it comes down to the same thing I mentioned for
I think, I understand where the confusion comes from. With enabling near to full evm compatibility without the pallet, I meant having such possibility, pallet would remain there as an option for teams to consider when they want to have EVM compatible chain. But it would be possible to "write" to the chain without using the adapter pallet. And |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welcome back and thanks for the application, @dastanbeksamatov.
You write that "In the future, we plan to explore if we can make the adapter pallet optional". Are you planning to use this architecture in a project of your own, or are you just building it in the hopes that it will generate enough community interest to maintain itself?
thanks @semuelle!
IMO, one of the main disadvantages of current solutions is the fact that they require a lot of changes to the core protocol (runtime and client). And by having the adapter pallet, we are not completely fixing that. This is why I think it is important to explore options that could enable frictionless EVM compatibility that does not require changes to the protocol. Obviously without sacrificing security of the chain.
RPC adapter itself will be a community tool that can run a light client of any Substrate chain and expose ETH RPC from it. As I mentioned above, there is enough community interest for this. And the evm adapter pallet, it will also be a public module that chains can use to provide "almost" full EVM compatibility. I can maintain it for the foreseeable future. If it generates enough interest (especially from the polkadot evm community), I would be interested in integrating it to upstream frontier monorepo as a stripped down version of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification, @dastanbeksamatov. Sounds good to me. I will share your application with the rest of the committee.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @dastanbeksamatov thanks for the explanations and also for the presentation you gave me during our call. Based on your previous work, also happy to approve it.
I know you've worked with us a lot but I don't believe you've gone through a KYC phase with us yet, which we now require for all grantees. Could you take a moment to submit verification? Thanks! Once that is done we can merge the grant.
just completed it! thanks! |
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
Project Abstract
Substrate EVM adapter aims to present an alternative approach to EVM compatibility for Substrate chains. The main goals are to improve developer experience and introduce an approach that requires the least amount of changes to the runtime and client. It does so by leveraging the best parts of multiple existing compatibility solutions and other awesome ecosystem tools.
Grant level
Application Checklist
project_name.md
).@_______:matrix.org
(change the homeserver if you use a different one)