Prerequisites and snapshots

Node system requirements

Please note that all system requirements listed below are presented in a Minimum/Recommended format.

Specs

Node type	RAM	CPU	Storage	Network bandwidth
Full Node/Sentry Node	8 GB/16 GB	8 core/16 core	1 TB/2 TB	1 Gbit/s
Validator Node	8 GB/16 GB	8 core/16 core	1 TB/2 TB	1 Gbit/s
Archive Node	16 GB	16 core	1 TB/2 TB (io1 or above with at least 20k+ iops and RAID-0 based disk structure)	1 Gbit/s

Downloading the snapshot

It is recommended that you keep your snapshots handy before setting up the node. Link to the snapshot documentation here.

Open necessary ports

Sentry/full nodes

Port	Description
26656	Heimdall service connects your node to another node’s Heimdall service using this port.
30303	Bor service connects your node to another node’s Bor service using this port.
22	For the validator to be able to SSH from wherever they are.
26660	Prometheus port for Tendermint/Heimdall. Not required to be opened to the public. Only allow for the monitoring systems (Prometheus/Datadog).
7071	Metric port for Bor. Only needs to be opened for the Monitoring system.
8545, 8546,  1317	Can be opened for Bor HTTP RPC, Bor WS RPC, and Heimdall API respectively; but only if really necessary.

Validator nodes

Port	Description
22	Opening this to the public is not a good idea as the default SSH port 22 is prone to attacks. It is better to secure it by allowing it only in a closed network (VPN).
30303	To be opened to only Sentry to which the validator is connected for Bor P2P discovery.
26656	To be opened to only Sentry to which the validator is connected for Heimdall/Tendermint P2P discovery.
26660	Prometheus port for Tendermint/Heimdall. Not required to be opened to the public. Only allow for the monitoring systems (Prometheus/Datadog).
7071	Metric port for Bor. Only needs to be opened for the monitoring system.

Install RabbitMQ

"Only for validator nodes"

This step is only relevant for validator nodes.

Before setting up your validator node, it’s advisable to install the RabbitMQ service. You can use the following commands to set up RabbitMQ (if it’s not already installed):

sudo apt-get update
sudo apt install build-essential
sudo apt install erlang
wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.10.8/rabbitmq-server_3.10.8-1_all.deb
sudo dpkg -i rabbitmq-server_3.10.8-1_all.deb

Connect to Ethereum RPC endpoint

"Only for validator nodes"

This step is only relevant for validator nodes.

Validator nodes need to connect to an Ethereum RPC endpoint. You may use your own Ethereum node, or utilize external infrastructure providers.

Mandatory checklist for validators

Please follow the below checklist in order to set up your validator node using binaries, Ansible, or packages.

Checklist	Binaries	Ansible	Packages
Machines required	2 Machines - sentry & validator	3 Machines - local machine, sentry and validator	2 Machines - sentry & validator
Install Go packages	Yes	No	No
Install Python	No	Yes (only on the local machine where the Ansible Playbook runs)	No
Install Ansible	No	Yes (only on one machine)	No
Install Bash	No	No	Yes
Run Build Essential	Yes	No	No

When setting up a new sentry, validator, or full node server, it is recommended that you use snapshots for faster syncing without having to sync over the network. Using snapshots will save you several days for both Heimdall and Bor.

Snapshots

• https://shibarium.shib.io/snapshots

Downloading and using client snapshots

To begin, ensure that your node environment meets the prerequisites outlined.

• You can use the wget command to download and extract the .tar snapshot files. For example:

wget -O - snapshot_url_here | tar -xvf -C /target/directory

• Configure your client's datadir setting to match the directory where you downloaded and extracted the snapshot data. This ensures the systemd services can correctly register the snapshot data when the client is spun up.

• To maintain your client's default configuration settings, consider using symbolic links (symlinks).

Example

Let's say you have mounted your block device at ~/snapshots and have downloaded and extracted the chain data into the heimdall_extract directory for Heimdall, and into the bor_extract directory for Bor. Use the following commands to register the extracted data for Heimdall and Bor systemd services:

# remove any existing datadirs for Heimdall and Bor
rm -rf /var/lib/heimdall/data
rm -rf /var/lib/bor/chaindata

# rename and setup symlinks to match default client datadir configs
mv ~/snapshots/heimdall_extract ~/snapshots/data
mv ~/snapshots/bor_extract ~/snapshots/chaindata
sudo ln -s ~/snapshots/data /var/lib/heimdall
sudo ln -s ~/snapshots/chaindata /var/lib/bor

# bring up clients with all snapshot data properly registered
sudo service heimdalld start
# wait for Heimdall to fully sync then start Bor
sudo service bor start

"Appropriate user permissions"

Ensure that the Bor and Heimdall user files have appropriate permissions to access the datadir. To set correct permissions for Bor, execute sudo chown -R bor:nogroup /var/lib/heimdall/data. Similarly, for Heimdall, run sudo chown -R heimdall:nogroup /var/lib/bor/data/bor

Recommended disk type and IOPS guidance

• Disk IOPS will affect the speed of downloading/extracting snapshots, getting in sync, and performing LevelDB compaction.
• To minimize disk latency, direct-attached storage is ideal.
• In AWS, when using gp3 disk types, we recommend provisioning IOPS of 16,000 and throughput of 1,000. This minimizes costs while providing significant performance benefits. io2 EBS volumes with matching IOPS and throughput values offer similar performance.
• For GCP, we recommend using performance (SSD) persistent disks (pd-ssd) or extreme persistent disks (pd-extreme) with similar IOPS and throughput values as mentioned above.