Autor: Carlos, Luke Leasure
Título original: Solana’s block-building wars
Compilado y organizado: BitpushNews
2026年1月5日, JITO lanzó una herramienta pública llamada IBRL Explorer, diseñada para medir el comportamiento de empaquetamiento de bloques de los validadores en Solana y revelar la "manipulación del timing" previamente invisible en la construcción de bloques.
Primero, necesitamos entender algunos antecedentes sobre la estructura de mercado de Solana. Solana fue diseñado 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 de datos). Este comportamiento tiene como objetivo minimizar la latencia de procesamiento de transacciones (es decir, el intervalo de tiempo entre que un validador recibe una transacción y cuando esta es procesada). Sin embargo, si la canalización de transacciones de Solana es verdaderamente continua, en realidad depende de cómo los validadores ensamblan sus bloques.
Jito define el comportamiento óptimo de empaquetamiento de bloques desde la perspectiva del validador: 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 estas tres variables:
-
Tiempo del Slot (35%): Los validadores obtienen una puntuación más alta si su bloque se construye dentro de los siguientes umbrales: slot de traspaso (tomado de otro validador) menos de 550 ms, o como slot continuo (es decir, cualquier slot restante en la ronda del líder) menos de 380 ms.
-
Empaquetamiento de transacciones no votantes (40%): Los validadores son recompensados con puntos cuando las transacciones se distribuyen uniformemente a lo largo de los 64 ticks del slot (en lugar de amontonar la mayoría de las transacciones no votantes en los últimos ticks del slot, es decir, "empaquetamiento tardío"). Esta es la variable más controvertida de la puntuación IBRL, que se explicará en detalle más adelante.
-
Votación temprana (25%): Los validadores obtienen la puntuación completa cuando al menos el 90% de las transacciones de votación se procesan dentro de los primeros 32 ticks. La puntuación disminuye si la votación se retrasa hacia partes posteriores del bloque.
IBRL Explorer muestra que muchos validadores practican el empaquetamiento tardío de transacciones no votantes, y en algunos casos incluso extienden el tiempo del slot. El empaquetamiento tardío retrasa la propagación del estado, aumenta la varianza de los resultados de ejecución, socava el diseño de flujo de Solana y, por lo tanto, reduce la latencia de la red. En lugar de un flujo continuo de datos, se obtiene una erupción repentina de datos.
En un bloque óptimo, como el ejemplo del validador Helius a continuación, 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 votantes se distribuyen de manera relativamente uniforme a lo largo de los 64 ticks del slot ("transmisión continua en flujo").
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, seleccionando aquellas con las tarifas más altas, maximizando así las recompensas.
Pero, ¿por qué debería importarle a los usuarios? Aunque maximizar las ganancias es un comportamiento racional para un validador individual, este comportamiento introduce censura implícita, retrasa la propagación del estado y obliga al siguiente líder a "ponerse al día", ralentizando así toda la red.
Lo más importante es que el empaquetamiento tardío también está directamente relacionado con la dinámica emergente de "Pago por Flujo de Órdenes" (PFOF) de Solana, como Benedict Brady ha descrito en este artículo. Dado que las billeteras y aplicaciones suelen generar transacciones firmadas previamente enrutadas (es decir, órdenes de mercado con límites de deslizamiento), las órdenes incorporan valiosas opciones de "post-ejecución". Lo favorable para el usuario es vender este derecho de post-ejecución a firmas de trading, mientras que el comportamiento extractivo sería realizar "ataques sandwich". De cualquier manera, existe un incentivo para ralentizar el procesamiento de transacciones para aumentar el valor de la post-ejecución, que es exactamente lo que logra el empaquetamiento tardío.
Este incentivo empuja a Solana hacia una estructura de mercado más adversa para las aplicaciones y los usuarios. También debilita las garantías clave en las que confían los creadores de mercado, particularmente en cuanto a cancelaciones dentro del bloque y ejecución determinista, lo que lleva a un ensanchamiento de los spreads de compra-venta. Sin transmisión en flujo, sin importar cuán buena sea la lógica de la aplicación, los mercados verdaderamente en tiempo real seguirán siendo inalcanzables para Solana.
El debate Temporal vs. Jito
Antes de profundizar en cómo Solana puede resolver este problema, es importante reconocer que existe un debate activo incluso sobre lo que constituye una "buena" construcción de bloques. Temporal, contribuyente principal de Harmonic, ha objetado el marco y el método de puntuación IBRL de Jito. Su crítica es que la puntuación incorpora un conjunto específico de preferencias de diseño que favorecen la forma en que Jito construye bloques y, por defecto, hace que Harmonic parezca peor, lo que se refleja en las puntuaciones consistentemente más bajas de los validadores que ejecutan Harmonic.
Según el cofundador de Harmonic, los bloques de Harmonic se ejecutan de forma continua sin demora, pero los fragmentos de datos solo se liberan después de que se completa una subasta de unos 300 ms. Este método da suficiente tiempo a los constructores de bloques para competir y también da suficiente tiempo al resto de la red para reproducir el bloque de Harmonic. La visualización a continuación muestra el mismo slot (391,822,619) del validador Temporal Emerald, que ejecuta Harmonic.
En el contexto de cómo se propaga el bloque (gráfico superior), la ejecución de Harmonic parece estar espaciada uniformemente. En otras palabras, el constructor de bloques construye continuamente el bloque mediante construcción de bloques en paralelo, y las transacciones solo se concentran en los ticks finales (gráfico inferior) porque ese es el momento de la resolución de la subasta.
En los últimos 30 días, Harmonic ha superado a Jito y Firedancer en los ingresos totales promedio y medianos por bloque (tarifa prioritaria + propinas), generando así mayores recompensas para validadores y stakers. La pregunta pendiente es si este rendimiento superior se logra a expensas de los usuarios mediante la manipulación del timing descrita anteriormente.
Fuente: https://reports.firedancer.io/
Proponentes Múltiples Concurrentes (MCP) vs. BAM
Después de exponer ambos lados, un punto sigue siendo cierto: la transmisión continua en flujo es crucial.
La afirmación de Harmonic no es que la transmisión en flujo no sea importante, sino que el IBRL no captura cómo Harmonic la logra, y potencialmente clasifica erróneamente su mecanismo de subasta como "manipulación del timing". En esta etapa, no tengo suficiente contexto técnico o datos para formar una opinión definitiva, pero Solana ya está desarrollando una solución dentro del protocolo destinada a abordar el problema subyacente de incentivos.
Esta solución son los Proponentes Múltiples Concurrentes (MCP), una arquitectura desarrollada por Anatoly Yakovenko y Max Resnick. La motivación es simple: bajo el modelo actual de líder único, un proponente controla el ordenamiento y, de hecho, puede actuar más tarde que otros, permitiendo así el empaquetamiento tardío y reforzando la dinámica tipo PFOF descrita anteriormente. MCP elimina el monopolio del líder único al permitir que múltiples proponentes construyan bloques candidatos de forma independiente y en paralelo. Esta arquitectura evita que un solo líder suprima unilateralmente transacciones o retrase la ejecución para extraer ganancias.
Dicho esto, un prerrequisito para MCP es que Alpenglow esté activo en la red principal. Se espera que Alpenglow se lance en 2026, pero el cronograma aún es incierto. Mientras tanto, BAM de Jito podría impulsar el cambio al hacer que la lógica de ordenamiento sea auditable. BAM tiene como objetivo expandir el espacio de diseño microestructural de Solana, permitiendo aplicaciones que requieren un control más granular del ordenamiento (por ejemplo, priorizar la cancelación de órdenes en venues de trading de perpetuals), al mismo tiempo ayuda a mitigar los efectos externos negativos de MEV, como el front-running. El siguiente diagrama describe la canalización de transacciones de BAM.
Vale la pena observar cómo evolucionarán las dinámicas competitivas de la construcción de bloques en los próximos meses y lo que esto significa para la estructura de mercado de Solana.
