1

RaiBlocks: Ein gebuhrenfreies verteiltesKryptowahrungsnetzwerk

Colin LeMahieuclemahieu@gmail.com

Ubersicht—In letzter Zeit haben ein hoher Bedarfund beschrankte Skalierbarkeit zu einer Erhohung derdurchschnittlichen Transaktionszeiten und Gebuhren beliebterKrptowahrungen gefuhrt, was in einem unbefriedigendenNutzungserlebnis resultierte. In diesem Whitepaper stellenwir RaiBlocks vor, eine Kryptowahrung mit einer neuartigenBlockgitter-Architektur, in der jedes Konto uber seineeigene Blockchain verfugt. Dadurch werden nahezu sofortigeTransaktionen und unbeschrankte Skalierbarkeit ermoglicht.Jeder Nutzer verfugt uber seine eigene Blockchain, die erasynchron zum restlichen Netzwerk aktualisieren kann, was zuschnellen Transaktionen mit minimalem Mehraufwand fuhrt.Transaktionen uberwachen anstelle von Transaktionsbetragendas verbleibende Konto-Guthaben, was eine aggressiveDatenbankreinigung ohne Abstriche bei der Sicherheitermoglicht. Zum gegenwartigen Zeitpunkt hat das RaiBlocks-Netzwerk bereits 4,2 Millionen Transaktionen verarbeitet, beieiner unbereinigten Ledgergroße von nur 1,7 GB. RaiBlocksgebuhrenfreie, sekundenschnelle Transaktionen machen es zurprimaren Kryptowahrung fur Verbrauchertransaktionen.

Index-Begriffe—Kryptowahrung, Blockchain, Raiblocks,Distributed-Ledger, Digital, Transaktionen

I. EINFUHRUNG

SEIT der Implementierung von Bitcoin im Jahre 2009,gab es einen zunehmenden Ubergang von traditionellen,

staatlich unterstutzten Wahrungen und Finanzsystemen zumodernen, kryptografischen Zahlungsmethoden, die eine ver-trauensfreie und sichere Aufbewahrung und Uberweisung vonGeldmitteln ermoglichen [1]. Um effektiv funktionieren zukonnen, muss eine Wahrung einfach zu uberweisen undunumkehrbar sein, und darf uber keine oder nur beschrankteGebuhren verfugen. Die erhohten Transaktionszeiten, hohenGebuhren und die ungewisse Skalierbarkeit seines Netzwerkswarfen Fragen zur Tauglichkeit von Bitcoin als eine Wahrungfur den alltaglichen Gebrauch auf.

In diesem Papier stellen wir RaiBlocks vor, eineNiedriglatenz-Kryptowahrung, die auf einer innovativenBlockgitter-Datenstruktur entwickelt wurde und sich durchuneingeschrankte Skalierbarkeit und Gebuhrenfreiheit ausze-ichnet. Per Design handelt es sich bei RaiBlocks umein einfaches Protokoll mit dem alleinigen Zweck, alseine Hochleistungskryptowahrung zu funktionieren. DasRaiBlocks-Protokoll kann auf Niedrigstrom-Hardware aus-gefuhrt werden, was es zu einer praktischen, dezentralisiertenKryptowahrung fur den Alltag macht.

Die in diesem Papier zitierten Kryptowahrungsstatistikenwaren zum Veroffentlichungszeitpunkt wahrheitsgetreu.

II. HINTERGRUND

2008 veroffentlichte eine anonyme Person unter demPseudonym Satoshi Nakamoto ein Whitepaper, in demdie weltweit erste dezentralisierte Kryptowahrung, Bitcoin,beschrieben wurde [1]. Eine der wichtigsten Innovationen,die mit Bitcoin eingefuhrt wurde, war die Blockchain – eineoffentliche, unveranderliche und dezentralisierte Datenstruktur,die als ein Ledger (Kontobuch) fur die Transaktionen derWahrung benutzt wird. Leider traten im Laufe der weit-eren Entwicklung von Bitcoin diverse Probleme innerhalbdes Protokolls auf, die Bitcoin fur viele Anwendungszweckeunbrauchbar gemacht haben:

1) Schlechte Skalierbarkeit: Jeder Block in der Blockchainkann nur eine beschrankte Menge an Daten speichern,was bedeutet, dass das System nur eine bestimmteAnzahl an Transaktionen pro Sekunde verarbeiten kann,wodurch der Platz innerhalb eines Blocks zu einerWare wird. Momentan betragt die mediane Transaktion-sgebuhr $10,38 [2].

2) Hohe Latenz: Die durchschnittliche Bestatigungszeitbetragt 164 Minuten [3].

3) Ineffizienter Stromverbrauch: Das Bitcoin-Netzwerkverbraucht geschatzt 27,28 TWh pro Jahr, wobei imDurchschnitt 260 KWh pro Transaktion verbraucht wer-den [4].

Bitcoin, ebenso wie andere Kryptowahrungen, funktion-iert durch das Erreichen eines Konsens auf seinem globalenLedger, um so legitime Transaktionen zu verifizieren undboswillige Akteure abzuwehren. Bitcoin erreicht den Kon-sens mit Hilfe einer okonomischen Maßnahme namens Proofof Work (PoW). In einem PoW-System konkurrieren dieTeilnehmer um die Berechnung einer Zahl namens Nonce,so dass der Hash eines gesamten Blocks sich im Zielspek-trum befindet. Dieses gultige Spektrum ist umgekehrt pro-portional zur kumulativen Rechenkraft des gesamten Bitcoin-Netzwerks, um eine konsistente Durchschnittszeit zur Ent-deckung einer gultigen Nonce zu gewahrleisten. Der Findereiner gultigen Nonce darf anschließend den Block zurBlockchain hinzufugen; daher spielen Teilnehmer, die mehrRechenkraft zur Berechnung einer Nonce aufwenden, einegroßere Rolle fur den Status der Blockchain. PoW bietetWiderstand gegen eine Sybil-Attacke, bei der eine Entitat sichals mehrere Entitaten ausgibt, um in einem dezentralisiertenSystem mehr Macht zu gewinnen, und reduziert auch sig-nifikant die Race Conditions (Wettlaufsituationen), die beimZugriff auf eine globale Datenstruktur inharent auftreten.

2

Empfangen Wiederholen Beobachten Quorum Bestatigen

