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

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

**Cet article est une interprétation technique d’Arbitrum One par Benben Luo, ancien ambassadeur technique d’Arbitrum et ancien cofondateur de Goplus Security, une société d’audit d’automatisation des contrats intelligents. **

Parce que les articles ou les matériaux impliquant la couche 2 dans le cercle chinois manquent d’une interprétation professionnelle d’Arbitrum et même de OP Rollup, cet article tente de combler cette lacune dans ce domaine en popularisant le mécanisme de fonctionnement d’Arbitrum. En raison de la complexité de la structure d’Arbitrum elle-même, le texte intégral compte toujours plus de 10 000 mots sur la base d’une simplification maximale, il est donc divisé en deux articles, qu’il est recommandé de rassembler et de transmettre comme documents de référence !**

Une brève description du séquenceur Rollup

Le principe de la mise à l’échelle par cumul peut se résumer en deux points :

Optimisation des coûts : déchargez la plupart des tâches de calcul et de stockage vers L1 hors chaîne, c’est-à-dire L2. **L2 est principalement une chaîne fonctionnant sur un seul serveur, c’est-à-dire un séquenceur/opérateur.

Le séquenceur ressemble à un serveur centralisé, abandonnant la « décentralisation » dans « Blockchain Impossible Three Times » en échange de TPS et d’avantages en termes de coûts. Les utilisateurs peuvent laisser L2 traiter les instructions de transaction au lieu d’Ethereum à un coût bien inférieur à celui du trading sur Ethereum.

**Sécurité : Le contenu de la transaction sur L2 et l’état après la transaction seront synchronisés avec Ethereum L1, et la validité de la transition d’état sera vérifiée par le biais du contrat. Dans le même temps, l’historique L2 sera conservé sur Ethereum, et même si le séquenceur est définitivement en panne, d’autres peuvent restaurer l’intégralité de l’état L2 grâce aux enregistrements sur Ethereum.

Fondamentalement, la sécurité des rollups est basée sur Ethereum. Si le séquenceur ne connaît pas la clé privée d’un compte, il ne peut pas initier de transactions au nom de ce compte, ni altérer le solde des actifs de ce compte (et même s’il le sait, il est rapidement reconnu).

Bien que le séquenceur soit centralisé en tant qu’épine dorsale du système, dans le schéma Rollup relativement mature, le séquenceur centralisé ne peut implémenter que des comportements malveillants tels que l’examen des transactions ou les temps d’arrêt malveillants, mais dans le schéma Rollup idéal, il existe des moyens correspondants pour le freiner (tels que des mécanismes de résistance à la censure tels que les retraits forcés ou les preuves de commande).

Les méthodes de vérification de l’état pour empêcher le séquenceur de cumul d’être maléfique sont divisées en deux types : la preuve de la fraude et la preuve de validité. Les cumuls utilisant des preuves de fraude sont appelés cumuls OP (cumuls optimistes, OPR) et, en raison de certains bagages historiques, les cumuls utilisant des preuves de validité sont souvent appelés cumuls ZK (Zero-knowledge Proof Rollups, ZKR) au lieu de cumuls de validité.

Arbitrum One est un OPR typique qui déploie des contrats sur L1 et ne valide pas activement les données soumises, croyant avec optimisme qu’il n’y a pas de problème avec les données. S’il y a une erreur dans les données soumises, le nœud de validation de L2 lance une contestation.

L’OPR implique donc également une hypothèse de confiance : il existe au moins un nœud validateur L2 honnête à un moment donné. Le contrat de ZKR, quant à lui, utilise la cryptographie pour vérifier activement mais de manière rentable les données soumises par le séquenceur.

Dans cet article, nous allons vous présenter en profondeur Arbitrum One, le projet leader dans le domaine des rollups optimistes, couvrant tous les aspects de l’ensemble du système, et après avoir lu attentivement, vous aurez une compréhension approfondie d’Arbitrum et du rollup/OPR optimiste.

