diff --git a/README.md b/README.md index 32bb56f..cc911a4 100644 --- a/README.md +++ b/README.md @@ -53,5 +53,5 @@ Correcteurs et soutenance : **[tokenizerRendu/README.md](tokenizerRendu/README.m 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 [guide-realisation.md](docs/pedagogie/guide-realisation.md) et le [plan](docs/pedagogie/README.md). +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 index 6b5f245..c2c2f05 100644 --- a/docs/README.md +++ b/docs/README.md @@ -19,6 +19,7 @@ Documentation du projet, sur le modèle de [piscine_mobile/docs](../../piscine_m | **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) | | **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) diff --git a/docs/pedagogie/00-reprise-et-etat.md b/docs/pedagogie/00-reprise-et-etat.md index c67c707..761c832 100644 --- a/docs/pedagogie/00-reprise-et-etat.md +++ b/docs/pedagogie/00-reprise-et-etat.md @@ -1,14 +1,15 @@ # Reprise du projet — où nous en sommes -> Dernière mise à jour : initialisation documentation et squelette de rendu. +> Dernière mise à jour : démarrage parcours guidé — **étape 1 en cours**. ## En bref | | | |---|---| | **Fait** | Dépôt de travail, sujet FR v1.1, captures PDF, plan pédagogique, paquet `tokenizerRendu/` | -| **À faire** | Smart contract, déploiement testnet, doc utilisateur, README école complété | -| **Prochaine action** | Lire [guide-realisation.md](guide-realisation.md) étape 1 — figer chaîne + nom du token | +| **En cours** | **[Étape 1](etapes/etape-01-cadrage-wallet-testnet.md)** — cadrage + wallet testnet + `decisions-projet.md` | +| **À faire** | Étapes 2→6 (code, deploy, doc rendu, démo) ; bonus 7 optionnel | +| **Prochaine action** | Toi : compléter l’étape 1 puis demander **vérification** dans le chat | ## Arborescence actuelle @@ -26,7 +27,11 @@ tokenizer/ ← dépôt Git de TRAVAIL (perso) │ └── pedagogie/ │ ├── README.md │ ├── 00-reprise-et-etat.md ← ce fichier +│ ├── parcours-etape-par-etape.md +│ ├── decisions-projet.md ← suivi étape 1+ (travail) +│ ├── etapes/etape-01-…md │ ├── 01-apports-pedagogiques.md +│ ├── 02-web3-comprendre.md │ └── guide-realisation.md └── tokenizerRendu/ ← futur dépôt ÉCOLE (racine Vogosphere) ├── README.md @@ -42,20 +47,23 @@ tokenizer/ ← dépôt Git de TRAVAIL (perso) | Chaîne | BSC testnet, Sepolia, autre EVM | **BSC testnet** (partenariat BNB, faucet tBNB) | | Toolchain | Hardhat, Foundry, Remix seul | **Hardhat** pour scripts reproductibles dans `deployment/` | | Lib | OpenZeppelin ERC20 → BEP-20 | **OpenZeppelin** pour ownership et standard éprouvé | -| Nom / symbole | Doit contenir `42` | Ex. nom `Token42School`, symbole `TK42` — à valider perso | +| Nom / symbole | Doit contenir `42` | **`FGC42Forge`** / **`FG42`** — voir [decisions-projet.md](decisions-projet.md) | | Bonus multisig | Gnosis Safe, contrat custom | Seulement après obligatoire **parfaite** | -## Avancement par étape +## Avancement par étape (parcours guidé) + +→ Détail : [parcours-etape-par-etape.md](parcours-etape-par-etape.md) | Étape | Contenu | Statut | |-------|---------|--------| | **0** | Structure, traduction, séparation travail / école | ✅ **Terminé** | -| **1** | Choix stack + init projet dans `code/` | ⏳ | -| **2** | Contrat token + tests locaux | ⏳ | -| **3** | Déploiement + verify + adresse dans README | ⏳ | -| **4** | `documentation/` + démo soutenance | ⏳ | -| **5** | Rendu Vogosphere + partage Git perso (recommandé) | ⏳ | -| **6** | Bonus multisig | ⏳ | +| **1** | Cadrage + wallet + tBNB + `decisions-projet.md` | 🔄 **En cours** | +| **2** | Init Hardhat dans `tokenizerRendu/code/` | ⏳ | +| **3** | Contrat BEP-20 + tests | ⏳ | +| **4** | `deployment/` + deploy testnet + BscScan | ⏳ | +| **5** | `tokenizerRendu/documentation/` + README école | ⏳ | +| **6** | Démo + code review (préparation soutenance) | ⏳ | +| **7** | Bonus multisig | ⏳ | ## Reprendre le travail (checklist) diff --git a/docs/pedagogie/02-web3-comprendre.md b/docs/pedagogie/02-web3-comprendre.md index 7903a3f..d160910 100644 --- a/docs/pedagogie/02-web3-comprendre.md +++ b/docs/pedagogie/02-web3-comprendre.md @@ -43,7 +43,7 @@ Plusieurs machines (nœuds) maintiennent une **copie** (ou une vue) du même reg ### 3.2 Blockchain -Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). Consensus (PoS, PoA, etc.) définit qui peut proposer le bloc suivant. +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. @@ -55,9 +55,19 @@ Programme déployé à une **adresse** sur la chaîne. Une fois publié, son cod ### 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**. +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) @@ -82,6 +92,31 @@ Frais payés dans la **monnaie native** de la chaîne (BNB sur BSC, ETH sur Ethe 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 @@ -109,10 +144,7 @@ flowchart LR RPC[Réseau RPC] Chain[Blockchain publique] SC[Smart contract Token BEP-20] - Explorer[Explorateur BscScan] - end - User --> Browser - User --> Wallet + Explorer[Explorateur BscScan]source ~/.bashrc Wallet --> RPC RPC --> Chain Chain --> SC @@ -125,13 +157,128 @@ flowchart LR 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 : pourquoi BEP-20 / ERC-20 ? +## 6. Standards : ERC-20 et BEP-20 -Les blockchains compatibles **EVM** (Ethereum, BSC, etc.) partagent souvent le même modèle de contrat. **ERC-20** (Ethereum) et **BEP-20** (BSC) décrivent les mêmes idées : `balanceOf`, `transfer`, `approve`, `allowance`, événements `Transfer`, etc. +### 6.1 C’est quoi, en une phrase ? -Les wallets et explorateurs savent afficher un token **s’il respecte** ce standard. C’est pour cela que le sujet exige de respecter le standard de ta chaîne. +**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) | --- @@ -148,6 +295,180 @@ Le Web3 déplace une partie des risques vers **le code** et **les clés** : 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é) diff --git a/docs/pedagogie/README.md b/docs/pedagogie/README.md index e71705e..1b92e81 100644 --- a/docs/pedagogie/README.md +++ b/docs/pedagogie/README.md @@ -4,13 +4,17 @@ Parcours pour construire le projet **étape par étape** et le défendre en sout ## Reprise rapide -→ **[00-reprise-et-etat.md](00-reprise-et-etat.md)** — état du projet, décisions, prochaine action. +→ **[parcours-etape-par-etape.md](parcours-etape-par-etape.md)** — **parcours guidé** (une étape → vérification → suivante). -→ **[guide-realisation.md](guide-realisation.md)** — **guide dev** détaillé (choix techniques, sécurité, déploiement, démo). +→ **[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). → **[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** (Web1/2/3, blockchain, token, wallet, **BNB / Binance**, lien avec Tokenizer). +→ **[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 @@ -27,8 +31,8 @@ Ressources externes utiles : [docs Solidity](https://docs.soliditylang.org/), [O | Étape | Objectif | Statut | |-------|----------|--------| -| **0** | Dépôt travail + `docs/`, sujet FR, paquet `tokenizerRendu/` | ✅ **Fait** — [00-reprise-et-etat.md](00-reprise-et-etat.md) | -| **1** | Choix chaîne + stack (ex. BSC testnet + Hardhat) + nom token avec `42` | ⏳ À faire | +| **0** | Dépôt travail + `docs/`, sujet FR, paquet `tokenizerRendu/` | ✅ **Fait** | +| **1** | [Cadrage + wallet testnet](etapes/etape-01-cadrage-wallet-testnet.md) | 🔄 **En cours** | | **2** | Smart contract BEP-20 dans `tokenizerRendu/code/` (ownership, commentaires) | ⏳ À faire | | **3** | Scripts `tokenizerRendu/deployment/` + déploiement testnet + verify explorer | ⏳ À faire | | **4** | `documentation/` utilisateur + README école (adresse, réseau, choix) | ⏳ À faire | diff --git a/docs/pedagogie/decisions-projet.md b/docs/pedagogie/decisions-projet.md new file mode 100644 index 0000000..891e8eb --- /dev/null +++ b/docs/pedagogie/decisions-projet.md @@ -0,0 +1,115 @@ +# 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** | 1 — en cours | Wallet + faucet à finaliser par toi avant validation. | [etape-01](etapes/etape-01-cadrage-wallet-testnet.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) | + +### 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 | +|-------|--------|---------|-----------| +| **Adresse publique** | `À COMPLÉTER` (`0x…`) | Identifiant **public** de ton compte ; reçoit **tBNB** et, après deploy, les **FG42**. | [02-web3 § 3.5 wallet](02-web3-comprendre.md#35-wallet-portefeuille) | +| **tBNB (faucet)** | `À COMPLÉTER` (oui/non + date) | Gas pour déployer **FGC42Forge** et envoyer des txs de démo. | Sujet ch. I · [faucet](https://www.bnbchain.org/en/testnet-faucet) | +| **Compte dédié** | Recommandé | Ne pas réutiliser un wallet mainnet avec de vrais fonds. | Sujet ch. IV (pas d’argent réel) | + +### Paramètres MetaMask — BSC Testnet + +| Paramètre | Valeur | Concept | +|-----------|--------|---------| +| Nom | BNB Smart Chain Testnet | Libellé dans l’UI wallet | +| RPC URL | `https://data-seed-prebsc-1-s1.binance.org:8545/` | Voir colonne RPC ci-dessus | +| Chain ID | `97` | Doit correspondre à Hardhat `networks.bscTestnet` | +| Symbole | tBNB | Monnaie native pour le **gas** (pas FG42) | +| Explorer | https://testnet.bscscan.com | Vérifier balance tBNB et futur contrat FG42 | + +--- + +## 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 new file mode 100644 index 0000000..602bf1e --- /dev/null +++ b/docs/pedagogie/etapes/etape-01-cadrage-wallet-testnet.md @@ -0,0 +1,73 @@ +# É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)) + +- [ ] **Nom du token** (contient `42`, ex. `School42Token`) +- [ ] **Symbole** (ex. `S42`) — court, style ticker +- [ ] **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 + +- [ ] Installer **MetaMask** (ou Rabby, etc.) — navigateur ou mobile +- [ ] Créer ou utiliser un compte **uniquement pour le testnet** (pas de gros soldes mainnet) +- [ ] Ajouter le réseau **BNB Smart Chain Testnet** si absent : + - Nom : `BNB Smart Chain Testnet` + - RPC : `https://data-seed-prebsc-1-s1.binance.org:8545/` + - Chain ID : `97` + - Symbole : `tBNB` + - Explorer : `https://testnet.bscscan.com` +- [ ] Copier ton **adresse publique** (0x…) dans `decisions-projet.md` — **jamais** la phrase secrète / clé privée + +### C. Faucet tBNB + +- [ ] Aller sur [BNB Chain Testnet Faucet](https://www.bnbchain.org/en/testnet-faucet) +- [ ] Demander des **tBNB** sur ton adresse (parfois file d’attente ou limite — réessayer si besoin) +- [ ] Vérifier dans MetaMask : solde **tBNB** > 0 sur **BSC Testnet** + +### 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 + +--- + +## 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/parcours-etape-par-etape.md b/docs/pedagogie/parcours-etape-par-etape.md new file mode 100644 index 0000000..58d0d5b --- /dev/null +++ b/docs/pedagogie/parcours-etape-par-etape.md @@ -0,0 +1,33 @@ +# 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 | 🔄 **En cours** | +| **2** | *(à publier après validation étape 1)* | Init Hardhat dans `tokenizerRendu/code/` | ⏳ | +| **3** | *(à venir)* | Contrat BEP-20 + tests | ⏳ | +| **4** | *(à venir)* | Dossier `deployment/` + deploy + BscScan | ⏳ | +| **5** | *(à venir)* | `documentation/` utilisateur + README école (choix, adresse) | ⏳ | +| **6** | *(à venir)* | Démo minimale + préparation code review | ⏳ | +| **7** | *(à venir)* | Bonus multisig (optionnel) | ⏳ | + +## 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/sujets/tokenizer.md b/docs/sujets/tokenizer.md index a054ecc..a8420f4 100644 --- a/docs/sujets/tokenizer.md +++ b/docs/sujets/tokenizer.md @@ -131,9 +131,21 @@ Pour créer un token, plusieurs exigences techniques et organisationnelles s’a | **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.) | +| **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. @@ -245,7 +257,7 @@ Ces points ne sont pas toujours explicites dans le PDF ; ils servent de fil cond | Terme | En bref | |-------|---------| | **Token** | Contrat intelligent qui suit une norme (souvent **20** : solde, `transfer`, `approve`, etc.) | -| **BEP-20 / ERC-20** | Interface standard ; sur BSC testnet, BscScan reconnaît les tokens BEP-20 | +| **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. |