Ethereum merge testnet A Kintsugi hiba miatt felosztva, íme, miért

Az összevonási esemény az Ethereum hálózaton a Proof-of-Stake konszenzusos modellre való áttérés a jelenleg alkalmazott Proof-of-Work modellről. Ez az egyesülés azt jelenti, hogy a jelenlegi Ethereum mainnet rendszer és az új Beacon lánc, amelyet gyakran Ethereum 2.0-nak neveznek, egy blokkláncba egyesül.

Az egyesítés tesztelésére decemberben a Kintsugi testnetet telepítették. A testnet célja különböző éles esetek futtatása és a rendszer viselkedésének megfigyelése. A Kintsugi tesztjeinek futtatásában részt vevő egyik fejlesztő az Marius van der Wijden, Az Ethereum magfejlesztője a Geth (Go-Ethereum) ügyfélcsapattal együttműködve.

„A tesztnet pár hétig hibátlanul futott. Múlt héten létrehoztam egy fuzzert, amely érvénytelen blokkokat küld. Egy blokk sok információt tartalmaz, például a tranzakciókat, az előző blokk hash-ét, a gázkorlátot stb.” – mondja Marius van der Wijden.

Egyes megvalósítások nem hajtották végre és nem ellenőrizték a blokkot

A fuzzer egy gyakori teszteszköz, amelyet a fejlesztők használnak arra, hogy véletlenszerű bemeneteket generáljanak függvényekhez vagy más kódrészletekhez, és megpróbálják ezeket valamilyen módon megszakítani. Ez a hibás és váratlan bemenetek generálásáról szól, és figyeli, mi történik a rendszerrel.

A van der Wijden által létrehozott fuzzer egy érvényes blokkot állít elő, és megváltoztatja annak egy elemét, hogy érvénytelenné tegye. Az egyik technika, amelyet használ, az, hogy egy elemet egy másikra cserél. Ebben az esetben a fuzzer megváltoztatta a blokkkivonatot a szülő hashre.

„A csomópontoknak el kell utasítaniuk az ilyen megváltozott blokkot. Mivel azonban a szülő hash magára egy érvényes blokkra mutatott, egyes megvalósítások valójában nem hajtották végre és nem ellenőrizték a blokkot, hanem a gyorsítótárban keresték meg. Mivel az előző blokk érvényes volt és a gyorsítótárban volt, feltételezték, hogy az új blokk is érvényes” – magyarázza van der Wijden.

A hálózat kétszer fel van osztva

Az eredmény az volt, hogy a hálózat fele, a Geth kliensek elutasították a blokkolást, míg a másik fele, a Nethermind- és Besu kliensek elfogadták, ami a lánc kettészakadását okozta, mivel két különböző nézetünk volt a helyes állapotról. A helyzetet rontotta, hogy a tetején egy másik probléma is felmerült.

Van der Wijden szerint a Geth-lánc csomópontjai, amelyek Lighthouse-Geth-ből, Prysm-Geth-ből, Lodestar-Geth-ből, Nimbus-Geth-ből és Teku-Geth-ből állnak, szintén kettészakadt közöttük.

„Ezt a felosztást még vizsgálják, de úgy tűnik, hogy a Teku-nak is lehet valamilyen gyorsítótárazási mechanizmusa, amely meghibásodott” – mondja van der Wijden.

Mivel az írás pillanatában a Kintsugi testnet több különböző forkja létezik, és minden csomópont azt hiszi, hogy a megfelelő elágazáson van, a hálózat már nem véglegesíthető.

„Kitalálunk valamit, hogy visszaállítsuk a hálózatot. Már frissítettük a Nethermind klienst, és ezek a csomópontok most a megfelelő láncon vannak. Még mindig szükségünk van a Teku javítására, mivel a csomópontok több mint 33 százaléka Teku, különben a lánc nem véglegesíthető” – mondja van der Wijden.

Az incidens jót hoz

Van der Wijden szerint ez az incidens nem tiltja vagy késlelteti az Ethereum egyesítés további tesztelését, és magát az egyesítést sem. Valójában van der Wijden azt állítja, hogy az incidens valójában olyan szélsőséges esetek tesztelésében segít, amelyeket nehéz lett volna tesztelni, ha a hálózat megfelelően működik.

„A hosszú, nem véglegesítési időszakok kihívást jelentenek a csomópontok számára, és nagyon fontos számunkra, hogy lássuk, hogyan viselkednek jelenleg. Úgy gondoljuk, hogy a testnet végül újra összeáll, de nem hiszem, hogy megpróbáljuk manuálisan megjavítani, mivel ez lehetőséget ad számunkra, hogy érdekes éles eseteket teszteljünk.”

„Nem hiszem, hogy ez késlelteti az összevonást, mivel az összevonás még nincs ütemezve. De ez mutatja, milyen fontos a tesztelés. Szerintem nagyon jól halad az összevonás. Még néhány hétre van szükségünk, hogy a szoftver elfogadható állapotba kerüljön, majd néhány hónapra van szükség a tesztelésre” – mondja van der Wijden.

Mi van, ha ez a mainneten történik?

Érdekes kérdés, hogy mi lett volna, ha egy ilyen hiba fordul elő a főláncon.

„Elég korán elkezdtük a tesztelést, ezért számítottunk néhány ehhez hasonló hibára. Egy ilyen hiba a mainnet-en azonban elég csúnya lenne, mivel meg kellene találnunk és kijavítanunk a hibát, amiben nagyon jók vagyunk, ki kell adnunk a kódot, majd tájékoztatnunk kell minden érintettet, hogy frissíteni kell a csomópontjait. Az utolsó rész a legnehezebb szerintem, mivel egyes felhasználók nem követik túl szorosan a fejlesztést” – mondja van der Wijden.

További részletekért Marius van der Wijden könyvét olvassa el az érdeklődő olvasó tweets az esetről.