zx402 testet private Finanzierung für KI Agenten auf Cardano

zx402 hat zwei Servicekäufe auf Cardano Preprod dokumentiert, die einen Pool verwenden, der darauf ausgelegt ist, die Ausgaben eines KI Agenten von seinem ursprünglichen Wallet zu trennen. Die Tests vom 7. Oktober befassen sich mit einem Datenschutzproblem im automatisierten Handel: Öffentliche Zahlungshistorien können die Lieferanten eines Agenten, die Kaufhäufigkeit und das Betriebsbudget offenlegen.

Zwei Käufe über x402 und Masumi

Die erste Demonstration bezahlte einen Wetterdienst über x402, das HTTP 402 zur Zahlungsanforderung verwendet. Die Antwort kostete 2 tUSDM, dazu kam eine separate Gebühr für den Relayer, der die Pool Transaktion einreichte.

Mit zuvor eingezahlten Mitteln finanzierte der Pool eine frische Einmaladresse, die eine Standard x402 Zahlung abschloss. Der Dienst lieferte eine Wetterantwort zurück, während der verbleibende Saldo im Pool für einen weiteren Kauf verblieb.

Der zweite Test zahlte dem Masumi Agent „Expose: Web Single Answer“ 0.01 tUSDM, um einen Zero Knowledge Beweis in einem Satz zu erklären. Hier finanzierte der Pool das Einkaufs Wallet eines Masumi Zahlungsnodes. Die Mittel gingen anschließend in die Masumi Treuhand, und das veröffentlichte Log verzeichnete die Aufgabe als abgeschlossen.

Die Unterscheidung ist für den Zahlungsablauf wichtig: Der x402 Test nutzte eine Einmaladresse, während der Masumi Test ein bestehendes Einkaufs Wallet finanzierte. Das Team veröffentlichte Terminal Logs und Transaktionslinks für beide Durchläufe, die Testtokens und keine Mainnet Mittel verwendeten.

So funktioniert der Cardano Privacy Pool

Ein Agent zahlt Mittel öffentlich ein und behält eine private Notiz, die seinen Anspruch darauf dokumentiert. Sobald die Einzahlung genehmigt ist, erzeugt der Agent lokal einen Zero Knowledge Beweis, der den Besitz genehmigter, ungenutzter Mittel nachweist, ohne die Einzahlung hinter dem Kauf zu identifizieren.

Ein Relayer übermittelt den Beweis und die Transaktion. Im Standard x402 Ablauf finanziert der Pool eine neue Einmaladresse, bevor die Zahlung den Verkäufer erreicht. Laut Dokumentation können Verkäufer diese Zahlungen akzeptieren, ohne zx402 spezifischen Code zu integrieren. Nicht ausgegebene Mittel werden zu einer neuen privaten Notiz, die für spätere Käufe verfügbar ist.

Die Privatsphäre hat definierte Grenzen. Beträge, Zeitpunkte und ausgehende Pool Zahlungen bleiben sichtbar. Ein kleiner Pool oder übereinstimmende Beträge können Transaktionen leichter korrelierbar machen, während das öffentliche Abheben des verbleibenden Saldos Verbindungen zu früheren Käufen offenlegen kann.

Der Blockchain Infrastrukturanbieter des Agenten kann ebenfalls seine Adressen und Anfragen beobachten. Das Design zielt daher auf die öffentliche Verbindung zwischen Finanzierung und Ausgaben ab, wobei zusätzliche Privatsphäre davon abhängt, wie der Agent auf das Netzwerk zugreift.

Was vor dem Mainnet noch aussteht

Der Quellcode, das SDK und Testanleitungen stehen Entwicklern zur Verfügung. Die öffentliche Website bietet Dokumentation, verbindet jedoch keine Wallets und führt keine Transaktionen aus.

Die Einzahlungsfreigabe ist implementiert, externe Screenings jedoch nicht. Der aktuelle Dienst genehmigt Einzahlungen, sofern nicht eine konfigurierte Ablehnungsfunktion sie zurückweist; es ist keine Screening Datenquelle angeschlossen.

Auch die Kosten prägen den vorgesehenen Einsatz. Cardano Outputs müssen einen Mindestbetrag an ADA enthalten, daher positioniert das Team den Pool für größere Zahlungen, Treuhand Finanzierung und Zahlungskanäle statt für einzelne Blockchain Transaktionen bei jeder günstigen API Anfrage.

Der Einsatz im Mainnet steht noch aus, und niemand außerhalb des Projekts hat Design oder Code geprüft. Bevor externe Mittel akzeptiert werden, nennt zx402 unter seinen Anforderungen eine Mehrparteien kryptografische Einrichtung und eine externe Sicherheitsprüfung. Außerdem wird ein neuer Pool mit Blockchain Prüfungen benötigt, die den korrekten Anfangszustand erzwingen, anstelle der derzeitigen Abhängigkeit davon, dass der Deployer ihn korrekt initialisiert.