Revelando o protótipo da próxima geração da Internet Permaweb: a arquitetura descentralizada de microsserviços sob a teoria SCP

Autor: Outprog @ Colaborador do PermaDAO

Revisor: Xiaosong HU @ Colaborador de PermaDAO

Permaweb é a arquitetura de Internet de última geração proposta pela Arweave Ecology. O que Permaweb enfatiza é que aplicativos e sites estão permanentemente acessíveis. Ele permite que a Internet tenha memórias e nunca as esqueça. Ao mesmo tempo, o Permaweb possui o recurso Severless. Os desenvolvedores não precisam implantar front-end e back-end durante o processo de construção. Todos os serviços desenvolvidos serão fornecidos pela camada de serviço básico do Permaweb.

Para saber mais sobre o conceito e a visão do Permaweb, você pode ler “Arweave’s Potential Is to Revive the Alexandria Library, Not a Filecoin Substitute”, escrito pelo professor Liu Yi para aprender mais sobre o conceito do Permaweb.

Este artigo irá interpretar o Permaweb de uma perspectiva técnica combinada com a teoria do SCP.

Estrutura básica

Permaweb usa uma arquitetura de três camadas, a camada superior é a camada de aplicativo, que é a interface orientada ao usuário. A camada do meio é a camada de serviço, que fornece serviços de back-end para o aplicativo. A camada inferior é a camada de armazenamento, que usa Arweave para fornecer serviços de armazenamento de dados para aplicativos.

A arquitetura do Permaweb não é muito diferente da arquitetura Web2. A camada de aplicação corresponde ao front-end Web2 tradicional, a camada de serviço corresponde ao back-end e a camada de armazenamento corresponde ao servidor físico ou banco de dados.

Usar armazenamento descentralizado é a maior diferença entre Permaweb e Web2. Depois que o aplicativo Permaweb integrar o armazenamento permanente Arweave, será muito difícil adulterar e apagar o conteúdo do aplicativo, e o aplicativo obterá a propriedade de descentralização. Embora a arquitetura da Permaweb tenha semelhanças superficiais com a Web2, sua tecnologia subjacente e filosofia de design fazem diferenças fundamentais.

A arquitetura do aplicativo Permaweb é mostrada na figura abaixo

Imagem de Livro de receitas Permaweb

A seguir apresentaremos a arquitetura de três camadas do Permaweb em detalhes

camada de armazenamento

A camada de armazenamento é o núcleo do Permaweb. Se a camada de armazenamento não usar a tecnologia blockchain, não haverá diferença entre Permaweb e Web2. A camada de armazenamento do Permaweb não está necessariamente limitada ao Arweave. Em teoria, também é possível usar Bitcoin ou Ethereum como camada de armazenamento para construir um Permaweb completo, mas é difícil para desenvolvedores e usuários arcar com custos excessivos de armazenamento. Arweave é atualmente o blockchain mais profissional para armazenamento permanente e custa apenas $ 5 por 1 GB, que é a melhor escolha para Permaweb.

Então a camada de armazenamento pode usar IPFS? Se o IPFS for usado, o Permaweb perderá o recurso de rastreabilidade de dados. O CID de dados do IPFS pode garantir que não seja adulterado, mas o IPFS não usa a tecnologia blockchain. Os dados IPFS não possuem um registro de data e hora do bloco, portanto, é impossível dizer quando os dados foram gerados; ao mesmo tempo, os dados serão perdidos após o fechamento do nó de serviço IPFS e não há garantia de que os dados serão permanentemente rastreável.

Camada de serviço

Como um middleware unificado, a camada de serviço fornece APIs para aplicativos, semelhantes aos clusters de microsserviço Web2, que não possuem estado e podem ser expandidos horizontalmente. Normalmente, a camada de serviço do Permaweb fornecerá interfaces e protocolos padronizados (semelhantes ao gRPC ou Thrift da Web2, completamente de código aberto e protocolos abertos), essas interfaces e protocolos são totalmente abertos e de código aberto, e qualquer provedor de serviços que implanta serviços pode fornecer o mesmo API de acordo com os padrões do protocolo. Qualquer aplicativo pode ser operado e usado em diferentes serviços, desde que seja desenvolvido usando protocolos padrão.

