L'ancien ambassadeur technique d'Arbitrum explique la structure des composants d'Arbitrum (partie 2)

Comment Arbitrum gère-t-il les messages inter-chaînes et les transactions résistantes à la censure ? Quel est son modèle de pont à chaînes croisées ?

Écrit par : Luo Benben, ancien ambassadeur technique d’Arbitrum et contributeur geek web3

Dans l’article précédent* “L’ancien ambassadeur technique d’Arbitrum interprète la structure des composants d’Arbitrum (partie 1)”**, nous avons introduit le séquenceur, le validateur, le contrat Sequencer Inbox, le bloc Rollup et la preuve de fraude non interactive dans les composants principaux d’Arbitrum. Dans l’article d’aujourd’hui, nous nous concentrerons sur les composants liés à la messagerie inter-chaînes et aux entrées de transactions résistantes à la censure parmi les composants principaux d’Arbitrum. *

Dans l’article précédent, nous avons mentionné que le contrat Sequencer Inbox reçoit spécifiquement le package de données de transaction Batch publié par le séquenceur sur Layer1. Dans le même temps, nous soulignons que Sequencer Inbox est également appelée boîte rapide, par opposition à boîte lente Delayed Inbox (appelée Inbox). Ci-dessous, nous fournirons une explication détaillée des composants liés à la messagerie inter-chaînes tels que la boîte de réception différée.

Principes de cross-chain et de pontage

Les transactions cross-chain peuvent être divisées en L1 à L2 (recharge) et L2 à L1 (retrait). Notez que la recharge et le retrait mentionnés ici ne sont pas nécessairement liés aux 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 de comportements liés à l’ensemble des chaînes.

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

De plus, ce que nous appelons habituellement le comportement cross-chain est un cross-chain sur deux réseaux non liés utilisant un pont cross-chain en mode témoin. La sécurité de ce cross-chain dépend du pont cross-chain. Opérateurs, vol de cross-chain Les ponts à chaînes basés sur le modèle témoin se sont produits fréquemment dans l’histoire.

Le comportement inter-chaînes entre Rollup et le réseau principal ETH est essentiellement différent de l’inter-chaîne mentionné ci-dessus, car l’état de Layer2 est déterminé par les données enregistrées sur Layer1,** tant que vous utilisez le Rollup officiel. Le pont à chaînes croisées est absolument sûr dans sa structure opérationnelle. **

Cela met également en évidence l’essence de Rollup. Du point de vue de l’utilisateur, il ne ressemble qu’à une chaîne indépendante, mais en fait ce qu’on appelle “**Layer2” n’est qu’une fenêtre d’affichage rapide ouverte par Rollup aux utilisateurs. Son véritable type de chaîne La structure est toujours gravé sur Layer1. **Nous pouvons donc considérer L2 comme une demi-chaîne, ou « une chaîne créée sur Layer1 ».

Tickets réessayablesRéessayables

Il convient de noter que les chaînes croisées sont asynchrones et non atomiques. Il est impossible de connaître le résultat après avoir confirmé une transaction comme sur une chaîne, ni de garantir que quelque chose se passera de l’autre côté à un moment donné. . Par conséquent, le cross-chain peut échouer en raison de certains problèmes mineurs, mais tant que les bons moyens sont utilisés, tels que Retryable Ticket, des problèmes difficiles tels que des blocages de fonds ne se produiront pas.

Les tickets réessayables sont les outils de base utilisés lors des dépôts via le pont officiel d’Arbitrum. Les dépôts ETH et ERC20 seront utilisés. Son cycle de vie se divise en trois étapes :

**1. Soumettez le ticket sur L1. **Utilisez la méthode createRetryableTicket() dans le contrat Delayed Inbox pour créer un ticket de recharge et le soumettre.

**2. Rachat automatique sur L2. **Dans la plupart des cas, le trieur peut automatiquement aider les utilisateurs à payer leurs factures sans opérations manuelles ultérieures.

