1

RaiBlocks: Een Gedistribueerd CryptocurrencyNetwerk Zonder Kosten

Colin LeMahieuclemahieu@gmail.com

Abstract—Tegenwoordig hebben de grote vraag en de beperkteschaalmogelijkheden van populaire cryptocurrencies de gemid-delde transactietijden verhoogd, wat resulteert in een slechtegebruikerservaring. RaiBlocks, een cryptocurrency met eennieuwe block-lattice-architectuur, waarbij elk account zijn eigenblockchain heeft en met een bijna onmiddellijke transactiesnel-heid en onbeperkte schaalbaarheid, biedt hierop een antwoord.Elke gebruiker heeft zijn eigen blockchain, waardoor dezeasynchroon kan worden bijgewerkt naar de rest van het netwerk,wat resulteert in snelle transacties met minimale overhead-kosten. Transacties houden rekeningevenwichten bij in plaatsvan transactiebedragen, waardoor in de database kan wordengesnoeid zonder de beveiliging in gevaar te brengen. Tot op hedenheeft het RaiBlocks-netwerk 4,2 miljoen transacties verwerktmet een niet-ondersteunde grootboekgrootte van slechts 1,7 GB.RaiBlock’s kosteloze, split-second transacties maken het de eerstecryptocurrency voor consumententransacties.

Index Terms—cryptocurrency, blockchain, raiblocks, gedis-tribueerd grootboek, digitaal, transacties

I. INTRODUCTIE

S INDS de implementatie van Bitcoin in 2009 is er eentoenemende verschuiving gaande van traditionele, door

de overheid gesteunde valuta’s en financiele systemen naarmoderne betalingssystemen op basis van cryptografie, diede mogelijkheid bieden om fondsen op een betrouwbareen veilige manier op te slaan en over te dragen [1]. Omeffectief te kunnen functioneren, moet een valuta gemakkelijkoverdraagbaar en onomkeerbaar zijn, en beperkte of geenkosten bevatten. De verhoogde transactietijden, hoge kosten entwijfelachtige schaalbaarheid van het netwerk hebben vragendoen rijzen over de bruikbaarheid van Bitcoin als dagelijksevaluta.

In dit artikel introduceren we RaiBlocks, een cryptocur-rency met lage latentie, gebouwd op een innovatieve block-lattice-gegevensstructuur, die onbeperkte schaalbaarheid engeen transactiekosten biedt. RaiBlocks is volgens ontwerp eeneenvoudig protocol met als enige doel een high-performancecryptocurrency te zijn. Het RaiBlock-protocol kan op low-power-hardware draaien, waardoor het een praktische, gede-centraliseerde cryptocurrency voor dagelijks gebruik is.

Cryptocurrency-statistieken die in dit document wordenvermeld, zijn accuraat vanaf de publicatiedatum.

II. ACHTERGROND

In 2008 publiceerde een anonieme bron onder de schuil-naam Satoshi Nakamoto, een whitepaper, die ’s werelds eerstegedecentraliseerde cryptocurrency, Bitcoin, uitlijnde [1]. Een

sleutelinnovatie die Bitcoin tot stand bracht was de blockchain.Een publieke, onveranderlijke en gedecentraliseerde datastruc-tuur die wordt gebruikt als een grootboek voor de transactiesvan de valuta. Naarmate Bitcoin volwassen werd, maaktenverschillende problemen in het protocol Bitcoin onbruikbaar:

1) Slechte schaalbaarheid: elk blok in de blockchainkan een beperkte hoeveelheid gegevens opslaan. Datbetekent dat het systeem slechts zoveel transacties perseconde kan verwerken, wat van deze blokken eengrondstof maakt. Momenteel zijn de gemiddelde trans-actiekosten $10.38 [2].

2) Hoge latentie: de gemiddelde bevestigingstijd is 164minuten [3].

3) Energie inefficient: Het Bitcoin netwerk verbruikt eengeschatte 27.28TWh per jaar, met een gemiddelde van260KWh per transactie [4].

Bitcoin en andere cryptocurrencies functioneren door con-sensus te bereiken over hun wereldwijde grootboeken omlegitieme transacties te verifieren, terwijl ze kwaadwillendeactoren weerstaan. Bitcoin bereikt een consensus via eeneconomische maatregel genaamd Proof of Work (PoW). In eenPoW-systeem concurreren deelnemers om een getal, genaamdnonce, te berekenen, zodat de hash van de hele blockchain bin-nen doelbereik ligt. Dit geldige bereik is omgekeerd evenredigmet het cumulatieve rekenvermogen van het gehele Bitcoin-netwerk om een consistente gemiddelde tijd te behouden dieis bereikt voor een geldige nonce. De vinder van een geldigenonce wordt dan toegestaan om het blok aan de blockchain toete voegen; daarom zullen degenen die meer computerkrachthebben, een grotere rol spelen in het berekeningsproces vande blockchain. PoW biedt weerstand tegen een Sybil-aanval,waarbij een entiteit zich als meerdere entiteiten voordoet omextra kracht te krijgen in een gedecentraliseerd systeem, en ookde racetoestanden die inherent aanwezig zijn tijdens toegangtot een wereldwijde gegevensstructuur aanzienlijk vermindert.

Een alternatief consensusprotocol, Proof of Stake (PoS),werd voor het eerst geıntroduceerd door Peercoin in 2012[5]. In een PoS-systeem stemmen de deelnemers met eengewicht dat overeenkomt met het aandeel dat ze bezitten in eenbepaalde cryptocurrency. Met deze regeling hebben degenenmet een grotere financiele investering meer macht gekregenen worden ze inherent gestimuleerd om de eerlijkheid vanhet systeem te behouden, of ze lopen hey risico om hun in-vestering te verliezen. PoS maakt komaf met de verkwistenderekenkrachtwedstrijd, waardoor alleen lichtgewicht softwarenodig is die draait op hardware met een laag vermogen.

2

Ontvangst Herhaling Observatie Quorum Bevestiging

(a) Als er geen conflict is gedetecteerd, zijn er geen verdere overheadkosten vereist.

Ontvangst Herhaling Observatie Conflict Stemming Bevestiging

(b) Als een tegenstrijdige transactie (conflict) zich voordoet, stemmen nodes voor de valide transactie.Fig. 1. RaiBlocks vereist geen additionele overheadkosten voor typische transacties. Als er tegenstrijdige transacties zijn, moeten nodes stemmen voor detransactie die behouden wordt

De oorspronkelijke RaiBlocks-paper en de eerste beta-implementatie werden gepubliceerd in december 2014, waar-door het een van de eerste Direct Acyclic Graph (DAG)cryptocurrencies werd [6]. [6]. Kort daarna begonnen zichandere DAG-cryptocurrencies te ontwikkelen, met name Dag-Coin / Byteball en IOTA [7], [8]. Deze op DAG gebaseerdecryptocurrencies braken de blockchain-vorm, waardoor desysteemprestaties en -beveiliging werden verbeterd. Byteballbereikt een consensus door te vertrouwen op een ”hoofdketen”bestaande uit eerlijke, gerenommeerde en door de gebruikervertrouwde ”getuigen”. In tegenstelling presteert IOTA viade cumulatieve PoW van gestapelde transacties. RaiBlocksbereikt consensus via een balansgewogen stem over tegenstri-jdige transacties. Dit consensussysteem biedt snellere en meerdeterministische transacties, terwijl er nog steeds een sterk engedecentraliseerd systeem wordt onderhouden. RaiBlocks zetdeze ontwikkeling voort en heeft zich gepositioneerd als eenvan de best presterende cryptocurrencies.

III. RAIBLOCKS COMPONENTEN

Voordat we de algemene RaiBlocks-architectuur beschri-jven, moeten we eerst de individuele componenten waaruithet systeem bestaat definieren.

A. Account

Een account is het openbare sleutelgedeelte van een digitaalhandtekenings-sleutelpaar. De openbare sleutel, ook wel hetadres genoemd, wordt gedeeld met andere netwerkdeelnemers.De privesleutel dient volstrekt geheim te blijven. Een digitaalondertekend pakket van gegevens zorgt ervoor dat de inhoudwordt goedgekeurd door de houder van de privesleutel. Eengebruiker kan veel accounts beheren, maar er kan per accountslechts een openbaar adres bestaan.

B. Blok/Transactie

De term ”blok” en ”transactie” worden vaak onderlingverwisselbaar gebruikt, waarbij een blok een enkele transactiebevat. Transactie verwijst specifiek naar de actie terwijl bloknaar de digitale codering van de transactie verwijst. Transactiesworden ontworpen door de privesleutel die hoort bij hetaccount waarop de transactie wordt uitgevoerd.

C. Grootboek

Het grootboek is de wereldwijde set van rekeningen, ofaccounts, waarbij elke rekening een eigen transactieketen

heeft (Figuur 2). Dit is een belangrijke ontwerp-componentdie valt onder de categorie van het vervangen van eenlooptijd overeenkomst met een ontwerptijd overeenkomst;iedereen gaat akkoord via handtekeningscontrole dat alleeneen rekening-eigenaar zijn eigen keten kan wijzigen. Ditconverteert een schijnbaar gedeelde gegevensstructuur, eengedistribueerd grootboek, naar een reeks niet-gedeelde groot-boeken.

D. Node

Een node is een stuk software dat wordt uitgevoerd op eencomputer die voldoet aan het RaiBlocks-protocol en deelneemtaan het RaiBlocks-netwerk. De software beheert het grootboeken eventuele accounts die de node al dan niet beheert. Eennode kan ervoor kiezen om het hele grootboek op te slaan, ofalleen een beknopte geschiedenis die de laatste blokken vande blockchain van elk account bevat. Bij het opzetten van eennieuwe node wordt het aanbevolen om de gehele geschiedenisen stam lokaal te verifieren.

IV. SYSTEEMOVERZICHT

In tegenstelling tot blockchains die in veel andere cryptocur-rencies worden gebruikt, gebruikt RaiBlocks een blok-roosterstructuur. Elk account heeft zijn eigen blockchain (account-chain) equivalent aan de transactie/balans-geschiedenis vanhet account (Figuur 2). Elke accountketen kan alleen wor-den bijgewerkt door de eigenaar van het account; hierdoor

Account ABlock NA

Account ABlock NA − 1

...

Account ABlock 1

Account ABlock 0

Account BBlock NB

Account BBlock NB − 1

...

Account BBlock 1

Account BBlock 0

Account CBlock NC

Account CBlock NC − 1

...

Account CBlock 1

Account CBlock 0

Fig. 2. Elk account heeft zijn eigen blockchain die de geschiedenis van derekeningbalans bevat. Blok 0 moet een open transactie zijn (Section IV-B)

3

kan elke accountketen onmiddellijk en asynchroon wordenbijgewerkt naar de rest van het blok-rooster, wat resulteertin snelle transacties. Het protocol van RaiBlocks is extreemlicht; elke transactie past binnen de vereiste minimale UDP-pakketgrootte voor verzending via internet. Voorwaarden voorhardwarevereisten zijn ook minimaal, omdat nodes alleen deblokken voor de meeste transacties hoeven te registreren enopnieuw moeten uitwerken (Figuur 1).

Het systeem wordt geınitieerd met een genesis-accountdat de genesis-balans bevat. De genesis-balans is een vastehoeveelheid en kan nooit worden verhoogd. De genesis-balanswordt gedeeld en verzonden naar andere accounts via verzend-transacties die zijn geregistreerd op de genesis-accountketen.De som van de saldi van alle accounts overschrijdt nooitde oorspronkelijke genesis-balans die het systeem dus eenbovengrens geeft voor de maximale hoeveelheid. Er is dusook geen mogelijkheid om de totale balans te verhogen.

