Possíveis direções futuras do protocolo Ethereum: Capítulo da prosperidade
O design do protocolo Ethereum tem muitos "detalhes" importantes que são cruciais para o seu sucesso. Cerca de metade do conteúdo envolve diferentes tipos de melhorias EVM, enquanto o restante é composto por vários tópicos de nicho, e é isso que significa "prosperidade".
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 usuários desfrutem de contas mais seguras e convenientes.
Otimizar a economia das taxas de transação, aumentar a escalabilidade enquanto se reduz o risco
Explorar criptografia avançada, para que o Ethereum melhore significativamente a longo prazo
Melhoria do EVM
resolveu qual problema?
Atualmente, a EVM é difícil de analisar estaticamente, o que torna complicado 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 várias 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 do objeto EVM (EOF), 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 ( pode ser executado, mas não é possível ler ) do EVM e os dados ( podem ser lidos, mas não podem ser executados entre a separação de ).
Proibido 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
A estrutura do código EOF inclui a seção de código, a seção de dados e a seção de informações de tipo.
Após a introdução do EOF, as atualizações adicionais tornaram-se mais fáceis. O desenvolvimento mais avançado atualmente é a extensão aritmética do módulo EVM ( 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 inacessível através de outros códigos de operação, o que possibilita o uso de otimizações como a multiplicação de Montgomery.
Uma ideia mais recente é combinar o EVM-MAX com a característica de SIMD (Single Instruction, Multiple Data) (. O SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, e a combinação do EVM-MAX com o SIMD torna essas duas escalabilidades orientadas para o desempenho uma combinação natural.
) ligação de pesquisa existente
EOF:
EVM-MAX:
SIMD:
trabalho restante e ponderações
Atualmente, o EOF está programado para ser incluído na próxima bifurcação dura. Embora sempre seja possível removê-lo no último minuto, fazê-lo enfrentará grandes desafios. Remover o EOF significa que quaisquer futuras atualizações ao EVM terão que ser feitas sem o EOF, embora isso possa ser feito, 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 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 roadmap do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante que precisa ser feita é 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 mais facilmente. Se ambos não forem ajustados em sincronia, pode haver incompatibilidade, o que traria 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 impactar drasticamente a eficiência.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.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
A rotação de chaves antigas ### é amplamente considerada uma prática de segurança recomendada (
Carteira multi-assinatura e carteira de recuperação social
Usar uma chave para operações de baixo valor, usar outra chave ) ou um conjunto de chaves ( para operações de alto valor
Permitir que o protocolo de privacidade funcione sem intermediários, reduzindo significativamente sua complexidade e eliminando um ponto de dependência central crítico.
Desde que a abstração de contas foi proposta em 2015, o seu objetivo também se expandiu para incluir uma série de "objetivos de conveniência", como por exemplo, uma conta que não tem ETH mas possui alguns ERC20 poder pagar o gas com ERC20.
![Vitalik sobre o possível futuro do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) O que é, como funciona?
O núcleo da abstração de contas é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade vem de implementar isso de uma forma que seja amigável para a manutenção de uma rede descentralizada e de prevenir ataques de negação de serviço.
Um desafio crítico típico é o problema de múltiplas falhas: se houver 1000 contas cuja função de verificação depende de um único valor S, e o valor atual S faz com que as transações no pool de memória sejam todas 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ços, com o objetivo de expandir as funcionalidades enquanto limita os riscos de negação de serviço ### DoS (, finalmente foi alcançada uma solução para realizar a "abstração ideal de contas": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações do utilizador em duas fases: validação e execução. Todas as validações são processadas primeiro, e todas as execuções são processadas depois. No pool de memória, uma operação do utilizador só será aceite se a fase de validação envolver apenas a sua própria conta e não ler variáveis de ambiente. Isso pode prevenir ataques de falha múltipla. Além disso, limites rigorosos de gas são também impostos na etapa de validação.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Links de pesquisa existentes
Palestra sobre a história da abstração de contas:
ERC-4337:
EIP-7702:
O código BLSWallet ### utiliza a função de agregação (:
EIP-7562) escrita no protocolo de abstração de conta (:
EIP-7701) protocolo de escrita baseado em EOF conta abstrata (:
) o trabalho restante e as compensações
Atualmente, a principal questão a resolver é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem sido popular recentemente é o EIP-7701, que implementa a abstração de contas acima do EOF. Uma conta pode ter uma parte de código separada para verificação; se a conta configurar essa parte de código, ela será executada na etapa de verificação das transações provenientes dessa conta.
A beleza deste método reside no fato de que ele demonstra 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 definir limites rigorosos para a complexidade do código executável durante o período de validação, a segurança deste método torna-se muito clara: basta 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 flexibilizar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários, bem como 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 simplistas.
A principal consideração parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" em comparação com "esperar mais tempo, possivelmente obtendo uma solução mais ideal", sendo que 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 mais ambiciosa de abstração de contas na L2. No entanto, o desafio que isso enfrenta é que a equipe da L2 precisa ter confiança no trabalho da proposta adotada para estar disposta a implementá-la, especialmente para garantir que o L1 e/ou outras L2 possam adotar soluções compatíveis no futuro.
Outra aplicação que também precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta no L1 ou em um L2 dedicado, mas pode ser utilizada no 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 da abstração de conta no L2 suporte essas operações.
) Como interage com outras partes do roteiro?
As listas de inclusão precisam suportar transações de abstração de conta. Na prática, a necessidade de listas de inclusão é muito semelhante à necessidade de um pool de memória descentralizado, embora haja um pouco mais de flexibilidade para as listas de inclusão. Além disso, a implementação da abstração de conta deve coordenar-se entre L1 e L2 o máximo possível. Se no futuro esperarmos que a maioria dos usuários utilize Rollup de armazenamento de chaves, o design da abstração de conta deve ser baseado nisso.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Melhoria EIP-1559
) Que problema resolve?
O EIP-1559 foi ativado no Ethereum em 2021, melhorando significativamente o tempo médio de inclusão de blocos. No entanto, a implementação atual do EIP-1559 não é perfeita em vários aspectos:
A fórmula tem algumas falhas: não é direcionada a 50% dos blocos, mas sim a cerca de 50-53% dos blocos cheios, dependendo da variância ###, o que está relacionado com o que os matemáticos chamam de "desigualdade da média aritmética-geométrica" (.
Ajuste não é rápido o suficiente em situações extremas.
A fórmula )EIP-4844( usada para blobs é projetada especificamente para resolver o primeiro problema, sendo também mais simples no geral. No entanto, o EIP-1559 em si e o EIP-4844 não tentaram resolver o segundo problema. Portanto, a situação atual é um estado intermediário confuso, envolvendo dois mecanismos diferentes, e há uma visão de que, com o tempo, ambos precisam ser melhorados.
Além disso, existem outras fraquezas na precificação de recursos do Ethereum que não estão relacionadas com o EIP-1559, mas que podem ser resolvidas com ajustes ao EIP-1559. Um dos principais problemas é a diferença entre a situação média e a pior situação: os preços dos recursos no Ethereum devem ser definidos para lidar com a pior situação, ou seja, o consumo total de gas de um bloco ocupa um recurso, mas o uso médio real está muito abaixo disso, levando à ineficiência.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) O que é Gas multidimensional e como funciona?
A solução para esses problemas de ineficiência é o Gas multidimensional: estabelecer preços e limites diferentes para diferentes recursos. Este conceito é tecnicamente independente do EIP-1559, mas do EIP-1
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.
14 Curtidas
Recompensa
14
7
Compartilhar
Comentário
0/400
MissedAirdropBro
· 07-26 03:16
Por que é outra vez a abstração de contas!
Ver originalResponder0
BrokenDAO
· 07-25 06:25
Mais um roteiro ambicioso, que provavelmente acabará repetindo os erros do Casper.
Ver originalResponder0
GasGuru
· 07-24 20:52
Parece muito confiável, hum.
Ver originalResponder0
SigmaBrain
· 07-24 20:51
O que é que é esta versão que ainda precisa de alterações?
Ver originalResponder0
OPsychology
· 07-24 20:45
Quando é que esta atualização vai ser lançada?
Ver originalResponder0
WalletWhisperer
· 07-24 20:31
padrões comportamentais sugerem que o evm2.0 irá desencadear migrações em massa de carteiras... estatisticamente inevitável
Ver originalResponder0
Whale_Whisperer
· 07-24 20:29
A atualização do EVM deveria ter sido proposta há muito tempo, essa taxa de gás realmente não dá para suportar.
O futuro do protocolo Ethereum: Atualizações de EVM, abstração de contas e otimização de taxas
Possíveis direções futuras do protocolo Ethereum: Capítulo da prosperidade
O design do protocolo Ethereum tem muitos "detalhes" importantes que são cruciais para o seu sucesso. Cerca de metade do conteúdo envolve diferentes tipos de melhorias EVM, enquanto o restante é composto por vários tópicos de nicho, e é isso que significa "prosperidade".
Prosperidade: Objetivo-chave
Melhoria do EVM
resolveu qual problema?
Atualmente, a EVM é difícil de analisar estaticamente, o que torna complicado 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 várias 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 do objeto EVM (EOF), 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:
A estrutura do código EOF inclui a seção de código, a seção de dados e a seção de informações de tipo.
Após a introdução do EOF, as atualizações adicionais tornaram-se mais fáceis. O desenvolvimento mais avançado atualmente é a extensão aritmética do módulo EVM ( 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 inacessível através de outros códigos de operação, o que possibilita o uso de otimizações como a multiplicação de Montgomery.
Uma ideia mais recente é combinar o EVM-MAX com a característica de SIMD (Single Instruction, Multiple Data) (. O SIMD pode ser utilizado para acelerar muitas formas de criptografia, incluindo funções de hash, STARKs de 32 bits e criptografia baseada em redes, e a combinação do EVM-MAX com o SIMD torna essas duas escalabilidades orientadas para o desempenho uma combinação natural.
) ligação de pesquisa existente
trabalho restante e ponderações
Atualmente, o EOF está programado para ser incluído na próxima bifurcação dura. Embora sempre seja possível removê-lo no último minuto, fazê-lo enfrentará grandes desafios. Remover o EOF significa que quaisquer futuras atualizações ao EVM terão que ser feitas sem o EOF, embora isso possa ser feito, 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 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 roadmap do Ethereum L1 deve incluir e se basear no EOF.
Uma tarefa importante que precisa ser feita é 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 mais facilmente. Se ambos não forem ajustados em sincronia, pode haver incompatibilidade, o que traria 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 impactar drasticamente a eficiência.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.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 sua complexidade e eliminando um ponto de dependência central crítico.
Desde que a abstração de contas foi proposta em 2015, o seu objetivo também se expandiu para incluir uma série de "objetivos de conveniência", como por exemplo, uma conta que não tem ETH mas possui alguns ERC20 poder pagar o gas com ERC20.
![Vitalik sobre o possível futuro do Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) O que é, como funciona?
O núcleo da abstração de contas é simples: permite que contratos inteligentes iniciem transações, e não apenas EOA. Toda a complexidade vem de implementar isso de uma forma que seja amigável para a manutenção de uma rede descentralizada e de prevenir ataques de negação de serviço.
Um desafio crítico típico é o problema de múltiplas falhas: se houver 1000 contas cuja função de verificação depende de um único valor S, e o valor atual S faz com que as transações no pool de memória sejam todas 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ços, com o objetivo de expandir as funcionalidades enquanto limita os riscos de negação de serviço ### DoS (, finalmente foi alcançada uma solução para realizar a "abstração ideal de contas": ERC-4337.
O funcionamento do ERC-4337 divide o processamento das operações do utilizador em duas fases: validação e execução. Todas as validações são processadas primeiro, e todas as execuções são processadas depois. No pool de memória, uma operação do utilizador só será aceite se a fase de validação envolver apenas a sua própria conta e não ler variáveis de ambiente. Isso pode prevenir ataques de falha múltipla. Além disso, limites rigorosos de gas são também impostos na etapa de validação.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Links de pesquisa existentes
) o trabalho restante e as compensações
Atualmente, a principal questão a resolver é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem sido popular recentemente é o EIP-7701, que implementa a abstração de contas acima do EOF. Uma conta pode ter uma parte de código separada para verificação; se a conta configurar essa parte de código, ela será executada na etapa de verificação das transações provenientes dessa conta.
A beleza 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, a segurança deste método torna-se muito clara: basta 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 flexibilizar esses limites, pois permitir que aplicações de proteção de privacidade funcionem sem intermediários, bem como 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 simplistas.
A principal consideração parece ser "escrever rapidamente uma solução que satisfaça menos pessoas" em comparação com "esperar mais tempo, possivelmente obtendo uma solução mais ideal", sendo que 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 mais ambiciosa de abstração de contas na L2. No entanto, o desafio que isso enfrenta é que a equipe da L2 precisa ter confiança no trabalho da proposta adotada para estar disposta a implementá-la, especialmente para garantir que o L1 e/ou outras L2 possam adotar soluções compatíveis no futuro.
Outra aplicação que também precisamos considerar claramente é a conta de armazenamento de chaves, que armazena o estado relacionado à conta no L1 ou em um L2 dedicado, mas pode ser utilizada no 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 da abstração de conta no L2 suporte essas operações.
) Como interage com outras partes do roteiro?
As listas de inclusão precisam suportar transações de abstração de conta. Na prática, a necessidade de listas de inclusão é muito semelhante à necessidade de um pool de memória descentralizado, embora haja um pouco mais de flexibilidade para as listas de inclusão. Além disso, a implementação da abstração de conta deve coordenar-se entre L1 e L2 o máximo possível. Se no futuro esperarmos que a maioria dos usuários utilize Rollup de armazenamento de chaves, o design da abstração de conta deve ser baseado nisso.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Melhoria EIP-1559
) Que problema resolve?
O EIP-1559 foi ativado no Ethereum em 2021, melhorando significativamente o tempo médio de inclusão de blocos. No entanto, a implementação atual do EIP-1559 não é perfeita em vários aspectos:
A fórmula )EIP-4844( usada para blobs é projetada especificamente para resolver o primeiro problema, sendo também mais simples no geral. No entanto, o EIP-1559 em si e o EIP-4844 não tentaram resolver o segundo problema. Portanto, a situação atual é um estado intermediário confuso, envolvendo dois mecanismos diferentes, e há uma visão de que, com o tempo, ambos precisam ser melhorados.
Além disso, existem outras fraquezas na precificação de recursos do Ethereum que não estão relacionadas com o EIP-1559, mas que podem ser resolvidas com ajustes ao EIP-1559. Um dos principais problemas é a diferença entre a situação média e a pior situação: os preços dos recursos no Ethereum devem ser definidos para lidar com a pior situação, ou seja, o consumo total de gas de um bloco ocupa um recurso, mas o uso médio real está muito abaixo disso, levando à ineficiência.
![Vitalik sobre o possível futuro do Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
) O que é Gas multidimensional e como funciona?
A solução para esses problemas de ineficiência é o Gas multidimensional: estabelecer preços e limites diferentes para diferentes recursos. Este conceito é tecnicamente independente do EIP-1559, mas do EIP-1