Lectura del estado del metagrafo de Bittensor: pesos, emisiones y dividendos desde un nodo subtensor

Qué es el metagrafo y dónde se encuentra

Bittensor es una blockchain basada en Substrate (la red Finney) que mantiene un registro de subredes, cada una identificada por un netuid. Dentro de cada subred, las entidades registradas se denominan neuronas y se identifican mediante un UID único. El metagrafo es la vista agregada y observable de este registro por subred: incluye el stake de cada neurona, el stake de delegación (TAO delegado), los pesos, la confianza, los rangos de consenso, el incentivo y los dividendos. Este estado no se almacena como un único blob JSON; se deriva del almacenamiento del runtime del pallet subtensor. La documentación oficial de Bittensor describe el mecanismo de incentivos de la red, y el código fuente de subtensor (disponible en GitHub) implementa las fórmulas exactas.

Cuando se conecta a un endpoint de subtensor (como uno proporcionado por la guía de RPC de Bittensor de OnFinality), se accede a la interfaz JSON-RPC de la cadena Finney. El metagrafo no se expone como un único método RPC; en su lugar, se consultan los mapas de almacenamiento subyacentes para las neuronas de la subred y luego se calculan los campos derivados. Las herramientas y los indexadores de la comunidad (por ejemplo, taostats o el SDK de Python bittensor) realizan esta agregación por usted, pero son capas de conveniencia de terceros. Para confiar en los datos, debe verificarlos contra el estado de la cadena, como se describe en este artículo.

• El estado del metagrafo se almacena en los mapas de almacenamiento del pallet subtensor, con clave por netuid y UID o hotkey.
• La forma canónica de leerlo es mediante consultas de estado de Substrate (por ejemplo, state_getStorage o la superficie RPC subnetInfo).
• Las API de terceros son vistas derivadas; siempre verifique con un nodo subtensor local o de confianza.

El modelo económico: de los pesos a las emisiones y dividendos

Cada subred ejecuta un juego de incentivos competitivo. Los validadores establecen periódicamente pesos para los mineros: un vector de valores, uno por UID, basado en sus propias puntuaciones de calidad. Estos pesos se almacenan en cadena y se utilizan para calcular las puntuaciones de consenso. El mecanismo de consenso es un juego de estilo Schelling: los validadores que establecen pesos cercanos a la mediana ponderada de la red son recompensados, mientras que los que se desvían son penalizados. El algoritmo exacto está implementado en el código fuente de subtensor y se describe en la documentación oficial de Bittensor sobre validación.

Las emisiones se distribuyen por época según el presupuesto alfa/enlace de una subred. Cada subred recibe una parte de la emisión total de TAO, y esa parte se divide entre los mineros según sus puntuaciones de incentivo. Los validadores reciben dividendos: una parte de la emisión de la subred que refleja su stake ponderado por consenso. Es importante destacar que los dividendos no son lo mismo que la recompensa de minería del propio validador; son el derecho del validador sobre la emisión de la subred en función de qué tan bien se alinean sus pesos con la red. El campo stake-from rastrea el TAO delegado, y las recompensas se dividen entre el stake propio del validador y el stake delegado. Por lo tanto, cuando vea una cifra de 'APR' o 'recompensas', debe descomponerla en el rendimiento propio del validador y la parte del delegador.

El intervalo de emisión preciso y la cadencia de recompensas evolucionan con el tiempo. Siempre confirme los parámetros actuales en los documentos oficiales o leyendo las constantes del runtime de la cadena. Nunca asuma un número diario fijo sin verificarlo.

• Los pesos son un vector por UID establecido por los validadores cada época.
• Las puntuaciones de consenso determinan el orden de los pagos de incentivos.
• Los dividendos son la parte del validador del consenso sobre el incentivo de los mineros.
• Los rendimientos de stake-from fluyen a los delegadores, por lo que las recompensas deben dividirse.

Superficies de lectura prácticas: RPC de subtensor e indexadores fuera de cadena

