Vitalik Buterin: Ethereum 2.0 Beacon Chain Prepares for Its First HF1 Hard Fork Upgrade

On Monday, February 15, Ethereum co-founder Vitalik Buterin published the plan for the first-ever hard fork upgrade of the Ethereum 2.0 Beacon Chain. Dubbed HF1, this hard fork upgrade will also let developers introduce new features to the Beacon Chain.

These new features will also serve as the foundation for additional changes in the future. One of the most-important upgrades with the hard fork is the addition of light clients. It means that the nodes can run even on mobile devices with minimal resource requirements. This will facilitate the “trust minimalized wallets” that can verify the blockchain on their own instead of relying on any third-party service providers.

The introduction of the light client will happen via special-purpose “sync committees”. The blog post by Vitalik states:

“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)”.

Ethereum 2.0 Hard Fork to Solve Vulnerability to Re-Organization Attacks

The Ethereum 2.0 developers spotted several instances of the protocol that are vulnerable to re-org attacks. This vulnerability might have allowed malicious actors to exploit the network by controlling some validators. Buterin also states that developers spotted these vulnerabilities before the launch. However, it was too late for any fixes by then.

Besides, the hard fork in the Beacon Chain also aims to overhaul or cut-down the inactivity leakage mechanics work. At present, ETH 2.0 stakers can lose a portion of their capital for being inactive. Also, they get punished for supporting any minority fork n the chain. In addition, the stakers also faced flak for patchy internet connections and blackouts.

The team is thus working on a mechanism that makes life simpler for stakers and other unstable connections. The blog post notes that the inactivity leak will become ‘quadratic’ per validator. Thus “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”.

Upon finality, the inactivity leak also slows down gradually rather than stopping completely. “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”.