Análise aprofundada da história e futuro da abstração de contas no Ethereum
Introdução
Este artigo é dividido em duas grandes partes:
A parte superior começa com a primeira proposta AA de 2015, sistematizando o conteúdo principal das propostas EIP até agora, com a esperança de explorar a evolução das propostas históricas de AA através de uma perspectiva histórica e avaliar abrangentemente as vantagens e desvantagens de cada solução.
A parte inferior foca na comparação da reação morna do mercado após o lançamento do EIP4337, analisando profundamente o EIP7702 que será incluído na próxima atualização da Ethereum. Uma vez que esta proposta seja mesclada, mudará completamente a forma das aplicações on-chain.
O EIP-7702 é de importância revolucionária, vamos explorar isso em detalhes juntos.
1. O contexto da abstração de contas
1.1 A importância da abstração de contas
O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, onde a configuração sobre a abstração de contas permanece inalterada. O modelo atual está a passar da EIP-4337 para a próxima fase "conversão voluntária de contas EOA".
Mais de um ano após o lançamento do EIP4337, no dia 1 de março de 2023, durante o WalletCon em Denver, foi anunciado oficialmente que o contrato central ERC-4337, desenvolvido por programadores da Fundação Ethereum, passou pela auditoria da OpenZeppelin e é considerado um marco histórico do lançamento oficial (. O mercado apresenta um estado contraditório de ampla aceitação pelos usuários, mas não de uso generalizado. Nesse ambiente, o progresso do EIP-7702 foi antecipado significativamente e foi confirmado que será incorporado na próxima atualização.
) 1.2 o estado atual do mercado de abstração de contas
Após um ano e meio de desenvolvimento, o número total de contas do EIP4337 nas cadeias principais é de apenas 12 milhões, dos quais há apenas 6.764 endereços ativos na rede principal do Ethereum, o que representa uma diferença significativa em relação ao número de endereços EOA e CA. O número de endereços independentes na rede principal do Ethereum já atingiu 270 milhões. Pode-se dizer que o EIP4337 praticamente não teve desenvolvimento substancial na rede principal.
No entanto, isso não afeta o valor essencial da abstração de contas (AA). O design do EIP4337 desde o início estava fadado a ter dificuldades em resolver os sérios problemas de compatibilidade retroativa da mainnet. Com várias cadeias L2 geralmente integrando AA nativa, o número de endereços EIP4337 explodiu nas L2, onde o número de usuários ativos mensais da Base e da Polygon atingiu 1 milhão e 3 milhões, respetivamente, o que é um desempenho razoável.
Portanto, não é que o design do EIP4337 esteja errado, ele tem muitas vantagens, que iremos resumir sistematicamente mais tarde. A situação atual resulta das diferenças entre a mainnet e o L2, que precisam de soluções adequadas a cada uma.
2. O que é a abstração de contas?
A abstração de contas resolve essencialmente o problema da separação de propriedade.
Na arquitetura EVM, existem dois tipos de contas: conta externa ### EOA ( e conta de contrato ) Contract Account (. A propriedade e o direito de assinatura da conta externa são, na realidade, detidos pela mesma entidade. A pessoa que possui a chave privada não só detém a "propriedade" da conta, mas também tem o direito de "assinar a transferência de todos os ativos".
Isto é determinado pela estrutura de transação da conta Ethereum. A partir da estrutura da transação, pode-se ver que a transação padrão do Ethereum não tem o campo From. Na verdade, é através dos parâmetros VRS ) que o usuário assina ( e o endereço From é obtido por reversão.
Isto envolve conceitos como ECDSA e funções de limiar unidirecionais, que não serão aprofundados aqui. Em suma, a segurança é garantida pela criptografia, o que também causou a atual dificuldade de consolidação da propriedade dos endereços EOA.
O efeito central do EIP4337 é adicionar o Endereço do Remetente no campo da transação, permitindo assim a separação entre a chave privada e o endereço operado.
A razão pela qual a separação de propriedade é tão importante é que o design da conta externa )EOA( gerará mais problemas:
Dificuldade em proteger a chave privada: a perda da chave privada ), ataques de hackers ou a quebra de criptografia ( significam a perda de todos os ativos.
Algoritmo de assinatura único: A verificação de transações do protocolo nativo só pode usar o algoritmo de assinatura e verificação ECDSA.
Permissões de assinatura excessivas: a multi-assinatura nativa ) só pode ser implementada através de contrato inteligente (, uma única assinatura pode executar qualquer operação.
As taxas de transação só podem ser pagas em ETH, não suportam transações em lote.
Divulgação de privacidade de transações: negociações um a um tornam fácil analisar as informações de privacidade dos detentores de conta.
Essas limitações tornam difícil para usuários comuns utilizarem o Ethereum:
Primeiro, ao usar qualquer aplicativo na Ethereum, os usuários devem possuir Éter ) e assumir o risco de volatilidade de preços (.
Em segundo lugar, os usuários precisam lidar com uma lógica de taxas complexa, preço do Gas, limite do Gas, bloqueio de transações ) ordem do Nonce ( e outros conceitos que são demasiado complexos para os usuários.
Por último, embora muitas carteiras ou aplicações de blockchain tentem melhorar a experiência do usuário através da otimização de produtos, os resultados são limitados.
Portanto, a chave está em implementar a abstração de contas, desacoplando a propriedade )Owner( e o direito de assinatura )Signer(, resolvendo gradualmente os problemas mencionados acima.
Historicamente, várias propostas foram apresentadas, que acabaram convergindo para duas rotas.
![Análise profunda da abstração de contas do Ethereum: passado e futuro])https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp(
3. Análise do histórico das propostas de AA
) 3.1 Primeiro caminho: transformar o endereço EOA em endereço CA
No dia 15 de novembro de 2015, Vitalik propôs uma nova estrutura de contas como contratos no EIP-101. A mudança do endereço para conter apenas código e espaço de armazenamento, alterando o suporte a taxas de transação para ser pago por ERC20, através de contratos pré-compilados que transformam o token nativo em um saldo semelhante ao ERC20 ###, com funções como autorização de débito automático (, e simplificando os campos da transação para to, startgas, data e code.
Esta proposta pode ser vista como uma transformação estilo Grande Salto, que mudará significativamente o design subjacente, permitindo que cada endereço de conta tenha sua própria lógica "código" ), que é precisamente o efeito que o EIP-7702 pretende alcançar (.
Ele também pode derivar outras funções, como:
As transações utilizam mais algoritmos de criptografia, podendo o método de verificação e autenticação ser especificado pelo código interno de cada endereço.
Possui características de resistência a ataques quânticos, pois o código é atualizável.
Permitir que o Éter possua características funcionais consistentes com os contratos ERC20, com o efeito principal de implementar a autorização de dedução, sem a necessidade de consumir a moeda nativa.
Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte a SBT, recuperação de chaves, etc.
A razão pela qual não se conseguiu avançar é simples: claramente, o passo foi demasiado grande, e não se consideraram adequadamente os problemas atuais de colisão de hash nas transações e as preocupações com a segurança, por isso ficou sempre em suspenso. No entanto, cada conceito positivo tornou-se uma das funções centrais das subsequentes EIP4337 e EIP7702.
Depois, houve uma série de EIPs que tentaram aprimorar essa lógica:
EIP-859: abstração de contas da cadeia principal )2018-01-30(
Tentando resolver o problema de implantação de Código, a função principal é que, se o contrato da parte transacional não estiver implantado, será utilizado o parâmetro code anexado à transação para executar a implantação da carteira do contrato. Em segundo lugar, foi proposto um novo código de operação PAYGAS, que além de pagar o gas, também serve como um delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.
Embora não tenha sido implementado na época, isso se tornou uma das lógicas centrais do EIP7702. Cada transação do EIP7702, combinada com uma estrutura de transação especial, pode incluir um determinado código, permitindo assim que endereços EOA tenham capacidade de contrato durante esta transação.
EIP-7702: definir código de conta EOA )2024-05-07(
Este também é o núcleo do mecanismo de discussão subsequente deste artigo, proposto por Vitalik como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi descontinuado, e o EIP-7702 será incluído no próximo fork hard ETH Prague/Electra)Pectra(, cujos detalhes iremos expandir mais adiante.
) 3.2 Segunda rota: deixar o endereço EOA conduzir o endereço CA
EIP-3074: adicionar os códigos de operação AUTH e AUTHCALL ###2020-10-15(
Adicionar dois novos OpCodes AUTH e AUTHCALL no EVM, permitindo que a EOA autorize contratos a chamar outros contratos em vez da identidade da EOA através desses dois opcodes.
Em resumo, uma EOA pode enviar uma mensagem assinada ) e uma transação ( para um contrato ) em que confia, chamado de Invoker (. Este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para substituir a EOA no envio da transação.
EIP-4337: implementação de abstração de contas com o pool de memórias de transações )2021-09-29(
Inspirado pelo MEV, seu valor central é que pode evitar completamente alterações no protocolo da camada de consenso.
O EIP4337 propõe um novo objeto de transação chamado UserOperation, que os usuários enviam para o pool de memórias, onde os bundlers agrupam e entregam em massa as transações de execução de contratos do ponto de vista dos mineradores, essencialmente levando as transações subjacentes e a operação de contas para serem executadas a nível de contrato.
EIP-5189: operação de conta abstrata através de endossantes )2022-06-29(
Esta é uma otimização da lógica do EIP4337, enfrentando Bundlers maliciosos através do estabelecimento de um mecanismo de endossamento de penalização financeira para prevenir ataques de bloqueio DoS.
) 3.3 Outras propostas que suportam a abstração de contas
EIP-2718: embalagem de novos tipos de transação ###2020-06-13(
Esta é uma proposta que já está Final, definindo um novo tipo de transação, como um envelope para futuros tipos de transação a serem adicionados.
O efeito final é que, ao introduzir novos tipos de transações, é necessário diferenciar os tipos de transações através de uma codificação específica, precisando apenas de compatibilidade retroativa, sem necessidade de compatibilidade para a frente. O exemplo mais comum é o EIP1559, que diferencia as taxas de transação, utilizando uma nova codificação de tipo de transação, sem afetar o tipo de transação legada original.
EIP-3607: proibição de endereços EOA de implantar contratos )2021-06-10(
Esta é uma solução complementar na rota AA, utilizada para evitar conflitos entre o endereço de implantação do contrato e o endereço EOA. Ela controlará o método de geração do contrato, proibindo o sistema de implantar o código em um endereço que já seja um endereço EOA. Este risco é, na verdade, muito pequeno, uma vez que os endereços Ethereum têm 160 bits de comprimento; embora exista um método para colidir a chave privada para gerar a chave privada de um endereço de contrato específico, estima-se que, com o poder de computação total da rede Bitcoin, levaria um ano.
) 3.4 Como entender a evolução da abstração de contas?
Primeiro é necessário entender o valor após a conversão para CA.
Basicamente, é o efeito prático do EIP-4337, que pode realizar:
No entanto, a principal desvantagem do EIP-4337 é contrariar o princípio da motivação humana.
Parece melhor, mas caiu em um ciclo vicioso de desenvolvimento de mercado, muitos Dapps ainda não são compatíveis, os usuários relutam em usar endereços de CA, e até mesmo usar CA pode ter um custo de transação mais alto ### em cenários de transferência comuns, as taxas de transação dobram (, além de depender demais da compatibilidade do próprio Dapp.
Portanto, ainda não se popularizou na rede principal do Ethereum.
O custo é o critério mais importante para os usuários, e deve ser reduzido.
Mas para realmente reduzir o GAS, é necessário realizar um upgrade de soft fork na própria Ethereum, modificando o cálculo de GAS ou o consumo de GAS de módulos como códigos de operação. Já que vamos fazer um soft fork, por que não considerar diretamente o EIP-7702?
![Análise aprofundada da trajetória da abstração de contas do Ethereum: passado e futuro])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
4. Análise Completa do EIP-7702
) 4.1 O que é EIP-7702
Ele diferencia através de novos tipos de transações, permitindo que EOA tenha temporariamente funções de contrato inteligente em uma única transação, apoiando assim transações em lote, transações sem Gas e gerenciamento de permissões personalizadas, sem a necessidade de introduzir um novo EVM opCode### que impacte a compatibilidade para frente(.
Ele permite que os usuários obtenham a maior parte das capacidades de AA sem a necessidade de implantar contratos inteligentes, podendo até oferecer a capacidade de um terceiro iniciar transações em nome do usuário, sem que o usuário precise fornecer a chave privada, bastando assinar a autorização.
) 4.2 estrutura de dados
Ele define um novo tipo de transação 0x04, cujo TransactionPayload é o resultado da serialização RLP do seguinte conteúdo:
É importante mencionar que foi adicionado um objeto authorization_list, que armazena o código que o signatário deseja executar na sua EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado, que existe como uma lista bidimensional, indicando que pode armazenar várias informações de operações em lote e executar operações em lote.
Na fase inicial da execução da transação, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:
A partir da assinatura r, s, utilize ecrecover para recuperar o endereço do assinante ###. Note que este é um mecanismo da própria Ethereum, portanto, este EIP não altera o algoritmo de assinatura (.
authority = ecrecover)keccak(MAGIC || rlp(chain_id, address, nonce, y_parity, r, s]) semelhante ao endereço from obtido anteriormente a partir da assinatura, aqui obtém-se o endereço da assinatura parcial para esta lista(
Verificar a ID da cadeia ) para evitar a reprodução da cadeia de bifurcação (.
Verifique se o código do signatário authority está vazio ou se já foi delegado ).
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.
9 Curtidas
Recompensa
9
4
Compartilhar
Comentário
0/400
AirdropHunter9000
· 08-06 05:33
Há mais um grande acontecimento: o V神 está a fazer algo grande.
Ver originalResponder0
0xSherlock
· 08-06 05:28
Ocupa um banco e vê primeiro.
Ver originalResponder0
WalletDivorcer
· 08-06 05:24
Outra proposta destinada ao fracasso chegou.
Ver originalResponder0
SundayDegen
· 08-06 05:22
Pintar um grande BTC no vazio... será que realmente pode ser usado?
EIP-7702: grande avanço na abstração de contas Ethereum
Análise aprofundada da história e futuro da abstração de contas no Ethereum
Introdução
Este artigo é dividido em duas grandes partes:
A parte superior começa com a primeira proposta AA de 2015, sistematizando o conteúdo principal das propostas EIP até agora, com a esperança de explorar a evolução das propostas históricas de AA através de uma perspectiva histórica e avaliar abrangentemente as vantagens e desvantagens de cada solução.
A parte inferior foca na comparação da reação morna do mercado após o lançamento do EIP4337, analisando profundamente o EIP7702 que será incluído na próxima atualização da Ethereum. Uma vez que esta proposta seja mesclada, mudará completamente a forma das aplicações on-chain.
O EIP-7702 é de importância revolucionária, vamos explorar isso em detalhes juntos.
1. O contexto da abstração de contas
1.1 A importância da abstração de contas
O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, onde a configuração sobre a abstração de contas permanece inalterada. O modelo atual está a passar da EIP-4337 para a próxima fase "conversão voluntária de contas EOA".
Mais de um ano após o lançamento do EIP4337, no dia 1 de março de 2023, durante o WalletCon em Denver, foi anunciado oficialmente que o contrato central ERC-4337, desenvolvido por programadores da Fundação Ethereum, passou pela auditoria da OpenZeppelin e é considerado um marco histórico do lançamento oficial (. O mercado apresenta um estado contraditório de ampla aceitação pelos usuários, mas não de uso generalizado. Nesse ambiente, o progresso do EIP-7702 foi antecipado significativamente e foi confirmado que será incorporado na próxima atualização.
) 1.2 o estado atual do mercado de abstração de contas
Após um ano e meio de desenvolvimento, o número total de contas do EIP4337 nas cadeias principais é de apenas 12 milhões, dos quais há apenas 6.764 endereços ativos na rede principal do Ethereum, o que representa uma diferença significativa em relação ao número de endereços EOA e CA. O número de endereços independentes na rede principal do Ethereum já atingiu 270 milhões. Pode-se dizer que o EIP4337 praticamente não teve desenvolvimento substancial na rede principal.
No entanto, isso não afeta o valor essencial da abstração de contas (AA). O design do EIP4337 desde o início estava fadado a ter dificuldades em resolver os sérios problemas de compatibilidade retroativa da mainnet. Com várias cadeias L2 geralmente integrando AA nativa, o número de endereços EIP4337 explodiu nas L2, onde o número de usuários ativos mensais da Base e da Polygon atingiu 1 milhão e 3 milhões, respetivamente, o que é um desempenho razoável.
Portanto, não é que o design do EIP4337 esteja errado, ele tem muitas vantagens, que iremos resumir sistematicamente mais tarde. A situação atual resulta das diferenças entre a mainnet e o L2, que precisam de soluções adequadas a cada uma.
2. O que é a abstração de contas?
A abstração de contas resolve essencialmente o problema da separação de propriedade.
Na arquitetura EVM, existem dois tipos de contas: conta externa ### EOA ( e conta de contrato ) Contract Account (. A propriedade e o direito de assinatura da conta externa são, na realidade, detidos pela mesma entidade. A pessoa que possui a chave privada não só detém a "propriedade" da conta, mas também tem o direito de "assinar a transferência de todos os ativos".
Isto é determinado pela estrutura de transação da conta Ethereum. A partir da estrutura da transação, pode-se ver que a transação padrão do Ethereum não tem o campo From. Na verdade, é através dos parâmetros VRS ) que o usuário assina ( e o endereço From é obtido por reversão.
Isto envolve conceitos como ECDSA e funções de limiar unidirecionais, que não serão aprofundados aqui. Em suma, a segurança é garantida pela criptografia, o que também causou a atual dificuldade de consolidação da propriedade dos endereços EOA.
O efeito central do EIP4337 é adicionar o Endereço do Remetente no campo da transação, permitindo assim a separação entre a chave privada e o endereço operado.
A razão pela qual a separação de propriedade é tão importante é que o design da conta externa )EOA( gerará mais problemas:
Dificuldade em proteger a chave privada: a perda da chave privada ), ataques de hackers ou a quebra de criptografia ( significam a perda de todos os ativos.
Algoritmo de assinatura único: A verificação de transações do protocolo nativo só pode usar o algoritmo de assinatura e verificação ECDSA.
Permissões de assinatura excessivas: a multi-assinatura nativa ) só pode ser implementada através de contrato inteligente (, uma única assinatura pode executar qualquer operação.
As taxas de transação só podem ser pagas em ETH, não suportam transações em lote.
Divulgação de privacidade de transações: negociações um a um tornam fácil analisar as informações de privacidade dos detentores de conta.
Essas limitações tornam difícil para usuários comuns utilizarem o Ethereum:
Primeiro, ao usar qualquer aplicativo na Ethereum, os usuários devem possuir Éter ) e assumir o risco de volatilidade de preços (.
Em segundo lugar, os usuários precisam lidar com uma lógica de taxas complexa, preço do Gas, limite do Gas, bloqueio de transações ) ordem do Nonce ( e outros conceitos que são demasiado complexos para os usuários.
Por último, embora muitas carteiras ou aplicações de blockchain tentem melhorar a experiência do usuário através da otimização de produtos, os resultados são limitados.
Portanto, a chave está em implementar a abstração de contas, desacoplando a propriedade )Owner( e o direito de assinatura )Signer(, resolvendo gradualmente os problemas mencionados acima.
Historicamente, várias propostas foram apresentadas, que acabaram convergindo para duas rotas.
![Análise profunda da abstração de contas do Ethereum: passado e futuro])https://img-cdn.gateio.im/webp-social/moments-cecbf67df71971d38b0a927be5e4c4d9.webp(
3. Análise do histórico das propostas de AA
) 3.1 Primeiro caminho: transformar o endereço EOA em endereço CA
No dia 15 de novembro de 2015, Vitalik propôs uma nova estrutura de contas como contratos no EIP-101. A mudança do endereço para conter apenas código e espaço de armazenamento, alterando o suporte a taxas de transação para ser pago por ERC20, através de contratos pré-compilados que transformam o token nativo em um saldo semelhante ao ERC20 ###, com funções como autorização de débito automático (, e simplificando os campos da transação para to, startgas, data e code.
Esta proposta pode ser vista como uma transformação estilo Grande Salto, que mudará significativamente o design subjacente, permitindo que cada endereço de conta tenha sua própria lógica "código" ), que é precisamente o efeito que o EIP-7702 pretende alcançar (.
Ele também pode derivar outras funções, como:
As transações utilizam mais algoritmos de criptografia, podendo o método de verificação e autenticação ser especificado pelo código interno de cada endereço.
Possui características de resistência a ataques quânticos, pois o código é atualizável.
Permitir que o Éter possua características funcionais consistentes com os contratos ERC20, com o efeito principal de implementar a autorização de dedução, sem a necessidade de consumir a moeda nativa.
Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte a SBT, recuperação de chaves, etc.
A razão pela qual não se conseguiu avançar é simples: claramente, o passo foi demasiado grande, e não se consideraram adequadamente os problemas atuais de colisão de hash nas transações e as preocupações com a segurança, por isso ficou sempre em suspenso. No entanto, cada conceito positivo tornou-se uma das funções centrais das subsequentes EIP4337 e EIP7702.
Depois, houve uma série de EIPs que tentaram aprimorar essa lógica:
EIP-859: abstração de contas da cadeia principal )2018-01-30(
Tentando resolver o problema de implantação de Código, a função principal é que, se o contrato da parte transacional não estiver implantado, será utilizado o parâmetro code anexado à transação para executar a implantação da carteira do contrato. Em segundo lugar, foi proposto um novo código de operação PAYGAS, que além de pagar o gas, também serve como um delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.
Embora não tenha sido implementado na época, isso se tornou uma das lógicas centrais do EIP7702. Cada transação do EIP7702, combinada com uma estrutura de transação especial, pode incluir um determinado código, permitindo assim que endereços EOA tenham capacidade de contrato durante esta transação.
EIP-7702: definir código de conta EOA )2024-05-07(
Este também é o núcleo do mecanismo de discussão subsequente deste artigo, proposto por Vitalik como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi descontinuado, e o EIP-7702 será incluído no próximo fork hard ETH Prague/Electra)Pectra(, cujos detalhes iremos expandir mais adiante.
) 3.2 Segunda rota: deixar o endereço EOA conduzir o endereço CA
EIP-3074: adicionar os códigos de operação AUTH e AUTHCALL ###2020-10-15(
Adicionar dois novos OpCodes AUTH e AUTHCALL no EVM, permitindo que a EOA autorize contratos a chamar outros contratos em vez da identidade da EOA através desses dois opcodes.
Em resumo, uma EOA pode enviar uma mensagem assinada ) e uma transação ( para um contrato ) em que confia, chamado de Invoker (. Este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para substituir a EOA no envio da transação.
EIP-4337: implementação de abstração de contas com o pool de memórias de transações )2021-09-29(
Inspirado pelo MEV, seu valor central é que pode evitar completamente alterações no protocolo da camada de consenso.
O EIP4337 propõe um novo objeto de transação chamado UserOperation, que os usuários enviam para o pool de memórias, onde os bundlers agrupam e entregam em massa as transações de execução de contratos do ponto de vista dos mineradores, essencialmente levando as transações subjacentes e a operação de contas para serem executadas a nível de contrato.
EIP-5189: operação de conta abstrata através de endossantes )2022-06-29(
Esta é uma otimização da lógica do EIP4337, enfrentando Bundlers maliciosos através do estabelecimento de um mecanismo de endossamento de penalização financeira para prevenir ataques de bloqueio DoS.
) 3.3 Outras propostas que suportam a abstração de contas
EIP-2718: embalagem de novos tipos de transação ###2020-06-13(
Esta é uma proposta que já está Final, definindo um novo tipo de transação, como um envelope para futuros tipos de transação a serem adicionados.
O efeito final é que, ao introduzir novos tipos de transações, é necessário diferenciar os tipos de transações através de uma codificação específica, precisando apenas de compatibilidade retroativa, sem necessidade de compatibilidade para a frente. O exemplo mais comum é o EIP1559, que diferencia as taxas de transação, utilizando uma nova codificação de tipo de transação, sem afetar o tipo de transação legada original.
EIP-3607: proibição de endereços EOA de implantar contratos )2021-06-10(
Esta é uma solução complementar na rota AA, utilizada para evitar conflitos entre o endereço de implantação do contrato e o endereço EOA. Ela controlará o método de geração do contrato, proibindo o sistema de implantar o código em um endereço que já seja um endereço EOA. Este risco é, na verdade, muito pequeno, uma vez que os endereços Ethereum têm 160 bits de comprimento; embora exista um método para colidir a chave privada para gerar a chave privada de um endereço de contrato específico, estima-se que, com o poder de computação total da rede Bitcoin, levaria um ano.
) 3.4 Como entender a evolução da abstração de contas?
Primeiro é necessário entender o valor após a conversão para CA.
Basicamente, é o efeito prático do EIP-4337, que pode realizar:
No entanto, a principal desvantagem do EIP-4337 é contrariar o princípio da motivação humana.
Parece melhor, mas caiu em um ciclo vicioso de desenvolvimento de mercado, muitos Dapps ainda não são compatíveis, os usuários relutam em usar endereços de CA, e até mesmo usar CA pode ter um custo de transação mais alto ### em cenários de transferência comuns, as taxas de transação dobram (, além de depender demais da compatibilidade do próprio Dapp.
Portanto, ainda não se popularizou na rede principal do Ethereum.
O custo é o critério mais importante para os usuários, e deve ser reduzido.
Mas para realmente reduzir o GAS, é necessário realizar um upgrade de soft fork na própria Ethereum, modificando o cálculo de GAS ou o consumo de GAS de módulos como códigos de operação. Já que vamos fazer um soft fork, por que não considerar diretamente o EIP-7702?
![Análise aprofundada da trajetória da abstração de contas do Ethereum: passado e futuro])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(
4. Análise Completa do EIP-7702
) 4.1 O que é EIP-7702
Ele diferencia através de novos tipos de transações, permitindo que EOA tenha temporariamente funções de contrato inteligente em uma única transação, apoiando assim transações em lote, transações sem Gas e gerenciamento de permissões personalizadas, sem a necessidade de introduzir um novo EVM opCode### que impacte a compatibilidade para frente(.
Ele permite que os usuários obtenham a maior parte das capacidades de AA sem a necessidade de implantar contratos inteligentes, podendo até oferecer a capacidade de um terceiro iniciar transações em nome do usuário, sem que o usuário precise fornecer a chave privada, bastando assinar a autorização.
) 4.2 estrutura de dados
Ele define um novo tipo de transação 0x04, cujo TransactionPayload é o resultado da serialização RLP do seguinte conteúdo:
rlp###[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s](
É importante mencionar que foi adicionado um objeto authorization_list, que armazena o código que o signatário deseja executar na sua EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado, que existe como uma lista bidimensional, indicando que pode armazenar várias informações de operações em lote e executar operações em lote.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
) 4.3 ciclo de vida da transação
4.3.1 Fase de Verificação
Na fase inicial da execução da transação, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:
A partir da assinatura r, s, utilize ecrecover para recuperar o endereço do assinante ###. Note que este é um mecanismo da própria Ethereum, portanto, este EIP não altera o algoritmo de assinatura (. authority = ecrecover)keccak(MAGIC || rlp(chain_id, address, nonce, y_parity, r, s]) semelhante ao endereço from obtido anteriormente a partir da assinatura, aqui obtém-se o endereço da assinatura parcial para esta lista(
Verificar a ID da cadeia ) para evitar a reprodução da cadeia de bifurcação (.
Verifique se o código do signatário authority está vazio ou se já foi delegado ).