Dans l'article précédent, "La structure des composants d'Arbitrum interprétée par l'ancien ambassadeur technique d'Arbitrum (Partie 1)", nous avons présenté les rôles des composants clés d'Arbitrum, notamment le séquenceur, le validateur, le contrat de boîte de réception du séquenceur, le bloc de rollup, ainsi que le rôle des preuves de fraude non interactives. Dans l'article d'aujourd'hui, nous nous concentrerons sur l'explication des composants liés à la transmission de messages entre chaînes et à l'entrée des transactions anti-censure dans les composants de base d'Arbitrum.

Texte principal : Dans les articles précédents, nous avons mentionné que le contrat Sequencer Inbox est spécifiquement conçu pour recevoir les lots de données de transaction publiés par le séquenceur sur la couche 1. En même temps, nous avons souligné que la boîte de réception du séquenceur est également appelée "boîte rapide" et qu'il existe, en revanche, une "boîte lente" ou boîte de réception différée (appelée boîte de réception). Vous trouverez ci-dessous une interprétation détaillée des composants liés au passage de messages entre chaînes, y compris la boîte de réception différée.

Le principe de la chaîne croisée et du pontage

Les transactions inter-chaînes peuvent être divisées en transactions de L1 à L2 (dépôt) et en transactions de L2 à L1 (retrait). Il est important de noter que les termes "dépôt" et "retrait" n'impliquent pas nécessairement le transfert d'actifs d'une chaîne à l'autre ; ils peuvent faire référence à la transmission de messages sans transfert direct d'actifs. Par conséquent, ces termes représentent simplement les deux directions des actions liées à la chaîne croisée.

Par rapport aux transactions L2 pures, les transactions inter-chaînes impliquent l'échange d'informations entre deux systèmes différents, L1 et L2, ce qui rend le processus plus complexe.

En outre, lorsque nous parlons d'actions inter-chaînes, il s'agit généralement de passer d'un réseau à l'autre sans aucun lien, en utilisant un pont inter-chaînes dans le cadre d'un modèle fédéré. La sécurité de ces opérations de chaîne croisée dépend de l'opérateur du pont de chaîne croisée et, historiquement, les incidents de vol ont été fréquents dans les ponts de chaîne croisée basés sur des témoins.

D'autre part, les actions inter-chaînes entre Rollup et le réseau principal de l'ETH sont fondamentalement différentes des processus inter-chaînes susmentionnés. En effet, l'état de la couche 2 est déterminé par les données enregistrées sur la couche 1. Tant que vous utilisez le pont officiel de la chaîne croisée du Rollup, son fonctionnement est structurellement sûr.

Cela met en évidence l'essence de Rollup qui, du point de vue de l'utilisateur, apparaît comme une chaîne indépendante, mais en réalité, ce que l'on appelle la "couche 2" n'est qu'une fenêtre d'affichage rapide ouverte par Rollup aux utilisateurs, et sa véritable structure en chaîne est toujours enregistrée sur la couche 1. Par conséquent, nous pouvons considérer L2 comme la moitié d'une chaîne ou "une chaîne créée sur la couche 1".

Retryables

Veuillez noter que les transactions inter-chaînes sont asynchrones et non atomiques. Contrairement aux transactions sur une seule chaîne, il n'est pas possible de terminer une transaction et de confirmer le résultat après une transaction sur une chaîne dans le cas des transactions inter-chaînes. Il n'y a pas non plus de garantie que quelque chose de spécifique se produira de l'autre côté à un moment donné. Par conséquent, les transactions entre chaînes peuvent échouer en raison de certains problèmes mineurs, mais avec l'utilisation de techniques appropriées, telles que les tickets réessayables, les problèmes difficiles tels que le blocage des fonds ne se produiront pas.

Les tickets à retenter sont des outils fondamentaux utilisés dans le pont officiel d'Arbitrum pendant les dépôts, applicables à la fois aux dépôts ETH et ERC20. Le cycle de vie se compose de trois étapes :

