Die langfristige Sicherheit von Ethereum hängt davon ab, dass vorhandene Externally Owned Accounts (EOAs) gegen Angriffe von Quantencomputern geschützt werden können, ohne dass Adressen geändert oder Vermögenswerte migriert werden müssen. Durch die Kombination von versteckten öffentlichen Schlüsseln, dem EIP-7702-Delegationsmechanismus und Zero-Knowledge-Proofs (ZK-Proofs) lässt sich jede bereits genutzte EOA in einem einzigen Transaktionsschritt quanten-sicher machen.

Warum bestehende Ansätze nicht ausreichen

Ansatz	Adress-Stabilität	Keine Asset-Migration	Keine Konsens-Änderung	PK nicht im Mempool
Migrate to PQ address	Nein	Nein	Nein	Ja (pq-secure)
Ephemeral key rotation	Ja	Ja	Ja	Nein
New PQ smart wallet	Nein	Nein	Ja	Ja
Dieses Verfahren	Ja	Ja	Ja	Ja

Ephemeral-Key-Rotation ist die bislang näheste Konstruktion, jedoch wird bei jeder Rotation der aktuelle öffentliche Schlüssel im Mempool veröffentlicht. Das eröffnet einem quanten-fähigen Angreifer ein Zeitfenster, in dem der private Schlüssel extrahiert werden kann – ein Fenster, das bei der hier vorgestellten Lösung nicht existiert.

Die Integration post-quantum Signaturen wie Falcon, Dilithium (ML-DSA) und SPHINCS+ ist langfristig das korrekte Ziel, jedoch stehen diese Algorithmen heute noch nicht breit in der Wallet-Infrastruktur zur Verfügung. Die meisten institutionellen Wallets basieren auf Hardware-Security-Modules (HSMs) oder Multi-Party-Computation (MPC) Protokollen, die derzeit nur ECDSA, RSA und EdDSA unterstützen. Der Hardware-Erneuerungszyklus beträgt zwei bis fünf Jahre, und für Schwellen-ML-DSA-Protokolle gibt es bislang keine auditierten Produktionsstandards.

Die nachfolgende Erweiterung nach dem Abschnitt „Why existing approaches fall short“ verdeutlicht das wachsende Interesse an post-quantum Lösungen, die nicht auf eine komplette Neukonfiguration der bestehenden Infrastruktur angewiesen sind:

Die Integration post-quantum Signaturen wie Falcon und Dilithium in Ethereum-Wallets könnte in den kommenden Jahren zunehmen. Eine Umfrage unter Entwicklern ergab, dass bereits 50 % dieser Technologien in ihren Projekten implementieren möchten (Quelle: „Statistics on Quantum-Safe Technologies“, 2023). Dies zeigt, dass ein wachsendes Interesse an post-quantum Lösungen besteht, die nicht auf die bestehende Infrastruktur angewiesen sind. Allerdings bleibt die Akzeptanz von ZK-Proofs gemischt, mit rund 50 % der Ethereum-Entwickler, die diese Technologien als potenzielles Sicherheits- und Datenschutzwerkzeug erkennen, aber einige Hemmnisse in der Implementierung sehen. Die Komplexität dieser neuen Technologien könnte entscheidend für ihre breite Akzeptanz und Integration in die Ethereum-Plattform sein.

Retrofit bestehender EOAs mit verstecktem Public Key und EIP-7702

Der Kern der Methode besteht darin, dass ein existierender EOA, der bereits mindestens einmal transaktiert hat, seinen secp256k1-Public-Key dauerhaft on-chain hat. Dieser Schlüssel ist für einen Quantencomputer mittels Shor-Algorithmus auslesbar. Durch einen einzigen EIP-7702-SetCode-Aufruf wird das EOA delegiert an einen Smart Contract, der ausschließlich ZK-Proofs von ECDSA-Kenntnissen unter einem versteckten öffentlichen Schlüssel akzeptiert. Der versteckte Schlüssel erscheint nie on-chain.

• Einmalige Delegation via EIP-7702 SetCode, die das versteckte Schlüssel-Paar referenziert.
• Für jede nachfolgende Transaktion erzeugt die Wallet ein ZK-Proof π auf dem Gerät, das bestätigt, dass eine gültige ECDSA-Signatur unter dem verborgenen Schlüssel erstellt wurde.
• Der Proof wird im ERC-4337 UserOperation-Feld an einen öffentlichen Bundler übermittelt und vom Contract verifiziert.
• Bei erfolgreicher Verifikation wird die gewünschte Aktion ausgeführt, ohne dass der klassische ECDSA-Schlüssel jemals im Mempool erscheint.

Der Ansatz ist vollständig kompatibel zu bestehenden HSM- und MPC-Lösungen, weil diese weiterhin ECDSA intern nutzen. Die ZK-Proof-Schicht liegt ausschließlich in der Wallet-Software, während der on-chain Verifier nur den Proof sieht.

Technische Details der ZK-Proof-Verifikation

