Observando a segunda camada do Bitcoin da perspectiva de uma máquina de estado, como é a arquitetura de aplicativos Web3 em larga escala?

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

Leia os comentários:

(1) Este artigo é um pouco obscuro porque envolve alguns princípios subjacentes do sistema, e o autor tem experiência teórica e prática limitada em sistemas distribuídos. Os leitores gerais podem ler diretamente a conclusão, que é a arquitetura de aplicativos web3.0 de grande escala, na Seção 3.3.

(2) Para a classificação da construção de segunda camada, consulte o artigo “Um artigo que resume o sistema de conhecimento básico da construção de segunda camada (Camada 2) do Bitcoin”. De acordo com a classificação da estrutura do sistema no artigo de referência, a segunda camada do Bitcoin Layer 2 é dividida em três tipos: estrutura blockchain, estrutura de sistema distribuído e estrutura de sistema centralizado.

(3) Observando a construção de segunda camada do Bitcoin da perspectiva de uma máquina de estado, você descobrirá que o princípio da máquina de estado é aplicável a todas as três estruturas do sistema (sistema blockchain, sistema distribuído, sistema centralizado), mas a implementação método é limitado na estrutura do sistema.

(4) Três ângulos de visão: razão distribuída, máquina de estado, estrutura de bloco + cadeia

Prefácio Multiníveis e multiângulos

Observar as coisas em vários níveis e ângulos pertence à metodologia de análise abrangente. Suas vantagens se refletem em diversos aspectos: abrangência, compreensão aprofundada, abrangência, precisão e facilidade de execução. As vantagens da metodologia de análise abrangente fazem com que ela tenha um forte valor de aplicação em problemas complexos e mutáveis, podendo fornecer resultados de análise mais abrangentes, aprofundados e precisos, fornecendo forte suporte para a resolução de problemas e promovendo o desenvolvimento.

(1) Vários níveis

Os multiníveis geralmente podem ser observados nos níveis macro, meso e micro, ou da perspectiva dos ciclos temporais, os níveis de curto, médio e longo prazo podem ser usados para observação. No desenvolvimento do ecossistema Bitcoin, podemos obter uma compreensão mais abrangente, profunda e precisa do ecossistema Bitcoin, observando-o a partir de três níveis: curto prazo, médio prazo e longo prazo.

Aqui está um resumo do professor Dashan: “O ecossistema Bitcoin está dividido em três oportunidades: curto prazo, médio prazo e longo prazo: A oportunidade de curto prazo para o ecossistema Bitcoin é a faixa de inscrição representada pelo BRC-20; a oportunidade de médio prazo é a trilha Bitcoin Layer 2 e Nostr Plus. Trilha Lightning Network; a oportunidade de longo prazo é a trilha de solução fora da cadeia representada pelo protocolo RGB e BitVM. Isso inclui quatro trilhas, a trilha Inscription; a trilha Layer 2; a trilha Nostr mais Lightning Network; a trilha off-chain (representada por RGB e BitVM).

Na Seção 3.4 deste artigo, o estágio inicial da construção da segunda camada baseada em cadeia no Layer também é classificado como uma oportunidade de curto prazo. As razões são apresentadas na Seção 3.4.

(2) Vários ângulos

Ao mesmo tempo, observamos o ecossistema Bitcoin de múltiplos ângulos, o que pode trazer vantagens abrangentes, objetivas, aprofundadas, flexíveis e inovadoras. Este tipo de observação multiângulo ajuda-nos a conhecer e compreender melhor as coisas e conduz à inovação.

A partir dessas múltiplas perspectivas, partimos da perspectiva de negócios - razão distribuída (propícia à compreensão do negócio), da perspectiva da computação abstrata - máquina de estado (propiciosa à compreensão da implementação de blockchain + sistemas distribuídos), e da perspectiva de implementação técnica - bloco + estrutura da cadeia (conducente à compreensão da parte blockchain do ecossistema).

1. Três ângulos de visão

No documento do Ethereum “Ethereum EVM Illustrated”, é apresentado que existem três ângulos de visão para a estrutura de blocos do Ethereum (razão distribuída, máquina de estado, blockchain). Esta observação também se aplica ao Bitcoin e é mais adequada para observar a estrutura ecológica do Bitcoin. Na introdução a seguir, entendemos essas três perspectivas e haverá ganhos diferentes.

Do ponto de vista de uma máquina de estado, não só é fácil entender o status e o processamento de status no blockchain, mas também é mais fácil entender o status, os canais de status e as transições de status no sistema distribuído. Ao mesmo tempo, combinado com a estrutura do sistema distribuído, será mais fácil entender o roteamento.O problema é entender os requisitos do grafo acíclico direcionado de transições de estado. As máquinas de estado são baseadas nos princípios de computação abstratos subjacentes da teoria dos grafos. Com base nesses princípios e estruturas de implementação específicas (blockchain, distribuída, centralizada), você compreenderá os problemas específicos que precisam ser resolvidos e as ideias para soluções.

Em segundo lugar, do ponto de vista comercial, entenderemos facilmente por que o blockchain pode lidar com dados confiáveis e por que os dados no blockchain podem ser usados como moeda digital, o que torna o sistema blockchain mais parecido com um livro-razão. Você entenderá por que o sistema distribuído não é um livro-razão e precisa cooperar com o livro-razão. Ao mesmo tempo, você entenderá como o sistema distribuído lida com os dados e o fluxo no livro-razão em cooperação com o livro-razão.

Do ponto de vista da implementação técnica, entenderemos que um sistema como o Blockchain é uma estrutura blockchain, as vantagens e desvantagens dessa estrutura técnica também podem ser facilmente resumidas e resumidas.

Em relação à estrutura do ecossistema Bitcoin, do ponto de vista dos livros e máquinas de estado, podemos entender melhor as vantagens e desvantagens de cada estrutura, e como usar três estruturas alternativas para construir a segunda camada do Bitcoin, mesmo que construamos Web3. 0 Toda a arquitetura da aplicação.

Tive uma sensação ao ler a documentação do Ethereum “Ethereum EVM ilustrado”. Observar coisas que podem ser comparadas ao Ethereum de três ângulos diferentes nos fornece algumas ideias de pensamento e referências de experiência de processamento para resolver o Ethereum. Por exemplo, quando Ethereum é visto como um autômato baseado em estado, as teorias e algoritmos em máquinas de estado no campo da informática podem ser adaptados ao Ethereum. Ao considerar o Ethereum como um banco de dados baseado em razão, algumas teorias do banco de dados podem ser aplicadas ao Ethereum – como a ideia de fragmentação no banco de dados. Esse sentimento também se aplica ao ecossistema Bitcoin, e será misturado e utilizado em três grandes estruturas de sistema, tornando a flexibilidade ainda maior.

