Resumen
Este tutorial recorre las partes prácticas de construir sobre Bittensor: conectarse a la cadena Subtensor a través de RPC, leer el estado del metagrafo y de la subred, y enviar extrinsics con el SDK de Python. Se centra en la capa de conexión que la mayoría de los tutoriales omiten, para que tus scripts se mantengan confiables a medida que pasas de experimentos locales a algo que se ejecuta continuamente.
Verás cómo configurar un endpoint WebSocket, ejecutar llamadas JSON-RPC y del SDK, y decidir cuándo un endpoint público compartido es suficiente frente a cuándo un nodo dedicado tiene más sentido. El objetivo es una configuración funcional que puedas extender a mineros, validadores, paneles o herramientas de subred.
Bittensor es una red descentralizada de subredes de aprendizaje automático, y la cadena que las coordina a todas es Subtensor. Si buscaste un tutorial de Bittensor, probablemente quieras hacer algo concreto: leer datos de una subred, registrar una hotkey, ejecutar un minero o construir un panel. Casi todas esas tareas comienzan con el mismo paso: obtener una conexión confiable a Subtensor.
Este tutorial está construido en torno a esa capa de conexión. En lugar de solo explicar qué es Bittensor, muestra cómo conectarse, qué llamadas hacer primero y cómo decidir si un endpoint público compartido o un nodo dedicado se ajusta a tu carga de trabajo. Puedes seguirlo con el SDK de Python o con JSON-RPC sin procesar.
Empieza aquí: elige tu ruta de conexión
Antes de escribir código, decide cómo hablarás con Subtensor. La elección correcta depende de si estás explorando, ejecutando un proceso de larga duración o sirviendo a otros usuarios.
| Tu situación | Conexión recomendada | Por qué |
|---|---|---|
| Aprendizaje, scripts únicos, leer algunos valores | Endpoint RPC público compartido | Rápido de configurar, sin infraestructura que gestionar |
| Minero o validador ejecutándose continuamente | Nodo dedicado o un plan de proveedor con capacidad estable | Las sesiones WebSocket de larga duración y el rendimiento constante importan |
| Panel o aplicación que sirve a muchos usuarios | RPC de proveedor con monitoreo y failover | Necesitas capacidad predecible y una ruta de respaldo |
| Indexación de datos históricos de la cadena | Nodo con capacidad de archivo | Se requiere el historial completo para rellenos |
Si recién comienzas el tutorial, usa un endpoint público y continúa. Vuelve a esta tabla cuando tu script necesite permanecer en línea.
Qué es realmente Subtensor
Subtensor es una blockchain basada en Substrate. Eso importa porque da forma a cómo interactúas con ella. No llamas a contratos inteligentes como lo harías en una cadena EVM. En su lugar, lees el estado de la cadena a través de consultas de almacenamiento y envías extrinsics (transacciones) que se asignan a pallets específicos.
Las piezas que tocarás con más frecuencia:
- Subredes — redes independientes de mineros y validadores, cada una identificada por un netuid.
- Metagrafo — la instantánea por subred de neuronas, sus stakes, incentivos y rangos.
- Hotkeys y coldkeys — las hotkeys firman la actividad operativa, las coldkeys mantienen el stake y controlan el registro.
- TAO — el token nativo utilizado para staking, registro e incentivos.
Debido a que Subtensor está basado en Substrate, la mayoría de las herramientas utilizan el stack estilo Polkadot: los paquetes Python substrate-interface o bittensor, o polkadot-js en JavaScript. La capa RPC subyacente es JSON-RPC estándar de Substrate.
Conéctate a Subtensor a través de RPC
OnFinality expone Bittensor Finney mainnet tanto por HTTP como por WebSocket. Los endpoints públicos son:
- HTTP:
https://bittensor-finney.api.onfinality.io/public - WebSocket:
wss://bittensor-finney.api.onfinality.io/public-ws
Para la mayoría del trabajo con Bittensor querrás el endpoint WebSocket, porque los SDK y las suscripciones dependen de él. Una verificación rápida de que el nodo es accesible y devuelve metadatos de la cadena:
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 el nombre de la cadena. Si obtienes un error de conexión, el endpoint o tu red son lo primero que debes verificar. Si obtienes un error JSON-RPC, el nombre del método o los parámetros son la causa probable.
Para cualquier cosa interactiva, cambia a WebSocket. En Python con el SDK de Bittensor:
import bittensor as bt
subtensor = bt.subtensor(network="wss://bittensor-finney.api.onfinality.io/public-ws")
print(subtensor.get_current_block())
print(subtensor.get_total_stake())
Si prefieres la interfaz Substrate de más bajo nivel, el mismo endpoint funciona:
from substrateinterface import SubstrateInterface
substrate = SubstrateInterface(
url="wss://bittensor-finney.api.onfinality.io/public-ws"
)
print(substrate.get_chain_head())
Ambos enfoques se conectan al mismo nodo; el SDK simplemente envuelve las llamadas comunes de Bittensor para ti.
Lee datos de subred y metagrafo
Lo primero útil que hacen la mayoría de los tutoriales es leer el estado de una subred. El metagrafo te da una instantánea de cada neurona en una subred, incluyendo stake, incentivo y consenso. Estos son los datos que los mineros y validadores usan para tomar decisiones.
Con el SDK de Bittensor:
import bittensor as bt
subtensor = bt.subtensor(network="wss://bittensor-finney.api.onfinality.io/public-ws")
metagraph = subtensor.metagraph(netuid=1)
print("neurons:", metagraph.n)
print("top incentive:", metagraph.incentive.max())
print("total stake:", metagraph.total_stake)
El metagrafo es una vista en un punto en el tiempo. Si estás construyendo un panel o un minero que reacciona a los cambios, necesitas actualizarlo en un intervalo o suscribirte a nuevos bloques. Ahí es donde la calidad de la conexión comienza a importar: una actualización del metagrafo en una subred ocupada extrae una cantidad significativa de datos, y hacerlo en cada bloque a través de una conexión inestable producirá vacíos.
Un bucle de sondeo simple se ve así:
import time
import bittensor as bt
subtensor = bt.subtensor(network="wss://bittensor-finney.api.onfinality.io/public-ws")
last_block = 0
while True:
block = subtensor.get_current_block()
if block != last_block:
metagraph = subtensor.metagraph(netuid=1)
print(block, metagraph.n, float(metagraph.total_stake))
last_block = block
time.sleep(6)
Ajusta el intervalo de espera a tus necesidades. Sondear cada bloque está bien para una sola subred; sondear muchas subredes a la vez es una carga de trabajo más pesada y una buena razón para pasar a un nodo dedicado.
Envía un extrinsic sin romper cosas
Leer datos es seguro. Escribir en la cadena es donde los errores cuestan dinero, así que trata esta sección como una lista de verificación en lugar de un script para copiar y pegar.
- Usa primero una testnet o una hotkey de bajo valor. Confirma que tu extrinsic se construye y se envía antes de tocar stake real.
- Verifica el bloque actual y el saldo de tu cuenta antes de enviar, para que sepas que la transacción es válida en ese momento.
- Establece una era y una propina sensatas. Una era corta evita que la transacción se quede; una propina puede ayudar a la inclusión durante la congestión.
- Espera la finalización, no solo el envío. Un extrinsic enviado aún puede fallar.
Un extrinsic mínimo estilo transferencia con el SDK:
import bittensor as bt
wallet = bt.wallet(name="my_coldkey", hotkey="my_hotkey")
subtensor = bt.subtensor(network="wss://bittensor-finney.api.onfinality.io/public-ws")
result = subtensor.transfer(
wallet=wallet,
dest_ss58="5F...destination...",
amount=bt.Balance.from_tao(0.1),
)
print(result)
Reemplaza el destino y la cantidad con tus propios valores. El hábito importante es registrar el hash del extrinsic y verificar su estado en lugar de asumir el éxito.
Modos de fallo comunes y cómo depurarlos
La mayoría de los problemas de conexión de Bittensor caen en un pequeño número de categorías. Esta tabla asigna el síntoma a la causa probable.
| Síntoma | Causa probable | Qué probar |
|---|---|---|
| WebSocket se desconecta después de un tiempo | Tiempo de espera inactivo o endpoint inestable | Reconectar con retroceso; usar un nodo dedicado para sesiones largas |
Method not found | Nombre de método incorrecto o tipo de endpoint | Confirmar que estás en un endpoint JSON-RPC de Substrate, no en uno EVM |
| El metagrafo devuelve datos obsoletos | Nodo en caché o retrasado | Consultar el bloque actual y comparar; cambiar de endpoint |
| Extrinsic enviado pero nunca finalizado | Era expirada o tarifa demasiado baja | Reenviar con una era fresca y una propina adecuada |
| Respuestas lentas durante actividad pico | Endpoint compartido bajo carga | Mover cargas de trabajo pesadas o continuas a un nodo dedicado |
El patrón es consistente: las llamadas ocasionales de solo lectura toleran endpoints compartidos, mientras que el trabajo continuo o de alto volumen se beneficia de capacidad dedicada.
Cuándo un endpoint compartido no es suficiente
Un endpoint público está bien para aprender y para scripts ligeros. Se convierte en un problema cuando tu proceso necesita permanecer conectado durante horas, actualizar metagrafos en muchas subredes o servir a otros usuarios. En ese punto ya no estás depurando tu código, estás depurando tu infraestructura.
OnFinality proporciona RPC de Bittensor a través de endpoints API compartidos y nodos dedicados. Un nodo dedicado le da a tu carga de trabajo su propia capacidad, lo que ayuda cuando ejecutas mineros, validadores o paneles que no pueden permitirse vacíos de conexión. Puedes revisar Precios de RPC y la página de la red Bittensor para ver qué se ajusta a tu carga de trabajo, y comparar opciones con otras redes RPC compatibles si operas en varias cadenas.
Si estás evaluando proveedores en general, aplican los mismos criterios: soporte de transporte (HTTP y WebSocket), disponibilidad de archivo si necesitas historial, y cómo se maneja el failover. Una breve lista de verificación para elegir un proveedor de RPC cubre esas compensaciones con más detalle.
Un primer proyecto práctico
Si quieres un objetivo concreto para este tutorial, construye un pequeño monitor de subred. Debería:
- Conectarse a Subtensor a través de WebSocket.
- Sondear el bloque actual en un intervalo.
- Actualizar el metagrafo para una o dos subredes en cada bloque.
- Imprimir o almacenar el recuento de neuronas, el stake total y el incentivo principal.
- Reconectarse automáticamente si el WebSocket se cae.
Ese proyecto ejercita cada parte de la capa de conexión que reutilizarás más adelante: selección de endpoint, seguimiento de bloques, consultas de estado y lógica de reconexión. Una vez que se ejecute de manera confiable durante un día, tendrás una base para herramientas de minero o validador.
Puntos clave
- Subtensor es una cadena basada en Substrate, por lo que interactúas a través de consultas de almacenamiento y extrinsics en lugar de contratos EVM.
- Usa el endpoint WebSocket para trabajo con SDK y suscripciones; HTTP está bien para verificaciones rápidas de JSON-RPC.
- El metagrafo es una instantánea: actualízalo en un intervalo o por bloque si tu lógica depende del estado actual.
- Trata el envío de extrinsics como una lista de verificación: prueba primero, verifica saldo y bloque, espera la finalización.
- Los endpoints públicos compartidos son adecuados para aprendizaje y scripts ligeros; los nodos dedicados son adecuados para mineros, validadores y paneles continuos.
Preguntas frecuentes
¿Necesito un nodo para seguir este tutorial de Bittensor?
No. Puedes completar el tutorial usando un endpoint RPC público compartido. Un nodo dedicado se vuelve útil cuando tu proceso necesita permanecer conectado continuamente o manejar un volumen mayor.
¿Qué endpoint debo usar, HTTP o WebSocket?
Usa WebSocket para trabajo con SDK, suscripciones y cualquier cosa de larga duración. Usa HTTP para llamadas JSON-RPC rápidas y verificaciones de estado.
¿Por qué mi metagrafo parece desactualizado?
Es posible que estés leyendo de un nodo que está retrasado o en caché. Compara el bloque actual entre endpoints y cambia si los valores divergen.
¿Puedo ejecutar esto contra una testnet?
Sí. El flujo de trabajo es el mismo; solo cambia el endpoint. Prueba extrinsics en una testnet o con una hotkey de bajo valor antes de tocar stake real.
¿Cómo mantengo un minero o validador en línea?
Ejecútalo contra un endpoint estable, agrega lógica de reconexión con retroceso y considera un nodo dedicado para que tu conexión no dependa de capacidad compartida.
Próximos pasos
Una vez que tu monitor se ejecute de manera confiable, extiéndelo: agrega alertas cuando la distribución de incentivos de una subred cambie, almacena instantáneas históricas del metagrafo o conéctalo a un minero que se ajuste según el estado en vivo. Cada uno de esos pasos aumenta tu dependencia de una conexión estable, así que planifica tu estrategia de endpoints antes de escalar. Comienza con la página de la red Bittensor para detalles del endpoint, y revisa nodos dedicados cuando estés listo para dejar la capacidad compartida.