Files

2026-10-19 13:54:57 +02:00

31 KiB

Raw Blame History

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 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 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 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 :

Wallet multisig qui possède l’ownership du token + démo d’un mint ou 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).

31 KiB Raw Blame History Unescape Escape