O futuro possível do protocolo Ethereum (VI): prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais 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, que é o que significa "繁荢".
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, permitindo que o Ethereum melhore significativamente a longo prazo
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 de objeto EVM (EOF), que está planejado para ser incluído no próximo hard fork. 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:
O código ( pode ser executado, mas não é possível ler ) do EVM e os dados ( podem ser lidos, mas não podem ser executados entre a separação de ).
Proibido saltos dinâmicos, apenas saltos estáticos permitidos
O código EVM não pode mais observar informações relacionadas ao combustível
Adicionada uma nova mecânica de sub-rotina explícita
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, e os contratos antigos ( poderão até ser forçados a serem convertidos em código EOF ). Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro, através de um bytecode ligeiramente reduzido com a característica de sub-rotinas, 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. 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 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, 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 ú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 muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em rede, e a combinação do EVM-MAX com SIMD torna essas duas expansões orientadas para o desempenho uma combinação natural.
Um design aproximado de um EIP combinado começará com o EIP-6690 e, em seguida:
Permitir (i) qualquer número ímpar ou (ii) qualquer potência de 2 que não exceda 2768 como módulo
Para cada opcode EVM-MAX ( adição, subtração, multiplicação ), adicione uma versão que não utilize 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 uma função semelhante 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 prática, isso será processado de forma paralela.
Pode adicionar XOR, AND, OR, NOT e SHIFT( incluindo ciclos e não ciclos), pelo menos para potências de 2 como módulo. Ao mesmo tempo, adicionar ISZERO( irá empurrar a saída para a pilha principal do EVM), o que será suficientemente poderoso para implementar criptografia de curva elíptica, criptografia de pequeno domínio( como Poseidon, Circle STARKs), funções de hash tradicionais( como SHA256, KECCAK, BLAKE) e criptografia baseada em grades. Outras atualizações do EVM também podem ser implementadas, mas até agora têm recebido menos atenção.
Link de pesquisa existente
EOF:
EVM-MAX:
SIMD:
Trabalho restante e ponderações
Atualmente, o EOF está planejado para ser incluído na próxima bifurcação dura. Embora sempre seja possível removê-lo no último minuto - funcionalidades foram temporariamente removidas em bifurcações duras anteriores, fazer isso enfrentará grandes desafios. Remover o EOF significa que quaisquer atualizações futuras ao EVM terão que ser feitas sem o EOF, embora seja possível, pode ser mais difícil.
O principal compromisso do EVM reside na complexidade do L1 e na 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á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 para a melhoria contínua do Ethereum L1 deve incluir e ser construída sobre o EOF.
Uma tarefa importante a ser feita é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark para 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 realizar ajustes correspondentes mais facilmente. Se ambos não realizarem ajustes sincronizados, isso pode causar incompatibilidade e trazer impactos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir os custos de gás 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.
abstração de conta
Que problema foi resolvido?
Atualmente, a transação só pode ser verificada de uma maneira: assinatura ECDSA. Inicialmente, a abstração de conta foi projetada para ir além disso, permitindo que a lógica de verificação da conta seja qualquer código EVM. Isso pode habilitar uma série de aplicativos:
Mudar para criptografia quântica resistente
Rotacionar a chave antiga ( é amplamente considerado uma prática de segurança recomendada )
Carteira multi-assinatura 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 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 que tem alguns ERC20, podendo usar ERC20 para pagar o gás.
MPC( computação multipartidária ) é uma tecnologia com 40 anos de história, usada 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.
A EIP-7702 é uma proposta que está prevista para ser introduzida no próximo hard fork. A EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência de fornecer abstração de conta para beneficiar todos os usuários (, incluindo usuários EOA ), e visa melhorar a experiência de todos os usuários a curto prazo, além de evitar a divisão em dois ecossistemas.
O trabalho começou com o EIP-3074 e acabou formando 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 de propriedade (EOA) ( de hoje, ou seja, contas controladas por assinaturas ECDSA ).
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 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 de transações. A razão pela qual isso ainda não foi realizado é a 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 à manutenção de uma rede descentralizada e que previna ataques de negação de serviço.
Um desafio chave típico é o problema da falha múltipla:
Se houver 1000 funções de verificaçã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 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ços, visando expandir as funcionalidades enquanto limita os riscos de negação de serviço (DoS), foi finalmente encontrada 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 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 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.
As 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 do usuário.
Garantir a necessidade das propriedades do Ethereum: como a lista de inclusão criada para garantir que precisa ser transferida para a conta de usuários abstratos.
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 apenas a conta do remetente pode ser acessada na fase de validação, portanto, um tratamento especial foi introduzido para garantir a segurança do mecanismo de agente de pagamento.
Agregadores(: Suporta funcionalidades 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.
![Vitalik sobre o possível futuro do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Link de pesquisa existente
Discurso sobre a história da abstração de contas:
ERC-4337:
EIP-7702:
O código BLSWallet ### usa a funcionalidade de agregação (:
EIP-7562) escrita no protocolo de abstração de contas (:
EIP-7701) protocolo de escrita baseado em EOF conta abstrata (:
)# Trabalho restante e ponderações
Atualmente, a principal necessidade é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que se tornou 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 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.
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.
9 Curtidas
Recompensa
9
5
Compartilhar
Comentário
0/400
SignatureAnxiety
· 6h atrás
Este gás que economizei dá para comprar o que?
Ver originalResponder0
BlockchainRetirementHome
· 08-02 07:21
Finalmente chegou a atualização da versão EVM da Lenda Dourada
Ver originalResponder0
Web3ExplorerLin
· 08-02 07:20
hipótese: evm é como um computador antigo em busca da sua forma final... fascinante como espelha a evolução da consciência humana, para ser sincero
Ver originalResponder0
WenAirdrop
· 08-02 07:09
Não brinque, as taxas de gás continuam caras até vomitar, está bem?
Ver originalResponder0
MEVictim
· 08-02 07:08
Quanto tempo mais pode demorar a reforma das taxas... Não compliquem o EVM.
Éter EVM atualização e abstração de contas: construir uma infraestrutura de Blockchain mais eficiente e segura
O futuro possível do protocolo Ethereum (VI): prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais 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, que é o que significa "繁荢".
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 de objeto EVM (EOF), que está planejado para ser incluído no próximo hard fork. 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 poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, e os contratos antigos ( poderão até ser forçados a serem convertidos em código EOF ). Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro, através de um bytecode ligeiramente reduzido com a característica de sub-rotinas, 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. 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 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, 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 ú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 muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em rede, e a combinação do EVM-MAX com SIMD torna essas duas expansões orientadas para o desempenho uma combinação natural.
Um design aproximado 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 prática, isso será processado de forma paralela.
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 seja possível removê-lo no último minuto - funcionalidades foram temporariamente removidas em bifurcações duras anteriores, fazer isso enfrentará grandes desafios. Remover o EOF significa que quaisquer atualizações futuras ao EVM terão que ser feitas sem o EOF, embora seja possível, pode ser mais difícil.
O principal compromisso do EVM reside na complexidade do L1 e na 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á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 para a melhoria contínua do Ethereum L1 deve incluir e ser construída sobre o EOF.
Uma tarefa importante a ser feita é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark para 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 realizar ajustes correspondentes mais facilmente. Se ambos não realizarem ajustes sincronizados, isso pode causar incompatibilidade e trazer impactos negativos. Além disso, o EVM-MAX e o SIMD podem reduzir os custos de gás 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.
abstração de conta
Que problema foi resolvido?
Atualmente, a transação só pode ser verificada de uma maneira: assinatura ECDSA. Inicialmente, a abstração de conta foi projetada para ir além disso, permitindo que a lógica de verificação da conta seja qualquer código EVM. Isso pode habilitar uma série de aplicativos:
Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente a 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 que tem alguns ERC20, podendo usar ERC20 para pagar o gás.
MPC( computação multipartidária ) é uma tecnologia com 40 anos de história, usada 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.
A EIP-7702 é uma proposta que está prevista para ser introduzida no próximo hard fork. A EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência de fornecer abstração de conta para beneficiar todos os usuários (, incluindo usuários EOA ), e visa melhorar a experiência de todos os usuários a curto prazo, além de evitar a divisão em dois ecossistemas.
O trabalho começou com o EIP-3074 e acabou formando 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 de propriedade (EOA) ( de hoje, ou seja, contas controladas por assinaturas ECDSA ).
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 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 de transações. A razão pela qual isso ainda não foi realizado é a 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 à manutenção de uma rede descentralizada e que previna ataques de negação de serviço.
Um desafio chave típico é o problema da falha múltipla:
Se houver 1000 funções de verificaçã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 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ços, visando expandir as funcionalidades enquanto limita os riscos de negação de serviço (DoS), foi finalmente encontrada 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 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 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.
As 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 (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Link de pesquisa existente
)# Trabalho restante e ponderações
Atualmente, a principal necessidade é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que se tornou 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 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.
Este tipo