Verdere opbouw

Waar welke technologie precies terechtkomt wordt getoond op figuur 3.5. Er werd een Big- chainDB driver aan de front-end applicatie toegevoegd die communiceert met de BigchainDB server van een knoop. De blockchain interface wordt zowel door BigchainDB als door Tender- mint gerealiseerd. BigchainDB communiceert met de interface van Tendermint die vervolgens de nodige aanpassingen uitvoert aan de BigchainDB applicatie zodat de gegevens kunnen opgeslagen worden in MongoDB. De consensus tussen de verschillende knopen wordt volledig gerealiseerd door Tendermint. Merk op dat er zowel een front-end als blockchain applicatie is. Dit zijn de twee delen van de applicatielaag vernoemd in 3.1. De front-end applicatie is wat de gebruiker ter beschikking heeft en waar de validatie gebeurt bij deze implementatie. De blockchain applicatie is de applicatie die zich op de knoop resideert en waar alle data wordt opgeslagen.

Met de huidige frameworks die ter beschikking zijn, werd een eerste implementatie geco- deerd. Deze implementatie is bruikbaar via de commandline. Hierbij werden twee delen zelf ge¨ımplementeerd: De applicatie die de hoofdtaken verricht en de virtual RDF service. Voor de PPM compressie werd vrij beschikbare software [43] gebruikt. De applicatie die de hoofdtaken verricht heeft twee belangrijke functies:

ˆ writeTx: Verwacht een pad naar het herkomstinformatie bestand en het formaat van de herkomstinformatie.

ˆ readTx: Verwacht een pad waar het bestand zal worden opgeslagen, het formaat van de uitvoer en de transactie id voor het lokaliseren van de juiste transactie op de blockchain met de bijhorende herkomstinformatie.

3.4

Evaluatie

Met de implementatie die werd gebouwd, kan er al een herkomstinformatie blockchain systeem worden opgezet. Dit systeem heeft de volgende functionaliteiten:

Figuur 3.5: Een visuele voorstelling van de implementatie met de bijhorende technologie¨en

ˆ Wegschrijven van herkomstinformatie naar de blockchain vanaf meerdere formaten. ˆ Uitlezen van herkomstinformatie in meerdere formaten.

Dit verwezenlijkt een systeem waarmee herkomstinformatie in de blockchain kan worden op- geslagen. Hiermee werd al een eerste experiment uitgevoerd die mogelijke problemen met de huidige implementatie kon aantonen. Daarbij werd zowel herkomstinformatie als willekeurige data verstuurd naar de blockchain via zowel de applicatie als rechtstreeks via de BigchainDB endpoint (zonder gebruik van compressie of PROV Python). De reden dat er ook willekeurige data werd verstuurd is zodat kon worden bekeken hoe het blockchain systeem hierop zou re- ageren. De resultaten van dit experiment werden dan gebruikt om mogelijke problemen met het systeem te identificeren. Hoewel er al op voorhand tekortkomingen werden verwacht, gaf het voornamelijk een beter beeld van wat de tekortkomingen precies gingen zijn.

3.4.1 Opzet

Om te kunnen uittesten hoe goed onze initi¨ele implementatie werkte was er nood aan een reeks van realistische herkomstinformatie bestanden. Een goede bron hiervoor was de Prov Store [37]. Dit maakt deel uit van Open Provenance en werd al eerder vernoemd in 2.4.3.5. Prov Store biedt een opslag aan voor zowel private als publieke herkomstinformatie. Prov Store on- dersteund meerdere specificaties: PROV-N, PROV-O in Turtle of TriG formats, PROV-XML en PROV-JSON. Bij het opslaan wordt deze verwerkt door Prov Store naar een gestandaar- diseerd formaat (PROV-N) gebruikmakend van PROV Python. Door dit standaardiseren kunnen de documenten opgehaald worden uit de Prov Store in ´e´en van de ondersteunde formaten.

