O possível futuro do Ethereum: A Purga

Um dos desafios que o Ethereum enfrenta é que, por padrão, a expansão e a complexidade de qualquer protocolo de blockchain aumentam ao longo do tempo. Isso acontece em dois lugares:

Dados históricos: Em qualquer momento da história, todas as transações realizadas e todas as contas criadas precisam ser armazenadas permanentemente por todos os clientes e baixadas por qualquer novo cliente, de modo a estarem completamente sincronizadas com a rede. Isso resultará em um aumento contínuo na carga dos clientes e no 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 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.000.000 de dólares na cadeia, entrar em uma caverna por dez anos e, ao sair, descobrir que ainda está lá, esperando para ser lido e interagido. Para que os DApps possam se descentralizar completamente 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 demandas e minimizar ou reverter a burocracia, a complexidade e o declínio, mantendo a continuidade, isso é absolutamente possível. Os organismos vivos conseguem isso: embora a maioria dos organismos envelheça com o tempo, alguns poucos sortudos não o fazem. Até mesmo sistemas sociais podem ter uma longevidade muito longa. Em certos casos, Ethereum já teve sucesso: o Proof of Work desapareceu, o opcode SELFDESTRUCT desapareceu em grande parte, e os nós da Beacon Chain armazenaram dados antigos por até seis meses. Encontrar este 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, sustentabilidade técnica e até mesmo segurança.

The Purge: Principais objetivos.

Reduzir os requisitos de armazenamento do cliente ao diminuir 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

Expiração do estado

Limpeza de características

História de expiração

Que problema é resolvido?

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 maioria dos quais tem vários anos. Isso significa que, mesmo que o limite de Gas não aumente de forma alguma, o tamanho do nó continuará aumentando em centenas de GB a cada ano.

O que é, como funciona?

Uma característica chave da simplificação do problema de armazenamento histórico é que, uma vez que cada bloco aponta para o bloco anterior por meio 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, transação ou estado (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 verifique 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 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 operam há 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 pode até não reduzir a robustez dos dados. Se, tornando 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 desvincular do modelo em que todos os nós armazenam permanentemente toda a história. 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 em torno de 18 dias), durante o qual cada nó é responsável por armazenar tudo, e então criar uma rede ponto a ponto composta por nós do Ethereum, armazenando dados antigos de forma distribuída.

Códigos de apagamento podem ser usados para aumentar a robustez, mantendo o fator de replicação o mesmo. Na verdade, o Blob já foi codificado para suportar a amostragem de disponibilidade de dados. A solução mais simples provavelmente será reutilizar esses códigos de apagamento e também colocar os dados de execução e consenso no blob.

Quais são as ligações com as pesquisas existentes?

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 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órico------pelo menos o histórico de execução, mas eventualmente também incluirá consenso e blob. A solução mais simples é (i) simplesmente introduzir bibliotecas torrent existentes, bem como (ii) chamada solução nativa da Ethereum conhecida como Portal Network. Uma vez que qualquer um dos dois seja introduzido, podemos ativar 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, há 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 obtêm.

Os principais trade-offs envolvem como nos esforçamos para fornecer dados históricos "antigos". A solução mais simples é parar de armazenar história antiga 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. 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 armazene todos os dados?

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

Uma abordagem extremista para (1) envolverá prova de custódia: exigindo efetivamente que cada validador de prova de participação armazene uma certa proporção de registros históricos e verifique periodicamente de forma criptografada se o faz. Uma abordagem mais suave é 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 envolveria realmente conectá-lo ao processo de sincronização, de modo que, se alguém quisesse 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 poderiam fazê-lo através da sincronização direta da rede do portal.

Como interage com 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, enquanto os restantes cerca de 800 GB tornaram-se históricos. Só será possível alcançar a visão de executar um nó Ethereum em um relógio inteligente e configurá-lo em apenas alguns minutos com a implementação da ausência de estado e do EIP-4444.

A limitação do 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 é seguro remover muitas linhas de código, pois 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 parte da história, os clientes podem remover com segurança todo o código relacionado à prova de trabalho.

Estado de expiração

Que problema resolve?

Mesmo que eliminemos a necessidade de armazenar o histórico no cliente, a necessidade 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ódigo de contratos e armazenamento de contratos. Os usuários podem pagar uma taxa única, transferindo assim uma carga para os clientes Ethereum atuais e futuros.

O estado é mais difícil de "expirar" do que a história, porque o EVM é fundamentalmente projetado com a suposição de que, uma vez que um objeto de estado é criado, ele sempre existirá e pode ser lido a qualquer momento por qualquer transação. Se introduzirmos a ausência de estado, algumas pessoas acreditam que esse problema talvez não seja tão ruim: apenas classes de construtores de blocos especializadas precisariam realmente armazenar o estado, enquanto todos os outros nós (até mesmo aqueles que geram listas!) poderiam operar de forma sem estado. No entanto, há uma opinião que acredita que não queremos depender excessivamente da ausência de estado, e que, no final, poderíamos querer fazer o estado expirar para manter a descentralização do Ethereum.

O que é, como funciona

Hoje, quando você cria um novo objeto de estado (o que 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 principal é fazer isso de maneira a alcançar 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...

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 rigidificadas 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, algo que pode ocorrer automaticamente em qualquer leitura ou gravação), 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 (mesmo requisitos de armazenamento), e certamente 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 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 precisam considerar como "transferir" os custos contínuos de armazenamento para os usuários.

Estes são problemas que a comunidade de desenvolvimento central do Ethereum tem trabalhado arduamente para resolver ao longo dos anos, incluindo propostas como "renda 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 más":

• Solução para o estado parcialmente expirado
• Sugestões 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. Nós dividimos o estado em blocos. Todos armazenam permanentemente o "mapeamento de topo", onde os blocos podem estar vazios ou não vazios. Os dados em cada bloco só serão armazenados se forem acessados recentemente. Existe um mecanismo de "ressurreição" que, se não estiver mais armazenado.

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