¿Qué necesita realmente una aplicación de minería de Bittensor de la infraestructura RPC?

Una aplicación de minería de Bittensor no es un programa descargable con un botón de inicio. Es un pequeño stack de procesos que se comunican con la cadena Bittensor, y la parte que la mayoría de la gente subestima es la capa RPC subyacente. Si tu minero puede registrar una hotkey pero no puede leer el metagraph de manera confiable, o si tu validador pierde su suscripción WebSocket a mitad de época, la aplicación parece rota aunque la lógica de minería esté bien.

Esta página explica qué contiene realmente el stack, cómo apuntarlo a Bittensor Finney y cómo decidir si un endpoint público compartido, una API RPC gestionada o un nodo dedicado es la base adecuada para tu carga de trabajo.

Empieza aquí: ¿qué tipo de aplicación Bittensor estás construyendo?

Antes de elegir un endpoint, decide cuál de estas tres formas coincide con tu proyecto. Tienen perfiles RPC diferentes, y confundirlos es la fuente más común de tiempo de inactividad evitable.

Si estás construyendo un minero, a menudo puedes comenzar en un endpoint compartido y moverte más tarde. Si estás ejecutando un validador o un panel del que dependen otras personas, planifica una conexión dedicada desde el principio, porque una suscripción caída durante el establecimiento de pesos es costosa de depurar después.

Los componentes detrás de una "aplicación de minería"

La mayoría de las guías omiten esto y saltan directamente a los comandos de instalación. Ayuda nombrar las piezas primero:

• Cliente Subtensor — la biblioteca que habla con la cadena Bittensor. Necesita un endpoint RPC, una billetera y un nombre de red.
• Billetera — coldkey y hotkey. La coldkey mantiene el stake; la hotkey firma las acciones del minero o validador.
• Lógica de subred — tu modelo, tu función de puntuación o tu mecanismo de incentivos. Esto se ejecuta fuera de la cadena.
• Servidor Axon — el endpoint que otros participantes llaman para consultar tu minero.
• Lector de cadena — el bucle que extrae el estado del metagraph, el número de bloque y los parámetros de la subred.

El endpoint RPC se encuentra debajo del cliente subtensor y el lector de cadena. Todo lo demás es local. Por eso los problemas de RPC parecen problemas del minero: el proceso del minero está saludable, pero el lector de cadena está desactualizado.

Configuración de la cadena de un vistazo

La mainnet de Bittensor es Finney. Usa estos valores al configurar un cliente, una billetera o una sonda de monitoreo.

OnFinality expone Bittensor Finney como una API RPC gestionada con transportes HTTP y WebSocket, por lo que la misma familia de endpoints puede servir las lecturas puntuales de tu minero y el bucle de suscripción de tu validador. Consulta la página de la red Bittensor Finney para obtener los detalles actuales del endpoint, y precios de RPC si necesitas dimensionar un plan.

Conectar un minero o validador a través de HTTP

La mayoría de los clientes subtensor aceptan una cadena de endpoint. Una forma rápida de confirmar que el endpoint es accesible y devuelve datos de la cadena es una llamada JSON-RPC. Bittensor utiliza métodos estilo Substrate, por lo que los nombres de los métodos difieren de las cadenas EVM.

curl -s https://bittensor-finney.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "chain_getHeader",
    "params": []
  }'

Una respuesta saludable devuelve un objeto de encabezado con un número de bloque. Si obtienes un tiempo de espera agotado o un resultado vacío, el problema es la conexión, no la lógica de tu minero. Verifica el endpoint, luego verifica si tu cliente apunta al nombre de red correcto.

Para un cliente JavaScript, el patrón es el mismo: crea un proveedor con el endpoint, luego lee el encabezado o el metagraph. Mantén la instancia del proveedor de larga duración en lugar de crear una nueva por llamada, porque reconectar en cada solicitud agrega latencia y oculta fallas reales.

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 header = await api.rpc.chain.getHeader();
console.log('current block', header.number.toNumber());

