Elronds Design-Begründung

6 min readOct 27, 2020

Hinweis: In diesem Artikel beziehen wir uns auf eine Node/Einheit im Netzwerk, die zu einem bestimmten Zeitpunkt für das Vorschlagen eines neuen Blocks verantwortlich ist, während der/die Validierer die Nodes/Einheiten benennen, die für die Validierung des vom Antragsteller vorgeschlagenen Blocks verantwortlich sind und somit effektiv für den Antragsteller “bürgen”.

Die beiden Probleme, die Elrond von Anfang an zu lösen versucht, sind die Erhöhung des Durchsatzes — erreichbar durch Shards und Senkung des Energieaufwands — und durch den Übergang von einem auf dem Arbeitsnachweis (proof-of-work) basierenden Konsens zu einem “proof-of-stake”-Konsens. Jeder dieser beiden Bereiche erfordert unterschiedliche Aspekte, die beim Entwurf der Architektur und der Komponenten um sie herum zu berücksichtigen sind.

Der PoS-Aspekt muss um alle (bzw. meisten?) gemeinsamen Probleme in PoS-Systemen herum bearbeitet werden — und damit Anreize für rationales Verhalten schaffen. Der Sharding-Aspekt benötigt Mechanismen, um Vereinbarungen innerhalb jedes kleineren Teils des Netzwerks (Shard) zu erreichen, sowie eine Einigung zwischen den Teilnehmern an einer Transaktion, die sich über mehrere Shards erstreckt. Und all dies muss auch das potenzielle byzantinische (kontradiktorische) Verhalten berücksichtigen.

Bevor wir über irgendetwas sprechen, lassen Sie uns einen gemeinsamen Ansatz für die Blockchain auf der Grundlage von Proof-of-stake beschreiben: Jeder neigt dazu, Zeit mit zwei Einheiten zu messen; die offensichtliche nennt man Blockzeit (das Intervall zwischen zwei aufeinanderfolgenden Blöcken), aber auch Epoche oder Ära bei einer höheren Ordnung. Unter diesem Gesichtspunkt ist das Intervall, das erforderlich ist, um eine bestimmte Anzahl (X) von Blöcken zu erzeugen, eine Epoche (also immer Epoche = X * Blockzeit).

Kenne deinen Feind…

Alle PoS-Blockchains, die heute existieren oder nur theoretisiert sind, verwenden kryptoökonomische Anreize, um sicherzustellen, dass das Verhalten der Menschen (als ihre Netzwerkpersonen, die durch Nodes repräsentiert werden) einem erwarteten Muster folgt — Nodes werden belohnt, wenn sie gute Dinge (für das Netzwerk) tun, und sie werden bestraft, wenn sie schlechte Dinge tun. Während in einigen Fällen bei diesem Zuckerbrot-und-Peitsche-Ansatz eine Seite der Gleichung überbetont wird (d.h. es gibt Fälle, in denen es keine Strafen für gegnerisches Verhalten gibt), sind diese beiden Seiten in den meisten Fällen ausgeglichen. Erwähnenswert ist auch, dass Bestrafungen weitgehend mit einem Einsatz verbunden sind, die jede Node für einen vordefinierten Zeitraum (normalerweise mehrere Epochen) einsperrt. Das gegnerische Verhalten in Abwesenheit dieses gesperrten Einsatzes, die jede Node (teilweise oder ganz) verlieren kann, wird als Nothing-at-stake-Angriff bezeichnet.

