O que é o upgrade Fusaka do Ethereum? Guia dev com 12 EIPs

O upgrade Fusaka é o próximo grande hard fork do Ethereum, com ativação na mainnet prevista provisoriamente para 3 de dezembro de 2025. Já está ativo na testnet para integração antecipada e testes por desenvolvedores.

Fusaka dá continuidade ao que o Pectra começou, introduzindo 12 mudanças de protocolo (EIPs) que aprofundam a escalabilidade do Ethereum, a transparência dos validadores, a economia de gas e a criptografia, tornando o Fusaka o maior upgrade de todos em número de EIPs incluídos.

O nome Fusaka vem da combinação de "Fulu" (upgrade da camada de consenso, batizado em homenagem a uma estrela) e "Osaka" (upgrade da camada de execução, batizado em homenagem a um local do Devcon). Neste artigo, detalhamos cada melhoria que chega com o Fusaka, explicando o que muda e como isso te impacta como desenvolvedor, seja você alguém que faz deploy de apps, smart contracts, ou constrói sua própria chain.

Principais EIPs em resumo

Os 12 EIPs do Fusaka cobrem quatro grandes áreas:

• Disponibilidade de dados e sampling: Libera novos caminhos de escalabilidade para rollups e blobs.
• Primitivas de criptografia e matemática: Precompiles nativas para a curva secp256r1, padrão da indústria, expandindo a criptografia onchain.
• Mudanças em gas e execução: Otimiza custos de gas e a alocação de recursos do protocolo.
• Operações de consenso e validadores: Adiciona seleção de validadores mais previsível e mais eficiência.

Disponibilidade de dados e escalabilidade

EIP-7594: peer data availability sampling (PeerDAS)

O EIP-7594 introduz o Peer Data Availability Sampling (PeerDAS), uma mudança importante em como o Ethereum verifica e armazena dados de blob. Em vez de cada nó baixar blobs completos, os nós agora amostram pequenos trechos aleatórios de outros peers e verificam colaborativamente que o conjunto completo de dados está disponível.

Isso permite que a rede lide com muito mais dados sem sacrificar confiança ou descentralização - um pré-requisito para escalar a camada de dados do Ethereum para centenas de blobs por bloco.

O PeerDAS é o primeiro passo prático em direção ao Danksharding completo. Ao permitir que os nós se especializem em armazenar dados parciais e ainda assim validem tudo, o teto de throughput do Ethereum aumenta drasticamente. No longo prazo, esse mecanismo pode expandir a capacidade de dados de centenas de kilobytes por segundo para vários megabytes, reduzindo diretamente os custos de postagem na Layer 2 e viabilizando aplicações de alto throughput.

Rollups podem postar lotes de transações muito maiores a custo menor, permitindo maior throughput e taxas mais baratas para o usuário. As integrações precisarão ajustar a lógica de postagem de blobs para aproveitar a capacidade ampliada.

EIP-7892: blob parameter only (BPO) hardforks

O EIP-7892 introduz um novo mecanismo chamado Blob Parameter Only (BPO) hardforks, permitindo que o Ethereum ajuste parâmetros relacionados a blobs, como o alvo e o máximo de blobs por bloco, sem exigir um upgrade completo da rede.

Em vez de agrupar essas mudanças com forks maiores, o BPO cria um processo leve e independente para escalar a capacidade de blobs conforme a demanda de dados da Layer 2 cresce.

Antes do Fusaka, mudar os limites de blob significava esperar por um hardfork coordenado, muitas vezes com meses de intervalo. Com o BPO, o Ethereum agora pode aumentar a capacidade de blobs em passos menores e mais seguros, reagindo rapidamente ao uso da rede e ao mesmo tempo mantendo uma escalabilidade previsível. Isso mantém as taxas estáveis, sustenta o crescimento contínuo da Layer 2 e remove os gargalos causados por mudanças de parâmetros pouco frequentes e de alto risco.

EIP-7918: blob base fee bounded by execution cost

O EIP-7918 refina o mercado de taxas de blob do Ethereum introduzindo um preço de reserva atrelado à taxa de gas principal de execução. Isso garante que as taxas de blob nunca fiquem abaixo de uma base justa em relação à demanda geral da rede.