1. Soumission du ticket en L1 : Utilisez la méthode "createRetryableTicket()" du contrat Delayed Inbox pour créer un ticket de dépôt et le soumettre.
2. Remboursement automatique sur L2 : Dans la plupart des cas, le séquenceur peut automatiquement échanger le billet pour l'utilisateur sans nécessiter d'actions manuelles supplémentaires.
3. Remboursement manuel sur la ligne L2 : Dans certains cas extrêmes, tels qu'une hausse soudaine des prix de l'essence sur la L2, si la quantité d'essence prépayée sur le billet est insuffisante, le remboursement automatique ne peut pas avoir lieu. Dans ce cas, une intervention manuelle de l'utilisateur est nécessaire. Il est important de noter que si l'échange automatique échoue, l'utilisateur doit échanger manuellement le billet dans les 7 jours. Sinon, le billet sera supprimé (ce qui entraînera une perte permanente de fonds) ou l'utilisateur devra payer une certaine somme pour renouveler le stockage du billet.

Par ailleurs, en ce qui concerne le processus de retrait sur le pont officiel de l'Arbitrum, bien qu'il y ait une certaine symétrie dans le processus par rapport aux dépôts, il n'y a pas de concept de tickets réessayables. Cela peut se comprendre du point de vue du protocole Rollup lui-même, et certaines différences peuvent être mises en évidence :

• Il n'y a pas de remboursement automatique pendant le processus de retrait parce que le MVE n'a pas de minuterie ou d'automatisation. Sur L2, le rachat automatique peut être mis en œuvre, et il est facilité par le séquenceur. Par conséquent, les utilisateurs de L1 doivent interagir manuellement avec le contrat Outbox pour réclamer leurs biens.
• Il n'y a pas de problème d'expiration des billets lors des retraits. Tant que la période de défi est passée, les utilisateurs peuvent réclamer leurs biens à tout moment.

Passerelle inter-chaînes pour les actifs ERC-20

Le chaînage croisé des actifs ERC-20 est complexe. Nous pouvons nous poser plusieurs questions :

• Comment déployer un jeton déployé sur L1 sur L2 ?
• Le contrat L2 correspondant doit-il être déployé manuellement à l'avance, ou le système peut-il déployer automatiquement des contrats d'actifs pour les jetons qui ont franchi le seuil mais n'ont pas encore déployé de contrat ?
• Pour les actifs ERC-20 sur L1, quelle est l'adresse du contrat correspondant sur L2 ? Doit-elle être cohérente avec celle de L1 ?
• Comment les jetons émis nativement sur L2 peuvent-ils être transférés sur L1 ?
• Comment les jetons ayant des fonctions spéciales, tels que les jetons de rebase avec des quantités ajustables et les jetons porteurs d'intérêts à croissance automatique, peuvent-ils faire l'objet d'une chaîne croisée ?

Nous n'allons pas répondre à toutes ces questions car elles sont trop complexes pour être développées. Ces questions servent uniquement à illustrer la complexité de la chaîne croisée ERC20.

Actuellement, de nombreuses solutions de mise à l'échelle utilisent des listes blanches et des listes manuelles pour éviter divers problèmes complexes et conditions limites.

Arbitrum utilise le système Gateway pour résoudre la plupart des problèmes de blocage de la chaîne croisée ERC20. Il présente les caractéristiques suivantes :

• Les composants de la passerelle apparaissent par paires à L1 et L2.
• Le routeur passerelle est chargé de maintenir la correspondance des adresses entre Token L1<->Token L2. En outre, la correspondance entre certains jetons<->certaines passerelles.
• La passerelle elle-même peut être divisée en passerelle ERC20 standard, passerelle générique-personnalisée, passerelle personnalisée, etc., pour résoudre les différents types et fonctions des problèmes de pontage ERC20.

