Publicar

A Comunidade Ethereum Propõe Reduzir o Período de Retenção de Blocos da Camada de Consenso para 36 Dias



A comunidade Ethereum publicou uma Proposta de Melhoria do Ethereum (EIP) fundamental, que visa reduzir significativamente o período de retenção de blocos da camada de consenso, de aproximadamente 146 dias para cerca de 36,4 dias . Esta alteração proposta representa uma modificação informativa que não implica um fork e que não requer uma atualização da rede ou um hard fork para ser implementada . A proposta foi concebida para responder ao desafio crescente da expansão dos dados da blockchain, que tem vindo a aumentar as exigências de hardware impostas aos operadores de nós . Ao encurtar o período de retenção, a EIP pretende reduzir significativamente a largura de banda, o espaço em disco e o tempo necessários para o preenchimento retroativo de dados após a sincronização de checkpoints, ajudando a preservar a descentralização da Ethereum ao tornar a operação de nós mais acessível . Esta melhoria técnica reflecte os esforços contínuos para optimizar a infraestrutura da Ethereum e melhorar a eficiência operacional dos nós.
Ver original
post-image
Esta página contém conteúdo de terceiros e não constitui qualquer aconselhamento, nem representa a aprovação destas opiniões pela Gate. Para mais detalhes, consulte a isenção de responsabilidade.
ETHETH-0,72%

  • 2

Adicionar um comentário
Adicionar um comentário

Comentar
SeedPhraseAmnesia
21-08-2026
Uma alteração ao nível da informação sem fork parece uma otimização de baixo custo, mas, na prática, os nós antigos poderão ter problemas de compatibilidade durante a implementação?
0Ver original
LiquidSniper
19-08-2026
Esta proposta de 36 dias é bastante pragmática e reduz bastante a pressão sobre o armazenamento dos nós, mas espero que a eficiência da sincronização não seja comprometida.
0Ver original
OptionWave
19-08-2026
É claro que a redução do espaço ocupado em disco é uma coisa boa, mas passar de 146 para 36 dias não tornará mais difícil consultar dados históricos? Os clientes leves e os nós de arquivo não deverão ser afetados, certo?
0Ver original
SpikeGuard
19-08-2026
Finalmente alguém está a tratar das necessidades de armazenamento dos nós completos. Antes, sincronizar uma vez exigia descarregar centenas de GB, o que era mesmo desmotivador. Que venham mais alterações destas.
0Ver original
MacroScope
19-08-2026
Como operador de um nó, esta alteração é muito apelativa: permite poupar bastante largura de banda e espaço em disco. Só não sei se terá efeitos secundários no serviço de snapshots.
1Ver original
Ver mais
DividendRetire
19-08-2026
Ao reduzir a janela de retenção para 36 dias, a minha primeira reação foi: quem ficará responsável por guardar os dados anteriores? Isso significa que, no futuro, só poderemos consultar blocos antigos através de serviços de terceiros?
1Ver original
Ver mais
DepositBouncer
19-08-2026
A abordagem do EIP é bastante clara: trocar tempo por espaço; afinal, depois de sincronizar o checkpoint, basta recorrer ao histórico. Mas, como condição prévia, a rede tem de ter nós de arquivo suficientes; caso contrário, as lacunas no histórico podem tornar-se problemáticas.
1Ver original
Ver mais
TwoFactorZen
19-08-2026
Otimizar a infraestrutura é positivo, mas não transformem a descentralização numa dependência de indexadores centralizados apenas para reduzir a barreira de entrada. Esperemos que sejam apresentadas soluções complementares posteriormente.
1Ver original
Ver mais
GasWizard
19-08-2026
Primeira análise
A diferença entre 36 e 146 dias é bastante grande; parece que estão a apostar que toda a gente fará sincronizações periódicas? No entanto, não foram dados muitos pormenores técnicos, por isso vou aguardar para ver o que se discute na comunidade.
0Ver original
Ver mais