In dit gedeelte wordt beschreven hoe verschillende soortentransacties worden geconstrueerd en verspreid door het helenetwerk.

A B C

S

R

R

R

S

R

R

S

S

S

......

...

Tijd

Fig. 3. Visualisatie van het blok-rooster. Elke transactie van fondsen vereisteen zend blok (S) en een ontvangst blok (R), beiden ondertekend door hunrekeninghouder (A,B,C)

A. Transacties

Voor het overboeken van bedragen van het ene naar hetandere account zijn twee transacties nodig: een zending diehet bedrag van het account van de zender verminderd eneen ontvangst die de bedragen optelt bij de balans van deontvanger (Figuur 3).

Het overboeken van bedragen als afzonderlijke transactiesin de rekeningen van de afzender en de ontvanger dient eenaantal belangrijke doelen:

1) Het ordenen van inkomende transfers die inherent asyn-chroon zijn.

2) Transacties klein houden om in UDP-pakketten tepassen.

3) Mogelijkheid tot beperken van het grootboek door hetminimaliseren van de data-voetafdruk.

4) Het isoleren van afgehandelde transacties tegenover nietafgehandelde transacties.

Meerdere accounts die worden overgedragen naar hetzelfdebestemmingsaccount, vormen een asynchrone bewerking. Do-ordat netwerklatentie en verzendaccounts niet noodzakelijkin communicatie met elkaar zijn, betekent dit dat er geenalgemeen aanvaardbare manier is om te weten welke transactiehet eerst is gebeurd. Omdat optellen associatief is, is devolgorde van de inputs niet van belang, en daarom hebbenwe eenvoudigweg een wereldwijde overeenkomst nodig. Dit iseen sleutelontwerp-component die een looptijd-overeenkomstconverteert naar een overeenkomst voor ontwerptijd. Het ont-vangende account heeft controle over de beslissing welkeoverdracht het eerst is binnengekomen en wordt uitgedruktdoor de ontworpen volgorde van de inkomende blokken.

Als een account een grote overschrijving wil doen die werdontvangen als een set van veel kleine overschrijvingen, willenwe dit weergeven op een manier die past in een UDP-pakket.Wanneer aan een ontvangstrekening inkomende reeksen wor-den overgedragen, houdt deze een lopend totaal van haarrekeningsaldo bij, zodat het op elk moment de mogelijkheidheeft om elke hoeveelheid met een transactie van een vasteafmeting over te dragen. Dit verschilt van het input / output-transactiemodel dat door Bitcoin en andere cryptocurrencieswordt gebruikt.

Sommige nodes hebben geen interesse in het bestedenvan bronnen om de volledige transactiegeschiedenis van eenaccount op te slaan; ze zijn alleen geınteresseerd in het huidigesaldo van elk account. Wanneer een account een transactieuitvoert, codeert het zijn geaccumuleerde saldo en hoevendeze nodes alleen het laatste blok bij te houden, waardoorze historische gegevens kunnen verwijderen met behoud vande juistheid.

Zelfs met een focus op ontwerptijd-overeenkomsten is ereen uitstel-venster voor het valideren van transacties, van-wege het identificeren en verwerken van slechte actorenin het netwerk. Omdat overeenkomsten in RaiBlocks snelworden bereikt, in de orde van milliseconden tot secon-den, kunnen we de gebruiker twee vertrouwde categorieenvan inkomende transacties presenteren: afgehandeld en niet-afgehandeld. Afgehandelde transacties zijn transacties waar-bij een account ontvangstblokken heeft gegenereerd. Niet-afgehandelde transacties zijn nog niet opgenomen in hetcumulatieve saldo van de ontvanger. Dit is een vervangingvoor de meer complexe en onbekende bevestigingsmetriek inandere cryptocurrencies.

B. Een Account maken

Als u een account wilt maken, moet u een openstaandetransactie uitvoeren (Figuur 4). Een open transactie is altijdde eerste transactie van elke accountketen en kan wordenaangemaakt bij de eerste ontvangst van een bedrag. Hetaccount veld bewaart de publieke sleutel (adres) afgeleid van

4

de privesleutel die gebruikt wordt voor de handtekening. Hetbron veld bevat de hash van de transactie die de bedragenheeft verzonden. Bij het maken van een account moet eenvertegenwoordiger worden gekozen om namens u te stemmen;dit kan later worden gewijzigd (Sectie IV-F). Het account kanzichzelf tot eigen vertegenwoordiger verklaren.

open {account: DC04354B1...AE8FA2661B2,source: DC1E2B3F7C...182A0E26B4A,representative: xrb_1anr...posrs,work: 0000000000000000,type: open,signature: 83B0...006433265C7B204

}

Fig. 4. Anatomie van een open transactie

C. Rekening-balans

Het rekeningsaldo wordt binnen het grootboek zelf gereg-istreerd. In plaats van het bedrag van een transactie op tenemen, zal verificatie (Sectie IV-I) het controleren van hetverschil tussen de balans op het verzend-blok en de balansvan het vorige blok vereisen. Het ontvangende account kandan het vorige saldo verhogen zoals gemeten in het eindsaldodat is gegeven in het nieuwe ontvang-blok. Dit wordt gedaanom de verwerkingssnelheid te verbeteren bij het downloadenvan grote hoeveelheden blokken. Bij het aanvragen van deaccountgeschiedenis zijn bedragen al gegeven.

D. Zenden van een Account