1.1. Perspectiva de negócios – razão distribuída

Da perspectiva de um livro-razão, um blockchain é um grupo de transações, assim como as páginas de dados escritas em um livro-razão.

Do ponto de vista dos livros-razão, é mais fácil compreendermos as suas capacidades de negócio e as suas funções monetárias e financeiras. Este também é o papel de um livro-razão na arquitetura geral dos aplicativos Web3.0.

Da perspectiva dos livros, podemos compreender facilmente a construção do segundo nível Da cadeia.As contas de diferentes empresas podem ser registadas EM diferentes livros, e estes sub-livros podem ser resumidos no livro geral.

Do ponto de vista do razão + distribuição, podemos entender que se um participante receber uma moeda digital, como lidar com ela e como dividir as contas, os próprios participantes podem negociar e lidar com ela e, finalmente, registrá-la no razão .

1.2. Perspectiva de computação abstrata – máquina de estado

Aqui nos concentramos em máquinas de estado, porque esta perspectiva pode fornecer uma boa compreensão dos sistemas blockchain e dos sistemas distribuídos. E você pode entender a diferença entre como os dados (ou estado) são processados em um sistema blockchain e como são processados em um sistema distribuído.

Do ponto de vista estatal, o blockchain é uma máquina de estado baseada em transações. Uma transação é uma condição de gatilho que faz com que um estado original σt se transforme no próximo estado σt+ 1 sob a ação da transação.

Um conjunto de transações é empacotado em um blockchain, que é um pacote de dados, fazendo com que o status associado a esse conjunto de dados mude.

Portanto, sob essa perspectiva, o blockchain é uma cadeia de estados (em um sistema distribuído, é um canal de estados). Do ponto de vista estatal, o sistema blockchain pode ser visto como um autômato baseado em estado.

Do ponto de vista do estado, quando observamos o sistema blockchain + distribuído, será mais fácil entender as regras de transmissão e mudança de estado nos dois sistemas. Ambos os sistemas são, na verdade, autômatos baseados em estado.

Quando o blockchain é visto como um autômato baseado em estado, as teorias e algoritmos sobre máquinas de estado na teoria dos grafos no campo da computação podem ser aplicados ao blockchain. Da mesma forma, se a estrutura técnica implementada não for uma estrutura blockchain, mas uma estrutura distribuída, também podemos usar a teoria da máquina de estado. Assim como o gráfico acíclico finito DAG (para evitar flores duplas), canais de estado e vedação única são tecnologias que precisam ser usadas para lidar com estados em sistemas distribuídos.

1.3. Perspectiva de implementação técnica – estrutura bloco + cadeia

Do ponto de vista da implementação técnica, sistemas como Bitcoin e Ethereum são uma blockchain. Os dados dispersos são vinculados pelo bloco de dados e pelo ponteiro hash interno.

Esta é apenas uma estrutura de implementação técnica mantida para operar um sistema como o blockchain. Os dados e cálculos no blockchain adotam uma abordagem global, e somente esta estrutura pode completar a função do livro-razão. Os detalhes de implementação e aplicabilidade desta estrutura precisam ser considerados na interface com sistemas externos.

Podemos compreender facilmente as características desta estrutura de implementação da tecnologia block + chain e também calcular indicadores de desempenho. Por exemplo, o tamanho do bloco da rede Bitcoin é 1 M (o máximo teórico é 4 M após o suporte ao Segregated Witness), e o número de transações que ela suporta pode ser totalmente calculado.

A fórmula de cálculo é: (tamanho do bloco/tamanho médio das transações)/intervalo médio de tempo do bloco. Em circunstâncias normais, cada bloco Bitcoin pode acomodar aproximadamente 2.000 a 3.000 transações, ou 3 a 7 TPS.

1.4. Características básicas do blockchain e características de três estruturas de construção da Camada 2

Consulte as três classificações da construção da segunda camada do Bitcoin: estrutura blockchain, estrutura de sistema distribuído e estrutura de sistema centralizado. Comparando algumas características básicas da construção de primeira e segunda camadas do Bitcoin, podemos ver claramente as diferenças entre elas. Conforme mostrado na tabela abaixo. Posteriormente, compararemos os requisitos de aplicação na Seção 3.2 para nos ajudar a selecionar uma combinação adequada de construção de arquitetura a partir dessas estruturas básicas de sistema.

Através da tabela acima, podemos resumir aproximadamente as características da estrutura blockchain, estrutura do sistema distribuído e estrutura centralizada.

(1) Estrutura Blockchain

O maior benefício da estrutura blockchain é que ela resolve problemas relacionados à confiança e pode registrar o processo de mudança de dados (transição de estado), de modo que os dados e as regras de cálculo se tornem dados confiáveis e cálculos confiáveis. Um desses dados confiáveis são os dados originais básicos (expressos como moeda) e o outro é o conjunto de instruções para processamento de dados (expressos como código e contratos inteligentes).

O maior problema da estrutura blockchain é o baixo desempenho. Há duas razões para isso: primeiro, a estrutura blockchain não pode remover cenários de cálculo parciais e todas as solicitações são processadas de maneira completa. Por exemplo, cálculo parcial e cálculo global, dados locais e dados globais, dados temporários e dados permanentes. Em segundo lugar, a estrutura do blockchain tem um limite superior de desempenho óbvio. Se a expansão da camada 2 for realizada através de uma cadeia, o número de transações suportadas também será muito limitado. Um cálculo simples é o seguinte:

O limite superior de um sistema blockchain é o número máximo de transações que podem ser acomodadas por uma capacidade de bloco único. O limite superior de um blockchain multinível é o produto do número de transações na capacidade de bloco de cada camada. Por exemplo, uma camada de Bitcoin tem 7 TPS por segundo, e uma cadeia de camada 2 tem uma capacidade de processamento de 100 TPS. Então as duas estruturas combinadas são 700 TPS.

Para expandir o desempenho de estruturas contendo blockchain, a construção multicamadas é necessária e deve ser usada em conjunto com sistemas heterogêneos. Para o trabalho que deve ser concluído no sistema blockchain, apenas os dados que precisam ser salvos e calculados globalmente precisam ser registrados.Outros dados não globais podem ser atribuídos a outras camadas para processamento, de modo que os dados e códigos processados sejam apenas relacionados às partes relevantes tanto quanto possível.

A partir da tabela acima, apenas a estrutura blockchain pode realizar a função de livro-razão sem confiança.Portanto, se um sistema quiser realizar a função de livro-razão sem confiança, ele deve incluir um sistema blockchain. No entanto, devido aos requisitos de desempenho de aplicações de grande escala, o sistema blockchain deve ser combinado com outros sistemas para atender às necessidades.

(2) Sistema distribuído

Na tabela acima, podemos ver as vantagens óbvias dos sistemas distribuídos: descentralização, desempenho e escalabilidade são excelentes, mas existem recursos mais complexos na implementação de funções. Além disso, os sistemas distribuídos não têm a capacidade de confiar no livro-razão.

Portanto, se pudermos usar o sistema distribuído na construção de segunda camada com base na função de registro de primeira camada do Bitcoin, podemos teoricamente alcançar uma expansão de desempenho ilimitada, mantendo as características básicas do blockchain. Um caso nesta área é representado pela Bitcoin + Lightning Network. O desempenho desta combinação é de 7 TPS * ∞ do Bitcoin.

A razão para alcançar a completude de Turing em um sistema distribuído é que o custo de registrar e executar contratos inteligentes em um sistema blockchain é muito alto porque se trata de dados globais e código global. Portanto, os contratos inteligentes também são adequados para a teoria em camadas, que limita o armazenamento de código e a execução de contratos inteligentes aos participantes. Este também é o cenário em que a verificação do lado do cliente ocorre em sistemas distribuídos.Apenas dados confiáveis (estado, selo único) entre as partes relevantes são necessários para participar do cálculo, e os cálculos completos de Turing são realizados apenas localmente. Isto é o que muitas vezes se diz sobre o consenso de toda a rede e o consenso dos participantes em sistemas distribuídos.A maior dificuldade na construção da segunda camada com uma estrutura de sistema distribuído é que a implementação técnica é relativamente complexa. Redes como a Lightning Network, que simplesmente resolvem problemas de pagamento, estão se desenvolvendo lentamente e apresentam muitas imperfeições. É ainda mais desafiador implementar a computação Turing-completa em um sistema distribuído. O lento desenvolvimento e as lentas atualizações de versão do RGB são um caso de referência.

O maior custo da resolução da complexidade é a vulnerabilidade a questões de segurança e o elevado limiar para o desenvolvimento. A implementação de funções de contrato inteligente completas de Turing em um sistema distribuído não requer apenas um ciclo de desenvolvimento longo e difícil para a plataforma subjacente, mas também muitas vezes leva a vulnerabilidades de código de contrato e ataques contínuos de hackers.

(3) Sistema centralizado

Na tabela acima, podemos ver que o benefício do sistema centralizado é que a implementação da engenharia é relativamente simples, devido ao controle lógico interno simples e ao cálculo simples. Da mesma forma, os sistemas centralizados não têm a capacidade de confiar nos livros-razão. As vantagens de um sistema centralizado não são excelentes: se você estiver processando dados em pequena escala ou processando dados temporários e cálculos temporários, será relativamente adequado.

A construção do segundo andar do sistema centralizado pode ser utilizada como solução complementar ou transitória aos outros dois métodos.

(4) Análise abrangente

Na era do valor, através do conteúdo acima, podemos ver que é difícil alcançar o efeito de satisfazer as necessidades confiando apenas num sistema. Esta é também uma necessidade prática para a segunda camada do desenvolvimento ecológico do Bitcoin. Mas como combinar esses três sistemas requer muita exploração. Vamos analisá-lo primeiro teoricamente. Diante de diferentes necessidades, haverá diferentes estruturas de combinação.

Em primeiro lugar, do ponto de vista do conceito de design de camadas de protocolo, a rede Bitcoin não requer integridade de Turing, é uma máquina de confiança global e só precisa salvar os dados e alterações de dados que exigem confiança global. Com base neste requisito mais básico, o conjunto de instruções do Bitcoin pode ser reduzido ao mínimo. Outras funções são deixadas para as extensões da camada superior serem concluídas. Além de atender aos requisitos funcionais desta camada, a tecnologia de conexão entre a primeira camada do Bitcoin e a rede da camada superior também precisa ser desenvolvida e melhorada.Além disso, esta tecnologia de conexão, na premissa de atender às funções, ocupa o mínimo possível de espaço de dados do Bitcoin.

Geralmente, pequenas aplicações só precisam ser concluídas em uma única blockchain. Sistemas um pouco maiores são adequados para conclusão da construção de segunda camada de blockchain + blockchain. Mas para aplicações em larga escala, a solução preferida é usar um sistema blockchain + sistema distribuído. Do ponto de vista do desempenho, o limite superior do sistema distribuído é teoricamente ilimitado, então tal combinação é o 7 TPS * ∞ do Bitcoin. A implementação de engenharia também será limitada por alguns fatores específicos.Normalmente, o limite superior de tal sistema é limitado pelas capacidades de roteamento do sistema distribuído, pelas capacidades de processamento de gráficos acíclicos direcionados de mudanças de estado e outros links de implementação técnica específicos. Mais tarde, na arquitetura típica do aplicativo Web3.0, você também pode ver o diagrama de combinação de vários sistemas.

Através da combinação de múltiplas estruturas de sistemas, as limitações da teoria básica de um único sistema podem ser quebradas. Por exemplo, o sistema blockchain é limitado pelas limitações do triângulo impossível DSS, mas se um sistema blockchain + sistema distribuído for usado, o triângulo impossível de descentralização D, segurança S e escalabilidade S pode ser resolvido. Outras combinações, blockchain + sistema centralizado, também podem resolver o problema de escalabilidade até certo ponto. Sistema distribuído + sistema centralizado podem resolver as limitações do triângulo CAP em sistemas distribuídos.

Na história do desenvolvimento tecnológico do passado também ocorreram alguns casos de uso combinado. Por exemplo, quando o banco de dados centralizado tem capacidades limitadas, ele adota uma estrutura mestre-escravo, depois passa para subbancos de dados e subtabelas, para bancos de dados distribuídos, que são exemplos de uso de sistemas centralizados e sistemas distribuídos.

