En la conferencia Solana Breakpoint de la semana pasada, el ambiente era vibrante con lanzamientos de productos y varios eventos paralelos interesantes. Un acontecimiento destacado fue el lanzamiento oficial en la red principal de la primera versión del cliente validador de Solana, Firedancer.
Se prestó especial atención a este hito, que supuso un importante salto en el rendimiento de la red Solana y mitigó el riesgo de caída de la red provocada por el fallo de un solo cliente.
El desarrollo de Firedancer se remonta a 2021-2022, encabezado por Jump Trading Group como segundo cliente validador de Solana (con el cliente original, Agave, desarrollado por Anza). Su principal objetivo era eliminar los puntos únicos de fallo, mejorando la solidez y resistencia generales de la red.
A diferencia del validador original basado en Rust, Firedancer está escrito en C, excluyendo el código Rust. Esta elección reduce significativamente el impacto potencial de las vulnerabilidades en la red, añadiendo una sólida capa de seguridad a Solana.
¿Cómo funciona Firedancer?
Durante una presentación en Solana Breakpoint, el director científico de Jump Crypto, Kevin Bowers, mostró la capacidad de Firedancer para procesar más de un millón de transacciones por segundo (TPS), superando con creces el límite teórico actual de Solana de decenas de miles de TPS. Comparó metafóricamente este logro con la ampliación de una «carretera rural» para convertirla en una «autopista interestatal», lo que indica una doble optimización de los costes y la capacidad de la red.
Liam Heeger, ingeniero del núcleo, compartió los progresos realizados en la red de pruebas, señalando que Firedancer produjo con éxito más de 20.000 bloques con un ratio de replanteo del 1%. Otro ingeniero, Aryaman Jain, demostró el rendimiento de Firedancer en condiciones específicas, revelando un TPS de hasta un millón en un entorno de 10 validadores, con más de 1.200 millones de cálculos por segundo y una capacidad de espacio de bloques de 3,5 Gbps.
¿Cómo funciona Firedancer?
Firedancer se basa en tres componentes principales: una pila de computación de alto rendimiento, una pila de red y los mecanismos de tiempo de ejecución y consenso. Su capacidad para elevar el rendimiento de Solana a 1 millón de TPS (los límites actuales del protocolo rondan los 81.000 TPS) reside en su innovadora arquitectura y en la optimización del flujo de datos.
El validador emplea un modelo de concurrencia que ejecuta diversas tareas en varios subprocesos, cada uno de los cuales se centra en tareas específicas como el procesamiento de paquetes de red, la validación de transacciones y el empaquetado de bloques. Este diseño maximiza la utilización de los recursos y acelera considerablemente el procesamiento de las transacciones.
En concreto, cada subproceso ejecuta una de 11 tareas diferentes. Algunas tareas requieren un único subproceso, mientras que otras requieren varios subprocesos trabajando en paralelo. Cada subproceso funciona en un núcleo dedicado de la CPU, lo que garantiza que nunca entre en reposo ni sea reasignado por el sistema operativo.
Firedancer también introduce una arquitectura denominada «mosaicos», en la que cada mosaico representa un trabajo, su subproceso en ejecución y el núcleo de CPU asignado. Esta combinación permite un ajuste del rendimiento flexible y eficaz. Por ejemplo, los mosaicos net y quic pueden manejar más de 1 millón de TPS, mientras que los mosaicos verify y bank se centran en la validación de transacciones y la ejecución de bloques, suficiente para escenarios de alta concurrencia.
La documentación oficial de Firedancer enumera las 11 fichas siguientes:
- red: Envía y recibe paquetes de red (cada baldosa puede manejar >1 millón de TPS);
- quic: Recibe transacciones de clientes, gestionando la conexión y el procesamiento de paquetes para el protocolo QUIC (cada baldosa puede manejar >1 millón de TPS);
- verifique: Valida las firmas criptográficas de las transacciones entrantes, filtrando las no válidas (cada ficha puede gestionar entre 20.000 y 40.000 TPS);
- dedup: Comprueba y filtra las transacciones entrantes duplicadas;
- envase: Empaqueta las transacciones entrantes cuando actúa como líder, programándolas inteligentemente para su ejecución;
- banco: Ejecuta transacciones programadas (cada baldosa puede manejar 20-40.000 TPS);
- poh: Realiza hashes continuamente en segundo plano, mezclando los hashes generados con las transacciones ejecutadas para probar el orden y el tiempo;
- triturar: Distribuye datos en bloque a la red cuando actúa como líder; cuando no, recibe y retransmite datos en bloque (el rendimiento depende principalmente del tamaño del clúster, con puntos de referencia que indican >1 millón de TPS para clústeres pequeños);
- tienda: Recibe los datos de los bloques cuando actúa como líder o de otros nodos cuando son líderes, almacenándolos en una base de datos en disco local;
- métrico: Recoge información de monitorización sobre otros mosaicos y la proporciona a los extremos HTTP;
- firmar: Contiene la clave privada del validador y responde a las solicitudes de firma de otros mosaicos.
En particular, antes de que Firedancer madure, su versión de transición, Frankendancer, ya ha entrado en la Solana mainnet. Frankendancer es un híbrido del código de Firedancer y Agave, que aprovecha las ventajas de Firedancer en cuanto a pila de red y producción de bloques, al tiempo que conserva las funcionalidades de ejecución y consenso de Agave. En cambio, Firedancer se construye completamente desde cero sin ningún código de Agave.
¿Cuál es el impacto de Firedancer?
Sin duda, el lanzamiento de Firedancer tiene implicaciones significativas para el ecosistema Solana, ya que aumenta en gran medida la diversidad de validadores y reduce aún más el riesgo de puntos únicos de fallo, fortificando así la fiabilidad de la red.
Además, Firedancer mantiene la compatibilidad con los protocolos existentes, garantizando una transición suave para el ecosistema sin requerir ajustes sustanciales por parte de los desarrolladores y usuarios de DApp.
Aunque Firedancer se encuentra actualmente en modo sin voto y en proceso de optimización y auditoría continuas, dibuja un panorama esperanzador para el futuro desarrollo de la red Solana.
-
-
-
-
-
-
-
-
