Fundamentos de blockchain al estilo Chainspect: una metodología reproducible para métricas de TPS, finalidad y descentralización

Qué mide realmente un rastreador de fundamentos de blockchain

Un rastreador de fundamentos como Chainspect agrega señales técnicas observables desde un nodo: cuántas transacciones está procesando una cadena en este momento, cuánto tardan en producirse los bloques, cuánto tiempo pasa hasta que una transacción es irreversible, cuántos ingresos por comisiones genera la cadena y qué tan concentrado está el poder de los validadores o del stake. El valor no es un número individual, sino la capacidad de comparar la misma métrica entre redes usando una definición consistente.

El punto editorial importante es que estos paneles son descriptivos, no prescriptivos. Una cifra alta de TPS en tiempo real te dice lo que una cadena está haciendo en este minuto; no te dice lo que puede sostener bajo carga adversaria, ni si las transacciones son económicamente significativas. Trata cada cifra del panel como una hipótesis que puedes probar con tus propias llamadas RPC.

• Rendimiento: transacciones por segundo, tanto en tiempo real como el máximo registrado.
• Latencia: tiempo de bloque y tiempo hasta la finalidad, que son cosas diferentes.
• Economía: comisiones pagadas, ingresos on-chain y métricas de valor.
• Descentralización: número de validadores, distribución del stake, coeficiente de Nakamoto.
• Vitalidad: si los bloques se siguen produciendo al ritmo esperado.

Requisitos previos y supuestos antes de medir

Necesitas un endpoint RPC para cada cadena que quieras comparar, idealmente uno que exponga métodos JSON-RPC estándar como eth_blockNumber, eth_getBlockByNumber y eth_getBlockReceipts. Para cadenas no EVM los nombres de los métodos difieren, pero el patrón es el mismo: obtener bloques recientes, contar transacciones y marcarlas con tiempo. Si aún no tienes endpoints, la guía de endpoints RPC multicadena explica cómo estructurar el acceso, y puedes comparar planes en la página de precios de RPC.

Asume que tu endpoint puede estar balanceado entre nodos ligeramente desincronizados. Eso está bien para medir rendimiento en una ventana de docenas de bloques, pero distorsionará las mediciones de latencia de un solo bloque. Para trabajos sensibles a la finalidad, fija un solo nodo o usa un nodo dedicado para no cambiar de backend silenciosamente a mitad de la medición.

Por último, decide tu ventana de antemano. Una ventana de 60 segundos es ruidosa; una de 7 días suaviza los picos pero oculta el comportamiento máximo. Publica ambas si quieres ser honesto sobre el rendimiento de una cadena.

El modelo mental: rendimiento, tiempo de bloque y finalidad son tres relojes diferentes

El rendimiento es una tasa: transacciones divididas por el tiempo transcurrido en tiempo real. El tiempo de bloque es una cadencia: el intervalo entre las marcas de tiempo de los bloques. La finalidad es una garantía: el punto después del cual una transacción no puede revertirse bajo los supuestos del protocolo. Estos tres relojes se mueven de forma independiente. Una cadena puede producir un bloque cada 400 ms y aún tardar 12 segundos en finalizar, y una cadena puede finalizar instantáneamente mientras procesa muy pocas transacciones por segundo.

Por eso los paneles separan el TPS en tiempo real del TPS máximo registrado. El TPS en tiempo real es un promedio móvil de las transacciones realmente incluidas. El TPS máximo registrado es la tasa sostenida más alta observada en alguna ventana, lo cual es un hecho histórico, no una garantía de capacidad. Ninguno equivale al TPS teórico de un whitepaper, que suele ser un benchmark en condiciones ideales y debería etiquetarse como tal.

Para la finalidad, la medición honesta es la diferencia entre el bloque que incluyó tu transacción y el bloque en el que el protocolo la declara irreversible. En cadenas con finalidad probabilística, esa diferencia es un umbral de confianza, no un límite duro, así que cualquier número único es una convención que debes declarar.

Procedimiento ejecutable: medir TPS en tiempo real a partir de bloques en bruto