**3. Rachat manuel sur L2. **Dans certains cas extrêmes, comme une hausse soudaine des prix du gaz sur L2 et une insuffisance de gaz prépayé sur le billet, le paiement automatique ne peut pas être effectué. À ce stade, une opération manuelle par l’utilisateur est requise.

Notez que si le rachat automatique échoue, le billet doit être racheté manuellement dans les 7 jours, sinon soit le billet sera supprimé (les fonds seront définitivement perdus), soit des frais devront être payés pour sauvegarder le billet afin de renouveler le bail.

De plus, bien que le processus de retrait du pont officiel Arbitrum présente une certaine similitude symétrique avec le comportement de recharge, il n’y a pas de concept de Retryables. D’une part, cela peut être compris à partir du protocole Rollup lui-même, et d’autre part, nous pouvons le comprendre à partir de quelques différences :

• **Il n’y a pas de rachat automatique pendant le processus de retrait, **car EVM n’a pas de minuterie ni d’automatisation, et le rachat automatique peut être réalisé sur L2, qui est implémenté à l’aide du séquenceur, donc les utilisateurs sur L1 doivent manuellement interagir avec le contrat Outbox pour réclamer les actifs Récupérer.
• **Il n’y a aucun problème d’expiration du ticket lors du retrait d’argent. **Tant que la période de défi est passée, vous pouvez le recevoir à tout moment.

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

** Les actifs ERC-20 inter-chaînes sont complexes. Nous pouvons réfléchir à plusieurs questions :**

• Un token déployé sur L1, comment le déployer sur L2 ?
• Son 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 traversé 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-il être cohérent avec la L1 ?
• Comment cross-chain des tokens émis nativement sur L2 vers L1 ?
• Comment les jetons dotés de fonctions spéciales, tels que les jetons de rebase avec des quantités réglables et les jetons portant intérêt à croissance automatique, peuvent-ils être inter-chaînes ?

Nous n’allons pas répondre à toutes ces questions car elles sont trop complexes à aborder. Ces questions ne sont utilisées que pour illustrer la complexité du cross-chain ERC20.

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

**Arbitrum utilise le système Gateway pour résoudre la plupart des problèmes inter-chaînes de l’ERC20. **Il présente les caractéristiques suivantes :

• Les composants de la passerelle apparaissent par paires en L1 et L2.
• **Le routeur passerelle est responsable du maintien du mappage d’adresses entre le jeton L1<->Jeton L2, ** et du mappage entre un jeton<->une passerelle.
• La passerelle elle-même peut être divisée en passerelle StandardERC20, passerelle générique personnalisée, passerelle personnalisée, etc. pour résoudre différents types et fonctions de problèmes de pontage ERC20.

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

WETH est un équivalent ERC20 de l’ETH. En tant que monnaie principale, Ether ne peut pas implémenter de fonctions complexes dans de nombreuses dApps, un équivalent ERC20 est donc nécessaire. Transférez des ETH dans le contrat WETH, ils seront verrouillés dans le contrat et le même montant de WETH sera généré.

De la même manière, WETH peut également être détruit et ETH retiré. De toute évidence, le nombre de WETH en circulation et d’ETH verrouillés est toujours de 1 : 1. **

Si nous lions maintenant WETH directement à L2, nous trouverons des problèmes étranges :

• Il est impossible de déballer 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 car les contrats WETH sur L1 et L2 ne sont pas “symétriques”**.

Évidemment, cela viole les principes de conception de WETH. **Ensuite, lorsque WETH est inter-chaînes, qu’il s’agisse d’une recharge ou d’un retrait, il doit d’abord être déballé dans ETH, puis traversé de l’autre côté, puis enveloppé dans WETH. **C’est le rôle de WETH Gateway.

Il en va de même pour les autres jetons dotés d’une 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înes de la passerelle ordinaire et permet aux développeurs de personnaliser le comportement inter-chaînes lié à la logique des jetons, qui peut répondre à la plupart des besoins.

Boîte de réception retardée

A la box rapide, également appelée SequencerInbox, correspond la box lente Inbox (nom complet Delayed Inbox)**. Pourquoi devrait-il y avoir une distinction entre vitesse et lenteur ? La fast box étant dédiée à la réception du lot de transactions L2 émis 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 fast box.