komstinformatie (aantal agenten, entiteiten, ...), mogelijkheid tot visualisatie en een RESTful interface. De RESTful interface is een interessant onderdeel omdat dit ervoor gezorgd heeft dat alle publieke herkomstinformatie snel kon worden opgehaald door middel van een kort script. Via de /store/api/v0/documents/:id endpoint van de Prov Store API kan voor een specifiek document id informatie worden opgehaald. Door de extensie van het formaat toe te voegen aan de endpoint kan de herkomstinformatie zelf worden opgehaald. Een voorbeeld hiervan is /store/api/v0/documents/5.ttl. Dit geeft document nummer vijf terug in Turtle formaat. Alle documenten worden sequentieel genummerd. Als een document niet toegan- kelijk is wordt er een foutmelding gegeven: HTTP 403 Forbidden, wat wil zeggen dat de bron niet toegankelijk is. Elk document dat dan wel toegankelijk is zal worden opgeslagen en verstuurt worden als transactie naar de blockchain.

Het doel was om eerst alle bestanden op te halen en vervolgens al deze bestanden door te sturen naar een BigchainDB knoop die lokaal gehost werd. Om te vermijden dat er onnodig bandbreedte werd gebruikt, werd dit opgesplitst in twee delen. Het eerste deel haalde alle bestanden met herkomstinformatie op vanuit de Prov Store. Hierbij werd ook al bekeken hoe- veel bestanden er precies werden opgehaald aangezien een groot deel niet publiek beschikbaar is. Het tweede deel maakte van elk herkomstinformatie bestand een transactie en stuurde dit door naar de blockchain. Op die manier werd er bij mogelijke fouten vermeden dat alle data opnieuw moest worden opgehaald. Er werden ook bestanden verstuurd die geen herkomstin- formatie bevatten en deze werden zowel via de applicatie als ook via de BigchainDB endpoint verstuurd. Het experiment wordt ook visueel geschetst op figuur 3.6.

Figuur 3.6: Het verloop van het experiment

3.4.2 Uitvoering

Op het moment van de uitvoering van dit experiment had het laatste publieke ge¨uploade document met herkomstinformatie de id 2108. Doordat al deze id’s incrementeel oplopen

was het ook niet nodig dat er verder werd gegaan dan deze id in het proces om de data op te halen. In het script werd een lus gedefinieerd die 2108 keer een verzoek heeft uitgevoerd om zo alle beschikbare data in Turtle formaat op te halen. Het bleek echter dat bepaalde Turtle bestanden niet correct waren opgeslagen in de Prov Store en dat er @prefix triplets misten. Hierdoor konden ze niet ingelezen worden in onze implementatie, wat nochtans geen probleem zou mogen zijn aangezien Prov Store dezelfde software bibliotheek gebruikt als in onze implementatie wordt gebruikt om PROV data in te lezen, namelijk PROV Python. Een oplossing was door ze in een ander formaat te exporteren. Door PROV Python worden alle bestanden immers eerst gestandaardiseerd waardoor er geen afhankelijkheid is van het originele formaat. Om die reden werd er gekozen om alle bestanden in JSON op te halen in de plaats in Turtle. Dit gaf verder geen problemen meer.

Vervolgens werd in het tweede deel van het script de data naar de blockchain verstuurd door middel van een transactie. Dit script overliep de folder waar zich alle opgehaalde bestanden bevonden en ging die individueel gaan versturen naar de blockchain. Hiermee kon dan worden vergeleken hoe groot alle bestanden samen zijn en hoe groot de bestanden van de blockchain zijn geworden. Tijdens het verzenden van de transacties bleek ´e´en bestand te groot (zelf indien het gecomprimeerd was) en werd om die reden ook verwijderd uit de verzameling van herkomstinformatie bestanden. Zo bleek dat BigchainDB een limiet heeft op hoe groot een transactie mag zijn, iets wat niet eerder in het onderzoek naar boven kwam.

Tot slot werden nog twee andere bestanden verstuurd die geen herkomstinformatie bevat- ten. Het ene bestand bevatte RDF data, echter was dit geen herkomstinformatie. Namelijk de RDF data die eerder werd getoond op code voorbeeld 2.3 in hoofdstuk 2.1.4. Dit werd verstuurd op dezelfde manier zoals de herkomstinformatie bestanden van Prov Store. Het andere bestand bevatte een willekeurige JSON string en werd rechtstreeks verstuurd naar de BigchainDB endpoint. Dit bestand bevatte noch herkomstinformatie, noch RDF data. Er moet rekening mee gehouden worden dat malafide gebruikers niet noodzakelijk de applicatie hoeven te gebruiken maar een andere toegangsweg tot de blockchain kunnen gebruiken, na- melijk de API van BigchainDB zelf. Dit is al een negatief aspect van de implementatie die naar boven kwam tijdens de uitvoering van het experiment en wordt in 3.5 verder besproken.

