Uma postagem marcadas com "Pectra"

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.