Fusaka: O salto evolutivo do Ethereum rumo à escalabilidade infinita após Pectra

Depois do sucesso da atualização Pectra, a comunidade Ethereum prepara-se para o próximo grande passo. Em 3 de dezembro de 2025 chegará Fusaka, um hard fork que incorpora a visão da rede de alcançar uma escalabilidade praticamente ilimitada. O próprio nome reflete essa ambição: Fusaka combina “Fulu” (camada de execução) e “Osaka” (camada de consenso), simbolizando a integração entre os dois pilares do protocolo.

Porque Fusaka é crucial para o futuro dos Layer 2

Os últimos anos mostraram como os Rollups Layer 2 se tornaram a solução principal para os custos elevados na rede principal do Ethereum. No entanto, esses protocolos ainda enfrentam obstáculos significativos: as taxas permanecem demasiado altas em períodos de congestão, e a arquitetura da rede ainda não está otimizada para lidar com volumes massivos de dados. Fusaka aborda diretamente esses problemas através de nove propostas de melhoria (EIP), cada uma projetada para aprimorar um aspecto específico da rede.

PeerDAS (EIP-7594): Como o Ethereum verificará os dados sem sobrecarregar os nós

A introdução do EIP-4844 revolucionou a disponibilidade de dados, mas criou uma nova limitação: cada nó deve baixar enormes quantidades de blobs de dados para verificar sua autenticidade. Isso ameaça a descentralização da rede. Os requisitos de banda aumentam, o nível de descentralização diminui, e validadores menores têm dificuldade em acompanhar.

PeerDAS (EIP-7594) resolve esse dilema permitindo que os nós verifiquem a integridade dos dados baixando apenas fragmentos aleatórios, em vez de todo o conjunto de dados. O mecanismo funciona dividindo cada blob em pequenas unidades chamadas “células”, organizadas em colunas. Cada nó é responsável por algumas colunas específicas e amostra outras de peers. Se um nó coleta pelo menos 50% das colunas totais (por exemplo, 32 de 64), pode reconstruir completamente o blob graças a um código de eliminação que adiciona redundância aos dados.

Essa abordagem cria um equilíbrio: validadores, com hardware mais potente, podem armazenar volumes maiores e atuar como pontos âncora da rede. Os nós comuns permanecem participantes ativos sem suportar toda a carga computacional. A consequência? O Ethereum pode aumentar significativamente a capacidade de blobs mantendo baixos os requisitos de hardware para os participantes.

Uma regra importante acompanha essa novidade: nenhuma transação pode conter mais de 6 blobs. Esse limite protege o sistema de abusos e distribui melhor a carga na rede.

Repricing do gás: MODEXP e limites de segurança

Três EIP abordam o delicado tema do preço do gás, cada um lidando com problemas específicos no mecanismo de pré-cálculo MODEXP.

EIP-7823: Pôr um freio aos dados MODEXP

A pré-cálculo MODEXP do Ethereum historicamente aceitava entradas de tamanhos teoricamente ilimitados. Isso causou várias vulnerabilidades de consenso: cada cliente implementava a função de forma diferente, os testes tornaram-se impossíveis, e a fórmula de precificação era imprevisível.

EIP-7823 introduz uma regra simples mas fundamental: base, expoente e módulo não podem ultrapassar 1024 bytes (8192 bits). Esse limite é seguro para todas as aplicações práticas—a criptografia RSA usa chaves até 4096 bits, as curvas elípticas ainda menos. Analisando a história da blockchain de 2018 a janeiro de 2025, nenhuma chamada de MODEXP bem-sucedida ultrapassou 513 bytes. Portanto, a mudança não invalida transações históricas nem introduz novos riscos, mas elimina casos patológicos que ameaçavam a estabilidade da rede.

EIP-7825: O teto máximo de gás por transação

Outra vulnerabilidade estrutural: uma única transação pode consumir quase todo o gás disponível em um bloco (40 milhões). Se alguém envia uma transação de 38 milhões de gás, o bloco torna-se praticamente inutilizável para outras transações, criando um efeito semelhante a um ataque de negação de serviço.

EIP-7825 fixa um limite rigoroso de 16.777.216 de gás (2²⁴) por transação, independentemente do limite total do bloco. Isso garante que cada bloco contenha naturalmente mais transações, prevenindo o monopólio de uma única operação. A escolha de 2²⁴ não é arbitrária: é uma potência de 2 (fácil de implementar), grande o suficiente para contratos complexos, e cerca de metade do tamanho típico de um bloco.

O impacto na comunidade é mínimo—quase todas as transações atuais consomem bem menos de 16 milhões de gás. Apenas operações extremas precisarão ser divididas em múltiplas etapas.

EIP-7883: Recalcular o custo real do MODEXP