3.4.3 Resultaten

Er werden 289 bestanden opgehaald vanuit de Prov Store die publiek toegankelijk waren waarvan er 288 verzonden werden naar de blockchain. ´E´en bestand van de 289 nam ongecom- primeerd 3MB (Megabyte) in beslag en werd verwijderd omdat het te groot was. BigchainDB bleek zelfs zijn gecomprimeerde grootte niet te accepteren. De andere bestanden hadden elk een ongecomprimeerde grootte van 2 bytes tot 1.6MB. Deze bestanden samen namen 9.03MB in beslag. Tendermint slaat de blockchain bestanden standaard op onder de /.tendermint/data

folder in de thuismap van de knoop. Die worden opgeslagen onder .log bestanden. In dit ge- val was er ´e´en .log bestand aanwezig dat een grootte had van 2.39MB. Dit wil zeggen dat de compressie wel degelijk zijn effect heeft gehad. Er is ook geprobeerd geweest om deze bestanden allemaal zonder compressie te versturen naar de blockchain, echter gaf dit opnieuw het probleem dat de bestanden te groot zijn voor BigchainDB. Het gehele proces van de 288 bestanden naar de blockchain te sturen nam 4 minuten en 23 seconden in beslag. Het grootste deel van deze tijd is te wijten aan de individuele compressie van de bestanden.

Er was nu informatie aanwezig die aangeeft hoe de blockchain er uit ziet na 288 transacties. Op basis hiervan werd een benadering uitgevoerd van hoe groot de blockchain zou zijn als het dezelfde trend volgt als Bitcoin. Waarop voornamelijk de nadruk werd gelegd op de grootte en het aantal transacties. Er werd al in 2.4.1 vermeld dat bij Bitcoin blokken gemiddeld 1.07 megabyte groot zijn en elke blok gemiddeld meer dan 2000 transacties bevat [28]. Als 288 transacties al een grootte van 2.39MB hebben, dan zou dat voor 2000 transacties een grootte van 16.5MB zijn voor de herkomstinformatie blockchain. Bij Bitcoin wordt er elke tien minuten een blok gevonden, als deze trend wordt doorgetrokken naar onze herkomstinformatie blockchain wil dit zeggen dat er 99MB per uur aan nieuwe data binnenkomt. Dit komt neer op 2.37GB (Gigabyte) per dag. Zou een validator een jaar lang deze hoeveelheid data binnenkrijgen komt dat neer op 865GB aan data die de validator moet bijhouden. Hierbij werd ook nog geen rekening gehouden met de plaats die de MongoDB databank inneemt, waardoor het effectieve getal nog hoger zal liggen. Bij het schrijven van dit onderzoek bevatte de Bitcoin blockchain 270GB aan data en die is al actief sinds 2009. Uiteraard is dit een vrij eenvoudige benadering. Op basis van slechts 288 transacties kunnen er geen realistische conclusies gedefinieerd worden. Wel kan worden gesteld dat de transacties gemiddeld groter zijn dan bij Bitcoin. Met een groei gelijkaardig aan Bitcoin zou dit willen zeggen dat de validators die meewerken aan het netwerk veel ruimte zouden moeten reserveren voor de blockchain, wat niet positief is.

De twee bestanden die geen herkomstinformatie bevatte en niet via de applicatie werden verstuurd maar wel rechtstreeks naar BigchainDB gaven geen problemen. Wat opnieuw niet positief is. Dit heeft ervoor gezorgd dat de blockchain nu niet enkel herkomstinformatie bevat maar ook non-herkomstinformatie en non-RDF data. Data die eigenlijk, geen nut heeft in deze herkomstinformatie blockchain. Het is duidelijk dat deze implementatie niet klaar is voor verdere evaluatie en nog moet bijgeschaafd worden. In het volgende deel worden de problemen met deze implementatie overlopen.

Een link naar de repository voor de bijhorende code en documentatie van dit experiment is te vinden in appendix B.

3.5

Discussie

