O possível futuro do protocolo Ethereum(seis): prosperidade

Algumas coisas são difíceis de classificar em uma única categoria. No design do protocolo Ethereum, muitos "detalhes" são muito importantes para o sucesso do Ethereum. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias do EVM, enquanto o restante é composto por vários tópicos de nicho, e é isso que significa "prosperidade".

Prosperidade: Objetivo-chave

• Transformar o EVM em um "estado final" de alto desempenho e estabilidade
• Introduzir a abstração de contas 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 se reduz o risco
• Explorar a criptografia avançada, para que o Ethereum melhore significativamente a longo prazo

melhoria do EVM

Que problema foi resolvido?

Atualmente, o EVM é difícil de analisar estaticamente, o que torna complicado criar implementações eficientes, validar formalmente o código e realizar expansões adicionais. Além disso, a eficiência do 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 é, como funciona?

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

• O código ( é executável, mas não pode ler ) do EVM e os dados ( podem ser lidos, mas não podem executar a separação entre ).
• 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 serem convertidos para código EOF ). Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF — primeiro com o bytecode ligeiramente reduzido através de características de sub-rotina, e depois com novas funcionalidades específicas do EOF ou redução nos custos de gas.

Após a introdução do EOF, futuras atualizações tornaram-se mais fáceis, atualmente o desenvolvimento mais avançado é a extensão aritmética do módulo EVM ( EVM-MAX ). O EVM-MAX cria um conjunto de novas operações especificamente para operações de módulo 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 torna possível 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, já existe há muito tempo, tendo sido proposto pela primeira vez por Greg Colvin no EIP-616. O SIMD pode ser usado para acelerar muitas formas de criptografia, incluindo funções hash, STARKs de 32 bits e criptografia baseada em redes. A combinação do EVM-MAX e do SIMD torna estas duas expansões orientadas para desempenho uma combinação natural.

Um design geral de um EIP de combinação começará com o EIP-6690 e depois:

• Permitir (i) qualquer número ímpar ou (ii) qualquer potência de 2 até 2768 como módulo
• Para cada código de operação EVM-MAX ( adição, subtração, multiplicação ), adicione uma versão que não utiliza mais 3 valores imediatos x, y, z, mas sim 7 valores imediatos: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. No código Python, a função desses códigos de operação é similar a:

python for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

Na implementação real, isso será tratado em paralelo.

• Pode adicionar XOR, AND, OR, NOT e SHIFT( incluindo ciclos e não-ciclos), pelo menos para uma potência de 2 módulo. Ao mesmo tempo, adicionar ISZERO( irá empurrar a saída para a pilha principal do EVM), o que será suficientemente poderoso para implementar criptografia de curva elíptica, criptografia de pequeno domínio( como Poseidon, Circle STARKs), funções de hash tradicionais( como SHA256, KECCAK, BLAKE) e criptografia baseada em redes. Outras atualizações do EVM também podem ser implementadas, mas até agora têm recebido menos atenção.

Trabalho restante e ponderações

Atualmente, o EOF está planeado para ser incluído no próximo hard fork. Embora sempre exista a possibilidade de ser removido no último momento — funcionalidades foram temporariamente removidas em hard forks anteriores, fazê-lo enfrentará grandes desafios. Remover o EOF significa que qualquer atualização futura ao EVM terá que ser feita sem o EOF, embora seja possível, 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 adicionado à implementação do EVM, e a verificação de código estático também é relativamente complexa. No entanto, em troca, podemos simplificar as linguagens de alto nível, simplificar a implementação do EVM e obter outros benefícios. Pode-se dizer que o roteiro para a melhoria contínua do Ethereum L1 deve incluir e basear-se 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 gás de várias operações criptográficas.

Como interagir com outras partes do roteiro?

A L1 ajusta seu EVM para que o L2 também possa realizar ajustes correspondentes com mais facilidade. Se ambos não forem ajustados em sincronia, pode haver incompatibilidade, trazendo efeitos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir o custo de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Isso também torna mais fácil substituir mais pré-compilações por código EVM que pode executar a mesma tarefa, o que pode não afetar significativamente a eficiência.

