Observando la segunda capa de Bitcoin desde la perspectiva de una máquina de estado, ¿cómo es la arquitectura de las aplicaciones Web3 a gran escala?

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

Leer los comentarios:

(1) Este artículo es un poco oscuro porque involucra algunos principios subyacentes del sistema y el autor tiene una experiencia teórica y práctica limitada en sistemas distribuidos. Los lectores generales pueden leer directamente la conclusión, que es la arquitectura de aplicaciones web3.0 a gran escala en la Sección 3.3.

(2) Para conocer la clasificación de la construcción de la segunda capa, consulte el artículo “Un artículo que resume el sistema de conocimiento básico de la construcción de la segunda capa (Capa 2) de Bitcoin”. Según la clasificación de la estructura del sistema en el artículo de referencia, la segunda capa de Bitcoin Layer 2 se divide en tres tipos: estructura blockchain, estructura de sistema distribuido y estructura de sistema centralizado.

(3) Al observar la construcción de la segunda capa de Bitcoin desde la perspectiva de una máquina de estado, encontrará que el principio de la máquina de estado es aplicable a las tres estructuras del sistema (sistema blockchain, sistema distribuido, sistema centralizado), pero la implementación El método está limitado a la estructura del sistema.

(4) Tres ángulos de visión: libro mayor distribuido, máquina de estado, estructura de bloque + cadena

Prefacio Multiniveles y múltiples ángulos

Observar las cosas en múltiples niveles y ángulos pertenece a la metodología de análisis integral. Sus ventajas se reflejan en varios aspectos: amplitud, comprensión profunda, amplitud, precisión y facilidad de ejecución. Las ventajas de la metodología de análisis integral hacen que tenga un gran valor de aplicación en problemas complejos y cambiantes, y puede proporcionar resultados de análisis más completos, profundos y precisos, brindando un fuerte apoyo para resolver problemas y promover el desarrollo.

(1) Múltiples niveles

Los niveles múltiples generalmente se pueden observar en los niveles macro, meso y micro, o desde la perspectiva de los ciclos de tiempo, se pueden utilizar niveles de corto, mediano y largo plazo para la observación. En el desarrollo del ecosistema Bitcoin, podemos obtener un conocimiento y una comprensión más completos, profundos y precisos del ecosistema Bitcoin observándolo desde tres niveles: corto, mediano y largo plazo.

Aquí hay un resumen del profesor Dashan: “El ecosistema de Bitcoin se divide en tres oportunidades: corto, mediano y largo plazo: la oportunidad a corto plazo para el ecosistema de Bitcoin es la pista de inscripción representada por BRC-20; la oportunidad a mediano plazo es la vía de Bitcoin Layer 2 y Nostr Plus. Lightning Network; la oportunidad a largo plazo es la vía de solución fuera de la cadena representada por el protocolo RGB y BitVM. Esto incluye cuatro vías, la vía de Inscripción; la vía de Capa 2; la pista Nostr plus Lightning Network; la pista fuera de la cadena (representada por RGB y BitVM)”.

En la Sección 3.4 de este artículo, la etapa inicial de la construcción de la segunda capa basada en cadenas en Layer también se clasifica como una oportunidad a corto plazo, las razones se presentan en la Sección 3.4.

(2) Múltiples ángulos

Al mismo tiempo, observamos el ecosistema de Bitcoin desde múltiples ángulos, lo que puede aportar ventajas integrales, objetivas, profundas, flexibles e innovadoras. Este tipo de observación desde múltiples ángulos nos ayuda a conocer y comprender mejor las cosas y favorece la innovación.

Desde estas múltiples perspectivas, comenzamos desde la perspectiva empresarial: libro mayor distribuido (que favorece la comprensión del negocio), la perspectiva informática abstracta: máquina de estado (que favorece la comprensión de la implementación de blockchain + sistemas distribuidos) y la perspectiva de implementación técnica: bloque + estructura de la cadena (propicia para comprender la parte blockchain del ecosistema).

1. Tres ángulos de visión

En el documento de Ethereum “Ethereum EVM Illustrated”, se presenta que hay tres ángulos de visión para la estructura de bloques de Ethereum (libro mayor distribuido, máquina de estado, blockchain). Esta observación también se aplica a Bitcoin y es más adecuada para observar la estructura ecológica de Bitcoin. En la siguiente introducción, entenderemos desde estas tres perspectivas y habrá diferentes beneficios.

Desde la perspectiva de una máquina de estado, no solo es fácil comprender el estado y el procesamiento de estado en la cadena de bloques, sino que también es más fácil comprender el estado, los canales de estado y las transiciones de estado en el sistema distribuido. La estructura del sistema distribuido hará que sea más fácil comprender el enrutamiento. El problema es comprender los requisitos del gráfico acíclico dirigido de transiciones de estado. Las máquinas de estado se basan en los principios informáticos abstractos subyacentes de la teoría de grafos. Con base en estos principios y estructuras de implementación específicas (blockchain, distribuida, centralizada), comprenderá los problemas específicos que deben resolverse y las ideas de solución.

En segundo lugar, desde una perspectiva empresarial, entenderemos fácilmente por qué blockchain puede manejar datos confiables y por qué los datos de blockchain pueden usarse como moneda digital, lo que hace que el sistema blockchain se parezca más a un libro de contabilidad. Comprenderá por qué el sistema distribuido no es un libro de contabilidad y necesita cooperar con el libro de contabilidad. Al mismo tiempo, comprenderá cómo el sistema distribuido maneja los datos y el flujo en el libro mayor en cooperación con el libro mayor.

Desde la perspectiva de la implementación técnica, entenderemos que un sistema como Blockchain es una estructura blockchain, y las ventajas y desventajas de esta estructura técnica también se pueden resumir y resumir fácilmente.

Con respecto a la estructura del ecosistema de Bitcoin, desde la perspectiva de los libros de contabilidad y las máquinas de estado, podemos comprender mejor las ventajas y desventajas de cada estructura y cómo usar tres estructuras alternativas para construir la segunda capa de Bitcoin, incluso si construimos Web3. 0 Toda la arquitectura de la aplicación.

Tuve una sensación al leer la documentación de Ethereum “Ethereum EVM ilustrada”. Observar cosas que se pueden comparar con Ethereum desde tres ángulos diferentes nos proporciona algunas ideas de pensamiento y referencias de experiencia de procesamiento para resolver Ethereum. Por ejemplo, cuando se ve a Ethereum como un autómata basado en estados, las teorías y algoritmos de las máquinas de estados en el campo de la informática se pueden aplicar a Ethereum mediante transformación. Al considerar a Ethereum como una base de datos basada en un libro mayor, algunas teorías de la base de datos se pueden aplicar a Ethereum, como la idea de fragmentación de la base de datos. Este sentimiento también se aplica al ecosistema de Bitcoin, y se combinará y utilizará en tres grandes estructuras de sistemas, lo que hará que la flexibilidad sea aún mayor.

1.1 Perspectiva empresarial: libro mayor distribuido

Desde la perspectiva de un libro de contabilidad, una cadena de bloques es un grupo de transacciones, al igual que las páginas de datos escritas en un libro de contabilidad.

Desde la perspectiva de los libros de contabilidad, nos resulta más fácil comprender sus capacidades comerciales y sus funciones monetarias y financieras. Este es también el papel del libro mayor en la arquitectura general de las aplicaciones Web3.0.

Desde la perspectiva de los libros mayores, podemos comprender fácilmente la construcción de la segunda capa de la cadena: las cuentas de diferentes negocios se pueden registrar en diferentes libros mayores y estos libros auxiliares se pueden resumir en el libro mayor general.

Desde la perspectiva del libro mayor + distribución, podemos entender que si a un participante se le da una moneda digital, cómo manejarla y cómo dividir las cuentas, los participantes pueden negociar y manejarla ellos mismos, y finalmente registrarla en el libro mayor. .

1.2 Perspectiva informática abstracta: máquina de estados

Aquí nos centramos en las máquinas de estado, porque esta perspectiva puede proporcionar una buena comprensión de los sistemas blockchain y los sistemas distribuidos. Y puede comprender la diferencia entre cómo se procesan los datos (o el estado) en un sistema blockchain y cómo se procesan en un sistema distribuido.

Desde una perspectiva estatal, blockchain es una máquina de estado basada en transacciones. Una transacción es una condición desencadenante que hace que un estado original σt se transforme al siguiente estado σt+ 1 bajo la acción de la transacción.

Un conjunto de transacciones se empaqueta en una cadena de bloques, que es un paquete de datos, lo que hace que cambie el estado asociado con este conjunto de datos.

Entonces, desde esta perspectiva, blockchain es una cadena estatal (en un sistema distribuido, es un canal estatal). Desde una perspectiva estatal, el sistema blockchain puede verse como un autómata basado en el estado.

Desde la perspectiva del estado, cuando observamos el sistema distribuido blockchain +, será más fácil comprender las reglas de transmisión y cambio de estado en los dos sistemas. Ambos sistemas son en realidad autómatas basados en el estado.

Cuando la cadena de bloques se ve como un autómata basado en estados, las teorías y algoritmos sobre las máquinas de estados en la teoría de grafos en el campo de la informática se pueden aplicar a la cadena de bloques. De manera similar, si la estructura técnica implementada no es una estructura blockchain, sino una estructura distribuida, también podemos usar la teoría de la máquina de estados. Como el gráfico acíclico finito DAG (para evitar flores dobles), los canales de estado y el sellado único son tecnologías que deben usarse para manejar estados en sistemas distribuidos.

1.3 Perspectiva de implementación técnica: estructura de bloque + cadena

Desde una perspectiva de implementación técnica, sistemas como Bitcoin y Ethereum son una cadena de bloques. Los datos dispersos están vinculados entre sí mediante el bloque de datos y el puntero hash en su interior.

Esta es solo una estructura de implementación técnica mantenida para operar un sistema como blockchain. Los datos y cálculos en la cadena de bloques adoptan un enfoque global y solo esta estructura puede completar la función del libro mayor. Es necesario considerar los detalles de implementación y la aplicabilidad de esta estructura al interactuar con sistemas externos.

Podemos comprender fácilmente las características de esta estructura de implementación de tecnología blockchain + cadena y también podemos calcular indicadores de rendimiento. Por ejemplo, el tamaño de bloque de la red Bitcoin es 1 M (el máximo teórico es 4 M después de admitir Segregated Witness) y la cantidad de transacciones que admite se puede calcular por completo.

La fórmula de cálculo es: (tamaño de bloque/tamaño promedio de transacciones)/intervalo de tiempo promedio de bloque. En circunstancias normales, cada bloque de Bitcoin puede acomodar aproximadamente entre 2000 y 3000 transacciones, o entre 3 y 7 TPS.

1.4 Características básicas de blockchain y características de tres estructuras de construcción de Capa 2

Consulte las tres clasificaciones de la construcción de la segunda capa de Bitcoin: estructura de cadena de bloques, estructura de sistema distribuido y estructura de sistema centralizado. Al comparar algunas características básicas de la construcción de la primera y la segunda capa de Bitcoin, podemos ver claramente las diferencias entre ellas. Como se muestra en la siguiente tabla. Más adelante, compararemos los requisitos de la aplicación en la Sección 3.2 para ayudarnos a seleccionar una combinación de construcción de arquitectura adecuada a partir de estas estructuras de sistemas básicos.

A través de la tabla anterior, podemos resumir aproximadamente las características de la estructura blockchain, la estructura del sistema distribuido y la estructura centralizada.

(1) Estructura de la cadena de bloques

El mayor beneficio de la estructura blockchain es que resuelve problemas relacionados con la confianza y puede registrar el proceso de cambio de datos (transición de estado), por lo que los datos y las reglas de cálculo se convierten en datos y cálculos confiables. Entre estos datos confiables, uno son los datos originales básicos (expresados como moneda) y el otro es el conjunto de instrucciones para procesar datos (expresados como código y contratos inteligentes).

El mayor problema de la estructura blockchain es el bajo rendimiento. Hay dos razones para esto: en primer lugar, la estructura blockchain no puede eliminar escenarios de cálculo parciales y todas las solicitudes se procesan en forma de cálculo completo. Por ejemplo, cálculo parcial y cálculo global, datos locales y datos globales, datos temporales y datos permanentes. En segundo lugar, la estructura blockchain tiene un límite superior de rendimiento obvio. Si la expansión de la capa 2 se realiza a través de una cadena, la cantidad de transacciones admitidas también es muy limitada. Un cálculo simple es el siguiente:

El límite superior de un sistema blockchain es el número máximo de transacciones que puede acomodar una capacidad de bloque único. El límite superior de una cadena de bloques multinivel es el producto del número de transacciones en la capacidad de bloque de cada capa. Por ejemplo, una capa de Bitcoin tiene 7 TPS por segundo y una cadena de capa 2 tiene una capacidad de procesamiento de 100 TPS, entonces las dos estructuras combinadas son 700 TPS.

Para ampliar el rendimiento de las estructuras que contienen blockchain, se requiere una construcción multicapa y debe usarse junto con sistemas heterogéneos. Para el trabajo que debe completarse en el sistema blockchain, solo se deben registrar los datos que deben guardarse y calcularse globalmente. Otros datos no globales se pueden asignar a otras capas para su procesamiento, de modo que los datos procesados y el código solo estén relacionados. a las partes relevantes tanto como sea posible.

De la tabla anterior, solo la estructura blockchain puede realizar la función de libro mayor sin confianza, por lo tanto, si un sistema quiere realizar la función de libro mayor sin confianza, debe incluir un sistema blockchain. Sin embargo, debido a los requisitos de rendimiento de las aplicaciones a gran escala, el sistema blockchain debe combinarse con otros sistemas para satisfacer las necesidades.

(2) Sistema distribuido

En la tabla anterior, podemos ver las ventajas obvias de los sistemas distribuidos: la descentralización, el rendimiento y la escalabilidad son excelentes, pero hay características más complejas en la implementación de funciones. Además, los sistemas distribuidos no tienen la capacidad de confiar en el libro mayor.

Por lo tanto, si podemos utilizar el sistema distribuido en la construcción de la segunda capa basada en la función de contabilidad de la primera capa de Bitcoin, en teoría podemos lograr una expansión ilimitada del rendimiento mientras mantenemos las características básicas de la cadena de bloques. Un caso en esta área es el de Bitcoin + Lightning Network. El rendimiento de esta combinación es de 7 TPS * ∞ de Bitcoin.

La razón para lograr la integridad de Turing en un sistema distribuido es que el costo de registrar y ejecutar contratos inteligentes en un sistema blockchain es muy alto porque se trata de datos y códigos globales. Por lo tanto, los contratos inteligentes también son adecuados para la teoría en capas, que limita el almacenamiento de código y la ejecución de contratos inteligentes a los participantes. Este es también el escenario donde ocurre la verificación del lado del cliente en sistemas distribuidos: solo se requieren datos confiables (estado, sello único) entre las partes relevantes para participar en el cálculo, y los cálculos completos de Turing solo se realizan localmente. Esto es lo que a menudo se dice sobre el consenso de toda la red y el consenso de los participantes en los sistemas distribuidos. La mayor dificultad para construir la segunda capa con una estructura de sistema distribuido es que la implementación técnica es relativamente compleja. Redes como Lightning Network que simplemente resuelven problemas de pago se están desarrollando lentamente y tienen muchas imperfecciones. Es aún más desafiante implementar la computación completa de Turing en un sistema distribuido. El lento desarrollo y las lentas actualizaciones de versiones de RGB son un caso de referencia.

El mayor costo de resolver la complejidad es la vulnerabilidad a los problemas de seguridad y el alto umbral de desarrollo. La implementación de funciones de contrato inteligente completas de Turing en un sistema distribuido no solo requiere un ciclo de desarrollo largo y difícil para la plataforma subyacente, sino que también a menudo conduce a vulnerabilidades en el código del contrato y continuos ataques de piratas informáticos.

(3) Sistema centralizado

En la tabla anterior, podemos ver que el beneficio del sistema centralizado es que la implementación de ingeniería es relativamente simple, debido al simple control lógico interno y al simple cálculo. De manera similar, los sistemas centralizados no tienen la capacidad de confiar en los libros de contabilidad. Las ventajas de un sistema centralizado no son sobresalientes: si está procesando datos a pequeña escala, o procesando datos temporales y cálculos temporales, será relativamente adecuado.

La construcción del segundo piso del sistema centralizado se puede utilizar como solución complementaria o transitoria a los otros dos métodos.

(4) Análisis completo

En la era del valor, a través del contenido anterior, podemos ver que es difícil lograr el efecto de satisfacer las necesidades confiando en un solo sistema. Esta es también una necesidad práctica para la segunda capa del desarrollo ecológico de Bitcoin. Pero cómo combinar estos tres sistemas requiere mucha exploración, analicémoslo teóricamente primero: ante diferentes necesidades, habrá diferentes estructuras de combinación.

En primer lugar, desde la perspectiva del concepto de diseño de capas de protocolos, la red Bitcoin no requiere la integridad de Turing: es una máquina de confianza global y solo necesita guardar los datos y los cambios de datos que requieren confianza global. Con base en este requisito tan básico, el conjunto de instrucciones de Bitcoin se puede reducir al mínimo. Otras funciones se dejan para que las completen las extensiones de la capa superior. Además de cumplir con los requisitos funcionales de esta capa, también es necesario desarrollar y mejorar aún más la tecnología de conexión entre la primera capa de Bitcoin y la red de la capa superior. Además, esta tecnología de conexión, bajo la premisa de cumplir con las funciones, ocupa el menor espacio de datos posible de Bitcoin.

Generalmente, las aplicaciones pequeñas solo deben completarse en una única cadena de bloques. Los sistemas un poco más grandes son adecuados para completar la construcción de la segunda capa de blockchain + blockchain. Pero para aplicaciones a gran escala, la solución preferida es utilizar un sistema blockchain + sistema distribuido. Desde una perspectiva de rendimiento, el límite superior del sistema distribuido es teóricamente ilimitado, por lo que dicha combinación es 7 TPS * ∞ de Bitcoin. La implementación de ingeniería también estará limitada por algunos factores específicos. Por lo general, el límite superior de dicho sistema está limitado por las capacidades de enrutamiento del sistema distribuido, las capacidades de procesamiento de gráficos acíclicos dirigidos de cambios de estado y otros vínculos de implementación técnica específicos. Más adelante, en la arquitectura de aplicación típica de Web3.0, también se pueden ver los diagramas de combinación de varios sistemas.

Mediante la combinación de múltiples estructuras de sistemas, se pueden superar las limitaciones de la teoría básica de un sistema único. Por ejemplo, el sistema blockchain está limitado por las limitaciones del triángulo imposible DSS, pero si se utiliza un sistema blockchain + sistema distribuido, se puede resolver el triángulo imposible de descentralización D, seguridad S y escalabilidad S. Otras combinaciones, blockchain + sistema centralizado, también pueden resolver el problema de escalabilidad hasta cierto punto. El sistema distribuido + el sistema centralizado puede resolver las limitaciones del triángulo CAP en los sistemas distribuidos.

En la historia del desarrollo tecnológico del pasado también hubo algunos casos de uso combinado. Por ejemplo, cuando la base de datos centralizada tiene capacidades limitadas, adopta una estructura maestro-esclavo, luego pasa a subbases de datos y subtablas, a bases de datos distribuidas, que son ejemplos del uso de sistemas centralizados y sistemas distribuidos.

Esta combinación también encarna una idea filosófica: **La solución a un problema no puede obtener la respuesta en el nivel donde surge el problema, pero puede resolverlo en un nivel superior. **No es muy fácil entender esta frase con claridad. Pienso en una metáfora particularmente buena en “El Zen y el arte del mantenimiento de motocicletas”: No podemos levantarnos por el pelo. Esto nos dice que no podemos confiar en el sistema en sí para resolver nuestros propios problemas, sino que debemos utilizar sistemas externos para resolverlos.

2. Revisar el diseño y desarrollo de la segunda capa de Bitcoin desde la perspectiva de una máquina de estados

En los tres edificios de dos pisos existen estados y máquinas de estados, pero los nombres son ligeramente diferentes, lo que hace que la mayoría de la gente no preste atención a este ángulo de observación.

Si lo miramos desde la perspectiva de los estados y las máquinas de estados, las tres estructuras de dos capas son todas máquinas de estados que procesan estados, pero los principios son ligeramente diferentes. Cuando estos tres sistemas se utilizan en combinación, es necesario garantizar que el concepto de “estado” sea coherente en los tres sistemas y que la máquina de estado de cada sistema pueda manejar cambios de estado, pero no pueda destruir la coherencia del estado.

Desde la perspectiva de una máquina de estados, la arquitectura de aplicaciones del ecosistema Bitcoin o Web3.0 utiliza la combinación de estos sistemas para completar el procesamiento de las transformaciones de estado y así completar el procesamiento de la lógica de negocios.

Utilizando la idea de máquinas de estado, observamos la construcción de red de dos capas de Bitcoin y podemos ver que cada capa de la arquitectura tiene una división del trabajo adecuada a sus características.

2.1 Conocimientos básicos de estados y máquinas de estados en teoría de grafos

En teoría de grafos, el conocimiento básico de los estados y las máquinas de estados incluye lo siguiente:

Estado: El estado se refiere a un nodo o vértice en la teoría de grafos. En un gráfico dirigido, el estado se puede representar como un nodo; en un gráfico no dirigido, el estado se puede representar como un vértice.

Transición de estado: La transición de estado se refiere al proceso de un estado a otro. En un gráfico dirigido, la transición de estado se puede representar como un borde dirigido; en un gráfico no dirigido, la transición de estado se puede representar como un borde no dirigido.

Máquina de estados: una máquina de estados es un modelo informático abstracto que se utiliza para describir una serie de estados y reglas de transición entre estados. La máquina de estados consta de un conjunto de estados, un estado inicial, una función de transición y un estado de terminación.

** Gráfico dirigido **: un gráfico dirigido es una estructura de gráfico compuesta por vértices y aristas dirigidas. Los bordes dirigidos apuntan de un vértice a otro vértice, lo que representa la relación de transición entre estados.

** Gráfico no dirigido **: Un gráfico no dirigido es una estructura de gráfico compuesta por vértices y aristas no dirigidas. Los bordes no dirigidos conectan dos vértices y representan la asociación entre estados.

Clasificación topológica: la clasificación topológica se refiere a ordenar linealmente los vértices de un gráfico acíclico dirigido (DAG), de modo que para dos vértices cualesquiera u y v, si hay un borde (u, v), entonces u aparece antes de v. en la clasificación.

Gráfico acíclico dirigido (DAG): Un gráfico acíclico dirigido es un gráfico dirigido en el que no hay un ciclo que comience desde un vértice y regrese al vértice después de pasar por varias aristas.

Ruta más corta: la ruta más corta se refiere a la ruta con la suma más pequeña de pesos de borde entre las rutas que conectan dos vértices en el gráfico.

Árbol de expansión mínimo: El árbol de expansión mínimo se refiere a encontrar un árbol que contenga todos los vértices en un gráfico conectado de modo que la suma de los pesos de los bordes del árbol sea mínima.

Estos conocimientos básicos son conceptos centrales en la teoría de grafos y se utilizan para describir y analizar las relaciones y reglas de transición entre estados. Los conocimientos y gráficos relevantes se pueden aprender en profundidad en libros profesionales.

Aunque este conocimiento parece un poco abstracto y aburrido, es fácil de entender si lo convertimos en algunos conceptos de blockchain que encontramos a menudo. Por ejemplo, algunos escenarios requieren gráficos acíclicos dirigidos para evitar el problema del doble gasto; la encapsulación única es transformar el estado en la cadena de bloques al estado en el sistema distribuido; el algoritmo de enrutamiento es encontrar el camino más corto en el sistema distribuido Cálculo: la ruta con el costo de pago más pequeño en Lightning Network es el problema del árbol de expansión mínimo; la verificación del cliente también puede considerarse como una forma de máquina de estado.

2.2 Máquina de estados y sistema distribuido

Aquí utilizamos varias redes distribuidas para presentar:

(1) En la Red Lightning

En Lightning Network, los puntos de conocimiento relacionados con estados y máquinas de estados son:

Lightning Network es una solución de segunda capa para Bitcoin basada en la tecnología de canal estatal. El canal de pago en Lightning Network es un canal estatal bidireccional. Los participantes pueden realizar múltiples transacciones en el canal y actualizar el estado del canal para lograr resultados rápidos y bajos. -transacciones de costos.Pago de costos.

Las transacciones (es decir, estados) en Lightning Network se implementan a través de contratos de tiempo bloqueado (HTLC) basados en Hash, a través de los cuales los participantes pueden bloquear fondos (el estado se transfiere entre los sistemas Bitcoin y Lightning Network) y realizar transacciones seguras dentro de los canales. (manejo de estado simple).

Enrutamiento en Lightning Network: para permitir pagos entre canales, Lightning Network utiliza un mecanismo llamado enrutamiento, donde los participantes pueden realizar pagos encontrando una ruta confiable.

Nodos de retransmisión en Lightning Network: los nodos de retransmisión son nodos que pueden reenviar solicitudes de pago y pueden ayudar a realizar pagos entre canales.

Pago bidireccional en Lightning Network: Lightning Network permite a los participantes realizar pagos bidireccionales en el canal de pago, es decir, no solo pueden pagar a la otra parte, sino también aceptar el pago de la otra parte.

Privacidad de pago de Lightning Network: dado que las transacciones en Lightning Network se realizan dentro del canal, no es necesario escribir todas las transacciones en la cadena de bloques, por lo que se puede mejorar la privacidad de los pagos.

Limitaciones de Lightning Network (principalmente limitaciones de estado y tecnología de implementación de máquinas de estado): Lightning Network también tiene algunas limitaciones, como la capacidad de supervivencia del canal, el tiempo de bloqueo de fondos, etc. Estas limitaciones deben considerarse de manera integral para diseñar un canal de pago adecuado.

