Autres conceptions de chaînes que les analystes rencontrent

Les enquêtes ne se limitent que rarement à Bitcoin et Ethereum : des fonds volés transitent par des programmes Solana, des stablecoins sont transférés en volume sur Tron, des jetons passent d’une chaîne Cosmos à une autre par IBC, et certaines pistes disparaissent dans Monero ou un pool protégé de Zcash. Chaque conception stocke la valeur différemment ; la même question (« qui a envoyé quoi à qui ? ») nécessite donc une requête différente et parfois ne trouve aucune réponse sur la chaîne. Cette leçon présente les notions essentielles propres à chaque conception et précise explicitement ce qui n’est pas visible.

Solana : comptes, programmes et comptes de jetons

Solana utilise un modèle de compte, mais plus littéralement qu’Ethereum : tout est un compte composé de cinq champs : lamports (solde ; 1 SOL = 1 000 000 000 lamports), data, owner, executable et rent_epoch. Les adresses sont des clés publiques Ed25519 de 32 octets ou des adresses dérivées de programmes, affichées en base58. Les comptes doivent détenir un solde minimum remboursable en lamports, qui varie selon la taille de leurs données.

Les programmes (les contrats intelligents de Solana) sont des comptes exécutables qui ne détiennent pas d’état propre. L’état se trouve dans des comptes de données distincts dont owner est le programme, et seul le programme propriétaire peut modifier les données d’un compte ou débiter ses lamports.

Les jetons suivent le même modèle. Un compte de mint définit un jeton (offre, décimales, autorité de mint, autorité de gel). Les soldes se trouvent dans des comptes de jetons, qui enregistrent chacun un mint, un propriétaire et un montant. Un portefeuille peut détenir plusieurs comptes de jetons pour le même mint, mais la norme est le compte de jetons associé, dont l’adresse est dérivée de l’adresse du propriétaire, du programme de jetons et du mint ; chaque portefeuille dispose ainsi d’un compte prévisible par jeton. Il existe deux programmes de jetons : le programme de jetons d’origine et Token-2022 (Token Extensions), qui ajoute des fonctionnalités telles que les frais de transfert.

Conséquence pour l’analyste : les transferts de jetons s’effectuent entre des comptes de jetons, et non entre des portefeuilles. Pour les attribuer, associez chaque compte de jetons à son owner et gardez à l’esprit que le propriétaire d’un compte de jetons peut être réattribué ; il faut donc établir cette correspondance au moment du transfert. Les métadonnées de transaction font une grande partie de ce travail. Chaque transaction répertorie à l’avance tous les comptes qu’elle touche ; le premier signataire paie les frais, et la première signature est l’identifiant de la transaction. getTransaction renvoie les soldes avant et après :

{
  "fee": 5000,
  "preTokenBalances": [
    { "accountIndex": 1, "mint": "EPx7…t1v", "owner": "7Hq2…ZpA",
      "uiTokenAmount": { "amount": "900000000", "decimals": 6 } },
    { "accountIndex": 2, "mint": "EPx7…t1v", "owner": "9mLc…4Rd",
      "uiTokenAmount": { "amount": "0", "decimals": 6 } }
  ],
  "postTokenBalances": [
    { "accountIndex": 1, "mint": "EPx7…t1v", "owner": "7Hq2…ZpA",
      "uiTokenAmount": { "amount": "650000000", "decimals": 6 } },
    { "accountIndex": 2, "mint": "EPx7…t1v", "owner": "9mLc…4Rd",
      "uiTokenAmount": { "amount": "250000000", "decimals": 6 } }
  ]
}

Comparer les soldes avant et après par index de compte montre que le propriétaire 7Hq2…ZpA a perdu 250 jetons (de 900 à 650, avec 6 décimales) et que le propriétaire 9mLc…4Rd en a gagné 250. Cette comparaison est souvent plus fiable que le décodage de chaque instruction, en particulier lorsqu’un swap passe par plusieurs programmes au moyen d’instructions internes. Les variations de lamports apparaissent de la même manière dans preBalances et postBalances.

Cardano : UTXO étendu

