Heuristiques du modèle de comptes

Les chaînes fondées sur des comptes, telles qu’Ethereum, ne fournissent à l’analyste aucun des deux outils incontournables de Bitcoin : chaque transaction possède exactement un expéditeur, et les soldes restent dans le même compte ; il n’y a donc ni entrées dépensées conjointement ni sorties de monnaie rendue. Les utilisateurs peuvent néanmoins créer autant d’adresses qu’ils le souhaitent, et beaucoup le font. Le regroupement sur ces chaînes repose sur les comportements liés aux services, aux jetons et aux contrats, et les éléments probants sont plus faibles et moins validés que sur les chaînes UTXO.

Ce qui change dans le modèle de comptes

Sur une chaîne fondée sur des comptes, une seule adresse contient souvent tout l’historique d’un utilisateur, ce qui rend chaque adresse plus riche en informations, mais ne fournit aucune règle intrinsèque pour la relier à une autre. Victor (2020, « Heuristiques de regroupement d’adresses pour Ethereum ») a proposé trois heuristiques : la réutilisation d’adresses de dépôt, la participation multiple à un airdrop (plusieurs adresses qui réclament chacune un airdrop de jetons, puis transfèrent ces jetons vers une même adresse) et l’auto-autorisation au moyen d’approbations de jetons. Il a constaté que, sur les quatre premières années d’Ethereum, elles permettaient de regrouper 17,9 % de tous les comptes détenus en externe (EOA) actifs. L’article reconnaît clairement qu’aucune vérité terrain ne permettait de mesurer leur exactitude. Une étude ultérieure en sources ouvertes sur la confidentialité d’Ethereum et de Tornado Cash (Wu et al., 2022) a appliqué la plus solide des trois, la réutilisation d’adresses de dépôt, et a obtenu 26 millions d’EOA répartis en 2,5 millions de groupes ; évalué par rapport à 1 028 groupes issus d’enregistrements de services de noms, son rappel était de 39,4 %. Ce sont les chiffres disponibles les mieux documentés, et ils montrent que la plupart des liens ne sont pas détectés et que la précision reste largement non mesurée.

Les heuristiques ci-dessous sont présentées approximativement de la plus solide à la plus faible.

Réutilisation d’adresses de dépôt

De nombreuses plateformes d’échange dépositaires attribuent à chaque client une adresse de dépôt unique et centralisent périodiquement son solde dans un portefeuille à chaud (voir la leçon Suivi des fonds à travers les plateformes d’échange et les services dépositaires). Si deux EOA envoient des fonds à la même adresse de dépôt, ils sont probablement crédités sur le même compte client et, par conséquent, probablement contrôlés par la même personne ou organisation. Il s’agit de l’heuristique des adresses de dépôt de Victor, la plus productive des règles du modèle de comptes.

Les adresses de dépôt ne sont pas étiquetées sur la chaîne ; elles doivent donc être déduites : il s’agit d’une adresse qui reçoit des fonds et transfère presque le même montant vers un portefeuille connu d’une plateforme d’échange peu de temps après.

-- Adresses de dépôt candidates et expéditeurs qu’elles relient
WITH forwards AS (           -- transfers : une ligne par mouvement d’ETH ou de jetons
  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          -- les expéditeurs ne doivent pas être des services connus
)
SELECT deposit_addr, COUNT(DISTINCT sender) AS linked_senders
FROM forwards
GROUP BY deposit_addr
HAVING COUNT(DISTINCT sender) >= 2;

La requête associe chaque transfert entrant à un transfert sortant depuis la même adresse vers un portefeuille à chaud étiqueté d’une plateforme d’échange dans un délai de 2 000 blocs, exclut les expéditeurs qui sont eux-mêmes des services connus et conserve les adresses de dépôt utilisées par au moins deux expéditeurs. Une version destinée à la production vérifie également que le montant transféré est proche du montant reçu et que l’adresse effectue ces transferts de manière régulière dans le temps. La fenêtre de 2 000 blocs est une hypothèse à documenter, et non une norme.

