- Tópico
550 Popularidade
31k Popularidade
720 Popularidade
29k Popularidade
7k Popularidade
14k Popularidade
17k Popularidade
155k Popularidade
1836k Popularidade
60k Popularidade
- Pino
550 Popularidade
31k Popularidade
720 Popularidade
29k Popularidade
7k Popularidade
14k Popularidade
17k Popularidade
155k Popularidade
1836k Popularidade
60k Popularidade
Desenvolvimento do protocolo Ethereum: Atualização do EVM e avanço na abstração de contas
O futuro possível do protocolo Ethereum (seis): prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais para o seu sucesso. Cerca de metade do conteúdo envolve diferentes tipos de melhorias do EVM, enquanto o restante é composto por vários tópicos de nicho, e é isso que significa "prosperidade".
Prosperidade: Objetivo chave
melhoria do EVM
Que problema foi resolvido?
Atualmente, o 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 do 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 é isso, como funciona?
O primeiro passo do roteiro de melhoria do EVM atual é o formato de objeto EVM (EOF), que está planejado para ser incluído na próxima hard fork. 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:
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, com a conversão forçada para código EOF (. Os novos contratos beneficiarão do aumento de eficiência proporcionado pelo EOF - primeiro com bytecode ligeiramente reduzido através de características de sub-rotinas, e posteriormente com novas funcionalidades específicas do EOF ou custos de gas reduzidos.
Após a introdução do EOF, atualizações 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 inacessível por outros códigos de operação, tornando possível o uso de otimizações como a multiplicação de Montgomery.
Uma ideia mais recente é combinar o EVM-MAX com características de SIMD de múltiplos dados de uma única instrução )SIMD(, sendo que SIMD já existe como um conceito em Ethereum há muito tempo, sendo proposto inicialmente por Greg Colvin no EIP-616. SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, a combinação do EVM-MAX e SIMD torna essa dupla de escalabilidade orientada para o desempenho uma combinação natural.
Um design geral de um EIP combinatório começará com o 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 implementação real, isso será tratado de forma paralela.
![Vitalik sobre o futuro possível do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Trabalho restante e consideraçõ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 momento - em bifurcações duras anteriores, algumas funcionalidades foram temporariamente removidas, mas fazê-lo enfrentará grandes desafios. Remover o EOF significa que quaisquer atualizações futuras para o EVM precisam ser feitas sem o EOF, embora seja possível, pode ser mais difícil.
O principal trade-off do EVM está na complexidade do L1 e na complexidade da infraestrutura. O EOF é um grande conjunto de códigos 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 priorização do roteiro de melhorias contínuas do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante a realizar é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark sobre o consumo de gas das várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta seu EVM para que a L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não forem ajustados de forma síncrona, isso pode causar incompatibilidades e trazer 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é-compilações por código EVM que pode executar as mesmas tarefas, o que pode não afetar significativamente a eficiência.
![Vitalik sobre o possível futuro do Ethereum (seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) 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:
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) cálculo multipartidário( é uma tecnologia com 40 anos de história, utilizada para dividir uma chave em várias partes e armazená-las em vários dispositivos, aproveitando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes da chave.
EIP-7702 é uma proposta que está planejada para ser introduzida na próxima bifurcação dura. EIP-7702 é o resultado de um reconhecimento crescente da conveniência de 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 finalmente formou o EIP-7702. O EIP-7702 oferece a "funcionalidade conveniente" da abstração de contas a todos os usuários, incluindo as contas externas atualmente existentes EOA), que são contas controladas por assinaturas ECDSA (.
![Vitalik sobre o futuro possível do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
A partir do gráfico, pode-se ver que, embora alguns desafios ), especialmente o desafio de "conveniência" (, possam ser resolvidos por meio de 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 deve-se à implementação segura, que é um desafio.
)# O que é, 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 realizar isso de uma maneira que seja amigável para a manutenção de uma rede descentralizada e prevenir ataques de negação de serviço.
Um desafio crítico típico é o problema da múltipla falha:
Se houver 1000 funções de verificação de contas que dependem de um único valor S, e o valor S atual faz com que as transações no pool de memória sejam todas 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 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 (, foi finalmente alcançada uma solução para a implementação da "abstração ideal de contas": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações do usuário em duas etapas: 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, as operações do usuário são aceitas apenas quando a fase de verificação envolve apenas a sua própria conta e não lê 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(, não havia 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.
Duas razões-chave são as seguintes:
Além disso, o ERC-4337 também expandiu duas funcionalidades:
(# Trabalho restante e ponderação
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 ganho popularidade recentemente é o EIP-7701, que implementa a abstração de contas em cima do EOF. Uma conta pode ter uma parte de código separada para verificação; se a conta configurar essa parte de código, ela será executada na etapa de verificação das transações provenientes dessa conta.
A beleza deste método reside no fato de que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Se começarmos a estabelecer limites rigorosos sobre a complexidade do código executável durante o período de validação - não permitindo o acesso ao estado externo, e mesmo o limite de gas definido no início sendo tão baixo que se torna ineficaz 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, com o passar do tempo, precisamos relaxar 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 muito importantes. Para isso, precisamos encontrar uma maneira mais flexível de resolver o serviço de negação )DoS### vento.