Proposal for Ethereum Classic to Use The Etherplan Consensus Engine

Below is an Ethereum Classic Improvement Proposal (ECIP) that I submitted for review by the Ethereum Classic (ETC) community. It proposes to use the The Etherplan Consensus Engine as the mechanism to decide on a portion of the planned ETC proto treasury system.

ECIP: 1102
Title: Use The Etherplan Consensus Engine for Approving Proto Treasury Funding Proposals
Lang: EN
Author: Donald McIntyre (@TokenHash)
Discussions-to: https://github.com/ethereumclassic/ECIPs/issues/407
Status: WIP
Type: Meta
Created: 2021-02-03
Complementary to: ECIP-1098 Proto Treasury System
License: CC-BY-SA

Abstract

The Ethereum Classic (ETC) Proto Treasury System (p-ECTS) proposal suggests directing 10% of the miner tax funds to a Gitcoin grants program. This ECIP proposes to direct those funds to an ETC community managed pool on the Etherplan Consensus Engine (ECE) dapp. The ECE is a system designed for decentralized groups of any kind to distribute funds using rough consensus.

Motivation

Currently, the ETC Proto Treasury System (p-ECTS) proposal ECIP-1098 suggests to send 90% of the miner tax to three client members of the treasury, 30% each. The other 10% is suggested to be sent to the Gitcoin grant system.

It is the opinion of this author that Gitcoin is not an optimal system to distribute Ethereum Classic treasury funds for projects by individuals, developers, or teams who want to contribute to ETC. Gitcoin is a private Ethereum native project owned, in part, by ConsenSys, it uses quadratic funding which exponentiates payments to grantees based on the small contributions of strangers, and constitutes another information hurdle ETC community members would need to overcome to understand who are the grantees, what are their projects, and if they are actually implementing them adequately.

The Etherplan Consensus Engine, an Ethereum Classic native project by Donald McIntyre, founder of Etherplan, is proposed as the replacement of Gitcoin in the p-ECTS so ETC community members may have a direct say in what projects are funded on a rough consensus basis, which is ETC’s historical method of making decisions, rather than on the contributions of third parties.

The ECE pool of the ETC ecosystem would have a GitHub repo to edit, control, and associate funding proposals with a similar, but not identical, process as the Ethereum Classic Improvement Proposal (ECIP) process.

Specification

Replace Gitcoin by directing the suggested 10% p-ECTS miner tax funds to the ETC community’s ECE pool contract account in the Ethereum Classic blockchain.
Create a repo within the Ethereum Classic GitHub organization for individuals, developers, and teams to enter proposals as pull requests.
This repo may be called the Ethereum Classic Funding Proposal (ECFP) process and its URL may be /github.com/ethereumclassic/ECFPs.
Each funding proposal may be called an ECFP.
Each ECFP must go through a similar process as ECIPs where proposers, who may be anyone, enter them as pull requests (PRs), so then ECFP administrators (who are analogous to editors in the ECIP process) and proposers may check and correct them, and associate them, if applicable, as competing or complementary to other ECFPs.
Once ECFP admins and proposers are finished setting up and associating ECFP PRs according to the ECFP and ECE rules, they may be merged into the repo for community consideration.
When ECFPs are merged, they must also be entered into the ECE dapp where all the corresponding smart contracts will be deployed on the layer 2 PoS blockchain (possibly Cardano) and ETC as the base layer, or layer 1.
When ECFPs are entered in the ECE, a proof of authority list of ETC voting participants will analyze and vote on them.
When ECFPs are processed and voted on in the ECE dapp, they will either be approved for funding or rejected as per the ECE protocol.
Please see the Etherplan Consensus Engine white paper for full details of its operation here: https://etherplan.com/2021/02/02/the-etherplan-consensus-engine/14989/
As the Ethereum Classic Proto Treasury System proposal is gaining traction in ETC, and it is proposed by a team from IOHK, and IOHK is also the main technical supporter of the Cardano PoS blockchain, then it makes sense for the PoS execution layer, or layer 2, of the ETC ECE pool to be built on that blockchain.

Rationale

The ECE is a consensus engine so it does not distribute funds in a matching format as are typical 1:1 matched grants or CLR matched grants on Gitcoin. However, the Ethereum Classic ecosystem needs a direct way for deciding what projects to fund with its miner tax rather than having third parties from other communities choose their desired projects and then having the p-ECTS matching them. The reason for this is that ETC needs to directly finance the most relevant projects for its system and promotion, while minimizing the risk of fraud and misdirection of funds to benefit other ecosystems.

The Etherplan Consensus Engine is a native ETC project that is designed to demonstrate the multilayered vision of the blockchain stack, establishing ETC as the base layer of its system. It also mimics how rough consensus is reached in Bitcoin and Ethereum Classic as a better and more secure way of distribution p-ECTS funds.

Implementation

The description of the ECE smart contracts, their functionality, and the general dapp structure are specified in the Etherplan Consensus Engine white paper linked above. The ECE pool for Ethereum Classic to send the 10% of p-ECTS funds could be built with ETC community resources, or other funding sources as this author is not a developer or engineer and does not count with such resources.

The Etherplan Consensus Engine would need intense testing, peer review through this proposal, and smart contracts should be audited thoroughly before sending funds and processing real funding proposals on them.

Participants, admins, and users will pay the regular layer 1 or layer 2 network gas fees when making proposals, deploying them, or voting on them.

