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

Este artigo é dividido em duas partes principais:

A parte superior começa com a primeira proposta AA de 2015, sistematizando o conteúdo principal das propostas EIP até agora, explorando o desenvolvimento histórico das propostas AA e avaliando de forma abrangente cada plano.

A parte inferior foca na comparação das reações do mercado após a proposta do EIP4337, analisando em profundidade o EIP7702, que será incluído na próxima atualização do Ethereum. Uma vez que esta proposta seja integrada, mudará completamente a forma das aplicações em cadeia.

O EIP-7702 possui um significado revolucionário, vamos entender isso em detalhes.

1. O contexto da abstração de contas

1.1 Significado e localização 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 da abstração de contas não mudou. O modelo principal está atualmente em transição do EIP-4337 para a próxima fase "conversão voluntária de contas EOA".

Mais de um ano após o lançamento da EIP4337, em 1 de março de 2023, foi oficialmente apresentada na WalletCon de Denver (, recebendo amplo reconhecimento dos usuários, mas não sendo amplamente utilizada. Neste ambiente de mercado contraditório, o progresso da EIP-7702 foi antecipado significativamente, e foi confirmado que será incorporada 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 principais cadeias é de apenas 12 milhões, dos quais existem apenas 6.764 endereços ativos na rede principal do Ethereum, uma diferença considerável 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.

Pode-se dizer que o EIP4337 não teve desenvolvimento substancial na mainnet.

No entanto, isso não afeta o valor essencial do AA. O design do EIP4337 destina-se a tornar difícil a resolução do problema de compatibilidade retroativa da mainnet. Com vários L2 chains geralmente integrados ao AA nativo, o número de endereços do EIP4337 teve um grande crescimento no L2, com a Base e a Polygon alcançando 1 milhão e 3 milhões de usuários ativos em julho, respectivamente, apresentando um desempenho notável.

Portanto, o design do EIP4337 não é um erro, ele possui muitas vantagens. A situação atual decorre das diferenças entre a mainnet e o L2, que precisam adotar soluções adequadas para cada um.

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

2. O que é a 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: conta externa ) EOA ( e conta de contrato ) Contract Account (. A propriedade e o direito de assinatura da conta externa são, na verdade, 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 transação padrão do Ethereum não possui o campo From, na verdade, o endereço From é decifrado através do parâmetro VRS ), ou seja, a assinatura do usuário (. Isso envolve conceitos como ECDSA e funções de limite unidirecional. A criptografia garante a segurança, mas também causa a atual dificuldade de fusão da propriedade do endereço EOA.

O efeito central do EIP4337 é adicionar o campo Endereço do Remetente ao campo de 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 de contas externas )EOA( irá gerar mais problemas:

1. Difícil de proteger a chave privada: perder a chave privada significa perder todos os ativos.

2. Algoritmo de assinatura único: o protocolo nativo só pode usar o algoritmo de assinatura e verificação ECDSA ao validar transações.

3. Permissões de assinatura excessivas: não há múltiplas assinaturas nativas ), as múltiplas assinaturas só podem ser implementadas através de contratos inteligentes (, 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 tornam fácil analisar as informações pessoais do titular da conta.

Estas limitações tornam difícil para os usuários comuns utilizarem o Ethereum:

Primeiro, para usar qualquer aplicação 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 a lógica de taxas complexas, como o preço do gás, o limite de gás, o bloqueio de transações ), a ordem do nonce ( e outros conceitos que são demasiado complexos para os usuários.

Por fim, embora muitas carteiras de blockchain ou aplicações tentem melhorar a experiência do usuário através da otimização de produtos, os resultados são limitados.

Portanto, a chave para a superação está na realização da abstração de contas, desacoplando a propriedade )Owner( e o direito de assinatura )Signer(, resolvendo gradualmente os problemas acima mencionados.

Historicamente, houve muitas propostas, que podem ser resumidas em duas rotas.

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

3. Revisão do contexto das propostas de abstração de contas

A solução para o problema parece ter muitas propostas de EIP, mas no fundo existem apenas duas ideias centrais. Cada EIP que não foi aprovado reúne as questões consideradas que se tornaram os pontos de ruptura da solução atual.

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

Em 15 de novembro de 2015, Vitalik propôs uma nova estrutura de conta como contrato na EIP-101. A mudança do endereço para conter apenas código e espaço de armazenamento, alterando o suporte de taxas para ser pago com tokens ERC20, através de contratos pré-compilados para converter o token nativo em um tipo semelhante ao ERC20 para armazenar saldo ###, podendo ter funções como autorização de retenção, etc. (, simplificando os campos de transação para to, startgas, data e code.

Esta transformação parece radical, alterando significativamente o design subjacente, permitindo que cada endereço de conta tenha sua própria lógica de "código" ), que é precisamente o efeito que o EIP-7702 pretende alcançar (.

Ele também pode derivar outras funcionalidades, como:

1. Permitir que as transações utilizem mais algoritmos de criptografia, com o método de verificação de assinatura especificado pelo Code interno de cada endereço.

2. Possui características de resistência a ataques quânticos, pois o código pode ser atualizado.

3. Fazer com que o Éter tenha características funcionais consistentes com os contratos ERC20, com o efeito principal de realizar a autorização de débito, sem necessidade de consumir a moeda nativa.

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

A razão pela qual não conseguimos continuar é simples: claramente, a marcha foi muito grande e a consideração sobre o atual problema de colisão de hash nas transações e as preocupações de segurança foram inadequadas, por isso foi sempre adiado. Mas cada conceito positivo se tornou uma das funcionalidades principais dos subsequentes EIP4337 e EIP7702.

Depois, houve uma série de EIPs que tentaram aperfeiçoar essa lógica:

EIP-859: abstração de contas da cadeia principal )2018-01-30(

Tentativa de resolver o problema de implantação do Code. 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. Além disso, um novo opcode PAYGAS foi proposto, que, além de pagar gas, também se tornará um delimitador entre a parte de validação e a parte de execução nos parâmetros da transação.

Embora não tenha sido realizado na época, isso também 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 certo código, permitindo que o endereço EOA tenha capacidade de contrato nesta transação.

EIP-7702: configurar código da conta EOA )2024-05-07(

Este também é o núcleo do mecanismo discutido posteriormente neste artigo, publicado por Vitalik como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi descartado, e o EIP-7702 foi determinado para ser incluído na próxima bifurcação dura ETH Prague/Electra)Pectra(, cujos detalhes serão desenvolvidos a seguir.

) 3.2 Segunda rota: permitir que o endereço EOA conduza 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 EOA autorize contratos a chamar outros contratos em vez da identidade do EOA através desses dois opcodes.

