La vision future de la blockchain est d'atteindre la décentralisation, la sécurité et l'évolutivité. Mais il n'est généralement possible d'en réaliser que deux, ce qui est appelé le problème du triangle impossible de la blockchain. Depuis des années, les gens explorent 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é.
La décentralisation, la sécurité et l'évolutivité de la blockchain sont définies comme suit :
Décentralisé : n'importe qui peut devenir un nœud participant à la production et à la validation du système blockchain, plus il y a de nœuds, plus le degré de décentralisation est élevé.
Sécurité : Plus le coût pour obtenir le contrôle d'un système blockchain est élevé, plus la sécurité est grande, 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 hard fork significative du réseau Bitcoin est née du problème de l'évolutivité. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions, le réseau Bitcoin, dont la taille maximale des blocs est de 1 Mo, a commencé à faire face à des congestions. À partir de 2015, la communauté Bitcoin a eu des divergences sur la question de l'évolutivité, une partie soutenant l'augmentation de la taille des blocs, tandis que l'autre estimait qu'il fallait utiliser la solution Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, la partie qui soutenait l'augmentation de la taille des blocs a développé de manière autonome un système client allant jusqu'à 8 Mo, entraînant la première hard fork significative de l'histoire de Bitcoin et donnant naissance à la nouvelle cryptomonnaie BCH.
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 qu'Ethereum ne limite pas le volume des transactions en restreignant la taille des blocs comme le fait Bitcoin, il impose en réalité un plafond sur les frais de gaz qu'un seul bloc peut contenir. L'objectif est le même : réaliser un consensus sans confiance et garantir une large distribution des nœuds.
Depuis les CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure 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 entraîné une augmentation constante des coûts de transaction, des temps de règlement prolongés, rendant la plupart des Dapps incapables de supporter les coûts d'exploitation. L'ensemble du réseau est devenu lent et coûteux pour les utilisateurs, et le problème de l'évolutivité de la blockchain doit être résolu de toute urgence. La solution d'évolutivité idéale est : augmenter la vitesse et le débit des transactions du réseau blockchain autant que possible, sans compromettre la décentralisation et la sécurité.
2. Catégories des solutions d'extension
Nous avons classé les solutions d'extension en deux grandes catégories : l'extension on-chain et l'extension off-chain, en utilisant "s'il y a un changement de couche de la chaîne principale" comme critère.
2.1 Scalabilité on-chain
Concept central : une solution visant à atteindre un effet d'extension en modifiant une couche du 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 les détaillera pas, mais en mentionnera brièvement deux :
La première solution consiste à élargir l'espace de bloc, à augmenter le nombre de transactions empaqueté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 rejoindre les nœuds et réduisant le degré de "décentralisation".
La solution deux est le sharding, qui consiste à diviser le grand livre blockchain en plusieurs parties, chaque partie étant responsable de la comptabilité par différents shards, ce qui permet un calcul parallèle pour traiter plusieurs transactions simultanément ; cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, tout en 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é" du réseau.
Modifier le code du protocole principal d'un réseau peut avoir des conséquences négatives imprévisibles, car toute vulnérabilité de sécurité mineure au niveau sous-jacent peut sérieusement menacer la sécurité de l'ensemble du réseau, et celui-ci peut être contraint d'effectuer une fourche ou d'interrompre une mise à niveau de réparation.
2.2 off-chain scaling
Concept clé : solution d'extension qui ne modifie pas le protocole de la couche principale existant.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et d'autres solutions :
Layer2 : State Channels, Plasma, Rollups ( Optimistic Rollups et ZK Rollups )
Autres : Sidechains, Validium
3. Solutions d'extension off-chain
3.1 Canaux d'état
3.1.1 Résumé
Le canal d'état stipule que les utilisateurs doivent interagir avec la blockchain principale uniquement lorsque le canal est ouvert, fermé ou résolu, et que les interactions entre utilisateurs se déroulent off-chain, afin de réduire le temps et le coût des transactions des utilisateurs, tout en permettant un nombre illimité de transactions.
Les canaux d'état sont des protocoles P2P simples, adaptés aux "applications basées sur des tours", comme un jeu d'échecs à deux joueurs. 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 différends entre les participants. Après le déploiement du contrat sur le réseau blockchain, les participants déposent des fonds et les verrouillent, et une fois que les deux parties ont signé pour confirmer, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions off-chain gratuites ( tant que la valeur nette des transferts ne dépasse pas le montant total des jetons déposés ). Les participants envoient alternativement des mises à jour d'état à l'autre, en attendant la confirmation de signature de l'autre partie. Une fois que l'autre partie a signé, cette mise à jour d'état est considérée comme complétée. Normalement, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la chaîne principale, seules les situations de différend ou de fermeture du canal nécessitent une confirmation de la chaîne principale. Lorsque le canal doit être fermé, l'un des participants peut soumettre une demande de transaction sur la chaîne principale, si la demande de retrait obtient l'approbation de tous les signataires, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds restants verrouillés en fonction des soldes de chaque participant à l'état final du canal ; si d'autres participants n'ont pas approuvé par signature, alors tout le monde doit attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, le schéma de canal d'état peut considérablement réduire la charge de calcul sur la chaîne principale, 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 publient un projet de livre blanc sur le réseau Lightning.
En novembre 2015, Jeff Coleman a systématiquement résumé le concept de State Channel pour la première fois, 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 une solution d'extension du réseau Lightning de Bitcoin, le Payment Channel (, qui n'est utilisé que pour traiter les paiements de transfert sur le réseau Bitcoin.
Novembre 2017, la première spécification de conception de State Channel basée sur le cadre Payment Channel, Sprites, a été proposée.
2018/06, Counterfactual a proposé un design détaillé des Generalized State Channels, c'est le premier design entièrement lié aux State Channels.
2018/10, l'article Generalised State Channel Networks a proposé les concepts de State Channel Networks et de Virtual Channels.
2019/02, le concept des canaux d'état s'est étendu aux canaux N-Party, Nitro est le premier protocole établi 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 en ligne en permanence.
2020/03, Hydra a proposé des Fast Isomorphic Channels.
)# 3.1.3 Principe technique
Flux de travail traditionnel sur la chaîne : Alice et Bob interagissent avec des contrats intelligents déployés sur la chaîne principale, les utilisateurs modifient l'état du contrat intelligent en envoyant des transactions sur la chaîne. L'inconvénient est que cela entraîne des problèmes de temps et de coût.
La plupart des flux de travail généraux suivis par les protocoles de canal d'état :
Alice et Bob déposent des fonds de leur EOA personnel à l'adresse du contrat sur la chaîne, ces fonds sont verrouillés dans le contrat jusqu'à ce qu'ils soient restitués à l'utilisateur lorsque le canal est fermé ; après la confirmation de leur signature, le canal d'état entre eux est officiellement ouvert.
Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions hors chaîne via ce canal, les participants communiquant entre eux par des messages signés cryptés. Les deux utilisateurs doivent signer chaque transaction pour éviter les doubles dépenses. 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 après la fin de la période de contestation.
![Rapport de recherche en profondeur : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Flux de travail du canal d'état dans un scénario pessimiste : au départ, deux participants déposent des fonds, puis commencent à échanger des mises à jour d'état. Supposons qu'à un moment donné, Bob ne réponde pas à la mise à jour d'état signée envoyée par Alice dans son tour, à ce moment-là, Alice peut initier un défi en soumettant son dernier état valide au contrat, 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 le dernier état a été confirmé par Bob. Ensuite, le contrat permet à Bob de répondre en soumettant le prochain état au contrat pendant une période donnée ; si Bob répond, les deux peuvent continuer à échanger dans le canal d'état ; si Bob ne répond pas dans cette période, le contrat ferme automatiquement le canal d'état et retourne les fonds à Alice.
)# 3.1.4 Avantages et inconvénients
Avantages:
Instantanéité: les transactions sont presque réalisées instantanément.
Haute capacité de traitement : théoriquement extensible à l'infini
Coût faible : les transactions off-chain n'ont presque aucun coût
Confidentialité : une interaction sur la chaîne n'est nécessaire que lors de l'ouverture et de la fermeture du canal.
Inconvénients :
Efficacité des fonds faible : besoin de verrouiller les fonds
Exigences en ligne : les participants doivent rester en ligne en permanence
Applications limitées: mieux adapté aux interactions fréquentes entre un nombre fixe de participants
La complexité de la fermeture des canaux et de la résolution des litiges
Problèmes de liquidité du réseau de canaux
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 avec une multi-signature 2/2, possibilité de construire un canal de paiement bidirectionnel après l'ajout de RSMC, puis connexion des canaux de paiement à plusieurs participants après l'ajout de HTLC, et enfin construction d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce aux canaux de paiement de petite taille hors chaîne, puis en s'appuyant sur des intermédiaires pour former un réseau de transactions, on peut résoudre le problème de scalabilité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus "dépôt ### établissement du canal ( → transactions réseau Lightning ) mise à jour de l'état du canal ( → remboursement/règlement ) fermeture du 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é un brouillon de livre blanc sur le 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 publié la première version principale du réseau Lightning, la version LND 0.4.
Début 2021, la capacité publique du réseau Lightning )TVL( n'était que d'environ 40 millions de dollars, avec environ 100 000 utilisateurs.
En juin 2021, le Salvador a annoncé l'adoption du Bitcoin comme monnaie légale, et en septembre, il a lancé le portefeuille Chivo basé sur le réseau Lightning.
En 2022, Cash App et 26 plateformes d'échange de cryptomonnaies, y compris OKX, Kraken et Bitfinex, ont annoncé le soutien au réseau Lightning.
Octobre 2022, Lightning Labs a publié la nouvelle version alpha du protocole Taro basé sur Taproot), qui est actuellement en phase de test sur le réseau de test.
Le 23 novembre 2022, le réseau Lightning comptait 76 236 canaux de paiement, avec des fonds de canal de 5049 $BTC($81.8M)
Développement écologique:
L'écosystème du réseau Lightning BTC se compose de bas en haut : le réseau BTC de base --- les infrastructures fondamentales --- divers Dapps.
Les infrastructures de base comprennent :
Solutions de réseau Lightning : les particuliers et les entreprises peuvent exécuter des programmes logiciels connectés au réseau Lightning, dont la part de marché la plus importante est détenue par Lightning Labs.
Services de nœuds et de liquidité : Parce que faire fonctionner son propre nœud de manière indépendante est assez complexe, il est nécessaire de fournir une interface conviviale pour aider à gérer les canaux de paiement instantané.
Au-dessus des infrastructures de base se trouvent divers services de paiement et financiers ainsi que des applications, par exemple, Strike est construit sur la solution LND qui permet aux utilisateurs d'acheter et de vendre des BTC, d'utiliser des BTC pour récompenser les créateurs sur Twitter et de permettre aux commerçants de Shopify d'accepter des BTC, etc.
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.
10 J'aime
Récompense
10
5
Partager
Commentaire
0/400
CryptoWageSlave
· 08-05 15:53
L'extension est imminente.
Voir l'originalRépondre0
ConsensusBot
· 08-05 15:52
Le chemin de l'extension est encore long.
Voir l'originalRépondre0
CryptoGoldmine
· 08-05 15:52
Coût de consensus entièrement équilibré
Voir l'originalRépondre0
GigaBrainAnon
· 08-05 15:44
La situation du triangle est difficile à déchiffrer
Détails sur les solutions d'extension off-chain : des State Channels aux solutions Layer2
Analyse approfondie de l'extension off-chain
1. La nécessité de l'extension
La vision future de la blockchain est d'atteindre la décentralisation, la sécurité et l'évolutivité. Mais il n'est généralement possible d'en réaliser que deux, ce qui est appelé le problème du triangle impossible de la blockchain. Depuis des années, les gens explorent 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é.
La décentralisation, la sécurité et l'évolutivité de la blockchain sont définies comme suit :
Décentralisé : n'importe qui peut devenir un nœud participant à la production et à la validation du système blockchain, plus il y a de nœuds, plus le degré de décentralisation est élevé.
Sécurité : Plus le coût pour obtenir le contrôle d'un système blockchain est élevé, plus la sécurité est grande, 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 hard fork significative du réseau Bitcoin est née du problème de l'évolutivité. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions, le réseau Bitcoin, dont la taille maximale des blocs est de 1 Mo, a commencé à faire face à des congestions. À partir de 2015, la communauté Bitcoin a eu des divergences sur la question de l'évolutivité, une partie soutenant l'augmentation de la taille des blocs, tandis que l'autre estimait qu'il fallait utiliser la solution Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, la partie qui soutenait l'augmentation de la taille des blocs a développé de manière autonome un système client allant jusqu'à 8 Mo, entraînant la première hard fork significative de l'histoire de Bitcoin et donnant naissance à la nouvelle cryptomonnaie BCH.
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 qu'Ethereum ne limite pas le volume des transactions en restreignant la taille des blocs comme le fait Bitcoin, il impose en réalité un plafond sur les frais de gaz qu'un seul bloc peut contenir. L'objectif est le même : réaliser un consensus sans confiance et garantir une large distribution des nœuds.
Depuis les CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure 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 entraîné une augmentation constante des coûts de transaction, des temps de règlement prolongés, rendant la plupart des Dapps incapables de supporter les coûts d'exploitation. L'ensemble du réseau est devenu lent et coûteux pour les utilisateurs, et le problème de l'évolutivité de la blockchain doit être résolu de toute urgence. La solution d'évolutivité idéale est : augmenter la vitesse et le débit des transactions du réseau blockchain autant que possible, sans compromettre la décentralisation et la sécurité.
2. Catégories des solutions d'extension
Nous avons classé les solutions d'extension en deux grandes catégories : l'extension on-chain et l'extension off-chain, en utilisant "s'il y a un changement de couche de la chaîne principale" comme critère.
2.1 Scalabilité on-chain
Concept central : une solution visant à atteindre un effet d'extension en modifiant une couche du 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 les détaillera pas, mais en mentionnera brièvement deux :
La première solution consiste à élargir l'espace de bloc, à augmenter le nombre de transactions empaqueté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 rejoindre les nœuds et réduisant le degré de "décentralisation".
La solution deux est le sharding, qui consiste à diviser le grand livre blockchain en plusieurs parties, chaque partie étant responsable de la comptabilité par différents shards, ce qui permet un calcul parallèle pour traiter plusieurs transactions simultanément ; cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, tout en 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é" du réseau.
Modifier le code du protocole principal d'un réseau peut avoir des conséquences négatives imprévisibles, car toute vulnérabilité de sécurité mineure au niveau sous-jacent peut sérieusement menacer la sécurité de l'ensemble du réseau, et celui-ci peut être contraint d'effectuer une fourche ou d'interrompre une mise à niveau de réparation.
2.2 off-chain scaling
Concept clé : solution d'extension qui ne modifie pas le protocole de la couche principale existant.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et d'autres solutions :
Layer2 : State Channels, Plasma, Rollups ( Optimistic Rollups et ZK Rollups )
Autres : Sidechains, Validium
3. Solutions d'extension off-chain
3.1 Canaux d'état
3.1.1 Résumé
Le canal d'état stipule que les utilisateurs doivent interagir avec la blockchain principale uniquement lorsque le canal est ouvert, fermé ou résolu, et que les interactions entre utilisateurs se déroulent off-chain, afin de réduire le temps et le coût des transactions des utilisateurs, tout en permettant un nombre illimité de transactions.
Les canaux d'état sont des protocoles P2P simples, adaptés aux "applications basées sur des tours", comme un jeu d'échecs à deux joueurs. 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 différends entre les participants. Après le déploiement du contrat sur le réseau blockchain, les participants déposent des fonds et les verrouillent, et une fois que les deux parties ont signé pour confirmer, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions off-chain gratuites ( tant que la valeur nette des transferts ne dépasse pas le montant total des jetons déposés ). Les participants envoient alternativement des mises à jour d'état à l'autre, en attendant la confirmation de signature de l'autre partie. Une fois que l'autre partie a signé, cette mise à jour d'état est considérée comme complétée. Normalement, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la chaîne principale, seules les situations de différend ou de fermeture du canal nécessitent une confirmation de la chaîne principale. Lorsque le canal doit être fermé, l'un des participants peut soumettre une demande de transaction sur la chaîne principale, si la demande de retrait obtient l'approbation de tous les signataires, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds restants verrouillés en fonction des soldes de chaque participant à l'état final du canal ; si d'autres participants n'ont pas approuvé par signature, alors tout le monde doit attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, le schéma de canal d'état peut considérablement réduire la charge de calcul sur la chaîne principale, 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 publient un projet de livre blanc sur le réseau Lightning.
En novembre 2015, Jeff Coleman a systématiquement résumé le concept de State Channel pour la première fois, 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 une solution d'extension du réseau Lightning de Bitcoin, le Payment Channel (, qui n'est utilisé que pour traiter les paiements de transfert sur le réseau Bitcoin.
Novembre 2017, la première spécification de conception de State Channel basée sur le cadre Payment Channel, Sprites, a été proposée.
2018/06, Counterfactual a proposé un design détaillé des Generalized State Channels, c'est le premier design entièrement lié aux State Channels.
2018/10, l'article Generalised State Channel Networks a proposé les concepts de State Channel Networks et de Virtual Channels.
2019/02, le concept des canaux d'état s'est étendu aux canaux N-Party, Nitro est le premier protocole établi 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 en ligne en permanence.
2020/03, Hydra a proposé des Fast Isomorphic Channels.
)# 3.1.3 Principe technique
Flux de travail traditionnel sur la chaîne : Alice et Bob interagissent avec des contrats intelligents déployés sur la chaîne principale, les utilisateurs modifient l'état du contrat intelligent en envoyant des transactions sur la chaîne. L'inconvénient est que cela entraîne des problèmes de temps et de coût.
La plupart des flux de travail généraux suivis par les protocoles de canal d'état :
Alice et Bob déposent des fonds de leur EOA personnel à l'adresse du contrat sur la chaîne, ces fonds sont verrouillés dans le contrat jusqu'à ce qu'ils soient restitués à l'utilisateur lorsque le canal est fermé ; après la confirmation de leur signature, le canal d'état entre eux est officiellement ouvert.
Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions hors chaîne via ce canal, les participants communiquant entre eux par des messages signés cryptés. Les deux utilisateurs doivent signer chaque transaction pour éviter les doubles dépenses. 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 après la fin de la période de contestation.
![Rapport de recherche en profondeur : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Flux de travail du canal d'état dans un scénario pessimiste : au départ, deux participants déposent des fonds, puis commencent à échanger des mises à jour d'état. Supposons qu'à un moment donné, Bob ne réponde pas à la mise à jour d'état signée envoyée par Alice dans son tour, à ce moment-là, Alice peut initier un défi en soumettant son dernier état valide au contrat, 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 le dernier état a été confirmé par Bob. Ensuite, le contrat permet à Bob de répondre en soumettant le prochain état au contrat pendant une période donnée ; si Bob répond, les deux peuvent continuer à échanger dans le canal d'état ; si Bob ne répond pas dans cette période, le contrat ferme automatiquement le canal d'état et retourne les fonds à Alice.
)# 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 avec une multi-signature 2/2, possibilité de construire un canal de paiement bidirectionnel après l'ajout de RSMC, puis connexion des canaux de paiement à plusieurs participants après l'ajout de HTLC, et enfin construction d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce aux canaux de paiement de petite taille hors chaîne, puis en s'appuyant sur des intermédiaires pour former un réseau de transactions, on peut résoudre le problème de scalabilité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus "dépôt ### établissement du canal ( → transactions réseau Lightning ) mise à jour de l'état du canal ( → remboursement/règlement ) fermeture du canal (" ; théoriquement, le réseau Lightning peut traiter un million de transactions par seconde.
Chronologie:
Développement écologique: L'écosystème du réseau Lightning BTC se compose de bas en haut : le réseau BTC de base --- les infrastructures fondamentales --- divers Dapps.
Les infrastructures de base comprennent :
Au-dessus des infrastructures de base se trouvent divers services de paiement et financiers ainsi que des applications, par exemple, Strike est construit sur la solution LND qui permet aux utilisateurs d'acheter et de vendre des BTC, d'utiliser des BTC pour récompenser les créateurs sur Twitter et de permettre aux commerçants de Shopify d'accepter des BTC, etc.
Jusqu'en novembre 2022,