基于区块链的毕业设计The Etherplan Consensus Engine – 以太计划共识引擎

本文提供基于区块链的毕业设计国外最新区块链项目源码下载,包括solidity,eth,fabric等blockchain区块链,基于区块链的毕业设计The Etherplan Consensus Engine – 以太计划共识引擎 是一篇很好的国外资料

The Etherplan Consensus Engine

Abstract. The Etherplan Consensus Engine will help 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, or layer 2, for performance; and a proof of work blockchain as a base layer, or layer 1, for security, custody, settlements, and auditable record keeping.


You can find this paper in pdf format here: https://etherplan.com/ECE.pdf


The Etherplan Consensus Engine - 以太计划共识引擎This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.


1. Introduction

The goal of blockchains is trust minimization [1] so their systems don’t have to rely on central trusted authorities, corporations, or governments to manage their money, property, agreements, and information. The reasons to try to avoid these trusted third parties are to reduce agency risk, error, mass breaches, and outright fraud [2].

However, outside of the highly secure internal environment of operating blockchains it has been difficult for users, developers, and computer scientists to minimize the risk of centralized decision making when managing pools of funds or performing needed fixes and desired upgrades of the blockchain systems themselves.

Several methods are in use today for decision making in blockchain ecosystems. For example, on blockchains such as Bitcoin (BTC) and Ethereum Classic (ETC), a pure rough consensus [3] process is used to decide changes using what are called improvement proposal or standard processes [4] [5].

In networks such as Ethereum (ETH) or Zcash (ZEC), they use foundations [6] or blockchain based treasuries [7], which distribute funds for improvement proposals, centrally directing the roadmap of their systems. Treasuries to finance development have also been proposed for the Ethereum Classic blockchain [8 (a) (b)].

Other networks, such as Tezos (XTZ) and Dfinity (ICP), have implemented governance systems with internal democracies, where they use constitution-like or liquid voting mechanisms [9] [10] to decide and enforce change on their ecosystems at large.

The purpose of this paper is to describe the Etherplan Consensus Engine (ECE) which is a decision making system that tries to emulate, as closely as possible, the process of rough consensus practiced in Bitcoin and Ethereum Classic, but for groups in general to be able to make decisions on the deployment of capital hosted on blockchains.

These groups may be open communities, such as blockchain ecosystems, or affinity groups, such as decentralized teams, multinational entities, industry groups, or supranational organizations with diverse decision making participants.

If the functionality of ECE evolves as expected, it will even be useful for corporations, foundations, mutual funds, insurance companies, reinsurance markets, banking institutions, and other types of economic groups, who manage pools of capital as their core business, to securely make and execute the most optimal decisions on them.

The Etherplan Consensus Engine is a platform for groups to manage pools of money on decentralized blockchains. As such, the ECE is not an improvement proposal process per se. Actual proposals for change may be approved specifically for funding on the ECE, but whether those proposed changes eventually materialize, become implemented, or accepted and deployed on blockchains or other kinds of systems is a distinct and separate function.

For example, a funding proposal may be put forward by any proposer to a pool through the Etherplan Consensus Engine decentralized application (dapp) to finance a research and development project for a new technology. However, once the research and development project has concluded, whether such technology is actually adopted by its intended target system or users is decided in other mechanisms.

In summary, the role of ECE is to help open or affinity groups to reach rough consensus on proposals for funding in a secure, objective, transparent, and mechanical way to efficiently manage pools of capital on trust minimized blockchains.

2. Problem and Solution Logic

The problem is that to reach consensus in decentralized settings is difficult.

Just as in information theory [11] the main problem of communication is to solve the problem of noise, in decentralized decision making systems noise is represented by error, hackers, DoS attacks, cheating, permanent disagreement, and the risk of intervention by trusted third parties or malicious actors.

The other problem is the uncertainty of relevance. It is often not guaranteed that traditional voting mechanisms will produce the most relevant decisions or changes for groups or systems. Traditional voting actually does not seek truth or agreement. It is primarily a conflict minimization device, so decisions may be made with less friction and cost, and then all parties must accept them without further resistance.

That decisions may be made for the purpose of reducing conflict, but not to seek truth, or the best approximation of it, eventually creates a lack of trust in the voting mechanism, as constituents, who may be persistently marginalized or affected negatively by the decisions, will tend to exit or create even more conflict.

Rough consensus seeks relevance by focusing on truth, correctness, fit, and usefulness, or the best approximations of them. This is achieved by the justification, logic, and consistency of the proposals, not by the force of majorities.

The Etherplan Consensus Engine - 以太计划共识引擎

Diagram 1: Consensus reduces noise and increases relevance within a large information space.

But, how can a mechanism with smart contracts deployed on blockchains emulate, as closely as possible, the process of rough consensus?

As will be seen in the next section, the solution proposed in this paper is to try to imitate, as best as possible, how basic computational algorithms work in neural circuits to achieve consensus.

For hundreds of millions of years, neurons have evolved [12] to overcome noise in the environment and to assess relevance for survival. Consequently, neural circuits are designed to detect signal above noise and to overcome uncertain relevance [13].

As seen in diagram 1 above, the Etherplan Consensus Engine tries to emulate rough consensus in nature by helping groups to reduce noise and increase relevance in an environment where the information space, especially in open public systems and decentralized groups, is very large, but only a small subset of it is optimal for better decision making.

For example, if a decentralized team or community is responsible for a large sum of money on the blockchain; and needs to decide as best as possible on proposals for future action; just by the open nature of the system, there could be collusion between participants, approving bad or fraudulent proposals.

Not only that, but from the subset of not-bad and non-fraudulent proposals, the great majority may be undesirable for the goals and purpose of the group, beneficiaries, or underlying system.

To address this, the Etherplan Consensus Engine, being a consensus mechanism, as opposed to a democratic mechanism, has a bias to favor decisions that have broad consensual support and to not execute options without such support.

3. Neural Computation Analogy

How do neural circuits compute? Or, more abstractly, how do neural circuits reach consensus and make decisions?

As this author has explained in other articles [14], neuroscience is in a relatively early stage [15], as compared to other disciplines, when it comes to understanding its underlying subject: the brain.

It is not fully known, at a macro level, how the brain works, how the thought process works, or even less how abstractions such as consciousness work.

However, there are many things that are relatively well known. For example, the main molecular pathways within neurons, basic neural circuit algorithms, neuron anatomy and structure, and how cells and networks communicate, messaging each other, overcoming noise and increasing relevance.

It is not the goal of this paper to explain neurobiology in detail, but as seen in table 1 below, neural computation [16] is distributed between a peripheral and a central nervous system; receptors that sense stimuli, such as light, touch, sound, smell, and taste, are exposed to the environment; these stimuli are translated into flows of ions that change the electrochemical gradients within neuron cells through transmembrane ion channels; when neuron cells receive these stimuli, they perform summation computations [17] to overcome noise and asses relevance; and, if a threshold potential is reached, send messages to other cells, of which some may be lateral excitatory or inhibitory neurons, in the form of action potentials that release neurotransmitters.

The Etherplan Consensus Engine - 以太计划共识引擎

Table 1: The neural computation analogy to the Etherplan Consensus Engine.

The interactions of neurons with other neurons; of which some may be lateral excitatory or inhibitory cells, across the peripheral and central nervous systems; further reduce noise and increase relevance as they continue to filter the information space to identify the most pertinent signal. Thus, achieving rough consensus within and between neural circuits about what is the most pertinent information to make the next decision.

For example, as seen in diagram 2 below, the eye retina [18], which is part of the peripheral nervous system, has several layers of neurons which detect enormous quantities of information as light stimuli. However, from the cone and rod receptor cells to the ganglion cells, through several mechanisms of direct and lateral excitation and inhibition, they eventually send only 5% of the captured data to the central nervous system through the optic nerve [19].

The Etherplan Consensus Engine - 以太计划共识引擎

Diagram 2: Structure of the retina (source Britannica) and the Etherplan Consensus Engine model.

The central nervous system then further computes this information, cross checks it with contextual information and further logic, and eventually makes decisions through action selection pathways [20].

The ECE is analogous to neural computation because, as seen in table 1 and diagram 2, it is designed with a similar structure, algorithms, and pathways as neuron cells and circuits.

In the Etherplan Consensus Engine, a proof of stake (PoS) network [21] represents the peripheral nervous system because it receives large quantities of information from the external environment from participant activity, in the form of transactions, contract deployments, and contract calls, and performs heavy loads of computations to filter noise and increase relevance; a proof of work (PoW) blockchain [22] represents the central nervous system because it receives pre-filtered information from the proof of stake network, checks context information, and executes the most important rules and final logic of the system, which is used for decision making and further action, potentially mobilizing pool resources; the web app represents the external environment where participant’s activity is captured in the form of contract deployments, transactions, and contract calls; real ions in nervous systems are represented by positive (+) and negative (-) ion tokens on the blockchain; and, finally, neuron cells are represented by smart contracts, which receive (+) or (-) ion tokens from participants, perform summation computations, have a threshold potential to overcome noise and increase relevance, calculate the net summation number, and perform further action interacting with other smart contracts, such as the proposal, intermediate, inhibitory, excitatory, and pool contracts.

In the Etherplan Consensus Engine, as with neural computation, the internal computations within smart contracts, coupled with the interactions between contracts, have the overall effect of reducing noise and increasing relevance, thus achieving rough consensus for sound decision making.

4. The Decentralized Application

The Etherplan Consensus Engine product is a decentralized application, optimal for decentralized settings and decision making on funding proposals.

It is for groups of decision makers. These may be global blockchain ecosystems or affinity groups, regionally distributed teams, multinational entities, industry groups, or organizations with diverse decision making participants in different jurisdictions, nations, continents, or cultures.

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 3 below, 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 [23] [24]; 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 Etherplan Consensus Engine - 以太计划共识引擎

Diagram 3: Layered structure of the Etherplan Consensus Engine (ECE) decentralized application (dapp).

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 [25] and the Ethereum Classic Improvement Proposal (ECIP) process [26], 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) [27] 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 [28].

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.

This last characteristic, and the evolution of the ECE model, is what will likely enable it to be useful for corporations, foundations, mutual funds, insurance companies, reinsurance markets, banking institutions, and other types of economic groups, who manage pools of capital as their core business, to make and execute the most optimal decisions efficiently, in a trust minimized way, and transparently across national and cultural boundaries.

