De l’explosion à la porte dérobée multisig de couche 2 : pourquoi le consensus social est-il plus important que la technologie ?

Auteur : Faust, geek web3

Introduction : Le sous-texte de Blast face à l’orthodoxie de la Couche2 telle que le Polygone zkEVM peut être « Généraux princiers, préférez-vous en avoir une sorte ? » Puisque tout le monde n’est pas assez confiant, et que l’essence est de s’appuyer sur le consensus social pour assurer la sécurité, pourquoi s’embêter à critiquer le fait que la concentration de couche 2 de Blast n’est pas assez élevée, « Pourquoi est-il si anxieux de se faire frire les uns les autres » ?

Certes, la dépendance de Blast sur le multisig 3/5 pour contrôler les adresses de dépôt a été largement critiquée, mais la plupart des couches 2 s’appuient également sur le multisig pour gérer les contrats, et Optimism n’a même utilisé qu’une seule adresse EOA pour contrôler les privilèges d’escalade des contrats. À une époque où les couches 2 grand public présentent presque tous des risques de sécurité tels que la multi-signature, critiquer Blast pour ne pas être assez sûr ressemble plus au « mépris » de l’élite technique pour un projet d’extraction d’or.

Mais en mettant de côté les deux mérites ci-dessus, l’importance de l’existence de la blockchain est davantage de résoudre le problème de l’opacité de l’information dans le consensus social/la gouvernance démocratique, et lorsque nous prônons la suprématie de la technologie, nous devons admettre que le consensus social lui-même est plus important que la technologie, car c’est la base qui assure le fonctionnement efficace de tous les projets Web3. En fin de compte, la technologie est au service du consensus social, et les projets qui ne peuvent pas être reconnus par la majorité des gens, quelle que soit la supériorité de la technologie, ne sont essentiellement qu’un magnifique appendice.

Texte : Récemment, le nouveau projet Blast lancé par le fondateur de Blur est devenu populaire sur tout le réseau, ce protocole d’« intérêt d’actif » sous la bannière de la couche 2 a mis en place une adresse de dépôt sur la chaîne ETH, et après que les utilisateurs aient déposé des fonds dans l’adresse Blast, ces fonds seront utilisés pour le jalonnement natif du réseau ETH, en les plaçant dans MakerDAO pour gagner des intérêts, etc., et les bénéfices seront retournés aux utilisateurs.

S’appuyant sur l’aura du fondateur lui-même et sur le gameplay attrayant, Blast a reçu un financement de 20 millions de dollars de la part d’investisseurs dirigés par Paradigm, et a également attiré la participation d’innombrables investisseurs particuliers. En moins de 5 jours après son lancement, l’adresse de recharge Blast a attiré plus de 400 millions de dollars en TVL. Il n’est pas exagéré de dire que BLast est comme un remède puissant dans un long marché baissier, qui suscite instantanément la frénésie des gens.

Cependant, si Blast a connu un succès progressif, il a également suscité les doutes de nombreux experts. Par exemple, les ingénieurs de L2BEAT et de Polygon ont tous dit que le Blast actuel n’est qu’un contrat de dépôt déployé sur Ethereum, qui peut être mis à niveau sous le contrôle de 3/5 multisig, en d’autres termes, la logique du code du contrat peut être réécrite, et Rug peut toujours être Rug. Dans le même temps, Blast ne prétend qu’implémenter la structure Rollup, mais ce n’est plus qu’une coquille vide, et même la fonction de retrait ne sera pas lancée avant février de l’année prochaine.

La grande majorité des Rollups s’appuient sur un ensemble de contrats de gestion multi-signatures pour mettre à niveau leurs autorisations, et d’autres Layer2 accusent « Blast with multi-signature » de ne comporter que 50 et 100 étapes.

Le multisig de couche 2 est un problème de longue date