Cas d’échec : une personne versant des fonds sur le compte de plateforme d’échange d’un ami ou de son employeur ; les prestataires de traitement des paiements et les bureaux de négociation de gré à gré qui effectuent des dépôts pour le compte de clients ; les plateformes d’échange qui réattribuent ou partagent des adresses de dépôt ; et l’erreur consistant à étiqueter une simple adresse de transfert comme une adresse de dépôt.

Schémas de financement du gas

Un nouvel EOA a besoin de monnaie native pour payer le gas avant de pouvoir effectuer la moindre opération. Son premier transfert entrant provient souvent du même opérateur ; ainsi, de nombreux nouveaux EOA financés par une seule adresse sur une courte période, avec des montants similaires et une activité ultérieure similaire, suggèrent un contrôle commun. Les équipes chargées des airdrops utilisent ce schéma pour détecter les faux participants, et il constitue une piste utile dans les enquêtes sur l’exploitation de vulnérabilités (voir la leçon Analyse des exploitations de vulnérabilités et des piratages).

La faiblesse de cette approche tient au fait que le financeur est souvent un service. Les portefeuilles de retrait des plateformes d’échange, les ponts et les robinets de distribution financent un très grand nombre d’utilisateurs sans lien entre eux ; il faut donc vérifier les financeurs à l’aide des étiquettes de services avant d’établir un lien. La prise en charge du gas par un tiers rompt entièrement ce lien : avec ERC-4337, un paymaster peut payer les opérations d’un utilisateur, et depuis EIP-7702 (activé en mai 2025), un EOA peut déléguer à du code et faire soumettre et payer ses transactions par un sponsor. La leçon Le modèle de comptes et la reconstitution des soldes explique pourquoi l’identité du payeur du gas et celle du signataire sont deux questions distinctes.

Approbations de jetons

Un appel ERC-20 approve permet à une adresse autorisée à dépenser de déplacer des jetons depuis le solde du propriétaire et émet un événement Approval :

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

Le premier topic est le hachage de la signature de l’événement Approval(address,address,uint256), le deuxième correspond au propriétaire, le troisième à l’adresse autorisée à dépenser, et le champ data au montant autorisé. La plupart des approbations désignent un contrat, tel qu’un routeur de DEX. L’heuristique d’auto-autorisation de Victor relie un propriétaire à une adresse autorisée à dépenser lorsque cette dernière est un autre EOA, au motif que les personnes autorisent rarement l’adresse personnelle d’un inconnu à dépenser leurs jetons.

Le principal cas d’échec est la fraude. L’hameçonnage par approbation incite les victimes à approuver une adresse contrôlée par un attaquant, et ces approbations ressemblent en tous points à une auto-autorisation. Avant d’établir un lien, vérifiez si l’adresse autorisée à dépenser a vidé le compte du propriétaire peu après ; si c’est le cas, il s’agit d’un lien entre une victime et un voleur, et non d’un propriétaire unique.

Liens avec le déployeur de contrats

Chaque contrat possède un créateur. Avec CREATE, l’adresse du nouveau contrat est dérivée de l’adresse et du nonce du déployeur ; avec CREATE2 (EIP-1014), elle est dérivée du contrat qui effectue le déploiement, d’un sel et du hachage du code d’initialisation. Les contrats déployés par le même EOA appartiennent souvent à la même équipe, et le déployeur d’un contrat d’exploitation de vulnérabilité est généralement un nœud clé du groupe d’adresses de l’attaquant.

Cas d’échec : les contrats fabriques publics que tout le monde peut utiliser (c’est la fabrique, et non l’utilisateur, qui apparaît comme créateur), les services de déploiement, les clés de déployeur compromises et le code open source copié. Un bytecode identique indique un code commun, et non un contrôle commun.

Indices liés aux horaires, aux nonces et aux noms

