Agradecemos especialmente os feedbacks e revisões de Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden e Tomasz Stanczak.

Uma das dificuldades do Éter é que, por padrão, a expansão e complexidade de qualquer Blockchain protocolo de Bloco aumentarão 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 todos os novos clientes para uma sincronização completa com a rede. Isso resultará 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.

Função do protocolo: Adicionar novas funcionalidades é muito mais fácil do que remover as antigas, o que leva a um aumento na complexidade do código ao longo do tempo.

Para que o Ethereum possa ser sustentado a longo prazo, precisamos exercer forte pressão contrária a essas duas tendências, à medida que o tempo passa, a complexidade e a expansão da Gota. Mas ao mesmo tempo, precisamos manter uma das propriedades-chave que tornam a blockchain grande: a persistência. Você pode colocar um Token não fungível, 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 descobrir que ainda está lá, esperando para ser lido e interagido. Para que os DApps possam com segurança se tornar totalmente descentralizados e remover a Chave Secreta de atualização, eles precisam ter certeza de que suas dependências não serão atualizadas de forma a prejudicá-los - especialmente a L1 em si.

Se nos comprometermos a equilibrar essas duas necessidades e minimizar ou reverter a obesidade, complexidade e declínio ao máximo, mantendo a continuidade, isso é absolutamente possível. Os organismos vivos podem fazer isso: embora a maioria dos organismos vivos envelheça com o tempo, alguns sortudos não o fazem. Mesmo os sistemas sociais podem ter uma vida útil muito longa. Em alguns casos, Ethereum já teve sucesso: o trabalho de prova desapareceu, a maioria dos códigos de operação SELFDESTRUCT desapareceu, e o nó beacon da cadeia armazenou dados antigos por até seis meses. Encontrar esse caminho de maneira mais geral para Ethereum e seguir em direção ao resultado final de longo prazo é o desafio final da escalabilidade, sustentabilidade técnica e até mesmo da segurança de longo prazo do Ethereum.

The Purge: Principais objetivos.

· Ao reduzir ou eliminar a necessidade de cada Nó armazenar permanentemente todos os registros históricos ou até mesmo o estado final, reduz os requisitos de armazenamento do cliente Nó.

· Reduzindo a complexidade do Gotaprotocolo, eliminando funções desnecessárias.

Índice do artigo:

· História de expiração

· Expiração do estado

· Limpeza de recursos (Feature cleanup)

História de expiração

Que problema resolve?

No momento em que este artigo foi escrito, 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, a maioria 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á a aumentar 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 por meio 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 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 uma prova de Merkle, e essa prova permite que qualquer outra pessoa a verifique. O consenso é um modelo de confiança N/2-de-N, enquanto o histórico é um modelo de confiança N-de-N.

Isto oferece-nos muitas opções para armazenar o histórico. Uma escolha natural é que cada Nó armazene apenas uma pequena parte dos dados da rede. Esta tem sido a forma como a rede de semente tem operado ao longo das décadas: embora a rede armazene e distribua milhões de ficheiros no total, cada participante armazena e distribui apenas alguns deles. Talvez contra-intuitivamente, este método nem sempre Gota a robustez dos dados. Se tornarmos os Nós mais eficientes economicamente, podemos construir uma rede com 100.000 Nós, em que cada Nó armazena aleatoriamente 10% do histórico, resultando em cada dado ser replicado 10.000 vezes - o mesmo fator de replicação que uma rede de 10.000 Nós - onde cada Nó armazena todo o conteúdo.

Atualmente, o Ethereum já começou a se afastar do modelo em que todos os nós armazenam permanentemente todo o histórico. A parte do ConsensoBloco (ou seja, a parte relacionada ao Consenso de Prova de Stake) agora armazena apenas cerca de 6 meses. O Blob armazena apenas cerca de 18 dias. O EIP-4444 tem como objetivo introduzir um período de armazenamento de um ano para histórico de Bloco 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, em seguida, estabelecer uma rede ponto a ponto composta por nós do Ethereum para armazenar os dados antigos de forma distribuída.

Erasure codes can be used to improve robustness while maintaining the same replication factor. In fact, Blob has already been erasure-coded to support data availability sampling. The simplest solution is likely to reuse these Erasure codes and also place the execution and Consenso block data in the blob.

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

