Fork this! nl

Door Rannasha op dinsdag 24 april 2018 11:41 - Reacties (4)
Categorie: Cryptocurrency, Views: 4.149

Een wijziging aanbrengen in de regels die een cryptocurrency / blockchain definieren is niet eenvoudig. In een decentraal systeem kun je niet simpelweg op zondagavond een update pushen zodat vanaf maandag het allemaal anders gaat. Een belangrijk concept in de blockchain wereld is dan ook de "fork", of de splitsing van de blockchain in 2 incompatibele regelsets. Vaak wordt onderscheid gemaakt tussen een "softfork" en een "hardfork", waarbij dan gezegd wordt dat die eerste eenvoudig is met beperkte impact en die tweede ingewikkeld met verregaande gevolgen.

De zaken zijn, zoals meestal het geval is, wat genuanceerder dan dat.

In een ideale wereld zullen zowel softforks als hardforks nooit daadwerkelijk leiden tot een splitsing van de blockchain, omdat forks alleen worden uitgevoerd met 100% steun van de gebruikers en met meer dan voldoende voorbereidingstijd zodat iedereen op een degelijke manier kan upgraden voor de fork plaats vindt. Maar goed, de wereld is verre van ideaal.

Het onderscheid tussen soft- en hardfork is vanuit de formele definitie vrij duidelijk, maar als het gaat om de daadwerkelijke consequenties is er, in theorie, meer overlap mogelijk.

De definities. Een softfork is een wijziging in de regels van het protocol die deze regels stricter maakt. Dat wil zeggen: Iets dat eerst wel toegestaan was, is dat na de fork niet meer. Een hardfork is het omgekeerde, het verruimt de regels en laat dingen toe die daarvoor niet toegestaan waren.


Softfork, scenario 1
Het daadwerkelijke effect van een softfork hangt af van welke beperkingen er precise worden geintroduceerd. Een verlaging van de block-size naar 100 kB is een softfork, want de regels worden strenger. Miners die hun software niet updaten zullen alsnog proberen om grotere blocks te minen, die door de miners en nodes die wel geupdate hebben worden geweigerd. Zolang de miners die geupdate hebben in de meerderheid zijn (gemeten aan de hand van hashrate), zullen de niet-upgradende miners alsnog de chain van de upgradende miners volgen. Zo nu en dan produceren de niet-upgraders een tijdelijke aftakking als ze een of meer blocks van >100 kB minen, maar uiteindelijk zal de upgrader-tak de grootste hoeveelheid rekenwerk bevatten en dus worden overgenomen.

Als slechts een minderheid van de miners upgrade, dan ontstaat de situatie dat er 2 aparte takken zijn die ook blijven bestaan. De niet-upgradende meerderheid zal werken aan een chain met grote blocks, maar deze chain wordt pertinent geweigerd door de upgraders, die hun eigen tak hebben met kleine blocks. Omdat deze tak minder rekenwerk bevat dan de chain van de niet-upgraders en dit verschil met de tijd alleen maar toeneemt, zullen de niet-upgraders deze tak met kleine blocks simpelweg negeren. In dit scenario kan een softfork dus leiden tot een permanente splitsing van de blockchain.

Merk op dat ik het hier alleen heb over miners, maar niet over gewone gebruikers. In het hierboven geschetste scenario zullen niet-miner-clients die niet updaten simpelweg de langste tak volgen, omdat voor niet-updaters beide takken geldig zijn. Een wijziging als de verlaging van de block size heeft geen noemenswaardige impact op de gebruikers. Zij kunnen zelf kiezen of en wanneer ze de software updaten.


Softfork, scenario 2
Maar, dat is niet met iedere softfork per se het geval. Stel je hebt een, in mijn ogen zeer redelijke, softfork waarin wordt geeist dat iedere transactie een output bevat die aan mijn adres wordt toegekend met ten minste 10% van de totale waarde van de transactie. Dit is een softfork omdat het een extra restrictie is op de regels waaraan transacties moeten voldoen.

Voor miners geldt het zelfde verhaal als hierboven. Maar voor gewone gebruikers ligt het anders. Gebruikers die enkel transacties ontvangen hoeven nog steeds niets te doen, maar als een gebruiker transacties wil versturen, dan moet deze gebruiker z'n software updaten zodat de Rannasha-belasting op de juiste manier betaald wordt.

Er is hier dus sprake van een softfork, waarbij het toch noodzakelijk is dat alle gebruikers hun software updaten. Omdat dit geen wenselijk scenario is (de Rannasha-belasting wel, de verplichte update niet), is er tot nu toe voor gekozen om vooral scenario 1 softforks toe te passen. Softforks waarbij miners moeten updaten, maar waarbij gebruikers zelfs kunnen kiezen of en wanneer ze de update uitvoeren.