Prenons l'exemple relativement simple de la chaîne croisée WETH pour illustrer la nécessité de personnaliser la passerelle.

Le WETH est un équivalent ERC20 de l'ETH. En tant que monnaie principale, l'Ether ne peut pas mettre en œuvre des fonctions complexes dans de nombreuses dApps, c'est pourquoi un équivalent ERC20 est nécessaire. Transférez quelques ETH dans le contrat WETH, ils seront bloqués dans le contrat, et la même quantité de WETH sera générée.

De la même manière, le WETH peut être brûlé et l'ETH peut être retiré. Il est évident que le rapport entre les WETH en circulation et les ETH bloqués est toujours de 1:1.

Si nous croisons maintenant directement la chaîne WETH avec la chaîne L2, nous allons rencontrer d'étranges problèmes :

• Il est impossible de déballer le WETH en ETH sur L2 car il n'y a pas d'ETH correspondant pour le verrouillage sur L2.
• La fonction Wrap peut être utilisée, mais si ces WETH nouvellement générés sont renvoyés vers L1, ils ne peuvent pas être décapsulés en ETH sur L1 parce que les contrats WETH sur L1 et L2 ne sont pas "symétriques".

Il est évident que cela va à l'encontre des principes de conception de WETH. Par conséquent, lorsque le WETH fait l'objet d'une chaîne croisée, qu'il s'agisse d'un dépôt ou d'un retrait, il doit d'abord être déballé en ETH, puis traversé de l'autre côté, et enfin emballé en WETH. C'est le rôle du portail WETH.

Il en va de même pour d'autres jetons à la logique plus complexe, qui nécessitent une passerelle plus complexe et soigneusement conçue pour fonctionner correctement dans un environnement inter-chaînes. La passerelle personnalisée d'Arbitrum hérite de la logique de communication inter-chaîne de la passerelle ordinaire et permet aux développeurs de personnaliser le comportement inter-chaîne lié à la logique des jetons, ce qui peut répondre à la plupart des besoins.

Boîte de réception retardée

La contrepartie de la boîte de réception rapide, connue sous le nom de boîte de réception du séquenceur, est la boîte de réception lente (appelée aussi boîte de réception différée). Pourquoi faire la différence entre rapide et lent ? En effet, la boîte de réception rapide est dédiée à la réception de lots de transactions L2 publiés par le séquenceur, et toutes les transactions non prétraitées par le séquenceur au sein du réseau L2 ne doivent pas apparaître dans le contrat de la boîte de réception rapide.

La première fonction de la boîte de réception lente est de gérer le processus de dépôt de L1 à L2. Les utilisateurs effectuent des dépôts par l'intermédiaire de la boîte de réception lente et, une fois que le séquenceur l'a constaté, il le répercute sur L2. Finalement, cet enregistrement de dépôt est inclus dans la séquence de transactions L2 par le séquenceur et soumis au contrat de boîte de réception rapide (boîte de réception du séquenceur).

Dans ce scénario, il n'est pas approprié que les utilisateurs soumettent directement des transactions de dépôt à la boîte de réception rapide (boîte de réception du séquenceur), car les transactions soumises à la boîte de réception rapide peuvent perturber l'ordre normal des transactions dans la couche 2, affectant ainsi le fonctionnement du séquenceur.

La deuxième fonction de la boîte de réception lente est de résister à la censure. Les transactions directement soumises au contrat de la boîte de réception lente sont généralement regroupées dans la boîte de réception rapide dans un délai de 10 minutes par le séquenceur. Toutefois, si le séquenceur ignore malicieusement votre demande, la boîte de réception lente dispose d'une fonction d'inclusion forcée :

Si une transaction est soumise à la boîte de réception différée et que, après 24 heures, elle n'est toujours pas incorporée dans la séquence de transactions par le séquenceur, les utilisateurs peuvent déclencher manuellement la fonction d'inclusion forcée sur la couche 1. Cette action oblige les transactions ignorées par le séquenceur à être regroupées de force dans la boîte de réception rapide (boîte de réception du séquenceur). Par la suite, ils seront détectés par tous les nœuds Arbitrum One et inclus de force dans la séquence de transactions de la couche 2.

