Basic operation of the Masternodes
In this section, we will go deeper into the subject of Masternodes to fully understand the basic operations of a Masternode.
Masternodes are paid by the network for their services PrivateSend, InstantSend and Governance. For example, at Dash, 45% of the block rewards go to the Masternodes, 45% to the miners and 10% to the budget. In practice, half of the reward goes from a normal block to the miner and a half to the masternodes. Then every 16,616 blocks (approximately 30.29 days) a superblock is created. This superblock contains the entire payout of 10% to the winners of the budget proposal. Master nodes are selected for payment in each block (approximately every 2.6 minutes) from a deterministic master mode list and moved to the back edge of the list after payment. As more master nodes are created, the duration between payments increases. If the security is delivered past a master node or a master node is no longer providing services to the network for more than an hour, it will be removed from the list until the normal service becomes available again. In this way, Masternodes receive an incentive to provide the network with efficient and reliable services.
It can be very useful to have so many servers with a complete copy of the blockchain and to work for the coin. Thanks to the reward system, there is no risk of not having enough masterternodes. Developers can count on them to quickly provide new decentralized features that they want to implement. This is the true power of projects that have implemented masternodes in their blockchain. With a system of thousands of distributed servers running around the clock, these projects can scale more efficiently and deliver services faster than a blockchain operated by unpaid volunteers. The more Masterternodes, the better and safer the network of the respective cryptocurrency.
For example, Dash, like Bitcoin and most other crypto currencies, is based on a decentralized ledger of all transactions called blockchain. This blockchain is backed by a consensus mechanism. In the case of Dash and Bitcoin, the consensus mechanism is a proof of work (PoW). Miners try to solve difficult problems with specialized computers. When they solve the problem, they get the right to add a new block to the blockchain. If all other people running the software agree that the problem has been resolved correctly, the block will be added to the blockchain and the miner will be rewarded.
Dash works a bit differently than Bitcoin because it has a two-tier network. The second layer is powered by the Masternodes (Full Nodes), which provide financial privacy (PrivateSend), instant transactions (InstantSend) and the decentralized governance and budgeting system. Since this second shift is so important, Masternodes are also rewarded when miners discover new blocks. The split is as follows: 45% of the block reward goes to the miner, 45% to the masternodes, and 10% is reserved for the budget system (created each month by super blocks), as described above.
The Masternode system is referred to as a proof of service (PoSe) because the master nodes provide crucial services to the network. In fact, the entire network is monitored by the master nodes, which have the ability to reject improperly formed blocks of miners. If a miner attempted to take over the entire block reward or run an old version of the Dash software, that block would have been orphaned by the masternode network and would not be added to the blockchain.
In short, the miners operate the first level, which requires the basic sending and receiving of funds, and prevent expenses from being incurred. Masternodes operate the second layer, which provides additional features that distinguish Dash from other cryptocurrencies, for example. Very important to understand is that Masternodes themselves do not break down blocks, and that mining computers can not perform the services of Masternodes. In addition, each master mode is backed by a certain amount of coins deposited as collateral. At Dash it's 1000 Dash. These coins are, at all times, under the sole control of their holder and may continue to be freely distributed. The funds are not blocked in any way. However, when the money is moved or spent, the associated masternode goes offline and receives no rewards.
Masternode payments are fully deterministic and based on a simple list sorting algorithm.
- The complete set, which contains all registered master nodes that have not spent their collateral financing transactions.
- The valid set, a subset of the full set that contains all master nodes that are not marked as proof of service (PoSe), is prohibited.
All master nodes, in the set of valid master nodes identified by their registration transaction ID, are associated with the block on which they were last paid. If they have never received a payment or have been suspended for non-compliance with PoSe requirements, the lock will be used instead, upon which they were first registered or restored. The list is sorted in ascending order of this block height and the ProRegTx hash (as a disconnect switch in the event that two master nodes have been registered in the same block). The first entry is selected for payment.
PoSe is a rating system that determines if a masternode provides network services in good faith. A number of metrics are included in the calculation. Therefore, it is not possible to play in the system by locking Masternodes for PoSe because it has not responded to ping requests, e.g. By a DDoS attack immediately before payment. Any failure to provide services results in an increase in PoSe score relative to the maximum score that matches the number of master nodes in the valid set. If the score reaches the number of master deaths in the valid sentence, a PoSe ban will be issued. Then, the masternode needs to be repaired to ensure a reliable service and be re-registered with a ProUpServTx.
InstantSend transactions are backed up with a consensus of deterministically selected masternodes. This group of Masternodes is informally referred to as a quorum and must be at least six out of ten in a majority agreement in order to successfully block the transaction receipts. Multiple quorums are selected for each entry in an InstantSend transaction itself, using the mathematical distance between the hash of each entry and the amount of masternode financing transactions. Each master node receiving the InstantSend transaction flush request compares the hash of the funding transaction of the master node with the hash of the input requesting the lock. After validating the inputs, the inputs are not output and the ten farthest master nodes match the acceptance of the lock. All InstantSend entries must be at least six blocks old, otherwise the transaction will be rejected.
Most of this information was acquired and generalized by Dash Core, for the most part.