Les risques liés à la confiance dans les signatures multiples et les comités lors des mises à niveau de Rollup : les L2 ne sont pas aussi « idéaux » que beaucoup le pensent
TechFlow SélectionTechFlow Sélection
Les risques liés à la confiance dans les signatures multiples et les comités lors des mises à niveau de Rollup : les L2 ne sont pas aussi « idéaux » que beaucoup le pensent
Comment réduire les risques de confiance liés aux signatures multiples et au comité de sécurité ?
Dédié à des analyses Web3 approfondiesAuteur : Lin Ke, GeekerWeb3
Introduction
Depuis le déclin progressif de Solana et l'émission du jeton OP, les Layer2 et Rollups semblent être devenus un nouveau refuge pour d'innombrables acteurs de Web3. Alors que le marché baissier s'étend et que FTX fait faillite, entraînant de lourdes pertes pour Multicoin, les concurrents d'Ethereum ont progressivement quitté la scène principale de Web3, perdant petit à petit toute confiance face à ETH. De plus en plus de personnes commencent à considérer les Rollups comme le cœur d'une nouvelle narration, et toujours davantage de projets fleurissent sur les L2 comme des champignons après la pluie.
Mais tout ceci est-il une « prospérité illusoire », une « bulle susceptible d’éclater à tout moment » ? Les Rollups et les L2 sont-ils vraiment aussi idéaux que la majorité les décrit ? Sont-ils réellement aussi sûrs qu'on le pense ? Sans même parler du fait que de nombreux Rollups OP ne disposent pas de preuve de fraude, quels autres risques de sécurité entourent les Rollups ?
Cet article s'inspire du rapport récent publié par L2BEAT intitulé « Upgradeability of Ethereum L2s », et traite spécifiquement des risques liés à la confiance dans les signatures multiples (multisig) et les comités responsables des mises à niveau des Rollups, ainsi que des questions fréquemment soulevées concernant les Rollups. En repensant au récent cas de Multichain, il vise à faire une synthèse globale sur pourquoi les L2 ne sont pas aussi « idéaux » que beaucoup le croient.
Principe simplifié des Rollups
(Si vous connaissez déjà bien le fonctionnement des Rollups, vous pouvez sauter directement plusieurs paragraphes ci-dessous.)
Résumé du principe de fonctionnement des Rollups :
Un Rollup Ethereum = un ensemble de contrats sur la couche 1 (L1) + les propres nœuds du réseau de la couche 2 (L2).
Le groupe des nœuds du réseau L2 peut être divisé en plusieurs rôles, dont le plus important est sans doute le séquenceur (Sequencer). Celui-ci reçoit les demandes de transactions sur la L2, décide de leur ordre d'exécution, puis regroupe ces transactions sous forme de lots (Batch), qu'il transmet aux contrats du projet Rollup présents sur la L1 (appelés ici contrats Rollup).
Schéma illustrant la logique d'interaction de Starknet
Les nœuds complets (full nodes) de la L2 peuvent obtenir directement la séquence des transactions auprès du séquenceur, ou lire les lots de transactions envoyés par ce dernier sur la L1. Toutefois, cette dernière méthode offre une finalité (immutabilité) supérieure. Généralement, une fois qu’un lot de transactions a été transmis à la L1 par le séquenceur, son ordre devient immuable (tant qu’Ethereum ne subit pas de réorganisation de blocs, la séquence des transactions sur le Rollup ne change pas non plus).
Étant donné que l’exécution des transactions modifie l’état du registre blockchain, outre l’ordre des transactions, les nœuds complets de la L2 doivent également synchroniser avec le séquenceur l’état du registre afin d’en garantir la cohérence.
Par conséquent, le séquenceur doit non seulement transmettre les lots de transactions au contrat Rollup sur la L1, mais aussi y envoyer les résultats de mise à jour d’état suite à l’exécution des transactions, appelés Stateroot / State diff.
Il est facile de comprendre que la L1 (Ethereum) joue en réalité le rôle d’un tableau d’affichage pour les nœuds de la L2 — elle est bien plus décentralisée, plus trustless et plus sécurisée que le propre réseau de la L2. Pour un nœud complet de la L2, dès lors qu’il dispose sur la L1 de la séquence des transactions Rollup + le Stateroot initial, il peut reconstruire le registre blockchain de la L2 et calculer le Stateroot le plus récent. Si le Stateroot calculé par le nœud complet diffère de celui publié par le séquenceur sur la L1, cela signifie que le séquenceur a commis une fraude.
Prenons un exemple imaginaire évident : le séquenceur de la L2 pourrait-il voler les actifs des utilisateurs ? Par exemple, pourrait-il falsifier certaines transactions qui ne devraient pas exister (par exemple, transférer les jetons de certains utilisateurs L2 vers l’adresse du gestionnaire du séquenceur, puis transférer ces jetons vers la L1). Cette question revient à se demander : que faire si le séquenceur publie de fausses données de transaction ou un faux Stateroot ?
Face au risque de fraude du séquenceur, différents types de Rollups adoptent des mesures différentes. Les Rollups optimistes (Optimistic Rollup) permettent aux nœuds complets de la L2 de fournir une preuve de fraude (Fraud Proof) attestant que les données publiées par le séquenceur sur la L1 sont erronées. Par exemple, Arbitrum met en place une liste blanche de nœuds, autorisant uniquement ceux figurant sur cette liste à publier des preuves de fraude.
En outre, étant donné que la plupart des bourses et des ponts inter-chaînes privés exécutent des nœuds complets L2 et peuvent donc détecter immédiatement les erreurs, la probabilité de succès d’un vol de jetons par un séquenceur de Rollup est pratiquement nulle (car pour réaliser ses gains, il devra finalement passer par une bourse ou trouver un autre moyen après avoir transféré les jetons volés vers la L1).
Dans l’image, l’Aggregator correspond en réalité au séquenceur
Toutefois, pour Optimism qui ne dispose pas de preuve de fraude, le séquenceur pourrait voler des jetons via le contrat bridge du Rollup lui-même. Par exemple, l’exploitant du séquenceur pourrait falsifier des instructions de transaction afin de transférer les actifs d’autres utilisateurs sur la L2 vers son adresse, puis utiliser le contrat bridge intégré au Rollup pour transférer les jetons volés vers la L1. En l’absence de preuve de fraude, les nœuds complets d’OP ne peuvent contester les transactions erronées. Ainsi, théoriquement, le séquenceur d’OP pourrait voler les actifs des utilisateurs sur la L2 (à condition qu’il souhaite réellement le faire).
Au 24 juillet 2023, après la mise à niveau Bedrock, OP n’avait toujours pas lancé son système de preuve de fraude
La solution à ce problème repose soit sur le "consensus social" (surveillance par la communauté et les médias sociaux), soit sur la caution de confiance fournie par l’équipe officielle d’OP.
Curieusement, récemment, une certaine bourse a réduit le délai de dépôt des transferts depuis Arbitrum et Optimism (passant de 100 blocs L2 à 1 seul bloc L2), ce qui revient à faire confiance au séquenceur d’ARB et d’OP pour ne pas mal agir (en les considérant implicitement comme des serveurs centralisés soutenus officiellement).
Contrairement aux Rollups optimistes, outre la dépendance aux nœuds complets L2, les ZK Rollups résolvent le problème de fraude du séquenceur grâce à la preuve de validité (Validity Proof) (souvent confondue avec la ZK Proof). Dans un réseau ZK Rollup, il existe un type de nœud appelé Prover, spécialisé dans la génération de preuves de validité pour les lots de transactions (Batch) publiés par le séquenceur. Parallèlement, la L1 dispose d’un contrat spécifique chargé de vérifier ces preuves de validité (généralement appelé Verifier). Dès que la preuve associée à un lot de transactions et au Stateroot / State diff est validée par le contrat Verifier, la transaction est définitivement confirmée (Finalized). Le pont officiel du ZK Rollup n’autorisera que les retraits ayant passé la vérification par preuve de validité — ce qui le rend manifestement bien plus fiable qu’Optimism.
Les trois phases définies par Scroll pour les données de transaction
Théoriquement parlant, la sécurité des Rollups OP repose sur les nœuds complets L2 (il suffit qu’au moins un nœud honnête capable de produire une preuve de fraude existe). Celle des ZK Rollups est assurée par le contrat Verifier sur la L1 (la confirmation finale des transactions est réalisée par les nœuds L1). En apparence, ils peuvent tous deux « hériter de la sécurité de la L1 » (utiliser la L1 pour finaliser et régler les transactions), et certains maximalistes d’Ethereum vont jusqu’à parler de « sécurité équivalente à celle de la L1 » (finalité des transactions identique à celle de la L1). Mais en réalité, ce n’est pas le cas — loin de là.
Ces points fréquemment abordés
Premièrement, la génération de la preuve de validité dans les ZK Rollups est extrêmement lente. Un séquenceur peut exécuter des milliers de transactions en une seconde, mais générer la preuve pour ces milliers de transactions peut prendre plusieurs heures au maximum. Mais ce problème est facile à résoudre : les principaux ZKR utilisent généralement une approche consistant à diviser la tâche de génération de preuve et à la distribuer à différents nœuds Prover pour traitement parallèle, ce qui accélère fortement la production des preuves.
Deuxièmement, il faut tenir compte du délai de publication des données sur la L1 par les nœuds L2. Chaque fois que le séquenceur ou le Prover envoie des données sur la L1, un coût fixe est engagé (comme chaque expédition nécessitant un conteneur). Publier fréquemment des données sur la L1 n’est pas rentable, voire entraîne des pertes. Par conséquent, le séquenceur et le Prover essaient de minimiser la fréquence de publication, en attendant d’avoir accumulé suffisamment de données avant de les envoyer groupées.
Autrement dit, lorsque le nombre d’utilisateurs est insuffisant et que le volume de transactions est faible, le séquenceur retarde la publication des données sur la L1. Par exemple, l’année dernière, lorsque peu d’utilisateurs étaient présents, Optimism ne transmettait un lot de transactions à la L1 que toutes les demi-heures. Aujourd’hui, avec l’augmentation du nombre d’utilisateurs, ce problème a été efficacement résolu. Contrairement à OP, Starknet adopte une stratégie visant à réduire la fréquence de publication du State diff afin de diminuer les coûts de données, ce qui allonge considérablement le délai de confirmation finale des transactions sur Starknet, atteignant 7 à 8 heures.
En outre, afin de réduire encore davantage les coûts, la plupart des ZK Rollups choisissent souvent de « agréger plusieurs preuves avant de les envoyer en une seule fois sur la L1 ». Autrement dit, le Prover n’envoie pas immédiatement une preuve générée sur la L1, mais attend que plusieurs preuves soient prêtes, puis les regroupe et les envoie au contrat Verifier sur la L1. (En réalité, le processus d’agrégation consiste à utiliser une seule preuve pour encapsuler les étapes de vérification de plusieurs preuves.)
Schéma illustrant l’agrégation de preuves chez Scroll
La conséquence est que la fréquence de publication des preuves diminue encore, et le délai entre l’envoi d’une transaction et sa confirmation finale s’allonge davantage.
Selon les explorateurs de blocs, le délai de confirmation des transactions sur Polygon ZKEVM est d’environ 30 à 50 minutes, tandis que sur Starknet et Zksync Era, il dépasse 7 heures. Il est clair que cela ne représente qu’une « sécurité partiellement héritée de la L1 », très éloignée de la « sécurité équivalente à celle de la L1 » vantée par les supporters d’Ethereum.
Bien sûr, tous ces problèmes pourront être résolus grâce aux progrès technologiques, probablement dans un futur proche. Par exemple, de nombreux projets développent des matériels haute performance pour réduire le temps de génération des preuves de validité ; Optimism promet également de lancer rapidement son système de preuve de fraude ; la proposition Danksharding d’Ethereum réduira les coûts de données des Rollups de plusieurs dizaines de fois, voire davantage, ce qui permettrait efficacement de résoudre les problèmes énumérés ci-dessus.
Le problème insoluble du contrôle humain ("règne de l'homme")
Comme les projets applicatifs tels que DeFi, le fonctionnement d’un réseau Rollup dépend de contrats associés sur la L1, et ces contrats sont « mis à jour ». Autrement dit, certaines parties du code peuvent être remplacées (la plupart des Rollups utilisent des contrats proxy), et ces mises à jour peuvent être effectuées immédiatement sous l’autorisation d’une multisig ou d’un comité de sécurité. Voici la conclusion : un Rollup peut, via une multisig ou un comité de sécurité contrôlé par quelques individus, modifier rapidement le code des contrats sur la L1, puis voler les actifs des utilisateurs.
Source : Rapport de recherche L2BEAT
D’abord, pourquoi les contrats Rollup doivent-ils être mis à jour et comment ces mises à jour sont-elles effectuées ? Une fois déployés sur Ethereum, le code des contrats ne peut plus être modifié. Or, pendant le développement des Rollups, divers bogues peuvent survenir, conduisant à des résultats erronés ; par ailleurs, les Rollups subissent fréquemment des itérations produits nécessitant l’ajout régulier de nouvelles fonctionnalités ; dans des cas extrêmes, les contrats Rollup peuvent même être piratés. Ainsi, les contrats Rollup doivent être mis à jour, généralement via des contrats proxy.
Source : wtf academy
Le contrat proxy est une méthode courante en développement de contrats Ethereum : il sépare les données du contrat et la logique métier, les stockant dans des contrats distincts. Les données (variables d’état) sont conservées dans le contrat proxy, tandis que la logique métier (fonctions) est placée dans un contrat logique. Le contrat proxy utilise l’instruction delegatecall pour déléguer entièrement l’exécution des fonctions au contrat logique (Implementation), puis renvoie le résultat final à l’appelant (Caller).
Pour mettre à jour un contrat en mode proxy, il suffit de rediriger le contrat proxy vers un nouveau contrat logique (en modifiant l’adresse du contrat logique stockée dans le proxy). La plupart des projets Rollup utilisent cette méthode simple et brutale pour mettre à jour leurs contrats.
Source : wtf academy
On peut aisément imaginer que la possibilité de mise à jour des contrats Rollup constitue une énorme menace : si le contrat mis à jour contient du code malveillant, par exemple en modifiant les conditions d’autorisation de retrait du contrat bridge intégré au Rollup, ou en altérant les critères du contrat Verifier pour juger la validité d’une preuve, alors le séquenceur pourrait voler des jetons (le principe en a déjà été expliqué précédemment).
Mais le problème est qu’on ne peut pas interdire la mise à jour des contrats Rollup, pour les raisons exposées plus haut. Après réflexion, la grande majorité des Rollups recourent à la gouvernance DAO, à un comité de sécurité ou à une autorisation multisig — autrement dit, à un contrôle humain — pour décider s’il faut ou non mettre à jour les contrats. En outre, on ajoute souvent un verrou temporel (Timelock) pour introduire un délai avant la mise à jour effective du contrat.
Source : Rapport de recherche L2BEAT
Étant donné que la plupart des propositions DAO disposent d’un flux d’exécution automatisé (réalisé via des contrats sur chaîne), même pour mettre à jour un contrat, il faut d’abord obtenir suffisamment de votes, puis attendre le délai imposé par le Timelock (souvent plusieurs jours) avant que l’opération de mise à jour ne soit exécutée. Quiconque tenterait une mise à jour malveillante devrait franchir l’étape de la gouvernance DAO par une attaque de gouvernance (comme celle survenue sur Tornado Cash), ce qui est coûteux car il faudrait d’abord acquérir suffisamment de jetons. Normalement, cela ne réussit pas. Même si une attaque de gouvernance réussissait, le verrou temporel donnerait aux utilisateurs assez de temps pour retirer leurs actifs de la L2, et l’équipe officielle du Rollup aurait assez de temps pour prendre des mesures d’urgence.
Un verrou temporel impose un délai avant qu’une opération puisse être effectuée
Le verrou temporel semble donc être la panacée contre les mises à jour malveillantes. Mais le hic est que les mésures d’urgence que l’équipe officielle du Rollup peut prendre consistent précisément à contourner la gouvernance DAO et le verrou temporel, et à mettre à jour immédiatement le contrat Rollup via une multisig ou un comité de sécurité. Étant donné que les principaux Rollups actuels gèrent des actifs utilisateur s’élevant à plusieurs milliards de dollars, la possibilité de mise à jour immédiate autorisée par une multisig ou un comité de sécurité constitue certes la mesure ultime d’urgence, mais aussi l’épée de Damoclès suspendue au-dessus de la tête de tous les utilisateurs.
Il s’agit clairement d’un problème de confiance maximale : vous devez faire confiance à l’équipe officielle du Rollup pour qu’elle n’ait aucune intention de voler vos actifs. Si l’on adopte une perspective trustless (selon Nick Szabo), tous les Rollups contrôlés par une multisig ou un comité de sécurité sont intrinsèquement non sécurisés. Emin Gun Sirer, fondateur d’Avalanche, Anatoly, fondateur de Solana, et Justin Bons, célèbre critique, ont tous souligné ce problème.
Quels Rollups sont contrôlés par une multisig ou un comité ?
Selon le rapport « Upgradeability of Ethereum L2s » publié par L2 BEAT, prestigieux institut de recherche sur les L2, ainsi que les données affichées sur le site de visualisation L2BEAT, Arbitrum, Optimism, Loopring, ZKSync Lite, ZkSync Era, Starknet et Polygon ZKEVM — des Rollups majeurs — possèdent tous des contrats mis à jour via multisig ou comité de sécurité, pouvant contourner la restriction du verrou temporel.
dYdX possède une adresse EOA capable de mettre à jour le contrat sans passer par la gouvernance DAO, mais reste soumise à un verrou temporel (avec un délai minimal de 2 jours). Immutable X présente un délai de 14 jours pour la mise à jour de contrat. Selon L2BEAT, dYdX et Immutable X seraient donc plus trustless que les autres Rollups majeurs actuellement en mainnet.
Source : Rapport de recherche L2BEAT
Comment réduire les risques de confiance liés à la multisig et au comité de sécurité ? La réponse est similaire à celle de l’incident Multichain : elle revient à un problème anti-Sybil. Il faut absolument garantir que la multisig / le comité soit contrôlé par plusieurs entités distinctes, sans conflits d’intérêts majeurs ni risque élevé de collusion. À ce stade, outre le renforcement de la maturité de la gouvernance DAO décentralisée et l’invitation de personnalités ou institutions influentes et crédibles à participer à la multisig / au comité, il ne semble guère exister de meilleures solutions. Ce genre de scénario semble d’ailleurs déjà familier dans la politique démocratique du monde réel.
Bien sûr, on pourrait aussi restreindre via un verrou temporel les actions de mise à jour gérées par la multisig / le comité, mais cela implique de nombreux compromis, car la raison d’être de la multisig / du comité est justement de traiter rapidement les situations d’urgence. Par ailleurs, si l’équipe du projet Rollup n’a pas une volonté ferme en matière de décentralisation et de confiance minimale, ce problème ne pourra jamais être résolu.
Ainsi, bien que divers projets Rollup utilisent des conceptions mécaniques sophistiquées pour assurer la sécurité des actifs des utilisateurs dans la plupart des cas, la présence de la multisig et du comité signifie que la probabilité d’un événement noir (black swan) sur un Rollup n’est pas nulle. Même si la probabilité de collusion entre membres de la multisig / du comité est d’un sur dix mille, compte tenu de la valeur des actifs gérés par les L2 (supposons 100 milliards de dollars), le risque quotidien pour les utilisateurs atteint encore 1 million de dollars. En pensant à l’incident Multichain, on en frissonne d’effroi.
Personnellement, je pense, comme Polynya l’a déjà dit, que la majeure partie des fonds dans l’écosystème Ethereum continuera de circuler et d’être bloquée sur la L1 plutôt que sur la L2. L’écosystème des Rollups ne pourra pas capter la majeure partie de la valeur de l’écosystème Ethereum à long terme. Pour les gros portefeuilles et les baleines, le réseau principal d’Ethereum reste un lieu bien plus approprié et fiable pour leurs fonds. Ainsi, la question que beaucoup se posaient auparavant — « L’essor des L2 entraînera-t-il le déclin de la L1 ? » — a déjà trouvé sa réponse.
Comme l’a dit Keigo Higashino dans son œuvre, l’esprit humain est bien plus difficile à saisir, à comprendre, plus complexe et plus difficile à changer que les formules mathématiques. Beaucoup de choses ne peuvent être résolues par des moyens techniques purs. Dès qu’un facteur lié à la « nature humaine » intervient, cela devient toujours la chose la plus incontrôlable, la plus imprévisible et la plus sérieuse à traiter. Ici, rappelons-nous cette phrase classique gravée sur la tombe de Kant :
« Deux choses me remplissent toujours l’âme d’un étonnement et d’un respect renouvelés : le ciel étoilé au-dessus de moi, et la loi morale en moi. »
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
