Test a Cluster

Charon test commands are designed to help you evaluate the performance and readiness of your candidate cluster. It allows you to test your connection to other Charon peers, the performance of your beacon node(s), the readiness of your validator client, the performance of the MEV relays you will be using and the infrastructure on which you will run the cluster. It prints a performance report to the standard output (which can be omitted with the --quiet flag) and a machine-readable JSON format of the report if the --output-json flag is set.

Adding the --publish flag to the below commands, and running the command from the directory containing your .charon folder, will submit the test results to the Obol API. Publishing your performance reports grows the staking node dataset, and allows Obol and Ethereum development teams to make data-driven choices regarding the required specs for validating Ethereum. We hope you will consider opting in.

Executable

Test all

Intended for running tests across all categories. Each flag should have a prefix for its category (i.e.: the flag --endpoints from the beacon tests becomes --beacon-endpoints). For details about each category refer to their respective sections.

Regular Test

Regular tests intended for relatively fast run, without putting any major load on any tested system. Based on which stage you are with your cluster creation, some steps are eased.

Just starting

Pre-requisites

• ENR private key.

• Peers' ENRs, supplied to the --peers-enrs flag.

• Running beacon node(s) towards which tests will be executed, supplied to --beacon-endpoints flag.

• Running validator client towards which tests will be executed.

• Running MEV relay(s) towards which tests will be executed, supplied to --mev-endpoints flag.

Example run

charon alpha test all \
  --peers-enrs="enr:-HW4QMno_MB_ID6GFVxoIQAHHVHZZZjzFctxtX2tm9D95tvaPbHathi8YUP8jh8v2YUAVu2fYWEOB_BT14pt8QgiGg2AgmlkgnY0iXNlY3AyNTZrMaECdpnK83s0dbBwCaEfDIkQ-3nJkkC93STvv6Vmi0bYlzg,enr:-HW4QO2vefLueTBEUGly5hkcpL7NWdMKWx7Nuy9f7z6XZInCbFAc0IZj6bsnmj-Wi4ElS6jNa0Mge5Rkc2WGTVemas2AgmlkgnY0iXNlY3AyNTZrMaECR9SmYQ_1HRgJmNxvh_ER2Sxx78HgKKgKaOkCROYwaDY" \
  --beacon-endpoints="https://ethereum-holesky-beacon-api.publicnode.com,https://ethereum-sepolia-beacon-api.publicnode.com" \
  --mev-endpoints="https://0xa15b52576bcbf1072f4a011c0f99f9fb[e-mail],https://0xa7ab7a996c8584251c8f925da3170bdf[e-mail],https://0x8b5d2e73e2a3a55c6c87b8b6eb92e014[e-mail],https://0xac6e77dfe25ecd6110b8e780608cce0d[e-mail],https://0xa1559ace749633b997cb3fdacffb890a[e-mail],https://0x8c4ed5e24fe5c6ae21018437bde14769[e-mail],https://0x8c4ed5e24fe5c6ae21018437bde14769[e-mail]"

Completed cluster creation

Completed DKG

Load Test

Docker

Test connection to peers

Run tests towards other Charon peers to evaluate the effectiveness of a potential cluster setup. The command sets up a libp2p node, similarly to what Charon normally does. This test command has to be run simultaneously with the other peers. After the node is up it waits for other peers to get their nodes up and running, retrying the connection every 3 seconds. The libp2p node connects to relays (configurable with p2p-relays flag) and to other libp2p nodes via TCP. Other peer nodes are discoverable by using their ENRs. Note that for a peer to be successfully discovered, it needs to be connected to the same relay. After completion of the test suite the libp2p node stays alive (duration configurable with keep-alive flag) for other peers to continue testing against it. The node can be forcefully stopped as well.

To be able to establish direct connection, you have to ensure:

• Your machine is publicly accessible on the internet or at least a specific port is.

• You add flag p2p-tcp-address (i.e.: 127.0.0.1:9001) flag and the port specified in it is free and publicly accessible.

