Yao gaf toen het volgende voorbeeld. Twee miljonairs – vandaag zouden we eerder spreken over miljardairs – willen weten wie de rijkste is, zonder hun exacte rijkdom of zelfs maar indicaties daarvan aan de andere of aan een derde partij prijs te geven. Beide partijen willen dus weten of wealth₁ < wealth₂ waar of fout is, zonder dat er voor de rest informatie lekt, dus zonder dat de ene miljonair verdere informatie over wealth₁ prijsgeeft en zonder dat de andere verdere informatie over wealth₂ prijsgeeft.

Lange tijd bleef SMC een louter academische aangelegenheid met enkel toy-examples zoals hierboven. Het was (en is) immers erg moeilijk om SMC in de praktijk te brengen, onder meer door de dramatische impact op de efficiëntie en de intensieve communicatie tussen de betrokken partijen. 

Ondertussen zijn we ongeveer 40 jaar verder en is er heel wat onderzoek verricht rond SMC – het blijft trouwens een zeer actief onderzoeksdomein -, waarbij protocollen ontwikkeld werden die efficiënter zijn, die andere veiligheidseigenschappen hebben, die drie of meer partijen toelaten, etc. Daardoor duiken hier en daar – zij het momenteel nog in beperkte mate – praktische SMC toepassingen op.  Toch blijft de generieke SMC technologie, zoals die door Yao geïntroduceerd werd, in vele gevallen weinig praktisch.

Daarom werden en worden specifiekere protocollen ontwikkeld zoals oblivious transfer, wat toelaat dat een partij een specifiek record uit een lijst opvraagt bij een andere partij, zonder dat die laatste te weten komt het welke, wat handig kan zijn voor bijvoorbeeld politiediensten die elders informatie opvragen over verdachte burgers. Een ander voorbeeld is private set intersection (PSI), waarbij een partij te weten komt over welke items (vb. burgers of ondernemingen) een andere partij eveneens een dossier heeft, waarbij er verder geen data lekt. Ook onze eigen oblivious join, om data afkomstig van meerdere bronnen voor onderzoeksdoeleinden te kruisen en te pseudonimiseren, is zo’n specifiek protocol. In de academische crypto-wereld slaat SMC doorgaans enkel op de generieke technologie, al merken we dat daarbuiten ook de meer specifieke protocollen onder de SMC vlag geplaatst worden.

In de praktijk

SMC wordt hier en daar reeds in de praktijk gebruikt, zoals blijkt uit de drie onderstaande cases.

De bekendste en misschien ook de eerste reële toepassing van (generieke) SMC wordt al sinds 2008 gebruikt en wordt geregeld ingezet voor Deense suikerveilingen. Het is een dubbele veiling, waarbij zowel kopers als verkopers bieden. De veiling, die zonder centrale partij verloopt, moest voldoen aan strikte privacy vereisten, waarbij de biedingen confidentieel blijven. De veiling wordt uitgevoerd als een 3-party SMC tussen 1) vertegenwoordigers van Danisco, de enige suikerbietenverwerker in Denemarken, 2) de boerenvereniging (DKS) en 3) de onderzoekers (SIMAP).

Ons tweede voorbeeld is Sharemind. Het wordt commercieel aangeboden en gebruikt voor analyses op gevoelige gegevens afkomstig van verschillende partijen. Die partijen kappen elk afzonderlijk hun data in stukjes die afzonderlijk geen informatie bevatten en uploaden een derde van de stukjes data naar elk van drie verschillende servers. Dit gebeurt op zo’n manier dat de data confidentieel blijft voor de individuele servers, weliswaar onder de veronderstelling dat deze niet samenspannen. Om een query uit te voeren, zullen de drie partijen en de vraagsteller (de onderzoeker) met elkaar interageren (het SMC protocol), waarbij de vraagsteller – en enkel de vraagsteller – toegang krijgt tot het uiteindelijke resultaat door de antwoorden van de drie servers te combineren. Om de efficiëntie en governance te verbeteren, wordt Sharemind ook aangeboden in één enkele appliance, waarbij gebruik gemaakt wordt van hardware (Intel SGX) om de drie zones van elkaar te scheiden. Sharemind heeft zijn eigen taal voor het doen van analyses. We geven ook nog mee dat Sharemind heel wat verschillende cryptografische bouwstenen combineert.

Unbound is ons derde voorbeeld. Het lost met SMC het probleem op van de gecompromitteerde sleutel. De veiligheid van cryptografische operaties (encryptie, decryptie, ondertekenen, …) steunt immers op de veronderstelling dat de geheime/private sleutel ook effectief geheim/privaat blijft. In de praktijk is dit niet steeds even vanzelfsprekend. Unbound reikt een oplossing aan waarbij de sleutel opgesplitst is in twee deeltjes die door verschillende partijen bewaard worden. Wanneer een deeltje gecompromitteerd is, kan de hacker daar nog steeds niets mee aanvangen. Dit verhoogt aanzienlijk de veiligheid, maar impliceert wel dat een cryptografische operatie enkel mogelijk is met medewerking van de partij die het andere deel van de sleutel heeft. De cryptografische operaties worden uitgevoerd m.b.v. SMC waarbij de twee sleuteldeeltjes nooit samenkomen. Unbound biedt in zijn producten ondersteuning voor zowel symmetrische (AES) als publieke sleutelcryptografie (vb. RSA).

Ten slotte kan SMC gebruikt worden voor veilige machine learning, maar daarover meer in een toekomstige blogpost. Dit lijkt zich nog meer in de onderzoeksfase te bevinden.

Initiatieven in overheidscontext (NL)

Recentelijk zien we hier en daar proof of concepts en piloten opduiken in overheidscontext. Nederland zet duidelijk in op SMC in zijn meer algemene definitie waarin dus ook meer specifieke protocollen vervat liggen. Uit een recent en inspirerend rapport van de Nederlandse TNO (Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek ) blijkt alvast dat ze heel wat potentieel zien binnen overheidscontext:

Er zijn ontzettend veel toepassingsmogelijkheden voor privacyverbeterende technieken zoals MPC en FL [Federated Learning]. Zo kan de effectiviteit van de zorg vergroot worden door op een privacy vriendelijke manier inzichten uit patiëntdata te verkrijgen. De groeiende financiële criminaliteit kan ingedamd worden door het veilig koppelen van gevoelige data van verschillende financiële organisaties. Daarnaast kan de overheid haar dienstverlening verbeteren door privacy respecterende samenwerkingen tussen verschillende overheidsinstanties.

We blijven even stilstaan bij een case uit de Nederlandse overheidscontext waarover we toch wat – zij het beperkt – technische informatie konden vinden. In Nederland vormt de AOW uitkering een basispensioen. Indien dit onder het bestaansminimum valt, hebben gepensioneerden recht op een aanvulling (de AIO). 34.000 (48%) tot 50.000 (56%) van de huishoudens met een inkomen onder het bestaansminimum maakt hier geen gebruik van. De SVB, de instelling verantwoordelijk voor die AOW, heeft geen toegang tot gegevens over sociale uitkeringen en pensioenen (gekend door het UWV) en kan dus niet nagaan wie er AIW-gerechtigd is. Dit tracht men in Nederland in een piloot op te lossen m.b.v. homomorfe encryptie (zie verder) om te komen tot een SMC protocol. Toch lijkt het op basis van de beschikbare informatie voor uw nederige auteur logischer om in dit geval gebruik te maken van de eerder vermeldde private set intersection (PSI).

Ook in Belgische overheidscontext schuilt er ongetwijfeld heel wat potentieel. Smals Research wil dit samen met u exploreren. Aarzel daarom niet contact met ons op te nemen.

We vermelden ook graag dat de COSIC groep aan de KU Leuven wereldwijd aan de top staat wat betreft SMC onderzoek. Dit onderzoek resulteerde in een uitgebreide, door hen ontwikkelde library die SCALE-MAMBA gedoopt werd. Een ander veelbelovend COSIC project is JANA:

Jana aims to provide practical private data as a service to protect subject privacy while retaining data utility to analysts. 

Relatie tot andere technologieën

SMC laat toe om zonder centrale partij, dus gedistribueerd berekeningen te doen. Wat is dan het verschil met blockchain-technologie? In een klassieke blockchainbenadering, wordt alle input nodig voor de berekeningen op de blockchain geplaatst en dus gedeeld met andere participanten in het blockchain netwerk. Die participanten doen vervolgens allen exact dezelfde berekeningen op die data. Gegeven dit basisprincipe is het niet altijd makkelijk om een blockchain benadering te verzoenen met strenge privacyvereisten. Bij SMC, daarentegen, staan confidentialiteit en privacy centraal. Blockchaintechnologie blinkt wel uit om informatie onweerlegbaar en zonder centrale partij te registreren. Het sleutel(werk)woord bij MPC is berekenen, het sleutelwoord bij blockchain is registreren.

Homomorfe encryptie (HE) is een cryptografische techniek om berekeningen op een veilige manier te outsourcen naar een centrale partij (vb. naar de public cloud), en is daarmee op functioneel vlak een alternatief voor SMC. HE laat toe dat een centrale partij berekeningen doet op data zonder toegang te krijgen tot die data zelf. De centrale partij doet daarbij berekeningen op de vercijferde gegevens, waarbij het resultaat opnieuw een cijfertekst is. Bijvoorbeeld enc(5) * enc (3) = enc(15). De centrale partij doet in dit geval een vermenigvuldiging, maar het komt noch de waarden 5 en 3 (input) noch de waarde 15 (output) te weten.

Homomorfe encryptie kan, net zoals SMC, dezelfde berekeningen als een klassieke computer (de Turingmachine) ondersteunen. In dat geval speken we van full homomorphic encryption (FHE), waarvoor een eerste concrete schema pas relatief recent – in 2009 – voorgesteld werd. FHE is weliswaar een pak minder efficiënt en daardoor –  veel meer nog dan SMC – een theoretisch gegeven. In het boek “A Pragmatic Introduction to Secure Multi-Party Computation” uit 2017 schrijven de auteurs:

Hoewel er recent veel belangstelling is geweest voor het implementeren van FHE-schema’s […] blijft het bouwen van veilige, inzetbare, schaalbare systemen met FHE een ongrijpbaar doel. [..] State-of-the-art FHE-implementaties zijn duizenden keren langzamer dan two-party en multi-party secure computation in typische toepassingen en instellingen die in de literatuur worden overwogen.

