Autor: Vitalik Buterin

Compilação: Odaily Planet Daily Como fazer

Desde 14 de outubro, Vitalik Buterin, fundador do ETH Workshop, publicou uma série de discussões sobre o possível futuro do ETH Workshop, desde "The Merge", "The Surge", "The Scourge", "The Verge" até o último lançamento "The Purge", destacando a visão de Vitalik para o desenvolvimento futuro do diretor da Rede do ETH Workshop e como resolver os problemas atuais.

《The Merge》: discute a necessidade de melhorar a finalidade de uma única slot e o limiar de Gota de participação do ETH após a transição para PoS, a fim de aumentar a participação e a velocidade de confirmação das transações.

《The Surge》: Explora diferentes estratégias de escalabilidade do Ethereum, especialmente o roadmap centrado no Rollup, e os desafios e soluções em termos de escalabilidade, Descentralização e segurança.

"The Scourge": Explora os riscos de centralização e extração de valor enfrentados pelo Ethereum durante a transição para PoS. Desenvolveu-se vários mecanismos para fortalecer a descentralização e a equidade, ao mesmo tempo em que se realizou uma reforma econômica de stake para proteger os interesses dos usuários.

《The Verge》：discutiu os desafios e soluções da verificação de estado sem estado do Ethereum, focando em como tecnologias como árvores Verkle e STARK melhoram a Descentralização e eficiência da blockchain.

Em 26 de outubro, Vitalik Buterin publicou um artigo sobre "The Purge", no qual discutiu como os desafios enfrentados pela Ethereum enfrentam a complexidade e as necessidades de armazenamento a longo prazo, ao mesmo tempo que mantém a persistência e a descentralização da rede. As medidas-chave incluem a redução do fardo de armazenamento do cliente através de "expiração de histórico" e "expiração de estado", e simplificando o protocolo através de "limpeza de características", para garantir a sustentabilidade e escalabilidade da rede.

O seguinte é o conteúdo original, traduzido pela Odaily Planet Daily.

Agradeço especialmente os comentários e revisões de Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden e Tomasz Stanczak.

Um dos desafios enfrentados pelo Ethereum é que, por padrão, a expansão e complexidade de qualquer protocolo de bloco aumentam com o tempo. Isso ocorre em dois lugares:

Dados Históricos: Todas as transações realizadas e todas as contas criadas em qualquer momento da história precisam ser permanentemente armazenadas por todos os clientes e baixadas por qualquer novo cliente para se sincronizar totalmente com a rede. Isso resulta em um aumento contínuo na carga e no tempo de sincronização do cliente com o passar do tempo, mesmo que a capacidade da cadeia permaneça inalterada.

A funcionalidade do protocolo: adicionar novas funcionalidades é muito mais fácil do que remover antigas, o que resulta no aumento da complexidade do código ao longo do tempo.

Para manter o Ethereum a longo prazo, precisamos de uma forte pressão contrária a essas duas tendências que, com o tempo, diminuem a complexidade e a expansão da cadeia. Mas, ao mesmo tempo, precisamos preservar uma das principais propriedades que tornam a blockchain ótima: a persistência. Você pode deixar um token não fungível, uma carta de amor em uma transação ou um contrato inteligente que contém 1 milhão de dólares na cadeia, entrar em uma caverna por dez anos e sair para descobrir que ele ainda está lá esperando por você para ler e interagir. Para DApps terem a tranquilidade de se tornarem totalmente descentralizados e atualizarem suas chaves secretas, eles precisam ter certeza de que suas dependências não serão atualizadas de uma forma que possa prejudicá-los - especialmente o L1 em si.

Se nos comprometermos a equilibrar essas duas necessidades e, ao mesmo tempo, minimizar ou reverter ao máximo a obesidade, a complexidade e a decadência, é absolutamente possível. Os organismos vivos podem fazer isso: embora a maioria dos organismos vivos envelheça ao longo do tempo, alguns sortudos não o fazem. Até mesmo sistemas sociais podem ter uma vida útil muito longa. Em alguns casos, o Ethereum já teve sucesso: o trabalho de prova desapareceu, a maioria dos códigos de operação SELFDESTRUCT desapareceu, e os nós da cadeia de beacons armazenam dados antigos por até seis meses. Encontrar esse caminho de forma mais geral para o Ethereum e chegar a um resultado final de estabilidade a longo prazo é o desafio definitivo para a escalabilidade, sustentabilidade técnica e até mesmo segurança a longo prazo do Ethereum.

O Purge: principais objetivos.

