Feed del secuenciador de Base y derivación L1: suscripción a bloques no seguros

El modelo de flujo de datos de OP-Stack: secuenciador, feed y derivación

En el modelo OP-Stack documentado en docs.optimism.io/stack/rollup/overview, un secuenciador ordena transacciones y difunde los bloques resultantes. Los op-nodes consumidores se conectan al feed del secuenciador, un flujo pub/sub que normalmente se transporta por WebSocket o HTTP, para recibir estos bloques de inmediato como bloques no seguros. En paralelo, el mismo nodo deriva la cadena segura a partir de lotes del secuenciador y raíces de estado que se publican en L1.

Este diseño de doble ruta significa que un nodo siempre tiene al menos dos vistas de la cadena: la cabeza no segura, rápida y proporcionada por el secuenciador, y la cabeza segura, más lenta y derivada de L1. La especificación del nodo rollup de OP Stack describe en detalle el feed del secuenciador y el comportamiento del op-node, incluido cómo se conecta un consumidor que no es secuenciador a un endpoint de secuenciador.

Para los operadores, la consecuencia práctica es que el feed es una optimización de latencia, no un ancla de confianza. El feed te dice qué está produciendo el secuenciador en este momento; la derivación te dice qué ha atestiguado L1. Ambos son necesarios para una imagen completa, y el artículo Finalidad de Base OP Stack, bloques seguros y finalizados cubre cómo se etiquetan esas cabezas a través de RPC.

• Secuenciador: ordena transacciones y difunde bloques al feed.
• Feed: flujo pub/sub que entrega bloques no seguros a los op-nodes consumidores.
• Derivación: reconstruye la cadena segura a partir de lotes y raíces de estado de L1.
• Cabeza no segura: último bloque visto desde el feed, sujeto a reorganización.
• Cabeza segura: bloque derivado de L1 equivalente a la etiqueta safe de L2.
• Cabeza finalizada: bloque finalizado en L1, la garantía más fuerte.

Por qué la cabeza no segura y la cabeza segura divergen

La cabeza no segura avanza en cuanto el secuenciador publica un bloque, mientras que la cabeza segura avanza solo cuando el lote correspondiente se incluye en un bloque de L1 y es procesado por la derivación. Esta diferencia de tiempos es la razón principal por la que ambas cabezas divergen. En operación normal, la cabeza no segura va por delante de la cabeza segura en cierto número de bloques; durante congestión de L1 o reinicios del secuenciador, la brecha puede ampliarse.

Una divergencia no es necesariamente un error. Es el comportamiento esperado de un rollup que separa la secuenciación rápida de la liquidación respaldada por L1. El riesgo surge cuando una aplicación trata la cabeza no segura como si fuera segura. Debido a que la cabeza no segura puede reorganizarse, cualquier acción con valor basada únicamente en ella puede invalidarse. El artículo Profundidad de reorganización de Base OP-Stack y reversión de indexadores analiza cómo razonar sobre la profundidad de reversión para indexadores.

Para leer ambas cabezas, consultas el RPC rollup o admin del op-node. El método optimism_syncStatus devuelve los números de bloque L2 no seguro, seguro y finalizado junto con sus orígenes en L1, lo que te da una instantánea única de la vista del nodo.

• La cabeza no segura va por delante porque el feed es más rápido que la inclusión en L1.
• La cabeza segura va por detrás por el tiempo que tarda en publicarse y derivarse los lotes.
• La cabeza finalizada va aún más atrás, esperando la finalidad de L1.
• Una brecha que se amplía es una señal para revisar la salud de L1 y el estado del secuenciador.

Leer las cabezas no segura, segura y finalizada con optimism_syncStatus

El op-node expone optimism_syncStatus a través de su interfaz RPC. Una sola llamada devuelve los números de bloque L2 no seguro, seguro y finalizado actuales, sus orígenes en L1 y el estado de sincronización del nodo. Esta es la forma más directa de observar la relación entre feed y derivación en un nodo en ejecución.

El ejemplo siguiente usa curl contra un endpoint RPC local de op-node. Reemplaza la URL por tu propia dirección RPC de op-node. La forma de la respuesta está documentada en la especificación del nodo rollup de OP Stack y es estable entre cadenas OP-Stack, incluida Base.

