O possível futuro do Ethereum: A Purga

Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain tendem a aumentar ao longo do tempo. Isso ocorre em dois lugares:

Dados históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história devem ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, a fim de se sincronizar completamente com a rede. Isso resultará em um aumento contínuo da carga dos clientes e do tempo de sincronização ao longo do tempo, mesmo que a capacidade da cadeia permaneça inalterada.

Função do protocolo: adicionar novas funções é muito mais fácil do que remover funções antigas, resultando em uma complexidade de código que aumenta com o tempo.

Para que o Ethereum possa manter-se a longo prazo, precisamos exercer uma forte pressão contrária a essas duas tendências, reduzindo a complexidade e a expansão ao longo do tempo. Mas, ao mesmo tempo, precisamos preservar uma das propriedades-chave que tornam a blockchain grandiosa: a persistência. Você pode colocar um NFT, uma carta de amor em dados de chamada de transação, ou um contrato inteligente contendo 1 milhão de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ainda está lá, esperando por você para ler e interagir. Para que as DApps possam descentralizar-se completamente e remover as chaves de atualização com confiança, precisam ter certeza de que suas dependências não serão atualizadas de maneira a comprometer sua integridade - especialmente a L1 em si.

Se decidirmos equilibrar essas duas demandas e minimizar ou reverter a gordura, a complexidade e o declínio enquanto mantemos a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma vida extremamente longa. Em certos casos, Ethereum já teve sucesso: a prova de trabalho desapareceu, o código de operação SELFDESTRUCT desapareceu na maior parte, e os nós da cadeia de beacon armazenaram dados antigos por até seis meses. Encontrar esse caminho para Ethereum de uma maneira mais genérica e caminhar em direção a um resultado final estável a longo prazo é o desafio definitivo para a escalabilidade a longo prazo, a sustentabilidade técnica e até mesmo a segurança do Ethereum.

The Purge: Principal objetivo.

Reduzir os requisitos de armazenamento do cliente ao diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os registros históricos ou mesmo o estado final.

Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.

Índice do artigo:

História de expiração

Expiração do estado

Limpeza de funcionalidades

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 históricos, transações e recibos, a maioria dos quais tem vários anos. Isso significa que mesmo que o limite de Gas não aumente, o tamanho do nó continuará a aumentar 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 hashes ( e outras estruturas ), basta que haja consenso sobre o atual para que haja consenso sobre o histórico. Desde que a rede atinja consenso sobre o último bloco, qualquer bloco histórico, transação ou estado (, saldo de conta, número aleatório, 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.

Isso nos oferece muitas opções sobre como armazenar registros históricos. Uma escolha natural é uma rede em que cada nó armazena apenas uma pequena parte dos dados. É assim que as redes de sementes funcionaram por décadas: embora a rede armazene e distribua milhões de arquivos, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contra a intuição, esse método pode até não reduzir a robustez dos dados. Se, ao tornar a operação dos nós mais econômica, pudermos construir uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% dos registros históricos, então cada dado será replicado 10.000 vezes - exatamente o mesmo fator de replicação de uma rede de 10.000 nós, onde cada nó armazena tudo.

Atualmente, o Ethereum começou a se desvincular do modelo em que todos os nós armazenam permanentemente todo o histórico. O bloco de consenso ( está relacionado à parte do consenso de prova de participação, armazenando 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 históricos e recibos. O objetivo de longo prazo é estabelecer um período unificado, ) pode ser de cerca de 18 dias, durante o qual cada nó é responsável por armazenar todo o conteúdo, e então criar uma rede peer-to-peer composta por nós do Ethereum, armazenando dados antigos de forma distribuída.

Códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já foi codificado para suportar a amostragem de disponibilidade de dados. A solução mais simples pode ser reutilizar esses Códigos de apagamento e também colocar os dados de execução e de consenso em blob.

( tem alguma relação com a pesquisa existente?

EIP-4444;

Torrents e EIP-4444;

Portal de rede;

Portal Network e EIP-4444;

Armazenamento e recuperação distribuídos de objetos SSZ no Portal;

Como aumentar o limite de gas.

) O que mais precisa ser feito, o que precisa ser ponderado?

O trabalho principal restante inclui a construção e integração de uma solução distribuída específica para armazenar registros históricos------pelo menos os registros de execução, mas eventualmente também incluindo consenso e blob. A solução mais simples é ###i### simplesmente introduzir uma biblioteca torrent existente, bem como (ii) denominada solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer uma delas seja introduzida, podemos ativar o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente precisa de uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo ao mesmo tempo para todos os clientes, caso contrário, existe o risco de falha do cliente devido à conexão com outros nós que esperam baixar o registro 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 arquivo 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. A abordagem mais difícil, mas mais segura, é primeiro construir e integrar uma rede torrent para armazenar o histórico de forma distribuída. Aqui, "quão duro nós nos esforçamos" tem duas dimensões:

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

Qual é a profundidade da integração do armazenamento histórico no protocolo?

Um método extremamente paranoico para (1) envolveria a prova de custódia: na prática, exigindo que cada validador de prova de participação armazenasse uma certa proporção de registros históricos e os verificasse regularmente de forma criptografada para garantir que o fizessem. Um método mais brando seria estabelecer um padrão voluntário para a percentagem 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 um arquivo ERA que contém toda a história do Ethereum. Uma implementação mais completa envolverá realmente conectá-lo ao processo de sincronização, assim, 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 poderão fazê-lo através da sincronização direta da rede do portal.

( Como interage com outras partes do roteiro?

Se quisermos tornar a execução ou o início de nós extremamente fácil, então a redução das necessidades de armazenamento histórico pode ser considerada 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 800 GB tornaram-se históricos. Apenas alcançando a sem estado e o EIP-4444, será possível realizar 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 as versões mais recentes do protocolo, o que os torna mais simples. Por exemplo, agora é possível remover com segurança várias linhas de código, uma vez que os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram todos eliminados. 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 os clientes armazenarem históricos, a necessidade de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, uma vez que o estado continua a crescer: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, assim, onerando os clientes de Ethereum atuais e futuros para sempre.

O estado é mais difícil de "expirar" do que a história, porque a EVM foi projetada 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 o problema talvez não seja tão ruim: apenas classes de construtores de blocos especializados precisam realmente armazenar estado, enquanto todos os outros nós ), até mesmo a geração de listas! ###, podem operar sem estado. No entanto, há uma opinião de que não queremos depender demais da ausência de estado, e que, eventualmente, poderemos 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 com código, ( iii ) definindo um slot de armazenamento que nunca foi tocado (, e 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 chave é fazer isso de uma forma que atinja os três objetivos:

Eficiência: não requer uma grande quantidade de cálculos adicionais para executar o processo de vencimento.

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

Amigabilidade para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento completamente desconhecido. Além disso, as aplicações que estão atualmente rigidificadas e não atualizadas devem continuar a funcionar normalmente.

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

Estes são problemas que a comunidade de desenvolvimento central do Ethereum tem trabalhado arduamente 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 piores":

• Solução para parte do status expirado
• Sugestão de expiração de estado baseada no ciclo de endereço.

( Expiração parcial do estado

Algumas propostas de estado expiradas seguem os mesmos princípios. Dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de topo", onde os blocos estão vazios ou não vazios. Os dados em cada bloco só serão armazenados se os dados tiverem sido acessados recentemente. Existe um "