(a) Wenn kein Konflikt erkannt wird, ist kein weiterer Mehraufwand erforderlich.

Empfangen Wiederholen Beobachten Konflikt Wahlen Bestatigen

(b) Im Falle einer widerspruchlichen Transaktion, wahlen die Knoten die gultige Transaktion.Abb. 1. RaiBlocks erfordert fur typische Transaktionen keinen zusatzlichen Mehraufwand. Bei widerspruchlichen Transaktionen, mussen die Knoten dieTransaktion wahlen, die beibehalten werden soll.

Ein alternatives Konsensprotokoll, Proof of Stake (PoS),wurde 2012 durch Peercoin eingefuhrt [5]. In einem PoS-System stimmen die Teilnehmer mit dem Gewichtsaquivalentder Geldmenge ab, die sie in einer bestimmten Kryp-towahrung besitzen. Bei diesem Arrangement erhalten Teil-nehmer mit einer großeren finanziellen Investition mehr Machtund verfugen uber einen inharenten Anreiz, die Ehrlichkeit desSystems aufrecht zu erhalten, um nicht dem Risiko ausgesetztzu sein, ihre Investition zu verlieren. PoS beseitigt den ver-schwenderischen Konkurrenzkampf um Rechenleistung underfordert nur leichtgewichtige Software, die auf Niedrigstrom-Hardware betrieben werden kann.

Das ursprungliche RaiBlocks-Papier und die erste Beta-Implementierung wurden im Dezember 2014 veroffentlicht,was RaiBlocks zu einer der ersten Kryptowahrungen macht,die auf einem Directed Acyclic Graph (DAG) basieren[6]. Kurz darauf begann die Entwicklung anderer DAG-Kryptowahrungen, allen voran DagCoin/Byteball und IOTA[7], [8]. Diese DAG-basierten Kryptowahrungen brachen mitder Blockchain-Form und verbesserten die Systemleistung undSicherheit. Byteball erreicht einen Konsens, indem es sichauf eine “Hauptkette” verlasst, die aus ehrlichen, angese-henen und von Nutzern vertrauten “Zeugen” besteht, wahrendIOTA seinen Konsens uber ein kumulatives PoW gestapel-ter Transaktionen etabliert. RaiBlocks erreicht einen Kon-sens durch Guthaben-gewichtete Abstimmungen zu wider-spruchlichen Transaktionen. Dieses Konsenssystem bietetschnellere, deterministischere Transaktionen, wahrend es nachwie vor ein starkes, dezentralisiertes System gewahrleistet.RaiBlocks setzt diese Entwicklung weiter fort und hat sichals eine der leistungsstarksten Kryptowahrungen positioniert.

III. RAIBLOCKS-KOMPONENTEN

Bevor wir die gesamte RaiBlocks-Architektur beschreiben,definieren wir zunachst die individuellen Komponenten, ausdenen das System sich zusammensetzt.

A. Konto

Ein Konto ist die Public-Key-Halfte eines digitalenSignaturschlusselpaars. Der Public-Key, auch bekannt alsAdresse, wird mit anderen Netzwerk-Teilnehmern geteilt,wahrend der Private-Key geheim gehalten wird. Ein digitalsigniertes Datenpaket garantiert, dass die Inhalte vom Inhaberdes Private-Keys genehmigt wurden. Ein Nutzer kann vieleKonten besitzen, aber es kann nur eine offentliche Adressepro Konto existieren.

B. Block/Transaktion

Die Begriffe “Block” und “Transaktion” werden oft aus-tauschbar verwendet, wobei ein Block eine einzelne Transak-tion beinhaltet. “Transaktion” bezieht sich speziell auf dieHandlung, wahrend “Block” die digitale Verschlusselungder Transaktion bezeichnet. Transaktionen werden mit demPrivate-Key signiert, der zum Konto gehort, auf dem dieTransaktion durchgefuhrt wird.

C. Ledger

Der Ledger ist das globale Kontenbuch, worin jedesKonto uber eine eigene Transaktionskette verfugt (Abbil-dung 2). Dies ist eine zentrale Designkomponente, die denErsatz einer Laufzeit-Vereinbarung mit einer Designzeit-Vereinbarung darstellt; alle Teilnehmer stimmen uber dieSignaturprufung zu, dass nur der Kontoinhaber seine eigeneKette modifizieren kann. Dadurch wird eine scheinbar geteilteDatenstruktur, ein Distributed-Ledger, in eine Reihe vonungeteilten Datenstrukturen konvertiert.

D. Knoten

Ein Knoten ist eine Software, die auf einem Computerausgefuhrt wird, dem RaiBlocks-Protokoll entspricht und sicham RaiBlocks-Netzwerk beteiligt. Die Software verwaltet denLedger und alle Konten, die der Knoten kontrolliert (fallsvorhanden). Ein Knoten kann entweder den gesamten Ledger

Konto ABlock NA

Konto ABlock NA − 1

...

Konto ABlock 1

Konto ABlock 0

Konto BBlock NB

Konto BBlock NB − 1

...

Konto BBlock 1

Konto BBlock 0

Konto CBlock NC

Konto CBlock NC − 1

...

Konto CBlock 1

Konto CBlock 0

Abb. 2. Jedes Konto verfugt uber seine eigene Blockchain, die den Guthaben-Verlauf des Kontos enthalt. Block 0 muss eine offene Transaktion sein(Section IV-B)

3

oder einen gereinigten Verlauf speichern, der nur die letztenBlocks der Blockchain jedes Kontos enthalt. Bei der Ein-richtung eines neuen Knotens wird empfohlen, den gesamtenVerlauf zu verifizieren und lokal zu reinigen.

IV. SYSTEMUBERSICHT

Im Gegensatz zu den Blockchains vieler anderer Kryp-towahrungen, verwendet RaiBlocks eine Blockgitter-Struktur.Jedes Konto verfugt uber seine eigene Blockchain (Kon-tokette), die dem Transaktions-/Guthabenverlauf des Kontosentspricht (Abbildung 2). Jede Kontokette kann nur vomKonto-Inhaber aktualisiert werden; dadurch lasst sich jedeKontokette sofort und asynchron zum Rest des Blockgittersaktualisieren, was schnelle Transaktionen ermoglicht. DasRaiBlocks-Protokoll ist extrem leichtgewichtig; jede Transak-tion passt in die minimale, fur die Internet-Ubertragungerforderliche UDP-Paketgroße. Die Hardware-Anforderungenfur Knoten sind ebenfalls minimal, da Knoten fur die meistenTransaktionen lediglich Blocks aufzeichnen und erneut sendenmussen (Abbildung 1).

