Quorums in Dash

In this post, I’d like to describe what quorums in Dash are and what they solve. I’d also like to explain the problems with these and why we can’t easily scale these or use them for new use cases. Initially, this was part of another post that I’m writing at the same time and which I’m going to release sometime after this one. Basically, in this post I will try to describe what Quorums are, what they are currently used for and what their current limitations are. The next post will then give an answer on how we plan to solve these issues once and for all.

What are Quorums?

A quorum is a collection of entities that are able to vote on something. Every member is generally allowed to vote only once. If >= 51% vote for the same thing, majority is reached. Something either got the majority of votes or not, there should be nothing in between.

This is useful if the likelihood of disagreement is too high, which for example is the case when it comes to propagation of transactions and handling of conflicts if they arise. Bitcoin introduced a policy to handle this, which is the first-seen policy. Dash inherited this policy. It basically means that if a conflict arises (e.g. a double spending transaction) the first seen transaction is the only one a node should accept and propagate while ignoring all others.

This removes all ambiguity on a single node, including miners. It also reduces ambiguity on the whole network, as it also means that a transaction that is well propagated can’t be replaced by a conflicting one. If however, a transaction is not well propagated yet, two competing transactions will start to race in the network, resulting in one part of the network seeing one of the transactions first, and the other part of the network seeing the other transaction first. In the end, it’ll be impossible to tell which of both transactions is going to be mined and confirmed on-chain. This is because a single node can not know what the other nodes have seen first.

InstantSend

Dash has already solved this problem thanks to InstantSend. InstantSend is the first time we used quorums to solve such ambiguity in the network. It works by choosing a new quorum of 10 masternodes per transaction input and letting every member sign and propagate a vote for it. If 6 out of these 10 do this, we can be pretty sure that the majority of the network has also seen this transaction first. If this is the case, a node can safely reject all other transactions conflicting with that one, even if they were locally seen first. If some race had happened between two conflicting transactions, only one of both would have been able to reach more than the other one.

Delegating the voting to the quorum is then like a statistical measurement, because what applies to the whole network statistically also applies to a random subgroup of that network.

If 3 transactions would race in the same way, it’s still only possible for one to gain majority, but it might happen that no majority at all is gained which means no decision can be made. For InstantSend, this is ok as the worst thing that happens is that the receiver of a transaction does not get the instant assurance of later confirmation and thus has to wait for normal on-chain confirmation.

Sybil Attacks and Masternodes

You might ask yourself why this solution was not used in other coins, e.g. Bitcoin. The reason is that such a system is only secure if the chance of so called sybil attacks is practically zero. A sybil attack means that a single entity (possibly an adversary) is able to easily create as many entities as needed to increase the chance of him being able to control the outcome of a vote.

In cryptocurrencies for example, this means that you can’t simply choose a set of nodes from all known nodes, as any adversary is able to create thousands or even tens of thousands of nodes to increase the likelihood of his nodes being chosen.

This means that to make the system secure, the number of possible quorum members must be limited. It must also be relatively expensive to become a member, as otherwise one could cheaply become a member multiple times. There must also be an incentive to behave well, meaning that there must be a risk to lose something in case someone is caught trying to cheat the system.

Masternodes in Dash solve all this by requiring a collateral of 1000 Dash and by paying masternode owners a portion of the block reward. This limits the number of possible quorum members and incentivizes Masternodes to behave in a honest way. Someone owning many Masternodes risks losing his rewards when trying to play games with the system.

Scaling Quorums and InstantSend

Currently, InstantSend is an optional feature that requires paying a higher fee. You basically pay some extra fees so that the receiver of an InstantSend transaction receives the funds faster. There is demand in the community for this to change so that every transaction basically becomes an InstantSend transaction.

However, this is not as easy as one might expect. The Quorums behind InstantSend have some overhead on the network as they require to propagate a lot more messages than a normal transaction. Generally, InstantSend requires around 10x as many messages to be fully propagated in the network. InstantSend is also more demanding when it comes to CPU and RAM requirements.

The reasons for this is that every quorum member creates one vote per transaction input and then propagates it to the whole network. In the end, 10 messages per transaction input are propagated. A transaction with 10 inputs would already require 100 messages to be propagated. At the same time, every node in the network has to verify these messages and then keep them in-memory until the transaction is mined onto the chain and confirmed by multiple blocks. Imagine what this means if all people in the world start to use Dash…

The load on the network would also not only increase hardware and network demands. It would decrease the stability, reliability and security of the whole network. This is because every vote is treated as a single message and only if 6 out of 10 are locally present, majority can be proven. Due to the load, the likelihood of different nodes seeing a different subset of the votes increases, making it easier for adversaries taking advantage of slow and non-deterministic propagation.

Using Quorums for new use cases

There are many other use cases which would benefit from quorums. Some are even impossible to implement without something like quorums.

These would however suffer from the same scalability issues as described for InstantSend, making the current system unsuitable. At the same time, many use cases require a much higher level of security, which can only be achieved by increasing the size of quorums.

Increasing the quorum size would however also increase the load on the network. If we for example used 100 members per quorum, 100 votes would have to be propagated for everything that needs to be voted on.

Evolution and Quorums

Evolution contains some fundamental features which highly rely on majority decisions done by quorums. Initially, the plan was to reuse the existing quorums system for this, but it turned out that we’d hit too many limits with it.

Basically the same limits as with scaling InstantSend apply, but also some new limitations came to light. For example, we need to store the results of quorum decisions on-chain so that it can be verified by everyone and forever. However, storing 100 or more ECDSA signatures on-chain each time does not sound as if it would scale well ?

Conclusion

The quorums currently used in Dash are mostly good enough for what they are currently being used. We are however at a point were we need a better solution if we want to continue improving. One of my next posts will describe a solution which we’ve been working on for quite some time now.

Author: Alexander Block
Original link: https://blog.dash.org/quorums-in-dash-e1f19a66f4bf