Através da redução ou eliminação da necessidade de armazenamento permanente de todos os registros históricos e até mesmo do estado final em cada Nó, os requisitos de armazenamento do cliente Gota são reduzidos.

Reduzir a complexidade do Gotaprotocolo eliminando funcionalidades desnecessárias.

Índice do Artigo:

Expiração do histórico (历史记录到期)

Expiração do estado

Limpeza de recursos

Expiração do histórico

O que problema está sendo resolvido?

No 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órico: dados sobre blocos históricos, transações e recibos, muitos dos quais têm vários anos de idade. Isso significa que, mesmo que as restrições de gás não aumentem, o tamanho do nó continuará aumentando centenas de GB a cada ano.

O que é isso, como funciona?

Uma característica-chave de simplificação do problema de armazenamento histórico é que, como cada bloco aponta para o bloco anterior através de links de hash (e outras estruturas), alcançar consenso atual é suficiente para alcançar consenso histórico. Desde que a rede chegue a um consenso no 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 de Merkle, e essa prova permite que qualquer outra pessoa verifique sua correção. O consenso é um modelo de confiança N/2-de-N, enquanto o histórico é um modelo de confiança N-de-N.

Isso nos dá muitas opções sobre como armazenar o histórico. Uma escolha natural é que cada Nó armazene apenas uma pequena parte dos dados da rede. Esta tem sido a maneira como as redes de semente têm operado há décadas: embora a rede armazene e distribua um total de milhões de arquivos, cada participante armazena e distribui apenas alguns deles. Surpreendentemente, este método pode até não garantir a robustez dos dados. Se fizermos com que os Nós sejam mais econômicos, poderemos estabelecer uma rede com 100.000 Nós, onde cada Nó armazena aleatoriamente 10% do histórico, resultando em cada dado sendo replicado 10.000 vezes - o mesmo fator de replicação de 10.000 Nós - uma rede de Nós onde cada Nó armazena todo o conteúdo.

Atualmente, a Ethereum está começando a se afastar do modelo em que os nós armazenam permanentemente todo o histórico. A parte do bloco de consenso (ou seja, a parte relacionada ao consenso de prova de participação) armazena apenas cerca de 6 meses. O Blob armazena apenas cerca de 18 dias. A EIP-4444 tem como objetivo introduzir um período de armazenamento de um ano para blocos e recibos históricos. 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 estabelecer uma rede ponto a ponto composta por nós Ethereum para armazenar dados antigos de forma distribuída.

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

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

EIP-4444;

Torrents e EIP-4444;

Rede do portal;

Rede de portal e EIP-4444;

Armazenamento e recuperação distribuídos de objetos SSZ no Portal;

Como aumentar o limite de gás (Paradigma).

O que mais precisa ser feito e o que precisa ser considerado?

O trabalho restante principal inclui a construção e integração de uma solução distribuída específica para armazenar registros históricos - pelo menos para executar registros históricos, mas também inclui Consenso e blob. A solução mais simples é (i) simplesmente introduzir a biblioteca torrent existente e (ii) o solução nativa do Ethereum chamada Rede Portal. Uma vez que qualquer um deles seja introduzido, podemos abrir o EIP-4444. O EIP-4444 em si não requer uma forquilha dura, mas requer uma nova versão do protocolo de rede. Portanto, vale a pena ativá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de falha do cliente que espera baixar o histórico completo ao se conectar a outros Nós, mas na realidade não o obtém.

A principal consideração envolve 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 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, é construir e integrar primeiramente uma rede de torrent para armazenar registros históricos de forma distribuída. Aqui, 'o quão duro trabalhamos' tem duas dimensões:

Como garantimos que o maior conjunto de Nós armazena realmente todos os dados?

Até que profundidade integramos o armazenamento histórico no protocolo Profundidade?

Para um método extremamente paranóico de (1) envolveria uma prova de custódia: na realidade, exigiria que cada validador de Prova de Staking armazenasse uma certa proporção de registros históricos e os verificasse periodicamente de forma encriptação. Uma abordagem mais suave seria estabelecer um padrão voluntário de percentagem de histórico armazenado para cada cliente.

Para (2), a implementação básica envolve apenas o trabalho já concluído hoje: o Portal já armazenou o arquivo ERA contendo todo o histórico do Ethereum. Uma implementação mais completa envolveria conectá-lo ao processo de sincronização, para que, se alguém quiser sincronizar com um Nó de Armazenamento completo ou um Nó de Arquivo, mesmo que não haja outros Nós de Arquivo online, eles possam alcançá-lo por meio de sincronização direta a partir da rede do portal.

Como interage com outras partes do roteiro?

