O futuro possível do protocolo Ethereum ( seis ): prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais para seu sucesso. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias EVM, enquanto o restante é composto por uma variedade de temas de nicho, e é isso que significa "prosperidade".
Prosperidade: Objetivo Chave
Transformar o EVM em um "estado final" de alto desempenho e estabilidade
Introduzir a abstração de contas no protocolo, permitindo que todos os usuários desfrutem de contas mais seguras e convenientes.
Otimizar a economia das taxas de transação, aumentar a escalabilidade enquanto reduz o risco
Explorar criptografia avançada, para melhorar significativamente o Ethereum a longo prazo
Melhoria do EVM
Que problema foi resolvido?
Atualmente, a EVM é difícil de analisar estaticamente, o que torna a criação de implementações eficientes, a verificação formal de código e a expansão adicional difíceis. 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 por meio de pré-compilações.
O que é, como funciona?
O primeiro passo no roteiro de melhoria do EVM atual é o formato de objeto EVM (EOF), 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:
O código ( é executável, mas não é possível ler ) do EVM e os dados ( podem ser lidos, mas não é possível executar ) entre a separação.
Proibido saltos dinâmicos, apenas saltos estáticos permitidos
O código EVM não pode mais observar informações relacionadas ao combustível
Adicionou um novo mecanismo de sub-rotina explícita
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, e até mesmo forçados a serem convertidos para código EOF (. Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro com um bytecode ligeiramente reduzido através de características de sub-rotina, e depois 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 atualmente é a extensão aritmética do módulo EVM ) EVM-MAX (. O EVM-MAX criou um conjunto de novas operações especificamente para operações de módulo e as colocou 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.
![Vitalik sobre o possível futuro do Ethereum (VI): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Uma ideia mais recente é combinar o EVM-MAX com a característica de Múltiplos Dados de Instrução Única )SIMD(, sendo o SIMD uma filosofia do Ethereum que já existe há muito tempo, proposta pela primeira vez por Greg Colvin no EIP-616. O SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em grade, e a combinação do EVM-MAX com o SIMD torna essas duas expansões orientadas para o desempenho uma combinação natural.
Um design geral de um EIP combinado começará com o EIP-6690 e depois:
Permitir )i( qualquer número ímpar ou )ii( qualquer potência de 2 até 2768 como módulo
Para cada opcode EVM-MAX ) adição, subtração, multiplicação (, adicionar uma versão que não usa mais 3 constantes imediatas x, y, z, mas sim 7 constantes imediatas: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. No código Python, esses opcodes têm funções semelhantes a:
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.
Poderia adicionar XOR, AND, OR, NOT e SHIFT) incluindo ciclos e não ciclos(, pelo menos para potências de 2 módulo. Ao mesmo tempo, adicionar ISZERO) empurrará a saída para a pilha principal do EVM(, que será suficientemente poderosa para implementar criptografia de curva elíptica, criptografia de pequeno domínio) como Poseidon, Circle STARKs(, funções hash tradicionais) como SHA256, KECCAK, BLAKE( e criptografia baseada em redes. Outras atualizações do EVM também podem ser implementadas, mas até agora tiveram menos atenção.
)# Trabalho restante e considerações
Atualmente, o EOF está planejado para ser incluído na próxima hard fork. Embora sempre seja possível removê-lo no último minuto — em hard forks anteriores, algumas funcionalidades foram temporariamente removidas, mas fazê-lo 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.
O principal compromisso do EVM está na complexidade do L1 e na 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 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 gas de várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta o seu EVM para que o L2 também possa realizar ajustes correspondentes de forma mais fácil. Se ambos não forem ajustados em sincronia, pode resultar em incompatibilidade e causar efeitos adversos. 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é-compilados 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 (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) abstração de contas
Que problema foi resolvido?
Atualmente, as transações podem ser validadas apenas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de contas visava ir além disso, permitindo que a lógica de validação da conta fosse qualquer código EVM. Isso pode permitir uma série de aplicações:
Mudar para criptografia quântica resistente
A rotação de chaves antigas ### é amplamente considerada uma prática de segurança recomendada (
Carteira de múltiplas assinaturas e carteira de recuperação social
Usar uma chave para operações de baixo valor, usar outra chave ) ou um conjunto de chaves ( para operações de alto valor
Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente a sua complexidade e eliminando um ponto de dependência central crítico.
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 alguns ERC20 podendo usar ERC20 para pagar o gás.
MPC) cálculo 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, utilizando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes da chave.
EIP-7702 é uma proposta planejada para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de um reconhecimento crescente da conveniência da abstração de contas para beneficiar todos os usuários ), incluindo usuários EOA (, visando 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 disponibiliza a "funcionalidade conveniente" da abstração de contas a todos os utilizadores, incluindo as contas externas EOA) de hoje, que são contas controladas por assinaturas ECDSA(.
Embora alguns desafios ), especialmente o desafio da "conveniência" (, possam ser resolvidos por tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas inicialmente apresentada só pode ser alcançado revertendo 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, o que é um desafio.
![Vitalik sobre o futuro possível do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
)# 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 à manutenção de uma rede descentralizada e que previna ataques de negação de serviço.
Um desafio chave 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 S atual 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 indesejadas 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 realizar a "abstração ideal da conta": 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, as operações do usuário só serão aceitas quando 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 rígidos de gas 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 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 principais são as seguintes:
EntryPoint como a ineficiência inerente ao contrato: cada pacote tem um custo fixo de cerca de 100.000 gas, além de milhares de gas adicionais para cada operação de usuário.
Garantir a necessidade das propriedades do Ethereum: como a lista criada inclui garantias que precisam ser transferidas para a conta do usuário abstrato.
Além disso, o ERC-4337 também expandiu duas funcionalidades:
Agente de pagamento ) Paymasters (: permite que uma conta pague taxas em nome de outra conta, o que viola a regra de que na fase de verificação só se pode aceder à conta do remetente, portanto, foram introduzidos tratamentos especiais para garantir a segurança do mecanismo de agentes de pagamento.
Agregadores): Suporta a funcionalidade de agregação de assinaturas, como agregação BLS ou agregação baseada em SNARK. Isso é necessário para alcançar a máxima eficiência de dados em Rollup.
(# Trabalho restante e considerações
Atualmente, o que precisa ser resolvido é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem sido popular recentemente é o EIP-7701, que implementa a abstração de contas acima do EOF. Uma conta pode ter uma parte de código separada para validação; se a conta configurar essa parte de código, esse código será executado na etapa de validação das transações provenientes dessa conta.
A parte fascinante deste método é que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Integrar o EIP-4337 como parte do protocolo
Um novo tipo de EOA, onde o algoritmo de assinatura é a execução de código EVM
Se começarmos por estabelecer limites rigorosos para a complexidade do código executável durante a validação - não permitindo o acesso a estados externos, e mesmo os limites de gas estabelecidos inicialmente sendo tão baixos que se tornam inválidos para aplicações de resistência quântica ou proteção de privacidade - então a segurança desse método é muito clara: simplesmente substituindo 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, é extremamente importante. 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 simples.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
8 Curtidas
Recompensa
8
8
Compartilhar
Comentário
0/400
StakeOrRegret
· 07-08 09:26
evm está a bombear, mais cedo ou mais tarde será derrubado
Ver originalResponder0
LiquidityOracle
· 07-08 00:32
quando será concluída a atualização do evm?
Ver originalResponder0
AlphaLeaker
· 07-07 10:28
Muito bem, vai haver uma redução no gás!
Ver originalResponder0
ChainChef
· 07-07 10:23
parece que o eth está a preparar algumas atualizações de protocolo saborosas... essa otimização do evm é o molho secreto que temos estado à espera para ser sincero
Ver originalResponder0
DisillusiionOracle
· 07-07 10:16
o evm é assim mesmo. Se fosse realmente tão bom, já teria sido alterado.
Ver originalResponder0
Web3Educator
· 07-07 10:15
*ajusta os óculos* hmmm... o evm precisa de um upgrade sério fr fr
Ver originalResponder0
DeFiVeteran
· 07-07 10:12
Hmm? Isso também pode ser chamado de prosperidade?
Perspectivas futuras do protocolo Ethereum: otimização da EVM e abstração de contas liderando a prosperidade
O futuro possível do protocolo Ethereum ( seis ): prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais para seu sucesso. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias EVM, enquanto o restante é composto por uma variedade de temas de nicho, e é isso que significa "prosperidade".
Prosperidade: Objetivo Chave
Melhoria do EVM
Que problema foi resolvido?
Atualmente, a EVM é difícil de analisar estaticamente, o que torna a criação de implementações eficientes, a verificação formal de código e a expansão adicional difíceis. 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 por meio de pré-compilações.
O que é, como funciona?
O primeiro passo no roteiro de melhoria do EVM atual é o formato de objeto EVM (EOF), 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, e até mesmo forçados a serem convertidos para código EOF (. Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro com um bytecode ligeiramente reduzido através de características de sub-rotina, e depois 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 atualmente é a extensão aritmética do módulo EVM ) EVM-MAX (. O EVM-MAX criou um conjunto de novas operações especificamente para operações de módulo e as colocou 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.
![Vitalik sobre o possível futuro do Ethereum (VI): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Uma ideia mais recente é combinar o EVM-MAX com a característica de Múltiplos Dados de Instrução Única )SIMD(, sendo o SIMD uma filosofia do Ethereum que já existe há muito tempo, proposta pela primeira vez por Greg Colvin no EIP-616. O SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em grade, e a combinação do EVM-MAX com o SIMD torna essas duas expansões orientadas para o desempenho uma combinação natural.
Um design geral de um EIP combinado começará com o EIP-6690 e depois:
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.
)# Trabalho restante e considerações
Atualmente, o EOF está planejado para ser incluído na próxima hard fork. Embora sempre seja possível removê-lo no último minuto — em hard forks anteriores, algumas funcionalidades foram temporariamente removidas, mas fazê-lo 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.
O principal compromisso do EVM está na complexidade do L1 e na 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 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 gas de várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta o seu EVM para que o L2 também possa realizar ajustes correspondentes de forma mais fácil. Se ambos não forem ajustados em sincronia, pode resultar em incompatibilidade e causar efeitos adversos. 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é-compilados 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 (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) abstração de contas
Que problema foi resolvido?
Atualmente, as transações podem ser validadas apenas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de contas visava ir além disso, permitindo que a lógica de validação da conta fosse qualquer código EVM. Isso pode permitir uma série de aplicações:
Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente a sua complexidade e eliminando um ponto de dependência central crítico.
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 alguns ERC20 podendo usar ERC20 para pagar o gás.
MPC) cálculo 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, utilizando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes da chave.
EIP-7702 é uma proposta planejada para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de um reconhecimento crescente da conveniência da abstração de contas para beneficiar todos os usuários ), incluindo usuários EOA (, visando 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 disponibiliza a "funcionalidade conveniente" da abstração de contas a todos os utilizadores, incluindo as contas externas EOA) de hoje, que são contas controladas por assinaturas ECDSA(.
Embora alguns desafios ), especialmente o desafio da "conveniência" (, possam ser resolvidos por tecnologias progressivas como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas inicialmente apresentada só pode ser alcançado revertendo 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, o que é um desafio.
![Vitalik sobre o futuro possível do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
)# 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 à manutenção de uma rede descentralizada e que previna ataques de negação de serviço.
Um desafio chave 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 S atual 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 indesejadas 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 realizar a "abstração ideal da conta": 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, as operações do usuário só serão aceitas quando 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 rígidos de gas 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 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 principais são as seguintes:
Além disso, o ERC-4337 também expandiu duas funcionalidades:
(# Trabalho restante e considerações
Atualmente, o que precisa ser resolvido é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem sido popular recentemente é o EIP-7701, que implementa a abstração de contas acima do EOF. Uma conta pode ter uma parte de código separada para validação; se a conta configurar essa parte de código, esse código será executado na etapa de validação das transações provenientes dessa conta.
A parte fascinante deste método é que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Se começarmos por estabelecer limites rigorosos para a complexidade do código executável durante a validação - não permitindo o acesso a estados externos, e mesmo os limites de gas estabelecidos inicialmente sendo tão baixos que se tornam inválidos para aplicações de resistência quântica ou proteção de privacidade - então a segurança desse método é muito clara: simplesmente substituindo 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, é extremamente importante. 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 simples.