Hay dos formas prácticas de leer el metagrafo. La primera es consultar un nodo subtensor directamente. Un nodo completo sincronizado expone el almacenamiento sin procesar a través de métodos RPC de Substrate. Por ejemplo, puede usar el método state_getStorage con la clave de almacenamiento adecuada, o usar la superficie RPC subnetInfo que proporcionan algunas implementaciones de nodos. El SDK de Python bittensor de la comunidad envuelve estas llamadas y ofrece un objeto metagraph que obtiene y calcula el estado. El segundo enfoque es usar un indexador fuera de cadena o un explorador de bloques que ya calcule el consenso y las emisiones. Estos son convenientes, pero deben validarse contra el estado de la cadena.

Al usar un endpoint RPC de subtensor, tenga en cuenta que el nodo debe estar sincronizado y no rezagado respecto al último bloque de la cadena. Un nodo rezagado devolverá datos obsoletos. Consulte nuestra guía sobre detección de un nodo RPC rezagado respecto al último bloque para conocer los métodos de verificación. Además, diferentes proveedores pueden tener diferentes límites de velocidad y métodos admitidos; consulte las páginas de precios de RPC y servicio de API para obtener más detalles.

• Consulta directa al nodo: use state_getStorage o la superficie RPC subnetInfo.
• Los SDK de la comunidad (por ejemplo, el paquete de Python bittensor) proporcionan un objeto metagraph.
• Los indexadores como taostats son de terceros; siempre verifique con el estado de la cadena.

Ejemplo reproducible: lectura de stake y pesos para una hotkey específica

El siguiente ejemplo usa el SDK de Python bittensor para conectarse a un endpoint de subtensor y leer el metagrafo de una subred específica. Reemplace wss://your-subtensor-endpoint con su endpoint real (por ejemplo, de la guía de RPC de Bittensor de OnFinality). El script obtiene el metagrafo de la subred 1 e imprime el stake, los pesos, el incentivo y los dividendos para una hotkey determinada.

import bittensor as bt

# Connect to a subtensor node
subtensor = bt.subtensor(network="wss://your-subtensor-endpoint")

# Fetch the metagraph for subnet 1
metagraph = subtensor.metagraph(netuid=1)

# Specify a hotkey to inspect
hotkey = "5C..."  # replace with actual hotkey

# Find the UID for this hotkey
uid = metagraph.hotkeys.index(hotkey)

print(f"UID: {uid}")
print(f"Stake: {metagraph.S[uid]}")
print(f"Weights: {metagraph.W[uid]}")
print(f"Incentive: {metagraph.I[uid]}")
print(f"Dividends: {metagraph.D[uid]}")
print(f"Trust: {metagraph.T[uid]}")
print(f"Stake-from: {metagraph.ST[uid]}")

Salida esperada y cómo conciliar las recompensas reportadas

La salida mostrará los valores sin procesar de la cadena. Por ejemplo, el stake está en Tao (con precisión de 10^9), los pesos están normalizados y el incentivo/dividendos también están en Tao. Para conciliar una cifra de 'APR' o 'recompensas' reportada, debe comprender el programa de emisiones. La emisión total por subred está determinada por la tasa de emisión de la red y el alfa de la subred. El incentivo para un minero es el producto de la emisión de la subred y la puntuación de incentivo del minero. Para un validador, los dividendos son la suma del incentivo de los mineros en los que apuesta, ponderado por su stake. La tabla a continuación proporciona una plantilla para completar con sus propios datos y verificar una reclamación de recompensa.

Tenga en cuenta que el intervalo de emisión exacto y los valores alfa cambian con el tiempo. Siempre verifique los parámetros actuales en los documentos oficiales o leyendo las constantes del runtime de la cadena. La siguiente tabla es una plantilla para su propia verificación.

• El stake está en Tao con precisión de 10^9 (u64).
• Los pesos son un vector de flotantes, normalizados para sumar 1.
• El incentivo y los dividendos están en Tao por época.
• Para calcular el APR, necesita la duración de la época y la tasa de emisión.