Eine andere Art von feindseligem Verhalten im Zusammenhang mit gesperrten Einsätzen besteht darin, dass ein Node Teil des “Entscheidungsprozesses” ist, dann aus diesem Prozess aussteigt und seinen Einsatz zurückholt. Einige Zeit nach diesen Ereignissen kann der Node/die Einheit mit Hilfe der mit dem Einsatz verbundenen Berechtigungsnachweise (d.h. Schlüssel) versuchen, eine andere Geschichte zu “fälschen” (entweder selbst oder indem er diese Berechtigungsnachweise einer böswilligen Partei zur Verfügung stellt); auf diese Weise wird der Angriff in einen verzögerten Angriff auf nichts auf dem Spiel, der gewöhnlich als Long-range-Angriff bezeichnet wird, verwandelt. Unter diesem Gesichtspunkt dargelegten Begriffe ist es wichtig, dass die Freigabe des Einsatzes erst dann erfolgt, wenn die von dem diskutierten Node vorgeschlagenen oder bestätigten Blöcke abgeschlossen sind.

Bei einigen Arten von Langstreckenangriffen, die in Blockchains durchgeführt werden die Strafen vorsehen (im Prinzip solche mit Lebendigkeitszielen) könnte die Veröffentlichung dieser alternativen Geschichte den Eindruck erwecken, dass einige der Nodes ihre Pflichten nicht erfüllt haben und daher (ungerecht) bestraft werden. Diese Art von feindseligem Verhalten wird als Stake-Bleeding-Angriff [SB] bezeichnet.

Auch kann es Situationen geben, in denen Nodes durch Gegner vom Netzwerk isoliert sind, die ihnen ein verzerrtes Bild der Realität “vorgeben” (z.B. nur Transaktionen von ihren “Freunden” weiterleiten und legitime Transaktionen zensieren). Diese Arten von Angriffen werden als Eclipse-Angriffe bezeichnet.

…kennen sie auch Ihre Schwächen, um dem entgegenzuwirken

Wie bereits dargelegt, müssen PoS-Systeme im Umgang mit Gegnern einige Schwachstellen abdecken. Die zwei Wichtigsten sind:

Extern: Die DoS-ing (oder anderweitige Beeinträchtigung) des/der aktuellen Validierer(s) oder des aktuellen Antragstellers, so dass die PoS-Systeme nicht in der Lage sind, mit dem Rest der Nodes zu kommunizieren und keine Entscheidungen treffen können. Dies wirkt sich offensichtlich auf die Lebensdauer der Blockchain aus, kann aber auch die Sicherheit beeinträchtigen (und damit zu unvorhersehbaren Ergebnissen führen).
Intern: Nodes (Identitäten oder Entitäten), die in einem bestimmten Schritt ausgewählt werden, um eine der “offiziellen” Rollen für den/die nächsten Schritt(e) zu übernehmen, können sich kontradiktorisch verhalten (z.B. ungültige Blöcke vorschlagen, sich weigern, an Kollektivzeichnungsverfahren teilzunehmen usw.)

In einem anderen Artikel beschreiben wir die drei Arten von Sharding im Detail — Netzwerk, Transaktion und Zustand. Wir haben uns für das State-Sharding entschieden und als Antwort auf diese beiden soeben skizzierten Probleme zwei Konzepte entwickelt, die wir Secure Proof-of-Stake und Adaptive-State-Sharding genannt haben.

Ein neuartiger Ansatz für kontradiktorisches Verhalten durch robuste Anpassungsfähigkeit

Jedermanns Intuition sagt, je länger im Voraus ein Gegner über den Vorschlagenden-Node und/oder Validator-Node Bescheid weiß — ausgehend von der Nodeidentität, aber vielleicht auch von ihren “Netzwerk-Koordinaten” — desto mehr Schaden kann dieser Gegner der Node (und damit auch dem Netzwerk) zufügen. Ein noch schlimmeres Szenario ist, wenn der Gegner, indem er lange im Voraus weiß, wer für einen bestimmten Blockvorschlag verantwortlich sein wird, mit dem besagten Vorschlagenden (oder Validierer) kollaborieren kann, so dass sie ungültige Blöcke vorschlagen (oder validieren z.B. eine doppelte Ausgabe oder erlauben Token aus dem Nichts zu prägen — nicht unähnlich dem, was Zentralbanken heute tun!!! :-D). Folglich ist es wünschenswert, die Rolle eines Nodes für einen bestimmten Schritt (Block) so wenig wie möglich im Voraus zu kennen.

