Der Kern der Blockchain besteht darin, einen strengen globalen Konsens zu erreichen: Das bedeutet, dass unabhängig davon, wo die Netzwerkknoten in welchem Land oder in welcher Zeitzone verteilt sind, alle Teilnehmer letztendlich einen Konsens über eine Reihe von objektiven Ergebnissen erzielen müssen.

Aber die Realität verteilter Netzwerke ist nicht ideal: Knoten gehen offline, Knoten lügen und einige sabotieren sogar absichtlich. In diesem Fall, wie kann das System "mit einer Stimme sprechen" und Konsistenz aufrechterhalten?

Dies ist das Problem, das das Konsensprotokoll lösen soll. Es handelt sich im Wesentlichen um einen Satz von Regeln, um eine Gruppe unabhhängiger und teilweise nicht vertrauenswürdiger Knoten anzuleiten, wie sie eine einheitliche Entscheidung über die Reihenfolge und den Inhalt jeder Transaktion treffen können.

Sobald dieser 'strengen Konsens' hergestellt ist, kann die Blockchain viele wichtige Funktionen freischalten, wie den Schutz digitaler Eigentumsrechte, Anti-Inflations-Währungsmodelle und skalierbare soziale Kollaborationsstrukturen. Die Voraussetzung ist jedoch, dass das Konsensprotokoll selbst gleichzeitig zwei grundlegende Aspekte sicherstellen muss:

• Zwei konkurrierende Blöcke können nicht beide bestätigt werden;
• Das Netzwerk muss weiter voranschreiten und darf nicht stecken bleiben oder stoppen.

MonadBFT ist der neueste technologische Durchbruch in dieser Richtung.

Eine kurze Überprüfung der Evolution der Konsensprotokolle

Im Bereich des Konsensmechanismus wurde tatsächlich seit Jahrzehnten geforscht. Die frühesten Protokolle wie PBFT (Practical Byzantine Fault Tolerance) können bereits sehr realistische Situationen bewältigen: Selbst wenn einige Knoten im Netzwerk die Kette abwerfen, sich bösartig verhalten oder Unsinn reden, solange sie nicht mehr als ein Drittel der Gesamtzahl ausmachen, kann das System dennoch einen Konsens erreichen.

Das Design dieser frühen Protokolle ist eher „traditionell“: In jeder Runde wird ein Anführer ausgewählt, um einen Vorschlag zu initiieren, und andere Validatoren stimmen in mehreren Runden über diesen Vorschlag ab, um die Transaktionsreihenfolge allmählich zu bestätigen.

Der gesamte Abstimmungsprozess durchläuft in der Regel mehrere Phasen, wie z.B. Vorbereitung, Vorbereitung, Bestätigung und Antwort. In jeder Phase müssen sich alle Validatoren miteinander verständigen. Anders ausgedrückt, jeder muss jedem anderen sagen, und das Nachrichtenvolumen wächst explosionsartig in einem 'Mesh'-Muster.

Die Komplexität dieser Kommunikationsstruktur beträgt n² - das bedeutet, wenn es 100 Validatoren im Netzwerk gibt, kann jede Runde des Konsenses fast 10.000 Nachrichten übertragen.

In einem kleinen Netzwerk ist dies kein Problem, aber sobald die Anzahl der Validatoren zunimmt, wird die Kommunikationslast des Systems schnell unerträglich, was sich direkt auf die Effizienz auswirkt.

Quelle der Informationen:https://medium.com/coinmonks/pbft-verst%C3%A4ndnis-des-algorithmus-b7a7869650ae

Die sekundäre Kommunikationsstruktur „Jeder spricht mit jedem“ ist tatsächlich sehr ineffizient. Zum Beispiel muss in einem Netzwerk mit 100 Validatoren jede Runde des Konsenses Zehntausende von Nachrichten verarbeiten.

Dies kann immer noch in einem kleinen Kreis verwaltet werden, aber wenn es in einem globalen, offenen Kettennetzwerk platziert wird, wird die Kommunikationslast sofort unakzeptabel. Frühe BFT-Protokolle wie PBFT und Tendermint werden daher in der Regel nur in berechtigten Netzwerken oder Systemen mit sehr wenigen Validatoren verwendet, um kaum zu funktionieren.

Um es dem BFT-Protokoll zu ermöglichen, sich an genehmigungslose, öffentliche Kettenumgebungen anzupassen, bewegen sich einige Designs der nächsten Generation in Richtung leichterer Kommunikationsmethoden: Jeder Validator kann nur mit dem Anführer kommunizieren, anstatt mit allen Mitgliedern.

Dies optimiert die Nachrichtenkomplexität vom ursprünglichen n² auf n und reduziert dadurch erheblich die Systemlast.

Das HotStuff-Protokoll wurde 2018 vorgeschlagen, um dieses Skalierbarkeitsproblem zu lösen. Seine Designphilosophie ist sehr klar: den komplexen Abstimmungsprozess des PBFT durch eine prägnantere, vom Leader gesteuerte Kommunikationsstruktur zu ersetzen.

Eine der Schlüsselfunktionen von HotStuff ist die sogenannte lineare Kommunikation. In seinem Mechanismus muss jeder Validator nur seine Stimme an den aktuellen Anführer senden, der diese dann verpackt, um ein Quorum-Zertifikat (QC) zu generieren.

Dieser QC ist im Wesentlichen eine kollektive Signatur, die dem gesamten Netzwerk beweist: 'Die meisten Knoten stimmen diesem Vorschlag zu.'

Im Gegensatz dazu ist der Kommunikationsmodus von PBFT 'An alle senden', bei dem jeder in der Gruppe spricht, was manchmal zu chaotischen Szenen führt. Der Modus von HotStuff ähnelt mehr dem von 'einer sammelt, einer verpackt zu einer Zeit', was einen effizienten Betrieb unabhängig davon ermöglichen kann, wie viele Personen im Netzwerk sind.

Die Abbildung vergleicht die Fan-Out-Kommunikationsstruktur von HotStuff mit dem vollständig verbundenen Modus von PBFT. Quelle:

https://www.mdpi.com/1424-8220/24/16/5417

Neben der linearen Kommunikation kann HotStuff in eine gepipelte Version weiterentwickelt werden, um die Effizienz zu verbessern.

Im ursprünglichen HotStuff wird derselbe Validator mehrere Runden hintereinander als Anführer dienen, bis ein Block vollständig bestätigt ist. Dieser Prozess besteht darin, 'einen Block pro Runde zu verarbeiten', wobei alle Bemühungen darauf gerichtet sind, den aktuellen voranzubringen.

Im HotStuff-Pipeline ist der Mechanismus noch flexibler: In jeder Runde wird ein neuer Anführer ausgewählt und jeder Anführer hat zwei Aufgaben:

• Packen Sie die letzte Runde der Stimmen in ein Quorum-Zertifikat (QC) auf einer Seite und senden Sie es an das gesamte Netzwerk;
• Auf der einen Seite einen neuen Block vorschlagen, bereit, die nächste Runde zu starten.

Mit anderen Worten, es gilt nicht mehr „eins bestätigen, bevor das nächste verarbeitet wird“, sondern wie an einem Fließband, übernehmen verschiedene Führungskräfte abwechselnd die Verantwortung für jeden Schritt. Der vorherige schlägt einen Block vor, der nächste bestätigt ihn und setzt fort, neue Blöcke vorzuschlagen, und der Konsens in der Kette wird wie bei einem Staffellauf weitergegeben.

Das ist der Ursprung der Metapher der „Fließbandfertigung“: Der aktuelle Block befindet sich noch im Bestätigungsprozess, während der nächste bereits in Vorbereitung ist, mehrere Schritte verlaufen parallel und erhöhen die Durchsatzeffizienz.

Zusammenfassend haben Protokolle wie HotStuff auf zwei Ebenen erhebliche Verbesserungen gegenüber dem traditionellen BFT erzielt:

• Zunächst ist die Kommunikation leichter, da jeder Validator nur mit dem Anführer kommunizieren muss;
• Zweitens ist die Verarbeitungseffizienz höher, und mehrere Blockbestätigungsprozesse können parallel ablaufen.

Das macht HotStuff zu einer Designvorlage für viele moderne PoS-Blockchain-Konsensmechanismen. Aber alles hat seine Vor- und Nachteile - während die Pipeline-Struktur in der Leistung leistungsstark ist, führt sie auch leise ein nicht leicht erkennbares strukturelles Risiko ein.

Als nächstes werden wir uns mit diesem Kernproblem befassen: Tail Forking.

Schwanzgabelungsproblem am Ende

Obwohl HotStuff, insbesondere seine gepipelte Version, das Skalierbarkeitsproblem des Konsensprotokolls löst, bringt es auch einige neue Herausforderungen mit sich. Die wichtigste und leicht übersehbare ist das sogenannte "Tail Forking"-Problem.

Was ist eine Schwanzgabel? Es kann einfach verstanden werden als: Eine Blockchain erfährt eine versehentliche Block-Reorganisation am 'Schwanz' der Kette.

Speziell gibt es einen Block, der gültig ist, erfolgreich an die Mehrheit der Validatoren weitergeleitet wurde und genügend Stimmen erhalten hat. In der Theorie sollte er sofort bestätigt und in die Hauptkette geschrieben werden. Am Ende wird er jedoch "übersprungen", verwaist und durch einen anderen neuen Block gleicher Höhe ersetzt.

Dies ist kein Fehler, kein Angriff, sondern aufgrund der Designstruktur des Protokolls selbst besteht die Möglichkeit dieses 'Chain Tailing'. Klingt das ein wenig unfair? Wie passiert das also?

Wie bereits erwähnt, hat jeder Führer des HotStuff-Pipelines zwei Aufgaben:

• A. Einen neuen Block vorschlagen (wie z. B. Bₙ₊₁)
• B. Stimmen für den Block des vorherigen Anführers sammeln, um QC zu generieren (z. B. um Bₙ endgültig zu bestätigen)

Diese beiden Aufgaben werden parallel ausgeführt und wechseln sich ab. Aber hier entsteht das Problem.

Zum Beispiel, nehmen wir an, dass Alice die Anführerin ist und sie den Block Bₙ in der Höhe n vorgeschlagen hat, der eine überwältigende Mehrheit an Stimmen erhalten hat und "fast bestätigt" ist.

Als nächstes sollte Bob an der Reihe sein, die Rolle des Anführers zu übernehmen, um zum nächsten Block Bₙ₊₁ der Kette vorzurücken und auch die QC (Qualified Commitment) von Bₙ in seinen Vorschlag aufzunehmen, um die endgültige Bestätigung von Bₙ abzuschließen.

Aber wenn Bob zu diesem Zeitpunkt offline ist oder absichtlich den QC von Bₙ nicht einreicht, dann gibt es ein Problem.

Da niemand Alice Block mit QC verpackt hat, verbreitete sich der Abstimmungsbericht von Bₙ nicht. Dieser Block, der bestätigt worden sein sollte, wurde daher 'kalt verarbeitet' und letztendlich vom gesamten Netzwerk ignoriert.

Das ist die Essenz einer Schwanzgabel: Ein Block des vorherigen Anführers wird aufgrund der Fahrlässigkeit oder Bosheit des nächsten Anführers übersprungen.

Warum ist die Schwanzgabel so stark?

Das Problem der Schwanzgabel konzentriert sich hauptsächlich auf zwei Aspekte: 1) der Anreizmechanismus wird gestört, 2) die Aktivität des Systems wird bedroht.

Zuerst werden Belohnungen geschluckt:

Wenn ein Block aufgegeben wird, erhält der Anführer, der ihn vorgeschlagen hat, keine Belohnungen, weder Blockbelohnungen noch Transaktionsgebühren. Wenn zum Beispiel Alice einen gültigen Block vorgeschlagen und überwältigende Unterstützung in der Abstimmung erhalten hat, aber aufgrund eines Fehlers oder einer bösartigen Operation von Bob der Block nicht bestätigt werden konnte, wird Alice am Ende keinen einzigen Cent erhalten. Dies führt zu einer fehlerhaften Anreizstruktur: Bösartige Knoten wie Bob können ihre Belohnungsquelle 'abschneiden', indem sie die Blöcke ihrer Gegner überspringen. Dieses Verhalten erfordert keine technischen Angriffe, sondern lediglich absichtliche 'Nichtkooperation', um die Gewinne der Konkurrenten zu schwächen. Wenn dies wiederholt geschieht, wird im Laufe der Zeit die Beteiligung und Fairness des gesamten Systems abnehmen und sogar eine Kollusion unter den Knoten auslösen.

Zweitens erweitert sich die MEV-Angriffsfläche:

Die Heckgabel stellt auch ein heimtückischeres, aber ernsthafteres Problem dar: Es gibt mehr Spielraum für die böswillige Manipulation des MEV (Maximum Extractable Value). Hier ist ein Beispiel: Nehmen wir an, Alice hat einen wertvollen Arbitrage-Trade in ihrem Block. Wenn Bob Ärger machen will, kann er sich mit der nächsten Anführerin, Carol, absprechen und Alices Blockade absichtlich nicht verteilen. Carol baut dann einen neuen Block auf der gleichen Höhe wieder auf und "stiehlt" Alices ursprüngliches Arbitrage-Geschäft - wodurch der MEV seinen eigenen gewinnt. Diese Praxis der "Neuordnung von Kettenköpfen + Absprache und Aneignung" ist nach den Regeln an der Oberfläche immer noch ein Block, aber es ist tatsächlich eine gut geplante Plünderung. Schlimmer noch, es führt zu "geheimen Absprachen" zwischen den Führern und verwandelt die Bestätigung von Blöcken in ein Spiel mit dem Vorteilsausgleich und nicht in einen öffentlichen Dienst.

Drittens, untergraben Sie die Endgültigkeitsgarantie, die die Benutzererfahrung beeinträchtigt:

Im Vergleich zu Nakamoto-ähnlichen Protokollen ist ein großer Vorteil von BFT die deterministische Endgültigkeit: Sobald ein Block bestätigt ist, kann er nicht zurückgerollt werden. Allerdings stört der 'Tail Fork' diese Garantie, insbesondere bei Blöcken, die 'vorläufig bestätigt, aber nicht formell bestätigt' sind. Einige hochleistungsfähige DApps möchten oft Daten sofort nach dem Block-Voting lesen, um die Latenz zu reduzieren, und wenn der Block plötzlich verworfen wird, kann dies zu einem Rollback des Benutzerzustands führen - wie ungewöhnliche Kontostände, hoch gehebelte Trades, die gerade abgeschlossen wurden, die aus unerklärlichen Gründen verschwinden, oder plötzliche Spielstatus-Resets.

Viertens kann eine Kettenreaktionsstörung verursachen:

Im Allgemeinen kann eine Schwanzgabelung nur die Bestätigung eines Blocks für eine Runde verzögern, was keine große Auswirkung hat. In einigen Randfällen kann das System jedoch stecken bleiben, wenn mehrere aufeinanderfolgende Führer beschließen, den vorherigen Block zu überspringen, und niemand bereit ist, den vorherigen Block zu "übernehmen". Die gesamte Kette bleibt stecken, bis ein Führer erscheint, der bereit ist, Verantwortung zu übernehmen, und das Netzwerk wird weiterhin voranschreiten.

Obwohl es zuvor einige Lösungen gegeben hat, wie z.B. der von BeeGees-Protokoll vorgeschlagene Mechanismus zur Vermeidung von Schwanzgabeln, erfordern sie oft Opfer von Leistung, wie die Wiedereinführung von sekundärer Kommunikationskomplexität, was den Verlust nicht wert ist.

Was ist MonadBFT?

MonadBFT ist ein neuartiges Konsensprotokoll der nächsten Generation, das speziell entwickelt wurde, um das Problem des Schwanzgabelns zu lösen. Seine Stärke liegt darin, dass es strukturelle Schwachstellen angeht, ohne die Leistungs-vorteile zu opfern, die durch die HotStuff-Pipeline gebracht werden. Mit anderen Worten, MonadBFT fängt nicht von vorne an, sondern optimiert weiterhin auf Basis des Kernrahmens von HotStuff. Es behält drei Schlüsselmerkmale bei:

1) Rotierender Leader: Wählen Sie für jede Runde einen neuen Leader aus, um die Kette voranzutreiben;
2) Pipelined commits: Mehrere Block-Bestätigungsprozesse können sich überschneiden;
3) Lineare Kommunikation (lineare Nachrichtenübermittlung): Jeder Validator muss nur mit dem Anführer kommunizieren, was viel Netzwerkoverhead spart.

Aber sich nur auf diese drei Punkte zu verlassen, ist nicht sicher genug. Um die strukturelle Schwachstelle des Schwanzgabels zu beheben, hat MonadBFT zwei wichtige Mechanismen hinzugefügt:

1) Obligatorischer Neuvorschlagsmechanismus (Neuvorschlag)
2) Keine Bescheinigung der Billigung (NEC)

Wiederholungsmechanismus

Im BFT-Protokoll wird die Zeit in Runden (sogenannte Ansichten) unterteilt, wobei in jeder Runde ein Leader dafür verantwortlich ist, einen neuen Block vorzuschlagen. Wenn der Leader versagt (zum Beispiel, indem er keinen Block rechtzeitig vorschlägt oder mit einem ungültigen Vorschlag), wechselt das System zur nächsten Runde und wählt einen neuen Leader aus.

MonadBFT hat einen Mechanismus hinzugefügt, um sicherzustellen, dass während des Ansichtswechselprozesses vorgeschlagene Blöcke nicht aufgrund der Führerrotation 'die Kette abwerfen'.

Wenn der aktuelle Leader versagt, werden die Validatoren eine signierte Nachricht für einen Rundenwechsel (Ansichtswechsel) senden, die darauf hinweist, dass die aktuelle Runde abgelaufen ist.

Insbesondere gibt diese Nachricht nicht nur 'Zeitüberschreitung' an, sondern muss auch die Blockinformationen der letzten Abstimmung des Validierers enthalten, was bedeutet, 'Ich habe keinen gültigen Vorschlag erhalten, dies ist der neueste Block, den ich derzeit sehe.'

Die neuen Führer werden diese Zeitüberschreitungsnachrichten von der Supermehrheit (2f+1) Validatoren sammeln und sie zu einem Timeout-Zertifikat (TC) zusammenführen. Dieses TC repräsentiert den vereinheitlichten kognitiven Schnappschuss des 'Chain Head Block' des gesamten Netzwerks, wenn die vorherige Runde scheitert. Der neue Führer wird den Block mit der höchsten Höhe (oder der neuesten Ansichtsnummer), bekannt als high_tip, daraus auswählen.

MonadBFT erfordert: Der Vorschlag eines neuen Leaders muss eine gültige TC enthalten und den höchsten ausstehenden Block im TC erneut vorschlagen, um diesem Block eine weitere Chance zu geben, bestätigt zu werden.

Warum? Wie bereits erwähnt: Wir möchten nicht, dass ein Block, der kurz vor der Bestätigung steht, verschwindet.

Beispielsweise, nehmen wir an, dass Alice der Anführer von Ansicht 5 ist, einen gültigen Block vorgeschlagen hat und die Mehrheit der Stimmen erhalten hat. Als nächstes, wenn der Anführer von Ansicht 6, Bob, offline ist und es versäumt, den Kettenprozess voranzutreiben, muss Carol, wenn sie die Führung von Ansicht 7 übernimmt, gemäß den Regeln von MonadBFT TC einschließen und den Block von Alice erneut vorschlagen. Auf diese Weise wird die ehrliche Arbeit von Alice nicht umsonst sein.

Wenn Carol den Block von Alice nicht hat, kann sie ihn von anderen Knoten anfordern. Knoten können:

• Geben Sie den Block oder
• Geben Sie eine signierte „Keine Unterstützung (NE)“-Nachricht zurück, die anzeigt, dass der Absender diesen Block nicht hat (dessen Mechanismus später erläutert wird). (Bis zu f byzantinische Knoten können wählen, die Anfrage zu ignorieren und nicht zu antworten.)

Sobald Carol Alice's Block erneut vorschlägt, erhält sie eine zusätzliche Vorschlagsmöglichkeit, um sicherzustellen, dass sie aufgrund des Scheiterns des vorherigen Anführers nicht 'impliziert' wird.

Die Rolle dieses erneuten Vorschlagsmechanismus ist klar: sicherzustellen, dass der Fortschritt der Kette fair ist und keine gültige Arbeit aufgrund von Pech oder Sabotage von jemandem stillschweigend verworfen wird.

Nicht übertragbares Zertifikat (NEC)

In Fortsetzung des vorherigen Beispiels: Nach Ablauf von Bobs Zug fordert Carol andere Validatoren auf, den high_tip-Block (d.h. Alices Block) bereitzustellen. Zu diesem Zeitpunkt werden mindestens 2f+1 Validatoren antworten:

• Entweder stellen Sie Alice's Blöcke bereit
• Senden Sie entweder eine signierte NE-Nachricht, die anzeigt, dass Sie Alices Block nicht erhalten haben.

Sobald Carol den Block von Alice empfängt, muss sie ihn gemäß den Regeln erneut vorschlagen. Carol kann den Block nur überspringen und einen neuen vorschlagen, wenn mindestens f+1 Validatoren die NE-Nachricht unterzeichnet haben.

Warum f+1? In einem BFT-System, das aus 3f+1 Validatoren besteht, können maximal nur f bösartig sein. Wenn der Block von Alice tatsächlich eine Supermehrheit der Stimmen erhalten hat, dann haben mindestens 2f+1 ehrliche Knoten ihn erhalten.

Daher muss Carol, wenn sie behauptet: „Ich kann Alice's Block nicht erhalten“, f+1 Validierungssignaturen vorlegen, um zu beweisen, dass keiner von ihnen ihn erhalten hat. Dies stellt ein Endorsement-Zertifikat (NEC) dar.

NEC ist das "Disclaimer"-Zeugnis eines Anführers: Es ist ein überprüfbarer Beweis dafür, dass der vorherige Block nicht bereit ist, bestätigt zu werden, nicht böswillig übersprungen, sondern mit Gründen "aufgegeben" wurde.

Neuvorschlag + Nicht bestätigtes Zertifikat = Beheben der Schwanzgabel

MonadBFT führt eine Reihe von strengen und klaren Regeln für die Verarbeitung von Chain-Heads ein, indem der Re-Proposal-Mechanismus und das No-Endorsement-Zertifikat (NEC) eingeführt werden.

Entweder endlich zum 'fast bestätigten' Block verpflichten;

Entweder liefern Sie ausreichende Beweise, um zu beweisen, dass der Block noch nicht bereit ist, bestätigt zu werden,

Andernfalls ist es nicht erlaubt, den vorherigen Block zu überspringen oder zu ersetzen.

Dieser Mechanismus stellt sicher, dass ein Block, der eine rechtliche Mehrheit der Stimmen erhalten hat, nicht aufgrund von Führungsfehlern oder absichtlicher Umgehung aufgegeben wird.

Die strukturellen Risiken der Schwanzgabel werden systematisch gelöst, und das Protokoll kann unangemessenes Überspringen klar einschränken.