• You add the flag p2p-external-ip (i.e.: 8.8.8.8) and specify your public IP.

If all points are satisfied by you and the other peers, you should be able to establish a direct TCP connection between each other. Note that a relay is still required, as it is used for peer discovery.

Based on which stage you are with your cluster creation, some steps are eased.

Just starting

Pre-requisites

• ENR private key.

• Peers' ENRs, supplied to the --enrs flag.

Example run

charon alpha test peers \
  --enrs="enr:-HW4QMno_MB_ID6GFVxoIQAHHVHZZZjzFctxtX2tm9D95tvaPbHathi8YUP8jh8v2YUAVu2fYWEOB_BT14pt8QgiGg2AgmlkgnY0iXNlY3AyNTZrMaECdpnK83s0dbBwCaEfDIkQ-3nJkkC93STvv6Vmi0bYlzg,enr:-HW4QO2vefLueTBEUGly5hkcpL7NWdMKWx7Nuy9f7z6XZInCbFAc0IZj6bsnmj-Wi4ElS6jNa0Mge5Rkc2WGTVemas2AgmlkgnY0iXNlY3AyNTZrMaECR9SmYQ_1HRgJmNxvh_ER2Sxx78HgKKgKaOkCROYwaDY"

Completed cluster creation

Completed DKG

Test beacon node

Run tests on beacon node(s), to evaluate their effectiveness for a Distributed Validator cluster. The beacon node is usually the client doing the most work in a validating stack, especially with a high number of validators being serviced by the validator client(s) and Charon(s) that depend on it.

Regular test

Regular tests intended for relatively fast run, without putting any major load on any tested system.

Pre-requisites

• Running beacon node(s) towards which tests will be executed, supplied to --endpoints flag.

Example run

charon alpha test beacon \
  --endpoints="https://ethereum-holesky-beacon-api.publicnode.com,https://ethereum-sepolia-beacon-api.publicnode.com"

Load test

Test validator client

Run tests towards your validator client, to evaluate its effectiveness for a Distributed Validator cluster.

Default endpoint for validator and port is used at 127.0.0.1:3600. This can be changed by supplying different endpoint to the --validator-api-address flag.

Pre-requisites

• Running validator client towards which tests will be executed.

Example run

charon alpha test validator

Test MEV relay

Run tests towards MEV relays, to evaluate their effectiveness for a Distributed Validator cluster. If MEV-Boost clients are configured for the distributed validator nodes, it is of utmost importance that the relays they connect to are fast and reliable. If not, the chance of missing a block proposal increases significantly. Supplying --beacon-node-endpoint and --load-test flags allows the test to ask relays for real MEV headers, increasing the accuracy (and duration) of this test.

At least 1 endpoint is required to be supplied to the --endpoints flag.

Executable

Regular Test

Pre-requisites

• Running MEV relay(s) towards which tests will be executed.

Example run

charon alpha test mev \
  --endpoints="https://0xa15b52576bcbf1072f4a011c0f99f9fb[e-mail],https://0xa7ab7a996c8584251c8f925da3170bdf[e-mail],https://0x8b5d2e73e2a3a55c6c87b8b6eb92e014[e-mail],https://0xac6e77dfe25ecd6110b8e780608cce0d[e-mail],https://0xa1559ace749633b997cb3fdacffb890a[e-mail],https://0x8c4ed5e24fe5c6ae21018437bde14769[e-mail],https://0x8c4ed5e24fe5c6ae21018437bde14769[e-mail]"

Load Test

Docker

Test machine and network performance

Run tests of your machine and network, to evaluate their effectiveness for a Distributed Validator cluster. Distributed Validators need stable, low-latency, internet, a reasonable amount of RAM, and a highly performant disk drive for storage. This test aims to analyse these requirements to give an overview of the systems suitability.

Executable

Pre-requisites

The executable storage tests require fio to be installed on your host machine. Read more about fio here.

Example run

charon alpha test infra

Docker