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

• Dados históricos: qualquer transação efetuada e qualquer conta criada em qualquer momento da história precisa ser armazenada por todos os clientes para sempre e baixada por quaisquer novos clientes fazendo uma sincronização completa com a rede. Isso causa carga e tempo de sincronização do cliente a aumentar ao longo do tempo, mesmo que a capacidade da cadeia permaneça a mesma.
• Recursos do protocolo: é muito mais fácil adicionar um novo recurso do que remover um antigo, o que causa um aumento na complexidade do código ao longo do tempo.

Para que o Ethereum se sustente a longo prazo, precisamos de uma forte contra-pressão contra essas duas tendências, reduzindo a complexidade e o inchaço ao longo do tempo. Mas ao mesmo tempo, precisamos preservar uma das principais propriedades que tornam as blockchains ótimas: sua permanência. Você pode colocar um NFT, uma mensagem de amor em dados de transação ou um contrato inteligente contendo um milhão de dólares na cadeia, entrar em uma caverna por dez anos, sair e encontrá-lo ainda lá esperando você ler e interagir com ele. Para que os dapps se sintam confortáveis em se tornarem totalmente descentralizados e removerem suas chaves de atualização, eles precisam ter confiança de que suas dependências não vão atualizar de uma forma que os quebre - especialmente a L1 em si.

O Purge, roteiro de 2023.

Equilibrar entre essas duas necessidades e minimizar ou reverter inchaço, complexidade e decadência, enquanto preserva a continuidade, é absolutamente possível se nos dedicarmos a isso. Os organismos vivos podem fazê-lo: enquanto a maioria envelhece com o tempo, alguns sortudos não. Até mesmo os sistemas sociais podem ter longevidade extrema. Em algumas ocasiões, o Ethereum já mostrou sucessos: a prova de trabalho desapareceu, o opcode SELFDESTRUCT está em grande parte desaparecido e os nós da cadeia de beacons já armazenam dados antigos por apenas seis meses. Descobrir esse caminho para o Ethereum de uma forma mais generalizada e avançar em direção a um resultado final estável a longo prazo é o desafio final da escalabilidade a longo prazo, sustentabilidade técnica e até mesmo segurança do Ethereum.

A Purificação: objetivos-chave

• Reduzir os requisitos de armazenamento do cliente, reduzindo ou eliminando a necessidade de cada nó armazenar permanentemente todo o histórico, e talvez até mesmo o estado eventualmente
• Reduzindo a complexidade do protocolo eliminando recursos desnecessários

Neste capítulo

• Expiração do histórico
• Expiração de estado
• Limpeza de recursos

Expiração de histórico

Que problema resolve?

No momento em que este texto foi escrito, um nó Ethereum totalmente sincronizado requer aproximadamente 1,1 terabytesde espaço em disco para ocliente de execução, mais alguns centenas de gigabytes para o cliente de consenso. A grande maioria disto é história: dados sobre blocos históricos, transações e recibos, a maior parte dos quais tem muitos anos. Isto significa que o tamanho de um nó continua a aumentar em centenas de gigabytes a cada ano, mesmo que o limite de gás não aumente de todo.

O que é e como funciona?

Uma característica chave de simplificação do problema de armazenamento de histórico é que cada bloco aponta para o bloco anterior através de um link de hash (e outro estruturas) ter consenso sobre o presente é suficiente para ter consenso sobre a história. Desde que a rede tenha consenso sobre o último bloco, qualquer bloco ou transação histórica ou estado (saldo da conta, nonce, código, armazenamento) pode ser fornecido por qualquer ator único juntamente com uma prova de Merkle, e a prova permite a qualquer outra pessoa verificar a sua correção. Enquanto o consenso é um modelo de confiança N/2-de-N, a história é um modelo de confiança 1-de-N.

Isso abre muitas opções para como podemos armazenar o histórico. Uma opção natural é uma rede onde cada nó armazena apenas uma pequena porcentagem dos dados. É assim que as redes de torrent funcionam há décadas: enquanto a rede como um todo armazena e distribui milhões de arquivos, cada participante armazena e distribui apenas alguns deles. Talvez de forma contraintuitiva, essa abordagem não necessariamente diminui a robustez dos dados. Se, tornando a execução do nó mais acessível, pudermos chegar a uma rede com 100.000 nós, onde cada nó armazena aleatoriamente 10% do histórico, então cada dado seria replicado 10.000 vezes - exatamente o mesmo fator de replicação de uma rede de 10.000 nós onde cada nó armazena tudo.