Composants de base et flux de travail d’Arbitrum

Contrats de base :

Les contrats les plus importants d’Arbitrum incluent SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Nous y reviendrons plus tard.

Séquenceur:

Les transactions de l’utilisateur sont reçues et triées, les résultats de la transaction sont calculés et un reçu est renvoyé à l’utilisateur rapidement (généralement < 1). Les utilisateurs peuvent souvent voir leurs transactions sur la chaîne L2 en quelques secondes, tout comme une plateforme Web2.

Dans le même temps, le séquenceur diffusera également le dernier bloc L2 en temps réel sous la chaîne Ethereum, et n’importe quel nœud de couche 2 peut le recevoir de manière asynchrone. Mais à ce stade, ces blocs L2 ne sont pas finalisés et peuvent être annulés par le séquenceur.

Toutes les quelques minutes, le séquenceur compresse les données de transaction L2 triées, les agrège en lots et les soumet au contrat de boîte de réception SequencerInbox sur la couche 1 pour garantir la disponibilité des données et le fonctionnement du protocole de cumul. En général, les données L2 soumises à la couche 1 ne peuvent pas être restaurées et peuvent être finalisées.

À partir du processus ci-dessus, nous pouvons résumer : Layer2 a son propre réseau de nœuds, mais le nombre de ces nœuds est rare, et il n’y a généralement pas de protocole de consensus utilisé par la chaîne publique, donc la sécurité est très faible, et il doit être rattaché à Ethereum pour assurer la fiabilité de la publication des données et l’efficacité de la transition d’état.

Protocole de cumul d’Arbitrum :

Une série de contrats qui définissent la structure du Block RBlock de la chaîne Rollup, la continuation de la chaîne, la libération de RBlock et le processus du mode défi. Notez que la chaîne Rollup mentionnée ici n’est pas un registre de couche 2 tel que nous l’entendons, mais une « structure de données en chaîne » abstraite mise en place par Arbitrum One afin de mettre en œuvre un mécanisme de preuve de fraude.

Un RBlock peut contenir les résultats de plusieurs blocs L2, et les données sont également très différentes, et son entité de données RBlock est stockée dans une série de contrats dans RollupCore. S’il y a un problème avec un RBlock, le validateur contestera le commit de ce RBlock.

Validateur:

Le nœud validateur d’Arbitrum est en fait un sous-ensemble spécial des nœuds complets de couche 2, actuellement avec un accès à la liste d’autorisation.

Le validateur crée un nouveau RBlock (Rollup Block, également connu sous le nom d’assertion) basé sur le lot de transactions soumises par le séquenceur au contrat SequencerInbox, et surveille l’état de la chaîne de cumul actuelle pour contester les données erronées soumises par le séquenceur.

Les validateurs actifs nécessitent un jalonnement préalable des actifs sur la chaîne de ETH, parfois appelés jalonnements. Bien que les nœuds de couche 2 qui ne misent pas puissent également surveiller la dynamique de fonctionnement des Rollups, envoyer des alarmes anormales aux utilisateurs, etc., ils ne peuvent pas intervenir directement dans les données d’erreur soumises par le séquenceur sur la chaîne ETH.

Défi:

Les étapes fondamentales peuvent être résumées comme suit : segmentation interactive à plusieurs tours et preuves en une seule étape. Au cours de la session de segmentation, les deux parties sont mises au défi d’effectuer plusieurs cycles de subdivision au tour par tour des données de transaction problématiques jusqu’à ce que l’instruction de code d’opération de l’étape problématique soit décomposée et vérifiée. Le paradigme de la « segmentation multi-tours - preuve en une seule étape » est considéré par les développeurs d’Arbitrum comme la mise en œuvre la plus économe en gaz des preuves de fraude. Tout est sous contrôle contractuel, et aucune partie ne peut tricher.

Période du défi :

