¿Qué son las Preconfirmations (Preconfs) en Solana?

El ciclo de vida de una transacción dentro del líder

A continuación presentamos un recorrido deliberadamente específico por el ciclo de vida de una transacción dentro del líder, en lo que respecta a las Preconfirmations y la observabilidad. Para ver un recorrido completo por el ciclo de vida de una transacción en Solana, consulta nuestro resumen técnico de Solana Virtual Machine (SVM).

Antes del líder

En Solana, las transacciones firmadas se envían directamente al productor del bloque (es decir, el líder) y a los próximos líderes. Llegan mediante QUIC, con una capacidad de conexión asignada según la ponderación por stake. Por eso, es mucho más probable que las transacciones retransmitidas mediante conexiones con stake sean aceptadas cuando hay mucha carga.

En este punto, una transacción solo es visible para el remitente y para el nodo RPC o servicio de inclusión de transacciones que la retransmite a los líderes actuales y próximos. 

En esta etapa, no se puede saber nada sobre el destino de la transacción. 

Etapa 1: Ingesta y SigVerify

La Unidad de Procesamiento de Transacciones (TPU) del líder recibe las transacciones entrantes como paquetes, las deserializa, verifica sus firmas y descarta los duplicados. Cuando hay mucha carga, los paquetes malformados y las transacciones de spam se descartan antes de consumir más recursos.

Una transacción que se ingiere y supera la verificación de firma en la etapa SigVerify es apenas una candidata. Miles de transacciones candidatas llegan por slot y muchas nunca entran en un bloque.

No existe observabilidad útil en esta etapa porque transmitir estas transacciones equivaldría a transmitir ruido. 

Etapa 2: El planificador

La producción de bloques ocurre en la etapa Banking y, desde Agave 1.18, su núcleo es el planificador central: un único hilo de planificación con una vista global de todas las transacciones pendientes, que distribuye el trabajo entre un grupo de workers de ejecución. La idea es que un solo hilo con todo el contexto empaqueta bloques con muchos menos conflictos de bloqueo que n hilos compitiendo agresivamente por una cola compartida.

En esencia, el planificador procesa las transacciones en tres pasos principales:

1. Almacenamiento en búfer y priorización

Las transacciones entrantes llegan al componente recepción y búfer del planificador, donde se calculan la prioridad y el costo de cada transacción y se insertan en un contenedor ordenado por prioridad.

En este momento, una transacción sigue siendo una de miles de “posibilidades” que podrían expulsarse si el búfer se llena con trabajo de mayor prioridad.

2. Planificación 

El ciclo de control del controlador del planificador extrae repetidamente del contenedor las transacciones de mayor prioridad, comprueba si hay conflictos de bloqueo de cuentas y las agrupa en lotes para ejecutarlas.

Desde Agave 2.3, el algoritmo de planificación incluido es el planificador voraz, que reemplaza el diseño anterior basado en grafos de prioridad después de que las pruebas mostraran que el enfoque voraz empaquetaba bloques con menos sobrecarga.

3. Distribución 

El lote programado se envía por un canal a un worker de ejecución. El líder ya ha asignado recursos reales —un hilo de worker, bloqueos de cuentas y un lugar en el bloque que se está ensamblando— a esta transacción específica.

En este punto, la transacción sigue pendiente. El líder tiene la intención de ejecutarla, pero todavía no se ha ejecutado nada, por lo que no hay resultados que informar. Las Preconfirmations llegan un paso después.

¿En qué se diferencia la arquitectura del planificador de Firedancer de la de Agave?

Firedancer llega al mismo punto mediante una arquitectura ligeramente distinta. En lugar de hilos que comparten memoria, Firedancer ejecuta tiles aislados conectados mediante colas de memoria compartida, con su lógica de planificación ubicada en el pack tile. 

El pack tile mantiene todas las transacciones pendientes, lleva un registro de las cuentas que retiene cada bank tile y selecciona transacciones sin conflictos que maximizan las comisiones. Luego las agrupa en microbloques y las entrega a los bank tiles para su ejecución. 

Ocurre la misma transferencia: las transacciones seleccionadas pasan de la lógica de empaquetado a las unidades de ejecución, donde se determinan sus resultados.

Etapa 3: Ejecución

Los workers de Agave o los bank tiles de Firedancer ejecutan el lote programado de transacciones en el banco actual, cargan las cuentas, ejecutan los programas y confirman sus resultados.

Aquí también puede fallar una transacción programada por distintos motivos, como fondos insuficientes, un error de programa, una comprobación de deslizamiento que revierte la operación u otras condiciones de ejecución. En cualquier caso, el resultado ahora solo existe localmente, en la máquina del líder.

Este es el momento en que se emite una preconfirmation. Un líder transmite cada transacción en el instante en que se ejecuta, junto con su estado, antes de registrar los resultados en una entrada y mucho antes de que los datos del bloque salgan de la máquina.

Este es el primer momento de todo el ciclo de vida en el que el resultado de una transacción existe y puede informarse. Antes de la ejecución, solo hay un conjunto de candidatas pendientes sin resultados que transmitir. Después, la información ya se está empaquetando en el bloque que avanza hacia el resto de la red.

Por lo tanto, la ejecución es el único punto donde puede existir una señal temprana de este tipo. Por eso, cada preconfirmation incluye el resultado real de la transacción en lugar de una predicción.

Sin embargo, una preconfirmation no puede indicar si el bloque que contiene la transacción se volverá canónico. Ese bloque aún no se ha dividido en shreds, propagado ni sometido a votación. 

Por este motivo, las Preconfirmations son una señal, no una garantía.

Etapa 4: Proof of History y entradas

Los lotes ejecutados se registran en el stream de Proof of History para producir entradas, que son conjuntos de transacciones con hash integrados en el reloj verificable del líder. Las entradas son el formato nativo del ledger, pero en este punto solo existen en la máquina del líder.

Para cualquier persona fuera del líder, la observabilidad es prácticamente nula.

Ten en cuenta que Proof of History se eliminará con la actualización Alpenglow, ya que Rotor y Votor eliminan la necesidad de un reloj descentralizado en Solana. El modelo de Preconfirmations no se ve afectado: los líderes seguirán ejecutando transacciones antes de difundirlas, por lo que la primera señal observable seguirá siendo el resultado de la ejecución local del líder. 

Etapa 5: División en shreds y transmisión

Las entradas se dividen en shreds, es decir, fragmentos del tamaño de una MTU que usan códigos de borrado para tolerar pérdidas. Estos shreds se firman y transmiten mediante el árbol ponderado por stake de Turbine.

Aquí se abren las compuertas de la observabilidad. Los shreds son el primer elemento de un bloque determinado que sale de la máquina del líder. Por eso, todos los demás productos de datos tempranos de Solana, incluidos los streams de shreds, comienzan aquí. Quienes reconstruyen transacciones a partir de shreds son rápidos en comparación con los niveles de compromiso de RPC, pero llegan tarde frente a una preconfirmation, ya que el líder ejecutó la transacción antes de que existieran los shreds. 

A partir de aquí, los validadores reproducen el bloque, votan y las transacciones avanzan por los niveles de compromiso processed, confirmed y finalized. 

¿Dónde se ubican las Preconfirmations en la escala de latencia?

Las Preconfirmations son la señal más rápida de Solana frente a todas las demás, incluidos los shreds sin procesar y decodificados, LaserStream y otros métodos de transmisión de datos. 

Sin embargo, las preconfs se entienden mejor como un peldaño en una escala de latencia, donde cada peldaño sacrifica cierto grado de integridad o certeza para ofrecer una observación más temprana.

De la más temprana a la más tardía:

De esta tabla se desprenden dos observaciones. 

Primero, todas estas señales se complementan en lugar de sustituirse directamente entre sí.

Por ejemplo, las Preconfirmations informan lo que un líder acaba de ejecutar antes de que la red lo sepa, mientras que un mensaje de LaserStream indica lo ocurrido con todos sus metadatos.

Los sistemas de producción suelen necesitar ambos: actúan según las Preconfirmations y usan señales posteriores para verificar los resultados.  

Segundo, la distancia entre los peldaños no es uniforme.

El paso de los streams procesados a los shreds ahorra milisegundos de un solo dígito, mientras que el paso de los shreds a las Preconfirmations omite el resto del flujo de producción del bloque (es decir, el registro de entradas, la división en shreds y la propagación). Esto ocurre porque el punto de observación pasa del primer elemento público del bloque a resultados que solo existen dentro del líder. 

Como resultado, las Preconfirmations son entre 5 y 50 milisegundos más rápidas que los shreds. 

El modelo de confianza de Preconfirmations: señal, no garantía

Todo lo que promete una preconfirmation puede resumirse en una sola oración: el líder ejecutó esta transacción con este resultado. Todo lo que una preconf no promete se desprende de esa misma oración.

Una transacción ejecutada todavía no es una transacción incluida, lo que significa que el bloque que la contiene aún no se ha dividido en shreds, propagado ni sometido a votación. Todavía es posible que este bloque se omita o se excluya de la bifurcación antes de que la red lo confirme. Casi todas las transacciones preconfirmadas se incluyen correctamente onchain. Sin embargo, cualquier sistema que actúe según las Preconfirmations debe confirmar los resultados mediante otras comprobaciones de observabilidad antes de considerarlos definitivos.

