O possível futuro do Ethereum: The Purge

Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain aumentam com o tempo. Isso acontece em dois lugares: dados históricos e funcionalidades do protocolo. Para que o Ethereum possa se manter a longo prazo, precisamos aplicar uma forte pressão contrária a essas duas tendências, diminuindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos preservar uma das principais características que tornam a blockchain grandiosa: a persistência.

O principal objetivo de The Purge:

• Reduzir os requisitos de armazenamento do cliente, eliminando ou reduzindo a necessidade de cada nó armazenar permanentemente todos os históricos, até mesmo o estado final.
• Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.

Expiração do histórico

Resolve que problema?

Até o momento da redação deste artigo, um nó Ethereum totalmente sincronizado requer cerca de 1,1 TB de espaço em disco para executar o cliente, além de centenas de GB de espaço em disco para o cliente de consenso. A maior parte disso é histórica: dados sobre blocos antigos, transações e recibos, a maior parte dos quais tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente, o tamanho do nó continuará a crescer em centenas de GB a cada ano.

O que é isso, como funciona?

Uma característica chave da simplificação do problema de armazenamento histórico é que, como cada bloco está ligado ao bloco anterior por meio de hash ( e outras estruturas ), é suficiente alcançar consenso sobre o atual para alcançar consenso sobre o histórico. Desde que a rede alcance consenso sobre o bloco mais recente, qualquer bloco, transação ou estado histórico (, como saldo de conta, números aleatórios, código, armazenamento ), pode ser fornecido por qualquer participante individual, juntamente com a prova Merkle, e essa prova permite que qualquer outra pessoa verifique sua correção. O consenso é um modelo de confiança N/2-of-N, enquanto o histórico é um modelo de confiança N-of-N.

Isto nos oferece muitas opções sobre como armazenar registros históricos. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados. Esta é a forma como as redes de sementes operam há décadas: embora a rede armazene e distribua milhões de arquivos no total, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contrariando a intuição, este método nem sempre diminui a robustez dos dados. Se, ao tornar a operação dos nós mais económica, conseguirmos estabelecer uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% dos registros históricos, então cada dado será copiado 10.000 vezes - exatamente o mesmo fator de cópia que uma rede de 10.000 nós, onde cada nó armazena todo o conteúdo.

Agora, o Ethereum começou a se livrar do modelo de armazenamento permanente de todo o histórico por todos os nós. O bloco de consenso ( está relacionado à parte do consenso de prova de participação que armazena apenas cerca de 6 meses. O Blob armazena apenas cerca de 18 dias. O EIP-4444 visa introduzir um período de armazenamento de um ano para blocos e recibos históricos. O objetivo a longo prazo é estabelecer um período unificado ) que pode ser de cerca de 18 dias (, durante o qual cada nó é responsável por armazenar todo o conteúdo, e então estabelecer uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de forma distribuída.

Os códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. Na verdade, o Blob já utilizou códigos de apagamento para suportar a amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de apagamento e colocar também os dados de execução e de bloco de consenso dentro do blob.

![Vitalik: O futuro potencial do Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(

) ainda precisa fazer o quê, precisa ponderar o quê?

O trabalho principal restante inclui a construção e integração de uma solução distribuída concreta para armazenar o histórico ------ pelo menos o histórico de execução, mas eventualmente também incluirá consenso e blob. A solução mais simples é ###i( simplesmente introduzir uma biblioteca torrent existente, bem como )ii( chamada de solução nativa de Ethereum conhecida como Portal Network. Assim que qualquer uma delas for introduzida, poderemos ativar o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente necessita de uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo simultaneamente para todos os clientes, caso contrário, há o risco de os clientes falharem devido à conexão com outros nós que esperam baixar o histórico completo, mas na verdade não o obtêm.

As principais considerações envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar dados históricos antigos amanhã e confiar nos nós de arquivamento existentes e em vários provedores centralizados para replicação. Isso é fácil, mas enfraquece a posição do Ethereum como um local de registro permanente. Um caminho mais difícil, mas mais seguro, é primeiro construir e integrar uma rede torrent para armazenar o histórico de forma distribuída. Aqui, "o quanto nos esforçamos" tem duas dimensões:

1. Como nos esforçamos para garantir que o maior conjunto de nós realmente armazene todos os dados?

2. Quão profunda é a integração do armazenamento histórico no protocolo?

Uma abordagem extremista para )1( envolveria a prova de custódia: exigindo efetivamente que cada validador de prova de participação armazenasse uma certa proporção de histórico e verificasse regularmente, de forma criptografada, se o faz. Uma abordagem mais moderada seria estabelecer um padrão voluntário para a porcentagem de histórico armazenado por cada cliente.

Para )2(, a implementação básica envolve apenas o trabalho que já foi concluído hoje: o Portal já armazenou arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais completa envolverá a conexão real ao processo de sincronização, de modo que, se alguém quiser sincronizar um nó de armazenamento de histórico completo ou um nó de arquivo, mesmo que não haja outros nós de arquivo online, eles possam alcançá-lo através da sincronização direta da rede do Portal.

) Como isso interage com outras partes do roteiro?

Se quisermos que a execução ou o início de um nó se torne extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a sem estado: dos 1,1 TB necessários para o nó, cerca de 300 GB são estado, enquanto os restantes aproximadamente 800 GB tornaram-se históricos. Apenas alcançando a sem estado e o EIP-4444, é que se poderá concretizar a visão de executar um nó Ethereum em um smartwatch e configurá-lo em apenas alguns minutos.

A limitação do armazenamento histórico também torna a implementação de nós Ethereum mais viável, suportando apenas a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é possível remover com segurança muitas linhas de código, uma vez que todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Agora que a transição para a prova de participação se tornou história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.

![Vitalik: O possível futuro do Ethereum, The Purge]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(

Expiração do estado

) Resolve que problema?

Mesmo que eliminemos a necessidade de armazenamento de histórico no cliente, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a aumentar: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, que irá sobrecarregar os clientes de Ethereum, tanto agora quanto no futuro.

O estado é mais difícil de "expirar" do que o histórico, porque o EVM foi projetado fundamentalmente em torno da suposição de que, uma vez criado um objeto de estado, ele sempre existirá e poderá ser lido a qualquer momento por qualquer transação. Se introduzirmos a ausência de estado, alguns acreditam que esse problema talvez não seja tão ruim: apenas classes especializadas de construtores de blocos precisam realmente armazenar o estado, enquanto todos os outros nós ###, até mesmo aqueles que geram listas! (, podem funcionar sem estado. No entanto, há um ponto de vista que acredita que não queremos depender demais da ausência de estado, e que, no final, poderíamos querer fazer o estado expirar para manter a descentralização do Ethereum.

) O que é, como funciona

