Polish `merge/beacon-chain.md` with mostly non-substantive changes.
**Non-substantive changes**
* rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD`
- rename "execution transaction" to just "transaction" as per discussion with Danny
* rename `compute_time_at_slot` to `compute_timestamp_at_slot`
- the function returns a Unix timestamp
- "timestamp" matches `execution_payload.timestamp`
* be explicit about `ExecutionEngine.execution_state` for clarity
* rename `ExecutionPayload.number` to `ExecutionPayload.block_number`
- more specific ("number" is pretty vague)
- consistent with `ExecutionPayload.block_hash`
* rename `new_block` to `on_payload`
- the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers))
- the `_payload` suffix is more to the point given the function accepts an `execution_payload`
- avoids conflict with `on_block` which is already used in the fork choice
* rework the table of contents for consistency
* order `is_execution_enabled` after `is_transition_completed` and `is_transition_block`
- `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block`
* rename "transition" to "merge"
- "transition" is a bit vague—we will have other transitions at future hard forks
- there is no need for two words to refer to the same concept
* add a bunch of inline comments, e.g. in `process_execution_payload`
* make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body`
* remove `TRANSITION_TOTAL_DIFFICULTY`
- to be put in `merge/fork-choice.md` where it is used
* various misc cleanups
**Substantive changes**
* reorder `ExecutionPayload` fields
- for consistency with yellow paper and Eth1
- same for `ExecutionPayloadHeader`
- added comments separating out the execution block header fields from the extra fields (cosmetic)
Sync committee rewards as currently implemented significantly increase variance in proposer rewards: https://github.com/ethereum/eth2.0-specs/issues/2448
For example, if there are 200000 validators (6.4m ETH staked), then during each 1/4-eek (~54 hour) period there is a chance of 512/200000 that a validator will get accepted into the sync committee, so on average that will happen once every 200000/512 * 1/4 = 97.6 eeks, or close to two years. The payout of this "lottery" is 1/8 of that, or ~12.2 eeks (a bit less than four months) of revenue. This is much more severe than block proposing (a chance of 1/200000 per slot, or a lottery worth ~0.38 eeks of revenue once every ~3.05 eeks).
This PR makes three changes to cut make the sync committee lottery less drastic and bring variance closer in line with what is available from block proposing:
* Reduce the `SYNC_REWARD_WEIGHT` from 8 to 2
* Add a penalty for not participating in the sync committee, so that despite the first change the total net reward for participating vs not participating is only cut down by 2x
* Reduce the sync committee period from 1/4 eek to 1/8 eek (~27 hours)
With these three factors combined, the lottery reduces to ~1.5 eeks of revenue, on average occurring every ~48 eeks. Validators who are maximally unlucky (ie. never become part of a sync committee) only lose ~3.12% of their rewards instead of ~12.5%.
The compromises that this approach makes are:
* In the extreme case where >50% of proposers are operating efficiently, being in a sync committee becomes a net burden. However, this should be extremely rare, and in such cases validators would likely be suffering inactivity leak penalties anyway.
* Incentive to participate in a sync committee decreased by 2x (but this is IMO an improvement; sync committees are _not_ as important as proposals and deserve to have lower rewards)
* Minimum data syncing needed to maintain a light client increases by 2x (from 24 kB per 54 hours to 24 kB per 27 hours). A burden for on-chain light clients, but still insignificant for others.
Danny Ryan
Mikhail Kalinin
terence tsao
Justin
protolambda
Nishant Das
ericsson
Alex Stokes
Anton Nashatyrev
Hsiao-Wei Wang
vbuterin
Paul Hauner