Depois de Pectra, vem Fusaka: o passo mais crucial do Ethereum rumo à “expansão infinita”

A hard fork Fusaka, prevista para ser ativada em 3 de dezembro de 2025, é uma atualização de rede significativa do Ethereum após a Pectra, marcando mais um passo importante deste gigante cripto em direção à escalabilidade.

Os EIPs da atualização Pectra focam em melhorar desempenho, segurança e ferramentas para desenvolvedores. Já os EIPs da atualização Fusaka concentram-se em escalabilidade, atualização de opcodes e segurança de execução.

O PeerDAS (EIP-7594) melhora a disponibilidade de dados ao permitir que os nós verifiquem blobs sem precisar baixar todos os dados. Várias atualizações também reforçam a segurança de execução, incluindo a limitação do ModExp (EIP-7823), limitação do gas máximo por transação (EIP-7825) e atualização do custo de gas do ModExp (EIP-7883). Esta atualização Fusaka também melhora a geração de blocos através de um mecanismo determinístico de previsão de proponentes (EIP-7917) e mantém a estabilidade das taxas de blob ao definir um “preço de reserva” vinculado ao custo de execução (EIP-7918).

Outras melhorias incluem a limitação do tamanho dos blocos em formato RLP (EIP-7934), a adição do novo opcode CLZ para acelerar operações de bits (EIP-7939) e a introdução da pré-compilação secp256r1 (EIP-7951) para melhor compatibilidade com criptografia moderna e chaves de segurança de hardware.

Fusaka é uma combinação de Fulu (camada de execução) e Osaka (camada de consenso). Representa mais um passo do Ethereum em direção a um futuro altamente escalável e rico em dados, onde os rollups de Layer 2 podem operar com custos mais baixos e maior velocidade.

Este artigo irá analisar em profundidade as 9 principais propostas EIP do hard fork Fusaka.

EIP-7594: PeerDAS — Amostragem de Disponibilidade de Dados pelos Nós

O Ethereum precisa desta proposta porque a rede pretende oferecer maior disponibilidade de dados aos utilizadores (especialmente aos utilizadores de rollups).

No entanto, sob o design atual do EIP-4844, cada nó ainda precisa baixar grandes quantidades de dados blob para verificar se foram publicados. Isso cria problemas de escalabilidade, pois se todos os nós tiverem de baixar todos os dados, as exigências de largura de banda e hardware da rede aumentam e o grau de descentralização é afetado. Para resolver este problema, o Ethereum precisa de um método que permita aos nós confirmar a disponibilidade dos dados sem ter de baixar tudo.

A amostragem de disponibilidade de dados (DAS) resolve este problema ao permitir que os nós verifiquem apenas uma pequena quantidade de dados aleatórios.

No entanto, o Ethereum também precisa de um método DAS compatível com a rede Gossip existente e que não imponha uma carga computacional pesada aos produtores de blocos. O PeerDAS foi criado precisamente para satisfazer estas necessidades e aumentar com segurança o throughput de blobs mantendo as exigências dos nós baixas.

PeerDAS é um sistema de rede que permite aos nós baixar apenas pequenos fragmentos de dados para verificar se os dados completos foram publicados. Os nós não precisam baixar todos os dados, mas sim usar a rede gossip normal para partilhar dados, descobrir quais nós possuem partes específicas dos dados e solicitar apenas uma pequena amostra necessária. A ideia central é que, ao baixar apenas uma pequena parte aleatória dos fragmentos de dados, os nós ainda podem confiar na existência do fragmento completo. Por exemplo, um nó pode baixar apenas cerca de 1/8 dos dados, em vez de baixar o fragmento completo de 256 KB — mas como muitos nós amostram partes diferentes, qualquer dado em falta será rapidamente detetado.

Para implementar a amostragem, o PeerDAS utiliza um código de correção de erros básico para expandir cada fragmento de dados do EIP-4844. Um código de correção de erros é uma técnica que adiciona dados redundantes extras, permitindo recuperar os dados originais mesmo que alguns fragmentos estejam em falta — semelhante a um puzzle que pode ser completado mesmo com algumas peças em falta.

O blob transforma-se numa “linha” que contém os dados originais e alguns dados codificados extra, permitindo a reconstrução posterior. Esta linha é então dividida em muitos pequenos blocos chamados “células”, que são a menor unidade de verificação associada ao compromisso KZG. Todas as “linhas” são então reorganizadas em “colunas”, cada coluna contendo células da mesma posição de todas as linhas. Cada coluna é atribuída a uma sub-rede gossip específica.

Os nós são responsáveis por armazenar determinadas colunas com base no seu ID de nó e, em cada slot, amostram algumas colunas dos nós pares. Se um nó recolher pelo menos 50% das colunas, pode reconstruir completamente os dados. Se recolher menos de 50%, deve solicitar as colunas em falta aos pares. Isto garante que, se os dados foram realmente publicados, podem sempre ser reconstruídos. Em resumo, se houver 64 colunas no total, um nó só precisa de cerca de 32 para reconstruir o blob completo. Ele guarda algumas colunas e baixa outras dos pares. Desde que metade das colunas estejam presentes na rede, o nó pode reconstruir tudo, mesmo que algumas estejam em falta.

Além disso, o EIP-7594 introduz uma regra importante: nenhuma transação pode conter mais de 6 blobs. Este limite deve ser aplicado durante a verificação da transação, propagação gossip, criação e processamento de blocos. Isto ajuda a reduzir casos extremos em que uma única transação sobrecarrega o sistema de blobs.

