L’ancien ambassadeur technique d’Arbitrum explique la structure des composants d’Arbitrum (Partie II)

Auteur : Benben Luo, ancien ambassadeur technique d’Arbitrum, contributeur geek web3

Dans l’article précédent, « D’anciens ambassadeurs techniques d’Arbitrum expliquent la structure des composants d’Arbitrum (Partie I) », nous avons présenté le rôle des séquenceurs, des validateurs, des contrats SequencerInbox, des blocs de cumul et des preuves de fraude non interactives dans les composants de base d’Arbitrum, et dans l’article d’aujourd’hui, nous nous concentrerons sur les composants de base d’Arbitrum liés à la messagerie d’interaction inter-chaînes et aux entrées de transaction résistantes à la censure.

Corps : Dans un article précédent, nous avons mentionné que le contrat de boîte de réception du séquenceur reçoit spécifiquement le lot de paquets de transaction publiés par le séquenceur sur la couche 1. Dans le même temps, nous soulignons que la boîte de réception du séquenceur est également connue sous le nom de boîte de réception rapide, par opposition à la boîte de réception retardée de la boîte lente (boîte de réception en abrégé). **Ci-dessous, nous examinerons de plus près les composants liés à la messagerie d’interaction inter-chaînes, tels que la boîte de réception différée.

Principes de l’interaction inter-chaînes et du pont

Les transactions d’interaction inter-chaînes peuvent être divisées en L1 à L2 (dépôt) et L2 à L1 (retrait). Notez que les dépôts et les retraits mentionnés ici ne sont pas nécessairement liés à l’interaction inter-chaînes d’actifs et peuvent être des messages qui n’associent pas directement des actifs. Ces deux mots ne signifient donc que deux directions de comportement lié à l’interaction inter-chaînes.

Les transactions d’interaction inter-chaînes sont plus compliquées que les transactions L2 pures, les transactions d’interaction inter-chaînes ont des informations échangées dans deux systèmes différents, L1 et L2.

De plus, ce que nous appelons habituellement le comportement d’interaction inter-chaînes est une interaction inter-chaînes sur deux réseaux non liés avec un pont d’interaction inter-chaînes en mode témoin, et la sécurité de cette interaction inter-chaînes dépend de l’opérateur du pont d’interaction inter-chaînes, et le vol de ponts d’interaction inter-chaînes basé sur le modèle témoin s’est produit fréquemment dans l’histoire.

Le comportement d’interaction inter-chaînes entre le Rollup et l’ETHMainnet est fondamentalement différent de l’interaction inter-chaînes ci-dessus, car 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 d’interaction inter-chaînes de cumul, il est absolument sûr en termes de structure de fonctionnement. **

Cela met également en évidence l’essence de Rollup, c’est juste du point de vue de l’utilisateur, comme une chaîne indépendante, mais en fait, la soi-disant ** « Layer2 » n’est qu’une fenêtre d’affichage rapide de Rollup ouverte aux utilisateurs, et sa structure de chaîne réelle est toujours gravée sur la couche 1. Par conséquent, nous pouvons considérer L2 comme une demi-chaîne, ou « une chaîne créée sur la couche 1 ».

Ticket réessayable Retryables

Il convient de noter que l’interaction inter-chaînes est asynchrone et non atomique, il est impossible de connaître le résultat après avoir terminé une confirmation de transaction comme sur une chaîne, et il n’y a aucune garantie que quelque chose se passera de l’autre côté à un moment donné. Par conséquent, l’interaction inter-chaînes peut échouer en raison de certains problèmes mineurs, mais tant que les bons moyens sont utilisés, tels que le ticket réessayable, les problèmes difficiles tels que les fonds bloqués ne se produiront pas.

**Les tickets réessayables sont les outils de base utilisés lors du dépôt via le pont officiel d’Arbitrum, ** les dépôts ETH et ERC20 sont utilisés. Son cycle de vie est divisé en trois étapes :

**1. Soumettez le ticket sur L1. **Utilisez la méthode createRetryableTicket() dans le contrat de boîte de réception différée pour créer un ticket de dépôt et l’envoyer.

**2. Échange automatique sur L2. **Dans la plupart des cas, le séquenceur peut racheter automatiquement la facture pour l’utilisateur, sans qu’il soit nécessaire de procéder à une opération manuelle ultérieure.

**3. L2. **Dans certains cas marginaux, tels qu’une flambée soudaine des prix de l’essence sur L2 et une quantité insuffisante d’essence prépayée sur le billet, il ne sera pas automatiquement remboursé. Dans ce cas, cela doit être fait manuellement par l’utilisateur.