· EIP-4444 ；

· Torrents and EIP-4444 ；

· Rede de portal;

· Rede de Portais 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, o que precisa ser ponderado?

O trabalho restante inclui a construção e integração de uma solução distribuída concreta para armazenar registros históricos - pelo menos a execução de registros históricos, mas eventualmente também inclui Consenso e blob. A solução mais simples é (i) introduzir simplesmente uma biblioteca torrent existente e (ii) uma solução nativa do Ethereum chamada Portal Network. Uma vez que qualquer uma delas seja introduzida, podemos abrir o EIP-4444. O próprio EIP-4444 não requer uma forquilha rígida, mas requer uma nova versão do protocolo de rede. Portanto, é valioso habilitá-lo para todos os clientes ao mesmo tempo, caso contrário, há o risco de falha dos clientes ao se conectarem a outros nós esperando baixar o histórico completo, mas na verdade 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 seria parar de armazenar dados históricos antigos a partir de amanhã e depender de nós de arquivo 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, é primeiro construir e integrar uma rede torrent para armazenar registros históricos de forma distribuída. Aqui, “quão duro tentamos” tem duas dimensões:

1. Como garantimos que o maior conjunto de Nó armazene todos os dados corretamente?

2. Quão profunda é a profundidade de armazenamento histórico integrada no protocolo Profundidade?

Uma abordagem extremamente obsessiva para (1) envolveria uma prova de custódia: efetivamente exigiria que cada validador de prova de aposta armazenasse uma certa proporção de registros históricos e os verificasse periodicamente de forma criptografada se eles o fizessem. Uma abordagem mais suave 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 já concluído hoje: o Portal já armazenou o arquivo ERA que contém todo o histórico do Ethereum. Uma implementação mais completa envolverá conectá-lo efetivamente ao processo de sincronização, para que, se alguém quiser sincronizar um nó de histórico completo ou um nó de arquivo, mesmo que não haja outros nós de arquivo online, eles possam alcançar isso por meio de sincronização direta a partir da rede do portal.

Como interage com as outras partes do roteiro?

Se quisermos tornar a execução ou inicialização de um Nó extremamente fácil, reduzir as necessidades de armazenamento histórico é mais importante do que a não ter estado: dos 1,1 TB necessários pelo Nó, cerca de 300 GB são para o estado e os restantes cerca de 800 GB já são históricos. Só com a implementação da falta de estado e do EIP-4444 é possível alcançar a visão de executar um Nó Ethereum numa smartwatch e configurá-lo em apenas alguns minutos.

A limitação do armazenamento histórico também torna mais viável a implementação de nós Ethereum mais recentes, suportando apenas as versões mais recentes do protocolo, tornando-as mais simples. Por exemplo, agora é seguro excluir muitas linhas de código, pois todos os slots de armazenamento vazios criados durante o ataque DoS de 2016 foram removidos. Com a mudança para a atestação, os clientes podem excluir com segurança todo o código relacionado ao PoW.

Expiração do estado

Que problema resolve?

Mesmo que eliminemos a necessidade de histórico de armazenamento do cliente, a demanda de armazenamento do cliente continuará a subir, cerca de 50 GB por ano, devido ao contínuo aumento do saldo da conta e números aleatórios, código de contrato e armazenamento de contrato. Os usuários podem pagar uma taxa única para aliviar o fardo para os clientes atuais e futuros da Ethereum.

O estado é mais difícil de ‘expirar’ do que a história, porque o EVM foi fundamentalmente projetado com base nesta suposição: uma vez que um objeto de estado é criado, ele existirá para sempre e pode ser lido a qualquer momento por qualquer transação. Se introduzirmos a falta de estado, alguns argumentam que talvez isso não seja tão ruim: apenas a classe de construtor de bloco especializado precisa armazenar o estado real, enquanto todos os outros nós (até mesmo incluindo a geração de listas!) podem funcionar sem estado. No entanto, há uma visão de que não queremos depender muito da falta de estado, e no final, talvez queiramos que o estado expire para manter a descentralização do Ethereum.

