All news is rigorously fact-checked and reviewed by leading blockchain experts and seasoned industry insiders.
- Buterin has made the details of Ethereum 2.0’s first hard fork public.
- HF1 will introduce support for light clients and reduce penalties to honest nodes.
Ethereum’s inventor Vitalik Buterin released a plan for the first hard fork of the Beacon Chain (Ethereum 2.0) yesterday. The preliminary codename is HF1. The main goals of HF1 are to add light-client support and fix some vulnerabilities in the Beacon Chain that were discovered too late to be addressed at Genesis. In addition, the hard forking mechanism should become testable “with a relatively small change” “before major changes (sharding, merging) need to be made.” Last but not least, the plan proposes several consensus changes with HF1.
Ethereum 2.0’s first hard fork
As Buterin discusses, support for light clients – nodes that have minimal resource requirements and could run on mobile devices – will be created by a randomly selected “sync committee.”
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.
This, Buterin says, will enable “trust-minimized wallets” that are able to verify the blockchain on their own, rather than users having to rely on external service providers and thus trust their integrity.
In addition, HF1 is intended to mitigate an issue that has been hotly debated for months, “slashing.” Until now, it is the case on the Beacon Chain that validators can lose some of their staked ETH in the event of inactivity. This made staking dangerous, especially for smaller “home stakers” as they are penalized for events that were not their fault, like an internet or power outage.
HF1 aims to mitigate this by distinguishing between intermittent and continuous inactivity:
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.
As for fixing vulnerabilities, Buterin wrote that there were improvements to the fork-choice rules. The developers identified several cases where the protocol opened the door to 34% attacks and a “balance attack.” Even if precise timing had been required for the attacks, a reorganization of the blockchain could have taken place. However, the bugs have now been fixed.
Currently, it is not yet known when the fork will be activated. Meanwhile, a naming convention for all upcoming hard forks of Ethereum 2.0 is being sought via GitHub. Among the suggestions are chemical elements, World of Warcraft zones, mythical objects, star names, solar systems and city names.
