LogoLogo
HomeCommmunityLegal
  • Getting started
    • Welcome
    • Useful links
    • Framing the problem
    • Design goals
  • Methodologies
    • Ethereum Beacon Chain
      • Resources
      • Network explorer definitions
        • Landing page
        • Entity views
          • Top screener
          • Entity overview
          • Consensus layer statistics
          • Execution layer statistics
          • Aggregate rewards statistics
        • Aggregate views
          • Trending
          • Network overview
            • Gini coefficient measurement
          • Relayer landscape
          • Builder landscape
        • Misc
          • Index Coop dsETH
      • RAVER methodology
        • Proposer effectiveness
        • Attester effectiveness
        • Effectiveness rating
        • Slashing moderator
        • Sync committees
        • Post-hoc analysis of the Rated v0 effectiveness rating
      • Penalties and Missed Rewards methodologies
        • Penalties computation
          • Pre-Altair penalties computation
        • Validator missed rewards computation
          • Consensus missed rewards computation
          • Execution missed rewards computation
      • Baseline MEV computation
      • Aggregating validator indices
        • Classes of aggregation
    • Miscellaneous
      • Value enabled by Rated
  • API documentation
    • Introduction
    • Getting past authentication
    • API guide
    • Swagger schema
  • Legal
    • ToU & Privacy Notice
      • Website Terms of Use
      • API Terms of Use
      • Privacy Notice
  • Community
    • 🍬Let's Rate!
Powered by GitBook
On this page
  • Estimating rewards
  • Deriving penalties

Was this helpful?

  1. Methodologies
  2. Ethereum Beacon Chain
  3. Penalties and Missed Rewards methodologies
  4. Penalties computation

Pre-Altair penalties computation

Estimating rewards

Validator rewards pre- and post-Altair are some function of base_reward. Our calculation follows the spec along each of the two periods. To estimate the actual reward amounts in Gwei, we sum the number of units validators should receive per activity, and then we multiply them by the estimated base_reward for that day. Base_reward is a function of active validators and uptime, and is computed per epoch, but the variability between a day is small enough to approximate it with daily averages; which is the approach we are taking.

CASE WHEN vd.day > 329
THEN (
rewardsu.uptimebr.base_reward +
proposed_countbr.base_rewardbr.active_validators8.0/(32.064.0) +
sync_signature_count*(((br.total_active_balance64)/FLOOR(SQRT(br.total_active_balance))) / (32512*32))
)
ELSE (
rewardsu.uptimebr.pre_alt_base_reward +
proposed_count*(br.pre_alt_base_reward/8.0)*(br.active_validators/32.0)
)
END as estimated_rewards

Deriving penalties

Now from Lighthouse we fetch a validator_index's daily earnings and we can compare the theoretical maximum rewards for the given activities they performed with the actual outcome. We compute estimated penalties as:

estimated_penalties == estimated_rewards - realised_rewards

Example under Altair: A validator attested perfectly 90 times but missed 10 attestations. Say the base_reward is 20K GWei For the 90 perfect attestations, the validator should get:

90 * (0.218752 + 0.40625) = 75.9375 * base_reward =
75.9375 * 20K = 1,518.75K = 1.5M GWei

If a validator received 1.2M Gwei, we have a difference of 300K Gwei that we need to attribute somewhere! It is not opportunity cost, as the theoretical maximum is not factored in at all in the model.

Thus it has to be the penalties!

PreviousPenalties computationNextValidator missed rewards computation

Last updated 2 years ago

Was this helpful?