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, 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 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é : Tout le monde peut devenir un nœud et participer à la production et à la vérification du système blockchain. Plus le nombre de nœuds est élevé, plus le degré de décentralisation est important, 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 d'un système blockchain est élevé, plus la sécurité est grande, alors la chaîne peut résister à une plus grande proportion d'attaques de participants.
• Scalabilité : capacité de la blockchain à traiter un grand nombre de transactions.

La première grande bifurcation dure du réseau Bitcoin est due à un problème de scalabilité. Avec l'augmentation du nombre d'utilisateurs et du volume de transactions de Bitcoin, 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 la scalabilité. D'un côté, il y a le camp en faveur de l'augmentation de la taille des blocs, représenté par Bitcoin ABC, et de l'autre, le camp des petits blocs, représenté par Bitcoin Core, qui estime qu'il faut utiliser la solution Segwit pour optimiser la structure de la chaîne principale. Le 1er août 2017, le système client développé par Bitcoin ABC, capable de gérer 8 Mo, a commencé à fonctionner, entraînant la première grande bifurcation dure 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 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 comme le fait le réseau Bitcoin en restreignant la taille des blocs, il a en quelque sorte évolué vers un plafonnement des frais de gas pouvant être contenus dans un seul bloc, mais l'objectif est le même : réaliser un Consensus sans confiance et assurer une large distribution des nœuds (. Que ce soit en annulant ou en augmentant la limite, de nombreux petits nœuds avec une bande passante, un espace de stockage et une capacité de calcul insuffisants seront éliminés ).

Depuis le CryptoKitties de 2017, l'été DeFi, jusqu'à l'émergence ultérieure des applications on-chain telles que GameFi et NFT, la demande du marché pour le débit augmente sans cesse. 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 incapables de supporter les coûts d'exploitation. L'ensemble du réseau devient également lent et coûteux pour les utilisateurs, ce qui rend urgent de résoudre le problème de l'évolutivité de la blockchain. La solution d'évolutivité idéale est de : sans sacrifier la décentralisation et la sécurité, 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é.

2. Catégories des 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 nous basant sur le critère "s'il y a un changement de couche sur la chaîne principale".

2.1 Scalabilité on-chain

Concept clé : une solution visant à atteindre un effet d'évolutivité en modifiant un niveau de protocole de la chaîne principale, la principale solution actuelle étant le sharding.

Il existe plusieurs solutions pour l'extension de la chaîne, 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 emballées dans chaque bloc, mais cela augmentera les exigences pour les équipements de nœuds haute performance, augmentera le seuil d'entrée des nœuds et réduira 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 à l'enregistrement de toutes les transactions, 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 permet de 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 du réseau est dispersée, ce qui peut diminuer la "sécurité" de l'ensemble du réseau.

Changer le code du protocole principal d'une couche peut avoir des conséquences négatives imprévisibles, car la moindre faille de sécurité au niveau inférieur peut gravement menacer la sécurité de l'ensemble du réseau. Le réseau peut être contraint de procéder à un fork ou à une mise à jour de réparation interrompue. Par exemple, l'incident de la faille 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 faille critique dans le code sous-jacent, à savoir que les tokens pouvaient être émis en quantité illimitée. L'équipe a alors passé 8 mois à corriger cette faille en secret, et l'incident n'a été rendu public qu'après la correction.

2.2 off-chain Scalabilité

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 la chaîne principale que lors de l'ouverture, de la fermeture ou de la résolution des différends du canal, et que les interactions entre utilisateurs se déroulent 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.

Les canaux d'état sont 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 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 différends entre les participants ( selon les preuves de fraude ) avec signatures et horodatages. Après le déploiement du contrat sur le réseau blockchain, les participants déposent un fonds et le verrouillent, après confirmation par signature des deux parties, le canal est officiellement ouvert. Le canal permet des transactions gratuites hors chaîne entre les participants sans limite 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, 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 terminé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 celles en cas de différend ou de fermeture du canal dépendent de la confirmation de la chaîne principale. Lorsque le canal doit être fermé, l'un des participants peut soumettre une demande de transaction sur la chaîne principale, si la demande de sortie obtient l'approbation 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 selon le solde final de chaque participant dans le canal ; si d'autres participants n'approuvent pas par signature, tout le monde devra attendre la fin de la "période de contestation" pour recevoir les fonds restants.

En résumé, le schéma 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 brouillon du livre blanc sur le réseau Lightning.
• 2015/11, Jeff Coleman a systématiquement résumé pour la première fois 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'évolutivité pour le réseau Lightning de Bitcoin, le 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 de State Channel basée sur le cadre Payment Channel, Sprites, a été proposée.
• 2018/06, Counterfactual a proposé un design très détaillé de Generalized State Channels, c'est le premier design entièrement lié aux State Channels.
• 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 canaux d'état a été étendu aux N-Party Channels, Nitro est le premier protocole basé 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. Le inconvénient est qu'il entraîne les problèmes de temps et de coût 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 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 à l'adresse de contrat en chaîne (, 1,2), ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment auquel le solde est retourné à l'utilisateur ; après confirmation par signature des deux parties, le canal d'état entre eux 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 doubles dépenses malveillantes. À 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 les fonds verrouillés selon l'état final et les renverra à l'utilisateur correspondant ( accord 4,5). Si Bob ne répond pas à la signature, l'accord libérera les fonds verrouillés et les renverra à l'utilisateur correspondant à la fin de la période de contestation.

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 initier 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 dans un certain délai en soumettant le nouvel état au contrat ; si Bob répond, les deux peuvent continuer à échanger 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).

3.1.4 Avantages et inconvénients

Avantages:

• Confirmation de transaction instantanée
• Haute capacité de traitement
• Faibles frais
• Haute confidentialité

Inconvénients :

• Il est nécessaire de verrouiller les fonds
• Les utilisateurs doivent se connecter fréquemment
• Augmentation de la complexité

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é : 2/2 multi-signatures construisant un canal de paiement unidirectionnel, ajoutant RSMC.