---
title: "Canaux d’état"
description: "Les canaux d’état permettent à des participants fixes d’échanger des états signés hors chaîne tout en gardant un recours on-chain pour imposer le dernier résultat valide."
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.
# Canaux d’état
> À des fins éducatives uniquement ; ceci ne constitue aucun conseil en investissement ou en sécurité. Les fonds peuvent être perdus si les clés, l’état récent, la surveillance ou la capacité de répondre on-chain sont indisponibles.
## Réponse directe
Un canal d’état est un protocole où des participants fixes verrouillent des actifs ou établissent des règles exécutoires sur une blockchain, puis échangent hors chaîne des mises à jour authentifiées. La blockchain ne traite pas chacune d’elles : elle arbitre en dernier ressort lors de la fermeture ou d’un désaccord.
Chaque mise à jour engage le canal, l’état ou l’allocation de l’application et une valeur d’ordre croissante, telle qu’un tour ou nonce. Selon les règles, le nouvel état valide remplace l’ancien. Un canal de paiement suit surtout les soldes ; un canal général peut aussi représenter parties de jeu, transactions ou autres données déterministes.
Faible latence, confidentialité partielle face à l’historique public et absence de frais de couche de base par mise à jour sont possibles. Mais participants et capital sont généralement fixes, chacun doit conserver la preuve d’exécution et la chaîne de base doit rester disponible et abordable en cas de litige.
## Fonctionnement
1. **Ouvrir et financer.** Les parties conviennent des identités, règles, durée de contestation et allocation initiale. Les fonds sont verrouillés dans un arbitre on-chain ou proviennent d’un canal financé ; ils ne sont alors plus un solde ordinaire.
2. **Échanger les états signés.** Elles calculent l’état valide suivant et échangent signatures ou messages nécessaires. L’identifiant unique et l’ordre croissant empêchent de substituer une signature d’un autre canal ou d’un tour ancien.
3. **Conserver le dossier d’exécution.** Le portefeuille garde dernier état, signatures, transferts conditionnels et secrets ou données de révocation requis. Une phrase de récupération restaure parfois les clés, pas forcément ces données évolutives.
4. **Continuer hors chaîne.** De nombreuses mises à jour n’utilisent aucune transaction de base. La capacité limite l’envoi à l’allocation et aux réserves dans cette direction ; chaque saut d’un itinéraire ajoute des dépendances de liquidité et de disponibilité.
5. **Fermer conjointement.** Les parties signent le résultat final et soumettent la transaction minimale. Cette voie évite généralement la course de contestation et règle plus vite ou moins cher qu’une fermeture unilatérale.
6. **Porter le litige on-chain.** Si un participant disparaît ou présente un état périmé, un autre fournit une preuve exécutoire. L’arbitre applique ordre, délais et transitions. Certains systèmes opposent un état récent à l’ancien ; Lightning emploie engagements et révocations plutôt qu’une course générique au nonce maximal.
7. **Finaliser après échéance.** Après contestation ou timelock, le résultat est réclamé. Jusqu’à résolution de toutes les sorties, il peut falloir surveiller les réorganisations et augmenter les frais des transactions urgentes.
## Exemple
Alice et Bob ouvrent un canal bilatéral avec `5 ETH` chacun, soit `10 ETH`. L’état d’ouverture signé est le tour `0` : Alice reçoit `5 ETH` et Bob reçoit `5 ETH` au règlement.
Alice paie `1 ETH` à Bob. Ils valident et signent le tour `1`, attribuant `4 ETH` à Alice et `6 ETH` à Bob. Puis Bob paie `2 ETH` à Alice ; le tour `2` attribue `6 ETH` à Alice et `4 ETH` à Bob. En coopération, seuls financement et règlement final atteignent la chaîne de base.
Si Bob soumet ensuite le tour `1`, dans un système au tour maximal Alice doit produire le tour `2` entièrement soutenu avant l’échéance. Le contrat rejette alors l’ancien et règle le tour `2`. Si elle a perdu le tour `2`, n’accède plus à sa clé, n’a pas l’actif nécessaire aux frais ou reste hors ligne trop longtemps, le protocole ne peut deviner l’historique privé. Le résultat exécutoire peut différer du dernier accord.
Cet exemple est conceptuel. Les protocoles réels définissent précisément signatures, transitions, paiements conditionnels, appels et délais. Ne transférez pas de fonds sur cette seule arithmétique simplifiée.
## Risques et contrôles
- **Règlement périmé.** Conservez le dossier complet le plus récent et testez sa restauration. Comprenez données et pouvoirs avant toute tour de garde.
- **Délai manqué.** Surveillez la bonne chaîne jusqu’à résolution, avec une marge réaliste pour panne, réorganisation, congestion et intervention humaine.
- **Frais et congestion.** Gardez un actif de base libre et un moyen d’augmenter les frais. Des litiges simultanés peuvent renchérir une sortie urgente.
- **Perte de clé ou d’état.** Suivez la sauvegarde documentée. Ne restaurez pas un canal actif depuis un ancien instantané sans garantie explicite.
- **Capacité ou routage.** Vérifiez liquidités entrante et sortante, réserves, plafonds, expirations et intermédiaires. Le solde total n’est pas la capacité disponible.
- **Contrepartie et disponibilité.** Elle ne peut normalement réécrire un résultat protégé, mais peut refuser mise à jour ou fermeture conjointe et forcer le litige lent.
- **Implémentation.** Bugs du client, arbitre, domaine de signature, transitions ou mises à niveau peuvent annuler les garanties. Vérifiez déploiement et audits.
- **Fuite de confidentialité.** Hors chaîne ne signifie pas anonyme : pairs, routeurs, observateurs, sauvegardes et litige final peuvent révéler liens ou données.
## Idées reçues
- **« Hors chaîne signifie sans confiance ni blockchain. »** Le recours on-chain crédible limite la confiance ; sa sécurité, disponibilité et son coût restent essentiels.
- **« Tout état signé par les deux parties sera réglé. »** Ordre, validité, finalité, révocation et délais du protocole déterminent la preuve exécutoire.
- **« La phrase de récupération restaure tout le canal. »** Elle restaure généralement les clés, pas forcément état récent, secrets, transferts en attente ou base des pairs.
- **« On peut rester hors ligne indéfiniment. »** Beaucoup de systèmes exigent observation et réponse dans un délai, directement ou par service délégué.
- **« La capacité égale le solde du portefeuille. »** Les fonds doivent être engagés et la capacité dépend du sens, des réserves, des attentes et de la liquidité de route.
- **« Les canaux remplacent toujours les rollups. »** Ils conviennent aux interactions répétées entre parties connues ; adhésion ouverte, état global et forte composabilité favorisent parfois les rollups ou l’on-chain.
## Sujets associés
- [Frais de gas](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [Couche 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [Contrat intelligent](/crypto/smart-contract/)
## Sources
- [Réseaux généraux de canaux d’état](https://doi.org/10.1145/3243734.3243856) - ACM (consulté le 2026-08-21)
- [Protocole Nitro](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive (consulté le 2026-08-21)
- [États et canaux](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels (consulté le 2026-08-21)
- [BOLT #2 : protocole pair-à-pair de gestion des canaux](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications (consulté le 2026-08-21)
- [BOLT #5 : traitement des transactions on-chain](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications (consulté le 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/state-channels/index.mdx