Ethereum merge testnet Kintsugi delat efter bugg, här är varför

Sammanslagningshändelsen på Ethereum-nätverket är övergången till Proof-of-Stake-konsensusmodellen från den för närvarande använda Proof-of-Work-modellen. Denna sammanslagning innebär att det nuvarande Ethereums mainnet-system och den nya Beacon-kedjan, ofta kallad Ethereum 2.0, kommer att slås samman till en blockkedja.

För att testa sammanslagningen distribuerades Kintsugi-testnätet i december. Syftet med testnätet är att köra olika kantfall och observera hur systemet beter sig. En av utvecklarna som är involverade i att köra tester på Kintsugi är Marius van der Wijden, Ethereums kärnutvecklare som arbetar med Geth (Go-Ethereum) kundteam.

"Testnätet fungerade felfritt i ett par veckor. Förra veckan skapade jag en fuzzer som skulle skicka ogiltiga block. Ett block innehåller mycket information, som transaktionerna, hashen från det föregående blocket, gasgränsen, et cetera, säger Marius van der Wijden.

Vissa implementeringar exekverade och verifierade inte blockeringen

En fuzzer är en vanlig typ av testverktyg som används bland utvecklare för att generera slumpmässiga indata till funktioner eller andra delar av kod, och försöka få dem att gå sönder på ett eller annat sätt. Det handlar om att generera felaktiga och oväntade indata och se vad som händer med systemet.

Fuzzer skapad av van der Wijden producerar ett giltigt block och ändrar ett element i det för att göra det ogiltigt. En teknik som den använder är att ändra ett element till ett annat. I det här fallet ändrade fuzzer blockhash till överordnad hash.

"Noder bör avvisa ett sådant ändrat block. Men eftersom den överordnade hashen pekade på ett giltigt block i sig, exekverade och verifierade vissa implementeringar inte blocket utan slog upp det i en cache istället. Eftersom det tidigare blocket var giltigt och i cachen, antog de att det nya blocket också var giltigt, förklarar van der Wijden.

Nätverket delas två gånger

Resultatet var att halva nätverket, Geth-klienterna, avvisade blocket, medan den andra hälften, Nethermind- och Besu-klienterna, accepterade det, vilket gjorde att kedjan splittrades eftersom vi nu hade två olika syn på rätt tillstånd. För att göra saken värre fanns det en annan fråga på toppen.

Enligt van der Wijden delas Geth-kedjenoderna i sin tur, som består av Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth och Teku-Geth, också mellan sig.

"Denna splittring undersöks fortfarande, men det ser ut som att Teku också kan ha någon cachningsmekanism som misslyckades", säger van der Wijden.

Eftersom flera olika gafflar av Kintsugi-testnätet finns i skrivande stund, och varje nod tror att de är på rätt gaffel, slutförs inte nätverket längre.

"Vi kommer att hitta på något för att få ihop nätverket igen. Vi har redan uppdaterat Nethermind-klienten och de noderna är i rätt kedja nu. Vi behöver fortfarande fixa Teku, eftersom mer än 33 procent av noderna är Teku, annars kommer kedjan inte att slutföras”, säger van der Wijden.

Incidenten ger något gott

Enligt van der Wijden förbjuder eller fördröjer denna incident inte ytterligare testning av Ethereum-sammanslagningen, och den försenar inte heller själva sammanslagningen. Faktum är att van der Wijden säger att incidenten faktiskt hjälper till att testa kantfall som skulle ha varit svåra att testa om nätverket fungerade korrekt.

”Långa perioder av icke-avslutande är utmanande för noderna och det är väldigt viktigt för oss att se hur de beter sig just nu. Vi tror att testnätet så småningom kommer att samlas igen, men jag tror inte att vi kommer att försöka fixa det manuellt, eftersom det ger oss möjlighet att testa intressanta kantfall.”

"Jag tror inte att detta kommer att försena sammanslagningen, eftersom sammanslagningen inte är planerad ännu. Men det visar hur viktigt det är att testa. Jag tycker att sammanslagningen går riktigt bra. Vi behöver ett par veckor till för att få programvaran i ett acceptabelt tillstånd och sedan behöver vi ett par månader för att testa det, säger van der Wijden.

Vad händer om detta händer på mainnet?

En intressant fråga är vad som skulle ha hänt om en bugg som denna hade inträffat på huvudkedjan.

"Vi har börjat testa ganska tidigt, så vi förväntade oss ett par sådana här buggar. En sådan bugg på mainnet skulle dock vara ganska otäck, eftersom vi skulle behöva hitta och fixa buggen, vilket vi är ganska bra på, släppa koden och sedan låta alla aktörer veta att de borde uppdatera sina noder. Den sista delen är den svåra delen enligt mig, eftersom vissa användare inte följer utvecklingen för noggrant”, säger van der Wijden.

För mer information uppmanas den intresserade läsaren att läsa Marius van der Wijdens tweets om händelsen.