**La première fonction de la slow box est de gérer le comportement de recharge de L1 à L2. ** L’utilisateur recharge via la boîte lente, et le séquenceur le surveille puis le reflète sur L2. Enfin, l’enregistrement de recharge sera inclus dans la séquence de transaction L2 par le séquenceur et soumis au contrat de boîte rapide Sequencer Inbox.

Dans cet exemple, il n’est pas approprié pour les utilisateurs de soumettre des transactions de recharge directement à la boîte express, car les transactions soumises à la boîte express Sequencer Inbox interféreront avec le tri normal des transactions de la couche 2, et affecteront ensuite le travail du séquenceur.

La deuxième fonction de la slow box est de résister à la censure. Les utilisateurs soumettent directement les transactions au contrat de boîte lente, et le trieur les regroupera généralement dans la boîte rapide dans un délai de 10 minutes. Mais si le trieur ignore par malveillance votre demande, la slow box dispose également d’une fonction forcer l’inclusion :

Si une transaction est soumise dans la boîte de réception différée et qu’après 24 heures, la transaction dans la boîte lente n’a pas été incluse dans la séquence de transactions par le séquenceur, ** l’utilisateur peut déclencher manuellement la fonction d’inclusion forcée sur la couche 1, ** pour ignorez-le par le séquenceur. Les demandes de transaction sont collectées de force dans la boîte de réception du séquenceur, puis seront surveillées par tous les nœuds Arbitrum One et seront incluses de force dans la séquence de transactions de couche 2. **

Comme nous venons de le mentionner, les données de la case rapide sont l’entité de données historiques de L2. Par conséquent, en cas de censure malveillante, les instructions de transaction peuvent finalement être incluses dans le grand livre L2 via la boîte lente, qui couvre des scénarios tels que les retraits forcés et l’évasion de la couche 2. **

On peut en déduire que pour des transactions dans n’importe quelle direction et n’importe quel niveau, le séquenceur ne sera finalement pas en mesure de vous examiner en permanence.

Plusieurs fonctions essentielles de la boîte de réception Slow Box :

• depositETH(), la fonction la plus simple pour déposer de l’ETH.
• createRetryableTicket(), qui peut être utilisé pour l’ETH, l’ERC20 et la recharge des messages. Par rapport à depositETH(), il offre une plus grande flexibilité, par exemple, vous pouvez spécifier l’adresse de paiement L2 après le dépôt, etc.
• forceInclusion(), qui est la fonction de collecte forcée, peut être appelée par n’importe qui. Cette fonction vérifiera si une transaction soumise au contrat slow box n’a pas été traitée après 24 heures. Si les conditions sont remplies, les messages seront collectés de force.

Cependant, il convient de noter que la fonction d’inclusion de force se trouve en fait dans le contrat de la boîte rapide. Juste pour faciliter la compréhension, nous l’expliquerons ensemble dans la boîte lente.

Boîte d’envoi Boîte d’envoi

Outbox concerne uniquement les retraits et peut être compris comme un système d’enregistrement et de gestion des retraits :

• Nous savons que les retraits depuis le pont officiel d’Arbitrum doivent attendre environ 7 jours pour la fin de la période de défi et que le Rollup Block soit finalisé avant que le retrait puisse être mis en œuvre. Une fois la période de défi terminée, l’utilisateur soumet la preuve Merkle correspondante au contrat Outbox sur Layer1, qui communique ensuite avec les contrats pour d’autres fonctions (telles que le déverrouillage des actifs verrouillés dans d’autres contrats) et termine finalement le retrait.
• Le contrat OutBox enregistrera les messages inter-chaînes de L2 à L1 qui ont été traités pour empêcher quelqu’un de soumettre à plusieurs reprises des demandes de retrait exécutées. ça passe
• mapping(uint256 => bytes32) public dépensé, enregistre la correspondance entre l’indice de dépense de la demande de retrait et l’information, si mapping [spentIndex] != bytes32(0) alors la demande a été retirée. Le principe est similaire au compteur de transactions Nonce pour empêcher les attaques par rejeu.