Een eerste probleem is dat de blockchain transacties, op basis van de resultaten uit het ex- periment, gemiddeld groter zijn dan de transacties bij de crypto valuta. Dit kan negatieve gevolgen hebben voor de schaalbaarheid in de toekomst. De blockchain is immers onveran- derlijk, kan enkel maar groter worden en de validators moeten steeds een volledige kopie van deze blockchain bijhouden. Het gebruik van compressie helpt al heel wat om de hoeveel- heid gebruikte data te verminderen maar blijkt nog steeds niet voldoende. Het valt moeilijk te voorspellen hoeveel zo een herkomstinformatie blockchain zou gebruikt worden. Het is belangrijk dat de blockchain zich hier preventief tegen opstelt, iets wat deze implementatie duidelijk mist.

Het eerste probleem hangt ook nauw samen met een volgend probleem dat voorkomt. Het is onwaarschijnlijk dat in de herkomstinformatie bestanden die werden opgehaald van Prov Store geen duplicate of slecht geformatteerde herkomstinformatie bestanden zitten. Er wordt slechts door PROV Python bij de applicatie voor de gebruiker een kleine controle gedaan. Daarbij wordt gekeken of alle correcte @prefix triplets aanwezig zijn en of het wel een vorm van RDF data is. Er is echter geen validatie op het feit dat het wel degelijk om herkomstinformatie of zelfs om correcte herkomstinformatie gaat. De gewone RDF data en zelfs de willekeurige JSON string konden zonder problemen worden opgeslagen op de blockchain. Iets wat niet zou mogen aangezien de blockchain enkel herkomstinformatie zou mogen bevatten. Deze slechte data verwijderen zou wel (deels) mogelijk zijn door een alternatieve blokketen te starten vanaf een blok die v`o`or de slechte data ligt, maar dat zou niet praktisch als dit te frequent moet gebeuren.

Daarnaast voert BigchainDB geen enkele controle uit op het feit of het hier om herkomstinfor- matie gaat of niet. Zolang er data wordt verstuurd die niet te groot is, accepteert BigchainDB dit. Er kan niet worden vanuit gegaan dat de gebruiker altijd de voorziene applicatie gebruikt. Er kan nog steeds voor gekozen worden om rechtstreeks de data te versturen naar de Big- chainDB API endpoint. Dit zorgt er voor dat gebruikers eender welke data kunnen versturen naar de blockchain. Dit kan negatieve gevolgen hebben op het nut en de werking van de blockchain. Er wordt dan een soort van “vervuilde” blockchain verkregen die data bevat waarvoor het niet bedoelt was. Al deze extra en onbruikbare data neemt plaats in en zorgt ervoor dat de blockchain sneller gaat groeien waardoor deze niet schaalbaar is. BigchainDB was een goede optie om een eerste implementatie mee te doen, echter is het niet volledig geschikt voor wat de voorgestelde oplossing tracht te bereiken. Namelijk een blockchain die enkel uit herkomstinformatie bestaat.

Deze eerste implementatie geeft de mogelijkheid om herkomstinformatie in een blockchain op te slaan. Maar heeft geen vorm van beveiliging tegen slechte data. Onder slechte data kan

onder andere het volgende worden verstaan: ˆ Data die geen herkomstinformatie is.

ˆ Herkomstinformatie die al voorkomt in de blockchain.

ˆ Herkomstinformatie die niet de juiste regels volgt van de PROV specificaties. ˆ Herkomstinformatie die URI’s bevat naar malafide locaties.

Herkomstinformatie draait net om kwaliteit en vertrouwen geven aan data. Als de blockchain zelf niet te vertrouwen is en mogelijk slechte data bevat, heeft een blockchain voor herkom- stinformatie weinig zin. Deze eerste implementatie maakt onze probleemstelling duidelijker en toonde aan waarom verder onderzoek nodig was. Er is nood aan een verbeterde imple- mentatie die rekening houdt met het feit dat niet elke gebruiker of knoop te vertrouwen is binnen het netwerk. Een drijfveer die er voor zorgt dat de knopen binnen het netwerk zich aan de regels houden waardoor de blockchain niet vervuild wordt met data die niet nuttig is. De blockchain zal groeien, sneller dan de blockchain van een crypto valuta als het even actief zou zijn als zo een blockchain, dit probleem is niet te omzeilen. Daarom is het net belangrijk dat de blockchain zich hier preventief voor op stelt om dit probleem zoveel mogelijk in te perken. Zo kan ervoor gezorgd worden dat de blockchain meer schaalbaar is en nog steeds de principes en het nut van herkomstinformatie bezit.

