Benchmarking BFT: Medir TPS, latencia y saturación sin caer en métricas vanidosas

En blockchain, las cifras de TPS (transacciones por segundo) circulan como si fueran la ficha técnica completa de un protocolo. No lo son. Un número de throughput aislado no dice cuánto esperó cada transacción, con cuántas réplicas se midió, qué tamaño tenían los mensajes, si la red cruzaba continentes ni qué pasaba cuando el líder se caía.

Este artículo propone una forma honesta de medir: tratar el benchmark como un experimento con variables declaradas, curvas en lugar de puntos y fallas inyectadas a propósito. Usaremos como referencia la manera en que evalúan sus sistemas los papers de HotStuff, Narwhal y Tusk y ResilientDB, y la metodología de testing de Twins para recordar que el rendimiento y la corrección se prueban con herramientas distintas.

Por qué un número de TPS no es un resultado

Un protocolo de consenso BFT ordena transacciones entre $n$ réplicas de las cuales hasta $f$ pueden comportarse de forma arbitraria. Su rendimiento depende de casi todo lo que rodea al protocolo: el tamaño del comité, el tamaño de los lotes, la latencia entre réplicas, el costo de verificar firmas y la forma en que se diseminan los datos. Cambiar cualquiera de esas variables mueve el resultado, a veces más que cambiar de protocolo.

Por eso los papers serios no reportan un número, sino familias de curvas. La evaluación de HotStuff, por ejemplo, compara su implementación con BFT-SMaRt y presenta throughput y latencia variando el tamaño de lote, el tamaño de las solicitudes y respuestas y el número de réplicas. [1] Cada curva responde una pregunta distinta; ninguna, por sí sola, resume el protocolo.

La pregunta útil para un equipo de ingeniería no es "¿cuántos TPS?", sino "¿cuánto throughput puedo sostener manteniendo la latencia por debajo de lo que mi aplicación tolera, con este comité, esta red y estas fallas?". Esa pregunta ya contiene las tres dimensiones que un benchmark debe fijar: carga, latencia objetivo y condiciones del entorno.

La curva throughput-latencia y la rodilla de saturación

La forma estándar de presentar el rendimiento de un sistema de consenso es una curva con throughput comprometido en un eje y latencia en el otro. Para construirla, el experimento ofrece carga creciente desde clientes y, en cada nivel, mide cuántas transacciones se comprometen por segundo y cuánto tardan. Narwhal y Tusk se evalúan exactamente así: los clientes envían transacciones a una tasa fija, la latencia se mide de extremo a extremo desde el envío hasta el commit, y los resultados se muestran como curvas de latencia contra throughput. [2]

Con carga baja, la curva es casi plana: hay capacidad de sobra, las colas están vacías y la latencia se acerca al piso que imponen los viajes de red y las fases del protocolo. A medida que la carga crece, algún recurso se acerca a su límite. En un protocolo con líder, suele ser el ancho de banda o la CPU del líder, que debe difundir los bloques y procesar los votos.

La rodilla de saturación es la región donde el throughput deja de seguir a la carga ofrecida y la latencia sube con rapidez. Pasada esa zona, el sistema no compromete más transacciones por segundo; simplemente acumula más trabajo pendiente. Un resultado de throughput máximo tomado más allá de la rodilla suele venir acompañado de latencias que ninguna aplicación interactiva aceptaría.

La teoría de colas da una intuición útil. La ley de Little relaciona el número promedio de transacciones en el sistema $L$, la tasa de llegada $\lambda$ y el tiempo promedio de permanencia $W$ mediante $L = \lambda W$ para sistemas estables. Si la tasa de llegada supera la capacidad de servicio, el sistema deja de ser estable: $L$ crece sin cota y $W$ con él. La rodilla es el aviso de que te acercas a ese borde.

Ojo con un detalle de lectura: dos protocolos se comparan con justicia en la misma latencia objetivo o en curvas completas, no en sus picos respectivos. Si uno reporta su máximo con latencias muy altas y otro con latencias bajas, la comparación de picos no dice nada sobre cuál sirve mejor a tu aplicación.

Safety y liveness no son métricas de rendimiento

Un benchmark responde cuánto y cuán rápido. No responde si el protocolo es correcto. Safety significa que dos réplicas correctas nunca comprometen bloques en conflicto; liveness significa que, después de GST, las transacciones terminan comprometiéndose. Ninguna curva de throughput demuestra la primera propiedad: un sistema puede ser rapidísimo y tener un bug que, bajo una combinación rara de particiones y cambios de vista, comprometa dos historias distintas.

Twins ataca justamente ese hueco. Su metodología crea réplicas gemelas que comparten identidad y claves para emular comportamientos bizantinos como la equivocación y el doble voto, y genera de forma sistemática escenarios con particiones y elecciones de líder para buscar violaciones de safety y liveness. [4] Es una herramienta de testing, no de medición de rendimiento, y esa separación es la lección.

En la práctica, un informe de benchmark honesto debe registrar dos tipos de señal en columnas separadas. Las señales de corrección son binarias o de conteo: violaciones de safety observadas (que deben ser cero), vistas que no produjeron commit, tiempo hasta recuperar el progreso. Las señales de rendimiento son continuas: throughput comprometido y percentiles de latencia. Mezclarlas en una sola cifra esconde justo lo que importa cuando algo sale mal.

Que un benchmark no observe violaciones de safety tampoco es una prueba de safety. Es evidencia de que ese escenario concreto no la rompió. La garantía viene de la demostración del protocolo, como la regla de bloqueo y el commit de tres cadenas de HotStuff, y de testing dirigido como el de Twins. [1] [4]