Ci-dessous, nous prendrons l’ETH comme exemple pour expliquer pleinement le processus de dépôt et de retrait. La seule différence entre ERC20 et Gateway est qu’il ne sera pas décrit en détail.

Dépôt ETH

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

2. Cette fonction continuera à appeler bridge.enqueueDelayedMessage(), enregistrera le message dans le contrat de pont et enverra ETH au contrat de pont. **Tous les fonds de recharge ETH sont conservés dans le contrat relais, qui équivaut à une adresse de recharge. **

3. Le séquenceur surveille les messages de recharge dans la boîte lente et reflète l’opération de recharge dans la base de données L2. Les utilisateurs peuvent voir les actifs qu’ils ont rechargés sur le réseau L2.

4. Le séquenceur inclut l’enregistrement de recharge dans le lot de transactions et le soumet au contrat fast box sur L1.

Retrait d’ETH

1. L’utilisateur appelle la fonction RemoveEth() du contrat ArbSys sur L2 pour détruire le montant correspondant d’ETH sur L2.

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

3 **Le nœud Validator crée un nouveau bloc Rollup basé sur la séquence de transaction dans la boîte rapide, qui contiendra la transaction de retrait ci-dessus. **

4. Une fois que le bloc Rollup a passé la période de défi et a été 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 mentionné ci-dessus.

5. Une fois que le contrat Outbox a été confirmé comme étant correct, le montant correspondant d’ETH dans le pont déverrouillé sera envoyé à l’utilisateur.

Retrait rapide

**Si vous utilisez le pont officiel Optimistic Rollup pour retirer de l’argent, il y aura un problème d’attente pour la période de défi. Nous pouvons utiliser un pont inter-chaînes tiers privé pour contourner ce problème : **

• Échange de serrures atomiques. Cette méthode n’échange d’actifs qu’entre les deux parties au sein de leurs chaînes respectives et est atomique. Tant qu’une partie 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 point à point.
• **Témoin du pont à chaînes croisées. **Les types généraux de ponts à chaînes croisées sont des ponts témoins. Les utilisateurs soumettent leurs propres demandes de retrait et la destination du retrait pointe vers l’opérateur du pont tiers ou du pool de liquidité. Une fois que le témoin a découvert que la transaction cross-chain a été soumise au contrat fast box de L1, il peut transférer de l’argent directement à 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 soumises à la couche 1. **Le problème est que le facteur de sécurité dans ce mode n’est pas aussi élevé que celui du pont Rollup officiel. **

Retrait forcé

force Inclusion() La fonction d’inclusion forcée est utilisée pour résister à la révision du séquenceur.Toute transaction locale L2, transaction L1 à L2 et transaction L2 à L1 peut être implémentée à l’aide de cette fonction. L’examen malveillant du séquenceur affecte sérieusement l’expérience de la transaction. Dans la plupart des cas, nous choisirons de retirer de l’argent et de quitter L2. Par conséquent, ce qui suit utilise le retrait forcé comme exemple pour introduire l’utilisation de forceInclusion.

**Rappelez-vous que dans les étapes de retrait d’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 de boîte lente sur L1. Les paramètres d’entrée sont les paramètres qui doivent être saisis lors de l’appel de RemoveEth() sur L2. Ce message sera partagé avec le contrat relais sur L1.
• Après avoir attendu le délai d’attente d’inclusion forcée de 24 heures, appelez force Inclusion() dans la case rapide pour effectuer l’inclusion forcée. Le contrat de la boîte rapide vérifiera s’il y a un message correspondant dans le pont.

Les utilisateurs finaux peuvent retirer de l’argent dans Outbox et les étapes restantes sont les mêmes que pour les retraits normaux.

En outre, les didacticiels arbitrum proposent également des didacticiels détaillés sur l’utilisation du SDK Arb pour guider les utilisateurs sur la façon d’effectuer des transactions locales L2 et des transactions L2 à L1 via forceInclusion().