O que é o crescimento histórico?

A história no Ethereum consiste em todos os blocos e transações executadas ao longo de sua vida. Estes dados são necessários para sincronizar a cadeia desde o bloco de gênese até o seu estado atual. O crescimento histórico refere-se à acumulação de novos blocos e transações ao longo do tempo.

A Figura 1 mostra a relação entre o crescimento histórico, várias métricas de protocolo e limitações de hardware do nó Ethereum. Ao contrário do crescimento do estado, o crescimento histórico é limitado por um conjunto diferente de limitações de hardware. Essa pressão de crescimento afeta a E/S da rede porque novos blocos e transações precisam ser transmitidos pela rede. Também sobrecarrega o espaço de armazenamento do nó, já que cada nó Ethereum armazena uma cópia completa do registro histórico. Se o crescimento histórico ultrapassar essas limitações de hardware, os nós não serão mais capazes de alcançar um consenso estável com seus pares. Para obter uma visão geral do crescimento do estado e de outros gargalos de escalabilidade, consulteParte 1desta série.

Figura 1: Ethereum gargalo de expansão

Até recentemente, a maior parte do throughput da rede de cada nó era utilizada para transmitir registos históricos (por exemplo, novos blocos e transações). Isto mudou com a introdução de blobs no Dencunhard fork. Agora, os blobs constituem uma parte significativa da atividade da rede de nós. No entanto, os blobs não são considerados parte do registro histórico porque 1) os nós os armazenam apenas por 2 semanas antes de descartá-los e 2) eles não são necessários para reproduzir a cadeia desde o Genesis. Devido a (1), os blobs não aumentam significativamente a carga de armazenamento em cada nó Ethereum. Discutiremos os blobs com mais detalhes mais tarde neste artigo.

Neste artigo, iremos focar no crescimento de dados históricos e na sua relação com o crescimento do estado. Uma vez que o crescimento do estado e o crescimento histórico partilham algumas restrições de hardware sobrepostas, são questões inter-relacionadas; abordar uma pode ajudar a mitigar a outra.

Quão rápido se desenvolve a história?

A Figura 2 mostra a taxa de crescimento histórico ao longo do tempo desde a origem do Ethereum. Cada barra vertical representa o crescimento de um mês. O eixo Y representa o número de GBs adicionados ao histórico nesse mês. As transações são categorizadas pelo seu “endereço de destino” e o seu tamanho é determinado usando o seuRLPrepresentação de byte. Contratos que não podem ser facilmente identificados são classificados como "desconhecidos". A categoria "outros" inclui uma longa cauda de categorias menores como infraestrutura e jogos.

Várias conclusões importantes podem ser retiradas deste gráfico:

1. A taxa de crescimento histórico é cerca de 6 a 8 vezes mais rápida do que o crescimento do Estado: o crescimento histórico atingiu recentemente o pico de 36,0 GiB/mês e está atualmente em 19,3 GiB/mês. O crescimento do Estado atingiu o pico de cerca de 6,0 GiB/mês e agora está em 2,5 GiB/mês. Uma comparação entre o crescimento histórico e o do Estado, tanto em termos de taxa como de tamanho acumulado, pode ser encontrada mais adiante neste artigo.
2. A taxa de crescimento histórico estava a acelerar rapidamente antes de Dencun: enquanto o crescimento estatal tem sido aproximadamente linear ao longo dos anos (ver Parte 1)O crescimento histórico tem sido superlinear. O crescimento linear resulta num aumento quadrático no tamanho total, enquanto o crescimento superlinear resulta num aumento mais rápido do que quadrático. Esta aceleração parou abruptamente após Dencun, marcando a primeira desaceleração significativa no crescimento histórico na história do Ethereum.
3. O crescimento histórico recente advém principalmente dos Rollups: Cada L2 envia uma cópia das suas transações de volta para a mainnet, gerando uma quantidade significativa de dados históricos e tornando os rollups o maior contribuinte para o crescimento histórico no último ano. No entanto, o Dencun permite que os L2s usem blobs em vez de registos históricos para enviar os seus dados de transação, pelo que os rollups já não geram a maioria dos registos históricos do Ethereum. Vamos examinar os rollups com mais detalhe mais tarde neste artigo.