Hoje, o Ethereum já começou a se afastar do modelo de todos os nós armazenando toda a história para sempre. Os blocos de consenso (ou seja, as partes relacionadas ao consenso de prova de participação) são armazenados apenas por cerca de 6 meses. Os blobs são armazenados apenas por cerca de 18 dias.EIP-4444pretende introduzir um período de armazenamento de um ano para blocos e recibos históricos. Um objetivo a longo prazo é ter um período harmonizado (que poderia ser ~18 dias) durante o qual cada nó é responsável por armazenar tudo, e depois ter uma rede peer-to-peer composta por nós Ethereum armazenando dados mais 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, os blobs já vêm codificados com apagamento para suportar a amostragem de disponibilidade de dados. A solução mais simples pode ser reutilizar esta codificação com apagamento e colocar os dados de bloco de execução e consenso nos blobs também.

Quais são alguns links para pesquisas existentes?

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrents e EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• Rede do portal:https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• Rede de portal e EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• Armazenamento e recuperação distribuídos de objetos SSZ no Portal: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• Como aumentar o limite de gás (Paradigma):https://www.paradigm.xyz/2024/05/como-aumentar-o-limite-de-gas-2

O que resta fazer e quais são os compromissos?

O trabalho principal restante envolve a construção e integração de uma solução distribuída concreta para armazenar o histórico - pelo menos o histórico de execução, mas também o consenso e os blobs. As soluções mais fáceis para isso são (i) simplesmente introduzir uma biblioteca de torrent existente e (ii) uma solução nativa do Ethereum chamada a rede Portal. Uma vez que qualquer um destes seja introduzido, podemos activar o EIP-4444. O próprio EIP-4444 não requer uma hard fork, embora exija uma nova versão do protocolo de rede. Por esta razão, há valor em ativá-lo para todos os clientes ao mesmo tempo, porque caso contrário existem riscos de os clientes avariarem ao ligarem-se a outros nós a contar com o download da história completa mas na realidade não a receberem.

O principal compromisso envolve o quão duro tentamos tornar os dados históricos "antigos" disponíveis. A solução mais fácil seria simplesmente parar de armazenar a história antiga amanhã e confiar nos nós de arquivo existentes e em vários fornecedores centralizados para replicação. Isso é fácil, mas enfraquece a posição do Ethereum como um lugar para fazer registros permanentes. O caminho mais difícil, mas mais seguro, é primeiro construir e integrar a rede de torrent para armazenar a história de forma distribuída. Aqui, existem duas dimensões de "quão duro tentamos":

1. Até que ponto nos esforçamos para garantir que um conjunto de nós maximamente grande esteja realmente armazenando todos os dados?
2. Quão profundamente integramos o armazenamento histórico no protocolo?

Uma abordagem maximalmente paranóica para (1) envolveriaprova de custódiana verdade, exigindo que cada validador de prova de participação armazene uma porcentagem do histórico e verifique regularmente criptograficamente se eles o fazem. Uma abordagem mais moderada é estabelecer um padrão voluntário para a porcentagem do histórico que cada cliente armazena.

Para (2), uma implementação básica envolve apenas pegar o trabalho que já é feito hoje: o Portal já armazena arquivos ERA contendo todo o histórico do Ethereum. Uma implementação mais completa envolveria realmente conectar isso ao processo de sincronização, para que, se alguém quisesse sincronizar um nó de armazenamento de histórico completo ou um nó de arquivo, eles pudessem fazê-lo mesmo se nenhum outro nó de arquivo existisse online, sincronizando diretamente da rede do Portal.

Como interage com outras partes do roteiro?

Reduzir os requisitos de armazenamento de histórico é possivelmente ainda mais importante do que a falta de estado se quisermos tornar extremamente fácil executar ou iniciar um nó: dos 1,1 TB que um nó precisa ter, ~300 GB são de estado, e os restantes ~800 GB são de histórico. A visão de um nó Ethereum rodando em um smartwatch e levando apenas alguns minutos para ser configurado só é alcançável se tanto a falta de estado quanto o EIP-4444 forem implementados.

Limitar o armazenamento de histórico torna também mais viável para as novas implementações de nós Ethereum suportarem apenas versões recentes do protocolo, o que lhes permite ser muito mais simples. Por exemplo, muitas linhas de código podem ser removidas com segurança agora que todas as ranhuras de armazenamento vazias criadas durante os ataques DoS de 2016 foramremovido. Agora que a mudança para o proof of stake é história antiga, os clientes podem remover com segurança todo o código relacionado ao proof-of-work.

Expiração do estado

Que problema resolve?

Mesmo que removamos a necessidade de os clientes armazenarem o histórico, o requisito de armazenamento de um cliente continuará a crescer, em cerca de 50 GB por ano, devido ao crescimento contínuo do estado: saldos e nonces de conta, código de contrato e armazenamento de contrato. Os usuários podem pagar um custo único para impor um ônus nos clientes presentes e futuros do Ethereum para sempre.

