Heuristiken im Kontenmodell

Kontenbasierte Blockchains wie Ethereum bieten Analysten keines der beiden bewährten Bitcoin-Werkzeuge: Jede Transaktion hat genau einen Absender, und Guthaben verbleiben auf demselben Konto. Es gibt daher weder gemeinsam ausgegebene Inputs noch Wechselgeld-Outputs. Nutzer können dennoch beliebig viele Adressen erstellen, und viele tun dies auch. Das Clustering auf diesen Blockchains stützt sich auf Verhaltensmuster im Zusammenhang mit Diensten, Token und Verträgen; die Belege sind schwächer und weniger validiert als bei UTXO-Blockchains.

Was sich im Kontenmodell ändert

Auf einer kontenbasierten Blockchain bildet eine einzelne Adresse häufig die gesamte Historie eines Nutzers ab. Dadurch ist jede Adresse aussagekräftiger, doch es gibt keine systembedingte Regel, um sie mit einer anderen zu verknüpfen. Victor (2020, „Heuristiken zur Adressclusterbildung für Ethereum“) schlug drei Heuristiken vor: Wiederverwendung von Einzahlungsadressen, Airdrop-Mehrfachteilnahme (mehrere Adressen, die jeweils einen Token-Airdrop beanspruchen und die Token anschließend an eine gemeinsame Adresse weiterleiten) und Selbstautorisierung durch Token-Freigaben. Er stellte fest, dass sich damit über die ersten vier Jahre von Ethereum hinweg 17,9 % aller aktiven extern kontrollierten Konten (EOAs) zu Clustern zusammenfassen ließen. Die Veröffentlichung räumt offen ein, dass keine gesicherten Referenzdaten zur Verfügung standen, anhand derer sich die Genauigkeit messen ließ. Eine spätere Open-Source-Studie zum Datenschutz bei Ethereum und Tornado Cash (Wu et al., 2022) wandte die stärkste der drei Heuristiken an, die Wiederverwendung von Einzahlungsadressen, und gruppierte 26 Millionen EOAs in 2,5 Millionen Cluster. Bei der Überprüfung anhand von 1.028 Clustern, die aus Namensdienst-Einträgen abgeleitet wurden, betrug die Trefferquote (Recall) 39,4 %. Dies sind die am besten dokumentierten verfügbaren Zahlen. Sie zeigen, dass die meisten Verknüpfungen nicht erkannt werden und die Präzision weitgehend ungemessen ist.

Die folgenden Heuristiken sind ungefähr von der stärksten bis zur schwächsten geordnet.

Wiederverwendung von Einzahlungsadressen

Viele verwahrende Börsen weisen jedem Kunden eine eindeutige Einzahlungsadresse zu und überführen deren Guthaben regelmäßig in eine Hot Wallet (siehe die Lektion Nachverfolgung über Börsen und verwahrende Dienste). Wenn zwei EOAs beide Gelder an dieselbe Einzahlungsadresse senden, werden diese wahrscheinlich demselben Kundenkonto gutgeschrieben. Daher werden die EOAs wahrscheinlich von derselben Person oder Organisation kontrolliert. Dies ist Victors Einzahlungsadressen-Heuristik, die ergiebigste der Regeln für das Kontenmodell.

Einzahlungsadressen sind on-chain nicht gekennzeichnet und müssen daher erschlossen werden: Eine Adresse empfängt Gelder und leitet kurz darauf nahezu denselben Betrag an eine bekannte Wallet einer Börse weiter.

-- Potenzielle Einzahlungsadressen und die dadurch verknüpften Absender
WITH forwards AS (           -- transfers: eine Zeile pro ETH- oder Token-Bewegung
  SELECT t_in.to_address   AS deposit_addr,
         t_in.from_address AS sender
  FROM transfers t_in
  JOIN transfers t_out
    ON t_out.from_address = t_in.to_address
   AND t_out.block_number BETWEEN t_in.block_number
                              AND t_in.block_number + 2000
  JOIN labels hw
    ON hw.address = t_out.to_address AND hw.category = 'exchange_hot_wallet'
  LEFT JOIN labels svc
    ON svc.address = t_in.from_address
  WHERE svc.address IS NULL          -- Absender dürfen keine bekannten Dienste sein
)
SELECT deposit_addr, COUNT(DISTINCT sender) AS linked_senders
FROM forwards
GROUP BY deposit_addr
HAVING COUNT(DISTINCT sender) >= 2;

Die Abfrage ordnet jeder eingehenden Übertragung eine ausgehende Übertragung von derselben Adresse an eine gekennzeichnete Hot Wallet einer Börse innerhalb von 2.000 Blöcken zu, schließt Absender aus, die selbst bekannte Dienste sind, und behält Einzahlungsadressen bei, die von mindestens zwei Absendern genutzt werden. Eine für den produktiven Einsatz geeignete Version prüft außerdem, ob der weitergeleitete Betrag annähernd dem empfangenen Betrag entspricht und ob die Adresse über die Zeit hinweg beständig weiterleitet. Das Zeitfenster von 2.000 Blöcken ist eine zu dokumentierende Annahme, kein Standard.