Esta combinação também incorpora uma ideia filosófica: **A solução para um problema não pode obter a resposta ao nível onde o problema surge, mas pode resolvê-lo a um nível superior. **Não é particularmente fácil entender esta frase com clareza. Penso em uma metáfora particularmente boa em “Zen e a arte da manutenção de motocicletas”: Não podemos nos levantar pelos cabelos. Isto diz-nos que não podemos confiar no próprio sistema para resolver os nossos próprios problemas, mas devemos utilizar sistemas externos para os resolver.

2. Revisite o design e desenvolvimento da segunda camada do Bitcoin da perspectiva de uma máquina de estado

Estados e máquinas de estado existem nos três prédios de dois andares, mas os nomes são um pouco diferentes, o que faz com que a maioria das pessoas não preste atenção a esse ângulo de observação.

Se olharmos da perspectiva dos estados e das máquinas de estado, as três estruturas de duas camadas são todas máquinas de estado que processam estados, mas os princípios são ligeiramente diferentes. Quando estes três sistemas são utilizados em combinação, é necessário garantir que o conceito de “estado” seja consistente nos três sistemas, e que a máquina de estado de cada sistema possa lidar com mudanças de estado, mas não possa destruir a consistência do estado.

Do ponto de vista da máquina de estado, a arquitetura de aplicação do ecossistema Bitcoin ou Web3.0 utiliza essas combinações de sistemas para completar o processamento das transformações de estado, completando assim o processamento da lógica de negócios.

Usando a ideia de máquinas de estado, olhamos para a construção da rede de duas camadas do Bitcoin e podemos ver que cada camada da arquitetura possui uma divisão de trabalho adequada às suas características.

2.1. Conhecimento básico de estados e máquinas de estados na teoria dos grafos

Na teoria dos grafos, o conhecimento básico de estados e máquinas de estados inclui o seguinte:

Estado: Estado refere-se a um nó ou vértice na teoria dos grafos. Em um grafo direcionado, o estado pode ser representado como um nó; em um grafo não direcionado, o estado pode ser representado como um vértice.

Transição de Estado: A transição de estado refere-se ao processo de um estado para outro. Em um grafo direcionado, a transição de estado pode ser representada como uma aresta direcionada; em um grafo não direcionado, a transição de estado pode ser representada como uma aresta não direcionada.

Máquina de estados: uma máquina de estados é um modelo de computação abstrato usado para descrever uma série de estados e regras de transição entre estados. A máquina de estados consiste em um conjunto de estados, um estado inicial, uma função de transição e um estado de terminação.

Gráfico direcionado: um gráfico direcionado é uma estrutura de gráfico composta de vértices e arestas direcionadas. As arestas direcionadas apontam de um vértice para outro vértice, representando a relação de transição entre estados.

Gráfico não direcionado: um gráfico não direcionado é uma estrutura de gráfico composta de vértices e arestas não direcionadas. As arestas não direcionadas conectam dois vértices e representam a associação entre estados.

Classificação topológica: a classificação topológica refere-se à classificação linear dos vértices de um gráfico acíclico direcionado (DAG), de modo que, para quaisquer dois vértices uev, se houver uma aresta (u, v), então u aparece antes de v na classificação.

Gráfico Acíclico Direcionado (DAG): Um gráfico acíclico direcionado é um gráfico direcionado no qual não há ciclo que começa em um vértice e retorna ao vértice após passar por várias arestas.

Caminho Mais Curto: O caminho mais curto refere-se ao caminho com a menor soma dos pesos das arestas entre os caminhos que conectam dois vértices no gráfico.

Árvore de abrangência mínima: A árvore de abrangência mínima refere-se a encontrar uma árvore contendo todos os vértices em um gráfico conectado, de modo que a soma dos pesos das arestas da árvore seja mínima.

Esses conhecimentos básicos são conceitos centrais na teoria dos grafos e são usados para descrever e analisar as relações e regras de transição entre estados. Conhecimentos e gráficos relevantes podem ser aprendidos em profundidade em livros profissionais.

Embora esse conhecimento pareça um pouco abstrato e enfadonho, é fácil de entender se convertermos esse conhecimento em alguns conceitos de blockchain que encontramos com frequência. Por exemplo, alguns cenários exigem gráficos acíclicos direcionados para evitar o problema de gastos duplos; o encapsulamento único serve para transformar o estado no blockchain no estado do sistema distribuído; o algoritmo de roteamento serve para encontrar o caminho mais curto no sistema distribuído Cálculo: a rota com menor custo de pagamento na Lightning Network é o problema da árvore geradora mínima; a verificação do cliente também pode ser considerada uma forma de máquina de estado.

2.2. Máquina de estado e sistema distribuído

Aqui usamos várias redes distribuídas para apresentar:

(1) Na Rede Lightning

Na Lightning Network, os pontos de conhecimento relacionados a estados e máquinas de estado são:

A Lightning Network é uma solução de segunda camada para Bitcoin baseada na tecnologia de canal estatal. O canal de pagamento na Lightning Network é um canal estatal bidirecional. Os participantes podem realizar múltiplas transações no canal e atualizar o status do canal para obter resultados rápidos e baixos. -transações de custos.Pagamento de custos.

As transações (ou seja, estados) na Lightning Network são implementadas por meio de contratos time-locked baseados em Hash (HTLC), por meio dos quais os participantes podem bloquear fundos (o estado é transferido entre os sistemas Bitcoin e Lightning Network) e realizar transações seguras dentro dos canais (manipulação de estado simples).

Roteamento na Lightning Network: Para permitir pagamentos entre canais, a Lightning Network usa um mecanismo chamado roteamento, onde os participantes podem fazer pagamentos encontrando um caminho confiável.

Nós de retransmissão na Lightning Network: nós de retransmissão são nós que podem encaminhar solicitações de pagamento e podem ajudar a realizar pagamentos entre canais.

Pagamento bidirecional na Lightning Network: A Lightning Network permite que os participantes façam pagamentos bidirecionais no canal de pagamento, ou seja, podem não apenas pagar à outra parte, mas também aceitar o pagamento da outra parte.

Privacidade de pagamento da Lightning Network: Como as transações na Lightning Network são realizadas dentro do canal, todas as transações não precisam ser gravadas no blockchain, para que a privacidade dos pagamentos possa ser melhorada.

Limitações da Lightning Network (principalmente limitações da tecnologia de implementação de máquinas de estado e de estado): A Lightning Network também tem algumas limitações, como capacidade de sobrevivência do canal, tempo de bloqueio de fundos, etc.