En raison de la nature optimiste du OP Rollup, une fois que chaque RBlock est soumis à la chaîne, le contrat ne le vérifie pas activement, ce qui laisse une fenêtre de temps aux validateurs pour falsifier. Cette fenêtre de temps est la période de défi, qui est de 1 semaine sur le réseau principal d’Arbitrum One. Une fois la période de défi terminée, le RBlock sera finalisé et le message correspondant de L2 à L1 dans le bloc (comme une opération de retrait effectuée via le pont officiel) pourra être libéré.

ArbOS, Geth, WAVM :

La machine virtuelle utilisée par Arbitrum s’appelle AVM, qui se compose de deux parties : Geth et ArbOS. Geth est le logiciel client le plus couramment utilisé d’Ethereum, et Arbitrum y a apporté de légères modifications. ArbOS est responsable de toutes les fonctions spéciales liées à la L2, telles que la gestion des ressources réseau, la génération de blocs L2, l’utilisation de l’EVM, etc. Nous considérons la combinaison des deux comme un AVM natif, qui est la machine virtuelle utilisée par Arbitrum. WAVM est le résultat de la compilation du code d’AVM dans Wasm. Dans le processus de contestation d’Arbitrum, la « preuve en une seule étape » finale vérifie les instructions WAVM.

Ici, nous pouvons illustrer la relation et le flux de travail entre les composants ci-dessus dans le diagramme suivant :

Cycle de vie des transactions L2

Voici comment fonctionne une transaction L2 :

1. L’utilisateur envoie une instruction de trading au séquenceur.

2. Le séquenceur vérifie d’abord les données telles que la signature numérique de la transaction à traiter, élimine la transaction non valide, trie et calcule.

3. Le séquenceur envoie le reçu de transaction à l’utilisateur (généralement très rapidement), mais il ne s’agit que du « prétraitement » de la chaîne hors ETH séquenceur, qui est dans un état de Soft Finality et n’est pas fiable. Mais pour les utilisateurs qui font confiance au séquenceur (la plupart des utilisateurs), il est optimiste que la transaction a été terminée et ne sera pas annulée.

4. Le séquenceur encapsule les données brutes de transaction prétraitées dans un lot après une compression élevée.

5. De temps en temps (sous l’effet de facteurs tels que le volume de données, l’encombrement ETH, etc.), le séquenceur publiera des lots de transactions dans le contrat de boîte de réception du séquenceur sur L1. À ce stade, la transaction peut être considérée comme ayant une finalité stricte.

Contrat de boîte de réception du séquenceur

Le contrat recevra le lot de transactions soumises par le séquenceur pour assurer la disponibilité des données. En regardant plus profondément, les données de lot dans SequencerInbox enregistrent complètement les informations d’entrée de transaction de la couche 2, même si le séquenceur est définitivement en panne, n’importe qui peut restaurer l’état actuel de la couche 2 en fonction de l’enregistrement de lot, en remplaçant le séquenceur défectueux/Rug pull.

Physiquement, ce que nous voyons comme L2 n’est qu’une projection du lot dans SequencerInbox, et la source de lumière est le STF. Étant donné que la source lumineuse STF ne change pas facilement, la forme de l’ombre n’est déterminée que par le lot qui fait office d’objet.

Le contrat de boîte de réception du séquenceur, également connu sous le nom de Fastbox, est un séquenceur qui lui soumet des transactions prétraitées, et seul le séquenceur peut lui soumettre des données. La boîte rapide correspondante est la boîte de réception lente Delayer Inbox, et ses fonctions seront décrites dans le processus suivant.

Le validateur écoutera toujours le contrat SequencerInbox, et chaque fois que le séquenceur libère un lot dans le contrat, il lèvera un événement on-chain, et une fois que le validateur aura entendu cet événement, il téléchargera les données du lot, et après l’exécution locale, il libérera RBlock dans le contrat de protocole Rollup sur la chaîne ETH.

