Je souhaite partager quelque chose d'assez important que vous ne comprenez peut-être pas encore bien — c’est la vulnérabilité de reentrancy dans les contrats intelligents. Si vous développez des dapps ou travaillez avec la blockchain, c’est une connaissance indispensable.

Quel est le problème fondamental de la reentrancy ? Il survient lorsqu’un contrat intelligent appelle un autre contrat, et que ce dernier peut rappeler le contrat d’origine pendant qu’il est encore en exécution. Un attaquant peut exploiter ce laps de temps pour voler de l’argent.

Imaginez que ContractA possède 10 Ether et que ContractB y a déjà envoyé 1 Ether. Lorsqu’il appelle la fonction de retrait, ContractA vérifie si le solde est supérieur à 0, et si c’est le cas, il envoie l’Ether en retour. Mais voici le problème — ContractA ne met à jour le solde qu’après avoir envoyé l’argent. Donc, pendant l’envoi, si ContractB a une fonction fallback, il peut rappeler la fonction de retrait de ContractA. Comme le solde n’a pas encore été mis à jour, la vérification réussira à nouveau, et il recevra encore 1 Ether. Cette boucle continue jusqu’à ce que ContractA n’ait plus d’argent.

Je vais vous présenter trois méthodes pour protéger le contrat contre cette attaque de reentrancy.

La première méthode consiste à utiliser le modificateur nonReentrant. L’idée est très simple — vous verrouillez le contrat pendant l’exécution d’une fonction. Si quelqu’un tente de rappeler cette fonction, la requête sera rejetée car le contrat est verrouillé. Vous devez terminer l’exécution du code, puis déverrouiller, et à ce moment-là, la vérification échouera si une tentative de réappel est faite.

La deuxième méthode consiste à utiliser le modèle Checks-Effects-Interactions. Au lieu de mettre à jour le solde après l’envoi, vous le mettez à jour immédiatement après la vérification, mais avant l’envoi. De cette façon, même si un autre contrat rappelle la fonction, le solde sera déjà à 0, et la vérification échouera. C’est pourquoi l’ordre est crucial — vérifier d’abord, puis appliquer les effets, et enfin interagir avec d’autres contrats.

La troisième méthode consiste à créer un GlobalReentrancyGuard séparé, particulièrement utile si vous avez plusieurs contrats qui interagissent. Au lieu de protéger chaque fonction individuellement, vous créez un contrat de garde commun, qui stocke l’état de verrouillage à un endroit central. Lorsqu’un contrat tente d’appeler une fonction protégée, il vérifie avec ce garde. Si le garde indique que le contrat est verrouillé, la transaction est rejetée. Cette approche est très puissante car elle empêche la reentrancy non seulement dans un seul contrat, mais aussi entre plusieurs contrats.

Je vous recommande d’appliquer ces trois techniques selon la situation. Pour les fonctions de retrait ou de transfert d’actifs, utilisez toujours nonReentrant ou Checks-Effects-Interactions. Et si votre projet comporte un système de contrats complexes, envisagez d’utiliser le GlobalReentrancyGuard comme couche de protection supplémentaire.

C’est l’une des vulnérabilités les plus courantes qui causent de grosses pertes, donc comprendre la reentrancy est crucial si vous souhaitez écrire des contrats intelligents sécurisés.