Solana getBlockProduction: producción de bloques y tasa de omisión por RPC

Qué devuelve getBlockProduction y por qué importa la forma

El método JSON-RPC de Solana getBlockProduction devuelve un objeto de resultado con dos campos de nivel superior: un objeto range que contiene firstSlot y lastSlot, y un mapa byIdentity. Cada entrada en byIdentity tiene como clave una identidad de validador (una dirección de cuenta de voto) y contiene un arreglo de dos elementos, que convencionalmente se lee como [leaderSlots, blocksProduced]. La referencia del método en la referencia de Solana getBlockProduction documenta esta forma directamente, y es la descripción autoritativa de los campos.

El arreglo de dos elementos es toda la medición. leaderSlots es el número de slots en el rango consultado para los cuales esa identidad estaba programada para ser líder; blocksProduced es cuántos de esos slots realmente produjeron un bloque en la vista del nodo. La diferencia son los slots omitidos atribuibles a esa identidad dentro del rango. Como ambos números comparten el mismo denominador, puedes calcular una tasa sin ninguna llamada adicional.

Esta forma agregada es lo que distingue a getBlockProduction de los métodos que devuelven datos enumerados. Si necesitas la lista real de slots producidos para detección de brechas, ese es otro método; si necesitas un número de slot puntual, ese es otro. getBlockProduction es específicamente la medición agregada de producción y tasa de omisión por identidad sobre un rango de slots.

• range.firstSlot y range.lastSlot delimitan la ventana que el nodo realmente evaluó.
• byIdentity asigna la identidad de la cuenta de voto a [leaderSlots, blocksProduced].
• Tasa de omisión por identidad = (leaderSlots - blocksProduced) / leaderSlots.
• Tasa de omisión del rango = (suma de leaderSlots - suma de blocksProduced) / suma de leaderSlots.

Delimitar el rango con range, identity y la ventana de época predeterminada

getBlockProduction acepta un objeto de configuración opcional. El parámetro range toma { firstSlot, lastSlot } y restringe la medición a esa ventana inclusiva. El parámetro identity restringe el mapa byIdentity a una sola identidad de validador, lo cual es útil cuando monitoreas un validador y no quieres analizar el mapa completo. Ambos están documentados en la referencia del método en la referencia de Solana getBlockProduction.

Cuando llamas al método sin argumentos, informa la época actual agregada por identidad de validador. Ese valor predeterminado es el modo de monitoreo más conveniente: una llamada te da los leaderSlots y blocksProduced de cada identidad para lo que va de la época. La contrapartida es que una época en curso es una ventana parcial, por lo que la tasa que calculas es provisional y cambiará a medida que la época se complete.

Si necesitas la línea de tiempo de slots y el cronograma de líderes que enmarcan la ventana, la página Solana getEpochInfo y cronograma de líderes cubre cómo se leen los límites de época y el cronograma de líderes por RPC. Combinar ese contexto con getBlockProduction te permite razonar sobre si un rango está completo o aún abierto.

• range: { firstSlot, lastSlot } para una ventana histórica o reciente acotada.
• identity: restringe el mapa a una sola dirección de cuenta de voto.
• Sin argumentos: época actual, agregada por identidad (ventana parcial).
• Confirma la ventana contra los límites de época antes de tratar una tasa como definitiva.

Calcular correctamente la tasa de omisión a partir de leaderSlots y blocksProduced

La tasa de omisión es una proporción, no un conteo. Para una sola identidad, divide la diferencia entre leaderSlots y blocksProduced por leaderSlots. Para todo el rango, suma leaderSlots de todas las identidades, suma blocksProduced de todas las identidades y aplica la misma fórmula a los totales. Sumar las tasas por identidad y promediarlas es una estadística diferente (y normalmente engañosa) porque pondera a un validador con pocos slots de liderazgo igual que a uno con muchos.

Protege el denominador. Si leaderSlots es cero para una identidad, la tasa es indefinida, no cero; omite esa identidad o repórtala como sin slots programados en la ventana. Esto ocurre naturalmente en validadores sin slots de liderazgo en un rango corto.

Dado que leaderSlots es el conteo programado, una baja relación producidos-a-líder significa que el validador no produjo bloques en slots que estaba programado para liderar. No significa que el cronograma estuviera mal. Puedes validar el denominador de forma independiente con getLeaderSchedule, documentado en https://solana.com/docs/rpc/http/getleaderschedule, que devuelve el cronograma de líderes por identidad para una época.