O que é isso, como funciona

Quando você cria um novo objeto de estado hoje (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, ou (iii) configurando um slot de armazenamento não tocado anteriormente), esse objeto de estado permanece nesse estado para sempre. Em vez disso, queremos que o objeto expire automaticamente ao longo do tempo. O desafio chave é fazer isso de uma maneira que atenda aos três objetivos.

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

2. Amigável para o usuário: se alguém entrar em uma caverna por cinco anos e voltar, eles não devem perder o acesso a ETH, ERC 20, Token não fungível, posição de CDP…

3. Amigável para os desenvolvedores: os desenvolvedores não precisam alternar para um modelo mental completamente desconhecido. Além disso, os aplicativos que estão atualmente rígidos e desatualizados 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 Rentável’ e ‘Recuperação’. No final, combinamos as melhores partes das propostas e concentramo-nos em duas categorias de ‘soluções conhecidas menos ruins’:

· Solução para expiração de alguns estados

· Proposta de expiração de estado com base no ciclo de Endereço.

Expiração parcial do estado 部分状态到期

Algumas propostas de expiração de status seguem o mesmo princípio. Dividimos o Estado em pedaços. Todos armazenam permanentemente o “mapeamento de nível superior”, onde os blocos estão vazios ou não vazios. Os dados em cada bloco são armazenados apenas se os dados tiverem sido acessados recentemente. Existe uma mecânica de “ressurreição” se ela não estiver mais armazenada

As principais diferenças entre essas propostas são: (i) como definimos o termo “recente” e (ii) como definimos o termo “bloco”? Uma proposta específica é a EIP-7736, que se baseia no design de “tronco-folha” introduzido para a árvore Verkle (embora seja compatível com qualquer forma de estado sem estado, como uma árvore binária). Nesse design, os cabeçalhos, códigos e slots de armazenamento adjacentes são armazenados sob o mesmo “tronco”. Os dados armazenados sob um tronco podem ter no máximo 256 * 31 = 7.936 bytes. Em muitos casos, o cabeçalho e o código completos da conta, bem como muitos slots de armazenamento de chaves, serão armazenados sob o mesmo tronco. Se os dados em um determinado tronco não forem lidos ou gravados nos últimos 6 meses, eles não serão mais armazenados, apenas o compromisso de 32 bytes desses dados (“stub”) será armazenado. Transações futuras que acessem esses dados precisarão “reviver” os dados e fornecer uma prova baseada no stub para verificar.

Existem outras maneiras de realizar ideias semelhantes. Por exemplo, se a granularidade do nível da conta não for suficiente, podemos elaborar um esquema em que cada uma das metades de 1/2 32 da árvore seja controlada por um mecanismo de folha semelhante.

Devido a incentivos, isso se torna ainda mais complicado: um atacante pode forçar o cliente a armazenar permanentemente uma grande quantidade de estados, colocando uma grande quantidade de dados em uma única subárvore e enviando uma transação por ano para ‘atualizar a árvore’. Se você fizer o custo de renovação ser 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 2^16 = 65536 objetos de estado consecutivos podem ser considerados um ‘grupo’. No entanto, essas ideias são mais complexas; o método baseado em ramos é simples e permite ajustar os incentivos, pois geralmente todos os dados sob o mesmo ramo estão relacionados à mesma aplicação ou usuário.

Recomendação de expiração de estado baseada no ciclo de Endereço

Se quisermos evitar completamente qualquer estado permanente subir, mesmo que seja um stub de 32 bytes, o que devemos fazer? Isso é um problema de ressurreição: 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 e se alguém interessado no objeto de estado original voltar e tentar recuperá-lo? Quando parte do estado expirar, o “stub” impede a criação de novos dados. À medida que o estado expira completamente, nem mesmo podemos armazenar o stub.

O design baseado em ciclo de Endereço é a ideia mais famosa para resolver este problema. Não armazenamos todo o estado em uma árvore de estados, mas temos uma lista de árvores de estados que sobem continuamente, e qualquer estado lido ou escrito é 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 completamente. 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 sua prova de Merkle - uma vez provada, uma cópia é mantida novamente na árvore mais recente.

