🚀 Layer-2 & Scaling (Mise à l'échelle)
Analyse dense : Le Trilemme, Rollups (Optimistic vs ZK), Arbitrum, Optimism & EIP-4844.
Le Problème : Le Trilemme
Le défi fondamental : Sécurité vs Scalabilité vs Décentralisation. Pourquoi Ethereum L1 est lent et cher (par conception).
TrilemmeScalabilitéGasL2 (Rollup) vs Sidechain
La distinction de sécurité critique. L2 (hérite) vs Sidechain (propre consensus). Rollups (L2) vs Polygon PoS (Sidechain).
Rollup (L2)SidechainModèle de SécuritéOptimistic Rollups (Théorie)
Modèle "Trust, but Verify" (Innocent jusqu'à preuve du contraire). La "Fraud Proof" (Preuve de Fraude) et la fenêtre de 7 jours.
OptimisticFraud Proof7 JoursPlateformes : Arbitrum vs Optimism
Arbitrum Nitro (Multi-Round Fraud Proof) vs Optimism (Single-Round). La course à l'"OP Stack" (Superchain).
ArbitrumOptimismOP StackZK-Rollups (Théorie)
Modèle "Don't Trust, Verify" (Coupable jusqu'à preuve d'innocence). La "Validity Proof" (Preuve de Validité). SNARKs vs STARKs.
Zero-KnowledgeValidity ProofSNARK/STARKPlateformes : zkSync vs Starknet
La course au "zkEVM". zkSync (SNARKs, Compatibilité EVM) vs Starknet (STARKs, Langage Cairo, performance pure).
zkSyncStarknetzkEVMCairoAvancé : Modularité & Data Availability
Monolithique vs Modulaire. Le goulot d'étranglement du "Calldata". Le rôle de Celestia ($TIA) comme couche de "Data Availability" (DA).
ModulaireData AvailabilityCelestiaFutur : EIP-4844 (Proto-Danksharding)
La solution L1. "Proto-Danksharding". Le "Blobspace" : un nouveau marché de frais pour les L2, 10-100x moins cher.
EIP-4844DankshardingBlobsLe **"Trilemme de la Blockchain"** (popularisé par Vitalik Buterin) est le défi de conception fondamental auquel sont confrontés *tous* les protocoles de Layer 1 (L1). Il stipule qu'un L1 ne peut optimiser que **deux** des trois propriétés suivantes, au détriment de la troisième.
Les 3 Piliers
- 1. Décentralisation (Le "Nœud Domestique") :
- Définition : Le système peut fonctionner sans dépendre d'acteurs centraux.
- Mesure : La capacité pour un individu "normal" de faire tourner un **Nœud Complet (Full Node)** (le gardien de la validité) sur un ordinateur personnel, avec une connexion internet standard.
- Pourquoi ? Si seuls 10 data centers (ex: Google, Amazon) peuvent se permettre de faire tourner un nœud, le réseau est centralisé et vulnérable à la censure ou aux pannes.
- 2. Sécurité (L'Attaque) :
- Définition : La capacité du réseau à résister à une attaque (ex: une attaque 51%).
- Mesure : Le **coût** (en $ milliards) pour "corrompre" le consensus. En PoW (Bitcoin), c'est le coût de l'énergie (Hashrate). En PoS (Ethereum), c'est le coût du capital (le $ total staké).
- Pourquoi ? C'est la garantie de l'immuabilité et de la finalité.
- 3. Scalabilité (La Vitesse) :
- Définition : La capacité du réseau à traiter un grand nombre de transactions par seconde (TPS).
- Mesure : TPS (Transactions Per Second). (Ex: Visa ≈ 24 000 TPS).
- Pourquoi ? Pour l'adoption de masse (paiements, jeux, etc.).
Le Compromis Inévitable (pour un L1)
Pourquoi ces piliers sont-ils en conflit ?
Pour augmenter la Scalabilité (TPS), vous devez (généralement) :
- Augmenter la Taille des Blocs : (Ex: de 1 Mo à 128 Mo).
- Réduire le Temps de Bloc : (Ex: de 12 sec à 400ms).
La Conséquence : Si les blocs sont 1000x plus gros et 10x plus rapides, les "fichiers" de la blockchain (l'historique) explosent (ex: 50 To/an). La bande passante et le CPU requis pour *valider* ce bloc en 400ms deviennent énormes.
L'ordinateur personnel (le "nœud domestique") ne peut plus suivre. Il abandonne.
Seuls des "Super-Nœuds" (data centers) peuvent participer. Vous avez **sacrifié la Décentralisation** pour gagner en **Scalabilité** (ex: le modèle de Solana).
La "Roadmap" d'Ethereum (La Solution)
La philosophie d'Ethereum est de **ne pas faire de compromis sur le L1** :
- L1 (Ethereum) : Optimise **Décentralisation + Sécurité**. Il reste *volontairement* lent et cher (faibles TPS). Son rôle n'est pas l'exécution, c'est le **Consensus** et la **Disponibilité des Données (Data Availability)**. C'est la "Cour Suprême" de la sécurité.
- L2 (Rollups) : Optimise la **Scalabilité**. Les L2 (Arbitrum, Optimism) sont des "tribunaux de district" qui gèrent *l'exécution* (les transactions) rapidement et à bas coût, mais qui "postent" un résumé (les preuves ou les données) sur le L1 pour **hériter** de sa sécurité.
Ces deux termes sont souvent confondus, mais leur **modèle de sécurité** est fondamentalement différent. C'est la distinction la plus importante du "scaling".
1. Layer-2 (Rollup) - Sécurité Héritée
- Exemples : Arbitrum, Optimism, zkSync, Starknet.
- Définition : Un L2 est une chaîne qui **hérite sa sécurité** du L1 (Ethereum). L'état du L2 est "garanti" par le L1.
- Le Pont (Bridge) : Le "pont" est un **Smart Contract** (sur L1).
- Mécanisme de Sécurité : Les Rollups (Optimistic ou ZK) **publient les données de transaction (Calldata)** ou les **preuves (Validity Proofs)** sur le L1.
- Conséquence (La Plus Importante) :
- Si le "Sequencer" (l'opérateur) du L2 devient malveillant (censure, vol), la communauté peut (en théorie) **forcer la sortie (Forced Exit)** de ses fonds.
- N'importe qui peut utiliser les *données* publiées sur L1 pour **reconstruire l'état** du L2 et **prouver la fraude** (Optimistic) ou **prouver la validité** (ZK).
- Le L1 (Ethereum) est l'**arbitre final** de la validité de l'état du L2.
- Niveau de Confiance : Vous ne faites confiance qu'à la **cryptographie** (ZK) ou à la **théorie des jeux** (Optimistic) et à la **sécurité du L1 (Ethereum)**.
2. Sidechain (Chaîne Latérale) - Sécurité Propre
- Exemples : Polygon PoS, Gnosis Chain (xDAI), Ronin (Axie).
- Définition : Une Sidechain est une **blockchain indépendante** qui a son *propre* consensus (ex: PoS, PoA) et qui est simplement *connectée* à Ethereum par un "pont" (bridge).
- Le Pont (Bridge) : Le "pont" est un **Smart Contract Multi-Sig** (Multi-Signatures). (Ex: un contrat contrôlé par 5 clés sur 8).
- Mécanisme de Sécurité :
- Pour "passer" 100 ETH du L1 à la Sidechain :
- 1. Vous déposez 100 ETH dans le contrat "Bridge" sur L1 (Ethereum).
- 2. Les 5/8 validateurs de la Sidechain voient ce dépôt.
- 3. Ils "signent" un message, et le contrat de la Sidechain "minte" (crée) 100 "ETH-wrapper" sur la Sidechain.
- Le Problème (Risque de Pont) :
- La sécurité de la Sidechain est **indépendante** de celle d'Ethereum.
- Si les 5/8 validateurs de la Sidechain sont malveillants ou hackés, ils peuvent **voler** tous les ETH (des milliards) bloqués dans le contrat Bridge sur L1, en signant une fausse transaction de retrait.
- Ethereum L1 ne peut RIEN FAIRE. Il ne valide pas l'état de la Sidechain. Il ne fait que *confiance* aux 5/8 signataires du pont.
- (C'est ainsi que le pont Ronin a été hacké pour 600M$).
- Niveau de Confiance : Vous devez faire confiance à la **sécurité du consensus de la Sidechain** (ex: les validateurs de Polygon PoS) ET à la **sécurité du pont**.
Les **Optimistic Rollups (ORUs)** (Arbitrum, Optimism) sont la première solution L2 mature. Leur philosophie est "Innocent jusqu'à preuve du contraire".
Principe : "Nous exécutons des milliers de transactions off-chain (L2), et nous **supposons ("optimistement")** que ces transactions sont valides. Nous postons le résultat sur L1 sans preuve, et nous donnons 7 jours à quiconque pour **prouver (s'il y en a une) la fraude**."
1. Le Flux de Transaction (Le "Sequencer")
L'opérateur principal d'un L2 est le **"Sequencer" (Séquenceur)**. C'est (actuellement) un serveur centralisé géré par l'équipe (ex: Arbitrum Foundation, Optimism Foundation).
- 1. Réception (L2) : Vous (sur le réseau L2) envoyez votre transaction (ex: 1 swap Uniswap) au Sequencer.
- 2. Ordonnancement (L2) : Le Sequencer reçoit 1000 transactions. Il les ordonne (c'est son pouvoir centralisé) et les exécute. Il vous donne une "confirmation" instantanée (soft confirmation).
- 3. "Rollup" (L2 -> L1) : Toutes les 5-10 minutes, le Sequencer compresse ces 1000 transactions.
- 4. Ancrage (L1 - Le Coût) : Le Sequencer effectue une seule transaction L1. Il poste :
- Le "Batch" (
calldata) : La *totalité* des 1000 transactions (compressées) est postée dans le champ `calldata` de la transaction L1. C'est la garantie de **Data Availability (Disponibilité des Données)**. C'est ce qui coûte cher. - Le "State Root" (La Promesse) : Il poste le nouveau "Merkle Root" de l'état du L2. (Ex: "Après ces 1000 txs, l'état du L2 est
0xABC...").
- Le "Batch" (
2. La "Fraud Proof" (Le Système de Justice)
Le Sequencer a posté son "State Root" (`0xABC...`). Le L1 (Ethereum) ne le vérifie pas. Il le "note" et démarre un **"Challenge Period" (Période de Défi)** d'environ **7 jours**.
Le Rôle du "Verifier" (Vérificateur)
Pendant ces 7 jours, n'importe quel **Nœud L2 "Full Node"** (les "Verifiers", qui peuvent être vous, moi, ou un autre protocole) fait le travail suivant :
- Il lit le `calldata` (les 1000 txs) posté sur L1.
- Il ré-exécute *lui-même* ces 1000 transactions sur son nœud local.
- Il calcule son *propre* "State Root" (ex: `0xDEF...`).
- Il compare : Mon calcul (`0xDEF...`) est-il égal à celui du Sequencer (`0xABC...`) ?
Scénario de Fraude (Le Défi)
- Cas A (Honnête) : `0xDEF...` == `0xABC...`. Le Verifier ne fait rien. Après 7 jours, le "State Root" `0xABC...` est considéré comme **finalisé** par L1.
- Cas B (Fraude !) : `0xDEF...` != `0xABC...`. Le Sequencer a menti (ex: il s'est attribué 1000 ETH).
- Action : Le Verifier initie un "Défi" (Challenge) on-chain sur L1.
- Résolution : Le Verifier soumet une **"Fraud Proof"** au L1. Le L1 (via un smart contract) **ré-exécute** la (ou les) transaction(s) litigieuse(s) *on-chain*.
- Jugement : L1 (la "Cour Suprême") voit que le calcul du Verifier (`0xDEF...`) était le bon.
- Pénalité ("Slashing") : Le "State Root" `0xABC...` est rejeté. Le "Stake" (la caution) du Sequencer malveillant est **slashé** (détruit) et une partie est donnée au Verifier en récompense.
Arbitrum (Offchain Labs) et Optimism (Optimism Collective) sont les deux principaux ORUs. Ils partagent la même philosophie "Optimistic", mais leur implémentation technique (surtout la "Fraud Proof") et leur stratégie d'écosystème diffèrent.
Comparaison Technique (Surtout : La Preuve de Fraude)
Optimism (Avant "Cannon")
- Implémentation : Non-interactive (Single-Round) Fraud Proof.
- Mécanisme de Défi : Si un Verifier conteste un "State Root", le contrat sur L1 (Ethereum) doit **ré-exécuter l'intégralité du "batch" de transactions (les milliers de txs)**.
- Coût : Extrêmement cher en Gas (sur L1). La transaction de "challenge" peut coûter des millions de dollars de Gas.
- Problème : Cela crée une incitation économique négative. Si le challenge coûte plus cher (en Gas) que le montant de la fraude, personne ne le fera.
- VM : OVM (Optimistic Virtual Machine) - une version modifiée de l'EVM (historique).
Arbitrum (Nitro)
- Implémentation : **Multi-Round Interactive Fraud Proof (Le "Jeu de la Bisection")**.
- Mécanisme de Défi : C'est la différence clé.
- Challenger : "Ton State Root est faux."
- Sequencer : "Non, il est juste."
- Contrat (L1) : "Ok, jouez au 'jeu de la bisection' (off-chain). Le batch avait 10 000 étapes. Mettez-vous d'accord sur l'étape #5000."
- Challenger : "Le problème est *après* l'étape 5000."
- Contrat (L1) : "Ok, regardez l'étape #7500."
- ... Ce "jeu" (ping-pong off-chain) continue jusqu'à ce qu'ils isolent la **seule instruction (Opcode) en litige** (ex: "un
ADDà l'étape #6152"). - Résolution : Le contrat L1 n'a plus qu'à **exécuter CETTE SEULE INSTRUCTION** (un
ADD) pour déterminer qui a menti.
- Coût : Le "challenge" on-chain est **extrêmement peu coûteux** (le coût d'un
ADD), ce qui rend la sécurité beaucoup plus robuste. - VM : **WASM**. Arbitrum Nitro compile le code de Geth (le client Ethereum) directement en WASM, ce qui le rend **EVM-compatible** au niveau du bytecode (pas besoin de ré-écrire un "compilateur Solidity").
Comparaison (Écosystème & Stratégie)
| Critère | Optimism ($OP) | Arbitrum ($ARB) |
|---|---|---|
| Preuve de Fraude | Single-Round (Historiquement OVM, maintenant "Cannon") | Multi-Round Interactive (Jeu de Bisection) (Considéré comme plus robuste) |
| VM | EVM (via le compilateur Solidity modifié) | Nitro (Geth compilé en WASM) (Plus compatible au niveau du bytecode) |
| Séquenceur | Centralisé (OP Labs) | Centralisé (Offchain Labs) |
| Philosophie | Bien Public & Hyper-Scalabilité. L'accent est mis sur le **"OP Stack"**. | Pragmatisme & Sécurité. L'accent est mis sur la technologie (Nitro) et l'adoption par les DApps. |
| Le "Stack" (L2-as-a-Service) | OP Stack : Un "Wordpress pour L2s". Un kit de développement open-source pour lancer son *propre* L2 Optimistic (ex: Base (par Coinbase), Zora). | Arbitrum Orbit : La réponse d'Arbitrum à l'OP Stack. Permet de lancer des L2 ou L3. |
| Vision Future | La **"Superchain"**. Une vision où tous les L2 (Base, Zora, OP) sont interconnectés et partagent le Séquençage. | Développement de Stylus (permettant d'écrire des contrats en Rust/C++ sur Arbitrum). |
Les **ZK-Rollups (Zero-Knowledge Rollups)** sont la "deuxième génération" de L2. Leur philosophie est "Ne faites pas confiance, vérifiez" ("Don't Trust, Verify").
Principe : "J'exécute 10 000 transactions off-chain (L2). Je ne vous demande pas de me croire sur parole (Optimistic). Je vous fournis une **Preuve Cryptographique (Validity Proof)** que vous (le L1) pouvez vérifier mathématiquement en quelques millisecondes. Cette preuve *prouve* que les 10 000 transactions étaient valides."
1. Le Flux de Transaction (Le "Prover" & "Verifier")
- 1. Réception (L2) : L'utilisateur envoie sa transaction au **Sequencer** ZK (similaire à l'ORU).
- 2. Ordonnancement (L2) : Le Sequencer exécute 10 000 transactions.
- 3. Génération de la Preuve (L2 - Le "Prover") :
- C'est l'étape la plus intensive. Le Sequencer (ou un acteur spécialisé, le **Prover**) utilise un matériel extrêmement puissant (GPUs, ASICs) pour exécuter un algorithme cryptographique complexe (SNARK ou STARK).
- Cet algorithme "compresse" l'exécution des 10 000 txs en une **seule, petite "Preuve de Validité" (Validity Proof)**.
- 4. Ancrage (L1) : Le Sequencer effectue une seule transaction L1, qui poste :
- Le "State Diff" : Juste le *résultat* (les changements d'état), pas les transactions elles-mêmes (optionnel, voir 4.1).
- La Preuve (Validity Proof) : La preuve cryptographique (ex: 20 Ko).
- 5. Vérification (L1 - Le "Verifier") :
- Un **Smart Contract "Verifier"** (déployé sur L1) reçoit cette preuve.
- Il exécute l'algorithme de vérification. C'est *extrêmement* rapide et peu coûteux (ex: 200 000 Gas).
- Si la preuve est mathématiquement valide : Le L1 accepte le nouveau "State Root" instantanément.
- Si la preuve est invalide : Le L1 rejette la transaction.
2. ZK-SNARKs vs ZK-STARKs
"Zero-Knowledge" (Connaissance Nulle) est le concept. SNARK et STARK sont les deux *familles d'implémentation* (algorithmes) de cette preuve.
| Critère | ZK-SNARK (Succinct Non-Interactive...) | ZK-STARK (Scalable Transparent...) |
|---|---|---|
| Exemples de Protocoles | zkSync, Polygon zkEVM, Zcash | Starknet (StarkWare), Polygon Miden |
| "Trusted Setup" (Mise en Place de Confiance) | Oui. Nécessite une "cérémonie" (ex: "Ignition") pour générer les paramètres cryptographiques (le "toxic waste"). Si cette cérémonie est compromise, l'attaquant peut créer de fausses preuves (et voler des fonds). | Non (Transparent). N'utilise que des fonctions de hachage publiques. Pas de "toxic waste". Considéré comme plus sûr. |
| Taille de la Preuve | Très Petite (Succinct). ~20-30 Ko. Très peu cher à vérifier sur L1. | Grande (Scalable). ~100-200 Ko. Plus cher à vérifier sur L1 (mais s'amortit mieux à très grande échelle). |
| Génération de la Preuve | Intensive (rapide). | Très intensive (lente). |
| Résistance Quantique | Non. Vulnérable aux ordinateurs quantiques (basé sur la cryptographie à courbe elliptique). | Oui. Basé sur la résistance aux collisions (hachage), qui est considéré comme "quantum-resistant". |
L'écosystème ZK est en pleine "guerre de standards". Le défi n'est pas seulement de *créer* des preuves, mais de le faire d'une manière qui soit **compatible avec l'EVM** (la machine virtuelle d'Ethereum), afin que les DApps (Uniswap, Aave) puissent s'y déployer sans tout réécrire.
1. Le Défi : Qu'est-ce qu'un "zkEVM" ?
Problème : L'EVM (la machine virtuelle d'Ethereum) n'a **pas** été conçue pour être "ZK-friendly". Ses "Opcodes" (instructions) sont très difficiles à *prouver* (cryptographiquement). Il est beaucoup plus facile de "prouver" un langage simple (comme Cairo).
Un **"zkEVM"** est un L2 qui tente de **recréer l'environnement EVM** et de **générer des preuves de validité ZK** pour cette exécution EVM.
C'est le "Saint Graal" du scaling, car il offre :
- La sécurité cryptographique (ZK)
- Les retraits instantanés (ZK)
- La compatibilité avec le code (Solidity) et les outils (Metamask, Hardhat) existants.
Les 5 "Types" de zkEVM (par Vitalik)
Il y a un spectre de compatibilité :
- Type 1 (Équivalence Parfaite) : (Le Rêve). Prouve l'EVM tel quel. (Ex: Polygon Hermez "Type 1"). Extrêmement lent à prouver.
- Type 2/2.5 (Équivalence EVM) : (Le "Sweet Spot"). (Ex: **zkSync**, **Polygon zkEVM**). Modifie *légèrement* l'EVM (ex: change le coût du Gas d'un Opcode) pour le rendre plus facile à prouver. 99% du code Solidity/Outils fonctionne.
- Type 3 (Compatibilité EVM) : (Ex: Scroll). Modifie *plusieurs* choses dans l'EVM. Le code Solidity doit être ré-audité.
- Type 4 (Compatibilité Langage) : (Ex: **Starknet**). **Pas compatible EVM du tout**. Le code (Solidity) est "transpilé" (traduit) dans un langage différent (Cairo), qui est ensuite exécuté dans une VM différente (la Cairo VM) et prouvé.
2. zkSync (Matter Labs)
- Type : zkEVM (Type 2.5/3).
- Preuve : **ZK-SNARK**. (Nécessite un "Trusted Setup", mais preuves plus petites/rapides à vérifier sur L1).
- Philosophie : L'objectif principal est la **Compatibilité EVM**. Ils veulent que l'écosystème Ethereum "copie/colle" ses DApps le plus facilement possible.
- Fonctionnalité (Unique) : **"Account Abstraction" (AA) Natif**. Le protocole (au niveau L2) considère *tous* les comptes (même les EOA) comme des "Smart Contracts". Cela permet des fonctionnalités natives (ex: payer le Gas avec de l'USDC, sessions, clés sociales) que l'EVM L1 ne peut pas faire.
3. Starknet (StarkWare)
- Type : zkVM (Type 4). **Non compatible EVM**.
- Preuve : **ZK-STARK**. (Pas de "Trusted Setup", résistant au quantique, mais preuves plus grosses/lentes).
- Philosophie : L'objectif principal est la **Performance & la Sécurité à long terme**. Ils ont abandonné la compatibilité EVM pour créer un écosystème *natif* au ZK.
- Langage : **Cairo**. Un nouveau langage (similaire à Rust) conçu de A à Z pour être "prouvable" (provable). Les développeurs *doivent* apprendre le Cairo pour construire sur Starknet (bien que des transpileurs comme "Kakarot" existent).
- StarkEx (Le Prédécesseur) : StarkWare (l'entreprise) a d'abord prouvé sa technologie avec **StarkEx**, un L2 "Validium" (voir 4.1) centralisé qui alimente des géants (dYdX, Sorare, Immutable X). Stark*net* est la version décentralisée.
La "roadmap" actuelle du scaling est passée d'une vision "monolithique" (tout faire sur L1) à une vision **"Modulaire"**. Une blockchain modulaire "dé-bundle" (sépare) les 3 tâches principales :
- Exécution (Execution) : Qui exécute les transactions ? (Ex: Le Sequencer d'Arbitrum).
- Consensus & Règlement (Settlement) : Qui arbitre les litiges et finalise l'état ? (Ex: Ethereum L1).
- Disponibilité des Données (Data Availability - DA) : Où sont *stockées* les données de transaction (le `calldata`) pour que les Verifiers puissent les vérifier ?
Le coût d'une transaction sur un L2 (ex: Arbitrum) est composé à 90-95% du coût de **stockage des données (Calldata)** sur le L1 (Ethereum). L'exécution (le "compute" L2) est déjà très peu chère. Pour rendre les L2 moins chers, il faut réduire le coût du stockage des données.
Le Spectre de la Disponibilité des Données (DA)
1. Rollup (Sécurité Max)
- Ex: Arbitrum, Optimism, zkSync.
- DA : **Ethereum L1 (Calldata)**.
- Avantage : Sécurité maximale. N'importe qui peut reconstruire l'état du L2 en lisant les données sur le L1.
- Inconvénient : **Extrêmement cher**. Vous payez le prix du "blockspace" L1.
2. Validium (Scalabilité Max)
- Ex: StarkEx (dYdX v3), Polygon Miden.
- Mécanisme : Un ZK-Rollup qui poste la **Preuve (Proof)** sur L1, mais qui poste les **Données (Data)** *ailleurs* (Off-Chain).
- DA : **Comité DA (DAC - Data Availability Committee)**. Un petit groupe (ex: 8 acteurs de confiance) qui atteste : "Nous avons les données".
- Avantage : 100x moins cher (pas de coût de Calldata L1).
- Inconvénient : **Risque de Confiance.** Vous devez faire confiance au comité (DAC). S'ils décident de "geler" (retenir) les données, ils peuvent bloquer les fonds des utilisateurs.
2. La Solution Hybride : "Celestiums" (Le Rôle de Celestia)
**Celestia ($TIA)** est la première blockchain "Modulaire" L1. Elle est conçue pour ne faire **qu'une seule chose** : être une couche de **Data Availability (DA)** bon marché et décentralisée.
Elle n'a *pas* d'EVM, pas de smart contracts. Elle ne fait que *stocker* des données et prouver (via "Data Availability Sampling") qu'elles sont disponibles.
L'Architecture "Celestium"
C'est le "meilleur" des deux mondes (Rollup + Validium).
- Exécution : Le L2 (ex: Arbitrum).
- Règlement (Settlement) : Le L1 (Ethereum). Le L2 poste ses **preuves** (Fraud ou ZK) sur Ethereum pour hériter de sa sécurité.
- Data Availability (DA) : Le L2 poste ses **données de transaction (Calldata)** sur **Celestia**.
**EIP-4844** (surnommé **"Proto-Danksharding"**, et au cœur de la mise à jour "Cancun-Deneb") est la **réponse officielle d'Ethereum** au problème du coût des L2. C'est la solution "monolithique" (intégrée) au problème de Data Availability.
Elle reconnaît que les L2 n'ont pas besoin que leurs données (calldata) soient stockées *éternellement* (comme le `SSTORE`) et exécutées par l'EVM. Ils ont juste besoin que les données soient **garanties d'être disponibles (DA)** pendant une courte période (ex: 1 mois) pour que les Verifiers puissent faire leur travail.
1. L'Introduction des "Blobs" de Données
L'EIP-4844 introduit un **nouveau type de transaction** (BlobCarryingTransaction) et un **nouvel espace de données** (le "Blobspace").
Avant EIP-4844 (Aujourd'hui)
Un Rollup (Arbitrum) poste ses données (le "batch") dans le champ calldata d'une transaction L1 normale. Il est en **concurrence directe** pour le "blockspace" (l'espace de bloc) avec tout le monde (les swaps Uniswap, les mints NFT). C'est pour cela que les frais L2 augmentent quand les frais L1 augmentent.
Après EIP-4844 (Le Futur)
Le Rollup utilise la nouvelle transaction "Blob" (ex: `PostBlobs`).
- Les "Blobs" (Binary Large Objects) : C'est un "side-car" (un conteneur attaché) à un bloc Ethereum. C'est un espace de stockage de données (ex: 128 Ko par Blob, 6 Blobs par bloc).
- Non-Accessible par l'EVM : Le point crucial. L'EVM (les smart contracts) **NE PEUT PAS LIRE** le contenu d'un Blob. Il peut seulement *prouver* (via un "hash") que le Blob existe.
- "Pruning" (Élagage) : Les Nœuds L1 (Consensus Clients) **suppriment (jettent)** les données des Blobs après une courte période (ex: 18 à 45 jours).
2. L'Impact : Un Nouveau Marché de Frais
L'EIP-4844 crée **deux marchés de frais distincts** sur Ethereum :
- Marché du "Gas" (EVM) : (L'actuel). Pour l'exécution (Swaps, Mints).
- Marché des "Blobs" (Données) : (Le nouveau). Un marché "offre/demande" *uniquement* pour le stockage de données L2.
Au lancement, ce nouveau "marché des blobs" sera presque vide. La concurrence sera faible.
Le coût pour les L2 (Arbitrum, Optimism) pour poster leurs données va **s'effondrer de 90% à 99%** du jour au lendemain (car ils n'achètent plus de "Gas" L1 cher, mais du "Blobspace" L1 bon marché).
Cette économie sera (en théorie) **directement répercutée** sur l'utilisateur final.
Résultat : Les frais de transaction sur Arbitrum/Optimism/zkSync passeront (potentiellement) de 0.20$ à 0.01$ (ou moins).
Note : "Proto-Danksharding" (EIP-4844) est la première étape. Le "Full Danksharding" (à venir) augmentera le nombre de blobs (ex: de 6 à 64 par bloc), rendant la scalabilité des L2 quasi-illimitée.