O futuro possível 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 tendem a aumentar com o tempo. Isso acontece em dois lugares:

Dados históricos: A qualquer momento da história, todas as transações realizadas e todas as contas criadas precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de forma a sincronizar completamente com a rede. Isso levará a 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.

Funcionalidade do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover funcionalidades antigas, levando a um aumento da complexidade do código ao longo do tempo.

Para que o Ethereum possa se manter a longo prazo, precisamos impor 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 os DApps possam se descentralizar completamente e remover a chave de atualização, eles precisam ter certeza de que suas dependências não vão ser atualizadas de uma forma que as destrua - especialmente o L1 em si.

Se nos decidirmos a encontrar um equilíbrio entre essas duas demandas e a minimizar ou reverter a obesidade, a complexidade e o declínio, mantendo 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 longevidade muito longa. Em certos casos, o Ethereum já obteve sucesso: a prova de trabalho desapareceu, a opcode SELFDESTRUCT desapareceu na maior parte, e os nós da beacon chain armazenaram dados antigos por até seis meses. Encontrar esse caminho para o Ethereum de uma maneira mais geral e caminhar em direção a um resultado final estável a longo prazo é o desafio definitivo para a escalabilidade de 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órico de expiração ( histórico de registros expirado )

Estado de expiração( estado de expiração)

Limpeza de recursos ( limpeza de características )

Expiração da história

Que problema resolve?

Até à data da redação deste artigo, um nó Ethereum totalmente sincronizado requer aproximadamente 1,1 TB de espaço em disco para executar o cliente, além de precisar de várias centenas de GB de espaço em disco para o cliente de consenso. A maior parte disto é histórica: dados sobre blocos históricos, transações e recibos, a maior parte dos quais já tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente de todo, o tamanho do nó continuará a aumentar várias centenas de GB anualmente.

O que é, como funciona?

Uma característica simplificada chave do problema de armazenamento histórico é que, uma vez que cada bloco está ligado ao bloco anterior através de um 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 ou transação ou estado histórico (, saldo de contas, números aleatórios, código, armazenamento ) pode ser fornecido por qualquer participante individual, assim como 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 proporciona muitas opções sobre como armazenar o histórico. Uma escolha natural é uma rede onde cada nó armazena apenas uma pequena parte dos dados. Esta é a forma como as redes de semente funcionam há 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, este método pode até não diminuir 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% do histórico, 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 tudo.

Agora, o Ethereum começou a se desvincular do modelo em que todos os nós armazenam permanentemente toda a história. 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 históricos e recibos. O objetivo de longo prazo é estabelecer um período unificado ) que pode ser de cerca de 18 dias (, durante o qual cada nó é responsável por armazenar tudo, e então estabelecer uma rede peer-to-peer composta por nós do Ethereum para armazenar dados antigos de forma distribuída.

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

)# Quais são as conexões com a pesquisa existente?

EIP-4444;

Torrents e EIP-4444;

Rede de portal;

Rede de portal e EIP-4444;

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

Como aumentar o limite de gas ### Paradigm (.

)# 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 concreta para armazenar o histórico ------ pelo menos o histórico 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( chamada solução nativa da Ethereum da rede Portal. 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 necessita 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 um cliente falhar ao se conectar a outros nós, esperando baixar o histórico completo, mas na verdade não o obtendo.

As principais considerações envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar história antiga amanhã e confiar em nós para replicar com nós de arquivo existentes e vários provedores centralizados. Isso é fácil, mas isso 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:

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

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

Um método de extrema paranoia para ) envolveria a prova de custódia: na prática, exigiria que cada validador de prova de participação armazenasse uma certa proporção de registros históricos e os verificasse regularmente de forma criptografada. Um método mais brando seria estabelecer um padrão voluntário para a porcentagem histórica armazenada por cada cliente.

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

(# Como interage com as outras partes do roteiro?

Se quisermos que a execução ou o arranque de um nó seja 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, e os restantes cerca de 800 GB tornaram-se históricos. Apenas alcançando a sem estado e o EIP-4444 é que se pode 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 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 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.

) Expiração do estado

Que problema resolver?

Mesmo que eliminemos a necessidade de os clientes armazenarem o histórico, a demanda de armazenamento dos clientes continuará a crescer, cerca de 50 GB por ano, pois o estado continua a crescer: saldos de contas e números aleatórios, código de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, o que trará um fardo para os clientes de Ethereum agora e no futuro.

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 esse problema pode não ser tão ruim: apenas classes de construtores de bloco especializadas precisam realmente armazenar estado, enquanto todos os outros nós ### até mesmo incluem a geração de listas! ### podem operar sem estado. No entanto, há uma perspectiva que considera que não queremos depender demais da ausência de estado, e que, eventualmente, podemos querer tornar o estado obsoleto 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 ( enviar ETH para uma nova conta, ( ii ) criar uma nova conta usando código, ( iii ) configurar um slot de armazenamento que nunca foi tocado antes (, e esse objeto de estado permanece nesse estado para sempre. Em contraste, o que queremos é que o objeto expire automaticamente ao longo do tempo. O desafio chave é fazer isso de uma maneira que atinja os três objetivos:

Eficiência: não é necessário um grande cálculo adicional para executar o processo de vencimento.

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

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

Não atender a esses objetivos torna a resolução de problemas muito fácil. 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 ao ler ou escrever ), e há um processo de iteração sobre o estado para remover objetos de estado com datas de expiração. No entanto, isso introduz requisitos adicionais 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 dificuldades em raciocinar sobre 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 tornaria a vida dos desenvolvedores mais fácil, mas tornaria a economia mais complicada: os desenvolvedores devem considerar como "transferir" os custos contínuos de armazenamento para os usuários.

Estes são todos os 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 "renovação". No final, combinámos as melhores partes das propostas e focámo-nos em duas categorias de "soluções conhecidas como as menos piores":

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

(# Expiração parcial do estado

Algumas propostas de estado expiram seguindo os mesmos princípios. Dividimos o estado em blocos. Todos armazenam permanentemente o "mapeamento de topo", onde o bloco pode estar vazio ou não. Apenas quando o mais