(2) No RGB, os pontos de conhecimento relacionados ao estado, máquina de estado e canal de estado são:

RGB é baseado nos protocolos LNP e BP. Há uma discussão sobre se RGB é a segunda ou terceira camada. Se o RGB for calculado diretamente com base no BP, ele estende diretamente a função completa de Turing do Bitcoin e pertence à segunda camada. Este método tem expansão limitada de desempenho. Se o cálculo RGB for baseado em LNP, ele pertence à terceira camada (porque LNP é a segunda camada do Bitcoin). Este método pode expandir tanto o desempenho quanto o poder de computação Turing-completo, mas há uma certa complexidade na implementação técnica. Gastar . Normalmente, o método combinado pode não apenas expandir o poder de computação, mas também expandir o desempenho e reduzir a complexidade da implementação.

RGB é baseado na tecnologia de canal estatal em Bitcoin ou na Lightning Network. O canal de status em RGB refere-se ao canal de comunicação entre duas ou mais partes construído em LNP e BP.Múltiplas transações e atualizações de status podem ser realizadas dentro do canal, reduzindo o número de transações e taxas no blockchain.

Os canais estaduais em RGB usam scripts de múltiplas assinaturas baseados em Bitcoin para bloquear fundos e usam tipos de transação especiais para atualizar o estado do canal.

O canal estadual no RGB pode ser aplicado a diversos cenários, como canais de pagamento, exchanges descentralizadas, emissão de ativos, etc., melhorando a eficiência das transações e a experiência do usuário.

O canal de estado no RGB realiza pagamentos e transferências de ativos atualizando o status do canal. As transações no canal não precisam ser gravadas no blockchain, apenas o estado final será gravado no blockchain.

O canal de estado no RGB também pode implementar funções mais complexas, como atomic swaps, roteamento de pagamentos, etc., por meio de contratos inteligentes e scripts de múltiplas assinaturas.

Os canais de estado em RGB podem ser combinados com outras tecnologias e protocolos, como Lightning Network, LNURL, etc., para fornecer funcionalidades mais ricas e melhor experiência do usuário.

O projeto e implementação de canais estaduais em RGB precisam considerar fatores como segurança, privacidade, escalabilidade, etc. para garantir a confiabilidade e disponibilidade do sistema.

(3) Em Nostr, conceitos relacionados a estados, máquinas de estado e canais de estado.

No Nostr, como a informação é transmitida, os conceitos de estado (dados confiáveis, moeda digital) e máquina de estado ainda não foram refletidos. Porém, acredito que se a estrutura distribuída do Nostr for ligeiramente modificada e o processamento de status for aumentado, será formado um sistema semelhante à Lightning Network, que pode transmitir informações e agregar valor. A possibilidade de transformar gradualmente este sistema distribuído baseado em informação num sistema distribuído que inclua processamento de valor também é descrita no diagrama de arquitetura de aplicação da Web3.0 na Seção 3.3.

Uma breve introdução ao Nostr atual: Existem dois componentes principais no Nostr, o cliente e o relé. Cada usuário executa um cliente e se comunica com outros através de retransmissões. Cada usuário é identificado por uma chave pública. Cada postagem que um usuário faz é assinada. Cada cliente verifica essas assinaturas. Os clientes obtêm e publicam dados no retransmissor de sua escolha. Os relés não se comunicam entre si, apenas diretamente com os usuários.

(4) Em sistemas distribuídos, os pontos de conhecimento relacionados com máquinas de estado incluem:

Modelo de máquina de estado: Uma máquina de estado é um modelo matemático que descreve as transições e o comportamento de um sistema entre diferentes estados. Em sistemas distribuídos, modelos de máquinas de estado são frequentemente usados para descrever o comportamento e as mudanças de estado do sistema.

Máquina de estados finitos (FSM): A máquina de estados finitos é o modelo de máquina de estados mais básico, que contém um conjunto finito de estados e um conjunto de regras de transição entre estados. Em sistemas distribuídos, máquinas de estados finitos podem descrever vários estados do sistema e transições entre estados.

Transição de estado: A transição de estado refere-se ao processo de mudança do sistema de um estado para outro. Num sistema distribuído, as transições de estado podem ser desencadeadas por vários eventos ou condições, tais como recepção de mensagens, tempo limite, etc.

Comportamento da máquina de estado: a máquina de estado pode definir diferentes comportamentos em diferentes estados. Em um sistema distribuído, o comportamento de uma máquina de estados pode incluir processamento de mensagens, execução de operações, envio de mensagens, etc.

Consistência de estado: Em um sistema distribuído, vários nós podem ter estados diferentes. A consistência de estado refere-se a manter os estados de vários nós do sistema coordenados e consistentes entre si.

Máquina de estado distribuída (DSM): Máquina de estado distribuída refere-se a uma tecnologia que aplica modelos de máquina de estado a sistemas distribuídos. Ele pode distribuir o estado do sistema e as transições de estado entre vários nós e garantir a consistência do estado entre os nós.

Máquina de estado atômico (ASM): Uma máquina de estado atômico refere-se a uma máquina de estado que mantém a atomicidade durante as transições de estado. Em sistemas distribuídos, as máquinas de estado atômico podem garantir a consistência e a confiabilidade do sistema durante as transições de estado.

Protocolo de consistência: Um protocolo de consistência é um protocolo usado para garantir consistência de estado em um sistema distribuído. Protocolos de consenso comuns incluem Paxos, Raft, ZAB, etc.

Tolerância a falhas: As máquinas de estado distribuído precisam ser tolerantes a falhas, ou seja, o sistema ainda pode manter o estado e o comportamento corretos em caso de falha do nó ou perda de mensagem.

Escalabilidade: As máquinas de estado distribuídas precisam ser escaláveis, ou seja, devem ser capazes de manter transições de estado eficientes e consistência à medida que a escala do sistema aumenta.

2.3. Máquina de estado e sistema blockchain

De acordo com o documento do Ethereum “Ethereum EVM ilustrado”, cada bloco é um conjunto de estados de gatilho, e todo o sistema Ethereum é um processador de estado. Na versão 1.2, introduzimos o conteúdo da máquina de estado no sistema blockchain. Há também muitas descrições de máquinas de estado no white paper da Ethereum.

Embora a máquina de estado tenha fortes capacidades de processamento, seu limite superior é o teto da estrutura do blockchain.

