A Optimism visa reduzir em 20% o intervalo de pré-confirmação da OP Mainnet, de 250 milissegundos para 200 milissegundos, numa alteração gradual com meta para 31 de agosto. Os subblocos, anteriormente designados por Flashblocks, são atualizações incrementais do sequenciador enviadas enquanto um bloco normal está a ser construído, proporcionando às aplicações feedback antes de o bloco ser selado. O payload mantém o tipo ExecutionPayloadFlashblockDeltaV1, mas state_root, block_hash e withdrawals_root passam a ter valores compostos apenas por zeros, enquanto withdrawals passa a ser uma lista vazia. O software continua a conseguir descodificar o stream, embora quatro campos já não transportem dados utilizáveis.
Porque é importante
O risco concentra-se na interface com o fornecedor. Os subblocos são pré-confirmações, não blocos finalizados nem compromissos de estado, pelo que os consumidores diretos do stream têm de executar as transações transmitidas para derivar o estado pré-confirmado, em vez de lerem as raízes preenchidas com zeros ou o hash do bloco.
As aplicações que utilizam um fornecedor de RPC com suporte para subblocos podem continuar a usar os métodos padrão do Ethereum, muitas vezes com a tag pending. Um fornecedor ou nó corretamente configurado mantém a sua própria visão do estado, permitindo que eth_getBalance devolva dados derivados do estado pré-confirmado sem depender de uma raiz de estado utilizável.
Impacto no mercado
A cadência mais rápida representa um ganho real de escalabilidade para aplicações sensíveis à latência, mas torna mais importantes as verificações de integração. As equipas que consomem diretamente o stream WebSocket devem procurar acessos de leitura aos quatro campos afetados, tratar os valores de preenchimento como indisponíveis e mantê-los fora do estado, dos saldos e dos dados de entrada das provas.
Os fornecedores de payloads em bruto têm de notificar os clientes. A Alchemy documenta atualizações de 200 ms através dos endpoints RPC da Optimism, enquanto a QuickNode aplica a migração aos componentes RPC da Optimism Mainnet e da Sepolia. A meta de 31 de agosto pode mudar e a implementação é gradual, pelo que os operadores devem validar o tratamento dos dados antes de a alteração chegar às suas integrações.
Perguntas frequentes
-
O que são os subblocos da Optimism e são blocos finalizados?
São atualizações incrementais do sequenciador enviadas enquanto um bloco normal está a ser construído. Fornecem informação de pré-confirmação, mas não são blocos finalizados nem compromissos de estado.
-
Que valores deixam de ser utilizáveis nos payloads mais rápidos da Optimism?
state_root, block_hash e withdrawals_root passam a conter apenas zeros, enquanto withdrawals passa a ser uma lista vazia. O tipo do payload continua a ser ExecutionPayloadFlashblockDeltaV1.
-
Como pode um descodificador não detetar o risco da migração para 200 ms?
O payload mantém o tipo ExecutionPayloadFlashblockDeltaV1, pelo que o software consegue analisá-lo sem erro, embora quatro campos já não transportem dados utilizáveis.
-
Como devem os consumidores diretos do stream calcular o estado pré-confirmado?
Devem executar as transações transportadas pelo stream e tratar as raízes preenchidas com zeros e o hash do bloco como ausentes. Os valores de preenchimento não devem entrar no estado, nos saldos nem nos dados de entrada das provas.
-
Como podem os utilizadores de RPC ler saldos pré-confirmados após a alteração?
Um fornecedor de RPC ou nó com suporte para subblocos, corretamente configurado, mantém a sua própria visão do estado, permitindo que eth_getBalance com a tag pending devolva dados derivados do estado pré-confirmado. Os fornecedores que encaminham campos em bruto têm de notificar os clientes.
Glassnode
CoinDesk
Altcoin Daily
TheBlock
Crypto News
WuBlockchain
Crypto Rank News
WatcherGuru