Texte principal : Dans les articles précédents, nous avons mentionné que le contrat Sequencer Inbox est spécifiquement conçu pour recevoir des lots de données de transaction publiées par le séquenceur sur la couche 1. Dans le même temps, nous avons fait remarquer que la boîte de réception du séquenceur est également appelée « boîte rapide », son homologue étant la boîte de réception différée (appelée boîte de réception). Ensuite, nous fournirons une explication détaillée des composants liés à la transmission de messages entre chaînes, tels que la boîte de réception différée.

Le principe de l'interchaîne et du pontage

Les transactions inter-chaînes peuvent être divisées en L1 à L2 (dépôt) et L2 à L1 (retrait). Notez que le dépôt et le retrait mentionnés ici ne sont pas nécessairement liés à des actifs inter-chaînes, mais peuvent être des messages qui n'incluent pas directement les actifs. Ces deux mots ne représentent donc que deux directions des comportements liés à l'interchaîne.

Par rapport aux transactions purement L2, les transactions inter-chaînes échangent des informations dans deux systèmes différents, L1 et L2, donc le processus est plus compliqué.

De plus, ce que nous appelons habituellement le comportement inter-chaînes est un comportement inter-chaînes sur deux réseaux indépendants à l'aide d'un pont inter-chaînes en mode témoin. La sécurité de ce pont inter-chaînes dépend du pont inter-chaînes. Historiquement, les ponts inter-chaînes basés sur le mode témoin étaient fréquemment victimes de vols.

En revanche, le comportement inter-chaînes entre Rollup et le réseau principal d'Ethereum est fondamentalement différent de celui des opérations inter-chaînes susmentionnées. C'est parce que 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 inter-chaînes Rollup officiel, sa structure opérationnelle est totalement sécurisée.

Cela met également en lumière l'essence de Rollup, qui, du point de vue de l'utilisateur, apparaît comme une chaîne indépendante. Cependant, 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 forme de chaîne est toujours enregistrée sur la couche 1. Nous pouvons donc considérer la L2 comme une demi-chaîne ou comme une « chaîne créée sur la couche 1 ».

Produits réutilisables

Il est important de noter que les opérations inter-chaînes sont asynchrones et non atomiques. Contrairement à une chaîne unique où le résultat d'une transaction est connu une fois celle-ci confirmée, les transactions interchaînes ne peuvent garantir que certains événements se produiront de l'autre côté à un moment précis. Par conséquent, les transactions inter-chaînes peuvent échouer à cause de problèmes mineurs, mais avec les bonnes méthodes, comme les tickets réessayables, il n'y aura aucun problème tel que le blocage des fonds.

Les billets réessayables sont des outils de base utilisés pour déposer des fonds via le pont officiel Arbitrum pour les jetons ETH et ERC20. Son cycle de vie comprend trois étapes :

1. Soumettre le ticket en L1 : créez un ticket de dépôt en utilisant la méthode createRetryableTicket () dans le contrat de boîte de réception différée et soumettez-le.

2. Remboursement automatique en L2 : Dans la plupart des cas, le séquenceur peut automatiquement échanger le billet pour l'utilisateur sans autre intervention manuelle.

3. Remboursement manuel sur la L2 : Dans certains cas extrêmes, comme une hausse soudaine du prix de l'essence sur la L2 alors que l'essence prépayée sur le billet est insuffisante, le remboursement automatique peut échouer. Dans ce cas, l'intervention manuelle de l'utilisateur est requise. Notez que si le remboursement automatique échoue, le billet doit être utilisé manuellement dans les 7 jours ; sinon, le billet peut être supprimé (entraînant une perte définitive de fonds) ou nécessiter le paiement de frais pour renouveler son bail.

De plus, dans le processus de retrait du pont officiel Arbitrum, bien qu'il existe une certaine similitude symétrique avec le comportement des dépôts en termes de processus, il n'existe aucun concept de Retryables. Cela peut être compris à la fois du point de vue du protocole Rollup lui-même et en examinant certaines différences :

• Il n'y a pas de remboursement automatique lors des retraits car l'EVM n'est pas doté de minuterie ni d'automatisation. Bien que le remboursement automatique puisse être mis en œuvre en L2 à l'aide du séquenceur, les utilisateurs en L1 doivent interagir manuellement avec le contrat Outbox pour réclamer leurs actifs.