Si te conectas a través de un endpoint alojado en lugar de un op-node local, comprueba qué métodos están expuestos. La página Endpoint RPC de Base (RPC Assistant) describe la superficie RPC estándar de Base, mientras que los métodos específicos de op-node como optimism_syncStatus normalmente solo están disponibles en tu propio nodo o en un proveedor que los exponga explícitamente.

curl -s -X POST http://localhost:9545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"optimism_syncStatus","params":[]}' \
  | jq '{unsafe: .result.unsafe_l2.number, safe: .result.safe_l2.number, finalized: .result.finalized_l2.number, unsafe_l1: .result.unsafe_l2.l1origin.number, safe_l1: .result.safe_l2.l1origin.number}'

La forma JSON de un payload de bloque del feed del secuenciador

El feed del secuenciador entrega payloads de bloque como mensajes JSON sobre un transporte pub/sub. El envoltorio exacto varía según el cliente y el transporte, pero el payload generalmente contiene los campos del payload de ejecución: hash del padre, número de bloque, raíz de estado, marca de tiempo, transacciones y los metadatos del origen en L1. Comprender esta forma te ayuda a analizar los mensajes del feed y compararlos con los bloques derivados.

El ejemplo siguiente muestra una estructura de payload representativa. Los nombres de los campos siguen las convenciones del payload de ejecución de la Engine API que usa op-node. Trátalo como una referencia estructural; valida siempre contra los mensajes reales que emite tu nodo, porque el framing específico del proveedor puede diferir.

Cuando consumes el feed directamente, eres responsable de rastrear la cabeza no segura por tu cuenta. El propio optimism_syncStatus del nodo sigue siendo la fuente autoritativa para las cabezas segura y finalizada, que el feed no transporta.

{
  "parentHash": "0xabc...",
  "blockNumber": "0x112a880",
  "stateRoot": "0xdef...",
  "timestamp": "0x66f1a2c0",
  "transactions": ["0x02f8..."],
  "l1Origin": {
    "blockNumber": "0x14a2b3c",
    "blockHash": "0x123..."
  }
}

Suscribirse al feed y reconectarse con backoff

Un op-node consumidor se conecta a un endpoint de secuenciador para recibir el feed. Cuando el feed se desconecta o el nodo se reinicia, el nodo recurre a la derivación L1 y debe ponerse al día. Una aplicación que solo observa el feed verá un hueco durante esta ventana, porque el feed no reproduce bloques perdidos. El patrón de recuperación correcto es reconectarse con backoff exponencial y luego reconciliar contra optimism_syncStatus para detectar cualquier hueco.

El ejemplo de Node.js siguiente implementa un bucle de reconexión con backoff y un paso de reconciliación. Usa una conexión WebSocket al feed y sondea periódicamente optimism_syncStatus por HTTP. Reemplaza los endpoints por los tuyos. El patrón es agnóstico al transporte; la misma lógica se aplica a feeds con long-polling HTTP.

Después de reconectarte, compara el último número de bloque que viste desde el feed con la cabeza no segura reportada por optimism_syncStatus. Si la cabeza no segura del nodo va por delante, perdiste bloques y deberías rellenarlos desde el RPC del nodo en lugar de asumir que el feed los reenviará.

const WebSocket = require('ws');
const fetch = require('node-fetch');

const FEED_URL = 'ws://localhost:8546';
const RPC_URL = 'http://localhost:9545';
let lastSeen = 0;
let backoff = 1000;

async function syncStatus() {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'optimism_syncStatus', params: [] })
  });
  const json = await res.json();
  return json.result;
}

function connect() {
  const ws = new WebSocket(FEED_URL);
  ws.on('open', () => { backoff = 1000; console.log('feed connected'); });
  ws.on('message', (data) => {
    const block = JSON.parse(data);
    lastSeen = parseInt(block.blockNumber, 16);
    console.log('unsafe block', lastSeen);
  });
  ws.on('close', async () => {
    const status = await syncStatus();
    const nodeUnsafe = parseInt(status.unsafe_l2.number, 16);
    if (nodeUnsafe > lastSeen) {
      console.log('gap detected: missed', nodeUnsafe - lastSeen, 'blocks; backfill required');
    }
    setTimeout(connect, backoff);
    backoff = Math.min(backoff * 2, 30000);
  });
  ws.on('error', (err) => console.error('feed error', err.message));
}

connect();

Elegir la cabeza adecuada para indexadores y puentes

