O "câmbio contínuo" na atualização Fusaka do Ethereum: estabelecendo um mecanismo de resposta rápida para a escalabilidade do L2

O futuro do Ethereum será como instalar uma "transmissão continuamente variável", de modo que a expansão de Blob não precisará mais estar fortemente vinculada a grandes atualizações de versão.

Autor: Zhixiong Pan

Contexto: Atualização do Gas Limit sem necessidade de hard fork

Antes da atualização Fusaka, a grande maioria dos parâmetros centrais da camada de protocolo do Ethereum (como recompensa de bloco, algoritmo de ajuste de dificuldade, etc.) eram "hardcoded" no software do cliente. Isso significava que, mesmo para modificar um único valor, era necessário passar por uma longa proposta EIP, testes em testnet e coordenar todos os nós da rede para realizar um grande hard fork, o que normalmente levava meio ano ou até mais.

Antes disso, a única exceção no protocolo Ethereum era o Block Gas Limit (limite de Gas por bloco). O Gas Limit não é determinado por hard fork, mas permite que os validadores façam pequenos ajustes através de um algoritmo ao empacotar blocos (por exemplo, este ano de 30M para 60M). Esse mecanismo confere certa flexibilidade à rede.

O surgimento do EIP-7892, BPO (Blob Parameter Only), visa exatamente expandir essa flexibilidade para o domínio dos dados. Ele transforma os parâmetros-chave do Blob em configurações dinâmicas e os implementa por meio do BPO, um "hard fork leve que só altera parâmetros, sem alterar código". Do ponto de vista do desenvolvimento do cliente, é quase como uma atualização quente de parâmetros.

Isso permite que o Ethereum, em questões de escalabilidade, se livre do ritmo de "ter que esperar o próximo grande hard fork para ajustar o número de Blobs", podendo ajustar os parâmetros com mais frequência através de pequenos forks BPO.

Por que a quantidade de Blobs é importante?

O principal alvo deste ajuste é o Blob. Desde a atualização Cancun (Dencun), a maioria dos Rollups deixou de armazenar a maior parte dos dados de transações no caro calldata, migrando para o Blob, uma "área de montagem de dados temporária" dedicada.

A lógica econômica do Blob é muito simples: o Blob é um recurso escasso, e a quantidade de Blobs que pode ser montada em cada bloco é limitada. Seu preço deriva da relação entre oferta e demanda; quando a demanda da Layer 2 excede a oferta, o preço unitário do Blob aumenta, tornando as taxas do L2 mais caras.

Portanto, garantir o aumento do limite máximo de Blobs, desde que a segurança seja mantida, é a maneira mais direta de reduzir o custo para os usuários do L2.

Parâmetros principais: O mecanismo de Target e Max

No plano de ajuste do BPO, é possível ver dois números que aparecem em pares (por exemplo, 10/15). Estes são dois limiares-chave definidos pelo mecanismo do EIP-4844:

Target (Valor alvo): O "regulador" das taxas

Este é o volume de carga ideal definido pelo Ethereum. O sistema ajusta dinamicamente a taxa base (Base Fee) do Blob com base neste valor. Se o uso real > Target, a taxa aumenta para conter a demanda; se o uso real < Target, a taxa diminui.

Ele determina a capacidade de throughput da rede em condições normais e serve como referência para as taxas.

Max (Valor máximo): O "fusível" de segurança

Este é o limite físico máximo definido para evitar a paralisação da rede. Independentemente da demanda, o protocolo obriga que o número de Blobs em um único bloco não ultrapasse esse valor, para evitar que os nós travem ou fiquem offline devido ao processamento de dados excessivos.

É o teto máximo da capacidade de suporte da rede.

Além disso, desde o Pectra, os parâmetros de blob da mainnet seguem basicamente o padrão "Max = 1,5 × Target": 6/9, 10/15, 14/21, todos nessa proporção.

Roteiro de atualização: Por que Fusaka escolheu o "caminho em etapas"?

Esta expansão não será concluída de uma só vez em 3 de dezembro (UTC+8), mas adota uma estratégia rigorosa de três fases: "primeiro implantar a tecnologia, depois liberar a capacidade".

Primeira fase: Lançamento da atualização Fusaka (3 de dezembro (UTC+8))

Status dos parâmetros: Target: 6 / Max: 9 (mantendo-se igual à versão anterior do Pectra, sem alterações).

A atualização Fusaka ativou o PeerDAS (amostragem de disponibilidade de dados), uma tecnologia central. Embora tecnicamente já seja possível processar mais dados, por motivos de segurança, os desenvolvedores optaram por não aumentar a carga da rede no primeiro dia da atualização. Este é um "período de observação de segurança", usado para verificar a estabilidade do PeerDAS sob o tráfego atual.

Segunda fase: BPO 1 (previsto para 9 de dezembro (UTC+8))

Ajuste de parâmetros: Target: 10 / Max: 15

Após cerca de uma semana de funcionamento estável do PeerDAS, será realizada a primeira atualização quente via BPO. O valor alvo aumentará de 6 para 10. Esta é a primeira expansão substancial durante o ciclo Fusaka.

Terceira fase: BPO 2 (previsto para 7 de janeiro de 2026 (UTC+8))

Ajuste de parâmetros: Target: 14 / Max: 21

Após um mês de testes de estresse completos, será realizada a segunda atualização quente. Em comparação com o lançamento do Fusaka, a capacidade aumentará 2,3 vezes (6 → 14). Isso marca a implementação total do plano de expansão.

Resumo

A introdução do BPO é um marco. Ele rompe com o antigo paradigma de "cada expansão de Blob exige um grande hard fork funcional", dividindo a expansão em uma série de mini hard forks que só alteram parâmetros.

Isso significa que o futuro do Ethereum será como instalar uma "transmissão continuamente variável", de modo que a expansão de Blob não precisará mais estar fortemente vinculada a grandes versões. Será possível, de acordo com a demanda do L2 e o desempenho do cliente, planejar BPO3, BPO4 em intervalos regulares, otimizando o throughput com pequenos hard forks mais frequentes, em vez de esperar anos para cada ajuste.