Resumen
Minar TAO en Bittensor no es hashing de prueba de trabajo. Registras una hotkey en una subred, ejecutas un minero que produce la tarea que esa subred recompensa y mantienes una conexión a la cadena lo suficientemente saludable como para establecer pesos, reclamar emisiones y volver a registrarte cuando te desregistran. El lado de la cadena de ese bucle es donde la mayoría de los mineros pierde dinero: una conexión RPC caída durante el establecimiento de pesos o el registro puede costarte un tempo completo de emisiones.
Este artículo se centra en el lado operativo de la minería de TAO: con qué habla realmente el minero, cómo funcionan el registro y la desregistración, qué llamadas RPC importan y cómo decidir entre ejecutar tu propio nodo Subtensor y usar un endpoint RPC de Bittensor gestionado como OnFinality. Complementa los artículos más amplios sobre minería y nodos de Bittensor en lugar de repetirlos.
Minar TAO en Bittensor se describe a menudo como "minería", pero no se hashea nada. No hay un rompecabezas de prueba de trabajo ni una carrera de GPU para encontrar un bloque. Un minero de Bittensor es un proceso que registra una hotkey en una subred, produce cualquier salida que esa subred recompense y luego depende de la cadena para puntuarla, ponderarla y pagarla en emisiones de TAO. Si vienes de la minería de Bitcoin o Ethereum, el modelo mental es incorrecto de una manera que importa: tu cuello de botella rara vez es el cómputo bruto, es mantenerte registrado y establecer tus pesos a tiempo.
Por eso este artículo trata la minería de TAO como un problema de operaciones primero y un problema de modelado segundo. El modelo es tu negocio, la conexión a la cadena es tu tiempo de actividad.
Qué sucede realmente cuando "minas" TAO
Una subred de Bittensor es un mercado competitivo. Los mineros envían trabajo, los validadores puntúan ese trabajo y la cadena convierte esas puntuaciones en emisiones. Tu minero gana TAO cuando se cumplen tres condiciones al mismo tiempo:
- Tu hotkey está registrada en la subred (tienes un UID).
- Tu minero responde a las consultas de los validadores dentro de la ventana de tempo de la subred.
- Los validadores están estableciendo pesos que reflejan tu puntuación, y esos pesos llegan a la cadena.
Rompe cualquiera de esas condiciones y tus emisiones se van a cero durante ese tempo. El registro es la parte que la gente subestima. Cada subred tiene un número fijo de UIDs, por lo que registrarse significa superar la oferta de quien posee actualmente el slot que quieres. Si tu minero tiene un rendimiento inferior, te desregistran y tu slot se recicla a un nuevo registrante. Volver a registrarse cuesta TAO de nuevo.
Así que el bucle real de minería se ve así: registrarse, ejecutar, ser puntuado, establecer pesos, cobrar emisiones, monitorear la desregistración, volver a registrarse si es necesario. Todo excepto el modelo en sí se ejecuta a través de RPC.
Guía de decisión: ¿nodo Subtensor propio o RPC de Bittensor gestionado?
Antes de ajustar un modelo, decide cómo tu minero llegará a la cadena. Esta es la única elección que más afecta si tu minero permanece en línea.
| Situación | Nodo Subtensor autoalojado | RPC de Bittensor gestionado |
|---|---|---|
| Ejecutas un minero y quieres empezar hoy | El tiempo de sincronización y el costo de disco se pagan por adelantado; puede que esperes antes de tu primer registro | Puedes apuntar tu minero a un endpoint de inmediato y registrarte el mismo día |
| Ejecutas muchos mineros o muchas subredes | Un nodo puede servir a muchas hotkeys, pero tú eres dueño de cada modo de fallo | Cada hotkey puede compartir un endpoint gestionado; el failover es problema del proveedor |
| Necesitas datos de stake de archivo o históricos | Debes ejecutar un nodo de archivo y gestionar su almacenamiento | Verifica si el proveedor expone consultas de tipo archivo antes de comprometerte |
| Necesitas establecimiento de pesos de baja latencia en los límites de tempo | Un nodo local evita un salto de red, pero solo si está saludable | Un endpoint gestionado cercano más lógica de reintento suele superar a un nodo local no saludable |
| Estás experimentando y eres sensible al costo | El hardware y el tiempo de sincronización son el costo | El RPC de pago por uso mantiene bajo el costo fijo |
Un camino intermedio práctico: ejecuta un nodo Subtensor local para desarrollo y para leer el estado de la cadena, y usa un endpoint gestionado como la conexión de la que realmente dependen tus scripts de minero y validador en producción. OnFinality expone un endpoint de Bittensor Finney tanto por HTTP como por WebSocket, lo que cubre los dos patrones de acceso que más usan los mineros: extrinsics de una sola vez y observación de bloques basada en suscripción. Consulta la página de red de Bittensor Finney para los detalles actuales del endpoint, y Precios de RPC si quieres dimensionar el costo según tu número de hotkeys.
Registro, desregistración y las llamadas que importan
La mayoría de las herramientas de Bittensor envuelven estas llamadas, pero conocerlas te ayuda a depurar. La cadena es Subtensor y expone una interfaz JSON-RPC estilo Substrate.
| Tarea | Qué llamas | Por qué le importa a un minero |
|---|---|---|
| Verificar tu UID en una subred | Búsqueda de neuronInfo / uid a través del SDK de Bittensor, respaldada por state_getStorage | Confirma que sigues registrado antes de dedicar tiempo a ajustar |
| Leer el costo de registro actual | Valor de burn / recycle en la subred | Te dice cuánto costará el re-registro ahora mismo |
| Registrar una hotkey | Extrinsic burnedRegister | El momento en que tu slot está activo; si esto falla a mitad de tempo, pierdes tiempo |
| Establecer pesos como validador | Extrinsic set_weights | Si esto no llega, los mineros que puntuaste no reciben nada y tú tampoco |
| Observar nuevos bloques | chain_subscribeNewHeads por WebSocket | Permite que tu minero reaccione en los límites de tempo en lugar de sondear a ciegas |
| Verificar tu saldo | system_accountNextIndex y consultas de saldo | Evita colisiones de nonce cuando envías varios extrinsics seguidos |
Dos modos de fallo aparecen constantemente. Primero, colisiones de nonce: si disparas un extrinsic de registro y uno de establecimiento de pesos seguidos, pueden compartir un nonce y uno se descarta. Segundo, lecturas obsoletas: si tu endpoint está detrás de la cabeza de la cadena, puedes creer que estás registrado cuando no lo estás, o establecer pesos contra un tempo antiguo.
Aquí tienes una sonda de salud mínima que puedes ejecutar contra cualquier endpoint de Bittensor antes de apuntar un minero a él:
curl -s -X POST https://bittensor-finney.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "chain_getHeader",
"params": []
}'
Si eso devuelve un encabezado de bloque reciente, el endpoint es accesible y sigue la cadena. Compara el número de bloque con una segunda fuente antes de confiar en él para el establecimiento de pesos.
Conectar un minero a un endpoint WebSocket
Los mineros y validadores que necesitan actuar en los límites de tempo deberían suscribirse en lugar de sondear. Una conexión WebSocket te permite reaccionar a nuevos encabezados a medida que llegan, que es exactamente lo que quieres cuando se abre una ventana de establecimiento de pesos.
import { ApiPromise, WsProvider } from "@polkadot/api";
const provider = new WsProvider(
"wss://bittensor-finney.api.onfinality.io/public-ws"
);
const api = await ApiPromise.create({ provider });
// React to each new block head instead of polling on a timer.
const unsubscribe = await api.rpc.chain.subscribeNewHeads((header) => {
const blockNumber = header.number.toNumber();
console.log("new head", blockNumber);
// Your tempo logic goes here: check UID, check stake,
// decide whether this is the block to set weights.
});
// Always keep a handle so you can unsubscribe cleanly on shutdown.
process.on("SIGINT", async () => {
await unsubscribe();
await api.disconnect();
process.exit(0);
});
Dos notas operativas. Primero, trata la suscripción como recuperable: si el socket se cae, reconéctate con retroceso exponencial en lugar de hacer fallar el minero. Segundo, no asumas que una conexión es suficiente para una flota de hotkeys. Un solo WebSocket puede llevar muchas suscripciones, pero un único punto de fallo sigue siendo un único punto de fallo.
Dónde pierden emisiones realmente los mineros
La mayoría de los problemas de "minar TAO" no son problemas de modelo. Son los siguientes, aproximadamente en orden de frecuencia con que afectan:
- Desregistración silenciosa. Tu UID se recicla y tu minero sigue ejecutándose contra un slot que ya no posee. Sondea tu UID periódicamente y alerta ante cambios.
- Establecimiento de pesos que nunca llega. El extrinsic se envía pero no se incluye, a menudo por una colisión de nonce o falta de fondos para la tarifa. Confirma la inclusión, no solo el envío.
- Deriva del endpoint. Tu nodo o endpoint se queda atrás de la cabeza de la cadena. Establecer pesos contra una vista obsoleta es peor que no establecerlos en absoluto.
- Sorpresas en el costo de registro. El costo de reciclaje se mueve con la demanda. Presupuesta el re-registro como un costo recurrente, no como una tarifa única.
- Errores de gestión de claves. Las hotkeys son calientes por una razón. Mantén las coldkeys fuera de línea y nunca dejes que un proceso minero tenga más autoridad de la que necesita.
Un hábito útil es registrar, para cada tempo, tres números: tu UID, la cabeza de la cadena sobre la que actuaste y si tu extrinsic se incluyó. Cuando las emisiones caen, esos tres números suelen decirte cuál de los modos de fallo anteriores sufriste.
Elegir un endpoint para un minero en producción
Si estás evaluando opciones de RPC para un minero de Bittensor, los criterios son más estrechos que una lista de verificación general para dApps. Te importa:
| Qué verificar | Por qué le importa a un minero |
|---|---|
| Soporte de HTTP y WebSocket | Los extrinsics necesitan HTTP; la lógica de límites de tempo necesita WebSocket |
| Frescura de la cabeza de la cadena | Las lecturas obsoletas causan mal establecimiento de pesos y verificaciones de registro falsas |
| Disponibilidad de archivo | Necesario si haces backtesting de puntuaciones o reconstruyes stake histórico |
| Comportamiento de failover | Un minero que no puede reconectarse pierde un tempo, no una solicitud |
| Límites de tasa y concurrencia | Una flota de hotkeys multiplica tu volumen de solicitudes |
| Cómo pagas | El precio por solicitud se adapta mejor al tráfico irregular de mineros que las tarifas planas |
OnFinality proporciona acceso a Bittensor Finney como una API RPC gestionada, y para equipos que ejecutan muchas hotkeys o subredes, la infraestructura de nodo dedicado elimina los efectos de vecinos ruidosos y te da un endpoint privado. Si estás comparando proveedores de forma más amplia, la guía de selección de proveedor de RPC cubre el marco de evaluación general, y redes RPC compatibles enumera lo que está disponible hoy.
Una advertencia que aplica a todos los proveedores, incluidos nosotros: no asumas que un endpoint público es el hogar adecuado para la ruta de establecimiento de pesos de un validador. Los endpoints públicos son compartidos. Si tus emisiones dependen de que un extrinsic específico llegue en una ventana específica, dimensiona tu plan y tu failover en consecuencia.
Un plan realista para la primera semana
Si empiezas desde cero, una secuencia que evita las trampas comunes:
- Elige una subred y lee su mecanismo de incentivos antes de escribir cualquier código.
- Ejecuta un nodo Subtensor local o apunta un minero de desarrollo a un endpoint gestionado para aprender el flujo de registro.
- Registra una hotkey y observa un ciclo de tempo completo sin cambiar nada. Registra tu UID, tu puntuación y tus emisiones.
- Añade monitoreo para cambios de UID y frescura de la cabeza de la cadena antes de añadir una segunda hotkey.
- Solo entonces escala a múltiples hotkeys, y decide en ese momento si la infraestructura compartida o dedicada se ajusta a tu tolerancia al riesgo.
El paso tres es el que la gente omite, y es el que te enseña qué recompensa realmente tu subred.
Puntos clave
- La minería de Bittensor es registro más puntuación más establecimiento de pesos, no hashing de prueba de trabajo.
- Tus emisiones dependen de mantenerte registrado y establecer pesos a tiempo; la conexión a la cadena es el riesgo operativo.
- HTTP maneja extrinsics, WebSocket maneja reacciones en límites de tempo; los mineros en producción normalmente necesitan ambos.
- Las colisiones de nonce y las lecturas obsoletas de la cadena son las dos causas más comunes de emisiones perdidas.
- Un endpoint RPC de Bittensor gestionado es un valor predeterminado razonable para mineros en producción; un nodo local sigue siendo útil para desarrollo y depuración profunda.
- Presupuesta el re-registro como un costo recurrente y monitorea tu UID como una métrica de primera clase.
Preguntas frecuentes
¿Minar TAO es lo mismo que minar Bitcoin?
No. No hay prueba de trabajo. Registras una hotkey en una subred, produces la salida que esa subred recompensa y los validadores la puntúan. Las emisiones se derivan de las puntuaciones y los pesos, no de la tasa de hash.
¿Necesito ejecutar mi propio nodo Subtensor para minar TAO?
No necesariamente. Muchos mineros usan un endpoint RPC gestionado para la conexión a la cadena y ejecutan solo el proceso minero. Un nodo local sigue siendo útil para desarrollo, backtesting y depuración cuando sospechas que un endpoint está detrás de la cabeza de la cadena.
¿Qué pasa si mi minero se desconecta?
Dejas de ser puntuado durante ese período, y si tienes un rendimiento inferior durante el tiempo suficiente pueden desregistrarte. Volver a registrarse cuesta TAO, por lo que el tiempo de actividad de la conexión a la cadena tiene un costo directo.
¿Puedo usar un endpoint RPC para muchas hotkeys?
Técnicamente sí, pero vigila la concurrencia y los límites de tasa. Si tus emisiones dependen de un establecimiento de pesos oportuno, considera si el acceso compartido o la infraestructura dedicada se ajusta mejor a tu tolerancia al riesgo.
¿Dónde encuentro los detalles del endpoint de Bittensor?
Los endpoints HTTP y WebSocket actuales para Bittensor Finney se enumeran en la página de red de Bittensor Finney. Para planificar costos con múltiples hotkeys, consulta Precios de RPC.