01. Okt’21
Übersetzung des Blogartikel von Autor Hans Moog, IOTA Foundation
Entwurf einer geisteswissenschaftlichen Vertrauensschicht für die digitale Welt
Im letzten Teil unserer Blogserie haben wir ein neues Ledger-Modell vorgestellt, das es den Nodes ermöglicht, die kausalen Beziehungen zwischen Konflikten zu verstehen.
In diesem Teil werden wir die theoretischen Modelle, die zur Beschreibung verteilter Systeme verwendet werden, um ein neues Primitiv – das Generalized Voting Protocol (dt. ein verallgemeinertes Abstimmungsprotokoll) – erweitern und dann die Spezifikation für eine Instanz dieses Primitivs bereitstellen, die die neu gewonnene Freiheit nutzt, um die optimale Protokollleistung zu erreichen.
Theoretisches Modell
In dem Versuch, ein theoretisches Modell der in verteilten Systemen verwendeten Komponenten zu entwickeln, hat die Forschung auf dem Gebiet des distributed computing eine Sammlung grundlegender Bausteine identifiziert.
Bei diesen Primitiven des distributed computing handelt es sich um verallgemeinerte, hochgradige Abstraktionen von Protokollen, die in Bezug auf ihre tatsächliche Gestaltung und Implementierung völlig unabhängig sind.
Diese Abstraktion ermöglicht es den Forschern nicht nur, die Leistung verschiedener Lösungen für ein ähnliches Problem zu vergleichen und zu untersuchen, sondern auch, modulare Software zu erstellen, bei der einzelne Elemente des Systems ausgetauscht werden können, wenn neue und bessere Lösungen verfügbar werden.
Atomic Broadcast
Eines der bekanntesten Primitive des distributed computings, das mit dem Bereich des Konsens zusammenhängt, ist das Atomic Broadcast.
Es beschreibt ein Protokoll, das sicherstellt, dass alle Nodes in einem verteilten Netzwerk die gleiche Menge an Messages – also Broadcast – in genau der gleichen Reihenfolge erhalten. Es wird atomic genannt, weil das Protokoll entweder bei allen Teilnehmern erfolgreich sein oder bei allen Teilnehmern anhalten kann.
Anmerkung: Es gibt mehrere verschiedene Protokolle, die dieses Primitiv implementieren, aber die bekanntesten sind wahrscheinlich Hashgraph und HoneyBadger.
Generalized voting (dt. Verallgemeinerte Abstimmung)
Wir haben bereits erörtert, inwiefern die Festlegung einer Gesamtreihenfolge direkt für die Einschränkungen heutiger DLTs verantwortlich ist, und möchten daher ein anderes, allgemeineres Primitiv vorschlagen, das nicht von einer Gesamtreihenfolge abhängt.
Wir nennen dieses Primitiv generalized voting und es beschreibt ein Protokoll, das sicherstellt, dass alle Teilnehmer in einem verteilten Netzwerk letztendlich den gleichen Satz von Messages erhalten und sich im Falle von Konflikten in diesen Messages letztendlich für eine einzige Version der Wahrheit entscheiden.
Dieses Primitiv ist allgemein genug, um alle Formen des Konsenses abzudecken (einschließlich Satoshis ursprünglichem Blockchain-Design), was ein guter Indikator dafür ist, dass es ein echtes Primitiv ist.
Anmerkung:Das Atomic-Broadcast-Protocol erweist sich als eine spezialisierte Version des generalized voting protocol und damit “nicht wirklich” als echtes Primitivum, da es Annahmen über das zugrunde liegende Design macht (nämlich Konflikte durch die Festlegung einer Gesamtordnung zu lösen).
- – –
Nachdem wir die theoretische Grundlage für unser neues Abstimmungsprotokoll vorgestellt haben, werden wir nun mit der Bereitstellung der fehlenden Teile der Spezifikation fortfahren.
Wir werden die Konzepte schrittweise von unten nach oben vorstellen, wobei wir mit dem Networking Layer beginnen und dann die Konzepte erweitern, um auch den Konsens abzudecken.
Networking Layer
Ähnlich wie bei anderen DLTs verwenden wir ein Peer-to-Peer-Netzwerk, bei dem die Nodes mit einer festen Anzahl von Nachbarn kommunizieren.
die grüne Node hat 5 Nachbarn
Die Auswahl der Nachbarn kann durch manuelles gegenseitiges Peering, durch eine automatische Peer-Erkennung oder durch eine Kombination aus beidem erfolgen.
Anmerkung: IOTA bietet eine Standard-Peering-Strategie (Autopeering), die es den Nodes ermöglicht, automatisch und ohne Benutzereingriff Nachbarn zu finden.
Gossip-Protocol
Da unser Protokoll auf den Prinzipien der vierfachen Buchführung (engl. quadruple entry accounting) basiert, ist das Schreiben in das Ledger so einfach wie das Senden einer Transaktion an das Netzwerk.
Dementsprechend sendet die Node, die eine Transaktion durchführen möchte, eine Message mit der Transaktion an alle seine Nachbarn, die ihr Ledger aktualisieren und die Message rekursiv weiterleiten.
Nodes tauschen Messages mit Transaktionen aus
Crash Fault Tolerance (dt. Fehlertoleranz bei Abstürzen)
Bislang ist unser Protokoll zwar skalierbar, aber noch nicht zuverlässig, da es mehrere Situationen gibt, in denen eine Node nicht alle Messages empfangen kann (z. B. wenn sie offline ist oder eine Störung vorliegt).
Um dieses Problem zu lösen, werden wir Satoshi Nakamotos Idee nutzen, die Messages zu einem DAG (gerichteten azyklischen Graphen) zusammenzufassen, in dem spätere Messages auf frühere verweisen. Im Gegensatz zu einer Blockchain, bei der jeder Block nur einen einzigen anderen Block referenziert, referenziert eine Message in IOTA zwei Parents (dt. Eltern), wodurch wir uns von der Notwendigkeit befreien können, eine Gesamtreihenfolge festzulegen.
Jede Message verweist auf zwei vorhergehende Messages
Eine Node, die eine Message empfängt, die auf einen unbekannten Parent verweist, kann die fehlende Message bei ihren Nachbarn anfordern. Dieser einfache Mechanismus stellt sicher, dass auch Nodes, die für einige Zeit offline waren, in der Lage sind, die Messages, die sie verpasst haben, rekursiv anzufordern, sobald sie wieder online sind und aktuelle Messages erhalten.
Der Vorgang des rekursiven Anforderns fehlender Messages wird als solidification (dt. Verfestigung) bezeichnet, und eine Message, die keine Lücken in ihren direkten oder indirekten Vorgängern hat, wird als solid bezeichnet.
Die Fähigkeit eines verteilten Systems, mit unzuverlässigen Teilnehmern, die über ein unzuverlässiges Medium kommunizieren, umzugehen, wird als Crash Fault Tolerance bezeichnet.
Der Tangle
Da die resultierende DAG ein wenig anders aussieht als eine Blockchain, wollen wir uns etwas Zeit nehmen und einige zusätzliche Begriffe einführen.
Die erste Message, die das Netzwerk aufbaut, wird als Genesis Message bezeichnet, und die Nodes referenzieren sie, wenn es keine anderen Messages gibt, auf die sie sich beziehen können. Sie ist standardmäßig als solid eingestuft.
Das Netzwerk beginnt mit einer Genesis-Message (blau)
Messages, die noch nicht von anderen Messages referenziert wurden, werden als Tips bezeichnet und der Prozess der Einstellung dieser Referenzen während der Ausgabe einer Message wird als Tip-Selection bezeichnet.
Die violetten Messages sind die Tips des DAG
Alle Messages, die direkt oder indirekt von einer Message referenziert werden, werden als Past Conebezeichnet.
Die violetten Messages bilden den Past Cone der blauen Message
Dementsprechend werden alle Messages, die direkt oder indirekt auf eine Message verweisen, als ihr Future Cone bezeichnet.
Messages, die nur von einer sehr kleinen Anzahl von Nodes gesehen werden, haben eine geringere Chance, von späteren Messages referenziert zu werden, und in seltenen Ausnahmefällen kann es passieren, dass die Message überhaupt nicht referenziert wird.
Wir nennen diese Message orphaned (dt. verwaist) und sie werden bereinigt, sobald klar ist, dass niemand mehr auf sie verweisen wird.
Die rote Message wurde von anderen nicht aufgegriffen und wird keine Auswirkungen haben – sie ist verwaist.
Schlussfolgerung
Wir haben ein sehr einfaches Broadcast-Protokoll spezifiziert, das sicherstellt, dass jede Node letztendlich eine ähnliche Wahrnehmung der Messages hat, die vom Netzwerk verarbeitet wurden (orphans werden ignoriert).
Anstatt ständig jeden Teilnehmer zu überwachen und das Netzwerk anzuhalten, wenn zu viele Nodes Probleme haben – wie in einem atomic broadcast protocol – geben wir Nodes die Möglichkeit, ihren Rückstand aufzuholen.
Anmerkung: Diese sehr einfache Idee, Nodes die Möglichkeit zu geben, ihren Rückstand aufzuholen, war einer der größten Durchbrüche Satoshi Nakamotos.
Es ermöglicht den Nodes nicht nur, Zeiten suboptimaler Netzwerkbedingungen zuverlässig zu überbrücken, sondern erlaubt es auch jedem, das Netzwerk zu verlassen oder ihm beizutreten, wann immer er möchte – es ist wirklich offen und erlaubnisfrei.
Consensus Layer
Bis jetzt ist unser Protokoll extrem einfach und erfordert nur das Senden von zwei zusätzlichen Hashes bei jeder Transaktion, aber wir haben uns auch noch nicht wirklich mit dem schwierigen Problem des Konsens auseinandergesetzt.
Während das Erreichen eines Konsenses normalerweise als ein sehr komplexes Thema angesehen wird, werden wir sehen, dass unser Protokoll eigentlich schon fertig ist und nur noch einige kleine Anpassungen benötigt, um auch einen Konsens zu ermöglichen.
Satoshi verstehen
Um die folgenden Abschnitte zu verstehen, müssen wir zunächst die Art und Weise ändern, wie wir Blockchains betrachten.
Anstatt sie als eine einzige, längste Chain zu sehen, kann man sie als einen Baum betrachten, in dem alle aufgegebenen Abzweigungen (Forks) noch sichtbar sind und in dem das Ergebnis der Abstimmung darüber, welche Abzweigung sich durchsetzen soll, in die Länge der konkurrierenden Chains einfließt.
Die längste Kette ist in Wirklichkeit nur ein Zweig (en. Branch) in einem Baum von konkurrierenden Abzweigungen.
Eine Nakamoto-Blockchain ist nicht nur eine Folge von Messages, die Zustandsänderungen enthalten, sondern auch ein Abstimmungsmechanismus, bei dem jeder Block für eine bestimmte Abspaltung stimmt.
Diese kleine Verschiebung der Perspektive führt zu einer wirklich wichtigen Beobachtung:
Jede Referenz in Satoshis Blockchain stimmt über eine potentiell unbegrenzte Anzahl von Forks mit einem kleinen und konstant großen Hash ab, was die Komplexität der Nachrichtenübermittlung völlig konstant und unabhängig von Faktoren wie z.B. der Größe des Netzwerks macht.
Diese Form der virtuellen Abstimmung – bei der Nodes ihre Meinung durch einen Verweis in einer replizierten Datenstruktur ausdrücken, anstatt zusätzliche Messages auszutauschen – ist so effizient, dass selbst Projekte, die Satoshis Konsens nicht mehr verwenden, immer noch diese Prinzipien nutzen, um den Rest des Netzwerks über Zustandsänderungen zu informieren, und es ist sehr unwahrscheinlich, dass wir jemals einen effizienteren Weg zur Komprimierung von Meinungen finden werden.
Anmerkung: Den Hashes, die die Messages verbinden, eine Bedeutung zu geben und den Nodes eine Möglichkeit, diese Bedeutung zu verstehen, war die zweitgrößte Revolution von Satoshi Nakamoto.
Virtual Voting
Da unser Ledger-Modell potenziell zu einer großen Anzahl von Konflikten führen könnte und Abstimmungen in der Regel eine teure Angelegenheit sind, beschließen wir, Satoshis Ideen zu kopieren und jede Message in eine Abstimmung zu verwandeln.
Damit unsere Messages über die Zweige (branches) unseres vierfach geführten Hauptbuchs (engl. quadruple entry accounting ledger) abstimmen können, müssen wir zunächst die Informationen aus dem Ledger auf den Tangle projizieren und dann unseren Referenzen eine Bedeutung geben.
Dementsprechend nehmen wir die folgenden Anpassungen an unserem Protokoll vor:
- Eine Node, die eine Message ausgibt, die eine Transaktion enthält, stimmt für den Zweig, zu dem diese Transaktion gehört.
- Die Referenzen zwischen den Nachrichten bedeuten Zustimmung, so dass jede Message rekursiv für die Zweige der Messages stimmt, die sie direkt oder indirekt referenziert (die Stimmen werden entlang der Ränder (engl. edges) im Tangle vererbt).
- Eine Message, die für zwei sich paarweise widersprechende Zweige stimmt, gilt als ungültig.
Die Verzweigungen, für die eine Message abstimmt, werden durch Verketten der Zweige ihrer Parents und ihrer enthaltenen Transaktion bestimmt.
Eine Message erbt die Verzweigungen von den Parents und ihrer enthaltenen Transaktion
Beispiel
Am einfachsten lässt sich die Funktionsweise anhand eines Beispiels nachvollziehen.
Nehmen wir an, wir haben einen konfliktfreien Tangle, in dem alle Messages ehrliche Transaktionen enthalten und dementsprechend für den Hauptzweig (engl. Master-Branch) unseres vierfach geführten Hauptbuchs stimmen.
In Abwesenheit von Konflikten sind die Messages einfach Zeugen anderer Messages und stimmen für den Master Branch (dt. Hauptzweig)
Nehmen wir nun an, dass ein Angreifer eine doppelte Ausgabe (engl. double spend) tätigt, d. h. eine Message, die eine Transaktion enthält, die im Widerspruch zu einer der anderen Message steht, die zuvor ausgegeben wurde.
Was nun geschieht, ist, dass die beiden kollidierenden Transaktionen in den entsprechenden Zweig gebucht werden und diese neu eingeführten Zweige sich automatisch auf die Messages im Tangle ausbreiten, gemäß den Regeln, die wir gerade definiert haben.
Die Verzweigungen werden an alle Messages weitergegeben, die direkt oder indirekt die kollidierenden Messages genehmigen.
Alle Messages im Future Cone einer konfligierenden Message stimmen für den entsprechenden Zweig, um vom Netzwerk akzeptiert zu werden.
Branch DAG: der grüne Zweig hat mehr Zustimmungen und Stimmen erhalten als der rote Zweig
Die Konsensregel ist sehr einfach: Der Zweig, der die meisten Zustimmungen erhalten hat, gewinnt. Bei einem Gleichstand wählen die Nodes den Zweig mit dem niedrigeren Hashwert.
Ähnlich wie bei einer Blockchain, bei der spätere Blöcke frühere Entscheidungen verstärken, indem sie sich an die Gewinner-chain anhängen, beziehen sich die Nodes in unserem Protokoll auch weiterhin auf Messages des siegreichen Zweigs – was es immer schwieriger macht, Entscheidungen rückgängig zu machen.
Im Gegensatz zu einer Blockchain, die nur ein einziges Validierungsstatement mit jedem Block veröffentlicht, teilen die Nodes in IOTA ständig ihre Meinung mit jeder ausgegebenen Transaktion.
Dies löst eines der größten Probleme von Satoshis ursprünglichem Blockchain-Design, da es dem Netzwerk erlaubt, in einem asynchronen Netzwerkmodell zu arbeiten und eine große Anzahl von Bestätigungen parallel zu sammeln, um so schnell wie möglich eine endgültige Finalität zu erreichen.
Je mehr Transaktionen es gibt, desto mehr Stimmen können wir sammeln und desto schneller erreichen wir die Finalität – das Netzwerk wird mit mehr Benutzern schneller.
Dezentralisierte Identitäten
Da wir jedoch einen identitätsbasierten Konsensmechanismus aufbauen wollen, bei dem verschiedene Nodes einen gewichteten Einfluss auf den Konsensprozess haben, müssen wir eine weitere Anpassung an unserem Protokoll vornehmen.
Um jede Message mit dem Stimm-Gewicht ihres Absenders in Verbindung bringen zu können, lassen wir jede Node seine Message signieren.
Zusätzlich zu den beiden Hashes fügen wir jeder Message die Identität und Signatur der ausstellenden Node hinzu.
Auf diese Weise kann jede Message objektiv einem bestimmten Aussteller zugeordnet werden, der einen gewissen Einfluss auf den Konsensprozess hat.
Anmerkung: In Zeiten geringer Akzeptanz werden die einflussreichsten Nodes in regelmäßigen Abständen leere Nachrichten ausgeben, um das Netzwerk zu sichern.
Message payloads & layers
Um datenzentrierte Anwendungsfälle zu ermöglichen, können Messages nicht nur Transaktionen, sondern auch beliebige data payloads (dt. Daten-Nutzlasten) transportieren.
Die ersten Bytes jeder Payload kodieren ihren Typ, der verwendet werden kann, um die Art und Weise, wie sie geparst (parsen) und in ihre speicherinterne Darstellung übersetzt wird, dynamisch zu ändern.
Genauso wie TCP/IP die Definition zusätzlicher Protokolle auf seinem generischen Datensegment erlaubt, können wir auf diese Weise Protokolle auf höherer Ebene erstellen.
Anmerkung: Nicht transaktionsbezogene Payloads werden immer dem Hauptzweig (Master Branch) zugeordnet, da sie kein inhärentes und gemeinsames Konzept von Konflikten auf Layer 1 haben.
Dezentrale Anwendungen und Virtual Machines
Nodes können Plugins installieren, die eine Payload spezifische Virtual Machine definieren, die die verschiedenen Payload-Typen analysiert und verarbeitet, um eine dezentralisierte Anwendung zu erstellen, die ihren Zustand unter allen anderen Nodes repliziert, die das gleiche Plugin installiert haben.
Plugins verwenden eine ereignisgesteuerte Architektur, um auf Messages zu warten, die die entsprechenden Payload-Typen enthalten.
Da jede DLT Messages verwendet, die zwischen den Nodes repliziert werden, um einen Konsens zu erreichen, ist es sogar möglich, zusätzliche DLTs mit anwendungsspezifischen Konsensalgorithmen innerhalb dieser Virtual Machines zu betreiben.
Die Nodes können individuell entscheiden, welche Payloads verarbeitet werden sollen, aber um einen guten Grad an Dezentralisierung zu erreichen, muss die dezentralisierte Anwendung eine angemessene Anzahl von Teilnehmern haben.
Messages, die Payloads enthalten, an denen eine Node nicht interessiert ist, werden immer noch ge-gossiped (geklatscht), benötigen aber sehr wenig Rechenaufwand, da sie als generische Datenfragmente behandelt werden.
Anmerkung: Ein Proof of Concept für eine dezentrale und zensurresistente Chat-Anwendung finden Sie im GitHub-Repository.
Parent types (übergeordnete Typen)
Da auch ein virtueller Abstimmungsmechanismus immer noch ein Abstimmungsmechanismus ist, bei dem das Ergebnis nicht von vornherein feststeht, kann und wird es vorkommen, dass ehrliche Nodes ihre Messages an einen Teil der DAG anhängen, der sich nicht als der siegreiche herausstellt, und die Payloads dieser Messages müssten später erneut angehängt werden.
Eine Node, die sowohl den roten als auch den grünen Zweig mag, kann niemals beide genehmigen, da sie auch Blau genehmigen würde.
Dies führt zu einem spieltheoretischen Problem, bei dem die Nodes einen Anreiz hätten, ihre Messages an ältere Messages anzuhängen, die bereits entschieden sind.
Wären alle Nodes rational und würden ihre Tip-Selection entsprechend ändern, könnten wir bei der Abstimmung keine Fortschritte machen, da keine neuen Messages eintreffen würden, die die Konflikte bestätigen und das System zu einem Ergebnis bringen würden.
Der Grund, warum ehrliche Messages, die gültige Payloads enthalten, nicht genehmigt werden können, wenn sie sich auf den falschen Teil der DAG beziehen, liegt darin, dass sich die Genehmigung immer auf den gesamten Past Cone einer Message bezieht und eine Message, die zwei Double Spends genehmigt, als ungültig angesehen wird.
Um dieses Problem zu lösen, führen wir verschiedene Arten von Parent-Referenzen ein, die unterschiedliche Bedeutungen haben:
Strong parent: Stimmt für die referenzierte Message und alles in deren Past Cone.
Message4 erbt alle Verzweigungen der referenzierten Messages (einschließlich ihres Past Cones).
Weak parent: Stimmt für die referenzierte Message und für nichts in ihrem Past Cone.
Message4 referenziert Message3 mit einem weak parent und ignoriert die Zweige in seinem past cone (blau)
Like parent: Stimmt für die referenzierte Message und alles in ihrem past cone (und wenn es widersprüchliche Zweige im anderen parent gibt, dann haben die in diesem angegebenen parent Vorrang).
Message4 ignoriert den blauen Zweig, da er mit dem grünen in Konflikt steht und wird Grün mehr mögen (mit unserem speziellen Like Parent)
Mit diesen neuen Referenztypen können Nodes nun unabhängig von ihren Referenzen auf andere ehrliche Messages verweisen.
Schlussfolgerung
Wir haben die High-Level-Spezifikation für ein neues Base-Layer-Voting-Protocol vorgelegt, das ausschließlich auf Satoshis Nakamotos Ideen basiert und das es den Nodes erlaubt, Transaktionen vollständig asynchron und in Echtzeit zu verarbeiten.
Das resultierende Protokoll ist nicht nur konzeptionell sehr einfach, sondern hat auch einige andere wünschenswerte Eigenschaften:
- Das Protokoll ist skalierbar (es unterstützt eine unbegrenzte Anzahl von Nodes und Validatoren).
- Das Protokoll ist robust (es funktioniert auch dann noch, wenn Validatoren plötzlich verschwinden – das Einzige, was wir brauchen, um Entscheidungen zu treffen, ist eine relative Wahrnehmung des Stimmen-Gewichts).
- Das Protokoll ist schnell (die Bestätigungszeiten sind nahezu in Echtzeit).
- Das Protokoll ist sicher (widerstandsfähig gegen byzantinische Angreifer).
- Das Protokoll bietet Fehlertoleranz bei Abstürzen (Nodes, die nicht richtig funktionieren, haben eine Möglichkeit, den Fehler zu beheben).
- Das Protokoll bietet Unveränderlichkeit (da Messages durch Hashes miteinander verknüpft sind, können frühere Entscheidungen nicht geändert werden, wenn wir davon ausgehen, dass sich die Nodes auf die richtige Menge von Tips einigen können).
- Das Protokoll ist effizient (es hat keinen unnötigen Overhead irgendwo im Protokoll – es sendet nicht einmal Stimmen).
- Das Protokoll ist maximal zensurresistent (keine Instanz kontrolliert den Schreibzugriff auf den Ledger – nicht einmal ein Miner).
- Das Protokoll ist flexibel (kompatibel mit jeder Art von Sybil-Schutz – z.B. PoW, PoS, dPoS, VDFs, permissioned committees und so weiter).
Obwohl die Konzepte aus konzeptioneller Sicht sehr einfach sind, ist es dennoch eine große technische Herausforderung, da es viele voneinander abhängige Layer gibt, die alle Hand in Hand arbeiten müssen.
Wir mussten mehrere neue Datenstrukturen und Indextypen erfinden, die es uns ermöglichen, all dies effizient zu verwalten und in mehr oder weniger O(1) auszuführen, und wir sind immer noch dabei, Teile der Codebasis zu optimieren.
Ich glaube, dass man davon ausgehen kann, dass die hier vorgestellten Konzepte das einfachste und effizienteste Abstimmungsprotokoll darstellen, das man jemals entwickeln könnte. Es ist sehr unwahrscheinlich, dass wir jemals besser werden, als nur zwei Hashes zu jeder Transaktion hinzuzufügen (ich wäre wirklich überrascht, wenn man es mit einem einzigen schaffen würde).
– – –
Aber der effizienteste Abstimmungsmechanismus ist noch nicht der effizienteste Konsensmechanismus, und wir werden unser Protokoll in den kommenden Teilen dieser Serie weiter verbessern und erweitern.
ELI5
Wir haben ein Protokoll entwickelt, das es Nodes erlaubt, direkt in ein Distributed Ledger zu schreiben, ohne Mittelsmänner und einfach indem sie Transaktionen mit ihren Nachbarn teilen.
Jede Transaktion trägt einen kleinen Sticker (Hinweis) von wenigen Bytes, und die Nodes können einen Konsens erreichen, indem sie sich einfach die Sticker ansehen, ohne zusätzliche Messages austauschen zu müssen.
Das Protokoll ist ebenso robust und sicher wie Satoshis Blockchain und funktioniert auch dann noch, wenn eine sehr große Anzahl von Nodes offline genommen wird.