5. How it Works

The Etherplan Consensus Engine may be used by open ecosystems as blockchains, or closed affinity groups that use blockchains to manage pools of money.

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 4, 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.

The Etherplan Consensus Engine - 以太计划共识引擎

Diagram 4: The Etherplan Consensus Engine (ECE) basic model with a PoA example of 600 participants.

Although similar parameters and proportions would work perfectly well in open communities, the model in diagram 4 is an example of a closed group with 600 participants.

The different parts of the model are explained in the following points.

5.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.

The proposers may link their proposals to external systems to point voting participants to written content, discussions, or external improvement proposal systems where their project descriptions may reside.

5.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.

5.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.

5.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. For example, if it received 100+ and 30- ions, then the net summation number is 70+, if it received 65+ and 150- ions, then the net summation number is 85-.

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.

In other words, the result of the proposal may be approved or disapproved in this primary instance depending on whether it reached this minimum threshold.

For example, if a proposal had no (-) ions, but only got 50+ ions, it will not be funded. If there is more participation and both (+) and (-) ions are sent, and the net summation number is 60+, 97+, 320+, or 550+, then the proposal has a primary approval. If the net summation number is 59+, 33+, 277-, or 550-, then it has a primary disapproval.

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.

The sending of ions to other contracts is called action.

Note that contracts may spontaneously create ions. For example, if the primary result in the proposal contract was 60+, then it will send 60+ ions to its associated intermediate contract, and its associated excitatory and inhibitory contracts, if they were activated. This means that from an original 60+ net ions, a total 180+ were sent.

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.

This is, when proposal contracts have other proposal contracts that are competing or complementary, their excitatory and inhibitory contracts may be activated to down or upvote them in the secondary summation and secondary result. The secondary summation computation and result are performed in the associated intermediate contract.

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.

5.5. Threshold

The analogy of neural computation to the threshold, or threshold potential, in Etherplan Consensus Engine proposal contracts is that neurons have evolved the threshold potential [29] 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.

The Etherplan Consensus Engine - 以太计划共识引擎

Figure 1: Comparison of neuron action potentials (top 2 charts – source Wikipedia) and the ECE proposal contract primary approval voting process (bottom 2 charts), including resting state, possible oscillation scenarios, threshold, proposal expiration, and primary result.

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 [30] [31].

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.

The rationale for choosing the threshold of 10% of total participants in the Etherplan Consensus Engine was the result of several years of observation of the Ethereum Classic ecosystem [32]. The ETC community that is actively operating or managing many parts of the ecosystem is composed of around 600 individuals and entities. These are usually around 500 node operators, 15 miner pools, the 10 most active exchanges, around 15 core developers, and a group of around 55 investors and volunteer individuals who consistently participate in debates, community calls, and promote upgrades.

Of all these individuals and entities, usually around 10% are the ones who drive the main debates and form rough consensus in the network for the key decisions. The rest tend to observe on social media channels or follow the discussions on the ECIP process where much of the technical debates occur.

These roles have some rotation as some community members come and go, and new ones enter the day to day discussions and debates.

The 10% level mentioned above determined the 60+ voting threshold in this example for a proposal to get primary approval in the ECE.

It is analogous to the more or less 60 people who typically participate in decision making in ETC, and provides the minimum hurdle mentioned before for primary approval of proposals in the case of low participation rates. It also creates a permanent margin of consensus for primary approval in the case of higher participation, as the 60+ differential must be preserved in all cases to achieve primary approval.

Due to all of the above, the threshold in Etherplan Consensus Engine proposal contracts is a key security parameter to reach true rough consensus, rather than having naive voting mechanisms.

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.

5.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 (-).

Both the creation of ions and change of charge of ions are analogous to natural phenomena in the nervous system. This is because these types of  exchanges of molecules in neurons are primarily information messaging, rather than energy or matter transfers. Each cell locally produces or acquires the molecules or ions they use for messaging or performing their effects on postsynaptic cells.

In diagram 4 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.

5.7. Intermediate Contracts

Intermediate or intermediary 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+.

Intermediate contracts perform this secondary summation computation in the blocks right after the proposal contract period ended.

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.

5.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.

The final decision to pay or not pay solicited funds by proposals is called action.

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 they have a disapproved primary result, then the funds will not 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.

The pool operators may limit the number of possible complementary and competing proposals entered at one time to minimize complexity.

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 6.12. 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 perform this tertiary summation computation in the blocks right after the intermediate contract computations ended and were sent to them.

The consensus engine algorithm is very conservative as it must guarantee real rough consensus. In other words, a tie of competing proposals means there was no consensus, as contention means the opposite of consensus.

As said before, 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.

Payments may be limited by default by the group who are the pool operators. For example, a grant system of a university or public entity may have maximum payment value per proposal equivalent to $100,000.

Payments may be executed in the form of lump sums or scheduled payments.

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.

5.9. Funding Sources

The funding sources for pools and pool contracts depend on the nature or business of the group who created it.

They may be a treasury of a blockchain created with a miner tax; a community fund; the funds of a foundation; the working capital of a decentralized team of developers; a charity that receives regular donations; capital from a financial institution; or funds from any kind of entity who’s business or responsibility is to manage money on the blockchain securely, efficiently, and transparently, with a sound consensus mechanism to make decisions.

Pool operators may even use the Etherplan Consensus Engine dapp to create new pools from scratch and direct their funders, customers, donors, or any other funding sources to send the money directly to the pool contract on the blockchain.

6. Operation and Examples

In the following examples, simple cases are cases where participants send either a (+) or (-) ion to proposals, but not both. Complex cases are cases where participants, at least in one of the proposals, sent both the (+) and (-) ions to proposals, thus cancelling them out.

The ability to send one or both ions, and the freedom to withdraw them or abstain from voting, is similar to real ion flows in neurons when experiencing oscillations, polarization, depolarization, or hyper polarization prior to spiking or when initiating action potentials. Various kinds of ions are constantly being exchanged across the cell membrane through various types of ion channels.

It also reflects the real nature of discussions and debates during consensus formation for proposals, as participants tend to change or evolve their thinking and opinions as the context changes and as the arguments on all sides of the debate are heard and analyzed.

The key moment in the life cycle of proposals is the expiration of the proposal period and after the intermediate and pool contracts finished their computations a few blocks later, where the final result will determine whether final approval or disapproval were achieved.

For security reasons, in a proof of authority setting, a limited number of ions, in this case one (+) and one (-) ion, are distributed per participant. This is so no single participant may have sufficient votes to approve or disapprove individual proposals by themselves, thus forcing real consensus.

In proof of stake settings, this security guarantee is traded off for openness and privacy as any participant within and beyond the ecosystem can obtain and use ions based on their staked coin deposits, rather than by their identity, reputation, or historic participation.

As to the security vs performance trade off, note that all the voting transactions, inter-contract connections, inter-contract transactions, and summation computations are executed in the cheaper, more scalable, proof of stake, layer 2 blockchain. This is why it is called the execution layer.

Conversely, only the net secondary results from intermediate contracts, which generate a very small fraction of all transactions in the dapp, are sent to the pool contracts at the proof of work base layer, or layer 1 blockchain. In this more expensive but highly secure layer, the final proposal settlement payments are made and the metadata of proposals is stored for record keeping and context information.

All transaction fees are paid by proposers when entering and deploying proposals, and participants when entering ion transactions. When the subset of proposals that are approved are paid to proposer addresses, the fees are debited from the payments.

As per all of the above, the following points describe 12 different scenarios that may occur while processing proposals by the hypothetical group of 600 participants using the Etherplan Consensus Engine.

6.1. Simple Single Case

Diagram 5 shows a simple 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.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 5: Simple single case.

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 simple 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.

6.2. Special Case With Low Participation Rate

Diagram 6 shows a special simple 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.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 6: Simple single uncontroversial case with low participation rate.

It was special because it was uncontroversial as there were no (-) ions sent, and the proposal gained primary approval with a low participation rate of 60 voting participants sending 60+ ions, which barely reached the threshold of 60+.

However, this is more or less 100% of the usual subset of participants who are always active in the community forming rough consensus for new proposals, so being an uncontroversial case with low participation, it still gained a high level of rough consensus, as the rest of the community will likely follow and agree with this result.

All the steps of the process went as usual, and the pool contract paid the amount solicited in the proposal.

6.3. Simple Case Where the Proposal Was Not Funded

Diagram 7 shows a simple single case where proposal X for funding a project was entered by a proposer, but was not paid by the pool contract.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 7: Simple single case where the proposal was not paid.

The proposal got 33+ and 67- ions for a primary net summation number of 34-.

When the pool contract received the primary result, it performed the usual checks where it verified that the primary result was below the primary threshold, so it decided to not pay the solicited funds by the proposal.

Note that all the steps in the process continued to occur even if the proposal was rejected in the first instance. This is because there could have been entering complementary or competing proposals during the proposal period, which would have affected secondary and tertiary results as will be seen in later examples.

Also, the pool contract needs to receive all metadata and results of all historic proposals, regardless of their results, to keep as context information and for the permanent auditable record at the base layer.

6.4. Special Simple Cases With Full Participation

Diagrams 8 and 9 show two special simple cases with full participation where one was paid and the other was not.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 8: Special simple case with full participation where the proposal was paid.

The case in diagram 8 above is special because it demonstrates the maximum number of (-) ions, which is 270- in this example, a proposal may get in the primary instance to be able to reach the threshold of 60+ to gain primary approval when the participation rate is 100%, but participants sent only one of the two ions they have available.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 9: Special simple case with full participation where the proposal was not paid.

The case in diagram 9 above is special because it demonstrates what is the minimum number of (-) ions, which is 271- in this example, opponents of a proposal must send in the primary instance to be able to defeat it with a primary disapproval just under the threshold of 60+ when the participation rate is 100%, but participants sent only one of the two ions they have available.

6.5. Special Complex Cases With Full Participation

Diagrams 10 and 11 show two special complex cases with full participation where one was paid and the other was not.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 10: Special complex case with full participation where the proposal was paid.

The case in diagram 10 above is special because it demonstrates what is the maximum number of (-) ions, which is 540- in this example, a proposal may get in the primary instance to be able to reach the threshold of 60+ to gain primary approval when the participation rate is 100%, and many participants sent both (+) and (-) ions.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 11: Special complex case with full participation where the proposal was not paid.

