Masternodes, once unique to the Dash network, are now becoming popular as the technology is forked into other blockchains. This section of the documentation describes the principles and mechanisms of masternodes and the services they provide to the Dash network specifically.
Simply put, a masternode is a server connected to the network which guarantees a certain minimum level of performance and functionality to perform certain tasks related to PrivateSend and InstantSend, as the anonymity and instant transaction features in Dash are called. The masternodes are paid for this service, using a concept known as Proof of Service. This is in addition to the Proof of Work done by miners to secure the blockchain. Masternodes are also allowed to vote on governance and funding proposals, with each masternode receiving one vote (yes/no/abstain) on each proposal submitted to the system.
Anyone can run a masternode. The objective is to have enough decentralization to ensure that no single person controls a significant fraction of the masternodes. However, to avoid bloating the network with unnecessary masternodes or encouraging reckless operators, there is one condition that needs to be fulfilled: proof of ownership of 1000 Dash. The coins don’t need to be in the masternode, but they need to be kept in a certain way that is transparent to the entire network. If the owner moves or spends those coins, the masternode stops working and payment ceases.
Masternodes are paid by the network for the PrivateSend, InstantSend and governance services they provide. 45% of the block reward is paid out to the masternodes, 45% to miners and 10% to the budget. In practice, half of the reward from a normal block goes to the miner and half to the masternode. Then, every 16,616 blocks (approximately 30.29 days), a superblock is created that contains the entire 10% payout to the budget proposal winners. Masternodes are randomly selected for payment in each block (approximately every 2.6 minutes) from a list once they reach the top 10% of the total count of masternodes, and moved to the back of the list after payment. As more masternodes are created, the duration between payments increases. Due to the selection algorithm, there is always an aspect of randomness to payment selection, but in the long term all masternode owners should receive similar payments. If the collateral behind a masternode is spent, or if a masternode stops providing services to the network for more than one hour, it is removed from the list until normal service resumes. In this way, masternodes are given incentive to provide efficient and reliable services to the network.
Having so many servers holding a full copy of the blockchain and working for the coin can be extremely useful. Thanks to the reward system, there is no risk of not having enough masternodes, and the developers can rely on them quickly deploying any new decentralized feature they want to implement. This is where the true strength of Dash lies - an incentivized system of thousands of distributed servers working 24x7 means that Dash can scale more efficiently and deploy services more quickly than a blockchain run entirely by unpaid volunteers. The more masternodes, the better and safer the Dash network.
As of March 2018, the Dash network has over 4700 masternodes located in over 41 countries and hosted on over 100 ISPs. The block reward is approximately 3.34 Dash, so the selected masternode receives 1.67 Dash per payment or approximately 6 Dash per month. The block reward decreases by 7.14% approximately once per year, so the annual return on investment (ROI) to a masternode owner is approximately 7% and will decrease over time as calculated here. See this tool to calculate real-time ROI rates, and this site for various real-time statistics on the masternode network.
Masternodes vs. mining¶
Dash, like Bitcoin and most other cryptocurrencies, is based on a decentralized ledger of all transactions, known as a blockchain. This blockchain is secured through a consensus mechanism; in the case of both Dash and Bitcoin, the consensus mechanism is Proof of Work (PoW). Miners attempt to solve difficult problems with specialized computers, and when they solve the problem, they receive the right to add a new block to the blockchain. If all the other people running the software agree that the problem was solved correctly, the block is added to the blockchain and the miner is rewarded.
Dash works a little differently from Bitcoin, however, because it has a two-tier network. The second tier is powered by masternodes (Full Nodes), which enable financial privacy (PrivateSend), instant transactions (InstantSend), and the decentralized governance and budget system. Because this second tier is so important, masternodes are also rewarded when miners discover new blocks. The breakdown is as follows: 45% of the block reward goes to the miner, 45% goes to masternodes, and 10% is reserved for the budget system (created by superblocks every month).
The masternode system is referred to as Proof of Service (PoSe), since the masternodes provide crucial services to the network. In fact, the entire network is overseen by the masternodes, which have the power to reject improperly formed blocks from miners. If a miner tried to take the entire block reward for themselves or tried to run an old version of the Dash software, the masternode network would orphan that block, and it would not be added to the blockchain.
In short, miners power the first tier, which is the basic sending and receiving of funds and prevention of doublespending. Masternodes power the second tier, which provide the added features that make Dash different from other cryptocurrencies. Masternodes do not mine, and mining computers cannot serve as masternodes. Additionally, each masternode is “secured” by 1000 DASH. Those DASH remain under the sole control of their owner at all times, and can still be freely spent. The funds are not locked in any way. However, if the funds are moved or spent, the associated masternode will go offline and stop receiving rewards.
Masternode payments in Dash version 12 are determined using a completely decentralized deterministic queue with probabilistic selection.
Every masternode appears in the global list. Their position in this list is determined by their time since the last payment according to the network, not the blockchain. New masternodes joining the network and masternodes receiving payment are placed at the end of the list. Running, active masternodes which are restarted using the rpc commands ‘masternode start’ or ‘masternode start-alias’ are also placed at the end of the list. Using the new rpc command ‘masternode start-missing’ avoids this. As masternodes are moved to the end of the global list, the remaining masternodes slowly migrate towards the top of the list. Once a masternode reaches the top 10% of the global list, it is eligible for selection from the selection pool.
The selection pool is the top 10% of the global list. Its size is determined by the total masternode count. As an example, if there are 4500 active masternodes, the top 450 masternodes in the global list are eligible for selection. Once in the selection pool, selection for payment is determined by block hash entropy. The block hash 100 blocks ago determines which masternode will be selected for payment. A double SHA256 of the funding transaction hash and index for all masternodes in the selection pool is compared with the proof of work hash 100 blocks ago. The masternode with the closest numeric hash value to that block hash is selected for payment.
Because selection is determined by block hash entropy, it is impossible to predict when a payment will occur. Masternode operators should expect considerable variance in payment intervals over time. Once a masternode enters the selection pool, payments become a probability. The probabilities in this example are calculated using an assumed current pool size of 450 (at 4500 total masternodes). Nodes in the selection pool are selected for rewards randomly, i.e. the probability of being selected on any given block is 1/450.
The table below shows the probably of an eligible node being selected for payment over a particular period of time. For example, the probability that an eligible node is selected within 12 hours is about 46%. The table does not (and cannot) tell us the probability of being selected after a given period of time. For example, if you haven’t been selected within the past 12 hours — and we know from this table there is about a 54% chance of that happening — the probability of being selected on the next block is not 46%. It remains 1/450. Putting these together, if you have an eligible node, and, say, 48 hours have passed without payment, then you’ve been very unlucky, as there’s less than a 10% chance of that happening. But, your chances of being selected on the next block remain the same as for any block, i.e. 1/450.
Once a node is selected for payment, it is moved to the back of the list and cannot be selected again until it re-enters the selection pool.
You can run the code (written by community member moocowmoo used to create the table above here.
InstantSend transactions in Dash version 12 are secured using a consensus of deterministically selected masternodes. This set of masternodes is informally termed a quorum and must be in a majority agreement, at least six out of ten, for a successful lock of the transaction inputs. Multiple quorums are self-selected for each input in an InstantSend transaction using the mathematical distance between the hash of each input and of the set of masternode funding transactions.
Each masternode receiving the InstantSend transaction lock request compares the hash of the masternode’s funding transaction to the hash of the input requesting the lock. After validating the inputs are not spent, the ten masternodes furthest from this hash broadcast their acceptance of the lock.
All InstantSend inputs must be at least six blocks old or the transaction will be rejected.
- 1000 Dash: Arguably the hardest part. Dash can be obtained from exchanges such as Poloniex, Bittrex, Kraken and LiveCoin. Shapeshift’s service is also an excellent way.
- A server or VPS running Linux: Most recent guides use Ubuntu 16.04 LTS. We recommend VPS services such as Vultr and DigitalOcean, although any decent provider will do. Generally an instance with low to average specifications will do, although performance requirements will increase according to this roadmap.
- A dedicated IP address: These usually come with the VPS/server.
- A little time and (heart): Masternodes used to require complex setup, but tools such as dashman now greatly simplify the process.
In addition to the 1000 Dash held in collateral, masternodes also have minimum hardware requirements. As of version 12.1, these requirements are as follows:
|CPU||1x 1 GHz||1x 2 GHz|
|RAM||1 GB||2 GB|
|Disk||8 GB||16 GB|
|Network||400 GB/mth||1 TB/mth|
Masternode bandwidth use ranges between 300-500 GB per month and will grow as the network does.
The exact hardware requirements for Dash Evolution masternodes have yet to be determined, although some pointers can be taken from the roadmap and this blog post. It should be possible to run Dash masternodes on normal VPS servers until the block size reaches approximately 20 MB, after which custom hardware such as GPUs and eventually ASICs will be required.