Das System wird mit einem Genesis-Konto initiiert, in demdas Genesis-Guthaben enthalten ist. Das Genesis-Guthaben istein Fixbetrag und kann niemals erhoht werden. Das Genesis-Guthaben wird aufgeteilt und uber die Sende-Transaktionen,die auf der Genesis-Kontokette registriert sind, an andereKonten gesendet. Die Guthaben-Summe auf allen Kontenwird niemals das anfangliche Genesis-Guthaben uberschreiten,wodurch das System eine Quantitatsschranke erhalt, die nichterhoht werden kann.

Dieser Abschnitt behandelt, wie unterschiedliche Transak-tionsarten konstruiert und innerhalb des Netzwerks propagiertwerden.

A B C

S

E

E

E

S

E

E

S

S

S

......

...

Zei

t

Abb. 3. Visualisierung des Blockgitters. Jede Uberweisung erfordert einenSendeblock (S) und einen Empfangsblock (E), von denen jeder vom jeweiligenEigentumer der Kontokette signiert werden muss (A,B,C).

A. Transaktionen

Fur Uberweisungen von einem Konto an ein anderes Kontowerden zwei Transaktionen benotigt: eine Sendetransaktion,die den entsprechenden Betrag vom Guthaben des Sendersabzieht, und eine Empfangstransaktion, die den Betrag zumGuthaben des Empfangerkontos addiert (Figure 3).

Die Uberweisung von Betragen als separate Transaktionenin den Konten des Senders und Empfangers erfullt einigewichtige Funktionen:

1) Sequenzierung eingehender Uberweisungen, dieinharent asynchron sind.

2) Kleinhaltung von Transaktionen, damit diese in UDP-Pakete passen.

3) Erleichterung der Ledgerreinigung durch Minimierungdes Datenfußabdrucks.

4) Isolierung abgeschlossener und ausstehender Transaktio-nen.

Wenn von mehr als einem Konto an die selbe Zieladresseuberwiesen wird, handelt es sich dabei um eine asyn-chrone Operation; Netzwerklatenz und die Tatsache, dassdie Sendekonten nicht zwangslaufig mit einander kommu-nizieren, haben zur Folge, dass es keine universal akzept-able Methode gibt, zu wissen, welche Transaktion zuerststattgefunden hat. Da die Addition assoziativ ist, spielt dieReihenfolge der Eingaben keine Rolle, weshalb lediglich eineglobale Ubereinstimmung benotigt wird. Dies ist eine zentraleDesignkomponente, die eine Laufzeit-Vereinbarung in eineDesignzeit-Vereinbarung konvertiert. Das Empfangerkonto hatdie Kontrolle daruber, zu entscheiden, welche Uberweisungzuerst ankam. Dies wird durch die signierte Reihenfolge dereingehenden Blocke ausgedruckt.

Falls ein Konto eine große Uberweisung senden mochte, dieals eine Reihe kleinerer Uberweisungen ankommt, wollen wirdies auf eine Weise ausdrucken, die in ein UDP-Paket hinein-passt. Wenn ein Empfangerkonto Eingabeuberweisungen ineiner Reihenfolge anordnet, behalt es eine laufende Summeseines Kontostandes bei, so dass es jederzeit einen Betrag miteiner fixen Transaktionsgroße uberweisen kann. Dies unter-scheidet sich vom Eingabe-/Ausgabe-Transaktionsmodell, dasvon Bitcoin und anderen Kryptowarungen verwendet wird.

Einige Knoten sind nicht daran interessiert, Ressourcen zuverbrauchen, um den vollen Transaktionsverlauf eines Kontoszu speichern; sie interessieren sich nur fur das gegenwartigeGuthaben jedes Kontos. Wenn ein Konto eine Transaktiondurchfuhrt, verschlusselt es sein kumuliertes Guthaben, so dassdiese Knoten lediglich den letzten Block uberwachen mussen.Dadurch konnen sie historische Daten verwerfen und trotzdemkorrekt bleiben.

Selbst mit dem Schwerpunkt auf Designzeit-Vereinbarungen, gibt es bei der Validierung von Transaktionenein Verzogerungsfenster, um boswillige Akteure imNetzwerk zu identifizieren und zu bekampfen. DaVereinbarungen in RaiBlocks schnell zustande kommen(innerhalb von Millisekunden bis Sekunden), konnenwir dem Nutzer zwei vertraute Kategorien eingehenderTransaktionen prasentieren: Abgeschlossen und ausstehend.Transaktionen sind abgeschlossen, wenn ein Konto bereits

4

Empfangsblocke generiert hat. Transaktionen sind ausstehend,wenn sie noch nicht zum kumulativen Guthaben desEmpfangers addiert wurden. Dies ist ein Ersatz fur diekomplexeren und unvertrauteren Bestatigungsmetrikenanderer Kryptowahrungen.

B. Ein Konto erstellen

Um ein Konto zu erstellen, muss eine offene Transaktionerstellt werden (Abbildung 4). Eine offene Transaktion istimmer die erste Transaktion jeder Kontokette und kann beimersten Empfang einer Einzahlung erstellt werden. Das Feldaccount speichert den Public-Key (die Adresse), der aus demPrivate-Key generiert wird, welcher zur Signierung dient. DasFeld source enthalt den Hash der Transaktion, uber welche dieZahlung gesendet wurde. Bei der Erstellung eines Kontos mussein Vertreter gewahlt werden, der im Namen dieses Kontosabstimmen soll; dies kann nachtraglich geandert werden (Ab-schnitt IV-F). Das Konto kann sich selbst als seinen eigenenVertreter erklaren.

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

}

Abb. 4. Anatomie einer offenen Transaktion

C. Konto-Guthaben