Le contrat-relais d’Arbitrum comporte un paramètre appelé accumulateur, qui enregistrera le nombre de lots L2 nouvellement soumis, ainsi que le nombre de transactions nouvellement reçues et d’informations sur la boîte de réception lente.

Le contrat SequencerInbox a deux fonctions principales :

ajouter le séquenceur L2Batch From Origin(), que le séquenceur appelle à chaque fois pour soumettre des données de lot au contrat Sequencer Inox.

force Inclusion(), qui peut être appelée par n’importe qui et est utilisée pour implémenter des transactions résistantes à la censure. Le fonctionnement de cette fonction sera expliqué plus en détail plus tard lorsque nous parlerons du contrat de boîte de réception différée.

Les deux fonctions appellent bridge.enqueueSequencerMessage() pour mettre à jour le paramètre accumulator accumulator dans le contrat bridge.

Prix de l’essence

De toute évidence, les transactions L2 ne peuvent pas être gratuites en raison des attaques DoS, des coûts de fonctionnement du séquenceur L2 lui-même et de la surcharge liée à la soumission de données sur L1. Lorsqu’un utilisateur initie une transaction au sein d’un réseau de couche 2, les frais de gaz sont structurés comme suit :

Le coût de publication des données généré par l’occupation des ressources de la couche 1 provient principalement des lots soumis par le séquenceur (chaque lot comporte de nombreuses transactions utilisateur), et le coût est finalement partagé à parts égales entre les initiateurs de la transaction. L’algorithme de tarification des frais générés par la publication de données est dynamique, et le séquenceur fixera le prix en fonction des profits et pertes récents, de la taille du lot et du prix actuel du gaz Ethereum.

Le coût encouru par les utilisateurs en raison de l’occupation des ressources de la couche 2 est fixé à un nombre maximum de gaz par seconde pouvant assurer le fonctionnement stable du système (actuellement 7 millions pour Arbitrum One). Les prix indicatifs de l’essence pour L1 et L2 sont suivis et ajustés par ArbOS, et la formule ne sera pas répétée ici pour le moment.

Bien que le processus spécifique de calcul du prix du gaz soit plus compliqué, les utilisateurs n’ont pas besoin de percevoir ces détails, et il est évident que les frais de transaction de cumul sont beaucoup moins chers que ETH réseau principal.

À l’épreuve de la fraude

Pour récapituler, L2 n’est en fait qu’une projection de l’entrée batch des transactions soumises par le séquenceur dans Fastbox, c’est-à-dire :

Entrées de transaction -> STF -> Sorties d’état。 L’entrée est déterminée, le STF est constant, et la sortie est également déterminée, et le système de preuve de fraude et le protocole Arbitrum Rollup est un système qui publie la racine de l’état de la sortie à L1 sous la forme de RBlock (alias assertion) et le prouve de manière optimiste.

Sur L1, il y a les données d’entrée publiées par le séquenceur, et il y a aussi l’état de sortie publié par le validateur. Regardons de plus près, est-il nécessaire de publier l’état de la couche 2 on-chain ?

Étant donné que l’entrée a entièrement déterminé la sortie et que les données d’entrée sont visibles publiquement, la soumission de l’état de sortie semble redondante, mais cette idée ignore le fait que le règlement de l’état est en fait nécessaire entre les systèmes L1-L2, c’est-à-dire le comportement proposé de L2 dans la direction de L1, et qu’il doit y avoir une preuve d’état.

Lors de la création d’un rollup, l’une des idées de base est de placer la majeure partie du calcul et du stockage sur L2 pour éviter le coût élevé de L1, ce qui signifie que L1 ne connaît pas l’état de L2, il aide uniquement le séquenceur L2 à publier les données d’entrée de toutes les transactions, mais n’est pas responsable du calcul de l’état de L2.

