Des transactions Ethereum réversibles : la nouvelle idée délirante de ces universitaires

Une fausse bonne idée ? – Ethereum (ETH) est le berceau d’une innovation vibrante via l’essor de la finance décentralisée (DeFi). Cependant, la fiabilité des smart contracts n’est pas absolue et a engendré de nombreux hacks. C’est pour cela qu’une équipe de chercheurs a abordé un concept surprenant : celui des transactions réversibles sur Ethereum. 

Des transactions réversibles sur Ethereum

L’écosystème de la finance décentralisée (DeFi) n’a cessé d’innover depuis sa naissance à la fin de l’année 2019. En effet, celui-ci propose de décentraliser les services financiers habituels pour que ces derniers soient accessibles à tous.

Cependant, la DeFi fait face à un problème de taille : les hacks. En effet, rien qu’au cours de l’année 2021, les pirates ont dérobé plus de 14 milliards de dollars au sein de l’écosystème crypto. De son côté, la DeFi comptabilise, à elle seule, 3 milliards de dollars de pertes suite à des failles ou bugs de smart contract. 

Ce bilan douloureux a poussé une équipe de chercheurs de Stanford à proposer une solution pour le moins surprenante, en imaginant des transactions réversibles sur Ethereum :

« Nous avons conçu des standards de jetons qui sont frères et sœurs de l’ERC-20 et de l’ERC-721 et qui permettent d’inverser les transactions (lorsqu’il y a suffisamment de preuves pour le faire). Nous avons écrit un article à leur sujet et nous avons mis en œuvre quelques prototypes. Ces normes de jetons sont respectivement intitulées ERC-20R et ERC-721R. »

Fonctionnement des ERC-20R et ERC-721R

Vous l’aurez compris. Ces nouveaux standards de jetons viennent améliorer deux des standards les plus utilisés sur Ethereum : 

• ERC-20, le standard des jetons ; 
• ERC-721, le standard des NFT. 

Ainsi, ces jetons offrent un recours en cas de hack. En effet, si un hacker réussit à dérober ce type de jeton sur un protocole, il sera possible de mettre en place un processus de récupération en 5 étapes : 

1. La victime demande un gel des fonds dérobés. Celle-ci va publier une demande de gel sur le contrat de gouvernance. Le demandeur doit fournir des preuves justifiant le gel ;
2. Des juges acceptent ou refusent le gel. Un consortium décentralisé de juges va voter en faveur ou contre la proposition au cours d’une période de délibération de deux jours. Si les juges acceptent la demande, ils vont procéder au gel via le contrat de l’ERC-20R ou l’ERC-721R ;
3. Exécution du gel. Le transfert des fonds gelés ne sera plus possible ;
4. Le procès. La victime ainsi que le hacker pourront présenter des preuves pour soutenir leur version des faits à un panel décentralisé de juges. Ces derniers vont statuer sur le cas et décider d’appeler, ou non, la fonction qui va inverser la transaction ;
5. Inversion de la transaction. Si les juges ont statué en faveur de la victime la transaction est inversée et les fonds restitués. 

En pratique, ce type de jeton aurait pu permettre à de nombreux protocoles de récupérer les fonds suite à une attaque. Cependant, cela lève une série de questionnements philosophiques et idéologiques. 

Les impacts sur la décentralisation d’Ethereum

Bien que cette proposition parte d’un bon sentiment, celle-ci présente de nombreuses faiblesses. En effet, le caractère immuable est central à l’écosystème des blockchains. Par conséquent, la mise en place des jetons ERC-20R et ERC-721R engendre une remise en question profonde de cette immuabilité. 

De surcroît, la décision relative à l’inversion d’une transaction est remise dans les mains d’un acteur centralisé. Par conséquent, bien que le consortium soit décentralisé, la décision revient à une poignée d’acteurs qui pourraient servir leurs propres intérêts. 

De plus, cette idée se base sur une énième gouvernance décentralisée. Pourtant, au fil des expériences, de nombreuses faiblesses ont été décelées dans ce type de gouvernance. En effet, celles-ci s’avèrent être grandement centralisées dans la plupart des cas. 

Selon le dernier rapport de Chainalysis sur le sujet, moins d’1% des adresses détiennent 90 % de la puissance de vote. 

Le frontrunning : la solution de Peckshield

Évidemment, ces chercheurs de Stanford ne sont pas les premiers à avoir imaginé des solutions aux problèmes des hacks.  Effectivement, la société Peckshield, spécialisée dans la sécurité des blockchains, a proposé une toute autre solution. Contrairement aux transactions réversibles, la solution de Peckshield vise à intervenir en amont de l’attaque. 

Concrètement, la solution baptisée « KillSwitch » vise à détecter les transactions de hacks au moment où elles surviennent et à prendre des mesures avant que la transaction ne soit validée. Ce service utilisera une méthode appelée frontrunning pour prendre de court les hackers. 

« KillSwitch vise à détecter les transactions de hack avant leur inclusion dans le bloc et à prendre des mesures d’urgence pour bloquer l’attaque ou empêcher le vol des actifs. Il s’agit en fait d’une protection DeFi basée sur le frontrunning. »

Déclaration de Peckshield

Pour ce faire, KillSwitch va mettre en place des programmes chargés de surveiller la mempool. Si une transaction réunissant les conditions définies en amont est détectée, le programme va « frontrunner » la transaction pour prévenir l’attaque. 

« La condition de déclenchement capture le fait d’une perte significative due à un hack et nécessite de connaître l’adresse du protocole, le bien, et un pourcentage de perte. Pour les biens multiples, nous spécifions la perte pour chacun. »

Déclaration de Peckshield

En fait, cette solution vise à résoudre le problème en amont sans consortium décentralisé de juges. 

Notons tout de même que chaque protocole devra paramétrer KillSwitch. De surcroît, bien que la transaction d’urgence soit envoyée par KillSwitch, celle-ci devra en amont être signée par l’équipe du protocole pour qu’elle puisse en même temps mettre en pause le protocole en cas d’attaque.

La dernière attaque d’envergure a impacté le market maker Wintermute. Au total, 160 millions de dollars ont été dérobés à cause d’une faille dans l’outil Profanity.