Introduction :

Le scientifique américain en gestion Lawrence Peter a proposé autrefois la théorie du "tonneau", qui soutient que les performances globales d'un système sont limitées par sa partie la plus faible. En d'autres termes, la quantité d'eau qu'un tonneau peut contenir est déterminée par sa planche la plus courte. Bien que ce principe soit simple, il est souvent négligé. Dans le passé, les débats sur la sécurité de la couche 2 ont largement ignoré la priorité et l'importance des différents composants, se concentrant essentiellement sur la fiabilité de la transition d'état et les problèmes DA, mais négligeant les éléments de niveau inférieur et plus importants. De cette manière, toute la base théorique pourrait devenir intenable. Par conséquent, lorsque nous discutons d'un système multi-modules complexe, nous devons d'abord identifier quelle pièce est le "maillon faible". Inspirés par la théorie du tonneau, nous avons effectué une analyse du système et constaté qu'il existe des dépendances évidentes entre différents composants dans le modèle de sécurité de la couche 2 de Bitcoin/Ethereum, ou que certains composants sont plus fondamentaux et importants pour la sécurité que d'autres, pouvant être considérés comme "plus courts". À cet égard, nous pouvons initialement classer l'importance/la base de différents composants dans le modèle de sécurité de la couche 2 mainstream comme suit :

1. Que les droits de contrôle du pont contractuel/officiel soient raisonnablement dispersés (à quel point les droits de contrôle de la signature multiple sont centralisés)