Le comportement de retrait consiste essentiellement à débloquer les fonds correspondants du contrat L1 en fonction du message d’interaction inter-chaînes donné par L2, à les transférer sur le compte L1 de l’utilisateur ou à effectuer d’autres choses.

À ce stade, le contrat de couche 1 vous demandera : quel est votre état sur la couche 2 et comment pouvez-vous prouver que vous êtes vraiment propriétaire des actifs que vous prétendez croiser. À ce stade, l’utilisateur doit fournir l’épreuve de Merkle correspondante, etc.

Ainsi, si nous construisons un cumul sans fonction de retrait, il est théoriquement possible de ne pas synchroniser l’état avec L1, et il n’y a pas besoin d’un système de preuve d’état tel que la preuve de fraude (bien que cela puisse causer d’autres problèmes). Mais dans la pratique, ce n’est clairement pas faisable.

Dans la preuve dite optimiste, le contrat ne vérifie pas si la sortie soumise à L1 est dans le bon état, et est optimiste que tout est correct. Le système de preuve optimiste suppose qu’il y a au moins un validateur honnête à un moment donné, et s’il y a un état erroné, il est contesté par la preuve de fraude.

L’avantage de cette conception est qu’il n’est pas nécessaire de valider activement chaque RBlock publié en L1 pour éviter de gaspiller du gaz. En fait, il n’est pas pratique pour OPR de vérifier chaque assertion, car chaque rblock contient un ou plusieurs blocs L2, et ce n’est pas différent de l’exécution de transactions L2 directement sur L1 pour réexécuter chaque transaction sur L1, ce qui perd le sens de la mise à l’échelle de la couche 2.

ZKR n’a pas ce problème, car ZK Proof est simple et n’a besoin de vérifier qu’une petite preuve, et n’a pas besoin d’exécuter de nombreuses transactions derrière la preuve. Par conséquent, ZKR n’est pas optimiste, et à chaque fois l’état de la version est vérifié mathématiquement par le contrat Verfier.

Bien que les preuves de fraude ne puissent pas être aussi concises que les preuves à divulgation nulle de connaissance, Arbitrum utilise un processus d’interaction au tour par tour « preuve en plusieurs étapes » et, en fin de compte, un seul code d’opération de machine virtuelle doit être prouvé, ce qui est relativement peu coûteux.

Protocole de cumul

Jetons un coup d’œil au fonctionnement du protocole Rollup, le point d’entrée pour lancer des défis et lancer des épreuves.

Le contrat de base du protocole Rollup est RollupProxy.sol, qui utilise une structure rare à double proxy pour assurer la cohérence de la structure de données, un proxy correspond à deux implémentations de RollupUserLogic.sol et RollupAdminLogic.sol, qui ne peuvent pas être correctement analysées dans des outils tels que Scan.

En outre, il existe le contrat ChallengeManager.sol pour gérer le défi, et la série de contrats OneStepProver pour déterminer les preuves de fraude.

Dans RollupProxy, une série de RBlocks (alias assertions) soumis par différents validateurs sont enregistrés, qui sont les carrés du diagramme suivant : vert - confirmé, bleu - non confirmé, jaune - falsifié.

RBlock contient l’état final d’un ou plusieurs blocs L2 après exécution depuis le dernier RBlock. Ces RBlocks forment morphologiquement une chaîne de cumul formelle (notez que le registre L2 lui-même est différent). Dans un scénario optimiste, cette chaîne de cumul ne devrait pas être forkée, car avoir un fork signifie qu’il y a des validateurs qui ont soumis des blocs de cumul conflictuels.

Pour faire ou être d’accord avec une affirmation, le validateur doit d’abord miser une certaine quantité de ETH pour l’assertion et devenir un staker. De cette façon, en cas de contestation/preuve de fraude, le collatéral du perdant sera réduit, ce qui est la base économique pour garantir le comportement honnête des validateurs.

