Analyse approfondie de l'extension off-chain

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 aspects, satisfaire à ces trois exigences est ce qu'on appelle 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 de la discussion 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écentralisé : Toute personne peut devenir un nœud et participer à 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 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 élevée, alors la chaîne peut résister à une proportion plus élevée de participants qui l'attaquent.
• 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 des problèmes de scalabilité. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions de Bitcoin, le réseau Bitcoin, dont la taille maximale par 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 l'extension, 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, le camp des petits blocs, représenté par Bitcoin Core, qui soutient qu'il faut optimiser la structure de la chaîne principale en utilisant la solution Segwit (Segregated Witness). 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, entraînant la première grande hard fork de l'histoire de Bitcoin, et donnant naissance à une nouvelle cryptomonnaie, BCH.

De même, 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 n'impose pas de limite sur le volume des transactions comme le fait le réseau Bitcoin en limitant la taille des blocs, il a en quelque sorte évolué vers un plafond sur les frais de carburant qu'un seul bloc peut contenir, mais l'objectif reste d'atteindre un consensus sans confiance et d'assurer une large distribution des nœuds ( que ce soit en annulant ou en augmentant les limites, 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, jusqu'à l'émergence des applications on-chain telles que GameFi et NFT, la demande du marché pour la capacité de traitement a considérablement augmenté. 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 rend la plupart des Dapps difficilement viables. 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 serait d'augmenter 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'extensibilité

Nous avons divisé 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 cela modifie un niveau de la chaîne principale".

2.1 Scalabilité on-chain

Concept clé : solution permettant d'atteindre un effet d'extension en modifiant un niveau du protocole de la chaîne principale, la principale solution actuelle est le sharding.

L'extension on-chain a plusieurs solutions, cet article ne va pas s'étendre, 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 de nœuds haute performance, augmentant le seuil d'entrée des nœuds et réduisant le degré de "décentralisation".
• La solution deux est le sharding, qui consiste à diviser 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, permettant ainsi un calcul parallèle qui 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 globale du réseau est dispersée, ce qui peut diminuer la "sécurité" de l'ensemble du réseau.

Modifier le code d'un protocole de réseau principal peut avoir des effets négatifs imprévisibles, car la moindre faille de sécurité au niveau sous-jacent menace gravement 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 d'inflation de Zcash en 2018 : le code de Zcash est basé sur le code modifié de la version 0.11.2 de Bitcoin, et en 2018, un ingénieur a découvert une vulnérabilité critique dans le code sous-jacent, à savoir que les tokens pouvaient être émis de manière illimitée. L'équipe a ensuite passé 8 mois à corriger cette faille en 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'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 n'ont besoin d'interagir avec le réseau principal que lors de l'ouverture, de la fermeture ou de la résolution des litiges du canal, et que les interactions entre utilisateurs se font 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 chaîne principale, ce contrat contrôlant les actifs déposés dans le canal, vérifiant les mises à jour d'état et arbitrant 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 un montant de fonds et le verrouillent, et après confirmation par les signatures des deux parties, le canal est officiellement ouvert. Le canal permet des transactions gratuites hors chaîne entre les participants 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 tour à tour des mises à jour d'état à l'autre, attendant la confirmation par 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. En général, les mises à jour d'état acceptées par les deux parties ne sont pas téléchargées sur la chaîne principale, seules les situations de litige ou de fermeture du canal se basent sur la confirmation de la chaîne principale. Lorsqu'il est nécessaire de fermer le canal, l'un des participants peut soumettre une demande de transaction sur la chaîne principale, si la demande de sortie reçoit l'approbation par signature unanime, elle est exécutée immédiatement sur la chaîne, c'est-à-dire que le contrat intelligent distribue les fonds verrouillés restants selon le solde de chaque participant à l'état final du canal ; si d'autres participants n'approuvent pas par signature, alors 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 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 projet de livre blanc sur le réseau Lightning.
• En novembre 2015, Jeff Coleman a systématiquement résumé le concept de State Channel pour la première fois, 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, le Payment Channel(, cette solution étant uniquement destinée à traiter les paiements par transfert sur le réseau Bitcoin.
• 2017/11, la première spécification de conception concernant 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.
• En 2018/10, l'article Generalised State Channel Networks a proposé les concepts de State Channel Networks et de Virtual Channels.
• 2019/02, le concept de canal 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 de 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 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 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 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 le 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 de leur EOA personnel au contrat sur la chaîne ), 1,2(, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment auquel le solde sera 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 en pointillés (, les participants communiquent entre eux par des messages signés cryptés ) plutôt que de communiquer avec le réseau blockchain (. Les deux utilisateurs doivent signer chaque transaction pour éviter les doubles dépenses malveillantes. Grâce à ces messages, ils proposent des mises à jour de l'état de leurs comptes et acceptent les mises à jour de l'é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 ) à contrat 3(. Si Bob signe pour approuver, le contrat libérera les fonds verrouillés selon l'état final et les renverra à l'utilisateur correspondant ) 4,5(. Si Bob ne répond pas par une signature, le contrat libérera les fonds verrouillés à l'utilisateur correspondant à la fin de la période de contestation.

![Rapport de recherche approfondi : Analyse complète de l'extensibilité 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 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 initier un défi en soumettant son dernier état valide au contrat ) interaction 4(, cet é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 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 retourne les fonds à Alice ) interaction 5(.

![Rapport d'étude 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 peuvent être confirmées immédiatement, sans avoir besoin d'attendre la confirmation de bloc.
• Haute capacité de traitement : n'interagit avec la chaîne principale que lors de l'ouverture et de la fermeture du canal, ce qui augmente considérablement la capacité de traitement.
• Coût faible : les transactions off-chain ne nécessitent pas de paiements de frais de mineur, seules des frais minimes sont nécessaires lors de l'ouverture et de la fermeture du canal.
• Confidentialité : le contenu des transactions off-chain ne sera pas enregistré sur la chaîne, seule l'état final sera soumis au réseau principal.

Inconvénients :

• Complexité : La mise en œuvre et l'utilisation des canaux d'état sont relativement complexes.
• Liquidité verrouillée : nécessite de verrouiller à l'avance un certain montant de fonds
• Exigences en ligne : les participants doivent rester en ligne pour répondre aux derniers statuts.
• Portée limitée : principalement applicable aux scénarios d'interaction fréquente entre les deux parties

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 traversé : 2/2 multisignature construisant un paiement unidirectionnel.