Ethereums zkAPI verbirgt, wer für KI bezahlt – das Modell sieht den Prompt trotzdem

Die Ethereum Foundation und das Open Anonymity Project haben zkAPI am 1. Oktober im Ethereum-Mainnet gestartet. Ein Nutzer kann Guthaben einzahlen und nachweisen, dass eine spätere KI-API-Anfrage bezahlt ist, ohne dem Zahlungsserver eine Identität oder dem Modellanbieter die Finanzierungsadresse preiszugeben. Der Anbieter erhält weiterhin den Prompt. Diese Trennung ist nützlich, aber sie ist eine engere Datenschutzaussage als eine anonyme Konversation mit einem Modell.

Die technische Ankündigung der Ethereum Foundation ist ungewöhnlich explizit über die Grenze. Der Proof verbirgt, welcher Note die Nutzung bezahlt, während der Anbieter das Modell betreibt und die Anfrage sieht. Sie benennt auch Netzwerk-Metadaten und Prompt-Inhalt als verbleibende Korrelationsquellen. Das ist wichtig, weil der Ausdruck private KI-Zahlungen leicht als private KI-Nutzung verstanden werden kann.

Das Projekt ist laut der Foundation live, mit einem öffentlichen GitHub-Repository, einem Mainnet-Tresor mit USDC-Guthaben und einer Demonstrations-Chat-Oberfläche, die von ihrer Ankündigung verlinkt ist. Die Live-Bereitstellung belegt, dass es Code und einen Vertrag zur Überprüfung gibt. Sie belegt nicht die Nutzerakzeptanz, den Umfang eines Sicherheitsaudits, Anonymität in jeder Client-Konfiguration oder Schutz gegen einen Anbieter, der die Handschrift und Dokumente eines Nutzers erkennt.

Eine Einzahlung ersetzt eine Spur von API-Rechnungen

Die meisten kommerziellen KI-APIs verbinden einen Schlüssel mit einem Konto und einer Zahlungsmethode. Der Anbieter kann Anfragen einer Abrechnungsidentität zuordnen, selbst wenn ein Nutzer den Prompt nie mit einem Namen signiert. zkAPI führt einen finanzierten Tresor und einen privaten Note ein. Ein Nutzer zahlt unterstützte Vermögenswerte wie USDC in einen Vertrag ein; Software auf dem Gerät des Nutzers erzeugt später einen Zero-Knowledge-Proof, dass ein gültiger finanzierter Note für eine begrenzte Nutzung bezahlen kann, ohne offenzulegen, welcher Note es ist.

Der Zahlungsserver verifiziert den Proof und stellt einen kurzlebigen, dollar-begrenzten API-Schlüssel aus. Im von der Foundation beschriebenen direkten Runtime-Key-Modus gehen Prompts vom Gerät des Nutzers mit diesem Schlüssel an den KI-Anbieter. Nach der Sitzung zeichnet eine signierte Quittung die gemessene Nutzung auf, und das private Guthaben wird für den genutzten Betrag belastet, nicht einfach für die reservierte Obergrenze. Ein Proof kann eine Sitzung mit mehreren Anfragen abdecken.

Dies vermeidet es, jede Modellanfrage auf Ethereum zu legen. Die Chain sieht Tresoreinzahlungen, Schließungen und Abhebungen, während der Server Ausgabenachweise offchain verifiziert. Der Modellanbieter sieht den Text und den API-Datenverkehr. Der Zahlungsserver sieht den Nachweis, dass die Sitzung finanziert ist, und die Gesamtgebühr, erhält im direkten Modus aber nicht den Prompt. Dies sind Behauptungen über die beschriebene Architektur, nicht der Beweis, dass die Logs oder die Netzwerkkonfiguration einer bestimmten Bereitstellung niemals Nutzer korrelieren können.

Es gibt einen einfacheren Proxy-Modus. Darin leitet der zkAPI-Server die Anfrage des Nutzers an den Modellanbieter weiter. Dieser Server kann den Datenverkehr sehen, so die Foundation. Wer zwischen den Modi wählt, sollte fragen, welcher Partei er den Inhalt anvertraut und welche nur einen Zahlungsnachweis validieren muss. Eine lokale Oberfläche, die identisch aussieht, könnte Anfragen unter der Haube anders weiterleiten.

Der Schein beweist den Wert, ohne seinen Einzahler zu nennen

Die kryptografische Konstruktion verwendet Commitments in einem Merkle-Baum. Ein Beweis besagt, dass der Schein des Nutzers zu den gültigen finanzierten Scheinen gehört, ohne sein Blatt zu identifizieren. Ein Nullifier, der aus einem Scheingeheimnis abgeleitet wird, verhindert, dass dasselbe Guthaben zweimal ausgegeben wird. Die Foundation nennt Groth16-Beweise auf BN254 und Poseidon-Hashes mit einem 32-stufigen Baum. Diese Details sind für Implementierer wichtig, doch das finanzielle Prinzip ist einfacher: die Zugehörigkeit und die verbleibende Ausgabebefugnis zu verifizieren, ohne das Konto zu veröffentlichen, das das Guthaben bereitgestellt hat.

Der Nutzer erhält keine kostenlose Nutzung, indem er eine Identität verbirgt. Der Server muss den Ausgabebeweis prüfen und eine Obergrenze reservieren, bevor er den temporären Schlüssel ausgibt. Der Anbieter misst die Nutzung. Die Quittung begleicht den tatsächlichen Betrag nach Ablauf des Schlüssels. Wenn eine Obergrenze von 10 $ reserviert und eine Dienstleistung im Wert von 3 $ verbraucht wird, soll das System 3 $ berechnen, nicht 10 $. Dieses Beispiel veranschaulicht die Reservierungslogik, nicht einen veröffentlichten Preis oder einen garantierten Mindestbetrag. Das verbleibende Guthaben verbleibt im privaten Schein gemäß den Regeln der Implementierung.

Der Nullifier adressiert einen bestimmten Fehler: den Versuch, einen Schein zweimal auszugeben. Er beweist nicht, dass das KI-Modell korrekt geantwortet hat, wahrt nicht die Vertraulichkeit des Prompts und hindert den Anbieter nicht daran, Anfragen aufzuzeichnen. Ein Zero-Knowledge-Beweis ist eine Aussage über die Gültigkeit einer Transaktion unter einer definierten Schaltung. Seine Garantien erstrecken sich nicht automatisch auf andere Daten, die zusammen mit der Transaktion übertragen werden.

Der Ausstiegspfad des Vertrags ist ebenfalls wichtig. Die Foundation sagt, dass ein Nutzer das Vault-Guthaben schließen und onchain abheben kann, selbst wenn zkAPI-Server verschwinden. Dies vermeidet, dass der Zahlungsserver der einzige Weg ist, um Gelder zurückzuerlangen. Es macht Ausstiege nicht unsichtbar: Ethereum zeichnet die relevanten Transaktionen auf. Die Fähigkeit des Nutzers auszusteigen hängt vom Vertrag und dem Besitz des erforderlichen Geheimnisses ab, und ein umsichtiger Nutzer sollte Bereitstellungsadressen, Berechtigungen und jede unabhängige Überprüfung prüfen, bevor er dem Mechanismus einen großen Wert zuweist.

Der Anbieter kann erkennen, was der Beweis nicht offenbaren kann

Der Zahlungsbeweis kann eine Finanzierungsquelle verbergen, während der Anfragetext den Namen einer Person, den Arbeitgeber, die Krankengeschichte oder proprietären Code enthält. Ein Modellanbieter, der den Prompt liest, kann ihn mit früheren Sitzungen verknüpfen, indem er wiederholte Phrasen, hochgeladene Dateien, Gesprächsverlauf oder höchst charakteristische Fakten verwendet. Es ist keine Wallet-Verknüpfung erforderlich. Ein Prompt über ein unveröffentlichtes Produkt mit demselben internen Projektnamen in drei Sitzungen ist sein eigener Identifikator.

