En savoir plus sur les raisons pour lesquelles les Rollups ont besoin d’un comité de sécurité ?

AUTEUR ORIGINAL : PATRICK MCCORRY

Compilation originale : Luffy, Foresight News

Toute base de données qui interagit avec des crypto-actifs choisira un jour Rollup comme pile technologique. Il y a un certain nombre de bonnes raisons pour les développeurs de prendre une telle décision :

• Audit en temps réel
• Certificat de solvabilité par défaut
• L’entiercement des fonds de l’utilisateur est facultatif
• Un participant honnête protège l’ensemble du système

Plus important encore, tous les efforts de conception et de mise en œuvre de Rollup sont axés sur la protection des utilisateurs, de leurs fonds et de toutes leurs interactions contre les opérateurs de système potentiellement inconnus et puissants.

Même si l’ensemble du système est hors ligne, les utilisateurs peuvent récupérer leurs fonds par eux-mêmes.

Si les Rollups peuvent être largement déployés en tant que pile technologique, nous pourrions avoir la capacité de faire tomber les barrières de confiance et de permettre des interactions financières pour tous les membres de la communauté mondiale, ce qui conduirait à une nouvelle ère de commerce électronique mondial, d’embauche à distance et de prestation de services sans friction.

Il faut beaucoup d’efforts pour qu’un rollup fonctionne correctement.

Qu’en est-il des multisigs ?

Cela sonne bien, mais l’ensemble du système est finalement contrôlé par multisig. Si le signataire est compromis ou malveillant, il peut facilement voler tous les fonds.

Alors, qui se soucie des Rollups ? quelque part sur CT.

Il est vrai que tous les rollups actuels ont le multisig et ont le droit de mettre à niveau le contrat intelligent sous-jacent, mais comme nous le verrons, il s’agit d’un mécanisme conservateur qui protège les fonds des utilisateurs et fait partie d’une architecture système plus large.

Responsabilités du comité de sécurité

Multisig est un terme technique qui fait référence à un système qui nécessite plusieurs signataires pour autoriser une action. Par exemple, K des N signataires complètent la signature numérique pour que la transaction soit autorisée.

Dans le contexte des cumuls, le multisig est souvent appelé comité de sécurité, où les signataires ont le pouvoir de mettre à niveau tous les contrats intelligents associés.

Jetons un coup d’œil au Conseil de sécurité d’Arbitrum (tel que je le connais très bien) pour avoir une idée des types de responsabilités que cette organisation pourrait avoir :

*Veto. Si le Comité de sécurité estime qu’une proposition adoptée par la DAO d’Arbitrum viole la charte d’Arbitrum et peut nuire à l’écosystème d’Arbitrum, il peut annuler la proposition. Par exemple, annulez une proposition qui a réussi en raison d’une attaque de gouvernance. *Entretien. Mettez à niveau la suite de contrats intelligents Arbitrum pour apporter des modifications mineures qui ont moins d’impact et ne nécessitent pas l’implication d’Arbitrum DAO. *Urgences. Réagissez rapidement en cas d’urgence, et s’ils pensent que les fonds des utilisateurs sont en danger imminent, ils peuvent mettre à niveau de toute urgence le contrat intelligent.

Bien sûr, le plus important est que le premier devoir du comité de sécurité est de répondre aux urgences et d’agir rapidement pour protéger les fonds des utilisateurs.

Les membres du comité de sécurité doivent être des personnes de confiance.

Il y a une confiance dans les signataires pour être en mesure de réagir rapidement, d’être en mesure de mettre à niveau le contrat intelligent en cas d’urgence et de faire de leur mieux pour garder les fonds dans le contrat intelligent en sécurité.

Sélectionner le bon seuil multisig

Il y a deux facteurs importants à prendre en compte lorsqu’on décide de mettre sur pied un comité de sécurité :

• Combien y a-t-il de signataires ?
• Quel est le nombre minimum de signataires requis pour approuver une action ?
• Cela peut sembler une question triviale, après tout, il ne s’agit que de deux chiffres, mais il y a un équilibre à prendre en compte :
• Faille de sécurité : les membres de K peuvent s’entendre pour modifier les contrats intelligents et voler les fonds des utilisateurs.
• Violation active : les membres de N-K+ 1 s’entendent pour empêcher toute modification du contrat intelligent, en particulier si une vulnérabilité critique est trouvée.

