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 de la blockchain. Depuis des années, les gens explorent comment résoudre ce dilemme, en améliorant le débit et la vitesse des transactions de la blockchain tout en garantissant la décentralisation et la sécurité, c'est-à-dire en résolvant le problème de l'évolutivité, qui est l'un des sujets chauds du processus de développement actuel de la blockchain.

La décentralisation, la sécurité et l'évolutivité de la blockchain sont définies comme suit :

• Décentralisé : N'importe qui 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 que le réseau n'est pas contrôlé par des 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 élevée, la chaîne peut résister à un plus grand pourcentage d'attaques des participants.

• Scalabilité : la capacité de la blockchain à traiter un grand nombre de transactions.

La première grande fourche dure du réseau Bitcoin est née d'un problème d'extensibilité. Avec l'augmentation du nombre d'utilisateurs et du volume des transactions, 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 a eu des divergences sur la question de l'extensibilité, une partie soutenant l'augmentation de la taille des blocs, tandis que l'autre estime qu'il faut optimiser la structure de la chaîne principale en utilisant le système SegWit. Le 1er août 2017, le système client développé par Bitcoin ABC pour des blocs de 8 Mo a commencé à fonctionner, entraînant la première grande fourche dure de Bitcoin, et ainsi a vu naître la nouvelle cryptomonnaie BCH.

Le réseau Ethereum a également choisi de sacrifier une partie de sa capacité d'extension pour garantir la sécurité et la décentralisation du réseau. Bien qu'il n'y ait pas de limite de taille de bloc comme pour Bitcoin, la quantité de transactions est limitée en restreignant les frais de carburant qu'un seul bloc peut contenir, dans le but d'atteindre un consensus sans confiance et de garantir une large distribution des nœuds.

Depuis les CryptoKitties de 2017, jusqu'à l'été DeFi, puis à l'émergence ultérieure des applications on-chain telles que GameFi et NFT, la demande du marché en matière de débit ne cesse d'augmenter. Mais même l'Ethereum, qui est Turing-complet, ne peut traiter que 15 à 45 transactions par seconde, ce qui entraîne une augmentation des coûts de transaction et un allongement des délais de règlement, rendant la plupart des Dapps incapables de supporter les coûts d'exploitation, et rendant l'ensemble du réseau lent et cher pour les utilisateurs. Le problème de l'évolutivité de la blockchain doit être résolu de toute urgence. La solution d'évolutivité idéale est : augmenter la vitesse et le débit des transactions du réseau blockchain autant que possible sans sacrifier la décentralisation et la sécurité.

2. Catégories des solutions d'extension

Selon le critère "si une couche de la chaîne principale est modifiée", les solutions d'extension peuvent être classées en deux grandes catégories : l'extension on-chain et l'extension off-chain.

2.1 Extensibilité on-chain

Concept clé : une solution pour augmenter la capacité en modifiant un protocole principal de la chaîne, la principale solution actuelle étant le sharding.

Il existe plusieurs solutions pour l'extension on-chain, en voici deux brièvement énumérées :

• La première solution consiste à élargir l'espace de bloc, en augmentant le nombre de transactions emballées dans chaque bloc, mais cela augmentera les exigences pour les équipements de nœuds hautes performances, réduisant ainsi le degré de "décentralisation".

• La solution deux est le sharding, qui divise le livre de la blockchain en plusieurs parties, chaque nœud étant responsable de la comptabilité de différentes parties, permettant un calcul parallèle pour traiter plusieurs transactions simultanément. Cela peut réduire la pression de calcul sur les nœuds et le seuil d'entrée, augmenter la vitesse de traitement des transactions et le degré de décentralisation, mais cela réduira la "sécurité" de l'ensemble du réseau.

Modifier le code du protocole de la couche principale peut avoir des effets négatifs imprévisibles, car la moindre faille de sécurité dans la couche sous-jacente menace gravement la sécurité de l'ensemble du réseau. Le réseau pourrait être contraint de se fork ou d'interrompre les mises à niveau de réparation. Par exemple, l'incident de faille d'inflation de Zcash en 2018 : le code de Zcash est basé sur une modification du code de Bitcoin version 0.11.2, en 2018, un ingénieur a découvert une faille critique dans son code sous-jacent, permettant l'émission illimitée de tokens, et l'équipe a ensuite passé 8 mois à réparer secrètement la faille, cet incident n'ayant été rendu public qu'après la correction.

2.2 off-chain extensibilité

Concept clé : solution d'extension qui ne modifie pas le protocole de la couche principale existante.

Les solutions d'extensibilité off-chain peuvent être subdivisées en Layer2 et autres solutions :