La cobertura también es parcial por diseño. Las Preconfirmations solo existen para los slots cuyo líder reenvía a Helius su stream de transacciones programadas. Por lo tanto, la cobertura aumenta según la proporción del stake de la red que participa, y el stream no es necesariamente continuo.

Si los servicios necesitan cobertura continua como garantía absoluta, deben considerar usar LaserStream o Shred Delivery como alternativa cuando ocurran interrupciones.

Como las Preconfirmations se emiten después de la ejecución, un suscriptor ve resultados ya decididos, no un flujo de órdenes pendiente que pueda explotarse. Esto significa que la oportunidad de adelantarse a esa transacción dentro del bloque ya se cerró. Esta es la diferencia fundamental entre vender visibilidad temprana y filtrar el flujo de órdenes previo a la planificación: lo primero permite que los suscriptores reaccionen más rápido que el resto de la red; lo segundo les permitiría actuar contra las mismas transacciones que se transmiten. Las Preconfirmations corresponden estrictamente al primer caso.

La señal es transparente sobre lo que representa: no existe un compromiso económico que respalde una preconfirmation ni se afirma lo contrario. El líder informa sus resultados locales, pero no pone nada en stake para garantizar que se completen. Para las estrategias que usan Preconfirmations, este es el equilibrio correcto.

Por ejemplo, un bot de liquidación no necesita una promesa infalible y sujeta a slashing de que una transacción se incluirá. Necesita conocer el resultado de una transacción determinada milisegundos antes que sus competidores.

¿Cómo funcionan Helius Preconfirmations?