La medición de TPS reproducible más simple obtiene los últimos N bloques, suma sus recuentos de transacciones y divide por la diferencia de marcas de tiempo entre el bloque más nuevo y el más antiguo. El script siguiente usa un RPC_URL de marcador de posición y funciona en cualquier cadena compatible con EVM. Ejecútalo varias veces a lo largo del día para ver la varianza.

Ten en cuenta que los recuentos de transacciones de las cabeceras de bloque incluyen transacciones fallidas en la mayoría de las cadenas EVM. Si quieres el TPS de transacciones exitosas, debes obtener los recibos, lo cual es más lento pero más preciso para comparaciones económicas.

import json, urllib.request, time

RPC_URL = "RPC_URL"
WINDOW = 50  # blocks to sample

def rpc(method, params):
    req = urllib.request.Request(
        RPC_URL,
        data=json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params}).encode(),
        headers={"Content-Type":"application/json"},
    )
    with urllib.request.urlopen(req, timeout=15) as r:
        return json.load(r)["result"]

head = int(rpc("eth_blockNumber", []), 16)
blocks = []
for n in range(head - WINDOW + 1, head + 1):
    b = rpc("eth_getBlockByNumber", [hex(n), False])
    blocks.append((int(b["timestamp"], 16), len(b["transactions"])))

elapsed = blocks[-1][0] - blocks[0][0]
tx_total = sum(c for _, c in blocks[1:])
tps = tx_total / elapsed if elapsed else 0
print(f"blocks={WINDOW} elapsed={elapsed}s txs={tx_total} tps={tps:.2f}")

Procedimiento ejecutable: tiempo de bloque y verificación de finalidad

El tiempo de bloque es el intervalo medio entre marcas de tiempo de bloques consecutivos en tu ventana. Es fácil de calcular y fácil de malinterpretar: una cadena con producción de bloques variable puede mostrar un promedio estable mientras los intervalos individuales son largos. Reporta la mediana y el intervalo máximo junto con la media para que los lectores puedan ver la cola.

Para la finalidad, la verificación portátil es enviar una transacción y sondear hasta que el bloque que la contiene esté en o por debajo de la cabeza finalizada de la cadena. El fragmento siguiente asume un endpoint que expone una etiqueta de bloque finalizado; sustituye el método de finalidad nativo de la cadena donde difiera.

async function finalityProbe(rpcUrl, txHash) {
  const call = async (method, params) => {
    const r = await fetch(rpcUrl, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
    });
    return (await r.json()).result;
  };

  const start = Date.now();
  const receipt = await call("eth_getTransactionReceipt", [txHash]);
  const includedIn = parseInt(receipt.blockNumber, 16);

  while (true) {
    const fin = await call("eth_getBlockByNumber", ["finalized", false]);
    const finNum = parseInt(fin.number, 16);
    if (finNum >= includedIn) {
      return { includedIn, finalizedAt: finNum, seconds: (Date.now() - start) / 1000 };
    }
    await new Promise((r) => setTimeout(r, 1000));
  }
}

finalityProbe("RPC_URL", "0xYOUR_TX_HASH").then(console.log);

Tabla de resultados: qué registrar y cómo presentarlo

No publiques un solo número de TPS. Publica una tabla con la ventana, el tamaño de la muestra y la dispersión para que un lector pueda juzgar si la cifra es estable. La plantilla siguiente es la presentación honesta mínima; complétala con tus propios valores medidos, nunca con cifras prestadas o estimadas.

Si te comparas con un panel público, registra la ventana declarada y la marca de tiempo del panel junto a las tuyas para que ambas sean comparables. Un panel que muestra TPS de 24 horas y tu script que muestra una ventana de 50 bloques no están midiendo lo mismo, y la diferencia suele ser mayor que la varianza subyacente de la cadena.

Entradas de descentralización y por qué son más difíciles de reproducir

El rendimiento es barato de medir; la descentralización no. Los recuentos de validadores, la distribución del stake y el coeficiente de Nakamoto dependen de un estado específico de la cadena que puede no estar expuesto a través del RPC estándar. Algunas cadenas exponen conjuntos de validadores mediante un método dedicado o una consulta de pallet de staking; otras requieren un indexador o un panel de gobernanza.

