Gains :
- Capacité à utiliser l'intelligence artificielle pour produire des frameworks, des tests et réviser des ébauches basées sur des bibliothèques éprouvées (par exemple OpenZeppelin) et comprendre que les humains garantissent la sécurité de la production
- Capacité à vérifier la version du code, le modèle et le contrôle d'accès produits par l'intelligence artificielle via la compilation, les tests et testnet
- Être capable de distinguer que la compilation ne signifie pas être sécurisé et que le testnet et l'audit sont essentiels.
L'écriture d'un contrat intelligent est différente d'un logiciel ordinaire : le code que vous écrivez est public, immuable et constitue un programme qui déplace directement de l'argent. Dans cette unité, vous apprendrez à utiliser l'IA comme assistant de développement de contrats intelligents ; Nous apprendrons de la production d'ébauches à l'écriture de tests, du rappel de modèles à l'optimisation du gaz (frais de transaction). Mais soyons clairs dès le départ : l’IA produit des plans ; Les humains garantissent la sécurité du code mis en production.
Le terrain d’abord : la langue et l’environnement
Le langage de contrat intelligent le plus courant est Solidity (le langage d'Ethereum et d'EVM — Ethereum Virtual Machine, la machine virtuelle sur laquelle les contrats s'exécutent — chaînes compatibles). L'alternative est Vyper (un langage de type Python qui se veut plus contraint et plus lisible). Votre code consomme du gaz (le coût de chaque transaction vers la blockchain) ; Un code inefficace coûte cher. Garder ces termes clairs dans le contexte que vous les donnez à l'IA est essentiel pour obtenir un résultat précis.
Là où l'IA est le plus précieuse, ce n'est pas dans « l'écriture à partir de zéro » mais dans la production du cadre + du bon moule : un départ conforme aux normes, un plan sur lequel ajouter votre expertise.
Couches d'utilisation de l'IA dans le codage
1. Générer des squelettes. L'IA exploite rapidement le squelette d'un jeton standard (ERC-20) ou d'un NFT (ERC-721 – une norme d'actif numérique unique). Mais assurez-vous que l'IA utilise une bibliothèque éprouvée : par exemple, OpenZeppelin (la bibliothèque de contrats standards de confiance et auditée de la communauté). La règle est d'utiliser le bloc testé plutôt que d'écrire la sécurité à partir de zéro.
2. Description et examen des fonctions. Expliquer une fonction existante à l’IA vous permet de détecter rapidement les erreurs logiques.
3. Génération de tests. L'IA est efficace pour générer des cas de test pour les cas extrêmes : zéro entrée, très grand numéro, appelant non autorisé, appel répété. Cela rappelle l’un des scénarios que l’on saute.
4. Gaz et lisibilité. L'IA signale les modèles coûteux tels que les écritures de stockage inutiles et suggère des alternatives.
Astuce : demandez à l'IA de "s'appuyer sur les contrats audités d'OpenZeppelin et de réécrire la sécurité à partir de zéro". Il est beaucoup plus risqué pour une IA d’écrire du code de sécurité original que d’utiliser une bibliothèque testée.
Invite faible/Invite forte
Invite faible :
Écrivez-moi un contrat symbolique.
Cette invite est dangereuse : on ne sait pas quelle norme, quelle chaîne, quelle bibliothèque, quelle exigence de sécurité. L'IA génère du code aléatoire, éventuellement obsolète ou non sécurisé.
Invite puissante :
Votre rôle : développeur senior Solidity. Générez un brouillon de jeton ERC-20 pour une chaîne compatible EVM. Règles : - Basé sur les contrats ERC20 et Ownable audités d'OpenZeppelin. - Écrivez explicitement la ligne de version et de licence Solidity (SPDX). - Seul le propriétaire a la permission de créer ; ajoutez un capuchon contre une pression infinie. - Ajoutez un commentaire NatSpec à chaque fonction. - Écrire la sécurité à partir de zéro ; Utilisez le bloc standard. - Ajouter un avertissement à la fin : "Ceci est un brouillon ; un audit et des tests sont requis". Marquez les zones dont vous n'êtes pas sûr avec // TODO.
Différence : une invite forte donne des attentes claires en matière de rôle, de norme, de bibliothèque, de limite de sécurité, de documentation et de validation.
Quatre modèles copiables
1) Squelette basé sur des normes :
Votre rôle : Développeur Solidity. Générez un cadre de contrat [ERC-20 / ERC-721 / staking] basé sur la bibliothèque auditée OpenZeppelin. Écrivez la licence SPDX et la version pragma. Ajoutez un contrôle d'accès (qui peut appeler) à chaque fonction externe. Réinventer la sécurité ; Utilisez des blocs standards. Ceci est un brouillon.
2) Examen des fonctions :
Examinez la fonction suivante comme un développeur senior : que fait-elle, quels états change-t-elle, qui peut l'appeler ? Marquez les erreurs logiques possibles et les risques de sécurité comme HYPOTHÈSE, en reliant chacun à une ligne du code. Ne dites pas carrément « sûr » ; énumérez simplement les points d’attention.
3) Projet de scénario de test :
Proposer des cas de test pour ce contrat (pourrait être une ébauche pour Foundry/Hardhat). Couvre spécifiquement les cas limites : entrée nulle, nombre très important, appel non autorisé, appel réentrant, fonds insuffisants. Écrivez CE QUE chaque test confirme.
4) Revue de gaz et de lisibilité :
Dans ce contrat, marquez les schémas qui peuvent réduire le coût du gaz : écriture de stockage inutile, appel externe dans la boucle, calcul répétitif. Expliquez la différence avant/après dans chaque suggestion. Recommander des optimisations de sécurité ; Si ce n'est pas clair, dites « demandez à l'auditeur ».
Trois mini-cases (en chiffres)
Cas 1 — Le squelette a gagné 4 heures. Une équipe a extrait le squelette d’un contrat d’acquisition audité basé sur une bibliothèque avec AI en 30 minutes ; Cela a pris environ 4 heures manuellement. L'équipe a consacré du temps à la sécurité et aux tests. Le gain n’est pas venu du transfert de la sécurité, mais de l’accélération du cadre fastidieux.
Cas 2 — Piège de version obsolète. L'IA a produit un modèle qui envoie de l'Ether brut par transfert, ce qui n'est plus recommandé car les données d'entraînement sont obsolètes. Le développeur l'a remarqué et l'a modifié pour le modèle actuel basé sur les appels et protégé contre la réentrée. Leçon : La bibliothèque/le modèle de l'IA est toujours confirmé comme étant à jour ; AI ne sait pas au-delà de la date limite de formation.
Cas 3 — Le brouillon de test a fait apparaître un bug caché. Le test "appelant non autorisé" produit par l'IA a révélé que le développeur avait oublié le contrôle d'accès dans une fonction. onlyOwner manque 1 ligne, détecté en 5 minutes sur testnet ; Il aurait pu y avoir une perte de fonds sur le réseau principal. Leçon : L'IA couvre l'angle mort humain lors des tests.
Se souvenir des modèles de sécurité avec l'IA
L’IA est efficace pour vous rappeler les modèles de vulnérabilité connus, comme une liste de contrôle. Les modèles les plus courants :
- Réentrée : passer un appel externe sans mettre à jour le statut. Solution : ordre contrôles-effets-interactions, garde de réentrée.
- Absence de contrôle d’accès : n’importe qui peut appeler la fonction critique.
- Dépassement/sous-dépassement d'entiers : Modern Solidity détecte la plupart d'entre eux, mais reste un risque dans le code de bas niveau.
- Validation d'entrée inadéquate : adresse nulle, contrôle de quantité nulle.
- Dépendance Oracle : confiance aveugle dans les données externes (telles que le prix).
Attention : l'IA peut rappeler cette liste, mais elle ne peut pas garantir si un élément de la liste figure dans votre code spécifique. La liste de contrôle est un début ; Cela ne remplace pas le contrôle des conteneurs.
Bien comprendre le contexte : le secret d'un bon code issu de l'IA
La qualité du code produit par l’IA dépend directement de la qualité du contexte que vous lui donnez. Dans Web3, cela est particulièrement critique car un petit détail (quelle chaîne, quelle version Solidity, quel standard de jeton) modifie la totalité de la sortie. Un bon contexte comprend :
- Chaîne cible et environnement : réseau principal Ethereum ou couche 2 (sidechain moins cher qui s'exécute au-dessus de la chaîne principale) ? Le coût du gaz et certaines fonctionnalités varient selon la chaîne.
- Version et bibliothèque : Quelle version Solidity, quelle version OpenZeppelin ? Si aucune version n'est spécifiée, l'IA peut produire des modèles obsolètes et obsolètes.
- Exigences de sécurité : existe-t-il un plafond, peut-il être suspendu, peut-il être augmenté ? Il faut le dire dès le début.
- Contraintes : Limites claires comme « ne pas utiliser de montage », « éviter les appels externes », « optimiser le gaz mais conserver la lisibilité ».
Une autre technique puissante consiste à demander d'abord à l'IA le plan, puis le code : « Faites d'abord la liste des fonctions de ce contrat et de ce que chacun fera ; écrivez le code une fois que je l'aurai approuvé. » Cela détecte très tôt l'IA qui va dans la mauvaise direction et vous permet de conserver la décision architecturale.
Indice : demandez à l'IA "pourquoi avez-vous écrit ce code comme ça ?" demander. Expliquer la justification accélérera à la fois votre apprentissage et fera ressortir toute erreur logique (par exemple une fausse hypothèse de sécurité). Ne faites pas confiance aux résultats d'une IA qui ne peut pas défendre son propre code.
Erreurs courantes
- Intégrer la sécurité dans l'IA à partir de zéro. Utilisez une bibliothèque testée.
- Ne confirme pas la version/le modèle produit par l'IA. Les données de formation peuvent être anciennes.
- Contourner le testnet. Chaque brouillon doit être exécuté sur le réseau de test avant d'être mis en ligne.
- Ne pas ajouter NatSpec/documentation. L'inspection et l'entretien deviennent difficiles.
- "C'est compilé, donc c'est sûr" idée fausse. Être compilé ne signifie pas être en sécurité.
- Oublier le contrôle d’accès. C’est l’une des erreurs les plus courantes et les plus coûteuses.
En résumé
- Dans la rédaction de contrats intelligents, l'IA produit des cadres, des tests et des versions de révision ; L’humain garantit la sécurité de la production.
- Construisez la sécurité non pas à partir de zéro mais sur la base de bibliothèques éprouvées (par exemple OpenZeppelin).
- L'actualité des versions et des modèles produits par YZ est toujours confirmée.
- Les talons de test sont précieux pour capturer les angles morts humains (cas limites, contrôle d'accès).
- Être compilé ne signifie pas être en sécurité ; testnet et audit sont indispensables.
Tâche de candidature
Pour un simple jeton ERC-20, générez un brouillon à l'aide de l'invite « squelette basé sur des normes » ci-dessus. Ensuite : (1) vérifiez s'il utilise une bibliothèque vérifiée, (2) vérifiez les contrôles d'accès, (3) générez des tests avec l'invite "projet de scénario de test" et exécutez réellement au moins un test d'appelant malveillant. Trouvez et notez au moins un point de sécurité que l'IA a manqué.
liste de contrôle
- [ ] J'ai clairement indiqué la norme et la chaîne dans l'invite.
- [ ] Je voulais une production éprouvée basée sur une bibliothèque.
- [ ] Licence SPDX et version pragma disponibles.
- [ ] Il existe un contrôle d'accès dans chaque fonction critique.
- [ ] J'ai créé et exécuté des tests pour les cas limites.
- [ ] J'ai confirmé que la bibliothèque/le modèle est à jour.
- [ ] J'ai marqué le code pour l'audit et les tests ; Je ne l'ai pas obtenu sans surveillance sur le réseau principal.