---
title: "Réseaux Layer 2"
description: "Guide propre à chaque déploiement sur l'exécution, la disponibilité des données, la validation de l'état, le règlement, la finalité, les séquenceurs, la gouvernance, les bridges, les frais et les sorties exécutables des Layer 2."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Réseaux Layer 2

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## Réponse directe

Une Layer 2 est un protocole qui exécute ou coordonne des activités hors d'une chaîne de base tout en s'appuyant sur celle-ci pour une partie définie de la validation, de la disponibilité des données, du règlement ou de l'exécution des sorties. Cette appellation n'est pas une norme universelle. Un rollup qui publie suffisamment de données et impose les transitions d'état au moyen de fault proofs ou de preuves de validité repose sur des hypothèses de confiance différentes de celles d'un validium, d'un state channel, d'une sidechain, d'un bridge multisignature ou du registre d'une plateforme d'échange, même si tous se présentent comme des L2.

Pour un déploiement précis, il faut déterminer ce que le contrat L1 accepte réellement, où résident les données de dérivation, qui ordonne les transactions, comment un état invalide est rejeté, quand un bloc devient safe ou finalized, qui peut mettre à niveau ou suspendre le système et si un utilisateur peut sortir sans l'opérateur. Des confirmations plus rapides et des frais inférieurs sont utiles, mais n'établissent pas à eux seuls une sécurité héritée.

<a id="mechanism"></a>

## Fonctionnement

1. Fixez l'identité du système : chain IDs L1 et L2, genèse et fork, stack et version du rollup, contrats de règlement et de bridge, implémentations des proxies, type de preuve ou de jeu de contestation, mode de disponibilité des données, séquenceur et références de blocs. Considérez le nom du site et le terme L2 comme des métadonnées de découverte, non comme une authentification.
2. Classez l'architecture sur des axes distincts. Consignez l'environnement d'exécution, le modèle d'ordonnancement, le mécanisme de validation de l'état, l'emplacement des données, la chaîne de règlement et le parcours de conservation. Optimistic rollups, validity rollups, validiums, channels et sidechains combinent ces axes différemment ; un moteur compatible EVM n'égalise pas leur sécurité.
3. Reconstituez le pipeline d'état. Suivez la soumission par l'utilisateur, l'ordonnancement du séquenceur, l'exécution L2, l'encodage du batch, la publication des données, l'engagement d'état, la contestation par fault proof ou la vérification d'une preuve de validité, l'inclusion L1 et la finalité L1. Vérifiez qu'un logiciel indépendant peut dériver l'état L2 revendiqué à partir des entrées définies par le protocole.
4. Séparez disponibilité et liveness. Déterminez si les données se trouvent dans les calldata ou blobs L1, un système DA externe ou un comité ; identifiez les hypothèses de conservation et de récupération. Testez la panne du séquenceur, l'inclusion forcée, la soumission alternative, la défaillance du proposer ou prover, le relais des messages et le parcours exact de sortie ou de retrait.
5. Séparez les horloges et les libellés d'état. Un bloc confirmé par le séquenceur ou unsafe peut précéder la publication des données ; un bloc safe peut précéder la finalité L1 ; l'acceptation d'une preuve, la résolution d'une contestation, la maturation d'un retrait et le déblocage par le bridge peuvent ajouter des étapes indépendantes. Utilisez les définitions du déploiement plutôt qu'un nombre universel de confirmations ou une règle fixe de sept jours.
6. Cartographiez contrôle et économie. Examinez les administrateurs des proxies, délais de mise à niveau, pouvoirs du security council et du guardian, état de suspension, coefficients de frais, token de gas, capacité des batchs et destinataires des frais. Tenez des registres séparés pour l'exécution L2, la publication L1 ou DA, les frais d'opérateur, les frais de bridge, le gas de destination et le coût d'attente ; une cotation ne garantit pas l'exécution.
7. Rapprochez les résultats de l'utilisateur. Vérifiez le contrat et la représentation exacts du token, le débit à la source, le crédit à destination, le statut du reçu, les racines d'état et de message, les hashes de blocs safe et finalized, les autorisations restantes et un remboursement ou une sortie de marché exécutable. Revérifiez la configuration après chaque mise à niveau et ne déduisez pas la sécurité du bridge du système de preuves du rollup.

<a id="example"></a>

## Exemples détaillés