The case in diagram 11 above is special because it demonstrates what is the minimum number of (-) ions, which is 541- in this example, opponents of a proposal must send in the primary instance to be able to defeat it with a primary disapproval just under the threshold of 60+ when the participation rate is 100%, and many participants sent both (+) and (-) ions.

It’s unlikely the two cases in this point will happen because it seems irrational that so many participants would send both their ions to a proposal, cancelling each other. However, these scenarios are possible according to the rules, so it’s worth noting them.

6.6. Simple Double Case of Competing Proposals

Diagram 12 shows a simple double case of competing proposals where proposals X and Y were entered by two proposers.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 12: Simple double case of competing proposals.

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.

6.7. Simple Double Case of Competing Proposals Where Both Got Primary Disapprovals

Diagram 13 shows a simple double case of competing proposals where proposals X and Y were entered by two proposers, but both got primary disapproval.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 13: Simple double case of competing proposals where both got primary disapprovals.

As X and Y were competing proposals, both had activated and directed their inhibitory contracts to each other. However, as both proposals were disapproved in the primary instance, then they could not send any ions to their corresponding inhibitory contracts because that can only be done if proposals get primary approvals.

However, the results were processed in the primary and the secondary instances, and both secondary results were sent to the pool contracts for final computation, verification, rejection, and record keeping.

6.8. Complex Double Case of Competing Proposals Where One Got a Primary Disapproval

Diagram 14 shows a complex double case of competing proposals where proposals X and Y were entered by two proposers, but one got primary disapproval.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 14: Complex double case of competing proposals where one got a primary disapproval.

The case is complex because proposal Y got 600+ ions and 600-. As said before, these cases are very unlikely, but are possible. As per the rules, proposal Y could not downvote proposal X through its inhibitory contract.

As proposal X had a primary approval, it just went through the motions, sent the negative ions to its competitor, and got a final tertiary approval by the pool contract, so the proposal was funded.

The reason why proposal X sent the negative ions to downvote its competitor is that it is never known until the end of a proposal period whether any proposal will win or lose the competition.

This means proposers must always identify and have their proposals upvote and downvote their complementary or competing proposals, as the final results are never known until the end.

6.9. Simple Triple Case of Competing and Complementary Proposals

Diagram 15 shows a simple 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.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 15: Simple triple case of competing and complementary proposals.

As seen in diagram 15 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 point 6.11. below.

The only equal or similar data, computation, and storage objects on both layers was the proposal metadata and processing.

6.10. Simple Triple Case of Competing and Complementary Proposals Where A Low Scorer Won

Diagram 16 shows the same scenario as the previous case, but where the scores of proposal X and Z were inverted to demonstrate that a lower primary approval scorer may win over a higher primary approval scorer when it is reinforced by a complementary proposal and its competitor is not.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 16: Simple triple case of competing and complementary proposals where a low scorer won.

As seen in diagram 16, the whole process went as usual, but proposal Z was on the winning side and got the funding it solicited.

Note that proposal Z actually had a primary approval, so it did pass the threshold initially. Something different happens in the next example.

6.11. Simple Triple Case of Competing and Complementary Proposals Where A Complementary Winner Was Not Funded

Diagram 17 shows the same scenario as the previous case, but where proposal Z was not funded.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 17: Simple triple case of competing and complementary proposals where a complementary winner was not funded.

As seen in diagram 17, proposal Z had a 100% voting participation rate. However it was not funded because, even if it won in the secondary and tertiary instances, it got a primary disapproval as its primary net summation result was 58+, below the 60+ threshold.

It’s important to note again that these final results can only be known by the end of the proposal period, so proposers, admins, and voting participants must remain alert at all times. It would have only taken 2+ ions or the change of heart of one voter, removing his (-) ion and sending a (+) ion to change the outcome.

As to the layer 1 and layer 2 security vs performance tradeoff, this competition would have had over 760 transactions plus several summation computations on the execution layer, and only 4 transactions plus fewer computations at the base layer.

6.12. Simple Triple Case of Competing and Complementary Proposals Where the Complementary Proposals Lost

Diagram 18 shows the same scenario as in point 6.9. above, but where the complementary proposals lost against an individual proposal.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 18: Simple triple case of competing and complementary proposals where the complementary proposals lost.

As seen in diagram 18, proposals Y and Z were the same as in point 6.9., 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 [33] is their way to increase sharpness and contrast [34] of the signal, which is what is repeatedly referred to as “relevance” in this paper.

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.

7. Instances, Contrast, and Context

The Etherplan Consensus Engine may be better understood from the perspective of instances. It has 3 instances for proposals to pass: The primary instance or proposal contract threshold, the secondary instance or intermediate contract summation of competing and complementary down and upvotes, and the tertiary instance or ultimate approval by the pool contract.

  • Primary instance (proposal contract): The 60+ threshold only applies in the first instance and helps reduce noise by imposing a high number of (+) votes over (-) votes, especially in case of low participation rates, which will likely be the most common scenario.

  • Secondary instance (intermediate contract): It adds and subtracts up or downvotes from complementary and competing proposals. This increases contrast between proposals or groups of proposals by expanding the differentials in the primary results. It helps in prioritization and numbing the lower score candidates so the focus remains in the few that have support and helps them even more if they have complementary proposals (e.g. Taproot + Graftroot + Miniscript [35] would all complement each other in Bitcoin, likely killing any competition. In ETC, Keccak256 + Flyclient + NiPoPoWs + Checkpointing would kill ETChash + MESS [36]). The enhanced contrast also helps the pool contract in clearly discarding losers and focusing on winners. This augmenting contrast feature will be even more important in the future when the pool contract also operates with a threshold as does the proposal contract now.

  • Tertiary instance (pool contract): It adds up all complementary proposals, then ranks them against other complementary proposals, and discards the losers. This means that all proposals in losing complementary groups are discarded even if they individually had primary approval. It also uses context information; such as what is the cash balance of the pool, or if a proposal is requesting money above a certain amount; to decide whether to discard or pay proposals. In the future, it will use more context information, each with thresholds as well, such as reputation of voters and proposers, etc.

All of the above mimics how groups of neurons (or the brain for that matter) work and decide on things like the color of objects, focusing on sounds, attractiveness of mates, or how much effort or work will be put between alternative options depending on the contrast of expected rewards.

In what could be described as a golden rule, if after the three instances described above there is a tie between pairs or larger groups of proposals, they all get discarded because that means there was no rough consensus.

This author believes that the 2017 SegWit2x proposal [37] would have won against the big blockers in this consensus engine because the SegWit2x side may have blocked big blockers by reducing their primary result, perhaps making them not meet the threshold. But to understand the possible scenarios it would be beneficial to run thousands of random simulations.

In any case, for now, the ECE is not for concrete systems upgrades, but just to fund them, or, in general, for any kind of decentralized group to decide on any kind of funding proposals.

With advanced context information, even insurance and reinsurance markets such as Lloyd’s of London could operate an ECE pool with their over $100 billion insurance and reinsurance reserve fund [38].

8. Primary Summation Space

The primary summation space represented in figure 2 below is the total number of possible outcomes of the voting mechanism in the primary instance on the proposal contracts. The space size depends on the distribution of (+) and (-) ions per participant; the ability for participants to use both to vote for single proposals; and the number of participants. Due to the primary approval threshold, a subset of the summation space may produce primary approval outcomes.

The Etherplan Consensus Engine - 以太计划共识引擎
Figure 2: The primary summation space and the primary approval outcomes subset.

In the hypothetical case in this paper of 600 participants with one (+) and one (-) ions each, and the possibility of using both or abstaining, the Etherplan Consensus Engine primary summation space size of total possible outcomes is 601 x 601 = 361,201.

With a primary approval threshold of 60+ ions, the possible primary approval outcomes are (541 x 541) / 2 = 146,340.5, or 40.51% of the primary summation space.

To make ECE more constrained or flexible, the threshold may be adjusted higher or lower depending on the profile of the group setting up the pool and relative to its expected voting participation rate.

9. Adjustable Parameters

Each open or affinity group who becomes a pool operator on the Etherplan Consensus Engine dapp may have their own policies. For example, the treasury of a blockchain system may be very open, accepting any participants or proposers to the system; or the pool managed by a charity may have a fixed set of participants, proposers, defined proposal types, and targeted beneficiaries.

As described previously in this paper, some parameters, such as the primary threshold potential; the ability to use one or both (+) (-) ion charges for voting per proposal; proposal periods; whether voting participants may be anyone or selected individuals; whether proposers may be anyone or selected individuals; and payment limits and format may be adjusted to suit each pool operator’s needs.

Pool operators may have several pools under management on the ECE with different styles and for different purposes.

Changes to some sensitive parts or rules of the consensus engine per group or pool may be entered as proposal contracts on the system itself. The difference will be that their result will not affect payments to projects, but just indicate that there is consensus to make changes to the pool rules.

Examples of these kinds of changes may be changes in the openness or closeness of the pool, e.g. from a proof of authority to a proof of stake mechanism and vice versa; additions or deletions in the proof of authority white list; number of allowed participants; or even the liquidation and termination of the pool.

10. Managing Complexity

As the complexity of the nervous system, complexity in the ECE may rise very quickly as individual smart contract functionality and the system in general evolve. However, with a gradual approach, it may become very useful to manage more intricate group decision processes.

For example, diagram 19 below is a representation of a hypothetical case where multiple clusters of competing and complementary decisions may be managed by pool operators on the system.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 19: Hypothetical case with multiple clusters of competing and complementary proposals.

With careful research and development of the rules and interrelations of smart contracts that mimic neural circuits, and beginning from a very basic and simple starting point, as in the sample model in this paper, complexity risk may be managed, while greatly increasing the intelligence and usefulness of the system.

11. Modularity

As seen in all the sections, tables, figures, and diagrams in this paper, the Etherplan Consensus Engine has a very high level of vertical and horizontal modularity.

Vertical modularity means that the system is layered to adapt and adjust each part to the security, performance, and economic needs of its functionality. Horizontal modularity means the division of specific functions between smart contracts mimicking neuron specialization.

Division of labor and specialization between smart contracts with discrete functions permits easier design, research and development, management, understanding, and evolution of the system. It also enables easier addition, replacement, or adjustment of features or parameters by users and pool operators to adapt them to their needs.