O PeerDAS adiciona uma funcionalidade chamada “prova KZG de célula”. A prova KZG de célula demonstra que o compromisso KZG corresponde realmente a uma célula específica (uma pequena unidade) dentro do blob. Isto permite que os nós baixem apenas as células que desejam amostrar. Obtendo o blob completo com garantia de integridade dos dados, o que é fundamental para a amostragem de disponibilidade de dados.

No entanto, o custo de gerar todas estas provas de célula é elevado. Os produtores de blocos precisam calcular repetidamente estas provas para muitos blobs, tornando o processo demasiado lento. Contudo, o custo de verificação das provas é muito baixo, por isso, o EIP-7594 exige que o remetente da transação blob gere antecipadamente todas as provas de célula e as inclua no wrapper da transação.

Por este motivo, o gossip de transações (PooledTransactions) agora utiliza um wrapper modificado:

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

No novo wrapper, cell_proofs é apenas uma lista que contém todas as provas de cada célula de cada blob (por exemplo: [cell_proof_0, cell_proof_1, ...]). Os outros campos tx_payload_body, blobs e commitments são exatamente os mesmos do EIP-4844. A diferença é que o campo “proofs” original foi removido e substituído pela nova lista cell_proofs, sendo adicionado também um campo chamado wrapper_version para indicar o formato do wrapper utilizado.

O PeerDAS permite ao Ethereum aumentar a disponibilidade de dados sem aumentar a carga de trabalho dos nós. Atualmente, um nó só precisa de amostrar cerca de 1/8 dos dados totais. No futuro, esta proporção poderá descer para 1/16 ou 1/32, melhorando assim a escalabilidade do Ethereum. O sistema funciona bem porque cada nó tem muitos pares, por isso, se um par não puder fornecer os dados necessários, o nó pode pedir a outros. Isto cria naturalmente um mecanismo de redundância e aumenta a segurança, sendo que os nós também podem optar por armazenar mais dados do que o necessário, reforçando ainda mais a segurança da rede.

Os nós validadores têm mais responsabilidades do que os nós completos normais. Como os validadores operam hardware mais potente, o PeerDAS atribui-lhes uma carga de armazenamento de dados proporcional ao número total de validadores. Isto garante que há sempre um grupo estável de nós para armazenar e partilhar mais dados, aumentando a fiabilidade da rede. Em resumo, se houver 900.000 validadores, cada um pode ser responsável por armazenar e servir uma pequena parte dos dados totais. Como os validadores têm máquinas mais potentes, a rede pode confiar que garantirão a disponibilidade dos dados.

O PeerDAS utiliza amostragem por colunas em vez de por linhas porque isso simplifica muito a reconstrução dos dados. Se os nós amostrassem linhas inteiras (o blob completo), seria necessário criar “blobs expandidos” adicionais que não existiam originalmente, o que tornaria a produção de blocos mais lenta.

Através da amostragem por colunas, os nós podem preparar previamente dados de linhas extra, sendo o remetente da transação (e não o produtor de blocos) a calcular as provas necessárias. Isto mantém a criação de blocos rápida e eficiente. Por exemplo: suponha que um blob é uma grelha de 4×4 células. Amostragem por linha significa retirar todas as 4 células de uma linha, mas algumas linhas expandidas ainda não estão prontas, obrigando o produtor de blocos a gerá-las no momento; amostragem por coluna é retirar uma célula de cada linha (de cada coluna), podendo as células extra necessárias ser preparadas antecipadamente, permitindo aos nós validar os dados sem abrandar a geração de blocos.

O EIP-7594 é totalmente compatível com o EIP-4844, pelo que não quebra nenhuma funcionalidade existente no Ethereum. Todos os testes e regras detalhadas estão incluídos nas especificações de consenso e execução.

O principal risco de segurança de qualquer sistema DAS é o “ataque de ocultação de dados”, em que o produtor de blocos finge que os dados estão disponíveis, mas esconde parte deles. O PeerDAS previne isto usando amostragem aleatória: os nós verificam partes aleatórias dos dados. Quanto mais nós amostram, mais difícil é para um atacante enganar. O EIP-7594 até fornece uma fórmula para calcular a probabilidade de sucesso de tal ataque com base no número total de nós (n), número total de amostras (m) e número de amostras por nó (k). Na mainnet do Ethereum, com cerca de 10.000 nós, a probabilidade de sucesso do ataque é extremamente baixa, pelo que o PeerDAS é considerado seguro.

EIP-7823: Definir limite de 1024 bytes para o MODEXP

A necessidade desta proposta reside no facto de o mecanismo de pré-compilação MODEXP do Ethereum ter causado várias vulnerabilidades de consenso ao longo dos anos. Estas vulnerabilidades devem-se principalmente ao facto de o MODEXP permitir quantidades de dados de entrada extremamente grandes e irrealistas, obrigando os clientes a lidar com inúmeros casos excecionais.

Como cada nó tem de processar todos os dados de entrada fornecidos pela transação, a ausência de um limite torna o MODEXP mais difícil de testar, mais propenso a erros e mais suscetível a comportamentos divergentes entre clientes diferentes. Entradas de dados excessivamente grandes também tornam a fórmula de custo de gas imprevisível, pois é difícil definir preços quando o volume de dados pode crescer indefinidamente. Estes problemas também dificultam a substituição futura do MODEXP por código ao nível da EVM usando ferramentas como EVMMAX, pois sem um limite fixo, os programadores não conseguem criar caminhos de execução seguros e otimizados.

Para reduzir estes problemas e melhorar a estabilidade do Ethereum, o EIP-7823 adiciona um limite rigoroso ao volume de dados de entrada do MODEXP, tornando o processo de pré-compilação mais seguro, fácil de testar e previsível.

O EIP-7823 introduz uma regra simples: todos os três campos de comprimento usados pelo MODEXP (base, expoente e módulo) devem ser menores ou iguais a 8192 bits, ou seja, 1024 bytes. A entrada do MODEXP segue o formato definido no EIP-198: <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>, pelo que este EIP limita apenas os valores de comprimento. Se algum comprimento exceder 1024 bytes, a pré-compilação é imediatamente interrompida, retorna erro e consome todo o gas.

Por exemplo, se alguém tentar fornecer uma base com 2000 bytes, a chamada falhará antes de qualquer trabalho ser iniciado. Estes limites continuam a satisfazer todos os cenários de aplicação prática. A verificação RSA normalmente utiliza chaves de 1024, 2048 ou 4096 bits, todos dentro do novo limite. Operações de curvas elípticas usam tamanhos de entrada ainda menores, normalmente abaixo de 384 bits, pelo que também não são afetadas.

Estes novos limites também facilitam futuras atualizações. Se no futuro o MODEXP for reescrito como código EVM usando o EVMMAX, os programadores podem adicionar caminhos otimizados para tamanhos de entrada comuns (por exemplo, 256, 381 ou 2048 bits) e usar um fallback mais lento para casos raros. Com um tamanho máximo fixo, os programadores podem até adicionar tratamento especial para módulos muito comuns. Antes, devido à ausência de limites, o espaço de design era demasiado vasto para ser gerido com segurança, tornando estas otimizações inviáveis.

Para confirmar que esta alteração não quebra transações passadas, o autor analisou todas as utilizações do MODEXP do bloco 5.472.266 (20 de abril de 2018) ao bloco 21.550.926 (4 de janeiro de 2025). O resultado mostra que todas as chamadas MODEXP bem-sucedidas na história nunca usaram entradas superiores a 513 bytes, muito abaixo do novo limite de 1024 bytes. A maioria das chamadas reais usou comprimentos menores, como 32, 128 ou 256 bytes.

Existem algumas chamadas inválidas ou corrompidas, como entradas vazias, entradas preenchidas com bytes repetidos e uma entrada muito grande mas inválida. Estas chamadas continuam inválidas sob o novo limite, pois já eram inválidas por si só. Portanto, embora o EIP-7823 seja tecnicamente uma alteração significativa, na prática não altera o resultado de nenhuma transação passada.

Do ponto de vista da segurança, reduzir o tamanho permitido das entradas não traz novos riscos. Pelo contrário, elimina casos extremos desnecessários que anteriormente causavam erros e inconsistências entre clientes. Ao limitar as entradas do MODEXP a um intervalo razoável, o EIP-7823 torna o sistema mais previsível, reduz casos extremos estranhos e diminui a probabilidade de erros entre implementações diferentes. Estes limites também ajudam a preparar o sistema para futuras atualizações (como o EVMMAX) que possam introduzir caminhos de execução otimizados, permitindo uma transição mais suave.

EIP-7825: Limite de Gas de 16,7 milhões por transação

O Ethereum realmente precisa desta proposta porque atualmente uma única transação pode consumir quase todo o limite de gas de um bloco.

Isto causa vários problemas: uma transação pode consumir a maior parte dos recursos do bloco, causando atrasos semelhantes a ataques DoS; operações que consomem muito gas aumentam rapidamente o estado do Ethereum; a validação de blocos torna-se mais lenta, dificultando que os nós acompanhem.

Se um utilizador submeter uma transação que consome quase todo o gas do bloco (por exemplo, uma transação que consome 38 milhões de gas num bloco de 40 milhões), outras transações normais não podem ser incluídas nesse bloco e cada nó tem de gastar tempo extra a validar o bloco. Isto ameaça a estabilidade e descentralização da rede, pois a validação mais lenta faz com que nós menos potentes fiquem para trás. Para resolver este problema, o Ethereum precisa de um limite seguro de gas, restringindo a quantidade de gas que uma única transação pode usar, tornando a carga do bloco mais previsível, reduzindo o risco de ataques DoS e equilibrando a carga dos nós.

O EIP-7825 introduz uma regra rígida: nenhuma transação pode consumir mais de 16.777.216 (2²⁴) de gas. Este é um limite ao nível do protocolo, aplicando-se a todas as etapas: envio de transações, verificação no mempool e inclusão em blocos pelos validadores. Se alguém enviar uma transação com um limite de gas superior a este valor, o cliente deve rejeitá-la imediatamente e retornar um erro semelhante a MAX_GAS_LIMIT_EXCEEDED.

Este limite é totalmente independente do limite de gas do bloco. Por exemplo, mesmo que o limite de gas do bloco seja 40 milhões, nenhuma transação individual pode consumir mais de 16,7 milhões. O objetivo é garantir que cada bloco possa conter várias transações, em vez de uma única transação ocupar todo o bloco.

Para ilustrar, suponha que um bloco pode conter 40 milhões de gas. Sem este limite, alguém poderia enviar uma transação que consome entre 35 e 40 milhões de gas. Esta transação monopolizaria o bloco, não deixando espaço para outras, como se uma pessoa alugasse um autocarro inteiro e ninguém mais pudesse entrar. O novo limite de 16,7 milhões de gas fará com que o bloco contenha naturalmente várias transações, evitando este tipo de abuso.

A proposta também define requisitos específicos para a verificação das transações pelos clientes. Se o gas de uma transação exceder 16.777.216, o mempool deve rejeitá-la, o que significa que nem sequer entra na fila. Durante a validação do bloco, se o bloco contiver uma transação acima do limite, o bloco deve ser rejeitado.

O valor 16.777.216 (2²⁴) foi escolhido por ser uma potência de 2 clara, facilitando a implementação, e ainda suficientemente grande para lidar com a maioria das transações reais. Por exemplo, deploys de contratos inteligentes, interações DeFi complexas ou chamadas de contratos multi-etapas. Este valor é cerca de metade do tamanho típico de um bloco, o que significa que mesmo as transações mais complexas podem ser facilmente controladas dentro deste limite.

Este EIP mantém a compatibilidade com o mecanismo de gas existente. A maioria dos utilizadores não notará a mudança, pois quase todas as transações atuais consomem muito menos que 16 milhões. Os validadores e produtores de blocos ainda podem criar blocos com gas total acima de 16,7 milhões, desde que cada transação respeite o novo limite.

As únicas transações afetadas são aquelas que antes tentavam usar mais do que o novo limite. Estas agora terão de ser divididas em várias operações menores, como dividir um ficheiro muito grande em dois menores para upload. Tecnicamente, esta alteração não é retrocompatível para estas transações extremas, mas espera-se que o número de utilizadores afetados seja muito pequeno.

Em termos de segurança, o limite de gas torna o Ethereum mais resistente a ataques DoS baseados em gas, pois os atacantes já não podem forçar os validadores a processar transações gigantescas. Também ajuda a manter o tempo de validação dos blocos previsível, facilitando a sincronização dos nós. O principal caso extremo é que alguns deploys de contratos muito grandes podem não cumprir o limite e terão de ser redesenhados ou divididos em várias etapas.

No geral, o EIP-7825 visa reforçar a proteção da rede contra abusos, manter as exigências dos nós razoáveis, aumentar a justiça na utilização do espaço dos blocos e garantir que, com o aumento do limite de gas, a blockchain continue a funcionar de forma rápida e estável.

EIP-7883: Aumento do custo de gas do ModExp

O Ethereum precisa desta proposta porque o preço da pré-compilação ModExp (usada para operações de exponenciação modular) tem sido demasiado baixo em relação aos recursos realmente consumidos.

Em certos casos, a quantidade de computação necessária para uma operação ModExp excede em muito o que os utilizadores atualmente pagam. Esta discrepância traz riscos: se chamadas ModExp complexas forem demasiado baratas, podem tornar-se um gargalo, dificultando o aumento seguro do limite de gas do bloco. Os produtores de blocos podem ser forçados a processar operações extremamente pesadas a um custo muito baixo.

Para resolver isto, o Ethereum precisa de ajustar a fórmula de preços do ModExp, para que o consumo de gas reflita com precisão o trabalho real realizado pelos clientes. Assim, o EIP-7883 introduz novas regras, aumentando o custo mínimo de gas, aumentando o custo total e tornando operações com grandes volumes de dados de entrada (especialmente expoentes, bases ou módulos acima de 32 bytes) mais caras, alinhando o preço do gas com o esforço computacional real.

A proposta aumenta o custo em vários aspetos importantes, modificando o algoritmo de preços do ModExp originalmente definido no EIP-2565.

Primeiro, o consumo mínimo de gas sobe de 200 para 500, e o consumo total de gas deixa de ser dividido por 3, o que significa que o custo total de gas triplica. Por exemplo, se antes uma chamada ModExp consumia 1200 gas, agora consumirá cerca de 3600 gas.

Segundo, operações com expoentes superiores a 32 bytes duplicam o custo, pois o multiplicador passa de 8 para 16. Por exemplo, se o expoente tiver 40 bytes, o EIP-2565 aumentava o número de iterações em 8 × (40 − 32) = 64, enquanto o EIP-7883 usa 16 × (40 − 32) = 128, duplicando o custo.

Terceiro, o preço agora assume um tamanho mínimo de base/módulo de 32 bytes, e quando estes valores excedem 32 bytes, o custo computacional aumenta drasticamente. Por exemplo, se o módulo tiver 64 bytes, a nova regra aplica o dobro da complexidade (2 × words²), em vez da fórmula mais simples anterior, refletindo o custo real de operações com números grandes. Estas alterações garantem que operações ModExp pequenas pagam um mínimo razoável, e operações grandes e complexas têm o custo ajustado ao seu tamanho.

A proposta define uma nova função de cálculo de gas, atualizando as regras de complexidade e número de iterações. A complexidade da multiplicação agora usa o valor padrão 16 para bases/módulos até 32 bytes, e para entradas maiores, muda para a fórmula mais complexa 2 × words², onde “words” é o número de blocos de 8 bytes. O número de iterações também foi atualizado: expoentes até 32 bytes usam o comprimento em bits para determinar a complexidade, enquanto expoentes maiores recebem uma penalização de gas maior.

Isto garante que operações com expoentes muito grandes, que são realmente dispendiosas, agora têm custos de gas mais altos. Importa referir que o custo mínimo de gas é forçado a 500, em vez dos 200 anteriores, tornando mesmo as chamadas ModExp mais simples mais razoáveis.

O aumento dos preços foi motivado por benchmarks que mostraram que, em muitos casos, o preço da pré-compilação ModExp era claramente demasiado baixo. A fórmula revista aumenta o custo de gas de operações pequenas em 150%, operações típicas em cerca de 200% e operações grandes ou desequilibradas em múltiplos ainda maiores, por vezes mais de 80 vezes, dependendo do tamanho do expoente, base ou módulo.