• Il n'y a pas non plus de problème d'expiration des billets lors du retrait ; tant que la période de challenge est passée, les actifs peuvent être réclamés à tout moment.

Passerelle inter-chaînes ERC-20 Asset

Les transactions inter-chaînes impliquant des actifs de l'ERC-20 sont complexes. Nous pouvons nous poser plusieurs questions :

• Comment est déployé un jeton en L2 s'il est déployé en L1 ?
• Le contrat correspondant en L2 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 été transférés mais qui n'ont pas encore été déployés ?
• Quelle est l'adresse contractuelle d'un actif ERC-20 en L2 par rapport à son adresse en L1 ? Doit-elle correspondre à l'adresse sur la L1 ?
• Comment les jetons sont-ils émis de manière native entre la L2 et la L1 ?
• Comment se croisent les jetons dotés de fonctionnalités spéciales, telles que des jetons Rebase à approvisionnement ajustable ou des jetons de jalonnement automatique ?

Nous n'avons pas l'intention de répondre à toutes ces questions car elles sont trop complexes pour être abordées de manière exhaustive. Ces questions visent simplement à illustrer la complexité des transactions inter-chaînes ERC-20.

Actuellement, de nombreuses solutions de dimensionnement utilisent des solutions de liste blanche et de liste manuelle pour éviter divers problèmes complexes et conditions limites.

Arbitrum utilise un système de passerelle pour résoudre la plupart des problèmes liés aux transactions inter-chaînes ERC20, qui présente les caractéristiques suivantes :

• Les composants Gateway apparaissent par paires en L1 et en L2.
• Le Gateway Router est chargé de gérer les mappages d'adresses entre les jetons L1 <-> L2 et certains jetons <-> d'une passerelle.
• La passerelle elle-même peut être divisée en différents types, tels que la passerelle standard, la passerelle personnalisée générique, la passerelle personnalisée, etc., afin de résoudre les problèmes de passerelle liés aux différents types et fonctionnalités des jetons ERC20.

Pour illustrer la nécessité de passerelles personnalisées, prenons un exemple relativement simple de transfert WETH entre chaînes.

Le WETH est l'équivalent ERC20 de l'ETH. L'éther étant la monnaie principale, de nombreuses fonctionnalités complexes des DApps sont impossibles à accéder directement. Un équivalent ERC20 tel que WETH est donc nécessaire. En déposant des ETH dans le contrat WETH, ils sont bloqués dans le contrat, générant un montant équivalent de WETH.

De même, les WETH peuvent être brûlés pour retirer des ETH. De toute évidence, le montant en circulation de WETH et le montant bloqué d'ETH seront toujours maintenus à un ratio de 1:1.

Si nous relions maintenant directement le WETH à la L2, nous rencontrerons d'étranges problèmes :

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

Cela va clairement à l'encontre des principes de conception de WETH. Par conséquent, lorsque vous traversez une chaîne WETH, qu'il s'agisse d'un dépôt ou d'un retrait, il faut d'abord le déballer dans de l'ETH, puis le croiser et le remettre dans du WETH. C'est là que le WETH Gateway entre en jeu.

De même, pour les autres jetons dont la logique est plus complexe, ils nécessitent des passerelles plus sophistiquées et plus soigneusement conçues pour fonctionner correctement dans un environnement inter-chaînes. La passerelle personnalisée d'Arbitrum hérite de la logique de communication inter-chaînes d'une passerelle standard et permet aux développeurs de personnaliser les comportements inter-chaînes liés à la logique des jetons, afin de répondre à la plupart des exigences.

Boîte de réception différée

L'équivalent de la SequencerInbox, également connue sous le nom de boîte rapide, est la boîte de réception (officiellement nommée Delayed Inbox). Pourquoi fait-on une distinction entre les boîtes rapides et les boîtes différées ? Parce que le fast box est spécialement conçu pour recevoir des lots de transactions L2 publiées par le séquenceur, et que toutes les transactions non prétraitées par le séquenceur sur le réseau L2 ne devraient pas figurer dans le contrat Fast Box.

Le premier rôle de la slow box est de gérer le comportement des dépôts de la L1 à la L2. Les utilisateurs initient les dépôts via la boîte lente, que le séquenceur répercute ensuite sur L2. À terme, cet enregistrement de dépôt sera inclus dans la séquence des transactions L2 par le séquenceur et soumis au contrat Fast Box, le SequencerInbox.