Notez que si le rachat automatique échoue, vous devrez rembourser manuellement le billet dans les 7 jours, sinon soit la facture sera supprimée (les fonds seront définitivement perdus), soit vous devrez payer des frais pour renouveler le bail pour la conservation de la facture.

De plus, bien qu’il existe une certaine similitude symétrique entre le processus de retrait du bridge officiel d’Arbitrum et le comportement de dépôt, il n’y a pas de concept de Retryables, qui peut être compris à partir du protocole Rollup lui-même d’une part, et de quelques différences d’autre part :

Il n’y a pas de rachat automatique dans le processus de retrait, car il n’y a pas de minuterie ou d’automatisation dans l’EVM, et le rachat automatique peut être réalisé sur L2, ce qui est réalisé à l’aide du séquenceur, de sorte que les utilisateurs sur L1 doivent interagir manuellement avec le contrat de boîte d’envoi pour récupérer des actifs avec Claim. Il n’y a pas de problème de factures impayées pour les retraits, tant que la période de contestation est passée, elle peut être réclamée à tout moment.

Passerelle d’interaction inter-chaînes d’actifs ERC-20

• L’interaction inter-chaînes des actifs ERC-20 est complexe. Il y a quelques questions que nous pouvons nous poser :
• Token déployé sur L1, comment se déploie-t-il sur L2 ?
• Son homologue L2 doit-il être déployé manuellement à l’avance, ou le système peut-il déployer automatiquement des contrats d’actifs pour les tokens qui traversent mais n’ont pas encore déployé le contrat ?
• Quelle est l’adresse contractuelle des actifs ERC-20 sur L1 correspondant à L2 ? Doit-elle être cohérente avec L1 ?
• Comment faire une interaction inter-chaînes vers L1 pour les tokens émis nativement sur L2 ?
• Tokens avec des fonctions spéciales, telles que le nombre réglable de tokens Rebase, les tokens portant intérêt auto-croissants, comment faire une interaction inter-chaînes ?

Nous n’allons pas répondre à toutes ces questions, car c’est trop compliqué de s’étendre. Ces questions ne sont utilisées que pour illustrer la complexité de l’interaction inter-chaînes ERC20.

À l’heure actuelle, de nombreuses solutions de mise à l’échelle utilisent des solutions de liste d’autorisation + d’inventaire manuel pour éviter divers problèmes complexes et situations limites.

Arbitrum utilise le système Gateway pour résoudre la plupart des problèmes liés à l’interaction inter-chaînes ERC20, avec les fonctionnalités suivantes :

• Les composants de passerelle s’affichent par paires en L1 et L2. Le routeur de passerelle est responsable de la gestion des mappages d’adresses entre le jeton L1<->jeton L2, ainsi qu’entre certains jetons <-> certaines passerelles.
• Les passerelles peuvent être divisées en passerelles ERC20 standard, passerelles génériques-personnalisées, passerelles personnalisées, etc., pour résoudre différents types et problèmes de pontage ERC20 fonctionnels.

Prenons l’exemple relativement simple de l’interaction inter-chaînes WETH pour illustrer la nécessité d’une passerelle personnalisée.

WETH est l’équivalent de l’ERC20 de ETH. Comme l’Ether est la pièce principale, de nombreuses fonctions complexes dans les dApps ne sont pas possibles, un équivalent ERC20 est donc nécessaire. Transférez des ETH dans le contrat WETH, elles seront bloquées dans le contrat et le même montant de WETH sera généré.

De la même manière, il est également possible de brûler du WETH et d’en retirer ETH. **Évidemment, la quantité de WETH en circulation et la quantité de ETH position de verrouillage seront toujours de 1 :1. **

Si nous intervenons maintenant avec l’interaction inter-chaînes WETH directement sur L2, nous trouverons des problèmes étranges :

• Il n’est pas possible de déplier WETH en ETH sur L2 car il n’y a pas de position de verrouillage correspondant à ETH sur L2.
• La fonction Wrap peut être utilisée, mais ces WETH nouvellement générés ne peuvent pas être décapsulés comme ETH sur L1 s’ils reviennent à L1, car les contrats WETH sur L1 et L2 ne sont pas « symétriques ».

De toute évidence, cela viole les principes de conception de WETH. **Ensuite, lorsque WETH est une interaction inter-chaînes, qu’il s’agisse d’un dépôt ou d’un retrait, il doit d’abord être déballé dans ETH, puis croisé du côté opposé, puis enveloppé dans WETH. C’est là qu’intervient la passerelle WETH.