Das Konto-Guthaben wird im Ledger selbst aufgezeich-net. Anstatt den Betrag einer Transaktion aufzuzeichnen, er-fordert die Verifizierung (Abschnitt IV-I) eine Uberprufungder Differenz zwischen dem Guthaben des Sendeblocksund dem Guthaben des vorangegangenen Blocks. DasEmpfangerkonto kann anschließend das vorherige Guthaben inUbereinstimmung mit dem errechneten Endguthaben erhohen,das im neuen Empfangsblock enthalten ist. Dies dient zurErhohung der Geschwindigkeit beim Herunterladen von hohenBlockvolumen. Bei der Abfrage des Kontoverlaufs sind dieBetrage bereits enthalten.

D. Von einem Konto senden

Um von einer Adresse senden zu konnen, muss die Adressebereits uber einen bestehenden offenen Block und ergo uberein Guthaben verfugen (Abbildung 5). Das Feld previousenthalt den Hash des vorherigen Blocks in der Kontokette. DasFeld destination enthalt das Konto, an das Geld uberwiesenwerden soll. Ein Sendeblock kann nachdem er bestatigt wurdenicht verandert werden. Sobald es an das Netzwerk ubertragenwird, wird das Geld sofort vom Guthaben des Sendekontosabgezogen und als pending (ausstehend) behandelt werden,bis der Empfanger einen Block signiert, um dieses Geld

anzunehmen. Ausstehende Transaktionen warten nicht aufBestatigungen; sie sind auf dem Konto des Senders praktischverbraucht und der Sender kann die Transaktion nicht wider-rufen.

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

}

Abb. 5. Anatomie einer Sendetransaktion

E. Eine Transaktion erhalten

Um eine Transaktion abzuschließen, muss der Empfangerdes uberwiesenen Geldes einen Empfangsblock auf seinereigenen Kontokette erstellen (Abbildung 6). Das Feld “Quelle”bezieht sich auf den Hash der entsprechenden Sendetransak-tion. Sobald dieser Block erstellt und ubertragen wird, wird dasGuthaben des Kontos aktualisiert und das uberwiesene Geldoffiziell diesem Konto gutgeschrieben.

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

}

Abb. 6. Anatomie einer Empfangstransaktion

F. Einen Vertreter einsetzen

Die Fahigkeit von Kontoinhabern, einen Vertreter zuwahlen, der in ihrem Namen wahlen kann, ist einleistungsstarkes Dezentralisierungswerkzeug, das uber keinebenburtiges Analog in den Proof of Work und Proof ofStake Protokollen verfugt. In konventionellen PoS-Systemen,muss der Knoten des Kontoinhabers aktiv sein, um wahlen zukonnen. Das kontinuierliche Betreiben eines Knotens ist furviele Nutzer unpraktisch; die Ubertragung des Stimmrechtsan einen Vertreter lockert diese Voraussetzung. Kontoinhaberverfugen uber die Fahigkeit, den Konsens jederzeit einem an-deren Konto zuzuweisen. Eine Wechseln-Transaktion wechseltden Vertreter eines Kontos, indem das Stimmgewicht vomalten Vertreter abgezogen und dem neuen Vertreter zugewiesenwird (Abbildung 7). Bei dieser Transaktion wird kein Geldubertragen und der Vertreter verfugt nicht uber das Recht, dasGuthaben des Kontos auszugeben.

5

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

}

Abb. 7. Anatomie einer Wechseln-Transaktion

G. Forks und Abstimmungen

Ein Fork ereignet sich, wenn j signierte Blockeb1, b2, . . . , bj den selben Block als ihren Vorganger ansehen(Abbildung 8). Diese Blocke erzeugen eine widerspruchlicheAnsicht zum Status eines Kontos, die gelost werden muss.Nur der Inhaber eines Kontos ist in der Lage, Blocke in ihreKontokette zu signieren, daher muss ein Fork zwangslaufigaus schlechter Programmierung oder der boswilligen Absicht(doppelte Ausgabe) des Kontoinhabers entstehen.

Konto ABlock i

Konto ABlock i+ 1

Konto ABlock i+ 2

Konto ABlock i+ 2

Abb. 8. Ein Fork entsteht, wenn zwei (oder mehr) signierte Blocke den selbenvorangegangenen Block referenzieren. Altere Blocke sind links; neuere Blockesind rechts.

Nach der Erkennung eines Forks, erstellt ein Vertreter inseinem Ledger eine Abstimmung zum Block bi und sendetdiese an das Netzwerk. Das Stimmgewicht eines Knotens,wi, ist die Summe der Guthaben aller Konten, die ihn alsVertreter ernannt haben. Der Knoten beobachtet die eingehen-den Stimmen der anderen M Online-Vertreter und fuhrt einekumulative Aufzahlung fur 4 Abstimmungszeitraume durch(Gesamtdauer von 1 Minute), anschließend bestatigt er denBlock, der gewonnen hat (Gleichung 1).

v(bj) =

M∑i=1

wi1bi=bj(1)

b∗ = argmaxbj

v(bj) (2)

Der beliebteste Block b∗ wird die meisten Stimmen erhaltenund im Ledger des Knotens gespeichert werden (Gleichung 2).Die Blocke, die die Abstimmung verlieren, werden entsorgt.Falls ein Vertreter einen Block in seinem Ledger ersetzt,erstellt er eine neue Abstimmung mit einer hoheren Sequen-znummer und sendet die neue Abstimmung an das Netzwerk.Dies ist das einzige Szenario, bei dem Vertreter abstimmen.

Unter einigen Umstanden konnen kurze Netzwerk-Verbindungsstorungen dazu fuhren, dass ein gesendeter Blocknicht von allen Peers akzeptiert wird. Alle folgenden Blockeauf diesem Konto werden von Peers, die die ursprungliche

Ubertragung nicht gesehen haben, als ungultig angesehenund ignoriert. Eine erneute Ubertragung dieses Blocks wirdvon den verbleibenden Peers akzeptiert werden und allenachfolgenden Blocke werden automatisch abgerufen. Selbstwenn ein Fork oder fehlender Block sich ereignet, sinddavon nur die Konten betroffen, die in der entsprechendenTransaktion referenziert werden; der Rest des Netzwerksverarbeitet weiterhin die Transaktionen aller anderen Konten.

H. Proof of Work

