O futuro do protocolo Ethereum ( seis ): prosperidade
Escrito por: Vitalik Buterin
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 da EVM, enquanto o restante consiste em vários tópicos 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 de taxas de transação, melhorar a escalabilidade e ao mesmo tempo reduzir o risco
Explorar criptografia avançada, permitindo que o Ethereum melhore significativamente a longo prazo
melhoria do EVM
Que problema foi resolvido?
Atualmente, o 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 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 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. 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 podem ser executados 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
Adicionou um novo mecanismo de rotina explícita de subexemplo
Prosperidade: Melhoria EVM ( continuação )
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados os contratos antigos ( e até mesmo forçados a serem convertidos para código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF------primeiro pela redução ligeira do bytecode através de características de sub-rotina, e depois pelas novas funcionalidades específicas do EOF ou custos de gas reduzidos.
Após a introdução do EOF, as 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 inacessível 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, 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 de hash, STARKs de 32 bits e criptografia baseada em redes, 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 depois:
Permitir (i) qualquer ímpar ou (ii) qualquer potência de 2 até 2768 como módulo
Para cada opcode EVM-MAX ( adição, subtração, multiplicação ), adicione uma versão que não utiliza 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, o efeito desses opcodes é semelhante a:
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á tratado 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 EVM), o que será suficientemente poderoso 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 EVM também podem ser implementadas, mas até agora têm recebido menos atenção.
Trabalho restante e trade-offs
Atualmente, o EOF está planejado para ser incluído no próximo hard fork. Embora sempre haja a possibilidade de removê-lo no último momento ------ em 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 isso 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 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 realizar é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark sobre o consumo de gas das 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 realizar ajustes correspondentes com mais facilidade. Se ambos não forem ajustados em sincronia, isso pode causar incompatibilidades e trazer 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 torna mais fácil substituir mais pré-compilações por código EVM que pode executar as mesmas tarefas, o que pode não impactar significativamente a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, a transação só pode ser verificada de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta 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 a chave antiga ( é 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 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 convenientes", por exemplo, uma conta que não possui ETH, mas tem alguns ERC20, pode usar ERC20 para pagar 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 que está prevista para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência da abstração de contas para beneficiar todos os usuários (, incluindo usuários de 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 culminou no EIP-7702. O EIP-7702 oferece a "funcionalidade de conveniência" da abstração de conta a todos os usuários, incluindo as contas externas EOA( de hoje, que são contas controladas por assinaturas ECDSA ).
A partir do gráfico, pode-se ver que, 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 originalmente apresentada só pode ser alcançado retrocedendo 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 alcançado se deve à 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 maneira que seja amigável à manutenção de redes descentralizadas e prevenir ataques de negação de serviço.
Um desafio crítico típico é o problema da múltipla falha:
Se houver 1000 funções de validação de contas que dependem de um único valor S, e o valor atual S faz com que todas as transações no pool de memórias sejam 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órias se tornem inválidas. Isso permite que um atacante envie transações de lixo para o pool de memórias 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 ), chegou-se finalmente a uma solução para realizar a "abstração ideal da 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, limites de gas rigorosos também são impostos 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), 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:
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 incluída que foi criada para incluir garantias que precisam ser transferidas para os usuários de contas abstratas.
Além disso, o ERC-4337 também expandiu duas funcionalidades:
Agentes de pagamento ( Paymasters ): permite que uma conta pague taxas em nome de outra conta, o que viola a regra que permite acesso apenas à conta do remetente durante a fase de verificação, portanto, foi introduzido um tratamento especial 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.
![Vitalik sobre o futuro possível do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Trabalho restante e trade-offs
Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas mais 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 definir essa parte de código, ela será executada no passo de verificação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Incluir 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 a estabelecer limites rigorosos para a complexidade do código executável durante o período de validação ------ não permitindo acesso a estados externos, mesmo com o limite de gás inicialmente definido tão baixo que se torna ineficaz para aplicações de resistência quântica ou proteção de privacidade ------ então a segurança desse método é muito clara: apenas substituindo a validação ECDSA pela execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir aplicações de proteção de privacidade sem a mediação
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
6
Compartilhar
Comentário
0/400
LuckyBlindCat
· 07-20 01:39
Vitalik Buterin finalmente não conseguiu ficar parado.
O futuro do protocolo Ethereum: novas oportunidades trazidas pela atualização do EVM e pela abstração de contas
O futuro do protocolo Ethereum ( seis ): prosperidade
Escrito por: Vitalik Buterin
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 da EVM, enquanto o restante consiste em vários tópicos de nicho, e é isso que significa "prosperidade".
Prosperidade: Objetivo-chave
melhoria do EVM
Que problema foi resolvido?
Atualmente, o 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 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 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. 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:
Prosperidade: Melhoria EVM ( continuação )
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados os contratos antigos ( e até mesmo forçados a serem convertidos para código EOF ). Os novos contratos beneficiarão das melhorias de eficiência trazidas pelo EOF------primeiro pela redução ligeira do bytecode através de características de sub-rotina, e depois pelas novas funcionalidades específicas do EOF ou custos de gas reduzidos.
Após a introdução do EOF, as 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 inacessível 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, 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 de hash, STARKs de 32 bits e criptografia baseada em redes, 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 depois:
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á tratado de forma paralela.
Trabalho restante e trade-offs
Atualmente, o EOF está planejado para ser incluído no próximo hard fork. Embora sempre haja a possibilidade de removê-lo no último momento ------ em 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 isso 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 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 realizar é implementar funcionalidades semelhantes ao EVM-MAX com SIMD e realizar testes de benchmark sobre o consumo de gas das 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 realizar ajustes correspondentes com mais facilidade. Se ambos não forem ajustados em sincronia, isso pode causar incompatibilidades e trazer 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 torna mais fácil substituir mais pré-compilações por código EVM que pode executar as mesmas tarefas, o que pode não impactar significativamente a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, a transação só pode ser verificada de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta 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 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 convenientes", por exemplo, uma conta que não possui ETH, mas tem alguns ERC20, pode usar ERC20 para pagar 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 que está prevista para ser introduzida no próximo hard fork. O EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência da abstração de contas para beneficiar todos os usuários (, incluindo usuários de 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 culminou no EIP-7702. O EIP-7702 oferece a "funcionalidade de conveniência" da abstração de conta a todos os usuários, incluindo as contas externas EOA( de hoje, que são contas controladas por assinaturas ECDSA ).
A partir do gráfico, pode-se ver que, 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 originalmente apresentada só pode ser alcançado retrocedendo 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 alcançado se deve à 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 maneira que seja amigável à manutenção de redes descentralizadas e prevenir ataques de negação de serviço.
Um desafio crítico típico é o problema da múltipla falha:
Se houver 1000 funções de validação de contas que dependem de um único valor S, e o valor atual S faz com que todas as transações no pool de memórias sejam 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órias se tornem inválidas. Isso permite que um atacante envie transações de lixo para o pool de memórias 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 ), chegou-se finalmente a uma solução para realizar a "abstração ideal da 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, limites de gas rigorosos também são impostos 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), 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:
![Vitalik sobre o futuro possível do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Trabalho restante e trade-offs
Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas mais 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 definir essa parte de código, ela será executada no passo de verificação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele indica claramente duas perspectivas equivalentes da abstração de contas locais:
Se começarmos a estabelecer limites rigorosos para a complexidade do código executável durante o período de validação ------ não permitindo acesso a estados externos, mesmo com o limite de gás inicialmente definido tão baixo que se torna ineficaz para aplicações de resistência quântica ou proteção de privacidade ------ então a segurança desse método é muito clara: apenas substituindo a validação ECDSA pela execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir aplicações de proteção de privacidade sem a mediação