Le défi consiste à établir un seuil qui permettra à la fois d’assurer la sécurité des fonds en temps de paix et d’agir rapidement en cas d’urgence lorsque les fonds des utilisateurs sont menacés.

Prenons un exemple concret. Supposons que le seuil soit défini sur 9/10 où 9 signataires doivent cosigner un message. Il s’agit d’un seuil de sécurité strict, car 9 signataires doivent s’entendre pour voler les fonds. L’inconvénient, cependant, est que deux signataires peuvent bloquer toute action en cas d’urgence. Par exemple, si deux signataires voyagent loin sur un vol transatlantique, le comité de sécurité ne sera pas en mesure de remplir ses fonctions.

Bien sûr, si le seuil de sécurité est bas, disons 2/10, il suffit que deux signataires s’entendent (ou que la clé privée soit compromise) pour que les fonds de l’utilisateur soient volés.

La perception de l’intégrité d’une personne est susceptible de changer avec le temps

Le choix du seuil approprié est plus une question sociale que technique, et je pense que c’est plus un art qu’une science. La sécurité dépend fortement de l’intégrité de chaque signataire. Comme nous le verrons bientôt, il existe des moyens de réduire la confiance dans le multisig, mais cela s’accompagne d’une série de compromis.

Membre du Comité de Sécurité

Le correctif cumulatif principal met instantanément à niveau le seuil multisig requis pour tous les contrats intelligents

La plupart des Rollups ont un groupe de signataires anonymes dans leurs comités de sécurité. Nous soupçonnons que cela peut être dû à :

• L’étape de développement du rollup,
• Pour protéger la sécurité personnelle des membres,
• Croire que l’anonymat est la meilleure option pour protéger les fonds des utilisateurs.
• D’autre part, il y a trois projets de Rollup qui ont annoncé publiquement leur appartenance au comité de sécurité :
• Arbitrum : Les signataires sont élus publiquement, et la liste actuelle peut être consultée sur Tally. Seuls trois signataires sont associés au projet Arbitrum (deux d’Offchain Labs et un de la Fondation Arbitrum).
• Base : 2/2 multisig, l’un contrôlé par la Base et l’autre contrôlé par l’Optimisme.
• Polygon zkEVM : Pas encore implémenté, mais ils ont annoncé qu’ils mettraient à niveau leur multisig vers 10/13, qui comprend deux membres de Polygon Labs et un consultant de Polygon Labs.
• zkSync Lite : zkSync Lite doit être distingué de ZkSync Era, dont le comité de sécurité est annoncé publiquement et n’inclut pas les affiliés directs du projet Rollup (à l’exception des investisseurs dans zkSync).

Dans Arbitrum, et dans le prochain Polygon, seule une poignée de signataires sont directement associés au projet Rollup, et le nombre est suffisamment faible pour s’assurer que les affiliés ne peuvent pas s’entendre pour bloquer les mesures prises par le Comité de sécurité. Dans zkSync Lite, en plus des investisseurs de zkSync, ils nomment des signataires indépendants du projet.

Dans tous les cas, le Rollup accorde une grande importance aux signataires qui ne sont pas directement liés au projet.

Cependant, il semble y avoir un manque de consensus sur ce qui constitue un bon multisig, ce qui nous amène à plusieurs problèmes de conception :

• Les membres anonymes devraient-ils être autorisés ?
• Les membres doivent-ils provenir de différentes zones géographiques ?
• Les membres doivent-ils être des particuliers ou des sociétés ?
• Les membres devraient-ils être nommés ou élus ?
• Combien de membres d’une même entreprise (ou d’un même pays) doivent être autorisés ?
• Y a-t-il une taille minimale et un seuil qui sont considérés comme appropriés ?

La règle générale devrait être de choisir des membres ayant un haut degré d’intégrité afin que le public ait confiance dans la sécurité du système. Du moins, je crois que c’est probablement le cas de la plupart des projets, même si ce n’est pas toujours vérifiable publiquement.

P.S. Six membres du Comité de sécurité d’Arbitrum sont actuellement pré-nommés, mais ils seront remplacés lors des élections de mars.

Affaiblir les pouvoirs de la Commission

