---
id: 18
title: "Glosario de métricas de rendimiento: TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto"
slug: performance-metrics-glossary
date: 2026/09/08
summary: TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto se mezclan sistemáticamente. Este artículo ofrece definiciones reutilizables, patrones de mal uso comunes y la lista de divulgación que conviene exigir a cualquier benchmark. No es asesoramiento de inversión.
keywords: TPS,BPS,latencia de confirmación,finalidad,tasa de conflicto,benchmarks
heroImage: /images/community-bg.png
---

Uno de los movimientos más comunes en la narrativa de cadenas públicas es soltar una cifra de rendimiento lo bastante grande. El «TPS pico» de una página de inicio y el rendimiento que se puede observar en cadena en tiempo real a menudo no son la misma estadística. Monitores de terceros han comparado públicamente los picos declarados con el rendimiento medido; en algunas redes la brecha abarca dos órdenes de magnitud o más. Eso no suele ser una simple historia de «quién miente», sino de que el «pico teórico» y el «rendimiento en una ventana de observación» se confunden por costumbre.

Para los lectores que evalúan diseños de alto rendimiento —sobre todo EVM paralela— las comparaciones son de manzanas con naranjas hasta que TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto comparten definiciones. [Quién debería leer sobre la EVM paralela](/es/blog/who-should-read-parallel-evm) dividió las rutas de lectura por rol; este artículo aporta el vocabulario de medición compartido. Las cifras externas citadas abajo son ejemplos de divulgación pública usados para ilustrar diferencias de medición; **no son calificaciones de proyectos ni asesoramiento de inversión**.

## TPS: una sigla, al menos tres fórmulas

TPS significa literalmente transacciones por segundo. En la práctica hay al menos tres cálculos distintos:

1. **Pico teórico / de laboratorio**: una cota superior bajo hardware, versión de cliente y mezcla de transacciones especificados (a menudo transferencias simples o carga sintética de bajo conflicto). Es el número más grande y el de extrapolación más débil a la mainnet.
2. **Rendimiento sostenible**: la tasa que el sistema puede mantener bajo restricciones declaradas de latencia y tasa de fallos. Para pagos y liquidación, suele ser más significativo que el pico.
3. **Rendimiento de la ventana de observación**: transacciones incluidas y confirmadas (bajo una definición de finalidad elegida) en una ventana de tiempo, divididas por los segundos. Refleja la demanda y la congestión reales, no el techo de capacidad.

Haga tres preguntas en paralelo o la comparación falla: ¿cómo se cuentan las transacciones (se incluyen votos y tareas de mantenimiento)? ¿Se incluyen las transacciones fallidas o revertidas? ¿Cuánto dura la ventana y qué hardware y versión de cliente se usaron? La EVM paralela añade una cuarta: ¿cuál fue la tasa de conflicto o la distribución de hotspots de la carga de prueba? Un pico sin distribución de conflictos tiene un valor limitado; se amplía en [Hotspots de conflicto y cargas de trabajo](/es/blog/parallel-evm-workload-hotspots).

La misma cadena puede publicar honestamente los tres modos de TPS: pico de laboratorio para el techo, sostenible para la banda utilizable del producto, ventana de observación para saber si la demanda llena la capacidad hoy. Imprimirlos como un solo número es donde empieza el desvío. Cuando vea «hasta», colóquelo por defecto en el cajón del pico y busque sus contrapartes sostenible y observada.

## BPS: no traduzca «bloques más rápidos» directamente a «usuarios más rápidos»

En este artículo BPS significa **bloques por segundo**, la frecuencia de producción de bloques. Subir los BPS puede acortar la espera media hasta el bloque siguiente, pero la latencia que percibe el usuario también depende de cuándo entra la transacción en el mempool del proponente, cuánto tardan la ejecución y los reintentos por conflicto, y cuántos bloques o rondas de votación más exige la finalidad del protocolo.

Los BPS son, por tanto, una métrica de consenso y de ritmo de empaquetado, no una estadística suficiente para la experiencia de extremo a extremo. Una cadena puede subir los BPS y aun así sentirse lenta si la ejecución de alto conflicto acumula una cola de reejecución. Al leer materiales, registre los BPS por separado de la latencia de confirmación y de la finalidad; no deje que tiempos de bloque más rápidos ocupen el lugar de toda la historia de rendimiento. Si un documento usa BPS con otro significado (por ejemplo, rendimiento orientado a bytes), siga la definición de esa página y no lo mezcle con el sentido de este artículo.

## Latencia de confirmación: del envío al «lo veo»

La latencia de confirmación suele significar: el tiempo desde que un usuario (o una cartera) envía una transacción hasta que la red la reconoce bajo alguna regla de «confirmación aceptable». La parte crítica es escribir qué significa «aceptable»: aparecer en el último bloque propuesto, sobrevivir k bloques posteriores o cumplir una condición de confirmación al estilo BFT.

Hábitos prácticos de lectura:

- Prefiera **p50 / p95 / p99** antes que solo los promedios; las colas generan tickets de soporte y ventanas de arbitraje.
- Anote la carga: la latencia de una cadena vacía y la de un período congestionado son métricas distintas.
- Para la ejecución paralela, vigile además si los reintentos por conflicto ensanchan parte de la distribución de latencia.
- Separe «ejecutado en mi nodo local» de «finalizado por la red»: las interfaces de cartera a veces muestran lo primero; la liquidación suele necesitar lo segundo.

Una divulgación completa de latencia declara la definición de confirmación, los percentiles, la descripción de la carga y cómo se muestrearon los clientes. Si falta cualquier ítem, el número es difícil de reproducir. Los pagos y la liquidación de comercios necesitan sobre todo cotas superiores de latencia predecibles; los materiales que solo dan promedios casi no tienen valor de decisión para esos escenarios.