Quando o gas de execução fica caro mas o uso de blob permanece baixo, o sistema impede que os preços de blob desabem para próximo de zero (por exemplo, 1 wei), mantendo um mercado equilibrado e funcional para disponibilidade de dados.

Sem esse mecanismo, o mercado de taxas de blob poderia perder seu sinal econômico em períodos em que a execução domina a atividade da rede — tornando artificialmente barato postar blobs de dados grandes. Ao ancorar o preço do blob aos custos de execução, o EIP-7918 mantém o mercado de blobs eficiente, evita a subprecificação e suaviza picos de taxa quando o uso sobe repentinamente.

Impacto para desenvolvedores: disponibilidade de dados e escalabilidade

• Desenvolvedores de rollup e L2 podem começar a testar volumes maiores de postagem de blob. Espere custos menores e maior throughput ao longo do tempo, e rollups e L2s ganham espaço para incluir mais dados onchain por transação sem explosões de custo. Isso libera novas classes de produto antes limitadas pela precificação de calldata ou blob.
• Upgrades de client são obrigatórios. Os nós agora participam de sampling coordenado em vez de baixar todos os dados, então os requisitos de armazenamento e largura de banda mudam, mas a carga geral se torna mais equilibrada e escalável.
• O EIP-7594 (PeerDAS) muda o formato de prova de blob proofs para cell proofs. Os originadores de transações de blob (L2s, etc.) precisam atualizar seu software para gerar cell proofs em vez de blob proofs. Essa mudança pode quebrar aplicações que enviam transações de blob. Leia os detalhes completos e o guia de migração.
• Recomenda-se que os desenvolvedores validem seus sequencers de rollup e pipelines de DA na testnet do Fusaka antes da ativação na mainnet em 3 de dezembro de 2025, e verifiquem a compatibilidade entre todas as versões de client que implementam PeerDAS e o agendamento de BPO.

Criptografia e primitivas matemáticas

EIP-7939: opcode CLZ (count leading zeros)

O EIP-7939 introduz um novo opcode, CLZ, que conta o número de bits zero à esquerda em um valor de 256 bits. Ele retorna quantos bits zero aparecem antes do primeiro bit "1" em um valor de 256 bits. Por exemplo, 0x000...001 retorna 255, e 0x800...000 retorna 0. Ele retira x da pilha e empilha o número de bits zero à esquerda em x. Se x for zero, ele empilha 256.

Essa adição pequena, mas poderosa, elimina a necessidade de lógica de bit-looping cara no Solidity ao realizar operações matemáticas de baixo nível.

O CLZ permite implementações eficientes de logaritmos inteiros, normalização, geração de aleatoriedade e computações baseadas em bits — tudo em um único opcode. Protocolos de DeFi, contratos de rollup e primitivas criptográficas que dependem de manipulação rápida de bits ou de matemática em escala logarítmica vão se beneficiar de economias de gas mensuráveis e de uma lógica mais limpa.

Exemplo de caso de uso:

EIP-7951: precompile para a curva secp256r1

O EIP-7951 adiciona uma precompile nativa para a curva elíptica secp256r1 (NIST P-256), uma das curvas criptográficas mais usadas em WebAuthn, módulos de segurança de hardware e carteiras corporativas. Até agora, o Ethereum suportava apenas secp256k1 e BLS12-381, forçando os desenvolvedores a verificar assinaturas P-256 fora da chain ou por meio de contratos customizados caros. Essa precompile traz verificação rápida e de baixo gas diretamente para a EVM.

O suporte nativo ao secp256r1 permite integração direta com os padrões WebAuthn e FIDO2 — a mesma criptografia usada em chaves de hardware, navegadores e sistemas de autenticação corporativos. Carteiras e aplicações agora podem verificar assinaturas de usuário nativamente onchain, reduzindo a dependência de relays externos ou camadas custodiais. É um passo crítico para adoção corporativa e mainstream, conectando sistemas de identidade do mundo real a smart contracts do Ethereum.

Impacto para desenvolvedores: criptografia e primitivas matemáticas

