ACE Runtime - A ZKP-Native Blockchain Runtime with Sub-Second Cryptographic Finality

Die Arbeit stellt ACE Runtime vor, eine ZKP-native Blockchain-Laufzeitumgebung, die durch die Trennung von Identität und Autorisierung sowie die Verwendung von HMAC-Attestierungen und aggregierten Zero-Knowledge-Beweisen eine kryptografische Endgültigkeit unter einer Sekunde bei konstanten Verifizierungskosten und geringerem Hardwarebedarf ermöglicht.

Das Wesentliche

Hier ist eine einfache Erklärung des ACE Runtime-Papiers, vorgestellt mit ein paar kreativen Analogien, damit jeder es verstehen kann.

Das große Problem: Der Stau an der Kasse

Stell dir eine sehr schnelle Bank vor (wie Solana), die Tausende von Kunden pro Sekunde bedienen möchte. Das Problem ist jedoch: Jeder Kunde muss an der Kasse einen schweren, komplexen Ausweis (eine kryptografische Signatur) vorzeigen.

• Das aktuelle System: Der Bankangestellte muss jeden einzelnen Ausweis einzeln und sehr sorgfältig prüfen. Je mehr Kunden da sind, desto länger dauert es. Wenn 100.000 Kunden kommen, muss der Angestellte 100.000 Ausweise prüfen. Das kostet viel Zeit und erfordert extrem teure, leistungsstarke Computer (Grafikkarten), damit die Bank nicht zusammenbricht.
• Das Ergebnis: Die Bank wird langsam, wenn sie voll ist, und nur sehr reiche Leute können sich die teuren Computer leisten, um als "Wächter" (Validator) zu arbeiten.

Die Lösung: ACE Runtime – Der "Stempel" statt des Ausweises

ACE Runtime schlägt eine völlig neue Art vor, wie die Bank funktioniert. Sie trennt zwei Dinge, die bisher immer zusammengehört haben: Wer du bist (Identität) und dass du diesen Auftrag jetzt ausführen darfst (Autorisierung).

Stell dir ACE Runtime wie ein super-schnelles Flughafen-System vor:

1. Der neue Pass: Der "HMAC-Stempel" (Attestation)

Anstatt dass jeder Passagier seinen schweren, komplexen Reisepass (die Signatur) vorzeigen muss, bekommt jeder Passagier am Eingang einen einfachen, leichten Stempel auf die Hand.

• Wie es funktioniert: Der Passagier hat einen geheimen Code (seine "Identität"). Daraus wird automatisch ein einfacher Stempel (ein HMAC) berechnet.
• Der Vorteil: Das Prüfen dieses Stempels dauert nur eine winzige Sekunde (Mikrosekunden). Ein gewöhnlicher Computer kann das mühelos schaffen. Kein teurer Spezialcomputer nötig!
• Die Magie: Der Stempel beweist, dass der Passagier berechtigt ist, ohne dass der Angestellte den schweren Reisepass sehen muss.

2. Der "Nachhinein-Beweis" (Zero-Knowledge Proof)

Jetzt kommt der geniale Teil: Die Bank muss nicht warten, bis jeder Stempel einzeln geprüft wurde, bevor sie die Flugzeuge starten lässt.

• Der Prozess:
  1. Sofort: Die Angestellten prüfen nur die Stempel (sehr schnell) und lassen die Kunden durch. Das Flugzeug startet sofort (Block wird veröffentlicht).
  2. Später (im Hintergrund): Ein spezielles Team (die "Beweis-Generatoren") nimmt alle Stempel des Tages und erstellt einen einzigen, winzigen Beweis dafür, dass alle Stempel echt waren.
  3. Das Ergebnis: Dieser eine Beweis wird an die Wächter geschickt. Sie müssen nur einen einzigen Beweis prüfen, egal ob 100 oder 100.000 Kunden durch waren.

Was bringt das alles? (Die Vorteile)

Hier sind die vier großen Gewinne, die das Papier beschreibt:

• Blitzschnelle Sicherheit (Sub-Second Finality):

  • Alt: Bei Solana dauert es etwa 12 Sekunden, bis man sich zu 100 % sicher ist, dass ein Geschäft nicht rückgängig gemacht werden kann (wie ein langsames Warten auf den Brief vom Gericht).
  • Neu (ACE): Es dauert nur 600 Millisekunden (knapp eine halbe Sekunde). Das ist wie ein schneller Händedruck, der sofort als verbindlich gilt.

• Keine teuren Computer mehr für alle:

  • Alt: Jeder Wächter brauchte eine teure Grafikkarte (GPU), um die schweren Ausweise zu prüfen. Das kostete Tausende von Dollar.
  • Neu: Da nur ein einfacher Stempel geprüft werden muss, reicht ein ganz normaler Computer. Das macht die Teilnahme an der Bank viel günstiger und demokratischer.

• Platzsparend (Bandbreite):

  • Alt: Jeder Kunde brachte einen riesigen Rucksack (Signatur + öffentlicher Schlüssel) mit.
  • Neu: Jeder Kunde hat nur einen kleinen Zettel. Am Ende des Tages wird nur ein einziger, winziger Zettel (der Beweis) für die ganze Gruppe benötigt. Das spart enorm viel Platz im Netzwerk.

