Auteur : Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. La nécessité de l'expansion
La vision future de la blockchain est la décentralisation, la sécurité et l'évolutivité. Mais généralement, la blockchain ne peut réaliser que deux de ces trois objectifs, ce qui est connu sous le nom de problème du triangle impossible de la blockchain. Depuis des années, les gens explorent comment augmenter 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 d'actualité dans le processus de développement actuel de la blockchain.
Définissons d'abord la décentralisation, la sécurité et l'évolutivité de la blockchain :
Décentralisation : Tout le monde peut devenir un nœud et participer au système blockchain, plus il y a de nœuds, plus le degré de décentralisation est élevé, garantissant que le réseau n'est pas contrôlé par un petit nombre de participants.
Sécurité : plus le coût d'acquisition du contrôle d'un système blockchain est élevé, plus la sécurité est élevée, la chaîne peut résister à une plus grande proportion d'attaques de participants.
Scalabilité : capacité de la blockchain à traiter un grand nombre de transactions.
La première importante bifurcation dure du réseau Bitcoin provient du problème de l'extension. Avec l'augmentation du nombre d'utilisateurs de Bitcoin et du volume des transactions, le réseau avec une limite de bloc de 1 Mo a commencé à faire face à des congestions. À partir de 2015, la communauté Bitcoin a eu des divergences sur le problème de l'extension, une partie soutenant l'élargissement des blocs, tandis que l'autre partie soutenait l'utilisation de Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, la partie en faveur des grands blocs a développé de manière autonome un système client de 8 Mo qui a commencé à fonctionner, entraînant la première importante bifurcation dure de Bitcoin et donnant naissance à la nouvelle cryptomonnaie BCH.
De même, le réseau Ethereum a également sacrifié une partie de sa capacité d'évolutivité pour garantir la sécurité et la décentralisation du réseau, en imposant une limite aux frais de transaction pouvant être inclus dans un seul bloc pour restreindre le volume des transactions. L'objectif est d'atteindre un consensus sans confiance et de garantir une large distribution des nœuds.
Depuis les CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure des applications en chaîne comme GameFi et NFT, la demande du marché pour le débit n'a cessé d'augmenter, mais Ethereum ne peut toujours traiter que 15 à 45 transactions par seconde. Cela a entraîné une augmentation des coûts de transaction, des temps de règlement plus longs, et la plupart des DApps ont du mal à supporter les coûts d'exploitation, rendant l'ensemble du réseau lent et cher pour les utilisateurs, et le problème de l'extensibilité de la blockchain doit être résolu en urgence. La solution d'extensibilité idéale est d'augmenter autant que possible la vitesse des transactions et le débit du réseau blockchain 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 grandes catégories : l'extension on-chain et l'extension off-chain, en nous basant sur le critère "si la couche principale du réseau est modifiée".
2.1 Scalabilité on-chain
Concept clé : une solution visant à augmenter la capacité en modifiant un niveau 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éveloppe pas, mais en énumère brièvement deux :
La première solution consiste à élargir l'espace de bloc, en augmentant le nombre de transactions empaquetées dans chaque bloc, mais cela augmentera les exigences en matière de matériel pour les nœuds haute performance, augmentant 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 grand livre de la blockchain en plusieurs parties, chaque shard étant responsable de la comptabilité différente, et le calcul parallèle peut traiter plusieurs transactions simultanément. Cela peut réduire la pression de calcul des nœuds et le seuil d'entrée, améliorer la vitesse de traitement des transactions et le degré de décentralisation, mais cela diminuera la "sécurité" de l'ensemble du réseau.
Modifier le protocole de la couche principale du réseau peut avoir des conséquences négatives imprévisibles, car toute légère vulnérabilité de sécurité à la base peut gravement menacer la sécurité de l'ensemble du réseau. Par exemple, l'incident de la vulnérabilité d'inflation de Zcash en 2018 : le code de Zcash est basé sur une modification de la version 0.11.2 de Bitcoin, et en 2018, une vulnérabilité critique a été découverte dans son code sous-jacent, permettant l'émission illimitée de jetons. L'équipe a passé 8 mois à corriger cette faille en secret, et l'incident n'a été rendu public qu'après la réparation.
2.2 off-chain scalabilité
Concept clé : solution de mise à l'échelle qui ne modifie pas le protocole de la couche principale existante.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et d'autres solutions :
3. Solutions d'extension off-chain
3.1 Canaux d'État
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 de litiges, et que les interactions entre utilisateurs se font hors chaîne, 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. Chaque canal est géré par un contrat intelligent multisignature fonctionnant sur la chaîne principale, qui contrôle les actifs déposés dans le canal, vérifie les mises à jour de l'état et arbitre les litiges entre les participants ( en fonction de la preuve de fraude avec signatures et horodatages ). Après le déploiement du contrat sur le réseau blockchain, les participants déposent des fonds et les verrouillent. Une fois les deux parties ayant signé et confirmé, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions off-chain gratuites ( tant que leur valeur nette de transfert ne dépasse pas le total des jetons déposés ). Les participants envoient à tour de rôle des mises à jour d'état à l'autre partie, en attendant la confirmation de signature. Une fois que l'autre partie a signé et confirmé, cette mise à jour d'état est considérée comme terminée. Normalement, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la chaîne principale; elles ne sont confirmées sur la chaîne principale qu'en cas de litige ou de fermeture du canal. Pour fermer le canal, n'importe quel participant peut soumettre une demande de transaction sur la chaîne principale, et si la demande de retrait reçoit l'approbation par signature unanime, l'exécution sur la chaîne se fait immédiatement, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants en fonction des soldes de chaque participant dans l'état final du canal; si les autres participants n'ont pas signé pour approuver, tous doivent attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, la solution des canaux d'état peut considérablement réduire la charge de calcul du réseau principal, augmenter la vitesse des transactions et diminuer 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 d'abord résumé de manière systématique le concept de State Channel, suggérant 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'évolutivité pour le réseau Lightning de Bitcoin, le Payment Channel (, ce qui est uniquement destiné à traiter les paiements de transfert sur le réseau Bitcoin.
En novembre 2017, la première spécification de conception de State Channel basée sur le cadre Payment Channel, appelée Sprites, a été proposée.
2018/06, Counterfactual a proposé un design très détaillé des Generalized State Channels, 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.
2019/02, le concept de canaux d'état a été étendu aux N-Party Channels, Nitro est le premier protocole basé 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 continu.
2020/03, Hydra a proposé des Fast Isomorphic Channels.
)# 3.1.3 Principes techniques
La figure 1 montre le flux de travail traditionnel sur la chaîne : Alice et Bob interagissent avec un contrat intelligent déployé 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 les problèmes de temps et de coûts discutés ci-dessus.
![Rapport d'étude approfondi : Analyse complète de l'expansion off-chain]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp(
La figure 2 montre le flux de travail général suivi par la plupart des protocoles de canaux d'état : dans un scénario optimiste, Alice et Bob doivent effectuer les mêmes opérations qu'auparavant, mais cette fois, ils utilisent un canal d'état au lieu d'interagir avec un contrat sur la chaîne.
Première étape, Alice et Bob interagissent en déposant des fonds de leur EOA personnel à l'adresse du contrat on-chain ), 1,2(, ces fonds sont bloqué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.
La deuxième étape, Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions off-chain via ce canal ) ligne bleue (, les participants communiquent entre eux par des messages signés cryptés ) plutôt que de communiquer avec le réseau blockchain (. Chaque utilisateur doit signer chaque transaction pour éviter les doubles dépenses malveillantes. À 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.
Troisième étape, si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre à l'accord l'état final de son compte ) interaction 3(, si Bob signe pour approbation, l'accord libérera les fonds verrouillés en fonction de l'état final et les renverra à l'utilisateur correspondant ) interaction 4,5(. Si Bob ne répond pas par une signature, l'accord libérera les fonds verrouillés et les renverra à l'utilisateur correspondant à la fin de la période de contestation.
![Rapport de recherche approfondi : analyse complète de l'extension off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
La figure 3 montre le flux de travail du canal d'état dans le cas pessimiste : au départ, deux participants déposent des fonds ) interaction 1, 2(, puis commencent à échanger des mises à jour d'état ) ligne bleue pointillée (. Supposons qu'à un moment donné, Bob ne réponde pas à la mise à jour d'état signée envoyée par Alice ) interaction 3(, à ce moment-là, Alice peut lancer un défi en soumettant son dernier état valide au contrat ) interaction 4(, 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 pendant une certaine période en soumettant le prochain état au contrat ; 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 retourne les fonds à Alice ) interaction 5(.
![Rapport de recherche approfondi : Analyse complète de l'extension off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
)# 3.1.4 Avantages et inconvénients
Avantages :
Instantanéité : les transactions off-chain sont presque instantanées
Scalabilité : le nombre de transactions off-chain n'est pas limité
Confidentialité : seul l'état final du canal sera enregistré sur la chaîne
Faibles frais : Réduit considérablement les frais de transaction on-chain.
Inconvénients:
Disponibilité : Les participants doivent être en ligne en permanence pour répondre aux défis des adversaires.
Efficacité des fonds : nécessite de verrouiller des fonds
Risque de centralisation : le développement à long terme du réseau de canaux peut entraîner le fait que certains nœuds deviennent des "nœuds" centralisés.
Complexité : le mécanisme de mise à jour de l'état est relativement complexe
3.1.5 Application
Réseau Lightning Bitcoin
Aperçu:
Le réseau Lightning est un canal de paiement à faible montant sur le réseau Bitcoin, dont l'évolution technologique globale a connu : la construction d'un canal de paiement unidirectionnel par signature multiple 2/2, l'ajout du RSMC###Revocable Sequence Maturity Contract( permettant de construire un canal de paiement bidirectionnel, puis l'ajout du HTLC)Hash Time Lock Contract( permettant d'étendre les canaux de paiement à plusieurs utilisateurs, et enfin la construction d'un réseau de paiements, c'est-à-dire le réseau Lightning. Grâce aux canaux de paiement à faible montant off-chain, puis en s'appuyant sur des intermédiaires pour constituer un réseau de transactions, il est possible de résoudre le problème de scalabilité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus suivant : "Dépôt) établir un canal( → transactions du réseau Lightning) mettre à jour l'état du canal( → remboursement/settlement) 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 publié la première version du réseau Lightning mainnet, Lightning Network Daemon )LND( version 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 utilisant le réseau Lightning.
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 de trading de cryptomonnaies, y compris OKX, Kraken et Bitfinex, ont annoncé le soutien au réseau Lightning, permettant des dépôts et retraits de BTC instantanés et peu coûteux.
En octobre 2022, Lightning Labs a lancé un nouveau protocole basé sur Taproot -- la version alpha du protocole Taro), objectif
Voir l'original
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.
21 J'aime
Récompense
21
7
Partager
Commentaire
0/400
SandwichHunter
· 07-09 12:24
Trinité impie vrai, c'est-à-dire que cela ne peut pas être résolu.
Voir l'originalRépondre0
SatoshiLegend
· 07-06 18:53
Exploration de la blockchain de deuxième couche redémarrée.... L'idée du Lightning Network de Satoshi Nakamoto en 2006 avait en fait semé des graines ici.
Voir l'originalRépondre0
ForkTongue
· 07-06 18:51
Ah, c'est vraiment ce triangle éternel et immuable.
Voir l'originalRépondre0
retroactive_airdrop
· 07-06 18:50
Le plus difficile à gérer dans le dilemme triangulaire est cette extension.
Voir l'originalRépondre0
MemeEchoer
· 07-06 18:48
Ce triangle n'est pas un problème, c'est le quatrième angle qui l'est.
Voir l'originalRépondre0
LiquidityWizard
· 07-06 18:45
Le problème triangulaire est vraiment trop difficile à résoudre...
Voir l'originalRépondre0
ruggedNotShrugged
· 07-06 18:41
Encore en train de parler de l'impossible triangle.
Analyse complète des solutions d'extension off-chain : canal d'état, Lightning Network et leur histoire de développement
Analyse approfondie de l'extension off-chain
Auteur : Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin
1. La nécessité de l'expansion
La vision future de la blockchain est la décentralisation, la sécurité et l'évolutivité. Mais généralement, la blockchain ne peut réaliser que deux de ces trois objectifs, ce qui est connu sous le nom de problème du triangle impossible de la blockchain. Depuis des années, les gens explorent comment augmenter 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 d'actualité dans le processus de développement actuel de la blockchain.
Définissons d'abord la décentralisation, la sécurité et l'évolutivité de la blockchain :
Décentralisation : Tout le monde peut devenir un nœud et participer au système blockchain, plus il y a de nœuds, plus le degré de décentralisation est élevé, garantissant que le réseau n'est pas contrôlé par un petit nombre de participants.
Sécurité : plus le coût d'acquisition du contrôle d'un système blockchain est élevé, plus la sécurité est élevée, la chaîne peut résister à une plus grande proportion d'attaques de participants.
Scalabilité : capacité de la blockchain à traiter un grand nombre de transactions.
La première importante bifurcation dure du réseau Bitcoin provient du problème de l'extension. Avec l'augmentation du nombre d'utilisateurs de Bitcoin et du volume des transactions, le réseau avec une limite de bloc de 1 Mo a commencé à faire face à des congestions. À partir de 2015, la communauté Bitcoin a eu des divergences sur le problème de l'extension, une partie soutenant l'élargissement des blocs, tandis que l'autre partie soutenait l'utilisation de Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, la partie en faveur des grands blocs a développé de manière autonome un système client de 8 Mo qui a commencé à fonctionner, entraînant la première importante bifurcation dure de Bitcoin et donnant naissance à la nouvelle cryptomonnaie BCH.
De même, le réseau Ethereum a également sacrifié une partie de sa capacité d'évolutivité pour garantir la sécurité et la décentralisation du réseau, en imposant une limite aux frais de transaction pouvant être inclus dans un seul bloc pour restreindre le volume des transactions. L'objectif est d'atteindre un consensus sans confiance et de garantir une large distribution des nœuds.
Depuis les CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure des applications en chaîne comme GameFi et NFT, la demande du marché pour le débit n'a cessé d'augmenter, mais Ethereum ne peut toujours traiter que 15 à 45 transactions par seconde. Cela a entraîné une augmentation des coûts de transaction, des temps de règlement plus longs, et la plupart des DApps ont du mal à supporter les coûts d'exploitation, rendant l'ensemble du réseau lent et cher pour les utilisateurs, et le problème de l'extensibilité de la blockchain doit être résolu en urgence. La solution d'extensibilité idéale est d'augmenter autant que possible la vitesse des transactions et le débit du réseau blockchain 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 grandes catégories : l'extension on-chain et l'extension off-chain, en nous basant sur le critère "si la couche principale du réseau est modifiée".
2.1 Scalabilité on-chain
Concept clé : une solution visant à augmenter la capacité en modifiant un niveau 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éveloppe pas, mais en énumère brièvement deux :
La première solution consiste à élargir l'espace de bloc, en augmentant le nombre de transactions empaquetées dans chaque bloc, mais cela augmentera les exigences en matière de matériel pour les nœuds haute performance, augmentant 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 grand livre de la blockchain en plusieurs parties, chaque shard étant responsable de la comptabilité différente, et le calcul parallèle peut traiter plusieurs transactions simultanément. Cela peut réduire la pression de calcul des nœuds et le seuil d'entrée, améliorer la vitesse de traitement des transactions et le degré de décentralisation, mais cela diminuera la "sécurité" de l'ensemble du réseau.
Modifier le protocole de la couche principale du réseau peut avoir des conséquences négatives imprévisibles, car toute légère vulnérabilité de sécurité à la base peut gravement menacer la sécurité de l'ensemble du réseau. Par exemple, l'incident de la vulnérabilité d'inflation de Zcash en 2018 : le code de Zcash est basé sur une modification de la version 0.11.2 de Bitcoin, et en 2018, une vulnérabilité critique a été découverte dans son code sous-jacent, permettant l'émission illimitée de jetons. L'équipe a passé 8 mois à corriger cette faille en secret, et l'incident n'a été rendu public qu'après la réparation.
2.2 off-chain scalabilité
Concept clé : solution de mise à l'échelle qui ne modifie pas le protocole de la couche principale existante.
Les solutions d'extension off-chain peuvent être subdivisées en Layer2 et d'autres solutions :
3. Solutions d'extension off-chain
3.1 Canaux d'État
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 de litiges, et que les interactions entre utilisateurs se font hors chaîne, 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. Chaque canal est géré par un contrat intelligent multisignature fonctionnant sur la chaîne principale, qui contrôle les actifs déposés dans le canal, vérifie les mises à jour de l'état et arbitre les litiges entre les participants ( en fonction de la preuve de fraude avec signatures et horodatages ). Après le déploiement du contrat sur le réseau blockchain, les participants déposent des fonds et les verrouillent. Une fois les deux parties ayant signé et confirmé, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions off-chain gratuites ( tant que leur valeur nette de transfert ne dépasse pas le total des jetons déposés ). Les participants envoient à tour de rôle des mises à jour d'état à l'autre partie, en attendant la confirmation de signature. Une fois que l'autre partie a signé et confirmé, cette mise à jour d'état est considérée comme terminée. Normalement, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la chaîne principale; elles ne sont confirmées sur la chaîne principale qu'en cas de litige ou de fermeture du canal. Pour fermer le canal, n'importe quel participant peut soumettre une demande de transaction sur la chaîne principale, et si la demande de retrait reçoit l'approbation par signature unanime, l'exécution sur la chaîne se fait immédiatement, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants en fonction des soldes de chaque participant dans l'état final du canal; si les autres participants n'ont pas signé pour approuver, tous doivent attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, la solution des canaux d'état peut considérablement réduire la charge de calcul du réseau principal, augmenter la vitesse des transactions et diminuer 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 d'abord résumé de manière systématique le concept de State Channel, suggérant 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'évolutivité pour le réseau Lightning de Bitcoin, le Payment Channel (, ce qui est uniquement destiné à traiter les paiements de transfert sur le réseau Bitcoin.
En novembre 2017, la première spécification de conception de State Channel basée sur le cadre Payment Channel, appelée Sprites, a été proposée.
2018/06, Counterfactual a proposé un design très détaillé des Generalized State Channels, 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.
2019/02, le concept de canaux d'état a été étendu aux N-Party Channels, Nitro est le premier protocole basé 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 continu.
2020/03, Hydra a proposé des Fast Isomorphic Channels.
)# 3.1.3 Principes techniques
La figure 1 montre le flux de travail traditionnel sur la chaîne : Alice et Bob interagissent avec un contrat intelligent déployé 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 les problèmes de temps et de coûts discutés ci-dessus.
![Rapport d'étude approfondi : Analyse complète de l'expansion off-chain]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp(
La figure 2 montre le flux de travail général suivi par la plupart des protocoles de canaux d'état : dans un scénario optimiste, Alice et Bob doivent effectuer les mêmes opérations qu'auparavant, mais cette fois, ils utilisent un canal d'état au lieu d'interagir avec un contrat sur la chaîne.
Première étape, Alice et Bob interagissent en déposant des fonds de leur EOA personnel à l'adresse du contrat on-chain ), 1,2(, ces fonds sont bloqué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.
La deuxième étape, Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions off-chain via ce canal ) ligne bleue (, les participants communiquent entre eux par des messages signés cryptés ) plutôt que de communiquer avec le réseau blockchain (. Chaque utilisateur doit signer chaque transaction pour éviter les doubles dépenses malveillantes. À 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.
Troisième étape, si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre à l'accord l'état final de son compte ) interaction 3(, si Bob signe pour approbation, l'accord libérera les fonds verrouillés en fonction de l'état final et les renverra à l'utilisateur correspondant ) interaction 4,5(. Si Bob ne répond pas par une signature, l'accord libérera les fonds verrouillés et les renverra à l'utilisateur correspondant à la fin de la période de contestation.
![Rapport de recherche approfondi : analyse complète de l'extension off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
La figure 3 montre le flux de travail du canal d'état dans le cas pessimiste : au départ, deux participants déposent des fonds ) interaction 1, 2(, puis commencent à échanger des mises à jour d'état ) ligne bleue pointillée (. Supposons qu'à un moment donné, Bob ne réponde pas à la mise à jour d'état signée envoyée par Alice ) interaction 3(, à ce moment-là, Alice peut lancer un défi en soumettant son dernier état valide au contrat ) interaction 4(, 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 pendant une certaine période en soumettant le prochain état au contrat ; 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 retourne les fonds à Alice ) interaction 5(.
![Rapport de recherche approfondi : Analyse complète de l'extension 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 à faible montant sur le réseau Bitcoin, dont l'évolution technologique globale a connu : la construction d'un canal de paiement unidirectionnel par signature multiple 2/2, l'ajout du RSMC###Revocable Sequence Maturity Contract( permettant de construire un canal de paiement bidirectionnel, puis l'ajout du HTLC)Hash Time Lock Contract( permettant d'étendre les canaux de paiement à plusieurs utilisateurs, et enfin la construction d'un réseau de paiements, c'est-à-dire le réseau Lightning. Grâce aux canaux de paiement à faible montant off-chain, puis en s'appuyant sur des intermédiaires pour constituer un réseau de transactions, il est possible de résoudre le problème de scalabilité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus suivant : "Dépôt) établir un canal( → transactions du réseau Lightning) mettre à jour l'état du canal( → remboursement/settlement) terminer le canal(" ; théoriquement, le réseau Lightning peut traiter un million de transactions par seconde.
Chronologie :