Alle vier Transaktionsarten haben einen Arbeitsbereich, derkorrekt ausgefullt werden muss. Der Arbeitsbereich ermoglichtes dem Transaktionsersteller, eine Nonce zu berechnen, sodass der Hash der Nonce, die mit dem vorherigen Bereichin der Empfangen-/Senden-/Wechseln-Transaktion oder demKontobereich in einer offenen Transaktion verkettet ist, einenbestimmten Schwellwert nicht ubersteigt. Im Gegensatz zuBitcoin wird das RaiBlocks-PoW lediglich als ein Anti-Spam-Werkzeug benutzt (ahnlich wie bei Hashcash) und kann inner-halb von Sekunden berechnet werden [9]. Sobald eine Transak-tion gesendet wird, kann das PoW fur den folgenden Blockvorberechnet werden, da der vorangegangene Blockbereichbekannt ist; auf diese Weise erscheinen Transaktionen fur denEndnutzer sofort, so lange die Zeit zwischen Transaktionengroßer ist, als die Zeit, die zur Berechnung des PoW benotigtwird.

I. Transaktionsverifizierung

Damit ein Block als gultig betrachtet wird, muss er uber diefolgenden Eigenschaften verfugen:

1) Der Block darf noch nicht im Ledger sein (doppelteTransaktion).

2) Der Block muss vom Kontoinhaber signiert sein.3) Der vorherige Block ist der Kopfblock der Kontokette.

Falls der Block existiert, aber nicht der Kopfblock ist,handelt es sich um einen Fork.

4) Das Konto muss uber einen offenen Block verfugen.5) Der berechnete Hash erfullt die PoW-

Schwellwertbedingung.

Falls es sich um einen Empfangsblock handelt, muss gepruftwerden, ob der Quellblock-Hash ausstehend ist, was bedeutet,dass er noch nicht eingelost wurde. Falls es sich um einenSendeblock handelt, muss das Guthaben großer sein als dasvorherige Guthaben.

V. ANGRIFFSFLACHEN

So wie andere dezentralisierte Kryptowahrungen, ist auchRaiBlocks dem Risiko eines Angriffs durch boswilligeParteien ausgesetzt, die sich finanziellen Gewinn erhoffen oderdas System zerstoren mochten. In diesem Bereich schildernwir einige mogliche Angriffsszenarien, die Konsequenzensolcher Angriffe, und die Praventivmaßnahmen des RaiBlocks-Prokolls.

6

A. Blocklucken-Synchronisierung

Im Abschnitt IV-G, haben wir ein Szenario diskutiert, indem ein Block nicht ordnungsgemaß ubertragen wird, was dasNetzwerk dazu veranlasst, nachfolgende Blocke zu ignorieren.Falls ein Knoten einen Block erkennt, der nicht uber denreferenzierten vorherigen Block verfugt, hat der Knoten zweiOptionen:

1) Den Block ignorieren, da er ein schadlicher Abfallblocksein konnte.

2) Resynchronisierung mit einem anderen Knoten beantra-gen.

Im Falle einer Resynchronisierung, muss eine TCP-Verbindung mit einem Bootstrapping-Knoten hergestellt wer-den, um den erhohten Datenverkehr abzudecken, der mit einerResynchronisierung einhergeht. Falls es sich bei dem Blockallerdings um einen boswilligen Block gehandelt hat, war dieResynchronisierung nicht erforderlich und hat unnotig denDatenverkehr im Netzwerk erhoht. Hierbei handelt es sich umeinen Netzwerk-Verstarkungsangriff, welcher zu einem Denialof Service fuhrt.

Um eine unnotige Resynchronisierung zu vermeiden, wartenKnoten ab, bis ein bestimmter Schwellwert an Stimmen fureinen moglicherweise boswilligen Block erreicht wird, bevorsie eine Verbindung mit einem Bootstrap-Knoten herstellenund die Synchronisierung einleiten. Falls ein Block nichtgenug Stimmen erhalt, ist anzunehmen, dass es sich dabei umJunk-Daten handelt.

B. Transaktionsuberflutung

Ein boswilliger Akteur konnte viele unnotige aber den-noch gultige Transaktionen zwischen von ihm kontrolliertenKonten veranlassen, um zu versuchen, so das Netzwerk zuuberlasten. Ohne Transaktionsgebuhren kann dieser Angriffendlos fortgesetzt werden. Allerdings beschrankt das fur jedeTransaktion erforderliche PoW die Transaktionsrate, die vonder boswilligen Partei generiert werden kann, ohne signifikantin Rechenleistung zu investieren. Selbst unter einem solchenAngriff, bei dem versucht wird, den Ledger zu uberlasten,konnen Knoten, welche nicht den vollstandigen Verlauf spe-ichern, alte Transaktionen einfach aus ihrer Kette reinigen;dadurch wird die Speicherauslastung durch einen solchenAngriff fur nahezu alle Nutzer eingeschrankt.

C. Sybil-Attacke

Eine Partei konnte Hunderte von RaiBlocks-Knoten aufeinem einzigen Gerat erstellen; da das Abstimmungssystemallerdings anhand des Konto-Guthabens gewichtet wird, erhaltder Angreifer durch zusatzliche Knoten in einem Netzwerkkeine zusatzlichen Stimmen. Aus diesem Grund ist es nichtmoglich, sich durch eine Sybil-Attacke einen Vorteil zu ver-schaffen.

D. Penny-Spend-Attacke

Bei einer Penny-Spend-Attacke ladt ein Angreifer dieGuthaben einer großen Anzahl von Konten mit Kleinst-betragen auf, um die Speicherressourcen der Knoten zu

verschwenden. Die Blockveroffentlichungsrate ist durch dasPoW beschrankt, daher ist die Erstellung von Konten undTransaktionen zu einem gewissen Maß eingeschrankt. Knoten,die nicht den vollen Verlauf speichern, konnen Konten unter-halb einer statistischen Metrik reinigen, unter der ein Kontoaller Wahrscheinlichkeit nach unauthentisch ist. Daruber hin-aus ist RaiBlocks darauf ausgerichtet, minimalen Speicher-platz zu verbrauchen, daher ist der Speicher, der fur einzusatzliches Konto benotigt wird, proportional zur Große einesoffenen Blocks + Indexierung = 96B + 32B = 128B. Dasbedeutet, dass in 1GB Speicher 8 Millionen Penny-Spend-Kontos gespeichert werden konnen. Falls Knoten eine ag-gressivere Reinigung vornehmen wollen, konnen sie eine aufZugriffshaufigkeit basierte Verteilung berechnen und seltengenutzte Konten in den langsameren Speicher delegieren.

