Mixer, CoinJoin und Privacy-Coins · Lektion 3 von 5
Smart-Contract-Mixer
8 Min. Lesezeit
Ein Smart-Contract-Mixer hinterlässt einen vollständigeren öffentlichen Datensatz als jeder Verwahrungsdienst: Jede Einzahlung und jede Auszahlung ist ein Ereignis, das jeder entschlüsseln kann. Entfernt wird die eine Information, die Ermittler wissen wollen: die Verbindung zwischen beiden. Dies geschieht mit Kryptografie statt mit einer Datenbank, die beschlagnahmt werden kann. In dieser Lektion geht es darum, was die Aufzeichnungen des Vertrags belegen, wie veröffentlichte Verknüpfungsheuristiken funktionieren und wie verlässlich sie sind sowie wo sich die Belege befinden, die eine Verbindung tatsächlich klären: Notes, Relayer und Front-Ends.
Tornado Cash aus beweisrechtlicher Sicht
Tornado Cash ist das Referenzdesign. Jeder Pool ist ein Vertrag, der einen festen Betrag annimmt; die ETH-Pools nehmen 0,1, 1, 10 oder 100 ETH an, und Token-Pools gibt es für Vermögenswerte wie DAI, USDC, USDT und WBTC. Die Pool-Verträge können weder pausiert noch aktualisiert werden. Die Funktionsweise wird in der IDFE-BA-Lektion Mixer, CoinJoin und Verschleierung in Graphen beschrieben; hier geht es darum, was die einzelnen Aufzeichnungen belegen.
| Aufzeichnung | Wichtige Felder | Was sie belegt | Was sie nicht belegt |
|---|---|---|---|
Aufruf von deposit(bytes32 _commitment) und Deposit-Ereignis | commitment, leafIndex, timestamp, Absender der Transaktion | Diese Adresse hat den Pool-Betrag eingezahlt und dieses Commitment registriert | Wer später ausgezahlt hat |
Aufruf von withdraw(...) | Proof, Merkle-Root, nullifierHash, Empfänger, Relayer, Gebühr, Rückerstattung | Für eine nicht ausgegebene Einzahlung im Baum wurde ein gültiger Proof vorgelegt | Welche Einzahlung |
Withdrawal-Ereignis | to, nullifierHash, relayer, fee | Dieser Empfänger hat den Betrag abzüglich der Gebühr erhalten; dieser Relayer, falls vorhanden, wurde bezahlt | Wer die Auszahlung angefordert hat |
Die Software des Einzahlers erzeugt zwei Geheimnisse: einen Nullifier und einen Zufallswert. Das Commitment ist ein Hash aus beiden; der Nullifier-Hash ist ein Hash des Nullifiers allein. Der Nutzer bewahrt beide Geheimnisse als Note auf, einer Zeichenfolge wie tornado-eth-0.1-1-0x…, die die Währung, den Betrag, die Chain-ID und die Geheimnisse codiert. Der Vertrag zeichnet jeden Nullifier-Hash auf und lehnt eine zweite Auszahlung mit demselben Wert ab. Wer die Note besitzt, kann auszahlen; die Note ist praktisch ein Inhaberschlüssel.
Die Anonymitätsmenge und ihre Darstellung
Bei einer bestimmten Auszahlung kommen die Einzahlungen infrage, die zuvor in denselben Pool getätigt wurden. Zwei Zahlen beschreiben diese Menge sachgerecht, und dekodierte Ereignistabellen liefern beide:
-- Anonymitätsmenge für eine Auszahlung aus dem 10-ETH-Pool bei Block 15.200.000
SELECT
(SELECT COUNT(*) FROM tc_deposits
WHERE pool = 'ETH-10' AND block_number < 15200000) AS prior_deposits,
(SELECT COUNT(*) FROM tc_withdrawals
WHERE pool = 'ETH-10' AND block_number < 15200000) AS prior_withdrawals;
Die erste Unterabfrage zählt jede Einzahlung vor dem Auszahlungsblock: Jede davon kommt infrage, denn der Vertrag legt nie offen, welche Einzahlungen bereits ausgegeben wurden. Die zweite zählt frühere Auszahlungen. Die Differenz ist die Zahl der zu diesem Zeitpunkt noch nicht ausgegebenen Einzahlungen und damit die praktische Größe des Pools. Berichten Sie beide Werte zusammen mit dem Pool, dem Block und der Datenquelle. Die Tabellennamen hier dienen nur der Veranschaulichung; erstellen Sie die Tabellen anhand der Logs des Pool-Vertrags, gefiltert nach Ereignissignatur (siehe die IDFE-BA-Lektion EVM-Logs und Traces abfragen).
Verknüpfungsheuristiken in veröffentlichten Forschungsarbeiten
Forschende haben gemessen, wie oft Nutzer die Verbindung selbst preisgeben. Die am häufigsten zitierten Heuristiken:
| Heuristik | Logik | Stärke und Vorbehalte |
|---|---|---|
| Adressübereinstimmung | Dieselbe Adresse zahlt ein und zahlt aus | Nahezu deterministisch hinsichtlich der Kontrolle; prüfen Sie dennoch, ob es sich um gemeinsam genutzte oder verwahrte Adressen handelt |
| Verknüpfte Adressen | Einzahler- und Empfängeradressen haben außerhalb des Mixers miteinander Transaktionen durchgeführt (Tutela verwendete drei oder mehr solcher Transaktionen) | Stark, wenn die Interaktionen direkt und wiederholt sind |
| Gasfinanzierung | Der Einzahler oder eine von ihm finanzierte Adresse bezahlt das Gas für die Auszahlungsadresse | Starkes Muster; Gas-Anbieter und gemeinsame Geldgeber erzeugen falsche Verknüpfungen |
| Mehrere Stückelungen | Eine ungewöhnliche Kombination von Einzahlungen über verschiedene Pools hinweg (zum Beispiel 3 × 10 ETH und 1 × 1 ETH) stimmt mit derselben Kombination von Auszahlungen innerhalb von etwa einem Tag überein | Probabilistisch; wird schwächer, wenn die Aktivität im Pool zunimmt |
| Einzigartiger Gaspreis | Bei Einzahlung und Auszahlung wurde derselbe ungewöhnliche, vom Nutzer festgelegte Gaspreis verwendet | Nur vor der Änderung des Gebührenmarkts im August 2021 (EIP-1559) und nur bei Auszahlungen ohne Relayer |
| Zeitpunkt | Eine Auszahlung kurz nach einer Einzahlung in einem wenig genutzten Pool | Für sich genommen schwach; nützlich, um die Kandidatenmenge einzugrenzen |
| Belohnungsansprüche | Ansprüche im Rahmen des Belohnungsprogramms für Anonymitäts-Mining (Dezember 2020 bis Dezember 2021) zeigten, wie lange eine Einzahlung im Pool blieb | Eng begrenzt; betrifft nur Nutzer, die Ansprüche geltend machten |
Zwei Studien veranschaulichen das Ausmaß. Tutela (Wu und Kollegen, 2022) markierte etwa 42.800 von 97.300 Einzahlungen, ungefähr 44 %, als durch mindestens eine Heuristik potenziell kompromittiert. Am häufigsten waren verknüpfte Adressen (18.900), Adressübereinstimmung (18.600) und mehrere Stückelungen (16.200). Die Studie schätzte eine durchschnittliche Verringerung der Anonymitätsmengen um 37 % (±15 %). Wang und Kollegen (ACM Web Conference 2023) berichteten durchschnittliche Verringerungen von 27,34 % bei den beliebtesten Ethereum-Mixer-Pools und 46,02 % bei einem vergleichbaren Mixer auf einer anderen Chain. Béres und Kollegen (2021) verwendeten Kennungen von Namensdiensten als teilweise Ground Truth, um Nutzer anhand ihrer Gaspreisgewohnheiten und ihrer Aktivität zu verschiedenen Tageszeiten zu profilieren.
Der entscheidende Punkt für die Beweisführung: Die Autoren von Tutela erklären, dass ihre Heuristiken zu falsch positiven Ergebnissen führen, und berichten von keiner Validierung anhand einer Ground Truth für die Tornado-Cash-Heuristiken. Die veröffentlichten Zahlen zeigen, dass es häufig zu Datenlecks kommt; sie liefern jedoch keine Fehlerquote für eine Verknüpfung in Ihrem Fall. Bewerten Sie eine Verknüpfung anhand einer einzelnen Heuristik je nach Logik mit C oder D und suchen Sie nach Bestätigung durch eine andere Art von Beleg.
Durchgearbeitetes Beispiel. Die Adresse 0xA1b2…9F zahlt innerhalb einer Stunde 3 × 10 ETH und 1 × 1 ETH ein. Neunzehn Stunden später erhält die neue Adresse 0x5cE0…71 über einen Relayer drei Auszahlungen aus dem 10-ETH-Pool und eine aus dem 1-ETH-Pool, jeweils abzüglich der Gebühr des Relayers. Bei ihrer ersten ausgehenden Transaktion zahlt sie an eine Einzahlungsadresse einer Börse. Die untersuchende Person zählt, wie viele andere Adressen in den vorangegangenen 48 Stunden dieselbe Kombination eingezahlt haben (keine) und wie viele Auszahlungskombinationen dieser Art es gab (eine). Die Übereinstimmung bei den mehreren Stückelungen wird mit der Bewertung D und den jeweiligen Zahlen dokumentiert; die Unterlagen der Börse zur Einzahlungsadresse werden angefordert. Zeigen sie denselben Kunden, der 0xA1b2…9F finanziert hat, steigt die Bewertung der Verknüpfung auf B.
Notes: der Beleg, der eine Verbindung klärt
Eine Note, die im Rahmen einer rechtmäßigen Maßnahme gefunden wird, leistet, was keine Heuristik kann. Anhand der Geheimnisse in der Note berechnet die untersuchende Person das Commitment neu, das das Deposit-Ereignis identifiziert, sowie den Nullifier-Hash, der das Withdrawal-Ereignis identifiziert, sofern eines existiert. Das ergibt eine deterministische und unabhängig reproduzierbare Verbindung vom Einzahler zum Empfänger. Enthält keine Auszahlung diesen Nullifier-Hash, befindet sich die Einzahlung weiterhin im Pool und die Note kontrolliert sie nach wie vor; sie zu sichern ist dann eine Frage der Rückgewinnung von Vermögenswerten (siehe die Lektionen Optionen zum Einfrieren und zur Beschlagnahme und Beschlagnahmte Krypto-Vermögenswerte sichern).
Fundorte von Notes:
- Textdateien, einschließlich Sicherungsdateien, die der Befehlszeilen-Client beim Erstellen einer Note schreibt;
- Passwortmanager, Notiz-Apps, Screenshots, Chatnachrichten an sich selbst und Papier;
- verschlüsselte Sicherungskopien, die die Schnittstelle über ein „Note-Konto“ auf der Chain speichern könnte und die mit dem Schlüssel des Kontos lesbar sind;
- Berichte des Compliance-Tools der Schnittstelle, das ausgehend von einer Note ein Dokument mit Angaben zu deren Einzahlung und Auszahlung erstellt hat.
Behandeln Sie eine Note wie einen privaten Schlüssel (siehe die Lektionen Wallets auf beschlagnahmten Geräten und Hashing, Protokollierung und Beweismittelkette). Fügen Sie sie niemals in eine gehostete Schnittstelle oder eine Website eines Drittanbieters ein: Jeder, der sie sieht, kann nicht ausgegebene Mittel abheben. Berechnen Sie die Werte mit Open-Source-Code auf einem isolierten Untersuchungsrechner neu, dokumentieren Sie die Softwareversion und den Hash und lassen Sie die Berechnung von einer zweiten untersuchenden Person wiederholen.
Relayer und Front-Ends
Das Withdrawal-Ereignis nennt den Relayer und dessen Gebühr; die Relayer-Adresse ist daher eine deterministische Tatsache. Relayer sind unabhängige Betreiber. Registrierte Relayer hinterlegen Governance-Token in einem On-Chain-Register, das von der Schnittstelle ausgelesen wird; die Pools bezahlen jedoch jeden Relayer, der in einer Auszahlung genannt wird. Ein Relayer erhält die Auszahlungsanfrage über das Netzwerk und kann Protokolle zu den Anfragezeitpunkten und Netzwerkadressen aufbewahren, falls er solche führt. Betrachten Sie ihn als möglichen Inhaber von Aufzeichnungen, ermitteln Sie anhand von Register- und Namensdatensätzen den Betreiber und gehen Sie davon aus, dass viele hinter Anonymisierungsnetzwerken operieren oder nichts aufbewahren.
Das Front-End besteht aus separatem Code, der über dezentralen Speicher und Gateways bereitgestellt wird und sich ändert. Anfang 2024 fügte ein böswilliger Governance-Vorschlag dem über IPFS-Gateways bereitgestellten Code der Schnittstelle Funktionen hinzu, die Notes vom 1. Januar 2024 bis zum Zeitpunkt der Entdeckung an einen externen Server sendeten. Daraus folgen zwei Lehren: Dokumentieren Sie, welche Schnittstellenversion und welches Gateway eine Person verwendet hat (Browser-Verlauf, Verbindungsprotokolle der Wallet-Erweiterung), und bedenken Sie, dass sich eine Note auch in den Händen einer anderen Person befinden kann.
Eine Behörde sanktionierte die Tornado-Cash-Verträge im August 2022 und hob die Einstufung im März 2025 auf; die Verträge funktionierten während des gesamten Zeitraums weiter (siehe die IDFE-CC-Lektion Wallet- und Transaktionsprüfung).
Prüfungsschwerpunkt: Was dieDeposit- undWithdrawal-Ereignisse sowie die Parameter vonwithdrawbelegen und was nicht; Commitment, Nullifier-Hash und Note als Inhaberschlüssel; die Angabe früherer und nicht ausgegebener Einzahlungen als Anonymitätsmenge; Heuristiken zu Adressübereinstimmung, verknüpften Adressen, Gasfinanzierung, mehreren Stückelungen, einzigartigem Gaspreis, Zeitpunkt und Belohnungsansprüchen einschließlich ihrer Vorbehalte; Tutela (etwa 44 % der Einzahlungen markiert, durchschnittliche Verringerung um 37 %) und Wang et al. (27,34 %) sowie das Fehlen validierter Fehlerquoten; eine gefundene Note als deterministische Verknüpfung, Fundorte von Notes und deren sichere Handhabung; Belege zu Relayern und Front-Ends.