Mogelijke scenario’s

In het huidige voorstel kunnen er meerdere scenario’s voorkomen die elk een mogelijk gevolg hebben (zie ook figuur 4.2):

ˆ Geldige herkomstinformatie ontvangen en deze voorstellen aan het netwerk: Geeft een positieve score.

ˆ Een positieve stem uitbrengen op een geldige blok: Geeft een positieve score

ˆ Ongeldige herkomstinformatie ontvangen en deze niet voorstellen aan het netwerk: Geeft geen positieve score, noch een straf.

ˆ Een positieve stem uitbrengen op een ongeldige blok waarbij meer dan 2/3 niet akkoord is: Indien dit een validator met de maximale score was, krijgt deze weer de startscore van het netwerk. Indien niet, wordt de validator verbannen.

ˆ Een ongeldige blok voorstellen aan het netwerk waarbij meer dan 2/3 niet akkoord is: Indien dit een validator met de maximale score was, krijgt deze weer de startscore van het netwerk. Indien niet, wordt de validator verbannen.

Het is belangrijk om te weten dat een goede validator die goed geconfigureerd werd en de correcte implementatie gebruikt nooit onbewust foute data kan sturen naar het netwerk, ten- zij het echt om een zeldzame computerfout gaat. Als een validator de juiste implementatie toepast waarbij de juiste validatie regels worden gevolgd, die ook alle andere validators toe- passen binnen het netwerk, dan is het onmogelijk om slechte data voor te stellen aan het netwerk en daardoor ongewild een straf te verkrijgen. Het is enkel als een validator bewust negatieve data voorstelt dat dit een straf kan opleveren. Er kan immers niet gecontroleerd worden of de validator wel de juiste implementatie gebruikt. Een validator zou zelf zijn eigen implementatie kunnen maken die andere validatie regels volgt waarmee mogelijks slechte data naar het netwerk kan verstuurd worden. In andere woorden, een implementatie die de slechte

Figuur 4.2: De mogelijke scenario’s bij de voorgestelde oplossing

data niet tegenhoudt. Slechte data versturen is enkel mogelijk als er een andere implementatie wordt gebruikt die niet de juiste validatie regels van die blokketen toepast. Validators die correct meewerken aan het netwerk zullen daarom nooit afgestraft worden.

Het nut van deze geloofswaardigheidsscore kan door sommigen betwist worden. Het is louter een getal en heeft geen financi¨ele waarde. Hetgeen wat deze score wil cre¨eren is immers een waarde die men niet zomaar wil kwijtspelen. Toch is het doel van deze score dat het op lange termijn wel een waarde krijgt. Bij onze herkomstinformatie blockchain kan het zijn dat gebruikers net deze score als een reden zien om hun data er wel of niet naar te versturen. Er wordt verwacht dat een hoge score meer vertrouwen geeft aan de gebruikers en daarom ook meer vertrouwen aan de herkomstinformatie die er ondergebracht is. Daarnaast verstrijkt er een bepaalde tijdsperiode voordat een hoge score is verkregen door de validators. Hierdoor wordt ook verwacht dat de validators een extra waarde aan de score hechten omdat het niet eenvoudig is om deze te verkrijgen. Door een waarde te cre¨eren op de score wordt ervoor gezorgd dat goed gedrag wordt gestimuleerd en zo heeft het dus wel zijn nut.

In dit hoofdstuk werd er een voorgestelde oplossing aangetoond die een stimulans geeft aan de validators om enkel blokken die voldoen aan de validatie regels voor te stellen aan het netwerk. Validators die dit niet doen worden afgestraft en uiteindelijk verbannen uit het netwerk. Door dit toe te passen wordt verwacht dat de blockchain niet zomaar vervuild wordt met slechte data waardoor deze minder snel zal groeien en meer schaalbaar zal zijn naargelang de blockchain groeit. Dit zorgt er voor dat de herkomstinformatie blockchain beter kan vertrouwt worden en de doelstellingen van herkomstinformatie niet verwerpt.

4.2

Verbeterde implementatie

