Esto es increíble. He explorado varios creadores de bloques diferentes: Agave, Firedancer, BAM y Harmonic. Los cuatro muestran diferentes lógicas de programación. También tenemos a Paladin y Rakurai, cada uno con sus propias versiones. Desde una perspectiva de microestructura del mercado, en TradFi, tienes un sistema no restringido: los pedidos llegan continuamente y se ejecutan FIFO por un único motor de emparejamiento. Esta continuidad es lo que permite a los creadores de mercado cancelar cotizaciones sin arriesgarse constantemente a ser eliminados. No se necesitan tarifas de prioridad, y los creadores pueden cotizar diferenciales de menos de 1 pb en operaciones individuales por valor de millones de dólares. A primera vista, Solana parece estar restringida por tiempos de slot de ~380 ms. Eso es cierto, pero hasta cierto punto. Gracias a Turbine, los validadores descomponen las transacciones cada ~15–20 ms y propagan estos fragmentos a través de la red. Una vez que se produce un fragmento, el orden dentro de ese lote es fijo. Con la utilización actual de bloques muy por debajo de los límites de CU, Solana se comporta mucho más como un sistema FIFO por lotes de lo que sugeriría la longitud del slot. Sin embargo, el desmenuzamiento es solo parte de la imagen. La otra gran restricción es el diseño del programador. Diferentes creadores de bloques implementan lógicas de programación significativamente diferentes: cómo se entrelazan los votos y los no votos, cuándo se incluyen las transacciones no votadas dentro del slot y cómo se agrupan las transacciones económicamente relacionadas. Para los AMMs prop, esto introduce incertidumbre. Incluso cuando los bloques están medio vacíos y no se eliminan transacciones debido a tarifas de prioridad bajas, el orden aún varía de slot a slot dependiendo del creador. Los AMMs prop necesitan actualizaciones de cotización y transacciones de tomador ordenadas de manera predecible dentro de un fragmento. Con programadores heterogéneos, ese orden es no determinista entre slots, lo que dificulta razonar sobre las garantías de ejecución. Se podría imaginar mitigar esto con prioridad para creadores o topes de velocidad para el flujo de tomadores. Pero si el objetivo es ICM en Solana, este problema necesita una solución más sistémica. Darse cuenta de que hay un problema es el primer paso para resolverlo, así que el explorador IRBL es un recurso muy valioso.