V God released the first hard fork proposal HF1 of the ETH2.0 beacon chain, introducing a fairer node penalty mechanism

Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc), by Kyle, published with permission.

Editor's Note: This article comes from

Babbitt Information (ID: bitcoin8btc)

• Babbitt Information (ID: bitcoin8btc)

• , by Kyle, published with permission.

• "The founder of Ethereum, V God, introduced the upgrade proposal of the first hard fork of the Ethereum Beacon Chain (tentatively named "HF1") on Twitter. V God said that HF1 added light client support and simplified specification, improved efficiency, and introduced 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 way to make deeper Useful test for changes. Where light clients support nodes that have minimal resource requirements and can run on mobile devices. This will allow "minimum trust wallets" to be able to verify the blockchain themselves, rather than relying on external services to provide By."

HF1 is the tentative code name for the first hard fork upgrade of the Ethereum beacon 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 the beacon chain. These vulnerabilities were discovered too late to be fixed when the Beacon Chain genesis kicked off.

The consensus changes proposed in HF1 include:

more content:https://github.com/ethereum/eth2.0-specs/pull/2130

Synchronization Committee

In each time period (approximately 27 hours), 1024 validators are randomly selected as members of the sync 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.

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

more content:

Bookkeeping Reform (Tier 1)

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:

Bookkeeping Reform (Tier 2)https://github.com/ethereum/eth2.0-specs/issues/2098

• Additionally, we've made two changes to how inactivity penalties work:

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

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

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.

• 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)

More discussion can be found here:

Validator inactivity penalties are gradually slowed down rather than stopped after being determined. 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:

One thing to celebrate is that by weakening the validator penalty, we may be slightly (though not completely) out of the woods. We'll make changes to the constants:

Fork choice changes deployed at (nearly) the same time as HF1https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf

Currently, if no block was published in the most recent slot, it is considered the latest block in the chain that the prover is supporting for the purposes of LMD GHOST proofs during that slot. For example, in this diagram below, proofs on BLANK count as proofs on A:

more content:https://github.com/ethereum/eth2.0-specs/pull/2197

However, this opens the door for 34% attacks. 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 Section 3.1 of the paper:

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.