Vitalik Buterin, criador do Ethereum, anunciou o próximo passo da rede, que consiste em eliminar o excesso de recursos. Ele chama isso de "A Purga"
Na quinta postagem de sua série no blog, Vitalik apresentou um plano implacável para eliminar o inchaço do blockchain, remover recursos redundantes e simplificar o protocolo. A rede Ethereumestá congestionada com transações desatualizadas e recursos legados complexos.
A solução? Vitalik quer que os dados históricos e de estado sejam eliminados, os recursos do protocolo sejam simplificados e os nós sejam tornados mais fáceis de executar. Essa decisão ousada é uma resposta ao rápido crescimento de dados do Ethereum.
Atualmente, um nó completo Ethereum requer mais de 1,1 terabytes de armazenamento apenas para o cliente de execução, com mais espaço reservado para os dados de consenso.
Com o acúmulo de transações e contas, a necessidade de armazenamento aumenta, criando gargalos. Sem mudanças, Ethereum corre o risco de ficar lento, com novos clientes enfrentando tempos de sincronização extremamente longos apenas para se atualizarem com a blockchain.
Expiração do histórico: Reduzindo a carga de memória do Ethereum
Em vez de cada nó armazenar todas as transações já registradas, Vitalik sugere que os nós retenham apenas os dados recentes. Blocos históricos, transações mais antigas e recibos são distribuídos entre os nós em pequenas porções.
Para Vitalik, os dados históricos devem funcionar como uma rede torrent — os nós armazenam fragmentos de dados, garantindo a disponibilidade dos dados sem que um único nó detenha tudo. "Estamos falando de centenas de gigabytes de blocos antigos se acumulando a cada ano", disse ele.
O modelo atual, com os nós armazenando todos os dados, já foi ajustado. Os blocos de consenso, vitais para a prova de participação (proof-of-stake), são armazenados por seis meses, enquanto os blobs — blocos maiores de dados de transação — desaparecem após 18 dias.
A nova proposta de Vitalik, EIP-4444, defende um limite de armazenamento de um ano para blocos e recibos históricos. Seu objetivo final? Uma rede distribuída onde cada nó armazena apenas uma fração do histórico, usando provas de Merkle e codificação de apagamento para garantir a precisão.
Esse armazenamento de histórico distribuído não reduzirá a confiabilidade dos dados do Ethereum. Vitalik afirma que, ao aumentar o número de nós, as cópias de dados se multiplicarão pela rede, tornando cada fragmento do histórico bem fundamentado.
A codificação de apagamento adicionará resiliência, semelhante à tecnologia que ajuda os blobs a permanecerem disponíveis para amostragem de dados. Vitalik também aponta para a Portal Network e métodos ponto a ponto como possíveis soluções, permitindo que Ethereum gerencie a disseminação de seus dados sem depender de armazenamento centralizado.
Validade do estado: Limitar a permanência dos dados
Além do histórico, a limpeza de Vitalik inclui um problema mais complexo: a "expiração de estado". Ao contrário do histórico, os dados de estado (como saldos de contas, nonces e armazenamento detracinteligentes) são mais difíceis de expirar. Uma vez criado, um objeto de estado (como uma conta com ETH ou um slot de armazenamento de umtrac) permanece acessível a qualquer transação.
E com cada objeto, os dados do Ethereumaumentam. Para conter isso, Vitalik propõe a expiraçãomatic , eliminando os dados que não foram alterados recentemente. O desafio é equilibrar a expiração do estado com a permanência do Ethereum.
Ele acredita que os usuários deveriam poder "desaparecer por cinco anos, voltar e ainda ter acesso aos seus fundos". Esse sistema precisa de eficiência — sem cálculos extras ou modelos complexos para os desenvolvedores.
Ethereum tentou várias ideias, como o "aluguel de blockchain", que cobrava dos usuários para manter seus dados ativos, e a "regênese", que tentava redefinir o blockchain para reduzir o volume de dados. Nenhuma delas vingou.
Duas novas propostas visam combater o inchaço do estado. A primeira é a "expiração parcial do estado". A rede dividiria os dados em blocos, armazenando apenas os blocos recentes e preservando "stubs" (pequenos fragmentos de dados inativos) para comprovar sua existência.
Se um fragmento de dados for excluído, os usuários podem recuperá-lo com comprovantes de dados anteriores. A proposta de design de Vitalik, EIP-7736, utiliza árvores de Verkle e um modelo de "caule e folhas" para agrupar os dados. Quaisquer dados que permaneçam inalterados por seis meses são removidos, restando apenas um esboço para ser restaurado quando necessário.
A segunda ideia é a expiração baseada no período de endereço, que divide os objetos de estado por tempo. Cada conta tem um "período de endereço", e apenas os dados dos dois períodos mais recentes são armazenados.
Se alguém precisar de dados antigos, deverá enviar uma prova Merkle para restaurá-los. Essa configuração baseada em pontos exigirá a alteração dos formatos de endereço, expandindo o formato atual de 20 bytes para incluir números de versão e pontos.
Vitalik também sugere atracdo espaço de endereçamento para manter a compatibilidade. O desafio será, então, garantir que os usuários entendam e confiem nesse sistema de períodos sem sacrificar a promessa fundamental do Ethereumde disponibilidade.
Limpeza de funcionalidades: Reduzindo a complexidade do código do Ethereum
A fase final da purga atinge a complexidade do protocolo. Vitalik afirma: "Cada novo recurso torna Ethereum mais difícil de usar, mas remover qualquer coisa é um pesadelo". O exemplo mais infame é o SELFDESTRUCT, um opcode que permite aos usuários excluir o armazenamento detrac.
Originalmente, permitia a limpeza voluntária do estado, mas está praticamente sem uso e apresenta riscos de ataques de negação de serviço. O hard fork Dencun do Ethereumenfraqueceu o opcode, e Vitalik planeja removê-lo completamente em breve.
Outras funcionalidades problemáticas incluem tipos de transação antigos, formatos de dados redundantes e uma configuração de protocolo com endianness misto. Essas peculiaridades tornam o desenvolvimento confuso e dificultam as atualizações Ethereum .
A lista de melhorias propostas por Vitalik também inclui a transição dos formatos de dados de RLP para SSZ, a simplificação das regras de gás para melhor gerenciar os recursos de bloco e a remoção de pré-compilações não utilizadas, como RIPEMD160, MODEXP e BLAKE. Ele também apoia a migração Ethereum para um modelo de cliente sem estado, o que eliminaria a sobrecarga de armazenamento para a maioria dos nós.
Algumas dessas mudanças exigirãotracde contas, permitindo que os usuários lidem com tipos de transação legados por meio de "código EVM de conta padrão". Isso, segundo Vitalik, simplificará a Máquina Virtual Ethereum (EVM) e reduzirá o tamanho do código. A longo prazo, a própria EVM poderá receber uma atualização.
Ele explica que os desenvolvedores Ethereum estão considerando um novo modelo de execução, como o RISC-V ou o Cairo, ou possivelmente o uso de um formato de objeto EVM (EOF) para padronizar as regras de código.
O EOF altera as regras de gás e proíbe certas instruções para permitir atualizações modulares, aumentando a escalabilidade do Ethereum. Esse formato permitirá que os desenvolvedores façam melhorias incrementais, ajudando Ethereum a se manter enxuto.
Mas Vitalik apresentou outra opção. Ele disse : "Uma estratégia de simplificação mais radical Ethereum seria manter o protocolo como está, mas transferir grandes partes dele de funcionalidades do protocolo para trac ."
