Ponts, couches 2, chaînes latérales et autres architectures de chaînes

Les pistes restent rarement sur le réseau principal de Bitcoin ou d’Ethereum. Les fonds volés sont transférés par des ponts vers des rollups et des chaînes latérales, déplacés sous forme de stablecoins sur Tron, acheminés par des programmes Solana ou transférés entre des chaînes Cosmos. Chaque passage est un point où la piste se renforce ou se perd. Un passage bien documenté laisse sur les deux registres un identifiant qui relie le dépôt au versement aussi solidement qu’une sortie dépensée relie deux transactions Bitcoin ; un passage mal documenté ne laisse qu’une supposition fondée sur le montant et l’heure. L’examinateur doit trouver cet identifiant, prouver la correspondance sur les deux chaînes, expliquer chaque différence de montant, savoir où chaque chaîne conserve ses données et qui pourrait les réécrire, et savoir quel opérateur détient ce que les chaînes ne montrent pas. La leçon 5.3 traite des schémas de passage d’une chaîne à l’autre et de la mise en correspondance par montant et heure ; cette leçon traite des mécanismes et des éléments de preuve laissés par chacun.

Architectures de ponts et leurs clés de liaison

Entre les deux côtés se trouve une couche de vérification : un ensemble de validateurs, un client léger, une fenêtre de contestation optimiste ou une preuve à divulgation nulle de connaissance. Les ponts vers les chaînes latérales reposent généralement sur les signatures d’un petit ensemble de validateurs ; un lien « déterministe » n’y est donc valable que dans les limites de la confiance accordée à ces validateurs ; le rapport doit le préciser.

La plupart des ponts fonctionnent sur une couche de messagerie. Wormhole identifie chaque message par la chaîne émettrice, l’adresse émettrice et le numéro de séquence ; LayerZero attribue à chaque paquet un point de terminaison source, un expéditeur et un nonce, ainsi qu’un identifiant global (GUID) de 32 octets. Les applications héritent de ces identifiants ; commencez donc par déterminer quelle couche utilise un pont. Le Cross-Chain Transfer Protocol (CCTP) de Circle pour l’USDC repose sur la destruction et l’émission : la source émet DepositForBurn (montant, déposant, destinataire de l’émission, domaine de destination), et la destination MessageReceived (domaine source, nonce). Dans la version actuelle, l’émetteur attribue les nonces hors chaîne et son service d’attestation les renvoie pour un hachage de transaction source. Une partie de la clé provient donc de l’opérateur : traitez cette réponse d’API comme une pièce à conviction, avec la requête, l’heure de récupération et un hachage de la réponse.

Les ponts numérotent également les chaînes à leur manière : Wormhole possède ses propres identifiants de chaîne sur 16 bits, LayerZero ses identifiants de points de terminaison, et CCTP ses domaines (Ethereum 0, Arbitrum 3, Solana 5, Base 6), tandis que l’identifiant de chaîne EIP-155 d’Arbitrum One est 42161. Interpréter destinationDomain = 3 comme « chaîne 3 » vous envoie sur le mauvais réseau. Consignez chaque correspondance et sa source, à savoir la documentation du pont dans une version datée.

Mettre un dépôt en correspondance avec sa libération

Une correspondance défendable satisfait à sept vérifications :

1. Décodez l’événement source à partir du reçu, et non d’un résumé d’explorateur : contrats, montant, déposant, destinataire, identifiant de destination, clé de liaison.
2. Associez l’identifiant de destination à un réseau et consignez cette correspondance.
3. Trouvez l’événement de destination portant la même clé (et, sur les couches de messagerie, le même émetteur ou expéditeur).
4. Vérifiez le destinataire par rapport à celui inscrit dans l’événement source ; expliquez toute différence avant de poursuivre.
5. Rapprochez les montants : le montant à destination est égal au montant source moins les frais indiqués, en vérifiant le nombre de décimales des deux côtés, car les jetons enveloppés ne conservent pas toujours le nombre de décimales du jeton d’origine.
6. Vérifiez l’ordre et le statut : la libération doit suivre le dépôt ; un dépôt sans libération peut être en attente, avoir expiré ou avoir été remboursé.
7. Reproduisez la mise en correspondance à partir d’une seconde source de données et consignez les deux.

La réussite des sept vérifications donne un lien de flux de niveau A selon l’échelle de la leçon 3.2 ; un échec à la vérification du destinataire ou du montant signifie qu’aucune correspondance ne peut être établie tant qu’il n’est pas expliqué. Dans un entrepôt de données, la mise en correspondance est une LEFT JOIN des dépôts avec les exécutions sur l’identifiant de chaîne d’origine et l’identifiant de dépôt, et non une recherche par montant : elle conserve les dépôts non exécutés pour vérifier les remboursements, calcule les frais implicites et identifie le relais afin que personne ne le confonde avec le sujet de l’enquête. Les exécutions par les relais peuvent intervenir quelques secondes après le dépôt, avant que la chaîne source n’atteigne la finalité ; si une réorganisation faisait disparaître le bloc source, le relais supporterait généralement la perte, mais vos éléments de preuve citeraient une transaction qui n’existe plus. Consignez le hachage du bloc source et son statut de finalité (leçon 8.2).

Pièges qui affaiblissent un lien :

• Les relais, les exécuteurs et les finalisateurs ne sont pas les propriétaires. Un traçage naïf à travers un pont de liquidité bascule dans les fonds d’un tiers sans rapport avec l’enquête.
• Le destinataire n’est pas le déposant. Le champ destinataire de l’événement source constitue l’élément de preuve.
• Les agrégateurs peuvent apparaître comme déposants ; lisez la trace pour déterminer qui les a appelés.
• Même adresse, propriétaire différent. Un compte détenu en externe (EOA) possède la même adresse sur toutes les chaînes EVM, mais une adresse de contrat peut contenir un code différent, voire aucun code, ailleurs. En juin 2022, environ 20 millions de jetons OP ont été envoyés à une adresse Optimism où le portefeuille multisignature prévu n’existait que sur Ethereum ; un attaquant y a déployé un autre portefeuille multisignature et s’en est emparé.
• Identifiez les jetons par leur contrat, pas par leur symbole : plusieurs versions transférées par pont d’un même actif peuvent coexister.

Rapprocher le séquestre et l’offre

L’invariant d’un pont à verrouillage et émission : l’offre de jetons enveloppés à destination ne dépasse jamais la garantie sous séquestre à la source, à l’exception des dépôts en transit. Comparez le balanceOf du séquestre au totalSupply() du jeton enveloppé à des instants correspondants, ou tenez des totaux cumulés quotidiens des unités nettes verrouillées et des unités nettes émises. Un petit écart positif est normal ; un écart négatif signifie que des jetons ne sont pas garantis. Les exploitations de failles inversent le traçage : des fonds apparaissent sans dépôt légitime ; commencez donc par l’émission ou la libération (les causes profondes sont abordées dans la leçon 5.5).

Les six jours de Ronin plaident en faveur d’une surveillance continue. Les protocoles de prêt nécessitent le même contrôle (jetons représentant les dépôts comparés aux actifs sous-jacents détenus plus la dette), et leurs événements distinguent qui a agi de la personne dont la position a changé : un routeur apparaît comme user, le propriétaire comme onBehalfOf. Les soldes rémunérés tels que les aTokens augmentent sans événements Transfer ; lisez-les donc dans l’état. Le principal d’un prêt flash entre et sort dans une seule transaction et doit être déduit de toute perte (leçon 5.5).

Les opérateurs comme sources. La chaîne montre le transfert ; les opérateurs peuvent révéler la personne. Un opérateur de pont ou une interface peut détenir des journaux d’API et Web (adresses IP, agents utilisateurs, portefeuilles connectés), des exécutions de relais, des attestations, des tickets d’assistance et des journaux de filtrage ; les émetteurs derrière les ponts à destruction et émission peuvent également geler les fonds (leçon 10.1). Un pont entièrement décentralisé peut n’avoir aucun opérateur ; adressez-vous alors à l’interface utilisée par le sujet de l’enquête. Précisez la chaîne, le hachage du dépôt, le déposant, le destinataire, la fenêtre UTC et les champs, et demandez d’abord la conservation des données (leçon 1.4).

Rollups et chaînes latérales

L’historique d’un rollup peut en principe être reconstruit à partir de la L1 ; celui d’une chaîne latérale n’est fiable qu’à hauteur de ses validateurs. Pour une chaîne latérale, consignez les règles de consensus et de finalité, l’ensemble des validateurs s’il est publié, et indiquez si vous avez utilisé son unique explorateur ou votre propre nœud.

Séquenceurs et finalité à plusieurs niveaux. La plupart des rollups ont un seul séquenceur qui ordonne les transactions, fixe les horodatages L2 dans les limites du protocole et publie des lots sur la L1. Les nœuds OP Stack exposent des têtes unsafe (séquenceur uniquement, susceptibles de réorganisation), safe (dérivées des données L1) et finalized ; constituez vos éléments de preuve à partir de blocs sûrs ou finalisés et consignez la transaction L1 d’ancrage. Depuis la mise à niveau Dencun (13 mars 2024), la plupart des rollups publient des blobs, que les nœuds L1 élaguent après 4 096 époques, soit environ 18 jours, en ne laissant qu’un hachage versionné. Pour montrer que l’historique L2 peut être reconstruit indépendamment, conservez les données des blobs dans ce délai ou indiquez l’archive utilisée. Les opérateurs de séquenceurs et les fournisseurs RPC publics peuvent journaliser les métadonnées de soumission et recevoir des demandes précises.

Dépôts. Sur les chaînes OP Stack, le contrat L1 OptimismPortal émet TransactionDeposited et la L2 crée une transaction de dépôt non signée de type 0x7E (126 sous forme d’entier), dont le sourceHash, calculé à partir du hachage du bloc L1 et de l’index du journal, constitue une clé de jointure exacte ; son champ mint correspond à l’ETH créé sur la L2, en contrepartie de l’ETH verrouillé sur la L1. En l’absence de signature, l’autorité et l’attribution proviennent de l’expéditeur L1. Sur Arbitrum, un ticket réessayable dont l’exécution automatique échoue reste en attente jusqu’à une semaine ; l’effet sur la L2 peut donc être retardé de plusieurs jours. Les deux familles créent des alias des contrats L1 en ajoutant 0x1111000000000000000000000000000000001111 : le contrat L1 0x5d3a…7c10 arrive sur la L2 sous la forme 0x6e4b…8d21. Les EOA n’ont pas d’alias ; recherchez l’alias.

Retraits. Un retrait canonique OP Stack comporte trois étapes reliées par un hachage de retrait : initiation sur la L2 (MessagePassed), preuve sur la L1 (WithdrawalProven), finalisation après la fenêtre de contestation (WithdrawalFinalized). Arbitrum n’a pas d’étape de preuve (sendTxToL1, puis exécution par Outbox environ une semaine plus tard). Dès que l’initiation est visible, le destinataire L1 et l’heure d’arrivée au plus tôt sont connus plusieurs jours à l’avance ; une plateforme d’échange peut donc être alertée avant l’arrivée des fonds (leçon 10.1). Les acteurs qui soumettent les preuves et les finalisateurs sont souvent des relais, et les fenêtres varient selon la chaîne et évoluent ; consignez donc le paramètre en vigueur. Les auteurs d’infractions passent par conséquent généralement par des ponts de liquidité pour sortir.

Utilisez comme clé de chaque table l’identifiant de chaîne et l’adresse : Ethereum 1, OP Mainnet 10, BNB Smart Chain 56, Polygon PoS 137, zkSync Era 324, Base 8453, Arbitrum One 42161, Linea 59144, Scroll 534352.

Autres architectures de chaînes

Tron est compatible avec l’EVM (TRC-20 émet l’événement Transfer d’ERC-20), transporte une part importante de l’USDT et produit des blocs environ toutes les trois secondes. Les adresses T… encodent un octet 0x41 suivi d’un corps de 20 octets ; convertissez-les en hexadécimal pour effectuer une jointure avec les données EVM, en conservant l’identifiant de chaîne dans chaque ligne. Les frais utilisent la bande passante et l’énergie, qui peuvent être déléguées ou louées ; le compte payeur peut donc être un service de location. Une nouvelle adresse s’active généralement lorsqu’elle reçoit des TRX pour la première fois, et l’activateur constitue une piste. L’émetteur de l’USDT peut geler une adresse (AddedBlackList) et détruire son solde (DestroyedBlackFunds) ; vérifiez les deux avant de déclarer les fonds disponibles.

Solana conserve tout dans des comptes (1 SOL = 1 000 000 000 lamports). Les programmes ne conservent aucun état ; un compte d’émission définit un jeton et les soldes se trouvent dans des comptes de jetons, normalement le compte de jetons associé dérivé du propriétaire, du programme de jetons et du compte d’émission. Les jetons circulent entre comptes de jetons ; associez donc chacun à son propriétaire au moment du transfert. Consignez la première signature (l’identifiant de transaction), le slot et le blockTime estimé. Comparer preTokenBalances et postTokenBalances est plus efficace que décoder les instructions internes : un compte qui passe de 900 000 000 à 650 000 000 d’unités de base avec 6 décimales a envoyé 250 jetons. De nombreux nœuds ne conservent que l’historique récent ; indiquez la source d’archives.

Cardano étend le modèle UTXO (eUTXO) : les sorties contiennent de l’ADA et des jetons natifs ; les sorties de script contiennent un datum et sont dépensées avec un redeemer. Les adresses de paiement qui partagent un même identifiant de délégation appartiennent dans la plupart des cas à un même portefeuille, ce qui constitue un indice fort de regroupement, mais pas une preuve.

Les chaînes Cosmos utilisent des adresses Bech32 préfixées (cosmos1…, osmo1…), et une même clé produit souvent des adresses correspondantes sur plusieurs chaînes. IBC place les actifs sous séquestre à la source et émet un jeton représentatif dont la dénomination est ibc/ suivi d’un hachage SHA-256 du chemin et de la dénomination de base ; le port, le canal et le numéro de séquence du paquet apparaissent dans send_packet, ainsi que dans recv_packet et acknowledge_packet, constituant une clé de jointure exacte. Un même actif arrivant par deux chemins possède deux dénominations différentes.

Monero et les transactions protégées de Zcash masquent les parties et les montants ; l’analyse se concentre sur les points d’entrée et de sortie (leçon 6.4).

Chaînes non prises en charge. Lorsque vos outils ne peuvent pas décoder une chaîne : lisez sa documentation dans une version datée ; obtenez les données auprès de deux sources, en enregistrant et en hachant les réponses brutes (leçon 8.3) ; validez-les sur une base connue, par exemple un dépôt dont vous détenez les enregistrements de la plateforme d’échange ; ne rapportez que les champs validés ; appuyez-vous sur les ponts et les plateformes d’échange aux points d’entrée et de sortie ; et indiquez chaque limite (leçon 3.6).

Points clés pour l’examen : les quatre architectures de ponts et ce que chacune laisse sur les deux chaînes ; les identifiants Wormhole, LayerZero et CCTP, les nonces CCTP attribués par l’émetteur et l’association des identifiants de ponts tels que les domaines CCTP aux réseaux ; la mise en correspondance en sept étapes ; les relais, agrégateurs et finalisateurs en tant que non-propriétaires ; l’invariant selon lequel l’offre de jetons enveloppés ne dépasse jamais le séquestre, et la manière dont Wormhole, Ronin et Nomad y apparaissent ; l’adresse qui agit par opposition à onBehalfOf ; les rollups optimistes et ZK par rapport aux chaînes latérales ; les têtes unsafe, safe et finalized et l’élagage des blobs après environ 18 jours ; sourceHash, les tickets réessayables et la création d’alias ; le retrait en trois étapes comme délai d’alerte ; l’utilisation de l’identifiant de chaîne et de l’adresse comme clé ; les ressources Tron, l’activation et les gels d’USDT ; les comptes de jetons Solana et les différences de soldes ; les identifiants de délégation Cardano ; les clés de paquets IBC.