《off-chain扩容Depth解析》

Auteur : l'équipe de recherche

1. La nécessité de l'extension

L'avenir de la blockchain est une vision grandiose : décentralisation, sécurité et évolutivité ; mais généralement, la blockchain ne peut réaliser que deux de ces trois aspects, et satisfaire à ces trois exigences est ce qu'on appelle le triangle d'incompatibilité de la blockchain. Depuis des années, les gens explorent comment résoudre ce dilemme, 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 de discussion les plus chauds dans le développement actuel de la blockchain.

Définissons d'abord de manière générale la décentralisation, la sécurité et l'évolutivité de la blockchain :

• Décentralisation : Tout le monde 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 ainsi que le réseau n'est pas contrôlé par un petit groupe de grands participants centralisés.
• Sécurité : Plus le coût pour acquérir le contrôle d'un système blockchain est élevé, plus la sécurité est renforcée, permettant ainsi à la chaîne de résister à un plus grand pourcentage d'attaques de participants.
• Scalabilité : capacité de la blockchain à traiter un grand nombre de transactions.

La première grande hard fork du réseau Bitcoin est née du problème de scalabilité. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions de Bitcoin, le réseau Bitcoin, dont la taille maximale de chaque bloc est de 1 Mo, a commencé à faire face à des problèmes de congestion ; depuis 2015, la communauté Bitcoin est divisée sur la question de la scalabilité, d'un côté se trouvent les partisans de l'augmentation de la taille des blocs, représentés par Bitcoin ABC, et de l'autre, les partisans des petits blocs, représentés par Bitcoin Core, qui estiment qu'il convient d'optimiser la structure de la chaîne principale en utilisant la solution Segwit. Le 1er août 2017, le système client développé par Bitcoin ABC, capable de gérer des blocs de 8 Mo, a commencé à fonctionner, ce qui a conduit à la première grande hard fork de l'histoire de Bitcoin, donnant également naissance à la nouvelle cryptomonnaie BCH.

De même, le réseau Ethereum a également choisi de sacrifier une partie de l'évolutivité pour garantir la sécurité et la décentralisation du réseau ; bien que le réseau Ethereum ne limite pas le volume des transactions comme le fait le réseau Bitcoin en restreignant la taille des blocs, il a en quelque sorte évolué vers un plafond sur les frais de carburant pouvant être contenus dans un seul bloc, mais le but reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds. Quelle que soit l'annulation ou l'augmentation de la limite, cela éliminera de nombreux nœuds plus petits qui manquent de bande passante, de stockage et de capacité de calcul.

Depuis les CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure des applications en chaîne telles que GameFi et NFT, la demande du marché en matière de 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 constante des coûts de transaction, un allongement des temps de règlement, et la plupart des Dapps ont du mal à supporter leurs 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 de toute urgence. L'idéal pour une solution d'évolutivité est d'augmenter autant que possible la vitesse des transactions du réseau blockchain ( un temps de finalité plus court ) et un débit de transactions ( un TPS plus élevé ), sans sacrifier la décentralisation et la sécurité.

2. Types de 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 "si le changement d'un niveau de réseau principal" comme critère.

( 2.1 Scalabilité on-chain

Concept clé : une solution pour augmenter la capacité en modifiant un protocole de couche principale, la principale solution actuelle est le sharding.

Il existe plusieurs solutions pour l'extension on-chain, cet article ne va pas les développer, 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 emballées dans chaque bloc, mais cela augmentera les exigences pour les équipements des nœuds à haute performance, augmentera le seuil d'entrée pour les nœuds et réduira le degré de "décentralisation".
• La solution deux est le sharding, qui divise le grand livre de la blockchain en plusieurs parties, où chaque nœud ne participe plus à tous les enregistrements, mais 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 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 signifie que la puissance de calcul du réseau est dispersée, ce qui peut réduire la "sécurité" globale du réseau.

Modifier le code d'un protocole principal peut avoir des conséquences négatives imprévisibles, car la moindre vulnérabilité de sécurité au niveau sous-jacent peut menacer gravement la sécurité de l'ensemble du réseau, qui pourrait être contraint de subir un fork ou une interruption pour une mise à jour de réparation. Par exemple, l'incident de vulnérabilité d'inflation de Zcash en 2018 : le code de Zcash est basé sur une version modifiée du code de Bitcoin 0.11.2, et en 2018, un ingénieur a découvert une vulnérabilité critique dans le code sous-jacent, à savoir que les jetons pouvaient être émis indéfiniment. L'équipe a alors consacré 8 mois à un correctif secret, et l'incident n'a été rendu public qu'après la correction de la vulnérabilité.

) 2.2 off-chain extension