As operações MODEXP historicamente foram subavaliadas em relação ao seu custo computacional real. Isso cria um gargalo: os produtores de blocos processam cálculos pesados por recompensas irrisórias, e atacantes podem encher blocos com operações caras sem gastar muito.

Usando uma fórmula empírica atualizada, EIP-7883 aumenta o custo mínimo de 200 para 500 gás e triplica os custos gerais, com penalidades ainda maiores para operações com entrada superior a 32 bytes. O custo de operações com números grandes pode aumentar até 76-80 vezes. 99,69% das chamadas históricas terão pelo menos um aumento triplo. Isso não altera o funcionamento do MODEXP, mas alinha o preço ao trabalho efetivamente exigido.

Estabilidade dos blobs e previsão dos proponentes

EIP-7918: Conectar a taxa dos blobs ao custo de execução

As taxas dos blobs (introduzidas pelo EIP-4844) oscilam bastante. Quando o gás de execução domina o custo total dos Rollups, reduzir a taxa base dos blobs não aumenta a demanda—um fenômeno econômico chamado demanda inelástica. O protocolo continua a reduzir o preço até 1 gwei (o mínimo absoluto), momento em que o mecanismo para.

EIP-7918 introduz um “preço de reserva” mínimo calculado como BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB. Isso garante que a taxa base dos blobs mantenha sempre uma relação sensata com o custo de execução, criando estabilidade previsível para os Rollups. Uma análise empírica de quatro meses de dados blockchain confirma que o novo mecanismo evita quedas a 1 gwei e reduz drasticamente a volatilidade.

EIP-7917: Tornar a previsão dos proponentes completamente determinística

A seleção dos validadores proponentes para epochs futuros atualmente não é previsível. Mesmo conhecendo a seed RANDAO, mudanças nos saldos efetivos (EB) durante um epoch podem alterar a lista dos proponentes do próximo epoch. Isso cria problemas para protocolos de pré-confirmação e abre espaço para manipulações.

EIP-7917 resolve o problema introduzindo um mecanismo determinístico que calcula e armazena o planejamento dos proponentes para os próximos dois epochs completos no início de cada epoch. Uma vez determinado, a lista não muda mais devido a atualizações EB tardias. Essa previsibilidade é essencial para a estabilidade dos Layer 2 e previne o “balance brushing”—tentativas de validadores manipularem seus saldos após verem o RANDAO.

Segurança e eficiência da rede

EIP-7934: Um limite ao tamanho dos blocos

Sem limites na dimensão RLP dos blocos, um atacante pode criar blocos gigantescos que paralisam os nós e atrasam a propagação. EIP-7934 fixa o limite máximo em 10 MiB (com uma margem de segurança de 2 MiB), alinhando-se ao limite já vigente no protocolo gossip da camada de consenso. Isso elimina incoerências entre os layers e previne ataques DoS baseados em tamanhos excessivos.

EIP-7939: O opcode CLZ para operações rápidas em bits

Desenvolvedores historicamente tiveram que implementar manualmente funções de contagem de zeros iniciais em Solidity, consumindo gás excessivo e bytecode volumoso. EIP-7939 introduz um novo opcode nativo CLZ (0x1e) ao custo de 5 gás, o mesmo de ADD. Isso acelera bibliotecas matemáticas, algoritmos de compressão, bitmap, esquemas de assinatura e operações criptográficas, reduzindo taxas e custos de provas de conhecimento zero.

EIP-7951: Suporte nativo para assinaturas modernas de hardware

Apple Secure Enclave, Android Keystore, FIDO2/WebAuthn e dispositivos de segurança de hardware usam a curva secp256r1 (P-256). EIP-7951 introduz uma pré-cálculada P256VERIFY no endereço 0x100, permitindo que o Ethereum verifique assinaturas ECDSA na curva P-256 de forma segura e nativa, ao custo de 6900 gás. Isso corrige vulnerabilidades de segurança da proposta anterior (RIP-7212) e finalmente permite que usuários acessem carteiras suportadas por hardware moderno com a mesma simplicidade do Ethereum.

Conclusão: A infraestrutura escalável de amanhã

Fusaka não é uma mudança revolucionária isolada, mas uma série coordenada de melhorias que enfrentam limitações específicas da rede. PeerDAS habilita a escalabilidade de dados, os repricing do gás garantem estabilidade econômica, o determinismo dos proponentes reforça a previsibilidade, e as novas primitivas otimizam a eficiência.

O resultado é um Ethereum preparado para o futuro: Layer 2 Rollups poderão operar com custos menores e maior velocidade, os nós permanecem descentralizados graças aos mecanismos de amostragem, e a segurança da rede é consolidada por limites e incentivos bem calibrados. Quando Fusaka for ativado em 3 de dezembro de 2025, marcará oficialmente a transição para a infraestrutura de escalabilidade infinita que o Ethereum sempre prometeu.