Sécurité du contrat

Le critère de sélection du kickoff est un smart contract « solide et sécurisé ». Cette page recense les menaces qui pèsent sur BlockLucky et BlockLuckyPOAP, la parade de chacune dans le code, les risques acceptés, et le triage de l'analyse statique. Elle porte sur les contrats ; la sécurité du backend, des portefeuilles et de l'infrastructure est traitée dans la partie Sécurité, en particulier Clés et garde des portefeuilles.

#Acteurs et actifs

Les actifs à protéger sont les mises des tours en cours, les cagnottes et remboursements non retirés, la commission accumulée, et l'équité du tirage.

#Synthèse

#Checks-effects-interactions

Chaque fonction qui envoie des ethers suit le même ordre : vérifier, modifier l'état, émettre l'événement, puis seulement appeler le destinataire.

function claimPrize(uint256 roundId) external nonReentrant {
    Round storage round = rounds[roundId];
    if (round.status != RoundStatus.Completed) revert RoundNotCompleted(roundId);
    if (msg.sender != round.winner) revert NotWinner(msg.sender);
    if (round.prizeClaimed) revert PrizeAlreadyClaimed(roundId);

    round.prizeClaimed = true;
    uint256 amount = round.prize;
    emit PrizeClaimed(roundId, msg.sender, amount);
    (bool success, ) = payable(msg.sender).call{value: amount}("");
    if (!success) revert TransferFailed(msg.sender, amount);
}

Le transfert utilise call sans limite de gaz plutôt que transfer, qui plafonne à 2 300 gaz et échoue avec les portefeuilles de contrat. C'est sûr précisément parce que l'état est déjà à jour. En cas d'échec, le revert TransferFailed annule toute la transaction, y compris la mise à jour de l'état : le bénéficiaire peut réessayer.

#Réentrance

Un contrat gagnant pourrait, dans sa fonction receive, rappeler claimPrize pour se faire payer deux fois. Deux protections indépendantes l'en empêchent :

