Utilisation de la théorie du tonneau en bois pour analyser les modèles de sécurité et les indicateurs de risque du Bitcoin et des Layer 2 d'Ethereum
TechFlow SélectionTechFlow Sélection
Utilisation de la théorie du tonneau en bois pour analyser les modèles de sécurité et les indicateurs de risque du Bitcoin et des Layer 2 d'Ethereum
Lorsque nous examinons un système complexe composé de plusieurs modules, il est essentiel d'identifier d'abord quel module constitue la « planche la plus courte ».
Dédié à des analyses Web3 approfondiesRédaction : Faust & Wuyue, Geek web3
Conseiller : Kevin He (@0xKevinHe), VP technique chez New Fire Technology
Introduction : Le chercheur américain en management Laurence Peter a formulé la « théorie du tonneau », selon laquelle la performance globale d'un système est limitée par son élément le plus faible. Autrement dit, la quantité d'eau qu’un tonneau peut contenir dépend de sa planche la plus courte. Ce principe, bien que simple, est souvent négligé. Les débats passés sur la sécurité des Layer2 ont majoritairement ignoré les priorités et niveaux d'importance entre différents composants, se concentrant presque exclusivement sur la fiabilité de la transition d'état et la disponibilité des données (DA), tout en omettant des éléments fondamentaux encore plus critiques, compromettant ainsi toute base théorique solide. Ainsi, lorsqu’on examine un système complexe à modules multiples, il est essentiel d’identifier d’abord quelle partie constitue la « planche la plus courte ».
Inspirés par cette théorie, notre analyse systématique révèle qu’il existe une relation de dépendance claire entre les différents composants des modèles de sécurité des Layer2 sur Bitcoin/Éther. Certains aspects sont fondamentalement plus basiques et cruciaux que d’autres — autrement dit, « plus courts ».
À cet égard, nous pouvons proposer un classement préliminaire des **composants selon leur niveau d’importance/fondamentalité dans les modèles de sécurité des Layer2 dominants** :
-
La permission de contrôle du contrat/pont officiel est-elle suffisamment décentralisée ? (à quel point le contrôle multisignature est-il centralisé)
-
Existe-t-il une fonction de retrait forcée résistante à la censure (retrait forcé, capsule d’évacuation)
-
La couche DA ou le format de publication des données est-il fiable ? (les données DA sont-elles publiées sur Bitcoin ou Ethereum)
-
Un système fiable de preuves de fraude ou de preuves d’efficacité est-il déployé sur Layer1 ? (nécessite BitVM pour les L2 Bitcoin)
Nous devrions intégrer avec mesure les recherches de la communauté Ethereum sur les Layer2, afin d'éviter le lyssenkisme
Comparé au système hautement structuré des Layer2 d'Ethereum, les Layer2 Bitcoin ressemblent à un nouveau territoire vierge. Ce concept, devenu crucial après l'essor des inscriptions, montre des signes prometteurs mais voit aussi son écosystème s'embrouiller rapidement, plongeant dans le chaos. De nombreux projets Layer2 émergent comme des champignons après la pluie. Bien qu'ils apportent de l'espoir à l'écosystème Bitcoin, certains dissimulent volontairement leurs risques de sécurité, allant jusqu'à affirmer « rejeter les Layer2 Ethereum et suivre une voie unique propre à l'écosystème Bitcoin », adoptant une posture presque extrémiste.
Compte tenu des différences fonctionnelles entre Bitcoin et Ethereum, il est inévitable que les Layer2 Bitcoin ne puissent pas s'aligner immédiatement sur les Layer2 Ethereum. Cependant, cela ne signifie nullement que nous devrions rejeter catégoriquement les connaissances communément admises dans la communauté Ethereum ou celle des blockchains modularisées (en référence à l'affaire Lyssenko, où le biologiste soviétique Trofim Lyssenko, utilisant des arguments idéologiques, persécuta les partisans de la génétique occidentale).
Au contraire, ces critères d'évaluation, forgés par des efforts considérables antérieurement et largement acceptés aujourd'hui, possèdent une force persuasive indéniable. Nier sciemment leur valeur relève de l'irrationalité.
Lors de la construction des Layer2 Bitcoin, nous devons reconnaître pleinement la pertinence du principe « apprendre de l'Ouest pour servir l'Est », intégrant avec discernement et optimisation les conclusions de la communauté Ethereum. Mais en empruntant des perspectives extérieures à l'écosystème Bitcoin, nous devons être conscients de leurs différences initiales et parvenir finalement à une coexistence dans la diversité.
C’est comme discuter des similitudes et différences entre « Occidentaux » et « Orientaux ». Qu’ils soient occidentaux ou orientaux, le suffixe « humain » implique de nombreuses caractéristiques communes ; seulement, selon le préfixe « Occidental » ou « Oriental », certaines particularités varient.
En fin de compte, il existe nécessairement des points communs entre « Occidentaux » et « Orientaux », ce qui signifie que beaucoup de ce qui s'applique aux premiers convient aussi aux seconds. De même, bon nombre des principes valables pour les « Layer2 Ethereum » s'appliquent également aux « Layer2 Bitcoin ». Avant de distinguer les différences entre les L2 Bitcoin et Ethereum, clarifier leurs points communs semble être une démarche plus importante et significative.
Dans cet esprit de « recherche de consensus tout en respectant les différences », les auteurs de cet article n’entendent pas aborder la question « qu’est-ce qu’un Layer2 Bitcoin, qu’est-ce qui ne l’est pas », car ce sujet suscite trop de controverses, et même la communauté Ethereum n’a pas réussi à définir objectivement quels projets sont véritablement des Layer2.
Ce qui est certain, c’est que tandis que différentes solutions technologiques apportent une scalabilité à Bitcoin, leurs risques de sécurité varient, et les hypothèses de confiance présentes dans leurs modèles de sécurité seront précisément le cœur de cet article.
Comment comprendre la sécurité des Layer2 et ses critères d'évaluation
En réalité, la sécurité des Layer2 n’est pas un sujet nouveau. Même le terme « sécurité » recouvre un concept composite incluant plusieurs attributs spécifiques.
Auparavant, le fondateur d’EigenLayer a simplifié la « sécurité » en quatre éléments : l’irréversibilité des transactions (résistance au rollback), la résistance à la censure, la fiabilité de la DA / publication des données, et la validité de la transition d’état.
(Le fondateur d’EigenLayer a exprimé son avis sur la manière dont les solutions de validation client / Rollup souverain peuvent hériter de la sécurité du réseau principal Bitcoin)
Par ailleurs, L2BEAT et des pionniers de la communauté Ethereum ont proposé un modèle d’évaluation des risques des Layer2 relativement complet. Toutefois, ces conclusions concernent principalement les Layer2 basés sur contrats intelligents, et non les solutions non contractuelles typiques telles que les Rollups souverains ou la validation client.
Bien que cela ne s’applique pas à 100 % aux L2 Bitcoin, ces analyses contiennent de nombreuses conclusions valables, largement reconnues dans la communauté occidentale, et facilitent notre évaluation objective des risques associés aux différents L2 Bitcoin.
(Vitalik a indiqué que, comme les solutions Rollup ne peuvent atteindre leur perfection théorique dès leur lancement, elles doivent recourir à des mécanismes complémentaires pour renforcer la sécurité — appelés « roues d’apprentissage » — introduisant ainsi des hypothèses de confiance. Ces hypothèses constituent justement les risques)
D’où proviennent donc ces risques de sécurité ? Actuellement, tant les Layer2 Ethereum que Bitcoin dépendent largement de nœuds centralisés agissant comme ordonnanceurs (« sequencers »), ou de comités restreints formant des sidechains. Si ces séquenceurs ou comités centralisés ne sont pas contraints, ils peuvent voler les actifs des utilisateurs et disparaître, refuser les transactions, gelant ainsi les fonds. Cela touche directement les notions de validité de la transition d’état et de résistance à la censure mentionnées précédemment par le fondateur d’EigenLayer.
De plus, comme les Layer2 Ethereum reposent sur des contrats de la chaîne ETH pour vérifier les transitions d’état et les dépôts/retraits, si le contrôleur du contrat (c’est-à-dire l’équipe officielle du Layer2) peut mettre à jour rapidement la logique du contrat et y insérer du code malveillant (par exemple autoriser une adresse spécifique à transférer tous les tokens verrouillés dans le pont L1-L2), il peut directement subtiliser les actifs gérés.
Ceci est connu sous le nom de « problème de distribution du multisig », qui s’applique également aux Layer2 Bitcoin, car ceux-ci dépendent souvent de « ponts notariés », nécessitant plusieurs nœuds pour approuver via multisig les requêtes inter-chaînes. La question de la répartition adéquate du multisig se pose donc tout autant pour les Layer2 Bitcoin, que nous pouvons considérer comme la première « roue d’apprentissage » fondamentale.
En outre, la question de la DA est également cruciale. Si un Layer2 ne publie pas ses données sur Layer1, mais choisit un lieu de publication DA peu fiable, et que ce comité DAC (Data Availability Committee) collabore pour refuser de publier les dernières données transactionnelles, une attaque par rétention de données rendrait le réseau inutilisable, empêchant potentiellement les retraits.
L2BEAT a résumé ces problèmes et identifié plusieurs éléments clés des modèles de sécurité des Layer2 :
-
La fiabilité du système de validation d’état / preuve (State Validation)
-
La fiabilité du mode de publication des données DA (Data Availability)
-
Si le réseau Layer2 refuse intentionnellement vos transactions ou tombe en panne, pouvez-vous retirer vos actifs de force ? (Sequencer Failure, Proposer Failure)
-
Le contrôle des contrats associés au Layer2 — le pont officiel inter-chaînes — est-il suffisamment décentralisé ? En cas de complicité, les utilisateurs disposent-ils d’un délai suffisant pour réagir ? (Exit Window)
(Graphique de « facteurs de risque » configuré par L2BEAT pour différents projets Layer2)
Bref, analyser les vulnérabilités des Layer2 revient à examiner combien de scénarios existent où les actifs des utilisateurs pourraient être compromis, et si le design du système peut efficacement contraindre ces menaces. Lorsque certains comportements malveillants ne peuvent être totalement évités, quelle ampleur de « confiance » devons-nous introduire ? Combien d’individus faut-il faire confiance ? Combien de « roues d’apprentissage » sont nécessaires ?
Dans la suite, nous analyserons les facteurs de risque présents dans les modèles généraux des Layer2 Ethereum/BTC (les objets traités ici excluent les « canaux d’état » ou « canaux de paiement », ainsi que les protocoles d’indexation d’inscriptions, car ils sont particuliers). Nous tenterons aussi d’explorer quels facteurs sont plus fondamentaux, profonds et importants dans les modèles de sécurité des Layer2. Ces lacunes plus fondamentales représentent des risques de confiance qu’il convient de prioriser face aux autres.
L’effet tonneau des Layer2 — Quelles sont les planches les plus courtes ?
La planche la plus courte — Le pouvoir de gestion du contrat / pont officiel
Ici, appliquons l’« effet tonneau » à l’analyse de la sécurité des Layer2. Il devient vite évident que la planche la plus courte est précisément ce dont nous avons parlé : la possibilité de mise à jour du contrat (notamment pour les Layer2 Ethereum), ou plus largement, le contrôle du pont inter-chaînes officiel (valable pour les Layer2 Bitcoin et Ethereum).
Pour un Layer2 Ethereum, tant que l’équipe officielle peut mettre à jour rapidement le contrat sur Layer1, elle pourrait théoriquement subtiliser les tokens verrouillés sur l’adresse du pont, indépendamment de la fiabilité de la couche DA ou du système de preuve.
On peut dire que le contrôle du contrat de pont affecte la sécurité globale du système. C’est l’élément le plus fondamental et critique de tout le stack des Layer2 et des blockchains modularisées. Si le composant de pont / contrat peut être mis à jour sous contrôle multisig, alors nous devons introduire une « hypothèse de confiance » : supposer que les contrôleurs du contrat / pont officiel ne feront pas mal.
(Sur L2BEAT, le délai de mise à jour des contrats est indiqué pour différents projets Layer2. La plupart des contrats L2 peuvent être mis à jour immédiatement par leurs contrôleurs. Si ces derniers veulent voler les actifs, ou si leurs clés privées sont piratées, les fonds déposés par les utilisateurs sont gravement menacés.)
Contrairement aux Layer2 Ethereum, les ponts des Layer2 Bitcoin ne sont pas contrôlés par des contrats sur Layer1, car Bitcoin ne supporte pas nativement les contrats intelligents. Par conséquent, alors que les Layer2 Ethereum dépendent fortement des contrats sur Layer1, les Layer2 Bitcoin ne peuvent pas fonctionner ainsi.
(Schéma de Starknet)
Pour les Layer2 Bitcoin, c’est un dilemme incontournable, ayant des avantages et des inconvénients. Pour l’instant, le « pont sans confiance » réalisé par contrat sur Ethereum ne peut pas être reproduit sur les L2 Bitcoin. Un tel « pont sans confiance » nécessite un contrat spécialisé sur Layer1, combiné à DA + système de preuve de fraude / preuve ZK, similaire en essence aux « ponts optimistes » comme Orbiter ou aux ponts ZK comme Polyhedra.
Actuellement, l’opinion dominante dans l’industrie est que, sans tenir compte des bugs pratiques mais uniquement du modèle théorique, les ponts optimistes et ZK offrent le niveau de sécurité le plus élevé. Tant que le code du contrat est exempt de bogues ou ne peut pas être mis à jour malicieusement, ils sont essentiellement sans confiance.
(Un pont optimiste nécessite simplement qu’un seul honnête parmi N gardiens garantisse la sécurité — modèle de confiance 1/N)
Comme les Layer2 Bitcoin ne peuvent pas déployer de composants contractuels sur Layer1 (hors Lightning Network), leurs ponts officiels sont presque toujours des « ponts notariés » ou « ponts multisig » composés d’un petit groupe de nœuds. La sécurité de ces ponts dépend de la configuration du multisig/signature seuil, et impose une forte hypothèse de confiance : supposer que ces notaires ne collaborent pas ni ne se font voler leurs clés privées.
Actuellement, la plupart des ponts basés sur notaires/signatures seuil ne peuvent rivaliser en sécurité avec les « ponts sans confiance » des Layer2 Ethereum (sous réserve que les contrats Ethereum ne soient pas mis à jour malicieusement). Il est clair que la sécurité des actifs gérés par un réseau Layer2 Bitcoin dépend de celle de son pont officiel, ou plus précisément de la dispersion du pouvoir du pont multisig — c’est là la première « roue d’apprentissage ».
Puisque les « droits de mise à jour » des contrats liés aux ponts officiels des Layer2 Ethereum sont souvent concentrés entre quelques contrôleurs multisig, si ces contrôleurs collaborent, le pont Ethereum peut aussi être compromis, sauf si le contrat est non mis à jour ou soumis à un long délai (seuls Degate et Fuel V1 actuellement respectent cela).
(Degate accorde une période de 30 jours d’évacuation sécurisée à chaque mise à jour de contrat. Pendant cette période, si les utilisateurs détectent une logique malveillante dans le nouveau code, ils peuvent fuir via le retrait forcé / capsule d’évacuation)
Concernant cette partie du « pont officiel », les modèles de confiance des Layer2 Ethereum et Bitcoin sont fondamentalement similaires : il faut faire confiance au fait que les contrôleurs multisig ne collaboreront pas pour nuire. Ce groupe multisig peut contrôler le pont officiel du L2, soit en modifiant sa logique, soit en approuvant illégalement des demandes de retrait, aboutissant toutes deux au vol d’actifs utilisateur.
La seule différence est que, tant que le contrat Ethereum n’est pas mis à jour malicieusement ou que le délai est suffisamment long, son pont est sans confiance, alors que les Layer2 Bitcoin ne peuvent jamais atteindre cet objectif.
La deuxième planche la plus courte — Le retrait forcé résistant à la censure
Supposons maintenant que le problème de contrôle du multisig/du pont officiel mentionné plus haut puisse être ignoré — autrement dit, qu’il n’existe pas — alors le prochain aspect le plus critique est la résistance à la censure des retraits.
Concernant l’importance du retrait forcé / capsule d’évacuation, Vitalik a souligné dans un article précédent « Different types of layer 2s » que la capacité des utilisateurs à retirer leurs actifs de Layer2 vers Layer1 est un indicateur de sécurité crucial.
Si le séquenceur du Layer2 rejette continuellement vos transactions ou tombe en panne prolongée, vos actifs seront « gelés », inutilisables. Même si la DA et les systèmes de preuve de fraude/ZK sont opérationnels, sans solution anti-censure, un tel Layer2 reste insuffisamment sûr, capable de bloquer vos actifs à tout moment.
D’ailleurs, la solution Plasma, populaire dans l’écosystème Ethereum, permet à quiconque, en cas de défaillance DA ou de preuve de fraude, de retirer en toute sécurité ses actifs vers Layer1. À ce stade, le réseau Layer2 est pratiquement hors service, mais vos actifs peuvent encore être récupérés. Il est clair que la fonction de retrait anti-censure est plus fondamentale et plus basique que la DA et les systèmes de preuve.
(Dankrad de la Fondation Ethereum indique que Plasma permet aux utilisateurs de retirer leurs actifs en sécurité lorsque la DA échoue ou que les utilisateurs ne peuvent pas synchroniser les dernières données)
Certains Layer2 Ethereum, comme Loopring, StarkEx, dYdX, Degate, etc., implémentent sur Layer1 une fonction d’activation de retrait forcé / capsule d’évacuation anti-censure. Prenons Starknet comme exemple : si une demande de retrait forcé soumise par l’utilisateur sur Layer1 n’obtient aucune réponse du séquenceur Layer2 au terme d’une fenêtre de 7 jours, l’utilisateur peut invoquer manuellement la fonction freezeRequest pour figer le L2 et activer le mode capsule d’évacuation.
À ce moment-là, le séquenceur ne peut plus soumettre de données au contrat Rollup sur L1, et tout le Layer2 est gelé pendant un an. Ensuite, les utilisateurs peuvent soumettre une preuve Merkle prouvant leur état d’actif sur Layer2, et effectuer directement un retrait sur Layer1 (c’est-à-dire retirer leurs fonds équivalents depuis l’adresse de dépôt/retrait du pont officiel).
Il est évident que le mode capsule d’évacuation ne peut être réalisé que sur des chaînes supportant les contrats intelligents comme Ethereum, ce que Bitcoin ne peut pas exécuter. Autrement dit, la fonction capsule d’évacuation est presque un monopole des Layer2 Ethereum. Les Layer2 Bitcoin doivent recourir à des mécanismes complémentaires pour l’imiter, constituant ainsi la deuxième « roue d’apprentissage ».
Mais simplement déclarer une « demande de retrait forcé » est bien plus simple que d’activer directement la capsule d’évacuation. La première méthode nécessite uniquement que l’utilisateur soumette une transaction sur Layer1 vers une adresse désignée, incluant dans les données annexes les informations destinées à tous les nœuds Layer2 (ce qui permet de contourner le séquenceur et de transmettre directement la demande aux autres nœuds Layer2). Si le « retrait forcé » n’obtient pas de réponse pendant longtemps, l’utilisateur peut ensuite déclencher le mode capsule d’évacuation — une conception raisonnable.
(Référence : À quel point les fonctions de retrait forcé et capsule d’évacuation sont-elles importantes pour les Layer2 ?)
Déjà, certaines équipes de Layer2 Bitcoin envisagent d’imiter la mise en œuvre d’Arbitrum du traitement forcé, permettant aux utilisateurs de publier des déclarations de transaction forcée (Forced Transaction Envelopes) sur la chaîne Bitcoin. Avec cette solution, les utilisateurs peuvent contourner le séquenceur pour « faire entendre leur voix » directement aux autres nœuds Layer2. Si le séquenceur continue de rejeter la demande après avoir vu la déclaration, cela sera détecté par d’autres nœuds et pourrait entraîner des sanctions.
Le problème est que la fonction de transaction forcée d’Arbitrum bénéficie de son système de preuve de fraude, capable de sanctionner un séquenceur/proposeur qui ignore constamment les transactions. Mais pour les Layer2 Bitcoin, difficiles à vérifier sur Layer1, cela pose un défi (sans parler de BitVM pour l’instant). Dans le cas des Rollups souverains, dont le niveau de sécurité est proche de celui de la validation client, il est difficile d’évaluer sérieusement leur fiabilité — cela dépendra probablement des détails techniques spécifiques à chaque projet.
Bien sûr, étant donné que de nombreux Layer2 Bitcoin fonctionnent actuellement comme des sidechains, implémentant un séquenceur décentralisé, cela peut résoudre partiellement le problème de censure. Mais ce n’est qu’un mécanisme complémentaire efficace, certainement pas une solution finale.
PS : Certaines solutions Layer2 actuelles, comme Validium, ont un mécanisme de capsule d’évacuation imparfait : en cas d’attaque par rétention de données ou de DA indisponible, les utilisateurs ne peuvent pas retirer leurs fonds. Mais cela résulte d’un design défectueux de la capsule d’évacuation. Théoriquement, le retrait optimal via capsule ne devrait dépendre que des données historiques, sans nécessiter l’accès à la DA ou aux nouvelles données.)
La troisième planche la plus courte : Fiabilité de la publication des données sur la couche DA
Bien que la DA soit appelée « disponibilité des données », ce terme désigne en réalité la « publication des données », simplement parce que Vitalik et Mustafa n’ont pas choisi soigneusement le nom initiallement, conduisant à cette appellation trompeuse.
La publication des données signifie simplement : les derniers blocs, transactions ou paramètres de transition d’état peuvent-ils être reçus sans difficulté par ceux qui en ont besoin ? La fiabilité varie selon la chaîne utilisée pour publier les données.
(Référence : Malentendus sur la disponibilité des données : DA = publication des données ≠ recherche dans l’historique)
La communauté occidentale considère généralement que des blockchains matures comme Bitcoin ou Ethereum sont les couches DA les plus sans confiance. Si un séquenceur Layer2 publie de nouvelles données sur Ethereum, toute personne exécutant un client geth Ethereum peut télécharger ces données et les synchroniser, presque sans entrave, grâce à l’ampleur du réseau Ethereum et à la multitude de sources de données publiques.
Il convient de noter que les Rollups Ethereum exigent impérativement que le séquenceur publie les données transactionnelles / paramètres de transition d’état sur Layer1, ce qui est garanti par les preuves d’efficacité / preuves de fraude.
Par exemple, après qu’un séquenceur ZK Rollup a publié les données transactionnelles sur Layer1, un datahash est généré dans la logique du contrat, et le contrat vérificateur doit confirmer que la preuve d’efficacité soumise par le proposeur correspond bien à ce datahash.
Cela équivaut à vérifier que la preuve zk et le Stateroot soumis par le Proposer sont liés aux données Tx soumises par le Séquenceur, soit Nouveau Stateroot = STF(Ancien Stateroot, Txdata). STF est la fonction de transition d’état.
Cela garantit que les données de transition d’état / DA sont obligatoirement enregistrées sur la chaîne. Si seul le stateroot et la preuve d’efficacité étaient soumis, la vérification échouerait.
Quant à savoir si la publication des données DA ou le système de vérification des preuves est plus fondamental, la communauté Ethereum/Celestia a déjà largement débattu. La conclusion générale est : la fiabilité de la couche DA est plus importante que l’intégrité du système de preuve de fraude / preuve d’efficacité. Par exemple, des solutions comme Plasma, Validium, Optimium — où la DA est hors chaîne Ethereum mais le règlement sur Ethereum — sont vulnérables à l’« attaque par rétention de données », c’est-à-dire :
Le Séquenceur/Proposer peut conspirer avec les nœuds de la couche DA hors ETH pour mettre à jour le stateroot sur Layer1, tout en retenant les paramètres d’entrée correspondants, empêchant les tiers de vérifier la validité du nouveau stateroot — devenant ainsi aveugles.
Si cela arrive, le réseau Layer2 est pratiquement hors service, car on ne sait plus à quoi ressemble le grand livre Layer2. Pour les Layer2 basés sur preuve de fraude (Plasma, Optimium), le séquenceur peut modifier arbitrairement les données/comptes ; pour ceux basés sur preuve d’efficacité (Validium), bien qu’il ne puisse pas modifier librement les comptes, tout le réseau devient une boîte noire, sans différence avec une panne. C’est pourquoi les solutions Layer2 orthodoxes dans l’écosystème Ethereum sont principalement des Rollups, tandis que Validium et Optimium ne sont généralement pas reconnus par la Fondation Ethereum.
(Référence : Rétention de données et preuve de fraude : pourquoi Plasma ne supporte pas les contrats intelligents)
Bienvenue dans la communauté officielle TechFlow Groupe Telegram :https://t.me/TechFlowDaily Compte Twitter officiel :https://x.com/TechFlowPost Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
