O futuro possível do protocolo Ethereum(seis): prosperidade
Na design do protocolo Ethereum, há muitos "detalhes" que são muito importantes para o sucesso do Ethereum. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias do EVM, enquanto o resto é composto por vários tópicos de nicho, que é o que significa "complexidade".
Prosperidade: Objetivo chave
Transformar o EVM em um "estado final" de alto desempenho e estabilidade
Introduzir a abstração de contas no protocolo, permitindo a todos os usuários desfrutar de contas mais seguras e convenientes.
Otimizar a economia das 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, 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 é, como funciona?
O primeiro passo no roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), que está previsto 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 ( pode ser executado, mas não é possível ler ) a partir do EVM e os dados ( podem ser lidos, mas não podem ser executados entre a separação de ).
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 sub-rotina explícita
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 contratos novos beneficiarão do aumento de eficiência trazido pelo EOF — primeiro com bytecode ligeiramente reduzido por meio da 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, sendo o módulo de cálculo EVM a evolução mais desenvolvida até o momento (EVM-MAX). O EVM-MAX criou um conjunto de novas operações especificamente para a operação 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 de uma única instrução (SIMD), o SIMD, como um conceito do Ethereum, já existe há muito tempo, sendo inicialmente proposto 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 SIMD torna essa dupla orientada para o desempenho uma combinação natural.
Um design aproximado de uma combinação de EIP começará com o EIP-6690 e depois:
Permitir (i) qualquer número ímpar ou (ii) qualquer potência de 2 com um máximo de 2768 como módulo
Para cada código de operação 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 códigos de operação é 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. Ao mesmo tempo, adicionar ISZERO( irá empurrar a saída para a pilha principal EVM), que será suficientemente poderosa para implementar criptografia de curva elíptica, criptografia de pequenos campos( como Poseidon, Circle STARKs), funções hash tradicionais( como SHA256, KECCAK, BLAKE) e criptografia baseada em grades. Outras atualizações EVM também podem ser implementadas, mas até agora têm recebido menos atenção.
O trabalho restante e as ponderações
Atualmente, o EOF está planejado para ser incluído na próxima bifurcação dura. Embora sempre haja a possibilidade de removê-lo no último momento – em bifurcações duras anteriores, algumas funcionalidades foram temporariamente removidas, mas isso enfrentaria grandes desafios. Remover o EOF significa que quaisquer atualizações futuras ao EVM teriam que ser feitas 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 adicionada à implementação do EVM, e a verificação de código estático também é relativamente complexa. No entanto, em troca, podemos simplificar as linguagens de alto nível, simplificar a implementação do EVM e obter outros benefícios. Pode-se dizer que a prioridade em relação ao roadmap de melhorias contínuas do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante a ser realizada é implementar funcionalidades semelhantes a EVM-MAX com SIMD e realizar testes de benchmark no consumo de gas de várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta seu EVM para que a L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não forem ajustados de forma sincronizada, pode haver incompatibilidade, resultando em efeitos adversos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente os custos de gas em muitos sistemas de prova, tornando a L2 mais eficiente. Isso também facilita a substituição de mais pré-compilados por código EVM que pode executar as mesmas tarefas, o que pode não impactar muito a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser verificadas de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta tinha como objetivo 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
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 central de dependência.
Desde que a abstração de conta foi proposta em 2015, seu objetivo também se expandiu para incluir uma série de "objetivos convenientes", como, por exemplo, uma conta que não possui ETH, mas que tem alguns ERC20, podendo usar ERC20 para pagar o gás.
O que é, como funciona?
O núcleo 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 maneira que seja amigável à manutenção de uma rede descentralizada e proteger contra ataques de negação de serviço.
Um desafio crítico típico é o problema da múltipla falha:
Se houver uma função de validação de 1000 contas que dependa de um único valor S, e o valor S atual 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 invalidar todas as outras transações no pool de memórias. Isso permite que um atacante envie transações 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 as funcionalidades enquanto limita o risco de negação de serviço (DoS), finalmente foi encontrado uma solução para alcançar a "abstração ideal da conta": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações do usuário em duas fases: 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, uma operação do usuário só será aceita quando 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, restrições rigorosas de gas também são aplicadas à 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 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 a ineficiência inerente do contrato: cada pacote tem um custo fixo de cerca de 100.000 gas, além de vários milhares de gas para cada operação do usuário.
Garantir a necessidade das propriedades do Ethereum: como a lista incluída que cria a garantia que precisa ser transferida para a conta do usuário abstrato.
Além disso, o ERC-4337 também expandiu duas funcionalidades:
Agente de pagamento ( Paymasters ): permite que uma conta pague taxas em nome de outra conta, o que viola a regra de que a fase de validação pode acessar apenas a conta do remetente, portanto, foi introduzido um tratamento especial 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 no Rollup.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# 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 tem estado em destaque recentemente é o EIP-7701, que 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 configurar essa parte de código, esse código será executado 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 contas locais:
Incorporar 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 definir limites rigorosos para a complexidade do código executável durante o período de validação—não permitindo o acesso ao estado externo, e mesmo o limite de gás definido no início sendo tão baixo que se torna inválido para aplicações com resistência quântica ou proteção de privacidade—então a segurança desse método é muito clara: apenas substituir a validação ECDSA por uma execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediação, assim como a resistência quântica, são extremamente importantes. Para isso, precisamos encontrar formas 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 compensação parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo para possivelmente obter uma solução mais ideal", e a abordagem ideal pode ser algum tipo de método híbrido. Um método híbrido é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implementar primeiro uma versão de abstração de conta mais ambiciosa na L2. No entanto, o desafio que isso enfrenta é que a equipe da L2 precisa ter confiança no trabalho da proposta de adoção para estar disposta a implementá-la, especialmente para garantir que L1 e/ou outras L2 possam adotar uma solução compatível no futuro.
Outro aplicativo que precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta em L1 ou em L2 dedicado, mas pode ser utilizada em L1 e em qualquer L2 compatível. Fazer isso de forma eficaz pode exigir que o L2 suporte códigos de operação como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação de abstração de contas no L2 suporte essas operações.
)# Como interage com as outras partes do roteiro?
A lista de inclusão precisa suportar transações de abstração de conta. Na prática, a necessidade da lista de inclusão é na verdade muito semelhante à necessidade de um pool de memórias descentralizado, embora sobre
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
12 gostos
Recompensa
12
5
Partilhar
Comentar
0/400
NeverPresent
· 07-25 21:24
Os pros estão sempre a mudar o evm. Quando é que o meu gás vai diminuir?
Ver originalResponder0
GateUser-00be86fc
· 07-23 01:23
Atualizar o EVM vai apenas criar BTC o dia todo.
Ver originalResponder0
MemeCoinSavant
· 07-23 01:22
baseado em melhorias estatisticamente significativas do evm fr fr... em alta sobre o potencial memético do eth tbh
Ver originalResponder0
Deconstructionist
· 07-23 01:16
Aqueles que falavam sobre o estado final já estão fora de cena.
Ver originalResponder0
ReverseFOMOguy
· 07-23 01:14
O protocolo ainda não é divertido o suficiente, entende?
Roteiro de atualização do protocolo Ethereum: melhorias do EVM, abstração de contas e otimização 1559
O futuro possível do protocolo Ethereum(seis): prosperidade
Na design do protocolo Ethereum, há muitos "detalhes" que são muito importantes para o sucesso do Ethereum. Na verdade, cerca de metade do conteúdo envolve diferentes tipos de melhorias do EVM, enquanto o resto é composto por vários tópicos de nicho, que é o que significa "complexidade".
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 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 é, como funciona?
O primeiro passo no roteiro de melhorias do EVM atual é o formato de objeto EVM (EOF), que está previsto para ser incluído na próxima bifurcação dura. EOF é uma série de EIPs que especificam uma nova versão do código EVM, com muitas características únicas, sendo a mais notável:
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados os contratos antigos ( e até mesmo forçados a serem convertidos para código EOF ). Os contratos novos beneficiarão do aumento de eficiência trazido pelo EOF — primeiro com bytecode ligeiramente reduzido por meio da 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, sendo o módulo de cálculo EVM a evolução mais desenvolvida até o momento (EVM-MAX). O EVM-MAX criou um conjunto de novas operações especificamente para a operação 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 de uma única instrução (SIMD), o SIMD, como um conceito do Ethereum, já existe há muito tempo, sendo inicialmente proposto 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 SIMD torna essa dupla orientada para o desempenho uma combinação natural.
Um design aproximado de uma combinação de EIP 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.
O trabalho restante e as ponderações
Atualmente, o EOF está planejado para ser incluído na próxima bifurcação dura. Embora sempre haja a possibilidade de removê-lo no último momento – em bifurcações duras anteriores, algumas funcionalidades foram temporariamente removidas, mas isso enfrentaria grandes desafios. Remover o EOF significa que quaisquer atualizações futuras ao EVM teriam que ser feitas 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 adicionada à implementação do EVM, e a verificação de código estático também é relativamente complexa. No entanto, em troca, podemos simplificar as linguagens de alto nível, simplificar a implementação do EVM e obter outros benefícios. Pode-se dizer que a prioridade em relação ao roadmap de melhorias contínuas do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante a ser realizada é implementar funcionalidades semelhantes a EVM-MAX com SIMD e realizar testes de benchmark no consumo de gas de várias operações criptográficas.
Como interagir com as outras partes do roteiro?
A L1 ajusta seu EVM para que a L2 também possa fazer ajustes correspondentes com mais facilidade. Se ambos não forem ajustados de forma sincronizada, pode haver incompatibilidade, resultando em efeitos adversos. Além disso, o EVM-MAX e o SIMD podem reduzir significativamente os custos de gas em muitos sistemas de prova, tornando a L2 mais eficiente. Isso também facilita a substituição de mais pré-compilados por código EVM que pode executar as mesmas tarefas, o que pode não impactar muito a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser verificadas de uma forma: assinatura ECDSA. Inicialmente, a abstração de conta tinha como objetivo 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 conta foi proposta em 2015, seu objetivo também se expandiu para incluir uma série de "objetivos convenientes", como, por exemplo, uma conta que não possui ETH, mas que tem alguns ERC20, podendo usar ERC20 para pagar o gás.
O que é, como funciona?
O núcleo 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 maneira que seja amigável à manutenção de uma rede descentralizada e proteger contra ataques de negação de serviço.
Um desafio crítico típico é o problema da múltipla falha:
Se houver uma função de validação de 1000 contas que dependa de um único valor S, e o valor S atual 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 invalidar todas as outras transações no pool de memórias. Isso permite que um atacante envie transações 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 as funcionalidades enquanto limita o risco de negação de serviço (DoS), finalmente foi encontrado uma solução para alcançar a "abstração ideal da conta": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações do usuário em duas fases: 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, uma operação do usuário só será aceita quando 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, restrições rigorosas de gas também são aplicadas à 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 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:
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# 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 tem estado em destaque recentemente é o EIP-7701, que 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 configurar essa parte de código, esse código será executado 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 contas locais:
Se começarmos a definir limites rigorosos para a complexidade do código executável durante o período de validação—não permitindo o acesso ao estado externo, e mesmo o limite de gás definido no início sendo tão baixo que se torna inválido para aplicações com resistência quântica ou proteção de privacidade—então a segurança desse método é muito clara: apenas substituir a validação ECDSA por uma execução de código EVM que requer um tempo semelhante.
No entanto, com o passar do tempo, precisamos relaxar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediação, assim como a resistência quântica, são extremamente importantes. Para isso, precisamos encontrar formas 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 compensação parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" versus "esperar mais tempo para possivelmente obter uma solução mais ideal", e a abordagem ideal pode ser algum tipo de método híbrido. Um método híbrido é escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem é implementar primeiro uma versão de abstração de conta mais ambiciosa na L2. No entanto, o desafio que isso enfrenta é que a equipe da L2 precisa ter confiança no trabalho da proposta de adoção para estar disposta a implementá-la, especialmente para garantir que L1 e/ou outras L2 possam adotar uma solução compatível no futuro.
Outro aplicativo que precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta em L1 ou em L2 dedicado, mas pode ser utilizada em L1 e em qualquer L2 compatível. Fazer isso de forma eficaz pode exigir que o L2 suporte códigos de operação como L1SLOAD ou REMOTESTATICCALL, mas isso também requer que a implementação de abstração de contas no L2 suporte essas operações.
)# Como interage com as outras partes do roteiro?
A lista de inclusão precisa suportar transações de abstração de conta. Na prática, a necessidade da lista de inclusão é na verdade muito semelhante à necessidade de um pool de memórias descentralizado, embora sobre