// read subnet state without polling the whole chain
const meta = await api.query.subtensorModule.subnetInfo(1);
console.log(meta.toHuman());

Por qué WebSocket importa más de lo que piensas

Hacer polling de chain_getHeader en un bucle funciona para un panel. Es una mala opción para un validador que necesita reaccionar a nuevos bloques o cambios de época. Los clientes Substrate exponen suscripciones, y un endpoint WebSocket te permite suscribirte una vez y recibir actualizaciones a medida que ocurren.

const unsub = await api.rpc.chain.subscribeNewHeads((header) => {
  console.log('new head', header.number.toNumber());
  // trigger metagraph refresh or weight-setting logic here
});

El modo de falla a tener en cuenta es una caída silenciosa de la suscripción. El cliente permanece conectado, no se lanza ningún error y tu minero deja de reaccionar a nuevos bloques. Agrega un latido: rastrea el último número de bloque que viste, y si no ha avanzado en unos pocos bloques, destruye el proveedor y reconéctate. Esta única verificación previene la mayoría de los incidentes de "mi minero dejó de ganar".

Cuándo un endpoint compartido es suficiente, y cuándo no

Un endpoint público compartido está bien para desarrollo, para un solo minero con volumen de lectura modesto y para scripts exploratorios. Es una opción más débil cuando:

• Ejecutas un validador que establece pesos cada época y no puede tolerar una suscripción caída.
• Operas varios mineros y quieres aislamiento por proceso para que un bucle ruidoso no afecte a los demás.
• Necesitas rendimiento predecible para un panel con muchos lectores concurrentes.
• Quieres registros y métricas vinculados a tu propio tráfico en lugar de un grupo compartido.

En ese punto, la elección es entre una API RPC gestionada y un nodo dedicado. Una API gestionada te brinda un endpoint estable, soporte WebSocket y alguien más manejando las actualizaciones y la sincronización de la cadena. Un nodo dedicado te brinda una instancia privada con tus propios recursos, lo cual importa cuando tu patrón de lectura es intenso o cuando quieres controlar la ventana de actualización alrededor de un cambio de runtime.

Registro, nonces y otros escollos del lado de escritura

Las lecturas son la parte fácil. Las escrituras — registrar una hotkey, establecer pesos, transferir stake — son donde las aplicaciones de minería se rompen de maneras que parecen fallas de RPC pero no lo son.

• Colisiones de nonce. Si dos procesos comparten una coldkey y envían extrinsics al mismo tiempo, uno fallará con un nonce obsoleto. Serializa las escrituras o usa claves separadas por proceso.
• Cambios en el costo de registro. El costo de registro de subred es dinámico. Una transacción que tuvo éxito ayer puede fallar hoy porque el costo cambió. Lee el costo actual antes de enviar.
• Mortalidad y finalidad. Los extrinsics tienen una vida útil limitada. Si tu endpoint está retrasado, la transacción puede expirar antes de ser incluida. Confirma que el bloque contra el que estás construyendo esté actualizado.
• Ventanas de establecimiento de pesos. Los validadores deben establecer pesos dentro de la ventana permitida. Un lector de cadena lento o desactualizado puede hacer que la pierdas.

Ninguno de estos se resuelve solo con un endpoint más rápido, pero un endpoint estable los hace más fáciles de diagnosticar, porque puedes confiar en que los datos de bloque que estás leyendo están actualizados.

Una sonda de monitoreo mínima

Cualquiera sea el endpoint que elijas, agrega una sonda que se ejecute independientemente de tu minero. Debe responder una pregunta: ¿están frescos los datos de la cadena que estoy leyendo?

#!/usr/bin/env bash
ENDPOINT="https://bittensor-finney.api.onfinality.io/public"
BLOCK=$(curl -s "$ENDPOINT" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"chain_getHeader","params":[]}' \
  | grep -o '"number":"0x[0-9a-f]*"' | head -1)
echo "probe block: $BLOCK"

