Endpoints RPC de Bittensor: Conexión a la red de la OpenTensor Foundation

Bittensor es una red descentralizada para el aprendizaje automático, coordinada por la OpenTensor Foundation y ejecutada en la mainnet Finney. Los mineros registran modelos en subnets, los validadores puntúan esos modelos y TAO fluye entre ellos según el mecanismo de incentivos de la red. Si estás construyendo un panel, un explorador de subnets, una herramienta de validación o un script de monitorización de mineros, necesitas leer y escribir en esa cadena, lo que significa que necesitas un endpoint RPC.

Esta página se centra en el aspecto práctico: cómo conectarte a Bittensor a través de JSON-RPC, qué comprobar antes de elegir un endpoint y cómo mantener tu integración estable a medida que crecen las subnets y el tráfico. Está escrita para desarrolladores que ya entienden los conceptos básicos de las cadenas basadas en Substrate y quieren una conexión funcional además de una forma clara de decidir entre infraestructura pública, compartida y dedicada.

¿Qué endpoint de Bittensor se adapta a tu carga de trabajo?

Antes de copiar un endpoint, adáptalo a lo que realmente hace tu aplicación. El tráfico de Bittensor es inusual porque gran parte consiste en sondeos de lectura intensiva del estado de las subnets, datos de metagraph y saldos de stake, a menudo con alta frecuencia.

Si tu carga de trabajo es exploratoria —un script que se ejecuta unas pocas veces al día— un endpoint público suele ser suficiente para empezar. Si ejecutas un panel con muchos usuarios, un bucle de monitorización que sondea cada pocos segundos o un indexador que necesita estado histórico, un endpoint compartido o dedicado te evitará los modos de fallo descritos más adelante en este artículo.

OnFinality proporciona RPC de Bittensor (Finney) tanto por HTTP como por WebSocket, junto con una variedad de otras redes RPC compatibles. Puedes comparar planes en la página de precios de RPC, o pasar a recursos aislados con un nodo dedicado si necesitas capacidad predecible.

Configuración de la cadena de un vistazo

Bittensor es una cadena basada en Substrate, por lo que utiliza la interfaz JSON-RPC estándar de Substrate en lugar del conjunto de métodos JSON-RPC de Ethereum. Ten a mano estas configuraciones al configurar carteras, SDKs y herramientas de monitorización.

Dado que la moneda nativa utiliza 9 decimales, recuerda escalar las cantidades de TAO por 1e9 al convertir entre enteros estilo planck y valores legibles por humanos. Un error común en las herramientas de Bittensor es mostrar saldos sin ese escalado, lo que hace que los números de stake y emisión parezcan incorrectos en nueve órdenes de magnitud.

Realizar tus primeras llamadas JSON-RPC

Las cadenas Substrate exponen un pequeño conjunto de métodos principales en los que se basa la mayoría de las herramientas. Comienza con una comprobación de estado y una lectura de identidad de la cadena para confirmar que tu endpoint está activo y apunta a la red correcta.

# Confirmar que el nodo está sano y sincronizado
curl -s https://bittensor-finney.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_health","params":[]}'

# Leer el nombre de la cadena para verificar que estás en la mainnet Finney
curl -s https://bittensor-finney.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_chain","params":[]}'

Una respuesta saludable devuelve isSyncing: false y un recuento de pares. Si isSyncing es true, el nodo aún se está poniendo al día y las lecturas pueden estar desactualizadas; no trates su estado como definitivo.

Para el código de la aplicación, la API de Polkadot.js es la forma más común de comunicarse con Bittensor. Gestiona los metadatos, el registro de tipos y la codificación SCALE por ti, lo cual es importante porque las llamadas directas a state_getStorage requieren que conozcas las claves de almacenamiento y los tipos.

import { ApiPromise, WsProvider } from '@polkadot/api';

const provider = new WsProvider('wss://bittensor-finney.api.onfinality.io/public-ws');
const api = await ApiPromise.create({ provider });

