La vision future de la blockchain est la décentralisation, la sécurité et l'évolutivité, mais il est souvent possible d'en réaliser seulement deux, ce qui est connu sous le nom de problème du triangle impossible de la blockchain. Depuis des années, les gens explorent comment résoudre ce dilemme, comment améliorer le débit et la vitesse des transactions de la blockchain tout en garantissant la décentralisation et la sécurité, c'est-à-dire résoudre le problème de l'évolutivité, qui est l'un des sujets brûlants dans le processus de développement actuel de la blockchain.
La décentralisation, la sécurité et l'évolutivité de la blockchain sont définies comme suit :
Décentralisation : Toute personne peut devenir un nœud participant à la production et à la vérification du système blockchain. Plus le nombre de nœuds est élevé, plus le degré de décentralisation est important, garantissant ainsi que le réseau n'est pas contrôlé par un petit groupe de grands participants centralisés.
Sécurité : Plus le coût pour obtenir le contrôle du système blockchain est élevé, plus la sécurité est élevée, alors la chaîne peut résister à un plus grand pourcentage d'attaques de participants.
Scalabilité : La capacité de la blockchain à traiter un grand nombre de transactions.
La première grande bifurcation dure du réseau Bitcoin est née du problème de l'extension. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions de Bitcoin, le réseau Bitcoin, dont la taille maximale des blocs est de 1 Mo, a commencé à faire face à des problèmes de congestion; à partir de 2015, la communauté Bitcoin a eu des divergences sur le problème de l'extension, d'un côté se trouvait le camp des pro-extension représenté par Bitcoin ABC, qui soutenait l'augmentation de la taille des blocs, et de l'autre côté se trouvait le camp des petits blocs représenté par Bitcoin Core, qui pensait qu'il fallait utiliser la solution Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, le système client développé par Bitcoin ABC jusqu'à 8 Mo a commencé à fonctionner, ce qui a conduit à la première grande bifurcation dure dans l'histoire de Bitcoin, donnant également naissance à la nouvelle cryptomonnaie BCH.
De même, le réseau Ethereum a également choisi de sacrifier une partie de l'évolutivité pour garantir la sécurité et la décentralisation du réseau ; bien que le réseau Ethereum ne limite pas le volume des transactions en restreignant la taille des blocs comme le fait le réseau Bitcoin, il a en quelque sorte évolué vers un plafond sur les frais de gaz pouvant être contenus dans un bloc unique, mais l'objectif reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds. ( Que ce soit pour annuler ou augmenter les limites, cela éliminera de nombreux nœuds plus petits qui manquent de bande passante, de stockage et de puissance de calcul. ).
Depuis le CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure des applications on-chain telles que GameFi et NFT, la demande du marché en matière de débit ne cesse d'augmenter. Cependant, même Ethereum, qui est Turing-complet, ne peut traiter que 15 à 45 transactions par seconde ( TPS ), ce qui entraîne une augmentation des coûts de transaction, un allongement des temps de règlement, et la plupart des Dapps ont du mal à supporter les coûts d'exploitation. L'ensemble du réseau devient également lent et coûteux pour les utilisateurs, et le problème de l'évolutivité de la blockchain doit être résolu. L'idéal en matière de solution d'évolutivité est d'augmenter la vitesse des transactions du réseau blockchain ( un temps de finalité ) plus court et un débit de transactions ( un TPS ) plus élevé, sans sacrifier la décentralisation et la sécurité.
2. Catégories des solutions d'extensibilité
Nous avons classé les solutions d'extension en deux catégories principales : l'extension on-chain et l'extension off-chain, en nous basant sur le critère "s'il y a un changement de la couche principale du réseau".
2.1 Scalabilité on-chain
Concept clé : une solution visant à atteindre un effet d'extensibilité en modifiant un niveau de protocole de la chaîne principale, la principale solution actuelle étant le sharding.
Il existe plusieurs solutions pour l'extension on-chain, cet article ne s'étendra pas, voici un bref aperçu de deux solutions :
La première solution consiste à élargir l'espace de bloc, c'est-à-dire à augmenter le nombre de transactions emballées dans chaque bloc, mais cela augmentera les exigences en matière de matériel des nœuds à haute performance, augmentant ainsi le seuil d'entrée pour les nœuds et réduisant le degré de "décentralisation".
La solution deux est le sharding, qui divise le livre de la blockchain en plusieurs parties, chaque nœud ne participant plus à tous les enregistrements, mais différents shards, c'est-à-dire différents nœuds, étant responsables de différents enregistrements. Le calcul parallèle peut traiter plusieurs transactions simultanément; cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, améliorant la vitesse de traitement des transactions et le degré de décentralisation; mais cela signifie que la puissance de calcul de l'ensemble du réseau est dispersée, ce qui peut réduire la "sécurité" de l'ensemble du réseau.
Modifier le code d'un protocole de réseau principal peut avoir des conséquences négatives imprévisibles, car même la plus petite faille de sécurité sous-jacente peut sérieusement menacer la sécurité de l'ensemble du réseau, qui pourrait être contraint de procéder à un fork ou à une interruption pour réparer une mise à jour. Par exemple, l'incident de faille d'inflation de Zcash en 2018 : le code de Zcash est basé sur une modification du code de Bitcoin version 0.11.2, en 2018, un ingénieur a découvert une faille critique dans le code sous-jacent, à savoir que les tokens pouvaient être émis de manière illimitée, et l'équipe a alors passé 8 mois à corriger secrètement la faille, ne rendant publique cette affaire qu'après la correction.
2.2 off-chain扩容
Concepts clés : solutions d'extensibilité qui ne modifient pas le protocole de la couche principale existante.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et autres solutions :
Les canaux d'état stipulent que les utilisateurs n'ont besoin d'interagir avec la chaîne principale que lors de l'ouverture, de la fermeture ou de la résolution des litiges du canal, et que les interactions entre utilisateurs se déroulent hors chaîne, afin de réduire le temps et le coût des transactions pour les utilisateurs, tout en permettant un nombre illimité de transactions.
Les canaux d'état sont un protocole P2P simple, adapté aux "applications basées sur des tours", par exemple, un jeu d'échecs à deux personnes. Chaque canal est géré par un contrat intelligent multi-signatures fonctionnant sur la chaîne principale, ce contrat contrôle les actifs déposés dans le canal, vérifie les mises à jour d'état et arbitre les litiges entre les participants ( selon la preuve de fraude avec signature et horodatage ). Après que les participants aient déployé le contrat sur le réseau blockchain, ils déposent une somme d'argent et la verrouillent, et après que les deux parties aient signé pour confirmer, le canal est officiellement ouvert. Le canal permet des transactions hors chaîne gratuites illimitées entre les participants ( tant que la valeur nette de leurs transferts ne dépasse pas le montant total des jetons déposés ). Les participants envoient tour à tour des mises à jour d'état à l'autre, attendant la confirmation de signature de l'autre partie. Une fois que l'autre partie a signé pour confirmer, cette mise à jour d'état est considérée comme terminée. En règle générale, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la chaîne principale, seules en cas de litige ou de fermeture du canal, une confirmation de la chaîne principale sera nécessaire. En cas de besoin de fermeture du canal, l'un des participants peut soumettre une demande de transaction sur la chaîne principale, si la demande de retrait obtient l'approbation par consensus de tous, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds bloqués restants en fonction du solde de chaque participant à l'état final du canal ; si d'autres participants n'ont pas approuvé la signature, alors tout le monde devra attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, la solution de canal d'état peut réduire considérablement la charge de calcul sur la chaîne principale, améliorer la vitesse des transactions et réduire les coûts des transactions.
3.1.2 Chronologie
En février 2015, Joseph Poon et Thaddeus Dryja ont publié un projet de livre blanc sur le réseau Lightning.
En novembre 2015, Jeff Coleman a d'abord résumé de manière systématique le concept de State Channel, en proposant que le Payment Channel de Bitcoin soit un sous-cas du concept de State Channel.
En janvier 2016, Joseph Poon et Thaddeus Dryja ont officiellement publié le livre blanc « The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments » proposant une solution d'évolutivité pour le réseau Bitcoin, le Payment Channel(, cette solution est uniquement destinée à traiter les paiements de transfert sur le réseau Bitcoin.
En novembre 2017, la première spécification de conception des State Channels basée sur le cadre Payment Channel, appelée Sprites, a été proposée.
En juin 2018, Counterfactual a proposé un design de Generalized State Channels très détaillé, qui est le premier design entièrement lié aux state channels.
En octobre 2018, l'article Generalised State Channel Networks a proposé les concepts de State Channel Networks et de Virtual Channels.
En février 2019, le concept de canaux d'état a été étendu aux canaux N-Party, Nitro est le premier protocole basé sur cette idée.
En octobre 2019, Pisa a élargi le concept de Watchtowers pour résoudre le problème de la nécessité pour tous les participants d'être en ligne en permanence.
Mars 2020, Hydra a proposé des Fast Isomorphic Channels.
)# 3.1.3 Principes techniques
Le flux de travail des canaux d'état est le suivant :
Alice et Bob déposent des fonds de leur EOA personnel dans l'adresse de contrat on-chain, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment auquel le solde est restitué à l'utilisateur ; après confirmation par signature, le canal d'état entre les deux est officiellement ouvert.
Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions off-chain via ce canal, les participants communiquant entre eux par des messages signés cryptés ### au lieu de communiquer avec le réseau blockchain (. Les deux utilisateurs doivent signer chaque transaction pour éviter les attaques de double dépense. Grâce à ces messages, ils proposent des mises à jour de l'état de leurs comptes et acceptent les mises à jour d'état proposées par l'autre.
Si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre l'état final de son compte au contrat. Si Bob signe pour approuver, le contrat libérera les fonds verrouillés et les renverra à l'utilisateur correspondant en fonction de l'état final. Si Bob ne répond pas à la signature, le contrat libérera les fonds verrouillés et les renverra à l'utilisateur correspondant à la fin de la période de contestation.
Si à un certain moment, Bob ne répond pas à la signature de mise à jour d'état envoyée par Alice dans son tour, Alice peut initier un défi en soumettant au contrat son dernier état valide, cet état valide contenant également la signature précédente de Bob, prouvant ainsi que la dernière transaction a déjà reçu l'approbation de Bob et que l'état final a été confirmé par Bob. Ensuite, le contrat permet à Bob de répondre en soumettant le prochain état au contrat pendant une période de temps; si Bob répond, les deux peuvent continuer à échanger dans le canal d'état; si Bob ne répond pas pendant cette période, le contrat ferme automatiquement le canal d'état et renvoie les fonds à Alice.
![Rapport d'étude approfondi : Analyse complète de l'expansion off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.4 Avantages et inconvénients
Avantages:
Instantanéité : les mises à jour de l'état sont presque instantanées, sans besoin d'attendre la confirmation de bloc.
Confidentialité : seul l'état final sera enregistré sur la chaîne, les états intermédiaires sont privés.
Scalabilité : théoriquement extensible à l'infini, tant que les fonds des participants sont suffisants.
Coût faible : les transactions off-chain ne nécessitent pas de frais de gas
Inconvénients:
Efficacité des fonds faible : nécessite de verrouiller des fonds
Exigences en ligne : les participants doivent surveiller en ligne en continu
Temps de sortie long : il faut attendre la période de contestation lors de la fermeture du canal
Dépendance à des nœuds centralisés : nécessite des services de surveillance tiers ### comme les Watchtowers (
État d'explosion : N utilisateurs nécessitent N)N-1(/2 canaux
Liquidité limitée : les fonds sont bloqués dans des canaux spécifiques
)# 3.1.5 Application
Réseau Lightning Bitcoin
Aperçu : le réseau Lightning est un canal de paiement de petite taille sur le réseau Bitcoin, dont l'évolution technique globale a été la suivante : construction d'un canal de paiement unidirectionnel par multi-signatures 2/2, ajout de RSMC###Contrat de Maturité Séquentielle Révocable( permettant de construire un canal de paiement bidirectionnel, puis ajout de HTLC)Contrat de Verrouillage Temporel de Hachage( permettant d'élargir les canaux de paiement à des paiements multi-parties, et finalement la construction d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce à des canaux de paiement de petite taille hors chaîne, puis en utilisant des intermédiaires pour constituer un réseau de transactions, il est possible de résoudre le problème d'évolutivité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus : "Dépôt)établir un canal(→transaction du réseau Lightning)mettre à jour l'état du canal(→remboursement/règlement)terminer le canal(" ; théoriquement, le réseau Lightning peut traiter un million de transactions par seconde.
Chronologie:
En février 2015, Joseph Poon et Thaddeus Dryja ont publié le brouillon du livre blanc du réseau Lightning;
La version officielle du livre blanc a été publiée en janvier 2016 et Lightning Labs a été fondée;
Le 15 mars 2018, Lightning Labs a lancé la première version mainnet du réseau Lightning, le Lightning Network Daemon )LND( version 0.4.
Début 2021, la capacité publique du réseau Lightning était de )TVL( d'environ 40 millions de dollars, avec environ 100 000 utilisateurs utilisant le réseau Lightning.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
4
Partager
Commentaire
0/400
ImpermanentPhilosopher
· Il y a 17h
Je ne comprends toujours pas le problème triangulaire.
Analyse approfondie des solutions d'extension off-chain : des canaux d'état aux Layer2
Analyse approfondie de l'extension off-chain
1. La nécessité de l'extension
La vision future de la blockchain est la décentralisation, la sécurité et l'évolutivité, mais il est souvent possible d'en réaliser seulement deux, ce qui est connu sous le nom de problème du triangle impossible de la blockchain. Depuis des années, les gens explorent comment résoudre ce dilemme, comment améliorer le débit et la vitesse des transactions de la blockchain tout en garantissant la décentralisation et la sécurité, c'est-à-dire résoudre le problème de l'évolutivité, qui est l'un des sujets brûlants dans le processus de développement actuel de la blockchain.
La décentralisation, la sécurité et l'évolutivité de la blockchain sont définies comme suit :
Décentralisation : Toute personne peut devenir un nœud participant à la production et à la vérification du système blockchain. Plus le nombre de nœuds est élevé, plus le degré de décentralisation est important, garantissant ainsi que le réseau n'est pas contrôlé par un petit groupe de grands participants centralisés.
Sécurité : Plus le coût pour obtenir le contrôle du système blockchain est élevé, plus la sécurité est élevée, alors la chaîne peut résister à un plus grand pourcentage d'attaques de participants.
Scalabilité : La capacité de la blockchain à traiter un grand nombre de transactions.
La première grande bifurcation dure du réseau Bitcoin est née du problème de l'extension. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions de Bitcoin, le réseau Bitcoin, dont la taille maximale des blocs est de 1 Mo, a commencé à faire face à des problèmes de congestion; à partir de 2015, la communauté Bitcoin a eu des divergences sur le problème de l'extension, d'un côté se trouvait le camp des pro-extension représenté par Bitcoin ABC, qui soutenait l'augmentation de la taille des blocs, et de l'autre côté se trouvait le camp des petits blocs représenté par Bitcoin Core, qui pensait qu'il fallait utiliser la solution Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, le système client développé par Bitcoin ABC jusqu'à 8 Mo a commencé à fonctionner, ce qui a conduit à la première grande bifurcation dure dans l'histoire de Bitcoin, donnant également naissance à la nouvelle cryptomonnaie BCH.
De même, le réseau Ethereum a également choisi de sacrifier une partie de l'évolutivité pour garantir la sécurité et la décentralisation du réseau ; bien que le réseau Ethereum ne limite pas le volume des transactions en restreignant la taille des blocs comme le fait le réseau Bitcoin, il a en quelque sorte évolué vers un plafond sur les frais de gaz pouvant être contenus dans un bloc unique, mais l'objectif reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds. ( Que ce soit pour annuler ou augmenter les limites, cela éliminera de nombreux nœuds plus petits qui manquent de bande passante, de stockage et de puissance de calcul. ).
Depuis le CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure des applications on-chain telles que GameFi et NFT, la demande du marché en matière de débit ne cesse d'augmenter. Cependant, même Ethereum, qui est Turing-complet, ne peut traiter que 15 à 45 transactions par seconde ( TPS ), ce qui entraîne une augmentation des coûts de transaction, un allongement des temps de règlement, et la plupart des Dapps ont du mal à supporter les coûts d'exploitation. L'ensemble du réseau devient également lent et coûteux pour les utilisateurs, et le problème de l'évolutivité de la blockchain doit être résolu. L'idéal en matière de solution d'évolutivité est d'augmenter la vitesse des transactions du réseau blockchain ( un temps de finalité ) plus court et un débit de transactions ( un TPS ) plus élevé, sans sacrifier la décentralisation et la sécurité.
2. Catégories des solutions d'extensibilité
Nous avons classé les solutions d'extension en deux catégories principales : l'extension on-chain et l'extension off-chain, en nous basant sur le critère "s'il y a un changement de la couche principale du réseau".
2.1 Scalabilité on-chain
Concept clé : une solution visant à atteindre un effet d'extensibilité en modifiant un niveau de protocole de la chaîne principale, la principale solution actuelle étant le sharding.
Il existe plusieurs solutions pour l'extension on-chain, cet article ne s'étendra pas, voici un bref aperçu de deux solutions :
La première solution consiste à élargir l'espace de bloc, c'est-à-dire à augmenter le nombre de transactions emballées dans chaque bloc, mais cela augmentera les exigences en matière de matériel des nœuds à haute performance, augmentant ainsi le seuil d'entrée pour les nœuds et réduisant le degré de "décentralisation".
La solution deux est le sharding, qui divise le livre de la blockchain en plusieurs parties, chaque nœud ne participant plus à tous les enregistrements, mais différents shards, c'est-à-dire différents nœuds, étant responsables de différents enregistrements. Le calcul parallèle peut traiter plusieurs transactions simultanément; cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, améliorant la vitesse de traitement des transactions et le degré de décentralisation; mais cela signifie que la puissance de calcul de l'ensemble du réseau est dispersée, ce qui peut réduire la "sécurité" de l'ensemble du réseau.
Modifier le code d'un protocole de réseau principal peut avoir des conséquences négatives imprévisibles, car même la plus petite faille de sécurité sous-jacente peut sérieusement menacer la sécurité de l'ensemble du réseau, qui pourrait être contraint de procéder à un fork ou à une interruption pour réparer une mise à jour. Par exemple, l'incident de faille d'inflation de Zcash en 2018 : le code de Zcash est basé sur une modification du code de Bitcoin version 0.11.2, en 2018, un ingénieur a découvert une faille critique dans le code sous-jacent, à savoir que les tokens pouvaient être émis de manière illimitée, et l'équipe a alors passé 8 mois à corriger secrètement la faille, ne rendant publique cette affaire qu'après la correction.
2.2 off-chain扩容
Concepts clés : solutions d'extensibilité qui ne modifient pas le protocole de la couche principale existante.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et autres solutions :
Layer2 : canaux d'état, chaînes latérales, Plasma, Rollups
Autres : Validium, Volition
3. Solution d'extension off-chain
3.1 Canaux d'état ( State Channels )
3.1.1 Résumé
Les canaux d'état stipulent que les utilisateurs n'ont besoin d'interagir avec la chaîne principale que lors de l'ouverture, de la fermeture ou de la résolution des litiges du canal, et que les interactions entre utilisateurs se déroulent hors chaîne, afin de réduire le temps et le coût des transactions pour les utilisateurs, tout en permettant un nombre illimité de transactions.
Les canaux d'état sont un protocole P2P simple, adapté aux "applications basées sur des tours", par exemple, un jeu d'échecs à deux personnes. Chaque canal est géré par un contrat intelligent multi-signatures fonctionnant sur la chaîne principale, ce contrat contrôle les actifs déposés dans le canal, vérifie les mises à jour d'état et arbitre les litiges entre les participants ( selon la preuve de fraude avec signature et horodatage ). Après que les participants aient déployé le contrat sur le réseau blockchain, ils déposent une somme d'argent et la verrouillent, et après que les deux parties aient signé pour confirmer, le canal est officiellement ouvert. Le canal permet des transactions hors chaîne gratuites illimitées entre les participants ( tant que la valeur nette de leurs transferts ne dépasse pas le montant total des jetons déposés ). Les participants envoient tour à tour des mises à jour d'état à l'autre, attendant la confirmation de signature de l'autre partie. Une fois que l'autre partie a signé pour confirmer, cette mise à jour d'état est considérée comme terminée. En règle générale, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la chaîne principale, seules en cas de litige ou de fermeture du canal, une confirmation de la chaîne principale sera nécessaire. En cas de besoin de fermeture du canal, l'un des participants peut soumettre une demande de transaction sur la chaîne principale, si la demande de retrait obtient l'approbation par consensus de tous, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds bloqués restants en fonction du solde de chaque participant à l'état final du canal ; si d'autres participants n'ont pas approuvé la signature, alors tout le monde devra attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, la solution de canal d'état peut réduire considérablement la charge de calcul sur la chaîne principale, améliorer la vitesse des transactions et réduire les coûts des transactions.
3.1.2 Chronologie
En février 2015, Joseph Poon et Thaddeus Dryja ont publié un projet de livre blanc sur le réseau Lightning.
En novembre 2015, Jeff Coleman a d'abord résumé de manière systématique le concept de State Channel, en proposant que le Payment Channel de Bitcoin soit un sous-cas du concept de State Channel.
En janvier 2016, Joseph Poon et Thaddeus Dryja ont officiellement publié le livre blanc « The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments » proposant une solution d'évolutivité pour le réseau Bitcoin, le Payment Channel(, cette solution est uniquement destinée à traiter les paiements de transfert sur le réseau Bitcoin.
En novembre 2017, la première spécification de conception des State Channels basée sur le cadre Payment Channel, appelée Sprites, a été proposée.
En juin 2018, Counterfactual a proposé un design de Generalized State Channels très détaillé, qui est le premier design entièrement lié aux state channels.
En octobre 2018, l'article Generalised State Channel Networks a proposé les concepts de State Channel Networks et de Virtual Channels.
En février 2019, le concept de canaux d'état a été étendu aux canaux N-Party, Nitro est le premier protocole basé sur cette idée.
En octobre 2019, Pisa a élargi le concept de Watchtowers pour résoudre le problème de la nécessité pour tous les participants d'être en ligne en permanence.
Mars 2020, Hydra a proposé des Fast Isomorphic Channels.
)# 3.1.3 Principes techniques
Le flux de travail des canaux d'état est le suivant :
Alice et Bob déposent des fonds de leur EOA personnel dans l'adresse de contrat on-chain, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment auquel le solde est restitué à l'utilisateur ; après confirmation par signature, le canal d'état entre les deux est officiellement ouvert.
Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions off-chain via ce canal, les participants communiquant entre eux par des messages signés cryptés ### au lieu de communiquer avec le réseau blockchain (. Les deux utilisateurs doivent signer chaque transaction pour éviter les attaques de double dépense. Grâce à ces messages, ils proposent des mises à jour de l'état de leurs comptes et acceptent les mises à jour d'état proposées par l'autre.
Si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre l'état final de son compte au contrat. Si Bob signe pour approuver, le contrat libérera les fonds verrouillés et les renverra à l'utilisateur correspondant en fonction de l'état final. Si Bob ne répond pas à la signature, le contrat libérera les fonds verrouillés et les renverra à l'utilisateur correspondant à la fin de la période de contestation.
Si à un certain moment, Bob ne répond pas à la signature de mise à jour d'état envoyée par Alice dans son tour, Alice peut initier un défi en soumettant au contrat son dernier état valide, cet état valide contenant également la signature précédente de Bob, prouvant ainsi que la dernière transaction a déjà reçu l'approbation de Bob et que l'état final a été confirmé par Bob. Ensuite, le contrat permet à Bob de répondre en soumettant le prochain état au contrat pendant une période de temps; si Bob répond, les deux peuvent continuer à échanger dans le canal d'état; si Bob ne répond pas pendant cette période, le contrat ferme automatiquement le canal d'état et renvoie les fonds à Alice.
![Rapport d'étude approfondi : Analyse complète de l'expansion off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.4 Avantages et inconvénients
Avantages:
Inconvénients:
)# 3.1.5 Application
Réseau Lightning Bitcoin
Aperçu : le réseau Lightning est un canal de paiement de petite taille sur le réseau Bitcoin, dont l'évolution technique globale a été la suivante : construction d'un canal de paiement unidirectionnel par multi-signatures 2/2, ajout de RSMC###Contrat de Maturité Séquentielle Révocable( permettant de construire un canal de paiement bidirectionnel, puis ajout de HTLC)Contrat de Verrouillage Temporel de Hachage( permettant d'élargir les canaux de paiement à des paiements multi-parties, et finalement la construction d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce à des canaux de paiement de petite taille hors chaîne, puis en utilisant des intermédiaires pour constituer un réseau de transactions, il est possible de résoudre le problème d'évolutivité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus : "Dépôt)établir un canal(→transaction du réseau Lightning)mettre à jour l'état du canal(→remboursement/règlement)terminer le canal(" ; théoriquement, le réseau Lightning peut traiter un million de transactions par seconde.
Chronologie: