EIP-8182-Entwurf schlägt native Ethereum-Privacy-Transfers vor

Ein neuer Entwurf von EIP-8182 will private Transfers zu einer erstklassigen Funktion von Ethereum machen, nicht zu einer App, die man nachträglich anbinden muss. Der Vorschlag, den Entwickler Tom Lehman diese Woche veröffentlicht hat, würde gemeinsame Privacy Pools und Zero-Knowledge-Proof-Verifizierung durch einen Hard Fork direkt ins Basisprotokoll integrieren. Kein Admin-Schlüssel. Kein Governance-Token. Keine Upgrade-Hintertür.

Was EIP-8182 tatsächlich auf Protokollebene bewirkt

Ohne den Fachjargon ist das Design simpel. EIP-8182 führt einen einzelnen System-Contract mit fester Adresse ein, den jeder auf Ethereum als geschützten Pool nutzen kann, plus eine kleine Reihe neuer Precompiles, mit denen die EVM Zero-Knowledge-Proofs kostengünstig verifizieren kann. Nutzer zahlen in den Pool ein, führen darin private Transaktionen durch und können an jede normale Ethereum-Adresse oder jeden ENS-Namen auszahlen, wenn sie mit dem Rest der Chain interagieren wollen.

Was den Vorschlag von jeder bisherigen Privacy-App unterscheidet, ist das Fehlen eines Wrappers. Es gibt keinen separaten Token, keinen upgradefähigen Contract in der Mitte, kein Team, das eine Multisig über Nutzergelder hält. Der Pool existiert ab dem Moment des Hard Fork an einer fest codierten Adresse, und von da an verhält er sich wie jeder andere Teil von Ethereum: unveränderlich, neutral und außerhalb der Kontrolle einer einzelnen Partei.

Genau auf diesen letzten Punkt setzt Lehman am stärksten. Privacy-Tools, die als eigenständige Apps gebaut wurden, wurden in den letzten drei Jahren sanktioniert, von Listen gestrichen oder still aufgegeben, weil Regulierungsbehörden gegen die Betreiber vorgingen. Ein Precompile kann nicht auf dieselbe Weise sanktioniert werden. Es gibt keinen Betreiber.

Wer ist Tom Lehman und warum ist dieser Entwurf wichtig?

Der Autor ist Tom Lehman, ein Ethereum-Entwickler, der am 24. April den formellen Diskussionsthread im Ethereum Magicians Forum eröffnet hat. Das Forum ist der Ort, an dem jedes ernsthafte EIP von Core-Entwicklern, Client-Teams und Forschern auseinandergenommen wird, bevor es auch nur die Chance hat, in einen Hard Fork aufgenommen zu werden. Dort zu posten ist gleichbedeutend mit der Aussage, dass man bereit ist, den Vorschlag öffentlich zu verteidigen.

Der Entwurf ist wegen des Timings von Bedeutung. Privacy auf Ethereum ist seit Jahren stillschweigend gescheitert. Tornado Cash wurde 2022 sanktioniert. Aztec Network hat seinen öffentlichen Mainnet-Rollup im März 2024 eingestellt. Railgun und eine Handvoll kleinerer Shielded-Pool-Projekte existieren noch, aber jedes davon ist eine separate App mit eigener Liquidität, eigenen Vertrauensannahmen und einer eigenen Zielscheibe auf dem Rücken. Das Ergebnis ist eine Chain, auf der jede Überweisung über Kleingeld die komplette Finanzhistorie des Absenders an jeden mit einem Block Explorer preisgibt.

Privacy ist keine Anwendung. Es ist eine Eigenschaft des Systems. EIP-8182 behandelt sie zum ersten Mal als solche.

Wie gemeinsame Privacy Pools das Anonymitätsmengen-Problem lösen

Die technische Grundlage hier ist nicht neu. Das Modell des gemeinsamen Pools geht auf ein Paper von 2023 zurück, verfasst von Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schär und Ameen Soleimani mit dem Titel "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium." Dieses Paper führte die Idee der Privacy Pools ein, bei denen Nutzer kryptographisch nachweisen, dass ihre Einzahlungen nicht aus einer bekannten illegalen Menge stammen, während der Rest ihrer Aktivitäten privat bleibt.

Anonymität in Privacy-Systemen ist ein Zahlenspiel. Je größer die Menge der Nutzer, die sich im selben Pool verbergen, desto schwieriger ist es, eine einzelne Transaktion zurückzuverfolgen. Verteilt man diese Menge auf zehn verschiedene Apps, geht die Mathematik nicht mehr auf, weil die Menge jeder einzelnen App zu klein ist. Konzentriert man sie hingegen in einem einzigen geschützten Pool, der fest ins Protokoll eingebaut ist, trägt jeder Ethereum-Nutzer, der jemals Privacy haben will, zur selben Anonymitätsmenge bei.

