Resumo:

· Uma aplicação descentralizada consiste em várias partes, mas atualmente apenas a lógica central de backend é executada no Ethereum, e outras partes, como o código de front-end, ainda são implantadas fora do Ethereum. Ao mesmo tempo, ela também contém muitos dados que não estão na cadeia, então a maioria das DAPPs não pode herdar totalmente a segurança do Ethereum e estão longe do estado ideal.

· Existem duas razões principais para os problemas acima: uma é que o Ethereum não fornece aos desenvolvedores os padrões e ferramentas front-end correspondentes, e a outra é que o custo de armazenar dados na cadeia é muito alto.

· Para fornecer um padrão de front-end descentralizado, a equipe EthStorage propôs o protocolo de acesso web3://, fornecendo aos desenvolvedores um conjunto completo de padrões e ferramentas para implantar e acessar código de front-end por meio de contratos inteligentes e até sistemas de arquivos, que agora se tornou o padrão oficial do Ethereum.

· Para reduzir o custo de armazenamento de dados na cadeia Ethereum, a equipe EthStorage desenvolveu o protocolo de armazenamento de segunda camada EthStorage, que utiliza PoRA (Prova de Acesso Aleatório) e prova de conhecimento zero para reduzir significativamente a sobrecarga de armazenamento, ao mesmo tempo em que herda a segurança da primeira camada do Ethereum.

Agradecimentos: Obrigado a Faust da GeekWeb3, Zhixiong Pan da ChainFeeds, Bruce da LXDAO, Qi Zhou e Lun Deng da EthStorage pelo feedback sobre este artigo.

Antecedentes e questões do DAPP descentralizado

A visão do Ethereum é tornar-se o computador do mundo, e as aplicações construídas nele devem herdar a sua segurança. Os desenvolvedores só precisam implantá-lo uma vez, e a aplicação continuará a funcionar no Ethereum para sempre, e nenhuma entidade pode censurá-lo ou manipulá-lo maliciosamente.

Mas as atuais aplicações descentralizadas DAPP alcançaram os objetivos acima? Para responder a esta pergunta de forma mais clara, precisamos desconstruir uma aplicação DAPP para ver quais partes ela inclui e, em seguida, analisar o grau de falta de confiança de cada parte para chegar à conclusão final.

Em termos gerais, um DAPP descentralizado incluirá uma interface front-end, um servidor back-end e um banco de dados. Quando os usuários acessam a interface front-end, eles carregarão o conteúdo front-end através de um navegador e um serviço de nome de domínio. Entre eles:

· Serviços de front-end e nome de domínio: A maioria deles não é implantada e acessada por meio de contratos inteligentes. As características fornecidas pela blockchain, como evitar falhas de ponto único, imutabilidade do código, anti-censura e governança comunitária, não são refletidas nesta parte do front-end.

· Servidores de back-end: Parcialmente implementados por contratos inteligentes, algumas tarefas computacionalmente intensivas não podem ser totalmente on-chain.

· Banco de dados: Parcialmente implementado por contratos inteligentes. Devido aos altos custos de armazenamento na cadeia, DAPP ainda utiliza soluções de armazenamento off-chain quando a quantidade de dados é grande.

Através da análise acima, podemos ver que apenas alguns componentes do atual DAPP descentralizado foram protegidos pela Ethereum por meio de contratos inteligentes, e o sistema Ethereum está longe de realizar a visão original de "computador mundial descentralizado".

No final de 2023, Vitalik revisou o desenvolvimento do Ethereum e escreveu um artigo altamente responsivo 'Make Ethereum Cypherpunk Again', discutindo como a comunidade do Ethereum deveria retornar ao conceito de cypherpunk. No artigo, ele resumiu os valores aos quais o Ethereum e até mesmo a maior comunidade Web3 devem aderir e mencionou um ponto muito importante:

Aplicações descentralizadas devem minimizar sua dependência de qualquer entidade única, para que mesmo que os desenvolvedores principais do DAPP desapareçam para sempre, a aplicação possa continuar operando.

Pode-se ver que Vitalik tem expectativas semelhantes quanto à forma como as aplicações descentralizadas devem ser construídas. Em seguida, analisaremos detalhadamente os problemas enfrentados por cada componente no DAPP descentralizado e exploraremos como melhorá-los.

Serviços de front-end e nome de domínio

Entre os vários componentes das aplicações descentralizadas, o front-end e os serviços de nome de domínio são os mais centralizados. Atualmente, a maioria dos front-ends de dApp usa servidores centralizados. Os proprietários do projeto podem modificar o código do front-end a qualquer momento sem governança da comunidade ou bloqueios de tempo. A segurança desta parte está longe da dos contratos inteligentes implementados no Ethereum.

