Après plusieurs attaques DeFi en avril, la discussion sur la sécurité dans l’industrie de la finance décentralisée s’oriente clairement vers d’autres sujets. Auparavant, ce que l’on examinait le plus souvent dans les protocoles DeFi, c’était si les contrats intelligents avaient été audités et s’il existait des vulnérabilités dans le code ; mais Andre Cronje, fondateur de Flying Tulip, a déclaré récemment, lors d’une interview accordée à Cointelegraph, que les risques auxquels font face aujourd’hui de nombreux protocoles DeFi ne proviennent plus seulement du code côté chaîne, mais aussi des droits de mise à niveau, de la gouvernance multisig, des infrastructures hors chaîne et des processus d’exploitation de l’équipe.
DeFi n’est plus du code impossible à modifier
Cronje a été catégorique : si l’on se réfère aux définitions strictes du début du DeFi — « décentralisé, immuable, sans besoin de confiance » — alors de nombreux protocoles ne peuvent plus être qualifiés de DeFi à proprement parler. Il inclut même Flying Tulip dans ce jugement, affirmant que l’industrie ressemble davantage aujourd’hui à des services financiers lucratifs gérés par des équipes, plutôt qu’à des infrastructures publiques totalement immuables.
Il a déclaré : « Je pense que ce que nous avons aujourd’hui, y compris Flying Tulip, n’est plus du DeFi. Ce n’est pas une finance décentralisée, ni un code impossible à falsifier ; c’est une activité rentable que l’équipe gère. »
Ces propos mettent en lumière une réalité particulièrement délicate pour l’industrie DeFi : de nombreux protocoles continuent d’utiliser la narration, l’évaluation et le langage de marque du DeFi, mais dans la pratique, ils s’appuient depuis longtemps sur une forte maîtrise humaine et des processus hors chaîne.
Le plus grand risque du DeFi n’est plus seulement une faille de contrat
Cronje estime que, dans les débuts du DeFi, le modèle de sécurité était relativement simple : après le déploiement du protocole, les contrats intelligents étaient immuables, et les utilisateurs supportaient principalement le risque lié à la logique du code. Mais aujourd’hui, les systèmes DeFi sont généralement beaucoup plus complexes : un protocole peut utiliser un proxy upgrade pour mettre à niveau des contrats, gérer des droits clés via multisig, dépendre de fournisseurs d’infrastructures externes, et en cas de problème, faire réagir l’équipe centrale lors de la gestion de crise.
Cela signifie que les problèmes de sécurité ne se limitent plus à « est-ce que le code a un bug ? », mais s’étendent à : « qui a le droit de mettre à niveau le contrat », « qui détient le multisig », « le timelock est-il assez long », « les serveurs hors chaîne ou les interfaces de gestion peuvent-ils être attaqués », « l’équipe peut-elle réagir correctement en situation anormale ».
Cronje souligne que l’industrie a par le passé trop concentré son attention sur l’audit des contrats intelligents, mais que récemment, de nombreuses attaques ressemblent davantage à des problèmes de sécurité typiques du Web2 traditionnel ou de TradFi : par exemple, une intrusion dans des droits d’accès à l’infrastructure, des attaques d’ingénierie sociale, une procédure de gestion détournée, ou encore le compromis d’un nœud de permission unique.
Autrement dit, le DeFi ne n’a pas pas besoin d’audit, mais « l’audit seul ne suffit plus ». Lorsqu’un protocole peut être mis à niveau, administré et qu’il peut être modifié par des interventions humaines, il doit aussi reconnaître qu’il présente des risques d’exploitation similaires à ceux auxquels sont confrontées les institutions financières traditionnelles.
Flying Tulip ajoute un mécanisme de coupe-circuit des retraits
Dans ce contexte, Flying Tulip a récemment ajouté un mécanisme de coupe-circuit des retraits (withdrawal circuit breaker). Ainsi, lorsque le protocole détecte des sorties de fonds anormales, il peut retarder ou mettre en file d’attente le traitement des retraits. Cronje insiste sur le fait que ce mécanisme n’a pas pour but de bloquer définitivement les retraits, ni de permettre à l’équipe de geler arbitrairement des fonds : il s’agit plutôt d’obtenir une courte fenêtre de réaction lorsque la situation devient anormale.
Dans le cas de Flying Tulip, ce mécanisme permettrait d’accorder à l’équipe environ 6 heures. Cronje estime que si la taille de l’équipe est plus petite, ou si les membres ne sont pas assez globalisés, il faudra peut-être 12 à 24 heures, voire davantage, pour finaliser les vérifications internes, les signatures et la gestion de l’incident au moment où l’attaque survient.
La logique de ce type de conception ressemble fortement à celle des suspensions de transactions ou des portes de contrôle du risque dans les marchés financiers traditionnels : lorsqu’un système fait face à une liquidité anormale ou à une sortie d’actifs, il ne conclut pas immédiatement que toutes les transactions sont invalides ; il ralentit d’abord le système pour empêcher qu’un attaquant ne transfère l’ensemble des fonds en quelques minutes.
Cependant, Cronje rappelle aussi que le coupe-circuit ne peut être qu’un élément d’une architecture de sécurité en couches, et ne doit pas être considéré comme une solution miracle. La véritable protection doit toujours inclure : audit, multisig décentralisé, timelock, processus de gouvernance, mécanismes de surveillance et contrôle des permissions.
Le coût du coupe-circuit : protéger les utilisateurs, ou créer une nouvelle porte dérobée de centralisation ?
Ce mécanisme déclenche pourtant immédiatement une controverse dans la communauté des développeurs DeFi. Curve Finance et le fondateur de Yield Basis, Michael Egorov, sont d’accord : les récentes attaques ont bien exposé le risque de centralisation hors chaîne. Mais il reste très vigilant face à la solution consistant à « ajouter un contrôle d’urgence humain ».
Egorov indique que de nombreux événements majeurs du DeFi récemment ne résultaient pas d’un piratage des contrats intelligents eux-mêmes, mais d’une défaillance ponctuelle hors chaîne. Il cite notamment des événements liés à rsETH : il affirme que les contrats intelligents d’Aave, de Kelp et de LayerZero n’ont pas été piratés ; le problème se situait en réalité dans l’infrastructure hors chaîne.
Ainsi, selon Egorov, si le risque le plus important vient déjà des personnes et des permissions hors chaîne, ajouter un mécanisme de coupe-circuit contrôlé par des humains ne ferait peut-être que concentrer davantage le pouvoir entre les mains d’un petit nombre de signataires ou de gestionnaires.
Egorov craint qu’en cas d’autorisation du contrôle d’urgence permettant aux signataires de modifier le contrat, de suspendre les retraits ou d’intervenir sur les flux de fonds, si ces signataires sont à leur tour attaqués, le mécanisme initialement conçu pour protéger les utilisateurs puisse devenir l’outil permettant aux pirates d’assécher les fonds, ou une porte dérobée pour geler des actifs de manière centralisée. Sa conclusion est que la conception du DeFi devrait réduire au maximum les points de défaillance uniques d’origine humaine, plutôt que de résoudre un problème causé par des permissions humaines en ajoutant encore plus de permissions humaines.
Le DeFi doit admettre ce qu’il est devenu
Le désaccord entre Cronje et Egorov, en apparence centré sur le débat concernant le coupe-circuit, est en réalité un débat sur l’identité du DeFi. La position de Cronje est davantage pragmatique : puisque beaucoup de protocoles ne sont déjà plus des contrats immuables, mais des produits financiers dotés de droits de mise à niveau, de processus de gestion et d’activités d’exploitation menées par une équipe, il faut reconnaître cette réalité et mettre en place des mesures de contrôle du risque adaptées.
Egorov se rapproche, lui, des puristes du DeFi : si la sécurité du DeFi repose sur la décentralisation, alors la solution ne devrait pas consister à confier davantage de contrôle à des humains ; elle devrait concevoir des systèmes qui dépendent de moins d’interventions humaines.
Les deux parties reconnaissent en fait la même chose : aujourd’hui, le plus gros problème du DeFi ne tient plus seulement à la qualité du code des contrats, mais à qui les utilisateurs finissent par faire confiance. Si un protocole peut être mis à niveau, peut suspendre, peut mettre en file d’attente des retraits, et peut modifier la logique fondamentale via un multisig, alors les risques assumés par les utilisateurs ne sont plus uniquement des risques liés aux contrats intelligents ; ils incluent aussi les risques de gouvernance de l’équipe, les risques liés aux signataires, les risques d’infrastructure et les risques opérationnels.
Cet article, le DeFi est-il encore décentralisé ? Andre Cronje : admettez-le, la plupart des protocoles sont un code modifiable — Publication initiale : Chaîne News ABMedia.
