HTTP-402-Zahlungen (x402) ermöglichen es KI-Agenten, Ressourcen-Server-Aufrufe zu bezahlen. Bisher war jedoch kein kryptografischer Mechanismus vorhanden, der die Zahlung an die nachweisliche Korrektheit der Inferenz bindet. Dadurch konnten Anbieter Zahlungen annehmen und entweder keine Antwort liefern oder falsche Resultate zurückgeben – ein klassisches Fair-Exchange-Problem. Durch die Kombination von Zero-Knowledge-Proof-gated Escrows und der Validation Registry von ERC-8004 wird ein atomarer, vertrauensloser Settlement-Mechanismus geschaffen, der Zahlung und korrekte Modell-Ausführung in einer einzigen Transaktion verknüpft.

Das Fair-Exchange-Problem bei x402-Zahlungen

• Das Fair-Exchange-Problem verlangt kryptografische Escrow-Bindungen, wenn kein vertrauenswürdiger Dritter existiert (Pagnia & Gärtner, 1999).
• x402-Facilitatoren fungieren bislang als vertrauensbehaftete Intermediäre, was systemische Risiken mit sich bringt.
• Ohne Bindung kann ein Anbieter die Zahlung erhalten, aber die erwartete Inferenz nicht liefern oder ein falsches Ergebnis zurückgeben.
• Reputation allein reicht nicht aus, da Angriffe wie Free-Shopping, Asset-Diebstahl und Gas-Abuse nachweislich vorkommen (Studie, 2026).

Zero-Knowledge-Escrow als Lösung

Der Kernmechanismus besteht aus einem proof-gated Escrow, das als x402-Zahlungsschema registriert wird. Der Ablauf ist:

1. Der Client sendet eine Anfrage inkl. eines Salts und einem Verweis auf das gewünschte Modell-Circuit (Verifying-Key-Hash).
2. Der Client signiert eine EIP-3009-Zahlungsautorisierung, deren Nonce aus allen Anfragenparametern abgeleitet wird – das verhindert Manipulation durch Relayer.
3. Der Provider berechnet das Ergebnis und liefert es sofort über HTTP (optimistische Auslieferung < 1 s).
4. Parallel erzeugt der Provider einen Zero-Knowledge-Beweis (EZKL/Halo2), dass das pinned Circuit exakt den gelieferten Output auf dem committed Input erzeugt.
5. Ein einziger On-Chain-Call verifiziert den Beweis, gibt die Zahlung frei und veröffentlicht das Ergebnis im Calldata.
6. Fehlt ein gültiger Beweis bis zum festgelegten Deadline, kann der Client die Mittel permissionlos zurückfordern.

Damit wird der Facilitator vom vertrauenswürdigen Settlement-Executor zum optionalen, unprivilegierten Relayer degradiert.

Messwerte aus Base Sepolia

• Solo-Settlement (kleiner Circuit, K5): ca. 970 000 Gas (Quelle S1).
• Channel-Funding + K=8 Batch-Verification reduziert den Gasverbrauch um 84 % gegenüber Solo-Settlement (Quelle S1).
• Latenz für die Generierung des Verifier-Bytecodes aus vk.key: 0,28 s (Quelle S1).
• Proof-Generierung für MnistMLP (K=8) dauert 2-22 s, abhängig von Modellgröße (Quelle S1).
• L1-Datenverfügbarkeitsgebühren machen aktuell 3-4 % der Gesamtkosten aus, können jedoch bei Gas-Spikes dominant werden (Quelle S1).

Integration in den ERC-8004 Standard

ERC-8004 definiert ein dreistufiges Framework für autonome AI-Agenten:

• Identity Registry – ERC-721-basiert, verwaltet eindeutige Agenten-Identitäten.
• Reputation Registry – speichert Reputation, bleibt jedoch anfällig für Sybil-Angriffe.
• Validation Registry – ermöglicht die formale Verifikation von zustandslosen oder kryptografischen Aufgaben, einschließlich zkML-Beweisen und TEE-Attestierungen.

Der Zero-Knowledge-Inference-Escrow wird exakt in die Validation Registry eingebettet. Der Verifying-Key-Hash (keccak256(vk.key)) dient als eindeutiger Fingerabdruck des Circuit und wird im Registry-Eintrag gespeichert. Damit entsteht ein unveränderlicher Nachweis, dass ein bestimmtes Modell-Circuit korrekt ausgeführt wurde, ohne Reputations-Sybil-Lücken zu öffnen.

