¿Qué es Firedancer? Análisis profundo de Solana 2.0

¿De qué trata este artículo?

Solana es la blockchain más rápida. Pero puede ser aún más rápida. El cliente validador actual de Solana Labs es bueno, pero está optimizado para acelerar su lanzamiento al mercado. Gracias a la experiencia adquirida, la oportunidad de comenzar desde cero y décadas de experiencia en computación de alto rendimiento, Jump busca hacer que Solana sea aún más rápida y confiable. Jump aplica su experiencia en trading de alta frecuencia para desarrollar Firedancer. Este es el cliente validador con mayor rendimiento de cualquier blockchain. Propone una reescritura completa del cliente validador actual de Solana en el lenguaje de programación C.

Este artículo analiza los validadores y la importancia de contar con distintos clientes validadores. Después, explicaremos por qué Jump está creando un nuevo cliente validador y cómo su experiencia en trading de alta frecuencia lo convierte en el equipo ideal para desarrollar Firedancer. Luego, explicaremos qué es Firedancer, cómo funciona, por qué es rápido, cómo se protege y cuál es su estado actual.

Al terminar este artículo, comprenderás a fondo el nuevo cliente validador de Jump. Conocerás sus innovadoras optimizaciones, que lo convierten en el cliente validador con mayor rendimiento de cualquier blockchain. También comprenderás por qué Firedancer es esencial para el rendimiento y la confiabilidad de la red Solana. Este es el único artículo que necesitas para aprender sobre Firedancer.

La sección de Apéndice contiene una introducción totalmente opcional al hardware informático y las redes. Se agregó para brindar el contexto necesario al lector promedio y permitirle comprender los conceptos más avanzados de hardware y redes que aborda este artículo. No obstante, se ofrece contexto cuando es necesario. Este artículo busca ser accesible para que cualquier persona que use Solana pueda comprender Firedancer y su importancia.

¿Qué son los validadores y qué es la diversidad de clientes validadores?

Un validador es una computadora que participa en una blockchain de prueba de participación. Los validadores son la columna vertebral de la red Solana. Procesan transacciones y participan en el consenso. Un validador ayuda a proteger la red al bloquear cierta cantidad del token nativo de Solana como participación. Considéralo un depósito de seguridad que expone financieramente al validador ante la red. Esta exposición incentiva a los validadores a realizar sus tareas con precisión y eficiencia, ya que reciben recompensas por sus aportes. Los validadores también reciben penalizaciones por actividades maliciosas o incorrectas. La participación de un validador se reduce por comportamiento indebido mediante un proceso conocido como slashing. Por lo tanto, al validador le conviene cumplir correctamente sus funciones para aumentar su participación.

Los clientes validadores son aplicaciones que los validadores usan para cumplir sus funciones. El cliente sirve como base para los validadores y utiliza su identidad criptográfica única para participar en el consenso.

Tener varios clientes diferentes mejora la tolerancia a fallos si una implementación falla. Por ejemplo, si ningún cliente controla más del 33 % de la participación, una caída o un error que afecte la disponibilidad no derribará la red. Del mismo modo, si un error en un cliente provoca una transición de estado no válida, la red puede evitar un fallo de seguridad si menos del 33 % de la participación utiliza ese cliente. Esto se debe a que la mayor parte de la red permanecerá en un estado válido, lo que impedirá una división o bifurcación de la blockchain. Por lo tanto, la diversidad de clientes validadores aumenta la resiliencia de la red, ya que un error o una vulnerabilidad en un cliente no inutilizará toda la red.

La diversidad de clientes se mide según el porcentaje de participación que utiliza cada cliente y la cantidad total de clientes disponibles. Al momento de escribir este artículo, hay 1979 validadores en la red Solana. Los dos clientes que estos validadores usan en mainnet son proporcionados por Solana Labs y Jito Labs. Solana se lanzó con un cliente validador en marzo de 2020, desarrollado por Solana Labs. En agosto de 2022, Jito Labs lanzó un segundo cliente validador. Este cliente es una bifurcación del código de Solana Labs que Jito mantiene e implementa. El cliente optimiza la extracción de MEV (valor máximo extraíble) dentro de los bloques. El cliente de Jito crea una pseudomempool, ya que Solana transmite bloques sin una. Como aclaración, una mempool, o pool de memoria, es una cola de transacciones pendientes y sin confirmar. Una pseudomempool permite a los validadores buscar entre estas transacciones, agruparlas de forma óptima y enviarlas al Block Engine de Jito.

En octubre de 2023, el cliente de Solana Labs tenía el 68,55 % de la participación activa, mientras que Jito tenía el 31,45 %. La cantidad de validadores que usan el cliente de Jito aumentó un 16 % desde el Informe de salud anterior de Solana Foundation. El creciente uso del cliente de Jito indica una tendencia positiva hacia la diversidad de clientes.

Aunque esta noticia sobre el crecimiento es alentadora, la situación no es perfecta. Es fundamental destacar que el cliente de Jito es una bifurcación del cliente de Solana Labs. Esto significa que Jito comparte muchos componentes con la base de código original del validador y podría ser vulnerable a errores o ataques que afectarían al cliente de Labs. En un futuro ideal, Solana tendría al menos cuatro clientes validadores independientes. Distintos equipos desarrollarían estos clientes en diferentes lenguajes de programación. Ninguna implementación tendría más del 33 % de la participación, ya que cada cliente mantendría alrededor del ~25 %. Esta configuración ideal no tendría ningún punto único de fallo en toda la pila del validador.

Desarrollar un segundo cliente validador independiente es esencial para hacer realidad este futuro, y Jump se dedica a conseguirlo.

¿Por qué Jump está creando un nuevo cliente validador?

La mainnet de Solana ha sufrido cuatro interrupciones en la producción de bloques. Cada una requirió correcciones manuales por parte de cientos de validadores. Estas interrupciones han generado preocupación sobre la confiabilidad de la red Solana. Jump sostiene que el protocolo es sólido. En cambio, atribuye el tiempo de inactividad a problemas en módulos de software que afectan al consenso. Por eso, Jump desarrolla un nuevo cliente validador para solucionar estos problemas. El objetivo general de este cliente es mejorar la estabilidad y eficiencia de la red Solana.

Desarrollar un cliente validador independiente es una tarea difícil. Sin embargo, esta no es la primera vez que Jump crea una red global confiable. Antes, los especialistas del mercado ejecutaban manualmente las operaciones con valores (es decir, la compra y venta de acciones). Con la llegada de las plataformas de trading electrónico, las bolsas de valores se volvieron más abiertas. Esta apertura aumentó la competencia y la automatización, además de reducir el tiempo y el costo de las operaciones para los inversionistas. Esto desató una carrera tecnológica entre los especialistas del mercado.

Los traders viven para operar. Una experiencia de trading óptima exige soluciones de software, hardware y redes sin concesiones. Estos sistemas deben ofrecer alta inteligencia automatizada, baja latencia en tiempo real, alto rendimiento, gran adaptabilidad, alta escalabilidad, gran confiabilidad y alta responsabilidad.

Las soluciones genéricas (es decir, software que una empresa puede comprar directamente) no ofrecen una ventaja competitiva. Enviar diez veces la orden correcta a una bolsa y quedar en segundo lugar es una forma costosa de perder dinero. La intensa competencia del trading de alta frecuencia genera un ciclo de desarrollo continuo para crear infraestructura global de trading de primer nivel.

Este escenario puede resultarte familiar. Las exigencias de un sistema de trading exitoso se parecen a las de una blockchain exitosa. Las blockchains necesitan ser redes de alto rendimiento, tolerantes a fallos y con baja latencia. Una blockchain lenta es tecnología fallida que no puede satisfacer las exigencias de las aplicaciones empresariales modernas: solo obstaculiza la innovación, la escalabilidad y la utilidad en el mundo real. Con más de dos décadas de experiencia escalando redes globales y desarrollando sistemas de alto rendimiento, Jump es el equipo ideal para crear un cliente validador independiente. Kevin Bowers, director científico de Jump Trading, supervisa este proceso.