En fait, la multisignature des contrats de couche 2 est un problème de longue date. Dès le mois de juillet de cette année, L2BEAT a mené une enquête spéciale sur la possibilité d’évolutivité du contrat de cumul, et la soi-disant « mise à niveau » consiste à modifier l’adresse logique du contrat indiquée par le contrat de procuration pour obtenir l’effet d’un changement de la logique du contrat. Si le nouveau contrat contient une logique malveillante, la couche 2 peut voler les ressources de l’utilisateur.

(图源 :WTF Academy)

Selon les données de L2BEAT, les rollups grand public tels que Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet et Polygon ZKEVM utilisent tous des contrats de mise à niveau autorisés à signatures multiples, qui peuvent être mis à niveau immédiatement en contournant la limite de verrouillage de temps. (Vous pouvez lire l’article précédent de Geek sur le web3 : Le jeu du crédit : les rollups manipulés par Multisig et Commission)

Étonnamment, Optimism n’utilisait qu’une adresse EOA pour gérer la mise à niveau du contrat, et même le multisig n’a été ajouté qu’en octobre de cette année. Quant à Polygon zkEVM, qui s’est attaqué à Blast, il peut également procéder à une « prise de contrôle d’urgence » du contrat Rollup sous l’autorisation de 6/8 multi-signature, et faire passer la couche 2 de la gouvernance contractuelle à la « gouvernance humaine nue ». Il est intéressant de noter que l’ingénieur de Polygon qui a critiqué Blast ci-dessus l’a également mentionné, mais d’une manière vague.

Quelle est donc la signification de l’existence de ce « mode d’urgence » ? Pourquoi la plupart des rollups doivent-ils se laisser un bouton de panique ou une porte dérobée ? Selon la déclaration précédente de Vitalik, les Rollups doivent fréquemment mettre à jour les contrats déployés sur ETH pendant le processus d’itération, et il est difficile d’itérer efficacement sans introduire des moyens évolutifs tels que les contrats de proxy.

De plus, les contrats intelligents qui hébergent un grand nombre d’actifs peuvent présenter des bogues qui ne sont pas facilement détectables, et il est inévitable que l’équipe de développement de la couche 2 soit négligente et que si certaines vulnérabilités sont exploitées par des pirates, cela peut entraîner le vol d’un grand nombre d’actifs. Par conséquent, qu’il s’agisse d’un protocole de couche 2 ou d’un protocole DeFi, un bouton de panique est souvent mis en place, et les « membres du comité » interviennent lorsque cela est nécessaire pour éviter que certains événements vicieux ne se produisent.

Bien sûr, les comités de couche 2 peuvent souvent contourner les restrictions de verrouillage temporel et mettre immédiatement à niveau le code du contrat, ce qui, d’une certaine manière, semble être plus tabou que les pirates informatiques et d’autres facteurs externes. En d’autres termes, dans tous les cas, il est difficile pour un contrat intelligent qui héberge une énorme quantité d’actifs d’être exempté d’un certain degré de « supposition de confiance », c’est-à-dire l’hypothèse que le contrôleur multisig derrière le contrat ne fait pas le mal. Sauf si le contrat est conçu pour ne pas être évolutif et qu’il n’y a pas de bogues qui pourraient menacer la sécurité des actifs de l’utilisateur.

La réalité est que les couches 2 traditionnelles permettent soit à leurs propres comités de mettre à jour les contrats immédiatement, soit d’introduire des restrictions de verrouillage plus courtes (par exemple, toute personne qui souhaite mettre à niveau le contrat dYdX a un délai d’au moins 48 heures). S’il s’avère que le comité a l’intention d’ajouter une logique malveillante au vol d’actifs dans la nouvelle version du code du contrat, l’utilisateur aura théoriquement suffisamment de temps pour réagir et retirer d’urgence les actifs de la couche 1.

(Pour plus d’informations sur le retrait forcé et la fonction de capsule d’évacuation, veuillez lire notre article précédent « Quelle est l’importance de la fonction de retrait forcé et de capsule d’évacuation pour la couche 2 ? »)

(Le timelock est un délai qui vous permet d’effectuer certaines opérations)**