Netzwerk-Metadaten bieten einen weiteren Pfad. Im Runtime-Key-Modus kann der Anbieter die IP-Adresse sehen, von der aus sich das Gerät verbindet. Im Proxy-Modus kann der Vermittler den Datenverkehr und möglicherweise seine Ursprungsnetzwerkinformationen sehen. Die Foundation sagt ausdrücklich, dass eine stabile IP und korrelierte Zeitangaben die Privatsphäre schwächen können, und empfiehlt Netzwerkanonymisierungswerkzeuge für Nutzer, die stärkeren Schutz suchen. Ein VPN oder Tor kann den Netzwerkpfad ändern, aber keines von beiden entfernt einen in den Prompt eingegebenen Namen.

Es gibt einen dreischichtigen Privatsphäre-Test. Zahlungsprivatsphäre fragt, ob eine Rechnung an einen Finanzierungsschein oder eine Person gebunden werden kann. Netzwerkprivatsphäre fragt, ob der Dienst eine Verbindung anhand von IP, Zeitangaben oder Geräteeigenschaften identifizieren kann. Inhaltsprivatsphäre fragt, ob jemand, der das Modell betreibt, den Prompt lesen kann. zkAPI ist hauptsächlich für die erste Schicht konzipiert. Es kann eine Verknüpfung auf Kontoebene zwischen dem Nutzungsprotokoll des Modellanbieters und der Zahlungsquelle des Nutzers reduzieren. Es liefert die anderen beiden nicht von sich aus.

Dies ist kein im Kleingedruckten versteckter Defekt. Die eigene Ankündigung des Projekts besagt, dass der Anbieter die Anfragen sieht. Die ehrliche Beschreibung ist stärker als ein weitreichendes Anonymitätsslogan, weil sie den Nutzern sagt, worauf sie zusätzliche Vorsichtsmaßnahmen konzentrieren sollten. Eine Person, die den Dienst nutzt, um allgemeine Fragen zu stellen, kann eine erhebliche Zahlungsunverknüpfbarkeit gewinnen. Eine Person, die einen unterzeichneten Vertrag und einen vollständigen Namen einfügt, hat ihre Identität im Inhalt offengelegt, unabhängig vom Zahlungsweg.

Die Anonymitätsmenge kann selbst bei soliden Beweisen klein sein

Zero Knowledge kann verbergen, welcher von mehreren Scheinen bezahlt hat, aber die praktische Menge ist wichtig. Wenn nur ein Nutzer einen Vault in einem engen Zeitfenster mit einem ungewöhnlichen Einzahlungsbetrag finanziert und eine ebenso charakteristische Abhebung nach einer Sitzung folgt, kann ein Beobachter aus öffentlichen Zeitangaben und Beträgen eine plausible Korrelation bilden. Der Beweis kann kryptografisch gültig und ungebrochen bleiben. Die Inferenz aus externen Informationen ist ein separater Angriff.

Der 32-stufige Baum ist ein Kapazitätsparameter im Design, kein Beweis dafür, dass heute Milliarden verschiedener Nutzer ihre Guthaben mischen. Ein neu gestarteter Dienst kann eine kleine Menge finanzierter Scheine haben. Um die Anonymität in der Praxis zu bewerten, möchte man datierte Zählungen von Einzahlungen, verschiedenen aktiven Scheinen und Abhebungsmustern mit datenschutzbewusster Aggregation. Ein Repository oder eine theoretische Baumgröße liefert diese Zahlen nicht.

Angenommen, zehn Notizen kommen für eine Sitzung infrage und öffentliche Fakten schließen neun davon aus. Der mathematische Beweis kann seinen Zeugen immer noch perfekt verbergen, während die umgebenden Informationen auf die zehnte hinweisen. Dieses Spielzeugbeispiel erklärt, warum die Größe und Vielfalt der plausiblen Menge mehr zählt als die reine Anzahl der Transaktionen im Tresor. Betragsstandardisierung, verzögerte Aktivität und regelmäßige Nutzung können helfen, aber Nutzerverhalten und Servicedesign bestimmen, was zur Korrelation verfügbar ist.

