Dans le monde de la cryptomonnaie, une simple erreur de clic peut déclencher une « catastrophe numérique ». L’un des cauchemars les plus courants est d’envoyer des actifs vers la mauvaise blockchain. Par exemple, vous souhaitez envoyer des ETH à une adresse sur le testnet Sepolia d’Ethereum, mais par erreur, vous les envoyez à une adresse sur le réseau principal d’Ethereum. Dans ce cas, est-il encore possible de récupérer les fonds transférés par erreur depuis le réseau principal ? La possibilité de retrouver les actifs dépend principalement du type d’adresse de destination. Cet article analysera différentes situations.
1. Scénario 1 : l’adresse de destination est une EOA
Une (Compte Externe Contrôlé) (EOA) est ce que nous appelons couramment un portefeuille contrôlé directement par une clé privée ou une phrase de récupération.
Conditions préalables pour récupérer les actifs :
- Vous avez envoyé des actifs à une adresse EOA.
- Vous possédez la clé privée ou la phrase de récupération de cette adresse EOA cible. (Généralement, il s’agit d’un autre portefeuille que vous contrôlez, ou celui d’un ami prêt à coopérer).
- La chaîne cible est compatible EVM.
Méthode de récupération des actifs :
Le titulaire de la clé privée de l’adresse EOA de réception peut simplement retirer les fonds sur la chaîne cible.
2. Scénario 2 : l’adresse de réception est un contrat
C’est l’un des scénarios les plus désespérés. Étant donné que l’adresse d’un contrat intelligent n’est pas générée par une clé privée, personne ne possède la clé privée du contrat. Par conséquent, il n’est pas possible de contrôler le contrat de la même manière qu’une EOA. De plus, si le contrat n’a pas été préalablement programmé pour gérer “les transferts d’erreur” avec une fonction de secours, les fonds envoyés par erreur risquent d’être verrouillés définitivement dans le contrat, personne ne pouvant les retirer.
Cependant, dans certains cas, il existe encore une lueur d’espoir. Nous allons d’abord élaborer un scénario où des ETH sont verrouillés sur le réseau principal d’Ethereum, puis expliquer comment récupérer ces fonds.
2.1. Présentation du scénario
Ce scénario peut être résumé ainsi : un utilisateur souhaite appeler un contrat sur le testnet Sepolia et transférer des ETH dans ce contrat pour minter des tokens, mais lors de l’envoi, il s’est connecté par erreur au réseau principal, ce qui a entraîné le verrouillage des ETH dans un contrat sur le réseau principal. La construction précise du scénario est la suivante :
1. Sur le testnet Ethereum Sepolia, le projet (EOA) déploie un contrat de réalisation, supposons que ce contrat a pour fonction principale que l’utilisateur dépose des ETH pour minter des AToken, une version simplifiée de la fonction mintTokens. Supposons que l’adresse du déploiement soit A. À noter que, dans A, il n’existe aucune fonction permettant de retirer directement des ETH.
2. Sur le testnet Ethereum Sepolia, le projet déploie un contrat de usine (factory), ce contrat permet, en utilisant l’adresse du contrat de réalisation et un salt, de déployer un contrat proxy minimal (Clones) pointant vers le contrat de réalisation (comme la fonction deployProxyByImplementation). Admettons que cette usine ait été déployée à l’adresse B. En appelant la fonction deployProxyByImplementation avec l’adresse du contrat A comme _implementation,** on déploie un contrat proxy pointant vers A, à l’adresse C.**
3. Un utilisateur souhaite, sur le testnet Sepolia, minter des AToken en transférant ETH, et envoie une transaction pour appeler le contrat proxy C. Normalement, le contrat proxy C appelle la fonction mintTokens du contrat A pour effectuer l’opération. Cependant, l’utilisateur s’est connecté par erreur au réseau principal. Il a donc envoyé des ETH directement à l’adresse C sur le réseau principal.** À ce moment-là, aucune contrat n’est déployé à l’adresse C du réseau principal, et personne ne possède la clé privée de C, donc l’argent de l’utilisateur est temporairement verrouillé à cette adresse C du réseau principal.
2.2. Points clés
Avant de présenter une solution de secours concrète, il est important de connaître quelques notions fondamentales nécessaires.
2.2.1. create & create2
create et create2 sont deux méthodes courantes pour déployer un contrat en Solidity.
- create déploie un contrat dont l’adresse est déterminée par l’adresse de l’expéditeur et le nonce de ce compte, indépendamment du contenu du contrat.
- create2 déploie un contrat dont l’adresse dépend non seulement de l’adresse de l’expéditeur, mais aussi de quatre paramètres :
- 0xff
- l’adresse du contrat à déployer (address))
- la valeur de salt (entière) fournie en paramètre
- le bytecode d’initiation du contrat (init_code)
2.2.2. Clones (Proxy minimal)
https://docs.openzeppelin.com/contracts/4.x/api/proxy#clones
Les Clones, ou contrats proxy minimaux, sont une technique pour déployer à coût réduit (gas faible) un contrat proxy pointant vers un contrat de réalisation spécifique. Dans le contrat Clones, le déploiement d’un proxy via create ou create2 est possible, par exemple avec la fonction cloneDeterministic, qui utilise create2.
Dans la fonction cloneDeterministic, le bytecode du proxy déployé est très court, par exemple : 0x363d3d373d3d3d363d73<adresse du contrat de réalisation>5af43d82803e903d91602b57fd5bf3. L’adresse du proxy est calculée en intégrant l’adresse du déployeur, le salt, et le bytecode, mais elle n’est pas dépendante du contenu du contrat de réalisation.
Selon la fonction cloneDeterministic, le proxy déployé via create2 a une adresse qui dépend du déployeur, du salt, et de l’adresse du contrat de réalisation, mais pas du bytecode du contrat de réalisation lui-même.
2.3. Solution de secours
Nous allons maintenant expliquer comment récupérer les ETH présents à l’adresse C du réseau principal. L’idée principale est de déployer un contrat à cette adresse, qui prendra en charge la gestion du fonds, et pourra ainsi récupérer et transférer les ETH.
Voici les étapes détaillées :
1. Déployer sur le réseau principal un contrat usine (factory) à la même adresse B que sur le testnet. La raison est que, lors du déploiement via cloneDeterministic, l’adresse du proxy dépend de l’adresse du contrat usine. En retrouvant la transaction de déploiement de l’usine sur le testnet, on peut calculer le nonce du déployeur à ce moment-là. Sur le réseau principal, en utilisant ce nonce, on déploie à nouveau le même contrat usine, ce qui donne la même adresse B.
2. Déployer un contrat de réalisation (implementation) à la même adresse A que sur le testnet. Le déploiement du contrat de réalisation n’est pas dépendant du bytecode, mais de l’adresse du déployeur et du nonce. On peut donc déployer un contrat compatible à l’adresse A, en ajustant le nonce du déployeur pour correspondre à celui du testnet. Ce contrat doit disposer d’une fonction permettant de retirer des ETH.
3. Déployer sur le réseau principal un contrat proxy à la même adresse C que sur le testnet. En utilisant la transaction de déploiement du proxy sur le testnet (avec le même salt), on peut calculer l’adresse C. En déployant le proxy avec ce même salt, on obtient le même contrat proxy à l’adresse C.
4. Appeler la fonction de retrait dans le contrat proxy C pour transférer les ETH vers le portefeuille souhaité. Le propriétaire (EOA) appelle la fonction de retrait du contrat proxy C, en spécifiant une adresse de réception, pour récupérer les ETH verrouillés.
#最小代理合约（Clones）## 2.4. Résumé
D’après cette méthode de secours, la récupération des fonds dépend de plusieurs conditions. Par exemple, l’adresse du déployeur n’a pas été utilisée avec un nonce supérieur à celui du déploiement initial, le contrat verrouillant les fonds possède une fonction de retrait ou une méthode pour déployer une telle fonction, ou via des mécanismes d’upgrades ou de proxies (Clones).
En conclusion, il faut être extrêmement prudent lors de chaque transaction, vérifier attentivement chaque étape, et avant d’interagir avec un contrat, utiliser des outils de scan de vulnérabilités comme AI SCAN de ZAN pour tester la sécurité. En cas de fonds bloqués, ne pas paniquer : contactez l’équipe de sécurité contractuelle de ZAN pour une assistance de récupération.
Cet article a été rédigé par ZANTeam (@zan_team) & AntChain OpenLabs (@AntChainOpenLab), avec Cara (@Cara6289).