1. L'ordre checks-effects-interactions : au second appel, prizeClaimed vaut déjà true.
2. nonReentrant d'OpenZeppelin, posé sur buyTickets, buyTicketsFor, requestDraw, retryDraw, closeExpiredRound, cancelRound, claimPrize, claimRefund et withdrawFees. Le verrou est partagé : pendant un claimPrize, aucune de ces fonctions n'est accessible, ce qui interdit aussi la réentrance croisée (par exemple un claimRefund lancé depuis le receive d'un claimPrize).

Le contrat d'attaque ReentrantPlayer.sol tente exactement ces deux scénarios. Les tests constatent que la tentative a bien lieu (reentryAttempts == 1), qu'elle échoue (reentrySucceeded == false), que l'attaquant reçoit exactement une fois son dû, et que le solde du contrat tombe à zéro après le remboursement.

#Manipulation du hasard

Le contrat n'utilise ni block.prevrandao, ni blockhash, ni block.timestamp pour le tirage. Le seul aléa est le mot fourni par Chainlink VRF, accompagné d'une preuve vérifiée par le coordinateur. rawFulfillRandomWords refuse tout appelant autre que s_vrfCoordinator (OnlyCoordinatorCanFulfill).

Le gagnant est ticketOwners[roundId][randomWords[0] % ticketCount]. Le biais du modulo est négligeable pour un ticketCount sur 32 bits. Chaque ticket a la même probabilité, ce que vérifient les tests de fuzzing en contrôlant que l'index gagnant est toujours inférieur au nombre de tickets vendus et que le gagnant est bien le détenteur de ce ticket.

block.timestamp n'intervient que dans les délais (endTime, drawTimeout). Un validateur peut le décaler de quelques secondes ; sur des tours de 48 heures, l'effet est nul. Ce constat Slither est accepté (voir plus bas).

#Front-running

#Déni de service par revert

Un contrat qui refuse les ethers, comme RejectingPlayer.sol, ne peut bloquer que son propre retrait. Le tirage et l'annulation n'envoient aucun ether, et le tour suivant s'ouvre dans la même transaction. Trois tests le vérifient : gagnant qui refuse (prizeClaimed reste false), payeur qui refuse (sa contribution reste due), trésorerie qui refuse (accruedFees est conservé).

Aucune boucle ne parcourt les participants. La seule boucle, dans _buyTickets, est bornée par la quantité achetée, elle-même plafonnée par maxTicketsPerPlayer.

#Abus de l'administrateur

Le contrat est conçu pour qu'aucun rôle ne puisse prendre l'argent des joueurs.

Le pire que puisse faire un opérateur malveillant est d'annuler un tour : tous les payeurs sont alors remboursés intégralement. Le pire que puisse faire un administrateur malveillant est de détourner la commission, en changeant la trésorerie.

Deux pouvoirs méritent toutefois d'être connus.

Les autres garde-fous contre l'abus :

• Configuration non rétroactive. Chaque tour copie ses paramètres à l'ouverture. Ni le prix, ni le plafond, ni la commission d'un tour en cours ne peuvent changer.
• Commission plafonnée à MAX_FEE_BPS (20 %) par _validateRoundConfig.
• Validation de toute configuration au constructeur comme dans les setters : une configuration absurde (prix nul, minimum supérieur au plafond, délai nul, gaz du callback sous 100 000) est refusée avec InvalidConfiguration.
• Transparence. Chaque changement émet un événement (TreasuryUpdated, RoundConfigUpdated, VrfConfigUpdated, RoleGranted, Paused) visible de tous sur l'explorateur.

#Épuisement du gaz du callback VRF

Le coordinateur appelle le consommateur avec exactement callbackGasLimit gaz. Si le callback en consomme davantage, il échoue, la requête est considérée comme servie et le tour reste bloqué en Drawing.

Parades :

• le callback ne contient aucune boucle et aucun appel externe : son coût est constant, quel que soit le nombre de tickets ;
• il ne transfère aucun ether : la cagnotte est retirée plus tard par claimPrize ;
• il ne revert jamais sur une réponse inattendue : il l'ignore ;
• callbackGasLimit vaut 500 000 dans les scripts et le contrat refuse moins de 100 000 ;
• en dernier recours, l'opérateur relève la limite par setVrfConfig puis appelle retryDraw.

#Oracle muet

Si aucune réponse n'arrive, retryDraw permet à l'opérateur de renvoyer une requête une fois drawTimeout écoulé (24 heures sur Sepolia). L'ancienne requête est retirée de roundByRequestId : si sa réponse arrive malgré tout, elle est ignorée. En dernier recours, cancelRound rend les mises remboursables. Voir Tirage Chainlink VRF.

#Autres protections

• Arithmétique vérifiée. Solidity 0.8 revert en cas de dépassement ; le contrat n'utilise pas de bloc unchecked.
• Erreurs personnalisées partout, imposées par la règle solhint gas-custom-errors.
• Imports nommés uniquement (no-global-import).
• Version du compilateur contrainte à ^0.8.28 dans les sources et fixée à 0.8.34 dans Hardhat.
• Ethers forcés. Sans receive, seul un selfdestruct tiers peut ajouter des ethers ; ils ne sont comptabilisés nulle part et ne faussent aucun calcul, le contrat ne lisant jamais address(this).balance.

#Analyse statique

#solhint

npm run lint lance solhint avec smart-contract/.solhint.json, qui étend solhint:recommended et refuse tout avertissement (--max-warnings 0). Les règles désactivées le sont pour une raison précise :

#Triage Slither

npm run slither lance Slither 0.11.6 dans Docker par scripts/slither.sh, sur chacun des deux contrats, avec --fail-medium. La configuration slither.config.json exclut node_modules et contracts/test, ainsi que les détecteurs informatifs et d'optimisation. La CI échoue dès qu'un constat de niveau Medium ou supérieur n'est pas trié.

Les constats acceptés sont consignés dans slither.db.json, passé à Slither par --triage-database. Il en contient huit :

Aucun constat n'est trié pour BlockLuckyPOAP : la base ne concerne que BlockLucky.

Slither n'a pas été relancé pour la rédaction de cette page, qui s'appuie sur la base de triage et sur la CI.

#Ce qui n'a pas été fait

• Pas d'audit externe. Les contrats n'ont été relus que par l'équipe et les outils automatiques.
• Pas de vérification formelle ni de tests d'invariants avec état sur des séquences d'appels ; le fuzzing porte sur des scénarios fixes aux paramètres aléatoires.
• Pas de multisignature pour l'administrateur ni pour le propriétaire dans les scripts : un seul compte détient ces pouvoirs.

Ces points, et d'autres, sont repris dans Limites connues.