• Por identidad: (leaderSlots - blocksProduced) / leaderSlots.
• Para todo el rango: (Σ leaderSlots - Σ blocksProduced) / Σ leaderSlots.
• No promedies las tasas por identidad; pondera por leaderSlots en su lugar.
• Trata leaderSlots = 0 como indefinido, no como una puntuación perfecta.

Validar el denominador con getLeaderSchedule

El error de interpretación más común es asumir que leaderSlots refleja algo distinto al liderazgo programado. No es así: es el conteo de slots en el rango para los cuales la identidad estaba programada para liderar. Para confirmarlo, obtén el cronograma de líderes de la época correspondiente con getLeaderSchedule y cuenta los slots asignados a cada identidad, luego compara ese conteo con el valor de leaderSlots que getBlockProduction reportó para la misma ventana.

Cuando ambos coinciden, tu denominador de tasa de omisión es confiable y cualquier déficit en blocksProduced es genuinamente producción omitida. Cuando no coinciden, las causas probables son un rango que no se alinea con la época para la que obtuviste el cronograma, o un nodo cuya vista del rango difiere del cronograma que consultaste. Alinear el rango a los límites de época elimina la mayor parte de esta ambigüedad.

Para un tratamiento más profundo de los límites de época y cómo se lee el cronograma, consulta Solana getEpochInfo y cronograma de líderes.

• getLeaderSchedule devuelve el liderazgo programado por identidad para una época.
• Compara sus conteos de slots por identidad con leaderSlots para la misma ventana.
• Las discrepancias suelen indicar una desalineación rango/época, no un método roto.

Ejemplo ejecutable en Node.js: tasa de omisión de la época actual por identidad

El siguiente ejemplo llama a getBlockProduction sin argumentos para obtener la época actual agregada por identidad, calcula la tasa de omisión de cada identidad, ordena la lista por tasa descendente y marca las identidades por encima de un umbral. Usa el fetch global disponible en Node.js moderno y un endpoint RPC configurable.

Configura el endpoint con tu propia URL de RPC de Solana. El umbral es un parámetro que tú eliges; el script no asume que ningún valor particular sea saludable. Ejecútalo periódicamente y compara salidas sucesivas en lugar de actuar sobre una sola ejecución.

// measure-skip-rate.mjs
const RPC_URL = process.env.SOLANA_RPC_URL || "https://your-solana-rpc-endpoint";
const SKIP_THRESHOLD = Number(process.env.SKIP_THRESHOLD || 0.05); // 5%

async function rpc(method, params = []) {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const json = await res.json();
  if (json.error) throw new Error(JSON.stringify(json.error));
  return json.result;
}

const result = await rpc("getBlockProduction");
const { range, byIdentity } = result;

const rows = Object.entries(byIdentity).map(([identity, pair]) => {
  const [leaderSlots, blocksProduced] = pair;
  const skipRate = leaderSlots > 0 ? (leaderSlots - blocksProduced) / leaderSlots : null;
  return { identity, leaderSlots, blocksProduced, skipRate };
});

rows.sort((a, b) => (b.skipRate ?? -1) - (a.skipRate ?? -1));

console.log(`Range: ${range.firstSlot}..${range.lastSlot}`);
for (const r of rows) {
  const rate = r.skipRate === null ? "n/a" : (r.skipRate * 100).toFixed(2) + "%";
  const flag = r.skipRate !== null && r.skipRate > SKIP_THRESHOLD ? "  <-- above threshold" : "";
  console.log(`${r.identity}  leader=${r.leaderSlots}  produced=${r.blocksProduced}  skip=${rate}${flag}`);
}

const totalLeader = rows.reduce((s, r) => s + r.leaderSlots, 0);
const totalProduced = rows.reduce((s, r) => s + r.blocksProduced, 0);
const rangeSkip = totalLeader > 0 ? (totalLeader - totalProduced) / totalLeader : null;
console.log(`Range-wide skip rate: ${rangeSkip === null ? "n/a" : (rangeSkip * 100).toFixed(2) + "%"}`);

Ejemplo ejecutable con curl: rango acotado e identidad única

Para una ventana histórica acotada, pasa el parámetro range explícitamente. El ejemplo a continuación consulta un rango de slots específico e imprime el JSON sin procesar para que puedas inspeccionar range.firstSlot y range.lastSlot junto con el mapa byIdentity.

