7.2 KiB
7.2 KiB
Hardhat et alternatives (Remix, Truffle, Foundry…)
Contexte : projet Tokenizer — dossier
code/+deployment/(sujet ch. IV).
Choix projet : decisions-projet.md → Hardhat + OpenZeppelin.
1. Le problème que résout une « toolchain »
Écrire un fichier .sol ne suffit pas. Il faut :
| Besoin | Sans outil | Avec toolchain |
|---|---|---|
| Traduire Solidity en bytecode | Impossible à la main | Compilation |
Vérifier que transfer marche |
Deploy à chaque essai sur testnet (gas) | Tests locaux |
| Envoyer le contrat sur BSC testnet | Tx manuelle complexe | Scripts de déploiement |
| Reproduire le deploy pour l’éval | Oublis, « ça marche sur ma machine » | Scripts + config versionnés dans Git |
Le sujet cite explicitement : IDE, Remix, Truffle ou Hardhat — ce sont des outils pour compiler, tester et déployer, pas le standard BEP-20 lui-même.
2. C’est quoi Hardhat ?
Hardhat est un environnement de développement pour smart contracts sur chaînes EVM (Ethereum, BSC, etc.).
- Écrit en JavaScript / TypeScript (Node.js).
- Projet typique :
hardhat.config.js, dossiercontracts/,scripts/,test/. - Commandes courantes :
npx hardhat compile— compile Solidity → artefacts dansartifacts/npx hardhat test— lance les tests (souvent avec ethers.js)npx hardhat run scripts/deploy.js --network bscTestnet— déploie sur le testnetnpx hardhat node— blockchain locale temporaire (0 tBNB réel, pour dev)
Rôle dans Tokenizer :
| Dossier sujet | Rôle Hardhat |
|---|---|
code/ |
Sources .sol, config Hardhat, tests, package.json |
deployment/ |
Scripts / notes de deploy (souvent scripts/deploy.js appelé depuis code/, ou copie documentée — l’important est que l’évaluateur retrouve comment redéployer) |
Hardhat ne remplace pas MetaMask : MetaMask signe ; Hardhat utilise ta clé privée (via .env) pour envoyer la transaction de deploy depuis le terminal.
3. Les briques autour de Hardhat (vocabulaire)
| Terme | Rôle |
|---|---|
| Solidity | Langage du contrat (FGC42Forge.sol) |
| OpenZeppelin | Bibliothèque de contrats éprouvés (ERC20, Ownable) |
| ethers.js | Bibliothèque JS pour parler à la chaîne (lire balances, envoyer txs) |
| RPC | URL dans hardhat.config → même idée que MetaMask (02-web3 § 3.9) |
| @nomicfoundation/hardhat-toolbox | Pack plugins (tests, verify, etc.) recommandé par Hardhat |
| artifacts/ | Sortie compilée (bytecode) — souvent gitignoré, régénéré par compile |
| BscScan verify | Publier le code source sur l’explorer (étape deploy, hors Hardhat strict mais complémentaire) |
4. Alternatives citées par le sujet (et autres)
Remix (IDE navigateur)
| C’est quoi | Site remix.ethereum.org : éditeur + compile + deploy dans le navigateur. |
| Pour | Prototyper vite, premier contrat, démo visuelle, cours. |
| Contre | Moins pratique pour un dépôt 42 structuré (code/, tests, CI, scripts reproductibles). |
| Tokenizer | Autorisé par le sujet ; beaucoup d’étudiants font un premier test sur Remix puis migrent vers Hardhat/Truffle pour le rendu. |
Truffle
| C’est quoi | Framework Node.js plus ancien que Hardhat : Truffle Compile, Migrate, Ganache. |
| Pour | Cycle complet migrations + tests ; encore vu en entreprise / anciens tutos. |
| Contre | Écosystème moins « par défaut » qu’Hardhat aujourd’hui ; config parfois plus lourde. |
| Exemple 42 | BdClement/Tokenizer a choisi Truffle + Alchemy RPC — valide si README explique les choix. |
Foundry (forge / cast)
| C’est quoi | Toolchain en Rust : forge (compile/test), cast (CLI), très rapide, tests souvent en Solidity. |
| Pour | Perf, culture « smart contract pur », projets DeFi avancés. |
| Contre | Courbe d’apprentissage différente (moins JS) ; moins cité dans le PDF Tokenizer. |
| Tokenizer | Possible si BEP-20 + deploy testnet + doc — à justifier dans le README école. |
Autres (hors PDF mais utiles à situer)
| Outil | Note |
|---|---|
Ganache / hardhat node |
Blockchain locale pour tests |
| Brownie | Python — plutôt écosystème Ethereum historique |
| Thirdweb, etc. | Abstractions / SDK — le sujet demande de comprendre ce que tu déploies ; éviter le « tout no-code » en soutenance |
5. Tableau comparatif (révision soutenance)
| Critère | Hardhat | Remix | Truffle | Foundry |
|---|---|---|---|---|
| Où ça tourne | Terminal + VS Code | Navigateur | Terminal | Terminal |
| Langage orchestration | JS/TS | GUI | JS | Rust + Solidity tests |
| Tests automatisés | ✅ (Mocha/Chai) | Limité | ✅ | ✅ (forge) |
| Scripts deploy reproductibles | ✅ | Manuel | ✅ (migrations) | ✅ |
| Cité sujet Tokenizer | ✅ | ✅ | ✅ | ❌ (mais EVM OK) |
Fit dossiers code/ + deployment/ |
✅ très bon | Moyen seul | ✅ bon | ✅ bon |
Le sujet n’impose pas Hardhat : il impose de maîtriser un outil et de livrer du code commenté + deploy documenté.
6. Pourquoi Hardhat pour ton parcours FGC ?
| Raison | Détail |
|---|---|
| Alignement doc 42 / tutoriels BEP-20 | Beaucoup d’exemples OpenZeppelin + Hardhat |
| Un seul écosystème Node | npm install, proche d’autres stacks JS |
| Tests avant testnet | Économise tes 0,1 tBNB |
hardhat.config.js |
Réseau bscTestnet chainId 97 = même logique que MetaMask |
| Séparation claire | contracts/ + scripts/ → facile à expliquer en code review |
Tu pourrais dire en soutenance :
« J’ai choisi Hardhat pour compiler et tester FGC42Forge en local, puis déployer sur BSC Testnet avec un script reproductible dans le dépôt, comme le sujet le prévoit pour la partie deployment. »
7. Flux mental : de Hardhat à la chaîne
flowchart LR
subgraph local [Machine dev]
SOL[FGC42Forge.sol]
HH[Hardhat compile / test]
SCRIPT[script deploy.js]
end
subgraph chain [BSC Testnet 97]
RPC[RPC URL]
SC[Adresse contrat]
end
SOL --> HH
HH --> SCRIPT
SCRIPT -->|tx signée PRIVATE_KEY| RPC
RPC --> SC
SC --> BSCScan[testnet.bscscan.com]
MetaMask reste utile pour démos manuelles (transfer FG42) ; Hardhat sert surtout au deploy et aux tests.
8. Liens
- Index complet tutos & docs : ressources-solidity-hardhat.md
- Hardhat — Getting started
- OpenZeppelin Contracts
- Étape suivante : etape-02-init-hardhat.md
- guide-realisation.md