Durante la mayor parte de su historia, Solana con una sola implementación de validador. Eso la hacía rápida, pero también frágil, ya que un solo error de software podía paralizar toda la cadena.

Firedancer eso. Proporciona Solana segundo cliente totalmente independiente, con código propio, un lenguaje diferente y su propio equipo: el modelo de seguridad multicliente que Ethereum un estándar de referencia.

A continuación te explicamos cómo Firedancer desarrollado Firedancer , cuál es su situación tras el lanzamiento y qué implica esto para la fiabilidad y la hoja de ruta Solana. 👇

¿Qué es Firedancer?

Firedancer es un cliente validador para Solana por Jump Crypto, la división de blockchain de la empresa de negociación Jump Trading Group. Un cliente validador es el software que procesa las transacciones, genera bloques y vota en el consenso, por lo que el cliente que ejecuta un nodo determina el rendimiento de la red.

Jump inició el proyecto en 2022 y tomó una decisión deliberada. En lugar de crear una bifurcación del software Solana, basado en Rust, reescribió el validador desde cero en C y C++, lenguajes que permiten un control preciso de la memoria y el hardware. El nuevo cliente no comparte código alguno con el actual, y ese es precisamente el objetivo.

El cliente predeterminado Solana es Agave, cuyo mantenimiento corre a cargo de Anza, un equipo surgido de Solana . La variante más utilizada es la bifurcación de Agave MEVJito. Firedancer de ambos por ser una versión totalmente independiente, junto con clientes más pequeños como Sig, Mithril y Tinydancer.

A pesar de la confusión habitual, Firedancer no Firedancer un token, airdrop ni un cambio en el protocolo. No afecta a SOL , a staking ni a las reglas de transacción. Modifica el funcionamiento de los validadores, sin alterar el funcionamiento de la red.

¿Cómo funciona Firedancer ?

Firedancer el validador como un conjunto de componentes especializados e independientes, en lugar de un único programa de gran tamaño, y elimina así la sobrecarga del sistema operativo que limita el rendimiento a gran escala.

1. Arquitectura basada en módulos

Firedancer el trabajo de los validadores en procesos independientes denominados «tiles», cada uno de los cuales se encarga de una tarea concreta, como las comunicaciones de red, la verificación de firmas, el empaquetado de transacciones o la generación de bloques. Cada «tile» está asignado a un núcleo de CPU específico y se comunica con los demás a través de canales de memoria compartida.

Agave se ejecuta como un único proceso monolítico en el que las funciones de red, ejecución y consenso comparten memoria. La arquitectura dividida Firedancer aprovecha al máximo el hardware multinúcleo mediante el paralelismo y limita los fallos, ya que un error en un solo bloque rara vez provoca la caída de todo el validador. La distribución de memoria adaptada a NUMA y las estructuras de datos sin bloqueos evitan que los núcleos compitan por los mismos recursos.

2. Redes sin pasar por el núcleo

Cada paquete que gestiona un validador estándar recorre varias veces la pila de red del núcleo de Linux, que se satura bajo una carga elevada. Firedancer la mayor parte de ese recorrido gracias a AF_XDP y eBPF, leyendo los paquetes cerca de la tarjeta de red, de modo que el límite lo marca el hardware, y no el software que lo gestiona.

Por encima de eso se encuentra una versión personalizada de QUIC llamada «fd_quic» y una función de escalado en el lado receptor que distribuye el tráfico entre los núcleos. Según la Firedancer , los módulos de red nunca entran en modo de espera, sino que realizan sondeos continuos para mantener una latencia constante. El inconveniente es que esto requiere acceso de root durante la configuración y un hardware de red específico.

3. Verificación acelerada de firmas

La verificación de firmas Ed25519 es una de las tareas más costosas para un validador a gran escala. Firedancer instrucciones vectoriales AVX-512 para verificar las firmas en lotes paralelos, en lugar de hacerlo una por una. Los ingenieros de Jump han medido que su rutina alcanza una velocidad aproximadamente 3,9 veces superior a la de la versión escalar estándar en el mismo chip.

4. Propagación de bloques

Firedancer optimiza Turbine, el mecanismo de propagación de bloques Solana, y su codificación de borrado, de modo que los datos se distribuyen de forma eficiente bajo carga. Junto con las mejoras en las redes y la criptografía, así es como el cliente alcanza un rendimiento muy superior al que ofrecía el software original.

Frankendancer contra Firedancer

Estos dos nombres se confunden constantemente, por lo que es importante conocer la diferencia. Frankendancer es un híbrido: integra el código de redes y de producción de bloques Firedancer en el tiempo de ejecución y el consenso de Agave, lo que permite a los validadores adoptar parte de la arquitectura sin tener que confiar en un código de consenso sin probar.

Frankendancer llegó a mainnet 2024 y ganó un gran impulso a lo largo de 2025. Dado que se basa en Agave para la ejecución y el consenso, su rendimiento está limitado por ese entorno de ejecución, y no resuelve por completo el problema del cliente único, ya que todos los nodos siguen dependiendo del consenso de Agave.

