Heuristiques du modèle à comptes

Les chaînes à comptes, comme Ethereum, ne fournissent à l’analyste aucun des deux outils phares du Bitcoin : chaque transaction a 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 tout de même 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 de preuve sont moins solides et moins validés que sur les chaînes UTXO.

Ce qui change avec le modèle à comptes

Sur une chaîne à comptes, une seule adresse contient souvent tout l’historique d’un utilisateur : chaque adresse est donc plus riche en informations, mais aucune règle intégrée ne permet de la relier à une autre. Victor (2020, « Heuristiques de regroupement des adresses pour Ethereum ») a proposé trois heuristiques : la réutilisation d’adresses de dépôt, la participation multiple aux distributions gratuites de jetons (plusieurs adresses réclament chacune une distribution gratuite de jetons, puis transfèrent les jetons vers une même adresse) et l’autorisation par le propriétaire au moyen d’approbations de jetons. Il a constaté que, durant les quatre premières années d’Ethereum, ces heuristiques ont regroupé 17,9 % de tous les comptes détenus par des comptes externes (EOA) actifs. L’article précise franchement qu’il n’existait pas de vérité terrain permettant d’en mesurer la précision. Une étude open source ultérieure sur Ethereum et la confidentialité de Tornado Cash (Wu et al., 2022) a appliqué la plus efficace des trois heuristiques, la réutilisation d’adresses de dépôt, et a trouvé 26 millions d’EOA répartis en 2,5 millions de groupes. Comparée à 1 028 groupes dérivés des données d’un service de nommage, sa couverture était de 39,4 %. Ce sont les chiffres les mieux documentés disponibles : ils montrent que la plupart des liens ne sont pas détectés et que la précision n’est pour l’essentiel pas 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 transfèrent périodiquement son solde vers un portefeuille chaud (voir la leçon Suivre les flux de valeur à travers les plateformes d’échange et les services). Si deux EOA envoient toutes deux des fonds à la même adresse de dépôt, ils sont probablement crédités sur le même compte client et sont donc probablement contrôlés par la même personne ou organisation. C’est l’heuristique de réutilisation d’adresses de dépôt de Victor, et c’est la plus efficace des règles du modèle à comptes.

Les adresses de dépôt ne sont pas identifiées sur la chaîne : il faut donc les inférer. Il s’agit d’une adresse qui reçoit des fonds et transfère peu après un montant presque identique vers un portefeuille d’échange connu.

