Possíveis direções de desenvolvimento futuro do protocolo Ethereum: Capítulo da Prosperidade

No protocolo Ethereum, existem muitos "detalhes" que são cruciais para o seu sucesso. Na verdade, cerca de metade do conteúdo diz respeito a diferentes tipos de melhorias do EVM, enquanto o restante é composto por vários temas de nicho, que é o que significa "prosperidade".

Prosperidade: Objetivo chave

• Transformar o EVM em um "estado final" de alto desempenho e estável
• Introduzir a abstração de conta no protocolo, permitindo que todos os usuários desfrutem de contas mais seguras e convenientes.
• Otimizar a economia das taxas de transação, aumentar a escalabilidade enquanto reduz o risco
• Explorar criptografia avançada, para que o Ethereum melhore significativamente a longo prazo

melhoria do EVM

Que problema foi resolvido?

Atualmente, a EVM é difícil de analisar estaticamente, o que torna difícil criar implementações eficientes, validar formalmente o código e realizar expansões adicionais. Além disso, a eficiência da EVM é baixa, dificultando a implementação de muitas formas de criptografia avançada, a menos que haja suporte explícito através de pré-compilações.

O que é isso, como funciona?

O primeiro passo do roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), que está planejado para ser incluído na próxima bifurcação dura. O EOF é uma série de EIPs que especificam uma nova versão do código EVM, com muitas características únicas, sendo a mais notável:

• O código ( pode ser executado, mas não é possível ler ) do EVM e os dados ( podem ser lidos, mas não podem ser executados entre a separação de ).
• Proibido redirecionamentos dinâmicos, apenas redirecionamentos estáticos permitidos
• O código EVM não pode mais observar informações relacionadas ao combustível.
• Adicionada uma nova mecânica de sub-rotina explícita

Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados os contratos antigos ( e até mesmo forçados a converter para o código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF - primeiro com um bytecode ligeiramente reduzido devido à característica de sub-rotinas, e em seguida com novas funcionalidades específicas do EOF ou custos de gas reduzidos.

Após a introdução do EOF, atualizações adicionais tornaram-se mais fáceis. O módulo EVM de extensão aritmética mais desenvolvido atualmente é o EVM-MAX(. O EVM-MAX cria um conjunto de novas operações especificamente para operações modulares e as coloca em um novo espaço de memória que não pode ser acessado por outros códigos de operação, o que possibilita o uso de otimizações como a multiplicação de Montgomery.

Uma ideia mais recente é combinar o EVM-MAX com a característica de múltiplos dados de uma única instrução )SIMD(. O SIMD, como um conceito do Ethereum, existe há muito tempo, sendo inicialmente proposto pelo EIP-616 de Greg Colvin. O SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, e a combinação do EVM-MAX com o SIMD torna essas duas extensões orientadas para o desempenho uma combinação natural.

![Vitalik sobre o possível futuro do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(

)# Pesquisa existente

• EOF:
• EVM-MAX:
• SIMD:

Trabalho restante e considerações

Atualmente, o EOF está planejado para ser incluído no próximo hard fork. Embora sempre haja a possibilidade de removê-lo no último minuto -- funcionalidades foram temporariamente removidas em forks anteriores, fazer isso enfrentará grandes desafios. Remover o EOF significa que qualquer atualização futura ao EVM deve ser feita sem o EOF, embora possa ser feito, pode ser mais difícil.

A principal consideração do EVM é a complexidade do L1 em relação à complexidade da infraestrutura, o EOF é uma grande quantidade de código que precisa ser adicionada à implementação do EVM, e a verificação de código estático também é relativamente complexa. No entanto, como troca, podemos simplificar as linguagens de alto nível, simplificar a implementação do EVM e outros benefícios. Pode-se dizer que a prioridade no roteiro de melhorias contínuas do Ethereum L1 deve incluir e ser baseada no EOF.

Uma tarefa importante a ser realizada é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark sobre o consumo de gas de várias operações criptográficas.

Como interagir com as outras partes do roteiro?

A L1 ajusta seu EVM para que L2 também possa realizar ajustes correspondentes com mais facilidade. Se ambos não forem ajustados em sincronia, isso pode causar incompatibilidades e trazer efeitos adversos. Além disso, EVM-MAX e SIMD podem reduzir o custo de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Isso também facilita a substituição de mais pré-compilações por código EVM que pode executar as mesmas tarefas, possivelmente sem impactar significativamente a eficiência.

![Vitalik sobre o possível futuro do Ethereum (seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(

) abstração de conta

Que problema foi resolvido?

Atualmente, as transações só podem ser verificadas de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta pretendia ir além disso, permitindo que a lógica de verificação da conta fosse qualquer código EVM. Isso pode habilitar uma série de aplicações:

• Mudar para criptografia quântica resistente
• Rotacionar chaves antigas ### é amplamente considerado uma prática de segurança recomendada (
• Carteira de múltiplas assinaturas e carteira de recuperação social
• Usar uma chave para operações de baixo valor, usar outra chave ) ou um conjunto de chaves ( para operações de alto valor

Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente sua complexidade e eliminando um ponto central de dependência.

Desde que a abstração de contas foi proposta em 2015, seu objetivo também se expandiu para incluir uma série de "objetivos de conveniência", como por exemplo, uma conta que não possui ETH mas possui alguns ERC20 podendo pagar o gas com ERC20.

)# O que é, como funciona?

O cerne da abstração de contas é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade surge de como implementar isso de uma maneira que seja amigável à manutenção de uma rede descentralizada e prevenir ataques de negação de serviço.

Um desafio chave típico é o problema da múltipla falha:

Se houver 1000 funções de verificação de contas que dependem de um único valor S, e o valor S atual faz com que as transações no pool de memórias sejam válidas, então uma única transação que inverta o valor de S pode invalidar todas as outras transações no pool de memórias. Isso permite que um atacante envie transações de lixo para o pool de memórias a um custo muito baixo, bloqueando assim os recursos dos nós da rede.

Após anos de esforço, visando expandir funcionalidades enquanto limita o risco de negação de serviço ###DoS(, chegou-se finalmente a uma solução para realizar a "abstração ideal da conta": ERC-4337.

O funcionamento do ERC-4337 divide o processamento das operações do usuário em duas fases: validação e execução. Todas as validações são processadas primeiro, e todas as execuções são processadas em seguida. No pool de memória, as operações do usuário só serão aceitas quando a fase de validação envolver apenas a sua própria conta e não ler variáveis de ambiente. Isso pode prevenir ataques de falha múltipla. Além disso, limites de gás rigorosos também são impostos à etapa de validação.

ERC-4337 foi projetado como um padrão de protocolo adicional )ERC(, porque na época os desenvolvedores de clientes Ethereum estavam focados na fusão )Merge(, sem energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 utiliza um objeto chamado operação de usuário, em vez de transações convencionais. No entanto, recentemente, percebemos a necessidade de escrever pelo menos parte disso no protocolo.

Duas razões chave são as seguintes:

1. A ineficiência inherente do EntryPoint como contrato: cada pacote tem um custo fixo de cerca de 100.000 gas, além de milhares de gas adicionais para cada operação do usuário.
2. Garantir a necessidade das propriedades do Ethereum: como a lista incluída que cria a garantia que precisa ser transferida para a conta do usuário abstrato.

Além disso, o ERC-4337 também expandiu duas funcionalidades:

• Agentes de pagamento )Paymasters(: Permite que uma conta pague taxas em nome de outra conta, o que viola a regra de que na fase de validação só se pode aceder à conta do próprio remetente, por isso foram introduzidos tratamentos especiais para garantir a segurança do mecanismo de agentes de pagamento.
• Agregadores): suporte a funções de agregação de assinaturas, como agregação BLS ou agregação baseada em SNARK. Isso é necessário para alcançar a máxima eficiência de dados em Rollup.

(# Link de pesquisa existente

• Palestra sobre a história da abstração de contas:
• ERC-4337:
• EIP-7702:
• O código BLSWallet ) usa a função de agregação ###:
• EIP-7562( escrever conta de abstração de protocolo ):
• EIP-7701( protocolo de escrita baseado em EOF conta abstrata ):

(# Trabalho restante e considerações

Atualmente, o principal desafio é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que ganhou popularidade recentemente é o EIP-7701, que implementa a abstração de contas sobre o EOF. Uma conta pode ter uma parte de código separada para verificação; se a conta configurar essa parte de código, essa parte será executada durante a etapa de verificação das transações provenientes daquela conta.

O fascínio deste método reside no fato de que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:

1. Incluir o EIP-4337 como parte do protocolo
2. Um novo tipo de EOA, onde o algoritmo de assinatura é a execução de código EVM.

Se começarmos a estabelecer limites rigorosos para a complexidade do código executável durante o período de validação - não permitindo o acesso a estados externos, e até mesmo o limite de gás estabelecido no início sendo baixo a ponto de ser ineficaz para aplicações de resistência quântica ou proteção de privacidade - então a segurança deste método fica muito clara: é apenas uma substituição da validação ECDSA por uma execução de código EVM que requer um tempo semelhante.

No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários, assim como a resistência quântica, é extremamente importante. Para isso, precisamos encontrar maneiras mais flexíveis de abordar os riscos de negação de serviço )DoS###, sem exigir que os passos de verificação sejam extremamente simplificados.

A principal compensação parece ser entre "escrever rapidamente uma solução que satisfaça menos pessoas" e "esperar mais tempo para possivelmente obter uma solução mais ideal", sendo que a abordagem ideal pode ser algum tipo de método híbrido. Um método híbrido é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implantar primeiro uma versão mais ambiciosa de abstração de contas no L2. No entanto, o desafio que isso enfrenta é que a equipe do L2 precisa ter plena confiança no trabalho da proposta de adoção para estar disposta a implementá-la, especialmente para garantir que o L1 e/ou outros L2 possam adotar soluções compatíveis no futuro.

Outra aplicação que também precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta no L1 ou em um L2 dedicado, mas pode ser utilizada no L1 e em qualquer L2 compatível. Fazer isso de forma eficaz pode exigir que o L2 suporte opcodes como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação da abstração de conta no L2 suporte essas operações.

(# Como interage com outras partes do roteiro?

A lista de inclusão precisa suportar transações de abstração de contas. Na prática, a necessidade de listas de inclusão é muito semelhante à necessidade de pools de memória descentralizados, embora a flexibilidade para listas de inclusão seja um pouco maior. Além disso, a implementação da abstração de contas deve coordenar-se entre L1 e L2 sempre que possível. Se no futuro esperarmos que a maioria dos usuários utilize Rollup de armazenamento de chaves, o design da abstração de contas deve ser baseado nisso.

![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###

( EIP-1559 melhoria

)# Que problema resolve?

EIP-1559 foi ativado no Ethereum em 2021, melhorando significativamente o tempo médio de inclusão de blocos.

No entanto, a implementação atual do EIP-1559 não é perfeita em vários aspectos:

1. A fórmula tem algumas falhas: não tem como objetivo 50% dos blocos, mas sim cerca de 50-53% dos blocos completos, dependendo da variância ###, o que está relacionado com o que os matemáticos chamam de "desigualdade entre a média aritmética e a média geométrica".