O estado é muito mais difícil de “expirar” do que a história, porque o EVM é fundamentalmente projetado com base na suposição de que, uma vez que um objeto de estado é criado, ele estará sempre lá e pode ser lido por qualquer transação a qualquer momento. Se introduzirmos a falta de estado, há um argumento de que talvez esse problema não seja tão ruim: apenas uma classe especializada de construtores de blocos precisaria realmente armazenar o estado, e todos os outros nós (mesmolista de inclusãoprodução!) pode ser executado sem estado. No entanto, há um argumento de que não queremos depender muito do estado sem, e eventualmente podemos querer expirar o estado para manter o Ethereum descentralizado.

O que é isto e como funciona?

Hoje, quando você cria um novo objeto de estado (o que pode acontecer de três maneiras: (i) enviando ETH para uma nova conta, (ii) criando uma nova conta com código, (iii) definindo um slot de armazenamento previamente não utilizado), esse objeto de estado permanece no estado para sempre. O que queremos é que os objetos expirem automaticamente ao longo do tempo. O desafio-chave é fazer isso de uma maneira que cumpra três objetivos:

1. Eficiência: não requerem grandes quantidades de computação adicional para executar o processo de expiração
2. Facilidade de uso: se alguém entrar numa caverna por cinco anos e voltar, não deve perder o acesso ao seu Ethereum, ERC20s, NFTs, posições de CDP...
3. Facilidade de uso para desenvolvedores: os desenvolvedores não devem ter que mudar para um modelo mental completamente desconhecido. Além disso, as aplicações que estão ossificadas hoje e não atualizam devem continuar a funcionar razoavelmente bem.

É fácil resolver o problema sem satisfazer esses objetivos. Por exemplo, você pode fazer com que cada objeto de estado também armazene um contador para sua data de expiração (que pode ser estendida pela gravação de ETH, o que pode acontecer automaticamente sempre que for lido ou gravado) e ter um processo que percorra o estado para remover objetos de estado expirados. No entanto, isso introduz computação extra (e até mesmo requisitos de armazenamento), e definitivamente não satisfaz o requisito de facilidade de uso. Os desenvolvedores também teriam dificuldade em raciocinar sobre casos de borda envolvendo valores de armazenamento às vezes redefinidos para zero. Se você fizer o contrato do temporizador de expiração em todo o contrato, isso torna a vida tecnicamente mais fácil para os desenvolvedores, mas torna a economia mais difícil: os desenvolvedores teriam que pensar em como "repassar" os custos contínuos de armazenamento para seus usuários.

Estes são problemas com os quais a comunidade de desenvolvimento central do Ethereum lutou por muitos anos, incluindo propostas como “aluguer de blockchain" e "regenesis“Eventualmente, combinámos as melhores partes das propostas e convergimos em duas categorias de 'soluções menos más conhecidas'.

• Soluções parciais de expiração de estado
• Propostas de expiração do estado com base no período de endereço.

Expiração parcial do estado

As propostas de expiração parcial do estado funcionam todos segundo o mesmo princípio. Nós dividimos o estado em pedaços. Todo mundo armazena permanentemente o “mapa de nível superior” de quais pedaços estão vazios ou não vazios. Os dados dentro de cada pedaço só são armazenados se esses dados tiverem sido acessados recentemente. Existe um mecanismo de “ressurreição” onde, se um pedaço não estiver mais armazenado, qualquer pessoa pode trazer esses dados de volta fornecendo uma prova do que os dados eram.

As principais distinções entre essas propostas são: (i) como definimos "recentemente" e (ii) como definimos "pedaço"? Uma proposta concreta é EIP-7736, que se baseia no design de "caule e folha"introduzido para árvores Verkle (embora compatível com qualquer forma de apatridia, por exemplo, árvores binárias). Neste design, cabeçalho, código e slots de armazenamento que são adjacentes uns aos outros são armazenados sob o mesmo "caule". Os dados armazenados sob uma haste podem ser, no máximo, 256 * 31 = 7.936 bytes. Em muitos casos, todo o cabeçalho e código, e muitos slots de armazenamento de chaves, de uma conta serão todos armazenados sob a mesma haste. Se os dados sob uma determinada haste não forem lidos ou gravados por 6 meses, os dados não serão mais armazenados e, em vez disso, apenas um compromisso de 32 bytes ("stub") para os dados será armazenado. Transações futuras que acessam esses dados precisariam "ressuscitar" os dados, com uma prova que seria verificada em relação ao stub.

