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

No design do protocolo Ethereum, muitos "detalhes" importantes são cruciais para o seu sucesso. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias EVM, enquanto o restante é composto por vários tópicos de nicho, que é o 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.
• Otimização dos custos de transação, aumentando a escalabilidade enquanto reduz o risco
• Explorar criptografia avançada para melhorar significativamente o Ethereum a longo prazo

melhoria do EVM

Que problema foi resolvido?

Atualmente, a EVM é difícil de ser analisada 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 é, como funciona?

O primeiro passo do roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), que está previsto para ser incluído na próxima bifurcação dura. 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 ( é executável, mas não é possível ler ) do EVM e os dados ( podem ser lidos, mas não é possível executar a separação entre ).
• Proibido redirecionamento dinâmico, apenas redirecionamento estático permitido
• 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, com os contratos antigos ( podendo até ser forçados a converter-se para o código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF - primeiro através da bytecode ligeiramente reduzida devido à característica de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou custos de gas reduzidos.

Após a introdução do EOF, futuras atualizações tornaram-se mais fáceis, atualmente o mais desenvolvido é 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 modulares e as coloca em um novo espaço de memória que não pode ser acessado através de 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). SIMD, como um conceito do Ethereum, existe há muito tempo, tendo sido inicialmente proposto pelo EIP-616 de Greg Colvin. SIMD pode ser usado para acelerar muitas formas de criptografia, incluindo funções hash, STARKs de 32 bits e criptografia baseada em rede, e a combinação do EVM-MAX com SIMD torna estas duas extensões orientadas para o 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 ímpar ou (ii) qualquer potência de 2 com valor máximo de 2768 como módulo
• Para cada opcode EVM-MAX ( adição, subtração, multiplicação ), adicione uma versão que não utiliza mais 3 números imediatos x, y, z, mas sim 7 números imediatos: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. No código Python, esses opcodes funcionam de forma semelhante a:

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 prática, isso será tratado de forma paralela.

• Pode adicionar XOR, AND, OR, NOT e SHIFT( incluindo ciclos e não ciclos), pelo menos para potências 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 pequenos domínios( como Poseidon, Circle STARKs), funções de hash tradicionais( como SHA256, KECCAK, BLAKE) e criptografia baseada em grades. Outras atualizações do EVM também podem ser implementadas, mas até agora tiveram menos atenção.

Trabalho restante e considerações

Atualmente, o EOF está planejado para ser incluído no próximo hard fork. Embora sempre exista a possibilidade de removê-lo no último momento - em forks anteriores, algumas funcionalidades foram temporariamente removidas, mas fazê-lo enfrentará grandes desafios. Remover o EOF significa que quaisquer futuras atualizações ao EVM deverão ser feitas sem o EOF, embora seja possível, pode ser mais difícil.

O principal compromisso do EVM reside na complexidade do L1 e na 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 linguagens de alto nível, simplificar a implementação do EVM e outros benefícios. Pode-se dizer que a prioridade na melhoria contínua do roadmap do Ethereum L1 deve incluir e construir sobre o EOF.

Uma tarefa importante a ser realizada é implementar funcionalidades semelhantes a 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 o L2 também possa fazer ajustes correspondentes mais facilmente. Se ambos não forem ajustados de forma sincronizada, isso pode causar incompatibilidades e trazer efeitos adversos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente os custos 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 as mesmas tarefas, o que pode não afetar significativamente a eficiência.

abstração de conta

Que problema foi resolvido?

Atualmente, as transações só podem ser verificadas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de contas visava 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 resistente a quantos
• 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 convenientes", por exemplo, uma conta que não tem ETH, mas possui alguns ERC20, pode usar ERC20 para pagar o gas.

O que é, como funciona?

O núcleo da abstração de contas é simples: permitir que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade vem de implementar isso de uma maneira que seja amigável à manutenção de uma rede descentralizada, enquanto se previne ataques de negação de serviço.

Um desafio crítico típico é o problema da falha múltipla: se houver 1000 contas cuja função de validação depende de um único valor S, e o valor atual S torna todas as transações no 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 no pool de memória. Isso permite que um atacante envie transações lixo para o pool de memória a um custo extremamente baixo, obstruindo assim os recursos dos nós da rede.

Após anos de esforço, com o intuito de expandir funcionalidades ao mesmo tempo que limita o risco de negação de serviço ( DoS ), finalmente foi encontrada uma solução para implementar a "abstração ideal de contas": ERC-4337.

O funcionamento do ERC-4337 é dividido em duas fases: verificação e execução. Todas as verificações são processadas primeiro, seguidas de todas as execuções. No pool de memória, uma operação do usuário só será aceita se a fase de verificaçã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 rígidos de gas também são rigorosamente impostos à 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), não tendo 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 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 as garantias criadas pela lista incluída precisam ser transferidas para usuários de contas abstratas.

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ó é permitido acessar a conta do remetente. Portanto, foram introduzidos tratamentos especiais para garantir a segurança do mecanismo de agentes de pagamento.
• Agregadores(: suporta a funcionalidade de agregação de assinaturas, como agregação BLS ou agregação baseada em SNARK. Isto é 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-c0f722db75e53f4ff37ef40f5547dfc4.webp(

)# Trabalho restante e ponderações

Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem estado em alta recentemente é o EIP-7701, que implementa a abstração de contas acima do EOF. Uma conta pode ter uma parte de código separada para validação; se a conta definir essa parte de código, esse código será executado na etapa de validação das transações provenientes dessa conta.

A fascinante característica deste método é que ele revela claramente duas perspectivas equivalentes da abstração de contas locais:

1. Incorporar 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 à complexidade do código executável durante o período de validação -- não permitindo acesso a estados externos, e mesmo os limites de gas definidos inicialmente sendo tão baixos que se tornam inúteis para aplicações de resistência quântica ou proteção de privacidade -- então a segurança desse método é muito clara: é simplesmente 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 flexibilizar 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 resolver os riscos de negação de serviço ###DoS(, sem exigir que os passos de verificação sejam extremamente simplistas.

A principal consideração parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo, possivelmente obtendo uma solução mais ideal"; a abordagem ideal pode ser algum tipo de método misto. Um método misto é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implantar primeiro uma versão de abstração de conta mais ambiciosa no L2. No entanto, o desafio enfrentado é 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.

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

Outra aplicação que precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado da conta relacionado em L1 ou L2 dedicado, mas pode ser utilizada em L1 e em qualquer L2 compatível. Fazer isso de maneira eficaz pode exigir que o L2 suporte funções como L1SLOAD ou REMOTESTATI.