# Web3 — définition et concepts (pour le projet Tokenizer)

> Document **pédagogique** (dépôt de travail). Le sujet Tokenizer indique seulement : *« This document is a Web3 related exercise »* — ce texte complète cette mention avant de coder.

---

## 1. Qu’est-ce que le Web3 ?

**Web3** (ou **Web 3.0**) désigne une **vision** d’Internet où les utilisateurs interagissent avec des **services numériques** en s’appuyant sur des **réseaux décentralisés** (souvent des **blockchains**), plutôt que sur des **plateformes centralisées** seules (serveurs d’une entreprise, comptes verrouillés chez un opérateur).

En pratique, quand on dit « projet Web3 » à l’école ou en entreprise, on parle souvent de :

- des **smart contracts** (programmes exécutés sur une chaîne) ;
- des **tokens** (actifs numériques définis par ces contrats) ;
- des **portefeuilles** (*wallets*) qui signent des transactions avec des **clés cryptographiques** ;
- des **applications décentralisées** (**DApps**) qui lisent/écrivent l’état on-chain via des bibliothèques (ethers.js, web3.js, etc.).

Le Web3 n’est **pas** un protocole unique ni un fichier de norme ISO : c’est un **ensemble d’idées et de technologies** dont l’emballage marketing varie. Pour Tokenizer, l’angle utile est **technique** : tu crées un **token sur une blockchain publique** — c’est un brique classique de l’écosystème Web3.

---

## 2. Web1, Web2, Web3 — repères historiques (simplifiés)

| Génération | Image courante | Qui « possède » les données / la logique ? | Exemples |
|------------|----------------|--------------------------------------------|----------|
| **Web1** (~1990–2000) | Pages **lecture seule** | Éditeurs de sites, hébergeurs | Pages HTML statiques, premiers forums |
| **Web2** (~2000–aujourd’hui) | **Lecture + écriture** sociale, apps riches | **Plateformes** (GAFAM, SaaS) : tes données et règles chez elles | Réseaux sociaux, Google Docs, API 42 hébergée par 42 |
| **Web3** (depuis ~2017, terme popularisé) | **Lecture + écriture + propriété** d’actifs / règles on-chain | **Réseau** + contrats : l’état partagé est sur la chaîne ; l’utilisateur garde souvent sa **clé** | Tokens, DeFi, NFT, DApps |

Ces frontières sont **floues** : le Web2 n’a pas disparu ; la plupart des DApps ont encore un **site web classique** (Web2) qui parle à la blockchain (Web3).

**Lien Tokenizer :** tu ne construis pas tout un site décentralisé ; tu fabriques l’**actif** (token BEP-20) que d’autres apps Web3 pourraient utiliser plus tard.

---

## 3. Idées centrales du Web3 (vocabulaire)

### 3.1 Décentralisation

Plusieurs machines (nœuds) maintiennent une **copie** (ou une vue) du même registre. Personne ne peut, à lui seul, « effacer » une transaction validée selon les règles du protocole — contrairement à une base SQL sur un serveur unique.

- **Nuance :** « décentralisé » ≠ « parfaitement égalitaire ». Miners/validateurs, fondations, bridges peuvent concentrer du pouvoir. Il faut rester **critique**.

### 3.2 Blockchain

Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). **Consensus** (PoW, PoS, PoA, PoSA…) définit qui peut proposer le bloc suivant — voir [§ 6.6](#66-consensus-de-la-chaîne-pow-pos-poa-et-variantes).

- **BNB Chain** (sujet Tokenizer) est une de ces chaînes, orientée **smart contracts** et volume d’usage.

### 3.3 Smart contract

Programme déployé à une **adresse** sur la chaîne. Une fois publié, son code est (en principe) **immuable** sauf si le contrat prévoit une mise à jour ou un proxy. Les utilisateurs l’appellent en envoyant des **transactions**.

- **Ton projet :** le token est un smart contract (souvent basé sur le standard **BEP-20**).

### 3.4 Token

Actif numérique défini par un contrat : soldes par adresse, transferts, parfois **mint** / **burn**. Un token peut représenter une **unité de compte** (style monnaie), des **parts**, ou un rôle dans un protocole — selon ce que **tu documentes**.

| Action | Effet sur la supply |
|--------|---------------------|
| **Mint** | **Crée** des tokens et les crédite à une adresse → `totalSupply` **augmente** |
| **Burn** | **Détruit** des tokens → `totalSupply` **diminue** |
| **Transfer** | Déplace des tokens existants → la supply **ne change pas** |

Au **déploiement**, beaucoup de contrats créent toute la supply dans le constructeur (**supply fixe**, pas de `mint` après). D’autres gardent une fonction `mint()` — souvent réservée au **`owner`** (`onlyOwner`).

- **Contrainte 42 :** le **nom** doit contenir `42` ; le ticker et l’usage sont à toi (dans le cadre du sujet).
- **Mint « illimité »** : voir [§ 7.1](#71-mint-et-mint-illimité).
- **Supply, owner, Ownable, onlyOwner** : voir [§ 7.2](#72-glossaire-anglais--supply-owner-ownable-onlyowner).

### 3.5 Wallet (portefeuille)

Logiciel ou matériel qui gère une **paire de clés** :

- **Adresse publique** (ex. `0xabc…`) — identifiant pour recevoir ;
- **Clé privée** — secret qui **signe** les transactions (ne jamais la committer dans Git).

Sur testnet, le wallet contient des **tBNB** (gas) et tes tokens après déploiement / transfer.

### 3.6 DApp (Decentralized Application)

Application dont une partie critique repose sur des contrats on-chain (échanges, votes, tokens). Souvent : front web ou mobile + bibliothèque Web3 + RPC vers un nœud.

- Tokenizer **n’exige pas** une DApp complète ; le token est la brique de base.

### 3.7 Gas

Frais payés dans la **monnaie native** de la chaîne (BNB sur BSC, ETH sur Ethereum) pour exécuter une transaction. Sur **testnet**, cette monnaie n’a **pas de valeur réelle** — le sujet insiste : pas d’argent réel pour le projet.

### 3.8 Explorateur de blocs (BscScan, etc.)

Site qui indexe chaîne : adresses, transactions, code vérifié du contrat. Obligatoire pour **prouver** le déploiement et le ticker en soutenance.

### 3.9 Réseau RPC

**RPC** (*Remote Procedure Call*) = façon pour un programme (wallet, Hardhat, Remix) de **parler à un nœud** de la blockchain via une **URL HTTP(S)**.

La blockchain ne tourne pas sur ton PC : des **nœuds** répartis sur Internet maintiennent le registre. Ton outil doit pourtant :

- **lire** l’état (solde, `name()` du token, code d’un contrat) ;
- **envoyer** des transactions déjà **signées** par ta clé privée (déploiement, `transfer`, etc.).

Le **point d’accès RPC** est la « ligne téléphonique » vers ce réseau. Ce n’est **pas** une blockchain séparée : c’est la **porte d’entrée** vers la chaîne que tu as choisie (testnet ou mainnet).

| Élément | Rôle |
|---------|------|
| **URL RPC** | Adresse du service/nœud (ex. endpoint BSC Testnet dans MetaMask ou `hardhat.config.js`) |
| **Wallet / script** | Construit la tx, la signe localement, l’envoie **via** le RPC |
| **Chaîne** | Reçoit la tx, l’exécute, met à jour l’état on-chain |

**Exemple (BSC Testnet, indicatif)** — une URL publique souvent utilisée :

`https://data-seed-prebsc-1-s1.binance.org:8545/`

**Erreur fréquente :** RPC pointant sur le **mainnet** alors que tu crois être sur le **testnet** → tu dépenses du vrai BNB ou tu ne vois pas ton contrat de test. Vérifie **réseau + chainId** (BSC Testnet = `97`) dans le wallet et dans Hardhat.

Dans le schéma ci-dessous, la boîte **« Réseau RPC »** est cette couche entre ton wallet et la **blockchain publique**.

---

## 4. Web3 et « crypto » — ne pas confondre

| Terme | Sens |
|-------|------|
| **Cryptographie** | Mathématiques (signatures, hash) — **fondation** technique de la blockchain |
| **Crypto-actif / « crypto »** (langage courant) | Tokens échangeables, souvent spéculatifs — **contexte économique** |
| **Web3** | Mouvement produit / dev autour d’apps et actifs on-chain |

Le projet Tokenizer est un exercice **d’ingénierie** (contrat, déploiement, sécurité, documentation), pas une recommandation d’investissement. Le partenariat **BNB Chain** situe l’exercice dans un **écosystème** réel, tout en utilisant le **testnet** pour éviter le risque financier.

---

## 5. Architecture mentale : où se place ton token ?

```mermaid
flowchart LR
  subgraph web2 [Couche familière Web2]
    User[Utilisateur]
    Browser[Navigateur / IDE / Git]
  end
  subgraph web3 [Couche Web3]
    Wallet[Wallet]
    RPC[Réseau RPC]
    Chain[Blockchain publique]
    SC[Smart contract Token BEP-20]
    Explorer[Explorateur BscScan]source ~/.bashrc 
  Wallet --> RPC
  RPC --> Chain
  Chain --> SC
  SC --> Explorer
  Browser --> Explorer
```

1. Tu **écris** le contrat en local (`code/`).
2. Tu **déploies** via un script (`deployment/`) — transaction signée par ton wallet test.
3. Le contrat vit à une **adresse** sur la chaîne.
4. Tout le monde peut **lire** l’état via l’explorateur ; les détenteurs de tokens **transfèrent** via leurs wallets.

**Lecture du schéma :** `Wallet → RPC → Chain` = ton MetaMask ou Hardhat envoie des requêtes à l’**URL RPC** du testnet, qui relaie vers les nœuds BSC Testnet. Détail : [§ 3.9](#39-réseau-rpc).

---

## 6. Standards : ERC-20 et BEP-20

### 6.1 C’est quoi, en une phrase ?

**ERC-20** et **BEP-20** sont des **normes** (des « contrats types ») pour des **tokens fongibles** : chaque unité est interchangeable (comme des pièces identiques), contrairement aux NFT (ERC-721, etc.).

| Norme | Chaîne concernée (exemples) |
|-------|------------------------------|
| **ERC-20** | **Ethereum** et la plupart des L2 EVM (Sepolia testnet, etc.) |
| **BEP-20** | **BNB Chain** / **BSC** (*BNB Smart Chain*) — partenaire du sujet Tokenizer |

Le **BEP** signifie *BNB Evolution Proposal* (propositions d’évolution de l’écosystème BNB), sur le même principe que **EIP** (*Ethereum Improvement Proposal*) pour ERC-20.

### 6.2 Que impose le standard ?

Ce n’est pas un fichier que tu télécharges : c’est une **interface** — ton contrat doit exposer au minimum des fonctions et événements reconnus par les wallets et explorateurs.

| Fonction / événement | Rôle |
|----------------------|------|
| `name()`, `symbol()`, `decimals()` | Affichage dans MetaMask, BscScan, etc. |
| `totalSupply()` | Offre totale de tokens existants |
| `balanceOf(adresse)` | Solde d’un compte |
| `transfer(dest, montant)` | Envoyer des tokens |
| `approve(spender, montant)` | Autoriser un autre compte/contrat à dépenser pour toi |
| `allowance(owner, spender)` | Combien il reste à dépenser via `approve` |
| `transferFrom(from, to, montant)` | Dépenser pour quelqu’un qui t’a `approve` |
| `event Transfer` | Historique on-chain des mouvements |

En projet 42, on utilise presque toujours **OpenZeppelin `ERC20`** : le code respecte ERC-20 ; déployé sur **BSC**, l’explorateur le qualifie de token **BEP-20**.

### 6.3 ERC-20 vs BEP-20 : même logique, nom selon la chaîne

Les deux chaînes sont **compatibles EVM** (même machine virtuelle, même langage **Solidity**). Pour un token « classique », le **code est souvent identique** ; ce qui change :

| | ERC-20 | BEP-20 |
|---|--------|--------|
| **Réseau typique Tokenizer** | Possible (ex. Sepolia) | **Recommandé** (BSC Testnet, tBNB, BscScan) |
| **Gas** | ETH (ou ETH test) | BNB / **tBNB** |
| **Explorateur** | Etherscan | BscScan |
| **Standard token fongible** | ERC-20 | BEP-20 (interface équivalente) |

**BEP-2** (autre norme BNB, ancienne Binance Chain) n’est **pas** le standard de ton exercice type « token ERC-20-like » sur BSC.

### 6.4 Le sujet t’oblige-t-il à choisir BEP-20 ?

**Non au sens « BEP-20 pour tout le monde ».** Le sujet dit :

- tu **choisis** une blockchain ;
- tu respectes **le standard de cette chaîne** (exemples : ERC-20 sur ETH, **BEP-20 sur BSC**).

Donc :

- **Si tu déploies sur BNB Smart Chain** → tu dois livrer un token **BEP-20** (en pratique : contrat ERC-20-compatible sur BSC).
- **Si tu déploies sur Ethereum testnet** → **ERC-20**, avec justification dans le README.

Le partenariat **42 × BNB Chain**, le faucet **tBNB** et les exemples **BscScan** orientent fortement vers **BSC testnet + BEP-20**, sans interdire formellement une autre chaîne EVM bien documentée.

**Phrase utile en soutenance :**

> « Mon token suit le standard **BEP-20** de BNB Chain, l’équivalent de l’**ERC-20** sur Ethereum ; j’ai utilisé OpenZeppelin ERC20 déployé sur le testnet. »

### 6.5 Pourquoi le sujet insiste sur un standard ?

Sans norme commune, chaque contrat aurait des noms de fonctions différents : les wallets ne pourraient pas afficher ton token ni proposer `transfer`. Le standard rend le token **lisible** par tout l’écosystème — c’est ce que l’évaluateur vérifie (comportement + code review), pas un label marketing.

### 6.6 Consensus de la chaîne : PoW, PoS, PoA (et variantes)

Quand le § 3.2 parle de **consensus**, il s’agit de la règle du réseau pour répondre à une question simple :

> **Qui a le droit de proposer le bloc suivant**, et comment les autres nœuds **acceptent** qu’il est valide ?

Tu **n’implémentes pas** ce mécanisme dans Tokenizer : tu **déploies sur une chaîne** qui l’a déjà. Comprendre PoS / PoA aide en soutenance (« sur quelle infra tourne mon token ? ») et évite de confondre **consensus réseau** et **multisig** (voir [§ 7.3](#73-multisig--types-et-lien-avec-le-bonus)).

#### PoW — *Proof of Work* (preuve de travail)

| | |
|---|---|
| **Idée** | Des **mineurs** rivalisent pour résoudre un puzzle cryptographique coûteux ; le gagnant publie le bloc et reçoit une récompense. |
| **Forces** | Très étudié (Bitcoin) ; sécurité liée à la **puissance de calcul** globale. |
| **Faiblesses** | **Consommation énergétique** élevée ; temps de bloc et frais variables. |
| **Exemples** | Bitcoin ; Ethereum **avant** « The Merge » (2022). |

#### PoS — *Proof of Stake* (preuve d’enjeu)

| | |
|---|---|
| **Idée** | Des **validateurs** bloquent une **mise** (*stake*) en tokens natifs ; le protocole **désigne** qui propose le bloc ; triche possible → **pénalités** (*slashing*). |
| **Forces** | Beaucoup moins énergivore que PoW ; modèle dominant sur les chaînes récentes. |
| **Faiblesses** | Débats sur concentration du stake, gouvernance, MEV — hors scope Tokenizer. |
| **Exemples** | Ethereum **depuis** The Merge ; Cardano, Polkadot, etc. |

#### PoA — *Proof of Authority* (preuve d’autorité)

| | |
|---|---|
| **Idée** | Seules des **entités identifiées** (liste fermée de validateurs / *sealers*) peuvent créer des blocs — pas de mining ni de stake ouvert comme en PoS grand public. |
| **Forces** | Blocs **rapides**, prévisibles ; idéal pour **réseaux privés** ou **testnets d’entreprise**. |
| **Faiblesses** | **Centralisation** assumée : il faut **faire confiance** aux autorités listées. |
| **Exemples** | Nombreux **testnets locaux** Hardhat ; chaînes consortium (Hyperledger Besu en mode PoA, etc.). |

#### Autres noms que tu peux croiser

| Sigle | Signification | Lien utile |
|-------|---------------|------------|
| **DPoS** | *Delegated Proof of Stake* — les détenteurs **élisent** un petit nombre de délégués validateurs | Certaines chaînes grand public |
| **PoSA** | *Proof of Staked Authority* — **mélange** : validateurs limités + mise en jeu | **BNB Smart Chain** utilise ce modèle (petit ensemble de validateurs actifs, historiquement ~21) |
| **IBFT / QBFT** | Variantes PoA pour réseaux privés | Plutôt entreprise, pas ton deploy BSC testnet |

**Pour BNB Chain (sujet Tokenizer) :** ce n’est pas du PoW ; ce n’est pas exactement le PoS « ouvert » d’Ethereum. C’est plutôt un modèle **PoSA** : validateurs connus + stake — assez pour dire en oral : « chaîne EVM avec validateurs, je suis utilisateur via testnet, pas validateur ».

#### Tableau comparatif (révision)

| | PoW | PoS (typique) | PoA |
|---|-----|---------------|-----|
| **Qui produit les blocs ?** | Mineurs (calcul) | Validateurs (stake) | Autorités désignées |
| **Barrière à l’entrée** | Matériel + électricité | Capital en stake | Invitation / liste |
| **Décentralisation** | Variable | Variable | Souvent **faible** (volontaire) |
| **Ton projet** | Tu ne le choisis pas | Tu **utilises** la chaîne telle quelle | Idem (sauf réseau local perso) |

---

## 7. Sécurité — angle Web3 (rappel sujet)

Le Web3 déplace une partie des risques vers **le code** et **les clés** :

| Risque | Exemple |
|--------|---------|
| Clé privée exposée | Drain du wallet |
| `owner` trop puissant | Mint illimité, vol de confiance |
| Bug de contrat | Fonds ou tokens bloqués / volés |
| Mauvaise doc | Utilisateurs qui ne comprennent pas les privilèges |

Tokenizer te demande explicitement de réfléchir à **ownership** et **privilèges** et de le montrer en **démo minimale** + **revue de code**.

### 7.1 Mint et mint illimité

Ce n’est **pas** le nom d’une fonction dans le code. On parle d’une **situation de gouvernance** :

> Tant que le **`owner`** peut appeler `mint` **sans plafond** ni règle stricte dans le contrat, il peut **créer autant de tokens qu’il veut**, quand il veut.

**Pourquoi c’est sensible (même sur testnet, pour la soutenance) :**

- Si le token représente des parts ou une « monnaie » fictive, un mint massif **dilue** tous les détenteurs (comme une impression monétaire sans limite).
- Si la **clé privée du owner** est compromise, un attaquant peut abuser de `mint`.
- Le sujet demande d’expliquer **ownership** et **privilèges** : un `mint()` `onlyOwner` **sans** `MAX_SUPPLY` est le cas classique à **documenter** et à **assumer** dans le README école.

**Pistes de design (à justifier dans ton README) :**

| Approche | Idée |
|----------|------|
| **Supply fixe** | Toute la supply créée au deploy, **pas** de `mint` ensuite |
| **Plafond** | `require(totalSupply() + amount <= MAX_SUPPLY)` |
| **Mint one-shot** | Mint initial puis fonction désactivée |
| **Bonus multisig** | Plusieurs signatures avant un mint ou avant une action owner critique |

**Exemple courant (OpenZeppelin) :** `ERC20` + `Ownable` + une fonction `mint(address, uint256)` en `onlyOwner` = mint illimité **tant que** tu n’ajoutes pas de limite explicite. Ce n’est pas « faux » pour l’exercice, mais tu dois le dire à l’oral : qui peut mint, quel risque, pourquoi tu as choisi ainsi.

**Démo eval utile :** montrer qu’un compte **non-owner** ne peut pas `mint` (transaction qui **revert** ou test Hardhat).

### 7.2 Glossaire anglais — supply, owner, Ownable, onlyOwner

La doc Solidity et OpenZeppelin est en anglais. Ces quatre termes reviennent partout dans Tokenizer et en soutenance.

#### Supply (*offre*, *quantité en circulation*)

| Terme | Signification |
|-------|----------------|
| **supply** | **Quantité totale** de tokens qui **existent** pour ce contrat (à un instant donné). |
| **total supply** | Même idée ; en code ERC-20 : fonction **`totalSupply()`** qui renvoie un nombre (souvent en plus petite unité, avec **décimales**). |
| **fixed supply** | Toute la supply est créée **une fois** (souvent au déploiement) ; il n’y a plus de création après. |
| **max supply** | **Plafond** : on ne peut pas dépasser ce total (souvent constante `MAX_SUPPLY` dans le contrat). |

**Exemple mental :** si tu crées 1 000 000 tokens au deploy et qu’il n’y a pas de `mint`, la supply est **fixe** à 1 000 000. Chaque `transfer` ne change pas `totalSupply` ; seul un **mint** l’augmente et un **burn** la diminue.

**À l’oral en français :** tu peux dire « **offre totale** » ou « **quantité totale de tokens émis** » plutôt que laisser *supply* sans traduction.

---

#### Owner (*propriétaire du contrat*)

| Précision | Détail |
|-----------|--------|
| **Ce que c’est** | Une **adresse** (compte wallet) désignée comme **administrateur** du smart contract — pas « propriétaire de tous les tokens ». |
| **Ce que ce n’est pas** | Ce n’est pas automatiquement la personne qui détient le plus de tokens ; c’est celui qui a les **droits d’administration** définis dans le code (mint, changer le owner, etc.). |
| **Qui devient owner au deploy ?** | Souvent **`msg.sender`** : l’adresse qui a **déployé** le contrat (ta transaction de déploiement). |

Le sujet parle d’**ownership** (*propriété* / *gouvernance*) au sens : **qui a le pouvoir** sur les fonctions sensibles du contrat.

---

#### Ownable (bibliothèque OpenZeppelin)

**Ownable** n’est pas un mot du standard BEP-20 : c’est un **module** fourni par [OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) que tu **hérites** dans ton contrat, par exemple :

```solidity
contract MonToken42 is ERC20, Ownable {
    // ...
}
```

Ce module ajoute notamment :

| Élément | Rôle |
|---------|------|
| Variable interne `_owner` | Stocke l’adresse du **owner** actuel |
| `owner()` | Fonction **lecture** : qui est owner ? |
| `transferOwnership(nouvelleAdresse)` | Transfère le rôle admin à une autre adresse (**onlyOwner**) |
| `renounceOwnership()` | Owner renonce à son rôle (plus personne n’est owner — à utiliser en connaissance de cause) |

**Pourquoi l’utiliser :** pattern éprouvé, lisible en **code review**, moins de bugs qu’un `address boss` écrit à la main.

---

#### onlyOwner (modificateur Solidity)

En Solidity, un **modifier** (*modificateur*) est une règle placée **avant** une fonction. **`onlyOwner`** (fourni par `Ownable`) signifie :

> Seule l’adresse retournée par `owner()` peut appeler cette fonction ; **toute autre adresse** voit la transaction **échouer** (*revert*).

Exemple typique :

```solidity
function mint(address to, uint256 amount) public onlyOwner {
    _mint(to, amount);
}
```

| Lecteur du code | Comportement |
|-----------------|--------------|
| Appel depuis le **wallet owner** | `mint` s’exécute, supply augmente |
| Appel depuis **un autre compte** | Échec : pas le droit d’appeler |

**Lien avec le sujet :** c’est un **privilège** explicite à expliquer en README : « seul le owner peut mint ; en eval je montre qu’un autre compte ne peut pas ».

---

#### Tableau récapitulatif

| Anglais | Français (soutenance) | Où tu le vois |
|---------|----------------------|---------------|
| **supply** | offre / quantité totale émise | `totalSupply()`, doc, whitepaper |
| **owner** | propriétaire (admin du contrat) | `owner()`, sujet « ownership » |
| **Ownable** | contrat / module « propriété unique » | `import` OpenZeppelin, héritage |
| **onlyOwner** | « réservé au propriétaire » | modifier sur `mint`, `pause`, etc. |

### 7.3 Multisig — types et lien avec le bonus

**Multisig** (*multisignature*) = une action (souvent une **transaction** ou un appel de contrat) n’est **valide** que si **plusieurs clés** ont approuvé, selon un seuil **m sur n** :

> Exemple **2-of-3** : trois signataires possibles, **au moins 2** signatures requises pour exécuter.

Ce n’est **pas** un mécanisme de consensus de **chaîne** (PoS/PoA) : c’est une règle de **gouvernance** sur un **wallet** ou un **contrat** — souvent proposé en **bonus** Tokenizer.

#### Multisig ≠ onlyOwner

| | **onlyOwner** (obligatoire courante) | **Multisig** (bonus sujet) |
|---|--------------------------------------|----------------------------|
| **Qui décide ?** | **Une** adresse | **Plusieurs** adresses selon seuil |
| **Risque** | Une clé volée = tout perdu | Une clé volée ne suffit en général **pas** |
| **Complexité** | Faible (`Ownable`) | Plus élevée (contrat dédié ou wallet multisig) |

#### Types / formes de multisig (les plus utiles à connaître)

**1. Wallet multisig on-chain (contrat portefeuille)**

- Un **smart contract** détient les fonds (BNB, tokens).
- Flux typique : `proposeTransaction` → chaque signataire `confirm` → `execute` quand le seuil **m** est atteint.
- Exemples connus : **Safe** (ex-Gnosis Safe), contrats multisig « maison » pour le bonus.
- **Usage Tokenizer :** le **owner** du token peut être ce contrat multisig au lieu d’un seul MetaMask.

**2. Multisig sur une fonction précise (contrat custom)**

- Ton token reste `ERC20`, mais `mint` ou `transferOwnership` exige que **k adresses** aient signé ou validé (pattern plus rare en débutant ; souvent on passe par un wallet multisig qui **est** l’owner).

**3. Seuils différents (m-of-n)**

| Notation | Signification |
|----------|----------------|
| **1-of-n** | Une seule signature parmi n suffit (peu protecteur) |
| **2-of-3** | Classique pour petites équipes / testnet |
| **n-of-n** | **Tous** doivent signer (très strict, risque de blocage si une clé est perdue) |
| **m-of-n** | Cas général du sujet (« plusieurs parties » + nombre requis) |

**4. Multisig « hors chaîne » / institutionnel**

- Clés réparties entre coffres HSM, procédures bancaires — tu n’en fais pas pour 42 ; utile seulement pour situer le paysage.

**5. Ce qu’on ne confond pas**

| Terme | Ce que ce n’est pas |
|-------|---------------------|
| **Multisig** | Pas « plusieurs owners » indépendants sur le même `Ownable` OpenZeppelin standard |
| **Multi-sig Bitcoin (P2SH)** | Même **idée** (m-of-n), autre blockchain — pas ton stack BEP-20 |
| **RPC / plusieurs nœuds** | Infrastructure réseau, pas gouvernance de clés |

#### Bonus sujet Tokenizer — ce qu’on attend (esprit)

Le PDF demande un contrat où **plusieurs signatures** sont nécessaires **avant** d’exécuter une transaction sensible. En pratique, les approches acceptables en soutenance :

1. **Wallet multisig** qui possède l’ownership du token + démo d’un `mint` ou transfert validé à 2-of-n.
2. **Contrat multisig minimal** + documentation : qui signe, quel seuil, comment tester sur testnet.

Adapter le bonus à **ta** partie obligatoire (même token, même réseau) — voir [guide-realisation.md](guide-realisation.md) étape 8.

#### Phrase oral utile

> « Le **consensus PoSA** de BNB Chain fait tourner le réseau ; mon **multisig**, c’est au niveau **application** : plusieurs clés doivent valider avant qu’on puisse agir en tant qu’admin du token. »

---

## 8. Ce que le Web3 t’apporte dans *ce* projet (résumé)

| Concept Web3 | Dans Tokenizer |
|--------------|----------------|
| Blockchain publique | Déploiement testnet + adresse dans README |
| Smart contract | `code/` — token |
| Token standard | BEP-20 (recommandé) |
| Wallet + gas | tBNB via faucet |
| Transparence | Explorer + verify |
| Gouvernance minimale | Owner, éventuel bonus multisig |

Pour aller plus loin sur les **compétences** visées : [01-apports-pedagogiques.md](01-apports-pedagogiques.md).  
Pour passer à l’action : [guide-realisation.md](guide-realisation.md).

---

## 9. Lectures utiles (hors 42)

- [Ethereum.org — Introduction](https://ethereum.org/fr/developers/docs/intro-to-ethereum/) (concepts transférables à BSC)
- [BNB Chain — documentation développeurs](https://www.bnbchain.org/en/developers)
- [OpenZeppelin — ERC20](https://docs.openzeppelin.com/contracts/5.x/erc20)

---

## 10. BNB, BNB Chain et Binance (partenaire du sujet)

Le chapitre I du sujet parle de **BNB Chain** et du faucet **tBNB**. Le sigle **BNB** prête souvent à confusion avec **Binance** : voici une cartographie claire pour Tokenizer.

### 10.1 Trois sens différents de « BNB »

| Sens | Explication |
|------|-------------|
| **BNB Chain** | Le **réseau blockchain** (smart contracts, tokens, DApps). Nom marketing actuel : *Build N Build* — c’est ce que le PDF cite en partenariat avec 42. |
| **BNB (l’actif)** | La **monnaie native** de cette chaîne : tu la dépenses en **gas** pour déployer un contrat ou envoyer une transaction. |
| **tBNB** | Même rôle sur le **testnet** : BNB de **test**, **sans valeur réelle** — obtenu via le [faucet](https://www.bnbchain.org/en/testnet-faucet) du sujet. |

Ton token du projet (BEP-20) est un **autre** contrat : ce n’est pas le BNB natif, mais il vit sur la **même chaîne** et les transferts de ton token consomment aussi du gas payé en (t)BNB.

### 10.2 Rapport avec Binance

**Oui, il y a un lien historique et économique**, mais **BNB Chain n’est pas « l’application Binance »** au sens du site d’échange.

| Élément | Rôle |
|---------|------|
| **Binance** | Entreprise fondée en 2017, connue surtout comme **plateforme d’échange** centralisée (ordres, carnets, comptes utilisateurs). |
| **Origine du token BNB** | Lancé par l’écosystème Binance ; le nom venait souvent de **Binance Coin** à l’époque. |
| **Binance Smart Chain (BSC)** | Lancée en 2020 : chaîne **compatible EVM** (proche d’Ethereum) pour des contrats moins chers / rapides que le mainnet ETH de l’époque. |
| **Rebranding BNB Chain** | La chaîne et la marque ont été regroupées sous **BNB Chain** (*Build N Build*) : communication orientée **réseau pour développeurs**, pas seulement exchange. |

En soutenance, une formulation honnête et suffisante :

> « Le sujet est en partenariat avec **BNB Chain**. BNB est la monnaie native de ce réseau ; l’écosystème est lié historiquement à **Binance**, mais mon projet tourne sur le **testnet public** avec **tBNB** — je n’utilise pas de fonds réels ni le compte trading Binance. »

### 10.3 Noms que tu peux croiser (glossaire)

| Abréviation | Signification | Utile pour Tokenizer |
|-------------|---------------|----------------------|
| **BSC** | *Binance Smart Chain* — ancien nom courant de la chaîne | Encore utilisé dans les tutos (MetaMask « BSC Testnet ») |
| **BNB Smart Chain** | Formulation intermédiaire | Même famille que BSC / BNB Chain |
| **BEP-20** | Standard des **tokens** sur BNB Chain | **Obligatoire** à respecter (équivalent ERC-20) |
| **BEP-2** | Ancien format sur une autre brique (Binance Chain legacy) | **Pas** le standard de ton exercice type ERC-20/BEP-20 |
| **BscScan** | Explorateur de blocs pour BSC / BNB Chain | Où publier l’adresse du contrat après déploiement |
| **chainId 97** | Identifiant du **BSC Testnet** | À mentionner dans le README école avec l’adresse |

### 10.4 Ce dont tu as besoin (et ce dont tu n’as pas besoin)

| Besoin | Pourquoi |
|--------|----------|
| **Wallet** (MetaMask, Rabby, etc.) | Adresse + signature des transactions de déploiement |
| **RPC testnet** | Connexion Hardhat / Remix à la chaîne de test |
| **tBNB** (faucet) | Payer le gas du deploy et des démos |
| **Compte Binance / KYC** | **Non requis** pour le projet tel que décrit dans le sujet |

Le **mainnet** BNB (vrai BNB avec valeur marché) n’est **pas** demandé ; le sujet insiste sur les **test chains**.

### 10.5 Lien avec le chapitre I du PDF

Le partenariat **42 × BNB Chain** explique :

- les statistiques d’usage (volume, DApps) dans le préambule ;
- le lien vers [bnbchain.org](https://www.bnbchain.org/) (Figure I.1) ;
- le **faucet** pour développer sans argent réel.

Ce n’impose pas juridiquement BSC en une phrase « tu dois utiliser BSC », mais c’est la piste **la plus alignée** avec le sujet (BEP-20, tBNB, BscScan). Une autre chaîne EVM reste possible si tu **justifies** tes choix dans le README école.

→ Rappel dans le sujet traduit : [Chapitre I — BNB, Binance et BNB Chain](../sujets/tokenizer.md#bnb-binance-et-bnb-chain).

---

*Dernière révision : ajout section BNB / Binance — à compléter si tu choisis une chaîne non-EVM (peu courant pour ce sujet).*