Met de voorgestelde oplossing werd in het onderzoek op basis van Tendermint een verbeterde implementatie gebouwd waarvan de architectuur wordt beschreven in 4.2.1. Er werden enkele validatie regels opgesteld die rekening houden met de voornaamste oorzaken waardoor een blockchain slechte herkomstinformatie zou kunnen bevatten. Deze validatieregels worden in 4.2.2 opgesomd. Daarnaast wordt ook de effectieve score die een validator kan verkrijgen of verliezen vermeldt in 4.2.3. Vervolgens wordt in 4.2.4 de bijhorende functionaliteiten van de implementatie besproken. Tot slot worden de beperkingen tegenover de voorgestelde oplossing die Tendermint met zich meebracht besproken in 4.2.5

4.2.1 Architectuur

In tegenstelling tot de eerste implementatie wordt er geen gebruik meer gemaakt van Big- chainDB. Er werd een eigen Tendermint applicatie ontworpen net zoals BigchainDB een ap- plicatie is bovenop Tendermint. Daarnaast werd, in tegenstelling tot de eerste implementatie, de validatie in deze verbeterde implementatie niet enkel meer op de front-end gedaan. Dit was immers ´e´en van de aangekaarte problemen die de eerste implementatie had. Door die verantwoordelijkheid te verschuiven van de vele gebruikers naar de weinige validators wordt ervoor gezorgd dat met dit proces minder geknoeid kan worden.

Er werd ook bewust geen gebruik meer gemaakt van compressie. In de initi¨ele versie werden de bestanden gecomprimeerd door de applicatie van de gebruiker en er moest dus geen extra werk uitgevoerd worden door de knoop op het netwerk. Echter, zoals aangehaald in de pro- blemen van de eerste implementatie in 3.5, kan er niet op vertrouwd worden dat de gebruiker steeds de verwachte data verstuurd en kan er daarom ook niet verwacht worden dat er steeds gecomprimeerde data wordt verstuurd. Daarnaast zou het decomprimeren om de data te vali- deren een te grote last zijn voor een validator. Ook indien de validator de compressie voorziet (en niet de gebruiker) is dit nog steeds processor tijd die moet voorzien worden. Dit is iets wat de consensus enorm kan vertragen en zo het volledige netwerk vertraagd. Het gebruiken van compressie is dan net een zwakte zijn, in de plaats van een sterkte. Dit wordt nog verder besproken in 5.1.

De front-end applicatie werd ge¨ımplementeerd met behulp van React [46] en dient voorname- lijk als communicatiemiddel met de blockchain interface. Die wordt, samen met de consensus, door Tendermint gerealiseerd. Opnieuw is er, zoals in de initi¨ele implementatie, een block- chain applicatie die zich op de knoop bevindt. Deze applicatie werd gebouwd in Java [47] en implementeert de in 3.2.2 aangehaalde methodes waardoor Tendermint via de ABCI kan communiceren met de Applicatie. Deze Java applicatie wordt verder steeds de ABCI applica- tie genoemd om verwarring te vermijden. Het is deze ABCI applicatie die de applicatie staat

bevat en hetgeen wat doorheen de blockchain wordt gerepliceerd. De ABCI applicatie voert dan de nodige methodes uit om de aanpassingen door te voeren en ook de data toe te voegen aan de lokale databank.

Net zoals bij BigchainDB wordt deze data zowel in de blockchain als in een aparte databank opgeslagen. Dit maakt het mogelijk om query’s uit te voeren op de blockchain data. In dit geval werd gekozen voor een key:value (sleutel:waarde) store genaamd JetBrains Xodus [48]. Dit is een eenvoudige database die een stuk data kan opslaan onder een bepaalde sleutel. In deze implementatie werd de SHA-256 hashwaarde van de herkomstinformatie als waarde van de sleutel gekozen. Dit is een unieke reeks van tekens en doordat deze steeds dezelfde uitvoer heeft voor dezelfde invoer, kan duplicate data vermeden worden. Sleutels mogen namelijk bij zo een key:value store slechts ´e´en maal voorkomen. De opslag zou in de plaats van een key:value store ook bijvoorbeeld een RDF opslag kunnen zijn waarmee SPARQL query’s mogelijk worden. De keuze om de implementatie toch slechts bij een key:value store te houden heeft voornamelijk te maken met het doel van de voorgestelde oplossing. De focus ligt op het afstraffen van slechte data en het belonen van goede data. Waar deze data precies wordt opgeslagen, is niet van belang. Het model van deze verbeterde implementatie is te zien op figuur 4.3.

Figuur 4.3: Het model van de verbeterde implementatie met Tendermint