Cardano conserve le modèle UTXO et l’étend (eUTXO). Les sorties peuvent transporter plusieurs actifs à la fois : de l’ADA (1 ADA = 1 000 000 lovelaces) ainsi que des jetons natifs identifiés par un ID de politique et un nom d’actif, sans contrat intelligent nécessaire pour un simple transfert. Chaque sortie doit contenir un montant minimum d’ADA, qui augmente selon la quantité de jetons et de données qu’elle transporte. Les sorties verrouillées par des scripts comportent un datum (des données attachées à la sortie) ; leur dépense fournit un redeemer (un argument), et le script valide l’ensemble de la transaction (le contexte du script). Un ordre sur une plateforme d’échange décentralisée (DEX) ou une position de prêt est donc un UTXO situé à une adresse de script, dont les conditions sont inscrites dans le datum.

Les adresses Cardano (Bech32, commençant par addr1 sur le réseau principal) comportent généralement deux parties : une partie de paiement, qui contrôle la dépense, et une partie de délégation, qui contrôle les droits de staking. Les comptes de récompenses ont leurs propres adresses, qui commencent par stake1. Dans la plupart des cas, plusieurs adresses de paiement partageant une même donnée d’identification de délégation appartiennent au même portefeuille : c’est un signal de regroupement puissant qui n’existe pas sur Bitcoin. Ce n’est pas une preuve, car la norme permet aux deux parties d’appartenir à des parties différentes, et certaines adresses ne comportent aucune partie de délégation.

Tron

Tron est une chaîne fondée sur un modèle de compte, dont la machine virtuelle est compatible avec l’EVM. Les jetons TRC-20 émettent donc les mêmes événements Transfer que les jetons ERC-20, et le même décodage s’applique (voir la leçon Lire les transferts de jetons). C’est l’un des principaux réseaux utilisés pour les transferts de stablecoins, et il apparaît fréquemment dans les enquêtes sur les fraudes et les escroqueries.

Les adresses sont des chaînes Base58Check commençant par T : un octet de préfixe 0x41 suivi d’un corps de 20 octets dérivé de la clé publique, comme sur Ethereum. Convertir les adresses T… en format hexadécimal permet à l’analyste d’utiliser des outils de type EVM et de les joindre à des jeux de données EVM, tout en conservant l’identifiant de chaîne dans chaque ligne.

Les frais utilisent un modèle de ressources plutôt que des prix du gaz. Les transferts simples consomment de la bande passante (chaque compte bénéficie d’une petite allocation quotidienne gratuite), et les appels de contrat, comme les transferts TRC-20, consomment de l’énergie. Les ressources proviennent du staking de TRX, d’un autre compte qui les délègue ou de la combustion de TRX lorsqu’aucune autre option n’est disponible. La délégation et la location d’énergie signifient que le compte dont les ressources ont payé une transaction peut être un service plutôt que l’expéditeur, à l’instar du parrainage du gaz (voir la leçon Le modèle de compte pour les analystes). Une nouvelle adresse devient généralement active sur la chaîne lorsqu’elle reçoit des TRX pour la première fois ; l’expéditeur qui l’active constitue donc une piste utile.

Cosmos et IBC

L’écosystème Cosmos est une famille de chaînes indépendantes, spécifiques à des applications, dont la plupart sont construites avec Cosmos SDK et le consensus CometBFT, qui assure la finalité dès qu’un bloc est validé. Les adresses sont au format Bech32 et utilisent un préfixe propre à chaque chaîne (cosmos1…, osmo1…). Pour les chaînes qui utilisent la même dérivation de clé, une clé produit des adresses sur de nombreuses chaînes avec la même charge utile et des préfixes et sommes de contrôle différents. Réencoder une adresse avec un autre préfixe permet donc de retrouver rapidement le détenteur de la même clé sur d’autres chaînes.

