Skip to main content
Before reaching out for support, here are some steps to check your installation.

​
Quick diagnosis script

Berachain distributes a stand-alone diagnosis script. Drop this into your Unix-based system and run: 
/path/to/node-diagnostic.sh -d /var/beacond/ -p /opt/bin/beacond
Substitute the path to your Beacon Kit data directory (containing config and data directories), and the path to the beacond binary (if not in your $PATH). This script produces clearly marked recommendations. Provide the output of this script when communicating with the team for support.

​
Beacon Kit version check

Ensure you are running the latest version of Beacon Kit.

​
Execution client version check

Check that you are running a supported version of your execution client. Note that Berachain doesn’t always support the latest version of a given client.

​
Peering

There are several ingredients to successful peering. If you are running in a containerized environment, ensure your services are properly advertising their real network address, and that traffic is being directed into the container, both for Beacon Kit and your execution client.
  1. Check bootnodes for initial chain sync: Check that you have a current list of bootnodes. Both geth and reth accept the --bootnodes option. beacond has the boot node list baked into the distributed config.
  2. Check Execution Layer peering: The execution layer needs excellent peering to ensure that transactions flow to your validator for sealing in blocks. Ensure port 30303 TCP (for transactions) and UDP (for peer exchange) is open. Check that you have a current list of bootnodes.
  3. Indicate your Execution Layer’s external IP address: Execution clients need to know the publicly routable IP address they can be reached at. Most execution clients try to determine your public IP with UPnP, which is not available in cloud computing environments. Therefore, you must tell your execution client what your external IP address is. For reth and geth, this is done with the --nat extip:<IP> option.
  4. Check beacond peering: beacond needs good peering to organize and perform consensus actions. This is carried out over TCP port 26656. Also, correctly advertise your node’s external IP with p2p.external_address in config.toml. To limit beacond’s memory consumption, 40 inbound + 10 outbound peers is recommended:
max_num_inbound_peers = 40
max_num_outbound_peers = 10
  1. No static or persistent peers: Both the CL and EL should have no static or persistent peers set up, unless they are for your internal network or business partners you want permanent connections to.
For Reth, the following options are recommended in the Reth launch: 
--engine.persistence-threshold 0
--engine.memory-block-buffer-target 0
For Geth, override the gas price lower limit to agree with Reth: 
--miner.gasprice 1
For both clients, ensure the debug API is not enabled in the --http.api option. It is better to remove the --http.api option entirely and allow the secure default to apply, unless you have specific reasons to enable additional modules. For Geth, exposing the debug API module enables highly destructive commands.

​
Register with the team

If you have launched a validator on the chain, it’s in your interest to let the team know who you are, so they know who to contact in case there’s trouble with on-chain performance. Steps to do that:
  1. (Optional) Formulate a pull request to the Validator Metadata repository with a public handle for your validator. You can use an anon if you want. Provide a logo attached to the pull request if you would like it posted on your validator profile.
  2. Reach out on the #node-support channel on Discord. The team will set you up with dedicated support, chat, and announcement channels for validators.

​
Operational hygiene

Make sure Beacon Kit and your execution client are configured to start when your operating system starts. Cause your operating system to rotate logs, and slim the log output.
  • Read the beacond config files to find log verbosity settings.
  • Consult the instructions for your chosen chain node to adjust logging settings.
  • Set up the logrotate service to rotate logs.
Monitor your node’s disk space, memory consumption, and service availability. You can add --metrics=<ip>:6060 to the reth invocation to enable Prometheus metrics collection. Specify an internal IP address accessible only to your Prometheus server, or ensure this port is firewalled off from the internet. Particularly if you are a validator, consult the guide to Becoming an Awesome Validator for references to other monitoring tools.