• Zukunftssicher (Quantencomputer):

  • Die alten Ausweise könnten von zukünftigen Quantencomputern geknackt werden. ACE nutzt eine neue Art von "Stempel" und "Beweis", die auch gegen diese zukünftigen Supercomputer sicher ist, ohne das System umbauen zu müssen.

Zusammenfassung in einem Satz

ACE Runtime verwandelt die Blockchain von einem System, bei dem jeder einzelne Passagier einen schweren Koffer durchleuchten muss, in ein System, bei dem jeder nur einen leichten Stempel bekommt und am Ende des Tages nur ein einziger, winziger Beweis geprüft werden muss – was alles viel schneller, billiger und sicherer macht.

Es ist der Unterschied zwischen dem manuellen Zählen von 10.000 Münzen und dem Drücken eines einzigen Knopfes, der bestätigt: "Ja, das Geld ist echt."

Technische Zusammenfassung

Technische Zusammenfassung: ACE Runtime

1. Problemstellung

Hochleistungs-Blockchains der ersten Generation (Layer-1), wie beispielsweise Solana, stoßen an fundamentale Grenzen, die durch die Architektur ihrer Transaktionsverarbeitung verursacht werden:

• O(N) Signatur-Verifizierung: Bei herkömmlichen Systemen muss jede Transaktion eine kryptografische Signatur (z. B. Ed25519) enthalten, die von jedem Validator verifiziert werden muss. Dies führt zu einer linearen Komplexität ($O(N)$) der Verifizierungskosten pro Block. Bei großen Blockgrößen (z. B. 100.000 Transaktionen) verbraucht die Signaturprüfung (SigVerify) bereits die Hälfte des Blockintervalls (ca. 200 ms), was den Durchsatz begrenzt.
• Hohe Hardware-Anforderungen: Um diesen Bottleneck zu bewältigen, müssen alle Validatoren (nicht nur Blockproduzenten) leistungsstarke GPUs für die Batch-Verifizierung von Signaturen betreiben. Dies erhöht die Einstiegskosten auf ca. 7.500 $ und die Betriebskosten erheblich, was die Dezentralisierung gefährdet.
• Post-Quantum-Schwachstelle: Der Übergang zu quantenresistenten Signaturverfahren (z. B. ML-DSA-44) würde die Datengröße pro Transaktion um das 38-fache erhöhen (von 96 auf ~3.732 Bytes). Dies würde die Blockgrößen und die Bandbreitenanforderungen der aktuellen Architekturen unpraktikabel machen.
• Latenz bei der Finalität: Selbst bei schnellen Blockzeiten (400 ms) dauert die kryptografische „harte Finalität" (unumkehrbare Bestätigung) bei Systemen wie Solana oft mehrere Sekunden bis Minuten (z. B. 12 s), da viele Bestätigungen oder Forks abgewartet werden müssen.

2. Methodik und Architektur

Das Paper stellt ACE Runtime vor, eine Blockchain-Laufzeitumgebung, die auf dem Konzept der Trennung von Identität und Autorisierung (Identity–Authorization Separation) basiert, implementiert durch das ACE-GF-Framework.

Kernarchitektur: Attest–Execute–Prove Pipeline

Die Architektur entkoppelt die kritische Pfad-Verarbeitung von der aufwändigen Beweisgenerierung durch eine dreiphasige Pipeline:

1. Phase 1: Attest & Execute (Kritischer Pfad)

   • Attestation (Berechtigungsprüfung): Anstelle einer vollständigen kryptografischen Signatur pro Transaktion wird ein leichtgewichtiges HMAC-basiertes Attestat verwendet. Dieses wird vom Nutzer aus einem Root Entropy Value (REV) abgeleitet.
   • Verifizierung: Validatoren prüfen nur die Formatintegrität und die Bindung an die On-Chain-Identität (via HKDF und HMAC-SHA256). Dies kostet nur ca. 1–5 µs pro Transaktion auf einer Standard-CPU.
   • Ausführung: Die Transaktionen werden parallel ausgeführt (basierend auf dem Sealevel-Modell von Solana).
   • Block-Publishing: Der Block wird nach ca. 400 ms veröffentlicht und erreicht „weiche Finalität" (Soft Finality) durch BFT-Stimmen.

2. Phase 2: Prove (Asynchron, außerhalb des kritischen Pfads)

   • ZK-Beweisgenerierung: Ein dedizierter „Builder" (mit GPU-Hardware) generiert nach der Blockveröffentlichung einen Zero-Knowledge-Beweis (ZK-Proof).
   • Aggregation: Dieser Beweis bestätigt, dass alle Attestate im Block korrekt von den entsprechenden Identitäten abgeleitet wurden. Die Beweise werden in einem Baumstruktur-Verfahren zu einem einzigen Groth16-Proof pro Block aggregiert.
   • Finalitätszertifikat: Der aggregierte Beweis wird als Finalitätszertifikat (Finality Certificate) veröffentlicht. Validatoren verifizieren diesen einen Beweis in ca. 0,5 ms, was die „harte Finalität" (Hard Finality) bei ca. 600 ms erreicht.

