Gulf Stream de Solana: más mempool, más problemas

Conclusiones prácticas

• El término "Gulf Stream" puede definirse, a grandes rasgos, como el proceso que ocurre desde que un nodo recoge una transacción de la red hasta que esta llega al líder del slot actual y la recibe la etapa Fetch de la TPU (Unidad de Procesamiento de Transacciones).
• Solana destaca porque se diseñó desde el principio para operar sin mempool. A diferencia de las blockchains más tradicionales, que usan protocolos de gossip para propagar ampliamente las transacciones por la red, Solana reenvía todas las transacciones a un validador líder predeterminado, conocido como el líder, para cada slot. El líder cambia cada 4 slots y todos los nodos activos de la red conocen de antemano el cronograma de líderes, lo que garantiza un reenvío eficiente de las transacciones.
• De forma predeterminada, las transacciones de Solana deben incluir un blockhash reciente, que los desarrolladores pueden solicitar fácilmente mediante una simple llamada a la API. Un blockhash reciente es válido durante un máximo de 150 slots (aproximadamente 1 minuto). Después de este periodo, queda obsoleto y la red descarta las transacciones que hacen referencia a él. Esto evita que las transacciones sin procesar permanezcan pendientes. Los blockhashes recientes también ayudan a deduplicar transacciones. Los desarrolladores también disponen de métodos para agregar nonces duraderos.
• Las transacciones en Gulf Stream se codifican y envían al líder mediante streams QUIC. La adopción de QUIC a finales de 2022 fue una actualización importante de la red que reemplazó las conexiones UDP utilizadas anteriormente. El principal motivo de este cambio fue mejorar la capacidad de la red para filtrar spam. Sin embargo, el cambio a QUIC ha generado cierta controversia, ya que Solana ha experimentado niveles de actividad sin precedentes durante 2024.
• La introducción de la Calidad de Servicio Ponderada por Stake (SWQoS) a principios de 2024 transformó profundamente la forma en que las transacciones llegan al líder mediante Gulf Stream. Ahora los líderes priorizan los mensajes de transacción enviados a través de otros validadores con stake. En concreto, el 80 % de la capacidad de un líder (2,000 conexiones) se reserva para pares con stake, mientras que el 20 % restante (500 conexiones) se asigna a mensajes de transacción procedentes de nodos sin stake.
• Actualmente, más del 80 % del stake de Solana está bloqueado en validadores que ejecutan el cliente Jito-Solana en lugar del cliente Agave original. Jito introduce una subasta de espacio de bloque fuera del protocolo, lo que añade más complejidad a la forma en que las transacciones llegan al líder. En concreto, el relayer de Jito añade un “reductor de velocidad” de 200 milisegundos para ralentizar el flujo de mensajes de transacción entrantes y dar a los buscadores tiempo suficiente para enviar bundles.

Introducción

El término "Gulf Stream" proviene de una serie de publicaciones de blog introductorias escritas por el equipo fundador de Solana en 2019, en las que asignaron nombres inspirados en la aviación a muchos de los mecanismos más innovadores de Solana. En estas publicaciones, Gulf Stream se definió como el “protocolo de reenvío de transacciones sin mempool” de Solana. Sin embargo, hoy una búsqueda del término “Gulf Stream” en el código base de Solana solo devuelve una mención trivial.

En el contexto más amplio del ciclo de vida de una transacción de Solana, “Gulf Stream” puede entenderse como todo el proceso que ocurre desde que un nodo de la red, normalmente un RPC, recoge una transacción hasta que esta llega al líder del slot actual (es decir, cuando la “etapa Fetch” de la TPU la recoge). También podríamos conceptualizar Gulf Stream como la imagen especular de Turbine, el mecanismo de propagación de bloques de Solana, ya que Gulf Stream lleva las transacciones al líder y Turbine distribuye las transacciones procesadas desde el líder.

Primero, puede resultar útil definir los nodos RPC (Llamada a Procedimiento Remoto) en el contexto de Solana. Puedes considerarlos puertas de enlace para interactuar con la red y leer sus datos. Actúan como intermediarios entre los usuarios y los validadores de Solana. Los RPC ejecutan el mismo software que los validadores completos, pero con configuraciones diferentes. Esto les permite simular transacciones con precisión y mantener una vista actualizada del estado actual (el banco). Sin embargo, los nodos RPC no tienen stake y, por tanto, no participan en el consenso. Sin stake, no pueden votar ni crear bloques. Esta configuración difiere de muchas otras blockchains, donde los validadores y los nodos RPC suelen ser los mismos. En cuanto a Gulf Stream, podemos resumir la función del RPC así: recibe transacciones mediante HTTP, las convierte a QUIC (más adelante profundizaremos en esto), consulta la dirección y el puerto del líder actual mediante el cronograma de líderes y reenvía la transacción a los líderes actual y siguiente.