Cuando no puedas reproducir directamente una métrica de descentralización, al menos verifica sus entradas. Confirma el recuento de validadores contra el propio módulo de staking de la cadena, confirma la distribución del stake contra la misma fuente que cita el panel e indica el bloque de la instantánea. Un coeficiente de Nakamoto calculado con datos de stake obsoletos es una curiosidad histórica, no una propiedad actual.

Aquí es también donde los paneles demuestran su valor: mantener pipelines consistentes de validadores y stake en docenas de redes es trabajo de ingeniería real. Reproducirlo para una cadena es factible; reproducirlo para cincuenta es un producto, no un script.

Solución de problemas con números inconsistentes o sorprendentes

Si tu TPS difiere mucho de un panel, revisa los sospechosos habituales en orden. La mayoría de las discrepancias son de definición, no maliciosas.

Si tu sonda de finalidad nunca se resuelve, comprueba si tu endpoint admite la etiqueta finalized o si la cadena usa una primitiva de finalidad diferente. Si las marcas de tiempo de los bloques parecen incorrectas, confirma que estás leyendo la cadena canónica y no una bifurcación o un endpoint de testnet. Si los números varían entre ejecuciones, probablemente tu balanceador de carga esté enrutando a nodos con alturas diferentes; fija el endpoint.

• Desajuste de ventana: 50 bloques versus 24 horas versus 7 días.
• Transacciones fallidas incluidas en los recuentos de cabecera pero no en los recuentos de TPS exitoso.
• Transacciones de L2 o rollup agrupadas en una sola transacción de L1.
• Retraso del endpoint: tu nodo está por detrás de la cabeza que lee el panel.
• Fuente de la marca de tiempo: marca de tiempo del bloque versus hora local de recepción.
• Endpoint de testnet o bifurcación usado accidentalmente en lugar de mainnet.

Limitaciones y compensaciones de las métricas estilo panel

Los paneles de fundamentos optimizan la comparabilidad, lo que significa que necesariamente aplanan los matices específicos de cada cadena. Una sola columna de TPS no puede expresar que las transacciones de una cadena son transferencias simples mientras que las de otra son llamadas a contratos con diferentes costos de gas. Una sola columna de finalidad no puede expresar garantías probabilísticas versus deterministas. Estas son compensaciones, no defectos, pero deberías saber cuáles estás aceptando.

También existe una brecha entre medición y significado. Un alto rendimiento con bajos ingresos por comisiones puede indicar actividad subsidiada; altos ingresos con bajo rendimiento pueden indicar espacio de bloque costoso. Leer dos columnas juntas es más informativo que clasificar cadenas por cualquier métrica individual, y es el hábito que separa el análisis de la simple observación de tablas de clasificación.

Por último, los paneles en tiempo real son instantáneas. Si necesitas tendencias históricas o investigación reproducible, captura tus propias muestras de forma programada y guárdalas, en lugar de depender de una página que se actualiza bajo tus pies.

Próximos pasos: construye tu propio pipeline de fundamentos

Empieza con una cadena y una métrica. Ejecuta el script de TPS de forma programada, escribe los resultados en un pequeño almacén de series temporales y añade tiempo de bloque y finalidad una vez que el primer pipeline sea estable. Cuando te expandas a múltiples cadenas, estandariza la ventana y la regla de conteo de transacciones antes de añadir redes; de lo contrario, tus comparaciones serán de peras con manzanas.

Para la selección de endpoints entre las redes que quieras rastrear, el directorio de redes lista las cadenas compatibles, y el servicio de API describe cómo obtener claves y gestionar límites de velocidad. Si estás ejecutando tus propios nodos de medición para mantener la consistencia, revisa la guía de alojamiento de nodos de blockchain antes de comprometerte con la infraestructura.

Para la pregunta concreta de qué endpoint usar para una cadena específica, deja esa decisión en manos de RPC Assistant en lugar de adivinar; la metodología anterior es independiente del endpoint, y la elección del endpoint debe basarse en criterios de fiabilidad y latencia. Una vez que tu pipeline esté en marcha, tendrás algo más valioso que una captura de pantalla de un panel: un registro reproducible de lo que cada cadena realmente hizo, con las consultas para demostrarlo.