Toch mogen we niet vergeten dat beperktere vormen van HE onmisbaar zijn in de cryptografie ter ondersteuning van andere cryptografische bouwblokken zoals…  bepaalde SMC protocollen! 

We geven ten slotte nog mee dat sommige generieke SMC protocollen onder meer gebruik maken van vormen van het reeds aangehaalde oblivious transfer. 

Conclusie

SMC was lange tijd een eerder academisch curiosum, maar ondertussen hebben de eerste concrete toepassingen reeds het licht gezien. We bevinden ons weliswaar nog in een vroeg stadium om SMC in de praktijk te brengen.

Toch lijkt er heel wat potentieel in de technologie te zitten. Het is echter niet steeds eenvoudig om de juiste technologie te selecteren. Er zijn verschillende generieke SMC protocollen, en er zijn talrijke voorstellen voor meer specifieke SMC protocollen. COSIC biedt alvast ondersteuning bij het selecteren van een generiek SMC raamwerk.

We kijken in elk geval al uit naar uw suggesties om samen met u een concrete overheidscase uit te werken.

Dit is een ingezonden bijdrage van Kristof Verslype, cryptograaf bij Smals Research. Het werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Bronvermelding foto
20111005_Ozark Henry Quatre Mains @ Arenberg by Tom Van Ghent. Published on Flickr under creative commons.

Het is oktober 1969. Charlie Kline bevindt zich in de University of California Los Angeles (UCLA). Zijn collega Bill Duvall, eveneens een jonge programmeur, is op datzelfde moment in het Stanford Research Institute (SRI). Ze slagen er voor het eerst in een bericht te versturen over ARPANET, een gedistribueerd en robuust netwerk waar een paar jaar later TCP/IP protocol uit zou ontstaan. Ons hele Internet is tot op vandaag op dit protocol gebouwd. ARPANET liet toe om berichten te versturen over een netwerk dat exclusief bestaat uit knooppunten die onbetrouwbaar zijn, in de zin dat ze op elk moment konden uitvallen. Een dergelijk netwerk was niet afhankelijk van een centraal knooppunt en kon zelfs een nucleaire aanval overleven, wat in volle Koude Oorlog een sterk pluspunt was.

De echo’s uit de jaren ‘60 van de vorige eeuw zijn onmiskenbaar als we kijken naar blockchain; door middel van een gedistribueerd netwerk kan robuust en zonder afhankelijk te zijn van een centrale partij informatie (ARPANET) of activa (DLT) uitgewisseld worden. Zoals reeds eerder geschreven, wordt vaak gesteld dat blockchain, en meer algemeen Distributed Ledger Technology (DLT) even belangrijk zal worden als het Internet zelf. Daar waar het Internet het uitwisselen van informatie snel en goedkoop maakte, zal DLT het uitwisselen van alles van waarde snel en goedkoop maken. Het mooie is, zo horen we, dat we daarvoor niet langer afhankelijk zullen zijn van een autoriteit zoals de bank, notaris of overheid. Het zal allemaal gebeuren op een robuust, gedistribueerd blockchainnetwerk, dat op het Internet leeft. De vraag is echter of alles wel zo’n vaart zal lopen. Laat ons daarvoor eens naar de evolutie van het Internet zelf kijken.

Bovenop het gedistribueerde Internet werden heel wat gecentraliseerde of hiërarchische top-down diensten gebouwd. Midden jaren 1980 ontstond DNS (Domain Name Service), waardoor we niet langer de IP-adressen van computers hoeven te kennen, maar enkel de domeinnaam. We hoeven dus niet langer 74.125.224.72 te onthouden, maar gewoon google.com. Als we over een veilig kanaal naar een website surfen, of een digitale handtekening willen verifiëren, maken we gebruik van een PKI (Public Key Infrastructure), wat eveneens een hiërarchische top-downdienst is die reeds begin jaren 70 ontwikkeld werd. Dankzij een PKI weten we met wie we communiceren, maar daarvoor moeten we die PKI wel vertrouwen.

Begin 1990 werd HTTP (HyperText Transfer Protocol) geïntroduceerd, wat de creatie van websites toeliet. Hoe vinden we echter de juiste website? In 1996 zetten twee studenten aan Stanford University, Larry Page en Sergey Brin, een zoekmachine op die luisterde naar de naam Google. Hun bedrijf groeide snel uit tot een mastodont.

De ontwikkeling van nieuwe technologieën liet vanaf de eerste jaren van dit millennium toe om het idee van het Web 2.0 te realiseren, waarbij de nadruk voortaan zou liggen op interactiviteit en door de burgers zelf gecreëerde inhoud, wat in scherp contrast stond tot de voorheen statische websites. Ook toen hoorden we stemmen verkondigen dat de oligopoliepositie van mediabedrijven zou verdwijnen en de democratie hoogtij zou vieren. Iedereen wordt redacteur van nieuws, iedereen wordt auteur dankzij de nieuwe kanalen. We zouden niet langer afhankelijk zijn van die mediabedrijven die we maar moeten vertrouwen voor accurate informatie en representatieve berichtgeving. In 2003 lanceerde Marc Zuckerberg, een student aan de Harvard University, Facemash. Wegens schendingen van de auteursrechten en privacy moest Facemash al snel offline gehaald worden, maar Zuckerberg werkte desondanks verder aan zijn project en lanceerde in 2004 Facebook. Dit was enkel mogelijk dankzij het Web 2.0, wat naast Facebook het ontstaan toeliet van een heel aantal andere grote sociale platformen zoals LinkedIn, Youtube en Twitter. Het zijn de bedrijven achter deze platformen die bepalen wat gecensureerd wordt, wat u te zien krijgt en die moeite hebben uw privacy te respecteren. Iedereen auteur dus, maar dan wel onder strikte supervisie. Bij onrust in landen zoals Turkije en Egypte wordt toegang tot dergelijke platformen op kritische momenten door de overheid overigens gewoon geblokkeerd. Recent zien we ook nog de proliferatie van fake news, dat door middel van deze sociale media gefaciliteerd wordt. Centrale platformen bepalen in toenemende mate wat echt en wat fake nieuws is. De participerende burger die inhoud aanlevert klinkt zeer gedistribueerd, maar in de praktijk zien we tegelijkertijd ook een sterke centralisatiebeweging.  

Dit zijn maar een aantal voorbeelden die aangeven dat er vandaag niet veel meer overblijft van dat gedistribueerde karakter van het Internet. Het kan wat paradoxaal klinken, maar de gedistribueerde basislaag van het Internet heeft net de condities gecreëerd voor gecentraliseerde megaspelers zoals Facebook en Google.

Dit alles leert ons dat de idee of de belofte van publieke gedistribueerde netwerken, waarbij de macht opnieuw komt te liggen bij de individuele participanten en waarbij centrale spelers niet langer nodig zijn, niets nieuws is. Het verleden leert ons dat er in de praktijk echter steeds een centralisatiebeweging is. Of anders geformuleerd: de intentie tot distributie, die mogelijk wordt dankzij technologische evoluties, resulteert de facto in nieuwe vormen van centralisatie.