Om van een adres te verzenden, moet het adres reeds eenopenstaand blok hebben, en dus ook een balans (Figuur 5).Het vorige veld bevat de hash van het vorige blok in derekening-keten. Het bestemming veld bevat de rekening voorde te verzenden bedragen. Een verzend-blok is onverander-baar zodra het is bevestigd. Zodra het op het netwerk isuitgezonden, worden de bedragen onmiddellijk van het saldovan de afzenders-rekening afgetrokken en worden beschouwdals wachtend totdat de ontvanger een blok signeert om debedragen te aanvaarden. Geld in afwachting moet niet wordenbeschouwd als een wachtende bevestiging, omdat ze zo goedals uitgegeven zijn door het afzender-account en de afzenderde transactie niet kan intrekken.

send {previous: 1967EA355...F2F3E5BF801,balance: 010a8044a0...1d49289d88c,destination: xrb_3w...m37goeuufdp,work: 0000000000000000,type: send,signature: 83B0...006433265C7B204

}

Fig. 5. Anatomie van een verzend-transactie

E. Een Transactie Ontvangen

Om een transactie te voltooien, moet de ontvanger vanverzonden bedragen een ontvangstblok maken in zijn eigenaccountketen (Figuur 6). Het bronveld verwijst naar de hashvan de bijbehorende verzend-transactie. Zodra dit blok isgemaakt en uitgezonden, wordt het accountsaldo bijgewerkten zijn de bedragen officieel op hun rekening geplaatst.

receive {previous: DC04354B1...AE8FA2661B2,source: DC1E2B3F7C6...182A0E26B4A,work: 0000000000000000,type: receive,signature: 83B0...006433265C7B204

}

Fig. 6. Anatomie van een ontvangst-transactie

F. Een Vertegenwoordiger Toewijzen

Rekeninghouders die de mogelijkheid hebben om een verte-genwoordiger te kiezen die namens hen stemt, is een krachtigedecentralisatie-tool die geen sterke analogie heeft met Proofof Work, noch Proof of Stake protocollen. In conventionelePoS-systemen moet de node van de rekeninghouder draaienom deel te nemen aan de stemming. Het continu uitvoerenvan een node is voor veel gebruikers onpraktisch; een verte-genwoordiger de mogelijkheid geven namens een account testemmen, versoepelt deze vereiste. Rekeninghouders kunnenop elk moment consensus toevoegen aan een rekening. Eenveranderings- transactie wijzigt de vertegenwoordiger van eenrekening door het stemgewicht af te trekken van de oudevertegenwoordiger en het gewicht toe te voegen aan de nieuwevertegenwoordiger (Figuur 7). Er worden geen bedragen ver-plaatst in deze transactie en de vertegenwoordiger heeft geenkoopkracht over de tegoeden van het account.

change {previous: DC04354B1...AE8FA2661B2,representative: xrb_1anrz...posrs,work: 0000000000000000,type: change,signature: 83B0...006433265C7B204

}

Fig. 7. Anatomie van een veranderings-transactie

G. Vorken en Stemmen

Een vork treedt op wanneer j ondertekende blokkenb1, b2, . . . , bj dezelfde blok als hun voorgaande opeisen(Figuur 8). Deze blokken veroorzaken een conflicterendeweergave van de status van een account en moeten wordenopgelost. Alleen de eigenaar van de rekening heeft de mogeli-jkheid om blokken in de account-keten te ondertekenen, duseen vork moet het resultaat zijn van slechte programmering

5

Account ABlock i

Account ABlock i+ 1

Account ABlock i+ 2

Account ABlock i+ 2

Fig. 8. Een vork treedt op wanneer twee (of meer) ondertekende blokkenverwijzen naar hetzelfde vorige blok. Oudere blokken staan aan de linkerkant;nieuwere blokken staan aan de rechterkant

of kwaadwillige intentie (dubbele uitgaven) door de eigenaarvan het account.

Na detectie creeert een vertegenwoordiger een stem dieverwijst naar het blok bi in het grootboek en zendt het naarhet netwerk. Het stemgewicht van een node, wi, is de som vande saldi van alle accounts die het als zijn vertegenwoordigerhebben genoemd. De node neemt de inkomende stemmen vande andere online vertegenwoordigers van M waar en houdt eencumulatief aantal stemperioden van 1 minuut bij en bevestigthet winnende blok 1).

v(bj) =

M∑i=1

wi1bi=bj(1)

b∗ = argmaxbj

v(bj) (2)

Het meest populaire blok b∗ zal de meerderheid van destemmen halen en zal worden bewaard in het grootboek(Vergelijking 2). De blokken die de stemming verliezen wor-den genegeerd. Als een vertegenwoordiger een blok in hetgrootboek vervangt, maakt het een nieuwe stem met een hogervolgnummer en zendt het de nieuwe stem uit naar het netwerk.Dit is het enige scenario waarin de vertegenwoordigers stem-men.

In sommige omstandigheden kunnen korte netwerkconnec-tiviteitsproblemen ertoe leiden dat een uitgezonden blok nietdoor alle peers wordt geaccepteerd. Elk volgend blok in ditaccount zal als ongeldig worden genegeerd door peers diede eerste uitzending niet hebben gezien. Een heruitzendingvan dit blok wordt door de resterende peers geaccepteerd ende daaropvolgende blokken worden automatisch opgehaald.Zelfs wanneer een vork of een ontbrekend blok voorkomt,worden alleen de rekeningen beınvloed die in de transactieworden genoemd; de rest van het netwerk gaat verder metverwerkingstransacties voor alle andere accounts.

H. Proof of Work

Alle vier de transactietypen hebben een werkveld dat correctmoet worden ingevuld. Het werkveld maakt het de transac-tiemaker mogelijk om een nonce te berekenen, zodanig datde hash van de nonce samengevoegd met het vorige veld inontvang / verzend / wijzigings transacties of het accountveldin een open transactie onder een bepaalde drempelwaardeligt. In tegenstelling tot Bitcoin, wordt de PoW in RaiBlockseenvoudig weg gebruikt als antispamhulpmiddel, vergelijkbaar

