zkAPI trennt KI-Prompts von der Zahlungsidentität
Die Ethereum Foundation hat zkAPI am 1. Oktober 2026 gemeinsam mit dem Open Anonymity Project auf dem Ethereum-Mainnet gestartet. Das System soll vorausbezahlte API-Nutzung ermöglichen, ohne Zahlungsidentität und Anfragen beim Anbieter miteinander zu verknüpfen.
Im Mittelpunkt stehen zunächst KI-Dienste: Prompts können sensible Informationen enthalten, während herkömmliche API-Schlüssel Anfragen meist einem Konto und einer Zahlungsmethode zuordnen. zkAPI trennt diese Abrechnungsspur technisch von der Nutzung – allerdings nicht von allen Informationen, die bei einer Anfrage anfallen.
Wie zkAPI Zahlung und API-Nutzung trennt
Nutzer hinterlegen Credits wie ETH oder USDC mit einer gewöhnlichen Transaktion in einem Ethereum-Vault. Anschließend erzeugt die Software auf dem eigenen Gerät einen Zero-Knowledge-Proof. Dieser weist nach, dass ein Guthaben die geplante Ausgabe deckt und nicht bereits ausgegeben wurde, ohne die konkrete Einzahlung, die zugrunde liegende Guthabennotiz oder die Person offenzulegen. Zero-Knowledge-Proofs ermöglichen damit einen Nachweis, ohne die dazugehörigen Identitätsdaten preiszugeben.
Der zkAPI-Server prüft den Beweis und erstellt einen kurzlebigen API-Schlüssel mit einem festgelegten Ausgabenlimit. Im Runtime-Key-Modus gehen die Prompts direkt vom Gerät an den KI-Anbieter; der Server, der die Zahlung verarbeitet, sieht den Inhalt der Anfragen nicht. Läuft der Schlüssel ab, wird die tatsächliche Nutzung anhand eines signierten Belegs vom privaten Guthaben abgezogen – das Limit dient dabei als Reservierung, nicht als endgültiger Rechnungsbetrag.
Eine Autorisierung kann eine ganze Sitzung abdecken, statt für jeden einzelnen API-Aufruf einen neuen Proof zu benötigen. Die technischen Bausteine umfassen Groth16-Beweise auf der BN254-Kurve, Poseidon-Hashes und einen 32 Ebenen tiefen Merkle-Baum. Ein sogenannter Nullifier – eine einmalige Kennung für eine Ausgabe – macht doppelte Ausgaben erkennbar, ohne die übrigen Zahlungsdaten offenzulegen.
Die Idee hinter privaten API-Credits
Im üblichen Abrechnungsmodell verweist ein API-Schlüssel auf ein Konto, das wiederum mit einer Zahlungsmethode verbunden ist. Anbieter können dadurch die Nutzung über längere Zeit einem Profil zuordnen. Die Ethereum Foundation beschreibt direkte Onchain-Zahlungen pro Anfrage als langsam, teuer und öffentlich nachvollziehbar; ein Vermittler würde dagegen Vertrauen erfordern, dass er die Nutzungsdaten nicht zusammenführt.
zkAPI geht auf einen Entwurf für „ZK API usage credits“ von Davide Crapis und Vitalik Buterin auf Ethereum Research zurück. Die Umsetzung nutzt Commitment-Daten im Merkle-Baum, damit ein Proof die Gültigkeit einer Einzahlung belegen kann, ohne auf eine bestimmte Einzahlung zu verweisen. Ethereums Skalierungs- und Kryptografieentwicklung bildet einen breiteren technischen Kontext für solche Anwendungen.
Welche Grenzen und weitere Einsatzfelder bleiben
Die Trennung schützt nicht vor jeder Form der Identifizierung. Der Zahlungserver erkennt, dass eine gültige Zahlung vorliegt, und sieht die Gesamtausgaben einer Sitzung; laut Projekt erfährt er aber weder die Identität noch den Prompt oder die konkrete Einzahlung. Der KI-Anbieter sieht Prompts und Antworten, soll jedoch nicht erfahren, wer die Rechnung bezahlt. Auf Ethereum bleiben Einzahlungen, Schließungen und Abhebungen öffentlich, nicht aber, wofür ein Guthaben verwendet wurde.
IP-Adresse und zeitliche Muster können Anfragen dennoch korrelierbar machen. Auch wiederverwendete persönliche Angaben, Schreibstil, Gesprächsverläufe oder Projektdokumente können Sitzungen beim Anbieter erkennbar machen. Netzwerk-Anonymität und Inhaltsprivatsphäre sind daher separate Ebenen: Die Foundation nennt VPN oder Tor für die Netzwerkschicht und vertrauliche GPU-Ausführung als möglichen Ansatz für den Schutz von Inhalten; beides ist nicht Bestandteil von zkAPI.
Über KI-Inferenz hinaus nennt das Projekt Blockchain-RPC-Abfragen, Bild- und Videogenerierung, VPN-Bandbreite sowie Machine-to-Machine-Dienste als mögliche Anwendungen. Der lokale Client stellt OpenAI- und Ollama-kompatible Schnittstellen bereit, sodass bestehende Apps über localhost angebunden werden können. Neben dem Runtime-Key-Modus gibt es einen einfacheren Proxy-Modus, bei dem der Relay-Server den Datenverkehr sieht. Das Guthaben bleibt an einen Ethereum-Contract gebunden und kann dort geschlossen und abgehoben werden, selbst wenn ein zkAPI-Server ausfällt. Automatisierte Krypto-Zahlungen für digitale Dienste zeigen einen weiteren Ansatz, API- und Agentenökonomie mit Zahlungsinfrastruktur zu verbinden.
The post zkAPI trennt KI-Prompts von der Zahlungsidentität appeared first on Cryptonews Germany.
