ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities) stellt einen Paradigmenwechsel in der Post-Quantum-Migration von Blockchains dar. Statt die herkömmliche Praxis zu verfolgen, post-quantum-sichere Signaturen zu verifizieren – ein Prozess, der laut Analyse mehrere Millionen R1CS-Constraints erfordert – ersetzt ZK-ACE die Signatur durch einen identitätszentrierten Zero-Knowledge-Beweis. Das Ergebnis ist ein äußerst effizientes Autorisierungsverfahren, das sowohl die Datenlast als auch die Verifizierungszeit drastisch reduziert.

Motivation – die PQC-Datenwand

Die Migration zu post-quantum-sicheren Signaturen erhöht die pro-Transaktion zu speichernde Autorisierungs-Datenmenge erheblich. Die gängigen Schemes zeigen dabei folgende Werte (Quelle: INFO 2):

• ML-DSA-44 (Level 2): 3 732 B pro Transaktion
• ML-DSA-65 (Level 3): 5 261 B pro Transaktion
• ML-DSA-87 (Level 5): 7 219 B pro Transaktion
• SLH-DSA-128f: 17 120 B pro Transaktion
• FN-DSA-512: 1 563 B pro Transaktion
• Ed25519 (klassisch): 96 B pro Transaktion

Diese Steigerungen von 30- bis 60-fach im Vergleich zu klassischen Signaturen stellen ein erstes-Ordnung-Skalierbarkeitsproblem dar, insbesondere für Rollup-Architekturen, bei denen die Calldata-Kosten direkt mit der Datenmenge korrelieren.

Kernidee – Autorisierung ohne Signaturen

ZK-ACE erkennt, dass Blockchains auf der Konsens-Ebene lediglich die Autorisierung einer Transaktion prüfen müssen, nicht jedoch das Vorhandensein eines bestimmten Signatur-Objekts. Die Lösung besteht darin, anstelle einer Signatur ein kompaktes Identitäts-Commitment (32 Byte) zu speichern und einen Zero-Knowledge-Beweis zu liefern, der folgende Bedingungen erfüllt:

• (C1) Commitment-Konsistenz – Der Prover kennt das Pre-Image des Identity-Commitments.
• (C2) Ableitungs-Korrektheit – Der Ziel-Binding-Hash entspricht einer deterministischen Schlüsselableitung aus dem Identity-Root.
• (C3) Autorisierungs-Binding – Der Identity-Root hat die konkrete TxHash autorisiert.
• (C4) Anti-Replay – Nonce-Commitment oder Nullifier ist korrekt abgeleitet.
• (C5) Domain-Separation – Alle Bindungen nutzen den deklarierten Chain/Domain-Tag.

Die gesamte Schaltung besteht aus fünf Poseidon-Hash-Aufrufen und Gleichheits-Constraints, ohne jegliche Gitter-Arithmetik oder nicht-native Feld-Emulation.

Effizienz- und Leistungsdaten

Reduzierte R1CS-Constraints

Der Referenz-ZK-ACE-Zirkel benötigt lediglich 4 024 R1CS-Constraints (INFO 1). Im Vergleich dazu benötigen In-Circuit-Verifikationen von ML-DSA-44 mindestens 2 Millionen Constraints – ein Faktor von rund 500.

On-Chain Datenlast

Durch die Eliminierung von Signaturen sinkt die pro-Transaktion gespeicherte Datenmenge auf etwa 288 Byte (INFO 1). Das entspricht einer 32-fachen Kompression gegenüber ML-DSA-65 und einer Reduktion von über 90 % gegenüber den traditionellen PQC-Signaturen.

Beweis- und Verifizierungszeiten

Benchmark-Ergebnisse (Apple M3 Pro, single-threaded) zeigen:

• Beweisgenerierung: median 52 ms pro Transaktion (INFO 1)
• Verifizierung: 604 µs pro Transaktion (INFO 1)

Diese Zeiten ermöglichen den praktischen Einsatz in realen Blockchain-Szenarien, da sie im Millisekunden-Bereich liegen.

Vergleich mit traditionellen PQC-Signaturen

Die folgende Gegenüberstellung verdeutlicht die Einsparungen:

