Thin client support is also among the improvement proposals. This hard fork is a test to see how the network works when making changes.
Few months after the Beacon Chain network’s activation, the first step of the new Ethereum 2.0 is the first hard fork. Vitalik Buterin himself, the co-founder of the smart contract network, announced the modification.
The proposal to change the code appeared in public this Monday, February 15, which temporary identification was as HF1. Some features include series of adjustments to penalties for breaching nodes and support for thin clients.
According to Buterin, the fork’s purpose is to correct every single weak point that would be discovered too late before the activation of the Beacon Chain and set a test to the hard fork mechanism regarding changes that seem to be relatively small.
Ethereum 2.0 Penalties and Inactivity
Regarding adjustments of the inactivity flight penalties, Buterin explained in the report that there was a proposal for a change of operation. According to the developer, the leak becomes quadratic for each validator node.
“If there is an idle leak during which a validator that does not appear online lost 10% of its balance, then a validator that is online 90% of the time during that period will only lose ~ 0.1% of its balance. Balance (instead of ~ 1%)”, highlighted the programmer.
For Buterin, the modification would focus on sanctioning nodes that show lousy behavior and not the nodes that show connectivity or even power problems. The proposal would set differences between continuous inactivity and intermittences due to extra-factors.
These are penalties that punish those malicious nodes that operate and spread their malice. The Ethereum 2.0’s intention is to bring more efficiency and obtain better network requirements.
Synchronization for Thin Clients as well as for Mobile Devices
Another powerful and significant change is the so-called random “timing committees.” It is a support for clients such as nodes with less capacity.
Buterin explained that this synchronization allows thin clients to control and determine the chain’s head with a low amount of overhead (20 kB per day minimum to keep up, and 500 bytes to verify a single block).
The mechanism would work this way: every 27 hours, there is a selection of 1,024 validators to participate in the synchronization committee. This group would gain access to publish signatures that would witness the current head.
According to Buterin, this signature issuing would be part of the LightClientUpdate that will help thin clients find the head and gain inclusion in the Beacon Chain. The document does not specify this hard fork’s release date, but the implementation is on its way.
By: Jenson Nuñez
