Friss: február végén várható az Ethereum hard fork

Az Ethereum vezető fejlesztői február végére időzítik a Constantinople hard forkot, amit a héten fújtak le egy utolsó pillanatban felfedezett bug miatt.

A hálózatfrissítés február 27-én esedékes a 7 280 000. blokknál.

A Constantinople hard fork 2.0 időpontjáról egy mai konferenciahívás során egyeztek meg az ETH vezető fejlesztők. A hívásban többek között részt vett Vitalik Buterin, Hudson Jameson, Lane Rettig, Afri Schoedon, Szilágyi Péter, Martin Holste Swende, Danny Ryan és Alexey Akhunov is.

A döntés közvetlenül a feltárt bug után született, melynek hatására el kellett halasztani a január 16-ára időzített frissítést. A hibát a ChainSecurity okos szerződés audit cég jelentette kedden, az utolsó pillanatban, amit az egyik ethereum fejlesztési javaslat (EIP) kódjában találtak.

A sebezhetőség miatt a Constantinople aktiválási ideje jövő hó 27-én lesz, ha minden jól megy. A bugos 1283-as EIP-et addig a fejlesztők áttervezik és újratesztelik úgy, hogy a Constantinople-t két szimultán művelet során aktiválják. Az elsőben bevezetik az 5 eddig elfogadott EIP frissítést, majd a következőben törlik a bugos 1283-ast.

A stratégiára – amit Szilágyi Péter javasolt – azért van szükség, mert így szeretnék biztosítani a teszthálózatok és magánhálózatok zavartalan működését, amik már frissítettek a Constantinople verzióra, anélkül, hogy vissza kellene állítani a blokkokat egy korábbi időpontra.

“Azt javaslom, hogy legyen két hard fork, a Constantinople a jelenlegi formájában és a Constantinople fix, amivel kikapcsolják ezt a funkciót… A két fork segítségével bárki aki frissített, a második forkkal úgy mondva visszaminősítheti a forkját,” magyarázta Szilágyi.

A bugos EIP 1283 javaslatot az említett ChainSecurity audit cég fedezte fel nem sokkal a Constantinople előtt és a blokklánc tárolási költségekért volt felelős.

Matthias Egli, a ChainSecurity műveleti igazgatója szerint a hiba felett nagy valószínűséggel elsiklottak a vezető fejlesztők mikor tesztelték a szoftvert pontosan azért, mert a hatása csak az okos szerződés fejlesztésekor jelentkezett volna és nem magán az ethereum virtuális gép fejlesztésekor.

A gyors döntésre a Constantinople átütemezéséről szükség volt, mert már ketyeg az ethereum nehézségi bombája, ami egy extra kód a blokkláncon és az idő előrehaladtával fokozatosan emeli a blokkidőt.

A blokkidő emelése a konszenzus algoritmus graduális áttérését jelenti proof-of-work-ről (PoW) proof-of-stake-re (PoS), de a jelenlegi állapotában még bőven tesztfázisban lévő Ethereum PoS koncepció miatt kénytelenek a nehézségi bombát 12 hónappal kitolni, így hagyva több időt a fejlesztésre és tesztelésre. Pontosan ennek a nehézségi bombának a kitolásáért felel a Constantinople hard fork EIP 1234-es késleltetője és pontosan ezért van szükség a Constantinople minél előbbi bevezetésére.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé.