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

Ethereum founder V God introduced the first hard fork of the Ethereum beacon chain (tentatively named “HF1”) upgrade proposal on Twitter. God said that HF1 added light client support, simplified specifications, improved efficiency, and introduced a less punitive inactivity penalty mechanism. According to the document, the hard fork will allow developers to perform some key upgrades to the recently released beacon chain, and will also be a useful test for deeper changes in the future. Among them, the light client supports nodes that require the least resources and can run on mobile devices. This will allow “trust-minimized wallets” to be able to verify the blockchain on their own, rather than relying on external service providers. “

HF1 is the tentative code name for the first hard fork upgrade of the Ethereum beacon chain (for the long-term naming idea of ​​the hard fork, please see here). 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 repaired when the beacon chain started.

Test the hard-fork upgrade mechanism of the beacon chain in a minor change upgrade environment for larger changes in the future.

The consensus changes proposed in HF1 include:

Synchronization Committee

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

In each time period (approximately 27 hours), 1024 validators are randomly selected as members of the synchronization committee. The verifier node in the synchronization committee will issue a signature to prove to the current head. These signatures will be broadcast as part of the LightClientUpdate object, which can help light clients find this head and will be included in the beacon chain for rewards.

Bookkeeping Reform (Level 1)

We replaced the calculation method of the prover’s reward. Rather than storing PendingAttestation objects and finally processing them, we chose to add a bit field to store the status of each verifier, so that data about who participated in it can be accumulated in real time. The bit fields are sorted in “regroup order” to ensure that the records of verifiers in the same committee are displayed together. The purpose of this change is to simplify client implementation and make it cheaper to update Merkle trees.

Bookkeeping Reform (Level 2)

We make changes to the validator set, and the penalty accounting only occurs once every 64 epochs, not every single epoch. The purpose of this is to greatly reduce the complexity of dealing with “empty period transition”-for example, there is a chain with very low participation, in which two consecutive blocks are separated by a thousand slots, and there is only a blank period between them. In order to deal with such a chain, the client currently needs to recalculate the balance of each verifier once every period to punish the verifier for inactivity; in the new proposal, they only need to execute it once every 64 periods.

In addition, we made two changes to the way the inactivity penalty works:

The inactivity penalty will become a quadratic for each verifier. In other words, if there is an inactivity penalty, validators who are completely offline during this period will lose about 10% of their balance, and validators who are online 90% of the time during this period will now only lose about 0.1% of their balance (relative to ~1%). This attempts to focus penalties on nodes that really misbehave and reduce honest nodes that go offline due to network connection problems.

The verifier inactivity penalty gradually slows down instead of stopping after it is determined. This ensures that once the final state is reached, offline nodes will continue to lose their balance for a period of time, thereby ensuring that the percentage of validators’ online time is significantly higher than 2/3, rather than just slightly higher than the threshold.

The point to celebrate is that by weakening the verifier’s fines, we may get out of the predicament a little (though not yet fully). We will make changes 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 selection changes deployed at the same time as HF1 (close to)

(Block, slot) for (pair) fork choice

Currently, if no block is published in the most recent slot, for the purpose of the LMD GHOST proof during the slot, it is regarded as the latest block in the chain that the prover is supporting.

However, this opened the door to 34% attacks. Assume that m validators are assigned to each slot, and the malicious attacker controls 0.34*m. The attacker also has the right to publish block B for slot n+1. The attack proceeded as follows: the attacker did not release B, nor did he release any proof of it. All honest provers will vote for the claim that they see block A in the nth slot and see nothing in the n+1th slot. The current count is considered a vote for A. In the n+2th slot, an honest proposer will build a block C on top of A. At this time, the malicious proposer will announce B and its proof of B to slots n+1 and n+2. The upper fork has 0.68*m validators supporting it, but the top fork only supports 0.66*m, so the lower fork wins.

The proposed solution is to change the way the fork selection works, so that it operates on the tree of (block, slot) pairs instead of on the block tree. Therefore, in the above figure, honest votes in slot n+1 will be counted as votes for (BLANK, n+1), so they will be correctly counted as supporting the above fork, so the above fork is supported It is 1.32*m, thus defeating the attack.

Fix forking balance attack

There is a “balance attack” in the fork selection. An attacker with 2% of validators will issue a small number of proofs at the correct time before the end of a slot, persuading more than 49% of people in the network to believe that a certain block A wins. And more than 49% of the networks believe that Block B won. If they schedule the broadcast time correctly, each group of verifiers will see the message for them on time, but there is no time to rebroadcast the message to another group of verifiers before the slot ends. If the network environment is optimal for the attacker, they can be repeated indefinitely.

The proposed solution is to authorize the proposer of the next slot to have a temporary but significant impact on the fork choice, thereby decisively shifting the direction of support of all verifiers to one side or the other, thus “breaking the symmetry” .