Ancien ambassadeur technique d'Arbitrum explique l'architecture des composants d'Arbitrum (1ère partie)
TechFlow SélectionTechFlow Sélection
Ancien ambassadeur technique d'Arbitrum explique l'architecture des composants d'Arbitrum (1ère partie)
Un article pour comprendre le fonctionnement d'Arbitrum.
Dédié à des analyses Web3 approfondiesRédaction : Luo Benben, ancien ambassadeur technique d'Arbitrum et contributeur web3 geek
Cet article est une analyse technique d’Arbitrum One par Luo Benben, ancien ambassadeur technique d’Arbitrum et ancien cofondateur de l’entreprise d’audit automatisé de contrats intelligents Goplus Security.
Étant donné qu’il existe peu de documents ou articles en chinois traitant professionnellement d’Arbitrum ou même des OP Rollups dans l’écosystème Layer2, cet article tente de combler cette lacune en vulgarisant le mécanisme de fonctionnement d’Arbitrum. En raison de la grande complexité intrinsèque d’Arbitrum, l'article totalise malgré une simplification maximale plus de 10 000 caractères, aussi est-il divisé en deux parties. Nous vous recommandons vivement de le sauvegarder comme référence !
Présentation succincte du Séquenceur Rollup
Le principe de mise à l'échelle des Rollups peut se résumer en deux points :
Optimisation des coûts : transférer la majeure partie des opérations de calcul et de stockage hors chaîne L1, c’est-à-dire sur L2. La couche L2 est généralement constituée d'une blockchain exécutée sur un seul serveur, appelé séquenceur (Sequencer/Operator).
Le séquenceur apparaît subjectivement comme un serveur centralisé, sacrifiant la « décentralisation » dans le « triangle impossible des blockchains » afin d’obtenir un avantage en termes de TPS et de coût. Les utilisateurs peuvent ainsi faire traiter leurs transactions par L2 au lieu d’Ethereum, pour un coût nettement inférieur.
Sécurité : le contenu des transactions sur L2 et les états qui en résultent sont synchronisés avec Ethereum L1, où des contrats vérifient la validité des transitions d'état. En outre, l'historique complet de L2 est conservé sur Ethereum ; même si le séquenceur tombe définitivement en panne, n'importe qui peut restaurer entièrement l'état de L2 à partir des données archivées sur Ethereum.
Fondamentalement, la sécurité des Rollups repose sur celle d’Ethereum. Le séquenceur ne peut pas initier une transaction au nom d’un compte dont il ignore la clé privée, ni falsifier le solde de ses actifs (et s’il le fait, cela sera rapidement détecté).
Bien que le séquenceur, en tant que centre du système, ait un caractère centralisé, dans les solutions Rollup matures, un séquenceur centralisé ne peut commettre que des abus doux comme la censure de transactions ou provoquer une panne intentionnelle. Toutefois, dans un scénario idéal de Rollup, des contre-mesures existent (telles que des mécanismes de retrait forcé ou de preuve de séquençage) pour limiter ces comportements.
(Fonction de retrait forcé implémentée dans le code source du contrat L1 du protocole Loopring, invocable par les utilisateurs)
La méthode de vérification d’état destinée à prévenir les abus du séquenceur Rollup se divise en deux catégories : preuve de fraude (Fraud Proof) et preuve de validité (Validity Proof). Les solutions Rollup utilisant la preuve de fraude sont appelées OP Rollup (Optimistic Rollup, OPR), tandis que pour des raisons historiques, celles utilisant la preuve de validité sont souvent appelées ZK Rollup (Zero-knowledge Proof Rollup, ZKR), plutôt que Validity Rollup.
Arbitrum One est un exemple typique d’OPR. Son contrat déployé sur L1 ne valide pas activement les données soumises, mais suppose de manière optimiste qu’elles sont correctes. Si des erreurs sont présentes, les nœuds validateurs de L2 lancent un défi.
Par conséquent, l’OPR repose implicitement sur une hypothèse de confiance : à tout moment, au moins un nœud validateur honnête doit être présent sur L2. En revanche, le contrat ZKR utilise des calculs cryptographiques pour valider activement, à faible coût, les données soumises par le séquenceur.
(Fonctionnement d’un Optimistic Rollup)
(Fonctionnement d’un ZK Rollup)
Cet article présente en profondeur Arbitrum One, leader parmi les projets Optimistic Rollup, en couvrant tous les aspects du système. Une lecture attentive vous permettra d’acquérir une compréhension approfondie d’Arbitrum et des Optimistic Rollups (OPR).
Composants principaux et flux de travail d’Arbitrum
Contrats principaux :
Les contrats les plus importants d’Arbitrum incluent SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Nous entrerons dans les détails ultérieurement.
Séquenceur (Sequencer) :
Reçoit les transactions utilisateur, les ordonne, calcule leurs résultats et renvoie rapidement (généralement <1s) un accusé de réception. Les utilisateurs voient souvent leur transaction confirmée sur L2 en quelques secondes, offrant une expérience similaire à celle des plateformes Web2.
En outre, le séquenceur diffuse instantanément hors chaîne Ethereum les derniers blocs L2 générés. Tout nœud Layer2 peut les recevoir de manière asynchrone. Cependant, ces blocs L2 n’ont alors aucune finalité, car ils peuvent être annulés par le séquenceur.
Toutes les quelques minutes, le séquenceur compresse les transactions L2 ordonnées, les regroupe en lots (batches) et les soumet au contrat SequencerInbox sur Layer1, assurant ainsi la disponibilité des données et le bon fonctionnement du protocole Rollup. En général, les données L2 soumises sur L1 ne peuvent pas être annulées et acquièrent une finalité définitive.
À partir de ce processus, on peut conclure : Layer2 dispose de son propre réseau de nœuds, mais celui-ci est limité en nombre et ne possède généralement aucun protocole de consensus comme les blockchains publiques. Sa sécurité est donc faible et dépend nécessairement d’Ethereum pour garantir la fiabilité de la publication des données et la validité des transitions d’état.
Protocole Rollup d’Arbitrum :
Définit une série de contrats régissant la structure des blocs Rollup (RBlock), la façon dont la chaîne progresse, la publication des RBlocks et le processus de contestation. Notez bien que cette chaîne Rollup n’est pas le grand livre L2 tel qu’on l’entend couramment, mais une structure de données abstraite en forme de chaîne, indépendamment définie par Arbitrum One pour mettre en œuvre son mécanisme de preuve de fraude.
Un RBlock peut contenir les résultats de plusieurs blocs L2, et ses données sont différentes. L’entité RBlock est stockée dans une série de contrats RollupCore. Si un RBlock est incorrect, un validateur lance un défi contre son soumissionnaire.
Validateurs (Validator) :
Les nœuds validateurs d’Arbitrum sont un sous-ensemble spécial des nœuds complets L2, actuellement soumis à une liste blanche d’autorisation.
Le validateur crée un nouveau RBlock (bloc Rollup, également appelé assertion) à partir du lot de transactions (batch) que le séquenceur a soumis au contrat SequencerInbox, surveille l’état actuel de la chaîne Rollup et lance un défi si les données soumises par le séquenceur sont erronées.
Un validateur actif doit préalablement déposer des actifs sur la chaîne ETH, on parle alors aussi de Staker. Un nœud L2 non engagé peut certes surveiller le fonctionnement de Rollup et alerter les utilisateurs en cas d’anomalie, mais il ne peut pas intervenir directement sur la chaîne ETH pour contester les données erronées du séquenceur.
Contestation (Challenge) :
Les étapes de base peuvent être résumées par un processus interactif en plusieurs tours puis une preuve en une étape. Dans la phase de découpage, les deux parties concernées subdivisent de manière itérative les données de transaction litigieuses jusqu’à isoler l’instruction problématique, puis la vérifient. Ce paradigme de « multi-tours de découpage - preuve en une étape » est considéré par les développeurs d’Arbitrum comme la manière la plus économique en gaz (gas) de mettre en œuvre la preuve de fraude. Toutes les étapes sont contrôlées par des contrats, empêchant toute tricherie.
Période de contestation (Challenge period) :
En raison de la nature optimiste (optimistic) des OP Rollups, le contrat ne vérifie pas activement chaque RBlock après sa soumission, mais laisse une fenêtre temporelle aux validateurs pour réfuter d’éventuelles erreurs. Cette période est appelée période de contestation. Sur le réseau principal d’Arbitrum One, elle dure une semaine. Après expiration de cette période, le RBlock est définitivement confirmé, et les messages correspondants passant de L2 à L1 (comme les opérations de retrait via le pont officiel) peuvent alors être libérés.
ArbOS, Geth, WAVM :
La machine virtuelle utilisée par Arbitrum est appelée AVM, composée de deux parties : Geth et ArbOS. Geth est le logiciel client le plus utilisé sur Ethereum, légèrement modifié par Arbitrum. ArbOS gère toutes les fonctions spécifiques à L2, telles que la gestion des ressources réseau, la génération de blocs L2 et la coordination avec EVM. Ensemble, nous les considérons comme une AVM native, c’est-à-dire la machine virtuelle d’Arbitrum. WAVM est le résultat de la compilation du code AVM en Wasm. Dans le processus de contestation d’Arbitrum, la dernière « preuve en une étape » consiste à vérifier une instruction WAVM.
Nous pouvons illustrer ci-dessous les relations entre ces composants et leur flux de travail :
Cycle de vie d’une transaction L2
Voici comment une transaction L2 est traitée :
1. L’utilisateur envoie une instruction de transaction au séquenceur.
2. Le séquenceur effectue d’abord une validation des données, notamment la signature numérique, écarte les transactions invalides, puis les ordonne et les exécute.
3. Le séquenceur renvoie un accusé de réception à l’utilisateur (généralement très rapide), mais il s’agit seulement d’un « prétraitement » hors chaîne Ethereum, dans un état de finalité molle (Soft Finality), donc non fiable. Pour les utilisateurs faisant confiance au séquenceur (la majorité), la transaction peut être considérée comme terminée sans risque de réversion.
4. Le séquenceur compresse fortement les données brutes des transactions prétraitées et les emballe dans un lot (Batch).
5. À intervalles réguliers (selon volume de données, congestion d’ETH, etc.), le séquenceur publie le lot de transactions sur le contrat Sequencer Inbox de L1. À ce stade, on peut considérer que la transaction a atteint la finalité définitive (Hard Finality).
Contrat Sequencer Inbox
Ce contrat reçoit les lots de transactions soumis par le séquenceur, garantissant la disponibilité des données. En profondeur, les données batch dans SequencerInbox enregistrent intégralement les entrées des transactions L2. Même si le séquenceur tombait définitivement en panne, n'importe qui pourrait restaurer l'état actuel de L2 à partir de ces enregistrements, et prendre la relève du séquenceur défaillant ou disparu.
Pour utiliser une analogie physique, ce que nous voyons de L2 n’est qu’une projection du batch dans SequencerInbox, la source lumineuse étant STF. Comme la source STF ne change pas facilement, la forme de l’ombre dépend uniquement du batch, qui joue le rôle de l’objet.
Le contrat Sequencer Inbox est aussi appelé « boîte rapide ». Seul le séquenceur peut y soumettre des données, et uniquement après avoir prétraité les transactions. Il existe une « boîte lente » (Delayed Inbox), dont la fonction sera expliquée plus tard.
Les validateurs surveillent continuellement le contrat SequencerInbox. Dès que le séquenceur publie un lot sur ce contrat, un événement est émis sur chaîne. En détectant cet événement, le validateur télécharge les données du lot, les exécute localement, puis publie un RBlock sur le contrat du protocole Rollup d’Ethereum.
Le contrat bridge d’Arbitrum contient un paramètre appelé accumulateur (accumulator), qui enregistre les nouveaux lots L2 soumis, ainsi que le nombre et les informations des nouvelles transactions reçues par la boîte lente (Delayed Inbox).
(Le séquenceur soumet continuellement des lots à SequencerInbox)
(Informations détaillées du lot : le champ data contient les données du lot, volumineuses, partiellement affichées ici)
Le contrat SequencerInbox dispose de deux fonctions principales :
addSequencerL2BatchFromOrigin(), que le séquenceur appelle systématiquement pour soumettre un lot au contrat SequencerInbox.
forceInclusion(), que n’importe qui peut appeler, permettant de réaliser des transactions résistantes à la censure. Le fonctionnement de cette fonction sera expliqué en détail lors de la discussion sur le contrat DelayedInbox.
Les deux fonctions appellent bridge.enqueueSequencerMessage() pour mettre à jour le paramètre accumulateur dans le contrat bridge.
Prix du gaz (Gas pricing)
Il va de soi que les transactions L2 ne sont pas gratuites : sinon, elles encourageraient des attaques DoS, sans compter les coûts d’exploitation du séquenceur et de la soumission des données sur L1. Lorsqu’un utilisateur lance une transaction sur le réseau Layer2, la structure des frais de gaz est la suivante :
Coût lié à l'utilisation des ressources L1 pour la publication des données, principalement causé par les lots envoyés par le séquenceur (chaque lot contenant les transactions de nombreux utilisateurs), coût finalement réparti entre les initiateurs des transactions. Le prix de ce service est dynamique : le séquenceur l’ajuste selon les bénéfices récents, la taille du lot et le prix actuel du gaz sur Ethereum.
Coût dû à l'utilisation des ressources L2, fixé avec une limite maximale de gaz par seconde garantissant la stabilité du système (actuellement 7 millions pour Arbitrum One). Les prix indicatifs du gaz sur L1 et L2 sont suivis et ajustés par ArbOS, selon une formule non détaillée ici.
Bien que le calcul précis du prix du gaz soit complexe, les utilisateurs n’en perçoivent pas les détails, mais constatent clairement que les frais des transactions Rollup sont bien inférieurs à ceux du réseau principal d’Ethereum.
Preuve de fraude optimiste
En reprenant ce qui précède, L2 n’est en réalité qu’une projection des entrées de transaction (batch) soumises par le séquenceur dans la « boîte rapide », autrement dit :
Entrées de transaction → STF → Sorties d’état. L’entrée étant fixée et STF constant, la sortie est déterminée. Le système de preuve de fraude et le protocole Rollup d’Arbitrum consistent à publier la racine d’état résultante sous forme de RBlock (ou assertion) sur L1, puis à la prouver de manière optimiste.
Sur L1, nous avons les données d’entrée publiées par le séquenceur et les états de sortie publiés par les validateurs. Réfléchissons attentivement : est-il vraiment nécessaire de publier l’état de L2 sur la chaîne ?
Puisque l’entrée détermine entièrement la sortie, et que les données d’entrée sont publiques, publier à nouveau l’état semble redondant ? Cette idée néglige toutefois la nécessité d’un règlement d’état entre les systèmes L1 et L2, notamment le retrait de fonds de L2 vers L1, qui requiert une preuve d’état.
Lors de la conception d’un Rollup, l’idée centrale est de déplacer la plupart des calculs et du stockage sur L2 pour éviter les coûts élevés de L1. Cela signifie que L1 ne connaît pas l’état de L2 : il aide simplement le séquenceur L2 à publier les entrées complètes des transactions, sans calculer lui-même l’état L2.
Une opération de retrait consiste essentiellement à débloquer des fonds dans un contrat L1 selon un message inter-chaînes provenant de L2, puis à les transférer vers le compte L1 de l’utilisateur ou à accomplir d’autres actions.
À ce moment-là, le contrat L1 demande : « Quel est votre état sur L2 ? Comment prouvez-vous que vous possédez vraiment les actifs que vous souhaitez retirer ? » L’utilisateur doit alors fournir une preuve Merkle correspondante.
Ainsi, si nous construisions un Rollup sans fonction de retrait, théoriquement, la synchronisation d’état vers L1 serait inutile, tout comme le système de preuve d’état tel que la preuve de fraude (bien que cela pose d'autres problèmes). Mais en pratique, ceci est irréaliste.
Dans la preuve optimiste, le contrat ne vérifie pas si l’état publié sur L1 est correct, supposant naïvement que tout est exact. Le système de preuve optimiste suppose qu’à tout moment, au moins un validateur honnête est présent ; si un état erroné est détecté, une preuve de fraude peut être lancée.
Ce design évite de gaspiller du gaz en vérifiant activement chaque RBlock publié sur L1. En réalité, pour un OPR, valider chaque assertion est irréaliste : chaque RBlock contient un ou plusieurs blocs L2, et exécuter chaque transaction sur L1 reviendrait à exécuter directement les transactions L2 sur L1, annulant ainsi tout intérêt du Rollup pour la mise à l’échelle.
Ce problème n’existe pas pour les ZKR, car la preuve ZK est concise : il suffit de vérifier une très petite preuve, sans avoir à exécuter toutes les transactions qu’elle représente. Ainsi, les ZKR ne fonctionnent pas de manière optimiste : chaque publication d’état est mathématiquement vérifiée par un contrat Verifier.
Bien que la preuve de fraude ne bénéficie pas de la concision d’une preuve à connaissance nulle, Arbitrum utilise un processus interactif en « plusieurs tours de division - preuve en une étape », où seule une instruction de machine virtuelle finale doit être prouvée, à un coût relativement faible.
Protocole Rollup
Examinons d’abord le point d’entrée pour lancer une contestation ou démarrer une preuve, c’est-à-dire comment fonctionne le protocole Rollup.
Le contrat principal du protocole Rollup est RollupProxy.sol, qui utilise une structure rare de double proxy, un proxy pointant vers deux implémentations : RollupUserLogic.sol et RollupAdminLogic.sol, tout en maintenant une structure de données cohérente. Les outils comme Scan ne parviennent pas encore à bien analyser cette configuration.
De plus, le contrat ChallengeManager.sol gère les contestations, et la série de contrats OneStepProver juge les preuves de fraude.
Dans RollupProxy, sont enregistrés les RBlocks (ou assertions) soumis par différents validateurs, représentés ci-dessous par des carrés : vert = confirmé, bleu = non confirmé, jaune = réfuté.
Chaque 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 visuellement une chaîne Rollup (distincte du grand livre L2). En situation optimiste, cette chaîne Rollup ne devrait pas présenter de fourches, car une fourche indiquerait que des validateurs ont soumis des blocs Rollup conflictuels.
Pour proposer ou accepter une assertion, un validateur doit d’abord déposer une certaine quantité d’ETH, devenant ainsi un Staker. En cas de contestation ou de preuve de fraude, la mise du perdant est confisquée, ce qui constitue la base économique incitant les validateurs à rester honnêtes.
Le bloc bleu n°111 en bas à droite sera finalement réfuté, car son bloc parent n°104 est incorrect (jaune).
En outre, le validateur A a proposé le bloc Rollup n°106, que B conteste.
Après que B lance la contestation, le contrat ChallengeManager supervise le processus de découpage :
1. Le découpage est un processus interactif alterné : une partie segmente les données historiques d’un bloc Rollup, l’autre identifie le segment problématique. C’est un processus progressif similaire à une dichotomie (en réalité N/K) réduisant progressivement la plage.
2. On peut ensuite localiser quelle transaction et quel résultat sont erronés, puis affiner jusqu’à l’instruction machine litigieuse.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