(2) En RGB, los puntos de conocimiento relacionados con el estado, la máquina de estados y el canal de estado son:

RGB se basa en los protocolos LNP y BP. Existe una discusión sobre si RGB es la segunda o tercera capa. Si RGB se calcula directamente en base a BP, extiende directamente la función completa de Turing de Bitcoin y pertenece a la segunda capa. Este método tiene una expansión limitada del rendimiento. Si el cálculo RGB se basa en LNP, pertenece a la tercera capa (porque LNP es la segunda capa de Bitcoin), este método puede ampliar tanto el rendimiento como la potencia informática completa de Turing, pero existe una cierta complejidad en la implementación técnica. . Por lo general, el método combinado no solo puede expandir la potencia informática, sino también expandir el rendimiento y reducir la complejidad de la implementación.

RGB se basa en la tecnología de canal estatal en Bitcoin o Lightning Network. El canal de estado en RGB se refiere al canal de comunicación entre dos o más partes construido en LNP y BP. Se pueden realizar múltiples transacciones y actualizaciones de estado dentro del canal, lo que reduce la cantidad de transacciones y tarifas en la cadena de bloques.

Los canales estatales en RGB utilizan scripts de firmas múltiples basados en Bitcoin para bloquear fondos y utilizan tipos de transacciones especiales para actualizar el estado del canal.

El canal estatal en RGB se puede aplicar a varios escenarios, como canales de pago, intercambios descentralizados, emisión de activos, etc., mejorando la eficiencia de las transacciones y la experiencia del usuario.

El canal de estado en RGB realiza pagos y transferencias de activos actualizando el estado del canal. No es necesario escribir las transacciones en el canal en la cadena de bloques, solo se escribirá el estado final en la cadena de bloques.

El canal estatal en RGB también puede implementar funciones más complejas, como intercambios atómicos, enrutamiento de pagos, etc., a través de contratos inteligentes y scripts de firmas múltiples.

Los canales de estado en RGB se pueden combinar con otras tecnologías y protocolos, como Lightning Network, LNURL, etc., para proporcionar una funcionalidad más rica y una mejor experiencia de usuario.

El diseño e implementación de canales estatales en RGB debe considerar factores como seguridad, privacidad, escalabilidad, etc. para garantizar la confiabilidad y disponibilidad del sistema.

(3) En Nostr, conceptos relacionados con estados, máquinas de estados y canales de estados.

En Nostr, debido a que la información se transmite, los conceptos de estado (datos confiables, moneda digital) y máquina de estado aún no se han reflejado. Sin embargo, creo que si se modifica ligeramente la estructura distribuida de Nostr y se aumenta el procesamiento de estados, se formará un sistema similar a Lightning Network, que puede transmitir información y entregar valor. La posibilidad de transformar gradualmente este sistema distribuido basado en información en un sistema distribuido que incluya procesamiento de valores también se describe en el diagrama de arquitectura de la aplicación Web3.0 en la Sección 3.3.

Una breve introducción al Nostr actual: Hay dos componentes principales en Nostr, el cliente y el relé. Cada usuario ejecuta un cliente y se comunica con otros a través de retransmisiones. Cada usuario está identificado mediante una clave pública. Cada publicación que hace un usuario está firmada. Cada cliente verifica estas firmas. Los clientes obtienen datos y los publican en el relé de su elección. Los repetidores no se comunican entre sí, sólo directamente con los usuarios.

(4) En sistemas distribuidos, los puntos de conocimiento relacionados con las máquinas de estado incluyen:

Modelo de máquina de estados: Una máquina de estados es un modelo matemático que describe las transiciones y el comportamiento de un sistema entre diferentes estados. En los sistemas distribuidos, los modelos de máquinas de estados se utilizan a menudo para describir el comportamiento y los cambios de estado del sistema.

Máquina de estados finitos (FSM): la máquina de estados finitos es el modelo de máquina de estados más básico, que contiene un conjunto finito de estados y un conjunto de reglas de transición entre estados. En los sistemas distribuidos, las máquinas de estados finitos pueden describir varios estados del sistema y transiciones entre estados.

Transición de estado: la transición de estado se refiere al proceso en el que el sistema pasa de un estado a otro. En un sistema distribuido, las transiciones de estado pueden desencadenarse por diversos eventos o condiciones, como la recepción de mensajes, el tiempo de espera, etc.

Comportamiento de la máquina de estados: la máquina de estados puede definir diferentes comportamientos en diferentes estados. En un sistema distribuido, el comportamiento de una máquina de estados puede incluir procesar mensajes, realizar operaciones, enviar mensajes, etc.

Coherencia de estado: en un sistema distribuido, varios nodos pueden tener diferentes estados. La coherencia del estado se refiere a mantener los estados de varios nodos del sistema coordinados y coherentes entre sí.

Máquina de estados distribuidos (DSM): la máquina de estados distribuidos se refiere a una tecnología que aplica modelos de máquinas de estados a sistemas distribuidos. Puede distribuir el estado del sistema y las transiciones de estado entre múltiples nodos y garantizar la coherencia del estado entre los nodos.

Máquina de estados atómicos (ASM): una máquina de estados atómicos se refiere a una máquina de estados que mantiene la atomicidad durante las transiciones de estado. En los sistemas distribuidos, las máquinas de estados atómicos pueden garantizar la coherencia y confiabilidad del sistema durante las transiciones de estado.

Protocolo de coherencia: un protocolo de coherencia es un protocolo utilizado para garantizar la coherencia del estado en un sistema distribuido. Los protocolos de consenso comunes incluyen Paxos, Raft, ZAB, etc.

Tolerancia a fallos: las máquinas de estado distribuidas deben ser tolerantes a fallos, es decir, el sistema aún puede mantener el estado y el comportamiento correctos en caso de fallo del nodo o pérdida de mensajes.

Escalabilidad: las máquinas de estados distribuidos deben ser escalables, es decir, deben poder mantener transiciones de estado eficientes y coherencia a medida que aumenta la escala del sistema.

2.3 Máquina de estados y sistema blockchain

Según el documento de Ethereum “Ethereum EVM ilustrado”, cada bloque es un conjunto de estados de activación y todo el sistema Ethereum es un procesador de estado. En 1.2, introdujimos el contenido de la máquina de estados en el sistema blockchain. También hay muchas descripciones de máquinas de estado en el documento técnico de Ethereum.

Aunque la máquina de estados tiene fuertes capacidades de procesamiento, su límite superior es el techo de la estructura blockchain.

