Solana getVersion y características de runtime: sondeo de capacidades del nodo

El papel de getVersion en Solana RPC

El método RPC getVersion es una llamada ligera que devuelve la versión de software del nodo de Solana al que estás conectado, junto con un mapa feature-set. Según la documentación de Solana getVersion, la respuesta incluye una cadena de versión solana-core y un objeto feature-set donde cada clave es un identificador de feature-gate (una clave pública codificada en base58) y cada valor es el slot de activación de esa característica. Esta información es crucial para los clientes que necesitan asegurar la compatibilidad antes de invocar métodos RPC más recientes o interpretar formatos de transacción que dependen de características de runtime específicas.

A diferencia de los métodos que consultan el estado de la blockchain, getVersion informa la propia configuración de software del nodo. No requiere ningún parámetro y normalmente responde rápido. Debido a que refleja las capacidades anunciadas por el nodo, es el primer paso para construir un perfil de capacidades de un endpoint RPC. Puedes usarlo junto con otros métodos de salud y de clúster para formar una imagen completa, como se describe en la guía de la API de Solana (RPC Assistant).

• Devuelve la cadena de versión solana-core (por ejemplo, '1.18.22').
• Devuelve el mapa feature-set: ID de característica → slot de activación.
• No requiere parámetros; es seguro llamarlo con frecuencia.
• El feature-set anunciado puede ir por detrás del clúster si el nodo no está completamente sincronizado.

Entender los feature gates de Solana y su activación

Los feature gates de Solana son cambios de runtime que se activan en un slot específico una vez que una supermayoría de stake ha votado para habilitarlos. Cada característica se identifica mediante una clave pública única, y su slot de activación se registra on-chain. La referencia de feature gates de Solana explica que las características pueden cambiar el procesamiento de transacciones, añadir nuevos métodos RPC o alterar el comportamiento de los existentes. Cuando se activa una característica, los nodos que se han actualizado a una versión de software que la soporta comenzarán a aplicar el nuevo comportamiento desde el slot de activación en adelante.

Debido a que la activación de características se coordina en todo el clúster, los nodos que ejecutan software más antiguo pueden no reconocer una característica y podrían rechazar transacciones o devolver errores para los métodos que dependen de ella. Por lo tanto, comprobar el feature-set de getVersion te ayuda a determinar si un nodo conoce una característica antes de depender de ella. Sin embargo, la presencia de una característica en el feature-set no garantiza que el nodo la haya activado por completo; el slot de activación indica cuándo debería volverse activa, pero el nodo también debe estar saludable y cerca de la punta de la cadena para procesar transacciones correctamente.

• Los feature gates se identifican mediante claves públicas y se activan en slots específicos.
• La activación requiere un voto ponderado por stake y soporte de software.
• Los nodos con versiones más antiguas pueden no incluir características más recientes en su feature-set.
• La presencia en el feature-set es necesaria pero no suficiente para la disponibilidad del método.

Construir un registro de capacidades del nodo con getVersion, getHealth, getClusterNodes y getEpochInfo

Una sola llamada a getVersion te da la versión anunciada y el feature-set, pero para confiar en esa información necesitas confirmar que el nodo está saludable y sincronizado. El método getHealth devuelve 'ok' si el nodo está dentro de cierto umbral del clúster, mientras que getEpochInfo proporciona la época actual, el slot y el recuento de transacciones. getClusterNodes enumera todos los nodos del clúster con sus versiones, lo que te ayuda a comparar la versión de tu endpoint con la mayoría del clúster.

Al combinar estas llamadas, puedes construir un registro de capacidades que incluya: la versión solana-core del nodo, su feature-set, su estado de salud, la época y el slot actuales, y la distribución de versiones del clúster. Este registro debe almacenarse en caché por endpoint y actualizarse periódicamente, porque los nodos pueden actualizarse o quedarse atrás. Para una discusión más profunda sobre cómo detectar retrasos, consulta Detectar un nodo RPC retrasado respecto a la punta de la cadena.

• getVersion: versión y feature-set.
• getHealth: devuelve 'ok' si el nodo está saludable.
• getEpochInfo: época actual, slot y recuento de transacciones.
• getClusterNodes: lista de nodos del clúster con versiones.
• Almacena en caché el registro combinado por endpoint y actualízalo con regularidad.

Detectar un nodo que va por detrás de un despliegue

Cuando se despliega una nueva característica, los nodos que no se han actualizado no la anunciarán en su feature-set. Si intentas usar un método que depende de esa característica, el nodo puede devolver un error de 'method not found' o rechazar una transacción con una versión no soportada. Para detectar ese retraso, compara la versión solana-core del nodo con la versión mayoritaria reportada por getClusterNodes. Si tu endpoint está significativamente por detrás, puede que no soporte formatos de transacción o métodos RPC más recientes.

