BLOCKCHAIN EN SMART CONTRACTS IN DE VERZEKERINGSSECTOR: JURIDISCHE ASPECTEN

BLOCKCHAIN EN SMART CONTRACTS
IN DE VERZEKERINGSSECTOR
JURIDISCHE ASPECTEN
Aantal woorden: 34.911
Jan De Vleeschouwer
Studentennummer: 01104692
Promotor: Prof. dr. Kristiaan Bernauw
Copromotor: Prof. dr. Jean Rogge
Masterproefscriptie voorgelegd voor het behalen van de graad master in de richting Master in de rechten
Academiejaar: 2018 - 2019
Inhoudstafel
Voorwoord .............................................................................................................................................. 4
Overzicht ................................................................................................................................................. 1
Deel 1: Blockchain: wat, hoe en waarom? .............................................................................................. 3
1. Inleiding ........................................................................................................................................... 3
2. De noodzakelijke basis om blockchain als volstrekte leek te begrijpen.......................................... 4
2.1. Software-architectuur en de relatie met blockchain ............................................................... 6
2.2. De voor- en nadelen van gedistribueerde systemen ............................................................... 8
2.3 Peer-to-Peer (P2P) systemen, een specifieke variant op gedistribueerde systemen ............... 9
2.4. Een mix van beide types software-architectuur (hybride architecturen) .............................. 10
2.5. Kernonderscheid tussen centraal- & gedistribueerd systeem ............................................... 11
2.6. Het nut van blockchain ........................................................................................................... 11
2.7. Welk probleem probeert Blockchain te verhelpen en waarom is het zo belangrijk om dit te
verhelpen? ..................................................................................................................................... 12
2.8. De term ‘Blockchain’ .............................................................................................................. 13
2.9. Het beheer van eigendom als meest besproken applicatie van blockchain .......................... 14
2.10. Het dubbel-uitgave probleem (double spending problem) .................................................. 17
2.11. Hoe worden gegevens (betreffende eigenaarschap) praktisch opgeslaan bij blockchain? . 18
2.12. Hashwaarden & hashfuncties............................................................................................... 19
2.13. Hashreferenties .................................................................................................................... 21
2.14. Data bewaren in een omgeving gevoelig voor veranderingen ............................................ 23
2.15 Hashpuzzels ........................................................................................................................... 25
2.16 Cryptografie ........................................................................................................................... 27
2.17 Digitale handtekening als autorisatie van transacties binnen de blockchain ....................... 30
2.18 Wijzen van gebruik van digitale handtekening ..................................................................... 33
2.19 Het bewaren van transactiedata op een veilige manier d.m.v. de blockchainstructuur ...... 34
2.20 Het beveiligen van de opgeslagen data in de blockchain ..................................................... 41
2.21 De communicatie tussen de computers ................................................................................ 45
2.22 De meest voorkomende misbruiken door oneerlijke spelers in de blockchain .................... 49
2.23 De transactiehistorie(s) ......................................................................................................... 50
2.24 Fraudegevoeligheid van collectieve beslissingen .................................................................. 58
2.25 Het complete plaatje van wat blockchain nu eigenlijk is ...................................................... 61
2.26 Abstractie maken................................................................................................................... 71
2.27 Hoe kunnen de beperkingen van de blockchain overtroffen worden ?................................ 72
2.28 De noodzaak van vier types blockchain ................................................................................ 77
2.29 De blockchain en haar mogelijke toepassingen in het echte leven ...................................... 82
Deel 2: Smart contracts ......................................................................................................................... 85
1. Inleiding ......................................................................................................................................... 85
2. Orakels ........................................................................................................................................... 85
3. Ricardiaans contract of smart legal contract ................................................................................ 87
4. Voorbeelden uit de praktijk........................................................................................................... 88
Deel 3: De verzekeringssector ............................................................................................................... 91
1. De relevantie van blockchain en smart contracts in de verzekeringssector ................................. 91
2. Het Belgisch verzekeringscontractenrecht .................................................................................... 93
2.1. Algemeen................................................................................................................................ 93
2.2. Verzekeringsovereenkomsten op afstand gesloten ............................................................... 94
3.2. Recht van de elektronische economie (Boek XII WER) .......................................................... 96
4. Gedaan met in concreto beoordelingen met smart (verzekerings)contracten? Een ode aan het
rechtszekerheidsbeginsel .................................................................................................................. 96
5. Blockchain als vervanger van bewijs via geschrift? (art. 64 W. Verz.) ........................................ 100
6. Personalisatie van de dekking en de premie? Segmentatie 2.0? (Titel 3, hoofdstuk 2 W. Verz.)104
7. Anonimiteit op een blockchain. Onoverkomelijk… of toch niet? ................................................ 106
Deel 4: Conclusie ................................................................................................................................. 108
Bibliografie .......................................................................................................................................... 110
BIJLAGEN ............................................................................................................................................. 119
Bijlage I: Vragenlijst betreffende een onderzoek naar de voordelen die een blockchain en/of smart
contracts potentieel te bieden hebben binnen de verzekeringssector – beantwoord door Bart Van
Buggenhout (Development business manager, KBC Bank & Verzekering), Joeri Jackers (Blockchain
developer, KBC Bank & Verzekering) & Matthieu Merlyn (Blockchain developer, KBC Bank &
Verzekering) .................................................................................................................................... 119
Bijlage II: Interview Johan De Vleeschouwer (Verzekeringsagent DVV – Zelfstandig Agentenkorps CVBA DRS-Zakenkantoor (De Rocker – Smet) te Heusden) ............................................................ 122
Voorwoord
Deze masterscriptie vormt het slotstuk van mijn 5-jarige opleiding Rechten aan de Universiteit van
Gent. Het was een verrijkende periode die in grote mate bijgedragen heeft aan de intellectuele
vorming van mijzelf als persoon. Het schrijven van deze thesis heb ikzelf ervaren als een moeilijke
opgave. Het heeft mij nochtans wel gesterkt als mens om niet meteen op te geven en te blijven geloven
in je eigen kunnen. Hiervoor wens ik allereerst mijn promotor, professor Dr. Bernauw Kristiaan, te
bedanken om mij het interessante en actuele onderwerp van blockchain en smart contracts aan te
reiken. Bovendien was hij het die de interesse voor het verzekeringsrecht tijdens de lessen van de
grondige studie verzekeringsrecht bij mij heeft aangewakkerd. Daarnaast wens ik ook mijn
commissaris, professor Dr. Rogge Jean, te bedanken. Hij bracht mij op het juiste spoor in mijn
onderzoek en stelde mij o.a. met de juiste mensen in contact. Tenslotte wens ik hen beide ook te
bedanken voor de vlotte en begripvolle communicatie tijdens deze periode.
Ik wens ook nog een aantal andere mensen te bedanken. In het bijzonder wens ik mijn moeder Lieve,
mijn vader Guido, mijn zus Tine en mijn stiefvader Yves te bedanken. Hun onvoorwaardelijke steun en
liefde hebben ertoe geleid dat ik steeds de moed terugvond om erin te vliegen. Ondanks de ups- &
downs tijdens mijn studententijd zorgden zij er steeds voor dat ik tijdens de downs niet ben afgehaakt
met mijn studie rechten. Zij kennen mij als geen ander en moesten vaak fungeren als het luisterend
oor bij thuiskomst waarbij ik hen meermaals overstelpte met een uiteenzetting van de kennis die ik
had opgedaan in de les die dag. Al hadden zij hier misschien niet altijd iets aan, voor mij betekende dit
heel veel. Ook mijn vriendin Sofie wens ik te bedanken voor de liefde, de rust en begrip die ze mij
schonk tijdens het schrijven van deze scriptie. Overigens moet ik ook mijn voltallige familie en mijn
vrienden bedanken voor de bemoedigende woorden en nodige ontspanning die zij mij bezorgden in
deze stressvolle periode.
Tot slot bedank ik ook nog 3 viervoeters nl. Jack, Bob en Diesel. Hoewel zij deze scriptie nooit zullen
lezen is een dankwoord gepast. Elk van de drie hebben zich meermaals aan mijn voeten gelegd en
geprofiteerd van de situatie om geaaid te worden. Op het eerste zicht dienen zij mij dus te bedanken.
Niettemin brachten zij mij op therapeutische wijze tot rust tijdens deze stressvolle periode.
Bedankt !
Jan De Vleeschouwer,
15 mei 2019
Overzicht
In deze masterproef wordt onderzocht of het huidige Belgische verzekeringsrecht matcht met
blockchaintechnologie en smart contracts. Het onderzoek gebeurt aan de hand van een uitgebreide
literatuurstudie. Verder ga ik ook ten rade bij specialisten uit de praktijk om mijn reeds opgebouwde
constataties af te toetsen aan de werkelijkheid. Bovendien geef ik een aantal aanbevelingen hoe er
zou kunnen verholpen worden aan de obstakels waar blockchaintechnologie en smart contracts
mogelijks op botsen in het huidige Belgische verzekeringsrecht.
Deze masterscriptie bestaat uit 4 delen en is opgebouwd als volgt:
Vooreerst start ik met een beschrijving van de technologie die blockchain is (Deel 1: Blockchain: wat,
hoe en waarom?) en een beschrijving van de interessante toepassing van de smart contracts (Deel 2:
Smart Contracts). Ik probeer deze 2 delen aan te snijden vanuit de optiek dat de lezers van deze
masterproef voornamelijk juristen zijn en tevens mensen werkzaam binnen de verzekeringssector.
Vóór ik aan mijn onderzoek begon, was mijn kennis omtrent blockchain en smart contracts quasi nihil
als jurist zijnde. Vandaar dat ik het belangrijk vind om jullie mee te nemen in mijn ontdekkingsreis wat
deze 2 onderdelen betreft en ze op een zo conceptueel mogelijke manier uitgelegd te krijgen.
Voor Deel 1 zal hoofdzakelijk de conceptuele aanpak gevolgd worden zoals beschreven in het boek
“Blockchain Basics: A Non-Technical Introduction in 25 Steps1” van Daniel Drescher. Daniel is doctor in
de Econometrie aan de Technische Universiteit van Berlijn en bezit daarnaast nog een Master of
Science in de Software Engineering behaalt aan de Universiteit van Oxford. Zijn boek zal de basisbron
vormen om blockchaintechnologie uit te leggen. Het gaat over een groot stuk binnen deze
masterscriptie maar des te meer een belangrijk onderdeel dat bijdraagt aan de redeneringen die erop
volgen en in het bijzonder de slotconclusie van mijn onderzoek.
Voor Deel 2 wordt de meeste waarde in de eerste plaats toegeschreven aan een zeer recent en
overzichtelijk boek getiteld “Blockchain en smart contracts: Het einde van de vertrouwde
tussenpersoon?2” van Jurgen Goossens, postdoctoraal onderzoeker hier aan de faculteit Rechten en
universitair docent staatsrecht aan de Erasmus Universiteit Rotterdam, en Kristof Verlype,
computerwetenschapper, onderzoeker, adviseur, spreker in de domeinen van cryptografie, blockchain
& privacy. Op de tweede plaats wordt ook veel waarde gehecht aan een tweedelig artikel in het
1
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 255 p.
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 136 p.
2
1
Weekblad voor Privaatrecht, Notariaat en Registratie getiteld “Van oud naar nieuw: van internet naar
smart contracts en van mensen naar code3” geschreven door Mr. Dr. Tycho de Graaf, universitair
docent burgerlijk recht aan de Universiteit Leiden.
Vervolgens betrek ik er de verzekeringssector zelf bij en probeer ik van hieruit de link te maken met
blockchain en smart contracts (Deel 3: De verzekeringssector). In dit deel van de tekst haal ik relevante
aspecten van het positief Belgisch verzekeringsrecht aan en ga ik op basis daarvan op zoek naar
enerzijds de mogelijke conformiteit van blockchaintechnologie en smart contracts met het huidig
Belgische verzekeringsrecht en anderzijds de mogelijke problemen waar deze 2 fenomenen op botsen
in ons huidige recht. Ter ondersteuning van deze juridische analyse sta ik terloops stil bij de potentiële
waarde van blockchain en smart contracts om naast een zuiver juridische bijdrage eveneens een
bescheiden meta-juridische bijdrage te leveren.
Tot slot concludeer ik wat ik uit mijn onderzoek heb geleerd en lever ik een antwoord op de centrale
onderzoeksvraag die klinkt als volgt “Matcht het huidige Belgische verzekeringsrecht met de
blockchaintechnologie en smart contracts?” (Deel 4: Conclusie).
3
T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (I)", Weekblad
voor Privaatrecht, Notariaat en Registratie 2018, afl. 7199, (494) 494-501; T.J. DE GRAAF, "Van oud naar nieuw:
van internet naar smart contracts en van mensen naar code (II)", Weekblad voor Privaatrecht, Notariaat en
Registratie 2018, afl. 7200, (525) 525-530.
2
Deel 1: Blockchain: wat, hoe en waarom?
1. Inleiding
Blockchain… Het is een term die u de laatste jaren waarschijnlijk vaak heeft horen vallen. Velen
linken het direct aan de cryptomunten met namen als Bitcoin, Ethereum, Ripple, etc. Deze
cryptomunten zijn weliswaar gebaseerd op het idee van de blockchain maar zijn niet de blockchain
zelf.
Wat is dat nu eigenlijk die blockchain? In kort, het is een nieuwe technologie te situeren is in
de software engineering4, dit is een deelgebied binnen de computerwetenschappen. Blockchain maakt
deel uit van een softwaresysteem. Als jurist was ik vrijwel een leek wat betreft de werking van
software. Tot op vandaag sta ik nog steeds in beginnersschoenen wanneer het hem aankomt op de
zeer technische kant van softwaresystemen. Maar daar is mijn onderzoek in deze masterproef niet op
gericht.. Dat lijkt vooralsnog het werk van de programmeur. Doch lijkt het een steeds sterker wordende
realiteit dat juristen hun horizon zullen moeten verbreden door in de toekomst nauwer samen te
werken met informatici5. Ook de verzekeraar wordt geconfronteerd met een steeds groeiende
digitalisering in zijn sector6.
Met dit onderzoek zal ik beoordelen of het gebruik van een blockchain en smart contracts in
de verzekeringssector matcht met het huidige Belgische verzekeringsrecht. We zullen de blockchain,
als zeer technisch gegeven binnen het vakgebied van de informatie- en computertechnologie (hierna:
4
Zie C. SUNGDEOK, T.N. RICHARD en K. KANG (ED.), Handbook of Software Engineering, Basel, Zwitserland,
Springer International Publishing, 2019, 93.
5
M. TRUYENS, "Smart contracts: moeten juristen programmeurs worden?", Juristenkrant, 23 november 2016,
12-13; A. KEEREMAN, "UGent organiseert eerste Belgische Legal Techathon", Juristenkrant, 7 november 2018, 8;
R.K. BOONE, Annelien, "Legal tech maakt meer tijd vrij voor contacten met cliënten", Juristenkrant, 13 maart
2019, 8-9; Voorbeeld van een software-ontwikkelaar in België voor de verzekeringssector met klanten zoals ING,
Aegon en Allianz: S.A. COMARCH, https://www.comarch.be/nl/verzekeringen/ (consultatie 13 mei 2019).
6
BLOOVI, Onderzoek: Helft Belgen klaar voor de 'digitale verzekeraar', maar sector volgt niet,
https://www.bloovi.be/artikels/innoveren/2018/onderzoek-helft-belgen-klaar-voor-de-digitale-verzekeraarmaar-sector-volgt-niet (consultatie 13 april 2019); FIDEA, De digitale revolutie geeft de verzekeringssector een
nieuw gezicht, https://trends.knack.be/economie/trends-information-services/de-digitale-revolutie-geeft-deverzekeringssector-een-nieuw-gezicht/article-publishingpartner-923781.html (consultatie 19 april 2019); D.
CLUDTS, Verzekeringssector voelt hete adem van Google en Amazon in de nek,
https://www.techzine.be/blogs/13276/verzekeringssector-voelt-hete-adem-van-google-en-amazon-in-denek.html (consultatie 19 april 2019); NBB, Impactanalyse van fintech en digitalisering op de Belgische banksector
en
bankentoezicht,
https://www.nbb.be/nl/artikels/impactanalyse-van-fintech-en-digitalisering-op-debelgische-banksector-en-bankentoezicht (consultatie 19 april 2019).
3
ICT), vanuit een juridisch perspectief gaan bekijken op een niet-technische wijze. Vandaar leg ik
blockchain eerst uit op niet-technische wijze opdat mijn visie wat betreft de overeenstemming van de
blockchaintechnologie met het huidige Belgische verzekeringsrecht ineens duidelijk is voor de lezer die
niet vertrouwd is met de idee achter blockchain. Met dit in het achterhoofd ga ik van start!
2. De noodzakelijke basis om blockchain als volstrekte leek te begrijpen
Het is belangrijk om softwaresystemen op een correcte manier te gaan analyseren. Daarom
wordt het voor de leek ook aangeraden om softwaresystemen te bekijken als een compositie van
lagen. Die compositie van lagen vormen dan uiteindelijk in zijn geheel het softwaresysteem as such.
Deze benadering van softwaresystemen via lagen is belangrijk om het idee van blockchain te begrijpen.
We kunnen de lagen van een softwaresysteem van elkaar onderscheiden op 2 wijzen:
1) Vanuit het oogpunt van de gebruiker
2) Door te kijken naar de functionaliteit van het systeem zelf
Laat ons beginnen met het te bekijken vanuit het oogpunt van de gebruiker. Enerzijds kan je
een laag van een softwaresysteem bekijken op het applicatieniveau. Dit wijst op die delen van het
softwaresysteem die voor de gebruikers ervan als nuttig worden ervaren (bv. het nemen van foto’s,
het kunnen versturen van berichten, …). Naast het applicatieniveau is er het implementatieniveau. Het
implementatieniveau wijst op die delen van het softwaresysteem die de delen van het applicatieniveau
mogelijk maken. Het implementatieniveau wijst dus naar de wijze waarop het applicatieniveau wordt
gerealiseerd (bv. Het converteren van digitale signalen in akoestische signalen, het herkennen van een
pixel in een digitale camera, …). De delen op het implementatieniveau zijn van nature uit een technisch
gegeven.
Anderzijds kunnen we de lagen van een softwaresysteem ook van elkaar onderscheiden door
te kijken naar de functionaliteit van het systeem zelf. Je hebt de functionele delen van het
softwaresysteem en daarnaast de niet-functionele delen.
De functionele delen zijn die delen die wijzen op wat het systeem allemaal kan en doet. Bv. het nemen
van foto’s, het versturen van data over een netwerk, het bewerken van een foto, etc.
De niet-functionele delen zijn die delen die op het eerste zicht niet nuttig blijken te zijn maar als ze er
niet zijn wel een probleem vormen en bijgevolg de functionele delen niet meer naar behoren werken.
4
Denk aan: een mooie en gebruiksvriendelijke interface, de snelheid van de software, de mogelijkheid
om data veilig en privé te bewaren, … Bovendien is er één niet-functioneel aspect van een softwaresysteem dat doorgaans zeer belangrijk is nl. de integriteit.
Integriteit bevat 3 grote componenten nl. de data-integriteit, de gedragsintegriteit en de
veiligheid.
De data-integriteit zorgt ervoor dat de data in het systeem volledig, correct en zonder contradicties
bestaat.
De gedragsintegriteit zorgt ervoor dat het systeem doet wat ervan het systeem verwacht wordt. Bv. je
drukt op de letter A, dan verwacht je ook dat de letter A en niet de letter X verschijnt op je monitor.
De veiligheid zorgt er dan weer voor dat de informatie, die je privé wil houden en niet wil laten lekken,
via het softwaresysteem daadwerkelijk ook privé blijft en niet publiek kan worden gemaakt zonder de
toestemming van een gemachtigde gebruiker.
De integriteit is een belangrijk niet-functioneel aspect op het implementatieniveau van ieder
softwaresysteem dat vaak als een evidentie wordt aangenomen. Toch is het één van de belangrijkste
aspecten van een softwaresysteem waar software-engineers (terecht) heel veel aandacht aan
besteden.
Als je nu deze 2 mogelijke manieren, om delen van een softwaresysteem te onderscheiden,
combineert dan kom je tot een 2-dimensionale benadering van het softwaresysteem (zie ter illustratie
Table 1-1).7
7
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 3-6.
5
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 5.
2.1. Software-architectuur en de relatie met blockchain
Software-architectuur kan omschreven worden als de manier waarop de onderdelen in een
softwaresysteem zijn georganiseerd en afgestemd op elkaar. Het is een belangrijke keuze die men
maakt bij het implementeren8 van een softwaresysteem. “Het behouden van de integriteit van een
systeem veronderstelt eveneens het behouden van uw software-architectuur9”.
De 2 grote types van software-architectuur zijn centraal en gedistribueerd. Men kan beide zien
als tegenpolen van elkaar.
Bij gecentraliseerde softwaresystemen worden de componenten binnen het systeem allemaal
gebouwd rond en verbonden met één centrale component. In de vakliteratuur gebruikt men de term
8
Zie voor een overzicht van de verschillende fasen in het software-ontwikkelingsproces: C. SUNGDEOK et al.,
Handbook of Software Engineering, Basel, Zwitserland, Springer International Publishing, 2019, 24, 2e al; Zie ook
WIKIPEDIA,
Implementatie,
https://nl.wikipedia.org/wiki/Implementatie#Implementatie_van_software
(consultatie 6 mei 2019). De implementatiefase in het ontwikkelingsproces van een softwareproduct houdt het
effectief programmeren/coderen in van de software;
9
C. SUNGDEOK et al., Handbook of Software Engineering, Basel, Zwitserland, Springer International Publishing,
2019, 94, 5e al. e.v.
6
‘nodes’ om die componenten binnen het systeem aan te duiden. Nodes zijn in feite niets meer of
minder dan de fysieke computers die deelnemen aan het systeem. Er is dus één centrale node die
verbonden is met alle aparte nodes. De nodes staan enkel in verbinding met die centrale node en niet
onderling. Ik stel vast, uit de bevraging die ik deed bij o.a. KBC Bank & Verzekering10 en de literatuur
die ik ter beschikking had, dat bijna elke verzekeringsmaatschappij met gecentraliseerde
softwaresystemen en dus één centrale controlerende entiteit werkt.
Bij gedistribueerde softwaresystemen daarentegen vormen alle componenten samen één groot
netwerk van onderling verbonden nodes zonder één centrale controlerende node. Voornamelijk de
eigenschap dat er geen controle is binnen het systeem welke uitgaat van één centrale component is
belangrijk om het onderscheid tussen de 2 grote types software-architectuur te maken. Bij
gedistribueerde softwaresystemen wordt het systeem gecontroleerd door de meerderheid van de
nodes.
Zie op onderstaande afbeelding een voorbeeld van een gedistribueerd systeem (links op de afbeelding)
en een voorbeeld van een gecentraliseerd systeem (rechts op de afbeelding).11
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 11.
10
11
Zie bijlage I, antwoord op vraag 6.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 10-11.
7
2.2. De voor- en nadelen van gedistribueerde systemen
De voordelen van een gedistribueerd systeem:
-
Hogere computerkracht (door het samenbrengen van de kracht van alle verbonden computers)
-
Kostenbesparend (het maken, onderhouden en beheren van een gedistribueerd systeem met
verbonden mainstream computers is nog steeds veel lager dan het maken, onderhouden en
beheren van een gecentraliseerd systeem met een centrale supercomputer)
-
Hogere betrouwbaarheid (als één individuele computer uitvalt in het systeem dan zal het systeem
blijven werken gezien de andere computers die uitval kunnen opvangen. Een gedistribueerd
systeem heeft geen enkelvoudig faalpunt)
-
Bezit het vermogen om natuurlijk te groeien (door het bijvoegen van computerkracht of
vernieuwen van oudere computers)
De nadelen van een gedistribueerd systeem:
-
Coördinatie van de leden in het systeem gebeurt niet centraal (geen centraal controlerende
entiteit, wat nu bij de meeste beheersoftware (zoals bijv. Insusoft12) in de verzekeringssector wel
het geval is)
-
Communicatie evenmin (communicatieprotocol nodig om de deelnemende computers met elkaar
te laten communiceren -> kost dus moeite en computerkracht die niet op de hoofdtaak van het
systeem gericht is)
-
Afhankelijkheid van netwerken (elke soort uitwisseling van informatie heeft een medium nodig. In
deze is het medium het netwerk en zal bij het wegvallen van het netwerk al het overige van het
systeem ook op de helling komen te staan)
-
Hogere complexiteit van het programma (gezien voorgaande 3 nadelen vergt het schrijven van
programma’s en software een hogere complexiteit)
-
Veiligheidsproblemen (entiteiten met slechte bedoelingen zouden via het netwerk kunnen
proberen om informatie uit het systeem te halen en te misbruiken -> doch valt dit nadeel m.i. als
matig tegenargument gewaardeerd te worden t.a.v. gedistribueerde systemen. Centrale systemen
staan nl. evenzeer bloot aan mogelijke entiteiten met slechte bedoelingen. Het essentiële verschil
ligt in de controle ervan. Bij gedistribueerde systemen ligt die controle in de collectieve handen
12
CRM.ART, https://crm.be/nl/insusoft (consultatie 5 april 2019). Zie ook bijlage II, antwoord op vraag 4.
8
van elk lid binnen het systeem en niet in de handen van één groep van mensen of zelfs één
persoon)13
2.3 Peer-to-Peer (P2P) systemen, een specifieke variant op gedistribueerde systemen
Peer-to-Peer systemen zijn gedistribueerde systemen bestaande uit individuele computers
(‘nodes’) die hun computerkracht rechtstreeks openstellen voor gebruik aan alle leden (‘peers’) binnen
het netwerk zonder één centraal punt van coördinatie te hebben.14 Elk lid (peer) in het systeem bezit
in beginsel evenwaardige rechten en gebruiksfuncties binnen het systeem. Ze zijn dus elk zowel
consument als leverancier als het ware15. Hoe meer leden, hoe sterker en groter het systeem. Vaak
kennen peer-to-peer systemen interessante applicaties zoals file-sharing (i.e. het delen van
bestanden), privacy protection (i.e. veiligheidsbescherming van de gedeelde informatie), etc.16
De muziekindustrie werd door zo een peer-to-peer systeem compleet veranderd. Het bedrijf Napster
creëerde een peer-to-peer file-sharing systeem dat fungeerde als vertrouwd platform bij
muziektransacties17. De traditionele muziekstudios en hun distributiekanalen werden plots overbodig
nu de artiesten zelf hun muziek konden gaan aanbieden via dit systeem en de consumenten zelf hun
muziek konden halen via dit systeem. Het pijnpunt van de muziekindustrie lag hem in de aard van hun
goederen. Muziek is een immaterieel goed dat via het overbrengen & kopiëren van data aan een lage
kost kan gebeuren.
Tot slot is het gebruik van zo een peer-to-peer systeem ook een correctere weergave van de realiteit.
Door het gebruik van een peer-to-peer systeem gebeuren transacties zonder tussenkomst van een
‘echte’ tussenpersoon zoals bijv. muziekstudio’s, banken, notarissen, verzekeringsagenten en makelaars, etc. Deze tussenpersonen (ook wel TTP’s of Trusted Third Parties genaamd) zijn vandaag de
dag in feite een lastige omweg om een simpele transactie te laten plaatsvinden tussen A en B. Tevens
13
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 12-14.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 23; J.
GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?, Brussel,
Els Belgium, 2019, 14-15.
15
Vgl. S. GEIREGAT, "Cryptocurrencies are (smart) contracts", Computer Law & Security Review 2018, afl. 5, 11461147, waar de auteur meent dat de rechtspositie van de gebruikers van cryptomunten gezien moet worden als
een contractuele rechtspositie in een multilateraal contract waarbij de contractanten zowel schuldeiser als
schuldenaar zijn t.a.v. elkaar.
16
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 14-15.
17
T.E.o.E. BRITANNICA, Napster File-sharing computer service, https://www.britannica.com/topic/Napster
(consultatie 28 september 2018).
14
9
brengen tussenpersonen kostenverhogende- en vertragende effecten met zich mee. In de
verzekeringssector spreekt men al eens over ‘operational excellence’18 wanneer er wordt nagedacht
over oplossingen die deze nadelige procedurele effecten kunnen verhelpen.
Via een peer-to-peer systeem gebeurt de transactie dus rechtstreeks tussen de werkelijke
contractspartijen (leverancier-consument of in het geval van de verzekeringssector rechtstreeks
tussen verzekeraar en verzekerde). Dit betekent dat bij gebruik van dit systeem, de functie van
verzekeringstussenpersoon/makelaar in theorie overbodig wordt. Het weghalen van tussenpersonen
in transacties noemt men ook wel disintermediatie. Het is voornamelijk dit laatste waar blockchain, als
vrij nieuwe technologie, veel potentieel bezit om dit te gaan verwezenlijken.19
Daar vandaag de dag veel regelgeving in zowel de huidige financiële- als verzekeringssector
voornamelijk gericht is op tussenpersonen zal de regelgever en toezichthouder in de toekomst hun
pijlen niet langer op deze tussenpersonen moeten richten maar op het systeem en haar gebruikers
zelf. Mogelijks zullen zij een volledig nieuw wetgevend kader dienen uit te werken dat hieraan
tegemoet komt20. Meer hierover in deel 3.
2.4. Een mix van beide types software-architectuur (hybride architecturen)
Je kan een softwaresysteem ook gaan opbouwen met een architectuur waar beide types in zijn
verweven.
Een centrale component binnen een gedistribueerd systeem (links op figuur 2-2).
Een gedistribueerd systeem binnen in een centrale component (rechts op figuur 2-2).21
18
R. PEVERELLI, Marketing Science: Blockchain in verzekeringen https://www.ey-vodw.com/blog/marketingscience-blockchain-in-verzekeringen (consultatie 6 mei 2019).
19
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 22; J.
GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?, Brussel,
Els Belgium, 2019, 7.
20
Vgl. A. DE BACKER en V. DE BOE, "Smart contracts in de financiële sector: grote verwachtingen en regulatoire
uitdagingen", Computerr. 2017, afl. 6, (355) 361-363.
21
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 15-16.
10
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 11.
2.5. Kernonderscheid tussen centraal- & gedistribueerd systeem
De vuistregel om een onderscheid tussen beide systemen te maken is de volgende: kijk of er
een centrale node is die het hele systeem kan platleggen:
➔ Zo ja, dan heb je te maken met een centraal systeem;
➔ Zo niet, dan heb zit je met een gedistribueerd systeem.22
2.6. Het nut van blockchain
Je kan de keuze tussen beide systemen vergelijken met de keuze die je maakt bij het kopen
van een auto. Welke motor wil ik erin? Welke banden wil ik er op? Welke remschijven? etc. Je zal in
elk geval, ongeacht welke keuze je hebt gemaakt, een auto hebben die rijdt maar meer dan
waarschijnlijk zal je bij bepaalde keuzes een betere auto hebben dan bij andere keuzes. Maar het
hoofddoel van uw aankoop blijft hetzelfde nl. een auto kopen met als hoofddoel je te verplaatsen met
die auto. Kortom, elke keuze heeft zijn voor- en nadelen in de manier waarop de auto zal functioneren.
Dat is bij de keuze van je software-architectuur net hetzelfde.23
22
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 16.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 9-10.
23
11
De functionele & niet-functionele aspecten van je systeem zullen op een verschillende manier
worden benaderd naargelang het type software-architectuur.
Dit brengt ons bij het begrijpen van het nut van de blockchain. De blockchain kan als een handig middel
worden gezien bij het behalen en aanhouden van de integriteit (zie puntje 2.2.) van een gedistribueerd
systeem. Het is een interessante technologie die dit belangrijk niet-functioneel aspect kan bereiken
bij het implementeren van je softwaresysteem!24
2.7. Welk probleem probeert Blockchain te verhelpen en waarom is het zo belangrijk om dit te
verhelpen?
Vertrouwen en integriteit zijn de 2 niet-functionele aspecten in zuiver gedistribueerde
systemen die problematisch kunnen zijn, net omdat er geen centrale controlerende node is in het
systeem die de overige nodes controleert.
Vertrouwen wijst op het geloof bij mensen dat ze, bij het toetreden tot een peer-to-peer systeem, erop
kunnen rekenen dat het systeem voldoet aan hun verwachtingen en een normale standaard. Kortom,
het systeem moet doen wat het hoort te doen.
Integriteit25 zorgt ervoor dat, eens ze deel uitmaken van het systeem, dit vertrouwen telkens bevestigd
wordt en bestendigd door de gebruikers die vertrouwen op het systeem. Bij een gebrek aan integriteit
zullen gebruikers het systeem verlaten en zal het systeem gedoemd zijn om te falen op lange termijn.
Hoe wordt die integriteit dan bekomen en bestendigd in een peer-to-peer systeem? Dit hangt
af van verschillende factoren waaronder 2 belangrijke nl. de kennis over het aantal peers & de kennis
over de betrouwbaarheid van de peers. Men zal een grotere kans hebben om die integriteit te
bekomen en te bewaren wanneer de kennis over deze 2 factoren hoog is.
Er zijn 2 gevaren die de integriteit kunnen schaden bij gedistribueerde peer-to-peer systemen:
1)Technische fouten
24
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 16-17
juncto 5.
25
Zie ook: C. SUNGDEOK et al., Handbook of Software Engineering, Basel, Zwitserland, Springer International
Publishing, 2019, 94 en 115.
12
2)Peers met slechte bedoelingen (cf. peers die ten koste van het systeem hun eigen belang gaan
nastreven)
Wat is nu het probleem dat Blockchain moet verhelpen? Wel, blockchain moet verhelpen dat
de integriteit zou worden beschadigd bij een zuiver gedistribueerd peer-to-peer systeem waar er geen
kennis is over het aantal peers en de betrouwbaarheid van die peers.26
2.8. De term ‘Blockchain’
Je kan de term ‘blockchain’ in 4 betekenissen gebruiken:
1) Als naam voor een datastructuur
2) Als naam voor een algoritme
3) Als naam voor een resem aan technologieën
4) Als parapluterm voor zuiver gedistribueerde peer-to-peer systemen met een gemeenschappelijk
toepassingsgebied
1)Datastructuur: In de computerwetenschappen & software-engineering wijst men hiermee op de
manier waarop de informatie georganiseerd is, ongeacht de inhoud van de informatie. Blockchain als
datastructuur wijst op data die samen in units zijn gebundeld, genaamd ‘blocks’. Deze ‘blocks’ zijn aan
elkaar gelinkt met een ‘chain’. Vandaar dus de naam blockchain. Je kan de blocks vergelijken met de
pagina’s uit een boek. De chain is in dit voorbeeld dan de logische volgorde van de pagina’s zoals
bijvoorbeeld de paginanummering die ervoor zorgt dat de pagina’s aan elkaar gelinkt worden (cf. een
logische ordening). De volgorde en de nummering zal later duidelijk worden dat die belangrijk is bij
blockchain. Blockchain bevat namelijk een speciale nummering en volgorde die verschilt van een
standaardnummering zoals bijvoorbeeld in een boek.
2)Algoritme: Software-engineers gebruiken de term blockchain ook om te wijzen op een sequentie
van instructies die gegeven wordt aan een computer om die vervolgens uit te voeren.
3)Resem aan technologieën: Blockchain als resem aan technologieën verwijst naar een combinatie
van blockchain als datastructuur, blockchainalgoritme maar ook als cryptografische- en
26
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 30-32.
13
veiligheidstechnologie die gecombineerd gebruikt kan worden om de integriteit van een zuiver
gedistribueerd peer-to-peer systeem te garanderen.
4)Parapluterm: Blockchain als parapluterm wijst op een zuiver gedistribueerd peer-to-peer systeem
van grootboeken die gebruik maakt van de blockchaintechnologie (dit wordt ook vaak Distributed
Ledger Technology genoemd27). Grootboeken zijn registers die gegevens aan elkaar linken en oplijsten.
Vele instellingen zijn erop gericht die registers up-to-date te houden. Denk bijvoorbeeld aan het
hypotheekkantoor (sinds kort in België gekend onder de naam ‘kantoor Rechtszekerheid’28) (instelling)
waar men onder andere de authentieke verkoopakten van onroerende goederen bijhoudt en een lijst
(grootboek) maakt die duidelijkheid schept over wie eigenaar is van welk welomschreven onroerend
goed.29
2.9. Het beheer van eigendom als meest besproken applicatie van blockchain
Het beheer van eigendom via grootboeken is een taak die voornamelijk voor de overheid is
weggelegd. Om didactische reden wordt de blockchain hier uitgelegd a.d.h.v. het voorbeeld van
beheer van eigendom. Denk hier opnieuw aan het hypotheekkantoor die er o.a. voor zorgt dat elke
transfer van eigendom van onroerende goederen keurig wordt bijgehouden in een grootboek. In
Ghana vindt er zelf al een project plaats, genaamd ‘BenBen’, waarbij blockchaintechnologie gebruikt
wordt om de eigenaars van een stuk land een platform te bezorgen waarmee ze kunnen aantonen dat
ze wel degelijk de eigenaar zijn van hun beweerde stuk land. Vaak willen banken geen lening
verstrekken zonder een onderpand. Doordat vele Ghanezen vaak het vereiste papieren bewijs niet
bezitten, kunnen zij vaak ook hun rechten niet afdwingen. Dit papieren bewijs is een geschrift komende
uit een centraal register (gelijkaardig aan de registers in ons hypotheekkantoor) welke wordt beheerd
door de overheid. Via BenBen hebben zij nu een alternatief om via de BenBen-blockchain aan te tonen
dat zij wel degelijk eigenaar zijn en op die manier een correctere onderhandelingspositie krijgen bij de
bank30.
27
S. GOETEYN, D.c. COUCKUYT en L.p.N.I.V. LEMEIRE, Blockchain as a Service, onuitg. Universiteit Gent, 2018,
http://lib.ugent.be/catalog/rug01:002508971, 1.
28
FOD FINANCIËN, Registratie- en hypotheekkantoren worden 1 kantoor Rechtszekerheid,
https://financien.belgium.be/nl/Actueel/registratie-en-hypotheekkantoren-worden-1-kantoor-rechtszekerheid
(consultatie 6 mei 2019).
29
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 33-37.
30
BIGCHAINDB,
Blockchain
Powered
Land
Registry
in
Ghana
with
BenBen,
https://www.bigchaindb.com/usecases/government/benben/ (consultatie 6 mei 2019).
14
Op onderstaande figuur (figuur 6-1) staat een overzicht van de concepten die ten grondslag
liggen aan dat van eigenaarschap. De concepten van de bovenste lagen zijn meer algemeen dan de
onderste. De onderste laag geeft de implementatielaag weer. De concepten in de bovenste lagen
kunnen gezien worden als realisaties van de lagen die eronder liggen. Bv. Het grootboek (Ledger) ->
zorgt voor het linken van eigenaars aan hun eigendom (Mapping of Owners to Property) -> wat op zich
dan weer bijdraagt aan het bewijs van eigenaarschap (Proof of Ownership).31
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 42.
Er zijn 3 grote veiligheidsconcepten die belangrijk zijn bij softwaresystemen:
1)Identificatie: het claimen van een naam en beweren die iemand te zijn. Anders geformuleerd: aan
de hand van een naam, die dient als identificator, beweren die iemand te zijn.
2)Authenticatie: Verifiëren of bewijzen dat je bewering, nl. de bewering van die iemand te zijn, ook
daadwerkelijk klopt. Dit kan gebeuren a.d.h.v. een unieke authenticator (bv. je identiteitskaart).
3)Autorisatie: Toegang verlenen tot beschikbare middelen of diensten a.d.h.v. de karakteristieken of
specifieke eigenschappen van iemand zijn identiteit. Autorisatie is het gevolg van een combinatie van
een succesvolle authenticatie en evaluatie van iemand zijn karakteristieken of rechten32.
31
32
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 39-42.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 42-44.
15
Op onderstaande afbeelding (figure 6-2) kan je zien hoe het bewijs van eigendom (Proof of
Ownership) en de overgang van eigendom (Transfer of Ownership) gerelateerd is aan het doel en de
eigenschappen van een grootboek (Ledger). De 2 voornaamste doelen van een grootboek zijn enerzijds
het bewijs van eigendom te leveren via de aanwezige historische data in het grootboek en anderzijds
voor de overgang van eigendom via de creatie van nieuwe data aan het grootboek.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 44.
Uw eigendom kunnen bewijzen moet via een transparant systeem gebeuren dat openstaat
voor iedereen (transparancy). Maar de eigendom laten overgaan op iemand anders mag echter enkel
gebeuren door de rechtmatige eigenaar van het betreffende goed en dient dus beschermd te worden
(privacy). Transparantie enerzijds en privacy anderzijds zijn eigenlijk conflicterende krachten in een
grootboek. Welnu, blockchain is een gigantisch gedistribueerd peer-to-peer systeem met
datastructuren als in een grootboek.
Het nadeel van een grootboek is wel als je met slechts 1 grootboek werkt en er worden daar foute
gegevens in gezet of het grootboek wordt beschadigd, dan kan je nergens anders op terugvallen om
te gaan bewijzen dat je bijvoorbeeld eigenaar bent van je huis. M.a.w. hoe meer grootboeken waar je
op kan terugvallen, hoe beter. Dit zou je kunnen bereiken via een zuiver gedistribueerd peer-to-peer
16
systeem waar de peers kopieën houden van éénzelfde grootboek en verzoeken betreffende
eigenaarschap bevestigen volgens dat systeem. Elke node bewaart haar eigen kopie van het grootboek
in het systeem. Op die manier kan het bewijs van eigenaarschap door de meerderheid van de peers
worden bevestigd33.
2.10. Het dubbel-uitgave probleem (double spending problem)
Het updaten van de laatste actuele informatie over de verschillende kopieën van grootboeken
binnen het peer-to-peer netwerk vergt enige tijd. Bepaalde peers bezitten al de laatste up-to-date info
terwijl anderen die nog niet bezitten. Dit kan leiden tot misbruik door de peers die de info wel al
bezitten en bovendien leiden tot een onevenwicht tussen de peers. Je kan het vergelijken met de
eigenaar die éénzelfde onroerend goed tweemaal verkoopt aan 2 verschillende partijen tegelijk (i.e.
dubbele verkoop34). Bijvoorbeeld: De eigenaar verkoopt het eerst aan B en vervolgens nog eens aan C.
Misbruik van die traagheid van informatietransfer kan dus leiden tot een situatie die gelijkaardig is aan
die als bij de dubbele verkoop van een onroerend goed.
Het dubbel-uitgave probleem is drieledig:
1) Het is een probleem bij het kopiëren van digitale goederen (cf. kopieën maken is eenvoudig en
daarom vatbaar voor misbruiken)
2) Het is een probleem bij gedistribueerde peer-to-peer systemen van grootboeken (cf. consistent
houden van informatie voor alle leden van het systeem)
3) Het is een voorbeeld van een breuk in de integriteit van gedistribueerde peer-to-peer systemen
(cf. data-consistentie)
Verschillende oplossingen:
1) Het gebruik van een up-to-date grootboek die te allen tijde correct werkt.
2) Blockchain als tool/oplossing voor het oplossen van het double spending problem.
33
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 38-46.
Zie voor de problematiek van de dubbele verkoop: F. BAUDONQ, "Dubbele verkoop", NJW 2004, afl. 86, (1126)
1126-1130.
34
17
3) Afhankelijk van het specifieke gebruik waarvoor het gedistribueerd peer-to-peer systeem bestemd
is, zal de concrete invulling van het begrip ‘integriteit’ verschillen en zullen de gepaste oplossingen
eveneens verschillen.35
2.11. Hoe worden gegevens (betreffende eigenaarschap) praktisch opgeslaan bij blockchain?
Het idee is dat ALLE gegevens, in ons gevolgde voorbeeld dus m.b.t. elke overdracht van
eigendom, worden opgeslaan en dit op onuitwisbare wijze! Vergelijk het met het plaatsen van uw
handpalm in een stuk nat cement. Eens de cement is opgedroogd, heb je een handafdruk staan in dat
stuk cement. Je zal die handafdruk in principe niet meer kunnen verwijderen uit dat stuk cement.
Je hebt 2 manieren om ‘eigenaarschap’ in een blockchain te omschrijven. Je kan het omschrijven via
inventarisdata of via transactiedata.
Inventarisdata beschrijft de huidige staat van het eigenaarschap. Het is vergelijkbaar met de weergave
van de hoeveelheid geld die er op huidig ogenblik op uw bankrekening staat.
Transactiedata beschrijft de overgang van eigenaarschap. Neem nu terug het voorbeeld van de
bankrekening. Elke overschrijving, geldopname of geldstorting wordt op uw rekeninguittreksel
weergegeven. Dat is transactiedata. M.a.w. hetgeen beweegt.
Beide types data zeggen iets over eigenaarschap. Het fundamentele verschil tussen beide zit er hem
in dat transactiedata het eigenaarschap uitlegt en rechtvaardigt terwijl de inventarisdata een snelle en
gebruikelijke manier is om de huidige staat van eigenaarschap na te gaan36.
Een transactie is de handeling die de overgang van eigendom van de één naar de ander
teweegbrengt. In een gecentraliseerd systeem zoals bij banktransfers zal er een transactiekost worden
aangerekend aan alle klanten bij hun bank voor het behandelen, controleren en uitvoeren van die
banktransfers door een centrale autoriteit. Bij ons gedistribueerd peer-to-peer systeem zullen het de
leden zelf zijn die bepalen in welke mate zij bereid zijn om voor het systeem te betalen om een
bepaalde transactie te laten plaatsvinden. Diegene die zijn eigendom overdraagt zal uiteindelijk die
kost dragen.
35
36
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 48-53.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 64-65.
18
 De blockchain bewaart de volledige geschiedenis van alle transacties door die alle transactiedata