Desde el lanzamiento de la red, Gulf Stream ha recibido al menos dos actualizaciones importantes: QUIC y la QoS ponderada por stake, que analizaremos en detalle más adelante. También es la parte del protocolo central que probablemente ha soportado más presión durante los últimos años debido al volumen sin precedentes de tráfico en la red de Solana. Para ponerlo en contexto, cuando un validador se convierte en líder, puede esperar un aumento brusco del tráfico entrante, que supera un gigabyte por segundo cuando toda la red dirige paquetes hacia él. Gestionar volúmenes tan intensos de datos entrantes supone un enorme desafío de ingeniería.

Más mempool, más problemas

La definición original de Gulf Stream del equipo fundador destaca la ausencia de un mempool. Podemos definir un mempool (literalmente, un “grupo de memoria”) como un conjunto de transacciones que los usuarios enviaron y que esperan a ser procesadas por la red. Por lo general, estas transacciones no están cifradas ni protegidas mientras esperan públicamente. Se propagan por toda la red mediante un protocolo de gossip. Según la red, las transacciones firmadas pueden permanecer en el mempool de forma indefinida hasta que se cumplan las condiciones para ejecutarlas. Esto ocurre especialmente con las transacciones que establecen una comisión (precio por unidad de cómputo) considerablemente inferior al rango habitual del mercado. En casos extremos, estas transacciones pueden tardar días o semanas en ejecutarse si las condiciones de la red no favorecen su inclusión en un bloque.

Este escenario no es posible en Solana, que no solo carece de un concepto nativo de mempool, sino que además exige que todos los mensajes de transacción incluyan un blockhash reciente. Los desarrolladores pueden solicitar fácilmente blockhashes recientes mediante una llamada a la API JSON RPC del método getLatestBlockhash. Este blockhash se integra en el mensaje de transacción y es válido durante un máximo de 150 slots, aproximadamente 1 minuto, considerando que el tiempo objetivo de cada slot es de 400 milisegundos. Después de 150 slots, el blockhash queda obsoleto y la red descarta las transacciones que hacen referencia a él. De forma predeterminada, los RPC intentan reenviar las transacciones cada 2 segundos, pero, una vez que vence el blockhash reciente, la transacción se descarta, lo que garantiza que nunca se ejecutará on-chain.

El blockhash reciente también permite detectar y eliminar transacciones duplicadas, algo que en otras redes se conseguiría exigiendo la inclusión de un nonce (un número que se usa una sola vez). Aunque los desarrolladores disponen de métodos para agregar nonces duraderos a las transacciones de Solana en casos específicos, no es obligatorio incluir nonces en una transacción estándar de Solana.

El sistema Gulf Stream de Solana es viable porque todos los nodos activos siempre conocen de antemano el cronograma de líderes. Los nodos actualizan sus cronogramas de líderes cada vez que la altura del slot cruza el límite de una época, aproximadamente cada 2 días. El cronograma de líderes de una época se calcula a partir del estado del ledger al inicio de la época anterior. El proceso algorítmico para generar el cronograma es el siguiente:

• Usar periódicamente la altura del tick de la prueba de historial (PoH) (es decir, un contador que aumenta de forma monótona) para inicializar un algoritmo pseudoaleatorio estable.
• En esa altura, tomar una muestra del banco con todas las cuentas con stake cuyas identidades de líder hayan votado dentro de un número de ticks configurado por el clúster. Esta muestra se denomina conjunto activo.
• Ordenar el conjunto activo según el peso del stake.
• Usar una semilla aleatoria para seleccionar nodos ponderados por stake y crear un orden ponderado por stake.
• Este orden entra en vigor después de un número de ticks configurado por el clúster.

Fuente: documentación oficial de Solana

La ponderación por stake garantiza que los nodos de confianza con más stake tengan mayores probabilidades de ser elegidos líderes con más frecuencia, mientras que los nodos con menos stake se eligen con menor frecuencia o no se eligen. 

‍La asignación de recursos ponderada por stake es un tema recurrente en todo el protocolo central de Solana, incluidos las recompensas por votación, los árboles de Turbine, los cronogramas de líderes y la red de gossip*. Incluso Gulf Stream emplea la ponderación por stake, como explicaremos más adelante.