De vraag is nu of dit voor de blockchaintechnologie ook het geval zal zijn. Voor Bitcoin zien we alvast opnieuw deze beweging. Bitcoin zou de democratie verhogen, zo werd beloofd. We hoorden slogans zoals “democratisering van het geld” en “banking the unbanked”. Centrale en andere banken zouden verworden tot termen uit geschiedenisboeken, want burgers zouden voortaan hun eigen geld kunnen creëren en transfereren. De werkelijkheid is dat er een paar nieuwe machtscentra ontstaan zijn, mining bedrijven en mining pools, die zich aan alle vormen van controle onttrekken^[. Vanuit democratisch perspectief is dat een stap achteruit in vergelijking met het bestaande systeem. Daarnaast zijn er nog de handelsplatformen en aanbieders van online wallets, waar we afhankelijk van zijn. Bovendien is ook de bitcoinrijkdom erg sterk geconcentreerd; bijna één derde van alle bitcoins is eigendom van 1600 pseudoniemen (adressen)^[. Dit geeft een paar mensen de mogelijkheid om koersen te manipuleren ten nadele van alle anderen. Bovendien zijn deze paar mensen niet aan politieke controle onderhevig, zoals dat bij de centrale banken wel het geval is.

Over blockchain en Distributed Ledger Technology (DLT) in het algemeen zijn gelijkaardige optimistische geluiden te horen, zoals: “Blockchain biedt mogelijk de infrastructuur voor een rechtvaardige, inclusieve, veilige en democratische digitale economie.^[” De vraag is echter in welke mate publieke blockchain netwerken zullen kunnen weerstaan aan de dynamiek tot centralisering die we tot nu toe zagen.

Wanneer nieuwe virtuele munten of gedistribueerde applicaties gelanceerd worden, die allen van DLT gebruik maken, houden de makers een groot deel van de muntjes of tokens voor zichzelf. Daardoor krijgen ze naast rijkdom ook disproportioneel veel zeggenschap over blockchains gebaseerd op proof of stake of distributed proof of stake. Daarnaast zullen de bedrijven vaak de controle over de ontwikkeling van de code, alsook een sterke controle over het smart contract, bij hen houden, zoals het geval is bij de gedistribueerde toepassing CryptoKitties. Het bedrijf achter CryptoKitties heeft weliswaar geen controle over de uitvoering van het smart contract, maar heeft wel een mechanisme voorzien dat toelaat het smart contract te vervangen door een ander. Stel dat er ooit een gedistribueerd alternatief voor booking.com ontstaat op een blockchain, dan is er een goede kans dat dit dus nog steeds gecontroleerd zal worden door één bedrijf, dat misschien zelfs het moederbedrijf van booking.com zelf zou kunnen zijn.

Ook bij afgeschermde blockchainnetwerken zien we vormen van centralisering ontstaan. Denken daarbij aan een BaaS (Blockchain as a Service) aanbieder waarop het hele blockchain network draait, of aan de PKI (Public Key Infrastructure) die een Hyperledger Fabric blockchain netwerk afschermt. De noodzaak aan vertrouwen verdwijnt dus niet, maar wordt geherlokaliseerd op zodanige wijze dat samenwerking tussen de beperkte elkaar kennende maar toch wantrouwende groep participanten gefaciliteerd en gestimuleerd wordt. In afgeschermde blockchain netwerken zullen de verschillende participanten bovendien contractueel verbintenissen moeten aangaan. Ook dit maakt vertrouwen in centrale partijen (het gerecht) noodzakelijk, zelfs in een blockchainwereld. Zo zullen criteria afgesproken worden met betrekking tot onder meer veiligheid, beschikbaarheid en reactietijd van de systemen bij de verschillende participanten. Ook het smart contract zal aan bepaalde criteria moeten voldoen (veiligheid, functioneel, …). Het creëren van vertrouwen dat aan al die criteria voldaan is kan audits noodzakelijk maken, wat gebeurt door een vertrouwde partij. Afspraken en verantwoordelijkheden zullen moeten onderling vastgelegd worden. In het kader van de GDPR moeten bijvoorbeeld het doel en de middelen van de verwerking van de persoonsgegevens bepaald worden, en moet afgesproken worden wie verantwoordelijk is voor welke verplichting, in het bijzonder het informeren van de burger. Dit alles sluit niet uit dat het alsnog verkeerd loopt of dat er geschillen ontstaan. In dat geval moeten de participanten alsnog naar de (vertrouwde, centrale) rechter kunnen stappen.

De toekomst zal dus niet enkel uitwijzen in welke mate DLT een rol zal spelen in onze bredere samenleving, maar ook onder welke vorm. Willen we vlot waarde kunnen uitwisselen en tegelijkertijd risico’s, zoals verlies van de geheime sleutel, voldoende afdekken, dan is centralisatie van bepaalde aspecten wellicht een noodzaak.

Een wereld waarin al het vertrouwen evenredig gedistribueerd is over alle betrokkenen en waarbij er geen nood meer is aan vertrouwde entiteiten is dus niet aan de orde. Misschien moeten we tot de vaststelling komen dat het bij de initiële vraagstelling vaak al verkeerd zat. Deze luidde: “Hoe kunnen we een autoriteit, die we verplicht zijn te vertrouwen, elimineren?” Moeten we die vraag in veel gevallen niet vervangen door: “Kunnen we, gebruik makend van onder andere technologie, processen optimaliseren en het vertrouwen in en de controle over de daarbij noodzakelijke autoriteiten maximaliseren?” Ook bij deze vraag kan DLT, eens volwassen, wellicht een zeer waardevolle rol spelen. Vertrouwde autoriteiten, zoals overheden, banken en ook notarissen, zullen dus blijven bestaan, maar hun exacte rol kan in de toekomst wel veranderen.

Bovenstaand artikel is een fragment uit twee recente gepubliceerde boeken:
– “Blockchain en smart contracts – Het einde van de vertrouwde tussenpersoon?” door Jurgen Goossens & Kristof Verslype
– “Blockchain en smart contracts – Impact op de notaris als vertrouwde tussenpersoon?” door Benjamin Verheye & Kristof Verslype, met voorwoord van Paul Danneels, Chief Transformation Officer Fednot.

Wat bedoel ik met de drie termen?

• Distributie van vertrouwen. Het aantal participanten betrokken in het consensusmechanisme en de graad waarin die macht evenredig verdeeld is over deze participanten. Of anders geformuleerd: het aantal partijen dat de blockchain veilig houdt en verifieert of de regels gerespecteerd worden. En heeft elk van die participanten daarbij een even zware stem?
• Schaalbaarheid. Het aantal transacties dat per seconde door het netwerk verwerkt kan worden.
• Veiligheid. Veiligheid bestaat uit diverse componenten. Traditioneel spreekt met over CIA, wat staat voor confidentiality, integrity en availability. Blockchain technologie scoort slecht op het vlak van confidentialiteit (zie vorige blogpost), goed op het vlak van integriteit, en, afhankelijk van de invalshoek, goed of slecht op het vlak van beschikbaarheid; er is enerzijds geen single point of failure (SPOF), maar anderzijds zal in een blockchain benadering “pur sang” de participant zijn geheime sleutel moeten beschermen om toegang tot zijn op de blockchain geregistreerde activa te behouden.

Er zijn dus drie wederzijdse spanningen: 1) distributie van vertrouwen Vs. schaalbaarheid, 2) schaalbaarheid Vs. veiligheid en 3) veiligheid Vs. distributie van vertrouwen. We illustreren in wat volgt elk van deze spanningsvelden alvorens naar de afronding te gaan.

Distributie van vertrouwen Vs. Schaalbaarheid

Permissionless blockchains hebben een beperkte capaciteit. Bitcoin kan naar schatting 3,3 tot 7 transacties per seconde verwerken. Voor Ethereum ligt dit rond de 15. Permissioned (afgeschermde) blockchain technologieën zoals Multichain en BigChainDB 2.0 claimen een duizendtal transacties per seconde, wat al aanzienlijk hoger ligt. In dergelijke afgeschermde netwerken is er dan ook een veel kleinere en permanentere set validatoren. Als we naar gecentraliseerde oplossingen gaan dan ligt de verwerkingscapaciteit nog eens vele malen hoger. VISA kan bijvoorbeeld 65 000 transacties per seconde aan.

Om de capaciteit te verhogen is bovenop Bitcoin een extra laag, het Lightning Network, gebouwd. Het claimt miljarden bliksemsnelle transacties per dag, door een groot deel off-chain te behandelen. Toch wordt er gevreesd dat dit opnieuw tot centralisatie zal leiden: “What it doesn’t tell you is that this can only be accomplished by using large, centralized ‘banking’ hubs.” Bovendien moet je eerst virtueel geld vastzetten vooralleer je het Lightning Network kunt gebruiken en lijkt het systeem vooral nuttig in situaties waarbij een vaste groep van entiteiten geregeld met elkaar financiële transacties doet.

De Ethereum community werkt volop aan Plasma, waarbij het mogelijk wordt om nieuwe blockchain netwerken aan te maken die verankerd worden in de Ethereum blockchain. Virtueel geld (ether) zal transfereerbaar worden tussen de Ethereum blockchain en het kind-blockchain. Die laatste kan zijn eigen smart contracts bevatten. Enkel de validatoren van het kind-blockchain verifiëren alle transacties gerelateerd aan dit smart contract. Het totale netwerk, dus de Ethereum blockchain en alle kind-blockchainnetwerken samen, heeft zo een grotere capaciteit, maar niet iedereen verifieert nog alles.

Onder meer door Zilliqa en Ethereum wordt gewerkt aan sharding van blockchains, waarbij validerende participanten niet langer de volledige maar slechts een deel van de blockchain hoeven te valideren en bewaren, wat de schaalbaarheid ten goede komt. Ook dit vermindert de distributie van vertrouwen. Net zoals bij Plasma wordt een smart contract niet langer gevalideerd door alle validatoren, maar door een subset.

Sommige publieke blockchain netwerken hebben een lagere graad van distributie van vertrouwen, waardoor ze wel efficiënter zijn. Een voorbeeld is Ripple, waar de validatie gebeurt door een beperkt – weliswaar groeiend – aantal bedrijven. Het recentere EOS gebruikt DPoS (Delegated Proof of Stake), waarbij een beperkt aantal validatoren verkozen wordt.

Wanneer het aantal transacties per seconde verhoogd wordt, betekent dit meer werk voor de validatoren, meer bandbreedte die vereist zal zijn en meer opslagcapaciteit. Wanneer het aantal transacties per seconde te snel verhoogd wordt, zullen de infrastructuurkosten om een validerende node te draaien stijgen, waardoor een deel zal afhaken en je dus een centralisatiebeweging krijgt. Een beperkt aantal validatoren zal snelle onderlinge connecties opzetten, waardoor het voor anderen nog moeilijker wordt te participeren. Deze vrees werd reeds uitgedrukt voor Ethereum. Ook in de Bitcoin community was er een heftige discussie omtrent het al dan niet vergroten van de maximum blok grootte. Grotere blokken betekenen meer transacties per seconde, maar ook meer werk – en dus kosten – voor de validatoren.

Schaalbaarheid Vs. Veiligheid

Dit is een wat bijzondere categorie vanuit blockchain standpunt, gezien datgene waar blockchain goed in is, distributie van vertrouwen, hier niet aan bod komt. Toch hebben we ook hier een mooi blockchain-voorbeeld.

BigChainDB 1.0 noemde zichzelf een blockchain database; een database met blockchain eigenschappen. Het claimde tot 1 miljoen schrijfoperaties per seconde. Toch bleek dat het een aantal ernstige security zwakheden kende. Zo kon een hacker alles verwijderen door slechts één participant te hacken. BigChainDB 2.0 is midden 2018 uitgebracht, waarbij deze security kwetsbaarheden verholpen zijn. De verwerkingssnelheid die ze claimen zakte daarmee tot “duizenden transacties per seconde“.

Een concept om Bitcoin te ontlasten zijn sidechains, blockchain netwerken die naast de hoofd-blockchain bestaan. Bitcoins kunnen getransfereerd worden tussen de hoofdblockchain en de sidechain. Goed voor de schaalbaarheid, gezien de hoofd-blockchain niet meer alles moet doen. Maar ook daarrond werden bedenkingen over de veiligheid geformuleerd.

Veiligheid Vs. Distributie van vertrouwen

Om hun virtueel geld te beschermen, maken velen gebruik van een vertrouwd, centraal platform. Verschillende van die centrale platformen zijn reeds gehackt, met soms zware financiële verliezen tot gevolg. Maar toch kunnen deze platformen veiliger zijn dan het zelf bewaren van de geheime sleutel op je computer zonder meer. Dit zal sterker het geval zijn eens centrale platformen gereguleerd zullen zijn, wat in Europa slechts een kwestie van tijd is.

Uit de Bitcoin blockchain kan informatie afgeleid worden, die soms aan personen of organisaties gelinkt kan worden. Dit is negatief voor de confidentialiteit (van persoonsgegevens). Zoals in de vorige blogpost besproken, lost zCash dit op. Maar het valideren van een zCash transactie vereist meer rekenkracht, en het opslaan ervan in de blockchain meer schijfruimte (en dus bandbreedte). Dit zijn aspecten die negatief zijn voor de distributie van het vertrouwen (en voor de schaalbaarheid). Je hebt immers een zwaardere machine nodig om eenzelfde aantal transacties per seconde te kunnen verwerken, en wellicht zullen bij een stijgend aantal transacties minder participanten over een voldoende zware machine beschikken.