Das ist der entscheidende Durchbruch. Nicht die Kryptographie, die gibt es seit Jahren. Sondern die Vereinheitlichung.

• Einzelner geschützter Pool an einer festen System-Contract-Adresse, gemeinsam genutzt von allen Ethereum-Nutzern
• Zero-Knowledge-Precompiles in der EVM, sodass die Proof-Verifizierung günstig genug ist, um in Standard-Transaktionen ausgeführt zu werden
• Atomare Shield-, Interact- und Reshield-Abläufe, die es Nutzern ermöglichen, die Privacy vorübergehend aufzuheben, um mit einem DeFi-Protokoll zu interagieren, und dann in derselben Transaktion wieder in den Pool einzutreten
• Kein Upgrade-Pfad, kein Admin-Schlüssel, kein Governance-Token: Der Contract wird beim Hard Fork festgelegt und ändert sich nie

Werden Regulierungsbehörden das zulassen?

Ehrliche Antwort: Genau darum wird gekämpft. Einen geschützten Pool auf Protokollebene einzubetten, ist die aggressivste Wette auf glaubwürdige Neutralität, die die Ethereum-Community seit The Merge eingegangen ist. Es gibt kein Unternehmen zum Sanktionieren, keinen Gründer zum Vorladen, keinen Upgrade-Schlüssel zum Erzwingen. Will eine Regulierungsbehörde die Funktion entfernen, muss sie jeden Node-Betreiber im Netzwerk davon überzeugen, sie per Fork herauszunehmen, und das ist auf Ethereum noch nie passiert.

Der Vorschlag enthält den Compliance-Mechanismus aus dem ursprünglichen Buterin-Paper. Nutzer können freiwillig nachweisen, dass ihre Einzahlungen nicht Teil einer sanktionierten Menge sind, was Börsen und On-Ramps die Möglichkeit gibt, Auszahlungen aus dem Pool zu akzeptieren, ohne gestohlene Gelder aufzunehmen. Das ist die "Practical Equilibrium"-Hälfte des Titels des akademischen Papers, und es ist der Grund, warum dieses Design eine reale Chance hat, den politischen Kampf zu überleben, der Tornado Cash den Todesstoß versetzt hat.

Was als Nächstes auf dem Weg zum Hard Fork passiert

Entwürfe sind billig. Hard Forks nicht. EIP-8182 durchläuft nun denselben monatelangen Prüfungsprozess, den jede Änderung auf Konsensebene bestehen muss: Review auf Ethereum Magicians, Feedback von Client-Teams (Geth, Nethermind, Besu, Erigon, Reth), Sicherheitsanalyse durch die Privacy- und Scaling-Forschungsgruppe der Ethereum Foundation, und schließlich die Entscheidung, in welchen Fork er aufgenommen wird.

Der nächste geplante Hard Fork ist Glamsterdam, voraussichtlich Ende 2026. Danach wird Amsterdam für 2027 erwartet. Realistisch betrachtet kämpft EIP-8182 frühestens um einen Platz in Amsterdam. Privacy-Vorschläge werden grundsätzlich strenger geprüft als Performance-Vorschläge, und ein System-Contract an einer festen Adresse ohne Upgrade-Pfad bedeutet, dass jede Zeile beim ersten Mal stimmen muss. Nachträglich patchen geht nicht.

Falls er ausgeliefert wird, reichen die Auswirkungen weit über das Ethereum-Mainnet hinaus. Jede L2, die von Ethereums Execution Layer erbt, darunter Base, Arbitrum, Optimism und die Dutzende dahinter, würde native private Transfers erhalten, sobald sie ihre EVM-Version aktualisiert. Das sind Hunderte Millionen Nutzer, die downstream Privacy als Standard-Eigenschaft der Chain bekommen, statt sie als Feature aktiv wählen zu müssen.

Warum dies der wichtigste Privacy-Vorschlag ist, den Ethereum je gesehen hat

Man kann es ambitioniert nennen oder überfällig. So oder so ist EIP-8182 der erste ernsthafte Versuch, Ethereums Privacy-Problem auf der Ebene zu lösen, auf der es tatsächlich existiert. Jeder vorherige Versuch war ein Workaround. Dieser hier ist eine Neudefinition der Annahme, dass öffentliche Chains eine vollständig öffentliche Historie erfordern.

Ob er 2026, 2027 oder nie kommt, die Diskussion hat nun in dem Raum begonnen, in dem Ethereums tatsächliche Regeln geschrieben werden. Das allein ist bereits ein Wendepunkt.