2 postagens marcadas com "EIP-7702"

Em 7 de maio de 2025, a atualização Pectra do Ethereum (Prague + Electra) chegou à mainnet. Entre suas mudanças mais visíveis para desenvolvedores está o EIP-7702, que permite que uma conta externa (EOA) "monte" lógica de smart-contract—sem migrar fundos ou alterar endereços. Se você constrói carteiras, dapps, ou relayers, isso desbloqueia um caminho mais simples para UX de smart-account.

Abaixo está um guia conciso e focado em implementação: o que realmente foi lançado, como o 7702 funciona, quando escolhê-lo sobre ERC-4337 puro, e um scaffold para copiar e colar que você pode adaptar hoje.

O Que Realmente Foi Lançado​

• EIP-7702 está no escopo final do Pectra. O meta-EIP para o hard fork Pectra lista oficialmente 7702 entre as mudanças incluídas.
• Detalhes de ativação: Pectra foi ativado na mainnet na época 364032 em 7 de maio de 2025, seguindo ativações bem-sucedidas em todas as testnets principais.
• Nota de toolchain: Solidity v0.8.30 atualizou seu alvo EVM padrão para prague para compatibilidade com Pectra. Você precisará atualizar seus compiladores e pipelines CI, especialmente se você fixa versões específicas.

EIP-7702—Como Funciona (Detalhes Técnicos)​

EIP-7702 introduz um novo tipo de transação e um mecanismo para uma EOA delegar sua lógica de execução para um smart contract.

• Novo Tipo de Transação (0x04): Uma transação Tipo-4 inclui um novo campo chamado authorization_list. Esta lista contém uma ou mais tuplas de autorização—(chain_id, address, nonce, y_parity, r, s)—cada uma assinada pela chave privada da EOA. Quando esta transação é processada, o protocolo escreve um indicador de delegação para o campo de código da EOA: 0xef0100 || address. A partir desse ponto, todas as chamadas para a EOA são direcionadas para o address especificado (a implementação), mas executam dentro do contexto de armazenamento e saldo da EOA. Esta delegação permanece ativa até ser explicitamente alterada.
• Escopo de Chain: Uma autorização pode ser específica de chain fornecendo um chain_id, ou pode se aplicar a todas as chains se chain_id for definido como 0. Isso permite que você implemente o mesmo contrato de implementação em várias redes sem exigir que os usuários assinem uma nova autorização para cada uma.
• Revogação: Para reverter uma EOA de volta ao seu comportamento original não-programável, você simplesmente envia outra transação 7702 onde o address de implementação é definido como endereço zero. Isso limpa o indicador de delegação.
• Auto-Patrocinado vs. Relayed: Uma EOA pode submeter a transação Tipo-4 ela mesma, ou um relayer terceiro pode submetê-la em nome da EOA. O último é comum para criar uma experiência de usuário sem gas. O manuseio de nonce difere ligeiramente dependendo do método, então é importante usar bibliotecas que manuseiem corretamente essa distinção.

Mudança no Modelo de Segurança: Como a chave privada EOA original ainda existe, ela sempre pode sobrescrever qualquer regra de smart contract (como recuperação social ou limites de gastos) submetendo uma nova transação 7702 para alterar a delegação. Esta é uma mudança fundamental. Contratos que dependem de tx.origin para verificar que uma chamada é de uma EOA devem ser re-auditados, pois 7702 pode quebrar essas suposições. Audite seus fluxos adequadamente.

7702 ou ERC-4337? (E Quando Combinar)​

Tanto EIP-7702 quanto ERC-4337 habilitam abstração de conta, mas servem necessidades diferentes.

• Escolha EIP-7702 quando…
  • Você quer fornecer UX de smart-account instantânea para EOAs existentes sem forçar usuários a migrar fundos ou alterar endereços.
  • Você precisa de endereços consistentes entre chains que podem ser progressivamente atualizados com novas funcionalidades.
  • Você quer escalonar sua transição para abstração de conta, começando com recursos simples e adicionando complexidade ao longo do tempo.
• Escolha ERC-4337 puro quando…
  • Seu produto requer programabilidade completa e engines de política complexas (ex. multi-sig, recuperação avançada) desde o primeiro dia.
  • Você está construindo para novos usuários que não têm EOAs existentes, tornando novos endereços de smart-account e a configuração associada aceitáveis.
• Combine-os: O padrão mais poderoso é usar ambos. Uma EOA pode usar uma transação 7702 para designar uma implementação de carteira ERC-4337 como sua lógica. Isso faz a EOA se comportar como uma conta 4337, permitindo que ela seja empacotada, patrocinada por paymasters, e processada pela infraestrutura 4337 existente—tudo sem o usuário precisar de um novo endereço. Este é um caminho compatível para frente explicitamente encorajado pelos autores do EIP.

Scaffold 7702 Mínimo Que Você Pode Adaptar​

Aqui está um exemplo prático de um contrato de implementação e o código do lado cliente para ativá-lo.

1. Um Contrato de Implementação Pequeno e Auditável​

Este código de contrato executará no contexto da EOA uma vez designado. Mantenha-o pequeno, auditável, e considere adicionar um mecanismo de upgrade.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice Executa chamadas do contexto EOA quando designado via EIP-7702.
contract DelegatedAccount {
    // Slot de armazenamento único para evitar colisões com outros contratos.
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // Opcional: adicionar verificações para restringir quem pode chamar certas funções.
        _;
    }

    function initialize() external payable onlyEOA {
        // Definir uma flag de inicialização única no armazenamento da EOA.
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // Reverter se já inicializado
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. Designar o Contrato numa EOA (tx Tipo-4) com viem​

Clientes modernos como viem têm helpers integrados para assinar autorizações e enviar transações Tipo-4. Neste exemplo, uma conta relayer paga o gas para atualizar uma eoa.

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. Definir o relayer (patrocina gas) e a EOA a ser atualizada
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. A EOA assina a autorização apontando para o contrato de implementação
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // Se a EOA fosse enviar isso ela mesma, você adicionaria: executor: 'self'
});

