En observant la deuxième couche de Bitcoin du point de vue d’une machine à états, à quoi ressemble l’architecture des applications Web3 à grande échelle ?

Auteur original : Fu Shaoqing, SatoshiLab, Bihelix, All Things Island BTC Studio

Lisez les commentaires :

(1) Cet article est un peu obscur car il implique certains principes sous-jacents du système et l’auteur a une expérience théorique et pratique limitée des systèmes distribués. Les lecteurs généraux peuvent lire directement la conclusion, qui est l’architecture des applications Web3.0 à grande échelle dans la section 3.3.

(2) Pour la classification de la construction de deuxième couche, reportez-vous à l’article « Un article résumant le système de connaissances de base de la construction de deuxième couche (couche 2) de Bitcoin ». Selon la classification de la structure du système dans l’article de référence, la deuxième couche de Bitcoin Layer 2 est divisée en trois types : structure blockchain, structure système distribuée et structure système centralisée.

(3) En observant la construction de la deuxième couche de Bitcoin du point de vue d’une machine à états, vous constaterez que le principe de la machine à états est applicable aux trois structures du système (système blockchain, système distribué, système centralisé), mais la mise en œuvre La méthode est limitée par la structure du système.

(4) Trois angles de vision : grand livre distribué, machine à états, structure bloc + chaîne

Préface Multi-niveaux et multi-angles

Observer les choses à plusieurs niveaux et angles fait partie de la méthodologie d’analyse globale. Ses avantages se reflètent sous plusieurs aspects : exhaustivité, compréhension approfondie, exhaustivité, précision et facilité d’exécution. Les avantages de la méthodologie d’analyse complète lui confèrent une forte valeur d’application dans des problèmes complexes et changeants, et peuvent fournir des résultats d’analyse plus complets, approfondis et précis, fournissant ainsi un soutien solide pour résoudre les problèmes et promouvoir le développement.

(1)Plusieurs niveaux

Les niveaux multiples peuvent généralement être observés aux niveaux macro, méso et micro, ou du point de vue des cycles temporels, les niveaux à court, moyen et long terme peuvent être utilisés pour l’observation. Dans le développement de l’écosystème Bitcoin, nous pouvons acquérir une compréhension plus complète, approfondie et précise de l’écosystème Bitcoin en l’observant à trois niveaux : court terme, moyen terme et long terme.

Voici un résumé du professeur Dashan : « L’écosystème Bitcoin est divisé en trois opportunités : à court terme, à moyen terme et à long terme : L’opportunité à court terme pour l’écosystème Bitcoin est la piste d’inscription représentée par BRC-20 ; l’opportunité à moyen terme est la piste Bitcoin Layer 2 et Nostr Plus. La piste Lightning Network ; l’opportunité à long terme est la piste de solutions hors chaîne représentée par le protocole RGB et BitVM. Cela comprend quatre pistes, la piste Inscription ; la piste Layer 2 ; la piste Nostr plus Lightning Network ; la piste hors chaîne (représentée par RGB et BitVM).

Dans la section 3.4 de cet article, le stade précoce de la construction d’une deuxième couche basée sur la chaîne dans Layer est également classé comme une opportunité à court terme.Les raisons sont présentées dans la section 3.4.

(2) Angles multiples

Dans le même temps, nous observons l’écosystème Bitcoin sous plusieurs angles, qui peuvent apporter des avantages complets, objectifs, approfondis, flexibles et innovants. Ce type d’observation sous plusieurs angles nous aide à mieux connaître et comprendre les choses, et est propice à l’innovation.

De ces multiples perspectives, nous partons de la perspective métier - grand livre distribué (propice à la compréhension de l’entreprise), de la perspective informatique abstraite - machine à états (propice à la compréhension de la mise en œuvre de la blockchain + des systèmes distribués) et de la perspective de mise en œuvre technique - bloc + structure de la chaîne (propice à la compréhension de la partie blockchain de l’écosystème).

1. Trois angles de vision

Dans le document d’Ethereum « Ethereum EVM Illustrated », il est introduit qu’il existe trois angles de vue pour la structure de bloc d’Ethereum (grand livre distribué, machine à états, blockchain). Cette observation s’applique également au Bitcoin, et est plus adaptée à l’observation de la structure écologique du Bitcoin. Dans l’introduction suivante, nous comprenons ces trois perspectives et il y aura des gains différents.

Du point de vue d’une machine à états, il est non seulement facile de comprendre l’état et le traitement de l’état sur la blockchain, mais également de comprendre l’état, les canaux d’état et les transitions d’état dans le système distribué. la structure du système distribué, il sera plus facile de comprendre le routage. Le problème est de comprendre les exigences du graphe acyclique dirigé des transitions d’état. Les machines à états sont basées sur les principes informatiques abstraits sous-jacents de la théorie des graphes. Sur la base de ces principes et de structures de mise en œuvre spécifiques (blockchain, distribuée, centralisée), vous comprendrez les problèmes spécifiques qui doivent être résolus et les idées de solutions.

Deuxièmement, d’un point de vue commercial, nous comprendrons facilement pourquoi la blockchain peut gérer des données de confiance et pourquoi les données de la blockchain peuvent être utilisées comme monnaie numérique, ce qui fait du système blockchain une sorte de grand livre. Vous comprendrez pourquoi le système distribué n’est pas un grand livre et doit coopérer avec le grand livre. Dans le même temps, vous comprendrez comment le système distribué gère les données et les flux sur le grand livre en coopération avec le grand livre.

Du point de vue de la mise en œuvre technique, nous comprendrons qu’un système comme Blockchain est une structure blockchain.Les avantages et les inconvénients de cette structure technique peuvent également être facilement résumés et résumés.

Concernant la structure de l’écosystème Bitcoin, du point de vue des registres et des machines à états, nous pouvons mieux comprendre les avantages et les inconvénients de chaque structure, et comment utiliser trois structures alternatives pour construire la deuxième couche de Bitcoin, même si nous construisons Web3. 0 L’architecture complète de l’application.

J’ai eu un pressentiment en lisant la documentation d’Ethereum “Ethereum EVM illustré”. Observer des choses qui peuvent être comparées à Ethereum sous trois angles différents nous fournit des idées de réflexion et des références d’expérience de traitement pour résoudre Ethereum. Par exemple, lorsque Ethereum est considéré comme un automate basé sur l’état, les théories et les algorithmes des machines à états dans le domaine informatique peuvent être appliqués à Ethereum par le biais d’une transformation. Lorsque l’on considère Ethereum comme une base de données basée sur un grand livre, certaines théories de la base de données peuvent être appliquées à Ethereum – comme l’idée de partitionnement dans la base de données. Ce sentiment s’applique également à l’écosystème Bitcoin et sera mélangé et utilisé dans trois grandes structures de système, ce qui rendra la flexibilité encore plus grande.

