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

No design do protocolo Ethereum, muitos "detalhes" 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 a EVM em um "estado final" de alto desempenho e estabilidade
• Introduzir a abstração de conta no protocolo, permitindo que todos os usuários desfrutem de uma conta mais segura e conveniente.
• Otimizar a economia das taxas de transação, aumentar a escalabilidade enquanto se reduz o risco
• Explorar criptografia avançada, para que o Ethereum melhore significativamente a longo prazo

Melhoria do EVM

resolveu que problema?

Atualmente, o EVM é difícil de analisar estaticamente, o que torna complicado criar implementações eficientes, verificar 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 por meio de pré-compilações.

O que é, como funciona?

O primeiro passo do roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), planejado 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, enquanto os dados ( podem ser lidos, mas não são executáveis entre a separação de ).
• Proibida a redireção dinâmica, apenas permitido o redirecionamento estático
• O código EVM não pode mais observar informações relacionadas ao combustível
• Adicionou um novo mecanismo de sub-rotina explícita

Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, com contratos antigos ( podendo até ser convertidos para código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF - primeiro pela redução do código byte, ligeiramente menor devido às características de sub-rotina, e depois pelas novas funcionalidades específicas do EOF ou redução nos custos de gas.

Após a introdução do EOF, as atualizações subsequentes tornaram-se mais fáceis, sendo o desenvolvimento mais avançado atualmente 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 modulo e coloca-as 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), sendo que o SIMD, como um conceito do Ethereum, já existe há muito tempo, inicialmente proposto por Greg Colvin no EIP-616. O SIMD pode ser utilizado para acelerar várias formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes. A combinação do EVM-MAX e do SIMD torna essas duas expansões orientadas para desempenho uma combinação natural.

Um design aproximado para um EIP combinado começará com o EIP-6690 e, em seguida:

• Permitir (i) qualquer número ímpar ou (ii) qualquer potência de 2 até 2768 como módulo
• Para cada opcode EVM-MAX ( adição, subtração, multiplicação ), adicione uma versão que não usa mais 3 constantes imediatas x, y, z, mas sim 7 constantes imediatas: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. No código Python, o efeito desses opcodes é 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.

• Poderá adicionar XOR, AND, OR, NOT e SHIFT( incluindo ciclos e não ciclos), pelo menos para potências de 2 de módulo. Simultaneamente, adicionar ISZERO( irá enviar a saída para a pilha principal do EVM), o que será suficientemente potente para implementar criptografia de curva elíptica, criptografia de pequenos campos( como Poseidon, Circle STARKs), funções hash tradicionais( como SHA256, KECCAK, BLAKE) e criptografia baseada em redes. Outras atualizações do EVM também podem ser implementadas, mas até agora receberam menos atenção.

Link de pesquisa existente

• EOF:
• EVM-MAX:
• SIMD:

Trabalho restante e compensações

Atualmente, o EOF planeia ser incluído na próxima bifurcação dura. Embora sempre exista a possibilidade de ser removido no último minuto — funcionalidades foram temporariamente removidas em bifurcações duras anteriores, fazê-lo enfrentará grandes desafios. Remover o EOF significa que quaisquer atualizações futuras ao EVM terão de ser feitas sem o EOF, embora isso 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 quantidade significativa 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, 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 dada ao roteiro de melhorias contínuas do Ethereum L1 deve incluir e ser construída sobre o 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 em várias operações criptográficas.

Como interagir com outras partes do roteiro?

A L1 ajusta sua EVM para que a L2 também possa ser ajustada mais facilmente. Se ambas não forem ajustadas de forma sincronizada, isso pode causar incompatibilidade e trazer efeitos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir o custo de gás de muitos sistemas de prova, tornando a 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 impactar significativamente a eficiência.

Abstração de Conta

resolveu que problema?

Atualmente, as transações só podem ser validadas de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta visava ir além disso, permitindo que a lógica de validaçã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 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 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 tem alguns ERC20, podendo usar ERC20 para pagar o gas.

MPC( computação multipartidária ) é uma tecnologia com 40 anos de história, usada para dividir chaves em várias partes e armazená-las em vários dispositivos, utilizando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.

A EIP-7702 é uma proposta que está planeada para ser introduzida no próximo hard fork. A EIP-7702 é o resultado de uma crescente consciência sobre a conveniência da abstração de contas para beneficiar todos os usuários (, incluindo usuários EOA ), com o objetivo de melhorar a experiência de todos os usuários a curto prazo e evitar uma divisão em dois ecossistemas.

Este trabalho começou com o EIP-3074 e acabou por formar o EIP-7702. O EIP-7702 oferece a "função de conveniência" da abstração de contas a todos os usuários, incluindo as contas externas EOA( de hoje, ou seja, contas controladas por assinaturas ECDSA ).

Embora alguns desafios (, especialmente o desafio da "conveniência" ), possam ser resolvidos por tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança do proposta de abstração de conta, inicialmente apresentada, só pode ser alcançado retrocedendo e resolvendo o problema original: permitir que o código do contrato inteligente controle a validação de transações. A razão pela qual isso ainda não foi alcançado é a implementação segura, que representa um desafio.

O que é isso, como funciona?

A essência da abstração de conta é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade decorre da necessidade de implementar isso de uma forma que seja amigável à manutenção de redes descentralizadas e proteja contra 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 conta que dependem 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 tornar todas as outras transações no pool de memória inválidas. Isso permite que um atacante envie transações de lixo para o 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 alcançar a "abstractização ideal de contas": ERC-4337.

O funcionamento do ERC-4337 divide o processamento das operações do usuário 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, apenas quando a fase de verificação da operação do usuário envolve apenas a sua própria conta e não lê variáveis de ambiente é que será aceita. Isso pode prevenir ataques de falha múltipla. Além disso, limites rigorosos de gas também são impostos à etapa de verificação.

ERC-4337 foi projetado como um padrão de protocolo adicional (ERC), pois 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 disso no protocolo.

As duas razões principais são as seguintes:

1. A EntryPoint como a ineficiência inerente do 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 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 apenas a conta do remetente pode ser acessada durante a fase de verificação, 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 Rollups.

) ligação 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) escreve a abstração de conta do protocolo (:
• EIP-7701) conta abstrata de protocolo de escrita baseada em EOF (:

) O trabalho restante e as 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 que tem sido popular recentemente é o EIP-7701, que implementa a abstração de contas sobre o EOF.