- **Économie du batch.** Un batch contient `2,000` transactions d'une taille moyenne de `160 bytes` après compression, plus `20,000 bytes` de framing fixe, soit `340,000 bytes`. À `$0.00002/byte`, les données coûtent `$6.80` ; l'ajout de `$4.00` de coût fixe de preuve et de règlement porte le total à `$10.80`, soit `$0.0054/transaction`. Avec seulement `200` transactions, les mêmes hypothèses donnent `52,000 bytes`, `$1.04` de coût de données et `$5.04` au total, soit `$0.0252/transaction`. Le batching ne réduit le coût moyen que selon les hypothèses indiquées de taille, d'utilisation et de frais.
- **Capacité et débit réalisé.** Une L2 hypothétique autorise `60,000,000 gas` toutes les `2 seconds`, soit une capacité de `30,000,000 gas/second`. À `120,000 gas` par opération utilisateur, le plafond mécanique est de `250 operations/second` ; avec un taux d'utilisation réalisé de `72%`, il est de `180 operations/second`. Il ne s'agit ni de finalité, ni de décentralisation, ni de débit de bout en bout ; les limites liées aux données, aux preuves ou au séquenceur peuvent être atteintes en premier.
- **Trois horloges de statut et une étape de retrait.** Dans une chronologie pédagogique de type OP, une transaction est confirmée par le séquenceur à `12:00 UTC`, son batch devient safe après sa publication sur L1 à `12:07`, et le bloc L1 qui la contient devient finalized à `12:20`. Si un retrait par bridge est prouvé à `14:00` et présente une maturation illustrative de `7-day`, le premier déblocage intervient la semaine suivante à `14:00`, sous réserve du jeu de contestation, des suspensions et des conditions L1. La finalité de la transaction L2 à `12:20` n'est pas le même événement que le déblocage par le bridge.
- **Valeur exécutable après passage par un bridge.** Un utilisateur dépose `1,000 USDC` ; des frais de protocole de `2 USDC` laissent `998 USDC` sur L2, tandis que le gas sur la chaîne source coûte séparément `$7.50`. Le token reçu présente un bid exécutable de `$0.995`, un impact de prix de `0.20%` et un gas de sortie de `$3` ; sa valeur nette de sortie est donc `998 * 0.995 * (1 - 0.002) - 3 = $988.02398`. Par rapport à `$1,000`, l'écart est de `$11.97602`, soit `1.197602%` ; l'identité du token, la créance sur le bridge et la liquidité comptent au-delà de l'appellation L2.

<a id="risks"></a>

## Risques

- Utiliser une L1, une L2, un chain ID, un déploiement, un fork ou une version de protocole erronés.
- Traiter une appellation commerciale L2 comme une classification de sécurité normalisée.
- Confondre une sidechain, un validium, un channel ou un registre custodial avec un rollup.
- Accepter un RPC, explorateur, bridge, token ou une adresse de contrat contrefaits.
- Censure, équivoque, panne ou abus d'ordonnancement privé par le séquenceur.
- Données de batch et de dérivation absentes ou retardées.
- Rétention, défaillance ou collusion d'un système DA externe ou d'un comité.
- Engagements d'état invalides ou bug du système de preuves, du jeu ou du verifier.
- Défaillance de liveness du proposer, prover, challenger ou relayer.
- Congestion, censure, réorganisation ou finalité retardée de L1.
- Confusion entre les états unsafe, safe, finalized, proven et withdrawable.
- Parcours d'inclusion forcée ou de sortie suspendus, coûteux ou inutilisables.
- Mises à niveau immédiates des proxies ou fenêtres de sortie insuffisantes.
- Compromission des clés de l'administrateur, du guardian ou du security council.
- Défaillance de l'escrow du bridge, du mapping du token, des décimales ou de la représentation.
- Omission des frais de données, d'exécution, d'opérateur, de bridge ou de destination dans les cotations.
- Limites de capacité ou de fréquence, congestion, slippage ou pénurie du token de gas.
- Confusion entre compatibilité EVM et règles identiques d'opcodes, de précompilés ou de sécurité.
- Messages entre L2 combinant des hypothèses plus faibles de finalité, de bridge ou de dépendance.
- Confusion entre succès du wallet, TPS élevé ou faibles frais et sécurité ou finalité économique.

<a id="misconceptions"></a>

## Idées reçues

- Tout réseau appelé Layer 2 hérite de toute la sécurité d'Ethereum.
- Une confirmation du séquenceur équivaut à une finalité garantie par L1.
- Les preuves de validité ou fault proofs résolvent automatiquement disponibilité des données et censure.
- Le système de preuves du rollup garantit également chaque token transféré par bridge et chaque application.
- Des frais inférieurs ou un TPS supérieur prouvent décentralisation, solvabilité et sortie exécutable.

<a id="related"></a>

## Sujets connexes

- [Rollups](/fr/crypto/rollup/)
- [Disponibilité des données](/fr/crypto/data-availability/)
- [Sorties de secours des rollups](/fr/crypto/rollup-escape-hatch/)

<a id="sources"></a>

## Sources

- [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (consulté le : 2026-08-12)
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consulté le : 2026-08-12)
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consulté le : 2026-08-12)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consulté le : 2026-08-12)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulté le : 2026-08-12)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (consulté le : 2026-08-12)
- [Transaction finality](https://docs.optimism.io/op-stack/transactions/transaction-finality) - Optimism Documentation (consulté le : 2026-08-12)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (consulté le : 2026-08-12)

Source: https://wiki.fcontext.com/fr/crypto/layer2/index.mdx