Une couche 2 capable de mettre en œuvre un système de vérification de preuve de fraude/validité sur la couche 1 sera toujours bien meilleure qu’un simple modèle de « vérification client ».
Écrit par : Faust & Wuyue, geek web3
Conseiller : Kevin He (@0xKevinHe), vice-président de Xinhuo Technology
Introduction : Le scientifique américain en gestion Lawrence Peter a un jour proposé la « théorie du baril », selon laquelle la performance globale d’un système est limitée par sa partie la plus faible. En d’autres termes, la quantité d’eau qu’un baril peut contenir est déterminée par sa planche la plus courte. Bien que ce principe soit simple, il est souvent négligé. ** Les débats précédents sur la sécurité de la couche 2 ignoraient pour la plupart la priorité et l’importance des différents composants. Ils se concentraient essentiellement sur la fiabilité de la transition d’état et les problèmes de DA, mais ignoraient les éléments de niveau inférieur et plus importants. De cette façon, l’ensemble du fondement théorique n’est probablement même pas défendable. Par conséquent, lorsque nous discutons d’un système multi-modules complexe, nous devons d’abord déterminer quelle pièce est la « planche la plus courte ».
Inspirés par la théorie du baril, nous avons effectué une analyse du système et découvert qu’il existe des dépendances évidentes entre les différents composants du modèle de sécurité Bitcoin/Ethereum Layer 2, ou que certains composants sont plus sécurisés que d’autres. -appelé “plus court”.
À cet égard, nous pouvons initialement prioriser l’importance/la base des différents composants du modèle de sécurité principal de couche 2 comme suit :**
- L’autorité de contrôle du contrat/pont officiel est-elle raisonnablement dispersée (dans quelle mesure l’autorité de contrôle multi-signatures est-elle concentrée) ?
- Existe-t-il une fonction de retrait résistant à la censure (retrait forcé, trappe de secours)
- Si la couche DA/le formulaire de publication des données est fiable (que les données DA soient publiées sur Bitcoin ou Ethereum)
- Si un système fiable de preuve de fraude/de validité a été déployé sur la couche 1 (Bitcoin L2 nécessite BitVM)
Nous devrions modérément absorber les résultats de recherche de la couche 2 de la communauté Ethereum et éviter le lysenkoïsme
Comparé au système hautement ordonné Ethereum Layer 2, Bitcoin Layer 2 ressemble à un tout nouveau monde. Ce nouveau concept, devenu de plus en plus important après l’engouement pour les inscriptions, montre un élan croissant, mais son écosystème devient de plus en plus chaotique et chaotique. Du chaos, divers projets de couche 2 ont poussé comme des champignons après la pluie. Tout en apportant de l’espoir à l’écosystème Bitcoin, ils dissimulent délibérément leurs propres risques en matière de sécurité. Certains ont même menacé de « nier Ethereum Layer 2 et de suivre le chemin unique de l’écosystème Bitcoin ». Ils ont une forte tendance à emprunter une voie extrémiste.
Compte tenu des différences d’attributs fonctionnels entre Bitcoin et Ethereum, ** Bitcoin Layer 2 est destiné à ne pas pouvoir s’aligner sur Ethereum Layer 2 dans les premiers jours, mais cela ne signifie pas que nous devrions complètement nier qu’Ethereum et même l’industrie de la blockchain modulaire L’industrie a depuis longtemps eu le bon sens** pour tirer une conclusion finale (voir “l’incident Lyssenko” dans lequel l’ancien biologiste soviétique Lyssenko a utilisé des questions idéologiques pour persécuter les partisans occidentaux de la génétique).
Au contraire, ces normes d’évaluation, qui ont été obtenues par de grands efforts par les « prédécesseurs », ont déjà fait preuve d’un fort pouvoir 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. **
**Lors de la construction de Bitcoin Layer 2, nous devons pleinement comprendre l’importance de « apprendre de l’Occident et l’appliquer à l’Est » et absorber et optimiser de manière appropriée les nombreuses conclusions de la communauté Ethereum. Mais lorsque nous nous appuyons sur des perspectives extérieures à l’écosystème Bitcoin, nous devons être conscients des différences dans leurs points de départ et, en fin de compte, rechercher un terrain d’entente tout en réservant les différences. **
C’est comme discuter des similitudes et des différences entre les « Occidentaux » et les « Orientaux ». Qu’il soit occidental ou oriental, le suffixe « 人 » 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, et beaucoup de choses qui s’appliquent à « Ethereum Layer 2 », également s’applique à “Bitcoin Layer2”. **Avant de distinguer les différences entre Bitcoin L2 et Ethereum L2, il peut être plus important et plus significatif de clarifier l’interopérabilité entre les deux.
Adhérant à l’objectif de “rechercher un terrain d’entente tout en réservant les différences”, l’auteur de cet article n’a pas l’intention de discuter de “qu’est-ce que Bitcoin Layer 2 et ce qui ne l’est pas”, ** car ce sujet est trop controversé, même la communauté Ethereum a pas discuté de “qu’est-ce qu’Ethereum Layer 2”, lesquels ne sont pas la couche 2" et d’atteindre une vision objective et cohérente.
**Mais ce qui est certain, c’est que si différentes solutions techniques entraînent des effets d’expansion sur Bitcoin, elles comportent également des risques de sécurité différents. Les hypothèses de confiance existant dans leurs modèles de sécurité seront le sujet sur lequel cet article entend se concentrer. **
Comment comprendre les critères de sécurité et d’évaluation de Layer2
En fait, la sécurité de couche 2 n’est pas un nouveau sujet de discussion. Même le mot sécurité est un concept composite qui comprend de multiples attributs subdivisés.
Auparavant, le fondateur de **EigenLayer avait simplement subdivisé la « sécurité » en quatre éléments, dont « l’irréversibilité des transactions (anti-rollback), la résistance à la censure, la fiabilité de la publication des données/DA et la validité de la transition d’état ». **
(Le fondateur d’EigenLayer a un jour exprimé son point de vue sur la façon dont le système de vérification/de cumul souverain 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 relativement systématique de couche 2. Bien entendu, ces conclusions visent la couche 2 des contrats intelligents, plutôt que la couche 2 de contrats non intelligents typiques tels que le cumul souverain et la vérification du client.
**Bien que cela ne soit pas adapté à 100 % au Bitcoin L2, il contient néanmoins de nombreuses conclusions dignes de reconnaissance. La plupart de ses points de vue ont été largement reconnus dans la communauté occidentale, ** et cela facilite également notre évaluation objective des risques des différents Bitcoin. L2.
(Vitalik a dit un jour que parce que la solution Rollup ne peut pas atteindre la perfection théorique lors de son lancement précoce, elle doit utiliser des moyens auxiliaires pour améliorer la sécurité, et ces moyens auxiliaires sont appelés « roues d’entraînement » et introduiront des hypothèses de confiance. Ces hypothèses de confiance sont des risques. )
Alors d’où viennent les risques de sécurité ? Compte tenu de la situation actuelle, qu’il s’agisse d’Ethereum Layer 2 ou de Bitcoin Layer 2, beaucoup d’entre eux s’appuient sur des nœuds centralisés pour faire office de séquenceurs, ou sur un petit nombre de nœuds formant un « comité » sous la forme d’une side chain. être centralisé. Si le séquenceur/comité n’est pas restreint, il peut voler les actifs des utilisateurs et s’enfuir à tout moment. Il peut refuser les demandes de transaction des utilisateurs, provoquant le gel des actifs et les rendant inutilisables. **Cela implique l’efficacité de la transition étatique et la résistance à la censure mentionnées plus tôt par le fondateur d’EigenLayer. **
Dans le même temps, étant donné qu’Ethereum Layer2 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 Layer2 officiel) peut rapidement mettre à jour la logique du contrat, ajoutez des segments de code malveillant (par exemple , permettant à une adresse spécifiée de transférer tous les tokens verrouillés sur le contrat de dépôt et de retrait L1-L2), vous pouvez directement voler les actifs en garde.
**Cela est attribué au “problème de distribution multi-signatures du contrat”, et le problème de distribution multi-signatures s’applique également à Bitcoin Layer 2, ** car Bitcoin Layer 2 s’appuie souvent sur le “Notary Bridge” et nécessite la libération de plusieurs nœuds. Grâce à des requêtes multi-signatures inter-chaînes, Bitcoin Layer 2 a également le problème de savoir comment distribuer raisonnablement les multi-signatures. Nous pouvons même le considérer comme la « roue auxiliaire » la plus basique de Bitcoin Layer 2. **
**De plus, la question du DA est extrêmement importante. **Si Layer2 ne télécharge pas de données sur Layer1, mais choisit des lieux de publication DA peu fiables, si cette couche DA hors chaîne (communément appelée Comité de disponibilité des données DAC) est de connivence et refuse de divulguer les dernières données de transaction au monde extérieur, les attaques de rétention de données rendront le réseau obsolète et pourraient empêcher les utilisateurs de retirer des fonds en douceur.
L2BEAT a résumé les problèmes ci-dessus et a résumé plusieurs éléments essentiels du modèle de sécurité Layer2 :
- Validation d’État/Prouver si le système est fiable (Validation d’État)
- La méthode de publication des données DA est-elle fiable ? (Disponibilité des données)
- Si le réseau Layer2 rejette délibérément votre transaction/s’arrête, pouvez-vous forcer les actifs à se retirer de Layer2 (échec du séquenceur, échec du proposeur)
- Contrats liés à la couche 2 - si le contrôle du pont officiel entre chaînes est suffisamment décentralisé. Si le pouvoir est relativement concentré, les utilisateurs auront-ils suffisamment de temps pour réagir en cas de « vol de surveillance » (Fenêtre de sortie)
(“Affichage du facteur de risque” défini pour différents projets Layer2 sur L2BEAT)
Quoi qu’il en soit, lorsque nous analysons les risques de sécurité de couche 2, nous discutons en fait du nombre de scénarios existants dans le réseau de couche 2 qui peuvent causer des dommages aux actifs des utilisateurs, et si le système de couche 2 peut limiter efficacement ces situations dangereuses grâce à la conception de mécanismes. **Si certains comportements malveillants ne peuvent pas être éliminés, quel degré de « confiance » devons-nous introduire, combien d’individus dans un groupe devons-nous faire confiance et sur combien de « roues auxiliaires » devons-nous nous appuyer.
Ci-dessous, nous analyserons les facteurs de risque dans le modèle général Ethereum Layer2/Bitcoin Layer2** (Les objets mentionnés dans cet article n’incluent pas le « canal d’état » ou le « canal de paiement », ni le protocole d’index d’inscription, car ils sont spécial). **Et nous essaierons d’explorer quels facteurs sont les plus fondamentaux, de niveau inférieur et les plus importants dans le modèle de sécurité de couche 2. Ces lacunes plus fondamentales seront des risques de confiance qui méritent notre attention plus que d’autres lacunes.
L’effet barillet de Layer2 - quels sont les défauts ?
Le conseil le plus court - contrat/droits officiels de gestion du pont
Ici, autant utiliser « l’effet baril » pour analyser les problèmes de sécurité de la couche 2. Il est facile de voir que la carte la plus courte est « l’évolutivité du contrat » mentionnée ci-dessus (principalement pour Ethereum Layer 2), ou d’ailleurs, c’est la « droit de gestion du pont inter-chaînes officiel » (applicable à la fois à Bitcoin et à Ethereum Layer 2). **
Pour Ethereum Layer 2, tant que le responsable de la couche 2 peut rapidement mettre à niveau le contrat sur la chaîne de couche 1, le jeton verrouillé sur l’adresse officielle de dépôt et de retrait du pont L2 peut théoriquement être volé, quelle que soit la fiabilité de sa couche DA ou de son système de certification. est.
On peut dire que l’autorité de contrôle du contrat de pont est liée à la sécurité de l’ensemble du système. Il s’agit de la partie la plus fondamentale et la plus critique de l’ensemble de la couche 2 et même de la pile modulaire de blockchain. **Si le composant/contrat du pont peut être mis à jour et itéré sous contrôle multi-signature, alors nous devons introduire ici une « hypothèse de confiance », en supposant que le contrôleur du contrat/pont officiel de couche 2 ne fera pas de mal. **
(Les délais de mise à niveau des contrats des différents projets Layer2 sont marqués sur L2BEAT. La plupart des contrats L2 peuvent être mis à niveau immédiatement par le contrôleur. Si le contrôleur de contrat souhaite voler des actifs, ou si sa clé privée est volée par un pirate informatique, les actifs de l’utilisateur hébergés par L2 va certainement souffrir)
Contrairement à Ethereum Layer 2, le pont de Bitcoin Layer 2 n’est fondamentalement pas contrôlé par le contrat sur la couche 1, car Bitcoin ne prend pas en charge à l’origine les contrats intelligents. Relativement parlant, l’ensemble du flux de travail d’Ethereum Layer2 dépend fortement du contrat sur Layer1, alors que Bitcoin Layer2 ne peut pas le faire.
(Schéma Starknet)
**Il s’agit d’un problème inévitable pour Bitcoin Layer 2. On peut dire qu’il présente à la fois des avantages et des inconvénients. À l’heure actuelle, il semble que le « pont sans confiance » mis en œuvre par Ethereum Layer 2 et reposant sur des contrats ne puisse pas être réalisé dans Bitcoin L2. **Ce “Trustless Bridge” nécessite le déploiement d’un contrat dédié sur Layer1 et la coopération du système DA+ anti-fraude/ZK proof. Il est essentiellement similaire au “pont optimiste” comme les ponts Orbiter ou ZK comme Polyhedra.
L’opinion dominante actuelle dans l’industrie est que si l’on ne considère pas les bogues possibles dans la pratique et que l’on considère uniquement les modèles théoriques, le niveau de sécurité d’Optimistic Bridge et du ZK Bridge est fondamentalement le niveau 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, il est fondamentalement sans confiance.
(Le Pont Optimiste doit seulement s’assurer qu’un observateur sur N est honnête pour garantir la sécurité. Le modèle de confiance est 1/N)
Puisque Bitcoin Layer 2 ne peut pas déployer de composants contractuels sur la couche 1 (nous ne parlons pas ici du Lightning Network), ses ponts officiels sont essentiellement des “** Notary Bridges” composés d’un petit nombre de nœuds, ou des “Multi-Signature Bridges”. Ce type de pont La sécurité dépend de la manière dont sont mises en place les multi-signatures/signatures à seuil, ce qui nécessite d’introduire des hypothèses de confiance fortes : on suppose que ces notaires ne s’entendront pas et ne se feront pas voler leurs clés privées. **
À l’heure actuelle, la plupart des ponts basés sur des signatures notariées/à seuil ne peuvent pas être comparés au « pont sans confiance » officiel d’Ethereum Layer 2 en termes de sécurité (le principe est que le contrat d’Ethereum Layer 2 ne sera pas mis à niveau de manière malveillante). Évidemment, 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 par la décentralisation du pouvoir du pont multi-signature. C’est sa première « roue auxiliaire ». **
Étant donné que les « droits de mise à niveau » des contrats officiels liés au pont Ethereum Layer 2 sont souvent concentrés entre les mains de quelques contrôleurs multi-signatures, ** si les contrôleurs multi-signatures s’entendent, le pont Ethereum Layer 2 aura également des problèmes, à moins que it Le contrat ne peut pas être amélioré ou est soumis à un retard important** (actuellement uniquement Degate et Fuel V1).
(Chaque fois que le contrat Degate est mis à niveau, il réservera une période d’évasion sûre de 30 jours aux utilisateurs. Pendant cette période, tant que tout le monde découvre que la nouvelle version du code du contrat a une logique malveillante, ils peuvent s’échapper en toute sécurité grâce au retrait forcé. /fonction cabine de secours)
Concernant la partie “pont officiel”, **Les modèles de confiance d’Ethereum Layer 2 et Bitcoin Layer 2 sont fondamentalement les mêmes : les contrôleurs qui ont besoin de faire confiance à la multi-signature ne s’entendront pas pour faire le mal.**Ce groupe de multi-signatures les signatures peuvent contrôler le pont officiel L2 ou le modifier. La logique du code est de libérer directement les demandes de retrait invalides, et le résultat final est : les actifs des utilisateurs peuvent être volés.
La seule différence entre les deux est que Le pont officiel d’Ethereum Layer 2 est sans confiance tant que le contrat n’est pas mis à niveau de manière malveillante/la fenêtre de mise à niveau est suffisamment longue, mais Bitcoin Layer 2 ne peut de toute façon pas obtenir cet effet.
Le deuxième tableau le plus court - retrait forcé résistant à la censure
Si nous supposons que la question des contrats multi-signatures/contrôle officiel des ponts mentionnée ci-dessus peut être ignorée, c’est-à-dire qu’il n’y a aucun problème avec cette couche, alors la couche suivante la plus importante doit être la résistance à la censure des retraits.
Concernant l’importance de la fonction de retrait/évasion forcé résistant à la censure, Vitalik a souligné dans son article “Différents types de couche 2” il y a quelques mois que la possibilité pour les utilisateurs de retirer avec succès des actifs de la couche 2 vers la couche 1 est un facteur clé. indicateur. **
Si le séquenceur de Layer 2 continue de rejeter vos demandes de transaction, ou tombe en panne/est en panne pendant une longue période, vos actifs seront « gelés » et rien ne pourra être fait. **Même si des systèmes DA et anti-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 du DA ou de la preuve de fraude. À l’heure actuelle, l’ensemble du réseau de couche 2 est pratiquement mis au rebut, mais il existe toujours un moyen pour que vos actifs s’en sortent indemnes. **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 toujours permettre aux actifs des utilisateurs d’être évacués en toute sécurité en cas de panne de DA/les utilisateurs ne peuvent pas synchroniser les dernières données)
Certains Ethereum Layer 2, tels que Loopring, StarkEx, dYdX, Degate, etc., mettront en place une fonction d’activation de cabine de retrait/évasion forcée résistante à la censure sur la couche 1. En prenant Starknet comme exemple, si l’utilisateur soumet Forcé sur la couche 1 Si la demande de retrait ne reçoit pas de réponse du séquenceur Layer2 à la fin de la période fenêtre de 7 jours, la fonction de demande de gel peut être appelée manuellement pour mettre L2 à l’état gelé et activer le mode cabine d’évacuation.
Pour le moment, le trieur ne peut pas soumettre de données au contrat Rollup sur L1, et l’ensemble de la couche 2 sera gelé pendant un an. Ensuite, ** les utilisateurs peuvent soumettre une preuve Merkle pour prouver leur statut d’actif sur la couche 2 et retirer directement de l’argent sur la couche 1 (en fait, ils retirent leur propre montant égal de fonds de l’adresse officielle de dépôt et de retrait du pont). **
De toute évidence, le mode trappe de secours ne peut être implémenté que sur une chaîne comme Ethereum qui prend en charge les contrats intelligents, et Bitcoin ne peut pas exécuter une logique aussi complexe. **En d’autres termes, la fonction de trappe de secours est essentiellement un brevet d’Ethereum Layer 2. Bitcoin Layer 2 doit utiliser des moyens auxiliaires supplémentaires pour imiter le chat et le tigre. Il s’agit de la deuxième « roue auxiliaire ». **
**Mais simplement énoncer une « demande de retrait forcé » est bien plus pratique que d’activer directement la trappe de secours. **Le premier nécessite uniquement 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 de la couche 2 (**Cela peut directement contourner le trieur et envoyer des données à d’autres nœuds de couche 2 (le nœud communique la demande). **Si le « retrait forcé » ne reçoit pas de réponse pendant une longue période, il est plus raisonnable pour l’utilisateur de déclencher le mode cabine d’évacuation.
(Référence : Quelle est l’importance des fonctions de retrait forcé et de cabine d’évacuation pour la couche 2 ?)
**Actuellement, il existe déjà des équipes Bitcoin Layer 2 qui prévoient d’imiter la mise en œuvre des transactions forcées d’Arbitrum et de permettre aux utilisateurs d’émettre des déclarations de transactions forcées (enveloppes de transactions forcées) sur la chaîne Bitcoin. **Avec cette solution, les utilisateurs peuvent contourner le séquenceur et « transmettre leurs voix » directement aux autres nœuds Layer2. Si le séquenceur rejette toujours la demande de l’utilisateur après avoir vu l’instruction de transaction forcée de l’utilisateur, cela sera remarqué par les autres nœuds de couche 2 et pourra être puni.
**Mais le problème est que la fonction de transaction forcée d’Arbitrum, bénéficiant de son système anti-fraude, peut punir le séquenceur/proposant qui a ignoré les transactions des utilisateurs. Cependant, Bitcoin Layer 2, dont il est difficile de vérifier la preuve de fraude sur la couche 1, rencontrera certains défis à cet égard. (Ne parlons pas de BitVM pour l’instant) **S’il s’agit d’une solution telle que le Rollup souverain, où le niveau de sécurité n’est pas très différent de la vérification du client, il nous est difficile d’évaluer sérieusement sa fiabilité, et nous devrons peut-être évaluer la détails de mise en œuvre de différents projets.
Bien entendu, étant donné que de nombreux Bitcoin Layer 2 fonctionnent actuellement sous une forme similaire aux chaînes latérales, cela équivaut à réaliser un ** séquenceur décentralisé, qui peut résoudre dans une certaine mesure le problème de l’anti-censure. Mais il ne s’agit là que d’un moyen auxiliaire efficace, et certainement pas d’une solution ultime. **
ps : Certaines solutions actuelles de couche 2, comme Validium, etc., ne sont pas parfaites dans la conception du mécanisme de la cabine d’évacuation. Lorsque le séquenceur lance une attaque de rétention de données/DA n’est pas disponible, les utilisateurs ne peuvent pas retirer de fonds. Mais cela est dû à la conception imparfaite de la cabine d’évacuation de couche 2. Théoriquement, le retrait optimal de la cabine d’évacuation ne peut s’appuyer que sur des données historiques et n’a pas besoin de s’appuyer sur la disponibilité de DA/nouvelles données)
La troisième carte la plus courte : la fiabilité de la publication des données de la couche DA
**Bien que DA soit appelé disponibilité des données, ce terme fait en réalité référence à la publication des données. **C’est uniquement parce que Vitalik et Mustafa n’ont pas bien réfléchi lorsqu’ils ont initialement nommé ce concept que le nom DA/disponibilité des données ne correspond pas. Vrai nom.
**La publication des données, comme son nom l’indique, fait référence à la question de savoir si les derniers blocs/données de transaction/paramètres de transition d’état peuvent être reçus avec succès par ceux qui en ont besoin. **La publication de données sur différentes chaînes a une fiabilité différente.
(Référence : Incompréhension de la disponibilité des données : DA=publication des données ≠ récupération des données historiques)
Les communautés occidentales pensent généralement que les chaînes publiques établies telles que Bitcoin et Ethereum sont les couches DA les plus fiables. Si le trieur Layer2 publie de nouvelles données sur Ethereum, toute personne exécutant le client Ethereum Geth peut télécharger les données et les synchroniser sans aucune entrave. **Cela est dû au fait que cela est réalisé grâce à l’énorme échelle du réseau Ethereum et du grande variété de sources de données publiques.
**Il convient de mentionner qu’Ethereum Rollup forcera le séquenceur à publier les paramètres de transition des données de transaction/état sur la couche 1, ce qui est garanti par une preuve de validité/preuve 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éclenchera la logique du contrat pour générer un datahash, et le contrat du validateur doit confirmer que le certificat de validité soumis par le proposant a une relation correspondante avec le datahash.
Cela équivaut à : confirmer que la preuve zk et le Stateroot soumis par le proposant sont associés aux données Tx soumises par le séquenceur, c’est-à-dire New Stateroot=STF(Old Stateroot, Txdata). STF est la fonction de transition d’état.
**Cela garantit que les données de transition d’état/DA sont téléchargées de force sur la chaîne. Si vous soumettez uniquement le certificat de racine d’état et de validité, il ne pourra pas passer la vérification du contrat du validateur. **
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 approfondie. La conclusion générale est la suivante : **La fiabilité de la couche DA est plus importante que l’exhaustivité de la preuve de fraude/ système de preuve 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 se trouve sur la chaîne Ethereum, sont sujettes aux « attaques de rétention de données », ce qui signifie :
**Sequencer/Proposer peut conspirer avec les nœuds de couche DA sous la chaîne ETH pour mettre à jour la racine d’état sur Layer1, mais les paramètres d’entrée correspondant à la transition d’état sont retenus et non envoyés, ce qui rend impossible pour les étrangers de juger si le nouveau stateroot est correct, ce qui devient “les yeux ouverts” aveugles ". **
**Si cela se produit, l’ensemble du réseau de couche 2 équivaut à être mis au rebut, **car pour le moment, vous n’avez aucune idée de ce qu’est devenu le grand livre de couche 2. S’il s’agit de la couche 2 (Plasma et Optimium) basée sur une preuve de fraude, le trieur peut réécrire les données/actifs sous n’importe quel compte à volonté ; s’il s’agit de la couche 2 (Validium) basée sur une preuve de validité, bien que le trieur ne puisse pas réécrire votre compte à volonté. sera, à ce moment-là, l’ensemble du réseau de couche 2 est devenu une boîte noire. Personne ne savait ce qui s’était passé à l’intérieur, et ce n’était pas différent d’être mis au rebut. 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.
(Référence : Rétention de données et preuve de fraude : pourquoi Plasma ne prend pas en charge les contrats intelligents)
Par conséquent, 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 validité. **Pour Bitcoin Layer 2, en particulier la couche 2 basée sur le modèle de vérification client, même si le système de vérification de preuve de fraude/validité n’est pas configuré sur la couche 1, tant que la couche DA fonctionne comme d’habitude, tout le monde peut toujours savoir si il y a une erreur dans la transition d’état du réseau L2.
À l’heure actuelle, il est difficile pour le réseau principal Bitcoin de vérifier la preuve de fraude/validité (BitVM ne sera pas abordé ici). Supposons d’abord que Bitcoin L2 ne dispose pas d’un système de vérification de preuve. Idéalement, si le trieur L2 fait vraiment le mal et publie une racine d’état qui n’est pas liée aux données DA sur la couche de règlement/BTC, il ne peut toujours pas véritablement voler les actifs de l’utilisateur car il a soumis unilatéralement la racine d’état/le résultat de l’état. la transition ne sera pas reconnue par les nœuds honnêtes, et en fin de compte, ce sera peut-être juste pour le plaisir personnel.
*(***À l’heure actuelle, tant que les nœuds gérés par les fournisseurs d’installations périphériques de l’écosystème tels que les échanges et les ponts inter-chaînes ne s’entendent pas avec le séquenceur, le séquenceur ne peut pas réaliser rapidement les actifs volés en publiant des données incorrectes. **Après cela, tant qu’un nœud honnête découvre que quelque chose ne va pas et émet une alarme à un moment critique, l’erreur peut être corrigée par le consensus social. Cependant, le coût du consensus social lui-même est très élevé et ne peut pas prendre effet. immédiatement)
S’il s’agit d’un modèle similaire à une chaîne latérale, dans lequel la plupart des nœuds conspirent pour effectuer des changements d’état malveillants, les utilisateurs peuvent rapidement découvrir le problème. Tant que les installations tierces telles que les ponts et les échanges inter-chaînes ne reconnaissent pas les données erronées, le contrôleur malveillant de la couche 2/side-chain ne sera pas en mesure d’encaisser avec succès, à moins qu’il ne convainque les autres de le faire directement. OTC avec lui sur la chaîne.
(Viatlik a souligné un jour dans l’article que la vérification du client est le véritable fondement pour assurer la sécurité du réseau blockchain, vérifiez par vous-même)
Il y a un point très intéressant ici : en fait, Ethereum Layer 2 et Bitcoin Layer 2 peuvent réaliser une « vérification 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 des preuves pour garantir la validité des transitions d’état et n’a fondamentalement pas besoin de s’appuyer sur un consensus social (à condition qu’il existe une preuve/validité de fraude mature. système de preuve).
Le système de « vérification 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 l’est toujours. Il peut en causer Les gens perdent des actifs. Pour Ethereum Layer 2, parce que son pont officiel doit prouver la coopération du système, si le système s’avère imparfait, le séquenceur peut voler les actifs de l’utilisateur et s’enfuir sur L1. Bien sûr, les exigences spécifiques Voir comment concevoir le composant de pont à chaînes croisées).
Par conséquent, une couche 2 capable de mettre en œuvre un système de vérification de preuve de fraude/validité sur la couche 1 sera toujours bien meilleure qu’un simple modèle de « vérification client ». **
**PS : étant donné que la plupart des Bitcoin Layer 2 qui adoptent le système de preuve de fraude/validité ne peuvent pas permettre à la couche 1 de participer directement au processus de vérification de la preuve, son essence consiste toujours simplement à traiter Bitcoin comme la couche DA, et le modèle de sécurité est équivalent à “vérification finale du client”. **
Théoriquement, la preuve de fraude peut être vérifiée sur la chaîne Bitcoin grâce à 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 Layer1, 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 Layer1 ».
Résumer
Après une simple analyse du modèle baril, nous pouvons dans un premier temps tirer une conclusion** : dans le modèle de sécurité traditionnel Layer2, selon le degré d’importance/degré de base, il peut être trié comme suit :**
- Si l’autorité de contrôle du pont contractuel/officiel est raisonnablement dispersée
- Existe-t-il une fonction de retrait résistante à la censure ?
- Le formulaire de diffusion de la couche DA/des données est-il fiable ?
- Si un système fiable de preuve de fraude/preuve de validité est déployé sur la couche 1
Bien entendu, nous n’avons pas analysé le ckBTC, le Inscription Index Protocol et d’autres solutions du Lightning Network/State Channel et de l’écosystème ICP, car ils sont assez différents des solutions typiques de Rollup, Plasma, Validium ou de vérification client. En raison de contraintes de temps, il nous est difficile de procéder à une évaluation prudente de ses facteurs de sécurité et de risque, mais compte tenu de leur importance, des travaux d’évaluation pertinents seront effectués comme prévu à l’avenir.
Dans le même temps, il existe de sérieuses divergences entre de nombreuses parties au projet quant à savoir si le protocole d’index d’inscription doit être considéré comme la couche 2. Cependant, quelle que soit la définition de la couche 2, de nouveaux éléments tels que le protocole d’index d’inscription ont apporté suffisamment d’innovation technologique. à l’écosystème Bitcoin et finira par éclater avec une grande vitalité.
