Turbine: propagación de bloques en Solana

¿De qué trata este artículo?

La disponibilidad de datos es fundamental para las blockchains. Garantiza que los nodos puedan acceder fácilmente a toda la información necesaria para la validación, lo que mantiene la integridad y seguridad de la red. Sin embargo, garantizar la disponibilidad de datos y, al mismo tiempo, mantener un alto rendimiento es un gran desafío, especialmente a medida que las redes escalan.

Solana ha respondido a este desafío con un diseño arquitectónico único que permite crear y propagar bloques de forma continua. Esto es posible gracias a varias innovaciones clave, como la selección de líderes, Gulf Stream (que elimina la necesidad de un mempool) y Turbine (el mecanismo de propagación de bloques).

La naturaleza continua de Solana exige un sistema eficiente que garantice que todos los validadores reciban rápidamente el estado más actualizado. Un enfoque sencillo consistiría en que el líder transmitiera todos los bloques directamente a cada uno de los demás validadores. Sin embargo, debido al alto rendimiento de Solana, este método aumentaría considerablemente los requisitos de ancho de banda y otros recursos, además de perjudicar la descentralización.

El ancho de banda es un recurso escaso, y Turbine es la ingeniosa solución de Solana para optimizar la propagación de información desde el líder de un bloque determinado hacia el resto de la red. Turbine se diseñó específicamente para reducir la carga de salida (envío de datos) del líder hacia la red.

En este artículo, profundizaremos en el funcionamiento de Turbine y en su papel fundamental dentro del panorama general de inclusión de transacciones en Solana. También compararemos Turbine con otras soluciones de disponibilidad de datos y analizaremos líneas de investigación abiertas en este ámbito.

¿Qué es Turbine?

Turbine es un mecanismo multicapa de propagación de bloques que utiliza un clúster de Solana para transmitir entradas del registro a todos los nodos. Las ideas centrales de Turbine han estado presentes en el ámbito académico durante muchos años, como demuestran este artículo publicado en 2004 y otros trabajos más recientes.

A diferencia de las blockchains tradicionales, donde un bloque se envía a todos los nodos de forma secuencial o mediante inundación, Turbine adopta un enfoque más estructurado para minimizar la sobrecarga de comunicación y reducir la carga de los nodos individuales. En términos generales, Turbine divide un bloque en piezas más pequeñas y las distribuye mediante una jerarquía de nodos. Así, un nodo individual no necesita estar en contacto con todos los demás, sino que solo debe comunicarse con unos pocos nodos seleccionados. Esto cobra cada vez más importancia conforme crece la red, ya que los métodos tradicionales de propagación se volverían insostenibles por el enorme volumen de comunicaciones necesarias. De este modo, Turbine garantiza una distribución rápida y eficiente de los datos en Solana. La velocidad con la que se propagan y verifican los bloques es crucial para mantener el alto rendimiento y la seguridad de la red de Solana.

Además, Turbine aborda el problema de la disponibilidad de datos y garantiza que todos los nodos puedan acceder de forma eficiente a los datos necesarios para validar transacciones. Lo consigue sin requerir una cantidad enorme de ancho de banda, un cuello de botella común en otras redes blockchain.

Turbine contribuye significativamente a la capacidad de Solana para procesar grandes volúmenes de transacciones y mantener una estructura de red ágil y eficiente. Para ello, reduce los cuellos de botella del ancho de banda y garantiza una rápida propagación de bloques. Este innovador protocolo es uno de los pilares que permiten que Solana cumpla su promesa de ser una red rápida, segura y escalable.

Ahora profundicemos en la mecánica de Turbine y en cómo propaga bloques por la red de Solana.

¿Cómo propaga Turbine los bloques?

Antes de propagar un bloque (es decir, transmitirlo a otros validadores de la red), el líder lo construye y ordena a partir del flujo de transacciones entrantes. Una vez construido, el bloque está listo para enviarse mediante Turbine al resto de la red. Este proceso se denomina propagación de bloques. Después, los validadores intercambian mensajes de voto, que se encapsulan en los datos del bloque para alcanzar el estado de compromiso “confirmed” o “finalized”. Un bloque confirmado es un bloque que ha recibido una supermayoría de votos del registro, mientras que un bloque finalizado es uno que ha sido confirmado y sobre el cual se han construido 31 o más bloques confirmados. La diferencia entre los estados de compromiso se explica con más detalle aquí. Esta parte del consenso se analizará en una publicación futura.