Um dieses Rätsel zu lösen, haben wir folgenden Ansatz gewählt: Wir verwenden die aktuelle Blocksignatur als Zufallsquelle und wählen darauf aufbauend a/ aktueller Antragsteller und b/ aktueller Validatorensatz. Eine Möglichkeit dies zu erreichen besteht darin, dass jeder Berechtigte eine verifizierbare Zufallsfunktion (Verifiable Random Function, VRF) auf dem aktuellen Blockhash ausführt und eine Zufallszahl erhält (und einen Beweis dafür, dass die Zufallszahl von der gewählten VRF korrekt erzeugt wurde).

Die Zufallszahlen sind angeordnet (sagen wir niedrig bis hoch) und die erste (Hersteller der kleinsten Zahl) ist der Antragsteller, die nächsten N sind die Validierer. Auf diese Weise kann der Vorschlagende zwar einen bestimmten Block auswählen, aber er kann nicht sagen, ob die anderen Konsensteilnehmer im nächsten Schritt eine vielleicht kleinere Zufallszahl erhalten werden.

Um die Dinge für byzantinische Nodes noch schwieriger zu machen, haben wir auch ein Verfahren entwickelt, bei dem von Zeit zu Zeit (sagen wir jede Epoche) ein Teil der Shard Nodes verschiedenen Shards zugeordnet wird, ohne dass jemand im Netzwerk im Voraus sagen kann, welche Node neu zugeordnet wird und auf welchen Shard er darüber hinaus verschoben wird. Der Neuzuordnungsprozess kann wiederum das Ergebnis der Ausführung eines VRF sein.

Die Besonderheit, die wir bei der Entwicklung unserer Zuckerbrot-und-Peitsche-Mechanismen eingesetzt haben, besteht darin, dass jeder Nodes neben Belohnungen und Kürzungen eine Bewertung haben wird, die die Sicht des Netzwerks auf das Verhalten des besagten Nodes repräsentiert. Wenn man sich an die Regeln hält, erhöht sich die Bewertung des Nodes (bis zu einer Grenze), während sie sich bei feindseligem Verhalten verringert.

Diese Bewertung wird bei der Berechnung der einsatzbezogenen Wahrscheinlichkeiten mit dem Einsatz der Node kombiniert — d.h. am Ende entsteht eine Gewichtung des Einsatzes des Benutzers. Positive Bewertungen wirken so, als ob der Anteil der Node größer als der tatsächliche Anteil ist, während negative Bewertungen den gleichen Effekt haben wie eine Senkung des Anteils der Node. Tatsächliche Belohnungen und Bestrafungen könnten ebenfalls von dieser Bewertung beeinflusst werden. Damit würde ein positives Verhalten einer Node auf lange Sicht mehr Vorteile bringen als ein Negatives, wenn man von demselben Einsatz ausgeht.

Zum Mitnehmen

Zusammenfassend lässt sich sagen, dass wir diese neue Blockchain-Architektur aufbauen wollen, indem wir die optimalen (unserer Meinung nach) Mechanismen finden:

Anreize für gutes Verhalten schaffen — indem Entitäten, die “spielen” wollen, aufgefordert werden, “ihren Worten Taten folgen zu lassen”, während gleichzeitig Belohnungen für die Teilnahme am Konsensverfahren vorgesehen sind.
Minimierung bestimmter Entscheidungen und die Anfälligkeit der Teilnehmer für Angriffe, indem einige Entscheidungen (Shardzuweisung, Gruppen- und Führerwahlen) auf der Grundlage einer Zufallsquelle (Block- und Nodesignaturen) getroffen werden.
Eliminierung (oder zumindest drastische Reduzierung der Wahrscheinlichkeit von Kollusion) durch gelegentliches Mischen von Nodes in Shards und auch durch Rollenwechsel innerhalb eines Shards