Skip to content

Typo: missing closing parenthesis #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Typo: missing closing parenthesis #26

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion altair/beacon-chain.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -722,7 +722,7 @@ def process_sync_aggregate(state: BeaconState, aggregate: SyncAggregate) -> None

This function verifies that the sync committee included in the block is correct, and computes and applies the rewards for participants. The signature verification logic is simple: sync committee members are expected to sign the block header, and the signing root is computed from the block header root and the domain (much like all BLS signatures in the beacon chain protocol sign messages with domains attached for anti-replay-rpotection reasons). The signature is verified against the subset of sync committee members that participated, which can be determined from the sync committee and the bitfield.

There is some subtlety in correctly computing the rewards. The goal is for maximum possible total sync committee rewards to equal `2/64` of the base reward for the _total_ validator set (so that _in the long term, on average_, a perfectly participating validator gets `2/64` of the base reward per epoch for their sync committee participation. The base reward itself is per-epoch, and sync committees are per-slot, so to get the total reward per-slot, we take the total base reward and further divide it by `SLOTS_PER_EPOCH`. This gives us `max_participant_rewards`, the maximum possible combined reward to the whole sync committee in one slot.
There is some subtlety in correctly computing the rewards. The goal is for maximum possible total sync committee rewards to equal `2/64` of the base reward for the _total_ validator set (so that _in the long term, on average_, a perfectly participating validator gets `2/64` of the base reward per epoch for their sync committee participation). The base reward itself is per-epoch, and sync committees are per-slot, so to get the total reward per-slot, we take the total base reward and further divide it by `SLOTS_PER_EPOCH`. This gives us `max_participant_rewards`, the maximum possible combined reward to the whole sync committee in one slot.

We get the `participant_reward` (the reward to each participant) by dividing the `max_participant_rewards` by the size of the committee. Proposer rewards for including signatures are set to `8/56` of the rewards for producing the signatures, [just like in the rest of the protocol](#aside-proposer-rewards-in-altair).

Expand Down