Skip to content

3.2 Code Lodestar CLI Validator

From lodestar documentation:

It's codebase start with packages/validator folder.

From CLI:#

https://github.com/ChainSafe/lodestar/blob/v1.5.1/packages/cli/src/cmds/validator/index.ts

export const validator: ICliCommand<IValidatorCliArgs, IGlobalArgs> = {
  command: "validator",
  // ...
  handler: validatorHandler,
};

validatorHandler is the main function. Similar to beacon-node initialization, it also parses configs, prepares databases, and prepares metrics. The core is about initializing Validator class in https://github.com/ChainSafe/lodestar/blob/v1.5.1/packages/validator/src/validator.ts:

const validator = await Validator.initializeFromBeaconNode(
    // ...
  );

Deep Dive into Validator.constructor#

After having the genesis block, static function initializeFromBeaconNode creates Validator instance.

Create IndicesService and ValidatorStore#

const indicesService = new IndicesService(logger, api, metrics);

Every validator has a unique index: https://beaconscan.com/validators. (First column 'INDEX'). IndicesService and ValidatorStore together make sure it keeps a local storage of known validators by their public key and validator index.

ValidatorStore can store multiple signers, i.e. one node can have multiple validators. It also implements functions like signAttestation and signBlock. Later we will dive into the steps in 3.4 Code - Lodestar - Attestation

BlockProposingService, AttestationService and SyncCommitteeService#

this.blockProposingService = new BlockProposingService(
  // ...
);
this.attestationService = new AttestationService(
  // ...
);
this.syncCommitteeService = new SyncCommitteeService(
  // ...
);

All these services implement periodic tasks that runs every slot for jobs of block proposing, attestations, or sync committee. Sync committee, specifically, is introduced in 'altair' upgrade to help light client: https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md. Attestation and block proposing also have implemented 'xxxDutiesService' that runs every epoch to check for their duties.

Duties at start of every epoch

https://github.com/ethereum/beacon-APIs/blob/master/validator-flow.md
"On start of every epoch, validator should fetch proposer duties. Result is array of objects, each containing proposer pubkey and slot at which he is suppose to propose."
"On start of every epoch, validator should ask for attester duties for epoch + 1. Result are array of objects with validator, his committee and attestation slot."

Refer also to here:
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/attestations/#attestation-inclusion-lifecycle