Die Ethereum-Plattform steht vor einer grundlegenden Neuausrichtung, um quantenresistente Signaturen zu integrieren und gleichzeitig die Skalierbarkeit von Layer-1 zu erhalten. Während BLS-Signaturen algebraisch aggregierbar sind, benötigen die alternativen, hash-basierten Verfahren wie XMSS, SPHINCS+ oder SLH-DSA neue Hash-Primitives, die in binären Beweissystemen wie Flock und LeanVM effizient eingesetzt werden können. Der folgende Artikel fasst die wichtigsten Fakten, Benchmarks und Standards zusammen, die die Auswahl geeigneter Hash-Funktionen bestimmen.
Hintergrund: Post-Quantum-Signaturen und die Rolle von Hash-Funktionen
Quantensichere, zustandsbehaftete Signaturen (z. B. XMSS) und zustandslose Signaturen (z. B. SPHINCS+/SLH-DSA) können nicht wie BLS algebraisch aggregiert werden. Deshalb hängt die Sicherheit und Performance von Ethereum Layer 1 künftig stark von der Leistungsfähigkeit der gewählten Hash-Funktion in SNARK-Beweisen ab. Binäre Beweissysteme (Flock, Ligerito) machen dafür algebraische ZK-Hashes wie Poseidon überflüssig und erlauben den Einsatz etablierter Standard-Hashes (SHA-2, Keccak, BLAKE).
Standardisierung von SPHINCS+ als SLH-DSA (FIPS 205)
- Im August 2024 veröffentlichte das NIST den Standard FIPS 205 für SLH-DSA, früher SPHINCS+.
- Der Standard definiert Parameterlängen für SHA-256 und SHAKE256 und bietet Sicherheitslevel 1-5 (128-256 Bit).
- Damit existiert für den Execution Layer eine formell standardisierte, rein hash-basierte Signaturmethode, die exakt auf SHA-2 bzw. SHAKE aufbaut.
Die Standardisierung untermauert das Argument, dass SHA-2 und Keccak/SHAKE trotz höherer Gatterkosten in Flock-Beweisen weiterhin zentrale Sicherheitsanker bleiben.
Ethereum Foundation: Abkehr von Poseidon und Fokus auf binäre Beweissysteme
2026 gab die Ethereum Foundation bekannt, spezialisierte arithmetische ZK-Hashes wie Poseidon nicht weiterzuverfolgen. Der Durchbruch bei Binärfeld-Beweissystemen (Binius, Flock) verlagert den Fokus auf bewährte Primitives wie BLAKE3, BLAKE2s und Keccak. Die relevanten Leistungskennzahlen aus den Benchmarks lauten:
- Flock-Durchsatz auf 10-Core Apple M4 Max: 660 000 BLAKE3-Kompressionen /s, 340 000 SHA-256-Kompressionen /s.
- LeanVM-Aggregationsrate für leanXMSS: 1 650 verifizierte Signaturen /s (Signaturgröße 1,17 KiB).
- LeanVM-Aggregationsrate für leanSPHINCS+: 295 Signaturen /s.
Diese Zahlen zeigen, dass die angestrebte Zielgröße von tausenden Attestierungen pro Konsens-Slot ohne algebraische BLS-Konstruktionen realistisch ist (EIP-8292, 2026).
KangarooTwelve: IETF-Standard und quantifizierte Sicherheitsmarge
- RFC 9861 (2025) definiert KangarooTwelve (K12) und TurboSHAKE als IETF-Standards.
- K12 verwendet nur 12 Runden der Keccak-Permutation – halbiert die Rundenzahl gegenüber SHA-3 (24 Runden).
- Die beste bekannte Kollision auf Keccak-Permutation liegt bei 6 Runden, sodass bei K12 ein Sicherheitsabstand von 6 Runden verbleibt.
- Durch Baum-Hashing und Vektorisierung (AVX-512) erreicht K12 bis zu 0,5 Zyklen pro Byte.
Damit ist KangarooTwelve von einer „kürzlich publizierten Design-Variante“ zu einem vollwertigen, quantifizierten RFC-Standard avanciert.
Leistungskennzahlen von Flock und LeanVM im Detail
Die Praxisrelevanz der Durchsatzmetriken spiegelt sich im Architekturwechsel der Ethereum Foundation wider. Die wichtigsten Messwerte:
| Metric | Wert | Einheit | Jahr |
|---|---|---|---|
| Flock-Durchsatz BLAKE3 | 660 000 | Kompressionen/s | 2026 |
| Flock-Durchsatz SHA-256 | 340 000 | Kompressionen/s | 2026 |
| LeanVM XMSS-Aggregationsrate | 1 650 | Signaturen/s | 2026 |
| Größe einer leanXMSS-Signatur | 1,17 | KiB | 2026 |
| RFC-Nummer KangarooTwelve / TurboSHAKE | 9861 | RFC | 2025 |
| RFC-Nummer BLAKE2 | 7693 | RFC | 2015 |
Die Benchmarks zeigen, dass BLAKE3 in Flock fast doppelt so schnell ist wie SHA-256, während LeanVM bereits mehrere tausend XMSS-Signaturen pro Sekunde verifizieren kann – ein entscheidender Faktor für die Post-Quantum-Attestations-Aggregierung.
Risiken und Gegenargumente
- Fehlende Hardware-Beschleunigung für BLAKE3: Auf Validator-Knoten fehlt derzeit eine dedizierte Instruktionsunterstützung, sodass BLAKE3 rein über SIMD laufen muss. Auf schwächerer Hardware kann dies die Energieeffizienz beeinträchtigen.
- Längen-Erweiterbarkeit von SHA-2: Die Länge-Extension-Schwäche schließt SHA-2 als Random Oracle aus. In Beweissystemen, die die Fiat-Shamir-Transformation nutzen, birgt die Verwendung von unverändertem SHA-256 ohne Prefix/Domain-Envelope gravierende Sicherheitsrisiken.
FAQ zur Hash-Auswahl für Ethereum
Warum nutzt Ethereum für Post-Quantum-Signaturen nicht einfach NIST ML-DSA (Dilithium)?Gitterbasierte Signaturen wie ML-DSA haben signifikante Schlüssel- und Signaturgrößen und lassen sich nicht verlustfrei in einem einzigen kompakten SNARK über Binärfelder aggregieren. Hash-basierte Verfahren (XMSS/SPHINCS+) basieren zudem auf minimaleren kryptografischen Annahmen.Kann das bestehende Keccak-256 von Ethereum unverändert beibehalten werden?Theoretisch ja, da Keccak bereits im Execution Layer verankert ist und hohe Sicherheitsmargen bietet; praktisch erfordert Keccak in Beweissystemen wie Flock rund 38 000 AND-Gatter pro Permutation, was die Beweiserstellung gegenüber BLAKE3 um den Faktor 2,5-3 verlangsamt.Was unterscheidet die Hash-Funktion im Consensus Layer von der im Execution Layer?Im Consensus Layer dominieren kurze Festlängen-Nachrichten (39-54 Bytes für WOTS-Ketten und Merkle-Bäume) mit strikten Latenz-Anforderungen im Slot-Budget, während der Execution Layer neben variablen Transaktionsdaten vor allem extrem große Merkle-Patricia- bzw. Binär-Statusbäume verarbeiten muss.
Fazit
Die Evaluation zeigt, dass die Kombination aus standardisierten, gut analysierten Hash-Primitives und hochperformanten binären Beweissystemen die Basis für Ethereums Post-Quantum-Roadmap bildet. Die NIST-Standardisierung von SPHINCS+ als SLH-DSA (FIPS 205) liefert einen klaren regulatorischen Anker für zustandslose Signaturen, während die Abkehr von Poseidon zugunsten von BLAKE3, BLAKE2s und Keccak die Nutzung etablierter, kryptoanalytisch gehärteter Primitiven ermöglicht. KangarooTwelve ergänzt das Portfolio durch einen IETF-Standard mit halbierter Rundenzahl und nachgewiesener Sicherheitsmarge.
Leistungsmetriken von Flock (660 k BLAKE3-Kompressionen /s) und LeanVM (1 650 XMSS-Verifikationen /s) belegen, dass die angestrebten Ziele – tausende Attestierungen pro Konsens-Slot und Echtzeit-Proving von Ethereum-Blöcken – bereits auf Consumer-Hardware erreichbar sind. Gleichzeitig müssen offene Risiken, insbesondere die fehlende Hardware-Beschleunigung für BLAKE3 und die Länge-Extension-Problematik von SHA-2, in zukünftigen Implementierungen adressiert werden.
Insgesamt positioniert sich Ethereum mit einer klaren strategischen Ausrichtung: standardisierte, gut verstandene Hash-Funktionen, kombiniert mit fortschrittlichen binären SNARK-Systemen, bilden das Fundament für eine skalierbare, quantenresistente Zukunft.