Análise profunda da abstração de contas do Ethereum: passado e futuro
Introdução
Este artigo é dividido em duas partes principais:
A primeira parte começa com a proposta AA de 2015, sistematiza o conteúdo das principais propostas EIP até o momento, explora o desenvolvimento histórico das propostas AA e fornece uma avaliação abrangente de cada proposta.
A segunda parte foca na comparação das reações do mercado após o lançamento do EIP4337, bem como na análise aprofundada do EIP7702, que será integrado na próxima atualização do Ethereum. Uma vez que esta proposta seja mesclada, irá transformar completamente a forma de aplicação na cadeia.
EIP-7702 tem um significado revolucionário, vamos nos aprofundar juntos.
1. Background da abstração de contas
1.1 Significado da abstração de contas
O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, mas a posição sobre a abstração de contas não mudou. O modelo principal atual está a transitar de EIP-4337 para a próxima fase de "conversão voluntária de contas EOA".
1.2 O estado atual do mercado de abstração de contas
Após um ano e meio de desenvolvimento, o EIP4337 tem apenas 12 milhões de endereços totais nas principais blockchains, dos quais apenas 6.764 estão ativos na rede principal do Ethereum, 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á alcançou 270 milhões, podendo-se dizer que o EIP4337 está se desenvolvendo lentamente na rede principal.
No entanto, isso não afeta o valor essencial do AA. O design do EIP4337 destina-se a dificultar a compatibilidade retroativa na mainnet. Com a incorporação generalizada de diversas cadeias L2 na AA nativa, o número de endereços do EIP4337 teve um crescimento explosivo nas L2, com a atividade mensal de julho nas cadeias Base e Polygon atingindo 1 milhão e 3 milhões, respetivamente, um desempenho notável.
Portanto, o design do EIP4337 não é um erro, ele tem várias vantagens. 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 é essencialmente uma solução para o problema da separação da propriedade.
Na arquitetura EVM, existem dois tipos de contas: conta externa ( EOA ) e conta de contrato ( CA ). Na conta externa, a propriedade e os direitos de assinatura são detidos pela mesma entidade. A pessoa que possui a chave privada não só possui 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ções da conta Ethereum. A partir da estrutura da transação, pode-se ver que uma transação padrão na verdade não possui o campo From. Quando ocorre a transferência de fundos, o endereço específico consumido é obtido por meio do parâmetro VRS (, ou seja, a assinatura do usuário ) é desfeita.
E o efeito principal do EIP4337 é que ele adiciona o Endereço do Remetente no campo da transação, permitindo assim a separação entre a chave privada e o endereço sendo operado.
A razão pela qual a separação de propriedade é tão importante é que o design da conta externa (EOA) gera muitos problemas:
Difícil de proteger a chave privada: perder a chave privada significa perder todos os ativos.
Algoritmo de assinatura único: a verificação de transações do protocolo nativo só pode usar o algoritmo ECDSA.
Permissão de assinatura muito alta: sem funcionalidade nativa de múltiplas assinaturas, uma única assinatura pode executar qualquer operação.
A taxa de transação só pode ser paga em Éter, não suporta transações em massa.
A privacidade das transações pode ser facilmente revelada: transações um a um facilitam a análise das informações dos titulares de contas.
Essas limitações tornam difícil para usuários comuns utilizarem Ethereum:
Primeiro, os usuários devem manter Éter e assumir o risco de volatilidade dos preços.
Em segundo lugar, os usuários precisam lidar com lógicas de taxas complexas, como o preço do Gas, limite de Gas, bloqueio de transações e outros conceitos.
Por fim, as carteiras ou aplicações de blockchain tentam melhorar a experiência do utilizador através da otimização de produtos, mas os resultados são limitados.
Portanto, a solução reside na implementação da abstração de contas, desconectando a propriedade (Owner) e o direito de assinatura (Signer), resolvendo assim gradualmente os problemas mencionados.
Historicamente, houve várias propostas, que acabaram por se resumir a duas rotas.
3. Contextualização das propostas históricas de AA
A solução para o problema parece ter muitas propostas de EIP, mas no fundo, são apenas duas abordagens principais. Cada questão considerada por um EIP não aprovado convergiu para os pontos de ruptura das soluções existentes.
3.1 Primeira rota: mudar o endereço EOA para endereço CA
Em novembro de 2015, Vitalik propôs uma nova estrutura de conta como contrato no EIP-101. A mudança do endereço para conter apenas código e espaço de armazenamento, suportando pagamentos de taxas em ERC20, e através de contratos pré-compilados, a conversão de tokens nativos para saldo de classe ERC20, simplificando os campos da transação para to, startgas, data e code.
Esta proposta pode ser considerada uma revolução de grande salto, que irá alterar significativamente o design subjacente, permitindo que cada endereço de conta tenha sua própria lógica de "código". ( é exatamente o efeito que o EIP-7702 pretende alcançar. ).
Ele também pode derivar outras funcionalidades, como:
Permitir que as transações utilizem mais algoritmos de criptografia, com o método de verificação e autenticação 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 tenha funcionalidades consistentes com contratos ERC20, como autorização de dedução.
Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte a SBT, recuperação de chave, entre outros.
O motivo pelo qual não continuamos a avançar é principalmente porque demos um passo grande demais, não consideramos adequadamente o problema atual de colisão de hash nas transações e as preocupações de segurança, mas cada conceito positivo se tornou uma das funcionalidades centrais das EIP4337 e EIP7702.
Após isso, há uma série de EIPs que tentam aprimorar essa lógica:
EIP-859: abstração de contas da cadeia principal (2018-01-30)
Tentando resolver o problema de implantação do código. A função principal é que, se o contrato da parte transacionadora não estiver implantado, usa-se o parâmetro de código anexado à transação para executar a implantação da carteira de contrato. Também foi proposto um novo opcode PAYGAS, que além de pagar o gás, também serve como delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.
Embora não tenha sido bem-sucedido na época, isso se tornou um dos 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 que o endereço EOA tenha capacidade de contrato nesta transação.
EIP-7702: definir o código da conta EOA (2024-05-07)
Este é o EIP central da discussão posterior deste artigo, proposto por Vitalik como uma alternativa ao EIP-3074. O EIP-3074 foi descartado, e o EIP-7702 será incluído no próximo hard fork ETH Prague/Electra(Pectra).
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 OpCode ao EVM: AUTH e AUTHCALL, permitindo que EOA autorize contratos a chamar outros contratos em vez da identidade EOA através desses dois opcodes.
Em resumo, um EOA pode enviar uma mensagem assinada ( para um contrato de sua confiança ) chamado Invoker (. Este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para emitir transações em vez do EOA.
EIP-4337: implementar a abstração de contas na memória de transações )2021-09-29(
Inspirado pelo MEV, o valor central é 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 movendo as transações de base e a operação da conta para serem executadas ao nível do contrato.
EIP-5189: através da operação de endossante abstração de contas )2022-06-29(
Esta é uma otimização da lógica do EIP4337, através da criação de um mecanismo de endosse de penalização de fundos para prevenir ataques de bloqueio DoS maliciosos por parte dos Bundlers.
) 3.3 Outras propostas que suportam a abstração de contas
EIP-2718: envelope de embalagem para novos tipos de transações ###2020-06-13(
Esta é uma proposta já finalizada, 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 um novo tipo de transação, a distinção entre os tipos de transação é feita através de uma codificação específica, necessitando apenas de compatibilidade retroativa, sem precisar de compatibilidade para frente. O exemplo mais comum é o EIP1559, que distingue as taxas de transação, utilizando uma nova codificação de tipo de transação, mas não afeta o tipo de transação legacy original.
EIP-3607: impedir que o endereço EOA implemente contratos )2021-06-10(
Esta é uma solução complementar para o caminho AA, usada 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 de contratos, não permitindo que o código seja implantado em endereços que já são endereços EOA. Este risco é na verdade muito pequeno, o endereço Ethereum tem 160 bits de comprimento, e 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 isso levaria um ano de investimento total de poder de cálculo do Bitcoin.
) 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 real do EIP-4337:
Suporte a transações em lote
Suporte à recuperação social
Suporte à validação de assinatura personalizada
Não é necessário pagar taxas de transação com tokens nativos
Gestão de permissões mais granular
Escalabilidade
No entanto, a principal desvantagem do EIP-4337 é que contraria o princípio dos motivos humanos.
Parece melhor, mas caiu em um ciclo vicioso de desenvolvimento de mercado: muitas Dapps ainda não são compatíveis, os usuários não querem usar endereços CA, e usar CA resulta em custos de transação mais altos ### em cenários de transferência comuns, as taxas de transação dobram (, dependência excessiva da compatibilidade das próprias Dapps.
Portanto, ainda não se popularizou na rede principal do Ethereum.
O custo é o critério de medição mais importante para os usuários, deve-se reduzir o custo.
Mas para realmente reduzir o GAS, é necessário que a própria Ethereum faça um upgrade de soft fork, modificando o cálculo de GAS ou módulos de consumo de GAS dos códigos de operação. Já que vamos fazer um soft fork, por que não considerar diretamente o EIP-7702?
![Análise profunda do passado e futuro da abstração de contas do Ethereum])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. Análise Completa do EIP-7702
) 4.1 O que é EIP-7702
Ele permite que EOA tenha temporariamente funcionalidades de contrato inteligente em uma única transação através de um novo tipo de transação, suportando transações em lote, transações sem Gas e gerenciamento de permissões personalizadas, sem a necessidade de introduzir um novo EVM opCode### que afete a compatibilidade retroativa(.
Os usuários podem obter a maioria das capacidades de AA sem a necessidade de implantar contratos inteligentes, podendo até fornecer a capacidade de iniciar transações em nome dos usuários por terceiros, sem que os usuários precisem fornecer chaves privadas, apenas assinando informações de autorização.
) 4.2 estrutura de dados
Definir um novo tipo de transação 0x04, TransactionPayload é o resultado da serialização RLP do seguinte conteúdo:
É importante notar que foi adicionado o objeto authorization_list, que armazena o código que o signatário deseja executar em sua EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado, existindo como uma lista bidimensional, podendo armazenar várias informações de operação, permitindo a execução de operações em lote.
Quando a execução da transação começa, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:
Recuperar o endereço do signatário a partir dos valores de assinatura r e s usando ecrecover.
Verificar o ID da cadeia ### para evitar a reprodução de cadeias bifurcadas (.
Verifique se o código do signatário da autoridade está vazio ou foi delegado.
Verificar o nonce do assinante authority ) para prevenir a reprodução da assinatura authority (.
Defina o código do signatário authority como 0xef0100 || address) para contornar a estratégia de prevenção de colisões EIP3607 (.
Aumentar o nonce dos signatários de authority ) para evitar a reprodução de assinaturas locais (.
Adicione a conta do assinante authority à lista de endereços acessados ) para o endereço de transferência, reduzindo o custo do gás de armazenamento de consulta (.
)# 4.3.2 Fase de execução da operação
A nova versão apenas alterou o comportamento de implantação do código.
Não definir mais account_code como contract_code, mas sim recuperar o código especificado pelo address da authorization_list e definir como account_code.
Ao executar o código autorizado, carregue o código do campo address da authorization_list, executando no contexto da conta do signatário.
Isso significa que o código do contrato do usuário é armazenado em um endereço específico na cadeia, em vez de estar diretamente incluído na transação.
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.
11 Curtidas
Recompensa
11
7
Compartilhar
Comentário
0/400
LiquidationWizard
· 07-25 01:53
Que diabos o 7702 está fazendo agora?
Ver originalResponder0
GasWaster
· 07-24 18:03
meu Deus, outro eip... gastei 2eth em txs falhadas no ano passado e agora eles me dizem isso?
Ver originalResponder0
EntryPositionAnalyst
· 07-24 15:19
AA voltou a ter popularidade depois de poucos dias.
Ver originalResponder0
MetaMuskRat
· 07-22 06:03
Já se começa a falar de AA novamente, provavelmente é o velho vinho em nova garrafa da Blockchain.
EIP-7702 vai remodelar o ecossistema Ethereum. A abstração de contas entra numa nova era.
Análise profunda da abstração de contas do Ethereum: passado e futuro
Introdução
Este artigo é dividido em duas partes principais:
A primeira parte começa com a proposta AA de 2015, sistematiza o conteúdo das principais propostas EIP até o momento, explora o desenvolvimento histórico das propostas AA e fornece uma avaliação abrangente de cada proposta.
A segunda parte foca na comparação das reações do mercado após o lançamento do EIP4337, bem como na análise aprofundada do EIP7702, que será integrado na próxima atualização do Ethereum. Uma vez que esta proposta seja mesclada, irá transformar completamente a forma de aplicação na cadeia.
EIP-7702 tem um significado revolucionário, vamos nos aprofundar juntos.
1. Background da abstração de contas
1.1 Significado da abstração de contas
O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, mas a posição sobre a abstração de contas não mudou. O modelo principal atual está a transitar de EIP-4337 para a próxima fase de "conversão voluntária de contas EOA".
1.2 O estado atual do mercado de abstração de contas
Após um ano e meio de desenvolvimento, o EIP4337 tem apenas 12 milhões de endereços totais nas principais blockchains, dos quais apenas 6.764 estão ativos na rede principal do Ethereum, 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á alcançou 270 milhões, podendo-se dizer que o EIP4337 está se desenvolvendo lentamente na rede principal.
No entanto, isso não afeta o valor essencial do AA. O design do EIP4337 destina-se a dificultar a compatibilidade retroativa na mainnet. Com a incorporação generalizada de diversas cadeias L2 na AA nativa, o número de endereços do EIP4337 teve um crescimento explosivo nas L2, com a atividade mensal de julho nas cadeias Base e Polygon atingindo 1 milhão e 3 milhões, respetivamente, um desempenho notável.
Portanto, o design do EIP4337 não é um erro, ele tem várias vantagens. 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 é essencialmente uma solução para o problema da separação da propriedade.
Na arquitetura EVM, existem dois tipos de contas: conta externa ( EOA ) e conta de contrato ( CA ). Na conta externa, a propriedade e os direitos de assinatura são detidos pela mesma entidade. A pessoa que possui a chave privada não só possui 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ções da conta Ethereum. A partir da estrutura da transação, pode-se ver que uma transação padrão na verdade não possui o campo From. Quando ocorre a transferência de fundos, o endereço específico consumido é obtido por meio do parâmetro VRS (, ou seja, a assinatura do usuário ) é desfeita.
E o efeito principal do EIP4337 é que ele adiciona o Endereço do Remetente no campo da transação, permitindo assim a separação entre a chave privada e o endereço sendo operado.
A razão pela qual a separação de propriedade é tão importante é que o design da conta externa (EOA) gera muitos problemas:
Difícil de proteger a chave privada: perder a chave privada significa perder todos os ativos.
Algoritmo de assinatura único: a verificação de transações do protocolo nativo só pode usar o algoritmo ECDSA.
Permissão de assinatura muito alta: sem funcionalidade nativa de múltiplas assinaturas, uma única assinatura pode executar qualquer operação.
A taxa de transação só pode ser paga em Éter, não suporta transações em massa.
A privacidade das transações pode ser facilmente revelada: transações um a um facilitam a análise das informações dos titulares de contas.
Essas limitações tornam difícil para usuários comuns utilizarem Ethereum:
Primeiro, os usuários devem manter Éter e assumir o risco de volatilidade dos preços.
Em segundo lugar, os usuários precisam lidar com lógicas de taxas complexas, como o preço do Gas, limite de Gas, bloqueio de transações e outros conceitos.
Por fim, as carteiras ou aplicações de blockchain tentam melhorar a experiência do utilizador através da otimização de produtos, mas os resultados são limitados.
Portanto, a solução reside na implementação da abstração de contas, desconectando a propriedade (Owner) e o direito de assinatura (Signer), resolvendo assim gradualmente os problemas mencionados.
Historicamente, houve várias propostas, que acabaram por se resumir a duas rotas.
3. Contextualização das propostas históricas de AA
A solução para o problema parece ter muitas propostas de EIP, mas no fundo, são apenas duas abordagens principais. Cada questão considerada por um EIP não aprovado convergiu para os pontos de ruptura das soluções existentes.
3.1 Primeira rota: mudar o endereço EOA para endereço CA
Em novembro de 2015, Vitalik propôs uma nova estrutura de conta como contrato no EIP-101. A mudança do endereço para conter apenas código e espaço de armazenamento, suportando pagamentos de taxas em ERC20, e através de contratos pré-compilados, a conversão de tokens nativos para saldo de classe ERC20, simplificando os campos da transação para to, startgas, data e code.
Esta proposta pode ser considerada uma revolução de grande salto, que irá alterar significativamente o design subjacente, permitindo que cada endereço de conta tenha sua própria lógica de "código". ( é exatamente o efeito que o EIP-7702 pretende alcançar. ).
Ele também pode derivar outras funcionalidades, como:
Permitir que as transações utilizem mais algoritmos de criptografia, com o método de verificação e autenticação 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 tenha funcionalidades consistentes com contratos ERC20, como autorização de dedução.
Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte a SBT, recuperação de chave, entre outros.
O motivo pelo qual não continuamos a avançar é principalmente porque demos um passo grande demais, não consideramos adequadamente o problema atual de colisão de hash nas transações e as preocupações de segurança, mas cada conceito positivo se tornou uma das funcionalidades centrais das EIP4337 e EIP7702.
Após isso, há uma série de EIPs que tentam aprimorar essa lógica:
EIP-859: abstração de contas da cadeia principal (2018-01-30)
Tentando resolver o problema de implantação do código. A função principal é que, se o contrato da parte transacionadora não estiver implantado, usa-se o parâmetro de código anexado à transação para executar a implantação da carteira de contrato. Também foi proposto um novo opcode PAYGAS, que além de pagar o gás, também serve como delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.
Embora não tenha sido bem-sucedido na época, isso se tornou um dos 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 que o endereço EOA tenha capacidade de contrato nesta transação.
EIP-7702: definir o código da conta EOA (2024-05-07)
Este é o EIP central da discussão posterior deste artigo, proposto por Vitalik como uma alternativa ao EIP-3074. O EIP-3074 foi descartado, e o EIP-7702 será incluído no próximo hard fork ETH Prague/Electra(Pectra).
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 OpCode ao EVM: AUTH e AUTHCALL, permitindo que EOA autorize contratos a chamar outros contratos em vez da identidade EOA através desses dois opcodes.
Em resumo, um EOA pode enviar uma mensagem assinada ( para um contrato de sua confiança ) chamado Invoker (. Este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para emitir transações em vez do EOA.
EIP-4337: implementar a abstração de contas na memória de transações )2021-09-29(
Inspirado pelo MEV, o valor central é 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 movendo as transações de base e a operação da conta para serem executadas ao nível do contrato.
EIP-5189: através da operação de endossante abstração de contas )2022-06-29(
Esta é uma otimização da lógica do EIP4337, através da criação de um mecanismo de endosse de penalização de fundos para prevenir ataques de bloqueio DoS maliciosos por parte dos Bundlers.
) 3.3 Outras propostas que suportam a abstração de contas
EIP-2718: envelope de embalagem para novos tipos de transações ###2020-06-13(
Esta é uma proposta já finalizada, 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 um novo tipo de transação, a distinção entre os tipos de transação é feita através de uma codificação específica, necessitando apenas de compatibilidade retroativa, sem precisar de compatibilidade para frente. O exemplo mais comum é o EIP1559, que distingue as taxas de transação, utilizando uma nova codificação de tipo de transação, mas não afeta o tipo de transação legacy original.
EIP-3607: impedir que o endereço EOA implemente contratos )2021-06-10(
Esta é uma solução complementar para o caminho AA, usada 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 de contratos, não permitindo que o código seja implantado em endereços que já são endereços EOA. Este risco é na verdade muito pequeno, o endereço Ethereum tem 160 bits de comprimento, e 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 isso levaria um ano de investimento total de poder de cálculo do Bitcoin.
) 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 real do EIP-4337:
No entanto, a principal desvantagem do EIP-4337 é que contraria o princípio dos motivos humanos.
Parece melhor, mas caiu em um ciclo vicioso de desenvolvimento de mercado: muitas Dapps ainda não são compatíveis, os usuários não querem usar endereços CA, e usar CA resulta em custos de transação mais altos ### em cenários de transferência comuns, as taxas de transação dobram (, dependência excessiva da compatibilidade das próprias Dapps.
Portanto, ainda não se popularizou na rede principal do Ethereum.
O custo é o critério de medição mais importante para os usuários, deve-se reduzir o custo.
Mas para realmente reduzir o GAS, é necessário que a própria Ethereum faça um upgrade de soft fork, modificando o cálculo de GAS ou módulos de consumo de GAS dos códigos de operação. Já que vamos fazer um soft fork, por que não considerar diretamente o EIP-7702?
![Análise profunda do passado e futuro da abstração de contas do Ethereum])https://img-cdn.gateio.im/webp-social/moments-9d6eae95e3a0983a7b379ce2cfd7945f.webp(
4. Análise Completa do EIP-7702
) 4.1 O que é EIP-7702
Ele permite que EOA tenha temporariamente funcionalidades de contrato inteligente em uma única transação através de um novo tipo de transação, suportando transações em lote, transações sem Gas e gerenciamento de permissões personalizadas, sem a necessidade de introduzir um novo EVM opCode### que afete a compatibilidade retroativa(.
Os usuários podem obter a maioria das capacidades de AA sem a necessidade de implantar contratos inteligentes, podendo até fornecer a capacidade de iniciar transações em nome dos usuários por terceiros, sem que os usuários precisem fornecer chaves privadas, apenas assinando informações de autorização.
) 4.2 estrutura de dados
Definir um novo tipo de transação 0x04, 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 notar que foi adicionado o objeto authorization_list, que armazena o código que o signatário deseja executar em sua EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado, existindo como uma lista bidimensional, podendo armazenar várias informações de operação, permitindo a execução de 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
Quando a execução da transação começa, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:
)# 4.3.2 Fase de execução da operação
A nova versão apenas alterou o comportamento de implantação do código.
Não definir mais account_code como contract_code, mas sim recuperar o código especificado pelo address da authorization_list e definir como account_code.
Ao executar o código autorizado, carregue o código do campo address da authorization_list, executando no contexto da conta do signatário.
Isso significa que o código do contrato do usuário é armazenado em um endereço específico na cadeia, em vez de estar diretamente incluído na transação.