UTXO-Historie, Datenschutz und Retention-Modelle – Diskussion aus dem Ethereum-Research-Forum

8. September 2026 Kryptowährungen

Im Ethereum-Research-Forum haben mehrere Nutzer die Problematik von UTXO-Historie, Datenschutz und Datenaufbewahrung diskutiert. Die Beiträge zeigen unterschiedliche Sichtweisen auf die Notwendigkeit, dass einige Nodes Historie behalten, sowie mögliche technische Lösungen, um UTXOs zu prüfen, Datenschutz zu wahren und Anreize für die Datenaufbewahrung zu schaffen.

Historie behalten und UTXO-Prüfung

Ein zentrales Argument lautet, dass nicht alle Nodes die gesamte Historie entfernen dürfen. Für die Prüfung von UTXOs könne ein Light-Client, der in einer Wallet integriert ist, das P2P-Netz nutzen, um UTXOs von Archiv- oder Full-Nodes gefiltert anzufordern. Diese Vorgehensweise sei ähnlich zu anderen Chains wie Zcash, Monero oder Bitcoin.

  • Light-Client in der Wallet integriert
  • Abfrage von gefilterten UTXOs über das P2P-Netz
  • Abhängigkeit von Nodes, die Historie behalten

Grenzen des Light-Client-Modells bei Stealth-Adressen

Die Diskussion hebt hervor, dass das Filtern von UTXOs nach Empfänger bei Stealth-Adressen nicht funktioniert, weil jede Abfrage dem Server offenbart, welche Outputs dem Nutzer gehören. Die Alternativen seien das Herunterladen aller Daten und blindes Scannen, was zu schweren Wallet-Synchronisationen führt. Mögliche Mitigationen umfassen:

  • Scannable Hint Tags (z. B. View-Tag à la EIP-5564)
  • Viewing Keys
  • Filter-Downloads

All diese Ansätze erfordern jedoch einen Kompromiss zwischen Entdeckung und Privatsphäre.

Retention-Boni als Anreiz zur Historienaufbewahrung

Ein Vorschlag sieht vor, dass bei der Erstellung eines UTXOs ein kleiner Bounty (Retention-Boni) escrowed wird. Dieser Bounty kann von demjenigen beansprucht werden, der das Opening (Daten) zum Zeitpunkt des Spend nachweist. Der Mechanismus folgt dem „Creator-pays“-Prinzip, wodurch die Kosten dort internalisiert werden, wo sie entstehen.

  • Retention-Boni werden beim UTXO-Erstellen hinterlegt
  • Bei Ausgaben des UTXOs kann der Bounty vom Daten-Halter beansprucht werden
  • Reduziert Dust-Minting-Griefing, weil das Erstellen von UTXOs mit Kosten verbunden ist

Alternative Modelle, wie Spender-pays-Retrieval-Fees oder gestakte Custody-Challenges, wurden ebenfalls genannt, wobei „Creator-pays“ den geringsten zusätzlichen Aufwand benötigt.

Technische Vorschläge: View Tags, Öffnungsfelder und EIP-5564

Ein ein-Byte-View-Tag, wie in EIP-5564 beschrieben, könnte das Scannen von UTXOs um das 256-fache beschleunigen, bei nur minimaler Informationsfreigabe. Das vorgeschlagene Feld in den Openings sei variabel-längen- und versionsfähig, protocol-opaque, und könnte später durch einen Fork erweitert werden.

  • Ein Byte View-Tag = ca. 256-mal schnelleres Scannen
  • Nur geringe Privatsphären-Leakage
  • Ein variabel-längen-Feld in den Openings, das später erweitert werden kann

Mutable vs. Immutable UTXO-Bäume

Ein weiterer Diskussionspunkt bezieht sich auf die Struktur des UTXO-Baums. Während ein unveränderlicher (immutable) Baum die Commitment-Roots pro Block festlegt, erlaubt ein veränderlicher (mutable) Baum das Entfernen von Einträgen nach dem Spend. Dabei entstehen jedoch Probleme:

  • Veränderliche Bäume führen zu veralteten Pfaden (Witnesses) für andere unverbrauchte UTXOs im selben Block
  • Validatoren benötigen aktuelle Witnesses oder Mechanismen zum Aktualisieren
  • Der „spent bit“ wird zum Preis für stabile Opening-Proofs

Falls Ethereum in Zukunft breite State-Witness-Verfügbarkeit bietet, könnte der mutable Ansatz interessanter sein.

EIP-8304, SSZ-Encoding und Trustless Logs

Einige Nutzer schlagen vor, anstelle eines per-Block-Openings-Root das Log-System auf SSZ-kodierte Receipts umzustellen. Durch EIP-8304 könnten Block-Einträge effizient bewiesen werden, wodurch ein Trustless-Log-Index-API standardisiert werden könnte. Die vorgeschlagene Architektur umfasst:

  • Lineare, eindeutige Opening-Index-Zuweisung im UTXO-Contract
  • Referenzierung des Index in den emittierten Logs
  • Tightly packed spent-Bitfields
  • EIP-8304- und SSZ-Receipts als generelle Bausteine

Der Ansatz ermöglicht, dass Nutzer nur den Block-Header und den Merkle-Pfad zum Receipt benötigen, um den Proof dauerhaft zu behalten.

Zusammenfassung der offenen Fragen

Die Diskussion lässt mehrere offene Punkte zurück:

  • Wie soll das Format der Öffnungs-Felder heute gestaltet werden, um spätere Mitigationen zu ermöglichen?
  • Welcher Anreizmechanismus (Creator-pays vs. Spender-pays) ist langfristig am effizientesten?
  • Welcher Baum-Ansatz (mutable vs. immutable) lässt sich besser mit zukünftigen Ethereum-State-Witness-Lösungen kombinieren?
  • Wie kann das Log-System (EIP-8304, SSZ) standardisiert werden, um Trustless-Logs zu unterstützen?

Fazit

Die Beiträge im Ethereum-Research-Forum verdeutlichen, dass das Gleichgewicht zwischen Daten-Discovery, Datenschutz und effizienter Historien-Aufbewahrung komplex ist. Light-Client-Modelle ermöglichen UTXO-Abfragen, stoßen jedoch bei Stealth-Adressen an Grenzen. Retention-Boni bieten einen möglichen Anreiz, dass Nodes Historie behalten, während View-Tags und ein variabel-längen-Opening-Feld als technische Mittel das Scannen beschleunigen können. Die Entscheidung zwischen mutable und immutable UTXO-Bäumen sowie die Integration von EIP-8304 und SSZ-Encoding bleiben zentrale Designfragen, die zukünftige Protokoll-Entwicklungen prägen könnten.