3 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.

Saques, ajustes de gás, e o que veio depois—sem o hype.

A Versão Resumida​

A atualização Shapella, um portmanteau de Shanghai (para a camada de execução) e Capella (para a camada de consenso), foi ao ar no Ethereum em 12 de abril de 2023. Sua característica principal foi habilitar saques de staking pela primeira vez desde o lançamento da Beacon Chain.

A mudança principal, EIP-4895, introduziu um sistema onde saques de validadores são automaticamente "empurrados" da camada de consenso para a camada de execução, não requerendo transação de usuário ou taxas de gás. Junto a isso, quatro EIPs menores foram enviados para ajustar a EVM, incluindo reduções de custo de gás (Warm COINBASE), otimizações de bytecode (PUSH0), e limites de criação de contratos (Initcode metering). A atualização também serviu como aviso final aos desenvolvedores de que o opcode SELFDESTRUCT estava sendo descontinuado.

Shapella efetivamente fechou o ciclo do Merge, e a próxima grande atualização, Dencun, seguiu em 13 de março de 2024, mudando o foco da rede para escalabilidade com "blobs" EIP-4844.

Por Que Shapella Foi um Marco Crítico​

Desde o início da Beacon Chain até abril de 2023, fazer staking de ETH era uma rua de mão única. Você podia depositar 32 ETH para ajudar a proteger a rede e ganhar recompensas, mas não conseguia recuperar seu principal ou essas recompensas da camada de consenso. Essa liquidez bloqueada era um compromisso significativo e uma barreira para muitos stakers em potencial.

Shapella mudou tudo ao abrir a porta de saída.

O núcleo da atualização foi EIP-4895, que engenhosamente projetou uma "operação de saque" em nível de sistema. Em vez de exigir que stakers criassem uma transação e pagassem gás para sacar, o protocolo em si agora automaticamente coleta fundos elegíveis da camada de consenso e os empurra para a camada de execução. Este design limpo, baseado em push, minimizou complexidade e risco, tornando muito mais fácil testar e implantar a mudança com segurança.

O Que Realmente Mudou: Os EIPs em Português Claro​

Shapella foi um pacote de cinco Propostas de Melhoria do Ethereum (EIPs) principais:

• EIP-4895 — Saques da Beacon Chain (Baseados em Push) Este foi o evento principal. Habilitou tanto saques parciais (recompensas) quanto completos (principal + recompensas) para fluir da camada de consenso para o endereço de saque especificado do staker. A inovação chave é que essas não são transações iniciadas pelo usuário; são operações automáticas incorporadas em blocos propostos.

• EIP-3651 — "Warm COINBASE" Este EIP fez uma pequena mas importante otimização de gás. Na EVM, COINBASE refere-se ao endereço do produtor do bloco (o validador), não a exchange. Antes do Shapella, a primeira vez que um contrato inteligente acessava este endereço dentro de uma transação, incorria em um custo de gás mais alto. EIP-3651 tornou o endereço COINBASE "warm" por padrão, reduzindo o custo de gás para protocolos que frequentemente interagem com ele, como aqueles que pagam gorjetas MEV diretamente ao construtor de blocos.

• EIP-3855 — Opcode PUSH0 Uma adição simples mas elegante à EVM. Este novo opcode, PUSH0, faz exatamente o que diz: empurra o valor zero para a pilha. Anteriormente, desenvolvedores tinham que usar opcodes mais pesados e caros para conseguir isso. PUSH0 torna o bytecode ligeiramente menor e mais eficiente em gás, especialmente para os numerosos contratos que inicializam variáveis em zero.

• EIP-3860 — Limitar e Medir initcode Esta mudança introduziu duas regras para o código usado para criar um contrato inteligente (initcode). Primeiro, limitou o tamanho máximo do initcode em 49.152 bytes. Segundo, adicionou uma pequena taxa de gás para cada pedaço de 32 bytes deste código. Isso previne ataques de negação de serviço envolvendo contratos excessivamente grandes e torna os custos de criação de contratos mais previsíveis.