Una nota sobre QUIC

La primera actualización importante de Gulf Stream llegó a finales de 2022  con la adopción del protocolo de red QUIC para gestionar la transmisión de mensajes de transacción al líder. Esta actualización respondió a las interrupciones de la red provocadas por ataques DDoS y transacciones de spam que saturaban la cadena durante los mints de NFT. Tras la integración completa de QUIC en Mainnet-Beta con la versión 1.13.4, mejoró la estabilidad de la red.

Antes, Solana usaba el protocolo de red UDP (Protocolo de Datagramas de Usuario) para enviar transacciones desde los nodos RPC al líder actual. Aunque UDP es rápido y eficiente, no usa conexiones y carece tanto de control de flujo como de confirmaciones de recepción. Por ello, no existe una forma efectiva de desalentar o mitigar el comportamiento abusivo. Para controlar el tráfico de red, el protocolo de ingesta de transacciones del validador (es decir, la etapa Fetch de la TPU) se volvió a implementar con QUIC.

QUIC, desarrollado inicialmente por Google en 2012, intenta ofrecer lo mejor de TCP y UDP. Facilita una comunicación rápida y asíncrona similar a UDP, pero con las sesiones seguras y las estrategias avanzadas de control de flujo de TCP. Esto permite establecer límites para fuentes de tráfico individuales, de modo que la red pueda concentrarse en procesar transacciones auténticas. También ofrece streams separados. Así, si se descarta una transacción, no se bloquean las demás. Google ha sido el principal impulsor de la adopción de QUIC en Web2. Las conexiones con los servidores de Google se establecen mediante QUIC, por lo que muchas aplicaciones de Google se basan en QUIC, como Hangouts, Gmail y YouTube. Como dato adicional, QUIC no es un acrónimo, sino el nombre real del protocolo. 

Dicho esto, la eficacia de la implementación de QUIC en Solana sigue abierta a debate. Durante los picos de tráfico intenso en la red, los validadores pueden verse saturados por los handshakes de QUIC. Es justo decir que no ha sido la solución definitiva que algunos esperaban inicialmente para resolver los problemas de congestión en la red. Cabe señalar que QUIC tiene un bajo nivel de adopción en la industria blockchain fuera de su implementación en Solana. Algunos miembros de la comunidad de validadores de Solana han criticado abiertamente el protocolo y consideran que adoptar QUIC fue un error.

Calidad de Servicio Ponderada por Stake (SWQoS)

A principios de 2024, se adoptó la Calidad de Servicio Ponderada por Stake (SWQoS) como mecanismo para prevenir el spam y aumentar la resistencia a ataques Sybil. Este sistema permite que los líderes prioricen los mensajes de transacción enrutados a través de validadores con stake. Los validadores con más stake reciben una capacidad proporcionalmente mayor para transmitir paquetes de mensajes de transacción al líder. Esto mitiga eficazmente los ataques Sybil de nodos sin stake o con poco stake en toda la red. Esta segmentación es posible porque las direcciones IP se pueden verificar mediante QUIC, lo que permite que los validadores prioricen y limiten el tráfico de conexiones específicas. 

Con SWQoS, los validadores pueden alquilar a los nodos RPC su capacidad ponderada por stake. A cambio, los nodos RPC obtienen más ancho de banda, lo que les permite lograr mayores tasas de inclusión de transacciones en los bloques. En particular, el 80 % de la capacidad de un líder (2,000 conexiones) se reserva para la QoS ponderada por stake, mientras que el 20 % restante (500 conexiones) se asigna a mensajes de transacción de otros nodos. Esta estrategia de asignación se asemeja a un sistema de carriles prioritarios en una autopista, donde los conductores pagan un peaje para evitar el tráfico.

La cantidad mínima de stake necesaria para calificar como par con stake es actualmente del 0.04 % del stake total. Al momento de escribir este artículo, el stake total es de 384 millones de SOL, por lo que el requisito mínimo es de 15,360 SOL.‍

SWQoS ha tenido un impacto significativo en el ecosistema de Solana al elevar los requisitos para reenviar transacciones al líder y reducir la eficacia de los ataques de spam. Este cambio ha incentivado a las aplicaciones con mucho tráfico a integrar verticalmente sus operaciones. Al ejecutar sus propios nodos validadores, las aplicaciones pueden garantizar acceso privilegiado al líder y mejorar así su capacidad para procesar transacciones. En Helius, nos enorgullece operar uno de los principales validadores de la red por stake, lo que nos permite asegurar una mayor inclusión de transacciones. Obtén más información sobre cómo hacer staking con nosotros en nuestra guía detallada aquí.

