Ethereum merge testnet Kintsugi gesplitst door bug, dit is waarom

De merge-gebeurtenis op het Ethereum-netwerk is de overgang naar het Proof-of-Stake-consensusmodel van het momenteel gebruikte Proof-of-Work-model. Deze fusie betekent dat het huidige Ethereum-mainnetsysteem en de nieuwe Beacon-keten, vaak aangeduid als Ethereum 2.0, zullen samensmelten tot één blockchain.

Om de samenvoeging te testen, werd in december het Kintsugi-testnet uitgerold. Het doel van het testnet is om verschillende randgevallen uit te voeren en te observeren hoe het systeem zich gedraagt. Een van de ontwikkelaars die betrokken is bij het uitvoeren van tests op Kintsugi is Marius van der Wijden, Ethereum-kernontwikkelaar die werkt met het Geth (Go-Ethereum) klantteam.

“Het testnet heeft een paar weken vlekkeloos gedraaid. Vorige week heb ik een fuzzer gemaakt die ongeldige blokken zou verzenden. Een blok bevat veel informatie, zoals de transacties, de hash van het vorige blok, de gaslimiet, et cetera”, zegt Marius van der Wijden.

Sommige implementaties hebben het blok niet uitgevoerd en geverifieerd

Een fuzzer is een veelgebruikt type testtool dat door ontwikkelaars wordt gebruikt om willekeurige invoer naar functies of andere stukjes code te genereren en ze op de een of andere manier te laten breken. Het gaat over het genereren van misvormde en onverwachte invoer en kijken wat er met het systeem gebeurt.

De fuzzer gemaakt door van der Wijden produceert een geldig blok en verandert één element ervan om het ongeldig te maken. Een techniek die het gebruikt, is om het ene element in het andere te veranderen. In dit geval heeft de fuzzer de blockhash gewijzigd in de bovenliggende hash.

“Nodes zouden zo’n gewijzigd blok moeten afwijzen. Omdat de bovenliggende hash echter zelf naar een geldig blok wees, hebben sommige implementaties het blok niet daadwerkelijk uitgevoerd en geverifieerd, maar in plaats daarvan opgezocht in een cache. Omdat het vorige blok geldig was en in de cache zat, gingen ze ervan uit dat het nieuwe blok ook geldig was', legt Van der Wijden uit.

Netwerk twee keer gesplitst

Het resultaat was dat de helft van het netwerk, de Geth-clients, het blok verwierp, terwijl de andere helft, de Nethermind- en Besu-clients, het accepteerde, waardoor de keten splitste omdat we nu twee verschillende weergaven van de juiste status hadden. Om het nog erger te maken, was er nog een ander probleem bovenop.

Volgens Van der Wijden splitsen de Geth-ketenknooppunten op hun beurt, die bestaat uit Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth en Teku-Geth, zich daartussen ook op.

"Deze splitsing wordt nog steeds onderzocht, maar het lijkt erop dat Teku mogelijk ook een caching-mechanisme heeft dat is mislukt", zegt Van der Wijden.

Aangezien er op het moment van schrijven verschillende forks van het Kintsugi-testnet bestaan, en elk knooppunt denkt dat ze op een correcte fork zitten, is het netwerk niet meer aan het finaliseren.

'We zullen iets bedenken om het netwerk weer bij elkaar te krijgen. We hebben de Nethermind-client al bijgewerkt en die knooppunten staan ​​nu in de juiste keten. We hebben nog steeds de fix voor Teku nodig, aangezien meer dan 33 procent van de nodes Teku is, anders wordt de keten niet voltooid”, zegt Van der Wijden.

Incident brengt wat goeds

Volgens Van der Wijden verbiedt of vertraagt ​​dit incident het verdere testen van de Ethereum-fusie niet, noch vertraagt ​​het de fusie zelf. Van der Wijden zegt dat het incident zelfs helpt om edge-cases te testen die moeilijk te testen zouden zijn als het netwerk goed zou werken.

“Lange perioden van niet-voltooiing zijn een uitdaging voor de knooppunten en het is erg belangrijk voor ons om te zien hoe ze zich nu gedragen. We denken dat het testnet uiteindelijk weer bij elkaar zal komen, maar ik denk niet dat we zullen proberen het handmatig te repareren, omdat het ons de mogelijkheid geeft om interessante randgevallen te testen.”

“Ik denk niet dat dit de fusie zal vertragen, aangezien de fusie nog niet gepland is. Maar het laat zien hoe belangrijk testen is. Ik vind dat de fusie heel goed vordert. We hebben nog een paar weken nodig om de software in een acceptabele staat te krijgen en dan hebben we nog een paar maanden nodig om het te testen”, zegt Van der Wijden.

Wat als dit gebeurt op het mainnet?

Een interessante vraag is wat er zou zijn gebeurd als een dergelijke bug op de mainchain was opgetreden.

“We zijn vrij vroeg begonnen met testen, dus we verwachtten een paar van dit soort bugs. Zo'n bug op het mainnet zou echter behoorlijk vervelend zijn, omdat we de bug, waar we best goed in zijn, moeten vinden en repareren, de code vrijgeven en dan alle stakers laten weten dat ze hun nodes moeten bijwerken. Het laatste deel vind ik het moeilijkste, omdat sommige gebruikers de ontwikkeling niet al te nauw volgen”, zegt van der Wijden.

Voor meer details wordt de geïnteresseerde lezer aangemoedigd om Marius van der Wijden's te lezen tweets over het incident.