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 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 histórico precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, a fim de serem completamente sincronizadas com a rede. Isso resulta em um aumento contínuo da carga do cliente 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, resultando em uma complexidade de código que aumenta com o tempo.

Para que o Ethereum possa se manter a longo prazo, precisamos exercer uma forte pressão contrária sobre 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.000.000 de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ele ainda está lá esperando por você para ler e interagir. Para que os DApps possam ser totalmente descentralizados e remover a chave de atualização, eles precisam ter certeza de que suas dependências não serão atualizadas de maneira a prejudicá-los - especialmente o L1 em si.

Se decidirmos equilibrar essas duas necessidades e minimizar ou reverter a gordura, 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 vida muito longa. Em certos casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o opcode SELFDESTRUCT desapareceu em sua maior parte, e os nós da cadeia de beacon 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 de estabilidade a longo prazo é o desafio supremo para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.

The Purge: Principal objetivo.

• Reduzir os requisitos de armazenamento do cliente, diminuindo ou eliminando a necessidade de cada nó armazenar permanentemente todos os históricos ou até mesmo o estado final.

• Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.

Índice do artigo:

• Expiração do histórico
• Expiração do estado
• Limpeza de recursos

Expiração da história

Resolve que problema?

Até o momento da redação deste artigo, um nó Ethereum totalmente sincronizado necessita de cerca de 1,1 TB de espaço em disco para executar o cliente, além de vários 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 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 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 aponta para o bloco anterior através de ligações hash (e outras estruturas), é suficiente alcançar consenso sobre o estado atual para alcançar consenso sobre a história. Desde que a rede alcance consenso sobre o último bloco, qualquer bloco histórico, transação ou estado (saldos de contas, números aleatórios, código, armazenamento) pode ser fornecido por qualquer participante individual juntamente com uma 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 a história é um modelo de confiança N-of-N.

Isto oferece-nos muitas opções sobre como armazenar o histórico. Uma escolha natural é uma rede em que cada nó armazena apenas uma pequena parte dos dados. Esta é a forma como as redes de sementes têm funcionado durante décadas: embora a rede armazene e distribua milhões de arquivos, cada participante armazena e distribui apenas alguns deles. Talvez contra a intuição, este método pode até não reduzir a robustez dos dados. Se, ao tornar a operação dos nós mais económica, conseguirmos 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 de uma rede de 10.000 nós, onde cada nó armazena tudo.

Atualmente, o Ethereum começou a se afastar do modelo em que todos os nós armazenam permanentemente todo o histórico. Os blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazenam apenas cerca de 6 meses. Os Blobs armazenam 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 (possivelmente 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 maneira distribuída.

Códigos de eliminação podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. De fato, o Blob já foi codificado com 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 do bloco dentro do blob.

com que pesquisas existentes estão relacionadas?

• 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) uma solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer um deles seja introduzido, podemos habilitar o EIP-4444. O EIP-4444 em si não requer um hard fork, mas realmente requer uma nova versão do protocolo de rede. Portanto, é valioso habilitá-lo ao mesmo tempo para todos os clientes, caso contrário, há o risco de falha do cliente ao conectar-se a outros nós esperando baixar o histórico completo, mas na verdade não o obtendo.

Os principais trade-offs 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 a 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 registros históricos de forma distribuída. Aqui, "quão duro 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?

Um método extremamente paranoico para (1) envolveria a prova de custódia: na prática, exigiria que cada validador de prova de participação armazenasse uma certa proporção de históricos e verificasse regularmente, de forma criptografada, se o faziam. 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 arquivos 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 arquivamento, mesmo que não haja outros nós de arquivamento online, eles poderão fazê-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 nós seja extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser considerado mais importante do que a ausência de 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. Somente com a implementação da ausência de estado e do EIP-4444 é que se poderá 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 mais recentes do 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. Uma vez 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 de estado

Resolve que problema?

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, à 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, o que carregará um ônus para os clientes de Ethereum atuais e futuros.

O estado é mais difícil de "expirar" do que a história, porque a EVM foi fundamentalmente projetada com a 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 este problema talvez não seja tão ruim: apenas as classes de construtores de blocos especializados precisam realmente armazenar estado, enquanto todos os outros nós (até mesmo aqueles que geram listas!) podem operar sem estado. No entanto, há uma perspectiva que argumenta que não queremos depender excessivamente da ausência de estado, e que, no final, talvez queiramos permitir que o estado expire 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 três maneiras a seguir: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) configurando um slot de armazenamento que nunca foi tocado 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 chave é fazer isso de uma maneira que atinja três objetivos:

1. Eficiência: não é necessário um grande volume de cálculos adicionais para executar o processo de expiração.

2. Facilidade de uso: Se alguém entrar na caverna durante cinco anos e voltar, não deveria perder o acesso ao ETH, ERC20, NFT, posições de CDP...

3. Amizade para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento completamente desconhecido. Além disso, aplicativos que estão atualmente rígidos e não atualizados devem continuar a funcionar normalmente.

Não cumprir 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 durante a leitura ou gravação), e ter um processo que percorre o estado para remover objetos de estado com data de expiração. No entanto, isso introduz cálculo adicional (até mesmo requisitos de armazenamento) e definitivamente não pode atender aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos em que os valores armazenados às vezes são redefinidos para zero. Se você configurar um temporizador de expiração dentro do escopo do contrato, isso tecnicamente tornará a vida do desenvolvedor mais fácil, mas tornará a economia mais complicada: os desenvolvedores devem considerar como "transferir" o custo contínuo de armazenamento para os usuários.

Estes são todos problemas que a comunidade de desenvolvedores centrais do Ethereum tem trabalhado para resolver ao longo dos anos, incluindo propostas como "aluguel de blockchain" e "renovação". No final, combinamos as melhores partes das propostas e focamos em duas categorias de "soluções conhecidas como as menos ruins":

• Solução para o estado parcialmente 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 pessoa armazena permanentemente o "mapeamento superior", 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 mecanismo de "ressurreição" que se não estiver mais armazenado.