4.2.2 Validatie

De validatie van de data gebeurt in twee methodes bij Tendermint: de CheckTx en de Deli- verTx methode. Deze gaat na of de data goed of slecht is. Voor deze implementatie werden de volgende validatieregels ge¨ımplementeerd:

2. Transacties die niet geformatteerd zijn volgens de regels (zie 4.2.4.1) worden niet aan- vaard.

3. De data moet RDF data zijn. Dit wordt geverifieerd door RDF4J [49]. Een software bibliotheek die het inlezen van RDF data voorziet. Zou deze bibliotheek bij de parser een fout geven, dan wil dat zeggen dat de transactie geen syntactisch correcte RDF data is.

4. Enkel de Turtle syntax wordt toegelaten in de blockchain. Het is aan de front-end applicatie om andere RDF formaten om te zetten naar Turtle. De reden dat enkel Turtle wordt toegelaten, is dat transacties niet meer door Tendermint zelf kunnen worden aangepast. De CheckTx kan ze enkel tegenhouden, niet aanpassen. Dit wordt in 4.2.5 verder besproken.

5. De SHA-256 gehashte waarde van de verstuurde data, mag zich niet in de key:value store bevinden. Dit zorgt ervoor dat twee identieke herkomstinformatie bestanden niet in de blockchain kunnen worden opgeslagen. Daarnaast heeft Tendermint een cache die ervoor zorgt dat duplicate transacties niet meer dan ´e´en maal in een korte periode kunnen verstuurd worden. Zo is er een dubbele bescherming aanwezig die duplicate data tegengaat.

6. Om bepaalde regels van het PROV model na te kijken wordt er gebruik gemaakt van SHACL [17]. Hiermee kunnen mogelijke fouten in de transacties die herkomstinformatie bevatten herkend worden. SHACL werd gekozen om zijn eenvoud, in tegenstelling tot hardgecodeerde regels die meer tijd zouden gekost hebben om te implementeren. De gebruikte SHACL regels voor deze implementatie zijn te zien in de bijlage A.1. Deze regels zijn niet meer dan het PROV-O model en kunnen aangepast worden door het shacl rules.ttl bestand in de implementatie aan te passen. Als de SHACL validatie een fout geeft, dan is het slechte data.

7. Bij het toevoegen van een nieuwe validator moet het om een geldige publieke sleutel gaan. Elke validator wordt immers ge¨ıdentificeerd door deze publieke sleutel. Daarnaast mag deze validator niet verbannen zijn uit het netwerk of zich niet al bij het netwerk hebben aangesloten.

8. Bij elke transactie hoort een handtekening en publieke sleutel. De handtekening is gebaseerd op de Base64 gecodeerde versie van de herkomstinformatie in de transactie. Door middel van de publieke sleutel kan die handtekening worden geverifieerd en is ook het eigendom van de data verbonden aan een publieke sleutel. Deze handtekening moet uiteraard kloppen. Opmerking: Dit is een andere sleutel dan de publieke sleutel van een validator en moet door de gebruiker zelf aangemaakt worden.

9. De grootte van herkomstinformatie bestanden blijven beperkt tot de standaard waarde die Tendermint opgeeft namelijk 1.048576MB. De keuze hiervoor was omdat Tendermint nog te instabiel bleek bij bestanden die groter waren, dit wordt nog verder verduidelijkt in 4.3. In de praktijk ligt deze maximale waarde iets lager door de Base64 codering die gebruikt wordt bij het versturen van transacties. Base64 gebruikt immers zes bits voor een byte, maar het computersysteem ziet die byte nog steeds als acht bits [27]. Daarom zullen er veel nul bits zijn die extra plaats innemen. De werkelijke maximale waarde is dan ongeveer 788KB zonder codering en 1.048576MB met codering.

Met deze regels wordt er een minimale validatie gerealiseerd. Dit is een goed startpunt voor mogelijks andere implementaties die deze regels kunnen uitbreiden (of afschaffen). Zo toont het al de effectiviteit van enkele eenvoudige validatie regels. Het is belangrijk dat elke (goede) validator deze regels exact volgt. Een afwijking hiervan kan ervoor zorgen dat de validator wordt gezien als een slechte validator. Dit kan eenvoudig worden gerealiseerd door een exacte kopie van de implementatie te gebruiken en geen aanpassingen hier meer aan door te voeren.

4.2.3 Geloofwaardigheidsscore

Het verwerven van geloofwaardigheidsscore werkt niet volledig op de manier als werd beschre- ven in de voorgestelde oplossing. Zo wordt er geen beloning of straf gegeven aan validators die in een ronde geen voorsteller zijn. De reden hiervoor wordt gegeven in 4.2.5. Bij deze implementatie zijn er om die redenen vier scenario’s voor een validator:

ˆ Een nieuwe validator: Ontvangt een start score van twintig. ˆ Een geldige blok voorstellen aan het netwerk: Een score van ´e´en.

ˆ Een ongeldige blok voorstellen aan het netwerk met een reeds verworven maximale score van vijftig: De score wordt weer op de start score van twintig gezet.

ˆ Een ongeldige blok voorstellen aan het netwerk waarbij nog geen maximale score werd verworven: De validator wordt verbannen uit het netwerk.

Een knoop die een nieuwe validator wordt op het netwerk zal steeds starten met een score van twintig. Dit is gedaan zodat er nog steeds dertig goede voorstellen moeten worden gedaan vooraleer de validator wordt gezien als een vertrouwde validator. Daarnaast werd de maximale score op vijftig ingesteld. Dit zorgt ervoor dat een goede validator niet te veel invloed krijgt over het netwerk en zo nieuwe validators nog steeds de kans krijgen om vertrouwen te winnen. De keuze van de opgenoemde scores werd voornamelijk gedaan omdat ze eenvoudig waren om uit te testen, het is niet bewezen of ze ook de meest optimale zijn.

Tendermint beschikt in zijn eigen implementatie ook over een waarde die elke validator krijgt. Deze score wordt in Tendermint stemkracht genoemd en heeft een grote invloed op wie de volgende voorsteller wordt van de validators. Het proces werkt als volgt:

ˆ Er wordt eerst bekeken wat het totale aantal stemkracht is in het netwerk. Stel dat er een validator A is met 50 stemkracht en een validator B met 20 stemkracht en beiden zijn validators van eenzelfde netwerk. Dan is de totale stemkracht 70.

ˆ De validator met de hoogste huidige stemkracht wordt gekozen als voorsteller. Zou dit gelijk zijn, dan valt Tendermint terug op de volgorde waarin de validators werden toegevoegd. Bij een netwerk met X aantal validators met elk een gelijke stemkracht zal elke validator exact ´e´en keer aanbod komen in X aantal rondes.

ˆ Als validator A een blok voorstelt dan wordt zijn stemkracht met de totale stemkracht van het netwerk (70) verlaagd. Deze validator heeft dan -20 stemkracht.

ˆ Elke nieuwe ronde wordt de originele stemkracht van de validator bij elke validator opgeteld. Voor validator A geeft dit een nieuwe stemkracht van 30 (-20 + 50) en voor validator B een nieuwe stemkracht van 40 (20 + 20).

ˆ Nu heeft validator B de grootste stemkracht en mag hij een blok voorstellen aan het netwerk. Opnieuw wordt zijn stemkracht verlaagd met het totale van het netwerk. Dit komt dan neer op een stemkracht van -30 voor validator B.

ˆ In de volgende ronde worden de stemkrachten weer verhoogd en geeft dit voor validator A een stemkracht van 80 en voor validator B ´e´en van -10.

ˆ Validator A heeft de meeste stemkracht en mag de blok voorstellen. Opnieuw verliest hij hierbij stemkracht maar dit keer komt dat neer op 10.

ˆ De volgende ronde wordt de originele stemkracht er weer bij opgeteld en krijgt validator A een stemkracht van 60 en validator B een stemkracht van 10. Validator A heeft nu een hogere stemkracht dan validator B, ondanks dat validator A de vorige ronde al een voorsteller was.

ˆ Validator A zal twee keer na mekaar een blok mogen voorstellen omdat hij opnieuw de hoogste stemkracht heeft. Dit geeft duidelijk aan dat stemkracht er voor zorgt dat een validator met meer stemkracht (lees, met meer geloofwaardigheidsscore) frequenter blokken mag voorstellen.

