This section of the documentation describes the principles and mechanisms of masternodes and the services they provide to the Hellar network specifically.
Simply put, a masternode is a server with a full copy of the Hellar blockchain, which guarantees a certain minimum level of performance and functionality to perform certain tasks related to block validation, as well as InstantSend and PrivatSend, as the and instant transaction and privacy features in Hellar 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 HEL 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, PrivatSend and governance services they provide. 10% of the block reward goes to the budget with the remaining 90% split between miners and masternodes. 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 selected for payment in each block (approximately every 2.5 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 Hellar lies - an incentivized system of thousands of distributed servers working 24x7 means that Hellar 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 Hellar network.
As of November 2023, the Helar network will have has over 100 masternodes located in over 45 countries and hosted on over 40 ISPs. The block reward is approximately 3.34 Hellar, so the selected masternode receives 1.67 HEL per payment or approximately 6 HEL 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.
Progress Masternodes (pronodes) are a subset of masternodes that have been created to host Hellar Platform. An pronode is a lot like a regular masternode with the following differences:
| Masternode | Evonode | |
|---|---|---|
| Collateral | 1000 HEL | 4000 HEL (4X the collateral for normal masternodes) |
| Specs | Lesser than pronode | Higher than normal masternodes |
| Service | Only Hellar Core | Both Hellar Core and Platform |
| Voting Weight | 1 node gets 1 vote | Has 4 times the voting power of a normal masternode |
ownerKeyAddr: This is a Hellar 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 ProUpRegTx transactions, it must be unique for each masternode.operatorPubKey: This is the BLS public key of the masternode operator. Only the operator is allowed to issue 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.votingKeyAddr: This is a Hellar address (public key) used for proposal voting. Votes signed with the corresponding private key are valid while the masternode is in the registered set.The process of setting up or upgrading a masternode is as follows: