Ancien ambassadeur technique d'Arbitrum explique l'architecture des composants d'Arbitrum (2/2)
TechFlow SélectionTechFlow Sélection
Ancien ambassadeur technique d'Arbitrum explique l'architecture des composants d'Arbitrum (2/2)
Comment Arbitrum gère-t-il la transmission de messages inter-chaînes et les transactions résistant à la censure ?
Dédié à des analyses Web3 approfondiesRédaction : Luo Benben, ancien ambassadeur technique d'Arbitrum, contributeur web3 passionné
Dans l'article précédent « Analyse de la structure des composants d'Arbitrum par un ancien ambassadeur technique (Partie 1) », nous avons présenté les rôles du séquenceur, des validateurs, du contrat Sequencer Inbox, des blocs Rollup et des preuves de fraude non interactives dans les composants centraux d'Arbitrum. Dans cet article, nous allons maintenant nous concentrer sur les composants liés au transfert de messages inter-chaînes et aux entrées de transactions résistantes à la censure.
Comme mentionné précédemment, le contrat Sequencer Inbox reçoit spécifiquement sur la couche 1 (Layer1) les paquets de transactions publiés par le séquenceur. En outre, nous avons souligné que le Sequencer Inbox est également appelé « boîte rapide », tandis que Delayed Inbox (appelé simplement Inbox) constitue la « boîte lente ». Nous allons maintenant examiner en détail les composants associés au Delayed Inbox et au transfert inter-chaînes.
Principes des ponts inter-chaînes
Les transactions inter-chaînes peuvent être divisées en deux catégories : de la L1 vers la L2 (dépôt) et de la L2 vers la L1 (retrait). Notez que ces termes « dépôt » et « retrait » ne se réfèrent pas nécessairement à des transferts d'actifs, mais simplement aux deux directions possibles du transfert d'informations entre couches.
Comparées aux transactions purement L2, les transactions inter-chaînes impliquent un échange d’information entre deux systèmes distincts (L1 et L2), ce qui rend leur processus plus complexe.
En général, les opérations inter-chaînes sont réalisées via des ponts utilisant un modèle dit « de témoin » entre deux réseaux indépendants. La sécurité de ces ponts dépend entièrement de leurs opérateurs, et historiquement, de nombreux incidents de piratage ont touché ce type de ponts.
Cependant, les transferts entre un Rollup et le réseau principal Ethereum diffèrent fondamentalement de ce cas : l'état de la couche 2 (L2) étant entièrement déterminé par les données enregistrées sur la couche 1 (L1), l'utilisation d'un pont officiel du Rollup garantit une sécurité structurelle absolue.
Cela illustre bien l'essence d’un Rollup : bien qu’il apparaisse comme une chaîne indépendante aux yeux des utilisateurs, en réalité, la « couché 2 » n’est qu’une fenêtre rapide exposée par le Rollup ; sa véritable structure en chaîne reste gravée sur Layer1. On peut donc considérer la L2 comme une demi-chaîne, ou une « chaîne créée sur Layer1 ».
Billets réutilisables (Retryables)
Il convient de noter que les transactions inter-chaînes sont asynchrones et non atomiques. Contrairement aux transactions sur une même chaîne, il est impossible de connaître immédiatement le résultat ni de garantir qu’une action aura lieu à un moment donné sur l’autre chaîne. Ainsi, certaines transactions peuvent échouer pour des raisons mineures, mais grâce à des mécanismes appropriés comme les billets réutilisables (Retryable Tickets), aucun problème critique tel que la perte de fonds ne surviendra.
Le billet réutilisable est l'outil fondamental utilisé lors d’un dépôt via le pont officiel d’Arbitrum, aussi bien pour ETH que pour les jetons ERC20. Son cycle de vie comporte trois étapes :
1. Soumission du billet sur L1. Création et soumission du billet de dépôt via la fonction createRetryableTicket() dans le contrat Delayed Inbox.
2. Échange automatique sur L2. Dans la plupart des cas, le séquenceur échange automatiquement le billet pour l’utilisateur, sans intervention manuelle requise.
3. Échange manuel sur L2. Dans certains cas particuliers — par exemple si le prix du gaz sur L2 augmente soudainement et que le gaz prépayé est insuffisant — l’échange automatique échoue. L'utilisateur doit alors intervenir manuellement.
Attention : si l’échange automatique échoue, le billet doit être échangé manuellement dans les 7 jours. Sinon, soit il sera supprimé (avec perte définitive des fonds), soit un frais de renouvellement devra être payé pour prolonger sa validité.
Par ailleurs, bien que le processus de retrait via le pont officiel d’Arbitrum présente une certaine symétrie avec le dépôt, il n’existe pas de concept équivalent aux Retryables. Cela peut s’expliquer à la fois par le protocole Rollup lui-même et par plusieurs différences clés :
-
Aucun échange automatique n'est possible lors du retrait, car l'EVM ne dispose pas de minuteur ou de système automatisé. Sur L2, l'échange automatique est rendu possible grâce au séquenceur, mais sur L1, l'utilisateur doit interagir manuellement avec le contrat Outbox pour récupérer ses actifs.
-
Il n’y a pas de problème d’expiration du billet : dès que la période de contestation est terminée, le retrait peut être effectué à tout moment.
Ponts pour actifs ERC-20
Le transfert inter-chaînes des actifs ERC-20 est complexe. Réfléchissons à quelques questions :
-
Comment un jeton déployé sur L1 peut-il être déployé sur L2 ?
-
Son contrat correspondant sur L2 doit-il être déployé manuellement à l’avance, ou le système peut-il déployer automatiquement un contrat pour tout nouveau jeton ?
-
Quelle est l’adresse du contrat correspondant sur L2 pour un actif ERC-20 sur L1 ? Doit-elle être identique à celle de L1 ?
-
Comment un jeton nativement émis sur L2 peut-il être transféré vers L1 ?
-
Comment transférer des jetons dotés de fonctionnalités spéciales, comme les jetons Rebase ajustables ou les jetons générant des intérêts ?
Nous ne répondrons pas ici à toutes ces questions, car cela nécessiterait une explication trop longue. Elles servent uniquement à illustrer la complexité inhérente au transfert inter-chaînes des jetons ERC-20.
Actuellement, de nombreuses solutions de mise à l’échelle adoptent un système de liste blanche combiné à une gestion manuelle afin d’éviter les cas limites et les situations complexes.
Arbitrum utilise un système de Gateway qui résout la majorité des problèmes liés au transfert des ERC-20, offrant les caractéristiques suivantes :
-
Les composants Gateway existent par paires sur L1 et L2.
-
Le Gateway Router gère les mappages d'adresses entre Token L1<->Token L2, ainsi que les associations entre token et gateway.
-
Les gateways peuvent être classés en StandardERC20 gateway, Generic-custom gateway, Custom gateway, etc., permettant de traiter divers types de jetons ERC20 selon leurs fonctionnalités.
Prenons l'exemple simple du WETH pour illustrer la nécessité d’un gateway personnalisé.
WETH est un équivalent ERC20 de l’Ether. Étant donné que l’Ether, en tant que monnaie principale, ne supporte pas certaines fonctionnalités avancées dans de nombreuses dApps, un équivalent ERC20 est nécessaire. En envoyant ETH vers le contrat WETH, ceux-ci sont verrouillés et un montant équivalent de WETH est émis.
Inversement, on peut brûler du WETH pour récupérer de l’ETH. Il est donc évident que la quantité de WETH en circulation correspond toujours 1:1 à la quantité d’ETH verrouillée.
Si l’on transfère directement WETH vers L2, des anomalies apparaissent :
-
Impossible de défaire le wrapping (Unwrap) du WETH en ETH sur L2, car aucun ETH n’est verrouillé sur cette couche.
-
La fonction Wrap peut être utilisée, mais les nouveaux WETH ainsi créés ne pourront pas être défaits sur L1, car les contrats WETH sur L1 et L2 ne sont pas « symétriques ».
Ceci va à l’encontre du principe fondamental du WETH. Par conséquent, lors d’un transfert inter-chaînes (dépôt ou retrait), le WETH doit d’abord être converti en ETH, puis transféré, avant d’être à nouveau converti en WETH sur la destination. C’est précisément le rôle du WETH Gateway.
De même, tout jeton à logique complexe nécessite un Gateway soigneusement conçu pour fonctionner correctement dans un environnement inter-chaînes. Les Gateways personnalisés d’Arbitrum reprennent la logique de communication inter-chaînes standard, tout en permettant aux développeurs de définir des comportements spécifiques adaptés à chaque jeton, répondant ainsi à la majorité des besoins.
Boîte lente (Delayed Inbox)
Contrairement à la « boîte rapide » (SequencerInbox), la « boîte lente » (Delayed Inbox, ou simplement Inbox) existe pour une bonne raison : la boîte rapide est exclusivement dédiée aux lots de transactions L2 publiés par le séquenceur. Toute transaction non prétraitée par le séquenceur ne doit pas figurer dans ce contrat.
La première fonction du Delayed Inbox est de gérer les dépôts de L1 vers L2. Lorsqu’un utilisateur effectue un dépôt via le Delayed Inbox, le séquenceur l’écoute et reflète l’opération sur L2. Cette transaction est ensuite incluse par le séquenceur dans un lot de transactions envoyé au contrat Sequencer Inbox (boîte rapide).
Dans ce cas, il serait inapproprié pour l’utilisateur de soumettre directement sa transaction de dépôt au Sequencer Inbox, car cela perturberait l’ordre normal des transactions L2 et affecterait le travail du séquenceur.
La deuxième fonction du Delayed Inbox est la résistance à la censure. Les transactions soumises directement au contrat Delayed Inbox sont généralement intégrées dans la boîte rapide par le séquenceur sous 10 minutes. Toutefois, si le séquenceur ignore malicieusement une requête, le Delayed Inbox dispose d'une fonction d’inclusion forcée (force inclusion) :
Si une transaction soumise au Delayed Inbox n’a pas été incluse dans la séquence après 24 heures, l’utilisateur peut déclencher manuellement la fonction force inclusion sur Layer1, forçant ainsi l’intégration de la transaction ignorée dans le Sequencer Inbox. À partir de là, tous les nœuds Arbitrum One la détecteront et elle sera obligatoirement incluse dans la séquence de transactions L2.
Comme mentionné précédemment, les données de la boîte rapide constituent l’historique réel de L2. Ainsi, en cas de censure malveillante, le Delayed Inbox permet d’inscrire finalement toute instruction de transaction dans le grand livre L2, y compris des scénarios critiques comme le retrait forcé hors de la L2.
On comprend donc que, quel que soit le sens ou le niveau de la transaction, le séquenceur ne peut jamais vous censurer de façon permanente.
Fonctions principales du Delayed Inbox :
-
depositETH() : fonction la plus simple pour déposer de l’ETH.
-
createRetryableTicket() : permet de déposer ETH, ERC20 ou des messages. Plus flexible que depositETH(), notamment en permettant de spécifier l’adresse destinataire sur L2.
-
forceInclusion() : fonction d’inclusion forcée, appelable par n’importe qui. Elle vérifie si une transaction soumise au Delayed Inbox n’a pas été traitée après 24 heures, et si oui, procède à son intégration forcée.
Notez toutefois que la fonction forceInclusion() se trouve techniquement dans le contrat de la boîte rapide, mais pour des raisons de clarté, nous la présentons ici avec le Delayed Inbox.
Boîte de sortie (Outbox)
L’Outbox est uniquement lié aux retraits, agissant comme un système d’enregistrement et de gestion des sorties :
-
Nous savons que le retrait via le pont officiel d’Arbitrum nécessite environ 7 jours de période de contestation. Une fois le bloc Rollup définitivement confirmé, l’utilisateur peut envoyer une preuve de Merkle au contrat Outbox sur Layer1. Ce dernier communique alors avec d’autres contrats (par ex. pour déverrouiller des actifs) afin de finaliser le retrait.
-
Le contrat Outbox enregistre quels messages inter-chaînes (L2 → L1) ont déjà été traités, empêchant ainsi les tentatives multiples d’exécution d’un même retrait.
-
À l’aide de mapping(uint256 => bytes32) public spent, il associe chaque index de retrait (spentIndex) à ses données. Si mapping[spentIndex] != bytes32(0), cela signifie que la demande a déjà été traitée. Ce mécanisme est similaire au nonce contre les attaques de rejeu.
Nous allons maintenant expliquer en détail les processus complets de dépôt et de retrait pour ETH. Pour les jetons ERC20, le processus est identique, à l’exception du passage par un Gateway, que nous ne répéterons pas.
Dépôt d’ETH
1. L'utilisateur appelle la fonction depositETH() du Delayed Inbox.
2. Cette fonction appelle ensuite bridge.enqueueDelayedMessage() pour enregistrer le message dans le contrat bridge, et transfère l’ETH vers ce contrat. Tous les fonds déposés sont conservés dans le contrat bridge, agissant comme une adresse de dépôt.
3. Le séquenceur détecte le message de dépôt dans le Delayed Inbox et met à jour la base de données L2. L’utilisateur voit alors ses fonds apparaître sur le réseau L2.
4. Le séquenceur inclut cet enregistrement de dépôt dans un lot de transactions envoyé au contrat Sequencer Inbox sur Layer1.
Retrait d’ETH
1. L’utilisateur appelle la fonction withdrawEth() du contrat ArbSys sur L2 pour brûler la quantité correspondante d’ETH.
2. Le séquenceur envoie cette demande de retrait au Sequencer Inbox.
3. Les nœuds validateurs créent un nouveau bloc Rollup basé sur la séquence du Sequencer Inbox, incluant cette transaction de retrait.
4. Une fois le bloc Rollup confirmé après la période de contestation, l’utilisateur peut appeler la fonction Outbox.executeTransaction() sur Layer1, en fournissant les paramètres fournis par le contrat ArbSys.
5. Après vérification, le contrat Outbox déverrouille l’ETH correspondant dans le contrat bridge et l’envoie à l’utilisateur.
Retrait rapide
Utiliser le pont officiel d’un Rollup optimiste implique d’attendre la période de contestation. Pour éviter cela, on peut recourir à des ponts tiers privés :
-
Échange avec verrou atomique (Atomic swap). Cette méthode consiste à échanger des actifs sur chacune des chaînes, de manière atomique : dès qu’un participant fournit la préimage, les deux parties obtiennent leurs actifs. Problème : la liquidité est rare, et il faut trouver un partenaire point à point.
-
Ponts par témoin. La plupart des ponts inter-chaînes relèvent de ce modèle. L’utilisateur soumet sa demande de retrait vers l’opérateur ou le pool de liquidité du pont tiers. Dès que le témoin constate que la transaction a été soumise au Sequencer Inbox sur L1, il transfère directement les fonds sur L1. Ce système repose essentiellement sur un autre consensus surveillant la L2 et agissant selon les données soumises sur L1. Inconvénient : la sécurité est moindre comparée au pont officiel du Rollup.
Retrait forcé
La fonction forceInclusion() permet de contrer la censure du séquenceur, quelle que soit la nature de la transaction (locale L2, L1→L2 ou L2→L1). Une censure malveillante nuisant gravement à l’expérience utilisateur, on choisira souvent de quitter la L2. Voici donc un exemple de retrait forcé utilisant forceInclusion.
Rappel : dans le processus de retrait ETH, seules les étapes 1 et 2 sont sensibles à la censure. Seules celles-ci doivent donc être modifiées :
-
Appeler la fonction inbox.sendL2Message() sur le contrat Delayed Inbox de L1, en entrant les mêmes paramètres que ceux requis par withdrawEth() sur L2. Ce message est relayé au contrat bridge sur L1.
-
Après 24 heures d’attente, appeler forceInclusion() sur le Sequencer Inbox pour forcer l’inclusion. Le contrat vérifie alors la présence du message dans le bridge.
L’utilisateur peut ensuite retirer via l’Outbox, les étapes restantes étant identiques à un retrait normal.
En outre, le dépôt arbitrum-tutorials contient des tutoriels détaillés utilisant le SDK Arb pour guider les utilisateurs sur l’utilisation de forceInclusion() pour les transactions locales L2 et L2→L1.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