-- Adresses de dépôt candidates et expéditeurs qu’elles relient
WITH forwards AS (
  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 d’échange identifié, dans un intervalle 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 aussi que le montant transféré est proche du montant reçu et que l’adresse effectue régulièrement de tels transferts au fil du temps. La fenêtre de 2 000 blocs est une hypothèse à documenter, et non une norme.

Modes d’échec : une personne qui dépose des fonds sur le compte d’échange d’un ami ou de son employeur ; les processeurs de paiement et les bureaux de gré à gré qui déposent des fonds pour le compte de clients ; les plateformes d’échange qui réattribuent ou partagent des adresses de dépôt ; et l’erreur qui consiste à identifier une adresse de transfert ordinaire comme une adresse de dépôt.

Modèles de financement du gaz

Un EOA nouvellement créé a besoin de monnaie native pour payer le gaz avant de pouvoir faire quoi que ce soit. Son premier transfert entrant provient souvent du même opérateur. Ainsi, de nombreux EOA nouvellement créés, financés par une même adresse sur une courte période, avec des montants similaires et une activité ultérieure similaire, suggèrent un contrôle commun. Les équipes responsables de distributions gratuites de jetons utilisent ce modèle pour détecter les faux participants ; il constitue également une piste utile dans les enquêtes sur les exploits (voir la leçon Analyser les exploits et les piratages).

La faiblesse de cette heuristique tient au fait que le financeur est souvent un service. Les portefeuilles de retrait des plateformes d’échange, les passerelles et les robinets financent un très grand nombre d’utilisateurs sans lien entre eux. Il faut donc vérifier les étiquettes des services associés aux financeurs avant d’établir le moindre lien. Le parrainage du gaz rompt entièrement ce lien : dans le cadre d’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 à comptes pour les analystes explique pourquoi le payeur du gaz et le signataire sont deux questions différentes.

Approbations de jetons

Un appel approve ERC-20 permet à un dépensier de transférer 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 sujet est le hachage de signature de l’événement Approval(address,address,uint256), le deuxième correspond au propriétaire, le troisième au dépensier, et le champ data indique le montant autorisé. La plupart des approbations désignent un contrat, comme un routeur de DEX. L’heuristique d’autorisation par le propriétaire de Victor relie un propriétaire à un dépensier lorsque ce dernier est un autre EOA, selon le raisonnement qu’une personne autorise rarement l’adresse personnelle d’un inconnu à dépenser ses jetons.

Le principal mode d’échec est la fraude. L’hameçonnage par approbation pousse les victimes à autoriser une adresse contrôlée par un attaquant, et ces approbations ressemblent exactement à une autorisation par le propriétaire. Avant d’établir un lien, vérifiez si le dépensier a vidé le compte du propriétaire peu après. Si c’est le cas, le lien relie une victime à un voleur, et non deux adresses d’un même propriétaire.

Liens entre déployeurs de contrats

Chaque contrat a 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 déployeur, 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’exploit est généralement un nœud clé dans le groupe de l’attaquant.

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

Signaux temporels, de nonce et de nommage

Temporalité. Les adresses gérées par la même personne ou le même robot présentent souvent un rythme 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 nonce indiquent le niveau d’activité d’une adresse et l’ordre des actions. Plusieurs adresses dont les nonces progressent de concert, chacune envoyant une transaction par tour dans un ordre fixe, suggèrent qu’un même script les pilote.

Services de nommage. ENS relie les noms aux adresses au moyen d’enregistrements directs (nom vers adresse) et, en option, d’enregistrements inverses (adresse vers nom principal). Un enregistrement inverse est défini par le propriétaire de l’adresse ; il s’agit donc d’une déclaration personnelle. Vérifiez que l’enregistrement direct du nom renvoie à 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 Attribution et étiquetage.

Pièges propres aux chaînes à comptes

Ne regroupez jamais les adresses en fonction 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. Regrouper toutes les opérations envoyées par un bundler ou un relais fusionnerait des milliers d’utilisateurs. Il en va de même pour les contrats qui détiennent les fonds de nombreux utilisateurs, comme les pools de DEX et les passerelles.

Les portefeuilles de contrats intelligents ajoutent une difficulté supplémentaire. Un portefeuille de contrat multisignature est une adresse contrôlée par plusieurs EOA signataires, dont la liste peut être lue dans l’état du contrat. Les signataires coopèrent, mais il peut s’agir de personnes différentes. Traitez le portefeuille comme l’entité et les signataires comme des parties liées, et non comme un seul groupe.

Comme chaque signal du modèle à comptes est faible à lui seul, il est recommandé d’exiger deux signaux indépendants avant d’établir un lien, par exemple un financement du gaz provenant d’une adresse qui n’est pas un service, associé à une temporalité synchronisée. Consignez les deux signaux dans le tableau des éléments de preuve et attribuez à chacun son propre niveau de confiance.

Points clés pour l’examen : pourquoi les chaînes à comptes ne disposent pas des heuristiques d’entrées communes et de monnaie rendue ; les trois heuristiques de Victor (réutilisation d’adresses de dépôt, participation multiple aux distributions gratuites de jetons, autorisation par le propriétaire) et les raisons pour lesquelles leur précision n’est, pour l’essentiel, pas mesurée (couverture de 17,9 % sans vérité terrain, couverture de 39,4 % pour la réutilisation d’adresses de dépôt) ; inférer les adresses de dépôt à partir des transferts vers des portefeuilles chauds ; le financement du gaz et les raisons pour lesquelles les financeurs de services, les paymasters et les sponsors d’EIP-7702 invalident cette heuristique ; lire un journal Approval et reconnaître le faux positif de l’hameçonnage par approbation ; les liens de déployeur avec CREATE et CREATE2 et les pièges des fabriques ; les éléments de preuve liés à la temporalité, aux nonces et à ENS, ainsi que leurs limites ; ne jamais regrouper des adresses en fonction de l’adresse d’expéditeur d’un bundler ou d’un relais.