Wat is een Hard Fork?

Wijzigingen in de regels van een blockchain kunnen gevolgen hebben voor gebruikers, ontwikkelaars, handelaren en beleggers. Een belangrijk begrip daarbij is een hard fork: een verandering van de consensusregels die niet compatibel is met de oude software.

Niet iedere blockchainupdate vereist een hard fork. Er bestaan ook soft forks en softwareverbeteringen die de consensusregels niet veranderen. Het onderscheid maakt duidelijk welke software nieuwe regels controleert en wanneer een netwerk kan splitsen.

Wat is een hard fork?

Een hard fork verandert de regels waarmee nodes bepalen of blokken en transacties geldig zijn.

Blokken die volgens de nieuwe regels geldig zijn, kunnen worden afgewezen door nodes die de oude regels volgen. Zo kunnen functies of protocollimieten veranderen. Doorslaggevend is de compatibiliteit van de consensusregels, niet alleen de omvang van de codewijziging.

Nodebeheerders die de keten met nieuwe regels willen controleren, moeten geschikte software gebruiken. Niet iedereen is technisch verplicht om mee te doen: sommige deelnemers kunnen de oude regels blijven volgen. Of de oude keten doorgaat, hangt af van de steun van deelnemers en het consensusmechanisme.

Ontwikkelaars of leden van de gemeenschap kunnen een hard fork voorstellen voor nieuwe functies, het oplossen van problemen of een andere ontwikkelrichting. Een voorstel verandert het netwerk niet vanzelf; deelnemers moeten software overnemen en de activering afstemmen.

Wat gebeurt er bij een hard fork?

Nieuwe regels worden meestal op een bepaalde blokhoogte of een bepaald tijdstip geactiveerd. Nodes zonder update kunnen blokken afwijzen die nieuwe nodes accepteren. Toch leidt een hard fork niet noodzakelijk tot twee blijvende netwerken of munten. Als deelnemers samen overstappen, kan de oude keten stoppen.

Als verschillende groepen onder onverenigbare regels blokken blijven maken, kan een blijvende splitsing ontstaan. Dat verschilt van een tijdelijke vertakking waarbij twee geldige blokken bijna tegelijk worden gevonden en het netwerk vervolgens weer één geschiedenis volgt.

Twee ketens die doorgaan, delen hun geschiedenis tot het splitsingspunt en ontwikkelen zich daarna afzonderlijk. De oude keten wordt niet automatisch irrelevant. Beide hebben steun nodig van gebruikers, ontwikkelaars, nodebeheerders en miners of validators.

Welke keten geldt als de oorspronkelijke?

Hard forks komen niet alleen voor bij Bitcoin of Ethereum. Naam en identiteit na een splitsing hangen af van het gebruik en de erkenning door de gemeenschap en de markt. Geen universele regel geeft de oorspronkelijke naam aan de keten met de nieuwste code.

Een regelupdate en de identiteit van een project zijn verschillende zaken. Na een afgestemde update kan een netwerk dezelfde naam houden. Deelnemers die het oneens zijn, kunnen een andere keten onder een andere naam voortzetten. Dat betekent niet dat elke Bitcoinupdate een hard fork is.

Bitcoin Cash en Bitcoin Gold zijn voorbeelden van projecten die uit vertakkingen rond Bitcoin ontstonden. Bitcoin SV kwam later voort uit een splitsing van Bitcoin Cash. Dit zijn afzonderlijke netwerken, niet alleen versienamen van dezelfde Bitcoinsoftware.

Waarom een hard fork voorstellen?

Redenen kunnen nieuwe functies, andere consensusparameters of het herstellen van kwetsbaarheden zijn. Steun van een meerderheid kan de afstemming helpen, maar vormt geen centraal besluit dat alle nodes dwingt te veranderen. Deelnemers kiezen welke regels zij uitvoeren.

Een grote keten of veel nodes betekent geen automatische bescherming tegen aanvallen. Fouten in smart contracts, software en consensus vormen verschillende problemen. In bijzondere omstandigheden kan een gemeenschap een wijziging van de netwerktoestand steunen, maar dat is niet hetzelfde als vrijelijk de transactiegeschiedenis wissen.

Een regelwijziging moet ook worden onderscheiden van een overstap naar een ander platform, zoals besproken in het gerelateerde artikel over Polymath en Ethereum. Een voorbeeld van een toestandswijziging via een hard fork was de reactie van Ethereum op de DAO-aanval in 2016.

Op 20 juli 2016 werd de DAO-fork geactiveerd bij blok 1.920.000. Het verslag van de Ethereum Foundation beschrijft hoe geld uit de betrokken DAO-contracten naar een herstelcontract werd verplaatst. Veel steun betekende geen volledige overeenstemming: sommige deelnemers wezen de wijziging af en zetten de keten zonder fork voort als Ethereum Classic.

De fork wiste de aanvalstransacties niet uit de geschiedenis. De toestandswijziging verplaatste geld naar een nieuw contract waarmee DAO-tokenhouders volgens hun rechten konden opnemen. Het herstel verliep via dat contract, niet als een automatische gelijktijdige betaling aan iedereen.

Verschillen tussen hard forks en soft forks

Beide kunnen consensusregels veranderen, maar de compatibiliteit verschilt. Een soft fork scherpt regels aan: blokken die aan de nieuwe regels voldoen, worden ook door oude nodes geaccepteerd. Die oude nodes controleren alleen niet alle nieuwe beperkingen.

Bij een hard fork kunnen oude nodes blokken afwijzen die volgens de nieuwe regels geldig zijn. Als beide groepen hun regels blijven volgen, kunnen twee ketens overleven. Een soft fork is gericht op één compatibele keten, maar fouten in afstemming of uitvoering kunnen alsnog problemen en splitsingen veroorzaken.

Beheerders die alle nieuwe regels willen controleren, moeten hun software bijwerken. Bij een soft fork kunnen oude nodes nieuwe blokken volgen zonder alle aanvullende beperkingen te begrijpen. Bij een hard fork kunnen zij die blokken afwijzen. De twee methoden veroorzaken dus niet noodzakelijk dezelfde splitsing.

Een hard fork is niet van zichzelf veiliger dan een soft fork. Veiligheid hangt af van ontwerp, uitvoering, tests, afgestemde activering en netwerksteun. Soft forks zijn ook geen verouderde techniek: Bitcoins Taproot was een soft fork die in 2021 werd geactiveerd. Een hard fork vereist niet automatisch veel meer rekenkracht; het middelengebruik hangt af van de concrete protocolwijziging.

Conclusie

Hard forks maken consensuswijzigingen mogelijk die niet compatibel zijn met oude nodes. Ze kunnen onderdeel zijn van een ontwikkelplan of reageren op dringende problemen, maar niet iedere nieuwe functie vereist deze methode.

De uitkomst hangt af van de inhoud van de wijziging en de steun van deelnemers. Een afgestemde update kan één netwerk behouden, terwijl onenigheid afzonderlijke ketens kan opleveren. Voor gebruikers is het belangrijk de gekozen regels, software en het netwerk te begrijpen.