√Radix.

For the English version of this article, please click here.

Heute möchte ich ein neues aber dem ein oder anderem langjährigem Leser durchaus bekanntes Infrastruktur-Projekt vorstellen, welches sich nun mehr als fünf Jahre in der Entwicklung befunden hat. Der Kopf hinter dem Projekt forschte zunächst an einem neuen Blockchain Protokoll, verwarf es, baute erneut ein DAG ähnliches Konzept, verlor 900 BTC einer Funding Runde in einem Hack (die Investoren erhielten das Investment komplett von Dan Hughes zurück), startete erneut mit einem anderen Ansatz und tat dies alles, um das altbekannte Problem der Skalierbarkeit zu lösen. Jetzt ist Dan Hughes zurück als CTO des Projektes, welches sich in der Vergangenheit eMunie nannte: Radix.

In diesem Post möchte ich das Projekt selbst vorstellen, aber auch etwas detaillierter auf den komplett neu entwickelte Konsens-Algorithmus von Radix eingehen. Besonders letzterer ist meiner Meinung nach extrem wichtig zu verstehen, besonders im Hinblick auf die Vielzahl neuer Projekte, die alle behaupten, das Skalierungsproblem ein und alle mal gelöst zu haben.

Das Projekt

Seit das Development 2012 bei eMunie begonnen hat, wurde die die Zahl der Transaktionen pro Sekunde konstant nach oben geschraubt. Waren Anfang 2015 erst 200 und Ende 2015 1000 Transaktionen pro Sekunde möglich, so wirken diese Zahlen heute fast lächerlich. Mit dem Rebranding zu Radix Q3 2016 und dem neuen Konsensus Algorithmus „Tempo“ Mitte 2017 gab es einen Sprung auf 14000 Transaktionen/Sekunde. Aktuell wurden in Tests eine Milliarde Transaktionen pro Woche erreicht und die Zahl der Transaktionen pro Sekunde soll sich laut Roadmap noch dieses Jahr auf eine Million erhöhen. Sämtliche Tests werden dabei in einer Testumgebung durchgeführt und können in dem von Radix bereitgestellten Explorer verfolgt werden. Gänzlich ohne Transaktionsgebühr kommt Radix allerdings nicht aus – es wird eine Transaktionsgebühr von ca. einem Cent gegenwert angestrebt, während Micro-Transaktionen gratis sein sollen.

Zusätzlich zu diesem hohen Transaktionsvolumen pro Sekunde sollen ein paar spannende Features nach und nach veröffentlicht werden:

• Smart Contracts sind mit eines der wichtigsten Features eines neuen Infrastrukturprojekts und sind mit Radix umsetzbar. Die Contracts sollen in einer neuen, JavaScript basierten, Programmiersprache namens Scrypto geschrieben werden. Zunächst soll die Sprache Ende diesen Jahres auf dem TestNet auf den Prüfstand, dann langsam auf dem Mainnet und schließlich Q2 2019 komplett und Turing complete freigeschaltet werden.
• Wie schon im Ethereum Netzwerk, wird auch Radix ein Naming System einführen und so Radix Adressen mit „Text“ verknüpfen. Aktuell ist es so z.B im Ethereum Netzwerk möglich, statt eine lange Adresse Copy & Pasten zu müssen einfach die  Ether an den mit der Adresse verbundenen Namen wie z.B „altcoinspekulant.eth“ zu senden.
• Weiterhin wird Ende diesen Jahres auch ein Development Kit zur Verfügung gestellt werden, welches es jedem selbst erlaubt, eine Radix EC-Karte zu erstellen. Dieses Video zeigt die Funktionsweise mit Hilfe eines Prototypen. Da geplant ist den Radix Token in naher Zukunft zu einem Stable Token umzubauen, könnte dies eine Schlüsseltechnologie werden und in der Kombination sehr viel tatsächliche Adaption bringen.
• Zusätzlich muss noch erwähnt werden, dass Radix komplett ohne Proof of Work, Proof of Stake oder Masternodes auskommen wird und auch keine zentrale Node, wie es aktuell noch bei IOTA mit dem Coordinator der Fall ist, benötigt. Eine Radix Node soll auch auf einem Raspberry Pi laufen können.

