31 KiB
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.
- 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.
- Supply, owner, Ownable, onlyOwner : voir § 7.2.
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 ?
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
- Tu écris le contrat en local (
code/). - Tu déploies via un script (
deployment/) — transaction signée par ton wallet test. - Le contrat vit à une adresse sur la chaîne.
- 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.
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).
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
ownerpeut appelermintsans 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()onlyOwnersansMAX_SUPPLYest 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 que tu hérites dans ton contrat, par exemple :
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 :
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 signataireconfirm→executequand 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, maismintoutransferOwnershipexige 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 :
- Wallet multisig qui possède l’ownership du token + démo d’un
mintou transfert validé à 2-of-n. - 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 é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.
Pour passer à l’action : guide-realisation.md.
9. Lectures utiles (hors 42)
- Ethereum.org — Introduction (concepts transférables à BSC)
- BNB Chain — documentation développeurs
- OpenZeppelin — 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 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 (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.
Dernière révision : ajout section BNB / Binance — à compléter si tu choisis une chaîne non-EVM (peu courant pour ce sujet).