Em resumo, um EOA pode enviar uma mensagem assinada ) para um contrato de confiança (, chamado de Invoker ). Este contrato Invoker pode utilizar os códigos de operação AUTH e AUTHCALL para substituir este EOA na emissão desta transação.

EIP-4337: Implementação da abstração de contas através do 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ória, onde os bundlers o empacotam em massa a partir da perspectiva dos mineradores para entregar transações de execução de contratos, essencialmente movendo as transações subjacentes e a operação de contas para serem executadas ao nível do contrato.

EIP-5189: operar contas abstratas através de endossantes (2022-06-29)

Isso é uma otimização da lógica do EIP4337, que enfrenta Bundlers maliciosos por meio da criação de um mecanismo de penalização de fundos para endossadores, a fim de prevenir ataques de bloqueio DoS.

( 3.3 Outras propostas para suportar a abstração de contas

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

Esta é uma proposta já finalizada, que define 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, é possível diferenciá-lo por meio de uma codificação específica, permitindo que tenha apenas 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: impedir que endereços EOA implantem contratos (2021-06-10)

Esta é uma solução complementar no caminho AA, utilizada para evitar problemas de conflito entre o endereço de implantação de contratos e o endereço EOA. Ela controlará o método de geração de contratos, impedindo que o sistema permita a implantação de código em um endereço que já seja um endereço EOA. Este risco é na verdade bastante pequeno, pois o endereço Ethereum tem 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 toda a capacidade de cálculo do Bitcoin, ainda seria necessário 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:

• Os usuários não precisam mais possuir diretamente ETH para pagar as taxas de Gas.
• Permite configurar flexivelmente as permissões da conta, como multiassinatura, recuperação social, etc.
• Suporte para transações em lote, reduzindo custos de transação
• Algoritmo de verificação de assinatura personalizado, aumentando a segurança
• Algumas operações podem ser pagas por terceiros para o Gas

No entanto, a principal desvantagem do EIP-4337 é que contraria 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 não estão dispostos a usar endereços CA, e até mesmo usar CA tem custos de transação mais altos ) em cenários de transferência comuns, as taxas de transação também dobrarão ###, muito dependente da compatibilidade do Dapp em si.

Portanto, até agora, a Ethereum na mainnet nunca se popularizou.

O custo é o critério mais importante para os usuários e deve ser reduzido.

Mas para realmente reduzir o Gas, é necessário que o Ethereum em si faça uma atualização de soft fork, modificando o cálculo do Gas ou alterando o consumo de Gas de módulos como o opcode. No entanto, uma vez que é necessário um soft fork, por que não considerar diretamente o EIP-7702?

4. Análise completa do EIP-7702

( 4.1 O que é o EIP-7702

Ele se distingue por meio de um novo tipo de transação, permitindo que EOA tenha temporariamente as funcionalidades de um 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 opCode EVM ) que afete a compatibilidade retroativa ###.

Ele permite que os usuários obtenham a maior parte das capacidades de AA sem precisar implantar contratos inteligentes, podendo até fornecer a capacidade de terceiros para iniciar transações em nome do usuário, sem que o usuário precise fornecer a chave privada, apenas a informação de autorização da assinatura.

( 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, destino, valor, dados, access_list, lista_de_autorização, signature_y_parity, signature_r, signature_s ]###

É importante que foi adicionado um 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 em que assina o código do contrato a ser executado, que existe como uma lista bidimensional, indicando que várias informações de operação podem ser armazenadas em lote, permitindo a execução de operações em lote.

autorização_