**1. Por que precisamos de Abstração de Conta (AA)? **
As pessoas gostam de lançar perguntas como: “Como trazemos o próximo bilhão de usuários para a Web3?” "Há muitos obstáculos a ultrapassar, mas o mais importante deles é a experiência do utilizador.
O diagrama a seguir é uma experiência de usuário típica para um novo usuário. Observe também que, se você perder sua frase semente, não há como obter seus próprios fundos de volta. Este é um grande obstáculo para novos usuários.
Existem dois tipos de contas: contas externas (EOA) e contas contratuais. O EOA é controlado pela chave privada e a conta do contrato é controlada pelo código do contrato.
EOAs podem iniciar transações para outras contas EOA ou contrato, que podem então executar seu código. As contas de contrato também podem enviar negociações para outras contas de contrato, que podem executar seu próprio código.
Os primeiros dias do Ethereum: execução e verificação de transações**
Quando uma transação é enviada para a rede, ela passa por duas etapas: verificação e execução. Embora a execução da lógica da transação possa ser arbitrária, a parte de validação é fixa.
A parte de verificação é feita por um único algoritmo fixo que o EOA deve usar, ou seja, verificação de assinatura ECDSA. Mas por que usamos um método fixo para verificar a validade das transações? E se a verificação de assinatura ECDSA não for mais confiável no futuro devido à computação quântica?
Se deixarmos a parte de validação aberta, então você pode criar uma transação com um algoritmo de validação muito complexo, então o minerador/validador terá que gastar muitos recursos para verificar se a transação pode ser incluída no bloco.
Agora, observe que os mineradores são pagos apenas para executar e incluir transações, não para verificação. Então, se, depois de gastar muitos recursos, os mineradores descobrirem que não podem adicionar transações, então eles desperdiçam recursos e não recebem nada por isso. Portanto, isso pode ser usado para realizar ataques DDoS na rede. É por isso que o Ethereum começou com um algoritmo de verificação fixo.
Os primeiros dias do Ethereum: o problema de adoção do Multisig**
Uma carteira multisig é um contrato com muitos proprietários com limites. Se você quiser enviar uma transação, você deve obter assinaturas de todos os proprietários antes de poder enviar a transação.
Isso suporta recursos como recuperação social, onde você pode ter muitos amigos para ajudá-lo a recuperar sua carteira se você perder suas chaves privadas. Desde os primeiros dias do Ethereum, o valor que as carteiras multisig podem fornecer tem sido aparente. Portanto, a equipe de desenvolvimento do Ethereum na época queria que os usuários do Ethereum usassem carteiras multisig. No entanto, isso não aconteceu.
Como a equipe de desenvolvimento do Ethereum previa usuários usando carteiras multisig, eles não adicionaram um log automático para transferências ETH porque esperavam que a carteira multisig registrasse todas as transferências ETH. As exchanges na época tinham que analisar as transações de transferência ETH, não registrá-las.
Quando alguém tenta usar uma carteira multisig com logs de transferência ETH, a troca fica irreconhecível porque a troca não analisa os logs. Portanto, essa pequena suposição acaba dificultando a adoção de carteiras multisig.
EIP 86 e 1014: Abstração de Conta Primeiro Passo**
O EIP-86 visa introduzir o conceito de carteira de contrato inteligente chamado “contratos de encaminhamento”. Esses contratos são projetados para receber apenas transações de endereços de “ponto de entrada”, que precisam aderir a um formato específico.
Agora, para criar uma carteira de contrato inteligente, você precisa ter algum ETH de antemão para pagar as taxas de gás. Você pode ir para CEX e obter algum ETH, mas como sua carteira de contrato inteligente ainda não foi criada, você não pode enviar ETH para a carteira ainda.
Se pudermos de alguma forma saber exatamente o endereço do contrato antes que o contrato inteligente seja criado, podemos enviar ETH para esse endereço e, em seguida, criar uma carteira de contrato inteligente usando ETH no endereço.
É isso que o EIP-1014 introduz. Ele apresenta CREATE2 opcodes que permitem determinar o endereço do contrato antes de criar um contrato inteligente. Este é o primeiro passo para a abstração de contas.
O EIP-86 original exigiu mudanças significativas no protocolo porque as mudanças no protocolo exigiam colaboração entre as equipes de desenvolvimento do nó e exigiam um escrutínio extensivo, por isso nunca foi implementado. O EIP-1014 foi implementado no hard fork de Constantinopla.
Desenvolvimento comunitário: Gnosis Safe, Argent Wallet, Rede de postos de gasolina**
Ao discutir o estudo da PEI, a comunidade já se propôs a desenvolver as suas próprias soluções.
O mais notável deles foi o lançamento do Gnosis Safe em 2018. Safe é uma carteira de contrato inteligente que permite aos usuários criar carteiras multisig e também permite que os usuários agrupem várias operações em uma única transação. Ele também permite que os usuários paguem taxas de gás usando tokens ERC20.
Outra nota notável é o lançamento da carteira Argent em 2019. Argent Smart Wallet suporta usuários para criar carteiras multisig, e também permite que os usuários paguem taxas de gás usando tokens ERC20. Ele também permite que os usuários usem a recuperação social para recuperar suas carteiras.
A Gas Station Network (GSN), lançada em 2019, é uma rede descentralizada que permite aos usuários pagar taxas de gás usando tokens ERC20. A GSN pode ser usada com qualquer carteira de contrato inteligente.
EIP 2938 – Um salto gigantesco em frente
A partir de 2018, a equipe do Ethereum voltou sua atenção para a migração para PoS (proof-of-stake), o que inadvertidamente levou a menos ênfase na avaliação e implementação de EIP por equipes de pesquisa e equipes de desenvolvimento de nós.
Esta mudança abriu caminho para a EIP-2938 em 2020, dois anos após a implementação da EIP-1014.
A ideia central por trás da proposta é a introdução de carteiras de contratos inteligentes, que são projetadas para receber especificamente tipos específicos de transações, que podem ser programadas para determinar o limite de gás das transações e desenvolver métodos de verificação arbitrários.
A proposta introduz dois novos opcodes para lidar com transações e, como destacado anteriormente, incluir essas atualizações principais é um processo complexo.
Além disso, há questões em aberto sobre como a proteção contra repetição é implementada e como os nós podem verificar a validade desses novos tipos de transações. Embora a proposta não tenha recebido muita atenção, abriu caminho para a próxima proposta (EIP-3074).
EIP-3074 – Solução altamente versátil**
A proposta introduz dois novos opcodes: AUTH e AUTHCALL. A diferença desta proposta é que apoia as contas externas (EOA) para delegar o controlo aos contratos. Estes opcodes são especificados para contratos “invocadores”, que têm o potencial de melhorar significativamente a funcionalidade de qualquer EOA.
O contrato inicia uma estrutura de transação completamente arbitrária, facilitando a implementação de soluções como multiassinatura, compras em lote e ajuda, recuperação de chaves e depósitos CeFi mais amigáveis. Devido à sua natureza aberta, a proposta surgiu como uma solução altamente versátil capaz de atender a uma ampla gama de casos de uso.
Por outro lado, a posição neutra da proposta também coloca alguns desafios em matéria de segurança. Uma discussão mais aprofundada sugere uma abordagem AUTHCALL mais opinativa para mitigar os riscos associados. Essa discussão levou os pesquisadores a chegarem a uma solução mais otimizada, resultando no EIP-4337.
EIP-4337 – Abstração da conta Ethereum sem alterar o protocolo da camada de consenso**
EIP-4337 propõe um mecanismo para trazer a abstração de conta para o Ethereum sem alterar o protocolo de camada de consenso. Sob este EIP, os usuários interagem com a rede Ethereum de forma diferente; Em vez de enviar transações, o usuário envia o objeto UserOperation para um pool de memória separado. Remetente é o contrato de conta que inicia a ação do usuário. O bundler coleta essas operações e as empacota em uma transação que dispara uma chamada handleOps no contrato EntryPoint especificado para executar a operação empacotada. Paymaster é a entidade que patrocina a transação, e seus detalhes estão incluídos no UserOperation para processamento de taxas.
O agregador verifica assinaturas agregadas, melhorando a segurança e a eficiência. A lista branca do bundler ou cliente suporta pontos de entrada e contratos agregadores, controla as interações e garante a execução adequada das ações do usuário na rede Ethereum, consistente com os objetivos da abstração da conta sem alterar a camada de consenso.
As carteiras de contratos inteligentes implantadas por meio desse processo gerenciam de forma autônoma valores aleatórios e verificação de assinaturas, proporcionando ampla flexibilidade. Esse design ajuda a criar carteiras de contratos inteligentes que podem lidar com transações multisig e empacotadas, recuperação social e até mesmo pagar taxas usando tokens ERC20.
Alguma forma de abstração de conta como a proposta no EIP-4337 poderia ser implementada no futuro de médio prazo do Ethereum, inicialmente aparecendo em novas soluções L2 e eventualmente entrando no Ethereum L1, expandindo assim o escopo da interação do usuário com o Ethereum.
10、L2 - Nova Fronteira
As atualizações do protocolo principal são um obstáculo significativo ao introduzir qualquer EIP relacionada à abstração de contas. Os principais desenvolvedores têm estado ocupados com o roteiro do ETH 2.0, que tem sido uma prioridade máxima há muito tempo.
Mas e o L2? Ao contrário do Ethereum L1, que carrega dívidas técnicas, as cadeias L2 recentes têm uma arquitetura que integra abstrações de contas desde o início.
Por exemplo, StarkNet é um pacote cumulativo de ZK que cria uma abstração de conta exclusiva. Além disso, a Argent, conhecida por sua carteira de contrato inteligente L1, lançou o ArgentX na StarkNet, incorporando uma implementação de abstração de conta personalizada que foi fortemente influenciada pelo EIP-4337. Essas iniciativas ressaltam a importância e aplicabilidade da abstração de contas no blockchain Ethereum.
Ver original
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.
O inventário EIP por trás da abstração da conta
Por Vasa, cofundador da OpenSea Pro; Tradução: Golden Finance Xiaozou
Neste artigo, vamos dar uma olhada rápida nas diferentes EIPs que nos trouxeram às abstrações de contas de hoje.
! [IBi1wWpT0680RWZaqv5DB56VCs7bGvDrkaHl3Wky.png] (https://img.jinse.cn/7122936_watermarknone.png “7122936”)
**1. Por que precisamos de Abstração de Conta (AA)? **
As pessoas gostam de lançar perguntas como: “Como trazemos o próximo bilhão de usuários para a Web3?” "Há muitos obstáculos a ultrapassar, mas o mais importante deles é a experiência do utilizador.
O diagrama a seguir é uma experiência de usuário típica para um novo usuário. Observe também que, se você perder sua frase semente, não há como obter seus próprios fundos de volta. Este é um grande obstáculo para novos usuários.
! [vvFxw94g95EIvo2NuFwxQX9g5mTtJo2EvxwLJO2y.png] (https://img.jinse.cn/7122937_watermarknone.png “7122937”)
Aqui estão algumas coisas que podemos fazer para melhorar a experiência do usuário. Nós podemos:
Crie carteiras sem frases mnemônicas.
Use uma carteira que não exija armazenar ETH e pagar taxas de gás com ETH.
Use o Social Recovery para recuperar sua carteira.
Operações em massa em uma transação.
! [dE8KCPMN0cVxJwYU2lm5yt5B9g3GLhSxilFQWvfW.png] (https://img.jinse.cn/7122938_watermarknone.png “7122938”)
2、Tipo abstrato da conta
Existem dois tipos de contas: contas externas (EOA) e contas contratuais. O EOA é controlado pela chave privada e a conta do contrato é controlada pelo código do contrato.
! [64lX5U5G6sNJZBjPvNiC827QJil9Zi8BpTNMeQ8Y.png] (https://img.jinse.cn/7122939_watermarknone.png “7122939”)
EOAs podem iniciar transações para outras contas EOA ou contrato, que podem então executar seu código. As contas de contrato também podem enviar negociações para outras contas de contrato, que podem executar seu próprio código.
Quando uma transação é enviada para a rede, ela passa por duas etapas: verificação e execução. Embora a execução da lógica da transação possa ser arbitrária, a parte de validação é fixa.
A parte de verificação é feita por um único algoritmo fixo que o EOA deve usar, ou seja, verificação de assinatura ECDSA. Mas por que usamos um método fixo para verificar a validade das transações? E se a verificação de assinatura ECDSA não for mais confiável no futuro devido à computação quântica?
Se deixarmos a parte de validação aberta, então você pode criar uma transação com um algoritmo de validação muito complexo, então o minerador/validador terá que gastar muitos recursos para verificar se a transação pode ser incluída no bloco.
Agora, observe que os mineradores são pagos apenas para executar e incluir transações, não para verificação. Então, se, depois de gastar muitos recursos, os mineradores descobrirem que não podem adicionar transações, então eles desperdiçam recursos e não recebem nada por isso. Portanto, isso pode ser usado para realizar ataques DDoS na rede. É por isso que o Ethereum começou com um algoritmo de verificação fixo.
Uma carteira multisig é um contrato com muitos proprietários com limites. Se você quiser enviar uma transação, você deve obter assinaturas de todos os proprietários antes de poder enviar a transação.
Isso suporta recursos como recuperação social, onde você pode ter muitos amigos para ajudá-lo a recuperar sua carteira se você perder suas chaves privadas. Desde os primeiros dias do Ethereum, o valor que as carteiras multisig podem fornecer tem sido aparente. Portanto, a equipe de desenvolvimento do Ethereum na época queria que os usuários do Ethereum usassem carteiras multisig. No entanto, isso não aconteceu.
Como a equipe de desenvolvimento do Ethereum previa usuários usando carteiras multisig, eles não adicionaram um log automático para transferências ETH porque esperavam que a carteira multisig registrasse todas as transferências ETH. As exchanges na época tinham que analisar as transações de transferência ETH, não registrá-las.
Quando alguém tenta usar uma carteira multisig com logs de transferência ETH, a troca fica irreconhecível porque a troca não analisa os logs. Portanto, essa pequena suposição acaba dificultando a adoção de carteiras multisig.
EIP 86 e 1014: Abstração de Conta Primeiro Passo**
O EIP-86 visa introduzir o conceito de carteira de contrato inteligente chamado “contratos de encaminhamento”. Esses contratos são projetados para receber apenas transações de endereços de “ponto de entrada”, que precisam aderir a um formato específico.
Agora, para criar uma carteira de contrato inteligente, você precisa ter algum ETH de antemão para pagar as taxas de gás. Você pode ir para CEX e obter algum ETH, mas como sua carteira de contrato inteligente ainda não foi criada, você não pode enviar ETH para a carteira ainda.
Se pudermos de alguma forma saber exatamente o endereço do contrato antes que o contrato inteligente seja criado, podemos enviar ETH para esse endereço e, em seguida, criar uma carteira de contrato inteligente usando ETH no endereço.
É isso que o EIP-1014 introduz. Ele apresenta CREATE2 opcodes que permitem determinar o endereço do contrato antes de criar um contrato inteligente. Este é o primeiro passo para a abstração de contas.
O EIP-86 original exigiu mudanças significativas no protocolo porque as mudanças no protocolo exigiam colaboração entre as equipes de desenvolvimento do nó e exigiam um escrutínio extensivo, por isso nunca foi implementado. O EIP-1014 foi implementado no hard fork de Constantinopla.
Desenvolvimento comunitário: Gnosis Safe, Argent Wallet, Rede de postos de gasolina**
Ao discutir o estudo da PEI, a comunidade já se propôs a desenvolver as suas próprias soluções.
O mais notável deles foi o lançamento do Gnosis Safe em 2018. Safe é uma carteira de contrato inteligente que permite aos usuários criar carteiras multisig e também permite que os usuários agrupem várias operações em uma única transação. Ele também permite que os usuários paguem taxas de gás usando tokens ERC20.
Outra nota notável é o lançamento da carteira Argent em 2019. Argent Smart Wallet suporta usuários para criar carteiras multisig, e também permite que os usuários paguem taxas de gás usando tokens ERC20. Ele também permite que os usuários usem a recuperação social para recuperar suas carteiras.
A Gas Station Network (GSN), lançada em 2019, é uma rede descentralizada que permite aos usuários pagar taxas de gás usando tokens ERC20. A GSN pode ser usada com qualquer carteira de contrato inteligente.
EIP 2938 – Um salto gigantesco em frente
A partir de 2018, a equipe do Ethereum voltou sua atenção para a migração para PoS (proof-of-stake), o que inadvertidamente levou a menos ênfase na avaliação e implementação de EIP por equipes de pesquisa e equipes de desenvolvimento de nós.
Esta mudança abriu caminho para a EIP-2938 em 2020, dois anos após a implementação da EIP-1014.
A ideia central por trás da proposta é a introdução de carteiras de contratos inteligentes, que são projetadas para receber especificamente tipos específicos de transações, que podem ser programadas para determinar o limite de gás das transações e desenvolver métodos de verificação arbitrários.
A proposta introduz dois novos opcodes para lidar com transações e, como destacado anteriormente, incluir essas atualizações principais é um processo complexo.
Além disso, há questões em aberto sobre como a proteção contra repetição é implementada e como os nós podem verificar a validade desses novos tipos de transações. Embora a proposta não tenha recebido muita atenção, abriu caminho para a próxima proposta (EIP-3074).
EIP-3074 – Solução altamente versátil**
A proposta introduz dois novos opcodes: AUTH e AUTHCALL. A diferença desta proposta é que apoia as contas externas (EOA) para delegar o controlo aos contratos. Estes opcodes são especificados para contratos “invocadores”, que têm o potencial de melhorar significativamente a funcionalidade de qualquer EOA.
O contrato inicia uma estrutura de transação completamente arbitrária, facilitando a implementação de soluções como multiassinatura, compras em lote e ajuda, recuperação de chaves e depósitos CeFi mais amigáveis. Devido à sua natureza aberta, a proposta surgiu como uma solução altamente versátil capaz de atender a uma ampla gama de casos de uso.
Por outro lado, a posição neutra da proposta também coloca alguns desafios em matéria de segurança. Uma discussão mais aprofundada sugere uma abordagem AUTHCALL mais opinativa para mitigar os riscos associados. Essa discussão levou os pesquisadores a chegarem a uma solução mais otimizada, resultando no EIP-4337.
EIP-4337 – Abstração da conta Ethereum sem alterar o protocolo da camada de consenso**
! [HQ5SxXOpxJLs0tzXo1IgTdGxAe5XHPNAIJiDKUMM.png] (https://img.jinse.cn/7122940_watermarknone.png “7122940”)
EIP-4337 propõe um mecanismo para trazer a abstração de conta para o Ethereum sem alterar o protocolo de camada de consenso. Sob este EIP, os usuários interagem com a rede Ethereum de forma diferente; Em vez de enviar transações, o usuário envia o objeto UserOperation para um pool de memória separado. Remetente é o contrato de conta que inicia a ação do usuário. O bundler coleta essas operações e as empacota em uma transação que dispara uma chamada handleOps no contrato EntryPoint especificado para executar a operação empacotada. Paymaster é a entidade que patrocina a transação, e seus detalhes estão incluídos no UserOperation para processamento de taxas.
O agregador verifica assinaturas agregadas, melhorando a segurança e a eficiência. A lista branca do bundler ou cliente suporta pontos de entrada e contratos agregadores, controla as interações e garante a execução adequada das ações do usuário na rede Ethereum, consistente com os objetivos da abstração da conta sem alterar a camada de consenso.
As carteiras de contratos inteligentes implantadas por meio desse processo gerenciam de forma autônoma valores aleatórios e verificação de assinaturas, proporcionando ampla flexibilidade. Esse design ajuda a criar carteiras de contratos inteligentes que podem lidar com transações multisig e empacotadas, recuperação social e até mesmo pagar taxas usando tokens ERC20.
Alguma forma de abstração de conta como a proposta no EIP-4337 poderia ser implementada no futuro de médio prazo do Ethereum, inicialmente aparecendo em novas soluções L2 e eventualmente entrando no Ethereum L1, expandindo assim o escopo da interação do usuário com o Ethereum.
10、L2 - Nova Fronteira
As atualizações do protocolo principal são um obstáculo significativo ao introduzir qualquer EIP relacionada à abstração de contas. Os principais desenvolvedores têm estado ocupados com o roteiro do ETH 2.0, que tem sido uma prioridade máxima há muito tempo.
Mas e o L2? Ao contrário do Ethereum L1, que carrega dívidas técnicas, as cadeias L2 recentes têm uma arquitetura que integra abstrações de contas desde o início.
Por exemplo, StarkNet é um pacote cumulativo de ZK que cria uma abstração de conta exclusiva. Além disso, a Argent, conhecida por sua carteira de contrato inteligente L1, lançou o ArgentX na StarkNet, incorporando uma implementação de abstração de conta personalizada que foi fortemente influenciada pelo EIP-4337. Essas iniciativas ressaltam a importância e aplicabilidade da abstração de contas no blockchain Ethereum.