État de preuve de fraude dans la couche 2 d'Éther

Je prends cela très au sérieux. À partir de l'année prochaine, je ne mentionnerai publiquement que les L2 qui ont atteint le stade 1 ou plus, lors de blogs, discours, etc. Il y aura peut-être une période de grâce temporaire pour certains nouveaux projets intéressants.

Que je participe ou non, que tu sois ou non mon ami, nous devons tous atteindre la première étape, sinon rien ne sera accordé.

Le système de "phases" de Rollup est un cadre pour évaluer approximativement son niveau de sécurité, de la phase 0 à la phase 2. Dans les Rollup les plus populaires aujourd'hui, seuls Arbitrum et Optimism ont atteint la phase 1, la plupart des autres Optimistic Rollup étant actuellement encore à la phase 0.

Dans ce cas, quelques problèmes se posent:

Depuis le lancement de l'Optimistic Rollup il y a trois ans, pourquoi aucun projet n'a-t-il atteint la phase 2 ?
Quand pouvons-nous nous attendre à ce que l'Optimistic Rollup atteigne la phase 2 ?

Cet article vise à répondre à ces questions en analysant les preuves de fraude et les mécanismes de contestation d'Optimistic Rollup, et examine les efforts de chaque projet pour atteindre la phase 2. De plus, cet article envisage également le développement futur d'Optimistic Rollup et du système de preuve de fraude.

1.2. Comparaison entre l'Optimistic Rollup et le ZK Rollup

Comme on le sait, la vitesse d'Éther est lente et le blanchiment de capitaux est élevé. Les chercheurs et développeurs de la communauté Ethereum ont travaillé dur pour résoudre ce problème. Après avoir exploré des solutions telles que le Sharding (sharding) et le plasma, la communauté a finalement décidé que le Rollup est la principale approche pour la mise en œuvre de la scalabilité. Ainsi, des Rollups tels que Arbitrum, Optimism et zkSync ont émergé. Selon les données de L2Beat, environ 40 Rollups sont actuellement en cours d'exécution, et d'autres solutions telles que Validium et Optimium adoptent des solutions alt-DA pour une scalabilité accrue, pour un total d'environ 41. De plus, il est prévu qu'environ 80 nouveaux Rollups seront lancés.

