Der Avalanche Konsensus

In diesem Artikel wird der Avalanche-Konsensus in einfachen Worten erklärt

Im Jahr 2018 führte die pseudonymisierte Gruppe Team Rocket das Avalanche-Konsensus-Protokoll ein. Dieser Beitrag beschreibt das Protokoll mit seinen Eigenschaften, stellt es in den Vergleich zu anderen Ansätzen und beschreibt die technischen Grundlagen, die das Protokoll so einzigartig machen.

Was ist ein Konsensus?

Ein Konsensus ist eine Möglichkeit, mit welcher unabhängige Wähler (“Validatoren”) zu einer Einigung über eine bestimmte Entscheidung kommen. Auf den ersten Blick klingt das Verfahren unkompliziert: Man muss herausfinden, ob ein Datenelement mit den Regeln des Systems übereinstimmt und ob der Rest des Netzwerks ebenfalls mit dieser Einschätzung übereinstimmt.
Konsensus-Protokolle (wie “Avalanche”) erleichtern die Einigung zwischen allen Validatoren und stellen sicher, dass das Netzwerk synchron läuft. Robuste Konsensus-Protokolle funktionieren auch dann, wenn einige Validatoren im Netzwerk fehlerhaft sind.
Am Ende dieses Prozesses teilen sich alle Nodes die gleichen Daten, die als “State” bezeichnet werden und auf die man sich in diesem Entscheidungsprozess geeinigt hat. Wenn eine widersprüchliche Transaktion einen Node durchläuft und nicht in voller Übereinstimmung mit dem Rest des Netzwerks ist, wird dies als “Sicherheitsverletzung” bezeichnet. Das bedeutet, dass mindestens ein Validator mit den anderen Validatoren im Netzwerk inkonsistent ist. Der Zweck von Konsensus-Protokollen besteht darin, die Wahrscheinlichkeit von Sicherheitsverletzungen im Netzwerk so weit wie nur möglich zu minimieren.

Die Historische Entwicklung des Konsenses

In der 45-jährigen Geschichte der dezentralen Systeme gab es nur drei Ansätze zur Lösung des Konsensus-Problems: Klassisch, Nakamoto und Avalanche. An dieser Stelle sollen diese drei Ansätze diskutiert werden, um darzustellen, was diese voneinander unterscheidet.

Klassische Protokolle
Klassische Konsensus-Protokolle wie Praktische Byzantinische Fehlertoleranz (Practical Byzantine Fault Tolerance, PBFT) und HotStuff basieren auf der Alle-zu-Alle-Abstimmung. Das bedeutet, dass ein Validator von einer großen Anzahl von Nodes informiert werden muss, um eine Entscheidung zu treffen.
Der klassische Konsensus hat zwei Hauptprobleme.

1. Ihre Korrektheit hängt stark davon ab, dass jeder im System die Identitäten der Validatoren, aus denen das System besteht, zu jedem Zeitpunkt kennt und ihnen zustimmt. Darüber hinaus benötigt ein Angreifer nur die Kontrolle über 33% des Netzwerks, um einen Angriff zu starten, dessen Erfolg garantiert ist.
2. Diese Systeme sind zwar schnell, skalieren aber nicht gut, wenn die Anzahl der Teilnehmer stark ansteigt. Das am besten skalierbare klassische Protokoll HotStuff (übrigens von Ted Yin entworfen, der jetzt am Avalanche-Protokoll arbeitet), welches von der Facebook-Libra verwendet wird, unterstützt nur etwa 100 Validatoren, bevor die Leistung wieder abnimmt.
   Diese beiden Mängel machen den Klassischen Konsensus zu einem unrentablen Kandidaten für offene Netzwerke, in denen die Nodes dem Netzwerk nach Belieben beitreten und dieses auch wieder verlassen können.

Nakamoto-Konsens
Mehr als ein Jahrzehnt lang waren byzantinische fehlertolerante Systeme ein Novum, weil der klassische Konsensus nicht in der Lage war, allen Bedürfnissen gerecht zu werden. Dann tauchte aus dem Nichts Satoshi Nakamoto auf, schrieb das Bitcoin-Whitepaper und zeigte der Welt, dass es möglich ist, ein gegnerresistentes Konsensprotokoll zu schaffen, das auf globaler Ebene funktioniert. Nakamoto erreichte dies, indem er das Konsensus-Problem neu definierte und die Korrektheitsdefinition (correctness definition) probabilistisch machte.