Existem outras maneiras de implementar uma ideia semelhante. Por exemplo, se a granularidade ao nível da conta não for suficiente, poderíamos criar um esquema em que cada fração 1/232 da árvore seja regida por um mecanismo semelhante ao caule e folha.

Isso é mais complicado por causa dos incentivos: um atacante poderia forçar os clientes a armazenar permanentemente uma quantidade muito grande de estado colocando uma quantidade muito grande de dados em uma única subárvore e enviando uma única transação a cada ano para 'renovar a árvore'. Se você fizer com que o custo de renovação seja proporcional (ou a duração de renovação inversamente proporcional) ao tamanho da árvore, então alguém poderia prejudicar outro usuário colocando uma quantidade muito grande de dados na mesma subárvore que eles. Poderíamos tentar limitar ambos os problemas tornando a granularidade dinâmica com base no tamanho da subárvore: por exemplo, cada 216 objetos de estado = 65536 consecutivos poderiam ser tratados como um 'grupo'. No entanto, essas ideias são mais complexas; a abordagem baseada no caule é simples e alinha os incentivos, porque geralmente todos os dados sob um caule estão relacionados à mesma aplicação ou usuário.

Propostas de expiração de estado baseadas em período de endereço

E se quisermos evitar qualquer crescimento permanente de estado, mesmo com conectores de 32 bytes? Este é um problema difícil por causa de @vbuterin/state_size_management#Conflitos_de_r ressurreição": conflitos de ressurreição: e se um objeto de estado for removido, mais tarde a execução do EVM coloca outro objeto de estado na exata mesma posição, mas depois alguém que se preocupa com o objeto de estado original volta e tenta recuperá-lo? Com expiração parcial do estado, o “stub” impede a criação de novos dados. Com expiração completa do estado, não podemos nos dar ao luxo de armazenar nem mesmo o stub.

O design baseado em períodos de endereço é a melhor ideia conhecida para resolver isso. Em vez de ter uma árvore de estado armazenando todo o estado, temos uma lista constantemente crescente de árvores de estado e qualquer estado que seja lido ou gravado é salvo na árvore de estado mais recente. Uma nova árvore de estado vazia é adicionada uma vez por período (pense: 1 ano). As árvores de estado mais antigas estão congeladas. Espera-se que os nós completos armazenem apenas as duas árvores mais recentes. Se um objeto de estado não for tocado por dois períodos e, portanto, cair em uma árvore expirada, ainda poderá ser lido ou gravado, mas a transação precisará provar uma prova de Merkle para isso - e, uma vez que o fizer, uma cópia será salva novamente na árvore mais recente.

Uma ideia-chave para tornar tudo isto amigável para utilizadores e desenvolvedores é o conceito de períodos de endereço. Um período de endereço é um número que faz parte de um endereço. Uma regra fundamental é que um endereço com o período de endereço N só pode ser lido ou escrito durante ou após o período N (ou seja, quando a lista da árvore de estado atingir o comprimento N). Se estiver a guardar um novo objeto de estado (por exemplo, um novo contrato ou um novo saldo ERC20), se certificar-se de colocar o objeto de estado num contrato cujo período de endereço seja N ou N-1, então pode guardá-lo imediatamente, sem necessidade de fornecer provas de que não havia nada antes. No entanto, quaisquer adições ou edições ao estado em períodos de endereço antigos requerem uma prova.

Este design preserva a maioria das propriedades atuais do Ethereum, é muito leve em computação extra, permite que as aplicações sejam escritas quase como estão hoje (os ERC20s precisarão ser reescritos, para garantir que os saldos dos endereços com período de endereço N sejam armazenados em um contrato filho que por si só tem um período de endereço N), e resolve o problema de "o usuário entra em uma caverna por cinco anos". No entanto, tem um grande problema: os endereços precisam ser expandidos além de 20 bytes para caber nos períodos de endereço.

Extensão do espaço de endereços

Uma proposta é introduzir um novo formato de endereço de 32 bytes, que inclui um número de versão, um número de período de endereço e um hash expandido.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

O vermelho é um número de versão. Os quatro zeros coloridos a laranja aqui são destinados como espaço vazio, que poderia acomodar um número de partição no futuro. O verde é um número de período de endereço. O azul é um hash de 26 bytes.

O desafio chave aqui é a compatibilidade retroativa. Os contratos existentes são projetados em torno de endereços de 20 bytes e frequentemente usam técnicas de compactação de bytes apertadas que assumem explicitamente que os endereços têm exatamente 20 bytes de comprimento.@ipsilon/address-space-extension-exploration">Uma ideia para resolver isso envolve um mapa de tradução, onde contratos no estilo antigo interagindo com endereços no novo estilo veriam um hash de 20 bytes do endereço no novo estilo. No entanto, existem complexidades significativas envolvidas em tornar isso seguro.