Permissioned blokchain netwerken worden afgeschermd door een toegangscontrolelaag. In Hyperledger Fabric is dit bijvoorbeeld een top-down hiërarchische PKI (public key infrastructure). Het gevaar dat je je sleutel verliest kan zo opgevangen worden, wat dus de security ten goede komt, maar we moeten wel een gecentraliseerde dienst vertrouwen, wat het gedistribueerde karakter vermindert.

In Hyperledger Fabric kun je enkel een beperkte, geselecteerde set van participanten laten instaan voor de correcte uitvoering van een smart contract. De rest van het netwerk heeft geen toegang tot de betrokken gegevens. Dit komt de confidentialiteit (veiligheid) ten goede, maar reduceert de graad van distributie van vertrouwen.

Meerdere participanten in een afgeschermd blockchain netwerk hebben toegang tot dezelfde data. Afhankelijk van de gegevens en hoe blockchain gebruikt wordt, is het dus mogelijk dat uit die blockchain gevoelige gegevens afgeleid kunnen worden. Elk van de participanten moet in dat geval dus voldoende beveiligd zijn. Als de kans op een ernstig lek in een gecentraliseerde aanpak x% per jaar is, dan stijgt dit bij een gedistribueerde aanpak met y participanten tot x*y% per jaar, en dit in de optimistische veronderstelling dat alle participanten even goed beveiligd zijn als bij een gecentraliseerde aanpak. Distributie van vertrouwen komt hier dus met een verhoogd veiligheidsrisico.

Het opzetten, onderhouden en veilig houden van een afgeschermde blockchain infrastructuur is niet eenvoudig. Om dit te vergemakkelijken bieden een aantal cloud providers vandaag Blockchain-as-Service (BaaS) aan. Daar kan je snel en goedkoop een blockchain netwerk opzetten. Enige probleem: je wordt afhankelijk van de BaaS provider. Het is niet nodig dat participanten elkaar vertrouwen, maar ze moeten wel allemaal de BaaS provider vertrouwen. In ruil daarvoor krijgen we o.a. snel & goedkoop een goed beveiligd en afgeschermd blockchain netwerk.

Afronding

Soms hoor ik blockchain believers het volgende verkondigen: “Alle problemen waar blockchain vandaag mee te kampen heeft, zoals schaalbaarheid, veiligheid en privacy, zullen binnen afzienbare tijd door erg slimme mensen opgelost worden.” Dit heb ik steeds een enorm zware aanname gevonden.

In dit artikel bekeken we het spanningsveld tussen schaalbaarheid, veiligheid en distributie van vertrouwen. De talrijke voorbeelden in het artikel bevestigen dat het erg moeilijk is om tot een oplossing te komen die op de drie punten erg sterk scoort. Dit hoeft geenszins te betekenen dat blockchain technologie naar de prullenmand verwezen moet worden, maar enkel dat gewoon niet alles tegelijkertijd mogelijk is. Het zet misschien een domper op het idee dat er voor platformen met enorm hoge volumes zoals zoals eBay en Facebook, sterk gedistribueerde en tegelijkertijd zeer veilige alternatieven mogelijk zijn. Maar laat ons eerlijk zijn, veelal is dit ook niet nodig. Het zal er dus op aankomen om de juiste keuzes te maken.

De business case

Disclaimer: Er bestaan verschillende eBoxen. Met BeSure willen een zo generiek mogelijke dienst aanbieden. We focussen dan ook niet op een specifieke bestaande eBox.

Binnen de overheid is er een eBox platform dat gebruikt wordt voor het uitwisselen van documenten tussen eindgebruikers. Er zijn verschillende organisaties die elk een verschillend, niet-overlappend deel van de eindgebruikers vertegenwoordigen (zie figuur 1). Elke eindgebruiker wordt dus door exact één organisatie vertegenwoordigd. Wanneer Alice een bericht verstuurt naar Bob, is de flow als volgt:

1. Alice stuurt het bericht via haar organisatie naar de eBox.
2. Bob download het bericht via zijn organisatie.

Alice en Bob maken daarbij gebruik van een web client of fat client aangeboden door de hen vertegenwoordigende organisatie. De eBox moet je dus zien als een gecentraliseerd uitwisselplatform voor documenten, waarop verschillende organisaties aangesloten zijn.

Nu hadden we graag een bewijs dat het document op een bepaald moment door Alice verstuurd werd, en dat het op een bepaald moment door Bob ontvangen werd. Die bewijzen moeten 40 à 50 jaar lang bewaard worden. We kunnen er natuurlijk op vertrouwen dat de eBox dit correct zal doen, maar eigenlijk vertrouwen de eindgebruikers en organisaties de eBox toch onvoldoende daarvoor. De eindgebruikers vertrouwen wel hun organisatie en willen zelf ver weg blijven van complexe informatica. Een blockchain benadering, waarbij de organisaties deel uitmaken van het blockchain netwerk (de blauwe cirkel in figuur 1) lijkt dan ook een logische benadering.

Basisidee

In een ideale blockchain-wereld zijn het de eindgebruikers zelf die direct participeren in het blockchain netwerk. Dat vereist echter dat ze blockchain software installeren, draaien en updates installeren wanneer nodig. Het vereist dat ze een private sleutel genereren en afdoende beschermen. Het vereist dat er een systeem is om te beheren wie wel en wie geen toegang heeft tot het blockchain netwerk, wat niet evident is met een grote variabele groep eindgebruikers. Eindgebruikers worden liever niet lastig gevallen met al het bovenstaande. Vandaar dat we een benadering voorstellen waarin enkel de organisaties en de eBox participeren. Dat is een relatief kleine, stabiele set entiteiten die over de mogelijkheid beschikken om te participeren in het blockchain netwerk en die onderling (juridisch bindende) afspraken kunnen maken. In onze benadering hoeft de eindgebruiker dus niet eens te weten dat er achterliggend een blockchain gebruikt wordt. De prijs is dat het vertrouwen gedecentraliseerd is onder een paar entiteiten, en niet gedistribueerd onder de eindgebruikers.

Per document worden twee bewijzen gecreëerd: eentje dat bewijst dat een specifiek document afkomstig van Alice en bestemd voor Bob op een bepaald moment verstuurd werd naar de eBox, en eentje dat bewijst dat het document ook op een bepaald moment ontvangen is. Zo’n bewijs is eigenlijk een akkoord tussen de betrokken organisatie en de eBox. Het is een blockchain-transactie die door de twee partijen ondertekend wordt. De creatie van dit akkoord is een proces tussen slechts de twee betrokken partijen.

Daarna wordt dit akkoord aan het blockchain netwerk gegeven. Slechts indien de transactie door de eBox en een van de gekende organisaties ondertekend is, wordt het door het netwerk collectief aanvaard, en komt het in de blockchain terecht, waar het onverwijderbaar is. Dit is een collectief proces tussen de betrokken organisaties. De eBox speelt in deze stap niet mee.

Figuur 2 geeft de inhoud weer van zo’n akkoord. Eerst wordt de cryptografische hash van enkel het document berekend. De resulterende documenthash wordt nog eens gehasht, maar nu samen met de identifier van zowel de zender als de bestemmeling. Die finale hash komt in het bewijs terecht. Ten tweede bevat een bewijs het moment waarop het akkoord gecreëerd is, en ten derde de actie; wordt het document afgeleverd aan de eBox (‘SEND’), of wordt het document er opgehaald (‘RECEIVE’). Deze drie zaken worden ondertekend door zowel de eBox als de betrokken organisatie. Beide partijen ondertekenen pas als ze akkoord zijn met deze informatie. Het blockchain netwerk verifieert vervolgens dat het bewijs effectief ondertekend is door de eBox en een gekende organisatie, en is op zich niet geïnteresseerd in de inhoud van het bewijs/akkoord. Bemerk dat de blockchain dus geen persoonsgegevens bevat, wat een zorg minder is. Dit is niet onbelangrijk gegeven het spanningsveld tussen de GDPR en blockchain.

Bewijskracht

Wat is de bewijskracht van een dergelijk bewijs? Er zijn drie niveaus, afhankelijk van de extra informatie die we hebben.

1. Zonder extra informatie bewijst een bewijs enkel dat een ongekend document op een gekend moment verstuurd of ontvangen werd door een ongekende eindgebruiker die aangesloten is bij een geïdentificeerde organisatie. Dit is wat de participanten in het netwerk sowieso te weten komen en zegt iets over de activiteit van de verschillende organisaties
2. Wanneer we enkel de documenthash en de identifiers van de afzender en bestemmeling hebben, kunnen we bewijzen dat een ongekend document verstuurd door een geïdentificeerde afzender naar een geïdentificeerde bestemmeling op een bepaald moment verstuurd of ontvangen is. Dit komt functioneel in de buurt van zowel de klassieke papieren aangetekende zending als de meta-data die telefonieoperatoren juridisch verplicht zijn bij te houden.
3. Wanneer we naast de identifiers van de afzender en de bestemmeling ook nog het originele document hebben, kunnen we bewijzen dat exact dat document, verstuurd door een geïdentificeerde afzender en bestemd voor een geïdentificeerde afzender, op een gekend moment verstuurd of ontvangen is.

Een dergelijke granulariteit kan nuttig zijn. Ook zonder het document prijs te geven kan je bepaalde activiteit bewijzen.

Veiligheid

We willen uiteraard vermijden dat de eBox of een organisatie kan valsspelen. Het wijzigen van het document, zender, ontvanger, tijdstip of type actie is dankzij de twee digitale handtekeningen onmogelijk. Maar er zijn nog aspecten om rekening mee te houden.

• We willen vermijden dat de eBox valse berichten kan injecteren in het systeem, dus dat de eBox in naam van een eindgebruiker een document kan versturen naar een andere eindgebruiker.
• We willen niet dat een document verzonden of ontvangen wordt, zonder dat een bewijs daarvan op de blockchain terecht komt.
• We willen niet dat op de blockchain een bewijs geregistreerd wordt dat een document verzonden of ontvangen is, terwijl dit in werkelijkheid niet zo is.

Dit is niet triviaal in een context waarbij de partijen elkaar niet vertrouwen. Toch hebben we hiervoor een sterke en realistische oplossing gevonden.