Se quisermos tornar a execução ou inicialização do Nó extremamente fácil, então a redução da necessidade de armazenamento histórico pode ser considerada mais importante do que a ausência de estado: dos 1,1 TB necessários pelo Nó, cerca de 300 GB são estado e os restantes 800 GB já são históricos. A visão de executar um Nó Ethereum em um smartwatch e configurá-lo em apenas alguns minutos só pode ser realizada com a implementação de estado ausente e EIP-4444.

A restrição de armazenamento histórico também torna mais viável a implementação de Nó Ethereum mais recente, suportando apenas as versões mais recentes do protocolo, o que as torna mais simples. Por exemplo, agora é seguro excluir várias linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Agora que a mudança para a prova de aposta se tornou história, os clientes podem excluir com segurança todo o código relacionado à prova de trabalho.

Expiração do estado

O que problema está sendo resolvido?

Mesmo que eliminemos a necessidade de histórico de armazenamento do cliente, as necessidades de armazenamento do cliente continuarão a subir, cerca de 50 GB por ano, devido à contínua subida do saldo da conta e números aleatórios, código de contrato e armazenamento de contratos. Os usuários podem pagar uma taxa única, aliviando assim o fardo dos clientes atuais e futuros da Éter.01928374656574839201

O estado é mais difícil de 'expirar' do que o histórico, porque a EVM foi projetada em torno de uma suposição fundamental: uma vez que um objeto de estado é criado, ele existe permanentemente e pode ser lido a qualquer momento por qualquer transação. Se introduzirmos a não-estado, alguns argumentam que esse problema pode não ser tão ruim: apenas a classe Bloco especializada precisa armazenar o estado real, enquanto todos os outros Nós (até mesmo os geradores de lista!) podem ser executados sem estado. No entanto, há uma visão de que não queremos depender muito da não-estado e, eventualmente, podemos querer 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: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) configurando um slot de armazenamento previamente inexplorado), esse objeto de estado permanece nesse estado para sempre. Pelo contrário, o que queremos é que o objeto expire automaticamente com o tempo. O desafio chave é fazer isto de uma forma que alcance três objetivos:

Eficiência: não é necessário um grande número de cálculos adicionais para executar o processo de expiração.

Usabilidade do utilizador: se alguém entrar numa caverna durante cinco anos e regressar, não deve perder o acesso a posições ETH, ERC20, Token não fungível, CDP...

Amigável para os desenvolvedores: os desenvolvedores não precisam mudar para um modelo mental completamente desconhecido. Além disso, os aplicativos atualmente rígidos e não atualizados devem continuar funcionando normalmente.

Se você não atingir essas metas, é fácil resolver o problema. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador de data de expiração (a data de expiração pode ser estendida gravando ETH, o que pode acontecer automaticamente a qualquer momento de leitura ou gravação) e ter um processo que percorre o estado para remover a data de expiração do objeto de estado. No entanto, isso introduz computação adicional (e até mesmo requisitos de armazenamento), e certamente não atende aos requisitos de facilidade de uso. Também é difícil para os desenvolvedores raciocinar sobre casos de borda envolvendo 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 facilitará a vida do desenvolvedor, mas tornará a economia mais difícil: o desenvolvedor terá que pensar em como "repassar" os custos de armazenamento contínuos para o usuário.

Estes são os problemas que a comunidade de desenvolvimento central do Ethereum tem vindo a tentar resolver ao longo dos anos, incluindo propostas como "Bloco chain rent" e "regeração". No final, combinamos as melhores partes das propostas e focamo-nos em duas categorias de "soluções conhecidas menos más":

• Algumas soluções para estados expirados
• Recomendação de expiração de estado com base no ciclo de Endereço.

Expiração parcial do estado

Algumas propostas de vencimento de estado seguem os mesmos princípios. Dividimos o estado em blocos. Cada pessoa armazena permanentemente um 'mapeamento de nível superior', onde o bloco pode estar vazio ou não. Os dados em cada bloco só são armazenados quando são acessados recentemente. Existe um mecanismo de 'ressurreição' se os dados não forem mais armazenados.

