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