Analyse approfondie de l'extension off-chain

1. La nécessité de l'extension

La vision future de la blockchain est la décentralisation, la sécurité et l'évolutivité, mais il est généralement possible d'en réaliser seulement deux, ce qui est appelé le problème du triangle impossible. 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é, qui est l'un des sujets chauds dans le 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. 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 grands participants centralisés.

• Sécurité : Plus le coût d'obtention du contrôle du système est élevé, plus la sécurité est élevée, la chaîne peut résister à une proportion plus importante 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 est née d'un problème d'évolutivité. Avec l'augmentation du nombre d'utilisateurs et du volume de transactions, le réseau Bitcoin, avec une limite de 1 Mo par bloc, a commencé à faire face à des problèmes de congestion ; à partir de 2015, la communauté Bitcoin a eu des divergences sur la question de l'évolutivité, certains soutenant l'augmentation de la taille des blocs, tandis que d'autres pensaient qu'il fallait utiliser la solution Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, Bitcoin ABC, qui soutenait l'augmentation de la taille des blocs, a lancé son système client de 8 Mo, entraînant la première grande hard fork de l'histoire de Bitcoin, donnant naissance à la nouvelle cryptomonnaie BCH.

Le réseau Ethereum choisit également de sacrifier une partie de l'évolutivité pour garantir la sécurité et la décentralisation du réseau. Bien que le réseau Ethereum ne limite pas le volume des transactions en restreignant la taille des blocs comme le fait le réseau Bitcoin, il a en quelque sorte transformé cela en établissant un plafond sur les frais de carburant pouvant être inclus dans un seul bloc, mais l'objectif reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds.

Depuis le CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure d'applications on-chain comme GameFi et NFT, la demande du marché en matière de débit augmente constamment. Cependant, même l'Ethereum, qui est Turing-complet, ne peut traiter que 15 à 45 transactions par seconde (TPS), ce qui entraîne une augmentation des coûts de transaction et un allongement des temps de règlement. La plupart des Dapps ont du mal à supporter les coûts d'exploitation, et l'ensemble du réseau devient lent et coûteux pour les utilisateurs. Le problème de l'extensibilité de la blockchain nécessite une solution urgente. La solution d'extensibilité idéale est d'augmenter la vitesse des transactions et le débit des transactions du réseau autant que possible, sans sacrifier la décentralisation et la sécurité.

2. Catégories des solutions d'extensibilité

Nous classons les solutions d'augmentation de la capacité en deux grandes catégories : l'augmentation de la capacité on-chain et l'augmentation de la capacité off-chain, en nous basant sur le critère "si cela modifie une couche de la chaîne principale".

2.1 extension on-chain

Concept central : une solution d'extension des capacités en modifiant un niveau du protocole de la chaîne principale, la principale solution actuelle étant le sharding.

Il existe plusieurs solutions d'extension on-chain, cet article ne sera pas développé, voici un bref aperçu de deux solutions :

• La première solution consiste à élargir l'espace de bloc, c'est-à-dire à augmenter le nombre de transactions packagées dans chaque bloc, mais cela augmentera les exigences pour les équipements de nœuds haute performance, augmentera le seuil d'entrée pour les nœuds et diminuera le degré de "décentralisation".

• La solution deux est le sharding, qui divise le grand livre blockchain en plusieurs parties, où chaque nœud ne participe plus à l'enregistrement de toutes les transactions, mais où différents shards, c'est-à-dire différents nœuds, sont responsables de l'enregistrement de différentes transactions. Le calcul parallèle peut traiter plusieurs transactions simultanément ; cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, tout en améliorant la vitesse de traitement des transactions et le degré de décentralisation. Cependant, cela signifie que la puissance de calcul de l'ensemble du réseau est dispersée, ce qui pourrait réduire la "sécurité" de l'ensemble du réseau.

Modifier le code du protocole principal d'un réseau peut avoir des conséquences négatives imprévisibles, car toute faille de sécurité, même minime, dans la couche sous-jacente peut gravement menacer la sécurité de l'ensemble du réseau. Le réseau pourrait être contraint de procéder à une fourche ou à une mise à niveau de réparation interrompue. Par exemple, l'incident de vulnérabilité d'inflation de Zcash en 2018 : le code de Zcash est basé sur une modification du code de la version 0.11.2 de Bitcoin. En 2018, un ingénieur a découvert une vulnérabilité critique dans le code sous-jacent, à savoir que les jetons pouvaient être émis sans limite. L'équipe a ensuite passé 8 mois à corriger secrètement le problème, et ce n'est qu'après la réparation de la vulnérabilité qu'elle a rendu cet incident public.

2.2 off-chain extensibilité