Concept clé : solution d'extensibilité 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 :

![Rapport de recherche en profondeur sur 10 000 mots : Analyse complète de l'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp###

3. Solutions d'extension off-chain

( 3.1 Canaux d'État

)# 3.1.1 Résumé

Les canaux d'état stipulent que l'utilisateur n'a besoin d'interagir avec la blockchain principale que lors de l'ouverture, de la fermeture ou de la résolution d'un litige, et que les interactions entre utilisateurs se font hors chaîne, afin de réduire le temps et le coût en argent 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", par exemple, un jeu d'échecs à deux personnes. 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 litiges entre les participants ### selon des preuves de fraude signées et horodatées ###. Après que les participants aient déployé le contrat sur le réseau blockchain, ils déposent des fonds et les verrouillent, et après confirmation par signature des deux parties, le canal est officiellement ouvert. Le canal permet des transactions off-chain gratuites illimitées entre les participants ( tant que leur valeur nette de transfert 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 par signature de l'autre partie. Une fois que l'autre partie a confirmé par signature, 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 disputes ou la fermeture du canal dépendent de la confirmation de la chaîne principale. Lorsqu'il est nécessaire de fermer le canal, n'importe quel participant peut soumettre une demande de transaction sur la chaîne principale, si la demande de retrait obtient l'approbation par signature unanime, l'exécution est immédiate sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants en fonction du solde 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 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 réduire les coûts 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.
• 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 » proposant une solution d'extension pour le réseau Lightning de Bitcoin, Payment Channel), qui est uniquement utilisée pour traiter les paiements de transfert sur le réseau Bitcoin.
• Novembre 2017, la première spécification de conception sur les State Channels basée sur le cadre Payment Channel, Sprites, a été proposée.
• 2018/06, Counterfactual a proposé un design très détaillé des Generalized State Channels, c'est le premier design entièrement lié aux State Channels.
• 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 canal 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é de rester en ligne en permanence pour tous les participants.
• 2020/03, Hydra a proposé des Fast Isomorphic Channels.

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.

La figure 2 montre le flux de travail général suivi par la plupart des protocoles de canaux d'état : dans un cas 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 depuis leurs EOA personnels vers 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é à l'utilisateur ; après confirmation par signature des deux parties, 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 off-chain via ce canal ) ligne bleue (, les participants communiquent entre eux par des messages signés cryptographiquement ) plutôt qu'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 veut fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre l'état final de son compte ) à l'accord 3(. Si Bob signe et approuve, l'accord libérera alors 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, l'accord libérera alors les fonds bloqués et les renverra à l'utilisateur correspondant après 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-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 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 période donnée en soumettant le prochain état au contrat ; si Bob répond, les deux 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 d'analyse approfondie : 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 :

• Forte instantanéité des transactions, adapté aux paiements fréquents et de faible montant
• Frais de transaction bas
• Forte confidentialité, les transactions off-chain ne seront pas rendues publiques
• Scalabilité élevée, théoriquement TPS infini

Inconvénients :

• Nécessite de verrouiller des fonds
• Une confirmation on-chain est nécessaire lorsque le canal est fermé.
• Les participants doivent rester en ligne
• Pas adapté aux transactions de gros montants ou peu fréquentes
• Risque de vol de fonds

(# 3.1.5 Application

Réseau Lightning Bitcoin

Aperçu :

Le réseau Lightning est un canal de paiements à faible montant pour le réseau Bitcoin, dont l'évolution technologique globale a été la suivante : création d'un canal de paiement unidirectionnel avec une signature multiple 2/2, ajout de RSMC)Revocable Sequence Maturity Contract### permettant de construire un canal de paiement bidirectionnel, puis ajout de.