Zusammenfassung des Durchbruchs in MonadBFT Gestern veröffentlichte Category Labs das MonadBFT-Papier, in dem der Konsensmechanismus beschrieben wird, der Monad im Mainnet antreiben wird. MonadBFT ist eine bedeutende Entwicklung in der Konsensforschung, da es das erste Mal ist, dass Pipelined HotStuff resistent gegen Tail-Forking wird. Tail-Forking tritt auf, wenn ein verpasster Slot dazu führt, dass der vorherige Vorschlag verworfen und erneut abgebaut wird. Es ist ein ernstes Problem in früheren Pipelined HotStuff-Formulierungen, da es MEV-Angriffe mit mehreren Blöcken ermöglicht, die den Konsens destabilisieren. Die Linderung dieses Problems ist eine große Sache, da sie uns alle Vorteile von Pipelined HotStuff bietet - häufige Blöcke, geringe Latenz, große Validator-Sets - und gleichzeitig den größten Nachteil vermeidet. MonadBFT bietet auch ein enormes Upgrade für die Endgültigkeit. Es verfügt über eine spekulative Finalität mit einem Slot (500 ms) und eine harte Finalität mit zwei Slots (1s). "Spekulative Finalität" bedeutet "Finalität, die nur im Falle einer Unklarheit (Doppelsignierung) durch eine Mehrheit der Validatoren rückgängig gemacht wird". Äquivokation ist in den meisten Blockchain-Systemen ein schwerwiegendes Vergehen und wird häufig mit Slashing bestraft. Je höher die Strafe für Zweideutigkeiten ist, desto näher kann man sich die "spekulative Finalität" an die Endgültigkeit denken. Die spekulative Finalität mit einem Slot ist eine enorme Freischaltung für Hochleistungsanwendungen, die den aktualisierten Zustand der Welt sofort nach Erhalt des nächsten Blocks anzeigen können. Diese Eigenschaften machen MonadBFT zu einem enormen Fortschritt im Konsens und zu einer würdigen Ergänzung zu anderen Verbesserungen in Monad, einschließlich asynchroner Ausführung, optimistischer paralleler Ausführung und MonadDb. Der Rest dieses Artikels dient als Zusammenfassung dessen, wie aufeinanderfolgende Verbesserungen in HotStuff aufeinander aufgebaut haben, um das Problem zu erklären, das MonadBFT löst. Zusammenfassend: 1. HotStuff bietet uns eine lineare Kommunikationskomplexität, so dass wir große Validator-Sets haben können, aber es ist nicht sehr effizient 2. Pipelined HotStuff bietet uns Effizienz und geringe Latenz, indem wir Blöcke für jeden Slot vorschlagen, leiden aber unter dem Problem der Heckgabeln 3. MonadBFT gibt uns Widerstand gegen die Heckgabel und spekulative Endgültigkeit von einem Slot --- HotStuff: Lineare Kommunikationskomplexität ermöglicht große Knotenzahlen HotStuff-Algorithmen durchlaufen im Laufe mehrerer Kommunikationsrunden, die in der Regel in Form einer "Fan out, fan in"-Kommunikation direkt von Führungskräften zu Validatoren zurück zu Führungskräften erfolgen. Jede Runde beginnt damit, dass der Anführer eine Nachricht direkt an andere Validatoren sendet, die jeweils eine signierte Nachricht zurücksenden, die bestätigt, dass sie die Nachricht erhalten haben. Unter der Voraussetzung, dass eine Supermehrheit (2/3) der Validatoren eine Bescheinigung zurücksendet, endet jede Runde damit, dass der Leiter die unterzeichneten Bescheinigungen in einem Quorum-Zertifikat (QC) zusammenfasst, das als Nachweis dafür dient, dass die Supermehrheit die vorherige Nachricht bestätigt hat. HotStuff-Algorithmen haben mehrere Kommunikationsrunden wie diese. - Die erste Nachricht des Anführers ist ein Blockvorschlag - Die zweite Nachricht ist die QC für diesen Blockvorschlag - Die dritte Nachricht ist eine QC über die vorherige QC (d.h. eine QC-on-QC) -Und so weiter Wenn der Vorgang zu irgendeinem Zeitpunkt vor der Endgültigkeit unterbrochen wird, kann der Block nicht abgeschlossen werden und wird verworfen. Transaktionen aus diesem Block müssen im nächsten Block wieder aufgenommen werden. Das ursprüngliche HotStuff-Protokoll hat kein Pipelining und hat 3 Kommunikationsrunden, bevor es endgültig wird; In jeder Runde spielt derselbe Validator die Rolle des Anführers. --- Pipelined HotStuff: Ein neuer Block pro Slot steigert die Effizienz Pipelining ist das, was wir alle intuitiv tun, wenn wir zwei Ladungen Wäsche zu erledigen haben. Anstatt darauf zu warten, dass Ladung 1 den gesamten Zyklus beendet hat, bevor wir mit Ladung 2 beginnen, geben wir beim Pipelining Ladung 1 gleichzeitig mit Ladung 2 in den Trockner. Sie können sich das ursprüngliche HotStuff als diesen naiven Ansatz zum Wäschewaschen vorstellen (beginnen Sie nicht mit Ladung 2, bis Ladung 1 vollständig fertig ist), während Pipelined HotStuff das intuitive Verhalten ausführt, mehrere Wäscheladungen gestaffelt durchzuführen. In Pipelined HotStuff staffeln wir die Vorschläge, so dass in jeder Runde ein neuer Block vorgeschlagen wird, wobei der neue Block huckepack auf die Nachricht aufgesetzt wird, die die QC aus dem vorherigen Block enthält. Blockvorschläge marschieren im Laufe mehrerer Runden auf die Endgültigkeit zu. Die Vorteile des Pipelinings sind erheblich. Pipelining erhöht die Dichte von Blockvorschlägen, da in jedem Slot ein Blockvorschlag gemacht wird, was den Durchsatz erhöht und die Zeit bis zur Finalität verkürzt. Es gibt jedoch einen großen Nachteil des Pipelinings, der am besten an einem Beispiel veranschaulicht wird. Angenommen, die Führungslinien für die Blöcke N, N+1 und N+2 sind Alice, Bob und Charlie. Wenn Bob seinen Platz verpasst, wird Alices Vorschlag ebenfalls ungültig, da Bobs Nachricht sowohl seinen Vorschlag als auch eine QC für Alices Vorschlag enthält. Als dies geschieht, wird Charlie aufgefordert, einen Block zu produzieren, als ob Alices Vorschlag nie existiert hätte. Wir bezeichnen dieses Verhalten als "Tail-Forking" und können es sich als eine Mini-Reorganisation der Tiefe 1 vorstellen. Die Möglichkeit des Tail-Forking hat erhebliche Folgen, denn verpasste Slots sind nicht unbedingt zufällig. Wenn es eine Möglichkeit gibt, Wert zu extrahieren, indem man Alices Block erneut abbaut, während einige der Transaktionen neu angeordnet oder weggelassen werden, dann können Bob und Charlie sich absprechen, um Bob absichtlich seinen Platz verpassen zu lassen, was Charlie die Möglichkeit gibt, Alices Block erneut zu minen. Dies war ein erheblicher Nachteil von Pipelined HotStuff-Protokollen (von denen einige heute im Mainnet sind). --- MonadBFT ändert das MonadBFT ist das erste Protokoll, das Pipelining ermöglicht und gleichzeitig den Algorithmus gegen Tail-Forks resistent macht. Dieser Tail-Fork-Widerstand kommt von der Fallback-Prozedur, wenn Bob seinen Slot verpasst, was es den Validatoren ermöglicht, ihr kollektives Wissen über Alices Vorschlag und den Grad des Konsenses innerhalb des Validator-Sets zusammenzustellen. Insbesondere bei MonadBFT gilt: Wenn Bob seinen Slot verpasst, müssen die Validatoren im Rahmen des Fallback-Verfahrens mit unterschriebenen Bescheinigungen kommunizieren, die angeben, ob sie Alices Block gesehen haben. Wenn die Mehrheit Alices Block bestätigt, dann ist Charlie gezwungen, Alices Block erneut vorzuschlagen. Wenn Charlie einen anderen Block vorschlagen möchte, muss er eine unterschriebene Bescheinigung von der Mehrheit der Validatoren vorlegen, die bestätigt, dass er Alices Block nicht rechtzeitig gesehen hat. In dem typischen Fall, in dem Charlie Alices Block erneut vorschlägt, darf er seinen Block in der folgenden Runde vorschlagen. Das Ergebnis sind zwei wichtige Eigenschaften: der Tail-Forking-Widerstand und die spekulative Finalität eines einzelnen Slots. Wir haben bereits über den Widerstand gegen die Schwanzgabelung gesprochen, aber lassen Sie uns die Auswirkungen auf die Endgültigkeit verstehen. Nehmen Sie wie zuvor an, dass die Führungslinien für die Blöcke N, N+1 und N+2 Alice, Bob und Charlie sind. Unter Pipelined 2-Phase HotStuff - d.h. vor MonadBFT - als Validator (oder Full Node) können Sie Alices Blockvorschlag erst finalisieren, wenn Sie Charlies Blockvorschlag sehen. Warum? Denn wenn du abschließt, sobald du Bobs Vorschlag siehst, ist es möglich, dass Bob dich, indem er seinen Vorschlag NUR an dich weiterleitet, und er tatsächlich vorhat, seinen Vorschlag nicht an alle anderen zu senden und so seinen Platz zu verpassen. Aber in MonadBFT können Sie, sobald Sie Bobs Vorschlag sehen, "spekulativ" Alices Vorschlag abschließen, da Bobs Vorschlag eine QC zu Alices Vorschlag enthält, was ein Beweis dafür ist, dass 2/3 des Netzwerks Alices Vorschlag bestätigt haben. Selbst wenn Bob sich mit Ihnen anlegt, indem er seinen Vorschlag NUR an Sie weiterleitet, und am Ende seinen Platz verpassen wird, wissen Sie, dass eine große Mehrheit des Senders Alices Vorschlag gesehen hat und wenn sie am Fallback-Verfahren teilnehmen, Alices Vorschlag erneut absegnen wird. Die einzige Möglichkeit, dass Alices Block nicht abgeschlossen wird, besteht darin, dass die Validatoren zweideutig sind und unterschreiben, dass sie Alices Nachricht nicht gesehen haben. Dieser Fehler ist leicht beweisbar - wir haben widersprüchliche Nachrichten von ihnen signiert. Wenn die Strafe für die Zweideutigkeit erheblich ist - und das sollte sie sein -, dann ist diese "spekulative" Finalität eigentlich nicht wirklich so spekulativ. --- Fazit MonadBFT ist eine äußerst aufregende Entwicklung für den Konsens und eine würdige Ergänzung zu anderen Compounding-Verbesserungen in Monad, einschließlich asynchroner Ausführung, optimistischer paralleler Ausführung und MonadDb. Herzlichen Glückwunsch an @MohammadMJalal1 und @KushalBabel zu diesem bedeutenden Durchbruch. MonadBFT wird in Kürze im Monad Testnet implementiert, das derzeit Pipelined 2-Phase HotStuff implementiert. Weitere Informationen finden Sie im verlinkten Blogbeitrag und Paper im nächsten Tweet.