Momentan arbeitet das Radix Team, welches aus 14 Personen (9 Developer) bestehend aus London heraus operiert, mit Hochdruck am geplanten Alpha Release, der am 19. Juni in London vorgestellt werden soll. Doch all diese Ziele wären ohne Tempo, den neuen Konsens-Algorithmus nur Schall und Rauch, weshalb dieser im Folgenden erklärt und beleuchtet werden soll – das ganze sieht dabei auf den ersten Blick nicht ganz einfach aus.

Tempo – Der neue Consensus Algorithmus

Tempo ist ein vollständig neu entwickelter Algorithmus, der sich der Sharding Technologie sowie eines Gossip Protokolls bedient. Sharding bezeichnet dabei eine bestimmte Datenbankpartitionierung (eine Aufteilung der Datenbank in mehrere Teile), während ein Gossip Protokoll eine Form der Kommunikation bzw. Datenverbreitung beschreibt (diese kann mit der Verbreitung von Gerüchten in der echten Welt verglichen werden – mehr dazu in diesem Wikipedia Artikel). Um weiter in die Tiefe gehen zu können, müssen an dieser Stelle zunächst ein paar fundamentale Dinge geklärt werden:

• Ein Radix Netzwerk in seiner Gesamtheit wird als „universe“, also als Universum, bezeichnet.
• Jedes Event in diesem Universum, sei es eine Transaktion oder eine Nachricht, wird repräsentiert durch ein Objekt, das sich Atom nennt. Alle Atome enthalten mindestens eine Adresse als Endpunkt, die aus einer Identität (z.B dem Private-Key des Empfängers) gewonnen wird.
• Ein Atom kann entweder ein „Payload“ (Transport)-Atom in Form von z.B einer Nachricht an ein oder mehrere Personen, oder ein Transfer-Atom zur Übertragung von Eigentum sein. Atome können auch andere Atome enthalten, sofern diese dazu ausgelegt (programmiert) wurden.

Das Tempo Ledger, das dem Netzwerk zugrunde liegt, ist dabei eine verteilte Datenbank, die alle Atome eines Universums speichert. Eine Node kann wahlweise die gesamte globale Datenbank speichern oder nur einen Teil davon. Die einzelne Teile, in die die Datenbank aufgeteilt wird, werden Shards genannt. Die Menge an Shards, die existieren, wird bei der Erstellung eines jeden Universums festgelegt und kann anschließend nicht mehr verändert werden. Das Radix Mainnet soll aus mehr als 18 Quantillionen Shards bestehen und jede Node kann jederzeit entscheiden, welche einzelnen Shards sie lokal speichert.

Wie also kann man Transaktionen senden, wie werden sie bestätigt und wie gespeichert? Dazu muss man zunächst verstehen, wie in Radix „Besitz“ und eine Änderung dessen abgebildet wird und wie einzelne Transaktionen in eine logische Reihenfolge gebracht werden. Während bei Payload Atomen Besitz keine Rolle spielt, wird bei einem Transfer-Atom das Besitzverhältnis über sogenannte „Consumables“ geklärt. Ein Consumable ist quasi ein Stück Code, welches den derzeitigen Besitzer des Objekts über dessen Public-Key festlegt. Besitz wird dabei über eine Kette von diesen Consumables definiert. Um ein Objekt also mit Hilfe eines Atoms und einer Transaktion an jemanden zu senden und den Besitz an diesen abzutreten, muss der aktuelle Besitzer, nennen wir ihn Ernie, einen sogenannten „Consumer“ für das zu übertragende Objekt erstellen. Dieser Consumer enthält den Hash des Consumables, welches Ernie als den aktuellen Besitzer ausweist, sowie eine Referenz aus den Consumables sämtlicher Vorbesitzer. Das gesamte Konstrukt wird nun in einer Transaktion weitergegeben an den Empfänger, nennen wir ihn Grobi, welcher seinerseits erneut ein Consumable für das nun ihm gehörende Objekt erstellt und dieses in den Consumer des Objekts einfügt. Vereinfacht ausgedrückt: Ernie besitzt einen Kettenbrief in einem Briefumschlag. In dem Brief stehen alle Unterschriften der Besitzer chronologisch untereinander. Um zu zeigen, dass ihm aktuell der Brief gehört, schreibt Ernie seine Unterschrift auf ein Post-it und klebt dieses auf den Brief. Unter der letzten Unterschrift verweist er nun auf sein Post-it. Bei einem Transfer an Grobi wird nun das Post-it von Ernie entfernt und Ernies Unterschrift tatsächlich unter die anderen gesetzt. Grobi seinerseits verfährt nun wie Ernie zu Beginn. Das gesamte Verfahren muss man sich natürlich kryptografisch über Private-/Public-Key und Hashes gesichert vorstellen.

