Clés d’administration et immuabilité

Curiosité

1. Qu’est-ce qu’une autorité de frappe et que permet-elle à son détenteur ?
2. Pourquoi un proxy upgradable peut-il être à la fois un dispositif de sécurité et une porte dérobée ?
3. Si la suppression des clés d’administration élimine les attaques mais empêche également les correctifs, qui décide quel risque une communauté accepte ?

Explorer

Partie IClés d’administration : la racine des vols par contrat

1. De nombreux rug pulls remontent à un pouvoir conservé. Une autorité de frappe permet à son détenteur de créer un nombre illimité de jetons et de les vendre sur le marché à sa guise. Une autorité de gel ou une liste noire empêche certains détenteurs de déplacer leur solde. Une taxe modifiable par le propriétaire peut porter les frais de vente à cent pour cent, bloquant la liquidité sur place. Chacun de ces pouvoirs est une clé que quelqu’un détient, et chacun peut être retourné contre ceux-là mêmes qu’il était censé servir.
2. Les proxys upgradables séparent le stockage de la logique : l’état réside à une adresse tandis que le code s’exécute depuis une autre, qu’un administrateur peut remplacer à tout moment. Cela permet d’appliquer des correctifs lorsqu’on découvre des bugs, mais cela signifie aussi que les règles d’un jeton peuvent changer rétroactivement pour tous ses détenteurs. Lors d’exploits DeFi, des mises à niveau de proxy ont été détournées pour rediriger des fonds ou modifier le comportement d’un protocole après son déploiement. Le jeton Squid Game (novembre 2021) montre où mène un contrôle conservé : son contrat permettait à n’importe qui d’acheter mais empêchait les détenteurs ordinaires de vendre, et lorsque ses créateurs ont encaissé leurs gains, le prix est tombé quasiment à zéro en quelques minutes.
3. Le compromis est structurel. Supprimez la clé de frappe et personne ne peut créer de jetons supplémentaires ; supprimez la possibilité de retirer la liquidité du pool et personne ne peut en extraire les réserves. Le prix à payer est qu’aucun développeur, auditeur ou membre de la communauté ne peut corriger un bug, réagir à une urgence ou ajuster les paramètres quand les conditions changent. Dans un marché sans permission, chaque pouvoir d’administration est à la fois une surface d’attaque et un outil de maintenance. Le camp qu’il sert dépend de la bonne foi du détenteur de la clé et de sa capacité à la garder en sécurité.
4. Les défenses au niveau du portefeuille ne peuvent pas remplacer la conception au niveau du contrat. Un utilisateur peut révoquer les approbations de jetons, éviter de signer des transactions inconnues et vérifier les adresses des contrats avant d’interagir, mais ces pratiques ne servent à rien face à une autorité de frappe activement utilisée ou à une mise à niveau de proxy qui change les règles en cours de transaction. Pour les jetons SPL, l’autorité de frappe est toujours définie à la création et le reste tant qu’elle n’est pas mise à None ; l’autorité de gel est facultative et, si elle est omise, ne peut jamais être ajoutée. Dans tous les cas, une autorité active fonctionne quelle que soit la prudence de l’utilisateur.
5. La documentation d’OpenZeppelin sur les proxys rend l’architecture explicite : un contrat d’implémentation contient la logique, tandis qu’un proxy conserve l’état et lui transmet chaque appel via delegatecall. Mettre à niveau signifie faire pointer le proxy vers une nouvelle adresse d’implémentation. C’est ainsi que les équipes livrent des correctifs, mais cela signifie aussi que tout détenteur de l’autorité de mise à niveau peut remplacer l’ensemble des règles en une seule transaction. La distinction entre un correctif et un vol est purement comportementale, et non technique.
6. L’inspection du contrat d’un jeton révèle quelles clés sont actives. Sur une chaîne EVM, vérifiez si le contrat comporte un rôle de propriétaire et s’il se trouve derrière un proxy upgradable ; sur Solana, vérifiez les autorités de frappe et de gel ainsi que toute extension Token-2022, comme un délégué permanent, un transfer hook ou des frais de transfert. Chaque pouvoir absent ou révoqué supprime la classe d’attaque correspondante. Le risque restant se déplace vers les personnes : le phishing, l’usurpation d’identité et la manipulation sociale opèrent entièrement en dehors du code.

