La vision future de la blockchain est la décentralisation, la sécurité et l'évolutivité, mais il est généralement possible d'en réaliser seulement deux, ce qui est appelé le 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 du processus de développement actuel de la blockchain.
Définition de la décentralisation, de la sécurité et de l'évolutivité de la blockchain:
Décentralisation : Toute personne 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é, garantissant que le réseau n'est pas contrôlé par un petit nombre de 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 forte, la chaîne peut résister à un plus grand pourcentage d'attaques des participants.
Scalabilité : la capacité de la blockchain à traiter un grand nombre de transactions.
La première grande hard fork du réseau Bitcoin provient d'un problème de scalabilité. 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é à rencontrer des problèmes de congestion ; à partir de 2015, la communauté Bitcoin était divisée sur la question de la scalabilité, d'une part, il y avait ceux qui soutenaient l'expansion des blocs, appelés partisans de l'augmentation de la taille des blocs, et d'autre part, ceux qui soutenaient l'utilisation de la solution Segwit avec des petits blocs. Le 1er août 2017, les partisans de l'expansion ont développé et commencé à faire fonctionner un système client de 8 Mo, ce qui a conduit à la première grande hard fork de l'histoire de Bitcoin, donnant naissance à une nouvelle cryptomonnaie, le BCH.
Le réseau Ethereum a également choisi de sacrifier une partie de sa scalabilité 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 fixant un plafond sur les frais de carburant pouvant être acceptés par un seul bloc. Cependant, l'objectif reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds.
Depuis CryptoKitties en 2017, l'été DeFi, jusqu'à l'essor ultérieur des applications on-chain telles que GameFi et NFT, la demande du marché pour le 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 continue 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. 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 d'urgence. La solution d'évolutivité idéale est : augmenter autant que possible la vitesse des transactions et le débit des transactions du réseau blockchain, sans sacrifier la décentralisation et la sécurité.
2. Catégories des solutions d'extension
Nous classons les solutions d'extension en deux grandes catégories : l'extension on-chain et l'extension off-chain, selon le critère "si cela change un niveau de la chaîne principale".
2.1 Scalabilité on-chain
Concept central : 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éveloppera pas, mais en énumérera brièvement deux :
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 pour les équipements de 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 grand livre 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 simultanément ; cela réduit 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 est dispersée sur l'ensemble du réseau, ce qui peut réduire 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 faille de sécurité sous-jacente peut gravement menacer la sécurité de l'ensemble du réseau, qui peut être contraint de se diviser ou d'interrompre les mises à jour de réparation. Par exemple, l'incident de la faille d'inflation de Zcash en 2018 : le code de Zcash est basé sur le code modifié de la version 0.11.2 de Bitcoin. En 2018, un ingénieur a découvert une faille critique dans le code sous-jacent, à savoir que les jetons pouvaient être émis sans limite, et l'équipe a ensuite passé 8 mois à corriger secrètement le problème, avant de rendre cet incident public après la correction de la faille.
2.2 off-chain scalabilité
Concept clé : solution d'extensibilité qui ne modifie pas le protocole de la couche principale existante.
La solution d'extension off-chain peut être subdivisée en Layer2 et d'autres solutions :
3. Solutions d'extensibilité 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. Les interactions entre utilisateurs sont effectuées 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 des protocoles P2P simples, adaptés aux "applications basées sur des tours", par exemple, un jeu d'échecs à deux joueurs. 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 litiges entre les participants ( selon les preuves de fraude accompagnées de signatures et de timestamps ). 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é et confirmé, le canal est officiellement ouvert. Le canal permet des transactions hors chaîne gratuites et 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, 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 complétée. Normalement, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la blockchain principale, elles ne dépendent de la confirmation de la blockchain principale qu'en cas de litige ou de fermeture du canal. Lorsque la fermeture du canal est nécessaire, l'un des participants peut soumettre une demande de transaction sur la blockchain principale, et si la demande de retrait reçoit l'approbation de tous par signature unanime, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants en fonction des soldes de chaque participant à l'état final du canal ; si d'autres participants n'ont pas approuvé par signature, alors tous doivent attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, la solution de canal d'état peut considérablement réduire la charge de calcul du réseau principal, améliorer la vitesse des transactions et réduire le coût des transactions.
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 d'abord résumé de manière systématique 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 une solution d'extension 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 sur les State Channels 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, c'est le premier design entièrement lié aux State Channels.
2018/10, l'article Generalised State Channel Networks a introduit les concepts de State Channel Networks et de Virtual Channels.
2019/02, le concept de 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 continu.
2020/03, Hydra a proposé des canaux isomorphes rapides.
)# 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 blockchain principale, les utilisateurs modifient l'état du contrat intelligent en envoyant des transactions sur la chaîne. L'inconvénient est qu'il entraîne les problèmes de temps et de coût discutés ci-dessus.
![Rapport de recherche en profondeur : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.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 en chaîne.
Première étape, Alice et Bob interagissent en déposant des fonds de leur EOA personnel à l'adresse de contrat en chaîne ), 1,2(, ces fonds étant verrouillés dans le contrat jusqu'à ce que le canal soit fermé et que le solde soit retourné aux utilisateurs ; après confirmation par signature, le canal d'état entre les deux est officiellement ouvert.
Deuxième étape, Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions hors chaîne via ce canal ) ligne bleue pointillée (, 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 fraudes par 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.
Troisième étape, si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre l'état final de son compte ) à l'accord, interaction 3(. Si Bob signe et approuve, le contrat libérera les fonds bloqués en fonction de l'état final et les renverra à l'utilisateur correspondant ), interaction 4,5(. Si Bob ne répond pas à la signature, le contrat libérera les fonds bloqués après la fin de la période de contestation et les renverra à l'utilisateur correspondant.
![Rapport de recherche approfondi : Analyse complète de l'expansion off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
La figure 3 montre le flux de travail d'un canal d'état dans un scénario 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 de l'état signée envoyée par Alice ) interaction 3(, à ce moment-là, Alice peut initier un défi en soumettant la dernière mise à jour d'état valide au contrat ) interaction 4(, cette mise à jour d'état valide contient é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 dans un certain laps de temps en soumettant le prochain état au contrat ; si Bob répond, alors les deux peuvent continuer à effectuer des transactions dans le canal d'état ; si Bob ne répond pas dans ce délai, le contrat ferme automatiquement le canal d'état et renvoie 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-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Avantages et inconvénients
Avantages:
Détermination instantanée
Frais très bas
Bonne confidentialité
Haute évolutivité
Flexibilité élevée
Inconvénients:
Tous les participants doivent être en ligne en continu.
Pas adapté aux calculs complexes
Le coût initial de la création d'un canal est élevé
Mauvaise évolutivité
Un fonds de pré-stockage est nécessaire
3.1.5 Application
Réseau Lightning de Bitcoin
Aperçu :
Le réseau Lightning est un canal de paiement de faible montant sur le réseau Bitcoin, dont l'évolution technologique globale a connu : la construction d'un canal de paiement unidirectionnel à 2/2 signatures multiples, l'ajout de RSMC### Revocable Sequence Maturity Contract( permettant de construire un canal de paiement bidirectionnel, puis l'ajout de HTLC) Hash Time Lock Contract( permettant d'étendre le canal de paiement à plusieurs personnes, et enfin la construction d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce à des canaux de paiement de faible montant off-chain, et en profitant d'intermédiaires pour former 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 "Dépôt) Établir un canal( → Transactions du réseau Lightning) Mettre à jour l'état du canal( → Remboursement/Règlement) Fin 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é le brouillon du livre blanc du réseau Lightning;
La version finale 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, Lightning Network Daemon )LND( version 0.4.
Au début de 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.
8 J'aime
Récompense
8
6
Partager
Commentaire
0/400
ChainWanderingPoet
· Il y a 1h
Cette question triangulaire tourne encore en rond.
Voir l'originalRépondre0
SandwichTrader
· Il y a 9h
Je n'ai même pas compris un seul niveau, l'extension, haha, qu'est-ce que c'est.
Voir l'originalRépondre0
PumpStrategist
· 07-27 12:11
Encore une fois le vieux piège de la Trinité impie, pas de percée sur le plan technique.
Voir l'originalRépondre0
fork_in_the_road
· 07-27 12:04
Ils travaillent encore sur l'extension.
Voir l'originalRépondre0
TokenTaxonomist
· 07-27 12:04
statistiquement parlant, 99,7 % des scaling solutions échouent à l'optimisation du trilemme...
Voir l'originalRépondre0
Anon32942
· 07-27 11:54
Après avoir parlé pendant un moment, c'est juste un triangle.
Analyse approfondie des solutions d'extension off-chain : State Channels et Bitcoin Lightning Network
Analyse approfondie de l'extensibilité off-chain
Auteur : Cobo Ventures
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 généralement possible d'en réaliser seulement deux, ce qui est appelé le 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 du processus de développement actuel de la blockchain.
Définition de la décentralisation, de la sécurité et de l'évolutivité de la blockchain:
Décentralisation : Toute personne 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é, garantissant que le réseau n'est pas contrôlé par un petit nombre de 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 forte, la chaîne peut résister à un plus grand pourcentage d'attaques des participants.
Scalabilité : la capacité de la blockchain à traiter un grand nombre de transactions.
La première grande hard fork du réseau Bitcoin provient d'un problème de scalabilité. 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é à rencontrer des problèmes de congestion ; à partir de 2015, la communauté Bitcoin était divisée sur la question de la scalabilité, d'une part, il y avait ceux qui soutenaient l'expansion des blocs, appelés partisans de l'augmentation de la taille des blocs, et d'autre part, ceux qui soutenaient l'utilisation de la solution Segwit avec des petits blocs. Le 1er août 2017, les partisans de l'expansion ont développé et commencé à faire fonctionner un système client de 8 Mo, ce qui a conduit à la première grande hard fork de l'histoire de Bitcoin, donnant naissance à une nouvelle cryptomonnaie, le BCH.
Le réseau Ethereum a également choisi de sacrifier une partie de sa scalabilité 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 fixant un plafond sur les frais de carburant pouvant être acceptés par un seul bloc. Cependant, l'objectif reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds.
Depuis CryptoKitties en 2017, l'été DeFi, jusqu'à l'essor ultérieur des applications on-chain telles que GameFi et NFT, la demande du marché pour le 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 continue 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. 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 d'urgence. La solution d'évolutivité idéale est : augmenter autant que possible la vitesse des transactions et le débit des transactions du réseau blockchain, sans sacrifier la décentralisation et la sécurité.
2. Catégories des solutions d'extension
Nous classons les solutions d'extension en deux grandes catégories : l'extension on-chain et l'extension off-chain, selon le critère "si cela change un niveau de la chaîne principale".
2.1 Scalabilité on-chain
Concept central : 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éveloppera pas, mais en énumérera brièvement deux :
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 pour les équipements de 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 grand livre 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 simultanément ; cela réduit 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 est dispersée sur l'ensemble du réseau, ce qui peut réduire 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 faille de sécurité sous-jacente peut gravement menacer la sécurité de l'ensemble du réseau, qui peut être contraint de se diviser ou d'interrompre les mises à jour de réparation. Par exemple, l'incident de la faille d'inflation de Zcash en 2018 : le code de Zcash est basé sur le code modifié de la version 0.11.2 de Bitcoin. En 2018, un ingénieur a découvert une faille critique dans le code sous-jacent, à savoir que les jetons pouvaient être émis sans limite, et l'équipe a ensuite passé 8 mois à corriger secrètement le problème, avant de rendre cet incident public après la correction de la faille.
2.2 off-chain scalabilité
Concept clé : solution d'extensibilité qui ne modifie pas le protocole de la couche principale existante.
La solution d'extension off-chain peut être subdivisée en Layer2 et d'autres solutions :
3. Solutions d'extensibilité 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. Les interactions entre utilisateurs sont effectuées 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 des protocoles P2P simples, adaptés aux "applications basées sur des tours", par exemple, un jeu d'échecs à deux joueurs. 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 litiges entre les participants ( selon les preuves de fraude accompagnées de signatures et de timestamps ). 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é et confirmé, le canal est officiellement ouvert. Le canal permet des transactions hors chaîne gratuites et 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, 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 complétée. Normalement, les mises à jour d'état convenues par les deux parties ne sont pas téléchargées sur la blockchain principale, elles ne dépendent de la confirmation de la blockchain principale qu'en cas de litige ou de fermeture du canal. Lorsque la fermeture du canal est nécessaire, l'un des participants peut soumettre une demande de transaction sur la blockchain principale, et si la demande de retrait reçoit l'approbation de tous par signature unanime, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants en fonction des soldes de chaque participant à l'état final du canal ; si d'autres participants n'ont pas approuvé par signature, alors tous doivent attendre la fin de la "période de contestation" pour recevoir les fonds restants.
En résumé, la solution de canal d'état peut considérablement réduire la charge de calcul du réseau principal, améliorer la vitesse des transactions et réduire le coût des transactions.
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 d'abord résumé de manière systématique 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 une solution d'extension 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 sur les State Channels 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, c'est le premier design entièrement lié aux State Channels.
2018/10, l'article Generalised State Channel Networks a introduit les concepts de State Channel Networks et de Virtual Channels.
2019/02, le concept de 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 continu.
2020/03, Hydra a proposé des canaux isomorphes rapides.
)# 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 blockchain principale, les utilisateurs modifient l'état du contrat intelligent en envoyant des transactions sur la chaîne. L'inconvénient est qu'il entraîne les problèmes de temps et de coût discutés ci-dessus.
![Rapport de recherche en profondeur : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.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 en chaîne.
Première étape, Alice et Bob interagissent en déposant des fonds de leur EOA personnel à l'adresse de contrat en chaîne ), 1,2(, ces fonds étant verrouillés dans le contrat jusqu'à ce que le canal soit fermé et que le solde soit retourné aux utilisateurs ; après confirmation par signature, le canal d'état entre les deux est officiellement ouvert.
Deuxième étape, Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions hors chaîne via ce canal ) ligne bleue pointillée (, 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 fraudes par 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.
Troisième étape, si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre l'état final de son compte ) à l'accord, interaction 3(. Si Bob signe et approuve, le contrat libérera les fonds bloqués en fonction de l'état final et les renverra à l'utilisateur correspondant ), interaction 4,5(. Si Bob ne répond pas à la signature, le contrat libérera les fonds bloqués après la fin de la période de contestation et les renverra à l'utilisateur correspondant.
![Rapport de recherche approfondi : Analyse complète de l'expansion off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(
La figure 3 montre le flux de travail d'un canal d'état dans un scénario 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 de l'état signée envoyée par Alice ) interaction 3(, à ce moment-là, Alice peut initier un défi en soumettant la dernière mise à jour d'état valide au contrat ) interaction 4(, cette mise à jour d'état valide contient é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 dans un certain laps de temps en soumettant le prochain état au contrat ; si Bob répond, alors les deux peuvent continuer à effectuer des transactions dans le canal d'état ; si Bob ne répond pas dans ce délai, le contrat ferme automatiquement le canal d'état et renvoie 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-815c5eb2bdba725e04eebe67b22d42aa.webp(
)# 3.1.4 Avantages et inconvénients
Avantages:
Inconvénients:
3.1.5 Application
Réseau Lightning de Bitcoin
Aperçu :
Le réseau Lightning est un canal de paiement de faible montant sur le réseau Bitcoin, dont l'évolution technologique globale a connu : la construction d'un canal de paiement unidirectionnel à 2/2 signatures multiples, l'ajout de RSMC### Revocable Sequence Maturity Contract( permettant de construire un canal de paiement bidirectionnel, puis l'ajout de HTLC) Hash Time Lock Contract( permettant d'étendre le canal de paiement à plusieurs personnes, et enfin la construction d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce à des canaux de paiement de faible montant off-chain, et en profitant d'intermédiaires pour former 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 "Dépôt) Établir un canal( → Transactions du réseau Lightning) Mettre à jour l'état du canal( → Remboursement/Règlement) Fin du canal(" ; théoriquement, le réseau Lightning peut traiter un million de transactions par seconde.
Chronologie: