Die Einführung quantenresistenter Signaturen wie leanSPHINCS oder ML-DSA stellt Ethereum-Rollups vor ein neues Daten-Bottleneck. Im Vergleich zu klassischen ECDSA-Signaturen sind PQ-Signaturen bis zu 100-mal größer, sodass bereits wenige Transaktionen die L1-Blob-Kapazitäten sprengen würden. EIP-8288 kombiniert rekursive STARK-Aggregation mit der minimalen zkVM leanVM, um Signaturen und Beweise aus den Transaktionskörpern auszulagern und die Datenmenge pro Transaction auf 100-129 Byte zu reduzieren. Dieser Artikel fasst die Fakten, Messungen und die langfristige Roadmap zusammen, die ausschließlich aus den bereitgestellten Quellen stammen.

Das Daten-Bottleneck bei Post-Quantum-Signaturen in Rollups

Rollups haben die Ausführungslogik von L1 verlagert, doch die Authentifizierung jeder Transaktion landet weiterhin auf L1. Ohne Aggregation würden PQ-Signaturen die L1-Blob-Grenzen schnell überschreiten:

• ECDSA-Signatur (secp256k1): 65 Byte
• Falcon-512 Signatur: ~666 Byte
• ML-DSA-44 Signatur: 2 420 Byte
• leanSPHINCS Signatur + Public Key: 4 936 Byte + 32 Byte
• SLH-DSA-128s Signatur: 7 856 Byte

In einem 6-Blob-Kanal (maximale L1-Blob-Kapazität) können mit ECDSA-Signaturen rund 6 600 Transaktionen verarbeitet werden. Mit einer einzigen leanSPHINCS-Signatur inline sinkt die Kapazität auf nur 155 Transaktionen – 99 % der Daten würden von Signaturen beansprucht. ZK-Anwendungen (z. B. leanVM-Beweise) benötigen zusätzlich mehrere hundert KiB pro Proof, was das Problem weiter verschärft.

EIP-8288 – Architektur und Funktionsweise

EIP-8288 definiert eine L1-Design-Erweiterung, die Signaturen und Beweise aus den Blöcken auslagert. Die Kernidee ist, dass schwere kryptografische Operationen in einem rekursiven STARK-Baum zusammengefasst und als ein einziger leanVM-Aggregat-Proof auf L1 gepostet werden.

Integration mit EIP-8141 Frame Transactions

EIP-8288 baut auf dem nativen Frame-Transaktionsstandard EIP-8141 auf. Transaktionen werden in drei Frames (Validierungs-, Ausführungs- und Bezahl-Frames) aufgeteilt, wodurch die Kontenlogik von dem Signaturverfahren entkoppelt wird. Die neue “Dependency Frame”-Erweiterung ermöglicht, dass ein Transaction-Wrapper im Mempool die Signatur bzw. den Beweis enthält, während der Block selbst nur einen Verweis (Dependency Triple) enthält. Das reduziert die on-chain Datenmenge erheblich.

Proof-Aggregation in leanVM

Der leanVM-Aggregator sammelt Signaturen und ZK-Beweise aus vielen L2-Blöcken, erzeugt daraus ein rekursives STARK-Aggregat und postet dieses als neuen Batch-Typ auf L1. Wesentliche Kennzahlen:

• Ein 32-vCPU-AWS-c7a.8xlarge-Instance aggregiert bis zu 170 leanSPHINCS-Signaturen pro Sekunde.
• Ein Aggregat enthält bis zu 4 096 Statements von bis zu 64 Programmen.
• Die Größe des Aggregats beträgt konstant ~322 KB (komprimiert) bzw. ~354 KB unkomprimiert, unabhängig von der Anzahl der enthaltenen Signaturen.
• Verifikationsdauer eines leanSPHINCS-Aggregats in leanVM: 7,46 ms (Benchmark 2026).

Durch die Aggregation sinkt der L1-Blob-Bedarf von 79 Blobs (inline) auf 2,8-3,3 Blobs pro Block – ein Einsparungsfaktor von 96 %.

Messungen und Leistungsdaten

Alle Messungen stammen aus dem PoC-Paper “EIP-8288 Proof Aggregation on OP Stack” (Ethresearch, 2026-10-31) und den zugehörigen Benchmark-Reports.

• Transaktionsgröße nach Kompression: 100-129 Byte (inkl. Signatur-Abhängigkeit), nahe an ECDSA-Transaktionen.
• Durchsatz leanSPHINCS-Aggregation: 170-195 Signaturen /s auf einer 32-vCPU-Instanz.
• L1-Blob-Bedarf bei 170 Transaktionen /s: 2,8-3,3 Blobs (Aggregat) vs. 79 Blobs (inline).
• Gas-Kosten pro Signatur-Validierung (EIP-8288): 3 000 Gas.
• Gas-Kosten pro STARK-Beweis-Validierung (EIP-8288): 30 000 Gas.
• Cannon-Trace-Aufwand für disputed Aggregat-Verifikation: ca. 800 Millionen MIPS64-Schritte (unter 13-14 MiB Speicherbedarf).
• Rechenkosten pro Signatur: ~0,0000027 $ (bei voller Auslastung), aber permanente Infrastrukturkosten bei niedriger Last.

In einem 6-Blob-Kanal ermöglichen signatur-aggregierte Transaktionen etwa 3 550-4 096 Transaktionen, gegenüber nur 155 bei inline PQ-Signaturen.

Roadmap und langfristige Perspektive

Die Ethereum-Foundation hat 2026 die Initiative “Lean Ethereum” gestartet und strebt bis 2029 eine vollständige Post-Quantum-Resistenz über Konsens-, Daten- und Ausführungsebene an. Die Kernkomponenten leanVM und leanSPHINCS sind zentrale Bausteine dieser Roadmap:

• 2026: Veröffentlichung von EIP-8288, EIP-8141-Erweiterungen und ersten Benchmarks.
• 2029: Zieljahr für vollständige Post-Quantum-Resistenz (Quelle: EF Protocol Priorities, 2026-09-07).

Die OP-Stack-Experimente zeigen, dass L2-Netzwerke bereits als Testfeld für künftige L1-Standards fungieren. Sobald die L1-Implementierung von EIP-8288 vollständig ist, könnten Aggregat-Proofs noch weiter reduziert werden, etwa durch kontinuierliche ZK-Rollup-Umstellungen, die den Blob-Verbrauch weiter senken.

Risiken und offene Fragen

Während die Benchmarks beeindruckend sind, gibt es konkrete Gegenargumente, die im PoC adressiert werden:

• Sequencer- und Prover-Latenzen: Bei Reorganisationen oder Batch-Verzögerungen kann ein Aggregat außerhalb des Sequencing-Fensters gepostet werden, was dazu führt, dass betroffene Blöcke nur noch Deposit-Blöcke enthalten – Transaktionen werden verzögert oder verworfen.
• Fehlende GPU-Beschleunigung: Die aktuelle Implementierung nutzt reine CPU-Leistung. Ohne GPU-Beschleunigung bleiben die Fixkosten hoch, besonders bei niedriger Transaktionslast.
• Infrastrukturkosten: Eine 32-vCPU-Instanz läuft dauerhaft und verursacht Kosten, die bei geringem Durchsatz nicht durch die minimale Rechengebühr von ~0,0000027 $ pro Signatur gedeckt werden.

Weitere Forschungspunkte umfassen die Trennung von Tree-Konstruktion und Programmlogik in leanVM, das Erhöhen des Statements-Limits über 4 096 hinaus und die Integration von GPU-Prover-Kernen.

Häufig gestellte Fragen (FAQ)

Warum können Post-Quantum-Signaturen nicht einfach wie bisher auf L1 veröffentlicht werden?
PQ-Signaturen (z. B. leanSPHINCS) benötigen 2,4 KB bis fast 8 KB, verglichen mit 65 Byte ECDSA. In einem 6-Blob-Kanal würde bereits ein kleiner Satz von Transaktionen das gesamte Datenkontingent füllen, wodurch Rollups praktisch unbenutzbar würden.

Wie wird die Sicherheit bei Betrugsversuchen garantiert?
Der OP-Stack-Fault-Proof-Mechanismus (Kona/Cannon) führt die vollständige leanVM-Aggregat-Verifikation on-chain im MIPS64-Emulator aus. Durch Vorabberechnung eines 1-KB-Klassenschlüssels sinkt der Verifikationsaufwand auf etwa 800 Millionen MIPS-Schritte, deutlich unter dem Cannon-Limit.

Fazit

EIP-8288 kombiniert rekursive STARK-Aggregation mit der minimalistischen zkVM leanVM, um das zentrale Daten-Bottleneck bei quantenresistenten Signaturen in Ethereum-Rollups zu lösen. Durch das Auslagern von Signaturen und ZK-Beweisen aus den Transaktionskörpern reduziert das System die L1-Blob-Nutzung um bis zu 96 %, die Transaktionsgröße auf 100-129 Byte und die Gas-Kosten für Verifikation auf ein überschaubares Niveau (3 000 Gas pro Signatur). Benchmarks auf einer 32-vCPU-Instanz zeigen, dass 170 leanSPHINCS-Signaturen pro Sekunde realistisch sind und damit ein geschätztes Durchsatz-Limit von 4 080 Signaturen pro Block (bei 2-Sekunden-Blockzeit) erreichen. Die Ethereum-Foundation plant, diese Technologie bis 2029 vollständig in die Mainnet-Architektur zu integrieren, was den Weg für eine langfristig sichere, skalierbare und post-quantum-resistente Ethereum-Infrastruktur ebnet. Trotz offener Herausforderungen – insbesondere Latenz- und Infrastrukturkosten – liefert EIP-8288 ein praktikables, messbar getestetes Fundament für die nächste Generation von L2-Rollups.