14 KiB

Raw Blame History

Validator client

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 (5052).

You can select one or more beacon nodes to connect to using the --beacon-node option:

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
attestation-data	produceAttestationData()
attestation-publish	submitPoolAttestations()
aggregated-data	getAggregatedAttestation()
aggregated-publish	publishAggregateAndProofs()
block-data	produceBlockV2()
block-publish	publishBlock()
sync-data	getBlockRoot() produceSyncCommitteeContribution()
sync-publish	publishContributionAndProofs() submitPoolSyncCommitteeSignatures()
duties	getGenesis() getSpec() getSyncingStatus() getValidatorsActivity() getForkSchedule() getAttesterDuties() getProposerDuties() getSyncCommitteeDuties() getStateValidators() prepareSyncCommitteeSubnets() prepareBeaconCommitteeSubnet()

Also there could be combinations

Name	Roles
attestation	attestation-data, attestation-publish
aggregated	aggregated-data, aggregated-publish
block	block-data, block-publish
sync	sync-data, sync-publish
publish	attestation-publish, aggregated-publish, block-publish, sync-publish
data	attestation-data, aggregated-data, block-data, sync-data
all	attestation, aggregated, block, sync, duty

Configuration

Roles are configured using the #roles= URL anchor - the default is all:

Examples: http://127.0.0.1:5052/#roles=attestation-data,attestation-publish http://127.0.0.1:5053/#roles=block-proposal-data,block-proposal-publish http://127.0.0.1:5054/#roles=all http://127.0.0.1:5055/ also means all roles.

Before usage all the roles are got stripped from BN URLs.

Advanced topologies

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 block
The other beacon node has the block role

Separating block production makes it harder for an attacker to target the specific IP address that the validator would otherwise use for block production.

14 KiB Raw Blame History