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

Este artigo é dividido em duas partes principais:

A parte superior começa com a primeira proposta AA de 2015, o sistema organizou até agora o conteúdo das principais propostas EIP, discutindo o histórico de desenvolvimento das propostas AA e avaliando de forma abrangente cada uma das propostas.

A segunda parte foca na análise comparativa das razões pelas quais a reação do mercado foi morna após o lançamento do EIP4337, e uma análise aprofundada do EIP7702, que será incorporado na próxima atualização do Ethereum. Uma vez que esta proposta seja integrada, mudará completamente a forma das aplicações em cadeia.

EIP-7702 é de importância revolucionária, vamos entender isso em detalhes.

1. Background da abstração da conta

1.1 Significado abstrato da conta

O fundador do Ethereum, Vitalik, ao atualizar o roteiro do ETH no final de 2023, não alterou a configuração da abstração de conta. O modo principal está atualmente a evoluir de EIP-4337 para a próxima fase de conversão voluntária de contas EOA.

Desde o lançamento do EIP4337 há mais de um ano, ( foi oficialmente anunciado na WalletCon em Denver em 1 de março de 2023, e tem sido amplamente reconhecido pelos usuários, mas a taxa de uso não é alta. Neste ambiente de mercado contraditório, o progresso do EIP-7702 foi adiantado significativamente, e já foi confirmado que será integrado na próxima atualização.

) 1.2 estado atual do mercado da conta abstrata

Após um ano e meio de desenvolvimento, o número de contas do EIP4337 nas cadeias principais é de apenas 12 milhões, dos quais apenas 6.764 são endereços 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 únicos na rede principal do Ethereum já atingiu 270 milhões, pode-se dizer que o EIP4337 não teve um desenvolvimento substancial na rede principal.

No entanto, isso não afeta o valor essencial do AA. O design do EIP4337 determina que é difícil resolver o problema de compatibilidade para frente da mainnet. Com a incorporação nativa do AA em várias L2, o número de endereços EIP4337 explodiu nas L2, com a Base e a cadeia Polygon alcançando 1 milhão e 3 milhões de usuários ativos mensais, respectivamente, em julho.

Portanto, não é que o design do EIP4337 esteja errado, ele tem muitas vantagens. A situação atual resulta das diferenças entre a mainnet e o L2, que precisam de soluções aplicáveis a cada uma.

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

2. O que é a abstração de conta?

A abstração de conta 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ó 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 de transação, pode-se ver que a transação padrão do Ethereum não tem o campo From. Quando os fundos são transferidos, qual endereço específico é utilizado para consumir os fundos é determinado pelo parâmetro VRS ), ou seja, o endereço From é obtido a partir da assinatura do usuário (.

Isto envolve conceitos como ECDSA e funções de limiar unidirecionais, que não iremos discutir em detalhe. Em resumo, aqui a segurança é garantida pela criptografia, mas isso também causou a atual dificuldade na fusão da propriedade dos endereços EOA.

O efeito principal do EIP4337 é adicionar o campo Sender Address no 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 da propriedade é tão importante é que o design da conta externa )EOA( pode gerar mais problemas:

1. Dificuldade em proteger a chave privada: a perda da chave privada ), ataques de hackers ou quebra criptográfica ( significam a perda de 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: sem multisig nativo ), o multisig só pode ser realizado através de contrato inteligente (, uma única assinatura pode executar qualquer operação.

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

5. Vazamento de privacidade em transações: transações um a um tornam mais 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, ao usar qualquer aplicação na Ethereum, os utilizadores devem possuir Éter ) e assumir o risco de volatilidade de preços (.

Em segundo lugar, os utilizadores precisam lidar com uma lógica de taxas complexa; conceitos como preço do Gas, limite de Gas, bloqueio de transações ) e ordem de nonce ( são demasiado complicados para os utilizadores.

Por fim, 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 solução reside na implementação da abstração de contas, desacoplando a propriedade )Owner( e o direito de assinatura )Signer(, resolvendo gradualmente os problemas acima mencionados.

Historicamente, houve várias propostas, que acabaram convergindo para duas rotas.

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

3. Contextualização das Propostas Históricas de AA

A solução para o problema parece ter muitas propostas de EIP, mas no fundo existem apenas duas abordagens principais. Cada questão considerada em EIPs não aprovados acaba convergindo para os pontos de ruptura das soluções existentes.

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

Em 15 de novembro de 2015, em torno do EIP-101, Vitalik propôs uma nova estrutura de conta baseada em contratos. Mudou o endereço para que tivesse apenas código e espaço de armazenamento, alterou o suporte a taxas de transação para serem pagas por ERC20, e, através de contratos pré-compilados, transformou o token nativo em um tipo de ERC20 para manter o saldo ###, podendo incluir funcionalidades como autorização de desconto (, e simplificou os campos da transação para incluir apenas to, startgas, data e code.

A partir de agora, parece uma transformação de grande salto, que alterará significativamente o design subjacente, permitindo que cada endereço de conta tenha sua própria lógica de "código" ). Este é exatamente 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, podendo ser especificados os métodos de verificação e autenticação de assinatura interna por 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 possua características funcionais consistentes com os contratos ERC20, com o efeito principal de realizar a autorização de dedução, sem a necessidade de perda de moeda nativa.

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

