NachrichtenKryptoEthereum L2 BB84 schafft Transaktionssignaturen ab, um der Quantenbedrohung zu begegnen

Ethereum L2 BB84 schafft Transaktionssignaturen ab, um der Quantenbedrohung zu begegnen

Autor: Coindoo·

Wichtige Erkenntnisse

  • •BB84 läuft seit dem 30. September auf dem Ethereum-Mainnet und ersetzt ECDSA-Signaturen durch keccak-256-Hash-Ketten-Konten, um die Anfälligkeit für künftige Quantenangriffe zu verringern.
  • •Zahlungen im Netzwerk werden ausschließlich in gebridgtem USDC und EURC abgerechnet; Commit- und Reveal-Transaktionen sind für Nutzer kostenlos, und für jeden Empfänger wird eine frische Einmaladresse erstellt.
  • •Eine Front-Running-Schwachstelle in unsignierten Commits wurde beim Verfassen des Research-Beitrags entdeckt und am 21. Oktober durch eine First-Commit-Wins-Regel behoben; Griefing- und Rogue-Sequencer-Risiken bestehen fort.
  • •Dem Rollup fehlen Fault Proofs, sodass es nach L2BEATs Staging-Rahmenwerk nicht einmal Stage 0 erfüllen würde; Auszahlungen hängen von einem berechtigten Proposer ab.
  • •Hadamard schlägt vor, dass Hash-Ketten-Validierung als EIP-7702-artiger oder nativer Account-Abstraction-Modus auf Allzweck-Layer-2-Netzwerken übernommen werden könnte; ein ausführlicher Text wird für arXiv vorbereitet.
Ethereum L2 BB84 schafft Transaktionssignaturen ab, um der Quantenbedrohung zu begegnen

BB84, ein OP-Stack-Rollup, der auf dem Ethereum-Mainnet unter der Chain-ID 42069000 läuft, hat Transaktionssignaturen aus seinem Netzwerk vollständig entfernt und durch Lamport-artige Hash-Ketten ersetzt – ein Design, das die langfristige Quantenbedrohung für konventionelle Kryptografie ab schwächen soll. Das Netzwerk läuft seit dem 30. September auf dem Mainnet. Sein Gründer, der unter dem Pseudonym Hadamard veröffentlicht, beschrieb das System in einem Ethereum-Research-Beitrag vom 24. Oktober und bat um kritisches Feedback.

Gewöhnliche Ethereum-Konten autorisieren Transaktionen mit ECDSA-Signaturen, die ein ausreichend großer Quantencomputer mit Shors Algorithmus brechen könnte. Eine solche Maschine existiert heute nicht, aber Warnungen vor offengelegten Wallet-Keys haben Entwickler dazu gebracht, nach Alternativen zu suchen – ein Key wird öffentlich sichtbar, sobald ein Konto eine Transaktion gesendet hat. Hash-basierte Konstruktionen gehören zudem zu den ältesten Post-Quantum-Kandidaten: Leslie Lamport schlug 1979 ein hash-basiertes Signaturverfahren vor, und die Post-Quantum-Standards des NIST von 2024 enthalten mit SLH-DSA ebenfalls ein hash-basiertes Verfahren.

Hash-Ketten-Konten, Schritt für Schritt

Jedes BB84-Konto basiert auf einem Geheimnis, das immer wieder mit keccak-256 gehasht wird – derselben Hash-Funktion, die Ethereum selbst nutzt –, wodurch eine Kette von Werten entsteht, bei der nur der letzte Wert öffentlich ist. Für eine Zahlung legt die Wallet den Wert vor der aktuellen Position offen, den jeder durch einmaliges Hashen überprüfen kann. Das Netzwerk zeichnet diesen Wert dann auf und verschiebt das Konto einen Schritt in der Kette.

Der Protokollstandard liegt bei 1.000 Zahlungen pro Hash-Kette, während die Entwickler-CLI von BB84 für jede Einmaladresse 10-stufige Ketten erstellt. Ein Schritt wird auch dann verbraucht, wenn die Zahlung selbst fehlschlägt, und die Kette weist jede konventionell signierte Transaktion zurück.

Zahlungen laufen ausschließlich in gebridgtem USDC und EURC. Sowohl die Commit- als auch die Reveal-aktion sind für Nutzer kostenlos, und Zahler erstellen für jeden Empfänger eine frische Einmaladresse.

Der Sicherheits-Kompromiss

Der Beitrag nennt die Grenzen des Designs. Innerhalb des Netzwerks hängt alles davon ab, dass keccak-256 schwer umzukehren ist, und Grovers Quantensuchalgorithmus würde das nur auf etwa 2^128 Operationen reduzieren. Adressen werden jedoch auf 160 Bit verkürzt, was auf der Adresse selbst nur etwa 2^80 Quantenresistenz übrig lässt. Die Dokumentation von BB84 wirbt ohne diesen Vorbehalt mit 128-Bit-Post-Quantum-Sicherheit. Der Ethereum-Mainnet ist zudem weiterhin ECDSA: Einzahlungen starten über gewöhnliche Ethereum-Wallets, und Auszahlungen werden an diese überwiesen.

Ein Front-Running-Fehler, der beim Schreiben des Beitrags entdeckt wurde