Hackers podem invadir o servidor para modificar o código front-end, e os usuários de dApp perderão ativos por usar o front-end malicioso. Esse problema tem aparecido repetidamente no último Verão DeFi, e não podemos deixar de perguntar: Por que o front-end não pode ser implantado no Ethereum como o back-end, para que o comportamento de modificação só possa ter efeito por meio de governança comunitária e travas de tempo?

Além disso, por favor, imagine, se a equipe de desenvolvimento da Uniswap não pagar mais pelos servidores de front-end e serviços de nome de domínio um dia, como os usuários e LPs da Uniswap usarão a Uniswap?

A maioria dos usuários não sabe como contornar o front-end e interagir com contratos inteligentes. Embora a Uniswap tenha tentado fazer upload de seu front-end para o IPFS, o IPFS e o Ethereum são redes diferentes, e sua confiabilidade e falta de confiança são completamente diferentes. Vale mencionar que a velocidade de acesso ao conteúdo do IPFS é muito lenta, e a maioria dos usuários ainda está interagindo com o front-end da Uniswap implantado em servidores centralizados.

Além disso, como o operador da interface da Uniswap é a Uniswap Labs, eles aumentaram a revisão da lista de tokens para atender à supervisão, o que contrasta com os contratos inteligentes que eles implantaram no Ethereum, já que ninguém pode modificar os contratos inteligentes à vontade. Portanto, os tokens que são revisados na interface ainda podem interagir no nível do contrato, o que mostra a importância do código on-chain para resistir à censura.

Servidor de back-end

Como o EVM pode fornecer um ambiente de execução completo de Turing, a maioria da lógica backend pode ser executada na cadeia Ethereum. Podemos dizer que as aplicações de contrato inteligente podem herdar totalmente a segurança do Ethereum. Apenas por razões de custo que algumas tarefas intensivas em computação não podem ser executadas diretamente na cadeia.

Para resolver esse problema, a exploração atual é usar ZK ou OP para transferir o cálculo para o off-chain, e a cadeia Ethereum apenas confirma os resultados do cálculo, a fim de expandir a capacidade no nível de computação. Alguns projetos relacionados à IA levaram esse método ao extremo, esperando vincular tarefas super intensivas em computação, como grandes modelos de IA, com blockchains, o que merece nossa atenção.

Banco de dados

Para bancos de dados, a EVM originalmente suporta pares de chave-valor/armazenamento KV (Key Value Store), que podem cobrir uma ampla gama de cenários de uso, mas o problema central é: o custo do armazenamento on-chain é muito alto.

Quão caro é isso? Quando o Preço do Gás é 10Gwei, leva mais de 6.200 ETH para armazenar 1GB de dados na cadeia, o que é mais de 20 milhões de dólares! Obviamente, os custos de armazenamento se tornaram a questão central da descentralização do banco de dados.

Podemos nos perguntar se podemos usar um método semelhante à expansão de computação mencionada acima para expandir o armazenamento, ou seja, armazenamento off-chain e verificação on-chain dos efeitos de armazenamento. Vamos elaborar essa ideia mais tarde.

Após analisar os componentes DAPP mencionados acima, descobrimos que somente quando cada parte do DAPP é segura e sem confiança o suficiente, ele pode verdadeiramente tornar-se um DAPP descentralizado como um todo sem confiança. Ethereum, como a plataforma de operação e hospedagem do dApp, precisa fornecer aos desenvolvedores soluções correspondentes para criar um ecossistema de aplicativos que atenda à visão do Ethereum.

Solução sem confiança para DAPP

Em torno de como fazer um DAPP completamente baseado em Ethereum para implantar e acessar, a equipe EthStorage propôs duas soluções:

• Protocolo de acesso web3://: Resolver o problema de como usar contratos inteligentes para implantar e acessar código front-end e até sistemas de arquivos.
• Protocolo de armazenamento de camada 2 EthStorage: Ao herdar a segurança do Ethereum, ele reduz significativamente a sobrecarga de armazenamento.

Protocolo de Acesso web3://

web3:// pode ser entendido como uma versão descentralizada do http://. Semelhante ao URL http que acessa recursos centralizados especificando um endereço IP do servidor ou nome de domínio, o URL web3 precisa especificar um endereço de contrato inteligente ou nome de domínio ENS para acessar os recursos armazenados nele.

Podemos implantar todo o front end de um site em um smart contract e acessá-lo por meio de web3://! Você pode comparar a diferença entre os dois:

Atualmente, web3:// se tornou o padrão oficial do Ethereum (ERC-4804). Se você deseja aprender mais sobre o conteúdo do protocolo de acesso web3://, pode visitar seu site oficial. Para gerenciar arquivos de forma mais eficiente em contratos inteligentes, propusemos o ERC-5018, que simula um conjunto de interfaces de sistema de arquivos em contratos inteligentes, para que você possa fazer upload da pasta de código front-end empacotada para um contrato inteligente através do ethfs-cli e acessar este site através do web3://.