D’autres jetons avec une logique plus complexe font de même, nécessitant des passerelles plus complexes et bien conçues pour fonctionner correctement dans un environnement d’interaction inter-chaînes. La passerelle personnalisée d’Arbitrum hérite de la logique d’interaction inter-chaînes des passerelles ordinaires et permet aux développeurs de personnaliser le comportement d’interaction inter-chaînes lié à la logique de jeton, ce qui peut répondre à la plupart des besoins.

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

La contrepartie de la boîte de réception du séquenceur est la boîte de réception retardée (boîte de réception retardée). Étant donné que la boîte rapide est dédiée à la réception du lot de transactions L2 publiées par le séquenceur, toutes les transactions qui n’ont pas été prétraitées par le séquenceur dans le réseau L2 ne doivent pas apparaître dans le contrat de la boîte rapide.

**La première fonction de la boîte lente est de gérer le comportement de recharge de L1 à L2. **L’utilisateur effectue un dépôt via la Slow Box, et le séquenceur l’écoute puis le reflète sur L2, et enfin l’enregistrement de dépôt sera inclus dans la séquence de transaction L2 par le séquenceur et soumis à la boîte de réception du séquenceur.

Dans cet exemple, il n’est pas approprié pour l’utilisateur d’envoyer la transaction de dépôt directement dans la boîte de réception du séquenceur, car la transaction envoyée dans la boîte de réception du séquenceur interférera avec l’ordre normal des transactions de la couche 2, puis affectera le travail du séquenceur.

La deuxième fonction de la slow box est de résister à la censure. **Les transactions soumises directement par les utilisateurs au contrat Slowbox seront collectées par le séquenceur dans un délai de 10 minutes. Mais si le séquenceur ignore malicieusement votre requête, la slowbox dispose également d’une fonction d’inclusion forcée :

Si la transaction est soumise à la boîte de réception différée, après 24 heures, la transaction dans la Slowbox n’a pas été incluse dans la séquence de transaction par le séquenceur, L’utilisateur peut déclencher manuellement la fonction d’inclusion forcée sur la couche 1, et les demandes de transaction ignorées par le séquenceur sont regroupées de force dans la boîte de réception du séquenceur Fastbox, puis elles seront surveillées par tous les nœuds Arbitrum One et seront incluses de force dans la séquence de transaction de couche 2.

Comme nous l’avons mentionné précédemment, les données de la boîte rapide sont l’entité de données historiques de L2. Par conséquent, dans le cas d’une censure malveillante, ** peut enfin inclure des instructions de transaction dans le registre L2 via la boîte lente, qui couvre des scénarios tels que les retraits forcés pour s’échapper de la couche 2. **

On peut en déduire que, quelle que soit la direction et le niveau des transactions, le séquenceur ne sera pas en mesure de vous examiner en permanence à la fin.

Plusieurs fonctions de base de la boîte de réception Slowbox :

• depositETH(), la fonction la plus simple pour déposer des ETH.
• createRetryableTicket(), qui peut être utilisé pour déposer des ETH et ERC20 ainsi que des messages. Par rapport à depositETH(), il a une plus grande flexibilité, comme la possibilité de spécifier l’adresse de réception de L2 après le dépôt.
• forceInclusion(), qui est la fonction d’agrégation forcée, peut être appelée par n’importe qui. Cette fonction permet de vérifier si une transaction soumise au contrat Slowbox n’a pas été traitée après 24 heures. Si les conditions sont remplies, le message sera agrégé de force.

Cependant, il convient de noter que la fonction d’inclusion de force est en fait située dans le contrat Slowbox, histoire de la rendre plus facile à comprendre, nous allons la mettre ici dans la Slowbox et l’expliquer ensemble.

Boîte d’envoi

La boîte d’envoi n’est liée qu’aux retraits, qui peuvent être compris comme un système d’enregistrement et de gestion du comportement de retrait :**

• Nous savons que les retraits du pont officiel d’Arbitrum doivent attendre la fin de la période de contestation d’environ 7 jours avant que le retrait puisse être mis en œuvre après la finalisation du blocage de cumul. À la fin de la période de défi, l’utilisateur soumet la preuve Merkle correspondante au contrat de boîte d’envoi sur la couche 1, qui communique avec d’autres contrats fonctionnels (tels que le déblocage d’actifs bloqués dans d’autres contrats) et termine enfin le retrait.
• Le contrat OutBox enregistrera les messages d’interaction inter-chaînes L2 à L1 qui ont été traités pour empêcher quelqu’un de soumettre à plusieurs reprises des demandes de retrait exécutées. Il utilise mapping(uint256 => octets32) public spen pour enregistrer l’index dépensé de la demande de retrait et la correspondance entre les informations, si le mappage[spentIndex] != bytes32(0), la requête a déjà été retirée. Le principe est similaire à celui du nonce de compteur de transactions qui empêche les attaques par rejeu.