Nous venons de mentionner que les données de la boîte de réception rapide représentent l'entité de données historiques de L2. Par conséquent, en cas de censure malveillante, l'utilisation de la boîte de réception lente permet aux instructions de transaction d'être finalement incluses dans le grand livre L2, ce qui permet de couvrir des scénarios tels que les retraits forcés pour échapper à la couche 2.

Il en ressort que, quels que soient le sens et le niveau des transactions, le séquenceur ne peut en fin de compte pas vous censurer de manière permanente.

Plusieurs fonctions essentielles de la boîte de réception lente (Inbox) :

• depositETH() : La fonction la plus simple pour déposer de l'ETH.
• createRetryableTicket() : Utilisé pour le dépôt d'ETH, d'ERC20 et de messages. Elle offre une plus grande flexibilité que depositETH(), permettant des spécifications telles que l'adresse de réception en L2 après le dépôt.
• forceInclusion() : Cette fonction, la fonction d'inclusion forcée, peut être appelée par n'importe qui. La fonction vérifie si une transaction soumise au contrat de boîte de réception lente n'a pas été traitée après 24 heures. Si les conditions sont remplies, il inclut le message avec force.

Cependant, il est important de noter que la fonction d'inclusion de force est en fait située dans le contrat de boîte de réception rapide. Pour faciliter la compréhension, nous l'avons expliqué en même temps que la boîte de réception lente.

Boîte d'envoi

Outbox est uniquement lié aux retraits et peut être considéré comme un système d'enregistrement et de gestion des comportements de retrait :