Hoje, quando você cria um novo objeto de estado, ### pode ocorrer de uma das seguintes três maneiras: ( i ( enviando ETH para uma nova conta, ) ii ( criando uma nova conta usando código, ) iii ( configurando um slot de armazenamento que nunca foi acessado antes ), esse objeto de estado permanece nesse estado para sempre. Em vez disso, o que queremos é que o objeto expire automaticamente ao longo do tempo. O desafio principal é fazer isso de uma maneira que atinja os três objetivos:

• Eficiência: não requer um grande número de cálculos adicionais para executar o processo de vencimento.

• Facilidade de uso: Se alguém entrar na caverna por cinco anos e voltar, não deve perder o acesso às posições de ETH, ERC20, NFT e CDP...

• Amizade com os desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento completamente desconhecido. Além disso, aplicações que atualmente estão rígidas e não atualizadas devem continuar a funcionar normalmente.

Não satisfazer esses objetivos torna fácil resolver problemas. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador de data de expiração ) que pode ser estendido queimando ETH, o que pode ocorrer automaticamente a qualquer momento de leitura ou gravação (, e há um processo que percorre o estado para remover os objetos de estado com data de expiração. No entanto, isso introduz uma necessidade extra de computação ) e até mesmo de armazenamento (, e certamente não pode atender aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre os casos extremos que envolvem valores de armazenamento que às vezes são redefinidos para zero. Se você definir um temporizador de expiração dentro do escopo do contrato, isso tecnicamente tornará a vida dos desenvolvedores mais fácil, mas tornará a economia mais difícil: os desenvolvedores devem considerar como "transmitir" os custos contínuos de armazenamento para os usuários.

Estes são problemas que a comunidade de desenvolvedores centrais do Ethereum tem trabalhado para resolver ao longo dos anos, incluindo propostas como "aluguel de blockchain" e "regeneração". No final, combinámos as melhores partes das propostas e concentrámo-nos em duas categorias de "soluções conhecidas como as menos más":

• Solução para parte dos estados expirados
• Sugestões de expiração de estado baseadas no ciclo de endereços.

![Vitalik: O possível futuro do Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp(

)# Expiração parcial do estado

Propostas de estado de parte do tempo de expiração seguem os mesmos princípios. Nós dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de nível superior", onde os blocos podem estar vazios ou não. Os dados em cada bloco só serão armazenados se forem acessados recentemente. Existe um mecanismo de "ressurreição" que, se não estiver mais armazenado.

A principal diferença entre essas propostas é: ### i ( como definimos "recente", e ) ii ( como definimos "bloco"? Uma proposta concreta é a EIP-7736, que se baseia no design de "folhas" introduzido para a árvore Verkle ), embora seja compatível com qualquer forma de estado sem estado, como a árvore binária (. Neste design, os cabeçalhos, código e slots de armazenamento adjacentes são armazenados sob o mesmo "tronco". Os dados armazenados sob um tronco podem ter no máximo 256 * 31 = 7.936 bytes. Em muitos casos, todo o cabeçalho e código da conta, bem como muitos slots de armazenamento de chaves, serão armazenados sob o mesmo tronco. Se os dados sob o tronco dado não forem lidos ou gravados em 6 meses, esses dados não serão mais armazenados, mas apenas o compromisso de 32 bytes desses dados ) "tronco" (. As transações futuras que acessarem esses dados precisarão "reviver" os dados e fornecer uma prova de verificação com base no tronco.

Há outras maneiras de realizar ideias semelhantes. Por exemplo, se o nível de granularidade da conta não for suficiente, podemos elaborar um esquema em que cada 1/232 da árvore seja controlado por um mecanismo de folhas e caules semelhante.

Devido a fatores de incentivo, isso se torna mais complicado: atacantes podem "atualizar a árvore" colocando uma grande quantidade de dados em uma única subárvore e enviando uma única transação por ano, forçando o cliente a armazenar permanentemente um grande estado. Se você tornar o custo de renovação proporcional ao tamanho da árvore ) ou inversamente proporcional à duração da renovação (, então alguém pode prejudicar outros usuários colocando uma grande quantidade de dados na mesma subárvore que eles. As pessoas podem tentar limitar esses dois problemas dinamicando a granularidade com base no tamanho da subárvore: por exemplo, cada 216= 65536 objetos de estado consecutivos podem ser considerados um "grupo". No entanto, essas ideias são mais complexas; a abordagem baseada em caule é simples e pode ajustar os incentivos, pois geralmente o caule.