O futuro possível do protocolo Ethereum (seis): prosperidade
Algumas coisas são difíceis de classificar. No design do protocolo Ethereum, muitos "detalhes" são cruciais para o sucesso do Ethereum. Cerca de metade do conteúdo envolve diferentes tipos de melhorias no EVM, enquanto o restante é composto por vários 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 de taxas de transação, aumentar a escalabilidade enquanto reduz o risco
Explorar a 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 difícil criar implementações eficientes, validar formalmente o código e expandir ainda mais. Além disso, a eficiência da EVM é baixa, dificultando a implementação de muitos criptografias avançadas, a menos que haja suporte explícito através de pré-compilações.
O que é, como funciona?
O primeiro passo do roteiro de melhoria do EVM atual é o formato do objeto EVM (EOF), que está previsto para ser incluído na próxima divisão dura. EOF é uma série de EIPs, que especificam uma nova versão do código EVM, com muitas características únicas, a mais notável é:
O código ( é executável, mas não pode ser lido a partir da EVM. ) e os dados ( podem ser lidos, mas não podem ser executados ).
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-rotinas explícitas
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, e mesmo forçados a serem convertidos para o código EOF (. Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF — primeiramente através de um bytecode ligeiramente reduzido devido à característica de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou redução nos custos de gas.
Após a introdução do EOF, a atualização adicional tornou-se mais fácil, e 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 voltadas para a operação de módulo, colocando-as 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 SIMD (Single Instruction Multiple Data) ), sendo que a SIMD como um conceito do Ethereum já existe há muito tempo, tendo sido proposta pela primeira vez por Greg Colvin na EIP-616. A SIMD pode ser usada 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 a SIMD torna essas duas extensões orientadas para desempenho uma combinação natural.
Um design geral 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 com um máximo de 2768 como módulo
Para cada opcode EVM-MAX ( adição, subtração, multiplicação ), adicione 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, a função 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á 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. 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 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.
(# Trabalho restante e ponderações
Atualmente, o EOF está planejado para ser incluído na próxima bifurcação rígida. Embora sempre exista a possibilidade de removê-lo no último momento — em bifurcações rígidas anteriores, algumas funcionalidades foram removidas temporariamente, 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 consideração do EVM é a complexidade do L1 em relação à complexidade da infraestrutura. O EOF é uma quantidade significativa 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 o roteiro para a melhoria contínua do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante a ser feita é implementar funcionalidades semelhantes a 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 mapa?
A L1 ajusta seu EVM para que a L2 também possa realizar ajustes correspondentes mais facilmente. Se ambos não forem ajustados em sincronia, isso pode causar incompatibilidade e trazer efeitos adversos. Além disso, EVM-MAX e SIMD podem reduzir os custos de gas 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, as transações só podem ser validadas de uma forma: 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 habilitar 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 sua complexidade e eliminando um ponto crítico de dependência central.
Desde que a abstração de contas foi proposta em 2015, seu objetivo também se expandiu para incluir uma série de "objetivos de conveniência", como, por exemplo, uma conta que não possui ETH, mas tem alguns ERC20, podendo usar ERC20 para pagar o 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 múltiplos dispositivos, utilizando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
EIP-7702 é uma proposta planejada para ser introduzida no próximo hard fork. EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência de abstração de contas para beneficiar todos os usuários (, incluindo usuários de EOA ), com o objetivo de 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 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 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 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 está na implementação segura, que é um desafio.
(# O que é, como funciona?
O cerne da abstração de contas é simples: permitir 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 para a 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 uma função de verificação de 1000 contas que dependa de um único valor S, e o valor atual S faz com que todas as transações no pool de memória sejam 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, visando expandir funcionalidades ao mesmo tempo que limita o risco de negação de serviço )DoS###, finalmente foi alcançada 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: verificação e execução. Todas as verificações são processadas primeiro, e todas as execuções são processadas posteriormente. No pool de memórias, 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 falhas múltiplas. Além disso, limites de gás rigorosos são também aplicados à 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), e não tinham energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usa um objeto chamado operação de 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 ineficiência inerente do 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 contém as garantias que precisam ser transferidas para a conta de usuários abstratos.
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 estipula que na fase de validaçã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 funções 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 ponderações
Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas, que se tornou popular recentemente, é o EIP-7701, e esta proposta implementa a abstração de contas sobre o 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 na etapa de verificação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele demonstra claramente duas perspectivas equivalentes da abstração de conta local:
Incluir 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 - sem acesso a estado externo, e mesmo o limite de gás definido no início é tão baixo que se torna inválido para aplicações de resistência quântica ou proteção de privacidade - então a segurança deste método é muito clara: simplesmente substituir a verificação ECDSA pela execução de código EVM que requer um tempo semelhante.
No entanto, à medida que o tempo passa, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários e a resistência quântica são extremamente importantes. Para isso, precisamos encontrar maneiras mais flexíveis de abordar o risco de negação de serviço (DoS), sem exigir que os passos de verificação sejam extremamente simplificados.
A principal consideração parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" em vez de "esperar mais tempo
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.
18 Curtidas
Recompensa
18
5
Repostar
Compartilhar
Comentário
0/400
LonelyAnchorman
· 2h atrás
Quando é que esta coisa chamada EVM vai funcionar melhor...
Ver originalResponder0
GateUser-2fce706c
· 15h atrás
Aproveitando a oportunidade de melhoria do EVM para estabelecer um grande quadro... já previa esta direção de desenvolvimento.
Ver originalResponder0
PoetryOnChain
· 15h atrás
Está prestes a atingir o limite, o V神 finalmente percebeu.
Perspectivas futuras do protocolo Ethereum: melhorias no EVM e abstração de contas lideram a prosperidade
O futuro possível do protocolo Ethereum (seis): prosperidade
Algumas coisas são difíceis de classificar. No design do protocolo Ethereum, muitos "detalhes" são cruciais para o sucesso do Ethereum. Cerca de metade do conteúdo envolve diferentes tipos de melhorias no EVM, enquanto o restante é composto por vários 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 difícil criar implementações eficientes, validar formalmente o código e expandir ainda mais. Além disso, a eficiência da EVM é baixa, dificultando a implementação de muitos criptografias avançadas, a menos que haja suporte explícito através de pré-compilações.
O que é, como funciona?
O primeiro passo do roteiro de melhoria do EVM atual é o formato do objeto EVM (EOF), que está previsto para ser incluído na próxima divisão dura. EOF é uma série de EIPs, que especificam uma nova versão do código EVM, com muitas características únicas, a mais notável é:
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados, e mesmo forçados a serem convertidos para o código EOF (. Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF — primeiramente através de um bytecode ligeiramente reduzido devido à característica de sub-rotinas, e depois com novas funcionalidades específicas do EOF ou redução nos custos de gas.
Após a introdução do EOF, a atualização adicional tornou-se mais fácil, e 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 voltadas para a operação de módulo, colocando-as 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 SIMD (Single Instruction Multiple Data) ), sendo que a SIMD como um conceito do Ethereum já existe há muito tempo, tendo sido proposta pela primeira vez por Greg Colvin na EIP-616. A SIMD pode ser usada 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 a SIMD torna essas duas extensões orientadas para desempenho uma combinação natural.
Um design geral 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á tratado de forma paralela.
(# Trabalho restante e ponderações
Atualmente, o EOF está planejado para ser incluído na próxima bifurcação rígida. Embora sempre exista a possibilidade de removê-lo no último momento — em bifurcações rígidas anteriores, algumas funcionalidades foram removidas temporariamente, 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 consideração do EVM é a complexidade do L1 em relação à complexidade da infraestrutura. O EOF é uma quantidade significativa 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 o roteiro para a melhoria contínua do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante a ser feita é implementar funcionalidades semelhantes a 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 mapa?
A L1 ajusta seu EVM para que a L2 também possa realizar ajustes correspondentes mais facilmente. Se ambos não forem ajustados em sincronia, isso pode causar incompatibilidade e trazer efeitos adversos. Além disso, EVM-MAX e SIMD podem reduzir os custos de gas 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, as transações só podem ser validadas de uma forma: 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 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 crítico de dependência central.
Desde que a abstração de contas foi proposta em 2015, seu objetivo também se expandiu para incluir uma série de "objetivos de conveniência", como, por exemplo, uma conta que não possui ETH, mas tem alguns ERC20, podendo usar ERC20 para pagar o 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 múltiplos dispositivos, utilizando técnicas criptográficas para gerar assinaturas, sem a necessidade de combinar diretamente essas partes de chave.
EIP-7702 é uma proposta planejada para ser introduzida no próximo hard fork. EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência de abstração de contas para beneficiar todos os usuários (, incluindo usuários de EOA ), com o objetivo de 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 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 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 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 está na implementação segura, que é um desafio.
(# O que é, como funciona?
O cerne da abstração de contas é simples: permitir 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 para a 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 uma função de verificação de 1000 contas que dependa de um único valor S, e o valor atual S faz com que todas as transações no pool de memória sejam 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, visando expandir funcionalidades ao mesmo tempo que limita o risco de negação de serviço )DoS###, finalmente foi alcançada 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: verificação e execução. Todas as verificações são processadas primeiro, e todas as execuções são processadas posteriormente. No pool de memórias, 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 falhas múltiplas. Além disso, limites de gás rigorosos são também aplicados à 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), e não tinham energia extra para lidar com outras funcionalidades. É por isso que o ERC-4337 usa um objeto chamado operação de 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 ponderações
Atualmente, a principal questão a resolver é como introduzir completamente a abstração de contas no protocolo. O EIP de abstração de contas, que se tornou popular recentemente, é o EIP-7701, e esta proposta implementa a abstração de contas sobre o 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 na etapa de verificação das transações provenientes dessa conta.
O fascínio deste método reside no fato de que ele demonstra claramente duas perspectivas equivalentes da abstração de conta local:
Se começarmos a estabelecer limites rigorosos para a complexidade do código executável durante o período de validação - sem acesso a estado externo, e mesmo o limite de gás definido no início é tão baixo que se torna inválido para aplicações de resistência quântica ou proteção de privacidade - então a segurança deste método é muito clara: simplesmente substituir a verificação ECDSA pela execução de código EVM que requer um tempo semelhante.
No entanto, à medida que o tempo passa, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários e a resistência quântica são extremamente importantes. Para isso, precisamos encontrar maneiras mais flexíveis de abordar o risco de negação de serviço (DoS), sem exigir que os passos de verificação sejam extremamente simplificados.
A principal consideração parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" em vez de "esperar mais tempo