met Hashcash, en kan deze worden berekend in de ordevan seconden [9]. Zodra een transactie is verzonden, kan dePoW voor het volgende blok vooraf worden berekend sindshet vorige blokveld bekend is; hierdoor zullen transactiesogenblikkelijk aan een eindgebruiker verschijnen, zolang detijd tussen transacties groter is dan de tijd die nodig is om dePoW te berekenen.

I. Transactie Verificatie

Om een blok als geldig te kunnen beschouwen, moet hetblok de volgende attributen hebben:

1) Het blok mag zich niet al in het grootboek bevinden(dubbele transactie).

2) Moet door de eigenaar van het account worden ondertek-end.

3) Het vorige blok is het hoofdblok van de accountketen.Als het bestaat, maar niet het hoofd is, is het een vork.

4) Het account moet een open blok hebben.5) De berekende hash voldoet aan de PoW-drempelvereiste.

Als het een ontvangst blok is, controleer dan of de bronblokhash in behandeling is, wat betekent dat het nog niet isingewisseld. Als het een verzendblok is, moet het saldo kleinerzijn dan het vorige saldo.

V. AANVALSVECTOREN

RaiBlocks kan, net als alle gedecentraliseerde cryptocur-rencies, worden aangevallen door kwaadwillende partijen voorpoging tot financieel gewin of het vernietigen van het systeem.In deze sectie schetsen we enkele mogelijke aanvalscenario’s,de gevolgen van een dergelijke aanval en hoe het protocol vanRaiBlocks preventieve maatregelen neemt.

A. Block Gap Synchronisatie

In Sectie IV-G, hebben we het scenario besproken waarbijeen blok mogelijk niet goed wordt uitgezonden, waardoor hetnetwerk de volgende blokken negeert. Als een node een blokwaarneemt dat niet het vorige blok bevat, heeft het twee opties:

1) Negeer het blok want het kan kwaadaardig zijn.2) Vraag een hersynchronisatie met een andere node.

In het geval van een hersynchronisatie moet een TCP-verbinding worden gevormd met een bootstrap-node om detoegenomen hoeveelheid verkeer die een hersynchronisatienodig heeft te vergemakkelijken. Als het blok echter een slechtblok zou zijn geweest, zou de hersynchronisatie onnodig zijnen het verkeer op het netwerk zou onnodig zijn toegenomen.Dit is een Network Amplification Attack en resulteert in eendenial-of-service.

Om onnodige hersynchronisatie te voorkomen, wachtennodes tot een bepaalde drempel van stemmen is vastgesteldvoor een mogelijk kwaadaardig blok, voordat een verbind-ing met een bootstrap-node wordt gestart om te synchronis-eren. Als een blok onvoldoende stemmen krijgt, kan wordenaangenomen dat dit ongewenste gegevens zijn.

6

B. Het netwerk overspoelen met transactiesEen kwaadwillende entiteit kan veel onnodige maar geldige

transacties verzenden tussen accounts onder zijn beheer ineen poging het netwerk te verzadigen. Zonder transactiekostenkunnen ze deze aanval voor onbepaalde tijd voortzetten. Devereiste PoW voor elke transactie beperkt echter de transac-tiewaarde die de kwaadwillende entiteit zou kunnen genererenzonder significant te moeten investeren in computationelebronnen. Zelfs onder een dergelijke aanval in een poging omhet grootboek op te blazen, zijn nodes die geen nodes meteen volledige historie zijn in staat om oude transacties uit hunketen te snoeien; dit beperkt het opslaggebruik van dit typeaanval voor bijna alle gebruikers.

C. Sybil-AanvalEen entiteit kan honderden RaiBlocks-nodes maken op een

enkele machine; Aangezien het stemsysteem echter wordtgewogen op basis van het rekeningsaldo, resulteert het toevoe-gen van extra nodes aan het netwerk niet tot extra stemmenvoor aanvallers. Daarom is er geen voordeel te behalen viaeen Sybil-aanval.

D. Penny-Spend-AanvalBij een Penny-Spend-aanval zal een aanvaller oneindige

spam-hoeveelheden aan een groot aantal accounts bestedenom de opslagbronnen van nodes te verspillen. Blok publicatiewordt beperkt door het PoW-bestand, dus dit beperkt hetmaken van accounts en transacties tot op zekere hoogte. Nodesdie geen volledige historische nodes zijn, kunnen accountsonder een statistische metriek snoeien waarbij het accounthoogstwaarschijnlijk geen geldig account is. Ten slotte isRaiBlocks afgestemd om minimale permanente opslagruimtete gebruiken, dus ruimte die nodig is om een extra accountop te slaan is evenredig met de grootte van een open block+indexing = 96B + 32B = 128B. Dit staat gelijk aan het opkunnen slaan van 8 miljoen penny-accounts in 1GB. Als nodesagressiever accounts willen inkorten, kunnen ze een distributieberekenen op basis van de toegangsfrequentie en niet vaakgebruikte accounts delegeren naar langzamere opslag.

E. Precomputed PoW AanvalAangezien de eigenaar van een account de enige entiteit is

die blokken aan de accountketen toevoegt, kunnen opeenvol-gende blokken worden berekend, samen met hun PoW, voordatze naar het netwerk worden uitgezonden. Hier genereert deaanvaller een groot aantal opeenvolgende blokken, elk meteen minimale waarde, over een langere periode. Op eenbepaald moment voert de aanvaller een Denial of Service(DoS) uit door het netwerk te overspoelen met veel geldigetransacties, die andere nodes zo snel mogelijk verwerkenen echoen. Dit is een geavanceerde versie van de overslagvan transacties beschreven in Sectie V-B. Een dergelijkeaanval zou slechts kort werken, maar zou samen met andereaanvallen kunnen worden gebruikt, zoals een >50% Aanval(Section V-F) om de effectiviteit te vergroten. Momenteelworden transactiesnelheid-beperkende en andere techniekenonderzocht om aanvallen te verminderen.