Para la aplicación combinada de interconexión blockchain basada en el modelo UTXO y el modelo de cuenta (como EVM), los métodos de implementación de estado y máquina de estado son bastante diferentes. Las cadenas de bloques basadas en el modelo UTXO son más fáciles de combinar con sistemas distribuidos porque los estados en ambos sistemas se basan en UTXO y no hay conversión o solo una conversión simple, que es más fácil de implementar. La cadena basada en el modelo de cuenta requiere una mayor encapsulación y conversión entre su estado y el estado del sistema distribuido externo, lo cual es complejo de implementar, lo que también es parte de la razón por la cual el desarrollo de Raiden Network en Ethereum no es fluido.

2.4 Máquina de estados y sistema centralizado

Ejemplos de uso de sistemas centralizados blockchain + incluyen Ordinals y el intercambio centralizado CEX.

Estos sistemas son relativamente simples y algunos no tienen ninguna transferencia estatal, como los ordinales, que sólo utilizan índices centralizados para completar el trabajo estadístico.

Al igual que un intercambio centralizado, la transferencia de estado en él depende completamente de las reglas establecidas por el sistema centralizado. La máquina de estado interna también es un procesador de estado compuesto por programas del sistema centralizado y no existen conceptos complicados.

En futuras aplicaciones Web3.0, debería haber más casos de uso de sistemas centralizados blockchain +.

3. ¿Cómo debería ser la estructura de una aplicación Web3?

A través del contenido anterior del artículo, sabemos que mediante la combinación de tres arquitecturas de dos capas de Bitcoin, se pueden completar diseños estructurales más complejos para obtener los requisitos de características requeridos. Y desde una perspectiva empresarial, si la lógica subyacente de la aplicación se puede descomponer en estados y máquinas de estados, se puede utilizar una combinación de los tres sistemas para completar toda la lógica empresarial de la capa superior.

Entonces, ¿cuáles son estas combinaciones comunes? ¿Qué factores determinarán la estructura de la cartera? Especulamos sobre la estructura de aplicaciones a gran escala que cumplen con Web3.0 en función de clasificaciones y requisitos de aplicaciones comunes.

3.1 Clasificación de aplicaciones comunes

Utilizamos como referencia las estadísticas de aplicación del 48.º “Informe estadístico sobre el desarrollo de Internet en China”, en lo sucesivo denominado informe estadístico. Debido a que Web2.0 ha madurado y no afecta el análisis de la clasificación de aplicaciones y los resultados de la escala de usuarios, los datos de referencia de aplicaciones que utilizamos son datos antiguos de 2020 y 2021. Una cosa a tener en cuenta es que estas son solo las estadísticas de Internet en China: en la etapa Web3.0, muchas aplicaciones son globales y los usuarios tienen mayores requisitos de escala y rendimiento.

En el informe estadístico podemos ver que las aplicaciones en Web2.0 son muy ricas y tienen un enorme grupo de usuarios. Estas aplicaciones incluyen: mensajería instantánea, vídeo en línea, vídeo corto, pago en línea, compras en línea, motor de búsqueda, noticias en línea, música en línea, transmisión en vivo en línea, juegos en línea, comida para llevar en línea, literatura en línea, transporte compartido en línea, oficina en línea y reserva de viajes online, educación online, atención médica online,… cubriendo casi todos los ámbitos de la vida de las personas. Además de estos contenidos de Internet para el consumidor, también existen muchas aplicaciones en la Internet industrial.

Si todas las aplicaciones Web2.0 se migran a Web3.0, la mayoría de ellas tendrán requisitos de rendimiento muy altos. Tomando el pago de Visa como ejemplo, el requisito de rendimiento máximo es: 65.000 TPS. Dichos indicadores de rendimiento solo pueden ser compatibles con sistemas distribuidos. Por ejemplo, el rendimiento actual de Lightning Network es de 40 millones de transacciones por segundo, y el rendimiento de Lightning La red no es teóricamente suficiente límite superior.

Además, tomemos juegos comunes como ejemplo: actualmente, el juego de cadena completa con el TPS más alto en la cadena de bloques puede alcanzar un pico de alrededor de unos pocos miles de TPS, lo que representa una gran brecha con respecto a los juegos tradicionales Web2 3A con cientos de miles. del TPS. Si desea migrar todos los juegos a Web3.0, el rendimiento de la infraestructura requerido será un gran desafío.

Es más, los juegos son sólo una aplicación dentro de las categorías de aplicaciones comunes, y otras aplicaciones tienen más rendimiento y requisitos específicos.

3.2 Requisitos para aplicaciones Web3.0

Para comprender las necesidades de la aplicación, será más directo utilizar la estructura de ingresos como indicador. Nos referimos al informe “Token Terminal, curado por FutureMoney Research 2022 Q2”. Aunque este informe es anterior, el pago y otras aplicaciones se encuentran en la etapa inicial y no afectarán los resultados del análisis principal. Así que el autor fue vago aquí y usó los datos cuando estaba escribiendo libros Web3.0. Si hay datos del cuarto trimestre de 2023, serán más precisos.

(1) Análisis de necesidades a través de informes de ingresos

La clasificación de ingresos en el informe representa mejor la composición actual de productos principales de Web3.0. como muestra la imagen.

1. Los ingresos de la Capa 1 (la cadena principal básica de blockchain) son del 48%, lo que representa casi la mitad de los ingresos totales. Su modelo de negocio puede entenderse como “venta de espacio en bloque”;

2. Los ingresos de la plataforma comercial NFT representan el 22% y su modelo de negocio puede entenderse como regalías o actividades de marketing;

3. Los ingresos de DeX en DeFi representan el 15%, y su modelo de negocio son las tarifas de transacción y los ingresos por generación de mercado de liquidez;

4. Los ingresos por apuestas en DeFi representan el 8%, y su modelo de negocio es el diferencial de comisiones o intereses de la gestión de activos;

5. Gamefi representa el 5% y su modelo de negocio son regalías, tarifas de transferencia, ventas de NFT, etc.;

6. Los ingresos por préstamos en DeFi representan aproximadamente el 1% y su modelo de negocio es el diferencial de intereses;

7. Los ingresos de Tooling representan aproximadamente el 1% y su modelo de negocio son las tarifas de servicio, que también incluirán tarifas de monetización del tráfico en el futuro;

Otras industrias relacionadas con Web3.0 no son aplicaciones Web3.0 y no se cuentan como industrias principales de Web3.0 y no se incluirán. Por ejemplo: medios Web3.0, organizaciones de investigación, organizaciones de formación, etc.

