From dc4863cac8ce40cbed38a9a194519cb8b99525ca Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 23 Aug 2022 14:05:15 +0100 Subject: [PATCH 1/8] add page on pos rewards and penalties --- .../pos/rewards-and-penalties/index.md | 95 +++++++++++++++++++ src/data/developer-docs-links.yaml | 2 + src/intl/en/page-developers-docs.json | 1 + 3 files changed, 98 insertions(+) create mode 100644 src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..db77d5b7e96 --- /dev/null +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,95 @@ +--- +title: Proof-of-stake rewards and penalties +description: Learn about the in-protocol incentives in proof-of-stake Ethereum. +lang: en +sidebar: true +--- + +Ethereum is secured using its native cryptocurrency, ether (ETH). Node operators that wish to participate in validating blocks and identifying the head of the chain deposit ether into a smart contract on Ethereum. They are then paid in ether to run validator software that checks the validity of new blocks received over the peer-to-peer network and apply the fork-choice algorithm to identify the head of the chain. + +There are two primary roles for a validator: 1) checking new blocks and “attesting” to them if they are valid, 2) proposing new blocks when selected at random from the total validator pool. If the validator fails to do either of these tasks when asked they miss out on an ether payout. + +There are also some actions that are very difficult to do accidentally and signify some malicious intent, such as proposing multiple blocks for the same slot or attesting to multiple blocks for the same slot. These are “slashable” behaviors that result in the validator having some amount of ether (up to 0.5 ETH) burned before the validator is removed from the network, which takes 36 days. The slashed validator’s ether slowly drains away across the exit period, but on Day 18 they receive a “correlation penalty” which is larger when more validators are slashed around the same time. The Beacon Chain’s incentive structure therefore pays for honesty and punishes bad actors. + +All rewards and penalties are applied once per epoch. + +Read on for more details... + +## Rewards and penalties{#rewards} + +### Attestation rewards {#attestation-rewards} + +Validators receive attestation rewards when they make votes that are consistent with the majority of other validators. The value of the attestation rewards in each epoch are calculated from a `base_reward`. This is the base unit that other rewards are calculated from. The `base_reward` represents the average reward received by a validator under optimal conditions per epoch. This is calculated from the validator's effective balance and the total number of active validators as follows: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +where `base_reward_factor` = 64, `base_rewards_per_epoch` = 4 and the `active balance` is the total staked ether across all active validators. + +This means the base reward is proportional to the validator's effective balance and inversely proportional to the number of validators on the network. The more validators, the greater the overall issuance (as `sqrt(N)` but the smaller the `base_reward` per validator (as `1/sqrt(N)`). These factors influence the APR for a staking node. Read the rationale for this in [Vitalik's notes](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). + +For each attesting validator in each epoch, 1/8 of the `base_reward` then goes to the block producer, leaving up to 7/8 available for the attestor. + +The `base_reward` for each validator is then also multiplied by the `participation_rate` which is the fraction of all active validators that participate consistently with each other. So, if all validators attest identically, `base_reward`==`base_reward`, if 10% of validators fail to participate or do so differently to the majority `base_reward` == `base_reward * 0.9`. This ensures there is no benefit to attacking other validators. + +The `base_reward` is also modified by the `inclusion_delay` which rewards prompt attestations. If the delay between block proposal and attestation is >= 1 slot, the attestor receives the full 7/8 _ `base_reward`. For each additional missed slot, the denominator is increased by 8, meaning that the reward for a delay of two slots is scaled by 7/16, for three slots it is 7/24, for four slots it is 7/32 (or, put another way, `7/8 _ base_reward \* 1/k`where`k` = number of slots separating block and attestation). 32 is the maximum inclusion delay denominator that can be applied. This means the slower the attestation, the smaller the reward. + +There are also three additional rewards: `source` (reward for voting for the correct source checkpoint), `target` (reward for voting for the correct target checkpoint), `head` (reward for voting for the correct head block). The value of each of these is equal to `base_reward * inclusion_delay * participation_rate`. The same value can be removed from the validator's balance as a penalty for an incorrect or missing `source`, `target` or `head` vote. + +When validators are assigned to sync committees they receive rewards for each slot they sign off. When validators in a sync committee fail to sign blocks they are penalized exactly the value of ether they would have received for signing successfully. + +### Attestation scenarios + +Assuming attestations are timely (same slot as proposed block) the following table describes the attestation rewards for four scenarios: + +| `source` | `target` | `head` | `base_reward` | penalty | `inclusion_delay` | Result | +| ----------------- | ----------------- | ----------------- | ---------------------------------------- | ------------------ | -------------------- | ----------------------------------------------------------------- | +| incorrect/missing | incorrect/missing | incorrect/missing | 0 | 3 \* `base_reward` | 0 | -3 \* `base_reward` | +| correct | incorrect/missing | incorrect/missing | `base_reward` \* `participation_rate` | 2 \* `base_reward` | `base_reward` \* 7/8 | `base_reward` _ `participation_rate` - 9/8 _ `base_reward` | +| correct | correct | incorrect/missing | 2 _ `base_reward` _ `participation_rate` | `base_reward` | `base_reward` \* 7/8 | (2 _ `base_reward` _ `participation_rate`) - 1/8 \* `base_reward` | +| correct | correct | correct | 3 _ `base_reward` _ `participation_rate` | 0 | `base_reward` \* 7/8 | (3 _ `base_reward` _ `participation_rate`) + `base_reward` \* 7/8 | + +Assuming a 100% `participation_rate`: + +- You vote correctly and gets included in the next slot: you get 31/8 \* `base_reward` +- You miss head because you got a late block and it gets included in the next slot: you get 15/8 \* `base_reward` +- You miss head and target cause you got late a block, you get -1/8 \* `base_reward` +- You attest and vote correctly, but the next block is missed, you get 55/16 \* `base_reward` + +Overall these penalties are fairly mild and amount to a very slow bleed of staked ether for continued inactivity. + +### Block reward {#block-reward} + +When validators are selected to be block proposers they get rewarded if their proposed block gets finalized. Block proposers can also increase their reward by including evidence of misbehavior by other validators in their proposed block. These rewards are the "carrots" that encourage validator honesty. + +Only **valid** attestations (correct source checkpoint) can be included in a block and the rewards for a block proposal scale with the amount of included attestations because they receive 1/8 of the `base_reward` for every attestation in the block. There is no penalty for failing to propose a block. + +A block proposer which includes slashing will be rewarded with the `slashed_validators_effective_balance / 512` where `512` is the `Whistleblower_reward_quotient` + +## Slashing {#slashing} + +Slashing is a more severe action that results in the forceful removal of a validator from the network and an associated loss of their staked ether. There are three ways a validator can be slashed, all of which amount to the dishonest proposal or attestation of blocks: + +- By proposing and signing two different blocks for the same slot +- By attesting to a block that "surrounds" another one (effectively changing history) +- By "double voting" by attesting to two candidates for the same block + +If these actions are detected, the validator is slashed. This means that 1/64th of their staked ether (up to a maximum of 0.5 ether) is immediately burned, then a 36 day removal period begins. During this removal period the validators stake gradually bleeds away. At the mid-point (Day 18) an additional penalty is applied whose magnitude scales with the total staked ether of all slashed validators in the 36 days prior to slashing event. This means that when more validators are slashed, the magnitude of the slash increases. The maximum slash is the full effective balance of all slashed validators (i.e. if there are lots of validators being slashed they could lose their entire stake). On the other hand, a single, isolated slashing event only burns a small portion of the validator's stake. This midpoint penalty that scales with the number of slashed validators is called the "correlation penalty". + +## Inactivity Leak {#inactivity-leak} + +If the Beacon Chain has gone more than four epochs without finalizing, an emergency protocol called the "inactivity leak" is activated. The ultimate aim of the inactivity leak is to create the conditions required for the chain to recover finality. As explained above, finality requires a 2/3 majority of the total staked ether to agree on source and target checkpoints. If validators representing more than 1/3 of the total validators go offline or fail to submit correct attestations then it is not possible for a 2/3 supermajority to finalize checkpoints. The inactivity leak lets the stake belonging to the inactive validators gradually bleed away until they control less than 1/3 of the total stake, allowing the remaining active validators finalize the chain. However large the pool of inactive validators, the remaining active validators will eventually control >2/3 of the stake. The loss of stake is a strong incentive for inactive validators to reactivate as soon as possible! + +The reward, penalty and slashing design of the Beacon Chain encourages individual validators to behave correctly. However, from these design choices emerges a system that strongly incentivizes equal distribution of validators across multiple clients, and should strongly disincentivize single-client dominance. + +## Further Reading {#further-reading} + +[Upgrading Ethereum: The incentive layer](https://eth2book.info/altair/part2/incentives) +[Incentives in Ethereum's hybrid Casper protocol](https://arxiv.org/pdf/1903.04205.pdf) +[Rewards and Penalties on Ethereum 2.0](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) +[Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) + +_Sources_ +[_https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/_](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) +\__[\_https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/_](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/) diff --git a/src/data/developer-docs-links.yaml b/src/data/developer-docs-links.yaml index 870254e6060..c7811137478 100644 --- a/src/data/developer-docs-links.yaml +++ b/src/data/developer-docs-links.yaml @@ -77,6 +77,8 @@ to: /developers/docs/consensus-mechanisms/pos/weak-subjectivity/ - id: docs-nav-attestations to: /developers/docs/consensus-mechanisms/pos/attestations + - id: docs-nav-rewards-and-penalties + to: /developers/docs/consensus-mechanisms/pos/rewards-and-penalties/ - id: docs-nav-ethereum-stack path: /developers/docs/ items: diff --git a/src/intl/en/page-developers-docs.json b/src/intl/en/page-developers-docs.json index 8ac334ae02e..a7eece954ef 100644 --- a/src/intl/en/page-developers-docs.json +++ b/src/intl/en/page-developers-docs.json @@ -115,6 +115,7 @@ "docs-nav-data-structures-and-encoding-rlp": "Recursive-length prefix (RLP)", "docs-nav-data-structures-and-encoding-patricia-merkle-trie": "Patricia Merkle Trie", "docs-nav-data-structures-and-encoding-ssz": "Simple serialize (SSZ)", + "docs-nav-rewards-and-penalties": "PoS rewards and penalties", "page-calltocontribute-desc-1": "If you're an expert on the topic and want to contribute, edit this page and sprinkle it with your wisdom.", "page-calltocontribute-desc-2": "You'll be credited and you'll be helping the Ethereum community!", "page-calltocontribute-desc-3": "Use this flexible", From e774eb6bda07a25671e8f8b6bb2d71ad0ec745f0 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 23 Aug 2022 15:19:07 +0100 Subject: [PATCH 2/8] fix italic --- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index db77d5b7e96..9acd5be052f 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -33,7 +33,7 @@ For each attesting validator in each epoch, 1/8 of the `base_reward` then goes t The `base_reward` for each validator is then also multiplied by the `participation_rate` which is the fraction of all active validators that participate consistently with each other. So, if all validators attest identically, `base_reward`==`base_reward`, if 10% of validators fail to participate or do so differently to the majority `base_reward` == `base_reward * 0.9`. This ensures there is no benefit to attacking other validators. -The `base_reward` is also modified by the `inclusion_delay` which rewards prompt attestations. If the delay between block proposal and attestation is >= 1 slot, the attestor receives the full 7/8 _ `base_reward`. For each additional missed slot, the denominator is increased by 8, meaning that the reward for a delay of two slots is scaled by 7/16, for three slots it is 7/24, for four slots it is 7/32 (or, put another way, `7/8 _ base_reward \* 1/k`where`k` = number of slots separating block and attestation). 32 is the maximum inclusion delay denominator that can be applied. This means the slower the attestation, the smaller the reward. +The `base_reward` is also modified by the `inclusion_delay` which rewards prompt attestations. If the delay between block proposal and attestation is >= 1 slot, the attestor receives the full 7/8 * `base_reward`. For each additional missed slot, the denominator is increased by 8, meaning that the reward for a delay of two slots is scaled by 7/16, for three slots it is 7/24, for four slots it is 7/32 (or, put another way, `7/8 * base_reward * 1/k`where`k` = number of slots separating block and attestation). 32 is the maximum inclusion delay denominator that can be applied. This means the slower the attestation, the smaller the reward. There are also three additional rewards: `source` (reward for voting for the correct source checkpoint), `target` (reward for voting for the correct target checkpoint), `head` (reward for voting for the correct head block). The value of each of these is equal to `base_reward * inclusion_delay * participation_rate`. The same value can be removed from the validator's balance as a penalty for an incorrect or missing `source`, `target` or `head` vote. From 23ec421b2e4e0381ac761f36fff4b0ce7f9f5ad9 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Thu, 1 Sep 2022 14:56:18 +0100 Subject: [PATCH 3/8] Apply suggestions from code review Co-authored-by: Paul Wackerow <54227730+wackerow@users.noreply.github.com> --- .../pos/rewards-and-penalties/index.md | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 9acd5be052f..5dbb2c500f8 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -9,13 +9,13 @@ Ethereum is secured using its native cryptocurrency, ether (ETH). Node operators There are two primary roles for a validator: 1) checking new blocks and “attesting” to them if they are valid, 2) proposing new blocks when selected at random from the total validator pool. If the validator fails to do either of these tasks when asked they miss out on an ether payout. -There are also some actions that are very difficult to do accidentally and signify some malicious intent, such as proposing multiple blocks for the same slot or attesting to multiple blocks for the same slot. These are “slashable” behaviors that result in the validator having some amount of ether (up to 0.5 ETH) burned before the validator is removed from the network, which takes 36 days. The slashed validator’s ether slowly drains away across the exit period, but on Day 18 they receive a “correlation penalty” which is larger when more validators are slashed around the same time. The Beacon Chain’s incentive structure therefore pays for honesty and punishes bad actors. +There are also some actions that are very difficult to do accidentally and signify some malicious intent, such as proposing multiple blocks for the same slot or attesting to multiple blocks for the same slot. These are “slashable” behaviors that result in the validator having some amount of ether (up to 1 ETH) burned before the validator is removed from the network, which takes 36 days. The slashed validator’s ether slowly drains away across the exit period, but on Day 18 they receive a “correlation penalty” which is larger when more validators are slashed around the same time. The Beacon Chain’s incentive structure therefore pays for honesty and punishes bad actors. All rewards and penalties are applied once per epoch. Read on for more details... -## Rewards and penalties{#rewards} +## Rewards and penalties {#rewards} ### Attestation rewards {#attestation-rewards} @@ -25,15 +25,19 @@ Validators receive attestation rewards when they make votes that are consistent base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) ``` -where `base_reward_factor` = 64, `base_rewards_per_epoch` = 4 and the `active balance` is the total staked ether across all active validators. +where `base_reward_factor` is 64, `base_rewards_per_epoch` is 4 and `sum(active balance)` is the total staked ether across all active validators. This means the base reward is proportional to the validator's effective balance and inversely proportional to the number of validators on the network. The more validators, the greater the overall issuance (as `sqrt(N)` but the smaller the `base_reward` per validator (as `1/sqrt(N)`). These factors influence the APR for a staking node. Read the rationale for this in [Vitalik's notes](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). -For each attesting validator in each epoch, 1/8 of the `base_reward` then goes to the block producer, leaving up to 7/8 available for the attestor. +For each slot in an epoch, 1/8 of the `base_reward` goes to the block proposer, and 7/8 is available to be split over the attesting validators assigned to that slot. The `base_reward` for each validator is then also multiplied by the `participation_rate` which is the fraction of all active validators that participate consistently with each other. So, if all validators attest identically, `base_reward`==`base_reward`, if 10% of validators fail to participate or do so differently to the majority `base_reward` == `base_reward * 0.9`. This ensures there is no benefit to attacking other validators. -The `base_reward` is also modified by the `inclusion_delay` which rewards prompt attestations. If the delay between block proposal and attestation is >= 1 slot, the attestor receives the full 7/8 * `base_reward`. For each additional missed slot, the denominator is increased by 8, meaning that the reward for a delay of two slots is scaled by 7/16, for three slots it is 7/24, for four slots it is 7/32 (or, put another way, `7/8 * base_reward * 1/k`where`k` = number of slots separating block and attestation). 32 is the maximum inclusion delay denominator that can be applied. This means the slower the attestation, the smaller the reward. +The `base_reward` is also modified by the `inclusion_delay` which rewards prompt attestations, and degrades the reward for delayed attestations as these are less valuable to the network when forming consensus. If the distance between the attestation and block it is included in is only one block, the attester received the full `7/8 * base_reward`. + +This is the maximum possible reward, and will degrade inversely as the number of blocks increases before the attestation is included. If we denote this "inclusion distance" as `k`, the maximum reward (`7/8 * base_reward`) is divided by `k` to determine the reward after inclusion delay: `(7/8 * base_reward) / k`. Since an attestation cannot be included in the same slot, the optimal distance is one. The further allowable distance is 32 before the attestation is forfeited entirely. The inclusion delay factor can be summed up as `inclusion_delay = 7 / (8 * k)`. + +Note that empty slots (where a block was not proposed) do not count towards the inclusion distance for attestations from other validators. If a validator is assigned to attest to the 10th slot in an epoch, and there is no block proposed for the 11th slot causing the attestation to be included in a block at slot 12, this would still be considered an inclusion distance of 1. This prevents penalizing active validators for another validator being unavailable. There are also three additional rewards: `source` (reward for voting for the correct source checkpoint), `target` (reward for voting for the correct target checkpoint), `head` (reward for voting for the correct head block). The value of each of these is equal to `base_reward * inclusion_delay * participation_rate`. The same value can be removed from the validator's balance as a penalty for an incorrect or missing `source`, `target` or `head` vote. @@ -41,7 +45,7 @@ When validators are assigned to sync committees they receive rewards for each sl ### Attestation scenarios -Assuming attestations are timely (same slot as proposed block) the following table describes the attestation rewards for four scenarios: +Assuming attestations are timely (included in the very next block, inclusion distance of 1) the following table describes the attestation rewards for four scenarios: | `source` | `target` | `head` | `base_reward` | penalty | `inclusion_delay` | Result | | ----------------- | ----------------- | ----------------- | ---------------------------------------- | ------------------ | -------------------- | ----------------------------------------------------------------- | @@ -89,7 +93,8 @@ The reward, penalty and slashing design of the Beacon Chain encourages individua [Incentives in Ethereum's hybrid Casper protocol](https://arxiv.org/pdf/1903.04205.pdf) [Rewards and Penalties on Ethereum 2.0](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +[Eth2 Slashing Prevention Tips](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) _Sources_ -[_https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/_](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/) -\__[\_https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/_](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/) +_[https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/](https://consensys.net/blog/codefi/rewards-and-penalties-on-ethereum-20-phase-0/)_ +_[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ From 74bdf6043409c147fac89de3dd220ee21695f32b Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Thu, 1 Sep 2022 15:05:14 +0100 Subject: [PATCH 4/8] Update src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md --- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 5dbb2c500f8..dfcb56c44d4 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -7,7 +7,7 @@ sidebar: true Ethereum is secured using its native cryptocurrency, ether (ETH). Node operators that wish to participate in validating blocks and identifying the head of the chain deposit ether into a smart contract on Ethereum. They are then paid in ether to run validator software that checks the validity of new blocks received over the peer-to-peer network and apply the fork-choice algorithm to identify the head of the chain. -There are two primary roles for a validator: 1) checking new blocks and “attesting” to them if they are valid, 2) proposing new blocks when selected at random from the total validator pool. If the validator fails to do either of these tasks when asked they miss out on an ether payout. +There are two primary roles for a validator: 1) checking new blocks and “attesting” to them if they are valid, 2) proposing new blocks when selected at random from the total validator pool. If the validator fails to do either of these tasks when asked they miss out on an ether payout. Validators are also sometimes tasked with signature aggregation and participating in sync committees. There are also some actions that are very difficult to do accidentally and signify some malicious intent, such as proposing multiple blocks for the same slot or attesting to multiple blocks for the same slot. These are “slashable” behaviors that result in the validator having some amount of ether (up to 1 ETH) burned before the validator is removed from the network, which takes 36 days. The slashed validator’s ether slowly drains away across the exit period, but on Day 18 they receive a “correlation penalty” which is larger when more validators are slashed around the same time. The Beacon Chain’s incentive structure therefore pays for honesty and punishes bad actors. From 0d6755477ead57cb12eca0466f35fa0de3af54b9 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Mon, 5 Sep 2022 12:04:31 +0100 Subject: [PATCH 5/8] rework rewards and penalties section --- .../pos/rewards-and-penalties/index.md | 61 ++++++++----------- 1 file changed, 25 insertions(+), 36 deletions(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index dfcb56c44d4..108dfb1e927 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -17,9 +17,8 @@ Read on for more details... ## Rewards and penalties {#rewards} -### Attestation rewards {#attestation-rewards} - -Validators receive attestation rewards when they make votes that are consistent with the majority of other validators. The value of the attestation rewards in each epoch are calculated from a `base_reward`. This is the base unit that other rewards are calculated from. The `base_reward` represents the average reward received by a validator under optimal conditions per epoch. This is calculated from the validator's effective balance and the total number of active validators as follows: +### Rewards {#rewards} +Validators receive rewards when they make votes that are consistent with the majority of other validators, when they propose blocksd and when they participate in sync committees. The value of the rewards in each epoch are calculated from a `base_reward`. This is the base unit that other rewards are calculated from. The `base_reward` represents the average reward received by a validator under optimal conditions per epoch. This is calculated from the validator's effective balance and the total number of active validators as follows: ``` base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) @@ -29,47 +28,37 @@ where `base_reward_factor` is 64, `base_rewards_per_epoch` is 4 and `sum(active This means the base reward is proportional to the validator's effective balance and inversely proportional to the number of validators on the network. The more validators, the greater the overall issuance (as `sqrt(N)` but the smaller the `base_reward` per validator (as `1/sqrt(N)`). These factors influence the APR for a staking node. Read the rationale for this in [Vitalik's notes](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). -For each slot in an epoch, 1/8 of the `base_reward` goes to the block proposer, and 7/8 is available to be split over the attesting validators assigned to that slot. - -The `base_reward` for each validator is then also multiplied by the `participation_rate` which is the fraction of all active validators that participate consistently with each other. So, if all validators attest identically, `base_reward`==`base_reward`, if 10% of validators fail to participate or do so differently to the majority `base_reward` == `base_reward * 0.9`. This ensures there is no benefit to attacking other validators. - -The `base_reward` is also modified by the `inclusion_delay` which rewards prompt attestations, and degrades the reward for delayed attestations as these are less valuable to the network when forming consensus. If the distance between the attestation and block it is included in is only one block, the attester received the full `7/8 * base_reward`. - -This is the maximum possible reward, and will degrade inversely as the number of blocks increases before the attestation is included. If we denote this "inclusion distance" as `k`, the maximum reward (`7/8 * base_reward`) is divided by `k` to determine the reward after inclusion delay: `(7/8 * base_reward) / k`. Since an attestation cannot be included in the same slot, the optimal distance is one. The further allowable distance is 32 before the attestation is forfeited entirely. The inclusion delay factor can be summed up as `inclusion_delay = 7 / (8 * k)`. - -Note that empty slots (where a block was not proposed) do not count towards the inclusion distance for attestations from other validators. If a validator is assigned to attest to the 10th slot in an epoch, and there is no block proposed for the 11th slot causing the attestation to be included in a block at slot 12, this would still be considered an inclusion distance of 1. This prevents penalizing active validators for another validator being unavailable. - -There are also three additional rewards: `source` (reward for voting for the correct source checkpoint), `target` (reward for voting for the correct target checkpoint), `head` (reward for voting for the correct head block). The value of each of these is equal to `base_reward * inclusion_delay * participation_rate`. The same value can be removed from the validator's balance as a penalty for an incorrect or missing `source`, `target` or `head` vote. - -When validators are assigned to sync committees they receive rewards for each slot they sign off. When validators in a sync committee fail to sign blocks they are penalized exactly the value of ether they would have received for signing successfully. - -### Attestation scenarios - -Assuming attestations are timely (included in the very next block, inclusion distance of 1) the following table describes the attestation rewards for four scenarios: +The total reward is then calculated as the sum of five components that each have a weighting that determines how much each component adds to the total reward. The components are: +``` +1. source vote: the validator has made a timely vote for the correct source checkpoint +2. target vote: the validator has made a timely vote for the correct target checkpoint +3. head vote: the validator has made a timely vote for the correct head block +4. sync committee reward: the validator has participated in a sync committee +5. proposer reward: the validator has proposed a block in the correct slot +``` +The weightings for each component are as follows: -| `source` | `target` | `head` | `base_reward` | penalty | `inclusion_delay` | Result | -| ----------------- | ----------------- | ----------------- | ---------------------------------------- | ------------------ | -------------------- | ----------------------------------------------------------------- | -| incorrect/missing | incorrect/missing | incorrect/missing | 0 | 3 \* `base_reward` | 0 | -3 \* `base_reward` | -| correct | incorrect/missing | incorrect/missing | `base_reward` \* `participation_rate` | 2 \* `base_reward` | `base_reward` \* 7/8 | `base_reward` _ `participation_rate` - 9/8 _ `base_reward` | -| correct | correct | incorrect/missing | 2 _ `base_reward` _ `participation_rate` | `base_reward` | `base_reward` \* 7/8 | (2 _ `base_reward` _ `participation_rate`) - 1/8 \* `base_reward` | -| correct | correct | correct | 3 _ `base_reward` _ `participation_rate` | 0 | `base_reward` \* 7/8 | (3 _ `base_reward` _ `participation_rate`) + `base_reward` \* 7/8 | +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` -Assuming a 100% `participation_rate`: +These weights sum to 64. The reward is calculated as the sum of the applicable weigths divided by 64. A validator that has made timely source, target and head votes, proposed a block and participated in a sync committee could there receive `64/64 * base_reward == base_reward`. However, a validator is not usually a block proposer, so their maximum reward is `64-8 /64 * base_reward == 7/8 * base_reward`. Validators that are neither block proposers nor in a sync committee can receive `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. -- You vote correctly and gets included in the next slot: you get 31/8 \* `base_reward` -- You miss head because you got a late block and it gets included in the next slot: you get 15/8 \* `base_reward` -- You miss head and target cause you got late a block, you get -1/8 \* `base_reward` -- You attest and vote correctly, but the next block is missed, you get 55/16 \* `base_reward` +An additional reward is added to incentivize rapid attestations. This is the `inclusion_delay_reward`. This has a value equal to the `base_reward` multiplied by `1/delay` where `delay` is the number of slots separating the block proposal and attestation. For example, if the attestation is submitted within one slot of the block proposal the attestor receives `base_reward * 1/1 == base_reward`. If the attestation arrives int he next slot, the attestor received `base_reward * 1/2` and so on. -Overall these penalties are fairly mild and amount to a very slow bleed of staked ether for continued inactivity. +Block proposers receive `8 / 64 * base_reward` for **each valid attestation** included in the block, so the actual value of the reward scales with the number of attesting validators. Block proposers can also increase their reward by including evidence of misbehavior by other validators in their proposed block. These rewards are the "carrots" that encourage validator honesty. A block proposer which includes slashing will be rewarded with the `slashed_validators_effective_balance / 512`. -### Block reward {#block-reward} +### Penalties {#penalties} -When validators are selected to be block proposers they get rewarded if their proposed block gets finalized. Block proposers can also increase their reward by including evidence of misbehavior by other validators in their proposed block. These rewards are the "carrots" that encourage validator honesty. +So far we have considered perfectly well-behaved validators, but what about validators that do not make timely head, source and target votes or do so slowly? -Only **valid** attestations (correct source checkpoint) can be included in a block and the rewards for a block proposal scale with the amount of included attestations because they receive 1/8 of the `base_reward` for every attestation in the block. There is no penalty for failing to propose a block. +The penalties for missing the head, target and source votes are equal to the rewards the attestor would have received had they submitted them. This means that instead of having the reward aded to their balance, they have an equal value removed from their balance. There is no penalty associated with the `inclusion_delay` - the reward will simply not be added to the validator's balance. There is no penalty for failing to propose a block. -A block proposer which includes slashing will be rewarded with the `slashed_validators_effective_balance / 512` where `512` is the `Whistleblower_reward_quotient` +Read more about rewards and penalties in the [consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Rewards and penalties were adjusted in the Altair upgrade - watch DannY Ryan and Vitalik discuss this in this [Peep an EIP video](https://www.youtube.com/watch?v=iaAEGs1DMgQ). ## Slashing {#slashing} From b10031eac11317b5c2dc96fd359479fb4a3056aa Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 6 Sep 2022 12:02:27 +0100 Subject: [PATCH 6/8] Update src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md --- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 108dfb1e927..a422b1d346a 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -68,7 +68,7 @@ Slashing is a more severe action that results in the forceful removal of a valid - By attesting to a block that "surrounds" another one (effectively changing history) - By "double voting" by attesting to two candidates for the same block -If these actions are detected, the validator is slashed. This means that 1/64th of their staked ether (up to a maximum of 0.5 ether) is immediately burned, then a 36 day removal period begins. During this removal period the validators stake gradually bleeds away. At the mid-point (Day 18) an additional penalty is applied whose magnitude scales with the total staked ether of all slashed validators in the 36 days prior to slashing event. This means that when more validators are slashed, the magnitude of the slash increases. The maximum slash is the full effective balance of all slashed validators (i.e. if there are lots of validators being slashed they could lose their entire stake). On the other hand, a single, isolated slashing event only burns a small portion of the validator's stake. This midpoint penalty that scales with the number of slashed validators is called the "correlation penalty". +If these actions are detected, the validator is slashed. This means that 1/32 of their staked ether (up to a maximum of 1 ether) is immediately burned, then a 36 day removal period begins. During this removal period the validators stake gradually bleeds away. At the mid-point (Day 18) an additional penalty is applied whose magnitude scales with the total staked ether of all slashed validators in the 36 days prior to slashing event. This means that when more validators are slashed, the magnitude of the slash increases. The maximum slash is the full effective balance of all slashed validators (i.e. if there are lots of validators being slashed they could lose their entire stake). On the other hand, a single, isolated slashing event only burns a small portion of the validator's stake. This midpoint penalty that scales with the number of slashed validators is called the "correlation penalty". ## Inactivity Leak {#inactivity-leak} From d1427c9943368b501448d05fcd2dfe466f4d2f08 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 6 Sep 2022 12:04:56 +0100 Subject: [PATCH 7/8] add note about inactivity leak on medalla --- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index a422b1d346a..b126395f6f3 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -72,7 +72,7 @@ If these actions are detected, the validator is slashed. This means that 1/32 of ## Inactivity Leak {#inactivity-leak} -If the Beacon Chain has gone more than four epochs without finalizing, an emergency protocol called the "inactivity leak" is activated. The ultimate aim of the inactivity leak is to create the conditions required for the chain to recover finality. As explained above, finality requires a 2/3 majority of the total staked ether to agree on source and target checkpoints. If validators representing more than 1/3 of the total validators go offline or fail to submit correct attestations then it is not possible for a 2/3 supermajority to finalize checkpoints. The inactivity leak lets the stake belonging to the inactive validators gradually bleed away until they control less than 1/3 of the total stake, allowing the remaining active validators finalize the chain. However large the pool of inactive validators, the remaining active validators will eventually control >2/3 of the stake. The loss of stake is a strong incentive for inactive validators to reactivate as soon as possible! +If the Beacon Chain has gone more than four epochs without finalizing, an emergency protocol called the "inactivity leak" is activated. The ultimate aim of the inactivity leak is to create the conditions required for the chain to recover finality. As explained above, finality requires a 2/3 majority of the total staked ether to agree on source and target checkpoints. If validators representing more than 1/3 of the total validators go offline or fail to submit correct attestations then it is not possible for a 2/3 supermajority to finalize checkpoints. The inactivity leak lets the stake belonging to the inactive validators gradually bleed away until they control less than 1/3 of the total stake, allowing the remaining active validators finalize the chain. However large the pool of inactive validators, the remaining active validators will eventually control >2/3 of the stake. The loss of stake is a strong incentive for inactive validators to reactivate as soon as possible! An inactivity leak scenario was encountered on the Medalla testnet when < 66% of active validators were able to come to consensus on the current head of the blockchain. The inactivity leak was activated and finality was eventually regained! The reward, penalty and slashing design of the Beacon Chain encourages individual validators to behave correctly. However, from these design choices emerges a system that strongly incentivizes equal distribution of validators across multiple clients, and should strongly disincentivize single-client dominance. From 768612429b98c06bbcef6ae543474e6d1c162a67 Mon Sep 17 00:00:00 2001 From: Paul Wackerow <54227730+wackerow@users.noreply.github.com> Date: Mon, 12 Sep 2022 11:21:30 +0200 Subject: [PATCH 8/8] chore: small copy adjustments --- .../pos/rewards-and-penalties/index.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index b126395f6f3..a761c0de92c 100644 --- a/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/src/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -18,7 +18,8 @@ Read on for more details... ## Rewards and penalties {#rewards} ### Rewards {#rewards} -Validators receive rewards when they make votes that are consistent with the majority of other validators, when they propose blocksd and when they participate in sync committees. The value of the rewards in each epoch are calculated from a `base_reward`. This is the base unit that other rewards are calculated from. The `base_reward` represents the average reward received by a validator under optimal conditions per epoch. This is calculated from the validator's effective balance and the total number of active validators as follows: + +Validators receive rewards when they make votes that are consistent with the majority of other validators, when they propose blocks, and when they participate in sync committees. The value of the rewards in each epoch are calculated from a `base_reward`. This is the base unit that other rewards are calculated from. The `base_reward` represents the average reward received by a validator under optimal conditions per epoch. This is calculated from the validator's effective balance and the total number of active validators as follows: ``` base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) @@ -29,6 +30,7 @@ where `base_reward_factor` is 64, `base_rewards_per_epoch` is 4 and `sum(active This means the base reward is proportional to the validator's effective balance and inversely proportional to the number of validators on the network. The more validators, the greater the overall issuance (as `sqrt(N)` but the smaller the `base_reward` per validator (as `1/sqrt(N)`). These factors influence the APR for a staking node. Read the rationale for this in [Vitalik's notes](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). The total reward is then calculated as the sum of five components that each have a weighting that determines how much each component adds to the total reward. The components are: + ``` 1. source vote: the validator has made a timely vote for the correct source checkpoint 2. target vote: the validator has made a timely vote for the correct target checkpoint @@ -36,6 +38,7 @@ The total reward is then calculated as the sum of five components that each have 4. sync committee reward: the validator has participated in a sync committee 5. proposer reward: the validator has proposed a block in the correct slot ``` + The weightings for each component are as follows: ``` @@ -46,19 +49,19 @@ SYNC_REWARD_WEIGHT uint64(2) PROPOSER_WEIGHT uint64(8) ``` -These weights sum to 64. The reward is calculated as the sum of the applicable weigths divided by 64. A validator that has made timely source, target and head votes, proposed a block and participated in a sync committee could there receive `64/64 * base_reward == base_reward`. However, a validator is not usually a block proposer, so their maximum reward is `64-8 /64 * base_reward == 7/8 * base_reward`. Validators that are neither block proposers nor in a sync committee can receive `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. +These weights sum to 64. The reward is calculated as the sum of the applicable weights divided by 64. A validator that has made timely source, target and head votes, proposed a block and participated in a sync committee could receive `64/64 * base_reward == base_reward`. However, a validator is not usually a block proposer, so their maximum reward is `64-8 /64 * base_reward == 7/8 * base_reward`. Validators that are neither block proposers nor in a sync committee can receive `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. -An additional reward is added to incentivize rapid attestations. This is the `inclusion_delay_reward`. This has a value equal to the `base_reward` multiplied by `1/delay` where `delay` is the number of slots separating the block proposal and attestation. For example, if the attestation is submitted within one slot of the block proposal the attestor receives `base_reward * 1/1 == base_reward`. If the attestation arrives int he next slot, the attestor received `base_reward * 1/2` and so on. +An additional reward is added to incentivize rapid attestations. This is the `inclusion_delay_reward`. This has a value equal to the `base_reward` multiplied by `1/delay` where `delay` is the number of slots separating the block proposal and attestation. For example, if the attestation is submitted within one slot of the block proposal the attestor receives `base_reward * 1/1 == base_reward`. If the attestation arrives in the next slot, the attestor received `base_reward * 1/2` and so on. Block proposers receive `8 / 64 * base_reward` for **each valid attestation** included in the block, so the actual value of the reward scales with the number of attesting validators. Block proposers can also increase their reward by including evidence of misbehavior by other validators in their proposed block. These rewards are the "carrots" that encourage validator honesty. A block proposer which includes slashing will be rewarded with the `slashed_validators_effective_balance / 512`. ### Penalties {#penalties} -So far we have considered perfectly well-behaved validators, but what about validators that do not make timely head, source and target votes or do so slowly? +So far we have considered perfectly well-behaved validators, but what about validators that do not make timely head, source and target votes or do so slowly? -The penalties for missing the head, target and source votes are equal to the rewards the attestor would have received had they submitted them. This means that instead of having the reward aded to their balance, they have an equal value removed from their balance. There is no penalty associated with the `inclusion_delay` - the reward will simply not be added to the validator's balance. There is no penalty for failing to propose a block. +The penalties for missing the head, target and source votes are equal to the rewards the attestor would have received had they submitted them. This means that instead of having the reward added to their balance, they have an equal value removed from their balance. There is no penalty associated with the `inclusion_delay` - the reward will simply not be added to the validator's balance. There is no penalty for failing to propose a block. -Read more about rewards and penalties in the [consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Rewards and penalties were adjusted in the Altair upgrade - watch DannY Ryan and Vitalik discuss this in this [Peep an EIP video](https://www.youtube.com/watch?v=iaAEGs1DMgQ). +Read more about rewards and penalties in the [consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Rewards and penalties were adjusted in the Bellatrix upgrade - watch Danny Ryan and Vitalik discuss this in this [Peep an EIP video](https://www.youtube.com/watch?v=iaAEGs1DMgQ). ## Slashing {#slashing}