Profundidade da análise da evolução histórica da abstração de contas do Ethereum e perspectivas futuras
Introdução
Este artigo irá explorar a evolução da abstração de contas Ethereum (AA) sob dois aspectos principais:
Primeiro, iremos rastrear o contexto histórico desde a primeira proposta AA em 2015, sistematicamente organizar o conteúdo principal das várias propostas EIP até o momento, explorar profundamente o processo de evolução da proposta AA e realizar uma avaliação abrangente das vantagens e desvantagens de cada proposta.
Em segundo lugar, vamos analisar as razões para a reação fraca do mercado após o lançamento do EIP4337 e explorar em profundidade o EIP7702, que será incluído nas futuras atualizações do Ethereum. Uma vez que esta proposta seja incorporada, irá mudar fundamentalmente a forma das aplicações em cadeia.
A EIP-7702 é considerada uma revolução histórica, vamos explorar juntos os seus mistérios.
1. A background da abstração de contas
1.1 a localização do significado da abstração de contas
O fundador do Ethereum atualizou recentemente o roteiro de desenvolvimento do ETH, mas a configuraçã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".
Apesar de já ter passado mais de um ano desde o lançamento do EIP4337, a reação do mercado é bastante contraditória - os usuários reconhecem amplamente o seu valor, mas a taxa de utilização real não é alta. Neste contexto, o progresso do EIP-7702 foi significativamente antecipado e já foi confirmado que será integrado na próxima atualização.
1.2 A situação 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 nas principais cadeias públicas, dos quais apenas 6.764 são endereços ativos na rede principal do Ethereum, muito aquém do 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, o que demonstra que o EIP4337 não teve praticamente nenhum avanço substancial na rede principal.
No entanto, isso não significa que o valor intrínseco da AA seja afetado. O design do EIP4337 torna difícil resolver adequadamente o problema de compatibilidade retroativa da mainnet. Com a integração generalizada de vários L2s com a AA nativa, o número de endereços do EIP4337 teve um crescimento explosivo nos L2s, com o número de usuários ativos mensais da Base e da Polygon em julho alcançando 1 milhão e 3 milhões, respectivamente, o que é bastante considerável.
Portanto, o problema não está no design do EIP4337, mas sim nas diferenças entre a mainnet e a L2, que necessitam de soluções adequadas a cada uma.
2. O que é abstração de contas?
A abstração de contas resolve essencialmente o problema da separação de propriedade.
Na arquitetura da Máquina Virtual Ethereum ( EVM ), existem dois tipos de contas: contas externas ( EOA ) e contas de contrato ( Contract Account ). Na EOA, a propriedade e o direito de assinatura da conta são detidos pela mesma entidade. A pessoa que possui a chave privada não apenas possui a "propriedade" da conta, mas também tem o direito de "assinar a transferência de todos os ativos".
Esta característica é determinada pela estrutura de transações da conta Ethereum. Na estrutura de transações padrão do Ethereum, na verdade, não existe o campo From. O endereço da parte que inicia a transação é obtido através do parâmetro VRS (, ou seja, é obtido pela reversão da assinatura do usuário ).
Este design, embora garanta a segurança através da criptografia, também levou à atual dificuldade de fusã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 a ser operado.
A razão pela qual a separação de propriedade é tão importante é que o design do EOA gera muitos problemas:
A chave privada é difícil de proteger: perder a chave privada significa perder todos os ativos.
Algoritmo de assinatura único: o protocolo nativo suporta apenas o algoritmo de assinatura e verificação ECDSA.
Permissão de assinatura muito alta: sem suporte nativo a múltiplas assinaturas, uma única assinatura pode executar qualquer operação.
A taxa de transação só pode ser paga em ETH, não suporta transações em massa.
A privacidade das transações é facilmente divulgada: as transações um a um facilitam a análise das informações dos titulares das contas.
Estas limitações tornam difícil para os utilizadores comuns usar o Ethereum:
Primeiro, os usuários devem possuir Éter ( e assumir o risco de volatilidade de preços ) para usar as aplicações na Ethereum.
Em segundo lugar, os usuários precisam lidar com lógicas de taxas complexas, como preço do Gas, limite do Gas, bloqueio de transações ( ordem do Nonce ) e conceitos semelhantes que são demasiado complexos para os usuários.
Por fim, embora muitas carteiras ou aplicações de blockchain tentem melhorar a experiência do utilizador através da otimização de produtos, os resultados são limitados.
Portanto, a chave para superar a dificuldade reside na implementação da abstração de contas, desacoplando a propriedade (Owner) e o direito de assinatura (Signer), resolvendo assim gradualmente os problemas mencionados.
Historicamente, foram propostas várias soluções, que acabaram por convergir em duas principais direções.
3. Revisão do contexto das propostas de abstração de contas
A solução para o problema parece ter várias propostas de EIP, mas no fundo, existem apenas duas linhas de pensamento principais. Cada um dos problemas considerados nas EIPs que não foram aprovadas acabou por convergir para os pontos de ruptura das soluções existentes.
3.1 Primeira rota: transformar o endereço EOA em endereço CA
Em novembro de 2015, Vitalik propôs uma nova estrutura de conta baseada em contratos no EIP-101. Esta proposta sugere que o endereço contenha apenas código e espaço de armazenamento, suportando o pagamento de taxas com tokens ERC20, transformando o token nativo em um token semelhante ao ERC20 ( com funcionalidades como autorização de débito ), e simplificando os campos de transação para conter apenas to, startgas, data e code.
Esta solução pode ser considerada uma mudança revolucionária, que irá alterar significativamente o design subjacente, fazendo com que cada endereço de conta tenha a sua própria lógica de "código" (, que é exatamente o efeito que o atual EIP-7702 pretende alcançar ).
Ele também pode derivar outras funcionalidades, como:
Suporte a transações usando mais algoritmos de criptografia, com os métodos de verificação e autenticação especificados pelo código interno de cada endereço.
Possui características de resistência a ataques quânticos, pois o código pode ser atualizado.
Conferir ao Éter as mesmas características funcionais que os contratos ERC20, permitindo a autorização de dedução sem consumir a moeda nativa.
Aumentar o espaço de personalização da conta, suportando recuperação social, SBT, recuperação de chaves e outras funcionalidades.
A razão pela qual este plano não pôde ser avançado é simples: os passos foram demasiado grandes, e as questões de conflito de hash de transação e de segurança na época não foram consideradas devidamente, por isso foi sempre adiado. No entanto, cada uma das suas vantagens e conceitos tornou-se uma das funcionalidades centrais do EIP4337 e EIP7702.
Após isso, houve uma série de EIPs que tentaram aprimorar essa lógica:
EIP-859: abstração de contas da cadeia principal (2018-01-30)
Esta proposta tenta resolver o problema de implantação do código. A sua função principal é que, quando o contrato da parte transacionadora não está implantado, utiliza o parâmetro code anexado à transação para executar a implantação da carteira do contrato. Além disso, foi proposta uma nova opcode PAYGAS, que além de pagar gas, 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 realizado na época, essa ideia se tornou uma das lógicas centrais do atual EIP7702. Cada transação do EIP7702, combinada com uma estrutura de transação especial, pode incluir um certo código, permitindo que o endereço EOA tenha capacidade de contrato nesta transação.
EIP-7702: configurar o código da conta EOA (2024-05-07)
Este é o EIP central que será discutido na sequência deste artigo, proposto por Vitalik, como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi abandonado, e o EIP-7702 será incluído no próximo hard fork ETH Prague/Electra(Pectra), cujos detalhes iremos desenvolver mais adiante.
3.2 Segunda rota: permitir que o endereço EOA dirija o endereço CA
EIP-3074: adicionar os códigos de operação AUTH e AUTHCALL (2020-10-15)
A proposta sugere adicionar dois novos códigos de operação AUTH e AUTHCALL no EVM, permitindo que EOA autorize contratos a chamar outros contratos em vez da identidade EOA através desses dois códigos de operação.
Em resumo, uma EOA pode enviar uma mensagem assinada ( transação ) para um contrato de sua confiança ( chamado Invoker ), e esse contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para enviar transações em vez dessa EOA.
EIP-4337: implementar a abstração de contas com o pool de memórias de transação (2021-09-29)
Esta proposta foi concebida com base no MEV, e o seu valor central reside na completa evitação de alterações ao protocolo da camada de consenso.
O EIP-4337 propôs um novo objeto de transação chamado UserOperation, que os usuários enviam para a pool de memória, onde os bundlers, do ponto de vista dos mineradores, empacotam em massa e entregam as transações para execução de contratos, essencialmente elevando as transações de nível inferior e a operação de contas para serem executadas em nível de contrato.
EIP-5189: através da operação de endossantes da abstração de contas (2022-06-29)
Isto pode ser visto como uma otimização da lógica do EIP4337, através da criação de um mecanismo de endosse de penalização de fundos (endorser) para evitar ataques de bloqueio DoS maliciosos por parte de Bundlers.
3.3 Outras propostas que suportam a abstração de contas
EIP-2718: envelope de nova tipo de transação (2020-06-13)
Esta é uma proposta que já foi finalizada, que define um novo tipo de transação, atuando como um envelope para futuros tipos de transação a serem adicionados.
O efeito final é que, ao introduzir novos tipos de transações, é possível distinguir diferentes tipos de transações através de uma codificação específica, permitindo assim considerar apenas a compatibilidade retroativa, sem necessidade 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, sem afetar o tipo de transação legacy original.
EIP-3607: proibição de endereços EOA de implantar contratos (2021-06-10)
Esta é uma solução complementar no caminho AA, destinada a evitar conflitos entre endereços de implantação de contratos e endereços EOA. Ela controlará o método de geração de contratos, proibindo o sistema de implantar código em endereços que já são endereços EOA. Este risco é, na verdade, muito pequeno, considerando que os endereços Ethereum têm até 160 bits. Embora exista um método que utiliza a colisão de chaves privadas para gerar uma chave privada de um endereço de contrato específico, mesmo utilizando toda a capacidade de mineração da rede Bitcoin, estima-se que levaria um ano.
3.4 Como entender a evolução da abstração de contas?
Primeiro, é necessário entender o valor convertido para CA.
Este é basicamente o efeito prático do EIP-4337, que pode realizar:
Suporte para múltiplas assinaturas e recuperação social
Suporte a transações em lote
Suporte para pagamento de taxas de gas com tokens ERC20
Suporte a limites de transação
Suporte a transações sem gas ( para pagamento de gas )
Suporte à abstração de contas ( para alternar entre carteiras quentes e frias )
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 do 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 gerar custos de transação mais altos ( em cenários de transferências comuns, as taxas de transação podem dobrar ), dependendo excessivamente da compatibilidade do próprio Dapp.
Esta é a razão pela qual ainda não se popularizou na rede principal do Ethereum.
O custo é o critério de medição mais importante para os usuários, e deve ser reduzido.
Mas para realmente reduzir o GAS, é necessário realizar uma atualização de bifurcação suave no próprio Ethereum, modificando o cálculo de GAS ou o consumo de GAS dos códigos de operação, entre outros módulos. Já que vamos fazer uma bifurcação suave, por que não considerar diretamente o EIP-7702?
4. Análise abrangente do EIP-7702
4.1 Introdução ao EIP-7702
Esta proposta permite que, ao introduzir novos tipos de transações, as EOA tenham temporariamente a funcionalidade de contratos inteligentes em uma única transação, suportando operações comerciais como transações em lote, transações sem Gas e gestão de permissões personalizadas, sem a necessidade de introduzir um novo opCode EVM ( que afete a compatibilidade retroativa ).
Isso permite que os usuários obtenham a maior parte das capacidades de AA sem precisar implantar contratos inteligentes, e até suporta terceiros para iniciar transações em nome dos usuários, sem que estes precisem fornecer a chave privada, bastando assinar as informações de autorização.
4.2 Estruturas de Dados
EIP-7702 define um novo tipo de transação 0x04, cujo TransactionPayload é o resultado da serialização RLP do seguinte conteúdo:
O novo objeto authorization_list armazena o código que os signatários desejam executar em sua EOA. O usuário assina a transação ao mesmo tempo que assina o que deve ser executado.
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.
12 Curtidas
Recompensa
12
5
Compartilhar
Comentário
0/400
CryptoPunster
· 20h atrás
7702 já chegou, 4337 ainda não subiu à terra.
Ver originalResponder0
RektRecovery
· 08-01 17:29
meh... outra proposta AA que provavelmente será rekt como a 4337 foi. estou a chamá-lo agora
Ver originalResponder0
BearMarketNoodler
· 08-01 17:26
A nova proposta finalmente chegou, o 4337 ainda não está quente.
EIP-7702: Um novo marco na abstração de contas do Ethereum e desenvolvimento futuro
Profundidade da análise da evolução histórica da abstração de contas do Ethereum e perspectivas futuras
Introdução
Este artigo irá explorar a evolução da abstração de contas Ethereum (AA) sob dois aspectos principais:
Primeiro, iremos rastrear o contexto histórico desde a primeira proposta AA em 2015, sistematicamente organizar o conteúdo principal das várias propostas EIP até o momento, explorar profundamente o processo de evolução da proposta AA e realizar uma avaliação abrangente das vantagens e desvantagens de cada proposta.
Em segundo lugar, vamos analisar as razões para a reação fraca do mercado após o lançamento do EIP4337 e explorar em profundidade o EIP7702, que será incluído nas futuras atualizações do Ethereum. Uma vez que esta proposta seja incorporada, irá mudar fundamentalmente a forma das aplicações em cadeia.
A EIP-7702 é considerada uma revolução histórica, vamos explorar juntos os seus mistérios.
1. A background da abstração de contas
1.1 a localização do significado da abstração de contas
O fundador do Ethereum atualizou recentemente o roteiro de desenvolvimento do ETH, mas a configuraçã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".
Apesar de já ter passado mais de um ano desde o lançamento do EIP4337, a reação do mercado é bastante contraditória - os usuários reconhecem amplamente o seu valor, mas a taxa de utilização real não é alta. Neste contexto, o progresso do EIP-7702 foi significativamente antecipado e já foi confirmado que será integrado na próxima atualização.
1.2 A situação 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 nas principais cadeias públicas, dos quais apenas 6.764 são endereços ativos na rede principal do Ethereum, muito aquém do 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, o que demonstra que o EIP4337 não teve praticamente nenhum avanço substancial na rede principal.
No entanto, isso não significa que o valor intrínseco da AA seja afetado. O design do EIP4337 torna difícil resolver adequadamente o problema de compatibilidade retroativa da mainnet. Com a integração generalizada de vários L2s com a AA nativa, o número de endereços do EIP4337 teve um crescimento explosivo nos L2s, com o número de usuários ativos mensais da Base e da Polygon em julho alcançando 1 milhão e 3 milhões, respectivamente, o que é bastante considerável.
Portanto, o problema não está no design do EIP4337, mas sim nas diferenças entre a mainnet e a L2, que necessitam de soluções adequadas a cada uma.
2. O que é abstração de contas?
A abstração de contas resolve essencialmente o problema da separação de propriedade.
Na arquitetura da Máquina Virtual Ethereum ( EVM ), existem dois tipos de contas: contas externas ( EOA ) e contas de contrato ( Contract Account ). Na EOA, a propriedade e o direito de assinatura da conta são detidos pela mesma entidade. A pessoa que possui a chave privada não apenas possui a "propriedade" da conta, mas também tem o direito de "assinar a transferência de todos os ativos".
Esta característica é determinada pela estrutura de transações da conta Ethereum. Na estrutura de transações padrão do Ethereum, na verdade, não existe o campo From. O endereço da parte que inicia a transação é obtido através do parâmetro VRS (, ou seja, é obtido pela reversão da assinatura do usuário ).
Este design, embora garanta a segurança através da criptografia, também levou à atual dificuldade de fusã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 a ser operado.
A razão pela qual a separação de propriedade é tão importante é que o design do EOA gera muitos problemas:
A chave privada é difícil de proteger: perder a chave privada significa perder todos os ativos.
Algoritmo de assinatura único: o protocolo nativo suporta apenas o algoritmo de assinatura e verificação ECDSA.
Permissão de assinatura muito alta: sem suporte nativo a múltiplas assinaturas, uma única assinatura pode executar qualquer operação.
A taxa de transação só pode ser paga em ETH, não suporta transações em massa.
A privacidade das transações é facilmente divulgada: as transações um a um facilitam a análise das informações dos titulares das contas.
Estas limitações tornam difícil para os utilizadores comuns usar o Ethereum:
Primeiro, os usuários devem possuir Éter ( e assumir o risco de volatilidade de preços ) para usar as aplicações na Ethereum.
Em segundo lugar, os usuários precisam lidar com lógicas de taxas complexas, como preço do Gas, limite do Gas, bloqueio de transações ( ordem do Nonce ) e conceitos semelhantes que são demasiado complexos para os usuários.
Por fim, embora muitas carteiras ou aplicações de blockchain tentem melhorar a experiência do utilizador através da otimização de produtos, os resultados são limitados.
Portanto, a chave para superar a dificuldade reside na implementação da abstração de contas, desacoplando a propriedade (Owner) e o direito de assinatura (Signer), resolvendo assim gradualmente os problemas mencionados.
Historicamente, foram propostas várias soluções, que acabaram por convergir em duas principais direções.
3. Revisão do contexto das propostas de abstração de contas
A solução para o problema parece ter várias propostas de EIP, mas no fundo, existem apenas duas linhas de pensamento principais. Cada um dos problemas considerados nas EIPs que não foram aprovadas acabou por convergir para os pontos de ruptura das soluções existentes.
3.1 Primeira rota: transformar o endereço EOA em endereço CA
Em novembro de 2015, Vitalik propôs uma nova estrutura de conta baseada em contratos no EIP-101. Esta proposta sugere que o endereço contenha apenas código e espaço de armazenamento, suportando o pagamento de taxas com tokens ERC20, transformando o token nativo em um token semelhante ao ERC20 ( com funcionalidades como autorização de débito ), e simplificando os campos de transação para conter apenas to, startgas, data e code.
Esta solução pode ser considerada uma mudança revolucionária, que irá alterar significativamente o design subjacente, fazendo com que cada endereço de conta tenha a sua própria lógica de "código" (, que é exatamente o efeito que o atual EIP-7702 pretende alcançar ).
Ele também pode derivar outras funcionalidades, como:
Suporte a transações usando mais algoritmos de criptografia, com os métodos de verificação e autenticação especificados pelo código interno de cada endereço.
Possui características de resistência a ataques quânticos, pois o código pode ser atualizado.
Conferir ao Éter as mesmas características funcionais que os contratos ERC20, permitindo a autorização de dedução sem consumir a moeda nativa.
Aumentar o espaço de personalização da conta, suportando recuperação social, SBT, recuperação de chaves e outras funcionalidades.
A razão pela qual este plano não pôde ser avançado é simples: os passos foram demasiado grandes, e as questões de conflito de hash de transação e de segurança na época não foram consideradas devidamente, por isso foi sempre adiado. No entanto, cada uma das suas vantagens e conceitos tornou-se uma das funcionalidades centrais do EIP4337 e EIP7702.
Após isso, houve uma série de EIPs que tentaram aprimorar essa lógica:
EIP-859: abstração de contas da cadeia principal (2018-01-30)
Esta proposta tenta resolver o problema de implantação do código. A sua função principal é que, quando o contrato da parte transacionadora não está implantado, utiliza o parâmetro code anexado à transação para executar a implantação da carteira do contrato. Além disso, foi proposta uma nova opcode PAYGAS, que além de pagar gas, 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 realizado na época, essa ideia se tornou uma das lógicas centrais do atual EIP7702. Cada transação do EIP7702, combinada com uma estrutura de transação especial, pode incluir um certo código, permitindo que o endereço EOA tenha capacidade de contrato nesta transação.
EIP-7702: configurar o código da conta EOA (2024-05-07)
Este é o EIP central que será discutido na sequência deste artigo, proposto por Vitalik, como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi abandonado, e o EIP-7702 será incluído no próximo hard fork ETH Prague/Electra(Pectra), cujos detalhes iremos desenvolver mais adiante.
3.2 Segunda rota: permitir que o endereço EOA dirija o endereço CA
EIP-3074: adicionar os códigos de operação AUTH e AUTHCALL (2020-10-15)
A proposta sugere adicionar dois novos códigos de operação AUTH e AUTHCALL no EVM, permitindo que EOA autorize contratos a chamar outros contratos em vez da identidade EOA através desses dois códigos de operação.
Em resumo, uma EOA pode enviar uma mensagem assinada ( transação ) para um contrato de sua confiança ( chamado Invoker ), e esse contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para enviar transações em vez dessa EOA.
EIP-4337: implementar a abstração de contas com o pool de memórias de transação (2021-09-29)
Esta proposta foi concebida com base no MEV, e o seu valor central reside na completa evitação de alterações ao protocolo da camada de consenso.
O EIP-4337 propôs um novo objeto de transação chamado UserOperation, que os usuários enviam para a pool de memória, onde os bundlers, do ponto de vista dos mineradores, empacotam em massa e entregam as transações para execução de contratos, essencialmente elevando as transações de nível inferior e a operação de contas para serem executadas em nível de contrato.
EIP-5189: através da operação de endossantes da abstração de contas (2022-06-29)
Isto pode ser visto como uma otimização da lógica do EIP4337, através da criação de um mecanismo de endosse de penalização de fundos (endorser) para evitar ataques de bloqueio DoS maliciosos por parte de Bundlers.
3.3 Outras propostas que suportam a abstração de contas
EIP-2718: envelope de nova tipo de transação (2020-06-13)
Esta é uma proposta que já foi finalizada, que define um novo tipo de transação, atuando como um envelope para futuros tipos de transação a serem adicionados.
O efeito final é que, ao introduzir novos tipos de transações, é possível distinguir diferentes tipos de transações através de uma codificação específica, permitindo assim considerar apenas a compatibilidade retroativa, sem necessidade 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, sem afetar o tipo de transação legacy original.
EIP-3607: proibição de endereços EOA de implantar contratos (2021-06-10)
Esta é uma solução complementar no caminho AA, destinada a evitar conflitos entre endereços de implantação de contratos e endereços EOA. Ela controlará o método de geração de contratos, proibindo o sistema de implantar código em endereços que já são endereços EOA. Este risco é, na verdade, muito pequeno, considerando que os endereços Ethereum têm até 160 bits. Embora exista um método que utiliza a colisão de chaves privadas para gerar uma chave privada de um endereço de contrato específico, mesmo utilizando toda a capacidade de mineração da rede Bitcoin, estima-se que levaria um ano.
3.4 Como entender a evolução da abstração de contas?
Primeiro, é necessário entender o valor convertido para CA.
Este é 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 do 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 gerar custos de transação mais altos ( em cenários de transferências comuns, as taxas de transação podem dobrar ), dependendo excessivamente da compatibilidade do próprio Dapp.
Esta é a razão pela qual ainda não se popularizou na rede principal do Ethereum.
O custo é o critério de medição mais importante para os usuários, e deve ser reduzido.
Mas para realmente reduzir o GAS, é necessário realizar uma atualização de bifurcação suave no próprio Ethereum, modificando o cálculo de GAS ou o consumo de GAS dos códigos de operação, entre outros módulos. Já que vamos fazer uma bifurcação suave, por que não considerar diretamente o EIP-7702?
4. Análise abrangente do EIP-7702
4.1 Introdução ao EIP-7702
Esta proposta permite que, ao introduzir novos tipos de transações, as EOA tenham temporariamente a funcionalidade de contratos inteligentes em uma única transação, suportando operações comerciais como transações em lote, transações sem Gas e gestão de permissões personalizadas, sem a necessidade de introduzir um novo opCode EVM ( que afete a compatibilidade retroativa ).
Isso permite que os usuários obtenham a maior parte das capacidades de AA sem precisar implantar contratos inteligentes, e até suporta terceiros para iniciar transações em nome dos usuários, sem que estes precisem fornecer a chave privada, bastando assinar as informações de autorização.
4.2 Estruturas de Dados
EIP-7702 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, destino, valor, dados, access_list, lista_de_autorização, signature_y_parity, assinatura_r, assinatura_s ])
O novo objeto authorization_list armazena o código que os signatários desejam executar em sua EOA. O usuário assina a transação ao mesmo tempo que assina o que deve ser executado.