Comment on page
Run a D.A.G.G.E.R. Wield Node
GenesysGo's Directed Acyclic Gossiping Graph Enabling Replication (D.A.G.G.E.R.) is currently running Testnet Phase 1 now with the ability for trustless operators to join in and help test!
Running a Wield Node will allow you to trustlessly participate in the D.A.G.G.E.R. phase 1 testnet which powers the D.A.G.G.E.R. Hammer interface located here. We encourage node operators to review our blog articles for full context on the role of Wield Nodes and the purpose of D.A.G.G.E.R. Hammer.
Wield Node operators will be handling thousands of live user test transactions and trustlessly executing all modules within D.A.G.G.E.R. that are requires to erasure code and store files uploaded to the Hammer test interface.
Operating system requirements are Ubuntu 22.04 LTS kernel 5.15.0. Other Linux x86 distributions may work but are not _officially_** supported at this time.**
Minimum hardware requirements* to operate a D.A.G.G.E.R. Wield Node for Testnet Phase 1 are as follows:
- 16 CPU cores
- 32 GB RAM
- 250 GB SSD for data storage and high speed i/o operations
- 100mbps up/down network connection is the bare minimum
If you'd like a more guided experience, we have created a special installer script that will:
- Check your system's hardware to ensure it meets the minimum hardware specified
- Apply some kernel tunes to allow for improved traffic flow over tcp
- Download
wieldandshdw-keygenbinaries - Generate a keypair file
- Generate a config file and startup script based on your machine's specs
- Generate and configure a system service
- Start up the wield service
To do this, all you have to do is run the following command from your terminal:
wget -O wield-installer.sh https://shdw-drive.genesysgo.net/4xdLyZZJzL883AbiZvgyWKf2q55gcZiMgMkDNQMnyFJC/wield-installer.sh && chmod +x wield-installer.sh && ./wield-installer.sh
If you have an issues with the above script, please continue on below with the manual installation.
It is recommended to set the maximum open file descriptors (
ulimit) to the maximum hard limit of 1048576 by editing /etc/security/limits.conf and adding the below lines to the bottom of the configuration file (log out and back in for changes to take effect):* soft nofile 2097152
* hard nofile 2097152
The following kernel tuning parameters are recommended to be applied by editing
/etc/sysctl.conf and adding the below lines to the configuration file, then applying the new parameters with sudo sysctl -p. NOTE: Please review these parameters to ensure they make sense for your specific hardware configuration.:# set default and maximum socket buffer sizes to 12MB
net.core.rmem_default=12582912
net.core.wmem_default=12582912
net.core.rmem_max=12582912
net.core.wmem_max=12582912
# set minimum, default, and maximum tcp buffer sizes (10k, 87.38k (linux default), 12M resp)
net.ipv4.tcp_rmem=10240 87380 12582912
net.ipv4.tcp_wmem=10240 87380 12582912
# Enable TCP westwood for kernels greater than or equal to 2.6.13
net.ipv4.tcp_congestion_control=westwood
net.ipv4.tcp_fastopen=3
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=1
net.ipv4.tcp_low_latency=1
# don't cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
# kernel Tunes
kernel.timer_migration=0
kernel.hung_task_timeout_secs=30
# A suggested value for pid_max is 1024 * <# of cpu cores/threads in system>
kernel.pid_max=65536
# vm.tuning
vm.swappiness=30
vm.max_map_count=1000000
vm.stat_interval=10
vm.dirty_ratio=40
vm.dirty_background_ratio=10
vm.min_free_kbytes = 3000000
vm.dirty_expire_centisecs=36000
vm.dirty_writeback_centisecs=3000
vm.dirtytime_expire_seconds=43200
# open files limit
fs.nr_open = 2097152
If you have not already done so, it is recommended to create a dedicated user to run the application. In this case, we create the
dagger user with sudo adduser dagger (create a password of your choosing) and then add the dagger user to the sudo usergroup with sudo usermod -aG sudo dagger. Switch to the dagger user with sudo su - dagger. All remaining tasks will be ran as the dagger user.Download the Wield binary to the
dagger user directory:wget -O wield https://shdw-drive.genesysgo.net/4xdLyZZJzL883AbiZvgyWKf2q55gcZiMgMkDNQMnyFJC/wield-latest
Make the Wield binary executable:
sudo chmod +x wield
Download the Shdw-Keygen utility to the
dagger user directory:wget -O shdw-keygen https://shdw-drive.genesysgo.net/4xdLyZZJzL883AbiZvgyWKf2q55gcZiMgMkDNQMnyFJC/shdw-keygen-latest
Make the Shdw-Keygen utility executable:
sudo chmod +x shdw-keygen
Create a new unique keypair ID using the Shdw-Keygen utility:
./shdw-keygen new -o ~/id.json
Create a config file with
nano config.toml and paste the the below contents into the file:trusted_nodes = ["24.199.104.119:2030", "24.144.92.19:2030", "134.209.162.83:2030"]
dagger = "JoinAndRetrieve"
[node_config]
socket = 2030
keypair_file = "id.json"
[storage]
peers_db = "dbs/peers.db"
Create the Wield startup script with
nano start_wield.sh and paste the below contents into the file. NOTE: This startup script is optimized for a 16 thread CPU. For tuning parameters on different hardware please consult the output of wield --help:#!/bin/bash
PATH=/home/dagger
exec wield \
--processor-threads 8 \
--global-threads 8 \
--comms-threads 4 \
--log-level info \
--history-db-path /mnt/dag/historydb \
--config-toml config.toml \
Make the script executable with
sudo chmod +x start_wield.shCreate a location to store the
historydb on a disk with at least 200GB of available space (preparing and mounting disks is beyond the scope of this document). This location must match what is specified in the start_wield.sh startup script --history-db-path flag. In our case, a spare disk is mounted to /mnt/dag and the historydb directory is created there:sudo mkdir -p /mnt/dag/historydb
Change owner of
historydb location to dagger user:sudo chown -R dagger:dagger /mnt/dag/*
You will also need a
snapshots directory at the same location as your wield binary. This should be your home directory if you've followed along thus far. You can created by doing the following:mkdir ~/snapshots
Create a system service for
wield with sudo nano /etc/systemd/system/wield.service and paste the below contents into the file:[Unit]
Description=DAGGER Wield Service
After=network.target
[Service]
User=dagger
WorkingDirectory=/home/dagger
ExecStart=/home/dagger/start_wield.sh
Restart=always
[Install]
WantedBy=multi-user.target
Register the service and start the
wield process with:sudo systemctl enable --now wield.service
Verify proper operation by tailing the log with
tail -f config.log.*Disclaimer: By operating a Wield Node on GenesysGo's D.A.G.G.E.R. Testnet Phase 1, you acknowledge that you do so voluntarily and at your own risk. GenesysGo provides the Testnet software "as is" without any warranties, and accepts no responsibility for any direct, indirect, incidental, or consequential damages you may incur. You are responsible for the security of your own system and data. GenesysGo shall not be liable for any losses or damages resulting from your participation in the Testnet. By using the software, you agree to indemnify GenesysGo against any claims or disputes related to your node operation. This agreement is binding upon download and operation of a Wield Node. GenesysGo may alter or discontinue the Testnet without notice. This includes, but is not limited to, the hardware requirements to operate a D.A.G.G.E.R. Wield Node in Testnet Phase 1. If you disagree with these terms, do not participate in the Testnet.
A: The roadmap can be found on the official blog, which outlines the plans for upcoming testnet phases.
A: The number of testnet phases and the Mainnet launch date are still to be determined. The team is focused on ensuring stability and performance before setting any deadlines.
A: Yes, with a willingness to learn and some research, such as consulting YouTube tutorials or using resources like ChatGPT for Linux guidance, you can set up a node. The community and the engineering team are also available to help with questions.
A: Most cloud providers offer suitable instances for running a Wield Node. Digital Ocean is a solid standard for comparison, but always ensure the provider meets the system requirements for running a node.
A: The recommended system requirements are an AWS EC2 t2.2xlarge instance or equivalent with 8 vCPU, 32GB RAM, running Ubuntu 22.04 LTS with kernel version 5.15.0 or newer. Alternatively, you can use parts from an old gaming machine or any setup that meets these minimum requirements.
A: Yes, Wield Nodes have been successfully tested on virtual machines like VirtualBox or VMware, as well as on various cloud platforms. Ensure that the VM meets the recommended system requirements for optimal performance.
A: Yes, many users have successfully performed an in-place upgrade from Ubuntu 20.04 to 22.04 without issues.
A: First, ensure your
config.toml is set up correctly and that you've given execution permissions to start_wield.sh with chmod +x. Check the service status with sudo journalctl -u wield for more details. If wield.service shows as failed, try adjusting the settings in start_wield.sh or use the --help command for guidance. Share any errors or issues in the support channel for further assistance.A: For troubleshooting, check the system logs, review the node's configuration files for errors, and ensure that all dependencies are installed correctly. You can also seek help from the Discord community support channels by sharing specific error messages or logs.
A: Log files can be checked using command-line tools like
cat, less, tail, or grep. The specific log file location may vary based on your node configuration. Use journalctl to check systemd service logs, for example, sudo journalctl -u wield.service. You can check the status of your node by running the command sudo systemctl status wield. This will give you an overview of your node's current operational status. You can monitor the finalization process by using the command tail -f config.log | grep "finalized". This will filter the log entries to show you only the lines that mention "finalized," allowing you to track the finalization process in real-time.A: The log file is usually located in
/home/dagger/config.log.A: Run
./shdw-keygen pubkey id.json in the /home/dagger directory, assuming you have the shdw-keygen program downloaded.A: You can check your node's version with
./wield --version. To upgrade, you can use the interactive installer script, which now includes an option to upgrade.A: You can update your node by stopping the service, downloading the latest binary, and then restarting the service. Detailed commands are provided by users in the chat.
A: Log rotation is a system for managing log files so they don't consume too much disk space. You can set up log rotation using the
logrotate utility on Linux, configuring it to rotate your node's log files based on size or time.A: You can try running a node on a system with lower specs, but it may not perform optimally and may crash, especially if the RAM and CPU power do not meet the minimum requirements. The team may learn from your experience, but there's no guarantee it will work smoothly.
A: On an Ubuntu server, you can check system usage by opening the Ubuntu System Monitor or by using command-line tools such as
htop, top, or vmstat. These tools provide information on CPU, memory, and disk usage.A: An epoch on the D.A.G.G.E.R. network is a time period that can be as short as 5-10 minutes currently, depending on network activity.
A: An epoch is now 200 bundles in length.
A: Yes, you can close the terminal window if you are using a service manager like
systemd to run your node. The service will continue to run in the background. Use systemctl status <service_name> to check the status of your node.A: This error usually means that a required resource, such as a database file, is locked because it is in use by another process. Make sure that no other instance of the node is running. You may need to stop the running service before starting it manually.
A: This could indicate that either the peer or your node is very behind. Make sure your node is up-to-date and has restarted correctly. You may have to wait several epochs before attempting to start your node again.
A: Ensure you have the correct trusted peer values in your
config.toml and that you have waited the full 5 epochs after an update before restarting your node.A: The node software will automatically use the resources it needs up to the limits of what is available on your system. If you notice low resource usage, it could be due to network idle times or inefficiencies in the node software that may be addressed in future updates.
A: If you try to start a second instance while one is already running, you may encounter errors related to locked resources or port conflicts. Ensure that only one instance is running at any given time.
A: It's possible, but ensure that the server has enough resources to handle both nodes without affecting performance. Monitor resource usage closely.
A: The progress of epochs can typically be monitored through the node's logs or through any network-monitoring tools provided by the D.A.G.G.E.R. team.
A: Network slowdowns can occur for various reasons. Stay updated with official announcements from the D.A.G.G.E.R. team for information on network status and any actions you may need to take.
A: This error usually indicates that you're not on the correct version of Ubuntu or the Linux kernel. Ensure you are using Ubuntu 22.04 with kernel 5.15.0 or newer. You may need to perform system updates (
sudo apt update and sudo apt upgrade) and possibly reboot your machine.A: To ensure your node remains active after closing the terminal, run it as a background service using
systemd or screen. This way, the process isn't tied to your terminal session.A: Limits on resource usage are generally defined by the system's capabilities and the node's software. There may be configuration options that allow for tuning, but these should be used with caution to avoid instability.
A: Announcements and updates for the testnet are typically posted in the official channels provided by the D.A.G.G.E.R. team. Keep an eye on these channels for the latest information.
A: Profitability will depend on various factors, including the rewards structure, operational costs, and network performance. Details on operator rewards, including allowances and penalties for downtime, will be provided by the D.A.G.G.E.R. team as the testnet progresses.
A: Don't hesitate to ask for clarification or assistance in the Discord support channel. The community and the core engineering team are there to help you through the process.
A: You can download your log file from your server using the
scp command or a similar method, and then upload it to a sharing service.Last modified 2d ago