• EIP-6049 — Depreciar SELFDESTRUCT (Aviso) Isso não foi uma mudança de código, mas um aviso formal para a comunidade de desenvolvedores. Sinalizou que o opcode SELFDESTRUCT, que permite a um contrato se deletar e enviar seu ETH para um endereço alvo, teria sua funcionalidade drasticamente mudada em uma atualização futura. Isso deu aos desenvolvedores tempo para eliminar gradualmente sua dependência antes da atualização Dencun posteriormente alterar seu comportamento com EIP-6780.

Saques 101: Parciais vs. Completos​

Shapella introduziu dois tipos de saques automáticos, cada um com suas próprias regras.

• Saques Parciais Estes são coletas automáticas de recompensas. Se o saldo de um validador cresce acima de 32 ETH devido a recompensas da camada de consenso, o protocolo automaticamente "descremá" o valor excedente e o envia para o endereço de saque designado. O validador permanece ativo e continua seus deveres. Isso acontece sem ação requerida do staker.

• Saques Completos (Saída) Isso é para stakers que querem parar de validar e recuperar todo seu saldo. O staker deve primeiro transmitir uma mensagem de saída voluntária. Após um período de espera, o validador se torna elegível para um saque completo. Uma vez processado na coleta, todo o saldo é enviado para o endereço de saque, e o validador não é mais parte do conjunto ativo.

Throughput e Cadência​

A rede é projetada para processar saques suavemente sem causar instabilidade.

• Até 16 saques podem ser incluídos em cada bloco (a cada 12 segundos), permitindo um máximo de aproximadamente 115.200 saques por dia.
• O proponente do bloco escaneia a lista de validadores ativos e inclui os primeiros 16 saques elegíveis. O próximo proponente de bloco continua de onde o último parou, garantindo que cada validador tenha sua vez na fila.
• Para prevenir um êxodo em massa de desestabilizar a rede, o número de validadores que podem sair por época (a cada ~6.4 minutos) é limitado por um limite de rotatividade. Este limite é dinâmico baseado no número total de validadores ativos, suavizando ondas de saída.

Também é importante notar que recompensas da camada de consenso são tratadas por este mecanismo de saque EIP-4895, enquanto recompensas da camada de execução (taxas prioritárias e MEV) são enviadas diretamente para o endereço do destinatário de taxas configurado do validador e estão disponíveis imediatamente.

O Que Veio Depois: Dencun e o Caminho para Escalabilidade​

Shapella marcou a conclusão bem-sucedida da "era do Merge." Com staking agora sendo um processo completamente líquido e bidirecional, desenvolvedores voltaram sua atenção para o próximo grande desafio do Ethereum: escalabilidade.

A próxima grande atualização, Dencun (Deneb + Cancun), chegou em 13 de março de 2024. Sua peça central foi EIP-4844, que introduziu "blobs"—uma nova forma mais barata para rollups de Camada 2 postarem dados de transação na mainnet do Ethereum. Isso reduziu drasticamente as taxas de transação em L2s e foi um passo massivo à frente no roteiro centrado em rollups. Dencun também cumpriu a promessa do EIP-6049 implementando EIP-6780, que significativamente restringiu o poder do opcode SELFDESTRUCT.

O Quadro Geral​

Shapella foi o marco de confiança essencial para o consenso Proof-of-Stake do Ethereum. Ao habilitar saques, des-arriscou o staking, restaurou liquidez, e afirmou a capacidade da rede de executar atualizações complexas e coordenadas. Também entregou algumas melhorias pragmáticas da EVM que limparam débito técnico e pavimentaram o caminho para otimizações futuras.

Em resumo, Shapella não apenas abriu a porta de saída para stakers—solidificou a fundação da era pós-Merge e limpou a pista para o Ethereum focar em sua próxima fronteira: escalabilidade massiva.