Resumo

• As crescentes demandas de armazenamento apresentam desafios significativos para os nós do Ethereum.
• Alguns clientes começaram a podar os dados históricos devido a restrições de armazenamento, resultando em comportamentos de armazenamento inconsistentes entre nós completos na rede.
• Para garantir a uniformidade em todos os clientes, a poda de dados históricos está sendo padronizada no EIP-4444 e EIP-4844
• Consequentemente, recuperar o estado mais recente de L1 ou L2, reproduzindo dados históricos, depende de serviços centralizados, fora do protocolo, o que estimula a exploração de soluções mais descentralizadas alinhadas com o Ethereum
• A rede Ethereum Portal é uma rede P2P leve e descentralizada para todos os tipos de dados do Ethereum, incluindo dados históricos. É projetada para dispositivos com recursos limitados e fornece serviço JSON-RPC do Ethereum. A rede histórica e a rede beacon estão quase prontas para uso.
• A rede de armazenamento EthStorage é uma rede de armazenamento modular incentivada para BLOBs EIP-4844. Para armazenar um BLOB, um usuário chama o contrato de armazenamento L1put()método com o hash BLOB e uma taxa em ETH. A taxa será distribuída gradualmente aos provedores de armazenamento ao enviar uma prova válida de armazenamento de BLOBs off-chain ao longo do tempo. A rede de teste EthStorage está em execução na rede de teste Ethereum Sepolia com vários participantes da comunidade provando com sucesso seu armazenamento local.
• Iniciativas futuras incluem o desenvolvimento de uma rede estatal descentralizada, a implementação de prova de armazenamento para dados de tamanho dinâmico e acesso descentralizado diretamente a partir dos navegadores.

Agradecimento: Muito obrigado a Piper Merriam da EF, Karthik Raju da Polychain, Qiang da EthStorage por fornecerem feedback do artigo.

Antecedentes

Em 22 de outubro de 2023, Péter Szilágyi, o renomado líder de desenvolvimento do Go-Ethereum (Geth), expressou suas profundas preocupações no Twitter. Ele apontou que, enquanto os clientes Geth preservam todos os dados históricos, outros clientes Ethereum como Nethermind e Besu podem ser configurados para operar sem determinados dados históricos do Ethereum, como corpos e cabeçalhos de blocos históricos. Isso torna todos os clientes inconsistentes e é injusto para o Geth. Isso desencadeou intensas discussões e debates em torno do problema de armazenamento do Ethereum no roadmap do Ethereum.

O Desafio de Armazenamento

Por que Nethermind e Besu optam por parar de armazenar dados históricos? Quais problemas estão por trás dessa decisão? Na minha perspectiva, existem duas causas raiz principais:

• Os requisitos de armazenamento para um cliente Ethereum estão se tornando cada vez mais exigentes.
• Não há incentivo ou penalidade no protocolo para armazenar dados históricos do Ethereum.

A primeira razão decorre das crescentes demandas de armazenamento para executar um cliente Ethereum. Para aprofundar nos requisitos específicos, o gráfico de pizza a seguir ilustra a distribuição dos custos de armazenamento para um novo nó Geth, a partir do bloco 18.779.761 em 13 de dezembro de 2023.

Como a imagem mostra:

• Requisito total de armazenamento: 925.39 GB
• Dados históricos (blocos/recibos): Aproximadamente 628.69 GB
• Estado na Árvore de Patricia Merkle (MPT): Aproximadamente 269,74 GB

A segunda razão é a ausência de incentivos ou penalidades in-protocolo para armazenar blocos históricos. Embora o protocolo exija que os nós armazenem todos os dados históricos, ele falha em fornecer qualquer mecanismo para incentivar o armazenamento ou penalizar a falta de conformidade. Armazenar e compartilhar dados históricos pelos nós se torna puramente altruísta, e um nó tem liberdade para podar todos os dados históricos sem enfrentar quaisquer consequências adversas. Em contraste, os validadores, por exemplo, devem manter o estado completo mais recente para evitar propor/votar em um bloco inválido, arriscando a perda de incentivos em qualquer caso.

