Actualizaciones de la red Solana

Solana registra un crecimiento notable en usuarios y adopción, lo que exige mejoras estratégicas en la red. El equipo de ingeniería de Solana Foundation ha diseñado un conjunto integral de actualizaciones para reforzar la infraestructura de la red, optimizar el rendimiento y mejorar la experiencia de los usuarios. Estas modificaciones resuelven cuellos de botella críticos en la gestión de transacciones, el ancho de banda y la eficiencia de transmisión de datos, consolidando el estado general de la red Solana.

QUIC

Actualmente, Solana utiliza un protocolo personalizado basado en UDP sin formato para transmitir transacciones entre los nodos Remote Procedure Call (RPC) y el líder actual. Si bien UDP es veloz, funciona como protocolo sin conexión, sin control de flujo ni confirmaciones de recepción, lo que limita la capacidad para mitigar comportamientos abusivos en la red.

Para superar estas limitaciones, el protocolo de ingestión de transacciones de Solana fue reimplementado con QUIC, el protocolo desarrollado por Google. QUIC combina la velocidad de UDP con la gestión de sesión y el control de flujo de TCP, permitiendo comunicaciones asíncronas más rápidas y una gestión de tráfico integrada. Esta mejora permite a los operadores de la red adaptar y optimizar la ingestión de datos de forma más eficiente.

QUIC está activo en Mainnet-beta y lo emplea la mayoría de validadores y operadores RPC. Tras las sucesivas versiones, QUIC es ahora el protocolo predeterminado de ingestión de transacciones, sustituyendo por completo a UDP y logrando una adopción masiva en todo el ecosistema de la red Solana.

Stake-weighted QoS

El ancho de banda de la red del líder tiene una capacidad fija, lo que requiere una gestión sofisticada para su uso óptimo. El modelo anterior de aceptación de transacciones se basaba en el orden de llegada, sin considerar su origen, generando ineficiencias en la asignación del ancho de banda.

Stake-weighted Quality of Service (QoS) establece la equidad en función del stake de cada nodo en la red. Con este modelo, un nodo con el 0,5 % del stake en la red tiene garantizado transmitir al menos el 0,5 % de los paquetes al líder, y el resto de participantes no puede eliminar ni sobrescribir colectivamente esa cuota. Este enfoque utiliza la arquitectura proof-of-stake de Solana para garantizar derechos de transmisión equitativos.

Stake-weighted QoS se desarrolló en paralelo a la implementación de QUIC y se activó en Mainnet-beta para asegurar una distribución justa del ancho de banda, reforzando el estado de la red Solana.

Fee markets

Tras ingresar en la red, las transacciones compiten por modificar datos de cuentas compartidas. El sistema original ordenaba por llegada, sin permitir que los usuarios expresaran la urgencia o prioridad de sus transacciones frente a otras que accedían a las mismas cuentas.

Fee markets introducen un método de priorización de transacciones basado en el mercado, permitiendo a los usuarios añadir priority fees (pagos adicionales al coste base) para señalar la urgencia de sus operaciones. Estas priority fees se calculan según los recursos computacionales requeridos. Por ejemplo, una transferencia simple de tokens con igual urgencia tendrá priority fees inferiores a una operación compleja de Non-Fungible Token (NFT).

Fee markets está disponible en Mainnet-beta y sigue en desarrollo para ampliar la funcionalidad RPC, integrar wallets y añadir mecanismos avanzados como tarifas escalonadas para cuentas muy disputadas y algoritmos mejorados de programación de bloques.

Incremento del tamaño de transacción

Las transacciones en Solana están limitadas a 1 232 bytes, lo que restringe la composabilidad de los programas al limitar la cantidad de datos posibles en una sola transacción. Este límite resulta problemático cuando los programas interactúan entre sí, ya que secuencias de instrucciones complejas pueden exceder el espacio disponible.

Las mejoras en el protocolo QUIC han permitido aumentar los límites de tamaño de transacción. Los equipos de ingeniería evalúan su impacto en el rendimiento de la red y determinan nuevos parámetros óptimos que equilibren la composabilidad con la eficiencia, afectando directamente al estado de la red Solana.

Compact vote state

Las transacciones de votación son las más frecuentes entre los nodos de la red. El esquema actual exige gran ancho de banda y contribuye al tamaño de los bloques. Incluso reducciones modestas en el tamaño del estado de voto tienen un impacto relevante al disminuir el volumen de transmisión de datos y los requisitos de almacenamiento entre validadores.

La optimización de compact vote state se desarrolla y prueba en el Testnet de Solana. Esta mejora reducirá la huella de datos de las transacciones de votación, manteniendo la funcionalidad completa del consenso.

Conclusión

La iniciativa de actualizaciones de la red Solana aborda de forma integral los retos de escalabilidad y eficiencia. Con innovaciones en el diseño de protocolos (QUIC), asignación de recursos (stake-weighted QoS), precios de transacciones (fee markets), capacidad de datos (tamaño de transacción) y optimización del consenso (compact vote state), Solana refuerza su infraestructura para un crecimiento sostenido. Estas actualizaciones mejoran el uso del ancho de banda, los mecanismos de priorización y reducen la sobrecarga del sistema, consolidando el estado de la red Solana para soportar mayor adopción y crecimiento de usuarios, manteniendo rendimiento y seguridad.

FAQ

¿La red Solana está operativa actualmente?

Sí, la red Solana funciona normalmente. No se han registrado cortes ni incidencias en este momento.

¿Por qué hay congestión en la red Solana?

La congestión de la red Solana deriva del alto volumen de transacciones y el spam de bots que saturan la blockchain. Al aumentar el uso, los validadores no consiguen procesar todas las transacciones con agilidad, lo que provoca retrasos. Los desarrolladores trabajan en soluciones para incrementar el rendimiento y reducir la congestión.

¿Por qué tarda mi transferencia de Solana?

Las transferencias de Solana pueden demorarse por los tiempos de procesamiento de los exchanges o por congestión en la red. Las transacciones directas en la blockchain suelen completarse en segundos. Compruebe si su transferencia implica un exchange, ya que la mayoría de retrasos se debe a sus sistemas internos, no a la red Solana.

¿Por qué se cayó la red Solana?

Las caídas de la red Solana suelen producirse por congestión extrema en el volumen de transacciones. El modelo de tarifas fijas genera inestabilidad cuando la demanda se dispara, provocando degradación temporal del rendimiento o paradas de validadores.

¿Cómo consultar el estado actual y métricas de salud de la red Solana?

Visite status.solana.com para ver la disponibilidad y rendimiento de la red en tiempo real. Utilice los endpoints RPC de Solana para consultar la salud de la red con los métodos getHealth() o getClusterNodes(). Puede monitorizar el volumen de transacciones, tiempos de slot y la participación de validadores en los paneles y exploradores oficiales de Solana.

¿Cuáles son las causas habituales de ralentizaciones o caídas en la red Solana?

Las ralentizaciones y caídas de la red Solana suelen estar provocadas por errores de cliente, oleadas de spam en transacciones, inactividad de validadores, particiones de red y bloqueos de consenso que impiden la producción de bloques y la confirmación de transacciones.