A principal diferença entre essas propostas é: (i) como definimos "recente" e (ii) como definimos "bloco"? Uma proposta específica é EIP-7736, que se baseia no design de "folha de caule" introduzido para a árvore Verkle (embora seja compatível com qualquer forma de estado sem estado, como uma árvore binária). Nesse design, cabeçalhos, códigos e slots de armazenamento adjacentes são armazenados sob o mesmo "tronco". Os dados armazenados sob um tronco podem ser de no máximo 256 * 31 = 7.936 bytes. Em muitos casos, o cabeçalho completo e o código da conta, juntamente com muitos slots de armazenamento de chaves, serão armazenados sob o mesmo tronco. Se os dados sob um tronco específico não forem lidos ou escritos nos últimos 6 meses, os dados não serão mais armazenados, apenas um compromisso de 32 bytes para os dados (um "stub"). Transações futuras que acessem esses dados precisarão "ressuscitar" os dados e fornecer uma prova que verifica de acordo com o stub.

Existem outras maneiras de implementar ideias semelhantes. Por exemplo, se a granularidade do nível da conta não for suficiente, podemos criar um plano em que cada parte 1/232 da árvore seja controlada por um mecanismo semelhante de caule e folha.

Devido a incentivos, isso se torna mais complicado: um atacante pode forçar o cliente a armazenar permanentemente uma grande quantidade de estado, colocando uma grande quantidade de dados em uma única subárvore e enviando uma transação por ano para 'atualizar' a árvore. Se você tornar o custo de renovação proporcional ao tamanho da árvore (ou inversamente proporcional à duração da renovação), alguém pode prejudicar outros usuários colocando uma grande quantidade de dados na mesma subárvore que eles. As pessoas podem tentar limitar esses dois problemas tornando a granularidade dinâmica com base no tamanho da subárvore: por exemplo, cada grupo de 216=65536 objetos de estado consecutivos pode ser considerado um 'grupo'. No entanto, essas ideias são mais complexas; a abordagem baseada em tronco é simples e as medidas de incentivo podem ser ajustadas, pois geralmente todos os dados sob o tronco estão relacionados ao mesmo aplicativo ou usuário.

Recomendação de vencimento de estado com base no ciclo de Endereço

Se quisermos evitar completamente qualquer estado permanente subir, mesmo um stub de 32 bytes, o que podemos fazer? Devido a conflitos de ressurreição, isso é um problema: se um objeto de estado for excluído, uma execução posterior do EVM colocará outro objeto de estado exatamente na mesma posição, mas o que fazer quando alguém que se preocupa com o objeto de estado original voltar e tentar recuperá-lo? Quando parte do estado expira, o 'stub' impede a criação de novos dados. À medida que o estado expira completamente, nem mesmo podemos armazenar o 'stub'.

O design baseado no ciclo de Endereço é a ideia mais famosa para resolver esse problema. Em vez de armazenar todo o estado em uma árvore de estados, temos uma lista de árvores de estados que está subindo constantemente, e qualquer estado lido ou escrito será mantido na árvore de estados mais recente. Um novo estado vazio é adicionado a cada período (por exemplo, 1 ano). As árvores antigas são congeladas. O nó completo armazena apenas as duas árvores mais recentes. Se um objeto de estado não é tocado em dois períodos e cai em uma árvore expirada, ainda pode ser lido ou escrito, mas a transação precisa provar seu Merkle proof - uma vez provado, uma cópia será mantida novamente na árvore mais recente.

Uma ideia-chave que torna isso amigável para usuários e desenvolvedores é o conceito de ciclo de Endereço. O ciclo de Endereço é um número que faz parte do Endereço. A regra chave é que um Endereço com ciclo N só pode ser lido ou escrito durante ou após o ciclo N (ou seja, quando a lista da árvore de estados atinge o comprimento N). Se você deseja armazenar um novo objeto de estado (por exemplo, um novo contrato ou um novo saldo ERC20), pode fazê-lo imediatamente, sem a necessidade de fornecer provas, desde que coloque o objeto de estado em um contrato com ciclo de Endereço de N ou N-1. Por outro lado, qualquer adição ou edição feita durante um ciclo de Endereço antigo requer provas.

Este design mantém a maioria das características atuais do Ethereum, sem a necessidade de cálculos adicionais, permitindo a escrita de aplicações quase como agora (ERC20 precisa ser reescrito para garantir que o saldo do Endereço com ciclo N seja armazenado no subcontrato, que tem ciclo N), resolvendo o problema de 'entrar na caverna por cinco anos'. No entanto, ele tem um grande problema: o Endereço precisa ser expandido para mais de 20 bytes para acomodar o ciclo do Endereço.

Address space extension空间扩展

Uma sugestão é introduzir um novo formato de Endereço de 32 bytes, que inclui um número de versão, um número de ciclo de Endereço e um hash de extensão.

0x01 (vermelho) 0000 (laranja) 000001 (verde) 57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF (azul).