En om de overgang voor miners goed te laten verlopen, wordt er gebruik gemaakt van een signallerings-mechanisme waarmee kan worden aangegeven of men klaar is voor de softfork en bereid is deze te steunen. Is er onvoldoende steun, dan komt de fork er niet.


Hardforks
Een hardfork is, zoals al gezegd, het omgekeerde van een softfork. De regels worden verruimd. Een voorbeeld is het vergroten van de block size. Als een meerderheid van de miners een hardfork volgt, dan zal de blockchain zich splitsen. De minderheid die niet mee doet en de oorspronkelijke software blijft draaien, zal immers de tak met de verruimde regels weigeren ondanks dat deze langer is. Zo ontstaan er dus 2 parallele takken.

Als de minderheid van de miners de hardfork steunt, dan gebeurt er niets. De meerderheid die niet mee doet zal een langere tak produceren die ook door de minderheid als geldig wordt gezien. De minderheid zal deze tak dus ook volgen en blijven volgen, ondanks dat ze zo nu en dan een block produceren dat door de meerderheid als ongeldig wordt gezien.

De oplettende lezer springt nu op uit zijn of haar stoel en roept "Maar Bitcoin Cash en al die andere hardfork-coins hebben een minderheid van de miners, maar blijven alsnog als onafhankelijke takken bestaan. Sup with that?" Hier kom ik straks op terug, wees geduldig!

Hoe zit het met de gebruikers? Hier moet onderscheid gemaakt worden tussen gebruikers die een SPV client draaien en full node gebruikers. Uitgaand van het scenario dat de hardfork een meerderheid achter zich krijgt: Gebruikers die een full node draaien zullen moeten updaten. Doen ze dat niet, dan zullen ze de minderheids-tak gaan volgen. Maar het is goed mogelijk dat (vrijwel) alle miners de hardfork volgen. In dat geval zullen er geen nieuwe blocks meer worden gemined op de minderheids-tak en zullen gebruikers die niet upgraden dus geen gebruik meer kunnen maken van het netwerk.

SPV clients controleren de blockchain niet zelf, maar communiceren met een of meerdere full nodes om enkel de gegevens op te halen die voor de client relevant zijn. Een SPV client is dan ook fork-agnostisch. Zelfs als een hardfork wijzigingen aanbrengt op het gebied van transacties, dan zal een SPV client hier niet om geven, want deze kan gewoon de oude transactie-regels blijven toepassen voor het aanmaken van transacties.

In het geval van een blockchain-splitsing kan het gebruik van een SPV client dan ook gevaar opleveren, omdat het voor de gebruiker niet per se duidelijk is op welke tak de client actief is. Sommige ontwikkelaars van SPV clients hebben inmiddels functionaliteit toegevoegd die detecteert op welke tak de client werkt en/of die de gebruiker zelf laten kiezen.


Hardfork-altcoins
Zoals beloofd, verdere uitleg over hoe Bitcoin Cash en andere hardfork-altcoins ondanks een mining-minderheid toch een werkzame aftakking van de blockchain hebben gemaakt en in stand hebben gehouden.

In het geval van Bitcoin Cash komt dit door de "first must be large" ("de eerste moet groot zijn") regel die zegt dat het eerste block na het gekozen fork-moment verplicht groter moet zijn dan 1 MB. Dit block wordt door niet-forkers geweigerd, terwijl fork-miners de reguliere Bitcoin-tak weigeren omdat deze niet aan deze regel voldoet.

Maar de first must be large regel is eigenlijk een restrictie op de regels van het protocol. En dus een softfork. De Bitcoin Cash fork is dus niet enkel een hardfork, maar een combinatie van een hardfork en een softfork op hetzelfde moment. Dit zorgt ervoor dat het eenvoudiger wordt om te bepalen wat er gebeurt. Ongeacht de hoeveelheid mensen / miners die de fork steunen zal het zo zijn dat miners en gebruikers die de Bitcoin Cash software draaien de Bitcoin Cash tak volgen en zij die dat niet doen blijven op de Bitcoin tak. Gebruikers van SPV clients lopen nog steeds een risico, zolang de client niet expliciet aangeeft welke tak deze volgt (of de gebruiker laat kiezen).

Sommige fork-altcoins die volgden op Bitcoin Cash (bijvoorbeeld Bitcoin Gold) pasten nog weer een ander fork-mechanisme toe. Tot nu toe heb ik enkel gesproken over forks die de regels stricter maken (softforks) en forks die de regels ruimer maken (hardforks). Maar het is ook mogelijk om de regels simpelweg te veranderen, zonder dat deze stricter of ruimer worden.

Zo heeft Bitcoin Gold er voor gekozen om vanaf het fork-block een ander hashing-algoritme te gebruiken. Blocks voor het fork-block worden nog steeds gecontroleerd met het oorspronkelijke hashing-algoritme (SHA256), maar alle volgende blocks moeten met het nieuwe algoritme worden gechecked (en dus ook gemined).