From a technical perspective, this level of modularity facilitates auditing, easier debugging, reusability of code, readability, and all these characteristics together add up to greater reliability.

Greater reliability helps significantly in managing complexity.

12. Risks

In its current state as described in this paper, the Etherplan Consensus Engine presents two centralization risks explained with their possible solutions in the following points.

12.1. 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 solutions:

  • Idea 1: Proposals may be entered naked (unrelated to any other proposals). Then, voters can direct votes with instructions per vote to excite and/or inhibit other target proposals. If the votes to excite and/or inhibit other target proposals reach a certain threshold, say 30+, then the excitation and/or inhibition get directed to those target proposals. Note that if the entire proposal did not reach its own threshold for primary approval, it would not excite or inhibit any proposal in any case.

  • Idea 2: Make all proposals inhibit all other proposals, and make the ones with the most stimuli win.

  • Idea 3: Use the same manual method on Github [39] as the Bitcoin BIP and Ethereum Classic ECIP processes, where proposals are initially pull requests (PRs) [40] that are revised and merged by the editors. In the ECE, the admins would do the same with new funding proposals, but would also associate them by proposer request and/or the admin’s own judgement and analysis. Then, proposals can be merged [41], which means they would also be entered on the execution layer (layer 2) blockchain for voting.

Author’s opinion:

In this ECE early stage, it would be better to do the entry and association of proposals manually as in idea 3, as the Bitcoin BIP and Ethereum Classic ECIP processes are. The proposals may start as pull requests (PRs) on Github, and then the pool admins can clean and polish them and associate them, just like ECIPs and BIPs today.

In a future ECE version, autonomous or rough consensus based automated association solutions may be integrated.

12.2. 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’s proof of stake, then the problem is 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 PoA pool that may be completely trust minimized, but the Bitcoin BIP and Ethereum Classic ECIP processes work with groups of relatively known developers and editors, anyway.

In the hypothetical case of ETC, there would have to be an initial stage where all regular members of the ecosystem are “inducted” into the PoA 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. 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 always contacted to make upgrades [42].

All of the above could announce a public key so they would be inducted. When all of the above were inducted they would become the “genesis list”.

Once there is a large amount of participants, then a threshold may be set. It is 60+ in this paper, but it may be different based on the size of the PoA 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 PoA 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).

13. Conclusion

As the world will move 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.

These groups may be open communities, such as blockchain ecosystems, or affinity groups, such as decentralized teams, multinational entities, industry groups, or supranational organizations with diverse decision making participants.

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.

The Etherplan Consensus Engine dapp described in this paper will help groups and organizations of any kind to manage pools of money on the blockchain making and executing the most optimal decisions efficiently, in a trust minimized way, and transparently across national and cultural boundaries.

From how it works, from proposal entry to funding, and examples of its operation are provided in this paper, including various typical, edge, and improbable but possible cases.

The Etherplan Consensus Engine  may be customized up to a certain extent to the needs of pool operators and the profiles of their groups.

By managing complexity, and even leveraging it, the system’s functionality and usefulness may be greatly increased. It is possible that, as the platform evolves, corporations, foundations, mutual funds, insurance companies, reinsurance markets, banking institutions, and other types of economic groups, who manage pools of capital as their core business, will find it useful to make better decisions, more securely, and efficiently.

By mimicking the nervous system and neural circuits, the ECE mechanism actually becomes more simplified and highly modularized, creating specialized smart contracts that divide labour between them in different computational layers.

In these layers the distribution of risk and computational load and cost may be greatly optimized.

In conclusion the Etherplan Consensus Engine is an excellent tool for open or affinity groups and other kinds of entities to manage pools of money through rough consensus in a highly secure, efficient, transparent, and intelligent way.

References

[1] Satoshi Nakamoto Mentioned Trust Minimization 14 Times in the Bitcoin White Paper – by Donald McIntyre: https://etherplan.com/2020/02/29/satoshi-nakamoto-mentioned-trust-minimization-14-times-in-the-bitcoin-white-paper/10210/

[2] Trusted Third Parties Are Security Holes – by Nick Szabo: https://nakamotoinstitute.org/trusted-third-parties/

[3] Rough consensus – by Wikipedia: https://en.wikipedia.org/wiki/Rough_consensus

[4] Bitcoin Improvement Proposals – by Bitcoin Wiki: https://en.bitcoinwiki.org/wiki/Bitcoin_Improvement_Proposals

[5] Standards process – by IETF: https://www.ietf.org/standards/process/

[6] Ethereum Foundation: https://ethereum.org/en/foundation/

[7] A five-member board to control $36 million treasury for Zcash – by Shaurya Malwa: https://decrypt.co/39105/a-five-member-board-to-control-36-million-treasury-for-zcash

[8 (a)] Ethereum Classic Treasury System Proposal – ECTS – by IOHK – The Veritas Team – Dmytro Kaidalov, Lyudmila Kovalchuk, Andrii Nastenko, Mariia Rodinko, Oleksiy Shevtsov, Roman Oliynykov: https://etherplan.com/a-proposal-for-an-Ethereum-Classic-treasury-system.pdf

[8 (b)] Proto Treasury System – p-ECTS – by Julian Mendiola, Nicolas Tallar, Brian McKenna: https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1098.md

[9] Tezos: Superior Governance and Use Cases – by Kathleen Breitman: https://www.gemini.com/cryptopedia/what-is-tezos-xtz-governance-use-cases

[10] The DFINITY “Blockchain Nervous System” – by Dominic Williams: https://medium.com/dfinity/the-dfinity-blockchain-nervous-system-a5dd1783288e

[11] A  Mathematical Theory of Communication – by C. E. Shannon: http://etherplan.com/a-mathematical-theory-of-communication.pdf

[12] Early evolution of neurons – by William B. Kristan Jr.: https://www.sciencedirect.com/science/article/pii/S0960982216304894

[13] Neural circuit – by Wikipedia: https://en.wikipedia.org/wiki/Neural_circuit

[14] Noise, Signal, Skepticism, and Trust – by Donald McIntyre: https://etherplan.com/2020/12/15/noise-signal-skepticism-and-trust/14193/

[15] Questions from 1920 Still Haunt Neuroscience – by Neuroskeptic: https://www.discovermagazine.com/mind/questions-from-1920-still-haunt-neuroscience

[16] Nervous system – by Wikipedia: https://en.wikipedia.org/wiki/Nervous_system

[17] Summation (neurophysiology) – by Wikipedia: https://en.wikipedia.org/wiki/Summation_(neurophysiology)

[18] The retina – by Britannica: https://www.britannica.com/science/human-eye/The-retina

[19] Neural Computation: Markus Meister at TEDxCaltech: https://youtu.be/obAHnwp9tOM

[20] Action selection – by Tony J. Prescott, Scholarpedia: http://www.scholarpedia.org/article/Action_selection

[21] Proof of Stake (PoS) – by Jake Frankenfield: https://www.investopedia.com/terms/p/proof-stake-pos.asp

[22] Why Proof of Work Based Nakamoto Consensus Is Secure and Complete – by Donald McIntyre: https://etherplan.com/2020/03/21/why-proof-of-work-based-nakamoto-consensus-is-secure-and-complete/10509/

[23] 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/

[24] 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/

[25] Bitcoin Improvement Proposal (BIP) process – by Luke Dashjr.: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

[26] Ethereum Classic Improvement Proposal (ECIP) process – by Wei Tang: https://ecips.ethereumclassic.org/ECIPs/ecip-1000

[27] Proof of Authority – by Binance Academy: https://academy.binance.com/en/articles/proof-of-authority-explained

[28] The Meaning of Blockchain Immutability – by Donald McIntyre: https://etherplan.com/2018/04/19/the-meaning-of-blockchain-immutability/6852/

[29] Threshold potential – by Wikipedia: https://en.wikipedia.org/wiki/Threshold_potential

[30] Neural oscillation – by Wikipedia: https://en.wikipedia.org/wiki/Neural_oscillation

[31] Subthreshold membrane potential oscillations – by Wikipedia: https://en.wikipedia.org/wiki/Subthreshold_membrane_potential_oscillations

[32] The Ethereum Classic Ecosystem Explained – by Donald McIntyre: https://etherplan.com/2020/01/28/the-ethereum-classic-ecosystem-explained/9680/

[33] Lateral inhibition – by Wikipedia: https://en.wikipedia.org/wiki/Lateral_inhibition

[34]  Contrast effect – by Wikipedia: https://en.wikipedia.org/wiki/Contrast_effect

[35] Bitcoin’s Legal Hypertextualism – by Donald McIntyre: https://etherplan.com/2020/10/08/bitcoins-legal-hyper-textualism/12940/

[36] Ethereum Classic Protocol Compact 2020 –  by Donald McIntyre: https://etherplan.com/2020/09/27/ethereum-classic-protocol-compact-2020/12822/

[37]  SegWit2x – by Bitcoin Wiki: https://en.bitcoin.it/wiki/SegWit2x

[38] Lloyd’s of London – by Wikipedia: https://en.wikipedia.org/wiki/Lloyd%27s_of_London

[39] GitHub – by Wikipedia: https://en.wikipedia.org/wiki/GitHub

[40] About pull requests – by GitHub: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

[41] About pull request merges – by GitHub: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges

[42] Example of list of ETC nodes who are contacted every time there is an upgrade – by Donald McIntyre: https://docs.google.com/spreadsheets/d/1Q9c-q6J0zAJxqpaXxPetJQbcsb-soTIk-Xfnc-h041s/edit?usp=sharing


The Etherplan Consensus Engine

抽象的。Etherplan共识引擎将帮助任何类型的分散集团以安全、客观、透明和机械的方式使用粗略共识管理区块链blockchain上的资金池。该系统模拟神经计算,其中智能合约的内部计算,加上合约之间的相互作用,具有降低噪音和提高合理决策相关性的总体效果。参与者、管理者和提议者与他们管理或募集资金的资金池相连,形成一个三层模块化系统,以一种高成本效益的方式优化风险和计算负载的分配。它通过利用web界面来实现更好的用户体验;利用权益证明区块链blockchain作为执行层,或第2层来实现性能;利用工作证明区块链blockchain作为基础层,或第1层来实现安全性、托管、结算和可审计记录保持。


您可以在这里找到pdf格式的论文:https://etherplan.com/ECE.pdf


The Etherplan Consensus Engine - 以太计划共识引擎本作品根据Creative Commons Attribution Share4.0国际许可证获得许可。


1. Introduction

The goal of blockchains is trust minimization [1] so their systems don’t have to rely on central trusted authorities, corporations, or governments to manage their money, property, agreements, and information. The reasons to try to avoid these trusted third parties are to reduce agency risk, error, mass breaches, and outright fraud [2].

然而,在高度安全的区块链blockchain运营内部环境之外,用户、开发人员和计算机科学家在管理资金池或对区块链blockchain系统本身进行必要的修复和升级时,很难将集中决策的风险降至最低。

区块链blockchain生态系统中,目前有几种方法可用于决策。例如,在BTC(BTC)和以太坊eth经典(ETC)等区块链blockchain上,使用纯粹的粗略共识[3]流程,使用所谓的改进建议或标准流程[4][5]来决定变更。

以太坊eth(ETH)或Zcash(ZEC)等网络中,他们使用基金会[6]或基于区块链blockchain的国债[7],这些基金会为改进方案分配资金,集中指导其系统的路线图。为以太坊eth经典区块链blockchain[8(a)(b)]的开发融资的国债也被提议。

其他网络,如Tezos(XTZ)和Dfinity(ICP),已经实施了内部民主的治理体系,他们使用类似宪法的或流动的投票机制[9][10]来决定和实施整个生态系统的变革。

本文的目的是描述Etherplan共识引擎(ECE),它是一个决策系统,试图尽可能模拟BTC以太坊eth经典中实践的粗略共识过程,但对于一般群体来说,它能够对区块链blockchain上托管的资本的部署做出决策。

这些群体可能是开放社区,如区块链blockchain生态系统,或亲缘群体,如分散的团队、跨国实体、行业团体或具有不同决策参与者的超国家组织。

如果欧洲经委会的功能如预期发展,它甚至将有助于公司、基金会、共同基金、保险公司、再保险市场、银行机构和其他类型的经济集团,他们将资金池作为其核心业务进行管理,以安全地对其作出和执行最优化的决策。

Etherplan共识引擎是一个平台,供集团管理分散区块链blockchain上的资金池。因此,欧洲经委会本身不是一个改进建议进程。实际的变革建议可能会专门为欧洲经委会的供资而获得批准,但这些提议的变革是否最终实现、得到实施,或是否被接受并部署在区块链blockchain或其他类型的系统上,是一个独特而独立的职能。

例如,任何提案人都可以通过Etherplan共识引擎分散应用程序(dapp)向资金池提出资助提案,以资助新技术的研发项目。然而,一旦研究和开发项目结束,这种技术是否被预期的目标系统或用户实际采用,则由其他机制决定。

总而言之,欧洲经委会的作用是帮助开放或慈善团体以安全、客观、透明和机械的方式就筹资建议达成初步共识,以有效管理信托区块链blockchain上的资金池。

2. Problem and Solution Logic

The problem is that to reach consensus in decentralized settings is difficult.

正如在信息论[11]中,通信的主要问题是解决噪声问题,在分散决策系统中,噪声表现为错误、黑客、拒绝服务攻击、欺骗、永久性分歧以及受信任的第三方或恶意行为者干预的风险。另一个问题是相关性的不确定性。通常不能保证传统的投票机制会对团体或系统产生最相关的决定或改变。传统的投票实际上并不寻求真相或一致意见。它主要是一种冲突最小化的手段,因此可以在较少摩擦和成本的情况下作出决定,然后各方必须接受这些决定,而不产生进一步的阻力。

决策的目的可能是为了减少冲突,但不是为了寻求真相,或寻求真相的最佳近似值,这最终会造成对投票机制缺乏信任,因为选民可能长期被边缘化或受到决策的负面影响,他们往往会退出或产生更多的冲突。

粗略的共识通过关注真实性、正确性、适合性和有用性,或它们的最佳近似值来寻求相关性。这是通过提案的合理性、逻辑性和一致性来实现的,而不是通过多数人的力量。

The Etherplan Consensus Engine - 以太计划共识引擎

图1:共识在大信息空间中减少噪音并增加相关性。

但是,一个在区块链blockchain上部署智能合约的机制如何尽可能地模拟大致共识的过程?

如下一节所述,本文提出的解决方案是尽可能地模拟基本计算算法在神经电路中的工作方式,以达成共识。

数亿年来,神经元不断进化[12],以克服环境中的噪音,并评估其与生存的相关性。因此,神经电路被设计用来检测高于噪声的信号并克服不确定的相关性[13]。

如上图1所示,Etherplan共识引擎试图模拟粗糙的共识,在信息空间非常大的环境中,特别是在开放的公共系统和分散的群体中,帮助群体减少噪音,提高相关性,但只有一小部分对更好的决策是最佳的。

例如,如果一个分散的团队或社区负责区块链blockchain上的一大笔资金;并且需要尽可能最好地决定未来行动的建议;仅凭系统的开放性,参与者之间可能存在串通,批准不好的或欺诈性的建议。

不仅如此,从不坏和非欺诈性提案的子集来看,绝大多数提案可能不符合集团、受益人或基础系统的目标和宗旨。

为了解决这个问题,Etherplan共识引擎作为一种共识机制而不是民主机制,倾向于支持具有广泛共识支持的决策,并且在没有这种支持的情况下不执行选项。

正如作者在其他文章[14]中解释的那样,与其他学科相比,神经科学在理解其基础学科:大脑方面还处于相对早期的阶段[15]。在宏观层面上,大脑是如何工作的,思维过程是如何工作的,更不用说意识等抽象概念是如何工作的了。然而,有许多事情相对来说是众所周知的。例如,神经元内的主要分子通路,基本的神经回路算法,神经元的解剖和结构,以及细胞和网络如何交流,相互传递信息,克服噪音和增加相关性。

3. Neural Computation Analogy

How do neural circuits compute? Or, more abstractly, how do neural circuits reach consensus and make decisions?

本文的目的不是详细解释神经生物学,但如下面的表1所示,神经计算[16]分布在外周神经系统和中枢神经系统之间;感受刺激(如光、触觉、声音、嗅觉和味觉)的受体暴露在环境中;这些刺激被转化为信息流通过跨膜离子通道改变神经元细胞内电化学梯度的离子;当神经元细胞接收到这些刺激时,它们进行求和计算[17]以克服噪声并评估相关性;如果达到阈值电位,则向其他细胞发送信息,其中一些可能是外侧兴奋性或抑制性神经元,以动作电位的形式释放神经递质。

The Etherplan Consensus Engine - 以太计划共识引擎

表1:以太计划共识引擎的神经计算类比。

神经元与其他神经元的相互作用;其中一些可能是外周神经和中枢神经系统的侧向兴奋性或抑制性细胞;当它们继续过滤信息空间以识别最相关的信号时,进一步降低噪声并增加相关性。因此,在神经回路内部和神经回路之间就什么是下一个决策的最相关信息达成大致共识。

例如,如下图2所示,眼视网膜[18]是外周神经系统的一部分,它有几层神经元,可以检测大量信息作为光刺激。然而,从视锥和视杆受体细胞到神经节细胞,通过几种直接和侧向的兴奋和抑制机制,它们最终仅通过视神经将5%的捕获数据发送到中枢神经系统[19]。

The Etherplan Consensus Engine - 以太计划共识引擎

图2:视网膜结构(来源大英百科全书)和Etherplan共识引擎模型。你知道吗

For example, as seen in diagram 2 below, the eye retina [18], which is part of the peripheral nervous system, has several layers of neurons which detect enormous quantities of information as light stimuli. However, from the cone and rod receptor cells to the ganglion cells, through several mechanisms of direct and lateral excitation and inhibition, they eventually send only 5% of the captured data to the central nervous system through the optic nerve [19].

The Etherplan Consensus Engine - 以太计划共识引擎

Diagram 2: Structure of the retina (source Britannica) and the Etherplan Consensus Engine model.

The central nervous system then further computes this information, cross checks it with contextual information and further logic, and eventually makes decisions through action selection pathways [20].

The ECE is analogous to neural computation because, as seen in table 1 and diagram 2, it is designed with a similar structure, algorithms, and pathways as neuron cells and circuits.

In the Etherplan Consensus Engine, a proof of stake (PoS) network [21] represents the peripheral nervous system because it receives large quantities of information from the external environment from participant activity, in the form of transactions, contract deployments, and contract calls, and performs heavy loads of computations to filter noise and increase relevance; a proof of work (PoW) blockchain [22] represents the central nervous system because it receives pre-filtered information from the proof of stake network, checks context information, and executes the most important rules and final logic of the system, which is used for decision making and further action, potentially mobilizing pool resources; the web app represents the external environment where participant’s activity is captured in the form of contract deployments, transactions, and contract calls; real ions in nervous systems are represented by positive (+) and negative (-) ion tokens on the blockchain; and, finally, neuron cells are represented by smart contracts, which receive (+) or (-) ion tokens from participants, perform summation computations, have a threshold potential to overcome noise and increase relevance, calculate the net summation number, and perform further action interacting with other smart contracts, such as the proposal, intermediate, inhibitory, excitatory, and pool contracts.

In the Etherplan Consensus Engine, as with neural computation, the internal computations within smart contracts, coupled with the interactions between contracts, have the overall effect of reducing noise and increasing relevance, thus achieving rough consensus for sound decision making.

4. The Decentralized Application

The Etherplan Consensus Engine product is a decentralized application, optimal for decentralized settings and decision making on funding proposals.

It is for groups of decision makers. These may be global blockchain ecosystems or affinity groups, regionally distributed teams, multinational entities, industry groups, or organizations with diverse decision making participants in different jurisdictions, nations, continents, or cultures.

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 3 below, 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 [23] [24]; 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 Etherplan Consensus Engine - 以太计划共识引擎

Diagram 3: Layered structure of the Etherplan Consensus Engine (ECE) decentralized application (dapp).

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 [25] and the Ethereum Classic Improvement Proposal (ECIP) process [26], 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) [27] 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 [28].

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.

This last characteristic, and the evolution of the ECE model, is what will likely enable it to be useful for corporations, foundations, mutual funds, insurance companies, reinsurance markets, banking institutions, and other types of economic groups, who manage pools of capital as their core business, to make and execute the most optimal decisions efficiently, in a trust minimized way, and transparently across national and cultural boundaries.