O objetivo não é alterar o funcionamento do ModExp, mas garantir que, mesmo nos casos extremos de maior consumo de recursos, não ameaça a estabilidade da rede nem impede futuros aumentos do limite de gas do bloco. Como o EIP-7883 altera o gas necessário para o ModExp, não é retrocompatível, mas a reprecificação de gas já ocorreu várias vezes no Ethereum e é bem compreendida.

Os testes mostram que o aumento do custo de gas é muito significativo. Cerca de 99,69% das chamadas ModExp históricas agora exigem 500 gas (antes 200) ou três vezes o preço anterior. Mas alguns casos de teste de carga elevada têm aumentos ainda maiores. Por exemplo, num teste “intensivo em operações de expoente”, o consumo de gas subiu de 215 para 16.624, cerca de 76 vezes mais, porque agora o preço para expoentes muito grandes é mais realista.

Em termos de segurança, a proposta não introduz novas vias de ataque nem reduz o custo de nenhuma operação. Pelo contrário, foca-se em prevenir um risco importante: operações ModExp subvalorizadas podem permitir a um atacante encher blocos com cálculos extremamente pesados a custo quase nulo. O único possível inconveniente é que algumas operações ModExp podem ficar demasiado caras, mas isso é preferível ao problema atual de preços demasiado baixos. A proposta não introduz alterações de interface nem novas funcionalidades, pelo que o comportamento aritmético e os vetores de teste existentes continuam válidos.

EIP-7917: Previsão precisa do próximo proponente

O Ethereum precisa desta proposta porque o agendamento dos proponentes do próximo epoch na rede não é totalmente previsível. Mesmo quando a semente RANDAO do epoch N+1 é conhecida no epoch N, a lista real de proponentes pode mudar devido a atualizações do saldo efetivo (EB) dentro do epoch N.

Estas alterações de EB podem resultar de penalizações, punições, recompensas superiores a 1 ETH, fusão de validadores ou novos depósitos, especialmente após o EIP-7251 aumentar o saldo efetivo máximo para mais de 32 ETH. Esta incerteza cria problemas para sistemas que dependem de saber antecipadamente quem será o próximo proponente (por exemplo, protocolos baseados em pré-confirmação), que precisam de um calendário estável e previsível para funcionar corretamente. Os validadores podem até tentar “manipular” ou ajustar o seu saldo efetivo para influenciar o proponente do próximo epoch.

Devido a estes problemas, o Ethereum precisa de um método para tornar o calendário dos proponentes totalmente determinístico para os próximos epochs, de modo a não ser afetado por atualizações de EB de última hora e ser facilmente acessível pela camada de aplicação.

Para isso, o EIP-7917 introduz um mecanismo determinístico de previsão de proponentes, pré-calculando e armazenando o agendamento dos proponentes para os próximos MIN_SEED_LOOKAHEAD + 1 epochs no início de cada epoch. Em termos simples, o estado do beacon agora inclui uma lista chamada `prosoperer_lookahead`, que cobre sempre dois ciclos completos de proponentes (um total de 64 slots).

Por exemplo, quando o epoch N começa, esta lista já contém o proponente de cada slot dos epochs N e N+1. Depois, quando a rede entra no epoch N+1, a lista avança: remove as entradas do epoch N, move as do epoch N+1 para o início e adiciona as novas entradas do epoch N+2 no final. Isto torna o agendamento fixo, previsível e acessível diretamente pelos clientes, sem necessidade de recálculo a cada slot.

Para manter a atualização, a lista avança a cada fronteira de epoch: remove os dados do epoch anterior e calcula o conjunto de novos índices de proponentes para o próximo epoch futuro, adicionando-os à lista. O processo usa as mesmas regras de semente e saldo efetivo de antes, mas agora o agendamento é calculado mais cedo, evitando que alterações de saldo após a semente afetem o resultado. O primeiro bloco após o fork também preenche todo o intervalo de previsão, garantindo que todos os epochs futuros tenham o agendamento corretamente inicializado.

Suponha que cada epoch tem 8 slots em vez de 32 (para simplificar). Sem este EIP, durante o epoch 5, mesmo conhecendo a semente do epoch 6, se um validador for penalizado ou receber recompensas suficientes para alterar o saldo efetivo durante o epoch 5, o proponente real do slot 2 do epoch 6 ainda pode mudar. Com o EIP-7917, o Ethereum pré-calcula todos os proponentes dos epochs 5, 6 e 7 no início do epoch 5 e armazena-os em ordem em `prosopers_lookahead`. Assim, mesmo que o saldo mude no final do epoch 5, a lista de proponentes do epoch 6 permanece fixa e previsível.

O EIP-7917 corrige uma falha de design de longa data na beacon chain. Garante que, assim que a RANDAO do epoch anterior estiver disponível, a escolha dos validadores para os epochs futuros não pode ser alterada. Isto também previne a “manipulação do saldo efetivo”, em que validadores tentam ajustar o saldo após ver a RANDAO para influenciar a lista de proponentes do próximo epoch. O mecanismo determinístico de previsão elimina todo esse vetor de ataque, simplificando muito a análise de segurança. Também permite que os clientes de consenso saibam antecipadamente quem irá propor os próximos blocos, facilitando a implementação e permitindo que a camada de aplicação verifique facilmente o calendário dos proponentes através de provas Merkle da raiz do beacon.

Antes desta proposta, os clientes calculavam apenas o proponente do slot atual. Com o EIP-7917, agora calculam de uma só vez a lista de proponentes de todos os slots do próximo epoch durante cada transição de epoch. Isto aumenta ligeiramente o trabalho, mas o cálculo dos índices de proponentes é muito leve, envolvendo principalmente a amostragem da lista de validadores usando a semente. No entanto, os clientes devem fazer benchmarks para garantir que este cálculo extra não causa problemas de desempenho.

