Blockchain wordt gezien als een disruptieve technologie die de komende jaren een grote impact zal hebben, ook in overheidscontext. Veel bedrijven en overheden zullen dan ook geconfronteerd worden met de vraag of blockchain technologie een meerwaarde kan hebben bij de ontwikkeling van applicaties. Deze vraag wordt het best bekeken per applicatie, dus case per case. Dit is uiteraard niet evident zonder een grondige kennis van de mogelijkheden en uitdagingen van blockchain. Bovendien is hierbij doorgaans een grondige cryptografische expertise vereist. Om overheden hierbij te ondersteunen, stelt Smals Research in deze blogpost daarom een richtinggevend beslissingsmodel voor. Indien volgens dit model blockchain mogelijks een goede piste is, gaan we graag met u, als overheid, in gesprek om uw applicatie of idee meer in detail te bekijken en de haalbaarheid van een blockchain benadering na te gaan.
De blockchain technologie is nog jong en evolueert snel. Vandaar dat we ook openstaan om dit model op basis van uw feedback verder te verfijnen.
Een overzicht van het model wordt gegeven in onderstaande figuur. Er worden zes vragen gesteld die we in de rest van deze tekst zullen bespreken.
1. Do multiple parties need to interact with each other and does this result in the storage of data that should stay accessible by multiple entities?
De eerste vraag die we ons stellen is of er in de applicatie meerdere entiteiten met elkaar interageren, waarbij een interactie resulteert in data die voor meerdere entiteiten toegankelijk moeten blijven. Indien dit niet het geval is, is er weinig reden om een blockchain te gebruiken.
2. Low performance write operations (in seconds, not milliseconds)?
Indien snelle schrijfoperaties nodig zijn, is het waarschijnlijk geen goed idee om een blockchain te gebruiken. Blockchain technologie is bijvoorbeeld niet geschikt voor high-frequency trading, wat toelaat om aandelen en andere financiële instrumenten aan zeer hoge snelheden te verhandelen. Bitcoin, de killer applicatie voor blockchain, creëert een nieuw blok met daarin de meest recente transacties elke tien minuten en pas na een uur hebben we voldoende vertrouwen dat de transactie definitief in de Bitcoin blockchain opgenomen is. Er bestaan snellere blockchains, zoals Ethereum dat gemiddeld elke 10 seconden een nieuw blok creëert, maar ook dit is nog steeds veel te traag voor high-speed schrijfoperaties.
3. Is a traditional centralized approach, resulting in a trusted, all-knowing party, suboptimal?
De derde vraag gaat over het vertrouwensmodel. Misschien is er geen enkel bezwaar tegen een gecentraliseerde aanpak, waarbij de centrale partij absoluut vertrouwd wordt, alles kent en alles kan. Dan is er een goede kans dat een gecentraliseerde aanpak eenvoudiger en/of sneller zal zijn dan een blockchain benadering. Hou er wel rekening mee dat een dergelijke gecentraliseerde aanpak kwetsbaar is voor data breaches, wat dramatische gevolgen kan hebben en vermeden wordt in een blockchain benadering. Bovendien brengen bij een gecentraliseerde aanpak de vereisten voor hoge beschikbaarheid en sterke beveiliging extra kosten met zich mee. Anderzijds is in een blockchain benadering elke entiteit zelf verantwoordelijk voor de bescherming van zijn eigen private sleutel.
Voor Bitcoin is onafhankelijkheid van banken d.m.v. decentralisatie cruciaal en een belangrijke reden van haar succes. Anderzijds is de meerwaarde van een blockchain voor een gecentraliseerde overheidstoepassing zoals student@work, die studenten informeert over onder meer het aantal dagen dat ze nog mogen werken, al beperkter [1].
Indien er op vraag 3 positief geantwoord is, komen we terecht in een benadering die niet gecentraliseerd is. Het traditionele alternatief op een gecentraliseerde aanpak is een gedecentraliseerde aanpak, waarbij meerdere, maar nog steeds een beperkt aantal systemen vertrouwd worden en met elkaar interageren om business goals te realiseren. Een fictief voorbeeld zou de gedistribueerde verwerking van medische voorschriften kunnen zijn. Daarbij nemen we aan dat een centrale aanpak omwille van politieke redenen niet wenselijk was. Het RIZIV is hierbij betrokken, de zeven mutualiteiten, een handvol tariferingsdiensten, ongeveer 5.000 apothekers en meer dan 50.000 artsen.
In de context van een niet-gecentraliseerde aanpak volgen vragen 4.1, 4.2 en 4.3 die onafhankelijk van elkaar gesteld worden. Naarmate er op deze vragen meer en sterkere bevestigingen volgen, wordt het gebruik van blockchain technologie veelbelovender.
4.1. Are transparency, verifiability and/or auditability important?
In een gedistribueerd systeem is er nog steeds vertrouwen nodig in een aantal partijen. Elke van deze spelers kan bijvoorbeeld instaan voor een specifiek aspect van een business proces. Transparantie en verifieerbaarheid zorgen er in dit geval voor dat ook anderen kunnen verifiëren of deze spelers hun werk goed doen. De blockchain laat zo ook toe dat de verschillende vertrouwde partijen elkaar kunnen controleren. Deze controles kunnen in real-time of achteraf gebeuren. In het geval van medische voorschriften kunnen burgers nagaan of hun mutualiteit hun medische voorschriften correct verwerkt heeft, zodat de patient enkel het remgeld moet betalen bij de apotheker. Het RIZIV kan dan weer in real-time fraude analyse doen. We kunnen ons ook inbeelden dat de data op de blockchain omwille van confidentialiteitsredenen geëncrypteerd zijn, waardoor het aspect van transparantie wegvalt. Eventueel kan dan een auditor leesrechten gegeven worden tot (een deel van) de gegevens.
4.2. Does a traditional decentralized approach result in data consistency issues and/or complex information flows?
Een gevaar bij een traditionele, gedecentraliseerde benadering is het ontstaan van complexe informatiestromen, wat in de praktijk omslachtig kan worden. Bovendien heeft in een dergelijke benadering typisch elke betrokken partij een eigen database die up-to-date gehouden moet worden, wat kan leiden tot consistentie issues. Verschillende partijen kunnen bijvoorbeeld business rules op een net iets andere manier implementeren. Een blockchain benadering vermijdt zowel complexe interacties als consistentie issues over verschillende databases heen. Iedereen met een lokale kopie van de blockchain heeft immers dezelfde data. Dit wordt gegarandeerd door het onderliggende blockchain consensus mechanisme. Bovendien hoeven met smart contracts business rules maar één keer gedefinieerd te worden, waardoor inconsistenties minder waarschijnlijk worden.
4.3. Do we have relatively simple & static business rules between multiple parties?
Smart contracts laten m.b.v. een blockchain toe om regels tussen verschillende partijen af te dwingen zonder centrale partij. Helaas komt dit tegen een prijs. De variabelen die daarbij betrokken zijn moeten zich in een smart contract bevinden. Dit maakt het lastig om complexe regels, waarbij veel data of vaak veranderende data betrokken is, op die manier af te dwingen. Elke wijziging van data gebeurt immers via een transactie die permanent in de blockchain terechtkomt en complexe data structuren vereisen meer resources van de full nodes (de entiteiten die een volledige kopie van de blockchain bijhouden). Bovendien zijn al deze contractvariabelen, alsook hun volledige historiek, leesbaar voor iedereen die toegang heeft tot de blockchain. Het afdwingen van regels in een smart contract wordt dus een grotere uitdaging wanneer er ook confidentiële gegevens, zoals persoonsgegevens, door het contract opgeslagen en verwerkt worden. Als alternatief kunnen de data geëncrypteerd naar de blockchain geschreven worden en kunnen de business rules lokaal toegepast worden, maar dat maakt het gebruik van een blockchain dan weer minder interessant, gezien de voordelen van smart contracts verloren gaan. Ten slotte kan een smart contract niet gewijzigd worden. Telkens wanneer een regel verandert moet er dus een nieuw smart contract gecreëerd worden, wat al snel omslachtig wordt.
In deze blogpost hebben we een eenvoudig model voorgesteld om overheden te helpen bij het antwoorden op de vraag wanneer blockchain technologie een meerwaarde kan hebben bij de ontwikkeling van applicaties. Voor een meer diepgaande analyse van uw mogelijke blockchain applicatie of voor suggesties i.v.m. het voorgestelde beslissingsmodel kunt u contact opnemen met Smals Research (kristof [punt] verslype [at] smals [punt] be).
[1] Het wordt al interessanter wanneer het aantal dagen en uren dat een student nog mag werken op een blockchain berekend wordt op basis van aangiften die door werknemers op die blockchain geplaatst worden.
Leave a Reply