Consequentemente, quando o custo de armazenamento se torna um fardo substancial para um nó, não é surpreendente que alguns operadores de nó optem por podar dados históricos. Optar por executar sem dados históricos pode resultar em economias significativas de custos de armazenamento, reduzindo de aproximadamente 1TB para cerca de 300GB.

Ilustração: A configuração do Nethermined para executar um nó sem os corpos de bloco históricos - economizando ~460GB de custo de armazenamento no momento.

O desafio do armazenamento deve se intensificar com a próxima atualização de Disponibilidade de Dados (DA) do Ethereum. caminhoO caminho rumo à escalabilidade total do Ethereum DA começa com o EIP-4844 em DenCun, introduzindo um objeto binário grande de tamanho fixo (BLOB) acompanhado por um modelo de taxa independente conhecido como blobGasPrice. Cada BLOB é definido em 128KB, e o EIP-4844 permite que cada bloco contenha até 6 BLOBs. Para aprimorar a escalabilidade de dados, o plano envolve a implementação do código 1D Reed-Solomon, permitindo inicialmente 32 BLOBs por bloco e eventualmente alcançando 256 BLOBs por bloco na escalabilidade total.

Com o Ethereum DA operando com capacidade total de dados com 256 BLOBs por bloco, um ano da rede Ethereum DA é projetado para aceitar aproximadamente 80 TB de dados, superando as capacidades de armazenamento da maioria dos nós Ethereum.

Caminho de Armazenamento do Ethereum e Consequência

Vitalik’stweetdo roteiro do Ethereum, no qual o Purge lida principalmente com armazenamento.

Os crescentes custos de armazenamento têm chamado a atenção de pesquisadores dentro do ecossistema Ethereum. Para lidar com isso e garantir alinhamento entre todos os clientes, várias propostas estão em desenvolvimento para podar explicitamente o armazenamento. As duas principais propostas são:

1. EIP-4444: Dados Históricos Vinculados em Clientes de Execução: Esta proposta permite que um cliente corte blocos históricos com mais de um ano. Supondo um tamanho médio de bloco de 100K, os dados do bloco histórico são limitados a aproximadamente 250 GB (100K (3600 24 * 365) / 12, dado o tempo de bloco = 12s).
2. EIP-4844: Transações de BLOB de Fragmentos: EIP-4844 descarta BLOBs com mais de 18 dias. Esta é uma abordagem mais agressiva em comparação com a EIP-4444, limitando o tamanho histórico do BLOB em cerca de 100 GB ((18360024) 128K 6 / 12, dado tempo de bloco = 12s).

Qual é a consequência de podar dados históricos de todos os clientes? A principal é que um nó novo não pode sincronizar com o estado mais recente via “sincronização completa” - uma sincronização para retransmitir as transações desde o bloco de gênese até o bloco mais recente. Em vez disso, temos que recorrer a uma “sincronização rápida” ou “sincronização de estado” para sincronizar o estado mais recente a partir dos pares do Ethereum. Esta abordagem já está implementada no Geth e é executada como a sincronização padrão.

Da mesma forma, essa consequência também se aplica a todos os L2s, ou seja, um novo nó de L2 não pode reproduzir totalmente o estado mais recente da gênese L2 do Ethereum reproduzindo blocos L2 da gênese L2. Além disso, como os nós L1 não mantêm o estado L2, a abordagem de "snap sync" para L2 não pode derivar o estado L2 mais recente de L1 - quebrando uma suposição L2 importante de herdar garantias de segurança Ethereum. A solução projetada contará com serviços de 3ª parte, como os próprios projetos Infura / Etherscan / L2 para armazenar uma cópia de dados históricos L2 ou estado, que é centralizado com incentivo indireto fora do protocolo.

As perguntas centrais que estamos fazendo são

• Podemos ter uma solução descentralizada melhor, tanto em termos de armazenamento quanto de acesso, para o problema?
• É possível construir uma solução alinhada com o Ethereum e minimizada em confiança (por exemplo, em cima de um contrato L1) com uma solução de incentivo direto?
• Com tudo isso, podemos abrir caminho para uma solução de incentivo direto no protocolo para armazenamento do Ethereum e acessá-los de forma totalmente descentralizada no roteiro do Ethereum?