Quais são os maiores contribuintes para a história do Ethereum?

A quantidade de dados históricos gerados por cada categoria de contrato revela como os padrões de uso do Ethereum evoluíram ao longo do tempo. A Figura 3 mostra as contribuições relativas de várias categorias de contrato. Isso usa os mesmos dados da Figura 2, normalizados para 100%.

Os dados revelam quatro eras distintas de padrões de uso do Ethereum:

Primeira Era (Roxo): Nos primeiros anos do Ethereum, houve uma atividade mínima na cadeia. A maioria desses contratos iniciais é agora difícil de identificar e é rotulada como "desconhecida" no gráfico.

Era ERC-20 (Verde): O padrão ERC-20foi finalizado no final de 2015, mas não ganhou significativa tração até 2017 e 2018. Em 2019, os contratos ERC-20 tornaram-se a maior categoria no crescimento histórico.

Era DEX/DeFi (Marrom): Os contratos DEX e DeFi apareceram na cadeia tão cedo quanto 2016 e começaram a chamar a atenção em 2017. No entanto, não se tornaram a maior categoria históricaaté o Verão DeFi de 2020. Os contratos DeFi e DEX atingiram o pico de mais de 50% de crescimento histórico em vários momentos em 2021 e 2022.

Era de Rollup (Cinzento): No início de 2023, os Rollups da L2 começaram a executar consistentementemais transações do que a mainnet.Isso coincidiu com seus contratos gerando uma grande parte dos dados históricos, representando cerca de dois terços do crescimento histórico do Ethereum nos meses que antecederam Dencun.

Cada era representa padrões de uso cada vez mais complexos no Ethereum. Com o tempo, essa complexidade pode ser vista como uma forma de escalabilidade do Ethereum, não capturada por métricas simples como transações por segundo.

Nos dados mais recentes (abril de 2024), os rollups já não geram a maioria dos registos históricos. Não está claro se o crescimento histórico futuro será dominado por DEX e DeFi ou se surgirão novos padrões de utilização.

E sobre blobs?

A introdução de blobs no hard fork Dencun alterou significativamente a dinâmica de crescimento histórico, permitindo que os Rollups usem blobs baratos em vez de registros históricos para publicar dados. A Figura 4 amplia a taxa de crescimento histórico em torno da data da atualização Dencun. Este gráfico é semelhante à Figura 2, mas cada barra vertical representa um dia em vez de um mês.

Várias conclusões-chave podem ser tiradas deste gráfico:

O Crescimento Histórico dos Rollups Diminuiu Cerca de Dois Terços Desde Dencun: A maioria dos rollups mudou de usar dados de chamada para blobs, reduzindo significativamente a quantidade de dados históricos que geram. No entanto, em abril de 2024, alguns rollupsainda não mudaram de dados de chamada para blobs.

O Crescimento Histórico Total Diminuiu Cerca de Um Terço Desde Dencun: Dencun reduziu principalmente o crescimento histórico dos rollups. O crescimento histórico de outras categorias de contratos aumentou ligeiramente. Mesmo após Dencun, o crescimento histórico continua cerca de oito vezes o crescimento do estado (detalhes na próxima secção).

Apesar da redução no crescimento histórico, os blobs continuam a ser uma nova adição ao Ethereum. Atualmente, não está claro onde o crescimento histórico se estabilizará na presença de blobs.

Quanto Crescimento Histórico É Aceitável?

Aumentar o limite de gás aumentará a taxa de crescimento histórico. Portanto, propostas para aumentar o limite de gás (como Bombear o Gás) é necessário considerar a relação entre o crescimento histórico e os gargalos de hardware em cada nó.

Para determinar uma taxa de crescimento histórico aceitável, é útil examinar primeiro por quanto tempo as redes de nós modernas e o hardware de nós de armazenamento podem sustentar o estado atual. O hardware de rede pode sustentar o status quo indefinidamente porque as taxas de crescimento histórico dificilmente voltarão aos níveis pré-Dencun antes do aumento do limite de gás. No entanto, a carga de armazenamento de registros históricos aumenta ao longo do tempo. De acordo com as políticas de armazenamento atuais, a unidade de armazenamento de cada nó eventualmente será preenchida com histórico.