• Nous savons que les retraits sur le pont officiel de l'Arbitrum doivent attendre environ 7 jours pour que la période de challenge se termine, et le retrait ne peut être effectué qu'après la finalisation du Rollup Block. À la fin de la période de défi, l'utilisateur soumet la preuve de Merkle correspondante au contrat Outbox de la couche 1, qui communique ensuite avec les contrats pour d'autres fonctions (telles que le déverrouillage des actifs bloqués dans d'autres contrats), et achève finalement le retrait.
• Le contrat OutBox enregistrera les messages inter-chaînes de L2 à L1 qui ont été traités afin d'éviter que quelqu'un ne soumette à plusieurs reprises des demandes de retrait exécutées. Il enregistre la correspondance entre l'index des dépenses et les informations de la demande de retrait en utilisant "mapping(uint256 => bytes32) public spent". Si mapping[spentIndex] != bytes32(0), la demande a été retirée. Le principe est similaire à celui du compteur de transactions Nonce pour prévenir les attaques par rejeu.

Ci-dessous, nous prendrons l'exemple de l'ETH pour expliquer en détail le processus de dépôt et de retrait. La seule différence entre l'ERC20 et l'ETH est que le premier utilise Gateway. Nous ne l'expliquerons pas en détail.

Dépôt d'ETH

1. L'utilisateur appelle la fonction depositETH() de la boîte lente.

2. Cette fonction continuera à appeler 'bridge.enqueueDelayedMessage()', enregistrez le message dans le contrat-passerelle et envoyez l'ETH au contrat-passerelle. Tous les fonds déposés en ETH sont conservés dans le contrat-pont, qui équivaut à une adresse de dépôt.

3. Le séquenceur surveille les messages de dépôt dans la boîte lente et répercute l'opération de dépôt dans la base de données L2. Les utilisateurs peuvent voir les actifs qu'ils ont déposés sur le réseau L2.

4. Le séquenceur inclut l'enregistrement de dépôt dans le lot de transactions et le soumet au contrat de boîte rapide sur L1.

Retrait de l'ETH

1. L'utilisateur appelle la fonction withdrawEth() du contrat ArbSys sur L2, et le nombre correspondant d'ET est brûlé sur L2.

2. Le séquenceur envoie la demande de retrait à la boîte express.

3. Le nœud de validation crée un nouveau bloc de rollup basé sur la séquence de transactions dans la boîte rapide, qui contiendra les transactions de retrait ci-dessus.

4. Une fois que le bloc Rollup a passé la période d'essai, qui est également confirmée, l'utilisateur peut appeler la fonction Outbox.execute Transaction() sur L1 pour prouver que les paramètres sont donnés par le contrat ArbSys mentionné ci-dessus.

5. Une fois que le contrat Outbox est confirmé comme étant correct, la quantité correspondante d'ETH dans le pont sera débloquée et envoyée à l'utilisateur.

Retrait rapide d'argent

Lorsque vous utilisez le pont officiel du Rollup optimiste pour retirer de l'argent, il y a un problème d'attente de la période de challenge. Nous pouvons utiliser un pont inter-chaînes privé pour résoudre ce problème :

• Échange de serrures atomiques. Cette méthode n'échange des actifs qu'entre les deux parties au sein de leurs chaînes respectives et est atomique. Tant que l'une des parties fournit Preimage, les deux parties obtiendront certainement les actifs qu'elles méritent. Mais le problème est que les liquidités sont relativement rares et qu'il faut trouver des contreparties par le biais d'une méthode "peer-to-peer".F
• Des témoins traversent le pont en chaîne. Les ponts transversaux sont généralement des ponts témoins. Les utilisateurs soumettent leurs propres demandes de retrait, et la destination du retrait renvoie à l'opérateur du pont tiers ou du pool de liquidités. Lorsque le témoin découvre que la transaction inter-chaîne a été soumise au contrat de boîte rapide L1, il peut directement transférer de l'argent à l'utilisateur du côté L1. Cette approche utilise essentiellement un autre système de consensus pour surveiller la couche 2 et fonctionner sur la base des données qu'elle a transmises à la couche 1. Le problème est que le niveau de sécurité de ce mode n'est pas aussi élevé que celui du pont Rollup officiel. \

Retrait forcé

La fonction force Inclusion() est utilisée pour résister à la censure du séquenceur. Cette fonction permet de mettre en œuvre n'importe quelle transaction locale L2, transaction L1 vers L2 et transaction L2 vers L1. La censure malveillante du séquenceur affecte gravement l'expérience de la transaction. Dans la plupart des cas, nous choisirons de retirer de l'argent et de quitter la L2. C'est pourquoi les paragraphes suivants utilisent le retrait forcé comme exemple pour présenter l'utilisation de forceInclusion.

Si l'on examine les étapes du retrait de l'EPF, seules les étapes 1 et 2 impliquent la censure du séquenceur, de sorte que seules ces deux étapes doivent être modifiées :

• Lors de l'appel de "inbox.sendL2Message()" dans le contrat de boîte lente sur L1, les paramètres d'entrée sont les paramètres qui doivent être entrés lors de l'appel de withdrawEth() sur L2. Ce message sera transmis au contrat de bridge sur L1.
• Après une période d'attente de 24 heures, force Inclusion() dans la boîte rapide est appelée pour effectuer l'inclusion forcée. Le contrat de boîte rapide vérifie s'il existe un message correspondant dans le pont.

Les utilisateurs finaux peuvent retirer de l'argent dans la boîte aux lettres, et les autres étapes sont les mêmes que pour les retraits normaux.

En outre, des tutoriels détaillés sur l'utilisation du SDK Arb dans arbitrum-tutorials guident les utilisateurs sur la manière d'effectuer des transactions locales L2 et des transactions L2 vers L1 par le biais de la fonction forceInclusion().

Clause de non-responsabilité：

1. Cet article est repris de[极客 Web3]. Tous les droits d'auteur appartiennent à l'auteur original[极客 Web3]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.