Introduction : Depuis le déclin progressif de Solana et la sortie de Token par OP, Layer2 et Rollup semblent être devenus les nouveaux refuges pour d'innombrables praticiens du Web3. Alors que le marché baissier continue de se propager, FTX est hors jeu et Multicoin subit de lourdes pertes, les concurrents d'Ethereum ont progressivement disparu de la scène Web3 et ils ont continuellement perdu la confiance nécessaire pour rivaliser avec ETH. De plus en plus de gens ont commencé à considérer Rollup comme le cœur d'une nouvelle série de récits, et de plus en plus de projets ont surgi sur L2 comme des champignons après la pluie.
Mais est-ce que toute cette "fausse prospérité" ou une "bulle qui peut éclater à tout moment" ? Rollup et L2 sont-ils vraiment aussi bons que la plupart des gens le prétendent ? Est-ce vraiment aussi sûr que les gens le pensent ? Sans oublier que de nombreux OP Rollups n'ont pas de preuves de fraude, quels sont les risques de sécurité des ** Rollups ? **
Inspiré par le "Upgradeability of Ethereum L2s" récemment publié par L2BEAT, cet article se concentre sur les risques de multi-signature et de confiance du comité derrière la mise à niveau du Rollup (mise à niveau immédiate du contrat Rollup, enlevant les actifs de l'utilisateur) et les clichés précédents sur le Rollup. Rappelant le récent Multichain, nous expliquerons pourquoi L2 n'est pas aussi "beau" que beaucoup de gens le pensent.
Brève description du principe du Rollup
Une brève description du principe de fonctionnement de Rollup :
** Ethereum Rollup = un ensemble de contrats sur les propres nœuds du réseau Layer1 + Layer2. **
Le groupe de nœuds de réseau de couche 2 peut être divisé en plusieurs types de rôles, dont le plus important est le séquenceur (Sequencer). Il reçoit les demandes de transaction qui se produisent sur Layer2, détermine leur ordre d'exécution, puis regroupe la séquence de transaction dans un lot (Batch), qui est envoyé au contrat du projet Rollup sur Layer1 (ci-après collectivement dénommé contrat Rollup).
Le nœud complet de Layer2 peut obtenir directement la séquence de transactions du séquenceur, ou lire le lot de transactions (Batch) envoyé par le séquenceur à Layer1, mais ce dernier a une plus grande certitude finale (inchangeable) que le premier. Habituellement, lorsqu'un lot de transactions est envoyé à Layer1 par le séquenceur, l'ordre du lot de transactions ne peut pas être modifié (tant qu'il n'y a pas de bloc rollback dans Ethereum, la séquence de transaction de Rollup ne changera pas).
Étant donné que l'exécution des transactions modifiera l'état du registre de la blockchain, en plus de l'ordre des transactions, le nœud complet de couche 2 doit également synchroniser l'état du registre avec le séquenceur, afin d'assurer la cohérence.
Par conséquent, le séquenceur doit non seulement transmettre les lots de transactions au contrat Rollup de Layer1, mais également transmettre les résultats de la mise à jour de l'état (Stateroot/State diff) après l'exécution de la transaction à Layer1.
Il n'est pas difficile de voir que L1 (Ethereum) agit en fait comme un tableau d'affichage pour les nœuds L2, qui est beaucoup plus décentralisé, sans confiance et plus sûr que le propre réseau de L2. Pour les nœuds complets L2, tant qu'ils obtiennent la séquence de transaction Rollup sur L1 + le Stateroot initial, ils peuvent restaurer le registre de la blockchain L2 et calculer le dernier Stateroot. Si le Stateroot calculé par le nœud complet L2 lui-même est incohérent avec le Stateroot publié par le séquenceur à L1, cela signifie que le séquenceur a fraude.
Le cas hypothétique le plus intuitif est le suivant : le séquenceur de L2 peut voler les actifs de l'utilisateur. Par exemple, peut-il falsifier certaines transactions qui ne devraient pas se produire (ps : transférez certains jetons d'utilisateur L2 à l'adresse de l'opérateur du séquenceur, puis transférez ces jetons vers L1). Ce genre de question peut se résumer à : que faire après que le séquenceur a publié de mauvaises données de transaction ou un mauvais Stateroot ? **
Pour le risque de fraude du séquenceur, différents types de Rollup ont différentes contre-mesures. Optimistic Rollup (Optimistic Rollup) permet aux nœuds complets L2 de fournir des preuves de fraude (Fraud Proof), prouvant que les données publiées par le séquenceur en L1 comportent des erreurs. Par exemple, Arbitrum a mis en place une liste blanche de nœuds, permettant aux nœuds L2 de la liste blanche d'émettre des preuves de fraude.
De plus, étant donné que ** la plupart des échanges et des parties privées du projet de pont inter-chaînes exécuteront des nœuds complets L2 **, les erreurs peuvent être trouvées immédiatement, et le taux de réussite de la plupart des séquenceurs Rollup qui volent des pièces est fondamentalement de 0 (car il doit être encaissé à la fin, il doit encore être complété sur l'échange, ou les pièces volées peuvent être transférées vers L1 puis trouver une autre issue).
(L'agrégateur sur la figure est en fait un séquenceur)
Mais pour Optimism sans preuve de fraude, le séquenceur peut voler des pièces via le propre contrat de pont inter-chaînes de Rollup. Par exemple, l'opérateur du séquenceur peut falsifier des instructions de transaction, transférer les actifs d'autres personnes dans L2 à leur propre adresse, puis transférer les pièces volées à L1 via le contrat de pont intégré de Rollup. Parce qu'il n'y a pas de preuve de fraude, le nœud complet de l'OP ne peut pas contester la mauvaise transaction, donc en théorie, ** le séquenceur de l'OP peut voler les actifs de l'utilisateur en L2 ** (tant qu'il le veut vraiment).
La solution à ce type de problème est le ** "consensus social" ** (supervisé par l'opinion publique, comme les membres de la communauté et les médias sociaux), ou ** s'appuyant sur l'approbation de crédit officielle d'OP. **
Fait intéressant, un échange a récemment réduit le délai pour les utilisateurs d'Arbitrum et d'Optimisme pour transférer des pièces vers l'échange (de 100 blocs L2 à 1 bloc L2), ce qui consiste en fait à croire que les séquenceurs d'ARB et OP ne feront pas de mal ** (par défaut, ce sont des serveurs centralisés avec approbation officielle) **.
Contrairement à Rollup optimiste, en plus de s'appuyer sur des nœuds complets L2, ZK Rollup résout le problème de la fraude au séquenceur grâce à Validity Proof (souvent confondu avec ZK Proof). Il existe un nœud appelé Prover dans le réseau ZK Rollup, qui est conçu pour générer des preuves de validité pour les lots de transactions émis par le séquenceur. Parallèlement, il existe un contrat (généralement appelé Verifier) sur L1 qui vérifie spécifiquement la validité du certificat. Tant que le lot de transaction et le certificat correspondant à Stateroot/State diff passent la vérification du contrat Verifier, il sera finalisé (Finalized). Le pont officiel de ZK Rollup ne libérera que les transactions de retrait vérifiées par le certificat de validité, ce qui est évidemment beaucoup plus fiable qu'Optimism.
En théorie, la sécurité d'OP Rollup est garantie par des nœuds complets L2 (au moins un nœud honnête pouvant émettre des preuves de fraude). La sécurité de ZK Rollup est garantie par le contrat Verifier sur L1 (la transaction est finalement confirmée par le nœud L1). En surface, ils peuvent tous "hériter de la sécurité de L1" (avec l'aide de L1 pour compléter la confirmation/règlement final de la transaction), et les maximalistes d'Ethereum l'appellent même "équivalent à la sécurité de L1" (cohérent avec la finalité des résultats de la transaction de L1), mais la situation réelle n'est pas le cas, ou même loin de là.
Ces points "clichés"
Tout d'abord, la vitesse de génération de preuves de validité de ZK Rollup est extrêmement lente, le séquenceur peut exécuter des milliers de transactions en 1 seconde, mais cela peut prendre plusieurs heures au maximum pour générer des preuves pour ces milliers de transactions. Mais ce problème est également facile à résoudre.Le ZKR grand public divise essentiellement la tâche de génération de preuve et l'envoie à différents nœuds de preuve pour un traitement parallèle afin d'augmenter considérablement la vitesse de génération de preuve.
Deuxièmement, il est nécessaire de prendre en compte le délai de publication des données des nœuds L2 dans L1. Parce que chaque fois que le séquenceur ou le prouveur envoie des données à L1, il y aura un coût fixe (comme un conteneur est consommé pour chaque expédition). La publication fréquente de données sur L1 n'est pas rentable ou même à perte, de sorte que le séquenceur et le prouveur minimiseront la fréquence de publication des données sur L1, puis regrouperont et publieront une grande quantité de données en une seule fois.
En d'autres termes, lorsque le nombre d'utilisateurs est insuffisant et que le nombre de transactions initiées est insuffisant, le séquenceur retardera la libération des données vers L1. Par exemple, alors qu'il y avait peu d'utilisateurs l'année dernière, Optimism n'envoyait un lot de transactions à L1 que toutes les demi-heures. Maintenant, parce que le nombre d'utilisateurs a augmenté, ce problème a été efficacement résolu. Différent de l'OP, Starknet a adopté une méthode de réduction de la fréquence des publications de différences d'État pour réduire les coûts de données, ce qui prolonge le délai de confirmation finale de la transaction de Starknet à 7-8 heures.
De plus, la plupart des ZK Rollups "agrègent souvent de nombreuses épreuves et les envoient à L1 en même temps" afin de réduire davantage les coûts. C'est-à-dire que le prouveur n'enverra pas à L1 immédiatement après avoir généré une preuve, mais attendra que plusieurs preuves soient générées, les agrègent ensemble, puis les envoient au contrat de vérification de L1. (En fait, le processus d'agrégation des preuves consiste à utiliser une preuve pour inclure les étapes de calcul générées par la vérification de plusieurs preuves)
La conséquence en est que la fréquence des versions de preuve est encore réduite et que le délai entre le lancement de la transaction et la confirmation finale est encore allongé.
Selon l'explorateur de blocs, ** le délai de confirmation de transaction de Polygon ZKEVM est d'environ 30 à 50 minutes, et Starknet et Zksync Era sont de plus de 7 heures. ** Évidemment, il ne s'agit que "d'hériter partiellement de la sécurité de L1", ce qui est loin de "l'équivalent de sécurité de L1" selon les partisans d'Ethereum.
Bien sûr, les problèmes ci-dessus peuvent tous être résolus par le progrès technologique et seront réalisés dans un proche avenir. Par exemple, de nombreuses parties au projet développent du matériel haute performance pour réduire le temps de génération des preuves de validité ; Optimism promet également de publier bientôt un système anti-fraude ; la solution Danksharding d'Ethereum réduira le coût des données de Rollup de plusieurs dizaines de fois, voire plus, ce qui peut résoudre efficacement les problèmes énumérés ci-dessus.
Difficile de résoudre le problème de la "règle de l'homme"
A l'instar des projets applicatifs tels que Defi, le fonctionnement du réseau Rollup dépend des contrats concernés sur L1, et ces contrats sont "évolutifs", ce qui signifie que certains codes peuvent être remplacés (la plupart des Rollups utilisent des contrats proxy), et peuvent être réalisés immédiatement sous autorisation de multi-signature ou comité de sécurité. Permettez-moi de parler d'abord de la conclusion : ** Rollup peut rapidement modifier le code du contrat sur L1 via un comité de signatures multiples ou de sécurité contrôlé par quelques personnes, puis voler les actifs des utilisateurs. **
Tout d'abord, "pourquoi le contrat Rollup doit être mis à jour" et "comment est-il mis à jour". Le code de contrat sur Ethereum ne peut pas être modifié après le déploiement, mais Rollup présente inévitablement divers bogues au cours du processus de développement, ce qui peut entraîner des résultats erronés ; en même temps, Rollup subit également de fréquentes itérations de produits et de nouvelles fonctions doivent être ajoutées fréquemment ; dans des cas plus extrêmes, des pirates informatiques peuvent attaquer le contrat Rollup, de sorte que le contrat Rollup doit être évolutif, ce qui est souvent réalisé par le biais de contrats de proxy.
Le contrat proxy est en fait une méthode couramment utilisée dans le développement de contrats Ethereum, qui consiste à séparer les données du contrat de la logique métier et à les stocker dans différents contrats. Les données (variables d'état) sont stockées dans des contrats de proxy et la logique métier (fonctions) est stockée dans des contrats logiques. Le contrat de proxy (Proxy) confie le processus d'exécution de la fonction au contrat logique (Implementation) via l'appel délégué, puis renvoie le résultat final à l'appelant (Caller).
Pour mettre à jour le contrat en mode proxy, il suffit de faire pointer le contrat proxy vers le nouveau contrat logique (réécrire l'adresse du contrat logique stockée dans le contrat proxy). ** La plupart des projets Rollup ont adopté cette méthode de mise à niveau contractuelle, qui peut être décrite comme simple et grossière. **
Il n'est pas difficile d'imaginer que le contrat de Rollup peut être mis à jour est en fait un énorme tonnerre : si le contrat mis à jour contient du code malveillant, comme modifier les conditions de libération du retrait du contrat Bridge intégré de Rollup, ou modifier les conditions du contrat Verifier pour déterminer la validité et prouver l'exactitude, le séquenceur peut voler des pièces (le principe est mentionné plus haut).
Mais le problème est que le contrat Rollup ne peut pas être mis à niveau, et la raison en est très claire. Dans l'ensemble, la grande majorité de Rollup décidera de mettre à niveau le contrat Rollup via la gouvernance DAO, le comité de sécurité ou l'autorisation multi-signatures. De plus, le verrouillage horaire Timelock sera utilisé pour définir une période de délai pour les mises à niveau du contrat.
Considérant que la plupart des propositions DAO ont un processus d'exécution automatisé (mis en œuvre via des contrats en chaîne), même si le contrat doit être mis à niveau, suffisamment de votes doivent d'abord être obtenus, puis l'opération de mise à niveau du contrat ne sera exécutée qu'après le délai spécifié par le Timelock (souvent plusieurs jours). Si quelqu'un veut s'engager dans des mises à niveau de contrat malveillantes, il doit surmonter la gouvernance DAO par des attaques de gouvernance (telles que les attaques de gouvernance qui se sont produites sur Tornado Cash), mais le coût de le faire est très élevé et il doit d'abord obtenir suffisamment de jetons, ce qui ne réussira pas dans des circonstances normales. Même si l'attaque de gouvernance réussit, en raison du blocage du temps, les utilisateurs auront suffisamment de temps pour retirer des actifs de L2, et **Les responsables du Rollup auront suffisamment de temps pour prendre des mesures d'urgence. **
Il semble que les timelocks soient l'arme magique contre les mises à niveau de contrats malveillantes. Mais le problème est que les soi-disant ** "mesures d'urgence que les responsables du Rollup peuvent prendre" ** contournent en fait la gouvernance du DAO et les verrous horaires, et mettent immédiatement à niveau le contrat Rollup via une autorisation multi-signature ou du comité de sécurité. Considérant que le Rollup grand public actuel héberge des milliards de dollars d'actifs utilisateurs, la "mise à niveau immédiate du contrat" autorisée par le comité multi-signatures et sécurité est la mesure d'urgence ultime, mais c'est aussi l'épée de Damoclès suspendue au-dessus de la tête de tous les utilisateurs.
Évidemment, il s'agit de maximiser la confiance : vous devez avoir confiance que les responsables de Rollup n'auront pas l'idée de vous voler vos avoirs. Si vous le considérez du point de vue de Trustless (du point de vue de Nick Szabo), **tous les Rollups contrôlés par des comités multi-signatures et de sécurité ne sont pas sécurisés. **Emin Gun Sirer, le fondateur d'Avalanche, Anatoly, le fondateur de Solana, et Justin Bons, la célèbre tache solaire, ont tous insisté sur ce genre de problème.
Quels Rolllups sont manipulés par les multisigs/comités ?
Selon le rapport "Upgradeability of Ethereum L2s" publié par la célèbre institution de recherche L2 L2 BEAT et le site Web de visualisation de données L2BEAT, ** Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM et d'autres Rollups grand public ont tous des contrats évolutifs multi-signatures ou autorisés par le comité, et peuvent contourner les restrictions de verrouillage horaire. **
Bien que dYdX ait une adresse EOA qui peut contourner le contrat de mise à jour de la gouvernance DAO, elle est limitée par un blocage horaire (au moins 2 jours de délai). Immutable X a un délai de mise à niveau du contrat de 14. Par conséquent, selon L2BEAT, ** dYdX et Immutable X sont plus fiables que les autres rollups traditionnels qui ont lancé le réseau principal. **
** Alors, comment réduire le risque de confiance apporté par la multi-signature et le comité de sécurité ? ** La réponse est en fait similaire à l'incident de Multichain : elle peut être attribuée au problème anti-sorcière. Il faut s'assurer que les multisigs/comités sont contrôlés par plusieurs entités différentes sans degré élevé de chevauchement d'intérêts et avec un faible risque de collusion. À l'heure actuelle, il semble qu'il n'y ait pas d'autre moyen que d'accroître la maturité de la gouvernance décentralisée de DAO et d'inviter des célébrités ou des institutions célèbres et réputées à participer à plusieurs signatures/comités. Le scénario ci-dessus semble avoir été courant dans les démocraties du monde réel.
Bien sûr, il est également possible de limiter le comportement de mise à niveau du contrat géré par la multi-signature/comité via le blocage du temps, mais cela doit être mis en balance avec de nombreux facteurs, car le but de la multi-signature/comité est de faire face rapidement à certaines situations d'urgence ; en même temps, si la partie du projet Rollup n'a pas une détermination ferme sur la question de la non-confiance, ce problème ne peut pas être résolu.
Par conséquent, bien que différents projets Rollup puissent garantir la sécurité des actifs des utilisateurs la plupart du temps grâce à une conception de mécanisme sophistiquée, la probabilité d'un événement de cygne noir dans Rollup n'est pas nulle en raison de l'existence de multi-signatures et de comités. Même si la probabilité de collusion multi-signatures et membres de comité n'est que de 1 sur 10 000, compte tenu de la valeur des actifs sous garde L2 (supposée être de 10 milliards de dollars américains), le risque des actifs des utilisateurs L2 est toujours aussi élevé que 1 million de dollars américains par jour. Rappelant l'incident de Multichain, c'est vraiment effrayant.
Je pense donc personnellement que, comme Polynya l'a déjà dit, la plupart des fonds de l'écosystème Ethereum auront toujours tendance à circuler et à se verrouiller en L1 plutôt qu'en L2, et l'écosystème Rollup ne pourra pas capturer la majeure partie de la valeur de l'écosystème Ethereum à long terme. Pour les grands investisseurs et les baleines, le réseau principal Ethereum est évidemment un endroit plus approprié et plus fiable pour obtenir des fonds que L2. Par conséquent, beaucoup de gens se sont demandé "si la montée en puissance de la L2 conduirait à l'abandon de la L1", en fait, ils ont déjà la réponse.
Comme Keigo Higashino l'a dit dans son livre, le cœur humain est beaucoup plus insaisissable, plus difficile à comprendre, plus compliqué et plus difficile à modifier que les formules mathématiques. Beaucoup de choses ne peuvent pas être résolues par des moyens purement techniques, mais tout facteur impliquant la "nature humaine" sera toujours le problème le plus incontrôlable, imprévisible et le plus grave du monde. Ici, s'il vous plaît, gardons à l'esprit la phrase classique sur la pierre tombale de Kant :
"Deux choses ont toujours entouré mon esprit, et plus j'y pense, plus elles évoquent en moi de l'étonnement et de la crainte : la loi morale à l'intérieur et le ciel étoilé au-dessus.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Le plus grand risque de confiance de Rollup : le problème de la « règle de l'homme » qui ne peut être ignoré
Auteur : Lien, Geek Web3
Introduction : Depuis le déclin progressif de Solana et la sortie de Token par OP, Layer2 et Rollup semblent être devenus les nouveaux refuges pour d'innombrables praticiens du Web3. Alors que le marché baissier continue de se propager, FTX est hors jeu et Multicoin subit de lourdes pertes, les concurrents d'Ethereum ont progressivement disparu de la scène Web3 et ils ont continuellement perdu la confiance nécessaire pour rivaliser avec ETH. De plus en plus de gens ont commencé à considérer Rollup comme le cœur d'une nouvelle série de récits, et de plus en plus de projets ont surgi sur L2 comme des champignons après la pluie.
Mais est-ce que toute cette "fausse prospérité" ou une "bulle qui peut éclater à tout moment" ? Rollup et L2 sont-ils vraiment aussi bons que la plupart des gens le prétendent ? Est-ce vraiment aussi sûr que les gens le pensent ? Sans oublier que de nombreux OP Rollups n'ont pas de preuves de fraude, quels sont les risques de sécurité des ** Rollups ? **
Inspiré par le "Upgradeability of Ethereum L2s" récemment publié par L2BEAT, cet article se concentre sur les risques de multi-signature et de confiance du comité derrière la mise à niveau du Rollup (mise à niveau immédiate du contrat Rollup, enlevant les actifs de l'utilisateur) et les clichés précédents sur le Rollup. Rappelant le récent Multichain, nous expliquerons pourquoi L2 n'est pas aussi "beau" que beaucoup de gens le pensent.
Brève description du principe du Rollup
Une brève description du principe de fonctionnement de Rollup :
** Ethereum Rollup = un ensemble de contrats sur les propres nœuds du réseau Layer1 + Layer2. **
Le groupe de nœuds de réseau de couche 2 peut être divisé en plusieurs types de rôles, dont le plus important est le séquenceur (Sequencer). Il reçoit les demandes de transaction qui se produisent sur Layer2, détermine leur ordre d'exécution, puis regroupe la séquence de transaction dans un lot (Batch), qui est envoyé au contrat du projet Rollup sur Layer1 (ci-après collectivement dénommé contrat Rollup).
Le nœud complet de Layer2 peut obtenir directement la séquence de transactions du séquenceur, ou lire le lot de transactions (Batch) envoyé par le séquenceur à Layer1, mais ce dernier a une plus grande certitude finale (inchangeable) que le premier. Habituellement, lorsqu'un lot de transactions est envoyé à Layer1 par le séquenceur, l'ordre du lot de transactions ne peut pas être modifié (tant qu'il n'y a pas de bloc rollback dans Ethereum, la séquence de transaction de Rollup ne changera pas).
Étant donné que l'exécution des transactions modifiera l'état du registre de la blockchain, en plus de l'ordre des transactions, le nœud complet de couche 2 doit également synchroniser l'état du registre avec le séquenceur, afin d'assurer la cohérence.
Par conséquent, le séquenceur doit non seulement transmettre les lots de transactions au contrat Rollup de Layer1, mais également transmettre les résultats de la mise à jour de l'état (Stateroot/State diff) après l'exécution de la transaction à Layer1.
Il n'est pas difficile de voir que L1 (Ethereum) agit en fait comme un tableau d'affichage pour les nœuds L2, qui est beaucoup plus décentralisé, sans confiance et plus sûr que le propre réseau de L2. Pour les nœuds complets L2, tant qu'ils obtiennent la séquence de transaction Rollup sur L1 + le Stateroot initial, ils peuvent restaurer le registre de la blockchain L2 et calculer le dernier Stateroot. Si le Stateroot calculé par le nœud complet L2 lui-même est incohérent avec le Stateroot publié par le séquenceur à L1, cela signifie que le séquenceur a fraude.
Le cas hypothétique le plus intuitif est le suivant : le séquenceur de L2 peut voler les actifs de l'utilisateur. Par exemple, peut-il falsifier certaines transactions qui ne devraient pas se produire (ps : transférez certains jetons d'utilisateur L2 à l'adresse de l'opérateur du séquenceur, puis transférez ces jetons vers L1). Ce genre de question peut se résumer à : que faire après que le séquenceur a publié de mauvaises données de transaction ou un mauvais Stateroot ? **
Pour le risque de fraude du séquenceur, différents types de Rollup ont différentes contre-mesures. Optimistic Rollup (Optimistic Rollup) permet aux nœuds complets L2 de fournir des preuves de fraude (Fraud Proof), prouvant que les données publiées par le séquenceur en L1 comportent des erreurs. Par exemple, Arbitrum a mis en place une liste blanche de nœuds, permettant aux nœuds L2 de la liste blanche d'émettre des preuves de fraude.
De plus, étant donné que ** la plupart des échanges et des parties privées du projet de pont inter-chaînes exécuteront des nœuds complets L2 **, les erreurs peuvent être trouvées immédiatement, et le taux de réussite de la plupart des séquenceurs Rollup qui volent des pièces est fondamentalement de 0 (car il doit être encaissé à la fin, il doit encore être complété sur l'échange, ou les pièces volées peuvent être transférées vers L1 puis trouver une autre issue).
(L'agrégateur sur la figure est en fait un séquenceur)
Mais pour Optimism sans preuve de fraude, le séquenceur peut voler des pièces via le propre contrat de pont inter-chaînes de Rollup. Par exemple, l'opérateur du séquenceur peut falsifier des instructions de transaction, transférer les actifs d'autres personnes dans L2 à leur propre adresse, puis transférer les pièces volées à L1 via le contrat de pont intégré de Rollup. Parce qu'il n'y a pas de preuve de fraude, le nœud complet de l'OP ne peut pas contester la mauvaise transaction, donc en théorie, ** le séquenceur de l'OP peut voler les actifs de l'utilisateur en L2 ** (tant qu'il le veut vraiment).
La solution à ce type de problème est le ** "consensus social" ** (supervisé par l'opinion publique, comme les membres de la communauté et les médias sociaux), ou ** s'appuyant sur l'approbation de crédit officielle d'OP. **
Fait intéressant, un échange a récemment réduit le délai pour les utilisateurs d'Arbitrum et d'Optimisme pour transférer des pièces vers l'échange (de 100 blocs L2 à 1 bloc L2), ce qui consiste en fait à croire que les séquenceurs d'ARB et OP ne feront pas de mal ** (par défaut, ce sont des serveurs centralisés avec approbation officielle) **.
Contrairement à Rollup optimiste, en plus de s'appuyer sur des nœuds complets L2, ZK Rollup résout le problème de la fraude au séquenceur grâce à Validity Proof (souvent confondu avec ZK Proof). Il existe un nœud appelé Prover dans le réseau ZK Rollup, qui est conçu pour générer des preuves de validité pour les lots de transactions émis par le séquenceur. Parallèlement, il existe un contrat (généralement appelé Verifier) sur L1 qui vérifie spécifiquement la validité du certificat. Tant que le lot de transaction et le certificat correspondant à Stateroot/State diff passent la vérification du contrat Verifier, il sera finalisé (Finalized). Le pont officiel de ZK Rollup ne libérera que les transactions de retrait vérifiées par le certificat de validité, ce qui est évidemment beaucoup plus fiable qu'Optimism.
En théorie, la sécurité d'OP Rollup est garantie par des nœuds complets L2 (au moins un nœud honnête pouvant émettre des preuves de fraude). La sécurité de ZK Rollup est garantie par le contrat Verifier sur L1 (la transaction est finalement confirmée par le nœud L1). En surface, ils peuvent tous "hériter de la sécurité de L1" (avec l'aide de L1 pour compléter la confirmation/règlement final de la transaction), et les maximalistes d'Ethereum l'appellent même "équivalent à la sécurité de L1" (cohérent avec la finalité des résultats de la transaction de L1), mais la situation réelle n'est pas le cas, ou même loin de là.
Ces points "clichés"
Tout d'abord, la vitesse de génération de preuves de validité de ZK Rollup est extrêmement lente, le séquenceur peut exécuter des milliers de transactions en 1 seconde, mais cela peut prendre plusieurs heures au maximum pour générer des preuves pour ces milliers de transactions. Mais ce problème est également facile à résoudre.Le ZKR grand public divise essentiellement la tâche de génération de preuve et l'envoie à différents nœuds de preuve pour un traitement parallèle afin d'augmenter considérablement la vitesse de génération de preuve.
Deuxièmement, il est nécessaire de prendre en compte le délai de publication des données des nœuds L2 dans L1. Parce que chaque fois que le séquenceur ou le prouveur envoie des données à L1, il y aura un coût fixe (comme un conteneur est consommé pour chaque expédition). La publication fréquente de données sur L1 n'est pas rentable ou même à perte, de sorte que le séquenceur et le prouveur minimiseront la fréquence de publication des données sur L1, puis regrouperont et publieront une grande quantité de données en une seule fois.
En d'autres termes, lorsque le nombre d'utilisateurs est insuffisant et que le nombre de transactions initiées est insuffisant, le séquenceur retardera la libération des données vers L1. Par exemple, alors qu'il y avait peu d'utilisateurs l'année dernière, Optimism n'envoyait un lot de transactions à L1 que toutes les demi-heures. Maintenant, parce que le nombre d'utilisateurs a augmenté, ce problème a été efficacement résolu. Différent de l'OP, Starknet a adopté une méthode de réduction de la fréquence des publications de différences d'État pour réduire les coûts de données, ce qui prolonge le délai de confirmation finale de la transaction de Starknet à 7-8 heures.
De plus, la plupart des ZK Rollups "agrègent souvent de nombreuses épreuves et les envoient à L1 en même temps" afin de réduire davantage les coûts. C'est-à-dire que le prouveur n'enverra pas à L1 immédiatement après avoir généré une preuve, mais attendra que plusieurs preuves soient générées, les agrègent ensemble, puis les envoient au contrat de vérification de L1. (En fait, le processus d'agrégation des preuves consiste à utiliser une preuve pour inclure les étapes de calcul générées par la vérification de plusieurs preuves)
La conséquence en est que la fréquence des versions de preuve est encore réduite et que le délai entre le lancement de la transaction et la confirmation finale est encore allongé.
Selon l'explorateur de blocs, ** le délai de confirmation de transaction de Polygon ZKEVM est d'environ 30 à 50 minutes, et Starknet et Zksync Era sont de plus de 7 heures. ** Évidemment, il ne s'agit que "d'hériter partiellement de la sécurité de L1", ce qui est loin de "l'équivalent de sécurité de L1" selon les partisans d'Ethereum.
Bien sûr, les problèmes ci-dessus peuvent tous être résolus par le progrès technologique et seront réalisés dans un proche avenir. Par exemple, de nombreuses parties au projet développent du matériel haute performance pour réduire le temps de génération des preuves de validité ; Optimism promet également de publier bientôt un système anti-fraude ; la solution Danksharding d'Ethereum réduira le coût des données de Rollup de plusieurs dizaines de fois, voire plus, ce qui peut résoudre efficacement les problèmes énumérés ci-dessus.
Difficile de résoudre le problème de la "règle de l'homme"
A l'instar des projets applicatifs tels que Defi, le fonctionnement du réseau Rollup dépend des contrats concernés sur L1, et ces contrats sont "évolutifs", ce qui signifie que certains codes peuvent être remplacés (la plupart des Rollups utilisent des contrats proxy), et peuvent être réalisés immédiatement sous autorisation de multi-signature ou comité de sécurité. Permettez-moi de parler d'abord de la conclusion : ** Rollup peut rapidement modifier le code du contrat sur L1 via un comité de signatures multiples ou de sécurité contrôlé par quelques personnes, puis voler les actifs des utilisateurs. **
Tout d'abord, "pourquoi le contrat Rollup doit être mis à jour" et "comment est-il mis à jour". Le code de contrat sur Ethereum ne peut pas être modifié après le déploiement, mais Rollup présente inévitablement divers bogues au cours du processus de développement, ce qui peut entraîner des résultats erronés ; en même temps, Rollup subit également de fréquentes itérations de produits et de nouvelles fonctions doivent être ajoutées fréquemment ; dans des cas plus extrêmes, des pirates informatiques peuvent attaquer le contrat Rollup, de sorte que le contrat Rollup doit être évolutif, ce qui est souvent réalisé par le biais de contrats de proxy.
Le contrat proxy est en fait une méthode couramment utilisée dans le développement de contrats Ethereum, qui consiste à séparer les données du contrat de la logique métier et à les stocker dans différents contrats. Les données (variables d'état) sont stockées dans des contrats de proxy et la logique métier (fonctions) est stockée dans des contrats logiques. Le contrat de proxy (Proxy) confie le processus d'exécution de la fonction au contrat logique (Implementation) via l'appel délégué, puis renvoie le résultat final à l'appelant (Caller).
Pour mettre à jour le contrat en mode proxy, il suffit de faire pointer le contrat proxy vers le nouveau contrat logique (réécrire l'adresse du contrat logique stockée dans le contrat proxy). ** La plupart des projets Rollup ont adopté cette méthode de mise à niveau contractuelle, qui peut être décrite comme simple et grossière. **
Il n'est pas difficile d'imaginer que le contrat de Rollup peut être mis à jour est en fait un énorme tonnerre : si le contrat mis à jour contient du code malveillant, comme modifier les conditions de libération du retrait du contrat Bridge intégré de Rollup, ou modifier les conditions du contrat Verifier pour déterminer la validité et prouver l'exactitude, le séquenceur peut voler des pièces (le principe est mentionné plus haut).
Mais le problème est que le contrat Rollup ne peut pas être mis à niveau, et la raison en est très claire. Dans l'ensemble, la grande majorité de Rollup décidera de mettre à niveau le contrat Rollup via la gouvernance DAO, le comité de sécurité ou l'autorisation multi-signatures. De plus, le verrouillage horaire Timelock sera utilisé pour définir une période de délai pour les mises à niveau du contrat.
Considérant que la plupart des propositions DAO ont un processus d'exécution automatisé (mis en œuvre via des contrats en chaîne), même si le contrat doit être mis à niveau, suffisamment de votes doivent d'abord être obtenus, puis l'opération de mise à niveau du contrat ne sera exécutée qu'après le délai spécifié par le Timelock (souvent plusieurs jours). Si quelqu'un veut s'engager dans des mises à niveau de contrat malveillantes, il doit surmonter la gouvernance DAO par des attaques de gouvernance (telles que les attaques de gouvernance qui se sont produites sur Tornado Cash), mais le coût de le faire est très élevé et il doit d'abord obtenir suffisamment de jetons, ce qui ne réussira pas dans des circonstances normales. Même si l'attaque de gouvernance réussit, en raison du blocage du temps, les utilisateurs auront suffisamment de temps pour retirer des actifs de L2, et **Les responsables du Rollup auront suffisamment de temps pour prendre des mesures d'urgence. **
Il semble que les timelocks soient l'arme magique contre les mises à niveau de contrats malveillantes. Mais le problème est que les soi-disant ** "mesures d'urgence que les responsables du Rollup peuvent prendre" ** contournent en fait la gouvernance du DAO et les verrous horaires, et mettent immédiatement à niveau le contrat Rollup via une autorisation multi-signature ou du comité de sécurité. Considérant que le Rollup grand public actuel héberge des milliards de dollars d'actifs utilisateurs, la "mise à niveau immédiate du contrat" autorisée par le comité multi-signatures et sécurité est la mesure d'urgence ultime, mais c'est aussi l'épée de Damoclès suspendue au-dessus de la tête de tous les utilisateurs.
Évidemment, il s'agit de maximiser la confiance : vous devez avoir confiance que les responsables de Rollup n'auront pas l'idée de vous voler vos avoirs. Si vous le considérez du point de vue de Trustless (du point de vue de Nick Szabo), **tous les Rollups contrôlés par des comités multi-signatures et de sécurité ne sont pas sécurisés. **Emin Gun Sirer, le fondateur d'Avalanche, Anatoly, le fondateur de Solana, et Justin Bons, la célèbre tache solaire, ont tous insisté sur ce genre de problème.
Quels Rolllups sont manipulés par les multisigs/comités ?
Selon le rapport "Upgradeability of Ethereum L2s" publié par la célèbre institution de recherche L2 L2 BEAT et le site Web de visualisation de données L2BEAT, ** Arbitrum, Optimism, Loopring (Loopring), ZKSync Lite, ZkSync Era, Starknet, Polygon ZKEVM et d'autres Rollups grand public ont tous des contrats évolutifs multi-signatures ou autorisés par le comité, et peuvent contourner les restrictions de verrouillage horaire. **
Bien que dYdX ait une adresse EOA qui peut contourner le contrat de mise à jour de la gouvernance DAO, elle est limitée par un blocage horaire (au moins 2 jours de délai). Immutable X a un délai de mise à niveau du contrat de 14. Par conséquent, selon L2BEAT, ** dYdX et Immutable X sont plus fiables que les autres rollups traditionnels qui ont lancé le réseau principal. **
** Alors, comment réduire le risque de confiance apporté par la multi-signature et le comité de sécurité ? ** La réponse est en fait similaire à l'incident de Multichain : elle peut être attribuée au problème anti-sorcière. Il faut s'assurer que les multisigs/comités sont contrôlés par plusieurs entités différentes sans degré élevé de chevauchement d'intérêts et avec un faible risque de collusion. À l'heure actuelle, il semble qu'il n'y ait pas d'autre moyen que d'accroître la maturité de la gouvernance décentralisée de DAO et d'inviter des célébrités ou des institutions célèbres et réputées à participer à plusieurs signatures/comités. Le scénario ci-dessus semble avoir été courant dans les démocraties du monde réel.
Bien sûr, il est également possible de limiter le comportement de mise à niveau du contrat géré par la multi-signature/comité via le blocage du temps, mais cela doit être mis en balance avec de nombreux facteurs, car le but de la multi-signature/comité est de faire face rapidement à certaines situations d'urgence ; en même temps, si la partie du projet Rollup n'a pas une détermination ferme sur la question de la non-confiance, ce problème ne peut pas être résolu.
Par conséquent, bien que différents projets Rollup puissent garantir la sécurité des actifs des utilisateurs la plupart du temps grâce à une conception de mécanisme sophistiquée, la probabilité d'un événement de cygne noir dans Rollup n'est pas nulle en raison de l'existence de multi-signatures et de comités. Même si la probabilité de collusion multi-signatures et membres de comité n'est que de 1 sur 10 000, compte tenu de la valeur des actifs sous garde L2 (supposée être de 10 milliards de dollars américains), le risque des actifs des utilisateurs L2 est toujours aussi élevé que 1 million de dollars américains par jour. Rappelant l'incident de Multichain, c'est vraiment effrayant.
Je pense donc personnellement que, comme Polynya l'a déjà dit, la plupart des fonds de l'écosystème Ethereum auront toujours tendance à circuler et à se verrouiller en L1 plutôt qu'en L2, et l'écosystème Rollup ne pourra pas capturer la majeure partie de la valeur de l'écosystème Ethereum à long terme. Pour les grands investisseurs et les baleines, le réseau principal Ethereum est évidemment un endroit plus approprié et plus fiable pour obtenir des fonds que L2. Par conséquent, beaucoup de gens se sont demandé "si la montée en puissance de la L2 conduirait à l'abandon de la L1", en fait, ils ont déjà la réponse.
Comme Keigo Higashino l'a dit dans son livre, le cœur humain est beaucoup plus insaisissable, plus difficile à comprendre, plus compliqué et plus difficile à modifier que les formules mathématiques. Beaucoup de choses ne peuvent pas être résolues par des moyens purement techniques, mais tout facteur impliquant la "nature humaine" sera toujours le problème le plus incontrôlable, imprévisible et le plus grave du monde. Ici, s'il vous plaît, gardons à l'esprit la phrase classique sur la pierre tombale de Kant :
"Deux choses ont toujours entouré mon esprit, et plus j'y pense, plus elles évoquent en moi de l'étonnement et de la crainte : la loi morale à l'intérieur et le ciel étoilé au-dessus.