Prefácio

O artigo está dividido em duas secções principais:

Na primeira parte, começará com a primeira proposta AA de 2015, organizando sistematicamente o conteúdo principal das propostas EIP até à data. O objetivo é explorar o desenvolvimento histórico das propostas AA e avaliar de forma abrangente as forças e fraquezas de cada proposta.

Na segunda parte, irá focar-se na comparação do feedback de mercado após a introdução do EIP-4337 e depois aprofundar a análise do EIP-7702, que está definido para ser incluído na próxima atualização do Ethereum. Esta proposta, uma vez fundida, espera-se que transforme significativamente a natureza das aplicações on-chain.

EIP-7702 promete mudanças revolucionárias, e iremos discuti-lo em detalhe.

1. Antecedentes da Abstração de Conta

1.1 O significado da abstração de conta

No final de 2023, o fundador da Ethereum, Vitalik Buterin, atualizou mais uma vez o roteiro de desenvolvimento da ETH. No entanto, as disposições relacionadas com a Abstração de Conta permaneceram inalteradas. O modelo mainstream atual continua a evoluir do EIP-4337 para a próxima fase: Conversão Voluntária de EOA (conversão auto-iniciada de contas EOA).

https://x.com/VitalikButerin/status/1741190491578810445

Desde o lançamento do EIP-4337 há mais de um ano (em 1 de março de 2023, na WalletCon em Denver, os desenvolvedores da Ethereum Foundation anunciaram que os contratos principais do ERC-4337 tinham passado na auditoria da OpenZeppelin, marcando um marco histórico para o seu lançamento oficial), ele tem recebido ampla reconhecimento dos usuários, mas não viu uma adoção generalizada. Este ambiente de mercado paradoxal acelerou o progresso do EIP-7702, que agora está confirmado para ser incluído na próxima atualização.

1.2 Estado atual do mercado da abstração de conta

Sem mais delongas, vamos analisar os dados.

Após um ano e meio de desenvolvimento, EIP-4337 só acumulou 12 milhões de endereços em contas de cadeias mainstream. O que é particularmente surpreendente é que na mainnet do Ethereum, há apenas 6.764 endereços ativos. Embora possa haver problemas com as dimensões estatísticas, este número ainda é muito diferente dos contagens de endereços para EOAs e CAs. Para contextualizar, o número de endereços únicos na mainnet do Ethereum atingiu 270 milhões (fonte: https://etherscan.io/chart/address).

Pode-se dizer que o EIP-4337 não fez qualquer progresso substancial na mainnet.

(Fonte do gráfico: https://dune.com/niftytable/account-abstraction)

No entanto, isso não diminui o valor inerente da Abstração de Conta (AA). Desde o início, o design do EIP-4337 estava destinado a enfrentar problemas significativos de compatibilidade com versões anteriores na mainnet. Consequentemente, com várias cadeias de Camada 2 integrando AA nativo, o EIP-4337 viu um crescimento substancial nos endereços na Camada 2. Por exemplo, em julho, o número de usuários ativos nas cadeias Base e Polygon atingiu 1 milhão e 3 milhões, respectivamente, o que é bastante impressionante.

Portanto, não é que o design do EIP-4337 seja falho; ele tem muitas vantagens que iremos resumir sistematicamente. A situação atual decorre das diferenças entre a mainnet e a Camada 2, cada uma exigindo soluções personalizadas.

2. O que é a Abstração de Conta?

A Abstração de Conta pode parecer complexa, mas essencialmente aborda a questão da separação de propriedade.

Na arquitetura da Máquina Virtual Ethereum (EVM), existem dois tipos de contas: Contas de Propriedade Externa (EOAs) e Contas de Contrato. Nas EOAs, a propriedade e a autoridade de assinatura são detidas pela mesma entidade. A pessoa com a chave privada não só é proprietária da conta, como também tem o direito de assinar e transferir todos os seus ativos.

Esta configuração é determinada pela estrutura de transação da conta do Ethereum. Numa transação padrão do Ethereum, não é visível um endereço "De" direto. Quando ocorre uma transferência de fundos, o endereço real de onde os fundos são gastos é inferido através dos parâmetros VRS (ou seja, a assinatura do utilizador).

Isso envolve conceitos como criptografia assimétrica ECDSA e funções de limite unidirecional, mas não vamos aprofundar nesses detalhes aqui. Essencialmente, a criptografia garante segurança, o que leva à situação atual em que a propriedade e a autoridade de assinatura são combinadas em EOAs.

O efeito principal do EIP-4337 é adicionar um campo de Endereço do Remetente à transação, permitindo que a chave privada e o endereço operado sejam separados.

Então, por que é tão importante separar a propriedade?

Porque o design das Contas de Propriedade Externa (EOAs) leva a vários problemas:

Proteção da Chave Privada: Perder a chave privada (devido a perda, hacking ou compromisso criptográfico) significa perder todos os ativos.

Algoritmos de Assinatura Limitados**: O protocolo nativo apenas suporta ECDSA para assinatura e verificação.

Alta Autoridade de Assinatura: Sem suporte nativo para multi-assinatura (que só pode ser alcançada através de contratos inteligentes), uma única assinatura pode executar qualquer operação.

Taxas de transação: As taxas só podem ser pagas em Éter, o que não suporta um alto volume de transações.

Privacidade da Transação: Transações um para um tornam fácil analisar a informação privada do detentor da conta.

Estas restrições tornam difícil para os utilizadores comuns usar Ethereum:

Para usar qualquer aplicação no Ethereum, os utilizadores devem deter ETH (e suportar o risco das flutuações de preço do ETH).

Os utilizadores precisam lidar com uma lógica de taxas complexa, como o preço do gás, o limite do gás e o bloqueio da transação (ordem de nonce), o que pode ser demasiado complicado.

Embora muitas carteiras ou aplicações de blockchain tentem melhorar a experiência do utilizador através da otimização do produto, a sua eficácia tem sido limitada.

A solução reside na implementação da Abstração de Conta, que desacopla a propriedade (Proprietário) e a autoridade de assinatura (Assinante) para abordar essas questões. Historicamente, muitas soluções surgiram, convergindo eventualmente em duas abordagens principais.

3. Visão geral histórica das propostas de abstração de conta

Embora pareça que existem muitas propostas EIP abordando o problema, fundamentalmente, existem apenas duas abordagens principais. As questões consideradas em propostas anteriores que não foram aprovadas acabaram por convergir nas soluções atuais.

3.1 A primeira opção é transformar o endereço EOA num endereço CA

Em 15 de novembro de 2015, Vitalik Buterin propôs uma nova estrutura de conta em torno do EIP-101, que envolvia o uso de contratos como contas. Isso transformaria os endereços em entidades com apenas código e espaço de armazenamento, alteraria o suporte de taxa a ser pago por meio de tokens ERC20 e usaria contratos pré-compilados para converter tokens nativos em tokens semelhantes a ERC20 para armazenamento de saldo (com recursos como autorização delegada). Os campos de transação foram simplificados para incluir apenas to, startgas, data e código)

Olhando para trás, esta foi uma mudança revolucionária que iria alterar drasticamente o design subjacente, dando a cada endereço de conta sua própria lógica de “código”, que é essencialmente o que o EIP-7702 pretende alcançar hoje. Esta abordagem também poderia permitir funcionalidades adicionais, tais como:

Permitir transações para utilizar mais algoritmos criptográficos especificados pelo código interno de cada endereço para verificação e autenticação.

Fornecendo resistência quântica devido à natureza atualizável do código.

Atribuindo Éter com as mesmas características funcionais dos contratos ERC20, com funcionalidades como autorização delegada, eliminando a necessidade de despesa de moeda nativa.

Melhorar a personalização da conta, apoiar a recuperação social, SBT (tokens vinculados à alma) e recuperação de chaves.

A razão para não avançar com esta proposta foi simples: os passos eram demasiado ambiciosos. Questões como colisões de hash de transações e preocupações de segurança não foram totalmente abordadas, o que levou ao seu adiamento. No entanto, muitos dos seus benefícios tornaram-se características essenciais nos EIPs subsequentes, incluindo EIP-4337 e EIP-7702.

Vários EIPs posteriormente tentaram refinar esta lógica:

EIP-859: Conta Abstrata na Mainnet (30 de janeiro de 2018) teve como objetivo resolver problemas de implementação de código. Sua função principal era usar o códigoparâmetro anexado a transações para implantar carteiras de contratos se o contrato não foi implantado. Também introduziu um novo opcode PAYGAS para separar as partes de verificação e execução de uma transação.

Embora não tenha progredido na época, esta lógica tornou-se um componente essencial do EIP-7702, que permite que os endereços EOA tenham capacidades de contrato através de estruturas de transação especiais que podem incluir código.

EIP-7702: Setting EOA Account Code (7 de maio de 2024) é a principal EIP discutida aqui. Vitalik propôs o EIP-7702 como alternativa ao EIP-3074. Consequentemente, o EIP-3074 foi abandonado, e o EIP-7702 deve ser incluído no próximo hard fork ETH Praga/Electra (Pectra). Mais detalhes serão discutidos abaixo.

3.2 A segunda abordagem é permitir que os endereços EOA conduzam os endereços CA.

EIP-3074: Adição de Opcodes AUTH e AUTHCALL (15 de outubro de 2020)

Este EIP introduz dois novos opcodes, AUTH e AUTHCALL, no EVM, permitindo que EOAs autorizem contratos a substituir sua identidade e chamar outros contratos. Em essência, um EOA pode enviar uma mensagem assinada (transação) para um contrato confiável (chamado de Invoker). O contrato Invoker pode então usar os opcodes AUTH e AUTHCALL para enviar a transação em nome do EOA.

EIP-4337: Implementação da Abstração de Conta através de Pools de Transações (29 de setembro de 2021)

Inspirado pelo MEV, o valor principal deste EIP é que evita alterações no protocolo da camada de consenso. O EIP-4337 introduz um novo objeto de transação, UserOperation, que os utilizadores enviam para uma pool de memória. Os agrupadores então agrupam e entregam essas transações para a execução do contrato, movendo eficazmente as operações de transação e conta de nível inferior para a camada do contrato.

EIP-5189: Abstract Account Operations via Endorsers (29 de junho de 2022)

Este EIP otimiza o EIP-4337 ao abordar possíveis problemas com agrupadores maliciosos. Introduz um mecanismo para fundos apoiados por endossantes para evitar ataques de DoS penalizando os atores mal-intencionados.

3.3 Outras Propostas de Apoio à Abstração de Conta

EIP-2718: Novo Tipo de Envelope de Transação (13 de junho de 2020)

Esta proposta finalizada define um novo tipo de transação como um envelope para tipos de transação futuros. Garante que, quando novos tipos de transação são introduzidos, eles possam ser distinguidos por codificação específica, mantendo a compatibilidade retroativa sem afetar os tipos legados. Um exemplo comum é o EIP-1559, que diferenciou as taxas de transação com uma nova codificação de tipo de transação, preservando os tipos legados.

EIP-3607: Impedir que Endereços EOA Deployem Contratos (10 de junho de 2021)

Esta proposta suplementar aborda o problema dos endereços de implementação de contrato em conflito com os endereços de EOA. Controla os métodos de criação de contrato, impedindo que o código seja implementado em endereços já utilizados por EOAs. O risco é mínimo, dada a extensão de 160 bits dos endereços Ethereum, embora teoricamente possível através de colisões de chaves, exigiria um esforço computacional significativo.

3.4 Compreender o Desenvolvimento da Abstração de Conta

Para entender o valor da transição para endereços CA, é essencial compreender os efeitos práticos do EIP-4337, que pode alcançar...

No entanto, a principal desvantagem do EIP-4337 é que viola o princípio dos incentivos humanos. Embora pareça oferecer melhorias, cai num impasse de desenvolvimento de mercado. Muitas Dapps ainda não são compatíveis com ele, levando os utilizadores a relutarem em usar endereços CA. Além disso, o uso de CAs pode resultar em custos de transação mais elevados (por exemplo, as taxas de transação podem duplicar em cenários de transferência comuns), tornando-se fortemente dependente da compatibilidade das Dapps.

Como resultado, ainda não se tornou generalizado na mainnet do Ethereum até à data. O custo é o fator mais crucial para os utilizadores e deve ser reduzido. Para realmente diminuir os custos com GAS, o próprio Ethereum precisaria de uma atualização soft fork para modificar os cálculos de GAS ou alterar o consumo de GAS dos opcodes. Dada a necessidade de um soft fork, por que não considerar diretamente o EIP-7702?

4. Análise abrangente do EIP-7702

4.1 O que é EIP-7702

É distinguido por novos tipos de transações, que permitem que EOA tenha temporariamente a função de um contrato inteligente numa única transação, suportando assim transações em lote, transações sem gás e gestão de permissões personalizadas no negócio, sem a necessidade de introduzir um novo OpCode EVM (Afetando a compatibilidade futura).

Permite aos utilizadores obter a maioria das capacidades da AA sem implementar contratos inteligentes e até pode fornecer a terceiros a capacidade de iniciar transações em nome dos utilizadores. Não exige que os utilizadores forneçam chaves privadas, mas apenas precisa de assinar informações autorizadas.

4.2 Estrutura de dados

Ele definiu um novo tipo de transação 0x04. O TransactionPayload deste tipo de transação é o resultado da serialização de codificação RLP do seguinte conteúdo

rlp([

chain_id, //ID da cadeia, usado para prevenir ataques de repetição.

nonce, // Contador de transações para garantir a singularidade da transação.

max_priority_fee_per_gas, //taxa de transação 1559

max_fee_per_gas, //taxa de transação 1559

limite de gás,

destino, //Endereço de destino da transação

valor,

dados,

access_list, //Lista de acesso, utilizada para otimização de gás em EIP-2929.

lista de autorização,

signature_y_parity, // 3 parâmetros de assinatura, usados para verificar a assinatura da transação.

assinatura_r,

assinatura_s

])

O importante é que o objeto authorization_list seja adicionado para armazenar o código que o signatário deseja executar em sua EOA. Quando o usuário assina a transação, ele também assina o código do contrato a ser executado. Existe como uma lista bidimensional, indicando que várias informações de operação podem ser armazenadas em lotes, realizando operações em lote.

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

4.3 Ciclo de Vida da Transação

4.3.1 Fase de Verificação

No início da fase de execução da transação, para cada [chain_id, address, nonce, y_parity, r, s]tuplo no lista de autorização:

Use o Ecrecoverfunção para recuperar o endereço do signatário a partir da assinatura(r, s)Note que isto utiliza o mecanismo existente do Ethereum, portanto, o algoritmo de assinatura permanece inalterado por este EIP. O endereço é recuperado usando:autoridade = ecrecover(keccak(MAGIC || rlp([chain_id, endereço, nonce])), y_parity, r, s). Isto é semelhante à forma como o deO endereço é derivado de assinaturas, mas aplica-se à assinatura específica da lista.

Verifique o ID da cadeia para evitar ataques de repetição em cadeias diferentes.

Verifique se o autoridadeO código do signatário está vazio ou delegado (para confirmar se a transação é uma transação válida de EIP-7702, com mecanismos de delegação a lidar com a execução).

Verifique o autoridadenúmero do signatário para prevenir ataques de repetição em assinaturas.

Definir o autoridadecódigo do signatário para0xef0100 || endereço(para contornar as estratégias de prevenção de colisão EIP-3607).

Incrementar o autoridadenonce do signatário (para evitar a reutilização local da assinatura).

Adicione o autoridadeconta do signatário para a lista de acesso (para transição para armazenamento a quente, reduzindo os custos de gás para acesso).

4.3.2 Fase de Execução

Onde são executados o código do contrato e as instruções operacionais?

A nova versão altera como o código do contrato é implantado. Em vez de definir diretamente o código da conta, ele recupera o código do lista de autorizaçãoendereço e define-o como o código da conta.

Ao executar código autorizado, carregue o código do endereço especificado no lista de autorizaçãoe executá-lo 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 blockchain, em vez de ser diretamente incluído na transação.

As instruções operacionais e os parâmetros relacionados são armazenados no dadoscampo da carga útil da transação.

4.4 Qual é o valor do EIP-7702?

O EIP-7702 introduz um valor significativo, pois muda fundamentalmente todo o processo de transação para as carteiras Web3, levando a uma transformação drástica na experiência do utilizador. As transações comuns iniciadas por um EOA (Conta Possuída Externamente) agora podem executar múltiplas lógicas semelhantes às execuções de contratos inteligentes, como transferências em lote. Isso também afeta cenários de CeFi, afetando a identificação de transações e taxas para saques e consolidação.

EIP-7702 quebra muitas suposições de longa data: quebra a invariante de que o saldo da conta só pode diminuir devido a transações originadas dessa conta. Quebra a invariante de que o nonce da EOA aumenta em 1 após a execução de uma transação começar (agora pode aumentar por múltiplos valores simultaneamente). Quebra a lógica protetora que depende da comparação tx.originemsg.sender, introduzindo potenciais riscos para muitos contratos existentes. Também quebra o facto de que um EOA em si não pode emitir eventos, o que poderia afetar a identificação e monitorização de certos eventos on-chain. Por fim, quebra a suposição de que um endereço EOA sempre receberá com sucesso ativos ERC20, 721, 1155 e outros (pois pode falhar devido ao mecanismo de retorno de chamada).

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

1. Vantagens do EIP-7702

A EIP-7702 tem várias vantagens. Uma delas são custos de gás mais baixos, uma vez que não requer passar pelo módulo de entrada, reduzindo as operações on-chain. Outra é custos de migração de usuário mais baixos, uma vez que não é necessário implantar um contrato on-chain como a entidade principal antecipadamente.

Comparado com o EIP-4337, o EIP-7702 também suporta execução de código delegado e oferece dois tipos de delegação:

Delegação Total: Isso significa delegar o controle total de uma determinada operação a um endereço específico. Por exemplo, um usuário pode delegar a gestão de todos os tokens ERC-20 para um endereço de contrato inteligente, permitindo que o contrato execute todas as operações relacionadas em nome do usuário.

Delegação Protegida: Isso envolve adicionar restrições e salvaguardas durante a delegação para garantir a segurança e controlabilidade das operações delegadas. Por exemplo, um usuário pode delegar apenas direitos de gestão parciais de tokens ERC-20 a um contrato inteligente ou definir condições (por exemplo, gastar no máximo 1% do saldo total por dia).

2. Desvantagens do EIP-7702

A principal desvantagem do EIP-7702 é que envolve uma atualização de fork suave, exigindo consenso da comunidade para avançar. Suas mudanças são substanciais e podem ter um amplo impacto no ecossistema on-chain. Com base em uma avaliação inicial de Shisi Jun, vários desafios foram identificados, mas esses desafios também podem representar oportunidades de mercado:

O elevado grau de liberdade torna a auditoria difícil, levando os utilizadores a exigir carteiras mais fiáveis para garantir a proteção de segurança.

As alterações na arquitetura original são significativas. Embora diferentes tipos de transações possam ser distinguíveis, muitas infraestruturas fundamentais, especialmente contratos imutáveis on-chain, podem não ser diretamente compatíveis.

Embora o EIP-7702 forneça capacidades de contrato para endereços EOA, o espaço de armazenamento correspondente não pode ser retido.

O custo das transações individuais é ligeiramente mais alto devido a um aumento significativo na secção Calldata. O custo total estimado de uma chamada será de 16 (gás)15 (bytes) = 240 (gas) para custos de calldata, mais o custo do EIP-3860 de 215 = 30 e aproximadamente 150 para custos de tempo de execução. Portanto, mesmo preparar uma conta sem operações aumentaria os custos de gás em cerca de 500.

“Se o destinatário assinar um código que não tenha uma função de receção, o remetente pode enfrentar um ataque de DoS ao tentar enviar ativos.” Veja o caso. Este problema surge quando a EOA A assina algo que não deveria — um ficheiro reproduzível com implementação incorreta (faltando receive()).

A lógica de consolidação e saque on-chain pode ser inconsistente. Por exemplo, ao transferir tokens ERC-20, se a conta do destinatário tiver código, o contrato de token irá chamaronERC20Receivedna conta do destinatário. Se onERC20Receivedse reverter ou devolver um valor incorreto, a transferência de token será revertida.

Além disso, se um EOA pode emitir eventos, poderia haver algum problema? Algumas infraestruturas podem precisar prestar atenção a isso.

Estes são apenas alguns dos inconvenientes resumidos por Shisi Jun com base na proposta atual EIP-7702 e discussões no fórum oficial. Uma análise completa exigirá examinar o código de implementação final.

5. Resumo

O artigo pode parecer extenso, mas contém apenas cerca de 6.000 palavras. Muitas referências a interpretações passadas do EIP estão ligadas no texto para exploração adicional, por isso não irei aprofundar-me aqui.

Atualmente, parece que a abstração de conta só pode ser colocada no sexto módulo, que é a fase final de corrigir tudo antes de avançar. O progresso acelerado do EIP-7702 traz principalmente desafios para a segurança do sistema. É previsível que eventualmente seja implementado. Afinal, a fusão do Ethereum, que envolveu uma grande revisão do algoritmo de consenso, já aconteceu. Um novo tipo de transação é relativamente menor em comparação.

No entanto, desta vez as mudanças são bastante disruptivas, quebrando várias regras anteriormente 'impossíveis' on-chain e alterando a lógica da maioria das DApps. No entanto, o EIP-7702 agarra firmemente o ponto mais crucial: reduz significativamente os custos para o utilizador. Em contraste, o EIP-4337 quase duplica os custos das transações.

Os utilizadores permanecem com endereços EOA (Externally Owned Account), mas apenas invocam e utilizam lógica CA (Contract Account) quando necessário, reduzindo assim os custos de manutenção. Não é necessário converter primeiro para uma identidade CA on-chain antes de realizar ações, o que significa que os utilizadores não precisam de se registar.

Os utilizadores podem facilmente realizar várias transações em paralelo usando o seu EOA, como combinar autorização para dedução e executar deduções. Isso diminui os custos de transação para os utilizadores. Para DApps, especialmente projetos que exigem gestão empresarial on-chain de nível empresarial, como exchanges, esta otimização é revolucionária. Se a consolidação em lote for implementada nativamente, os custos operacionais básicos para as exchanges poderiam ser reduzidos em mais de metade, beneficiando também os utilizadores.

Portanto, embora o EIP-7702 introduza muitas mudanças, o seu impacto no custo por si só torna-o digno de estudo e adaptação para todas as DApps. Desta vez, os utilizadores estão, sem dúvida, do lado do EIP-7702.

Aviso legal：

1. Este artigo é reproduzido a partir de [PANews]. Todos os direitos de autor pertencem ao autor original [Décimo Quarto Senhor]. Se houver objeções a esta reimpressão, por favor entre em contato com oGate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.