Der steigende Fokus auf Post-Quantum-Sicherheit zwingt Entwickler von Layer-2-Lösungen, asymmetrische Signaturverfahren wie ECDSA zu hinterfragen. Ein aktueller Ansatz nutzt ausschließlich Hash-Preimages, verzichtet damit komplett auf klassische Signaturen und implementiert ein Rollup auf dem OP-Stack, das seine Sicherheit auf die Vorbildfunktion des 1998 veröffentlichten Guy-Fawkes-Protokolls stützt. Dieser Artikel fasst die kryptografischen Grundlagen, die architektonischen Entscheidungen und die Bewertung im L2BEAT-Framework zusammen – ausschließlich basierend auf den bereitgestellten Fakten.

Historischer und theoretischer Kontext: Das Guy-Fawkes-Protokoll

Das Guy-Fawkes-Protokoll wurde 1998 von Ross Anderson, Bruno Crispo und weiteren Autoren vorgestellt (Quelle S1). Es zeigte, dass digitale Authentifizierung und Verbindlichkeit ausschließlich über Einweg-Hashfunktionen und Zeitstempel- bzw. Reihenfolgedienste realisierbar sind – ohne asymmetrische Schlüsselpaare. Die Kernidee beruht auf zwei Bedingungen:

• Die Hashfunktion muss strikt präimagesicher sein.
• Eine verlässliche, append-only chronologische Ordnung muss gewährleistet sein.

Im originalen Modell werden pro Nachricht nur zwei Hash-Operationen benötigt (Metric: Guy-Fawkes Einweg-Hashberechnungen pro Nachricht = 2, Jahr 1998). Diese geringe Rechenlast macht das Verfahren attraktiv für ressourcenarme L2-Umgebungen.

Der in dem OP-Stack-Entwurf angewandte “First commit wins”-Mechanismus verkörpert das Prinzip “append-only”: Jeder Commit wird dauerhaft an die Kette angehängt, und nur der früheste Commit kann erfolgreich offenbart werden. Damit wird das klassische Front-Running-Problem eliminiert, weil spätere Commits keinen Anspruch mehr auf die gleiche Preimage-Bindung erhalten.

Post-Quantum-Sicherheitsanalyse von Keccak-256

Die einzige kryptographische Annahme im beschriebenen Rollup ist die Präimage-Resistenz von Keccak-256. Auf einem klassischen Computer gilt ein Sicherheitsniveau von 256 Bit. Unter Berücksichtigung von Grovers Algorithmus wird dieser Aufwand quadratisch reduziert:

• Grover reduziert den N-Bit-Suchraum auf N/2, wodurch für Keccak-256 ein theoretischer Aufwand von 2 ¹²⁸ Quanten-Operationen entsteht (Metric: Theoretischer Quanten-Suchaufwand Keccak-256 = 128, Jahr 2024).
• Laut NIST-Berichten (2024) bleibt 2 ¹²⁸ praktisch unknackbar, weil die erforderliche Quantenschaltungstiefe, Fehlerkorrektur und Ausführungszeit unrealistisch hoch sind.

Die im System genutzten 160-Bit-Adressen werden durch Trunkierung von Keccak-256 erzeugt (trunc20). Diese Kürzung reduziert die Second-Preimage-Resistenz auf etwa 2 ⁸⁰ Operationen (Metric: Theoretischer Quanten-Suchaufwand 160-Bit-Adresse = 80, Jahr 2024). Dieser Unterschied wird im Design bewusst als akzeptabler Trade-off für Speicher- und Gas-Effizienz dargestellt, wobei die Kern-Hash-Kette weiterhin 2 ¹²⁸ Sicherheit bietet.

Architektur des signaturlosen OP-Stack-Rollups

Der Rollup läuft auf Ethereum Mainnet (Chain-ID 42069000, live seit 30. September 2026) und verwendet ausschließlich hash-basierte Konten. Die wichtigsten Komponenten lassen sich wie folgt zusammenfassen:

• Kontomodell: Jeder Account repräsentiert das Ende einer Lamport-artigen Keccak-256-Hash-Kette. Der aktuelle Zustand wird durch den Hash-wert s0 = keccak256("OPOTASPENDv1" ‖ spendsk ‖ r) definiert.
• Schlüsselableitung: Pro-Konto-geheimnis sk wird iterativ über sk = keccak256(sk-1) erzeugt, wobei standardmäßig N = 1000 Schritte zulässig sind.
• Commit-Reveal-Mechanismus: Zwei neue EIP-2718-Transaktionstypen werden eingeführt:
  • HashCommitTx (0x7C) bindet ein (Preimage, Tx-Digest) ohne sofortige Offenlegung.
  • HashRevealTx (0x7F) offenbart das Preimage innerhalb eines festgelegten Zeitfensters (Standard 5 Blöcke).
• “First commit wins”-Regel: Jeder Account besitzt einen einzigen Pending-Commit-Slot. Ein neuer Commit wird abgewiesen, solange der Slot nicht durch das zugehörige Reveal oder den Ablauf des Zeitfensters geleert wurde. Diese Regel wurde am 21. Oktober 2026 aktiviert.
• Gas-Kosten: Commit- und Reveal-Transaktionen sind für Nutzer gas-frei; alle Kosten werden vom Sequencer getragen.
• Grenzüberschreitungen: Es gibt keine native ETH-Spending-Funktion; Zahlungen erfolgen über gebrückte Token (USDC/EURC). Ein-mal-Adressen werden per OPHASHADDRv1 erzeugt, wobei ein 8-Bit-View-Tag das Scannen von Ankündigungs-Events erleichtert.

