Introduction : Le sous-texte de Blast face à des solutions Layer 2 orthodoxes telles que Polygon zkEVM pourrait être : « Les princes, les généraux et les ministres préféreraient-ils avoir les leurs ? » Puisque tout le monde n'est pas assez digne de confiance et dépend essentiellement du consensus social pour garantir la sécurité, pourquoi critiquer Blast ? La concentration de Layer 2 n'est pas assez élevée, alors pourquoi se précipiter ?

Il est vrai que le fait que Blast s’appuie sur des multi-signatures 3/5 pour contrôler les adresses de recharge a été largement critiqué, mais la plupart des couches 2 s’appuient également sur des multi-signatures pour gérer les contrats. Auparavant, Optimism n’utilisait même qu’une seule adresse EOA pour contrôler les autorisations de mise à niveau des contrats. À une époque où presque tous les Layer 2 grand public présentent des risques de sécurité tels que la multi-signature, critiquer Blast pour ne pas être assez sûr revient plus à « regarder de haut » un projet d’extraction d’or par les élites techniques.

Mais en dehors de la question de savoir lequel est meilleur entre les deux ci-dessus, la signification de l'existence de la blockchain est plus de résoudre le problème de l'opacité de l'information dans le consensus social/gouvernance démocratique. En prônant la suprématie de la technologie, nous devons admettre que le consensus social lui-même est plus important que la technologie. est important car c'est la base pour assurer le fonctionnement efficace de tous les projets Web3. En dernière analyse, la technologie sert le consensus social. Un projet qui ne peut pas être reconnu par la plupart des gens, peu importe à quel point la technologie est supérieure, est essentiellement juste un appendice magnifique.

Texte: Récemment, le nouveau projet Blast lancé par le fondateur de Blur est devenu populaire sur Internet. Ce protocole de "génération d'intérêts d'actifs" sous la bannière de Layer 2 a mis en place une adresse de recharge sur la chaîne ETH. Après que les utilisateurs aient déposé des fonds dans l'adresse Blast, ces fonds seront utilisés pour le jalonnement natif sur le réseau ETH, les plaçant dans MakerDAO pour gagner des intérêts, etc. Les bénéfices seront retournés aux utilisateurs.

S'appuyant sur l'aura du fondateur et un gameplay attrayant, Blast a reçu 20 millions de dollars de financement de la part d'investisseurs menés par Paradigm, et a également attiré la participation de nombreux investisseurs particuliers. En moins de 5 jours depuis son lancement, l'adresse de recharge de Blast a attiré plus de 400 millions de dollars de TVL. Il n'est pas exagéré de dire que Blast est comme une forte dose de médicament sur le long marché baissier, suscitant instantanément l'enthousiasme des gens.

Cependant, bien que Blast ait connu un succès initial, il a également suscité des doutes de la part de nombreux experts. Par exemple, L2BEAT et les ingénieurs de Polygon l'ont dit clairement : Le Blast actuel déploie uniquement le contrat de dépôt pour recevoir des recharges sur Ethereum. Ce contrat peut être mis à niveau sous le contrôle de 3/5 multi-signatures. En d'autres termes, la logique du code du contrat peut être réécrite, si vous voulez tromper, vous pouvez toujours tromper. En même temps, Blast prétend seulement mettre en œuvre la structure Rollup, mais pour l'instant c'est juste une coquille vide, et même la fonction de retrait ne sera pas lancée avant février de l'année prochaine.

La signature multi-niveau est un problème de longue date

En fait, la multi-signature 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 l’évolutivité du contrat Rollup. Ce que l’on appelle la « mise à niveau » consiste à modifier l’adresse logique du contrat pointée par le contrat de l’agent pour obtenir l’effet d’une modification de la logique du contrat. Si le nouveau contrat modifié contient une logique malveillante, les responsables de Layer2 peuvent voler les actifs des utilisateurs.

(Source: wtf academy)

Selon les données de L2BEAT, les rollups principaux actuels tels que Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM, etc. utilisent tous des contrats autorisés de mise à niveau multi-signatures, qui peuvent contourner les restrictions de verrouillage temporel et être mis à niveau immédiatement. (Vous pouvez lire les articles précédents de Geek Web3 :Le Jeu du Crédit : Rollups Contrôlés par des Multi-Signatures et des Comités )

Ce qui est surprenant, c’est qu’Optimism n’utilisait qu’une adresse EOA pour gérer les mises à niveau des contrats, et même les signatures multiples n’ont été ajoutées qu’en octobre de cette année. Quant à Polygon zkEVM, qui a critiqué Blast, il peut également procéder à une « prise de contrôle d’urgence » du contrat Rollup en vertu de l’autorisation multi-signature 6/8, transformant la couche 2 de la gouvernance contractuelle en une « 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 était vague.

