Possibilidades futuras do protocolo Ethereum: prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais para o seu sucesso. Cerca de metade do conteúdo diz respeito a diferentes tipos de melhorias do EVM, enquanto o restante é composto por vários temas de nicho, que é o que significa "prosperidade".
Prosperidade: Objetivo chave
Transformar o EVM em um "estado final" de alto desempenho e estabilidade
Introduzir a abstração de conta no protocolo, permitindo que todos os usuários desfrutem de uma conta mais segura e conveniente.
Otimizar a economia das taxas de transação, aumentar a escalabilidade ao mesmo tempo que reduz o risco
Explorar a 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, tornando difícil implementar muitas formas de criptografia avançada, a menos que haja suporte explícito através de pré-compilações.
O que é isso e como funciona?
O primeiro passo do roteiro de melhoria do EVM atual é o formato de objeto EVM (EOF), que está planejado para ser incluído no próximo hard fork. EOF é uma série de EIPs que especificam uma nova versão do código EVM, com muitas características únicas, sendo a mais significativa:
O código ( é executável, mas não é possível ler ) do EVM e os dados ( podem ser lidos, mas não é possível executar ).
Proibido redirecionamento dinâmico, apenas redirecionamento estático permitido
O código EVM não pode mais observar informações relacionadas ao combustível
Foi adicionada uma nova mecânica de sub-rotina explícita
Os contratos antigos continuarão a existir e poderão ser criados, embora eventualmente possam ser gradualmente descontinuados os contratos antigos ( e até mesmo forçados a serem convertidos para código EOF ). Os novos contratos beneficiarão da melhoria de eficiência trazida pelo EOF---primeiro com o bytecode ligeiramente reduzido através das características de sub-rotina, e depois com novas funcionalidades específicas do EOF ou redução nos custos de gas.
Após a introdução do EOF, as atualizações adicionais tornaram-se mais fáceis, sendo o módulo EVM a extensão aritmética mais desenvolvida até o momento (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, o que possibilita a utilização 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), onde o SIMD, como um conceito do Ethereum, já existe há muito tempo, sendo proposto pela primeira vez por Greg Colvin no EIP-616. 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 expansões orientadas para o desempenho uma combinação natural.
Link de pesquisa existente
EOF:
EVM-MAX:
SIMD:
Trabalho restante e ponderações
Atualmente, o EOF está previsto 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, fazê-lo enfrentará grandes desafios. Remover o EOF significa que qualquer atualização futura do 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 rota priorizada 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 roteiro?
A L1 ajusta seu EVM para que o L2 também possa fazer 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 o custo de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Isso também facilita a substituição de mais pré-compilações por código EVM que pode executar as mesmas tarefas, o que pode não afetar significativamente a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser verificadas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de contas 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
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 de conveniência", como, por exemplo, uma conta que não possui ETH, mas que possui alguns ERC20, podendo usar ERC20 para pagar o gás.
MPC( cálculo multipartidário) é 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.
A EIP-7702 é uma proposta que está planejada para ser introduzida na próxima bifurcação dura. A EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência de fornecer abstração de contas para beneficiar todos os usuários (, incluindo usuários EOA ). O objetivo é melhorar a experiência de todos os usuários a curto prazo e evitar a divisão em dois ecossistemas.
Este trabalho começou no EIP-3074 e eventualmente formou o EIP-7702. O EIP-7702 oferece as "funções de conveniência" da abstração de contas a todos os usuários, incluindo as contas externas EOA( de hoje, ou seja, contas controladas por assinaturas ECDSA).
Embora alguns desafios (, especialmente o desafio da "conveniência" ), possam ser resolvidos por meio de tecnologias progressivas, como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas 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 é a implementação segura, o que representa 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 para a manutenção de redes descentralizadas e prevenir ataques de negação de serviço.
Um desafio chave 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 S atual torna todas as transações no pool de memória válidas, então uma única transação que inverta o valor de S pode invalidar todas as outras transações no pool de memória. Isso permite que um atacante envie transações de lixo para o pool de memória a um custo muito baixo, bloqueando assim os recursos dos nós da rede.
Após anos de esforço, visando expandir as funcionalidades enquanto limita o risco de negação de serviço (DoS), chegamos finalmente à solução para a implementação da "abstração ideal de conta": ERC-4337.
A forma como o ERC-4337 funciona é dividir o processamento das operações dos usuários em duas fases: validação e execução. Todas as validações são tratadas primeiro, e todas as execuções são tratadas em seguida. No pool de memória, uma operação dos usuários 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, limites rigorosos de gas também são impostos à etapa de validação.
ERC-4337 foi projetado como um padrão de protocolo adicional (ERC), pois 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.
As duas razões principais são as seguintes:
A ineficiência inerente do EntryPoint como contrato: cada bundle 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 criada com garantia precisa ser transferida para a conta do usuário abstrato.
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 de que a fase de validação só pode acessar a conta do remetente, portanto, um tratamento especial foi introduzido 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. Isto é necessário para alcançar a máxima eficiência de dados em Rollup.
![Vitalik sobre o possível futuro do Ethereum (Seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
)# Ligações de pesquisa existentes
Palestra sobre a história da abstração de contas:
ERC-4337:
EIP-7702:
O código BLSWallet ### utiliza a funcionalidade de agregação (:
EIP-7562) escrita no protocolo de abstração de conta (:
EIP-7701) protocolo de escrita baseado em EOF para abstração de conta (:
)# Trabalho restante e ponderações
Atualmente, o principal desafio é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem recebido atenção 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 tiver essa parte de código definida, ela será executada durante a etapa de verificação das transações provenientes dessa conta.
A fascinação 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 a 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 ineficaz para aplicações de resistência quântica ou proteção de privacidade---então a segurança desse método é muito clara: simplesmente substituir a verificação ECDSA por uma 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, bem como a resistência quântica, são extremamente importantes. Para isso, precisamos encontrar formas mais flexíveis de lidar com 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" versus "esperar mais tempo, possivelmente para obter uma solução mais ideal", sendo o método ideal uma espécie de abordagem híbrida. Uma abordagem híbrida seria escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem seria implementar primeiro uma versão de abstração de conta mais ambiciosa no L2. No entanto, o desafio enfrentado é que a equipe do L2 precisa ter plena confiança no trabalho da proposta adotada para estar disposta a implementá-la, especialmente para garantir que o L1 e/ou outros L2 possam adotar soluções compatíveis no futuro.
Outro aplicativo que também precisamos considerar claramente são as contas de armazenamento de chaves, que armazenam o estado relacionado à conta no L1 ou em L2 dedicado, mas podem ser acessadas tanto no L1 quanto em qualquer outro.
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.
25 gostos
Recompensa
25
6
Partilhar
Comentar
0/400
AllInAlice
· 07-18 02:48
BTC leva o caminho para novos máximos
Ver originalResponder0
BlockchainWorker
· 07-16 06:08
A mudança leva tempo
Ver originalResponder0
TokenDustCollector
· 07-15 04:37
A EVM precisa urgentemente de aumentar a eficiência
Roteiro de prosperidade do Ethereum: atualização do EVM, abstração de contas e otimização do EIP-1559
Possibilidades futuras do protocolo Ethereum: prosperidade
O design do protocolo Ethereum tem muitos "detalhes" que são cruciais para o seu sucesso. Cerca de metade do conteúdo diz respeito a diferentes tipos de melhorias do EVM, enquanto o restante é composto por vários temas de nicho, que é o 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, tornando difícil implementar muitas formas de criptografia avançada, a menos que haja suporte explícito através de pré-compilações.
O que é isso e como funciona?
O primeiro passo do roteiro de melhoria do EVM atual é o formato de objeto EVM (EOF), que está planejado para ser incluído no próximo hard fork. EOF é uma série de EIPs que especificam uma nova versão do código EVM, com muitas características únicas, sendo a mais significativa:
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 da melhoria de eficiência trazida pelo EOF---primeiro com o bytecode ligeiramente reduzido através das características de sub-rotina, e depois com novas funcionalidades específicas do EOF ou redução nos custos de gas.
Após a introdução do EOF, as atualizações adicionais tornaram-se mais fáceis, sendo o módulo EVM a extensão aritmética mais desenvolvida até o momento (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, o que possibilita a utilização 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), onde o SIMD, como um conceito do Ethereum, já existe há muito tempo, sendo proposto pela primeira vez por Greg Colvin no EIP-616. 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 expansões orientadas para o desempenho uma combinação natural.
Link de pesquisa existente
Trabalho restante e ponderações
Atualmente, o EOF está previsto 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, fazê-lo enfrentará grandes desafios. Remover o EOF significa que qualquer atualização futura do 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 rota priorizada 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 roteiro?
A L1 ajusta seu EVM para que o L2 também possa fazer 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 o custo de gas de muitos sistemas de prova, tornando o L2 mais eficiente. Isso também facilita a substituição de mais pré-compilações por código EVM que pode executar as mesmas tarefas, o que pode não afetar significativamente a eficiência.
abstração de conta
Que problema foi resolvido?
Atualmente, as transações só podem ser verificadas de uma maneira: assinatura ECDSA. Inicialmente, a abstração de contas 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 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 que possui alguns ERC20, podendo usar ERC20 para pagar o gás.
MPC( cálculo multipartidário) é 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.
A EIP-7702 é uma proposta que está planejada para ser introduzida na próxima bifurcação dura. A EIP-7702 é o resultado de uma crescente conscientização sobre a conveniência de fornecer abstração de contas para beneficiar todos os usuários (, incluindo usuários EOA ). O objetivo é melhorar a experiência de todos os usuários a curto prazo e evitar a divisão em dois ecossistemas.
Este trabalho começou no EIP-3074 e eventualmente formou o EIP-7702. O EIP-7702 oferece as "funções de conveniência" da abstração de contas a todos os usuários, incluindo as contas externas EOA( de hoje, ou seja, contas controladas por assinaturas ECDSA).
Embora alguns desafios (, especialmente o desafio da "conveniência" ), possam ser resolvidos por meio de tecnologias progressivas, como computação multipartidária ou EIP-7702, o principal objetivo de segurança da proposta de abstração de contas 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 é a implementação segura, o que representa 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 para a manutenção de redes descentralizadas e prevenir ataques de negação de serviço.
Um desafio chave 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 S atual torna todas as transações no pool de memória válidas, então uma única transação que inverta o valor de S pode invalidar todas as outras transações no pool de memória. Isso permite que um atacante envie transações de lixo para o pool de memória a um custo muito baixo, bloqueando assim os recursos dos nós da rede.
Após anos de esforço, visando expandir as funcionalidades enquanto limita o risco de negação de serviço (DoS), chegamos finalmente à solução para a implementação da "abstração ideal de conta": ERC-4337.
A forma como o ERC-4337 funciona é dividir o processamento das operações dos usuários em duas fases: validação e execução. Todas as validações são tratadas primeiro, e todas as execuções são tratadas em seguida. No pool de memória, uma operação dos usuários 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, limites rigorosos de gas também são impostos à etapa de validação.
ERC-4337 foi projetado como um padrão de protocolo adicional (ERC), pois 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.
As 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 (Seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
)# Ligações de pesquisa existentes
)# Trabalho restante e ponderações
Atualmente, o principal desafio é como integrar completamente a abstração de contas no protocolo. O EIP de abstração de contas que tem recebido atenção 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 tiver essa parte de código definida, ela será executada durante a etapa de verificação das transações provenientes dessa conta.
A fascinação 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 a 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 ineficaz para aplicações de resistência quântica ou proteção de privacidade---então a segurança desse método é muito clara: simplesmente substituir a verificação ECDSA por uma 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, bem como a resistência quântica, são extremamente importantes. Para isso, precisamos encontrar formas mais flexíveis de lidar com 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" versus "esperar mais tempo, possivelmente para obter uma solução mais ideal", sendo o método ideal uma espécie de abordagem híbrida. Uma abordagem híbrida seria escrever mais rapidamente alguns casos de uso e reservar mais tempo para explorar outros casos de uso. Outra abordagem seria implementar primeiro uma versão de abstração de conta mais ambiciosa no L2. No entanto, o desafio enfrentado é que a equipe do L2 precisa ter plena confiança no trabalho da proposta adotada para estar disposta a implementá-la, especialmente para garantir que o L1 e/ou outros L2 possam adotar soluções compatíveis no futuro.
Outro aplicativo que também precisamos considerar claramente são as contas de armazenamento de chaves, que armazenam o estado relacionado à conta no L1 ou em L2 dedicado, mas podem ser acessadas tanto no L1 quanto em qualquer outro.