Mais le nœud du problème est que de nombreux séquenceurs de couche 2 ne mettent même pas en place une fonction de retrait forcé qui peut contourner le séquenceur du séquenceur, de sorte que le responsable de la couche 2 peut faire le mal en demandant d’abord au séquenceur de rejeter la demande de retrait de tout le monde, puis de transférer les actifs de l’utilisateur sur le compte L2 contrôlé par le responsable de la couche 2. Après cela, le fonctionnaire mettra à jour le contrat de cumul en fonction de ses propres besoins, et lorsque le délai de verrouillage sera écoulé, tous les actifs de l’utilisateur pourront être transférés à la chaîne ETH.

Bien sûr, la situation réelle peut être pire que ce que j’ai dit, car la plupart des Rollups peuvent mettre à niveau les contrats sans verrouillage de temps, ce qui signifie qu’ils peuvent compléter des centaines de millions de dollars de tapis presque instantanément.

Un niveau 2 vraiment sans confiance devrait rendre le délai de mise à niveau du contrat plus long que le délai de retrait forcé

En fait, afin de résoudre le problème de la sécurité de la couche 2, les choses suivantes doivent être faites :

En mettant en place une sortie de retrait résistante à la censure sur la couche 1, les utilisateurs peuvent transférer directement des actifs de la couche 2 vers la chaîne ETH sans l’autorisation du séquenceur. Le délai de retrait forcé ne doit pas être trop long, afin de garantir que les actifs de l’utilisateur puissent être rapidement retirés de L2 ;

Toute personne souhaitant mettre à niveau un contrat de couche 2 doit être soumise à la limite de délai de verrouillage, et la mise à niveau du contrat doit prendre effet après le retrait obligatoire. Par exemple, s’il y a un délai d’au moins 48 heures pour la mise à niveau contractuelle de dYdX, le délai effectif du mode retrait forcé/capsule d’évacuation doit être réduit à 48 heures. De cette façon, les utilisateurs peuvent retirer des ressources de la couche 2 vers la couche 1 avant que le contrat ne soit mis à jour après avoir découvert que l’équipe du projet dYdX souhaite doper du code malveillant dans la nouvelle version du contrat.

À l’heure actuelle, la grande majorité des rollups qui ont lancé le mécanisme de retrait forcé/capsule d’évacuation ne remplissent pas les conditions ci-dessus. Par exemple, le délai de retrait/d’évasion obligatoire de dYdX est de 7 jours, mais le délai de mise à niveau du contrat du comité dYdX n’est que de 48 heures, ce qui signifie que le comité peut terminer le déploiement de nouveaux contrats avant que le retrait forcé de l’utilisateur ne prenne effet, et voler les actifs avant que l’utilisateur ne s’échappe.

De ce point de vue, à l’exception de Fuel, ZKSpace et Degate, les autres cumuls ne peuvent pas garantir que le retrait forcé de l’utilisateur sera traité avant la mise à niveau du contrat, et il existe un degré élevé de confiance dans l’hypothèse.

Bien que de nombreux projets qui adoptent le schéma de validation (DA est mis en œuvre hors chaîne sur Ethereum) aient un long délai de mise à niveau du contrat (par exemple, 8 jours ou plus), Validium s’appuie souvent sur des nœuds DAC hors chaîne pour publier les dernières données, et le DAC peut lancer une attaque de rétention de données pour invalider la fonction de retrait forcé, de sorte qu’il ne répond pas au modèle de sécurité discuté ci-dessus.

À ce stade, il semble clair et concis de conclure qu’aucune des solutions de couche 2, à l’exception de Fuel, ZKSpace et DeGate, n’est fiable. Les utilisateurs peuvent soit faire confiance au projet de couche 2 ou au comité de sécurité mis en place par celui-ci pour ne pas faire le mal, soit faire confiance aux nœuds DAC de la chaîne pour ne pas être de connivence, soit faire confiance au séquenceur pour ne pas examiner votre transaction (rejeter votre demande). Il n’y a que 3 couches 2 qui répondent vraiment aux exigences de sécurité, de résistance à la censure et d’absence de confiance.

