Las preconfirmaciones de Solana se han convertido en la señal más temprana para anticipar si una transacción acabará en la red. Según la guía publicada por Helius, el proveedor de infraestructura RPC —la capa que conecta aplicaciones con la red—, ese aviso se emite cuando el líder ejecuta la transacción, antes de que el bloque salga de su máquina. La ventaja temporal, de 5 a 50 milisegundos frente a los fragmentos llamados shreds, explica por qué los sistemas de latencia sensible miran ya esta capa.
Para entender de dónde sale la señal, conviene seguir la vida de una transacción dentro del líder: el validador encargado de producir el bloque en cada slot, el turno de producción. Antes de llegar a él, una transacción firmada viaja por el protocolo QUIC y compite con miles de candidatas. El acceso se asigna según el stake delegado —el SOL usado para respaldar validadores—, lo que en Solana se conoce como stake-weight.
La primera criba, llamada SigVerify, valida firmas y descarta duplicados, y paquetes mal formados. Superar esta fase no garantiza nada: la transacción sigue siendo una entre miles de «quizás». El planificador central de Agave, el cliente validador principal de Solana, incorporado desde la versión 1.18, es quien prioriza, comprueba conflictos de cuentas y envía lotes a los hilos de ejecución.
La arquitectura de Firedancer, el segundo cliente validador de la red, llega al mismo punto por otro camino. En lugar de hilos compartidos, usa piezas aisladas llamadas tiles que se comunican por colas de memoria compartida. Su pack tile selecciona las transacciones y las entrega a los bank tiles para ejecutarlas.
El instante clave es la ejecución. El worker de Agave o el bank tile de Firedancer ejecuta el lote contra el estado actual, carga cuentas, corre programas y confirma si la transacción tuvo éxito o falló. Ese resultado solo existe en la máquina del líder, y es justo ahí donde se emite la preconfirmación, también llamada preconf. Helius subraya que no es una predicción: es el resultado local ya calculado.
Cómo encaja en la escalera de latencia de Solana
Después de la ejecución, el resultado se graba en una entrada del Proof of History —el reloj criptográfico que ordena las transacciones—, se corta en shreds y se difunde por Turbine, el sistema de propagación de bloques de la red. Cualquier observador que reconstruya transacciones desde shreds llega rápido, pero ya va por detrás de la preconfirmación. La guía sitúa la ventaja entre 5 y 50 milisegundos.
El líder ejecuta y comunica el resultado antes de que la red sepa nada. Eso convierte a las preconfirmaciones en una ventaja competitiva, no en una promesa absoluta.
Esa ventaja no implica certeza. Helius repite que una preconfirmación solo dice que el líder ha ejecutado la transacción con un resultado concreto. El bloque aún no ha sido fragmentado ni votado, por lo que podría descartarse en un fork. Además, la cobertura es parcial: depende de qué líderes reenvían su flujo de transacciones a Helius.
Para sistemas de liquidación o bots de arbitraje, esa diferencia es valiosa. No necesitan una promesa infalible; necesitan saber el resultado unos milisegundos antes que el resto. La guía también aclara que no se está filtrando orden pendiente: la emisión ocurre después de ejecutar, así que la ventana para adelantarse a la propia transacción ya se cerró.
Una señal, no una garantía: el análisis de Merca2
La aparición de preconfirmaciones responde a una lógica de mercado que ya vimos con los flujos de shreds. Solana siempre ha separado a quienes se conforman con el nivel processed de los RPC de quienes reconstruyen datos en bruto. Ahora el movimiento se desplaza un peldaño más arriba: desde el primer artefacto público del bloque hasta el resultado que solo existe dentro del líder. Eso reduce la latencia en milisegundos, pero también reduce la certidumbre.
Lo importante es no confundir el aviso con la confirmación en cadena. Un validador puede ejecutar, pero la red solo da por válido el bloque tras las votaciones. Si un líder no propaga su flujo, la señal no existe; Helius recomienda combinar las preconfirmaciones con flujos de shreds o LaserStream para verificar. En el próximo salto técnico de Solana, la actualización Alpenglow eliminará Proof of History, aunque el modelo de preconfirmaciones seguirá funcionando porque nace de la ejecución, no del reloj.
Para los desarrolladores, la decisión no es elegir una única señal, sino orquestar varias. Las preconfirmaciones sirven para reaccionar; las confirmaciones en cadena, para asentar la operación.