1.1. Perspective commerciale : grand livre distribué

Du point de vue d’un registre, une blockchain est un groupe de transactions, tout comme les pages de données écrites sur un registre.

Du point de vue des grands livres, il nous est plus facile de comprendre ses capacités commerciales et ses fonctions monétaires et financières. C’est aussi le rôle d’un grand livre dans l’architecture globale des applications Web3.0.

Du point de vue des grands livres, nous pouvons facilement comprendre la construction du deuxième niveau de la chaîne. Les comptes des différentes entreprises peuvent être enregistrés dans différents grands livres, et ces sous-grands livres peuvent être résumés dans le grand livre général.

Du point de vue du grand livre + distribution, nous pouvons comprendre que si un participant reçoit une monnaie numérique, comment la gérer et comment diviser les comptes, les participants peuvent la négocier et la gérer eux-mêmes, et enfin l’enregistrer dans le grand livre. .

1.2. Perspective informatique abstraite : machine à états

Ici, nous nous concentrons sur les machines à états, car cette perspective peut fournir une bonne compréhension des systèmes blockchain et des systèmes distribués. Et vous pouvez comprendre la différence entre la façon dont les données (ou l’état) sont traitées dans un système blockchain et la façon dont elles sont traitées dans un système distribué.

Du point de vue de l’État, la blockchain est une machine à états basée sur les transactions. Une transaction est une condition de déclenchement qui provoque la transformation d’un état d’origine σt vers l’état suivant σt+ 1 sous l’action de la transaction.

Un ensemble de transactions est regroupé dans une blockchain, qui est un paquet de données, ce qui entraîne la modification du statut associé à cet ensemble de données.

De ce point de vue, la blockchain est donc une chaîne d’état (dans un système distribué, c’est un canal d’état). Du point de vue de l’État, le système blockchain peut être considéré comme un automate basé sur l’État.

Du point de vue de l’État, lorsque nous observons le système blockchain + distribué, il sera plus facile de comprendre les règles de transmission et de changement d’état dans les deux systèmes. Les deux systèmes sont en fait des automates basés sur l’état.

Lorsque la blockchain est considérée comme un automate basé sur l’état, les théories et les algorithmes sur les machines à états dans la théorie des graphes dans le domaine informatique peuvent être appliqués à la blockchain. De même, si la structure technique mise en œuvre n’est pas une structure blockchain, mais une structure distribuée, on peut aussi utiliser la théorie des machines à états. Comme le graphe acyclique fini DAG (pour éviter les fleurs doubles), les canaux d’état et le scellement unique sont toutes des technologies qui doivent être utilisées pour gérer les états dans les systèmes distribués.

1.3. Perspective de mise en œuvre technique : structure bloc + chaîne

Du point de vue de la mise en œuvre technique, des systèmes tels que Bitcoin et Ethereum constituent une blockchain. Les données dispersées sont liées entre elles par le bloc de données et le pointeur de hachage à l’intérieur.

Il s’agit simplement d’une structure de mise en œuvre technique maintenue pour faire fonctionner un système comme la blockchain. Les données et calculs sur la blockchain adoptent une approche globale, et seule cette structure peut compléter la fonction de grand livre. Les détails de mise en œuvre et l’applicabilité de cette structure doivent être pris en compte lors de l’interface avec des systèmes externes.

Nous pouvons facilement comprendre les caractéristiques de cette structure de mise en œuvre de la technologie bloc + chaîne et pouvons également calculer des indicateurs de performance. Par exemple, la taille de bloc du réseau Bitcoin est de 1 M (le maximum théorique est de 4 M après prise en charge du témoin séparé), et le nombre de transactions qu’il prend en charge peut être entièrement calculé.

La formule de calcul est la suivante : (taille du bloc/taille moyenne des transactions)/intervalle de temps moyen du bloc. Dans des circonstances normales, chaque bloc Bitcoin peut accueillir environ 2 000 à 3 000 transactions, soit 3 à 7 TPS.

1.4. Caractéristiques de base de la blockchain et caractéristiques des trois structures de construction de couche 2

Reportez-vous aux trois classifications de la construction de la deuxième couche de Bitcoin : structure de blockchain, structure de système distribué et structure de système centralisé. En comparant certaines caractéristiques de base de la construction des première et deuxième couches de Bitcoin, nous pouvons clairement voir les différences entre elles. Comme le montre le tableau ci-dessous. Plus tard, nous comparerons les exigences d’application dans la section 3.2 pour nous aider à sélectionner une combinaison de construction d’architecture appropriée à partir de ces structures de système de base.

Grâce au tableau ci-dessus, nous pouvons résumer grossièrement les caractéristiques de la structure de la blockchain, de la structure du système distribué et de la structure centralisée.

(1) Structure de la chaîne de blocs

Le plus grand avantage de la structure blockchain est qu’elle résout les problèmes liés à la confiance et peut enregistrer le processus de modification des données (transition d’état), de sorte que les données et les règles de calcul deviennent des données et des calculs fiables. L’une de ces données fiables est les données originales de base (exprimées sous forme de devise) et l’autre est le jeu d’instructions pour le traitement des données (exprimé sous forme de code et de contrats intelligents).

Le plus gros problème de la structure blockchain est la mauvaise performance. Il y a deux raisons à cela : premièrement, la structure blockchain ne peut pas supprimer les scénarios de calcul partiels et toutes les demandes sont traitées de manière complète. Par exemple, calcul partiel et calcul global, données locales et données globales, données temporaires et données permanentes. Deuxièmement, la structure de la blockchain a une limite supérieure de performances évidente. Si l’expansion de la couche 2 est effectuée via une chaîne, le nombre de transactions prises en charge est également très limité. Un calcul simple est le suivant :

La limite supérieure d’un système de blockchain est le nombre maximum de transactions pouvant être traitées par une seule capacité de bloc. La limite supérieure d’une blockchain à plusieurs niveaux est le produit du nombre de transactions dans la capacité de bloc de chaque couche. Par exemple, une couche de Bitcoin a 7 TPS par seconde, et une chaîne de couche 2 a une capacité de traitement de 100 TPS. Les deux structures combinées font alors 700 TPS.

Afin d’étendre les performances des structures contenant une blockchain, une construction multicouche est nécessaire et doit être utilisée conjointement avec des systèmes hétérogènes. Pour les travaux qui doivent être effectués dans le système blockchain, seules les données qui doivent être globalement enregistrées et calculées doivent être enregistrées. D’autres données non globales peuvent être affectées à d’autres couches pour le traitement, de sorte que les données traitées et le code soient uniquement liés. aux parties concernées autant que possible.

