Cada conta Ethereum implementa cinco funcionalidades:
Um EOA implementa-os de uma 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 a EOA com lógica de execução arbitrária através de invocadores. Tem uma propriedade única - estender as capacidades de um EOA sem ter de migrar ativos para uma nova conta. Não precisa de resolver problemas como o acesso descentralizado porque a execução não afeta isso. As outras quatro funcionalidades sim, mas estão fora do âmbito 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 o DoS e os vetores de ataque de luto habilitados abstraindo as quatro primeiras funcionalidades sem recorrer a uma infraestrutura centralizada. Como ERC, não pode alargar 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: EIP-3074 visa servir os EOAs existentes e manter as coisas o mais simples possível. O ERC-4337 visa fornecer Abstração de Conta completa sem sacrificar as propriedades essenciais do Ethereum, como a descentralização.
Se alguém insistir em comparar o ERC-4337 com uma proposta anterior, o mais próximo é o EIP-2938, 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 num mempool AA. O ERC-4337 resolve certos problemas que o EIP-2938 não resolveu, mas uma comparação completa está fora do âmbito deste documento.
Ambos resolvem a abstração de execução e, portanto, permitem a última categoria dos casos de uso acima:
O EIP-5003 complementa o EIP-3074 deixando a EOA revogar a sua chave ECDSA e tornar-se um contrato inteligente. Como contrato, pode abstrair o resto das funcionalidades da conta, por ex. substituir o ECDSA por uma assinatura diferente, girar chaves, aplicar políticas de acesso, etc. Nesse sentido, é um pouco equivalente a propostas como EIP-6913 e EIP-7377 , mas é superior ao EIP-7377 porque, como opcode, pode usar um sistema de abstração de gás para a própria migração.
Uma vez que o EOA é convertido num contrato inteligente, deixa de poder transacionar diretamente e precisa de ser acedido através de outro EOA. Isto introduz o desafio que o ERC-4337 foi concebido para resolver. O utilizador tem duas formas de transacionar com a conta após a migração:
A maneira 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 como pelo ERC-4337. O < a href= " https://notes.ethereum.org/@yoav/unified-erc-4337-mempool " > ERC-4337 mempool oferece uma maneira descentralizada de transacionar com a conta.
TL; DR: Não, apenas destaca a necessidade de ERC-4337.
É tentador para os utilizadores existentes da EOA migrarem para uma conta inteligente no local em vez de transferir ativos. No entanto, vem com uma certa vulnerabilidade, algumas das quais não podem ser mitigadas.
O que pode correr mal se a chave EOA estiver comprometida depois de ter sido revogada?
O utilizador pode queimar a chave privada após a migração e esperar que não restem cópias, mas o utilizador também não pode reivindicar o mesmo endereço noutras cadeias.
Portanto, a migração deve ser usada como último recurso quando há uma forte razão para manter o endereço antigo. Por predefinição, é melhor implementar novas contas com CREATE2 em vez de migradas de uma EOA, para que não estejam ligadas a uma chave EOA noutras cadeias.
A comunidade tende a enfatizar demasiado a importância da migração de EOA porque a maioria dos utilizadores actuais tem EOAs. Os próximos mil milhões de utilizadores podem começar com uma conta inteligente e não ter de migrar de uma EOA. Nós, os actuais utilizadores da EOA, somos uma pequena fração disso. A migração pode ser importante durante algum tempo, para os utilizadores actuais migrarem. Vai tornar-se um fluxo raramente utilizado quando a abstração da conta for a norma.
Sim, podem ser < a href= " https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy " > combinados de formas interessantes. Se uma cadeia adoptar o EIP-3074, os projetos que utilizam o ERC-4337 poderão utilizá-lo em seu benefício.
Tanto o EIP-3074 como o ERC-4337 são passos para obter alguns dos benefícios da abstração completa da conta nativa. O primeiro concentra-se em obter todos os benefícios da abstração de execução e o segundo concentra-se em obter todos os benefícios da abstração de contas em todas as cadeias EVM mas de uma forma não nativa que seja menos eficiente.
Uma cadeia que deseje que os seus utilizadores beneficiem da abstração completa da conta nativa poderia adotar o RIP-7560. Usa a mesma arquitectura de conta e mempool que o ERC-4337 mas funciona nativamente ao nível do protocolo.
O RIP-7560 não tem de ser adotado a partir do primeiro dia e as contas existentes poderão migrar para ele em cadeias que optarem por adotá-lo a qualquer momento no futuro:
Estamos a recolher feedback sobre o RIP-7560 antes de propor consagrá-lo. Se está interessado na abstração da conta nativa, reveja o PR ou participe da discussão.
Partilhar
İçerik
Cada conta Ethereum implementa cinco funcionalidades:
Um EOA implementa-os de uma 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 a EOA com lógica de execução arbitrária através de invocadores. Tem uma propriedade única - estender as capacidades de um EOA sem ter de migrar ativos para uma nova conta. Não precisa de resolver problemas como o acesso descentralizado porque a execução não afeta isso. As outras quatro funcionalidades sim, mas estão fora do âmbito 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 o DoS e os vetores de ataque de luto habilitados abstraindo as quatro primeiras funcionalidades sem recorrer a uma infraestrutura centralizada. Como ERC, não pode alargar 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: EIP-3074 visa servir os EOAs existentes e manter as coisas o mais simples possível. O ERC-4337 visa fornecer Abstração de Conta completa sem sacrificar as propriedades essenciais do Ethereum, como a descentralização.
Se alguém insistir em comparar o ERC-4337 com uma proposta anterior, o mais próximo é o EIP-2938, 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 num mempool AA. O ERC-4337 resolve certos problemas que o EIP-2938 não resolveu, mas uma comparação completa está fora do âmbito deste documento.
Ambos resolvem a abstração de execução e, portanto, permitem a última categoria dos casos de uso acima:
O EIP-5003 complementa o EIP-3074 deixando a EOA revogar a sua chave ECDSA e tornar-se um contrato inteligente. Como contrato, pode abstrair o resto das funcionalidades da conta, por ex. substituir o ECDSA por uma assinatura diferente, girar chaves, aplicar políticas de acesso, etc. Nesse sentido, é um pouco equivalente a propostas como EIP-6913 e EIP-7377 , mas é superior ao EIP-7377 porque, como opcode, pode usar um sistema de abstração de gás para a própria migração.
Uma vez que o EOA é convertido num contrato inteligente, deixa de poder transacionar diretamente e precisa de ser acedido através de outro EOA. Isto introduz o desafio que o ERC-4337 foi concebido para resolver. O utilizador tem duas formas de transacionar com a conta após a migração:
A maneira 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 como pelo ERC-4337. O < a href= " https://notes.ethereum.org/@yoav/unified-erc-4337-mempool " > ERC-4337 mempool oferece uma maneira descentralizada de transacionar com a conta.
TL; DR: Não, apenas destaca a necessidade de ERC-4337.
É tentador para os utilizadores existentes da EOA migrarem para uma conta inteligente no local em vez de transferir ativos. No entanto, vem com uma certa vulnerabilidade, algumas das quais não podem ser mitigadas.
O que pode correr mal se a chave EOA estiver comprometida depois de ter sido revogada?
O utilizador pode queimar a chave privada após a migração e esperar que não restem cópias, mas o utilizador também não pode reivindicar o mesmo endereço noutras cadeias.
Portanto, a migração deve ser usada como último recurso quando há uma forte razão para manter o endereço antigo. Por predefinição, é melhor implementar novas contas com CREATE2 em vez de migradas de uma EOA, para que não estejam ligadas a uma chave EOA noutras cadeias.
A comunidade tende a enfatizar demasiado a importância da migração de EOA porque a maioria dos utilizadores actuais tem EOAs. Os próximos mil milhões de utilizadores podem começar com uma conta inteligente e não ter de migrar de uma EOA. Nós, os actuais utilizadores da EOA, somos uma pequena fração disso. A migração pode ser importante durante algum tempo, para os utilizadores actuais migrarem. Vai tornar-se um fluxo raramente utilizado quando a abstração da conta for a norma.
Sim, podem ser < a href= " https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy " > combinados de formas interessantes. Se uma cadeia adoptar o EIP-3074, os projetos que utilizam o ERC-4337 poderão utilizá-lo em seu benefício.
Tanto o EIP-3074 como o ERC-4337 são passos para obter alguns dos benefícios da abstração completa da conta nativa. O primeiro concentra-se em obter todos os benefícios da abstração de execução e o segundo concentra-se em obter todos os benefícios da abstração de contas em todas as cadeias EVM mas de uma forma não nativa que seja menos eficiente.
Uma cadeia que deseje que os seus utilizadores beneficiem da abstração completa da conta nativa poderia adotar o RIP-7560. Usa a mesma arquitectura de conta e mempool que o ERC-4337 mas funciona nativamente ao nível do protocolo.
O RIP-7560 não tem de ser adotado a partir do primeiro dia e as contas existentes poderão migrar para ele em cadeias que optarem por adotá-lo a qualquer momento no futuro:
Estamos a recolher feedback sobre o RIP-7560 antes de propor consagrá-lo. Se está interessado na abstração da conta nativa, reveja o PR ou participe da discussão.