Dans ce scénario, il n'est pas approprié pour les utilisateurs de soumettre directement des transactions de dépôt au Fast Box, car les transactions soumises au SequencerInbox interféreraient avec le séquencement normal des transactions de la couche 2, affectant ainsi le fonctionnement du séquenceur.

Le deuxième rôle de la boîte différée est la résistance à la censure. Les transactions directement soumises au contrat de boîte différée sont généralement agrégées dans la boîte rapide en 10 minutes par le séquenceur. Cependant, si le séquenceur ignore votre demande par malveillance, la boîte différée est dotée d'une fonction d'inclusion forcée :

Si une transaction est envoyée dans la boîte de réception différée et qu'elle n'est pas agrégée dans la séquence des transactions par le séquenceur au bout de 24 heures, les utilisateurs peuvent déclencher manuellement la fonction d'inclusion forcée sur la couche 1. Cette action force les demandes de transaction ignorées par le séquenceur à être agrégées dans la boîte rapide, le SequencerInbox, puis détectées par tous les nœuds Arbitrum One, pour être incluses de force dans la séquence des transactions de couche 2.

Comme nous l'avons mentionné tout à l'heure, les données de la zone rapide représentent l'entité de données historique de L2. Par conséquent, en cas de censure malveillante, les transactions peuvent être incluses dans le registre L2 en utilisant la case différée, qui couvre des scénarios tels que les retraits forcés depuis la couche 2.

Cela montre que le séquenceur ne peut finalement pas censurer définitivement les transactions, quelle que soit la direction ou la couche.

Les principales fonctions de la boîte de réception lente sont les suivantes :

• depositETH () : Cette fonction est la méthode la plus simple pour déposer des ETH.
• createRetryableTicket () : Cette fonction peut être utilisée pour déposer des ETH, des jetons ERC20 et des messages. Comparé à DepositETH (), il offre une plus grande flexibilité, comme la spécification de l'adresse de réception sur la L2 après le dépôt.
• ForceInclusion () : Également connue sous le nom de fonction d'inclusion de force, qui peut être appelée par n'importe qui. Cette fonction vérifie si une transaction soumise au contrat Slow Box n'a pas été traitée au bout de 24 heures. Si la condition est remplie, la fonction agrège le message de force.

Cependant, il est important de noter que la fonction ForceInclusion () est en fait intégrée au contrat Fast Box. Pour plus de clarté, nous en avons discuté ici en plus des fonctions de la boîte lente.

Boîte d'envoi

Outbox ne concerne que les retraits et peut être compris comme un système d'enregistrement et de gestion des comportements de retrait :

• Nous savons que les retraits sur le bridge officiel d'Arbitrum doivent attendre environ 7 jours pour que la période de challenge prenne fin, et que le retrait ne pourra être effectué qu'une fois le Rollup Block finalisé. À la fin de la période de challenge, l'utilisateur soumet le Merkle Proof to the Outbox correspondant au contrat Outbox sur Layer1, qui communique ensuite avec les contrats relatifs à d'autres fonctions (comme le déverrouillage d'actifs bloqués dans d'autres contrats), et termine enfin le retrait.
• Le contrat OutBox enregistre les messages inter-chaînes de L2 à L1 qui ont été traités afin d'empêcher quelqu'un de soumettre à plusieurs reprises des demandes de retrait exécutées. Pour ce faire, elle utilise un mappage appelé dépenses, qui associe les indices de dépenses des demandes de retrait aux informations correspondantes. Si vous cartographiez [SpentIndex] ! = bytes32 (0), cela indique que la demande a déjà été retirée. Le principe est similaire à celui d'un compteur de transactions, utilisé pour empêcher les attaques par replay.

Ci-dessous, nous expliquerons le processus de dépôt et de retrait en utilisant l'ETH comme exemple. Le processus pour les jetons ERC20 est similaire, avec l'ajout d'une passerelle, mais nous n'en parlerons pas plus ici.

Dépôt ETH