Om de problemen op te lossen die de eerste implementatie in het vooronderzoek heeft aange- kaart werd een oplossing bedacht in 4.1 die deze tekortkomingen zou kunnen oplossen. Deze oplossing werd ge¨ımplementeerd en wordt beschreven in 4.2. Tot slot werd, net zoals onze eerste implementatie, deze verbeterde versie ge¨evalueerd. In 4.3 worden alle experimenten en hun resultaten beschreven die werden uitgevoerd op dit systeem.

4.1

Voorgestelde oplossing

In dit deel wordt een oplossing voorgesteld voor de problemen in het voorgaande stuk. Deze is onafhankelijk van een specifieke technologie, echter werd er wel inspiratie gehaald uit de werking van Tendermint. Om ervoor te zorgen dat de blockchain zo min mogelijk slechte data bevat moesten er meerdere aspecten worden aangepast tegenover de eerste implementatie. Een goed startpunt hiervoor was door te kijken naar hoe andere blockchains ervoor zorgen dat er geen foute blokken op het netwerk terechtkomen. Zo werd er in dit onderzoek gekeken naar Ethereum Casper [44]. Dit is het Proof-of-Stake consensus dat zal gebruikt worden in de toekomstige versies van Ethereum. Momenteel gebruikt Ethereum immers nog Proof-of-Work [45]. Ethereum casper werkt als volgt:

ˆ Een knoop kan meedoen aan het netwerk en een validator worden door een bepaalde hoeveelheid Ethereum te storten, deze hoeveelheid wordt de deposit genoemd. De knoop heeft dan een inzet (stake) in het netwerk.

ˆ Voor blokken toe te voegen aan de blockchain wordt er steeds een nieuwe validator gekozen voor elke nieuwe blok, de voorsteller. Die kan dan een volgende blok kiezen en dit voorstellen aan het netwerk.

ˆ Alle andere validators kijken deze blok na en indien de validators die minstens 2/3 van de totale ingezette Ethereum beheren van het netwerk een stem uitvoeren (validatie die ok is) op de blok, dan wordt deze blok toegevoegd.

ˆ Validators die zich niet aan de regels houden en malafide activiteiten uitvoeren worden afgestraft met een slash. Dit is een deel van hun inzet die wordt afgenomen, waardoor ze Ethereum (lees, echt geld) verliezen.

Een verschil dat bij onze blockchain niet aanwezig is, is uiteraard een valuta. Toch blijft Ethereum Casper een goede inspiratiebron. Daar worden knopen die zich niet aan de regels houden afgestraft door goed gedefinieerde regels, slashing condities genoemd. Die bepalen wat verboden is en waarvoor een knoop gestraft wordt. De stimulans (incentive) om geen foute praktijken uit te voeren is dat een deel van de inzet van een knoop zal ontnomen worden. Dit is een goed principe dat doorgetrokken werd naar onze voorgestelde oplossing om zo de kwaliteit en vertrouwen van de data beter te kunnen garanderen. Zo werden er regels opgesteld voor wat wel en wat niet mag opgeslagen worden in de blockchain en werd ook een virtuele waarde toegevoegd die de validators van het netwerk niet zomaar willen kwijtspelen. Dit is echter geen valuta die een financi¨ele waarde heeft, kan enkel worden bekomen door een validator en is niet-overdraagbaar naar andere validators.

4.1.1 Validatie en geloofwaardigheid

Er moet eerst voor gezorgd worden dat alle data die binnenkomt kan gevalideerd worden voordat het verspreid wordt in het blockchain netwerk. Daarbij zal er nood zijn aan een reeks van validatie regels waarmee een knoop de data die hij binnenkrijgt kan valideren. Vanaf nu zal een knoop genoemd worden als validator omdat dit duidelijker aangeeft wat de knoop precies doet in het netwerk. Het zou slecht zijn om de validatie enkel langs de kant van de gebruiker te