Además, comprueba el slot de activación de la característica que necesitas. Si el slot actual de getEpochInfo ya pasó el slot de activación pero la característica falta en el feature-set del nodo, es probable que el nodo esté ejecutando software desactualizado. En ese caso, deberías cambiar a un endpoint diferente o esperar a que el nodo se actualice. Las herramientas de monitorización pueden automatizar esta comprobación; consulta Monitorización de endpoints RPC para conocer estrategias.

• Compara la versión del nodo con la mayoría del clúster desde getClusterNodes.
• Comprueba si el slot actual > slot de activación de la característica pero la característica falta.
• Los nodos retrasados pueden rechazar formatos de transacción más recientes.
• Cambia de endpoint o espera la actualización si se detecta retraso.

Ejemplo ejecutable en Node.js: sondear getVersion y el feature-set

El siguiente script de Node.js se conecta a un endpoint RPC de Solana, llama a getVersion, extrae las claves del feature-set y comprueba si existe un ID de característica específico. También imprime la versión anunciada. Puedes adaptarlo a tu propia característica de interés reemplazando la constante FEATURE_ID. Este ejemplo usa la biblioteca @solana/web3.js, pero también puedes usar solicitudes HTTP sin procesar.

Antes de ejecutarlo, asegúrate de tener Node.js instalado y el paquete @solana/web3.js. El script usa un endpoint RPC público para la demostración; reemplázalo con la URL de tu propio endpoint. La salida mostrará la versión y si la característica está presente.

const { Connection } = require('@solana/web3.js');

// Replace with your RPC endpoint
const RPC_URL = 'https://api.mainnet-beta.solana.com';
const FEATURE_ID = '3a8f5b7c9d2e1f0a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a'; // example feature ID

async function probeNode() {
  const connection = new Connection(RPC_URL, 'confirmed');
  try {
    const versionInfo = await connection.getVersion();
    console.log('solana-core version:', versionInfo['solana-core']);
    const featureSet = versionInfo['feature-set'];
    const featureKeys = Object.keys(featureSet);
    console.log('Number of features advertised:', featureKeys.length);
    if (featureKeys.includes(FEATURE_ID)) {
      console.log(`Feature ${FEATURE_ID} is present, activation slot: ${featureSet[FEATURE_ID]}`);
    } else {
      console.log(`Feature ${FEATURE_ID} is NOT present in the advertised feature-set.`);
    }
  } catch (err) {
    console.error('Error probing node:', err);
  }
}

probeNode();

Verificar las afirmaciones de capacidad con getHealth y getSlot

Una entrada en el feature-set por sí sola no garantiza que el nodo procese con éxito una transacción que use esa característica. El nodo también debe estar saludable y cerca de la punta de la cadena. Después de llamar a getVersion, llama a getHealth para asegurarte de que el nodo devuelve 'ok', y a getSlot para comprobar el slot actual. Si el nodo está retrasado, puede que no haya procesado los últimos bloques y podría fallar al simular o enviar transacciones correctamente.

Por ejemplo, si estás a punto de enviar una transacción versionada que depende de una característica activada recientemente, deberías verificar que el slot del nodo esté dentro de unos pocos slots del slot más alto del clúster. Puedes obtener el slot más alto del clúster desde getClusterNodes o consultando múltiples endpoints. Solo confía en la afirmación de capacidad cuando el nodo esté saludable y su slot esté cerca de la punta. Esta práctica forma parte de una estrategia robusta de niveles de commitment y confirmación de transacciones en Solana.

• Llama a getHealth después de getVersion; espera 'ok'.
• Llama a getSlot y compáralo con el slot más alto del clúster.
• Si el nodo está retrasado, la afirmación de capacidad no es fiable.
• Combina las comprobaciones de salud y slot antes de enviar transacciones.

Tabla de resultados: medir el perfil de capacidades de tu endpoint

Para evaluar sistemáticamente un endpoint RPC, crea una tabla de resultados que registre las salidas de los sondeos de capacidad. Ejecuta los sondeos a intervalos regulares y rellena la tabla con los valores observados. Esto te ayuda a seguir los cambios a lo largo del tiempo y comparar múltiples endpoints. A continuación tienes una plantilla que puedes usar; reemplaza los valores de ejemplo con tus propias mediciones.