In de praktijk is het effect van zo'n forktype hetzelfde als de hardfork/softfork combinatie van Bitcoin Cash: Gebruikers die overstappen zullen altijd op de fork-tak komen, gebruikers die dat niet doen blijven op de oorspronkelijke tak. SPV gebruikers moeten oppassen.

Ondanks dat de hierboven beschreven forks geen pure verruiming zijn van de regels, beschouwen velen de hierboven genoemde forks als hardforks, omdat deze forks backwards compatibility breken: Gebruikers die de software update niet installeren, kunnen niet deelnemen aan deze forks.


SegWit
Maar hoe zit het dan met SegWit? Deze update voegde een heel nieuw sort transactie toe en maakte het mogelijk om blocks groter dan 1 MB te minen. Dit klinkt heel erg als een hardfork, maar toch is SegWit met een softfork geintroduceerd. Hoe kan dat?

Het antwoord zit verstopt in de slimme manier waarop SegWit is geimplementeerd. Bitcoin heeft een script-taal met daarin een heel aantal functies en mogelijkheden om aan te geven onder welke voorwaarden een transactie-output besteed mag worden. De meest voorkomende voorwaarde is dat de bezitter van een specifiek adres de vervolg-transactie ondertekent. Maar het is ook mogelijk dat meerdere handtekeningen nodig zijn (multi-sig) of de extra voorwaarde dat de vervolg-transactie niet voor een bepaald moment mag worden verstuurd.

Een van de mogelijkheden is simpelweg om geen enkele voorwaarde aan een transactie-output te verbinden. De zogenaamde "any can spend" transactie. Een any-can-spend output kon door iedereen in een willekeurige transactie worden gebruikt. In de praktijk werd deze mogelijkheid nooit gebruikt, omdat er geen use-case voor is.

De SegWit softfork introduceert een hele set extra voorwaarden op het besteden van een any-can-spend output. En deze set extra voorwaarden zijn precies de voorwaarden waar een SegWit transactie aan moet voldoen, dus ze bevatten de gebruikelijke eisen over het hebben van de juiste digitale handtekening. Deze voorwaarden specificeren ook dat de handtekeningen van dergelijke transacties in een aparte datastructuur moeten worden bewaard. Deze datastructuur is een aanvulling op het gebruikelijke block.

Een client of miner die de SegWit update niet heeft uitgevoerd zal SegWit transacties nog steeds als geldig zien. Hij ziet ze immers als any-can-spend transacties en voor dergelijke transacties is alles toegestaan. De extra datastructuur met handtekeningen van SegWit transacties zal een dergelijke client gewoon negeren als irrelevante onzin-data. Een client die niet geupdate is zal dan ook perfect blijven functioneren. Deze client kan gewoon transacties blijven versturen en ontvangen en ook minen is geen probleem. Alleen het versturen van any-can-spend transacties kan problemen opleveren, omdat de meerderheid van het network nu allerlei voorwaarden koppelt aan deze transacties. Maar, voor de SegWit softfork waren any-can-spend transacties al "non-standard", wat wil zeggen dat ze wel toegestaan zijn, maar in de praktijk niet door nodes worden doorgegeven.

Clients die wel zijn geupdate zullen alle any-can-spend transacties controleren aan de hand van de nieuwe voorwaarden. De handtekeningen worden uit de extra datastructuur gehaald en gecontroleerd voordat een dergelijke transactie wordt geaccepteerd. Omdat de extra datastructuur met handtekeningen niet meetelt in de block size van 1 MB, is het dus mogelijk om een effectieve block size (het pure block + de extra datastructuur) te hebben van meer dan 1 MB, afhankelijk van de hoeveelheid SegWit transacties die er in het block zitten.


Conclusie
Het verschil tussen een softfork en een hardfork is minder zwart/wit dan het lijkt. Desalniettemin is de impact op de gebruikers wezenlijk anders. Het doel van een softfork is om zoveel mogelijk backwards compatibility te bieden, zodat iedereen op eigen initiatief kan updaten of de update zelfs kan weigeren. Niet alles kan worden ingevoerd met behulp van een softfork, waardoor een hardfork voor sommige wijzigingen noodzakelijk is. Maar met slim hergebruik van bestaande functies, zoals de any-can-spend transactie, is er behoorlijk veel mogelijk met een softfork.

In het algemeen is een softfork te verkiezen boven een hardfork, omdat de impact voor de gebruikers beter te beheersen is. En hoewel dat in het huidige stadium van acceptatie van cryptocurrency nog niet een groot probleem is, zal het in een hypothetische cryptocurrency-toekomst een groot voordeel zijn als cruciale financiele infrastructuur gebouwd op cryptocurrency-nodes niet regelmatig consensus-veranderende updates hoeft te krijgen.