F. >50% Aanval

De mate van consensus voor RaiBlocks is een evenwichtiggewogen stemsysteem. Als een aanvaller in staat is om meerdan 50% van de stemkracht te krijgen, kan hij ervoor zorgendat het netwerk een consensus forceert waardoor het systeemkapot gaat. Een aanvaller kan de hoeveelheid balans die hijmoet inleveren verlagen door te voorkomen dat goede nodesvia een DoS netwerk stemmen. RaiBlocks neemt de volgendemaatregelen om een dergelijke aanval te voorkomen:

1) De belangrijkste verdediging tegen dit soort aanvallen isdat het stemgewicht wordt gekoppeld aan de investeringin het systeem. Een rekeninghouder is inherent gestim-uleerd om de eerlijkheid van het systeem te handhavenom zijn investering te beschermen. Een poging om hetgrootboek om te draaien zou destructief zijn voor hetsysteem als geheel, wat hun investering zou vernietigen.

2) De kosten van deze aanval zijn evenredig aan de mark-tkapitalisatie van RaiBlocks. In PoW-systemen kan tech-nologie worden uitgevonden die een onevenredige cont-role geeft in vergelijking met monetaire investeringenen als de aanval succesvol is, kan deze technologieworden hergebruikt nadat de aanval is voltooid. MetRaiBlocks worden de kosten van een aanval op hetsysteem geschaald met het systeem zelf en zelfs alseen aanval succesvol zou zijn, kan de investering vande aanval niet worden teruggevorderd.

3) Om het maximale aantal van kiezers te handhaven, isde volgende verdedigingslinie representatief stemmen.Rekeninghouders die wegens connectiviteitsredenen nietop betrouwbare wijze kunnen deelnemen aan het stem-men, kunnen een vertegenwoordiger aanduiden die kanstemmen met het gewicht van hun saldo. Het maximalis-eren van het aantal en de diversiteit van vertegenwoordi-gers verhoogt de netwerkbestendigheid.

4) Vorken in RaiBlocks gebeuren nooit per ongeluk, dusnodes kunnen beleidsbeslissingen nemen over hoe omte gaan met gevorkte blokken. De enige tijd dat niet-aanvallersaccounts kwetsbaar zijn voor blokvorken isals ze een saldo van een aanvallend account ontvangen.Accounts die beveiligd willen zijn tegen blokvorkenkunnen een beetje of veel langer wachten voordat ze eenaccount ontvangen dat vorken genereert of ervoor kiestom nooit te ontvangen. Ontvangers kunnen ook aparteaccounts genereren om te gebruiken bij het ontvangenvan geld van dubieuze accounts om andere accounts teisoleren.

5) Een laatste verdedigingslinie die nog niet isgeımplementeerd, is blokcementering. RaiBlocksdoet er alles aan om blokvorken snel te vereffenen viastemmen. Nodes kunnen worden geconfigureerd omblokken te cementeren, wat zou voorkomen dat ze naeen bepaalde periode worden teruggerold. Het netwerkis voldoende beveiligd door zich te concentreren op eensnelle insteltijd om dubbelzinnige vorken te voorkomen.

Een meer geavanceerde versie van een > 50% aanval isgedetailleerd in Figuur 9. “Offline” is het percentage vertegen-woordigers dat is genoemd maar niet online is om te stemmen.

7

“Stake” is de hoeveelheid investering waarmee de aanvallerstemt. “Active” zijn vertegenwoordigers die online zijn enstemmen volgens het protocol. Een aanvaller kan het bedragvan de te verbeuren inzet verrekenen door andere kiezersoffline te slaan via een netwerk-DoS-aanval. Als deze aanvalkan worden volgehouden, worden de aangevallen vertegenwo-ordigers niet gesynchroniseerd en dit wordt aangetoond door“Unsync.” Ten slotte kan een aanvaller een korte opstoot inrelatieve stemkracht krijgen door zijn Denial of Service-aanvalom te zetten in een nieuwe set vertegenwoordigers, terwijlde oude set hun grootboek opnieuw synchroniseert, dit wordtgedemonstreerd door “Attack.”

Offline Unsync Attack Active Stake

Fig. 9. Een mogelijk stemmingsarrangement dat de aanvalsbehoeften van51% kan verlagen.

Als een aanvaller een Stake >Active kan veroorzakendoor een combinatie van deze omstandigheden zouden zede stemmen op het grootboek kunnen omdraaien ten kostevan hun inzet. We kunnen inschatten hoeveel dit type aanvalkan kosten door de marktkapitalisatie van andere systemente onderzoeken. Als we schatten dat 33% van de vertegenwo-ordigers offline is of wordt aangevallen via DoS, dan moet eenaanvaller 33% van de marktkapitalisatie kopen om het systeemvia stemmen aan te vallen.

G. Bootstrap PoisoningHoe langer een aanvaller in staat is om een oude privesleutel