A partir de la estructura de ingresos, podemos ver que las necesidades de aplicaciones actuales del ecosistema BTC pueden resolverse básicamente mediante blockchain y su sistema de segunda capa, sin la necesidad de una arquitectura de sistema compleja. Sin embargo, Gamefi y SocialFi se están desarrollando relativamente rápido. Utilizando los ejemplos de juegos en la literatura de referencia, podemos ver que los juegos a gran escala ya tienen requisitos más altos y claros para la estructura del sistema.

Desde la estructura de ingresos, podemos ver las necesidades de aplicación del ecosistema BTC actual. Vale la pena rehacer todos los productos en Ethereum y otros ecosistemas. Transformar ligeramente la tecnología de construcción de segunda capa basada en cadena en el ecosistema Ethereum y establecer una nueva segunda capa en Bitcoin puede satisfacer mejor estas necesidades primarias, pero sólo en el grado de descentralización, seguridad, privacidad y resistencia a la censura. se hizo. En “Un artículo que resume el sistema de conocimiento básico de la construcción de la segunda capa (Capa 2) de Bitcoin”, esas nuevas construcciones de segunda capa basadas en el tipo EVM son todos casos de esta situación.

(2) Análisis de casos de juegos de uso de aplicaciones con requisitos de alto rendimiento

En el artículo “Lo imposible se vuelve posible: hacer realidad el desarrollo de juegos de cadena completa en Lightning Network”, hay una mayor demanda tanto de funcionalidad como de rendimiento. La verdadera arquitectura de las aplicaciones Web3.0 está surgiendo gradualmente.

Descripción del problema en el artículo: Para garantizar la seguridad, la privacidad y la descentralización, los juegos de cadena completa nunca han encontrado la solución óptima para la escalabilidad. Por ejemplo, los motores de juegos de cadena completa más populares, Mud y Dojo, se comprometen a ayudar a los juegos de cadena completa a lograr un TPS más alto, pero los jugadores aún necesitan más de 2 segundos de almacenamiento en búfer para cada operación. De hecho, el juego actual de cadena completa con el TPS más alto en la cadena de bloques puede alcanzar un pico de alrededor de unos pocos miles de TPS, lo que representa una gran brecha con respecto a los juegos tradicionales Web2 3A con cientos de miles de TPS. Si bien persiguen la premisa de no perder las ventajas de blockchain, los juegos de cadena completa pueden superar la escalabilidad.

En la solución que se analiza más adelante en la discusión técnica, se utilizan Lightning Network y RGB para ampliar el rendimiento, y también se proponen los conceptos de cadenas temporales y cadenas dedicadas.

Cadena efímera

Las cadenas de bloques efímeras se pueden definir como cadenas de bloques que no duran para siempre y se destruyen una vez que se cumple el propósito de la cadena de bloques (como registrar transacciones) o una vez que su estado se almacena permanentemente en otro lugar. El estado de terminación almacenado por una cadena temporal son simplemente datos sobre los hechos de terminación asociados con la cadena temporal, comprimiendo así todo en un orden de magnitud considerable. Las cadenas temporales están limitadas principalmente por la latencia de las transacciones y el rendimiento de la cadena de bloques.

Cadena temporal VS canal estatal

En lo que respecta a las cadenas temporales, acabaremos con una gran cantidad de usuarios debido al estado de la cadena pública. El estado que debe insertarse en la cadena pública se reducirá de tamaño mediante poda/compresión/extracción de diferencias y luego se guardará en la cadena pública de forma regular en lugar de irregularmente. La configuración del canal de estado RGB puede evitar las limitaciones de rendimiento de la cadena temporal y lograr la misma función que la cadena temporal.

Blockchains específicos de aplicaciones

Las cadenas de bloques específicas de aplicaciones son cadenas de bloques creadas para ejecutar una única aplicación descentralizada (dapp). En lugar de construir sobre una cadena de bloques existente, los desarrolladores construyen una nueva cadena de bloques desde cero utilizando una máquina virtual (VM) personalizada que ejecuta transacciones para que los usuarios interactúen con la aplicación. Los desarrolladores también pueden personalizar diferentes elementos de la pila de la red blockchain (consenso, red y ejecución) para cumplir con requisitos de diseño específicos. Mejorar la velocidad de ejecución de los contratos inteligentes y resolver las limitaciones de recursos informáticos puede ayudar a la implementación de blockchain para aplicaciones específicas. Facilitar el desarrollo al permitir a los desarrolladores personalizar la infraestructura para diferentes casos de uso. Al mismo tiempo, permite a los desarrolladores web3 crear modelos de valor potentes y ampliar sus dapps para satisfacer las necesidades de crecimiento exponencial e inspirar más innovación.

A través del caso de este juego, junto con nuestro análisis previo de varias arquitecturas, podemos juzgar aproximadamente la arquitectura de futuras aplicaciones a gran escala.

3.3 ¿Cómo debería ser la arquitectura que satisfaga las aplicaciones Web3.0 a gran escala?

En el contenido anterior, conocimos las categorías de aplicaciones comunes en Web2.0. Todas estas aplicaciones se han actualizado a Web3.0, lo que es una señal de que hemos entrado de lleno en la era Web3.0. ¿Qué tipo de arquitectura puede satisfacer las muchas aplicaciones anteriores?

(1) Diferencias arquitectónicas simples entre Web2.0 y Web3.0

Aquí está el contenido del artículo “La arquitectura de una aplicación Web 3.0” escrito por la diosa blockchain Preethi Kasireddy. . La descripción estructural de las aplicaciones Web3.0 aquí es una estructura muy simple que solo se basa en el sistema blockchain. Sin embargo, esta estructura es demasiado simple, no refleja la construcción de la segunda capa y no es competente en aplicaciones a gran escala.

Al comparar los casos de implementación técnica de los productos centralizados tradicionales y los de los productos Web3.0, será más fácil comprender las diferencias en la implementación técnica. En combinación con la descripción de Gavin Wood de la visión de la pila tecnológica de Web3.0, podemos ver que la mayor diferencia en la implementación técnica de Web3.0 está en segundo plano, y la diferencia en la capa de experiencia del usuario es relativamente pequeña.

(2) Arquitectura del sistema para aplicaciones a gran escala en la era Web3.0

En la era sin blockchain, las aplicaciones se creaban en sistemas centralizados y sistemas distribuidos. Por ejemplo, aplicaciones como centros comerciales, mensajería instantánea y videos se crean en sistemas centralizados, y las descargas de Thunder se crean en sistemas distribuidos.

Con el sistema blockchain, hemos entrado en la era Web3.0. Las aplicaciones en este período son una arquitectura compleja construida sobre el sistema blockchain, el sistema distribuido y el sistema centralizado. Entre ellos, el sistema blockchain y su extensión de segunda capa completan la transmisión y el procesamiento de valor, y el sistema distribuido y el sistema centralizado completan la transmisión y el procesamiento de información.

