Masternode Quorums

Dash's masternode quorums are used to facilitate the operation of masternode provided features in a decentralized, deterministic way. The original quorums (used largely for InstantSend and masternode payments) were ephemeral and used for a single purpose (e.g. voting on one specific InstantSend transaction).

Dash Core 0.14 (protocol version 70214) introduced the Long-Living Masternode Quorum (LLMQ) system described in detail by DIP6. These LLMQs are deterministic subsets of the global deterministic masternode list that are formed via a distributed key generation (DKG) protocol and remain active for a long periods of time (e.g. hours to days).

The main task of LLMQs is to perform threshold signing of consensus-related messages (e.g. ChainLocks).

LLMQ Creation (DKG)

The following table details the data flow of P2P messages exchanged during the distributed key generation (DKG) protocol used to establish an LLMQ.

📘

Intra-Quorum Communication

Note: With the exception of the final step (qfcommit message broadcast), the message exchanges happen only between masternodes participating in the DKG process via the Intra-Quorum communication process described in the DIP.

Quorum DKG Data Flow

Masternode	Direction	Peers	Description
Initialization Phase			Deterministically evaluate if quorum participation necessary
			Each quorum participant establishes connections to a set of quorum participants as described in DIP6
Contribution Phase			Send quorum contributions (intra-quorum communication)
inv message (qcontrib)	→		Masternode sends inventory for its quorum contribution to other masternodes in the quorum
	←	getdata message (qcontrib)	Peer(s) respond with request for quorum contribution
qcontrib message	→		Masternode sends the requested quorum contribution
Complaining Phase			Send complaints for any peers with invalid or missing contributions (intra-quorum communication)
inv message (qcomplaint)	→		Masternode sends inventory for any complaints to other masternodes in the quorum
	←	getdata message (qcomplaint)	Peer(s) respond with request for quorum complaints
qcomplaint message	→		Masternode sends the requested complaints
Justification Phase			Send justification responses for any complaints against own contributions (intra-quorum communication)
inv message (qjustify)	→		Masternode sends inventory for any justifications to other masternodes in the quorum
	←	getdata message (qjustify)	Peer(s) respond with request for quorum justifications
qjustify message	→		Masternode sends the requested justifications
Commitment Phase			Send premature commitment containing the quorum public key (intra-quorum communication)
inv message (qpcommit)	→		Masternode sends inventory for its premature commitment to other masternodes in the quorum
	←	getdata message (qpcommit)	Peer(s) respond with request for quorum premature commitment
qpcommit message	→		Masternode sends the requested premature commitment
Finalization Phase			Send final commitment containing the quorum public key
inv message (qfcommit)	→		Masternode sends inventory for its premature commitment to all peers
	←	getdata message (qfcommit)	Peer(s) respond with request for quorum final commitment
qfcommit message	→		Masternode sends the requested final commitment

LLMQ Signing Session

The following table details the data flow of P2P messages exchanged during an LLMQ signing session. These sessions take advantage of BLS threshold signatures to enable quorums to sign arbitrary messages. For example, Dash Core 0.14 uses this capability to create the quorum signature found in the clsig message that enables ChainLocks.

Please read DIP7 LLMQ Signing Requests / Sessions for additional details.

LLMQ Signing Session Data Flow

Masternode	Direction	Peers	Description
Siging Request Phase			Request quorum signing of a message (e.g. InstantSend transaction input) (intra-quorum communication)
qsigsesann message	→		Masternode sends a signing session announcement to other masternodes in the quorum
Share Propagation Phase			Members exchange signature shares within the quorum (intra-quorum communication)
qsigsinv message	→		Masternode sends one or more quorum signature share inventories to other masternodes in the quorum May occur multiple times in this phase
	←	qgetsigs message (qcontrib)	Peer(s) respond with request for signature shares May occur multiple times in this phase
qbsigs message	→		Masternode sends the requested batched signature share(s) May occur multiple times in this phase
Threshold Signature Recovery Phase			A recovered signature is created by a quorum member once valid signature shares from at least the threshold number of members have been received
qsigrec message	→		Masternode sends the quorum recovered signature to all peers (except those that have asked to be excluded via a qsendrecsigs message)

Note the following timeouts defined by Dash Core related to signing sessions:

Parameter	Timeout, sec	Description
SESSION_NEW_SHARES_TIMEOUT	60	Time to wait for new shares
SIG_SHARE_REQUEST_TIMEOUT	5	Time to wait for a requested share before requesting from a different node
SESSION_TOTAL_TIMEOUT	300	Time to wait for session to complete

Quorum Selection

Quorum Type	Members	Consensus	Description
Classic (non-LLMQ) InstantSend	10	Majority	A set of 10 masternodes are selected for each input of the InstantSend transaction. A majority (6+) of them must agree to lock the input. If all inputs in the transaction can be locked, it becomes a successful InstantSend.
MN Payments	10	Majority	A set of 10 masternodes are selected for each block. A majority (6+) of them must agree on the masternode payee for the next block.
MN Broadcast	10	Majority	Deprecated by DIP3 (deterministic masternode list) in Dash Core 0.13. If a majority (6+) of nodes agree, a new mnb message is not required.