Contração do espaço de endereçamento

Outra abordagem segue a direção oposta: proibimos imediatamente algumas subfaixas de endereços de tamanho 2128 (por exemplo, todos os endereços que começam com 0xffffffff) e, em seguida, usamos essa faixa para introduzir endereços com períodos de endereço e hashes de 14 bytes.

0xfffffff000169125d5dFcb7B8C2659029395bdF

O sacrifício-chave que esta abordagem faz, é que issointroduz riscos de segurança para endereços contrafactuais: endereços que possuem ativos ou permissões, mas cujo código ainda não foi publicado na cadeia. O risco envolve alguém criar um endereço que afirma ter um pedaço de código (ainda não publicado), mas também tem outro pedaço válido de código que gera o mesmo endereço. Calcular tal colisão requer 2⁸⁰hashes hoje; a contração do espaço de endereço reduziria esse número para um acessível 2⁵⁶hashes.

A área de risco chave, endereços contrafactuais que não são carteiras mantidas por um único proprietário, é um caso relativamente raro hoje, mas provavelmente se tornará mais comum à medida que entramos em um mundo multi-L2. A única solução é simplesmente aceitar esse risco, mas identificar todos os casos de uso comuns onde isso pode ser um problema e encontrar soluções alternativas eficazes.

Quais são alguns links para pesquisas existentes?

• Primeiras propostas
  • Aluguel de blockchain: https://github.com/ethereum/EIPs/issues/35
  • Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• Uma teoria de gestão do tamanho do estado do Ethereum:@vbuterin"/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
• Algumas possíveis formas de destituição de estado e expiração de estado: @vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
• Propostas de expiração parcial de estado
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• Documentos de extensão de espaço de endereço
  • Proposta original: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • Revisão do Ipsilon: @ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • Revisão do post do blog: @chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• O que quebraria se perdêssemos a resistência à colisão: https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

O que resta a fazer e quais são os compromissos?

Vejo quatro caminhos viáveis para o futuro:

• Fazemos apatridia e nunca introduzimos a caducidade do Estado. O estado está crescendo constantemente (embora lentamente: podemos não vê-lo exceder 8 TB por décadas), mas só precisa ser mantido por uma classe relativamente especializada de usuários: nem mesmo validadores PoS precisariam do estado. \
  \
  A única função que precisa de acesso a partes do estado é a produção da lista de inclusão, mas podemos alcançar isso de forma descentralizada: cada utilizador é responsável por manter a parte da árvore de estado que contém as suas próprias contas. Quando transmitem uma transação, fazem-no com uma prova dos objetos de estado acedidos durante a etapa de verificação (isto funciona tanto para EOAs como para contas ERC-4337). Os validadores sem estado podem então combinar estas provas numa prova para toda a lista de inclusão.
• Fazemos expiração parcial de estado e aceitamos uma taxa muito menor, mas ainda não nula, de crescimento do tamanho permanente do estado. Esse resultado é argumentavelmente semelhante à forma como propostas de expiração de histórico envolvendo redes peer-to-peer aceitam uma taxa muito menor, mas ainda não nula, de crescimento do armazenamento permanente de histórico a partir de cada cliente que precisa armazenar uma porcentagem baixa, mas fixa, dos dados históricos.
• Nós fazemos a expiração do estado, com expansão do espaço de endereços. Isso envolverá um processo plurianual para garantir que a abordagem de conversão de formato de endereço funcione e seja segura, inclusive para aplicações existentes.
• Fazemos a expiração do estado, com contração do espaço de endereçamento. Isso envolverá um processo de vários anos para garantir que todos os riscos de segurança envolvendo colisões de endereços, incluindo situações de interligação de cadeias, sejam tratados.

Um ponto importante é que as questões difíceis em torno da expansão e contração do espaço de endereço terão que ser abordadas eventualmente, independentemente de as medidas de expiração do estado que dependem das alterações de formato do endereço serem ou não implementadas. Hoje, leva aproximadamente 2⁸⁰ hashes para gerar uma colisão de endereços, uma carga computacional que já é viável para atores extremamente bem dotados de recursos: uma GPU pode fazer cerca de 2²⁷hashes, portanto, executando por um ano, ele pode calcular 2⁵², então todos ~2^30 GPUs no mundo poderia calcular uma colisão em ~1/4 de um ano, e FPGAs e ASICs poderiam acelerar isso ainda mais. No futuro, esses ataques tornar-se-ão abertos a cada vez mais pessoas. Por conseguinte, o custo real da implementação da expiração total do Estado pode não ser tão elevado como parece, uma vez que temos de resolver este problema de resolução muito difícil independentemente disso.