EIP-7918: Taxa base do Blob limitada pelo custo de execução

O Ethereum precisa desta proposta porque o sistema atual de taxas de blob (derivado do EIP-4844) falha quando o gas de execução se torna o principal custo dos rollups.

Atualmente, a maioria dos rollups paga muito mais pelo gas de execução (o custo de incluir transações blob no bloco) do que pela taxa real do blob. Isto cria um problema: mesmo que o Ethereum continue a baixar a taxa base do blob, o custo total dos rollups praticamente não muda, pois a parte mais cara continua a ser o gas de execução. Assim, a taxa base do blob continua a descer até ao valor mínimo absoluto (1 wei), altura em que o protocolo já não pode usar a taxa do blob para controlar a procura. Depois, quando o uso do blob aumenta repentinamente, a taxa demora muitos blocos a voltar ao normal. Isto torna o preço instável e imprevisível para os utilizadores.

Por exemplo, suponha que um rollup quer publicar os seus dados: precisa de pagar cerca de 25.000.000 gwei de gas de execução (cerca de 1.000.000 gas a 25 gwei), enquanto a taxa do blob é apenas cerca de 200 gwei. Isto significa um custo total de cerca de 25.000.200 gwei, quase todo devido ao gas de execução, não à taxa do blob. Se o Ethereum continuar a baixar a taxa do blob, por exemplo de 200 para 50, depois para 10 e finalmente para 1 gwei, o custo total quase não muda, permanecendo em 25.000.000 gwei.

O EIP-7918 resolve este problema ao introduzir um “preço de reserva” mínimo baseado no custo base de execução, impedindo que o preço do blob fique demasiado baixo e tornando o preço dos blobs dos rollups mais estável e previsível.

A ideia central do EIP-7918 é simples: o preço do blob nunca deve ser inferior a uma determinada quantidade de custo de gas de execução (chamada BLOB_BASE_COST). O valor de calc_excess_blob_gas() é definido como 2¹³, e este mecanismo é implementado através de uma pequena modificação da função calc_excess_blob_gas().

Normalmente, esta função aumenta ou diminui a taxa base do blob consoante o uso de blob gas no bloco esteja acima ou abaixo do alvo. Com esta proposta, se o blob ficar “demasiado barato” em relação ao gas de execução, a função deixa de deduzir o alvo de blob gas. Isto faz com que o excesso de blob gas cresça mais rapidamente, impedindo que a taxa base do blob desça ainda mais. Assim, a taxa base do blob agora tem um valor mínimo igual a BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB.

Para perceber a necessidade disto, vejamos a procura de blobs. Os rollups preocupam-se com o custo total: custo de execução mais custo do blob. Se o gas de execução for muito caro, por exemplo 20 gwei, mesmo que a taxa do blob desça de 2 para 0,2 gwei, o custo total quase não muda. Isto significa que baixar a taxa base do blob tem pouco efeito na procura. Em economia, isto chama-se “falta de elasticidade do preço”. Cria uma curva de procura quase vertical: baixar o preço não aumenta a procura.

Neste cenário, o mecanismo de taxa base do blob torna-se cego — mesmo sem resposta da procura, continua a baixar o preço. É por isso que a taxa base do blob frequentemente desce até 1 gwei. Depois, quando a procura aumenta, o protocolo precisa de quase uma hora de blocos cheios para voltar a subir a taxa para um nível razoável. O EIP-7918 resolve isto ao estabelecer um preço de reserva vinculado ao gas de execução, garantindo que, mesmo quando o custo de execução domina, a taxa do blob continua relevante.

Outro motivo para adicionar este preço de reserva é que os nós precisam de fazer muito mais trabalho para verificar as provas KZG dos dados blob. Estas provas garantem que os dados do blob correspondem ao seu compromisso. Sob o EIP-4844, os nós só precisavam de verificar uma prova por blob, com baixo custo. Mas no EIP-7918, o número de provas a verificar aumenta. Isto deve-se ao facto de, no EIP-7594 (PeerDAS), o blob ser dividido em muitos pequenos blocos chamados células, cada um com a sua própria prova, aumentando muito o trabalho de verificação.

A longo prazo, o EIP-7918 também ajuda o Ethereum a preparar-se para o futuro. À medida que a tecnologia avança, o custo de armazenar e partilhar dados naturalmente desce, e espera-se que o Ethereum permita armazenar mais dados blob ao longo do tempo. Quando a capacidade de blobs aumenta, a taxa do blob (em ETH) desce naturalmente. Esta proposta suporta isso, pois o preço de reserva é vinculado ao preço do gas de execução, não a um valor fixo, podendo ajustar-se ao crescimento da rede.

À medida que o espaço de blobs e o espaço de execução dos blocos aumentam, a relação entre os seus preços mantém-se equilibrada. Só em casos raros, se o Ethereum aumentar muito a capacidade de blobs sem aumentar a de execução, o preço de reserva pode ficar demasiado alto. Nesse caso, a taxa do blob pode acabar acima do necessário. Mas o Ethereum não planeia escalar desta forma — espera-se que o espaço de blobs e de execução cresçam em conjunto. Por isso, o valor escolhido (BLOB_BASE_COST = 2¹³) é considerado seguro e equilibrado.