La tabla debe incluir la URL del endpoint, la marca de tiempo, la versión solana-core, el número de características en el feature-set, la presencia de una característica específica, el estado de salud, el slot actual y el slot más alto del clúster. También puedes añadir una columna para la diferencia entre el slot del nodo y el slot más alto del clúster para detectar rápidamente el retraso.

• URL del endpoint: por ejemplo, https://api.mainnet-beta.solana.com
• Marca de tiempo: formato ISO 8601.
• Versión de solana-core: de getVersion.
• Recuento de características: número de claves en el feature-set.
• Característica X presente: sí/no.
• Salud: 'ok' o error.
• Slot del nodo: de getSlot.
• Slot más alto del clúster: de getClusterNodes u otra fuente.
• Diferencia de slot: slot del nodo - slot más alto del clúster.

Limitaciones y compensaciones de las capacidades anunciadas

El feature-set devuelto por getVersion es el propio informe del nodo y puede no reflejar el conjunto activo del clúster si el nodo está retrasado o mal configurado. Un nodo podría anunciar una característica pero aún así fallar al procesar transacciones que la usan debido a errores internos o sincronización incompleta. Además, algunos métodos RPC están limitados por la configuración del nodo en lugar de por feature gates; por ejemplo, un operador podría deshabilitar ciertos métodos por razones de seguridad o rendimiento. Este comportamiento está documentado / varía según el nodo, así que no puedes asumir que un método esté disponible solo porque la característica esté presente.

Otra limitación es que los endpoints con balanceo de carga pueden enrutar solicitudes a nodos diferentes con versiones diferentes. Una sola llamada a getVersion podría llegar a un nodo, mientras que una transacción posterior se envía a otro. Para mitigar esto, deberías usar un endpoint dedicado o realizar comprobaciones de capacidad en cada solicitud, aunque esto último añade sobrecarga. Para sistemas en producción, considera usar un proveedor que ofrezca versiones de nodo consistentes entre regiones, como los descritos en Precios de RPC.

• El feature-set anunciado es el autoinforme del nodo; puede ir por detrás del clúster.
• La disponibilidad de métodos puede estar limitada por configuración, no solo por características.
• Los balanceadores de carga pueden enrutar a versiones diferentes.
• Los endpoints dedicados o las comprobaciones por solicitud reducen el riesgo.

Solución de problemas comunes de getVersion y el feature-set

Si getVersion devuelve un error, el endpoint puede estar caído o no ser un nodo RPC de Solana. Comprueba la URL y asegúrate de que soporta JSON-RPC 2.0. Si el feature-set está vacío o le faltan características esperadas, el nodo puede estar ejecutando una versión más antigua o no estar completamente sincronizado. En ese caso, compáralo con getClusterNodes para ver la distribución de versiones del clúster. Si tu nodo es el único al que le falta una característica, es probable que esté desactualizado.

Si recibes un error de 'method not found' al llamar a un método que debería estar disponible, verifica que el método no esté limitado por configuración. Algunos proveedores deshabilitan ciertos métodos por defecto. Además, asegúrate de usar el nombre de método y los parámetros correctos. Para transacciones versionadas, comprueba que el nodo soporta la característica requerida y que tu transacción está correctamente formateada; consulta Transacciones versionadas de Solana y análisis de getBlock para más detalles.

• Error de getVersion: el endpoint puede estar caído o ser inválido.
• Feature-set vacío: el nodo puede estar desactualizado o sin sincronizar.
• Method not found: podría estar limitado por configuración o haber un desajuste de versión.
• Comprueba el nombre del método y los parámetros; consulta la documentación del proveedor.

Próximos pasos: integrar las comprobaciones de capacidad en tu flujo de trabajo

Para garantizar la fiabilidad, integra las comprobaciones de capacidad en el arranque de tu aplicación y en las comprobaciones de salud periódicas. Almacena en caché el registro de capacidades por endpoint y actualízalo cada pocos minutos o antes de operaciones críticas. Usa los resultados para decidir si continuar con una transacción o recurrir a un endpoint diferente. Para una visión más amplia de Solana RPC, consulta la guía de la API de Solana (RPC Assistant) y el centro de aprendizaje de OnFinality.

Si estás construyendo un servicio que depende de características específicas, considera usar múltiples proveedores RPC y balanceo de carga basado en capacidades. OnFinality ofrece endpoints de API de Solana con versiones consistentes y servicio de API para un acceso fiable. Prueba siempre tu integración contra las últimas características del clúster y monitoriza los cambios.

• Almacena en caché el registro de capacidades por endpoint; actualízalo con regularidad.
• Usa las comprobaciones antes de transacciones críticas.
• Considera múltiples proveedores para redundancia.
• Monitoriza las activaciones de características del clúster y los plazos de actualización.