abstração de conta

Que problema foi resolvido?

Atualmente, a transação só pode ser verificada de uma forma: assinatura ECDSA. Inicialmente, a abstração de contas foi concebida para ir além disso, permitindo que a lógica de verificação da conta seja qualquer código EVM. Isso pode habilitar uma série de aplicações:

• Mudar para criptografia quântica resistente
• A rotação de chaves antigas ( é amplamente considerada uma prática de segurança recomendada )
• carteira multi-assinatura 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 a sua complexidade e eliminando um ponto de dependência central crítico.

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", por exemplo, uma conta que não possui ETH, mas tem alguns ERC20, pode usar ERC20 para pagar o gás.

O que é, como funciona?

O núcleo da abstração de conta é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade vem de implementar isso de uma forma que mantenha a rede descentralizada amigável e previna ataques de negação de serviço.

Um desafio chave típico é o problema de múltiplas falhas:

Se houver 1000 funções de verificação de contas que dependem de um único valor S, e o valor S atual torna todas as transações na pool de memória válidas, então uma única transação que inverta o valor de S pode invalidar todas as outras transações na pool de memória. Isso permite que um atacante envie transações de lixo para a pool de memória 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 à solução para a implementação da "abstração ideal de contas": ERC-4337.

O funcionamento do ERC-4337 divide o processamento das operações dos usuários em duas fases: verificação e execução. Todas as verificações são processadas primeiro, e todas as execuções são processadas posteriormente. No pool de memória, as operações dos usuários são aceitas apenas quando a fase de verificação envolve apenas a sua própria conta e não lê variáveis de ambiente. Isso pode prevenir ataques de falha múltipla. Além disso, limites rígidos de gás também são rigorosamente aplicados à etapa de verificaçã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 do usuário, em vez de transações convencionais. No entanto, recentemente percebemos a necessidade de escrever pelo menos parte do conteúdo no protocolo.

Duas razões principais são as seguintes:

1. A ineficiência inerente 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 de inclusão criada inclui garantias que precisam ser transferidas para a conta de usuários abstratos.

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

• Agente de pagamento ( Paymasters ): permite que uma conta pague taxas em nome de outra conta, o que viola a regra de que a fase de verificação só pode acessar a conta do remetente em si, por isso foram introduzidos tratamentos especiais para garantir a segurança do mecanismo de agente de pagamento.
• Agregadores(: suporta 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.

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

Trabalho restante e ponderações

Atualmente, a principal questão a resolver é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas recentemente popularizado é 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, esse código será executado na etapa de verificação das transações provenientes dessa 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. Integrar 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 sobre a complexidade do código executável durante o período de validação — não permitindo o acesso a estados externos, e mesmo o limite de gás definido inicialmente sendo tão baixo que se torna inválido para aplicações de resistência quântica ou proteção de privacidade — então a segurança desse método é muito clara: é apenas substituir a validação ECDSA por uma execução de código EVM que requer um tempo semelhante.

No entanto, à medida que o tempo passa, 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, são extremamente importantes. 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 simplistas.

A principal compensação parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo, possivelmente obtendo uma solução mais ideal", sendo o método ideal uma certa abordagem mista. Uma abordagem mista é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implementar primeiro uma versão mais ambiciosa da abstração de contas no L2. No entanto, o desafio aqui é que a equipe do L2 precisa ter 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 precisamos considerar claramente são as contas de armazenamento de chaves, que armazenam o estado relacionado à conta na L1 ou em L2s dedicadas, mas podem ser usadas na L1 e em qualquer L2 compatível. Fazer isso de forma eficaz pode exigir que o L2 suporte códigos de operação como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação de abstração de conta no L2 suporte essas operações.

Como isso interage com outras partes do roteiro?

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

![Vitalik sobre o possível futuro do Ethereum（