Ethereum‑Privacy‑Roadmap: Vitalik Buterins drei kurzfristige Schritte

Ethereum verfügt schon lange über starke kryptografische Werkzeuge für private Transaktionen. In der Praxis geben Nutzer jedoch weiterhin viele Informationen preis – etwa durch die Reihenfolge ihrer Transaktionen, durch Wallet‑Infrastruktur oder durch Metadaten aus Netzwerk‑Anfragen.

Vitalik Buterin hat deshalb eine kurzfristige Privacy‑Roadmap vorgestellt, die nicht auf eine vollständige Neugestaltung des Protokolls wartet, sondern auf mehrere umsetzbare technische Verbesserungen setzt.

Der Ansatz konzentriert sich auf drei konkrete Engineering‑Schritte: stärkere Zensurresistenz bei der Aufnahme von Transaktionen in Blöcke, ein neues Nonce‑Modell für parallele Aktivitäten sowie Wallet‑ und Infrastruktur‑Upgrades gegen Off‑Chain‑Datenlecks. Zusammen sollen diese Maßnahmen echte, im Alltag nutzbare Privatsphäre im Ethereum‑Ökosystem ermöglichen.

1. Account Abstraction + FOCIL gegen Transaktionszensur

Der erste Schritt betrifft die Block‑Inklusion – also die Entscheidung, welche Transaktionen tatsächlich in einen Block aufgenommen werden. In der heutigen Architektur haben Block‑Builder und Validatoren erheblichen Einfluss darauf, welche Transaktionen erscheinen oder verzögert werden.

Buterin schlägt vor, Account Abstraction mit sogenannten Fork‑Choice Enforced Inclusion Lists (FOCIL) zu kombinieren. Dieses Mechanismus‑Design sorgt dafür, dass gültige Transaktionen aus dem öffentlichen Mempool innerhalb einer begrenzten Zahl von Slots in einen Block aufgenommen werden müssen, statt vollständig im Ermessen eines einzelnen Block‑Proposers zu liegen.

FOCIL soll ein zentrales Element des geplanten Hegota‑Upgrades sein, das für die zweite Hälfte von 2026 vorgesehen ist. Ziel ist es, zu verhindern, dass Builder, Relays oder Validatoren bestimmte Transaktionen einfach ignorieren können.

Gerade für Privacy‑Transaktionen ist das entscheidend: Wenn Infrastruktur‑Akteure sie leicht blockieren könnten, wäre jede Form von On‑Chain‑Privatsphäre praktisch wirkungslos. Eine garantierte Inklusion stärkt daher Ethereums Grundprinzip der Zensurresistenz.

2. Keyed Nonces (EIP‑8250): Parallele Transaktionen statt Warteschlangen

Das zweite Problem betrifft das aktuelle Nonce‑System von Ethereum. Jede Adresse besitzt eine einzige fortlaufende Nonce‑Sequenz. Diese verhindert zwar Replay‑Angriffe, hat aber einen großen Nachteil: Wenn eine Transaktion hängen bleibt, blockiert sie alle nachfolgenden Transaktionen derselben Adresse.

Die vorgeschlagene Verbesserung EIP‑8250 führt sogenannte keyed nonce lanes ein. Jede Transaktion enthält dabei zwei Felder:

• nonce_key – definiert eine eigene Replay‑Schutz‑Domäne
• nonce_seq – die Sequenz innerhalb dieser Domäne

Transaktionen mit unterschiedlichen Keys können unabhängig voneinander verarbeitet werden. Dadurch blockiert eine verzögerte Transaktion nicht mehr alle anderen.

Das ist besonders wichtig für Privacy‑Systeme und Relayer‑Infrastrukturen. Viele Datenschutz‑Protokolle bündeln Aktivitäten mehrerer Nutzer über gemeinsame Konten oder komplexe Transaktionspipelines. Im heutigen Nonce‑Modell kollidieren diese Vorgänge häufig miteinander.

Mit keyed nonces können solche Abläufe parallel laufen, ohne sich gegenseitig zu blockieren – ein Vorteil sowohl für Privatsphäre als auch für Skalierung.

Entwickler diskutieren, EIP‑8250 ebenfalls im Rahmen des Hegota‑Upgrades einzuführen, zusammen mit weiteren Änderungen an Ethereums Transaktionsarchitektur.

3. Privatsphäre auf der Zugriffsebene: Wallets, Kohaku und Private Reads

Der dritte Punkt betrifft ein weniger offensichtliches, aber weit verbreitetes Problem: Metadaten‑Leaks über Wallets und RPC‑Provider.

Selbst wenn Transaktionen selbst privat werden, können Nutzer weiterhin sensible Informationen preisgeben – etwa indem ihre Wallets Blockchain‑Daten abfragen. Node‑Betreiber oder RPC‑Provider können sehen, welche Adressen, Verträge oder Kontostände abgefragt werden und daraus Nutzerprofile erstellen.

Buterins Roadmap betont daher Access‑Layer‑Privatsphäre. Dazu gehören neue Wallet‑Frameworks und Infrastruktur, die solche Datenlecks verhindern sollen.

Ein Beispiel ist Kohaku, ein modulares Privacy‑Toolkit für Ethereum‑Wallets. Es integriert Datenschutz‑Funktionen direkt in Wallet‑Software, statt Nutzer auf separate Privacy‑Apps zu verweisen.

Einige Konzepte kombinieren diese Architektur mit Light‑Client‑Technologie, sodass Wallets Blockchain‑Daten selbst verifizieren können, ohne vollständig auf zentrale RPC‑Dienste angewiesen zu sein.

Das reduziert die Menge an Nutzerdaten, die Infrastruktur‑Betreiber passiv sammeln können.

Wie diese Roadmap in Ethereums größere Privacy‑Strategie passt

Buterins Vorschläge markieren einen wichtigen Strategiewechsel: Statt auf eine einzige umfassende Privacy‑Lösung zu warten, setzt Ethereum auf inkrementelle Verbesserungen entlang des gesamten Stacks.

Diese Änderungen adressieren zwei zentrale Schwachstellen moderner Blockchains:

• Transaktionszensur, wenn Infrastruktur‑Akteure bestimmte Aktivitäten unterdrücken können
• Metadaten‑Leaks, wenn Wallet‑Anfragen oder Infrastruktur‑Logs Nutzerverhalten offenlegen

Durch bessere Inklusionsgarantien, parallele Transaktionsmechanik und datenschutzfreundliche Wallet‑Architektur soll Privatsphäre von einem experimentellen Feature zu praktischer Standard‑Infrastruktur werden, die Wallets und Anwendungen direkt integrieren können.

Langfristig zielt die Strategie darauf ab, dass sowohl Privatnutzer als auch Institutionen Ethereum nutzen können, ohne jede Aktivität öffentlich sichtbar zu machen – während Transparenz und Verifizierbarkeit des öffentlichen Netzwerks erhalten bleiben.

Kurz gesagt: In dieser Roadmap wird Privatsphäre nicht als einzelnes Feature betrachtet, sondern als Eigenschaft des gesamten Systems – vom Konsensmechanismus über Transaktionen bis hin zur Wallet‑Software.