Para a aplicação combinada de interconexão blockchain baseada no modelo UTXO e no modelo de conta (como EVM), os métodos de implementação do estado e da máquina de estado são bastante diferentes. Blockchains baseados no modelo UTXO são mais fáceis de combinar com sistemas distribuídos porque os estados em ambos os sistemas são baseados em UTXO, e não há conversão ou apenas conversão simples, que é mais fácil de implementar. A cadeia baseada no modelo de conta requer encapsulamento e conversão adicionais entre seu estado e o estado do sistema distribuído externo, que é complexo de implementar.Isso também é parte da razão pela qual o desenvolvimento da Rede Raiden no Ethereum não é tranquilo.

2.4. Máquina de estado e sistema centralizado

Exemplos de uso de sistemas blockchain + centralizados incluem Ordinals e exchange centralizada CEX.

Esses sistemas são relativamente simples e alguns não têm nenhuma transferência de estado, como os ordinais, que usam apenas índices centralizados para completar o trabalho estatístico.

Como uma troca centralizada, a transferência de estado nela depende completamente das regras estabelecidas pelo sistema centralizado.A máquina de estado interna também é um processador de estado composto por programas de sistema centralizado, e não existem conceitos complicados.

Em futuras aplicações Web3.0, deverá haver mais casos de uso de blockchain + sistemas centralizados.

3. Qual deve ser a estrutura de um aplicativo Web3?

Através do conteúdo anterior do artigo, sabemos que através da combinação de três arquiteturas Bitcoin de duas camadas, projetos estruturais mais complexos podem ser concluídos para obter os requisitos de recursos necessários. E do ponto de vista comercial, se a lógica subjacente do aplicativo puder ser decomposta em estados e máquinas de estado, uma combinação dos três sistemas poderá ser usada para completar toda a lógica de negócios da camada superior.

Então, quais são essas combinações comuns? Que fatores determinarão a estrutura do portfólio? Especulamos sobre a estrutura de aplicativos de grande escala que atendem à Web3.0 com base em classificações e requisitos de aplicativos comuns.

3.1. Classificação de aplicações comuns

Usamos como referência as estatísticas de aplicação do 48º “Relatório Estatístico sobre o Desenvolvimento da Internet na China”, doravante denominado relatório estatístico. Como o Web2.0 amadureceu e não afeta a análise da classificação do aplicativo e dos resultados da escala do usuário, os dados de referência do aplicativo que usamos são dados antigos de 2020 e 2021. Uma coisa a notar é que estas são apenas estatísticas da Internet da China. No estágio Web3.0, muitos aplicativos são globais e os usuários têm requisitos de maior escala e desempenho.

No relatório estatístico, podemos ver que as aplicações da Web2.0 já são muito ricas e possuem um enorme grupo de usuários. Esses aplicativos incluem: mensagens instantâneas, vídeo on-line, vídeo curto, pagamento on-line, compras on-line, mecanismo de pesquisa, notícias on-line, música on-line, transmissão on-line ao vivo, jogos on-line, entrega on-line, literatura on-line, carona on-line, escritório on-line e reserva de viagens on-line., educação on-line, assistência médica on-line,… cobrindo quase todas as áreas da vida das pessoas. Além desses conteúdos da Internet para o consumidor, também existem muitas aplicações na Internet industrial.

Se todos os aplicativos Web2.0 forem migrados para Web3.0, a maioria deles terá requisitos de desempenho muito elevados. Tomando o pagamento Visa como exemplo, o requisito de desempenho máximo é: 65.000 TPS. Esses indicadores de desempenho só podem ser suportados por sistemas distribuídos. Por exemplo, o desempenho atual da Lightning Network é de 40 milhões de transações por segundo, e o desempenho do Lightning Network A rede não é teoricamente suficiente. limite superior.

Além disso, tomamos como exemplo os jogos comuns. Atualmente, o jogo full-chain com o maior TPS no blockchain pode atingir um pico de cerca de alguns milhares de TPS, o que é uma grande lacuna em relação aos jogos tradicionais Web2 3A com centenas de milhares. do TPS. Se você deseja migrar todos os jogos para Web3.0, o desempenho da infraestrutura necessária será um grande desafio.

Além do mais, os jogos são apenas um aplicativo em categorias de aplicativos comuns e outros aplicativos têm mais desempenho e requisitos específicos.

3.2. Requisitos para aplicativos Web3.0

Para compreender as necessidades da aplicação, será mais direto utilizar a estrutura de receitas como indicador. Referimo-nos ao relatório “Token Terminal, com curadoria de FutureMoney Research 2022 Q2”. Embora este relatório seja anterior, pagamentos e outras aplicações estão em estágio inicial e não afetarão os principais resultados da análise. Portanto, o autor foi preguiçoso aqui e usou os dados quando eu estava escrevendo livros sobre Web3.0. Se houver dados do quarto trimestre de 2023, serão mais precisos.

(1) Análise de necessidades por meio de relatórios de renda

A classificação de receita no relatório representa melhor a atual composição principal do produto Web3.0. como mostra a imagem.

1. A receita da Camada 1 (a cadeia principal básica do blockchain) é de 48%, representando quase metade da receita total. Seu modelo de negócios pode ser entendido como “venda de espaço em bloco”;

2. A receita da plataforma de negociação NFT representa 22%, e seu modelo de negócio pode ser entendido como royalties ou atividades de marketing;

3. A receita de DeX em DeFi representa 15%, e seu modelo de negócios consiste em taxas de transação e receita de criação de mercado de liquidez;

4. O staking de rendimentos no DeFi representa 8%, e seu modelo de negócio é o spread de comissões ou juros da gestão de ativos;

5. A Gamefi responde por 5%, e seu modelo de negócios são royalties, taxas de transferência, vendas NFT, etc.;

6. A receita de empréstimos no DeFi representa cerca de 1%, e seu modelo de negócio é o spread de juros;

7. A receita da Tooling representa cerca de 1%, e seu modelo de negócio são taxas de serviço, que também incluirão taxas de monetização de tráfego no futuro;

Outras indústrias relacionadas à Web3.0 não são aplicações Web3.0 e não são contadas como indústrias principais da Web3.0 e não serão incluídas. Por exemplo: mídia Web3.0, organizações de pesquisa, organizações de treinamento, etc.