D’après le tableau ci-dessus, seule la structure blockchain peut réaliser la fonction de registre sans confiance. Par conséquent, si un système souhaite réaliser la fonction de registre sans confiance, il doit inclure un système blockchain. Cependant, en raison des exigences de performances des applications à grande échelle, le système blockchain doit être combiné avec d’autres systèmes pour répondre aux besoins.

(2) Système distribué

Dans le tableau ci-dessus, nous pouvons voir les avantages évidents des systèmes distribués : la décentralisation, les performances et l’évolutivité sont toutes excellentes, mais il existe des fonctionnalités plus complexes dans la mise en œuvre des fonctions. De plus, les systèmes distribués n’ont pas la capacité de faire confiance au grand livre.

Par conséquent, si nous pouvons utiliser le système distribué dans la construction de deuxième couche basée sur la fonction de grand livre de première couche de Bitcoin, nous pouvons théoriquement atteindre une expansion illimitée des performances tout en conservant les caractéristiques de base de la blockchain. Un cas dans ce domaine est représenté par Bitcoin + Lightning Network. La performance de cette combinaison est de 7 TPS * ∞ de Bitcoin.

La raison pour laquelle Turing est complet dans un système distribué est que le coût d’enregistrement et d’exécution de contrats intelligents dans un système blockchain est très élevé car il s’agit de données et de codes globaux. Par conséquent, les contrats intelligents conviennent également à la théorie en couches, qui limite le stockage du code et l’exécution des contrats intelligents aux participants. C’est également le scénario dans lequel la vérification côté client a lieu dans les systèmes distribués. Seules les données fiables (état, sceau unique) entre les parties concernées sont requises pour participer au calcul, et les calculs complets de Turing ne sont effectués que localement. C’est ce que l’on dit souvent à propos du consensus à l’échelle du réseau et du consensus des participants dans les systèmes distribués. La plus grande difficulté dans la construction de la deuxième couche avec une structure de système distribué est que la mise en œuvre technique est relativement complexe. Les réseaux comme Lightning Network qui résolvent simplement les problèmes de paiement se développent lentement et présentent de nombreuses imperfections. Il est encore plus difficile de mettre en œuvre le calcul complet de Turing sur un système distribué. Le développement lent et les mises à jour lentes des versions de RGB constituent un cas de référence.

Le coût le plus important pour résoudre la complexité est la vulnérabilité aux problèmes de sécurité et le seuil élevé de développement. La mise en œuvre de fonctions de contrat intelligent complètes de Turing sur un système distribué nécessite non seulement un cycle de développement long et difficile pour la plate-forme sous-jacente, mais conduit également souvent à des vulnérabilités dans le code du contrat et à des attaques continues de pirates.

(3) Système centralisé

Dans le tableau ci-dessus, nous pouvons voir que l’avantage du système centralisé est que la mise en œuvre technique est relativement simple, grâce à un contrôle logique interne simple et à des calculs simples. De même, les systèmes centralisés n’ont pas la capacité de faire confiance aux grands livres. Les avantages d’un système centralisé ne sont pas exceptionnels : si vous traitez des données à petite échelle, ou si vous traitez des données temporaires et des calculs temporaires, il sera relativement adapté.

La construction au deuxième étage du système centralisé peut être utilisée comme solution complémentaire ou transitoire aux deux autres méthodes.

(4) Analyse complète

À l’ère de la valeur, à travers le contenu ci-dessus, nous pouvons voir qu’il est difficile d’obtenir l’effet de répondre aux besoins en s’appuyant sur un seul système. C’est également une nécessité pratique pour la deuxième couche de développement écologique du Bitcoin. Mais comment combiner ces trois systèmes nécessite beaucoup d’exploration. Analysons-le d’abord théoriquement. Face à des besoins différents, il y aura différentes structures de combinaison.

Tout d’abord, du point de vue du concept de conception de la superposition de protocoles, le réseau Bitcoin n’exige pas l’exhaustivité de Turing. Il s’agit d’une machine de confiance mondiale qui n’a besoin que de sauvegarder les données et les modifications de données qui nécessitent une confiance mondiale. Sur la base de cette exigence la plus élémentaire, le jeu d’instructions de Bitcoin peut être réduit au minimum. D’autres fonctions sont laissées aux extensions de couche supérieure. En plus de répondre aux exigences fonctionnelles de cette couche, la technologie de connexion entre la première couche de Bitcoin et le réseau de couche supérieure doit également être développée et améliorée. le moins d’espace de données de Bitcoin possible.

Généralement, les petites applications ne doivent être complétées que sur une seule blockchain. Des systèmes légèrement plus grands conviennent pour compléter la construction de deuxième couche de blockchain + blockchain. Mais pour les applications à grande échelle, la solution privilégiée est d’utiliser un système blockchain + système distribué. Du point de vue des performances, la limite supérieure du système distribué est théoriquement illimitée, donc une telle combinaison est le 7 TPS * ∞ de Bitcoin. La mise en œuvre technique sera également limitée par certains facteurs spécifiques. Habituellement, la limite supérieure d’un tel système est limitée par les capacités de routage du système distribué, les capacités de traitement des graphiques acycliques dirigés des changements d’état et d’autres liens de mise en œuvre techniques spécifiques. Plus tard, dans l’architecture d’application typique du Web3.0, vous pourrez également voir le diagramme de combinaison de différents systèmes.

Grâce à la combinaison de plusieurs structures de systèmes, les limites de la théorie de base d’un système unique peuvent être brisées. Par exemple, le système blockchain est limité par les limites du triangle impossible DSS, mais si un système blockchain + système distribué est utilisé, le triangle impossible de décentralisation D, de sécurité S et d’évolutivité S peut être résolu. D’autres combinaisons, blockchain + système centralisé, peuvent également résoudre dans une certaine mesure le problème d’évolutivité. Système distribué + système centralisé peut résoudre les limites du triangle CAP dans les systèmes distribués.

Dans l’histoire du développement technologique, il y a eu également quelques cas d’utilisation combinée. Par exemple, lorsque la base de données centralisée a des capacités limitées, elle adopte une structure maître-esclave, puis se déplace vers des sous-bases de données et des sous-tables, vers des bases de données distribuées, qui sont des exemples d’utilisation de systèmes centralisés et de systèmes distribués.

Cette combinaison incarne également une idée philosophique : **La solution à un problème ne peut pas obtenir la réponse au niveau où le problème se pose, mais elle peut résoudre le problème à un niveau supérieur. **Il n’est pas particulièrement facile de comprendre clairement cette phrase. Je pense à une métaphore particulièrement intéressante dans “Le zen et l’art de l’entretien des motos” : On ne peut pas se relever par les cheveux. Cela nous indique que nous ne pouvons pas compter sur le système lui-même pour résoudre nos propres problèmes, mais que nous devons utiliser des systèmes externes pour les résoudre.

