De kans is aanwezig dat blockchain-technologie gebruikt wordt voor het gedecentraliseerd vastleggen van certificaten. Maar hoe kun je overeenstemming krijgen over de waarde ervan, zonder dat één centrale partij daar de zegen aan geeft?
Ik heb een aantal keren geschreven over de toepassing van blockchain-technologie voor leren, opleiden en onderwijs. Een potentiële toepassing is het vastleggen en toegankelijk maken van (micro-)certificaten. Op dit moment worden certificaten en diploma’s door centrale instanties erkend. Dat wekt vertrouwen. Hoe krijg je echter consensus over de waarde van (micro-)certificaten als deze centrale instanties geen rol spelen?
Victor van der Hulst heeft onlangs een bijdrage geschreven over de wijze waarop je binnen blockchains tot consensus kunt komen. Hij maakt daarbij in eerste instantie onderscheid tussen een permissioned en een permissionless blockchain.
Bij een permissioned blockchain is de toegang tot het systeem beperkt tot een selecte groep deelnemers. Je kunt je bijvoorbeeld voorstellen dat een selecte groep universiteiten deel uit maken van zo’n permissioned blockchain, waarbij men automatisch elkaars (micro-)certificaten erkend (bijvoorbeeld van het afronden van massive open online courses). Dit gebeurt momenteel bijvoorbeeld in edX-verband, zonder daarbij gebruik te maken van blockchain-technologie. Deze constructie kan bijvoorbeeld ook door leden van de Vereniging Hogescholen of mbo raad worden gehanteerd. Dit zou overigens de vrijheid van lerenden wel beperken en alternatieve spelers op het gebied van leren, opleiden en onderwijs buiten de deur houden. Je hebt hiervoor ook geen blockchain-technologie nodig.
Bij een permissionless blockchain is geen sprake van toegangsbeperking tot de blockchain. Het aantal deelnemers kan erg groot en daarmee onbekend zijn. Een deelnemer is overigens een organisatie die (micro-)certificaten verstrekt, en niet een individuele lerende.
Om misbruik te voorkomen heb je dan mechanismes nodig waarmee bepaald wordt wat de inhoud en waarde van een (micro-)certificaat is. Victor onderscheidt daarbij de volgende mechanismen:
- Proof of Work. Bij Bitcoins moeten miners bijvoorbeeld een complexe cryptografische puzzel oplossen. Degene die wint mag het block met transacties toevoegen aan de blockchain en ontvangt een beloning. De oplossing wordt ook gecontroleerd door anderen. Deze aanpast kost veel rekencapaciteit, energie en dure hardware. Het belemmert wel oneerlijk gedrag. Voor het vastleggen van (micro-)certificaten lijkt me dit geen geschikte aanpak (duur, energievretend, complex; ik kan me ook geen voorstelling maken van de ‘puzzel’).
- Proof of Stake. De inzet van coins bepaalt wie de meeste kans maakt het volgende block met transacties te mogen toevoegen. Het block wordt gecontroleerd door andere ‘nodes’ in het systeem. Dit betekent dat degenen met de meeste coins steeds rijker worden. Er is dus sprake van een beperkt aantal grote partijen. Bij misbruik verliest de fraudeur de inzet. Eerlijk gezegd kan ik me hierbij ook maar moeilijk een toepassing voorstellen als het gaat om (micro-)certificaten. Behalve dat andere deelnemers binnen de blockchain de rol van validator vervullen. Dat kan echter een arbeidsintensief proces zijn. Ik zie ook het risico dat enkele grote spelers binnen de blockchain een dominante positie hebben.
- Leased en delegated Proof of Stake. Hierbij opereren gedelegeerde nodes onder de vleugels van de grote spelers.
- Proof of Importance. De ‘productive network activity‘ van een deelnemer binnen de blockchain bepaalt of men een block mag toevoegen. In relatie tot (micro-)certificering zou je kunnen zeggen dat de deelnemer die het meest actief is, een block mag toevoegen. Reputatie zal hierbij ook een belangrijke rol spelen. Nieuwe deelnemers zullen het hierbij moeilijk hebben.
- Proof of Activity. Dit is een combinatie van de eerste twee mechanismes (oplossen puzzel, en het valideren van het block). De relevantie (micro-)certificering is m.i. daarom gering.
- Practical Byzantine Fault Tolerance. Hierbij is het aantal nodes binnen de blockchain vooraf bekend en toegelaten. Deelnemers komen gezamenlijk tot het besluit om de transactie te erkennen of niet. Dit mechanisme is dus niet geschikt voor een permissionless blockchain. Maar op zich wel relevant voor (micro-)certificering.
- Federated Byzantine Fault Tolerance. Hierbij is sprake van een open netwerk, waarbij deelnemers gezamenlijk tot consensus komen. Niet door elke deelnemer om de mening te vragen. Elke node bepaalt zelf wie hij of zij vertrouwt. (Micro-)certificaten worden dan erkend via zogenaamde ‘federated voting’ (vote, accept en confirm). Dit is realiseerbaar, maar ook complex vorm te geven.
- Delegated Byzantine Fault Tolerance. Binnen dit mechanisme wordt volgens Victor gewerkt met zogenaamde consensus nodes (een soort boekhouders). Deelnemers voeren onderling transacties uit, maar houden zich niet bezig met het valideren van -in het geval van opleiden en onderwijs- (micro-)certificaten. Dat doen gedelegeerden, en de ‘speaker’ die nog een speciale rol heeft in het verbinden van blocken met elkaar. Gedelegeerden moeten daarbij aan bepaalde kwaliteitseisen voldoen (o.a. beschikken over voldoende rekenkracht). Indien tweederde van de gedelegeerden akkoord is, wordt het block toegevoegd en definitief gemaakt. (Micro-)certificaten worden dan door vertegenwoordigers van deelnemers gevalideerd. Dat kunnen weer exameninstituten of certificeringsinstellingen zijn. Daarmee realiseren we volgens mij de huidige situatie met nieuwe technologie. De ‘middle man’ verdwijnt daarbij niet. Je voorkomt hiermee wel dat lerenden nep-certificaten kunnen gebruiken en je slaat (micro-)certificaten permanent en veilig op. Ook kunnen deelnemers op een gegeven moment voor andere gedelegeerden kiezen.
Victor van der Hulst concludeert onder meer:
De perfecte oplossing (silver bullet) bestaat niet en de toepassing en context bepalen welk mechanisme het meest geschikt is.
Voor het gebruik van blockchain-technologie voor (micro-)certificaten komen m.i. niet heel veel mechanismes in aanmerking. Uitgaande van een permissionless blockchain zijn dat volgens mij:
- Proof of Importance
- Federated Byzantine Fault Tolerance
- Delegated Byzantine Fault Tolerance
Ik heb zelf de indruk dat het laatste mechanisme het meest passend is voor (micro-)certificering. Maar wellicht is ook een ander mechanisme noodzakelijk. Je bent er in elk geval niet met een technische infrastructuur alleen.
This content is published under the Attribution 3.0 Unported license.
Geef een reactie