Como interage com outras partes do roteiro?

A expiração do estado potencialmente facilita as transições de um formato de árvore de estado para outro, porque não haverá necessidade de um procedimento de transição: você poderia simplesmente começar a fazer novas árvores usando um novo formato e, posteriormente, fazer um hard fork para converter as árvores mais antigas. Assim, embora a expiração do estado seja complexa, ela tem benefícios em simplificar outros aspectos do roteiro.

Limpeza de funcionalidades

Que problemas resolve?

Uma das condições prévias chave de segurança, acessibilidade e neutralidade credívelé a simplicidade. Se um protocolo é bonito e simples, reduz a probabilidade de haver erros. Aumenta a probabilidade de novos desenvolvedores poderem entrar e trabalhar com qualquer parte dele. É mais provável que seja justo e mais fácil de defender contra interesses especiais. Infelizmente, os protocolos, como qualquer sistema social, por padrão, tornam-se mais complexos ao longo do tempo. Se não quisermos que o Ethereum entre num buraco negro de complexidade crescente, precisamos fazer uma das duas coisas: (i) parar de fazer alterações e ossificar o protocolo, (ii) ser capaz de realmente remover funcionalidades e reduzir a complexidade. Um caminho intermediário, de fazer menos alterações no protocolo e também remover pelo menos um pouco de complexidade ao longo do tempo, também é possível. Esta seção irá abordar como podemos reduzir ou remover a complexidade.

O que é isto e como funciona?

Não há uma grande correção única que possa reduzir a complexidade do protocolo; a natureza inerente do problema é que há muitas pequenas correções.

Um exemplo que já está quase concluído e pode servir como um modelo para lidar com os outros é o@vbuterinremoção do opcode SELFDESTRUCT. O opcode SELFDESTRUCT era o único opcode que podia modificar um número ilimitado de slots de armazenamento dentro de um único bloco, exigindo que os clientes implementassem significativamente mais complexidade para evitar ataques DoS. O objetivo original do opcode era permitir a limpeza voluntária do estado, permitindo que o tamanho do estado diminuísse ao longo do tempo. Na prática, muito poucos acabaram por usá-lo.o opcode foi enfraquecidopara permitir apenas contas autodestrutivas criadas na mesma transação no hardfork Dencun. Isso resolve o problema de DoS e permite uma simplificação significativa no código do cliente. No futuro, provavelmente faz sentido remover eventualmente o opcode completamente.

Alguns exemplos-chave de oportunidades de simplificação de protocolo identificadas até agora incluem as seguintes. Primeiro, alguns exemplos que estão fora do EVM; estes são relativamente não invasivos, e assim mais fáceis de obter consenso e implementar num prazo mais curto.

• Transição RLP → SSZ: originalmente, os objetos Ethereum eram serializados usando uma codificação chamada RLP. RLP é não tipado e desnecessariamente complexo. Hoje, a cadeia do beacon usa SSZ, que é significativamente melhor em muitos aspectos, incluindo o suporte não apenas à serialização, mas também ao hashing. Eventualmente, queremos nos livrar completamente do RLP e mover todos os tipos de dados para serem estruturas SSZ, o que facilitaria muito a atualização. Os EIPs atuais para isso incluem [1] [2] [3].
• Remoção de tipos de transação antigos: existem muitos tipos de transação hoje, muitos deles poderiam ser potencialmente removidos. Uma alternativa mais moderada à remoção total é um recurso de abstração de conta pelo qual as contas inteligentes podem incluir o código para processar e verificar transações antigas, se assim desejarem.
• Reforma do LOG: os logs criam filtros de bloom e outras lógicas que adicionam complexidade ao protocolo, mas na verdade não são usados pelos clientes porque são demasiado lentos. Nós poderíamosremova esses recursos, e em vez disso, empenhe-se em alternativas, como ferramentas de leitura de log descentralizadas fora do protocolo que utilizam tecnologia moderna como SNARKs.
• Remoção eventual do mecanismo do comitê de sincronização da cadeia de beacons: o mecanismo do comité de sincronizaçãofoi originalmente introduzido para permitir a verificação do cliente leve do Ethereum. No entanto, isso acrescenta complexidade significativa ao protocolo. Eventualmente, seremos capazes deverifique a camada de consenso Ethereum diretamente usando SNARKs, o que eliminaria a necessidade de um protocolo de verificação de cliente leve dedicado. Potencialmente, mudanças no consenso poderiam nos permitir remover comitês de sincronização ainda mais cedo, criando um protocolo de cliente leve mais "nativo" que envolve a verificação de assinaturas de um subconjunto aleatório dos validadores de consenso do Ethereum.
• Harmonização do formato de dados: hoje, o estado de execução é armazenado em uma árvore Merkle Patricia, o estado de consenso é armazenado em um árvore SSZ, e os blobs são comprometidos com@vbuterin/proto_danksharding_faq#Em que formato estão os dados de blob e como são comprometidos"> Compromissos KZG. No futuro, faz sentido criar um único formato unificado para os dados do bloco e um único formato unificado para o estado. Esses formatos cobririam todas as necessidades importantes: (i) provas fáceis para clientes sem estado, (ii) serialização e codificação por apagamento para dados, (iii) estruturas de dados padronizadas.
• Remoção de comissões da cadeia de beacons: esse mecanismo foi originalmente introduzido para apoiar umversão específica de sharding de execução. Em vez disso, acabamos fazendo shard.através de L2s e blobs. Portanto, os comitês são desnecessários e, portanto, há um rumo à remoção em andamento.
• Remoção de mistura de endianidade: o EVM é big-endian e a camada de consenso é little-endian. Pode fazer sentido re-harmonizar e tornar tudo um ou outro (provavelmente big-endian, porque o EVM é mais difícil de mudar)

