Solana presume de procesar miles de transacciones por segundo. Pero esa cifra no tiene sentido si los validadores no reciben los bloques a tiempo ni se ponen de acuerdo sobre cuál es el válido. Ahí entran dos protocolos que poca gente nombra: Turbine y Tower. El primero resuelve la propagación de datos. El segundo, el consenso.
Entender cómo funcionan explica tanto el rendimiento de la red como buena parte de sus puntos débiles.
El problema de escalar sin romper la red
Cuando una blockchain crece, propagar un bloque a todos los nodos se vuelve caro. Si el líder (el validador que produce el bloque en ese turno) tuviese que enviarlo directamente a cada uno de los otros 1.000 o 2.000 validadores activos, el ancho de banda que necesitaría sería enorme. Con bloques que llegan cada 400 milisegundos, eso es inviable.
Bitcoin y Ethereum resuelven este problema en parte limitando el tamaño del bloque o la frecuencia de producción. Solana tomó otro camino: diseñó un protocolo de propagación inspirado en cómo funciona BitTorrent.
Turbine: propagación por capas
Turbine divide cada bloque en fragmentos pequeños llamados shreds (astillas). Un bloque típico de Solana se divide en decenas o cientos de shreds, cada uno con su propio código de corrección de errores. Esto significa que no hace falta recibir el 100% de los shreds para reconstruir el bloque completo.
La distribución funciona en capas. El líder envía shreds a un primer grupo de validadores. Cada uno de esos validadores reenvía los shreds que ha recibido a otro grupo más pequeño, y así sucesivamente. La red forma una estructura de árbol, con capas que Solana llama neighborhoods (vecindarios).
Cada validador pertenece a un vecindario concreto según su participación (stake). Los que tienen más stake ocupan capas más altas del árbol, lo que les permite recibir datos antes. Esto tiene una consecuencia directa: un validador con mucho stake y buena conexión propaga información más rápido, lo que refuerza su posición en la red.
El beneficio de este diseño es claro. El líder no satura su conexión enviando el bloque completo a todos. La carga se distribuye entre los validadores de la capa superior. En la práctica, Turbine permite que la red propague bloques pesados sin que el ancho de banda del líder sea el cuello de botella.
Qué pasa cuando faltan shreds
Turbine no es infalible. Si un validador no recibe todos los shreds de un bloque dentro del tiempo límite, entra en juego un mecanismo de reparación llamado repair protocol. El validador solicita los shreds que le faltan a sus vecinos. Este proceso añade latencia y, en situaciones de congestión o pérdida de paquetes elevada, puede contribuir a que la red se ralentice o se atasque.
Varios de los episodios de degradación de rendimiento que Solana ha sufrido en el pasado tienen relación con condiciones que saturan la capa de propagación. Las caídas de red en Solana no siempre responden a un fallo único: a veces es la combinación de volumen extremo y propagación deficiente lo que colapsa el consenso.
Tower BFT: el consenso sobre la historia
Una vez que los validadores tienen los datos del bloque, necesitan acordar qué bloque es el correcto y en qué orden. Aquí entra Tower BFT, la variante de Solana del algoritmo de tolerancia a faltas bizantinas (BFT, por sus siglas en inglés).
Tower BFT adapta el algoritmo clásico PBFT (Practical Byzantine Fault Tolerance) para aprovechar Proof of History (PoH). Si quieres entender qué es PoH y por qué importa, el artículo sobre Proof of History: el reloj interno que hace funcionar Solana lo explica desde la base.
La idea central de Tower es que cada validador vota sobre qué bifurcación de la cadena considera válida. Pero esos votos tienen un coste: cuanto más tiempo llevas votando por una bifurcación, más difícil te resulta cambiar de opinión. Tower impone un bloqueo exponencial (lockout). Si votas por un bloque, no puedes votar contra esa rama durante un número de turnos determinado. Cada voto adicional en la misma rama dobla el tiempo de bloqueo.
Esto crea un incentivo económico fuerte para votar por la rama que crees que ganará, porque si apuestas por la equivocada y la red la descarta, pierdes las recompensas del staking de esos turnos. En la práctica, esto acelera la convergencia: los validadores convergen en la bifurcación dominante mucho más rápido que si pudieran cambiar de voto sin coste.
Cómo interactúan Turbine y Tower
Los dos protocolos están pensados para trabajar juntos dentro de los tiempos que impone PoH. Turbine intenta propagar cada bloque en cuestión de milisegundos para que Tower pueda recoger suficientes votos antes de que expire la ventana de ese slot. Si Turbine falla y los validadores no reciben los datos a tiempo, Tower no puede votar, y el slot queda sin confirmar.
Es una arquitectura que funciona bien cuando las condiciones de red son buenas y el volumen es manejable. Cuando ambas variables se deterioran al mismo tiempo, el sistema puede entrar en bucles de recuperación que detienen la producción de bloques. Ese es el origen técnico de las interrupciones más largas que ha vivido la red.
Implicaciones para el staking y los validadores
Si haces staking en Solana, la elección del validador importa más de lo que parece. Un validador con baja participación (stake) ocupa capas bajas en el árbol de Turbine, recibe los shreds más tarde y tiene más probabilidad de votar fuera de tiempo en Tower. Votar tarde o no votar reduce las recompensas que ese validador distribuye entre sus delegantes.
La guía sobre cómo hacer staking en Solana detalla los criterios para elegir validador, incluyendo la tasa de comisión y el historial de votos. La arquitectura de Turbine y Tower añade otro criterio: la posición del validador en la red y su conectividad real.
Fortalezas y límites del diseño
Turbine y Tower permiten a Solana operar a velocidades que no serían posibles con un diseño de propagación convencional. La fragmentación en shreds reduce la presión sobre el líder. El lockout exponencial de Tower acelera el consenso sin necesitar rondas de comunicación adicionales entre todos los validadores.
Pero el diseño tiene límites reconocidos. La dependencia del ancho de banda es alta: un validador con conexión lenta participa en condiciones de desventaja. La estructura de árbol de Turbine favorece a los validadores con más stake, lo que refuerza la concentración de influencia en los nodos más grandes. Y la velocidad del sistema entero depende de que la capa de propagación funcione de forma sostenida, sin picos de pérdida de paquetes.
Son concesiones de diseño. Solana las tomó conscientemente para priorizar el rendimiento. Conocerlas te da una imagen más honesta de lo que la red puede y no puede garantizar.
⚠ La información de este artículo tiene fines educativos y no constituye asesoramiento financiero, fiscal ni legal. Las criptomonedas son activos volátiles y puedes perder todo el capital invertido. Consulta con un profesional antes de tomar decisiones.