A razão pela qual não conseguimos avançar é simples: claramente, fomos longe demais, não consideramos adequadamente o problema atual dos conflitos de hash de transação e as questões de segurança, por isso foi sempre adiado. No entanto, cada conceito positivo se tornou uma das funcionalidades centrais do EIP4337 e EIP7702.

Depois houve uma série de EIPs que tentaram aprimorar essa lógica:

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

Tentativa de resolver o problema de implantação do código. A função principal é que, se o contrato da parte transacionadora não estiver implantado, utiliza-se o parâmetro code anexado à transação para executar a implantação da carteira de contrato. Além disso, foi proposta uma nova opcode PAYGAS, que, além de pagar o gas, também se torna 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, isso se tornou uma das lógicas centrais do EIP7702 atualmente. 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: definir código de conta EOA )2024-05-07(

Este é o núcleo do mecanismo de discussão subsequente deste artigo EIP. Vitalik publicou o EIP-7702 como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi descontinuado, e o EIP-7702 está determinado a ser incluído no próximo hard fork ETH Prague/Electra)Pectra(, cujos detalhes iremos abordar mais tarde.

) 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 o EOA autorize contratos a chamar outros contratos em vez da identidade do EOA através desses dois opcode.

Em resumo, um EOA pode enviar uma mensagem assinada ) para um contrato confiável ( chamado Invoker ). Este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para emitir transações em nome deste EOA.

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

Foi projetado inspirado pelo MEV, e 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 em massa a partir da perspectiva dos mineradores para entregar a execução de transações de contratos, essencialmente movendo as transações subjacentes e a operação de contas para serem executadas a nível de contrato.

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

Isso pode ser considerado uma otimização da lógica do EIP4337, que enfrenta Bundlers maliciosos através do mecanismo de endossar penalizações financeiras para prevenir ataques de bloqueio DoS.

( 3.3 Outras propostas para apoiar AA

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 diferenciar as transações através de uma codificação específica, permitindo apenas a compatibilidade retroativa, sem a necessidade de compatibilidade para a frente. O exemplo mais comum é o EIP1559, que diferencia as taxas de transação, usando uma nova codificação de tipo de transação, sem afetar os tipos de transação legados originais.

EIP-3607: impedir que endereços EOA implantem contratos (2021-06-10)

Esta é uma solução complementar no caminho AA, destinada a prevenir problemas de conflito entre o endereço de implantação do contrato 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á é um endereço EOA. Este risco é, na verdade, muito pequeno, uma vez que o endereço Ethereum tem 160 bits de comprimento; embora exista um método para colidir a chave privada e gerar a chave privada de um endereço de contrato específico, com a totalidade da capacidade de cálculo do Bitcoin, estima-se que ainda levaria um ano.

( 3.4 Como compreender a evolução da abstração de conta?

Primeiro, é necessário entender o valor após a conversão para CA.

Basicamente, é o efeito prático do EIP-4337, que pode realizar:

• Suporte a vários algoritmos de assinatura
• Suporte para recuperação social
• Suporte para tokens que permitem personalizar as taxas de Gas de pagamento
• Suporte a transações em lote
• Suporte à gestão de conta
• Suporte para pagamento de gas fees por terceiros

No entanto, a principal desvantagem do EIP-4337 é contrariar o princípio da motivação humana.

Parece melhor, mas está preso 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 um custo de transação mais alto ) em cenários de transferência comuns, as taxas de transação dobram ###, e depende demais da compatibilidade dos próprios Dapps.

Portanto, ainda não se popularizou na rede principal do Ethereum.

O custo é o critério de avaliação mais importante para os usuários, é necessário reduzir custos.

Mas para realmente reduzir o GAS, é necessário que o Ethereum em si faça um upgrade de soft fork, modificando o cálculo de GAS ou mudando o consumo de GAS de módulos como os códigos de operação. No entanto, já 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 distingue-se através de um novo tipo de transação, permitindo que a EOA tenha temporariamente a funcionalidade de contrato inteligente em uma única transação, apoiando assim transações em massa, 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###.

Ele permite que os usuários obtenham a maior parte das capacidades de AA sem precisar implantar contratos inteligentes, e pode até oferecer a capacidade de terceiros iniciarem transações em nome dos usuários, sem a necessidade de os usuários fornecerem a chave privada, bastando assinar a informação de 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, destino, valor, dados, access_list, lista_de_autorização, signature_y_parity, signature_r, assinatura_s ]###

Importante é que um novo objeto authorization_list foi adicionado, que 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 código do contrato a ser executado, que existe como uma lista bidimensional, indicando que múltiplas informações de operação podem ser armazenadas em lote, permitindo a execução de operações em lote.

authorization_list = [[chain_id, endereço, nonce, y_parity, r, s], ...]

(