Before you start - Secure Nodes

Before starting your Secure Node build, it is wise to review each of the eligibility criteria and ensure you're aware of how to meet each of them. This will prevent any wasted effort, or missed requirements when procuring and deploying a VM, VPS instance, or your own dedicated hardware.

CriteriaHow to meet

Balances

  • Maintain a balance of at least 42 ZEN, held as a stake, within a transparent (t) address where you control the private keys

Balances

Recommended minimum ZEN: per Secure Node = 42 ZEN

    • 42 ZEN for stake t address

How to stake:

    • Download Arizen or Sphere by Horizen wallet - to a separate device or computer from the Secure Node
    • Setup a wallet within Arizen or Sphere by Horizen
    • Select an unused t address from your wallet and send 42 ZEN to this t address
    • Optionally use a verified stake address created with the Stake Tool which can hold the stake for multiple nodes and pay out to other addresses

Availability / Exceptions

  • Meet, with minimal exceptions or downtime (~2hrs max), an availability target of 92% within a reward period
  • Not fall behind the current block height by more than 4 blocks
  • Maintain and run the minimum required version of zend and tracker software (upgrading 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 utilize additional transparent addresses, except for approved applications
  • There must not be more than 5 stake balance (stkbal) exceptions in one earning period

  • The stake address must not be used by other nodes (Secure or Super) at the same time

  • Must send updated stats to the tracking server on the configured schedule or when requested

  • Must only run approved nodetracker software
  • Must respond to all requests from the tracking server and allow the tracking server to update the node configuration

    • Exceptions will be triggered for nodes not responding from commands issued by the tracking server
  • Must provide the nodetracker a valid email to receive alerts and other notifications issued by the tracking server

Availability

In order to meet the uptime target, your Secure Node needs to be running 24/7, 365 days per year. This level of uptime is more easily achieved in a dedicated hosting environment i.e. dedicated hosted server, or VPS. It is possible to achieve this outside a hosted environment, but that of course requires dedicated hardware to be powered and have internet connectivity 24/7, 365 days per year.


Exceptions*

Block height - indicates that your Secure Node has downloaded fewer blocks than were generated within a certain time frame. Assuming your Secure Node is connected to the internet continuously, you will be unlikely to encounter this error


Version control - check for emails (to the address you register as part of Secure Node setup) with notifications of software version requirements, as well as the Secure Node tracker website (https://securenodes.zensystem.io/)


*A full, exhaustive list of exceptions is maintained on the Secure Node tracker website.


Network / Security

  • Must not restrict peer connections (no maxconnection= in zen.conf)
  • Must configure the zend P2P port with valid SSL/TLS certificate reachable from the outside for other nodes to connect to (zend MUST accept incoming connections from other nodes)
  • Correct reachable address and port combination are advertised to the network by zend (listed in zen-cli getnetworkinfo "localddresses" and 'reachable:true')
  • The Tracking Server must be able to establish a connection to zend directly
  • The Nodetracker must establish the outgoing connection to the tracking servers from the same IP address specified in zen.conf (externalip=)
  • Only one unique IPv4 or IPv6 is required, but it is suggested to have one of both types to help the network
  • The proper DNS record (A or AAAA) has to be in place for the same IP as configured in the zen.conf (externalip=)

Network

Unique IP address - By design, all ip addresses are required to be unique. Each Secure Node must be connected to the network via a unique IP address, which is not currently registered for use by another Secure Node or Super Node. The ip address can be ipv4, or ipv6. Standard home, or business broadband internet connections will provide a unique (generally dynamic) ipv4, or ipv6 address. Likewise, a VPS procured and used to host a Secure Node will provide an ipv4, or ipv6 address, these are usually static ip addresses.


DNS - The Secure Node public ip address must be referenced by an address mapping (A, or AAAA based on ip version) record with the fully-qualified domain name (FQDN). There are many freely available DNS registration schemes, or a paid DNS record can be used. It is also possible to add a sub domain entry to an existing DNS registration, resolving to the Secure Node ip address. The DNS entry is validated as part of the certificate-based checks to ensure it is valid for the Secure Node. NOTE: if you do not have a static ip address, as and when your ip address changes, the DNS A record must also be updated to resolve to the correct ip address.


External connectivity - in order to enable incoming connections to the zend daemon, you must ensure the port used for zend (default 9033 on mainnet) is accessible through your firewall(s). In order to achieve this, be sure to check all firewalls (host-based, modem/router if applicable, hardware firewall, VPS-panel) between the host which is running the Secure Node and the internet.


SSL/TLS Certificate - The Secure Node network mandates end-to-end encryption, in order to achieve this, a valid, non-expired SSL certificate is required. This must be generated for the FQDN used in the DNS address mapping record that resolves to the Secure Node's public ip address. You may use a paid certificate, or freely-available alternatives such as LetsEncrypt. Wildcard certificates can also be used and will, for example, allow an existing DNS record to have a sub domain added, mapped to a Secure Node using a wildcard certificate.


Before you start



© 2020 Horizen. All rights reserved.