Der Übergang von BLS-Signaturen zu hash-basierten leanSig-Schlüsseln im Rahmen der Ethereum-Roadmap stellt das bisherige RANDAO-System vor ein existenzielles Problem: Ohne BLS-Schlüssel ist EIP-7998 nicht mehr funktionsfähig. Der vorgestellte Ansatz einer post-quantensicheren Verifiable Random Function (PQ-VRF) nutzt PRF-Commitments und WHIR-Stark-Beweise, um den RANDAO-Mechanismus bereits ab Konsens-Meilenstein I zu schützen und die Lücke bei Meilenstein L zu schließen.
Hintergrund: RANDAO, BLS-Schlüssel und die Meilensteine I & L
Im aktuellen Ethereum-Design erzeugt jeder Block-Proposer einen BLS-VRF-Output und einen zugehörigen Nachweis (EIP-7998). Dieser Mechanismus verhindert den „last-revealer-Attack“ und ermöglicht Single Secret Leader Election (SSLE). Bei Meilenstein L werden jedoch sämtliche BLS-Schlüssel durch leanSig-Schlüssel ersetzt. Da BLS-Schlüssel auf der Kurve BLS12-381 basieren, können sie von einem zukünftigen quanten-resistenten Computer (CRQC) mittels Shor-Algorithmus gebrochen werden. Ohne Ersatzschlüssel würde das RANDAO-System vollständig zusammenbrechen.
Kernkonzept der PQ-VRF: PRF-Commitment und WHIR-Beweis
Der Vorschlag verwendet ein PRF-Commitment-VRF, das den VRF-Schlüssel deterministisch aus dem leanSig-Seed ableitet. Die Ableitung erfolgt über das Poseidon16-Hash-Konstrukt im KoalaBear-Feld (31-Bit-Primzahl p = 2^31 - 2^24 + 1 = 2130706433 ). Der daraus resultierende 8-Elemente-Vektor ( vrfsk ) liefert 124 Bit klassisches Sicherheitsniveau.
- Der VRF-Schlüssel wird ohne separate Registrierungszeremonie aus dem bereits on-chain registrierten leanSig-Seed abgeleitet.
- Die VRF-Ausgabe wird wie üblich über das gleiche Poseidon-Hash-Verfahren erzeugt.
- Der Nachweis ist ein eigenständiger WHIR-Beweis (WHIR-Stark), der die korrekte Berechnung des PRF-Outputs attestiert.
Der WHIR-Beweis wird synchron im Beacon-Block-Body eingebettet und benötigt keine zusätzlichen Precompiles in der leanVM.
Technische Details und Leistungskennzahlen
Die Implementierung basiert auf drei Poseidon16-Kompressionen über dem KoalaBear-Feld. Die wichtigsten Messwerte (Stand 2026) sind:
| Metric | Wert | Einheit | Quelle |
|---|---|---|---|
| Beweiserzeugungszeit (Prover) | 81,4 | ms | S1 |
| Beweisverifikationszeit (Node) | 19,2 | ms | S1 |
| Beweisgröße (WHIR) | 116 | KB | S1 |
| BLS-VRF-Beweisgröße (EIP-7998) | 96 | Bytes | S2 |
| Hash-Chain-RANDAO Overhead (EIP-8321) | 32 | Bytes | S3 |
| KoalaBear-Feldgröße | 2130706433 | – | S5 |
| Sicherheitsniveau (klassisch) | 124 | Bits | S5 |
Die Prover-Kosten von 81,4 ms liegen in einem 12-Sekunden-Slot praktisch im Hintergrund. Die Verifikationszeit von 19,2 ms ist mit dem Aufwand für die BLS-Aggregat-Verifikation vergleichbar. Der Hauptnachteil liegt im Daten-Overhead: 116 KB pro Slot gegenüber 96 Bytes im BLS-System.
Übersicht der wichtigsten Operationen
- PRF-Evaluation (nur): ca. 3,71 µs (2 ×
σ). - Vollständige WHIR-Beweis-Erzeugung: 81,4 ms.
- WHIR-Beweis-Verifikation: 19,2 ms.
Vergleich mit EIP-8321 (Hash-Chain RANDAO)
Parallel zur PQ-VRF wurde EIP-8321 von Benedikt Wagner vorgeschlagen. Dieser Ansatz verwendet eine minimalistische Hash-Kette mit nur 32 Bytes Overhead pro Slot. Die beiden Konzepte unterscheiden sich grundlegend im Anwendungsbereich:
- Ressourcenschonung: EIP-8321 ist mit 32 Bytes extrem leichtgewichtig.
- SSLE-Kompatibilität: Die Hash-Kette erfordert zusätzliche Set-Membership-Beweise, um die Proposer-Identität zu verbergen. Die PQ-VRF unterstützt SSLE nativ, da jeder VRF-Output per Input evaluierbar ist.
- Bandbreiten-Impact: Die PQ-VRF erzeugt pro Slot einen 116 KB-Beweis, was die Netzwerkauslastung signifikant erhöht.
Die Wahl zwischen beiden Varianten hängt stark davon ab, wie stark die Ethereum-Community die native Unterstützung von SSLE priorisiert.
Sicherheitsanalyse und offene Fragen
Die Sicherheitsargumentation umfasst vier Kernkomponenten:
- Korrektheit: Unconditional, aus WHIR-Vollständigkeit.
- Computational Uniqueness (ROM): Reduziert auf Kollisionsresistenz von Poseidon1.
- Pseudorandomness (QROM): Basierend auf Zhandry’s QPRF-Theorem (FOCS 2012). Gibt etwa 124 Bit Sicherheit.
- Proof Soundness (ROM): Fiat-Shamir-Transformation für WHIR im ROM.
Offene Risiken:
- Erhöhter Bandbreiten-Overhead von 116 KB pro Slot kann die Block-Budget-Grenzen belasten.
- Eine theoretische Beweislücke für WHIR + Fiat-Shamir im Quantum Random Oracle Model (QROM) bleibt ungeklärt.
Beide Punkte werden als Hauptthemen für das begleitende Papier und die Community-Diskussion genannt.
Häufig gestellte Fragen (FAQ)
Warum funktioniert EIP-7998 nach dem Übergang zu Meilenstein L nicht mehr?EIP-7998 basiert auf BLS12-381-Signaturen. Bei L werden BLS-Schlüssel vollständig durch hashbasierte leanSig-Schlüssel ersetzt, sodass keine BLS-Schlüssel mehr für randaoreveal zur Verfügung stehen.Warum wird das PQ-VRF-Schema bereits ab Meilenstein I und nicht erst ab L aktiviert?On-chain registrierte BLS-Schlüssel können von Quantencomputern mittels Shor-Algorithmus gebrochen werden. Durch die hybride XOR-Kombination von BLS und PQ-VRF ab I wird RANDAO bereits in der Übergangsphase quantensicher.Was unterscheidet diesen Vorschlag vom alternativen EIP-8321?EIP-8321 (Hash-Chain RANDAO) ist mit 32 Bytes extrem leichtgewichtig, offenbart aber die Proposer-Identität. Die WHIR-basierte PQ-VRF ermöglicht dagegen die direkte Evaluierung pro Input und unterstützt damit Single Secret Leader Election (SSLE).
Fazit
Die vorgestellte post-quantensichere VRF-Konstruktion bietet eine notwendige Migration vom BLS-basierten RANDAO zu einem System, das bereits ab Meilenstein I gegen Quantenangriffe resistent ist. Durch die deterministische Ableitung des VRF-Schlüssels aus dem leanSig-Seed entfällt eine zusätzliche Registrierungszeremonie, und die WHIR-Beweise lassen sich ohne neue Precompiles in die bestehende leanVM integrieren. Der Hauptnachteil liegt im erhöhten Daten-Overhead von 116 KB pro Slot und einer noch offenen QROM-Soundness-Analyse. Im Vergleich zu EIP-8321 bietet die PQ-VRF jedoch native SSLE-Unterstützung, was für Anwendungsfälle, die eine verdeckte Proposer-Auswahl erfordern, entscheidend sein kann. Die endgültige Entscheidung wird davon abhängen, wie stark die Ethereum-Community den Schutz vor quanten-basierten Angriffen gegenüber Ressourcen-Effizienz priorisiert.