La cabeza en la que confías debe coincidir con el valor en riesgo. Para datos solo de visualización, como el contador de último bloque de un explorador de bloques, la cabeza no segura es aceptable porque una reorganización solo cambia la visualización. Para indexación que alimenta analíticas, la cabeza segura suele ser la elección correcta porque está derivada de L1 y es equivalente a la etiqueta de bloque safe de L2. Para puentes y cualquier acción que mueva valor, la cabeza finalizada es la única que conlleva garantías de finalidad de L1.

Esta estratificación es coherente con el modelo de cabezas descrito en la documentación de OP Stack. El artículo Estado de sincronización del nodo Base OP-Stack y la Engine API explica cómo se asigna el estado forkchoice de la Engine API a estas cabezas, lo cual es útil cuando manejas un cliente de ejecución directamente.

Una regla práctica: nunca finalices un retiro, acredites un depósito ni liberes un escrow basándote en la cabeza no segura. Espera a la cabeza finalizada y usa la cabeza segura como punto de control intermedio para estado sin valor.

• Cabeza no segura: contadores de UI, monitoreo tipo mempool, telemetría sin valor.
• Cabeza segura: indexación, analíticas, estado sin valor que tolera reversiones raras.
• Cabeza finalizada: puentes, retiros, depósitos, escrow, cualquier transferencia de valor.
• Registra siempre el origen en L1 junto al bloque L2 para auditabilidad.

Flashblocks y el modelo de derivación: señales diferentes

Los flashblocks son preconfirmaciones sub-segundo que se sitúan sobre el modelo OP-Stack. Son una señal orientada a la latencia diseñada para dar a las aplicaciones una vista temprana del estado pendiente, no un reemplazo de la derivación segura o finalizada. Confundir los flashblocks con la derivación lleva a suposiciones incorrectas sobre la finalidad.

El artículo Derivación L1 y marcas de tiempo de Base OP-Stack cubre cómo se leen las marcas de tiempo de derivación a través de RPC, que es la forma correcta de razonar sobre cuándo un bloque se volvió seguro. Los flashblocks no cambian la línea temporal de derivación; solo acortan el tiempo hasta una señal preliminar.

Trata los flashblocks como una capa de optimización para la experiencia de usuario. Mantén tu lógica de seguro y finalizado anclada a la derivación y a la finalidad de L1, y usa flashblocks solo donde sea aceptable una señal de baja latencia tolerante a reorganizaciones.

• Flashblocks: preconfirmaciones sub-segundo, orientadas a latencia, tolerantes a reorganizaciones.
• Derivación: cabeza segura respaldada por L1, la base para puntos de control de indexación.
• Finalidad: cabeza finalizada en L1, la base para acciones con valor.
• No sustituyas los flashblocks por comprobaciones de seguro o finalizado.

Tabla de resultados reproducible para tu propio endpoint

Debido a que el comportamiento del feed, el retraso de derivación y los tiempos de reconexión dependen de tu nodo, las condiciones de red y la salud de L1, los únicos números fiables son los que mides. Usa la tabla siguiente para registrar observaciones desde tu propio endpoint. Ejecuta la consulta syncStatus y el suscriptor del feed juntos, y registra los valores a un intervalo fijo.

Rellena cada fila con una marca de tiempo, los números de bloque L2 no seguro y seguro, sus orígenes en L1, la brecha calculada y cualquier evento de reconexión. Repite al menos durante un periodo de congestión de L1 y un reinicio de nodo para capturar los casos interesantes. Esto te da una línea base que puedes comparar después de cambios de configuración.

No trates ninguna medición individual como un benchmark. El objetivo es un método reproducible, no un número publicado. Si necesitas datos de rendimiento a nivel de proveedor, solicítalos a tu proveedor en lugar de inferirlos de una sola ejecución.

• Marca de tiempo: hora ISO 8601 de la muestra.
• Bloque L2 no seguro: de optimism_syncStatus o del feed.
• Bloque L2 seguro: de optimism_syncStatus.
• Bloque L2 finalizado: de optimism_syncStatus.
• Origen L1 no seguro: bloque de L1 que respalda la cabeza no segura.
• Origen L1 seguro: bloque de L1 que respalda la cabeza segura.
• Brecha no seguro a seguro: número de bloque no seguro menos seguro.
• Tiempo hasta seguro: tiempo de reloj desde la observación no segura hasta la observación segura.
• Recuento de reconexiones del feed: número de eventos de reconexión en el intervalo.

Limitaciones y compensaciones del consumo basado en el feed