• EIP-7951 (precompile secp256r1): Os desenvolvedores ganham suporte nativo e de baixo gas para a curva secp256r1 (P-256) — a mesma criptografia usada em WebAuthn, hardware wallets e sistemas corporativos. Isso torna possível construir autenticação onchain, verificação de chave de hardware e fluxos de login seguros diretamente em smart contracts, sem depender de verificação off-chain ou bibliotecas matemáticas customizadas. Também abre caminho para integrações corporativas e institucionais, nas quais o P-256 já é padrão, dando aos desenvolvedores acesso mais fácil a sistemas reais de identidade e segurança.
• EIP-7939 (opcode CLZ): O novo opcode CLZ dá aos desenvolvedores uma forma nativa e eficiente em gas de lidar com matemática em nível de bit, removendo a necessidade de loops de 256 iterações no Solidity. Isso torna operações como log2, normalização, aleatoriedade e bitmasking muito mais baratas e simples de implementar. Protocolos com uso intenso de matemática, como AMMs, rollups, oráculos e sistemas de prova, podem esperar economias significativas de gas e uma lógica mais limpa e rápida usando esse opcode.
• Juntos, esses upgrades estendem as capacidades criptográficas e matemáticas da EVM, permitindo que os desenvolvedores construam aplicações mais seguras, mais eficientes e compatíveis com o mundo real diretamente no Ethereum.

Mudanças em gas e execução

EIP-7823 & EIP-7883: limites do MODEXP e aumento do custo de gas

O EIP-7823 e o EIP-7883 trabalham juntos para redefinir o custo e os limites da precompile MODEXP (Modular Exponentiation), uma função usada em criptografia onchain e verificação de zk-proofs. Essas atualizações limitam o tamanho máximo de entrada permitido e aumentam os custos de gas para refletir melhor a computação necessária, prevenindo potenciais vetores de negação de serviço a partir de operações matemáticas pesadas subprecificadas.

Ao apertar os limites superiores e ajustar a precificação, o Ethereum reduz o risco de abuso computacional e torna o uso de gas mais previsível para operações matemáticas complexas. Isso melhora a estabilidade de contratos que executam funções criptográficas como verificação de zk-SNARK, aritmética modular e matemática de curvas elípticas.

EIP-7825: limite de gas por transação

O EIP-7825 introduz um teto rígido para quanto gas uma única transação pode consumir. Isso garante que uma transação grande não monopolize a capacidade de um bloco inteiro nem atrase outras transações.

Isso torna a execução dos blocos mais consistente e reduz o risco de transações fora do padrão impactarem o desempenho da rede. Desenvolvedores que fazem deploy de contratos com alto uso computacional ou operações em lote grandes precisarão projetar fluxos que dividam a computação entre múltiplas transações em vez de colocar tudo em uma só.

EIP-7934: limite de tamanho de bloco de execução RLP

O EIP-7934 estabelece um novo limite para o tamanho do bloco codificado em RLP, essencialmente limitando o quão grande um bloco pode ficar quando serializado. Isso evita o crescimento excessivo dos blocos e melhora a eficiência de propagação entre os nós.

Com esse teto em vigor, a propagação de blocos se torna mais rápida e previsível, reduzindo o risco de atrasos de propagação e forks. Também padroniza o comportamento dos clients em relação a blocos grandes, melhorando a consistência entre clients.

EIP-7935: limite de gas padrão de 60m

O EIP-7935 aumenta o limite de gas padrão por bloco para 60 milhões, acima dos limites anteriores. Esse ajuste acompanha as crescentes necessidades de dados de blob e execução, dando a desenvolvedores e rollups mais espaço para processar transações complexas e operações em lote.

O teto de gas mais alto expande o espaço de bloco utilizável, permitindo lotes de rollup maiores, interações complexas de DeFi e maior throughput para aplicações com uso intenso de dados. É um benefício direto para desenvolvedores que constroem sistemas onchain que rotineiramente atingem os limites de gas de bloco anteriores.

Impacto para desenvolvedores: mudanças em gas e execução

