Two weeks ago, two friends of mine (Yunus Gürlek and Yaman Can) and I joined the ETH Prague hackathon. In this article, we want to share a weird solution we came up with to a fundamental problem, which we hope can inspire many to change their approach to blockchain. It is not the problem we have solved nor the product we have built, but the concept we have designed (which we call Consensus of Conflicts, may be a bit boldly), is we believe a unique approach to decentralized systems and an accurate description of how the blockchain technology may exist in all kind of forms.

Four weeks ago, Turkey had a huge national election where close to 90% of the population voted to choose one of the two candidates entering the election. As can be seen from this massive voting rate, the election results were very important to the majority of the population. Nevertheless, unfortunately, the traceability of the election was very inadequate. The results published by various press organizations differed significantly during the counting process, as well as the time they chose to publish results coming from different geographical areas. This was due to the opposing intentions of these organizations depending on their political side. The problem was not about the governance, as once the results were announced by the official committee, there was no more confusion on them. However, this was not until the next morning, and people were not able to reach trustable information until then.

In the blockchain community, voting and democracy is a topic of great interest and development. However, almost all the existing solutions in the ecosystem focus only on enhancing privacy during the voting process and reducing societal pressures, thus promoting objective voting. Our product takes a different approach compared to existing solutions. While embracing democracy as a system, it recognizes that certain countries may struggle while adapting to democracy culturally, leading to challenges in their election processes. As seen from the recent example above, one of the primary challenges is the lack of objectivity during the vote-counting phase and the reliance on a few institutions to share the results with the public.

Our proposal was to have a product on the blockchain to improve the traceability of election results. We designed a web app where auditors can validate and record the ballot box results into the system. If auditors who are responsible for the same box reach a consensus on the results, these results would be published to the public on the web application. If there is a lack of consensus among the parties, this disagreement will also be recorded on the blockchain, allowing the public to track which ballot boxes have not yet been added to the results. This would make the need of having a centered publishing organization (which may eventually alter the results and have bias) disappear, as well as making sure that all the information published is trustable. By having this website, the public would be able to reach accurate information on time.

At first, the solution seemed pretty easy to apply. We already had a giant audience unknowingly waiting for this product. We also had the perfect auditor group, as in Turkey, all big parties have some official volunteers at every election center, approving the results during the counting process. These people are authorized by the official election committee, and they have the right to object to the result of the center they work for. As a consequence, we were sure that the result provided by the consensus of these volunteers is a trustable information.

However, in practice this design was fundamentally flawed. First of all, it was not possible to have all the auditors in an election center share their respective opinion on a blockchain system. Moreover, even if that was possible and we were able to register all the auditors to our product, then it still would take a massive amount of transactions and a considerable amount of time to reach a total consensus on every election center. Everyone who volunteers and is trusted by the party could be an auditor during the elections, so the complexity of our design would depend on the number of volunteers, which can grow pretty fast as known by the experience. This meant that our product would not be able to actually scale or deliver the true information in a timely manner to the public. And this is where the magic happens :)

Our case has two significant characteristics: First of all, all the auditors (which can also be called as validators of election results) have a clear purpose. They are all chosen by the political side they represent, and thus they are all hoping for their side to win. This creates a perfect game theory model, where all the sides try to win and optimize the results for themselves. Moreover, in our case, only two sides exist, so there are only two different groups of validators. These two conditions made our use case a perfect binary game, where two parties play against each other to win.

Perfect binary games have a very basic property: If two opposing sides have the same idea on how the game has ended, then the result should be correct. As no party has the intention to lose, there is no reason for the losing one to lie on how the game ended. So to put it simply, you can always trust someone if he says he has lost the game :)

With these two special assumptions, our design offers a special consensus mechanism called “consensus of conflicts”. In this system, instead of requiring the consensus to approve the results, we only need two opposing validators to approve the same result for each election center. Instead of having an unknown number of validators, only two of them were enough to prove (with 100% certainty) that the results were correct.

The official auditors are published by the political parties before the election, so it is easy to group them and know which party they belong to at the time of election. By having only a merkle tree root hash on the chain (which is basically a number), we are able to prove that a transaction is made by an official and deduce her/his side on the election. So it is possible to count the number of approvals on each alleged result. Finally, the contract tags and shows the results with more than 1 approval (this number may be changed depending on the system details) of each opposing part as valid, publishing the data instantly to the public. We can also add an additional check to see if a validator will validate something that is not already validated by its own party, and by not sending its transaction if it does not provide any new information to the chain, we can also decrease the number of transactions needed by a significant amount.

To us, the most impressive part is that this kind of situation exists in a lot of cases. Basically, we propose that any transaction approved by two opposing parties (which are accepted to be rivals by the consensus), and where one of the parties loses against the other as a result of the transaction, can be easily accepted to be true by the rest of the validators without the need of any extra verification. Of course, this is rather a simplistic model of a real-life solution. Nevertheless, the idea of having conflicting validator groups to actually decrease the number of verifications needed and increase the transaction speed stays pretty valid. As in the end, blockchain is not about machines, but about people believing in what the technology says to them. And no-one can argue when you say you have lost the game :)

In conclusion, our point is that each use case is unique, and different approaches may exist for different situations. So instead of always keeping the same basic assumptions on how validators may act, try to come up with your own theory. Create your own assumptions and try to have a more restricted space for your problem. As known by all developers, specifying a problem even more can only improve the complexity of a system, in most cases resulting in a totally new and better solution. And we know that the world needs better solutions.