Zoals ik reeds in een vorige blogpost schreef, is er een spanningsveld tussen enerzijds blockchain, die steunt op transparantie, en anderzijds confidentialiteit. Hoewel we in de voorgestelde oplossing enkel hashes bewaren bevat ze toch nog een ernstige tekortkoming wat betreft confidentialiteitsbescherming. Dezelfde hash wordt immers herbruikt in alle bewijzen met betrekking tot eenzelfde document. Daardoor kunnen deze bewijzen triviaal aan elkaar gelinkt worden, ook door organisaties die niet in de flow betrokken zijn. Ze kunnen zien wanneer een ongekend document via een gekende organisatie verstuurd werd, en wanneer dat document via een andere gekende organisatie ontvangen werd. En als ze dit doen voor elk document, kunnen ze daar potentieel nuttige statistieken uit extraheren. Ook dit hebben we kunnen oplossen, waarbij we zelfs rekening hielden met erg subtiele vormen van datalekken.

Een gedetailleerde uitleg van alle veiligheidsaspecten zou deze blogpost helaas wat te lang maken, maar het staat u steeds vrij om mij te contacteren. We vatten toch even een aantal eigenschappen van BeSure samen:

• Het systeem kan omgaan met gecompromitteerde sleutels. Voor elke actie (rechtenbeheer, creatie bewijs, publicatie bewijs en sleutelbeheer) zijn immers meerdere sleutels vereist. Dit resulteert in een conceptueel hoger niveau van veiligheid dan gecentraliseerde systemen.
• De blockchain lekt geen confidentiële gegevens, zelfs niet op meer subtiele manieren. Participanten komen via de blockchain geen gevoelige informatie over elkaar te weten. En wanneer een hacker toegang krijgt tot de blockchain of als de blockchain op straat belandt, heeft dit geen implicaties voor de privacy van de burger.
• Het sleutelbeheer gebeurt via de blockchain. De participanten zijn dus niet afhankelijk van een PKI.
• Het crashen van een BeSure component resulteert niet in (tijdelijke) kwetsbaarheden.
• Wanneer de bestemmeling vb. na 25% de download onderbreekt komt er geen bewijs op de blockchain terecht; er is immers geen sprake van een succesvolle download. BeSure verhindert dat de bestemmeling toch al enige informatie uit het gedownloade deel kan extraheren.
• BeSure gebruikt MultiChain als onderliggende blockchain technologie. Dit is een fork van de Bitcoin code, die in de praktijk al uitgebreid getest is. Dit resulteert in een product met weinig bugs, dat dus als stabiel en veilig beschouwd kan worden.
• Externe validatoren kunnen toegevoegd worden aan het netwerk. Zij krijgen toegang tot de blockchain en staan mee in voor het verwerken van de bewijzen in de blockchain. Dit verhoogt verder het vertrouwen dat alles correct verloopt.

Samengevat bekomen we dus een systeem dat een erg hoog niveau van veiligheid kan garanderen.

Conclusies

Een vraag waar we dikwijls mee geconfronteerd worden is: “Kunnen we dit niet met traditionele technologie?” Dit kan, maar dan zullen we afhankelijk zijn van autoriteiten. Om digitale handtekeningen lange tijd geldig te houden, hebben we bijvoorbeeld nood aan een timestamping service telkens wanneer een bewijs gecreëerd wordt. In een traditionele oplossing moeten we ook een manier vinden om te vermijden dat de bewijzen in de loop der jaren verloren gaan of doelbewust verwijderd worden. Gaan we ook daarvoor vertrouwen op een centrale dienst? Er zijn dus goede redenen om een blockchain-benadering te overwegen.

Heel wat blockchain proofs of concept vandaag zijn helaas om weg te gooien. Sommige blockchain bedrijven negeren de GDPR, bouwen blockchain proofs of concept die niet bedoeld zijn om gedistribueerd te draaien (!) en negeren confidentialiteitsvereisten. Voor BeSure hebben we, naast een werkende poc, een uitgebreide analyse gemaakt. Bovendien maken we gebruik van een blockchain technologie die reeds uitgebreid getest is in de praktijk. Door bovenstaande combinatie verhogen we aanzienlijk de kans op uiteindelijke inproductiestelling.

De blockchain filosofie indachtig kunnen we nog een stap verder gaan en het bestaan van de eBox zelf, als centraal uitwisselplatform, in vraag stellen. We moeten immers erop vertrouwen dat de eBox beschikbaar is, de documenten confidentieel behandelt en niet gehackt wordt. Hoewel dit in pakweg de eerstvolgende tien jaar wellicht onrealiseerbaar zal blijven, blijft het een interessante denkpiste die ik misschien in een toekomstige blogpost uitwerk.

Stay tuned! 

Beschermen van data

Een beperkte hoeveelheid niet-gevoelige gegevens op een blockchain bewaren kan natuurlijk probleemloos. Op publieke (unpermissioned) blockchain netwerken zoals Bitcoin en Ethereum zul je daar wel een prijs voor betalen, uitgedrukt in de virtuele munt van het platform (bitcoin of ether). Je betaalt immers onder meer per byte. Sowieso moeten we opletten met de hoeveelheid data die we in de blockchain stoppen, aangezien we er niets uit kunnen verwijderen en de blockchain dus snel erg groot dreigt te worden.

Omwille van deze twee redenen, grootte & confidentialiteit, zal er veelal geopteerd worden om enkel de cryptografische hash (een unieke fingerprint) van gegevens op de blockchain te bewaren. Op die manier kunnen we nagaan of een document op de blockchain geregistreerd werd, wanneer, en onder welk pseudoniem (adres), zonder dat de blockchain verdere informatie lekt. Dan is de logische vraag: waar bewaren we de data zelf? We schetsen een aantal mogelijkheden:

• De eindgebruiker van de applicatie of participanten in het blockchain netwerk bewaren deze zelf. De burger is dan, als eindgebruiker, verantwoordelijk voor het bewaren zijn diploma’s, huwelijkscontracten, verkoopovereenkomsten, … die in de blockchain geregistreerd staan. Zorg wel voor een goede backup en beveiliging! En waar zouden velen deze informatie bewaren? In de omgeving van één of andere gecentraliseerde cloud aanbieder… In het geval van diploma’s kan iedere onderwijsinstelling, als participant in het netwerk, instaan voor het bewaren van de diploma’s. Dat is toch al wat gemakkelijker voor de burger, maar je introduceert weer een afhankelijkheid in de vorm van een SPOF (single point of failure). De server van de onderwijsinstelling kan bijvoorbeeld onbeschikbaar zijn, of misschien verdwijnt de onderwijsinstelling gewoon.
• De participanten in een blockchain applicatie maken gebruik van een gedeelde server met beveiligingsmechanismes zoals encryptie en toegangscontrole. Maar was centralisatie niet net wat we wilden vermijden? En komt een dergelijke hybride oplossing niet met een hogere kost? Tweemaal ja. Toch kan een dergelijke oplossing noodzakelijk zijn om in overeenstemming te zijn met regulering. We denken hierbij in de eerste plaats aan, verrassing, de GDPR. Dankzij vercijfering is het overigens niet nodig dat de centrale server zelf toegang heeft tot de gegevens. Het vereiste vertrouwen in de centrale server blijft dus beperkt.
• Een derde oplossing is dat de gegevens nog steeds – al dan niet geëncrypteerd – gedistribueerd bewaard worden door de participanten van de blockchain applicatie, maar buiten de blockchain. Dit is mogelijk met Distributed Hash Tables (DHTs). Deze technologie laat toe om gegevens te bewaren en te delen in een netwerk van participanten, waarbij de data redundant bewaard wordt. Als een participant uitvalt, blijft het systeem dus gewoon werken. In tegenstelling tot data in de blockchain, hoeft de data hier niet tot het einde der dagen bewaard te worden, en bewaart iedereen slechts een deel van de informatie. Dit versoepelt de vereisten naar opslag toe aanzienlijk. En net zoals bij blockchain kan data niet eenzijdig gewijzigd worden door een malafide participant. DHTs worden onder meer gebruikt in het Interplanetary File System (IPFS). Je hebt niet de centralisatie zoals in de vorige piste, maar de prijs is ook een verlies aan controle over de data, wat vanuit GDPR perspectief moeilijk kan liggen. Wanneer gevraagd wordt aan de participanten in het netwerk om bepaalde gegevens te verwijderen kun je niet nagaan of dit overal effectief gebeurd is en er geen kopieën achtergehouden worden. Wanneer de set van participanten relatief klein is en ze elkaar onderling kennen, zoals het geval is in een afgeschermd (permissioned) blockchain netwerk, kunnen contractuele clausules mogelijks wel een uitweg bieden. Ook encryptie kan nuttig zijn, maar dan moet je wel zorgen dat iedereen die toegang nodig heeft tot de data, en enkel zij, de data kunnen ontcijferen.
• Verschillende blockchain technologieën bieden geïntegreerde ondersteuning voor confidentiële off-chain opslag van data door de participanten in het netwerk, waarbij nodes (participanten) enkel deze data lokaal bewaren die voor hen relevant is en die ze gemachtigd zijn te zien. Deze gegevens worden confidentieel uitgewisseld en in een aparte gegevensbank, los van de blockchain bewaard. Enkel de fingerprint komt op de blockchain terecht. In Hyperledger Fabric heeft men daarvoor side databases, in MultiChain gewoon over off-chain data. MultiChain maakt bijvoorbeeld gebruik van data streams. Een participant kan geabonneerd zijn op nul, één of meer data streams op eenzelfde blockchain. De participant ontvangt, bewaart en verspreidt enkel die off-chain data voor streams waarop hij geabonneerd is. Zijn slechts twee participanten geabonneerd op een data stream, dan zal de bijhorende data enkel door hen bewaard worden. Data is hier dus gedupliceerd, maar niet echt gedistribueerd.

Het gebruik van encryptie om data on-chain te bewaren op een publiek (permissionless) blockchain is niet zonder risico, gezien encryptie de enige beschermlaag is. De geëncrypteerde data blijven voor eeuwig op de blockchain, maar mettertijd zal de sterkte van de gebruikte encryptie afnemen, en sleutels kunnen gestolen worden. In traditionele, gecentraliseerde omgevingen en in afgeschermde blockchain netwerken zijn er nog extra beschermlagen zoals toegangscontrole en blijft de data dus onder de controle van een of een beperkt aantal entiteiten (tenzij er een data leak is, uiteraard).

