Door deze antwoorden was het mogelijk om in de experimenten op een eenvoudige manier te filteren welke transacties gelukt zijn en welke niet. Zo werden de scripts steeds gebaseerd op de codes die werden teruggegeven. De codes in de huidige implementatie zijn als volgt:
code 0: De validatie is ok.
code 1: Het verzoek is niet in het JSON formaat. code 2: Geen formaat opgegeven.
code 3: Geen data opgegeven.
code 4: Geen publieke sleutel opgegeven. code 5: Geen handtekening opgegeven.
code 6: De opgegeven handtekening is foutief. code 7: Ongeldige publieke sleutel van de validator. code 8: Validator bevindt zich al in het netwerk.
code 9: De opgegeven data is geen syntactisch correcte RDF data. code 10: Data bevindt zich al in de blockchain.
code 11: SHACL validatie is niet ok. code 12: Niet ondersteund formaat.
code 13: Validator is verbannen uit het netwerk en kan niet opnieuw worden toegevoegd. code 100: Interne fout.
4.2.4.4 Inactieve validators
Standaard zou bij Tendermint een validator offline kunnen zijn voor altijd, zonder dat dit wordt aangepast in het netwerk. Stel dat een validator al zijn lokale data verliest en daardoor ook zijn private sleutel kwijt is waarmee hij zichzelf kon identificeren als een specifieke vali- dator, dan wil dat zeggen dat deze nooit meer uit de lijst van validators zou worden gehaald. Dat bijvoorbeeld ´e´en validator voor altijd offline is in een netwerk van een tiental validators, zou in principe geen probleem zijn. Zolang meer dan 2/3 van het netwerk meewerkt, kunnen de transacties worden verwerkt. Echter kan dit zich blijven opstapelen waardoor er een punt
komt wanneer niet meer dan 2/3 van het netwerk online is. Dit zou ervoor zorgen dat het netwerk plat ligt en daardoor een fork nodig is.
Dit is eenvoudig te vermijden door inactieve validators te verwijderen. Via Tendermint kan worden bekeken welke validators een stem op een blok hebben uitgebracht. Een validator die offline is, kan dat uiteraard niet. Door te kijken welke validators dit niet doen kan er worden gezien welke offline zijn of welke gewoonweg niet meewerken aan het netwerk. Een inactieve validator is een validator die voor een bepaalde periode geen stemmen uitbrengt op een blok. Deze periode defini¨eren in tijdseenheden zou een mogelijkheid kunnen zijn. Dat zou echter een synchronisatie tussen alle klokken van de validators vereisen wat een vrij complexe oplossing is. Daarnaast kan het ook perfect zijn dat er voor een bepaalde tijdperiode geen transacties binnenkomen wat dan ervoor kan zorgen dat elke validator wordt verwijderd. Een beter alternatief is door de periode te defini¨eren als het aantal blokken waarop geen stem werd uitgebracht. Dit is niet alleen eerlijker maar ook eenvoudiger om te implementeren. Echter is een goede waarde vinden voor het aantal blokken niet eenvoudig. In drukkere netwerken (gemiddeld meer transacties per uur) is een hogere waarde beter. In minder drukke netwerken (gemiddeld minder transacties per uur) zou een lagere waarde beter zijn. Dit is iets wat enkel in de praktijk kan ondervonden worden en moet mogelijks naargelang het verloop van het netwerk dynamisch kunnen worden bijgeschaafd. In 5.2 wordt dieper ingegaan op deze kwestie.
In deze implementatie werd er gekozen voor een inactiviteit op basis van het aantal blokken dat een validator achtereenvolgens geen stem op heeft uitgebracht. Concreter dat als een validator na vijf opeenvolgende blokken nog steeds geen stem heeft uitgebracht dat deze verwijderd wordt uit het netwerk. Dit is een waarde, kort genoeg zodat dit snel kan uitgetest worden en lang genoeg zodat een validator niet direct wordt verwijderd uit het netwerk. 4.2.4.5 Lijst van verbannen validators
Door de functionaliteit uit 4.2.4.4 waarbij een inactieve validator verwijderd wordt na een bepaalde periode, moet er een verschil worden gemaakt tussen permanente en tijdelijke ver- banning. Een goede validator kan immers perfect een tijdelijke storing hebben en zou hiervoor niet mogen gestraft worden. Toch is de validator verwijderen de beste oplossing aangezien dat de validator ook niet bijdraagt aan de werking van de blockchain zolang hij offline is. Als die validator opnieuw werkt, kan die zichzelf terug toevoegen. De goede validator werd slechts tijdelijk verwijderd. Een slechte validator die slechte data heeft verstuurd kan dit niet, die werd permanent verwijderd. De slechte validator wordt namelijk toegevoegd aan een zwarte lijst die alle verbannen validators bevat. Dit zorgt ervoor dat goede validators die tijdelijk uitvallen niet nodeloos afgestraft worden.
al bevat, een lijst met alle validators in het netwerk. Echter is deze extra lijst bedoeld om de validators te vermelden die verbannen zijn. Aangezien elke validator in normale omstan- digheden dezelfde implementatie heeft, zal deze lijst doorheen het netwerk identiek zijn. Zou een validator toch een validator verbannen die niet verbannen zou moeten zijn, dan zou dit op een bepaald punt ervoor zorgen dat deze validator niet tot een consistente staat komt. Een blok vermeldt immers steeds de volgende voorsteller. Als dat een verbannen validator is, staat die niet in de lijst van validators in het netwerk. Daardoor zal die ook niet als volgende voorsteller aanbod komen in zijn eigen berekeningen van de blok en faalt het consensus bij die validator. Zolang de goede implementatie wordt gebruikt kan dit probleem echter niet voorkomen.
Als een nieuwe validator wordt toegevoegd wordt eerst bekeken of de validator zich bevindt op de lijst met verbannen validators. Is dit zo, dan wordt de validator niet toegelaten. Is dit niet zo, dan wordt deze uiteraard wel toegelaten. Dit zorgt ervoor dat goede validators met een tijdelijke storing zich zonder problemen opnieuw bij het netwerk kunnen aansluiten. Toch kan het zijn dat een validator met frequente storingen, niet noodzakelijk een goede validator is. Een slechte validator kan bijvoorbeeld steeds offline vallen en zichzelf steeds opnieuw toevoegen aan het netwerk om zo toch het netwerk deels te kunnen plat krijgen. Frequent offline vallen zou bijvoorbeeld ook een mogelijk slecht gedrag zijn. Een mogelijke oplossing op dit probleem wordt verder besproken in 5.2.
4.2.5 Beperkingen van Tendermint
Zoals in de vorige delen al aangehaald werd, zijn sommige functionaliteiten anders ge¨ımplementeerd omwille van de beperkingen van Tendermint. Deze beperkingen hebben uiteraard enkel be- trekking tot dit onderzoek en kunnen in een andere context net geen beperking vormen. Dit is een kort overzicht van wat anders is ten opzichte van de voorgestelde oplossing:
1. Validators die geen voorstellers zijn in een ronde worden niet beloond of gestraft. Bij Tendermint worden er stemmen uitgebracht op blokken, maar de uitkomst van deze stem heeft niks te maken met de validatie regels die de ABCI applicatie opstelt. Dit heeft wel te maken met Tendermint specifieke processen zoals het valideren van de blok hoofding. Een positieve stem uitbrengen op een blok heeft niks te maken met de inhoud van de blok. Het is enkel door in de DeliverTx methode de transactie te valideren dat er kan gezien worden dat de voorgestelde blok slecht was. Maar zelfs door goede validators zou er nog steeds een positieve stem zijn uitgebracht omdat de blok hoofding klopte. Daardoor kan een score of straf enkel gegeven worden aan de voorsteller die de blok voorstelde. Hij kon immers de transactie die de blok bevat wel al hebben tegengehouden in de CheckTx, wat niet gebeurt is als de blok al werd voorgesteld. Om
deze reden kan een validator die geen voorsteller is in een ronde niet beloond, noch gestraft worden als hij een positieve stem uitbrengt op een goede of slechte blok. 2. In de implementatie wordt enkel herkomstinformatie in Turtle toegelaten. Tendermint
laat niet toe dat de inhoud van de transacties nog mag worden aangepast. Om een zekere eenheid te verzekeren, wordt enkel het Turtle formaat toegelaten.
3. Een score van nul is geen mogelijkheid bij Tendermint. Een score van nul wil zeggen dat de validator niet bij het netwerk hoort. Daarom moet de minimale score om bij het netwerk te mogen horen in deze implementatie steeds gelijk zijn aan ´e´en.
4. Veel delen van de antwoorden van de server worden automatisch door Tendermint ge- codeerd in Base64. Dit is onvermijdelijk. In de front-end applicatie worden deze wel automatisch omgezet.
5. Als de voorsteller een blok met slechte data verstuurt, dan zal deze blok nog steeds in de blockchain terechtkomen. Het is aan de ABCI applicatie om dit verder af te handelen. Dit is niet wat deze implementatie als doel had, dat was net deze slechte data vermijden. Door de validator die deze slechte data heeft verstuurd direct te verwijderen wordt uiteraard wel vermeden dat diezelfde validator nog meer slechte data kan versturen. In 5.2 wordt nog verder op deze beperkingen en hun mogelijke oplossingen ingegaan.
4.3
Evaluatie
Op deze verbeterde implementatie werd een reeks van experimenten uitgevoerd. De opzet is grotendeels hetzelfde voor elk experiment. Bij elk van deze experimenten is een netwerk aanwezig met tien tot twintig validators (of zullen nog toegevoegd worden) die zich op het- zelfde blockchain netwerk bevinden. Echter zal op bepaalde aspecten de uitvoering ervan verschillen. In 4.2.3 werden enkele mogelijke scenario’s aangehaald die kunnen voorkomen bij de implementatie. Op basis daarvan werden volgende experimenten gedefinieerd:
1. Geldige herkomstinformatie wordt ontvangen door een goede validator. 2. Ongeldige herkomstinformatie wordt ontvangen door een goede validator.
3. Ongeldige herkomstinformatie wordt ontvangen door een slechte validator waarbij meer dan 2/3 van het netwerk een goede validator is.
4. Een blok wordt voorgesteld aan het netwerk waarbij meer dan 2/3 van de validators online zijn en de andere offline.
5. Een blok wordt voorgesteld aan het netwerk waarbij minder dan 2/3 van de validators online zijn en de andere offline.
6. Er wordt een reeks nieuwe goedaardige validators aan het netwerk toegevoegd, gevolgd door een reeks goede transacties.
7. Er wordt een reeks nieuwe kwaadaardige validators aan het netwerk toegevoegd waar- door de nieuwe validators een meerderheid van 2/3 bezitten van het netwerk. Dit wordt gevolgd door een reeks slechte transacties.
8. Een groot aantal grote transacties wordt verstuurd naar een goede validator.
9. Er wordt een reeks van slechte herkomstinformatie verstuurd naar een goedaardig net- werk die steeds ´e´en van de validatie regels overtreedt.
10. Identieke herkomstinformatie bestanden worden verstuurd naar het netwerk zoals in het eerste experiment van de initi¨ele implementatie.
Experiment ´e´en, twee, drie en zes zijn bedoeld om het essenti¨ele van de blockchain uit te testen. Het is belangrijk dat deze vier slagen om te kunnen bewijzen dat de blockchain onder de meest normale omstandigheden werkt. Experiment vier en vijf zijn bedoelt om te kijken hoe Tendermint reageert op een netwerk dat deels niet werkt. Zo wordt er een beter beeld verkregen van wat de mogelijke gevolgen hiervan zijn. Experiment zeven heeft als doel om een mogelijk scenario uit te testen waarbij een aanval wordt gelanceerd op het netwerk. Hiermee kan worden bekeken in welke staat de blockchain zich na die aanval bevindt. Experiment acht heeft als doel om mogelijke problemen met het verwerken van grote transacties (transacties met veel herkomstinformatie) aan te tonen. Experiment negen is bedoeld om elke validatie regel van het netwerk uit te testen om zeker te zijn dat elk zijn effect heeft. Tot slot heeft experiment tien het doel om de grootte en de effectiviteit van de validatie regels te vergelijken met de blockchain uit het eerste experiment 3.4.
Door al deze experimenten uit te voeren wordt er een goed beeld gegeven over de capaciteiten van de huidige implementatie en waar er mogelijks nog tekortkomingen zijn.
4.3.1 Opzet
Zoals eerder vermeldt wordt steeds getracht een netwerk te hebben van tien tot twintig valida- tors. Elke validator heeft bij het begin van het experiment een gelijke hoeveelheid stemkracht, echter kan deze hoeveelheid stemkracht wel veranderen als er transacties worden verstuurd. Deze validators zijn niet noodzakelijk aanwezig aan het begin van het experiment maar kun- nen ook naargelang de uitvoering ervan toegevoegd worden, afhankelijk van het experiment. Elk van de experimenten werd uitgevoerd in een Docker [50] omgeving. Hiermee kan een eigen bestandssysteem worden opgezet die afgesloten is en volledig zelfstandig werkt. Dit wordt in Docker termen een container genoemd. Op deze manier is het mogelijk om op een eenvoudige manier een reeks validators te verbinden aan eenzelfde test netwerk. Dit gaf maxi- maal veertig containers voor elk experiment. Hierbij vertegenwoordigde elke validator twee
van die containers. ´E´en daarvan was de ABCI applicatie en de andere de Tendermint server. Elke Tendermint server moet zijn eigen ABCI applicatie bezitten. Het is niet mogelijk dat meerdere Tendermint servers gebruik maken van dezelfde applicatie. In principe is het ook niet nodig dat beiden op een aparte container draaien. Het is perfect mogelijk dat bij een echte validator (in een echt netwerk) de ABCI applicatie en de Tendermint server op dezelfde machine (op hetzelfde bestandssysteem) draaien. Echter was het in een test omgeving prak- tischer om deze af te scheiden zodat mogelijke storingen makkelijker te detecteren waren. De transacties werden ofwel manueel via de browser verstuurd of door een reeks van API verzoeken te versturen met een script.
In de experimenten komen regelmatig goede en slechte validators voor. Een goede validator volgt de in 4.2 beschreven implementatie terwijl een slechte validator een aangepaste versie hiervan volgt. De validatie van de slechte validator geeft steeds code 0 terug waardoor elke transactie, ook die met slechte data, geaccepteerd en verstuurd worden naar het netwerk door de slechte validator. Daarvoor is het uiteraard wel nodig dat de transacties ook expliciet worden verstuurd naar die slechte validator, anders zou de CheckTx methode ze bij de goede validators tegenhouden.
4.3.2 Uitvoering
Voor elk van deze experimenten werd eerst ´e´en herkomstinformatie bestand verstuurd. Daarna vijf opeenvolgende bestanden en tot slot nog eens honderd opeenvolgende bestanden. Afhan- kelijk van de aard van het experiment waren dit goede of slechte en kleine of grote bestanden. De kleine bestanden waren ongeveer 1KB (Kilobyte) terwijl de grotere rond de 470KB wa- ren. Voor sommige experimenten was het enkel nuttig om slechts ´e´en bestand te versturen. Deze bestanden bevatte herkomstinformatie en werden steeds door scripts gegenereerd met willekeurige data. Enkel voor het laatste experiment werden identieke bestanden van de Prov Store verstuurd zoals in het experiment van 3.4. Dit zodat de resultaten konden vergeleken worden.
Na elk experiment werd bijgehouden hoeveel transacties gelukt waren en hoeveel niet. Soms was het uiteraard de bedoeling dat de transacties niet lukte, dit is opnieuw afhankelijk van de aard van het experiment. Daarnaast werd ook bekeken of de blockchain een consistente staat had bereikt na ´e´en of meer transacties. Indien dit niet het geval was, werd steeds bekeken waarom dit zo was zodat hier mogelijke tekortkomingen van de implementatie uit gehaald konden worden. Tot slot werd ook een algemene conclusie geformuleerd die het experiment concludeerde.
4.3.3 Resultaten
Voor elk van de uitgevoerde experimenten worden de resultaten vermeldt met de volgende structuur:
Eigenschappen van het gebruikte netwerk. Werd er een consensus bereikt.
Algemeen resultaat.
Eventueel wordt ook nog aangegeven hoe lang de transacties duurden om aan te tonen dat dit niet onacceptabel lang heeft geduurd. Een kleine transactie die bijvoorbeeld langer dan vijf minuten zou duren om doorheen het netwerk te worden verspreid is uiteraard niet acceptabel. Echter is de transactie tijd zo laag mogelijk houden, niet het doel van dit onderzoek. Van elk experiment is er een bijhorende visuele voorstelling om de omstandigheden duidelijker weer te geven. Dit zijn voor de experimenten respectievelijk de figuren 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12 en 4.13.
1. Geldige herkomstinformatie wordt ontvangen door een goede validator. Bij deze proef werd een netwerk van twintig validators gebruikt die allen goedaardig waren. Hierbij ontving een goede validator goede herkomstinformatie. Zoals verwacht werd het con- sensus bereikt. Alle transacties werden gerepliceerd doorheen het netwerk en geen enkele validator gaf problemen. Ook bij vijf en honderd transacties na mekaar was alles stabiel en duurden transacties niet langer dan vijf seconden. Hiermee kan geconcludeerd worden dat in normale omstandigheden de implementatie werkt naar behoren.
Figuur 4.4: Visuele voorstelling van experiment ´e´en
2. Ongeldige herkomstinformatie wordt ontvangen door een goede validator. Bij deze proef werd een netwerk van twintig validators gebruikt die allen goedaardig waren. Hierbij ontving een goede validator slechte herkomstinformatie. Dit was steeds herkomstin- formatie die eenzelfde validatie regel overtrad. Dit test niet uit of alle validatie regels wel werken naar behoren. Zoals verwacht werd het consensus bereikt en werd alle slechte her- komstinformatie tegengehouden. Geen enkele transactie werd gerepliceerd in het netwerk.
Ook bij vijf en honderd transacties na mekaar gebeurde dit niet. Hiermee kan geconcludeerd worden dat in normale omstandigheden de implementatie werkt naar behoren en slechte data wordt tegengehouden door een goede validator.
Figuur 4.5: Visuele voorstelling van experiment twee
3. Ongeldige herkomstinformatie wordt ontvangen door een slechte validator waarbij meer dan 2/3 van het netwerk een goede validator is.
Bij deze proef werd een netwerk van twintig validators gebruikt waarvan er achttien goed- aardig en twee kwaadaardig waren. Hierbij ontving een slechte validator slechte herkomst- informatie. De kwaadaardige validator die de slechte data ontving en verstuurde naar het netwerk, werd uit het netwerk verbannen doordat de andere validators zagen dat deze slechte data wou verspreiden. De slechte data werd wel in het netwerk verstuurd (zoals aangehaald in 4.2.5) en opgenomen in de blockchain, maar ondertussen werd de kwaadaardige validator ook verbannen uit het netwerk. In dit experiment was het daarom niet nuttig om meer dan ´e´en opeenvolgende transactie te versturen. De andere kwaadaardige validator had een “consensus failure”. Dit wil zeggen dat volgens zijn implementatie geen consensus tot stand kon worden gebracht omdat meer dan 2/3 van de validators in het netwerk op een blok hebben gestemd die niet klopt. Hij gaf namelijk een code nul terwijl andere een niet-nul code gaven. Bij de berekening van de hash van die blok kwam dat niet overeen door de verschillende codes. Dit is echter een probleem door onze specifieke “slechte” implementatie. In een implementa- tie waarbij de Tendermint code zelf zou aangepast zijn en niet enkel een aangepaste ABCI applicatie werd ontwikkeld voor Tendermint, zouden malafide gebruikers deze fout bij het consensus kunnen uitschakelen.
4. Een blok wordt voorgesteld aan het netwerk waarbij meer dan 2/3 van de validators online zijn en de andere offline.
Bij deze proef werd een netwerk van achttien validators gebruikt die allen goedaardig waren. Hiervan werden vijf validators op voorhand uitgeschakeld zodat ze offline waren. Er werd een enkelvoudige transactie verstuurd en daarna een reeks van vijf en honderd opeenvolgende transacties. Elk van deze transacties werd doorgevoerd in het netwerk zonder problemen en zonder verlies van snelheid tegenover het eerste experiment. Er kan gesteld worden dat
Figuur 4.6: Visuele voorstelling van experiment drie
het netwerk ook met een deel van de validators offline perfect kan functioneren. Bij het