Fehlerquellen: Eine Person zahlt auf das Börsenkonto eines Freundes oder ihres Arbeitgebers ein; Zahlungsabwickler und OTC-Handelsstellen zahlen im Auftrag von Kunden ein; Börsen weisen Einzahlungsadressen neu zu oder nutzen sie für mehrere Kunden; eine gewöhnliche Weiterleitungsadresse wird fälschlich als Einzahlungsadresse gekennzeichnet.

Muster der Gas-Finanzierung

Ein neu angelegtes EOA benötigt die native Währung, um Gas zu bezahlen, bevor es überhaupt aktiv werden kann. Seine erste eingehende Übertragung stammt häufig vom selben Betreiber. Wenn also viele neu angelegte EOAs innerhalb eines kurzen Zeitfensters von einer Adresse mit ähnlichen Beträgen finanziert werden und anschließend ähnliche Aktivitäten zeigen, deutet dies auf gemeinsame Kontrolle hin. Airdrop-Teams nutzen dieses Muster, um gefälschte Teilnehmer zu erkennen. Auch bei der Untersuchung von Exploits ist es ein nützlicher Ermittlungsansatz (siehe die Lektion Analyse von Exploits und Hacks).

Die Schwäche besteht darin, dass der Geldgeber häufig ein Dienst ist. Auszahlungs-Wallets von Börsen, Bridges und Faucets finanzieren enorme Mengen nicht miteinander verbundener Nutzer. Geldgeber müssen deshalb anhand von Dienstkennzeichnungen überprüft werden, bevor eine Verknüpfung hergestellt wird. Gas-Sponsoring hebt den Zusammenhang vollständig auf: Unter ERC-4337 kann ein Paymaster für die Vorgänge eines Nutzers bezahlen. Seit EIP-7702 (aktiviert im Mai 2025) kann ein EOA an Code delegieren und seine Transaktionen von einem Sponsor einreichen und bezahlen lassen. Die Lektion Das Kontenmodell und die Rekonstruktion von Guthaben erläutert, warum die Identität des Gas-Zahlers und die des Unterzeichners getrennte Fragen sind.

Token-Freigaben

Ein ERC-20-Aufruf von approve erlaubt einem Verfügungsberechtigten, Token aus dem Guthaben des Eigentümers zu bewegen, und löst ein Approval-Ereignis aus:

{
  "address": "0x7d1a…c3E0",
  "topics": [
    "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
    "0x000000000000000000000000a1b2…009f",
    "0x000000000000000000000000c4d5…77e2"
  ],
  "data": "0x…ffffffff"
}

Das erste Topic ist der Hash der Ereignissignatur von Approval(address,address,uint256), das zweite der Eigentümer, das dritte der Verfügungsberechtigte und das Datenfeld der freigegebene Betrag. Die meisten Freigaben benennen einen Vertrag, etwa einen DEX-Router. Victors Heuristik der Selbstautorisierung verknüpft einen Eigentümer mit einem Verfügungsberechtigten, wenn dieser ein anderes EOA ist. Die Begründung lautet, dass Menschen der persönlichen Adresse eines Fremden nur selten erlauben, über ihre Token zu verfügen.

Die schwerwiegende Fehlerquelle ist Betrug. Beim Freigabe-Phishing werden Opfer dazu verleitet, einer vom Angreifer kontrollierten Adresse eine Freigabe zu erteilen. Diese Freigaben sehen genauso aus wie eine Selbstautorisierung. Prüfen Sie vor einer Verknüpfung, ob der Verfügungsberechtigte das Guthaben des Eigentümers kurz darauf geleert hat. Falls ja, besteht die Verbindung zwischen Opfer und Dieb, nicht innerhalb desselben Eigentümers.

Verknüpfungen über Vertragsbereitsteller

Jeder Vertrag hat einen Ersteller. Bei CREATE wird die Adresse des neuen Vertrags aus der Adresse und der Nonce des Bereitstellers abgeleitet; bei CREATE2 (EIP-1014) aus dem bereitstellenden Vertrag, einem Salt und dem Hash des Initialisierungscodes. Verträge, die vom selben EOA bereitgestellt wurden, gehören häufig demselben Team, und der Bereitsteller eines Exploit-Vertrags ist üblicherweise ein zentraler Knoten im Cluster des Angreifers.

Fehlerquellen: öffentliche Factory-Verträge, die jeder verwenden kann (die Factory, nicht der Nutzer, erscheint als Ersteller), Bereitstellungsdienste, kompromittierte Schlüssel von Bereitstellern und kopierter Open-Source-Code. Identischer Bytecode belegt gemeinsamen Code, nicht gemeinsame Kontrolle.