1. L'utilisateur appelle la fonction Depositeth () de la boîte de réception différée.
2. Cette fonction appelle ensuite Bridge.enqueueDelayedMessage (), qui enregistre le message contenu dans le contrat-relais et envoie l'ETH au contrat-relais. Tous les fonds ETH déposés sont détenus dans le contrat-relais, qui fait office d'adresse de dépôt.
3. Le séquenceur surveille le message de dépôt dans la boîte de réception différée et reflète l'opération de dépôt dans la base de données L2. Les utilisateurs peuvent consulter leurs actifs déposés sur le réseau L2.
4. Le séquenceur inclut l'enregistrement des dépôts d'un lot de transactions et le soumet au contrat Fast Inbox en L1.

Retrait de l'ETH

1. L'utilisateur appelle la fonction WithdrawETH () du contrat ArbSys en L2 et brûle la quantité correspondante d'ETH en L2.

2. Le séquenceur envoie la demande de retrait à la Fast Box.

3. Le nœud Validator crée un nouveau bloc cumulatif en fonction de la séquence des transactions dans la boîte rapide, qui contiendra les opérations de retrait ci-dessus.

4. Une fois le Rollup Block dépassé la période de défi et confirmé, l'utilisateur peut appeler la fonction Outbox.execute Transaction () en L1 pour prouver que les paramètres sont fournis par le contrat ArbSys mentionné ci-dessus.

5. Une fois que l'exactitude du contrat Outbox aura été confirmée, le montant correspondant d'ETH sur le bridge sera débloqué et envoyé à l'utilisateur.

Retraits rapides

Pour utiliser le pont officiel Rollup, qui est optimiste, il faut attendre une période de défi. Pour contourner ce problème, nous pouvons utiliser un pont inter-chaînes tiers privé :

• Atomic Swap Exchange : Dans cette approche, les actifs sont échangés entre les parties au sein de leurs chaînes respectives, et c'est atomique, ce qui signifie que si l'une des parties fournit la préimage, les deux parties peuvent obtenir les actifs correspondants. Cependant, les liquidités sont relativement rares, ce qui nécessite une recherche de contreparties entre pairs.
• Pont à chaînes croisées basé sur des témoins : La plupart des types de ponts à chaînes transversales entrent dans cette catégorie. Les utilisateurs soumettent leurs demandes de retrait en indiquant comme destination l'opérateur ou le pool de liquidités du pont tiers. Une fois que le témoin découvre que la transaction inter-chaînes a été soumise au contrat Fast Inbox en L1, il peut transférer des fonds directement à l'utilisateur en L1. Cette méthode utilise essentiellement un autre système de consensus pour surveiller la couche 2 et effectuer des opérations sur la base des données soumises à la couche 1. Cependant, le niveau de sécurité de ce mode est inférieur à celui du pont officiel Rollup.

Retrait forcé

La fonction ForceInclusion () est utilisée pour contrecarrer la censure des séquenceurs. Il peut être appliqué à toutes les transactions locales de niveau 2, de niveau 1 à niveau 2 et de niveau 2 à niveau 1. Comme la censure malveillante du séquenceur affecte de manière significative l'expérience des transactions, nous choisissons souvent de nous retirer de la L2. Voici un exemple d'utilisation de ForceInclusion () pour les retraits forcés :

Dans le contexte des retraits d'ETH, seules les étapes 1 et 2 impliquent la censure du séquenceur. Il nous suffit donc de modifier ces deux étapes :

• Appelez Inbox.sendL2Message () dans le cadre du contrat de boîte de réception différée en L1, avec les paramètres requis pour appeler WithdrawEth () en L2. Ce message est partagé avec le contrat de transition de la L1.
• Après avoir attendu le délai d'attente de 24 heures pour l'inclusion forcée, appelez ForceInclusion () dans le contrat Fast Inbox pour forcer l'inclusion. Le contrat Fast Inbox vérifiera s'il y a un message correspondant sur le pont.

Enfin, les utilisateurs peuvent effectuer des retraits depuis la boîte d'envoi, et les étapes restantes sont les mêmes que lors d'une procédure de retrait normale.

De plus, le référentiel Arbitrum propose des didacticiels détaillés qui expliquent aux utilisateurs comment effectuer des transactions locales de niveau 2 et des transactions de niveau 2 à niveau 1 à l'aide de ForceInclusion () via le SDK Arb.

Avertissement：

1. Cet article est repris de [Geek Web3]. Tous les droits d'auteur appartiennent à l'auteur original [Luo Benben, ancien ambassadeur technique d'Arbitrum, contributeur de Geek Web3]]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'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, de distribuer ou de plagier les articles traduits.