Jusqu’à présent, nous n’avons envisagé qu’un seul comité qui a le pouvoir de mettre à niveau le contrat intelligent immédiatement, mais il existe des moyens de limiter les pouvoirs du comité :

Temporisation. Toutes les mesures autorisées par la Commission ne seront pas exécutées et ne prendront effet qu’à l’expiration du délai T.

Pause uniquement. Tous les avoirs détenus par le pont inter-chaînes natif peuvent être gelés par le comité. Cela peut suspendre les fonctionnalités suivantes :

• Transmettre le message de L2 à L1 (c’est-à-dire retirer de l’argent),
• Terminer le tri des transactions en attente,
• Compléter de nouveaux points de contrôle/certificats,
• Accepter les nouvelles données de cumul (c’est-à-dire les transactions en attente).

Commission de contournement (supprimée). Abandonnez le comité et appuyez-vous sur un autre mécanisme de gouvernance, tel qu’une DAO, pour approuver la mise à niveau.

Ceci, bien sûr, limite la capacité de la Commission à agir rapidement et sa capacité à répondre efficacement aux urgences qui menacent les fonds des utilisateurs.

Si la vulnérabilité a été divulguée au comité en privé, mais qu’elle n’a pas encore été exploitée par des pirates, le comité de sécurité a la possibilité de mettre à niveau le contrat intelligent et de corriger le bogue. L’ajout d’un délai à une mise à niveau augmente le risque qu’un attaquant recherche une mise à niveau divulguée publiquement, trouve une vulnérabilité, puis l’exploite.

Par exemple, CVE-2018-17144 dans le BTC a été initialement annoncé comme une vulnérabilité DDoS dans le but de dissimuler une vulnérabilité plus grave à l’inflation des jetons. La vitesse de la mise à niveau est essentielle pour éviter qu’elle ne soit exploitée.

Évaluer les défenses du mécanisme de pause uniquement

Considérons un scénario potentiel pour qu’un attaquant exploite activement une vulnérabilité :

• Messages malveillants L2 → L1. Un attaquant peut créer des messages arbitraires provenant d’un contrat intelligent sur un cumul et transférer le message au contrat intelligent sur le ETH via un pont inter-chaînes natif.
• Transitions d’état non valides. Un attaquant peut exécuter une transaction sur un cumul qui enfreint les règles de la fonction de transition d’état et doit généralement être considérée comme non valide.
• Échappatoires de retrait. Un attaquant peut retirer des fonds du pont inter-chaînes natif en émettant simplement une transaction sur le ETH Fang (couche 1).

Dans les trois cas, le délai ne fait que donner à l’attaquant plus de temps pour continuer à voler les fonds et réduit la fenêtre d’opportunité pour le comité de défendre le système. La fonction time-lapse ne protège pas contre les attaques actives et ne peut être utilisée que pour la maintenance de routine et les tâches non urgentes.

Nous n’évaluerons que la capacité de mettre le système en pause et la mesure dans laquelle le système peut être suspendu.

Dans le cas de messages malveillants L2 → L1, la fonction de pause peut atténuer l’attaque sans interférer avec les activités de trading. Le comité devrait suspendre la messagerie et/ou finaliser la fonctionnalité des nouveaux points de contrôle. On prétend qu’il devrait y avoir un délai avant que le message L2 → L1 ne soit exécuté afin que le comité ait le temps de détecter les erreurs et de réagir aux urgences.

La défense contre les transitions d’état non valides est plus délicate, car la finalité de la transaction comporte différentes couches dans les cumuls. Si nous ne considérons que les transactions de cumul sans tenir compte des effets secondaires, alors la meilleure défense pour le comité de sécurité serait d’arrêter la possibilité de finaliser les points de contrôle, mais de continuer à autoriser le tri des transactions. Cela laisse le temps de corriger les bogues, de réactiver l’achèvement des points de contrôle et d’ignorer simplement les transactions non valides.

Toutefois, si l’activité de trading sur le Rollup n’est pas désactivée, l’expérience utilisateur sera chaotique et le Rollup peut sembler gravement interrompu jusqu’à ce que le logiciel client soit mis à niveau.

