Het belang van achterwaartse compatibiliteit

Eerder schreven we kort over het verschil tussen een hard fork en een soft fork en het belang van het voorkomen van een hard fork. Dit alles staat in het teken van het behouden van de achterwaartse compatibiliteit.

Niet zomaar buitengesloten

Wanneer iemand er voor kiest mee te doen met bitcoin, dan gaat men akkoord met de regels van het protocol. Deze regels kunnen vervolgens niet zomaar gebroken worden, want dit zou betekenen dat een deel van de gebruikers ineens niet meer mee kunnen doen of ineens deel uitmaken van een systeem van afspraken waar zij het niet mee eens zijn.

Het 'upgraden' van bitcoin is daarom lastig: sommige nieuwe features die men graag toegevoegd ziet kunnen gevolgen hebben voor de regels die in het verleden zijn afgesproken. Zo komt het bij een gedwongen upgrade, een hard fork, voor dat iemand die ervoor kiest een nieuwe feature niet te gebruiken niet meer mee kan doen in het systeem. Bij een systeem als bitcoin moet dit voorkomen worden, omdat het schade toericht aan de betrouwbaarheid en stabiliteit van bitcoin.

Als opfrisser, even snel het verschil tussen een hard fork en een soft fork. Bij een upgrade via hard fork worden de bestaande regels uitgebreid, de nieuwe regels vallen dus niet binnen de huidige afspraken. Dit zorgt voor een breuk in de achterwaartse compatibiliteit. Bij een upgrade via soft fork word er binnen de bestaande regels geopereerd. Hiermee wordt de achterwaartse compatibiliteit behouden.

Een andere manier van ontwikkelen

Er wordt daarom in de ontwikkeling van bitcoin veel moeite gedaan om nieuwe toevoegingen zoveel mogelijk zodanig te implementeren dat een upgrade optioneel is; via een soft fork. Door de upgrade optioneel te maken wordt er niemand buitengesloten. Er kan niet verwacht worden dat men de nieuwste versie van 'de regels' download voordat zij verder gaan. Tevens kan er niet verwacht worden dat iedereen het zomaar eens is met nieuwe regels. Een bitcoin is een bitcoin, en de definitie daarvan moet vandaag hetzelfde zijn als over 100 jaar. Door het toepassen van een conservatief beleid is het vandaag mogelijk om je wallet of node van vijf jaar geleden te openen en een transactie uit te voeren. Deze wordt zonder problemen geaccepteerd door het bitcoinnetwerk.

Zij die gebruik willen maken van de nieuwe feature kunnen dat en zij die dit niet willen kunnen gewoon doorgaan met het doen van betalingen zoals zij dit altijd hebben gedaan. Een voorbeeld van een dergelijke vrijwillige upgrade is de segregated witness soft fork, waar tot op heden ongeveer 40% van de transacties gebruik van maakt. De andere 60% heeft geen hinder ondervonden. Wanneer segregated witness doorgevoerd was als hard fork, dan zouden er dus twee verschillende blockchains ontstaan zijn met elk hun eigen regels. Het doorvoeren van upgrades middels een hard fork zorgt dus voor een reeks eindeloze splitsingen van het netwerk.

Veiligheid, decentraliteit en weerbaarheid voorop

Wanneer er gedebatteerd wordt of een verandering wel of niet doorgevoerd moet worden gaat dit debat vaak niet eens geheel over de verandering zelf, maar over het behouden van achterwaartse compatibiliteit. Als het toevoegen van een bepaalde feature ten koste gaat van de achterwaartse compatibiliteit, dan wordt er gekozen voor het behouden van de achterwaartse compatibiliteit.

Wanneer dit niet gedaan wordt kunnen oude versies van de software zich niet meer verenigen met het huidige netwerk en worden de regels die nieuwe software aanhoudt als ongeldig gezien door de oude software. Een systeem waarbij dat mogelijk is, is geen stabiel platform om een wereldwijd betaalmiddel op te draaien. Alleen wanneer het écht noodzakelijk is dat een verandering door wordt gevoerd wordt een hard fork overwogen. Bijvoorbeeld als blijkt dat de huidige cryptografie niet meer veilig is en deze vervangen moet worden.

Daarnaast zou de mogelijkheid tot het doorvoeren van een verandering die de achterwaartse compatibiliteit breekt gevoelig zijn voor allerlei invloeden van verschillende partijen met verschillende belangen: het maakt bitcoin kwetsbaar. Wie bepaalt welke verandering gedwongen doorgevoerd wordt? In een decentraal systeem als bitcoin is hier geen autoriteit voor. Alleen het netwerk als geheel kan een verandering doorvoeren.

Het voeren van een beleid waarbij de achterwaartse compatibiliteit koste wat kost behouden wordt komt wellicht over als een rigide beleid voor een softwareproject, maar het dient als manier om het project te coördineren zonder dat het project kwetsbaar wordt voor overname door een enkele partij. Hiermee wordt de continuïteit van bitcoin gegarandeerd.