Partnered With:

What did HF1, the first hard fork proposal of the ETH2.0 beacon chain, do?

Read this article in 13 Minutes

Fairer node penalty mechanism

Original title: "V God Releases ETH2.0 Beacon Chain's First Hard Fork Proposal HF1, Introducing a Fairer Node Punishment Mechanism"

Original Source: Babbitt

“V God, the founder of Ethereum, introduced the first hardware of the Ethereum Beacon Chain on Twitter < span class="font">Fork (tentatively named "HF1") upgrade proposal. V God said that HF1 added light client support, simplified specifications, and improved It improves efficiency and introduces a less punitive inactivity penalty mechanism. According to the document, the hard fork will allow developers to make some key upgrades to the recently released beacon chain, and will also be a useful tool for making deeper changes in the future. Testing. Where light clients support nodes that require minimal resources and can run on mobile devices. This will allow for a "trust-minimized wallet"Be able to verify the blockchain itself instead of relying on external service providers."

HF1 is an Ethereum beacon The tentative code name for the first hard fork upgrade of the chain (see here for the long-term naming idea for this hard fork). The main goals of HF1 are:

Add light client support
Fix some vulnerabilities in beacon chain. These vulnerabilities were discovered too late to be fixed when the Beacon Chain genesis kicked off.
Test the hard fork upgrade mechanism of the beacon chain in a minor change upgrade environment for future larger changes changes.

Consensus changes proposed in HF1 include:

Sync committee

We add a randomly drawn "sync committee" to the beacon chain. The purpose of this is to allow light clients to determine the chain head with very little overhead (about 20 kilobytes per day minimum, and about 500 bytes to verify a single block). This will enable light clients to actually use the beacon chain for use cases such as mobile devices, built-in browsers, paving the way for a more trust-minimized wallet ecosystem.

In each time period (about 27 hours), 1024 validators are randomly selected as members of the synchronization committee. Validator nodes in the sync committee will issue signatures to attest to the current head. These signatures will be broadcast as part of the LightClientUpdate object that helps light clients find this head and will be included in the beacon chain for rewards.

More content: https:/ /github.com/ethereum/eth3.0-specs/pull/2130

Accounting Reform (Level 1)

< p>

We replaced the calculation of prover rewards. Instead of storing PendingAttestation objects and processing them at the end, we chose to add a bitfield that stores the state of each validator, allowing real-time accumulation of data about who participated. Bitfields are sorted in "shuffling order" to ensure that records from validators in the same committee appear together. The purpose of this change is to simplify the client implementation and make it cheaper to update the Merkle tree.

Specific reference: https:// github.com/ethereum/eth3.0-specs/pull/2176

Accounting Reform (Level 2)

We make changes to the validator set, and penalty bookkeeping only happens every 64 epochs, not every single epoch. The purpose of this is to greatly reduce the complexity of dealing with "gap period transitions" - for example, there is a chain with very low participation where two consecutive blocks are separated by a thousand slots with only a gap period between them. To handle such chains, currently clients need to penalize validators for inactivity by recalculating each validator's balance every epoch; in the new proposal, they only need to do it every 64 epochs.

Additionally, we have made two changes to how inactivity penalties work:

The inactivity penalty will become quadratic for each validator. That is, if there is an inactivity penalty during which a validator who was completely offline loses about 10% of its balance, a validator who was online 90% of the time during this period will now only lose about 0.1% of its balance (compared to ~ 1%). This attempts to focus penalties on truly misbehaving nodes and less on honest nodes that are offline due to network connectivity issues.

For more discussion, please refer to this at: https://github.com/ethereum/eth3.0-specs/issues/2098

Verifier inactivity penalty Gradually slow down rather than stop when you are sure. This ensures that once the final state is reached, offline nodes will continue to lose their balance for a period of time, ensuring that the validator percent online time is significantly higher than 2/3, rather than just slightly above that threshold.

Specific reference: https://github.com/ethereum/eth3.0-specs/pull/2192

< p>

https://github.com/ethereum/eth3. 0-specs/pull/2194

One point to celebrate is that we may be slightly (though not quite) out of the woods by weakening validator penalties . We will make a change to the constant:

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)

Fork choice change for (near) simultaneous deployment with HF1

Fork selection of (block, slot) pair (pair)

Currently, if no blocks were published in the nearest slot, then out For LMD GHOST proof purposes during that slot, it is considered the latest block in the chain that the prover is supporting. For example, in the picture below, the proof on BLANK is counted as the proof on A:

V God released the Eth3.0 beacon chain The first hard fork proposal HF1 introduces a fairer node penalty mechanism

However, this opens the door for a 34% attack. Assume m validators are assigned to each slot, where the malicious attacker controls 0.34*m. The attacker also has the right to publish block B for slot n+1. The attack proceeds as follows: The attacker does not publish B, nor any proof of it. All honest attesters will vote for the claim that they saw block A in slot n and nothing in slot n+1, and this count is currently considered a vote for A. In slot n + 2, an honest proposer will construct a block C on top of A. At this time, the malicious proposer will announce B and its proof of B to slot n + 1 and n + 2. The upper fork has 0.68*m validators backing it, but the top fork only has 0.66*m backing, so the lower fork wins.

This attack is described in more detail in Chapter 3.1 of the paper: https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf

The proposed solution is to change the way fork selection works so that it operates on a tree of (block, slot) pairs rather than a tree of blocks. So, in the graph above, honest votes in slot n+1 will count as votes for (BLANK,n+1), so they will correctly count as supporting the fork above, so the support the fork above gets is 1.32*m, thus defeating the attack.

More content: https:/ /github.com/ethereum/eth3.0-specs/pull/2197

Fix fork choice balance attack

There is a "balance attack" in fork selection, where an attacker with 2% of validators will issue a small amount of proof at the right time before a slot ends, convincing more than 49% of the network of people think that a certain block A won, while more than 49% of the network thinks that block B won. If they time the broadcast correctly, each set of validators will see the message addressed to them on time, but will not have time to rebroadcast the message to another set of validators before the slot ends. They can be repeated indefinitely if the network environment is optimal for the attacker.

The proposed solution is to make the direction of support of all validators decisive by empowering the proposer of the next slot to have a temporary but significant influence on the choice of fork shift to one side or the other, thereby "breaking the symmetry".