• EIP-7823 & EIP-7883 (atualizações do MODEXP): Desenvolvedores que usam exponenciação modular para criptografia ou zk-proofs vão ver custos de gas mais altos, porém mais previsíveis. Atualize as premissas de gas em contratos de verificação e de prova para evitar chamadas subprecificadas ou reverts inesperados devido aos novos limites superiores.
• EIP-7825 (limite de gas por transação): Aplicações que fazem grandes computações ou atualizações de estado complexas precisam dividir a lógica pesada entre múltiplas transações ou adotar mecanismos de batching. Frameworks que lidam com transações de múltiplas etapas (como bridges ou sequencers) devem validar que a execução se encaixa dentro do novo teto por transação.
• EIP-7934 (limite de tamanho de bloco RLP): Provedores de infraestrutura, exploradores e ferramentas de tracing devem garantir compatibilidade com os tamanhos de bloco RLP limitados. Clients e APIs que dependem de serialização de bloco precisam lidar de forma adequada com casos-limite de blocos próximos do teto.
• EIP-7935 (limite de gas padrão de 60M): Os desenvolvedores se beneficiam de mais espaço de bloco para lotes de rollup, interações de DeFi e operações de alta frequência. Isso também dá aos builders flexibilidade para protocolos ricos em dados sem arriscar a instabilidade da rede.
• Em conjunto, esses upgrades tornam o ambiente de execução do Ethereum mais previsível, escalável e seguro, dando aos desenvolvedores uma base mais estável para apps de alto throughput, sistemas L2 e criptografia onchain.

Operações de consenso e validadores

EIP-7917: lookahead determinístico de proposer

O EIP-7917 introduz um mecanismo determinístico de lookahead de proposer para os validadores do Ethereum. Em vez de depender de aleatoriedade de curto prazo para determinar quem propõe o próximo bloco, os validadores agora podem conhecer o conjunto de proposers com vários slots de antecedência. Essa transparência reduz a incerteza e alinha a produção de blocos de forma mais previsível em toda a rede.

O lookahead determinístico melhora a coordenação entre validadores, o smoothing de MEV e a eficiência de relay de blocos. Builders, proposers e relays podem planejar com mais eficácia já que o próximo proposer é conhecido com antecedência. Também minimiza tentativas de reorg de última hora e melhora a justiça no processo de rotação de proposers.

EIP-7642: expiração de histórico e receipts mais simples

O EIP-7642 (também conhecido como eth/69) simplifica como o Ethereum lida com dados antigos da chain, introduzindo a expiração de histórico e um formato de receipt mais novo e enxuto. Dados históricos mais antigos agora podem ser removidos com segurança após um período definido, enquanto os receipts ficam mais leves e mais fáceis de verificar.

Essa mudança reduz significativamente o crescimento de estado de longo prazo para os nós, diminuindo os custos de armazenamento e melhorando os tempos de sincronização. Receipts mais simples também simplificam a verificação de provas para light clients e ferramentas de indexação. A operação de nós do Ethereum se torna mais sustentável conforme a chain continua a crescer em tamanho.

Impacto para desenvolvedores: operações de consenso e validadores

• EIP-7917 (lookahead determinístico de proposer): Operadores de validador e clients de staking devem atualizar para a nova lógica de seleção de proposer para garantir uma visão consistente dos futuros conjuntos de proposer. Builders de MEV e relays de bloco podem começar a planejar templates de bloco com mais antecedência, melhorando a latência e reduzindo condições de corrida no pipeline de submissão de blocos. Ferramentas de monitoramento e análise devem exibir as futuras rotações de proposer para transparência e coordenação entre validadores.
• EIP-7642 (expiração de histórico e receipts mais simples): Operadores de nó se beneficiam da redução no uso de disco e de pruning mais rápido, mas devem verificar as configurações do client quanto à retenção de dados caso seja necessário acesso a arquivos históricos. Desenvolvedores de infraestrutura e exploradores devem atualizar os pipelines de decodificação e indexação de receipts para corresponder à estrutura simplificada. Aplicações ou sistemas de prova que dependem de receipts de transações antigas podem precisar recorrer a serviços de arquivamento de terceiros assim que a expiração de histórico entrar em vigor.

