ImTeil 1,Wir haben untersucht, wie der klassische PBFT-Konsens funktioniert und wie frühere Versionen von HotStuff arbeiten. Wir haben auch betrachtet, wie MonadBFT das Problem des Tail-Forking von HotStuff löst, bei dem gültige Blöcke manchmal in pipelinierten Systemen zurückbleiben.

Dieses Schwanzgabelungsproblem führt zu zwei großen Problemen: 1) es vermasselt die Belohnungen für ehrliche Blockbuilder und 2) kann potenziell das Netzwerk zum Stillstand bringen.

MonadBFT führt die Reproposal-Regel und die No-Endorsement-Abstimmungsmechanismen ein, um das Problem des Tail-Forkings zu beseitigen und sicherzustellen, dass jeder ordnungsgemäß genehmigte Block eines ehrlichen Vorschlagsberechtigten immer in die Kette gelangt.

In Teil 2 erforschen wir die anderen beiden Charakteristika von MonadBFT, nämlich 1) spekulative Endgültigkeit und 2) optimistische Reaktionsfähigkeit. Wir werden auch die Auswirkungen von MonadBFT für Entwickler untersuchen.

Einmalige spekulative Endgültigkeit

Neben dem Widerstand gegen Schwanzgabeln ist ein weiteres wichtiges Merkmal von MonadBFT die spekulative Endgültigkeit innerhalb einer einzigen Runde.

In praktischen Begriffen bedeutet dies, dass Kunden und Benutzer unmittelbar nachdem ein Block eine überwältigende Mehrheit der Stimmen erhalten hat, eine Bestätigung für ihre Transaktion erhalten können, selbst bevor die nächste Runde abgeschlossen ist.

Erinnern Sie daran, dass in Protokollen Baseline HotStuff ein Block normalerweise nicht als endgültig (unumkehrbar) betrachtet wird, bis er mindestens zwei Phasen durchlaufen hat (z.B. Fast-Hotstuff & Diem-BFT): eine Phase, um ein Quorum-Zertifikat zu erhalten (den Block mit ≥2f+1 Stimmen zu sperren), und eine zweite Phase, in der der nächste Anführer auf diesem QZ aufbaut und den Block verpflichtet.

Diese Zwei-Phasen-Commit ist erforderlich, um die Sicherheit zu gewährleisten: Sobald genügend ehrliche Knoten einen Block gesperrt haben, kann kein konkurrierender Block eine Zustimmung erhalten, und der Commit in der nächsten Runde macht ihn dauerhaft. Daher muss ein Client normalerweise auf den nächsten Block oder die nächste Runde warten, um zu erfahren, dass die vorherige Transaktion endgültig ist.

MonadBFT ermöglicht im Grunde genommen, dass eine Transaktion nach nur einer Runde Abstimmung als endgültig genug betrachtet wird (sicher genug, um darauf zu reagieren). Dies wird als spekulative Endgültigkeit bezeichnet.

Wenn ein Anführer einen Block vorschlägt und die Validatoren abstimmen, um eine QC für diesen Block zu bilden, befindet sich dieser Block nun in einem Abstimmungsstatus (er ist von einem Quorum gesperrt). In MonadBFT werden die Validatoren die Transaktionen des Blocks ausführen, sobald sie die QC gebildet haben, und sogar eine vorläufige Bestätigung an die Kunden senden, die anzeigt, dass der Block (spekulativ) akzeptiert wurde. Dies entspricht der Aussage: "Wir haben eine überwältigende Mehrheit, die diesem Block zustimmt. Es sei denn, es passiert etwas sehr Unerwartetes, betrachten Sie diesen Block als bestätigt."

Diese sofortige Bestätigung ist optimistisch. Der Block wurde noch nicht im Hauptbuch verankert. Das wird geschehen, wenn der nächste Vorschlag kommt und ihn finalisiert (QC-on QC), aber unter normalen Bedingungen wird nichts ihn widerrufen. Das einzige Szenario, das einen spekulativ ausgeführten Block rückgängig machen kann, ist, wenn der Anführer sich widersprach (d.h. zwei verschiedene Blöcke desselben Höhenniveaus vorgeschlagen hat, um die Abstimmung zu spalten).

Sie können die spekulative Endgültigkeit als ein schönes Nebenprodukt des Widerstands gegen Schwanzgabeln betrachten. Der Widerstand gegen Schwanzgabeln garantiert, dass selbst wenn der nächste Anführer abstürzt, der aktuelle Vorschlag nicht aufgegeben wird (dank Reproposal- und NEC-Regeln). Somit wird ein spekulativ ausgeführter Block nur dann fallen gelassen, wenn der ursprüngliche Vorschlagende sich gleichzeitig widersprochen hat (doppeltes Signierungsfeld, das nachweislich bösartig ist), was: 1) durch konkurrierende QCs erkennbar ist, 2) bestrafbar ist und 3) äußerst selten vorkommt.

In früheren Protokollen wurde nicht garantiert, dass der nächste Anführer den vorherigen Block erneut vorschlagen würde, sodass Schwanzgabeln möglich waren und Spekulationsannahmen gebrochen wurden.

Optimistische Reaktionsfähigkeit

In den meisten Konsensprotokollen gibt es nach jeder Runde eine eingebaute Wartezeit wie eine Pufferzeit oder Timeout. Dies soll sicherstellen, dass alle Nachrichten eingetroffen sind, bevor es weitergeht. Es handelt sich um einen Schutzmechanismus, der für den Umgang mit dem schlimmsten Fall gedacht ist, z. B. wenn ein Leader abstürzt oder überhaupt nichts sendet.

Diese Timeouts sind oft übermäßig konservativ. Wenn das Netzwerk normal funktioniert und alle Validatoren sich korrekt verhalten, wird die feste Wartezeit zu einem unnötigen Overhead. Blöcke hätten schneller finalisiert werden können, aber das Protokoll hielt sich nur zur Sicherheit zurück.

MonadBFT führt eine optimistische Reaktionsfähigkeit ein, was bedeutet, dass das Protokoll sofort auf Netzwerknachrichten reagieren kann, anstatt sich immer auf feste Timer zu verlassen. Das Designprinzip hier kann als „schnell, wenn möglich, geduldig, wenn nötig“ zusammengefasst werden.

MonadBFT ist so konzipiert, dass es sowohl im Normalfall als auch bei der Fehlerwiederherstellung nicht pausiert, wenn es nicht muss.

• Im glücklichen Fall (bedeutet, dass wir einen ehrlichen Anführer haben): Es gibt keine eingebaute Verzögerung beim Vorschlagen oder Abstimmen. Sobald ein Anführer an der Reihe ist, schlägt er einen Block vor. Sobald die Validatoren einen gültigen Vorschlag erhalten, stimmen sie ab. In dem Moment, in dem der Anführer (oder vielmehr der nächste Anführer, da die Stimmen an den nächsten Vorschlagenden in pipelined HotStuff gehen) 2f+1 Stimmen sammelt, wird QC gebildet und kann verbreitet werden. In einem optimistisch reaktionsfreudigen Design löst dies sofort die nächste Phase aus.

In der Praxis bedeutet dies, dass wenn die Netzwerklatenz zwischen den Knoten beispielsweise 100 ms beträgt, der Konsens theoretisch in nur ein paar hundert Millisekunden (plus Rechen- und Aggregationsüberkopf) eine Runde abschließen kann.

Es wartet beispielsweise nicht eine volle Sekunde auf die „Slot-Zeit“, wenn es nicht muss. Dies steht im Gegensatz zum Ethereum-Hauptnetz, das einem anderen Ansatz folgt.Slot-und-Epoche-ModellAuf Ethereum erfolgt die Blockproduktion in festen 12-Sekunden-Intervallen. Selbst wenn alle früher bereit sind, wartet das Protokoll.

Die Herangehensweise von MonadBFT beseitigt unnötige Verzögerungen. Sie behält die gepipelte HotStuff-Struktur bei, entfernt jedoch die starre Regel "Sie müssen Δ Sekunden warten" im Normalfall. Dies bedeutet, dass sie in der Reaktionsfähigkeit zeitgebundene Systeme übertreffen kann, ohne die Sicherheit zu opfern.

• Im unglücklichen Pfad (Führerausfall): In vielen Konsensprotokollen erkennen andere Knoten erst nach Ablauf eines Timeouts Δ, dass ein Führer keinen Block vorschlägt. Wenn Δ beispielsweise 1 Sekunde beträgt, geht diese Zeit im Wesentlichen verloren. MonadBFT geht damit anders um. Wenn Validatoren einen fehlenden Vorschlag feststellen, senden sie sofort Timeout-Nachrichten (TC oder Timeout-Zertifikat). Sobald 2f+1 dieser Timeouts gesehen werden, übernimmt der nächste Führer. Der Übergang zur neuen Ansicht wird durch quorum-basierte Beweise und nicht durch die Uhr ausgelöst.

Vergleich mit dem HotStuff-Familienkonsens

MonadBFT baut auf der Linie der HotStuff-Familie Konsensprotokolle auf, sticht jedoch durch die Erreichung einer Kombination von wünschenswerten Eigenschaften hervor, die kein früheres Design in der Lage war, vollständig zu integrieren, ohne Kompromisse eingehen zu müssen. Frühere Protokolle waren oft für einige Dimensionen wie die pipelined Durchsatz oder die lineare Kommunikation optimiert, mussten jedoch andere opfern. MonadBFT schafft es einzigartigerweise, lineare Nachrichtenkomplexität, pipelined commits, starke Tail-Forking-Resistenz, sofortige Reaktionsfähigkeit ohne feste Verzögerungen und effiziente Wiederherstellungsmechanismen zu kombinieren, während gleichzeitig schnelle Finalität und hohe Liveness-Garantien erhalten bleiben. Die Tabelle unten fasst zusammen, wie sich MonadBFT in diesen kritischen Dimensionen im Vergleich zu anderen rotierenden-Leader BFT-Protokollen verhält:

Was bedeutet das für Entwickler und Benutzer?

Für Entwickler bedeutet MonadBFT ein paar Dinge:

• Einfacher Finalitätsmodell: Mit MonadBFT können Sie einen Block, der eine QC (Supermehrheitsvotum) hat, für die meisten Zwecke als effektiv finalisiert behandeln, da das Protokoll ihn finalisieren oder kürzen wird, wenn nicht. Entwickler können sicher auf Bestätigungen mit einer Blockhöhe von 1 handeln, mit hoher Zuversicht.
• Verbesserte UX für Apps: Wenn Sie eine High-Throughput-Anwendung (Börse, Spiel usw.) entwickeln, ermöglichen die geringe Latenz und die Fork-Resistenz von MonadBFT eine reibungslosere UX. Benutzer sehen fast sofort, wie ihre Aktionen bestätigt werden, und stoßen nicht häufig auf verwirrende Reorgs oder Rollbacks. Dadurch können Sie Anwendungen entwerfen, die von Endgültigkeit und schnellen Updates ausgehen.
• Deterministisches Verhalten: Die strengeren Regeln von MonadBFT (wie z.B. die Anforderung zur erneuten Vorschlagsstellung) reduzieren die Nichtdeterminismus bei der Blockeinbeziehung. Es gibt weniger "Grenzfall"-Szenarien, in denen ein Block je nach subtiler Zeitgebung entweder eingeschlossen oder übersprungen werden könnte, wie z.B. ob eine Abstimmung oder ein Timeout zuerst den Führer erreicht hat. MonadBFT ersetzt solche zeitkritische Unklarheiten durch explizite Regeln und überprüfbare Beweise. Dies erleichtert das Nachvollziehen der Korrektheit des Protokolls und dessen Testen. Es bietet auch klare Anhaltspunkte zur Identifizierung fehlerhafter Knoten (z.B. wenn jemand versäumt, erneut vorzuschlagen oder einen widersprüchlichen Block vorschlägt, weiß man, dass sie das Protokoll verletzt haben).
• Skalierbarer Spielraum: Wenn Sie als Entwickler Bedenken hinsichtlich Skalierung haben, bietet Ihnen MonadBFT mehr Spielraum, bevor Engpässe auftreten. Sie können die Blockgrößen oder die Anzahl der Validatoren komfortabler erhöhen als bei einem quadratischen Protokoll. Und Funktionen wie die blockweise Verbreitung mit Fehlerkorrektur bedeuten, dass Sie eine Menge Daten durch das Netzwerk leiten können, ohne die einzelnen Knoten zu überlasten. Dies ermöglicht es, auf eine höhere Durchsatzleistung abzuzielen, was den Gestaltungsspielraum für ehrgeizigere On-Chain-Anwendungen eröffnet.

Für Endbenutzer: Ein normaler Benutzer wird nichts von all den Dingen wissen, über die wir hier diskutiert haben, aber sie spüren deren Auswirkungen. Mit MonadBFT als Grundlage für Monad die Kette können Benutzer alle unten aufgeführten guten Eigenschaften erwarten, ohne dabei auf Dezentralisierung und Zensurresistenz zu verzichten.

• Schnellere Bestätigungen: Transaktionen (wie das Senden von Token, Tauschen von Vermögenswerten, Prägen von NFTs, Ausführen von Trades) werden sehr schnell bestätigt.
• Weniger Überraschungen: Die Konsistenz des Kettenzustands ist höher, da Dinge wie Schwanzgabeln, die im Wesentlichen eine Umstrukturierung sind, beseitigt werden.
• Fairness und Transparenz: Verbesserungen im Konsens bedeuten indirekt, dass der Betrieb der Kette fairer ist. Kein einzelner Validator kann Transaktionen einfach zensieren oder Spiele mit der Reihenfolge über Blöcke hinweg spielen.

Fazit

Zusammenfassend führt MonadBFT vier Kerninnovationen auf Basis des gepipelten HotStuff-Style-Konsenses ein:

Tail-Forking Resistance: MonadBFT ist das erste gepipelte BFT-Protokoll, das Tail-Forking-Angriffe beseitigt. Dies wird erreicht, indem der nächste Anführer aufgefordert wird, den zuletzt abgestimmten Block erneut vorzuschlagen, wenn der vorherige Anführer gescheitert ist, oder anderweitig ein No-Endorsement Certificate (NEC) vorlegt, um zu beweisen, dass der Block keine Unterstützung hatte. Dies garantiert, dass kein von einer Supermehrheit unterstützter Block aufgegeben wird, schützt die Belohnungen ehrlicher Anführer und verhindert bösartige Reorgs und die Extraktion von MEV über Blockgrenzen hinweg.

Spekulative Endgültigkeit in einer Runde: Validatoren können einen Block nach einer einzigen Kommunikationsrunde bestätigen (einen Vorschlag des Leiters und Abstimmungen), was den Kunden eine sofortige Zusicherung der Aufnahme gibt. Diese spekulative Bestätigung wird nur rückgängig gemacht, wenn der Leiter sich widerspricht (eine Handlung, die nachgewiesen und bestraft werden kann), was es in der Praxis zu einer sicheren Annahme macht.

Optimistische Reaktionsfähigkeit: Das Protokoll arbeitet mit Netzwerkgeschwindigkeit ohne inhärente Verzögerungen. Führungskräfte treiben den Konsens voran, sobald die erforderlichen Stimmen eingegangen sind, und Änderungen werden vorgenommen, sobald eine Quorum von Timeouts beobachtet wird, anstatt auf ein festes Timeout-Intervall zu warten. Dieses optimistisch reaktionsfähige Design minimiert die Wartezeiten und maximiert die Durchsatzleistung, während es gleichzeitig asynchron und robust mit Fehlern umgeht, wenn sie auftreten.

Lineare Kommunikation: Auf dem glücklichen Pfad (was bedeutet, dass der Anführer ehrlich ist), ist die Nachrichten- und Authentifizierungskomplexität linear in der Anzahl der Validatoren. MonadBFT behält das effiziente Kommunikationsmuster von HotStuff bei, indem aggregierte Signaturen und einfache Übertragungen vom Anführer an die Validatoren verwendet werden, was es dem Protokoll ermöglicht, auf Hunderte von Validatoren zu skalieren, ohne Leistungsengpässe zu verursachen.

Haftungsausschluss：

1. Dieser Artikel wurde von [michael_lwy] wieder veröffentlicht. Alle Urheberrechte gehören dem Originalautor [michael_lwy]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an dieGate LearnTeam und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel verboten.