Transférer le titre original :

Cet article fournit une interprétation technique d'Arbitrum One par Luo Benben (罗奔奔), ancien ambassadeur technique d'Arbitrum et ancien co-fondateur de Goplus Security, une entreprise d'audit d'automatisation de contrats intelligents.

En raison du manque d'interprétation professionnelle d'Arbitrum et même d'OP Rollup dans les articles ou documents chinois liés à la couche 2, cet article tente de combler le vide dans ce domaine en popularisant le mécanisme de fonctionnement d'Arbitrum. Comme la structure d'Arbitrum elle-même est trop complexe, bien que le texte complet ait été simplifié autant que possible, il dépasse toujours 10 000 mots, il est donc divisé en deux parties. Il est recommandé de le collecter et de le transmettre comme une référence!

Introduction brève du séquenceur Rollup

Le principe de l'expansion de Rollup peut être résumé en deux points :

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

Le séquenceur est proche d'un serveur centralisé dans un sens. Dans le «triangle impossible de la blockchain», la «décentralisation» est abandonnée en échange d'avantages en matière de TPS et de coûts. Les utilisateurs peuvent laisser L2 traiter les instructions de transaction au lieu d'Ethereum, et le coût est beaucoup plus bas que les échanges sur Ethereum.

(Source: Chaîne BNB)

Garantie de sécurité : Le contenu de la transaction et l'état résultant sur la couche 2 sont synchronisés avec la couche 1 d'Ethereum, où leur validité est vérifiée à travers des contrats. Entre-temps, Ethereum conserve les enregistrements historiques de L2, donc même si le séquenceur plante de manière permanente, d'autres peuvent reconstruire l'état entier de L2 à partir des enregistrements sur Ethereum.

Fondamentalement, la sécurité de Rollup est basée sur Ethereum. Si un 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 ou altérer le solde d’actifs de ce compte (même s’il tentait, il serait rapidement détecté).

Bien que le séquenceur, en tant que centre névralgique du système, puisse avoir une teinte centralisée, dans les solutions Rollup matures, un séquenceur centralisé ne peut s'engager que dans des comportements malveillants légers tels que la censure de transactions ou des pannes malveillantes. Cependant, dans les solutions Rollup idéales, il existe des mesures correspondantes pour restreindre de tels comportements (comme les retraits forcés ou les preuves de tri en tant que mécanismes anti-censure).