Aunque los líderes construyen y proponen bloques completos, los datos reales se envían como shreds (bloques parciales) a otros validadores de la red. Los shreds son las unidades atómicas que se envían entre validadores.

En términos generales, Turbine toma los shreds y los envía a un conjunto predeterminado de validadores, que luego los retransmiten a un nuevo conjunto de validadores. El siguiente diagrama presenta el proceso continuo de propagación de shreds:

En este ejemplo, el Validador 1 es el líder designado del slot. Durante su slot (los validadores se asignan como líderes durante 4 slots consecutivos), el Validador 1 construye y propone un bloque. Primero, divide el bloque en subbloques llamados shreds mediante un proceso denominado shredding. El shredding divide los datos del bloque en data shreds del tamaño de una unidad máxima de transmisión (MTU), es decir, la cantidad máxima de datos que puede enviarse de un nodo al siguiente sin fragmentarla en unidades más pequeñas, y genera los recovery shreds correspondientes mediante el esquema de codificación de borrado Reed-Solomon. Este esquema facilita la recuperación de datos y garantiza su integridad durante la transmisión, algo crucial para mantener la seguridad y confiabilidad de la red.

Este proceso de shredding y propagación garantiza una distribución rápida y eficiente de los datos de bloques en Solana, a la vez que mantiene un alto rendimiento y la seguridad de la red.

Codificación de borrado

Antes de propagarse por el árbol de Turbine, los shreds se codifican mediante la codificación de borrado Reed-Solomon, un esquema de detección y corrección de errores basado en polinomios. La codificación de borrado se usa como método de protección de datos para poder recuperar los datos originales aunque algunas partes se pierdan o corrompan durante la transmisión. La codificación de borrado Reed-Solomon es un tipo específico de algoritmo de corrección de errores hacia adelante (FEC).

Como Turbine depende principalmente de una serie de retransmisiones de paquetes realizadas por validadores posteriores, estos podrían actuar de forma maliciosa (nodos bizantinos adversarios) y retransmitir datos incorrectos, o podrían recibir datos incompletos debido a la pérdida de paquetes de red. Debido a la estructura de árbol de retransmisión de Turbine, cualquier pérdida de paquetes en toda la red se acumula, y la probabilidad de que un paquete no llegue a su destino aumenta con cada salto.

En términos generales, si el líder transmite el 33 % de los paquetes del bloque como códigos de borrado, la red puede perder cualquier 33 % de los paquetes sin perder el bloque. Los líderes pueden ajustar este número de forma dinámica (la tasa FEC) según las condiciones de la red. Para ello, consideran variables como la pérdida de paquetes observada recientemente en toda la red y la profundidad del árbol.

Para simplificar, examinemos un grupo de shreds con una tasa FEC de 4:4.

Los data shreds son bloques parciales del bloque original construido por el líder, mientras que los recovery shreds son los bloques con codificación de borrado generados mediante Reed-Solomon.

Los bloques de Solana suelen utilizar una tasa FEC de 32:32 (se pueden perder 32 de 64 paquetes sin necesidad de retransmitirlos). Como se describe en la documentación de Solana, se aplican los siguientes supuestos conservadores sobre la red:

• Tasa de pérdida de paquetes del 15 %
• 50 000 TPS que generan 6400 shreds por segundo

Una tasa FEC de 32:32 produce una tasa de éxito de bloques de ~99 %. Además, los líderes pueden aumentar la tasa FEC si desean incrementar la probabilidad de éxito de un bloque.

Actualmente, Turbine utiliza UDP para propagar bloques, lo que ofrece enormes ventajas de latencia. Según un operador de validadores, transmitir 6 MB más los datos correspondientes a la codificación de borrado desde us-east-1 hasta eu-north-1 mediante UDP toma 100 ms, mientras que con TCP toma 900 ms.

Árbol de Turbine

Un árbol de Turbine es una topología de red estructurada que Solana utiliza para facilitar la propagación eficiente de shreds (datos de bloques codificados) entre validadores. Una vez que los shreds se codifican correctamente en sus respectivos grupos, están listos para distribuirse por el árbol de Turbine e informar a los demás validadores de la red sobre el estado más actualizado.

Cada grupo de shreds se envía mediante un paquete de red a un nodo raíz especial, que determina qué validadores forman parte de la primera capa (a 1 salto de distancia). Después se ejecutan los siguientes pasos:

1. Creación de la lista: El nodo raíz agrupa todos los validadores activos en una lista, que luego se ordena según el stake de cada validador en la red. Los validadores con mayor peso de stake tienen prioridad para recibir antes los shreds, lo que les permite responder más rápido con sus propios mensajes de voto para el consenso.
2. Mezcla de la lista: Después, esta lista se mezcla de forma determinista. Esto crea un “árbol de Turbine” generado a partir del conjunto de nodos validadores para cada shred. Utiliza una semilla derivada del id del líder del slot, el slot, el índice del shred y el tipo de shred. Se genera un nuevo árbol en tiempo de ejecución para cada grupo de shreds con el fin de reducir los posibles riesgos de seguridad asociados con una estructura de árbol estática.
3. Formación de capas: Después, los nodos se dividen en capas, comenzando desde la parte superior de la lista. La división se basa en el valor DATA_PLANE_FANOUT, que determina la amplitud y profundidad del árbol de Turbine. Este valor influye en la rapidez con la que los shreds pueden propagarse por la red. Actualmente, el valor de DATA_PLANE_FANOUT es 200, por lo que la mayoría de los validadores están a solo 2 o 3 saltos de distancia (líder -> raíz -> L1 -> L2).

Como todos conocen el árbol de Turbine, cada validador sabe exactamente dónde debe retransmitir ese shred. El árbol de Turbine suele tener 2 o 3 saltos, según el número de validadores activos, dado el valor actual de DATA_PLANE_FANOUT de 200.

Además, los nodos pueden recurrir a gossip y reparación si no reciben suficientes shreds o si la tasa de pérdida supera la tasa FEC. Con la implementación actual, un nodo que no tiene suficientes shreds para reconstruir el bloque envía una solicitud de retransmisión al líder. Con Turbine determinista, cualquier nodo que haya recibido el bloque completo puede enviar los shreds de reparación que necesite el nodo solicitante. Esto impulsa la transmisión de datos hacia las zonas inferiores del árbol que solicitan datos.

Comparación de la propagación de bloques entre Solana y Ethereum

La propagación de bloques en Solana difiere de la de Ethereum. Estas son algunas diferencias generales:

• Los requisitos ideales de ancho de banda de Solana (>1 Gbps) son considerablemente mayores que los de Ethereum (geth recomienda >25 Mbps). Este mayor requisito de ancho de banda se debe a que Solana tiene bloques más grandes y tiempos de bloque más cortos. El diseño de Solana permite aprovechar eficazmente todo el ancho de banda para acelerar la transmisión de datos y reducir la latencia. Aunque se producen picos de ancho de banda de hasta 1 Gbps, no se utiliza 1 Gbps de forma constante. La arquitectura de Solana permite específicamente estos picos en la demanda de ancho de banda.
• Solana emplea Turbine para propagar los datos de bloques, mientras que Ethereum utiliza un protocolo gossip estándar. En Ethereum, la propagación de datos de bloques se realiza de forma directa: cada nodo se comunica con todos los demás nodos completos de la red. Cuando aparece un bloque nuevo, los clientes lo verifican enviándolo a sus pares y aprobando las transacciones incluidas en él. Este mecanismo es adecuado para Ethereum porque sus bloques son más pequeños y sus tiempos de bloque son más largos que los de Solana. En el caso de los datos de rollups L2 de Ethereum, sin incluir los validiums, la propagación también sigue el protocolo gossip y los datos de bloques se almacenan en el campo “calldata” de los bloques L1 de Ethereum.
• Ethereum utiliza TCP, mediante el protocolo DevP2P, para propagar bloques, mientras que Solana utiliza UDP (con cierto apoyo de la comunidad para migrar a QUIC). Existen algunas ventajas y desventajas que deben considerarse al comparar UDP y QUIC:
• La unidireccionalidad de UDP produce una latencia menor que QUIC, que requiere streams QUIC. Continúan los debates sobre la implementación de streams unidireccionales en QUIC.
• Quienes promueven QUIC afirman que, aunque es posible implementar un flujo de control personalizado sobre UDP, esto exige un gran esfuerzo de ingeniería. QUIC reduce ese esfuerzo al admitir estas funciones de forma nativa. El objetivo final es el mismo, pero el límite superior del rendimiento de QUIC —latencia, rendimiento, etc.— equivale al estado actual de UDP puro.

Estas diferencias subrayan las decisiones arquitectónicas únicas que adoptaron Solana y Ethereum, las cuales contribuyen al rendimiento, escalabilidad y solidez de cada red. Para consultar un análisis más detallado de TCP, UDP y QUIC, lee nuestro artículo sobre Solana y QUIC.

Preguntas para futuras investigaciones

