O futuro potencial do protocolo Ethereum (六): prosperidade

Escrito por: Vitalik Buterin

Algumas coisas são difíceis de classificar em uma única categoria. No design do protocolo Ethereum, muitos "detalhes" são extremamente importantes para o sucesso do Ethereum. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias na 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, aumentando a escalabilidade enquanto reduz o risco
• Explorar 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 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, tornando difícil 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 e 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. 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:

• 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
• 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 (podendo até ser forçados a converter-se para código EOF). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF ------ primeiro com bytecode ligeiramente reduzido através da funcionalidade de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou redução de custos de gas.

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 criou um conjunto de novas operações especificamente para a operação de módulo e as colocou 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 características de múltiplos dados de uma única instrução (SIMD), sendo que 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 utilizado 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 o SIMD torna essas duas expansões orientadas para o desempenho um emparelhamento natural.

Um design geral de um conjunto de EIP começará com o EIP-6690 e, em seguida:

• 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), adicionar uma versão que não usa 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.

• Pode adicionar XOR, AND, OR, NOT e SHIFT (incluindo rotacionais e não rotacionais), pelo menos para módulos de potências de 2. Ao mesmo tempo, adicionar ISZERO (que empurra a saída para a pilha principal da EVM), o que será poderoso o suficiente 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 da EVM também podem ser implementadas, mas até agora têm recebido menos atenção.

Link de pesquisa existente

• EOF:
• EVM-MAX:
• SIMD:

Trabalho restante e ponderações

Atualmente, o EOF está planejado para ser incluído na próxima bifurcação dura. Embora sempre exista a possibilidade de removê-lo no último minuto ------ em bifurcações duras anteriores, algumas funcionalidades foram temporariamente removidas, mas 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 seja possível, pode ser mais difícil.

A principal consideração do EVM está 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 as linguagens de alto nível, simplificar a implementação do EVM e outros benefícios. Pode-se dizer que a prioridade para o roadmap 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 referência sobre o consumo de gas das 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 fazer ajustes correspondentes mais facilmente; se ambos não forem ajustados em sincronia, pode haver incompatibilidade, trazendo impactos 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 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 como objetivo superar isso, 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 como 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 os protocolos de privacidade funcionem sem intermediários, reduzindo significativamente sua complexidade e eliminando um ponto crítico de dependência central.

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 algum ERC20, pode usar ERC20 para pagar o gas. Abaixo está o gráfico resumido desses objetivos:

MPC (Cálculo Multi-Sided) é uma tecnologia com 40 anos de história que divide chaves em várias partes e as armazena em vários dispositivos, utilizando técnicas criptográficas para gerar assinaturas sem a necessidade de combinar diretamente essas partes de chave.

EIP-7702 é uma proposta que está prevista para ser introduzida no próximo hard fork. A EIP-7702 é o resultado do reconhecimento crescente da conveniência da abstração de contas para beneficiar todos os usuários (incluindo usuários EOA), visando 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 "funcionalidade de conveniência" da abstração de contas a todos os usuários, incluindo as EOA (Contas de Propriedade Externa, 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 através de tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas apresentada inicialmente só pode ser alcançado retrocedendo e resolvendo o problema original: permitir que o código de contrato inteligente controle a validação de transações. A razão pela qual isso ainda não foi alcançado reside na implementação segura, que é um desafio.

O que é isso 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 como implementar isso de uma maneira que seja amigável à manutenção de redes descentralizadas e prevenir ataques de negação de serviço.

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

Se houver 1000 funções de verificação de contas que dependem de um único valor S, e o valor atual S faz com que todas as transações no pool de memória sejam 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 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, que visam expandir as funcionalidades enquanto limitam o risco de negação de serviço (DoS), finalmente foi encontrada a solução para implementar a "abstração ideal de contas": ERC-4337.

A forma de funcionamento do ERC-4337 é dividir o processamento das operações do usuário em duas fases: verificação e execução. Todas as verificações são tratadas primeiro, e todas as execuções são tratadas em seguida. No pool de memória, as operações do usuário só serão aceitas quando 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 falhas múltiplas. Além disso, limites de gas rigorosos são também 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) e não tinham energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usou um objeto chamado operação do usuário, em vez de transações convencionais. No entanto, recentemente percebemos a necessidade de incorporar pelo menos parte disso no protocolo.

Duas razões principais são as seguintes:

1. EntryPoint como a ineficiência inerente ao 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 de um utilizador abstrato.

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

• Agentes de pagamento (Paymasters): permitem que uma conta pague taxas em nome de outra conta, o que viola a regra que estipula que a fase de verificação só pode acessar a própria conta do remetente, portanto, foram introduzidos tratamentos especiais para garantir a segurança do mecanismo de agentes de pagamento.
• Agregadores: suportam a funcionalidade de agregação de assinaturas, como a agregação BLS ou a agregação baseada em SNARK. Isso é necessário para alcançar a máxima eficiência de dados no Rollup.

Link de pesquisa existente

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

restante