In the most simple setup, a single beacon node paired with an execution client is all that is needed to run a successful validator setup.
Nimbus however also provides options for running advanded setups that provide additional security and redundancy.
See the validator client page to get started!
Multiple beacon nodes
By default, the validator client will connect to a beacon node running on the same machine using the default port (
You can select one or more beacon nodes to connect to using the
build/nimbus_validator_client \ --beacon-node=http://127.0.0.1:5052 \ --beacon-node=http://127.0.0.1:5053
Beacon node roles
When configuring multiple beacon nodes, each beacon node can be assigned to perform specific tasks on behalf of the validator client.
|Role name||Role calls|
Also there could be combinations
|publish||attestation-publish, aggregated-publish, block-publish, sync-publish|
|data||attestation-data, aggregated-data, block-data, sync-data|
|all||attestation, aggregated, block, sync, duty|
Roles are configured using the
#roles= URL anchor - the default is
http://127.0.0.1:5055/ also means
Before usage all the roles are got stripped from BN URLs.
Fully redundant nodes
Using multiple beacon nodes with the same role allows fully redundant setups.
These setups are resilient against any single beacon node getting disconnected and provide additional "entry points" for the data that the validator client produces should any node experience poor connectivity.
Sentry node setup
In the Ethereum network, the block proposer is known up to 12 minutes before they propose the block. Because each validator sends attestations every 6 minutes, it is also possible to map the validator key to the beacon node IP address that serves it.
Sentry nodes setups allow separating block production traffic from attestations and sync committee messages, making sure that a separate public IP address is used when proposing blocks. In this setup, there are two beacon nodes:
- One beacon node has all roles except
- The other beacon node has the
Separating block production makes it harder for an attacker to target the specific IP address that the validator would otherwise use for block production.