Samengevat zijn er verschillende mogelijkheden om data te beschermen m.b.v. een blockchain. De data zelf kan on-chain of off-chain bewaard worden, kan al dan niet geëncrypteerd zijn, en al dan niet gecentraliseerd bewaard worden. De keuze zal afhangen van de applicatie. En soms zullen er op de een of ander manier concessies moeten gedaan worden. Verder moeten we er ook rekening mee houden dat er mogelijks gevoelige gegevens afgeleid kunnen worden uit de meta-data op de blockchain.

Afdwingen van regels

Op de blockchain zijn we gelukkig niet gekend onder onze echte naam (of rijksregisternummer), maar onder een pseudoniem (adres). Helaas is dit een nodige maar onvoldoende vorm van bescherming. Bij een relatief eenvoudige toepassing, het transfereren van virtuele munten, zijn er al diverse deanoniemisatieaanvallen gepubliceerd. Naarmate een applicatie complexer wordt, en er meer gegevens verwerkt worden, stijgt ook de kans dat deze gegevens door een aanvaller aan een bedrijf of burger gekoppeld kunnen worden. De GDPR blijft dan ook – terecht – van toepassing op gepseudonimiseerde persoonsgegevens.

Er wordt gelukkig wel onderzoek gedaan om het ongewenst lekken van informatie naar onbevoegden te verminderen. Denk maar aan het in 2016 gelanceerde Zcash, dat dankzij het gebruik van geavanceerde cryptografie erin slaagt om bij transacties van virtuele munten zowel het adres van de zender, het adres van de ontvanger, alsook het getransfereerde bedrag te verbergen, zelfs voor de validatoren. Dit klinkt fantastisch – zeker als je criminele intenties hebt – en het is inderdaad een indrukwekkende prestatie. Maar toch komt dit tegen een prijs. Daar waar een gemiddelde transactie in Bitcoin zo’n 300 bytes groot is en in enkele milliseconden gecreëerd kan worden, wordt dit bij Zcash 2000 bytes en enkele tientallen seconden op een typische desktop PC, volgens een rapport van het R3 consortium. Bovendien is dit enkel een oplossing voor één specifieke toepassing van blockchain, namelijk het transfereren van virtuele munten.

De voorgestelde oplossing kan niet zomaar geëxtrapoleerd worden naar andere toepassingen, laat staan naar een generieke technologie zoals blockchain-based smart contracts. Er werd wel een theoretisch model uitgewerkt voor private smart contracts, dat luistert naar de naam Hawk. Tot op heden is er nog geen implementatie, laat staan benchmarks, beschikbaar. Op conceptueel niveau is er alvast één nadeel dat gedetecteerd kan worden; Private smart contracts worden uitgevoerd door een manager, die toegang heeft tot alles met betrekking tot het smart contract en dus door de betrokkenen vertrouwd moet worden. Permissioned blockchain technologieën zoals Quorum en Hyperledger Fabric laten wel toe dat een contract maar door een beperkt aantal of zelf enkel de betrokkenen gezien en uitgevoerd kan worden, maar dan is de graad van distributie natuurlijk minder. Bovendien blijkt de benadering in de praktijk niet steeds even werkbaar, zoals blijkt uit experimenten door SWIFT. Ook volgens Ripple, een van de toonaangevende spelers, is het onwaarschijnlijk dat banken in de nabije toekomst zullen overschakelen op distributed ledger technologie, waar ook blockchain toe behoort. De redenen liggen bij schaalbaarheid en privacy.

Samengevat komt het gebruik van blockchain voor het afdwingen van regels vandaag met een prijs. Ofwel hebben meerdere partijen toegang tot bepaalde, mogelijks gevoelige, gegevens, ofwel gebruik je complexe, vaak op maat gemaakte, oplossingen, die bovendien een significante impact kunnen hebben op zaken zoals efficiëntie en schaalbaarheid. Of dergelijke oplossingen op maat altijd mogelijk zijn, is trouwens niet gezegd. In de tabel hieronder geven we samenvattend een aantal mitigerende maatregelen met hun consequenties.

Conclusies

Blockchain laat toe afhankelijkheden van intermediaire partijen te reduceren. Niet langer een vertrouwde partij bewaart data, garandeert eigenschappen over data of voert regels uit, maar het blockchain netwerk. De prijs die je ervoor betaalt is transparantie, in de zin dat meerdere entiteiten toegang tot bepaalde informatie nodig hebben in het validatieproces.

Dat kan lastig zijn wat betreft confidentialiteit als we gegevens willen registreren in het blockchain netwerk, of als we het netwerk collectief regels willen laten afdwingen. Vandaag zijn er bij mijn weten nog geen generieke blockchain oplossingen die deze uitdagingen op een voldoende praktische manier aanpakken. Ik kijk alvast uit naar de komende evoluties, in het bijzonder die rond zero-knowledge proofs.

Wat bedoelen we met gedistribueerd vertrouwen?

Wat bedoelen we eigenlijk met de term “distributed trust”? Het betekent dat niet langer één enkele partij moet vertrouwd worden om in een proces tot het gewenste resultaat te komen, zonder ongewenste neveneffecten. We willen m.a.w. afhankelijkheden van één partij elimineren, of toch op zijn minst reduceren. Drie voorbeelden van dergelijke partijen vandaag:

• Als je geld op een spaarboekje staan hebt, moet je je bank vertrouwen, wat ten tijde van de bankencrisis niet evident was.
• Als je gebruik maakt van Facebook, vertrouw je erop dat de dienst beschikbaar is, afdoende beveiligd is en dat Facebook op een behoorlijke manier met je gegevens omgaat. We verwachten dat misbruik zoals door onder meer Cambridge Analytica, niet voorvallen.
• Als je vastgoed bezit, vertrouw je erop dat dit correct in het kadaster geregistreerd werd en er ook geregistreerd blijft. In Syrië dreigen mensen door een nieuwe wet de aanspraak op hun woning en grond te verliezen.

In de drie voorbeelden zijn we afhankelijk van respectievelijk een bank, een bedrijf en een overheid. We moeten hen dus vertrouwen, of we nu willen of niet. Technologieën gebaseerd op cryptografie laten toe om niet langer afhankelijk te zijn van die ene partij, maar wel van een netwerk. En zolang de meerderheid van dat netwerk eerlijk is, loopt alles zoals het hoort. Dat is wat we bedoelen met gedistribueerd vertrouwen.

Er is een stelling uit de cryptografie, die als volgt luidt: “Elke berekening die kan berekend worden met een centrale autoriteit kan ook berekend worden zonder.” Wat algemener geformuleerd wordt dit: “Alles wat met een centrale autoriteit gedaan kan worden, kan ook zonder die autoriteit gedaan worden.” Bitcoin en blockchain hebben de verdienste dit idee gepopulariseerd te hebben. Dit betekent echter niet dat blockchain de enige en zaligmakende oplossing is. Blockchain is een specifiek concept dat distributed trust mogelijk maakt.

Wat kan blockchain wel en niet?

Laat ons eerst even scherp definiëren naar wat we met blockchain technologie kunnen. Het laat ons toe om drie zaken zonder vertrouwde autoriteit te regelen:

1. Het beschermen van data. Blockchain kan garanties bieden wat betreft de integriteit, onweerlegbaarheid en zelfs authenticiteit van gegeven. Ook is er achteraf geen antidatering mogelijk of betwisting over het moment van registratie. Denk bijvoorbeeld aan het registreren van diploma’s en testamenten op de blockchain.
2. Het transfereren van activa. Bitcoin laat toe om, zonder bank, waarde (virtuele valuta) uit te wisselen, maar met blockchain kan in principe om het even wat van waarde uitgewisseld worden, gaande van auteursrechten en domeinnamen tot diamanten en vastgoed. Eigenlijk wordt hier een simpele regel collectief door het netwerk afgedwongen: is de zender ook de eigenaar van de activa die hij wil transfereren”. Dit kan dus gezien worden als een specifieke, beperkte toepassing van het volgende puntje.
3. Het afdwingen van regels. In blockchain netwerken wordt een set van regels collectief (gedistribueerd) afgedwongen. Met smart contracts kan dit ook voor willekeurige code. Geen enkele entiteit in het netwerk kan op zichzelf de correcte uitvoering ervan beïnvloeden. Een smart contract kan bovendien activa op de blockchain ontvangen, blokkeren en transfereren. Vaak komt het neer op het volgende: “Indien aan voorwaarden A & B voldaan, transfereer activa naar X.”

Wat kan blockchain niet? In het geval gegevens in de blockchain geregistreerd worden kan het blockchain netwerk niet de correctheid van deze gegevens verifiëren, tenzij alle data voor die verificatie zich reeds op de blockchain bevinden. Een blockchain netwerk kan dus wel verifiëren of een Bitcoin transactie geldig is, maar weet niet of het huwelijkscontract of het diploma dat op de blockchain geregistreerd wordt, effectief correct, geldig of waar is. Stel dat er een smart contract je automatisch een bedrag uitbetaalt als je vlucht vertraging heeft, dan moet er informatie over de vluchten aan het smart contract aangeleverd worden. Het smart contract kan niet nagaan of de aangeleverde informatie correct is. Foutieve input resulteert dus in foutieve output. Of, samengevat: “Rommel in, rommel uit”. Een blockchain is dus niet per se een bron van waarheid, zoals het weleens, ietwat religieus, uitgedrukt wordt.

Dezelfde informatie kan natuurlijk ook door verschillende partijen aangeleverd worden. Naarmate meer partijen onafhankelijk van elkaar hetzelfde zeggen, hebben we een hogere graad van vertrouwen in de correctheid van de informatie. Wanneer je verhuist, zal een agent langskomen om te bevestigen dat je daar effectief woont. Stel dat dit in de toekomst niet langer door een agent gebeurt, maar door verschillende burgers en bedrijven. Je buren bevestigen dat je daar effectief woont, alsook pakjesbezorgers en nutsbedrijven. Het bevestigen van informatie gebeurt hier dus gedistribueerd, maar dit heeft op zich niets te maken met blockchain. Al deze entiteiten kunnen dit evengoed op een gecentraliseerde service aangeven. Het collectief valideren van externe aangeleverde informatie heeft dus niets met blockchain te maken. Dit gebeurt al jaren bij crowdsourcing, waarvan Wikipedia het meest gekende voorbeeld is. Een collectieve validatie van externe informatie is dus in zekere zin complementair met blockchain en kan er dus mee gecombineerd worden.