Escenarios de falla: líder caído y particiones

El caso sin fallas es el mejor caso, y por eso no basta. Un protocolo basado en líder progresa al ritmo de la red mientras el líder es correcto, pero cuando el líder cae, las réplicas deben esperar un timeout y ejecutar un cambio de vista antes de volver a comprometer. En HotStuff ese mecanismo lo coordina el pacemaker, y su costo aparece como vistas sin commit y picos de latencia. [1]

Narwhal y Tusk incluyen esta dimensión de forma explícita: evalúan sus sistemas con réplicas caídas y comparan contra una línea base de HotStuff. Su observación es que el protocolo basado en líder pierde rendimiento de manera marcada cuando los líderes fallan, mientras que Tusk, que es asíncrono y no depende de timeouts para avanzar, se ve mucho menos afectado. [2] No hace falta aceptar la conclusión para aprender el método: un benchmark sin fallas omite el régimen donde los protocolos más se diferencian.

Al diseñar escenarios conviene distinguir al menos tres casos. Primero, réplicas caídas desde el inicio, que reducen el comité efectivo y obligan a saltar las vistas de líderes muertos. Segundo, un líder que cae a mitad de la ejecución, que mide el tiempo de recuperación. Tercero, particiones o retrasos de red temporales, que ponen a prueba los timeouts y el comportamiento antes y después de GST.

Para cada escenario hay que reportar cuándo se inyecta la falla, cuánto dura y qué métrica se observa durante la recuperación. Un promedio de latencia sobre toda la corrida diluye una ventana de varios segundos sin commits; un percentil alto o una serie temporal la deja a la vista.

Variables del experimento: comité, payload y lotes

Un benchmark es un experimento, y un experimento declara sus variables independientes. En BFT, las que más mueven el resultado son el tamaño del comité, el tamaño de las transacciones, el tamaño de los lotes y la topología de red. HotStuff, por ejemplo, reporta curvas separadas para distintos tamaños de lote y de payload, y otra serie que escala el número de réplicas. [1]

El tamaño del comité importa porque cada QC exige votos de una supermayoría y porque el líder debe enviar cada propuesta a todas las réplicas. Un resultado medido con cuatro réplicas no dice cómo se comportará el sistema con decenas. Narwhal y Tusk reportan resultados para varios tamaños de comité y, además, escalan el número de workers por validador para mostrar cómo crece el throughput al separar la diseminación de datos del ordenamiento. [2]

La topología es la otra variable que suele esconderse. ResilientDB presenta GeoBFT, un diseño pensado para despliegues repartidos en varias regiones, y lo evalúa en ese escenario geográfico frente a otros protocolos BFT. [3] La lección metodológica es directa: la latencia entre regiones forma parte del experimento, y un benchmark en una sola LAN mide otro sistema.

Reproducibilidad: lo que un benchmark debe publicar

Un resultado que nadie puede repetir es una anécdota. Para que otro equipo pueda reproducir o refutar una curva, el informe debe publicar el commit exacto del código, la configuración de cada réplica, el tipo de máquina, la ubicación de cada nodo, la tasa de carga ofrecida en cada punto, la duración de cada corrida y cuántas veces se repitió. También debe indicar dónde empieza y termina la medición de latencia.

La duración y el calentamiento importan. Las primeras decenas de segundos de una corrida mezclan conexiones que se abren, cachés frías y colas que todavía se llenan. Medir solo una ventana estable, repetir la corrida varias veces y reportar la dispersión evita confundir ruido con diferencias entre protocolos.

Por último, el script que genera la carga y procesa los resultados forma parte del experimento. Si se publica junto al código del protocolo, un lector puede comprobar que el throughput se cuenta en commits y no en envíos, y que la latencia se calcula sobre todas las transacciones y no sobre una muestra favorable.

El laboratorio consensus-benchmark: fixtures, no mediciones

TrautsLab acompaña este capítulo con un laboratorio ejecutable en lab.trautslab.dev/consensus-benchmark. Conviene ser claro sobre lo que es: un arnés pedagógico con escenarios deterministas (una ejecución sana, un líder bizantino y pérdida de paquetes) definidos como fixtures. No abre sockets, no levanta nodos y no mide ninguna implementación real de HotStuff ni de otro protocolo. Sus cifras de latencia son datos de ejemplo, no resultados de rendimiento.

Lo que sí enseña es la estructura de un informe honesto. Para cada escenario registra por separado las violaciones de safety, las vistas ejecutadas, los commits obtenidos, las vistas de recuperación y la latencia mediana, y falla de forma explícita si algún escenario viola safety o no recupera progreso. Es decir, practica la separación entre señales de corrección y señales de rendimiento que este artículo defiende.

Un buen ejercicio es extender los fixtures con un escenario de partición temporal y preguntarse qué columnas cambiarían y cuáles deberían quedar intactas. Si una partición produce una violación de safety en el informe, el problema no es de rendimiento: es un bug de protocolo, y la herramienta adecuada para buscarlo se parece más a Twins que a una curva de throughput. [4]

Siguiente lectura

Para entender por qué el líder suele ser el primer recurso en saturarse, sigue con el cuello de botella de la doble transmisión de datos en los líderes. Si quieres ver cómo un mempool DAG ataca ese límite, continúa con Narwhal como mempool DAG para HotStuff. Y para la mitad del problema que ningún benchmark resuelve, lee Twins y la detección de errores de estado y bloqueos.