A Figura 5 ilustra o fardo de armazenamento dos nós do Ethereum ao longo do tempo e também prevê como esse fardo pode aumentar nos próximos 3 anos. As previsões são feitas usando as taxas de crescimento a partir de abril de 2024. Essa taxa pode aumentar ou diminuir no futuro devido a alterações nos padrões de uso ou limites de gás.

Várias conclusões-chave podem ser tiradas deste gráfico:

O espaço de armazenamento utilizado pela história é cerca de três vezes o do estado: Esta disparidade aumentará ao longo do tempo, uma vez que a taxa de crescimento da história é aproximadamente oito vezes a do estado.

Limiar Crítico em Torno de 1,8 TiB: Muitos nós serão obrigados a atualizar as suas unidades de armazenamento neste ponto. Uma unidade de 2TB, um tamanho comum, só fornece 1,8 TiB de espaço utilizável. Note que TB (terabytes) e TiB (tebibytes, = 1024^4 bytes) são unidades diferentes. Para muitos operadores de nós, o limiar crítico 'real' é ainda mais baixo porque os validadores devem executar um cliente de consenso juntamente com um cliente de execução pós-fusão.

Limite Alcançado em 2-3 Anos: Qualquer aumento no limite de gás acelerará este cronograma. Alcançar este limiar imporá um fardo significativo de manutenção aos operadores de nós, exigindo a compra de hardware adicional, como um $300 unidade NVME.

Armazenamento separado para dados históricos: Ao contrário dos dados de estado, os dados históricos são apenas acrescentados e acedidos com muito menos frequência. Portanto, teoricamente, poderiam ser armazenados separadamente dos dados de estado em suportes de armazenamento mais baratos. Alguns clientes, como Geth, já suporta essa separação.

A IO de rede como uma limitação de hardware: Além da capacidade de armazenamento, a IO de rede é outra restrição importante de hardware para o crescimento histórico. Ao contrário da capacidade de armazenamento, os limites de IO de rede não representarão problemas imediatos para os nós, mas se tornarão significativos para futuros aumentos do limite de gás.

Para entender até que ponto o crescimento histórico da capacidade de rede de um nó Ethereum típico pode suportar, é necessário descrever a relação entre o crescimento histórico e várias métricas de saúde da rede, como taxa de reorganização, falhas de slot, falta de finalidade, atestações em falta, falhas no comité de sincronização e atrasos na proposta de blocos. Analisar essas métricas está além do escopo deste artigo, mas pode ser encontrado em investigações anteriores sobre a saúde da camada de consenso [1] [2] [3].4]. Além disso, a Fundação Ethereum @ethpandaops/xatu-overview">O projeto Xatu tem vindo a construir conjuntos de dados públicos para facilitar tais análises.

Como Resolver o Crescimento Histórico?

O crescimento histórico é um problema mais fácil de abordar do que o crescimento do estado. O proposto EIP-4444resolve quase completamente esta questão. Este EIP altera o requisito para cada nó de reter toda a história do Ethereum para apenas reter um ano de história. Uma vez implementado o EIP-4444, mesmo com aumentos significativos no limite de gás a longo prazo, o armazenamento de dados deixará de ser um gargalo para a escalabilidade do Ethereum. O EIP-4444 é essencial para a sustentabilidade a longo prazo da rede, caso contrário, os dados históricos crescerão rapidamente o suficiente para necessitar de atualizações regulares de hardware para os nós da rede.

A Figura 6 mostra como o EIP-4444 afetaria a carga de armazenamento de cada nó nos próximos 3 anos. Isto é o mesmo que a Figura 4, com a adição de linhas mais finas representando a carga de armazenamento após a implementação do EIP-4444.

Várias conclusões importantes podem ser tiradas deste gráfico:

A EIP-4444 irá reduzir para metade o atual fardo de armazenamento: o fardo de armazenamento irá diminuir de 1,2 TiB para 633 GiB.

EIP-4444 Vai Estabilizar o Fardo de Armazenamento Histórico: Assumindo uma taxa constante de crescimento histórico, os dados históricos serão descartados à mesma taxa em que são gerados.

