Análise aprofundada do passado e futuro da abstração de contas do Ethereum

Introdução

Este artigo é dividido em dois grandes módulos:

A parte superior começa com a primeira proposta AA de 2015, o sistema organizou o conteúdo das principais propostas EIP até agora, revisou o histórico de propostas AA e fez uma avaliação abrangente das vantagens e desvantagens de cada proposta.

A parte inferior concentra-se na comparação das respostas de mercado insatisfatórias enfrentadas após o lançamento do EIP4337, analisando profundamente o EIP7702 que será incluído na próxima atualização do Ethereum; uma vez integrado, esta proposta mudará completamente a forma das aplicações on-chain.

O EIP-7702 tem um significado revolucionário, vamos detalhar isso.

1. Abstração de contas

1.1 a localização do 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 configuração para a abstração de contas não mudou. Atualmente, o modelo dominante está passando da EIP-4337 para a próxima fase de Conversão VoluntaryEOA (, a conversão voluntária de contas EOA ).

1.2 O estado do mercado da abstração de contas

Após um ano e meio de desenvolvimento, o número total de contas do EIP4337 nas principais cadeias é de apenas 12 milhões, dos quais apenas 6.764 são endereços ativos na rede principal do Ethereum, apresentando uma grande diferença 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, o que mostra que o EIP4337 não teve praticamente nenhum desenvolvimento substancial na rede principal.

No entanto, isso não afeta o valor essencial do AA. Desde o início, o design do EIP4337 estava destinado a ter dificuldades em resolver problemas de compatibilidade com a mainnet, mas foi amplamente aplicado em várias camadas L2. Entre elas, a Base e a Polygon alcançaram, em julho, 1 milhão e 3 milhões de usuários ativos mensais, respectivamente, mostrando um desempenho notável.

Portanto, o design do EIP4337 em si não tem problemas, a situação atual decorre das diferenças entre a mainnet e o L2, que precisam adotar soluções aplicáveis diferentes.

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 EOA são, na verdade, detidos pelo mesmo sujeito. A pessoa que possui a chave privada não só possui a "propriedade da conta", mas também pode "assinar a transferência de todos os ativos".