Agora, alguns exemplos que estão dentro do EVM:

• Simplificação da mecânica de gás: as regras atuais de gás não estão bem otimizadas para fornecer limites claros à quantidade de recursos necessários para verificar um bloco. Exemplos-chave disso incluem (i) custos de leitura / gravação de armazenamento, que são destinados a limitar o número de leituras / gravações em um bloco, mas atualmente são bastante caóticos e (ii) regras de preenchimento de memória, onde atualmente é difícil estimar o consumo máximo de memória do EVM. As correções propostas incluemmudanças no custo do gás sem estado, que harmonizam todos os custos relacionados ao armazenamento em uma fórmula simples e esta proposta para preços de memória.
• Remoção de pré-compilados: muitos dos pré-compilados que o Ethereum possui hoje são desnecessariamente complexos e relativamente não utilizados, e representam uma grande percentagem de quase falhas de consenso, embora na realidade não sejam utilizados por nenhuma aplicação. Duas formas de lidar com isto são (i) simplesmente remover o pré-compilado, e (ii) substituí-lo por um pedaço de código EVM (inevitavelmente mais caro) que implementa a mesma lógica.Este projeto de EIP propõepara fazer isso para o precompile de identidade como primeiro passo; mais tarde, RIPEMD160, MODEXP e BLAKE podem ser candidatos a remoção.
• Remoção da observabilidade de gás: tornar a execução do EVM incapaz de ver quanto gás resta. Isso quebraria algumas aplicações (principalmente transações patrocinadas), mas facilitaria muito a atualização no futuro (por exemplo, para versões mais avançadas do protocolo Ethereum).gás multidimensional). O Especificação EOFjá torna o gás inobservável, embora para ser útil para a simplificação do protocolo EOF precise 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 criar implementações otimizadas de EVM que pré-compilam o código EVM em outra linguagem. Podemos potencialmente corrigir isso porremovendo saltos dinâmicos(ou tornando-os muito mais caros, por exemplo, o custo de gás linear no número total de JUMPDESTs em um contrato). EOF faz isso, embora obter ganhos de simplificação de protocolo com isso exigiria tornar o EOF obrigatório.

Quais são alguns links para pesquisas existentes?

• Próximos passos na Purge: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• AUTO-DESTRUIÇÃO: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• SSZ-ificação EIPS: [1][2] [3]
• Alterações no custo de gás da Ausência de Estado:https://eips.ethereum.org/EIPS/eip-4762
• Preços de memória linear: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Remoção de pré-compilação: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Remoção do filtro Bloom: https://eips.ethereum.org/EIPS/eip-7668
• Uma maneira de fazer a recuperação segura de logs fora da cadeia usando cálculos incrementalmente verificáveis ​​(leia: STARKs recursivos):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

O que resta fazer e quais são os tradeoffs?

O principal compromisso ao fazer esse tipo de simplificação de recurso é (i) o quanto simplificamos e o quão rapidamente versus (ii) compatibilidade com versões anteriores. O valor do Ethereum como uma cadeia vem do fato de ser uma plataforma onde você pode implantar um aplicativo e ter confiança de que ainda funcionará muitos anos a partir de agora. Ao mesmo tempo, é possível levar esse ideal longe demais e,parafrasear William Jennings Bryan"crucificar o Ethereum em uma cruz de compatibilidade reversa". Se houver apenas duas aplicações em todo o Ethereum que usem uma determinada funcionalidade, e uma delas não tem nenhum usuário há anos e a outra é quase completamente não utilizada e assegura um valor total de $57, então devemos simplesmente remover a funcionalidade, e se necessário pagar as vítimas $57 do nosso bolso.