Commit-Reveal im Detail

Der Ablauf besteht aus drei Schritten:

1. Der Nutzer erzeugt das nächste Preimage sN und sendet einen HashCommitTx, welcher (sN, txDigest) im Merkle-ähnlichen State speichert.
2. Nach Bestätigung des Commits im Block wartet die Wallet auf den Commit-Receipt.
3. Der Nutzer broadcastet HashRevealTx, welches das Preimage veröffentlicht und die Nullifier-Markierung vornimmt. Auch im Falle eines Reverts wird die Autorisierung verbraucht.

Dieser Mechanismus stellt sicher, dass ein Angreifer das Preimage nicht vorzeitig auslesen und für eigene Transaktionen nutzen kann.

Front-Running und die “First commit wins”-Lösung

Ohne Authentifizierung könnte ein Angreifer ein bereits bekanntes Preimage in einer eigenen Transaktion mit einer anderen Zieladresse wiederverwenden. Durch das “First commit wins”-Prinzip wird das Commit-Slot nach dem ersten gültigen Commit gesperrt, sodass ein späterer Versuch, denselben Preimage zu binden, abgelehnt wird. Die Transaktions-Pool-Sichtbarkeit ist auf den internen Endpunkt beschränkt, sodass Außenstehende das Pending-Commit nicht auslesen können.

Griefing-Risiken

Ein Angreifer kann zwar einen Junk-Commit für eine Adresse posten und damit das Slot bis zu fünf Blöcke blockieren. Da dieser Commit nicht mit einem bekannten Preimage geöffnet werden kann, ist ein Diebstahl von Geldern ausgeschlossen; jedoch kann das Konto temporär unbrauchbar werden. Das System begrenzt dieses Risiko durch ein per-Adresse-Rate-Limit von zehn Transaktionen pro Minute.

Zustands-Desynchronisation bei Hash-Ketten-Wallets

Bei Netzwerk-Abbrüchen oder parallelen Transaktionen können Wallets den aktuellen Ketten-Index verlieren. In der Praxis führte dies bereits zu einer Situation, in der das Wallet nicht mehr weiterarbeiten konnte, bis es den Zustand aus der Chain neu synchronisierte. Deshalb ist eine robuste Resynchronisationslogik mandatory.

Bewertung im L2BEAT Stages Framework

Das L2BEAT-Framework definiert mehrere Reifestufen für Rollups. Für Stage 0 (“Full Training Wheels”) sind zwingend:

• Datenverfügbarkeit auf L1.
• Open-Source-Knotensoftware zur lückenlosen Zustandsrekonstruktion.

Der beschriebene Rollup liefert keine kryptografischen Gültigkeitsbeweise und verzichtet auf ein funktionierendes Dispute-Game. Nach den Spezifikationen (Quelle S3) wird er daher mit dem Wert Stage 0 = 0 (nicht erreicht) eingestuft (Metric: L2BEAT Rollup-Reifestufe ohne Dispute-Verfahren = 0, Jahr 2023).

Offene Fragen und weiterer Forschungsbedarf

• Ist das “First commit wins”-Prinzip mit kurzer Expiry sicher gegenüber einem Sequencer, der Commit- und Reveal-Phasen reordern oder reorgs durchführen kann?
• Welchen Nutzen bringt die erweiterte, append-only Guy-Fawkes-Variante im Vergleich zu dem aktuellen Single-Slot-Ansatz?
• Gibt es effizientere Methoden, den Commit-Schritt zu authentisieren, etwa durch eine sekundäre, kürzere Hash-Kette?
• Wie lässt sich das aktuelle Design als allgemeine Account-Abstraction (z. B. EIP-7702) auf anderen L2-Plattformen übertragen?
• Welche Änderungen sind nötig, um ein vollständiges Fault-Proof-System (z. B. Cannon/Asterisc) zu integrieren?

Fazit

Der signaturlose, hashkettenbasierte Rollup auf dem OP-Stack demonstriert, dass post-quantum-sichere Zahlungen ohne asymmetrische Signaturen prinzipiell machbar sind. Die Sicherheit beruht auf der Präimage-Resistenz von Keccak-256, die selbst unter Grovers Algorithmus einen Aufwand von 2 ¹²⁸ Operationen erfordert – ein Niveau, das laut NIST-Analysen praktisch unknackbar bleibt. Die 160-Bit-Adress-Trunkierung reduziert die Sicherheit auf 2 ⁸⁰, bleibt jedoch für das Adressierungsschema ausreichend.

Architektonisch ermöglicht das Commit-Reveal-Schema in Kombination mit der “First commit wins”-Regel ein Front-Running-resistentes System, das jedoch anfällig für Griefing-Attacken und Sequencer-Manipulationen bleibt. Die fehlende Dispute-Layer-Komponente verhindert das Erreichen von Stage 0 im L2BEAT-Framework, sodass das aktuelle Design als experimentelles Interim-Produkt zu verstehen ist.

Weitere Forschung sollte sich auf die Integration von append-only Guy-Fawkes-Commit-Logs, die Entwicklung eines robusten Dispute-Games und die Erschließung von Fault-Proof-Verfahren konzentrieren, um das System von einem provokativ-innovativen Prototypen zu einer produktionsreifen, post-quantum-sicheren L2-Lösung zu führen.