Beim KI-Anbieter gibt es eine zweite Art von Menge: die Gruppe von Anfragen, die sich einen kurzlebigen Schlüssel teilen. Der Schlüssel kann Anfragen innerhalb seiner begrenzten Sitzung verknüpfen, selbst wenn er die Einzahlung nicht identifizieren kann. Das ist der Messung einer Sitzung inhärent. Wenn der Client in späteren Sitzungen wiederholt dieselben Dokumente sendet, kann der Anbieter sie auch über Schlüssel hinweg verknüpfen. Das Verbergen des Abrechnungskontos ist wertvoll, aber es zwingt den Anbieter nicht, zu vergessen, was er gelesen hat.

Zeichnen Sie die Aufzeichnungen für eine einzelne Sitzung auf, ohne anzunehmen, dass jemand betrügt. Ethereum zeichnet die Einzahlungstransaktion und ihre Finanzierungsadresse auf. Das Nutzergerät behält das Notizgeheimnis und sendet einen Beweis an den Zahlungsserver. Der Server zeichnet die Gültigkeit des Beweises, einen Nullifier und ein Ausstellungsereignis für einen begrenzten Schlüssel auf. Der Modellanbieter zeichnet diesen Schlüssel, die Anfragen und die in Rechnung gestellte Nutzung auf. Die signierte Quittung verbindet den Schlüssel mit einer gemessenen Gesamtsumme. Beim Abschluss kann der Vertrag einen Ausstieg aufzeichnen. Jede Partei hat ein Teilbuch.

Die beabsichtigte Datenschutzeigenschaft ist, dass kein einzelnes ehrliches Parteibuch die Finanzierungsadresse direkt mit den Prompts des Anbieters verbindet. Eine Koalition, ein Datenleck oder ein externer Beobachter mit Zeitstempeln kann mehr Informationen haben. Wenn ein Nutzer einen ungewöhnlichen Betrag einzahlt und sofort eine einzelne ungewöhnliche Anfrage sendet, könnte die Korrelation von Ereignissen einfacher werden. Wenn ein Anbieter ein Dokument erhält, das den Nutzer identifiziert, kann er wissen, wer gefragt hat, obwohl er nie die Tresoradresse gesehen hat. Dies ist ein Kompositionsproblem, kein fehlgeschlagener Zero-Knowledge-Beweis.

Die Buchübung zeigt auch die Bedeutung von Schlüssel-Lebensdauern. Ein Sitzungsnachweis gruppiert absichtlich alle Anfragen, die er autorisiert, damit ein Anbieter sie messen kann. Eine Obergrenze von 50 $ kann viele Prompts unter einem Schlüssel erlauben. Niedrigere Obergrenzen und kürzere Sitzungen können reduzieren, wie viel Inhalt innerhalb eines Nachweises verknüpft wird, erfordern aber häufigere Beweise und können Latenz oder Kosten erhöhen. Es gibt keine universell private Einstellung; Nutzer und Anbieter wählen zwischen Bequemlichkeit, Kosten und Verknüpfbarkeit.

Ein öffentliches Bedrohungsmodell sollte genau benennen, welche Aufzeichnungen wie lange aufbewahrt werden. Es sollte sagen, ob der Server während der Beweiseinreichung Quell-IP-Adressen protokolliert, ob er Nullifier unbegrenzt speichert und ob der Anbieter Quittungsidentifikatoren nach der Abrechnung mit Anfrageinhalten verknüpfen kann. Das Löschen eines Abrechnungsnamens aus einer Datenbank ist hilfreich. Es ist unzureichend, wenn eine persistente Gerätekennung still und leise dasselbe Profil neu erstellt.

Eine signierte Nutzungsquittung verlagert Vertrauen in die Messung

Der Anbieter oder Server benötigt eine Möglichkeit, die tatsächlich erbrachte Arbeit in Rechnung zu stellen. Das Design verwendet eine signierte Quittung, die dem kurzlebigen Schlüssel und seiner Nutzung zugeordnet ist. Dies verlagert eine zentrale kommerzielle Frage auf die Genauigkeit der Messung. Wenn ein Anbieter Token, Anfragen oder Zeit überzählt, kann ein gültiger Zahlungsbeweis die zugrunde liegende Rechnung nicht korrigieren. Die Signatur macht eine behauptete Gesamtsumme später schwer umschreibbar; sie belegt nicht, dass die behauptete Nutzung nach der Preisliste des Anbieters fair war.