Les chaînes échangent des jetons et des messages par l’intermédiaire d’IBC (Inter-Blockchain Communication), chaque chaîne exécutant un client léger de l’autre et des relayeurs hors chaîne transportant les paquets. Dans un transfert de jetons fongibles ICS-20, la chaîne source place les jetons sous séquestre et la chaîne de destination émet un justificatif dont la dénomination est ibc/, suivi du hachage SHA-256 du chemin et de la dénomination de base. Des ATOM arrivant sur Osmosis par transfer/channel-0 apparaissent sous la forme ibc/2739…5EB2. Chaque paquet est identifié par son port source, son canal source et son numéro de séquence, qui apparaissent dans l’événement send_packet sur une chaîne et dans les événements recv_packet et acknowledge_packet sur l’autre : une clé de jointure exacte entre chaînes, contrairement à la plupart des ponts. Retrouvez le chemin correspondant à chaque hachage ibc/ au moyen de la requête de trace de dénomination de la chaîne, et gardez à l’esprit que le même actif reçu par deux chemins différents produit deux dénominations différentes et non interchangeables.

Chaînes axées sur la confidentialité : Monero et Zcash

Monero masque par défaut les trois parties. Chaque paiement est envoyé à une adresse furtive à usage unique ; l’adresse publique du destinataire n’apparaît donc jamais sur la chaîne. Chaque entrée est signée au moyen d’une signature en anneau qui mélange la sortie réelle à des leurres (taille d’anneau de 16 depuis la mise à niveau d’août 2022), et une image clé empêche la double dépense sans révéler quel membre de l’anneau a été dépensé. Les montants sont masqués par des engagements RingCT accompagnés de preuves de plage (Bulletproofs+ depuis 2022). Ce qui reste visible : la transaction, son heure, ses frais, le nombre d’entrées et de sorties, les membres de l’anneau et les données supplémentaires. Une étude de Möser et ses collègues (« An Empirical Analysis of Traceability in the Monero Blockchain », 2018) a montré que de nombreuses transactions anciennes étaient traçables, principalement à cause d’entrées sans leurres et d’une sélection des leurres qui faisait du membre le plus récent de l’anneau le membre réel le plus souvent ; le protocole a depuis rendu obligatoire la taille des anneaux et amélioré la sélection des leurres. Une mise à niveau prévue (FCMP++) remplacerait les anneaux par des preuves portant sur l’ensemble des sorties, ce qui éliminerait les fuites liées à la sélection des leurres ; vérifiez si elle est activée avant de vous appuyer sur un raisonnement fondé sur les anneaux. Les détenteurs peuvent divulguer les paiements reçus au moyen d’une clé de visualisation. En pratique, l’analyse de Monero se concentre sur les points d’entrée et de sortie (les plateformes d’échange et les services de swap) et sur leurs registres hors chaîne, obtenus par voie légale.

Zcash est un système hybride. Les adresses transparentes (t1…, t3… pour les signatures multiples) fonctionnent comme celles de Bitcoin et sont entièrement visibles. Les pools protégés (Sprout avec les adresses zc…, Sapling avec zs…, et Orchard depuis la mise à niveau NU5 du 31 mai 2022, utilisé au moyen d’adresses unifiées commençant par u1) masquent l’expéditeur, le destinataire, le montant et le mémo au sein du pool ; les frais restent visibles. Les points de passage révèlent des informations : la protection révèle l’expéditeur transparent et le montant, la sortie du pool révèle le montant et le destinataire transparent, et la valeur totale de chaque pool est publique via getblockchaininfo. Une étude empirique de Kappos et ses collègues (« An Empirical Analysis of Anonymity in Zcash », 2018) a montré que la plupart des activités étaient transparentes et que la correspondance des montants et des horaires entre les entrées dans le pool et les sorties permettait d’associer de nombreuses transactions. Les clés de visualisation permettent une divulgation volontaire.

Points clés pour l’examen : les champs de compte de Solana, les programmes sans état, les comptes de mint, les comptes de jetons et les comptes de jetons associés, et pourquoi les transferts doivent être associés aux propriétaires des comptes de jetons ; lecture de preTokenBalances et postTokenBalances ; eUTXO de Cardano (datum, redeemer, sorties multi-actifs) et distinction entre les parties de paiement et de délégation en tant que signal de regroupement ; adresses T de Tron, conversion hexadécimale et modèle de bande passante et d’énergie ; préfixes Bech32 de Cosmos, transferts IBC par séquestre et justificatif, dénominations ibc/ et séquence de paquet comme clé de jointure ; adresses furtives de Monero, taille d’anneau de 16, images clés et RingCT ; différence entre les pools transparents et protégés de Zcash et les fuites aux points de passage des pools.