op te slaan in de blockchaindatastructuur in de volgorde waarop ze hebben plaatsgevonden. Die
volledige geschiedenis van transactiedata zal bijgevolg volstaan om uit te maken wie er eigenaar
is37.
Door het feit dat die chronologie van transacties zo belangrijk is, is het bijgevolg ook belangrijk
dat al die transacties geldig verlopen. Het verifiëren van de geldigheid van die transacties omhelst 3
belangrijke aspecten:
1) Formele correctheid: De transactie moet in de juiste vorm gebeuren en moet alle vereiste data
bevatten.
2) Semantische correctheid: Wijst op het doel van de transactie en het gewenste effect. De
semantische correctheid is vaak gebaseerd op boekhoudkundige regels zoals: niet meer uitgeven dan
je aan activa bezit; limiteren van het aantal transacties; voorkomen van het double spending probleem;
etc.
3) Autorisatie: De blockchain dient bij elke transactie de goedkeuring te bevatten van de transactie
gegeven door de rechtmatige eigenaar38.
2.12. Hashwaarden & hashfuncties
2.12.1.Algemeen
Metaforisch zijn hashwaarden het digitale equivalent van vingerafdrukken. Via hashwaarden
kunnen alle afzonderlijke transactiedata in een peer-to-peer systeem geïdentificeerd worden en
bovendien vlot vergeleken worden met elkaar. Het concept wordt ‘hashfuncties’ genoemd en de
blockchain maakt er intensief gebruik van39.
Wat zijn die hashfuncties en hoe werken ze? Hashfuncties zijn kleine computerprogramma’s
die eender welke data omzetten in een aantal gefixeerde lengtes en dit ongeacht de grootte van de
inhoud die de data in zich draagt. Hashfuncties aanvaarden slechts één stukje data-input per keer en
37
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 65-66.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 67-68.
39
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 71.
38
19
zetten die dan om in een gefixeerde lengte (een hashwaarde genaamd) gebaseerd op de bits en bytes
waaruit dat stukje data bestaat. Een belangrijke groep van hashfuncties zijn de cryptografische
hashfuncties. De cryptografische hashfuncties bezitten de eigenschap dat ze veilig zijn gezien ze
gebruik maken van wiskundige principes en je a.d.h.v. de hashwaarde niet inhoudelijk de gegevens kan
nagaan naar waar ze verwijst40. De cryptografische hashfuncties bevatten volgende eigenschappen:
-
Eender welke data op snelle wijze een hashwaarde toebedelen
-
Deterministisch zijn (d.w.z. identieke hashwaarden voor dezelfde input-data. Enige discrepanties
tussen hashwaarden zullen dus gelegen zijn aan de input-data en niet aan de hashfunctie zelf)
-
Pseudotoevallig zijn (d.w.z. dat de hashwaarden niet kunnen afgeleid worden uit de inhoud van de
input-data. Ze zijn pseudotoevallig en dus niet voorspelbaar o.b.v. de input-data)
-
Eénrichtingsfuncties (het is niet mogelijk om de input-data te reconstrueren a.d.h.v. de
hashwaarden. Vandaar dus dat men zegt dat ze slechts in één richting werken)
-
Weerbaar zijn voor hashbotsingen (d.w.z. men mag niet in een situatie terechtkomen waar het
mogelijk is dat voor verschillende input-data er éénzelfde hashwaarde bestaat. Een hashbotsing
kan dus worden gezien als het digitale equivalent aan de situatie waarbij 2 personen identiek
dezelfde vingerafdruk bezitten. Dat moet vermeden worden binnen de hashfuncties om
hashwaarden als een unieke digitale vingerafdruk te kunnen gebruiken en te vertrouwen41)
2.12.2. Hashwaarden in de echte wereld
2.12.2.1 Het vergelijken van data
Het doel is uiteindelijk om gewoon de cryptografische hashwaarden te kunnen vergelijken
zonder inhoudelijk de aparte gegevens, waarvoor de hashwaarden staan, te gaan vergelijken. Dus
éénvoudigweg de hashwaarden op zich gaan vergelijken42.
2.12.2.2 Het opsporen van wijzigingen in data
Als je wil weten of er iets veranderd is aan de data waar je mee te maken hebt vergelijk je
gewoon of de cryptografische hashwaarde nog steeds dezelfde is wanneer je die door de hashfunctie
40
Vgl. J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 15-16.
41
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 72-73.
42
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 81-82.
20
laat gaan. Is dit het geval, dan heb je nog steeds te maken met dezelfde data. Heb je te maken met een
andere cryptografische hashwaarde dan is de data gewijzigd in het proces.
Het is dus een veiligheidstoets die ervoor zorgt dat je door bepaalde omstandigheden zoals het
tijdsverloop, het feit dat je gegevens via een netwerk worden verstuurd, etc. kan gaan verzekeren dat
je data ongewijzigd is gebleven43.
2.13. Hashreferenties
Hashreferenties kunnen verzekeren dat opgeslagen data zich nog steeds op de locatie bevindt
waar ze behoort te zijn. Ze vertellen ons dus iets over de locatie van de data. Hashreferenties worden
gecreëerd door uw cryptografische hashwaarde te gaan combineren met informatie m.b.t. de locatie
van de achterliggende data en op die manier zal de cryptografische hashwaarde niet meer dezelfde
zijn wanneer de data, waarnaar de hashwaarde verwijst, zich op een andere locatie bevindt dan ze
initieel stond. Je kan hashreferenties figuurlijk gaan vergelijken met het ticketnummer die je krijgt bij
een vestiaire. Je levert je kledij in bij de vestiaire en krijgt een ticket met een nummer op. Wil je uw
kledij terug ophalen dan zal je dat enkel kunnen a.d.h.v. jouw ticket dat je meekreeg bij het inleveren
van je kledij. Bovendien verwijst het ticketnummer waar precies in de vestiaire uw specifieke in
bewaring gegeven kledij zich bevindt.
Hashreferenties worden dus voornamelijk gebruikt in situaties waarbij de data niet van locatie mag
wijzigen eens ze gecreëerd is. De hashreferenties zelf zijn cryptografische hashwaarden die uniek zijn.
Zie voor een schematische voorstelling, onderstaande afbeeldingen44.
43
44
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 82-83.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 83-84.
21
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 84.
 Figuur 11-1: Een geldige hash referentie (R1) zal ervoor zorgen dat je toegang krijgt tot de