¿Por qué la velocidad de la luz es demasiado lenta?

Kevin Bowers ha hablado extensamente sobre por qué la velocidad de la luz es demasiado lenta. La velocidad de la luz es una constante finita que limita de forma natural la cantidad de cálculos que puede procesar un solo transistor. Actualmente, los bits se representan mediante electrones que recorren transistores. El teorema de capacidad de Shannon (es decir, la cantidad máxima de datos sin errores que pueden enviarse por un canal) restringe la cantidad de bits transmitidos mediante un transistor. Debido a la física fundamental y la teoría de la información, la velocidad de cálculo está limitada por la rapidez con la que un electrón puede desplazarse por la materia y por la cantidad de datos que se pueden enviar. Estas limitaciones se hacen evidentes cuando las supercomputadoras se llevan al límite. Como resultado, existe un “desajuste drástico entre la capacidad de las computadoras para procesar números y su capacidad para moverlos”.

Tomemos como ejemplo una CPU Intel Core i9 13900K. Tiene 24 núcleos x86 con una frecuencia base de 2,2 GHz y una frecuencia turbo máxima de 5,8 GHz. En el peor de los casos, la luz tendría que recorrer una distancia total de ~52,0 mm a través de esta CPU. La distancia Manhattan de la CPU (es decir, la distancia entre dos puntos medida a lo largo de ejes perpendiculares) es de ~73,6 mm. A la frecuencia turbo máxima de la CPU de 5,8 GHz, la luz puede recorrer ~51,7 mm en el aire. Esto significa que una señal puede casi completar un recorrido de ida y vuelta entre dos puntos cualesquiera de la CPU durante un solo ciclo de reloj.

La realidad es mucho peor. Estas mediciones usan la velocidad de la luz al desplazarse por el aire, pero estas señales viajan por dióxido de silicio (SiO2). La luz puede recorrer ~26,2 mm en dióxido de silicio durante un ciclo de reloj de 5,8 GHz. En el silicio (Si), la luz solo puede recorrer ~15,0 mm durante un ciclo de reloj de 5,8 GHz, poco más de la mitad del borde largo de la CPU.

El equipo de Firedancer sostiene que los avances tecnológicos recientes en computación se han centrado en incorporar más núcleos a una CPU, en lugar de hacerlos más rápidos. Cuando las personas necesitaban más rendimiento, se les recomendaba comprar más hardware. Esto funciona por ahora cuando el cuello de botella es la capacidad de procesamiento. El verdadero cuello de botella es la velocidad de la luz. Esta restricción natural provoca una parálisis en la toma de decisiones. Ninguna optimización genera beneficios inmediatos porque un sistema tiene muchos componentes y ninguno está bien optimizado. Los componentes que no se optimicen empeorarán con el tiempo porque tendrán menos recursos de cómputo disponibles. Entonces, ¿qué sigue?

En el mundo de la computación de alto rendimiento, tarde o temprano todo debe optimizarse. El resultado es la creación de sistemas para trading en producción e investigación cuantitativa que operan a los límites de la física y la teoría de la información a escala planetaria. Esto incluye desde la creación de tecnología personalizada de conmutación de redes hasta algoritmos sin bloqueos diseñados teniendo en cuenta estos límites físicos. Jump es tanto una empresa tecnológica como una empresa de trading. En la frontera entre la ciencia ficción y la realidad, y ante las notables similitudes entre los problemas que enfrentan Jump y Solana, Jump desarrolla Firedancer.

¿Qué es Firedancer?

Firedancer es un nuevo cliente validador totalmente independiente, desarrollado por el equipo de Firedancer en el lenguaje de programación C. Firedancer prioriza la confiabilidad mediante su arquitectura modular, dependencias mínimas y un exhaustivo proceso de pruebas. Propone una reescritura importante de los tres componentes funcionales del cliente de Solana Labs: redes, entorno de ejecución y consenso. Cada nivel está optimizado para ofrecer el máximo rendimiento, de modo que el cliente opere con una capacidad limitada únicamente por el hardware del validador. Esto contrasta con los límites de rendimiento que enfrentan actualmente los validadores debido a ineficiencias del software. Con Firedancer, Solana escalará junto con el ancho de banda y el hardware.

Los objetivos de Firedancer son:

• Documentar y estandarizar el protocolo de Solana (al final, una persona debería poder crear un validador de Solana con solo consultar la documentación, sin revisar el código del validador en Rust)
• Aumentar la diversidad de clientes validadores
• Mejorar el rendimiento del ecosistema

¿Cómo funciona Firedancer?

Arquitectura modular

Firedancer se diferencia de los clientes validadores actuales de Solana gracias a su particular arquitectura modular. A diferencia del cliente validador de Solana Labs escrito en Rust, que funciona como un único proceso, Firedancer está compuesto por numerosos procesos individuales de Linux escritos en C, conocidos como tiles. Un tile es un proceso y cierta cantidad de memoria. Esta arquitectura de tiles es fundamental para la filosofía operativa de Firedancer y su enfoque en la robustez y eficiencia.

Un proceso es una instancia de un programa en ejecución. Es un componente fundamental de los sistemas operativos modernos y representa la ejecución de un conjunto de instrucciones. Cada proceso tiene su propio espacio de memoria y recursos que el sistema operativo asigna, y funciona de forma independiente de los demás procesos. Un proceso es como un trabajador independiente en una gran fábrica que realiza una tarea específica con sus propias herramientas y espacio de trabajo.

En Firedancer, cada tile es un proceso individual con una función definida. Por ejemplo, el tile QUIC procesa el tráfico QUIC entrante y reenvía las transacciones encapsuladas al tile de verificación. El tile de verificación se encarga de verificar las firmas, y así sucesivamente con cada tile. Estos tiles funcionan de manera independiente y simultánea, y contribuyen a la funcionalidad general del sistema. Los procesos individuales de Linux permiten crear dominios de fallo pequeños e independientes. Esto significa que los problemas de un tile tienen un impacto mínimo —o un “radio de explosión” reducido— en el sistema general. Este enfoque difiere del cliente de Solana Labs escrito en Rust, ya que un punto único de fallo no puede comprometer al instante todo el validador.

Una ventaja clave de la arquitectura de Firedancer es su capacidad para reemplazar y actualizar cada tile en cuestión de segundos sin tiempo de inactividad. Esta capacidad contrasta marcadamente con el cliente de Solana Labs escrito en Rust, que requiere un apagado completo antes de las actualizaciones. La diferencia se debe a la falta de estabilidad de ABI (interfaz binaria de aplicaciones) en Rust. Esto impide realizar actualizaciones sobre la marcha en un entorno exclusivo de Rust. El uso de procesos en C, que aprovechan la estabilidad binaria del modelo de ejecución de C, reduce considerablemente el tiempo de inactividad relacionado con las actualizaciones. Esto es posible porque los tiles administran el estado del validador en diferentes espacios de trabajo. Estos objetos de memoria compartida persisten mientras el validador permanezca encendido. Cada tile puede reanudar sin inconvenientes el procesamiento desde el punto donde se detuvo durante un reinicio o una actualización.

En general, Firedancer se construye conforme a una arquitectura basada en tiles que tiene en cuenta NUMA. Explicaremos qué significa esto en la próxima sección. Por ahora, significa que ofrece recursos de hardware dedicados para cada hilo. En esta arquitectura, se utiliza 1 núcleo de CPU por tile. Ofrece un sistema de transmisión de mensajes de alto rendimiento entre los tiles, optimizado para la localidad de memoria, la distribución de recursos y las latencias de los componentes.

Procesamiento de red

El procesamiento de red de Firedancer está diseñado para gestionar las exigencias intensivas de la red Solana a medida que escala hasta alcanzar velocidades de gigabits por segundo. Este proceso se divide en actividades entrantes y salientes.

