Optimism tiene como objetivo reducir un 20 % el intervalo de preconfirmación de OP Mainnet, de 250 milisegundos a 200 milisegundos, mediante un cambio gradual con el 31 de agosto como fecha objetivo. Los subbloques, antes llamados Flashblocks, son actualizaciones incrementales del secuenciador que se envían mientras se construye un bloque normal, para que las aplicaciones reciban información antes de que quede sellado. El payload conserva el tipo ExecutionPayloadFlashblockDeltaV1, pero state_root, block_hash y withdrawals_root pasan a ser valores compuestos solo por ceros, mientras que withdrawals pasa a ser una lista vacía. El software aún puede decodificar el flujo, aunque cuatro campos ya no contienen datos utilizables.
Por qué es importante
El riesgo se concentra en el límite del proveedor. Los subbloques son preconfirmaciones, no bloques finalizados ni compromisos de estado, por lo que los consumidores directos del flujo deben ejecutar las transacciones transmitidas para derivar el estado preconfirmado, en lugar de leer las raíces puestas a cero o el hash del bloque.
Las aplicaciones que utilizan un proveedor RPC compatible con subbloques pueden seguir usando los métodos estándar de Ethereum, a menudo con la etiqueta pending. Un proveedor o nodo correctamente configurado mantiene su propia vista del estado, lo que permite que eth_getBalance devuelva datos preconfirmados derivados sin depender de una raíz de estado utilizable.
Impacto en el mercado
Una cadencia más rápida supone una mejora real de escalabilidad para las aplicaciones sensibles a la latencia, pero hace más importantes las comprobaciones de integración. Los equipos que consumen directamente el flujo de WebSocket deberían localizar las lecturas de los cuatro campos afectados, tratar los valores de relleno como no disponibles y mantenerlos fuera del estado, los saldos y las entradas de las pruebas.
Los proveedores de payloads sin procesar deben avisar a sus clientes. Alchemy documenta actualizaciones de 200 ms a través de los endpoints RPC de Optimism, mientras que QuickNode aplica la migración a los componentes RPC de Optimism Mainnet y Sepolia. La fecha objetivo del 31 de agosto puede cambiar y el despliegue es gradual, por lo que los operadores deberían validar la gestión de estos datos antes de que el cambio llegue a sus sistemas.
Preguntas frecuentes
-
¿Qué son los subbloques de Optimism y están finalizados?
Son actualizaciones incrementales del secuenciador enviadas mientras se construye un bloque normal. Ofrecen información de preconfirmación, pero no son bloques finalizados ni compromisos de estado.
-
¿Qué valores dejan de ser utilizables en los payloads más rápidos de Optimism?
state_root, block_hash y withdrawals_root pasan a contener solo ceros, mientras que withdrawals pasa a ser una lista vacía. El tipo de payload sigue siendo ExecutionPayloadFlashblockDeltaV1.
-
¿Por qué un decodificador puede no detectar el riesgo de la migración a 200 ms?
El payload conserva el tipo ExecutionPayloadFlashblockDeltaV1, por lo que el software puede analizarlo sin errores aunque cuatro campos ya no contengan datos utilizables.
-
¿Cómo deben calcular el estado preconfirmado los consumidores directos del flujo?
Deben ejecutar las transacciones que transporta el flujo y tratar las raíces puestas a cero y el hash del bloque como ausentes. Los valores de relleno no deben entrar en el estado, los saldos ni las entradas de las pruebas.
-
¿Cómo pueden los usuarios de RPC leer los saldos preconfirmados tras el cambio?
Un proveedor o nodo RPC compatible con subbloques y correctamente configurado mantiene su propia vista del estado, lo que permite que eth_getBalance con la etiqueta pending devuelva datos preconfirmados derivados. Los proveedores que reenvían campos sin procesar deben avisar a sus clientes.
TheBlock
Crypto News
CoinDesk
WuBlockchain
CoinTelegraph