La sécurité n’est pas seulement assurée par la technologie, mais doit l’être par consensus social

En fait, le sujet dont nous parlons aujourd’hui n’est pas nouveau, et l’essence de la couche 2 soulignée dans cet article dépend de la crédibilité de la partie du projet qui a été soulignée par d’innombrables personnes depuis longtemps. Par exemple, les fondateurs d’Avalanche et de Solana s’en sont pris à cela, mais le problème est que ces hypothèses de confiance qui existent dans la couche 2 existent également dans la couche 1 et dans tous les projets de blockchain.

Par exemple, nous devons supposer que les nœuds de validation qui représentent les 2/3 du poids de la mise dans le réseau Solana ne sont pas de connivence, et nous devons supposer que les deux premiers pools de minage, qui représentent la majorité de la puissance de hachage de Bitcoin, n’unissent pas leurs forces pour lancer une attaque à 51 % afin de faire reculer la plus longue chaîne. Bien que ces hypothèses soient difficiles à briser, « dur » ne signifie pas « non ».

Une fois qu’une chaîne publique traditionnelle de couche 1 a un comportement malveillant qui cause des dommages à un grand nombre d’actifs d’utilisateurs, elle abandonnera souvent la chaîne problématique et créera une nouvelle chaîne par consensus social (voir l’incident de 2016 The DAO qui a conduit au fork d’Ethereum en ETH et ETC). Si quelqu’un essaie de faire un fork malveillant, tout le monde devrait également choisir quel fork « plus fiable » suivre par consensus social. (Par exemple, la plupart des gens ne suivent pas le projet ETHW)

Le consensus social est la cause première pour assurer le bon fonctionnement des projets blockchain et même des protocoles DeFi qu’ils portent, même s’il s’agit d’un mécanisme de correction d’erreurs tel que l’audit du code de contrat et la divulgation des problèmes par les membres de la communauté dans un projet, il fait également partie du consensus social. Cependant, la décentralisation, qui est réalisée uniquement par la technologie, ne joue souvent pas le rôle le plus important et reste souvent au niveau théorique.

Ce qui joue vraiment un rôle à un moment critique, c’est souvent un consensus social qui n’a rien à voir avec la technologie, une supervision de l’opinion publique qui n’a rien à voir avec des articles académiques et une reconnaissance de masse qui n’a rien à voir avec les récits technologiques.

Nous pouvons imaginer le scénario suivant : une chaîne publique de prisonniers de guerre dont seulement quelques centaines de personnes ont entendu parler est temporairement dans un état hautement décentralisé, car il n’y a pas de domination d’une seule entreprise. Cependant, si une société de machines de minage investit soudainement toute sa puissance de calcul dans la chaîne POW, la puissance de calcul elle-même est plusieurs fois supérieure à celle de tous les autres mineurs, et à ce moment-là, la décentralisation de la chaîne POW sera désintégrée instantanément. Si l’entreprise de machines minières a l’intention de faire le mal, les gens ne peuvent corriger l’erreur que par le biais d’un consensus social.

D’autre part, la soi-disant couche 2, quelle que soit la conception élaborée de son mécanisme, ne peut pas éviter le lien du consensus social, même L2 tels que Fuel, DeGate et ZKSpace, que les responsables peuvent difficilement faire mal, la couche 1-Ethereum elle-même sur laquelle ils s’appuient dépend fortement du consensus social / de la supervision de la communauté et de l’opinion publique.

DE PLUS, NOUS PENSONS QUE LE CONTRAT N’EST PAS ÉVOLUTIF, CAR NOUS AVONS ÉCOUTÉ LES DÉCLARATIONS DES AUDITEURS DU CONTRAT ET DE L2BEAT, MAIS CES INSTITUTIONS PEUVENT ÊTRE NÉGLIGENTES OU MENTIR. Bien que cette probabilité soit extrêmement faible, nous devons admettre qu’une petite hypothèse de confiance a été introduite pour cela.

