O possível futuro do Ethereum: The Purge

Autor: Vitalik Buterin

Compilação: Como é que

Um agradecimento especial a Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden e Tomasz Stanczak pelo feedback e revisão.

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: Qualquer transação realizada e qualquer conta criada em qualquer momento da história deve ser armazenada permanentemente por todos os clientes e baixada por qualquer novo cliente, de modo a estar totalmente sincronizada com a rede. Isso fará com que a carga do cliente e o tempo de sincronização aumentem continuamente ao longo do tempo, mesmo que a capacidade da cadeia permaneça a mesma.

Função do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover funcionalidades antigas, levando ao 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 torna 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 o DApp possa ser completamente descentralizado e remover a chave de atualização com confiança, eles precisam ter certeza de que suas dependências não serão atualizadas de maneira que as prejudique - especialmente o L1 em si.

Se nos determinarmos a encontrar um equilíbrio entre essas duas necessidades e a minimizar ou reverter a sobrecarga, complexidade e degradação, 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 afortunados não o fazem. Mesmo os sistemas sociais podem ter uma vida útil muito longa. Em certos casos, o Ethereum já teve sucesso: a prova de trabalho desapareceu, o código de operação SELFDESTRUCT desapareceu em grande 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 genérica e caminhar em direção a um resultado final de estabilidade a longo prazo é o desafio supremo para a escalabilidade de longo prazo do Ethereum, sustentabilidade técnica e até mesmo segurança.

O Purge: principal objetivo.

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.

Índice do artigo:

Histórico de expiração

Estado de expiração

Limpeza de características

História de expiração

Que problema resolve?

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, transações e recibos históricos, 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 centenas de GB a cada ano.

O que é isso e como funciona?

Uma característica simplificada chave do problema de armazenamento histórico é que, uma vez que cada bloco aponta para o bloco anterior através de links 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 histórico ou transação ou estado (saldos de conta, números aleatórios, código, armazenamento) pode ser fornecido por qualquer participante individual e 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 nos oferece 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 seed têm funcionado durante 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 nem sequer precisará 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á replicado 10.000 vezes - exatamente o mesmo fator de replicação de uma rede de 10.000 nós, onde cada nó armazena tudo.

Hoje, o Ethereum começou a se afastar do modelo de armazenamento permanente de todo o histórico em todos os nós. 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 a 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 criar uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de forma distribuída.

Os códigos de eliminação podem ser utilizados 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 incluir os dados de execução e bloco de consenso no blob.

Quais são as conexões com as pesquisas existentes?

EIP-4444；

Torrents e EIP-4444；

Rede de portal;

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 específica para armazenar históricos - 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, assim 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 ativá-lo para todos os clientes ao mesmo tempo, caso contrário, existe o risco de os clientes falharem ao se conectar a outros nós, esperando baixar o histórico completo, mas na realidade 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 dados históricos antigos amanhã e depender de nós existentes nós de arquivamento e 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:

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

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

Uma abordagem extremamente obsessiva para (1) envolveria a prova de custódia: basicamente exigindo que cada validador de prova de participação armazene uma proporção específica de registos históricos e verifique regularmente de forma criptografada se o fazem. 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 um arquivo ERA contendo 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 com o histórico completo ou um nó de arquivo, mesmo que não houvesse outros nós de arquivo online, eles pudessem realizar isso através da sincronização direta com a 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 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 cerca de 800 GB tornaram-se históricos. Apenas alcançando a sem estado e o EIP-4444 é que podemos realizar a visão de executar nós Ethereum em um relógio inteligente e configurar 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 excluir 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 excluir com segurança todo o código relacionado à prova de trabalho.

Expiração do estado

Que problema é resolvido?

Mesmo que eliminemos a necessidade de os clientes armazenarem o histórico, a necessidade 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 trará um ônus permanente para os clientes Ethereum atuais e futuros.

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 falta de estado, algumas pessoas acreditam que esse problema pode não ser tão ruim: apenas classes de construtores de blocos especializadas precisam realmente armazenar o estado, enquanto todos os outros nós (mesmo aqueles que incluem a geração de listas!) podem operar sem estado. No entanto, há uma opinião de que não queremos depender excessivamente da falta de estado, e no final, podemos querer 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 (o que pode acontecer de uma das três maneiras seguintes: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) configurando um slot de armazenamento que não foi tocado anteriormente), 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 é conseguir fazer isso de uma maneira que atinja três objetivos:

Eficiência: não é necessário muito cálculo adicional 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...

Amigável para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento totalmente desconhecido. Além disso, as 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 uma leitura ou gravação) e ter um processo que percorre os estados para remover objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (e até mesmo necessidades 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 que envolvem valores de armazenamento que às vezes se resetam 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 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ão de expiração de estado com base 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 superior", onde