Expiração do Histórico Pré-Merge
Todos os clientes de Execução agora suportam expiração parcial de histórico de acordo com EIP-4444. Os usuários podem reduzir substancialmente
os requisitos de armazenamento para seu nó removendo o histórico de blocos pré-merge começando na versão v1.17.0 do Smartnode. Fique à vontade para conferir
esta postagem do blog para saber mais sobre expiração parcial de histórico: https://blog.ethereum.org/2025/07/08/partial-history-exp
Tenha em mente que as etapas para remover o histórico pré-merge dependem do cliente de Execução selecionado do seu nó:
- Usuários do Nethermind precisarão fazer uma ressincronização completa para remover o histórico pré-merge.
- Usuários do Geth podem usar o comando
rocketpool service prune-eth1ou fazer uma ressincronização completa. - Usuários do Besu e Reth podem realizar uma poda online enquanto seu nó continua a atestar.
As etapas a seguir para remover o histórico pré-merge são apenas para nós no modo Docker. Se você estiver usando um cliente externo no modo Hybrid ou modo Native, consulte a documentação fornecida pelo seu cliente de Execução.
Comece abrindo o Gerenciador de Configurações:
Para alterar o modo de poda do Cliente de Execução, vá ao menu Execution Client (ETH1) e selecione a configuração History Expiry no menu suspenso para Pruning Mode

Depois de fazer a seleção, pressione escape para retornar ao menu principal, depois pressione tab para destacar o botão Review Changes and Save. Pressione
a tecla enter para continuar. Você verá um menu para visualizar as alterações nas configurações do seu cliente de Execução.

Pressione a tecla enter em Save Settings para salvar e sair do Gerenciador de Configurações, depois digite y para reiniciar seu contêiner rocketpool_eth1.
A partir deste ponto, as etapas diferem dependendo de qual cliente de Execução você está usando:
Nós Nethermind requerem uma ressincronização completa para remover o histórico pré-merge. Você deve ressincronizar seu cliente de Execução após salvar
a configuração History Expiry e reiniciar seu contêiner eth1.
Se você não tiver um nó de fallback configurado, seu nó vai parar de validar durante uma ressincronização. Um nó de fallback permitirá que seu nó primário continue atestando e propondo blocos durante uma poda ou ressincronização. Clique aqui para aprender como configurar um nó de fallback.
Use o seguinte comando para ressincronizar seu cliente de Execução:
Pronto! O nó não armazenará mais dados pré-merge, melhorando substancialmente a viabilidade de colocar um nó em um drive de 2 TB. Recomendamos monitorar o progresso usando o seguinte comando.