The Dash network has tightened its standards for masternodes, resulting in hundreds of nodes going offline due to the new performance requirements.

Last week, Dash’s DKG (distributed key generation) spork was activated, spurring the creation of long-living masternode quorums (LLMQs) for a new way of running the Dash network, enabling innovations such as ChainLocks 51% attack-proofing. As part of the upgrade, masternodes, in addition to simply remaining online, now have to provide consistent service benchmarks to the network, and receive a score based on service provided:

“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 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″

    Masternodes that do not meet the newly-implemented service standards can be banned from the network until these issues are rectified.

    About 95% of the network remains standing after the stricter standards

    Despite the implementation of stronger service requirements for masternodes, the vast majority of the network has remained standing. Since implementation, over 200 masternodes have dropped offline, reducing counts from a recent high of 4,945 to a present figure of 4,704, with totals briefly dipping below 4,700 before some nodes were brought back online. Even with this drop, however, over 95% of the masternode network has remained active, indicating that most of the network was already performing at high levels.

    In recently-released documentation, the Dash developers outlined some of the steps a masternode operator should take in case it has been banned:

    “If your masternode fails to provide service to the network in accordance with the current consensus rules, it will receive a Proof of Service Ban. If your masternode is in the POSE_BANNED status, you should check the following settings are configured correctly:

    • Ensure you are running the latest version of Dash
    • Ensure your masternode has sufficient memory, swap, processing power and hard drive space
    • Ensure you are fully synced to the correct blockheight, and that you are on the correct chain and not forked off
    • Ensure that a BLS private key is specified using the masternodeblsprivkey option in the masternode’s dash.conf file
    • Ensure that the BLS private key on the masternode is unique on the network and not shared with any other masternodes
    • Ensure that the BLS private key on the masternode corresponds to the BLS public key registered on the blockchain in the ProRegTx or ProUpRegTx
    • Ensure that the externalip (and port if using testnet) are specified correctly and not blocked by a firewall or port forwarding service
    • Ensure that Sentinel is installed, updated, not exiting with an error and is entered in your crontab to run every 1-2 minutes”

    While including a collateral element of proving ownership of 1,000 Dash in order to operate, masternodes are not compensated for their stake, but rather for the service they provide to the network, with masternode rewards as compensation for a service rather than interest on investment.

    Dash’s hashrate reaches a new high as the network becomes more robust

    In addition to masternode performance improving due to the new proof-of-service standards, Dash’s mining network has improved as well. This week, Dash’s hashrate has reached a new all-time high of 3.688 petahashes, beating the previous high of 3.537 petahashes achieved in early May. This indicates that the security provided by the mining network is also rising with the masternode network’s growth of robustness following the new standards.

    In addition to network security growing with a higher hashrate, a newly-implemented, soon-to-be-activated feature promises to dramatically increase network security further. The addition of ChainLocks, included in the version 0.14 which was recently released, uses the masternode network to protect against mining attacks such as 51% attacks, selfish mining, and secret mining. This purely-defensive implementation, soon to be activated, allows masternodes to significantly overhaul network security while still leaving the power to process blocks and transactions entirely in the miners’ hands, meaning an attacker intending to reverse transactions would need control over both the mining and masternode network, not simply one or the other.