The Etherplan Consensus Engine (ECE) [1] helps decentralized groups of any kind manage pools of money on blockchains using rough consensus in a secure, objective, transparent, and mechanical way.
As seen in table 1, it is designed after the nervous system, where the web interface represents the environment; the execution layer represents the peripheral nervous system; and the base layer represents the central nervous system.
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.
1. The Decentralized Application
The ECE dapp is meant for groups to organize and manage pools of money on blockchains through rough consensus, and it may be used for single or competing funding proposals.
As seen in diagram 1, the dapp is divided into a base layer, or layer 1, that runs on a proof of work decentralized public network for higher security, but lower performance; an execution layer, or layer 2, that runs on a proof of stake decentralized public network for higher performance, but lower security [2] [3]; and a web interface, or layer 3, which runs on a centralized web hosting service, or cloud computing service, for participants to setup and manage proposals, deploy contracts, and send transactions and contract calls.
The logic of the distribution of functions between these layers is as follows:
– The user experience is better on a well designed and functional graphical web interface (layer 3). In this interface, proposers can enter proposals and deploy them on decentralized networks, and participants may obtain and use ion tokens for voting.
It may also be connected to relevant third party services, for related information to be associated on a per proposal basis, so it is readily available to voting participants to analyze.
For example, in the hypothetical cases for Bitcoin and Ethereum Classic, the ECE dapp to manage their pools of development funds would be connected to the Bitcoin Improvement Proposal (BIP) process [4] and the Ethereum Classic Improvement Proposal (ECIP) process [5], both hosted on the Github website.
– The proof of stake execution layer (layer 2) is much more secure than the web interface and, as the ECE will require it for the proposal and voting mechanisms, supports higher volumes of transactions and higher performance, while being much cheaper for conducting these transaction intensive activities than proof of work blockchains.
In the case of groups who may use proof of stake or proof of authority (PoA) [6] white lists to manage staker or voter participant lists, those lists would be hosted in this layer to list stakers or members; compute their actions; host stakes; and tally staker or member voting.
This layer 2 also hosts the positive and negative ion tokens, and the proposal, intermediate, inhibitory, and excitatory contracts.
– The proof of work base layer (layer 1) is the lowest performance, more expensive, but most secure of all layers.
Due to these characteristics, it is the one that hosts the final and most important logic for the execution of pool decisions and payments, it receives and holds in custody the capital of the pools, performs high value settlements, makes the final payments to proposers, and stores permanent and auditable records of pool cash flows and actions.
The key of this layer is that it is highly secure and immutable [7].
As the ultimate layer where final decisions are executed and money paid out, layer 1 will eventually accumulate and learn more context information; such as reputation of participants and proposers, cash flow histories, pool capital balances, sequence of events and proposal entry dates and times for better prioritization and approval, inflow and outflow budget projections, and other external data; that open or affinity groups may require to make their pool management more intelligent and functional.
2. How it Works
The system is modular and designed where each type of smart contract is analogous to a type of neuron.
The dapp connects the pools of money, the pool operators, the voting participants, the proposers, and the consensus mechanism all in one place.
The open model would use a proof of stake voting mechanism in layer 2, where participants would deposit coins and get votes per coin.
The closed model, as demonstrated in diagram 2, would use a proof of authority mechanism, where all group members, or a subset of them, would be in charge of accepting new proposals, voting on them, and, ultimately, deciding the destination of the funds through their collective action.
Although similar parameters and proportions would work perfectly well in open communities, the model in diagram 2 is an example of a closed group with 600 participants.
2.1. Participants
The 600 participants referred to in this model are the proof of authority voters, or voting participants.
There are also proposers, who may be anyone, who enter proposals to solicit funding for their projects.
The open or affinity group who sets up and operates the pool, together with their authorized administrators, may be called the pool operators.
The administrators have a basic role of general housekeeping and making sure the procedures and rules of the pool on the Etherplan Consensus Engine are being followed by all types of users. They have no decision nor political role in the consensus engine. They are analogous to the editors in the Bitcoin and Ethereum Classic improvement proposal processes.
Voting participants are in charge of reviewing proposals and then using their allocated (+) and (-) ions per proposal to signal their position about them.
When proposers enter their proposals, they must enter all required data; such as proposal name, amount solicited, description, goals of the project, and rationale; and must enter a blockchain address where they want the funds to be sent to in case they are approved.
2.2. Proof of Authority White List
In this hypothetical case there are 600 participants, who are a decentralized group in charge of managing a pool of capital on the blockchain.
They are registered in the PoA white list that is hosted on both the layer 2 and layer 1 blockchains so that smart contracts on both layers can have the proper context information about the participants.
2.3. Ion Tokens
The positive and negative ion tokens are used by voting participants to signal support or rejection of proposals.
They are spontaneously created when a proposal is created and deployed to the blockchain. (+) or (-) ions are sent in regular token transactions to the address of each proposal.
In this model, there are 600 voting participants, therefore each proposal will have 600 (+) and 600 (-) ion tokens, one of each for each participating voter.
Participants may use one positive, one negative, or both ions per proposal at the same or different times during the proposal period. They may also withdraw the ions or choose to abstain by not sending any ions to proposals.
2.4. Proposal Contracts
The proposal contract; as well as its associated intermediate, excitatory, and inhibitory contracts; contains the metadata of the proposal considered for funding as originally entered.
All these contracts go on layer 2 and were generated, associated, and deployed from the web application at the time of creation of the proposal by a proposer or an admin. As said before, anyone may be a proposer and create proposals if the pool operators establish that as a policy.
A small proposal fee paid to the corresponding pool fund may be required to prevent DoS attacks.
In this example, the proposal is called proposal X.
During the proposal period, the participants can send their (+) or (-) ion tokens, or both, to the proposal contract of proposal X.
As the ions are received by the contract it goes performing the summation, also called primary summation in this instance, to eventually reach a net summation number.
The proposal contract has a threshold of 60+ for the proposal. This is 10% of the total voting participants in the pool. The reason to choose this threshold is to provide a minimum hurdle for approval in the case of a low participation rate, and to create a permanent margin of consensus for approval in the case of high participation.
This instance in the proposal contract, whether a proposal is approved or disapproved, is called the primary result.
The proposal period and proposal cycles may be a standard preferred by the group managing the pool of funds on the blockchain, or can be set by the proposer or administrator. It could typically be 30, 60, 90, or 180 days, measured in blockchain blocks, depending on the complexity and size of the proposal to be analyzed.
The primary result of the proposal needs to reach the specific threshold of 60+ to have a primary approval, if not it will have a primary disapproval and will not be paid out by the pool contract at the base layer, no matter what happens in the secondary and tertiary instances.
The net summation number, whether reaching the threshold or not, will be sent by the proposal contract as (+) or (-) ions to the intermediate, excitatory, and inhibitory contracts, if these last two were activated by the proposer, administrators, or voters.
Only positive ions may be sent to excitatory or inhibitory contracts and only if the primary summation result reached the threshold of 60+. If not, then the net summation number in ions, be it (+) or (-), may only be sent to the associated intermediate contract.
A primary approval does not mean a proposal will receive final approval as it depends, in part, on whether there are competing or complementary proposals down or upvoting it.
To be paid, proposals have to be approved by the pool contracts in the tertiary instance in layer 1 based on calculations that will be described in the corresponding point below.
All competing or complementary proposals must ideally end within the same cycle, so they may be better ranked and compared at the end of the proposal period.
2.5. Threshold
The threshold of proposal contracts is analogous to the threshold potential [8] in neural computation. Neurons have evolved the threshold potential over hundreds of millions of years, adjusting and fine tuning it to optimal levels before initiating action potentials, as a way to overcome environmental noise and to capture and process more relevant information.
As seen in figure 1 above, typical neurons have a resting state where the difference in electric potential between the interior and the exterior of cells across their cell membrane is usually -70 millivolts (mV). When they receive stimuli, that electric differential may be raised, through the exchange of ions with the cerebrospinal or extracellular fluid, to a level of -55 mV which is the threshold potential. When this threshold is reached, then the action potential is initiated, suddenly taking the electric potential up to +40 mV, also called a spike. This triggers a massive inflow of positive ions that turns into a succession or wave of actions along the neuron’s axon that eventually ends in the release of a neurotransmitter that is the molecule that serves as the message to the next neuron or cell.
After the action potential, the electric potential falls precipitously and usually undershoots to -80 mV before the neuron restores its resting state at -70 mV again.
In the ECE proposal contract, it may be said the resting state is 0 electrical charge. When voting participants send (+) or (-) ions to it, that serves as the stimuli to change its state. In the example in this paper, the most negative electrical charge that the contract may have is 600-. And, the most positive is 600+. However, if it reaches or crosses over the threshold of 60+ by the end of the proposal period, then the proposal will be considered to have a primary approval.
As may be observed in figure 1, during the proposal period, the electric level may actually oscillate within the 600+ and 600- range, which is analogous to how membrane potentials oscillate, sometimes reaching the threshold initiating an action potential and sometimes not [9] [10].
If the ECE proposal contract achieves a primary approval, it will also acquire the ability to send (+) ions to associated excitatory and inhibitory contracts to up or downvote complementary or competing proposals.
This type of summation computation and threshold potential model will eventually be integrated to all types of smart contracts in the Etherplan Consensus Engine as the system evolves and becomes more intelligent.
2.6. Excitatory and Inhibitory Contracts
Excitatory and inhibitory contracts for now serve as passthrough channels of net summation number ions and primary results. They do not perform any internal summation computation.
Excitatory and inhibitory contracts will only receive (+) ions from their associated proposal contracts in a number of 60+ or more because proposal contracts that were disapproved in the primary summation cannot send any ions to excitatory or inhibitory contracts.
Excitatory contracts resend the (+) ions they received as (+) ions to the target complementary proposal’s associated intermediate contracts. This is why they are named excitatory contracts.
Inhibitory contracts resend the (+) ions they received as (-) ions to the target competing proposal’s associated intermediate contracts. This is why they are named inhibitory contracts.
In other words, inhibitory contracts, like inhibitory interneurons, receive excitation, which activates their inhibitory action on other targeted contracts, as inhibitory interneurons inhibit target cells when they are excited.
Note that inhibitory contracts, although they do not perform any summation, they do change the charge of ions from (+) to (-).
In diagram 2 above the excitatory and inhibitory contracts are deployed, but not activated as they do not point to the intermediate contracts of other competing or complementary proposals. However, in the following section below, several scenarios are described where these types of contracts are, indeed, activated.
2.7. Intermediate Contracts
Intermediate contracts are deployed as associated contracts to specific proposal contracts when the original proposal package of contracts is deployed by the admin or the proposer to the blockchain.
The intermediate contract receives the net summation number from its associated proposal contract, and has ion channels open by default to receive (+) or (-) ions from excitatory or inhibitory contracts from other complementary or competing proposals.
As they go receiving the ions of both kinds from the contracts mentioned above, they go performing the summation, or secondary summation in this instance. When they reach a net summation number they will reach a secondary result for the proposal. This result may be positive or negative, and does not have to reach any threshold.
For example, if an intermediate contract received 88+ ions from its associated proposal contract, 65+ ions from an excitatory contract from a complementary proposal, and 85- ions from an inhibitory contract from a competing proposal, then it will reach a net summation number of [88+] + [65+] + [85-] = 68+.
The net summation number, or secondary result, will be then sent as (+) or (-) ions to the pool contract on the base layer blockchain. In the example above, 68+ ions would be sent to the pool contract for proposal X.
2.8. Pool Contracts
The pool contract is a permanent contract for each pool on the base layer blockchain that holds the custody of the funds of the group and calculates whether there was final rough consensus on proposals, and whether to pay or not their solicited amounts.
As the pool contract is the core and final logic of the Etherplan Consensus Engine, analogous to the central nervous system, it receives the secondary results and proposal metadata from all intermediate contracts, whether they are positive or negative ions.
When the pool contract receives ions from the different intermediate contracts, it computes the tertiary result, which may end as a payment or no payment to the proposer’s account.
The computation in this instance is a comparison or ranking of values of competing and complementary proposals, and then a check whether each individual proposal had a primary approval or disapproval in the primary instance.
In the case of proposals that have no competing or complementary proposals, they will be checked only for their primary result.
If proposals that have no competing or complementary proposals have an approved primary result, then the funds solicited will be paid out.
If the pool contract receives the results of competing proposals, then the one with highest secondary score will win, provided it also had an approved primary result. The losing ones will be rejected, even if they had approved primary results.
If there is a tie of competing proposals both will be rejected even if both were approved in the primary result.
If there are several interlinked competing proposals and complementary proposals (see the following section below for sample scenarios), the pool contracts will compare their scores and only select the top scorers with their complementary proposals, provided they all have primary approvals.
In normal circumstances, combined complementary proposals will have a tendency to win over individual competing proposals because they reinforce each other with (+) ions through excitatory contracts. However, as it happens in neuron dynamics, if an individual proposal happens to receive sufficient external stimuli in (+) ions, it can perfectly overcome the inhibitory force of complementary proposals, as seen in case 3.4. in the examples in the following section.
Complementary proposals may compete against other complementary proposals, in which case the pool contracts will compute an additional summation to see which side has a higher score, but will always pay funds only to proposals that had a primary approval.
Pool contracts in layer 1 will eventually accumulate and learn more context information; such as reputation of participants and proposers; cash flow histories; pool capital balances; sequence of events and proposal entry dates and times; inflow and outflow budget projections; and other external data, which may be used to make final payment decisions.
In all cases, the results together with metadata of proposals will be stored permanently in the base layer for future reference, analysis, and for pool contracts to have context information to judge reputation and other qualities of participants, proposers, and historic proposals.
3. Operation and Examples
The following points describe 4 different scenarios that may occur while processing proposals by the hypothetical group of 600 participants using the Etherplan Consensus Engine.
3.1. Single Case
Diagram 3 shows a single case where proposal X for funding a project was entered by a proposer. This proposal had no complementary or competing proposals active on the system.
Mechanically, when the proposer sent the proposal, the proposal, intermediate, excitatory, and inhibitory contracts were deployed to the execution layer or layer 2.
The voting participants sent 90+ and 10- ions during the proposal period. The proposal contract performed the primary summation, arriving at a net summation number of [90+] + [10-] = 80+. As this was above the 60+ threshold, the proposal got a primary approval.
As there were no complementary or competing proposals, the excitatory and inhibitory contracts were not activated.
When the proposal period ended, the proposal contract sent the net summation number of 80+ ions to the intermediate contract. The intermediate contract received them and performed the secondary summation in the next few blocks.
As there were no other complementary or competing proposals sending (+) or (-) ions to the intermediate contract, the secondary net summation number or secondary result was [80+] + [0+] + [0-] = 80+.
When the intermediate contract arrived at the secondary result, it sent 80+ ions and the metadata of the proposal to the pool contract. The pool contract received them and performed the tertiary computation in the next few blocks.
As there were no other complementary or competing proposals sending (+) or (-) ions to the pool contract, it did not rank any proposals, but checked whether the proposal X’s primary result of 80+ was below, at, or above the primary threshold.
As the primary result was above the primary threshold, then the pool contract paid the solicited funds in the proposal, either as a lump sum or a schedule of payments, to the address indicated in the metadata, which was entered by the proposer when the proposal was initially submitted.
Note that, in this example of a single case, already 102 transactions occurred in the cheaper, higher performance execution layer, or layer 2; and, only one transaction was sent to the more expensive, low performance, but more secure base layer, or layer 1. Additionally, two gas consuming summation computations were performed on layer 2, and only one ranking computation on layer 1. This already begins to show the great optimization that can be achieved by leveraging the performance vs security tradeoff between proof of stake and proof of work blockchains.
3.2. Double Case of Competing Proposals
Diagram 4 shows a double case of competing proposals where proposals X and Y were entered by two proposers.
Proposal X and Y got primary approvals of 65+ and 71+ respectively.
As both got primary approvals, both activated their inhibitory contracts to downvote each other and sent them 65+ and 71+ ions respectively. The inhibitory contracts transformed the (+) ions to (-) ions and sent them to their corresponding competing intermediate contracts.
The intermediate contracts received the ions from all sources, performed the secondary summation and sent the resulting ions, 6- and 6+ respectively, and the metadata of proposals X and Y, to the pool contract.
The pool contract received the ions and metadata from both competing proposals, ranked them and determined that proposal X lost, so it rejected it and did not pay its solicited funds.
Then, the pool contract checked and verified that proposal Y had a primary approval and proceeded to pay its solicited funds.
3.3. Triple Case of Competing and Complementary Proposals
Diagram 5 shows a triple case of proposals where proposals X, Y, and Z were entered by three proposers, Y and Z were complementary, and X was their competitor.
As seen in diagram 5 above, the three proposals got primary approvals. This means they used their associated excitatory and inhibitory contracts.
Proposals Y and Z upvoted each other by sending (+) ions to their excitatory contracts which were directed at each other.
Proposals X and Y downvoted each other by sending (+) ions to their inhibitory contracts which were directed at each other, and these transformed the ions to (-) ions.
The X, Y, and Z intermediate contracts received the ions from all sides and performed the secondary summations computing the net secondary results, which were 15-, 80+, and 140+ respectively. Then, they sent the results to the pool contract.
When the pool contract received the ions from the intermediate contracts, it performed the ranking computation [X: 15-] < [Y: 80+] < [Z: 140+], where proposal X was rejected for scoring lower than Y and Z. Then, it proceeded to verify that Y and Z had primary approvals, so it proceeded to pay their solicited funds.
From a layer 1 and layer 2 security vs performance tradeoff perspective, as may be observed in this case, there were approximately 350 transactions processed in the proof of stake execution layer, and only 4 in the proof of work base layer. In addition to this, much more gas was used in layer 2 for summation computations than in layer 1. If participation rates were higher these volume and computation differentials would be even greater as will be seen in the next case.
The only equal or similar data, computation, and storage objects on both layers was the proposal metadata and processing.
3.4. Triple Case of Competing and Complementary Proposals Where the Complementary Proposals Lost
Diagram 6 shows a scenario where complementary proposals lost against an individual proposal.
As seen in diagram 6, proposals Y and Z were the same as in the previous point, however proposal X received 388+ ions, which enabled it to have a much higher primary score and send a strong inhibitory signal to its opponents. This is analogous to what happens in real life neurons when competing to determine which one will send the stronger signal upstream to the central nervous system. Cross inhibition [11] is their way to increase sharpness and contrast [12] of the signal, which is what is referred to as “relevance” in this article.
When the pool contract received the ions from the intermediate contracts, it performed a summation of the Y and Z complementary proposals, and then ranked them against proposal X, determining that proposal X won. Then, it verified that X had a primary result at or above the primary threshold of 60+, which it did so it proceeded to pay the proposal’s solicited funds.
Note that in the execution layer, or layer 2, 858 transactions took place in this contest plus 6 summation computations. In the base layer, or layer 1, only 4 transactions plus 1 summation computation and 2 rank computations took place. This efficiency continues to show the advantages of the layered approach.
4. Conclusion
As the world moves to a more decentralized organization, with all sorts of groups and entities becoming more decentralized, the problem they will increasingly face is how to achieve rough consensus for more efficient decision making. This will likely include the management of pools of capital on the blockchain.
The solution proposed is to use neural computation as a model to construct a consensus engine that may use the basic algorithms neurons use to achieve rough consensus.
From how it works to examples of its operation are provided in this article.
In conclusion, the Etherplan Consensus Engine is an excellent tool for open or affinity groups and other kinds of decentralized entities to manage pools of money through rough consensus in a highly secure, efficient, transparent, and intelligent way.
References
[1] The Etherplan Consensus Engine – by Donald McIntyre: https://etherplan.com/2021/02/02/the-etherplan-consensus-engine/14989/
[2] Why Proof of Stake Is Less Secure Than Proof of Work – by Donald McIntyre: https://etherplan.com/2019/10/07/why-proof-of-stake-is-less-secure-than-proof-of-work/9077/
[3] Proof of Work Has Division of Power, Proof of Stake Does not – by Donald McIntyre: https://etherplan.com/2019/05/18/proof-of-work-has-division-of-power-proof-of-stake-does-not/7619/
[4] Bitcoin Improvement Proposal (BIP) process – by Luke Dashjr.: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
[5] Ethereum Classic Improvement Proposal (ECIP) process – by Wei Tang: https://ecips.ethereumclassic.org/ECIPs/ecip-1000
[6] Proof of Authority – by Binance Academy: https://academy.binance.com/en/articles/proof-of-authority-explained
[7] The Meaning of Blockchain Immutability – by Donald McIntyre: https://etherplan.com/2018/04/19/the-meaning-of-blockchain-immutability/6852/
[8] Threshold potential – by Wikipedia: https://en.wikipedia.org/wiki/Threshold_potential
[9] Neural oscillation – by Wikipedia: https://en.wikipedia.org/wiki/Neural_oscillation
[10] Subthreshold membrane potential oscillations – by Wikipedia: https://en.wikipedia.org/wiki/Subthreshold_membrane_potential_oscillations
[11] Lateral inhibition – by Wikipedia: https://en.wikipedia.org/wiki/Lateral_inhibition
[12] Contrast effect – by Wikipedia: https://en.wikipedia.org/wiki/Contrast_effect