Ejecútala según un programa, registra el número de bloque y alerta si deja de avanzar. Esto es más útil que una simple verificación de tiempo de actividad, porque un endpoint puede estar activo y aún así estar retrasado.

Ruta de depuración cuando tu minero deja de funcionar

Trabaja en estos en orden. La mayoría de los incidentes se resuelven en los primeros tres pasos.

1. ¿Está respondiendo el endpoint? Ejecuta la sonda curl anterior. Si se agota el tiempo, el problema es la conectividad o el endpoint mismo.
2. ¿Está avanzando el número de bloque? Si responde pero el bloque está desactualizado, puede que estés en un nodo retrasado. Cambia de endpoint y vuelve a verificar.
3. ¿Está viva tu suscripción WebSocket? Si usas suscripciones, confirma que sigues recibiendo encabezados. Reconéctate si no.
4. ¿Está tu billetera cargada y desbloqueada? Una coldkey bloqueada produce errores de firma que en algunos clientes parecen errores de RPC.
5. ¿Sigue siendo válido el costo de registro? Vuelve a leer el costo actual antes de reenviar.
6. ¿Hay otro proceso usando la misma clave? Verifica colisiones de nonce entre tus procesos de minero y validador.

Si los pasos uno a tres pasan y el minero aún no gana, el problema está en tu lógica de subred, no en tu conexión RPC.

Conclusiones clave

• Una aplicación de minería de Bittensor es un stack: cliente subtensor, billetera, lógica de subred, servidor axon y un lector de cadena. El endpoint RPC se encuentra debajo de los dos últimos.
• La mainnet de Bittensor es Finney, con TAO como moneda nativa. OnFinality lo sirve tanto por HTTP como por WebSocket.
• Usa HTTP para lecturas puntuales y WebSocket para suscripciones. Agrega un latido para que una caída silenciosa de la suscripción no detenga tu minero.
• Los endpoints compartidos están bien para desarrollo y mineros individuales. Los validadores, configuraciones multi-minero y paneles deben usar una API RPC gestionada o un nodo dedicado.
• La mayoría de las "fallas de RPC" en aplicaciones de minería son en realidad colisiones de nonce, costos de registro obsoletos o extrinsics expirados. Verifica esos antes de culpar al endpoint.
• Explora redes RPC compatibles y precios de RPC cuando estés listo para dejar un endpoint compartido.

Preguntas frecuentes

¿Necesito una aplicación especial para minar en Bittensor? No. No hay una única aplicación de minería oficial. Armas un stack con un cliente subtensor, una billetera y tu propia lógica de subred, luego lo conectas a un endpoint RPC de Bittensor.

¿Qué endpoint debo usar para Bittensor Finney? OnFinality expone Bittensor Finney a través de HTTP y WebSocket. Usa https://bittensor-finney.api.onfinality.io/public para lecturas y wss://bittensor-finney.api.onfinality.io/public-ws para suscripciones. Los detalles actuales están en la página de la red Bittensor Finney.

¿Puedo ejecutar un minero en un endpoint público compartido? Sí, para desarrollo y configuraciones de un solo minero de bajo volumen. Si ejecutas un validador o varios mineros, una API RPC gestionada o un nodo dedicado reduce la posibilidad de que el tráfico de otra persona afecte tus lecturas.

¿Por qué mi minero deja de ganar aunque el proceso esté en ejecución? Generalmente es un lector de cadena desactualizado o una suscripción WebSocket caída. Agrega un latido que verifique si el número de bloque está avanzando, y reconéctate si no lo está.

¿Qué causa extrinsics fallidos en Bittensor? Las causas comunes son colisiones de nonce cuando dos procesos comparten una clave, cambios en el costo de registro y extrinsics que expiran antes de la inclusión. Lee el estado actual de la cadena antes de enviar.

¿Cuándo debo pasar a un nodo dedicado? Cuando necesitas rendimiento predecible, aislamiento por proceso o control sobre la ventana de actualización alrededor de un cambio de runtime. Un nodo dedicado es el siguiente paso habitual después de una API RPC gestionada.