diff --git a/README.md b/README.md deleted file mode 100644 index b83dc65..0000000 --- a/README.md +++ /dev/null @@ -1,58 +0,0 @@ -# Tokenizer — dépôt de travail - -Espace **perso** : sujet traduit, pédagogie, guides dev. Le rendu à l’école ne contient **pas** tout ce dépôt. - -## Deux dépôts Git distincts - -| Rôle | Où | Contenu typique | -|------|-----|-----------------| -| **Travail** (ce repo) | Racine `tokenizer/` | `docs/`, PDF, historique, notes | -| **École** (Intra / Vogosphere) | Racine = contenu de **`tokenizerRendu/`** | `README.md`, `code/`, `deployment/`, `documentation/` | - -Le dossier [`tokenizerRendu/`](tokenizerRendu/) est le **paquet de rendu** : structure et README **autonomes**, conformes au sujet v1.1. - -### Pousser vers l’école (quand le projet est prêt) - -**Option A — Git dans le sous-dossier** (recommandé en local) : - -```bash -cd tokenizerRendu -git init -git remote add origin -# premier push : uniquement les fichiers de ce dossier -``` - -Dans le dépôt de **travail**, ignorer le `.git` imbriqué (voir `.gitignore` racine). - -**Option B — Clone Vogosphere vide** puis copier le contenu de `tokenizerRendu/` à la racine du clone. - -Ne pas pousser : `docs/`, traductions, captures PDF, ce README de travail. - -## Documentation (travail uniquement) - -| Document | Lien | -|----------|------| -| Index doc | [docs/README.md](docs/README.md) | -| Sujet FR (v1.1) | [docs/sujets/tokenizer.md](docs/sujets/tokenizer.md) | -| PDF officiel | [docs/sujets/originaux/tokenizer_subject.pdf](docs/sujets/originaux/tokenizer_subject.pdf) | -| Plan pas à pas | [docs/pedagogie/README.md](docs/pedagogie/README.md) | -| Apports pédagogiques | [docs/pedagogie/01-apports-pedagogiques.md](docs/pedagogie/01-apports-pedagogiques.md) | -| Web3 (définitions) | [docs/pedagogie/02-web3-comprendre.md](docs/pedagogie/02-web3-comprendre.md) | -| Tutos Solidity / Hardhat | [docs/pedagogie/ressources-solidity-hardhat.md](docs/pedagogie/ressources-solidity-hardhat.md) | - -## Rendu école - -Correcteurs et soutenance : **[tokenizerRendu/README.md](tokenizerRendu/README.md)** (lu depuis le dépôt Intra une fois poussé). - -## Reprise du projet - -**État actuel :** structure doc + squelette de rendu ; smart contract et déploiement **à faire**. - -→ [docs/pedagogie/00-reprise-et-etat.md](docs/pedagogie/00-reprise-et-etat.md) - -## Démarrage - -1. Lire le [sujet traduit](docs/sujets/tokenizer.md) (avec éclaircissements). -2. Lire [02-web3-comprendre.md](docs/pedagogie/02-web3-comprendre.md) si le terme Web3 n’est pas clair, puis [01-apports-pedagogiques.md](docs/pedagogie/01-apports-pedagogiques.md) pour le « pourquoi » du projet. -3. Suivre le [parcours pas à pas](docs/pedagogie/parcours-etape-par-etape.md) (étape 1 en cours). -4. Coder et déployer **uniquement** dans `tokenizerRendu/` ([README rendu](tokenizerRendu/README.md)). diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 317e62c..0000000 --- a/docs/README.md +++ /dev/null @@ -1,31 +0,0 @@ -# Documentation — Tokenizer - -Documentation du projet, sur le modèle de [piscine_mobile/docs](../../piscine_mobile/docs/README.md) et [swifty_companion/docs](../../swifty_companion/docs/README.md). - -## Sujet officiel - -→ [sujets/README.md](sujets/README.md) - -| Document | Lien | -|----------|------| -| Traduction française (v1.1) + visuels | [sujets/tokenizer.md](sujets/tokenizer.md) | -| PDF Intra | [sujets/originaux/tokenizer_subject.pdf](sujets/originaux/tokenizer_subject.pdf) | - -## Pédagogie (dev) - -| Document | Lien | -|----------|------| -| **Reprise / état du projet** | [pedagogie/00-reprise-et-etat.md](pedagogie/00-reprise-et-etat.md) | -| **Ce que le projet t’apporte** | [pedagogie/01-apports-pedagogiques.md](pedagogie/01-apports-pedagogiques.md) | -| **Web3 — définition détaillée** | [pedagogie/02-web3-comprendre.md](pedagogie/02-web3-comprendre.md) | -| **Hardhat & alternatives** | [pedagogie/03-hardhat-et-alternatives.md](pedagogie/03-hardhat-et-alternatives.md) | -| **Tutos Solidity / Hardhat** | [pedagogie/ressources-solidity-hardhat.md](pedagogie/ressources-solidity-hardhat.md) | -| **Guide de réalisation** | [pedagogie/guide-realisation.md](pedagogie/guide-realisation.md) | -| **Parcours pas à pas** | [pedagogie/parcours-etape-par-etape.md](pedagogie/parcours-etape-par-etape.md) | -| Plan des étapes | [pedagogie/README.md](pedagogie/README.md) | - -## Dépôt de rendu 42 (hors dépôt de travail) - -Le code, le déploiement et la doc « utilisateur token » vivent dans **`tokenizerRendu/`** — racine du futur dépôt Intra. - -→ [../tokenizerRendu/README.md](../tokenizerRendu/README.md) · workflow : [../README.md](../README.md#deux-dépôts-git-distincts) diff --git a/docs/pedagogie/00-reprise-et-etat.md b/docs/pedagogie/00-reprise-et-etat.md deleted file mode 100644 index f9010fd..0000000 --- a/docs/pedagogie/00-reprise-et-etat.md +++ /dev/null @@ -1,50 +0,0 @@ -# Reprise du projet — où nous en sommes - -> Dernière mise à jour : **2026-10-22** — partie obligatoire **terminée** ; audit rendu + fiche soutenance ; bonus multisig **non retenu**. - -## En bref - -| | | -|---|---| -| **Fait** | Token **FGC42Forge** / **FG42**, BSC Testnet, deploy + BscScan vérifié | -| **Fait** | `code/` (contrat commenté, tests, Hardhat), `deployment/`, `documentation/` | -| **Fait** | Démo transfer MetaMask (FGC_account → demo_account) | -| **Non retenu** | Bonus multisig (manque de temps) | -| **Avant Vogosphere** | [audit-rendu-tokenizer.md](audit-rendu-tokenizer.md) (Git + `.gitignore`), checklist [demo](checklist-demo-evaluation.md), pas de `.env` | - -## Contrat (référence rapide) - -| Champ | Valeur | -|-------|--------| -| Adresse | `0x0c76df26A1149fDc22C8f994975705271b070fF4` | -| Réseau | BSC Testnet, chainId `97` | -| Code commenté | `tokenizerRendu/code/contracts/FGC42Forge.sol` | - -## Avancement par étape - -→ Détail : [parcours-etape-par-etape.md](parcours-etape-par-etape.md) - -| Étape | Contenu | Statut | -|-------|---------|--------| -| **0–1** | Structure, wallet, tBNB | ✅ | -| **2** | Hardhat 3 dans `code/` | ✅ | -| **3** | Contrat + tests | ✅ | -| **4** | Deploy + `deployment/` + BscScan verify | ✅ | -| **5** | `documentation/` + README choix techniques | ✅ | -| **6** | Démo + commentaires code (revue) | ✅ | -| **7** | Bonus multisig | ❌ Non retenu | - -## Reprendre avant correction - -1. `cd tokenizerRendu/code && npx hardhat test mocha --grep FGC42Forge` -2. Parcourir [checklist-demo-evaluation.md](checklist-demo-evaluation.md) -3. Ouvrir `FGC42Forge.sol` + README racine rendu pour la soutenance - -## Fichiers clés - -| Fichier | Rôle | -|---------|------| -| `tokenizerRendu/README.md` | Vue école + choix techniques | -| `tokenizerRendu/code/README.md` | Index code commenté pour correcteur | -| `tokenizerRendu/deployment/BSCSCAN_VERIFICATION.md` | Vérif explorateur | -| `docs/pedagogie/decisions-projet.md` | Suivi perso (hors rendu) | diff --git a/docs/pedagogie/01-apports-pedagogiques.md b/docs/pedagogie/01-apports-pedagogiques.md deleted file mode 100644 index 9504905..0000000 --- a/docs/pedagogie/01-apports-pedagogiques.md +++ /dev/null @@ -1,86 +0,0 @@ -# Ce que le projet Tokenizer t’apporte - -> Lecture **pédagogique** — hors rendu école. Le correcteur évalue le dépôt Vogosphere (`tokenizerRendu/`), pas ce dossier. - -## En une phrase - -Tu passes de « j’ai entendu parler de la blockchain » à « j’ai **déployé**, **documenté** et **défendu** un actif numérique sur une chaîne publique, en maîtrisant au minimum la **sécurité d’ownership** et les **standards de tokens** ». - -## Compétences techniques - -### 1. Smart contracts et langage de chaîne - -- Écrire ou adapter un contrat (**Solidity** si tu suis BSC/ETH) qui respecte une **interface standard** (BEP-20 / ERC-20). -- Comprendre ce que fait chaque fonction publique : `transfer`, `approve`, `allowance`, éventuellement `mint` / `burn`. -- Lire une **revue de code** en soutenance : noms explicites, commentaires sur les choix de sécurité, pas de « magie » copiée sans comprendre. - -**Pourquoi c’est utile :** l’écosystème Web3 recrute sur la capacité à livrer du code **auditable** ; ce projet reproduit une mini-livraison réelle (code + deploy + doc). - -### 2. Toolchain et reproductibilité - -- Utiliser **Hardhat**, **Truffle** ou **Remix** de façon cohérente : compilation, réseaux, scripts de déploiement. -- Séparer **`code/`** (source) et **`deployment/`** (procédure) comme demandé — même logique qu’en entreprise (CI/CD, infra). - -**Pourquoi c’est utile :** un token déployé « à la main une fois » sans script est difficile à maintenir ; le sujet t’entraîne à penser **reproductibilité**. - -### 3. Réseaux publics et explorateurs - -- Différence **mainnet** / **testnet**, **gas**, **adresse de contrat**, **vérification** sur BscScan ou équivalent. -- Obtenir des fonds de test via un **faucet** — flux standard pour tout développeur blockchain. - -**Pourquoi c’est utile :** tu sais **prouver** on-chain que ton contrat existe et correspond au code (verify + lecture explorer). - -### 4. Sécurité appliquée (obligatoire au sujet) - -- **Ownership** : qui peut changer les règles du jeu ? -- **Privilèges** : mint illimité, pause, blacklist — chaque pouvoir doit être **justifié** dans le README et la doc. -- Préparer une **démo minimale** qui montre les cas normaux **et** ce qui est interdit (ex. un compte non-owner ne peut pas mint). - -**Pourquoi c’est utile :** la majorité des incidents Web3 viennent de contrats mal conçus ; ce projet t’oblige à en parler à l’oral. - -### 5. Documentation produit - -- Deux niveaux distincts : - - **README école** : choix d’architecture et métadonnées de déploiement ; - - **`documentation/`** : comment **utiliser** le token (wallet, ajout du token, transfert, rôle du token dans ton « produit »). -- Option whitepaper : formaliser **à quoi sert** le token (même fictif). - -**Pourquoi c’est utile :** un développeur blockchain est aussi **rédacteur** pour utilisateurs et auditeurs. - -## Compétences transverses 42 - -| Compétence | Comment le projet la travaille | -|------------|--------------------------------| -| **Autonomie** | Peu de garde-fous : tu choisis la stack (dans les contraintes) | -| **Rigueur** | Arborescence imposée, eval = code review | -| **Communication** | README argumenté, soutenance avec démo | -| **Éthique** | Pas d’argent réel ; nom du token sans insultes ; honnêteté sur les limites du testnet | - -## Lien avec le partenariat BNB Chain - -Le sujet n’impose pas BSC en toutes lettres, mais le **préambule BNB** et le **faucet tBNB** orientent vers cet écosystème : - -- Volume et adoption réels (contexte donné dans le PDF). -- Standard **BEP-20** aligné sur l’industrie (compatible mental model ERC-20). -- Passerelle vers d’autres projets Web3 42 ou perso (DApp, ponts, etc.). - -## Bonus multisig — apports supplémentaires - -Si la partie obligatoire est **parfaite**, le multisig ajoute : - -- Modèle **seuil de confiance** (m-of-n signatures). -- Réflexion sur **gouvernance** et **opérations** (qui détient les clés en test ?). - -## Ce que ce projet n’est pas - -- Ce n’est **pas** un cours de trading ni une incitation à investir. -- Ce n’est **pas** une validation de « crypto » en général — c’est un exercice **d’ingénierie** sur registre distribué. -- Une vidéo démo **ne remplace pas** une doc écrite ni une démo live en soutenance. - -## Suite naturelle après Tokenizer - -- Auditer un contrat existant (lecture seule sur explorer). -- Front minimal (Web3.js / ethers) qui appelle ton token. -- Modules 42 ou projets perso : NFT (ERC-721), gouvernance, indexation (The Graph). - -→ Retour au plan : [README.md](README.md) · Guide technique : [guide-realisation.md](guide-realisation.md) diff --git a/docs/pedagogie/02-web3-comprendre.md b/docs/pedagogie/02-web3-comprendre.md deleted file mode 100644 index d160910..0000000 --- a/docs/pedagogie/02-web3-comprendre.md +++ /dev/null @@ -1,563 +0,0 @@ -# Web3 — définition et concepts (pour le projet Tokenizer) - -> Document **pédagogique** (dépôt de travail). Le sujet Tokenizer indique seulement : *« This document is a Web3 related exercise »* — ce texte complète cette mention avant de coder. - ---- - -## 1. Qu’est-ce que le Web3 ? - -**Web3** (ou **Web 3.0**) désigne une **vision** d’Internet où les utilisateurs interagissent avec des **services numériques** en s’appuyant sur des **réseaux décentralisés** (souvent des **blockchains**), plutôt que sur des **plateformes centralisées** seules (serveurs d’une entreprise, comptes verrouillés chez un opérateur). - -En pratique, quand on dit « projet Web3 » à l’école ou en entreprise, on parle souvent de : - -- des **smart contracts** (programmes exécutés sur une chaîne) ; -- des **tokens** (actifs numériques définis par ces contrats) ; -- des **portefeuilles** (*wallets*) qui signent des transactions avec des **clés cryptographiques** ; -- des **applications décentralisées** (**DApps**) qui lisent/écrivent l’état on-chain via des bibliothèques (ethers.js, web3.js, etc.). - -Le Web3 n’est **pas** un protocole unique ni un fichier de norme ISO : c’est un **ensemble d’idées et de technologies** dont l’emballage marketing varie. Pour Tokenizer, l’angle utile est **technique** : tu crées un **token sur une blockchain publique** — c’est un brique classique de l’écosystème Web3. - ---- - -## 2. Web1, Web2, Web3 — repères historiques (simplifiés) - -| Génération | Image courante | Qui « possède » les données / la logique ? | Exemples | -|------------|----------------|--------------------------------------------|----------| -| **Web1** (~1990–2000) | Pages **lecture seule** | Éditeurs de sites, hébergeurs | Pages HTML statiques, premiers forums | -| **Web2** (~2000–aujourd’hui) | **Lecture + écriture** sociale, apps riches | **Plateformes** (GAFAM, SaaS) : tes données et règles chez elles | Réseaux sociaux, Google Docs, API 42 hébergée par 42 | -| **Web3** (depuis ~2017, terme popularisé) | **Lecture + écriture + propriété** d’actifs / règles on-chain | **Réseau** + contrats : l’état partagé est sur la chaîne ; l’utilisateur garde souvent sa **clé** | Tokens, DeFi, NFT, DApps | - -Ces frontières sont **floues** : le Web2 n’a pas disparu ; la plupart des DApps ont encore un **site web classique** (Web2) qui parle à la blockchain (Web3). - -**Lien Tokenizer :** tu ne construis pas tout un site décentralisé ; tu fabriques l’**actif** (token BEP-20) que d’autres apps Web3 pourraient utiliser plus tard. - ---- - -## 3. Idées centrales du Web3 (vocabulaire) - -### 3.1 Décentralisation - -Plusieurs machines (nœuds) maintiennent une **copie** (ou une vue) du même registre. Personne ne peut, à lui seul, « effacer » une transaction validée selon les règles du protocole — contrairement à une base SQL sur un serveur unique. - -- **Nuance :** « décentralisé » ≠ « parfaitement égalitaire ». Miners/validateurs, fondations, bridges peuvent concentrer du pouvoir. Il faut rester **critique**. - -### 3.2 Blockchain - -Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). **Consensus** (PoW, PoS, PoA, PoSA…) définit qui peut proposer le bloc suivant — voir [§ 6.6](#66-consensus-de-la-chaîne-pow-pos-poa-et-variantes). - -- **BNB Chain** (sujet Tokenizer) est une de ces chaînes, orientée **smart contracts** et volume d’usage. - -### 3.3 Smart contract - -Programme déployé à une **adresse** sur la chaîne. Une fois publié, son code est (en principe) **immuable** sauf si le contrat prévoit une mise à jour ou un proxy. Les utilisateurs l’appellent en envoyant des **transactions**. - -- **Ton projet :** le token est un smart contract (souvent basé sur le standard **BEP-20**). - -### 3.4 Token - -Actif numérique défini par un contrat : soldes par adresse, transferts, parfois **mint** / **burn**. Un token peut représenter une **unité de compte** (style monnaie), des **parts**, ou un rôle dans un protocole — selon ce que **tu documentes**. - -| Action | Effet sur la supply | -|--------|---------------------| -| **Mint** | **Crée** des tokens et les crédite à une adresse → `totalSupply` **augmente** | -| **Burn** | **Détruit** des tokens → `totalSupply` **diminue** | -| **Transfer** | Déplace des tokens existants → la supply **ne change pas** | - -Au **déploiement**, beaucoup de contrats créent toute la supply dans le constructeur (**supply fixe**, pas de `mint` après). D’autres gardent une fonction `mint()` — souvent réservée au **`owner`** (`onlyOwner`). - -- **Contrainte 42 :** le **nom** doit contenir `42` ; le ticker et l’usage sont à toi (dans le cadre du sujet). -- **Mint « illimité »** : voir [§ 7.1](#71-mint-et-mint-illimité). -- **Supply, owner, Ownable, onlyOwner** : voir [§ 7.2](#72-glossaire-anglais--supply-owner-ownable-onlyowner). - -### 3.5 Wallet (portefeuille) - -Logiciel ou matériel qui gère une **paire de clés** : - -- **Adresse publique** (ex. `0xabc…`) — identifiant pour recevoir ; -- **Clé privée** — secret qui **signe** les transactions (ne jamais la committer dans Git). - -Sur testnet, le wallet contient des **tBNB** (gas) et tes tokens après déploiement / transfer. - -### 3.6 DApp (Decentralized Application) - -Application dont une partie critique repose sur des contrats on-chain (échanges, votes, tokens). Souvent : front web ou mobile + bibliothèque Web3 + RPC vers un nœud. - -- Tokenizer **n’exige pas** une DApp complète ; le token est la brique de base. - -### 3.7 Gas - -Frais payés dans la **monnaie native** de la chaîne (BNB sur BSC, ETH sur Ethereum) pour exécuter une transaction. Sur **testnet**, cette monnaie n’a **pas de valeur réelle** — le sujet insiste : pas d’argent réel pour le projet. - -### 3.8 Explorateur de blocs (BscScan, etc.) - -Site qui indexe chaîne : adresses, transactions, code vérifié du contrat. Obligatoire pour **prouver** le déploiement et le ticker en soutenance. - -### 3.9 Réseau RPC - -**RPC** (*Remote Procedure Call*) = façon pour un programme (wallet, Hardhat, Remix) de **parler à un nœud** de la blockchain via une **URL HTTP(S)**. - -La blockchain ne tourne pas sur ton PC : des **nœuds** répartis sur Internet maintiennent le registre. Ton outil doit pourtant : - -- **lire** l’état (solde, `name()` du token, code d’un contrat) ; -- **envoyer** des transactions déjà **signées** par ta clé privée (déploiement, `transfer`, etc.). - -Le **point d’accès RPC** est la « ligne téléphonique » vers ce réseau. Ce n’est **pas** une blockchain séparée : c’est la **porte d’entrée** vers la chaîne que tu as choisie (testnet ou mainnet). - -| Élément | Rôle | -|---------|------| -| **URL RPC** | Adresse du service/nœud (ex. endpoint BSC Testnet dans MetaMask ou `hardhat.config.js`) | -| **Wallet / script** | Construit la tx, la signe localement, l’envoie **via** le RPC | -| **Chaîne** | Reçoit la tx, l’exécute, met à jour l’état on-chain | - -**Exemple (BSC Testnet, indicatif)** — une URL publique souvent utilisée : - -`https://data-seed-prebsc-1-s1.binance.org:8545/` - -**Erreur fréquente :** RPC pointant sur le **mainnet** alors que tu crois être sur le **testnet** → tu dépenses du vrai BNB ou tu ne vois pas ton contrat de test. Vérifie **réseau + chainId** (BSC Testnet = `97`) dans le wallet et dans Hardhat. - -Dans le schéma ci-dessous, la boîte **« Réseau RPC »** est cette couche entre ton wallet et la **blockchain publique**. - ---- - -## 4. Web3 et « crypto » — ne pas confondre - -| Terme | Sens | -|-------|------| -| **Cryptographie** | Mathématiques (signatures, hash) — **fondation** technique de la blockchain | -| **Crypto-actif / « crypto »** (langage courant) | Tokens échangeables, souvent spéculatifs — **contexte économique** | -| **Web3** | Mouvement produit / dev autour d’apps et actifs on-chain | - -Le projet Tokenizer est un exercice **d’ingénierie** (contrat, déploiement, sécurité, documentation), pas une recommandation d’investissement. Le partenariat **BNB Chain** situe l’exercice dans un **écosystème** réel, tout en utilisant le **testnet** pour éviter le risque financier. - ---- - -## 5. Architecture mentale : où se place ton token ? - -```mermaid -flowchart LR - subgraph web2 [Couche familière Web2] - User[Utilisateur] - Browser[Navigateur / IDE / Git] - end - subgraph web3 [Couche Web3] - Wallet[Wallet] - RPC[Réseau RPC] - Chain[Blockchain publique] - SC[Smart contract Token BEP-20] - Explorer[Explorateur BscScan]source ~/.bashrc - Wallet --> RPC - RPC --> Chain - Chain --> SC - SC --> Explorer - Browser --> Explorer -``` - -1. Tu **écris** le contrat en local (`code/`). -2. Tu **déploies** via un script (`deployment/`) — transaction signée par ton wallet test. -3. Le contrat vit à une **adresse** sur la chaîne. -4. Tout le monde peut **lire** l’état via l’explorateur ; les détenteurs de tokens **transfèrent** via leurs wallets. - -**Lecture du schéma :** `Wallet → RPC → Chain` = ton MetaMask ou Hardhat envoie des requêtes à l’**URL RPC** du testnet, qui relaie vers les nœuds BSC Testnet. Détail : [§ 3.9](#39-réseau-rpc). - ---- - -## 6. Standards : ERC-20 et BEP-20 - -### 6.1 C’est quoi, en une phrase ? - -**ERC-20** et **BEP-20** sont des **normes** (des « contrats types ») pour des **tokens fongibles** : chaque unité est interchangeable (comme des pièces identiques), contrairement aux NFT (ERC-721, etc.). - -| Norme | Chaîne concernée (exemples) | -|-------|------------------------------| -| **ERC-20** | **Ethereum** et la plupart des L2 EVM (Sepolia testnet, etc.) | -| **BEP-20** | **BNB Chain** / **BSC** (*BNB Smart Chain*) — partenaire du sujet Tokenizer | - -Le **BEP** signifie *BNB Evolution Proposal* (propositions d’évolution de l’écosystème BNB), sur le même principe que **EIP** (*Ethereum Improvement Proposal*) pour ERC-20. - -### 6.2 Que impose le standard ? - -Ce n’est pas un fichier que tu télécharges : c’est une **interface** — ton contrat doit exposer au minimum des fonctions et événements reconnus par les wallets et explorateurs. - -| Fonction / événement | Rôle | -|----------------------|------| -| `name()`, `symbol()`, `decimals()` | Affichage dans MetaMask, BscScan, etc. | -| `totalSupply()` | Offre totale de tokens existants | -| `balanceOf(adresse)` | Solde d’un compte | -| `transfer(dest, montant)` | Envoyer des tokens | -| `approve(spender, montant)` | Autoriser un autre compte/contrat à dépenser pour toi | -| `allowance(owner, spender)` | Combien il reste à dépenser via `approve` | -| `transferFrom(from, to, montant)` | Dépenser pour quelqu’un qui t’a `approve` | -| `event Transfer` | Historique on-chain des mouvements | - -En projet 42, on utilise presque toujours **OpenZeppelin `ERC20`** : le code respecte ERC-20 ; déployé sur **BSC**, l’explorateur le qualifie de token **BEP-20**. - -### 6.3 ERC-20 vs BEP-20 : même logique, nom selon la chaîne - -Les deux chaînes sont **compatibles EVM** (même machine virtuelle, même langage **Solidity**). Pour un token « classique », le **code est souvent identique** ; ce qui change : - -| | ERC-20 | BEP-20 | -|---|--------|--------| -| **Réseau typique Tokenizer** | Possible (ex. Sepolia) | **Recommandé** (BSC Testnet, tBNB, BscScan) | -| **Gas** | ETH (ou ETH test) | BNB / **tBNB** | -| **Explorateur** | Etherscan | BscScan | -| **Standard token fongible** | ERC-20 | BEP-20 (interface équivalente) | - -**BEP-2** (autre norme BNB, ancienne Binance Chain) n’est **pas** le standard de ton exercice type « token ERC-20-like » sur BSC. - -### 6.4 Le sujet t’oblige-t-il à choisir BEP-20 ? - -**Non au sens « BEP-20 pour tout le monde ».** Le sujet dit : - -- tu **choisis** une blockchain ; -- tu respectes **le standard de cette chaîne** (exemples : ERC-20 sur ETH, **BEP-20 sur BSC**). - -Donc : - -- **Si tu déploies sur BNB Smart Chain** → tu dois livrer un token **BEP-20** (en pratique : contrat ERC-20-compatible sur BSC). -- **Si tu déploies sur Ethereum testnet** → **ERC-20**, avec justification dans le README. - -Le partenariat **42 × BNB Chain**, le faucet **tBNB** et les exemples **BscScan** orientent fortement vers **BSC testnet + BEP-20**, sans interdire formellement une autre chaîne EVM bien documentée. - -**Phrase utile en soutenance :** - -> « Mon token suit le standard **BEP-20** de BNB Chain, l’équivalent de l’**ERC-20** sur Ethereum ; j’ai utilisé OpenZeppelin ERC20 déployé sur le testnet. » - -### 6.5 Pourquoi le sujet insiste sur un standard ? - -Sans norme commune, chaque contrat aurait des noms de fonctions différents : les wallets ne pourraient pas afficher ton token ni proposer `transfer`. Le standard rend le token **lisible** par tout l’écosystème — c’est ce que l’évaluateur vérifie (comportement + code review), pas un label marketing. - -### 6.6 Consensus de la chaîne : PoW, PoS, PoA (et variantes) - -Quand le § 3.2 parle de **consensus**, il s’agit de la règle du réseau pour répondre à une question simple : - -> **Qui a le droit de proposer le bloc suivant**, et comment les autres nœuds **acceptent** qu’il est valide ? - -Tu **n’implémentes pas** ce mécanisme dans Tokenizer : tu **déploies sur une chaîne** qui l’a déjà. Comprendre PoS / PoA aide en soutenance (« sur quelle infra tourne mon token ? ») et évite de confondre **consensus réseau** et **multisig** (voir [§ 7.3](#73-multisig--types-et-lien-avec-le-bonus)). - -#### PoW — *Proof of Work* (preuve de travail) - -| | | -|---|---| -| **Idée** | Des **mineurs** rivalisent pour résoudre un puzzle cryptographique coûteux ; le gagnant publie le bloc et reçoit une récompense. | -| **Forces** | Très étudié (Bitcoin) ; sécurité liée à la **puissance de calcul** globale. | -| **Faiblesses** | **Consommation énergétique** élevée ; temps de bloc et frais variables. | -| **Exemples** | Bitcoin ; Ethereum **avant** « The Merge » (2022). | - -#### PoS — *Proof of Stake* (preuve d’enjeu) - -| | | -|---|---| -| **Idée** | Des **validateurs** bloquent une **mise** (*stake*) en tokens natifs ; le protocole **désigne** qui propose le bloc ; triche possible → **pénalités** (*slashing*). | -| **Forces** | Beaucoup moins énergivore que PoW ; modèle dominant sur les chaînes récentes. | -| **Faiblesses** | Débats sur concentration du stake, gouvernance, MEV — hors scope Tokenizer. | -| **Exemples** | Ethereum **depuis** The Merge ; Cardano, Polkadot, etc. | - -#### PoA — *Proof of Authority* (preuve d’autorité) - -| | | -|---|---| -| **Idée** | Seules des **entités identifiées** (liste fermée de validateurs / *sealers*) peuvent créer des blocs — pas de mining ni de stake ouvert comme en PoS grand public. | -| **Forces** | Blocs **rapides**, prévisibles ; idéal pour **réseaux privés** ou **testnets d’entreprise**. | -| **Faiblesses** | **Centralisation** assumée : il faut **faire confiance** aux autorités listées. | -| **Exemples** | Nombreux **testnets locaux** Hardhat ; chaînes consortium (Hyperledger Besu en mode PoA, etc.). | - -#### Autres noms que tu peux croiser - -| Sigle | Signification | Lien utile | -|-------|---------------|------------| -| **DPoS** | *Delegated Proof of Stake* — les détenteurs **élisent** un petit nombre de délégués validateurs | Certaines chaînes grand public | -| **PoSA** | *Proof of Staked Authority* — **mélange** : validateurs limités + mise en jeu | **BNB Smart Chain** utilise ce modèle (petit ensemble de validateurs actifs, historiquement ~21) | -| **IBFT / QBFT** | Variantes PoA pour réseaux privés | Plutôt entreprise, pas ton deploy BSC testnet | - -**Pour BNB Chain (sujet Tokenizer) :** ce n’est pas du PoW ; ce n’est pas exactement le PoS « ouvert » d’Ethereum. C’est plutôt un modèle **PoSA** : validateurs connus + stake — assez pour dire en oral : « chaîne EVM avec validateurs, je suis utilisateur via testnet, pas validateur ». - -#### Tableau comparatif (révision) - -| | PoW | PoS (typique) | PoA | -|---|-----|---------------|-----| -| **Qui produit les blocs ?** | Mineurs (calcul) | Validateurs (stake) | Autorités désignées | -| **Barrière à l’entrée** | Matériel + électricité | Capital en stake | Invitation / liste | -| **Décentralisation** | Variable | Variable | Souvent **faible** (volontaire) | -| **Ton projet** | Tu ne le choisis pas | Tu **utilises** la chaîne telle quelle | Idem (sauf réseau local perso) | - ---- - -## 7. Sécurité — angle Web3 (rappel sujet) - -Le Web3 déplace une partie des risques vers **le code** et **les clés** : - -| Risque | Exemple | -|--------|---------| -| Clé privée exposée | Drain du wallet | -| `owner` trop puissant | Mint illimité, vol de confiance | -| Bug de contrat | Fonds ou tokens bloqués / volés | -| Mauvaise doc | Utilisateurs qui ne comprennent pas les privilèges | - -Tokenizer te demande explicitement de réfléchir à **ownership** et **privilèges** et de le montrer en **démo minimale** + **revue de code**. - -### 7.1 Mint et mint illimité - -Ce n’est **pas** le nom d’une fonction dans le code. On parle d’une **situation de gouvernance** : - -> Tant que le **`owner`** peut appeler `mint` **sans plafond** ni règle stricte dans le contrat, il peut **créer autant de tokens qu’il veut**, quand il veut. - -**Pourquoi c’est sensible (même sur testnet, pour la soutenance) :** - -- Si le token représente des parts ou une « monnaie » fictive, un mint massif **dilue** tous les détenteurs (comme une impression monétaire sans limite). -- Si la **clé privée du owner** est compromise, un attaquant peut abuser de `mint`. -- Le sujet demande d’expliquer **ownership** et **privilèges** : un `mint()` `onlyOwner` **sans** `MAX_SUPPLY` est le cas classique à **documenter** et à **assumer** dans le README école. - -**Pistes de design (à justifier dans ton README) :** - -| Approche | Idée | -|----------|------| -| **Supply fixe** | Toute la supply créée au deploy, **pas** de `mint` ensuite | -| **Plafond** | `require(totalSupply() + amount <= MAX_SUPPLY)` | -| **Mint one-shot** | Mint initial puis fonction désactivée | -| **Bonus multisig** | Plusieurs signatures avant un mint ou avant une action owner critique | - -**Exemple courant (OpenZeppelin) :** `ERC20` + `Ownable` + une fonction `mint(address, uint256)` en `onlyOwner` = mint illimité **tant que** tu n’ajoutes pas de limite explicite. Ce n’est pas « faux » pour l’exercice, mais tu dois le dire à l’oral : qui peut mint, quel risque, pourquoi tu as choisi ainsi. - -**Démo eval utile :** montrer qu’un compte **non-owner** ne peut pas `mint` (transaction qui **revert** ou test Hardhat). - -### 7.2 Glossaire anglais — supply, owner, Ownable, onlyOwner - -La doc Solidity et OpenZeppelin est en anglais. Ces quatre termes reviennent partout dans Tokenizer et en soutenance. - -#### Supply (*offre*, *quantité en circulation*) - -| Terme | Signification | -|-------|----------------| -| **supply** | **Quantité totale** de tokens qui **existent** pour ce contrat (à un instant donné). | -| **total supply** | Même idée ; en code ERC-20 : fonction **`totalSupply()`** qui renvoie un nombre (souvent en plus petite unité, avec **décimales**). | -| **fixed supply** | Toute la supply est créée **une fois** (souvent au déploiement) ; il n’y a plus de création après. | -| **max supply** | **Plafond** : on ne peut pas dépasser ce total (souvent constante `MAX_SUPPLY` dans le contrat). | - -**Exemple mental :** si tu crées 1 000 000 tokens au deploy et qu’il n’y a pas de `mint`, la supply est **fixe** à 1 000 000. Chaque `transfer` ne change pas `totalSupply` ; seul un **mint** l’augmente et un **burn** la diminue. - -**À l’oral en français :** tu peux dire « **offre totale** » ou « **quantité totale de tokens émis** » plutôt que laisser *supply* sans traduction. - ---- - -#### Owner (*propriétaire du contrat*) - -| Précision | Détail | -|-----------|--------| -| **Ce que c’est** | Une **adresse** (compte wallet) désignée comme **administrateur** du smart contract — pas « propriétaire de tous les tokens ». | -| **Ce que ce n’est pas** | Ce n’est pas automatiquement la personne qui détient le plus de tokens ; c’est celui qui a les **droits d’administration** définis dans le code (mint, changer le owner, etc.). | -| **Qui devient owner au deploy ?** | Souvent **`msg.sender`** : l’adresse qui a **déployé** le contrat (ta transaction de déploiement). | - -Le sujet parle d’**ownership** (*propriété* / *gouvernance*) au sens : **qui a le pouvoir** sur les fonctions sensibles du contrat. - ---- - -#### Ownable (bibliothèque OpenZeppelin) - -**Ownable** n’est pas un mot du standard BEP-20 : c’est un **module** fourni par [OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) que tu **hérites** dans ton contrat, par exemple : - -```solidity -contract MonToken42 is ERC20, Ownable { - // ... -} -``` - -Ce module ajoute notamment : - -| Élément | Rôle | -|---------|------| -| Variable interne `_owner` | Stocke l’adresse du **owner** actuel | -| `owner()` | Fonction **lecture** : qui est owner ? | -| `transferOwnership(nouvelleAdresse)` | Transfère le rôle admin à une autre adresse (**onlyOwner**) | -| `renounceOwnership()` | Owner renonce à son rôle (plus personne n’est owner — à utiliser en connaissance de cause) | - -**Pourquoi l’utiliser :** pattern éprouvé, lisible en **code review**, moins de bugs qu’un `address boss` écrit à la main. - ---- - -#### onlyOwner (modificateur Solidity) - -En Solidity, un **modifier** (*modificateur*) est une règle placée **avant** une fonction. **`onlyOwner`** (fourni par `Ownable`) signifie : - -> Seule l’adresse retournée par `owner()` peut appeler cette fonction ; **toute autre adresse** voit la transaction **échouer** (*revert*). - -Exemple typique : - -```solidity -function mint(address to, uint256 amount) public onlyOwner { - _mint(to, amount); -} -``` - -| Lecteur du code | Comportement | -|-----------------|--------------| -| Appel depuis le **wallet owner** | `mint` s’exécute, supply augmente | -| Appel depuis **un autre compte** | Échec : pas le droit d’appeler | - -**Lien avec le sujet :** c’est un **privilège** explicite à expliquer en README : « seul le owner peut mint ; en eval je montre qu’un autre compte ne peut pas ». - ---- - -#### Tableau récapitulatif - -| Anglais | Français (soutenance) | Où tu le vois | -|---------|----------------------|---------------| -| **supply** | offre / quantité totale émise | `totalSupply()`, doc, whitepaper | -| **owner** | propriétaire (admin du contrat) | `owner()`, sujet « ownership » | -| **Ownable** | contrat / module « propriété unique » | `import` OpenZeppelin, héritage | -| **onlyOwner** | « réservé au propriétaire » | modifier sur `mint`, `pause`, etc. | - -### 7.3 Multisig — types et lien avec le bonus - -**Multisig** (*multisignature*) = une action (souvent une **transaction** ou un appel de contrat) n’est **valide** que si **plusieurs clés** ont approuvé, selon un seuil **m sur n** : - -> Exemple **2-of-3** : trois signataires possibles, **au moins 2** signatures requises pour exécuter. - -Ce n’est **pas** un mécanisme de consensus de **chaîne** (PoS/PoA) : c’est une règle de **gouvernance** sur un **wallet** ou un **contrat** — souvent proposé en **bonus** Tokenizer. - -#### Multisig ≠ onlyOwner - -| | **onlyOwner** (obligatoire courante) | **Multisig** (bonus sujet) | -|---|--------------------------------------|----------------------------| -| **Qui décide ?** | **Une** adresse | **Plusieurs** adresses selon seuil | -| **Risque** | Une clé volée = tout perdu | Une clé volée ne suffit en général **pas** | -| **Complexité** | Faible (`Ownable`) | Plus élevée (contrat dédié ou wallet multisig) | - -#### Types / formes de multisig (les plus utiles à connaître) - -**1. Wallet multisig on-chain (contrat portefeuille)** - -- Un **smart contract** détient les fonds (BNB, tokens). -- Flux typique : `proposeTransaction` → chaque signataire `confirm` → `execute` quand le seuil **m** est atteint. -- Exemples connus : **Safe** (ex-Gnosis Safe), contrats multisig « maison » pour le bonus. -- **Usage Tokenizer :** le **owner** du token peut être ce contrat multisig au lieu d’un seul MetaMask. - -**2. Multisig sur une fonction précise (contrat custom)** - -- Ton token reste `ERC20`, mais `mint` ou `transferOwnership` exige que **k adresses** aient signé ou validé (pattern plus rare en débutant ; souvent on passe par un wallet multisig qui **est** l’owner). - -**3. Seuils différents (m-of-n)** - -| Notation | Signification | -|----------|----------------| -| **1-of-n** | Une seule signature parmi n suffit (peu protecteur) | -| **2-of-3** | Classique pour petites équipes / testnet | -| **n-of-n** | **Tous** doivent signer (très strict, risque de blocage si une clé est perdue) | -| **m-of-n** | Cas général du sujet (« plusieurs parties » + nombre requis) | - -**4. Multisig « hors chaîne » / institutionnel** - -- Clés réparties entre coffres HSM, procédures bancaires — tu n’en fais pas pour 42 ; utile seulement pour situer le paysage. - -**5. Ce qu’on ne confond pas** - -| Terme | Ce que ce n’est pas | -|-------|---------------------| -| **Multisig** | Pas « plusieurs owners » indépendants sur le même `Ownable` OpenZeppelin standard | -| **Multi-sig Bitcoin (P2SH)** | Même **idée** (m-of-n), autre blockchain — pas ton stack BEP-20 | -| **RPC / plusieurs nœuds** | Infrastructure réseau, pas gouvernance de clés | - -#### Bonus sujet Tokenizer — ce qu’on attend (esprit) - -Le PDF demande un contrat où **plusieurs signatures** sont nécessaires **avant** d’exécuter une transaction sensible. En pratique, les approches acceptables en soutenance : - -1. **Wallet multisig** qui possède l’ownership du token + démo d’un `mint` ou transfert validé à 2-of-n. -2. **Contrat multisig minimal** + documentation : qui signe, quel seuil, comment tester sur testnet. - -Adapter le bonus à **ta** partie obligatoire (même token, même réseau) — voir [guide-realisation.md](guide-realisation.md) étape 8. - -#### Phrase oral utile - -> « Le **consensus PoSA** de BNB Chain fait tourner le réseau ; mon **multisig**, c’est au niveau **application** : plusieurs clés doivent valider avant qu’on puisse agir en tant qu’admin du token. » - ---- - -## 8. Ce que le Web3 t’apporte dans *ce* projet (résumé) - -| Concept Web3 | Dans Tokenizer | -|--------------|----------------| -| Blockchain publique | Déploiement testnet + adresse dans README | -| Smart contract | `code/` — token | -| Token standard | BEP-20 (recommandé) | -| Wallet + gas | tBNB via faucet | -| Transparence | Explorer + verify | -| Gouvernance minimale | Owner, éventuel bonus multisig | - -Pour aller plus loin sur les **compétences** visées : [01-apports-pedagogiques.md](01-apports-pedagogiques.md). -Pour passer à l’action : [guide-realisation.md](guide-realisation.md). - ---- - -## 9. Lectures utiles (hors 42) - -- [Ethereum.org — Introduction](https://ethereum.org/fr/developers/docs/intro-to-ethereum/) (concepts transférables à BSC) -- [BNB Chain — documentation développeurs](https://www.bnbchain.org/en/developers) -- [OpenZeppelin — ERC20](https://docs.openzeppelin.com/contracts/5.x/erc20) - ---- - -## 10. BNB, BNB Chain et Binance (partenaire du sujet) - -Le chapitre I du sujet parle de **BNB Chain** et du faucet **tBNB**. Le sigle **BNB** prête souvent à confusion avec **Binance** : voici une cartographie claire pour Tokenizer. - -### 10.1 Trois sens différents de « BNB » - -| Sens | Explication | -|------|-------------| -| **BNB Chain** | Le **réseau blockchain** (smart contracts, tokens, DApps). Nom marketing actuel : *Build N Build* — c’est ce que le PDF cite en partenariat avec 42. | -| **BNB (l’actif)** | La **monnaie native** de cette chaîne : tu la dépenses en **gas** pour déployer un contrat ou envoyer une transaction. | -| **tBNB** | Même rôle sur le **testnet** : BNB de **test**, **sans valeur réelle** — obtenu via le [faucet](https://www.bnbchain.org/en/testnet-faucet) du sujet. | - -Ton token du projet (BEP-20) est un **autre** contrat : ce n’est pas le BNB natif, mais il vit sur la **même chaîne** et les transferts de ton token consomment aussi du gas payé en (t)BNB. - -### 10.2 Rapport avec Binance - -**Oui, il y a un lien historique et économique**, mais **BNB Chain n’est pas « l’application Binance »** au sens du site d’échange. - -| Élément | Rôle | -|---------|------| -| **Binance** | Entreprise fondée en 2017, connue surtout comme **plateforme d’échange** centralisée (ordres, carnets, comptes utilisateurs). | -| **Origine du token BNB** | Lancé par l’écosystème Binance ; le nom venait souvent de **Binance Coin** à l’époque. | -| **Binance Smart Chain (BSC)** | Lancée en 2020 : chaîne **compatible EVM** (proche d’Ethereum) pour des contrats moins chers / rapides que le mainnet ETH de l’époque. | -| **Rebranding BNB Chain** | La chaîne et la marque ont été regroupées sous **BNB Chain** (*Build N Build*) : communication orientée **réseau pour développeurs**, pas seulement exchange. | - -En soutenance, une formulation honnête et suffisante : - -> « Le sujet est en partenariat avec **BNB Chain**. BNB est la monnaie native de ce réseau ; l’écosystème est lié historiquement à **Binance**, mais mon projet tourne sur le **testnet public** avec **tBNB** — je n’utilise pas de fonds réels ni le compte trading Binance. » - -### 10.3 Noms que tu peux croiser (glossaire) - -| Abréviation | Signification | Utile pour Tokenizer | -|-------------|---------------|----------------------| -| **BSC** | *Binance Smart Chain* — ancien nom courant de la chaîne | Encore utilisé dans les tutos (MetaMask « BSC Testnet ») | -| **BNB Smart Chain** | Formulation intermédiaire | Même famille que BSC / BNB Chain | -| **BEP-20** | Standard des **tokens** sur BNB Chain | **Obligatoire** à respecter (équivalent ERC-20) | -| **BEP-2** | Ancien format sur une autre brique (Binance Chain legacy) | **Pas** le standard de ton exercice type ERC-20/BEP-20 | -| **BscScan** | Explorateur de blocs pour BSC / BNB Chain | Où publier l’adresse du contrat après déploiement | -| **chainId 97** | Identifiant du **BSC Testnet** | À mentionner dans le README école avec l’adresse | - -### 10.4 Ce dont tu as besoin (et ce dont tu n’as pas besoin) - -| Besoin | Pourquoi | -|--------|----------| -| **Wallet** (MetaMask, Rabby, etc.) | Adresse + signature des transactions de déploiement | -| **RPC testnet** | Connexion Hardhat / Remix à la chaîne de test | -| **tBNB** (faucet) | Payer le gas du deploy et des démos | -| **Compte Binance / KYC** | **Non requis** pour le projet tel que décrit dans le sujet | - -Le **mainnet** BNB (vrai BNB avec valeur marché) n’est **pas** demandé ; le sujet insiste sur les **test chains**. - -### 10.5 Lien avec le chapitre I du PDF - -Le partenariat **42 × BNB Chain** explique : - -- les statistiques d’usage (volume, DApps) dans le préambule ; -- le lien vers [bnbchain.org](https://www.bnbchain.org/) (Figure I.1) ; -- le **faucet** pour développer sans argent réel. - -Ce n’impose pas juridiquement BSC en une phrase « tu dois utiliser BSC », mais c’est la piste **la plus alignée** avec le sujet (BEP-20, tBNB, BscScan). Une autre chaîne EVM reste possible si tu **justifies** tes choix dans le README école. - -→ Rappel dans le sujet traduit : [Chapitre I — BNB, Binance et BNB Chain](../sujets/tokenizer.md#bnb-binance-et-bnb-chain). - ---- - -*Dernière révision : ajout section BNB / Binance — à compléter si tu choisis une chaîne non-EVM (peu courant pour ce sujet).* diff --git a/docs/pedagogie/03-hardhat-et-alternatives.md b/docs/pedagogie/03-hardhat-et-alternatives.md deleted file mode 100644 index 1e105bd..0000000 --- a/docs/pedagogie/03-hardhat-et-alternatives.md +++ /dev/null @@ -1,160 +0,0 @@ -# Hardhat et alternatives (Remix, Truffle, Foundry…) - -> **Contexte :** projet Tokenizer — dossier `code/` + `deployment/` ([sujet ch. IV](../sujets/tokenizer.md#chapitre-iv--partie-obligatoire)). -> **Choix projet :** [decisions-projet.md](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`, dossier `contracts/`, `scripts/`, `test/`. -- Commandes courantes : - - `npx hardhat compile` — compile Solidity → artefacts dans `artifacts/` - - `npx hardhat test` — lance les tests (souvent avec **ethers.js**) - - `npx hardhat run scripts/deploy.js --network bscTestnet` — déploie sur le testnet - - `npx 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](02-web3-comprendre.md#39-réseau-rpc)) | -| **@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](https://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](https://github.com/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 - -```mermaid -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](ressources-solidity-hardhat.md) -- [Hardhat — Getting started](https://hardhat.org/hardhat-runner/docs/getting-started) -- [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/) -- Étape suivante : [etape-02-init-hardhat.md](etapes/etape-02-init-hardhat.md) -- [guide-realisation.md](guide-realisation.md) diff --git a/docs/pedagogie/README.md b/docs/pedagogie/README.md deleted file mode 100644 index a02e1ef..0000000 --- a/docs/pedagogie/README.md +++ /dev/null @@ -1,79 +0,0 @@ -# Pédagogie — Tokenizer - -Parcours pour construire le projet **étape par étape** et le défendre en soutenance. - -## Reprise rapide - -→ **[parcours-etape-par-etape.md](parcours-etape-par-etape.md)** — **parcours guidé** (une étape → vérification → suivante). - -→ **[00-reprise-et-etat.md](00-reprise-et-etat.md)** — état du projet. - -→ **[guide-realisation.md](guide-realisation.md)** — référence technique complète (toutes les étapes). - -→ **[decisions-projet.md](decisions-projet.md)** — choix token / chaîne / wallet (**travail**, pas rendu école). - -→ **[checklist-demo-evaluation.md](checklist-demo-evaluation.md)** — **checklist démo / correction** (hors dépôt Vogosphere). - -→ **[sujet-exigences-rendu.md](sujet-exigences-rendu.md)** — grille obligatoire / bonus (PDF v1.1). - -→ **[fiche-soutenance-tokenizer.md](fiche-soutenance-tokenizer.md)** — déroulé oral + code review. - -→ **[audit-rendu-tokenizer.md](audit-rendu-tokenizer.md)** — audit `tokenizerRendu/` + procédure Git Vogosphere. - -→ **[03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md)** — **Hardhat**, Remix, Truffle, Foundry (sujet ch. IV). - -→ **[ressources-solidity-hardhat.md](ressources-solidity-hardhat.md)** — **tutos & docs officiels** Solidity, Hardhat, OpenZeppelin, BSC (parcours d’apprentissage). - -## Apprentissage Solidity / Hardhat - -| Priorité | Document / lien | -|----------|-----------------| -| Index ressources | [ressources-solidity-hardhat.md](ressources-solidity-hardhat.md) | -| Concepts Web3 | [02-web3-comprendre.md](02-web3-comprendre.md) | -| Pourquoi Hardhat | [03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md) | -| Plan lecture minimum (avant étape 3) | [ressources-solidity-hardhat.md § 8](ressources-solidity-hardhat.md#8-plan-de-lecture-minimum-avant-létape-3) | - -→ **[01-apports-pedagogiques.md](01-apports-pedagogiques.md)** — **ce que ce projet t’apporte** (compétences, concepts). - -→ **[02-web3-comprendre.md](02-web3-comprendre.md)** — **Web3 : définition détaillée** (RPC, ERC-20/BEP-20, **PoW/PoS/PoA**, **multisig**, owner, BNB / Binance). - -## Prérequis suggérés - -| Domaine | Niveau attendu | -|---------|----------------| -| Git | Dépôt structuré, README, pas de secrets commités | -| Ligne de commande | npm ou équivalent, variables d’environnement | -| Programmation | Au moins un langage ; Solidity s’apprend pendant le projet | -| 42 | Aucun prérequis Web3 obligatoire — le sujet assume l’apprentissage | - -Ressources externes utiles : [docs Solidity](https://docs.soliditylang.org/), [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/), [BscScan Testnet](https://testnet.bscscan.com/). - -## Étapes du projet - -| Étape | Objectif | Statut | -|-------|----------|--------| -| **0** | Dépôt travail + `docs/`, sujet FR, paquet `tokenizerRendu/` | ✅ **Fait** | -| **1** | [Cadrage + wallet testnet](etapes/etape-01-cadrage-wallet-testnet.md) | ✅ **Validée** | -| **2** | [Init Hardhat](etapes/etape-02-init-hardhat.md) | 🔄 **En cours** | -| **3** | Contrat **FGC42Forge** BEP-20 + tests | ⏳ | -| **4** | `deployment/` + deploy testnet + BscScan | ⏳ | -| **5** | `documentation/` + README école | ⏳ | -| **6** | Démo + code review | ⏳ | -| **7** | Bonus multisig (optionnel) | ⏳ | - -README correcteurs (dépôt école) : [tokenizerRendu/README.md](../../tokenizerRendu/README.md) - -## Sujet de référence - -→ [Traduction FR v1.1](../sujets/tokenizer.md) · PDF : [originaux/tokenizer_subject.pdf](../sujets/originaux/tokenizer_subject.pdf) - -## Guides détaillés - -| Fichier | Rôle | -|---------|------| -| [00-reprise-et-etat.md](00-reprise-et-etat.md) | État, arborescence, reprise | -| [01-apports-pedagogiques.md](01-apports-pedagogiques.md) | Valeur pédagogique du projet | -| [02-web3-comprendre.md](02-web3-comprendre.md) | Web3 — définitions et vocabulaire | -| [guide-realisation.md](guide-realisation.md) | Réalisation technique pas à pas | - -Demande dans le chat l’étape à approfondir : le guide pourra être mis à jour au fil du code (fichiers réels, adresses, scripts). diff --git a/docs/pedagogie/audit-rendu-tokenizer.md b/docs/pedagogie/audit-rendu-tokenizer.md deleted file mode 100644 index 4f5cc23..0000000 --- a/docs/pedagogie/audit-rendu-tokenizer.md +++ /dev/null @@ -1,108 +0,0 @@ -# Audit rendu — `tokenizerRendu/` (avant Vogosphere) - -> Date : 2026-10-22 · Grille : [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md) - -## Verdict global - -| Statut | Commentaire | -|--------|-------------| -| **Prêt pour push école** | Partie obligatoire couverte ; nettoyage doc + `.gitignore` effectués | -| **À faire sur machine école** | `npm install` + `npx hardhat test` ; démo MetaMask ; `git init` ou clone dédié | - ---- - -## Conformité sujet (T1–T19) - -Tous les critères obligatoires du tableau **sujet-exigences-rendu.md** sont **OK** pour FGC42Forge (nom `42`, BEP-20 testnet, 3 dossiers, README choix, deploy + adresse, doc utilisateur, code commenté, bonus documenté comme non retenu). - ---- - -## Fichiers à **inclure** dans le dépôt Vogosphere - -| Zone | Fichiers clés | -|------|----------------| -| Racine | `README.md`, `.gitignore` | -| `code/` | `contracts/FGC42Forge.sol`, tests, ignition module, `hardhat.config.ts`, `package.json`, `package-lock.json`, `.env.example`, `.gitignore`, `README.md` | -| `deployment/` | `addresses.json`, `README.md`, `BSCSCAN_VERIFICATION.md`, `FGC42Forge_flat.sol`, `addresses.json.example` | -| `documentation/` | `README.md`, `STACK-GLOSSAIRE-ET-PARCOURS.md` | - -**Template Hardhat (Counter)** : présent mais documenté comme hors périmètre dans `code/README.md` — acceptable ; ne pas présenter Counter en code review. - ---- - -## Fichiers à **ne pas** committer - -| Chemin | Raison | -|--------|--------| -| `code/.env` | Clé privée | -| `code/node_modules/`, `cache/`, `artifacts/` | Générés | -| `code/ignition/deployments/` | État local Ignition (gros `build-info`) — adresses dans `deployment/addresses.json` | -| `code/.agents/`, `code/AGENTS.md` | Assistants locaux, hors sujet | -| Tout `docs/` ou `pedagogie/` | Dépôt de travail perso uniquement | - -`.gitignore` racine + `code/.gitignore` mis à jour en conséquence. - ---- - -## Écarts mineurs (non bloquants) - -| Point | Action | -|-------|--------| -| `code/scripts/send-op-tx.ts` | Script template Hardhat ; ignoré à l’oral ou supprimable si tu veux un tree plus minimal | -| Tests non relancés dans cet audit (lock compilateur sandbox) | Sur ta machine : `cd code && npx hardhat test` | -| Vidéo démo | Section vide dans README — conforme (optionnel) | - ---- - -## Liens internes rendu - -Aucun lien vers `docs/pedagogie` ou dépôt parent. Liens `../deployment`, `../code` : **OK** (dans le même repo école). - -## Autonomie fonctionnelle (vérification doc) - -| Parcours | Suffisant dans `tokenizerRendu/` seul ? | -|----------|----------------------------------------| -| Utiliser FG42 (MetaMask + BscScan) | ✅ `documentation/README.md` | -| Comprendre stack / commandes / alternatives | ✅ `documentation/STACK-GLOSSAIRE-ET-PARCOURS.md` | -| Tests Hardhat | ✅ README racine + `code/README.md` → `cd code` + `npm install` + test | -| Token on-chain sans redeploy | ✅ adresse dans README + `deployment/addresses.json` | -| Redeploy optionnel | ✅ `deployment/README.md` + `.env.example` | - ---- - -## Procédure Git — Vogosphere - -### Option A — Dépôt **uniquement** rendu (recommandé) - -Sur le PC où tu pousses vers l’intranet 42 : - -```bash -cd /chemin/vers/tokenizerRendu -git init -git add README.md .gitignore code deployment documentation -git status # vérifier : pas de .env, pas de node_modules -git commit -m "Tokenizer: FGC42Forge BSC testnet" -# remote Vogosphere fourni par l’école -git remote add origin -git push -u origin main -``` - -### Option B — Même machine, dépôt perso `tokenizer/` + sous-dossier rendu - -- Ne **pas** pousser la racine `tokenizer/` si elle contient `docs/`. -- Soit **Option A** dans `tokenizerRendu/`, soit branche `rendu` qui ne contient que le contenu de `tokenizerRendu/` (subtree / copie propre). - -### Avant chaque push - -```bash -cd code -grep -r "PRIVATE_KEY" .env 2>/dev/null && echo "STOP: .env présent" || true -git status -``` - ---- - -## Après push - -1. [checklist-demo-evaluation.md](checklist-demo-evaluation.md) -2. [fiche-soutenance-tokenizer.md](fiche-soutenance-tokenizer.md) §10 (démo + oral ch. III) diff --git a/docs/pedagogie/checklist-demo-evaluation.md b/docs/pedagogie/checklist-demo-evaluation.md deleted file mode 100644 index f8d0762..0000000 --- a/docs/pedagogie/checklist-demo-evaluation.md +++ /dev/null @@ -1,68 +0,0 @@ -# Checklist — démo et correction Tokenizer - -> **Dépôt de travail** (`docs/`) — ne pas confondre avec `tokenizerRendu/` (Vogosphere). -> À utiliser **avant** la soutenance : tout doit fonctionner sans improviser. - -**Références rendu :** adresse et vérif → [`tokenizerRendu/deployment/addresses.json`](../../tokenizerRendu/deployment/addresses.json) · [`BSCSCAN_VERIFICATION.md`](../../tokenizerRendu/deployment/BSCSCAN_VERIFICATION.md) · doc utilisateur → [`tokenizerRendu/documentation/README.md`](../../tokenizerRendu/documentation/README.md) - ---- - -## A. Matériel prêt (la veille) - -| # | Action | Fait | -|---|--------|------| -| A1 | MetaMask : réseau **BNB Smart Chain Testnet** (chainId **97**) | ☐ | -| A2 | Compte **FGC_account** : tBNB (gas) + solde **FG42** (token importé) | ☐ | -| A3 | Compte **demo_account** (ou 2ᵉ compte) : token FG42 importé (`0x0c76…0fF4`) | ☐ | -| A4 | Onglets navigateur : [contrat #code](https://testnet.bscscan.com/address/0x0c76df26A1149fDc22C8f994975705271b070fF4#code) · [token](https://testnet.bscscan.com/token/0x0c76df26A1149fDc22C8f994975705271b070fF4) · README rendu local | ☐ | -| A5 | `cd tokenizerRendu/code && npx hardhat test mocha --grep FGC42Forge` → **2 passing** | ☐ | -| A6 | Aucune clé privée à l’écran / dans le dépôt Git | ☐ | - ---- - -## B. Déroulé suggéré (5–10 min) - -| Étape | Tu montres | Tu dis (idée) | -|-------|------------|----------------| -| **B1** | `tokenizerRendu/README.md` | Token **FGC42Forge / FG42**, BSC testnet, adresse, lien doc utilisateur | -| **B2** | BscScan **token** : supply **1M**, transfers | Jeton **BEP-20** ; supply fixe au deploy | -| **B3** | BscScan **Contract** (vérifié) | Source = dépôt ; fiche [`BSCSCAN_VERIFICATION.md`](../../tokenizerRendu/deployment/BSCSCAN_VERIFICATION.md) si questions compilateur | -| **B4** | MetaMask **FGC_account** → transfer **100 FG42** → **demo_account** | `transfer` ERC-20 ; gas en **tBNB** | -| **B5** | BscScan transfers + solde **demo_account** | Preuve on-chain | -| **B6** | `documentation/README.md` | Un évaluateur peut importer le token et transférer sans ton aide | -| **B7** | `code/contracts/FGC42Forge.sol` (commenté) | OpenZeppelin **ERC20 + Ownable** ; supply fixe ; index : `code/README.md` § relecture | -| **B8** | (Optionnel) `npx hardhat test` | Tests automatisés avant deploy | - ---- - -## C. Questions fréquentes — réponses courtes - -| Question | Réponse | -|----------|---------| -| ERC-20 ou BEP-20 ? | **BEP-20** sur BSC ; code **OpenZeppelin ERC20** (même interface EVM). | -| Peut-on mint encore des FG42 ? | **Non** : pas de fonction `mint` publique ; supply **1 000 000** au deploy. | -| Rôle de `owner` ? | Admin **Ownable** ; pas de création de jetons dans ce contrat. | -| Pourquoi BSC testnet ? | Partenaire sujet, tBNB, BscScan ; pas d’argent réel. | -| Pourquoi Hardhat ? | Compile, tests, deploy reproductible (`deployment/`, Ignition). | - ---- - -## D. Bonus multisig - -| # | Action | Fait | -|---|--------|------| -| D1 | Partie **obligatoire** parfaite avant de présenter le bonus | ☐ | -| D2 | Savoir **où** est le code bonus et **comment** le tester (à remplir si implémenté) | ☐ | - ---- - -## E. Après la session - -| # | Action | -|---|--------| -| E1 | Noter questions de l’éval pour améliorer README / doc si besoin | -| E2 | Vérifier que le dépôt Vogosphere (`tokenizerRendu/`) est à jour avant push final | - ---- - -*Dernière mise à jour : 2026-10-20 — adresse contrat FGC42Forge testnet.* diff --git a/docs/pedagogie/decisions-projet.md b/docs/pedagogie/decisions-projet.md deleted file mode 100644 index 1f5584e..0000000 --- a/docs/pedagogie/decisions-projet.md +++ /dev/null @@ -1,130 +0,0 @@ -# Décisions projet — suivi (dépôt de travail) - -> Fichier **pédagogique** (`docs/`) — pas le rendu Vogosphere. Le README école (`tokenizerRendu/README.md`) reprendra une version **validée** à l’étape 5. -> **Identité choisie :** token autour des initiales **FGC** + contrainte sujet **`42`**. - -## Identité du token (FGC) - -| Élément | Choix | Pourquoi c’est « original » | -|---------|--------|-----------------------------| -| **Initiales** | **F · G · C** | Signature personnelle du projet (auteur / porteur du dépôt) | -| **42** | Dans le **nom on-chain** | Exigence obligatoire du sujet ([ch. IV](../sujets/tokenizer.md#contraintes-sur-le-token)) | -| **Métaphore** | **Forge** (*forge*) | Évoquer la **création** du jeton sur la chaîne (comme forger une pièce) — lien avec l’intro du sujet (« create your own token ») | -| **Nom affiché** | **FGC42Forge** | Lecture : *FGC* + *42* + *Forge* — unique, mémorable en soutenance | -| **Ticker** | **FG42** | **F**GC + **42** en 4 caractères (lisible sur BscScan et dans MetaMask) | - -*Variantes si tu veux ajuster avant étape 2 :* `ForgeFGC42` / symbole `F42G` — dis-moi dans le chat. - ---- - -## Métadonnées - -| Champ | Valeur | Concept | Référence | -|-------|--------|---------|-----------| -| **Date** | 2026-10-19 | Date de gel des décisions de cadrage (reprise projet). | [00-reprise-et-etat.md](00-reprise-et-etat.md) | -| **Étape** | **Obligatoire terminée** (2026-10-20) | Deploy `0x0c76…0fF4` · doc · vérif BscScan · bonus non retenu | [parcours](parcours-etape-par-etape.md) | -| **Auteur / initiales** | FGC | Contexte perso du nom du token (pas une exigence du PDF). | — | - ---- - -## Chaîne et standard - -| Champ | Valeur | Concept | Référence | -|-------|--------|---------|-----------| -| **Réseau** | BNB Smart Chain **Testnet** | Blockchain **publique** de test : même logique que la prod BSC, **sans valeur réelle** pour le gas. | Sujet ch. I (faucet tBNB) · ch. IV (« test chains », pas d’argent réel) | -| **Chain ID** | `97` | Identifiant numérique unique du réseau ; MetaMask et Hardhat l’utilisent pour ne pas envoyer une tx sur le mauvais réseau. | [02-web3 § 10.3](02-web3-comprendre.md#103-noms-que-tu-peux-croiser-glossaire) | -| **Standard token** | **BEP-20** | Norme des tokens **fongibles** sur BNB Chain (équivalent **ERC-20** sur Ethereum). | [Sujet ERC-20 / BEP-20](../sujets/tokenizer.md#erc-20-et-bep-20-éclaircissement) · [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) | -| **Consensus (info)** | **PoSA** (réseau) | Tu ne le configures pas ; BSC valide les blocs via validateurs + stake. Distinct du **multisig** (bonus). | [02-web3 § 6.6](02-web3-comprendre.md#66-consensus-de-la-chaîne-pow-pos-poa-et-variantes) | -| **Explorateur** | https://testnet.bscscan.com | Preuve du déploiement : adresse contrat, **ticker**, transfers. | Sujet ch. IV (explorer, adresse + réseau dans Git) | -| **RPC** | `https://data-seed-prebsc-1-s1.binance.org:8545/` | URL d’accès à un nœud : Hardhat / MetaMask envoient les transactions **via** ce point. | [02-web3 § 3.9](02-web3-comprendre.md#39-réseau-rpc) | -| **Monnaie gas** | **tBNB** | Frais de transaction sur testnet ; obtenu via **faucet**, pas d’achat. | Sujet ch. I · [BNB / Binance](../sujets/tokenizer.md#bnb-binance-et-bnb-chain) | - ---- - -## Token — FGC42Forge (sujet : `42` dans le nom) - -| Champ | Valeur | Concept | Référence | -|-------|--------|---------|-----------| -| **Nom** (`name`) | `FGC42Forge` | Chaîne de caractères **longue** affichée dans les wallets (ex. « FGC42Forge »). Doit contenir **`42`**. | Sujet ch. IV (nom libre + `42`, pas d’insultes) | -| **Symbole** (`symbol`) | `FG42` | **Ticker** court (symbole boursier du jeton) ; lié **FGC** + **42**. | Sujet ch. IV (ticker sur explorer après deploy) | -| **Décimales** (`decimals`) | `18` | Nombre de chiffres après la virgule **en interne** ; `1 FG42` = `1 × 10^18` unités minimales. Convention quasi universelle ERC-20. | [02-web3 § 6.2](02-web3-comprendre.md#62-que-impose-le-standard-) | -| **Supply initiale** | `1 000 000` **FG42** | **Offre totale** créée au lancement (`totalSupply`). Montant rond pour démos (`transfer` de 100, 1000…). | [02-web3 § 7.2 supply](02-web3-comprendre.md#supply-offre-quantité-en-circulation) | -| **Supply en contrat** | `1000000 * 10^18` wei | Solidity stocke les montants en **plus petite unité** (comme les « wei » pour l’ETH). | Implémentation ERC-20 (étape 3) | -| **Mint après deploy** | **Non** | Pas de fonction `mint` publique : **personne** ne peut créer de nouveaux FG42 après le deploy → pas de **mint illimité**. | [02-web3 § 7.1](02-web3-comprendre.md#71-mint-et-mint-illimité) | -| **Création initiale** | `_mint(déployeur, supply)` au **constructeur** | Toute la supply est forgée **une fois** à l’adresse qui déploie le contrat. | Pattern ERC-20 OpenZeppelin | -| **Owner** | `Ownable` (OpenZeppelin) | Une adresse **admin** du contrat (`owner()`), distincte du symbole FG42. | Sujet ch. IV (ownership, privilèges) · [02-web3 § 7.2 owner](02-web3-comprendre.md#owner-propriétaire-du-contrat) | -| **Privilèges owner** | `transferOwnership` / `renounceOwnership` | **Pas de mint** : en soutenance tu expliques que l’admin ne peut pas diluer la supply, seulement transférer le rôle admin. | Sujet ch. IV (sécurité, démo minimale) | -| **Fichier contrat prévu** | `FGC42Forge.sol` | Nom de fichier explicite pour la **code review**. | Sujet ch. IV (`code/`, noms lisibles) | - -### ERC-20 dans le code, BEP-20 à l’évaluation (mémo soutenance) - -| Question | Réponse courte | -|----------|----------------| -| Le sujet cite **ERC-20** ? | Oui, comme norme **générique** EVM ; sur **BSC** le sujet attend le standard de la chaîne : **BEP-20**. | -| Pourquoi `import ERC20` et pas `BEP20` ? | OpenZeppelin (et la quasi-totalité des projets BSC) utilisent le contrat **`ERC20`** ; l’interface est la même. | -| Qu’est-ce qui fait « BEP-20 » ? | Le **déploiement sur BNB Chain** (testnet 97) + respect de l’interface (`transfer`, `balanceOf`, etc.) ; **BscScan** qualifie le contrat en **BEP-20**. | -| Phrase à dire le jour J | *« Mon token est **BEP-20** sur BSC Testnet ; le Solidity hérite d’**OpenZeppelin ERC20**, l’équivalent ERC-20 sur cette chaîne. »* | - -Réf. : [sujet § ERC-20 / BEP-20](../sujets/tokenizer.md#erc-20-et-bep-20-éclaircissement) · [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) - -### Lore / justification (pour `documentation/` et whitepaper léger) - -| Aspect | Texte proposé | -|--------|----------------| -| **Univers** | *FGC42Forge* est un jeton **fictif** de test : chaque **FG42** représente une « étincelle » de participation à un atelier Web3 42 — forgée une seule fois sur BSC Testnet. | -| **FGC** | Initiales du créateur ; ancrage personnel du projet (comme une signature). | -| **42** | Rappel de l’école et contrainte du sujet. | -| **Forge** | Métaphore de la **création on-chain** (deploy = acte de forge). | -| **Valeur** | **Aucune** valeur monétaire réelle ; testnet uniquement. | -| **Public cible** | Évaluateur / pairs : comprendre BEP-20, transfers, explorer. | - ---- - -## Stack technique (prévue) - -| Outil | Choix | Concept | Référence | -|-------|--------|---------|-----------| -| **Langage** | Solidity | Langage des smart contracts **EVM** (BSC). | Sujet ch. IV (langage de la plateforme) | -| **Toolchain** | Hardhat | Compile, tests locaux, scripts de deploy → dossiers **`code/`** et **`deployment/`**. | Sujet ch. IV (Truffle, Remix, **Hardhat** cités) | -| **OpenZeppelin** | `ERC20` + `Ownable` | Bibliothèque auditée ; **BEP-20** en pratique via ERC20 sur BSC. | [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) | -| **Tests** | Hardhat + (chai/ethers) | Vérifier `transfer`, supply, droits **avant** testnet public. | Bonne pratique + soutenance | -| **Secrets** | `.env` + `PRIVATE_KEY` | Clé du compte **test** pour signer le deploy ; **jamais** dans Git. | `.gitignore` rendu · sujet (sécurité implicite) | -| **IDE** | Cursor / VS Code | Édition + doc ; Remix optionnel pour un test rapide. | Sujet ch. IV (IDE) | - ---- - -## Wallet de test (public uniquement) - -| Champ | Valeur | Concept | Référence | -|-------|--------|---------|-----------| -| **Compte MetaMask** | `FGC_account` | Compte Chrome dédié au projet (même adresse `0x…` sur tous réseaux EVM). | [Marche à suivre étape 1](etapes/etape-01-cadrage-wallet-testnet.md#marche-à-suivre-metamask-chrome--faucet-tbnb) | -| **Adresse publique** | `0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c` | Compte **FGC_account** — adresse **publique** (OK en doc ; ne jamais y associer seed / clé privée). | [02-web3 § 3.5 wallet](02-web3-comprendre.md#35-wallet-portefeuille) | -| **tBNB (faucet)** | **Oui** — **0,1 tBNB** (2026-10-20, Telegram @bnbchain_official_bot) | Suffisant pour deploy + démos (sujet testnet). Tx : [testnet.bscscan.com/tx/0x7ca577…bb2ee](https://testnet.bscscan.com/tx/0x7ca57757494000b98b83e82563cb59932fad2fb329c7948974825e9312cbb2ee) | [faucets doc](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/) | -| **Compte dédié** | `FGC_account` | Pas de fonds mainnet sur ce compte si possible. | Sujet ch. IV (pas d’argent réel) | - -**Procédure complète (MetaMask + réseau 97 + faucet)** → [etape-01 — section détaillée](etapes/etape-01-cadrage-wallet-testnet.md#marche-à-suivre-metamask-chrome--faucet-tbnb). - -### Paramètres MetaMask — BSC Testnet (config validée FGC) - -| Paramètre | Valeur | Concept | -|-----------|--------|---------| -| Nom | **`BNB Smart Chain Testnet`** (sans faute / sans espaces en trop) | Un nom ou RPC mal saisi peut déclencher l’avertissement « arnaque » même avec de vrais tBNB. | -| RPC URL | `https://data-seed-prebsc-1-s1.binance.org:8545/` ou `https://bsc-testnet-dataseed.bnbchain.org` | Les deux sont utilisés par la doc BNB / bot Telegram. | -| Chain ID | `97` | Doit correspondre à Hardhat `networks.bscTestnet` | -| Symbole | **`tBNB`** | OK une fois le réseau corrigé — solde **0,1 tBNB**, **sans** avertissement MetaMask (oct. 2026). | -| Explorer | https://testnet.bscscan.com | Tx faucet : `0x7ca577…bb2ee` | -| Compte | **FGC_account** | `0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c` | - ---- - -## Prochaines étapes (rappel parcours) - -| # | Action | -|---|--------| -| 1 | Compléter **adresse** + **tBNB** ci-dessus → demander vérification étape 1 | -| 2 | Init Hardhat dans `tokenizerRendu/code/` (nom package aligné sur FGC42Forge) | -| 3 | Écrire `FGC42Forge.sol` selon ce tableau | - ---- - -**Ne pas écrire ici :** clé privée, seed phrase, contenu complet de `.env`. diff --git a/docs/pedagogie/etapes/etape-01-cadrage-wallet-testnet.md b/docs/pedagogie/etapes/etape-01-cadrage-wallet-testnet.md deleted file mode 100644 index 5f3cade..0000000 --- a/docs/pedagogie/etapes/etape-01-cadrage-wallet-testnet.md +++ /dev/null @@ -1,231 +0,0 @@ -# Étape 1 — Cadrage + wallet testnet (tBNB) - -> **Sujet (chapitre IV) :** choisir une blockchain ; nom du token avec **`42`** ; **pas d’argent réel** — test chains + faucet (chapitre I). -> **Pas encore de code** dans `tokenizerRendu/code/` — uniquement des **décisions** documentées côté travail. - ---- - -## Ce que le sujet exige à ce stade - -| Exigence PDF | Action étape 1 | -|--------------|----------------| -| Plateforme blockchain | Choisir et noter : **BNB Smart Chain Testnet** (recommandé partenariat BNB) | -| Nom avec `42`, pas d’insultes | Choisir **nom** + **symbole** (ticker) | -| Standard de la chaîne | Noter : **BEP-20** (équivalent ERC-20 sur BSC) | -| Pas de vrai argent | Wallet **dédié test** + **tBNB** via faucet uniquement | -| README choix (plus tard) | Préparer les décisions ici ; README école à l’étape 5 | - ---- - -## À faire (checklist) - -### A. Décisions produit (à écrire dans [decisions-projet.md](../decisions-projet.md)) - -- [x] **Nom** / **symbole** validés : **`FGC42Forge`** / **`FG42`** (voir [decisions-projet.md](../decisions-projet.md)) -- [ ] Compléter le reste des tableaux si pas déjà fait -- [ ] **Décimales** (souvent `18` — standard ERC-20) -- [ ] **Supply** : fixe au deploy **ou** mint réservé au owner (justifier en une phrase) -- [ ] **Chaîne** : BSC Testnet, **chainId `97`** -- [ ] **Stack prévue** : Solidity + Hardhat + OpenZeppelin (pour étape 2+) - -### B. Wallet de test — voir [marche à suivre détaillée](#marche-à-suivre-metamask-chrome--faucet-tbnb) ci-dessous - -### C. Faucet tBNB — idem section détaillée - -### D. Sécurité (dès maintenant) - -- [ ] Ne **pas** committer `.env` ni clé privée (`.gitignore` rendu déjà prévu) -- [ ] Ne pas partager la **seed phrase** dans le chat 42 / Discord / Git - ---- - -## Pourquoi on ne « crée » pas le tBNB soi-même - -| Question | Réponse | -|----------|---------| -| Peut-on **générer** du tBNB comme on écrira **FGC42Forge** plus tard ? | **Non** sur le **testnet public** : le **tBNB** est la **monnaie native** de la chaîne (gas). Seuls le **réseau** (validateurs) et les **faucets** officiels / communautaires en **envoient** à ton adresse `0x…`. | -| Et en local (Hardhat) ? | Sur une chaîne **locale** (`npx hardhat node`), Hardhat te donne des ETH de test **fictifs** — utile pour coder (étape 2–3), mais le **sujet 42** exige aussi un déploiement sur une **blockchain publique** + explorer ([ch. IV](../../sujets/tokenizer.md#déploiement-2ᵉ-dossier)). Il faudra donc du **vrai testnet** tBNB à un moment. | -| Pourquoi Discord / Telegram ? | Ce ne sont pas des « contournements » : la [doc officielle BNB](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/) liste **faucet web**, **Discord**, **Telegram** et faucets tiers. Quand le site [bnbchain.org testnet-faucet](https://www.bnbchain.org/en/testnet-faucet) demande **0,002 BNB mainnet**, les autres canaux restent la voie normale. | -| Exemple projet 42 | [BdClement/Tokenizer](https://github.com/BdClement/Tokenizer) (BEP-20, BSC Testnet 97) : *« I obtained tBNB via a faucet available on the **BNB Discord server** »* + deploy Truffle / Alchemy RPC. | - -Le sujet PDF (ch. I) renvoie au **BNB Chain Faucet** : en 2025–2026 l’écosystème a **resserré** les faucets web (mainnet ou réserves vides). **Demander des tBNB** = étape d’intégration Web3 réaliste, pas une erreur de parcours. - ---- - -## Marche à suivre MetaMask (Chrome) + faucet tBNB - -> Retour d’expérience projet FGC — compte **`FGC_account`**, réseau **testnet 97**, faucet **BNB 0,3**. - -### 1. Installer et créer le compte - -| Étape | Action | -|-------|--------| -| 1 | Installer l’extension [MetaMask](https://metamask.io) depuis le **Chrome Web Store** (site officiel uniquement). | -| 2 | **Créer un wallet** avec un **mot de passe** (déverrouille l’extension sur ce PC). | -| 3 | **Sauvegarder la seed phrase** (12 mots) : Paramètres → Sécurité → **Révéler la phrase secrète de récupération** — noter sur papier, **jamais** Git / chat / `.env`. | -| 4 | Renommer le compte (optionnel) : ex. **`FGC_account`** — un compte dédié au projet Tokenizer. | - -### 2. Comprendre réseau vs adresse - -| Idée | Détail | -|------|--------| -| Menu du haut MetaMask | Liste de **réseaux** (Ethereum, BNB Chain, …), pas une « adresse BNB » différente par chaîne. | -| Même compte EVM | **`FGC_account`** a **une** adresse publique `0x…` sur Ethereum, BSC testnet, etc. | -| **BNB Chain** (sans « Testnet ») | Souvent le **mainnet** (chainId **56**) → **ne pas** utiliser pour ce projet. | -| **BNB Smart Chain Testnet** | chainId **97** → réseau du sujet + **tBNB**. | - -### 3. Ajouter BNB Smart Chain Testnet (souvent absent par défaut) - -**Méthode manuelle** - -1. MetaMask → clic sur le **nom du réseau** en haut. -2. **Ajouter un réseau** → si besoin **Ajouter un réseau manuellement**. -3. Remplir : - -| Champ | Valeur | -|-------|--------| -| Nom du réseau | `BNB Smart Chain Testnet` | -| URL RPC | `https://data-seed-prebsc-1-s1.binance.org:8545/` | -| ID de chaîne | `97` | -| Symbole | **`BNB`** (évite l’avertissement MetaMask) ou `tBNB` | -| Explorateur | `https://testnet.bscscan.com` | - -4. Enregistrer → **basculer** sur ce réseau. - -**Alternative :** [chainlist.org](https://chainlist.org) → activer **Include Testnets** → chercher BSC Testnet (97) → Add to MetaMask. - -### 4. Copier l’adresse dans MetaMask (étape A) - -1. Réseau sélectionné : **BNB Smart Chain Testnet** (en haut de l’extension). -2. Compte : **FGC_account**. -3. Sous le nom du compte tu vois une ligne du type **`0x1a2b…9f0c`** (tronquée). -4. Clique cette ligne **ou** les **trois points** → **Détails du compte** → bouton **Copier** / icône copier à côté de l’adresse. -5. Tu dois obtenir **une seule chaîne** : `0x` + **40** caractères (0–9, a–f) — **pas** d’espaces, **pas** de retour à la ligne. - -**Ce n’est pas :** la seed (12 mots), la clé privée, le mot de passe MetaMask, l’URL RPC, le chainId `97`. - -### 4 bis. Où coller l’adresse — et où **ne pas** la coller - -``` -MetaMask (FGC_account) ──copier 0x…──► SITE WEB du faucet ──► ton compte reçoit tBNB - │ - └── PAS dans MetaMask "Ajouter réseau" (sauf URL RPC officielle, pas ton 0x) -``` - -| Endroit | Coller ton `0x…` ? | Pourquoi | -|---------|-------------------|----------| -| **Site faucet** — champ « Wallet address » / « Enter your address » | ✅ **OUI** | C’est **ici** que le site envoie les tBNB. | -| **Site faucet** — bouton « Connect wallet » | ✅ **OUI** (alternative) | MetaMask remplit l’adresse tout seul — souvent plus simple. | -| MetaMask → Ajouter réseau → **URL RPC** | ❌ **NON** | On met l’URL `https://data-seed-prebsc-1-s1…`, **pas** ton adresse. | -| MetaMask → Ajouter réseau → **Chain ID** | ❌ **NON** | On met `97`, pas `0x…`. | -| Fichier `.env` à l’étape 1 | ❌ **pas obligatoire** | Plus tard : **clé privée** (autre format), pas l’adresse seule pour Hardhat. | -| [decisions-projet.md](../decisions-projet.md) | ✅ **OUI** (suivi perso) | Pour documenter ton étape 1. | -| Barre de recherche **testnet.bscscan.com** | ✅ (pour **vérifier**) | Pas pour recevoir des tBNB — seulement pour voir ton solde. | - -### 5. Faucet — QuickNode (recommandé si erreur mainnet) - -1. Ouvre **dans Chrome** (pas dans MetaMask) : https://faucet.quicknode.com/binance-smart-chain/bnb-testnet -2. Vérifie que la page indique **Binance Smart Chain** + **Testnet** (pas Mainnet). -3. **Option 1 — la plus simple :** bouton **Connect wallet** → choisis **MetaMask** → compte **FGC_account** → autorise. -4. **Option 2 :** champ du type **« Drop in your wallet details »** / adresse → **colle** le `0x…` copié à l’étape 4. -5. Passe captcha / Continue → confirme la demande. -6. **Ne colle pas** l’adresse dans un menu déroulant « Token » (BNB/BTC) : le token **BNB** est ce qu’on **reçoit**, pas un champ d’adresse. - -### 5 bis. Faucet officiel BNB (si tu l’utilises malgré tout) - -1. Ouvrir [BNB Chain Testnet Faucet](https://www.bnbchain.org/en/testnet-faucet). -2. Grand champ **adresse du wallet** (souvent au centre) → **colle `0x…`**. -3. Ensuite seulement : choisir token **BNB** et montant **0,3** → bouton **Request** / **Send**. - - **Token : BNB** (sur testnet = **tBNB**, pas de valeur réelle). - - **Montant : 0,3 BNB** — suffisant pour deploy + démos. - - **Ne pas** choisir BTC / autres tokens pour ce projet (inutiles sur BSC testnet). -4. Valider (captcha / connexion si demandé). -5. Attendre 1–5 min → MetaMask sur réseau **Testnet** : solde **tBNB** ≈ 0,3. -6. Noter dans `decisions-projet.md` : **tBNB reçu : oui** + date. - -### 6. Dépannage rapide - -| Problème | Piste | -|----------|--------| -| Pas de « Testnet » dans la liste | Ajout **manuel** (§ 3), pas seulement « BNB Chain ». | -| Faucet OK mais solde 0 | Mauvais réseau sélectionné dans MetaMask (revenir à **97**). | -| Adresse invalide sur BscScan | Re-copier l’adresse sans espace. | -| Limite faucet | Réessayer plus tard (souvent 1× / 24 h). | -| **« less than 0.002 BNB on BSC Mainnet »** | Le [faucet BNB officiel](https://www.bnbchain.org/en/testnet-faucet) exige parfois un peu de **BNB mainnet** sur la même adresse — **inutile d’acheter** pour le sujet 42 (pas d’argent réel). Utiliser un **faucet alternatif** (§ 7). | -| **QuickNode : « Low balance for this chain and network »** + **Continue** grisé | Souvent le **faucet QuickNode est à sec** (plus de tBNB côté serveur), **pas** que tu as mal connecté MetaMask. Réessayer plus tard ou utiliser **Discord / Telegram** (§ 7 bis). | - -### 7. Faucets alternatifs (sans BNB mainnet) - -Aligné sujet : **testnet uniquement**, pas d’achat de BNB réel. - -| Faucet | URL | Remarque | -|--------|-----|----------| -| **QuickNode** (recommandé) | https://faucet.quicknode.com/binance-smart-chain/bnb-testnet | Réseau **Testnet**, coller `0x…` ou connecter MetaMask ; pas de solde mainnet requis (cooldown ~12 h). | -| **Bot Telegram BNB Chain** | [@bnbchain_official_bot](https://t.me/bnbchain_official_bot) | Message du type : `I would like to get tBNB to my wallet 0x…` — voir [doc officielle](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/). | -| **Discord BNB Chain** | Serveur officiel (ticket support) | Même idée que Telegram — doc ci-dessus. | -| Chainstack | https://faucet.chainstack.com/bnb-testnet-faucet | **Évite** si tu n’as pas **0,002 ETH mainnet** (même type de blocage). | - -Après toute source : vérifier le solde **tBNB** sur MetaMask (réseau **97**) et sur https://testnet.bscscan.com. - -### 7 bis. Discord BNB Chain (si QuickNode + officiel bloqués) - -Souvent le moyen le plus fiable quand les faucets web sont vides ou demandent du mainnet : - -1. Rejoindre le **Discord officiel** BNB Chain (lien depuis [bnbchain.org](https://www.bnbchain.org/) ou [doc faucet](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/)). -2. Canal **#roles** → prendre le rôle **Developer** (ou les rôles proposés) pour voir **#testnet-faucet**. -3. Dans **#testnet-faucet** : commande **`/faucet`** → coller ton adresse `0x…` (compte **FGC_account**). -4. Limite typique : ~0,3 tBNB / jour. - -**Telegram :** [@bnbchain_official_bot](https://t.me/bnbchain_official_bot) — message : `I would like to get tBNB to my wallet 0x…` - -### 8 bis. Avertissement MetaMask « symbole du jeton natif » (tBNB vs BNB) - -**Symptôme :** icône ⚠️ *« Il pourrait s’agir d’une arnaque »* — *vous avez saisi **tBNB** alors que le symbole attendu…* - -| Cause | Ce n’est en général **pas** une arnaque si : | -|-------|---------------------------------------------| -| Tu as ajouté le réseau **manuellement** avec symbole **tBNB** | MetaMask compare au **registre** des chaînes (chainId **97** = symbole officiel souvent **BNB**, pas `tBNB`). | -| Ta tx BscScan est **Success** sur **Bsc Testnet** | Comme ta capture : 0,1 **BNB** reçu de `0xF2D4…` → `0xB6bE…` — c’est le **bon** testnet. | - -**Correction (retour d’expérience FGC) :** - -1. Vérifier le **nom exact** du réseau : **`BNB Smart Chain Testnet`** (pas de faute, pas d’espaces parasites dans RPC / chainId). -2. Chain ID **`97`**, explorer **testnet.bscscan.com**. -3. Symbole **`tBNB`** ou **`BNB`** selon ce que MetaMask accepte sans ⚠️ — les deux désignent le gas testnet. -4. Le solde (ex. **0,1 tBNB**) ne change pas après correction du réseau. - -**À ne pas faire :** supprimer le réseau en paniquant ; **ne pas** « ignorer » des tx inconnues — ici tu as **vérifié** le hash sur testnet.bscscan.com. - -### 9. BNB ou tBNB sur l’écran du faucet ? - -Sur le **testnet**, quand le faucet affiche **« BNB »**, tu reçois bien du **tBNB** (gas de test). MetaMask peut l’afficher en **tBNB** une fois le réseau **Testnet (97)** sélectionné. Pas besoin d’une ligne « tBNB » séparée sur le site. - -### 10. Fichier `.env` (pas à l’étape 1 obligatoire) - -| Emplacement | Usage | -|-------------|--------| -| `tokenizer/.env` à la racine | Éviter d’y mettre la **seed** ; racine déjà dans `.gitignore`. | -| `tokenizerRendu/code/.env` | **Étape 2+** : `PRIVATE_KEY` du compte **test** pour Hardhat uniquement. | - -**Ne jamais committer** `.env`. La clé privée (MetaMask → Détails du compte → Afficher la clé privée) = compte test seulement, plus tard pour deploy. - ---- - -## Livrable pour demander la vérification - -Quand tout est fait, envoie dans le chat : - -1. « Étape 1 terminée » -2. Le **nom** et **symbole** du token -3. Confirmation : **tBNB** visible (sans donner ta clé privée) -4. *(Optionnel)* les 4 premiers caractères de ton adresse publique pour qu’on vérifie que `decisions-projet.md` est cohérent - -L’assistant lira [decisions-projet.md](../decisions-projet.md) et validera avant l’**étape 2** (projet Hardhat dans `tokenizerRendu/code/`). - ---- - -## Références - -- [Sujet — partie obligatoire](../../sujets/tokenizer.md#chapitre-iv--partie-obligatoire) -- [BNB / faucet](../../sujets/tokenizer.md#faucet-testnet) -- [BEP-20 / ERC-20](../../sujets/tokenizer.md#erc-20-et-bep-20-éclaircissement) diff --git a/docs/pedagogie/etapes/etape-02-init-hardhat.md b/docs/pedagogie/etapes/etape-02-init-hardhat.md deleted file mode 100644 index eac3719..0000000 --- a/docs/pedagogie/etapes/etape-02-init-hardhat.md +++ /dev/null @@ -1,316 +0,0 @@ -# Étape 2 — Initialiser Hardhat dans `tokenizerRendu/code/` - -> **Sujet (ch. IV) :** dossier **`code/`** à la racine du dépôt école ; maîtriser la toolchain (Hardhat cité) ; code commenté plus tard (étape 3). -> **Prérequis :** étape 1 ✅ (réseau BSC Testnet 97, tBNB sur **FGC_account**). -> **Lire d’abord (recommandé) :** [Hardhat et alternatives](../03-hardhat-et-alternatives.md) · [Ressources Solidity / Hardhat](../ressources-solidity-hardhat.md) (§ 2 + § 8 plan minimum). - ---- - -## Objectif (en une phrase) - -Tu installes sur ta machine une **chaîne d’outils** (Node + Hardhat) qui va **compiler** du Solidity, **lancer des tests** et **déployer** sur BSC Testnet — sans écrire encore ton token **FGC42Forge** (étape 3). - -### Rappel pédagogique : qui fait quoi ? - -| Élément | Rôle | -|--------|------| -| **Solidity** | Langage des contrats (`FGC42Forge.sol`, plus tard). | -| **Hardhat** | Programme Node.js : compile, tests, scripts de déploiement. | -| **OpenZeppelin** | Bibliothèque de contrats éprouvés (`ERC20`, `Ownable`) — installée maintenant, utilisée à l’étape 3. | -| **`.env`** | Fichier local avec RPC + clé privée — lu par `hardhat.config.js`, **jamais** dans Git. | - ---- - -## Vue d’ensemble des sous-étapes - -1. **A** — Vérifier Node.js et se placer dans `tokenizerRendu/code/` -2. **B** — Créer `package.json` et installer Hardhat -3. **C** — Lancer `npx hardhat init` (assistant interactif) -4. **D** — Installer OpenZeppelin + `dotenv` -5. **E** — Configurer `hardhat.config.js` pour **BSC Testnet (chainId 97)** -6. **F** — Créer `.env` (secret) et `.env.example` (modèle pour le rendu) -7. **G** — `npx hardhat compile` (preuve que tout fonctionne) -8. **H** — Compléter `code/README.md` - -Durée indicative : **30–45 min** la première fois (surtout la lecture des menus `hardhat init`). - ---- - -## A. Environnement - -### Où travailler ? - -Le sujet demande le code dans **`tokenizerRendu/code/`** (dépôt de rendu), pas à la racine `tokenizer/` du dépôt de travail. - -```bash -cd /home/fgras-ca/projets/42School/tokenizer/tokenizerRendu/code -pwd # doit finir par .../tokenizerRendu/code -``` - -### Node.js - -```bash -node -v # idéalement ≥ 18 (ex. v20, v22) -npm -v -``` - -Si `node` est introuvable : installer [Node.js LTS](https://nodejs.org/) ou utiliser `nvm`. - -**Checklist :** - -- [ ] `node -v` OK -- [ ] Tu es dans `tokenizerRendu/code/` - ---- - -## B. Créer le projet npm - -`npm init -y` crée un **`package.json`** minimal : nom du projet, scripts, liste des dépendances. - -```bash -npm init -y -``` - -Tu dois voir un fichier `package.json` apparaître dans `code/`. - -Puis installer Hardhat et le **toolbox** (plugins officiels : tests, Ethers, etc.) : - -```bash -npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox -``` - -- `--save-dev` = outils de développement uniquement (pas besoin sur la blockchain). -- Première install : **téléchargement** depuis le registre npm → connexion Internet requise. - -**Checklist :** - -- [ ] `package.json` présent -- [ ] Dossier `node_modules/` créé (ignoré par Git via `.gitignore` parent) - ---- - -## C. Assistant d’initialisation Hardhat - -Tu as installé **Hardhat 3** (ex. `3.20.x` via `npm install hardhat`). À partir de la v3, la commande a changé : - -```bash -npx hardhat --init -``` - -> **Erreur HHE3** avec `npx hardhat init` ? C’est normal : l’ancienne sous-commande `init` n’existe plus. Le message te dit d’utiliser **`--init`** (avec deux tirets). - -Lance **`npx hardhat --init` dans ton terminal** (pas dans un environnement non interactif) : Hardhat affiche le logo et te pose des questions. - -`npx` exécute le binaire Hardhat **sans** l’installer globalement. - -### Variante (tutos Hardhat 2 uniquement) - -Si tu veux coller aux vieux tutos (`hardhat init` + `hardhat.config.js` + `npx hardhat compile`), tu peux **épingler Hardhat 2** avant d’initialiser : - -```bash -npm uninstall hardhat @nomicfoundation/hardhat-toolbox -npm install --save-dev hardhat@2.22.19 @nomicfoundation/hardhat-toolbox@5 -npx hardhat init -``` - -Pour ce projet 42, **Hardhat 3 + `--init`** convient très bien ; on adaptera la config réseau BSC après l’assistant (souvent `hardhat.config.ts` + `npx hardhat build` au lieu de `compile`). - -### Choix recommandés (JavaScript, plus simple pour ce projet) - -Les libellés peuvent varier légèrement selon la version de Hardhat ; l’idée : - -| Question | Choix conseillé | Pourquoi | -|----------|-----------------|----------| -| Type de projet | **Create a JavaScript project** | Moins de config TypeScript pour commencer | -| Emplacement du config | **Oui** / racine de `code/` | `hardhat.config.js` à côté de `package.json` | -| Projet vide ou exemple ? | **Oui, exemple** (Lock) | Tu vérifies compile + tests ; Lock supprimé à l’étape 3 | -| `.gitignore` dans `code/` ? | **Non** si déjà couvert par `tokenizerRendu/.gitignore` | Évite les doublons ; le parent ignore déjà `node_modules`, `cache`, `artifacts` | - -### Arborescence typique après init - -``` -tokenizerRendu/code/ -├── contracts/ -│ └── Lock.sol # exemple — temporaire -├── test/ -│ └── Lock.js # tests de l’exemple -├── scripts/ -│ └── (deploy Lock, etc.) -├── hardhat.config.js -├── package.json -└── package-lock.json -``` - -**Checklist :** - -- [ ] `hardhat.config.js` existe -- [ ] `contracts/Lock.sol` existe (pour l’instant) - ---- - -## D. OpenZeppelin et dotenv - -```bash -npm install @openzeppelin/contracts -npm install dotenv -``` - -- **OpenZeppelin** : tu n’importes rien encore ; c’est pour l’étape 3 (`import "@openzeppelin/contracts/..."`). -- **dotenv** : charge les variables du fichier `.env` dans `process.env` au lancement de Hardhat. - -**Checklist :** - -- [ ] Les deux paquets listés dans `package.json` → `dependencies` ou `devDependencies` - ---- - -## E. Configurer BSC Testnet dans `hardhat.config.js` - -Ouvre `hardhat.config.js` et remplace son contenu par (ou fusionne proprement si tu préfères) : - -```javascript -require("@nomicfoundation/hardhat-toolbox"); -require("dotenv").config(); - -/** @type import('hardhat/config').HardhatUserConfig */ -module.exports = { - solidity: "0.8.24", - networks: { - bscTestnet: { - url: process.env.BSC_TESTNET_RPC || "https://data-seed-prebsc-1-s1.binance.org:8545/", - chainId: 97, - accounts: process.env.PRIVATE_KEY ? [process.env.PRIVATE_KEY] : [], - }, - }, -}; -``` - -### Ce que signifient les lignes importantes - -- **`solidity: "0.8.24"`** : version du compilateur pour tous les contrats (alignée avec OpenZeppelin récent). -- **`bscTestnet`** : nom **local** du réseau ; tu l’utiliseras plus tard avec `--network bscTestnet`. -- **`chainId: 97`** : identifiant officiel BNB Smart Chain **Testnet** (doit correspondre à MetaMask). -- **`accounts`** : si `PRIVATE_KEY` est vide, tableau vide → compile/tests locaux OK ; **déploiement** testnet nécessitera la clé (étape déploiement). - -Tu ne déploies **pas** sur le testnet dans cette étape : tu prépares seulement la config. - -**Checklist :** - -- [ ] `require("dotenv").config();` présent -- [ ] `chainId: 97` présent - ---- - -## F. Fichiers `.env` et `.env.example` - -### Sécurité (à lire une fois pour toute la suite) - -- La **clé privée** = contrôle total du compte → **compte de test uniquement** (FGC_account). -- **Ne jamais** : commit Git, capture d’écran publique, message Discord/chat avec la clé. -- Si tu as un `.env` à la racine `tokenizer/` (dépôt travail), le secret pour Hardhat doit vivre dans **`tokenizerRendu/code/.env`** (celui que lit `hardhat.config.js`). - -### `tokenizerRendu/code/.env` (local, ignoré par Git) - -Crée le fichier à la main : - -```env -BSC_TESTNET_RPC=https://data-seed-prebsc-1-s1.binance.org:8545/ -PRIVATE_KEY=0x................................................................ -``` - -**Obtenir la clé (MetaMask)** : compte **FGC_account** → ⋮ → **Détails du compte** → **Afficher la clé privée** (mot de passe MetaMask) → copier **avec** le préfixe `0x`. - -### `tokenizerRendu/code/.env.example` (à committer) - -Même structure, **sans** vraie clé : - -```env -BSC_TESTNET_RPC=https://data-seed-prebsc-1-s1.binance.org:8545/ -PRIVATE_KEY= -``` - -Le `.gitignore` du rendu (`tokenizerRendu/.gitignore`) contient déjà `.env` et autorise `.env.example` via `!.env.example`. - -**Checklist :** - -- [ ] `.env` créé dans **`code/`** (pas seulement à la racine tokenizer) -- [ ] `.env.example` créé -- [ ] `git status` ne liste **pas** `.env` comme fichier à committer - ---- - -## G. Vérifier la compilation - -```bash -npx hardhat compile -``` - -### Sortie attendue (succès) - -Quelque chose comme : - -``` -Compiled 1 Solidity file successfully (evm target: paris). -``` - -Des dossiers **`cache/`** et **`artifacts/`** apparaissent (déjà ignorés par Git). - -### Tests optionnels (exemple Lock) - -```bash -npx hardhat test -``` - -Si les tests passent, Hardhat + toolbox sont bien branchés. Ce n’est pas obligatoire pour valider l’étape 2, mais c’est rassurant. - -### Dépannage rapide - -| Problème | Piste | -|----------|--------| -| **HHE3** — `No Hardhat config` + « run with **--init** » | Utiliser `npx hardhat --init` (Hardhat 3), pas `npx hardhat init` | -| **HHE11** — pas de shell interactif | Lancer `--init` dans **ton** terminal Cursor / système | -| `Cannot find module '@nomicfoundation/hardhat-toolbox'` | Relancer `npm install` dans `code/` | -| Erreur Solidity / version | Vérifier `solidity` dans `hardhat.config.js` et la version en tête de `Lock.sol` | -| `PRIVATE_KEY` / invalid account | Normal si clé mal formatée ; **compile** ne nécessite pas la clé. Corriger avant déploiement. | -| Permission réseau npm | Vérifier proxy / réseau ; réessayer `npm install` | - -**Checklist :** - -- [ ] `npx hardhat compile` **sans erreur** - ---- - -## H. Mettre à jour `code/README.md` - -Ajoute une section courte (en français pour ton suivi ; README école final plus tard si besoin) : - -- Prérequis : Node ≥ 18 -- `cd code && npm install` -- Copier `.env.example` → `.env` et remplir `PRIVATE_KEY` -- `npx hardhat compile` -- Prochaine étape : contrat **FGC42Forge** (étape 3) - ---- - -## Livrable pour vérification (dans le chat) - -1. « Étape 2 terminée » -2. Copier **uniquement** la dernière ligne de succès de `npx hardhat compile` (pas de `.env`) -3. Confirmer : `.env.example` présent, `.env` **non** commité - -**Ne pas envoyer** la clé privée. - ---- - -## Après cette étape - -- **Étape 3** : supprimer `Lock.sol`, ajouter `FGC42Forge.sol` (supply 1 000 000, pas de mint, `Ownable`), tests. -- **Déploiement testnet** : plus tard, avec `npx hardhat run scripts/... --network bscTestnet`. - ---- - -## Références - -- [decisions-projet.md](../decisions-projet.md) — FGC42Forge / FG42 -- [guide-realisation.md](../guide-realisation.md) — étape 2 -- Sujet : dossier `code/` — [tokenizer.md](../../sujets/tokenizer.md#code-) diff --git a/docs/pedagogie/etapes/etape-04-deploy-testnet.md b/docs/pedagogie/etapes/etape-04-deploy-testnet.md deleted file mode 100644 index 04f0cff..0000000 --- a/docs/pedagogie/etapes/etape-04-deploy-testnet.md +++ /dev/null @@ -1,75 +0,0 @@ -# Étape 4 — Déployer sur BSC Testnet + dossier `deployment/` - -> **Prérequis :** étapes 1–3 ✅ (`FGC42Forge.sol`, tests Mocha OK, `bscTestnet` dans `hardhat.config.ts`, `.env` local). -> **Sujet :** déploiement sur **chaîne publique de test**, adresse + réseau dans le dépôt Git, explorer (BscScan). - ---- - -## Objectif - -Avoir le contrat **FGC42Forge** déployé sur **BNB Smart Chain Testnet** (chainId **97**), avec l’adresse documentée dans `tokenizerRendu/deployment/` et le README école. - ---- - -## 4.1 — Module Ignition (déjà dans le repo) - -Fichier : `tokenizerRendu/code/ignition/modules/FGC42Forge.ts` - -Il déclare uniquement `m.contract("FGC42Forge")` : pas d’arguments, le constructeur Solidity fait le mint. - -Vérifier la compile : - -```bash -cd tokenizerRendu/code -npx hardhat build -``` - ---- - -## 4.2 — Lancer le déploiement (à faire **toi-même**) - -```bash -cd tokenizerRendu/code -npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts -``` - -| Problème possible | Piste | -|-------------------|--------| -| `ENV_VAR_NOT_FOUND` / clé manquante | `code/.env` avec `PRIVATE_KEY` et `BSC_TESTNET_RPC` | -| `insufficient funds` | Recharger **tBNB** sur le compte deployer | -| Mauvais réseau | MetaMask pas requis ici ; Hardhat signe avec `PRIVATE_KEY` | - -**Ne pas** coller la clé privée dans le chat. - ---- - -## 4.3 — Enregistrer l’adresse - -1. `cp deployment/addresses.json.example deployment/addresses.json` -2. Remplir `address`, `deployer`, `deployedAt`, `explorer` (URL BscScan). -3. Mettre à jour `tokenizerRendu/README.md` (table Token). - ---- - -## 4.4 — Vérifier sur BscScan (sujet) - -- Ouvrir l’adresse sur https://testnet.bscscan.com/ -- Vérifier **nom / symbole** du token si l’explorer les affiche. -- Option **Verify and Publish** : publier le **code source** (fichier aplati ou standard JSON). - ---- - -## Livrable pour vérification (chat) - -1. « Étape 4 deploy OK » -2. Adresse du contrat `0x...` (publique) -3. Lien BscScan -4. Confirmation : `deployment/addresses.json` rempli, pas de secret commité - ---- - -## Références - -- [deployment/README.md](../../../tokenizerRendu/deployment/README.md) -- [decisions-projet.md](../decisions-projet.md) -- [sujet ch. IV](../../sujets/tokenizer.md) diff --git a/docs/pedagogie/fiche-soutenance-tokenizer.md b/docs/pedagogie/fiche-soutenance-tokenizer.md deleted file mode 100644 index ea6593c..0000000 --- a/docs/pedagogie/fiche-soutenance-tokenizer.md +++ /dev/null @@ -1,127 +0,0 @@ -# Fiche de soutenance — Tokenizer (FGC42Forge) - -> **Usage :** préparation orale + code review. Fichier **hors rendu** (`docs/pedagogie/`). -> **Grille sujet :** [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md) (PDF v1.1, ch. IV–VI). - ---- - -## 1. Pitch (30–45 s) - -- Projet **Tokenizer** : token **BEP-20** sur **BSC Testnet**, nom **FGC42Forge**, symbole **FG42**, supply **1 000 000** mintée une fois au déploiement. -- Stack : **Solidity** + **OpenZeppelin** (`ERC20`, `Ownable`) + **Hardhat 3** + **Ignition**. -- Déployé et vérifié sur **BscScan** ; démo **transfer** entre deux wallets test. -- Bonus **multisig** non retenu (priorité obligatoire + simplicité ownership). - ---- - -## 2. Carte du dépôt école (`tokenizerRendu/`) - -| Chemin | Rôle (sujet) | -|--------|----------------| -| `README.md` | Choix techniques + **pourquoi** + adresse + réseau + explorer | -| `code/` | Source commenté, tests, Hardhat | -| `code/contracts/FGC42Forge.sol` | Contrat token — **cœur code review** | -| `deployment/` | Adresses, flatten, guide vérif BscScan | -| `documentation/README.md` | **Utilisateur** : qu’est-ce que FG42, comment l’utiliser | - -**Ne pas montrer** au correcteur comme partie du rendu : `docs/`, `tokenizerRendu/../docs/pedagogie`. - ---- - -## 3. Chiffres à avoir en tête (sans lire l’écran) - -| Élément | Valeur | -|---------|--------| -| Réseau | BSC Testnet, **chainId 97** | -| Contrat | `0x0c76df26A1149fDc22C8f994975705271b070fF4` | -| Wallet déploiement / owner | `0xB6bE…603c` (FGC_account — avoir l’adresse complète sous les yeux) | -| Supply | 1 000 000 × 10¹⁸ unités (18 décimales OZ) | -| Tests | `npx hardhat test` — 2 tests FGC42Forge | - ---- - -## 4. Déroulé oral suggéré (~10–15 min selon école) - -| Étape | Contenu | Lien exigence sujet | -|-------|---------|---------------------| -| 1 | Contexte Web3 + BNB Chain testnet, pas d’argent réel | T4, T6 | -| 2 | README : pourquoi BSC, OZ, supply fixe, pas de mint public | T5, T12 | -| 3 | `documentation/` : cas d’usage, limites, import MetaMask | T17–T19 | -| 4 | BscScan : contrat vérifié, token, une tx `transfer` | T11, T15–T16 | -| 5 | Démo live ou replay : transfer 100 FG42 | T11 | -| 6 | **Code review** `FGC42Forge.sol` | T9–T10 | -| 7 | `deployment/` : comment reproduire le deploy (sans exposer clé) | T13–T14 | -| 8 | Bonus : pourquoi pas multisig | Ch. V (choix assumé) | - ---- - -## 5. Code review — points à expliquer ligne par ligne (conceptuel) - -1. **`import ERC20, Ownable`** — standard BEP-20 / ERC-20, pas de réinvention. -2. **Constructeur** : `_mint(msg.sender, …)` une fois → supply initiale ; `msg.sender` = deployer = owner. -3. **Pas de `mint()` public** — seul le design « supply fixe » ; owner ne mint pas après (à confirmer dans le fichier). -4. **`Ownable`** — qui peut `transferOwnership` ; pas de pause si non implémentée. -5. **Tests** : supply, transfer, éventuellement owner — preuve locale avant deploy. - -*(Relire le contrat la veille ; adapter cette liste au code exact.)* - ---- - -## 6. Sécurité (obligatoire sujet — réponses courtes) - -| Question évaluateur | Réponse type | -|---------------------|--------------| -| Qui peut créer des tokens après deploy ? | Personne ; supply fixée au constructeur. | -| Risque si clé owner compromise ? | Ownership OZ : transfert de propriété possible ; pas de mint dans notre design. | -| Pourquoi testnet ? | Sujet : pas d’argent réel ; faucet tBNB. | -| Pourquoi OpenZeppelin ? | Bibliothèque auditée, conformité ERC-20. | - ---- - -## 7. Stack, outils, alternatives (README « pourquoi ») - -| Choix | Pourquoi | Alternative citée au sujet | -|-------|----------|----------------------------| -| BSC Testnet | Partenaire BNB, BEP-20, faucet | Ethereum testnet + ERC-20 | -| Hardhat 3 | Tests, compile, Ignition | Remix, Truffle | -| Ignition | Deploy reproductible | Script deploy manuel | -| `.env` + `.env.example` | Clé hors Git | — | -| Flatten + BscScan | Lisibilité évaluateur | Optionnel mais fait | - ---- - -## 8. Commandes utiles (machine école) - -```bash -cd tokenizerRendu/code # Hardhat n’est pas à la racine tokenizerRendu/ -npm ci # ou npm install -cp .env.example .env # renseigner PRIVATE_KEY 64 hex — jamais commit -npx hardhat test --grep FGC42Forge -npx hardhat ignition deploy ignition/modules/FGC42Forge.ts --network bscTestnet -``` - ---- - -## 9. Git / Vogosphere (rappel) - -- **Racine du repo école** = contenu de `tokenizerRendu/` (souvent `git init` dans ce dossier ou branche dédiée). -- `.gitignore` : `.env`, `node_modules`, `cache`, `artifacts`. -- **Seul le dépôt poussé** compte (ch. VI). - ---- - -## 10. Auto-contrôle avant soutenance - -Repasser la colonne « Projet » dans [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md) (T1–T19). - -- [x] README rendu **autonome** (pas de lien vers `docs/pedagogie`) -- [x] `documentation/README.md` sans référence au dépôt perso `docs/` -- [x] Adresse + réseau visibles sans chercher -- [ ] Démo transfer reproductible (FGC_account → 2ᵉ compte ; voir checklist demo) -- [ ] 2 phrases sur ch. III (compétences acquises) - ---- - -## 11. Si on te demande « qu’est-ce qui manquerait pour le bonus ? » - -Multisig (ex. Gnosis Safe ou contrat custom) sur actions sensibles ; **m** signatures sur **n** signataires ; extension cohérente avec le token — **seulement** si obligatoire jugée parfaite. diff --git a/docs/pedagogie/guide-realisation.md b/docs/pedagogie/guide-realisation.md deleted file mode 100644 index f0398ec..0000000 --- a/docs/pedagogie/guide-realisation.md +++ /dev/null @@ -1,211 +0,0 @@ -# Guide de réalisation — Tokenizer - -> **Objectif :** document de travail pour **coder, déployer et défendre** le projet. À mettre à jour quand le code existe (chemins, commandes, adresses). -> **Référence sujet :** [tokenizer.md](../sujets/tokenizer.md) -> **Apprentissage :** [ressources-solidity-hardhat.md](ressources-solidity-hardhat.md) - ---- - -## Vue d’ensemble du livrable école - -| Élément | Emplacement | Contenu attendu | -|---------|-------------|-----------------| -| README | `tokenizerRendu/README.md` | Choix + **adresse contrat** + **réseau** | -| Source | `tokenizerRendu/code/` | Contrat(s) commentés | -| Déploiement | `tokenizerRendu/deployment/` | Scripts, config réseaux, sorties | -| Doc utilisateur | `tokenizerRendu/documentation/` | Usage du token, rôle, limites | -| Hors dépôt école | `docs/` (ici) | Traduction, pédagogie, ce guide | - ---- - -## Étape 1 — Cadrage (avant d’écrire du Solidity) - -### Checklist décisions - -- [ ] Chaîne : **BNB Smart Chain Testnet** (chainId `97`) — ou autre EVM **justifié** dans README -- [ ] Nom du token contenant **`42`** (ex. `FortyTwoToken`, `School42Coin`) -- [ ] Symbole ticker (ex. `FT42`) — affiché sur l’explorer après déploiement -- [ ] Supply initiale, décimales (souvent `18`), droit de **mint** ou supply fixe -- [ ] Modèle de ownership : `Ownable` OpenZeppelin recommandé pour la soutenance - -### Comptes et secrets - -1. Wallet de test (MetaMask ou autre) — **jamais** la clé privée du mainnet avec de vrais fonds. -2. Faucet : [BNB Chain Testnet Faucet](https://www.bnbchain.org/en/testnet-faucet) -3. Fichier `.env` dans `deployment/` ou racine `code/` : - -```env -PRIVATE_KEY=0x... # compte TEST uniquement -BSC_TESTNET_RPC=https://data-seed-prebsc-1-s1.binance.org:8545/ -``` - -Ajouter `.env` au `.gitignore` (déjà prévu dans le paquet rendu). - ---- - -## Étape 2 — Projet `code/` - -### Structure suggérée (Hardhat) - -``` -tokenizerRendu/code/ -├── package.json -├── hardhat.config.js -├── contracts/ -│ └── Token42.sol # nom à adapter -├── test/ -│ └── Token42.test.js -└── README.md # comment compiler / tester localement -``` - -### Contrat minimal (logique, pas le code final) - -1. Hériter **ERC20** + **Ownable** (OpenZeppelin). -2. Constructeur : `name`, `symbol`, supply initiale au déployeur ou `mint` réservé à `owner`. -3. Si `mint` : fonction `onlyOwner` — **à expliquer** en README (risque si owner compromis). -4. Commentaires en tête de fichier : rôle du token, réseau cible, standard BEP-20. - -### Tests locaux (fortement recommandés avant deploy) - -```bash -cd tokenizerRendu/code -npm install -npx hardhat test -``` - -Points à couvrir : `transfer`, solde, `onlyOwner` sur fonctions sensibles. - ---- - -## Étape 3 — Dossier `deployment/` - -### Contenu type - -``` -tokenizerRendu/deployment/ -├── README.md # ordre des commandes -├── deploy.js # ou scripts Hardhat dans code/ référencés ici -└── addresses.json # adresse + chainId + date (après deploy) -``` - -### Déploiement (exemple Hardhat) - -Depuis `code/` (selon ton organisation) : - -```bash -npx hardhat run scripts/deploy.js --network bscTestnet -``` - -Enregistrer dans `addresses.json` : - -```json -{ - "network": "bscTestnet", - "chainId": 97, - "contract": "Token42", - "address": "0x...", - "explorer": "https://testnet.bscscan.com/address/0x..." -} -``` - -### Vérification sur l’explorer - -- [BscScan Testnet](https://testnet.bscscan.com/) → **Verify and Publish** (flatten ou standard JSON input selon toolchain). -- Copier l’URL du contrat dans `tokenizerRendu/README.md`. - ---- - -## Étape 4 — `documentation/` (utilisateur) - -Sections recommandées (`documentation/README.md` ou plusieurs fichiers) : - -1. **Qu’est-ce que ce token ?** (cas d’usage fictif ou pédagogique) -2. **Réseau et adresse** (lien explorer) -3. **Ajouter le token dans un wallet** (contract address, decimals, symbol) -4. **Actions supportées** : transfer, approve, etc. -5. **Sécurité** : qui est owner, ce qu’il peut faire, ce que les utilisateurs ne peuvent pas faire -6. **Limites testnet** : pas de valeur réelle, reset possible des faucets - -Option : `documentation/WHITEPAPER.md` court (1–2 pages). - ---- - -## Étape 5 — README école (`tokenizerRendu/README.md`) - -Le sujet exige d’y expliquer les **choix** et **raisons**. Modèle : - -| Section | Contenu | -|---------|---------| -| Présentation | Nom, symbole, standard BEP-20 | -| Chaîne | BSC Testnet, chainId, pourquoi pas mainnet | -| Stack | Hardhat, OpenZeppelin, versions | -| Sécurité | Ownable, mint ou non, pas de backdoor cachée | -| Déploiement | Adresse + lien BscScan | -| Démo soutenance | 3–5 actions à montrer (voir ci-dessous) | -| Bonus | Si multisig : où est le code, comment tester | - -Mettre à jour le fichier réel dans `tokenizerRendu/` au fil du projet (le squelette actuel liste les sections à compléter). - ---- - -## Étape 6 — Scénario de soutenance (démo minimale) - -Préparer un **fil narratif** de 5–10 minutes : - -| # | Action | Preuve | -|---|--------|--------| -| 1 | Montrer le repo : `code/`, `deployment/`, `documentation/` | `ls` ou IDE | -| 2 | Expliquer ownership / privilèges sur le contrat | Code ouvert `Token42.sol` | -| 3 | Lire `name`, `symbol`, `totalSupply` sur l’explorer | BscScan | -| 4 | `transfer` entre deux comptes test | Explorer « Token transfers » ou wallet | -| 5 | Montrer qu’un non-owner **ne peut pas** mint (si applicable) | Transaction revert ou test Hardhat | -| 6 | Bonus multisig | Seulement si obligatoire parfaite | - -Pas de vidéo obligatoire ; si lien vidéo : une ligne dans README. - ---- - -## Étape 7 — Code review (ce que l’évaluateur peut demander) - -- Pourquoi OpenZeppelin plutôt qu’un ERC20 from scratch ? -- Où est le risque principal de ton design (owner, mint) ? -- Comment quelqu’un utilise ton token sans ton aide ? -- Différence entre ton `documentation/` et le README racine ? -- Confirmation : **aucune clé privée** dans Git ? - ---- - -## Étape 8 — Bonus multisig (après obligatoire parfaite) - -Pistes : - -- Contrat wallet multisig simple (m-of-n) qui détient l’ownership du token. -- Ou contrat qui exige N signatures pour `mint` / transfert sortant d’un trésor. - -Documenter dans `documentation/` et README : nombre de signataires, adresses de test, procédure de signature. - ---- - -## Dépannage (à enrichir pendant le dev) - -| Problème | Piste | -|----------|--------| -| Faucet vide / rate limit | Réessayer plus tard, autre compte test | -| Transaction underpriced | Ajuster gas sur BSC testnet | -| Verify échoue | Vérifier version compilateur et settings Hardhat | -| Token invisible dans wallet | Ajouter manuellement par adresse de contrat | - ---- - -## Cartographie sujet ↔ dossiers (rappel) - -| Exigence sujet | Dossier / fichier | -|----------------|-------------------| -| Code commenté | `code/` | -| Déploiement | `deployment/` | -| Doc projet token | `documentation/` | -| Choix + adresse + réseau | `README.md` racine rendu | -| Revue de code | `code/` | -| Démo sécurité | soutenance + éventuellement tests | - -→ État du projet : [00-reprise-et-etat.md](00-reprise-et-etat.md) diff --git a/docs/pedagogie/parcours-etape-par-etape.md b/docs/pedagogie/parcours-etape-par-etape.md deleted file mode 100644 index a8af219..0000000 --- a/docs/pedagogie/parcours-etape-par-etape.md +++ /dev/null @@ -1,33 +0,0 @@ -# Parcours guidé — Tokenizer (pas à pas) - -> **Mode de travail :** une **étape** à la fois → tu réalises → tu demandes **vérification** dans le chat → étape suivante. -> **Référence obligatoire :** [sujet traduit](../sujets/tokenizer.md) · PDF [tokenizer_subject.pdf](../sujets/originaux/tokenizer_subject.pdf). -> **Doc travail** = `docs/` (ce fichier, étapes, décisions). **Doc rendu** = `tokenizerRendu/documentation/` (évaluateurs, plus tard). - -## Règles - -| Règle | Détail | -|-------|--------| -| Sujet | Chaque étape cite les exigences du chapitre IV (et bonus seulement après obligatoire parfaite) | -| Secrets | Jamais de clé privée dans Git — `.env` local uniquement | -| Rendu école | On ne remplit `tokenizerRendu/README.md` (choix finaux) qu’aux étapes prévues ; la doc **pédagogique** vit ici | - -## Plan des étapes - -| # | Fichier guide | Objectif | Statut | -|---|---------------|----------|--------| -| **1** | [etapes/etape-01-cadrage-wallet-testnet.md](etapes/etape-01-cadrage-wallet-testnet.md) | Décisions token + BSC testnet + tBNB | ✅ **Validée** (0,1 tBNB Telegram) | -| **2** | [etapes/etape-02-init-hardhat.md](etapes/etape-02-init-hardhat.md) | Init Hardhat dans `tokenizerRendu/code/` | ✅ | -| **3** | *(contrat + tests)* | `FGC42Forge.sol` + tests Mocha | ✅ | -| **4** | [etapes/etape-04-deploy-testnet.md](etapes/etape-04-deploy-testnet.md) | Dossier `deployment/` + deploy + BscScan | ✅ | -| **5** | `tokenizerRendu/documentation/README.md` | Doc utilisateur + choix techniques README | ✅ | -| **6** | [checklist-demo-evaluation.md](checklist-demo-evaluation.md) | Démo + code commenté (`FGC42Forge.sol`, config, tests) | ✅ | -| **7** | — | Bonus multisig (optionnel) | ❌ Non retenu | - -## Fichier de suivi (travail) - -→ [decisions-projet.md](decisions-projet.md) — **tu le remplis** à l’étape 1 ; l’assistant s’en sert pour vérifier. - -## État global - -→ [00-reprise-et-etat.md](00-reprise-et-etat.md) diff --git a/docs/pedagogie/ressources-solidity-hardhat.md b/docs/pedagogie/ressources-solidity-hardhat.md deleted file mode 100644 index bc34f70..0000000 --- a/docs/pedagogie/ressources-solidity-hardhat.md +++ /dev/null @@ -1,163 +0,0 @@ -# Ressources — apprendre Solidity & Hardhat (Tokenizer) - -> Liens **officiels** et parcours suggérés pour le projet **FGC42Forge** (BEP-20, BSC Testnet, Hardhat). -> Priorité : comprendre ce que tu déploies, pas tout lire d’un coup. - ---- - -## Parcours suggéré (ordre) - -| Phase | Quand | Objectif | Section ci-dessous | -|-------|--------|----------|-------------------| -| **A** | Avant / pendant étape 2 | Solidity : types, fonctions, `constructor` | § 1 | -| **B** | Étapes 2–3 | Hardhat : compile, test, config réseau | § 2 | -| **C** | Étape 3 | ERC-20 / OpenZeppelin, `Ownable` | § 3 | -| **D** | Étape 4+ | Deploy, verify BscScan, gas | § 4 | -| **E** | Optionnel | Approfondir Web3 / BNB | § 5 | - -Croiser avec : [02-web3-comprendre.md](02-web3-comprendre.md) · [03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md) · [decisions-projet.md](decisions-projet.md). - ---- - -## 1. Solidity — bases - -### Documentation officielle (référence) - -| Ressource | URL | À utiliser pour | -|-----------|-----|-----------------| -| **Solidity docs** (EN, référence) | https://docs.soliditylang.org/ | Syntaxe, types, visibilité, modifiers, erreurs | -| **By example** (courts extraits) | https://docs.soliditylang.org/en/latest/by-example.html | `mapping`, `modifier`, `events` | -| **Structure d’un contrat** | https://docs.soliditylang.org/en/latest/structure-of-a-contract.html | `state variables`, `functions`, `constructor` | -| **Sécurité (patterns)** | https://docs.soliditylang.org/en/latest/security-considerations.html | Bonnes pratiques (soutenance) | - -### Chapitres utiles pour Tokenizer (lecture ciblée) - -| Chapitre / thème | Pourquoi pour FGC42Forge | -|------------------|---------------------------| -| **Types** (`uint256`, `address`) | Soldes, adresses owner / holders | -| **Fonctions** (`public`, `view`, `pure`) | `balanceOf`, `transfer` (via ERC20) | -| **`constructor`** | Mint initial de la supply au deploy | -| **`modifier`** | Comprendre `onlyOwner` (OpenZeppelin) | -| **`require` / revert** | Tests « non-owner ne peut pas mint » | -| **Héritage** | `contract FGC42Forge is ERC20, Ownable` | - -### Tutoriels / cours (gratuits) - -| Ressource | URL | Note | -|-----------|-----|------| -| **Ethereum.org — Solidity** | https://ethereum.org/fr/developers/docs/programming-languages/solidity/ | Point d’entrée FR, liens vers la doc | -| **Ethereum.org — smart contracts** | https://ethereum.org/fr/developers/docs/smart-contracts/ | Concepts avant le code | -| **CryptoZombies** (jeu, EN) | https://cryptozombies.io/ | Solidity ludique — chapitres 1–3 suffisent pour démarrer | -| **OpenZeppelin — Learn** | https://docs.openzeppelin.com/learn/ | Articles ERC-20, access control (EN) | - -### Vidéos (optionnel, EN souvent) - -Chercher sur YouTube : *「Solidity tutorial 2024」* + *「ERC20 OpenZeppelin」* — privilégier chaînes qui montrent **testnet**, pas mainnet avec argent réel. - ---- - -## 2. Hardhat — bases - -### Documentation officielle - -| Ressource | URL | À utiliser pour | -|-----------|-----|-----------------| -| **Hardhat — Getting started** | https://hardhat.org/hardhat-runner/docs/getting-started | Install, premier `compile` | -| **Configuration** | https://hardhat.org/hardhat-runner/docs/config | `networks.bscTestnet`, `solidity` version | -| **Testing contracts** | https://hardhat.org/hardhat-runner/docs/guides/test-contracts | Écrire tests étape 3 | -| **Deploying** | https://hardhat.org/hardhat-runner/docs/guides/deploying | Scripts → dossier `deployment/` | -| **Hardhat Network** | https://hardhat.org/hardhat-network/docs | `hardhat node` — tests sans tBNB | -| **Hardhat Toolbox** | https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-toolbox | Plugins inclus (`ethers`, verify, etc.) | - -### Tutoriels alignés BSC / testnet - -| Ressource | URL | Note | -|-----------|-----|------| -| **BNB Chain — dev docs** | https://docs.bnbchain.org/bnb-smart-chain/developers/ | Faucet, réseau, outils | -| **How to Create a BEP20 Token** (QuickNode) | https://www.quicknode.com/guides/smart-contract-development/how-to-create-and-deploy-a-bep-20-token | Proche du sujet Tokenizer (vérifie dates / versions) | -| **OpenZeppelin — ERC20 guide** | https://docs.openzeppelin.com/contracts/5.x/erc20 | Utilisation `ERC20` + `_mint` | - -### Commandes à connaître (fiche mémo) - -```bash -cd tokenizerRendu/code -npm install -npx hardhat compile # compile contracts/ -npx hardhat test # tests/ -npx hardhat node # chaîne locale (optionnel) -npx hardhat run scripts/deploy.js --network bscTestnet -``` - ---- - -## 3. ERC-20 / BEP-20 & OpenZeppelin (cœur du projet) - -| Ressource | URL | Contenu | -|-----------|-----|---------| -| **OpenZeppelin ERC20** | https://docs.openzeppelin.com/contracts/5.x/erc20 | API : `transfer`, `approve`, `_mint`, `_burn` | -| **OpenZeppelin Ownable** | https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable | `owner()`, `onlyOwner` | -| **EIP-20 (standard)** | https://eips.ethereum.org/EIPS/eip-20 | Spec originale (= logique BEP-20) | -| **Doc projet — BEP-20** | [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) | Lien sujet 42 + BSC | - -**Exercice mental :** lire la doc `ERC20` et lister quelles fonctions tu **exposes** dans FGC42Forge et lesquelles viennent **uniquement** du parent OpenZeppelin. - ---- - -## 4. Déploiement, explorer, verify - -| Ressource | URL | Contenu | -|-----------|-----|---------| -| **BscScan — verify** | https://testnet.bscscan.com/verifyContract | Publier le **code source** après deploy | -| **Hardhat — verify plugin** | https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-verify | `npx hardhat verify --network bscTestnet ` | -| **BNB — faucet** | https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/ | tBNB (tu as déjà utilisé Telegram) | -| **Guide réalisation** | [guide-realisation.md](guide-realisation.md) | Étapes deploy du dépôt perso | - ---- - -## 5. ethers.js (utilisé par Hardhat) - -| Ressource | URL | Contenu | -|-----------|-----|---------| -| **ethers v6 docs** | https://docs.ethers.org/v6/ | `Wallet`, `Contract`, `parseEther` | -| **Hardhat + ethers** | https://hardhat.org/hardhat-runner/docs/advanced/using-ethers | Dans tests et scripts deploy | - -Tu n’as pas besoin de tout maîtriser : savoir lire un script `deploy.js` qui fait `const Token = await ethers.getContractFactory("FGC42Forge")` suffit au début. - ---- - -## 6. Outils complémentaires (sujet les cite) - -| Outil | URL | Usage | -|-------|-----|--------| -| **Remix IDE** | https://remix.ethereum.org/ | Test rapide d’un `.sol` sans Hardhat | -| **Truffle docs** | https://archive.truffleframework.com/docs | Comparaison — [03-hardhat](03-hardhat-et-alternatives.md) | -| **Solidity VS Code** | Extension « Solidity » (Nomic Foundation) | Coloration, compilation locale | - ---- - -## 7. Fiches projet Tokenizer (doc interne) - -| Document | Lien | -|----------|------| -| Sujet traduit | [../sujets/tokenizer.md](../sujets/tokenizer.md) | -| Web3, RPC, mint, multisig | [02-web3-comprendre.md](02-web3-comprendre.md) | -| Hardhat vs alternatives | [03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md) | -| Étapes pas à pas | [parcours-etape-par-etape.md](parcours-etape-par-etape.md) | -| Étape 2 Hardhat | [etapes/etape-02-init-hardhat.md](etapes/etape-02-init-hardhat.md) | - ---- - -## 8. Plan de lecture « minimum » avant l’étape 3 - -Si tu manques de temps, lire au moins : - -1. [Solidity — Simple Storage](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) (intro officielle) -2. [OpenZeppelin ERC20 — Usage](https://docs.openzeppelin.com/contracts/5.x/erc20#usage) -3. [Hardhat — Getting started](https://hardhat.org/hardhat-runner/docs/getting-started) jusqu’au premier `compile` -4. [02-web3 § 7.2](02-web3-comprendre.md#72-glossaire-anglais--supply-owner-ownable-onlyowner) (supply, owner, onlyOwner) - -Ensuite : coder `FGC42Forge.sol` avec le guide étape 3 (à venir après validation étape 2). - ---- - -*Dernière mise à jour : liens vérifiés oct. 2026 — signaler dans le chat si un lien est mort pour mise à jour.* diff --git a/docs/pedagogie/sujet-exigences-rendu.md b/docs/pedagogie/sujet-exigences-rendu.md deleted file mode 100644 index d17d0f4..0000000 --- a/docs/pedagogie/sujet-exigences-rendu.md +++ /dev/null @@ -1,122 +0,0 @@ -# Exigences du sujet Tokenizer (v1.1) — grille de conformité rendu - -> Source officielle : [`docs/sujets/originaux/tokenizer_subject.pdf`](../sujets/originaux/tokenizer_subject.pdf) -> Traduction structurée : [`docs/sujets/tokenizer.md`](../sujets/tokenizer.md) -> **Dépôt évalué** : racine Vogosphere = contenu de **`tokenizerRendu/`** (pas le dépôt de travail `tokenizer/` avec `docs/`). - ---- - -## Chapitre VI — Règle d’or - -| Règle | Implication | -|-------|-------------| -| Dépôt Git habituel | Push sur Vogosphere ; **seul le contenu du dépôt** est noté | -| Noms dossiers / fichiers | Respecter l’exemple ou un nom **explicite** justifiable à l’oral | -| Git perso `#web3` | **Recommandé en plus**, pas en remplacement du rendu école | - ---- - -## Arborescence obligatoire (PDF p.7) - -``` -README.md ← racine du dépôt ÉCOLE -code/ -deployment/ ← nom d’exemple ; autre nom OK si clair en soutenance -documentation/ -``` - -**Hors sujet dans le rendu :** dossier `docs/` perso, PDF sujet traduit, checklist perso — à garder dans le dépôt de **travail** uniquement. - ---- - -## Tableau des exigences — partie obligatoire (ch. IV) - -| # | Exigence (sujet) | Critère de validation | Projet FGC42Forge | -|---|------------------|----------------------|-------------------| -| **T1** | Nom du token contient **`42`** | `name()` on-chain ou nom documenté | ✅ `FGC42Forge` | -| **T2** | Pas d’insultes dans le nom | — | ✅ | -| **T3** | Standard de la chaîne | BEP-20 si BSC | ✅ OpenZeppelin ERC20 sur BSC Testnet | -| **T4** | **Pas d’argent réel** | Testnet + doc | ✅ tBNB, pas de mainnet requis | -| **T5** | **`README.md` racine** : choix + **pourquoi** | Section explicite technologies / chaîne / modèle | ✅ `tokenizerRendu/README.md` (choix techniques) | -| **T6** | Blockchain qui supporte les tokens | EVM / smart contracts | ✅ BNB Smart Chain | -| **T7** | Maîtrise langage + toolchain | Solidity + Hardhat (ou équivalent cité) | ✅ Solidity 0.8.34 + Hardhat 3 | -| **T8** | Dossier **`code/`** à la racine | Présent | ✅ | -| **T9** | Code **commenté**, noms **lisibles** | Revue en eval | ✅ `FGC42Forge.sol` + index `code/README.md` | -| **T10** | **Code review** en soutenance | Savoir expliquer le contrat | À préparer (fiche soutenance) | -| **T11** | **Démo minimale** : token fonctionne | `name`, `symbol`, `totalSupply`, `transfer` ; explorer | ✅ tests + MetaMask + BscScan | -| **T12** | **Sécurité** : ownership, privilèges | Expliquer owner, mint, pause, etc. | ✅ Ownable, pas de mint public ; à verbaliser | -| **T13** | Dossier **`deployment/`** (ou équivalent) | Scripts / infos deploy | ✅ | -| **T14** | Deploy **blockchain publique** | Testnet public OK | ✅ BSC Testnet | -| **T15** | **Ticker** + contrat sur **explorateur** | Symbole + adresse visible | ✅ FG42 + BscScan | -| **T16** | Git : **adresse contrat** + **réseau** | README ou deployment | ✅ README + `addresses.json` | -| **T17** | Dossier **`documentation/`** | Comprendre + **utiliser** le token | ✅ | -| **T18** | Doc **claire**, relue en eval | Guide utilisateur autonome | ✅ `documentation/README.md` + stack | -| **T19** | Whitepaper léger (envisagé) | Rôle, limites — pas toujours fichier séparé | ✅ `documentation/README.md` § 5 | - ---- - -## Ce qui n’est **pas** obligatoire (éviter de sur-investir) - -| Élément | Sujet | -|---------|--------| -| **Vidéo démo** | Optionnelle ; **ne change pas la note** ; lien seulement si faite | -| **Bonus multisig** | Ch. V ; **non noté** si obligatoire imparfaite ; tu as **abandonné** → OK | -| **Mint public en démo** | « Éventuellement mint **si prévu** » — pas requis si supply fixe documentée | -| **Vérification BscScan** | Non écrit mot pour mot ; **fortement recommandé** (preuve + code review) — ✅ fait | -| **NFT / ERC-721** | Hors token fongible type 20 | -| **Compte Binance** | Non requis ; wallet + faucet suffisent | - ---- - -## Chapitre V — Bonus (référence) - -| Règle | Conséquence | -|-------|-------------| -| Multisig (contrat ou extension) | Seuils m-of-n, qui signe | -| Obligatoire **PARFAITE** | Sinon bonus ignoré | - -**Ton choix :** bonus non implémenté — indiqué dans `tokenizerRendu/README.md`. - ---- - -## Objectifs pédagogiques (ch. III) — à mentionner à l’oral - -- Maîtrise d’**au moins un langage** chaîne (Solidity). -- Familiarité **blockchain publique** (réseau, explorer, adresses, txs). -- Capacité d’**adaptation** (apprentissage Web3). - ---- - -## Erreurs fréquentes à éviter (checklist anti-échec) - -| Erreur | Risque | -|--------|--------| -| Dépôt racine = `tokenizer/` avec `docs/` au lieu de `tokenizerRendu/` seul | Structure hors sujet | -| Pas d’adresse / réseau dans Git | T16 manquant | -| `documentation/` = copie de la doc dev ou liens vers `docs/pedagogie` | Évaluateur perdu ; fuite hors rendu | -| Clé privée / `.env` commité | Sécurité + disqualification possible | -| Nom sans `42` | T1 | -| Mainnet / vrai BNB obligatoire | T4 | -| Token non déployé sur chaîne publique | T14 | -| Code non commenté / illisible en review | T9–T10 | -| README sans **pourquoi** (liste d’outils seule) | T5 | -| Compter sur la vidéo pour la note | Inutile pour la note | -| Présenter le bonus sans obligatoire parfaite | Règle ch. V | - ---- - -## Démo minimale — script aligné sujet (ch. IV + éclaircissements) - -1. **Explorer** : adresse contrat + page **token** (symbole, supply). -2. **Lecture** : `name`, `symbol`, `totalSupply` (BscScan ou wallet). -3. **`transfer`** entre deux comptes test (MetaMask). -4. **Sécurité** : qui est `owner` ; **pas** de mint après deploy ; pas de privilèges cachés. -5. **`documentation/`** : montrer qu’un tiers peut importer FG42 et transférer. -6. **`code/`** : ouvrir `FGC42Forge.sol` (revue de code courte). - ---- - -## Prochaine étape doc perso - -→ Fiche de soutenance : [`fiche-soutenance-tokenizer.md`](fiche-soutenance-tokenizer.md) -→ Audit rendu avant push : [`audit-rendu-tokenizer.md`](audit-rendu-tokenizer.md) diff --git a/docs/sujets/README.md b/docs/sujets/README.md deleted file mode 100644 index 35136e7..0000000 --- a/docs/sujets/README.md +++ /dev/null @@ -1,9 +0,0 @@ -# Sujets — Tokenizer - -| Document | Description | -|----------|-------------| -| [tokenizer.md](tokenizer.md) | Traduction FR complète (v1.1) + interprétation des visuels | -| [originaux/tokenizer_subject.pdf](originaux/tokenizer_subject.pdf) | PDF officiel Intra | -| [captures/](captures/) | Pages extraites du PDF (`page-01.png` … `page-10.png`) | - -Copie locale à la racine du dépôt de travail : `tokenizer.pdf` (optionnel, doublon du PDF dans `originaux/`). diff --git a/docs/sujets/captures/page-01.png b/docs/sujets/captures/page-01.png deleted file mode 100644 index 6d5c307..0000000 Binary files a/docs/sujets/captures/page-01.png and /dev/null differ diff --git a/docs/sujets/captures/page-02.png b/docs/sujets/captures/page-02.png deleted file mode 100644 index 687430d..0000000 Binary files a/docs/sujets/captures/page-02.png and /dev/null differ diff --git a/docs/sujets/captures/page-03.png b/docs/sujets/captures/page-03.png deleted file mode 100644 index c976eda..0000000 Binary files a/docs/sujets/captures/page-03.png and /dev/null differ diff --git a/docs/sujets/captures/page-04.png b/docs/sujets/captures/page-04.png deleted file mode 100644 index 2f5ef55..0000000 Binary files a/docs/sujets/captures/page-04.png and /dev/null differ diff --git a/docs/sujets/captures/page-05.png b/docs/sujets/captures/page-05.png deleted file mode 100644 index 048f673..0000000 Binary files a/docs/sujets/captures/page-05.png and /dev/null differ diff --git a/docs/sujets/captures/page-06.png b/docs/sujets/captures/page-06.png deleted file mode 100644 index 0ce923a..0000000 Binary files a/docs/sujets/captures/page-06.png and /dev/null differ diff --git a/docs/sujets/captures/page-07.png b/docs/sujets/captures/page-07.png deleted file mode 100644 index d476f75..0000000 Binary files a/docs/sujets/captures/page-07.png and /dev/null differ diff --git a/docs/sujets/captures/page-08.png b/docs/sujets/captures/page-08.png deleted file mode 100644 index c9da0e6..0000000 Binary files a/docs/sujets/captures/page-08.png and /dev/null differ diff --git a/docs/sujets/captures/page-09.png b/docs/sujets/captures/page-09.png deleted file mode 100644 index 8c5a7fb..0000000 Binary files a/docs/sujets/captures/page-09.png and /dev/null differ diff --git a/docs/sujets/captures/page-10.png b/docs/sujets/captures/page-10.png deleted file mode 100644 index b57c764..0000000 Binary files a/docs/sujets/captures/page-10.png and /dev/null differ diff --git a/docs/sujets/originaux/tokenizer_subject.pdf b/docs/sujets/originaux/tokenizer_subject.pdf deleted file mode 100644 index 1c53888..0000000 Binary files a/docs/sujets/originaux/tokenizer_subject.pdf and /dev/null differ diff --git a/docs/sujets/tokenizer.md b/docs/sujets/tokenizer.md deleted file mode 100644 index a8420f4..0000000 --- a/docs/sujets/tokenizer.md +++ /dev/null @@ -1,273 +0,0 @@ -# Tokenizer — Build your own token - -> **Version :** 1.1 -> **Résumé :** Exercice lié au **Web3**. -> **Traduction française** — source : [tokenizer_subject.pdf](originaux/tokenizer_subject.pdf) - ---- - -## Table des matières - -1. [Chapitre I — Avant-propos](#chapitre-i--avant-propos) -2. [Chapitre II — Introduction](#chapitre-ii--introduction) -3. [Chapitre III — Objectifs](#chapitre-iii--objectifs) -4. [Chapitre IV — Partie obligatoire](#chapitre-iv--partie-obligatoire) -5. [Chapitre V — Bonus](#chapitre-v--bonus) -6. [Chapitre VI — Rendu et évaluation par les pairs](#chapitre-vi--rendu-et-évaluation-par-les-pairs) -7. [Éléments visuels du PDF](#éléments-visuels-du-pdf) -8. [Éclaircissements (lecture facilitée)](#éclaircissements-lecture-facilitée) - ---- - -## Page de garde (PDF page 1) - -| Champ | Texte officiel (EN) | Traduction | -|-------|---------------------|------------| -| Titre | Tokenizer | Tokenizer | -| Sous-titre | Build your own token | Construis ton propre token | -| Résumé | This document is a Web3 related exercise. | Ce document est un exercice lié au **Web3** → voir [définition détaillée](../pedagogie/02-web3-comprendre.md). | -| Version | 1.1 | 1.1 | - -### Référence visuelle — couverture - -![Page de garde](captures/page-01.png) - -| Zone | Description | -|------|-------------| -| Illustration centrale | Motif vertical en facettes (style low-poly), tons gris/noir — **élément graphique 42**, pas une maquette de smart contract | -| Fond | Motif géométrique léger (triangles) sur toutes les pages | -| En-têtes | « Tokenizer » à gauche, « Build your own token » à droite | - ---- - -## Chapitre I — Avant-propos - -Ce sujet est réalisé en **partenariat entre 42 et BNB Chain**. - -**BNB Chain** (*Build N Build*) est un réseau blockchain distribué sur lequel développeurs et innovateurs peuvent construire des **applications décentralisées (DApps)** dans la mouvance **Web3**. - -En octobre 2022 (chiffres du sujet), BNB Chain était parmi les plus grands réseaux de smart contracts au monde en volume de transactions et utilisateurs actifs quotidiens : plus de 3 milliards de transactions, 232 millions d’adresses uniques, plus de 1 500 DApps actives. La nature **décentralisée** du réseau permet de déployer un produit **sans permission** centrale et d’atteindre un large public. - -### Faucet (testnet) - -Tu peux obtenir des **tBNB** (BNB de **test**, sans argent réel) via le faucet officiel : - -- [BNB Chain Faucet](https://www.bnbchain.org/en/testnet-faucet) (lien cité dans le sujet : *BNB Chain Faucet*) - -### BNB, Binance et BNB Chain - -Le sigle **BNB** désigne à la fois l’**écosystème blockchain** du sujet (**BNB Chain**, *Build N Build*) et la **monnaie native** utilisée pour payer le **gas**. Sur testnet, on utilise **tBNB** (sans valeur réelle). - -**Rapport avec Binance :** oui, **historiquement** — Binance a lancé et porté cet écosystème (l’actif s’appelait souvent *Binance Coin* ; la chaîne s’appelait **Binance Smart Chain**, **BSC**). Aujourd’hui la communication officielle parle surtout de **BNB Chain** comme réseau pour développeurs et DApps. Ce n’est **pas** le même produit que l’application d’**échange** Binance : pour Tokenizer, tu n’as en principe **pas besoin** d’un compte Binance — wallet + **testnet** + faucet suffisent. - -| Terme | En bref | -|-------|---------| -| **Binance** | Exchange centralisé (entreprise) | -| **BNB Chain / BSC** | Blockchain smart contracts (ton déploiement) | -| **BEP-20** | Standard de **ton** token sur cette chaîne | -| **BscScan (testnet)** | Explorateur pour prouver le contrat déployé | - -→ Développement détaillé : [section 10 — BNB, BNB Chain et Binance](../pedagogie/02-web3-comprendre.md#10-bnb-bnb-chain-et-binance-partenaire-du-sujet). - -### Référence visuelle — Figure I.1 (PDF page 2) - -![Chapitre I — BNB Chain](captures/page-03.png) - -| Zone | Description | -|------|-------------| -| Logo | Hexagone jaune + mention **BNB CHAIN** | -| Légende | *Figure I.1: https://www.bnbchain.org/* — site officiel de l’écosystème | -| Message implicite | Le partenaire du sujet pousse vers l’écosystème **BSC / BNB** ; le standard token y est **BEP-20** (équivalent fonctionnel d’**ERC-20** sur Ethereum) | - ---- - -## Chapitre II — Introduction - -Bienvenue dans le monde de la **technologie blockchain**. - -Tu vas pouvoir **créer ton propre token numérique**. La blockchain permet de créer et distribuer des actifs numériques uniques (**tokens**) : monnaie, parts, représentation d’œuvres, ou lien avec un actif du monde réel (selon le design que tu documentes). - -Ce n’est pas trivial : il faut comprendre ce que tu déploies. Avec les bonnes ressources (testnet, faucet, outils), c’est un projet formateur et concret. - -### Référence visuelle (PDF page 3) - -![Introduction — illustration token / puce](captures/page-04.png) - -| Zone | Description | -|------|-------------| -| Illustration | Style « peinture numérique » : **jeton doré** sur une base type **puce / circuit** | -| Sens | Métaphore **hardware + actif numérique** — le token est un programme (smart contract) exécuté par le réseau, pas un simple fichier | - ---- - -## Chapitre III — Objectifs - -En participant à ce projet, tu contribues à la création d’un **actif numérique on-chain**. Le sujet te challenge sur : - -- la maîtrise d’**au moins un langage** lié à ta chaîne (ex. **Solidity** pour BSC/ETH) ; -- la familiarité avec une **blockchain publique** (réseau, explorer, adresses, transactions) ; -- l’**adaptation** : pas besoin d’être cryptographe expert au départ, mais tu dois apprendre en chemin. - -Objectif final : compétences utiles + participation à un écosystème innovant (Web3). - -### Référence visuelle (PDF page 4) - -![Objectifs](captures/page-05.png) - -| Zone | Description | -|------|-------------| -| Illustration | Jetons / pièces stylisées — rappel que le livrable est un **token** avec règles économiques et techniques définies par **toi** (dans les contraintes du sujet) | - ---- - -## Chapitre IV — Partie obligatoire - -Pour créer un token, plusieurs exigences techniques et organisationnelles s’appliquent. - -### Contraintes sur le token - -| Règle | Détail | -|-------|--------| -| **Nom** | Libre, mais le nom doit contenir **`42`** | -| **Insultes** | Interdites — sanctions école | -| **README racine** | Fichier **`README.md`** à la racine du dépôt **école** : expliquer tes **choix** et **pourquoi** | -| **Standard** | Respecter le standard de la chaîne (**ERC-20** sur Ethereum, **BEP-20** sur BSC, etc.) — voir [§ ERC-20 / BEP-20](#erc-20-et-bep-20-éclaircissement) | -| **Argent réel** | **Jamais** demandé — utiliser des **chaînes de test** | - -### ERC-20 et BEP-20 (éclaircissement) - -**ERC-20** (Ethereum) et **BEP-20** (BNB Chain / BSC) définissent la même famille de **tokens fongibles** : `balanceOf`, `transfer`, `approve`, `totalSupply`, etc. Sur BSC, le code Solidity est en pratique le même qu’un ERC-20 (souvent bibliothèque **OpenZeppelin `ERC20`**) ; l’explorateur (**BscScan**) parle de **BEP-20** parce que la chaîne est BNB, pas parce que tu réécris une norme différente. - -| Question | Réponse | -|----------|---------| -| BEP-20 obligatoire pour tout le monde ? | **Non** — obligatoire **si** tu choisis **BSC / BNB Chain**. Sur Ethereum testnet → **ERC-20**. | -| Piste la plus alignée avec le PDF ? | **BSC Testnet** + **BEP-20** (tBNB, partenariat BNB). | -| NFT / autre standard ? | Hors sujet type « token classique » ; rester sur le **20** fongible. | - -→ Détail : [Standards ERC-20 et BEP-20](../pedagogie/02-web3-comprendre.md#6-standards-erc-20-et-bep-20). - -### Plateforme et outils - -1. Choisir une blockchain qui supporte la création de tokens. -2. Maîtriser le langage et la toolchain de cette chaîne : **IDE**, **Remix**, **Hardhat**, **Truffle**, etc. - -### Code (`code/`) - -- Dossier **`code/`** à la **racine** du dépôt école. -- Code **commenté**, noms de variables et fonctions **lisibles**. -- En soutenance : **revue de code** (*code review*). - -### Démonstration et sécurité - -Tu dois pouvoir faire des **actions minimales** qui prouvent que le token fonctionne. - -Réfléchir explicitement à la **sécurité** : **propriété** (*ownership*), **privilèges** (qui peut mint, pause, transférer des rôles, etc.). - -### Déploiement (2ᵉ dossier) - -- Tout le nécessaire au **déploiement** dans un **second dossier** à la racine — le sujet donne l’exemple **`deployment/`** (nom libre mais structure claire attendue). -- Déployer sur une **blockchain publique** (en pratique : **testnet public** pour ne pas dépenser de vrai argent). -- Définir le **ticker** (symbole, ex. `TK42`) et **publier** le contrat sur un **explorateur** (ex. **BscScan**, **Blockscan** selon la chaîne). -- Dans le dépôt Git : indiquer l’**adresse du smart contract** et le **réseau** utilisé. - -### Documentation (`documentation/`) - -- Dossier **`documentation/`** à la racine du dépôt école. -- On doit comprendre **comment ça marche** et **comment utiliser** le token. -- Envisager un contenu type **whitepaper** léger : rôle du token, fonctionnalités, limites. -- La doc sera **relue en évaluation** — claire et explicite. - -### Vidéo démo (optionnelle) - -- Pas obligatoire ; **ne améliore pas la note**. -- Si tu en fais une : **lien** dans le README suffit (pas besoin de pousser la vidéo dans Git). - -### Encadrés d’avertissement (PDF pages 5–7) - -![Partie obligatoire — extraits](captures/page-06.png) - -| Encadré | Message | -|---------|---------| -| Rose / ⚠️ | **Revue de code** pendant l’évaluation | -| Rose / ⚠️ | Documentation **claire** — relue en eval | -| Bleu / ℹ️ | Vidéo : **lien** seulement, pas le fichier dans le repo | -| Rose / ⚠️ | Vidéo **non requise**, pas de bonus de note | - -### Arborescence attendue (exemple officiel, PDF page 7) - -![Structure du dépôt](captures/page-08.png) - -``` -README.md -code/ -deployment/ # nom d’exemple ; un autre nom explicite est possible si le sujet l’accepte en soutenance -documentation/ -``` - -→ Dans ce dépôt perso, le paquet école est préparé dans [`../../tokenizerRendu/`](../../tokenizerRendu/). - ---- - -## Chapitre V — Bonus - -Pour renforcer la sécurité (ex. transactions sensibles), tu peux implémenter un **multisig** (*multisignature*) : plusieurs signataires doivent approuver une action avant exécution. - -- Smart contract dédié ou extension adaptée à **ta** partie obligatoire. -- Définir le **nombre de signatures** et **qui** peut signer. - -### ⚠️ Règle bonus - -Le bonus n’est évalué **que si la partie obligatoire est PARFAITE** (intégrale, sans dysfonctionnement). Une seule exigence obligatoire manquante → **bonus non évalué**. - -![Bonus multisig](captures/page-09.png) - ---- - -## Chapitre VI — Rendu et évaluation par les pairs - -Dépôt Git habituel. **Seul le contenu du dépôt** est évalué. Vérifier **noms de dossiers et fichiers**. - -Exception : le sujet **recommande** de partager le projet sur un **compte Git personnel** une fois valide (hashtags `#web3`, langage, etc.) — **en plus** du rendu Vogosphere, pas en remplacement. - -![Rendu](captures/page-10.png) - ---- - -## Éléments visuels du PDF - -| Page PDF | Fichier | Contenu visuel | -|----------|---------|----------------| -| 1 | [page-01.png](captures/page-01.png) | Couverture | -| 2 | [page-03.png](captures/page-03.png) | Texte BNB + logo Figure I.1 | -| 3 | [page-04.png](captures/page-04.png) | Introduction + illustration token | -| 4 | [page-05.png](captures/page-05.png) | Objectifs + illustration | -| 5–6 | [page-06.png](captures/page-06.png), [page-07.png](captures/page-07.png) | Partie obligatoire, encadrés | -| 7 | [page-08.png](captures/page-08.png) | Exemple `ls -al` | -| 8 | [page-09.png](captures/page-09.png) | Bonus | -| 9 | [page-10.png](captures/page-10.png) | Soumission | - -*(La page PDF « Contents » / table des matières correspond visuellement à [page-02.png](captures/page-02.png).)* - ---- - -## Éclaircissements (lecture facilitée) - -Ces points ne sont pas toujours explicites dans le PDF ; ils servent de fil conducteur pour le [guide de réalisation](../pedagogie/guide-realisation.md). - -| Terme | En bref | -|-------|---------| -| **Token** | Contrat intelligent qui suit une norme (souvent **20** : solde, `transfer`, `approve`, etc.) | -| **BEP-20 / ERC-20** | Normes tokens fongibles (BSC vs Ethereum) — [§ détaillé](#erc-20-et-bep-20-éclaircissement) · [doc Web3 §6](../pedagogie/02-web3-comprendre.md#6-standards-erc-20-et-bep-20) | -| **Déploiement** | Transaction qui enregistre le bytecode du contrat sur la chaîne → **adresse** unique | -| **tBNB** | Monnaie native de **test** pour payer le gas sur BNB Smart Chain testnet | -| **Ownership** | Souvent `Ownable` (OpenZeppelin) : qui peut `mint`, changer des paramètres, etc. | -| **Démo minimale** | Ex. : lire `name`, `symbol`, `totalSupply` ; `transfer` ; éventuellement `mint` si prévu — montrable sur explorer + script ou Remix | -| **3 dossiers** | `code` = source ; `deployment` = scripts, config réseau, adresses déployées ; `documentation` = guide **utilisateur** du token (distinct de `docs/` du dépôt perso) | - -**Chaîne recommandée (alignée partenaire sujet)** : **BNB Smart Chain Testnet** + Solidity + BEP-20. Autre chaîne EVM possible si tu justifies en README et respectes le standard équivalent. - ---- - -## Prochaine étape - -→ [Plan de réalisation](../pedagogie/README.md) · [Apports pédagogiques](../pedagogie/01-apports-pedagogiques.md) diff --git a/tokenizer.pdf b/tokenizer.pdf deleted file mode 100644 index 1c53888..0000000 Binary files a/tokenizer.pdf and /dev/null differ