# Joining the beta network¶

A few common reasons for joining the beta network include:

• Learning node setup and management
• Testing out integrations for services build on Nano before running on the main network
• Assisting testing new node releases and features
• Contributing to a network testing various behaviors and patterns with the protocol

Running a beta node is a great way to join in and help the network grow stronger.

## Node release testing¶

The beta network is also used to coordinate the testing of Nano node releases. The Nano Foundation maintains a few beta nodes on the network and various community members also setup nodes to help provide an environment more similar to the main network. Ahead of each release builds are published as Release Candidates (RC). Starting with RC1 and incrementing with each published build (RC2, RC3, etc.), these are intended for use on the beta network to help identify issues not discovered earlier in the development process.

We invite anyone interested in contributing to Nano to consider participating on the beta network. Not only is it beneficial to the ecosystem, it is also a great way to learn more about setting up and managing a node.

Warning

• Release candidate builds are only recommended for use on the beta network
• The fastest and most recommended method of installation is through Docker
• Binaries and other details can be found at: https://beta.nano.org/

## Running a beta node¶

Setting up a node on the beta network is similar to the main network. To start you should install docker and be familiar with the general setup and Docker management processes.

### Network ports¶

Beta Network Ports Overview

• 54000 UDP: For live network activity
• 54000 TCP: For bootstrap network activity
• 55000 TCP: For communication with RPC server. Anyone with access to this port can control your node's RPC.

### Folder locations¶

OS Location
Windows C:\Users\<user>\AppData\Local\NanoBeta\
OSX /Users/<user>/Library/NanoBeta/
Linux /home/<user>/NanoBeta/

Info

Directory names for extracting builds downloaded from GitHub or https://beta.nano.org/ will be updated with RC versions for V19 and later.

### Pulling the Docker image¶

Pulls the latest release of the Nano Node:

docker pull nanocurrency/nano-beta


Pulls a specific version of the Nano node:

docker pull nanocurrency/nano-beta:V19.0RC1


Pulls the latest release which includes any release candidate versions:

docker pull nanocurrency/nano-beta:latest-including-rc


A list of beta tags can be found at the official Nano Currency Docker Hub

### Starting the Docker container¶

docker run --restart=unless-stopped -d \
-p 54000:54000/udp \
-p 54000:54000 \
-p [::1]:55000:55000 \
-v ${NANO_HOST_FOLDER_BETA}:/root \ --name${NANO_NAME} \
nanocurrency/nano-beta:latest-including-rc


Tip

Separate host folders

Be sure to use a different host folder for main network and beta network Docker node setups. Attempting to use the same folder will result in issues.

URL Description
https://beta.nano.org/ Official beta site and faucet
https://beta.nanocrawler.cc/ Beta Explorer
https://b.repnode.org/ Beta nodes and Stats

## Current Release Candidate Testing¶

### Release Candidate 4 for V19 (V19 RC4)¶

V19 RC4 is the latest build available for the beta network. In addition to any general or integration specific testing, some of the helpful testing activities during the release candidate period have been included below for reference:

Anyone attempting to upgrade to V19 from versions earlier than V18 will see a long period where the node will not participate on the network and RPC will not be responsive. This is because the sideband upgrade has been changed from a background process to being on the main thread this version. It is recommended that older nodes are upgraded to V18 before attempting the upgrade to V19 to avoid the service interruption.

Confirmation Height

CHT1 Complete Verifying RPC commands responsive during upgrade period (confirmation height setting of initial long chains occurs in background so shouldn't interrupt RPC, will take a while so confirmation height values may not show up for a while) 5/12: Confirmation height updates ongoing and completed for various nodes with no reported cases of impacts to RPC responsiveness
CHT2 Additional tests desired Requests to RPC block_confirm with already confirmed blocks will still include that block in confirmation_history and through the callback 5/12: At least one successful validation of this case has been done, additional tests are welcome
CHT3 Additional tests needed Requests to block_info and blocks_info should return confirmed true for recently confirmed blocks even during confirmation height upgrade process. Blocks underneath these recent ones may show unconfirmed status during upgrade. 5/12: Still pending testing on beta network
CHT4 Additional tests desired Attempt triggering fork resolution on an already confirmed block and monitor elections to ensure they aren't started for that block (ideally an older one that someone without confirmation height enabled wouldn't be trying to trigger an election for) 5/12: At least one successful validation of this case has been done, additional tests are welcome
CHM1 Waiting for reports Start upgrade and note start time, immediately publish a new block on a new account and poll account_info for it repeatedly until you see confirmation_height value appear - this is roughly the confirmation height upgrade time. CLI command nano_node --debug_cemented_block_count can also be used to see how far along the confirmed block count is vs. total block count 5/12: Various upgrades have been done, waiting on reported times for upgrade completion

