📡
beaconcha.in Knowledge Base
  • 👋Welcome
  • 🖥️v2 beaconcha.in explorer [BETA]
    • 🎉Introducing v2-beta
    • 🦸Summary view
    • 🟩Slot visualization
    • 🫂Validator groups
    • ⚒️Manage Validators
    • ⚒️Manage Validators [API]
    • 🤝Share your custom dashboard
    • 📈Metric: Validator Efficiency
    • ⏰Notifications v2
  • v1 beaconcha.in Explorer
    • Notifications
      • Understanding notifications
      • Notification configuration
    • Mobile App <> Node Monitoring
    • Optimal Inclusion Distance
  • Ethereum Staking
    • Glossary
    • The Genesis Event
    • Ethereum Validator Keys
    • Deposit Process
    • Rewards and Penalties
    • Attestation
Powered by GitBook
On this page
  • Attestation
  • Aggregated Attestation
  • Attestation Inclusion Lifecycle
  • Rewards
  • Attestation scenarios

Was this helpful?

Edit on GitHub
  1. Ethereum Staking

Attestation

An overview of attestations

Last updated 11 months ago

Was this helpful?

Attestation

Every (~6.4 minutes) a validator proposes an attestation (vote) to the network. This vote consists of the following segments:

  • Finality vote

  • Signature

  • Chain head vote (vote on what the validator believes is the head of the chain) If we multiply that with the information included in each Attestation per Epoch, it adds up quickly. Therefore, the consensus layer aggregates all of that information and minimises the data growth.

Aggregated Attestation

Each block one or more committees are chosen to attest. A committee has a minimum of 128 validators, of which 16 are randomly selected to become an aggregator. As shown below, the validators broadcast their unaggregated attestation to the aggregators (red arrow). The aggregators then merge the attestations and forward a single aggregated attestation to the .

Attestation Inclusion Lifecycle

  1. Generation

  2. Propagation

  3. Aggregation

  4. Propagation

  5. Inclusion

Rewards

Base reward

(Validator effective balance * 2**6) / SQRT(Effective balance of all active validators)

Inclusion delay

At the time when the validators voted on the head of the chain (Block 0), Block 1 was not proposed yet. Therefore attestations naturally get included one block later; so all attestations who voted on Block 0 being the chain head got included in Block 1 and, the inclusion delay is 1.

The effects of the inclusion delay on the attestation reward

As shown below, an Inclusion delay of 2 causes the the reward to drop by 50%.

Attestation scenarios

Missing Voting Validator

These validators have a maximum of 1 epoch to submit their attestation. If the attestation was missed in epoch 0, they can submit it with an inclusion delay in epoch 1.

Missing Aggregator

There are 16 Aggregators per epoch in total, additionally, random validators from the beacon-chain subscribe to two subnets for 256 Epochs and serve as a backup in case aggregators are missing.

Missing block proposer

Note that in some cases a lucky aggregator may also become the block proposer. If the attestation was not included because the block proposer has gone missing, the next block proposer would pick the aggregated attestation up and include it into the next block. However, the inclusion delay will increase by one.

The attestation reward is dependent on two variables, the and the inclusion delay. The best case for the inclusion delay is to be 1.

Credits - - (Consensys)

Epoch
Committee
Validator Index
block proposer
base reward
Attestation effectiveness
AttestantIO
Attestation Inclusion
Adrian Sutton
Source: ConsenSys Codefi Analysis
Source: Consensys