- Tópico
122 Popularidade
2k Popularidade
25k Popularidade
22k Popularidade
11k Popularidade
997 Popularidade
5k Popularidade
11k Popularidade
151k Popularidade
1739k Popularidade
- Pino
122 Popularidade
2k Popularidade
25k Popularidade
22k Popularidade
11k Popularidade
997 Popularidade
5k Popularidade
11k Popularidade
151k Popularidade
1739k Popularidade
Ethereum A fase Splurge: otimização EVM, abstração de contas e perspectivas da atualização EIP-1559
O possível futuro do protocolo Ethereum(seis): The Splurge
O design do protocolo Ethereum contém muitos "detalhes" que são cruciais para seu sucesso. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias no EVM, enquanto o restante é composto por uma variedade de temas de nicho, e é disso que se trata a "prosperidade".
Prosperidade: Objetivo chave
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 implementar 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 do roteiro de melhorias do EVM atual é o formato do objeto EVM (EOF), que está planejado para ser incluído na próxima bifurcação hard. 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, e contratos antigos ( poderão até ser forçados a converter-se em código EOF ). Os novos contratos beneficiarão da melhoria da eficiência proporcionada pelo EOF - primeiro com o bytecode ligeiramente reduzido devido às características de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou redução dos custos de gás.
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 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 usar 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, 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 redes, e a combinação do EVM-MAX com o SIMD torna essas duas extensões orientadas ao desempenho uma combinação natural.
Link de pesquisa existente
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 momento - em bifurcações duras anteriores, algumas funcionalidades foram temporariamente removidas, mas isso enfrentaria grandes desafios. Remover o EOF significa que quaisquer atualizações futuras ao EVM teriam que 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 requer a adição de uma grande quantidade de código à implementação do EVM, e a verificação de código estática também é relativamente complexa. No entanto, como troca, podemos simplificar linguagens de alto nível, simplificar a implementação do EVM e outros benefícios. Pode-se dizer que a prioridade na melhoria contínua do L1 do Ethereum 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 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 em sincronia, isso pode causar incompatibilidade 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. 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
Que problema foi resolvido?
Atualmente, as transações só podem ser verificadas de uma forma: 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 os protocolos de privacidade funcionem sem intermediários, reduzindo significativamente a sua complexidade e eliminando um ponto de dependência central crucial.
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 tem ETH, mas possui algum ERC20, podendo usar ERC20 para pagar o gás.
MPC( computação multi-partes) é uma tecnologia com 40 anos de história, utilizada para dividir chaves em várias partes e armazená-las em múltiplos dispositivos, aproveitando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
EIP-7702 é uma proposta planejada para ser introduzida na próxima bifurcação dura. 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 ), 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, por fim, formou 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).
O que é isso, como funciona?
O núcleo da abstração de contas é 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 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 de múltiplas falhas:
Se houver 1000 funções de validação de contas 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 inverte 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, com o objetivo de expandir funcionalidades enquanto se limita o risco de negação de serviço ( DoS ), chegou-se finalmente à solução para alcançar 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, somente 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 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) e não tinham energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usa objetos chamados de operações 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:
![Vitalik sobre o possível futuro do Ethereum (VI): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Link de pesquisa existente
)# Trabalho restante e 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, que tem estado em destaque 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 definir essa parte de código, esse código será executado na etapa de validação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele demonstra claramente duas perspectivas equivalentes da abstração de conta local:
Se começarmos a estabelecer limites rigorosos para a 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 estabelecido no início é 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: basta substituir a validação ECDSA por uma execução de código EVM que requer um tempo semelhante.
No entanto, à medida que o tempo passa, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários, bem como a resistência quântica, são muito importantes. Para isso, precisamos encontrar formas 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.
O principal trade-off parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo para possivelmente obter uma solução mais ideal", sendo que a abordagem ideal pode ser uma combinação de métodos. Uma abordagem mista é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é primeiro implantar uma versão de abstração de conta mais ambiciosa na L2. No entanto, o desafio é que a equipe da L2 precisa ter confiança no trabalho da proposta de adoção para estar disposta a implementar, especialmente para garantir que a L1 e/ou outras L2 possam adotar soluções compatíveis no futuro.
Outra aplicação que também precisamos considerar claramente é a conta de armazenamento de chaves, isso