met een saldo te behouden, des te groter de kans dat saldi dieop dat moment bestaan, geen deelnemende vertegenwoordigerszullen hebben, omdat ze hun saldo of vertegenwoordigers aannieuwere rekeningen hebben overgedragen. Dit betekent datals een node wordt gebootstrapped naar een andere repre-sentatie van het netwerk waar de aanvaller een quorum vanstembus heeft ten opzichte van vertegenwoordigers op datmoment in tijd, ze in staat zouden zijn om de stem-beslissingop de node te laten oscilleren. Als deze nieuwe gebruikerwilde communiceren met alle andere aanvallers, zouden alhun transacties genegeerd worden omdat ze verschillendehoofdblokken hebben. Het netto resultaat is dat nodes de tijdvan nieuwe nodes in het netwerk kunnen verspillen door henslechte informatie te geven. Om dit te voorkomen, kunnennodes worden gekoppeld aan een eerste database met accountsen bekende goede blok koppen; dit is een vervanging voorhet downloaden van de database helemaal terug naar hetgenesisblok. Hoe dichter de download is, hoe hoger de kans opeen nauwkeurige verdediging tegen deze aanval. Uiteindelijkis deze aanval waarschijnlijk niet slechter dan het voeden vanongewenste gegevens aan nodes die bootstrappen, omdat zeniet in staat zouden zijn om transacties met iemand met eenhedendaagse database uit te voeren.

VI. IMPLEMENTATIE

Momenteel is de referentie-implementatie geımplementeerdin C++ en zijn er releases uitgebracht op GitHub sinds 2014[10].

A. Ontwerp Kenmerken

De RaiBlocks implementatie houdt zich aan de architec-tuurstandaard die geschetst is in deze paper. Aanvullendespecificaties worden hier beschreven.

1) Ondertekenings Algoritme: RaiBlocks gebruikt eenaangepast ED25519 elliptic curve algoritme met Blake2b hash-ing voor alle digitale ondertekeningen [11]. Er is gekozen voorED25519 vanwege snelle ondertekening, snelle verificatie, eneen hoge mate van beveiliging.

2) Hashing Algoritme: Aangezien het hashing algoritmealleen wordt gebruikt om netwerk spam tegen te gaan, is dekeuze voor het algoritme minder belangrijk vergeleken metop mining gebaseerde cryptocurrencies. Onze implementatiegebruikt Blake2b als een digest algoritme tegen blokinhoud[12].

3) Sleutel Afleidings Functie: In de referentieportefeuilleworden sleutels gecodeerd met een wachtwoord en wordt hetwachtwoord door een sleutelafleidingsfunctie geleid om hette beschermen tegen pogingen tot ASIC-cracking. Momenteelis Argon2 [13] de winnaar van de enige publieke competitiegericht op het creeren van een veerkrachtige sleutelafleidings-functie.

4) Blok Interval: Omdat elk account zijn eigen blockchainheeft, kunnen updates asynchroon worden uitgevoerd naarhet netwerk. Daarom zijn er geen blok-intervallen en kunnentransacties direct worden gepubliceerd.

5) UDP Message Protocol: Ons systeem is ontworpen omvoor onbepaalde tijd te werken met behulp van de kleinstmogelijke hoeveelheid computer-hulpbronnen. Alle berichtenin het systeem zijn ontworpen om stateloos te zijn en passen ineen enkel UDP-pakket. Dit maakt het ook gemakkelijker voorlite-peers met intermitterende connectiviteit om deel te nemenaan het netwerk zonder opnieuw korte TCP-verbindingen totstand te brengen. TCP wordt alleen gebruikt voor nieuwe peerswanneer zij de blockchains in bulk willen opstarten.

Nodes kunnen er zeker van zijn dat hun transactie wordtontvangen door het netwerk door transactie-uitzendverkeer vanandere nodes te observeren, omdat verschillende exemplarenzouden moeten worden teruggekaatst naar zichzelf.

B. IPv6 en Multicast

Door te bouwen op verbindingsloze UDP kunnen toekom-stige implementaties IPv6-multicast gebruiken als vervangingvoor traditionele transactiestromingen en stemuitzendingen.Dit zal het verbruik van netwerkbandbreedte verminderen enzal meer beleidsflexibiliteit bieden aan nodes die voorwaartsgaan.

C. Prestaties

Op het moment van schrijven zijn er 4,2 miljoen transactiesverwerkt door het RaiBlocks-netwerk, wat een blockchain-omvang van 1,7 GB heeft opgeleverd. Transactietijden wordengemeten in de orde van seconden. Een huidige referentie-implementatie die werkt op standaard SSD’s kan meer dan10.000 transacties per seconde verwerken, voornamelijk IO-gebonden.

8

VII. BRONVERBRUIK

Dit is een overzicht van bronnen die worden gebruikt dooreen RaiBlocks-node. Daarnaast bespreken we ideeen voor hetverminderen van het gebruik van hulpbronnen voor speci-fieke use-cases. Gereduceerde nodes worden meestal lichte,gesnoeide of vereenvoudigde betalingsverificatie (SPV) nodesgenoemd.

A. NetwerkDe hoeveelheid netwerkactiviteit hangt af van hoeveel het

netwerk bijdraagt aan de gezondheid van een netwerk.1) Representatief: Voor een representatieve node zijn max-

imale netwerkbronnen nodig, aangezien het het stemverkeervan andere vertegenwoordigers waarneemt en zijn eigen stem-men publiceert.

2) Vertrouwd: Een vertrouwde node lijkt op een repre-sentatieve node maar is alleen een waarnemer, het bevatgeen persoonlijke sleutel van een representatief account enpubliceert geen eigen stemmen.

3) Vertrouwend: Een vertrouwende node observeert hetstemmingsverkeer van de ene vertegenwoordiger die hijvertrouwt om een juiste consensus te bereiken. Dit vermindertde hoeveelheid inkomend stemverkeer van vertegenwoordigersdie naar deze nodes gaan.

4) Lichte node: Een lichte node is ook een vertrouwen-snode die alleen verkeer waarneemt voor accounts waarin hetgeınteresseerd is, wat een minimaal netwerkgebruik mogelijkmaakt.

5) Bootstrap: Een bootstrap-node biedt delen van het groot-boek aan aan nodes die zichzelf online brengen. Dit wordtgedaan via een TCP-verbinding in plaats van UDP, omdathet om een grote hoeveelheid gegevens gaat waarvoor gea-vanceerde stroomregeling vereist is.