Uma das ideias-chave para tornar isso amigável para os utilizadores e desenvolvedores é o conceito de ciclo Endereço. Um ciclo Endereço é um número que pertence a um Endereço. A regra fundamental é 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 de árvores de estado atinge o comprimento N). Se você deseja armazenar um novo objeto de estado (por exemplo, um novo contrato ou saldo ERC 20), pode fazê-lo imediatamente se garantir que o objeto de estado é colocado dentro de um contrato com ciclo Endereço N ou N-1, sem a necessidade de fornecer provas de que nada existia anteriormente. Por outro lado, qualquer adição ou edição feita durante um ciclo Endereço antigo exigirá prova.

Este design mantém a maioria das propriedades atuais do Ethereum, não requer cálculos adicionais, permite que as aplicações sejam escritas quase da mesma forma que agora (ERC 20 precisa ser reescrito para garantir que o saldo do Endereço com ciclo N seja armazenado no contrato secundário, que em si tem um ciclo Endereço N), resolvendo o problema do “usuário entrar na caverna por cinco anos”. No entanto, tem um grande problema: o Endereço precisa ser expandido para mais de 20 bytes para se adaptar ao ciclo Endereço.

Extensão do espaço de endereços

Uma sugestão é a introdução de 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 estendido.

0x01（vermelho）0000（laranja）000001（verde）57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF（azul）。

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

O desafio chave aqui é a compatibilidade retroativa. Os contratos existentes são projetados em torno do endereço de 20 bytes e geralmente usam técnicas rigorosas de empacotamento de bytes, assumindo explicitamente que o endereço tem exatamente 20 bytes de comprimento. Uma ideia para resolver esse problema envolve uma conversão de mapeamento, onde contratos antigos que interagem com o endereço moderno verão o valor de hash de 20 bytes do endereço moderno. No entanto, garantir a segurança desse processo é bastante complexo.

Encolhimento do espaço de Endereço

Outra abordagem seria seguir na direção oposta: imediatamente proibir alguns subintervalos de Endereço de tamanho 2^128 (por exemplo, todos os Endereços que começam com 0xffffffff), e então introduzir Endereços com um ciclo de Endereço e um valor hash de 14 bytes nesse intervalo.

0xffffffff000169125 d5dFcb7B8C2659029395bdF

O principal sacrifício feito por este método é a introdução de riscos de segurança hash contrafactuais: 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 afirma possuir um trecho de código (ainda não publicado), mas também possui outro trecho de código válido hashado para o mesmo Endereço. Hoje, calcular tais colisões requer 2^80 hashes; a contração do espaço do Endereço reduziria esse número para 2^56 hashes facilmente acessíveis.

Nas áreas-chave de risco, ou seja, Endereço de Carteira de facto inverso detido por proprietários não individuais, é relativamente raro hoje em dia, mas pode tornar-se mais comum à medida que entramos no mundo L2. A única solução é simplesmente aceitar esse risco, mas identificar todos os casos de uso comuns que possam apresentar problemas e propor soluções eficazes.

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

Proposta inicial

Bloco链清洁;

Regeneração;

Teoria de gerenciamento de tamanho de estado do Ethereum;

Alguns possíveis caminhos para estados sem estado e expirados;

Algumas propostas de vencimento de estado

EIP-7736 ；

Documento de Expansão do Espaço de Endereço

Proposta original;

Ipsilon revisão;

Comentários sobre o artigo do blog;

O que será destruído se perdermos a resistência ao impacto.

O que mais precisa ser feito, o que precisa ser ponderado?

Eu acredito que há quatro caminhos viáveis para o futuro:

· Nós permanecemos sem estado e nunca introduzimos a expiração do estado. O estado está a subir constantemente (embora lentamente: podemos não ver isso ultrapassar 8 TB por várias décadas), mas só precisa ser mantido por utilizadores de categorias relativamente especiais: até mesmo os validadores PoS não precisam de estado.

Uma funcionalidade que requer acesso a parte do estado é a geração de listas, mas podemos fazer isso de forma descentralizada: cada usuário é responsável por manter parte da árvore de estado que contém sua própria conta. Quando eles transmitem transações, eles transmitem a transação e anexam a prova do objeto de estado acessado durante a etapa de validação (isso se aplica a contas EOA e ERC-4337). Em seguida, os validadores sem estado podem combinar essas provas em uma prova que contém a lista inteira.

