Analyse approfondie de l'extension off-chain

Auteur : Ellaine Xu, Hettie Jiang, June Wang, Walon Lin, Yiliu Lin

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 objectifs, et satisfaire ces trois exigences est connu sous le nom de 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 de discussion les plus chauds dans le processus de 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 niveau de décentralisation est élevé, garantissant ainsi que le réseau n'est pas contrôlé par un petit groupe 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 grande, alors la chaîne peut résister à un plus grand pourcentage d'attaques de la part 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 de scalabilité. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions de Bitcoin, le réseau Bitcoin, avec une limite de 1 Mo par bloc, a commencé à faire face à des problèmes de congestion ; depuis 2015, la communauté Bitcoin a des divergences concernant la scalabilité. D'un côté, il y a le camp pro-scalabilité représenté par Bitcoin ABC, qui soutient l'élargissement des blocs, et de l'autre, le camp des petits blocs représenté par Bitcoin Core, qui estime qu'il faut utiliser la solution Segwit (Witness Séparé) pour optimiser la structure de la chaîne principale. Le 1er août 2017, le système client de Bitcoin ABC, développé jusqu'à 8 Mo, a commencé à fonctionner, entraînant la première grande hard fork de l'histoire de Bitcoin, et donnant naissance à la nouvelle cryptomonnaie BCH.

De même, le réseau Ethereum a également choisi de sacrifier une partie de l'évolutivité afin de garantir la sécurité et la décentralisation du réseau ; bien que le réseau Ethereum n'ait pas limité 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 contenus dans un seul bloc, mais l'objectif est toujours d'atteindre un consensus sans confiance et de garantir une large distribution des nœuds. Que ce soit pour annuler ou augmenter le plafond, cela éliminera de nombreux petits nœuds qui manquent de bande passante, de stockage et de capacité de calcul.

Depuis CryptoKitties en 2017, l'été DeFi, puis l'émergence des applications on-chain telles que GameFi et NFT, la demande du marché pour le débit n'a cessé 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, des temps de règlement prolongés, 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 : sans sacrifier la décentralisation et la sécurité, il faut également augmenter autant que possible la vitesse des transactions du réseau blockchain( un temps de finalité) plus court et un débit de transaction( un TPS) plus élevé.

2. Catégories de 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 "s'il y a un changement de couche de la chaîne principale".

2.1 Extensibilité on-chain

Concepts clés : une solution qui permet d'augmenter la capacité en modifiant un niveau de protocole de la chaîne principale, la principale solution actuelle est le sharding.

Il existe plusieurs solutions pour l'extension on-chain, cet article ne les développera pas, ci-dessous, deux solutions sont brièvement énumérées :

• La solution un est d'élargir l'espace de bloc, c'est-à-dire d'augmenter le nombre de transactions empaquetées dans chaque bloc, mais cela augmentera les exigences en matière d'équipement des 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 consiste à diviser le livre de comptes de la blockchain en plusieurs parties. Ce n'est plus chaque nœud qui participe à tous les enregistrements, mais différents shards, c'est-à-dire différents nœuds, qui sont responsables de différents enregistrements. Le calcul parallèle peut traiter plusieurs transactions simultanément ; cela permet de réduire la pression de calcul sur les nœuds et le seuil d'entrée, d'améliorer la vitesse de traitement des transactions et le degré de décentralisation ; mais cela signifie que la puissance de calcul de l'ensemble du réseau est dispersée, ce qui peut réduire la "sécurité" du réseau.

Modifier le code d'un protocole de réseau principal peut avoir des conséquences négatives imprévisibles, car la moindre faille de sécurité dans les couches sous-jacentes peut gravement menacer la sécurité de l'ensemble du réseau, qui pourrait être contraint de procéder à une fourche ou à une interruption pour une mise à jour de réparation. Par exemple, l'incident de 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 indéfiniment, et l'équipe a ensuite mis 8 mois à corriger secrètement le problème, et ce n'est qu'après la correction de la faille qu'elle a rendu cet incident public.

2.2 off-chain scaling

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

Le canal d'état stipule 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 du canal, et que les interactions entre utilisateurs se font hors chaîne, afin de réduire le temps et le coût des transactions pour les utilisateurs, tout en permettant un nombre illimité de transactions.