Soluções

Solução 1: Rede Portal Ethereum

A rede Ethereum Portal serve como uma rede de acesso leve e descentralizada ao protocolo Ethereum. Oferecendo a interface JSON-RPC do Ethereum, como eth_call, eth_getBlockByNumber, ela traduz solicitações JSON-RPC em solicitações P2P para uma tabela de hash distribuída, semelhante à rede IPFS. Ao contrário do IPFS, que permite o armazenamento de qualquer tipo de dados e é suscetível a spam, a rede P2P do Portal hospeda exclusivamente dados do Ethereum, como cabeçalhos e corpos históricos. Isso é alcançado por meio de uma técnica de verificação de cliente leve incorporada dentro da rede Portal.

Uma característica significativa da rede Portal é o seu design para operação leve e compatibilidade com dispositivos com recursos limitados. Pode ser executado em cima de um nó com alguns megabytes de armazenamento e baixa memória, promovendo a descentralização. Até mesmo um celular ou um dispositivo Raspberry Pi pode potencialmente se juntar à rede e contribuir para a disponibilidade de dados do Ethereum.

O desenvolvimento da rede Portal está alinhado com a filosofia de diversidade de clientes Ethereum, com clientes escritos em Rust, JavaScript, Nim e Go. A rede de faróis e a rede de histórico estão prontas para uso, enquanto a rede de estado está ativamente em desenvolvimento. Notavelmente, a rede Portal não fornece incentivos diretos para armazenamento de dados - todos os nós na rede operam de forma altruística.

Ilustração: Executando uma rede Portal (Trin) com um limite de armazenamento de 100MB.

Solução 2: Rede EthStorage

A rede EthStorage é uma rede de armazenamento incentivada descentralizada, projetada especificamente para armazenar BLOBs EIP-4844, com suporte de uma bolsa do programa ESP.

• Confiança Mínima: Ao contrário das soluções existentes que precisam de uma ponte de dados centralizada, o EthStorage depende do consenso do Ethereum e do modelo de confiança de $1/m$ dos provedores de armazenamento do EthStorage sem permissão. O procedimento de armazenamento de um BLOB é o seguinte: um usuário assina uma transação que transporta um BLOB que chama o método _put(key, blob_idx)_ do contrato de armazenamento. O contrato de armazenamento então registrará o hash do BLOB e notificará os provedores de armazenamento com um evento. Os provedores de armazenamento, após receberem o evento, iriam baixar e armazenar o BLOB diretamente da rede Ethereum DA, contornando o problema da ponte de dados.
• Alinhar o custo de armazenamento com o incentivo: ao chamarcolocar()método, uma taxa de armazenamento deve ser enviada (via msg.value) e depositados no contrato. Esta taxa de armazenamento é gradualmente distribuída aos provedores de armazenamento ao longo do tempo, após a submissão e verificação bem-sucedidas de uma prova de armazenamento. Comparado ao modelo de taxa de armazenamento atual do Ethereum, que paga uma taxa de armazenamento única ao proponente, a taxa de armazenamento paga ao longo do tempo segue um modelo de fluxo de caixa descontado - assumindo que o custo de armazenamento diminui em relação ao ETH ao longo do tempo. Esta inovação significativa introduzida pelo EthStorage alinha a taxa paga pelos usuários e as contribuições dos provedores de armazenamento ao longo do tempo.
• Prova de Armazenamento: A prova de armazenamento é inspirada pela amostragem de dados disponíveis, enquanto a amostragem em EthStorage é realizada contra BLOBs ao longo do tempo, em vez dos de um bloco proposto. Para verificar eficientemente a amostragem on-chain, EthStorage utiliza amplamente contratos inteligentes e os últimos desenvolvimentos em tecnologias SNARK.
• Rede sem permissão: Qualquer nó no EthStorage pode ser pago como um provedor de armazenamento, desde que ele armazene dados e envie periodicamente provas de armazenamento na cadeia.

Do ponto de vista da modularidade blockchain, o EthStorage funciona como uma camada 2 do Ethereum, mas cobra taxas de armazenamento em vez de taxas de transação. Ao indexar hashes BLOB on-chain, o EthStorage é uma camada de armazenamento modular do Ethereum com escalabilidade de armazenamento significativa e economia de custos - visando cerca de 1000x.

