Vitalik: 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 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 modo a serem completamente sincronizadas com a rede. Isso levará a 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.

Função 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 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 milhão de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ainda está lá, esperando para você ler e interagir. Para que os DApps possam se descentralizar completamente e remover as chaves 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 demandas e minimizar ou reverter a gordura, a complexidade e a degradação, mantendo a continuidade, isso é absolutamente possível. Os organismos podem fazer isso: enquanto a maioria dos organismos envelhece com o tempo, alguns poucos afortunados 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 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 este caminho para o Ethereum de uma maneira mais geral e avançar em direção a um resultado final estável a longo prazo é o maior desafio para a escalabilidade a longo prazo do Ethereum, a sustentabilidade técnica e até mesmo a segurança.

The Purge: objetivo principal.

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

Reduzir a complexidade do protocolo eliminando funções desnecessárias.

Índice do artigo:

History expiry（历史记录到期）

Estado de expiração

Limpeza de características

Expiração da História

Resolve que problema?

Até a data da redação deste artigo, um nó Ethereum completamente sincronizado necessita de 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 de história. Isso significa que, mesmo que o limite de Gas não tenha aumentado, o tamanho do nó continuará a aumentar em 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, transação ou estado histórico (saldo de conta, número aleatório, código, armazenamento) pode ser fornecido por qualquer participante único, 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 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 de sementes têm funcionado por décadas: embora a rede armazene e distribua milhões de arquivos no total, cada participante armazena e distribui apenas alguns desses arquivos. Talvez contra a intuição, este método nem sequer precisa 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% do histórico, então cada dado será replicado 10.000 vezes - o que é 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 desvincular 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, que armazenará dados antigos de forma distribuída.

Os 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á utilizou 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 bloco de consenso dentro do blob.

tem alguma relação com a pesquisa existente?

EIP-4444；

Torrents e EIP-4444；

Portal de rede;

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 deve 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 bibliotecas torrent existentes, bem como (ii) chamada solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer um deles seja introduzido, podemos ativar o EIP-4444. O EIP-4444 em si não requer um hard fork, mas sim uma nova versão do protocolo de rede. Portanto, é valioso ativá-lo ao mesmo tempo para todos os clientes, caso contrário, há o risco de um cliente falhar por tentar conectar-se a outros nós esperando baixar o histórico completo, mas na verdade não o obtiver.

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 em nós mesmos nos nós de arquivamento 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. Uma abordagem mais difícil, mas mais segura, é primeiro construir e integrar uma rede torrent para armazenar historicamente 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?

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 verificasse periodicamente de forma criptografada se o faziam. Um método mais brando 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 arquivos ERA que contêm toda a história do Ethereum. Uma implementação mais abrangente envolverá realmente conectá-lo ao processo de sincronização, de modo que, 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 possam fazê-lo diretamente através da sincronização da rede do portal.

Como interage com outras partes do roteiro?

Se quisermos tornar a execução ou o início de um nó extremamente fácil, então reduzir a necessidade de armazenamento histórico pode ser 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 aproximadamente 800 GB tornaram-se históricos. Apenas alcançando a ausência de estado e o EIP-4444, podemos realizar a visão de executar um nó Ethereum em um relógio inteligente e configurá-lo em apenas alguns minutos.

Limitar o armazenamento histórico 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 eliminar com segurança muitas linhas de código, pois 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 remover com segurança todo o código relacionado à prova de trabalho.

Expiração do estado

Resolve que problema?

Mesmo que eliminemos a necessidade de armazenar o 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: saldos de contas e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única, transferindo assim o ônus para os clientes atuais e futuros do Ethereum.

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

O que é isso, como funciona?

Hoje, quando você cria um novo objeto de estado (o que pode acontecer 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 acessado 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 é 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 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, aplicações que estão atualmente rígidas e não atualizadas devem continuar a funcionar normalmente.

Não atender a 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 prolongado queimando Éter, o que pode acontecer automaticamente a qualquer momento durante a leitura ou gravação), e ter um processo que percorre os estados para remover objetos de estado com data de expiração. No entanto, isso introduz computação adicional (e até mesmo requisitos de armazenamento), e com certeza não pode atender aos requisitos de facilidade de uso. Os desenvolvedores também têm dificuldade em raciocinar sobre casos extremos onde 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 tornaria a vida dos desenvolvedores mais fácil, mas tornaria a economia mais difícil: os desenvolvedores precisam considerar como "transferir" o custo contínuo 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 status parcialmente expirados Sugestão de expiração de estado com base 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 superior", onde os blocos estão vazios ou não vazios. Os dados em cada bloco só serão armazenados se tiverem sido acessados recentemente. Existe um mecanismo de "ressurreição" que, se não forem mais armazenados.

A principal diferença entre estas propostas é: (i) como definimos "recentemente",