Quando o custo do gas de execução sobe subitamente, há um pequeno detalhe a considerar. Como o preço do blob depende da taxa base de execução, um aumento súbito do custo de execução pode fazer com que a taxa do blob fique temporariamente dominada pelo custo de execução. Por exemplo, se o gas de execução subir de 20 para 60 gwei num bloco, o preço do blob não pode descer abaixo desse novo patamar. Se o blob continuar a ser usado, a taxa crescerá normalmente, mas o protocolo não permitirá que desça até igualar o novo custo de execução. Isto significa que, durante alguns blocos, a taxa do blob pode crescer mais devagar do que o custo de execução. Este atraso temporário não é prejudicial — na verdade, previne oscilações bruscas no preço do blob e torna o sistema mais estável.

O autor também fez uma análise empírica da atividade real de transações em blocos de novembro de 2024 a março de 2025, aplicando a regra do preço de reserva. Em períodos de taxas de execução elevadas (média de cerca de 16 gwei), o limiar de reserva aumentou significativamente a taxa base dos blocos em comparação com o mecanismo antigo. Em períodos de taxas baixas (média de cerca de 1,3 gwei), a taxa dos blocos manteve-se praticamente inalterada, exceto quando a taxa calculada ficava abaixo do preço de reserva. Comparando milhares de blocos, o autor mostra que o novo mecanismo cria preços mais estáveis, mantendo a resposta natural à procura. O histograma das taxas dos blocos ao longo de quatro meses mostra que o preço de reserva impede que as taxas caiam para 1 gwei, reduzindo a volatilidade extrema.

Em termos de segurança, esta alteração não introduz riscos. A taxa base dos blocos será sempre igual ou superior ao custo unitário de BLOB_BASE_COST de gas de execução. Isto é seguro, pois o mecanismo apenas aumenta a taxa mínima e definir um preço mínimo não afeta a correção do protocolo. Apenas garante o funcionamento saudável da economia.

EIP-7934: Limite ao tamanho dos blocos de execução RLP

Antes do EIP-7934, o Ethereum não tinha um limite rigoroso ao tamanho dos blocos de execução codificados em RLP. Em teoria, se um bloco contivesse muitas transações ou dados muito complexos, o seu tamanho poderia ser enorme. Isto causava dois problemas principais: instabilidade da rede e risco de ataques de negação de serviço (DoS).

Se um bloco for demasiado grande, o tempo necessário para os nós o descarregarem e validarem aumenta, abrandando a propagação dos blocos e aumentando a probabilidade de forks temporários na blockchain. Pior ainda, um atacante pode criar um bloco enorme para sobrecarregar os nós, causando atrasos ou até desligando-os — um ataque DoS típico. Ao mesmo tempo, o protocolo Gossip da camada de consenso (CL) do Ethereum já recusa propagar blocos acima de 10MB, o que significa que blocos de execução demasiado grandes podem não ser propagados na rede, causando fragmentação ou divergências entre nós. Dada estes riscos, o Ethereum precisa de uma regra clara ao nível do protocolo para evitar blocos demasiado grandes e manter a rede estável e segura.

O EIP-7934 resolve isto ao introduzir um limite ao tamanho dos blocos de execução codificados em RLP ao nível do protocolo. O tamanho máximo permitido (MAX_BLOCK_SIZE) é definido em 10 MiB (10.485.760 bytes), mas como o bloco beacon também ocupa algum espaço (SAFETY_MARGIN), o Ethereum adiciona uma margem de 2 MiB (2.097.152 bytes).

Isto significa que o tamanho máximo real permitido para blocos de execução RLP é MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN. Se o bloco codificado exceder este limite, é considerado inválido e os nós devem rejeitá-lo. Com esta regra, os produtores de blocos devem verificar o tamanho codificado de cada bloco que constroem, e os validadores devem verificar este limite durante a validação do bloco. Este limite é independente do limite de gas, o que significa que mesmo que o bloco esteja “abaixo do limite de gas”, se o tamanho codificado for demasiado grande, será rejeitado. Isto garante que tanto o uso de gas como o limite de bytes são respeitados.

A escolha do limite de 10 MiB é intencional, pois corresponde ao limite já existente no protocolo gossip da camada de consenso. Qualquer dado acima de 10 MiB não é propagado na rede, pelo que este EIP alinha o limite da camada de execução com o da camada de consenso. Isto garante consistência entre todos os componentes e previne situações em que um bloco de execução válido não seja “visível” devido à recusa de propagação pela CL.

Esta alteração não é retrocompatível para blocos acima do novo limite, pelo que mineiros e validadores devem atualizar os seus clientes para cumprir a regra. No entanto, como blocos excessivamente grandes já são problemáticos e raros na prática, o impacto é mínimo.

Em termos de segurança, o EIP-7934 reforça significativamente a capacidade do Ethereum de resistir a ataques DoS baseados em blocos de tamanho extremo, garantindo que nenhum participante pode criar blocos que paralisem a rede. Em suma, o EIP-7934 adiciona uma fronteira de segurança importante, aumenta a estabilidade, unifica o comportamento da camada de execução (EL) e da CL, e previne vários ataques relacionados com a criação e propagação de blocos excessivamente grandes.

EIP-7939: Opcode para contar zeros à esquerda (CLZ)

Antes deste EIP, o Ethereum não tinha um opcode nativo para contar o número de zeros à esquerda num número de 256 bits. Os programadores tinham de implementar manualmente a função CLZ em Solidity, o que exigia muitas operações de deslocamento e comparação.

Isto era um grande problema porque as implementações personalizadas eram lentas, caras e ocupavam muito bytecode, aumentando o consumo de gas. Para sistemas de provas de conhecimento zero, o custo era ainda maior, pois as operações de deslocamento à direita são muito caras de provar, tornando operações como CLZ um grande entrave ao desempenho dos circuitos de provas. Como CLZ é uma função de baixo nível muito comum, usada em bibliotecas matemáticas, algoritmos de compressão, bitmaps, esquemas de assinatura e muitas tarefas criptográficas ou de processamento de dados, o Ethereum precisava de uma forma mais rápida e económica de a calcular.