2. Revisitez la conception et le développement de la deuxième couche de Bitcoin du point de vue d’une machine à états

Des États et des machines d’État existent dans les trois bâtiments de deux étages, mais les noms sont légèrement différents, ce qui fait que la plupart des gens ne prêtent pas attention à cet angle d’observation.

Si nous regardons les choses du point de vue des états et des machines à états, les trois structures à deux couches sont toutes des machines à états qui traitent les états, mais les principes sont légèrement différents. Lorsque ces trois systèmes sont utilisés en combinaison, il est nécessaire de s’assurer que le concept d’« état » est cohérent dans les trois systèmes et que la machine à états de chaque système peut gérer les changements d’état, mais ne peut pas détruire la cohérence de l’état.

Du point de vue d’une machine à états, l’architecture applicative de l’écosystème Bitcoin ou Web3.0 utilise la combinaison de ces systèmes pour compléter le traitement des transformations d’état et ainsi compléter le traitement de la logique métier.

En utilisant l’idée des machines à états, nous examinons la construction du réseau à deux couches du Bitcoin, et nous pouvons voir que chaque couche de l’architecture a une division du travail adaptée à ses caractéristiques.

2.1. Connaissances de base des états et des machines à états en théorie des graphes

En théorie des graphes, les connaissances de base sur les états et les machines à états comprennent les éléments suivants :

État : l’état fait référence à un nœud ou à un sommet dans la théorie des graphes. Dans un graphe orienté, l’état peut être représenté par un nœud ; dans un graphe non orienté, l’état peut être représenté par un sommet.

Transition d’état : la transition d’état fait référence au processus d’un état à un autre. Dans un graphe orienté, la transition d’état peut être représentée comme une arête dirigée ; dans un graphe non orienté, la transition d’état peut être représentée comme une arête non orientée.

Machine à états : une machine à états est un modèle informatique abstrait utilisé pour décrire une série d’états et des règles de transition entre les états. La machine à états se compose d’un ensemble d’états, d’un état initial, d’une fonction de transition et d’un état de fin.

Graphique orienté : un graphe orienté est une structure de graphe composée de sommets et d’arêtes dirigées. Les arêtes dirigées pointent d’un sommet à un autre, représentant la relation de transition entre les états.

Graphique non orienté : un graphe non orienté est une structure graphique composée de sommets et d’arêtes non orientées. Les arêtes non orientées relient deux sommets et représentent l’association entre les états.

Tri topologique : le tri topologique fait référence au tri linéaire des sommets d’un graphe acyclique orienté (DAG), de sorte que pour deux sommets u et v quelconques, s’il y a une arête (u, v), alors u apparaît avant v dans le tri.

Graphique acyclique dirigé (DAG) : un graphe acyclique dirigé est un graphe orienté dans lequel il n’y a pas de cycle qui commence à partir d’un sommet et revient au sommet après avoir traversé plusieurs arêtes.

Chemin le plus court : le chemin le plus court fait référence au chemin avec la plus petite somme de poids d’arête parmi les chemins reliant deux sommets du graphique.

Arbre couvrant minimum : L’arbre couvrant minimum fait référence à la recherche d’un arbre contenant tous les sommets d’un graphe connecté de telle sorte que la somme des poids des arêtes de l’arbre soit la plus petite.

Ces connaissances de base sont des concepts fondamentaux de la théorie des graphes et sont utilisées pour décrire et analyser les relations et les règles de transition entre les états. Les connaissances et graphiques pertinents peuvent être appris en profondeur dans des livres professionnels.

Bien que ces connaissances semblent un peu abstraites et ennuyeuses, elles sont faciles à comprendre si nous convertissons ces connaissances en certains concepts de blockchain que nous rencontrons souvent. Par exemple, certains scénarios nécessitent des graphes acycliques dirigés pour éviter le problème de la double dépense ; l’encapsulation unique consiste à transformer l’état de la blockchain en l’état du système distribué ; l’algorithme de routage consiste à trouver le chemin le plus court dans le système distribué. Calcul : l’itinéraire ayant le coût de paiement le plus faible dans le réseau Lightning est le problème du spanning tree minimum ; la vérification du client peut également être considérée comme une forme de machine à états.

2.2. Machine à états et système distribué

Ici, nous utilisons plusieurs réseaux distribués pour introduire :

(1) Dans le réseau Lightning

Dans Lightning Network, les points de connaissances liés aux états et aux machines à états sont :

Le Lightning Network est une solution de deuxième couche pour Bitcoin basée sur la technologie des canaux d’état. Le canal de paiement dans le Lightning Network est un canal d’état bidirectionnel. Les participants peuvent effectuer plusieurs transactions dans le canal et mettre à jour l’état du canal pour obtenir des résultats rapides et faibles. -transactions de frais.Paiement des frais.

Les transactions (c’est-à-dire les États) dans le réseau Lightning sont mises en œuvre via des contrats à durée limitée basés sur le hachage (HTLC), grâce auxquels les participants peuvent verrouiller des fonds (l’état est transféré entre les systèmes Bitcoin et Lightning Network) et effectuer des transactions sécurisées au sein des canaux. (gestion simple de l’état).

Routage dans le réseau Lightning : pour permettre les paiements multicanaux, le réseau Lightning utilise un mécanisme appelé routage, dans lequel les participants peuvent effectuer des paiements en trouvant un chemin fiable.

Nœuds relais dans le réseau Lightning : les nœuds relais sont des nœuds qui peuvent transmettre les demandes de paiement et aider à réaliser des paiements multicanaux.

Paiement bidirectionnel sur le réseau Lightning : le réseau Lightning permet aux participants d’effectuer des paiements bidirectionnels dans le canal de paiement, c’est-à-dire qu’ils peuvent non seulement payer à l’autre partie, mais également accepter le paiement de l’autre partie.

Confidentialité des paiements du réseau Lightning : étant donné que les transactions sur le réseau Lightning sont effectuées au sein du canal, toutes les transactions n’ont pas besoin d’être écrites dans la blockchain, ce qui permet d’améliorer la confidentialité des paiements.

Limites de Lightning Network (principalement limitations de la technologie de mise en œuvre des états et des machines à états) : Lightning Network présente également certaines limitations, telles que la capacité de survie du canal, le temps de blocage des fonds, etc. Ces limitations doivent être prises en compte de manière globale pour concevoir un canal de paiement approprié.

(2) En RVB, les points de connaissance liés à l’état, à la machine à états et au canal d’état sont :