Door dit principe kan er vanuit worden gegaan dat de goede validators meer invloed hebben op het netwerk. Stel dat er een nieuwe validator op het netwerk komt en deze valt offline om een bepaalde reden, dan zal dit minder invloed hebben dan dat een goede validator met de maximale score offline zou vallen. Zoals eerder vermeldt moet voor een nieuwe blok toe te voegen aan de blockchain meer dan 2/3 van het netwerk ermee akkoord gaan. Meer dan 2/3 slaat dan op de groep van validators die meer dan 2/3 van de totale stemkracht (geloofwaar- digheidsscore) in het netwerk bezitten. Zou validator B in het voorgaande voorbeeld offline

vallen, dan bezit validator A nog steeds 71,4% van de totale geloofwaardigheidsscore in het netwerk. Zo zullen nieuwe blokken nog steeds verwerkt kunnen worden.

Als een validator zich initieel aanmeld bij het netwerk zal deze een lijst van alle validators en hun corresponderende score ontvangen. Dit afstraffen of score geven gebeurt daardoor steeds lokaal bij elke validator. Zo moeten er niet onnodig blokken worden rondgestuurd voor elke score die veranderd. Aangezien alle validators (in normale omstandigheden) eenzelfde implementatie volgen, komt deze score steeds op hetzelfde neer.

4.2.4 Functionaliteiten

4.2.4.1 Transacties uitvoeren

Transacties en query’s kunnen verzonden worden vanuit de front-end naar de Tendermint server op een knoop. Uiteraard dient de front-end slechts als een eenvoudig alternatief voor niet-technische gebruikers. De Tendermint server kan ook rechtstreeks via zijn API endpoints worden aangesproken. Tendermint biedt 26 verschillende endpoints aan. Deze dienen voor onder andere: De status van de blockchain na te gaan, specifieke blokken te bekijken, trans- acties te versturen, query’s uit te voeren, ... De twee belangrijkste hiervan zijn transacties versturen en query’s uitvoeren. Deze worden daarom ook uitgebreider besproken.

Het versturen van transacties, met als inhoud herkomstinformatie, gebeurt door middel van de broadcast tx commit endpoint. Hier moet aan een parameter van de URI de transactie gecodeerd in Base64 worden toegevoegd. Deze parameter heeft een specifiek formaat zodat de blockchain dit verder kan verwerken. Elke transactie wordt getypeerd door een JSON object met het formaat vermeld in code voorbeeld 4.1

1 { 2 "format":"...", 3 "data":"...", 4 "pubkey":"...", 5 "signature":"..." 6 }

Code voorbeeld 4.1: Transactie JSON object

Het format stelt het type transactie voor en data de bijhorende Base64 gecodeerde inhoud van de transactie. Pubkey en signature zijn bedoelt om de handtekening validatie (vermeldt in 4.2.2) te kunnen uitvoeren. Onze implementatie ondersteund twee formaten: “ttl” en “ne- wval”. Deze dienen respectievelijk voor herkomstinformatie te versturen en nieuwe validators toe te voegen.

Herkomstinformatie versturen

Het formaat “ttl” stelt een Turtle transactie van herkomstinformatie voor. De implementatie ondersteunt alleen Turtle waardoor dit overbodig lijkt. Echter is dit voornamelijk zo gedaan

zodat er in de toekomst eenvoudig aanpassingen kunnen gemaakt worden waarmee moge- lijks wel, langs de kant van de blockchain, meerdere formaten kunnen ondersteund worden. Stel dat er een kleine hoeveelheid herkomstinformatie (getoond in code voorbeeld 4.2) wordt verstuurd naar de blockchain. Hiervoor wordt eerst een nieuw JSON object aangemaakt met als formaat “ttl”. Het dataveld moet Base64 gecodeerde informatie bevatten en daarom moet de herkomstinformatie gecodeerd worden in Base64. Hierop moet dan een handtekening berekend worden met een sleutelpaar. Het formaat, de Base64 gecodeerde versie van de her- komstinformatie, de publieke sleutel en de handtekening moeten dan aan het object worden toegevoegd. Dit geeft dan het opgevulde JSON object getoond in code voorbeeld 4.3. Het JSON object moet ook in Base64 gecodeerd worden en wordt dan aan de URI toegevoegd zodat het een volwaardig verzoek is voor de blockchain. Dit geeft dan het uiteindelijke re- sultaat getoond in code voorbeeld 4.4. Als deze URI wordt uitgevoerd dan zal de transactie