zkAPI befasst sich mit einem konkreten Problem nutzungsabhängig bezahlter KI: Ein Dienst soll bezahlt werden können, ohne jede Anfrage automatisch einer Rechnungsidentität zuzuordnen. Zero-Knowledge-Beweise machen die an ein Modell gesendeten Inhalte allerdings nicht von selbst anonym.
Wichtig ist außerdem der am 26. Oktober 2026 geprüfte Softwarestand. Die Ankündigung der Ethereum Foundation vom 1. Oktober beschreibt einen Dienst im Mainnet. Der aktuelle Entwicklungszweig enthält dagegen Warnungen zu Komponenten und Bereitstellungskonfigurationen, die noch nicht produktionsreif sind.
zkAPI: Was tatsächlich getrennt werden soll
Der Beitrag der Ethereum Foundation beschreibt die Trennung zwischen Ausgabenfreigabe und der Identität hinter einer Einzahlung. Der Anbieter erhält weiterhin die Anfrage, die er bearbeiten muss. Zahlungsprivatsphäre und Vertraulichkeit des Prompts sind unterschiedliche Eigenschaften.
Statt pauschal nach einem privaten Chat zu fragen, sollten Nutzer einzelne Beobachter unterscheiden. Wer sieht den Inhalt? Wer wickelt das Geld ab? Wer könnte diese Informationen mithilfe anderer Daten wieder miteinander verbinden?
Eine Anwendung kann eine Verbindung unterbrechen und eine andere unverändert lassen. Stehen Name, Arbeitgeber und interne Unterlagen direkt in einer Anfrage, verschwinden diese Angaben nicht dadurch, dass die Zahlung weniger leicht zugeordnet werden kann.
Ein Forschungsvorschlag ist keine Spezifikation jeder Veröffentlichung
Der Vorschlag ZK API Usage Credits von Davide Crapis und Vitalik Buterin untersucht das Zusammenspiel von Zahlung, Privatsphäre und Missbrauchsschutz. Er liefert den Forschungshintergrund, beschreibt aber nicht automatisch jede spätere Softwareversion.
Diese Unterscheidung verhindert einen verbreiteten Fehler: Ein theoretisches Schaubild, eine Vorführung und ein aktiver Vertrag werden sonst wie austauschbare Nachweise behandelt. Tatsächlich beantworten sie verschiedene Fragen und lassen jeweils andere Punkte offen.
Die Forschung erklärt das Ziel. Der Code zeigt, wie eine bestimmte Version dieses Ziel erreichen soll. Eine überprüfte Bereitstellung bezeichnet das System, mit dem Nutzer tatsächlich interagieren können. Für eine Sicherheitsbewertung müssen diese Ebenen ausdrücklich zusammenpassen.
Entscheidend ist die konkret verwendete Version
Das offizielle Repository bezeichnet das Protokoll beim Abruf am 26. Oktober als experimentell. Es warnt, dass der datenschutzorientierte Client-Entwicklungszweig keine Produktionsversion ist, nennt noch nicht bereitgestellte Konfigurationen der aktuellen Revision und verweist für frühere Notes auf eine separate Veröffentlichungslinie.
Diese Hinweise beweisen weder eine falsche ursprüngliche Ankündigung noch den Ausfall sämtlicher früherer Dienste. Sie zeigen aber, dass der Download des Hauptzweigs nicht automatisch dem Anfang Oktober beschriebenen Dienst entspricht.
Vor einem Einsatz mit echtem Geld müssen Veröffentlichung, Netzwerk, Vertragsadresse und passende Dokumentation eindeutig feststehen. Fehlt einer dieser Bezüge, ist ein Abbruch vernünftig. Bereitstellungsprüfungen durch zufällige Konfigurationsänderungen zu umgehen, wäre dagegen keine belastbare Lösung.
Schutzversprechen und notwendige Prüfungen
| Frage | Richtige Einordnung | Sinnvolle Prüfung |
|---|---|---|
| Sind Zahlung und Anfrage getrennt? | Das ist das Protokollziel | Tatsächliche Version untersuchen |
| Liest das Modell den Prompt? | Zahlungsprivatsphäre verhindert das nicht | Übertragene Daten begrenzen |
| Ist der Hauptzweig produktionsreif? | Nicht voraussetzen | Veröffentlichungshinweise lesen |
| Ist eine Einzahlung risikofrei? | Nein | Vertrag, Client und Ausstieg prüfen |
Eine verwandte Fragestellung behandelt unser Beitrag über Wallet-RPC und Datenschutz. Eine Information kann auf einer Ebene geschützt und für einen anderen beteiligten Dienst trotzdem sichtbar sein.
Ein Anwendungsbeispiel ohne Anonymitätsgarantie
Angenommen, ein Assistent ordnet öffentlich zugängliche Produktbeschreibungen mit einem begrenzten Budget ein. Eine Trennung zwischen Zahlungsquelle und einzelnen Aufgaben könnte nützlich sein, sofern Dienst und gewählte Version diesen Ablauf tatsächlich unterstützen.
Bei vertraulichen Verträgen kann dagegen der übertragene Inhalt das entscheidende Risiko sein. Dann gehören lokale Verarbeitung, geeignete Vereinbarungen mit dem Anbieter und eine Verringerung der gesendeten Unterlagen in den Vergleich, nicht nur ein anderer Zahlungsweg.
Dies ist ein Beispiel für eine Bewertung, kein von unserer Redaktion durchgeführter Integrationstest. Wir haben weder Geld eingezahlt noch Auszahlungen geprüft oder die Widerstandsfähigkeit gegen eine Verknüpfung mehrerer Sitzungen gemessen.
Welche Fragen vor einem Versuch beantwortet sein sollten
Zunächst muss die Grenze klar sein: Welcher Beteiligte soll Zahlung und Nutzung nicht verbinden können? Danach sind die Daten in jeder Anfrage und die vom lokalen Client gespeicherten Informationen zu erfassen.
Es folgen praktische Fragen. Wie wird der lokale Zustand geschützt? Was geschieht beim Verlust des Geräts? Welcher dokumentierte Ablauf ermöglicht bei dieser Version die Rückgewinnung eines Restguthabens? Eine allgemeine Erläuterung der Kryptografie ersetzt diese Antworten nicht.
Ausgabenlimits und Fehlerbehandlung gehören ebenfalls dazu. Die Anwendung sollte bei einem Ausfall nicht unbemerkt auf einen weniger privaten Weg wechseln. Sonst könnte sich das Risiko ändern, während die Oberfläche weiterhin einen normalen Betrieb anzeigt.
Infrastruktur statt Investmentversprechen
zkAPI ist als Versuch interessant, den Zugang zu Diensten von einer dauerhaften wirtschaftlichen Identität zu lösen. Dafür braucht es weder eine Prognose zum Ethereum-Kurs noch die Behauptung, eingezahlte Guthaben würden Rendite erzielen.
Der Maßstab entspricht unserer Einordnung zu Krypto-Privatsphäre und rechtmäßiger Nutzung: Risiken bestimmen, Grenzen prüfen und angemessene Schutzmaßnahmen wählen. Eine vielversprechende Richtung ist noch keine nachgewiesene Garantie für jede Umsetzung.
Für einen ersten Versuch ist deshalb ein eng begrenzter, nicht sensibler Ablauf sinnvoller als die Übernahme eines gesamten Arbeitsprozesses. Ein nachvollziehbarer Versionsnachweis und überprüfbare Abbruchbedingungen liefern mehr Sicherheit als eine Oberfläche, die lediglich mit dem Begriff anonym wirbt.
Auch die Zuständigkeit muss geklärt sein: Wer reagiert auf widersprüchliche Abrechnungen, wie werden Fehler dokumentiert, und welche Informationen braucht der Support dafür? Eine Verbesserung der Privatsphäre sollte nicht erst im Problemfall daran scheitern, dass niemand den vorgesehenen Ablauf kennt.