Vitalik: O possível futuro do Ethereum, The Purge

Um dos desafios enfrentados pelo Ethereum é 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 ou qualquer conta criada em qualquer momento da história deve ser permanentemente armazenada por todos os clientes e baixada por qualquer novo cliente, de forma a estar completamente sincronizada 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, o que leva ao aumento da complexidade do código ao longo do tempo.

Para que o Ethereum possa se manter a longo prazo, precisamos aplicar 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 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 ainda está lá, esperando para você ler e interagir. Para que os DApps possam descentralizar completamente 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 uma forma que as prejudique - especialmente o L1 em si.

Se decidirmos firmemente 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 ao longo do tempo, alguns poucos sortudos não o fazem. Mesmo os sistemas sociais podem ter uma vida útil muito longa. Em alguns 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 beacon chain armazenaram dados antigos por até seis meses. Encontrar esse 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 desafio definitivo para a escalabilidade de 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 diminuir ou eliminar a necessidade de cada nó armazenar permanentemente todos os registros históricos, incluindo o estado final.

Reduzir a complexidade do protocolo eliminando funcionalidades desnecessárias.

Índice do artigo:

Histórico de expiração

Expiração do estado

Limpeza de recursos

Expiração do histórico

Resolve que problema?

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 históricos, transações e recibos, a maior parte dos quais já tem muitos 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 e como funciona?

Uma característica chave de simplificação do problema de armazenamento histórico é que, como cada bloco se liga ao bloco anterior através de uma hash (e outras estruturas), alcançar consenso sobre o atual é suficiente para alcançar consenso sobre o histórico. Desde que a rede atinja consenso sobre o bloco mais recente, qualquer bloco histórico, transação ou estado (saldo de contas, número aleatório, 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 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 onde cada nó armazena apenas uma pequena parte dos dados. Esta é a maneira 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 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 que uma rede de 10,000 nós, onde cada nó armazena tudo.

Atualmente, o Ethereum já 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. 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 (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, onde os dados antigos são armazenados 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á implementou códigos de eliminação para suportar amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de eliminação e também colocar a execução e os dados do bloco de consenso dentro do blob.

tem alguma ligação com as pesquisas existentes?

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 específica 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 bibliotecas torrent existentes, bem como (ii) uma solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer um deles seja introduzido, 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 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 seria parar de armazenar dados históricos antigos amanhã e confiar 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. 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?

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 certa proporção de registros históricos e verificasse periodicamente, de forma criptografada, se o faz. Um método mais brando seria estabelecer um padrão voluntário para a percentagem histórica armazenada por cada cliente.

Para (2), a implementação básica envolve apenas o trabalho já 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, 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 disponíveis, eles possam realizar a sincronização diretamente através da rede do portal.

Como interage com as outras partes do roteiro?

Se quisermos que a execução ou o início 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, enquanto os restantes 800 GB são históricos. Apenas alcançando a ausência de estado e o EIP-4444 é que podemos 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ó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 armazenamento de histórico de clientes, a demanda de armazenamento do cliente continuará a crescer, cerca de 50 GB por ano, à medida que o estado continua a crescer: saldos de contas e números aleatórios, códigos de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, o que trará um encargo permanente para os clientes de Ethereum no presente 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 sem estado, alguns acreditam que esse problema pode não ser tão grave: apenas classes de construtores de blocos especializadas precisam realmente armazenar estado, enquanto todos os outros nós (mesmo aqueles que geram listas!) podem operar sem estado. No entanto, há uma opinião de que não queremos depender excessivamente da sem estado, e, no final, podemos querer permitir que o estado expire para manter a descentralização do Ethereum.

O que é isso e como funciona

Hoje, quando você cria um novo objeto de estado (o que pode ocorrer de uma das seguintes três 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 tocado antes), esse objeto de estado permanece nesse estado para sempre. Por outro lado, 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 são necessários muitos cálculos adicionais 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...

Amigável para desenvolvedores: os desenvolvedores não precisam mudar para um modelo de pensamento totalmente desconhecido. Além disso, aplicativos que estão atualmente rígidos e não atualizados 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 estendido queimando ETH, o que pode acontecer automaticamente a qualquer momento durante a leitura ou gravação) e ter um processo que percorra os estados para remover objetos de estado com datas de expiração. No entanto, isso introduz cálculos adicionais (e 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 limite 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 tornaria a vida do desenvolvedor mais fácil, mas tornaria a economia mais difícil: os desenvolvedores devem considerar como "transferir" o custo de armazenamento contínuo 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, combinámos as melhores partes das propostas e concentrá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 expiradas seguem 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. Os dados em cada bloco são armazenados apenas se esses dados foram acessados recentemente. Existe um mecanismo de "ressurreição" que atua se não estiver mais armazenado.

A principal diferença entre essas propostas é: (i) como definimos "