L'avenir de la blockchain est une vision grandiose : décentralisation, sécurité et évolutivité. Mais généralement, la blockchain ne peut réaliser que deux de ces trois objectifs, et satisfaire ces trois exigences 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 de discussion brûlants dans le processus de développement actuel de la blockchain.
Définissons d'abord de manière générale la décentralisation, la sécurité et l'évolutivité de la blockchain :
Décentralisation : toute personne peut devenir un nœud et participer à la production et à la validation du système blockchain. Plus il y a de nœuds, plus le degré de décentralisation est élevé, 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 d'un système blockchain est élevé, plus la sécurité est élevée, alors la chaîne peut résister à une plus grande proportion d'attaques de participants.
Scalabilité : la capacité de la blockchain à traiter un grand nombre de transactions.
La première grande hard fork du réseau Bitcoin est née du problème d'évolutivité. 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 ; depuis 2015, la communauté Bitcoin est divisée sur la question de l'évolutivité, d'une part, le camp pro-évolutivité, représenté par Bitcoin ABC, qui soutient l'augmentation de la taille des blocs, et d'autre part, le camp des petits blocs, représenté par Bitcoin Core, qui estime qu'il faut optimiser la structure de la chaîne principale en utilisant la solution Segwit. Le 1er août 2017, le système client développé par Bitcoin ABC jusqu'à 8 Mo a commencé à fonctionner, entraînant la première grande hard fork de l'histoire de Bitcoin, et donnant ainsi 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 plutôt transformé cela en un plafond sur les frais de carburant pouvant être inclus dans un seul bloc, mais l'objectif est de réaliser un consensus sans confiance et d'assurer une large distribution des nœuds. Que ce soit en annulant ou en augmentant le plafond, cela éliminera de nombreux petits nœuds qui manquent de bande passante, de stockage et de capacité de calcul.
Depuis l'émergence de CryptoKitties en 2017, de l'été DeFi, puis des applications on-chain telles que GameFi et NFT, la demande de débit sur le marché n'a cessé d'augmenter. Cependant, même Ethereum, qui est Turing-complet, ne peut traiter que 15 à 45 transactions par seconde ( TPS ). Cela a pour conséquence d'augmenter constamment les coûts de transaction, de prolonger le temps de règlement, rendant la plupart des Dapps difficiles à supporter en termes de coûts d'exploitation. L'ensemble du réseau devient également lent et cher pour les utilisateurs, et le problème de l'évolutivité de la blockchain doit être résolu d'urgence. L'état idéal d'une solution d'évolutivité est : améliorer autant que possible 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 de solutions d'extensibilité
Nous avons classé les solutions d'extension en deux grandes catégories : l'extension on-chain et l'extension off-chain, en nous basant sur le critère "si une couche de la blockchain principale est modifiée".
( 2.1 Élargissement on-chain
Concept clé : une solution pour atteindre une capacité d'extension en modifiant un niveau de protocole de la chaîne principale, la principale solution actuelle est le sharding.
Il existe plusieurs solutions pour l'extension on-chain, cet article ne les développera pas, voici un aperçu de deux solutions :
La première solution consiste à élargir l'espace de bloc, c'est-à-dire à augmenter le nombre de transactions empaquetées dans chaque bloc, mais cela augmentera les exigences pour les dispositifs de nœuds haute performance, majorera le seuil d'entrée des nœuds et réduira le degré de "décentralisation".
La solution deux est le sharding, qui consiste à diviser le registre de la blockchain en plusieurs parties. Au lieu que chaque nœud participe à tous les enregistrements, différents shards, c'est-à-dire différents nœuds, sont responsables de différents enregistrements. Le calcul parallèle peut traiter plusieurs transactions en même temps ; cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, tout en augmentant 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 diminuer la "sécurité" du réseau.
Modifier le code d'un protocole de réseau principal peut avoir des conséquences négatives imprévisibles, car la moindre vulnérabilité de sécurité sous-jacente peut gravement menacer la sécurité de l'ensemble du réseau, qui pourrait être contraint de procéder à un fork ou à une mise à jour de réparation interrompue. Par exemple, l'incident de la vulnérabilité d'inflation de Zcash en 2018 : le code de Zcash est basé sur une version modifiée du code de Bitcoin 0.11.2, en 2018, un ingénieur a découvert une vulnérabilité critique dans son code sous-jacent, à savoir que les jetons pouvaient être émis à l'infini, l'équipe a ensuite passé 8 mois à corriger cela en secret, et ce n'est qu'après la correction de la vulnérabilité qu'ils ont rendu cet incident public.
) 2.2 off-chain扩容
Concept clé : solution d'extensibilité qui ne modifie pas le protocole de la couche principale existant.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et autres solutions :
Layer2: En construisant un niveau de réseau supplémentaire au-dessus de la chaîne principale, la plupart des transactions et des calculs sont déplacés vers ce niveau pour améliorer le débit des transactions et réduire les coûts. Cela inclut principalement les canaux d'état, Plasma, Rollups, etc.
Autres solutions : comme les réseaux blockchain indépendants tels que les sidechains, interagissant en cross-chain avec la chaîne principale.
![Rapport de recherche en profondeur : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp###
3. Solutions d'extension off-chain
( 3.1 Canaux d'état
)# 3.1.1 Résumé
Les canaux d'état stipulent que les utilisateurs doivent interagir avec la chaîne principale uniquement lors de l'ouverture, de la fermeture ou de la résolution de litiges dans le canal, et que les interactions entre les utilisateurs se déroulent off-chain, 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. Chaque canal est géré par un contrat intelligent multi-signatures fonctionnant sur la blockchain principale, ce contrat contrôle les actifs déposés dans le canal, vérifie les mises à jour d'état et arbitre les différends entre les participants ### en fonction des preuves de fraude signées et horodatées ###. Après le déploiement du contrat sur le réseau blockchain, les participants déposent des fonds et les verrouillent, et après confirmation par signature des deux parties, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions hors chaîne gratuites ( 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 par signature de l'autre. Une fois que l'autre a confirmé par signature, cette mise à jour d'état est considérée comme terminée. En règle normale, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la blockchain principale, seules les mises à jour en cas de différend ou de fermeture du canal dépendront de la confirmation de la blockchain principale. Lorsqu'il est nécessaire de fermer le canal, n'importe quel participant peut soumettre une demande de transaction sur la blockchain principale, si la demande de retrait reçoit l'approbation par signature unanime de tous, elle est exécutée immédiatement sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants selon le solde de chaque participant à l'état final du canal ; si d'autres participants n'approuvent pas par signature, alors tout le monde devra attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, les solutions de canaux d'état peuvent considérablement réduire la charge de calcul du réseau principal, améliorer la vitesse des transactions et réduire les coûts de transaction.
(# 3.1.2 Chronologie
2015/02, Joseph Poon et Thaddeus Dryja ont publié un projet de livre blanc sur le réseau Lightning.
En novembre 2015, Jeff Coleman a systématiquement résumés le concept de State Channel, en proposant que le Payment Channel de Bitcoin est un sous-cas du concept de State Channel.
2016/01, Joseph Poon et Thaddeus Dryja ont officiellement publié le livre blanc « The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments » proposant un plan d'extension du réseau Lightning de Bitcoin Payment Channel), ce plan est uniquement utilisé pour traiter les paiements de transfert sur le réseau Bitcoin.
En novembre 2017, la première spécification de conception concernant les State Channels basée sur le cadre Payment Channel, Sprites, a été proposée.
2018/06, Counterfactual a proposé un design très détaillé des Generalized State Channels, c'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.
2019/02, le concept de canaux d'état a été étendu aux N-Party Channels, Nitro est le premier protocole construit sur cette idée.
2019/10, Pisa a élargi le concept de Watchtowers pour résoudre le problème de la nécessité pour tous les participants d'être continuellement en ligne.
2020/03, Hydra a proposé des Fast Isomorphic Channels.
![Rapport de recherche approfondi : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.3 Principe technique
Le flux de travail de base des canaux d'état est le suivant :
Alice et Bob déposent des fonds depuis leur EOA personnel à l'adresse du contrat on-chain, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment où le solde est retourné à l'utilisateur ; après confirmation par signature des deux parties, le canal d'état entre les deux est officiellement ouvert.
Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions hors chaîne via ce canal, les participants communiquent 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 empêcher les attaques de double dépense. À travers 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 retournera à 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 retournera à l'utilisateur correspondant à la fin de la période de contestation.
Si Bob ne répond pas à la signature de mise à jour d'état envoyée par Alice pendant son tour, Alice peut initier un défi en soumettant à l'accord son dernier état valide, cet état valide contenant également la signature précédente de Bob, prouvant ainsi que la dernière transaction a été approuvée par 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 donnée ; si Bob répond, les deux peuvent continuer à effectuer des transactions dans le canal d'état ; si Bob ne répond pas pendant cette période, le contrat ferme automatiquement le canal d'état et retourne les fonds à Alice.
![Rapport de recherche approfondi : analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Avantages et inconvénients
Avantages:
Instantanéité : Les transactions peuvent être effectuées immédiatement, sans attendre la confirmation de bloc.
Confidentialité : seul l'état final sera enregistré sur la chaîne, le processus intermédiaire ne sera pas exposé
Scalabilité : peut supporter un nombre illimité de transactions off-chain
Coût bas : les transactions off-chain n'ont pratiquement pas de frais.
Inconvénients:
Disponibilité : nécessite que les parties impliquées restent en ligne
Efficacité des fonds faible : les fonds ne peuvent pas être utilisés pendant la période de blocage.
Complexité : il y a un certain seuil pour les développeurs et les utilisateurs.
Limite de liquidité : fonds limités dans le canal
Applicabilité limitée : principalement applicable aux deux parties ayant des interactions fréquentes.
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 technologique globale a connu : 2/2 construction d'un canal de paiement unidirectionnel avec multi-signatures, ajout de RSMC)Revocable Sequence Maturity Contract### permettant de construire un canal de paiement bidirectionnel, puis ajout de HTLC###Hash Time Lock Contract( permettant d'étendre les canaux de paiement à plusieurs participants, et finalement la construction d'un réseau de paiement, à savoir le réseau Lightning. Grâce aux paiements de petite taille off-chain.
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.
9 J'aime
Récompense
9
5
Partager
Commentaire
0/400
BlockImposter
· Il y a 14h
off-chain transactions Mettons l'accent
Voir l'originalRépondre0
GasGasGasBro
· Il y a 15h
Profiter gratuitement du gas yyds !
Voir l'originalRépondre0
DaoGovernanceOfficer
· Il y a 15h
*soupir* encore une analyse superficielle du trilemme... empiriquement parlant, les canaux d'état ont échoué précisément à cause de ces cadres trop simplifiés.
Voir l'originalRépondre0
AirdropHunter007
· Il y a 15h
Les chaînes poubelles parlent toutes d'extension, autant ne pas utiliser de chaînes.
Voir l'originalRépondre0
Ser_Liquidated
· Il y a 15h
Pas besoin de me demander ce que je peux faire, c'est encore tout en dehors de la chaîne, juste en tapant de l'argent.
Analyse approfondie des solutions d'extension off-chain : des canaux d'état au Lightning Network
Analyse approfondie de l'extension off-chain
1. La nécessité de l'expansion
L'avenir de la blockchain est une vision grandiose : décentralisation, sécurité et évolutivité. Mais généralement, la blockchain ne peut réaliser que deux de ces trois objectifs, et satisfaire ces trois exigences 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 de discussion brûlants dans le processus de développement actuel de la blockchain.
Définissons d'abord de manière générale la décentralisation, la sécurité et l'évolutivité de la blockchain :
La première grande hard fork du réseau Bitcoin est née du problème d'évolutivité. 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 ; depuis 2015, la communauté Bitcoin est divisée sur la question de l'évolutivité, d'une part, le camp pro-évolutivité, représenté par Bitcoin ABC, qui soutient l'augmentation de la taille des blocs, et d'autre part, le camp des petits blocs, représenté par Bitcoin Core, qui estime qu'il faut optimiser la structure de la chaîne principale en utilisant la solution Segwit. Le 1er août 2017, le système client développé par Bitcoin ABC jusqu'à 8 Mo a commencé à fonctionner, entraînant la première grande hard fork de l'histoire de Bitcoin, et donnant ainsi 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 plutôt transformé cela en un plafond sur les frais de carburant pouvant être inclus dans un seul bloc, mais l'objectif est de réaliser un consensus sans confiance et d'assurer une large distribution des nœuds. Que ce soit en annulant ou en augmentant le plafond, cela éliminera de nombreux petits nœuds qui manquent de bande passante, de stockage et de capacité de calcul.
Depuis l'émergence de CryptoKitties en 2017, de l'été DeFi, puis des applications on-chain telles que GameFi et NFT, la demande de débit sur le marché n'a cessé d'augmenter. Cependant, même Ethereum, qui est Turing-complet, ne peut traiter que 15 à 45 transactions par seconde ( TPS ). Cela a pour conséquence d'augmenter constamment les coûts de transaction, de prolonger le temps de règlement, rendant la plupart des Dapps difficiles à supporter en termes de coûts d'exploitation. L'ensemble du réseau devient également lent et cher pour les utilisateurs, et le problème de l'évolutivité de la blockchain doit être résolu d'urgence. L'état idéal d'une solution d'évolutivité est : améliorer autant que possible 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 de solutions d'extensibilité
Nous avons classé les solutions d'extension en deux grandes catégories : l'extension on-chain et l'extension off-chain, en nous basant sur le critère "si une couche de la blockchain principale est modifiée".
( 2.1 Élargissement on-chain
Concept clé : une solution pour atteindre une capacité d'extension en modifiant un niveau de protocole de la chaîne principale, la principale solution actuelle est le sharding.
Il existe plusieurs solutions pour l'extension on-chain, cet article ne les développera pas, voici un aperçu de deux solutions :
Modifier le code d'un protocole de réseau principal peut avoir des conséquences négatives imprévisibles, car la moindre vulnérabilité de sécurité sous-jacente peut gravement menacer la sécurité de l'ensemble du réseau, qui pourrait être contraint de procéder à un fork ou à une mise à jour de réparation interrompue. Par exemple, l'incident de la vulnérabilité d'inflation de Zcash en 2018 : le code de Zcash est basé sur une version modifiée du code de Bitcoin 0.11.2, en 2018, un ingénieur a découvert une vulnérabilité critique dans son code sous-jacent, à savoir que les jetons pouvaient être émis à l'infini, l'équipe a ensuite passé 8 mois à corriger cela en secret, et ce n'est qu'après la correction de la vulnérabilité qu'ils ont rendu cet incident public.
) 2.2 off-chain扩容
Concept clé : solution d'extensibilité qui ne modifie pas le protocole de la couche principale existant.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et autres solutions :
Layer2: En construisant un niveau de réseau supplémentaire au-dessus de la chaîne principale, la plupart des transactions et des calculs sont déplacés vers ce niveau pour améliorer le débit des transactions et réduire les coûts. Cela inclut principalement les canaux d'état, Plasma, Rollups, etc.
Autres solutions : comme les réseaux blockchain indépendants tels que les sidechains, interagissant en cross-chain avec la chaîne principale.
![Rapport de recherche en profondeur : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp###
3. Solutions d'extension off-chain
( 3.1 Canaux d'état
)# 3.1.1 Résumé
Les canaux d'état stipulent que les utilisateurs doivent interagir avec la chaîne principale uniquement lors de l'ouverture, de la fermeture ou de la résolution de litiges dans le canal, et que les interactions entre les utilisateurs se déroulent off-chain, 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. Chaque canal est géré par un contrat intelligent multi-signatures fonctionnant sur la blockchain principale, ce contrat contrôle les actifs déposés dans le canal, vérifie les mises à jour d'état et arbitre les différends entre les participants ### en fonction des preuves de fraude signées et horodatées ###. Après le déploiement du contrat sur le réseau blockchain, les participants déposent des fonds et les verrouillent, et après confirmation par signature des deux parties, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions hors chaîne gratuites ( 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 par signature de l'autre. Une fois que l'autre a confirmé par signature, cette mise à jour d'état est considérée comme terminée. En règle normale, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la blockchain principale, seules les mises à jour en cas de différend ou de fermeture du canal dépendront de la confirmation de la blockchain principale. Lorsqu'il est nécessaire de fermer le canal, n'importe quel participant peut soumettre une demande de transaction sur la blockchain principale, si la demande de retrait reçoit l'approbation par signature unanime de tous, elle est exécutée immédiatement sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants selon le solde de chaque participant à l'état final du canal ; si d'autres participants n'approuvent pas par signature, alors tout le monde devra attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, les solutions de canaux d'état peuvent considérablement réduire la charge de calcul du réseau principal, améliorer la vitesse des transactions et réduire les coûts de transaction.
(# 3.1.2 Chronologie
![Rapport de recherche approfondi : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.3 Principe technique
Le flux de travail de base des canaux d'état est le suivant :
Alice et Bob déposent des fonds depuis leur EOA personnel à l'adresse du contrat on-chain, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment où le solde est retourné à l'utilisateur ; après confirmation par signature des deux parties, le canal d'état entre les deux est officiellement ouvert.
Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions hors chaîne via ce canal, les participants communiquent 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 empêcher les attaques de double dépense. À travers 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 retournera à 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 retournera à l'utilisateur correspondant à la fin de la période de contestation.
Si Bob ne répond pas à la signature de mise à jour d'état envoyée par Alice pendant son tour, Alice peut initier un défi en soumettant à l'accord son dernier état valide, cet état valide contenant également la signature précédente de Bob, prouvant ainsi que la dernière transaction a été approuvée par 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 donnée ; si Bob répond, les deux peuvent continuer à effectuer des transactions dans le canal d'état ; si Bob ne répond pas pendant cette période, le contrat ferme automatiquement le canal d'état et retourne les fonds à Alice.
![Rapport de recherche approfondi : analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-815c5eb2bdba725e04eebe67b22d42aa.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 technologique globale a connu : 2/2 construction d'un canal de paiement unidirectionnel avec multi-signatures, ajout de RSMC)Revocable Sequence Maturity Contract### permettant de construire un canal de paiement bidirectionnel, puis ajout de HTLC###Hash Time Lock Contract( permettant d'étendre les canaux de paiement à plusieurs participants, et finalement la construction d'un réseau de paiement, à savoir le réseau Lightning. Grâce aux paiements de petite taille off-chain.