O vermelho é o número da versão. Os quatro zeros em laranja aqui são para criar um espaço em branco para acomodar o número de fragmentação no futuro. O verde é o número do ciclo do Endereço. O azul é um valor de hash de 26 bytes.

O desafio-chave aqui é a compatibilidade com versões anteriores. Os contratos existentes são projetados em torno de um Endereço de 20 bytes e geralmente usam uma técnica rigorosa de empacotamento de bytes, assumindo explicitamente que o Endereço tem exatamente 20 bytes de comprimento. Uma ideia para resolver esse problema envolve um mapeamento de conversão, onde os contratos antigos que interagem com o novo Endereço verão o valor de hash de 20 bytes do novo Endereço. No entanto, garantir a sua segurança envolve uma grande complexidade.

Encolhimento do Espaço de Endereço

Outra abordagem seria seguir a direção oposta: proibir imediatamente algumas subfaixas de Endereço de tamanho 2128 (por exemplo, todos os Endereços que começam com 0xffffffff), e em seguida, introduzir Endereços com um ciclo de Endereço e um valor de hash de 14 bytes nessa faixa.

0xffffffff000169125d5dFcb7B8C2659029395bdF

O principal sacrifício feito por esse método é a introdução do risco de segurança de Endereço contrafactual: um Endereço que detém ativos ou permissões, mas cujo código ainda não foi publicado na cadeia. O risco envolve alguém criando um Endereço que alega possuir um código (ainda não publicado), mas também há outro código válido que hash para o mesmo Endereço. Hoje, calcular tal colisão requer 280 hashes; a contração do espaço do Endereço reduzirá esse número para 256 hashes fáceis de acessar.

Áreas-chave de risco, ou seja, Endereço de Carteira de facto alternativo não detido por um único proprietário, são relativamente raras hoje em dia, mas podem tornar-se mais comuns à medida que entramos no mundo L2. A única solução é simplesmente aceitar esse risco, mas identificar todos os casos de uso comuns onde possam surgir problemas e propor soluções eficazes.

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

Proposta inicial

• Bloco链清洁；
• Regeneração;
• Teoria de gerenciamento de tamanho de estado do Ethereum;
• Algumas possíveis trajetórias para estados sem estado e expiração de estado;

Proposta de vencimento parcial do estado

• EIP-7736;

Endereço空间扩展文档

• Proposta Original;
• Comentário Ipsilon;
• Comentários de artigos do blog;
• O que será danificado se perdermos a resistência ao impacto.

O que mais precisa ser feito e o que precisa ser considerado?

Eu acho que existem quatro caminhos viáveis para o futuro:

• Nós somos stateless e nunca introduzimos expiração de estado. O estado está aumentando continuamente (embora lentamente: pode levar décadas para chegarmos a mais de 8 TB), mas só precisa ser mantido por usuários de categorias relativamente especiais: nem mesmo validadores PoS precisam do estado. Uma funcionalidade que requer acesso a parte do estado é a geração de listas inclusivas, mas podemos fazer isso de forma descentralizada: cada usuário é responsável por manter uma parte da árvore de estado que inclui sua própria conta. Quando eles transmitem uma transação, eles transmitem a transação junto com uma prova do objeto de estado acessado durante a etapa de validação (isso se aplica a contas EOA e ERC-4337). Em seguida, validadores stateless podem combinar essas provas em uma prova que inclui a lista inteira.
• Nós estamos fazendo parte do estado expirar e aceitando uma taxa de crescimento do tamanho do estado permanente muito menor, mas ainda não nula. Este resultado pode ser dito ser semelhante a como as propostas de expiração histórica envolvendo redes peer-to-peer são aceitas e cada cliente deve armazenar uma taxa de crescimento permanente histórica muito menor, mas ainda não nula, de dados históricos fixa e mais baixa.
• Estamos a expandir o espaço Endereço para a expiração de estados. Isso envolverá um processo de vários anos para garantir que o método de conversão de formato Endereço seja eficaz e seguro, incluindo aplicações existentes.
• Estamos a reduzir o espaço do Endereço para expirar o estado. Isso envolverá um processo de vários anos para garantir que todos os riscos de segurança relacionados com conflitos de Endereço (incluindo casos de interação entre cadeias) sejam tratados.

Uma questão importante é que, independentemente de se implementar um esquema de estado de expiração que dependa de alterações de formato de Endereço, no final, é necessário resolver os problemas de expansão e contração do espaço de Endereço. Atualmente, gerar conflitos de Endereço requer aproximadamente 280 valores hash, o que é viável para participantes muito ricos em recursos: as GPUs podem calcular cerca de 227 valores hash, o que significa que podem calcular um em cerca de 252 dias, portanto, cerca de 230 GPUs em todo o mundo podem calcular um conflito em aproximadamente 1/4 de ano, enquanto as FPGA e ASIC podem acelerar ainda mais esse processo. No futuro, esse tipo de ataque estará ao alcance de um número crescente de pessoas. Portanto, o custo real da implementação de um esquema de estado de expiração completo pode não ser tão alto quanto parece, pois de qualquer forma, é necessário resolver este problema de Endereço extremamente desafiador.

Como interage com outras partes do roteiro?

A expiração de estados pode tornar mais fácil a conversão de um formato de árvore de estados para outro, pois o processo de conversão não é necessário: você pode simplesmente começar a criar uma nova árvore com o novo formato e, em seguida, realizar um hard fork para converter a árvore antiga. Portanto, embora a expiração de estados seja complexa, ela realmente beneficia outras partes do roteiro de simplificação.

Limpeza de recursos

Que problema resolve?

Uma das condições prévias fundamentais para a segurança, acessibilidade e neutralidade de confiança é a simplicidade. Se o protocolo for bonito e simples, reduzirá a probabilidade de erros. Isso aumenta as oportunidades para que novos desenvolvedores possam participar de qualquer parte dele. É mais provável que seja justo e também mais fácil de resistir a interesses especiais. Infelizmente, assim como qualquer sistema social, o protocolo tende a se tornar mais complexo com o tempo. Se não quisermos que o Ethereum caia em um buraco negro de crescente complexidade, precisamos fazer uma das duas coisas: (i) parar de fazer alterações e tornar o protocolo inflexível, (ii) ser capaz de realmente remover recursos e Gota complexidade. Um meio-termo também é possível, ou seja, fazer menos alterações no protocolo e, ao longo do tempo, pelo menos eliminar um pouco da complexidade. Esta seção discutirá como reduzir ou eliminar a complexidade.

O que é isso, como funciona?

Não há nenhuma correção significativa única que possa reduzir a complexidade do protocolo; a natureza deste problema é que existem muitas pequenas soluções.

Um exemplo concluído em grande parte é a remoção do código de operação SELFDESTRUCT e pode servir como um modelo para lidar com outros exemplos. O código de operação SELFDESTRUCT é o único que pode modificar um número ilimitado de slots de armazenamento em um único bloco, exigindo uma complexidade significativamente maior na implementação do cliente para evitar ataques DoS. O objetivo original deste código de operação era permitir a liquidação voluntária do estado, permitindo que o tamanho do estado diminuísse ao longo do tempo. Na prática, poucas pessoas acabaram usando-o. O código de operação foi enfraquecido, permitindo apenas a criação de contas de autodestruição na mesma transação de uma bifurcação difícil de Dencun. Isso resolve o problema de DoS e pode simplificar significativamente o código do cliente. No futuro, a remoção completa do código de operação pode fazer sentido.

Até agora, alguns exemplos-chave de oportunidades de simplificação do protocolo identificado incluem o seguinte. Primeiro, alguns exemplos fora do EVM; estes são relativamente não invasivos, tornando-os mais fáceis de atingir consenso e implementar em menos tempo.

RLP → SSZ conversão: Inicialmente, os objetos Ethereum eram serializados usando um método chamado RLP. RLP é não tipificado e desnecessariamente complexo. Atualmente, a cadeia beacon utiliza SSZ, que é significativamente melhor em muitos aspectos, incluindo o suporte não apenas à serialização, mas também ao hash. Em última análise, esperamos eliminar completamente o RLP e migrar todos os tipos de dados para a estrutura SSZ, o que facilitará as atualizações. Os EIP atuais incluem 01928374656574839201[1][2]。

Remover tipos de transação antigos: Existem muitos tipos de transação atualmente, muitos dos quais podem ser removidos. Uma alternativa mais suave à remoção completa é a funcionalidade de abstração de conta, onde contas inteligentes podem incluir código para processar e validar transações antigas (se desejarem).

LOG reforma: A criação de Filtro Bloom e outras lógicas aumentou a complexidade do protocolo, mas na realidade não são usadas pelo cliente, porque é demasiado lento. Podemos remover essas funcionalidades e concentrar-nos em alternativas, como o uso de tecnologias modernas como SNARK para um protocolo de leitura de registos descentralizado.