Las actividades entrantes se centran principalmente en recibir transacciones de los usuarios. El rendimiento de Firedancer es esencial porque los mensajes de consenso pueden perderse si un validador se retrasa en el procesamiento de paquetes. El ancho de banda operativo actual de un nodo de Solana es de ~0,2 Gbps, mientras que el mayor pico registrado en un nodo de Jump fue de ~40 GBps. Este pico de ancho de banda demuestra la necesidad de una solución sólida y escalable para procesar datos entrantes.

Las actividades salientes incluyen el empaquetado de bloques, la creación de bloques y el envío de shreds. Cada uno de estos pasos es crucial para el funcionamiento seguro y eficiente de la red Solana. El rendimiento de estas tareas no solo afecta la capacidad de procesamiento, sino también la confiabilidad general de la red.

Firedancer busca corregir las debilidades históricas de la interfaz peer-to-peer de Solana para procesar transacciones. Una deficiencia importante de esta interfaz era la ausencia de control de congestión para las transacciones entrantes. Esta deficiencia provocó importantes interrupciones de la red el 14 de septiembre de 2021 (17 horas) y el 30 de abril de 2022 (7 horas).

En respuesta, Solana realizó varias actualizaciones de red para gestionar correctamente grandes volúmenes de transacciones. Firedancer sigue el mismo camino al adoptar QUIC para controlar el flujo. QUIC es un protocolo multiplexado de transporte de red que sirve como base de HTTP/3. Es fundamental para protegerse contra ataques DDoS y administrar el tráfico de red. Sin embargo, es importante señalar que, en algunos casos, los costos superan los beneficios. QUIC, junto con el hardware especializado de los centros de datos para mitigar ataques DDoS, elimina el incentivo para inundar la red con transacciones.

La especificación de QUIC de 151 páginas añadió una complejidad considerable al desarrollo. Como no pudo encontrar una biblioteca existente en C que satisficiera sus necesidades de licencia, rendimiento y confiabilidad, el equipo de Firedancer creó su propia implementación. La implementación de QUIC de Firedancer, apodada fd_quic, incorpora estructuras de datos y algoritmos optimizados para reducir al mínimo la asignación de memoria y evitar que esta se agote.

La pila de red personalizada de Firedancer es el núcleo de sus capacidades de procesamiento. La pila se diseñó desde cero para aprovechar el escalado del lado receptor (RSS). RSS es una forma de balanceo de carga de red acelerado por hardware que distribuye el tráfico de red entre varios núcleos de CPU para aumentar el paralelismo del procesamiento. Cada núcleo de CPU gestiona una parte del tráfico entrante con una sobrecarga mínima. Este enfoque supera al balanceo de carga tradicional basado en software porque elimina la necesidad de usar planificadores complejos, bloqueos y operaciones atómicas.

Firedancer incorpora un nuevo framework de transmisión de mensajes para crear una aplicación compuesta por tiles de alto rendimiento. Estos tiles pueden eludir la red del kernel, limitada por su dependencia de sockets, mediante el uso de AF_XDP. AF_XDP es una familia de direcciones optimizada para procesar paquetes con alto rendimiento. El uso de AF_XDP permite que Firedancer lea directamente desde los búferes de las interfaces de red.

Este sistema de tiles facilita diversos conceptos de computación de alto rendimiento en la pila de Firedancer. Entre ellos:

• Compatibilidad con NUMA - NUMA (acceso no uniforme a memoria) es un diseño de memoria informática en el que un procesador puede acceder a su propia memoria más rápido que a la memoria asociada con otro procesador. Para Firedancer, tener en cuenta NUMA significa que el cliente puede administrar eficientemente la memoria en configuraciones multiprocesador. Esto es importante para procesar grandes volúmenes de transacciones, ya que optimiza el uso de los recursos de hardware disponibles.
• Localidad de caché - La localidad de caché se refiere al uso de datos que ya se encuentran en una caché cercana al procesador. Por lo general, se trata de una forma compleja de localidad temporal (es decir, datos a los que se accedió recientemente). En Firedancer, priorizar la localidad de caché significa que está diseñado para procesar datos de red mientras minimiza la latencia y maximiza la velocidad.
• Concurrencia sin bloqueos - La concurrencia sin bloqueos consiste en diseñar algoritmos que no requieran mecanismos de bloqueo (como los mutexes) para administrar operaciones simultáneas. En Firedancer, la concurrencia sin bloqueos permite ejecutar varias operaciones de red en paralelo sin causar demoras por los bloqueos. La concurrencia sin bloqueos mejora la capacidad de Firedancer para procesar simultáneamente una gran cantidad de transacciones.
• Tamaños de página grandes - Usar tamaños de página grandes en la administración de memoria ayuda a gestionar conjuntos de datos al reducir las consultas a las tablas de páginas y la posible fragmentación de la memoria. Para Firedancer, esto mejora la eficiencia de la administración de memoria. Resulta beneficioso para procesar grandes volúmenes de datos de red.

Sistema de compilación

El sistema de compilación de Firedancer está diseñado conforme a un conjunto de principios rectores para garantizar la confiabilidad y la coherencia. Hace hincapié en minimizar las dependencias externas y tratar como dependencias todas las herramientas que intervienen en el proceso de compilación. Esto incluye fijar cada dependencia, incluidos los compiladores, en versiones exactas. Un aspecto fundamental de este sistema es el aislamiento del entorno durante los pasos de compilación. El aislamiento del entorno mejora la portabilidad, ya que el entorno del sistema no afecta al proceso de compilación.

¿Cómo logra Firedancer ser tan rápido?

Paralelismo de datos avanzado

El enfoque de Firedancer para tareas criptográficas, como la verificación de firmas ED25519, utiliza el paralelismo de datos avanzado disponible en los procesadores modernos. Las CPU modernas incluyen instrucciones de una sola instrucción, múltiples datos (SIMD) para procesar varios elementos de datos al mismo tiempo, así como optimizaciones para ejecutar varias instrucciones por ciclo de CPU. Por lo general, resulta más eficiente en términos de espacio, tiempo y energía que una sola instrucción opere en paralelo sobre un arreglo o vector de elementos de datos. En este sentido, las mejoras en el procesamiento paralelo de datos pueden tener un mayor impacto en el rendimiento que los aumentos en la velocidad bruta de procesamiento.

Un área en la que Firedancer usa el paralelismo de datos es la optimización del cálculo de verificaciones de firmas. Este enfoque permite gestionar arreglos o vectores de elementos de datos al mismo tiempo para maximizar el rendimiento y minimizar la latencia. La base de esta implementación de ED25519 es la aritmética de campos de Galois. Esta forma de aritmética es adecuada para algoritmos criptográficos y cálculos binarios. En los campos de Galois, operaciones como la suma, la resta, la multiplicación y la división se definen de una forma que se ajusta a la naturaleza binaria de los sistemas informáticos. Este es un ejemplo de un campo de Galois definido por 23:

El único problema es que ED25519 usa un campo de Galois definido por 2255-19. Piensa en los elementos del campo como números entre 0 y 2255-19. Así se ven las operaciones básicas:

• x + y → suma escolar mod 2255-19
• x - y → resta escolar mod 2255-19
• x * y → multiplicación escolar mod 2255-19
• 1/x → x elevado a 2255-21 mod 2255-19

La suma, la resta y la multiplicación son operaciones matemáticas casi de tipo uint256_t (es decir, operaciones con enteros sin signo, donde el valor máximo es 2256-1). Calcular la división es difícil. Las CPU y GPU convencionales no realizan operaciones matemáticas de tipo uint256_t, mucho menos operaciones “casi de tipo uint256_t” y aún menos una división extraña y excepcionalmente difícil. Implementar este tipo de operaciones con un alto rendimiento depende de qué tan bien podamos emularlas.

La implementación de Firedancer descompone la aritmética al considerar los números de una forma más flexible. Si aplicamos los principios de la división y la multiplicación larga escolares, donde trasladamos números de una columna a la siguiente, podemos procesar estas columnas en paralelo. La forma más rápida de emular este tipo de operaciones es representar un uint256_t como seis dígitos de 43 bits con un “acarreo” de 9 bits. Esto permite utilizar las operaciones de 64 bits existentes en las CPU y, al mismo tiempo, deja suficiente espacio para los bits de acarreo. Esta disposición de los números reduce la necesidad de propagar el acarreo con frecuencia y permite que Firedancer gestione números grandes con mayor eficacia.