## Finalidad: no confunda la finalidad económica con la del protocolo

La finalidad describe cuán costoso es —o si, por protocolo, es posible— revertir todavía el resultado de una transacción. Dos usos comunes se mezclan a menudo:

- **Finalidad de protocolo (finalidad determinista)**: bajo consenso al estilo BFT, una vez recolectados suficientes votos un bloque entra en estado confirmado y los nodos honestos no lo revertirán bajo el protocolo. La latencia suele enmarcarse en rondas de mensajes.
- **Finalidad económica / probabilística**: bajo la cadena más larga o ciertas reglas de confirmación progresiva, la probabilidad de reorganización cae a medida que se acumulan bloques, pero una cadena más larga todavía podría reemplazar el historial en teoría; «final» es un umbral de riesgo.

Llamar «finalizado» a «N confirmaciones» bajo finalidad probabilística distorsiona la comparación entre cadenas. Para escenarios de liquidación y puentes, indique qué modelo de finalidad aplica y bajo qué supuestos (fracción de hashpower o stake del adversario, sincronía de red). La narrativa técnica de Bitroot en torno a Pipeline BFT apunta a una finalidad de protocolo rápida; véase [Pipeline BFT y sinergia multi-motor](/es/blog/bitroot-pipeline-bft). Que se sostenga una afirmación de producto de finalidad por debajo del segundo sigue atada a las condiciones divulgadas de esa prueba: los objetivos de diseño no son hechos verificados de mainnet.

El tiempo de finalidad se relaciona con la latencia de confirmación, pero no es idéntico: los usuarios pueden refrescar una interfaz tras una confirmación blanda mientras los puentes y los custodios siguen esperando la finalidad del protocolo. Al comparar dos cadenas, alinee primero qué nivel de «suficientemente bueno» está comparando.

## Tasa de conflicto: el «denominador oculto» de la EVM paralela

La tasa de conflicto describe, bajo paralelismo optimista, la proporción de transacciones que deben revertirse o reejecutarse en serie por conflictos de conjuntos de lectura/escritura (las definiciones deberían indicar: por cantidad de transacciones o por gas; con granularidad de cuenta o de slot). Rara vez aparece en los carteles clásicos de un solo hilo, pero es el denominador que explica por qué los benchmarks de transferencias se ven rápidos y los de AMM se frenan.

Intuición aproximada:

- Tasa de conflicto cercana a 0: la aceleración paralela puede acercarse a la cantidad de motores de ejecución (aún limitada por la planificación y la sobrecarga de acceso al estado).
- Tasa de conflicto en aumento: el rendimiento efectivo se desliza hacia «ejecución serial más costo de reversión»; las CPU siguen ocupadas mientras los usuarios igual esperan.

Un benchmark honesto de EVM paralela, por tanto, reporta al menos dos cifras: carga de bajo conflicto y carga de alto conflicto (o mezcla realista de contratos), con la definición de conflicto declarada. Publicar solo un pico de transferencias esconde el denominador. Conviene comparar también una tasa de conflicto ponderada por gas: unas pocas transacciones pesadas de hotspot pueden perforar el rendimiento más que muchos conflictos ligeros.

## Lista mínima de divulgación para leer benchmarks

Cuando vea una tabla de rendimiento, marque las casillas:

| Divulgación | Por qué importa |
|------|------------|
| Hardware (CPU / RAM / disco / red) y cantidad de nodos | De lo contrario no se sabe si el pico se apiló sobre máquinas extremas |
| Versión y configuración del cliente | Mismo protocolo, implementaciones distintas, números distintos |
| Mezcla de transacciones y definición de tasa de conflicto | Decide si las cifras paralelas son extrapolables |
| Modo de TPS (pico / sostenible / observado) | Evita comparar tres fórmulas como si fueran una |
| Definición de confirmación y percentiles | Evita que se esconda «rápido en promedio, lento en la cola» |
| Tipo de finalidad (protocolo / económica) | Evita comparaciones falsas entre modelos |
| Mainnet, testnet o laboratorio | Las cifras de testnet no son rendimiento estable de producción |

Cuantos más ítems falten, menos citable es el número. Eso va contra la lógica de página de inicio de «más grande es mejor», pero es la única lectura reproducible para ingeniería e investigación. Léalo junto con las dimensiones de descentralización del artículo siguiente: el mismo pico medido solo en unas pocas máquinas de altas prestaciones en una sola ciudad se encoge aún más al extrapolarlo.

## Cierre

Las métricas de rendimiento no son adjetivos para una página de inicio; son mediciones que exigen anexos. El TPS no tiene un único valor verdadero, los BPS no pueden reemplazar la latencia del usuario, la confirmación y la finalidad deben definirse antes de comparar, y la tasa de conflicto ya no debería faltar en la lectura de la EVM paralela. Con este glosario alineado, las discusiones sobre descentralización frente a listones de hardware —y sobre el colapso del rendimiento bajo cargas calientes— tienen menos probabilidades de ser secuestradas por un solo pico.

## Lecturas relacionadas

- Anterior: [Quién debería leer sobre la EVM paralela: tres caminos para desarrolladores de contratos, ingenieros de cliente e investigadores](/es/blog/who-should-read-parallel-evm)
- Siguiente: [La tensión entre descentralización y rendimiento: requisitos de validadores, hardware y distribución geográfica](/es/blog/decentralization-performance-tradeoff)
- Relacionado: [Hotspots de conflicto y cargas de trabajo: cuándo ayuda de verdad una EVM paralela](/es/blog/parallel-evm-workload-hotspots)