Resumo

• As crescentes exigências de armazenamento representam desafios significativos para os nós do Ethereum.
• Alguns clientes começaram a podar os dados históricos devido a restrições de armazenamento, levando a comportamentos de armazenamento inconsistentes entre os nós completos na rede.
• Para garantir a uniformidade entre todos os clientes, a poda de dados históricos está a ser padronizada no EIP-4444 e EIP-4844
• Consequentemente, recuperar o estado mais recente de L1 ou L2, repetindo dados históricos, depende de serviços centralizados, fora do protocolo, promovendo a exploração de soluções mais descentralizadas alinhadas com o Ethereum
• A rede de portal Ethereum é uma rede P2P leve e descentralizada para todos os tipos de dados Ethereum, incluindo dados históricos. É projetada para dispositivos com recursos limitados e fornece serviço JSON-RPC 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á gradualmente distribuída aos provedores de armazenamento após a apresentação de uma prova válida de armazenamento de BLOBs off-chain ao longo do tempo. A testnet EthStorage está em execução na testnet 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 fornecer 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 certos 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 dentro do roteiro do Ethereum.

O Desafio do Armazenamento

Por que Nethermind e Besu optam por parar de armazenar dados históricos? Quais são os problemas subjacentes a esta decisão? Do meu ponto de vista, existem duas causas raiz principais:

• Os requisitos de armazenamento para um cliente Ethereum estão a tornar-se cada vez mais exigentes.
• Não existe nenhum incentivo ou penalização no protocolo para armazenar dados históricos do Ethereum.

A primeira razão decorre das crescentes exigências de armazenamento para executar um cliente Ethereum. Para aprofundar os requisitos específicos, o seguinte gráfico de pizza 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 Merkle Patricia (MPT): Aproximadamente 269.74 GB

A segunda razão é a ausência de incentivos ou penalidades no protocolo para armazenar blocos históricos. Embora o protocolo exija que os nós armazenem todos os dados históricos, não fornece nenhum mecanismo para incentivar o armazenamento ou penalizar a não conformidade. Armazenar e compartilhar dados históricos pelos nós torna-se puramente altruístico, e um nó é livre 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 ambos os casos.

Consequentemente, quando o custo de armazenamento se torna um fardo substancial para um nó, não é surpreendente que alguns operadores de nós optem por podar os 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 Nethermined para executar um nó sem corpos de bloco históricos - economizando cerca de ~460GB de custo de armazenamento no momento.

Espera-se que o desafio do armazenamento se intensifique com a próxima atualização de Disponibilidade de Dados (DA) do Ethereum. O caminhoO caminho para a 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 melhorar a escalabilidade de dados, o plano envolve a implementação do código Reed-Solomon 1D, permitindo inicialmente 32 BLOBs por bloco e eventualmente atingindo 256 BLOBs por bloco na escalabilidade total.

Com o Ethereum DA a operar a plena capacidade de dados com 256 BLOBs por bloco, prevê-se que a rede Ethereum DA aceite aproximadamente 80 TB de dados num ano, ultrapassando as capacidades de armazenamento da maioria dos nós Ethereum.

Roadmap de Armazenamento do Ethereum e Consequência

Vitalik’stweetdo roteiro do Ethereum, em que o Purge lida principalmente com armazenamento.

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