Eventual remoção do mecanismo do comitê de sincronização de beacon de cadeia: O mecanismo do comitê de sincronização foi originalmente introduzido para permitir a verificação de cliente ligeiro na troca ETH. No entanto, aumenta significativamente a complexidade do protocolo. Eventualmente, poderemos usar diretamente SNARKs para validar a camada ETH Consenso, o que eliminará a necessidade de um cliente ligeiro dedicado para validar o protocolo. Potencialmente, a mudança do Consenso poderia nos permitir remover o comitê de sincronização mais cedo, criando um cliente ligeiroprotocolo mais "nativo" que envolve a verificação de assinaturas de um subconjunto aleatório de validadores do ETH Square Consenso.

Unificação do formato de dados: Atualmente, o estado de execução é armazenado em uma árvore de Merkle Patricia, o estado do Consenso é armazenado em uma árvore SSZ, e o blob é submetido através do compromisso KZG. No futuro, faz sentido ter um único formato unificado para os dados do bloco e um único formato unificado para o estado. Esses formatos atenderão a todas as necessidades importantes: (i) prova simples para clientes sem estado, (ii) serialização e codificação de apagamento de dados, (iii) estrutura de dados padronizada.

Remoção do comité da cadeia beacon: Este mecanismo foi inicialmente introduzido para apoiar a execução da Fragmentação numa versão específica. Em vez disso, acabámos por realizar a Fragmentação através de L2 e blob. Assim, o comité tornou-se desnecessário e, portanto, estamos a tomar medidas para o remover.

Remover a ordem dos bytes mistos: EVM é big-endian, a camada de consenso é little-endian. Reconciliar e tornar tudo uma coisa ou outra pode fazer sentido (talvez big-endian, porque EVM é mais difícil de alterar)

Agora, alguns exemplos no EVM:

Simplificação do mecanismo de gás: As regras atuais de gás ainda não foram bem otimizadas, não sendo possível fornecer restrições claras sobre a quantidade de recursos necessários para validar um bloco. Exemplos-chave incluem (i) custo de leitura/escrita de armazenamento, que visa limitar o número de leituras/escritas em um bloco, mas atualmente é bastante arbitrário, e (ii) regras de preenchimento de memória, que é difícil estimar o consumo máximo de memória do EVM. As medidas de correção propostas incluem mudanças nos custos de gás sem estado (unificando todos os custos relacionados ao armazenamento em uma fórmula simples) e uma proposta de precificação de memória.

Eliminar pré-compilação: A Ethereum tem atualmente muitas pré-compilações que são desnecessariamente complexas, relativamente não utilizadas e constituem uma grande parte do fracasso do Consenso, pois são quase não utilizadas por qualquer aplicação. Duas abordagens para lidar com este problema são (i) simplesmente remover as pré-compilações e (ii) substituí-las por uma seção de código EVM que implemente a mesma lógica (inevitavelmente mais cara). Este rascunho de EIP sugere que a primeira etapa seja executada nas pré-compilações de identidade; mais tarde, RIPEMD160, MODEXP e BLAKE podem ser candidatos à remoção.

Remoção de gás observável: faz com que a EVM não possa mais ver quanto gás ainda resta. Isso afetará alguns aplicativos (mais notavelmente transações patrocinadas), mas tornará futuras atualizações mais fáceis (por exemplo, para versões mais avançadas de gás multidimensional). A especificação EOF já torna o Gas não observável, mas para simplificar o protocolo, o EOF precisa se tornar obrigatório.

Melhorias na análise estática: atualmente, o código EVM é difícil de analisar estaticamente, especialmente porque os saltos podem ser dinâmicos. Isso também torna mais difícil otimizar a implementação do EVM (pré-compilando o código EVM para outras linguagens). Podemos resolver esse problema removendo saltos dinâmicos (ou tornando-os mais caros, por exemplo, o custo de gás linear do número total de JUMPDESTs no contrato). EOF faz exatamente isso, embora a execução forçada do EOF seja necessária para obter os benefícios de simplificação do protocolo.

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

• Passos seguintes para limpeza;
• Auto-destruição
• SSZ 化 EIPS：[1][2]；
• Custos de gás sem estado variáveis;
• Preço de memória linear;
• Pré-compilação excluída;
• Filtro Bloom移除；
• Um método de recuperação segura de logs usando cálculos verificáveis incrementalmente fora da cadeia (leia-se: STARK recursivo);

O que mais precisa ser feito e o que precisa ser considerado?