To the knowledge of this author, bridges or other interoperability technologies are not currently in place between Ethereum Classic and Cardano, or other possible candidate layer 2 proof of stake networks. These would have to be developed, implemented, and deployed on both layer 1 and layer 2 networks for the ECE to work as designed.

Building the ECE for this proposal as a community effort and investment could potentially benefit Etherplan privately as explained in the disclaimer section below.

Risks and Weaknesses

In its current state, the Etherplan Consensus Engine presents two centralization risks and a weakness explained with their possible solutions in the following points.

Who gets a vote and based on what criteria?

Problem:

The voter participants may be selected based on proof of stake or proof of authority. If it were proof of stake, then the problem would be solved because stakers get (+) and (-) ions based on their stake. If it’s PoA, then the problem is that participants may be arbitrarily included or left out by whoever creates the lists.

Possible solution:

This author does not see a genesis list in a proof of authority pool that may be completely trust minimized, but the Ethereum Classic ECIP process works with groups of relatively known participants, developers, and editors anyway.

There will have to be an initial stage where all regular members of the ecosystem are “inducted” into the proof of authority white list on the execution and base layers. From there they would get 1 (+) and 1 (-) ion per proposal so they can vote on them.

There are many people who are obvious community participants; lay people, investors, and engineers. Then, there are 10 or 15 mining pools who have been on ETC since the start or for a long time. Then, the top 10 or 15 exchanges that have supported ETC for a long time.

There is also a list of more or less 120 node operators that are usually contacted to make upgrades. There are community lists like this one used to do this.

All of the above participants could announce a public key so they may be inducted. When all of the above are inducted they will become the “genesis list”.

Once there is a large amount of participants, then a threshold may be set. It is 60+ in the ECE paper, but it may be different based on the size of the proof of authority list and expected participation rates.

For all the other anonymous node operators in ETC, it is likely they are largely exchanges, wallets, and dapps, so all should be invited. The proof of authority list may be edited with PRs or votes on the ECE to continuously add or delete keys (sometimes people also lose their private keys, so this mechanism may be used to change public keys of existing participants as well).

How can proposals be grouped as competing or complementary in a safe way?

Problem:

Maliciously relating unrelated proposals, entering fake proposals to up or downvote others, or making unrelated active proposals up or downvote others may manipulate outcomes.

Possible solution:

In this early stage of the ECE, it would be better to do the entry and association of proposals manually as described in the specification, similar to the Ethereum Classic ECIP process. The proposals may start as pull requests (PRs) on Github, and then the pool admins, together with proposers, can clean and polish them and associate them, just like ECIPs are processed by editors and authors today.

In a future ECE version, more autonomous, trust minimized, or rough consensus based automated association solutions may be proposed and integrated.

Are there bridges or interoperability technologies in place to implement the layered design of the Etherplan Consensus Engine?

Problem:

The Etherplan Consensus Engine is designed to have a proof of stake network as its execution layer, or layer 2, which would need to interoperate with Ethereum Classic as the base layer, or layer 1. To the knowledge of this author, there are no known such solutions in place at the time of this writing.

Possible solution:

There are several proposals in the ECIP pipeline that would enable interoperability between ETC and other blockchains. Such solutions are ECIP-1049, the integration of Keccak 256, ECIP-1055, Flyclient, and ECIP-1046, Merkle inclusion proofs to enable NiPoPoWs. As several engineers and developer teams are interested in these upgrades, and they are gaining rough consensus in the ETC ecosystem, it is entirely possible for these to be integrated, making possible the implementation of this ECIP. As IOHK is the main technical supporter of the Cardano blockchain, and all blockchains will eventually need to interoperate with other networks, they could work on the upgrades needed on that network’s side to be able to interoperate with ETC.

About The Etherplan Consensus Engine

The Etherplan Consensus Engine helps decentralized groups of any kind manage pools of money on blockchains using rough consensus in a secure, objective, transparent, and mechanical way. The system mimics neural computations where the internal computations of smart contracts, coupled with the interactions between contracts, have the overall effect of reducing noise and increasing relevance for sound decision making. Participants, administrators, and proposers are connected with the pools of capital they manage or solicit funds from in a three layered modular system that optimizes the distribution of risk and computational load in a highly cost effective way. It achieves this by leveraging a web interface for a better user experience; a proof of stake blockchain as an execution layer (Cardano), or layer 2, for performance; and a proof of work blockchain as a base layer (Ethereum Classic), or layer 1, for security, custody, settlements, and auditable record keeping.

See a short explanation of the ECE dapp here: https://etherplan.com/2021/02/04/the-etherplan-consensus-engine-dapp-explained/15371/

Disclaimer

The Etherplan Consensus Engine is an invention by Donald McIntyre, founder of Etherplan. The ETC ECE pool, dapp, and process may serve as a model and leading case of the Etherplan Consensus Engine in general. Etherplan may use this model and leading case to further develop a dapp for commercial use, similar to how Gitcoin is a commercial dapp, plausibly building an Etherplan Consensus Engine platform for general use by decentralized groups of any kind.

The above means that, indeed, the ECE is a bona fide proposal as the best decision making process for the ETC community to distribute treasury funds, but it will also benefit Etherplan for private business purposes in case it launches the ECE model as a general use commercial dapp. Consequently, any potential support or investment of ETC community resources in building the first ECE pool may directly or indirectly benefit Etherplan.

However, The Etherplan Consensus Engine is licensed as an open source project under CC-BY-SA as seen below.