O EIP-7939 resolve isto ao introduzir um novo opcode chamado CLZ (0x1e). Este opcode lê um valor de 256 bits da pilha e retorna o número de zeros à esquerda. Se o número de entrada for zero, retorna 256, pois um zero de 256 bits tem 256 zeros à esquerda.

Isto é consistente com o funcionamento do CLZ em muitas arquiteturas de CPU, como ARM e x86, onde a operação é suportada nativamente. Adicionar CLZ reduz significativamente o custo de muitos algoritmos: lnWad, powWad, LambertW, várias funções matemáticas, comparação de strings de bytes, varrimento de bitmaps, compressão/descompressão de calldata e esquemas de assinatura pós-quântica beneficiam de uma deteção de zeros à esquerda mais rápida.

O custo de gas do CLZ é definido em 5, igual ao ADD e ligeiramente acima do preço anterior do MUL, para evitar que o preço baixo cause riscos de DoS. Os benchmarks mostram que o custo computacional do CLZ é semelhante ao do ADD, e em ambientes de prova SP1 rv32im, o custo de prova do CLZ é até inferior ao do ADD, reduzindo o custo das provas de conhecimento zero.

O EIP-7939 é totalmente retrocompatível, pois introduz um novo opcode sem modificar nenhum comportamento existente.

No geral, o EIP-7939 torna o Ethereum mais rápido, barato e amigável para programadores ao adicionar um primitivo simples e eficiente já suportado por CPUs modernas — reduzindo taxas de gas, diminuindo o tamanho do bytecode e baixando o custo de provas de conhecimento zero para muitas operações comuns.

EIP-7951: Assinaturas suportadas por hardware moderno

Antes deste EIP, o Ethereum não tinha uma forma segura e nativa de verificar assinaturas digitais criadas com a curva secp256r1 (P-256).

Esta curva é o padrão usado por dispositivos modernos como Apple Secure Enclave, Android Keystore, HSM, TEE e chaves de segurança FIDO2/WebAuthn. Sem este suporte, aplicações e carteiras não podiam usar facilmente assinaturas seguras ao nível do hardware do dispositivo. Já houve uma tentativa anterior (RIP-7212), mas continha duas vulnerabilidades graves relacionadas com o tratamento do ponto no infinito e comparação incorreta de assinaturas. Estes problemas podiam causar verificações incorretas e até falhas de consenso. O EIP-7951 corrige estes problemas de segurança e introduz uma pré-compilação nativa e segura, permitindo finalmente ao Ethereum suportar assinaturas de hardware moderno de forma segura e eficiente.

O EIP-7951 adiciona um novo contrato pré-compilado chamado P256VERIFY no endereço 0x100, que executa a verificação de assinaturas ECDSA usando a curva secp256r1. Isto torna a verificação de assinaturas mais rápida e barata do que implementar o algoritmo diretamente em Solidity.

O EIP-7951 também define regras rigorosas de validação de entrada. Se houver qualquer situação inválida, a pré-compilação retorna falha sem rollback, consumindo o mesmo gas que uma chamada bem-sucedida. O algoritmo de verificação segue o ECDSA padrão: calcula s⁻¹ mod n, reconstrói o ponto de assinatura R', rejeita se R' for o ponto no infinito e verifica se a coordenada x de R' coincide com r (mod n). Isto corrige o erro do RIP-7212, que comparava r' diretamente em vez de o reduzir mod n.

O custo de gas desta operação é definido em 6900 gas, acima da versão do RIP-7212, mas alinhado com benchmarks reais de desempenho da verificação secp256r1. Importa referir que a interface é totalmente compatível com as redes Layer 2 que já implementaram o RIP-7212 (mesmo endereço e formato de entrada/saída), pelo que contratos inteligentes existentes continuarão a funcionar sem alterações. A única diferença é o comportamento corrigido e o custo de gas mais elevado.

Do ponto de vista da segurança, o EIP-7951 restaura o comportamento correto do ECDSA, elimina problemas de maleabilidade ao nível da pré-compilação (deixando verificações opcionais para a aplicação) e esclarece que a pré-compilação não precisa de execução em tempo constante. A curva secp256r1 oferece 128 bits de segurança e é amplamente confiável e analisada, sendo segura para uso no Ethereum.

Em resumo, o EIP-7951 visa introduzir autenticação suportada por hardware moderno de forma segura no Ethereum, corrigindo problemas de segurança de propostas anteriores e fornecendo uma forma fiável e padronizada de verificar assinaturas P-256 em todo o ecossistema.

Resumo

A tabela abaixo resume quais clientes do Ethereum precisam de alterações para diferentes EIPs do Fusaka. Um visto sob o cliente de consenso indica que o EIP requer atualização do cliente de consenso, enquanto um visto sob o cliente de execução indica que a atualização afeta o cliente de execução. Alguns EIPs exigem atualização de ambas as camadas, outros apenas de uma.

Em suma, estes são os principais EIPs incluídos no hard fork Fusaka. Embora esta atualização envolva várias melhorias tanto nos clientes de consenso como de execução — desde ajustes de gas e atualização de opcodes até novas pré-compilações — o núcleo da atualização é o PeerDAS, que introduz a amostragem de disponibilidade de dados ponto-a-ponto, permitindo um processamento mais eficiente e descentralizado dos dados blob em toda a rede.