Cependant, la nature open-source de la blockchain elle-même permet à n’importe qui, y compris aux pirates, de vérifier si le contrat contient une logique malveillante, ce qui minimise en fait l’hypothèse de confiance, ce qui réduit considérablement le coût du consensus social. Si ce coût est suffisamment réduit, nous pouvons supposer qu’il s’agit d’un « trust less ».

Bien sûr, en plus des trois mentionnées ci-dessus, l’autre couche 2 n’a pas du tout ce que l’on appelle l’absence de confiance, et ce qui garantit vraiment la sécurité dans les moments critiques, c’est toujours le consensus social, et la composante technique est souvent juste pratique pour que les gens puissent effectuer une supervision du consensus social. Si un projet dispose d’une technologie supérieure, mais qu’il n’est pas largement reconnu et qu’il ne peut pas attirer une grande communauté, alors sa gouvernance décentralisée et son consensus social lui-même ne seront pas efficaces à développer.

La technologie est importante, mais le plus souvent, la capacité d’être largement reconnu et de développer une forte culture communautaire est un facteur plus important, plus précieux et plus propice au développement du projet que la technologie.

Nous pourrions aussi bien prendre zkRollup comme exemple, à l’heure actuelle, de nombreux zkRollups n’implémentent que le système de preuve de validité et les données DA sur la chaîne, ce qui peut prouver que toutes les transactions et transferts d’utilisateurs qu’ils traitent sont valides, non falsifiés par le séquenceur, et qu’il n’y a pas de mal en matière de « transition d’état », mais il n’y a pas qu’un seul scénario dans lequel le fonctionnaire ou le séquenceur de couche 2 est mauvais.

Nous pouvons estimer que le système de preuve ZK ne fait que réduire considérablement le coût de la supervision de la couche 2 par les gens, mais beaucoup de choses ne peuvent pas être résolues par la technologie elle-même, et doivent s’appuyer sur l’intervention de la gouvernance humaine ou du consensus social.

Si le fonctionnaire de L2 ne met pas en place des issues résistantes à la censure, telles que des retraits forcés, ou s’il tente de mettre à niveau le contrat et de le mélanger avec la logique selon laquelle les actifs des utilisateurs peuvent être volés, les membres de la communauté devront s’appuyer sur le consensus social et la fermentation de l’opinion publique pour corriger leurs erreurs. À l’heure actuelle, il semble que la supériorité de la technologie ne soit plus la plus importante, non pas tant si la technologie est importante pour la sécurité, mais plutôt la conception du mécanisme lui-même qui permet aux gens de réaliser un consensus social, ce qui est en fait le vrai sens de la couche 2 et même de la blockchain.

À partir de Blast, qui est supervisé uniquement par le consensus social, nous devrions examiner plus directement la relation entre le consensus social et la mise en œuvre technique, plutôt que de juger les mérites d’un projet en fonction de « quelle L2 est plus proche de la couche 2 que l’autre L2 ». Lorsqu’un projet a obtenu l’approbation et l’attention de millions de personnes, un consensus social s’est formé, et peu importe qu’il repose sur des récits marketing ou techniques, car le résultat lui-même est plus important que le processus.

Il est vrai que le consensus social lui-même est une extension de la politique démocratique, et le monde réel a confirmé les défauts de la gouvernance démocratique, mais l’open source et la transparence des données de la blockchain elle-même réduisent considérablement le coût du consensus social, de sorte que le « règne de l’homme » du Web3 est fondamentalement différent du « règne de l’homme » des pays souverains réels.

Si l’on considère la blockchain elle-même comme un moyen technique d’améliorer la question de la transparence de l’information dans la gouvernance démocratique, plutôt que de simplement poursuivre la « mise en œuvre sans confiance du code », jamais réalisable, tout semble beaucoup plus optimiste et clair. Ce n’est qu’en se débarrassant de l’arrogance et des préjugés que l’élite technique a corrigés et en adoptant un public plus large que le système Ethereum Layer2 peut vraiment devenir une infrastructure financière de classe mondiale pour une adoption massive.