Isto é determinado pela estrutura de transação da conta Ethereum. Na estrutura de transação padrão, não existe efetivamente o campo From; a transferência de fundos é realizada através do parâmetro VRS (, que é assinado pelo usuário e o endereço From é obtido através da reversão.

O efeito central do EIP4337 é adicionar o Endereço do Remetente no campo de transação, permitindo 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 EOA pode gerar muitos problemas:

1. Difícil proteção da chave privada: perder a chave privada significa perder todos os ativos.

2. Algoritmo de assinatura único: o protocolo nativo só pode usar o algoritmo ECDSA para verificar transações.

3. Permissão de assinatura excessiva: sem múltiplas assinaturas nativas, uma única assinatura pode executar qualquer operação.

4. A taxa de transação só pode ser paga em Éter, não suporta transações em massa.

5. Vazamento de privacidade nas transações: transações um a um são fáceis de analisar as informações dos titulares de contas.

Essas limitações dificultam o uso do Ethereum por usuários comuns:

Primeiro, para usar aplicações Ethereum, é preciso ter ETH e assumir o risco de volatilidade de preços.

Em segundo lugar, os usuários precisam lidar com lógicas de custos complexas, como preço do Gas, limite de Gas, bloqueio de transações e outros conceitos.

Por fim, embora muitas carteiras 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(, para resolver gradualmente os problemas mencionados.

Historicamente, houve várias propostas, que acabaram se resumindo a duas rotas.

![Análise profunda da abstração de contas do Ethereum, passado e futuro])https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(

3. Contexto histórico das propostas de abstração de contas

Aparentemente, há muitas propostas de EIP para a solução do problema, mas, no fundo, existem apenas duas ideias centrais. Cada EIP não aprovado aborda questões que se convertem nos pontos de avanço da solução atual.

) 3.1 Primeira rota: transformar o endereço EOA em endereço CA

Desde 15 de novembro de 2015, Vitalik propôs uma nova estrutura de conta como contrato no EIP-101. Mudar o endereço para ter apenas código e espaço de armazenamento, suportar pagamento de taxas com ERC20, através de contratos pré-compilados, transformar o token nativo em um saldo semelhante ao ERC20, e simplificar os campos da transação para to, startgas, data e code.

Este plano pode derivar várias funcionalidades:

1. As transações podem utilizar mais algoritmos de criptografia, com o método de verificação de assinatura especificado pelo código interno do endereço.

2. Possui características de resistência a ataques quânticos, pois o código é atualizável.

3. Permitir que o ETH tenha as mesmas funcionalidades que os contratos ERC20, como a autorização de dedução.

4. Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte SBT, recuperação de chaves, etc.

A razão pela qual não foi possível continuar é simples: os passos foram grandes demais, e não se considerou adequadamente o problema atual de colisão de hashes de transação e as preocupações de segurança. Mas cada conceito positivo tornou-se uma das funcionalidades centrais das subsequentes EIP4337 e EIP7702.

No futuro, haverá uma série de EIPs que tentarão 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, o cerne é que se o contrato da parte transacionadora não estiver implantado, deve-se usar o parâmetro code anexado à transação para executar a implantação. Também foi proposto um novo opcode PAYGAS, como um delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.

Embora tenha terminado sem sucesso na época, tornou-se uma das lógicas centrais do EIP7702. Cada transação do EIP7702 pode incluir um código associado a uma estrutura de transação especial, permitindo que o endereço EOA tenha capacidades de contrato nesta transação.

EIP-7702: definir código de conta EOA )2024-05-07(

Este é o EIP central discutido posteriormente neste artigo, proposto por Vitalik como uma alternativa ao EIP-3074. O EIP-3074 foi descartado, e o EIP-7702 está determinado a ser incluído no próximo hard fork ETH Prague/Electra.

) 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(

Adicionar duas novas operações AUTH e AUTHCALL no EVM, permitindo que o EOA autorize contratos a chamar outros contratos em vez da identidade EOA usando esses dois opcodes.

Um EOA pode enviar uma mensagem assinada ) transação ( para um contrato confiável ) chamado Invoker (, este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL em vez de um EOA para enviar transações.

EIP-4337: implementar a abstração de contas usando o pool de memória de transações )2021-09-29(

Inspirado pelo MEV, o valor central é evitar completamente alterações no protocolo da camada de consenso.

Apresenta um novo objeto de transação UserOperation, que o usuário envia para o pool de memória, onde os bundlers agrupam em massa a partir da dimensão dos mineradores para entregar a execução do contrato de transação, essencialmente elevando as transações de nível inferior e a operação da conta para serem executadas no nível do contrato.

EIP-5189: através de operações de endossantes na abstração de contas )2022-06-29(

Otimizar a lógica do EIP4337, estabelecendo um mecanismo de endosse de multa de fundos para prevenir ataques de bloqueio DoS.

) 3.3 Outras propostas que suportam a abstração de contas

EIP-2718: embalagem de novo tipo de transação ###2020-06-13(

Proposta já finalizada, definindo um novo tipo de transação como um envelope para futuros tipos de transação a serem adicionados.

Ao introduzir novos tipos de transação, distingue-se através de codificação específica, sendo necessário apenas garantir a compatibilidade retroativa e não a compatibilidade para frente. O exemplo mais comum é o EIP1559, que distingue as taxas de transação, utilizando uma codificação de novo tipo de transação, sem afetar o tipo de transação legado original.