Como se muestra abajo,

El contenido específico se describe a continuación:

(1) La red principal de Bitcoin y la construcción de la segunda capa son el centro de todo el valor, y la mayor parte del valor se construye en esta red. En la construcción de la segunda capa de Bitcoin, la segunda capa basada en cadena completa la expansión del rendimiento y el procesamiento del valor, y procesa todos los datos del libro mayor. En la construcción de segunda capa de Bitcoin, la construcción de segunda capa basada en el sistema distribuido completa la expansión del rendimiento: procesa datos locales relevantes y utiliza el consenso de las partes relevantes, pero los resultados finales del cálculo deben implementarse en la cadena de bloques. sistema. En la construcción de segunda capa de Bitcoin, la construcción de segunda capa basada en el sistema centralizado proporciona directamente servicios para aplicaciones de capa superior.

(2) El sistema similar a RGB también requerirá algunas cadenas temporales o cadenas intermedias para completar la función de liquidación del libro mayor, como se muestra en la línea azul en la figura. El caso del juego en la Referencia 1 describe este escenario. No ha aparecido a gran escala porque la construcción de sistemas similares a RGB es complicada y aún no ha alcanzado la madurez.

(3) Además del ecosistema de Bitcoin, también existen otros ecosistemas de sistemas blockchain para satisfacer las necesidades de diferentes escenarios comerciales. Como describimos en el artículo sobre la infraestructura de la segunda capa, habrá muchos proyectos en la segunda capa basados en la cadena, y lo mismo se aplica a las cadenas en el ecosistema que no es Bitcoin. Otros sistemas blockchain y segundas capas también pueden ingresar a Lightning Network y RGB, y esto ocurrirá gradualmente a medida que la tecnología madure.

(4) En el ecosistema Web3.0, los sistemas centralizados también tendrán un lugar, pero la proporción ya no será tan grande como en Web2.0. Los sistemas centralizados tienen muchas ventajas.

(5) En aplicaciones reales, el cableado interno en la figura anterior será más complicado. Algunas no necesitan usar la segunda capa, sino operar directamente la red de la primera capa, como cuando RGB usa el protocolo BP. Otras cadenas de bloques también pueden utilizar sistemas distribuidos, como Raiden Network en Ethereum. Aunque es inmaduro, si hay escenarios de demanda, habrá escenarios de uso transformando algunas características básicas. La figura anterior es una descripción simplificada de la arquitectura de la aplicación Web3.0.

3.4 Caminos de construcción factibles

Desde la estructura de ingresos, podemos ver las necesidades de aplicaciones actuales del ecosistema BTC, y desde la clasificación de las aplicaciones de uso común, podemos ver las necesidades futuras para ingresar completamente a Web3.0. Será un largo camino. Por lo tanto, las cosas con un período de construcción relativamente largo deben abordarse por etapas.

Las tres etapas aquí son muy similares a las de corto, mediano y largo plazo mencionadas por el maestro Dashan. Simplemente resume la etapa simple de la construcción de la segunda capa basada en cadenas en la primera etapa de construcción.

(1) La primera fase es la etapa inicial de la construcción de dos capas basada en inscripciones y cadenas.

La construcción de dos capas basada en inscripciones y en cadenas es relativamente fácil y actualmente tiene muchas aplicaciones. Ya sean brc 20, src 20, arc 20, inscripción y otras aplicaciones, o esas fiestas de proyectos de construcción de segunda capa basadas en cadenas, todas son abundantes.

La construcción en esta etapa es relativamente simple, la mayoría de ellas son aplicaciones financieras, y con el apoyo de la experiencia en transformar e imitar la segunda capa de Ethereum, es más fácil y rápido. Aunque relativamente simple, este proceso es esencial e importante. Ayudaron a prosperar la ecología, atrajeron tráfico y fondos, probaron la tecnología de conexión entre cadenas, probaron monedas estables y probaron varias posibilidades. Esta etapa es principalmente para completar varias verificaciones de viabilidad funcional.

(2) La segunda etapa son las etapas intermedia y tardía de la construcción de segundo nivel basada en cadena y la construcción de segundo nivel basada en sistemas distribuidos.

En esta etapa también está involucrada la construcción de la segunda capa basada en cadenas, que es una etapa avanzada de la construcción basada en cadenas. Además, la segunda fase se centra en probar y mejorar una variedad de construcciones de la segunda capa distribuidas. Lightning Network madurará, sus funciones RGB y su estabilidad mejorarán enormemente y sus escenarios de aplicación serán más ricos. Poco a poco surgirán y madurarán competidores similares a RGB, como BitVM. Al mismo tiempo, los sistemas distribuidos como Nostr también incorporarán funciones de valor. Esta etapa es principalmente para completar diversas verificaciones de viabilidad funcional y de rendimiento.

(3) Construcción a gran escala basada en la ecología de Bitcoin

La última etapa es la etapa de madurez, en esta etapa la Web3.0 comienza a construirse en grandes cantidades y madura gradualmente. Las aplicaciones comunes descritas en 3.1 han comenzado a ingresar a la era Web3.0.

Tal vez esta etapa tarde más en llegar, tal vez haya un evento de punto de inflexión que pueda promover la entrada de una gran cantidad de aplicaciones Web2.0, y el tiempo puede no ser tan largo.

Pase lo que pase, cuando llegue la verdadera era Web3.0, definitivamente será muy diferente: las funciones y el valor de producción serán mayores y más brillantes que la actual Internet para PC + Internet móvil en su conjunto. Quizás sea como la aparición de Sora en el campo de la IA, que es muy sorprendente e impactante, pero el proceso no es tan repentino.

Descripción de referencia

(1) Consulte los artículos y el contenido del curso del Sr. Dashan sobre los aspectos a corto, mediano y largo plazo de la ecología de Bitcoin.

(2) “Lo imposible se vuelve posible: hacer realidad el desarrollo de juegos de cadena completa en Lightning Network” (La inspiración y verificación de este artículo son aún mayores)

(3) Los tres ángulos de observación se refieren principalmente a “Ethereum EVM ilustrado”, Takenobu T., 2018.3

(4) Para contenido relacionado con la clasificación de aplicaciones, consulte principalmente “Web3.0: Construyendo el futuro digital del metaverso” escrito por el autor en 2022.

(5) Consulte el conocimiento de la teoría de grafos en la lógica digital universitaria.

(6) Se hace referencia a algunos artículos sobre sistemas distribuidos.