Prefácio

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

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

Na segunda parte, o foco será comparar o feedback do 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 mesclada, espera-se que transforme significativamente a natureza das aplicações on-chain.

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

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 do ETH. No entanto, as disposições relacionadas à 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 haviam passado na auditoria da OpenZeppelin, marcando um marco histórico para o seu lançamento oficial), ele recebeu amplo reconhecimento dos usuários, mas não viu uma adoção generalizada. Esse 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 dar uma olhada nos dados.

Após um ano e meio de desenvolvimento, o EIP-4337 só acumulou 12 milhões de endereços em contas de cadeia 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, esse 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 progressos substanciais 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 possui muitas vantagens que resumiremos sistematicamente. A situação atual decorre das diferenças entre a mainnet e a Camada 2, cada uma exigindo soluções sob medida.

2. O que é 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 apenas possui a conta, mas também tem o direito de assinar e transferir todos os seus ativos.

Essa configuração é determinada pela estrutura de transação da conta do Ethereum. Em uma transação padrão do Ethereum, não há um endereço “De” direto visível. 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 usuário).

Isso envolve conceitos como criptografia assimétrica ECDSA e funções de limiar unidirecionais, mas não entraremos em 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 separar a propriedade é tão importante?

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

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

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

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

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

Privacidade da Transação: Transações um a um facilitam a análise das informações privadas do titular da conta.

Essas restrições tornam difícil para os usuários comuns usarem o Ethereum:

Para usar qualquer aplicação no Ethereum, os usuários devem possuir ETH (e arcar com o risco de flutuações no preço do ETH).

Os usuários precisam lidar com lógica de taxas complexa, como preço do gás, limite de gás e bloqueio de transações (ordem de nonce), o que pode ser muito complicado.

Embora muitas carteiras ou aplicativos de blockchain tentem melhorar a experiência do usuário por meio da otimização do produto, sua eficácia tem sido limitada.

A solução está em implementar Abstração de Conta, que desvincula a propriedade (Proprietário) e a autoridade de assinatura (Signatário) para lidar com essas questões. Historicamente, muitas soluções surgiram, eventualmente convergindo em duas abordagens principais.

3. Visão geral histórica das propostas de Abstração de Conta

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

3.1 A primeira rota é transformar o endereço EOA em um 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 endereços em entidades apenas com espaço de código e armazenamento, alteraria o suporte de taxas para ser pago via 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 para, startgas, dados e código.

Olhando para trás, essa foi uma mudança revolucionária que alteraria 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 visa alcançar hoje. Essa abordagem também poderia permitir recursos adicionais, como:

Permitindo que as transações usem 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.

Dotando o Ether com as mesmas características funcionais dos contratos ERC20, com recursos como autorização delegada, eliminando a necessidade de gasto de moeda nativa.

Melhorando a personalização da conta, suportando recuperação social, SBT (tokens vinculados à alma) e recuperação de chave.

O motivo de 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 funcionalidades principais em EIPs subsequentes, incluindo EIP-4337 e EIP-7702.

Vários EIPs posteriores tentaram refinar essa lógica:

EIP-859: Abstração de Conta na Mainnet (30 de janeiro de 2018) teve como objetivo resolver problemas de implantação de código. Sua função principal era usar o códigoparâmetro anexado às 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 avançado na época, essa lógica se tornou um componente central do EIP-7702, que permite que os endereços de EOA tenham capacidades de contrato por meio de estruturas de transação especiais que podem incluir código.

EIP-7702: Definir o Código da Conta EOA (7 de maio de 2024) é a chave do EIP discutido aqui. Vitalik propôs EIP-7702 como uma alternativa ao EIP-3074. Consequentemente, o EIP-3074 foi abandonado, e o EIP-7702 está definido para ser incluído no próximo hard fork ETH Prague/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: Implementando Abstração de Conta via Pools de Transações (29 de setembro de 2021)

Inspirado pelo MEV, o valor central deste EIP é que ele evita alterações no protocolo da camada de consenso. O EIP-4337 introduz um novo objeto de transação, UserOperation, que os usuários enviam para uma mempool. Os Bundlers então agrupam e entregam essas transações para a execução do contrato, movendo efetivamente as operações de transação e conta de nível inferior para a camada de contrato.

EIP-5189: Operações Abstratas de Conta via Endossantes (29 de junho de 2022)

Este EIP otimiza o EIP-4337 ao abordar problemas potenciais com agregadores maliciosos. Ele introduz um mecanismo de fundos apoiados por endossantes para evitar ataques de negação de serviço penalizando atores mal-intencionados.

3.3 Outras Propostas Apoiando a Abstração de Conta

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

Esta proposta finalizada define um novo tipo de transação como um envelope para futuros tipos de transação. Garante que quando novos tipos de transação são introduzidos, eles possam ser distinguíveis por codificação específica, mantendo a compatibilidade retroativa sem afetar os tipos legados. Um exemplo comum é 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 complementar aborda a questão dos endereços de implantação de contrato conflitantes com os endereços de EOA. Ele controla os métodos de criação de contrato, impedindo que o código seja implantado em endereços já usados por EOAs. O risco é mínimo, dada a extensão de 160 bits dos endereços do Ethereum, embora teoricamente possível através de colisões de chaves, exigiria um esforço computacional significativo.