Jetzt können wir uns dem eigentlichen Prozess der Transaktion widmen. Dabei ist es bei jeder Infrastruktur wichtig, dass sie einzelne Events bzw. Transaktionen in eine bestimmte Reihenfolge bringen kann, um so zu bestimmen, welches Event wann stattgefunden hat. Dabei spielt die tatsächliche Uhrzeit, wann eine Transaktion getätigt wurde, keine wirkliche Rolle. Viel wichtiger ist, die einzelne Transaktion in den Strom der Transaktionen einordnen zu können – also, ob eine Transaktion A vor oder nach einer Transaktion B getätigt wurde (mit wie viel zeitlichem Abstand ist dabei auch egal, lediglich das Ergebnis zählt). Bei Bitcoin wird dies über die Blockchain gelöst: Ist eine Transaktion A in einem Block vor einer Transaktion B, so wurde A vor B getätigt. In einem Radix Universum ist auch das, aufgrund der anderen Gegebenheiten, etwas komplizierter und wird erneut über verschiedene Mechanismen gelöst.

Zunächst hat jede Node ihren eigenen Zähler (vergleichbar mit einem Stromzähler), der, immer wenn diese Node eine neue Transaktion bzw. ein neues Event erhält (welches sie vorher noch nicht gesehen hatte), um eine Einheit nach oben gesetzt wird. Dieser Zähler wird als „Logical Clock“ bezeichnet. Beim Speichern eines Events in der lokalen Datenbank wird immer der aktuelle Wert dieser Logical Clock mit gespeichert. Anschließend muss man noch den Sinn hinter den Shards verstehen. Nehmen wir erneut an, dass Ernie ein Atom über eine Transaktion an Grobi senden möchte. Das Atom, welches Ernie senden möchte, liegt im Shard 1, während Grobis Zieladresse, die Ernie angeben muss, in Shard 3 liegt. Erinnert man sich, dass Sharing bedeutet, dass die Datenbank aufgeteilt ist und die Nodes entscheiden, welche Shards sie lokal speichern, so folgt daraus, dass die Transaktion von Ernie an Grobi nur für die Nodes von Relevanz ist, die entweder Shard 1, Shard 3 oder beide Shards lokal speichern. Bevor ein Event, bzw. eine Transaktion an sämtliche Nodes gesendet wird, muss diese Transaktion geprüft und bestätigt werden. Dieser Prozess involviert eine endliche, jedoch variable Anzahl (je mehr, desto weniger Diskrepanzen können im Netzwerk entstehen) an zufällig ausgewählten Nodes mit entsprechenden Shards und wird „Temporal Proof“ genannt. Konkret bedeutet dies, dass Ernies Node zunächst einmal in Shard 1 prüft, ob Ernie das zu sendende Atom überhaupt besitzt oder schon ausgegeben hat (läuft etwas schief, wird die Transaktion abgebrochen). Ist alles korrekt, so bestimmt die Node die für den Temporal Proof benötigte Anzahl an Nodes, die die jeweiligen Shards besitzen und die im Netzwerk (Universum) direkt miteinander verbunden sind (sollte keine passende Node gefunden werden, wird im weiteren Umfeld gesucht) und sendet die Transaktion an die nächste, zufällig ausgewählte, Node. Dabei wird nach jedem Check eine sogenannte „Space-Time-Koordinate“ (l, e, o, n) beigefügt und weitergesendet. Diese besteht aus dem aktuellen Wert der jeweiligen Logical Clock der Node (l), dem Hash des Events (e), der Identität der aktuellen Node (o) sowie der Identität der nächsten Node in der Kette, die die Transaktion prüfen wird (n). Nachdem eine Transaktion bzw. ein Event durch die festgelegte Anzahl an individuellen Node-Überprüfungen gelaufen ist und keine Diskrepanzen entdeckt wurden, gilt eine Transaktion als bestätigt und wird an die restlichen Nodes mit entsprechenden Shards weitergeleitet (Finalisierung). Nach der hier aufgeführten Beispiels-Transaktion von Shard 1 an Shard 3 wären sämtliche weitere Änderungen an dem gesendeten Atom nicht mehr relevant für Shard 1 und müssten nicht mehr von Nodes, die Shard 1 lokal speichern, gesichert werden (außer es erfolgt ein erneuter Transfer nach Shard 1). Die Bestätigung selbst soll dabei unter 5 Sekunden dauern.