Juntos, esses EIPs melhoram a coordenação entre validadores, a propagação de blocos e a sustentabilidade de longo prazo dos nós — dando aos desenvolvedores uma camada de consenso mais rápida, mais enxuta e mais previsível para construir.

Um Ethereum mais rápido e mais inteligente para a próxima era

O upgrade Fusaka marca mais um marco importante na evolução do Ethereum, reunindo avanços em disponibilidade de dados, eficiência de gas, previsibilidade de consenso e poder criptográfico. Para os desenvolvedores, o Fusaka entrega uma camada de execução mais eficiente, um mercado de taxas previsível e uma base criptográfica mais forte, viabilizando rollups mais rápidos, operações de nó mais leves e novos casos de uso como verificação nativa de WebAuthn e matemática de precisão onchain. O resultado é um Ethereum mais escalável, seguro e amigável para desenvolvedores, pronto para a próxima geração de aplicações de alto desempenho.

Explore os recursos

• PeerDAS e escalabilidade de blob: Aprenda como migrar para cell proofs e preparar rollups para uma capacidade de blob maior.
• Veja como times como o World escalam para milhões com rollups da Alchemy e entre em contato com nosso time para obter acesso.
• Comece a construir no Ethereum: Construa o futuro da economia da internet usando a plataforma de desenvolvimento blockchain de classe mundial da Alchemy.

Estamos aqui para ajudar você a aproveitar ao máximo o Fusaka. Entre em contato com nosso time, comece a testar na testnet do Fusaka e construa o futuro onchain.

Perguntas frequentes

Quando o upgrade Fusaka do Ethereum vai acontecer?

O upgrade Fusaka já está ativo na testnet atualmente e tem a ativação na mainnet prevista para 3 de dezembro de 2025. Desenvolvedores, operadores de nó e times de rollup devem começar os testes de integração agora para garantir compatibilidade com o PeerDAS, as atualizações do schedule de gas e as mudanças de comportamento dos clients.

Como carteiras e aplicações integram a nova precompile secp256r1 (EIP-7951)?

O Fusaka introduz uma precompile nativa para a curva elíptica secp256r1 (P-256), a mesma curva usada em WebAuthn, dispositivos FIDO2 e muitos sistemas de autenticação corporativos. Carteiras e aplicações que já dependem de WebAuthn para login agora poderão verificar assinaturas diretamente onchain sem relays ou bibliotecas criptográficas customizadas.

Para integrar, você vai referenciar o novo endereço da precompile e atualizar a lógica de verificação de assinatura para chamá-la diretamente em vez de fazer a validação off-chain. Isso torna login seguro e sem senha, além de transações baseadas em chave de hardware, significativamente mais simples de implementar.

Como o PeerDAS afeta a postagem de dados de rollup e os pipelines de DA?

O Peer Data Availability Sampling (EIP-7594) muda como os dados de blob são armazenados e validados em toda a rede: os nós agora amostram trechos dos dados de blob em vez de baixar o blob completo. Isso permite que rollups postem lotes maiores a custo menor, melhorando o throughput e reduzindo as taxas por transação.

No entanto, rollups que atualmente geram blob proofs precisam atualizar seu software para gerar cell proofs, que representam o novo formato de prova de DA. Essa é a principal mudança que quebra compatibilidade para sequencers de L2, pipelines de DA e qualquer ferramenta que prepara transações de blob.

Como o Fusaka vai impactar as taxas de gas no Ethereum e nas L2s?

O Fusaka inclui atualizações que tornam os custos de execução mais previsíveis, expandem a capacidade de gas por bloco e ajustam a precificação de certas operações criptográficas. Para os usuários, isso geralmente significa taxas menores nas L2s ao longo do tempo, já que o PeerDAS libera postagem de blob maior e mais eficiente.

Para os desenvolvedores, operações com uso intenso de gas, como exponenciação modular, passam a ser precificadas com mais precisão, então alguns contratos de verificação zk ou com uso intenso de matemática podem custar mais por chamada, mas com menos variabilidade. No geral, o Fusaka leva o Ethereum em direção a uma execução de rollup mais barata e a mercados de taxas mais estáveis em toda a stack.