Introducing Long Living Masternode Quorums

We’re very happy to introduce the community to another concept that is currently under development: Long Living Masternode Quorums, or simply LLMQs. These will have quite some influence on Evolution and non-Evolution related topics and features, which you’ll hopefully see after some time. More blog posts are planned which will go into more detail for the specific topics.

Links to DIPs and supporting documents

DIP6 — Long Living Masternode Quorums

DIP7 — LLMQ Signing Requests/Sessions

BLS Signature Scheme

BLS M-of-N Threshold Scheme and Distributed Key Generation

What are Long Living Masternode Quorums?

I have already described the quorum system we currently use for InstantSend in a previous post. That post also describes the issues and limitations with the old system and why we can’t use it for new use cases. LLMQs provide a solution to the described problems and will be deployed as part of Evolution.

They are long living (as the name implies…) and possibly very large, increasing the security of those. At the same time, they only increase the required resources (CPU, RAM, network) on the members of such quorums, instead of increasing the load on the whole network.

Long living means that instead of selecting a fresh quorum on-demand, we build them before we actually need them and then reuse them for a fixed period of time. The reason for this is that a LLMQ performs M-of-N threshold signing sessions to gain majority consensus when decisions need to be made. The new M-of-N scheme requires executing a trustless and distributed key generation (DKG) protocol before actual signing/voting can happen. Since this DKG protocol is quite resource-intensive, we do it in advance and then reuse the keys for multiple signing sessions.

Why/How do they solve the limitations?

As described in the previous post about quorums, the old system requires propagation of each individual vote of each member of a quorum. Propagation means that the votes are transferred to all nodes in the network which then have to verify and store them. This does not scale well and might also cause a variety of problems with consensus.

LLMQs however only require the members of the quorum to perform the propagation and validation of individual votes (signature shares). The final result (recovered signature) is only created and propagated to the remainder of the network when enough votes are collected by any quorum member. Since the final result is the outcome of a BLS based M-of-N threshold signing session, it’s just a single BLS signature. Propagating only this single signature in the network requires a lot less CPU, RAM, and network bandwidth resources.

As only the members of the LLMQs perform the hard work and there are multiple LLMQs active simultaneously, the overall network load remains well distributed.

Other Advantages

Due to the use of BLS, we also get a few more advantages. All BLS signatures are deterministic and unique, which means that there is only one valid signature for every combination of message and keys. This even holds true for M-of-N threshold signatures, which are in the end just normal BLS signatures. The result of a LLMQ signing session is thus deterministic and unique as well.

These properties are very important when it comes to storing quorum decisions on-chain. Without these properties, malleability problems would also leak into non-transactional features, e.g. blockchain users and state transitions. By eliminating malleability, Evolution can include features which were previously very hard to implement securely.

LLMQs and Verification of Signing Sessions

LLMQs are created with the help of a distributed key generation (DKG) protocol. The result of that protocol (the quorum commitment) is mined on-chain before activation and actual use of the LLMQ. This means that there is clear consensus about which LLMQs are active and which masternodes belong to which LLMQ. It also means that, unlike the old quorum system, every quorum signing session can be verified forever. This is very important when quorum decisions are mined on-chain or when SPV (or DAPI in the future) wallets need to verify quorum signatures.

Size of LLMQs

We will support multiple types of LLMQs, which most importantly differ in size and longevity. We have not decided exactly which sizes to use, but we are open to supporting LLMQs with as many as hundreds (e.g. 400) of members and as few as 10 members. It all depends on the use cases and their needs.

Implementation of LLMQs as a Platform

The implementation of LLMQs does already exist and is already very advanced (not just a simple proof of concept). It is implemented to be a platform, or base layer, for future use cases which require LLMQs. Basically, the implementation of new use cases should just call a few functions of the LLMQ platform. These functions are in the style of “sign this message”, “do we have majority?” and “is there a conflict?”. This should make it very easy to implement new use cases as they do not have to deal with the internals of LLMQs, DKGs, signing sessions, and so on.

Required changes in DIP3

DIP3 will have to be slightly changed to support LLMQs. The DKG process requires BLS public keys to be known and verified before the DKG session can start. This means that we’ll have to use a BLS public key instead of a ECDSA public key for the masternode operator key. DIP3 will be updated when we have made a final decision on which BLS curves to use.

Use Cases for LLMQs

The first and probably most obvious use case for LLMQs is InstantSend. It can be implemented by simply making LLMQ members threshold sign the inputs of observed transactions. If any member of a LLMQ collects enough threshold shares, they’ll create the final result and propagate it to the whole network. With this, the network will only have to propagate one message per transaction input. If a node observes such a message for each of a transaction’s inputs, it can consider that transaction as InstantSend confirmed.

I’ll post an article and another DIP soon which goes into more detail for InstantSend and how we could improve it with LLMQs.

Other use cases directly involve Evolution-related features, especially State Transitions. We’re also researching use cases which improve more non-Evolution related features. You’ll see more blog posts and DIPs in the future in regard to all this.