Tracking & Payment System: Beta(mainnet)
Secure Nodes employ encrypted communication to other nodes and wallets. They also are intended to provide services to applications like mobile wallets at a later time.
Each of the Secure Nodes connect to this system which tracks the state of the node. This server helps ensure a healthy network by periodically sending challenges to nodes to prove capability. The tracking system is completely independent of any Horizen transaction processing. It provides a means for node operators to share a small portion of the block generation rewards.
Payments based on a 10.0% percentage of the mined block reward are split between all Secure Nodes that adhere to the criteria below.
Situations such as down time, low stake balance and other exceptions are factored into the payment.
For more information visit horizen.global
Each of the following criteria must be met and maintained for a Secure Node to be eligible to recieve a share of the reward pool.These items may be added to or modified at any time. Criteria may change at any time.
Note: only one public Ip address is allowed per secure node tracker (IPv4 or IPv6). The node tracker must match the zend ip address.
An earning period is based upon block time. It is the amount of time between 572 blocks which is approximately 24 hours. When an earning period ends each active node is checked and any node with exceptions or downtime causing the node to be available less than 92% of the earning period is excluded from the earnings pool. A node with greater than 92% availability but with some downtime or exceptions will have the amount of time subtracted from their allocation. These small subtractions help offset the fees incurred with making the payments.
A payment administrator on a weekly basis reviews the earnings to ensure they were generated correctly and marks them to be paid.
Funds are then transferred to a payment address and the payment is made to each node's stake address. No funds are stored on the server.
A challenge is meant to prove the capability of a node and is sent to a node on a periodic basis. A challenge consists of a random block being chosen from the blockchain by the server, the server sending a challenge to a node, the node looking up specific information about the block and then creating a private transaction to send the result to the server via the blockchain. The node also replies to the server with the transaction id and the server looks up transaction and determines if the information matches once the block with the new transaction reaches the server.
A certificate issued by a Certificate Authority(CA) such as Let's Encrypt must be configured for a Secure Node. Even though zen is capable of using a self-signed cert, a CA issued cert is required to participate in the payments. The tracking server checks the hostname via DNS and verifies the certificate. It will first try a direct connection with a node and if there are connection issues it will check peer connections for a verified TLS connection.
Exceptions are logged and tracked when a node does not comply with the criteria listed above. Exceptions are listed on the Details page of a node. There should be only one Exception open at a time even if there are multiple conditions that may apply. When an Exception is closed an End time is present in the Exception. The duration of time an exception is open counts toward the uptime earnings calcuation.
Comprehensive installation and maintenance guides are available:
All grid tables are provided by jqgrid under a non-commecial CC BY-NC 3.0 license.