5. How it Works

The Etherplan Consensus Engine may be used by open ecosystems as blockchains, or closed affinity groups that use blockchains to manage pools of money.

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 4, 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.

The Etherplan Consensus Engine - 以太计划共识引擎

Diagram 4: The Etherplan Consensus Engine (ECE) basic model with a PoA example of 600 participants.

Although similar parameters and proportions would work perfectly well in open communities, the model in diagram 4 is an example of a closed group with 600 participants.

The different parts of the model are explained in the following points.

5.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.

The proposers may link their proposals to external systems to point voting participants to written content, discussions, or external improvement proposal systems where their project descriptions may reside.

5.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.

5.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.

5.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. For example, if it received 100+ and 30- ions, then the net summation number is 70+, if it received 65+ and 150- ions, then the net summation number is 85-.

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.

In other words, the result of the proposal may be approved or disapproved in this primary instance depending on whether it reached this minimum threshold.

For example, if a proposal had no (-) ions, but only got 50+ ions, it will not be funded. If there is more participation and both (+) and (-) ions are sent, and the net summation number is 60+, 97+, 320+, or 550+, then the proposal has a primary approval. If the net summation number is 59+, 33+, 277-, or 550-, then it has a primary disapproval.

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.

The sending of ions to other contracts is called action.

Note that contracts may spontaneously create ions. For example, if the primary result in the proposal contract was 60+, then it will send 60+ ions to its associated intermediate contract, and its associated excitatory and inhibitory contracts, if they were activated. This means that from an original 60+ net ions, a total 180+ were sent.

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.

This is, when proposal contracts have other proposal contracts that are competing or complementary, their excitatory and inhibitory contracts may be activated to down or upvote them in the secondary summation and secondary result. The secondary summation computation and result are performed in the associated intermediate contract.

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.

5.5. Threshold

The analogy of neural computation to the threshold, or threshold potential, in Etherplan Consensus Engine proposal contracts is that neurons have evolved the threshold potential [29] 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.

The Etherplan Consensus Engine - 以太计划共识引擎

Figure 1: Comparison of neuron action potentials (top 2 charts – source Wikipedia) and the ECE proposal contract primary approval voting process (bottom 2 charts), including resting state, possible oscillation scenarios, threshold, proposal expiration, and primary result.

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 [30] [31].

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.

The rationale for choosing the threshold of 10% of total participants in the Etherplan Consensus Engine was the result of several years of observation of the Ethereum Classic ecosystem [32]. The ETC community that is actively operating or managing many parts of the ecosystem is composed of around 600 individuals and entities. These are usually around 500 node operators, 15 miner pools, the 10 most active exchanges, around 15 core developers, and a group of around 55 investors and volunteer individuals who consistently participate in debates, community calls, and promote upgrades.

Of all these individuals and entities, usually around 10% are the ones who drive the main debates and form rough consensus in the network for the key decisions. The rest tend to observe on social media channels or follow the discussions on the ECIP process where much of the technical debates occur.

These roles have some rotation as some community members come and go, and new ones enter the day to day discussions and debates.

The 10% level mentioned above determined the 60+ voting threshold in this example for a proposal to get primary approval in the ECE.

It is analogous to the more or less 60 people who typically participate in decision making in ETC, and provides the minimum hurdle mentioned before for primary approval of proposals in the case of low participation rates. It also creates a permanent margin of consensus for primary approval in the case of higher participation, as the 60+ differential must be preserved in all cases to achieve primary approval.

Due to all of the above, the threshold in Etherplan Consensus Engine proposal contracts is a key security parameter to reach true rough consensus, rather than having naive voting mechanisms.

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.

5.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 (-).

Both the creation of ions and change of charge of ions are analogous to natural phenomena in the nervous system. This is because these types of  exchanges of molecules in neurons are primarily information messaging, rather than energy or matter transfers. Each cell locally produces or acquires the molecules or ions they use for messaging or performing their effects on postsynaptic cells.

In diagram 4 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.

5.7. Intermediate Contracts

Intermediate or intermediary 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+.

Intermediate contracts perform this secondary summation computation in the blocks right after the proposal contract period ended.

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.

5.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.

The final decision to pay or not pay solicited funds by proposals is called action.

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 they have a disapproved primary result, then the funds will not 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.

The pool operators may limit the number of possible complementary and competing proposals entered at one time to minimize complexity.

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 6.12. 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 perform this tertiary summation computation in the blocks right after the intermediate contract computations ended and were sent to them.

The consensus engine algorithm is very conservative as it must guarantee real rough consensus. In other words, a tie of competing proposals means there was no consensus, as contention means the opposite of consensus.

As said before, 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.

Payments may be limited by default by the group who are the pool operators. For example, a grant system of a university or public entity may have maximum payment value per proposal equivalent to $100,000.

Payments may be executed in the form of lump sums or scheduled payments.

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.

5.9. Funding Sources

The funding sources for pools and pool contracts depend on the nature or business of the group who created it.

They may be a treasury of a blockchain created with a miner tax; a community fund; the funds of a foundation; the working capital of a decentralized team of developers; a charity that receives regular donations; capital from a financial institution; or funds from any kind of entity who’s business or responsibility is to manage money on the blockchain securely, efficiently, and transparently, with a sound consensus mechanism to make decisions.

Pool operators may even use the Etherplan Consensus Engine dapp to create new pools from scratch and direct their funders, customers, donors, or any other funding sources to send the money directly to the pool contract on the blockchain.

6. Operation and Examples

In the following examples, simple cases are cases where participants send either a (+) or (-) ion to proposals, but not both. Complex cases are cases where participants, at least in one of the proposals, sent both the (+) and (-) ions to proposals, thus cancelling them out.

The ability to send one or both ions, and the freedom to withdraw them or abstain from voting, is similar to real ion flows in neurons when experiencing oscillations, polarization, depolarization, or hyper polarization prior to spiking or when initiating action potentials. Various kinds of ions are constantly being exchanged across the cell membrane through various types of ion channels.

It also reflects the real nature of discussions and debates during consensus formation for proposals, as participants tend to change or evolve their thinking and opinions as the context changes and as the arguments on all sides of the debate are heard and analyzed.

The key moment in the life cycle of proposals is the expiration of the proposal period and after the intermediate and pool contracts finished their computations a few blocks later, where the final result will determine whether final approval or disapproval were achieved.

For security reasons, in a proof of authority setting, a limited number of ions, in this case one (+) and one (-) ion, are distributed per participant. This is so no single participant may have sufficient votes to approve or disapprove individual proposals by themselves, thus forcing real consensus.

In proof of stake settings, this security guarantee is traded off for openness and privacy as any participant within and beyond the ecosystem can obtain and use ions based on their staked coin deposits, rather than by their identity, reputation, or historic participation.

As to the security vs performance trade off, note that all the voting transactions, inter-contract connections, inter-contract transactions, and summation computations are executed in the cheaper, more scalable, proof of stake, layer 2 blockchain. This is why it is called the execution layer.

Conversely, only the net secondary results from intermediate contracts, which generate a very small fraction of all transactions in the dapp, are sent to the pool contracts at the proof of work base layer, or layer 1 blockchain. In this more expensive but highly secure layer, the final proposal settlement payments are made and the metadata of proposals is stored for record keeping and context information.

All transaction fees are paid by proposers when entering and deploying proposals, and participants when entering ion transactions. When the subset of proposals that are approved are paid to proposer addresses, the fees are debited from the payments.

As per all of the above, the following points describe 12 different scenarios that may occur while processing proposals by the hypothetical group of 600 participants using the Etherplan Consensus Engine.

6.1. Simple Single Case

Diagram 5 shows a simple 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.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 5: Simple single case.

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 simple 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.

6.2. Special Case With Low Participation Rate

Diagram 6 shows a special simple 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.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 6: Simple single uncontroversial case with low participation rate.

It was special because it was uncontroversial as there were no (-) ions sent, and the proposal gained primary approval with a low participation rate of 60 voting participants sending 60+ ions, which barely reached the threshold of 60+.

However, this is more or less 100% of the usual subset of participants who are always active in the community forming rough consensus for new proposals, so being an uncontroversial case with low participation, it still gained a high level of rough consensus, as the rest of the community will likely follow and agree with this result.

All the steps of the process went as usual, and the pool contract paid the amount solicited in the proposal.

6.3. Simple Case Where the Proposal Was Not Funded

Diagram 7 shows a simple single case where proposal X for funding a project was entered by a proposer, but was not paid by the pool contract.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 7: Simple single case where the proposal was not paid.

The proposal got 33+ and 67- ions for a primary net summation number of 34-.

When the pool contract received the primary result, it performed the usual checks where it verified that the primary result was below the primary threshold, so it decided to not pay the solicited funds by the proposal.

Note that all the steps in the process continued to occur even if the proposal was rejected in the first instance. This is because there could have been entering complementary or competing proposals during the proposal period, which would have affected secondary and tertiary results as will be seen in later examples.

Also, the pool contract needs to receive all metadata and results of all historic proposals, regardless of their results, to keep as context information and for the permanent auditable record at the base layer.

6.4. Special Simple Cases With Full Participation

Diagrams 8 and 9 show two special simple cases with full participation where one was paid and the other was not.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 8: Special simple case with full participation where the proposal was paid.

The case in diagram 8 above is special because it demonstrates the maximum number of (-) ions, which is 270- in this example, a proposal may get in the primary instance to be able to reach the threshold of 60+ to gain primary approval when the participation rate is 100%, but participants sent only one of the two ions they have available.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 9: Special simple case with full participation where the proposal was not paid.

The case in diagram 9 above is special because it demonstrates what is the minimum number of (-) ions, which is 271- in this example, opponents of a proposal must send in the primary instance to be able to defeat it with a primary disapproval just under the threshold of 60+ when the participation rate is 100%, but participants sent only one of the two ions they have available.

6.5. Special Complex Cases With Full Participation

Diagrams 10 and 11 show two special complex cases with full participation where one was paid and the other was not.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 10: Special complex case with full participation where the proposal was paid.

The case in diagram 10 above is special because it demonstrates what is the maximum number of (-) ions, which is 540- in this example, a proposal may get in the primary instance to be able to reach the threshold of 60+ to gain primary approval when the participation rate is 100%, and many participants sent both (+) and (-) ions.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 11: Special complex case with full participation where the proposal was not paid.

The case in diagram 11 above is special because it demonstrates what is the minimum number of (-) ions, which is 541- in this example, opponents of a proposal must send in the primary instance to be able to defeat it with a primary disapproval just under the threshold of 60+ when the participation rate is 100%, and many participants sent both (+) and (-) ions.

It’s unlikely the two cases in this point will happen because it seems irrational that so many participants would send both their ions to a proposal, cancelling each other. However, these scenarios are possible according to the rules, so it’s worth noting them.

6.6. Simple Double Case of Competing Proposals

Diagram 12 shows a simple double case of competing proposals where proposals X and Y were entered by two proposers.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 12: Simple double case of competing proposals.

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.

6.7. Simple Double Case of Competing Proposals Where Both Got Primary Disapprovals

Diagram 13 shows a simple double case of competing proposals where proposals X and Y were entered by two proposers, but both got primary disapproval.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 13: Simple double case of competing proposals where both got primary disapprovals.

As X and Y were competing proposals, both had activated and directed their inhibitory contracts to each other. However, as both proposals were disapproved in the primary instance, then they could not send any ions to their corresponding inhibitory contracts because that can only be done if proposals get primary approvals.

However, the results were processed in the primary and the secondary instances, and both secondary results were sent to the pool contracts for final computation, verification, rejection, and record keeping.

6.8. Complex Double Case of Competing Proposals Where One Got a Primary Disapproval

Diagram 14 shows a complex double case of competing proposals where proposals X and Y were entered by two proposers, but one got primary disapproval.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 14: Complex double case of competing proposals where one got a primary disapproval.

The case is complex because proposal Y got 600+ ions and 600-. As said before, these cases are very unlikely, but are possible. As per the rules, proposal Y could not downvote proposal X through its inhibitory contract.

As proposal X had a primary approval, it just went through the motions, sent the negative ions to its competitor, and got a final tertiary approval by the pool contract, so the proposal was funded.

The reason why proposal X sent the negative ions to downvote its competitor is that it is never known until the end of a proposal period whether any proposal will win or lose the competition.

This means proposers must always identify and have their proposals upvote and downvote their complementary or competing proposals, as the final results are never known until the end.

6.9. Simple Triple Case of Competing and Complementary Proposals

Diagram 15 shows a simple 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.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 15: Simple triple case of competing and complementary proposals.

As seen in diagram 15 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 point 6.11. below.

The only equal or similar data, computation, and storage objects on both layers was the proposal metadata and processing.

6.10. Simple Triple Case of Competing and Complementary Proposals Where A Low Scorer Won

Diagram 16 shows the same scenario as the previous case, but where the scores of proposal X and Z were inverted to demonstrate that a lower primary approval scorer may win over a higher primary approval scorer when it is reinforced by a complementary proposal and its competitor is not.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 16: Simple triple case of competing and complementary proposals where a low scorer won.

As seen in diagram 16, the whole process went as usual, but proposal Z was on the winning side and got the funding it solicited.

Note that proposal Z actually had a primary approval, so it did pass the threshold initially. Something different happens in the next example.

6.11. Simple Triple Case of Competing and Complementary Proposals Where A Complementary Winner Was Not Funded

Diagram 17 shows the same scenario as the previous case, but where proposal Z was not funded.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 17: Simple triple case of competing and complementary proposals where a complementary winner was not funded.

As seen in diagram 17, proposal Z had a 100% voting participation rate. However it was not funded because, even if it won in the secondary and tertiary instances, it got a primary disapproval as its primary net summation result was 58+, below the 60+ threshold.

It’s important to note again that these final results can only be known by the end of the proposal period, so proposers, admins, and voting participants must remain alert at all times. It would have only taken 2+ ions or the change of heart of one voter, removing his (-) ion and sending a (+) ion to change the outcome.

As to the layer 1 and layer 2 security vs performance tradeoff, this competition would have had over 760 transactions plus several summation computations on the execution layer, and only 4 transactions plus fewer computations at the base layer.

6.12. Simple Triple Case of Competing and Complementary Proposals Where the Complementary Proposals Lost

Diagram 18 shows the same scenario as in point 6.9. above, but where the complementary proposals lost against an individual proposal.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 18: Simple triple case of competing and complementary proposals where the complementary proposals lost.

As seen in diagram 18, proposals Y and Z were the same as in point 6.9., 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 [33] is their way to increase sharpness and contrast [34] of the signal, which is what is repeatedly referred to as “relevance” in this paper.

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.

7. Instances, Contrast, and Context

The Etherplan Consensus Engine may be better understood from the perspective of instances. It has 3 instances for proposals to pass: The primary instance or proposal contract threshold, the secondary instance or intermediate contract summation of competing and complementary down and upvotes, and the tertiary instance or ultimate approval by the pool contract.

  • Primary instance (proposal contract): The 60+ threshold only applies in the first instance and helps reduce noise by imposing a high number of (+) votes over (-) votes, especially in case of low participation rates, which will likely be the most common scenario.

  • Secondary instance (intermediate contract): It adds and subtracts up or downvotes from complementary and competing proposals. This increases contrast between proposals or groups of proposals by expanding the differentials in the primary results. It helps in prioritization and numbing the lower score candidates so the focus remains in the few that have support and helps them even more if they have complementary proposals (e.g. Taproot + Graftroot + Miniscript [35] would all complement each other in Bitcoin, likely killing any competition. In ETC, Keccak256 + Flyclient + NiPoPoWs + Checkpointing would kill ETChash + MESS [36]). The enhanced contrast also helps the pool contract in clearly discarding losers and focusing on winners. This augmenting contrast feature will be even more important in the future when the pool contract also operates with a threshold as does the proposal contract now.

  • Tertiary instance (pool contract): It adds up all complementary proposals, then ranks them against other complementary proposals, and discards the losers. This means that all proposals in losing complementary groups are discarded even if they individually had primary approval. It also uses context information; such as what is the cash balance of the pool, or if a proposal is requesting money above a certain amount; to decide whether to discard or pay proposals. In the future, it will use more context information, each with thresholds as well, such as reputation of voters and proposers, etc.

All of the above mimics how groups of neurons (or the brain for that matter) work and decide on things like the color of objects, focusing on sounds, attractiveness of mates, or how much effort or work will be put between alternative options depending on the contrast of expected rewards.

In what could be described as a golden rule, if after the three instances described above there is a tie between pairs or larger groups of proposals, they all get discarded because that means there was no rough consensus.

This author believes that the 2017 SegWit2x proposal [37] would have won against the big blockers in this consensus engine because the SegWit2x side may have blocked big blockers by reducing their primary result, perhaps making them not meet the threshold. But to understand the possible scenarios it would be beneficial to run thousands of random simulations.

In any case, for now, the ECE is not for concrete systems upgrades, but just to fund them, or, in general, for any kind of decentralized group to decide on any kind of funding proposals.

With advanced context information, even insurance and reinsurance markets such as Lloyd’s of London could operate an ECE pool with their over $100 billion insurance and reinsurance reserve fund [38].

8. Primary Summation Space

The primary summation space represented in figure 2 below is the total number of possible outcomes of the voting mechanism in the primary instance on the proposal contracts. The space size depends on the distribution of (+) and (-) ions per participant; the ability for participants to use both to vote for single proposals; and the number of participants. Due to the primary approval threshold, a subset of the summation space may produce primary approval outcomes.

The Etherplan Consensus Engine - 以太计划共识引擎
Figure 2: The primary summation space and the primary approval outcomes subset.

In the hypothetical case in this paper of 600 participants with one (+) and one (-) ions each, and the possibility of using both or abstaining, the Etherplan Consensus Engine primary summation space size of total possible outcomes is 601 x 601 = 361,201.

With a primary approval threshold of 60+ ions, the possible primary approval outcomes are (541 x 541) / 2 = 146,340.5, or 40.51% of the primary summation space.

To make ECE more constrained or flexible, the threshold may be adjusted higher or lower depending on the profile of the group setting up the pool and relative to its expected voting participation rate.

9. Adjustable Parameters

Each open or affinity group who becomes a pool operator on the Etherplan Consensus Engine dapp may have their own policies. For example, the treasury of a blockchain system may be very open, accepting any participants or proposers to the system; or the pool managed by a charity may have a fixed set of participants, proposers, defined proposal types, and targeted beneficiaries.

As described previously in this paper, some parameters, such as the primary threshold potential; the ability to use one or both (+) (-) ion charges for voting per proposal; proposal periods; whether voting participants may be anyone or selected individuals; whether proposers may be anyone or selected individuals; and payment limits and format may be adjusted to suit each pool operator’s needs.

Pool operators may have several pools under management on the ECE with different styles and for different purposes.

Changes to some sensitive parts or rules of the consensus engine per group or pool may be entered as proposal contracts on the system itself. The difference will be that their result will not affect payments to projects, but just indicate that there is consensus to make changes to the pool rules.

Examples of these kinds of changes may be changes in the openness or closeness of the pool, e.g. from a proof of authority to a proof of stake mechanism and vice versa; additions or deletions in the proof of authority white list; number of allowed participants; or even the liquidation and termination of the pool.

10. Managing Complexity

As the complexity of the nervous system, complexity in the ECE may rise very quickly as individual smart contract functionality and the system in general evolve. However, with a gradual approach, it may become very useful to manage more intricate group decision processes.

For example, diagram 19 below is a representation of a hypothetical case where multiple clusters of competing and complementary decisions may be managed by pool operators on the system.

The Etherplan Consensus Engine - 以太计划共识引擎
Diagram 19: Hypothetical case with multiple clusters of competing and complementary proposals.

With careful research and development of the rules and interrelations of smart contracts that mimic neural circuits, and beginning from a very basic and simple starting point, as in the sample model in this paper, complexity risk may be managed, while greatly increasing the intelligence and usefulness of the system.

11. Modularity

As seen in all the sections, tables, figures, and diagrams in this paper, the Etherplan Consensus Engine has a very high level of vertical and horizontal modularity.

Vertical modularity means that the system is layered to adapt and adjust each part to the security, performance, and economic needs of its functionality. Horizontal modularity means the division of specific functions between smart contracts mimicking neuron specialization.

