Dash Core

Dash Core Developer Documentation

Welcome to the Dash Core developer documentation. You'll find guides and documentation to help you start working with Dash Core as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Guides

Masternode Quorums

Dash's masternodemasternode - A computer that provides second-tier Dash functionality (InstantSend, PrivateSend, decentralized governance). Masternodes are incentivized by receiving part of the block reward, but must hold 1000 Dash as collateral to prevent sybil attacks. quorums are used to facilitate the operation of masternode provided features in a decentralized, deterministic way. The original quorums (used largely for InstantSendInstantSend - InstantSend is a service that allows for near-instant transactions. Through this system, inputs can be locked to specific transactions and verified by consensus of the masternode network. 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 QuorumLong-Living Masternode Quorum - Long-Living Masternode Quorums (LLMQs) are a Dash innovation that enable masternodes to perform threshold signing of consensus-related messages (e.g. InstantSend transactions). LLMQs provide a more scalable, general use quorum system than the ephemeral ones used prior to Dash Core version 0.14. (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. ChainLocksChainLocks - ChainLocks are a feature enabling near instant consensus on the valid chain. ChainLocks use Long-Living Masternode Quroums to mitigate 51 percent attacks and reduce uncertainty when receiving funds.).

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

🚧

Minimum Masternode Protocol Version

As of Dash Core 0.16.0, masternodes perform a version check on their quorum peers during DKG. Masternodes that do not meet the MIN_MASTERNODE_PROTO_VERSION (70219 in Dash Core 0.17.0) will begin receiving increases in PoSe score once 60% of the masternodes on the network have upgraded to that version.

MasternodeDirectionPeersDescription
Initialization PhaseDeterministically evaluate if quorum participation necessary
Each quorum participant establishes connections to a set of quorum participants as described in DIP6
Contribution PhaseSend 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 messageMasternode sends the requested quorum contribution
Complaining PhaseSend 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 messageMasternode sends the requested complaints
Justification PhaseSend 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 messageMasternode sends the requested justifications
Commitment PhaseSend 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 messageMasternode sends the requested premature commitment
Finalization PhaseSend 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 messageMasternode 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 ChainLocksChainLocks - ChainLocks are a feature enabling near instant consensus on the valid chain. ChainLocks use Long-Living Masternode Quroums to mitigate 51 percent attacks and reduce uncertainty when receiving funds..

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

LLMQ Signing Session Data Flow

MasternodeDirectionPeersDescription
Siging Request PhaseRequest quorum signing of a message (e.g. InstantSend transaction input) (intra-quorum communication)
qsigsesann messageMasternode sends a signing session announcement to other masternodes in the quorum
Share Propagation PhaseMembers exchange signature shares within the quorum (intra-quorum communication)
qsigsinv messageMasternode 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 messageMasternode sends the requested batched signature share(s)
May occur multiple times in this phase
Threshold Signature Recovery PhaseA recovered signature is created by a quorum member once valid signature shares from at least the threshold number of members have been received
qsigrec messageMasternode 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:

ParameterTimeout, secDescription
SESSION_NEW_SHARES_TIMEOUT60Time to wait for new shares
SIG_SHARE_REQUEST_TIMEOUT5Time to wait for a requested share before requesting from a different node
SESSION_TOTAL_TIMEOUT300Time to wait for session to complete

Quorum Configuration

Mainnet and Testnet only use quorums of pre-defined sizes that are hard coded into Dash Core. RegTest and Devnet environments each have a quorum that supports custom size and threshold parameters that are controlled via command line or configuration file parameters (llmqtestparams/llmqdevnetparams).

A list of all the quorums and their default sizes can be found in the Current LLMQ Types table found in DIP-6.

Updated 3 months ago


What's Next

Proof of Service

Masternode Quorums


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.