La propagación de bloques y la disponibilidad de datos siguen siendo áreas de investigación abiertas, con numerosos equipos que desarrollan sus propios enfoques. Aunque las métricas pueden evolucionar, queremos ofrecer una visión general de los distintos enfoques y sus ventajas y desventajas:

• Han surgido algunos debates sobre la posición de Turbine como mecanismo de “disponibilidad de datos” (DA). Turbine funciona como mecanismo de disponibilidad de datos en el sentido de que todos los datos del bloque se publican y todos los demás validadores de Solana los descargan. Sin embargo, Turbine no admite el muestreo de disponibilidad de datos (DAS), una función que ayuda a los nodos ligeros a verificar el estado con menores requisitos de hardware. Este es un enfoque activo de desarrollo para equipos como Celestia. Al igual que Turbine, DAS también utiliza códigos de borrado, pero lo hace con el propósito expreso de detectar y prevenir ataques de retención de datos.
• Para las L2 de Solana Virtual Machine (SVM), como Eclipse, Turbine pierde relevancia porque no existe un conjunto de validadores entre los cuales transmitir datos. En el caso de Eclipse, los datos de bloques se publican en Celestia para garantizar su disponibilidad. Esto permite que observadores externos ejecuten pruebas de fraude para garantizar que la ejecución y las transiciones de estado sean correctas. Eclipse será una de las primeras implementaciones de SVM fuera de la propia red de Solana. Pyth también creó un fork de SVM para su propia red de oráculos llamada “Pythnet” y, en la práctica, funciona como su propia sidechain.
• En Solana, los nodos completos gestionan la propagación de bloques y, al mismo tiempo, participan en otros segmentos de la pila blockchain integrada, como el ordenamiento de transacciones y el consenso. ¿Cuáles serían las métricas cuantitativas de Turbine si funcionara como un componente modular sobre hardware especializado?
• Turbine prioriza los nodos con mayor peso de stake para que reciban primero los datos de bloques. ¿Esto provocará una mayor centralización de MEV con el tiempo?
• ¿Cómo se compararán en producción los distintos enfoques de disponibilidad de datos, como EigenDA —un único retransmisor unicast escalable horizontalmente— y Celestia —muestreo de disponibilidad de datos— con Turbine en términos de rendimiento bruto y minimización de la confianza?
• Firedancer busca aumentar aún más la propagación de datos y está optimizado para una conexión sólida con un ancho de banda de 10 Gbps. ¿Cómo funcionarán en producción las optimizaciones a nivel de sistema que realizaron en torno a Turbine, tanto con hardware de consumo como con hardware profesional?
• Actualmente, todos los nodos de Solana son nodos completos; las implementaciones de clientes ligeros aún están en desarrollo. Sreeram Kannan (EigenLayer) describió recientemente una implementación de DAS-S sobre Turbine. ¿Se admitirá alguna versión de DAS para Turbine? ¿Se pueden implementar clientes ligeros con DAS que mantengan un alto rendimiento de datos y, al mismo tiempo, satisfagan la minimización de la confianza con requisitos de recursos mucho menores?

Conclusión

¡Felicidades! En este artículo analizamos Turbine y cómo funciona dentro del panorama general de inclusión de transacciones de Solana. Comparamos Turbine con otras soluciones de disponibilidad de datos y analizamos las distintas líneas de investigación abiertas en este ámbito. El protocolo Turbine de Solana demuestra el compromiso de la red con alcanzar un alto rendimiento y una baja latencia mediante una topología de red estructurada que distribuye eficientemente los datos de bloques entre validadores.

La búsqueda de formas de mejorar la disponibilidad de datos y hacer más eficiente la propagación de bloques impulsa la innovación en toda la comunidad blockchain. El análisis comparativo de los mecanismos de propagación de bloques de Solana y Ethereum revela sus fortalezas y ventajas y desventajas particulares. También inspira una conversación más profunda sobre cómo las nuevas soluciones blockchain, como EigenDA, Celestia y Firedancer, podrían definir este ecosistema en el futuro.

La solución para una propagación eficiente y la disponibilidad de datos está lejos de estar completa. Sin embargo, el enfoque de Solana y su firme compromiso con optimizar el rendimiento de la red sin comprometer la seguridad ni la minimización de la confianza son muy bien recibidos.

Gracias a @dubbel06 y @jon_charb por la revisión y los comentarios.

Recursos adicionales / Lecturas complementarias

• Propagación de bloques con Turbine
• Introducción a la codificación de borrado
• Bloques de Ethereum
• Actualización de la red Pyth Perseus
• Introducción a EigenDA: disponibilidad de datos a hiperescala para rollups
• Firedancer