Beaucoup de gens parlent de sécurité, leur première réaction est souvent de penser aux pirates, aux vulnérabilités, aux prêts flash, aux contrats piratés. Mais si vous mettez vraiment Plasma à l'échelle du « réseau de liquidation de stablecoins », vous découvrirez que les accidents les plus dangereux de l'avenir ne proviennent peut-être pas d'attaques externes, mais sont plus susceptibles de provenir de l'intérieur : configuration des permissions, structure de gouvernance, modifications des paramètres, processus de mise à jour, ainsi que les frontières des permissions de signature multiple et d'administrateur. Car une fois que le réseau de liquidation gère des fonds à une échelle plus grande, sa sécurité ne dépend plus seulement de « l'absence de failles dans le contrat », mais de « qui détient les boutons clés du système, comment les utiliser, et s'il est possible de corriger une erreur ». Ce que je veux écrire, c'est que lorsque l'écosystème Plasma se développe, le plus susceptible de provoquer une crise n'est pas un pirate, mais le risque systémique des permissions et de la gouvernance — c'est-à-dire « ne laissez pas le système s'effondrer à cause de ses propres personnes ».
Commençons par un fait très réaliste : les produits liés aux stablecoins ont souvent des permissions lourdes. Les systèmes de paiement doivent contrôler le budget et la liste blanche, les coffres de rendement doivent ajuster les paramètres stratégiques, le marché des prêts doit ajuster les modèles de taux d'intérêt et les seuils de liquidation, et le côté commerçant doit configurer les règles de gestion des risques et la logique de remboursement. Tant que vous souhaitez offrir une expérience de niveau paiement, les permissions sont inévitables. Le problème est que plus il y a de permissions, plus le risque est grand ; et le véritable point de risque n'est souvent pas « malveillant », mais « erreur de manipulation ». Une erreur dans la modification d'un paramètre, un échec de mise à jour, une omission dans la configuration des permissions peuvent provoquer des incidents en chaîne : fonds bloqués, retards de rachat, paiements explosés, logique de liquidation anormale, voire provoquer une panique chez les utilisateurs. Le système de paiement craint toujours moins les petits bugs que « la confiance des utilisateurs étant brisée en un instant ».
Ainsi, dans l'écosystème Plasma, le premier principe de la gouvernance des permissions devrait être : minimum de permissions + limites claires. Toute fonction d'administrateur pouvant être appelée sans restriction, toute permission permettant de modifier des paramètres clés à volonté, tout contrat qui peut être « mis à jour à tout moment », deviendra une bombe à retardement lorsque l'échelle augmentera. Vous pouvez ne pas rechercher une décentralisation complète, mais vous devez rendre les risques clés contrôlables : quels paramètres peuvent être modifiés, lesquels ne peuvent pas l'être ; les paramètres modifiables ont-ils une limite ; y a-t-il un délai pour les modifications ; nécessite-t-il une signature multiple ; y a-t-il des annonces publiques ; la communauté ou les utilisateurs sont-ils autorisés à se retirer à l'avance ? Plus cela ressemble à une infrastructure financière, plus ce type de « retenue institutionnelle » est nécessaire.
Le deuxième point clé est le processus de mise à jour. De nombreux projets aiment utiliser des « contrats pouvant être mis à jour » pour améliorer l'efficacité des itérations, mais ce que les utilisateurs voient souvent est un autre signal : si vous pouvez modifier le code à tout moment, mes fonds sont-ils donc toujours incertains ? Pour un réseau de liquidation, la mise à jour n'est pas une action technique, mais une action de confiance. Une manière plus mature est de transformer la mise à jour en un processus prévisible : publier des notes de changement, établir un timelock (délai d'effet), fournir des avertissements de risque et des plans de migration, et activer les permissions d'urgence uniquement dans des situations critiques, toutes les actions étant traçables et auditées. Vous n'avez pas besoin de vous lier les mains, mais vous devez faire en sorte que les mises à jour ne ressemblent plus à une « opération secrète », mais à une « fenêtre de changement du système bancaire » — notification préalable, vérifiable, pouvant être annulée ou compensée.
Le troisième point clé est la signature multiple et le risque personnel. Beaucoup de gens pensent que la signature multiple est sécurisée, mais en réalité, elle ne fait que transformer un point unique en plusieurs points ; ce qui est vraiment important, c'est qui sont les signataires, si la distribution est suffisamment indépendante, s'il y a un processus opérationnel clair, s'il existe une protection contre les attaques d'ingénierie sociale, et s'il y a un plan d'urgence en cas de besoin. Le système de stablecoins craint le plus la « concentration des permissions + des processus aléatoires », car dès qu'une erreur interne se produit ou que l'on est victime d'ingénierie sociale, les conséquences sont plus difficiles à réparer que celles d'une attaque externe. Pour l'utilisateur, il ne se soucie pas de la gestion interne, il se préoccupe seulement de savoir si « les fonds peuvent soudainement rencontrer des problèmes ». Ainsi, la structure de gouvernance doit être conçue de manière à ce que « même si quelqu'un fait une erreur, le système ne s'effondrera pas immédiatement ».
Le quatrième point clé est de traiter le « risque de paramètre » comme un objet de contrôle des risques, et non comme un outil opérationnel. De nombreux incidents ne sont pas dus à des failles de code, mais à des paramètres réglés trop agressivement : pour une croissance à court terme, augmenter le montant des paiements, pour attirer des fonds, augmenter l'intensité des incitations, pour améliorer le rendement, maximiser le risque stratégique. À court terme, les données peuvent paraître très belles, mais à long terme, cela revient à poser des mines. Le principe d'un réseau de liquidation devrait être plus conservateur : il vaut mieux croître lentement tout en garantissant que le système peut résister sous pression, en particulier en garantissant que le rachat et la disponibilité des fonds ne soient pas sacrifiés. Les utilisateurs de stablecoins ont de la patience pour « la lenteur », mais pas pour « les problèmes ».
Si l'écosystème Plasma veut se développer à une plus grande échelle, le champ de bataille principal de la sécurité passera progressivement de « prévenir les pirates » à « gérer les permissions ». La présence de failles dans le contrat est importante, mais il est encore plus important de savoir qui peut actionner les boutons clés, comment ils le font, s'il y a des délais et des limites avant d'agir, et s'il est possible de limiter les pertes en cas d'erreur. Pour que les permissions et la gouvernance soient institutionnalisées, processus et vérifiables, Plasma ressemblera vraiment à un réseau de liquidation ; sinon, même avec une technologie solide, la confiance peut être brisée par une simple erreur interne ou un incident de gouvernance.