Le canal d'état est un protocole P2P simple, adapté 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, ce contrat contrôle les actifs déposés dans le canal, vérifie les mises à jour d'état et arbitre les différends entre les participants ) en fonction 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é et confirmé, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer des transactions off-chain gratuites sans limite de nombre ( 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 la signature de l'autre partie. Une fois que l'autre partie a confirmé par sa 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 blockchain principale, elles ne dépendent de la confirmation de la blockchain principale qu'en cas de différend ou de clôture du canal. Lorsqu'il est nécessaire de fermer le canal, l'un des participants peut faire une demande de transaction sur la blockchain principale, et si la demande de sortie reçoit l'approbation de signature unanime de tous, elle est immédiatement exécutée sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds restants verrouillés en fonction des soldes de chaque participant à l'état final du canal ; si les autres participants n'ont pas approuvé par signature, tous doivent attendre la fin de la "période de contestation" pour recevoir les fonds restants.

En résumé, les solutions de canaux d'état peuvent considérablement réduire la charge de calcul sur la chaîne principale, améliorer la vitesse des transactions et réduire les coûts de transaction.

3.1.2 Chronologie

• 2015/02, Joseph Poon et Thaddeus Dryja ont publié un brouillon du 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(, cette solution n'est utilisée que pour traiter les paiements de transfert sur le réseau Bitcoin.
• En novembre 2017, la première spécification de conception concernant les State Channels basée sur le cadre des Payment Channels, 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 a été é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 continuellement en ligne.
• 2020/03, Hydra a proposé des Fast Isomorphic Channels.

3.1.3 Principe technique

Flux de travail des canaux d'état:

1. Alice et Bob déposent des fonds depuis leur EOA personnel vers l'adresse du contrat on-chain, 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 par signature, le canal d'état entre les deux parties est officiellement ouvert.

2. Alice et Bob peuvent théoriquement effectuer un nombre illimité de transactions off-chain via ce canal, les participants communiquant entre eux par des messages signés cryptés ) plutôt qu'avec le réseau blockchain (. Les deux utilisateurs doivent signer chaque transaction pour éviter les attaques de double dépense. Grâce à ces messages, ils proposent des mises à jour de l'état de leurs comptes et acceptent les mises à jour d'état proposées par l'autre.

3. Si Alice souhaite fermer le canal et mettre fin à la transaction avec Bob, Alice doit soumettre l'état final de son compte au contrat. Si Bob signe pour approuver, le contrat libérera les fonds bloqués et les renverra à l'utilisateur correspondant en fonction de l'état final. Si Bob ne répond pas à la signature, le contrat libérera les fonds bloqués et les renverra à l'utilisateur correspondant après la fin de la période de contestation.

Flux de travail des canaux d'état en cas de pessimisme : Au départ, les deux participants déposent des fonds, puis commencent à échanger des mises à jour d'état. Supposons qu'à un moment donné, Bob ne réponde pas à la signature de mise à jour d'état envoyée par Alice lors de son tour. À ce moment-là, Alice peut initier un défi en soumettant son dernier état valide au contrat, cet état valide contenant également la signature précédente de Bob, prouvant ainsi que la dernière transaction a été approuvée par Bob et que l'état final a été confirmé par Bob. Ensuite, le contrat permet à Bob de répondre dans un certain délai 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 ce délai, le contrat ferme automatiquement le canal d'état et renvoie les fonds à Alice.

![Rapport d'étude approfondie : 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:

• Confirmation instantanée, la transaction peut être réalisée immédiatement.
• Haut débit, théoriquement des transactions illimitées
• Frais de transaction bas, seuls les frais de chaîne sont à payer lors de l'ouverture du canal.
• Bonne confidentialité, les transactions off-chain ne seront pas rendues publiques sur la chaîne principale.

Inconvénients :

• Faible taux d'utilisation des fonds, nécessite de verrouiller les fonds
• Pas convivial pour les utilisateurs, nécessite une surveillance continue du canal
• La création de canaux est relativement complexe
• Difficile de concevoir des canaux d'état généraux
• Manque de liquidité, le canal ne peut pas transférer des fonds de manière flexible

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 technique globale a traversé : un canal de paiement unidirectionnel construit avec une signature multiple 2/2, puis la possibilité de construire un canal de paiement bidirectionnel après l'ajout du RSMC)Revocable Sequence Maturity Contract(, et enfin l'ajout de HTLC)Hash Time Lock Contract( permettant d'étendre les canaux de paiement à des paiements multi-utilisateurs, créant finalement un réseau de paiement, à savoir le réseau Lightning. Grâce aux canaux de paiement à faible montant off-chain, et en utilisant des intermédiaires pour former un réseau de transactions, il est possible de résoudre le problème d'évolutivité du réseau Bitcoin. L'utilisation globale du réseau Lightning suit le processus suivant : "Dépôt) établissement du canal( → Transactions sur le réseau Lightning) mise à jour de l'état du canal( → Remboursement/Règlement) fermeture du canal(" ; théoriquement, le réseau Lightning peut traiter un million de transactions par seconde.

Chronologie :

• En février 2015, Joseph Poon et Thaddeus Dryja ont publié un brouillon du livre blanc du réseau Lightning;
• La version officielle du livre blanc a été publiée en janvier 2016 et a établi