- Tópico
25k Popularidade
18k Popularidade
61k Popularidade
31k Popularidade
3k Popularidade
95k Popularidade
28k Popularidade
27k Popularidade
7k Popularidade
18k Popularidade
- Pino
25k Popularidade
18k Popularidade
61k Popularidade
31k Popularidade
3k Popularidade
95k Popularidade
28k Popularidade
27k Popularidade
7k Popularidade
18k Popularidade
Futuro desenvolvimento do Ethereum: atualização do EVM e abstração de contas que lideram a prosperidade do protocolo
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. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias da EVM, enquanto o restante é composto por vários temas de nicho, e é isso que dá sentido a "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 é, como funciona?
O primeiro passo no roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), que está planejado para ser incluído na próxima bifurcação dura. 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, incluindo o contrato antigo (, que pode até ser forçado a converter para código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF - primeiro com bytecode levemente reduzido devido às características de sub-rotina, e depois com novas funcionalidades específicas do EOF ou redução de custos de gas.
Após a introdução do EOF, atualizações adicionais tornaram-se mais fáceis, atualmente 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 especialmente 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, tornando 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 Múltiplos Dados de Uma Única Instrução (SIMD), o SIMD como um conceito do Ethereum já existe há muito tempo, sendo proposto pela primeira vez por Greg Colvin no EIP-616. O SIMD pode ser utilizado para acelerar várias formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em matrizes, a combinação do EVM-MAX e SIMD faz com que essas duas expansões orientadas para o desempenho sejam uma combinação natural.
Um design geral de um EIP combinado começará com o EIP-6690 e, em seguida:
python 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 prática, isso será tratado de forma paralela.
ligação de pesquisa existente
Trabalho restante e considerações
Atualmente, o EOF está planeado para ser incluído na próxima hard fork. Embora seja sempre possível removê-lo no último minuto - funcionalidades foram temporariamente removidas em forks anteriores, fazê-lo representa um grande desafio. Remover o EOF significa que qualquer atualização futura ao EVM terá que ser feita sem o EOF, embora seja possível, pode ser mais difícil.
A principal compensaçã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 linguagens de alto nível, simplificar a implementação do EVM e obter outros benefícios. Pode-se dizer que a prioridade na melhoria contínua do L1 do Ethereum deve incluir e se basear no EOF.
Uma tarefa importante a ser realizada é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark do 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 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 significativamente os custos de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Isso também torna mais fácil substituir mais pré-compilados por código EVM que pode executar as mesmas tarefas, o que pode não impactar drasticamente a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser validadas de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta foi concebida para ir além disso, permitindo que a lógica de validaçã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, pode usar ERC20 para pagar o gás.
MPC( computação multipartidária ) é 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 criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
O EIP-7702 é uma proposta planejada para ser introduzida no próximo hard fork. O EIP-7702 é o resultado do reconhecimento crescente da conveniência de 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, finalmente, formou o EIP-7702. O EIP-7702 oferece a "funcionalidade de conveniência" da abstração de contas a todos os usuários, incluindo as contas externas EOA( de hoje, que são contas controladas por assinatura ECDSA).
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 originalmente 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 alcançado reside na 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 implementar isso de uma forma que seja amigável para a manutenção de redes descentralizadas e prevenir ataques de negação de serviço.
Um desafio chave típico é o problema de múltiplas falhas:
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 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, com o objetivo de expandir funcionalidades enquanto limita o risco de negação de serviço (DoS), finalmente foi alcançada a solução para implementar a "abstração ideal da conta": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações dos usuários em duas fases: validação e execução. Todas as validações são tratadas primeiro, e todas as execuções são tratadas 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 gas também são impostos na etapa de validaçã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 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 disso no protocolo.
Duas razões principais são as seguintes:
Além disso, o ERC-4337 também expandiu duas funcionalidades:
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# ligação 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 escrito recentemente e popular é o EIP-7701, que implementa a abstração de contas sobre o EOF. Uma conta pode ter uma seção de código separada para validação; se a conta definir essa seção de código, esse código será executado durante a etapa de validação das transações da conta.
Este método de