This has been mentioned during the Parachain Summit. The popularity of the frontier pallets is increasing and Frontier should get properly maintained and audited.
The current state is putting a lot of pressure on the Frontier’s only maintainer and is not sustainable.
In addition to the difficulty to maintain it, Parity’s (to my understanding) doesn’t want to take any responsibility for Frontier’s pallet/code/issues, making it hard to guarantee its quality and support.
(The Moonbeam foundation is currently the one paying for audits in the Frontier/EVM repos)
I would suggest that Frontier gets included in the new FRAME repository that should get proposed soon, which should allow to be maintained by the community and benefit from the repo common structure/tool/processes
What’s your opinion ?
5 Likes
I know that I am the one proposing a new FRAME repo, which we will migrate commonly use pallets into, but even I think that Frontier would be on the tail end of pallets / ecosystems to include, due to the complexity of it, and the fact that none of the current core FRAME devs work on Frontier. It is actually mostly maintained by Wei.
That being said, I think if we need more support maintaining it, we should open some treasury proposals to increase the incentives for open source developers to maintain it.
Yes, I agree the complexity and the lack of good structure is probably a blocker to be included in FRAME, but the current situation is problematic. Wei is he only maintainer of the repository, not that there are no other developers but none of the other developers have rights for that repository.
Trying to have it included in the FRAME repository would allow to bring the quality of the future FRAME processes into the Frontier pallet which is more used than many other pallets.
Maybe doing a group refactoring before including it could be a good idea
Are there developers who you think should be added as contributors? That probably can be done?
I guess I want to get to the core issue here: What is the main problem you want to find a solution to?
The main problem is to properly maintain Frontier. Which means having a good process and set of rules for code review/merge, having it following the substrate versions, supporting community driven security processes (vulnerability disclosure, code audit from treasuries maybe).
While those can be achieved by keeping it in its own repo, having it included in the common repo would avoid duplicating all those efforts (which will do in the other repos too) and guarantee it would be treated with the same processes and quality than other pallets.
Frontier in FRAME repo
In order for pallet-ethereum to make sense as part of a runtime which aims to offer ethereum-like features, several additional Frontier pieces must be in place:
- Runtime Api
- RPC methods
- Offchain DB
- Background tasks
This makes pallet-ethereum more of a single (runtime) piece of a whole architecture to emulate the ethereum blockchain within a substrate-based chain, rather than a fully independent STF piece of logic.
That doesn’t means the pallet cannot work standalone - which can if pallet-evm is also part of the runtime - but is more like the pallet loses it’s purpose and does not do anything that pallet-evm cannot handle itself in that case.
Maybe pallet-evm could be a good candidate to include in the new FRAME repo, as it’s more of a general purpose substrate interface with the evm crate.
Frontier maintenance
We’ve been contributing to Frontier for a couple of years now and I think Wei has done great designing and reviewing the project proposals but Alan is right in that a single maintainer can sometimes drag reviewing process depending on that person’s schedule, which is totally fine, but can be simply solved by having more eyes on it.
Now, regarding complexity, indeed that’s a problem and not only for adding Frontier pieces to the new FRAME repo, but also for selecting more maintainers that can be “trusted” as somehow knowledgeable enough to deal not only with Substrate-specific design decisions but also how those play out with what’s expected in the Ethereum emulation itself.
4 Likes