Ci-dessous, nous prendrons ETH exemple pour expliquer pleinement le processus de dépôt et de retrait. La différence entre ERC20 et ERC20 est qu’il passe simplement par le Gateway, donc je ne vais pas le répéter.

ETH dépôt

1. L’utilisateur appelle la fonction depositETH() de la Slowbox.

2. La fonction continuera d’appeler bridge.enqueueDelayedMessage(), d’enregistrer le message dans le contrat de pont et d’envoyer ETH au contrat de pont. **Tous les fonds ETH dépôt sont conservés dans le contrat relais, ce qui équivaut à une adresse de dépôt. **

3. Le séquenceur écoute le message de dépôt dans la zone lente et reflète l’opération de dépôt à la base de données L2, afin que les utilisateurs puissent voir les actifs qu’ils ont déposés dans le réseau L2.

4. Le séquenceur inclura l’enregistrement de dépôt dans le lot et le soumettra au contrat Express sur L1.

ETH retraits

1. L’utilisateur appelle la fonction withdrawEth() du contrat ArbSys sur L2 pour brûler la quantité correspondante de ETH sur L2.

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

**3.Le nœud de validation crée un nouveau bloc de cumul basé sur la séquence de transaction dans la Fastbox, qui contiendra les transactions de retrait ci-dessus. **

4. Une fois que le bloc de cumul a passé la période de défi et est confirmé, l’utilisateur peut appeler la fonction Outbox.ute Transaction() sur L1 pour prouver que les paramètres sont donnés par le contrat ArbSys susmentionné.

5. Une fois que le contrat d’envoi a confirmé qu’il est correct, la quantité correspondante de ETH dans le pont déverrouillé est envoyée à l’utilisateur.

Paiements rapides

Les retraits effectués à l’aide du pont officiel Optimistic Rollup entraîneront une période d’attente pour la période de défi. Nous pouvons contourner ce problème avec des ponts d’interaction inter-chaînes tiers privés :

• Échange de verrou atomique. Cette méthode ne permet qu’aux deux parties d’échanger des actifs au sein de leurs chaînes respectives, et elle est atomique, tant qu’une partie fournit une préimage, les deux parties obtiendront certainement les actifs qu’elles méritent. Mais le problème, c’est que la liquidité est relativement rare, et qu’il faut trouver des contreparties en peer-to-peer.
• Pont d’interaction inter-chaînes témoin. **Le type général de pont d’interaction inter-chaînes est un pont témoin. Les utilisateurs soumettent leurs propres demandes de retrait à l’opérateur du pont tiers ou du pool de liquidités. Une fois que le témoin découvre que l’interaction inter-chaînes a été soumise au contrat de la 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 opérer sur les données qu’il a engagées dans la couche 1. **Le problème est que le facteur de sécurité dans ce mode n’est pas aussi élevé que le pont Rollup officiel. **

Paiements forcés

force Inclusion() est utilisé pour contrer la censure du séquenceur et peut être utilisé pour toutes les transactions L2 locales, L1 à L2 et L2 à L1. La censure malveillante du séquenceur a sérieusement affecté l’expérience de trading, et dans la plupart des cas, nous choisirons de nous retirer et de quitter L2, ce qui suit est donc un exemple de retrait forcé pour introduire l’utilisation de forceInclusion.

Rappelez-vous que dans l’étape de retrait ETH, seules les étapes 1 et 2 impliquent une révision du séquenceur, donc seules ces deux étapes doivent être modifiées :

• Appelez inbox.sendL2Message() dans le contrat slowbox sur L1, et le paramètre d’entrée est le paramètre qui doit être entré lors de l’appel de withdrawEth() sur L2. Le message est partagé avec le contrat passerelle sur L1.
• Après avoir attendu la période d’attente d’agrégation forcée de 24 heures, appelez la force Inclusion() dans la boîte fast pour forcer la collecte, et le contrat de la boîte rapide vérifiera s’il y a un message correspondant dans le pont.

L’utilisateur final peut effectuer un retrait dans la boîte d’envoi, et le reste des étapes est le même que pour les retraits normaux.

En outre, arbitrum-tutorials contient également des tutoriels détaillés sur la façon d’utiliser le SDK Arb pour guider les utilisateurs sur la façon d’utiliser forceInclusion() pour effectuer des transactions locales L2 et des transactions L2 vers L1.