Before you start - Super Nodes

Before starting your Super 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 500 ZEN, held as a stake, within a transparent (t) address where you control the private keys

Balances

Recommended minimum ZEN: per Super Node = 500 ZEN

    • 500 ZEN for stake t address

How to stake:

    • Download Arizen or Sphere by Horizen wallet - to a separate device or computer from the Super Node
    • Setup a wallet within Arizen or Sphere by Horizen
    • Select an unused t address from your wallet and send 500 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 (~57 minutes max), an availability target of 96% 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 sole use as a Super Node and provision the required level of resources (CPU, RAM/SWAP, Disk space) to consistently meet the eligibility criteria, a minimum of;
    • Four CPU cores
    • 8GB of RAM 
    • 100GB of available space (not including OS and main blockchain)
  • 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 Super 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 Super Node has downloaded fewer blocks than were generated within a certain time frame. Assuming your Super 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 Super Node setup) with notifications of software version requirements, as well as the Super Node tracker website (https://supernodes.zensystem.io/)


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


Network / Security

  • Zend available for inbound connections on both IPv4 and IPv6
  • Zend listening on only one IPv4 address and only one IPv6 address (two IP addresses total, onion still allowed)
  • Correct reachable address and port combination are advertised to the network by zend (listed in zen-cli getnetworkinfo "localddresses" and 'reachable:true')
  • A unique IP address for the tracker client across secure and supernodes, either IPv4 or IPv6, this address must match one of the addresses Zend runs on, specified in zen.conf (externalip=)
    • The Tracking Server must be able to establish a connection to zend directly
  • 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)
  • The proper DNS records (A and AAAA) has to be in place for the same IP (IPv4 and IPv6) as configured in the zen.conf (externalip=)

Network

Unique IP address - By design, all ip addresses are required to be unique. Each Super Node zend instance must be connected to the network via a public IPv4 and IPv6 address, which is not currently registered for use by another Super Node or Secure Node. 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 Super Node will provide an ipv4, or ipv6 address, these are usually static ip addresses.


DNS - The Super Node public ip address must be referenced by an address mapping (A and 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 Super Node ip address. The DNS entry is validated as part of the certificate-based checks to ensure it is valid for the Super 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 Super Node and the internet.


SSL/TLS Certificate - The Super 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 Super 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 Super Node using a wildcard certificate.


Before you start



© 2020 Horizen. All rights reserved.