Ethereum fusjonere testnett Kintsugi delt etter feil, her er grunnen

Sammenslåingshendelsen på Ethereum-nettverket er overgangen til Proof-of-Stake-konsensusmodellen fra den for tiden brukte Proof-of-Work-modellen. Denne sammenslåingen betyr at dagens Ethereum mainnet-system og den nye Beacon-kjeden, ofte referert til som Ethereum 2.0, vil slå seg sammen til én blokkjede.

For å teste sammenslåingen ble Kintsugi-testnettverket distribuert i desember. Formålet med testnettet er å kjøre ulike edge-cases og observere hvordan systemet oppfører seg. En av utviklerne som er involvert i å kjøre tester på Kintsugi er Marius van der Wijden, Ethereum kjerneutvikler som jobber med Geth (Go-Ethereum) klientteam.

"Testnettet kjørte feilfritt i et par uker. Forrige uke opprettet jeg en fuzzer som ville sende ugyldige blokker. En blokk inneholder mye informasjon, som transaksjonene, hashen til den forrige blokken, gassgrensen, et cetera, sier Marius van der Wijden.

Noen implementeringer ble ikke utført og bekreftet blokkeringen

En fuzzer er en vanlig type testverktøy som brukes blant utviklere for å generere tilfeldige innganger til funksjoner eller andre kodebiter, og prøve å få dem til å gå i stykker på en eller annen måte. Det handler om å generere misdannede og uventede innganger og se hva som skjer med systemet.

Fuzzeren opprettet av van der Wijden produserer en gyldig blokk og endrer ett element i den for å gjøre den ugyldig. En teknikk som den bruker er å endre et element til et annet. I dette tilfellet endret fuzzer blockhash til overordnet hash.

"Noder bør avvise en slik endret blokk. Men siden den overordnede hashen pekte på en gyldig blokk i seg selv, ble ikke noen implementeringer utført og bekreftet blokken, men så den opp i en hurtigbuffer i stedet. Siden den forrige blokken var gyldig og i cachen, antok de at den nye blokken også var gyldig, forklarer van der Wijden.

Nettverk delt to ganger

Resultatet var at halve nettverket, Geth-klientene, avviste blokkeringen, mens den andre halvparten, Nethermind- og Besu-klientene, godtok den, noe som førte til at kjeden delte seg siden vi nå hadde to forskjellige syn på riktig tilstand. For å gjøre ting verre, var det et annet problem på toppen.

I følge van der Wijden er Geth-kjedenodene på sin side, som består av Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth og Teku-Geth, også delt inn mellom dem.

"Denne splittelsen blir fortsatt undersøkt, men det ser ut til at Teku også kan ha en buffermekanisme som mislyktes," sier van der Wijden.

Siden det finnes flere forskjellige gafler i Kintsugi-testnettet i skrivende stund, og hver node tror at de er på riktig gaffel, slutter ikke nettverket lenger.

«Vi skal finne på noe for å få nettverket sammen igjen. Vi har oppdatert Nethermind-klienten allerede, og disse nodene er på riktig kjede nå. Vi trenger fortsatt reparasjonen til Teku, siden mer enn 33 prosent av nodene er Teku, ellers vil ikke kjeden sluttføres, sier van der Wijden.

Hendelsen gir noe godt

I følge van der Wijden forbyr eller forsinker ikke denne hendelsen ytterligere testing av Ethereum-fusjonen, og den forsinker heller ikke selve fusjonen. Faktisk sier van der Wijden at hendelsen faktisk hjelper til med å teste kantsaker som ville vært vanskelige å teste hvis nettverket fungerte som det skal.

"Lange perioder med ikke-avslutning er utfordrende for nodene, og det er veldig viktig for oss å se hvordan de oppfører seg akkurat nå. Vi tror at testnettet etter hvert vil komme sammen igjen, men jeg tror ikke vi vil prøve å fikse det manuelt, da det gir oss muligheten til å teste interessante kantsaker.»

«Jeg tror ikke at dette vil forsinke sammenslåingen, siden sammenslåingen ikke er planlagt ennå. Men det viser hvor viktig testing er. Jeg synes sammenslåingen går veldig bra. Vi trenger et par uker til for å få programvaren i en akseptabel tilstand, og så trenger vi et par måneder for å teste den, sier van der Wijden.

Hva om dette skjer på hovednettet?

Et interessant spørsmål er hva som ville skjedd hvis en feil som dette hadde oppstått på hovedkjeden.

"Vi har begynt å teste ganske tidlig, så vi forventet et par slike feil. En slik feil på hovednettet ville imidlertid vært ganske ekkel, siden vi må finne og fikse feilen, som vi er ganske gode på, frigi koden og så la alle deltakere få vite at de bør oppdatere nodene sine. Den siste delen er den vanskelige delen etter min mening, siden noen brukere ikke følger utviklingen for nøye, sier van der Wijden.

For flere detaljer oppfordres den interesserte leser til å lese Marius van der Wijdens tweets på hendelsen.