Wie skaliert Monad die EVM, während die Dezentralisierung erhalten bleibt? MonadBFT ist der Konsensalgorithmus, der in Monad verwendet wird. Es ist die erste tailfork-resistente Implementierung von Hotstuff (was bedeutet das?). So kann MonadBFT auf Tausende von Validatoren skalieren und dabei leistungsfähig bleiben 🧵
1/7 Konsensmechanismen Der Mechanismus, den Blockchains verwenden, um sicherzustellen, dass neue Blöcke von der Mehrheit der Validatoren akzeptiert werden. Bisher sind Konsensalgorithmen nicht in der Lage, über ein paar hundert Validatoren hinaus zu skalieren, da die Komplexität in den meisten Fällen mit dem Quadrat der Anzahl der Validatoren zunimmt. Da jeder Validator mit allen anderen Validatoren kommuniziert, um sich über die Blöcke zu einigen: n Validatoren x n Nachrichten = n-Quadrat Nachrichten. Daher steigt die Komplexität erheblich mit der Anzahl der Validatoren.
2/7 Hotstuff ist ein Konsensalgorithmus, der linear skalieren kann (direkt proportional zur Anzahl der Validatoren), indem er die All-zu-All-Kommunikation vermeidet und es einem einzelnen "Leader" ermöglicht, mit allen Validatoren für den Konsens zu kommunizieren. Daher kann Hotstuff effizienter skalieren als der traditionelle PBFT-Konsens, ist jedoch anfällig für Tailforking-Angriffe. MonadBFT ist die erste tailfork-resistente Implementierung von Hotstuff.
3/7 Was ist Tailforking? Tailforking tritt auf, wenn der nächste Führer (Validator, der den nächsten Block vorschlägt) absichtlich oder versehentlich versäumt, das QC des gültigen Blocks des vorherigen Führers in seinen Vorschlag für den neuen Block aufzunehmen. (QC steht für Quorum-Zertifikat, das ein Beweis dafür ist, dass alle Validatoren dem vorherigen Block zugestimmt haben) Infolgedessen bleibt der vorherige Block, obwohl er gültig ist und die Mehrheit unterstützt, unbestätigt und wird schließlich verwaist oder durch einen anderen Block auf derselben Höhe ersetzt. Dies stört den Anreizmechanismus: ehrliche Vorschlagenden erhalten möglicherweise keine Blockbelohnungen oder Gebühren, wenn ihr Block übersprungen wird, was unfaire Verhaltensweisen fördert und die Sicherheit des Netzwerks schwächt.
4/7 Wie funktioniert MonadBFT? → Ein Führer (Alice) sendet einen signierten Blockvorschlag an alle anderen Knoten (Fan-Out), die seine Gültigkeit bestätigen, indem sie eine signierte Bestätigung an den nächsten Führer Bob senden (Fan-In). → Bob aggregiert die Bestätigungen zu einem „Quorum-Zertifikat“ (QC). → Bob sendet das QC an alle Knoten, die bestätigen, dass sie es erhalten haben, indem sie eine Nachricht an den 3. Führer (Charlie) senden, der diese Bestätigungen aggregiert. Da die Bestätigungen ein QC betreffen, nennen wir dieses neue QC ein QC-on-QC. → Charlie sendet das QC-on-QC an alle. Nach Erhalt des QC-on-QC weiß jeder, dass Alices Block finalisiert wurde.
5/7 Pipelining In der obigen Geschichte senden Bob und Charlie nur QCs oder QCs-on-QCs, aber in Wirklichkeit sind die Vorschläge gepuffert: Bobs Nachricht enthält sowohl das QC für Alices Block als auch die Inhalte eines neuen Blocks. Charlies Nachricht enthält das QC für Bobs Block (das ein QC-on-QC für Alices Block ist) und enthält auch die Transaktionen für einen neuen Block. Wenn Validatoren eine Bestätigung für Bobs Nachricht senden, bestätigen sie sowohl die Gültigkeit von Bobs Block als auch die Gültigkeit des QCs. Dieses Pipelining erhöht den Durchsatz des Netzwerks, da in jedem Slot ein neuer Block produziert wird.
6/7 Raptorcast: Monads Block-Propagation-Protokoll MonadBFT erfordert, dass der Leader Blockvorschläge an jeden Validator sendet. Die Blöcke können jedoch ziemlich groß sein: 10.000 Transaktionen/s * 200 Bytes/Tx = 2 MB/s. Direkt an 200 Validatoren zu senden, würde 400 MB/s erfordern. Idealerweise sollten Validatoren nicht über eine so hohe Upload-Bandbreite verfügen. Hier kommt Raptorcast ins Spiel. → Blöcke werden vom Leader fehlerkorrekturcodiert (Fehlerkorrekturcodierung bedeutet, dass die Nachricht in eine Menge von Chunks zerlegt wird, und sie kann aus einer ausreichend großen Teilmenge dieser Chunks dekodiert werden) → Der Leader verteilt eine andere Menge von Chunks an alle Validatoren im Netzwerk (Validatoren mit höherem Einsatz erhalten anteilig mehr) → Jeder Validator sendet seine Chunks an alle anderen Validatoren im Netzwerk erneut Auf diese Weise wird die gesamte Bandbreite des Netzwerks genutzt, um Blockvorschläge zu propagieren.
30,61K