Em termos de desenvolvimento, EthStorage já está integrado com EIP-4844 na rede de testes Ethereum Sepolia. Um teste de estresse em EthStorage e na rede de testes Ethereum Sepolia foi conduzido, envolvendo a escrita de aproximadamente centenas de Gigabytes de BLOBs no EthStorage. Mais de 50 participantes da comunidade se juntaram à rede e provaram com sucesso seus armazenamentos locais.

A principal vantagem da rede EthStorage reside em fornecer um incentivo direto e descentralizado sobre o Ethereum - uma característica pioneira, até onde se estende nosso conhecimento atual. No entanto, uma limitação da rede é que ela é especificamente projetada para BLOBs de tamanho fixo.

O painel do EthStorage na Ethereum Devnet

Projetando o Futuro

O armazenamento do Ethereum, embora menos destacado, tem uma importância significativa dentro do ecossistema do Ethereum. À medida que a rede Ethereum está passando por um crescimento rápido, o armazenamento e a acessibilidade dos dados do Ethereum surgem como desafios críticos. Embora a rede Portal e a rede EthStorage estejam em seus estágios iniciais, visualizamos várias direções intrigantes para o longo prazo:

• Acesso descentralizado de baixa latência ao Estado do Ethereum. Acessar o estado do Ethereum de maneira descentralizada e verificável é uma tarefa crítica, porém desafiadora. Dado um setup tradicional de DHT, a consulta de uma conta geralmente requer múltiplas consultas aos nós internos da trie armazenados em diferentes nós P2P. Isso frequentemente resulta em considerável latência longa. Como empregar a estrutura da árvore de estado para acelerar o acesso é a chave, conforme abordado pela próxima rede de estado da rede Portal do Ethereum.
• Integração entre a Rede Portal e a Rede EthStorage: A rede Portal pode estender sua suporte para incluir BLOBs dentro da rede de forma contínua, um passo já parcialmente dado pela equipe EthStorage. Uma progressão natural seria unir essas redes para oferecer uma rede JSON-RPC descentralizada capaz de chamar contratos com acesso a BLOBs. Combinando a lógica do aplicativo nos contratos e o armazenamento escalonado de BLOBs pela EthStorage, permitimos novos dApps no Ethereum, como sites descentralizados dinâmicos (por exemplo, twitter/youtube/wikipedia/etc descentralizados).
• Acesso descentralizado a partir de navegadores: Similar ao protocolo ipfs:// usado para acessar os dados na rede IPFS, há uma crescente necessidade de um protocolo de acesso nativo do Ethereum a partir de navegadores para desbloquear o vasto potencial dos ricos dados do Ethereum. Estes dados englobam um amplo espectro, que vai desde a propriedade e saldos de tokens até imagens de NFT e sites descentralizados dinâmicos, tudo possibilitado pelas capacidades dos contratos inteligentes e do armazenamento futuro do Ethereum. Neste âmbito, o protocolo web3://, conforme definido em ERC-4804/6860, está atualmente passando por um desenvolvimento ativo para cumprir este propósito.
• Prova Avançada de Armazenamento para Dados de Tamanho Dinâmico: Além de BLOBs fixos, explorar a prova avançada de armazenamento torna-se imperativo para lidar com dados de tamanho dinâmico, como blocos históricos ou até mesmo objetos de estado. O desenvolvimento de algoritmos sofisticados pode aprimorar a adaptabilidade das soluções de armazenamento.

Em nossa busca, aspiramos que esses esforços contribuam coletivamente para o roteiro do Ethereum, lançando as bases para futuras soluções de armazenamento descentralizado dentro do ecossistema do Ethereum.

declaração:

1. Este artigo é reproduzido a partir de [fluxo de tecnologia profunda na maré], o título original é “Ethereum Storage Roadmap: Desafios e Oportunidades”, os direitos autorais pertencem ao autor original [EthStorage], se você tiver alguma objeção à reprodução, entre em contatoEquipe 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 opiniões pessoais do autor e não constituem nenhum conselho de investimento.

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