Zeitmuster, Nonce und Namenssignale

Zeitmuster. Adressen, die von derselben Person oder demselben Bot betrieben werden, weisen häufig ein ähnliches tägliches Aktivitätsmuster auf, agieren innerhalb derselben Blöcke oder wechseln sich in einem festen Rhythmus ab. Béres et al. (2020, „Die Blockchain beobachtet Sie: Profilbildung und Deanonymisierung von Ethereum-Nutzern“) verwendeten Tageszeitprofile und Gebühreneinstellungen als Quasi-Identifikatoren. Gebühreneinstellungen wurden nach EIP-1559 (August 2021) deutlich weniger charakteristisch, als die meisten Wallets begannen, Gebühren automatisch zu berechnen.

Nonce. Die Nonce eines EOA zählt die von ihm gesendeten Transaktionen. Nonce-Folgen zeigen, wie aktiv eine Adresse ist und in welcher Reihenfolge ihre Aktionen stattfanden. Mehrere Adressen, deren Nonces sich im Gleichschritt erhöhen und die jeweils pro Runde eine Transaktion in einer festen Reihenfolge senden, deuten darauf hin, dass sie von einem einzigen Skript gesteuert werden.

Namensdienste. ENS verknüpft Namen mit Adressen über Vorwärtseinträge (Name zu Adresse) und optionale Rückwärtseinträge (Adresse zu primärem Namen). Ein Rückwärtseintrag wird vom Adressinhaber gesetzt und ist daher eine Selbstauskunft. Bestätigen Sie, dass der Vorwärtseintrag des Namens auf dieselbe Adresse zurückverweist. Namen laufen ab und können von jemand anderem erneut registriert werden. Dokumentieren Sie deshalb den Block, bei dem Sie die Verknüpfung beobachtet haben. Viele Namen sind personenbezogen; behandeln Sie sie wie in der Lektion Von der Adresse über die Entität zur Person: Attribution und Kennzeichnung beschrieben.

Besondere Fallstricke bei kontenbasierten Blockchains

Bilden Sie niemals Cluster anhand des Feldes from von Transaktionen, die über gemeinsam genutzte Infrastruktur gesendet werden. Ein ERC-4337-Bundler reicht eine Transaktion ein, die Vorgänge vieler nicht miteinander verbundener Nutzer enthält; Relayer und Meta-Transaktionsdienste tun dasselbe. Würden Sie alles verknüpfen, was ein Bundler oder Relayer gesendet hat, würden Tausende von Nutzern zusammengeführt. Dasselbe gilt für Verträge, die Gelder vieler Nutzer halten, etwa DEX-Pools und Bridges.

Smart-Contract-Wallets bringen eine weitere Besonderheit mit sich. Eine Multisig-Vertrags-Wallet ist eine einzelne Adresse, die von mehreren Unterzeichner-EOAs kontrolliert wird, deren Liste sich aus dem Zustand des Vertrags auslesen lässt. Die Unterzeichner arbeiten zusammen, können aber unterschiedliche Personen sein. Behandeln Sie die Wallet als Entität und die Unterzeichner als verbundene Parteien, nicht als ein einziges Cluster.

Da jedes Signal im Kontenmodell für sich genommen schwach ist, besteht eine solide Vorgehensweise darin, vor dem Herstellen einer Verknüpfung zwei unabhängige Signale zu verlangen, beispielsweise Gas-Finanzierung durch eine Adresse, die keinem Dienst gehört, in Verbindung mit zeitlichen Aktivitäten im Gleichschritt. Dokumentieren Sie beide Signale mit ihrer jeweiligen Aussagekraft in der Beweistabelle.

Prüfungsschwerpunkt: Warum bei kontenbasierten Blockchains Heuristiken zu gemeinsamen Inputs und Wechselgeld fehlen; Victors drei Heuristiken (Wiederverwendung von Einzahlungsadressen, Airdrop-Mehrfachteilnahme, Selbstautorisierung) und warum ihre Genauigkeit weitgehend ungemessen ist (17,9 % Abdeckung ohne gesicherte Referenzdaten, 39,4 % Trefferquote für die Wiederverwendung von Einzahlungsadressen); Erschließen von Einzahlungsadressen anhand der Weiterleitung an Hot Wallets; Gas-Finanzierung und warum Dienste als Geldgeber, Paymaster und EIP-7702-Sponsoren den Zusammenhang aufheben; Lesen eines Approval-Logs und die falsch-positive Zuordnung durch Freigabe-Phishing; Verknüpfungen über Bereitsteller bei CREATE und CREATE2 sowie Fallstricke bei Factory-Verträgen; Belege aus Zeitmustern, Nonces und ENS sowie deren Grenzen; niemals Cluster anhand der Absenderadresse eines Bundlers oder Relayers bilden.