Dynamic PoW and Prioritization

DPT1 Additional tests desired Spam the network and attempt to saturate it 5/12: Saturation has been achieved with ~50+ TPS multi-account spam, additional tests still desired
DPT2 Needs testing in RC 3 For low-powered nodes, try publishing some blocks and watch for work values increasing during saturation 5/12: Tests have indicated active difficulty does increase, changes to the algorithm controlling this will be included in RC 3 for further testing
DPT3 Additional tests desired in RC 3 Create conditions that would cause blocks to fail confirmation in less than 5 seconds, trigger some sends (noting work values) and then watch for node to do rework and republish the block with new work value after ~ 5s. Conditions to slow confirmations could be created with saturating the network with spam or possibly setting a high online_weight_quorum/online_weight_minimum value in config.json 5/27: Successful tests completed in RC3, additional testing desired
DPM1 Needs testing in RC 3 Capture average work values using the active_difficulty RPC 5/12: Average work values have been captured and monitored, but behavior may be changed with RC 3 and if so, would make more tests desirable

Websocket support

WST1 Complete Configure node to use the websocket callbacks and spam network with a known set of pre-calculated blocks 5/12: Multiple cases of websocket setups completed and functioning
WST2 Tests needed Setup websocket with confirmation of all blocks on a fresh node and allow syncing from scratch. NOTE: This will capture confirmations for all blocks in the ledger which will be a large amount of data. Validate confirmations seen is close to total block count when caught up with the network. Not yet tested
WST3 Tests needed Setup websocket with subscription confirmation including various filters for active, conf height, inactive as use cases need.
WSM1 Additional tests desired Collect all callbacks from websocket to compare against known spam blocks sent out for any potential gaps 5/12: Comparison of websocket to callback for validating full block capture has been attempted but so far is inconclusive, additional testing desired

Nano_ prefix

NPT1 Continued testing Any services integrating should verify they can properly handle nano_ prefix addresses 5/12: All services continue to be encouraged to setup a beta node and test with their systems

New RPC process

RPT1 Complete Verify RPC is responsive and doesn't spawn new process with default configuration - verify RPC is responsive to calls, including heavy usage 5/12: In process RPC observed behaving as expected with RC 2 build
RPT2 Complete Update RPC configuration for child process setups per https://github.com/nanocurrency/nano-node/pull/1874 - verify RPC is responsive to calls, including heavy usage 5/14: Testing looks good
RPT3 Complete Update RPC configuration for out of node process setups per https://github.com/nanocurrency/nano-node/pull/1874 - verify RPC is responsive to calls, including heavy usage 5/14: Testing looks good
RPT4 Additional testing needed Test that --network and data_path command line arguments are transferred correctly to nano_rpc when used as child/out of process RPC.
RPT5 Complete Use an incorrect rpc_path in config.json and confirm that an appropriate error message is displayed.
RPT6 Complete Spam many RPC requests (don't wait to response) with low numbers of io_threads, confirm node is still responsive after.

Confirmation times

RPM1 Additional tests desired Keep tracking confirmation times as the vote_generator delay was removed, likely helping reduce confirmation times during lower TPS situations 5/12: Confirmation times continually tracked on beta network. Under low network volume confirmation times under 0.2s, rising higher under saturation. Continued monitoring is desirable.

Fast bootstrap

FBT1 Additional tests desired Attempt bootstrapping from scratch using --fast_bootstrap option and report times and final ledger file size (NOTE: using this option doesn't clear unchecked) 5/12: Additional data for fast bootstrap times and resulting ledger file sizes is desired

Networking/TCP

NET2 Tests needed Track peering with other nodes via TCP by calling peers RPC command with peer_details = true. Expect to see connections via TCP to other nodes running V19RC3+, via UDP for nodes running versions lower. Disable all UDP ports to force TCP-only peering, although this may not result in enough votes to reach quorum if few nodes on the network have upgraded. 5/28: TCP connection drops were seen with RC 3 and updates to resolve are pending for RC 4
NET3 Tests needed Bandwidth limiting covers outbound vote traffic and defaults the limit to 1.5Mb/s. Configure the node to lower levels of bandwidth limiting (see bandwidth_limit option in config.json), especially during spam events, and report level of bandwidth seen vs. network volume. Using stats RPC with type = counters will show in the response type = drop, detail = message type, and value = number of messages dropped. Values seen here indicate the bandwidth limit is being hit.
NET4 Tests needed Launch node with optional flag --disable_udp to communicate entirely over TCP (ensure enough voting weight on beta is upgraded to RC4 first). Similar tests to NET1 above with different network configurations desired.