· Realizamos uma parte do estado expirar e aceitamos uma taxa de crescimento do tamanho do estado permanente muito mais baixa, mas ainda não nula. Este resultado pode ser considerado semelhante a como as propostas históricas expiradas que envolvem redes peer-to-peer aceitam que cada cliente deve armazenar uma taxa de crescimento do armazenamento histórico permanente muito mais baixa, mas ainda não nula, de dados históricos fixos.

· Estamos a realizar uma expansão do espaço de Endereço para gerir a expiração de estados. Isto será um processo de vários anos para garantir a eficácia e segurança dos métodos de conversão de formato de Endereço, incluindo aplicações existentes.

· Nós estamos usando uma redução do espaço de Endereço para expirar estados. Isso envolverá um processo de vários anos para garantir que todos os riscos de segurança relacionados a conflitos de Endereço (incluindo casos de cadeia cruzada) sejam tratados.

Uma questão importante é que, independentemente de se implementar um esquema de expiração de estado dependente de alterações de formato de Endereço, no final, será necessário resolver os desafios de expansão e contração do espaço de Endereço. Atualmente, gerar conflitos de Endereço requer aproximadamente 2^80 valores de hash, o que é viável para participantes extremamente ricos em recursos: as GPUs podem calcular cerca de 2^27 valores de hash, portanto, executar o cálculo por um ano pode calcular 2^52, o que significa que cerca de 230 GPUs em todo o mundo podem calcular uma colisão em cerca de 1/4 de ano, enquanto as FPGA e ASIC podem acelerar ainda mais esse processo. No futuro, esse tipo de ataque estará disponível para um número cada vez maior de pessoas. Portanto, o custo real da implementação de um esquema de expiração de estado completo pode não ser tão alto quanto parece, pois de qualquer forma teremos que resolver esse problema de Endereço extremamente desafiador.

Como interage com as outras partes do roteiro?

A expiração do estado em andamento pode tornar a conversão de um formato de árvore de estado para outro formato de árvore de estado mais fácil, pois não é necessário um processo de conversão: 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 do estado seja complexa, ela realmente beneficia outros aspectos da linha do tempo.

Limpeza de recursos

Resolve que problemas?

Uma das condições prévias essenciais para a segurança, acessibilidade e neutralidade de confiança é a simplicidade. Se o protocolo for esteticamente agradável e simples, reduzirá a possibilidade de erros. Aumenta a oportunidade de novos desenvolvedores participarem em qualquer parte dele. É mais provável que seja justo e mais resistente aos interesses especiais. Infelizmente, o protocolo, como qualquer sistema social, tende a tornar-se mais complexo com o tempo por padrão. Se não queremos que o Ethereum caia no buraco em constante aumento de complexidade, precisamos fazer uma das duas coisas: (i) parar de fazer alterações e tornar o protocolo rígido, (ii) ser capazes de remover efetivamente recursos e Gota complexidade. Também é possível um caminho intermediário, ou seja, fazer menos alterações no protocolo e, com o tempo, pelo menos reduzir um pouco a complexidade. Esta seção discutirá como reduzir ou eliminar a complexidade.

O que é isso, como funciona?

Não há uma única correção significativa que possa reduzir a complexidade do protocolo Gota; a essência desse problema é que existem muitas soluções pequenas.

Um exemplo parcialmente completo é a remoção do código de operação SELFDESTRUCT e pode servir como um modelo de como lidar com outros exemplos. O código de operação SELFDESTRUCT é o único que pode modificar um número ilimitado de slots de armazenamento dentro de um único bloco, exigindo que os clientes implementem uma complexidade significativamente maior para evitar ataques de 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 o usam. O código de operação foi enfraquecido, permitindo apenas contas de autodestruição criadas na mesma transação de bifurcação rígida Dencun. Isso resolve o problema de DoS e pode simplificar significativamente o código do cliente. No futuro, pode fazer sentido remover completamente o código de operação.