Horaires. Les adresses exploitées par la même personne ou le même robot présentent souvent un schéma d’activité quotidien commun, agissent dans les mêmes blocs ou alternent selon un rythme fixe. Béres et al. (2020, « La blockchain vous observe : profilage et désanonymisation des utilisateurs d’Ethereum ») ont utilisé les profils horaires et les paramètres de frais comme quasi-identifiants. Les paramètres de frais sont devenus beaucoup moins distinctifs après EIP-1559 (août 2021), lorsque la plupart des portefeuilles ont commencé à calculer automatiquement les frais.

Nonce. Le nonce d’un EOA compte les transactions qu’il a envoyées. Les séquences de nonces révèlent le niveau d’activité d’une adresse et l’ordre de ses actions ; plusieurs adresses dont les nonces progressent de manière synchronisée, chacune envoyant une transaction par cycle dans un ordre fixe, suggèrent qu’un seul script les pilote.

Services de noms. ENS relie les noms aux adresses au moyen d’enregistrements directs (du nom vers l’adresse) et d’enregistrements inverses facultatifs (de l’adresse vers le nom principal). Un enregistrement inverse est défini par le propriétaire de l’adresse ; il s’agit donc d’une déclaration de sa part. Confirmez que l’enregistrement direct du nom pointe bien vers la même adresse. Les noms expirent et peuvent être réenregistrés par quelqu’un d’autre ; consignez donc le bloc auquel vous avez observé le lien. De nombreux noms sont personnels ; traitez-les comme indiqué dans la leçon De l’adresse à l’entité puis à la personne : attribution et étiquetage.

Pièges propres aux chaînes fondées sur des comptes

N’effectuez jamais de regroupement à partir du champ from des transactions envoyées par une infrastructure partagée. Un bundler ERC-4337 soumet une transaction contenant les opérations de nombreux utilisateurs sans lien entre eux ; les relais et les services de méta-transactions font de même. Relier tout ce qu’un bundler ou un relais a envoyé fusionnerait des milliers d’utilisateurs. Il en va de même pour les contrats qui détiennent les fonds de nombreux utilisateurs, tels que les pools de DEX et les ponts.

Les portefeuilles à contrat intelligent ajoutent une difficulté supplémentaire. Un portefeuille à contrat multisignature est une adresse unique contrôlée par plusieurs EOA signataires, dont la liste peut être lue dans l’état du contrat. Les signataires coopèrent, mais ils peuvent être des personnes différentes ; considérez le portefeuille comme l’entité et les signataires comme des parties liées, et non comme un groupe unique.

Puisque chaque indice du modèle de comptes est faible pris isolément, une bonne pratique consiste à exiger deux indices indépendants avant d’établir un lien, par exemple un financement du gas provenant d’une adresse qui n’est pas un service et une synchronisation des activités, et à consigner les deux dans le tableau des éléments probants, chacun avec son propre niveau de fiabilité.

Points clés pour l’examen : pourquoi les chaînes fondées sur des comptes ne disposent pas des heuristiques des entrées communes et de la monnaie rendue ; les trois heuristiques de Victor (réutilisation d’adresses de dépôt, participation multiple à un airdrop, auto-autorisation) et pourquoi leur exactitude reste largement non mesurée (couverture de 17,9 % sans vérité terrain, rappel de 39,4 % pour la réutilisation d’adresses de dépôt) ; déduire les adresses de dépôt à partir des transferts vers des portefeuilles à chaud ; le financement du gas et pourquoi les financeurs qui sont des services, les paymasters et les sponsors EIP-7702 rompent ce lien ; lire un journal Approval et comprendre le faux positif lié à l’hameçonnage par approbation ; les liens avec les déployeurs CREATE et CREATE2 et les pièges des fabriques ; les éléments probants liés aux horaires, aux nonces et à ENS, ainsi que leurs limites ; ne jamais regrouper à partir de l’adresse d’expéditeur d’un bundler ou d’un relais.