Esta implementación aprovecha el paralelismo de datos al reorganizar los cálculos aritméticos como sumas de columnas en paralelo. Procesar las columnas en paralelo acelera el cálculo general, ya que convierte lo que habría sido un cuello de botella secuencial en una tarea paralelizable. Firedancer también utiliza conjuntos de instrucciones vectorizadas como AVX512 y su extensión IFMA (AVX512-IFMA). Estos conjuntos permiten procesar la aritmética de campos de Galois explicada anteriormente, lo que mejora la velocidad y la eficiencia.

La implementación de Firedancer acelerada con AVX512 es rápida. En un solo núcleo de servidor Icelake de 2.3 GHz, ofrece más del doble de rendimiento por ciclo de reloj del núcleo que su demostración de Breakpoint 2022. La implementación alcanza una utilización del 100% de los carriles vectoriales y una paralelización de datos masiva. Esta es otra demostración magistral del equipo de Firedancer de que, debido a los retrasos impuestos por la velocidad de la luz, es mucho más fácil ejecutar tareas independientes en paralelo que realizar una sola tarea a la vez, incluso con hardware personalizado.

Uso de FPGA para comunicaciones de red de alta velocidad

Las CPU pueden gestionar ~30,000 verificaciones de firmas por segundo y por núcleo. Aunque son una opción eficiente en términos de energía, resultan insuficientes para operaciones a gran escala. Esta limitación se debe a su enfoque de procesamiento secuencial. Las GPU elevan esta capacidad de procesamiento a ~1 millón de verificaciones por segundo y por núcleo. Sin embargo, su considerable consumo de energía de alrededor de ~300 W por unidad y la latencia inherente al procesamiento por lotes limitan su desempeño.

Las FPGA surgen como una alternativa superior. Igualan el rendimiento de las GPU, pero consumen mucha menos energía: alrededor de 50 W por FPGA. Su latencia también es inferior a los diez milisegundos de las GPU. Con una latencia de ~200 microsegundos, las FPGA ofrecen una solución mucho más receptiva para el procesamiento en tiempo real. A diferencia del procesamiento por lotes de las GPU, las FPGA de Firedancer procesan cada transacción de forma individual y continua. El uso de FPGA en Firedancer ofrece un impresionante rendimiento de 8 millones de firmas por segundo con un presupuesto energético inferior a 400 W para 8 FPGA.

El equipo presentó el proceso de verificación de firmas ED25519 de Firedancer en Breakpoint 2022. Este proceso incluía varias etapas, entre ellas el cálculo de SHA-512 en una canalización RTL pura, con diversas comprobaciones y cálculos en una canalización de procesador ECC-CPU personalizado. En esencia, el equipo de Firedancer escribió un compilador y un ensamblador para su procesador personalizado, tomó el código Python del RFC (solicitud de comentarios), lo ejecutó con objetos con operadores sobrecargados para generar código máquina y después colocó el código máquina sobre la ECC-CPU.

Es importante señalar que Firedancer utiliza un estilo de factor de forma de acelerador de AWS para equilibrar la robustez con la conectividad de red. Esta elección aborda los desafíos asociados con la conectividad directa de red, una característica que los proveedores de servicios en la nube suelen limitar. De este modo, Firedancer garantiza una integración fluida de sus capacidades avanzadas dentro de las restricciones de la infraestructura basada en la nube.

Es fundamental reconocer que las distintas operaciones requieren espacio físico tangible, no solo espacio conceptual para datos. Firedancer aplica este principio al disponer estratégicamente los componentes físicos para que estén cerca y puedan reutilizarse. Esta configuración permite que Firedancer maximice la eficiencia de su FPGA y alcance 8m TPS con una FPGA de hace 7 años en una máquina de hace 8 años.

Optimización de la codificación Reed-Solomon para comunicaciones de red

El desafío fundamental de las comunicaciones de red consiste en transmitir nuevas transacciones a todo el mundo. La naturaleza punto a punto de Internet, el ancho de banda limitado y los problemas de latencia dificultan la implementación de ideas tradicionales, como usar la red para una transmisión directa. Distribuir los datos en una estructura de anillo o árbol resuelve parcialmente estos problemas, pero no es suficiente porque los paquetes de datos pueden perderse durante la transmisión.

La codificación Reed-Solomon es una solución elegante para estos problemas. Introduce redundancia en la transmisión de datos (es decir, información de paridad) para recuperar paquetes perdidos. El concepto se basa en el principio de que dos puntos definen una línea y que dos puntos cualesquiera de esa línea pueden regenerar los puntos de datos originales. Si se construye un polinomio a partir de los puntos de datos y se distribuyen distintos puntos de esta función en paquetes separados, se pueden reconstruir los datos originales siempre que el destinatario reciba al menos dos paquetes.

Construimos un polinomio porque usar la fórmula tradicional para los puntos de una línea (y = mx + b) es lento desde el punto de vista computacional. Firedancer utiliza polinomios de Lagrange, un método especializado de construcción de polinomios, para acelerar el proceso. Estos simplifican la creación del polinomio necesario para la codificación Reed-Solomon. También convierten el proceso en un producto matriz-vector más eficiente que funciona con polinomios de orden superior. Esta matriz está muy estructurada y sus patrones se repiten de forma recursiva, por lo que la primera fila del patrón la determina por completo. Esta estructura permite multiplicar todo con mayor rapidez. Firedancer utiliza un enfoque O(n log n) presentado en un artículo de 2016 para multiplicar por esta matriz. Es el enfoque teórico más rápido conocido para la codificación Reed-Solomon. El resultado es un cálculo eficiente de la información de paridad en comparación con los métodos tradicionales:

• Más de ~120 Gbps/núcleo en codificación RS
• Hasta ~50 Gbps/núcleo en decodificación RS
• Todas estas métricas se comparan con los ~8 Gbps/núcleo actuales de codificación RS (rust-rse)

Firedancer puede calcular la paridad 14 veces más rápido que los métodos tradicionales gracias a este enfoque optimizado de codificación Reed-Solomon. Esto da como resultado un proceso rápido y confiable de codificación y decodificación de datos, esencial para mantener un alto rendimiento y una baja latencia a escala global.

¿Cómo se protege Firedancer?

Oportunidades

Actualmente, todos los validadores usan software basado en el cliente validador original. Firedancer puede mejorar la diversidad de clientes y de la cadena de suministro de Solana si se diferencia del cliente de Solana Labs. Esto incluye el uso de dependencias similares y de Rust para desarrollar su cliente.

Los clientes validadores de Solana Labs y Jito se ejecutan como un solo proceso. Es difícil añadir seguridad a una aplicación monolítica una vez que se ejecuta en producción. Los validadores que ejecutan estos clientes tendrían que apagarse para aplicar actualizaciones de seguridad sobre la marcha en Rust puro. El equipo de Firedancer puede incorporar una arquitectura segura en su nuevo cliente desde el principio.

Firedancer también tiene la ventaja de aprender de la experiencia. Solana Labs desarrolló el cliente validador en un entorno de startup. Este entorno acelerado obligó a Labs a avanzar con rapidez para llegar pronto al mercado. Esto creó una base deficiente para el desarrollo futuro. El equipo de Firedancer puede analizar lo que hizo Labs y lo que hicieron los equipos de otras cadenas, y preguntarse qué cambiarían si pudieran desarrollar un cliente validador desde cero.

Desafíos

Aunque Firedancer se diferencia del cliente de Solana Labs, debe reproducir su comportamiento con precisión. No hacerlo supone un riesgo de seguridad, ya que podría introducir errores de consenso por incompatibilidad. Esto puede mitigarse incentivando que un porcentaje del stake opere en ambos clientes y manteniendo a Firedancer por debajo del 33% del stake total durante un periodo prolongado. En cualquier caso, el equipo de Firedancer debe implementar el conjunto completo de funciones del protocolo, sin importar lo difícil que sea hacerlo de forma correcta o segura. Todo debe estar alineado con Firedancer. Por lo tanto, el equipo no puede desarrollar el código de forma aislada y debe compararlo con la funcionalidad del cliente de Labs. La falta de especificaciones y documentación agrava el problema, ya que obliga a Firedancer a incorporar estructuras ineficientes del protocolo.

