# HF1 Proposal HF1 is the tentative code name for the first hard fork of the beacon chain (see [here](https://github.com/ethereum/eth2.0-pm/issues/202) for longer-term naming ideas). The key goals of HF1 are: 1. Add light client support 2. Fix some weaknesses in the beacon chain that were discovered too late to be fixed at genesis 3. Test the hard forking mechanism with a relatively small change, before larger changes (sharding, merge) need to be done ## Proposed consensus changes in HF1 ### Sync committees We add a randomly sampled "sync committee" to the beacon chain. The purpose of this is to allow light clients to determine the head of the chain with a low amount of overhead (~20 kB per day minimum to keep up, and ~500 bytes to verify a single block). This would allow light clients to actually be viable for mobile devices, in-browser use cases in the like for the beacon chain (and post-merge Ethereum as a whole), paving the way for a much more trust-minimized wallet ecosystem. For each period (~27 hours), 1024 validators are randomly selected to be part of the sync committee during that period. Validators in the sync committee would publish signatures attesting to the current head. These signatures would be broadcasted as part of a `LightClientUpdate` object that could help light clients find the head, and would be included in the beacon chain to be rewarded. Key PR: * https://github.com/ethereum/eth2.0-specs/pull/2130 ### Accounting reform (tier 1) We replace the way that rewards for attesters are computed. Instead of storing `PendingAttestation` objects and then processing them at the end, we add a bitfield that stores the status of each validator, allowing the data about who participated to be accumulated in real time. The bitfield is ordered "in shuffled order", ensuring that records for validators in the same committee appear together. The goal of this change is to simplify client implementations and to make updating the Merkle tree much cheaper. Key PR: * https://github.com/ethereum/eth2.0-specs/pull/2176 ### Accounting reform (tier 2) We make validator set changes and penalty accounting only happen once every 64 epochs, instead of every single epoch. The goal of this is to greatly reduce the complexity of processing "empty epoch transitions" - for example, a chain with very low participation where two successive blocks are a thousand slots apart with only empty space between them. To process such a chain, currently clients would need to recompute each validator's balance once per epoch to apply inactivity penalties; with this proposal, they would only need to do so once per 64 epochs. Additionally, we add two changes to how inactivity leaks work: * **The inactivity leak becomes quadratic per validator**. That is, if there is an inactivity leak during which a fully offline validator loses ~10% of their balance, a validator that is online 90% of the time during that period would lose only ~0.1% of their balance (as opposed to ~1%). This attempts to focus penalties on truly misbehaving nodes and reduce penalties to honest nodes that merely have an imperfect connection to the network. See [here](https://github.com/ethereum/eth2.0-specs/issues/2125) for further discussion. * **The inactivity leak slows down gradually upon finality instead of stopping**. This ensures that once finality is reached, offline nodes continue to lose balance for some time further, ensuring that the percentage online is significantly above 2/3 instead of being only a little bit above that threshold. See [here](https://github.com/ethereum/eth2.0-specs/issues/2098) for further discussion (though note that the proposal there is slightly different). Key PRs: * https://github.com/ethereum/eth2.0-specs/pull/2192 * https://github.com/ethereum/eth2.0-specs/pull/2194 ### Adjustment to penalty constants We celebrate the fact that we are somewhat, though not yet completely, out of the woods by weakening the training wheels on validator penalties. We change the constants: * `INACTIVITY_PENALTY_QUOTIENT`: reduced from `2**26` (= 67,108,864) to `3 * 2**24` (= 50,331,648) * `PROPORTIONAL_SLASHING_MULTIPLIER`: increased from `1` to `2` * `MIN_SLASHING_PENALTY_QUOTIENT`: reduced from `2**7` (= 128) to `2**6` (= 64) ## Proposed fork choice changes for (approximately) simultaneous deployment with HF1 ### Fork choice by (block, slot) pair Currently, if there is no block published in the most recent slot, then for the purposes of LMD GHOST attestations during that slot count as supporting the most recent block in the chain that the attester is supporting. For example, in this diagram below, attestations on BLANK count as attestations on A:  However, this opens the door to 34% attacks. Suppose that there are `m` validators assigned to each slot, of which a malicious attacker controls `0.34 * m`. The attacker also has the right to publish B for slot `n+1`. The attack proceeds as follows: the attacker DOES NOT publish B, and does not publish any of their attestations. All honest attesters would vote for the claim that they saw A in slot `n` and nothing in slot `n+1`, which currently counts as votes for A. During slot `n+2`, an honest proposer would build a block `C` on top of `A`, and the honest validators would support C. At this point, the malicious proposer reveals B and their attestations for B for _both slots `n+1` and `n+2`_. The bottom fork has `0.68 * m` validators supporting it, but the top fork only has `0.66 * m` support, so the bottom fork wins. This attack is described in more detail in section 3.1 of this paper here: https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf The proposed fix is to change the way fork choice works, so that instead of operating on the tree of blocks, it operates on the tree of (block, slot) pairs. Hence, the honest votes during slot `n+1` would count as votes for `(BLANK, n+1)` in the diagram above, and so they would correctly count as supporting the top fork, and so the top fork's support would be `1.32 * m` and it would defeat the attack. Key PR: * https://github.com/ethereum/eth2.0-specs/pull/2197 ### Fork choice balance attack fix There is a ["balance attack" on the fork choice](https://arxiv.org/pdf/2009.04987.pdf), where an attacker with 2% of validators publishes a small amount of attestations at the right time just before the end of a slot, convincing >49% of the network that some block A is winning and >49% that block B is winning. If they time their broadcast correctly, each group sees the messages aimed at them on time, but does not have time to rebroadcast the messages to the other group before the slot boundary ends. They can then repeat potentially indefinitely, if network circumstances are optimal for the attacker. The proposed fix "breaks the symmetry" by empowering the proposer of the next slot to have a temporary, but significant, impact on the fork choice, decisively shifting all validators' position to one side or the other. Key doc: * https://notes.ethereum.org/@vbuterin/lmd_ghost_mitigation