A principal ponderação para simplificar essa funcionalidade é (i) o grau e a velocidade de simplificação e (ii) a retrocompatibilidade. O valor do Ethereum como plataforma deriva do fato de ser uma plataforma na qual as aplicações podem ser implementadas e ter a garantia de que continuarão a funcionar muitos anos depois. Ao mesmo tempo, esse ideal pode ser levado longe demais, para usar as palavras de William Jennings Bryan, 'crucificando o Ethereum na cruz da retrocompatibilidade'. Se apenas duas aplicações em toda a Ethereum utilizam uma determinada funcionalidade, e uma delas não tem nenhum usuário há anos, enquanto a outra quase não é utilizada e tem um valor total de 57 dólares, então deveríamos remover a funcionalidade e reembolsar as vítimas em 57 dólares, se necessário.

Um problema social mais amplo é criar um canal padronizado para alterações não urgentes de incompatibilidade retroativa. Uma maneira de resolver esse problema é examinar e expandir os precedentes existentes, como o processo de autodestruição. O pipeline se parece com o seguinte:

• Começar a falar sobre a função de exclusão X;
• Ao analisar e determinar o impacto da remoção de X no aplicativo, isso dependerá do resultado: (i) abandonar a ideia, (ii) continuar conforme planejado, ou (iii) determinar a abordagem modificada 'menos disruptiva' para remover X e continuar;
• Elabore um EIP oficial para descontinuar X. Garanta que infraestruturas populares de nível superior (como linguagens de programação, Carteira) respeitem isso e parem de usar essa funcionalidade.
• Por fim, elimine X na prática;
• Deve haver um pipeline de vários anos entre as etapas 1 e 4, e deve ser claramente especificado quais projetos estão em qual etapa. Neste ponto, é necessário equilibrar a dinâmica e velocidade do processo de remoção de recursos com a abordagem mais conservadora e com mais recursos investidos em outras áreas de desenvolvimento do protocolo, mas ainda estamos longe da fronteira de Pareto.

EOF

Um conjunto de alterações principais propostas para o EVM é o formato de objeto EVM (EOF). O EOF introduz várias mudanças, como a proibição da observabilidade do gás, a observabilidade do código (ou seja, sem CODECOPY) e apenas permitir saltos estáticos. O objetivo é permitir que o EVM seja atualizado de maneira mais robusta, mantendo a compatibilidade com versões anteriores (pois o EVM anterior ao EOF ainda existe).

A vantagem disso é que cria um caminho natural para adicionar novas funcionalidades ao EVM e incentiva a migração para um EVM mais rigoroso e com garantias. A desvantagem é que isso aumenta significativamente a complexidade do protocolo, a menos que possamos encontrar uma maneira de eventualmente descontinuar e remover o antigo EVM. Uma questão importante é: o que EOF desempenha no EVM simplificado, especialmente se o objetivo for reduzir a complexidade de Gota em todo o EVM?

Como interage com outras partes do roteiro?

Muitas das sugestões de "melhoria" na parte restante do roteiro são também oportunidades de simplificar as funcionalidades antigas. Repetindo alguns dos exemplos acima:

• Mudar para a máxima finalidade de slot único nos dá a oportunidade de desativar comissões, redesenhar a economia e simplificar outros aspectos relacionados ao Proof of Staking.
• A implementação completa da abstração de contas pode permitir-nos eliminar uma grande quantidade de lógica de processamento de transações existente, movendo-a para o "código EVM padrão da conta" que pode ser substituído por todos os EOA.
• Se transferirmos o estado do Ethereum para uma árvore de hash binária, isso pode ser compatível com a nova versão do SSZ para que todas as estruturas de dados do Ethereum possam ser hashadas da mesma maneira.

Método mais radical: transformar a maior parte do protocolo em código de contrato

Uma estratégia simplificada mais radical da Ethereum é manter o protocolo inalterado, mas transferir a maior parte de suas funcionalidades do protocolo para o código do contrato.

A versão mais extrema seria tornar o ETH L1 apenas uma cadeia beacon 'tecnicamente' e introduzir uma Máquina virtual mínima (como RISC-V, Cairo ou a menor especializada em sistemas de prova), permitindo que outros criem suas próprias agregações. Então o EVM se tornaria o primeiro dessas agregações. Ironicamente, isso é exatamente o que foi proposto em 2019-20, embora o SNARK torne sua implementação real mais viável.

Uma abordagem mais suave seria manter a relação entre a cadeia beacon e o ambiente de execução atual do Ethereum, mas trocar o EVM no local. Podemos escolher RISC-V, Cairo ou outra VM como a nova 'VM oficial do Ethereum', e depois forçar a conversão de todos os contratos EVM para o novo código da VM que interpreta a lógica do código-fonte original (por meio de compilação ou interpretação). Teoricamente, isso poderia até ser feito como uma versão do 'Máquina virtual de destino' como EOF.