Optimism acelera subblocks para 200ms e silencia campos de dados

A Optimism reduziu o intervalo dos subblocks da OP Mainnet de 250 para 200 milissegundos, um corte de 20% no tempo de preconfirmação. A mudança, com data-alvo de 31 de agosto, trouxe um problema silencioso. Quatro campos do payload transmitido pelo stream passam a retornar valores zerados sem qualquer aviso na API.

Subblocks são parciais de blocos que o sequencer publica enquanto constrói o completo. Aplicações conectadas ao stream recebem atualizações a cada 200 milissegundos e mostram resultados antes do selamento.

A redução não é arbitrária e bate com o padrão da especificação Flashblocks. Para aplicações que dependem de feedback quase instantâneo, cada milissegundo conta. O detalhe incômodo está no que a mudança apaga.

O que muda no payload

Quatro campos que antes carregam dados reais agora vêm zerados em cada subblock. O state_root, hash do estado da máquina, retorna uma sequência de zeros. O block_hash, que identifica o bloco, idem. O root_hash, que cobre retiradas da camada de consenso, também é zerado. E o campo de retiradas chega como lista vazia.

O resto do payload continua funcionando normalmente. receipts_root, logs_bloom, transactions e gas_used mantêm valores reais. Essa combinação é o que torna a mudança perigosa. O stream continua sendo decodificado sem erro de parsing, mas quatro campos específicos passam a mentir silenciosamente.

O risco é claro para integrações que leem esses campos diretamente. Um saldo calculado a partir de um state_root zerado não representa o estado real. Uma prova criptográfica construída sobre um block_hash nulo não tem validade. O sistema falha de forma silenciosa e propaga dados inválidos para camadas downstream sem levantar erro de parsing, o que torna o problema difícil de detectar em tempo real.

A documentação da Optimism é direta. Consumidores diretos do stream devem ignorar esses campos e calcular o estado preconfirmado executando as transações do subblock contra uma visão local da cadeia.

A maioria das aplicações não precisa se preocupar. Quem usa um RPC provider com suporte a subblocks e chama métodos como eth_call ou eth_getBalance com a tag pending recebe o estado derivado. O nó executa as transações internamente e serve o resultado sem expor os valores nulos.

A fronteira entre o stream e a API

O problema é quem consome o stream diretamente via WebSocket. Criadores de mercado, agregadores de liquidez, infraestrutura de indexação, ferramentas de monitoramento on-chain. Para essas, a migração exige auditoria. Cada leitura de state_root, block_hash, root_hash ou campo de retiradas precisa ser encontrada e substituída por lógica própria.

Os RPC providers que repassam o payload bruto também estão na lista. A orientação é que repassem a notificação e garantam que os valores nulos não vazem para a API pública sem tratamento.

A arquitetura explica. O op-node conduz a construção do bloco pela engine API. O execution client executa as transações e publica um subblock a cada 200 milissegundos. Um proxy WebSocket relay repassa o stream do sequencer ativo para os provedores. O state_root só é exato quando o bloco está selado, então não existe valor válido para o subblock.

Um subblock não é um bloco finalizado. É uma projeção do que o sequencer processou até aquele momento. A preconfirmação pode ser revogada se o sequencer reorganizar um bloco inseguro. A confiança é a mesma do operador do sequencer, não uma garantia criptográfica do protocolo.

A migração está sendo gradual. A OP Sepolia recebeu a mudança em 17 de agosto. A OP Mainnet tinha data-alvo de 31 de agosto, mas as datas podem mudar e não há momento documentado de conclusão em toda a rede.

Para desenvolvedores, a ação imediata é auditar o código. Buscar leituras dos 4 campos e confirmar que um valor zerado não pode se propagar para cálculos de saldo, provas de estado ou sistemas de prova. Quem faz parsing manual do payload precisa agir.

Redes de segunda camada competem por aplicações que exigem velocidade. Cada milissegundo cortado é um argumento a mais para que builders escolham uma cadeia. O custo dessa velocidade é a complexidade transferida para a periferia, para desenvolvedores que precisam entender que o stream que funciona hoje pode não funcionar amanhã sem aviso.

A recomendação é auditar agora, porque o stream não vai avisar quando os zeros chegarem.