const [chain, health] = await Promise.all([
  api.rpc.system.chain(),
  api.rpc.system.health(),
]);

console.log('Chain:', chain.toString());
console.log('Syncing:', health.isSyncing.toString());

// Leer el número de bloque actual
const header = await api.rpc.chain.getHeader();
console.log('Latest block:', header.number.toNumber());

Una vez conectado, puedes consultar el estado de subnets y stake a través de los módulos de runtime. Las claves de almacenamiento y los nombres de llamadas exactos dependen del runtime actual, así que léelos siempre desde los metadatos en vivo en lugar de codificar valores de un tutorial antiguo.

Leer datos de subnets y metagraph

La mayoría de las aplicaciones de Bittensor se centran en datos a nivel de subnet: qué neuronas están registradas, cuáles son sus valores de incentivo y emisión, y cómo se distribuye el stake. Estos datos residen en el almacenamiento del runtime y es mejor acceder a ellos mediante las consultas tipadas de la API en lugar de claves de almacenamiento sin procesar.

// Iterar neuronas registradas en una subnet (la estructura depende de la versión del runtime)
const entries = await api.query.subtensorModule.neurons.entries(1);

for (const [key, value] of entries) {
  const uid = key.args[1].toString();
  console.log('UID:', uid, 'Incentive:', value.incentive.toString());
}

Dos notas prácticas. Primero, las lecturas de metagraph pueden ser grandes: iterar cada neurona en una subnet ocupada devuelve muchos datos, así que pagina o filtra donde el runtime lo permita. Segundo, los identificadores de subnet y los nombres de módulos han cambiado a lo largo de las actualizaciones del runtime. Fija la versión de tu biblioteca cliente y prueba después de cada actualización de red, porque un elemento de almacenamiento renombrado romperá silenciosamente una consulta que antes funcionaba.

Suscripciones WebSocket para datos en vivo

Si estás construyendo algo que reacciona a nuevos bloques o eventos —un bot de alertas, un panel en vivo, un minero que vigila cambios de registro— el sondeo por HTTP no escalará bien. Utiliza una suscripción WebSocket en su lugar.

const provider = new WsProvider('wss://bittensor-finney.api.onfinality.io/public-ws');
const api = await ApiPromise.create({ provider });

// Reaccionar a cada nuevo bloque
const unsub = await api.rpc.chain.subscribeNewHeads((header) => {
  console.log('New block:', header.number.toNumber());
});

// Reaccionar a eventos específicos a medida que se incluyen
const unsubEvents = await api.query.system.events((events) => {
  events.forEach(({ event }) => {
    if (api.events.subtensorModule?.RegistrationAllowed?.is(event)) {
      console.log('Registration event detected');
    }
  });
});

Las conexiones WebSocket se caen. Las redes fallan, los portátiles se suspenden y los balanceadores de carga reciclan conexiones. Implementa siempre lógica de reconexión con retroceso y vuelve a suscribirte tras reconectar. Una suscripción que deja de entregar bloques silenciosamente es peor que un error, porque tu aplicación sigue ejecutándose con datos obsoletos.

Modos de fallo comunes y cómo depurarlos

La mayoría de los problemas de RPC de Bittensor siguen unos pocos patrones. Aquí te explicamos cómo reconocerlos y solucionarlos.

Un hábito de diagnóstico rápido: cuando algo parezca incorrecto, consulta system_health y chain_getHeader en dos endpoints diferentes y compara. Si las alturas de bloque difieren, tienes un problema de sincronización o retraso, no un error en tu código.

Evaluar un proveedor de RPC de Bittensor

Una vez que superas un prototipo rápido, el endpoint se convierte en parte de tu superficie de producción. Estos son los criterios que realmente importan para las cargas de trabajo de Bittensor.

OnFinality ejecuta RPC de Bittensor (Finney) como parte de un portafolio de red más amplio, para que puedas mantener tus integraciones de Substrate y EVM en herramientas consistentes. Si quieres comparar esto con otras cadenas y proveedores, el artículo cómo elegir un proveedor de RPC recorre el marco de evaluación general.