Para limitar la respuesta a un solo validador, agrega el parámetro identity con la dirección de la cuenta de voto. Esto es conveniente cuando ya sabes qué identidad estás monitoreando y no quieres filtrar un mapa grande en el cliente.

# Bounded range
curl -s https://your-solana-rpc-endpoint -X POST -H "content-type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlockProduction",
  "params": [
    { "range": { "firstSlot": 250000000, "lastSlot": 250000431 } }
  ]
}'

# Single identity
curl -s https://your-solana-rpc-endpoint -X POST -H "content-type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlockProduction",
  "params": [
    { "identity": "YourVoteAccountIdentityHere" }
  ]
}'

Elegir entre getBlockProduction, getBlocks, getSlot y getEpochInfo

Estos métodos responden preguntas diferentes y no son sustitutos. getBlockProduction da una medición agregada de producción y tasa de omisión por identidad sobre un rango. getBlocks devuelve una lista enumerada de bloques confirmados en un rango, que es lo que quieres para detección de brechas y reconciliación de indexadores; la página Solana getBlocks y detección de brechas por slots omitidos cubre ese flujo de trabajo. getSlot y getEpochInfo dan información puntual de la línea de tiempo en lugar de conteos de producción.

Una división práctica del trabajo: usa getBlockProduction para monitoreo a nivel de validador y alertas de tasa de omisión, getBlocks cuando necesitas saber exactamente qué slots faltan para un consumidor, y getSlot o getEpochInfo cuando necesitas la posición actual en la línea de tiempo. Si estás construyendo monitoreo basado en eventos en lugar de sondeo, la página Mecánica de slotSubscribe y blockSubscribe en Solana explica las alternativas de suscripción.

• getBlockProduction: producción agregada y tasa de omisión por identidad.
• getBlocks: bloques confirmados enumerados para detección de brechas.
• getSlot / getEpochInfo: posición puntual en la línea de tiempo.
• Suscripciones: alternativas basadas en push para monitoreo orientado a eventos.

Significado operativo de una tasa de omisión en aumento

La tasa de omisión importa porque un validador que produce tarde o no produce en sus slots programados degrada la latencia de confirmación para todos los que están aguas abajo. Cuando un líder omite, la red espera al siguiente líder programado, lo que puede agregar latencia a la confirmación de transacciones y a cualquier consumidor que dependa de la cadencia de bloques. Una tasa de omisión en aumento para una identidad específica es, por lo tanto, una señal que vale la pena investigar, ya sea que la causa sea local a ese validador o una condición de red más amplia.

Alerta sobre un umbral sostenido en lugar de una sola observación. Como los conteos son la vista del nodo consultado y pueden retrasarse respecto a la punta, una lectura puede ser ruidosa. Un patrón útil es calcular la tasa en una ventana móvil, compararla con un umbral que hayas elegido y exigir que la condición persista durante varias ventanas antes de generar una alerta. Esto reduce los falsos positivos por retraso transitorio de la punta o una época parcialmente completada.

Para patrones generales de monitoreo de endpoints que complementan este método, consulta Monitoreo de endpoints RPC.

• Los slots omitidos retrasan la confirmación para los consumidores aguas abajo.
• Usa una ventana móvil y un requisito de persistencia antes de alertar.
• Distingue una lectura ruidosa única de una tendencia sostenida.

Tabla de resultados reproducible para tu propio endpoint o validador

Los números que obtienes dependen del endpoint que consultas y la ventana que eliges, así que la forma honesta de presentarlos es como una tabla que tú mismo completas. Ejecuta el ejemplo de Node.js o las llamadas curl contra tu endpoint, registra el rango y los totales, y repite entre endpoints o a lo largo del tiempo. No trates ninguna fila individual como un benchmark; trata la tabla como tu propio registro de mediciones.

Completa una fila por endpoint o por validador por ventana. Mantener las columnas de rango explícitas permite comparar filas de manera justa y detectar cuándo una diferencia se explica por una ventana distinta y no por el comportamiento del endpoint.