(Le protocole Loopring définit une fonction de retrait forcé dans le code source du contrat sur L1 pour que les utilisateurs puissent l'appeler)

Pour empêcher les comportements malveillants des séquenceurs de cumul, il existe deux types de méthodes de vérification d’état : Fraud Proof et Validity Proof. Les solutions de cumul utilisant la preuve contre la fraude sont appelées Optimistic Rollup (OPR), tandis que celles qui utilisent la preuve de validité sont souvent appelées ZK Rollup (Zero-knowledge Proof Rollup, ZKR), plutôt que Validity Rollup, en raison de l’historique des bagages.

Arbitrum One est un OPR typique, déployé sur des contrats L1, qui ne valident pas activement les données soumises mais supposent de manière optimiste que les données sont correctes. S'il y a des erreurs dans les données soumises, les validateurs L2 lanceront des défis.

Par conséquent, l'OPR implique également une hypothèse de confiance : il y a au moins un nœud de validateur L2 honnête à tout moment donné. D'autre part, les contrats ZKR vérifient de manière proactive et rentable les données soumises par le séquenceur grâce à des calculs cryptographiques.

(Méthode d'opération Rollup optimiste)

(Méthode d'opération ZK Rollup)

Cet article fournira une introduction approfondie au principal projet d'Optimistic Rollup - Arbitrum One, couvrant tous les aspects du système. Après une lecture attentive, vous acquerrez une compréhension profonde d'Arbitrum et d'Optimistic Rollup (OPR).

Composants principaux et flux de travail d'Arbitrum :

Contrats de base:

Les contrats les plus importants dans Arbitrum incluent SequencerInbox, DelayedInbox, Portails L1, Portails L2, Boîte de réception, RollupCore, Bridge, etc. Ces éléments seront détaillés ultérieurement.

Séquenceur:

Recevoir les transactions des utilisateurs et les séquencer, calculer les résultats des transactions et renvoyer rapidement (généralement <1s) les reçus aux utilisateurs. Les utilisateurs peuvent généralement voir leurs transactions confirmées sur L2 en quelques secondes, offrant une expérience similaire à celle du Web2.

De plus, le séquenceur diffuse immédiatement les derniers blocs L2 générés sous la chaîne Ethereum, que tout nœud de couche 2 peut recevoir de manière asynchrone. Cependant, à ce stade, ces blocs L2 n'ont pas de finalité et peuvent être annulés par le séquenceur.

Toutes les quelques minutes, le séquenceur compresse les données de transaction L2 séquencées, les agrège en lots et les soumet au contrat SequencerInbox sur la couche 1 pour garantir la disponibilité des données et le fonctionnement du protocole Rollup. En général, les données L2 soumises à la couche 1 ne peuvent pas être annulées et peuvent être définitives.

De ce qui précède, nous pouvons résumer que la couche 2 a son propre réseau de nœuds, mais ces nœuds sont peu nombreux et manquent généralement des protocoles de consensus couramment utilisés dans les blockchains publiques. Par conséquent, leur sécurité est faible et ils doivent compter sur Ethereum pour garantir la fiabilité de la publication des données et la validité des transitions d'état.

Protocole de cumul d’Arbitrum :

Définit la structure des blocs, appelés RBlocks, sur la chaîne Rollup, la continuation de la chaîne, la publication des RBlocks, et le processus de mode de défi, etc., à travers une série de contrats. Il est important de noter que la chaîne Rollup mentionnée ici n'est pas le grand livre communément compris comme Layer 2, mais plutôt une structure de données abstraite de type "chaîne" mise en place indépendamment par Arbitrum One pour implémenter des mécanismes de preuve de fraude.

Un RBlock peut contenir les résultats de plusieurs blocs L2, et son entité de données, RBlock, est stockée dans une série de contrats au sein de RollupCore. En cas de problème avec un RBlock, les validateurs le contesteront en se basant sur les soumissions du créateur du RBlock.

Validateurs :

Les validateurs dans Arbitrum sont en fait un sous-ensemble spécial des nœuds complets de la Couche 2, actuellement avec admission sur liste blanche.

Les validateurs créent de nouveaux RBlocks (blocs Rollup, également appelés assertions) en fonction des lots de transactions soumis au contrat SequencerInbox par le séquenceur, et surveillent l'état actuel de la chaîne Rollup pour contester les données incorrectes soumises par le séquenceur.

Les validateurs actifs doivent jalonner des actifs sur la chaîne Ethereum à l’avance, et sont parfois appelés stakers. Bien que les nœuds de couche 2 qui ne jalonnent pas d’actifs puissent surveiller le fonctionnement du Rollup et envoyer des alertes aux utilisateurs en cas d’anomalies, ils ne peuvent pas intervenir directement dans les données incorrectes soumises par le séquenceur sur la chaîne Ethereum.

Défi :

Les étapes de base peuvent être résumées comme une subdivision interactive multi-tours et une preuve en une étape. Dans la phase de subdivision, les deux challengers commencent d'abord par une subdivision interactive multi-tours des données de transaction problématiques jusqu'à ce que l'instruction d'opcode problématique soit décomposée et vérifiée. Les développeurs d'Arbitrum considèrent le paradigme "subdivision multi-tours-preuve en une étape" comme la mise en œuvre de preuve de fraude la plus efficace en termes de gaz. Toutes les étapes sont contrôlées par des contrats intelligents, et aucune des parties ne peut tricher.

Période de défi:

En raison de la nature optimiste d'OP Rollup, après chaque RBlock soumis à la chaîne, le contrat ne le vérifie pas activement, laissant un laps de temps aux validateurs pour le falsifier. Cette fenêtre de temps est la période de défi, qui est d'une semaine sur le mainnet Arbitrum One. Après la fin de la période de défi, le RBlock sera enfin confirmé et les messages correspondant aux transactions de L2 à L1 (comme les opérations de retrait exécutées via le pont officiel) pourront être publiés.

ArbOS, Geth, WAVM:

Arbitrum utilise une machine virtuelle appelée AVM, qui se compose de Geth et d’ArbOS. Geth est le logiciel client le plus couramment utilisé pour Ethereum, et Arbitrum y a apporté de légères modifications. ArbOS est responsable de toutes les fonctions spéciales liées à la couche 2, telles que la gestion des ressources réseau, la génération de blocs L2 et le travail en coordination avec EVM. 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 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 représenter les relations et les flux de travail entre les différents composants à l'aide du diagramme ci-dessous :

Cycle de vie de la transaction L2

Le flux de traitement d'une transaction L2 est le suivant :

1. L'utilisateur envoie des instructions de transaction au séquenceur.
2. Le séquenceur vérifie d'abord les données, y compris les signatures numériques, des transactions à traiter, filtre les transactions invalides, puis les séquence et les calcule.
3. Le séquenceur envoie le reçu de transaction à l'utilisateur (généralement très rapidement), mais il s'agit uniquement du “prétraitement” effectué par le séquenceur sur la chaîne Ethereum, et il est dans un état de Soft Finality et n'est pas fiable. Cependant, pour les utilisateurs qui font confiance au séquenceur (la plupart des utilisateurs), ils peuvent supposer de manière optimiste que la transaction a été effectuée et ne sera pas annulée.
4. Le séquenceur encapsule les données de transaction prétraitées dans un lot après les avoir fortement compressées.
5. À intervalles réguliers (influencés par des facteurs tels que le volume de données et la congestion d'Ethereum), le séquenceur publie le lot de transactions sur le contrat Sequencer Inbox sur L1. À ce stade, on peut considérer que la transaction a une Finalité Rigide.

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

Le contrat reçoit des lots de transactions soumis par le séquenceur pour garantir la disponibilité des données. En profondeur, les données de lot dans la boîte de réception du séquenceur enregistrent entièrement les informations d'entrée de transaction de la Couche 2. Même si le séquenceur tombe en panne de manière permanente, n'importe qui peut restaurer l'état actuel de la Couche 2 en se basant sur les enregistrements du lot et prendre en charge le séquenceur défaillant/manquant.

Dans une analogie physique, ce que nous voyons comme L2 n'est que la projection du lot dans la boîte de séquenceur, tandis que la source de lumière est la finalité douce. Parce que la source de lumière, la finalité douce, ne change pas facilement, la forme de l'ombre est déterminée uniquement par le lot agissant comme l'objet.

Le contrat de la boîte de réception du séquenceur est également appelé une boîte rapide, et le séquenceur soumet spécifiquement des transactions prétraitées à celle-ci, et seul le séquenceur peut soumettre des données à celle-ci. La boîte lente correspondante est la boîte de réception du retardateur, dont la fonction sera décrite dans le processus ultérieur.

Les validateurs surveilleront en continu le contrat de la boîte de réception du séquenceur. Chaque fois que le séquenceur publie un lot sur ce contrat, un événement sur chaîne est déclenché. En détectant cet événement, le validateur téléchargera les données du lot, les exécutera localement, puis publiera un RBlock sur le contrat du protocole Rollup sur la chaîne Ethereum.

Le contrat de pont Arbitrum a un paramètre appelé l'accumulateur, qui enregistre des informations sur le nouveau lot L2 soumis et le nombre de transactions reçues sur la boîte de réception lente, entre autres choses.

(Le séquenceur soumet continuellement des lots à SequencerInbox)

（Les informations spécifiques du lot, le champ de données correspond aux données du lot. La taille de cette partie des données est très grande, et la capture d'écran n'est pas entièrement affichée.）

Le contrat SequencerInbox a deux fonctions principales :

ajouter Sequencer L2Batch De Origin()，Le séquenceur appellera cette fonction à chaque fois pour soumettre des données de batch au contrat Sequencer Inox.

force Inclusion()，Cette fonction peut être appelée par n'importe qui et est utilisée pour mettre en œuvre des transactions résistantes à la censure. La manière dont cette fonction prend effet sera expliquée en détail plus tard lorsque nous parlerons du contrat Delayed Inbox.

Les deux fonctions ci-dessus appelleront "bridge.enqueueSequencerMessage()" pour mettre à jour le paramètre d'accumulateur de l'accumulateur dans le contrat de pont.

Tarification du gaz

De toute évidence, les transactions L2 ne peuvent pas être gratuites, car cela entraînerait des attaques DoS. De plus, il y a des coûts d'exploitation pour le séquenceur L2 lui-même, et il y aura des frais généraux pour soumettre des données sur L1. Lorsqu'un utilisateur lance une transaction dans le réseau de couche 2, la structure des frais de gaz est la suivante :

Le coût de la publication de données générées en occupant les ressources Layer1 provient principalement des lots soumis par le séquenceur (chaque lot contient des transactions de nombreux utilisateurs), et le coût est finalement partagé entre les initiateurs de transactions. L'algorithme de tarification des frais de transaction générés par la publication de données est dynamique. Le séquenceur ajuste la tarification en fonction des conditions récentes de profits et pertes, de la taille du lot et du prix actuel du gaz Ethereum.

Le coût engagé par les utilisateurs pour occuper les ressources de la couche 2 est déterminé en fixant une limite maximale sur le gaz traité par seconde pour garantir le fonctionnement stable du système (actuellement Arbitrum One est de 7 millions). Les prix indicatifs du gaz pour les deux L1 et L2 sont suivis et ajustés par ArbOS, et la formule n'est pas élaborée ici.

Bien que le processus de calcul du prix du gaz spécifique soit relativement compliqué, les utilisateurs n'ont pas besoin d'en être conscients et peuvent clairement ressentir que les frais de transaction Rollup sont beaucoup moins chers que sur le réseau principal ETH.

Preuve de fraude optimiste

En regardant le texte précédent, il est évident que Layer2 (L2) est essentiellement juste une projection des lots d'entrée de transaction soumis par le séquenceur dans la boîte de réception du séquenceur :

Entrées de transaction -> Fonction de transition d'état (STF) -> Sorties d'état

Les entrées sont déjà déterminées, et le STF est immuable, donc le résultat de sortie est également déterminé. La preuve de fraude et le système de protocole de Rollup Arbitrum publient l'état de sortie, représenté par un RBlock (également connu sous le nom d'affirmation), sur la Couche1 et fournissent des preuves optimistes pour cela.

Sur L1, il y a à la fois des données d'entrée publiées par le séquenceur et des états de sortie publiés par les validateurs. Après mûre réflexion, est-il nécessaire de publier l'état de la couche 2 sur la chaîne ? Parce que les entrées ont déjà pleinement déterminé les sorties, et les données d'entrée sont publiquement visibles, soumettre les résultats de sortie ou l'état semble superflu. Cependant, cette idée néglige le fait qu'il doit y avoir un règlement des états entre les systèmes L1 et L2. C'est particulièrement nécessaire pour les actions de retrait de L2 à L1, qui nécessitent une preuve d'état.

Lors de la construction de Rollup, l'idée principale est de décharger la plupart des calculs et du stockage vers L2 pour éviter les coûts élevés de L1. Cela implique que L1 ne connaît pas l'état de L2 ; il aide uniquement le séquenceur L2 à publier les données d'entrée pour toutes les transactions mais n'est pas responsable du calcul de l'état de L2.

Les actions de retrait impliquent essentiellement le déverrouillage des actifs correspondants du contrat L1 sur la base des messages inter-chaînes fournis par L2 et de les transférer sur le compte L1 de l'utilisateur ou de réaliser d'autres tâches.

À ce stade, le contrat Layer1 demandera : quel est votre état sur Layer2, et comment prouvez-vous que vous possédez réellement les actifs que vous prétendez transférer ? À ce stade, les utilisateurs doivent fournir des preuves de Merkle correspondantes, etc.

Par conséquent, si nous construisons un Rollup sans fonction de retrait, il est théoriquement possible de ne pas synchroniser l'état avec L1, et il n'est pas nécessaire d'avoir un système de preuve d'état tel qu'une preuve de fraude (bien que cela puisse causer d'autres problèmes). Mais dans les applications réelles, cela n'est évidemment pas faisable.

Dans la soi-disant preuve optimiste, le contrat ne vérifie pas si l'état de sortie soumis à L1 est correct, mais croit de manière optimiste que tout est exact. Le système de preuve optimiste suppose qu'il y a au moins un valideur honnête à tout moment. Si un état incorrect se produit, il sera contesté par le biais d'une preuve de fraude.

L'avantage de cette conception est qu'il n'est pas nécessaire de vérifier activement chaque RBlock émis à L1 pour éviter de gaspiller du gaz. En fait, pour OPR, il est irréaliste de vérifier chaque assertion, car chaque Rblock contient un ou plusieurs blocs L2, et chaque transaction doit être ré-exécutée sur L1. Cela revient à exécuter directement les transactions L2 sur L1, ce qui perd le sens de la scalabilité de la couche 2.

ZKR ne rencontre pas ce problème car les preuves ZK sont succinctes, ne nécessitant que la validation d'une petite preuve sans avoir besoin d'exécuter réellement les nombreuses transactions derrière la preuve. Par conséquent, ZKR n'opère pas de manière optimiste ; chaque publication d'état est accompagnée d'une vérification mathématique par un contrat Vérificateur.

Bien que les preuves de fraude ne puissent pas atteindre le même niveau de concision que les preuves de connaissance nulle, Arbitrum utilise un processus interactif de "sous-division multi-tours - preuve en une étape" où finalement seul un seul opcode de machine virtuelle doit être prouvé, ce qui entraîne des coûts relativement plus bas.

protocole Rollup

Commençons par jeter un coup d'œil à l'entrée pour initier des défis et démarrer des preuves, c'est-à-dire comment le protocole Rollup fonctionne.

Le contrat principal du protocole Rollup est RollupProxy.sol. Tout en veillant à ce que la structure de données soit cohérente, une structure d'agent double rare est utilisée. Un agent correspond à deux implémentations de RollupUserLogic.sol et RollupAdminLogic.sol, qui ne peuvent pas être bien analysées par des outils tels que Scan.

De plus, le contrat ChallengeManager.sol est responsable de la gestion des défis, et les contrats de la série OneStepProver sont utilisés pour déterminer les preuves de fraude.

(Source : site officiel de L2BEAT)

Dans le RollupProxy, une série de RBlocks (également connus sous le nom d'assertions) soumis par différents validateurs sont enregistrés, représentés par des blocs dans le diagramme: vert pour confirmé, bleu pour non confirmé et jaune pour réfuté.

Le RBlock contient l'état final résultant de l'exécution d'un ou plusieurs blocs L2 depuis le précédent RBlock. Ces RBlocks forment une chaîne Rollup en apparence (notez la distinction avec le registre L2 lui-même). Dans un scénario optimiste, cette chaîne Rollup ne devrait pas avoir de forks, car le fork implique que des validateurs soumettent des blocs Rollup en conflit.

Pour proposer ou accepter une assertion, les validateurs doivent miser une certaine quantité d'ETH, devenant ainsi un Stakeur. Cela garantit la base économique d'un comportement honnête parmi les validateurs, car la mise du perdant sera confisquée en cas de contestation/preuve de fraude.

Le bloc bleu numéroté 111 dans le coin inférieur droit du diagramme sera finalement réfuté car son bloc parent, le bloc numéro 104, est incorrect (jaune).

De plus, le validateur A a proposé le bloc Rollup 106, ce avec quoi le validateur B n'est pas d'accord et conteste.

Après que B a initié le défi, le contrat ChallengeManager est responsable de vérifier la segmentation des étapes du défi :

1. La segmentation est un processus au cours duquel les deux parties interagissent à tour de rôle. Une partie segmente les données historiques contenues dans un certain bloc de regroupement, et l'autre partie indique quelle partie du fragment de données pose problème. Un processus similaire à la dichotomie (en fait N/K) qui réduit continuellement et progressivement la portée.

2. Par la suite, il est possible de déterminer plus précisément quelle transaction et quels résultats posent problème, puis de subdiviser davantage l'instruction machine spécifique au sein de cette transaction qui est contestée.

3. Le contrat ChallengeManager vérifie uniquement si le segment de données généré après la subdivision des données d'origine est valide.

4. Lorsque le challenger et la partie défiée identifient l'instruction machine à contester, le challenger invoque oneStepProveExecution() pour envoyer une preuve de fraude en une étape, démontrant que le résultat de l'exécution de cette instruction machine est défectueux.

Preuve en une étape

La preuve en une étape est au cœur de la preuve de fraude Arbitrum. Jetons un coup d'œil à ce que la preuve en une étape prouve spécifiquement.

Cela nécessite d'abord de comprendre WAVM. La machine virtuelle Wasm Arbitrum est une machine virtuelle compilée par le module ArbOS et le module de base Geth (client Ethereum). Étant donné que L2 est très différent de L1, le cœur Geth d'origine a dû être légèrement modifié et travailler avec ArbOS.

Par conséquent, la transition d'état sur L2 est en réalité le travail conjoint d'ArbOS+Geth Core.

Le client de nœud d’Arbitrum (séquenceur, validateur, nœud complet, etc.) compile le programme de traitement ArbOS+Geth Core mentionné ci-dessus en code machine natif que l’hôte du nœud peut traiter directement (pour x86/ARM/PC/Mac/etc.).

Si vous modifiez la langue cible obtenue après la compilation en Wasm, vous obtiendrez le WAVM utilisé par le vérificateur lors de la génération de preuves de fraude, et le contrat pour vérifier la preuve en une seule étape simule également les fonctions de la machine virtuelle WAVM.

Alors pourquoi doit-il être compilé en bytecode Wasm lors de la génération de preuves de fraude? La principale raison est que pour vérifier le contrat de preuve de fraude en une seule étape, il est nécessaire d'utiliser le contrat intelligent Ethereum pour simuler une machine virtuelle VM capable de gérer un certain ensemble d'ensembles d'instructions, et WASM est facile à mettre en œuvre la simulation sur le contrat.

Cependant, WASM s'exécute légèrement plus lentement que le code machine natif, donc les nœuds/contrats d'Arbitrum n'utiliseront WAVM que lors de la génération et de la vérification des preuves de fraude.

Après les précédentes rondes de subdivisions interactives, la preuve en une seule étape a enfin prouvé l'instruction en une seule étape dans l'ensemble d'instructions WAVM.

Comme on peut le voir dans le code ci-dessous, OneStepProofEntry détermine d'abord à quelle catégorie appartient le code opération de l'instruction à prouver, puis appelle le prouveur correspondant tel que Mem, Math, etc., pour passer l'instruction en une seule étape dans le contrat du prouveur.

Le résultat final aprèsHash sera retourné au ChallengeManager. Si le hachage est incompatible avec le hachage après l'opération d'instruction enregistrée sur le bloc Rollup, le défi réussira. S'ils sont cohérents, cela signifie qu'il n'y a aucun problème avec le résultat d'exécution de cette commande enregistrée sur le bloc Rollup, et le défi a échoué.

Avertissement：

1. Cet article est repris de [GateGeek Web3], Tous les droits d'auteur appartiennent à l'auteur original [Luo Benben, ancien ambassadeur technique d'Arbitrum, contributeur geek web3]. S’il y a des objections à cette réimpression, veuillez contacter le Gate Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.