Construir versus comprar para la infraestructura de Bittensor

Ejecutar tu propio nodo de Bittensor te da control total, pero conlleva un coste operativo real: espacio en disco para el historial de la cadena, mantenimiento continuo de sincronización y actualizaciones, monitorización y la experiencia para depurar problemas de Substrate. Para un equipo cuyo producto es una subnet, un minero o una herramienta de analítica, eso suele ser tiempo invertido lejos de lo que realmente entregas.

Un endpoint RPC gestionado elimina la mayor parte de esa sobrecarga. Obtienes una conexión mantenida a la mainnet Finney, acceso HTTP y WebSocket, y una vía de soporte cuando algo se rompe. La contrapartida es que dependes del proveedor para la disponibilidad y los límites de tasa, por lo que los criterios de evaluación anteriores importan.

Un camino intermedio es un nodo dedicado: recursos aislados para tu carga de trabajo sin la carga de ejecutar el hardware tú mismo. Normalmente es el paso correcto cuando tu tráfico es predecible y alto, o cuando los límites de tasa compartidos empiezan a interferir con tus bucles de sondeo.

Puntos clave

• Bittensor se ejecuta en la mainnet Finney y utiliza JSON-RPC de Substrate sobre HTTP y WebSocket, no el conjunto de métodos de Ethereum.
• Adapta tu elección de endpoint a tu carga de trabajo: los scripts exploratorios pueden usar un endpoint público, mientras que los paneles, monitores e indexadores necesitan capacidad compartida o dedicada.
• Verifica siempre system_health y system_chain antes de confiar en un endpoint, y compara las alturas de bloque entre endpoints cuando algo parezca obsoleto.
• Escala los valores de TAO por 1e9 y lee las claves de almacenamiento desde los metadatos en vivo, porque las actualizaciones del runtime renombran módulos y elementos de almacenamiento.
• Usa suscripciones WebSocket para datos en tiempo real y implementa siempre lógica de reconexión con retroceso.
• Evalúa a los proveedores por soporte de transporte, acceso a archivo, rendimiento, transparencia en los límites de tasa, manejo de actualizaciones y failover.

Preguntas frecuentes

¿Bittensor es una cadena EVM?

No. Bittensor es una cadena basada en Substrate, por lo que utiliza métodos JSON-RPC de Substrate como system_health, chain_getHeader y state_getStorage. Las herramientas de Ethereum como eth_getBalance no se aplican aquí; usa la API de Polkadot.js u otro cliente de Substrate en su lugar.

¿Cuál es la diferencia entre Bittensor y Finney?

Bittensor es la red y el proyecto, mientras que Finney es el nombre de la mainnet. Cuando te conectas a un endpoint RPC de Bittensor, te estás conectando a la mainnet Finney y leyendo su estado de cadena.

¿Puedo usar un endpoint RPC público para producción?

Los endpoints públicos son adecuados para prototipos y scripts de baja frecuencia. Para paneles de producción, bucles de monitorización o indexadores, los endpoints compartidos o dedicados te dan un rendimiento más predecible y menos sorpresas por límites de tasa.

¿Por qué mis saldos de TAO parecen incorrectos?

TAO utiliza 9 decimales. Si muestras valores enteros sin procesar sin escalarlos por 1e9, los saldos y las emisiones parecerán demasiado grandes. Convierte siempre antes de mostrar valores a los usuarios.

¿Cómo obtengo datos de Bittensor en tiempo real?

Usa un endpoint WebSocket y suscríbete a nuevas cabezas o eventos del sistema. Implementa lógica de reconexión con retroceso y vuelve a suscribirte tras cada reconexión para que tu aplicación no se ejecute con datos obsoletos.

¿Dónde puedo encontrar los detalles del endpoint de Bittensor de OnFinality?

Consulta la página de la red Bittensor para detalles de endpoints y transporte, y la página de precios de RPC para comparar planes. Hay una lista completa de cadenas disponible en la página de redes RPC compatibles.