Cela nous amène au scénario suivant. Comment le comité devrait-il réagir si l’on considère comment des transactions non valides sur les cumuls pourraient affecter d’autres systèmes ? La meilleure ligne de défense consiste à geler la capacité du pont inter-chaînes natif à finaliser l’ordre des transactions, ou à désactiver complètement le séquenceur.

En effet, certains systèmes, tels que les ponts inter-chaînes rapides qui transfèrent des fonds d’un cumul à un autre, peuvent autoriser le transfert de fonds une fois qu’ils estiment que les transactions du cumul (y compris les transactions non valides) sont triées. Dans cet exemple, il peut permettre à un attaquant d’exploiter un protocole DeFi sur un Rollup, puis de transférer des fonds rapidement en les transférant vers un autre Rollup via un pont inter-chaînes rapide.

Au moment où la commission corrige la violation et rétablit la transaction invalide, le mal est peut-être déjà fait. Les LP dans les protocoles DeFi et les ponts inter-chaînes peuvent supporter le coût d’une attaque.

Enfin, si la vulnérabilité permet à un attaquant de retirer des fonds directement depuis le pont inter-chaînes natif, à l’instar du Nomad Hack, le comité de sécurité peut être impuissant à l’arrêter.

En fin de compte, il y a un problème global avec le mécanisme de suspension. Nous devons supposer qu’il existe un système de gouvernance plus large qui peut approuver les mises à niveau et réactiver les cumuls. Si nous supposons que le système de gouvernance est une DAO avec un système de vote on-chain fonctionnant sur Rollup, des problèmes de mise en œuvre délicats se posent.

Par exemple, si le pont inter-chaînes de messages L2→L1 est suspendu, les résultats du vote de la DAO ne peuvent pas être transmis du cumul au pont inter-chaînes natif sur le ETH, et il doit exister un autre moyen pour la DAO d’envoyer l’approbation et d’effectuer la mise à niveau.

Suppression progressive du Conseil de sécurité

Il y a des gens dans la communauté qui croient que le comité de sécurité devrait être éliminé progressivement, mais à mon avis, cela pose deux problèmes :

Faux sentiment de sécurité. Les attaquants qui sont au courant de l’exploit attendent que le comité de sécurité soit progressivement éliminé avant d’exécuter l’attaque. Au fil du temps, cela peut éroder notre confiance dans la sécurité de nos systèmes.

Les options de récupération sont limitées. Sans comité de sécurité, la communauté ne peut pas se défendre contre les agresseurs. La seule option disponible est d’effectuer un piratage parallèle et, espérons-le, de récupérer une partie des fonds.

À mon avis, les comités de sécurité seront toujours nécessaires, mais les pouvoirs qui leur sont conférés devraient être progressivement réduits.

En gardant cela à l’esprit, la question de conception devrait être la suivante :

Comment pouvons-nous amener le comité de sécurité à suspendre le système avec un impact minimal sur les utilisateurs, tout en permettant à la communauté au sens large de participer à la décision sur la façon de corriger les bogues et de réactiver le système ?

En d’autres termes, nous avons besoin d’un programme qui permette vraiment à la communauté d’intervenir et de rétablir le système, puis de limiter le pouvoir de suspension du Conseil de sécurité.

Dans l’espace blockchain de couche 1, la communauté peut en effet être atteinte directement en utilisant des forks activés par l’utilisateur, mais cette méthode ne fonctionne pas pour les contrats intelligents sur ETH cases (tels que les rollups) car il n’est pas nécessaire de forker l’ensemble du ETH. Dans certains cas, la communauté ETH peut décider collectivement de sauver le Rollup, comme TheDAO en 2016, mais le Rollup ne doit jamais s’attendre à un tel résultat.

Une autre idée intéressante dans ce sens est de mettre en œuvre un ETH pour que la Cour suprême se prononce sur les mises à niveau des contrats intelligents et permette des forks similaires à l’activation de l’utilisateur.

Comme mentionné précédemment, si le Rollup délègue sa sécurité à la DAO, il devrait y avoir une implémentation qui permet à la DAO de voter directement sur la ETH. C’est très délicat, surtout si le protocole de vote existe dans Rollup.

Enfin, je pense qu’il est nécessaire de procéder à un examen complet des types de situations qui peuvent nécessiter une réponse de la part du Conseil afin de faciliter la discussion sur sa nécessité.