In einer solchen Netwerk-Architektur kann es natürlich auch zu Diskrepanzen kommen. Hier möchte ich an dieser Stelle nicht näher drauf eingehen, da dies den Rahmen sprengen würde. Allerdings kann man sagen, dass solche Konflikte in den allermeisten Fällen über einen Vergleich der Logical Clock Werte geklärt werden können, bzw. einen Austausch von Daten zwischen den Nodes über Gossiping. Sollte eine Diskrepanz zwischen zwei Transaktionen nicht gelöst werden können (extrem unwahrscheinlich), so werden beide nicht vom Netzwerk akzeptiert. Laut Radix ist es nicht möglich, dass eine Transaktion bestätigt wird und sich hinterher herausstellt, dass dies eigentlich nicht korrekt war. Näheres über Konflikte kann man hier im Tempo Paper nachlesen, potenzielle Attacken werden wie z.B hier im Blog aufgezeigt.

Node Incentivierung und Investitionsmöglichkeiten in Radix

Die Incentive eine Node laufen zu lassen liegt dabei in der Bezahlung für sämtliche Arbeit in Form der anfallenden Transaktionsgebühren sowie Inflation. Auch hier verweise ich für genauere Details auf das entsprechende Paper von Radix. Offen ist noch, wie genau die angesprochene Inflation definiert ist und wie Investoren genau an den Radix Token kommen können. Klar ist nur, dass der Verkauf über die eigene dezentrale Börse in Q4 geschehen soll, mehr Informationen sollen im Economics Paper, welches für Q3 angekündigt wurde, nachlesbar sein. Gegebenenfalls werden im Radix Telegram Channel ab und zu nähere Informationen herausgegeben.

Insgesamt hat das Projekt Radix meiner Meinung nach, vorausgesetzt es klappt alles wie geplant, ein enormes, fast schon IOTA ähnliches, Potenzial. Man sollte hier definitiv versuchen am Ball zu bleiben (hinsichtlich Informationen). Ich selbst werde am 19. Juni beim Alpha Launch in London vor Ort sein und voraussichtlich über die Entwicklungen und das Event schreiben.

-Lukas Fiedler

Disclaimer – Hinweis auf Interessenkonflikt: Der Autor oder Teile des Autorenteams sind in die oben genannten Kryptowährungen selbst investiert oder werden in diese investieren (Dies wird ab jetzt standardmäßig unter jedem Artikel erscheinen, da es sein kann, dass zu einem Zeitpunkt nach Veröffentlichung des Artikels investiert wurde).