Nakamoto ist unbestreitbar ein Durchbruch als robustes und globales Protokoll, aber es hat auch Nachteile: Es ist langsam, verbraucht viel Energie und es dauert sehr lange, bis man Vertrauen in die Finalität einer Transaktion hat. Das sind zwar akzeptable Nachteile für einen Vermögenswert, der sich nur selten bewegt oder als Reserve dient, aber sie sind eine zu große Belastung für Anwendungsfälle wie Peer-to-Peer-Zahlungen und dezentralisierte Finanzen.

Avalanche
Im Mai 2018 wurde von einer pseudonymen Gruppe namens Team Rocket ein Paper erstellt, welches eine dritte Klasse von Konsensus-Protokollen vorschlug, die sie als Avalanche bezeichneten. Mit all den Vorteilen des klassischen Konsenses und der massiven Dezentralisierung des Nakamoto-Konsenses bewies Avalanche, dass klassische Protokolle verallgemeinert werden können, um sich probabilistisch zu verhalten und dadurch massive Leistungsverbesserungen zu erzielen.

Wenn Sie detaillierte Informationen zum Thema Avalanche lesen möchten, besuchen Sie bitte https://avalabs.org/whitepapers.

Was ist der Avalanche-Konsensus?
Der Avalanche-Konsensus ist, wie der Nakamoto-Konsensus, ein probabilistisches Protokoll. Avalanche macht die Fehlerwahrscheinlichkeit mikroskopisch klein.
Avalanche kann den Fehler sogar so klein machen, dass es noch unwahrscheinlicher ist, dass eine Sicherheitsverletzung an einem Avalanche-Knoten auftritt, als die Wahrscheinlichkeit eine SHA-256-Hash-Kollision zu finden. Um diesen Vergleich besser zu verstehen: Es ist wesentlich wahrscheinlicher, dass ein lebensgefährlicher Asteroid in den nächsten hundert Jahren mit der Erde kollidiert, als dass eine SHA-256-Kollision in den nächsten tausend Jahren vom Netzwerk entdeckt wird, welches 1 Quintillion Hashes pro Sekunde berechnet.
Avalanche schließt auch alle Transaktionen sofort ab, ohne auf Bestätigungen zu warten. Avalanche ist dazu in der Lage, weil es sich um eine Verallgemeinerung gegenüber dem klassischen Konsens handelt, so dass es diese sehr wünschenswerte Eigenschaft erhält. Tatsächlich sind bei Avalanche die Transaktionen im Durchschnitt in weniger als einer Sekunde abgeschlossen. Dies ist im Vergleich zu bestehenden dezentralisierten Netzwerken sehr schnell.
Avalanche erfordert keine spezialisierte (sprich: teure) Hardware, um mehr als 4.500 Transaktionen pro Sekunde zu erreichen. Das bedeutet, dass der Computer, den Sie bereits haben (oder sogar der, der in Ihrem Schrank Staub sammelt), leistungsstark genug ist, um Avalanche auszuführen. Diese Kombination macht die Avalanche-Knotenpunkte sowohl extrem umweltfreundlich als auch wirtschaftlich.

