Checks-Effects-Interactions (CEI) en Solidity

A. Mécanisme du pattern CEI

Le principe CEI divise une fonction en 3 phases strictement ordonnées :

Pourquoi cet ordre ?

• Éviter la reentrancy : Si un appel externe (call) est fait avant la mise à jour de l’état, un attaquant peut rappeler la fonction et exploiter l’ancien état.
• Garantir la cohérence : L’état est toujours mis à jour avant qu’un échec externe ne se produise.
• Clarté du code : Séparation logique des étapes.

B. Exemple de code vulnérable (sans CEI)

// ❌ Contrat vulnérable à la reentrancy
contract Bank {
    mapping(address => uint256) public balances;

    function withdraw(uint256 _amount) external {
        // Interaction AVANT l'effect → Risque de reentrancy !
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Transfer failed");

        // Effect (trop tard !)
        balances[msg.sender] -= _amount;
    }
}

Attaque possible :

1. Un attaquant déploie un contrat malveillant avec un fallback() qui rappelle withdraw().
2. Le solde n’est pas encore mis à jour quand le rappel se produit → retrait multiple des mêmes fonds.

C. Exemple de code corrigé (avec CEI)

// ✅ Contrat sécurisé avec CEI
contract Bank {
    mapping(address => uint256) public balances;

    function withdraw(uint256 _amount) external {
        // 1. Checks
        require(balances[msg.sender] >= _amount, "Insufficient balance");

        // 2. Effects
        balances[msg.sender] -= _amount;
        emit Withdrawal(msg.sender, _amount);

        // 3. Interactions (en dernier !)
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Transfer failed");
    }
}

Pourquoi c’est sécurisé ?

• Le solde est mis à jour avant l’appel externe → impossible de rappeler withdraw() avec l’ancien solde.
• Même si call échoue, l’état reste cohérent (pas de double dépense).

D. Cas avancés et pièges courants

1. Les événements (emit) doivent être dans "Effects"

// ❌ Mauvaise pratique : emit après un appel externe
function transfer(address _to, uint256 _amount) external {
    balances[msg.sender] -= _amount;
    (bool success, ) = _to.call{value: _amount}("");
    emit Transfer(msg.sender, _to, _amount); // Trop tard !
}

Risque : Si call échoue, l’événement ne sera jamais émis, ce qui fausse les traces (ex : explorateurs de blockchain).

Correction :

// ✅ emit dans "Effects"
balances[msg.sender] -= _amount;
emit Transfer(msg.sender, _to, _amount); // Avant l'appel externe
(bool success, ) = _to.call{value: _amount}("");

2. Les appels externes "cachés" (ex : bibliothèques)

Même les appels à des bibliothèques ou contrats internes peuvent violer CEI :

// ❌ Appel externe indirect
function updateState() external {
    balances[msg.sender] = 100; // Effect
    ExternalLibrary.doSomething(); // Interaction cachée ! (peut rappeler ce contrat)
}

Solution : Traiter tous les appels externes (même internes) comme des "Interactions".

3. Les boucles avec appels externes

// ❌ Boucle avec interactions → risque de reentrancy à chaque itération
function batchTransfer(address[] calldata _receivers, uint256 _amount) external {
    for (uint i = 0; i < _receivers.length; i++) {
        balances[_receivers[i]] += _amount;
        _receivers[i].transfer(_amount); // Interaction DANS la boucle !
    }
}

Correction :

// ✅ Mettre à jour tous les états AVANT les interactions
for (uint i = 0; i < _receivers.length; i++) {
    balances[_receivers[i]] += _amount;
}
for (uint i = 0; i < _receivers.length; i++) {
    (bool success, ) = _receivers[i].call{value: _amount}("");
    require(success, "Transfer failed");
}

E. Intégration avec d’autres bonnes pratiques

4. Outils pour vérifier le CEI

5. Exemple complet : Contrat de prêt sécurisé

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureLoan is ReentrancyGuard {
    mapping(address => uint256) public balances;
    mapping(address => uint256) public loans;

    // ✅ Respecte CEI + ReentrancyGuard
    function borrow(uint256 _amount) external nonReentrant {
        // 1. Checks
        require(balances[msg.sender] >= _amount, "Insufficient collateral");
        require(loans[msg.sender] == 0, "Already have a loan");

        // 2. Effects
        balances[msg.sender] -= _amount;
        loans[msg.sender] = _amount;
        emit LoanTaken(msg.sender, _amount);

        // 3. Interactions
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Transfer failed");
    }

    // ✅ CEI + Pull Pattern (l'utilisateur doit appeler withdraw)
    function repay() external nonReentrant {
        // 1. Checks
        uint256 loan = loans[msg.sender];
        require(loan > 0, "No loan");
        require(msg.value >= loan, "Insufficient ETH");

        // 2. Effects
        loans[msg.sender] = 0;
        balances[msg.sender] += loan;
        emit LoanRepaid(msg.sender, loan);

        // 3. Interactions (ici, pas de transfer car c'est un "pull")
        // L'ETH est déjà envoyé par l'utilisateur (msg.value)
    }
}

6. Quand peut-on "violer" CEI ?

Il existe de rares exceptions où l’ordre CEI peut être ajusté, mais uniquement si :

1. L’appel externe est en lecture seule (ex : staticcall à un oracle).

   function getPrice() external {
      // Pas de modification d'état → pas de risque de reentrancy
      (bool success, bytes memory data) = oracle.staticcall(abi.encodeWithSignature("latestPrice()"));
      require(success, "Oracle failed");
      uint256 price = abi.decode(data, (uint256));
      // ... (pas d'Effects après)
   }

2. L’appel externe est à un contrat trusted et vérifié (ex : contrat admin contrôlé).

   function adminWithdraw(address _to, uint256 _amount) external {
      require(msg.sender == admin, "Not admin");
      // Interaction avant Effect (mais safe car admin est trusted)
      (bool success, ) = _to.call{value: _amount}("");
      require(success, "Transfer failed");
      // Mise à jour de l'état après (acceptable ici)
      adminBalances[_to] -= _amount;
   }

   ⚠️ À éviter sauf cas très spécifiques (et documentés).

7. Résumé des bonnes pratiques CEI

8. Ressources pour aller plus loin

1. Consensys Diligence : Checks-Effects-Interactions → Explication approfondie avec des exemples d’exploits réels.
2. Solidity Docs : Security Considerations → Section officielle sur CEI.
3. OpenZeppelin ReentrancyGuard → Implémentation du verrou contre la reentrancy.
4. SWCREGISTRY : Reentrancy → Base de données des vulnérabilités Solidity (incluant les violations CEI).

À retenir :

"Checks-Effects-Interactions n’est pas une option, c’est une loi physique en Solidity. La violer, c’est comme construire un pont sans calculer les forces : ça finira par s’effondrer." — Vitalik Buterin (paraphrasé, EthCC 2022)