Revelación de datos: ¿Por qué las transferencias en Solana se están ralentizando? ¿Es que los validadores están "haciendo cosas"?

Autor: Carlos 、 Luke Leasure

Título original: Las guerras de construcción de bloques en Solana

Compilación y organización: BitpushNews

El 5 de enero de 2026, JITO lanzó una herramienta pública llamada IBRL Explorer, diseñada para medir el comportamiento de los validadores en la empaquetación de bloques en Solana y revelar el “juego de tiempos” previamente invisible en la construcción de bloques.

Primero, necesitamos entender algunos antecedentes sobre la estructura del mercado de Solana. Solana fue diseñada como un sistema de procesamiento en flujo: en condiciones ideales, mientras se construye un bloque, el líder transmite continuamente fragmentos de datos (es decir, pequeños paquetes). Este comportamiento busca minimizar la latencia de confirmación de transacciones (el tiempo entre que un validador recibe una transacción y que esta se procesa). Sin embargo, si la línea de producción de transacciones de Solana es realmente continua, en realidad depende de cómo los validadores ensamblan sus bloques.

Jito define desde la perspectiva del validador el comportamiento óptimo de empaquetado de bloques: construcción rápida, transmisión continua en flujo y difusión temprana del estado. La puntuación IBRL de Jito es una mezcla ponderada de estos tres variables:

• Tiempo de Slot (35%): se obtiene una puntuación más alta si el bloque del validador se construye dentro de ciertos umbrales: si la transferencia de un slot de otro validador es menor a 550 ms, o si como slot consecutivo (es decir, en el que el líder en rotación aún tiene slots restantes) es menor a 380 ms.
• Empaquetado de transacciones no de votación (40%): cuando las transacciones se distribuyen uniformemente en los 64 ticks de un slot (en lugar de colocar la mayor parte de las transacciones no de votación en los últimos ticks, es decir, “empaquetado con retraso”), el validador recibe una recompensa en puntuación. Esta es la variable más controvertida en la puntuación IBRL, que se explicará en detalle más adelante.
• Votación temprana (25%): cuando al menos el 90% de las transacciones de votación se procesan en los primeros 32 ticks, el validador obtiene la puntuación máxima. Si las votaciones se retrasan hacia la parte final del bloque, la puntuación disminuye.

El IBRL Explorer muestra que muchos validadores retrasan el empaquetado de transacciones no de votación, en algunos casos incluso extendiendo el tiempo de slot. Este retraso en el empaquetado retrasa la difusión del estado, aumenta la varianza en los resultados de ejecución, rompe el diseño en flujo de Solana y reduce la latencia de la red. Lo que se obtiene no es un flujo continuo de datos, sino una explosión repentina de datos.

En un bloque óptimo, como en el ejemplo de un validador de Helius, la mayoría de las transacciones de votación se procesan en la primera mitad del bloque (“difusión temprana del estado”), mientras que las transacciones no de votación se distribuyen de manera relativamente uniforme en los 64 ticks del slot (“transmisión en flujo continuo”).

En contraste, el empaquetado con retraso intencionado en el ejemplo del bloque de Galaxy en la siguiente imagen es evidente, ya que la mayoría de las transacciones no de votación se colocan en los últimos ticks del slot. Al hacer esto, el validador prioriza el valor extractivo retrasando la conversión del estado hasta el último momento, en lugar de priorizar la salud de la red.

Según Lucas Bruder, cofundador y CEO de Jito Labs, los validadores están incentivados a esperar hasta el último momento del slot para observar más transacciones entrantes, y pagar las tarifas más altas para maximizar las recompensas.

Pero, ¿por qué le importa esto a los usuarios? Aunque para un validador individual maximizar beneficios sea una conducta racional, esta práctica introduce censura implícita, retrasos en la difusión del estado y obliga al siguiente líder a “alcanzar” al anterior, ralentizando toda la red.

Más importante aún, el empaquetado con retraso también está directamente relacionado con la emergente dinámica de “pago por flujo de órdenes” (PFOF) en Solana, que Benedict Brady ya ha resumido en este artículo. Debido a que las billeteras y aplicaciones suelen generar transacciones firmadas con rutas predefinidas (como órdenes de mercado con límites de deslizamiento), las órdenes contienen opciones valiosas de “ejecución posterior”. Lo que beneficia a los usuarios es vender estos derechos de ejecución posterior a las empresas de trading, mientras que la práctica extractiva sería realizar “ataques de sándwich”. En cualquiera de los casos, existe un incentivo para ralentizar la confirmación de transacciones y aumentar el valor de la ejecución posterior, precisamente lo que permite el empaquetado con retraso.