Helius Preconfirmations se entregan mediante una única suscripción de WebSocket. Un cliente puede conectarse a nuestro endpoint de Gatekeeper (es decir, wss://beta.helius-rpc.com) y enviar una solicitud preconfSubscribe:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Los filtros se aplican en el servidor por cuenta (es decir, incluidas, excluidas y obligatorias), región y estado, con compatibilidad para tablas de consulta (LUT). Así, el suscriptor solo recibe y paga por las transacciones programadas relevantes para su estrategia. 

Como las Preconfirmations se emiten después de la ejecución, el filtro de estado opera sobre resultados reales: failed: false, lo que significa que las transacciones fallidas nunca se transmiten ni se facturan.

El precio se basa en créditos, como en las demás suscripciones de WebSocket de Helius: 10 créditos por mensaje y un mensaje por transacción transmitida. Está disponible en los planes Professional y superiores. 

A partir de ahí, cada transacción programada que coincide con los filtros llega como un frame binario compacto. Es decir, un encabezado fijo de 18 bytes que contiene la versión de la transacción, el slot en el que está programada, el índice de la transacción dentro del slot y su estado, seguido de los bytes completos de la transacción. 

El formato es deliberadamente austero porque un encabezado fijo puede decodificarse en nanosegundos sin analizar JSON en la ruta crítica. El único JSON que necesitamos en este intercambio es la confirmación de la suscripción, por comodidad. 

Ten en cuenta que una preconfirmation solo representa la mitad de una operación. Ver una transacción primero solo importa si la respuesta también se incluye primero. Por eso también lanzamos Sender Max, el nivel de Helius Sender con el mayor rendimiento.

Sender Max dirige un envío (es decir, una sola transacción o un bundle atómico de hasta cuatro transacciones) por todas las rutas de alta velocidad disponibles y lo introduce en un búfer de propinas prioritarias que favorece las propinas más altas. La propina mínima es de 0.001 SOL.

Obtén señales con preconfSubscribe e incluye transacciones con Sender Max.  

¿Qué puedes crear con Preconfirmations?

Cualquier estrategia cuyas ganancias disminuyan con cada milisegundo que pasa entre la decisión y la observación de una transacción se beneficia de las preconfs. Esto incluye, entre otros, los siguientes casos de uso: 

Sniping

Las creaciones de nuevos pools y los lanzamientos de tokens son visibles en el instante en que la transacción de despliegue se ejecuta dentro del líder. Un sniper que consume Preconfirmations reacciona mientras quienes monitorean shreds todavía esperan a que lleguen los primeros fragmentos del bloque. 

Copy trading

Los movimientos de una wallet objetivo aparecen en el stream de Preconfirmations en cuanto el líder los ejecuta. Filtrar por la dirección de un objetivo con accountInclude convierte el stream en una fuente espejo especializada que permite detectar movimientos antes que otros copy traders.

Liquidaciones

Una actualización de oráculo que deja una posición con pérdidas puede conocerse en cuanto se ejecuta. El bot de liquidación que la detecta ahí activa todo un flujo antes que otro que observa shreds o un compromiso processed. Esto hace que las Preconfirmations sean extremadamente importantes para las actividades de liquidación.

Creación de mercado y propAMMs

El flujo entrante visible al momento de la ejecución permite a los propAMMs y otros sistemas de cotización adelantarse para ajustar precios o retirar cotizaciones obsoletas antes de que el flujo se haga público. 

En todos los casos, las Preconfirmations mueven el punto de reacción de la estrategia de “después de que la red se entera” a “en el momento en que el líder ejecuta”.

Genera ingresos al reenviar Preconfirmations

La cobertura de Preconfirmations es un efecto de red, con los validadores del lado de la oferta. Cualquier validador puede reenviar su stream a Helius y generar ingresos por hacerlo. Así convierte un subproducto de la producción de bloques en una fuente de ingresos, independientemente de si monetiza su posición de otra manera.

Cuanto mayor sea el stake participante, más amplia será la cobertura. Los validadores interesados en participar pueden contactarnos y encontrar más información en nuestra documentación de Preconfirmations para validadores. 

¿Cuál es la diferencia entre las preconfs de Ethereum y las preconfs de Solana?

Las Preconfirmations de Ethereum son compromisos de los proponentes que garantizan que una transacción se incluirá en un bloque futuro, mientras que las Preconfirmations de Solana son señales de transacciones onchain en tiempo real para transacciones que el líder acaba de ejecutar localmente en el bloque actual. Las primeras permiten saber antes; las segundas, ver antes.

Preconfirmations de Ethereum

En Ethereum, las Preconfirmations —a menudo denominadas based preconfs en la literatura de investigación, un diseño presentado por primera vez por Justin Drake en 2023— son compromisos de inclusión. Un proponente promete, antes de su slot, que una transacción se incluirá en un bloque futuro. Esa promesa está respaldada por un mecanismo económico como el slashing. 

Existen varias implementaciones activas: 

• MEV-Commit de Primev, un mercado donde wallets, searchers y protocolos de intención ofrecen pagos a proveedores de ejecución (es decir, constructores de bloques y secuenciadores) por compromisos
• ETHGas, una red de Preconfirmations con respaldo económico
• Bolt de Chainbound, que ofrece compromisos de proponentes sin permisos y compatibles con MEV-Boost

Lo más importante es que las Preconfirmations de Ethereum:

• Se refieren a tu propia transacción
• Se emiten antes de la ejecución
• Están optimizadas para la certeza

Las Preconfirmations de Ethereum garantizan que tu transacción se incluirá antes de que realmente ocurra.

Ethereum necesita este mecanismo por la forma en que construye sus bloques. La mayoría de los proponentes subastan la construcción del bloque justo a tiempo mediante MEV-Boost, por lo que no se puede prometer nada sobre un bloque de forma creíble hasta que concluya la subasta. Sin embargo, Solana nunca tuvo esa brecha. El calendario de líderes se conoce de antemano, no hay mempool y un solo líder recibe, ordena, ejecuta y transmite su bloque continuamente dentro del slot. La señal temprana que Ethereum debe fabricar con una estructura económica existe de forma nativa en el flujo de producción de bloques de Solana; solo era necesario exponerla.

Preconfirmations de Solana

Las Preconfirmations de Solana son señales onchain en tiempo real, no una promesa futura: el líder informa las transacciones que ya ejecutó antes de que se propaguen al resto de la red.

Lo más importante es que las Preconfirmations de Solana:

• Incluyen las transacciones de todos
• Se emiten después de la ejecución
• Están optimizadas para la latencia

Las Preconfirmations de Solana te permiten ver las transacciones ejecutadas milisegundos antes de que se observen en toda la red mediante shreds o solicitudes RPC con niveles de compromiso estándar.

El equivalente más cercano en Solana a las Preconfirmations de Ethereum para reservar espacio en bloques es el mercado de unidades de cómputo de Raiku para transacciones Ahead-of-Time (AOT), que permite a las aplicaciones reservar una inclusión garantizada en bloques futuros.

Conclusión

Cada transacción en Solana pasa por un único momento en el que su destino cambia de desconocido a decidido: el instante en que el líder la ejecuta. Las Preconfirmations transmiten ese momento antes de que el resto de la red pueda verlo. Están por encima de los shreds en la escala de latencia porque observan los resultados de ejecución del líder, no los elementos públicos del bloque. Las Preconfirmations son una señal, no una garantía, porque un bloque no se considera canónico hasta que la red lo confirma.

Para sistemas sensibles a la latencia —snipers, copy traders, bots de liquidación, creadores de mercado y searchers—, suscríbete con preconfSubscribe, filtra las cuentas relevantes, responde a las señales con Sender Max y verifica los resultados mediante comprobaciones de compromiso estándar.

La referencia completa de la suscripción, el formato de los mensajes y los ejemplos de integración están disponibles en nuestra documentación de Preconfirmations.