• Endpoint / identidad: qué URL de RPC o dirección de cuenta de voto consultaste.
• Rango firstSlot / lastSlot: la ventana que el nodo evaluó.
• Σ leaderSlots y Σ blocksProduced: totales para la ventana.
• Tasa de omisión del rango: calculada a partir de los totales, no promediada.
• Tasa de omisión por identidad: para el validador que estás siguiendo.
• Observado en (marca de tiempo): cuándo ejecutaste la consulta.
• Notas: época completa o en curso, endpoint detrás de un balanceador de carga, etc.

Limitaciones, compensaciones y advertencias honestas

Los conteos reportados son la vista del nodo consultado. Pueden retrasarse respecto a la punta, y diferentes nodos detrás de un balanceador de carga pueden devolver valores distintos para la misma consulta nominal. Si muestreas a través de un balanceador de carga, trata cada respuesta como la perspectiva de un nodo y considera fijar las consultas de monitoreo a un nodo específico cuando la consistencia importe.

Las claves de identidad son direcciones de cuentas de voto. Mapearlas a nombres de validadores legibles, operadores o tu propio inventario es un trabajo que debes hacer tú mismo; el método RPC no proporciona ese mapeo. Sin un mapeo, una tabla de tasa de omisión es una lista de direcciones opacas.

Una época en curso es una ventana parcial, por lo que su tasa no es definitiva y cambiará a medida que la época se complete. Si necesitas un número estable, espera a que cierre la época o usa un rango histórico acotado que esté completamente en el pasado.

Por último, los slots omitidos son un comportamiento normal del protocolo, no necesariamente una falla. Una tasa de omisión distinta de cero no es por sí misma evidencia de mala configuración. Interprétala junto con otras señales y sé cauteloso al atribuir una omisión a una causa específica sin evidencia que la corrobore.

• Los conteos son locales al nodo y pueden retrasarse respecto a la punta o diferir entre nodos.
• Las claves de identidad son direcciones de cuentas de voto; el mapeo es tu responsabilidad.
• Las épocas en curso producen tasas provisionales.
• Los slots omitidos son normales; una tasa distinta de cero no es prueba de una falla.

Solución de problemas comunes de getBlockProduction

Si el mapa byIdentity está vacío, la causa más probable es un rango sin liderazgo programado o una ventana que no se superpone con la época que pretendías. Amplía el rango o elimina el parámetro range para volver a la época actual. Si una sola identidad falta en el mapa, esa identidad puede simplemente no haber tenido slots de liderazgo en la ventana; confírmalo con getLeaderSchedule.

Si firstSlot y lastSlot del objeto range no coinciden con lo que solicitaste, el nodo puede haber recortado o ajustado la ventana. Lee siempre el rango devuelto en lugar de asumir que tu solicitud fue respetada textualmente. Si los resultados difieren entre dos llamadas al mismo endpoint, el retraso de la punta o una época parcialmente completada son explicaciones comunes; vuelve a ejecutar después de que cierre la época.

Si estás comparando endpoints y ves discrepancias, recuerda que cada nodo tiene su propia vista. Fija la consulta a un nodo, o acepta que la comparación entre endpoints es aproximada. Para contexto de selección de endpoints y conectividad, consulta la Guía de la API de Solana (RPC Assistant) y la página de la red Solana.

• Mapa vacío: amplía el rango o usa la ventana de época predeterminada.
• Identidad faltante: verifica que tuviera slots de liderazgo en la ventana.
• Rango inesperado: lee el rango devuelto, no asumas que tu solicitud fue respetada.
• Discrepancia entre endpoints: los nodos tienen vistas independientes.

Próximos pasos para el monitoreo de validadores y endpoints

Comienza ejecutando el ejemplo de la época actual contra tu endpoint y registrando una línea base en la tabla de resultados. Luego prográmalo periódicamente, calcula una tasa de omisión móvil y alerta solo ante incumplimientos sostenidos del umbral. Combina getBlockProduction con getLeaderSchedule para mantener el denominador honesto, y con getBlocks cuando necesites brechas enumeradas para un consumidor.

Si estás eligiendo o escalando el acceso RPC para este tipo de monitoreo, revisa Precios de RPC y las opciones del Servicio de API, y explora el centro de aprendizaje de OnFinality para temas adyacentes de fiabilidad de Solana. El objetivo es una medición repetible que tú controles, no un número único.

• Registra una línea base y luego programa la medición periódica.
• Alerta sobre umbrales móviles sostenidos, no sobre lecturas individuales.
• Combina con getLeaderSchedule y getBlocks para una cobertura completa.