achterliggende data.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 85.
 Figuur 11-2: Een ongeldige hashreferentie (R1) wil dus zeggen dat de data zich niet meer op de
initiële locatie bevindt en bijgevolg ook geen toegang meer krijgen tot de data.
22
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 85.
 Figuur 13-3: Er werd er een nieuwe hashreferentie (R1) gecreëerd, eens de data, waarnaar
verwezen wordt, werd gewijzigd.
2.14. Data bewaren in een omgeving gevoelig voor veranderingen
Denk aan het voorgaande voorbeeldje van de ticketjes die je krijgt bij de vestiaire (Supra, nr.
38). Stel nu dat er in je jas nog een ticket zit die verwijst naar een ander nummer in de vestiaire en
vervolgens zit er op dat nummer een andere jas met in die zak nog een ticket die naar een ander
nummer verwijst enzovoort… Op die manier kan je dus een ingewikkelde ketting maken van
verwijzingen naar andere nummers waar andere vesten hangen op andere plaatsen tot je uiteindelijk
bij je eigen vest uitkomt. Hetzelfde is te ondervinden bij hashreferenties die verwijzen naar data en op
hun beurt verwijzen naar een andere hashreferentie. Het finale doel van die hashreferenties zal zijn
om wijzigingen in data of nieuwe toevoegingen snel en gemakkelijk te kunnen opsporen binnen de
opslag van al uw data.
Er zijn 2 klassieke patronen die gebruikt worden bij hashreferenties:
1) Een ketting (vandaar de naam blockchain)
2) Een boom45
45
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 86.
23
2.14.1 Een ketting (chain)
Je kan spreken van een ketting wanneer elk stukje data een hashreferentie bevat die naar een
ander stukje data verwijst. Deze structuur is handig voor data die niet in één stap tegelijk beschikbaar
moeten zijn maar wel in een opeenvolging na elkaar beschikbaar worden. Zie onderstaande afbeelding
voor een voorbeeldje van een kettingstructuur voor het opslaan en linken van data. Data 1 bevat zelf
geen hashreferentie maar elk nieuw stukje data bevat wel een hashreferentie die naar Data 1 verwijst.
Op die manier worden alle stukjes gelinkt aan data 1. Het is dus een echt doorverwijssysteem. Eigenlijk
heb je enkel hashreferentie R3 nodig om toegang te krijgen tot alle data. R3 is het hoofd van de ketting
op deze afbeelding. Het verwijst naar het laatst toegevoegde stukje data in de ketting nl. Data 346.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 87.
2.14.2 Een boom (Merkle tree)
Het is handig om een boomstructuur te gebruiken wanneer je verschillende stukjes data hebt
die allen tegelijk beschikbaar zijn en je wil daarvoor één enkele hashreferentie gebruiken.
Zie op onderstaande figuur (Infra, 25 bovenaan) een voorbeeld van het gebruik van hashreferenties in
een boomstructuur bij het linken van transactiedata. Men noemt het een boomstructuur omdat als je
de afbeelding zou omdraaien, de structuur op een boom lijkt. De enkelvoudige hashreferentie R wordt
in de afbeelding de wortel genoemd en is ook de enige hashreferentie die je nodig hebt om tot de
transactiedata te komen47.
46
47
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 87.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 88.
24
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 88.
2.15 Hashpuzzels
Een hashpuzzel kan je zien als het digitale equivalent van een combinatieslot. Als je probeert
om alle mogelijke combinaties uit te testen op een combinatieslot dan zal je uiteindelijk uitkomen bij
de unieke combinatie waarmee je het slot openkrijgt. Dit is evenwel een tijdrovende en intensieve
methode. Welnu, hashpuzzels kunnen op een gelijkaardige manier worden opgelost maar dan door
gebruik van computerkracht om die unieke combinatie te vinden. Die unieke combinatie op
onderstaande afbeelding wordt ‘nonce’ genoemd. De nonce (lees: de juiste combinatie) zal in
25
combinatie met de data, via de vereiste hashfunctie, een hashwaarde genereren die de restricties kan
passeren48.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 90.
Onderstaande tabel is een voorbeeld waarbij we een hashpuzzel proberen op te lossen door de nonce
te zoeken die een hashwaarde genereert die start met 3 nullen. Zoals je kan zien zal je de nonce vinden
na 615 stappen om tot de correcte hashwaarde te komen49.
48
49
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 89-90.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 90-91.
26
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 91.
De moeilijkheidsgraad van een hashpuzzel kan worden herleid tot het aantal startende nullen
die de hashwaarde moet bezitten. Dus een hashpuzzel met moeilijkheidsgraad 4 zal een puzzel zijn
waarbij de hashwaarde minstens met 4 nullen start. Hoe hoger de moeilijkheidsgraad, des te moeilijker
de puzzel.
Deze hashpuzzles werken omdat hashfuncties slechts in een één richting werken nl. van input naar
output. Men kan m.a.w. niet adhv de gewenste output de input gaan achterhalen. Vandaar dat het
een echte puzzel wordt en er geen andere manier bestaat dan met het raden van de input, in dit geval
de juiste nonce om tot de correcte hashwaarde te komen die voldoet aan de restricties50.
2.16 Cryptografie
Naast hashfuncties is er een tweede techniek waar de blockchain intensief gebruik van maakt
nl. (asymmetrische) cryptografie. Het is de basis om de leden binnen de blockchain te identificeren en
hun eigendom te kunnen beschermen opdat enkel de rechtmatige eigenaars toegang hebben tot hun
eigendom. Dit is wel degelijk een uitdaging omdat het gedistribueerd peer-to-peer systeem, wat de
blockchain is, enerzijds open & toegankelijk is voor iedereen maar anderzijds de privé-eigendommen
die erin circuleren wel moeten voorbehouden blijven aan de rechtmatige eigenaars binnen de
blockchain. Om deze bescherming te bekomen gaan we de leden binnen de blockchain een soort van
brievenbus toekennen nl. je weet het publieke adres van ieder lid binnen de blockchain maar enkel de
private eigenaar van de brievenbus kan kijken wat er binnenkomt in zijn brievenbus via zijn private
sleutel. Het basisdoel van cryptografie is dus om ervoor te zorgen dat enkel rechtmatige personen
toegang kunnen krijgen tot welbepaalde data door te werken met (digitale) sleutels. De term
‘encryptie’ wijst op het feit dat er iets op slot wordt gedaan… M.a.w. encryptie is het beveiligen van
data met een slot. De term ‘decryptie’ wijst dan weer op het omgekeerde nl. het slot opendoen…
M.a.w. decryptie is de sleutel in het slot omdraaien dat ervoor zorgt dat de beveiliging ervan is om
toegang te krijgen51.
50
51
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 91-92.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 93-95.
27
Encrypted data ziet eruit als cypher tekst. Dit ziet eruit als een reeks nutteloze door elkaar
gehaalde letters en figuren voor iemand die geen weet heeft van cryptografie. Die reeks nutteloze
letters en figuren van de encrypted data zijn nl. dezelfde die nodig zijn voor de decryptie van de data.
Wil je dus toegang krijgen tot de versleutelde data dan zal je de juiste cypher tekst nodig hebben om
de decryptie door te voeren om terug de originele data te zien i.p.v. een reeks letters en figuren die
geen steekhouden. Dit laatste zal je namelijk te zien krijgen als je een verkeerde decryptiesleutel
gebruikt. Voor een schematische voorstelling van de basisconcepten in cryptografie, zie onderstaande
figuur52.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 96.
2.12.1 Symmetrische vs. Asymmetrische cryptografie
Initieel gebruikte men 1 sleutel om zowel de encryptie als de decryptie mee uit te voeren. Dit
is symmetrische cryptografie53.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 96.
52
53
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 95-96.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 96.
28
Naderhand bleek dat het niet altijd gewenst is om slechts 1 sleutel te hebben die zowel de
encryptie als de decryptie uitvoert. Daarom kwam men op de proppen met asymmetrische
cryptografie. Bij asymmetrische cryptografie werkt men met 2 complementaire sleutels i.p.v. 1 sleutel.
Een bijkomend gegeven is dat elke cypher tekst gecreëerd met de ene sleutel enkel zal kunnen
geopend worden met de andere sleutel en vice versa. Zie onderstaande afbeelding ter illustratie:
Bron: DRESCHER, D., Blockchain
Basics: A Non-Technical Introduction
in 25 Steps, New York, Apress, 2017,
97.
de zwarte sleutel maakt, via encryptie van het databestand ‘Hello World!’ een cypher tekst met witte
tekst. Maar voor datzelfde databestand kan de encryptie evengoed gebeuren met de witte sleutel. De
encryptie met de witte sleutel zorgt dan voor het vakje met de zwarte tekst. Naargelang de encryptie
gebeurd is met de zwarte of de witte sleutel zal je de complementaire sleutel nodig hebben om de
decryptie door te voeren.
Door het bestaan van die 2 sleutels, bij asymmetrische cryptografie, kan je leden gaan opsplitsen in
categorieën zoals een categorie leden waarbij je wil dat ze data kunnen creëren en die versleutelen
(encryptie -> cypher tekst maken) en een categorie leden waarbij je wil dat ze enkel toegang krijgen
tot data opendoen maar geen data kunnen creëren (decryptie -> cypher tekst decrypten).
Dat zorgt er dus voor dat er 2 dingen dienen te gebeuren bij het gebruik van asymmetrische
cryptografie nl. de sleutels maken en verdelen en ten slotte de sleutels effectief gaan gebruiken. Je zou
29
de sleutels een specifieke naam kunnen geven om elke sleutel zijn specifieke rol aan te duiden (meestal
de private sleutel en de publieke sleutel)54.
Er zijn 2 manieren om de publieke-private sleutels te gaan gebruiken.
1) Publiek-privaat: hier vloeit de informatie van de publieke sleutel, die een encryptie heeft
doorgevoerd, naar de private sleutel, die de decryptie doorvoert. Het is vergelijkbaar met een
mailbox waar enkel de eigenaar van het e-mailadres de e-mails kan openen en lezen.
2) Privaat-publiek: hier gebeurt het tegenovergestelde nl. de informatie vloeit van de private sleutel,
die de encryptie heeft doorgevoerd, naar de publieke sleutel, die de decryptie doorvoert. Het is
vergelijkbaar met een publieke nieuwssite waar iedereen de nieuwsberichten kan lezen maar
enkel de auteurs van de nieuwssite die artikels mogen bijcreëren op de website.
Waarvoor wordt asymmetrische cryptografie nu gebruikt bij blockchain ? Wel, voor 2 doelen
nl. het identificeren (van de accounts) van de leden in de blockchain en het autoriseren van transacties.
Voor het identificeren van de leden in de blockchain krijgt elk accountnummer van de leden binnen de
blockchain een publieke cryptografische sleutel. Iedereen kan via dit publiek adres naar het
betreffende lid berichten sturen en transactievoorstellen doen. Voor dit doel wordt dus gebruik
gemaakt van de publiek-private manier bij het gebruik van de sleutels.
Voor het autoriseren van transacties in de blockchain maakt men gebruik van de privaat-publieke
manier van de sleutels. In het voorbeeld van overdracht van eigendom kan je dit zien als de eigenaar
die zijn eigendom wil overdragen door met zijn private sleutel een cypher tekst te creëren, alle andere
leden kunnen de overdracht bevestigen door met de publieke sleutel (die het accountnummer is van
de overdragende eigenaar) de overeenkomst te gaan bevestigen en de cypher tekst te decrypten. Deze
stap is infeite de digitale handtekening van de overeenkomst55.
2.17 Digitale handtekening als autorisatie van transacties binnen de blockchain
De 3 grote componenten van de digitale handtekening:
54
55
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 96-98.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 98-100.
30
1) De creatie van de handtekening
2) Het verifiëren van data door gebruik van de handtekening
3) Fraude identificeren door gebruik van de handtekening56
2.17.1 Creatie van de handtekening
Onderstaande afbeelding geeft weer hoe het proces van de creatie van een digitale
handtekening verloopt. Je start bij de creatie van de data die je wil versturen, in dit geval de tekst ‘Hello
World!’. De hash waarde van de data wordt bepaald en je gebruikt je private sleutel om een encryptie
door te voeren die de unieke cypher tekst maakt. Die unieke cypher tekst is nu de digitale handtekening
van je data gezien die gelinkt is aan je private sleutel. Zowel je tekst ‘Hello World!’ als je digitale
handtekening worden in een bestand naar de buitenwereld verstuurd (Grijze zone rechts op de
afbeelding)57.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 105.
2.17.2 Verificatie van de data door gebruik van de handtekening
56
57
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 104.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 105.
31
Onderstaande afbeelding geeft weer hoe het verifiëren van ons uitgestuurde bericht ‘Hello
World’ wel degelijk van het correcte lid binnen de blockchain komt. Dit kunnen we gemakkelijk
verifiëren. We starten met het binnengekomen bericht door de hashfunctie de hashwaarde te laten
bepalen, zijnde 7F83B165. Vervolgens gebruiken we de publieke sleutel van de verzender van het
bericht door een decryptie door te voeren van de cypher tekst (= de digitale handtekening). We zien
nu dat de hashwaarden overeenstemmen en op die manier kunnen we zeker zijn dat het bericht wel
degelijk van het correcte lid komt binnen de blockchain58!
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 106.
2.17.3 Fraude identificeren door gebruik van de handtekening
Onderstaande afbeelding toont aan dat bij fraude (Het bericht/de data komt niet van het
juiste/beweerde lid binnen de blockchain) de hashwaarden niet overeenkomen. Het proces is identiek
hetzelfde als voorgaande afbeelding maar de uitkomst is anders nl. de berekende hashwaarden komen
niet overeen wat wil zeggen dat het bericht/de data niet van de beweerde verzender komt. Een hacker
heeft in dit geval geprutst aan het uitgestuurde bericht van de originele verzender. Er staat nu een
vraagteken i.p.v. een uitroepteken in de tekst. Dat is niet wat de originele verzender wou versturen en
door deze controle is het ook mogelijk om te zien dat er aan het bericht/de data geprutst is59.
58
59
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 105-106.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 106.
32
Bron:
DRESCHER,
D.,
Blockchain Basics: A NonTechnical Introduction in 25
Steps, New York, Apress,
2017, 106.
Van deze techniek bestaat er reeds een praktisch voorbeeld geleverd door de KBC groep in
België. Zij maken gebruik van de blockchain om fake news tegen te gaan. Ze hebben een website60
gecreëerd waarbij je een ontvangen bericht of document, dat volgens de afzender uitgaat van KBC (bv.
vanuit uw mailbox), kunt opladen om na te gaan of het bericht of document authentiek afkomstig is
van KBC zelf of niet. Dit kan bijvoorbeeld handig zijn om phishing tegen te gaan of misleidende
nieuwsberichten tegen te gaan zoals een vermeende stijging of daling van een welbepaald
aandelenkoers op de effectenmarkt61.
2.18 Wijzen van gebruik van digitale handtekening
Er zijn 2 wijzen om je digitale handtekening te gebruiken in de blockchain:
1) Het tekenen van een transactie
2) Het verifiëren van een transactie62
2.18.1 Het tekenen van een transactie
60
KBC, Verifieer uw KBC document, https://www.kbc.be/particulieren/nl/verifieer.html (consultatie 11 april
2019).
61
P. SUY, KBC bestrijdt 'fake news' met blockchain, https://www.tijd.be/ondernemen/financiele-dienstenverzekeringen/kbc-bestrijdt-fake-news-met-blockchain/9907261.html (consultatie 11 april 2019 2019).
62
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 107.
33
Een lid in de blockchain die zijn eigendom wenst over te dragen dient bepaalde stappen te
ondernemen om zijn transactie op een veilige manier tot stand te brengen:
1) De transactie gedetailleerd beschrijven (o.a. de accountnummers van de betrokken leden, de
hoeveelheid die hij in de transactie wenst te betrekken, etc.)
2) De cryptografische hashwaarde creëren van het transactiebestand.
3) De hashwaarde laten versleutelen via zijn private sleutel (=encryptie)
4) De cypher tekst die in stap 3 werd gecreëerd bijvoegen als digitale handtekening van de
transactie63.
2.18.2 Het verifiëren van een transactie
Om een transactie te verifiëren moeten volgende stappen gevolgd worden:
1) De hashwaarde bepalen van de transactiedata om deze te verifiëren, behalve de digitale
handtekening zelf.
2) Voer de decryptie door van de digitale handtekening van de transactiedata, met het
accountnummer in gedachten van diegene die beweert eigenaar te zijn van de goederen die het
voorwerp zijn van de transactie.
3) Vergelijk de hashwaarde van stap 1 met die van stap 2. Als beide gelijk zijn dan kan je ervan uit dat
de transactie geautoriseerd is door de werkelijke eigenaar van de betreffende goederen die in de
transactie begrepen zijn. Zijn beide hashwaarden niet gelijk dan is de transactie niet
geautoriseerd64.
2.19 Het bewaren van transactiedata op een veilige manier d.m.v. de blockchainstructuur
Het doel is om de transactiedata te bewaren op zo een manier dat men gemakkelijk de
chronologie binnen de historie van alle transacties kan nagaan en elke wijziging die daaraan zou
gemaakt zijn, kan controleren. Je kan de logische ordening en bewaring vergelijken met die van een
gewoon boek met opeenvolgende paginanummers en logisch geordende tekst met bijhorende titels
die ervoor zorgt dat je snel opzoekingen kan doen.
63
64
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 107-108.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 108-109.
34
Onderstaande figuur toont het voorbeeld aan van de logische opeenvolgende nummering van pagina’s
in een boek. Die logische ordening gaat er dus van uit dat de vorige pagina steeds de huidige pagina –
1 is. In dit geval dus 42-1= 41. Dit is de basisordening die door quasi iedereen wordt gebruikt die een
boek schrijft. Je kan controleren of er een pagina missende is door te kijken of de vorige pagina aan de
regel voldoet65.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 114.
Maar stel nu eens dat de schrijver van het boek een andere ordening in gedachten heeft… Je
kan in zo een geval niet meer impliciet van die regel van huidige paginanummer – 1 uitgaan. Vandaar
dat een expliciete bevestiging van de regel op de pagina zelf voor meer duidelijkheid zou zorgen (zie
afbeelding 14-2 op de volgende pagina)66.
65
66
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 111-114.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 114-115.
35
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 115.
Als je uitsluitend de ordening wil nagaan dan kan je ook werken met referentienummers die
verwijzen naar de inhoud (die ergens anders kan geplaatst worden dan op de pagina zelf). Dit is
gemakkelijk omdat je hiermee de inhoud niet per sé moet gaan nagaan. Onderstaande afbeelding geeft
dit weer ter illustratie67.
67
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 115-116.
36
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 115.
Onderstaande afbeelding gaat nog een stap verder en gebruikt de referentienummers als
paginanummers zelf! De referentienummers zelf worden gecreëerd d.m.v. eerst de cryptografische
hashwaarden te bepalen van de tekst ‘Hello’ -> wat uiteindelijk hashwaarde 185F8DB3 oplevert in ons
voorbeeld. Vervolgens wordt de cryptografische hashwaarde van de paginanummers bepaalt o.b.v. de
inhoud van de pagina zelf, zijnde het referentienummer van de inhoud en het referentienummer van
de vorige pagina. In dit voorbeeld is de pagina met hashwaarde B779E800 bepaalt via de combinatie
van de hashwaarde van de vorige pagina (011C01C1) & de hashwaarde van de inhoud van de huidige
pagina (185F8DB3)68.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 116.
Door te werken met deze referentienummers kunnen we zonder problemen ons boek volledig
uit elkaar halen zonder dat we de logische ordening verliezen. Onderstaande afbeelding toont het
verschil dat we nu bereikt hebben voor en na het gebruik van referentienummers (die in werkelijkheid
cryptografische hashwaarden zijn)69.
68
69
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 116.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 117-118.
37
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 118.
Dit getransformeerde boek dat we gecreëerd hebben kan je steeds als stokpaardje gebruiken
omdat de idee net dezelfde is als bij de blockchaindatastructuur. Alleen gebruikt de
blockchaindatastructuur andere terminologie die in volgend stuk duidelijk zal worden.
Op
onderstaande afbeelding kan je de vergelijking zien van de eigenschappen van ons getransformeerde
boek met dat van een blockchaindatastructuur70.
70
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 118-119.
38
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 119.
Vooreerst moet men duidelijk het onderscheid zien tussen het hoofd van een
blockchaindatastructuur en de (verschillende) hoofdingen van een blockchaindatastructuur. Er is
slechts één hoofd bij elke blockchaindatastructuur terwijl er meerdere hoofdingen zijn binnen elke
blockchaindatastructuur.
De mentale éénheid van een pagina in de inhoudsopgave van het boek komt overeen met één blokje
in een blockchaindatastructuur. Die mentale éénheid is dus een apart iets dan de pagina zelf met haar
inhoud. Het zijn 2 fysiek aparte zaken die van elkaar moeten onderscheiden worden.
De inhoudsopgave zelf van het boek komt overeen met de ketting van hoofdingen in een
blockchaindatastructuur. Elke pagina van de inhoudsopgave komt overeen met één enkele hoofding
van een blokje in de blockchaindatastructuur. Die hoofdingen van elk blokje worden onderling
verbonden via referenties en vormen op die manier terug een ketting van blok(hoofdingen). Net zoals
het geval is bij onze inhoudsopgave, zijn die hoofdingen van elk blokje een apart iets en bewaren ze
enkel de hash referenties van de overeenkomende transactiedata.
De inhoud van de pagina’s komen overeen met de transactiedata zelf. Deze wordt beheerd door de
blockchaindatastructuur.
De paginareferentienummers in ons getransformeerde boek komen overeen met de cryptografische
hashwaarden van de individuele hoofdingen van elk blokje in de blockchaindatastructuur. Ze worden
block hashen genoemd. Die block hashen worden gebruikt om elke hoofding van een blokje op unieke
wijze te kunnen identificeren en tevens te verwijzen naar het voorgaande blokje. De effectieve
verwijzing naar het voorgaande blokje gebeurt dan weer effectief door gebruik van de hashreferentie.
De inhoudelijke referentienummers van de pagina’s in ons boek die gebruikt worden om de effectieve
pagina met haar inhoud te identificeren komen overeen met de hashreferenties in de ketting van
hoofdingen van blokjes die verwijzen naar de overeenkomende transactiedata. Meer specifiek zijn
voornoemde hashreferenties, die bewaard worden in een hoofding van elk blokje in de ketting, de
wortels in een database met een boomstructuur zoals eerder uitgelegd (zie boomstructuur op figuur
11-5)71.
71
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 119-122.
39
Onderstaande figuur (figuur 14-5) toont een vereenvoudigde weergave van het bewaren van vier
transacties in de blockchaindatastructuur. Het linkse blokje op de figuur is de eerste in de
blockchaindatastructuur. Dit blokje bevat dus geen hashreferentie naar een vorig blokje gezien het de
eerste in de ketting is. Het rechtse blokje op de figuur is de tweede in de ketting en bevat een
hashreferentie B1 naar het vorige blokje. De hoofdingen van elk blokje bevatten ook een specifieke
cryptografische hashreferenties die de wortel zijn van 2 onderscheiden boomstructuren. De wortels
zijn op deze figuur R12 en R34 voor respectievelijk blokje 1 en blokje 2. Deze geven al een indicatie van
de transactiedata waarnaar ze verwijzen -> R12 is de combinatie van de hashreferenties R1 en R2 die
op zich verwijzen naar transactie 1 en transactie 2. R34 is de combinatie van de hashreferenties R3 en
R4 die op zich dan weer verwijzen naar transactie 3 en 4.
Bij het toetreden van een gedistribueerd peer-to-peer systeem krijg je alle transactiedata, alle
hashreferentiewaarden en alle hoofdingen van elk blokje. Wanneer je toetreedt zal een nieuw blokje
gecreëerd worden bij het hoofd van de blockchaindatastructuur. Het hoofd is het laatst toegevoegde
blokje in de ketting. Op onderstaande figuur (figuur 14-5) is het hoofd van de ketting B272.
72
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 119-122.
40
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 121.
2.19.1 Het maken van kettingen van blokjes die data bevatten
Zoals uitgelegd in voorgaande stukje wordt de data bewaard via een ketting van blokjes die
hoofdzakelijk bestaat uit 2 grote componenten nl. de hoofdingen van elk blokje en de verschillende
boomstructuren binnen elk blokje die de transactiedata bevat.
Hoe komt het nu dat, d.m.v. die kettingen, de bewaring van die data op een veilige manier gebeurt en
dat ze bovendien ook wijzigingen veilig kan laten verlopen?
Om deze vraag te beantwoorden kan je de blockchaindatastructuur het best vergelijken met een
breiwerk. Je kan steeds makkelijk steken toevoegen, maar om voorgaande steken in je breiwerk te
wijzigen zal dat een lastig werkje zijn gezien je alle voorgaande steken opnieuw zal moeten doen. Alles
is zodanig met elkaar verbonden in een kettingstructuur dat het moeilijk is om iets wat vroeger werd
toegevoegd, nadien te gaan wijzigen. Bij een blockchaindatastructuur zal een nieuw blokje toevoegen
in de ketting gemakkelijk zijn. Daarentegen zal het een ander paar mouwen zijn om nadien in de ketting
een voorgaand blokje te gaan wijzigen73.
2.20 Het beveiligen van de opgeslagen data in de blockchain
In dit deel wordt duidelijk gemaakt hoe de opgeslagen data in de blockchain beveiligd wordt
opdat er geen vervalsing zou plaatsvinden en aldus de data ongewijzigd blijft. Dit is een zware opgave
gezien de blockchain een zuiver open gedistribueerd peer-to-peer netwerk is, wat simpelweg kan
vergeleken worden met een openbare plaats waar iedereen toegang tot heeft. Die gemakkelijke
toegang tot het netwerk maakt dat het netwerk blootgesteld is aan vervalsing/manipulatie van de
onderliggende data. Door de onderliggende data onwijzigbaar te maken hoeft niemand zich nog
zorgen te maken dat er onbetrouwbare leden de historie van transacties zouden gaan manipuleren
gezien dit onmogelijk is gemaakt74.
73
74
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 123-134.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 135-138.
41
Die onwijzigbaarheid kan men in de blockchain gaan verwezenlijken door de data een ‘alleenlees’ status toe te schrijven. ‘Alleen-lezen’ betekent dus in deze dat eens de data werd gecreëerd, ze
enkel nog kan gelezen worden en niet meer beschreven/gewijzigd kan worden. In het dagelijks leven
kan je dat best vergelijken met een identiteitskaart of een autorijbewijs. Dergelijke documenten
worden authentiek opgesteld door een welbepaalde instantie. Het document draagt meestal een
kenmerk met zich mee dat mensen afschrikt om het document te wijzigen of het te proberen
namaken75.
Het onwijzigbaar maken van de historie van transacties in de blockchain bevat 3 elementen:
1) De historie van transacties zodanig gaan opslaan dat zelf een minimale wijziging gedetecteerd wordt
2) Afdwingen dat het verwezenlijken van een manipulatie, het herschrijven van een groot deel van de
historie van transacties vereist
3) Zorgen dat het toevoegen, schrijven en herschrijven van data aan de historie van transacties veel
computerkracht vergt
Het eerste element wordt bereikt doordat bij elke minimale wijziging de hashwaarden niet meer
consistent zullen zijn met elkaar.
Het tweede element wordt bereikt doordat bij iedere wijziging de blockchaindatastructuur
noodzakelijk een volledige herschrijving van de historie (vanaf het punt van de wijziging) met zich
meebrengt.
Het derde element wordt bereikt doordat bij iedere hoofding van elk blokje een unieke hashpuzzle
dient opgelost te worden en dat zorgt ervoor dat veel computerkracht nodig zal zijn om al die puzzels
te gaan oplossen (zijnde vanaf het punt van de wijziging tot aan het hoofd van de ketting)76.
Een volgende stap, voor het bereiken van die gewenste onwijzigbaarheid van de
blockchaindatastructuur, is om het toevoegen van een nieuw blokje aan de ketting ook een zware
computertaak te maken. 3 aspecten zullen bij dit doel belangrijk zijn:
1) Verplichte data bij hoofdingen van blokjes
2) Het proces van de creatie van een nieuwe hoofding van een blokje
75
76
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
42
3) Vastgelegde regels die de bekrachtiging van de hoofdingen op zich nemen77
2.20.1 Verplichte data
Elke hoofding moet op zijn minst volgende data bevatten:
- De wortel van transactiedata
- Een hashreferentie naar de hoofding van het vorige blokje
- Het moeilijkheidsniveau van de hashpuzzel
- De tijd wanneer het oplossen van de hashpuzzel van start ging
- De nonce (lees: de juiste combinatie) die de correcte hashwaarde genereert en de hashpuzzel oplost78
2.20.2 De creatie van een nieuw blokje (met hoofding)
Het proces van de creatie van een nieuw blokje verloopt als volgt:
- Je neemt de wortel van de nieuwe boomstructuur die de transactiedata bevat die moet toegevoegd
worden.
- Creëer een hashreferentie naar de hoofding van dat blokje. Dat blokje zal dus nu dus het blokje zijn
dat voorafgaat aan ons nieuwe blokje.
- Verkrijg het vereiste moeilijkheidslevel.
- Neem de huidige tijd.
- Creëer een voorafgaande blokjeshoofding die de data bevat beschreven in voorgaande vier streepjes.
- Los de hashpuzzle op van voorafgaande blokjeshoofding.
- Maak het nieuwe blokje af door de nonce toe te voegen aan de hoofding van voorafgaand blokje die
de hashpuzzel oplost.79
77
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
79
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
78
43
Onderstaande figuur (Figure 16-1) geeft het proces op schematische wijze weer.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 140.
2.20.3 Bekrachtigingsregels
De bekrachtigingsregels zijn er om te verzekeren dat enkel die blokjes worden toegevoegd die
vooraf met succes de hashpuzzel hebben opgelost en waarvoor dus de nodige computerkracht is
gebruikt om ze op te lossen. Het oplossen van hashpuzzels wordt ook wel mining genoemd.
Elke hoofding van de blokjes in de blockchain moeten daarom voldoen volgende vereisten om de
bekrachtigingsregels tegemoet te komen:
1) Elke hoofding moet een hashreferentie bevatten die verwijst naar voorgaand blokje in de ketting
2) Elke hoofding moet een geldige wortel bevatten van een boomstructuur die transactiedata bevat
3) Er moet een juist moeilijkheidslevel aanwezig zijn
4) De tijdsweergave moet later zijn dan die van voorgaand blokje
5) Er moet een nonce aanwezig zijn
44
6) De hashwaarde van al de 5 stukken data tezamen bepaalt het moeilijkheidslevel80
Het moeilijkheidsniveau van de hashpuzzels zal bepalend zijn voor de vereiste tijd en
computerkracht die nodig is om iedere puzzel in de ketting op te lossen. Een te laag
moeilijkheidsniveau zorgt ervoor dat de nodes binnen de blockchain mogelijks de ketting te makkelijk
zouden kunnen gaan manipuleren en aldus de integriteit van de blockchain kwetsbaar wordt. Een te
hoog moeilijkheidsniveau kan dan weer nodes afschrikken om nieuwe transacties toe te voegen omdat
dit telkens een lange tijd duurt en veel computerkracht vergt vooraleer de nodige hashpuzzels opgelost
zijn om een nieuwe transactie toe te voegen of te wijzigen… Vandaar dat bij het ontwerp van een
blockchaindatastructuur vaak een dynamisch moeilijkheidsniveau van hashpuzzels zal toegepast
worden om met beide bezorgdheden rekening te houden. Dergelijk dynamisch moeilijkheidsniveau
houdt meestal in dat er voor verschillende blokjes andere moeilijkheidsniveaus worden toegepast en
tevens regelmatig wordt aangepast aan de snelheid waarmee er blokjes worden toegevoegd in de
ketting81.
2.21 De communicatie tussen de computers
Even ter herinnering: alle nodes (computers) in de blockchain maken deel uit van een zuiver
gedistribueerd peer-to-peer netwerk. Elke computer heeft haar eigen kopie van de historie van
transacties gevat in de blockchain. Net bij dit specifieke type netwerk, hebben de nodes geen centrale
entiteit waarop ze kunnen terugvallen om de info m.b.t. de historie van transacties te gaan bevestigen.
De bevestiging van de informatie zal dus niet komen van één centrale (betrouwbare) entiteit maar wel
van alle nodes als samenwerkend (betrouwbaar) geheel die de juistheid van informatie bekrachtigt.
Om dat samenwerkend geheel goed te laten werken zal communicatie tussen computers dus heel
belangrijk zijn! Het idee van die communicatie stemt overeen met dat van het delen van nieuws tussen
mensen onderling in het dagelijkse leven. De één vertelt het door aan de andere en die andere vertelt
het op zijn beurt door aan nog iemand anders en voor je het weet is iedereen op de hoogte van het
laatste nieuws. Het peer-to-peer systeem gebruikt dezelfde communicatie als groepen van mensen die
in het echte leven dagelijks informatie met elkaar delen. Zowel belangrijke als onbelangrijke informatie
wordt met elkaar gedeeld. In plaats van gesproken woorden gebruikt het peer-to-peer netwerk het
80
81
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
45
internet (een digitaal netwerk) als medium om met elkaar te communiceren. Het internet zorgt ervoor
dat:
-
elke computer verbonden is met het systeem
-
elke computer een uniek adres heeft
-
elke computer de keuze heeft om connectie te maken of die te verbreken op elk ogenblik
-
elke computer een lijst bijhoudt van de peers in het netwerk en dit onafhankelijk van de andere
computers
-
de communicatie tussen computers verloopt via berichten en deze berichten lopen langs elke
computers’ eigen unieke internetadres82
Omdat elke computer de mogelijkheid om de connectie met het systeem te verbreken op elk
ogenblik kan het zijn dat de levering van de berichten ofwel verloren geraken, ofwel meerdere malen
geleverd worden, ofwel in een andere volgorde geleverd worden…. Hieraan wordt nochtans verholpen
doordat alle peers elk bericht, dat ze ontvangen, doorsturen naar de andere peers. Het werkt als een
soort roddelsysteem waarbij elk verkregen bericht informatie wordt doorgestuurd. Dat zorgt ervoor
dat als er een bepaalde node een verloren bericht niet heeft gekregen alsnog krijgt.
Bovendien kunnen nodes gemakkelijk kopieën van berichten die ze reeds gezien hebben gaan negeren
op basis van hun cryptografische hashwaarde.
Tot slot zorgt de tijdstempel bij elk blokje en transactiedata ervoor dat de nodes o.b.v. die tijdstempel
een objectief criterium hebben om zich op te baseren en de volgorde hiermee vast te stellen. Deze
vorm van communicatie is belangrijk opdat elke node in het systeem een juist beeld heeft over het
eigenaarschap en alle specifieke details van de historie van transacties.
Er zijn 3 hoofddoelen bij het gebruik van communicatie tussen de nodes:
1) Het onderhouden van bestaande relaties
2) Het creëren van nieuwe relaties
3) Het verdelen van nieuwe informatie
82
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
46
Het eerste hoofddoel kan je vergelijken met de smalltalk die een groep van collega’s onderling houden
om de sociale relatie te bestendigen met die collega’s. In ons peer-to-peer systeem komt dit er in feite
op neer dat men af en toe naar de peers een klein berichtje zal sturen en wanneer daar een respons
op komt dan weet men dat die peer nog actief deelneemt in het systeem. Komt er geen antwoord dan
wordt die welbepaalde peer uit de lijst van peers verwijderd.
Het tweede hoofddoel is om nieuwe nodes in het systeem op te nemen. Dit kan gemakkelijk door een
louter verzoekbericht te sturen naar eender welke bestaande node in het systeem. Wanneer deze een
confirmatie stuurt dan neemt die jou als nieuwe toetredende node op in haar lijst van peers. De nieuwe
node kan dan een kopie van de historie van transacties krijgen van een reeds bestaande peer om zo
ook volledig up to date te zijn wat betreft het eigenaarschap van elke node in het systeem, elk blokje,
elke transactie, etc.
Het derde hoofddoel is om het bewijs van eigendom te gaan leveren door het verspreiden van info
m.b.t. de transacties, de wijziging van data, etc83.
2.21.1 Wat gebeurt er eens de nodes deze informatie hebben ontvangen?
Eens de nodes de informatie hebben ontvangen wordt de transactiedata en elk blokje bij elke
individuele node verwerkt en geverifieerd op zo een manier dat enkel de geldige transactiedata en
blokjes worden toegevoegd aan de blockchain. Die verificatie vindt plaats doordat elke peer in het
netwerk als een toezichthouder kan fungeren. Elke peer kan namelijk een beloning geven aan een
andere peer die een geldige transactie heeft toegevoegd in de ketting en/of heeft gewezen op fouten
in het werk van andere peers. Hierdoor wordt elke peer aangemoedigd om alles correct te laten
verlopen en toezicht te houden opdat de integriteit van het systeem wordt bewaard84.
2.21.2 Het blockchainalgoritme
Het blockchainalgoritme is een opeenvolging van instructies die bepaalt hoe de verschillende
nodes in de blockchain nieuwe transactiedata en blokjes moeten verwerken.
83
84
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
47
Het ultieme doel van dit algoritme is om ervoor te zorgen dat enkel de geldige transactiedata en blokjes
worden toegevoegd aan de blockchain.
Om de nodes te stimuleren deze geldigheidsregels na te leven, werkt het blockchainalgoritme met
beloning, straffen en competitie.
Het werkt enerzijds met beloningen voor de peers die geldige blokjes toevoegen of m.a.w. zij die
correct de hashpuzzel hebben opgelost.
Anderzijds worden peers die het systeem tegenwerken gestraft. Die straffen kunnen variëren. Vaak
worden peers gestraft als blijkt dat een blokje dat in het verleden als geldig werd gezien maar later als
corrupt, dan zal men de beloning voor dat blokje terugclaimen van die welbepaalde peer. Soms ook
gewoon de afwezigheid van enige beloning is een straf op zich. Dit laatste net omdat het tijd en moeite
kost om die hashpuzzels op te lossen. Als je niet beloond wordt dan zullen die kosten voor niets
gemaakt zijn.
Tot slot werkt het blockchainalgoritme ook met competitie. Deze competitie is een wedstrijd die je op
2 vlakken dient te winnen alvorens je de beloning, voor het toevoegen van een nieuw blokje, ontvangt.
Je hebt enerzijds een snelheidscompetitie en anderzijds een kwaliteitscompetitie. Het eigenaardige
aan deze competitie is dat de verliezers van de snelheidscompetitie de scheidsrechters zullen zijn in
de kwaliteitscompetitie85.
2.21.2.1 De snelheidscompetitie
De snelheidscompetitie is kort en duidelijk. De eerste node die de hashpuzzel oplost en het
nieuwe blokje aanmaakt is de winnaar. Enkel hij zal de enige kandidaat zijn in de kwaliteitscompetitie86.
2.21.2.2 De kwaliteitscompetitie
Deze competitie doelt enkel op de controle van de juistheid van het nieuw toegevoegde blokje.
Het nieuwe toegevoegde blokje zal naar alle nodes in het systeem gestuurd worden om de
kwaliteitscontrole van de betrokken transactiedata en hoofding van het blokje na te gaan. Deze
85
86
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
48
controle gebeurt volgens de voordien besproken geldigheidsregels. Indien het nieuwe blokje de
controle doorstaat dan krijgt de node die het blokje aanmaakte de beloning en wordt er een nieuwe
snelheidscompetitie opgestart voor toekomstige blokjes. Indien daarentegen het nieuwe blokje de
controle niet doorstaat en dus niet voldoet aan de kwaliteitsvereisten dan begint de
snelheidscompetitie opnieuw voor desbetreffende transactiedata en wordt het blokje dat de controle
niet heeft doorstaan, verwijderd. Wanneer een blokje als ongeldig wordt aangemerkt in een fase nadat
het blokje reeds werd toegevoegd dan worden het blokje en de opeenvolgende blokjes eigenlijk niet
echt fysiek verwijderd uit de blockchain maar worden ze als ongeldig gemarkeerd. Op die manier blijft
elke wijziging die ooit in de blockchain heeft plaatsgevonden aanwezig maar hebben die ongeldige
blokjes geen werkelijk effect. Doordat de peers als scheidsrechters fungeren in deze competitie en zelf
ook nog voordeel kunnen halen uit een ongeldig blokje (nl. zelf terug meedoen in de competitie als het
blokje niet voldoet aan de geldigheidsvereisten), is deze controle van hoge kwaliteit en benadert ze
een hoge accuraatheid.
Alle nodes in het systeem zitten in een gelijklopende werkingsfase. De nodes volgen allen éénzelfde
ritme. Ofwel zijn alle nodes aan het controleren of het nieuwe blokje voldoet aan de geldigheidsregels,
ofwel zijn de nodes zelf een hashpuzzel aan het oplossen om een nieuw blokje te creëren met nieuwe
transactiedata87.
2.22 De meest voorkomende misbruiken door oneerlijke spelers in de blockchain
De meest voorkomende misbruiken zijn volgende:
-
Het toevoegen van transacties door zich voor te doen als iemand anders
-
Het accepteren van ongeldige transactiedata en blokjes
-
Het overbelasten van een node met transactiedata met als doel hem te laten crashen
-
Het weigeren om bepaalde transactiedata te controleren
-
Het weigeren om transactiedata door te sturen naar alle andere nodes
Voorgaande soorten misbruik worden reeds opgevangen op volgende wijze:
-
Het veiligheidsconcept van de transacties (identificatie, authenticiteit en autorisatie via
asymmetrische cryptografie en digitale sleutels)
87
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
49
-
Het roddelmodel voor het verspreiden van informatie waardoor elke node over de nodige
informatie beschikt
-
Het architecturaal model dat ervoor zorgt dat bij het uitvallen van individuele nodes, het systeem
zelf niet uitvalt
-
Het blockchainalgoritme
De veiligheid van het systeem wordt voornamelijk bereikt door de assumptie dat er een
meerderheid eerlijke spelers is en de minderheid die oneerlijk is, wordt gecounterd door de eerlijke
meerderheid88.
2.23 De transactiehistorie(s)
Gezien elke individuele node onafhankelijk haar eigen historie van transacties aanmaakt,
bestaat de kans dat door vertragingen en/of fouten in de overdracht van informatie, er histories van
transacties bestaan die onderling verschillen tussen de nodes. Om deze verschillen tussen de nodes in
het systeem aan te pakken, is er een oplossing bedacht. De oplossing om deze verschillen te
overkomen is een gedistribueerde consensus bereiken tussen de individuele nodes over de keuze wat
nu de transactiehistorie is die alle nodes zien als de werkelijke. Deze ‘werkelijke’ of ‘samen
overeengekomen’ transactiehistorie wordt ook wel de autoritaire transactiehistorie genoemd89.
Om tot een autoritaire transactiehistorie te komen hebben de nodes nochtans wel een
gemeenschappelijk criterium nodig waar ze hun keuze kunnen van laten afhangen. Dit criterium is de
hoeveelheid gemaakte computerkost geworden. Dit criterium heeft op haar beurt geleid tot een
opsplitsing van 2 criteria nl. het langste-ketting-criterium en het zwaarste-ketting-criterium90.
2.23.1 Het langste-ketting-criterium
Het idee van het langste-ketting-criterium is dat de blockchaindatastructuur met de meeste
blokjes ook meteen de datastructuur is waarvoor het meeste computerkosten zijn gemaakt.
88
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
90
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
89
50
Om een beter beeld te krijgen op dit criterium starten we met een initiële blockchaindatastructuur die
op vereenvoudigde wijze wordt weergegeven op onderstaande figuur (figuur 19-1). De blokjes op de
figuur stellen één blokje voor in de blockchaindatastructuur met een verkorte hashwaarde in. Het
pijltje stelt een hashreferentie voor die verwijst naar een voorgaand blokje met hashwaarde 33FF. Alle
nodes gaan akkoord met één transactiehistorie en willen nu een nieuw blokje toevoegen aan de ketting
die op haar beurt verwijst naar blokje A39791.
Bron: DRESCHER, D., Blockchain
Basics: A Non-Technical Introduction
in 25 Steps, New York, Apress, 2017,
169.
Op onderstaande figuur (figuur 19-2) zie je de blockchaindatastructuur na het toevoegen van een
nieuw blokje AB12. Op figuur 19-2 zie je dus de situatie dat één node de hashpuzzel van het nieuwe
blokje heeft opgelost en vervolgens verstuurd naar alle overige peers. Nu zullen de volgende peers een
nieuw blokje willen toevoegen dat verwijst naar AB12 als voorgaand blokje92.
91
92
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
D. DRESCHER, Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017.
51
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 170.
Nochtans is dit enkel het geval voor de meerderheid van de peers. Door een vertraging van de
berichtgeving (cf. vertraging doordat de berichtgeving via een netwerk moet passeren) over het
nieuwe blokje (AB12) is er nog steeds een minderheid van de peers die zich baseren op de ketting als
weergegeven op figuur 19-1. Uiteindelijk is er één van de nodes uit die minderheid die erin slaagt om
de hashpuzzel op te lossen van een nieuw blokje met hashwaarde DD01 en verstuurt dit naar alle
overige peers. Zo gebeurt het dat uiteindelijk de meerderheid van de nodes zowel blokje AB12 als
blokje DD01 ontvangen.
Die
meerderheid
van
de
nodes
baseert zich
nu op een
blockchaindatastructuur als weergegeven op onderstaande figuur (figuur 19-3). Het langste-kettingcriterium biedt nu geen soelaas gezien het telkens gaat om 3 blokjes, ofwel AB12-A397-33FF ofwel
DD01-A397-33FF. De nodes zijn in deze situatie dus vrij om zich op de ene tak met AB12 erin ofwel op
de andere tak met DD01 erin te baseren en daarop voor te bouwen93.
Bron: DRESCHER, D., Blockchain
Basics: A Non-Technical Introduction
in 25 Steps, New York, Apress, 2017,
125.
Nu we met deze situatie geconfronteerd worden, kan het zich voordoen dat er 2 nodes quasi
tegelijkertijd een hashpuzzel oplossen en elke node een nieuw blokje toevoegt, respectievelijk een
blokje met hashwaarde BB11 en een blokje met hashwaarde CCC1. Elk van deze 2 blokjes heeft een
hashreferentie die AB12 als voorgaand blokje aanduidt. Door de incorporatie van deze 2 blokjes in de
blockchaindatastructuur kom je met 3 kettingen te zitten waarbij er 1 bestaat uit 3 blokjes en 2 uit 4
blokjes (zie onderstaande figuur 19-4). Het langste-ketting-criterium kan bij deze met zekerheid één
93
52
ketting uitsluiten nl. de kortste ketting zijnde DD01-A397-33FF. Maar dan zit je nog steeds met 2
kettingen van dezelfde lengte94.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 171.
Opnieuw zorgt deze situatie ervoor dat potentieel nieuwe blokjes zich kunnen gaan baseren op de ene
ofwel de andere ketting. Uiteindelijk doet het zich voor dat er een node de hashpuzzel oplost voor een
nieuw blokje (0101) en gebruikt BB11 als het voorgaande blokje (zie onderstaande figuur 19-5).
Volgens het langste-ketting-criterium is het nu duidelijk welke ketting het langste is nl. die met 0101
in. De meerderheid van de nodes zullen uiteindelijk allen deze ketting volgen en gebruiken als de
authentieke ketting om eigenaarschap mee te bewijzen. De nodes zullen nu dus bij de creatie van een
nieuw blokje, willen verwijzen naar 0101 als voorgaand blokje. Bovendien wordt ook hier duidelijk dat
de blockchain grafisch niet echt volledig overeenstemt met een rechtlijnige ketting zoals wij die
gewoonlijk kennen. Het is eerder een ketting die de vorm aanneemt van een boom. Vandaar ook dat
men het beginblokje (=blokje zonder voorganger) in de ketting de wortel noemt. Het eindblokje
(=blokje zonder nakomend blokje) noemt men dan weer het blad en de volledige sequentie van wortel
tot blad noemt men het pad95.
94
95
53
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 172.
2.23.2 Het zwaarste-ketting-criterium
Het idee van het zwaarste-ketting-criterium houdt in dat je met een blockchain zit die gebruik
maakt van hashpuzzels met een dynamisch (veranderlijk) moeilijkheidsniveau. Dit wil zeggen dat het
moeilijkheidsniveau van de hashpuzzel van elk blokje veranderlijk is. Dit zorgt ervoor dat je bij een
blockchain die dynamisch moeilijkheidsniveaus gebruikt, niet zozeer kan zeggen dat de langste ketting
ook diegene is waarvoor de meeste computerkracht is gebruikt. In het geval van een blockchain met
dynamisch moeilijkheidsniveau moet je kijken naar het pad waarbij de som van alle
moeilijkheidsniveau in dat pad, ook de grootste is. Men noemt die som van moeilijkheidsniveaus ook
wel eens het gewicht van een pad. Slechts het pad met het grootste gewicht zal volgens het zwaarsteketting-criterium gezien worden als de authentieke ketting (zie figuur 19-6 op de volgende pagina
waarbij op elk blokje het moeilijkheidsniveau van de hashpuzzel wordt weergegeven)96.
96
54
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 174.
Als besluit hier, mag het duidelijk zijn dat men bij een blockchain met dynamisch moeilijkheidsniveau
steeds voor het zwaarste-ketting-criterium zal kiezen om een authentiek pad te kiezen.
2.23.3 De gevolgen van het kiezen van één autoritaire ketting
Het kiezen van één autoritaire ketting/pad binnen de blockchain brengt enkele gevolgen met
zich mee:
-
Zwevende/vrijstaande blokken
-
Teruggeclaimde beloningen
-
Verduidelijking van eigenaarschap
-
Herbekijken van transacties
-
Een groeiende gemeenschappelijke kruin
-
Een uiteindelijke consistentie
55
-
Sterk optreden tegen manipulaties97
2.23.3.1 Zwevende/vrijstaande blokken
Omdat we kiezen voor één autoritaire ketting, zijn er in onze blockchain bepaalde blokjes die
er niet meer toe doen. Deze blokjes, die de dans ontspringen a.h.w., noemen we de zwevende of
vrijstaande blokjes. Op voorgaande figuur (figuur 19-6) zijn de zwevende blokjes 0101, BB01 en DD0198.
2.23.3.2 Het terug claimen van beloningen
De zwevende blokjes zijn eigenlijk nutteloos binnen de blockchain eens er een autoritaire
ketting is gekozen. De beloningen die werden gegeven aan de nodes die de zwevende blokjes hebben
gecreëerd moeten daarom ook worden teruggedraaid en opnieuw worden gerecupereerd van die
nodes99.
2.23.3.3 Verduidelijking van eigenaarschap
De transactiedata die vervat zit in de zwevende blokjes wordt niet meer gebruikt en de
gevolgen die ze voordien met zich meebracht zullen worden ongedaan gemaakt gezien deze door de
autoritaire ketting buitenspel wordt gezet. Enkel de transactiedata vervat in de blokken die deel
uitmaken van de autoritaire ketting zullen worden gebruikt en de gevolgen op het vlak van
eigenaarschap zullen enkel hier effect hebben100.
2.23.3.4 Herbekijken van transacties
97
98
99
100
56
De transactiedata die deel uitmaakte van de zwevende blokjes komt terug in de inbox van de nodes
om ze een tweede kans te geven om uiteindelijk toch nog in de transactiehistorie te geraken binnen
de autoritaire ketting. Deze transactiedata wordt a.h.w. herbekeken101.
2.23.3.5 Een uiteindelijke consistentie
De groei van de blockchain wordt bepaald door de snelheidsrace waaraan de nodes
deelnemen zijnde proberen om als eerste één van de hashpuzzels op te lossen en bovendien wordt de
groei van de blockchain ook bepaald door de vrijheid die elke node bezit om te kiezen aan welke tak
binnen de boomstructuur ze hun blokje willen voortbouwen en de vertragingen waaronder de
berichtgeving verloopt via het netwerk tussen de nodes onderling. Ondanks de willekeurigheid welke
blokjes nu uiteindelijk binnen de autoritaire ketting behoren en welke er afvallen, kan men toch iets
besluiten dat de consistentie ten goede komt. Hoe dieper een blokje zit in de autoritaire ketting, :
-
Hoe verder het blokje in het verleden werd toegevoegd.
-
Hoe meer tijd er is verlopen sinds de toevoeging ervan.
-
Hoe meer gemeenschappelijke kosten er zijn gemaakt in de navolgende blokjes.
-
Hoe minder invloed ze ondervinden van willekeurige veranderingen van blokjes die behoren tot
de langste ketting.
-
Hoe minder reëel het is dat het blokje zal afvallen.
-
Hoe meer geaccepteerd het blokje is door de nodes in het systeem.
-
Hoe meer verankerd het blokje zit in de gemeenschappelijke historie van de nodes.
Als besluit van dit gevolg kan je stellen dat hoe meer blokjes er worden toegevoegd aan de blockchain,
des te groter de zekerheid is dat een blokje binnen de autoritaire ketting zit. Dit verschijnsel wordt
uiteindelijke consistentie genoemd.
2.23.3.6 Sterk optreden tegen manipulaties
Om de blokjes binnen de autoritaire ketting te manipuleren, die door de meerderheid van de
nodes wordt beheerd en aangehouden, zullen aanvallers van de blokjes binnen de autoritaire ketting
alle hashpuzzels vanaf het eerste blokje in de autoritaire ketting terug opnieuw moeten doen en de
101
57
hashwaarden overigens eraan aanpassen om de autoritaire ketting, die door de meerderheid van
eerlijke nodes wordt gedragen, te overstijgen. Dit is een quasi onmogelijke opgave voor de potentiële
aanvaller van de autoritaire ketting tenzij de potentiële aanvaller over een grotere gebundelde
computerkracht beschikt dan alle eerlijke nodes tezamen die tenslotte deel uitmaken van de
meerderheid binnen het systeem… Geen gemakkelijke opdracht dus voor potentiële fraudeurs.
Doordat de frauduleuze pogingen altijd zullen ingehaald worden door grotere snelheid van de eerlijke
meerderheid binnen het systeem, is de autoritaire transactiehistorie gesterkt tegen potentiële
aanvallen.
2.24 Fraudegevoeligheid van collectieve beslissingen
Elk systeem met een collectieve beslissingsprocedure staat bloot aan manipulatie. De
blockchain en haar gedistribueerd consensusalgoritme zijn hierin niet anders. Men kan een blockchain
manipuleren door van de blokjes, die binnen de autoritaire ketting zitten, zwevende blokjes te maken
en de actieve autoritaire ketting te vervangen door een nieuwe autoritaire ketting die een andere
transactiehistorie weergeeft nl. een nieuwe transactiehistorie die de aanvaller veel beter uitkomt.
Vanuit het standpunt van de aanvaller kan je meer specifiek in 3 meer specifieke doelen distilleren uit
voorgaand (algemeen) doel. Economisch gezien is een manipulatie van de transactiehistorie
interessant omdat de aanvaller hiermee de eigendomsrechten naar zijn hand kan zetten. Vanuit een
technisch standpunt is een aanval op de collectieve beslissingsprocedure ook een aanval op de
integriteit van het volledige systeem. Architecturaal kan je dergelijke aanval ook zien als een poging
om de staat van het systeem te veranderen door in het gedistribueerd systeem (op zijn minst tijdelijk)
een element van centraliteit toevoegen. Ten slotte kan je de aanval ook in technisch opzicht zien als
een poging om de integriteit van het systeem te ondermijnen.
Deze aanvallen worden vaak 51 percent aanvallen genoemd omdat de aanvaller er een machtspositie
wenst mee te bekomen in de collectieve beslissingsprocedure. Deze machtspositie komt uiteraard
quasi neer op een vetorecht.
2.24.1 De rol van de hashpuzzel
Een machtspositie verwerven in de blockchain staat gelijk aan de meerderheid van
computerkracht bezitten in het peer-to-peer systeem gezien stemrecht in de collectieve
58
beslissingsprocedure gelinkt wordt aan het oplossen van hashpuzzels en hiervoor is computerkracht
vereist.
2.24.2 De draagwijdte van beloning als instrument voor bijdragen aan de integriteit van het systeem
Het oplossen van de hashpuzzels is een belangrijk element om de integriteit van het peer-topeer systeem te bereiken en te behouden. Hiervoor is computerkracht vereist en bijgevolg kost het
geld. Om peers aan te zetten die kosten te blijven maken, moet er iets tegenover staan. Vooraf sprak
ik al over het feit dat nodes binnen het systeem beloond werden voor het oplossen van de hashpuzzels.
Maar wat is die beloning nu juist? Wat staat er effectief als vergoeding tegenover de kosten die de
peers maken?
Het kiezen van een betalingssysteem voor het toekennen van de vergoedingen aan de peers is
één van de grote uitdagingen voor elke blockchainapplicatie. Bij het kiezen van een betalingssysteem
moet rekening worden gehouden met volgende mogelijke gevolgen:
-
De impact op de integriteit van het systeem
-
De impact op de openbaarheid van het systeem
-
De impact op de gedistribueerde natuur van het systeem
-
De impact op de filosofie van het systeem
2.24.2.1 De impact op de integriteit van het systeem
De keuze van het betalingsinstrument, dat gebruikt wordt om de nodes te belonen voor hun
bijdrage aan het systeem, heeft een directe weerslag op de geloofwaardigheid van de gehele
blockchain zelf!
2.24.2.2 De impact op de openbaarheid van het systeem
Gezien de blockchain wordt verondersteld een open peer-to-peer systeem te zijn, kan
iedereen zijn of haar computer aansluiten op het systeem en zal hij of zij beloond worden voor de
bijdrage aan de integriteit van het systeem. De openbaarheid van de blockchain zelf zal dus pas echt
openbaar zijn als het gekozen betalingsinstrument ook openbaar is. Wat bedoel ik hier nu mee… Wel,
59
het gekozen betalingsinstrument mag niet gehinderd worden door bepaalde landelijke restricties of
bepaalde transfergrenzen die zouden gelden. Hierdoor zou de technische openbaarheid van de
blockchain zelf gehinderd worden door de economische grenzen van het gekozen betalingsinstrument.
2.24.2.3 De impact op de gedistribueerde natuur van het systeem
Het gekozen betalingsinstrument mag evenmin centraal beheerd worden want dan laat je toe
dat er een element van centraliteit in uw zuiver gedistribueerd peer-to-peer systeem binnensluipt. Dit
zou indruisen tegen de gedachte van decentralisatie die essentieel is in de blockchain.
2.24.2.4 De impact op de filosofie van het systeem
Al de voorgaande puntjes tonen aan dat de keuze van een betalingsinstrument op
verschillende manieren een impact kunnen hebben op essentiële eigenschappen van de blockchain. Is
het dan wel überhaupt mogelijk dat een blockchain, die beweert een zuiver gedistribueerd open peerto-peer systeem te zijn, geloofwaardig kan zijn bij de keuze van dergelijk betalingsinstrument dat
mogelijks indruist tegen de essentiële eigenschappen van dat systeem? Dit vormt een fundamentele
vraag voor elke blockchain.
2.24.3 Welke eigenschappen zijn gewenst bij de keuze van het betalingsinstrument dat gebruikt wordt
voor de beloning van de peers?
Een betalingsinstrument bevat best volgende eigenschappen om zo min mogelijk in te druisen
tegen de essentiële elementen van de blockchain:
-
Het betalingsinstrument bestaat best in digitale vorm gezien de blockchain zelf ook digitaal is.
-
Het betalingsinstrument moet aanvaard zijn in de werkelijke wereld.
-
Het betalingsinstrument moet overal ter wereld aanvaard zijn. Dus geen territoriale beperkingen.
-
Het betalingsinstrument mag geen transfergrenzen kennen. M.a.w. geen beperkingen van
kapitaalverkeer.
-
Het betalingsinstrument moet een stabiele waarde bezitten.
-
Het betalingsinstrument moet geloofwaardig zijn.
-
Het betalingsinstrument mag niet beheerd worden door één centrale organisatie.
60
Ik heb nu steeds gesproken over ‘betalingsinstrument’ maar je kan het evengoed zien als
‘munteenheid’. Al deze voorgaande eigenschappen zien eruit als een lijstje met tools voor de creatie
van een ideale wereldmunt. Merk tevens op dat de huidig bestaande munteenheden in de reële wereld
niet voldoen aan elk van deze eigenschappen. Kortom, er bestaat voorlopig nog geen perfect
betalingsinstrument als je deze lijst van eigenschappen als indicator neemt.
Dit brengt mij eveneens bij het fenomeen van de cryptografische munten. Bitcoin102 is één van
die cryptografische munten. Het Bitcoinsysteem is een blockchain die zijn applicatiedoel, zijnde het
beheer van eigenaarschap van een nieuwe digitale munt (Bitcoin), linkt aan de behoefte om een
betrouwbare compensatie te hebben voor leden die aan de integriteit van de blockchain bijdragen.
Metaforisch kan je dit gaan vergelijken met een chocolatier die zijn werknemers uitbetaalt met de
chocolade die hij zelf produceert.
2.25 Het complete plaatje van wat blockchain nu eigenlijk is
102
N. SATOSHI, Bitcoin: a peer-to-peer electronic cash system, www.bitcoin.org/bitcoin.pdf (consultatie 4 oktober
2018).
61
Onderstaande Tabel (Table 21-2) is een samenvattende weergave van de (individuele) concepten van
de blockchain (concept), hun beoogde doel (purpose) en de beeldspraak (metaphor used) die je als
ezelsbrug kan gebruiken bij het onthouden ervan.
Bron:
DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017,
190.
62
Bron:
DRESCHER,
D.,
Blockchain
Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017, 191.
Hoe al die (individuele) concepten van blockchain nu (als geheel) tezamen werken wordt duidelijker
als we blockchain terug als systeem op zich gaan analyseren zoals we gedaan hebben in het begin van
onze reis nl. de blockchain opdelen in lagen en aspecten. (zie onderstaande tabel (Table 21-3)).
63
2.25.1 Het doel van de blockchain: functionele aspecten op het applicatieniveau
Bron: DRESCHER, D.,
Blockchain Basics: A
Non-Technical
Introduction in 25 Steps,
New York, Apress, 2017,
192.
2.25.1.1 Het vaststellen van eigenaarschap
Het vaststellen van eigenaarschap beantwoord de cruciale vraag bij eigendomskwesties: Wie
bezit wat op welk moment en welke hoeveelheid?
2.25.2.2 Het veranderen van de huidige staat van eigenaarschap
Het veranderen van de huidige staat van eigenaarschap houdt de mogelijkheid in om als
eigenaar uw eigendom over te dragen aan iemand anders. Het beantwoord dus de cruciale vraag die
van belang is bij het vaststellen van eigenaarschap: Wie heeft iets overgedragen, wat heeft die persoon
overgedragen, welke hoeveelheid is er overgedragen en naar welke persoon?
2.25.2 Eigenschappen van de blockchain: niet-functionele aspecten
De kwaliteit waarmee de blockchain haar doelen bereikt wordt bepaald door de nietfunctionele aspecten:
1) De hoge beschikbaarheid
2) Vrij van censuur
3) Betrouwbaar
4) Open
5) Pseudo(ano)niem
6) Veilig
7) Veerkrachtig
8) Uiteindelijk consistent
9) Behouden van de integriteit
64
2.25.2.1 De hoge beschikbaarheid
De hoge beschikbaarheid komt erop neer dat de blockchain nooit uitvalt en 24/24, 7 dagen op
7 en elk jaar beschikbaar is.
2.25.2.2 Vrij van censuur
Er is geen enkel individu die een inhoudelijke controle zal doorvoeren van wat er circuleert
binnen de blockchain. Bovendien kan geen enkel individu het hele systeem uitzetten.
2.25.2.3 Betrouwbaar
2.25.2.4 Open
2.25.2.5 Pseudo(ano)niem
2.25.2.6 Veilig
65
2.20.2.7 Veerkrachtig
2.25.2.8 Uiteindelijk consistent
2.25.2.9 Behouden van de integriteit
2.25.3 Interne functionering: Functionele aspecten op de implementatielaag
-
Eigendomslogica
-
Transactieveiligheid
-
Transactieprocedurelogica
-
Opslaglogica
-
Peer-to-peer architectuur
66
-
Consensuslogica
2.25.3.1 Eigendomslogica (ownership logic)
De eigendomslogica (ownership logic) die gebruikt wordt in de blockchain hangt af van een
opslaglogica (storage logic) die de volledige historie van transactiedata beheerst en tevens van een
consensus logica (consensus logic) die de consistentie van de data verzekert. Bijkomend hangt de
eigendomslogica af van de transactieproceslogica (transaction processing logic) die ervoor zorgt dat
67
enkel geldige transactiedata wordt toegevoegd aan de blockchain en tevens van de
transactieveiligheid die verzekert dat enkel de rechtmatige eigenaar zijn/haar eigendom kan
overdragen naar iemand anders.
2.25.3.2 Transactieveiligheid (Transaction security)
Zoals hiervoor al werd geduid zorgt de transactieveiligheid ervoor dat enkel de rechtmatige
eigenaar toegang heeft tot zijn eigendom of kan overdragen. Onderstaande figuur (figuur 21-2) is een
weergave van de onderliggende concepten die nodig zijn bij het implementeren transactieveiligheid.
Opnieuw zijn de onderliggende concepten een noodzakelijk kwaad om de concepten, die in de boxen
bovenop liggen, te realiseren. Zo is autorisatie (authorization) pas mogelijk door het bestaan van een
digitale handtekening (digital signature) die op haar beurt bestaat uit cryptografische hashwaarden
(cryptographic hash values).
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 196.
68
2.25.3.3 Transactieprocedurelogica (transaction process logic)
De transactieprocedurelogica zorgt ervoor dat enkel geldige transacties plaatsvinden en enkel
deze laatste worden toegevoegd en beheerd door de historie van transactiedata. Onderstaande figuur
(figuur 21-3) is een weergave van de onderliggende concepten die de transactieprocedurelogica
verwezenlijken.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 197.
2.25.3.4 Opslaglogica (Storage logic)
De opslaglogica houdt zich bezig met in stand houden van de volledige historie van
transactiedata en het beschermen ervan tegen enige vorm van manipulatie of fraude. De opslaglogica
geeft vorm aan het idee dat data in de blockchain zeer moeilijk te veranderen is en een kostbare taak
inhoudt. De figuur (figuur 21-4 op volgende pagina) is een weergave van de opslaglogica en haar
onderliggende concepten.
69
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 198.
2.25.3.5 Peer-to-peer architectuur
De architectuur van een systeem bepaalt hoe de nodes of componenten van het systeem met
elkaar verbonden zijn. Zoals reeds duidelijk werd in voorgaande uitleg, bestaat de blockchain uit een
zuiver gedistribueerd peer-to-peer systeem bestaande uit onafhankelijke peers die nodes worden
genoemd.
Onderstaande figuur (figuur 21-5) is een weergave van het concept van de peer-to-peer architectuur
waaruit de blockchain is opgebouwd. Onafhankelijke nodes (independent nodes/peers) zijn verbonden
in het systeem via een netwerk (network) en wisselen informatie uit op een wijze die vergelijkbaar is
zoals het verspreiden van roddels in de echte wereld (gossip-style message passing).
70
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 198.
2.25.3.6 Consensuslogica
De consensuslogica zorgt ervoor dat alle nodes in de blockchain uiteindelijk één autoritaire
historie van transactiedata gebruiken nl. diegene die het meest collectieve inspanningen heeft
geleverd.
Onderstaande figuur (figuur 21-6) is een weergave van de consensuslogica met haar onderliggende
concepten.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 199.
2.26 Abstractie maken
71
Abstractie maken van alles wat we tot nu toe gezien hebben bereiken we door de verschillende
componenten van de blockchain te gaan opdelen naargelang het doel dat ze vervullen nl. ofwel de
componenten die specifiek een applicatiedoel nastreven ofwel componenten die het applicatiedoel
overstijgen.
Onderstaande figuur (figuur 21-7) toont de opsplitsing van de componenten van de blockchain zoals
hierboven vermeld.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 200.
In dit deel heb ik proberen een overzicht te geven van de belangrijkste concepten van de blockchain
en hun onderlinge afhankelijkheid.
In het volgende deel proberen we de beperkingen van de blockchain nader te bekijken.
2.27 Hoe kunnen de beperkingen van de blockchain overtroffen worden ?
72
Ondanks dat de blockchain prachtig in elkaar steekt, kunnen we toch kanttekeningen maken.
Geen enkel systeem is perfect. Zelf een systeem dat perfect blijkt te zijn op het eerste zicht, heeft
sowieso nog een aantal beperkingen. Dat is bij de blockchain niet anders…
2.27.1 Technische beperkingen van de blockchain
2.27.1.1 Een tekort aan privacy
Net omdat de toegang tot de blockchain openstaat voor iedereen is er geen privacy wat betreft
de details van de transactiedata. Alle peers beschikken over toegang tot de details van alle
transactiedata. Dit is een constitutioneel element van de blockchain. Het zorgt er namelijk voor dat
elke peer het eigenaarschap kan vaststellen en/of elke overdracht van eigendom kan verifiëren. Dit
tekort aan privacy zorgt ervoor dat gevoelige informatie die niet voor publieke ogen mag blootgesteld
worden, vaak geen geschikt voorwerp is om te laten circuleren in een grootboek zoals de blockchain.
2.27.1.2 Het veiligheidsmodel
De veiligheid van transacties in de blockchain wordt verzekerd door het gebruiken van een
private en een publieke sleutel. Dit zijn de zogeheten digitale handtekeningen. Enkel wie de
corresponderende private sleutel bevat (wat op zich een cryptografische hashwaarde is), krijgt toegang
tot de eigendom die toebehoort aan het desbetreffend accountnummer (zijnde de corresponderende
publieke sleutel). Zoals reeds werd verteld wordt dit gerealiseerd doordat de blockchain gebruik maakt
van asymmetrische cryptografie.103 Dit is tot op heden de meest geavanceerde vorm van cryptografie
die er bestaat. Op zich is er dus niks mis met het veiligheidsmodel van de blockchain maar er is geen
bijkomend veiligheidsmechanisme die ervoor zorgt dat peers hun private sleutel verliezen of
onvrijwillig delen met anderen. Nochtans is dit niet verschillend van de veiligheidsopties die reeds
bestaan in de echte wereld tot nu toe… Denk maar aan je huissleutel of de pincode die je gebruikt voor
je bankkaart. Ook als je deze verliest of doorgeeft aan anderen bestaat de kans dat er misbruik
plaatsvindt…
103
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 16-17.
73
2.27.1.3 Beperkte schaalbaarheid
2.27.1.4 Hoge kosten
2.27.1.5 Verborgen centraliteit
104
EDWIN, Wat is blockchain scaling (schaalbaarheid) en waarom is het zo belangrijk?,
https://www.bitcoinsaltcoins.nl/is-blockchain-scaling-schaalbaarheid-en-waarom-belangrijk/ (consultatie 15
april 2019); T.C. INVSTOR, Schaalbaarheid, https://thecryptoinvstor.nl/crypto-termen/schaalbaarheid
(consultatie 15 april 2019); WIKIPEDIA, Schaalbaarheid, https://nl.wikipedia.org/wiki/Schaalbaarheid
(consultatie 15 april 2019).
105
BITCOINWIKI, Scalability, https://en.bitcoin.it/wiki/Scalability#Scalability_targets (consultatie 15 april 2019).
106
74
2.27.1.6 Het gebrek aan flexibiliteit (cf. onwijzigbaarheid/immutability van de blockchain)
2.27.1.7 De kritieke grootte van het aantal betrouwenswaardige nodes
2.27.2 Niet-technische beperkingen van de blockchain
2.27.2.1 Gebrek aan wettelijke regeling
107
108
75
2.20.2.2 Gebrek aan gebruikersaanvaarding
2.27.3 Het overstijgen van de beperkingen van de blockchain
De technische beperkingen overkomen zal een werk zijn op alle technische niveaus en alle
componenten. Eén van de grootste uitdagingen om de technische beperkingen te overkomen is het
verschil tussen de technologie van de blockchain op zich te gaan verbeteren en de technologie van de
blockchain fundamenteel te veranderen.
De niet-technische beperkingen zijn voornamelijk de sociale, economische, legale en psychologische
aspecten die komen kijken bij het toepassen van een nieuwe technologie. Deze aspecten vergen vaak
enige tijd om tot zijn recht te komen. Denk maar aan het internet en haar e-commerce. Vooraleer daar
grondig uitgewerkte wettelijke initiatieven zijn gekomen was er eerst het algemeen
aanvaardingsproces van de gebruikers van het internet. Bij het gebruik van een nieuwe technologie
komt dus vaak meer kijken dan initieel verwacht. Doch wil ik hier niet gaan pretenderen dat de
blockchain een even grote revolutie teweeg zal brengen als bij de komst van het internet… Maar eens
het zover is dan is het verhaal van de blockchain nog lang niet voorbij en zullen er noodgedwongen
wettelijke initiatieven moeten getroffen worden om op zijn minst even sterke wettelijke waarborgen
te bieden als in de realiteit reeds het geval is. Als dit niet lukt dan bestaat in mijn ogen de kans dat
deze nieuwe technologie een stille dood zal sterven en haar potentieel om het leven van de mens te
verbeteren zal verliezen.
109
76
2.28 De noodzaak van vier types blockchain
2.28.1 De conflicterende doelen van de blockchain
1) Transparantie vs. privacy
2) Veiligheid vs. snelheid110
2.28.1.1 Transparantie vs. Privacy
Deze openheid en transparantie staat natuurlijk haaks op het concept privacy. Het conflict uit hem in
de wil om de details van gebruikers en transactiedata geheim te houden voor het publiek maar
eveneens de wil om het systeem open en transparant te houden voor het verifiëren van
eigenaarschap111.
2.28.1.2 Veiligheid vs. Snelheid
Deze 2 conflicten komen voort uit 2 fundamentele operatieve functies van de blockchain zijnde
enerzijds het lezen van transactiedata en anderzijds het schrijven van transactiedata. Het conflict
110
111
77
transparantie vs. privacy kan worden gelinkt aan de leesfunctie van de blockchain en het conflict
veiligheid vs. snelheid kan worden gelinkt aan de schrijffunctie van de blockchain.
Onderstaande tabel (tabel 23-1) geeft de 2 grote technische limitaties weer die volgen uit deze 2
conflicten en de fundamentele functionaliteit waaraan het gelinkt wordt112.
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 215.
2.28.2 Het oplossen van de conflicten
2.28.2.1 Kiezen tussen transparantie vs. privacy
1) Publieke blockchains (public)
2) Private blockchains (private)
Publieke blockchains (public blockchains)
112
113
78
Private blockchains (private blockchains)
2.28.2.2 Kiezen tussen veiligheid vs. snelheid
1) Blockchains zonder toestemming (permissionless)
2) Blockchains met toestemming (permissioned)
Blockchains zonder toestemming (permissionless blockchains)
Blockchains met toestemming (permissioned blockchains)
79
Bron: DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress,
2017, 216.
2.28.3 Wat zijn de expliciete gevolgen bij het invoeren van restricties op het niveau van de lees- en
schrijffunctie in de blockchain ?
1) De peer-to-peer architectuur
2) De gedistribueerde natuur
3) Het doel
De peer-to-peer architectuur
80
De gedistribueerde natuur
Het doel
De vraag is nu of we na deze constatatie nog steeds over hetzelfde doel kunnen spreken? Eigenlijk
wel… Maar het doel van de blockchain, zijnde het verkrijgen en beheren van integriteit in een zuiver
gedistribueerd peer-to-peer systeem, kan nu ietwat zachter en getemperd geformuleerd worden. Het
doel kan nu als volgt luiden: “het verkrijgen en beheren van integriteit in gedistribueerde systemen in
het algemeen”.
81
2.29 De blockchain en haar mogelijke toepassingen in het echte leven
2.29.1 Algemene toepassingspatronen
Met de vooropgestelde gedachte, kunnen we volgende toepassingsgevallen onderscheiden:
2.29.1.1 Bewijs van bestaan
2.29.1.2 Bewijs van niet-bestaande
2.29.1.3 Bewijs van tijd
2.29.1.4 Bewijs van volgorde
82
2.29.1.5 Bewijs van identiteit
2.29.1.6 Bewijs van auteurschap
2.29.1.7 Eigendomsbewijs
114
Zie P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 167-172.
83
2.29.2 Specifieke toepassingen
115
Zie voor een aantal mogelijke toepassingen: J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het
einde van de vertrouwde tussenpersoon?, Brussel, Els Belgium, 2019, 85-107.
84
Deel 2: Smart contracts
1. Inleiding
2. Orakels
116
S.C.W. GROUP, Smart contracts as a specific application of blockchain technology, https://axveco.com/wpcontent/uploads/2017/12/Smart-Contracts-ENG-report.pdf (consultatie 4 april 2019); J. NAVES, "Smart
contracts: Voer voor juristen?", Onderneming en Financiering 2018, afl. 4, (57) 61; Zie ook C. CLACK, V. A. BAKSHI
en L. BRAINE, "Smart Contract Templates: foundations, design landscape and research directions" 2016,
https://www.semanticscholar.org/paper/Smart-Contract-Templates%3A-foundations%2C-design-and-ClackBakshi/0c3166e6773fb8a894670bf4d6da9bd512170e63, 2; Zie ook N. VANDEZANDE, When an Original Is Not
Original, Antwerpen, Intersentia, 2019, 134-135, nrs. 265-267.
117
N. GLOUDEMANS-VOOGD, "Smart Contracts worden volwassen", Advocatenblad, December-Januari 2017, 5253.
118
J.B. SCHMAAL en E.M. VAN GENUCHTEN, "Smart contracts en de Haviltex-norm", Tijdschrift voor Internetrecht
2017, afl. 1, (12) 16, vn. 33.
119
T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (I)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7199, (494) 494; E. TJONG TJIN TAI, "Smart
contracts en het recht", Nederlands Juristenblad 2017, afl. 3, 176-183; J. GOOSSENS en K. VERLYPE, Blockchain
en smart contracts : Het einde van de vertrouwde tussenpersoon?, Brussel, Els Belgium, 2019, 29-30; R.M. PARIZI,
AMRITRAJ en A. DEHGHANTANHA, Smart Contract Programming Languages on Blockchains: An Empirical
Evaluation of Usability and Security, Cham, Springer International Publishing, 2018, 76; contra S. GEIREGAT,
"Cryptocurrencies are (smart) contracts", Computer Law & Security Review 2018, afl. 5, 1148, punt 3.1. waar de
auteur de stelling verdedigt dat een smart contract geen juridische overeenkomst op zichzelf is maar slechts een
technologie die als hulpmiddel fungeert bij de uitvoering van o.a. juridisch bindende overeenkomsten.
85
120
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 39; J. NAVES, "Smart contracts: Voer voor juristen?", Onderneming en Financiering
2018, afl. 4, (57) 57-67.
121
C. VAN SCHOUBROECK, I. SAMOY, J. AMANKWAH, K. RONSIJN, N. STROOBANTS en E. VERJANS, Themis 106 Aansprakelijkheids- en verzekeringsrecht, Brugge, die Keure / la Charte, 2018, 77-78, nrs. 1 en 2.
122
C. VAN SCHOUBROECK et al., Themis 106 - Aansprakelijkheids- en verzekeringsrecht, Brugge, die Keure / la
Charte, 2018, 77-78, nr. 1, 1e en 3e al.
123
Zie C. VAN SCHOUBROECK et al., Themis 106 - Aansprakelijkheids- en verzekeringsrecht, Brugge, die Keure /
la Charte, 2018, 77-106.
86
3. Ricardiaans contract of smart legal contract
Wanneer er gesproken wordt over smart contract code bedoelt men hiermee de klassiek geschreven
code die tot uiting komt in een welbepaalde programmeertaal die enkel te begrijpen is door een
kenner van de programmeertaal. Voor het schrijven van smart contract code bestaan er diverse
programmeertalen die hier buiten beschouwing worden gelaten125.
Wanneer men daarentegen over een smart legal contract spreekt dan bedoelt men hiermee ‘een
Ricardiaans contract’. Een Ricardiaans contract is op zich ook een smart contract maar verschilt van
smart contract code doordat men de computertaal met menselijke taal gaat combineren in de
geprogrammeerde code. Meestal zal men de inhoud van een traditioneel juridische overeenkomst
gaan koppelen aan computercode. Net omdat er ook menselijke taal mee gemoeid is, zorgt dit er voor
dat contractspartijen een transparanter zicht krijgen op de inhoud van het geconstrueerde smart
contract en de uitvoering ervan. Men probeert hiermee een onzekerheid weg te cijferen bij
contractspartijen die geen programmeertaal kennen. Zo hebben dergelijke partijen een beter gevoel
over de impact en de gevolgen van de aangegane verbintenissen die vervat liggen in de
geprogrammeerde code126. (Zie ter illustratie onderstaande afbeelding op volgende pagina)
124
A. DE BACKER en V. DE BOE, "Smart contracts in de financiële sector: grote verwachtingen en regulatoire
uitdagingen", Computerr. 2017, afl. 6, (355) 355, 2e al; C. CLACK et al., "Smart Contract Templates: foundations,
design landscape and research directions" 2016, https://www.semanticscholar.org/paper/Smart-ContractTemplates%3A-foundations%2C-design-and-Clack-Bakshi/0c3166e6773fb8a894670bf4d6da9bd512170e63, 2.
125
Zie bv. G. GOVERNATORI, F. IDELBERGER, Z. MILOSEVIC, R. RIVERET, G. SARTOR en X. XU, "On legal contracts,
imperative and declarative smart contracts, and blockchain systems", Artificial Intelligence and Law 2018, afl. 4,
377-409.
126
Vgl. J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 46-48.
87
Bron: GOOSSENS, J. en VERLYPE, K., Blockchain en smart contracts : Het einde van de vertrouwde
tussenpersoon?, Brussel, Els Belgium, 2019, 47.
4. Voorbeelden uit de praktijk
127
A. G. SIMPSON, Toyota, MIT Lab Eye Using Blockchain in Insurance Rating of Driverless and Shared Vehicles,
https://www.insurancejournal.com/news/national/2017/05/23/451913.htm (consultatie 4 april 2019).
88
128
C.H. TRUDELL, Yuki, Toyota $1B Research Labs Near Stanford, MIT to Develop Autonomous Vehicles,
https://www.insurancejournal.com/news/national/2015/11/06/387751.htm (consultatie 6 mei 2019).
129
Zie ook: Bijlage I, antwoord op vraag 8.
130
AXA, https://fizzy.axa/en-gb/ (consultatie 6 mei 2019).
131
C. FIRTH, AXA launches new blockchain based insurance product for airline passengers,
https://www.financemagnates.com/fintech/news/axa-launches-new-blockchain-based-insurance-productairline-passengers/
(consultatie
25
april
2019);
ETHERSCAN,
https://etherscan.io/address/0xe083515d1541f2a9fd0ca03f189f5d321c73b872 (consultatie 6 mei 2019).
132
Zie voor een gedetailleerde uitleg over de werking van het AXA Fizzy reisverzekeringscontract: A. CLEMENT,
fizzy.axa Smart contract explained, https://medium.com/@humanGamepad/fizzy-axa-smart-contract-explaind740df52894fd (consultatie 6 mei 2019).
133
P. KELAHAN, Parametric Insurance - The Least Known Best Response to Unfortunate Happenings,
https://dailyfintech.com/2019/03/21/parametric-insurance-the-least-known-best-response-to-unfortunatehappenings/ (consultatie 6 mei 2019).
134
Zie ook artikel 1 van de algemene voorwaarden van het AXA Fizzy contract: AXA, CONDITIONS GENERALES DU
CONTRAT FIZZY VALANT NOTICE D’INFORMATION, https://fizzy.axa/en-gb/static/media/conditionsgenerales.38af84e2.pdf (consultatie 6 mei 2019); Vgl. J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts
: Het einde van de vertrouwde tussenpersoon?, Brussel, Els Belgium, 2019, 32-37.
135
Vgl. G. GOVERNATORI et al., "On legal contracts, imperative and declarative smart contracts, and blockchain
systems", Artificial Intelligence and Law 2018, afl. 4, 386, 7e al.
89
Een tweede voorbeeld uit de praktijk betreft het Duitse InsurTech-bedrijf Etherisc136. Etherisc is bezig
met de ontwikkeling van een gewasverzekering die automatisch uitbetaalt bij droogte of overstroming.
Dit zou een stap voorwaarts kunnen betekenen in het kader van de idee van de micro-verzekeringen137
die enerzijds probeert om verzekeraars winstgevend in de markt te zetten in ontwikkelingslanden en
anderzijds de armere bevolking een mogelijkheid biedt om zich te verzekeren tegen dergelijke
risico’s138.
Minder positieve verhalen uit de praktijk zijn er ook. Een smart contract kan nl. ook bugs
(programmeerfouten) bevatten. Er zijn reeds 2 gekende gevallen waarbij zo een bug zich voordeed. In
2016 was er een bug bij een smart contract op het smart contract-platform genaamd ‘DAO’
(Decentralized Autonomous Organisation) die op Ethereum werd gepubliceerd139 en in 2017 was er
een gelijkaardig geval met de Parity Bug140.
136
ETHERISC, https://etherisc.com/ (consultatie 6 mei 2019).
Zie K. BERNAUW, S. ROUX en D. MILLARD, Dossier 2018: Micro-verzekering: naar een inclusieve
verzekeringsmarkt?, Mechelen, Wolters Kluwer, 2019, 1-83.
138
R. PEVERELLI, Marketing Science: Blockchain in verzekeringen https://www.ey-vodw.com/blog/marketingscience-blockchain-in-verzekeringen (consultatie 6 mei 2019).
139
T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (II)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7200, (525) 526-528; E. TJONG TJIN TAI,
"Juridische aspecten van blockchain en smart contracts", TPR 2017, afl. 2/3, (563) 583-585, nr. 30; J. NAVES,
"Smart contracts: Voer voor juristen?", Onderneming en Financiering 2018, afl. 4, (57) 60-61.
140
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 41; M. SUICHE, The $280M Ethereum’s Parity bug. A critical security vulnerability in
Parity multi-sig wallet got triggered on 6th November — paralyzing wallets created after the 20th July.,
https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513 (consultatie 17 april 2019).
137
90
Deel 3: De verzekeringssector
1. De relevantie van blockchain en smart contracts in de verzekeringssector
Bovendien zijn er verschillende actieve verenigingen die zich momenteel intellectueel buigen over
blockchaintechnologie waarvan B3i (The Blockchain Insurance Industry Initiative144) voor de
verzekeringssector een belangrijke is met grote namen zoals AXA, Allianz, Aegon, Ageas, etc145.
Ook bij juristen leeft het thema van blockchain en smart contracts en wordt het belang ervan in
verschillende domeinen van het recht gewikt en gewogen146.
141
PWC, InsurTech, https://www.pwc.nl/nl/marktsectoren/verzekeraars/insurtech.html (consultatie 13 april
2019); P. CLAERHOUT, Insurtech is the next big thing: technologische innovatie breekt door in de
verzekeringssector,
https://trends.knack.be/economie/bedrijven/insurtech-is-the-next-big-thingtechnologische-innovatie-breekt-door-in-de-verzekeringssector/article-normal-914545.html (consultatie 13
april 2019); J. S. HARRINGTON, The Present Use and Promise of Blockchain in Insurance,
https://www.insurancejournal.com/news/national/2017/05/16/451177.htm (consultatie 6 mei 2019).
142
E. TJONG TJIN TAI, "Juridische aspecten van blockchain en smart contracts", TPR 2017, afl. 2/3, (563) 583, nr.
28.
143
J. VANDERDONCKT, A. VAN MELKEBEKE en G.p. VAN DAELE, How fit is the Belgian insurance industry with
Blockchain technology?, onuitg. Faculteit Economie & Bedrijfskunde Universiteit Gent, 2018,
http://lib.ugent.be/catalog/rug01:002509028, 90 p.
144
H.
L.S.,
Blockchain
Insurance
Industry
Initiative
B3i
Grows
to
15
Members,
https://www.insurancejournal.com/news/international/2017/02/06/440629.htm (consultatie 6 mei 2019).
145
B3I, The Blockchain Insurance Industry Initiative, https://b3i.tech/home.html (consultatie 6 mei 2019).
146
Zie K.J. BAKKER en N. KREILEMAN, "Verslag WONO-symposium 25 januari 2019", Maandblad voor
Ondernemingsrecht 2019, afl. 3-4; A. BERLEE, "Pandakteregistratie van Belastingdienst naar blockchain: een
verkenning", Maandblad voor Vermogensrecht 2018, afl. 3; P. DAMBLY, "L'impact des insurtechs en 2025 sur
l'intermédiation en assurance", T.Verz. 2017, afl. 4, (483); A. DE BACKER en V. DE BOE, "Smart contracts in de
financiële sector: grote verwachtingen en regulatoire uitdagingen", Computerr. 2017, afl. 6, (355); T. DE GRAAF,
"De kwalificatie van bitcoins", Nederlands Juristenblad 2019, afl. 1, (2); T.J. DE GRAAF, "Van oud naar nieuw: van
internet naar smart contracts en van mensen naar code (I)", Weekblad voor Privaatrecht, Notariaat en Registratie
2018, afl. 7199, (494); T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen
91
Tot slot vinden er ook talrijke conferenties voor verzekeringsondernemingen plaats waarbij blockchain
(en InsurTech in het algemeen) vaak de primaire onderwerpen vormen147.
naar code (II)", Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7200, (525); M. FENWICK, M.
CORRALES en H. HAAPIO, Legal Tech, Smart Contracts and Blockchain, Singapore, Springer, 2019; D. DE JONGHE
en V.I. LAAN, "Blockchain in de realiteit", Computerr. 2017, afl. 6, (347); S. GEIREGAT, "Cryptocurrencies are
(smart) contracts", Computer Law & Security Review 2018, afl. 5; S. GEIREGAT, "Eigendom op bitcoins",
Rechtskundig Weekblad (RW) 2017, afl. 27; M. GIANCASPRO, "Is a ‘smart contract’ really a smart idea? Insights
from a legal perspective", Computer Law & Security Review 2017, afl. 6; N. GLOUDEMANS-VOOGD, "Smart
Contracts worden volwassen", Advocatenblad, December-Januari 2017, 52-53; G. GOVERNATORI et al., "On legal
contracts, imperative and declarative smart contracts, and blockchain systems", Artificial Intelligence and Law
2018, afl. 4; M.-C. JANSSENS en J. VANHERPE, Blockchain and copyright - Beyond the buzzword?, 2018; A.
JANSSEN en M. DUROVIC, "The Formation of Blockchain-based Smart Contracts in the Light of Contract Law",
European Review of Private Law 2018, (753) 753-771; G. GÜRKAYNAK, İ. YıLMAZ, B. YEŞILALTAY en B. BENGI,
"Intellectual property law and practice in the blockchain realm", Computer Law & Security Review 2018, afl. 4;
M. KAULARTZ en J. HECKMANN, Smart Contracts – Anwendungen der Blockchain-Technologie, 2016; H. KOSTER,
"Blockchain, crypto finance en robotisering in het ondernemingsrecht", Ondernemingsrecht 2018, afl. 3, (151);
V.I.R. LAAN, A., "Privacy-issues bij blockchain: hoe voorkom of minimaliseer je die?", Computerr. 2017, afl. 6,
(364); ISDA en LINKLATERS, Whitepaper Smart Contracts and Distributed Ledger - A Legal Perspective,
https://www.isda.org/2017/08/03/smart-contracts-and-distributed-ledger-a-legal-perspective/ (consultatie 16
april 2019); C. MILLARD, "Blockchain and law: Incompatible codes?", Computer Law & Security Review 2018, afl.
4; S.S. MURPHY, Ronald David; Percival, Robert L., Can Smart Contracts be legally binding contracts?,
https://www.nortonrosefulbright.com/en-ca/knowledge/publications/a90a5588/can-smart-contracts-belegally-binding-contracts (consultatie 9 april 2019); J. NAVES, "Smart contracts: Voer voor juristen?",
Onderneming en Financiering 2018, afl. 4, (57); R. O' SHIELDS, "Smart Contracts: Legal Agreements for the
Blockchain", Banking Insitute Journal 2017, afl. 1, (177); D. PHILIPPE, "Blockchain and smart contract: lex
cryptographia?", DAOR 2018, afl. 4; Y.J. POULLET, H., "Blockchain : une révolution pour le droit ?", Journal des
Tribunaux 2018, (801); H. SCHURINGA, "Enkele civielrechtelijke aspecten van blockchain", Computerr. 2017, afl.
6, (372); J. SIMAL, Blockchain en privacy: een onderzoek naar de verzoenbaarheid van blockchaintechnologie met
de GDPR, onuitg. Masterscriptie Faculteit Rechtsgeleerdheid KU Leuven, 2018; J.K. STAM, "Smart contracts?",
Contracteren 2018; E. TJONG TJIN TAI, "Smart contracts en het recht", Nederlands Juristenblad 2017, afl. 3; E.
TJONG TJIN TAI, "Juridische aspecten van blockchain en smart contracts", TPR 2017, afl. 2/3, (563); M. TRUYENS,
"Smart contracts: moeten juristen programmeurs worden?", Juristenkrant, 23 november 2016, 12-13; E.L.
VALGAEREN, J.J., "Inleiding: Blockchain ontketend", Computerr. 2017, afl. 6, (343); M. VAN DE LOVERBOSCH,
"Crypto-effecten: tussen droom en daad", TRV 2018, afl. 3, (193); M. VAN DER LINDEN, "Het recht geketend:
Smart contracts: dé oplossing voor gezeur, gedoe en onzekerheid?", Tijdschrift voor Internetrecht 2018, afl. 2,
(59); S. VAN HEUKELOM, "Responsieve rechtsstaat en digitale overheid: blockchain en smart contracts",
Nederlands Tijdschrift voor Bestuursrecht 2018, afl. 5, (217); J.G.L. VAN DER WEES, "Juridische verkenning naar
smart contracts", Computerr. 2018, afl. 1; S. VAN HEUKELOM, J. NAVES en M. VAN GRAAFLAND, Whitepaper
Juridische
aspecten
van
blockchain,
https://www.platformoutsourcing.nl/f/files/download/overig/whitepaper_blockchain.pdf (consultatie 5 april
2019); C.-A. VAN OLDENEEL (ED.), DOSSIER 2017 Data protection: De impact van de GDPR in de verzekering,
Mechelen, Wolters Kluwer, 2017, 45, 1e al., laatste zin; B. VERHEYE, "Blockchaintechnologie en het notariaat bij
vastgoedtransacties: Damocles' zwaard of opportuniteit?", Tijdschrift voor Notarissen (T. Not.) 2018, afl. 3; B.
VERHEYE, K. VERSLYPE en P. DANNEELS, "Blockchain en smart contracts. Impact op de notaris als vertrouwde
tussenpersoon?" 2018; B. VUYLSTEKE, "Blockchain - Wat is het? Wat kan het betekenen voor het notariaat?",
Tijdschrift voor Notarissen (T. Not.) 2018, afl. 3; K. WERBACH, "Trust, But Verify: Why The Blockchain Needs The
Law", Berkeley Technology Law Journal 2017, afl. 489, (489); A.D.F. WRIGHT, Primavera, "Decentralized
Blockchain Technology and the Rise of Lex Cryptographia", SSRN 2015, (1).
147
Bv.
W.K.
BELGIË,
Belgian
Insurance
Conference,
https://belgian-insuranceconference.wolterskluwer.be/nl/programma/ (consultatie 5 april 2019); B3I, B3i Community Conference –
Amsterdam
2018,
https://conference.b3i.tech/portfolio_page/november-2018conference/https://conference.b3i.tech/portfolio_page/november-2018-conference/ (consultatie 6 mei 2019);
SWISSRE, Airmic 2019 - 03 - 05 June 2019 CET, https://corporatesolutions.swissre.com/insights/events/airmic2019.html?tab=section-international (consultatie 10 mei 2019); GENOOTSCHAP, Masterclass The actuarial use
92
2. Het Belgisch verzekeringscontractenrecht
2.1. Algemeen
Art. 54, eerste lid W. Verz. bepaalt dat de bepalingen van Deel 4 W. Verz. van toepassing zijn op alle
(land)verzekeringsovereenkomsten die onderworpen zijn aan het Belgische recht in zoverre er niet van
wordt afgeweken door bijzondere wetten.
Art. 225, tweede lid W. Verz. bepaalt dan weer het toepassingsgebied van Deel 5 W. Verz. op negatieve
wijze nl. alle verzekeringsovereenkomsten die niet reeds gevat worden door het toepassingsgebied
van Deel 4 W. Verz. Het betreft hier een restcategorie.
Uiteraard zijn er daarnaast ook verzekeringsovereenkomsten die beheerst worden door bijzondere
reglementering. Denk bijvoorbeeld aan de motorrijtuigenverzekering152 (ook beter gekend als de
WAM-verzekering). Doch worden ook die bijzondere verzekeringsovereenkomsten beheerst door deel
4 van W. Verz. voor die aspecten die niet geregeld worden in de voornoemde bijzondere wetgeving153.
of Blockchain
https://www.ag-ai.nl/community_events.php?action=view&Event_Id=9223 (consultatie 13
mei 2019).
148
Wet van 4 april 2014 betreffende de verzekeringen, B.S. 30 april 2014.
149
Wet van 25 juni 1992 betreffende de Landverzekeringsovereenkomst, B.S. 20 augustus 1992.
150
Wet van 11 juni 1874 betreffende Verzekeringen, B.S. 14 juni 1874.
151
K. BERNAUW, "Wijzigingen in de verzekeringswetgeving: wet 4 april 2014 en andere nieuwigheden",
Rechtskroniek voor de vrede- en politierechters 2015 2015, (113-136).
152
Wet van 21 november 1989 betreffende de verplichte aansprakelijkheidsverzekering inzake motorrijtuigen,
B.S. 8 december 1989.
153
B. WEYTS en T. VANSWEEVELT, Handboek Verzekeringsrecht, Antwerpen, Intersentia, 2016, 3-26.
93
2.2. Verzekeringsovereenkomsten op afstand gesloten
2.2.1. Marktpraktijken en consumentenbescherming (Boek VI WER & de Wet Verzekeringen) –
Verzekeringsovereenkomsten op afstand gesloten met consumenten
In art. I.8, 16° WER wordt onder ‘techniek voor communicatie op afstand’ dan weer het volgende
begrepen: “ieder middel dat, zonder gelijktijdige fysieke aanwezigheid van onderneming en
consument, kan worden gebruikt voor de sluiting van de overeenkomst tussen deze partijen”.
Wanneer ik deze 2 definities155 aandachtig lees dan kom ik tot de vaststelling dat een smart
verzekeringscontract via blockchaintechnologie onder het materieel toepassingsgebied van een
overeenkomst op afstand valt. De technieken voor communicatie op afstand zijn m.i. de blockchain en
het internet. Dit heeft tot gevolg dat volgens het Belgische verzekeringsrecht het regime van
overeenkomsten op afstand zoals bepaald in art. 57, §5 W. Verz. voor smart verzekeringscontracten
gesloten met een consument moet worden gevolgd156.
Een consument in de zin van art. I.1., °2 WER is: “iedere natuurlijke persoon die handelt voor doeleinden
die buiten zijn handels-, bedrijfs-, ambachts- of beroepsactiviteit vallen”.
Dit veronderstelt dus dat men weet met welke partij met aan het contracteren is om te weten welke
regels er moeten gevolgd worden. De problematiek m.b.t. identificatie van een partij in een blockchain
en smart contracts behandel ik onder een aparte titel (Infra, nrs. 163-165).
154
Wetboek ingevoerd bij Wet tot invoering van het Wetboek van economisch recht, B.S. 28 februari 2013.
Art. I.8, 15° WER juncto art. I.8, 16° WER
156
M. FONTAINE, Verzekeringsrecht, Brussel, Larcier, 2017, 200, nr. 203; P. COLLE, De nieuwe wet van 4 april
2014 betreffende de verzekeringen : algemene beginselen van het Belgische verzekeringsrecht, Antwerpen,
Intersentia, 2015, 44-45, nr. 43.
155
94
Art. I.8.,°18 definieert een ‘financiële dienst’ als volgt: “iedere dienst van bancaire aard of op het gebied
van kredietverstrekking, verzekering, individuele pensioenen, beleggingen en betalingen;”
Deze beschermingsregeling voor consumenten157 volgens het huidige recht ook van toepassing zijn
wanneer verzekeraars consumenten de mogelijkheid aanbieden een smart verzekeringscontract te
sluiten via een blockchain. Deze beschermingsregeling in boek VI WER moet nochtans gezien worden
als een lex generalis inzake consumentenbescherming t.o.v. de lex specialis welke voorrang geniet,
zijnde de W. Verz. van 4 april 2014, de Controlewet- en reglementering158.
Volgens art. 57,§5, derde lid, eerste streepje W. Verz. gaat deze termijn in vanaf de dag van het sluiten
van de overeenkomst. Dit is dus vanaf het moment van de ontvangst van de aanvaarding door de
verzekeringsnemer
(art.
57,
§5,
eerste
lid,
laatste
zin
W.
Verz.).
Voor
levensverzekeringsovereenkomsten is er opnieuw een uitzondering voorzien en gaat de termijn van
30 dagen pas in op het moment dat de verzekeraar aan de verzekeringnemer heeft meegedeeld dat
de levensverzekeringsovereenkomst is gesloten. Art. 57, §5, derde lid, tweede streepje W. Verz. vangt
dan weer
de
situaties op waar de verzekeraar nog niet voldaan heeft aan zijn
informatieverplichtingen159. Het startpunt zoals bepaald in het eerste streepje zal overruled worden
door het aanvangspunt zoals bepaald in het tweede streepje wanneer de termijn in het eerste streepje
al zou verstreken zijn en de verzekeringnemer de contractsvoorwaarden en alle bijkomende informatie
nog niet heeft ontvangen. In dit laatste geval zal de termijn pas ingaan op de dag dat de
verzekeringnemer die informatie heeft ontvangen.
157
Zie L. SCHUERMANS en C. VAN SCHOUBROECK, Grondslagen van het Belgische verzekeringsrecht, 3e editie,
Antwerpen, Intersentia, 2015, 215-233.
158
L. SCHUERMANS en C. VAN SCHOUBROECK, Grondslagen van het Belgische verzekeringsrecht, 3e editie,
Antwerpen, Intersentia, 2015, 215-217, nr. 311.
159
Zie L. SCHUERMANS en C. VAN SCHOUBROECK, Grondslagen van het Belgische verzekeringsrecht, 3e editie,
Antwerpen, Intersentia, 2015, 218-222, nrs. 314-317.
95
3.2. Recht van de elektronische economie (Boek XII WER)
Het sluiten van een verzekeringsovereenkomst via elektronische weg is op het gebied van de
totstandkomingsvoorwaarden niet echt verschillend van de gebruikelijke schriftelijke polis163.
4. Gedaan met in concreto beoordelingen met smart (verzekerings)contracten? Een ode
aan het rechtszekerheidsbeginsel
160
G. GOVERNATORI et al., "On legal contracts, imperative and declarative smart contracts, and blockchain
systems", Artificial Intelligence and Law 2018, afl. 4, 384.
161
Bv. Richtl. nr. 2000/31/EG van het Europees Parlement en de Raad van 8 juni 2000 betreffende bepaalde
juridische aspecten van de diensten van de informatiemaatschappij, met name de elektronische handel, in de
interne markt („richtlijn inzake elektronische handel”), Pb. L. 17 juli 2000, afl. 178, 16.
162
Zie art. XII.1. WER
163
M. FONTAINE, Verzekeringsrecht, Brussel, Larcier, 2017, 201-202, nr. 207.
96
164
P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 24, nr. 20.
165
Zie ter illustratie: Art. 64, §1, derde lid W. Verz. waar de toepassing van artikel 1328 BW (Afdeling I, Schriftelijk
Bewijs) (cf. vaste datum) uitdrukkelijk wordt uitgesloten bij verzekeringsovereenkomsten.
166
M.E. STORME, "Rechtszekerheid en vertrouwensbeginsel in het Belgisch verbintenissenrecht", TPR 1997,
(1861) 1861-1935.
167
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 40-43; E. TJONG TJIN TAI, "Juridische aspecten van blockchain en smart contracts",
TPR 2017, afl. 2/3, (563) 582., nr. 29.
168
Europees Verdrag tot bescherming van de rechten van de mens en de fundamentele vrijheden, 4 november
1950, Rome, B.S. 19 augustus 1955.
169
Zie A. VAN OEVELEN, S. RUTTEN en J. ROZIE, Recht op toegang tot de rechter, Antwerpen, Intersentia, 2016,
172 p.
170
Vgl. T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (II)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7200, (525) 525 waar de auteur een shift van
vertrouwen benadrukt nl. één van vertrouwen in personen naar een vertrouwen in code.
171
D. PHILIPPE, "Blockchain and smart contract: lex cryptographia?", DAOR 2018, afl. 4, 6-17.
97
172
Zie ook B.M.A. VAN ECK, "noot onder ABRvS 17 mei 2017", Computerr. 2017/256, afl. 6, 395-397.
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 27, nr. 1.
174
K. TERMOTE, Terwijl de verzekeringsjurist kreunt, in B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014,
Antwerpen, Intersentia, 2015, 175-176., nr. 20 juncto nr.22, eerste zin.
175
Vgl. P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 21-23, nr. 17.
173
98
176
M. DE GRAEVE en M. GYSELAERS, Praktisch verzekeringsrecht, Berchem, De Boeck, 2011, 38.
Vgl. E. TJONG TJIN TAI, "Juridische aspecten van blockchain en smart contracts", TPR 2017, afl. 2/3, (563) 586,
nr. 33 waar de auteur verwijst naar eerdere succesverhalen van samenwerking met de overheid en dit ook
mogelijk acht bij decentrale systemen; Vgl. J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde
van de vertrouwde tussenpersoon?, Brussel, Els Belgium, 2019, 24, waar de auteur wijst op "een nood aan
doordachte wetgeving die toekomstbestendig is in een domein waar de snelheid van technologische evoluties
enkel zal toenemen".
178
T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (I)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7199, (494) 494, puntje 2, 3e al., laatste zin; ZieV.
MAK, "Op weg naar een Europese ‘Digital Single Market’ Twee nieuwe richtlijnvoorstellen voor het Europees
contractenrecht", Nederlands Juristenblad 2016, afl. 8, (518) 518-524; Zie ook FODECONOMIE, Raadpleging
Digital
Single
Market
Strategy,
https://economie.fgov.be/nl/themas/online/digitale-agenda-vooreuropa/raadpleging-digital-single (consultatie 13 mei 2019).
179
Zie toelichting bij art. 3, Voorstel (Comm.) van 9 december 2015 voor een richtlijn van het Europees Parlement
en de Raad betreffende bepaalde aspecten van overeenkomsten voor de levering van digitale inhoud ,
COM(2015) 634 final, 13.
177
99
5. Blockchain als vervanger van bewijs via geschrift? (art. 64 W. Verz.)
Indien evenwel een begin van bewijs door geschrift wordt geleverd, is het bewijs door getuigen of
vermoedens toegelaten […]”
Zowel verzekeraar als verzekeringnemer zijn dus genoodzaakt om een geschrift op te maken waaruit
de verzekeringsovereenkomst blijkt180. De vereiste van een geschrift is er natuurlijk enkel voor het
bewijs van de verzekeringsovereenkomst en niet voor het ontstaan van de verzekeringsovereenkomst
gezien een verzekeringscontract nog steeds een consensueel contract is181.
1° de datum waarop de verzekeringsovereenkomst is gesloten en de datum waarop de verzekering
begint te lopen;
2° de duur van de overeenkomst;
3° de identiteit van de verzekeringnemer en, in voorkomend geval, de identiteit van de verzekerde en
van de begunstigde;
4° de naam en het adres van de verzekeraar of van de medeverzekeraars;
5° in voorkomend geval, de naam en het adres van de verzekeringstussenpersoon;
6° de gedekte risico's;
180
P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 47, nr. 44.
181
P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 33, nr. 26.
100
7° het bedrag van de premie of de wijze waarop de premie kan worden bepaald.”
Al deze gegevens kunnen wel verwerkt zitten in data op een blockchain en in een smart contracts maar
als dit enkel via programmeertaal/codetaal tot uiting komt dan zal dit een effectief tot uiting moeten
komen in deze bepaling
182
Verord. (EU) Nr. 910/2014 van het Europees Parlement en de Raad van 23 juli 2014 betreffende elektronische
identificatie en vertrouwensdiensten voor elektronische transacties in de interne markt en tot intrekking van
Richtlijn 1999/93/EG, Pb.L. 28 augustus 2014, 73-114. (hierna: eIDAS)
183
N. VANDEZANDE, When an Original Is Not Original, Antwerpen, Intersentia, 2019, 134-135, nr. 268.
184
Wet tot uitvoering en aanvulling van de verordening (EU) nr. 910/2014 van het Europees Parlement en de
Raad van 23 juli 2014 betreffende de elektronische identificatie en vertrouwensdiensten voor elektronische
transacties in de interne markt en tot intrekking van Richtlijn 1999/93/EG, houdende invoeging van titel 2 in boek
XII “Recht van de elektronische economie” van het Wetboek van economisch recht, en houdende invoeging van
de definities eigen aan titel 2 van boek XII en van de rechtshandhavingsbepalingen eigen aan titel 2 van boek XII,
in de boeken I, XV en XVII van het Wetboek van economisch recht, B.S. 21 juli 2016.
101
Art. I.18, °5 WER definieert een ‘afnemer van de dienst’ dan weer als volgt: “[…] iedere natuurlijke of
rechtspersoon die, al dan niet voor beroepsdoeleinden, gebruikmaakt van een dienst van de
informatiemaatschappij, in het bijzonder om informatie te verkrijgen of toegankelijk te maken; […]”
Als je deze 2 definities samenlegt met art. XII.1.,§2, eerste lid WER kom je tot de vaststelling dat de
regeling van Boek XII WER zowel op consumenten als op professionelen (niet-consumenten) van
toepassing is. Het personeel toepassingsgebied omhelst zowel de privé persoon als de professioneel
(zowel de relatie B2C als B2B)185.
§ 2. Voor de toepassing van § 1, moet in overweging worden genomen dat :
- [aan de vereiste van een geschrift is voldaan door een geheel van alfabetische tekens of van enige
andere verstaanbare tekens aangebracht op een drager die de mogelijkheid biedt toegang ertoe te
hebben gedurende een periode die is afgestemd op het doel waarvoor de informatie kan dienen en
waarbij de integriteit ervan wordt beschermd, welke ook de drager en de transmissiemogelijkheden
zijn;]
- aan de uitdrukkelijke of stilzwijgende vereiste van een handtekening is voldaan wanneer deze laatste
beantwoordt aan de voorwaarden van [ofwel artikel 3.10. van verordening 910/2014],ofwel van artikel
3.12. van verordening 910/2014];
- aan de vereiste van een geschreven vermelding van degene die zich verbindt, kan worden voldaan
door om het even welk procédé dat waarborgt dat de vermelding effectief uitgaat van deze laatste.”
Art. XII.15, §1 WER spreekt over de ‘functionele kwaliteiten’ van elke wettelijke of reglementaire
vormvereiste waaraan moet voldaan zijn voor de totstandkoming van een elektronisch contract. In art.
185
Vgl. T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (I)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7199, (494) 495, puntje 2, voorlaatste zin.
102
II.15, §2 wordt deze functionele kwaliteitsvereiste verder gespecifieerd door een 3-tal nietcumulatieve voorwaarden in te stellen waarbij minstens aan één ervan moet voldaan zijn.
Art. XII.15., § 1, eerste streepje WER laat duidelijk blijken dat de wetgever veel waarde hecht aan ‘de
verstaanbaarheid’ van de tekens die aangebracht zijn op de drager. De verstaanbaarheid van
hashwaarden en smart contract code t.a.v. de gemiddelde ‘afnemer van de dienst’ bij een normaal
smart verzekeringscontract zal nihil zijn. Aan deze voorwaarde lijkt mij bijgevolg volgens het huidige
recht bijgevolg niet voldaan te zijn.
Art. XII.15, §1, tweede streepje WER spreekt over ‘de elektronisch handtekening186’ en
‘gekwalificeerde elektronische handtekening187’ zoals bepaald in de eIDAS-verordening. Het lijkt mij
eveneens een optie om a.d.h.v. de elektronische (gekwalificeerde) handtekening een smart contract
volgens het huidige recht rechtsgeldig te ondertekenen. De elektronische handtekening bezit vandaag
nl. 2 dezelfde gebruikte technieken als bij blockhain! Het cryptografische techniek zoals bij de publieke
sleutel (PKI – public key infrastructure) en het gebruik van hashwaarden188. De elektronische
handtekening kan m.i. als een soort van orakel dienen ter identificering van de verzekeringnemers die
een smart verzekeringscontract sluiten via een blockchain. Het orakel (elektronische handtekening
volgens eIDAS) verloopt dan off-chain maar de voorwaarden van de smart contract code kunnen hier
wel door worden getriggerd. Bv. Een smart contract waarin bepaald is dat het smart
verzekeringscontract slechts wordt gesloten als er een digitale eIDAS-handtekening voorafging (lees:
aanvaard wordt i.d. zin van art.57, §5, eerste lid WER). De ondertekening van een elektronisch contract
komt voornamelijk neer op de waarborg dat de handtekening authentiek is en ongewijzigd blijft189. In
deze hypothese lijkt het mij aannemelijk dat aan deze voorwaarde kan voldaan zijn om volgens het
huidige recht een uw smart verzekeringsovereenkomst op afstand via blockchain te sluiten. Maar dan
ook enkel in deze hypothese… Anders zal je genoodzaakt zijn om terug te grijpen naar art. 64, §1,
tweede lid W. Verz. om bijgevolg bv. een opgesteld Ricardiaans contract (wat in se een soort van kopie
is van uw originele smart verzekeringsovereenkomst maar dan in begrijpelijke taal (nietprogrammeertaal)) aan te voeren als begin van bewijs door geschrift (wat geenszins dezelfde
bewijswaarde behelst als het hogere bewijs door geschrift als bepaald in het eerste lid van art. 64 W.
Verz.).
186
Art.3.10. eIDAS
Art. 3.12. eIDAS
188
N. VANDEZANDE, When an Original Is Not Original, Antwerpen, Intersentia, 2019, 135-141, nrs. 268-281.
189
Vgl. N. VANDEZANDE, When an Original Is Not Original, Antwerpen, Intersentia, 2019, 138-141, nrs. 274-277.
187
103
In de andere hypothese waarbij men uitgaat van een code as law-principe zal men m.i. minstens met
een Ricardiaans contract moeten werken waarvan er een schriftelijke kopie bestaat die eveneens
voldoet aan de voorwaarden van art. 64 W. Verz.
6. Personalisatie van de dekking en de premie? Segmentatie 2.0? (Titel 3, hoofdstuk 2
W. Verz.)
190
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 24.
191
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 23.
192
EU, EU Blockchain Observatory and Forum, https://ec.europa.eu/digital-single-market/en/eu-blockchainobservatory-and-forum (consultatie 18 april 2019).
193
EU, https://www.eublockchainforum.eu/ (consultatie 18 april 2019).
194
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 28-29, nrs. 4 en 5.
195
P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 15-17, nr.11.
196
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 28-29, nr. 4.
104
Over de noodzakelijkheid om dit via een blockchain te doen kan er nog discussie worden gevoerd.
Maar dat het een passend medium is om ELKE segmentatie objectief te rechtvaardigen, dat lijdt m.i.
geen twijfel. Wat kan er nu beter zijn dan één groot netwerk van gedeelde informatie die eveneens
bijdraagt aan de correctheid van de segmentatie…?
197
P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 12, nr. 9.
198
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 28-29, nrs. 3 en 4.
199
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 29-30, nrs. 6 en 7.
200
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 33, nr. 12, laatste
zin.
201
B. WEYTS en T. VANSWEEVELT, De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 30-31, nr. 8.
105
7. Anonimiteit op een blockchain. Onoverkomelijk… of toch niet?
202
ZieL. SCHUERMANS en C. VAN SCHOUBROECK, Grondslagen van het Belgische verzekeringsrecht, 3e editie,
Antwerpen, Intersentia, 2015, 73-104.
203
ZELFMOORD1813, https://www.zelfmoord1813.be/ (consultatie 24 april 2019).
204
DE DRUGLIJN, Anonimiteit en Privacy, https://www.druglijn.be/privacy (consultatie 24 april 2019).
205
Zie
WIKIPEDIA,
Communications
Assistance
for
Law
Enforcement
Act,
https://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act (consultatie 24 april
2019).
206
A.D.F. WRIGHT, Primavera, "Decentralized Blockchain Technology and the Rise of Lex Cryptographia", SSRN
2015, (1) 23.
106
Verder verhindert anonimiteit van de kandidaat-verzekeringnemer een a priori selectie op basis
waarvan de verzekeraar met enige vorm van zekerheid de segmentatietechniek kan toepassen en de
premie en de dekking laat variëren in functie hiervan (Supra, nr. 179).
207
J. GOOSSENS en K. VERLYPE, Blockchain en smart contracts : Het einde van de vertrouwde tussenpersoon?,
Brussel, Els Belgium, 2019, 43-44.
208
P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 33, nr. 26.
209
Zie P. COLLE, De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 33-39.
107
Deel 4: Conclusie
108
Tot slot is het nog de vraag of de burger wel bereid is om de switch door te voeren naar een vertrouwen
in blockchain en smart contracts en hierbij af te stappen van een jarenlange ervaring met de
vertrouwde tussenpersonen210. Bij verzekeringen geldt deze switch van vertrouwen niet alleen voor
de verzekeringnemers, maar eveneens voor de verzekeraars zelf. Als de het doel van een blockchain
gerealiseerd wordt dan zou het voor de verzekeringstussenpersonen op het eerste zicht het verlies van
hun job kunnen betekenen… of misschien toch niet? Misschien kunnen zij hier de opportuniteit in zien
en eveneens hun focus op verleggen op andere zaken. in Vertrouwen in een nieuwe technologie
ontstaat niet van dag op dag. Dat is iets wat tijd vergt211. Maar die tijd gaat natuurlijk pas in wanneer
er effectief actie wordt ondernomen… Dat is tot op vandaag nog te weinig concreet. Hopelijk mogen
we binnenkort een reactie zien binnen de verzekeringswereld en wordt er daad bij woord gevoegd.
Want dat er reeds een pak woorden over gevloeid zijn en dat InsurTech een hot topic is, dat is zeker.
Maar dat van ‘daad bij woord’ zal eveneens afhangen van de Europese en Belgische wetgever zo blijkt.
210
Vgl. T.J. DE GRAAF, "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (II)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7200, (525) 525, puntje 4.1., 1e al. waar de auteur
het verschil benadrukt tussen vertrouwen in personen (trust by communication) en het vertrouwen in code (trust
by computation).
211
Vgl. D. WEYNS, Software Engineering of Self-adaptive systems, in C. SUNGDEOK et al., Handbook of Software
Engineering, Basel, Zwitserland, Springer International Publishing, 2019, 432, puntje 4.1., 1e al., eerste zin juncto
437, 2e al. waar de auteur verwijst naar een studie die zegt dat een technologie meestal een 15 tot 20-tal jaar
nodig heeft om maturiteit te vertonen om vervolgens wijdverspreid gebruikt te worden.
109
Bibliografie
AXA, CONDITIONS GENERALES DU CONTRAT FIZZY VALANT NOTICE D’INFORMATION,
https://fizzy.axa/en-gb/static/media/conditions-generales.38af84e2.pdf (consultatie 6 mei 2019).
AXA, https://fizzy.axa/en-gb/ (consultatie 6 mei 2019).
B3I,
B3i
Community
Conference
–
Amsterdam
2018,
https://conference.b3i.tech/portfolio_page/november-2018conference/https://conference.b3i.tech/portfolio_page/november-2018-conference/ (consultatie 6
mei 2019).
B3I, The Blockchain Insurance Industry Initiative, https://b3i.tech/home.html (consultatie 6 mei 2019).
BAKKER, K.J. en KREILEMAN, N., "Verslag WONO-symposium 25 januari 2019", Maandblad voor
Ondernemingsrecht 2019, afl. 3-4.
BAUDONQ, F., "Dubbele verkoop", NJW 2004, afl. 86, 1126-1130.
BELGIË,
W.K.,
Belgian
Insurance
Conference,
conference.wolterskluwer.be/nl/programma/ (consultatie 5 april 2019).
https://belgian-insurance-
BERLEE, A., "Pandakteregistratie van Belastingdienst naar blockchain: een verkenning", Maandblad
voor Vermogensrecht 2018, afl. 3, 87-93.
110
BERNAUW, K., "Wijzigingen in de verzekeringswetgeving: wet 4 april 2014 en andere nieuwigheden",
Rechtskroniek voor de vrede- en politierechters 2015 2015, 234.
BERNAUW, K., ROUX, S. en MILLARD, D., Dossier 2018: Micro-verzekering: naar een inclusieve
verzekeringsmarkt?, Mechelen, Wolters Kluwer, 2019, 1-83 p.
BIGCHAINDB,
Blockchain
Powered
Land
Registry
in
Ghana
with
https://www.bigchaindb.com/usecases/government/benben/ (consultatie 6 mei 2019).
BenBen,
BITCOINWIKI, Scalability, https://en.bitcoin.it/wiki/Scalability#Scalability_targets (consultatie 15 april
2019).
BLOOVI, Onderzoek: Helft Belgen klaar voor de 'digitale verzekeraar', maar sector volgt niet,
https://www.bloovi.be/artikels/innoveren/2018/onderzoek-helft-belgen-klaar-voor-de-digitaleverzekeraar-maar-sector-volgt-niet (consultatie 13 april 2019).
BOONE, R.K., Annelien, "Legal tech maakt meer tijd vrij voor contacten met cliënten", Juristenkrant,
13 maart 2019, 8-9.
BRITANNICA,
T.E.o.E.,
Napster
File-sharing
computer
https://www.britannica.com/topic/Napster (consultatie 28 september 2018).
service,
CLACK, C., A. BAKSHI, V. en BRAINE, L., "Smart Contract Templates: foundations, design landscape and
research directions" 2016, https://www.semanticscholar.org/paper/Smart-Contract-Templates%3Afoundations%2C-design-and-Clack-Bakshi/0c3166e6773fb8a894670bf4d6da9bd512170e63, 15.
CLAERHOUT, P., Insurtech is the next big thing: technologische innovatie breekt door in de
verzekeringssector,
https://trends.knack.be/economie/bedrijven/insurtech-is-the-next-big-thingtechnologische-innovatie-breekt-door-in-de-verzekeringssector/article-normal-914545.html
(consultatie 13 april 2019).
CLEMENT, A., fizzy.axa Smart contract explained, https://medium.com/@humanGamepad/fizzy-axasmart-contract-explaind-740df52894fd (consultatie 6 mei 2019).
CLUDTS, D., Verzekeringssector voelt hete adem van Google en Amazon in de nek,
https://www.techzine.be/blogs/13276/verzekeringssector-voelt-hete-adem-van-google-en-amazonin-de-nek.html (consultatie 19 april 2019).
COLLE, P., De nieuwe wet van 4 april 2014 betreffende de verzekeringen : algemene beginselen van het
Belgische verzekeringsrecht, Antwerpen, Intersentia, 2015, 266 p.
COMARCH, S.A., https://www.comarch.be/nl/verzekeringen/ (consultatie 13 mei 2019).
CRM.ART, https://crm.be/nl/insusoft (consultatie 5 april 2019).
111
DAMBLY, P., "L'impact des insurtechs en 2025 sur l'intermédiation en assurance", T.Verz. 2017, afl. 4,
483-493.
DE BACKER, A. en DE BOE, V., "Smart contracts in de financiële sector: grote verwachtingen en
regulatoire uitdagingen", Computerr. 2017, afl. 6, 355-363.
DE GRAAF, T., "De kwalificatie van bitcoins", Nederlands Juristenblad 2019, afl. 1, 2-13.
DE GRAAF, T.J., "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (I)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7199, 494-501.
DE GRAAF, T.J., "Van oud naar nieuw: van internet naar smart contracts en van mensen naar code (II)",
Weekblad voor Privaatrecht, Notariaat en Registratie 2018, afl. 7200, 525-530.
DE GRAEVE, M. en GYSELAERS, M., Praktisch verzekeringsrecht, Berchem, De Boeck, 2011, 276 p.
DE JONGHE, D. en LAAN, V.I., "Blockchain in de realiteit", Computerr. 2017, afl. 6, 347-353.
DRESCHER, D., Blockchain Basics: A Non-Technical Introduction in 25 Steps, New York, Apress, 2017,
255 p.
DRUGLIJN, Anonimiteit en Privacy, https://www.druglijn.be/privacy (consultatie 24 april 2019).
ECONOMIE,
Raadpleging
Digital
Single
Market
Strategy,
https://economie.fgov.be/nl/themas/online/digitale-agenda-voor-europa/raadpleging-digital-single
(consultatie 13 mei 2019).
EDWIN, Wat is blockchain scaling (schaalbaarheid) en waarom is het zo belangrijk?,
https://www.bitcoinsaltcoins.nl/is-blockchain-scaling-schaalbaarheid-en-waarom-belangrijk/
(consultatie 15 april 2019).
ETHERISC, https://etherisc.com/ (consultatie 6 mei 2019).
ETHERSCAN,
https://etherscan.io/address/0xe083515d1541f2a9fd0ca03f189f5d321c73b872
(consultatie 6 mei 2019).
EU, https://www.eublockchainforum.eu/ (consultatie 18 april 2019).
EU, EU Blockchain Observatory and Forum, https://ec.europa.eu/digital-single-market/en/eublockchain-observatory-and-forum (consultatie 18 april 2019).
112
FENWICK, M., CORRALES, M. en HAAPIO, H., Legal Tech, Smart Contracts and Blockchain, Singapore,
Springer, 2019, 276 p.
FIDEA, De digitale revolutie geeft de verzekeringssector een nieuw gezicht,
https://trends.knack.be/economie/trends-information-services/de-digitale-revolutie-geeft-deverzekeringssector-een-nieuw-gezicht/article-publishingpartner-923781.html (consultatie 19 april
2019).
FINANCIËN, Registratie- en hypotheekkantoren worden 1 kantoor Rechtszekerheid,
https://financien.belgium.be/nl/Actueel/registratie-en-hypotheekkantoren-worden-1-kantoorrechtszekerheid (consultatie 6 mei 2019).
FIRTH, C., AXA launches new blockchain based insurance product for airline passengers,
https://www.financemagnates.com/fintech/news/axa-launches-new-blockchain-based-insuranceproduct-airline-passengers/ (consultatie 25 april 2019).
FONTAINE, M., Verzekeringsrecht, Brussel, Larcier, 2017, 853 p.
G. SIMPSON, A., Toyota, MIT Lab Eye Using Blockchain in Insurance Rating of Driverless and Shared
Vehicles, https://www.insurancejournal.com/news/national/2017/05/23/451913.htm (consultatie 4
april 2019).
GEIREGAT, S., "Eigendom op bitcoins", Rechtskundig Weekblad (RW) 2017, afl. 27, 1043-1050.
GEIREGAT, S., "Cryptocurrencies are (smart) contracts", Computer Law & Security Review 2018, afl. 5,
1144-1149.
GENOOTSCHAP, Masterclass The actuarial use of Blockchain https://www.agai.nl/community_events.php?action=view&Event_Id=9223 (consultatie 13 mei 2019).
GIANCASPRO, M., "Is a ‘smart contract’ really a smart idea? Insights from a legal perspective",
Computer Law & Security Review 2017, afl. 6, 825-835.
GLOUDEMANS-VOOGD, N., "Smart Contracts worden volwassen", Advocatenblad, December-Januari
2017, 52-53.
GOETEYN, S., COUCKUYT, D.c. en LEMEIRE, L.p.N.I.V., Blockchain as a Service, onuitg. Universiteit Gent,
2018, 93 p., http://lib.ugent.be/catalog/rug01:002508971.
GOOSSENS, J. en VERLYPE, K., Blockchain en smart contracts : Het einde van de vertrouwde
tussenpersoon?, Brussel, Els Belgium, 2019, 136 p.
113
GOVERNATORI, G., IDELBERGER, F., MILOSEVIC, Z., RIVERET, R., SARTOR, G. en XU, X., "On legal
contracts, imperative and declarative smart contracts, and blockchain systems", Artificial Intelligence
and Law 2018, afl. 4, 377-409.
GROUP, S.C.W., Smart contracts as a specific application of blockchain technology,
https://axveco.com/wp-content/uploads/2017/12/Smart-Contracts-ENG-report.pdf (consultatie 4
april 2019).
GÜRKAYNAK, G., YıLMAZ, İ., YEŞILALTAY, B. en BENGI, B., "Intellectual property law and practice in the
blockchain realm", Computer Law & Security Review 2018, afl. 4, 847-862.
INVSTOR,
T.C.,
Schaalbaarheid,
(consultatie 15 april 2019).
https://thecryptoinvstor.nl/crypto-termen/schaalbaarheid
ISDA en LINKLATERS, Whitepaper Smart Contracts and Distributed Ledger - A Legal Perspective,
https://www.isda.org/2017/08/03/smart-contracts-and-distributed-ledger-a-legal-perspective/
(consultatie 16 april 2019).
JANSSEN, A. en DUROVIC, M., "The Formation of Blockchain-based Smart Contracts in the Light of
Contract Law", European Review of Private Law 2018, 753-771.
JANSSENS, M.-C. en VANHERPE, J., Blockchain and copyright - Beyond the buzzword?, 2018.
KAULARTZ, M. en HECKMANN, J., Smart Contracts – Anwendungen der Blockchain-Technologie, 2016,
618 p.
KBC, Verifieer uw KBC document, https://www.kbc.be/particulieren/nl/verifieer.html (consultatie 11
april 2019).
KEEREMAN, A., "UGent organiseert eerste Belgische Legal Techathon", Juristenkrant, 7 november
2018, 8.
KELAHAN, P., Parametric Insurance - The Least Known Best Response to Unfortunate Happenings,
https://dailyfintech.com/2019/03/21/parametric-insurance-the-least-known-best-response-tounfortunate-happenings/ (consultatie 6 mei 2019).
KOSTER, H., "Blockchain, crypto finance
Ondernemingsrecht 2018, afl. 3, 151-154.
en
robotisering
in
het
ondernemingsrecht",
L.S., H., Blockchain Insurance Industry Initiative B3i Grows to 15 Members,
https://www.insurancejournal.com/news/international/2017/02/06/440629.htm (consultatie 6 mei
2019).
114
LAAN, V.I.R., A., "Privacy-issues bij blockchain: hoe voorkom of minimaliseer je die?", Computerr. 2017,
afl. 6, 364-371.
MAK, V., "Op weg naar een Europese ‘Digital Single Market’ Twee nieuwe richtlijnvoorstellen voor het
Europees contractenrecht", Nederlands Juristenblad 2016, afl. 8, 518-524.
MILLARD, C., "Blockchain and law: Incompatible codes?", Computer Law & Security Review 2018, afl.
4, 843-846.
MURPHY, S.S., Ronald David; Percival, Robert L., Can Smart Contracts be legally binding contracts?,
https://www.nortonrosefulbright.com/en-ca/knowledge/publications/a90a5588/can-smartcontracts-be-legally-binding-contracts (consultatie 9 april 2019).
NAVES, J., "Smart contracts: Voer voor juristen?", Onderneming en Financiering 2018, afl. 4, 57-67.
NBB, Impactanalyse van fintech en digitalisering op de Belgische banksector en bankentoezicht,
https://www.nbb.be/nl/artikels/impactanalyse-van-fintech-en-digitalisering-op-de-belgischebanksector-en-bankentoezicht (consultatie 19 april 2019).
O' SHIELDS, R., "Smart Contracts: Legal Agreements for the Blockchain", Banking Insitute Journal 2017,
afl. 1.
PARIZI, R.M., AMRITRAJ en DEHGHANTANHA, A., Smart Contract Programming Languages on
Blockchains: An Empirical Evaluation of Usability and Security, Cham, Springer International Publishing,
2018, 75-91 p.
PEVERELLI,
R.,
Marketing
Science:
Blockchain
in
verzekeringen
https://www.eyvodw.com/blog/marketing-science-blockchain-in-verzekeringen (consultatie 6 mei 2019).
PHILIPPE, D., "Blockchain and smart contract: lex cryptographia?", DAOR 2018, afl. 4, 6-17.
POULLET, Y.J., H., "Blockchain : une révolution pour le droit ?", Journal des Tribunaux 2018, 801-819.
PWC, InsurTech, https://www.pwc.nl/nl/marktsectoren/verzekeraars/insurtech.html (consultatie 13
april 2019).
S. HARRINGTON, J., The Present Use and Promise of Blockchain in Insurance,
https://www.insurancejournal.com/news/national/2017/05/16/451177.htm (consultatie 6 mei
2019).
SATOSHI, N., Bitcoin: a peer-to-peer electronic cash system, www.bitcoin.org/bitcoin.pdf (consultatie
4 oktober 2018).
115
SCHMAAL, J.B. en VAN GENUCHTEN, E.M., "Smart contracts en de Haviltex-norm", Tijdschrift voor
Internetrecht 2017, afl. 1, 12-17.
SCHUERMANS, L. en VAN SCHOUBROECK, C., Grondslagen van het Belgische verzekeringsrecht, 3e
editie, Antwerpen, Intersentia, 2015, 1-1026 p.
SCHURINGA, H., "Enkele civielrechtelijke aspecten van blockchain", Computerr. 2017, afl. 6, 372-378.
SIMAL, J., Blockchain en privacy: een onderzoek naar de verzoenbaarheid van blockchaintechnologie
met de GDPR, onuitg. Masterscriptie Faculteit Rechtsgeleerdheid KU Leuven, 2018, 58 p.
STAM, J.K., "Smart contracts?", Contracteren 2018, 54-60.
STORME, M.E., "Rechtszekerheid en vertrouwensbeginsel in het Belgisch verbintenissenrecht", TPR
1997, 1861-1935.
SUICHE, M., The $280M Ethereum’s Parity bug. A critical security vulnerability in Parity multi-sig wallet
got triggered on 6th November — paralyzing wallets created after the 20th July.,
https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513 (consultatie 17 april 2019).
SUNGDEOK, C., RICHARD, T.N. en KANG (ED.), K., Handbook of Software Engineering, Basel,
Zwitserland, Springer International Publishing, 2019, 524 p.
SUY, P., KBC bestrijdt 'fake news' met blockchain, https://www.tijd.be/ondernemen/financielediensten-verzekeringen/kbc-bestrijdt-fake-news-met-blockchain/9907261.html (consultatie 11 april
2019 2019).
SWISSRE,
Airmic
2019
03
05
June
2019
CET,
https://corporatesolutions.swissre.com/insights/events/airmic-2019.html?tab=section-international
(consultatie 10 mei 2019).
TJONG TJIN TAI, E., "Juridische aspecten van blockchain en smart contracts", TPR 2017, afl. 2/3, 563608.
TJONG TJIN TAI, E., "Smart contracts en het recht", Nederlands Juristenblad 2017, afl. 3, 176-183.
TRUDELL, C.H., Yuki, Toyota $1B Research Labs Near Stanford, MIT to Develop Autonomous Vehicles,
https://www.insurancejournal.com/news/national/2015/11/06/387751.htm (consultatie 6 mei
2019).
TRUYENS, M., "Smart contracts: moeten juristen programmeurs worden?", Juristenkrant, 23 november
2016, 12-13.
116
VALGAEREN, E.L., J.J., "Inleiding: Blockchain ontketend", Computerr. 2017, afl. 6, 343-346.
VAN DE LOVERBOSCH, M., "Crypto-effecten: tussen droom en daad", TRV 2018, afl. 3, 193-207.
VAN DER LINDEN, M., "Het recht geketend: Smart contracts: dé oplossing voor gezeur, gedoe en
onzekerheid?", Tijdschrift voor Internetrecht 2018, afl. 2, 59-63.
VAN DER WEES, J.G.L., "Juridische verkenning naar smart contracts", Computerr. 2018, afl. 1, 54.
VAN ECK, B.M.A., "noot onder ABRvS 17 mei 2017", Computerr. 2017/256, afl. 6, 395-397.
VAN HEUKELOM, S., "Responsieve rechtsstaat en digitale overheid: blockchain en smart contracts",
Nederlands Tijdschrift voor Bestuursrecht 2018, afl. 5, 217-19.
VAN HEUKELOM, S., NAVES, J. en VAN GRAAFLAND, M., Whitepaper Juridische aspecten van
blockchain,
https://www.platformoutsourcing.nl/f/files/download/overig/whitepaper_blockchain.pdf
(consultatie 5 april 2019).
VAN OEVELEN, A., RUTTEN, S. en ROZIE, J., Recht op toegang tot de rechter, Antwerpen, Intersentia,
2016, 176 p.
VAN OLDENEEL (ED.), C.-A., DOSSIER 2017 Data protection: De impact van de GDPR in de verzekering,
Mechelen, Wolters Kluwer, 2017, 1-316 p.
VAN SCHOUBROECK, C., SAMOY, I., AMANKWAH, J., RONSIJN, K., STROOBANTS, N. en VERJANS, E.,
Themis 106 - Aansprakelijkheids- en verzekeringsrecht, Brugge, die Keure / la Charte, 2018, 142 p.
VANDERDONCKT, J., VAN MELKEBEKE, A. en VAN DAELE, G.p., How fit is the Belgian insurance industry
with Blockchain technology?, onuitg. Faculteit Economie & Bedrijfskunde Universiteit Gent, 2018, 90
p., http://lib.ugent.be/catalog/rug01:002509028.
VANDEZANDE, N., When an Original Is Not Original, Antwerpen, Intersentia, 2019, 174 p.
VERHEYE, B., "Blockchaintechnologie en het notariaat bij vastgoedtransacties: Damocles' zwaard of
opportuniteit?", Tijdschrift voor Notarissen (T. Not.) 2018, afl. 3, 212-239.
VERHEYE, B., VERSLYPE, K. en DANNEELS, P., "Blockchain en smart contracts. Impact op de notaris als
vertrouwde tussenpersoon?" 2018.
VUYLSTEKE, B., "Blockchain - Wat is het? Wat kan het betekenen voor het notariaat?", Tijdschrift voor
Notarissen (T. Not.) 2018, afl. 3, 205-212.
117
WERBACH, K., "Trust, But Verify: Why The Blockchain Needs The Law", Berkeley Technology Law
Journal 2017, afl. 489, 489-552.
WEYTS, B. en VANSWEEVELT, T., De Verzekeringswet 2014, Antwerpen, Intersentia, 2015, 178 p.
WEYTS, B. en VANSWEEVELT, T., Handboek Verzekeringsrecht, Antwerpen, Intersentia, 2016, 1152 p.
WIKIPEDIA,
Communications
Assistance
for
Law
Enforcement
Act,
https://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act (consultatie
24 april 2019).
WIKIPEDIA,
Implementatie,
https://nl.wikipedia.org/wiki/Implementatie#Implementatie_van_software (consultatie 6 mei 2019).
WIKIPEDIA, Schaalbaarheid, https://nl.wikipedia.org/wiki/Schaalbaarheid (consultatie 15 april 2019).
WRIGHT, A.D.F., Primavera, "Decentralized Blockchain Technology and the Rise of Lex Cryptographia",
SSRN 2015, 58.
X, https://nl.wikipedia.org/wiki/Software_engineering (consultatie 28 september 2018).
Europees Verdrag tot bescherming van de rechten van de mens en de fundamentele vrijheden, 4
november 1950, Rome, B.S. 19 augustus 1955.
Richtl. nr. 2000/31/EG van het Europees Parlement en de Raad van 8 juni 2000 betreffende bepaalde
juridische aspecten van de diensten van de informatiemaatschappij, met name de elektronische
handel, in de interne markt („richtlijn inzake elektronische handel”), Pb. L. 17 juli 2000, afl. 178, 16.
Verord. (EU) Nr. 910/2014 van het Europees Parlement en de Raad van 23 juli 2014 betreffende
elektronische identificatie en vertrouwensdiensten voor elektronische transacties in de interne markt
en tot intrekking van Richtlijn 1999/93/EG, Pb.L. 28 augustus 2014, 73-114.
Voorstel (Comm.) van 9 december 2015 voor een richtlijn van het Europees Parlement en de Raad
betreffende bepaalde aspecten van overeenkomsten voor de levering van digitale inhoud
Wet tot invoering van het Wetboek van economisch recht, B.S. 28 februari 2013.
Wet tot uitvoering en aanvulling van de verordening (EU) nr. 910/2014 van het Europees Parlement
en de Raad van 23 juli 2014 betreffende de elektronische identificatie en vertrouwensdiensten voor
elektronische transacties in de interne markt en tot intrekking van Richtlijn 1999/93/EG, houdende
invoeging van titel 2 in boek XII “Recht van de elektronische economie” van het Wetboek van
economisch recht, en houdende invoeging van de definities eigen aan titel 2 van boek XII en van de
rechtshandhavingsbepalingen eigen aan titel 2 van boek XII, in de boeken I, XV en XVII van het Wetboek
van economisch recht, B.S. 21 juli 2016.
118
Wet van 4 april 2014 betreffende de verzekeringen, B.S. 30 april 2014.
Wet van 11 juni 1874 betreffende Verzekeringen, B.S. 14 juni 1874.
Wet van 21 november 1989 betreffende de verplichte aansprakelijkheidsverzekering inzake
motorrijtuigen, B.S. 8 december 1989.
Wet van 25 juni 1992 betreffende de Landverzekeringsovereenkomst, B.S. 20 augustus 1992.
ZELFMOORD1813, https://www.zelfmoord1813.be/ (consultatie 24 april 2019).
BIJLAGEN
Bijlage I: Vragenlijst betreffende een onderzoek naar de voordelen die een blockchain
en/of smart contracts potentieel te bieden hebben binnen de verzekeringssector –
beantwoord door Bart Van Buggenhout (Development business manager, KBC Bank &
Verzekering), Joeri Jackers (Blockchain developer, KBC Bank & Verzekering) & Matthieu
Merlyn (Blockchain developer, KBC Bank & Verzekering)
Tijdstip: 25 april 2019, 13u27
1) Welke taken in je werk nemen het grootste deel in beslag volgens jouw persoonlijke ervaring?
o
KBC Verzekeringen is een vrij groot bedrijf met ca. 1.200 werknemers en > 300 zelfstandige
agentschappen. De taken die door al deze mensen worden uitgevoerd zijn zeer divers van
aard en het is niet eenvoudig om hier zo eenduidig een antwoord op te geven.
2) Zijn er taken in de verzekeringssector waarvan je zelf het gevoel hebt dat die evengoed
geautomatiseerd zouden kunnen worden?
o
o
Wij automatiseren vandaag reeds heel wat processen, in functie van:
1. Doorlooptijd (hoe snel bedienen we de klant)
2. Werkbelasting (hoeveelheid werk)
3. Risico (reductie van foutenlast)
Heel wat zaken die “procedureel” verlopen zijn zo reeds geautomatiseerd.
119
3) Hoe zou u zelf staan tegenover een polis die volledig geregeld wordt in een geprogrammeerde
code (=smart contract)? De afdwinging en nakoming van de polis zou compleet gecontroleerd
worden door die code i.p.v. een tussenkomst door een tussenpersoon zoals bv. een
verzekeringsagent/makelaar. M.a.w. zijn er ook polissen die bijna altijd een automatische inputoutput procedure zijn? Dit zou potentieel tijd vrijmaken om meer aandacht te besteden aan
andere dossiers die vaak een meer menselijke beoordeling en aanpak nodig hebben.
o
Het is niet zo dat de tussenpersoon vandaag het nakomen van de polis moet “afdwingen”.
Een schadegeval wordt meer en meer digitaal aangegeven.
o
Het lijkt me enkel voor “rechttoe-rechtaan” polissen mogelijk om deze volledig via een
“smart contract” te regelen (bv. vertraging vlucht is eenvoudig en vrij binair). Je hebt
enerzijds de complexiteit van de polis die je moet “programmeren”, maar anderzijds moet
je ook in staat zijn de aangifte correct te digitaliseren en interpreteren. Artificiële
intelligentie kan hierbij een rol spelen, maar bij zulke cases dienen we waarschijnlijk toch
steeds de mogelijkheid voor een menselijke beoordeling open te laten. Een mogelijkheid
zou bv. de levensverzekering kunnen zijn omdat deze ook vrij binair en eenvoudig is.
4) Een bijkomend gevolg van zo een smart contract zou kunnen betekenen dat de uitkomst die de
geprogrammeerde code bepaalt ook in de werkelijkheid moet nageleefd worden. Men spreekt ook
wel over “code is law” of “de code spreekt voor recht”. Discussies achteraf m.b.t. de polis zouden
hierdoor worden uitgeschakeld. Ook de eventuele rol van een rechter wordt hierdoor
weggeveegd. Hoe staat u tegenover dit idee?
o
Voor ons zijn de 2 aspecten niet “onlosmakelijk” met elkaar verbonden: je hebt:
1. Smart: dit betreft de automatisering ➔ programmeren van de logica
2. Contract: het juridisch aspect ➔ hierbij vooral de vraag of je discussies kan
“verbieden”, alsook de mogelijkheid kan/mag uitsluiten om naar een rechtbank te
stappen. Dat zou veronderstellen dat een “smart contract” onfeilbaar is…
5) Hoe verloopt de premiezetting nu (cf. berekening van het risico; segmentatie; spreiding (omslag);
personalisatie van de dekking)? De wet van de grote getallen in de praktijk? Kan dit eventueel via
een code statistisch worden bijgehouden en geautomatiseerd worden of gebeurt dit vandaag al?
o
Ik denk niet dat we op dit vlak veel toegevoegde waarde zullen hebben door Blockchain.
6) Met welk softwaresysteem wordt er nu gewerkt? Zijn er verschillende? Door wie worden ze
beheerd (centraal beheer door één entiteit of niet)? Is dit een extern informaticabedrijf of werken
jullie met een eigen (intern) ontwikkeld softwaresysteem?
o
o
We werken met verschillende softwaresystemen, die centraal beheerd worden. De meeste
werden intern ontwikkeld.
Zie ook het antwoord op de vraag hieronder.
7) Hoe wordt er bij jullie nagedacht over de veiligheid van jullie softwaresystemen? Zijn er vaak
veiligheidsupdates van de software die gebruikt wordt?
120
o
Als bank-verzekeraar dragen wij privacy en integriteit van onze klantengegevens uiteraard
hoog in het vaandel, waardoor wij ook zeer sterk inzetten op alles wat veiligheid betreft.
Binnen KBC hebben we een zeer grote groep IT specialisten die onze applicaties
ontwikkelen en ondersteunen en daar hoort natuurlijk ook een security afdeling bij.
Essentieel hierbij is dat deze kennis en expertise in-house wordt opgebouwd waardoor KBC
toch wel als een van de grote IT bedrijven binnen België beschouwd kan worden.
o
Het feit dat onze applicaties allemaal binnenshuis ontwikkeld en ondersteund worden,
betekent ook dat we een goed overzicht hebben op de technische implementaties en de
bijbehorende implicaties naar veiligheid. Het patchen en updaten van onze applicaties is
hierbij een integraal deel van het onderhoudsproces en behoort tot de dagtaak van
verschillende van onze medewerkers.
8) Had u voor deze vragenlijst reeds gehoord over blockchain en smart contracts? Indien ja, wat denkt
u over deze nieuwe technologie en ziet u een mogelijke rol voor deze technologie binnen de
verzekeringssector?
o
We hadden er zeker al over gehoord en hebben als KBC reeds ervaring met Blockchain. Op
vlak van Smart Contracts zien we ook in de markt echter nog maar een beperkt aantal
concrete “real life” toepassingen.
o
Op dit ogenblik hebben we al verschillende blockchain producten in de markt. Een ervan is
beschikbaar op onze website en geeft de mogelijkheid om KBC documenten op
authenticiteit
te
checken
m.b.v.
een
blockchain
toepassing.
Het We.Trade platform is een ander voorbeeld en heeft als doel om internationale handel
te vergemakkelijken. KBC heeft hier de rol van founding member opgenomen in het
consortium en we kunnen wel spreken van een van de eerste succesverhalen in het
blockchainlandschap
met
dit
internationaal
project.
Verder hebben we verschillende blockchainprojecten in de pipeline met een focus op onder
andere internationale betaalverkeer
(Utility Settlement
Coin
–
USC).
We zitten dus zeker niet stil binnen KBC, maar het verzekeringsluik is hier voorlopig nog
ondervertegenwoordigd.
Bart Van Buggenhout,
Business development manager, KBC Bank & Verzekering
Joeri Jackers,
Blockchain developer Surf Studio Labs, KBC Bank & Verzekering
Matthieu Merlyn,
Blockchain developer Surf Studio Labs, KBC Bank & Verzekering
Bedankt voor uw deelname aan deze vragenlijst !
Jan De Vleeschouwer
121
Bijlage II: Interview Johan De Vleeschouwer (Verzekeringsagent DVV – Zelfstandig
Agentenkorps - CVBA DRS-Zakenkantoor (De Rocker – Smet) te Heusden)
Tijdstip: 5 april 2019, 12u30
Plaats: Dorp 36, 9185 Wachtebeke
1) Welke taken in je werk nemen het grootste deel in beslag volgens jouw ervaring?
Johan: “Wij zijn een zelfstandig agentenkorps (CVBA DRS-Zakenkantoor (De Rocker – Smet)). Ik doe
voornamelijk het eerstelijnswerk. Een groot deel van mijn werk houdt de opmaak van polissen en
offerten (bijvoegsels) in. Ook schadebeheer.”
2) Wordt er vandaag al gewerkt met online offertes in jullie kantoor?
Johan: “Bij DRS wordt er met tussenpersonen gewerkt. Geen online offertes zonder tussenkomst van
een fysiek persoon. Ons zelfstandig agentenkorps heeft met DVV een bepaald contract afgesloten om
welbepaalde dingen te mogen doen (soort van beheerscontract dat voor meerdere jaren wordt
afgesloten met de vereniging van zelfstandige consulenten) (cf. commissielonen, werksystemen, etc.).
Bovendien maakt DVV deel uit van de Belfiusgroep (3 verzekeringskanalen (DVV met zelfstandige
consulenten; Belfius Bank; Corona).
3) Hoe verloopt de inning van de premies bij jullie kantoor ? Worden die premies eerst ontvangen
door jullie als zelfstandig verzekeringsagent en dan doorgestort naar DVV of hoe verloopt dit
precies?
Johan: “De premies worden rechtstreeks aan DVV zelf betaald. Dat is de regel. De zelfstandige
consulenten worden dan commissie uitbetaald door DVV. De uitzondering is dat er nog premies aan de
zelfstandige consulenten zelf wordt betaald. Dat komt hem meestal neer op een 2 à 3 personen in de
maand.”
122
4) Met welk softwaresysteem wordt er nu gewerkt? Zijn er verschillende? Door wie worden ze
(centraal?) beheerd?
Johan: “Wij gebruiken voornamelijk 2 programma’s nl. DIBIS (typisch voor DVV – polissen) en Insusoft
(Polissenbeheersysteem voor alle verzekeringsmaatschappijen). Daarnaast gebruiken wij ook een
programma voor de digitalisering van papieren documenten in het kader van polissenopslag en
raadpleging (DIGIS)”
5) Is er een verschil van software tussen directe verzekeringen en herverzekeringen?
Johan: “Wij doen enkel aan directe verzekeringen. Hoogstens een keer medeverzekering. Meestal is dat
in het kader van een overname (vaak als waarborg bij overnamen).”
Johan De Vleeschouwer,
Zelfstandig verzekeringsagent, DRS-zakenkantoor
Bedankt voor het interview!
Jan De Vleeschouwer
123