(Situation actuelle de L2 | Source: L2Beat）

Le concept clé de Rollup est d'exécuter des transactions hors chaîne, en ne soumettant que les données de transaction et l'état racine des résultats à Ethereum, ce qui permet une évolutivité. Les utilisateurs peuvent déposer des fonds dans un contrat bridge spécifique sur Ethereum, transférer ces fonds vers Rollup et effectuer des transactions à l'intérieur de Rollup. Étant donné que les données de transaction sont soumises à Ethereum et ne peuvent pas être modifiées une fois confirmées sans compromettre la sécurité d'Ethereum, on considère que Rollup "hérite de la sécurité d'Ethereum".

Mais est-ce vrai ? Et si les proposants de transactions à l'intérieur de Rollup étaient malveillants ? Les proposants malveillants pourraient altérer le solde d'Alice, le transférer vers leur propre compte et le retirer sur Ethereum, volant ainsi efficacement les fonds d'Alice.

Pour éviter cette situation, des mécanismes de sécurité supplémentaires sont nécessaires lors du retrait de Rollup vers la chaîne ETH. En fournissant une preuve au contrat de pont ETH, la transaction de retrait ne peut être achevée que si elle est correctement traitée et incluse dans la chaîne L2.

La méthode la plus simple, également adoptée par chaque Rollup, consiste à comparer le hachage de la transaction de retrait avec la racine d'état du Rollup pour prouver que cette transaction de retrait est correctement incluse dans l'état du Rollup. Cela nécessite de soumettre la transaction de retrait et la racine d'état au contrat de pont Ethereum. Les utilisateurs soumettent leurs transactions de retrait tandis que les validateurs calculent et soumettent la racine d'état.

Cependant, si les validateurs qui soumettent la racine d’état sont malveillants et que la mauvaise racine d’état est soumise, cela peut compromettre la sécurité des fonds de l’utilisateur. Pour ce risque de Goutte, deux mécanismes principaux sont proposés, qui différencient les rollups optimistes des rollups ZK.

**ZK Rollup ZK Rollup exige non seulement que les validateurs soumettent la racine de l'état, mais également qu'ils fournissent une preuve ZK pour vérifier l'exactitude du calcul de la racine de l'état. Si les validateurs soumettent une racine d'état incorrecte, la preuve ZK ne pourra pas passer la vérification du contrat de validation de L1, empêchant ainsi la soumission de racines d'état malveillantes.
**Optimistic Rollup **Optimistic Rollup permet aux validateurs désignés de soumettre une racine d'état sans garantie supplémentaire, sur la base de l'hypothèse que la soumission est honnête. Cependant, si la racine d'état soumise est incorrecte, n'importe qui peut contester et empêcher l'utilisation de cette racine d'état dans le processus de retrait. Le contestataire doit soumettre des preuves à la chaîne ETH pour prouver que la racine d'état est erronée, ce qui est appelé une preuve de fraude (fraud proof).

Pour garantir une résolution sécurisée des attaques telles que l'intention des périodes de défi de L1 Examens, le délai de retrait d'Optimistic Rollup est généralement d'environ une semaine.

1.3. Pourquoi avez-vous besoin d’une protection contre la fraude ?

Contrairement à ZK Rollup, les validateurs d'Optimistic Rollup peuvent soumettre une racine d'état incorrecte et tenter de manipuler les transactions de retrait. La preuve de fraude empêche efficacement cela, garantissant la sécurité des fonds dans le contrat de pontage.

Sans mécanisme de preuve de fraude solide, Optimistic Rollup ne peut pas hériter complètement de la sécurité d'Ethereum. Par exemple, dans le système de validateurs autorisés actuel d'Arbitrum, si tous les validateurs complotent, ils pourraient voler tous les fonds dans le contrat de pont. De même, sur des Rollup basés sur OP Stack tels que Base, un seul validateur malveillant pourrait également voler des fonds car il n'y a pas encore de mécanisme de preuve de défaillance sans permission sur Mainnet.

Par conséquent, la preuve de fraude joue un rôle clé dans la sécurité d'Optimistic Rollup et tout système qui manque d'un mécanisme de preuve de fraude complet présente un risque pour les actifs des utilisateurs.

Dans cet article, nous évaluerons les risques encourus par divers Optimistic Rollups et examinerons leurs implémentations à l’épreuve de la fraude, ainsi que leurs avantages et inconvénients.

1.4. Vers l'étape 2 : "Retrait des roues d'appoint"

Le système de protection contre la fraude a joué un rôle clé dans l’obtention de la « phase 2 » d’Optimistic Rollup. Le framework d’étape proposé par Vitalik, actuellement exploité par L2Beat, est utilisé pour évaluer le niveau de sécurité des cumuls.

Dans l'écosystème Ethereum, ce stade de développement est souvent comparé à l'apprentissage du vélo. Le Rollup de phase 0 repose sur des hypothèses de confiance maximales, et est comparé à un tricycle avec des roues d'appoint, tandis que le Rollup de phase 2, qui hérite complètement de la sécurité d'Ethereum, est comparé à un vélo sans roues d'appoint.

Voici les normes détaillées pour chaque étape, de l'étape 0 à l'étape 2 :

Comme mentionné précédemment, mettre en place un système de preuve de fraude et de mécanisme de contestation appropriés est crucial pour atteindre la phase 1 ou la phase 2 de l'Optimistic Rollup. En tenant compte de ces normes, un système de preuve de fraude répondant aux exigences de la phase 2 devrait présenter les caractéristiques suivantes :

Le système fonctionne bien, il n'y a pas de défauts connus et il possède la caractéristique "1-of-N".
Ceci est un système sans licence, n'importe qui peut soumettre une preuve.
Si des vulnérabilités sont identifiées dans le système de preuve, elles devraient pouvoir être prouvées hors chaîne.

Dans la seconde moitié de cet article, nous explorerons comment divers protocoles tentent de mettre en œuvre ces fonctionnalités.

2. preuve de fraude - concept et malentendus

2.1. Comment la preuve de fraude est-elle mise en œuvre ?

fraud proof provides off-chain verifiable evidence that the submitted state root is incorrect, indicating that a specific state transition function in L2 is not properly executed. One simple method is to start from the previous confirmed state root and generate proofs for executing all L2 Blocs until the current state root, thereby proving that the state root is incorrect. However, this method is costly and time-consuming.

Par conséquent, lors de la génération d'une preuve de fraude valide, il est nécessaire de d'abord réduire à un certain état de transition incorrect, puis générer la preuve pour cette partie. La plupart des protocoles de preuve de fraude suivent cette méthode.

fraud proof和质疑protocole通常包括以下步骤：

Les validateurs (proposants) soumettent régulièrement des sorties (ou déclarations) contenant la racine de l'état L2 à Ethereum.
Si les validateurs ne sont pas d'accord avec la sortie, ils lanceront une contestation.
Les auteurs et les contestataires identifient les parties en désaccord par un processus appelé la méthode du binaire ou de la dissection, en les affinant au niveau des instructions ou au niveau du Bloc (ZK Rollup).
Les contestataires soumettent des preuves de fraude hors de la chaîne pour prouver les parties incorrectes. Des protocoles tels que Arbitrum et Optimism exécutent généralement des instructions suspectes hors de la chaîne pour vérification.
Si la preuve de fraude est validée, les sorties incorrectes seront supprimées ou remplacées. Selon le protocole de contestation, le demandeur peut être puni, tandis que le contestataire sera récompensé.

2.2. Malentendu courant : la preuve de fraude et la remise en cause ne feront pas rollback de la chaîne

Il est important de noter que même en cas de preuve de fraude et de contestation, la chaîne ne sera pas annulée. La preuve de fraude garantit que les fonds dans le contrat de pont ne seront pas extraits de manière malveillante, sans impliquer de retour en arrière des transitions d'état incorrectes.

La principale raison de ne pas effectuer de rollback est qu'il n'est pas nécessaire. Lorsqu'une transition d'état incorrecte se produit dans Rollup, le problème principal est que des acteurs malveillants pourraient dérober les fonds des utilisateurs via le bridge. Pour éviter cela, il suffit de s'assurer que la racine de l'état soumise à L1 est correcte. Ce processus n'a rien à voir avec le rollback de la chaîne, il suffit de prévenir la confirmation finale d'une racine d'état malveillante, les preuves de fraude et les mécanismes de contestation sont suffisants.

De plus, s'il s'avère que les proposants de l'état racine et les arrangeurs de blocs L2 sont des entités distinctes, il n'est pas non plus nécessaire de mettre en œuvre le mécanisme de Rollback.

Par conséquent, même si les doutes sont résolus avec succès, la chaîne L2 ne sera pas Rollback ; seul l'état racine (sorties ou déclarations) soumis à L1 sera supprimé ou remplacé. Si la preuve de fraude et le mécanisme de doute fonctionnent normalement, la sécurité des fonds transférés par les utilisateurs sera garantie par le pont.

2.3. Cas réel : Le doute de Kroma en avril 2024

À partir de cas de contestation réels, on peut voir que toute la chaîne Rollup ne sera pas Rollback, seule la racine de sortie sera remplacée ou supprimée. Jusqu'à présent, le seul cas de contestation réussi connu sur Mainnet s'est produit en avril 2024 avec Kroma, un Rollup hybride basé sur OP Stack utilisant des preuves de défaillance ZK.

Kroma est un Rollup basé sur OP Stack, avec son propre système de preuve de défaillance ZK et des validateurs sans permission. Le 1er avril 2024, il y a eu un problème avec la source L1 du séquenceur Kroma, ce qui a entraîné la génération d'un Bloc incorrect par le séquenceur. De plus, les validateurs ayant observé cette situation ont soumis une racine de sortie erronée. Peu de temps après la soumission de la racine de sortie, 12 contestataires ont remis en question cette sortie.

L'un des détracteurs a réussi à appeler la fonction proveFault et à supprimer la sortie erronée.

Le sceptique a réussi à exécuter la fonction proveFault | Source:etherscan

Ceci est le premier cas de contestation réussie dans l'histoire du Rollup Mainnet d'ETH. C'est également le premier cas où une preuve de défaillance a été vérifiée et contestée avec succès sur un environnement Mainnet depuis la sortie du premier Optimistic Rollup (Arbitrum) en mai 2021, il y a environ trois ans. Pour une description détaillée de cette contestation, veuillez consulter l'article rédigé par Kroma (https://blog.kroma.network/about-the-first-successful-challenge-on-kroma-mainnet-aeca715b05d7). Dans ce cas, la chaîne Kroma n'a pas effectué de rollback, elle a simplement supprimé la racine de sortie incorrecte.

Déclaration de non-responsabilité : fraud proof ou preuve de fraude ?

La preuve de la fraude est également connue sous le nom de preuve d’échec. En particulier, dans les chaînes Optimism et OP Stack, le terme « preuve d’échec » est utilisé, tandis que dans des projets tels que Arbitrum, Cartesi, L2Beat, etc., le terme utilisé est « à l’épreuve de la fraude ».

Compte tenu des cas de remise en question de Kroma susmentionnés, on peut en déduire que les remises en question proviennent souvent d'une "erreur" plutôt que d'une tentative malveillante de manipulation des retraits. Dans les cas susmentionnés, la principale raison est l'observation d'une anomalie du client L1 par les validateurs Kroma. En d'autres termes, la remise en question est parfois simplement due à une erreur des validateurs ou à un patch inapproprié. Dans ce cas, l'utilisation du terme "preuve de panne" pourrait être plus appropriée.

Cependant, le terme qui reflète mieux son objectif est "fraud proof". Tous les mécanismes introduits jusqu'à présent, ainsi que ceux qui seront introduits à l'avenir, visent à vérifier les "comportements frauduleux" qui tentent de voler les fonds du pont par des sorties malveillantes.

Le point clé est que, bien que l'objectif soit de prévenir la fraude, les doutes peuvent en réalité être causés par des erreurs. Dans cet article, je vais utiliser le terme "fraud proof", qui est plus largement utilisé dans l'écosystème.

3. Attaque de Hacker! - Utilisation du mécanisme de preuve de fraude

3.1. 设计经济争议protocole

Chaque Optimistic Rollup met en œuvre son propre protocole et mécanisme de preuve de fraude pour protéger les fonds des utilisateurs. L'objectif commun de ces mécanismes est que le protocole reste sûr tant qu'il y a au moins un participant honnête. La preuve de fraude est une preuve que la fonction de transition d'état prévue a été correctement exécutée, et le processus de vérification finira par produire un résultat en faveur des participants honnêtes.

Cependant, ce n'est pas toujours le cas. En réalité, même en présence de participants honnêtes, il peut y avoir des situations où le protocole est en danger. Par exemple, en raison de la complexité du fraud proof, des vulnérabilités inattendues peuvent survenir, et les participants malveillants peuvent obtenir un avantage économique par rapport aux participants honnêtes en raison d'un alignement incorrect des incitations, entraînant des retards importants dans les retraits ou le vol de fonds.

Par conséquent, la conception de preuves de fraude et de mécanismes de remise en question est une tâche très difficile. En particulier, pour devenir un Rollup de phase 2, le mécanisme de remise en question doit être parfait et doit avoir des contre-mesures contre divers vecteurs d'attaque et vulnérabilités.

En d'autres termes, chaque preuve de fraude et mécanisme de remise en question doit prendre en compte comment faire face aux vecteurs d'attaque. Si l'on ne comprend pas chaque vecteur d'attaque, on ne peut pas comprendre pourquoi le protocole doit être conçu de cette manière.

Par conséquent, dans cette section, nous étudierons d'abord les Vecteur d'attaque suivants et explorerons comment chaque protocole fait face à ces attaques :

Attaques causées par des failles dans les jeux controversés;
attaque de latence, prolonge le temps de retrait de l'utilisateur de plus de 7 jours ;
Attaque Sybil qui consomme les fonds et les ressources des participants honnêtes ;
Attaque déclenchée par les validateurs L1 examinant ;
Attaques lancées en exploitant les vulnérabilités de Machine virtuellefraud proof.

Note: Les Vecteurs d'attaque discutés ci-dessous sont tous connus publiquement et n'affectent pas la sécurité de n'importe quel Mainnet.

Les prochains chapitres analyseront les différents protocoles et leurs caractéristiques respectives comme suit :

3.2. Vecteur d'attaque #1：利用经济争议游戏

La plupart des implémentations de l'optimiste Rollup avec un mécanisme de preuve de fraude exigent une approche binaire pour trouver le premier point de divergence. Le protocole doit fournir des incitations pour encourager les participants à agir de manière honnête, ce qui est crucial.

L'un des moyens les plus simples pour atteindre cet objectif est de demander aux participants de mettre une certaine somme d'argent en garantie (Marge) lorsqu'ils prennent des mesures, et s'ils sont considérés comme ayant un comportement malveillant, ils seront soumis à une sanction (slashing) sur la Marge.

Du point de vue de la théorie des jeux, protocole doit s'assurer que les participants malveillants dépensent plus d'argent pour attaquer que les participants honnêtes ne le font pour se défendre. Cependant, cela est très difficile à réaliser.

La raison clé ici est qu'environnement de jeu, avant que les interrogations ne soient terminées, il est impossible de savoir à l'avance qui est un participant malveillant. En d'autres termes, les déclarants qui soumettent les sorties peuvent être malveillants, tout comme les interrogateurs qui remettent en question les sorties. Par conséquent, le protocole doit être conçu en supposant que l'une ou l'autre partie peut être malveillante. De plus, en raison de la possibilité de divers vecteurs d'attaque, la conception du protocole devient extrêmement complexe.

Étant donné que chaque protocole utilise des mécanismes différents, il est donc nécessaire de définir un vecteur d'attaque et un modèle d'incitation pour chaque méthode correspondante. De plus, il est nécessaire de concevoir un modèle de sécurité économique pour garantir la sécurité, même lorsque ces modèles sont combinés.

Ce sujet est toujours en cours de discussion. Dans cette section, nous analyserons les Vecteur d'attaque qui pourraient se produire couramment, ainsi que les incitations des participants dans ces scénarios. De plus, nous examinerons comment chaque protocole fait face à ces attaques et dans quelle mesure ils limitent ces incitations.

3.2.1. Vecteur d'attaque #1-1: attaque de latence

L'attaque de latence fait référence à une entité malveillante qui n'a pas l'intention de voler des fonds Rollup, mais de bloquer ou retarder la confirmation sur L1. Cette attaque peut se produire dans la plupart des Rollup optimistes actuels, ajoutant un latence supplémentaire aux retraits et empêchant les utilisateurs de retirer des fonds de L1 pendant plus d'une semaine.

Ceci est légèrement différent de l'attaque causée par l'examen des validateurs L1, ce dernier étant discuté plus tard. L'examen empêche les participants honnêtes d'agir sur le bloc ETH, permettant ainsi la confirmation finale de la racine d'état malveillante. D'autre part, l'attaque de latence peut retarder la confirmation finale de la racine d'état, même si les participants honnêtes participent activement. Dans ce cas, le retrait de l'utilisateur peut non seulement être retardé, mais si le capital de l'attaquant est supérieur à celui du défenseur, la racine d'état malveillante peut être confirmée finalement, ce qui entraîne le vol des fonds de l'utilisateur.

L'un des moyens les plus simples de prévenir les attaques de latence est de demander aux participants du système en question de bloquer une certaine somme d'argent ou de Marge. S'ils sont soupçonnés de causer des retards, leur Marge peut être slashing.

Cependant, certains facteurs doivent être pris en compte. Que faire si l'attaquant tente toujours une attaque de latence même s'il n'a pas peur que les fonds soient confisqués ?

Ce Vecteur d'attaque est assez délicat. C'est aussi la raison pour laquelle le système de preuve de fraude d'Arbitrum fonctionne actuellement dans une structure autorisée.

Le mécanisme de preuve de fraude utilisé dans Arbitrum One et Arbitrum Classic utilise un modèle de bifurcation. Au lieu de simplement permettre aux participants de contester des déclarations incorrectes, chaque participant soumet une déclaration qu'il considère comme correcte, accompagnée d'une certaine quantité de fonds, considérée comme une “fourchette de chaîne”. Les déclarations peuvent également être considérées comme des points de contrôle de l'état de la chaîne.

Le modèle de bifurcation d'Arbitrum

Dans Arbitrum Classic, les participants soumettent leurs déclarations et branches de chaîne qu'ils estiment correctes, éliminent progressivement les branches de chaîne incorrectes par des contestations, et finalement confirment les déclarations correctes.

Cependant, une seule remise en question ne peut pas déterminer qui a raison. Deux participants malveillants peuvent diviser de manière incorrecte en définissant des points non pertinents comme des points de divergence, excluant ainsi la déclaration correcte. Par conséquent, Arbitrum s'assure que la remise en question se poursuit jusqu'à ce qu'aucun participant ne mette en jeu des fonds sur une déclaration spécifique, garantissant ainsi que si au moins un participant honnête existe, la remise en question peut être résolue avec succès.

Cela peut être exploité de manière malveillante pour une attaque de latence. Supposons qu'il y ait un participant honnête et N-1 attaquants malveillants qui parient des fonds sur une déclaration correcte, tandis qu'un attaquant parie des fonds sur une déclaration incorrecte. Si l'attaquant peut soumettre ses transactions avant les participants honnêtes, ils peuvent lancer une contestation en premier. Dans le pire des cas, s'ils divisent de manière incorrecte leur consensus au lieu de leur dissension, ils peuvent soumettre une preuve de fraude sur la partie incorrecte. Naturellement, cela passera, entraînant l'échec de la mise en gage de fonds sur la déclaration correcte.

由于每个质疑可能需要长达 7 天的时间，攻击者可以将protocole的latence时间延长至 7 * (N-1) 天。

Attaque de latence sur Arbitrum Classic | Source : L2Beat Medium

Le problème de ce mécanisme est que le coût des attaques de latence est hausse linéaire avec le temps de latence protocole. Si les attaquants découvrent que cette attaque est rentable, ils voudront prolonger autant que possible le temps de latence du protocole, et le temps total de latence sera proportionnel au montant total de fonds des attaquants, ce qui peut entraîner un temps de latence très long pour les retraits des utilisateurs.

En résumé, un protocole de preuve de fraude efficace pour défendre contre les attaques de latence doit être conçu de manière à limiter le temps de latence maximal dans une certaine plage, ou à mettre en place un mécanisme d'hausse exponentielle des coûts d'exécution de la latence au fil du temps, de sorte que le coût d'une attaque soit supérieur à l'incitation à attaquer.

3.2.2. Vecteur d'attaque #1-2：Sybil 攻击（资源耗尽攻击）

Un autre Vecteur d'attaque est l'attaque Sybil (attaque par épuisement des ressources, attaque Baleine). Lorsque les fonds ou les ressources de calcul de l'attaquant dépassent ceux du défenseur, cette situation se produit. L'attaquant peut soumettre continuellement des racines de sortie incorrectes ou créer des contestations sans signification, épuisant ainsi les fonds ou les ressources de calcul du défenseur. À un moment donné, le défenseur épuisera ses fonds ou ses ressources de calcul disponibles, ne pourra plus se défendre, et l'attaquant finira par déterminer la racine de sortie incorrecte et voler les fonds.

En général, le Vecteur d'attaque susmentionné peut se produire dans un système non autorisé de deux manières suivantes :

Continuer à soumettre des sorties incorrectes. Supposons que l'attaquant Bob ait plus de fonds que la somme des participants honnêtes (défenseurs) Alice, Charlie et David. Dans ce cas, Bob soumet continuellement des racines de sortie incorrectes. Les participants honnêtes Alice, Charlie et David répondront en payant des frais de gaz et des dépôts, et à un certain seuil, les fonds des participants honnêtes seront épuisés avant ceux de Bob. À ce stade, Bob soumet une autre sortie incorrecte, et comme il n'y a plus de fonds restants chez les participants honnêtes dans le réseau, cette sortie sera finalement acceptée sans être remise en question. Ainsi, Bob peut voler des fonds du rollup optimiste.
Soumettre plusieurs remises en question de manière honnête. Au contraire, un acteur malveillant peut attaquer un acteur honnête en soumettant plusieurs remises en question. De même, l'attaque se poursuivra jusqu'à ce que l'acteur honnête ait épuisé tous les fonds utilisés pour les frais de gas et les dépôts, puis l'attaquant malveillant soumettra une sortie incorrecte et volera les fonds des utilisateurs du bridge.

Pour empêcher de telles attaques, il est nécessaire de concevoir de manière adéquate les avantages du défenseur par rapport à l'attaquant. Dans tous les cas, le défenseur doit avoir suffisamment d'avantages sur l'attaquant. Une façon d'y parvenir est de concevoir soigneusement les dépôts de garantie ; étant donné que l'attaque Sybil est liée au montant total de fonds disponibles pour chaque participant, si les dépôts de garantie sont bien configurés, il devrait être possible de garantir que le système est sécurisé tant que le montant total des fonds de l'attaquant ne dépasse pas N fois le montant total des fonds du défenseur.

Une autre méthode connue pour prévenir les attaques Sybil est de mettre en place un protocole de résistance Sybil controversé. Dans les sections suivantes, nous présenterons plus en détail Cartesi Dave.

Let's see how each protocole deals with these latence and Sybil attacks through their respective designs.

3.3. Solution #1: Jeu de dispute économiquement sain

1） Arbitrum BoLD

BoLD a introduit les trois éléments suivants sur la base du modèle de bifurcation d'Arbitrum Classic pour prévenir les attaques de latence :

Tous les mécanismes de remise en question. Dans BoLD, la remise en question n'est plus effectuée paire par paire, mais plutôt par un système de tous contre tous concurrents, où tous les participants peuvent miser de l'argent sur la branche de leur choix. Cela empêche la latenceVecteur d'attaque précédemment engendrée par les remises en question individuelles et garantit qu'il ne peut y avoir plusieurs remises en question indépendantes pour le même litige.
La preuve de la latence empêche la bifurcation malveillante basée sur l'état correct (engagement historique). Le problème dans Arbitrum Classic est que les participants malveillants peuvent bifurquer de manière incorrecte, intentionnellement créer de la latence et marquer les parties non contestées comme des points de contestation. Pour cela, BoLD exige une preuve soumise avec la racine d'état pour vérifier que la racine d'état a été correctement calculée lors du processus de bifurcation, garantissant qu'il n'y a pas eu de bifurcation malveillante.

Dans BoLD, les participants doivent soumettre une preuve et une racine d'état lors du processus de scission. Cette preuve vérifie si la racine d'état actuelle a été correctement calculée sur la base de la racine d'état précédemment soumise. Si un participant malveillant tente de soumettre une racine arbitraire qui n'est pas liée à la racine d'état précédemment soumise, la vérification de la preuve échouera, entraînant l'échec de la transaction de scission. Cela garantit efficacement que chaque déclaration ne peut subir qu'un seul type de scission.

Par conséquent, si un attaquant veut diviser plusieurs fois une déclaration honnête dans BoLD, il doit soumettre plusieurs déclarations.

Cependant, la génération de cette preuve nécessite que les validateurs utilisent une quantité considérable de ressources de calcul. En interne, la génération de cette preuve nécessite la génération d'un hachage pour tous les états dans la recherche binaire, ce qui nécessite généralement environ 270 hachages sur Arbitrum (environ 1,18 x 10²¹). Pour résoudre ce problème, BoLD divise les contestations en trois niveaux, réduisant le nombre de hachages à calculer à 226 (environ 6,71 x 10⁷).

(Ce graphique suppose un total de 269 instructions, les données réelles peuvent être différentes)

Limiter le temps de stake via le mécanisme de l'horloge d'échecs.

Dans l'Arbitrum Classic précédent, la durée des contestations n'était pas limitée dans le temps, ce qui permettait aux participants malveillants de retarder le protocole indéfiniment tant qu'ils disposaient de suffisamment de fonds. BoLD introduit un mécanisme d'horloge d'échecs qui limite efficacement la durée des contestations.

Supposons que deux participants soumettent des déclarations différentes. Chaque participant a une horloge (une pendule d'échecs) réglée à 6,4 jours. Lorsqu'il est temps pour un participant de soumettre une preuve ou un témoignage, l'horloge démarre et s'arrête une fois que le participant a terminé sa tâche.

Étant donné que chaque participant dispose de 6,4 jours, le temps maximal de latence pour un seul participant est de 6,4 jours. Par conséquent, dans BoLD, la durée maximale du doute est de 12,8 jours (dans certains cas, elle est prolongée de 2 jours supplémentaires lorsque le comité de sécurité intervient).

Grâce à ces mécanismes, Arbitrum BoLD limite efficacement la latence causée par les doutes. La durée maximale des doutes est de deux semaines et la latence supplémentaire maximale que les utilisateurs peuvent subir est d'environ une semaine.

Cependant, cela pourrait être exploité pour mener des attaques de latence. Les acteurs malveillants peuvent créer une contestation et conspirer avec les validateurs de L1 pour examiner les validateurs honnêtes sur Arbitrum, ce qui entraînerait une latence de retrait pouvant durer jusqu'à une semaine pour les utilisateurs d'Arbitrum. Dans ce cas, les utilisateurs demandant un retrait pendant cette période pourraient être confrontés à des coûts d'opportunité en raison du gel de leurs fonds. Bien que ce ne soit pas une attaque visant directement à tirer un profit des fonds, elle devrait néanmoins être prévenue en raison des coûts d'opportunité pour les utilisateurs. Arbitrum BoLD répond à ce problème en dissuadant ce type d'attaque grâce à la fixation d'une caution suffisamment élevée pour créer une contestation.

Arbitrum a calculé ce montant dans le document économique en gras. La principale raison de la latence du protocole est l'examen des validateurs L1. En cas d'attaque de latence, la situation se déroulera comme suit:

L'attaquant soumet une déclaration N' incompatible avec la déclaration existante N sur Arbitrum.
Le défenseur a tenté d'envoyer une transaction binaire, mais cette opération a échoué car les validateurs L1 examinent la transaction de contestation du défenseur.
Comme l'examen de l'hypothèse BoLD ne peut pas durer plus de 7 jours, cela peut entraîner une confirmation finale de la déclaration N avec un maximum de latence d'une semaine.

Les profits des attaquants proviennent du coût d'opportunité supporté par les utilisateurs qui remettent en question les demandes de retrait. Dans le pire des cas, si tous les fonds d'Arbitrum sont demandés en retrait dans une seule sortie, le coût d'opportunité supporté par l'utilisateur est calculé comme suit, en supposant que le TVL d'Arbitrum One est de 154 milliards de dollars et que l'APY est de 5% :

Coût d'opportunité = 15,400,000 x (1.051/52 - 1) = $14,722,400

Étant donné que la soumission d'une déclaration incorrecte peut entraîner un coût d'opportunité aussi élevé, les soumissionnaires de déclarations dans BoLD sont tenus de fournir un dépôt de garantie de magnitude similaire. Actuellement, le dépôt de garantie requis pour la soumission de déclarations dans BoLD est de 3600 ETH, soit environ 9,4 millions de dollars.

Cela est fait pour éviter aux attaquants de causer de graves pertes au système grâce à la latence. Étant donné que les attaquants perdront leur dépôt en cas de contestation, ils peuvent causer un coût d'opportunité pouvant atteindre 14,7 millions de dollars, mais ils perdront environ 9,4 millions de dollars en capital. Par conséquent, BoLD réprime les attaques de latence en exigeant un dépôt équivalent au coût d'opportunité maximal.

Cependant, le dépôt de garantie de 3600 ETH n'est pas seulement établi en raison d'une attaque de latence. Pour se défendre contre les attaques Sybil, Arbitrum BoLD peut garantir que le système reste sécurisé avant que le capital total de l'attaquant ne soit 6,5 fois supérieur au capital total du défenseur, c'est la base de détermination du montant du dépôt de 3600 ETH.

Du point de vue d'une attaque Sybil, les scénarios d'attaque suivants pourraient se produire dans Arbitrum BoLD. Le système de remise en question de BoLD est composé de trois niveaux, où les utilisateurs doivent verrouiller des fonds pour soumettre leurs déclarations qu'ils estiment correctes.

Supposons que l'honnête participant Alice ait soumis une déclaration valide pour un montant de X ETH. Le participant malveillant Bob, qui possède 3600 ETH, peut créer plusieurs déclarations malveillantes. À ce stade, Alice doit bloquer Y ETH pour chaque déclaration de Bob.

Dans le modèle de chaîne latérale d'Arbitrum, verrouiller des fonds signifie accepter l'état de la chaîne de la genèse à la déclaration. Cette fonctionnalité permet aux participants de déplacer les fonds qu'ils ont mis en gage de la déclaration A vers ses sous-déclarations A' et A''. Ainsi, Alice déplace les X ETH qu'elle a initialement mis en gage vers le niveau inférieur, et verrouille Y ETH pour chaque déclaration malveillante de Bob.

Si Bob a clairement plus de fonds qu'Alice, que se passe-t-il? Bob peut générer d'innombrables déclarations malveillantes jusqu'à épuiser les fonds d'Alice et l'empêcher de continuer à verrouiller. À ce stade, Alice ne pourra plus continuer à bifurquer, ce qui permettra à Bob de confirmer des déclarations incorrectes.

Au final, la question se résume à la mesure dans laquelle le défenseur devrait être plus avantagé que l'attaquant dans le jeu.

Arbitrum appelle ce ratio le ratio de ressources. Il indique l'avantage des participants honnêtes par rapport aux participants malveillants. Ce ratio est représenté par le rapport entre les frais de gaz (G) que chaque participant doit payer et le montant de l'engagement (S), comme indiqué ci-dessous :

Le système de mise en doute de BoLD est divisé en trois niveaux, en maintenant ce ratio de ressources à chaque niveau pour garantir que le défenseur ait toujours N fois plus d'avantages que l'attaquant dans l'ensemble du système. Arbitrum calcule la quantité de dépôt requise pour le niveau supérieur en fonction de ce ratio de ressources et trace un graphique.

（Coût de mise en gage du litige de couche supérieure par rapport au ratio de ressources d'Arbitrum BoLD | Source :Desmos）

Selon ce graphique, lorsque le ratio de ressources est multiplié par 100, le dépôt requis au sommet dépasse 1 million d'ETH (plus de 4 billions de dollars). Bien que des ratios de ressources plus élevés rendent le système plus sûr contre les attaques Sybil, le montant du dépôt devient si élevé que presque personne ne peut participer au système, ce qui le rend semblable à un système centralisé où une seule entité soumet des déclarations.

Par conséquent, dans BoLD, le ratio des ressources est fixé à 6,5 fois, ce qui rend la marge supérieure de 3600 ETH, et les marges de niveau un et deux sont respectivement fixées à 555 ETH et 79 ETH.

En résumé, BoLD garantit une défense 6,5 fois supérieure à celle de l'attaquant en calculant le ratio des ressources et en fixant le montant de l'engagement pour prévenir les attaques Sybil.

2）Cartesi Dave

Dave de Cartesi a proposé pour la première fois en décembre 2022 dans un document intitulé "Tournoi d'examen non autorisé" avant le premier livre blanc de BoLD. Il vise à maintenir l'avantage des ressources de calcul et des fonds des participants honnêtes par rapport aux attaquants. La structure de Dave est similaire à celle de BoLD et présente deux caractéristiques clés :

La preuve de calcul d'état correcte (engagement historique) empêche la bifurcation malveillante.

Comme BoLD, Dave demande aux participants de générer une preuve pendant le processus de division pour montrer qu'ils ont effectué correctement les calculs et ainsi prévenir les formes malveillantes de division. Par conséquent, le système de remise en question de Dave est également divisé en plusieurs niveaux pour économiser les ressources des validateurs.

Le mécanisme de contestation en un-à-un est utilisé dans la structure du tournoi.

Les doutes de Dave ne sont pas exprimés une seule fois, mais sous forme de tournoi, comme indiqué dans le schéma ci-dessous.

Le schéma ci-dessus montre comment les remises en question sont effectuées lorsque sept déclarations erronées sont soumises par un attaquant malveillant pour remettre en question le réseau. En raison de la nature des engagements historiques, les participants honnêtes qui soutiennent les déclarations correctes (représentées en vert) sont regroupés en équipes. Dans Dave, ils sont organisés sous forme de tournoi et disposés selon le schéma, chaque participant faisant face à un seul défi. Les défis de la même phase sont effectués en parallèle et, après une semaine, lorsque les défis sont terminés, les gagnants passeront à la phase suivante. Dans le schéma, l'équipe des participants honnêtes doit passer par trois phases de défi pour remporter le tournoi.

Cette fonctionnalité est très efficace pour prévenir les attaques Sybil. Tout d'abord, l'attaquant doit créer plusieurs déclarations pour effectuer une attaque Sybil, chaque déclaration consommant considérablement les ressources de calcul et les fonds de l'attaquant.

La preuve de concept de Cartesi montre que, dans toutes les circonstances, le défenseur conserve toujours un avantage exponentiel sur l'attaquant. En d'autres termes, Dave s'assure qu'il peut défendre contre les attaques Sybil avec une ressource logarithmique par rapport au nombre d'attaquants. Cela rend l'exécution d'une attaque Sybil dans Dave très difficile, c'est pourquoi le montant de la mise en jeu de Dave est fixé à un minimum de 1 ETH, bien inférieur à celui de BoLD.

Cependant, Dave est facilement sujet à des attaques de latence. Chaque phase du tournoi consomme une unité de temps de remise en question (une semaine), donc plus il y a de déclarations malveillantes, plus la latence du protocole est longue. Le temps nécessaire pour résoudre complètement une question dans Dave peut être exprimé par la formule suivante :

Td = 7 x log2(1 + NA)(天数)

Où NAN_ANA représente le nombre de déclarations malveillantes. Cependant, les doutes de Dave peuvent être constitués de plusieurs niveaux pour générer efficacement des engagements historiques. Ici, les participants malveillants peuvent générer NAN_ANA déclarations malveillantes à chaque niveau de doute, ce qui augmentera le temps total de latence comme suit :

Td = 7 x [log2(1 + NA)]L(天数)

Où LLL représente le nombre de niveaux dans chaque contestation. Si, comme le montre le graphique ci-dessus, il y a sept déclarations malveillantes et L=2, alors la résolution complète de la contestation peut prendre jusqu'à 9 semaines, et les utilisateurs subiront une latence de retrait supplémentaire de 2 mois. Si le nombre de niveaux augmente ou si le nombre de déclarations malveillantes augmente, la latence pourrait s'allonger à plusieurs mois.

Cartesi vise à résoudre ce problème en utilisant la preuve de connaissance zéro (ZK), dont une discussion détaillée aura lieu dans la section 4, "Améliorations possibles".

3) Preuve d'optimisme des pannes (Optimism Fault Proof, OPFP)

OPFP est un protocole non autorisé, actuellement utilisé dans le Mainnet OP, avec les caractéristiques suivantes :

Tous les mécanismes de remise en question concurrents de l'arbre de jeu

OPFP permet à n'importe qui de soumettre des sorties (déclarations de racine) à tout moment. Les validateurs qui ne sont pas d'accord avec les sorties soumises peuvent les contester en lançant un processus de bifurcation.

OPFP Architecture of Game Trees and Binary Partitioning | Source: Optimism File

Le processus de bifurcation se déroule de manière concurrente sur l'arbre de jeu illustré ci-dessus. Les feuilles de l'arbre représentent l'état de L2, chaque Nœud de l'arbre correspond à un état de L2, et la feuille la plus à droite représente le dernier état de L2. Par exemple, soumettre une déclaration au Nœud 1 est équivalent à soumettre un état au Nœud 31.

Cette structure permet de représenter une bifurcation. Par exemple, si un validateurs n'est pas d'accord avec une déclaration de racine (Nœud 1), il soumettra une déclaration à Nœud 2, qui correspond à Nœud 23 dans l'arbre car il est le point médian entre Nœud 16 et Nœud 31. L'auteur de la soumission de Nœud 1 vérifiera ensuite l'état L2 de Nœud 23 et, s'il est d'accord, soumettra Nœud 6 (Nœud 27); s'il n'est pas d'accord, il soumettra Nœud 4 (Nœud 19), et ce processus se poursuivra jusqu'à ce qu'une divergence soit trouvée.

Même s'il existe plusieurs directions binaires dans un jeu, elles peuvent être menées simultanément, et n'importe qui peut participer au processus binaire, pas seulement l'expéditeur de la production.

Architecture complète de l'arbre de décision OPFP | Source : Fichier Optimism

L'arbre de jeu utilisé dans OPFP est une structure imbriquée, où l'arbre supérieur traite une division binaire au niveau du Bloc, tandis que les sous-arbres inférieurs traitent une division binaire au niveau de l'instruction.

Contrairement à BoLD ou Dave, OPFP n'impose pas la bifurcation correcte par le biais d'engagements historiques, car les coûts de génération et de soumission de tels engagements off-chain/off-chain sont élevés.

Jeu de disputes personnalisable basé sur la modularité Actuellement, le Mainnet OP n'a lancé que deux types de jeux de litige (non autorisés / autorisés). Optimism vise à finalement introduire divers types de jeux de litige et a mis en place une interface minimale pour soutenir cet objectif. En suivant les noms de fonctions et les paramètres spécifiés, il est possible de créer des jeux de litige personnalisés.
Limiter le temps de questionnement en utilisant l'horloge d'échecs

Dans OPFP, lorsque des doutes surviennent, le demandeur et le douteur reçoivent tous les deux une horloge, qui est allouée pour le temps de bifurcation. Chaque fois qu'une déclaration est faite, l'horloge commence à chronométrer l'autre partie. L'Optimisme l'appelle "l'horloge héritée du grand-père".

Ce qui est intéressant, c'est que chaque participant est autorisé à avoir 3,5 jours au lieu de 7 jours, ce qui signifie que si personne ne remet en question la sortie, celle-ci sera définitivement déterminée dans les 3,5 jours.

Cependant, cela ne permet pas un retrait immédiat. Une période de garde de 3,5 jours est prévue pour l'OPFP après la confirmation finale de la sortie, au cours de laquelle la commission de sécurité peut intervenir et, si nécessaire, rendre la sortie incorrecte invalide.

Processus de retrait des utilisateurs dans le 'Chemin du Bonheur' | Source: Blog OP Labs

Sur la base de ces mécanismes, OPFP et autres rollups optimistes garantissent aux utilisateurs de pouvoir retirer au moins 7 jours après leur soumission. Cependant, en cas de contestation, les utilisateurs pourraient avoir besoin de plus de 7 jours pour effectuer le retrait via cette sortie. Le modèle d'horloge d'échec d'OPFP limite le temps qu'un participant peut passer dans le processus de bifurcation, mais ne limite pas strictement le temps total avant la résolution de la contestation.

Cela soulève une question : si des doutes surgissent sur OPFP, est-il possible que les retraits des utilisateurs subissent une latence de plus d'une semaine, comme c'est le cas avec BoLD ? La réponse est "oui". Contrairement à BoLD ou Dave, Optimism offre aux utilisateurs des options pour faire face aux doutes, ce qui repose sur les caractéristiques uniques du protocole.

OPFP operates on the assumption that participants who make incorrect declarations will lose their Marge. However, there is an edge case in OPFP that breaks this assumption, known as the 'free-rider declaration'. This situation may occur in the following scenarios:

Alice a soumis une déclaration de racine d'état correcte.
Bob a fait une contre-déclaration tandis qu'Alice prend des mesures pour défendre sa déclaration initiale.
Bob attendit que sa montre soit presque épuisée (3,5 jours) avant de remettre en question sa déclaration.

À ce stade, Alice devrait répondre et réclamer la Marge de Bob, mais elle hérite du temps restant sur l'horloge de Bob, ce qui pourrait ne pas être suffisant pour contester sa déclaration. Ainsi, Bob pourrait éviter de perdre sa Marge en soumettant une déclaration de "covoiturage".

Déclaration de l'opportunisme de la preuve de défaillance | Source :L2Beat

Bien que cela n'empêche pas les doutes d'être correctement résolus, cela représente effectivement une situation où "une déclaration incorrecte a été soumise sans slashingMarge", du point de vue de l'incitation, cette situation devrait être évitée.

Par conséquent, si le temps restant du proposant ou du contestataire est inférieur à 3 heures, l'OPFP résoudra ce problème en réinitialisant l'horloge à 3 heures. Cela garantit un temps suffisant pour réfuter les allégations de parasitisme. Cependant, si aucune action n'est entreprise au cours de la prochaine période de deux heures et demie, le litige prendra fin.

Nous pouvons imaginer une situation dans laquelle ce mécanisme est utilisé pour mener une attaque de latence. Supposons qu'un participant honnête, Alice, soumette une sortie correcte. À partir du moment de la soumission d'Alice, le chronomètre du contestataire se met en marche. Le participant malveillant, Bob, attend une seconde avant l'expiration du chronomètre du contestataire pour soumettre une sortie incorrecte. À ce stade, les règles de l'OPFP prolongeront le temps de Bob à 3 heures. Alice répondra, tandis que Bob continuera à profiter des 3 heures supplémentaires fournies à chaque bifurcation.

Cela pourrait mettre en doute la latence de la résolution. Bob peut latence jusqu'à 3,5 jours + 3 heures × le nombre maximum de divisions. MAX_GAME_DEPTH de OPFP est 73, ce qui signifie que Bob peut retarder le processus jusqu'à 3,5 jours + 3 heures × 36 = 8 jours. Si Alice adopte des mesures similaires pour remettre en question la latence, le processus de division pourrait prendre 16 jours.

Cela signifie-t-il que les utilisateurs ne peuvent pas retirer leur argent dans les 16 jours? En fait, ce n'est pas le cas car la logique de retrait d'Optimism rend cette situation impossible. Contrairement à Arbitrum, qui exige que les retraits soient prouvés et inclus dans un bloc L2 spécifique, OP Stack utilise un mécanisme de preuve de stockage où les demandes de retrait sont enregistrées dans le contrat L2ToL1MessagePasser de L2. Cela signifie que même si le temps de contestation pour une sortie spécifique est long, les utilisateurs peuvent toujours attendre la prochaine sortie et retirer leur argent en fonction de la racine de stockage du contrat incluse dans cette sortie. Par conséquent, même si leur bloc de retrait est contesté, les utilisateurs n'ont pas à subir de longues latences car ils peuvent utiliser la sortie suivante.

Cependant, tout cela n'est valable que si l'utilisateur agit rapidement. Dans la plupart des cas, l'utilisateur peut encore subir une latence de plusieurs jours. Cela peut être attribué au processus de retrait dans la pile OP, qui comprend principalement les trois étapes suivantes :

Initier un retrait sur L2 (initiateWithdrawal).
Sur L1, prouver le retrait (proveWithdrawalTransaction), la preuve inclut les sorties du retrait.
Attendre une semaine pour que la preuve de latence soit mûre, puis finaliser le retrait (finalizeWithdrawalTransaction).

La clé est que, de la preuve de retrait à la finalisation du retrait, l'utilisateur doit attendre une semaine. Si Alice prouve son retrait sur la sortie B et qu'il y a contestation, elle peut envoyer une autre preuve pour la sortie C et finaliser le retrait une semaine plus tard. Dans ce cas, Alice ne subira qu'une latence entre les sorties B et C.

Par conséquent, les utilisateurs qui n'ont pas conscience de poser des questions ou de répondre tardivement peuvent subir jusqu'à 9 jours supplémentaires de latence de retrait.

De plus, OPFP a également un vecteur d'attaque de latence supplémentaire, à savoir chaque sortie est continuellement remise en question. Dans ce cas, l'utilisateur ne peut contourner la latence en prouvant sur la sortie suivante, ce qui entraîne une latence de l'ensemble du protocole. OPFP répond à cela en demandant aux participants de faire face à chaque niveau de stakeMarge binaire, où le montant de la Marge augmente de manière exponentielle, comme le montre le graphique ci-dessous.

Montant de la Marge OPFP | Source: Optimism Document

En d'autres termes, plus le temps de latence mis en doute dans OPFP est long, plus le coût de Marge nécessaire sera élevé, car l'exigence de Marge est en hausse exponentielle, ce qui réduit l'incitation à mener des attaques de latence au fil du temps. De plus, étant donné que les sorties dans OPFP peuvent être soumises à tout moment, il est difficile pour un attaquant d'estimer les ressources nécessaires pour mener une attaque de latence. La Marge initiale est fixée à 0.08 ETH, tandis que le total de la Marge à soumettre lors d'un doute complet atteint environ 700 ETH.

En résumé, OPFP laisse la durée de latence aux décisions des utilisateurs dans le cas d'une seule remise en question et utilise des exigences de marge exponentielle pour compenser les attaques de latence causées par des remises en question continues. Cependant, OPFP est facilement vulnérable aux attaques de Sybil. Dans OPFP, si l'attaquant a plus de fonds que le défenseur, une attaque de Sybil peut se produire.

Dans OPFP, il peut exister les attaques de vecteur Sybil suivantes, toutes pouvant entraîner le vol de fonds des utilisateurs :

L'attaquant crée plusieurs doutes, ce qui fait que le défenseur utilise tous ses fonds pour Marge et les frais de gaz.
Les attaquants soumettent continuellement des sorties incorrectes, forçant les défenseurs à réagir jusqu'à ce qu'ils épuisent leurs fonds en Marge et frais de Gas.

Cela est possible dans OPFP car tout au long du processus de contestation, le montant total de la Marge requis par l'attaquant et le défenseur est presque identique, et les ressources utilisées par le défenseur (telles que les frais de gaz ou la puissance de calcul) ne sont pas significativement inférieures à celles de l'attaquant.

Cependant, cela ne signifie pas que les fonds des utilisateurs sur le Mainnet OP actuel sont en danger. OPFP est toujours en phase 1, et le comité de sécurité a le pouvoir de corriger tout résultat inapproprié. Ainsi, même en cas d'attaque de ce type, le comité de sécurité peut intervenir pour protéger les fonds des utilisateurs sur le pont du Mainnet OP.

Cependant, pour faire passer OPFP à la phase 2, Optimism doit modifier le mécanisme pour s'assurer que les défenseurs ont un avantage plus important par rapport aux attaquants. Optimism prépare le jeu de contestation V2 pour résoudre ce problème, plus de détails seront présentés dans la section 4 "Améliorations réalisables".

4) Preuve de panne Kroma ZK (Kroma ZKFP)

Kroma est une L2 basée sur la pile OP. Avant l'introduction d'OPFP, elle a lancé en septembre 2023 un système ZK sans permission sur son Mainnet. Kroma ZKFP présente des caractéristiques similaires à celles d'OPFP, mais se distingue par l'utilisation de la génération de preuves ZK au niveau des blocs et l'utilisation de la décomposition plutôt que de la bifurcation, ce qui réduit considérablement le nombre d'interactions nécessaires lors du processus de contestation. Les principales caractéristiques de Kroma ZKFP sont les suivantes:

Réduire le nombre d'interactions grâce à ZK et la décomposition

Kroma ZKFP permet aux participants de trouver les points de divergence en quatre interactions. Lorsqu'une contestation est lancée, Kroma ZKFP traite la contestation sur 1 800 blocs, de la sortie précédente à la sortie actuelle. Contrairement à la méthode de dichotomie où la plage est divisée en deux, dans la méthode de décomposition, le proposant et le contestataire divisent la plage en N parties. Le processus est le suivant :

Après que chaque participant a soumis deux transactions, ils identifieront le bloc sur lequel ils divergent. Les contestataires peuvent générer une preuve de défaillance ZK pour montrer que les affirmations du proposant sont fausses. Dans Kroma ZKFP, le délai de bipartition est fixé à 1 heure, tandis que le délai de génération de preuve ZK est de 8 heures.

À travers le mécanisme d'incitation pour réaliser la Décentralisation des validateurs

BoLD et OPFP offrent tous deux des incitations aux gagnants des contestations, mais ne fournissent pas d'incitation concrète aux soumissionnaires de sortie. En réalité, toute personne souhaitant retirer des fonds peut soumettre une sortie et devenir un validateurs. Cependant, pour les utilisateurs souhaitant retirer des fonds, il n'est pas pratique de gérer le client validateurs eux-mêmes et quelqu'un doit soumettre régulièrement des sorties pour maintenir l'activité. Étant donné que c'est une tâche intensive en ressources, il faut payer des frais de gaz pour soumettre des sorties et exploiter le client validateurs. Par conséquent, sans incitation appropriée, seules quelques personnes peuvent participer en tant que validateurs, ce qui peut entraîner une centralisation et un manque de réponse en cas de panne.

Pour ce faire, Kroma a modifié le OP Stack pour allouer la moitié des frais de gaz générés off-chain aux validateurs soumettant des sorties. De plus, Kroma prévoit de transitionner ce mécanisme de récompense vers son token natif Jeton KRO après le TGE, et vise à introduire un système de validateurs similaire à DPoS, permettant aux utilisateurs ordinaires de contribuer à la sécurité et à l'activité de la chaîne sans exécuter leur propre client.

Dans Kroma, le montant de Marge est actuellement fixé à 0.2 ETH pour s'assurer qu'il est supérieur au coût de génération de preuves ZK et de bifurcation. Cette Marge sera transformée en stake de KRO dans le système de validateurs futur.

Système de défi 1 contre 1 concurrent

Pour garantir une distribution équitable et cohérente des incitations, Kroma fixe l'intervalle de soumission à une heure et sélectionne aléatoirement des validateurs dans la collection de validateurs préenregistrés comme proposants. Cela empêche une concurrence excessive entraînant le gaspillage de frais de gaz et évite le monopole des récompenses par les constructeurs de blocs qui ont le pouvoir de trier les transactions.

En raison de ce mécanisme, Kroma ZKFP fonctionne avec un système de validation 1 contre 1 en parallèle. Lorsque les validateurs sélectionnés au hasard soumettent une sortie, n'importe qui peut lancer un défi, qui se déroule uniquement entre le soumetteur de la sortie et le challenger. Plusieurs défis peuvent avoir lieu simultanément, et le premier challenger à soumettre une preuve ZK valide gagnera le défi.

Un délai strict signifie que même les contestataires malveillants qui tentent une attaque de latence doivent effectuer toutes les bifurcations et générer toutes les preuves dans les 10 heures. De plus, étant donné que les contestataires sont obligés de finaliser toutes les opérations en 6 jours (hors période de garde d'un jour), il est impossible de mener une attaque de latence classique sur Kroma.

Cependant, si les fonds de l'attaquant dépassent ceux du défenseur, Kroma ZKFP reste vulnérable aux attaques Sybil, semblables à OPFP. Dans Kroma ZKFP, un scénario d'attaque Sybil pourrait se présenter comme suit :

Les attaquants remettent continuellement en question les sorties valides jusqu'à ce que les fonds du soumetteur de sortie soient épuisés, moment où les attaquants soumettent une preuve de connaissance nulle (ZK) pour gagner le défi.

Comme OPFP, Kroma ZKFP supprimera les sorties correspondantes après un succès d'interrogation. Ainsi, en cas d'une telle attaque, les sorties concernées peuvent être supprimées, entraînant une latence de retrait atteignant 1 heure pour les utilisateurs. Si l'attaque se poursuit, tous les validateurs honnêtes pourraient être épuisés en fonds, ce qui entraînerait une confirmation finale erronée des sorties, permettant ainsi à l'attaquant de dérober les fonds des utilisateurs.

De plus, Kroma ZKFP est toujours à l'étape 0, son système de preuve n'est pas encore parfait, pour les raisons suivantes :

Le point de départ de la bifurcation est basé sur la sortie de la dernière soumission, et non sur la sortie confirmée finale.

Dans OPFP, le point de départ de la bifurcation est généralement la sortie de confirmation finale d'il y a environ une semaine. Cependant, dans Kroma ZKFP, le point de départ est la sortie soumise la plus récente, soumise environ une heure auparavant, et le processus de bifurcation se déroule sur 1 800 Blocs.

Cela pourrait permettre aux contestataires de remporter un défi dans le cas où une sortie précédente serait supprimée en raison de la contestation. Dans ce cas, la bifurcation sera basée sur les informations de sortie précédemment soumises par le contestataire, et s'ils manipulent malicieusement ces informations, ils pourraient remporter la contestation.

Est-ce que chaque validateurs remet en question les données de lot correctes, cela n'a pas été vérifié.

Bien que Kroma ZKFP utilise ZK pour garantir qu'en l'absence de faille dans le circuit ZK, il est impossible de confirmer finalement un transfert d'état erroné, Kroma ZKFP ne vérifie pas si la génération de la preuve ZK est basée sur les bonnes données en lots. Cela signifie que même si certaines transactions sont exclues ou que des transactions incorrectes sont incluses dans le lot, la preuve ZK peut toujours passer la vérification.

Par conséquent, il est possible de gagner des doutes en utilisant des preuves ZK basées sur des données erronées, et si les transactions de retrait des utilisateurs sont exclues du lot, leurs retraits pourraient être retardés.

Cependant, dans la pratique, le comité de sécurité peut intervenir pour retirer les résultats des doutes erronés ou supprimer les sorties invalides, de sorte que ces vecteurs d'attaque ne compromettent pas les fonds des utilisateurs de Kroma Mainnet. Cependant, pour atteindre la phase 2, Kroma ZKFP doit mettre en place des mécanismes de défense contre ces vulnérabilités. Kroma a proposé des améliorations pour ces problèmes, qui seront détaillées dans la section 4, "Améliorations réalisables".

3.4 Vecteur d'attaque #2：L1 审查

Comme mentionné précédemment, Rollup hérite de la sécurité d'Ethereum. Cela signifie que si la sécurité d'Ethereum est compromise, Rollup sera également affecté.

Les deux scénarios dans lesquels la situation d'Ethereum pourrait affecter la sécurité de Rollup sont les suivants：

Les validateurs de l'ETH foff examinent les transactions Rollup fraud proof Que se passerait-il si les vérificateurs ou les constructeurs de la chaîne Ethereum s'associaient pour soumettre une racine de sortie malveillante dans Optimistic Rollup, tout en examinant toutes les transactions liées à la preuve de fraude ? Les contestations pourraient ne pas être résolues dans les délais impartis, les sorties pourraient être confirmées et les fonds des utilisateurs pourraient être en danger. Ceci est appelé une faible vérification. Dans le cas d'Optimistic Rollup, si cette vérification se poursuit pendant une période définie (généralement 7 jours), les fonds de l'utilisateur pourraient être en danger.
**Ethereum subit une attaque de 51 %, ce qui entraîne la révision de toutes les transactions de preuve de fraude. **Cette situation implique deux voies d'attaque possibles :

Tout d'abord, une entité peut obtenir plus de 2/3 des mises totales d'Éther, ce qui lui permettra de confirmer les Blocs à sa guise. Dans ce cas, un attaquant peut examiner les transactions de preuve de fraude, voire générer ces transactions à volonté.
La deuxième méthode implique un acteur possédant plus d'un tiers du total des enjeux de ETH dans le bloc, qui mène une attaque "furtive". Cela est décrit dans la recherche sur la "attaque de censure non attribuable aux protocoles de couche 2 basés sur la preuve de fraude". Dans ce cas, l'attaquant détenant un tiers des enjeux de ETH dans le bloc peut empêcher la confirmation de tout bloc qu'il n'aime pas. S'ils continuent à voter pour les blocs réguliers tout en gardant le silence sur les blocs contenant une preuve de fraude, ils pourraient confirmer une racine de sortie malveillante, volant ainsi des fonds du Optimistic Rollup. Cela s'appelle une attaque de censure non attribuable aux protocoles de couche 2 basés sur la preuve de fraude. Cette attaque est plus difficile à détecter que le simple fait de détenir plus de deux tiers des enjeux et de contrôler tous les blocs de ETH.

Il est difficile de faire face à ces attaques basées sur l'examen au niveau de la couche Rollup, car elles se produisent au niveau de la couche protocole de l'ETH et nécessitent des améliorations de l'ETH lui-même. Cependant, Rollup peut adopter certaines stratégies pendant cette période.

3.5 Solution #2: Latence de retrait de 7 jours et récupération d'attaque de 51% semi-automatisée

Pour faire face à ces Vecteur d'attaque, Optimistic Rollup met actuellement en œuvre une latence de retrait de 7 jours. Cette période de 7 jours a été initialement proposée par Vitalik sur la base de l'idée que 7 jours suffisent pour contrer les attaques de révision.

Analysons si la période de contestation de 7 jours d'Optimistic Rollup est suffisante pour résister aux attaques de censure, en tenant compte de deux types d'attaques de censure : attaque de censure faible et attaque de censure forte.

Pour le premier type de faible vérification, nous pouvons utiliser des calculs de probabilité pour voir si 7 jours donnent à Optimistic Rollup la capacité de résister à une attaque de vérification. Cela implique de calculer la probabilité qu'une contestation réussisse lorsqu'un validateur remet en question une transaction Rollup suspecte.

Ici, deux facteurs doivent être pris en compte :

Pour contester avec succès dans les 7 jours, plusieurs transactions doivent être réussies.

Dans la plupart des protocoles, une contestation ne réussira pas si seulement une transaction d'un participant honnête est incluse dans la semaine. Par conséquent, nous devons calculer la probabilité que toutes les transactions nécessaires pour soumettre une preuve de fraude dans les 7 jours soient incluses.

Il est nécessaire de supposer raisonnablement le taux de validateurs impliqués dans l'examen. Actuellement, la plupart des constructeurs de blocs de la chaîne ETH (connus pour être centralisés) ne sont pas soumis à une vérification, étant donné le faible pourcentage des validateurs individuels sur la chaîne ETH, il est pratiquement impossible que la grande majorité (par exemple, 99,9 %) des validateurs collaborent à une vérification.

(Examen des principaux constructeurs de Blocs ETH | Source: Tweet de Justin Drake)

En tenant compte de ces deux points, si nous supposons que 99,5% des validateurs (ce qui reste une hypothèse extrême) participent à l'examen et calculons la probabilité que les participants honnêtes réussissent à envoyer avec succès de 30 à 40 transactions sur la plateforme d'échange nécessitant un protocole de contestation comme BoLD ou OPFP, alors dans tous les cas, la probabilité de succès est proche de 100%. De plus, avec l'apparition de futures solutions telles que l'inclusion de listes ou de multiples proposants concurrents tels que BRAID, APS + FOCIL, la capacité à résister à l'examen pourrait être encore renforcée, réduisant ainsi le risque pour la plateforme d'échange Gate.io de perdre les fonds des utilisateurs en raison d'un examen insuffisant.

Dans ce cas, est-ce que 7 jours sont suffisants sous une surveillance rigoureuse ? Comme mentionné précédemment, une attaque de 51% ne peut être résolue que par une bifurcation sociale. Les attaques de censure non attribuables sont particulièrement difficiles à détecter et ne peuvent pas être prévenues par des solutions conçues pour une censure faible, telles que l'inclusion dans une liste.

Une proposition consiste à développer un outil de récupération d'attaque de 51% semi-automatisé dans le logiciel client, basé sur la structure proposée par Vitalik. Les chercheurs d'ETH ont ensuite développé cette solution de détection d'examen en deux étapes :

Le client léger surveille le pool de mémoire et vérifie si le temps pendant lequel certaines transactions n'ont pas été incluses dans le Bloc est trop long.
Si une transaction spécifique reste dans le pool de mémoire pendant un jour sans être incluse dans un bloc, cela déclenche le bouton "Acceptez-vous de faire un fork social ?", permettant à la communauté de lancer un hard fork basé sur ce consensus.

Supposons que cet outil détecte une attaque de 51 %, la prochaine étape consistera à bifurquer socialement vers un nouvel hors-chaîne, rendant ainsi les fonds de l'attaquant invalides.

Dans ce cas, les fonds affectés par une attaque à 51% doivent rester verrouillés jusqu'à ce que le fork social soit terminé. Une situation similaire s'est produite pendant le Hard Fork de The DAO, où les fonds du Hacker ont été bloqués dans un sous-DAO pendant 27 jours, jusqu'à ce qu'ils puissent être retirés. Pendant cette période, la communauté Ethereum a réussi à effectuer avec succès un Hard Fork, empêchant ainsi le Hacker de retirer les fonds (pour plus de détails, veuillez consulter le post de Vitalik sur Reddit).

En d'autres termes, même en cas d'attaque de 51 %, les fonds doivent rester verrouillés jusqu'à ce qu'il y ait un fork social. Dans ce cas, la période de retrait de 7 jours dans l'Optimistic Rollup fait office de tampon. Si aucun fork social n'a lieu pendant cette semaine, les fonds des utilisateurs dans l'Optimistic Rollup pourraient être volés, retirés vers une plateforme d'échange centralisée, ou mélangés via Tornado Cash, les rendant pratiquement impossibles à récupérer pour les utilisateurs après un fork social.

En résumé, bien que la période de retrait de 7 jours dans Optimistic Rollup ait été initialement conçue pour faire face à une faible vérification, il est peu probable qu'une faible vérification se produise réellement, et ce délai de 7 jours agit comme un tampon dans le cas où une vérification plus stricte nécessite une bifurcation sociale.

De ce point de vue, certains critiquent le fait que OPFP ait réduit ce délai à 3,5 jours, le rendant ainsi plus vulnérable aux attaques d'examen approfondi. Cependant, cette critique est infondée. Étant donné qu'Optimism est toujours à la phase 1, les gardiens disposent d'une période tampon suffisante pour vérifier l'exactitude de la racine de l'état, et les retraits ne peuvent être effectués qu'après la fin de la période de garde supplémentaire de 3,5 jours. Par conséquent, même en cas d'attaque d'examen approfondi, l'attaquant devrait attendre 7 jours avant de pouvoir effectuer des retraits. De plus, l'attaquant doit également examiner toutes les transactions liées aux doutes pendant une semaine complète pour réussir, car les gardiens doivent également être examinés pour éviter qu'ils ne mettent fin à la confirmation de sorties malveillantes.

Cependant, la clé est que l'ETH doit s'assurer qu'il peut traiter le fork social dans les 7 jours. Cela signifie que les outils de détection des attaques à 51% doivent être prêts et nécessitent une recherche et une simulation approfondies pour déterminer si le fork social peut être mis en œuvre dans les 7 jours. Ce n'est que dans ce cas que la latence de retrait de 7 jours dans Optimistic Rollup peut être considérée comme une garantie valide.

3.6 Vecteur d'attaque #3：利用fraud proof系统中的漏洞

La plupart des protocoles sont remis en question en demandant aux participants de trouver un point spécifique (instruction ou bloc) sur lequel ils ne sont pas d'accord, puis de générer une preuve indiquant que l'affirmation d'un autre participant est incorrecte. La machine virtuelle utilisée pour générer cette preuve est appelée machine virtuelle de preuve de fraude (Fraud Proof VM), et le logiciel utilisé sur cette machine virtuelle pour générer la preuve est appelé programme. Chaque protocole utilise une machine virtuelle de preuve de fraude et un programme différents, comme indiqué ci-dessous:

Chaque système de preuve de fraude vise à prouver que le résultat d'une exécution spécifique de l'EVM est correct hors chaîne. Mais que se passe-t-il s'il y a des vulnérabilités dans ce système (qu'il s'agisse d'une machine virtuelle ou d'un programme) ?

Ce problème peut être exploré à travers le Vecteur d'attaque découvert par Yoav Weiss dans OVM. En raison d'une vulnérabilité dans la fonctionnalité de Rollback de OVM, une attaque est rendue possible, mais la création d'une transaction frauduleuse est essentielle à la mise en œuvre de l'attaque. Une transaction frauduleuse est une transaction qui est traitée normalement sur Rollup, mais qui donne des résultats différents lorsqu'elle est contestée à l'aide du système de fraude proofMachine virtuelle et de programme. Comme le système de fraude proof devrait produire les mêmes résultats que l'EVM, la capacité de créer des transactions frauduleuses signifie qu'il y a une vulnérabilité dans le système de fraude proof.

Yoav a découvert plusieurs failles dans le système de fraude de l'OVM et est capable de simuler cette attaque en générant des transactions frauduleuses. Un exemple d'attaque simple qu'il a découvert est que dans le StateManager de l'OVM, les coûts en gas des opérations de stockage et de chargement (utilisées pour stocker et lire l'état) ont été enregistrés de manière incorrecte. Cela signifie que toute transaction qui stocke ou lit une valeur dans un contrat (presque toutes les transactions, sauf les simples transferts d'ETH) sera identifiée comme une transaction frauduleuse lors du processus de contestation, même si elle s'exécute correctement sur Rollup.

En résumé, si des vulnérabilités existent dans le système, des modifications d'état correctement exécutées peuvent être incorrectement marquées comme invalides pendant la période de contestation, ce qui peut entraîner le marquage incorrect des sorties soumises par les participants honnêtes.

C'est également l'une des raisons pour lesquelles OP Mainnet a récemment transformé son système de preuve de défaillance d'un mode sans autorisation à un mode réservé aux participants autorisés uniquement. Après l'application de OPFP sur Mainnet, des audits de sécurité ont révélé plusieurs vulnérabilités dans le système de preuve de fraude (Cannon et op-program) ainsi que dans plusieurs protocoles de jeu contestés. Afin d'empêcher l'exploitation du système, Optimism a annoncé le 17 août qu'il passerait à un système de permissions.

Bien sûr, l'exploitation des vulnérabilités de la Machine virtuelle dans les Rollup de phase 0 ou de phase 1 pourrait ne pas avoir un impact majeur, car le comité de sécurité peut intervenir à tout moment pour corriger les résultats contestés. C'est un point de vue précédemment avancé par OP Labs. En fait, OP Labs a partagé sur le forum Optimism son cadre d'audit, qui décrit les normes pour lesquelles un audit externe est nécessaire.

(Cadre d'audit OP Labs | Source: Forum Optimism)

Dans ce cadre, la situation récente relève du quatrième quadrant : "preuve de panne en phase auxiliaire". Bien que ces situations soient liées à la sécurité de la chaîne, elles n'affectent pas directement les fonds des utilisateurs et ne sont donc pas incluses dans le champ d'application de l'audit. Cela signifie que même en cas d'exploitation des failles, le comité de sécurité peut toujours corriger les résultats.

Cependant, une fois que les vulnérabilités ont été identifiées, il est nécessaire de résoudre ces problèmes. Optimism a corrigé ces problèmes lors de sa mise à niveau du réseau Granite, permettant au OP Mainnet de revenir à la phase 1.

D'autre part, les vulnérabilités du système peuvent être fatales dans le Rollup de la phase 2. Dans la phase 2, le comité de sécurité ne peut intervenir que dans les cas de vulnérabilités pouvant être prouvées hors chaîne. Étant donné qu'il est presque impossible de prouver hors chaîne que les résultats de contestation sont erronés en raison de vulnérabilités du système, les fonds des utilisateurs peuvent être exposés à des risques en cas de vulnérabilités dans le Rollup de la phase 2.

3.7 Solution #3: Preuve multiple

Pour prévenir de tels problèmes, il est essentiel de procéder à une vérification complète avant la mise en production du code. Cependant, les fraud proofMachine virtuelle et les programmes sont des systèmes logiciels complexes, plus le système est complexe, plus il y a de risques de vulnérabilités. Par conséquent, même après une vérification rigoureuse, des vulnérabilités peuvent encore apparaître. Nous devons explorer des stratégies supplémentaires en dehors de l'audit.

Une méthode consiste à utiliser plusieurs systèmes de preuve au sein du même système. Lors du processus de contestation, le système ne se contente pas de générer une preuve de fraude à l'aide d'un seul système, mais peut utiliser simultanément différentes machines virtuelles et programmes pour générer plusieurs preuves de fraude, puis comparer les résultats. Cela permet de créer un système sécurisé même en cas de vulnérabilité.

Par exemple, imaginez un système de preuve multiple utilisant à la fois le Cannon d'Optimism et la Machine virtuelle de preuve de défaillance ZK asterisc (utilisant Risc-V). En cas de doute, les situations suivantes se produiront :

Si une erreur est détectée en sortie, le contestataire génère une contestation et lance une méthode de bifurcation.
Une fois que le Bloc de divergence est trouvé par la méthode de la dichotomie, deux sous-jeux se produiront simultanément :

Le sous-jeu de Cannon utilisant la méthode traditionnelle OPFP. Utilisation d'Asterisc pour générer un sous-jeu de preuve de panne ZK.

Après la fin de deux jeux, les deux types de preuves de fraude seront vérifiés.

Si les deux preuves sont validées, le contestataire l'emporte ; si les deux preuves sont invalides, le contestataire échoue. Cependant, si l'une est valide tandis que l'autre ne l'est pas, cela indique qu'il y a eu une faille inattendue dans le processus de génération de la preuve, soit au niveau de la Machine virtuelle ou du programme.

Dans ce cas, des entités telles que le comité de sécurité interviendront pour ajuster les résultats contestés. Cela garantit que le système reste sans faille tout en respectant la condition selon laquelle le comité de sécurité n'intervient que dans les cas de vulnérabilités prouvées en dehors de la chaîne (off-chain).

Il s'agit là d'un effort continu pour permettre à l'Optimisme d'atteindre la phase 2. Pour appuyer ce point, le jeu de controverses OPFP implique la modularité, permettant la mise en œuvre libre de plusieurs systèmes de preuve de fraude, et définissant des interfaces minimales pour soutenir cela.

4. Améliorations faisables

Dans les chapitres précédents, nous avons discuté de la conception du protocole Optimistic Rollup et des vulnérabilités potentielles dans son processus de remise en question et de vérification des fraudes. Ce chapitre examinera les problèmes et les solutions de chaque protocole, ainsi que le système de preuve de fraude et les perspectives futures d'Optimistic Rollup.

4.1 Espaces d'amélioration de chaque protocole

1) Arbitrum BoLD

BoLD has a robust economic protocol, as it limits the maximum protocol latency to one week and ensures effective defense against Sybil attacks before the attacker's funds exceed 6.5 times that of the defender. However, BoLD has two significant issues:

Le rapport de ressources de 6,5 fois est trop faible pour donner un avantage significatif à la défense.
Le dépôt pour la déclaration de la racine est de 3 600 ETH, ce montant est trop élevé.

Le premier problème peut être résolu en utilisant la technologie ZK. BoLD divise les contestations en plusieurs niveaux pour réduire les ressources nécessaires au calcul des engagements historiques. En utilisant ZK, cela peut être réduit à un seul niveau.

Ce concept est similaire à la proposition BoLD++ de Gabriel de Cartesi. Lorsque les objections sont classées en plusieurs niveaux, l'augmentation du ratio des ressources entraînera une hausse exponentielle de l'ampleur des dépôts au niveau le plus élevé. Cependant, lorsqu'un seul niveau est utilisé, il est plus facile d'augmenter le ratio des ressources, rendant le protocole plus résistant aux attaques Sybil.

Le deuxième problème, nécessitant un dépôt de 3 600 ETH, est encore plus difficile à résoudre. La taille du dépôt BoLD n'est pas seulement destinée à lutter contre les attaques Sybil, mais aussi à dissuader les attaques de latence. La taille du dépôt est une fonction de la TVL (valeur totale verrouillée), même avec l'utilisation de ZK, il ne peut pas être considérablement réduit. Pour résoudre ce problème, BoLD met en œuvre un mécanisme de dépôt de pool minier qui permet à plusieurs participants de partager le dépôt.

2）Cartesi Dave

Dave a efficacement fait face à l'attaque Sybil grâce à sa structure de tournoi, mais comme mentionné précédemment, il est vulnérable aux attaques de latence. Le temps de latence maximum est une fonction qui comprend le nombre de déclarations malveillantes NA et le nombre de niveaux de mise L, calculé selon la formule : Td = 7 x [log2(1 + NA)]L(天数)

Si NA = 7 et L = 3, le protocole pourrait être confronté à une latence pouvant aller jusqu'à quatre mois, ce qui entraînerait des inconvénients et des pertes évidents pour les utilisateurs, car les retraits seront soumis à une latence.

ZK peut aider à atténuer ce problème. En fixant le niveau L à 1 (comme dans la ligne BoLD++), le temps de latence maximal peut être réduit à : 01928374656574839201 Td = 7 x log2(1 + NA)(天数)

Selon les rapports, Cartesi utilise la technologie ZK de RISC Zero pour cette amélioration. Cependant, il y a encore des inquiétudes quant à savoir si cette amélioration est suffisante pour prévenir complètement les attaques de latence. Si NA = 7, le protocole pourrait encore être confronté à une latence supplémentaire pouvant aller jusqu'à deux semaines, alors que le coût pour l'attaquant ne serait que de 7 ETH, plus les frais de gaz et les coûts d'engagement historiques hors chaîne. Pour les chaînes de grande valeur avec des positions de verrouillées, cette punition pourrait ne pas être suffisante pour dissuader les attaques de latence.

(Dave: Mécanisme de sous-interrogation avec style BoLD | Source: L2Beat Medium)

Il est proposé que Dave adopte un mécanisme de questionnement en style BoLD, avec des compétitions de 8 participants par tour au lieu de duels 1 contre 1, similaires à un tournoi traditionnel. Dans ce cas, la formule de calcul de la latence est la suivante :

Td = 7 x log8(1 + NA)(天数)

Dans cette structure, l'attaquant doit fournir au moins 64 ETH de marge pour remettre en question la latence pendant plus de deux semaines, le total de la marge requise étant de 64 ETH, et il doit supporter des coûts importants hors chaîne et hors chaîne.

Cependant, l'inconvénient de cette méthode est qu'elle affaiblit l'avantage du défenseur face à une attaque Sybil. Bien que BoLD offre une structure où le défenseur a un avantage N fois supérieur à l'attaquant, Dave a créé une situation où le défenseur bénéficie d'un avantage exponentiellement supérieur à celui de l'attaquant.

En résumé, Dave peut limiter efficacement les attaques de latence en utilisant la preuve de fraude ZK. Bien que des structures similaires à BoLD puissent améliorer la capacité de résistance aux attaques de latence, cela pourrait entraîner un avantage pour les défenseurs face à une attaque Sybil.

3）Optimism Fault Proof (OPFP)

Le principal inconvénient d'OPFP est qu'il est vulnérable aux attaques de Sybil, car le coût pour l'attaquant et le défenseur est le même. OP Labs a proposé une solution à ce problème dans le jeu controversé V2.

Contrairement à l'OPFP d'origine, qui soumet une marge à chaque bifurcation, le V2 du jeu contesté ne demande que les participants soumettent une marge au début de la bifurcation. De plus, le jeu contesté V2 introduit une bifurcation, permettant aux participants de soumettre plusieurs demandes en même temps au point de bifurcation, ce qui réduit généralement le nombre d'interactions.

Déclaration de branche dans le jeu contesté V2 | Source: Optimism Specs GitHub

Dans les précédents OPFP, les vecteurs d'attaque Sybil comprennent :

Créez un grand nombre de doutes pour épuiser les fonds de Marge et de frais de gaz des défenseurs.
Continuellement soumettre des sorties fausses pour forcer le défenseur à répondre et épuiser ses ressources.

L'introduction de la déclaration de branche résout les deux problèmes de vecteur. Tout d'abord, les participants honnêtes n'ont pas besoin de soumettre des Marge supplémentaires lors du processus de bifurcation, alors que les détracteurs malveillants doivent soumettre des dépôts pour chaque nouveau défi qu'ils créent. Si le montant des dépôts est correctement défini, la création d'un grand nombre de défis devient insoutenable pour l'attaquant.

Deuxièmement, dans le jeu litigieux V2, le montant de la Marge de niveau supérieur est plus élevé, donc le coût de soumettre constamment des fausses sorties est plus élevé pour l'attaquant que pour le défenseur.

Par conséquent, OPFP peut efficacement faire face aux attaques Sybil en introduisant des déclarations de branche dans le jeu contesté V2.

4) Kroma ZK Fault Proof (Kroma ZKFP)

Kroma ZKFP est confronté à la vulnérabilité aux attaques Sybil et à un système de preuve imparfait, ces deux défis. Pour progresser vers la phase 1, Kroma ZKFP doit résoudre les deux problèmes suivants :

Le point de départ de la méthode de dichotomie est basé sur la sortie soumise en dernier lieu, plutôt que sur la sortie définitive.
Les validateurs n'ont pas vérifié si les doutes sur l'exactitude des données en lots étaient fondés.

Le projet Kroma prévoit de passer de Halo2 zkEVM de Scroll à Succinct SP1 zkVM pour résoudre ces deux problèmes et avancer vers la phase 1.

Kroma prévoit de modifier son processus de contestation pour l'aligner sur l'interface de jeu controversée d'Optimism. Cet ajustement est décrit en détail dans la norme de Kroma et permettra de déplacer le point de départ de la bissection vers la dernière sortie déterminée il y a une semaine, résolvant ainsi le premier problème.

Pour le deuxième problème, Kroma utilisera une dérivation sans confiance basée sur ZK. Voici comment cela fonctionne :

(Utilisation de la dérivation sans confiance de ZK | Source: Lightscale Notion)

Imaginez que nous voulions prouver que le L2 Bloc T spécifique est correctement exécuté. Avant de générer une preuve ZK, nous devons vérifier si les données de transaction du Bloc T sont correctement construites à partir de données en vrac L1.

Ici, Kroma a l'intention de vérifier via ZK si les données en vrac ont été extraites correctement de L1. Si les données sont simplement obtenues via un RPC externe de confiance en dehors du programme ZK, il est impossible de confirmer si les données en vrac ont été altérées. Il est possible de vérifier si le programme a accédé au bon bloc et a extrait les données en vrac en générant une preuve ZK de connectivité Blochash, ces blocs allant de Bloc O (la source L1 de Bloc T L2) à Bloc C (le bloc L1 lors de la création de la contestation). Par conséquent, tant qu'il n'y a pas de conflit de hachage, la connectivité des blocs L1 peut prouver que le contestataire a construit le bloc L2 à partir des bonnes données en vrac.

Kroma plans to use ZK to verify the accuracy of batch data, which can check the Blochash connectivity from L1 Bloc O to C. If the challenger constructs L2 Bloc T based on erroneous batch data, the L1 Blochash they reference will be different from the L1 Bloc containing the correct batch and will not connect to Bloc C. Without hash conflicts, this method can be used to verify the correct batch data during the challenge process.

Avec ces améliorations, Kroma ZKFP pourra passer à l'étape 1. Cependant, pour atteindre l'étape 2, Kroma a besoin de solutions supplémentaires pour prévenir les attaques Sybil, notamment en remplaçant le protocole de mise en doute par un protocole All-vs-All et en redessinant le mécanisme de Marge.

4.2. Résumé

5. L'avenir de la preuve de fraude

5.1. Phase 2 Rollup - Vos fonds sont en sécurité

Comme mentionné précédemment, les rollups optimistes évoluent vers la phase 2. Arbitrum s'efforce de mettre en œuvre la phase 2 sur la base de BoLD. Le déploiement de BoLD a déjà été annoncé sur le forum de gouvernance et a reçu un soutien important. Il est actuellement déployé sur le testnet. Sans découverte de problèmes de sécurité majeurs, Arbitrum devrait probablement mettre en œuvre la phase 2 via BoLD d'ici la fin de cette année.

Optimism travaille également à la réalisation de la phase 2. Pour que OP Mainnet atteigne la phase 2, il est nécessaire de terminer le jeu de contestation V2 et d'avoir plusieurs mécanismes de preuve pour soutenir la preuve multiple. Bien que les normes soient encore en cours d'amélioration, le jeu de contestation V2 résout efficacement les faiblesses de l'OPFP existant, offrant une protection solide contre les attaques Sybil et le rapprochant ainsi de la phase 2. De plus, diverses équipes, notamment OP Labs, Succinct, Kroma et Kakarot, travaillent activement au développement de preuves multiples, investissant des ressources de R&D importantes pour créer une diversité de moyens de preuve OP Stack. Par conséquent, sauf problème majeur, Optimism devrait également franchir la phase 2 au cours de la première moitié de l'année prochaine.

Le passage de ces deux Rollups à la phase 2 pourrait avoir un impact majeur sur l'écosystème Rollup. Arbitrum et Optimism ont chacun leur propre cadre Rollup, à savoir Arbitrum Orbit et OP Stack. Leur transition vers la phase 2 signifie que tous les Rollups utilisant ces cadres peuvent également passer à la phase 2.

Par conséquent, à partir de la fin de cette année jusqu'à l'année prochaine, les principaux Rollup avec une base d'utilisateurs massive, tels que Arbitrum, OP Mainnet et Base, devraient passer à la phase 2, héritant de la sécurité complète d'Ethereum. Cela pourrait probablement apaiser les critiques selon lesquelles "Rollup n'est qu'une signature multiple" ou "Rollup peut prendre votre argent à tout moment".

5.2. ZK fraud proof est l'avenir

La plupart des protocoles discutés peuvent bénéficier de la mise en œuvre de la preuve de fraude ZK. Par exemple, l'application de ZK à Arbitrum BoLD peut améliorer le taux de ressources, le rendant plus résistant aux attaques Sybil, tandis que Cartesi Dave peut le rendre moins vulnérable aux attaques de latence. OPFP investit également dans le développement de ZK pour soutenir les systèmes de preuve multiples, ce qui pourrait réduire le montant de la marge et renforcer la sécurité du protocole.

Il convient de noter que la preuve de fraude ZK ne signifie pas seulement une réduction des interactions entre les validateurs. Moins d'interactions signifie une réduction significative des ressources nécessaires aux validateurs, ce qui permet de réduire la marge de goutte, permettant ainsi à davantage de participants de rejoindre le protocole. De plus, cela réduit également la latence maximale possible et améliore la sécurité globale du protocole.

De cette manière, ZK fraud proof joue un rôle crucial dans la sécurité et la Décentralisation de l'Optimistic Rollup.

5.3. Comment se comporte le ZK Rollup ? La preuve de fraude sera-t-elle affaiblie ?

À ce stade, certains lecteurs pourraient se demander : Si la preuve de fraude et le mécanisme de contestation sont si complexes, les Rollups ZK seraient-ils un meilleur choix ? Dans une certaine mesure, c'est vrai. Dans les rollups ZK, atteindre la phase 2 ne nécessite pas de prendre en compte des facteurs économiques complexes, les fonds des utilisateurs ne sont pas exposés au risque de vol lors d'un événement d'audit L1, et les utilisateurs peuvent retirer leurs fonds en quelques heures.

La transition des rollups optimistes vers les rollups ZK pourrait être plus rapide que prévu. Cela est dû à l'amélioration rapide des principaux inconvénients des rollups ZK - des coûts de génération de preuves élevés et un temps considérable. Récemment, Succinct Labs a lancé OP Succinct, une version ZK basée sur OP Stack, offrant un cadre facile pour démarrer les rollups ZK.

OP Succinct Introduction | Source: Succinct Blog

Cependant, il y a encore quelques facteurs à considérer. Tout d'abord, les coûts. Dans OP Succinct, le coût de génération d'une preuve de bloc est d'environ 0,005 à 0,01 $, et le coût mensuel d'exécution du vérificateur est estimé entre 6 480 et 12 960 $. Si le volume de transactions (TPS) de la chaîne est élevé, ces coûts pourraient augmenter davantage.

（Coût de référence de chaque preuve de réseau | Source: Blog Succinct）

Par exemple, sur le réseau de base OP Succinct, le coût moyen de génération de preuve par Bloc est d'environ 0,62 $. En fonction de ce chiffre, les coûts mensuels atteindront 803 520 $. Il s'agit de coûts supplémentaires que les Rollups Optimistes n'ont pas, même si les coûts de fonctionnement des Rollups ZK restent toujours plus élevés que ceux des Rollups Optimistes, même si les coûts de ZK Goutte.

Le deuxième point à considérer est l'impact sur la Décentralisation. Dans les ZK Rollups, les validateurs doivent exécuter des preuves, ce qui est plus difficile et plus coûteux que l'exécution de programmes de preuve de fraude dans les Optimistic Rollups. De plus, en raison du temps de génération des preuves plus lent dans le système ZK, les utilisateurs ne peuvent pas vérifier les transactions en temps réel. Bien que des normes matérielles plus élevées puissent améliorer la vitesse de génération des preuves pour correspondre à la vitesse d'exécution des transactions, cela signifie que l'exécution des preuves nécessite un environnement informatique de haute qualité. Idéalement, n'importe qui devrait pouvoir exécuter un Nœud pour assurer la sécurité de la chaîne, mais le ZK n'a pas encore atteint ce niveau.

Enfin, les Rollups ZK sont basés sur des mathématiques et une cryptographie hautement complexes, cette complexité dépasse la portée de la preuve de fraude et remet en question le protocole. Par conséquent, avant de pouvoir être utilisé en production en toute sécurité, le système ZK doit être largement testé.

Arbitrum poursuit un protocole mixte combinant les méthodes ZK et Optimistic comme objectif final. Ce protocole fonctionne principalement comme un Optimistic Rollup, ne générant des preuves ZK que lorsqu'une retrait rapide est nécessaire. Cela est très utile pour les scénarios nécessitant un rééquilibrage rapide des fonds entre les chaînes (par exemple, plateforme d'échange ou bridges cross-chain), et contribue également à l'interopérabilité entre les chaînes.

