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

Escrito por: Vitalik Buterin

Algumas coisas são difíceis de categorizar, no design do protocolo Ethereum, muitos "detalhes" são muito importantes para o sucesso do Ethereum. Na verdade, cerca de metade do conteúdo refere-se a diferentes tipos de melhorias 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 e ao mesmo tempo reduzir o risco
• Explorar a criptografia avançada, permitindo 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 complicado criar implementações eficientes, validar formalmente o código e realizar expansões adicionais. Além disso, a eficiência da EVM é baixa, tornando difícil a implementação de muitas formas de criptografia avançada, a menos que seja explicitamente suportada por 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á previsto para ser incluído na próxima bifurcação dura. O 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:

• A separação entre código (executável, mas não legível a partir da EVM) e dados (legíveis, mas não executáveis)
• 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 rotinas de subexemplo explícitas

Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados (e até mesmo forçados a converter-se em código EOF). Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro, através de um bytecode ligeiramente reduzido com a característica de sub-rotina, e em seguida, com novas funcionalidades específicas do EOF ou custos de gás reduzidos.

Após a introdução do EOF, as atualizações adicionais tornaram-se mais fáceis. 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 a operação de módulo e as coloca em um novo espaço de memória inacessível através de 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 as características de múltiplos dados de uma única instrução (SIMD), que já é um conceito no Ethereum há muito tempo, sendo 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 rede. A combinação do EVM-MAX com o SIMD torna essas duas extensões orientadas para o desempenho uma combinação natural.

Um design aproximado de um conjunto de EIPs começará com o EIP-6690 e depois:

• Permitir (i) qualquer número ímpar ou (ii) qualquer potência de 2 que seja no máximo 2768 como módulo
• Para cada opcode EVM-MAX (adição, subtração, multiplicação), adicione uma versão que não use 3 literais x, y, z, mas sim 7 literais: 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 rotacionais e não rotacionais), pelo menos para módulos de potência de 2. Ao mesmo tempo, adicionar ISZERO (que 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 hash tradicionais (como SHA256, KECCAK, BLAKE) e criptografia baseada em redes. Outras atualizações do EVM também podem ser implementadas, mas até agora tiveram menos foco.

Links de pesquisas existentes

• EOF:
• EVM-MAX:
• SIMD:

O trabalho restante e considerações

Atualmente, o EOF está planejado para ser incluído na próxima hard fork. Embora sempre seja possível removê-lo na última hora — 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 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 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 outros benefícios. Pode-se dizer que a prioridade para o roteiro de melhoria contínua do Ethereum L1 deve incluir e ser construída sobre o EOF.

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

Como interagir com outras partes do roteiro?

A L1 ajusta seu EVM para que a L2 também possa fazer ajustes correspondentes mais facilmente. Se ambos não forem ajustados de forma sincronizada, pode causar incompatibilidade, resultando em efeitos adversos. Além disso, o EVM-MAX e o SIMD podem reduzir os custos de gas de muitos sistemas de prova, tornando a L2 mais eficiente. Isso também facilita a substituição de mais pré-compilados 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 forma: assinatura ECDSA. Inicialmente, a abstração de contas tinha o objetivo de 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 quântica
• Rotacionar chaves antigas (amplamente considerado como 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 a necessidade de intermediários, reduzindo significativamente a sua complexidade e eliminando um ponto central de dependência.

Desde que a abstração de conta 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 pagar gas com ERC20. Abaixo está um gráfico resumo desses objetivos:

MPC (cálculo multipartido) é uma tecnologia com 40 anos de história, utilizada para dividir uma chave em várias partes e armazená-las em múltiplos dispositivos, utilizando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes da chave.

EIP-7702 é uma proposta que está prevista para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de uma crescente consciência sobre a conveniência de fornecer 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 a divisão em dois ecossistemas.

Este trabalho começou com o EIP-3074 e culminou no EIP-7702. O EIP-7702 oferece a todos os usuários as "funções convenientes" da abstração de conta, incluindo as EOA (contas externas, ou seja, contas controladas por assinaturas ECDSA) de hoje.

A partir do gráfico, pode-se ver que, 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 da proposta de abstração de contas 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 das transações. A razão pela qual isso ainda não foi realizado é a implementação segura, que representa um desafio.

O que é e como funciona?

O núcleo da abstração de contas é simples: permite 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 e de prevenir ataques de negação de serviço.

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

Se houver uma função de validação para 1000 contas que dependa 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 fazer com que todas as outras transações no pool de memória se tornem inválidas. Isso permite que um atacante envie transações lixo para o pool de memória com um custo muito baixo, bloqueando assim os recursos dos nós da rede.

Após anos de esforços, com o objetivo de expandir funcionalidades enquanto limita o risco de negação de serviço (DoS), chegou-se finalmente à solução para implementar a "abstração ideal de conta": ERC-4337.

O funcionamento do ERC-4337 é dividir o processamento das operações do usuário em duas fases: validação e execução. Toda a validação é processada primeiro, e toda a execução é processada em seguida. No pool de memória, uma operação do usuário só será aceita se 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 rigorosos de gás são também aplicados à etapa de validaçã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) e não tinham energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usa objetos chamados operações 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.

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

1. EntryPoint como a ineficiência inerente do contrato: cada bundle tem um custo fixo de cerca de 100.000 gas, além de milhares de gas adicionais por operação de cada usuário.
2. Garantir a necessidade das propriedades do Ethereum: como a lista de inclusão criada que garante a necessidade de ser transferida para a conta do usuário abstrato.

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

• Agentes de pagamento (Paymasters): funcionalidade que permite que uma conta pague taxas em nome de outra conta, o que viola a regra de que a fase de validação só pode acessar a conta do remetente em si, portanto, foram introduzidos tratamentos especiais para garantir a segurança do mecanismo de agentes de pagamento.
• Agregadores (Aggregators): suportam a funcionalidade 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.

Ligação de pesquisa existente

• Discurso sobre a história da abstração de contas:
• ERC-4337：
• EIP-7702：
• Código BLSWallet (usando a função de agregação):
• EIP-7562 (abstração de conta no protocolo):
• EIP-7701 (protocolo de abstração de conta de escrita baseado em EOF):