Ein Kunde sollte fragen, welche Einheit berechnet wird, wer die Quittung signiert, wie ungenutzte Reservierung freigegeben wird und was passiert, wenn eine Anfrage auf halbem Weg fehlschlägt. Dies sind gewöhnliche Abrechnungsfragen in ungewöhnlicher kryptografischer Verkleidung. Eine Obergrenze begrenzt die Höhe einer unerwarteten Belastung in einer Sitzung, aber viele kleine Sitzungen können dennoch erhebliche Kosten verursachen. Ratenbegrenzungen und Rechnungen benötigen möglicherweise einen datenschutzwahrenden Streitbeilegungsprozess.

Der Kompromiss ist operativer Natur. Traditionelle API-Konten vereinfachen Kundensupport, Rückerstattungen und Missbrauchsuntersuchungen, weil ein Anbieter den Käufer identifizieren kann. zkAPI entfernt eine persistente Abrechnungsidentität aus dem beabsichtigten Zahlungspfad. Anbieter benötigen möglicherweise dennoch Missbrauchskontrollen, Sanktionsprüfungen, wo anwendbar, und Durchsetzung der Nutzung. Die Foundation sagt, dass Preisgestaltung und Ratenbegrenzungen bestehen bleiben können, aber tatsächliche Integrationen werden zeigen, wie Dienste kontenlose Zahlungen mit ihren Verpflichtungen und Betrugskontrollen in Einklang bringen.

Ein praktischer Test ist eine absichtlich unterbrochene Sitzung. Der Client erhält einen begrenzten Schlüssel, stellt mehrere Anfragen, verliert den Netzwerkzugang und verbindet sich später wieder. Spiegelt die Quittung nur die gelieferte Nutzung wider? Kann ein Nutzer die gemessene Menge lokal prüfen, ohne den Prompt an den Zahlungsserver zu senden? Wenn der Server verschwindet, kann der Nutzer das ungenutzte Guthaben wie beworben über den Vertrag abrufen? Diese Tests gehen über die Frage hinaus, ob ein Beweis verifiziert, hin zu der Frage, ob das Produkt die versprochene Trennung im Fehlerfall bewahrt.

Der Onchain-Vertrag ist eine Notluke, kein Privatsphärenschild

Der Vault-Vertrag kann laut der Foundation Beweise für Einzahlungs-, Schließungs- und Escape-Operationen verifizieren. Ein Onchain-Ausstiegsweg ist wichtig, weil eine Abschaltung des Anbieters Benutzergelder nicht in einer Betreiberdatenbank stranden lassen sollte. Der Vertrag ersetzt einen Teil des institutionellen Vertrauens durch Smart-Contract-Risiko. Ein Fehler in der Beweisverifikation, Buchhaltung oder Auszahlungslogik könnte Gelder beeinträchtigen, trotz eines soliden Privatsphärenkonzepts. Eine Live-Adresse ist ein Beweis für die Bereitstellung, kein Prüfzertifikat.

Öffentliche Ein- und Auszahlungen haben auch einen Privatsphärenpreis. Jemand, der die Finanzierungsadresse eines Benutzers kennt, kann beobachten, dass sie mit dem Vault interagiert hat. Er sieht möglicherweise nicht, für welche API-Sitzung bezahlt wurde, aber er sieht die Teilnahme und die Beträge. Wenn derselbe Benutzer schnell einen ungewöhnlichen Betrag an eine bereits mit ihm verbundene Adresse abhebt, kann ein Teil der umgebenden Anonymität schrumpfen. Der private Note bricht eine deterministische Abrechnungsverbindung; er löscht nicht die öffentliche Finanzierungstransaktion.