En conclusion, la méthode Optimistic Rollup semble actuellement être efficace, tout en utilisant ZK comme solution hybride. Cependant, à mesure que les coûts de génération de preuves ZK et la vitesse continuent de s'améliorer, il est possible que davantage de Rollups Optimistic envisagent sérieusement de passer à ZK à l'avenir.

5.4. La preuve de fraude s'applique-t-elle uniquement à Rollup ?

Nous avons étudié les rollups optimistes d'Ethereum et leur mécanisme de preuve de fraude. Quels sont les autres cas d'utilisation de cette preuve de fraude ?

Encore stakeprotocole fraud proof peut être activement utilisé dans le protocole de mise en jeu. Prenons Eigenlayer comme exemple, c'est un service de mise en jeu représentatif sur la chaîne ETH.

Eigenlayer est un service qui permet de garantir la sécurité de la location de Ethereum en staking. Dans Eigenlayer, les opérateurs peuvent déposer de l'ETH ou du LST des utilisateurs en fonction des contrats de délégation internes à Eigenlayer, et participer à la validation en choisissant plusieurs AVS (services de validation actifs). Grâce à Eigenlayer, les protocoles peuvent facilement construire des AVS et réduire les coûts initiaux d'introduction des validateurs.

Comme n'importe quelle autre blockchain, AVS récompense les opérateurs qui ont réussi à vérifier et les punit lorsqu'ils se livrent à des comportements malveillants. C'est là que la preuve de fraude peut être utilisée dans le processus de slashing.

