Der Ethereum-Mitbegründer Vitalik Buterin kommentierte am 17. Mai auf X ein Problem beim Ethereum-Statusspeicher. Dabei wies er darauf hin, dass selbst wenn Nutzer ihre Daten selbst speichern, die Blockchain nur Hashes speichert und Transaktionen lediglich Beweise enthalten, immer noch Daten gespeichert und aktualisiert werden müssen, die für die Verifikation der Beweise genutzt werden. Diese Daten seien „letztlich fast genauso groß wie der Status selbst“. Vitalik hatte zuvor gesagt, dass ZK-Zahlungen (Zero-Knowledge-Zahlungen) der nächste entscheidende Standard für die globale digitale Wirtschaft seien.
Statusspeicher-Problem: Vitalik bestätigt die zentralen technischen Herausforderungen
In seinem Kommentar bestätigte Vitalik einen grundlegenden technischen Widerspruch: Bei einem Design, das „on-chain nur Hashes“ speichert, müssen Verifizierer weiterhin auf Hilfsdaten (witness data) zugreifen oder diese neu aufbauen, um einen ZK-Beweis (Zeroknowledge-Proof) zu verifizieren. Deren Größe ist nahezu identisch mit den ursprünglichen Statusdaten. Das bedeutet, dass ein rein „on-chain Hashes“-Design das Problem der Statusaufblähung nicht vollständig lösen kann. Vitalik bestätigte, dass es dafür Lösungen gibt, betonte jedoch, dass alle Lösungen die Ethereum-Ebene betreffen. Als derzeit relevanten Vorschlag nannte er EIP-8037. Dessen Kernmechanismus ist, die anfänglichen Gas-Kosten für die Erstellung neuer Smart Contracts, Konten und Storage-Slots deutlich zu erhöhen. Es handelt sich dabei um eine einmalige Anpassung der Vorabkosten, nicht um ein kontinuierliches, zeitlich gewichtetes Mietmodell.
Vision für ZK-Zahlungen: Drei zentrale Thesen aus dem Blog vom 10. Mai
Vitalik bestätigte in seinem Forschungsartikel vom 10. Mai die folgenden Positionen:
Problemdefinition: Die Transparenz und Offenheit von Blockchains ist das Haupthemmnis dafür, dass Krypto-Zahlungen den Ersatz von traditionellen Fiat-Währungen im täglichen Einzelhandel breiter ersetzen können; als Lösung wird „Standard-Privatsphäre“ statt „selektiver Anonymität“ benötigt.
Technische Lösung: ZK-Beweis-Transaktionen ersetzen herkömmliche Überweisungen: Nutzer müssen weder ihren vollständigen Kontostand noch die Transaktionshistorie offenlegen, um die Gültigkeit der Zahlung zu verifizieren; Layer 2 kann über „rekursive SNARKs“ private Zahlungen mit derselben Geschwindigkeit und zu ähnlichen Kosten wie transparente Zahlungen verarbeiten.
Compliance-Mechanismus: In den ZK-Zahlungsstandard werden Mechanismen für „selektive Offenlegung“ und „Proof of Innocence“ (Beweis der Unschuld) eingeführt. So können Nutzer autorisierten Stellen oder Steuerbehörden bestimmte „Compliance-Beweise“ bereitstellen, ohne der Öffentlichkeit vollständige Transaktionsdaten offenzulegen. Dadurch soll das Kompatibilitätsproblem mit AML-Vorschriften (Anti-Geldwäsche) gelöst werden.
KI-Agenten-Anwendungsfälle: Punkte für die Nutzung von Zero-Knowledge-APIs
In seinem Blog wies Vitalik darauf hin, dass autonome KI-Agenten auf die Zahlung von LLM-API-Punkten und anderen Diensten angewiesen sind, ohne dabei Spuren zu hinterlassen, die auf ihren menschlichen Eigentümer zurückverfolgt werden können. Er schlägt „Zero-Knowledge-API-Nutzungspunkte“ vor, mit denen Agenten die Zahlungsüberprüfung auf Ethereum Layer 2 abschließen können, während gleichzeitig die Privatsphäre der Zahlungsaufzeichnungen erhalten bleibt. Das soll sowohl die operative Autonomie der Agenten als auch die Datensicherheit der Eigentümer berücksichtigen.
Häufige Fragen
Was bedeutet die technische Aussage „On-chain Hashes brauchen trotzdem vollständige Verifikationsdaten“?
In einem System mit ZK-Beweisen benötigt ein Verifizierer Hilfsdaten (witness), um die Korrektheit eines ZK-Beweises zu überprüfen. Selbst wenn die Blockchain nur den Hash des Zustands speichert, muss man beim Verifizieren neuer ZK-Beweise auf diese Hilfsdaten zugreifen, deren Größe nahe an den ursprünglichen Statusdaten liegt. Daher lässt sich das Problem der Statusaufblähung nicht vollständig durch „nur Hashes“ umgehen.
Welche grundlegenden Unterschiede bestehen zwischen dem Vorabkosten-Mechanismus und laufenden Speichermieten in EIP-8037?
Die Lösung in EIP-8037 sieht eine einmalige Erhöhung der anfänglichen Gas-Kosten vor, die auf neu erstellte Smart Contracts, Konten und Storage-Slots abzielt. Für bereits existierende Storage-Slots wird keine fortlaufende Gebühr erhoben. Laufende Speichermieten würden dagegen alle auf der Kette belegten On-Chain-Speicherdaten zeitbasiert bepreisen und damit alle bestehenden Smart Contracts betreffen; außerdem ist die Umsetzung schwieriger.
Wie berücksichtigt Vitaliks Ansatz für ZK-Zahlungen sowohl die Privatsphäre der Nutzer als auch die AML-Compliance-Anforderungen?
Gemäß Vitaliks Blog-Vorschlag enthält der Standard für ZK-Zahlungen Mechanismen für „selektive Offenlegung“ und „Proof of Innocence“: Nutzer behalten in der öffentlichen Sphäre die Privatsphäre, können aber bei Bedarf autorisierten Stellen verifizierbare Compliance-Beweise erzeugen lassen, ohne die vollständige Transaktionshistorie offenzulegen. So wird der langfristige Konflikt zwischen dem Schutz der Privatsphäre und Anti-Geldwäsche-Vorschriften (AML) gelöst.