Kryptografische Grundlagen

• ACE-GF (Atomic Cryptographic Entity Generative Framework): Nutzt einen einzigen hohen Entropiewert (REV) zur Ableitung aller Schlüsselströme über HKDF.
• Identitäts-Commitment: Die On-Chain-Identität ist nur ein Poseidon-Hash-Commitment (id_com). Keine öffentlichen Schlüssel werden offengelegt, was Schutz vor „Harvest Now, Decrypt Later"-Angriffen bietet.
• Beweislast: Der Beweis (Groth16 auf BN254) verifiziert die Korrektheit der HMAC-Attestate und die Bindung an die Identität, ohne die Transaktionsdaten preiszugeben.

3. Hauptbeiträge

1. Attest–Execute–Prove Pipeline: Eine neue Ausführungsarchitektur, die die Verifizierung von Berechtigungen von der Signaturprüfung auf leichte HMAC-Prüfungen umstellt und die Beweisgenerierung asynchronisiert.
2. O(1) Block-Verifizierung: Die Verifizierungskosten pro Block sind konstant, unabhängig von der Anzahl der Transaktionen, da nur ein einziger ZK-Proof pro Block geprüft werden muss.
3. Zwei-Ebenen-Finalitätsmodell:
   • Weiche Finalität: ~400 ms (durch BFT-Stimmen).
   • Harte Finalität: ~600 ms (durch Verifizierung des ZK-Proofs).
4. Quantenresistenz und PQC-Vorbereitung: Die Identitätsebene ist von Tag 1 an quantenresistent (Hash-basiert). Der Wechsel zu post-quanten Signaturen (PQC) im ZK-Circuit erhöht die Blockgröße nicht, da der Beweis immer gleich groß bleibt (256 Bytes).
5. GPU-freie Validatoren: Nicht-Building-Validatoren benötigen keine GPUs mehr, da sie nur leichte HMAC-Prüfungen und einen einzelnen ZK-Proof verifizieren.

4. Ergebnisse und quantitative Analyse

Die Autoren liefern analytische Modelle und Messungen auf Basis eines Rust-Prototyps (Apple M3 Pro):

• Durchsatz (TPS):
  • Konservativ geschätzt: ~16.000 TPS.
  • Mit moderatem Engineering (Parallelisierung): ~32.000 TPS.
  • Theoretisches Bandbreiten-Limit: Bis zu 512.000 TPS (durch reduzierte Datenmenge pro Transaktion).
• Finalitäts-Latenz:
  • Reduktion der harten Finalität von 12 s (Solana) auf **600 ms** (ACE Runtime).
  • Geschwindigkeitsteigerung von ca. 20-fach im Vergleich zu Solana.
• Verifizierungskosten:
  • Bei 100.000 Transaktionen pro Block: Solana benötigt ~200 ms (GPU) oder ~7,6 s (CPU) für die Signaturprüfung. ACE Runtime benötigt konstant 0,5 ms.
  • Geschwindigkeitsteigerung bei der Blockverifizierung: Bis zu 4.000-fach im Vergleich zu Solana bei großen Blöcken.
• Hardware-Kosten:
  • Elimination der GPU-Anforderung für Validatoren senkt die Hardwarekosten um 30–50 % (von ~7.500 $auf ~3.500–5.000$).
• Bandbreite:
  • Reduktion der On-Chain-Daten pro Transaktion um ca. 5-fach (von ~1.232 Bytes auf ~244 Bytes), da Signaturen und öffentliche Schlüssel entfernt wurden.

5. Bedeutung und Fazit

ACE Runtime stellt einen paradigmatischen Wandel in der Blockchain-Architektur dar, indem es die Trennung von Identität und Autorisierung als fundamentales Designprinzip nutzt.

• Skalierbarkeit: Durch die Verschiebung der rechenintensiven Beweisgenerierung aus dem kritischen Pfad wird der Durchsatz nicht mehr durch die Signaturprüfung limitiert.
• Dezentralisierung: Die Entfernung der GPU-Pflicht für Validatoren senkt die Eintrittsbarriere und fördert ein dezentraleres Netzwerk.
• Zukunftssicherheit: Das System ist von Grund auf für die Post-Quantum-Ära vorbereitet, ohne Performance-Einbußen bei der Verifizierung.
• Architektonische Innovation: Das Paper zeigt, dass die Kombination aus Identitäts-Abstraktion (ACE-GF) und Zero-Knowledge-Proofs (ZKP) zu einer signifikanten Verbesserung von Finalität, Verifizierungseffizienz und Hardware-Zugänglichkeit führt, die über reine Implementierungsoptimierungen hinausgeht.

Zusammenfassend demonstriert ACE Runtime, dass Sub-Sekunden-Finalität und hohe Skalierbarkeit auf Layer-1-Ebene erreichbar sind, ohne auf zentrale Hardware-Anforderungen oder langsame Finalitätsmechanismen angewiesen zu sein.