El equipo de Firedaner también debe tener en cuenta que desarrolla su nuevo cliente en C. C no ofrece de forma nativa las garantías de seguridad de memoria que proporcionan lenguajes como Rust. Uno de los objetivos principales del código base de Firedancer es reducir la incidencia y el impacto de las vulnerabilidades de seguridad de memoria. Este objetivo requiere especial atención porque Firedancer es un proyecto que avanza con rapidez. Firedancer debe encontrar una forma de mantener la velocidad de desarrollo sin introducir estos errores. El aislamiento del OS es la práctica de aislar los tiles del OS. Los tiles solo pueden acceder a los recursos y ejecutar las llamadas al sistema necesarias para su tarea. Como cada tile tiene un propósito claramente definido y el equipo de Firedancer desarrolló la mayor parte del código del cliente, sus permisos se reducen de acuerdo con el principio de privilegio mínimo.

Implementación de un diseño de defensa en profundidad

Todo software tendrá alguna vulnerabilidad de seguridad en algún momento. Partiendo de la premisa de que el software tendrá errores, Firedancer opta por limitar el impacto potencial de cada vulnerabilidad. Este enfoque se denomina defensa en profundidad. La defensa en profundidad es una estrategia que utiliza varias medidas de seguridad para proteger un activo. Si un atacante compromete una parte del sistema, existen medidas adicionales para impedir que la amenaza afecte a toda la pila.Firedancer está diseñado para aplicar mitigaciones entre las etapas de vulnerabilidad y explotación. Por ejemplo, sería difícil que un atacante explotara una vulnerabilidad de seguridad de memoria.

Esto se debe a que la prevención de estos tipos de ataques es un problema ampliamente estudiado. La extensa investigación sobre la seguridad de memoria en C ha dado lugar a un arsenal de técnicas de refuerzo y funciones de compiladores que el equipo utiliza en Firedancer. Incluso si un atacante pudiera eludir las prácticas recomendadas del sector, le resultaría difícil comprometer el sistema con el exploit. Esto se debe al aislamiento de tiles y al aislamiento del OS.

El aislamiento de tiles es el resultado de la arquitectura paralela de Firedancer. Cada tile tiene un único propósito claro, ya que ejecuta su propio proceso de Linux. Por ejemplo, un tile de QUIC procesa el tráfico QUIC entrante y reenvía las transacciones encapsuladas al tile de verificación. Después, el tile de verificación se encarga de verificar las firmas. La comunicación entre los tiles de QUIC y verificación se realiza mediante una interfaz de memoria compartida (es decir, los procesos de Linux pueden transferirse datos entre sí). Esta interfaz de memoria compartida entre dos tiles actúa como límite de aislamiento. Si el tile de QUIC tuviera un error que permitiera a un atacante ejecutar código arbitrario al procesar un paquete QUIC malicioso, no afectaría a ningún otro tile. En un proceso monolítico, esto comprometería el sistema de inmediato. Un atacante podría perjudicar a toda la red si explotara esta vulnerabilidad en varios validadores. Podría degradar el rendimiento del tile de QUIC, pero el diseño de Firedancer limita su alcance únicamente a ese tile.

El aislamiento del OS es la práctica de aislar los tiles del OS. Los tiles solo pueden acceder a los recursos y ejecutar las llamadas al sistema necesarias para su tarea. Como los tiles tienen un propósito claramente definido y el equipo de Firedancer desarrolló casi todo el código, sus permisos se reducen de acuerdo con el principio de privilegio mínimo. Los tiles se colocan en sus propios espacios de nombres de Linux, que proporcionan una vista limitada del sistema. Esta vista restringida impide que un tile acceda a la mayor parte del sistema de archivos, la red y cualquier otro proceso que se ejecute en el mismo sistema. Los espacios de nombres proporcionan un límite que prioriza la seguridad. Sin embargo, un atacante aún podría eludirlo si dispusiera de un exploit del kernel para escalar privilegios. La interfaz de llamadas al sistema es el último vector de ataque del kernel al que pueden acceder los tiles. Para protegerla, Firedancer usa seccomp-BPF con el fin de filtrar las llamadas al sistema antes de que el kernel las procese. El cliente puede restringir los tiles a un grupo específico de llamadas al sistema. En algunos casos, también puede filtrar los parámetros de las syscalls. Esto es importante porque Firedancer puede garantizar que las syscalls de lectura y escritura solo operen sobre descriptores de archivo específicos.

Implementación de un programa de seguridad integrado

Firedancer está diseñado con un programa de seguridad integral incorporado en cada etapa de su desarrollo. El programa de seguridad del cliente es una colaboración continua entre los equipos de desarrollo y seguridad que establece un nuevo estándar para la tecnología blockchain segura.

El proceso comienza con una infraestructura de fuzzing de autoservicio. A modo de explicación, el fuzzing es una técnica que detecta automáticamente bloqueos o condiciones de error que indican vulnerabilidades. Para ello, somete a pruebas de estrés todos los componentes que aceptan entradas de usuario no confiables, incluidas la interfaz P2P (analizadores) y la máquina virtual SBPF. OSS-Fuzz mantiene una cobertura de fuzzing continua a medida que cambia el código. El equipo de seguridad también configuró una instancia dedicada de ClusterFuzzer para realizar fuzzing continuo guiado por cobertura. Los desarrolladores y los ingenieros de seguridad también aportan arneses de fuzzing (es decir, versiones especiales de pruebas unitarias para componentes críticos de seguridad). Los desarrolladores también pueden aportar nuevas pruebas de fuzzing, que se incorporan y ejecutan automáticamente. El objetivo es someter todas las partes a pruebas de fuzzing exhaustivas antes de que pasen a la siguiente etapa.

Las revisiones internas del código ayudan a identificar los errores que las herramientas no detectaron. En esta etapa, la atención se centra en los componentes de alto riesgo y gran impacto. Esta fase funciona como un mecanismo de retroalimentación para el resto del programa de seguridad. El equipo aplica todo lo aprendido y utiliza estas revisiones para mejorar la cobertura del fuzzing, incorporar nuevas comprobaciones de análisis estático para determinadas clases de errores e incluso realizar grandes refactorizaciones del código para eliminar vectores de ataque complejos desde el diseño. Expertos líderes del sector complementarán estas revisiones internas con revisiones externas de seguridad y un programa activo de recompensas por errores, tanto antes como después del lanzamiento.

Firedancer también se sometió a exhaustivas pruebas de estrés en varias redes de prueba. Estas redes de prueba estarán sujetas a ataques y fallas, como duplicación de nodos, fallas en enlaces de red, inundaciones de paquetes y violaciones del consenso. Estas redes soportan cargas considerablemente mayores que cualquier escenario realista en mainnet.

Esto nos lleva a la pregunta: ¿cuál es el estado actual de Firedancer?

¿Cuál es el estado actual de Firedancer y qué es Frankendancer?

El equipo de Firedancer desarrolla Firedancer de forma incremental para modularizar el cliente validador. Esto se alinea con sus objetivos de documentación y estandarización. Este enfoque garantiza que Firedancer se mantenga al día con los últimos avances de Solana. Así surgió Frankendancer. Frankendancer es un modelo de cliente híbrido en el que el equipo de Firedancer integra los componentes que desarrolla en la infraestructura existente del cliente validador. Este proceso de desarrollo permite mejorar y probar nuevas funciones de forma gradual.

Frankendancer es como colocar un auto deportivo en medio del tráfico. El rendimiento aumentará a medida que se desarrollen más componentes y se eliminen los cuellos de botella. Este proceso de desarrollo modular fomenta un entorno de validación personalizable y flexible. En él, los desarrolladores pueden modificar o sustituir componentes específicos de su cliente validador según sus necesidades.