Até agora, alguns exemplos-chave de oportunidades de simplificação de protocolos identificados incluem o seguinte. Primeiro, alguns exemplos fora do EVM; estes são relativamente não invasivos, portanto, mais fáceis de alcançar Consenso e implementar em um período de tempo mais curto.

· Conversão RLP → SSZ: Inicialmente, objetos Ethereum eram serializados usando uma codificação chamada RLP. RLP é sem tipo e desnecessariamente complexo. Hoje, a cadeia beacon usa SSZ, que é significativamente melhor em muitos aspectos, incluindo suporte não apenas à serialização, mas também ao hash. No final, esperamos eliminar completamente o RLP e migrar todos os tipos de dados para a estrutura SSZ, o que, por sua vez, tornará as atualizações mais fáceis. As EIPs atuais incluem [1] [2] [3].

· Exclua os tipos de negociação antigos: Há muitos tipos de negociação atualmente, e muitos deles podem ser excluídos. Uma alternativa mais suave à exclusão completa é a função de abstração de conta, onde contas inteligentes podem incluir códigos para processar e validar transações antigas (se desejarem).

· Reforma de LOG: A criação de log Filtro Bloom e outras lógicas aumentaram a complexidade do protocolo, mas na prática não são utilizadas pelos clientes porque são muito lentas. Podemos remover essas funcionalidades e nos concentrar em soluções alternativas, como o uso de tecnologias modernas como SNARK para ferramentas de leitura de log descentralizadas protocolo.

· 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 Consenso.

· Formato de dados unificado: Atualmente, o estado de execução é armazenado em uma árvore Merkle Patricia, o estado de Consenso é armazenado em uma árvore SSZ e o blob é submetido através de compromissos KZG. No futuro, fará sentido ter um formato unificado único para os dados de bloco e um formato unificado único 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) estruturas de dados padronizadas.

· Remoção do comitê de cadeia beacon: Este mecanismo foi originalmente introduzido para suportar a execução da Fragmentação em versões específicas. Em vez disso, acabamos por realizar a Fragmentação através de L2 e blob. Portanto, o comitê é desnecessário e estamos a proceder à remoção do mesmo.

· Remover a ordem de bytes mista: EVM é big-endian, a camada de consenso é little-endian. Reconciliar e tornar tudo consistente em um ou outro pode fazer sentido (pode ser big-endian, já que EVM é mais difícil de mudar)

Agora, alguns exemplos do EVM:

· Simplificação do mecanismo de gás: As regras atuais de gás ainda não foram otimizadas, não sendo possível estabelecer limites claros para os recursos necessários para verificar o Bloco. Exemplos chave incluem (i) custos de leitura/escrita de armazenamento, destinados a limitar o número de leituras/escritas por bloco, mas atualmente são bastante arbitrários, e (ii) regras de preenchimento de memória, atualmente é difícil estimar o consumo máximo de memória do EVM. As medidas corretivas propostas incluem mudanças no custo de gás sem estado (unificando todos os custos relacionados ao armazenamento em uma fórmula simples) e proposta de precificação de memória.

· Remoção de pré-compilação: Ethereum atualmente possui muitas pré-compilações que são desnecessariamente complexas, relativamente não utilizadas e constituem uma grande parte do fracasso do consenso, visto que quase nenhum aplicativo as utiliza. Duas abordagens para lidar com esse problema são (i) simplesmente remover as pré-compilações e (ii) substituí-las por trechos de código EVM que implementem a mesma lógica (inevitavelmente mais dispendiosa). Esta proposta de EIP sugere que a primeira etapa seja a execução dessa operação para a pré-compilação de Identidade; posteriormente, RIPEMD-160, MODEXP e BLAKE podem se tornar candidatos à remoção.

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

