With LiquidFeedback published in late 2009 and the book “The Principles of LiquidFeedback” published in January 2014, we, the authors of LiquidFeedback, presented specific rules of procedure for a democratic process, providing every participant with truly equal rights to the maximum known extent while maintaining feasibility and effectiveness also in cases when the number of participants is huge. [PLF, Postface] Even though recorded votes ensure that any manipulation of the outcome can be detected by the participants, LiquidFeedback (as of now) still depends on a central authority (e.g. an organization or state administation) to host the system. With this article, we present a roadmap for a future LiquidFeedback that doesn't depend on a central authority but can be operated decentralized by any group of people who decide to do so.
The already existent LiquidFeedback proposition development and decision making process allows a (previously defined) group of people to enter a fair proposition development and decision making process where each participant gains equal rights to the maximum possible extent. The process is suitable for a broad range of applications such as policy making, technical standardization, (democratic) product development, or collaborative publications.
Currently, the correct execution of LiquidFeedback's rules of procedure is carried out by a centralized server infrastructure to be operated by an organization or political administration which wants to provide the system to the participants. The new idea is to empower the participants to not only engage in the process but to also be able to technically execute the process in a joint effort.
Not just changes to the rules of procedure or any document jointly created with such a future LiquidFeedback system would depend on a majority of people supporting these changes, but the actual execution of these changes would be carried out by a distributed system, hosted by eligible voters, that could interpret properly formed proposals automatically (e.g. enabling a new software component or changing a paragraph of a policy automatically).
When creating such a system, there are a couple of requirements to meet. First of all, we need to ensure that decentralization doesn't come at the cost of sacrificing the fairness of the existent LiquidFeedback process. It should also be ensured that the process is transparent for all participants. Only transparency ensures that compromized hard- or software (e.g. due to hacking attempts or technical failures) can be detected; i.e. the results of the system shall be verifiable by the participants. In case of errors or manipulations, it should be possible to correct the results.
Despite transparency and correctability, which allow us to handle errors of the system, we still expect such a system to be as secure as possible, i.e. it should be as difficult as possible to manipulate the system even if it cannot be completely outruled. Furthermore, such a system should be scalable and allow millions of people to take part in democratic decisions at the same time, if desired.
In order to fulfill the previously stated requirements, proper algorithms have to be selected and/or created where necessary. A data model as well as algorithms for data distribution and finding a consensus have to be defined. In some cases we can rely on existing technologies, in other cases we need to modify existing technologies or invent new algorithms, especially where existing solutions are not suitable for distributed application or are environmentally hazardous (e.g. blockchain with proof-of-work). The system needs to be fault tolerant and (as previously mentioned) correctable, e.g. it must be possible to recover from a compromized end user device due hacker intrusion (key revocation and recovery).
A couple of theoretical findings as well as technological insights must be kept in mind when designing a decision making process, even more so when abstaining from relying on a central trusted authority.
Most notably Kenneth Arrow's impossibility theorem published in 1951 affects the design of decision making processes. From this theorem follows that when there are more than two voting options, tactical voting cannot be outruled completely. [Gibbard] [PLF, section 4.14] On the other hand, breaking down complex decisions into simple binary (i.e. yes/no) questions suffers the problem that the order of the questions has a massive impact on the overall outcome of the process. [GoD] Consequently, if we want to treat all participants of a democratic process equally, we need to allow more than two voting options on a ballot for a given issue. In turn, tactical voting has to be taken into consideration. To treat everyone equally, it is important to temporarily hide cast ballots. [PLF, section 4.14] [GoD] Doing this without a central (trusted) authority is a rather complex issue because we want no participant to be able to change his or her ballot based on the other ballots. Even worse, in some cases even withdrawing a ballot from a vote (dependent on the other voters' ballots) may lead to tactical advantages. [Moulin] The last article in this Issue #6 of “The Liquid Democracy Journal on electronic participation, collective moderation, and voting systems” will elaborate the serious consequences of these findings for all forms of electronic decision making systems. [Practical]
Another aspect to keep in mind is the overall complexity of the system. The above mentioned challenges will require sophisticated algorithms, so another important aspect to keep in mind is making sure the overall complexity of the system is as low as possible in order to allow easy maintenance and continuing revolution.
In addition to new algorithms, a future decentralized LiquidFeedback will also be based on a couple of existing technologies. The currently existing version of LiquidFeedback already provides a process for proposition development and decision making that treats every participant equally and scales (in theory) for groups of unlimited size. [Infinite] [Limiter] However, current LiquidFeedback versions don't allow an automatic interpretation/application of proposals that were agreed upon. For example, the members of a political party may use LiquidFeedback to decide on changing their party program, but the actual change will need to be executed by a person designated to maintain the document. This limitation has partially been lifted by combining LiquidFeedback with revision control systems, which is a first step to automate the application of approved proposals in the decision making process. [RevisionControl]
Peer-to-peer networks for file sharing have been existent since the millenium change and are an important advance in distributed computing. While these networks allowed the distribution of data, they were unable to solve the problem of commonly agreeing on a particular state of data. Blockchains solved this problem by ensuring that a large portion of the participants work with and refer to the same working state.
To ensure that (in the long term) only one state exists within a decentralized network, blockchain systems usually rely on proof-of-work methods where energy (and therefore money) has to be invested on a well-defined mathematic challenge in order to create a new state within the network. Due to the bad environmental side effects and because of the risk that a malicious party could gain a majority of processing resources, an alternative to the proof-of-work scheme has been proposed, called proof-of-stake. However, applying these proof-of-stake algorithms (that do not rely on wasted energy) to traditional blockchains can cause problems because participants in the network have nothing to lose by creating conflicting blocks, thus effectively preventing a consensus within the network (which was the goal in the first place). Methods have been proposed to fix this problem by introducing a punishment for such behavior [EthereumWiki], but in the next article, we will show how a consensus can be achieved in a different way (that is, in our opinion, much easier). [LFB]
In order to be independent of a central authority, we need to make all operational decisions of the system in a decentralized way. In this context, each eligible voter shall have the same influence on all decisions being made within the system, including operational decisions such as a consensus on who cast a vote and who was late.
It should be noted that if we completely replace the central authority with an automatic, decentralized system where all participants hold the same stake (proof-of-stake with same stake for each eligible person), then it's up to the majority to properly execute the agreed upon rules. For the remainder of our considerations, we need to assume that the majority of people are willing to ensure the overall fairness of the process. This is not a major restriction because in traditional decision making processes, the proper execution of the rules of procedure usually depends on elected people (or persons appointed by elected people). If the majority of the electorate are malicious, every democratic system would fail. We therefore assume benevolence of a majority of eligible voters.
A necessary prerequisite for any democratic decision making process is the accreditation of the participants. There needs to be clarity who is eligible to vote and how to identify these people during the voting process. There needs to be a process allowing new people to gain eligibility to vote as well as a process to remove people's accounts (e.g. in case of death or leaving a political party). While the design of such an accreditation process in detail is out of scope of this article, we assert that it is made public (at least among the participants) who enters and who leaves the set of eligible voters.
Under the previously stated prerequisite that a majority of eligible voters are benevolent and further assuming that the accreditation process is designed in such a way that the electorate can verify the list of persons gaining or losing eligibility to vote, we can conduct a vote on each person to be added or removed from the list of eligible voters. In many cases, such a vote will not prompt the electorate to express their own opinion on accepting a person to enter or banning a person from the group of eligible voters, but may rather be a mere confirmation of the outcome of a previously defined process that has been carried out in the real world (e.g. appearing in front of an audience and paying the membership fee for an organization).
The article “Decentralized Accreditation” [Accreditation] in this Issue #6 will have a closer look at different choices on how to implement a decentralized accreditation process for determining, identifying, and authorizing the eligible voters.
A working prototype to demonstrate the basic principles has been created and will be included in the electronic version of this Issue #6 as well as published on the website of the journal in advance. The next article will explain the prototype as well as a new method for merging conflicting blocks in a blockchain which helps to implement a proof-of-stake system that is environmentally friendly.