A partir da estrutura de receitas, podemos ver que as atuais necessidades de aplicação do ecossistema BTC podem ser basicamente resolvidas pelo blockchain e seu sistema de segunda camada, sem a necessidade de uma arquitetura de sistema complexa. No entanto, Gamefi e SocialFi estão se desenvolvendo de forma relativamente rápida.Usando exemplos de jogos na literatura de referência, podemos ver que jogos de grande escala já possuem requisitos mais elevados e claros para a estrutura do sistema.

A partir da estrutura de renda, podemos ver as necessidades de aplicação do atual ecossistema BTC, vale a pena refazer todos os produtos no Ethereum e em outros ecossistemas. Transformar ligeiramente a tecnologia de construção de segunda camada baseada em cadeia no ecossistema Ethereum e estabelecer uma nova segunda camada no Bitcoin pode atender melhor a essas necessidades primárias, mas apenas no grau de descentralização, segurança, privacidade e resistência à censura. Um certo compromisso foi feito. Em “Um artigo que resume o sistema de conhecimento básico da construção da segunda camada (camada 2) do Bitcoin”, todas essas novas construções de segunda camada baseadas no tipo EVM são casos dessa situação.

(2) Análise de casos de jogos de uso de aplicativos com requisitos de alto desempenho

No artigo “O Impossível se Torna Possível: Tornando o Desenvolvimento de Jogos Full-Chain uma Realidade na Lightning Network”, há uma demanda maior por funcionalidade e desempenho. A verdadeira arquitetura das aplicações Web3.0 está emergindo gradualmente.

Descrição do problema no artigo: Com base na garantia de segurança, privacidade e descentralização, os jogos full-chain nunca encontraram a solução ideal para escalabilidade. Por exemplo, os motores de jogo full-chain mais populares, Mud e Dojo, estão empenhados em ajudar os jogos full-chain a atingir TPS mais elevados, mas os jogadores ainda precisam de mais de 2 segundos de buffer para cada operação. Na verdade, o atual jogo full-chain com o TPS mais alto no blockchain pode atingir um pico de cerca de alguns milhares de TPS, o que é uma grande lacuna em relação aos jogos Web2 3A tradicionais com centenas de milhares de TPS. Ao perseguir a premissa de não perder as vantagens do blockchain, os jogos full-chain podem superar a escalabilidade.

Na solução discutida posteriormente na discussão técnica, Lightning Network e RGB são usados para expandir o desempenho, e também são propostos os conceitos de cadeias temporárias e cadeias dedicadas.

Cadeia efêmera

Blockchains efêmeros podem ser definidos como blockchains que não duram para sempre e são destruídos quando o propósito do blockchain é cumprido (como registrar transações) ou quando seu estado é armazenado permanentemente em outro lugar. O status de encerramento armazenado por uma cadeia temporária são simplesmente dados sobre os fatos de encerramento associados à cadeia temporária, comprimindo tudo em uma ordem de grandeza considerável. As cadeias temporárias são limitadas principalmente pela latência da transação e pela taxa de transferência no blockchain.

Canal de estado VS de cadeia temporária

No que diz respeito às cadeias temporárias, acabaremos com um grande número de utilizadores devido ao estado da cadeia pública. O estado que precisa ser inserido na cadeia pública será reduzido em tamanho através de poda/compressão/extração de diferenças, e então salvo na cadeia pública regularmente em vez de irregularmente. A configuração do canal de status RGB pode contornar as restrições de desempenho da cadeia temporária e atingir a mesma função que a cadeia temporária.

Blockchains específicos do aplicativo

Blockchains específicos de aplicativos são blockchains criados para executar um único aplicativo descentralizado (dapp). Em vez de construir sobre um blockchain existente, os desenvolvedores constroem um novo blockchain do zero usando uma máquina virtual (VM) personalizada que executa transações para que os usuários interajam com o aplicativo. Os desenvolvedores também podem personalizar diferentes elementos da pilha de rede blockchain – consenso, rede e execução – para atender a requisitos específicos de design. Melhorar a velocidade de execução de contratos inteligentes e resolver restrições de recursos computacionais pode ajudar na implementação do blockchain para aplicações específicas. Permitir que os desenvolvedores personalizem a infraestrutura para diferentes casos de uso facilita o desenvolvimento. Ao mesmo tempo, permite que os desenvolvedores web3 construam modelos de valor poderosos e ampliem seus dapps para atender às necessidades de crescimento exponencial e inspirar mais inovação.

Através do caso deste jogo, juntamente com a nossa análise anterior de diversas arquiteturas, podemos julgar aproximadamente a arquitetura de futuras aplicações de grande escala.

3.3 Como deve ser a arquitetura que atende às aplicações de grande escala da Web3.0?

No conteúdo anterior, aprendemos sobre as categorias de aplicativos comuns na Web 2.0. Todos esses aplicativos foram atualizados para Web3.0, o que é um sinal de entrada total na era Web3.0. Que tipo de arquitetura pode satisfazer as muitas aplicações acima?

(1) Diferenças arquitetônicas simples entre Web2.0 e Web3.0

Aqui está o conteúdo do artigo “A arquitetura de uma aplicação Web 3.0” escrito pela deusa do blockchain Preethi Kasireddy. . A descrição estrutural dos aplicativos Web3.0 aqui é uma estrutura muito simples que depende apenas do sistema blockchain. No entanto, esta estrutura é demasiado simples, não reflecte a construção da segunda camada e não é competente em aplicações de grande escala.

Ao comparar os casos de implementação técnica de produtos centralizados tradicionais e os de produtos Web3.0, será mais fácil compreender as diferenças na implementação técnica. Combinado com a descrição de Gavin Wood da visão da pilha de tecnologia da Web3.0, podemos ver que a maior diferença na implementação técnica da Web3.0 está em segundo plano, e a diferença na camada de experiência do usuário é relativamente pequena.

(2) Arquitetura de sistema para aplicações de grande escala na era Web3.0

Na era sem blockchain, os aplicativos eram construídos em sistemas centralizados e sistemas distribuídos. Por exemplo, aplicativos como shopping centers, mensagens instantâneas e vídeos são criados em sistemas centralizados, e os downloads do Thunder são criados em sistemas distribuídos.

Com o sistema blockchain, entramos na era Web 3.0. As aplicações neste período são uma arquitetura complexa construída no sistema blockchain, sistema distribuído e sistema centralizado. Entre eles, o sistema blockchain e sua extensão de segunda camada completam a transmissão e processamento de valor, e o sistema distribuído e o sistema centralizado completam a transmissão e processamento de informações.