RVB est basé sur les protocoles LNP et BP. Il y a une discussion sur la question de savoir si RVB est la deuxième ou la troisième couche. Si l’opération RVB est effectuée directement sur la base de BP, elle étend directement la fonction complète de Turing du Bitcoin et appartient à la deuxième couche. Cette méthode a une expansion limitée des performances. Si le calcul RVB est basé sur LNP, il appartient à la troisième couche (car LNP est la deuxième couche de Bitcoin). Cette méthode peut augmenter à la fois les performances et la puissance de calcul complète de Turing, mais il existe une certaine complexité dans la mise en œuvre technique. . Habituellement, la méthode de combinaison peut non seulement augmenter la puissance de calcul, mais également augmenter les performances et réduire la complexité de la mise en œuvre.

RVB est basé sur la technologie des canaux d’état de Bitcoin ou du Lightning Network. Le canal d’état en RVB fait référence au canal de communication entre deux ou plusieurs parties construites sur LNP et BP. Plusieurs transactions et mises à jour de statut peuvent être effectuées au sein du canal, réduisant ainsi le nombre de transactions et les frais sur la blockchain.

Les canaux d’État en RVB utilisent des scripts multi-signatures basés sur Bitcoin pour verrouiller les fonds et utilisent des types de transactions spéciaux pour mettre à jour l’état du canal.

Le canal étatique en RVB peut être appliqué à divers scénarios, tels que les canaux de paiement, les échanges décentralisés, l’émission d’actifs, etc., améliorant ainsi l’efficacité des transactions et l’expérience utilisateur.

Le canal d’état dans RGB réalise le paiement et le transfert d’actifs en mettant à jour l’état du canal. Les transactions dans le canal n’ont pas besoin d’être écrites dans la blockchain, seul l’état final sera écrit dans la blockchain.

Le canal étatique de RGB peut également mettre en œuvre des fonctions plus complexes, telles que les échanges atomiques, le routage des paiements, etc., via des contrats intelligents et des scripts multi-signatures.

Les canaux d’état en RVB peuvent être combinés avec d’autres technologies et protocoles, tels que Lightning Network, LNURL, etc., pour offrir des fonctionnalités plus riches et une meilleure expérience utilisateur.

La conception et la mise en œuvre de canaux d’état en RVB doivent prendre en compte des facteurs tels que la sécurité, la confidentialité, l’évolutivité, etc. pour garantir la fiabilité et la disponibilité du système.

(3) Dans Nostr, concepts liés aux états, aux machines à états et aux canaux d’état.

Dans Nostr, parce que les informations sont transmises, les concepts d’État (données fiables, monnaie numérique) et de machine d’état n’ont pas encore été reflétés. Cependant, je pense que si la structure distribuée de Nostr est légèrement modifiée et que le traitement des statuts est augmenté, un système similaire au Lightning Network sera formé. Un tel système peut à la fois transmettre des informations et fournir de la valeur. La possibilité de transformer progressivement ce système distribué basé sur l’information en un système distribué incluant le traitement des valeurs est également décrite dans le diagramme d’architecture d’application du Web3.0 à la section 3.3.

Une brève introduction au Nostr actuel : Il y a deux composants principaux dans Nostr, le client et le relais. Chaque utilisateur exécute un client et communique avec les autres via des relais. Chaque utilisateur est identifié par une clé publique. Chaque message publié par un utilisateur est signé. Chaque client vérifie ces signatures. Les clients obtiennent des données et publient des données vers le relais de leur choix. Les relais ne communiquent pas entre eux, mais directement avec les utilisateurs.

(4) Dans les systèmes distribués, les points de connaissance liés aux machines à états comprennent :

Modèle de machine à états : une machine à états est un modèle mathématique qui décrit les transitions et le comportement d’un système entre différents états. Dans les systèmes distribués, les modèles de machines à états sont souvent utilisés pour décrire le comportement et les changements d’état du système.

Machine à états finis (FSM) : la machine à états finis est le modèle de machine à états le plus basique, qui contient un ensemble fini d’états et un ensemble de règles de transition entre les états. Dans les systèmes distribués, les machines à états finis peuvent décrire divers états du système et les transitions entre les états.

Transition d’état : la transition d’état fait référence au processus par lequel le système passe d’un état à un autre. Dans un système distribué, les transitions d’état peuvent être déclenchées par divers événements ou conditions, tels que la réception d’un message, un délai d’attente, etc.

Comportement de la machine à états : la machine à états peut définir différents comportements dans différents états. Dans un système distribué, le comportement d’une machine à états peut inclure le traitement de messages, l’exécution d’opérations, l’envoi de messages, etc.

Cohérence des états : dans un système distribué, plusieurs nœuds peuvent avoir des états différents. La cohérence des états fait référence au maintien de la coordination et de la cohérence des états des différents nœuds du système.

Machine à états distribuée (DSM) : la machine à états distribuée fait référence à une technologie qui applique des modèles de machines à états aux systèmes distribués. Il peut distribuer l’état et les transitions d’état du système sur plusieurs nœuds et garantir la cohérence des états entre les nœuds.

Machine à états atomique (ASM) : une machine à états atomique fait référence à une machine à états qui maintient l’atomicité pendant les transitions d’état. Dans les systèmes distribués, les machines à états atomiques peuvent garantir la cohérence et la fiabilité du système pendant les transitions d’état.

Protocole de cohérence : un protocole de cohérence est un protocole utilisé pour garantir la cohérence des états dans un système distribué. Les protocoles de consensus courants incluent Paxos, Raft, ZAB, etc.

Tolérance aux pannes : les machines à états distribuées doivent être tolérantes aux pannes, c’est-à-dire que le système peut toujours maintenir l’état et le comportement corrects en cas de défaillance d’un nœud ou de perte de message.

Évolutivité : les machines à états distribuées doivent être évolutives, c’est-à-dire qu’elles doivent être capables de maintenir des transitions d’état efficaces et une cohérence à mesure que l’échelle du système augmente.

2.3. Machine à états et système blockchain

Selon le document d’Ethereum « Ethereum EVM illustré », chaque bloc est un ensemble d’états de déclenchement et l’ensemble du système Ethereum est un processeur d’état. Dans la version 1.2, nous avons introduit le contenu de la machine à états dans le système blockchain. Il existe également de nombreuses descriptions de machines à états dans le livre blanc Ethereum.

Bien que la machine à états ait de fortes capacités de traitement, sa limite supérieure constitue le plafond de la structure de la blockchain.

Pour l’application combinée de l’interconnexion blockchain basée sur le modèle UTXO et le modèle de compte (comme EVM), les méthodes de mise en œuvre de l’état et de la machine à états sont très différentes. Les blockchains basées sur le modèle UTXO sont plus faciles à combiner avec des systèmes distribués car les états des deux systèmes sont basés sur UTXO et il n’y a pas de conversion ou seulement une simple conversion, ce qui est plus facile à mettre en œuvre. La chaîne basée sur le modèle de compte nécessite une encapsulation et une conversion supplémentaires entre son état et l’état du système distribué externe, ce qui est complexe à mettre en œuvre.C’est également en partie la raison pour laquelle le développement du réseau Raiden sur Ethereum ne se déroule pas sans heurts.

2.4. Machine d’état et système centralisé

Des exemples d’utilisation de blockchain + systèmes centralisés incluent les ordinaux et l’échange centralisé CEX.

De tels systèmes sont relativement simples et certains ne comportent aucun transfert d’État, comme les Ordinaux, qui utilisent uniquement des index centralisés pour effectuer un travail statistique.

Comme un échange centralisé, le transfert d’état repose entièrement sur les règles fixées par le système centralisé. La machine d’état à l’intérieur est également un processeur d’état composé de programmes système centralisés, et il n’y a pas de concepts compliqués.

Dans les futures applications Web3.0, il devrait y avoir davantage de cas d’utilisation de systèmes blockchain + centralisés.

3. À quoi doit ressembler la structure d’une application Web3 ?

Grâce au contenu précédent de l’article, nous savons que grâce à la combinaison de trois architectures Bitcoin à deux couches, des conceptions structurelles plus complexes peuvent être réalisées pour obtenir les fonctionnalités requises. Et d’un point de vue métier, si la logique sous-jacente de l’application peut être décomposée en états et machines à états, une combinaison des trois systèmes peut être utilisée pour compléter l’ensemble de la logique métier de la couche supérieure.

Alors, quelles sont ces combinaisons courantes ? Quels facteurs détermineront la structure du portefeuille ? Nous spéculons sur la structure des applications à grande échelle qui répondent au Web3.0 sur la base de classifications d’applications et d’exigences d’application communes.

3.1.Classification des applications courantes

Nous utilisons les statistiques d’application du 48e « Rapport statistique sur le développement de l’Internet en Chine » comme référence, ci-après dénommé le rapport statistique. Étant donné que le Web2.0 a mûri et n’affecte pas l’analyse des résultats de la classification des applications et de l’échelle des utilisateurs, les données de référence des applications que nous utilisons sont d’anciennes données de 2020 et 2021. Une chose à noter est qu’il ne s’agit que des statistiques de l’Internet chinois : au stade Web3.0, de nombreuses applications sont mondiales et les utilisateurs ont des exigences d’échelle et de performances plus élevées.

Dans le rapport statistique, nous pouvons voir que les applications du Web2.0 sont très riches et disposent d’un énorme groupe d’utilisateurs. Ces applications incluent : la messagerie instantanée, la vidéo en ligne, la vidéo courte, le paiement en ligne, les achats en ligne, le moteur de recherche, les actualités en ligne, la musique en ligne, la diffusion en direct en ligne, les jeux en ligne, les plats à emporter en ligne, la littérature en ligne, les services de covoiturage en ligne, le bureau en ligne et réservation de voyages en ligne, éducation en ligne, soins médicaux en ligne,… couvrant presque tous les domaines de la vie des gens. Outre ces contenus Internet grand public, il existe également de nombreuses applications dans l’Internet industriel.

Si toutes les applications Web2.0 sont migrées vers Web3.0, la plupart d’entre elles auront des exigences de performances très élevées. En prenant le paiement Visa comme exemple, l’exigence de performance maximale est : 65 000 TPS. De tels indicateurs de performance ne peuvent être pris en charge que par des systèmes distribués. Par exemple, la performance actuelle du Lightning Network est de 40 millions de transactions par seconde, et la performance du Lightning Network est de 40 millions de transactions par seconde. Le réseau n’est théoriquement pas suffisant.

De plus, prenons comme exemple les jeux courants : actuellement, le jeu en chaîne complète avec le TPS le plus élevé sur la blockchain peut atteindre un pic d’environ quelques milliers de TPS, ce qui représente un énorme écart par rapport aux jeux Web2 3A traditionnels avec des centaines de milliers. du TPS. Si vous souhaitez migrer tous les jeux vers Web3.0, les performances d’infrastructure requises constitueront un défi de taille.

De plus, les jeux ne sont qu’une application parmi les catégories d’applications courantes, et d’autres applications ont plus de performances et d’exigences spécifiques.

3.2. Exigences pour les applications Web3.0

Pour comprendre les besoins de l’application, il sera plus direct d’utiliser la structure des revenus comme indicateur. Nous nous référons au rapport « Token Terminal, organisé par FutureMoney Research 2022 Q2 ». Bien que ce rapport soit antérieur, le paiement et d’autres applications en sont à la phase initiale et n’affecteront pas les principaux résultats de l’analyse. L’auteur était donc paresseux ici et a utilisé les données lorsque j’écrivais des livres Web3.0. S’il y a des données du quatrième trimestre de 2023, elles seront plus précises.

(1) Besoin d’analyse via la déclaration des revenus

La classification des revenus dans le rapport représente mieux la composition actuelle des produits de base du Web3.0. comme le montre la photo.

1. Les revenus de la couche 1 (la chaîne principale de base de la blockchain) sont de 48 %, soit près de la moitié des revenus totaux. Son modèle commercial peut être compris comme « vendre de l’espace de blocs » ;

2. Les revenus de la plateforme de trading NFT représentent 22 %, et son modèle économique peut être compris comme des redevances ou des activités de marketing ;

3. Les revenus de DeX dans DeFi représentent 15 % et son modèle commercial repose sur les frais de transaction et les revenus de création de marché de liquidité ;

4. Les revenus de mise en jeu dans DeFi représentent 8 % et son modèle économique repose sur la répartition des commissions ou des intérêts provenant de la gestion d’actifs ;

5. Gamefi représente 5 %, et son modèle économique est constitué de redevances, de frais de transfert, de ventes de NFT, etc. ;

6. Les revenus des prêts dans DeFi représentent environ 1 % et son modèle économique est la répartition des intérêts ;

7. Les revenus de Tooling représentent environ 1 % et son modèle commercial repose sur les frais de service, qui incluront également les frais de monétisation du trafic à l’avenir ;

Les autres industries liées au Web3.0 ne sont pas des applications Web3.0 et ne sont pas considérées comme des industries principales du Web3.0 et ne seront pas incluses. Par exemple : médias Web3.0, organismes de recherche, organismes de formation, etc.

D’après la structure des revenus, nous pouvons voir que les besoins actuels en matière d’applications de l’écosystème BTC peuvent essentiellement être résolus par la blockchain et son système de deuxième couche, sans avoir besoin d’une architecture système complexe. Cependant, Gamefi et SocialFi se développent relativement rapidement et, à l’aide des exemples de jeux de la littérature de référence, nous pouvons constater que les jeux à grande échelle ont déjà des exigences plus élevées et claires en matière de structure du système.