Concept clé : solution d'extension 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 doivent interagir avec la chaîne principale uniquement lors de l'ouverture, de la fermeture ou de la résolution des litiges, et que 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. Chaque canal est géré par un contrat intelligent multi-signatures fonctionnant sur la blockchain principale, qui contrôle les actifs déposés dans le canal, vérifie les mises à jour d'état et arbitre les litiges entre participants ( selon 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 une fois que les deux parties ont signé pour confirmer, le canal est officiellement ouvert. Le canal permet des transactions gratuites et illimitées hors chaîne ( tant que la valeur nette de leurs 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é pour confirmer, cette mise à jour d'état est considérée comme terminée. Normalement, les mises à jour d'état acceptées 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. 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 de tous les participants par signature, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds restants verrouillés selon le solde de chaque participant à l'état final du canal ; si d'autres participants n'acceptent pas la signature, alors tous doivent attendre la fin de la "période de défi" 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, améliorer la vitesse des transactions et diminuer 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.
• 2015/11, 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 » qui propose une solution d'extension pour le réseau Lightning de Bitcoin, le Payment Channel(, ce plan étant uniquement destiné à traiter les paiements de transfert sur le réseau Bitcoin.
• En novembre 2017, la première spécification de conception des State Channels basée sur le cadre Payment Channel, appelée Sprites, a été proposée.
• 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 s'est étendu aux N-Party Channels, Nitro est le premier protocole établi sur cette idée.
• 2019/10, Pisa a élargi le concept des 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 canaux isomorphes rapides.

)# 3.1.3 Principe technique

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 qu'il entraîne les problèmes de temps et de coûts discutés ci-dessus.

![Rapport d'analyse approfondie : Analyse complète de l'extension 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 le cas optimiste, Alice et Bob doivent exécuter les mêmes opérations qu'auparavant, mais cette fois, ils utilisent un canal d'état au lieu d'interagir avec un contrat on-chain.

• Première étape, Alice et Bob interagissent en déposant des fonds de leur EOA personnel à l'adresse du contrat en chaîne ), 1,2(, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment où le solde est restitué à l'utilisateur ; après confirmation des signatures, 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 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 éviter les doubles dépenses malveillantes. À travers ces messages, ils proposent des mises à jour de l'état de leur compte 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 ) interaction 3( au contrat. Si Bob signe pour approuver, 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 et les renverra à l'utilisateur correspondant après la fin de la période de contestation.

![Rapport d'analyse approfondie : Analyse complète de l'expansion off-chain])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(

La figure 3 montre le flux de travail d'un canal d'état dans un scénario pessimiste : au départ, les deux participants déposent des fonds ) interaction 1, 2(, puis commencent à échanger des mises à jour d'état ) ligne pointillée bleue (. 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 à l'accord son dernier état valide ) 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 parties peuvent continuer à effectuer des transactions dans le canal d'état ; si Bob ne répond pas dans cette période, le contrat ferme automatiquement le canal d'état et renvoie les fonds à Alice ) interaction 5(.

![Rapport de recherche en profondeur : Analyse complète de l'expansion off-chain])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(

)# 3.1.4 Avantages et inconvénients

Avantages:

• Haute extensibilité : transactions illimitées possibles
• Latence faible : transactions effectuées instantanément
• Coût bas : les transactions off-chain n'ont pratiquement aucun coût
• Confidentialité : les transactions off-chain ne seront pas enregistrées sur la chaîne principale
• Disponibilité : même si la chaîne principale rencontre des problèmes, le canal d'état reste utilisable.

Inconvénients:

• Verrouillage des fonds : les deux parties doivent verrouiller les fonds
• En ligne en continu : Les participants doivent être en ligne en continu pour surveiller l'état du canal.
• Coût de création de canal : l'ouverture d'un canal nécessite une interaction avec la chaîne principale, le coût est élevé.
• Délai de fermeture : la fermeture de la chaîne nécessite d'attendre la période de contestation
• Contrepartie limitée : le canal ne peut échanger qu'avec une contrepartie fixe.
• Pas adapté à une utilisation à grande échelle : pas convivial pour les utilisateurs ordinaires

3.1.5 Application

Réseau Lightning Bitcoin

Aperçu:

Le réseau Lightning est un canal de paiements de petite taille sur le réseau Bitcoin, dont l'évolution technique globale a traversé : la construction de canaux de paiement unidirectionnels avec une signature multiple 2/2, la possibilité de construire des canaux de paiement bidirectionnels après l'ajout du RSMC###Contrat de Maturité Séquentielle Révocable(, et l'extension des canaux de paiement à plusieurs utilisateurs après l'ajout de HTLC)Contrat de Verrouillage Temporel de Hachage(, pour finalement constituer un réseau de paiements, c'est-à-dire le réseau Lightning. Grâce à des canaux de paiements de petite taille off-chain, et à l'aide 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)établissement du canal(→transactions sur le réseau Lightning)mise à jour de l'état du canal(→remboursement/solde)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é un brouillon du livre blanc du réseau Lightning;
• La version officielle du livre blanc a été publiée en janvier 2016 et Lightning Labs a été fondée;
• Le 15 mars 2018, Lightning Labs a lancé la première version principale du réseau Lightning, le Lightning Network Daemon )LND( version 0.4.
• Début 2021, la capacité publique du réseau Lightning était de )TVL( d'environ 40 millions de dollars.