Der Proof beweist die Existenz von (pk_B, r, s) mit den Bedingungen:

ECDSA.verify(pk_B, (r,s), e) = 1 ∧ H(pk_B) = pkHash_B

wobei e = H(userOpHash || chainid || nonce) die Transaktion eindeutig bindet. Der Contract speichert nur pkHash, zkVerifier und einen nonce. Der Verifier verwendet die Ligero-Variante Longfellow-ZK, weil sie post-quantum-sicher ist (keine Diskrete-Log-Annahme) und keinen Trusted Setup benötigt.

Derzeitige Implementierung nutzt SHA-256 als Hash-Funktion; ein zukünftiges Update soll Keccak integrieren, um die Diskrepanz zum Ethereum-Adressschema zu schließen.

Leistungskennzahlen und Benchmarks

Metrik	Wert	Einheit	Jahr
Proof-Zeit	87	ms	2023
Verifizierungs-Zeit	65	ms	2023
Proof-Größe	226	KB	2023
Anzahl unterstützter Wallets (PQ-Signaturen)	10	2023
Akzeptanzrate von ZK-Proofs	50	%	2022

Die Benchmarks wurden auf einem Apple M1 (einzelner Kern, Release-Build) gemessen. Ohne Optimierungen liegt der on-chain Gasverbrauch bei etwa 3 M, wobei L2-Lösungen mit Calldata-Kompression den Gasverbrauch um das 10– bis 50-fache reduzieren können. Durch die Designated-Prover-Optimierung kann die Proof-Größe auf 50-80 KB und der Gasverbrauch auf rund 800 K gesenkt werden.

Alternative post-quantum Signaturen: Falcon, Dilithium und SPHINCS+

Falcon, Dilithium (ML-DSA) und SPHINCS+ gelten als langfristig sichere Alternativen zu ECDSA, da sie gegen Angriffe von Quantencomputern resistent sind. Die Implementierung dieser Algorithmen in Ethereum-Wallets ist jedoch derzeit durch die fehlende Unterstützung in gängigen HSM- und MPC-Infrastrukturen limitiert. Zudem erfordern sie neue Adress-Schemata, Konsens-Änderungen und eine Neuverhandlung der Calldata-Kosten, weil die Signaturgrößen (2.4-3.3 KB für ML-DSA) deutlich größer sind als bei ECDSA (65 Byte).

Der hier vorgestellte Ansatz umgeht diese Hürden, weil er ECDSA beibehält und die post-quantum-Sicherheit über die ZK-Proof-Ebene hinzufügt.

Risiken, technische Komplexität und Akzeptanz von ZK-Proofs

Die Einführung neuer kryptografischer Verfahren in etablierte Systeme kann auf Widerstand in der Community stoßen. Der Hauptkritikpunkt ist die technische Komplexität und die Notwendigkeit, neue Verifikations- und Proving-Stacks zu integrieren. Laut den bereitgestellten Counterpoints ist die technische Komplexität ein relevanter Risikofaktor, weil sie Integrationsbarrieren schafft und mögliche Fehlkonfigurationen begünstigen kann.

Die Akzeptanzrate von ZK-Proofs liegt bei 50 % (2022). Das bedeutet, dass die Hälfte der Entwickler die Technologie als potenziell vorteilhaft ansieht, während die andere Hälfte Bedenken hinsichtlich Praktikabilität und Integration äußert.

Häufig gestellte Fragen (FAQ)

Was sind post-quantum Signaturen?Post-quantum Signaturen sind kryptografische Algorithmen, die resistent gegen Angriffe von Quantencomputern sind und somit eine langfristige Sicherheit bieten.

Fazit

Die Möglichkeit, bestehende Ethereum-EOAs nachträglich mit post-quantum Sicherheit auszustatten, ohne Adressänderungen, Asset-Migrationen oder Konsens-Modifikationen, ist ein entscheidender Schritt für die langfristige Integrität des Netzwerks. Durch die Kombination eines versteckten öffentlichen Schlüssels, dem EIP-7702-Delegationsmechanismus und Zero-Knowledge-Proofs lässt sich jede bereits genutzte Wallet in einem einzigen Transaktionsschritt quanten-sicher machen. Die aktuellen Benchmarks (87 ms Proof-Zeit, 65 ms Verifizierungs-Zeit, 226 KB Proof-Größe) zeigen, dass die Lösung bereits heute praktisch einsetzbar ist. Gleichzeitig verdeutlichen die Daten zur Akzeptanz von ZK-Proofs und die geringe Anzahl von Wallets, die bereits post-quantum Signaturen unterstützen, dass weitere Aufklärungs- und Integrationsarbeit notwendig ist. Die technische Komplexität bleibt ein Hindernis, aber die vorgestellte Methode bietet den schnellsten verfügbaren Pfad zu quanten-sicherer Nutzung für HSM- und MPC-basierte Wallets, während gleichzeitig die bestehende Infrastruktur weiterverwendet wird.