El feed del secuenciador es un servicio proporcionado por el secuenciador. Su disponibilidad, framing y retención están controlados por el operador del secuenciador, no por el protocolo. El consumo autoalojado del feed requiere ejecutar un op-node; no puedes consumir el feed de forma significativa sin uno, porque el feed por sí solo no te da las cabezas segura o finalizada.

Confiar en la cabeza no segura para acciones con valor es inseguro porque puede reorganizarse. El feed no reproduce bloques perdidos, por lo que una desconexión crea un hueco que debe rellenarse desde el RPC del nodo. Ejecutar tu propio op-node añade coste operativo pero elimina la dependencia de un endpoint de feed de terceros y te da acceso directo a optimism_syncStatus.

Para equipos que prefieren no ejecutar infraestructura, un endpoint gestionado puede exponer la superficie RPC estándar de Base. Consulta Endpoint RPC de Base (RPC Assistant) y Precios de RPC para opciones, y Servicio API para patrones de acceso gestionado. Ten en cuenta que los métodos específicos de op-node pueden no estar disponibles en todos los endpoints gestionados; verifícalo antes de diseñar en torno a ellos.

• La disponibilidad del feed está controlada por el operador del secuenciador.
• El feed no reproduce bloques perdidos; el relleno es tu responsabilidad.
• El consumo autoalojado requiere un op-node.
• La cabeza no segura es propensa a reorganizaciones y no es adecuada para acciones con valor.
• Los endpoints gestionados pueden no exponer métodos RPC específicos de op-node.

Solución de problemas del feed y la derivación

La mayoría de los problemas del feed se dividen en unas pocas categorías: fallos de conexión, huecos silenciosos y divergencia de cabezas. Empieza confirmando que el op-node está en ejecución y que optimism_syncStatus devuelve una instantánea coherente. Si la cabeza no segura avanza pero la cabeza segura está estancada, el problema suele estar en el lado de la derivación L1, no en el feed.

Si el feed se desconecta repetidamente, comprueba la estabilidad de la red y la accesibilidad del endpoint del secuenciador. Aumenta los límites de backoff para evitar tormentas de reconexión. Si ves un hueco después de reconectarte, rellena desde el RPC del nodo en lugar de esperar a que el feed lo reenvíe.

Si la cabeza segura está muy por detrás de la cabeza no segura, revisa los precios de gas de L1 y la publicación de lotes. El retraso de derivación suele ser un problema de economía de L1. El artículo Estado de sincronización del nodo Base OP-Stack y la Engine API cubre cómo inspeccionar el estado de sincronización a través de la Engine API cuando el RPC rollup no es suficiente.

• Feed conectado pero sin mensajes: verifica el tema de suscripción y el transporte.
• No seguro avanzando, seguro estancado: investiga la derivación L1 y la publicación de lotes.
• Desconexiones repetidas: revisa red, accesibilidad del endpoint, límites de backoff.
• Hueco tras reconexión: rellena desde el RPC del nodo, no esperes reproducción.
• Cabezas inconsistentes entre nodos: compara orígenes en L1 y estado de sincronización.

Próximos pasos para operadores de nodos de Base

Empieza ejecutando un op-node y consultando optimism_syncStatus para establecer una línea base de tus cabezas no segura, segura y finalizada. Luego añade un suscriptor del feed con reconexión y backoff, y registra la tabla de resultados descrita anteriormente. Esto te da una vista reproducible de cómo se comporta tu nodo en condiciones normales y degradadas.

Para contexto a nivel de red, consulta la página de red de Base y el hub de aprendizaje de OnFinality para análisis relacionados. Si estás diseñando un indexador, lee a continuación el artículo Profundidad de reorganización de Base OP-Stack y reversión de indexadores, y combínalo con la guía Finalidad de Base OP Stack, bloques seguros y finalizados para el manejo de cabezas a nivel de RPC.

Por último, decide tu nivel de confianza por operación: no seguro para visualización, seguro para indexación, finalizado para valor. Documenta esa decisión en tu runbook y revísala siempre que cambies de endpoints o proveedores.

• Ejecuta un op-node y establece una línea base de optimism_syncStatus.
• Añade un suscriptor del feed con reconexión y backoff.
• Registra la tabla de resultados en periodos normales y degradados.
• Define niveles de confianza por operación y documéntalos.
• Revisa la cobertura de métodos del proveedor antes de diseñar en torno al RPC de op-node.