Die Ethereum Foundation und das Open Anonymity Project haben zkAPI auf dem Ethereum-Mainnet live geschaltet. Damit kann jemand für gemessenen (metered) KI- oder API-Zugriff bezahlen, ohne dass der Anbieter erfährt, welche Einzahlung dafür verwendet wurde. Drei Punkte, die man auseinanderhalten sollte:
1. Die Privatsphäre ist auf den Abrechnungs-Kanal beschränkt, nicht auf den Inhalts-Kanal. Der Anbieter erhält weiterhin die Anfrage. Was er nicht erfährt, ist, welche finanzierte Einzahlung sie beglichen hat. Die Ankündigung sagt das ganz klar, und diese Reichweite ist die gesamte Behauptung.
2. Das Metering wird zu einem Double-Spend-Problem. Normale API-Abrechnung ist ein Kontostand, den ein Server gegen ein Konto dekrementiert, das er identifizieren kann. Hier gibt es kein identifizierbares Konto, daher muss die Korrektheit daraus folgen, dass man nachweist, dass eine Einzahlung existiert und noch nicht bereits verwendet wurde. Der schwierige Teil verlagert sich von der Buchhaltung zur Einzigartigkeit, und die Einzigartigkeit wird auf der Chain geklärt.
3. Der Prover sitzt beim Client. Bezahlen zu können hängt davon ab, welche Software der Nutzer ausführt, nicht nur davon, dass ein Abrechnungsserver online bleibt. Das ist ein anderes Ausfallverhalten als ein Ausfall der Infrastruktur (Outage), und es ist der Teil, den die meisten Menschen zuletzt entdecken.
Das Design folgt einem Rahmenwerk, das Vitalik Buterin und Davide Crapis bereits im Februar veröffentlicht haben. Worauf man achten sollte: Ob Anbieter eine Zahlung akzeptieren, die sie nicht zuordnen können, denn eine Schiene (rail), auf die niemand in Angeboten verweist, ist im Grunde nur ein sehr eleganter Tresor.
Keine Finanzberatung. Mach deine eigene Recherche.
#Ethereum #Web3 #Privacy
1. Die Privatsphäre ist auf den Abrechnungs-Kanal beschränkt, nicht auf den Inhalts-Kanal. Der Anbieter erhält weiterhin die Anfrage. Was er nicht erfährt, ist, welche finanzierte Einzahlung sie beglichen hat. Die Ankündigung sagt das ganz klar, und diese Reichweite ist die gesamte Behauptung.
2. Das Metering wird zu einem Double-Spend-Problem. Normale API-Abrechnung ist ein Kontostand, den ein Server gegen ein Konto dekrementiert, das er identifizieren kann. Hier gibt es kein identifizierbares Konto, daher muss die Korrektheit daraus folgen, dass man nachweist, dass eine Einzahlung existiert und noch nicht bereits verwendet wurde. Der schwierige Teil verlagert sich von der Buchhaltung zur Einzigartigkeit, und die Einzigartigkeit wird auf der Chain geklärt.
3. Der Prover sitzt beim Client. Bezahlen zu können hängt davon ab, welche Software der Nutzer ausführt, nicht nur davon, dass ein Abrechnungsserver online bleibt. Das ist ein anderes Ausfallverhalten als ein Ausfall der Infrastruktur (Outage), und es ist der Teil, den die meisten Menschen zuletzt entdecken.
Das Design folgt einem Rahmenwerk, das Vitalik Buterin und Davide Crapis bereits im Februar veröffentlicht haben. Worauf man achten sollte: Ob Anbieter eine Zahlung akzeptieren, die sie nicht zuordnen können, denn eine Schiene (rail), auf die niemand in Angeboten verweist, ist im Grunde nur ein sehr eleganter Tresor.
Keine Finanzberatung. Mach deine eigene Recherche.
#Ethereum #Web3 #Privacy