Pourquoi s’inquiéter des rollups si vous avez des multisigs ?

Nous avons passé pas mal de temps à comprendre les responsabilités, la conception et les besoins du comité de sécurité, mais il est important de revenir à la question initiale de cet article :

Est-ce que Rollup n’est qu’un multisig ?

La réponse est non.

Pour aider à comprendre pourquoi, il est préférable de prendre du recul et de comprendre ce que le système blockchain veut vraiment faire.

Un protocole blockchain est un outil qui permet aux utilisateurs de calculer une copie d’une base de données et d’être sûrs qu’ils ont la même base de données que tout le monde.

En gardant cela à l’esprit, il existe deux composants dans tout système blockchain :

• Protocole Blockchain. La combinaison de logiciels, de cryptographie et de systèmes distribués donne confiance à quiconque dans l’intégrité d’une base de données.
• Système de gouvernance. Un mécanisme de coordination qui permet à toutes les parties prenantes de travailler ensemble et de se mettre d’accord sur les modifications à apporter au protocole blockchain.

L’objectif de tout système blockchain, y compris Rollup, est de s’assurer que le protocole blockchain fonctionne toujours avec une disponibilité extrêmement fiable de 99,9999 %. Un exploitant de réseau de confiance devrait avoir peu ou pas d’interférence avec le fonctionnement quotidien du système. En fin de compte, ce sont les logiciels, la cryptographie et les systèmes distribués qui sont responsables de la protection des soldes des utilisateurs, du code des contrats intelligents et de l’état.

Parfois, il est nécessaire de modifier le protocole de la blockchain pour améliorer les intérêts des utilisateurs. La communauté peut vouloir résoudre des problèmes de configuration, ajouter de nouvelles fonctionnalités ou réagir à des vulnérabilités critiques qui menacent l’intégrité du système. Cela nécessite une intervention humaine et ne peut être appelé que 0,0001 % du temps.

Les systèmes de gouvernance sont responsables de la mise en œuvre de l’intervention humaine, et plusieurs approches ont émergé au fil des ans :

• Partis politiques totalitaires : Les partis unilatéraux peuvent décider individuellement de la manière de mettre à niveau le système (de nombreux projets, y compris BTC, ont commencé de cette façon).
• Consensus approximatif : la majorité des participants ont déclaré qu’ils étaient prêts à déployer la mise à niveau, à déterminer le jour de la marque, puis à effectuer la mise à niveau le jour de la marque (BTC/ETH).
• Accord de vote : Tous les partis participent à l’élection et votent explicitement pour approuver ou non l’escalade.
• Pas d’interférence : les contrats intelligents peuvent être immuables et le système ne peut jamais être modifié.

En plus de ce qui précède, la communauté peut également décider de nommer un comité de sécurité comme option complémentaire à la gouvernance pour agir rapidement en cas d’urgence.

Le Conseil de sécurité n’arrête pas l’attaque. Il s’agit d’un mécanisme passif qui fonctionne parallèlement à la gouvernance lorsque les fonds de l’utilisateur d’un protocole blockchain ou la fiabilité/performance du système sont attaqués.

Enfin

Toutes les discussions autour des protocoles blockchain, de la gouvernance et des comités de sécurité sont cruciales. L’existence de cette discussion est ce qui rend les crypto-monnaies si spéciales.

Il s’agit d’un bon exemple d’ingénierie de confiance : une discipline d’ingénierie qui se concentre sur l’identification, la mesure et la réduction/élimination des éléments de confiance dans un système.

Dans le domaine des crypto-monnaies, nous nous concentrons sur la construction de systèmes qui non seulement protègent les utilisateurs contre les puissants opérateurs de systèmes, mais leur permettent également de fonctionner de manière fiable (en toute sécurité) dans les conditions les plus défavorables.

C’est pourquoi il est sain que les membres de la communauté soient sceptiques quant au rôle du comité de sécurité, mais ils ont la responsabilité de trouver de meilleures solutions en cas d’urgence pour protéger les fonds des utilisateurs de manière réactive.

J’espère que cet article vous expliquera pourquoi les comités de sécurité sont utiles, ils sont nécessaires aujourd’hui, mais ils ne sont qu’une petite partie de l’architecture plus large des systèmes de contrats intelligents.