O futuro possível do Ethereum: The Purge

Autor: Vitalik Buterin

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: 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, de forma a serem completamente sincronizadas com a rede. Isso resulta em uma carga e tempo de sincronização dos clientes que aumentam ao longo do tempo, mesmo que a capacidade da cadeia permaneça inalterada.

Função do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover as antigas, o que leva a um aumento da complexidade do código ao longo do 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 chamadas 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 ele ainda está lá esperando por você para ler e interagir. Para que DApps se descentralizem completamente e removam as chaves de atualização, eles precisam ter certeza de que suas dependências não serão atualizadas de forma a prejudicá-las - especialmente a própria L1.

Se decidirmos equilibrar essas duas demandas e minimizar ou reverter a obesidade, 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 ao longo do tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma vida muito longa. Em alguns casos, o Ethereum já obteve sucesso: a prova de trabalho desapareceu, o opcode SELFDESTRUCT desapareceu na sua maior parte, e os nós da Beacon Chain armazenaram dados antigos por até seis meses. Descobrir esse caminho para o Ethereum de uma forma mais genérica e caminhar em direção a um resultado final estável 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 ao reduzir ou eliminar 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:

Histórico de expiração

Estado de expiração

Limpeza de recursos

História de expiração

Que problema está a resolver?

Até o momento da redação deste artigo, um nó Ethereum completamente 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 maior parte dos quais já tem vários anos. Isso significa que mesmo que o limite de Gas não aumente, o tamanho do nó continuará a aumentar centenas de GB a cada ano.

O que é isso e 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 o consenso sobre o atual para alcançar o 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 da 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 valide 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 oferece-nos 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 sementes têm funcionado durante décadas: embora a rede armazene e distribua milhões de ficheiros, cada participante armazena e distribui apenas alguns desses ficheiros. Talvez, ao contrário da intuição, este método nem sempre reduza 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 replicação que 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. Blocos de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazenam apenas cerca de 6 meses. 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 a longo prazo é estabelecer um período unificado (possivelmente de cerca de 18 dias), durante o qual cada nó é responsável por armazenar tudo, e depois criar uma rede ponto a ponto composta por nós do Ethereum, que armazenará 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. De fato, o Blob já foi codificado com códigos de apagamento para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de apagamento e também colocar a execução e os dados do bloco de consenso no blob.

Quais são as ligações com a pesquisa existente?

EIP-4444；

Torrents e EIP-4444；

Portal Network;

Portal Network 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 que eventualmente também incluirá consenso e blob. A solução mais simples é (i) simplesmente introduzir uma biblioteca torrent existente, bem como (ii) chamada solução nativa de Ethereum da rede Portal. Uma vez que qualquer uma delas seja introduzida, podemos abrir 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 habilitá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de que um cliente falhe ao se conectar a outros nós na expectativa de baixar o histórico completo, mas na verdade não o obtenha.

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 depender de nós existentes nós de arquivo e vários provedores centralizados para replicação. Isso é fácil, mas enfraquece a posição do Ethereum como um local de registro permanente. Uma abordagem mais difícil, mas mais segura, é 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?

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

Um método extremamente obsessivo para (1) envolveria a prova de custódia: na prática, exigindo que cada validador de prova de participação armazenasse uma proporção certa de registros históricos e verificasse regularmente de forma criptográfica se o faz. Um método mais brando seria estabelecer um padrão voluntário para a porcentagem da história 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 todo o histórico do Ethereum. Uma implementação mais abrangente envolveria realmente conectá-lo ao processo de sincronização, de modo que, se alguém quisesse sincronizar nós de armazenamento de histórico completo ou nós de arquivo, mesmo que não haja outros nós de arquivo online, eles poderiam fazê-lo sincronizando diretamente da rede Portal.

Como interage com as outras partes do roteiro?

Se quisermos tornar a execução ou o início de um nó extremamente fácil, então a redução das necessidades de armazenamento histórico pode ser considerada 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. Apenas alcançando a ausência de 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 a versão mais recente do protocolo, o que os torna mais simples. Por exemplo, agora é seguro remover muitas linhas de código, pois 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órica, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.

Estado de expiração

Que problema está a resolver?

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, pois o estado continua a aumentar: saldo 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 traz um fardo eterno para os clientes de Ethereum, tanto no presente como no futuro.

O estado é mais difícil de "expirar" do que a história, porque a EVM é essencialmente projetada 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 sem estado, alguns acreditam que esse problema talvez não seja tão ruim: apenas classes de construtores de blocos especializados precisariam realmente armazenar estado, enquanto todos os outros nós (incluindo aqueles que geram listas!) poderiam operar sem estado. No entanto, há uma opinião de que não queremos depender demais da sem estado, e no final, podemos querer permitir que o estado expire para manter a descentralização do Ethereum.

O que é isso, como funciona?

Hoje, quando você cria um novo objeto de estado (que pode ocorrer de uma das seguintes maneiras: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com 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 chave é fazer isso de uma maneira que atinja 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 por 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, aplicações que estão atualmente 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 durante a leitura ou escrita) e ter um processo que percorre o estado para remover objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (e até mesmo requisitos de armazenamento) e certamente não pode atender às exigências de facilidade de uso. Os desenvolvedores também têm dificuldade 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 tornará a vida dos desenvolvedores mais fácil, mas tornará 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 para resolver ao longo dos anos, incluindo propostas como "aluguel de blockchain" e "renovação". No final, combinamos as melhores partes das propostas e nos concentramos em duas categorias de "soluções conhecidas como as menos ruins":

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

Expiração parcial de estado

Algumas propostas de estado expiram seguindo os mesmos princípios. Dividimos o estado em blocos. Cada um armazena permanentemente o "mapeamento de topo", onde os blocos podem estar vazios ou não vazios. Os dados em cada bloco são armazenados apenas se foram acessados recentemente. Existe um mecanismo de "ressurreição" que, se não estiver mais armazenado

Estas propostas diferem principalmente em: (i) nós como