¿Qué se está ejecutando realmente?

Frankendancer implementa todas las funciones de red de un validador de Solana:

• Entrantes: QUIC, TPU, Sigverify, Dedup
• Salientes: empaquetado de bloques, creación/firma/envío de shreds (Turbine)

Frankendancer utiliza el código de red de alto rendimiento en C de Firedancer sobre el runtime y el código de consenso en Rust de Solana Labs.

La arquitectura de Frankendancer está diseñada con la optimización para hardware de gama alta en mente. Aunque admite hosts básicos convencionales en la nube que ejecutan sistemas operativos Linux estándar, el equipo de Firedancer optimiza Frankendancer para servidores con muchos núcleos. El objetivo a largo plazo es aprovechar el hardware que ya está disponible en la nube para mejorar la eficiencia y el rendimiento. El cliente admite varias conexiones al mismo tiempo, aceleración por hardware, direccionamiento aleatorio de flujos para distribuir la carga (es decir, garantizar una distribución uniforme del tráfico de red) y numerosos límites entre procesos para ofrecer seguridad adicional entre los componentes.

La eficiencia técnica es uno de los pilares de Frankendancer. El sistema evita las asignaciones de memoria y las operaciones atómicas en la ruta crítica, y optimiza todas las asignaciones para NUMA durante la inicialización. Este diseño garantiza la máxima eficiencia y rendimiento. Además, la capacidad de inspeccionar los componentes del sistema de forma asíncrona y remota, junto con la flexibilidad para administrar los tiles (iniciarlos, detenerlos y reiniciarlos de forma asíncrona), añade robustez y adaptabilidad al sistema.

¿Qué tan bueno es su rendimiento?

Frankendancer puede procesar 1,000,000 de transacciones por segundo (TPS) por tile en el lado de entrada de la red. Este rendimiento escala de forma lineal con la cantidad de núcleos utilizados, ya que cada tile usa 1 núcleo de CPU. Frankendancer logró esta hazaña con solo cuatro núcleos y llevó al límite una tarjeta de interfaz de red (NIC) de 25 Gbps.

Frankendancer ha mejorado considerablemente las operaciones de salida de red mediante sus optimizaciones de Turbine. El hardware estándar actual para nodos alcanza una velocidad de 6 Gbps por tile. Esto incluye mejoras sustanciales de velocidad en el shredding (es decir, la forma en que los datos de un bloque se dividen y se envían a los validadores a través de la red). En comparación con los nodos estándar actuales de Solana, Frankendancer aumenta la velocidad del shredding en ~22% sin árboles de Merkle y casi la duplica con árboles de Merkle. Esto representa una enorme mejora con respecto al rendimiento actual de propagación de bloques e ingestión de transacciones de los validadores.

El rendimiento de red de Firedancer demuestra que alcanzó el límite del hardware. Ha logrado el máximo rendimiento posible con el hardware estándar actual para validadores. Esto marca un hito técnico importante y demuestra la capacidad del cliente para gestionar cargas de trabajo extremas con eficiencia y eficacia.

Frankendancer ya está activo en testnet

Frankendancer actualmente tiene stake, vota y produce bloques en testnet. Coexiste de forma compatible con otros ~2900 validadores de Solana Labs y Jito. Este despliegue en vivo demuestra el sólido rendimiento de Firedancer en hardware convencional. Actualmente se ejecuta en un servidor Equinix Metal m3.large.x86 equipado con una CPU AMD EPYC 7513. Muchos otros validadores usan el mismo tipo de servidor. Ofrece una solución rentable con precios bajo demanda que varían según la ubicación. Las tarifas oscilan entre $3.10 y $4.65 por hora.

El progreso de Firedancer hacia su lanzamiento en mainnet abre varias posibilidades para el hardware de nodos:

• El hardware actual de los validadores puede ofrecer una capacidad de rendimiento mucho mayor por nodo
• La eficiencia de Firedancer permite que los validadores usen hardware más asequible y con especificaciones inferiores sin sacrificar niveles de rendimiento similares
• El diseño de Firedancer le permite aprovechar los avances en hardware y ancho de banda

Estos avances, junto con otras iniciativas como Wiredancer (es decir, los experimentos del equipo de Firedancer con aceleración por hardware) y un Runtime/SVM modular basado en Rust, posicionan a Firedancer como una solución orientada al futuro.

El progreso de Firedancer también abre el debate sobre la posibilidad de que los validadores ejecuten el cliente de Solana Labs junto con Firedancer mediante un proceso conocido como side-caring. Este enfoque podría maximizar la actividad de la red al aprovechar las fortalezas de ambos clientes y mitigar el posible impacto de los problemas de cualquiera de ellos sobre la red en general. Además, esto genera especulaciones sobre si proyectos como Jito considerarían crear un fork de Firedancer. Esto podría dar lugar a nuevas optimizaciones en la extracción de MEV y en la eficiencia del procesamiento de transacciones. Solo el tiempo lo dirá.

Conclusión

Los desarrolladores suelen pensar que las operaciones ocupan espacio de datos, no espacio físico. Al considerar la velocidad de la luz como una limitación natural, esta suposición produce sistemas lentos que no optimizan correctamente su hardware. En un entorno altamente competitivo y adversarial, debemos dejar de agregar más hardware a Solana y esperar que funcione mejor. Necesitamos optimizar. Firedancer revoluciona la estructura y el funcionamiento esperado de los clientes validadores. Al crear un cliente validador confiable, altamente modular y de alto rendimiento, el equipo de Firedancer prepara a Solana para una adopción masiva.

Tanto si eres un desarrollador principiante como un usuario promedio de Solana, es fundamental que comprendas Firedancer y su importancia. Este logro tecnológico mejora aún más la blockchain más rápida y de mayor rendimiento disponible actualmente. Solana está diseñada como una máquina de estados global de alto rendimiento y baja latencia. Firedancer representa un enorme avance hacia el perfeccionamiento de estos objetivos.

Si has leído hasta aquí, ¡gracias, anon! Ingresa tu correo electrónico a continuación para no perderte ninguna novedad sobre Solana. ¿Quieres profundizar? Únete a nuestro Discord y comienza hoy mismo a construir el futuro sobre la blockchain de mayor rendimiento.

Recursos adicionales y lecturas recomendadas

• Sitio web de Jump
• Repositorio de Firedancer en GitHub
• Breakpoint 2023: Actualización de Firedancer
• Breakpoint 2023: Protección de Firedancer
• Breakpoint 2023: Codificación Reed-Solomon rápida para comunicaciones de red
• Breakpoint 2023: FPGA funcionando a 8 millones de TPS
• Hito técnico de fd_quic de Firedancer
• Actualizaciones de la red Solana

Apéndice

Introducción al hardware informático y las redes

Una computadora es una máquina que puede programarse para ejecutar automáticamente secuencias de operaciones aritméticas o lógicas. Estas operaciones abarcan desde la automatización de cálculos básicos hasta el procesamiento complejo de datos. En esencia, una computadora combina componentes de hardware y software para ejecutar instrucciones y gestionar datos. El hardware comprende los componentes físicos, mientras que el software incluye los programas y sistemas operativos que indican al hardware cómo funcionar.

La computación útil suele involucrar cuatro recursos: capacidad de cómputo, memoria, almacenamiento en disco y conectividad de red. El cómputo, gestionado principalmente por CPU, GPU y posiblemente FPGA, es increíblemente rápido y puede realizar miles de millones de operaciones por segundo. Acceder a la RAM suele ser más lento que realizar un cálculo en la CPU. El almacenamiento en disco ofrece una solución a largo plazo útil para la computación. Sin embargo, acceder a datos desde unidades de estado sólido (SSD) y unidades de disco duro (HDD) es mucho más lento que las operaciones de la CPU. Las SSD suelen ser miles de veces más lentas y las HDD, decenas de miles de veces más lentas. Además, la red, incluidos Internet y las redes locales, es el componente más lento. Puede llegar a ser más de un millón de veces más lenta que la CPU.