// 3. O relayer envia uma transação Tipo-4 para definir o código da EOA e chamar initialize()
const hash = await client.sendTransaction({
  to: eoa.address, // O destino é a própria EOA
  authorizationList: [authorization], // O novo campo EIP-7702
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. Agora, a EOA pode ser controlada via sua nova lógica sem mais autorizações
// Por exemplo, para executar uma transação:
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. Revogar Delegação (De Volta para EOA Simples)​

Para desfazer a atualização, faça a EOA assinar uma autorização que designa o endereço zero como implementação e enviar outra transação Tipo-4. Depois, uma chamada para eth_getCode(eoa.address) deve retornar bytes vazios.

Padrões de Integração Que Funcionam em Produção​

• Atualizar no Local para Usuários Existentes: No seu dapp, detecte se o usuário está numa rede compatível com Pectra. Se sim, exiba um botão opcional "Atualizar Conta" que dispara a assinatura de autorização única. Mantenha caminhos de fallback (ex. approve + swap clássicos) para usuários com carteiras mais antigas.
• Onboarding Sem Gas: Use um relayer (seja seu backend ou um serviço) para patrocinar a transação Tipo-4 inicial. Para transações sem gas contínuas, roteie operações de usuário através de um bundler ERC-4337 para aproveitar paymasters existentes e mempools públicas.
• Rollouts Cross-Chain: Use uma autorização chain_id = 0 para designar o mesmo contrato de implementação em todas as chains. Você pode então habilitar ou desabilitar recursos por chain dentro da sua lógica de aplicação.
• Observabilidade: Seu backend deve indexar transações Tipo-4 e analisar a authorization_list para rastrear quais EOAs foram atualizadas. Após uma transação, verifique a mudança chamando eth_getCode e confirmando que o código da EOA agora combina com o indicador de delegação (0xef0100 || implementationAddress).

Modelo de Ameaça & Pegadinhas (Não Pule Isso)​

• Delegação é Persistente: Trate mudanças no contrato de implementação de uma EOA com a mesma gravidade de uma atualização padrão de smart contract. Isso requer auditorias, comunicação clara ao usuário, e idealmente, um fluxo opt-in. Nunca empurre nova lógica para usuários silenciosamente.
• Minas Terrestres de tx.origin: Qualquer lógica que usou msg.sender == tx.origin para garantir que uma chamada veio diretamente de uma EOA agora é potencialmente vulnerável. Este padrão deve ser substituído por verificações mais robustas, como assinaturas EIP-712 ou whitelists explícitas.
• Matemática de Nonce: Quando uma EOA patrocina sua própria transação 7702 (executor: 'self'), seu nonce de autorização e nonce de transação interagem de uma maneira específica. Sempre use uma biblioteca que manuseie isso corretamente para evitar problemas de replay.
• Responsabilidade de UX da Carteira: A especificação EIP-7702 avisa que dapps não devem pedir aos usuários para assinar designações arbitrárias. É responsabilidade da carteira verificar implementações propostas e garantir que são seguras. Projete sua UX para alinhar com este princípio de segurança mediada por carteira.

Quando 7702 é uma Vitória Clara​

• Fluxos DEX: Um approve multi-etapa e swap podem ser combinados em um único clique usando a função executeBatch.
• Jogos & Sessões: Conceda privilégios similares a session-key por tempo limitado ou escopo sem exigir que o usuário crie e financie uma nova carteira.
• Empresa & Fintech: Habilite transações patrocinadas e aplique políticas de gastos customizadas enquanto mantém o mesmo endereço corporativo em cada chain para contabilidade e identidade.
• Pontes L2 & Intents: Crie fluxos de meta-transação mais suaves com uma identidade EOA consistente em diferentes redes.

Estes casos de uso representam os mesmos benefícios centrais prometidos pelo ERC-4337, mas agora estão disponíveis para cada EOA existente com apenas uma autorização única.

Lista de Verificação de Lançamento​

Protocolo​

• Garantir que nós, SDKs, e provedores de infraestrutura suportem transações Tipo-4 e EVM "prague" do Pectra.
• Atualizar indexadores e ferramentas de análise para analisar o campo authorization_list em novas transações.

Contratos​

• Desenvolver um contrato de implementação mínimo e auditado com recursos essenciais (ex. batching, revogação).
• Testar completamente fluxos de revogar e re-designar em testnets antes de implantar na mainnet.

Clientes​

• Atualizar bibliotecas do lado cliente (viem, ethers, etc.) e testar as funções signAuthorization e sendTransaction.
• Verificar que tanto caminhos de transação auto-patrocinados quanto relayed manuseiam nonces e replays corretamente.

Segurança​

• Remover todas as suposições baseadas em tx.origin dos seus contratos e substituí-las por alternativas mais seguras.
• Implementar monitoramento pós-implantação para detectar mudanças de código inesperadas em endereços de usuário e alertar sobre atividade suspeita.

Linha de fundo: EIP-7702 fornece uma rampa de baixo atrito para UX de smart-account para os milhões de EOAs já em uso. Comece com uma implementação pequena e auditada, use um caminho relayed para configuração sem gas, torne a revogação clara e fácil, e você pode entregar 90% dos benefícios da abstração de conta completa—sem a dor de rotação de endereços e migração de ativos.

Por anos, o mundo cripto tem sido atrapalhado por um problema crítico de usabilidade: a carteira. Carteiras tradicionais, conhecidas como Contas Externamente Possuídas (EOAs), são implacáveis. Uma única frase‑semente perdida significa que seus fundos desaparecem para sempre. Cada ação requer uma assinatura, e as taxas de gás devem ser pagas no token nativo da cadeia. Essa experiência pesada e de alto risco é uma barreira importante para a adoção em massa.

Surge então a Abstração de Conta (AA), uma mudança de paradigma que promete redefinir como interagimos com a blockchain. No seu cerne, a AA transforma a conta do usuário em um contrato inteligente programável, desbloqueando recursos como recuperação social, transações de um clique e pagamentos de gás flexíveis.

A jornada rumo a esse futuro mais inteligente está se desenrolando por três caminhos distintos: o ERC‑4337, já testado em batalha; a AA Nativa, eficiente; e o tão aguardado EIP‑7702. Vamos analisar o que cada abordagem significa para desenvolvedores e usuários.

💡 Caminho 1: O Pioneiro — ERC‑4337​

O ERC‑4337 foi a ruptura que trouxe a abstração de conta para Ethereum e cadeias EVM sem alterar o protocolo central. Pense nele como uma camada inteligente adicionada ao sistema existente.

Ele introduz um novo fluxo de transação envolvendo:

• UserOperations: um novo objeto que representa a intenção do usuário (ex.: “trocar 100 USDC por ETH”).
• Bundlers: atores off‑chain que coletam UserOperations, as agrupam e as enviam à rede.
• EntryPoint: um contrato inteligente global que valida e executa as operações agrupadas.

O Positivo:

• Compatibilidade Universal: pode ser implantado em qualquer cadeia EVM.
• Flexibilidade: permite recursos avançados como chaves de sessão para jogos, segurança multi‑assinatura e patrocínio de gás via Paymasters.

O Trade‑off:

• Complexidade & Custo: introduz uma sobrecarga de infraestrutura significativa (execução de Bundlers) e tem os maiores custos de gás dos três métodos, já que cada operação passa pela lógica extra do EntryPoint. Por isso, sua adoção floresceu principalmente em L2s econômicas como Base e Polygon.

O ERC‑4337 abriu caminho para que outras soluções de AA pudessem existir. Ele provou a demanda e lançou as bases para uma experiência Web3 mais intuitiva.

🚀 Caminho 2: O Ideal Integrado — Abstração de Conta Nativa​

Se o ERC‑4337 é um add‑on, a AA Nativa incorpora recursos inteligentes diretamente na fundação da blockchain. Cadeias como zkSync Era e Starknet foram projetadas desde o início com a AA como princípio central. Nessas redes, toda conta é um contrato inteligente.

O Positivo:

• Eficiência: ao integrar a lógica de AA ao protocolo, elimina‑se as camadas extras, resultando em custos de gás significativamente menores comparados ao ERC‑4337.
• Simplicidade para Devs: desenvolvedores não precisam gerenciar Bundlers nem um mempool separado. O fluxo de transação se assemelha muito ao padrão.

O Trade‑off:

• Fragmentação do Ecossistema: a AA Nativa é específica de cada cadeia. Uma conta no zkSync é diferente de uma conta no Starknet, e nenhuma delas é nativa da mainnet Ethereum. Isso cria uma experiência fragmentada para usuários e desenvolvedores que trabalham em múltiplas cadeias.

A AA Nativa nos mostra o “fim de jogo” em termos de eficiência, mas sua adoção está atrelada ao crescimento dos ecossistemas que a hospedam.

🌉 Caminho 3: A Ponte Pragmática — EIP‑7702​

Previsto para ser incluído na atualização “Pectra” de 2025 da Ethereum, o EIP‑7702 é um divisor de águas projetado para levar recursos de AA às massas de usuários de EOAs existentes. Ele adota uma abordagem híbrida: permite que um EOA delegue temporariamente sua autoridade a um contrato inteligente para uma única transação.

Pense nisso como conceder superpoderes temporários ao seu EOA. Você não precisa migrar fundos nem mudar de endereço. Sua carteira pode simplesmente adicionar uma autorização a uma transação, permitindo executar operações agrupadas (ex.: aprovação + troca em um clique) ou ter seu gás patrocinado.

O Positivo:

• Compatibilidade Retroativa: funciona com os bilhões de dólares protegidos por EOAs atuais. Nenhuma migração necessária.
• Baixa Complexidade: usa o pool de transações padrão, eliminando a necessidade de Bundlers e simplificando drasticamente a infraestrutura.
• Catalisador de Adoção em Massa: ao tornar recursos inteligentes acessíveis a todo usuário Ethereum da noite para o dia, pode acelerar rapidamente a adoção de padrões de UX melhores.

O Trade‑off:

• Não é “AA Completa”: o EIP‑7702 não resolve a gestão de chaves para o próprio EOA. Se você perder sua chave privada, ainda estará sem acesso. Ele foca mais em aprimorar as capacidades de transação do que em reformular a segurança da conta.

Comparação Lado a Lado​

O Futuro é Convergente e Centrado no Usuário​

Esses três caminhos não são mutuamente exclusivos; eles convergem para um futuro onde a carteira deixa de ser ponto de atrito.

1. Recuperação Social Torna‑se Padrão 🛡️: A era de “chaves perdidas, fundos perdidos” está terminando. A AA permite recuperação baseada em guardiões, tornando a autocustódia tão segura e indulgente quanto uma conta bancária tradicional.
2. UX de Jogos Reimaginada 🎮: Chaves de sessão permitirão jogabilidade fluida sem pop‑ups constantes de “aprovar transação”, finalmente fazendo os jogos Web3 se sentirem como jogos Web2.
3. Carteiras como Plataformas Programáveis: As carteiras se tornarão modulares. Usuários poderão adicionar um “módulo DeFi” para farming automatizado ou um “módulo de segurança” que exija 2FA para transferências grandes.

Para desenvolvedores e provedores de infraestrutura como Blockeden.xyz, essa evolução é extremamente empolgante. A complexidade de Bundlers, Paymasters e os diversos padrões de AA cria uma oportunidade enorme para oferecer infraestrutura robusta, confiável e abstraída. O objetivo é uma experiência unificada onde o desenvolvedor possa integrar recursos de AA facilmente, e a carteira escolha inteligentemente entre ERC‑4337, AA Nativa ou EIP‑7702 conforme a cadeia suporte.

A carteira finalmente recebe a atualização que merece. A transição de EOAs estáticas para contas inteligentes dinâmicas não é apenas uma melhoria — é a revolução que tornará o Web3 acessível e seguro para o próximo bilhão de usuários.