Hay una señal en Solana que viaja más rápido que cualquier RPC: las preconfirmaciones. Helius, el proveedor de infraestructura que usan miles de aplicaciones para conectarse a la red, acaba de explicar cómo funcionan y por qué marcan la nueva frontera de la latencia. Un RPC es, en la práctica, el punto de contacto que monederos y bots utilizan para enviar transacciones y leer datos; las preconfirmaciones aparecen antes incluso de que esos datos salgan del validador que propone el bloque.
Qué es una preconfirmación y en qué punto nace
Dentro de Solana, cada bloque lo construye un validador conocido como líder durante un intervalo de unos 400 milisegundos llamado slot. Las transacciones pasan tres fases: verificación de firma, programación y ejecución. La preconfirmación se emite justo al terminar la ejecución, cuando el líder ya sabe si la transacción ha funcionado o ha fallado, pero todavía no ha empaquetado el resultado ni lo ha difundido. Es el primer instante con resultado observable: antes solo hay una cola de candidatos sin desenlace.
Ese timing convierte a las preconfirmaciones en la señal más temprana del ecosistema. Helius estima que llegan entre 5 y 50 milisegundos antes que los shreds, los fragmentos en los que se trocea un bloque para transmitirlo por el protocolo Turbine. Para un lector medio: hablamos de milisegundos, no de segundos, pero en mercados donde un bot de liquidaciones compite contra cientos de rivales, esa ventaja equivale a ejecutar antes que el resto.
La fuente es el blog técnico de Helius, que detalla el ciclo de vida de una transacción dentro del líder. No se trata de una predicción: cada preconfirmación incluye el estado real de la transacción, con su éxito o su error. Eso sí, no dice nada sobre si el bloque que la contiene acabará siendo canónico; ese bloque aún no se ha propagado ni votado por el resto de validadores.
No es un oráculo.
La escalera de latencia, peldaño a peldaño
Para entender por qué esto importa, conviene visualizar una escalera. En el peldaño más lento están los niveles que ofrecen los RPC: processed, confirmed y finalized. Cuanto mayor es el nivel, más garantía de irreversibilidad, pero más tarda. Por debajo, más rápido, están los flujos de shreds, que reconstruyen transacciones a partir de fragmentos. Las preconfirmaciones eliminan un paso adicional: observan el resultado dentro del líder, antes de que el bloque sea la primera pieza pública. La mejora frente a los shreds es de una decena de milisegundos de media, aunque varía según la carga.
La latencia no la gana el más rápido en ver, sino el que confirma antes de actuar.
Helius aclara que estas señales no se sustituyen entre sí. Los sistemas de producción serios consumen preconfirmaciones para actuar rápido y, después, verifican con el flujo de shreds o con un RPC convencional. Es el mismo principio que un radar y un sistema de control: el primero avisa, el segundo confirma. En la práctica, un bot de arbitraje puede disparar una orden al ver la preconfirmación y, milisegundos después, comprobar que todo sigue en orden.
Aquí está el matiz que separa una herramienta seria de un espejismo. La preconfirmación solo promete una cosa: que el líder ha ejecutado una transacción con un resultado concreto. No promete que ese bloque vaya a ser confirmado por el resto de la red. En el camino, un bloque puede quedarse fuera del consenso o ser adelantado por otro. Helius lo resume así: es una señal, no una garantía. Casi todas las transacciones preconfirmadas acaban en la cadena, pero actuar sobre ellas exige confirmar el desenlace con otras fuentes antes de darlo por cerrado.
El matiz importa.
La cobertura tampoco es total. Solo existen preconfirmaciones para los slots cuyo líder reenvía su flujo de transacciones a Helius, de modo que la cobertura crece con la participación de validadores. Si un sistema necesita continuidad absoluta, la recomendación del proveedor es combinar preconfirmaciones con su flujo de shreds o LaserStream. Dicho de otro modo, es una pieza de latencia extrema, no un interruptor que se enciende y se olvida.
El análisis: una señal temprana, no una promesa de inclusión
Conviene situar esta mejora en la historia reciente de Solana. Durante años, el reto no fue solo el throughput o transacciones por segundo, sino predecir con rapidez qué iba a pasar dentro del bloque. Tras el programador central de Agave 1.18 y el greedy scheduler de Agave 2.3, la producción se volvió más eficiente; ahora el foco se traslada a la observabilidad. Firedancer, el segundo cliente validador de Jump Crypto, usa piezas aisladas y llega al mismo punto: la ejecución local es el primer resultado observable. Por eso el modelo no depende de un solo proveedor.
El riesgo a vigilar es la interpretación. Una señal temprana no es un compromiso económico: el líder no deposita nada ni puede ser penalizado si el bloque se descarta. Para estrategias como liquidaciones o arbitraje, ese intercambio es correcto. Para sistemas de pago o liquidación final, no basta. La pregunta que deja abierta Helius es cuántos validadores acabarán emitiendo preconfirmaciones y si el estándar se integrará en los clientes principales. Ese es el siguiente peldaño por construir, y de su adopción dependerá que la latencia de Solana se mida en milisegundos para todos o solo para unos pocos.
Ese peldaño aún no existe.