2. Y a-t-il une fonction de retrait résistante à la censure (retrait forcé, trappe d'évacuation)

3. Le formulaire de sortie de couche de données DA est-il fiable? (Que les données DA soient publiées sur Bitcoin et Ethereum)

4. Que ce soit un système de preuve de fraude fiable/une preuve de validité est déployé sur Layer1 (Bitcoin L2 nécessite l'aide de BitVM)

Nous devrions absorber modérément les résultats de recherche de la communauté Ethereum sur la couche 2 et éviter le lysenkoïsme

Comparé au système hautement ordonné de couche 2 d’Ethereum, Bitcoin Layer 2 est comme un tout nouveau monde. Ce nouveau concept, qui a pris de plus en plus d’importance après l’engouement pour l’inscription, prend de l’ampleur, mais son écosystème devient de plus en plus chaotique. Du chaos, divers projets de la couche 2 ont poussé comme des champignons après une pluie. Bien qu’ils apportent de l’espoir à l’écosystème Bitcoin, ils dissimulent délibérément leurs propres risques de sécurité. Certaines personnes ont même menacé de « nier la couche 2 d’Ethereum et de suivre le chemin unique de l’écosystème Bitcoin », montrant une forte tendance à emprunter une voie extrémiste. Compte tenu des différences d’attributs fonctionnels entre Bitcoin et Ethereum, la couche 2 de Bitcoin est destinée à ne pas pouvoir s’aligner sur la couche 2 d’Ethereum dans les premiers stades, mais cela ne signifie pas que nous devrions nier complètement le bon sens industriel qui a longtemps été établi dans Ethereum et même dans l’industrie modulaire de la blockchain. (Reportez-vous à « l’incident de Lyssenko » dans lequel l’ancien biologiste soviétique Lyssenko a utilisé des questions idéologiques pour persécuter les partisans de la génétique occidentale). Au contraire, ces normes d’évaluation, qui ont été atteintes par des « prédécesseurs » au prix de grands efforts, ont déjà fait preuve d’une forte force de persuasion après avoir été largement reconnues. Il n’est certainement pas rationnel de nier délibérément la valeur de ces réalisations.

En construisant Bitcoin Layer 2, nous devrions pleinement réaliser l'importance de "apprendre de l'Occident et l'appliquer à l'Orient" et absorber et optimiser de manière appropriée les nombreuses conclusions de la communauté Ethereum. Mais en s'inspirant des perspectives en dehors de l'écosystème Bitcoin, nous devons être conscients des différences dans leurs points de départ, et finalement chercher un terrain d'entente tout en réservant les différences.

C'est un peu comme discuter des similitudes et des différences entre les "Occidentaux" et les "Orientaux". Que ce soit occidental ou oriental, le suffixe "-er (人)" exprime de nombreuses caractéristiques similaires, mais lorsqu'il correspond à différents préfixes tels que "Occidental" et "Oriental", les caractéristiques de subdivision seront différentes. Mais en dernière analyse, il y aura forcément un chevauchement entre les "Occidentaux" et les "Orientaux", ce qui signifie que beaucoup de choses qui s'appliquent aux Occidentaux s'appliquent également aux Orientaux. Beaucoup de choses qui s'appliquent à "Layer 2 Ethereum" s'appliquent également à "Layer 2 Bitcoin". Avant de distinguer les différences entre Bitcoin L2 et Ethereum L2, il peut être plus important et significatif de clarifier l'interopérabilité entre les deux.

En adhérant à l'objectif de "chercher des points communs tout en réservant les différences", l'auteur de cet article n'a pas l'intention de discuter de "ce qu'est Bitcoin Layer 2 et de ce qu'il n'est pas", car ce sujet est si controversé, même la communauté Ethereum n'a pas discuté de "ce qui est Ethereum Layer 2 et de ce qui n'est pas Layer 2" et n'a pas atteint un point de vue objectif et cohérent. Mais ce qui est certain, c'est que bien que différentes solutions techniques apportent des effets d'expansion à Bitcoin, elles présentent également différents risques de sécurité. Les hypothèses de confiance existant dans leurs modèles de sécurité seront le point central de cet article.

Comment comprendre les critères de sécurité et d'évaluation de la couche 2

En fait, la sécurité de la couche 2 n'est pas un nouveau point de discussion. Même le mot sécurité est un concept composite qui inclut plusieurs attributs subdivisés. Auparavant, le fondateur d'EigenLayer avait simplement subdivisé la "sécurité" en quatre éléments : "irréversibilité des transactions (résistance à la réorganisation), résistance à la censure, fiabilité de la libération de données/DA et validité de la transition d'état."

(Le fondateur d'EigenLayer a déjà exprimé son point de vue sur la manière dont le schéma de vérification/couche souveraine côté client peut hériter de la sécurité du réseau principal Bitcoin) L2BEAT et Ethereum Community OG ont proposé un modèle d'évaluation des risques de la couche 2 plus systématique. Bien sûr, ces conclusions visent la couche 2 des contrats intelligents, plutôt que la couche 2 non liée aux contrats intelligents tels que le rollup souverain et la vérification côté client. Bien que cela ne soit pas à 100% adapté à Bitcoin L2, il contient toujours de nombreuses conclusions dignes de reconnaissance, et la plupart de ses points de vue ont été largement reconnus dans la communauté occidentale. Cela nous permet également d'évaluer objectivement les risques des différents L2 Bitcoin.

(Vitalik a déjà dit que puisque la solution Rollup ne peut pas atteindre la perfection théorique lors de son lancement initial, elle doit utiliser certains moyens auxiliaires pour améliorer la sécurité, et ces moyens auxiliaires sont appelés "training wheels" et introduiront des hypothèses de confiance. Ces moyens auxiliaires sont appelés "training wheels" et introduiront des hypothèses de confiance. Les hypothèses de confiance sont des risques.)

Alors, d'où viennent les risques de sécurité ? Étant donné la situation actuelle, qu'il s'agisse d'Éther Layer 2 ou de Bitcoin Layer 2, beaucoup d'entre eux s'appuient sur des nœuds centralisés pour agir en tant que séquenceurs, ou un "comité" sous la forme d'une chaîne latérale composée d'un petit nombre de nœuds. Si ces ordonnanceurs/comités centralisés ne sont pas restreints, ils peuvent voler les actifs des utilisateurs et s'enfuir à tout moment. Ils peuvent refuser les demandes de transaction des utilisateurs, provoquant le gel et l'inutilité des actifs. Cela concerne l'efficacité et la résistance à la censure des transitions d'état mentionnées par le fondateur d'EigenLayer précédemment. En même temps, puisque Éther Layer 2 s'appuie sur des contrats sur la chaîne ETH pour la vérification des transitions d'état et la vérification du comportement de dépôt et de retrait, si le contrôleur de contrat (en fait, le Layer 2 officiel) peut rapidement mettre à jour la logique du contrat, ajouter des segments de code malveillants (par exemple, permettre à une adresse spécifiée de transférer tous les jetons bloqués sur le contrat de dépôt et de retrait L1-L2), vous pouvez directement voler les actifs sous garde. Cela est attribué au "problème d'allocation de multi-signature de contrat", et le problème d'allocation de multi-signature s'applique également à Bitcoin Layer 2. Parce que Bitcoin Layer 2 s'appuie souvent sur le "pont notarial" et nécessite que plusieurs nœuds publient des demandes de chaîne croisée par le biais de multi-signatures, Bitcoin Layer 2 a également le problème de comment distribuer raisonnablement les multi-signatures. Nous pouvons même le considérer comme les "roues d'entraînement" les plus basiques sur Bitcoin Layer 2.

En outre, la question de la DA est extrêmement importante. Si Layer2 ne télécharge pas de données vers Layer1, mais choisit des lieux de diffusion de DA peu fiables, si cette couche DA hors chaîne (communément appelée comité de disponibilité des données DAC) collabore et refuse de diffuser les dernières données de transaction au monde extérieur, une attaque de rétention de données se produira. Cela entraînera le réseau à devenir obsolète et pourrait empêcher les utilisateurs de retirer des fonds en toute fluidité.

L2BEAT a résumé les problèmes ci-dessus et a résumé plusieurs éléments clés du modèle de sécurité Layer2 :

1. Vérification de l'état/prouver si le système est fiable (Validation de l'état)

2. Que ce soit la méthode de publication des données DA est fiable (Disponibilité des données)

3. Si le réseau de couche 2 rejette délibérément votre transaction ou s'arrête, pouvez-vous forcer le retrait des actifs de la couche 2 (échec du séquenceur, échec du proposant)

4. En ce qui concerne les contrats liés à la couche 2 - le contrôle du pont inter-chaînes officiel est-il suffisamment décentralisé ? Si le pouvoir est relativement centralisé, en cas d'« agissements malveillants des initiés », les utilisateurs disposent-ils de suffisamment de temps pour réagir en cas d'urgence ? (Fenêtre de sortie)

("Tableau d'affichage des facteurs de risque" défini pour différents projets Layer 2 sur L2BEAT)

Quoi qu'il en soit, lorsque nous analysons les risques de sécurité de la couche 2, nous discutons en réalité du nombre de scénarios présents dans le réseau de la couche 2 qui pourraient causer des dommages aux actifs des utilisateurs, et de la capacité du système de la couche 2 à limiter efficacement ces situations dangereuses grâce à la conception des mécanismes. Si certains comportements malveillants ne peuvent pas être éliminés, quelle quantité de "confiance" devons-nous introduire, combien d'individus dans un groupe doivent être dignes de confiance, et combien de "roues de formation" devons-nous utiliser. Nous analyserons ci-dessous les facteurs de risque présents dans le modèle général de la couche 2 Ethereum/Bitcoin Layer 2. (Les objets discutés dans cet article n'incluent pas les "canaux d'état" ou les "canaux de paiement", ni les protocoles d'index inscription, car ils sont spéciaux. Et nous tenterons d'explorer quels facteurs sont plus fondamentaux, de niveau inférieur et plus importants dans le modèle de sécurité de la couche 2. Ces lacunes plus fondamentales seront des risques de confiance qui méritent davantage notre attention que d'autres lacunes.)

L'effet de baril de Layer 2 - quels sont ses inconvénients?

La planche la plus courte - les droits de gestion du pont contractuel/officiel

Ici, nous pourrions aussi bien utiliser l'effet du "baril" pour analyser les problèmes de sécurité de la couche 2. Il est facile de voir que la planche la plus courte est la "mise à niveau du contrat" mentionnée ci-dessus (principalement pour la couche 2 d'Ethereum), ou encore, les "droits de gestion du pont inter-chaînes officiel" (applicables à la fois à Bitcoin et à la couche 2 d'Ethereum).

Pour Ethereum Layer 2, tant que les responsables de la couche 2 peuvent rapidement mettre à niveau les contrats sur la chaîne de couche 1, théoriquement, ils peuvent voler les jetons verrouillés dans l’adresse de dépôt et de retrait officielle du pont de couche 2, quelle que soit la fiabilité de sa couche de disponibilité des données (DA) ou de son système de preuve. On peut dire que l’autorité de contrôle du contrat de pont concerne la sécurité de l’ensemble du système. C’est la partie la plus fondamentale et la plus critique de l’ensemble de la couche 2 et même de la pile modulaire de la blockchain. Si le composant/contrat de pont peut être mis à jour et itéré sous un contrôle multi-signatures, alors nous devons introduire une « hypothèse de confiance » ici, en supposant que le contrôleur du contrat/pont officiel de couche 2 ne fera pas le mal.

(Les retards de mise à niveau des contrats de différents projets Layer 2 sont marqués sur L2BEAT. La plupart des contrats L2 peuvent être mis à niveau immédiatement par le contrôleur. Si le contrôleur du contrat souhaite voler des actifs, ou si sa clé privée est volée par un pirate informatique, les actifs des utilisateurs hébergés par L2 doivent en souffrir)

Différent de Ethereum Layer 2, le pont de Bitcoin Layer 2 n'est pratiquement pas contrôlé par le contrat sur la couche 1, car Bitcoin ne prend pas en charge les contrats intelligents. Relativement parlant, tout le flux de travail d'Ethereum Layer 2 dépend fortement du contrat sur la couche 1, tandis que Bitcoin Layer 2 ne peut pas le faire.

(Schéma schématique de Starknet)

C'est un problème inévitable pour Bitcoin Layer 2. On peut dire qu'il a à la fois des avantages et des inconvénients. Actuellement, il semble que le “pont sans confiance” mis en œuvre par Ethereum Layer 2 reposant sur des contrats ne peut pas être réalisé dans Bitcoin L2. Ce “pont sans confiance” nécessite le déploiement d'un contrat dédié sur la couche 1 et la coopération du système DA+ preuve de fraude/ZK. Il est essentiellement similaire au “pont optimiste” comme Orbiter ou aux ponts ZK tels que Polyhedra. L'opinion dominante dans l'industrie actuelle est que si vous ne tenez pas compte des bogues possibles en pratique et ne considérez que les modèles théoriques, le niveau de sécurité du pont optimiste et du pont ZK est essentiellement le plus élevé. Tant que le code du contrat ne contient pas de bogues ou ne peut pas être mis à niveau de manière malveillante, c'est essentiellement sans confiance.

(Le pont Optimistic Bridge n'a besoin que de s'assurer qu'1 des N observateurs est honnête pour garantir la sécurité. Le modèle de confiance est de 1/N)

Étant donné que Bitcoin Layer 2 ne peut pas déployer des composants de contrat sur la Layer 1 (nous ne parlons pas du Lightning Network ici), ses ponts officiels sont essentiellement des ponts de "notaire" composés d'un petit nombre de nœuds, ou des ponts de "multi-signature". La sécurité de ce type de pont dépend de la manière dont les signatures multi-signatures/seuil sont configurées, ce qui nécessite l'introduction d'hypothèses de confiance solides : en supposant que ces notaires ne collaborent pas ou que leurs clés privées ne soient pas volées.

À l’heure actuelle, la plupart des ponts basés sur des signatures notariées/seuils ne peuvent pas être comparés au « pont sans confiance » officiel de la couche 2 d’Ethereum en termes de sécurité (la prémisse est que le contrat de la couche 2 d’Ethereum ne sera pas mis à niveau de manière malveillante). De toute évidence, la sécurité des actifs de la garde du réseau Bitcoin Layer 2 sera limitée par la sécurité de son pont officiel, ou la décentralisation du pouvoir du pont multi-signatures, qui est sa première « roue auxiliaire ». Étant donné que les « droits de mise à niveau » des contrats liés au pont officiel de la couche 2 d’Ethereum sont souvent concentrés entre les mains de quelques contrôleurs multi-signatures, si les contrôleurs multi-signatures sont de connivence, il y aura également des problèmes avec le pont de couche 2 d’Ethereum, à moins que son contrat ne puisse pas être mis à niveau, ou qu’il ne soit soumis à une longue limite de délai (actuellement uniquement Degate et Fuel V1).

(Chaque fois que les contrats Degate sont mis à jour, ils réserveront une période d'échappatoire sécurisée de 30 jours pour les utilisateurs. Pendant cette période, tant que chacun découvre que la nouvelle version du code du contrat contient une logique malveillante, ils peuvent s'échapper en toute sécurité grâce à la fonction de retrait/échappatoire forcé)

En ce qui concerne la partie "pont officiel", les modèles de confiance de Layer 2 d'Ethereum et de Layer 2 de Bitcoin sont essentiellement les mêmes : vous devez faire confiance au fait que le contrôleur multi-signature ne va pas colluder pour faire le mal. Ce groupe de multi-signatures peut contrôler le pont officiel L2 et soit modifier sa logique de code, soit publier directement des demandes de retrait invalides. Le résultat final est le suivant : les actifs des utilisateurs peuvent être volés. La seule différence entre les deux est que tant que le contrat de Layer 2 d'Ethereum ne se met pas à niveau de manière malveillante/la fenêtre de mise à niveau est suffisamment longue, son pont officiel sera sans confiance, mais Layer 2 de Bitcoin ne peut de toute façon pas atteindre cet effet.

Le deuxième lien le plus court - retraits forcés résistants à la censure

Si nous supposons que la question des contrats multi-signatures/du contrôle du pont officiel mentionné ci-dessus peut être ignorée, c'est-à-dire qu'il n'y a pas de problème à ce niveau, alors le niveau suivant le plus important doit être la résistance à la censure des retraits. En ce qui concerne l'importance de la fonctionnalité de retrait résistant à la censure/fonction de sortie de secours, Vitalik a souligné dans son article "Différents types de couches 2" il y a quelques mois que la capacité de l'utilisateur à retirer avec succès des actifs de la couche 2 à la couche 1 est un indicateur de sécurité très important.

Si le séquenceur de la couche 2 continue de rejeter vos demandes de transaction, ou s'il échoue/est hors service pendant une longue période, vos actifs seront "gelés" et rien ne pourra être fait. Même si les systèmes de preuve DA et de preuve de fraude/ZK sont disponibles, sans solution anti-censure, une telle couche 2 n'est pas suffisamment sécurisée et vos actifs peuvent être détenus à tout moment. De plus, la solution Plasma, qui était autrefois très populaire dans l'écosystème Ethereum, permet à quiconque de retirer en toute sécurité des actifs vers la couche 1 en cas d'échec de la DA ou de l'échec de la preuve de fraude. À ce moment-là, l'ensemble du réseau de la couche 2 est essentiellement abandonné, mais il existe toujours un moyen pour que vos actifs s'échappent sans dommage. De toute évidence, la fonction de retrait résistant à la censure est plus basique et de niveau inférieur que les systèmes DA et de preuve.

(Dankrad de la Fondation Ethereum a déclaré que Plasma peut encore permettre aux actifs des utilisateurs d'être évacués en toute sécurité lorsque DA échoue/que les utilisateurs ne parviennent pas à synchroniser les dernières données)

Certains jetons Ethereum Layer 2, tels que Loopring et StarkEx, dYdX, Degate, etc., mettront en place une fonction d'activation de la cabine de retrait/évasion résistante à la censure sur Layer1. En prenant Starknet comme exemple, si la demande de retrait forcé soumise par l'utilisateur sur Layer 1 ne reçoit pas de réponse du séquenceur Layer 2 à la fin de la période de fenêtre de 7 jours, la fonction de demande de gel peut être appelée manuellement pour mettre L2 dans un état gelé et activer le mode cabine d'évasion. À ce moment-là, le séquenceur ne peut pas soumettre de données au contrat Rollup sur L1, et l'ensemble du Layer2 sera gelé pendant un an. Ensuite, les utilisateurs peuvent soumettre une preuve de Merkle pour prouver le statut de leurs actifs sur Layer 2 et retirer directement de l'argent sur Layer 1 (en fait, ils prennent leur propre montant égal de fonds de l'adresse de dépôt et de retrait du pont officiel).

De toute évidence, le mode de trappe de sortie ne peut être implémenté que sur une chaîne comme Ethereum qui prend en charge les contrats intelligents. Bitcoin ne peut pas exécuter une logique aussi complexe. En d'autres termes, la fonction de trappe de sortie est essentiellement un brevet d'Éther Layer 2. Bitcoin Layer 2 doit utiliser certains moyens auxiliaires supplémentaires pour imiter le chat et le tigre. Il s'agit de la deuxième “roue auxiliaire”. Cependant, il est beaucoup plus pratique de simplement déclarer une “demande de retrait forcé” que d'activer directement la trappe de sortie. La première ne nécessite que l'utilisateur soumette une transaction à l'adresse spécifiée sur la couche 1, et dans les données supplémentaires de la transaction, déclare les données qu'il souhaite soumettre à tous les nœuds Layer 2 (ce qui peut contourner directement le séquenceur et communiquer les demandes à d'autres nœuds Layer 2). Si le “retrait forcé” ne reçoit pas de réponse pendant longtemps, il est plus raisonnable que l'utilisateur déclenche le mode cabine de sortie.

(Reference: Quelle est l'importance des fonctions de retrait forcé et de cabine d'évasion pour la couche 2）

Actuellement, il existe déjà des équipes de la couche 2 de Bitcoin qui prévoient d'imiter la méthode de mise en œuvre des transactions forcées d'Arbitrum et de permettre aux utilisateurs d'émettre des déclarations de transaction forcée (enveloppes de transaction forcée) sur la chaîne Bitcoin. Sous cette solution, les utilisateurs peuvent contourner le séquenceur et "transmettre leur voix" directement à d'autres nœuds de la couche 2. Si le séquenceur rejette toujours la demande de l'utilisateur après avoir vu la déclaration de transaction forcée de l'utilisateur, cela sera remarqué par d'autres nœuds de la couche 2 et pourrait être puni.

Mais le problème est que la fonction de transaction forcée d'Arbitrum, bénéficiant de son système de preuve de fraude, peut punir les Séquenceurs/Proposants qui ont ignoré les transactions des utilisateurs. Cependant, Bitcoin Layer 2, qui est difficile à vérifier la preuve de fraude sur Layer 1, rencontrera certaines difficultés à cet égard. (Ne discutons pas de BitVM pour le moment) S'il s'agit d'une solution telle que Rollup souverain, où le niveau de sécurité n'est pas très différent de la vérification client, il nous sera difficile d'évaluer sérieusement sa fiabilité, et nous pourrions avoir besoin d'évaluer les détails de mise en œuvre de différents projets.

Bien sûr, étant donné que de nombreux Bitcoin Layer 2 fonctionnent actuellement sous une forme similaire à des side chains, il est équivalent de réaliser que le séquenceur décentralisé peut résoudre le problème de l'anti-censure dans une certaine mesure. Mais il ne s'agit là que d'un moyen auxiliaire efficace, certainement pas de la solution ultime.

PS : Certaines solutions actuelles de Layer 2, telles que Validium, etc., ne sont pas parfaites dans la conception du mécanisme de cabine d'évasion. Lorsqu'un séquenceur lance une attaque de rétention de données ou que DA n'est pas disponible, les utilisateurs ne peuvent pas retirer d'argent. Mais cela est dû à la conception imparfaite de la cabine d'évasion de Layer 2. Théoriquement, le retrait optimal de la trappe d'évacuation peut reposer uniquement sur des données historiques et n'a pas besoin de dépendre de la disponibilité de DA / de nouvelles données.

La troisième planche la plus courte : la fiabilité de la diffusion des données de la couche DA

Bien que DA soit appelée disponibilité des données, le terme fait en réalité référence à la publication de données. C'est simplement parce que Vitalik et Mustafa n'ont pas réfléchi attentivement lorsqu'ils ont initialement nommé ce concept que le nom DA/disponibilité des données est devenu inexact.

La publication des données, comme son nom l'indique, fait référence à la possibilité pour ceux qui en ont besoin de recevoir avec succès les derniers blocs/données de transaction/paramètres de transition d'état. Les données publiées sur différentes chaînes ont une fiabilité différente.

(Reference:Malentendu sur la disponibilité des données: DA = publication des données ≠ récupération des données historiques)

Il est généralement admis dans la communauté occidentale que les chaînes publiques établies telles que Bitcoin et Ethereum sont les couches DA les plus fiables. Si le trieur de Layer2 publie de nouvelles données sur Ethereum, toute personne exécutant le client Ethereum geth peut télécharger ces données et les synchroniser sans aucun obstacle. Cela est réalisé en exploitant l'ampleur du réseau Ethereum et la grande variété de sources de données publiques. Il convient de mentionner que Ethereum Rollup obligera le séquenceur à publier des données de transaction/paramètres de transition d'état sur Layer1, ce qui est garanti par le biais de preuves de validité/preuves de fraude.

Par exemple, une fois que le séquenceur de ZK Rollup a publié les données de transaction sur la couche 1, il déclenche la logique du contrat pour générer un hachage de données, et le contrat de validation doit confirmer que le certificat de validité soumis par le proposant a une relation correspondante avec le hachage de données. Cela équivaut à : confirmer que la preuve zk et la racine d’état soumises par le proposant sont associées aux données d’émission soumises par le séquenceur, c’est-à-dire New Stateroot=STF(Old Stateroot,Txdata). STF est la fonction de transition d’état. Cela permet de s’assurer que les données de transition d’état/DA sont téléchargées de force dans la chaîne. Si vous ne soumettez que le certificat stateroot et le certificat de validité, vous ne pourrez pas passer la vérification du contrat de validation. Quant à savoir si la publication des données DA ou le système de vérification des preuves est plus basique, la communauté Ethereum/Celestia a déjà eu une discussion complète. La conclusion générale est que la fiabilité de la couche DA est plus importante que l’exhaustivité du système de preuve de fraude et de validité. Par exemple, des solutions telles que Plasma, Validium et Optimium, où la couche DA se trouve sous la chaîne Ethereum et la couche de règlement sous la chaîne Ethereum, sont susceptibles de rencontrer des problèmes d’attaque par retenue de données, ce qui signifie que : Le séquenceur/proposant peut conspirer avec les nœuds de la couche DA sous la chaîne ETH pour mettre à jour la stateroot sur la couche 1, mais retiennent les paramètres d’entrée correspondant à la transition d’état et ne les envoient pas, ce qui rend impossible pour les étrangers de juger si la nouvelle racine d’état est correcte, et deviennent « aveugles » .

Si cela se produit, l'ensemble du réseau de couche 2 sera abandonné. Parce qu'à ce moment-là, vous n'avez aucune idée de ce qu'est devenu le grand livre de la couche 2. S'il s'agit de la couche 2 (Plasma et Optimium) basée sur la preuve de fraude, le trieur peut réécrire les données/actifs sous n'importe quel compte à sa guise ; s'il s'agit de la couche 2 (Validium) basée sur la preuve de validité, bien que le trieur ne puisse pas réécrire votre compte à sa guise, à ce moment-là, l'ensemble du réseau de couche 2 devient une boîte noire. Personne ne savait ce qui se passait à l'intérieur, et c'était pareil à être abandonné. Pour cette raison, les solutions orthodoxes de couche 2 dans l'écosystème Ethereum sont essentiellement des Rollup, tandis que Validium et Optimium ne sont souvent pas reconnus par la Fondation Ethereum.

(Reference: Preuve de retenue de données et de fraude : Pourquoi Plasma ne prend pas en charge les contrats intelligents）

Ainsi, la fiabilité de la couche DA/la disponibilité des paramètres de transition d'état est plus importante et fondamentale que l'exhaustivité du système de preuve de fraude/de preuve de validité. Pour Bitcoin Layer 2, en particulier la couche 2 basée sur le modèle de vérification client, même s'il n'y a pas de système de vérification de preuve de fraude/de preuve de validité sur la couche 1, tant que la couche DA fonctionne comme d'habitude, tout le monde peut encore savoir s'il y a une erreur dans le réseau L2. Actuellement, il est difficile de vérifier la preuve de fraude/de validité sur le réseau principal de Bitcoin (BitVM n'est pas discuté ici). Supposons d'abord que Bitcoin L2 n'a pas de système de vérification de preuve. Idéalement, si le trieur L2 fait vraiment le mal et publie un stateroot qui n'est pas lié aux données DA sur la couche de règlement/BTC, il ne peut toujours pas voler vraiment les actifs des utilisateurs car le stateroot/résultat de transition d'état qu'il soumet unilatéralement ne sera pas reconnu par les nœuds honnêtes, mais à la fin, cela pourrait juste être de l'auto-plaisir. (À ce moment-là, tant que les nœuds exécutés par les fournisseurs d'installations périphériques dans l'écosystème comme les échanges et les ponts inter-chaînes ne collaborent pas avec le séquenceur, le séquenceur ne peut pas rapidement réaliser les actifs volés en publiant des données erronées. Ensuite, tant qu'un nœud honnête découvre quelque chose d'anormal et lance une alerte à un moment critique, l'erreur peut être corrigée grâce au consensus social. Cependant, le coût du consensus social est très élevé en soi et ne peut pas prendre effet immédiatement)

S'il s'agit d'un modèle similaire à un side chain et que la plupart des nœuds complotent pour effectuer des changements d'état malveillants, les gens peuvent rapidement découvrir le problème. Tant que des installations tierces telles que des ponts inter-chaînes et des échanges ne reconnaissent pas les données erronées, les contrôleurs malveillants des chaînes Layer 2/side ne pourront pas encaisser avec succès. À moins qu'il ne parvienne à convaincre d'autres de faire du OTC directement sur la chaîne avec lui.

(Viatlik a souligné dans l'article que la vérification du client est la véritable base pour assurer la sécurité du réseau blockchain, Vérifiez par vous-même)

Il y a là un point très intéressant. En fait, la couche 2 d’Ethereum et la couche 2 de Bitcoin peuvent toutes deux réaliser une « vérification du client ». Cependant, sur la base de la « vérification du client », la couche 2 d’Ethereum s’appuie sur la couche 1 et le système de vérification de la preuve pour garantir la validité des transitions d’état et n’a fondamentalement pas à s’appuyer sur un consensus social (à condition qu’il existe un système mature de preuve de fraude/preuve de validité). La solution de « vérification du client » de Bitcoin Layer 2 repose souvent fortement sur le « consensus social » et entraînera des risques correspondants. (Pour Bitcoin Layer 2, ce risque de sécurité est fondamentalement contrôlable, mais il peut tout de même faire perdre des actifs à certaines personnes. Pour Ethereum Layer 2, parce que son pont officiel doit prouver la coopération du système, si le système de preuve n’est pas parfait, l’ordre Le serveur peut voler les actifs de l’utilisateur et s’enfuir sur L1. Bien sûr, les détails dépendent de la façon dont le composant de pont inter-chaînes est conçu). Ainsi, une couche 2 capable de mettre en œuvre un système de vérification de la preuve de la fraude et de la validité sur la couche 1 sera toujours bien meilleure qu’un simple modèle de « vérification du client ». PS : Étant donné que la plupart des couches 2 de Bitcoin qui utilisent des systèmes de preuve de fraude / de validité ne peuvent pas permettre à la couche 1 de participer directement au processus de vérification de la preuve, leur essence est toujours de traiter Bitcoin comme une couche DA, et le modèle de sécurité est équivalent à la « vérification du client » ». Théoriquement, la preuve de la fraude peut être vérifiée sur la chaîne Bitcoin via la solution BitVM sur la couche 1. Cependant, la mise en œuvre de cette solution est très difficile et rencontrera de grands défis. Étant donné que la communauté Ethereum a déjà beaucoup discuté du système de preuve et de vérification basé sur la couche 1, qui est déjà bien connu, cet article n’a pas l’intention d’entrer dans les détails du « système de preuve et de vérification basé sur la couche 1 ».

Conclusion

Après une analyse simple du modèle de baril, nous pouvons initialement tirer une conclusion : Dans le modèle de sécurité Layer 2 principal, selon le degré d'importance/niveau de base, il peut être trié comme suit :

1. Que les droits de contrôle du pont contractuel/officiel soient raisonnablement dispersés

2. S'il existe une fonction de retrait résistante à la censure

3. Que le formulaire de libération de données de la couche DA soit fiable

4. Que ce soit un système de preuve de fraude/validité fiable est déployé sur la couche 1

Bien sûr, nous n'avons pas analysé le Lightning Network/State Channel et l'écosystème ICP ckBTC, Inscription Index Protocol et d'autres solutions, car ils sont assez différents des solutions Rollup, Plasma, Validium ou de vérification de client typiques. En raison de contraintes de temps, il nous est difficile de procéder à une évaluation prudente de leur sécurité et de leurs facteurs de risque, mais compte tenu de leur importance, un travail d'évaluation pertinent sera effectué comme prévu à l'avenir. En même temps, il existe de sérieuses différences entre de nombreux parties prenantes de projets quant à savoir si l'Inscription Index Protocol devrait être considéré comme Layer 2. Cependant, indépendamment de la définition de Layer 2, de nouvelles choses telles que l'Inscription Index Protocol ont apporté suffisamment d'innovation technologique à l'écosystème Bitcoin. Et finiront par éclater avec une grande vitalité.

Avertissement：

1. Cet article est repris de [ 极客web3]. Tous les droits d'auteur appartiennent à l'auteur original [Faust & 雾月, web3 geek]. If there are objections to this reprint, please contact the Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.