Após o EIP-4444, levará muitos anos para que o ônus de armazenamento atinja o nível de hoje: Isso ocorre porque o crescimento do estado, que é mais lento do que o crescimento histórico, será o único fator a aumentar o ônus de armazenamento.

EIP-4444 Ainda Imporá Alguma Sobrecarga de Armazenamento Devido a Um Ano de Dados Históricos: No entanto, essa carga será gerenciável mesmo se o Ethereum se expandir globalmente. Uma vez que o método de lidar com dados históricos se mostrar confiável, o período de retenção de um ano no EIP-4444 poderia ser reduzido para alguns meses, semanas ou até menos.

Como Preservar a História do Ethereum?

O EIP-4444 levanta a questão: se os próprios nós Ethereum não preservam o histórico, como deve ser preservado? O histórico é crucial para a verificação, contabilidade e análise do Ethereum, por isso deve ser preservado. Felizmente, preservar o histórico é simples, exigindo apenas 1/n de provedores de dados honestos, comparado com o problema de consenso de estado, que precisa de 1/3 a 2/3 de participantes honestos. Os operadores de nós podem verificar a autenticidade de qualquer conjunto de dados históricos através de: 1) repetir todas as transações desde o Genesis; e 2) verificar se essas transações reproduzem a mesma raiz de estado que a ponta da cadeia atual.

Existem vários métodos para preservar a história, cada um dos quais deve ser implementado em paralelo para maximizar as chances de preservação:

Torrents / P2P: Torrentssão o método mais simples e robusto. Os nós Ethereum podem periodicamente agrupar partes da história e partilhá-las como ficheiros torrent públicos. Por exemplo, um nó pode criar um novo ficheiro torrent de histórico a cada 100.000 blocos. Alguns clientes de nós, como o Erigon, já realizam este processo de forma não padronizada. Para padronizar este processo, todos os clientes de nós devem utilizar o mesmo formato de dados, parâmetros e rede P2P. Os nós podem optar por participar nesta rede com base na sua capacidade de armazenamento e largura de banda. A vantagem dos torrents é o uso de padrões abertos maduros suportados por um grande ecossistema de ferramentas de dados.

Portal Network: O Rede Portalé uma nova rede projetada especificamente para hospedar dados do Ethereum. Esta abordagem é semelhante aos torrents, mas oferece recursos adicionais para facilitar a verificação de dados. A vantagem da Rede Portal é que essas camadas adicionais de verificação oferecem aos clientes leves utilitários eficientes de verificação e consulta para conjuntos de dados compartilhados.

Hospedagem na Nuvem: Serviços de armazenamento na nuvem como AWSS3ou CloudflareR2oferecem opções baratas e de alto desempenho para preservar a história. No entanto, este método vem com mais riscos legais e operacionais de negócios, pois esses serviços de nuvem nem sempre estão dispostos ou são capazes de hospedar dados de criptomoeda.

Os desafios de implementação restantes são mais sociais do que técnicos. A comunidade Ethereum precisa de se coordenar nos detalhes de implementação específicos para que possam ser integrados diretamente em cada cliente de nó. Notavelmente, a sincronização total a partir do Génesis (em vez da sincronização instantânea) exigirá a obtenção de histórico de fornecedores de dados históricos em vez de nós Ethereum. Estas alterações não exigem um hard fork e podem ser implementadas antes do próximo hard fork do Ethereum, Pectra.

Os L2s também podem usar todos esses métodos para preservar os dados de blob que publicam na mainnet. A preservação do blob é 1) mais desafiadora devido ao maior volume total de dados; 2) menos crítica porque os blobs não são necessários para reproduzir o histórico da mainnet. No entanto, a preservação do blob é necessária para cada L2 reproduzir sua própria história. Portanto, algum tipo de preservação de blob é crucial para todo o ecossistema Ethereum. Além disso, se os L2s desenvolverem uma infraestrutura robusta de armazenamento de blob, também podem armazenar facilmente os dados históricos do L1.

