Solana acaba de ganar una nueva capa de observabilidad: las preconfirmaciones, también llamadas preconfs, la señal más temprana de que una transacción va a entrar en un bloque. Helius, uno de los proveedores de infraestructura RPC más utilizados del ecosistema —esos nodos que conectan carteras y aplicaciones con la red—, ha detallado cómo los desarrolladores pueden suscribirse a esa señal y recibir el resultado de una transacción entre 5 y 50 milisegundos antes que con los flujos de shreds, los fragmentos en los que Solana divide cada bloque.
Qué es una preconfirmación y de dónde sale
En Solana, cada bloque lo produce un líder rotatorio. Ese validador ejecuta las transacciones antes de empaquetarlas y difundirlas. La preconfirmación nace justo ahí, en la máquina del líder, cuando la ejecución ya tiene un resultado local pero el bloque todavía no ha salido de su máquina. No es una predicción: incluye el estado real de la transacción, con su éxito o su fallo.
Para entender por qué no existe una señal anterior conviene seguir el recorrido dentro del líder. Primero, la transacción llega vía QUIC y pasa por la verificación de firmas; en ese punto es solo una candidata entre miles. Después, el planificador central —el scheduler— la ordena junto a otras operaciones sin conflictos. En Agave, el cliente validador de referencia de Solana, el algoritmo greedy scheduler se encarga de empaquetar los bloques con menos bloqueos. Solo cuando un hilo de ejecución o un bank tile de Firedancer, el cliente validador alternativo, ejecuta la transacción aparece un resultado que pueda transmitirse.
Ese instante es la preconfirmación. Todo lo anterior es ruido: candidatas en cola. Todo lo posterior, como el registro en Proof of History, el reloj criptográfico de Solana, el troceado en shreds y la difusión por Turbine, el protocolo de propagación de Solana, llega después de que el líder ya conoce el desenlace. Por eso Helius puede ofrecer una ventana de 5 a 50 milisegundos de ventaja frente a los flujos de fragmentos.
La escalera de latencia en Solana
La preconfirmación no sustituye a los demás flujos de datos, sino que se suma a una escalera de latencia. Los sistemas que hoy consumen shreds ya se adelantan a los niveles RPC; las preconfs se sitúan un peldaño por encima porque se emiten antes de que el bloque se fragmente. Para un bot de liquidaciones, por ejemplo, no hace falta una garantía absoluta de que la transacción será canónica: basta con conocer el resultado unos milisegundos antes que el resto.
La preconfirmación no promete que el bloque será definitivo: dice que un líder ya ejecutó esa transacción y que este fue su resultado.
Señal, no garantía: el matiz que separa una ventaja de una promesa
Helius es transparente con el modelo de confianza. La cobertura depende de qué validadores deciden compartir su flujo de preconfirmaciones y, por tanto, no es continua por diseño. Además, un bloque ejecutado todavía puede ser descartado o bifurcado antes del consenso; por eso la preconfirmación es una señal, no una certeza. El sistema que actúe sobre ella debe verificar después el resultado mediante otro flujo.
Esa distinción importa. Vender visibilidad temprana no es lo mismo que filtrar la cola de órdenes pendientes. Como la preconfirmación se emite después de la ejecución, la ventana para adelantarse a esa transacción dentro del bloque ya está cerrada. El suscriptor reacciona más rápido, pero no puede manipular la operación que está observando.
En la práctica, Helius expone esta señal a través de una suscripción WebSocket, una conexión persistente en tiempo real, en su endpoint Gatekeeper. Un cliente envía una petición preconfSubscribe con filtros de estado y región; a partir de ahí recibe el resultado de cada transacción ejecutada en los líderes cubiertos. Es un producto pensado para infraestructura de trading, bots y aplicaciones sensibles a la latencia, no para el usuario que consulta su wallet una vez al día.
El lanzamiento refuerza una tesis que ya venía del propio diseño de Solana: la velocidad no depende solo de más transacciones por segundo, sino de cómo y cuándo se observa el estado de la red. La llegada de Firedancer no cambia el modelo; su arquitectura de tiles aislados también emite el resultado local antes de difundir el bloque. De cara a la actualización Alpenglow, que retirará Proof of History, la lógica se mantiene: el líder seguirá ejecutando primero y propagando después. Conviene, eso sí, no confundir preconfirmación con finalidad: el consenso de los validadores sigue decidiendo qué bloque es canónico.
