The sentinel

An important component of the Nyzo network is the sentinel. To go in-depth about the role of the sentinel, it is necessary that we first set up a Nyzo sentinel on a new Virtual Private Server (VPS).

Details on how to accomplish this have been laid out on the 'How to set up a sentinel' page, found in the 'Getting started' section of the Knowledgebase.

Initial configuration of the sentinel

Similar to the configuration procedure of a verifier, but with important distinctions in regards to selecting and configuring the run mode of the nyzoVerifier software.

During the installation process, various events take place:

• a directory /home/ubuntu is created (non-AWS installation only)
• port 9444 is opened for incoming and outgoing TCP connections
• port 9446 is opened for incoming and outgoing UDP connections
• the linux distribution is updated through apt
• haveged is installed on the machine
• openjdk-8 is installed on the machine
• supervisor is installed on the machine
• git is installed on the machine
• the nyzoVerifier repository is cloned
• the cloned files now residing in /home/ubuntu/nyzoVerifier are compiled using gradlew
• a new directory is created: /var/lib/nyzo/production
• the nyzoSentinel.conf file is copied to the /etc/supervisor/conf.d directory to configure supervisor
• the managed_verifiers file is configured by the node operator
• supervisor is initiated using the sudo supervisorctl reload command
• the status of the supervisor application is displayed using the sudo supervisorctl status command
• an entry for the sudo supervisorctl reload command is added as a cronjob, to enable automatic execution after reboot

nyzoSentinel.conf

The nyzoSentinel.conf file is used to correctly configure the supervisor.
The supervisor package available for linux distributions, essentially, as the name suggests, supervises the particular process under the parametered conditions specified in the configuration file.

The parameters set forth in the file by default excert the following behavior on the process:

• autostart is enabled
• autorestart is enabled
• the minimum amount of time the process needs to stay up and running to be considered a successful start is 10 seconds and is configured using the startsecs parameter
• the maximum amount of iterations the supervisor will go through, when the startsecs parameter condition is not met in a consecutive amount of times is by default 20 and is configured using the startretries parameter. After this condition is met, the process resides in a FATAL state
• regular output by the process is by default written to /var/log/nyzo-sentinel-stdout.log and is governed by the stdout_logfile parameter
• error output by the process is by default written to /var/log/nyzo-sentinel-stderr.log and is governed by the stderr_logfile parameter
• both files have a default cap of 10MB per log file to ensure that the act of writing to said files doesn't become a memory-heavy burden for the sentinel.
  This limit is imposed by the stdout_logfile_maxbytes and stderr_logfile_maxbytes parameters.
• the command necessary for executing the compiled jar file is added to the command parameter

managed_verifiers

As explained in the sentinel installation tutorial, the node operator enters a list of verifiers into the file. These are the verifiers which will be watched over by the sentinel. The verifiers in this file will also act as the primary source for information about the cycle, so make sure that at least some of them have the always_track_blockchain=1 parameter set in the preferences file of the verifier.

Running

After the sudo supervisorctl reload command has been invoked, the sentinel continuously contacts the verifiers listed in the managed_verifiers file, this communication between the listed verifiers and the sentinel happens in parallel.

If one of the verifiers from the list is unresponsive, the sentinel steps in to produce a block for that verifier.

This is important, because, as we know, the verifier drops out of the cycle if it fails to produce a block when it is expected to do so.

Next to protecting the verifiers from dropping out of the cycle when they unexpectedly become unresponsive, it can also aid cycle candidates in joining the cycle.

The propensity for a bad actor to attack a verifier (for example through the use of a DDoS attack) is at its highest when it is expected to produce a block or if it is being voted for to join the cycle.

It is exactly at those moments that having a sentinel is important as it has the power to stealthily produce a block (from a separate, not prematurely announced IPv4 address) - and the right to act as a substitute for the production of a block during the time where the verifier being voted for has the opportunity to produce a block, and thus has the opportunity to claim the rights to join the cycle.

Common to consider

As the power of the sentinel comes from it acting as a shadow node to stealthily produce blocks, it is common to consider running multiple sentinels from different VPS host providers as a matter of redundancy or to switch the IPv4 address from which the sentinel broadcasts its communications regularly, as it exposes itself after every intervention.