Comprender estas diferencias de velocidad es crucial para entender los principios de diseño y las consideraciones de eficiencia en aplicaciones informáticas de alto rendimiento como Firedancer. La velocidad de cálculo de la CPU establece el punto de referencia. La memoria, el almacenamiento en disco y el acceso a la red agregan cada uno una capa de demora, en orden decreciente de velocidad.

Unidad central de procesamiento (CPU)

La CPU, o unidad central de procesamiento, es la piedra angular del funcionamiento de una computadora: es el cerebro de la máquina. La CPU ejecuta instrucciones de software, realiza cálculos y toma decisiones según los datos que recibe. Funciona mediante el procesamiento de señales binarias, que son secuencias de ceros y unos. Cada serie única de códigos binarios corresponde a una instrucción específica que la CPU interpreta y ejecuta. Estas instrucciones se gestionan de forma secuencial: la CPU completa una operación antes de pasar a la siguiente. Este procesamiento secuencial de instrucciones es esencial para la función de la CPU, ya que determina cómo realiza cálculos complejos y toma decisiones según los datos que recibe.

Las CPU modernas suelen tener varios núcleos. Esto significa que contienen varias unidades de procesamiento dentro de un solo chip, conocidas como núcleos. Cada núcleo puede ejecutar instrucciones de forma independiente, lo que permite procesar tareas en paralelo. La arquitectura multinúcleo mejora la capacidad de la CPU para gestionar operaciones simultáneas y aumenta considerablemente el rendimiento general. Sin embargo, es importante señalar que las operaciones dentro de cada núcleo aún se procesan de forma secuencial. Por eso, las CPU son adecuadas para tareas complejas y secuenciales, pero resultan ineficientes para grandes volúmenes de tareas más sencillas y paralelas.

Las CPU también tienen cachés: pequeñas unidades de memoria de alta velocidad dentro de la CPU. Estas cachés almacenan datos e instrucciones a los que se accede con frecuencia, lo que permite recuperarlos más rápido que desde la RAM. Normalmente hay varios niveles de caché (L1, L2, L3 y, a veces, L4), cada uno con distintos tamaños y velocidades. Primero se accede a la caché L1, que es la más pequeña y rápida. Si los datos necesarios no están allí, la CPU consulta la caché L2, que es más grande y ligeramente más lenta, y así sucesivamente. Este sistema jerárquico de caché reduce el tiempo que la CPU espera por los datos de la RAM y mejora la velocidad general de procesamiento. El uso eficiente de la caché tiene profundas implicaciones para una aplicación como Firedancer, donde la distancia entre la CPU y la RAM puede afectar el rendimiento. Esto cobra especial relevancia al hablar de la velocidad de la luz y del uso de FPGA.

Como dato adicional, el término “x86” se refiere a una familia de CPU que sigue una arquitectura específica desarrollada originalmente por Intel. Esta arquitectura es conocida por su compatibilidad con una amplia variedad de software, ya que la mayoría de las computadoras de escritorio y portátiles vendidas se basan en la familia de arquitecturas x86.

Unidad de procesamiento gráfico (GPU)

La GPU es un procesador especializado que se desarrolló inicialmente para acelerar el renderizado de imágenes y videos en gráficos informáticos. Su función principal es gestionar y mejorar el rendimiento gráfico, en especial en tareas que requieren imágenes de alta resolución y cálculos gráficos complejos, como videojuegos o modelado 3D.

Con el tiempo, la GPU evolucionó más allá de su propósito original. Gracias a su arquitectura, las GPU se han vuelto invaluables para una gama más amplia de tareas de procesamiento de datos. Su capacidad de procesamiento paralelo eficiente las hace adecuadas para aplicaciones que necesitan gestionar grandes conjuntos de datos de forma simultánea. En la tecnología blockchain, las GPU se usan ampliamente para minar criptomonedas. Sobresalen en esta función porque pueden procesar cargas paralelas de cálculos criptográficos con mayor eficiencia que una CPU.

Memoria de acceso aleatorio (RAM)

La RAM es la memoria a corto plazo de una computadora. Almacena los datos que se utilizan o procesan activamente. Allí, la CPU “recuerda” en qué está trabajando y conserva la información relevante para acceder a ella y procesarla con rapidez.

La RAM con código de corrección de errores (ECC) puede detectar y corregir tipos comunes de corrupción interna de datos. Esta característica es fundamental en entornos donde la precisión de los datos es importante, como la computación científica, las transacciones financieras o los nodos de blockchain. La RAM ECC puede identificar y corregir automáticamente errores menores en los datos que almacena. Este proceso de corrección se realiza mediante hardware adicional en los módulos de RAM que verifica los datos almacenados.

La RAM sin ECC es el tipo de memoria más utilizado en computadoras estándar y dispositivos de consumo. Aunque no cuenta con las capacidades de corrección de errores de la RAM ECC, suele ser más rápida y económica. La RAM sin ECC se prefiere para usos generales por su rentabilidad y el riesgo relativamente bajo de errores de datos en la computación de escritorio estándar.

Almacenamiento en disco

El almacenamiento en disco conserva los datos a largo plazo, incluso cuando la computadora está apagada. Hay dos tipos principales de almacenamiento en disco: las unidades de disco duro (HDD) y las unidades de estado sólido (SSD).

Las HDD son unidades de disco más antiguas que almacenan datos en discos magnéticos conocidos como platos. Los platos se combinan con cabezales magnéticos, normalmente conectados a un brazo actuador móvil. Un cabezal de lectura y escritura ubicado en este brazo accede a los datos mientras gira el disco. La naturaleza mecánica de las HDD —discos que giran y cabezales que se mueven— las hace relativamente más lentas que las SSD. Sin embargo, ofrecen más capacidad de almacenamiento a un precio menor. Esto las convierte en una opción rentable para el almacenamiento masivo.

Por otro lado, las SSD usan memoria flash para almacenar datos. La memoria flash es una solución electrónica de almacenamiento no volátil que puede borrarse y reprogramarse. A diferencia de las HDD, el uso de memoria flash elimina las piezas móviles. En su lugar, chips de memoria flash interconectados almacenan los datos. Las SSD son más rápidas que las HDD porque pueden acceder a los datos de inmediato, sin esperar a que un disco gire o a que un cabezal de lectura y escritura encuentre la información. Esta velocidad convierte a las SSD en una excelente opción para aplicaciones donde es crucial recuperar datos rápidamente. Sin embargo, esta velocidad tiene un costo por gigabyte mayor que el de las HDD.

También existen las SSD NVMe (Non-Volatile Memory Express). Estas SSD están diseñadas para aprovechar su potencial de alta velocidad mediante el bus Peripheral Component Interconnect Express (PCIe) de una computadora. Las unidades NVMe ofrecen velocidades considerablemente mayores y menor latencia que las SSD tradicionales. Son ideales para cargas de trabajo intensivas, como las operaciones de alta frecuencia y las aplicaciones de blockchain, donde es fundamental procesar y recuperar datos con rapidez. Aunque las NVMe tienen un precio elevado, están empezando a convertirse en el estándar de la computación de alto rendimiento.

Placa base

Fuente: Diagrama de una Gigabyte X570 Elite tomado de una publicación de Reddit en r/buildapc

La placa base de una computadora es una gran tarjeta de circuitos que interconecta los componentes y facilita la comunicación entre ellos. Estos componentes incluyen la CPU, la GPU, la RAM, los dispositivos de almacenamiento y periféricos como teclados y ratones.

La placa base es el centro principal de actividad. Garantiza que cada componente pueda comunicarse de manera eficaz con los demás. También es fundamental para distribuir la energía, ya que dirige la electricidad desde la fuente de alimentación hacia cada componente principal. La placa base garantiza que cada componente reciba la energía adecuada para funcionar.

La placa base gestiona el flujo de datos dentro del sistema. Supervisa el envío de datos desde la CPU hacia la RAM para procesarlos, desde la RAM hacia los dispositivos de almacenamiento para guardarlos y desde la GPU hacia las salidas de pantalla para generar imágenes. Además, la placa base aloja el BIOS (sistema básico de entrada y salida) del sistema. El BIOS es esencial para controlar y supervisar el sistema. Inicializa y prueba el hardware de una computadora durante el arranque. También controla el estado del sistema mediante factores como la temperatura, el voltaje y la velocidad de los ventiladores.

