I denna sektion redovisas experimentets tillvägagångssätt.
Experimentet har som syfte att simulera ett industriellt scenario. Informatio-nen som överförs med hjälp av transaktioner består av en simulerad temperatur,
position samt klockslag för mjölken i en mjölktank. Detta för att säkra mjölkens färskhet från bondgård till mjölkpaket. Informationen sparas i blockkedjan och där-med säkras integriteten. Denna process kan i framtiden automatiseras av sensorer i tanken och automatiskt föras in i blockkedjan via transaktioner från noderna.
I experimentet används en PC med operativsystemet Linux virtualiserat och två Raspberry Pi Modell B+ som ansluts till ett privat nätverk. Raspberry Pi-enheterna har uppgraderats med senaste versionen av Raspbian OS, i detta expe-riment har Raspbian Stretch Lite Version 4.14 använts. Enheterna kommunicerar inom det slutna nätverket med hjälp av enheternas integrerade nätverkskort via nätverkskablar och sammankopplas med hjälp av en switch. IP-addresser delas ut till samtliga enheter med hjälp av routerns integrerade DHCP-server. För att kon-trollera en fungerande nätverkstopologi används verktyget ping för att verifiera att alla noder kan kommunicera med varandra.
Därefter laddas den senaste versionen av Go-Ethereum (geth) ner på samtliga enheter för implementering. Två mappar skapas på PCn, miner1 och miner2 genom kommando mkdir -p ~/Chainskills/miner1 och
mkdir -p ~/Chainskills/miner2, och mkdir -p ~/Chainskills/node1 samt mkdir -p ~/Chainskills/node2 på Raspberry Pi-enheterna. Vidare skapas ge-nesisblocket manuellt för att alla noder ska ha samma utgångspunkt och kunna synkronisera informationen mellan enheterna i filen genesis.json. Genesisblocket visas i Figur 9.
Figur 9: Filen för genesisblocket, Genesis.json
Miner1 och miner2 initialiseras med hjälp av kommandot
geth --datadir ~/Chainskills/miner1 init genesis.json och
geth --datadir ~/Chainskills/miner2 init genesis.json. På Raspberry Pi-enheterna körs kommandot
geth --datadir ~/Chainskills/node1 init genesis.json och 31
geth --datadir ~/Chainskills/node2 init genesis.json. Konton skapas på miner1 och miner2 genom kommandot
geth --datadir ~/Chainskills/miner1 account new och
geth --datadir ~/Chainskills/miner2 account new. På Raspberry Pi-enheterna körs kommandot
geth --datadir ~/Chainskills/node account new och
geth --datadir ~/Chainskills/node2 account new istället. Lösenord anges för de konton som skapas. Ett skript skapas för att starta geth-processen och moduler som ska startas med processen anges. Skriptet är unikt för varje enhet då avlyss-ningsport samt enhetsnamn anges för geth-processen. Genom skriptet initialiseras mining-processen på datorn och nod-processen på Raspberry Pi-enheterna. I Figur 10 visas geth-skriptet för miner1.
Figur 10: Skriptet som start geth-processen på miner1
I Figur 11 visas skriptet som startar geth-processen på nod1.
Figur 11: Skriptet som start geth-processen på nod1
Fortsättningsvis sammankopplas enheterna statiskt till varandra med hjälp av en enode-address, IP-address och nätverksport samt sparas i filen static-nodes.json.
Enode-adressen är en individuell adress som varje enhet får av geth-processen för sammankoppling. Filen static-nodes.json tillåter blocksynkroniseringen att initiera mellan de angivna noderna i filen när skriptet körs. Enode-addressen identifieras att med hjälp av kommandot geth attach som startar upp Javascript-konsolen och därefter skrivs admin.nodeInfo.enode in.
Genom konsolen tillåts även transaktioner att skickas, status på konton att kontrolleras och inspektion av individuella block att undersökas och felsökning att göras. För att säkerställa att noderna har sammankopplats körs kommandot admin.peers vilket visas i Figur 12. Vidare är blockkedjan färdigimplementerad och funktionsduglig.
Figur 12: Peers på det privata nätverket
33
Datorn konfigureras för att agera som miner, då Ethereum använder konsen-susmetoden proof-of-work. De två Raspberry Pi-enheterna konfigureras som noder på det privata nätverket. På detta vis kan en majoritet nås vid beslut om ett block ska placeras i kedjan eller inte.
Genom att i Javascript-konsolen exekvera kommandot
eth.sendTransaction({from:sender, to:receiver, value: amount}) genom-förs en transaktion ifrån sender till receiver, och value representerar antalet Ether.
Antalet Ether som skickas är oväsentligt då en privat Ethereum-instans körs och valutan saknar värde.
Ett manipuleringstest av blockkedjan utfördes genom att ändra en av nodernas interna klocka till ett tidigare skede. Den interna klockan på nod 1 konfigurerades till 03:30 medans de övriga nodernas klocka var ställd på 12:20. Syftet var att placera in ett block med en tidigare tidsstämpel än övriga noder i kedjan och manipulera tidslinjen för blocken. Att konfigurera klockan på noden gjordes med kommandot sudo date +%T -s "03:30:00".
För att återställa konfigurationen efter manipulation av variabler krävs det att mappen geth raderas på samtliga noder, genesis.json-filen initialiseras igen och static-nodes.json-filerna uppdateras med de nya enode-adresserna som utdelas.
För att testa ett realistiskt scenario där noder sänder insamlad information till blockkedjan, överfördes tio transaktioner i sekunden under ett fem-minutersintervall.
Ett annat test genomfördes för att identifiera medelvärdet av tiden att produ-cera fram varje block. Detta genomfördes med hjälp av ett skript, för att loopa igenom de senaste n blocken. Skriptet hämtade systematiskt ut epochen för varje block och jämförde det med blocket närmast före för att få en mellanskillnad i se-kunder. Dessa mellanskillnader jämfördes därefter för att räkna ut ett medelvärde för utvinning per block.
5 Resultat
I detta kapitel presenteras resultatet ifrån experimentet.
Vid varje transaktion är det möjligt att skicka data som representeras i hex-adecimal form i blocket. I Figur 13 visas en transaktion mellan två konton i det privata nätverket. Tillägget data.web3.toHex('Valfri text här') ger möjlig-heten att inkludera valfri text i transaktionen, som sedan placeras i blockkedjan. I detta fallet skrivs texten ”Mjölken är nuvarande 8 grader Celsius, på Gården Test-gård”. Svaret ifrån konsolen i grön text är transaktionshashen för den specifika transaktionen.
Figur 13: Transaktion via Javascript-konsolen, i vilken data lagras för att säkra integri-teten
Genom att exekvera kommandot eth.getTransaction('Hashen för transaktionen') hämtas blocket som transaktionen placerades i. Detta visas grafiskt i Figur 14. I blockets variabel ”input” lagras det hexadecimala värdet av data som skickas. Va-riabeln ”timestamp” visar blockets exakta tidpunkt för transaktionen i formatet epoch.
Figur 14: Blocket för den specifika transaktionen där temperaturen överfördes för att säkra integriteten
Att föra in den hexadecimala data i en översättare gör det möjligt att få texten läs-bar igen. Då återfås originalmeddelandet ”Mjölken är nuvarande 8 grader Celsius, på Gården Testgård”. Detta illustreras i Figur 15.
Figur 15: Översättning av hexadecimal data ifrån blocket till klartext
Transaktionen är dessutom möjlig att observera på övriga noder, vilket visas i Figur 16. Detta bekräftar att data har synkroniserats mellan enheterna.
Figur 16: Transaktionen observeras på nod #1
När blocket har accepterats av samtliga noder i beslutsprocessen är informatio-nen synkroniserad och integriteten säkrad i kedjan. Vidare kan informatioinformatio-nen inte längre påverkas (såvida inte extremt kraftfull datorkraft ansluts).
Att försöka manipulera tidslinjen för blockkedjan genom att ställa om den interna klockan på en av noderna resulterade i att den nod som konfigurerades avvisades av övriga noder och synkroniserade inte med blockkedjan. Därmed är det inte möjligt att påverka blockkedjans tidslinje utan att kontrollera majoriteten av noder.
5.1 Statistik av experiment
Resultatet ifrån testet där tio transaktioner i sekunden genomfördes under ett fem-minutersintervall visar en transaktionshastighet på 9,8 transaktioner per sekund.
Detta för att samtliga transaktioner inte hann föras in i ett block innan intervallet gick ut, vilket förklarar bortfallet av 59 transaktioner. 27 block skapades under de fem minuter testet pågick, vilket medför 5,4 block per minut. 2941 transaktioner hann läggas till i block, vilket innebär ett medelvärde på 108,9 transaktioner per block. Formel för uträkning av standardavvikelsen visas i Ekvation 1.
s =
√∑n
i=1(xi− ¯x)2
n− 1 (1)
Där:
• s är standardavvikelsen.
• xi är värdet av observationen i stickprovet.
• ¯x är medelvärdet av stickprovet.
• n är antalet observationer i stickprovet.
Ett konfidensintervall beräknades på testdata där 3000 transaktioner överför-des på fem minuter. Transaktionerna delaöverför-des upp i block i den takt block utvinns.
Konfidensintervallet använde signifikansnivån 95% och beräknades till (72.076, 145.776). Antalet transaktioner per block varierade beroende på hur snabbt bloc-ken kunde utvinnas. I Tabell 3 visas antalet utvunna block, totala antalet trans-aktioner inom tidsintervallet samt standardavvikelsen, variansen och medelvärdet av antalet transaktioner per block.
37
Tabell 3: Statistik från transaktionstest som genomfördes under 300 sekunder, antalet transaktioner per block loggades under de fem minuter testet pågick för att observera transaktioner/block, transaktioner/s, block/s. Tabellen redovisar antalet block, trans-aktioner, standardavvikelsen, variansen och medelvärdet.
Antal block 27
Transaktioner 2941
Standardavvikelsen 97.692581375663
Varians 9543.8404558405
Medelvärde tx/block 108.92592592593
6 Inledande diskussion
I detta kapitel kommer en diskussion och analys föras utifrån redovisad litteratur samt resultat.
6.1 Blockkedjor
De tekniker som har framlyfts och diskuterats har olika syften och olika egenska-per. Exempelvis är Ethereum främst en blockkedjeteknik med kryptovaluta som huvudsyfte, vilket innebär att blockkedjan är utformad efter finansiella ändamål.
Detta kan leda till att just den tekniken väljs bort vid implementering, baserat på Ethereums syfte och funktionalitet.
Som diskuterades i tidigare kapitel så passar Hyperledger nätverk med större omfattning, vilket resulterar i att Hyperledgers lösning är mer anpassningsbar efter användarens avsikter. Hyperledger har starkt stöd från stora företag och agerar som ett ramverk vid implementering, vilket gör det attraktivt för många marknader.
BigChainDB är skapad för samma ändamål som Hyperledger. Både dessa blockkedjelösningar är avsedda att fungera i större nätverk för lagring och distri-buering av stora datamängder, vilket kan behövas i industriella miljöer där stora mängder data överförs. BigchainDB kan lösa problem som andra blockkedjor inte klarar av lika bra, som den höga genomströmningen. Således har BigchainDB stora möjligheter att ses som en potentiell lösning till att säkra integritet av data, då den i teorin klarar av att hantera industrimiljön.
Ethereum är den enda blockkedjetekniken av de som här betraktas vars kon-sensusmetod är proof-of-work. Då resterande blockkedjetekniker främst används inom privata kontrollerade miljöer krävs inte miners för att åstadkomma konsen-sus utan sköts på administrativ väg istället. Lösningen med miners i en industriell miljö är genomförbart. Det finns andra konsensusmetoder som passar miljön bättre där inte stora mängder el och datorkraft behöver ödslas för att säkra integriteten av data. Hyperledgers konsensusmetod utnyttjar permissioned konsensus och en administratör styr skapelsen av blocken, vilket lämpar sig bättre.
Att Hyperledger och BigchainDB har anpassningsbara transaktionsegenskaper härstammar från deras möjligheter att anpassa storleken med antal enheter på nätverket. BigchainDB kan åstadkomma upp till 200 000 transaktioner per sekund då 16 serverkluster används på det privata nätverket. Detta gör dessa protokoll till attraktiva val där hastigheten av transaktionerna anses kritiska.
Ethereum klarar av mer jämnlöpande transaktioner men inte att hantera de snabbt nog, vilket till slut resulterar i att Hyperledger Fabric når snabbare genom-strömning.
39
Då Ethereum i nuläget använder sig av Proof-of-Work som konsensusmetod är det problematiskt för en angripare att besitta 51% av den totala hashraten som krävs för att kunna fatta egna beslut inom kedjan. Ethereums svagheter lig-ger främst inom dess teknik gällande smart contracts. Felkonfigureras dessa finns risken att sårbarheter i tekniken utnyttjas. Blockkedjan ska vara fullständigt oför-änderlig och detta medför att de publicerade smart contracts inte går att modifiera i efterhand. Har då ett sårbart smart contract introducerats i kedjan kan detta få oönskade effekter för användare, exempelvis förlorad kryptovaluta eller datain-tegritet. Detta innebär att noggrann planering av smart contracts krävs innan publikation för att förhindra att problem uppstår i framtiden. Experimentet bevi-sar att smart contracts inte är nödvändigt implementeringsmässiga för att säkra integriteten, men smart contracts för med sig många möjligheter att modifiera hur blockkedjan kan användas. Den föreslagna lösningen är att hoppa över en imple-mentering av smart contracts då de i slutändan kan åstadkomma mer skada än de bidrar till.
Hyperledger skiljer sig ifrån Ethereum genom att använda sig av en konsen-susmetod som inte kräver att miners bidrar till säkerheten. Ethereums konsensus-metod PoW är inte lika applicerbar prestandamässigt som Hyperledgers konsensus-metod i privata nätverk. Hyperledgers konsensusmetod, PBFT, är i sig en flaskhals och drar ner genomströmningen för nätverket. Varför man valt denna konsensusme-toden ändå är väl värt att diskutera då konsensusmetoder som PoS existerar och medför hög säkerhet samtidigt som energianvändningen avsevärt minskar, jämfört med PoW. PBFT visade sig även vara sårbar mot attacker vilket fick genomström-ningen att drastiskt sjunka ytterligare.
Hyperledger är en relativt ny blockkedja, detta leder till att vetenskapliga eva-lueringar av tekniken kan vara problematiska att hitta. Vidare var det svårt att finna information kring kända sårbarheter, till skillnad från Ethereum som stude-rats i större omfattning. I likhet med Hyperledger var Quorum och BigchainDB svåra att hitta vetenskapliga referenser till gällande sårbarheter. Troligtvis för att teknikerna fortfarande är i ett relativt tidigt skede i utvecklingsfasen, och att det inte finns tillräckligt med etablerad forskning.
BigchainDB är ett projekt under utveckling, vilket resulterar i att det fortfa-rande finns potential för förbättring. Tekniken beter sig fortfafortfa-rande mer likt en databas än en blockkedja, om nodernas informationsdelning studeras. Vidare kan den anses vara ofullständig i nuvarande skick. Varför BigchainDB likväl valts att kartläggas beror på att dess implementering är skalbar, passar i industrimiljöer där mycket data flödar och kräver administrering av kraftfulla databaser. Teknologin kan vara ett lämpligt alternativ att föra en diskussion kring.
När det finns potential, existerar det också problematik. Kvantdatorer är ett generellt hot mot majoriteten av nuvarande blockkedjor då kvantsäkra
krypterings-metoder sällan används. Detta problem kräver en lösning då kvantdatorer ständigt utvecklas och enbart är några år från att bli ett verkligt hot. Att implementera kvantsäker krypteringsmetodik är kritiskt då den brutala datorkraften som kvant-datorer sitter inne på snabbt kan hitta kollisioner av blockens hashsumma, och byta ut informationen i block för att gynna sig själv. Därmed skulle integriteten direkt förloras i blockkedjan.
Med tanke på blockkedjans explosionsartade utveckling där nya tekniker ut-formas för att göra implementering av blockkedjor mindre komplicerad och mer lönsam, uppstår problematik. En implementering kan utföras och fungera tillfreds-ställande under rådande omständigheter en dag, men nästa dag kan en ny teknik introduceras och utföra samma uppgift effektivare. Man får säga att blockkedjor är revolutionerande med alla möjligheter de innebär för majoriteten av marknaden och att tekniken bedöms därför fortfarande vara i ett tidigt skede av sin utveck-ling. Vidare finns utrymme för nya tekniker att expandera. Något som är värt att diskutera är hur anpassningsbart de är i industriella miljöer. Det finns idag ännu inte så mycket vetenskaplig forskning över hur mycket data en blockkedja verkligen klarar vid ett kontinuerligt flöde.
Genom att kartlägga och sammanställa egenskaperna av de blockkedjeteknolo-gier som förts fram i studien bidrar arbetet med en genomgång av de blockkedjor som existerar, vilka ändamål blockkedjorna har och egenskaper de besitter. Vi-dare kan informationen leda till ett enklare beslut vid implementering av en egen blockkedja. Visserligen skulle en implementation av Hyperledger vara mer relevant i det här sammanhanget, men slutligen valdes en annan variant vid implementation för en enklare demonstration. För att nå en liknande jämförelse med Hyperledger valdes Go-Ethereum.