De la structure des revenus, nous pouvons voir les besoins d’application de l’écosystème BTC actuel. Cela vaut la peine de refaire tous les produits d’Ethereum et d’autres écosystèmes. Transformer légèrement la technologie de construction de deuxième couche basée sur la chaîne dans l’écosystème Ethereum et établir une nouvelle deuxième couche sur Bitcoin peut mieux répondre à ces besoins primaires, mais uniquement en termes de degré de décentralisation, de sécurité, de confidentialité et de résistance à la censure. a été fait. Dans « Un article résumant le système de connaissances de base de la construction de deuxième couche (couche 2) de Bitcoin », ces nouvelles constructions de deuxième couche basées sur le type EVM sont toutes des cas de cette situation.

(2) Analyse de cas de jeux d’utilisation d’applications avec des exigences de performances élevées

Dans l’article « L’impossible devient possible : faire du développement de jeux en chaîne complète une réalité sur le réseau Lightning », il existe une demande accrue en termes de fonctionnalités et de performances. La véritable architecture des applications Web3.0 émerge progressivement.

Description du problème dans l’article : Sur la base de la garantie de la sécurité, de la confidentialité et de la décentralisation, les jeux en chaîne complète n’ont jamais trouvé la solution optimale pour l’évolutivité. Par exemple, les moteurs de jeu à chaîne complète les plus populaires, Mud et Dojo, s’engagent à aider les jeux à chaîne complète à atteindre des TPS plus élevés, mais les joueurs ont toujours besoin de plus de 2 secondes de mise en mémoire tampon pour chaque opération. En fait, le jeu complet actuel avec le TPS le plus élevé de la blockchain peut atteindre un pic d’environ quelques milliers de TPS, ce qui représente un énorme écart par rapport aux jeux Web2 3A traditionnels avec des centaines de milliers de TPS. Tout en poursuivant le principe de ne pas perdre les avantages de la blockchain, les jeux en chaîne complète peuvent surmonter l’évolutivité.

Dans la solution discutée plus loin dans la discussion technique, Lightning Network et RGB sont utilisés pour augmenter les performances, et les concepts de chaînes temporaires et de chaînes dédiées sont également proposés.

Chaîne éphémère

Les blockchains éphémères peuvent être définies comme des blockchains qui ne durent pas éternellement et sont détruites une fois que l’objectif de la blockchain est rempli (comme l’enregistrement des transactions) ou une fois que son état est stocké de manière permanente ailleurs. Le statut de terminaison stocké par une chaîne temporaire est simplement des données sur les faits de terminaison associés à la chaîne temporaire, compressant ainsi le tout d’un ordre de grandeur considérable. Les chaînes temporaires sont principalement limitées par la latence des transactions et le débit sur la blockchain.

Chaîne temporaire VS canal d’état

En ce qui concerne les chaînes temporaires, nous nous retrouverons avec un grand nombre d’utilisateurs en raison de l’état de la chaîne publique. L’État qui doit être inséré dans la chaîne publique sera réduit en taille grâce à l’élagage/compression/extraction de différence, puis sauvegardé sur la chaîne publique régulièrement plutôt qu’irrégulièrement. Le réglage du canal d’état RVB peut contourner les contraintes de performances de la chaîne temporaire et réaliser la même fonction que la chaîne temporaire.

Blockchains spécifiques aux applications

Les blockchains spécifiques aux applications sont des blockchains créées pour exécuter une seule application décentralisée (dapp). Plutôt que de s’appuyer sur une blockchain existante, les développeurs créent une nouvelle blockchain à partir de zéro à l’aide d’une machine virtuelle (VM) personnalisée qui exécute des transactions permettant aux utilisateurs d’interagir avec l’application. Les développeurs peuvent également personnaliser différents éléments de la pile réseau blockchain (consensus, réseau et exécution) pour répondre à des exigences de conception spécifiques. L’amélioration de la vitesse d’exécution des contrats intelligents et la résolution des contraintes de ressources informatiques peuvent faciliter la mise en œuvre de la blockchain pour des applications spécifiques. Permettre aux développeurs de personnaliser l’infrastructure pour différents cas d’utilisation facilite le développement. Dans le même temps, cela permet aux développeurs Web3 de créer des modèles de valeur puissants et d’étendre leurs dapps pour répondre aux besoins de croissance exponentielle et inspirer davantage d’innovation.

A travers le cas de ce jeu, couplé à notre analyse précédente de plusieurs architectures, nous pouvons juger grossièrement de l’architecture des futures applications à grande échelle.

3.3. À quoi devrait ressembler l’architecture adaptée aux applications Web3.0 à grande échelle ?

Dans le contenu précédent, nous avons découvert les catégories d’applications courantes du Web 2.0. Toutes ces applications ont été mises à niveau vers le Web 3.0, ce qui est le signe d’une entrée complète dans l’ère du Web 3.0. Quel type d’architecture peut satisfaire les nombreuses applications ci-dessus ?

(1) Différences architecturales simples entre Web2.0 et Web3.0

Voici le contenu de l’article “L’architecture d’une application Web 3.0” écrit par la déesse blockchain Preethi Kasireddy. . La description structurelle des applications Web3.0 ici est une structure très simple qui repose uniquement sur le système blockchain. Cependant, cette structure est trop simple, ne reflète pas la construction de la deuxième couche et n’est pas adaptée aux applications à grande échelle.

En comparant les cas de mise en œuvre technique des produits centralisés traditionnels et ceux des produits Web3.0, il sera plus facile de comprendre les différences de mise en œuvre technique. En combinaison avec la description par Gavin Wood de la vision de la pile technologique du Web3.0, nous pouvons voir que la plus grande différence dans la mise en œuvre technique du Web3.0 se situe en arrière-plan et que la différence dans la couche d’expérience utilisateur est relativement faible.

(2) Architecture système pour les applications à grande échelle à l’ère du Web3.0

À l’ère sans blockchain, les applications étaient construites sur des systèmes centralisés et des systèmes distribués. Par exemple, les applications telles que les centres commerciaux, la messagerie instantanée et les vidéos sont construites sur des systèmes centralisés, et les téléchargements Thunder sont basés sur des systèmes distribués.

Avec le système blockchain, nous sommes entrés dans l’ère du Web 3.0. Les applications de cette période sont une architecture complexe construite sur le système blockchain, le système distribué et le système centralisé. Parmi eux, le système blockchain et son extension de deuxième couche complètent la transmission et le traitement de la valeur, et le système distribué et le système centralisé complètent la transmission et le traitement de l’information.

Comme indiqué ci-dessous,

Le contenu spécifique est décrit comme suit :

(1) Le réseau principal Bitcoin et la construction de deuxième couche sont le centre de toute valeur, et la majeure partie de la valeur est construite sur ce réseau. Dans la construction de la deuxième couche de Bitcoin, la deuxième couche basée sur la chaîne complète l’expansion des performances et le traitement de la valeur, et traite toutes les données du grand livre. Dans la construction de deuxième couche de Bitcoin, la construction de deuxième couche basée sur le système distribué complète l’expansion des performances. Elle traite les données locales pertinentes et utilise le consensus des parties concernées, mais les résultats finaux du calcul doivent être implémentés dans la blockchain. système. Dans la construction de deuxième couche de Bitcoin, la construction de deuxième couche basée sur le système centralisé fournit directement des services pour les applications de couche supérieure.

(2) Le système de type RVB nécessitera également des chaînes temporaires ou des chaînes intermédiaires pour compléter la fonction de règlement du grand livre, comme le montre la ligne bleue sur la figure. Le cas de jeu dans la référence 1 décrit ce scénario. Il n’est pas apparu à grande échelle car la construction de systèmes de type RVB est compliquée et n’a pas encore atteint sa maturité.

(3) Outre l’écosystème Bitcoin, il existe également d’autres écosystèmes de systèmes blockchain pour répondre aux besoins de différents scénarios commerciaux. Comme nous l’avons décrit dans l’article sur l’infrastructure de deuxième couche, il y aura de nombreux projets sur la deuxième couche basés sur la chaîne, et il en va de même pour les chaînes de l’écosystème non Bitcoin. D’autres systèmes de blockchain et secondes couches peuvent également entrer dans le Lightning Network et le RGB, et cela se produira progressivement à mesure que la technologie mûrira.

(4) Dans l’écosystème Web3.0, les systèmes centralisés auront également leur place, mais la proportion ne sera plus aussi importante que dans le Web2.0. Les systèmes centralisés présentent de nombreux avantages.

(5) Dans les applications réelles, le câblage interne de la figure ci-dessus deviendra plus compliqué. Certains n’ont pas besoin d’utiliser la deuxième couche, mais exploitent directement le réseau de première couche, comme lorsque RVB utilise le protocole BP. D’autres blockchains peuvent également utiliser des systèmes distribués, comme le réseau Raiden sur Ethereum. Bien qu’il soit immature, s’il existe des scénarios de demande, il y aura des scénarios d’utilisation en transformant certaines fonctionnalités de base. La figure ci-dessus est une description simplifiée de l’architecture de l’application Web3.0.

3.4. Voies de construction réalisables

À partir de la structure des revenus, nous pouvons voir les besoins actuels en matière d’applications de l’écosystème BTC, et à partir de la classification des applications couramment utilisées, nous pouvons voir les besoins futurs pour entrer pleinement dans le Web3.0. Le chemin sera long. Par conséquent, les projets dont la période de construction est relativement longue doivent être traités par étapes.

Les trois étapes ici sont très similaires aux étapes à court, moyen et long terme mentionnées par le Maître Dashan. Il résume simplement l’étape simple de la construction de la deuxième couche en chaîne dans la première étape de la construction.

(1) La première phase est la première étape de la construction à deux couches basée sur des inscriptions et des chaînes

Les constructions à deux couches basées sur des inscriptions et des chaînes sont relativement simples et ont actuellement de nombreuses applications. Qu’il s’agisse de brc 20, src 20, arc 20, d’inscription et autres applications, ou de ces projets de construction de deuxième couche en chaîne, ils sont tous abondants.

La construction à ce stade est relativement simple, la plupart d’entre elles sont des applications financières, et avec le soutien de l’expérience dans la transformation et l’imitation de la deuxième couche d’Ethereum, elle est plus facile et plus rapide. Bien que relativement simple, ce processus est essentiel et important : il a contribué à faire prospérer l’écologie, à attirer du trafic et des fonds, à tester la technologie de connexion inter-chaînes, à tester les pièces stables et à tester diverses possibilités. Cette étape consiste principalement à réaliser diverses vérifications de faisabilité fonctionnelle.

(2) La deuxième étape correspond aux étapes intermédiaire et tardive de la construction de deuxième niveau basée sur la chaîne et de la construction de deuxième niveau basée sur un système distribué.

À ce stade, la construction de deuxième couche basée sur la chaîne est également impliquée, qui est une étape avancée de la construction basée sur la chaîne. De plus, la deuxième phase se concentre sur les tests et l’amélioration d’une variété de constructions de deuxième couche distribuées. Le Lightning Network deviendra plus mature, ses fonctions et sa stabilité RVB seront grandement améliorées et ses scénarios d’application seront plus riches. Des concurrents de type RVB émergeront et mûriront progressivement, comme BitVM. Dans le même temps, les systèmes distribués comme Nostr intégreront également des fonctions de valeur. Cette étape consiste principalement à réaliser diverses vérifications de faisabilité fonctionnelle et de performance.

(3) Construction à grande échelle basée sur l’écologie Bitcoin

La dernière étape est l’étape de maturité. Dans cette étape, le Web3.0 commence à être construit en grande quantité et mûrit progressivement. Les applications courantes décrites en 3.1 ont commencé à entrer dans l’ère du Web3.0.

Peut-être que cette étape mettra plus de temps à arriver, peut-être qu’il y aura un événement de point d’inflexion qui pourra favoriser l’entrée d’un grand nombre d’applications Web2.0, et le temps ne sera peut-être pas si long.

Quoi qu’il en soit, lorsque la véritable ère du Web3.0 arrivera, elle sera certainement très différente : ses fonctions et sa valeur de production seront plus grandes et plus brillantes que l’Internet PC + Internet mobile actuel dans son ensemble. C’est peut-être comme l’émergence de Sora dans le domaine de l’IA, ce qui est très étonnant et choquant, mais le processus n’est pas si soudain.

Description de la référence

(1) Se référer aux articles et contenus de cours de M. Dashan sur les aspects à court, moyen et long terme de l’écologie du Bitcoin.

(2) “L’impossible devient possible : faire du développement de jeux en chaîne complète une réalité sur le réseau Lightning” (L’inspiration et la vérification de cet article sont encore plus grandes)

(3) Les trois angles d’observation font principalement référence à « Ethereum EVM illustré », Takenobu T., 2018.3

(4) Pour les contenus liés à la classification des applications, reportez-vous principalement à « Web3.0 : Building the Digital Future of the Metaverse » écrit par l’auteur en 2022.

(5) Se référer aux connaissances en théorie des graphes en logique numérique universitaire.

(6) Il est fait référence à certains articles sur les systèmes distribués.