Se estiver interessado, pode seguir o tutorial para concluir um simples implantação de aplicativo descentralizado e acesso.

Com o protocolo de acesso web3://, podemos realmente fazer com que a parte frontal do dApp tenha o atributo de “O Código é a lei”. Para os desenvolvedores, uma vez implantada, esta parte frontal será executada para sempre. Imagine se o Uniswap labs também implantasse sua parte frontal no Ethereum, então mesmo que a equipe quisesse censurar e restringir os usuários no nível da parte frontal, não seria capaz de impedir as pessoas de usar sua parte frontal implantada no Ethereum.

Claro, após resolver o problema de viabilidade, também percebemos que o custo de armazenar grandes quantidades de dados na cadeia seria muito alto, o que causou problemas para os desenvolvedores ao implantar o front-end na cadeia. Desenvolvemos ainda mais o protocolo de armazenamento de segunda camada EthStorage, que reduz significativamente os custos de armazenamento, ao mesmo tempo em que herda a segurança do Ethereum.

Protocolo de armazenamento de camada 2 EthStorage

O protocolo EthStorage consiste em contratos inteligentes implantados no Ethereum e nós de armazenamento na rede Layer2, onde os contratos inteligentes fornecem armazenamento de chave-valor, enquanto os nós de armazenamento de segunda camada são responsáveis por armazenar os dados em si.

Os usuários carregam os dados a serem armazenados no Ethereum através do BLOB do EIP-4844. O contrato inteligente EthStorage apenas registra o hash dos dados no BLOB, reduzindo efetivamente os custos de armazenamento.

Ao mesmo tempo, o nó de armazenamento da segunda camada fará o download dos dados BLOB correspondentes para o disco local e usará PoRA (Proof of Random Access) e ZK para enviar a prova de armazenamento ao contrato no Ethereum para verificação. O contrato precisa usar o hash Blob previamente registrado para confirmar se a prova ZK enviada pelo nó de armazenamento corresponde, a fim de confirmar que o nó de armazenamento na rede da segunda camada realmente armazena esses dados.

O processo específico é o seguinte:

Para os desenvolvedores, a interface para carregar e obter dados é muito simples:

Os desenvolvedores de aplicativos podem ler e gravar diretamente grandes blocos de dados através da interface do contrato fornecida pelo EthStorage, e o custo de gravação é aproximadamente milésimo do que armazenar dados diretamente na cadeia. Portanto, o EthStorage não só suporta a implantação on-chain do front-end, mas também fornece uma solução de custo mais baixo para uma gama mais ampla de operações de banco de dados de armazenamento chave-valor.

Atualmente, EthStorage obteve as Bolsas oficiais da Ethereum e implantou uma rede de testes públicos em Sepolia. Todos são bem-vindos para participar.

Resumo e Perspectivas

A maioria dos componentes mais importantes do DAPP, como o front-end e o banco de dados, não são implantados no Ethereum e não podem herdar a segurança do Ethereum, resultando na incapacidade da aplicação como um todo de ser permanentemente executada, resistente à censura e governável.

EthStorage propôs duas soluções para este problema: o protocolo de acesso web3:// resolve o problema de usar smart contracts para implantar e acessar a interface; o protocolo de armazenamento de segunda camada do EthStorage resolve o problema dos altos custos de armazenamento.

Para realizar a visão original do Ethereum, acreditamos que ele evoluirá para um servidor web descentralizado, e os aplicativos descentralizados no ecossistema irão implantar todos os seus componentes no Ethereum. Seja o código de back-end, o front-end ou os dados, uma vez implantados, o código pode ser executado permanentemente e os dados podem ser acessados permanentemente, tornando-se um Dapp verdadeiramente imparável.

A rede de teste pública EthStorage está atualmente realizando sua segunda campanha de incentivo. Membros da comunidade interessados podem seguir o Guia para concluir sua primeira implantação de Dapp Imparável e acessar!

Declaração:

1. Este artigo é reproduzido a partir de [GateGeek Web3], a autoria pertence ao autor original [Equipe EthStorage], se você tiver alguma objeção à reprodução, entre em contato Equipe Gate Learn ), a equipe lidará com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. Aviso Legal: As visões e opiniões expressas neste artigo representam apenas as visões pessoais do autor e não constituem nenhum conselho de investimento.

3. Outras versões do artigo em outros idiomas são traduzidas pela equipe do Gate Learn e não são mencionadas em Gate.io) o artigo traduzido não pode ser reproduzido, distribuído ou plagiado.