• ML-DSA-44: 3 732 B → 288 B (13-fach)
• ML-DSA-65: 5 261 B → 288 B (18-fach)
• ML-DSA-87: 7 219 B → 288 B (25-fach)
• SLH-DSA-128f: 17 120 B → 288 B (59-fach)

Pluggable-Dual-Backend-Architektur

ZK-ACE unterstützt sowohl klassische zk-SNARKs (Groth16) als auch post-quantum-sichere STARKs. Die beiden Backends unterscheiden sich in Feldgröße, Hash-Primitiven und Leistungskennzahlen.

STARK-Backend (Circle STARK)

• Feld: Mersenne-31 (31-Bit)
• Hash: Poseidon2 (Breite = 16)
• Constraint-Anzahl: ~240 AIR
• Beweiszeit: 21 ms
• Verifizierungszeit: 1.1 ms
• Proof-Size: ~105 KB (transparent, keine vertrauenswürdige Einrichtung)
• Post-Quantum-Sicherheit: Ja

Groth16-Backend

• Feld: BN254 (254-Bit)
• Hash: Poseidon (Breite = 3)
• Constraint-Anzahl: ~1 200 R1CS (Produktions-Circuit)
• Beweiszeit: 44 ms
• Verifizierungszeit: 1.5 ms
• Proof-Size: 128 B (kleinster Proof, schnellste Verifikation)
• Vertrauenswürdige Einrichtung erforderlich

Beide Backends sind proof-system-agnostisch; die Kern-Autorisation-Logik (C1-C5) bleibt unverändert und kann ohne Identity-Rotation zwischen den Systemen wechseln.

Anwendungsfälle und Deployment

• ERC-4337 Validator-Modul – ZK-ACE lässt sich als Account-Abstraction-Validator einsetzen, ohne Änderungen am bestehenden Protokoll.
• Rollup-Architekturen – Die stark komprimierte On-Chain-Datenlast (288 B bzw. 160 B bei aggregierten STARK-Proofs) senkt die Kosten für Calldata/Blob-Space erheblich.
• Post-Quantum-L1-Designs – Kombination aus klassischen Ed25519- und ML-DSA-44-Schlüsseln, wobei ZK-ACE die Autorisierung komplett aus dem kritischen Pfad entfernt.
• Durchsatz-Steigerungen – Erste Implementierungen erreichen 570+ TPS auf Commodity-Hardware (MacBook Pro M3), ohne Performance-Einbußen gegenüber klassischen Signaturen.

Risiken und Gegenargumente

• Verfügbarkeit und Kompatibilität von STARKs – STARK-Technologie ist noch relativ neu; ihre breite Akzeptanz in der Blockchain-Community ist ungewiss (INFO 1).
• Proof-Size bei STARKs – Einzelne STARK-Proofs (~105 KB) sind größer als SNARK-Proofs, jedoch wird durch Aggregation die On-Chain-Datenlast auf etwa 160 B reduziert.

Häufig gestellte Fragen

Was ist ZK-ACE?

ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities) ist ein System zur Autorisierung von Transaktionen in Blockchains, das Signaturen durch identitätszentrierte Zero-Knowledge-Beweise ersetzt.

Wie wird ZK-ACE implementiert?

ZK-ACE kann als ERC-4337 Validator-Modul eingesetzt werden und erfordert keine Änderungen am bestehenden Protokoll.

Fazit

ZK-ACE liefert eine überzeugende Antwort auf die Skalierungsprobleme, die mit der Einführung post-quantum-sicherer Signaturen einhergehen. Durch die Eliminierung von Signatur-Objekten, die drastische Reduktion von R1CS-Constraints auf nur wenige Tausend, die Kompression der On-Chain-Datenlast auf unter 300 Byte und die schnellen Beweis-/Verifizierungszeiten wird ein praktisch einsetzbarer, post-quantum-sicherer Autorisierungsmechanismus bereitgestellt. Die pluggable-Dual-Backend-Architektur ermöglicht Flexibilität zwischen klassischer SNARK- und moderner STARK-Technologie, wobei beide Ansätze die Kern-Vorteile von ZK-ACE bewahren. Trotz offener Fragen zur breiten Akzeptanz von STARKs bietet ZK-ACE bereits heute eine skalierbare Alternative, die insbesondere für Rollup- und Account-Abstraction-Szenarien erhebliche Kosteneinsparungen und Performance-Gewinne verspricht.