Das Projekt hat Wurzeln in einem Ethereum-Research-Design für Zero-Knowledge-API-Credits, das die Foundation als Arbeit von Davide Crapis und Vitalik Buterin identifiziert. Ein Forschungsvorschlag und ein Produktionssystem beantworten unterschiedliche Fragen. Ersterer legt eine Konstruktion dar; letzteres muss Schlüsselspeicherung, Frontend-Verhalten, Ausfälle, Belegstreitigkeiten, Upgrades und reale Gegner bewältigen. Die Veröffentlichung vom 1. Oktober bringt die Idee in eine testbare Bereitstellung, und das ist der relevante neue Aufhänger.

Die breiteren Datenschutzbemühungen von Ethereum sind nicht dasselbe Produkt. Die Berichterstattung von Crypto.news über einen vorgeschlagenen nativen Datenschutzentwurf betrifft eine Entwurfsprotokolländerung, während zkAPI eine Anwendung ist, die jetzt läuft. Der kürzliche Start der zk.money-Wallet betrifft private Transfers in einer anderen Umgebung. Keines von beiden sollte als Beweis dafür angeführt werden, dass ein über zkAPI gesendeter KI-Prompt vor seinem Modellanbieter verborgen ist.

Datenschutzbehauptungen sollten einen reproduzierbaren Test überstehen

Ein unabhängiger Prüfer könnte zwei finanzierte Notes von nicht verwandten Adressen erstellen, kurze Sitzungen mit demselben Modellanbieter durchführen und jedes Paket und Protokoll inspizieren, das für den Client, den Zahlungsserver und den Anbieter sichtbar ist. Der Prüfer sollte die direkten und die Proxy-Modi getrennt testen. Wenn der Zahlungsserver im direkten Modus einen Prompt erhält, widerspricht das der beschriebenen Trennung. Wenn der Anbieter eine Einzahlungsadresse oder eine dauerhafte Abrechnungskontokennung erhält, ist die beabsichtigte Unverknüpfbarkeit auf der Integrationsschicht fehlgeschlagen, selbst wenn der Beweisschaltkreis solide ist.

Der schwierigere Test ist statistisch. Führen Sie viele Sitzungen mit unterschiedlichen Beträgen und Zeitpunkten durch und fragen Sie dann, ob eine Partei, die nur öffentliche Chain-Daten und Serverprotokolle hat, Finanzierung und Nutzung besser als der Zufall korrelieren kann. Der Maßstab hängt von der tatsächlichen Anonymitätsmenge und den Zusatzdaten ab, die der Angreifer hat. Eine erfolgreiche kleine Labordemonstration belegt keine Privatsphäre bei einer winzigen Produktionsnutzerbasis, aber sie schafft eine Methode, um zu messen, ob Bereitstellungen mit der Zeit besser werden.

Der Inhaltstest ist unkompliziert und ernüchternd. Reichen Sie dasselbe unverwechselbare Dokument unter zwei frischen Sitzungsschlüsseln ein. Wenn ein Anbieter es in beiden erkennen kann, hat die Zahlungsunverknüpfbarkeit dem Benutzer keine Gesprächsunverknüpfbarkeit gegeben. Eine Behauptung über Zahlungen sollte anhand der ersten beiden Tests bewertet werden; eine Behauptung über anonyme KI-Nutzung muss auch den dritten überstehen. Die Veröffentlichung des Modus, des Bedrohungsmodells und der Ergebnisse würde es Benutzern ermöglichen, das richtige Werkzeug für ihr tatsächliches Anliegen zu wählen.

Der stärkste Fall ist die Entkopplung der Abrechnung von nützlichen Inhalten

Es gibt viele legitime Gründe, einem KI-Anbieter eine sensible Frage zu stellen, ohne eine dauerhafte kontogebundene Nutzungsakte anzulegen. Ein Journalist, der ein öffentliches Dokument testet, ein Forscher, der eine kontroverse Hypothese untersucht, oder ein Entwickler, der eine API innerhalb eines Agenten verwendet, möchte möglicherweise, dass der Anbieter die aktuelle Anfrage sieht, während die dauerhafte Abrechnungsbeziehung getrennt wird. Das Design von zkAPI adressiert dieses engere Bedürfnis. Es ermöglicht auch einer Maschine, für messbare Dienste zu bezahlen, ohne für jede Anfrage ein langlebiges persönliches Konto verwalten zu müssen.