Le bloc bleu 111 dans le coin inférieur droit de l’image finira par être falsifié car son bloc parent 104 est Bloc erroné (jaune).

De plus, le validateur A propose le bloc de cumul 106, tandis que B n’est pas d’accord et le conteste.

Une fois que B a lancé un défi, le contrat ChallengeManager est chargé de valider la répartition des étapes du défi :

1. La segmentation est un processus dans lequel deux parties interagissent à tour de rôle, l’une segmentant les données historiques contenues dans un bloc de cumul et l’autre indiquant quelle partie du fragment de données est problématique. Semblable à un processus de dichotomie (N/K, en fait) qui réduit progressivement la fourchette.

2. Après cela, vous pouvez continuer à localiser la transaction et le résultat qui posent problème, puis le subdiviser en une instruction machine qui est contestée dans cette transaction.

3. Le contrat ChallengeManager ne vérifie la validité des « fragments de données » générés qu’après avoir subdivisé les données d’origine.

4. Lorsque le challenger et la partie contestée localisent l’instruction machine à contester, le challenger appelle oneStepProveution() et envoie une preuve de fraude en une seule étape pour prouver qu’il y a un problème avec le résultat d’exécution de l’instruction machine.

Épreuve en une seule étape

Les preuves en une seule étape sont au cœur des preuves de fraude dans l’ensemble d’Arbitrum. Jetons un coup d’œil à ce qu’une épreuve de marche prouve.

Cela nécessite une compréhension de WAVM, Wasm Arbitrum Virtual Machine, qui est une machine virtuelle compilée à partir de modules ArbOS et de modules de base Geth (client Ethereum). Étant donné que L2 est très différent de L1 à bien des égards, le noyau Geth original a dû être légèrement modifié et fonctionner avec ArbOS.

Ainsi, les transitions d’état sur L2 sont en fait une caractéristique commune d’ArbOS+Geth Core.

Le Node Client d’Arbitrum (Séquenceur, Validateur, Full Node, etc.) compile le programme traité par le noyau ArbOS+Geth ci-dessus en code machine natif (pour x86/ARM/PC/Mac/etc.) qui peut être directement traité par l’hôte Node.

Si vous remplacez la langue cible compilée par Wasm, vous obtenez le WAVM que le validateur utilise pour générer la preuve de fraude, et le contrat qui vérifie la preuve en une seule étape émule également la fonctionnalité de la machine virtuelle WAVM.

La raison principale est que le contrat qui vérifie la preuve de la fraude en une étape utilise EthereumSmart Contract pour simuler une machine virtuelle capable de gérer un certain ensemble de jeux d’instructions, et WASM est facile à mettre en œuvre sur le contrat.

Cependant, WASM est légèrement plus lent que le code machine natif, de sorte que WAVM ne sera utilisé par le nœud/contrat d’Arbitrum que lorsque des preuves de fraude seront générées et vérifiées.

Après les précédents cycles de segmentation des interactions, la preuve en une seule étape s’est finalement avérée être l’instruction en une seule étape dans le jeu d’instructions WAVM.

Comme vous pouvez le voir dans le code suivant, OneStepProofEntry détermine d’abord à quelle catégorie appartient le code d’opération de l’instruction à prouver, puis appelle le prouveur correspondant, tel que Mem, Math, etc., et transmet l’instruction pas à pas dans le contrat du prouveur.

Le résultat final de l’afterHash retournera au ChallengeManager, et si le hachage n’est pas cohérent avec le hachage enregistré sur le bloc de cumul, le défi sera réussi. S’il est cohérent, cela signifie que le résultat de l’exécution de l’instruction enregistrée sur le bloc de cumul est correct et que la contestation échoue.

Dans le prochain article, nous analyserons les modules contractuels qui gèrent les fonctions d’interaction/pontage inter-chaînes entre Arbitrum et même les couches 2 et 1, et nous clarifierons davantage comment une véritable couche 2 devrait être résistante à la censure.