Zonder vertrouwensissue, is er weinig reden om blockchain technologie te kiezen. Dit betekent niet dat als dat er wel is, er automatisch voor blockchain gekozen moet worden. Stel dat een aantal concurrerende partijen en een overheidsbedrijf moeten samenwerken en dat geen van deze partijen in het proces geëlimineerd kan worden. De banken vertrouwen elkaar niet, dus er is een vertrouwensissue. Maar als ze allen het overheidsbedrijf vertrouwen, is er mogelijks een alternatief voor een blockchain benadering, op basis van traditionele technologie, waarbij de banken dan wel afhankelijk worden van het overheidsbedrijf. Het is dan aan het consortium om een keuze te maken.

Gedistribueerd vertrouwen betekent trouwens niet dat de noodzaak aan vertrouwen verdwijnt. Of, anders geformuleerd, “distributed trust” impliceert niet “trustlessness”. We moeten er nog steeds op vertrouwen dat een meerderheid eerlijk is, dat er geen security kwetsbaarheden in de software van de client of inhet smart contract zitten, dat het smart contract doet wat de makers beloven, dat de cryptografische assumpties waar alles op steunt correct zijn en blijven, dat de orakels – de entiteiten die data aanleveren aan de blockchain – hun werk correct doen, dat we onze private sleutel niet verliezen, dat het bedrijf dat onze virtuele munten beheert niet gehackt wordt, … Ik ben dus niet overtuigd van de populaire stelling dat blockchain “trustless” of “vertrouwensvrij” zou zijn. Er is nog steeds vertrouwen vereist, maar op een minder zichtbaar, abstracter en daardoor minder inzichtelijk niveau.

Is gedistribueerd vertrouwen steeds goedkoper?

Het reduceren van afhankelijkheden m.b.v. blockchain technologie impliceert niet per se dat het proces ook goedkoper wordt, hoewel dat uiteraard wel mogelijk is. We verduidelijken dit a.d.h.v. twee voorbeelden.

Op het moment van schrijven was de kost van een gemiddelde Bitcoin transactie terug gezakt tot ongeveer een dollar, na een piek op 22 december met een daggemiddelde van 55 dollar. Deze bedragen zijn onafhankelijk van het te transfereren bedrag. Om je euro’s in bitcoins om te zetten wordt er trouwens nog een percentage door de handelsplatformen aangerekend. Zelfs ten tijde van de piek was het gebruik van bitcoin veelal nog goedkoper voor internationale transacties dan de klassieke weg. Lokaal een klein bedrag met bitcoin uitgeven is, in vergelijking met de bestaande, gencentraliseerde systemen dan weer erg duur. Er zijn nog andere virtuele munten met lagere transactievergoedingen, maar Bitcoin is vandaag wel de referentie. Bovendien hangt aan het gebruik van Bitcoin een stevige ecologische kost. IOTA is een crypto munt die niet gebaseerd is op blockchain. Er wordt geen transactievergoeding aangerekend, maar er wordt wel van je gevraagd een inspanning te doen in de vorm van computerkracht, door een kleine cryptografische puzzel op te lossen.

Een tweede voorbeeld vinden we in Nederland. Door de Nederlandse gemeente Stichtse Vest werd bekeken of blockchain een meerwaarde kan bieden bij het aanvragen van een rolstoel. Daarbij zijn, naast de burger, het gemeentebestuur en verschillende zorgaanbieders betrokken. Ze maakten de vergelijking: wat als we dit regelen m.b.v. een publieke blockchain, een afgeschermde (private) blockchain of een traditionele centrale database. Het resultaat is te zien in onderstaande tabel. Een centrale database heeft een lagere infrastructuurkost en complexiteit dan een afgeschermde blockchain. Ook wanneer gebruik gemaakt wordt van een publieke blockchain, is de complexiteit hoger volgens de tabel en zal je moeten betalen per actie. Die prijs fluctueert trouwens constant, afhankelijk van hoe verzadigd het netwerk is, en hoe snel je de actie op de blockchain geregistreerd wil krijgen.

Het distribueren van vertrouwen leidt dus niet per se tot een afname van de kosten.

Om de balans in dit artikel te herstellen, zou ik nog een positief voorbeeld willen aanhalen. In Jordanië is er een cash-for-food programma, georganiseerd door de WFP (World Food Programme), dat 100 000 Syrische vluchtelingen helpt. Dankzij een oplossing die onder meer gebruik maakt van blockchain, zouden de transactiekosten, die nu naar lokale banken gaan, met 98% verminderen.

Afronding

Dit artikel ging in op wat we bedoelen met gedistribueerd vertrouwen. Het komt erop neer dat we afhankelijkheden van één partij willen reduceren, zonder dat de noodzaak aan vertrouwen volledig verdwijnt. Verder werd ingegaan op wat blockhain op conceptueel niveau wel en niet kan. Een dergelijke benadering is trouwens niet steeds goedkoper dan een traditionele benadering.

Het volgende artikel gaat in op wat blockchain wel kan: het beschermen van data en het afdwingen van regels (met inbegrip van transfereren van activa). Kan blockchain dit compromisloos? Of is er toch een bepaalde prijs die we moeten betalen? We zullen zien dat de combinatie van blockchain om vertrouwen te distribueren aan de ene kant, en confidentialiteit (bijvoorbeeld om de privacy van de burger te beschermen) aan de andere kant vandaag een niet evidente evenwichtsoefening is.

Intro

Een traditioneel contract beschrijft in menselijke taal, op papier afspraken tussen meerdere partijen. Dit contract is ingebed in een wettelijk kader zodat juridische stappen ondernomen kunnen worden indien één of meer partijen de gemaakte afspraken niet nakomen. Bovendien is er soms een intermediaire partij vereist, de notaris, bijvoorbeeld bij de transactie van vastgoed.

Een smart contract op een blockchain is code die afspraken tussen meerdere partijen beschrijft. Doordat deze code autonoom op de blockchain draait, is er geen wetgever of notaris die we moeten vertrouwen voor de correcte uitvoering van het contract. Drie essentiële eigenschappen van een smart contract zijn dus:

• Gecodeerd. De in menselijke taal geschreven clausules die we in een traditioneel contract en in wetteksten vinden zijn in een smart contract vervangen door code.
• Gedistribueerd. In tegenstelling tot traditionele contracten is er geen, of in elk geval minder, nood aan vertrouwde instanties zoals de wetgever of de notaris. In de plaats daarvan vertrouwen we op het gedistribueerde blockchain netwerk dat correct blijft functioneren, zelfs indien een deel van de netwerk nodes (deelnemers) vals probeert te spelen.
• Efficiënt. Traditionele contracten vereisen dat de betrokken partijen zelf de in het contract vastgelegde afspraken implementeren, wat extra tijd, energie en geld kost en bovendien gepaard kan gaan met fouten. Smart contracts zijn zelf al die implementatie.

De twee bekendste blockchain platformen zijn Ethereum en Hyperledger. Ze zijn beiden open source en in volle ontwikkeling. Ethereum werd officieel gelanceerd in juli 2015 en is, net zoals Bitcoin, gebaseerd op een unpermissioned blockchain, wat wil zeggen dat iedereen toegang heeft tot de blockchain en kan meewerken aan de creatie van nieuwe blokken. Hyperledger is wat jonger, het bestaat sinds december 2015, en heeft ondersteuning van heel wat bedrijven waaronder IBM. Het is gebaseerd op een permissioned blockchain, wat wil zeggen dat slechts een geselecteerde set van participanten toegang heeft tot de blockchain en kan deelnemen aan het blokcreatieproces. Het blokcreatieproces bij Permissioned blockchains is enerzijds een pak efficiënter, maar anderzijds meer gecentraliseerd.

Een smart contract bestaat uit een aantal functies, waarvan een deel publiek is en zo de interface vormt. De publieke functies kunnen aangeroepen worden door deelnemers in het netwerk. Deze functies zullen typisch de toestand van het contract veranderen. Die toestand bevat de gegevens die nodig zijn voor de correcte uitvoering van het contract. Ten slotte kan een contract ook waarde ontvangen, beheren, en verder transfereren. Deze waarde wordt uitgedrukt in de crypto munteenheid van de onderliggende blockchain. We verduidelijken dit alles aan de hand van een aantal voorbeelden.

Voorbeelden

Een eerste voorbeeld is een crowdfunding campagne, waarbij een bepaald bedrag opgehaald moet worden tegen een vooropgestelde datum. Iedereen kan een storting doen via een contribute() functie in het crowdfunding contract. Samen met deze functie-oproep wordt een bedrag meegegeven. De toestand van het contract houdt onder meer bij wie welk bedrag gestort heeft. Wanneer de crowdfunding campagne afgelopen is, zijn er twee mogelijkheden. 1) Het vooropgestelde bedrag werd gehaald en de begunstigde krijgt door het uitvoeren van de settle() functie al het ingezamelde geld. 2) Het vooropgestelde bedrag werd niet gehaald, en het contract betaalt iedereen terug.

Een tweede voorbeeld is een veiling. Via een smart contract kunnen alle deelnemers bieden via een bid() functie in het contract, waarbij het geboden bedrag in een crypto munt al direct meegegeven wordt. De toestand van het contract houdt bij wie de hoogste bieder is en het bedrag van het hoogste bod. Pas wanneer iemand je overbiedt, krijg je het door jou geboden bedrag door het contract teruggestort. Op het einde van de veiling gaat het bedrag van de hoogste bieder naar de aanbieder.

Een derde voorbeeld zijn verkiezingen. De toestand van het contract houdt onder meer bij wie stemrecht heeft, wie reeds gestemd heeft en wat de keuzemogelijkheden bij het stemmen zijn. Iedereen kan via een vote() functie zijn stem uitbrengen, waarbij het contract nagaat of de persoon reeds gestemd heeft. Nadat iedereen de kans gehad heeft om te stemmen, kan het resultaat gegeven worden via de getResult() functie, wat de omslachtige procedures bij het tellen van de stemmen overbodig maakt. Bij dit voorbeeld is privacy erg belangrijk, wat momenteel één van de grote uitdagingen in het blockchain verhaal is.

