Analyse d'une mise à jour majeure d'Arbitrum : vérification sans autorisation avec BOLD

Auteur : @francescoweb3 ; traduction : Huohuo/chaîne vernaculaire

**Arbitrum devient de plus en plus décentralisé : utilisation de BOLD pour une vérification sans autorisation. ** Bien que ce ne soit pas une semaine avec un nom comme BALD, il s'agit d'une mise à jour majeure de la conception d'Arbitrum.

BOLD signifie Bounded Liquidity Delay et, comme son nom l'indique, il s'agit d'un "protocole de litige" qui fournit à Arbitrum des capacités de vérification sans autorisation.

**1. Pourquoi avez-vous besoin de BOLD ? **

En termes simples, tous les Rollups optimistes règlent leur état sur Ethereum. **Comment s'assurent-ils que la transaction est valide ? Par le biais du soi-disant système anti-fraude. **

En pratique, cela passe par un ensemble d'entités appelées validateurs. Ces validateurs émettent des déclarations sur l'état de L2 et confirment par le biais de contrats intelligents que ces déclarations sont vraies.

Ensuite, il y a une période de contestation de 7 jours (ou période de refroidissement) pendant laquelle d'autres validateurs peuvent réellement contester ces réclamations, et s'il y a une divergence, le processus de résolution des litiges est lancé.

Si une réclamation est confirmée, l'état L2 est considéré comme correct et le règlement est terminé sur Ethereum.

C'est le processus de vérification par la preuve de fraude qui cause un retard d'environ 7 jours pour le pont local entre Arbitrum et Ethereum.

Le protocole de litige implique que les parties soumettent des preuves de fraude à Ethereum pour déterminer le résultat valide d'une transaction L2.

**Quel est le problème? Actuellement, la vérification via des preuves de fraude est une autorisation requise sur Arbitrum One et Nova. **

La raison en est de protéger le protocole de litige contre les attaques par déni de service. Si un validateur malveillant continue de dépenser des fonds pour empêcher la confirmation des réclamations, les retraits L2 vers Ethereum seront bloqués, et tant qu'ils disposent de suffisamment de fonds, ce processus peut se poursuivre pendant presque longtemps.

C'est ce qu'on appelle une attaque par retard, et il tente d'arrêter la progression du protocole Rollup en "tentant d'empêcher ou de retarder la confirmation de tout résultat". Cette attaque est conçue pour empêcher les validateurs de soumettre des preuves frauduleuses, de sorte que l'état L2 ne puisse pas être confirmé et réglé sur Ethereum.

En effet, passer à la vérification sans autorisation nécessite un protocole résistant aux attaques par retard, comme BOLD.

BOLD est une nouvelle méthode de vérification L2 sans autorisation.

Il permet à Arbitrum de :

Garantir la sécurité et la vivacité de la chaîne

Minimiser la latence dans le règlement de l'État

Empêcher les parties malhonnêtes d'augmenter les coûts pour les parties honnêtes.

En fait, BOLD peut aider à décentraliser la chaîne Arbitrum en fournissant une "confirmation différée supplémentaire fixe de 7 jours" qui est immunisée contre les attaques de retard.

Il y parvient en permettant des "contestations globales" efficaces, où même un seul validateur honnête peut gagner un litige avec n'importe quel nombre de réclamations malveillantes.

Par conséquent, BOLD peut résoudre efficacement les litiges entre plusieurs parties en un seul processus sans s'appuyer sur les défis individuels précédents.

BOLD demande à toutes les parties soutenant une déclaration particulière de se battre ensemble "en équipe".

Par conséquent, tout litige en BOLD est lié à l'exécution "déterministe" de l'état L2, et non à un intervenant ou à une entité spécifique.

Cela signifie que toute personne qui est d'accord avec un état peut le justifier avant de trouver un seul point d'incohérence.

Par conséquent, étant donné que les litiges en BOLD sont menés dans le cadre de l'ensemble de l'équipe, toute action convenue prise au nom de l'équipe est soutenue par chaque membre honnête de l'équipe.

La nature déterministe d'un état L2 correct signifie que les parties honnêtes gagneront toujours si elles participent, puisque les parties malveillantes ne peuvent pas falsifier les preuves de l'exécution de la transaction. Cette conception est plus efficace car chaque partie peut "se reposer tranquillement sur les autres pour représenter sa position sans craindre que cette partie échoue délibérément au défi".

Compréhension approfondie de BOLD

Plutôt que d'être considéré comme un protocole de défi entre différentes parties, le protocole BOLD doit être compris comme une compétition entre "bords", où le but des participants est de sélectionner le bon bord comme gagnant.

Comment ce processus fonctionne-t-il en arrière-plan ?

1. "Edge" est la structure de données principale dans le protocole de challenge.
2. Le but de BOLD est de confirmer les arêtes correspondant à des calculs corrects et d'empêcher toute arête incorrecte d'être confirmée.
3. BOLD suit l'état d'un bord, mais ne lie pas un bord à une partie particulière.
4. Les arêtes sont classées en fonction de leur relation avec l'exécution correcte.
5. Le protocole ne sait pas à quelle catégorie appartient le bord, mais les participants honnêtes peuvent le dire.
6. Une arête a un "Engagement d'historique de début" et un "Engagement d'historique de fin".
7. Une arête est prouvable si son début et sa fin sont vrais, elle est déviante si seul son début est vrai et elle n'est pas pertinente si les deux sont faux.
8. Pour justifier le protocole : 8.1 Théorème de sécurité : Aucun écart par rapport à une marge ne peut être confirmé. 8.2 Temps de réalisation Théorème : Les arêtes honnêtes peuvent être confirmées avant une certaine échéance.

Infrastructure BOLD

2. Conclusion

BOLD atteint une latence optimale liée à la confirmation des résultats, et limite également linéairement le travail requis par les parties honnêtes en termes de bénéfices confisqués par la partie adverse.