B. OpslagcapaciteitAfhankelijk van de gebruikerseisen, vereisen verschillende

nodeconfiguraties verschillende opslagvereisten.1) Historisch: Een node die geınteresseerd is in het bi-

jhouden van een volledig historisch overzicht van alle trans-acties, heeft de maximale hoeveelheid opslagruimte nodig.

2) Actueel: Vanwege het ontwerp van het bijhouden vanverzamelde saldi met blokken, hoeven nodes alleen de nieuw-ste of hoofdblokken voor elk account bij te houden om deel tenemen aan consensus. Als een node niet geınteresseerd is inhet bijhouden van een volledige geschiedenis, kan deze ervoorkiezen om alleen de hoofdblokken te behouden.

3) Lichte node: Een lichte node bewaart geen gegevens inhet grootboek en neemt alleen deel aan het netwerk om ac-tiviteiten te observeren op accounts waarin het geınteresseerdis of om optioneel nieuwe transacties te maken metprivesleutels die het bevat.

C. CPU1) Transactie Genererend: Een node dat geınteresseerd

is in het maken van nieuwe transacties moet een bewijsvan nonce produceren om het throttling-mechanisme vanRaiBlocks te doorstaan. Een referentiekader van verschillendehardware is te vinden in Bijlage A.

2) Vertegenwoordiger: Een vertegenwoordiger moethandtekeningen verifieren voor blokken, stemmen en ookzijn eigen handtekeningen produceren om deel te nemenaan consensus. De hoeveelheid CPU-bronnen voor derepresentatieve node is aanzienlijk minder dan die voor hetgenereren van transacties en zou moeten werken met elkeafzonderlijke CPU in een moderne computer.

3) Waarnemers-node: Een waarnemers-node genereertgeen eigen stemmen. Aangezien de overhead van dehandtekeninggeneratie minimaal is, zijn de CPU-vereistenvrijwel identiek aan het uitvoeren van een representatievenode.

VIII. CONCLUSIE

In deze paper hebben we een framework besproken vooreen gedistribueerd cryptocurrency netwerk met hoge snelheiden zonder kosten, dat gebruik maakt van een nieuwe block-lattice structuur en delegated Proof of Stake stemming. Hetnetwerk vereist minimale middelen, geen mining hardwaremet hoog energieverbruik, en kan een hoge doorvoer vantransacties verwerken. Dit wordt bereikt door individueleblockchains voor ieder account, waardoor toegangsproble-men en inefficienties van een globale datastructuur wordengeelimineerd. We hebben mogelijke aanvalsvectoren op hetsysteem geıdentificeerd en bespraken argumenten over hoeRaiBlocks resistent is tegen deze vormen van aanvallen.

APPENDIX APOW HARDWARE REFERENTIEKADER

Zoals eerder vermeld is de PoW in RaiBlocks om netwerkspam te verminderen. Onze node implementatie biedt ver-snelling die kan profiteren van OpenCL compatibele GPUs.Tabel I verstrekt een actueel referentiekader van verschillendehardware. Momenteel is de PoW-drempel vaststaand, maareen adaptieve drempel zou geımplementeerd kunnen wordennaarmate de gemiddelde rekenkracht van computers toeneemt.

TABEL IHARDWARE POW PRESTATIES

Apparaat Transacties Per SecondeNvidia Tesla V100 (AWS) 6.4Nvidia Tesla P100 (Google,Cloud) 4.9Nvidia Tesla K80 (Google,Cloud) 1.64AMD RX 470 OC 1.59Nvidia GTX 1060 3GB 1.25Intel Core i7 4790K AVX2 0.33Intel Core i7 4790K,WebAssembly (Firefox) 0.14Google Cloud 4 vCores 0.14-0.16ARM64 server 4 cores (Scaleway) 0.05-0.07

DANKWOORD

We willen Brian Pugh bedanken voor het compileren enformatteren van deze paper.

9

REFERENTIES

[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[Online]. Available: http://bitcoin.org/bitcoin.pdf

[2] “Bitcoin median transaction fee historical chart.” [Online]. Avail-able: https://bitinfocharts.com/comparison/bitcoin-median transactionfee.html

[3] “Bitcoin average confirmation time.” [Online]. Available: https://blockchain.info/charts/avg-confirmation-time

[4] “Bitcoin energy consumption index.” [Online]. Available: https://digiconomist.net/bitcoin-energy-consumption

[5] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency withproof-of-stake,” 2012. [Online]. Available: https://peercoin.net/assets/paper/peercoin-paper.pdf

[6] C. LeMahieu, “Raiblocks distributed ledger network,” 2014.[7] Y. Ribero and D. Raissar, “Dagcoin whitepaper,” 2015.[8] S. Popov, “The tangle,” 2016.[9] A. Back, “Hashcash - a denial of service counter-measure,” 2002.

[Online]. Available: http://www.hashcash.org/papers/hashcash.pdf[10] C. LeMahieu, “Raiblocks,” 2014. [Online]. Available: https://github.

com/clemahieu/raiblocks[11] D. J. Bernstein, N. Duif, T. Lange, P. Shwabe, and B.-Y. Yang,

“High-speed high-security signatures,” 2011. [Online]. Available:http://ed25519.cr.yp.to/ed25519-20110926.pdf

[12] J.-P. Aumasson, S. Neves, Z. Wilcox-O’Hearn, and C. Winnerlein,“Blake2: Simpler, smaller, fast as md5,” 2012. [Online]. Available:https://blake2.net/blake2.pdf

[13] A. Biryukov, D. Dinu, and D. Khovratovich, “Argon2: The memory-hard function for password hashing and other applications,” 2015.[Online]. Available: https://password-hashing.net/argon2-specs.pdf