E. Vorberechnete PoW-Attacke

Da der Inhaber eines Kontos die einzige Entitat ist, dieBlocke zur Kontokette hinzufugen kann, ist es moglich, se-quentielle Blocke und ihr PoW zu berechnen, bevor sie an dasNetzwerk ubertragen werden. Hierbei erstellt der Angreiferuber einen langeren Zeitraum eine Unmenge an sequentiellenBlocken, von denen jeder von minimalem Wert ist. Ab einembestimmten Punkt fuhrt der Angreifer einen Denial of Service(DoS) durch, indem er das Netzwerk mit vielen gultigenTransaktionen uberflutet, die von anderen Knoten so schnellwie moglich verarbeitet und wiederholt werden. Dies ist einefortgeschrittene Version der in Abschnitt V-B beschriebe-nen Transaktionsuberflutung. Ein solcher Angriff wurde nurkurzzeitig funktionieren, konnte aber in Kombination mitanderen Angriffen wie der >50% Attacke (Abschnitt V-F)verwendet werden, um die Effektivitat zu erhohen. Momentanwerden Transaktionsratenbeschrankung und andere Technikenerwogen, um diese Angriffe abzuschwachen.

F. >50% Attacke

Die Konsensmetrik fur RaiBlocks ist ein Guthaben-basiertesAbstimmungssystem. Falls ein Angreifer mehr als 50% derStimmstarke erreichen kann, ist er in der Lage, einen Kon-sensumschwung innerhalb des Netzwerks zu bewirken undso das System zu brechen. Ein Angreifer kann das dafuraufzuwendende Guthaben verringern, indem die Beteiligungguter Knoten an der Abstimmung durch ein Netzwerk-DoSverhindert wird. RaiBlocks unternimmt die folgenden Maß-nahmen, um einen solchen Angriff zu verhindern:

1) Die primare Verteidigung gegen diese Angriffsart, istdie Tatsache, dass Stimmgewicht mit Investitionen indas System verbunden ist. Ein Konto-Inhaber verfugtuber einen inharenten Anreiz, die Ehrlichkeit des Sys-tems zu wahren, um seine Investition zu schutzen. EinVersuch, den Ledger zu manipulieren, ware zerstorerischfur das gesamte System und wurde die Investition desAngreifers zerstoren.

2) Die Kosten dieses Angriffs sind proportional zurMarktkapitalisierung von RaiBlocks. In PoW-Systemenkonnen Technologien entwickelt werden, die dispropor-tionale Kontrolle im Vergleich zum investierten Geld

7

zulassen, und im Falle eines erfolgreichen Angriffs,kann diese Technologie zweckentfremdet werden. BeiRaiBlocks skalieren die Kosten eines Angriffs auf dasSystem mit dem System selbst, und falls ein erfolgre-icher Angriff gelingen sollte, kann die Investition in denAngriff nicht zuruckgewonnen werden.

3) Um ein maximales Quorum von Wahlern zugewahrleisten, ist die nachste Verteidigungslinieein reprasentatives Wahlsystem. Konto-Inhaber, diesich aufgrund von Verbindungseinschrankungen nichtregelmaßig an Abstimmungen beteiligen konnen,konnen einen Vertreter ernennen, der mit dem Gewichtihrer Stimmen wahlen kann. Die Maximierungder Anzahl und Vielfalt an Vertretern erhoht dieWiderstandsfahigkeit des Netzwerks.

4) RaiBlocks-Forks passieren niemals zufallig, daherkonnen Knoten sich fur Richtlinien fur den Umgang mitgeforkten Blocken entscheiden. Die einzige Situation, inder Nicht-Angreifer-Konten anfallig fur Blockforks sind,ist, wenn sie ein Guthaben von einem Angreifer-Kontoempfangen. Konten, die vor Blockforks geschutzt seinwollen, konnen eine kurze oder lange Zeit abwarten,bevor sie eine Uberweisung von einem Konto emp-fangen, das Forks generiert hat, oder diese prinzipiellablehnen. Empfanger haben auch die Moglichkeit, sep-arate Konten fur den Empfang von Uberweisungen zuerstellen, die von dubiosen Konten ausgehen, um so ihreanderen Konten zu isolieren.

5) Eine letzte Verteidigungslinie, die noch nicht imple-mentiert wurde, ist Blockzementierung. RaiBlocks un-ternimmt die großtmoglichen Bemuhungen, um geforkteBlocks schnell uber Abstimmungen zu losen. Knotenkonnten konfiguriert werden, um Blocke zu zementieren,was verhindern konnte, dass diese nach einer bes-timmten Zeit zuruckgezogen werden. Das Netzwerk istdurch die Fokussierung auf eine schnelle Abschlusszeitausreichend geschutzt, um mehrdeutige Forks zu ver-meiden.

Eine intelligentere Version des > 50% Angriffs ist inAbbildung 9 geschildert. “Offline” bezeichnet den Prozen-twert der Vertreter, die ernannt wurden, aber nicht onlinesind, um an Abstimmungen teilzunehmen. “Anteil” bezeich-net den Investitionsbetrag, mit dem der Angreifer abstimmt.“Aktiv” bezeichnet die Vertreter, die online sind und inUbereinstimmung mit dem Protokoll wahlen. Ein Angreiferkann den benotigten Anteilsbetrag mindern, indem er andereWahler uber eine Netzwerk-DoS-Attacke offline nimmt. Fallsdiese Attacke gelingt, verlieren die angegriffenen Vertreterihre Synchronisierung, was durch “Unsync” dargestellt wird.Abschließend kann der Angreifer einen kurzen Schub in rela-tiver Stimmstarke erhalten, indem er seine Denial of ServiceAttacke gegen eine andere Reihe an Vertretern richtet, wahrenddie vorherige Reihe dabei ist, ihren Ledger zu resynchro-nisieren. Dies wird durch “Attacke” dargestellt.

Falls ein Angreifer mit Hilfe einer Kombination dieserUmstande Anteil >Aktiv bewirken kann, konnte er erfolgre-ich auf Kosten seines Anteils die Stimmen auf dem Ledger

Offline Unsync Attacke Aktiv Anteil