Exemple de slashing AVS | Source :Eigenlayer GitHub**

Prenons l'exemple du bridge AVS. La condition préalable du bridge AVS est de transférer correctement les fonds des utilisateurs vers la chaîne cible, et tout opérateur manipulateur malveillant doit être soumis à des sanctions. En cas de manipulation de ce type, les contestataires qui découvrent un comportement inapproprié peuvent créer une contestation avec une preuve de fraude dans le contrat de résolution des litiges, alléguant que l'opérateur a mal agi lors de l'opération du bridge. Si la preuve de fraude est considérée comme valide, AVS peut invoquer le contrat de sanction dans Eigenlayer pour suspendre toutes les récompenses de l'opérateur.

Bien que cette fonction de slashing ne soit pas encore implémentée dans Eigenlayer, ils ont récemment annoncé le modèle de sécurité partagé, prévoyant de l'inclure dans la prochaine version. Cela permettra à la preuve de fraude d'être utilisée pour le slashing.

Couche de disponibilité des données** fraud proof peut également être utilisé au niveau de la disponibilité des données (DA). Un exemple représentatif est la preuve de fraude proposée et mise en œuvre par Celestia. Celestia a une technologie qui permet au nœud léger de vérifier si les données sont stockées correctement en fonction de l'échantillonnage de la disponibilité des données. Examinons de plus près ce concept.