Uma comparação direta dos conjuntos de dados armazenados por várias configurações de nós antes e depois do EIP-4444 é útil. A Figura 7 mostra o fardo de armazenamento dos tipos de nó do Ethereum. Os dados de estado incluem contas e contratos, os dados históricos incluem blocos e transações, e os dados de arquivo são um conjunto de índices de dados opcionais. As contagens de bytes na tabela são baseadas em instantâneos recentes do reth, mas as figuras devem ser aproximadamente comparáveis em outros clientes de nó.

Figura 7: Ônus de armazenamento dos tipos de nó Ethereum

Em linguagem,

1. Os nós de arquivo armazenam dados de estado, dados históricos e dados de arquivo. Eles são usados quando é necessária uma consulta fácil do estado da cadeia histórica.
2. Os nós completos armazenam apenas dados históricos e dados de estado. A maioria dos nós hoje são nós completos. O fardo de armazenamento dos nós completos é de cerca de metade do que o dos nós de arquivo.
3. Após EIP-4444, os nós completos apenas armazenarão dados de estado e os dados históricos do último ano. Isso reduzirá o fardo de armazenamento de 1,2 TiB para 633 GiB e estabilizará o uso de armazenamento para dados históricos.
4. Nós sem estado, também conhecidos como "nós leves", não armazenam nenhum desses conjuntos de dados e podem validar instantaneamente na ponta da cadeia. Este tipo de nó torna-se possível uma vez Verkle tentaou outros esquemas de compromisso estatal são adicionados ao Ethereum.

Finalmente, existem propostas adicionais de ecossistema que visam limitar a taxa de crescimento histórica em vez de apenas se adaptar à taxa atual. Estas são úteis para manter os limites de IO da rede a curto prazo e os limites de armazenamento a longo prazo. Embora o EIP-4444 seja essencial para a sustentabilidade a longo prazo da rede, esses outros EIPs ajudarão o Ethereum a escalar de forma mais eficiente no futuro:

EIP-7623: Esta proposta sugere reajustar os dados de chamada para que as transações com dados de chamada excessivos se tornem mais caras. Tornar esses padrões de uso mais caros incentivará alguns a mudar de dados de chamada para blobs, reduzindo assim a taxa de crescimento histórica.

EIP-4488: Esta proposta impõe limites sobre a quantidade total de dados de chamada que podem ser incluídos em cada bloco, aplicando um controle mais rigoroso sobre a taxa de crescimento histórico.

Estas EIPs são mais fáceis de implementar do que a EIP-4444 e podem servir como medidas provisórias antes que a EIP-4444 esteja pronta para produção.

Conclusão

O objetivo deste artigo é fornecer uma compreensão baseada em dados de como o crescimento histórico opera e como lidar com esse problema. Muitos dos dados apresentados neste artigo tradicionalmente têm sido de difícil acesso, por isso pretendemos oferecer novas perspetivas sobre o problema do crescimento histórico.

O crescimento histórico como um gargalo para a escalabilidade do Ethereum não tem recebido atenção suficiente. Mesmo sem aumentar os limites de gás, a prática atual de reter o histórico no Ethereum exigiria que muitos nós atualizassem seu hardware dentro de alguns anos. Felizmente, este não é um problema particularmente difícil de resolver. Soluções claras foram delineadas no EIP-4444. Acreditamos que deve haver uma aceleração na implementação deste EIP para abrir caminho para futuros aumentos nos limites de gás.

Se estiver interessado na investigação de escalabilidade do Ethereum, entre em contacto storm@paradigm.xyzegeorgios@paradigm.xyz.Gostaríamos de ouvir as suas perspetivas sobre esta questão e explorar potenciais colaborações. Os dados e o código utilizados neste artigo podem serencontrado emGithub.

Agradecimentos

Grande obrigado a Thomas Thiery、Equipe Beiko、Toni Wahrstaetter、Oliver NordbjergeRoman Krasiukpara a sua revisão e feedback. Obrigado a lAchal Srinivasanpara as figuras fornecidas na Figura 1 e Figura 7.

Aviso Legal：

1. Este artigo é reproduzido a partir de [ Marsbit]. Todos os direitos de autor pertencem ao autor original [Storm Slivkoff, Georgios Konstantopoulos]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles tratarão do assunto prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.