Division of labor and specialization between smart contracts with discrete functions permits easier design, research and development, management, understanding, and evolution of the system. It also enables easier addition, replacement, or adjustment of features or parameters by users and pool operators to adapt them to their needs.

From a technical perspective, this level of modularity facilitates auditing, easier debugging, reusability of code, readability, and all these characteristics together add up to greater reliability.

Greater reliability helps significantly in managing complexity.

12. Risks

In its current state as described in this paper, the Etherplan Consensus Engine presents two centralization risks explained with their possible solutions in the following points.

12.1. 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 solutions:

  • Idea 1: Proposals may be entered naked (unrelated to any other proposals). Then, voters can direct votes with instructions per vote to excite and/or inhibit other target proposals. If the votes to excite and/or inhibit other target proposals reach a certain threshold, say 30+, then the excitation and/or inhibition get directed to those target proposals. Note that if the entire proposal did not reach its own threshold for primary approval, it would not excite or inhibit any proposal in any case.

  • Idea 2: Make all proposals inhibit all other proposals, and make the ones with the most stimuli win.

  • Idea 3: Use the same manual method on Github [39] as the Bitcoin BIP and Ethereum Classic ECIP processes, where proposals are initially pull requests (PRs) [40] that are revised and merged by the editors. In the ECE, the admins would do the same with new funding proposals, but would also associate them by proposer request and/or the admin’s own judgement and analysis. Then, proposals can be merged [41], which means they would also be entered on the execution layer (layer 2) blockchain for voting.

Author’s opinion:

In this ECE early stage, it would be better to do the entry and association of proposals manually as in idea 3, as the Bitcoin BIP and Ethereum Classic ECIP processes are. The proposals may start as pull requests (PRs) on Github, and then the pool admins can clean and polish them and associate them, just like ECIPs and BIPs today.

In a future ECE version, autonomous or rough consensus based automated association solutions may be integrated.

12.2. 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’s proof of stake, then the problem is 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 PoA pool that may be completely trust minimized, but the Bitcoin BIP and Ethereum Classic ECIP processes work with groups of relatively known developers and editors, anyway.

In the hypothetical case of ETC, there would have to be an initial stage where all regular members of the ecosystem are “inducted” into the PoA 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. 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 always contacted to make upgrades [42].

All of the above could announce a public key so they would be inducted. When all of the above were inducted they would become the “genesis list”.

Once there is a large amount of participants, then a threshold may be set. It is 60+ in this paper, but it may be different based on the size of the PoA 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 PoA 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).

13. Conclusion

As the world will move 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.

These groups may be open communities, such as blockchain ecosystems, or affinity groups, such as decentralized teams, multinational entities, industry groups, or supranational organizations with diverse decision making participants.

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.

The Etherplan Consensus Engine dapp described in this paper will help groups and organizations of any kind to manage pools of money on the blockchain making and executing the most optimal decisions efficiently, in a trust minimized way, and transparently across national and cultural boundaries.

From how it works, from proposal entry to funding, and examples of its operation are provided in this paper, including various typical, edge, and improbable but possible cases.

The Etherplan Consensus Engine  may be customized up to a certain extent to the needs of pool operators and the profiles of their groups.

By managing complexity, and even leveraging it, the system’s functionality and usefulness may be greatly increased. It is possible that, as the platform evolves, corporations, foundations, mutual funds, insurance companies, reinsurance markets, banking institutions, and other types of economic groups, who manage pools of capital as their core business, will find it useful to make better decisions, more securely, and efficiently.

By mimicking the nervous system and neural circuits, the ECE mechanism actually becomes more simplified and highly modularized, creating specialized smart contracts that divide labour between them in different computational layers.

In these layers the distribution of risk and computational load and cost may be greatly optimized.

In conclusion the Etherplan Consensus Engine is an excellent tool for open or affinity groups and other kinds of entities to manage pools of money through rough consensus in a highly secure, efficient, transparent, and intelligent way.

References

[1] Satoshi Nakamoto Mentioned Trust Minimization 14 Times in the Bitcoin White Paper – by Donald McIntyre: https://etherplan.com/2020/02/29/satoshi-nakamoto-mentioned-trust-minimization-14-times-in-the-bitcoin-white-paper/10210/

[2] Trusted Third Parties Are Security Holes – by Nick Szabo: https://nakamotoinstitute.org/trusted-third-parties/

[3] Rough consensus – by Wikipedia: https://en.wikipedia.org/wiki/Rough_consensus

[4] Bitcoin Improvement Proposals – by Bitcoin Wiki: https://en.bitcoinwiki.org/wiki/Bitcoin_Improvement_Proposals

[5] Standards process – by IETF: https://www.ietf.org/standards/process/

[6] Ethereum Foundation: https://ethereum.org/en/foundation/

[7] A five-member board to control $36 million treasury for Zcash – by Shaurya Malwa: https://decrypt.co/39105/a-five-member-board-to-control-36-million-treasury-for-zcash

[8 (a)] Ethereum Classic Treasury System Proposal – ECTS – by IOHK – The Veritas Team – Dmytro Kaidalov, Lyudmila Kovalchuk, Andrii Nastenko, Mariia Rodinko, Oleksiy Shevtsov, Roman Oliynykov: https://etherplan.com/a-proposal-for-an-Ethereum-Classic-treasury-system.pdf

[8 (b)] Proto Treasury System – p-ECTS – by Julian Mendiola, Nicolas Tallar, Brian McKenna: https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1098.md

[9] Tezos: Superior Governance and Use Cases – by Kathleen Breitman: https://www.gemini.com/cryptopedia/what-is-tezos-xtz-governance-use-cases

[10] The DFINITY “Blockchain Nervous System” – by Dominic Williams: https://medium.com/dfinity/the-dfinity-blockchain-nervous-system-a5dd1783288e

[11] A  Mathematical Theory of Communication – by C. E. Shannon: http://etherplan.com/a-mathematical-theory-of-communication.pdf

[12] Early evolution of neurons – by William B. Kristan Jr.: https://www.sciencedirect.com/science/article/pii/S0960982216304894

[13] Neural circuit – by Wikipedia: https://en.wikipedia.org/wiki/Neural_circuit

[14] Noise, Signal, Skepticism, and Trust – by Donald McIntyre: https://etherplan.com/2020/12/15/noise-signal-skepticism-and-trust/14193/

[15] Questions from 1920 Still Haunt Neuroscience – by Neuroskeptic: https://www.discovermagazine.com/mind/questions-from-1920-still-haunt-neuroscience

[16] Nervous system – by Wikipedia: https://en.wikipedia.org/wiki/Nervous_system

[17] Summation (neurophysiology) – by Wikipedia: https://en.wikipedia.org/wiki/Summation_(neurophysiology)

[18] The retina – by Britannica: https://www.britannica.com/science/human-eye/The-retina

[19] Neural Computation: Markus Meister at TEDxCaltech: https://youtu.be/obAHnwp9tOM

[20] Action selection – by Tony J. Prescott, Scholarpedia: http://www.scholarpedia.org/article/Action_selection

[21] Proof of Stake (PoS) – by Jake Frankenfield: https://www.investopedia.com/terms/p/proof-stake-pos.asp

[22] Why Proof of Work Based Nakamoto Consensus Is Secure and Complete – by Donald McIntyre: https://etherplan.com/2020/03/21/why-proof-of-work-based-nakamoto-consensus-is-secure-and-complete/10509/

[23] 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/

[24] 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/

[25] Bitcoin Improvement Proposal (BIP) process – by Luke Dashjr.: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

[26] Ethereum Classic Improvement Proposal (ECIP) process – by Wei Tang: https://ecips.ethereumclassic.org/ECIPs/ecip-1000

[27] Proof of Authority – by Binance Academy: https://academy.binance.com/en/articles/proof-of-authority-explained

[28] The Meaning of Blockchain Immutability – by Donald McIntyre: https://etherplan.com/2018/04/19/the-meaning-of-blockchain-immutability/6852/

[29] Threshold potential – by Wikipedia: https://en.wikipedia.org/wiki/Threshold_potential

[30] Neural oscillation – by Wikipedia: https://en.wikipedia.org/wiki/Neural_oscillation

[31] Subthreshold membrane potential oscillations – by Wikipedia: https://en.wikipedia.org/wiki/Subthreshold_membrane_potential_oscillations

[32] The Ethereum Classic Ecosystem Explained – by Donald McIntyre: https://etherplan.com/2020/01/28/the-ethereum-classic-ecosystem-explained/9680/

[33] Lateral inhibition – by Wikipedia: https://en.wikipedia.org/wiki/Lateral_inhibition

[34]  Contrast effect – by Wikipedia: https://en.wikipedia.org/wiki/Contrast_effect

[35] Bitcoin’s Legal Hypertextualism – by Donald McIntyre: https://etherplan.com/2020/10/08/bitcoins-legal-hyper-textualism/12940/

[36] Ethereum Classic Protocol Compact 2020 –  by Donald McIntyre: https://etherplan.com/2020/09/27/ethereum-classic-protocol-compact-2020/12822/

[37]  SegWit2x – by Bitcoin Wiki: https://en.bitcoin.it/wiki/SegWit2x

[38] Lloyd’s of London – by Wikipedia: https://en.wikipedia.org/wiki/Lloyd%27s_of_London

[39] GitHub – by Wikipedia: https://en.wikipedia.org/wiki/GitHub

[40] About pull requests – by GitHub: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

[41] About pull request merges – by GitHub: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges

[42] Example of list of ETC nodes who are contacted every time there is an upgrade – by Donald McIntyre: https://docs.google.com/spreadsheets/d/1Q9c-q6J0zAJxqpaXxPetJQbcsb-soTIk-Xfnc-h041s/edit?usp=sharing

部分转自网络,侵权联系删除区块链源码网

www.interchains.cc

https://www.interchains.cc/20243.html

区块链毕设网(www.interchains.cc)全网最靠谱的原创区块链毕设代做网站 部分资料来自网络,侵权联系删除! 最全最大的区块链源码站 ! QQ3039046426
区块链知识分享网, 以太坊dapp资源网, 区块链教程, fabric教程下载, 区块链书籍下载, 区块链资料下载, 区块链视频教程下载, 区块链基础教程, 区块链入门教程, 区块链资源 » 基于区块链的毕业设计The Etherplan Consensus Engine – 以太计划共识引擎

提供最优质的资源集合

立即查看 了解详情