Un light client devrait être en mesure de vérifier si un bloc a été approuvé par la majorité des validateurs (plus de 67%) sans télécharger l'ensemble des données de la chaîne de blocs. Cependant, il est difficile pour un light client de vérifier la signature de chaque validateur pour chaque bloc, et cela devient presque impossible avec l'augmentation du nombre de validateurs.

Dans ce domaine, Celestia a proposé un concept intéressant. Dans Celestia, même si la plupart des validateurs sont malveillants, il a proposé une méthode qui permet à un seul nœud complet honnête d'informer le client léger de refuser les blocs défectueux. Ce seul nœud complet honnête peut garantir son 'honnêteté' grâce à une preuve de fraude.

Dans Celestia, il existe deux types de preuves de fraude :

Preuve de fraude de transition d'état

Tout d'abord, le fonctionnement de la preuve de fraude des données est le suivant : Celestia permet aux validateurs légers de vérifier si les validateurs détiennent les bonnes données sans télécharger directement toutes les données dans le bloc. Pour ce faire, Celestia utilise une technique appelée échantillonnage de disponibilité des données (Data Availability Sampling, DAS).

Échantillonnage de la disponibilité des données de Celestia | Source : Fichier Celestia

Les validateurs de Celestia structurent les données de transaction en une matrice k x k, puis l'élargissent en une matrice 2k x 2k à l'aide de la technique appelée codage 2D Reed-Solomon. Ils calculent ensuite un total de 4k Merkle Root pour chaque ligne et chaque colonne, puis incluent les résultats du hachage ultérieur de ces Merkle Root dans l'en-tête du bloc et les propagent.