· Melhoria na análise estática: atualmente, é difícil realizar uma análise estática do código EVM, 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 os saltos dinâmicos (ou tornando-os mais caros, por exemplo, o custo de gás é linear em relação ao 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 as pesquisas existentes?

Passos seguintes para limpeza;

· Auto-destruição

· SSZ化EIPS：[1] [2] [3];

· Sem alteração no custo do gás;

· Preços de memória linear;

· Pré-compilação excluída;

· Remoção do Filtro Bloom;

· Um método de recuperação segura de logs utilizando computação verificável incremental fora da cadeia (leia-se: STARK recursivo);

O que mais precisa ser feito, o que precisa ser ponderado?

O principal trade-off dessa simplificação de funcionalidade é (i) o grau de simplificação e velocidade versus (ii) a compatibilidade com versões anteriores. O valor do Ethereum como uma cadeia reside no fato de ser uma plataforma na qual os aplicativos podem ser implantados e ter a certeza de que eles funcionarão anos depois. Ao mesmo tempo, esse ideal pode ter ido longe demais, para citar William Jennings Bryan, ‘crucificar o Ethereum na cruz da compatibilidade com versões anteriores’. Se apenas dois aplicativos em toda a rede Ethereum usarem uma determinada funcionalidade e um deles tiver zero usuários ao longo dos anos, enquanto o outro tiver um valor total de 57 dólares e quase não for usado, devemos remover essa funcionalidade e pagar os 57 dólares às vítimas do nosso próprio bolso, se necessário.

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

1. Começar a falar sobre a função de exclusão X;

2. Ao analisar, a determinação de excluir X e o impacto no aplicativo dependem do resultado: (i) desistir da ideia, (ii) continuar conforme planejado, ou (iii) determinar o método modificado com ‘mínima destructividade’ para excluir X e continuar;

3. Elabore um EIP oficial para descontinuar o X. Certifique-se de que infraestruturas populares de níveis superiores, como linguagens de programação e Carteira, respeitem isso e parem de usar essa funcionalidade.

4. Por fim, exclua X na prática;

Deve haver um pipeline de vários anos entre o Passo 1 e o Passo 4, e deve ser claramente indicado em que etapa cada projeto se encontra. Neste ponto, é necessário equilibrar a dinâmica e a velocidade do processo de remoção de recursos com a abordagem mais conservadora e com a alocação de mais recursos para o desenvolvimento de outros campos do protocolo, mas ainda estamos longe da fronteira de Pareto.

EOF

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

As vantagens desta abordagem são criar um caminho natural para adicionar novas funcionalidades ao EVM e incentivar a migração para um EVM mais rigoroso e com garantias mais fortes. 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. Um problema principal é: como EOF desempenha um papel na proposta de simplificação do EVM, especialmente se o objetivo for Gota toda a complexidade do EVM?

Como interage com as outras partes do roteiro?

Muitas das sugestões de “melhoria” nas partes restantes do roteiro também são oportunidades para simplificar as funcionalidades antigas. Repetindo alguns dos exemplos acima:

Mudar para a finalidade do slot único nos dá a oportunidade de cancelar comitês, redesenhar a economia e simplificar outros aspectos relacionados ao Staking.

· A implementação completa da abstração de contas permite-nos remover uma grande quantidade de lógica de processamento de transações existente e movê-la para o ‘código EVM de conta padrão’ que pode ser substituído por todas as EOA.

Se transferirmos o estado do Ethereum para uma árvore hash binária, isso pode ser consistente com a nova versão do SSZ, para que todas as estruturas de dados Ethereum possam ser processadas de hash da mesma maneira.

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

Uma estratégia simplificada mais radical do Éter é manter o protocolo inalterado, mas transferir a maior parte dele das funcionalidades do protocolo para o código do contrato.

A versão mais extrema seria fazer com que a L1 da Ethereum seja “tecnicamente” apenas uma cadeia beacon e introduzir uma máquina virtual mínima (como RISC-V, Cairo ou uma ainda menor projetada especificamente para sistemas de prova), permitindo que outros criem suas próprias agregações. Então, a EVM se tornaria a primeira dessas agregações. Ironicamente, isso é exatamente o resultado da proposta de ambiente de execução de 2019-20, embora o SNARK torne a 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 fazer uma troca in-place da EVM. Podemos escolher RISC-V, Cairo ou outra VM como a nova ‘VM oficial do Ethereum’, e então converter todos os contratos EVM em código de nova VM que interpreta a lógica do código original (por meio de compilação ou interpretação). Teoricamente, isso poderia até ser feito como uma versão do ‘objetivo da Máquina Virtual’ do Ethereum.

Link para o texto original