Das Argument gegen Übertreibung ist ebenso stark. Anbieter sehen weiterhin Prompts, und einige Prompts offenbaren zwangsläufig die Identität. Ein Unternehmen mit strengen Vertraulichkeitsanforderungen benötigt möglicherweise vertragliche Kontrollen, lokale Modelle oder vertrauliche Datenverarbeitung sowie Zahlungsunverknüpfbarkeit. Einige Benutzer bevorzugen möglicherweise ein gewöhnliches Konto mit etabliertem Support und Rückerstattungen gegenüber einer kryptografischen Zahlungsschicht, deren Streitbeilegungsmechanismen noch unreif sind. Die Wahl hängt vom tatsächlichen Bedrohungsmodell ab.

Die von crypto.news diskutierte Ethereum-Datenschutz-Roadmap rahmt Datenschutz als ein weiteres Ziel ein. Eine Roadmap verleiht dieser Anwendung heute nicht ihre zukünftigen Schutzmaßnahmen. Ein KI-Nutzer muss den aktiven Client- und Anbieterpfad beurteilen, der tatsächlich eine Eingabeaufforderung verarbeitet.

Crypto.news erklärte die engeren Mechanismen von Zero-Knowledge-Beweisen in einer separaten Einführung. Ein Beweis offenbart eine definierte Tatsache, ohne einen Zeugen preiszugeben; er ist kein Allzweck-Tarnumhang. Das Interview über datenschutzorientierte Ethereum-Infrastruktur unterstreicht, wie verschiedene Produkte unterschiedliche Daten schützen. Die nützliche Frage für zkAPI ist, welche Partei bei jedem Schritt welchen Datensatz sieht, nicht ob das Projekt für das breite Wort „privat“ qualifiziert ist.

Der beste Gegenbeweis zu einer skeptischen Lesart wäre eine gemessene Nutzung ohne dauerhafte Identitätsverknüpfung, klare Modusbezeichnungen, unabhängige Sicherheitsüberprüfung und ein veröffentlichtes Bedrohungsmodell, das IP, Browser-Telemetrie und Belege abdeckt. Der beste Gegenbeweis zu einer expansiven Marketingbehauptung steht bereits im Beitrag der Foundation: Der Anbieter sieht die Eingabeaufforderung. Beide Beobachtungen können gleichzeitig zutreffen.

Die Foundation listet Maschine-zu-Maschine-API-Zahlungen als mögliche Anwendung auf. Ein autonomer Agent kann Hunderte von Aufrufen mit einem einzigen finanzierten Note oder vielen kurzen Sitzungen senden. Wenn seine Aufgaben Kundendatensätze enthalten, kann der Modellanbieter über diese Kunden erfahren, selbst während die Zahlungsquelle des Agenten privat bleibt. Der Datenschutznutzen gehört zur Abrechnungsverknüpfung; er sollte nicht an jedes in einer Anfrage genannte Subjekt weitergegeben werden.

Ein Agent benötigt auch Budgetkontrollen. Eine Obergrenze pro Schlüssel begrenzt eine Sitzung, aber eine Schleife kann wiederholt Schlüssel erhalten, bis das Note geleert ist, es sei denn, der Client erzwingt eine umfassendere Ausgabenrichtlinie. Der Betreiber sollte ein Tages- oder Aufgabenlimit, Warnungen und eine Pausenkontrolle getrennt vom kryptografischen Beweis definieren. Der Beweis verifiziert autorisiertes Guthaben, nicht ob der Aufruf des Agenten notwendig oder wirtschaftlich war.

Wenn mehrere Agenten einen gemeinsamen Guthabenpool teilen, kann die interne Buchhaltung zum versteckten Abrechnungssystem werden. Der Betreiber muss möglicherweise Gebühren Teams oder Kunden zuordnen, ohne deren Identitäten an den API-Anbieter zu exportieren. Das kann mit einem lokalen Ledger erfolgen, schafft aber einen weiteren sensiblen Datensatz, der geschützt werden muss. Der Wechsel von der Kontenabrechnung zur Note-Abrechnung schafft die Abstimmung nicht ab; er verlagert sie.

