- Tema
38k Popularidade
14k Popularidade
7k Popularidade
16k Popularidade
62k Popularidade
31k Popularidade
3k Popularidade
96k Popularidade
27k Popularidade
27k Popularidade
- Marcar
38k Popularidade
14k Popularidade
7k Popularidade
16k Popularidade
62k Popularidade
31k Popularidade
3k Popularidade
96k Popularidade
27k Popularidade
27k Popularidade
Perspectivas futuras do protocolo Ethereum: atualização do EVM e o caminho crucial para a abstração de contas
O futuro possível 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 fundamentais 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 assuntos de nicho, e é isso que significa "prosperidade".
Prosperidade: Objetivo chave
melhoria do protocolo 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, 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 no roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), planejado para ser incluído na próxima hard fork. EOF é uma série de EIPs que especificam uma nova versão de código EVM, com muitas características únicas, sendo a mais significativa:
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, e os contratos antigos ( poderão até ser convertidos forçadamente em código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF — primeiro com um bytecode ligeiramente reduzido devido à funcionalidade de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou custos de gas reduzidos.
Após a introdução do EOF, melhorias adicionais tornaram-se mais fáceis. 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 SIMD (Single Instruction, Multiple Data) (, sendo que SIMD, como um conceito em Ethereum, já existe há muito tempo, tendo sido proposto inicialmente por Greg Colvin no EIP-616. SIMD pode ser usado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em rede. A combinação do EVM-MAX e SIMD torna essas duas extensões orientadas para desempenho uma combinação natural.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Um design aproximado de um EIP combinado começará pelo EIP-6690 e, em seguida:
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.
)# Trabalho restante e considerações
Atualmente, o EOF está programado para ser incluído na próxima bifurcação dura. Embora sempre exista a possibilidade de removê-lo no último minuto — funcionalidades foram temporariamente removidas em bifurcações duras anteriores, fazê-lo enfrentará grandes desafios. Remover o EOF significa que quaisquer futuras atualizações ao EVM terão que ser feitas sem o EOF, embora isso possa ser feito, pode ser mais difícil.
O principal trade-off do EVM reside na complexidade do L1 e na complexidade da infraestrutura. O EOF requer a adição de uma grande quantidade de código à 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 obter outros benefícios. Pode-se dizer que o roadmap priorizando a melhoria contínua do Ethereum L1 deve incluir e ser construído 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 ser ajustado mais facilmente; se ambos não forem ajustados de forma sincronizada, isso pode causar incompatibilidade e trazer efeitos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir os custos de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Isso também facilita a substituição de 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 tinha como objetivo ir além disso, permitindo que a lógica de verificação das contas fosse qualquer código EVM. Isso pode habilitar uma série de aplicações:
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 que tem alguns ERC20, podendo usar ERC20 para pagar o gás.
MPC) cálculo multipartidário( é uma tecnologia com 40 anos de história, utilizada para dividir chaves em várias partes e armazená-las em vários dispositivos, utilizando técnicas de criptografia para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
A EIP-7702 é uma proposta que se planeia introduzir na próxima hard fork. A EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência da abstração de contas para beneficiar todos os usuários ), incluindo usuários EOA (, e visa melhorar a experiência de todos os usuários a curto prazo, evitando a divisão em dois ecossistemas.
Este trabalho começou com o EIP-3074 e acabou formando o EIP-7702. O EIP-7702 fornece a "funcionalidade de conveniência" da abstração de contas a todos os usuários, incluindo as contas EOA) externas, ou seja, contas controladas por assinatura ECDSA(.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
A partir do gráfico, pode-se ver que, embora alguns desafios ), especialmente o desafio de "conveniência" (, possam ser resolvidos através de tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança do projeto de abstração de contas inicialmente proposto 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 está na implementação segura, que é um desafio.
)# O que é, como funciona?
O núcleo da abstração de conta é 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 e que previna ataques de negação de serviço.
Um desafio chave típico é o problema da múltipla falha:
Se houver uma função de validação de 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 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ços, visando expandir funcionalidades enquanto limita o risco de negação de serviço ###DoS(, finalmente foi alcançada uma solução para realizar a "abstraçã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 em seguida. 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 de gás rigorosos também são 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(, sem energia adicional para lidar com outras funcionalidades. É por isso que o ERC-4337 usa 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-chave são as seguintes:
Além disso, o ERC-4337 também expandiu duas funcionalidades:
(# O trabalho restante e as consideraçõ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 de escrita em protocolo que tem sido popular recentemente é o EIP-7701, que implementa a abstração de contas sobre o EOF. Uma conta pode ter uma parte de código separada para validação; se a conta configurar essa parte de código, ela será executada na etapa de validação das transações provenientes dessa conta.
A parte fascinante deste método é que ele mostra claramente duas perspectivas equivalentes da abstração de contas locais:
Se começarmos a estabelecer limites rigorosos em relação à complexidade do código executável durante a validação - não permitindo o acesso ao estado externo, e mesmo o limite de gás definido no início 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 substituindo a verificação ECDSA pela execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar essas limitações, 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 simplificados.
principal