Gisteren was de aandacht niet alleen gericht op de dalende prijs van Ether, maar ook op de Beacon Chain, waar een zogenaamde 'block reorganisatie' van maar liefst zeven blokken diep plaatsvond. Zulke reorganisaties komen bij Proof-of-work chains nog wel eens voor maar de bedoeling was dat ze verleden tijd zouden zijn bij Ethereums Proof-of-stake. Moeten we ons zorgen maken?

Ethereums Beacon Chain is de afgesplitste chain waarop Proof-of-stake grondig wordt uitgetest. Na de merge van (hopelijk) komend najaar draait Ethereum dan echt op wat nu nog een proof-of-stake testnet is. Er is dus nu nog tijd om kwetsbaarheden op te sporen. De block reorg was zo'n moment dat developers elkaar DM'den: wat is hier aan de hand? Kan dit kwaad? Het lijkt erop van niet.

Reorganisaties zijn normaal

Bij het aaneenrijgen van transactieblokken is het normaal dat er soms korte tijd een fork ontstaat. Hoe komt dat? Bij Proof-of-work chains zoals Bitcoin is het omdat twee miners op vrijwel hetzelfde moment hun 'puzzel' afgemaakt hebben en een blok mogen minen. Ze versturen dit blok naar de nodes. Als dit vrijwel gelijktijdig gebeurt, zullen sommige nodes eerder het ene blok goedkeuren, en andere nodes het andere. Er is dan een fork (splitsing) ontstaan. Die wordt meestal bij het volgende blok weer opgelost, waarna de winnende chain als enige overblijft. De kans is namelijk heel klein dat het vrijwel gelijktijdig minen wéér gebeurt - laat staan dat het drie of vier keer achter elkaar gebeurt. (Deze mogelijkheid van forken is wel de reden dat veel cryptobeurzen en wallets wachten op een aantal confirmaties. Pas als een transactie vier, vijf, zes blokken diep zit weggestopt, is de kans nihil dat hij nog teruggedraaid kan worden.)

Verschillende versies van de software in omloop

Hoe kon het gebeuren dat Ethereums Beacon Chain maar liefst zeven blokken lang dit conflict had (overigens is de bloktijd van Ethereum maar ongeveer 12 seconden)? Het heeft te maken met de verschillende Ethereum clients (versies van de Ethereum software) die in omloop waren. Sommige nodes draaiden clients waarop een protocolwijziging al was doorgevoerd - andere hadden die update nog niet doorgevoerd.

De update in kwestie had te maken met een zogenaamde boostfunctie. Deze zorgt ervoor dat snel gemaakte blokken extra snel verspreid worden - juist om te voorkomen dat er conflicterende versies van de chain rondgaan. Omdat niet elke client deze boost-functie geïmplementeerd had, hadden verschillende nodes een verschillend idee van wat het goede blok was om de rest van de chain op te baseren.

Dit is wat er gebeurd lijkt te zijn. De precieze toedracht volgt ongetwijfeld later nog. Zoals gezegd, het voorkomen van tijdelijke forks en de daaropvolgende reorganisaties is op zich geen probleem. En ongetwijfeld zullen alle clients deze boostfunctie gaan implementeren, waarna dit type blok-reorganisatie niet meer zal voorkomen.

Conclusie: overgang naar proof-of-stake heeft risico's

De block reorg had niets te maken met een aanval op het systeem, double spend-poging en zelfs niet met een bug. Er was niets ernstigs aan de hand dus. Maar het feit dat dit type gebeurtenis niet voorzien was door Ethereum-ontwikkelaars, zegt iets over de complexiteit van de overgang naar proof-of-stake. Het is een manier van valideren die veel en veel complexer is dan proof-of-work. De komende maanden en jaren - ook nog na de merge - moet blijken welke verrassingen er nog opduiken.

Dank aan Satoshi Radio voor de goede uitleg van deze block reorg.