O que é Crescimento Histórico?

A história no Ethereum é composta por todos os blocos e transações executadas ao longo de sua vida. Esses dados são necessários para sincronizar a cadeia desde o bloco de gênese até 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. Esse crescimento pressiona a E/S da rede porque novos blocos e transações devem 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, consulte Parte 1desta série.

Figura 1: Ethereum gargalo de expansão

Até recentemente, a maior parte da largura de banda da rede de cada nó era usada para transmitir registros históricos (por exemplo, novos blocos e transações). Isso mudou com a introdução de blobs no Dencunhard fork. Blobs now constitute a significant portion of node network activity. However, blobs are not considered part of the historical record because 1) nodes store them for only 2 weeks before discarding them, and 2) they are not required for replaying the chain from Genesis. Due to (1), blobs do not significantly increase the storage burden on each Ethereum node. We will discuss blobs in more detail later in this article.

Neste artigo, vamos focar no crescimento de dados históricos e sua relação com o crescimento do estado. Como o crescimento do estado e o crescimento histórico compartilham 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 gênese 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 naquele mês. As transações são categorizadas pelo seu "endereço de destino" e seu tamanho é determinado usando seu RLPrepresentaçã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 tiradas deste gráfico:

1. A Taxa de Crescimento Histórico é Cerca de 6 a 8 Vezes Mais Rápida do que a Taxa de Crescimento do Estado: O crescimento histórico atingiu recentemente o pico de 36,0 GiB/mês e atualmente está em 19,3 GiB/mês. O crescimento do estado atingiu 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 do estado, tanto em termos de taxa quanto de tamanho acumulado, pode ser encontrada mais adiante neste artigo.
2. A taxa de crescimento histórica estava acelerando rapidamente antes de Dencun: enquanto o crescimento do estado tem sido aproximadamente linear ao longo dos anos (ver Parte 1) , o crescimento histórico tem sido superlinear. O crescimento linear resulta em um aumento quadrático no tamanho geral, enquanto o crescimento superlinear resulta em um aumento mais rápido do que quadrático. Essa 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 provém principalmente dos Rollups: Cada L2 envia uma cópia de suas transações de volta para a mainnet, gerando uma quantidade significativa de dados históricos e fazendo dos rollups o maior contribuinte para o crescimento histórico ao longo do último ano. No entanto, o Dencun permite que os L2s usem blobs em vez de registros históricos para enviar seus dados de transação, fazendo com que os rollups não gerem mais a maioria dos registros históricos do Ethereum. Vamos examinar os rollups com mais detalhes mais adiante 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 utiliza os mesmos dados que a Figura 2, normalizados para 100%.

Os dados revelam quatro períodos distintos de padrões de uso do Ethereum:

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

Era ERC-20 (Verde): O padrão ERC-20foi finalizado no final de 2015, mas só ganhou significativa tração em 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 como 2016 e começaram a chamar a atenção em 2017. No entanto, eles não se tornaram a maior categoria históricaaté o Verão DeFi de 2020. Os contratos DeFi e DEX atingiram picos de mais de 50% de crescimento histórico em vários momentos em 2021 e 2022.

Era Rollup (Cinza): No início de 2023, os Rollups L2 começaram a ser executados de forma consistentemais 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 o 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 escalonamento do Ethereum, não capturada por métricas simples como transações por segundo.

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

E quanto aos blobs?

A introdução de blobs no hard fork Dencun alterou significativamente a dinâmica do crescimento histórico, permitindo que Rollups usem blobs baratos em vez de registros históricos para postar 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 importantes podem ser tiradas deste gráfico:

O Crescimento Histórico a partir 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, a partir de abril de 2024, alguns rollupsainda não mudei 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 permanece cerca de oito vezes maior do que o crescimento do estado (detalhes na próxima seção).

