Comment sécuriser votre contrat intelligent ? (Une liste de contrôle de sécurité)

Audit de code et vérification formelle

1. Engagez plusieurs sociétés de sécurité indépendantes pour effectuer des révisions manuelles du code avant le déploiement.

2. Appliquez des outils de vérification formelle comme Certora ou MythX pour prouver mathématiquement l'exactitude des invariants critiques.

3. Assurez-vous que tous les appels externes sont validés par rapport aux vecteurs de réentrée à l'aide de modèles de contrôles, d'effets et d'interactions.

4. Auditez toutes les bibliothèques importées, y compris les contrats OpenZeppelin, pour détecter les vulnérabilités spécifiques à la version.

5. Maintenez une piste d'audit immuable reliant chaque commit à son rapport de vérification et à son horodatage correspondant.

Contrôle d'accès et gestion des autorisations

1. Implémentez un contrôle d'accès basé sur les rôles à l'aide des modèles Ownable ou AccessControl issus des normes auditées.

2. Appliquez une séparation stricte entre les fonctions administratives et la logique orientée utilisateur : aucune opération privilégiée dans les points d'entrée publics.

3. Exigez des approbations multi-signatures pour les actions sensibles telles que la pause, la mise à niveau ou le retrait de fonds.

4. Faites régulièrement pivoter les clés d'administration et stockez-les hors ligne à l'aide de modules de sécurité matériels, et non dans les référentiels GitHub ou les fichiers en texte brut.

5. Enregistrez chaque modification d'autorisation en chaîne avec le contexte complet : appelant, horodatage, rôle cible et propriétaire précédent.

Optimisation du gaz et garanties de durée d'exécution

1. Évitez les boucles illimitées qui peuvent provoquer des pannes de gaz pendant l'exécution : utilisez la pagination ou des itérations plafonnées.

2. Insérez des limites de gaz explicites sur les appels externes pour empêcher le DoS via des boucles de repli infinies.

3. Validez les longueurs et les plages d'entrée avant de traiter des tableaux ou des chaînes pour éviter un débordement de pile ou une troncature silencieuse.

4. Utilisez les contrôles de débordement intégrés de SafeMath ou Solidity 0.8+ pour toutes les opérations arithmétiques impliquant des valeurs fournies par l'utilisateur.

5. Déployez avec les chaînes de restauration activées pour faciliter le débogage sans exposer la logique sensible dans les messages d'erreur de production.

Mise à niveau et modèles de proxy

1. Préférez les proxys transparents uniquement lorsque la logique de mise à niveau doit rester totalement découplée de la logique métier.

2. Stockez l'adresse de l'administrateur du proxy dans un contrat distinct et renforcé (et non dans le proxy lui-même) pour empêcher les mises à niveau non autorisées.

3. Geler la capacité de mise à niveau après le lancement du réseau principal, à moins qu'elle ne soit régie par un DAO verrouillé dans le temps avec des périodes de vote imposées par quorum.

4. Vérifiez la compatibilité de la disposition du stockage entre les implémentations à l'aide des outils slither ou crytic avant de déployer une nouvelle logique.

5. N'autorisez jamais l'autodestruction ou l'appel délégué à des adresses arbitraires, même dans les fonctions de mise à niveau, à moins qu'elles ne soient explicitement inscrites sur liste blanche et enregistrées.

Surveillance, alerte et réponse aux incidents

1. Intégrez le suivi des transactions en temps réel via Tenderly ou BlockSec pour détecter les transitions d'état anormales.

2. Configurez des observateurs d'événements en chaîne pour les conditions critiques telles que des baisses soudaines de solde, des transferts de propriété inattendus ou des retours répétés.

3. Acheminez les alertes via des canaux cryptés vers des intervenants désignés, et non vers des groupes publics Slack ou Discord.

4. Maintenir une transaction de pause d'urgence pré-signée prête à être diffusée dans les secondes suivant la confirmation de la compromission.

5. Archivez chaque semaine tous les instantanés d'état historiques à l'aide des racines Merkle soutenues par IPFS et signées par Governance Multisig.

Foire aux questions

Q : Puis-je compter uniquement sur des scanners automatisés comme Slither ou Mythril ? Les outils automatisés détectent les modèles connus mais manquent les défauts logiques propres à votre tokenomics ou à votre modèle d'interaction. L’examen humain reste essentiel.

Q : Est-il sûr d'utiliser les modèles ERC-20 de GitHub sans modification ? Non. De nombreux modèles populaires contiennent des hypothèses obsolètes sur les versions du compilateur, les modificateurs manquants ou la sémantique de transfert non sécurisée. Chaque ligne nécessite une validation contextuelle.

Q : Dois-je déployer mon contrat avec une fonction d'autodestruction ? L'autodestruction introduit un risque irréversible. Si cela est nécessaire pour les tests, désactivez-le définitivement avant le lancement du réseau principal à l'aide d'indicateurs de compilation ou d'une compilation conditionnelle.

Q : À quelle fréquence dois-je alterner les clés d'administration pour un contrat en direct ? La rotation des clés d'administration n'est pas applicable après le déploiement, car les clés privées ne régissent pas directement les contrats intelligents. Au lieu de cela, faites alterner les signataires de gouvernance et mettez à jour les seuils multisig via des propositions chronométrées.