De term contract moet in deze context dus op een ruime manier geïnterpreteerd worden. Het gaat hier om elke mogelijke overeenkomst tussen meerdere partijen, ook al wordt daarbij in de traditionele context geen apart contract ondertekend.

Werkingsprincipe

Elke node die betrokken is in het blokcreatieproces, kortweg de validating node, verzamelt alle nieuw gecreëerde transacties die bestemd zijn voor een nieuw te creëren blok. De validating node kijkt in de transacties welke functies in welke contracten moeten aangeroepen worden en voert die dan vervolgens lokaal uit, waardoor hij lokaal een nieuwe toestand krijgt voor de betrokken contracten. Een update van die toestand wordt aan het nieuw te creëren blok toegevoegd. Elk blok bevat dus naast een header en een set van transacties ook updates van contracttoestanden.

Op het eerste zicht lijkt het alsof we de validating nodes moeten vertrouwen. Dit is niet het geval gezien ook andere nodes de correctheid van een nieuw blok zullen controleren alvorens het aan de eigen kopie van de blockchain toe te voegen en het verder te verspreiden in het netwerk. Deze nodes gaan dus onder meer na of het toepassen op de vorige contracttoestanden van de transacties in het blok resulteert in de geregistreerde updates. Een validating node die niet de correcte contracttoestanden registreert valt dus door de mand. Bovendien krijgt een validating node doorgaans, zeker op unpermissioned blockchains, een beloning voor het geleverde werk. Indien het door hem gecreëerde blok niet aanvaard wordt, krijgt hij ook geen beloning. Op die manier wordt vertrouwen gedistribueerd over de community en is er niet langer nood aan één centrale autoriteit. We beschikken op deze manier dus over rekenkracht op een blockchain.

Vertrouwde externe bronnen

Er zijn voorbeelden te bedenken waarbij smart contracts informatie nodig hebben van vertrouwde, externe bronnen. Deze bronnen kunnen intelligente IoT toestellen zijn, maar eveneens organisaties die bijvoorbeeld wissel- en beurskoersen doorgeven. We geven twee voorbeelden om dit te verduidelijken.

Stel dat een slager een smart contract gebruikt bij een transport van een bestelling vlees. De slager wil enkel betalen indien de temperatuur in de laadruimte van de koelwagen nooit boven de 8°C gestegen is. Hij stort met de order() functie het gevraagde bedrag naar het smart contract. Er bevindt zich in de koelruimte van de vrachtwagen een IoT-sensor. Deze sensor wordt geregistreerd in het contract en geeft vanaf dan elke 5 minuten de maximum gemeten temperatuur door aan het smart contract via een updateTemperature() functie. De maximum temperatuur wordt in de toestand van het contract bewaard. Bij levering voert de slager de confirmDelivery() functie uit. Indien de temperatuur op een gegeven moment tijdens de rit boven de 8°C gestegen is, krijgt de slager daarmee het gestorte bedrag terugbetaald, indien dit niet het geval is, krijgt de transporteur het volledige bedrag.

Een ander voorbeeld zijn smart electricity meters. Een gezin stort via een pay() functie geregeld bedragen op een smart contract en de smart electricity meter geeft elke dag het verbruik van het gezin door aan het smart contract via een updateConsumption() functie. Het smart contract berekent of het gezin voldoende geld naar het smart contract getransfereerd heeft. Enkel dan laat de smart electricity meter toe dat het gezin meer dan het wettelijk minimum aan elektriciteit verbruikt. Gelijkaardig kunnen we denken aan een intelligent slot in een geleasde wagen, dat de wagen enkel start indien er voldoende op het smart contract gestort werd en de wagen niet als gestolen gesignaleerd staat.

Uitdagingen

De bovenstaande voorbeelden zijn vrij eenvoudig, maar geven wel al een feeling van het potentieel van smart contracts. Toch is er een gevaar dat niet zomaar onder de mat geschoven mag worden. Wanneer traditionele software een bug bevat, kan dit gecorrigeerd worden d.m.v. een patch. Maar een smart contract wordt gepubliceerd op de blockchain, is dus onveranderlijk en kan dus niet gepatcht worden. Een rigoreuze aanpak bij het schrijven en testen van een contract is dus onontbeerlijk, maar zelfs dat is geen garantie.

Dit hebben we kunnen vaststellen met The DAO; een crowdfunding contract dat op 30 april 2016 gepubliceerd werd op het publieke Ethereum netwerk. Op 21 mei had het reeds meer dan 150 miljoen dollar verzameld, afkomstig van meer dan 11000 investeerders. Het werd daarmee de grootste crowdfunding campagne ooit. En hoewel het contract door experts nagekeken was, bevatte het een bug. Op 17 juni 2016 werd het gehackt, waardoor op twee dagen tijd ongeveer één derde van het totale bedrag in handen kwam van de hacker (of hackersgroep). Dit leidde tot twee kampen in de Ethereum community en tot een split van de publieke Ethereum blockchain. Het grootste deel van de community besliste om het meest recente deel van de blockchain tot voor de hack te vergeten door verder te bouwen op een ouder blok i.p.v. het meest recente. Op die manier werd een nieuw heden gecreëerd waarin de hack nooit heeft plaatsgevonden, zoals geïllustreerd in onderstaande figuur. Een deel van de community bleef echter voortbouwen op de oude tak van de blockchain. In de ene tak heeft de hack wel plaatsgevonden, in de andere niet.

Door deze actie van de meerderheid kreeg het vertrouwen in de blockchain als onveranderbare, betrouwbare database natuurlijk een serieuze deuk. Veelal zal een dergelijke interventie gelukkig geen optie zijn. En in een dergelijke situatie is een klassiek wettelijk kader het enige dat nog overblijft om de hacker te vervolgen en de verliezen te recupereren.

Gelieerd daarmee is de vraag hoe mensen zonder programmeerkennis toch, en liefst op een eenvoudige en snelle manier, inzicht kunnen krijgen in de werking van een smart contract, zonder al te veel vertrouwen in autoriteiten zoals experts die het contract reviewden. Smart contracts horen immers de transparantie te vergroten en mogen dus absoluut geen de facto black box worden voor haar gebruikers.

Daarnaast blijven er de meer algemene blockchain uitdagingen. Zo heeft elke gebruiker van een smart contract een eigen private sleutel nodig, die op een voldoende veilige manier beschermd moet worden. Daar waar bij gecentraliseerde databases ook de beveiliging gecentraliseerd is, verschuift bij blockchain die beveiliging naar bescherming van de sleutels op de end-points.

Daarnaast moeten we absoluut vermijden dat smart contracts gevoelige gegevens en meer specifiek persoonsgegevens lekken naar onbevoegden. Een smart contract voor studentenarbeid zou bijvoorbeeld in de contract status kunnen bijhouden hoeveel een jobstudent dit jaar reeds verdiend heeft, hoeveel dagen hij dit jaar en hoeveel uur hij dit kwartaal al gewerkt heeft. Deze gegevens en elke update staan onvercijferd in de blockchain en zijn dus voor iedereen die toegang heeft tot de blockchain zichtbaar. Het vervangen van identifiers zoals het rijksregisternummer door pseudoniemen (adressen in blockchain terminologie) is hierbij een noodzakelijke maar onvoldoende voorwaarde.

Conclusie

Vandaag pakken bedrijven graag uit met proofs of concept gebaseerd op een blockchain. Operationele systemen blijven nog zeldzaam. Bovendien is een vaak gehoorde opmerking dat er alternatieve, betere maar wel meer gecentraliseerde aanpakken bestaan om tot een applicatie te komen met dezelfde of gelijkaardige eigenschappen. Toch is deze opmerking niet helemaal eerlijk, gezien mature met zeer prille technologie vergeleken wordt. Vandaar dat we nu eerder in een fase van experimenteren zitten.

Volgens sommigen zullen smart contracts qua impact vergelijkbaar zijn met het internet zelf, en zullen nieuwe organisatievormen mogelijk worden. Autonome bedrijven zullen geprogrammeerd kunnen worden als een smart contract en autonoom beslissingen nemen, mede op basis van artificiële intelligentie en het Internet of Things. Een eerste experiment van een dergelijke autonome organisatie was The DAO, die ik reeds eerder vermeldde, waarbij je een soort aandeelhouder wordt door cryptografisch geld op het contract te storten. Er kunnen projectvoorstellen ingestuurd worden en naarmate een aandeelhouder meer geld gestort heeft, heeft hij een zwaarder gewicht bij het beslissen of er al dan niet geld zal geïnvesteerd worden in het voorgestelde project.

Toch lijkt het niet onlogisch dat in vele gevallen slechts een deel van een traditioneel contract of bedrijfsvoering op een smart contract kan gebeuren. Sommige afspraken en regels zijn niet zomaar in code vast te leggen en kunnen een menselijke beoordeling vereisen.

Blockchains en smart contracts zijn een enorme hype en zullen misschien niet alle verwachtingen kunnen inlossen. Toch heeft dit het voordeel dat er momenteel honderden miljoenen in geïnvesteerd worden, onder meer om de uitdagingen aan te pakken. Daarbij zien we een verhoogde interesse in cryptografische technieken die in de laatste decennia ontwikkeld zijn. Deze technieken maken zaken mogelijk die intuïtief onmogelijk lijken, maar dit gaat wel ten koste van efficiëntie. Denken we maar aan homomorfische encryptie. Naarmate de tijd vordert, zullen dus enerzijds de mogelijkheden toenemen, maar zullen anderzijds ook fundamentele beperkingen duidelijker naar voor komen.

Smart contracts vergroten het potentieel van blockchains enorm. Daar waar blockchain 1.0 zich beperkte tot gedistribueerde opslag zonder een vertrouwde controlerende partij (autonome opslag), laat blockchain 2.0 ook het uitvoeren van willekeurige code zonder centrale, controlerende partij toe (autonome berekeningen), wat vrij revolutionair is en het huidige model met vertrouwde partijen zwaar door elkaar kan schudden. Volgens Forbes zal blockchain dan ook gezien worden als een mijlpaal in de evolutie weg van gesloten, gecentraliseerde systemen, richting open, gedistribueerde systemen.

Indien u als overheidsinstelling vragen heeft i.v.m. blockchain en smart contracts kunt u mailen naar kristof.verslype [at] smals.be