| Field | Value from chain | Reported value | Difference |
|-------|------------------|----------------|------------|
| Stake (Tao) | 123.456 | 123.456 | 0 |
| Incentive (Tao/epoch) | 0.001 | 0.001 | 0 |
| Dividends (Tao/epoch) | 0.0005 | 0.0005 | 0 |
| APR (calculated) | 12.3% | 12.3% | 0 |

Lista de verificación para la solución de problemas en lecturas del metagrafo

Al leer el metagrafo, puede encontrar varios problemas comunes. Primero, si está leyendo desde un nodo local no finalizado, los datos pueden estar rezagados respecto al último bloque de la cadena. Use los métodos de nuestra guía de detección de rezago para verificar. Segundo, un error de 'hotkey no encontrada' a menudo significa que el UID ha sido dado de baja o que la hotkey ha cambiado. Tercero, los pesos solo se actualizan en cada ventana de época, por lo que una lectura obsoleta es normal si consulta entre actualizaciones. Cuarto, tenga en cuenta la codificación de las cantidades u64/u128: los montos de TAO se almacenan con precisión de 10^9, por lo que debe dividir por 10^9 para obtener Tao. Finalmente, diferentes implementaciones de nodos (archivo vs. solicitudes/state_query) pueden tener diferente comportamiento y límites de velocidad; consulte la documentación de su proveedor.

• Rezago del nodo: verifique que el nodo esté en el último bloque.
• Hotkey no encontrada: verifique si el UID sigue registrado.
• Los pesos se actualizan por época: espere obsolescencia entre actualizaciones.
• Codificación de cantidades: divida por 10^9 para obtener Tao.
• Diferencias de proveedor: los nodos de archivo pueden tener diferentes métodos RPC y límites.

Limitaciones y compensaciones de las lecturas en cadena

Leer el metagrafo directamente desde un nodo subtensor le brinda los datos más autorizados, pero requiere un nodo sincronizado y cierto esfuerzo computacional para derivar el metagrafo. Los indexadores de terceros brindan conveniencia, pero pueden introducir latencia o errores de agregación. Además, la superficie RPC de subtensor no está estandarizada en todas las implementaciones de nodos; algunos métodos pueden estar obsoletos o ser específicos de una versión. Siempre consulte el código fuente oficial de subtensor y la documentación para conocer las claves de almacenamiento y las fórmulas exactas.

Para aplicaciones de producción, considere usar un proveedor de RPC confiable como la guía de RPC de Bittensor de OnFinality para garantizar disponibilidad y rendimiento. Consulte nuestra guía de rendimiento y latencia para conocer los puntos de referencia y las mejores prácticas. Si encuentra tiempos de espera o errores, consulte nuestra guía de tiempos de espera y errores.

Próximos pasos: validar, monitorear y construir

Ahora que comprende cómo leer el metagrafo, puede construir herramientas que verifiquen el rendimiento de los validadores, realicen un seguimiento de las emisiones o creen paneles de control. Comience validando algunas hotkeys contra una fuente confiable. Luego, configure el monitoreo de sus endpoints RPC para asegurarse de que no estén rezagados; consulte nuestra guía de monitoreo. Para una inmersión más profunda en la red Bittensor, explore la descripción general de la red Bittensor Finney.

Si está construyendo aplicaciones que dependen de los datos del metagrafo, considere usar un servicio de API dedicado para manejar la carga. Consulte nuestro servicio de API y precios de RPC para conocer las opciones. Finalmente, siempre verifique con la documentación oficial de Bittensor y el código fuente de subtensor para conocer los últimos cambios en el mecanismo.

• Valide sus lecturas contra una segunda fuente.
• Monitoree sus endpoints RPC para detectar rezagos y salud.
• Explore la red Bittensor Finney para obtener más contexto.
• Use el centro de aprendizaje de OnFinality para obtener más guías.