Schließlich kann sich ein Agent durch sein Verhalten verraten. Wiederholte Aufrufe zum gleichen Zeitplan, dieselben Tool-Header und dieselben aufgabenspezifischen Phrasen können separate kurzlebige Schlüssel leicht gruppierbar machen. Das Verbergen eines Onchain-Finanzierungs-Notes ist nützlich gegen Zahlungsüberwachung. Es ist keine Verteidigung gegen einen Verhaltensfingerabdruck, den der Agent mit jeder Anfrage sendet.

Eine Bereitstellung benötigt weiterhin ein Bedrohungsmodell-Audit

Stand 2. Oktober sagt die Foundation, dass der Code, der Server, der Client und der Tresor live sind. Der Beitrag verlinkt einen Mainnet-Vertrag und ein Repository. Er veröffentlicht in der Ankündigung keine definitive Nutzerzahl, keinen auditierten Gesamtwert, keine vollständigen Drittanbieter-Integrationen und keine Garantie, dass jede Client-Konfiguration den direkten Laufzeitschlüsselmodus verwendet. Diese Funktion behauptet keinen Verstoß oder Fehlverhalten eines genannten Anbieters. Sie identifiziert die Informationen, die jede Partei erhalten soll, und die zusätzlichen Lecks, die die Autoren des Projekts einräumen.

Eine externe Bewertung sollte Client-Standardeinstellungen und ausgehende Verbindungen prüfen. Sendet die Browser-Demonstration Telemetrie an nicht verwandte Domains? Behält der lokale Client Schlüssel oder Prompt-Protokolle? Kann der Zahlungsserver Ausstellungszeitstempel mit Netzwerkadressen verknüpfen? Sind Belege über Sitzungen hinweg verknüpfbar? Wie werden Aktualisierungen von Schaltkreisen und Verträgen geregelt? Ein Beweis kann mathematisch einwandfrei sein, während eine Benutzeroberfläche versehentlich die Identität preisgibt, die sie trennen sollte.

Dieselbe Bewertung sollte die Sicht eines KI-Anbieters testen. Er wird den Inhalt sehen, den er verarbeitet, und eine Sitzungsberechtigung. Er kann je nach Anfragepfad Geräte- oder Netzwerkmetadaten sammeln. Die Datenaufbewahrungsrichtlinie eines Anbieters und etwaige Vertragsbedingungen bleiben zentral. Die Zahlungsschicht kann eine Quelle identifizierender Informationen reduzieren, ohne alle anderen einzuschränken.

zkAPI macht einen echten Fortschritt, wenn es zuverlässig verhindert, dass ein Modellanbieter nützliche Anfragen an ein Abrechnungskonto bindet, während die Fähigkeit des Nutzers erhalten bleibt, Gelder zurückzufordern. Es wird jeden enttäuschen, der eine private Konversation erwartet, nur weil die Zahlung per Zero-Knowledge bewiesen wurde. Die beiden Behauptungen sollten getrennt beurteilt werden.

Worauf man achten sollte

• Moduskennzeichnung: Prüfen Sie, ob jeder Client direktes Runtime-Key- oder Proxy-Routing sichtbar macht, bevor ein Nutzer Prompts sendet.
• Mainnet-Aktivität: Suchen Sie nach datierten Zahlen zu finanzierten Notes und Nutzung, die berichtet werden, ohne die Anonymität der Nutzer zu gefährden.
• Sicherheitsüberprüfungen: Lesen Sie den Umfang unabhängiger Bewertungen, die Vertragsausstiege, Proof-Schaltkreise, Client-Speicherung und Belegabwicklung abdecken.
• Metadaten-Kontrollen: Testen Sie IP-Handhabung, Telemetrie, Schlüssellebensdauern und Anbieter-Aufbewahrung in tatsächlichen Integrationen.
• Abrechnungsstreitigkeiten: Prüfen Sie, wie fehlgeschlagene Anfragen, Cap-Freigabe und bestrittene Belege behandelt werden, ohne eine Offenlegung der Identität zu erzwingen.

FAQ