Seule avec les informations de Merkle Root dans l'en-tête de bloc, le nœud léger peut vérifier si les validateurs de Celestia détiennent les données correctes. Le nœud léger demande des données à des points aléatoires dans une matrice 2k x 2k, tout en obtenant les Merkle Root correspondants des lignes et des colonnes auprès des validateurs. Si ces données peuvent être vérifiées avec les valeurs dans l'en-tête de bloc, alors on peut faire confiance à ces validateurs pour détenir les bonnes données.

Cependant, un facteur important à prendre en compte est apparu : que se passerait-il si les validateurs exécutaient malicieusement le codage Reed-Solomon ? Celestia résout ce problème en mettant en œuvre un mécanisme appelé « preuve de fraude de mauvais codage » (fraud proof). Si un Full Node de Celestia découvre une erreur de codage lors du processus de récupération du bloc, il génère une preuve de fraude contenant la hauteur du bloc, la partie de codage incorrecte et la preuve de défaillance, et la propage à un light node. Le light node vérifie cette preuve pour confirmer que les données sont effectivement incorrectement codées, ce qui arrête l'utilisation des données erronées.

De plus, Celestia a également proposé un mécanisme de preuve de fraude pour la transition d'état.

L'architecture de Celestia Bloc | Source : Contribution DAO Blog