1. EIP-4444: Dados Históricos Limitados nos Clientes de Execução: Esta proposta permite que um cliente elimine blocos históricos com mais de um ano. Assumindo 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 Fragmento: O EIP-4844 descarta BLOBs com mais de 18 dias. Esta é uma abordagem mais agressiva em comparação com o EIP-4444, limitando o tamanho histórico do BLOB em cerca de 100 GB ((18360024)128K6 / 12, dada uma hora do 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 reexecutar as transações a partir do bloco gênesis 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 dos pares 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ó do L2 não pode reproduzir totalmente o estado mais recente do L2 desde o início do Ethereum, reproduzindo os blocos do L2 desde o início do L2. Além disso, como os nós L1 não mantêm o estado do L2, a abordagem de "snap sync" para o L2 não pode derivar o estado mais recente do L2 do L1 - quebra uma importante suposição do L2 de herdar as garantias de segurança do Ethereum. A solução projetada dependerá de serviços de terceiros, como Infura / Etherscan / os próprios projetos L2, para armazenar uma cópia dos dados ou do estado histórico do L2, que é centralizado com incentivo indireto fora do protocolo.

As questões centrais que estamos a fazer 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 a Ethereum e minimizada em confiança (por exemplo, em cima de um contrato L1) com uma solução de incentivo direto?
• Com tudo isto, podemos abrir caminho para uma solução de incentivo direto no protocolo para armazenamento de Éter e acesso a eles de forma totalmente descentralizada no roteiro do Ethereum?

Soluções

Solução 1: Rede Portal Ethereum

A rede Portal Ethereum funciona como uma rede de acesso leve e descentralizada ao protocolo Ethereum. Oferecendo a interface JSON-RPC do Ethereum, como eth_call, eth_getBlockByNumber, traduz pedidos JSON-RPC em pedidos 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 embutida de clientes leves 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 pouca memória, promovendo a descentralização. Até mesmo um celular ou um dispositivo Raspberry Pi pode potencialmente juntar-se à rede e contribuir para a disponibilidade de dados do Ethereum.

O desenvolvimento da rede Portal está alinhado com a filosofia de diversidade de clientes do Ethereum, com clientes escritos em Rust, JavaScript, Nim e Go. A rede de beacon e a rede de histórico estão prontas para uso, enquanto a rede de estado está ativamente em desenvolvimento. É importante destacar que 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: Executar uma rede Portal (Trin) com um limite de armazenamento de 100MB.

Solução 2: Rede EthStorage

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

• Confiança Mínima: Ao contrário das soluções existentes que necessitam de uma ponte de dados centralizada, o EthStorage baseia-se no consenso do Ethereum e no modelo de confiança de $1/m$ dos fornecedores de armazenamento EthStorage sem permissão. O procedimento de armazenamento de um BLOB é o seguinte: um utilizador assina uma transação de transporte de BLOB que chama o método_put(key, blob_idx) do contrato de armazenamento. O contrato de armazenamento registará então o hash do BLOB e notificará os fornecedores de armazenamento com um evento. Os fornecedores de armazenamento, após receberem o evento, irão então descarregar e armazenar o BLOB diretamente da rede DA Ethereum, contornando o problema da ponte de dados.
• Alinhar o custo de armazenamento com o incentivo: Ao chamarput()método, uma taxa de armazenamento deve ser enviada (via msg.value) e depositados no contrato. Esta taxa de armazenamento é gradualmente distribuída aos fornecedores de armazenamento ao longo do tempo, após a submissão e verificação bem-sucedidas de uma prova de armazenamento. Comparado com o 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 pela EthStorage alinha a taxa paga pelos usuários e as contribuições dos fornecedores 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 daquelas de um bloco proposto. Para verificar eficientemente a amostragem on-chain, EthStorage utiliza fortemente contratos inteligentes e os mais recentes desenvolvimentos em tecnologias SNARK.
• Rede Sem Permissão: Qualquer nó em EthStorage pode ser pago como um fornecedor de armazenamento, desde que armazene dados e envie periodicamente provas de armazenamento na cadeia.

Do ponto de vista da modularidade da blockchain, o EthStorage funciona como uma Ethereum Layer 2, 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 significativa de armazenamento 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 realizado, envolvendo a gravação de aproximadamente centenas de gigabytes de BLOBs em 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 descentralizado e direto sobre o Ethereum - uma característica pioneira, até onde se estende o nosso conhecimento atual. No entanto, uma limitação da rede é que ela é especificamente projetada para BLOBs de tamanho fixo.

O painel de EthStorage na Ethereum Devnet

Projetando o Futuro

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

• Acesso descentralizado de baixa latência ao Estado do Ethereum. Acessar o estado do Ethereum de forma descentralizada e verificável é uma tarefa crítica, mas desafiadora. Dado um setup DHT tradicional, consultar uma conta geralmente requer múltiplas consultas aos nós de trie internos 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, como está sendo 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 facilmente o seu suporte para incluir BLOBs dentro da rede, um passo já parcialmente dado pela equipa EthStorage. Uma progressão natural seria unir estas redes para oferecer uma rede JSON-RPC descentralizada capaz de chamar contratos com acesso a BLOBs. Combinando a lógica da aplicação nos contratos e o armazenamento escalado de BLOBs pela EthStorage, permitimos novas dApps no Ethereum, como websites descentralizados dinâmicos (por exemplo, twitter/youtube/wikipedia/etc descentralizados).
• Acesso descentralizado a partir de navegadores: Semelhante ao protocolo ipfs:// utilizado para aceder aos 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 dados ricos do Ethereum. Estes dados englobam um vasto espectro, desde a propriedade de tokens e saldos até imagens de NFT e websites descentralizados dinâmicos, tudo possibilitado pelas capacidades dos contratos inteligentes e futuro armazenamento do Ethereum. Neste domínio, o protocolo web3://, conforme definido no ERC-4804/6860, está atualmente em desenvolvimento ativo para cumprir este propósito.
• Prova avançada de armazenamento para dados de tamanho dinâmico: Além dos BLOBs fixos, explorar uma 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 melhorar a adaptabilidade das soluções de armazenamento.

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

declaração:

1. Este artigo é reproduzido a partir de [fluxo tecnológico profundo maré], o título original é “Roteiro de Armazenamento do Ethereum: Desafios e Oportunidades”, os direitos autorais pertencem ao autor original [EthStorage], se tiver alguma objeção à reimpressão, por favor entre em contatoEquipa Gate Learn, a equipa irá tratar do assunto o mais breve possível, de acordo com os procedimentos relevantes.

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

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