Abb. 9. Ein mogliches Stimmarrangement, dass die Anforderungen fur eine51% Attacke senken konnte.

umschwingen. Wir konnen einschatzen, wie viel ein Angriffdieser Art kosten wurde, indem wir die Marktkapitalisierunganderer Systeme betrachten. Wenn wir annehmen, dass 33%aller Vertreter offline sind oder per DoS angegriffen werden,musste ein Angreifer 33% der Marktkapitalisierung aufkaufen,um das System per Abstimmungsverfahren anzugreifen.

G. Bootstrap Poisoning

Je langer ein Angreifer einen alten Private-Key mit einemGuthaben behalten kann, desto hoher ist die Wahrschein-lichkeit, dass Konten, die zur selben Zeit existiert haben,uber keine teilnehmenden Vertreter mehr verfugen werden,da ihre Guthaben oder Vertreter an neue Konten ubertragenwurden. Das bedeutet, dass falls ein Knoten an eine alteReprasentation des Netzwerks gebootstrapped ist, in welcherder Angreifer gegenuber den Vertretern, die zu diesem Zeit-punkt existiert haben, uber ein Quorum des Stimmanteilsverfugt, die Entscheidungsgewalt an diesen Knoten ubertragenwerden konnte. Falls dieser neue Nutzer mit jemand anderemals dem Angreiferknoten kommunizieren wollte, wurden allseine Transaktionen abgelehnt werden, da sie uber unter-schiedliche Kopfblocke verfugen. Das Nettoergebnis ist, dassKnoten die Zeit neuer Knoten im Netzwerk verschwendenkonnen, indem sie diese mit schlechten Informationen ver-sorgen. Um dies zu verhindern, konnen Knoten mit derDatenbank der ursprunglichen Knoten und bekannten, gutenBlockkopfen gepaart werden; dies dient als Alternative zumDownloaden der gesamten Datenbank bis zum Genesis-Block.Je aktueller der Download ist, umso großer ist die Wahrschein-lichkeit, vor dieser Attacke geschutzt zu sein. Diese Attackeist letztendlich nicht schlimmer, als beim Bootstrapping Junk-Daten in einen Knoten einzuspeisen, da diese nicht in der Lagewaren, mit anderen Instanzen zu interagieren, die uber eineaktuelle Datenbank verfugen.

VI. IMPLEMENTIERUNG

Die aktuelle Referenzimplementierung verwendet C++ undveroffentlicht seit 2014 Releases auf Github [10].

A. Design-Funktionen

Die RaiBlocks-Implementierung entspricht demArchitektur-Standard, der in diesem Papier dargelegtwurde. Weitere Spezifizierungen werden hier beschrieben.

1) Signatur-Algorithmus: RaiBlocks verwendet einenmodifizierten ED25519 elliptischen Kurvenalgorithmus mitBlake2b-Hashing fur alle digitalen Signaturen [11]. ED25519wurde fur schnelles Signieren, schnelle Verifizierung und einhohes Maß an Sicherheit ausgewahlt.

8

2) Hashing-Algorithmus: Da der Hashing-Algorithmus nurverwendet wird, um Netzwerk-Spam zu vermeiden, ist dieAuswahl des Algorithmus im Vergleich zu Mining-basiertenKryptowahrungen weniger wichtig. Unsere Implementierungverwendet Blake2b als Digest-Algorithmus gegen Blockin-halte [12].

3) Schlussel-Ableitungsfunktion: Im Referenz-Wallet wer-den die Schlussel mit einem Passwort verschlusselt, welchesaus einer Schlussel-Ableitungsfunktion bezogen wird, umgegen ASIC-Cracking-Versuche geschutzt zu sein. Momentanist Argon2 [13] der Gewinner des einzigen offentlichen Wet-tbewerbs zur Entwicklung einer widerstandsfahigen Schlussel-Ableitungsfunktion.

4) Block-Intervall: Da jedes Konto uber seine eigeneBlockchain verfugt, konnen Aktualisierungen asynchron zumStand des Netzwerks durchgefuhrt werden. Daher gibt eskeine Block-Intervalle und Transaktionen konnen umgehendveroffentlicht werden.

5) UDP-Nachrichtenprotokoll: Unser System ist dazu de-signt worden, uber einen unendlich langen Zeitraum unterVerwedung einer minimalen Menge an Rechenressourcen be-trieben zu werden. Alle Nachrichten innerhalb des Systemswurden designt, um zustandslos zu sein und in ein einzigesUDP-Paket hineinzupassen. Auf diese Weise ist es auch ein-facher fur Lite-Peers mit schwankender Verbindung sich amNetzwerk zu beteiligen, ohne kurzzeitige TCP-Verbindungenwiederherstellen zu mussen. TCP ist nur fur neue Peersgedacht, die die Blockchains en masse bootstrappen wollen.

Ein Knoten kann sich sicher sein, dass das Netzwerk seineTransaktion empfangen hat, indem er den Transaktionsdaten-verkehr anderer Knoten beobachten, da mehrere Kopien vondiesen widergespiegelt werden sollten.

B. IPv6 und Multicast

Durch auf verbindungslosem UDP basierende Fortentwick-lung konnen zukunftige Implementierungen IPv6 Multicastals einen Ersatz fur traditionelle Transaktionsflutung undStimmubertragung verwenden. Dadurch wird der Bandbreiten-verbrauch des Netzwerks reduziert und Knoten erhalten mehrFlexibilitat bei der Festlegung von Richtlinien.

C. Leistung

Zum gegenwartigen Zeitpunkt hat das RaiBlocks-Netzwerk4,2 Millionen Transaktionen verarbeitet, woraus sich eineBlockchain-Große von 1,7 GB ergibt. Die Transaktionszeitenwerden in Sekunden gemessen. Eine aktuelle Referenzimple-mentierung, die auf SSDs betrieben wird, kann uber 10 000Transaktionen pro Sekunde verarbeiten, was vor allem mit IO-Beschrankungen zusammenhangt.

VII. RESSOURCENVERBRAUCH

Dies ist eine Ubersicht der Ressourcen, die von einemRaiBlocks-Knoten verbraucht werden. Zusatzlich betrachtenwir einige Ideen zur Reduzierung der Ressourcen-Nutzung furspezifische Anwendungszwecke. Reduzierte Knoten werdennormalerweise als leichtgewichtige, gereinigte oder verein-fachte Zahlungsverifizierungsknoten bezeichnet.