Der Standard-Status von ERC-8004 ist „Draft Track“ (2025) und wurde von De Rossi, Crapis, Ellis und Reppel initiiert (Quelle S2). Die modulare Trust-Tier-Architektur unterstützt die Einführung von Trust-less Agents, wobei die Validation Registry die zentrale Schicht für kryptografische Bindungen bildet.

Empirische Risiken zentralisierter x402-Facilitatoren

• Analyse von 15 Facilitatoren (Base/Solana) über 119 Millionen Transaktionen (2026) zeigt 100 % Sicherheitsverstöße in den untersuchten Fällen (Quelle S5).
• Fehlerhafte Zahlungsüberprüfungen führen zu Free-Shopping, Asset-Diebstahl und Gas-Abuse.
• Die Studie betont die Dringlichkeit, dass Facilitatoren das Settlement nicht eigenständig autorisieren dürfen.

Technische Grenzen von Halo2/EZKL bei großen Modellen

Halo2/EZKL nutzt eine Plonk-artige Arithmetisierung und Lookup-Tabellen. Die Constraint-Anzahl skaliert linear mit der Modellgröße (O(n)).

• MLPs und Decision Trees sind in Sekunden beweisbar.
• Transformer-Architekturen benötigen Milliarden Constraints und mehrere Gigabyte Prover-RAM, wodurch nur Sub-100 M-Parameter-Modelle praktikabel sind.
• Messung der Prover-Zeit für MnistMLP liegt bei 2-22 s (2026, K=8/K=5 Testnet-Setups).

Damit ist klar, dass die aktuelle Technik praxistaugliche Klassifikationsmodelle unterstützt, jedoch nicht die frontier LLMs.

Gegenmaßnahmen und Optimierungsansätze

• State-Channels – bieten den stärksten Skalierungshebel, weil State-Writes und EIP-3009-Transfers die Hauptkostenposition darstellen.
• Batch-Verification – kombiniert mehrere Proofs in einem Transaction-Batch, reduziert Gas um bis zu 84 % (siehe Channel-Funding-Ergebnis).
• Off-Chain-Pufferung – Optimistische Rückgabe an den Client (< 1 s) während das Settlement bis zur Batch-Schließung wartet; Timeout-Challenge sichert den Client bei Provider-Abbruch.
• L1-Datenverfügbarkeit – Modellieren von Blob-Space-Engpässen und Gas-Spikes, um unvorhersehbare Gebühren zu vermeiden.
• Verbesserte VK-zu-Model-Binding – Aktuell wird ein unabhängiges Attestations-Pattern genutzt; zukünftige Forschung könnte ein kryptografisch stärkeres Primitive schaffen, das die Modell-Identität ohne externe Attester beweist.

Häufig gestellte Fragen (FAQs)

Warum genügt keine einfache Server-Signatur über das Inferenz-Ergebnis?Eine Signatur belegt lediglich die Urheberschaft der Nachricht, liefert aber keinen Nachweis, dass das Ergebnis tatsächlich durch das spezifizierte Modell auf den bereitgestellten Eingabedaten berechnet wurde.Was unterscheidet die Verifikation der Verifying-Key-Hash von der Bytecode-Hash?Die Bytecode-Hash kann jeder Client direkt aus dem Smart Contract (eth_getCode) ableiten. Die Verifying-Key-Hash (keccak256(vk.key)) verknüpft das Kompilat mit den Modelldateien und erfordert zur vollständigen Rekonstruktion Zugriff auf Gewichte und Trainingsartefakte.

Fazit

Die kryptografisch atomare Kopplung von HTTP-402-Zahlungen an verifizierte Modellausführung löst das fundamentale Fair-Exchange-Problem bei autonomen KI-Agenten. Durch die Integration eines Zero-Knowledge-Inference-Escrows in die Validation Registry von ERC-8004 wird ein trustless Settlement-Mechanismus geschaffen, der Zahlung und korrekte Inferenz in einer einzigen Transaktion verknüpft. Empirische Analysen zeigen, dass zentrale x402-Facilitatoren erhebliche Sicherheitsrisiken bergen, während State-Channels und Batch-Verification signifikante Gas-Einsparungen ermöglichen. Technische Grenzen von Halo2/EZKL begrenzen derzeit den Einsatz auf Modelle mit weniger als 100 M Parametern, doch die Architektur bleibt zukunftssicher, da schnellere Prover-Techniken und verbesserte VK-Binding-Primitives die Anwendbarkeit erweitern werden. Insgesamt stärkt das Design die Sicherheit, Skalierbarkeit und Vertrauenslosigkeit von KI-Agenten-Ökosystemen im Ethereum-Umfeld.