O problema social mais amplo está em criar um pipeline padronizado para fazer alterações de compatibilidade reversa não emergenciais. Uma maneira de abordar isso é examinar e estender precedentes existentes, como o processo SELFDESTRUCT. O pipeline se parece com algo como o seguinte:

• Passo 1: comece a falar sobre a remoção da funcionalidade X
• Passo 2: fazer uma análise para identificar o quanto a remoção de X quebra as aplicações, dependendo dos resultados, ou (i) abandonar a ideia, (ii) prosseguir conforme planeado, ou (iii) identificar uma forma modificada 'menos disruptiva' de remover X e prosseguir com isso
• Passo 3: faça um EIP formal para depreciar X. Certifique-se de que a infraestrutura de alto nível popular (por exemplo, linguagens de programação, carteiras) respeite isso e pare de usar essa funcionalidade.
• Passo 4: finalmente, remover X de fato

Deve haver um pipeline de vários anos entre o passo 1 e o passo 4, com informações claras sobre quais itens estão em que passo. Nesse ponto, há um trade-off entre o quão vigoroso e rápido é o pipeline de remoção de recursos, em comparação com ser mais conservador e colocar mais recursos em outras áreas de desenvolvimento de protocolo, mas ainda estamos longe da fronteira de Pareto.

EOF

Um conjunto importante de mudanças que foi proposto para a EVM é oFormato de Objeto EVM (EOF). EOF introduz um grande número de mudanças, como a proibição da observabilidade de gás, observabilidade de código (ou seja, sem CODECOPY), permitindo apenas saltos estáticos. O objetivo é permitir que o EVM seja atualizado de maneira mais robusta, preservando a compatibilidade com versões anteriores (pois o EVM pré-EOF ainda existirá).

Isso tem a vantagem de criar um caminho natural para adicionar novas funcionalidades do EVM e incentivar a migração para um EVM mais restritivo com garantias mais fortes. Tem a desvantagem de aumentar significativamente a complexidade do protocolo, a menos que possamos encontrar uma maneira de eventualmente descontinuar e remover o antigo EVM. Uma questão importante é: qual é o papel do EOF nas propostas de simplificação do EVM, especialmente se o objetivo é reduzir a complexidade do EVM como um todo?

Como interage com outras partes do roteiro?

Muitas das propostas de “melhoria” no resto do roteiro também são oportunidades para simplificar recursos antigos. Para repetir alguns exemplos acima:

• Mudar para finalidade de slot único dá-nos a oportunidade de remover comissões, reformular economia e fazer outras simplificações relacionadas com a prova de participação.
• A implementação completa da abstração de contas permite-nos remover muita lógica de manipulação de transações existente, movendo-a para um pedaço de "código EVM de conta padrão" que todas as EOAs poderiam ser substituídas.
• Se transferirmos o estado do Ethereum para árvores de hash binárias, isso poderia ser harmonizado com uma nova versão do SSZ, de modo que todas as estruturas de dados do Ethereum pudessem ser hashadas da mesma forma.

Uma abordagem mais radical: transformar grandes partes do protocolo em código de contrato

Uma estratégia de simplificação do Ethereum mais radical é manter o protocolo como está, mas mover grandes partes dele de serem recursos do protocolo para serem código de contrato.

A versão mais extrema disso seria fazer com que o Ethereum L1 "tecnicamente" fosse apenas a cadeia beacon, e introduzir uma VM mínima (por exemplo. RISC-V, Cairo, ou algo ainda mais minimalista especializado em sistemas de provar) que permite a qualquer pessoa criar seu próprio rollup. A EVM então se tornaria o primeiro desses rollups. Ironicamente, esse é exatamente o mesmo resultado do propostas de ambiente de execução de 2019-20, embora os SNARKs tornem significativamente mais viável a sua implementação.

Uma abordagem mais moderada seria manter a relação entre a beacon chain e o ambiente de execução Ethereum atual, mas fazer uma troca no local da EVM. Poderíamos escolher RISC-V, Cairo ou outro VM para ser o novo 'Ethereum VM' oficial e, em seguida, converter forçadamente todos os contratos EVM em código de novo VM que interpreta a lógica do código original (compilando ou interpretando-o). Teoricamente, isso até poderia ser feito com o 'VM de destino' sendo uma versão do EOF.

Declaração de exoneração de responsabilidade:

1. Este artigo é reproduzido a partir de [ Vitalik Buterin], Todos os direitos autorais pertencem ao autor original [Vitalik Buterin]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da Gate. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.