Wenn ein Führer versucht, den vorherigen Block zu überspringen, ohne NEC-Beweise vorzulegen, wird das Protokoll das Verhalten sofort erkennen und ablehnen. Ein Sprungverhalten ohne kryptographische Beweise wird als illegal betrachtet und wird keine Unterstützung durch den Netzwerkkonsens erhalten.

Aus ökonomischer Anreizperspektive bietet dieses Design klaren Schutz für Validatoren:

• Solange der Block ehrlich vorgeschlagen wird und Unterstützung durch Abstimmung erhält, wird seine Belohnung aufgrund nachfolgender Fehler nicht entzogen.
• Auch in extremen Situationen, wie wenn ein Knoten absichtlich seine eigene Vorschlagsrunde überspringt und versucht, anderen zu helfen, MEV aus dem vorherigen Block zu ergreifen, wird das Protokoll den nachfolgenden Anführer zwingen, die erneute Vorschlag des ursprünglichen Blocks priorisieren, um zu verhindern, dass der Angreifer wirtschaftliche Vorteile erlangt, indem er den Prozess überspringt.

Noch wichtiger ist, dass MonadBFT die Protokollleistung nicht geopfert hat, um die Sicherheit zu verbessern.

Einige Designs, die sich in der Vergangenheit mit Schwanzgabeln beschäftigen (wie das BeeGees-Protokoll), verfügen über bestimmte Schutzfunktionen, verlassen sich aber oft auf hohe Kommunikationskomplexität (n²) oder ermöglichen schwere Kommunikationsprozesse in jeder Runde, was die Systemlast in der Praxis erheblich erhöht.

Die Designstrategie von MonadBFT ist ausgefeilter:

Zusätzliche Kommunikation (wie Timeout-Nachrichten, Block-Neuvorschläge) wird nur initiiert, wenn die Ansicht fehlschlägt oder Anomalien vorhanden sind. Auf dem regulären Pfad, wo die meisten ehrlichen Anführer kontinuierlich Blöcke produzieren, bleibt das Protokoll dennoch in einem leichten und effizienten Betriebszustand.

Das dynamische Gleichgewicht zwischen Leistung und Sicherheit ist genau einer der Kernvorteile von MonadBFT gegenüber seinen Vorgängerprotokollen.

Zusammenfassung

Dieser Artikel überprüft den grundlegenden Mechanismus des traditionellen PBFT-Konsenses, ordnet den Entwicklungsverlauf des HotStuff-Protokolls und konzentriert sich darauf, wie MonadBFT das inhärente Tail-Fork-Problem des HotStuff-Pipelines auf der Protokollebene löst.

Rückgabengabeln können die wirtschaftlichen Anreize der Block-Proposers verzerren und eine potenzielle Bedrohung für die Netzwerkaktivität darstellen. MonadBFT stellt sicher, dass jeder von ehrlichen Führern vorgeschlagene Block, der von einer gesetzlichen Mehrheitsabstimmung genehmigt wird, nicht durch Einführung eines Neu-Vorschlag-Mechanismus und Nicht-Endorsed-Zertifikat (NEC) aufgegeben oder übersprungen wird.

Im nächsten Artikel werden wir weiterhin die anderen beiden Kernfunktionen von MonadBFT erkunden:

1）Spekulative Endgültigkeit
2）Optimistische Reaktionsfähigkeit

Eine weitere Analyse dieser Mechanismen und ihrer praktischen Bedeutung für Validatoren und Entwickler.

Erklärung:

1. Dieser Artikel ist ein Nachdruck von [michael_lwy], das Copyright liegt beim ursprünglichen Autor [michael_lwy]，wenn Sie Einwände gegen den Nachdruck haben, wenden Sie sich bitte an Gate Learn Team)，das Team wird es so schnell wie möglich gemäß dem relevanten Prozess 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. Die anderen Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt, ohne zu erwähnenGate.ioKopieren Sie keine übersetzten Artikel, verteilen Sie sie nicht und plagiieren Sie sie nicht ohne Genehmigung.