Apesar da redução no crescimento histórico, os blobs continuam sendo 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órica. Portanto, propostas para aumentar o limite de gás (como Bombear o Gásdeve considerar a relação entre o crescimento histórico e os gargalos de hardware em cada nó.

Para determinar uma taxa de crescimento histórica aceitável, é útil primeiro examinar 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, pois as taxas de crescimento históricas provavelmente não voltarão aos níveis anteriores ao aumento do limite de gás. No entanto, a carga de armazenamento de registros históricos aumenta com o tempo. De acordo com as políticas de armazenamento atuais, o disco de armazenamento de cada nó eventualmente será preenchido com histórico.

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

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

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

Limiar crítico em torno de 1,8 TiB: Muitos nós serão obrigados a atualizar seus discos de armazenamento neste ponto. Um disco de 2 TB, tamanho comum, fornece apenas 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 menor, porque os validadores devem executar um cliente de consenso juntamente com um cliente de execução pós-fusão.

Limite atingido em 2-3 anos: Qualquer aumento no limite de gás acelerará este cronograma. Alcançar este limite imporá uma carga significativa de manutenção aos operadores de nós, necessitando a aquisição 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 para acréscimos e são acessados com muito menos frequência. Portanto, teoricamente, poderiam ser armazenados separadamente dos dados de estado em mídias de armazenamento mais baratas. Alguns clientes, como Geth, já suporta essa separação.

Entrada da Rede como uma Limitação de Hardware: Além da capacidade de armazenamento, a entrada da rede é outra restrição importante de hardware para o crescimento histórico. Ao contrário da capacidade de armazenamento, os limites de entrada da 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 o quanto de crescimento histórico a 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 finalização, atestações ausentes, falhas do comitê de sincronização e atrasos na proposta de bloco. 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 construído 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 propostoEIP-4444quase resolve completamente esse problema. Este EIP altera o requisito para cada nó de reter toda a história do Ethereum para reter apenas um ano de história. Uma vez que o EIP-4444 é implementado, mesmo com aumentos significativos no limite de gás a longo prazo, o armazenamento de dados não será mais um gargalo para a escalabilidade do Ethereum. O EIP-4444 é essencial para a sustentabilidade de longo prazo da rede, caso contrário, os dados históricos crescerão rapidamente o suficiente para exigir atualizações regulares de hardware para os nós da rede.

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

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

EIP-4444 Vai Reduzir pela Metade o Atual Ônus de Armazenamento: O ônus de armazenamento diminuirá de 1,2 TiB para 633 GiB.

EIP-4444 Estabilizará o Ônus de Armazenamento Histórico: Supondo uma taxa constante de crescimento histórico, os dados históricos serão descartados na mesma taxa em que são gerados.

Após o EIP-4444, levará muitos anos para que o ônus de armazenamento alcance 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 Carga de Armazenamento Devido a Um Ano de Dados Históricos: No entanto, essa carga será gerenciável mesmo que o Ethereum se expanda 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 nós Ethereum em si não preservam o histórico, como ele deve ser preservado? A história é crucial para a verificação, contabilidade e análise do Ethereum, portanto, deve ser preservada. Felizmente, preservar a história é simples, exigindo apenas 1/n provedores de dados honestos, em comparação com o problema de consenso de estado, que precisa de 1/3 a 2/3 participantes honestos. Os operadores de nós podem verificar a autenticidade de qualquer conjunto de dados históricos, reproduzindo todas as transações desde o Genesis e verificando se essas transações reproduzem a mesma raiz de estado que a ponta da cadeia atual.

Existem múltiplos 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 do Ethereum podem empacotar periodicamente partes da história e compartilhá-las como arquivos torrent públicos. Por exemplo, um nó pode criar um novo arquivo torrent de história a cada 100.000 blocos. Alguns clientes de nós, como Erigon, já realizam esse processo de forma não padronizada. Para padronizar esse processo, todos os clientes de nós devem usar o mesmo formato de dados, parâmetros e rede P2P. Os nós podem optar por participar dessa rede com base em 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.

Rede Portal: O Portal Networké 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 Portal Network é que essas camadas extras 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 em nuvem como AWSS3ou CloudflareR2oferecem opções baratas e de alto desempenho para preservar a história. No entanto, esse método vem com mais riscos legais e operacionais de negócios, pois esses serviços em nuvem nem sempre podem estar dispostos ou aptos a hospedar dados de criptomoedas.

Os desafios de implementação restantes são mais sociais do que técnicos. A comunidade do Ethereum precisa coordenar 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 Genesis (em vez da sincronização de snapshot) exigirá a recuperação de histórico de provedores de dados históricos em vez de nós do Ethereum. Essas mudanças 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 blob que publicam na mainnet. A preservação de blobs é 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 a história da mainnet. No entanto, a preservação de blobs é necessária para que cada L2 reproduza sua própria história. Portanto, algum tipo de preservação de blobs é crucial para todo o ecossistema Ethereum. Além disso, se os L2s desenvolverem uma infraestrutura robusta de armazenamento de blobs, eles 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 os números devem ser aproximadamente comparáveis em outros clientes de nó.

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

Em linguagem,

1. Nós de arquivamento armazenam dados de estado, dados históricos e dados de arquivamento. 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 ônus de armazenamento dos nós completos é de cerca de metade do dos nós de arquivo.
3. Após EIP-4444, os nós completos só irão armazenar 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. Esse tipo de nó se torna possível uma vez Verkle tentaou outros esquemas de compromisso de estado são adicionados ao Ethereum.

Finalmente, há 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 E/S da rede a curto prazo e os limites de armazenamento a longo prazo. Enquanto o EIP-4444 é 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 a repricing de dados de chamada para que 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 à quantidade total de dados de chamadas que podem ser incluídos em cada bloco, aplicando um controle mais rigoroso sobre a taxa de crescimento histórico.

Esses EIPs são mais fáceis de implementar do que o EIP-4444 e podem servir como medidas intermediárias antes que o EIP-4444 esteja pronto para produção.

Conclusão

O objetivo deste artigo é oferecer uma compreensão baseada em dados de como o crescimento histórico opera e como abordar essa questão. Grande parte dos dados apresentados neste artigo tem tradicionalmente sido de difícil acesso, então pretendemos oferecer novas perspectivas sobre o problema do crescimento histórico.

O crescimento histórico como um gargalo para a escalabilidade do Ethereum não recebeu 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 dar espaço para futuros aumentos nos limites de gás.

Se você estiver interessado em pesquisa de escalabilidade do Ethereum, por favor entre em contato storm@paradigm.xyzegeorgios@paradigm.xyz.Gostaríamos de ouvir suas perspectivas sobre essa questão e explorar possíveis colaborações. Os dados e o código usados neste artigo podem ser encontrado emGithub.

Agradecimentos

Grande agradecimento aThomas Thiery、Equipe Beiko、Toni Wahrstaetter、Oliver NordbjergeRoman Krasiukpara a revisão e feedback deles. Obrigado a lAchal Srinivasanpara os números fornecidos na Figura 1 e Figura 7.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Marsbit]. Todos os direitos autorais pertencem ao autor original [Storm Slivkoff, Georgios Konstantopoulos]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.