EIP-3607: restrição de endereços EOA para implantar contratos )2021-06-10(

Solução complementar na rota AA, para evitar conflitos entre o endereço de implantação do contrato e o endereço EOA. Controlar o método de geração de contratos, não permitindo que o código seja implantado em um endereço que já é EOA. Este risco é muito pequeno, o endereço Ethereum tem 160 bits de comprimento, embora exista um método para colidir a chave privada para gerar a chave privada do endereço de contrato especificado, estima-se que mesmo com todo o poder de cálculo do Bitcoin, isso 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:

Mas a principal desvantagem do EIP-4337 é que vai contra o princípio da motivação humana.

Parece melhor, mas cai em um ciclo vicioso de desenvolvimento do mercado. Muitos Dapps não são compatíveis, os usuários não estão dispostos a usar endereços de CA, e usar CA pode ter até custos de transação mais altos. Uma dependência excessiva 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, é necessário reduzir os custos.

Para realmente reduzir o Gas, é necessário que o Ethereum em si realize uma atualização de soft fork, modificando o cálculo de Gas ou módulos como o consumo de Gas de opcode. Uma vez que se vai fazer um soft fork, por que não considerar diretamente o EIP-7702?

![Análise aprofundada do passado e futuro da abstração de contas Ethereum]###https://img-cdn.gateio.im/webp-social/moments-3503a168bb61430839419efb40e130de.webp(

4. Análise completa do EIP-7702

) 4.1 O que é o EIP-7702

Através de um novo tipo de transação, permite que EOA tenha temporariamente funções de contrato inteligente em uma única transação, suportando transações em massa, transações sem Gas e gestão de permissões personalizadas, sem a necessidade de introduzir um novo opCode EVM.

Os usuários podem obter a maioria das capacidades de AA sem precisar implantar contratos inteligentes, e até mesmo fornecer a capacidade de terceiros para iniciar transações em nome dos usuários, bastando assinar informações de autorização em vez de fornecer a chave privada.

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](

Adicionada a nova objeto authorization_list, que armazena o código que o signatário deseja executar na 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 múltiplas informações de operação 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

No início da transação, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:

1. Recuperar o endereço do signatário a partir da assinatura r, s usando ecrecover.

2. Verificar ID da cadeia ### para evitar a reprodução de cadeias bifurcadas (.

3. Verifique se o código do signatário da authority está vazio ou foi delegado.

4. Verificar o nonce do signatário authority ) para prevenção de repetição da assinatura authority (.

5. Defina o código do signatário authority como 0xef0100 || endereço.

6. Aumentar o nonce do signatário authority ) para prevenir a reprodução de assinaturas locais (.

7. Adicionar a conta do signatário de autoridade à lista de endereços acessados.

)# 4.3.2 Fase de Execução da Operação

A versão "nova" altera apenas o comportamento de implantação do código.

Não definir mais o código da conta como contract_code, mas recuperar o código do campo address da authorization_list e definir como código da conta.

Ao executar o código autorizado, carregue o código do endereço especificado em authorization_list e execute-o no contexto da conta do signatário.

O código do contrato do usuário é armazenado em um endereço específico na cadeia, não está diretamente incluído na transação.

Os comandos de operação e os parâmetros relacionados são armazenados no campo de dados da carga útil da transação.

4.4 O valor do EIP-7702

Houve mudanças na cadeia completa das carteiras Web3, resultando em uma grande mudança na experiência do usuário. Transações comuns iniciadas por EOA podem executar várias lógicas, semelhantes à execução de contratos, como transferências em lote. Isso afeta a identificação de transações em cenários CeFi e a coleta de taxas de depósito e retirada.

Quebrar múltiplos preconceitos:

1. O saldo da conta pode diminuir devido a transações que não se originam dessa conta.

2. Após o início da execução da transação, o nonce do EOA pode aumentar várias vezes.

3. Quebrar a lógica de proteção da comparação entre tx.origin e msg.sender, muitos contratos existentes apresentam riscos.

4. O EOA pode emitir eventos, afetando a identificação e escuta de certos eventos na cadeia.

5. O endereço EOA pode falhar ao receber ativos ERC20, 721, 1155, etc. devido ao mecanismo de callback ###.

( 4.5 Comparação entre EIP-7702 e EIP-4337

1. Vantagens do EIP-7702

• Gas mais baixo, sem necessidade do módulo entrypoint, reduzindo operações na cadeia.
• O custo de migração do usuário é mais baixo, sem necessidade de implantar contratos na cadeia com antecedência.
• Em comparação com o EIP4337, também há execução de delegação de código, existindo duas maneiras:

Total Delegação)Full Delegation###

• Realizar uma determinada operação