AleoBFT: Entdecken Sie die Konsensebene von Aleo 

Datum und Autor des offiziellen Blogbeitrags:
13. Januar 2025
VON ZK Lim , DevRel Engineer
Übersetzt von discord: egormajj

In jedem dezentralen System oder jeder Blockchain ist ein Konsensmechanismus unerlässlich, damit es ordnungsgemäß und vertrauensfrei funktioniert. Aleo verwendet AleoBFT (Aleo Byzantine Fault Tolerance), einen DAG-basierten (Directed Acyclic Graph) Konsensalgorithmus, der weitgehend von Bullshark und Narwhal inspiriert ist und Erweiterungen für dynamische Komitees und Staking bietet. Darüber hinaus wird AleoBFT formal mit einem Beweis verifiziert, der zeigt, dass Blockchains von verschiedenen Validierern sich niemals verzweigen, was die Richtigkeit des Systemdesigns gewährleistet. Lesen Sie hier im Blog mehr über die formale Verifizierung .

In diesem Artikel erfahren Sie, wie AleoBFT es Aleo Network ermöglicht, durch seinen innovativen Konsensmechanismus einen hohen Transaktionsdurchsatz und robuste Sicherheit zu erreichen, indem es die effiziente Datenverbreitung von Narwhal mit dem optimierten Bestellprozess von Bullshark kombiniert. Sie werden verstehen, wie diese Architektur Aleo dabei hilft, zu skalieren, während gleichzeitig die Dezentralisierung erhalten bleibt und Blockchain-Forks verhindert werden, was sie zu einer leistungsstarken Grundlage für datenschutzwahrende Blockchain-Anwendungen macht.

Narwale verstehen

Narwhal ist ein DAG-basiertes Mempool-Abstraktionsprotokoll, das mit jedem Konsensmechanismus arbeiten kann. AleoBFT basiert auf der Zusammensetzung von Narwhal und einer teilweise synchronen Version von Bullshark. Narwhal erleichtert die Kommunikation von Transaktionen (eine Art der Übertragung auf Aleo) zwischen Knoten, sammelt Zertifikate und erstellt den DAG mit hohem Durchsatz. Ein DAG wird mit Zertifikaten als Eckpunkten des Graphen gebildet, während die Kanten durch Links dargestellt werden, die ein Zertifikat mit einer bestimmten Anzahl von Zertifikaten aus der vorherigen Runde verbinden. Jedes Zertifikat kann höchstens einen Autor pro Runde haben.

Die folgende Abbildung zeigt eine Visualisierung, wie ein DAG aussehen würde:

Narwhal kann jedoch nur eine kausale Reihenfolge bereitstellen – und hier kommt Bullshark ins Spiel. Durch einfaches Beobachten und Interpretieren des von Narwhal erstellten DAG kann Bullshark eine einzelne, endgültige Reihenfolge ohne Nachrichten-Overhead erstellen (d. h. es sind keine zusätzlichen Nachrichtenaustausche erforderlich). Die Commits dieser Gesamtreihenfolge bilden die endgültige „Blockchain“ des Netzwerks.

Narwhal funktioniert, indem die Datenverbreitung vom Konsens abgezogen wird, so dass dem Konsens nur kleine Referenzen mit fester Größe zur Sequenzierung der Transaktionen verbleiben, was die Leistung deutlich steigert.

Bildquelle - https://www.youtube.com/watch?v=NGOXVSFzYdI&t=2072s

So funktioniert Narwhal

Jeder Validator führt mehrere Worker-Instanzen und einen einzelnen Primär-Validator aus. Die Worker teilen kontinuierlich Transaktionsstapel mit anderen Validatoren im Hintergrund und erstellen einen Digest für den Primär-Validator. Dieser Digest stellt auch ein Verfügbarkeitszertifikat für die zugrunde liegenden Daten (Transaktionen) dar. Der Konsens muss nur Block-Digest-Zertifikate bestellen, die im Vergleich zu den ursprünglich umfangreichen Transaktionsdaten viel kleiner sind.

Die Integrität der Transaktionsdaten und die Verfügbarkeit der Blockdaten werden durch die Überprüfung des Digests über andere Validierer sichergestellt. Anstatt Transaktionen direkt in Blöcke aufzunehmen, nimmt der Primärblock alle kryptografischen Hashes seiner eigenen Worker-Batches in den nächsten Block auf. Dies führt zu kleineren Primärblöcken.

Der DAG-Aufbauprozess (und darüber hinaus)

Der DAG wird in mehreren Runden aufgebaut. Zu Beginn jeder Runde müssen nf Zertifikate aus der vorherigen Runde von unterschiedlichen Validierern gesammelt werden. Dabei stellt n die Gesamtzahl der Validierer und f die Anzahl der byzantinischen oder fehlerhaften Validierer dar. nf stellt sicher, dass das Netzwerk nur Werte akzeptiert, denen mehr als zwei Drittel aller Validiererknoten zugestimmt haben.

Während der Runde sendet jeder Validierer einen Vorschlag an andere Validierer. Die anderen Validierer bestätigen den Vorschlag, indem sie ihn unterzeichnen und als Bestätigung an den Absender zurücksenden. Sobald nf Bestätigungen für einen Block gesammelt wurden, ist ein Quorum erreicht. Der Validierer kombiniert diese Bestätigungen dann zu einem Zertifikat der Blockverfügbarkeit und sendet dieses Zertifikat an alle anderen Validierer, sodass diese es in ihre nächste Runde aufnehmen können. Die Validierer können erst in die nächste Runde übergehen, nachdem sie eine bestimmte Anzahl von Zertifikaten gespeichert haben. Die Validierer können ihre aktuelle Runde auch unter anderen Bedingungen fortsetzen, z. B. wenn der Timer abgelaufen ist und die Runde bereits so viele Zertifikate hat wie die Quorum-Zahl, um sich an Netzwerkverzögerungen anzupassen, die die Zertifikatsübermittlung beeinträchtigen.

Bildquelle - https://www.youtube.com/watch?v=NGOXVSFzYdI&t=2133s

Nachdem der DAG erstellt wurde, hilft Bullshark beim Ordnen (oder Interpretieren) der Blöcke, ohne dass eine zusätzliche Kommunikation zwischen den Validierern erforderlich ist, und der Verlauf kann festgeschrieben und abgeschlossen werden.

Dank der Art und Weise, wie Narwhal den DAG konstruiert, profitiert er von Eigenschaften wie der Nicht-Mehrdeutigkeit. Das bedeutet, dass, wenn zwei ehrliche Parteien in einer Runde ein von derselben Partei erstelltes Zertifikat haben, die Zertifikate identisch sind (d. h. die Transaktionsdaten und Kanten sind genau gleich). Die Anforderungen an Signaturen und Kanten stellen sicher, dass zwischen den DAGs verschiedener Validierer genügend Konsistenz besteht.

Dies vereinfacht die Ordnungslogik erheblich und macht einen Mechanismus zum Ändern der Ansicht im Falle eines Leader-Fehlers oder einer Ineffizienz überflüssig. Der DAG kodiert alle erforderlichen Informationen, sodass sich jeder Knoten ausschließlich auf seine lokale Ansicht verlassen kann, um die Gesamtreihenfolge zu interpretieren. Für jede gerade Runde kann potenziell ein neuer Block erstellt werden, obwohl dieser manchmal übersprungen werden kann, wie unten erläutert.

Bildquelle

In jeder geraden Runde wird durch deterministische Berechnung ein Leader ausgewählt, ein Prozess, der allen Validierern bekannt ist. Wenn ein Zertifikat vom Leader erstellt wurde, wird es als Anker bezeichnet. Wenn der Anker in nachfolgenden ungeraden Runden eine ausreichende Anzahl eingehender Kanten (Stimmen) von Zertifikaten hat, wird er festgeschrieben. Die Festschreibungsregel ist unkompliziert: Ein Anker muss mindestens 1+f Stimmen erhalten, um festgeschrieben zu werden.

Aufgrund der asynchronen Natur des Netzwerks kann die lokale Ansicht des DAG zwischen den Parteien unterschiedlich sein. Beispielsweise kann Anker A1 von einigen Parteien hinzugefügt werden, auch wenn Partei 1 ihn noch nicht erkannt hat. Da die Commit-Regel jedoch mindestens 1+f Stimmen erfordert und jedes Zertifikat mindestens nf Kanten zum vorherigen Zertifikat enthält, ist garantiert, dass, wenn eine Partei sich zu Anker A1 verpflichtet, alle Anker in höheren Runden einen Pfad zu A1 haben, wie mit A3 dargestellt.

Dies bedeutet auch, dass, wenn in zukünftigen Runden kein Pfad zu einem Anker existiert, dieser Anker nicht festgeschrieben wird, sodass er sicher übersprungen werden kann. Dieses Verhalten kann im Fall von Anker A2 in der Abbildung beobachtet werden.

Vorteile gegenüber dem traditionellen Konsens

Dieses Protokoll stellt nicht nur sicher, dass alle Validierer in derselben Reihenfolge dieselben Anker festlegen, sondern erreicht auch einen deutlich höheren Durchsatz im Vergleich zu herkömmlichen, auf Leadern basierenden Konsensprotokollen. In herkömmlichen Systemen trägt der Leader den größten Teil der Arbeitslast und verbraucht dabei häufig erhebliche Ressourcen, während die Ressourcen anderer Validierer nicht ausgelastet bleiben, da sie darauf warten, Daten vom Leader zu erhalten.

Weitere Informationen zu AleoBFT finden Sie in der Entwicklerdokumentation .