Les couches 2, les chaînes latérales et les ponts comme sources de données

Une grande partie de l’activité sur les réseaux de type Ethereum se déroule désormais sur des chaînes de couche 2 et des chaînes latérales plutôt que sur la chaîne de base elle-même. Les fonds circulent entre les couches par l’intermédiaire de ponts, et chaque couche possède ses propres blocs, son propre explorateur et son propre ID de chaîne. Un analyste qui ne suit les fonds que sur la couche 1 les voit disparaître dans un contrat de pont ; celui qui comprend comment les couches enregistrent les dépôts, les retraits et les messages peut les suivre d’une couche à l’autre et préciser le degré de certitude de chaque lien.

Une carte du territoire

Pour les preuves, la distinction importante est l’endroit où se trouvent les données et les personnes qui pourraient les réécrire. En principe, l’historique d’un rollup peut être reconstruit à partir de L1 ; l’historique d’une chaîne latérale n’est fiable que dans la mesure où ses propres validateurs le sont.

Séquenceurs et finalité sur L2

La plupart des rollups disposent d’un séquenceur unique qui ordonne les transactions et produit rapidement des blocs L2 (généralement toutes les 2 secondes sur les chaînes OP Stack, plus rapidement sur certaines autres). Les utilisateurs reçoivent une confirmation « souple » du séquenceur en quelques secondes ; la transaction est ancrée lorsque le séquenceur publie le lot sur L1, et réglée lorsque ce bloc L1 atteint la finalité. La plupart des rollups permettent également aux utilisateurs de forcer une transaction à passer par L1 si le séquenceur la censure.

Pour l’analyse, cela crée une finalité à plusieurs niveaux. Les nœuds OP Stack exposent les têtes unsafe (séquenceur uniquement), safe (dérivées des données publiées sur L1) et finalized (dérivées des blocs L1 ayant atteint la finalité), et les balises safe et finalized fonctionnent dans les appels JSON-RPC standard. Constituez vos jeux de données à partir de blocs L2 safe ou finalized, comme vous le feriez sur L1 (voir la leçon Les blocs et les en-têtes comme données). Des pannes de séquenceurs se sont produites sur plusieurs rollups, et la tête unsafe peut être réorganisée.

Disponibilité des données : où lire les données L2

En pratique, les analystes lisent les données L2 à partir de nœuds L2, d’explorateurs et d’entrepôts de données, exactement comme sur L1, avec les mêmes reçus, journaux et traces. La copie L1 est importante pour la vérification et pour comprendre les coûts :

• Jusqu’en mars 2024, les rollups publiaient les lots sous forme de données d’appel L1, conservées pour toujours.
• Depuis la mise à niveau Dencun (13 mars 2024), la plupart les publient sous forme de blobs (EIP-4844). Les nœuds de consensus L1 conservent les données des blobs pendant 4 096 époques, soit environ 18 jours, puis les élaguent ; seul un hachage versionné reste dans la transaction L1. La reconstruction de l’ancien historique L2 à partir de L1 nécessite donc une archive de blobs.
• Certains rollups ZK publient des différences d’état plutôt que des transactions, de sorte que la copie L1 prouve les soldes, mais ne répertorie pas chaque transfert.

Pour chaque jeu de données L2, consignez l’ID de chaîne, la plage de blocs L2, le nœud ou le fournisseur et, le cas échéant, le bloc L1 qui l’a ancré.

De L1 à L2 : dépôts et messages

Un dépôt transfère de la valeur ou un message de L1 vers L2. Sur les chaînes OP Stack, un utilisateur (ou le contrat de pont standard agissant pour lui) appelle l’OptimismPortal sur L1, qui émet TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData). Les nœuds L2 lisent ces événements et créent une transaction de dépôt de type 0x7E au début d’un bloc L2 ultérieur. Voici comment un nœud OP Stack la renvoie :

{
  "type": "0x7e",
  "sourceHash": "0x3c9e…a0d4",
  "from": "0xA1b2…9F",
  "to": "0xA1b2…9F",
  "mint": "0x6f05b59d3b20000",
  "value": "0x6f05b59d3b20000",
  "gas": "0x186a0",
  "input": "0x"
}

Une transaction de dépôt n’a pas de signature : son autorité provient de l’événement L1. mint correspond à l’ETH créé sur L2 (ici, 0,5 ETH), auquel correspond l’ETH verrouillé dans le portail sur L1. sourceHash identifie de manière unique l’origine L1, calculée à partir du hachage du bloc L1 et de l’index du journal de l’événement ; c’est donc la clé de jointure exacte entre l’événement L1 et la transaction L2. Dans un entrepôt de données qui stocke le type sous forme d’entier, il s’agit de lignes dont le type est 126.

Arbitrum utilise des tickets réessayables : un appel L1 à createRetryableTicket sur le contrat Inbox crée un ticket qui est normalement réclamé automatiquement sur L2. Si la réclamation automatique échoue, le ticket attend jusqu’à une semaine avant une réclamation manuelle ; un analyste peut donc voir un dépôt sur L1 dont l’effet sur L2 n’apparaît que plusieurs jours plus tard.

Les deux familles appliquent l’aliasage d’adresse. Lorsqu’un contrat L1 envoie un message vers L2, son adresse sur L2 est décalée par l’ajout de 0x1111000000000000000000000000000000001111, afin qu’il ne puisse pas usurper l’identité d’un contrat L2 à la même adresse. Un message du contrat L1 0x5d3a…7c10 arrive donc sur L2 depuis 0x6e4b…8d21. Les EOA ne sont pas aliasées. Un analyste qui recherche sur L2 l’adresse du contrat L1 ne trouvera rien ; il faut rechercher l’alias.

De L2 à L1 : retraits

Un retrait canonique est un processus en plusieurs étapes, réparti sur deux chaînes et sur plusieurs jours. Sur les chaînes OP Stack :

1. Lancer sur L2 : l’utilisateur appelle le pré-déploiement L2ToL1MessagePasser à l’adresse 0x4200…0016 (directement ou par l’intermédiaire du pont L2), qui émet MessagePassed avec un hachage de retrait.
2. Prouver sur L1 : une fois que l’état L2 contenant ce message a été proposé sur L1, n’importe qui peut soumettre une preuve à l’OptimismPortal, qui émet WithdrawalProven(bytes32 indexed withdrawalHash, address indexed from, address indexed to).
3. Finaliser sur L1 : après la période de contestation, n’importe qui peut appeler la fonction de finalisation ; le portail émet WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success) et libère les fonds.

Sur Arbitrum, le côté L2 appelle le précompilé ArbSys (adresse 100, 0x…0064) avec sendTxToL1, et environ une semaine plus tard, le message est exécuté sur L1 par l’intermédiaire de la fonction executeTransaction du contrat Outbox.

Le hachage de retrait relie ces trois étapes. Deux pièges à éviter : l’adresse qui prouve ou finalise le retrait peut être celle de n’importe qui, souvent un relais, et n’est pas nécessairement celle du propriétaire ; et les périodes de contestation varient selon les chaînes et évoluent avec les systèmes de preuve (certaines chaînes les ont raccourcies grâce à de nouveaux systèmes de preuve), alors vérifiez les paramètres en vigueur à l’époque. Comme une semaine est une longue attente, de nombreux utilisateurs sortent plutôt par l’intermédiaire de ponts tiers ou de fournisseurs de liquidités, qui paient sur L1 à partir de leurs propres fonds et rompent le lien canonique ; la mise en correspondance de ces flux est abordée dans la leçon Suivi inter-chaînes.

ID de chaîne et identités entre les couches

Chaque chaîne EVM possède un ID de chaîne (EIP-155), renvoyé par eth_chainId et intégré aux transactions signées :

Utilisez toujours conjointement l’ID de chaîne et l’adresse comme clés de chaque table, jamais l’adresse seule. La même clé privée contrôle la même adresse EOA sur chaque chaîne EVM, ce qui facilite l’identification des EOA d’une chaîne à l’autre. Les contrats sont différents : une adresse peut héberger un contrat sur une chaîne et rien du tout, ou le contrat de quelqu’un d’autre, sur une autre. En juin 2022, environ 20 millions de jetons OP ont été envoyés à une adresse sur Optimism où le multisig du destinataire prévu n’existait que sur Ethereum ; avant que le propriétaire ne puisse le déployer sur Optimism, un attaquant a déployé un autre multisig à cette adresse sur Optimism et s’est emparé des jetons. Une même adresse ne signifie pas un même propriétaire, à moins que le code et le déploiement ne soient vérifiés sur chaque chaîne.

Le décompte quotidien des dépôts OP Stack montre le filtre standard :

-- Dépôts quotidiens de L1 vers L2 sur une chaîne OP Stack (type de dépôt 0x7E = 126)
SELECT
  CAST(block_timestamp AS DATE)     AS day,
  COUNT(*)                          AS deposits,
  SUM(mint) / 1e18                  AS eth_minted
FROM transactions
WHERE chain_id = 8453
  AND tx_type = 126
  AND block_timestamp >= TIMESTAMP '2026-01-01 00:00:00'
GROUP BY 1
ORDER BY 1;

La requête filtre sur une seule chaîne et sur les transactions de dépôt, puis additionne l’ETH créé. Les noms de colonnes varient selon les jeux de données (type ou transaction_type, mint peut être absent), et les types d’horodatage diffèrent selon le moteur ; vérifiez le schéma avant de faire confiance à une valeur nulle.

Points clés pour l'examen : différences entre les rollups optimistes, les rollups ZK et les chaînes latérales, et emplacement des données de chacun ; séquenceurs et têtes unsafe, safe et finalized ; blobs depuis mars 2024 et leur conservation d’environ 18 jours ; dépôts OP Stack (TransactionDeposited, type 0x7E, mint, sourceHash comme clé de jointure) et tickets réessayables Arbitrum ; aliasage des adresses des contrats L1 par l’ajout de 0x1111…1111 ; étapes de lancement, de preuve et de finalisation d’un retrait OP Stack, et hachage de retrait qui les relie ; raisons pour lesquelles les personnes qui finalisent ne sont pas nécessairement les propriétaires ; ID de chaîne, clé des données combinant ID de chaîne et adresse, et raisons pour lesquelles une même adresse de contrat sur deux chaînes n’implique pas le même propriétaire.