.. meta::
:description: Explanation of how Dash masternodes work in theory and practice to support InstantSend, CoinJoin and governance
:keywords: dash, masternodes, hosting, linux, payment, instantsend, coinjoin, privatesend, governance, quorum, evolution, bls,
.. _understanding_masternodes:
=========================
Understanding Masternodes
=========================
Overview
========
.. raw:: html
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 with a full copy of the Dash
blockchain, which guarantees a certain minimum level of performance and
functionality to perform certain tasks related to block validation, as
well as InstantSend and CoinJoin, as the and instant transaction and
privacy 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 :ref:`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 DASH collateral.
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 InstantSend, CoinJoin and
governance services they provide. 20% of the block subsidy goes to the budget
with the remaining 80% split between miners and masternodes per this
:ref:`block reward reallocation table `.
Then, every 16,616 blocks (approximately 30.29 days), a
superblock is created that contains the entire 20% payout to the budget
proposal winners. Masternodes are selected for payment in each block
(approximately every 2.6 minutes) from a deterministic masternode list,
and moved to the back of the list after payment. As more masternodes are
created, the duration between payments increases. 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 July 2024, the Dash network has `over 3000 masternodes located
`_ in `over 20
countries `_ and
hosted on `over 140 ISPs
`_. The block
reward is approximately 1.9 Dash, so the selected masternode receives
1.4 Dash per payment or approximately 6.5 Dash per month. The block
reward decreases by 7.14% approximately once per year, so the annual
earnings for a masternode owner is approximately 7% of the collateral,
and will decrease over time `as calculated here
`_.
See `this tool `_ to calculate
real-time payment rates, and `this site
`_ for various real-time
statistics on the masternode network.
Evolution Masternodes (evonodes)
--------------------------------
Evolution Masternodes (evonodes) are a subset of masternodes that have been created to host Dash
Platform. Evonodes are similar to regular masternodes, but have these differences:
+----------------+-----------------------------------+--------------------------------+
| | Masternode | Evolution Masternode |
+================+===================================+================================+
| Collateral | 1000 DASH | 4000 DASH |
+----------------+-----------------------------------+--------------------------------+
| Service(s) | Only Dash Core | Both Dash Core and Platform |
+----------------+-----------------------------------+--------------------------------+
| Voting Weight | 1 (collateral amount / 1000) | 4 (collateral amount / 1000) |
+----------------+-----------------------------------+--------------------------------+
Evonodes also have :hoverxref:`higher hardware requirements ` than regular
masternodes due to the additional Dash Platform services they host. See `DIP28
`_ for more information about evonodes.
.. _mn-concepts:
Masternode Concepts
===================
A list of available documentation appears below:
- `DIP003 Deterministic Masternode Lists `__
- :ref:`Full masternode setup guide `
- :ref:`Information for users of hosted masternodes `
- :ref:`Information for operators of hosted masternodes `
Important concepts:
- Masternodes are "registered" and begin offering services when a `ProRegTx
`_
`special transaction
`_ containing a
particular key is written to the blockchain.
- The ProRegTx references the transaction id (txid) and index holding the
collateral. The IP address and port of the masternode are also defined in this
transaction.
- The ProRegTx contains 2 Dash addresses (also called public keys) and one BLS
public key, which represent 3 different roles in the masternode and define
update and voting rights. The keys are:
1. ``ownerKeyAddr``: This is a Dash address (public key) controlled by
the masternode owner. It is different from the address used for the
collateral. Because the owner uses the private key associated with
this address to issue :ref:`ProUpRegTx `
transactions, it must be unique for each masternode.
2. ``operatorPubKey``: This is the BLS public key of the masternode
operator. Only the operator is allowed to issue :ref:`ProUpServTx
` transactions. Because the operator key is
used during live masternode operation to sign masternode-related
P2P messages, quorum-related messages and governance trigger votes,
the BLS key must be unique for each masternode.
3. ``votingKeyAddr``: This is a Dash address (public key) used for
proposal voting. Votes signed with the corresponding private key
are valid while the masternode is in the registered set.
- Masternode owners should specify an address different from the collateral to
receive payments in the ProRegTx. The owner may optionally specify a non-zero
percentage as payment to a separate masternode operator, if applicable.
- The masternode configuration can later be updated using ProUpServTx,
ProUpRegTx and ProUpRevTx transactions. See `Updating Masternode
Information `_
in DIP003 and :ref:`update-dip3-config` in this documentation for more
details.
The process of setting up or upgrading a masternode is as follows:
1. Set up your server and operating system
2. Install the Dash software and synchronize the blockchain
3. Generate a BLS key pair and enter the private key on the masternode
4. Prepare a ProRegTx transaction
5. Sign the ProRegTx transaction
6. Submit the signed ProRegTx transaction
Step 1 can be omitted if you have an existing server. Steps 2 and 3
require direct access to the masternode. Steps 3 and 4 require access to
a Dash Wallet (or DMT). Step 5 requires access to the wallet actually
holding the collateral. Step 6 requires a Dash balance to pay the
transaction fee.
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).
:ref:`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 (CoinJoin), 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:
80% of the block subsidy is split between the miner and a masternode
per the distribution found :ref:`here `, while
20% 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 DASH collateral. 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.
.. _payment-logic:
Payment logic
=============
Masternodes payments all originate on the Core chain. The Core chain pays out 62.5% of the
masternode portion of Core block rewards. The remaining 37.5% is put into the :term:`credit pool`
and used for evonode rewards on Platform. Masternodes and evonodes also receive a portion of
transaction fees on the Core chain, while evonodes receive all fees from Platform.
Because the reward distribution percentages are fixed, the number of evonodes is
expected to stabilize around a fixed number based on the total number of
masternodes (considering the current number of ~3850 Masternodes, ~450 evonodes
are expected). This is because if there are more than that fixed number of evonodes,
running a regular MN will be more profitable than running an evonode, and hosts
will convert their evonodes into MNs.
.. _payment-logic-mn_rr:
Reward reallocation
-------------------
Since the masternode reward reallocation hard fork activated in August 2024 at `block 2128896
`_,
part of the coinbase masternode subsidy is moved into the :term:`credit pool` each time a block is
mined. Now, evonodes receive a single reward per payment cycle on the Core chain instead of rewards
from four sequential blocks, as in Dash Core v19/v20.
Masternode payment frequency and payment amount have both been affected by this fork, as described in
the following sections. Although masternodes initially saw a significant drop in rewards, a
market-driven point of equilibrium between regular masternodes and evonodes is expected where
rewards are similar to what they were before the fork.
.. tip::
Until the network reaches a point of equilibrium, the number of masternodes and evonodes is expected
to fluctuate. As more masternodes are converted to evonodes, payment frequency (and therefore rewards)
on the Core chain will continue to increase. See the `Evonode FAQ `_,
`DIP28 `_, and
the `proposal approving evonodes `_ for more information.
Payment frequency
~~~~~~~~~~~~~~~~~
The frequency of Core chain masternode payments has increased as fewer payments are made per cycle.
Around the time of the hard fork, the network had approximately 2600 enabled masternodes and
approximately 175 enabled evonodes. This resulted in a reduction from 3330 payments per cycle
(``2600 + (175 * 4)``) before the fork to only 2775 (``2600 + 175``) after the fork. See the
following table for the outcomes of this change.
+-------------------+-----------+-----------+------------+-----------------------+
| | Pre-fork | Post-fork | Difference | Outcome |
+===================+===========+===========+============+=======================+
| Payment (blocks) | 3300 | 2775 | -525 | More frequent payment |
+-------------------+-----------+-----------+------------+-----------------------+
| Payment (days) | 5.73 | 4.82 | -0.91 | More frequent payment |
+-------------------+-----------+-----------+------------+-----------------------+
| Payments / year | 64 | 76 | 12 | More payments |
+-------------------+-----------+-----------+------------+-----------------------+
Payment amount
~~~~~~~~~~~~~~
The increased payment frequency is balanced against the reduction per-block payment amount on the
Core chain. This reduction resulted from the moving of some funds to the credit pool for Dash
Platform. The table below compares the miner, credit pool, and Core chain masternode payments from a
`block immediately before
`_
the hard fork with the `block immediately after it
`_.
+--------------+------------+------------+-------------+
| Category | Pre-Fork | Post-Fork | Difference |
+==============+============+============+=============+
| Miner | 0.48 | 0.48 | No change |
+--------------+------------+------------+-------------+
| Credit pool | 0 | 0.54 | **+0.54** |
+--------------+------------+------------+-------------+
| Masternode | 1.43 | 0.89 | **-0.54** |
+--------------+------------+------------+-------------+
| **Total** | 1.91 | 1.91 | No change |
+--------------+------------+------------+-------------+
.. tip::
As more masternodes are converted to evonodes, payment frequency will increase,
and the difference between overall pre-fork and post-fork rewards per year on
the Core chain will decrease.
.. _payment-logic-core:
Core block rewards
------------------
Since Dash version 0.13.0, masternode payments are entirely deterministic
and based on a simple list sort algorithm. Dash version 0.13.0 implemented `DIP003
`_ which defines
two sets of masternodes.
1. The full set, which contains all registered masternodes that have not
spent their collateral funding transactions.
2. The valid set, a subset of the full set which contains all
masternodes which are not marked as Proof of Service (PoSe) banned.
Each masternode in the set of valid masternodes, identified by its
registration transaction ID, is associated with the block at which it
was last paid. If it has never received payment or was banned for
failing to meet the PoSe requirements, then the block at which it was
first registered or at which service was restored is used instead. The
list is sorted in ascending order by this block height and ProRegTx hash
(as a tie breaker in case two masternodes were registered in the same
block), and the first entry is selected for payment.
The Core block reward rules apply uniformly to regular masternodes and evonodes. Each are paid once
per payment cycle and receive the same block subsidy amount.
.. _payment-logic-platform:
Platform rewards
----------------
Evonode rewards are based on participation in Platform consensus. Specifically, evonodes are paid
for the blocks they propose while in the active validator set. At the end of each Platform epoch
(9.125 days), block rewards are paid to the masternode identities associated with the participating
evonodes.
.. _proof-of-service:
Proof of Service
================
Proof of Service (PoSe) is a scoring system used to determine if a
masternode is providing network services in good faith. A number of
metrics are involved in the calculation, so it is not possible to game
the system by causing masternodes to be PoSe banned for failing to
respond to ping requests by e.g. a DDoS attack just prior to payment.
Each failure to provide service results in an increase in the PoSe score
relative to the maximum score, which is equal to the number of
registered masternodes. If the score reaches the number of registered
masternodes, a PoSe ban is enacted and the masternode must be repaired
to ensure it provides reliable service and registered in the list again
using a :ref:`ProUpServTx `. The current scoring
rules as of Dash 0.14 are:
- Failure to participate in `DKG `__\ = 66% punishment
- Each subsequent block reduces PoSe score by 1
Quorum selection
================
In past versions of Dash, quorums of 10 masternodes were formed
spontaneously to lock InstantSend transactions. As of Dash 0.14, quorums
are deterministically formed, contain more masternodes and remain alive
for a longer period of time. While they remain responsible for
InstantSend transactions, the locking mechanism has changed to
automatically attempt locks on most network transactions according to
the requirements described :ref:`here `. Masternodes are
now also responsible for more network consensus functions, such as
:ref:`ChainLocks `. Masternode quorums are formed through a
process of `distributed key generation `__.
Failure to participate in DKG will eventually result in a PoSe ban as
described above.
.. _mn-hardware-reqs:
Masternode requirements
=======================
- DASH collateral: Hosting a masternode requires a large amount of DASH collateral.
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 22.04
LTS. We recommend VPS services such as Vultr and DigitalOcean,
although any decent provider will do.
- A dedicated IP address: These usually come with the VPS/server.
In addition to the DASH held in collateral, masternodes also have
minimum hardware requirements. For Dash versions 20.0 and higher, these
requirements are as follows:
.. _mn-hardware-reqs-table:
Regular masternodes
-------------------
+---------+------------------+------------------+
| | Minimum | Recommended |
+=========+==================+==================+
| CPU | 2x 2 GHz | 3x 2 GHz |
+---------+------------------+------------------+
| RAM | 4 GB + 2 GB swap | 8 GB + 4 GB swap |
+---------+------------------+------------------+
| Disk | 60 GB | 80 GB |
+---------+------------------+------------------+
| Network | 750 GB/mth | 1 TB/mth |
+---------+------------------+------------------+
.. _evonode-hardware-reqs-table:
Evonodes
--------
Evonodes have higher hardware requirements since they host Dash Platform services along with Dash
Core. To support the network effectively, the following requirements are recommended:
+---------+------------------+
| | Recommended |
+=========+==================+
| CPU | 4x 2.4 GHz |
+---------+------------------+
| RAM | 8 GB + 2 GB swap |
+---------+------------------+
| Disk | 200 GB |
+---------+------------------+
| Network | 1 TB/mth |
+---------+------------------+
Masternode bandwidth use varies and will grow as the network does.