La structure Bloc de Celestia comprend les données de suivi des transactions à des intervalles de temps donnés. Cela permet aux Nœuds complets de construire facilement des preuves de fraude, tandis que les Nœuds légers peuvent détecter les transitions d'état incorrectes sans exécuter l'ensemble du Bloc. Cependant, en raison de problèmes de complexité, ce mécanisme n'a pas encore été implémenté sur Celestia Mainnet.

En résumé, la preuve de fraude dans la couche de disponibilité des données peut filtrer les données incorrectes et les transitions d'état sans dépendre du Consensus.

Apprentissage automatique L'intelligence artificielle et la blockchain sont devenus des sujets populaires en 2024, et ont fait l'objet de nombreuses recherches dans ce domaine. L'un des aspects les plus remarquables est la combinaison de la blockchain et de l'apprentissage automatique.

L'application de l'apprentissage automatique à la blockchain s'explique principalement par les raisons suivantes：

Fiabilité des données : La chaîne de Bloc gère les données de manière décentralisée, toutes les transactions sont enregistrées de manière transparente et ouverte. Si un modèle d'apprentissage automatique apprend à partir des données de la chaîne de Bloc, la source des données est fiable, ce qui réduit la possibilité de falsification.
Transparence et vérifiabilité du modèle : Lorsque le modèle d'apprentissage automatique est exécuté hors chaîne, les mises à jour et les résultats du modèle sont enregistrés hors chaîne, ce qui les rend vérifiables. Cela empêche toute manipulation ou partialité des résultats qui pourraient survenir dans un environnement centralisé.

