Secure Nodes

About

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.

Secure Node Criteria

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.

Must maintain a balance of at least 42 ZEN in a 'stake' transparent address

Must maintain a minimum balance of .001 ZEN in a private address on the node for challenges

Must be available with minimal exception time for at least 92% of an earning period (approx. 1 day)

Must perform a challenge within 300 or under seconds

Must not restrict peer connections (no maxconnection=) by allowing public connections on the configured zen port (default 9033)

Must maintain a valid public SSL cert properly configured for zen

Must not fall behind the current block height by more than 4 blocks

Must update to current versions of the zen and/or tracker software within the posted time frame

Must dedicate the host for the sole use as a Secure Node and provision the required level of resources (CPU, RAM/SWAP, Disk space) to consistently meet the eligibility criteria

Must not add, or utilise additional transparent addresses, except for approved applications

Note: only one public Ip address is allowed per secure node tracker (IPv4 or IPv6). The node tracker must match the zend ip address.

General Secure Node expectations:

Maintain the full block chain

Run on a secured system (firewall, restricted logins, etc.)

Keep the node OS updated, patched

Periodically check for notices of updates, issues, etc.

Earnings

An earning period is based upon block time. It is the amount of time between 576 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.

Coins are then transferred to a payment address and the payment is made. No funds are stored on the server. This process may be automated at a later time.

Challenges

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.

Certificates

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

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 time an exception is open is subtracted from the earnings.