The Polkadot EVM collective is a planned on-chain technical collective that deals with everything related to EVM. It is similar to the fellowship program, with the topic of EVM, instead of core runtime.
There are four goals of this collective. It is first and foremost a standardization body that will be in charge of its own RFC process. It wants to provide transparency over the development and maintenance of various tools that the ecosystem uses. It also tries to create an inclusive roadmap with the aim of reconcile different needs. And finally, it provides expert opinions to those who need them. We'll discuss the four goals in more details in the following sections.
The discussion of an on-chain Polkadot EVM collective has been under way during the early days of Frontier development. During the last few months, especially during Parity's "decentralization", we increasingly see the need of an on-chain collective as the Frontier project moves independently. The recent "OpenEVM" movement (credit to Giotto) heavily accelerated the process.
In the context of Polkadot EVM, there are a number of Polkadot-specific modifications we need to do. Polkadot EVM has custom precompiles as well as custom gas metering logic. In the past, we have also seen some specific use cases that require custom transaction format or new opcodes. The Polkadot EVM collective aims to create an RFC process to document them.
A standardization process is important in certain modifications. The collective itself acts as a review and audit body to help discover various security issues in the specifications. It also helps to improve interoperability across parachains, as eventually we want to have contracts on different parachains talking with each other freely.
The collective aims to bring more transparency over the development and maintenance of various tools that the ecosystem uses. We aim to link the membership of the EVM collective with the membership and merge rights in the polkadot-evm Github organization. It therefore becomes clear who is responsible for the maintenance and who can merge PRs. It avoids single-point-of-failure if one person is temporarily not available. It also helps in the situation that some technical differences between different members are non-conciliable (but hopefully we never come to that point).
During the past few years when working on the Frontier project, I've seen, at first hand, the vast different opinions on how the Polkadot community should work with EVM development. And I'm afraid to say, that it is still the case at this moment, that there's a big disconnect between the core development team, and the parachain ecosystem. While those are purely different technical views, they have vast influence on how subsequently the ecosystem develops tools and use contracts.
Should the EVM interpreter be on-chain or should EVM contracts be off-chain compiled first? How strict should we treat EVM compatibility? What is the timeline of EVM? Should we support EVM indefinitely, or is it purely there to provide a migration path to WASM/RISC-V?
Such issues have a big impact on dapp developers. If they develop on Polkadot, we want to make sure they have certainty over what they may have and not have in the near future, so that they know that whatever tools they developed wouldn't be made obsolete by the core dev team. The Polkadot EVM collective aims to provide a discussion platform that can provide some certainty.
We also deal with bigger issue in the roadmap, such as the migration of a complete Ethereum blockchain over to Polkadot. (Yes, this is possible and technically a planned feature in Frontier.)
The Polkadot EVM collective also aims to provide expert opinions and help in review, audit, and coordinate certain ecosystem initiatives. For example, the collective may be in charge to draft the detailed technical requirements for the new "OpenEVM" parachain and supervise its implementation. For this, we currently don't expect the collective to handle anything related to code implementation. It will likely be decided through a tendering process via a treasury referendum, and developed by an external team who wins the bid.
The scope of the collective is intentionally set to be specific and concrete in order to ensure a functional collaboration. One is eligible as a member of the Polkadot EVM collective if one is involved in the development of a tool or a parachain/solochain that has EVM feature. This currently includes:
- Frontier
- Rust-EVM
- Moonbeam
- Astar
- Tangle
- Edgeware (EdgeEVM)
- Polkadot EVM substrate-etl/Dune integration (Colorful Notion)
- Acala
- Darwinia
- Hyperledger Solang
- Magnet
- NeuroWeb
- Please submit PRs to add another tool to this list.
There are two aspects of the membership -- ranks and roles. Rank defines a member's voting power within the collective. Role gives out ecosystem-specific permissions and responsibilities.
The EVM Collective uses a flat ranking system. We have two ranks.
- Junior members. This corresponds to rank I. This is a member that is at least somewhat involved in Polkadot EVM development.
- Senior members. This corresponds to rank III. This is a member that is deeply involved in Polkadot EVM development.
The ranks of a member define the member's voting power. Unlike the Fellowship collective, rank does not determine a member's other privileges, such as any financial incentives. They are instead defined by "roles", which we explain in more details below.
Role defines a member's responsibilities within the collective. The collective is run under the assumption that a member's contribution is correlated with the member's devotion, not seniority. As a result, financial incentives (if any) is associated with a role, but not with ranks. There are also no limitations on lower ranks with "higher" roles. A junior member might well have more financial incentives or other benefits, than a senior member, if she or he contributes more.
The list of roles are dynamic. On-chain, the definition of a role contains only two information -- its index, and a shortname. Roles can be added or removed by changing the runtime config, without runtime upgrades. The addition and removal of roles, and the granting and dismissing of roles of a member, is done by a majority vote of the collective (respective to the member's voting power), or a referendum in OpenGov.
The initial list of roles will only be defined once the collective becomes active on-chain, subject to all members' approvals. Below are examples of possible roles:
- RFC editor: grants merge rights to the EVM RFC repository, responsible for maintaining the RFC process.
- Frontier maintainer: grants merge rights to the Frontier repository, responsible for maintaining the Frontier project and making new releases.
- Other project maintainer roles.
- Speaker of the collective: responsible for publishing the collective's annual report to the community and handle certain communications.
- Special task force roles. For example, launching a community-driven EVM parachain.
To ensure that the collective is able to move forward and is not bloated with members of inactions, an inactivity check is utilized. We define the exact algorithm below. The gist of the algorithm is that we require each member to rate whether they think that each other member is active. A member must receive at least 1/3 of the votes to continue to be considered active.
The checking period is every 24 weeks (roughly 6 months). During each period, a member is
required to submit an on-chain extrinsic for inactivity check. The content of the extrinsic
is a bitmap of all other members, where 1 represents that the member believes that the
other member is active, and 0 otherwise. Repeated extrinsic submissions will override past
ones.
At the end of each checking period, the following is applied:
- Set
N0to be the total number of active members in the last checking period. - If a member did not submit any on-chain extrinsic, it is marked inactive.
- All new inactive members are filtered out. Set
N1to be the total number of new (pending) active members. - Collect the bitmap of all submitted on-chain extrinsics. If the count of
1s for a member is greater than or equal toN1 / 3rounded down to the nearest integer, then it is set as active. Otherwise, it is set as inactive.
An inactive member keeps its rank, but will not be able to vote and will not count towards the required quorum. An inactive member will also have all of its roles set to inactive.
The meaning of each inactive role is defined by each role. Usually, this means that the member will not have the privileges and responsibilities associated with the role.
An inactive member is moved back to the active list by either a majority vote of the collective, or by a Polkadot referendum.
The Polkadot EVM Collective has its own salary system and sub-treasury system for future use. Their values, right now, are always 0. Any increase or funding is only done through Polkadot referendums.
All seeding members are subject to a final vote of a root referendum. Please submit PRs to add your name to the seeding list.
| Github username | Polkadot Account | Rank |
|---|
While designing the collective, the first question we faced is whether we should have one single big collective -- one that covers all Polkadot ecosystem ("The Polkadot Ecosystem Collective") -- or several small collectives, each focusing on a concrete and specific field in Polkadot.
We believe that small collectives are much more effective in carrying out its tasks:
- Being concrete and specific ensures that all members of the collective always know the mission of the collective. What belongs, and not belongs a collective is always extremely clear.
- Small collectives are composible. It's possible to compose small collectives into a big collective, should the need arise. Members of the big collective are instances of small collectives, instead of people. On the other hand, it's difficult to divide a big collective into smaller collectives, if we realize that the former is not functioning well.
- Small collectives can move faster and get more things done because everyone is working in roughly the same field. Misunderstandings are less likely. The objectives are more clear. Participations are better encouraged because all motions / RFCs matters to nearly everyone.
The only real drawback we know so far about small collectives is the maintenance burden. At this moment, all collectives require separate runtime pallets and also require runtime upgrade. As we expect at least a dozen new collectives in the near future, this is not scalable. We plan to address this by helping the Fellowship to develop a separate set of pallets that can host multiple collectives, with sub-treasury and salary features. Proposing a new collective becomes a runtime config change, instead of a runtime upgrade.
Readers may notice that in Polkadot EVM Collective's membership design, we only have two ranks, junior members (with vote power correspond to rank I), and senior members (with vote power correspond to rank III). We designed this to be a flat ranking system. This is in contrast to the Polkadot Fellowship Collective where we have a deep ranking system, with 7-9 ranks.
We use a flat ranking system due to the practicality of the Polkadot EVM Collective, that we want to ensure that the majority of members are actually on-board with a certain motion. The EVM collective deals less with visionary changes, but more with the practical reality of making EVM work well on Polkadot. We want to ensure that, for example, EVM metering changes done specifically for Polkadot are properly reviewed, that precompiles can work with each other, and that EVM contracts across different parachains can interop. It is therefore really important to ensure that members are actually on-board, without the risk if a really senior member disagrees with everyone else.
Rank only defines a member's voting power. We introduced a separate concept, called roles, to define a member's responsibilities within the collective. Any financial incentives or benefits of a member is associated with a role, but not a rank. A role can be a project maintainer, an RFC editor, a community spokesperson, or a special task-force. Compared with the design of the Fellowship collective, which relies on a linear scale of ranks, the separate concept of roles makes it significantly easier to assess a member, and determine whether she or he is sufficiently carrying out the duty.