El reductor de velocidad de Jito

Este artículo estaría incompleto sin mencionar a Jito, dado que, al momento de escribirlo, más del 80 % del stake de la red usa el cliente validador de Jito, lo que añade cierta complejidad a la forma en que las transacciones suelen llegar al líder. El cliente validador Jito-Solana (Github) es un fork del cliente Agave (Github), originalmente el cliente de Solana Labs. Introduce una subasta de espacio de bloque fuera del protocolo y permite que los validadores reciban incentivos económicos adicionales en forma de propinas.

Un análisis exhaustivo del cliente de Jito queda fuera del alcance de este artículo. Por ello, limitaremos nuestro análisis a cómo afecta el cliente de Jito al flujo de transacciones normales a través de Gulf Stream. Las transacciones tienen dos rutas posibles: fluyen desde un RPC hasta un validador vinculado y luego hasta el líder actual (la ruta ponderada por stake), o se reenvían directamente al líder (la ruta de conexión abierta). En cualquiera de estos escenarios, si el líder ejecuta el cliente Jito-Solana, estas transacciones se envían primero a Jito-Relayer (Github), un software de código abierto que actúa como router proxy de transacciones. 

Los demás nodos de la red desconocen la existencia de Jito-Relayer. Simplemente envían las transacciones a la configuración de dirección y puerto que el líder haya decidido difundir mediante la red de gossip como su ingress_socket. El relayer retrasa las transacciones 200 milisegundos antes de reenviarlas al líder. Este mecanismo de “reductor de velocidad” ralentiza el flujo de mensajes de transacción entrantes y permite realizar subastas eficientes en tiempo discreto. Después de 200 milisegundos, el relayer libera las transacciones de forma optimista, independientemente de los resultados de la subasta.

Anteriormente, Jito operaba un servicio de mempool canónico fuera del protocolo, que ahora está obsoleto. Cuando un validador Jito-Solana es el líder, los buscadores aún pueden enviar grupos de transacciones ejecutadas de forma atómica, conocidos como bundles, para otros tipos de transacciones MEV que no dependen del mempool, como las transacciones de arbitraje y las liquidaciones.

Para obtener más información, consulta nuestro artículo del blog de Helius aquí, que ofrece una introducción al MEV de Solana.

Conclusión

En este artículo, analizamos distintos aspectos de Gulf Stream de Solana, incluidos el protocolo de red QUIC, la QoS ponderada por stake y la configuración del validador de Jito. Comparamos Gulf Stream con la arquitectura de mempool más tradicional y describimos las ventajas del enfoque de Solana en términos de mayor eficiencia y menor latencia. 

No cabe duda de que Gulf Stream seguirá evolucionando. El protocolo de Solana y su ecosistema más amplio avanzan rápidamente, y se esperan actualizaciones importantes. Por ejemplo, Anatoly Yakovenko, cofundador de Solana, ha defendido firmemente la implementación de varios líderes simultáneos. Los líderes simultáneos permitirían que varios nodos de todo el mundo secuenciaran al mismo tiempo las transacciones de los usuarios. Esto reduciría la latencia y eliminaría la necesidad de completar, en el peor de los casos, un viaje de ida y vuelta por todo el mundo antes de agregar una transacción a la blockchain.

Solana no se quedará quieta, y todo el protocolo, incluido Gulf Stream, tiene por delante un futuro emocionante. Por ello, los desarrolladores deben esperar muchas más actualizaciones y optimizaciones.

Si llegaste hasta aquí, ¡gracias! Considera unirte a nuestra comunidad en Discord, seguirnos en X o suscribirte a nuestra lista de correo a continuación.‍

Muchas gracias a Jacob Creech y 0xIchigo por revisar versiones anteriores de este artículo.‍

Recursos adicionales

• Gulf Stream: el protocolo de reenvío de transacciones sin mempool de Solana
• QUIC, un transporte multiplexado sobre UDP
• Una guía completa de HTTP/3 y QUIC
• Recopilación de enlaces sobre SWQoS
• Guía de la Calidad de Servicio Ponderada por Stake en Solana
• Formación para validadores de Solana: QoS ponderada por stake
• Documentación de Jito Relayer
• Ejecución asíncrona, arquitectura final

‍