3.4 Compreensão do Desenvolvimento da Abstração de Conta

Para entender o valor da transição para os 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 em um impasse no desenvolvimento de mercado. Muitos Dapps ainda não são compatíveis com ele, fazendo com que os usuários relutem em usar endereços de CA. Além disso, o uso de CAs pode resultar em custos de transação mais altos (por exemplo, as taxas de transação podem dobrar em cenários de transferência comuns), tornando-se fortemente dependente da compatibilidade dos Dapps.

Como resultado, ele não se tornou difundido na mainnet Ethereum até o momento. O custo é o fator mais crucial para os usuários e deve ser reduzido. Para realmente reduzir os custos de GAS, o próprio Ethereum precisaria de uma atualização de soft fork para modificar os cálculos de GAS ou alterar o consumo de opcodes de GAS. Dada a necessidade de um soft fork, por que não considerar EIP-7702 diretamente?

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 em uma única transação, sendo assim suportando transações em lote, transações sem gás e gerenciamento de permissão personalizado nos negócios, sem a necessidade de introduzir um novo OpCode EVM (afetando a compatibilidade futura).

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

4.2 Estrutura de Dados

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

rlp([

chain_id, //Identificação da cadeia, usada para prevenir ataques de repetição.

nonce, // Contador de transações para garantir a exclusividade 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, usada para otimização de gás no 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 seu EOA. Quando o usuário assina a transação, ele também assina o código do contrato a ser executado. Ele existe como uma lista bidimensional, indicando que várias informações de operação podem ser armazenadas em lotes, realizando operações em lote.

lista_de_autorizacao = [[chain_id, endereco, 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] tupla no lista de autorização:

Use the ecrecoverfunção para recuperar o endereço do signatário a partir da assinatura(r, s)Observe que isso 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). Isso é semelhante a como odeo endereço é derivado de assinaturas, mas se aplica à assinatura de lista específica.

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 EIP-7702, com mecanismos de delegação lidando com a execução).

Verifique o autoridadenonce do signatário para evitar ataques de repetição em assinaturas.

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

Incrementar o autoridadenúmero de nonce do signatário (para evitar a repetiçã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 o código do contrato e as instruções operacionais são executados?

A versão "nova" muda a forma como o código do contrato é implantado. Em vez de definir o código da conta diretamente, 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 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 carteiras Web3, levando a uma transformação drástica na experiência do usuário. As transações comuns iniciadas por um EOA (Conta Possuída Externamente) agora podem executar múltiplas lógicas semelhantes a execuções de contratos inteligentes, como transferências em lote. Isso também afeta cenários de CeFi, afetando a identificação da transação e as 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 do 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 riscos potenciais para muitos contratos existentes. Também quebra o fato de que um EOA em si não pode emitir eventos, o que poderia afetar a identificação e monitoramento de certos eventos on-chain. Por fim, quebra a suposição de que um endereço de 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

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

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

Delegação Completa: Isso significa delegar o controle total de uma determinada operação para 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 parciais de gerenciamento de tokens ERC-20 para 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 um upgrade de soft fork, 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 alto grau de liberdade torna a auditoria difícil, levando os usuários a exigir carteiras mais confiáveis para garantir proteção de segurança.

As mudanças na arquitetura original são significativas. Embora diferentes tipos de transação possam ser distinguidos, 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 maior devido a um aumento significativo na seção de 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 preparando uma conta sem operações, os custos de gás aumentariam em cerca de 500.

“Se o destinatário assina um código que não possui uma função de recebimento, o remetente pode enfrentar um ataque de negação de serviço ao tentar enviar ativos.” Veja o caso. Esse problema surge quando a EOA A assina algo que não deveria ter - um arquivo passível de reprodução 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 do token fará uma chamadaonERC20Receivedna conta do destinatário. Se onERC20Receivedse reverter ou retornar um valor incorreto, a transferência do token será revertida.

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

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 vinculadas no texto para exploração adicional, então não entrarei nesses detalhes aqui.

Atualmente, parece que a abstração de conta só pode ser colocada no sexto módulo, que é a etapa final de corrigir tudo antes de avançar. O progresso acelerado do EIP-7702 traz principalmente desafios à segurança do sistema. É previsível que eventualmente será implementado. Afinal, a fusão do Ethereum, que envolveu uma grande reformulaçã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 on-chain anteriormente “impossíveis” e alterando a lógica da maioria das DApps. No entanto, EIP-7702 agarra firmemente o ponto mais crucial: reduz significativamente os custos para o usuário. Em contraste, EIP-4337 quase duplica os custos das transações.

Os usuários permanecem com endereços EOA (Externally Owned Account), mas só invocam e usam a lógica do CA (Contrato de Conta) quando necessário, reduzindo assim os custos de retenção. Não é necessário converter primeiro para uma identidade de CA on-chain antes de realizar ações, o que significa que os usuários não precisam se registrar.

Os usuários podem facilmente realizar várias transações em paralelo usando seu EOA, como combinar autorização para dedução e executar deduções. Isso reduz os custos de transação para os usuários. Para DApps, especialmente projetos que exigem gerenciamento de nível empresarial on-chain, como exchanges, essa 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 da metade, beneficiando também os usuários.

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

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [PANews]. Todos os direitos autorais pertencem ao autor original [Décimo Quarto Senhor]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção 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 outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.