Como mostrado abaixo,

O conteúdo específico é descrito a seguir:

(1) A rede principal do Bitcoin e a construção da segunda camada são o centro de todo o valor, e a maior parte do valor é construída nesta rede. Na construção de segunda camada do Bitcoin, a segunda camada baseada em cadeia completa a expansão do desempenho e o processamento de valor e processa todos os dados contábeis. Na construção de segunda camada do Bitcoin, a construção de segunda camada baseada no sistema distribuído completa a expansão do desempenho.Ele processa dados locais relevantes e usa o consenso das partes relevantes, mas os resultados finais do cálculo precisam ser implementados no blockchain sistema. Na construção de segunda camada do Bitcoin, a construção de segunda camada baseada no sistema centralizado fornece serviços diretamente para aplicações de camada superior.

(2) O sistema semelhante ao RGB também exigirá algumas cadeias temporárias ou cadeias intermediárias para completar a função de liquidação do razão, conforme mostrado pela linha azul na figura. O caso do jogo na Referência 1 descreve esse cenário. Não apareceu em grande escala porque a construção de sistemas do tipo RGB é complicada e ainda não atingiu a maturidade.

(3) Além do ecossistema Bitcoin, existem também outros ecossistemas de sistemas blockchain para atender às necessidades de diferentes cenários de negócios. Conforme descrevemos no artigo sobre infraestrutura de segunda camada, haverá muitos projetos de segunda camada baseados na cadeia, e o mesmo se aplica às cadeias no ecossistema não-Bitcoin. Outros sistemas blockchain e segundas camadas também podem entrar na Lightning Network e RGB, e isso ocorrerá gradualmente à medida que a tecnologia amadurecer.

(4) No ecossistema Web3.0, os sistemas centralizados também terão um lugar, mas a proporção já não será tão grande como na Web2.0. Os sistemas centralizados têm muitas vantagens.

(5) Em aplicações reais, a fiação interna na figura acima se tornará mais complicada.Alguns não precisam usar a segunda camada, mas operam diretamente a rede da primeira camada, como quando RGB usa o protocolo BP. Outros blockchains também podem usar sistemas distribuídos, como a Raiden Network no Ethereum, embora imaturo, se houver cenários de demanda, haverá cenários de uso através da transformação de alguns recursos básicos. A figura acima é uma descrição simplificada da arquitetura do aplicativo Web3.0.

3.4. Caminhos de construção viáveis

A partir da estrutura de receitas, podemos ver as necessidades atuais de aplicativos do ecossistema BTC e, a partir da classificação dos aplicativos comumente usados, podemos ver as necessidades futuras para entrar totalmente na Web3.0. Será um longo caminho. Portanto, coisas com um período de construção relativamente longo precisam ser tratadas em etapas.

Os três estágios aqui são muito semelhantes ao curto, médio e longo prazo mencionados pelo Professor Dashan. Ele apenas resume o estágio simples da construção da segunda camada baseada em cadeia no primeiro estágio da construção.

(1) A primeira fase é o estágio inicial da construção de duas camadas baseada em inscrições e correntes

A construção de duas camadas baseada em inscrição e em cadeia é relativamente fácil e atualmente tem muitas aplicações. Quer se trate de brc 20, src 20, arc 20, inscrição e outras aplicações, ou aquelas partes de projetos de construção de segunda camada baseadas em cadeia, todas elas são abundantes.

A construção nesta fase é relativamente simples, a maioria são aplicações financeiras, e com o apoio da experiência na transformação e imitação da segunda camada do Ethereum, é mais fácil e rápido. Embora relativamente simples, este processo é essencial e importante: eles ajudaram a prosperar a ecologia, atraíram tráfego e fundos, testaram a tecnologia de conexão entre cadeias, testaram stablecoins e testaram várias possibilidades. Esta etapa consiste principalmente na realização de diversas verificações de viabilidade funcional.

(2) A segunda fase são as fases intermédia e final da construção de segundo nível baseada em cadeia e da construção de segundo nível baseada em sistema distribuído.

Nesta fase, também está envolvida a construção de segunda camada baseada em cadeia, que é um estágio avançado da construção baseada em cadeia.Além disso, a segunda fase se concentra em testar e melhorar uma variedade de construções distribuídas de segunda camada. A Lightning Network se tornará mais madura, suas funções e estabilidade RGB serão bastante melhoradas e seus cenários de aplicação serão mais ricos. Concorrentes do tipo RGB surgirão e amadurecerão gradualmente, como o BitVM. Ao mesmo tempo, sistemas distribuídos como o Nostr também incorporarão funções de valor. Esta etapa visa principalmente concluir diversas verificações de viabilidade funcional e de desempenho.

(3) Construção em larga escala baseada na ecologia Bitcoin

A última etapa é a fase de maturidade, nesta fase a Web3.0 começa a ser construída em grandes quantidades e amadurece gradativamente. Os aplicativos comuns descritos em 3.1 começaram a entrar na era Web3.0.

Talvez esse estágio demore mais para chegar, talvez haja um evento de ponto de inflexão que possa promover a entrada de um grande número de aplicações Web2.0, e o tempo pode não ser tão longo.

Não importa o que aconteça, quando a verdadeira era da Web3.0 chegar, ela será definitivamente muito diferente: as funções e o valor da produção serão maiores e mais brilhantes do que a atual Internet para PC + Internet móvel como um todo. Talvez seja como o surgimento de Sora no campo da IA, o que é surpreendente e chocante, mas o processo não é tão repentino.

Descrição de referência

(1) Consulte os artigos e o conteúdo do curso do Sr. Dashan sobre os aspectos de curto, médio e longo prazo da ecologia do Bitcoin.

(2) “O Impossível Torna-se Possível: Tornando o Desenvolvimento de Jogos Full-Chain uma Realidade na Lightning Network” (A inspiração e verificação deste artigo são ainda maiores)

(3) Os três ângulos de observação referem-se principalmente a “Ethereum EVM ilustrado”, Takenobu T., 2018.3

(4) Para conteúdo relacionado à classificação de aplicativos, consulte principalmente “Web3.0: Construindo o Futuro Digital do Metaverso” escrito pelo autor em 2022.

(5) Consulte o conhecimento da teoria dos grafos em lógica digital universitária.

(6) É feita referência a alguns artigos sobre sistemas distribuídos.