Atualmente, a camada de serviço do Arweave contém quatro componentes principais, a saber:

• • Serviço de gateway: armazenará em cache dados Arweave usados com frequência. Como arweave.asia, arweave.dev, g8way.io, arweave.world, etc.

• **Serviço de vinculação de dados (empacotamento de dados em lote): **Use o padrão Arweave ANS-104 para empacotar uma grande quantidade de dados em lotes para o Arweave. Tais como bundlr, arseeding, etc. Os dados ANS-104 também podem ser recuperados usando o GraphQL.
• **Serviços de serialização: **Serviços de contrato inteligente, serviços de pagamento, etc. Como Warp, everPay, etc.
• **Serviço de indexação: **Serviço de recuperação de tags Arweave, serviço de indexação de texto completo. Tais como Adot, KNN3, goldsky, etc.

O protocolo padrão atual inclui apenas os quatro módulos acima, e a camada de serviço do Permaweb pode expandir ainda mais o novo padrão no futuro.

Camada de aplicação

Os aplicativos Permaweb têm recursos sem servidor, os desenvolvedores não precisam implantar nenhum servidor. Como a camada de serviço fornece uma interface padrão para a camada de aplicativo, os aplicativos desenvolvidos de acordo com as especificações podem ser abertos e usados em qualquer camada de serviço.

**Interação: **Os usuários só precisam interagir com a camada de serviço e não precisam interagir com o blockchain subjacente.

• • **Carregamento de recursos: **O gateway padronizado são todos os recursos de arquivo que precisam ser carregados pelo front-end do Permaweb. De acordo com o padrão Manifest, esses recursos de arquivo organizam os recursos na camada de armazenamento em um formato de diretório, o que é conveniente para os protocolos da web carregar e montar.

• **Gravação de dados: **A escrita do Permaweb geralmente usa o padrão ANS-104 no Arweave, que pode suportar a escrita de dados em larga escala. O serviço de pacote implementado pelo ANS-104 torna a experiência de escrita do Permaweb exatamente igual à do Web2.
• **Consulta e indexação de dados: **O serviço de indexação padronizado permite que o Permaweb carregue conteúdo dinamicamente. O estabelecimento do índice não precisa esperar que os dados sejam finalmente empacotados no Arweave. Após o upload dos dados para o serviço de pacote, um índice de aplicativo eficiente pode ser gerado em tempo real, fornecendo aos usuários recursos de consulta de dados em tempo real .

Resumindo, o Permaweb pode alcançar a mesma experiência que o Web2 em termos de interação.

Resistência à censura: protocolos e interfaces padrão fornecem aplicativos com resistência à censura. A URL listada abaixo é um aplicativo Permaweb chamado livro de receitas:

Pode-se descobrir que o aplicativo do livro de receitas pode ser acessado abrindo qualquer URL, e o site é servido por diferentes gateways e servidores em todo o mundo. Se o arweave.asia ficar inacessível, os usuários ainda poderão usar vários outros URLs para continuar usando o aplicativo. Mesmo que todos os gateways estejam fechados, os dados do livro de receitas são armazenados no Arweave e os dados não serão perdidos para que o provedor de serviços possa restaurar o aplicativo do livro de receitas a qualquer momento.

Usar o armazenamento permanente Arweave como camada de armazenamento pode garantir a descentralização de dados de cada aplicativo Permaweb; usar um protocolo padronizado de código aberto como camada de serviço pode evitar o risco de revisão causado pelo desligamento de servidores individuais devido a força maior. Os aplicativos Permaweb são descentralizados e anticensura.

Versão de microsserviço do SCP

A arquitetura do Permaweb é semelhante à do tradicional Web 2. Em essência, o Permaweb é um conjunto de arquitetura de aplicativo de microsserviço baseado em armazenamento descentralizado.

Microsserviços é um padrão de arquitetura de software usado no desenvolvimento Web2, que divide um aplicativo grande e complexo em uma série de unidades de serviço menores e mais independentes. Cada microsserviço é um módulo funcional independente que pode ser desenvolvido, implantado e executado de forma independente. Esses microsserviços se comunicam por meio de APIs bem definidas, que podem ser implementadas usando protocolos de comunicação leves, como HTTP ou filas de mensagens.

A arquitetura geral do Permaweb é muito semelhante aos microsserviços, e cada aplicativo do Permaweb é composto por unidades de serviço padronizadas e independentes. O mesmo conceito de design dá ao Permaweb a capacidade de criar aplicativos grandes e complexos.

A diferença dos microsserviços tradicionais é que o Permaweb está em conformidade com o SCP e é um aplicativo baseado em consenso de armazenamento. Permaweb é a versão da arquitetura de microsserviços do SCP.

O que é SCP (paradigma de consenso baseado em armazenamento)? Com base no paradigma de consenso baseado em armazenamento, a ideia central é que, desde que o armazenamento seja imutável e as transações acima possam ser rastreadas, a aplicação e o cálculo em qualquer lugar serão o único resultado e o consenso pode ser obtido. A característica do SCP é que os dados subjacentes podem ter combinações ilimitadas. Desde que os dados e os padrões de montagem de dados sejam atendidos, o aplicativo pode gerar um estado exclusivo de qualquer camada de armazenamento ou até mesmo agregar várias camadas de armazenamento.

Ao usar o SCP para desenvolver aplicativos, a arquitetura tradicional do aplicativo não requer muitos ajustes, apenas o banco de dados (camada de armazenamento) precisa ser substituído por um armazenamento blockchain inviolável e rastreável.

Vantagem

Os aplicativos desenvolvidos usando essa arquitetura descentralizada de microsserviços podem obter as mesmas características do blockchain, incluindo descentralização, imutabilidade, rastreabilidade, anticensura e muito mais.

Assim como a arquitetura tradicional de microsserviços, esta arquitetura tem as seguintes vantagens de desenvolvimento:

**1. Modularidade e manutenibilidade: **Serviços independentes, cada um responsável por uma função específica. Esse design padronizado e modular permite que cada serviço seja desenvolvido, testado, implantado e mantido de forma independente, melhorando assim a capacidade de manutenção e a flexibilidade do aplicativo.

**2. Independência: **Cada serviço pode ser desenvolvido e mantido por equipes diferentes. Está mais de acordo com as características do DAO, permitindo que diferentes organizações e indivíduos forneçam o melhor desempenho e velocidade de desenvolvimento para o Permaweb, e permitindo que os desenvolvedores escolham a pilha de tecnologia e as ferramentas mais adequadas. No ecossistema Arweave, podemos ver que equipes diferentes fornecem serviços diferentes, por exemplo, ar.io fornece gateways, bundlr e arseeding de código aberto fornecem serviços de vinculação de dados, everPay e Permaswap fornecem serviços financeiros especializados e assim por diante.

**3. Escalabilidade: **Serviços independentes podem escalar determinados serviços horizontalmente conforme necessário. Pode-se até comparar que cada serviço é o shard mencionado no ETH 2.0, mas o Permaweb não tem limite no número de shards e pode expandir infinitamente horizontalmente. Além disso, o mesmo padrão de protocolo também pode fornecer diferentes serviços de conjunto de dados, como alguns gateways, para otimizar a velocidade de acesso de aplicativos específicos, eles podem apenas armazenar em cache e processar os dados de aplicativos específicos.

**4. Alta disponibilidade: ** Com vários gateways (microsserviços) disponíveis, a aplicação não terá um único ponto de falha e terá melhor disponibilidade.

Essa arquitetura herda todas as vantagens da arquitetura de microsserviços e quebra o problema do triângulo impossível dos aplicativos blockchain. Os aplicativos blockchain tradicionais devem abrir mão de um determinado recurso entre desempenho, segurança e descentralização para garantir a integridade dos outros dois recursos. Na teoria SCP, devido ao uso de um projeto de arquitetura em camadas, o consenso será garantido pela camada de armazenamento e pelo protocolo geral. Neste momento, a descentralização não precisa estar fortemente relacionada ao número de nós, mas ao grau de abertura (código aberto) do protocolo. Quando falamos sobre a descentralização do Ethereum, além de considerar o número de seus nós, devemos também perceber que o próprio software Ethereum é um protocolo padrão. Usuários e mineradores usam o mesmo conjunto de protocolos para chegar a um consenso, que pode formar alto grau de consenso centralizado. No caso do Ethereum, a grande maioria dos usuários e desenvolvedores atualmente usa os serviços fornecidos pelo infura.io. Embora o infura.io seja um serviço centralizado, os usuários podem implantar o protocolo Ethereum a qualquer momento e usar o acesso autônomo à rede. Da mesma forma, os microsserviços descentralizados também podem atender às características acima, mas os microsserviços descentralizados não são uma arquitetura VM específica (como EVM), mas mais flexíveis e mais próximos do modelo teórico das arquiteturas tradicionais. É uma combinação de microsserviços e teoria SCP. nascimento da próxima geração de arquitetura de Internet descentralizada.

Prática: de Arweave, além de Arweave

No momento, Permaweb tem apenas quatro serviços de gateway, ligação de dados, serialização e indexação, e esses serviços formaram certos padrões. Então, como é exatamente uma instância do Permaweb? Especificamente, como construir um Permaweb usando quatro serviços padrão?

Agora Inscreva-se

É um aplicativo Permaweb (doravante referido como Now), que é uma plataforma de comunicação para desenvolvedores ecológicos da Arweave. A principal função do Now é que os usuários iniciem blogs e os usuários possam gostar desses conteúdos.

Todos os dados do Now são armazenados no Arweave, e a camada de armazenamento imutável garante a descentralização do Now. Quando o usuário abrir o Now, o navegador primeiro carregará uma estrutura front-end do serviço de gateway do Arweave, conforme mostrado na figura abaixo, a estrutura da página inclui principalmente o componente Header do Now e não inclui os dados de exibição do aplicativo Now .

Depois que o navegador carrega a estrutura do aplicativo, podemos ver que a parte de exibição do conteúdo do Now exibirá Carimbos de carregamento. Neste momento, o aplicativo Now está iniciando uma solicitação GraphQL para recuperar os dados do aplicativo. Aguarde alguns segundos para que a recuperação seja concluída e o aplicativo Now exibirá os últimos comentários e curtidas do usuário (Stampers), conforme a figura abaixo:

Nesta página, o framework de inicialização e todos os dados do usuário, bem como todas as imagens apresentadas na página são obtidos através do gateway. Esses elementos serão calculados e montados no navegador para formar a página completa do Now. O gateway fornece a capacidade de carregamento de recursos estáticos e o serviço de indexação fornece a capacidade de carregamento de dados dinâmicos.

Quando um usuário deseja adicionar um blog, o usuário pode usar sua carteira para carregar o conteúdo no Arweave. Esses conteúdos serão marcados com tags específicas para que o Index Service possa fornecer a função de consulta GraphQL para esses conteúdos. Depois que o blog for carregado com sucesso, atualize o aplicativo Now novamente e o novo conteúdo será exibido na exibição de conteúdo do aplicativo.

A figura acima mostra o processo básico de escrita e leitura do Permaweb. Em aplicações práticas, tanto a escrita quanto a leitura do Permaweb serão realizadas através da camada de serviço.

Dimensionar

A maior vantagem dos microsserviços é a escalabilidade, que será totalmente herdada do aplicativo Now. Podemos acessar o Now usando qualquer gateway:

• /

Gateways semelhantes podem ser expandidos infinitamente, dando aos aplicativos Now desempenho quase infinito.

Práticas recomendadas de SCP

Na arquitetura do Permaweb, a camada inferior usa apenas o Arweave como camada de armazenamento. Mas os microsserviços descentralizados não devem se limitar a isso, devemos absorver profundamente as vantagens do Permaweb e da arquitetura de microsserviços para explorar as melhores práticas de engenharia do SCP.

A imagem abaixo é do artigo “Mudanças de Consenso, Jornada de Evolução do Paradigma do Aplicativo Blockchain”, que descreve a futura arquitetura do aplicativo blockchain - os usuários não interagem com o sistema blockchain em si, mas com A camada de serviço interage. Os aplicativos Blockchain passaram pelo processo de evolução da Figura 1 para a Figura 3, mais conteúdo pode ser lido:

Como pode ser visto na Figura 3 acima, o blockchain do qual o aplicativo depende não se limita a Arweave, e Bitcoin e Ethereum também são objetos blockchain. Esses blockchains servem como fonte de consenso para o aplicativo, fornecendo descentralização e garantias confiáveis para o aplicativo . Da mesma forma, Permaweb e microsserviços descentralizados também podem ser expandidos, e a camada de armazenamento não precisa limitar Arweave. Ao mesmo tempo, Bitcoin e Ethereum também podem ser usados como camada de armazenamento. Neste momento, a camada de armazenamento também pode ser outra tipos de blockchain. Uma possível arquitetura de melhores práticas é mostrada abaixo:

Usamos a ordem de baixo para cima para descrever:

• **Camada de consenso: **Não é mais apropriado nomear a camada de armazenamento após a expansão do Permaweb. Renomeamos a camada de armazenamento original como camada de consenso. A camada de consenso pode ser qualquer sistema blockchain, e esses sistemas são invioláveis e rastreáveis.
• **Camada de serviço: **A maior diferença entre a camada de serviço e Permaweb é que a camada inferior do protocolo padrão não se limita ao armazenamento Arweave, e os microsserviços podem ser estabelecidos para qualquer sistema blockchain. Tomando o serviço de índice como exemplo, Nansen fornece recursos de consulta de dados para a cadeia pública EVM existente, e muitos Dapps e dados de front-end podem usar Nansen diretamente como fonte de dados. O KNN3 também fornece recursos de indexação semelhantes, criando uma camada de consulta relacional padronizada para dados blockchain, e o KNN3 também fornece recursos de indexação de armazenamento compatíveis com o Arweave GraphQL. Nessa arquitetura, os microsserviços têm mais padrões e melhor compatibilidade de camada de consenso.
• **Camada de aplicação: **Não limitada a aplicações Permaweb, esta arquitetura pode fornecer suporte para aplicações descentralizadas (Web3) e aplicações Web2 ao mesmo tempo, e é totalmente compatível com o sistema de arquitetura original.

Resumo

Quando olhamos para a evolução da engenharia de software de computador nos últimos 30 anos e pensamos sobre a evolução da engenharia blockchain nos últimos 10 anos, temos que refletir se uma máquina virtual global (como EVM) mais uma expansão da Camada 2 solução é o sistema descentralizado definitivo.solução?

Este artigo não se aprofunda na viabilidade da tecnologia Layer2 ou sharding, mas fornece outra possibilidade para aplicação blockchain. Este artigo toma como exemplo o Permaweb do ecossistema Arweave, combinado com a ideia de Storage Consensus Paradigm (SCP) e arquitetura de microsserviços para reorganizar uma solução viável de engenharia. Esta solução não só tem uma forte capacidade de expansão, como também permite que a aplicação tenha características de descentralização. Mais importante ainda, a solução não é uma imagem espelhada, mas um sistema arquitetônico já praticado na engenharia.

Referência

1. O potencial do Arweave é reviver a biblioteca de Alexandria, não uma substituição do Filecoin

2. A evolução do consenso, a evolução do paradigma de aplicação blockchain

3. Cozinhar com o Permaweb

4. Blockchain Storage ARWEAVE: Fita de Papel da Turing Machine, Novo Paradigma de Computação Confiável

5. Uma breve história do desenvolvimento do Arweave e do paradigma de consenso de armazenamento