De Blast aux portes dérobées des multisignatures de Layer2 : quelle est la plus importante, la technologie ou le consensus social ?
TechFlow SélectionTechFlow Sélection
De Blast aux portes dérobées des multisignatures de Layer2 : quelle est la plus importante, la technologie ou le consensus social ?
La « gouvernance par l'homme » dans Web3 diffère fondamentalement de la « gouvernance par l'homme » des États souverains dans le monde réel.
Dédié à des analyses Web3 approfondiesAuteur : Faust, Geek web3
Introduction : Face à des projets comme Polygon zkEVM et autres Layer2 « orthodoxes », le message implicite de Blast pourrait bien être : « Les rois et généraux naissent-ils avec un privilège héréditaire ? ». Puisque personne n'est vraiment dépourvu de confiance, et que la sécurité repose fondamentalement sur le consensus social, pourquoi critiquer Blast pour son manque supposé de « pureté » en tant que Layer2 ? Pourquoi cette fraternité se déchirerait-elle avec tant de violence ?
Certes, le fait que Blast utilise un multisig 3/5 pour contrôler l'adresse de dépôt a été largement critiqué. Pourtant, la plupart des Layer2 utilisent également des mécanismes multisig pour gérer leurs contrats. Optimism, par exemple, n'utilisait auparavant qu'une simple adresse EOA pour autoriser les mises à jour de contrat. Dans un contexte où presque tous les Layer2 dominants présentent des vulnérabilités liées au multisig, critiquer Blast pour son manque de sécurité ressemble davantage au mépris d'une élite technologique envers un projet perçu comme une simple chasse aux rendements.
Mais au-delà de cette comparaison entre projets, la véritable valeur de la blockchain réside surtout dans sa capacité à résoudre les problèmes d'opacité de l'information inhérents aux systèmes de consensus social ou de gouvernance démocratique. En vantant la suprématie technologique, nous devons admettre que le consensus social lui-même est plus important que la technologie, car c'est lui qui constitue la base du fonctionnement effectif de tout projet Web3. En fin de compte, la technologie sert le consensus social. Un projet, aussi techniquement avancé soit-il, n’est qu’un appendice ornemental si la majorité ne l’accepte pas.
Contenu principal : Récemment, Blast, un nouveau projet lancé par le fondateur de Blur, a connu un succès fulgurant sur Internet. Présenté comme un protocole « générant des intérêts sur actifs » sous couvert de Layer2, il dispose sur la chaîne ETH d’une adresse de dépôt. Lorsqu’un utilisateur y transfère des fonds, ceux-ci sont utilisés pour le staking natif sur ETH, placés dans MakerDAO pour générer des intérêts, etc., et les bénéfices sont reversés aux utilisateurs.
Grâce à la notoriété de son créateur et à un modèle attractif, Blast a levé 20 millions de dollars auprès d'investisseurs menés par Paradigm, attirant également une foule d'investisseurs particuliers. Moins de cinq jours après son lancement, la TVL accumulée sur l'adresse de dépôt de Blast a dépassé 400 millions de dollars. Sans exagération, Blast a agi comme une dose puissante en pleine période de marché baissier, relançant instantanément l’enthousiasme général.
Cependant, malgré ce succès initial, Blast a suscité de nombreuses critiques d'experts. Par exemple, L2BEAT et des ingénieurs de Polygon ont souligné que le Blast actuel n’est rien d’autre qu’un contrat de dépôt déployé sur Ethereum. Ce contrat peut être mis à jour via un multisig 3/5, autrement dit, sa logique contractuelle peut être modifiée — rug pull inclus. De plus, Blast affirme vouloir implémenter une architecture Rollup, mais pour l’instant, il ne s’agit que d’une coquille vide, dont la fonction de retrait ne sera disponible qu’en février prochain.
Blast riposte fermement en rappelant que la grande majorité des Rollups reposent sur un groupe multisig pour gérer les mises à jour de contrat ; ainsi, les accusations contre Blast pour son usage du multisig ne sont qu’un cas classique de « l’hypocrite qui accuse autrui ».
Le problème du multisig dans les Layer2 existe depuis longtemps
En réalité, l'utilisation du multisig par les Layer2 n'est pas nouvelle. Dès juillet dernier, L2BEAT avait mené une étude approfondie sur la mise à jour des contrats Rollup. Ce qu’on appelle « mise à jour », c’est changer l’adresse du contrat logique pointé par le proxy, permettant ainsi de modifier la logique du contrat. Si le nouveau contrat contient une logique malveillante, l’équipe officielle du Layer2 pourrait voler les actifs des utilisateurs.
(Source de l'image : wtf academy)
Selon les données de L2BEAT, des Rollups majeurs comme Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet et Polygon ZKEVM utilisent tous des contrats mis à jour via multisig, pouvant contourner les time locks et effectuer immédiatement une mise à niveau. (Voir l'article précédent de Geek web3 : Le jeu de la confiance : les Rollups contrôlés par multisig et comités)
Ce qui surprend, c’est qu’Optimism utilisait auparavant une seule adresse EOA pour gérer les mises à jour de contrat, sans même utiliser de multisig avant octobre dernier. Quant à Polygon zkEVM, qui a critiqué Blast, il peut, grâce à un multisig 6/8, procéder à une « prise de contrôle d’urgence » du contrat Rollup, passant ainsi d’une gouvernance par contrat à une « gestion purement humaine ». Curieusement, l’ingénieur de Polygon ayant critiqué Blast mentionne ce point, mais de manière évasive.
Quel est alors le sens de ce mode « d’urgence » ? Pourquoi la plupart des Rollups gardent-ils un bouton d’urgence, une porte dérobée ? Selon Vitalik, les Rollups doivent fréquemment mettre à jour leurs contrats déployés sur Ethereum lors de leur itération. Sans recourir à des mécanismes tels que les proxies permettant la mise à jour, il serait difficile d’évoluer efficacement.
De plus, les contrats intelligents qui gèrent de gros volumes d’actifs peuvent contenir des bugs difficiles à détecter, et les équipes de développement des Layer2 peuvent commettre des erreurs. Si ces failles sont exploitées par des pirates, cela pourrait entraîner un vol massif d’actifs. Ainsi, que ce soit pour un Layer2 ou un protocole DeFi, on installe souvent un bouton d’urgence, permettant à un « comité » d’intervenir en cas de besoin pour prévenir des incidents graves.
Bien sûr, les comités des Layer2 peuvent souvent contourner les time locks pour mettre à jour immédiatement le code du contrat. D’un certain point de vue, ils semblent être une menace plus inquiétante que les hackers eux-mêmes. Autrement dit, quel que soit le cas, les contrats intelligents détenant de gros volumes d’actifs ne peuvent éviter un certain degré d’« hypothèse de confiance » — à savoir que les détenteurs du multisig ne tricheront pas. À moins que le contrat ne soit conçu comme non mis à jour, et qu’il n’existe aucune faille compromettant la sécurité des actifs des utilisateurs.
En pratique, les principaux Layer2 actuels permettent soit à leurs comités de mettre à jour immédiatement les contrats, soit imposent un time lock court (par exemple, toute mise à jour du contrat dYdX nécessite un délai minimal de 48 heures). Si les utilisateurs découvrent que le comité prévoit d’insérer une logique malveillante dans le nouveau contrat, ils théoriquement disposent d’un temps suffisant pour retirer leurs actifs vers Layer1.
(Sur les retraits forcés et les fonctions d'évacuation, voir notre article précédent : Pour un Layer2, quelle est l'importance des retraits forcés et des fonctions d'évacuation ?)
(Un time lock impose un délai avant qu'une certaine opération puisse être effectuée)
Mais le cœur du problème est que beaucoup de Layer2 n’ont même pas mis en place de fonction de retrait forcé indépendante du séquenceur. Dans ce cas, si l’équipe officielle veut tricher, elle peut d’abord faire refuser par le séquenceur toutes les demandes de retrait, puis transférer les actifs des utilisateurs vers un compte L2 contrôlé par l’équipe. Ensuite, elle met à jour le contrat Rollup selon ses besoins, et une fois le délai du time lock expiré, retire tous les actifs sur Ethereum.
Bien sûr, la situation réelle pourrait être encore pire, car la plupart des équipes officielles de Rollup peuvent mettre à jour leurs contrats sans être limitées par le time lock, ce qui signifie qu’elles pourraient potentiellement réaliser un rug d’un montant de centaines de millions en un instant.
Un Layer2 véritablement décentralisé devrait avoir un délai de mise à jour du contrat supérieur au délai de retrait forcé
En réalité, pour résoudre le problème de décentralisation/sécurité des Layer2, plusieurs conditions doivent être remplies :
Installer sur Layer1 une sortie de retrait résistante à la censure, permettant aux utilisateurs de retirer leurs actifs de Layer2 vers Ethereum sans autorisation du séquenceur. Le délai de retrait forcé ne doit pas être trop long, afin d’assurer une sortie rapide des actifs du L2 ;
Toute mise à jour du contrat Layer2 doit être soumise à un time lock, la mise à jour du contrat devant intervenir après l’activation du retrait forcé. Par exemple, si la mise à jour du contrat dYdX nécessite un minimum de 48 heures, le délai d’activation du retrait forcé/du mode d’évacuation devrait être inférieur à 48 heures. Ainsi, si les utilisateurs découvrent que dYdX prévoit d’insérer du code malveillant dans la nouvelle version, ils peuvent retirer leurs actifs de Layer2 vers Layer1 avant la mise à jour.
Actuellement, la plupart des Rollup ayant mis en place un mécanisme de retrait forcé/fonction d’évacuation ne respectent pas ces conditions. Par exemple, le retrait forcé/délai d’évacuation de dYdX peut atteindre 7 jours, tandis que le délai de mise à jour du contrat par le comité est de seulement 48 heures. Cela signifie que le comité peut déployer un nouveau contrat avant que le retrait forcé des utilisateurs ne prenne effet, et voler les actifs avant que les utilisateurs ne puissent fuir.
De ce point de vue, à l’exception de Fuel, ZKSpace et Degate, aucun autre Rollup ne garantit le traitement du retrait forcé des utilisateurs avant la mise à jour du contrat, et tous comportent donc un haut degré d’hypothèse de confiance.
Beaucoup de projets utilisant un schéma Validium (où les données DA sont gérées hors chaîne) ont certes un long délai de mise à jour du contrat (8 jours ou plus), mais le Validium dépend souvent de nœuds DAC hors chaîne pour publier les dernières données, et ces DAC peuvent lancer une attaque de rétention de données, rendant la fonction de retrait forcé inefficace, donc incompatible avec le modèle de sécurité décrit ci-dessus. (Voir notre article précédent : Expulser le Validium ? Reconsidérer le Layer2 à travers le prisme du proposant de Danksharding)
À ce stade, on peut tirer une conclusion claire : à l’exception de Fuel, ZKSpace et DeGate, les autres solutions Layer2 ne sont pas décentralisées. Les utilisateurs doivent soit faire confiance à l’équipe du projet ou à son comité de sécurité pour ne pas tricher, soit faire confiance aux nœuds DAC hors chaîne pour ne pas conspirer, soit faire confiance au séquenceur pour ne pas censurer leurs transactions (refuser leurs requêtes). Les seuls Layer2 véritablement sécurisés, résistants à la censure et décentralisés sont actuellement ces trois-là.
La sécurité ne repose pas uniquement sur la technologie, mais exige aussi le consensus social
En réalité, le sujet que nous abordons aujourd’hui n’est pas nouveau. Le fait que les Layer2 dépendent fondamentalement de la crédibilité de leur équipe a déjà été souligné par de nombreuses personnes. Des fondateurs comme ceux d’Avalanche et Solana ont violemment critiqué cela. Mais le problème est que cette hypothèse de confiance présente dans les Layer2 existe aussi au niveau des Layer1 et de tous les projets blockchain.
Par exemple, nous devons supposer que les nœuds validateurs de Solana représentant 2/3 du poids de mise en jeu ne conspirent pas, ou que les deux plus grands pools miniers de Bitcoin ne s’allient pas pour lancer une attaque 51 % et inverser la chaîne la plus longue. Bien que ces scénarios soient peu probables, « improbable » ne signifie pas « impossible ».
Lorsqu’un réseau public Layer1 traditionnel commet un acte malveillant causant de lourdes pertes aux utilisateurs, on finit souvent par abandonner cette chaîne via un consensus social et créer un fork (voir l’événement The DAO en 2016 ayant conduit à la bifurcation d’Ethereum en ETH et ETC). Si quelqu’un tente un fork malveillant, la communauté choisit aussi par consensus social quelle branche « plus fiable » suivre (par exemple, la majorité n’a pas suivi le projet ETHW).
Le consensus social est la racine qui assure le bon fonctionnement des projets blockchain et des protocoles DeFi qu’ils hébergent. Même les audits de code ou les divulgations communautaires de vulnérabilités font partie intégrante du consensus social. La décentralisation purement technique, quant à elle, ne joue souvent qu’un rôle limité et reste théorique.
Ce qui joue un rôle crucial en temps critique, ce ne sont pas la technologie, ni les articles académiques, ni les récits techniques, mais bien le consensus social, la surveillance par l’opinion publique, et la reconnaissance populaire.
Imaginons ce scénario : une chaîne publique PoW connue de quelques centaines de personnes est temporairement très décentralisée, car aucun acteur dominant n’existe encore. Mais si une entreprise de matériel minier décide soudainement d’y concentrer toute sa puissance de calcul, dépassant largement celle de tous les autres mineurs réunis, la décentralisation s’effondre instantanément. Si cette entreprise décide de tricher, les gens ne peuvent compter que sur le consensus social pour corriger l’erreur.
Inversement, même les Layer2 aux mécanismes les plus sophistiqués ne peuvent échapper au consensus social. Même pour des L2 comme Fuel, DeGate ou ZKSpace, où l’équipe officielle a presque zéro pouvoir malveillant, ils reposent toujours sur Ethereum, un Layer1 lui-même fortement dépendant du consensus social et de la surveillance communautaire.
D’ailleurs, notre conviction que certains contrats sont non mis à jour repose sur les rapports d’audits ou les affirmations de L2BEAT, mais ces institutions peuvent commettre des erreurs ou mentir. Bien que cette probabilité soit extrêmement faible, nous devons admettre qu’une petite hypothèse de confiance subsiste.
Néanmoins, l’open source inhérent à la blockchain permet à quiconque, y compris les hackers, d’inspecter les contrats pour y détecter une logique malveillante, minimisant ainsi au maximum les hypothèses de confiance, ce qui réduit considérablement le coût du consensus social. Quand ce coût est suffisamment bas, on peut considérer cela comme « dépourvu de confiance ».
Naturellement, en dehors de ces trois projets cités, les autres Layer2 n’ont aucune véritable absence de confiance. Ce qui assure réellement la sécurité en temps critique, c’est toujours le consensus social. La composante technologique sert souvent simplement à faciliter la surveillance par consensus social. Un projet peut être techniquement excellent, mais s’il ne gagne pas une reconnaissance large ni ne construit une communauté forte, sa gouvernance décentralisée et son consensus social peineront à s’exprimer efficacement.
La technologie est certes importante, mais plus encore, la reconnaissance générale et la capacité à développer une culture communautaire solide sont des facteurs plus cruciaux, plus précieux, et plus bénéfiques au développement du projet.
Prenons l'exemple du zkRollup : aujourd'hui, beaucoup de zkRollup n'implémentent que le système de preuve d'efficacité et la mise en ligne des données DA. Ils peuvent prouver que toutes les transactions et transferts traités sont valides, non falsifiés par le séquenceur, et donc honnêtes en matière de « transition d’état ». Mais les scénarios de malversation par l’équipe officielle ou le séquenceur ne se limitent pas à cela.
On peut dire que le système de preuve ZK réduit essentiellement le coût de surveillance du Layer2 par les utilisateurs, mais de nombreux aspects ne peuvent être résolus par la technologie seule et nécessitent l’intervention humaine ou du consensus social.
Si l’équipe L2 n’a pas mis en place de sortie anti-censure comme le retrait forcé, ou tente de mettre à jour le contrat en y insérant une logique de vol d’actifs, les membres de la communauté doivent compter sur le consensus social et la pression médiatique pour corriger l’erreur. À ce moment-là, la supériorité technologique semble secondaire. Plutôt que de mesurer l’importance de la technologie pour la sécurité, il est plus pertinent de valoriser la conception des mécanismes facilitant le consensus social — voilà la véritable essence du Layer2, voire de la blockchain elle-même.
À partir d’un projet comme Blast, qui repose entièrement sur le consensus social pour sa supervision, nous devrions mieux comprendre la relation entre consensus social et mise en œuvre technique, plutôt que de juger un projet meilleur qu’un autre selon le critère « quel L2 est plus proche du Layer2 tel que défini par Vitalik ». Lorsqu’un projet a déjà gagné la reconnaissance et l’attention de millions de personnes, le consensus social est déjà formé. Peu importe si c’est par marketing ou par narration technologique, car le résultat prime sur le processus.
Certes, le consensus social est une extension de la gouvernance démocratique, dont les défauts ont été prouvés dans le monde réel. Mais la nature open source et transparente de la blockchain réduit considérablement le coût du consensus social. Ainsi, le « gouvernement humain » du Web3 est fondamentalement différent du « gouvernement humain » des États souverains.
Si nous voyons la blockchain comme un outil visant à améliorer la transparence de l’information dans la gouvernance démocratique, plutôt que de poursuivre un idéal inaccessible de « trustless par pur code », alors tout devient soudain plus optimiste et clair. Seulement en dépassant l’arrogance et les préjugés de l’élite technologique, et en embrassant un public plus large, l’écosystème Layer2 d’Ethereum pourra véritablement devenir une infrastructure financière mondiale adoptée massivement.
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
