BNB-Hardfork-Countdown: Der Underlayer-Veteran zerlegt die angebliche Abspaltung der „dusk“- und $BNB -Konsens-Strategie – ein perfider Plan!
​Letzte Nacht habe ich in einer Wohnung in Tokio bis spät in die Nacht den BNB-Chain-8/Monat-Pasteur-Upgrade-Quellcode nachgearbeitet. Die Zusammenführung des BEP-675-Vorschlags hat mir, nachdem ich zehn Jahre lang Low-Level-Code geklopft habe, eiskalte Schauer über den Rücken gejagt. Der Kern der Initiative ist brutal: Block-Produktion und Block-Verifikation werden vollständig entkoppelt. Der Builder ist dafür zuständig, die Blöcke gewaltsam zusammenzusetzen; die Verifizierungsknoten broadcasten lediglich Signaturen nach den Konsensregeln, während die vollständige Zustandsprüfung direkt nachgelagert wird. Dieses „erst einsteigen, dann nachbezahlen“-PBS-artige Setup kenne ich nur zu gut – ist das nicht genau der Drei-Schienen-Konsens, den dusk durchdrungen hat? Und Dusk zerlegt es noch gnadenloser.
​Beim tiefen Blick in den Quellcode von @Dusk zeigt sich: Die angepriesene SBA (kurzer Beweis) ist in Wahrheit ein extrem schwergewichtiges Macht- und Verteilungs-Poker. Der Block-Produzess wird in drei eiserne Schranken zerschnitten: Der Vorschlagsknoten muss per Zero-Knowledge-„Blindauktion“ heimlich das Recht zum Block-Claim sichern, um gezielte DoS-Angriffe im Keim zu ersticken; das Verifikationskomitee prüft die Daten auf ihre rechtmäßige Gültigkeit; das Genehmigungskomitee macht die finale Rückversicherung. „Simpel“ bezieht sich dabei nur auf die verschlüsselte Quittung, die durch die Kompression des PLONK-Schaltkreises entsteht; darunter muss die Zustandsmaschine im schlimmsten Netzwerkkontext bis zu 50 Iterationen hart durchlaufen.
​Diese Ausbalancierung stützt sich ganz auf dusk’ ökonomisches Modell. Der Netzwerkzugang ist auf eine harte Staking-Schwelle von 1000 DUSK festgenagelt, und die Stimmkraft der Knoten wird strikt in einem konstanten Gewicht von 64 Credits geklemmt. Wagst du Doppel-Signaturen oder böswilliges Verhalten oder brichst du die Verbindung ab? Dann kassiert das Slashing-Mechanismus-System gnadenlos den Kapitaleinsatz ein. Das ist nicht einfach nur eine Aufteilung des Ablaufs, sondern eine mit echtem Geld verschweißte Anti-Misbehavior-Grenze.
​Aber nach der alten Regel, nach der ich Protokollsicherheit analysiere, muss man bis zur Unterhose durchleuchten, um das Risiko zu sehen. Je mehr man am Konsens herumschneidet, desto exponentiell steigt in einem Netzwerk Menge und Umfang der BLS-Signaturaggregation und des P2P-Nachrichtenbroadcasts – die Angriffsfläche im Code wird direkt auf Maximum hochgefahren. Dusk verdichtet die Stimmkraft auf Dutzende Komitee-Mitglieder: Anscheinend schützt das vor Single-Point-of-Failure, tatsächlich verlagert es aber das Risiko der Knoten-Kooperation in die „Darknet“-Ecke. Im Gegensatz dazu läuft es bei BNB in dieser Runde „erst signieren, dann verifizieren“: Zwar erkauft man sich damit durch asynchrone Verifikation einen extremen TPS-Wert, aber in dem ultrakurzen Zeitfenster für die Blockverifikation kann der Builder sehr leicht einen bösartigen Zustand einschleusen – und wird so zur direkten Zielscheibe für MEV-Überholmanöver oder sogar für Cross-Chain-„Sniping“.
​Die Entkopplung von Blockproduktion und Blockverifikation ist definitiv der Coup zur Skalierung – und zwar zum Vorteil eines echten Plans. Dusk tauscht mit drei Gremien Macht gegen mehr Verteilung; BNB tauscht mit asynchroner Verifikation TPS gegen…? #dusk $DUSK