A. NetzwerkDie Netzwerkaktivitat hangt davon ab, wie viel das Netzw-

erk zur Gesundheit des Netzwerks beitragt.1) Vertreter: Ein Vertreterknoten erfordert maximale Net-

zwerkressourcen, da er den Abstimmungsdatenverkehr andererVertreter uberwacht und seine eigenen Stimmen veroffentlicht.

2) Vertrauensfrei: Ein vertrauensfreier Knoten ahnelt einemVertreterknoten, aber fungiert ausschließlich als Beobachter,er umfasst keinen Private-Key eines Vertreterkontos undveroffentlicht keine eigenen Stimmen.

3) Vertrauensbasiert: Ein vertrauensbasierter Knotenuberwacht den Abstimmungsdatenverkehr eines Vertreters,dem er vertraut, einen korrekten Konsens herzustellen.Dadurch wird der eingehende Abstimmungsdatenverkehrverringert, den Vertreter an diesen Knoten senden.

4) Leichtgewichtig: Ein leichtgewichtiger Knoten ist auchein vertrauensbasierter Knoten, der ausschließlich Daten-verkehr fur Konten uberwacht, an denen er interessiert ist –auf diese Weise wird das Netzwerk nur minimal genutzt.

5) Bootstrap: Ein Bootstrap-Knoten ubertragt dengesamten Ledger oder Teile des Ledgers an Knoten, die dabeisind, online zu gehen. Dies findet uber eine TCP-Verbindunganstelle einer UDP-Verbindung statt, da bei diesem Prozessgroße Datenmengen involviert sind, die eine erweiterteDatenflusskontrolle benotigen.

B. Disk-KapazitatIn Abhangigkeit von den Nutzeranforderungen, verfugen

unterschiedliche Knotenkonfigurationen uber unterschiedlicheSpeicheranforderungen.

1) Historisch: Ein Knoten, der eine komplette Verlauf-saufzeichnung aller Transaktionen speichern mochte, benotigtden meisten Speicherplatz.

2) Aktuell: Aufgrund des Designs, in dessen Rahmen akku-mulierte Guthaben in Blocks gespeichert werden, mussenKnoten nur den letzten Block bzw. den Kopfblock jedesKontos speichern, um am Konsens teilzunehmen. Falls einKnoten nicht daran interessiert ist, einen vollen Verlauf zuspeichern, kann er stattdessen nur die Kopfblocke speichern.

3) Leichtgewichtig: Ein leichtgewichtiger Knoten speichertkeine lokalen Ledger-Daten und beteiligt sich nur am Netzw-erk, um Aktivitaten auf Konten zu uberwachen, an denen erinteressiert ist – oder er erstellt optionale Transaktionen mitseinen Private-Keys.

C. CPU1) Transaktionsgenerierung: Ein Knoten, der neue

Transaktionen erstellen mochte, muss eine Proof-of-Work-Nonce erstellen, um den Drosselungsmechanismus vonRaiBlocks zu passieren. Die Rechenleistung unterschiedlicherHardware wird im Anhang A verglichen.

2) Vertreter: Ein Vertreter muss Signaturen fur Blocksund Stimmen verifizieren und auch seine eigenen Signaturenproduzieren, um sich am Konsens zu beteiligen. Die Menge anCPU-Ressourcen, die fur einen Vertreterknoten benotigt wer-den, sind wesentlich niedriger, als der Ressourcenaufwand zurTransaktiosgenerierung. Eine einzige CPU in einem modernenComputer sollte ausreichend sein.

9

3) Beobachter: Ein Beobachter-Knoten erzeugt keine eige-nen Stimmen. Da der Mehraufwand zur Signaturgenerierungminimal ist, entsprechen die CPU-Anforderungen nahezugenau den Voraussetzungen zum Betreiben eines Vertreter-knotens.

VIII. SCHLUSSFOLGERUNG

Wir haben in diesem Papier das Rahmenwerk fur einevertrauensfreie, gebuhrenfreie Niedriglatenz-Kryptowahrungprasentiert, die eine neuartige Blockgitter-Struktur unddelegierte Proof-of-Stake-Abstimmungen verwendet. Das Net-zwerk erfordert nur minimale Ressourcen, benotigt keinestromaufwandige Mining-Hardware, und kann einen hohenTransaktionsdurchsatz verarbeiten. All das wird mit Hilfe vonindividuellen Blockchains fur jedes Konto erreicht, welche dieZugriffsprobleme und Ineffektivitaten einer globalen Daten-struktur eliminieren. Wir haben mogliche Angriffsflachengegenuber dem System identifiziert und Argumente dazuvorgestellt, weshalb RaiBlocks gegen diese Arten von Angrif-fen immunisiert ist.

ANHANG APOW-HARDWARE-BENCHMARKS

Wie zuvor erwahnt, dient das PoW von RaiBlocksdazu, Netzwerk-Spam zu reduzieren. Unsere Knoten-Implementierung bietet eine Beschleunigung, die von GPUsGebrauch machen kann, die mit OpenCL kompatibel sind.Tabelle I bietet einen praktischen Benchmark-Vergleichunterschiedlicher Hardware. Momentan ist die PoW-Schwellefixiert, aber eine anpassbare Schwelle kann in Zukunft alsReaktion auf eine wachsende durchschnittliche Rechenleistungimplementiert werden.

TABELLE IHARDWARE-POW-LEISTUNG

Gerat Transaktionen pro SekundeNvidia 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

Wie zuvor erwahnt, dient das PoW von RaiBlocksdazu, Netzwerk-Spam zu reduzieren. Unsere Knoten-Implementierung bietet eine Beschleunigung, die von GPUsGebrauch machen kann, die mit OpenCL kompatibel sind.Tabelle I bietet einen praktischen Benchmark-Vergleichunterschiedlicher Hardware. Momentan ist die PoW-Schwellefixiert, aber eine anpassbare Schwelle kann in Zukunft alsReaktion auf eine wachsende durchschnittliche Rechenleistungimplementiert werden.

ANERKENNUNG

Wir mochten Brian Pugh fur die Kompilierung und Format-tierung dieses Papiers danken.

VERWEISE

[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