Cada conta Ethereum implementa cinco funcionalidades:
Um EOA os implementa de forma codificada:
Abstração de conta significa adicionar lógica programática a estas cinco funcionalidades:
O EIP-3074 visa abstrair a execução, sobrecarregando o EOA com lógica de execução arbitrária por meio de invocadores. Tem uma propriedade única – alargar as capacidades de uma EOA sem ter de migrar activos para uma nova conta. Não é necessário abordar questões como o acesso descentralizado porque a execução não afeta isso. As outras quatro funcionalidades sim, mas estão fora do escopo do EIP-3074.
O ERC-4337 visa abstrair toda a conta – todas as cinco funcionalidades. É um problema mais difícil de resolver se quisermos preservar a descentralização e a resistência à censura. O foco do ERC-4337 é mitigar DoS e vetores de ataque de luto possibilitados pela abstração das primeiras quatro funcionalidades sem recorrer a infraestrutura centralizada. Como ERC, não pode ampliar as capacidades de uma EOA e requer a migração para uma conta inteligente.
A sobreposição entre os dois métodos é mínima: apenas abstração de execução.
Além disso, cada método visa resolver problemas que o outro não resolve: o EIP-3074 visa servir os EOAs existentes e manter as coisas o mais simples possível. O ERC-4337 visa fornecer abstração completa de contas sem sacrificar as propriedades principais do Ethereum, como a descentralização.
Se insistirmos em comparar o ERC-4337 com uma proposta anterior, o mais próximo é o EIP-2938, e não o EIP-3074. EIP-2938 foi um avanço na abstração de contas, a primeira proposta para perceber a dificuldade de mitigação de DoS em um mempool AA. O ERC-4337 resolve certos problemas que o EIP-2938 não resolveu, mas uma comparação completa está fora do escopo deste documento.
Ambos resolvem a abstração de execução e, portanto, habilitam a última categoria dos casos de uso acima:
O EIP-5003 complementa o EIP-3074, permitindo que a EOA revogue sua chave ECDSA e se torne um contrato inteligente. Como contrato, pode abstrair o resto das funcionalidades da conta, por exemplo substituir ECDSA por uma assinatura diferente, alternar chaves, aplicar políticas de acesso, etc. Nesse sentido é um tanto equivalente a propostas como EIP-6913 e EIP-7377, mas é superior ao EIP-7377 porque como opcode pode utilizar um sistema de captação de gás para a própria migração.
Depois que o EOA for convertido em um contrato inteligente, ele não poderá mais ser negociado diretamente e precisará ser acessado por meio de outro EOA. Isto introduz o desafio que o ERC-4337 foi projetado para resolver. O usuário tem duas maneiras de realizar transações com a conta após a migração:
A forma de descentralizar o acesso à conta pós-migração é aplicar certas restrições até que a conta pague o gás. Esta abordagem foi adotada tanto pelo EIP-2938 quanto pelo ERC-4337. O<a href="https://notes.ethereum.org/ @yoav /unified-erc-4337-mempool">ERC-4337 mempool oferece uma forma descentralizada de transações com a conta.
TL;DR: Não, apenas destaca a necessidade do ERC-4337.
É tentador para os usuários EOA existentes migrar para uma conta inteligente local em vez de transferir ativos. No entanto, apresenta certas vulnerabilidades, algumas das quais não podem ser mitigadas.
O que poderia dar errado se a chave EOA fosse comprometida após ter sido revogada?
O usuário pode queimar a chave privada após a migração e esperar que nenhuma cópia seja deixada, mas o usuário também não pode reivindicar o mesmo endereço em outras cadeias.
Portanto, a migração deve ser usada como último recurso quando houver um forte motivo para manter o endereço antigo. Por padrão, novas contas são melhor implantadas com CREATE2 em vez de migradas de uma EOA, para que não sejam vinculadas a uma chave EOA em outras cadeias.
A comunidade tende a enfatizar excessivamente a importância da migração EOA porque a maioria dos utilizadores actuais têm EOAs. O próximo bilhão de usuários poderia começar com uma conta inteligente e não ter que migrar de uma EOA. Nós, os atuais usuários da EOA, somos uma pequena fração disso. A migração pode ser importante por um tempo, para os usuários atuais migrarem. Ele se tornará um fluxo raramente usado quando a abstração de contas for a norma.
Sim, eles poderiam ser <a href="https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy"> combinados de maneiras interessantes. Se uma rede adotar o EIP-3074, os projetos que utilizam o ERC-4337 poderão utilizá-lo em seu benefício.
Tanto o EIP-3074 quanto o ERC-4337 são etapas para obter alguns dos benefícios da abstração completa de contas nativas. O primeiro se concentra em obter todos os benefícios da abstração de execução e o último se concentra em obter todos os benefícios da abstração de contas em todas as cadeias EVM, mas de uma forma não nativa e menos eficiente.
Uma rede que deseja que seus usuários se beneficiem da abstração completa de contas nativas poderia adotar o RIP-7560. Ele usa a mesma arquitetura de conta e mempool do ERC-4337, mas funciona nativamente no nível do protocolo.
O RIP-7560 não precisa ser adotado desde o primeiro dia, e as contas existentes poderão migrar para ele nas redes que optarem por adotá-lo a qualquer momento no futuro:
Estamos coletando feedback sobre o RIP-7560 antes de propor sua consagração. Se você estiver interessado na abstração de contas nativas, revise o PR ou participe da discussão.
Compartilhar
Conteúdo
Cada conta Ethereum implementa cinco funcionalidades:
Um EOA os implementa de forma codificada:
Abstração de conta significa adicionar lógica programática a estas cinco funcionalidades:
O EIP-3074 visa abstrair a execução, sobrecarregando o EOA com lógica de execução arbitrária por meio de invocadores. Tem uma propriedade única – alargar as capacidades de uma EOA sem ter de migrar activos para uma nova conta. Não é necessário abordar questões como o acesso descentralizado porque a execução não afeta isso. As outras quatro funcionalidades sim, mas estão fora do escopo do EIP-3074.
O ERC-4337 visa abstrair toda a conta – todas as cinco funcionalidades. É um problema mais difícil de resolver se quisermos preservar a descentralização e a resistência à censura. O foco do ERC-4337 é mitigar DoS e vetores de ataque de luto possibilitados pela abstração das primeiras quatro funcionalidades sem recorrer a infraestrutura centralizada. Como ERC, não pode ampliar as capacidades de uma EOA e requer a migração para uma conta inteligente.
A sobreposição entre os dois métodos é mínima: apenas abstração de execução.
Além disso, cada método visa resolver problemas que o outro não resolve: o EIP-3074 visa servir os EOAs existentes e manter as coisas o mais simples possível. O ERC-4337 visa fornecer abstração completa de contas sem sacrificar as propriedades principais do Ethereum, como a descentralização.
Se insistirmos em comparar o ERC-4337 com uma proposta anterior, o mais próximo é o EIP-2938, e não o EIP-3074. EIP-2938 foi um avanço na abstração de contas, a primeira proposta para perceber a dificuldade de mitigação de DoS em um mempool AA. O ERC-4337 resolve certos problemas que o EIP-2938 não resolveu, mas uma comparação completa está fora do escopo deste documento.
Ambos resolvem a abstração de execução e, portanto, habilitam a última categoria dos casos de uso acima:
O EIP-5003 complementa o EIP-3074, permitindo que a EOA revogue sua chave ECDSA e se torne um contrato inteligente. Como contrato, pode abstrair o resto das funcionalidades da conta, por exemplo substituir ECDSA por uma assinatura diferente, alternar chaves, aplicar políticas de acesso, etc. Nesse sentido é um tanto equivalente a propostas como EIP-6913 e EIP-7377, mas é superior ao EIP-7377 porque como opcode pode utilizar um sistema de captação de gás para a própria migração.
Depois que o EOA for convertido em um contrato inteligente, ele não poderá mais ser negociado diretamente e precisará ser acessado por meio de outro EOA. Isto introduz o desafio que o ERC-4337 foi projetado para resolver. O usuário tem duas maneiras de realizar transações com a conta após a migração:
A forma de descentralizar o acesso à conta pós-migração é aplicar certas restrições até que a conta pague o gás. Esta abordagem foi adotada tanto pelo EIP-2938 quanto pelo ERC-4337. O<a href="https://notes.ethereum.org/ @yoav /unified-erc-4337-mempool">ERC-4337 mempool oferece uma forma descentralizada de transações com a conta.
TL;DR: Não, apenas destaca a necessidade do ERC-4337.
É tentador para os usuários EOA existentes migrar para uma conta inteligente local em vez de transferir ativos. No entanto, apresenta certas vulnerabilidades, algumas das quais não podem ser mitigadas.
O que poderia dar errado se a chave EOA fosse comprometida após ter sido revogada?
O usuário pode queimar a chave privada após a migração e esperar que nenhuma cópia seja deixada, mas o usuário também não pode reivindicar o mesmo endereço em outras cadeias.
Portanto, a migração deve ser usada como último recurso quando houver um forte motivo para manter o endereço antigo. Por padrão, novas contas são melhor implantadas com CREATE2 em vez de migradas de uma EOA, para que não sejam vinculadas a uma chave EOA em outras cadeias.
A comunidade tende a enfatizar excessivamente a importância da migração EOA porque a maioria dos utilizadores actuais têm EOAs. O próximo bilhão de usuários poderia começar com uma conta inteligente e não ter que migrar de uma EOA. Nós, os atuais usuários da EOA, somos uma pequena fração disso. A migração pode ser importante por um tempo, para os usuários atuais migrarem. Ele se tornará um fluxo raramente usado quando a abstração de contas for a norma.
Sim, eles poderiam ser <a href="https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy"> combinados de maneiras interessantes. Se uma rede adotar o EIP-3074, os projetos que utilizam o ERC-4337 poderão utilizá-lo em seu benefício.
Tanto o EIP-3074 quanto o ERC-4337 são etapas para obter alguns dos benefícios da abstração completa de contas nativas. O primeiro se concentra em obter todos os benefícios da abstração de execução e o último se concentra em obter todos os benefícios da abstração de contas em todas as cadeias EVM, mas de uma forma não nativa e menos eficiente.
Uma rede que deseja que seus usuários se beneficiem da abstração completa de contas nativas poderia adotar o RIP-7560. Ele usa a mesma arquitetura de conta e mempool do ERC-4337, mas funciona nativamente no nível do protocolo.
O RIP-7560 não precisa ser adotado desde o primeiro dia, e as contas existentes poderão migrar para ele nas redes que optarem por adotá-lo a qualquer momento no futuro:
Estamos coletando feedback sobre o RIP-7560 antes de propor sua consagração. Se você estiver interessado na abstração de contas nativas, revise o PR ou participe da discussão.