Quelle est la signification de ce mode d'urgence? Pourquoi la plupart des Rollups se laissent-ils une touche de panique ou une porte dérobée? Selon la déclaration précédente de Vitalik, Rollup doit mettre à jour fréquemment les contrats déployés sur ETH pendant le processus d'itération. Sans l'introduction de moyens évolutifs tels que les contrats d'agence, il sera difficile d'itérer efficacement.

De plus, les contrats intelligents qui hébergent une grande quantité d'actifs peuvent présenter des bugs subtils, et l'équipe de développement de la couche 2 est inévitablement négligente. Si certaines vulnérabilités sont exploitées par des pirates informatiques, une grande quantité d'actifs peut être volée. Par conséquent, que ce soit la couche 2 ou les protocoles DeFi, un bouton d'urgence est souvent mis en place, et les "membres du comité" interviennent si nécessaire pour empêcher certains événements malveillants de se produire.

Bien sûr, le comité mis en place par Layer 2 peut souvent contourner les restrictions de verrouillage temporel et mettre à jour immédiatement le code du contrat. D'un certain point de vue, ils semblent être plus tabous que les facteurs externes tels que les pirates informatiques. En d'autres termes, dans tous les cas, les contrats intelligents qui hébergent d'énormes quantités d'actifs sont difficiles à éviter un certain degré d'« hypothèse de confiance », c'est-à-dire qu'il est supposé que le contrôleur multi-signature derrière le contrat ne fait pas de mal. À moins que le contrat ne soit conçu pour ne pas être actualisable et qu'il n'y ait pas de bugs pouvant menacer la sécurité des actifs des utilisateurs.

La situation actuelle est que le Layer 2 grand public actuel permet soit à son propre comité de mettre immédiatement à jour le contrat, soit d'introduire des restrictions relativement courtes de verrouillage temporel (par exemple, toute personne souhaitant mettre à jour le contrat dYdX devra attendre au moins 48 heures). S'il est découvert que le comité a l'intention d'incorporer une logique malveillante dans la nouvelle version du code du contrat pour voler des actifs, les utilisateurs auront théoriquement suffisamment de temps de réaction pour retirer en urgence leurs actifs du Layer 1.