Partie IIImmutabilité et absence de clés d’administration

7. De nombreux smart contracts peuvent être modifiés après leur lancement. Sur Solana, les programmes sont modifiables par défaut via une clé dite « upgrade authority » (autorité de mise à niveau) ; sur les chaînes EVM comme Ethereum, les contrats sont immuables, sauf s’ils ont été conçus avec des patterns de proxy qui redirigent l’exécution vers un contrat d’implémentation remplaçable. Cette conception permet de corriger des bugs et d’ajouter des fonctionnalités, mais elle signifie aussi que le code avec lequel les utilisateurs interagissent aujourd’hui n’est pas forcément celui qu’ils ont lu hier.
8. Le risque de la mutabilité, c’est une confiance concentrée. Si un développeur détient une clé d’administration, il peut théoriquement modifier l’offre de tokens, geler les comptes des utilisateurs ou vider les pools de liquidité à tout moment. Cela crée un « mode dieu » qui contredit l’esprit décentralisé de la blockchain. Lorsque The DAO a été piraté en juin 2016, la communauté Ethereum a débattu de l’opportunité d’un hard fork pour annuler le vol — une décision qui a scindé la chaîne en Ethereum et Ethereum Classic. Cet événement a montré que même les changements au niveau du réseau comportent de profonds risques de gouvernance.
9. L’immutabilité élimine entièrement ce risque. En révoquant toutes les autorités administratives — comme les autorités de mint, de gel et de mise à niveau du programme sur Solana — ou en déployant sans proxy ni rôle de propriétaire sur les chaînes EVM, le contrat devient un coffre scellé. Personne ne peut modifier les règles après le déploiement. Le code en production peut être comparé une fois pour toutes au code audité, et il restera tel quel. Cela supprime la menace d’abus de la part d’initiés, mais fige aussi définitivement tout bug éventuel.
10. Le prix de l’immutabilité, c’est la permanence. Si un bug critique existe, aucun correctif n’est possible ; seule une migration vers un nouveau contrat ou un fork du réseau peut y remédier. Cela accroît les enjeux de la vérification avant le lancement. Les équipes doivent investir massivement dans la vérification formelle, un fuzzing approfondi et des audits menés par plusieurs parties avant le déploiement. La charge passe de la maintenance après le lancement à la rigueur avant le lancement. Un seul cas limite négligé devient une caractéristique permanente du système.
11. Bitcoin sert de référence en matière de « neutralité crédible ». Ses règles ne changent que par un large consensus entre des milliers de nœuds indépendants, et non par la décision d’une seule entité. Il n’existe aucune clé d’administration capable de modifier la récompense de bloc ou les règles de validité des transactions. Cette rigidité explique en grande partie pourquoi beaucoup considèrent Bitcoin comme crédiblement neutre : aucune partie ne peut à elle seule en réécrire les règles.
12. Pour les concepteurs de tokens, choisir l’immutabilité signale un engagement en faveur de la transparence. Les utilisateurs peuvent vérifier que le code déployé ne peut pas être modifié. Ce choix implique toutefois d’accepter que les erreurs soient irréversibles. Le compromis est clair : gagner une prévisibilité vérifiable par les utilisateurs, ou conserver de la flexibilité au prix d’un point de défaillance unique et d’un risque d’abus.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Solana Program Library, SPL Token documentation
• OpenZeppelin, 'Proxy Upgrade Pattern' documentation
• Contemporary reporting on the Squid Game token collapse (November 2021)
• Chainalysis, Crypto Crime Report (2024)
• Solana documentation: deploying programs (upgrade authority)
• V. Buterin, 'Credible Neutrality as a Guiding Principle' (2020)