Full Firedancer esa dependencia. Implementa todo el proceso de validación, incluyendo el consenso y la ejecución, en un código fuente independiente escrito en C y C++. Esa versión es la que proporciona Solana auténtico segundo cliente y un dominio de fallos independiente de Agave.

Mainnet y la adopción de Mainnet

Jump Crypto anunció elmainnet completomainnet Firedancer el 12 de diciembre de 2025 en el evento Solana celebrado en Abu Dhabi. Para entonces, el cliente ya llevaba unos 100 días funcionando discretamente en producción con un pequeño grupo de validadores, habiendo generado más de 50 000 bloques sin incidencias. El equipo llevó a cabo primero una auditoría de seguridad pública respaldada por un programa de recompensas por errores dotado con un millón de dólares.

La implementación se ha llevado a cabo de forma deliberadamente gradual, en lugar de un cambio brusco. El ingeniero fundador Ritchie Patel declaró a CoinDesk en mayo de 2026 que el cliente había procesado decenas de millones de transacciones mientras la adopción se ampliaba con cautela.

En la primera mitad de 2026, la Firedancer se ejecutaba en aproximadamente el 20 % o más de los validadores activos, y el cliente completo poseía una cuota de SOL apostado de dos dígitos bajos. La bifurcación Agave Jito sigue teniendo la mayoría, por lo que aún faltan años para lograr una red multicliente equilibrada. SOL alrededor de un 6 % tras el lanzamiento, y el conjunto de validadores sat los 840 nodos, por debajo del máximo de más de 1300.

Por qué es importante la diversidad de clientes

El historial de interrupciones Solana explica el interés suscitado. El análisis de Helius sobre los tiempos de inactividad de la red atribuye cinco de las siete interrupciones importantes a errores de los validadores o de los clientes, y no al diseño del consenso. Cuando aproximadamente el 90 % de las participaciones utiliza un mismo software, un solo error de programación puede paralizar la producción de bloques, por muy rápida que parezca la cadena.

Ethereum esto desde el principio y considera la diversidad de clientes como una norma de seguridad, con el objetivo de que ningún cliente individual supere un tercio del poder de consenso. Un cliente que supere ese nivel puede retrasar la finalización; si supera los dos tercios, podría validar bloques erróneos. Solana una concentración mucho mayor, con cerca del 90 % en un solo cliente.

Firedancer las reglas del juego. Al no compartir código ni lenguaje con Agave, un error de memoria en el asignador de Rust de Agave no debería afectar al código C++ Firedancer, por lo que ambos pueden fallar de forma independiente. La red puede sobrevivir a un error catastrófico en cualquiera de ellos, siempre y cuando las participaciones estén distribuidas de tal manera que ningún cliente pueda desconectar a una mayoría cualificada de una sola vez.

Este es también el argumento institucional. Los equipos de gestión de riesgos quieren saber qué ocurre si algo falla, y el hecho de que haya dos clientes independientes les parece muy diferente. Con JPMorgan organizando una emisión de papel comercial en Solana State Street preparando un fondo de liquidez tokenizado para la red, la reducción del riesgo asociado a un único cliente responde a una de las principales objeciones a la creación de una financiación regulada en ese entorno.

Hoja de ruta SolanaFiredancer, Alpenglow y Solana

Firedancer una de las dos partes de una actualización más amplia, y la gente suele confundirlo con la otra parte. Alpenglow es un nuevo motor de consenso de Anza que sustituye a Proof of History y TowerBFT, y tiene como objetivo alcanzar la finalidad en unos 150 milisegundos. Firedancer un cliente; Alpenglow es un protocolo de consenso. Los validadores lo han aprobado y se encuentra en fase de pruebas antes de su mainnet , prevista para finales de 2026.

Los límites de computación también son importantes. Solana ido aumentando la capacidad de computación por bloque mediante propuestas como la SIMD-0256, que elevó el límite máximo por encima de los 60 millones de unidades, y se están debatiendo nuevos aumentos. Unos límites más altos suponen una mayor carga para el hardware de los validadores, precisamente la presión que la arquitectura Firedancer fue diseñada para absorber.

Ambos equipos también están planificando la seguridad poscuántica. En abril de 2026, Anza y el Firedancer se decidieron por separado por Falcon, un esquema de firma seleccionado por el NIST cuyas firmas compactas se adaptan a una red de alto rendimiento sin mermar el rendimiento.

Requisitos de Firedancer

Las primeras informaciones afirmaban que Firedancer la validación. Sin embargo, ocurrió todo lo contrario. Este sistema favorece a los equipos con un gran número de núcleos y a determinados dispositivos de red, y el aumento de los límites de computación Solana ha elevado el listón, en lugar de bajarlo.

Las previsiones de los operadores para 2026 apuntan a un perfil de producción similar:

• CPU: El mínimo exigido es un chip de 12 núcleos y 24 hilos a 2,8 GHz, pero los validadores de producción apuntan a más de 24 núcleos a 3,5 GHz o más. Predominan los procesadores AMD EPYC, como los modelos 9354 y 9355, en configuraciones de un solo zócalo para evitar la latencia entre zócalos.
• AVX-512: Imprescindible para la criptografía acelerada. Sin él, las ventajas en la verificación de firmas se pierden.
• RAM: Aproximadamente entre 384 GB y 512 GB de memoria ECC, una cifra muy superior a las previsiones anteriores, para bloques más grandes y el estado de la cuenta.
• Almacenamiento: unidades NVMe Gen4 o Gen5 de clase empresarial, con el sistema operativo en un disco independiente de ledger .
• Red: un enlace simétrico de 10 Gbps y una tarjeta de red compatible con XDP, elementos imprescindibles para que el diseño de omisión del núcleo funcione.
• Configuración: Desactiva la tecnología Hyper-Threading, aísla los núcleos del programador del núcleo y configura la afinidad de la CPU para que cada bloque tenga su propio núcleo. Considera todos estos requisitos como imprescindibles.

Firedancer una infraestructura de nivel profesional diseñada para hardware potente. No hace que la gestión de un nodo sea lighter más económica.

¿Por qué Jump Building es Firedancer?

La motivación de Jump tiene su origen en su actividad principal. Jump Trading Group ha dedicado dos décadas a desarrollar sistemas de baja latencia capaces de procesar enormes volúmenes de datos con un retraso mínimo, y Firedancer esa filosofía a un validador. Patel ha descrito el cliente como un auténtico motor de negociación, y el científico jefe Kevin Bowers dirigió las primeras demostraciones de rendimiento.

El objetivo declarado es la fiabilidad y el rendimiento de Solana, una red en la que Jump ha realizado una importante inversión. El dinero también forma parte de ello. Los validadores obtienen ingresos del valor máximo extraíble (MEV), es decir, el beneficio derivado de la ordenación de las transacciones dentro de los bloques, y MEV Solana es ahora un negocio en toda regla. Firedancer modifica directamente MEV , ya que esta se desarrolla principalmente en variantes como Jito, pero un cliente más rápido y estable refuerza la infraestructura en la que confían los operadores MEV.

Riesgos y cuestiones pendientes

Firedancer un gran logro de ingeniería, y su mainnet plantea tantas preguntas como respuestas ofrece. Ten esto en cuenta.

• Rendimiento en pruebas de rendimiento frente al rendimiento en producción: TPS más de un millón TPS procede de demostraciones controladas. mainnet real mainnet es mucho menor, del orden de miles, y las pruebas de rendimiento dicen poco sobre el comportamiento bajo cargas adversas o divisiones de red.
• Migración lenta: cambiar de cliente supone un esfuerzo considerable en cuanto a ajuste del hardware y operaciones, y Agave cuenta con años de mainnet Firedancer aún Firedancer igualar. Los operadores más prudentes esperarán, por lo que los cambios en las participaciones se producirán de forma gradual.
• El riesgo persistente de dependencia de un único cliente: mientras no se transfiera una parte suficiente de la participación a clientes independientes, un fallo en el software dominante basado en Agave podría seguir paralizando la cadena. La diversidad solo resulta útil cuando la distribución está verdaderamente equilibrada.
• Nuevo código base: una reescritura completa en C y C++ conlleva sus propios riesgos en materia de memoria y concurrencia, por lo que el lanzamiento se llevó a cabo tras una exhaustiva auditoría y un programa de recompensas. El escaso historial de funcionamiento en producción deja margen para sorpresas.
• Presión hacia la centralización: Las elevadas especificaciones de hardware benefician a los operadores profesionales y a los grandes centros de datos, y las normas de concentración de participaciones del Programa de Delegación Solana podrían hacer que la validación recaiga en un número menor de actores con mayor financiación.
• Sin inversión directa: no existe Firedancer , por lo que la exposición se canaliza a través de SOL, con la volatilidad habitual de las criptomonedas, independientemente de cualquier actualización concreta.

Consideraciones finales

Firedancer el rumbo del Solana . La red siempre se ha promocionado por su velocidad, y esa velocidad era real, pero sat un único punto de fallo de software que provocaba repetidas y vergonzosas interrupciones del servicio. Un segundo cliente independiente es la solución estructural, y se puso en marcha en su versión definitiva en diciembre de 2025.

TPS de 1 millón TPS seguirá acaparando titulares, pero es la parte menos interesante. El verdadero cambio es que Solana cuenta Solana con una vía creíble hacia la resiliencia multicliente, la que permite a las instituciones considerarla una infraestructura de producción en lugar de un experimento rápido pero frágil.

La ejecución a gran escala es la gran incógnita. El staking debe migrar, el nuevo código debe resistir años de condiciones adversas y las exigencias de hardware no pueden provocar una recentralización silenciosa del conjunto de validadores. Firedancer Solana arquitectura que necesitaba; que la red aproveche al máximo sus ventajas dependerá de cómo se lleve a cabo la implementación.