└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Polkadot EVM Collective 2 | 3 | The Polkadot EVM collective is a planned on-chain technical collective that 4 | deals with everything related to EVM. It is similar to the fellowship program, 5 | with the topic of EVM, instead of core runtime. 6 | 7 | There are four goals of this collective. It is first and foremost a 8 | standardization body that will be in charge of its own RFC process. It wants to 9 | provide transparency over the development and maintenance of various tools that 10 | the ecosystem uses. It also tries to create an inclusive roadmap with the aim 11 | of reconcile different needs. And finally, it provides expert opinions to those 12 | who need them. We'll discuss the four goals in more details in the following 13 | sections. 14 | 15 | The discussion of an on-chain Polkadot EVM collective has been under way during 16 | the early days of Frontier development. During the last few months, especially 17 | during Parity's "decentralization", we increasingly see the need of an on-chain 18 | collective as the Frontier project moves independently. The recent "OpenEVM" 19 | movement (credit to *Giotto*) heavily accelerated the process. 20 | 21 | ## Goals 22 | 23 | ### Standardization 24 | 25 | In the context of Polkadot EVM, there are a number of Polkadot-specific 26 | modifications we need to do. Polkadot EVM has custom precompiles as well as 27 | custom gas metering logic. In the past, we have also seen some specific use 28 | cases that require custom transaction format or new opcodes. The Polkadot EVM 29 | collective aims to create an RFC process to document them. 30 | 31 | A standardization process is important in certain modifications. The collective 32 | itself acts as a review and audit body to help discover various security issues 33 | in the specifications. It also helps to improve interoperability across 34 | parachains, as eventually we want to have contracts on different parachains 35 | talking with each other freely. 36 | 37 | ### Development and maintenance 38 | 39 | The collective aims to bring more transparency over the development and 40 | maintenance of various tools that the ecosystem uses. We aim to link the 41 | membership of the EVM collective with the membership and merge rights in the 42 | [polkadot-evm](https://github.com/polkadot-evm) Github organization. It 43 | therefore becomes clear who is responsible for the maintenance and who can merge 44 | PRs. It avoids single-point-of-failure if one person is temporarily not available. 45 | It also helps in the situation that some technical differences between different 46 | members are non-conciliable (but hopefully we never come to that point). 47 | 48 | ### Roadmap 49 | 50 | During the past few years when working on the Frontier project, I've seen, at 51 | first hand, the vast different opinions on how the Polkadot community should 52 | work with EVM development. And I'm afraid to say, that it is still the case at 53 | this moment, that there's a big disconnect between the core development team, 54 | and the parachain ecosystem. While those are purely different technical views, 55 | they have vast influence on how subsequently the ecosystem develops tools and 56 | use contracts. 57 | 58 | Should the EVM interpreter be on-chain or should EVM contracts be off-chain 59 | compiled first? How strict should we treat EVM compatibility? What is the 60 | timeline of EVM? Should we support EVM indefinitely, or is it purely there to 61 | provide a migration path to WASM/RISC-V? 62 | 63 | Such issues have a big impact on dapp developers. If they develop on Polkadot, 64 | we want to make sure they have certainty over what they may have and not have in 65 | the near future, so that they know that whatever tools they developed wouldn't 66 | be made obsolete by the core dev team. The Polkadot EVM collective aims to 67 | provide a discussion platform that can provide some certainty. 68 | 69 | We also deal with bigger issue in the roadmap, such as the migration of a 70 | complete Ethereum blockchain over to Polkadot. (Yes, this is possible and 71 | technically a planned feature in Frontier.) 72 | 73 | ### Expert opinions 74 | 75 | The Polkadot EVM collective also aims to provide expert opinions and help in 76 | review, audit, and coordinate certain ecosystem initiatives. For example, the 77 | collective may be in charge to draft the detailed technical requirements for the 78 | new "OpenEVM" parachain and supervise its implementation. For this, we currently 79 | don't expect the collective to handle anything related to code implementation. 80 | It will likely be decided through a tendering process via a treasury referendum, 81 | and developed by an external team who wins the bid. 82 | 83 | ## Scope 84 | 85 | The scope of the collective is intentionally set to be specific and concrete in 86 | order to ensure a functional collaboration. One is eligible as a member of the 87 | Polkadot EVM collective if one is involved in the development of a tool or a 88 | parachain/solochain that has EVM feature. This currently includes: 89 | 90 | * [Frontier](https://github.com/polkadot-evm/frontier) 91 | * [Rust-EVM](https://github.com/rust-ethereum/evm) 92 | * [Moonbeam](https://github.com/moonbeam-foundation/moonbeam) 93 | * [Astar](https://github.com/AstarNetwork/Astar) 94 | * [Tangle](https://github.com/webb-tools/tangle) 95 | * [Edgeware (EdgeEVM)](https://github.com/edgeware-network/edgeware-node) 96 | * [Polkadot EVM substrate-etl/Dune integration (Colorful Notion)](https://polkadot.polkassembly.io/referenda/366) 97 | * [Acala](https://github.com/AcalaNetwork/Acala) 98 | * [Darwinia](https://github.com/darwinia-network/darwinia) 99 | * [Hyperledger Solang](https://github.com/hyperledger/solang) 100 | * [Magnet](https://github.com/Magport/Magnet) 101 | * [NeuroWeb](https://github.com/OriginTrail/neuroweb) 102 | * Please submit PRs to add another tool to this list. 103 | 104 | ## Membership 105 | 106 | There are two aspects of the membership -- ranks and roles. Rank defines a member's 107 | voting power within the collective. Role gives out ecosystem-specific permissions 108 | and responsibilities. 109 | 110 | ### Rank 111 | 112 | The EVM Collective uses a flat ranking system. We have two ranks. 113 | 114 | * **Junior members**. This corresponds to rank I. This is a member that is at least 115 | somewhat involved in Polkadot EVM development. 116 | * **Senior members**. This corresponds to rank III. This is a member that is deeply 117 | involved in Polkadot EVM development. 118 | 119 | The ranks of a member define the member's voting power. Unlike the Fellowship 120 | collective, rank does not determine a member's other privileges, such as any financial 121 | incentives. They are instead defined by "roles", which we explain in more 122 | details below. 123 | 124 | ### Role 125 | 126 | Role defines a member's responsibilities within the collective. The collective is run 127 | under the assumption that a member's contribution is correlated with the member's 128 | devotion, not seniority. As a result, financial incentives (if any) is associated with 129 | a role, but not with ranks. There are also no limitations on lower ranks with "higher" 130 | roles. A junior member might well have more financial incentives or other benefits, 131 | than a senior member, if she or he contributes more. 132 | 133 | The list of roles are dynamic. On-chain, the definition of a role contains only two 134 | information -- its index, and a shortname. Roles can be added or removed by changing 135 | the runtime config, without runtime upgrades. The addition and removal of roles, 136 | and the granting and dismissing of roles of a member, is done by a majority vote of 137 | the collective (respective to the member's voting power), or a referendum in OpenGov. 138 | 139 | The initial list of roles will only be defined once the collective becomes active 140 | on-chain, subject to all members' approvals. Below are examples of possible roles: 141 | 142 | * **RFC editor**: grants merge rights to the EVM RFC repository, responsible for 143 | maintaining the RFC process. 144 | * **Frontier maintainer**: grants merge rights to the Frontier repository, responsible 145 | for maintaining the Frontier project and making new releases. 146 | * **Other project maintainer roles**. 147 | * **Speaker of the collective**: responsible for publishing the collective's annual report 148 | to the community and handle certain communications. 149 | * **Special task force roles**. For example, launching a community-driven EVM parachain. 150 | 151 | ### Inactivity 152 | 153 | To ensure that the collective is able to move forward and is not bloated with members of 154 | inactions, an inactivity check is utilized. We define the exact algorithm below. The gist of 155 | the algorithm is that we require each member to rate whether they think that each other member 156 | is active. A member must receive at least 1/3 of the votes to continue to be considered active. 157 | 158 | The checking period is every 24 weeks (roughly 6 months). During each period, a member is 159 | required to submit an on-chain extrinsic for inactivity check. The content of the extrinsic 160 | is a bitmap of all other members, where `1` represents that the member believes that the 161 | other member is active, and `0` otherwise. Repeated extrinsic submissions will override past 162 | ones. 163 | 164 | At the end of each checking period, the following is applied: 165 | 166 | * Set `N0` to be the total number of active members in the last checking period. 167 | * If a member did not submit any on-chain extrinsic, it is marked inactive. 168 | * All new inactive members are filtered out. Set `N1` to be the total number of new 169 | (pending) active members. 170 | * Collect the bitmap of all submitted on-chain extrinsics. If the count of `1`s for a member 171 | is greater than or equal to `N1 / 3` rounded down to the nearest integer, then it is set 172 | as active. Otherwise, it is set as inactive. 173 | 174 | An inactive member keeps its rank, but will not be able to vote and will not count towards 175 | the required quorum. An inactive member will also have all of its roles set to inactive. 176 | 177 | The meaning of each inactive role is defined by each role. Usually, this means that the member 178 | will not have the privileges and responsibilities associated with the role. 179 | 180 | An inactive member is moved back to the active list by either a majority vote of the collective, 181 | or by a Polkadot referendum. 182 | 183 | ## Salary and sub-treasury 184 | 185 | The Polkadot EVM Collective has its own salary system and sub-treasury system for future 186 | use. Their values, right now, are always 0. Any increase or funding is only done through 187 | Polkadot referendums. 188 | 189 | ## Seeding 190 | 191 | All seeding members are subject to a final vote of a root referendum. Please submit PRs 192 | to add your name to the seeding list. 193 | 194 | | Github username | Polkadot Account | Rank | 195 | | :---: | :---: | :---: | 196 | 197 | ## Discussions 198 | 199 | ### A big collective or several small collectives 200 | 201 | While designing the collective, the first question we faced is whether we should have 202 | one single big collective -- one that covers all Polkadot ecosystem ("The Polkadot 203 | Ecosystem Collective") -- or several small collectives, each focusing on a concrete and 204 | specific field in Polkadot. 205 | 206 | We believe that small collectives are much more effective in carrying out its tasks: 207 | 208 | * Being **concrete and specific** ensures that all members of the collective always know 209 | the mission of the collective. What belongs, and not belongs a collective is always 210 | extremely clear. 211 | * Small collectives are **composible**. It's possible to compose small collectives into 212 | a big collective, should the need arise. Members of the big collective are instances of 213 | small collectives, instead of people. On the other hand, it's difficult to divide a big 214 | collective into smaller collectives, if we realize that the former is not functioning 215 | well. 216 | * Small collectives can **move faster and get more things done** because everyone is working 217 | in roughly the same field. Misunderstandings are less likely. The objectives are more 218 | clear. Participations are better encouraged because all motions / RFCs matters to 219 | nearly everyone. 220 | 221 | The only real drawback we know so far about small collectives is the **maintenance burden**. At 222 | this moment, all collectives require separate runtime pallets and also require runtime upgrade. 223 | As we expect at least a dozen new collectives in the near future, this is not scalable. We plan 224 | to address this by helping the Fellowship to develop a separate set of pallets that can host 225 | multiple collectives, with sub-treasury and salary features. Proposing a new collective becomes 226 | a runtime config change, instead of a runtime upgrade. 227 | 228 | ### A flat or a deep ranking system 229 | 230 | Readers may notice that in Polkadot EVM Collective's membership design, we only have two ranks, 231 | junior members (with vote power correspond to rank I), and senior members (with vote power correspond 232 | to rank III). We designed this to be a **flat ranking system**. This is in contrast to the 233 | Polkadot Fellowship Collective where we have a **deep ranking system**, with 7-9 ranks. 234 | 235 | We use a flat ranking system due to the practicality of the Polkadot EVM Collective, that we 236 | want to ensure that the majority of members are actually on-board with a certain motion. The EVM collective 237 | deals less with visionary changes, but more with the practical reality of making EVM work well on 238 | Polkadot. We want to ensure that, for example, EVM metering changes done specifically for Polkadot 239 | are properly reviewed, that precompiles can work with each other, and that EVM contracts across 240 | different parachains can interop. It is therefore really important to ensure that members are 241 | actually on-board, without the risk if a really senior member disagrees with everyone else. 242 | 243 | Rank only defines a member's voting power. We introduced a separate concept, called **roles**, to 244 | define a member's responsibilities within the collective. Any financial incentives or benefits of 245 | a member is associated with a role, but not a rank. A role can be a project maintainer, an RFC editor, 246 | a community spokesperson, or a special task-force. Compared with the design of the Fellowship collective, 247 | which relies on a linear scale of ranks, the separate concept of roles makes it significantly easier 248 | to assess a member, and determine whether she or he is sufficiently carrying out the duty. 249 | --------------------------------------------------------------------------------