O futuro possível do protocolo Ethereum (seis): prosperidade
O design do protocolo Ethereum contém muitos "detalhes" que são cruciais para o seu sucesso. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias do EVM, e o restante é composto por vários tópicos de nicho, que é o que significa "complexidade".
Prosperidade: objetivo chave
Transformar a EVM em um "estado final" de alto desempenho e estabilidade
Introduzir a abstração de contas no protocolo, permitindo que todos os utilizadores desfrutem de contas mais seguras e convenientes.
Otimizar a economia das taxas de transação, aumentar a escalabilidade enquanto reduz os riscos
Explorar a criptografia avançada para melhorar significativamente o Ethereum a longo prazo
Melhoria do EVM
resolveu que problema?
Atualmente, a EVM é difícil de analisar estaticamente, o que torna difícil criar implementações eficientes, validar formalmente o código e realizar extensõ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 atual roteiro de melhorias do EVM é o formato de objeto EVM (EOF), que está planejado para ser incluído na próxima bifurcação dura. O 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 redirecionamento dinâmico, apenas redirecionamento estático permitido
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, mesmo podendo ser forçados a converter para código EOF (. Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro com bytecode ligeiramente reduzido através de características de sub-rotina, e posteriormente com novas funcionalidades específicas do EOF ou redução nos custos de gas.
Após a introdução do EOF, as atualizações subsequentes tornaram-se mais fáceis. O módulo EVM que se desenvolveu mais completamente é a extensão aritmética )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.
Uma ideia mais recente é combinar o EVM-MAX com a característica de múltiplos dados por 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 usado 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 para o desempenho um emparelhamento natural.
![Vitalik sobre o possível futuro do Ethereum (Seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
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 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 utiliza 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, o efeito desses opcodes é 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 módulos de potências de 2. 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 redes. 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 compensaçõ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 momento - em bifurcações 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 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 é 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 linguagens de alto nível, simplificar a implementação do EVM e outros benefícios. Pode-se dizer que a prioridade em melhorar continuamente o roteiro do Ethereum L1 deve incluir e construir 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 outras partes do roteiro?
A L1 ajusta seu EVM para que o L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não forem ajustados em sincronia, poderá haver incompatibilidade, o que trará efeitos adversos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente o custo de gas de muitos sistemas de prova, tornando o 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 muito a eficiência.
![Vitalik sobre o futuro possível do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
Abstração de Conta
) resolveu que problema?
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:
Mudar para criptografia quântica resistente
Rotacionar chaves antigas ### é amplamente considerado 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 central de dependência.
Desde que a abstração de contas foi proposta em 2015, seu objetivo também se expandiu para incluir um grande número de "objetivos de conveniência", por exemplo, uma conta que não possui ETH, mas possui 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 múltiplos dispositivos, aproveitando a tecnologia criptográfica para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
A EIP-7702 é uma proposta planejada para ser introduzida na próxima bifurcação dura. A 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 (, e visa melhorar a experiência de todos os usuários a curto prazo, evitando a divisão em dois ecossistemas.
Este trabalho começou com o EIP-3074 e acabou formando 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, ou seja, contas controladas por assinaturas ECDSA (.
Embora alguns desafios ), especialmente o desafio da "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, inicialmente apresentada, só pode ser alcançado revertendo e resolvendo o problema original: permitir que o código de contrato inteligente controle a validação de transações. A razão pela qual isso ainda não foi realizado é a implementação segura, o que é um desafio.
![Vitalik sobre o futuro possível do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) O que é e 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 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 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 invalidar todas as outras transações no pool de memória. 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 (, chegou-se finalmente à solução para realizar a "abstração ideal de conta": ERC-4337.
O funcionamento do ERC-4337 consiste em dividir o processamento das operações dos usuários 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 dos usuários 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, um limite rigoroso de gas também é imposto na 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(, não tendo 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-chave são as seguintes:
A ineficiência inerente do EntryPoint como 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 garantias criadas precisa ser transferida para a conta de usuários abstratos.
![Vitalik sobre o possível futuro do Ethereum (VI): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Além disso, o ERC-4337 também expandiu duas funcionalidades:
Agentes de pagamento ) Paymasters (: permite que uma conta represente outra conta no pagamento de taxas, o que viola a regra de que a fase de verificação só pode acessar a conta do remetente, portanto, foi introduzido um tratamento especial para garantir a segurança do mecanismo de agentes 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.
( link de pesquisa existente
Palestra sobre a história da abstração de contas:
ERC-4337:
EIP-7702:
O código BLSWallet ) utiliza a funcionalidade de agregação ###:
EIP-7562( escrever conta de abstração do protocolo ):
EIP-7701( conta abstrata de protocolo de escrita baseada em EOF ):
( Trabalho restante e considerações
Atualmente, a principal questão que precisa ser resolvida é 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 parte de código separada para validação; se a conta definir essa parte de código, ela será executada durante o passo de validaçã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.
17 Curtidas
Recompensa
17
5
Repostar
Compartilhar
Comentário
0/400
GweiTooHigh
· 08-12 00:28
A abstração de contas realmente pode se popularizar?
Ver originalResponder0
MEVictim
· 08-10 08:39
É só essa coisa do EVM, sem graça.
Ver originalResponder0
BlockchainDecoder
· 08-10 08:39
Citando dados do artigo RV2022, a eficiência da pilha da arquitetura EVM existente é de apenas 42%, necessitando realmente de otimização.
Ver originalResponder0
PessimisticOracle
· 08-10 08:39
Falaram tanto e ainda estão a sonhar? Se realmente conseguirem, então perdi.
Perspectivas futuras do Ethereum: a atualização do EVM e a abstração de contas lideram uma nova fase de prosperidade
O futuro possível do protocolo Ethereum (seis): prosperidade
O design do protocolo Ethereum contém muitos "detalhes" que são cruciais para o seu sucesso. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias do EVM, e o restante é composto por vários tópicos de nicho, que é o que significa "complexidade".
Prosperidade: objetivo chave
Melhoria do EVM
resolveu que problema?
Atualmente, a EVM é difícil de analisar estaticamente, o que torna difícil criar implementações eficientes, validar formalmente o código e realizar extensõ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 atual roteiro de melhorias do EVM é o formato de objeto EVM (EOF), que está planejado para ser incluído na próxima bifurcação dura. O 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, mesmo podendo ser forçados a converter para código EOF (. Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF - primeiro com bytecode ligeiramente reduzido através de características de sub-rotina, e posteriormente com novas funcionalidades específicas do EOF ou redução nos custos de gas.
Após a introdução do EOF, as atualizações subsequentes tornaram-se mais fáceis. O módulo EVM que se desenvolveu mais completamente é a extensão aritmética )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.
Uma ideia mais recente é combinar o EVM-MAX com a característica de múltiplos dados por 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 usado 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 para o desempenho um emparelhamento natural.
![Vitalik sobre o possível futuro do Ethereum (Seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
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 prática, isso será processado de forma paralela.
) Link de pesquisa existente
trabalho restante e compensaçõ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 momento - em bifurcações 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 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 é 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 linguagens de alto nível, simplificar a implementação do EVM e outros benefícios. Pode-se dizer que a prioridade em melhorar continuamente o roteiro do Ethereum L1 deve incluir e construir 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 outras partes do roteiro?
A L1 ajusta seu EVM para que o L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não forem ajustados em sincronia, poderá haver incompatibilidade, o que trará efeitos adversos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente o custo de gas de muitos sistemas de prova, tornando o 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 muito a eficiência.
![Vitalik sobre o futuro possível do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
Abstração de Conta
) resolveu que problema?
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 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 um grande número de "objetivos de conveniência", por exemplo, uma conta que não possui ETH, mas possui 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 múltiplos dispositivos, aproveitando a tecnologia criptográfica para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
A EIP-7702 é uma proposta planejada para ser introduzida na próxima bifurcação dura. A 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 (, e visa melhorar a experiência de todos os usuários a curto prazo, evitando a divisão em dois ecossistemas.
Este trabalho começou com o EIP-3074 e acabou formando 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, ou seja, contas controladas por assinaturas ECDSA (.
Embora alguns desafios ), especialmente o desafio da "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, inicialmente apresentada, só pode ser alcançado revertendo e resolvendo o problema original: permitir que o código de contrato inteligente controle a validação de transações. A razão pela qual isso ainda não foi realizado é a implementação segura, o que é um desafio.
![Vitalik sobre o futuro possível do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) O que é e 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 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 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 invalidar todas as outras transações no pool de memória. 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 (, chegou-se finalmente à solução para realizar a "abstração ideal de conta": ERC-4337.
O funcionamento do ERC-4337 consiste em dividir o processamento das operações dos usuários 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 dos usuários 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, um limite rigoroso de gas também é imposto na 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(, não tendo 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-chave são as seguintes:
![Vitalik sobre o possível futuro do Ethereum (VI): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Além disso, o ERC-4337 também expandiu duas funcionalidades:
( link de pesquisa existente
( Trabalho restante e considerações
Atualmente, a principal questão que precisa ser resolvida é 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 parte de código separada para validação; se a conta definir essa parte de código, ela será executada durante o passo de validação das transações provenientes dessa conta.
Este método é fascinante