- Tema
109k Popularidade
22k Popularidade
5k Popularidade
29k Popularidade
16k Popularidade
23k Popularidade
14k Popularidade
3k Popularidade
13k Popularidade
154k Popularidade
- Marcar
109k Popularidade
22k Popularidade
5k Popularidade
29k Popularidade
16k Popularidade
23k Popularidade
14k Popularidade
3k Popularidade
13k Popularidade
154k Popularidade
Caminho de prosperidade do protocolo Ethereum: melhorias no EVM, abstração de contas e Gas multidimensional
O futuro potencial do protocolo Ethereum (seis): Capítulo da prosperidade
Algumas coisas são difíceis de classificar em uma única categoria. No design do protocolo Ethereum, muitos "detalhes" são muito importantes 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 tópicos de nicho, e é disso que se trata a "prosperidade".
Prosperidade: objetivo chave
EVM melhoria
Que problema foi resolvido?
Atualmente, a 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 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 é e como funciona?
O primeiro passo do roteiro de melhoria do EVM atual é o formato de objeto EVM (EOF), que está previsto para ser incluído no próximo hard fork. O EOF é uma série de EIPs que especifica 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 podem ser criados, embora possam eventualmente ser gradualmente descontinuados (podendo até ser forçados a converter para código EOF). Os contratos novos beneficiarão do aumento de eficiência trazido pelo EOF.
Após a introdução do EOF, atualizações adicionais tornaram-se mais fáceis, sendo que 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 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 várias formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, e a combinação do EVM-MAX com o SIMD torna estas duas expansões orientadas para o desempenho uma combinação natural.
Link de pesquisa existente
Trabalho restante e compensações
Atualmente, o EOF está previsto para ser incluído na próxima bifurcação dura. Embora seja sempre possível removê-lo no último momento, isso enfrentará grandes desafios. 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 trade-off do EVM é entre a complexidade do L1 e a complexidade da infraestrutura; o EOF é uma grande quantidade de código que precisa ser adicionada à 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 do roteiro de melhorias contínuas do Ethereum L1 deve incluir e construir sobre o EOF.
Uma tarefa importante a realizar é implementar funcionalidades semelhantes a 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?
L1 ajusta seu EVM para que L2 também possa ser ajustado mais facilmente. Se ambos não forem ajustados de forma sincronizada, pode haver incompatibilidade, resultando em efeitos adversos. Além disso, EVM-MAX e SIMD podem reduzir os custos de gás de muitos sistemas de prova, tornando 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 podem ser verificadas de apenas 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 ativar uma série de aplicações:
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.
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 maneira que seja amigável para a manutenção de redes descentralizadas e prevenir ataques de negação de serviço.
Após anos de esforços, que visavam expandir funcionalidades enquanto limitavam o risco de negação de serviço (DoS), finalmente chegou-se a uma solução para implementar 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: validação e execução. Todas as validaçõ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ó serão aceitas 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 de gas rigorosos também são impostos à etapa de validação.
ligação de pesquisa existente
Trabalho restante e ponderações
Atualmente, a principal necessidade é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas que ganhou popularidade 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 principal consideração parece ser entre "escrever rapidamente uma solução que satisfaça menos pessoas" e "esperar mais tempo para possivelmente obter uma solução mais ideal", sendo que o método ideal poderia ser algum tipo de abordagem mista. Uma abordagem mista seria escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem seria implantar primeiro uma versão mais ambiciosa da abstração de contas na L2.
Como interage com as outras partes do roteiro?
A lista de inclusão precisa suportar transações de abstração de conta. Na prática, a demanda por listas de inclusão é muito semelhante à demanda por pools de memória descentralizados, embora haja um pouco mais de flexibilidade para as listas de inclusão. Além disso, a implementação de abstração de conta deve ser coordenada entre L1 e L2 sempre que possível. Se no futuro esperarmos que a maioria dos usuários utilize Rollup de armazenamento de chaves, o design da abstração de conta deve ser baseado nisso.
EIP-1559 melhoria
Que problema resolveu?
O EIP-1559 foi ativado na Ethereum em 2021, melhorando significativamente o tempo médio de inclusão de blocos.
No entanto, a implementação atual do EIP-1559 não é perfeita em vários aspetos:
A fórmula para blobs (EIP-4844) é projetada especificamente para resolver o primeiro problema, sendo no geral mais simples. No entanto, nem o EIP-1559 em si, nem o EIP-4844 tentaram resolver o segundo problema.
Além disso, existem outras fraquezas na precificação de recursos do Ethereum que não estão relacionadas com o EIP-1559, mas que podem ser resolvidas através de ajustes no EIP-1559. Um dos principais problemas é a diferença entre o caso médio e o pior caso: os preços dos recursos no Ethereum devem ser definidos para lidar com o pior caso, ou seja, o consumo total de gas de um bloco ocupa um recurso, mas o uso médio real está muito abaixo disso, levando à ineficiência.
O que é Gas multidimensional e como funciona?
A solução para esses problemas de ineficiência é o Gas multidimensional: definir preços e limites diferentes para diferentes recursos. Este conceito é tecnicamente independente do EIP-1559, mas a existência do EIP-1559 torna a implementação desta solução mais fácil. Sem o EIP-1559, a melhor forma de empacotar um bloco que contém restrições de vários recursos seria um complicado problema de mochila multidimensional. Com o EIP-1559, a maioria dos blocos não atinge a capacidade máxima em qualquer recurso, portanto, um algoritmo simples como "aceitar qualquer transação que pague taxas suficientes" é suficiente.
Atualmente, já temos Gas multidimensional para execução e blocos de dados; em princípio, podemos expandi-lo para mais dimensões: como calldata (dados de transação), leitura / escrita de estado e expansão do tamanho do estado.
A EIP-7706 introduz uma nova dimensão de gas, especificamente para calldata. Ao mesmo tempo, simplifica o mecanismo de gas multidimensional ao unificar três tipos de gas em uma única estrutura (estilo EIP-4844), resolvendo também as falhas matemáticas da EIP-1559. A EIP-7623 é uma solução mais precisa, que aborda os problemas de recursos nas situações médias e mais desfavoráveis, restringindo mais rigidamente o máximo de calldata, sem introduzir toda uma nova dimensão.
Links de pesquisa existentes