Op 16 februari werden de trusted keys van Wladimir van der Laan verwijderd van de github van bitcoin. Een grotere gebeurtenis dan je in eerste instantie zou denken. Wladimir was namelijk sinds 2014 de lead maintainer van bitcoin core. Niet geheel toevallig verscheen er deze week een artikel in de Wall Street Journal waar de schrijver in de wereld duikt van deze ‘mysterieuze programmeurs’. Zijn ze de bazen of juist de conciërges van bitcoin?
“Bitcoin's future depends on a handful of mysterious coders”, kopte de Wall Street Journal deze week. Met deze mysterieuze programmeurs bedoelen ze de groep van (nu Wladimir van der Laan en Marco Falke gestopt zijn) vier maintainers van bitcoin core, de software die op elke bitcoinnode draait. Volgens de WSJ heeft deze groep de macht in handen om de broncode van bitcoin te veranderen. Dat hebben ze ook regelmatig gedaan, om zeer ernstige bugs te verhelpen. Maar kunnen ze dan zomaar wijzigingen doorvoeren? Hoe zit dat precies?
Laten we beginnen met de meest voor de hand liggende vraag: wat is de rol van een maintainer? Op de website van bitcoin core vinden we de volgende beschrijving:
Project maintainers have commit access and are responsible for merging patches from contributors. They perform a janitorial role merging patches that the team agrees should be merged. They also act as a final check to ensure that patches are safe and in line with the project goals. The maintainers’ role is by agreement of project contributors.
Maintainers verschillen van normale contributors omdat ze voorgestelde wijzigingen daadwerkelijk in de broncode kunnen doorvoeren. Een fout die soms gemaakt wordt is dat alleen maintainers verantwoordelijk zouden zijn voor het beoordelen van wijzigingsvoorstellen. Hoewel dat inderdaad in hun rol valt, zijn daar veel meer mensen bij betrokken. Je zou de rol van een maintainer kunnen samenvatten als beoordelen of er voldoende review heeft plaatsgevonden op de wijzigingen om daarna de wijzigingen door te voeren in de broncode. Sjors Provoost vertelt er meer over in aflevering 63 van Bitcoin, Explained.
"What sets maintainers apart from other developers is their ability to approve those changes and move them into the GitHub repository."
— Sjors Provoost @sjors@sprovoost.nl (@provoost) February 17, 2023
Only the second part. All reviewers get to approve things. Though maintainers do often play a double role of also being a reviewer.
Het beoordelen en doorvoeren van wijzigingsvoorstellen is echter maar een klein deel van het werk van een maintainer. Het gros van het werk is minder glamoureus, aldus Gloria Zhao. Ze is sinds 2022 maintainer en geeft aan dat een flink deel van het werk bestaat uit het in de gaten houden van github en het opsporen van bugs.
Even samenvatten. Er zijn verschillende manieren om bij te dragen aan de bitcoinsoftware. Je kunt wijzigingen aandragen, bugs opsporen, wijzigingen van andere mensen reviewen, documentatie en tests schrijven of vertalingen doen. Doe je dit, dan ben je een contributor. Sommige contributors zijn langere tijd actief betrokken en groeien uiteindelijk uit tot maintainer. Een maintainer kan nog steeds wijzigingen aan de software aandragen, een review doen of bugs opsporen, maar heeft de extra taak om “op de merge-knop te klikken” zodat de inmiddels uitgebreid bekeken wijzigingen daadwerkelijk in de broncode landen.
Dan is er als laatste nog de lead maintainer. Tot op heden zijn er drie lead maintainers geweest: Satoshi Nakamoto, Gavin Andresen en Wladimir van der Laan. De rol van de eerste twee namen was duidelijk: ze waren het gezicht van bitcoin. Dit geldt in mindere mate voor Van der Laan, die naar buiten toe beperkt zichtbaar was. Ook heeft hij in de afgelopen jaren getracht om de rol van lead maintainer te verdelen over de verschillende maintainers. Begin 2021 schreef hij:
I will start by delegating my own tasks, and decreasing my involvement. I do not intend to stop contributing to Bitcoin, or even to the Bitcoin Core project, but I would like to remove myself from the critical path and take (even more) of a background role.
Note that we had a nice growth in development activity, and that maintenance of the code itself has already been spread over multiple people for a while. I’m not the most active maintainer. Looking at the number of git merges
Het is dus nog maar de vraag of de rol van lead maintainer blijft bestaan. Op dit moment is er in ieder geval formeel nog geen opvolger voor Van der Laan bekend.
Hoe verander je bitcoin?
Nu we de verschillende rollen (contributor, maintainer, lead maintainer) kennen, is het tijd om stil te staan bij het proces waarmee wijzigingen hun weg vinden naar de gebruikers. Dit noemen we het change management proces. Dat bestaat bij softwareontwikkeling normaal gesproken uit een aantal fasen: de aanvraag, het ontwikkelen, het testen en het migreren naar de productieomgeving. Deze fasen zie je ook terug bij bitcoin, maar het open en decentrale karakter zorgen voor grote verschillen. Komen we zo op terug.
Hoe komt een wijziging tot stand? Kan iedereen een voorstel doen? Het antwoord is ja. Als je iets wilt wijzigingen aan de software moet je eerst de laatste versie van de broncode downloaden. Als je de code op je lokale machine hebt staan kun je gaan programmeren. Als dat gebeurd is neem je de gewijzigde code op in een pull request, een verzoek om de voorgestelde wijziging over te nemen. In tegenstelling tot een normale organisatie waar er op dit punt al verschillende managers hun akkoord hadden moeten geven, hoef je bij bitcoin aan niemand toestemming te vragen.
Dat stopt echter op dit punt. Zodra je een pull request ingediend hebt, kunnen andere contributors de aanvraag beoordelen: de review. We bevinden ons nu in de testfase. Het testen van software gebeurt op verschillende manieren. Doet de wijziging wat het moet doen? Blijft het systeem als geheel werken? Heeft deze wijziging invloed op verwante software, bijvoorbeeld het lightningnetwerk?
Als de wijziging door de review heen komt zal één van de maintainers de wijziging doorvoeren in de master branch. Dit proces heet het mergen. Hierna zal de wijziging (samen met andere wijzigingen) onderdeel worden van een volgende versie van de software.
Eind goed, al goed. Het enige dat nog moet gebeuren is de software installeren, dat kan toch niet moeilijk zijn? Dat is niet helemaal waar. Ten eerste omdat, ook in normale bedrijven, het deployen van software in de productieomgeving altijd spannend blijft. Je kunt nog zo goed testen, er komen altijd problemen naar boven. Ten tweede omdat er in het geval van bitcoin geen centrale server is. De bitcoinsoftware draait op tienduizenden nodes wereldwijd. De beheerders van die nodes zullen expliciet moeten beslissen om de nieuwe versie te installeren. Er is dus geen “auto-update” feature, aldus Jameson Lopp.
Dit wordt nog belangrijker als we het hebben over consensus changes: wijzigingen die de spelregels van bitcoin veranderen. Als nodes verschillende regels toepassen loop je het risico dat de ene node blokken toevoegt aan de blockchain die de andere juist verwerpt. Er zijn twee soorten aanpassingen mogelijk: je kan regels toevoegen (soft fork) of regels verwijderen (hard fork). Bitcoin Cash is een voorbeeld van een hard fork (doordat de blocksize verhoogd werd, werden blokken die aan de oude regels voldeden verworpen). Segwit en Taproot zijn voorbeelden van soft forks.
Wie hebben nou de macht in handen als het gaat om het doorvoeren van wijzigingen aan de regels van bitcoin? De miners? De nodes? De mysterious coders? Dat is een discussie die al jaren loopt en waar nog steeds geen definitief antwoord op is. Als we bijvoorbeeld kijken naar de Segwit soft fork zien we dat daar in eerste instantie de miners moesten beslissen of ze de wijziging aan de consensusregels wilden doorvoeren. Daar deden ze echter zo lang over dat de beheerders van nodes met een plan kwamen: de user activated soft fork (UASF). Hiermee dwongen ze miners om hun keuze voor of tegen de soft fork publiek te maken. In dit geval zou je dus kunnen zeggen dat de nodes (gebruikers) de macht hebben. Bij Taproot werd echter gebruik gemaakt van speedy trial, een proces waarin de miners hun voorkeur voor de wijzigingen bekend maken (waar ze in het geval van Segwit mee treuzelden). Er is tot op de dag van vandaag veel discussie over de manier waarop wijzigingen aan de bitcoinsoftware geactiveerd moeten worden. Over die discussie zullen we jullie op de hoogte houden, maar voor nu gaan we terug naar de maintainers.
De bazen van bitcoin?
Nu we het complete plaatje van het ontwikkelproces hebben geschetst kunnen we beoordelen hoeveel macht de maintainers daadwerkelijk hebben. Wij denken dat het met die macht wel meevalt: voldoende ogen houden de broncode in de gaten. Niet alleen van andere bitcoinontwikkelaars, maar ook van experts en bedrijven die om verschillende reden belang bij het bestaan van bitcoin hebben. Zodra een maintainer opzettelijk kwaadaardige code toevoegt, zal dit direct opvallen bij de andere maintainers en zal er gecommuniceerd worden dat de broncode onveilig is.
Betekent dit dat er geen risico is? Nee. Vaak worden fouten niet veroorzaakt door kwaadwillendheid, maar door onkunde of ongeluk. En hoewel de maintainers niet de macht hebben om op individueel niveau opzettelijk bitcoin stuk te maken, ligt er wel een grote verantwoordelijkheid op een klein aantal schouders. Dit risico laat zich aardig vangen in de principaal-agenttheorie. Dit probleem steekt overal in onze maatschappij de kop op, simpelweg omdat je als mens niet alles kunt weten. Ik vertrouw op mijn bakker, slager en kapper dat ze mijn eten niet laten verbranden en mijn hoofd niet kaal scheren. Nu zal ik een kaal hoofd wel overleven, maar bij een hartoperatie leg ik mijn leven letterlijk in handen van de chirurg. De crux bij dit probleem is dat de chirurg niet altijd dezelfde belangen heeft als ik. Misschien heeft hij nog wel drie operaties te gaan, waardoor hij net wat sneller door moet werken dan je idealiter zou willen. Er ontstaat een informatie asymetrie in het voordeel van de agent (de dokter, kapper of bakker), omdat ik (de principaal) niet volledig in staat ben om te controleren wat de agent doet en of dat in mijn belang is.
Dit probleem is ook aanwezig in bitcoin. Het gezegde “don't trust, verify” klinkt leuk, maar gaat niet op als we het hebben over de moeilijke cryptografische concepten die aan de basis van bitcoin liggen. Er zijn weinig mensen die écht snappen hoe Taproot, Schnorr-handtekeningen en het SHA-256 algoritme werken. We zullen dus moeten vertrouwen op dat kleine groepje mensen die het wel snappen om een beslissing te kunnen nemen. Dat is niet per se een probleem: we kunnen namelijk wel uitleg aan diezelfde mensen vragen en de discussie tussen de experts volgen. Feit blijft echter dat wij als normale stervelingen moeten vertrouwen op de inschatting van de experts. Om die reden is het wijzigingsproces behoorlijk politiek. Je moet als programmeur daadwerkelijk steun voor je wijziging vinden bij partijen met invloed (of de community als geheel).
Dit brengt ons bij het tweede risico: wie wil er eigenlijk maintainer zijn? Of breder, wie wil er überhaupt aan bitcoin programmeren? Als we kijken naar het ecosysteem van bitcoin, dan is er voor bijna alle participanten wel een prikkel ingebouwd in het protocol om mee te doen: miners krijgen de block reward en gebruikers krijgen hard, digitaal en decentraal geld. De developers krijgen niets, behalve de eer. Hierdoor trekt het werken aan opensourceprojecten weinig ontwikkelaars aan. Dat is overigens een probleem voor bijna alle opensourcesoftware (zoek maar eens op cURL of OpenSSL).
Overigens zijn er veel opensourceontwikkelaars die ook alleen maar de eer willen, omdat ze vinden dat betaald worden niet in lijn is met de gedachte achter opensourcesoftware. Dat ethische rabbit hole laten we voor nu even dicht. Het probleem is dus dat ontwikkelaars wel de druk voelen van het in de lucht houden van een asset van 500 miljard dollar, maar afhankelijk zijn van donaties om dat werk te kunnen doen. De stress die dat oplevert was voor Wladimir van der Laan één van de redenen om te stoppen.
Conclusie en naslagwerk
Wat begon als een simpele uiteenzetting van de rollen en processen in het ontwikkelen van de bitcoinsoftware eindigt zoals altijd weer in rabbit holes zonder definitief antwoord. We zullen daarom de belangrijkste observaties en openstaande vragen bij je neerleggen, zodat je er nog wat verder over na kunt denken:
- De informatie-asymmetrie tussen ontwikkelaars en gebruikers (principaal-agenttheorie) van bitcoin zorgt voor een afhankelijkheid van een kleine groep ontwikkelaars. Dit brengt verschillende risico's met zich mee.
- Er is geen perfecte manier om gebruikers een nieuwe versie van de bitcoinsoftware in gebruik te laten nemen. Zowel de user activated soft fork als de miner activated soft fork hebben plus- en minpunten.
- Maintainer zijn is stressvol en er staat weinig tegenover behalve eer. Dit zorgt ervoor dat programmeurs niet staan te springen om de rol aan te nemen.
Toch willen we wel een gooi doen naar een antwoord op de vraag of maintainers de bazen of juist de conciërges van bitcoin zijn. Wij denken dat laatste, omdat er simpelweg geen baas van bitcoin is. Er is geen CEO van bitcoin. Misschien dat Satoshi (of Gavin Andreesen) in de rol als lead maintainer in de buurt kwam van een traditionele CEO, maar daar is al jaren geen sprake meer van. Het zien van developers als conciërges spreekt ons meer aan. Net als op de middelbare school vroeger was de conciërge niet de baas, maar toch kon niemand zonder ze. Het waren de mensen die na vijf uur ‘s middags toch nog even de aula aanveegden. De mensen die met zowel leerlingen als leraren overweg konden. Ze kenden elke ruimte in het gebouw en de snelste route naar elk lokaal. Onmisbaar, onderbetaald en te weinig erkend.
Lees-, Kijk- en Luistertips
Meer weten over het ontwikkelproces van bitcoin? Luister dan de onderstaande podcasts. In Bitcoin, Explained legt bitcoinontwikkelaar Sjors Provoost in 40 minuten uit hoe het proces werkt.
Wil je weten wat een maintainer doet? Luister dan naar deze aflevering van de Stephan Livera Podcast, waar maintainer Gloria Zhao uitlegt wat ze allemaal doet:
Als laatste podcast hebben we Bitcoin.Review van NVK. De podcast is een langer gesprek tussen vier experts en zeker het luisteren waard:
Als laatste hebben we het klassieke artikel van bitcoinexpert Jameson Lopp, waarin hij antwoord probeert te geven op de vraag wie de baas is van bitcoin.
Tot slot
Zo, de Deepen zit er weer op! Wij zijn benieuwd wat jullie ervan vonden. Laat het ons weten in de community. Tot over twee weken!
Bart, Peter en Bert.