• Layer2: Construire de nouvelles couches au-dessus de la chaîne principale, traiter la plupart des transactions et des calculs, n'interagir avec la chaîne principale que lorsque cela est nécessaire. Comprend les canaux d'état, les chaînes latérales, Plasma, Rollups, etc.

• Autres solutions : ne pas construire de nouvelles couches, mais plutôt réaliser l'extensibilité par d'autres moyens techniques. Comme Validium, Volition, etc.

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 de conflits du canal, en effectuant les interactions entre utilisateurs hors chaîne, afin de réduire le temps et le coût des transactions, et de permettre un nombre illimité de transactions.

Les canaux d'état sont des protocoles P2P simples, adaptés aux "applications basées sur des tours", comme le 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, valide les mises à jour d'état et arbitre les disputes entre les 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 après confirmation par les deux parties, le canal est officiellement ouvert. Le canal permet aux participants d'effectuer un nombre illimité de transactions off-chain gratuites ( tant que leur valeur nette des 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 de 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 terminée. Normalement, les mises à jour d'état convenues par les deux parties ne seront pas téléchargées sur la chaîne principale ; seules les disputes ou la fermeture du canal nécessiteront une 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, et si la demande de retrait 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 restants verrouillés en fonction du solde de chaque participant dans l'état final du canal ; si d'autres participants n'ont pas donné leur approbation par signature, tous doivent attendre la fin de la "période de contestation" avant de recevoir les fonds restants.

En résumé, les solutions de canaux d'état peuvent considérablement réduire la charge de calcul du réseau principal, améliorer la vitesse des transactions et réduire le coût 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.

• En novembre 2015, Jeff Coleman a systématiquement résumé le concept de State Channel et a proposé 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(, qui est uniquement utilisé pour traiter les paiements de 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, appelée Sprites, a été proposée.

• 2018/06, Counterfactual a proposé un design de Generalized State Channels très détaillé, c'est le premier design entièrement lié aux canaux d'état.

• 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 canaux N-Party, 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é d'être constamment en ligne pour tous les participants.

• 2020/03, Hydra a proposé des canaux isomorphes rapides.

)# 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'extension off-chain]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.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-ci, ils utilisent un canal d'état au lieu d'interagir avec un contrat en chaîne.

• Première étape, Alice et Bob interagissent en déposant des fonds de leur EOA personnel dans l'adresse de contrat en chaîne ) avec 1,2(, ces fonds sont verrouillés dans le contrat jusqu'à ce que le canal soit fermé, moment auquel le solde est retourné aux utilisateurs ; une fois que les deux ont signé et confirmé, 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é (, les participants communiquent entre eux par des messages signés de manière cryptée ) plutôt que de communiquer avec le réseau blockchain (. Les deux utilisateurs doivent signer chaque transaction pour prévenir les attaques de double dépense. Grâce à ces messages, ils soumettent 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 pour terminer 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 par une signature, le contrat libérera les fonds bloqués après la fin de la période de contestation et les renverra à l'utilisateur correspondant.

![Rapport d'étude approfondi : analyse complète de l'expansion 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 : initialement, 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 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 en soumettant le prochain état au contrat pendant une période donnée ; 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 retourne 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 :

• Confirmation instantanée de la transaction
• Haute capacité de traitement
• Coûts de transaction bas
• Bonne confidentialité

Inconvénients:

• Besoin de verrouiller les fonds
• Tous les participants doivent être en ligne en temps réel
• Retrait en retard
• Coût d'initialisation du canal élevé
• Réouverture du canal, s'il vous plaît.
• La complexité du réseau de canaux est élevée

3.1.5 Application

Réseau Lightning Bitcoin

Aperçu: Le réseau Lightning est un canal de paiement à faible montant pour le réseau Bitcoin, dont l'évolution technologique globale a traversé : la construction de canaux de paiement unidirectionnels à 2/2 multisignature, l'ajout de RSMC### Revocable Sequence Maturity Contract( permettant de construire des canaux de paiement bidirectionnels, puis l'ajout de HTLC) Hash Time Lock Contract( permettant d'étendre les canaux de paiement à plusieurs participants, aboutissant finalement à la création d'un réseau de paiement, c'est-à-dire le réseau Lightning. Grâce à des canaux de paiement à faible montant off-chain, puis en s'appuyant sur des 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 suivant : "Dépôt) Établir un canal( → Transaction du réseau Lightning) Mettre à jour l'état du canal( → Remboursement/Settle) Clore le 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 publié 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 )TVL( n'était que d'environ 40 millions de dollars, avec environ 100 000 utilisateurs utilisant le réseau Lightning.
• En juin 2021, le Salvador a annoncé l'adoption du Bitcoin comme monnaie légale,