Skip to content

Latest commit

 

History

History
44 lines (34 loc) · 2.44 KB

validator-flow.md

File metadata and controls

44 lines (34 loc) · 2.44 KB

Validator Flow

Detail explanation how validator should utilize this API to perform his regular BeaconChain duties.

Block Proposing

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.

If proposing block, then at immediate start of slot:

  1. Ask Beacon Node for BeaconBlock object
  2. Sign block
  3. Submit SignedBeaconBlock (BeaconBlock + signature)

Monitor chain block reorganization events (TBD) as they could change block proposers. If reorg is detected, ask for new proposer duties and proceed from 1.

Attestation

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.

Attesting:

  1. Upon receiving duty, have beacon node prepare committee subnet
  2. Wait for new BeaconBlock for the assigned slot (either stream updates or poll)
    • Max wait: SECONDS_PER_SLOT / 3 seconds into the assigned slot
  3. Fetch AttestationData
  4. Submit Attestation (AttestationData + aggregation bits)
    • Aggregation bits are Bitlist with length of committee (received in AttesterDuty) with bit on position validator_committee_index (see AttesterDuty) set to true
  5. If aggregator:

Monitor chain block reorganization events (TBD) as they could change attesters and aggregators. If reorg is detected, ask for new attester duties and proceed from 1..