Besser noch als der Nakamoto-Konsensus, gibt es keine bekannte Obergrenze dafür, wie viele Personen an dem Netzwerk teilnehmen können — dasselbe gilt nicht für die klassischen Protokolle, deren Leistung sich mit größerer Beteiligung exponentiell verschlechtert.
Avalanche ist nicht wie der Nakamoto-Konsensus auf Arbeitsnachweise angewiesen. In Protokollen wie Bitcoin ist der Arbeitsnachweis sowohl für das Netzwerk als auch für die Sicherheit gegen unehrliche Akteure notwendig. Avalanche könnte Proof of Work verwenden, entschied sich aber für Proof of Stake, um die Benutzer dazu zu zwingen, eine gewisse Anzahl von Token zu besitzen, bevor sie über die jeweiligen Transaktionen abstimmen dürfen.
Schließlich funktionieren die Avalanche-Knotenpunkte im Gegensatz zu Bitcoin und anderen auf der Arbeit von Nakamoto basierenden Systemen, die fortwährende Aktionen erfordern, nur dann, wenn Arbeit zu erledigen ist. Es gibt kein Mining oder Abstimmungen, um neue Blöcke zu erhalten. Die Transaktionen werden an das breitere Netzwerk übertragen, welches diese dann übernimmt und mit der Abstimmung beginnt. Wenn es keine Transaktionen gibt, über die abgestimmt werden können, machen die Nodes im Netzwerk nichts anderes, als abzuwarten, bis neue Transaktionen da sind. Einfach ausgedrückt: Avalanche arbeitet intelligenter, nicht schwergängiger.
Anmerkung für Fortgeschrittene: Die wichtigste Eigenschaft von Avalanche ist, dass es wie der Nakamoto-Konsens ohne bekannte Obergrenze der Teilnehmer im Netzwerk arbeiten kann.

Wie der Avalanche-Konsensus funktioniert
Avalanche ist ein Abstimmungsprotokoll. Validatoren reagieren auf Transaktionen. Wenn sie eine Transaktion bemerken, stimmen sie darüber ab, ob eine Transaktion “akzeptiert” oder als “abgelehnt” gekennzeichnet werden soll. Transaktionen, die richtig erscheinen, werden von einem Validator als “angenommen” abgestimmt. Wenn sie widersprüchlich sind, wird über die Transaktion als “abgelehnt” abgestimmt. Ein Validator sieht eine Entscheidung, trifft eine erste Entscheidung und arbeitet dann mit dem Rest des Netzwerks zusammen, um festzustellen, ob das Netzwerk mit dieser Entscheidung einverstanden ist. Dies ist die gleiche Erwartung in klassischen Abstimmungsprotokollen, aber in Avalanche geschieht dies bei viel höheren Validatorzahlen.
Dieser Abstimmungsprozess in Avalanche ist das, was ihn so einzigartig macht. Jeder Validator ist ein völlig unabhängiger Entscheidungsträger. Es gibt keine Dominanz. Laut Protokoll verwendet jedoch jeder Knotenpunkt das gleiche Verfahren, um festzustellen, ob eine Entscheidung richtig ist und wie wahrscheinlich ein Konsens mit dem Rest des Netzwerks ist. Sobald sie eine hohe Wahrscheinlichkeit für eine Einigung im gesamten Netzwerk sehen, hält der Node ihre Stimme fest und akzeptiert eine Transaktion als endgültig.
Das Verfahren, mit dem festgestellt wird, ob eine Transaktion bevorzugt wird und dass der Rest des Netzwerks dieser Entscheidung zustimmt, wird als “Wiederholtes zufälliges Subsampling” bezeichnet.
Auf hoher Ebene bedeutet dies, dass ein Validierer andere Validierer nach dem Zufallsprinzip auswählt, um sie zu fragen, was sie bevorzugen. Der Validator tut dies immer und immer wieder an neuen zufällig ausgewählten Knoten, bis er genügend Daten aufbaut, um festzustellen, dass seine Wahrscheinlichkeit, korrekt zu sein, so hoch ist, dass Sie es genauso gut für unmöglich halten können, dass es falsch ist.

Im Einzelnen funktioniert es wie folgt:

1. Einem Validator werden eine Reihe von Transaktionen vorgelegt, die ausgestellt wurden, und er muss entscheiden, welche Transaktionen “akzeptiert” werden sollen.
2. Der Node-Client präsentiert den virtuellen Maschinen (“VMs”) ihre Transaktionen und die VMs liefern Informationen, die dem Client bei der Entscheidung helfen, welche Transaktionen zu akzeptieren sind.
3. Der Validator wählt eine Teilmenge dieser Transaktionen aus, die nicht in Konflikt miteinander stehen, markiert sie als bevorzugt und versucht, sie über das Netzwerk zu akzeptieren.
4. Jede Node, der diesen Validator abfragt, erhält seine letzte bevorzugte Wahl für diese Entscheidung.
5. Dieser Prüfer wählt K Knoten aus der gesamten Prüferliste aus (die Auswahlwahrscheinlichkeit wird nach der Höhe des Einsatzes gewichtet), um ihre bevorzugte Entscheidung abzufragen.
6. Jeder abgefragte Validator antwortet mit seiner bevorzugten Entscheidung, die Stimmen des Validators werden entsprechend aktualisiert und es wird Vertrauen aufgebaut.
7. In der Zwischenzeit wählen auch andere Nodes zufällige Validatoren aus, die für ihre bevorzugte Antwort abgefragt werden sollen und aktualisieren ihre Antworten entsprechend.
8. Dieser Prozess dauert mindestens M Runden oder bis eine ausreichende Vertrauensschwelle erreicht ist, je nachdem, was zuletzt eintritt, wobei in jeder Runde K Validatoren nach dem Zufallsprinzip ausgewählt werden (ohne Ersatz).
9. Sobald eine Vertrauensschwelle erreicht ist, wird die Entscheidung über die Transaktion als endgültig festgeschrieben.
10. Wenn “Akzeptiert”, wird die Transaktion zur Bearbeitung an die VM geschickt; wenn “Abgelehnt”, wird die Transaktion aus dem Konsens entfernt.

Das Team Rocket-Whitepaper zeigt, dass bei korrekter Parametrisierung, ein Netzwerk — welches diesen Prozess nutzt, mit einer parametrisierbaren Wahrscheinlichkeit — zur gleichen Entscheidung kommt.

Probabilistische Finalität
Die Wissenschaftler brauchen Gewissheit in ihren Modellen. Es ist durchaus wünschenswert, bei der Beschreibung eines Systems oder Prozesses sagen zu können: “Dieser Sachverhalt ist absolut wahr, ohne den Schatten eines Zweifels”. Klassische Protokolle streben nach diesem idyllischen Modell, aber in der realen Welt ist nichts sicher.
Bei 100 Validatoren in einem klassischen Netzwerk besteht die Chance, dass 33% von ihnen alle auf einmal offline gehen könnten oder dass jemand 33% von ihnen übernimmt und versucht, dem Netzwerk seinen Willen aufzuzwingen. Es besteht auch eine Wahrscheinlichkeit, welche nicht Null ist, dass der gesamte Sauerstoff in einem Raum durch zufällige Kollisionen auf die andere Seite springt und jeden, der das Pech hat, auf der falschen Seite zu sein, in einem Stickstoffpool ersticken lässt. Das ist möglich, aber die Wahrscheinlichkeiten sind so gering, dass sie für niemanden ein Problem darstellen.

Indem Avalanche eine sehr geringe Fehlerquote akzeptiert, nimmt es die Möglichkeit in Kauf, dass bei einem Modell mit den richtigen Parametern gerade ein einziges Mal in 20.000 Jahren ein Fehler auftritt. Es ist daher wahrscheinlicher, dass eine veraltete Internet-Infrastruktur massive Netzwerkausfälle verursacht. Es war diese Schlüsselerkenntnis, die dem Team Rocket half, den Weg für ein neues Konsensprotokoll zu ebnen, das wesentlich besser skaliert als die bestehenden klassischen Netzwerke.

Eine skalierbare, dezentralisierte Zukunft mit Avalanche
Klassische praktische byzantinische fehlertolerante Protokolle zeigen, dass ein Netzwerk trotz manipulativer Teilnehmer zu einem Konsens kommen kann. Nakamoto-Protokolle zeigten, dass probabilistische Protokolle in der Praxis sicher sind und eine beispiellose Dezentralisierung und Robustheit bieten können.

Indem ein Validator nach dem Zufallsprinzip andere Validatoren auswählt, um sie nach ihren Präferenzen zu fragen, schaffen die Teilnehmer von Avalanche Vertrauen in die richtige Entscheidung, die von allen Nodes im Netzwerk geteilt wird. Mit genügend Vertrauen wird eine Entscheidung sofort abgeschlossen. Dieser Prozess verläuft so schnell, dass Avalanche bei der Abwicklung von Transaktionen in einem Netzwerk mit den wichtigsten Zahlungssystemen konkurriert.

Die deutsche Community

• AVA Deutsch Telegram — https://t.me/avalanche_dach
• AVA Deutsch Twitter — https://twitter.com/avalanche_dach
• AVA Deutsch Medium Blog — https://medium.com/avalanche-dach