Die Offenlegung eines Geheimnisses macht es öffentlich, sodass jeder Beobachter es in eine Transaktion kopieren könnte, die an sich selbst zahlt. Um das zu verhindern, sendet die Wallet zunächst eine Commit-Transaktion, die das Geheimnis an genau eine Zahlung bindet, ohne es offenzulegen. Das Reveal muss standardmäßig innerhalb von fünf Blöcken folgen.

Die Schwachstelle bestand darin, dass Commits keine Signatur tragen, weil es nichts zum Signieren gibt. In der ersten Version ersetzte ein neuer Commit einfach den ausstehenden. Ein Angreifer, der ein Geheimnis in einem ausstehenden Reveal entdeckte, könnte einen Commit einschleusen, der dieses Geheimnis an seine eigene Zahlung bindet. Hadamard sagt, das Team habe den Fehler beim Schreiben des Beitrags entdeckt und ihn mit einer neuen Regel behoben, die am 21. Oktober in Kraft trat. Nach der überarbeiteten Regel gewinnt der erste Commit, der Slot wird erst nach dem passenden Reveal oder Ablauf freigegeben, die Wallet wartet mit dem Reveal, bis ihr Commit in einem Block landet, und die öffentliche RPC-Schnittstelle legt keine ausstehenden Transaktionen offen.

Was die Korrektur offenlässt

Griefing bleibt möglich: Jeder kann einen Junk-Commit einreichen und eine Adresse für bis zu fünf Blöcke blockieren, ohne deren Mittel bewegen zu können. Ein bösartiger Sequencer ist ein weiteres Restrisiko: Läuft ein ehrlicher Commit ab oder wird er reorganisiert, während sein Reveal aussteht, ist das Geheimnis nicht mehr gebunden. Derzeit sieht nur BB84s eigener Sequencer ausstehende Transaktionen.

Hadamard schlägt eine strengere „Guy Fawkes“-Regel vor, bei der Commits angehängt statt ersetzt werden, sagt aber, diese sei noch nicht umgesetzt. Die Dokumentation geht weiter als der Beitrag und erklärt, dass Commit und Reveal bedeuten, dass ein Sequencer keine Auszahlung stehlen kann.

Eine Wallet, die den Überblick nicht verlieren darf

Da jede Kette eine feste Anzahl von Schritten hat, muss die Wallet sie im allerletzten erneuern, indem sie in dieser letzten Zahlung ein neues Commitment einbindet. Versäumt sie diesen Schritt, ist die Adresse tot. Der Überblick ist ebenso wichtig: Hadamard sagt, App und Kette seien in der Produktion aus dem Takt geraten, sodass Wallets aus Chain-Daten neu synchronisieren können müssen.

Die Geheimnisse müssen weiterhin wie Keys geschützt werden. Die CLI warnt, dass ihre Wallet-Datei Spend-Keys unverschlüsselt speichert, und führt Verschlüsselung als Roadmap-Punkt. Signaturen zu entfernen ändert, wie Ausgaben autorisiert werden – nicht die Notwendigkeit, Geheimnisse sicher aufzubewahren.

Auszahlungen beruhen auf einem vertrauenswürdigen Betreiber

84 hat keine Fault Proofs. Ein berechtigter Proposer übermittelt den Netzwerkzustand über ein benutzerdefiniertes Dispute-Spiel an Ethereum, das sofort abschließt, und ohne Proof-System schreibt Hadamard, wäre die Kette nach L2BEATs Rahmenwerk „not even Stage 0“. Das Rahmenwerk stuft Rollups von Stage 0 bis Stage 2 danach ein, wie weit Nutzer einem Betreiber statt einem Proof-System vertrauen müssen. Auszahlungen vertrauen daher dem Proposer. Die Dokumentation beschreibt Auszahlungen weiterhin nach dem OP-Stack-Fault-Proof-Ablauf mit sieben Tagen Reifefrist, aber wie Optimisms Erklärung darlegt, existieren Fault Proofs, damit ein falscher Zustand angefochten werden kann – und hier kann während der Wartezeit nichts angefochten werden. Der Sequencer wird ebenfalls von BB84 betrieben.

Was das Bild verändern würde

Der Beitrag endet mit Fragen, die über eine einzelne Kette hinausgehen. Die größte ist, ob Hash-Ketten-Konten zu einem EIP-7702-artigen oder nativen Account-Abstraction-Validierungsmodus auf Allzweck-Layer-2-Netzwerken werden könnten, was die Idee verfügbar machen würde, ohne zu einer dedizierten Kette zu wechseln. EIP-7702, live seit Ethereums Pectra-Upgrade im Mai 2025, erlaubt gewöhnlichen Konten, Smart-Contract-Code anzunehmen. Hadamard fügt hinzu, dass sich die zusätzlichen Prüfungen mit Optimisms bestehendem Cannon-Tooling beweisen ließen, dass eine Append-only-Commit-Regel sowohl die Griefing- als auch die Sequencer-Lücke schließen würde und dass ein ausführlicher Text mit den vollständigen Regeln für arXiv vorbereitet wird. Ethereums breiter angelegte Migrationsanstrengung, dargelegt in seiner Quantum-Roadmap, umfasst auch Validator-Signaturen, Daten-Commitments und Proof-Systeme.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar. Experimentelle Netzwerke bergen technische und Verwahrisiken.

Quelle: Coindoo