En el diseño de Firedancer, la arquitectura de la placa base cumple una función crucial. La proximidad entre la CPU y la RAM tiene un impacto considerable en el rendimiento, ya que una menor distancia mejora la velocidad de transferencia de datos. Esta distancia es esencial para aplicaciones como Firedancer, que exigen un alto rendimiento y baja latencia. Por eso, una arquitectura consciente de NUMA y el posible uso de FPGA se ajustan a la necesidad de Firedancer de optimizar la asignación de memoria y la eficiencia del procesamiento. Más adelante en este artículo explicaremos qué significa que una arquitectura sea consciente de NUMA y qué son las FPGA.

Sistemas operativos, máquinas virtuales y optimizaciones a nivel del kernel

Un sistema operativo (SO) es el software central que gestiona el hardware y el software de una computadora. Actúa como intermediario y facilita las interacciones entre el usuario y el hardware. Proporciona una interfaz para interactuar con el sistema, además de asignar y gestionar recursos para distintas aplicaciones. Algunos ejemplos populares son Windows, macOS y Linux.

El kernel está en el centro de todo sistema operativo. Es un componente crucial que interactúa directamente con el hardware del sistema. El kernel tiene control absoluto sobre todo el sistema. Gestiona la asignación de memoria, la programación de procesos y las solicitudes de entrada y salida. Al funcionar en este nivel bajo, el kernel cumple una función esencial en el rendimiento y la estabilidad del sistema.

Las llamadas al sistema (syscalls) conectan las aplicaciones de usuario con el kernel. Cuando una aplicación necesita realizar una operación que requiere acceso a un recurso del sistema, como leer un archivo o enviar datos por la red, hace una syscall. Luego, el kernel realiza la operación solicitada en nombre de la aplicación. Este mecanismo garantiza un acceso controlado a los recursos para mantener la seguridad y la estabilidad del sistema.

Las máquinas virtuales (VM) son emulaciones de software de computadoras físicas. Replican todas las funciones de una computadora física en un entorno aislado y operan sobre un hipervisor, es decir, un tipo de software que crea y gestiona entornos virtuales en una máquina anfitriona. Las VM ofrecen seguridad mediante el aislamiento, eficiencia en el uso de recursos y flexibilidad para las pruebas y el desarrollo.

Comprender estos conceptos es crucial en el contexto de Firedancer. Firedancer aplica varias optimizaciones a nivel del kernel para mejorar el rendimiento:

• Gran asignación estática: Firedancer minimiza las asignaciones dinámicas de memoria mediante grandes asignaciones estáticas, es decir, asignaciones de memoria compartida que otros procesos pueden utilizar. La memoria se asigna una sola vez y se reutiliza, lo que reduce la sobrecarga asociada con asignaciones y liberaciones frecuentes.
• Omisión de bibliotecas estándar: Las funciones de las bibliotecas estándar suelen agregar capas adicionales de abstracción y pueden ser menos eficientes para ciertas operaciones. Firedancer omite estas bibliotecas estándar y realiza syscalls directamente. Profundizaremos en este tema cuando hablemos de la arquitectura de tiles de Firedancer y de cómo optimiza el rendimiento de red.

Firedancer intenta evitar las syscalls y la interacción con el SO tanto como sea posible, ya que estas operaciones ralentizan considerablemente las tareas.

Entrada y salida

Entrada y salida son términos que describen el flujo de datos hacia dentro y fuera de un sistema informático o una red.

La entrada se refiere al ingreso de datos a un sistema. Es un término general que puede incluir diversas actividades, como recibir datos de Internet, aceptar entradas de usuarios o recopilar información de sensores en dispositivos de IoT (Internet de las cosas). En sistemas de red como servidores o blockchains, la entrada incluye tareas críticas como recibir solicitudes de transacciones, consultas de usuarios o flujos de datos entrantes que deben procesarse o almacenarse. Gestionar eficientemente los datos de entrada es fundamental para la capacidad de respuesta y el funcionamiento del sistema.

La salida se refiere a los datos que salen de un sistema. Esto incluye enviar información en línea, generar respuestas a solicitudes de usuarios o transmitir datos procesados a otros sistemas. En los sistemas conectados a una red, la salida implica enviar transacciones validadas, difundir actualizaciones de la blockchain o enviar datos a ubicaciones de almacenamiento externas. Gestionar correctamente los datos de salida es esencial para distribuir la información de forma adecuada y garantizar que el sistema se comunique eficazmente con otras partes de la red.

Pipelines y paralelismo de datos

Imagina un pipeline como una línea de montaje en una fábrica. Divide un proceso complejo en etapas secuenciales más pequeñas. Cada etapa del pipeline realiza una operación específica. Este enfoque es muy eficiente para tareas de procesamiento repetitivas o continuas, de forma similar a cómo una blockchain procesa transacciones continuamente.

El paralelismo de datos adopta un enfoque diferente: procesa varios elementos de forma simultánea, pero independiente. Es como si la fábrica tuviera más de una línea de montaje para procesar datos. Esto resulta eficaz para tareas que pueden dividirse en subtareas más pequeñas. En las blockchains, específicamente en sistemas como Firedancer, el paralelismo de datos es crucial para gestionar transacciones o tareas de procesamiento de datos al mismo tiempo. Las capacidades de procesamiento paralelo de Firedancer maximizan el rendimiento computacional y reducen los tiempos de procesamiento.

Imagina cada etapa del pipeline como una estación de trabajo individual en una fábrica. Cada estación puede funcionar de forma independiente y simultánea. Esto significa que, mientras una etapa procesa una parte de los datos, la siguiente puede trabajar con otra parte al mismo tiempo. Este enfoque permite que varias etapas del pipeline estén activas simultáneamente, lo que aumenta de forma considerable el rendimiento. Firedancer combina la eficiencia secuencial de los pipelines con la capacidad de procesamiento simultáneo del paralelismo para procesar grandes volúmenes de transacciones.

Matriz de puertas lógicas programable en campo (FPGA)

Las matrices de puertas lógicas programables en campo (FPGA) son circuitos integrados versátiles que pueden programarse o reconfigurarse después de su fabricación. Estos circuitos ofrecen un nivel de adaptabilidad que no existe en los componentes de hardware tradicionales. Constan de una amplia cuadrícula de bloques lógicos programables e interconectados, cada uno capaz de realizar diversas funciones digitales. Este diseño permite que las FPGA sean muy flexibles y eficientes en aplicaciones donde la velocidad, el procesamiento paralelo y la adaptabilidad son fundamentales.

Una FPGA típica consta de pequeños elementos programables, todos conectados mediante cables programables. Esta compleja red de componentes y conexiones permite programar diferentes regiones del chip para realizar tareas específicas. Así se crea un entorno de procesamiento completamente personalizado.

Las FPGA sobresalen en el procesamiento paralelo porque utilizan estos pequeños elementos programables de forma simultánea. Su estructura facilita el uso eficiente de pipelines, donde los datos atraviesan continuamente las etapas de procesamiento. Un pipeline bien diseñado desacopla el rendimiento del sistema de la latencia. Aunque este pipeline puede tardar más en producir resultados que una CPU convencional, el sistema puede gestionar varios flujos de datos de entrada al mismo tiempo. La latencia de cada operación tiene poco impacto en el flujo general de datos, como el agua que circula por una manguera.

En el contexto de Firedancer, las FPGA ofrecen una ventaja considerable. Pueden conectar pipelines de datos directamente a las redes. Las FPGA son más eficientes para gestionar el tráfico de red que las configuraciones tradicionales, donde las GPU dependen de las CPU para mover los datos. La conectividad directa y la capacidad de crear soluciones de procesamiento personalizadas, como implementar procesadores soft en la estructura de la FPGA, las hacen invaluables para desarrollar un cliente validador de alto rendimiento.

‍