(Pour des informations sur les retraits forcés et les fonctions de cabine d'évasion, vous pouvez lire notre article précédent " Quelle est l'importance des fonctions de retrait forcé et de cabine d'évacuation pour le Layer 2?“

(Le verrouillage temporel vous permet d'effectuer certaines opérations après un délai)

Mais le cœur du problème est que de nombreux Layer 2 n'ont même pas de fonction de retrait forcé qui puisse contourner le Séquenceur. Si les responsables du Layer 2 veulent faire quelque chose de mal, ils peuvent d'abord laisser le Séquenceur rejeter les demandes de retrait de tout le monde, puis diviser les actifs de l'utilisateur. Aller vers le compte L2 contrôlé par les responsables du Layer 2 eux-mêmes. Ensuite, l'officiel mettra à jour le contrat Rollup selon leurs propres besoins. Une fois le délai de verrouillage temporel écoulé, tous les actifs des utilisateurs peuvent être transférés vers la chaîne ETH.

Bien sûr, la situation réelle peut être pire que ce que j'ai dit, car la plupart des responsables de Rollup peuvent mettre à niveau les contrats sans restrictions de verrouillage temporel, ce qui signifie que des tapis d'une valeur de centaines de millions de dollars peuvent être complétés presque instantanément.

Un véritable Layer 2 sans confiance devrait faire en sorte que le délai de mise à jour du contrat soit supérieur au délai de retrait forcé.

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

Configurez une sortie de retrait résistante à la censure sur la couche 1, et les utilisateurs peuvent retirer 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 des utilisateurs puissent être retirés rapidement de L2 ;

Toute personne souhaitant mettre à niveau le contrat de la couche 2 doit être soumise à la limite de délai de verrouillage temporel, et la mise à niveau du contrat doit prendre effet après le retrait obligatoire. Par exemple, la mise à niveau du contrat de dYdX a actuellement un délai d'au moins 48 heures, donc le délai pour que le retrait forcé/le mode de sortie de secours prenne effet devrait être réduit à moins de 48 heures. De cette façon, après avoir découvert que l'équipe du projet dYdX souhaite incorporer un code malveillant dans la nouvelle version du contrat, les utilisateurs peuvent retirer leurs actifs de la couche 2 à la couche 1 avant la mise à jour du contrat.

Actuellement, la grande majorité des rollups qui ont lancé un mécanisme de cabine de retrait/évasion forcée ne remplissent pas les conditions ci-dessus. Par exemple, la trappe de retrait/évasion forcée de dYdX a un délai maximum de 7 jours, mais le délai de mise à niveau du contrat du comité dYdX n'est que de 48 heures. En d'autres termes, le comité peut terminer le déploiement du nouveau contrat avant que le retrait forcé de l'utilisateur ne prenne effet. Voler des actifs avant que l'utilisateur ne s'échappe.

De ce point de vue, à l'exception de Fuel, ZKSpace et Degate, les autres Rollups ne peuvent pas garantir que les retraits forcés des utilisateurs seront traités avant la mise à niveau du contrat, et il y a un degré élevé de présomption de confiance.

Bien que de nombreux projets utilisant la solution Validium (DA est implémenté en dehors de la chaîne Ethereum) aient de longs délais de mise à niveau des contrats (tels que 8 jours ou plus), Validium s’appuie souvent sur les nœuds DAC hors chaîne pour publier les données les plus récentes, et DAC peut lancer des attaques de rétention de données, désactiver la fonction de retrait forcé et donc ne pas être conforme au modèle de sécurité discuté ci-dessus. (Vous pouvez lire notre article précédent « Licencier Validium ? Reconsidérer la couche 2 du point de vue du proposant Danksharding “ )

À ce stade, nous semblons pouvoir tirer une conclusion concise et claire : les solutions de couche 2 autres que Fuel, ZKSpace et DeGate ne sont pas sans confiance. Les utilisateurs doivent soit faire confiance à la partie du projet de couche 2, soit au comité de sécurité mis en place par celle-ci pour ne pas faire de mal, soit faire confiance aux nœuds DAC hors chaîne pour ne pas colluder, soit faire confiance au séquenceur pour ne pas examiner votre transaction (rejeter votre demande). Il n'y a actuellement que les trois couches 2 susmentionnées qui répondent vraiment aux exigences de sécurité, de résistance à la censure et de sans confiance.

La sécurité n'est pas seulement assurée par la technologie, mais doit également introduire un consensus social

En fait, le sujet dont nous parlons aujourd'hui n'est pas nouveau. L'essence de Layer 2 indiquée dans cet article dépend de la crédibilité de la partie du projet, comme l'ont souligné d'innombrables personnes. Par exemple, les fondateurs d'Avalanche et de Solana ont vivement critiqué cela, mais le problème est que ces hypothèses de confiance qui existent dans Layer 2 existent également dans Layer 1 et même dans tous les projets blockchain.

Par exemple, nous devons supposer que les nœuds validateurs qui représentent les 2/3 du poids de l'engagement dans le réseau Solana ne collaborent pas, et nous devons supposer que les deux principaux pools de minage qui représentent la majorité de la puissance de calcul du Bitcoin ne s'unissent pas pour lancer une attaque à 51% afin de revenir en arrière sur la chaîne la plus longue. Bien que ces suppositions soient difficiles à briser, le terme "difficile" ne signifie pas "impossible".

Une fois qu'une chaîne publique traditionnelle de couche 1 commet un acte malveillant qui cause des dommages à un grand nombre d'actifs d'utilisateurs, elle abandonnera souvent la chaîne problématique et fork une nouvelle chaîne à travers le consensus social (voir l'incident du DAO en 2016 qui a conduit à la division d'Ethereum en ETH et ETC). Si quelqu'un tente un fork malveillant, tout le monde doit choisir quelle fourchette "plus fiable" suivre à travers le consensus social. (Par exemple, la plupart des gens ne suivent pas le parti du projet ETHW)

Le consensus social est à la base de garantir le fonctionnement ordonné des projets blockchain et même des protocoles DeFi qu'ils portent. Même les mécanismes de correction des erreurs tels que les audits de code de contrat et les membres de la communauté divulguant des problèmes avec un projet font également partie du consensus social. Cependant, la décentralisation réalisée uniquement par la technologie échoue souvent à jouer son plus grand rôle et reste souvent au niveau théorique.

Ce qui entre vraiment en jeu aux moments critiques 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 les articles académiques, et une reconnaissance de masse qui n'a rien à voir avec les récits techniques.

Nous pouvons imaginer le scénario suivant : une chaîne publique de preuve de travail (POW) que seuls quelques centaines de personnes ont entendu parler est temporairement dans un état hautement décentralisé car il n'y a pas encore eu de situation où une entreprise est dominante. Mais si une société minière investit soudainement toute sa puissance de calcul dans la chaîne POW, sa puissance de calcul sera plusieurs fois supérieure à celle de tous les autres mineurs. À ce moment-là, la décentralisation de cette chaîne POW s'effondrera instantanément. Si la société minière a l'intention de faire le mal, les gens ne pourront corriger l'erreur que par consensus social.

D'autre part, le soi-disant Layer 2, aussi sophistiqué soit-il dans sa conception mécanique, ne peut éviter le lien du consensus social. Même des L2 tels que Fuel, DeGate et ZKSpace, qui sont presque impossibles à corrompre, s'appuient fortement sur le consensus social/la supervision de l'opinion publique de la communauté sur le Layer 1-Ethereum sur lequel ils reposent.

De plus, nous croyons que le contrat ne peut pas être mis à niveau car nous avons écouté les soumissions de l'agence d'audit des contrats et de L2BEAT, mais ces agences peuvent être négligentes ou mentir. Bien que cette probabilité soit extrêmement faible, nous devons admettre qu'une petite supposition de confiance est encore introduite.

Cependant, la nature des données open source de la blockchain permet à quiconque, y compris aux pirates informatiques, de vérifier si le contrat contient une logique malveillante. En fait, l'hypothèse de confiance a été minimisée, ce qui réduit considérablement le coût du consensus social. Si ce coût est réduit à un niveau suffisamment bas, nous pouvons passer au mode "sans confiance".

Bien sûr, à l'exception des trois sociétés mentionnées ci-dessus, les autres solutions de couche 2 n'ont aucune prétendue confiance. Ce qui garantit vraiment la sécurité aux moments critiques, c'est toujours le consensus social. Le composant technique sert souvent simplement à faciliter la supervision du consensus social par les personnes. Si la technologie d'un projet est supérieure, mais qu'elle n'est pas largement reconnue et ne peut pas attirer un grand groupe de la communauté, alors sa gouvernance décentralisée et le consensus social lui-même auront du mal à se développer efficacement.

La technologie est en effet importante, mais plus souvent qu'autrement, le fait qu'elle puisse être largement reconnue et qu'elle puisse développer une culture communautaire forte sont des facteurs plus importants, plus précieux et plus propices au développement du projet que la technologie.

Prenons zkRollup comme exemple. Actuellement, de nombreux zkRollups implémentent uniquement le système de certification de validité et les données DA on-chain. Il peut prouver de manière externe que les transactions utilisateur qu'il gère et toutes les transferts effectués sont valides et non falsifiés par le séquenceur. Il n'y a pas de mal dans cette question de 'transition d'état', mais ce n'est pas le seul scénario où les officiels ou séquenceurs de Layer 2 agissent mal.

Nous pouvons approximer que le système de preuve ZK réduit essentiellement uniquement considérablement le coût de la supervision des gens de la couche 2, mais il y a beaucoup de choses qui ne peuvent pas être résolues par la technologie elle-même et qui doivent faire appel à l'intervention de la gouvernance humaine ou du consensus social.

Si les responsables de la couche 2 ne mettent pas en place des sorties anti-censure telles que des retraits forcés, ou s'ils tentent de mettre à niveau le contrat et d'incorporer une logique pouvant voler les actifs des utilisateurs, les membres de la communauté devront compter sur le consensus social et la fermentation de l'opinion publique pour corriger les erreurs. À ce moment-là, que la technologie soit supérieure ou non ne semble plus être le plus important. Plutôt que de dire que la technologie est importante pour la sécurité, il est plus important de dire que la conception du mécanisme lui-même qui facilite

À partir de Blast, qui s’appuie uniquement sur le consensus social pour la supervision, nous devrions examiner plus directement la relation entre le consensus social et la mise en œuvre technique, au lieu de simplement juger « quelle L2 est la plus proche de la couche 2 mentionnée par Vitalik que l’autre L2 » Déterminer les mérites d’un projet. Lorsqu’un projet a gagné la reconnaissance et l’attention de millions de personnes, un consensus social s’est formé. Peu importe qu’il s’agisse d’un discours marketing ou technique, 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 lacunes de la gouvernance démocratique. Cependant, la transparence des données et des sources ouvertes de la blockchain ont considérablement réduit le coût du consensus social. Par conséquent, il existe une différence essentielle entre le "gouvernement par l'homme" et le "gouvernement par l'homme" dans les États souverains réels.

Si nous considérons la blockchain elle-même comme un moyen technique d'améliorer les problèmes de transparence de l'information dans la gouvernance démocratique, plutôt que de simplement poursuivre la « Confiance atteinte uniquement par le code » qui est jamais à portée de main, tout semble devenir beaucoup plus optimiste et clair. Ce n'est qu'en se débarrassant de l'arrogance et des préjugés inhérents à l'élite technique et en embrassant un public plus large que le système Ethereum Layer 2 peut vraiment devenir une infrastructure financière de classe mondiale avec une adoption de masse.

Avertissement：

1. Cet article est reproduit à partir de [Compte WeChat : Geek Web3]. Tous les droits d’auteur appartiennent à l’auteur original [Faust]. Si des objections sont soulevées concernant cette réimpression, veuillez contacter le Portail Apprendrel'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.