Les principaux facteurs ici sont de vérifier si les modèles d'apprentissage automatique ont été correctement formés. Cependant, les calculs liés à l'apprentissage automatique sont très intensifs, ce qui rend presque impossible de les exécuter entièrement dans l'environnement Bloc. Ainsi, des cadres tels que opML et zkML ont émergé pour valider efficacement la formation des modèles d'apprentissage automatique dans l'environnement Bloc. opML adopte une approche optimiste pour la formation des modèles, enregistrant les résultats dans le hors-chaine Bloc, et corrige les erreurs via un mécanisme de contestation.

Examinons de plus près la méthode proposée par ORA, un projet qui fournit une infrastructure d'intelligence artificielle sur la blockchain. Le processus de défi d'opML est très similaire au processus de défi de rollup et se compose des trois éléments clés suivants :

Machine virtuelle de preuve de fraude（Fraud Proof VM） : Cette machine virtuelle effectue des inférences d'apprentissage automatique et fonctionne de manière similaire au WAVM d'Arbitrum ou au Cannon d'Optimism.
opML Smart Contract : Ce contrat vérifie la preuve de fraude, agissant de manière similaire au contrat MIPS.sol d'Optimism.
Jeu de validation : Les validateurs qui remettent en question interagissent avec le serveur par dichotomie pour identifier une seule étape erronée dans la machine virtuelle, puis génèrent une preuve de fraude pour cette étape et la soumettent au contrat opML.

Le jeu de vérification sur ORA opML | Source: Fichier ORA

Grâce à ce mécanisme de preuve de fraude, OPML utilise la sécurité et la crédibilité de la blockchain pour fournir un environnement rentable pour l'entraînement et la validation des modèles d'apprentissage automatique.

6. Conclusion

Optimistic Rollup met actuellement beaucoup d'efforts pour améliorer la preuve de fraude et remettre en question le protocole, afin d'hériter d'une plus grande sécurité d'Ethereum et de créer une chaîne moins fiable. Arbitrum devrait atteindre la phase 2 d'ici la fin de l'année grâce à BoLD, tandis qu'Optimism travaille également vers la phase 2, en s'appuyant sur le jeu de contestation V2 et un mécanisme multi-preuves. L'année prochaine, les utilisateurs d'Optimistic Rollup pourront interagir avec le réseau avec une plus grande sécurité, sans craindre que le Rollup ne puisse voler leurs fonds. De plus, Vitalik a mentionné dans son blog que le nombre de Rollups de phase 1 et supérieure devrait également augmenter.

Cependant, chaque protocole a encore de la place pour s'améliorer, et de nombreux aspects peuvent être renforcés par des preuves de fraude ZK. Kroma a déjà progressé sur cette base pour son protocole, tandis que d'autres protocoles tels que Arbitrum, Optimism et Cartesi peuvent également utiliser des preuves de fraude ZK pour rester plus sûrs et plus décentralisés.

Dans le domaine de la preuve de fraude, non seulement Rollup mais aussi d'autres protocoles investissent beaucoup de ressources dans le développement. En combinant la preuve de fraude avec ZK sous l'hypothèse de "un seul participant honnête", cela peut aider à construire une architecture de chaîne de Blocs à confiance minimale, dont l'impact finira par devenir une réalité tangible pour nous.

7. Références

(https://l2beat.com/scaling/summary)[L2Beat]

fraud proof战争 | Luca Donnoh at L2Beat

Fichier Arbitrum

Optimism 文件

Spécifications Optimism

无权限裁判的比赛 | Cartesi

Kroma 规格

Résolution rapide et peu coûteuse des différends en gras: (https://arxiv.org/abs/2404.10491)

BoLD 的经济学

Pourquoi le délai de défi pour Optimistic Rollup est-il de 7 jours ? | Kelvin Fichter chez OP Labs

fraud proof已崩溃 | Gabriel Coutinho de Paula at Cartesi

Voyage dans le temps optimiste | Yoav Weiss

Introduction sur le premier défi réussi concernant Kroma Mainnet: 关于 Kroma Mainnet首次成功质疑的介绍

Décryptage des progrès de la décentralisation de Baseline | OP Labs

Attaque de censure non attribuable sur les protocoles de couche 2 basés sur la preuve de fraude

Cadre d'audit OP Labs

Derivation sans confiance | Kroma

Présentation de OP Succinct：preuve de validité complète sur OP Stack | Succinct

Eigenlayer GitHub

Celestia 文件

Contribution DAO Blog

ORA 文件

Clause de non-responsabilité :

Cet article est repris de [research.2077], tous les droits d'auteur appartiennent aux auteurs originaux [sm-stack et BTC Penguin]. Si vous avez des objections à cette reproduction, veuillez contacter l'équipe de Gate Learn à l'adresse suivante : https://www.gate.io/questionnaire/3967. Ils traiteront rapidement votre demande.
Avertissement de non-responsabilité : Les opinions exprimées dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent pas des conseils en matière d'investissement.
L'équipe Gate Learn traduit des articles dans d'autres langues. Sauf indication contraire, la copie, la distribution ou la copie des articles traduits sont interdites.

ETH-1.32%

ARB-0.8%

OP-1.2%

CTSI-0.57%

Voir l'original

Récompense
J'aime
2
Partager

Commentaire

Aucun commentaire

Rubrique
#BTC#
98k publications
#GateioInto11#
63k publications
#ETH#
57k publications
4#ContentStar#
56k publications
5#BOME#
53k publications
6#SLERF#
46k publications
7#PIGCOIN#
44k publications
8#比特币#
43k publications
9#NADA#
39k publications
10#HotTopicDiscussion#
39k publications