Este incentivo lleva a Solana a una estructura de mercado más adversarial para aplicaciones y usuarios. También debilita las garantías clave en las que confían los market makers, especialmente en la cancelación dentro del bloque y en la ejecución determinista, lo que amplía el spread. Sin transmisión en flujo, por muy buena que sea la lógica de la aplicación, el mercado en tiempo real sigue siendo inalcanzable para Solana.

Debate entre Temporal y Jito

Antes de profundizar en cómo Solana puede resolver este problema, hay que reconocer que existe un debate activo sobre qué constituye una “buena” construcción de bloques. Temporal, uno de los contribuyentes principales de Harmonic, cuestiona el marco y la metodología de puntuación IBRL de Jito. Su crítica es que esa puntuación incorpora un conjunto de preferencias de diseño específicas, que favorecen la forma en que Jito construye bloques, y asumen que Harmonic se ve en peor posición, lo cual se refleja en que los validadores que ejecutan Harmonic obtienen puntuaciones consistentemente más bajas.

Según el cofundador de Harmonic, sus bloques se construyen de forma continua y sin retrasos, pero los fragmentos de datos solo se liberan después de aproximadamente 300 ms de subasta. Este método da suficiente tiempo de competencia a los constructores de bloques y también permite que otras partes de la red vuelvan a reproducir los bloques de Harmonic. La visualización a continuación muestra un ejemplo del mismo slot (391,822,619), en el que un validador que ejecuta Harmonic, Temporal Emerald, construye el bloque.

Desde la perspectiva de cómo se propaga el bloque (la imagen superior), la construcción de Harmonic parece ser uniforme en intervalos. En otras palabras, los constructores de bloques construyen de forma continua en paralelo, y las transacciones se concentran en los últimos ticks porque allí se decide en la subasta.

En los últimos 30 días, Harmonic ha superado a Jito y Firedancer en ingresos promedio y mediana por bloque (tarifa prioritaria + propinas), generando mayores recompensas para validadores y stakers. La pregunta pendiente es si este rendimiento superior se logra mediante el juego de tiempos mencionado anteriormente, sacrificando los intereses de los usuarios.

Fuente: https://reports.firedancer.io/

Múltiples proponentes concurrentes (MCP) y BAM

Tras presentar los puntos de vista de ambos lados, hay una conclusión que sigue siendo válida: la transmisión en flujo continuo es fundamental.

La postura de Harmonic no es que la transmisión en flujo no sea importante, sino que IBRL no captura cómo Harmonic logra esto, y puede clasificar erróneamente su mecanismo de subasta como un “juego de tiempos”. En esta etapa, no tengo suficiente conocimiento técnico ni datos para formar una opinión definitiva, pero Solana ya está desarrollando una solución protocolar para abordar los incentivos subyacentes.

Esta solución es la arquitectura de Múltiples Proponentes Concurrentes (MCP), desarrollada por Anatoly Yakovenko y Max Resnick. La motivación es simple: en el modelo actual de un solo líder, un proponente controla el orden y puede actuar más tarde que otros, logrando empaquetado con retraso y reforzando la dinámica PFOF mencionada. MCP elimina el monopolio del líder único permitiendo que múltiples proponentes construyan candidatos a bloques en paralelo e independientemente. Esta arquitectura puede evitar que un solo líder suprima transacciones o retrase la ejecución para extraer beneficios.

Es decir, una condición previa para MCP es que Alpenglow llegue a la mainnet. Se espera que Alpenglow se lance en 2026, pero la fecha aún no está confirmada. Mientras tanto, BAM de Jito podría impulsar cambios al hacer que la lógica de ordenamiento sea auditable. BAM busca ampliar el espacio de diseño microestructural de Solana, permitiendo que aplicaciones que requieren control más fino del orden (como plataformas de trading de derivados perpetuos que priorizan cancelaciones) puedan implementarse, y ayudando a mitigar efectos negativos de MEV externo, como los ataques de sándwich. La siguiente imagen muestra la línea de flujo de transacciones de BAM.

BAM (Agave-BAM) ya es actualmente el tercer cliente más grande en Solana en términos de participación en staking (aproximadamente 12%), solo detrás de Agave-Jito y Frankendancer-Jito. Aproximadamente 205 validadores ya están ejecutando BAM, lo que destaca su rápida adopción en la comunidad de validadores de Solana. En comparación, Harmonic aún es relativamente pequeño, con poco más del 3% de participación en staking y unos 20 validadores.

Es importante seguir la evolución de la competencia en construcción de bloques en los próximos meses y qué implicaciones tendrá esto en la estructura del mercado de Solana.