Estado de staking de Bittensor vía RPC: lectura de delegación, alpha stakes y estado del pool

Por qué un solo número de stake engaña: el modelo vectorial del staking en Bittensor

En Bittensor, la posición de un delegador no es un saldo escalar. Es un vector: stake raíz denominado en TAO, alpha stake mantenido por subred, la hotkey (validador) a la que se delega ese stake y el estado del pool de la subred (reserva de TAO y reserva de alpha) que determina cuánto vale actualmente en TAO una posición de alpha. Tratar 'mi stake' como un solo número producirá paneles, herramientas de validación y scripts de auditoría incorrectos.

La delegación es hacia una hotkey, que forma parte del par coldkey-hotkey de un validador. La misma coldkey puede mantener stake en muchas subredes y muchas hotkeys. Para reportar la posición real de un usuario, debes leer cada entrada de stake por separado y aplicar la conversión correcta para el pool de cada subred.

Esta ruta de lectura es distinta de leer los pesos y emisiones del metagraph, que rastrean flujos de recompensas en lugar del estado de stake y posición. Para profundizar en los flujos de recompensas, consulta Lectura del estado del metagraph de Bittensor, pesos y emisiones.

• Stake raíz: TAO delegado a la red raíz (netuid 0).
• Alpha stake: tokens específicos de la subred mantenidos por subred, no intercambiables con TAO.
• Hotkey: la identidad del validador a la que se delega el stake; una coldkey puede delegar a múltiples hotkeys.
• Reservas del pool: cada subred tiene una reserva de TAO y una reserva de alpha que determinan la tasa de conversión de alpha a TAO.

Estructura del almacenamiento de Subtensor: dónde vive el estado de staking

El estado de staking vive en el almacenamiento de Substrate, normalmente en mapas con clave coldkey/hotkey y por subred. Los nombres exactos del pallet y del elemento de almacenamiento los define la metadata del runtime en el bloque que estás inspeccionando. Lees este estado con state_getStorage en un hash de bloque específico, usando claves de almacenamiento derivadas de la metadata actual.

Alternativamente, puedes usar la API de polkadot.js o la interfaz Python de Subtensor, que manejan la derivación de claves y la decodificación SCALE por ti. Estas bibliotecas se recomiendan para la mayoría de los casos de uso porque abstraen la construcción de claves de almacenamiento de bajo nivel y la decodificación.

El estado del pool (reserva de TAO y reserva de alpha) también vive en el almacenamiento. La conversión de alpha a TAO debe calcularse a partir de ambas reservas en lugar de asumirse. La fórmula de conversión está documentada en la documentación de staking y pools de Bittensor, pero los parámetros actuales y la mecánica del pool deben confirmarse on-chain porque la economía de tokens de las subredes ha cambiado con las actualizaciones del runtime. La documentación oficial de Bittensor cubre la mecánica de staking y pools, y la referencia del runtime de nodo y staking de Subtensor es la fuente autorizada para la implementación del runtime.

• Usa state_getRuntimeVersion o la metadata en el bloque bajo inspección para saber qué diseño de almacenamiento y nombres de pallet aplican.
• Una actualización del runtime puede renombrar o reestructurar elementos de almacenamiento, por lo que las claves codificadas de forma fija pueden decodificarse silenciosamente a nada.
• Lee siempre en un hash de bloque específico, no en 'latest', si necesitas resultados reproducibles.

Resolver claves de almacenamiento contra la metadata del runtime

Antes de leer cualquier almacenamiento, obtén la metadata del runtime para el bloque que estás consultando. La metadata describe todos los pallets, elementos de almacenamiento y sus tipos de clave. Puedes recuperarla con state_getMetadata o mediante la API de polkadot.js. Para una guía detallada sobre cómo leer la metadata del runtime, consulta Lectura de metadata del runtime con state_getMetadata.

Una vez que tengas la metadata, deriva la clave de almacenamiento para el mapa de información de stake. La clave suele ser una tupla de la coldkey, la hotkey y el netuid, codificada según el códec SCALE. La interfaz Python de Subtensor proporciona funciones auxiliares para construir estas claves y decodificar los resultados.

Si usas JSON-RPC sin procesar, debes codificar la clave manualmente. Esto es propenso a errores y no se recomienda a menos que estés construyendo un cliente personalizado. La especificación oficial de JSON-RPC de Substrate y la documentación del códec SCALE son fuentes primarias autorizadas para esta codificación. La referencia del runtime de nodo y staking de Subtensor documenta los elementos de almacenamiento del runtime y sus tipos de clave.

• Obtén la metadata en el hash del bloque objetivo para garantizar la consistencia.
• Usa la interfaz de Subtensor o polkadot.js para evitar la codificación SCALE manual.
• Verifica que el elemento de almacenamiento exista en la metadata antes de consultar; los elementos faltantes indican un cambio en el runtime.

Ejemplo ejecutable en Python: lectura de stake, reservas del pool y delegación

El siguiente ejemplo en Python usa la interfaz oficial de Subtensor para conectarse a un endpoint de Bittensor, decodificar la metadata, leer el stake de una coldkey en la raíz y en una subred concreta, leer las reservas del pool de la subred, calcular el precio implícito de alpha y leer la relación de delegación para identificar la hotkey.

Este ejemplo asume que tienes instalado el paquete Python bittensor y acceso a un endpoint RPC de Subtensor. Reemplaza la URL del endpoint y los valores de coldkey/hotkey por los tuyos. La forma de la salida es un diccionario con stake raíz, stake de subred, reservas del pool, precio implícito de alpha y la hotkey asociada a la delegación. La documentación oficial de Bittensor y la referencia del runtime de nodo y staking de Subtensor describen las interfaces de staking y pool utilizadas aquí.

import bittensor as bt

# Connect to a Subtensor endpoint
subtensor = bt.subtensor(network='finney')

# Define the coldkey and hotkey to inspect
coldkey_ss58 = '5F...'  # replace with actual coldkey
hotkey_ss58 = '5G...'   # replace with actual hotkey
netuid = 1  # example subnet

# Read stake for the coldkey on root (netuid 0) and the specified subnet
stake_root = subtensor.get_stake(coldkey_ss58, hotkey_ss58, netuid=0)
stake_subnet = subtensor.get_stake(coldkey_ss58, hotkey_ss58, netuid=netuid)

# Read pool reserves for the subnet
pool = subtensor.get_subnet_pool(netuid)
tao_reserve = pool.tao_reserve
alpha_reserve = pool.alpha_reserve

# Compute implied alpha price in TAO
implied_alpha_price = tao_reserve / alpha_reserve if alpha_reserve else 0

# Read delegation relationship (hotkey associated with the coldkey's stake)
delegation = subtensor.get_delegation(coldkey_ss58, netuid)

print({
    'root_stake_tao': stake_root,
    'subnet_stake_alpha': stake_subnet,
    'tao_reserve': tao_reserve,
    'alpha_reserve': alpha_reserve,
    'implied_alpha_price_tao': implied_alpha_price,
    'delegated_hotkey': delegation.hotkey if delegation else None
})

Verificar la conversión de alpha a TAO de forma independiente

El precio implícito de alpha calculado a partir de las reservas del pool debe coincidir con la conversión que usa la interfaz de Subtensor cuando reporta el stake en TAO. Para verificarlo, compara la salida de tu script con una segunda fuente, como un explorador de bloques o un endpoint RPC diferente. Alternativamente, vuelve a derivar la conversión a partir de las reservas usando la fórmula documentada y comprueba que coincida. La documentación oficial de Bittensor documenta la fórmula de conversión del pool.

Si los números divergen, verifica que estás leyendo las reservas y el stake en la misma altura de bloque. Leer el stake en 'latest' y las reservas en un bloque histórico producirá resultados inconsistentes. Fija siempre un hash de bloque para todas las lecturas en una misma verificación.

• Compara tu precio de alpha calculado con el valor devuelto por la conversión de stake a TAO de la interfaz de Subtensor.
• Verifica de forma cruzada con un segundo endpoint RPC o un explorador de bloques que muestre las reservas del pool.
• Asegúrate de que todas las lecturas usen el mismo hash de bloque para evitar inconsistencias temporales.

Fallos comunes al leer el estado de staking de Bittensor

Varias trampas pueden hacer que tu panel o script de auditoría reporte posiciones incorrectas. La más común es tratar alpha como si fuera TAO 1:1. Los tokens alpha son específicos de cada subred y su valor en TAO lo determinan las reservas del pool. Otro error frecuente es leer el stake en 'latest' y luego reportarlo contra un bloque histórico, lo que mezcla estados de momentos diferentes.

Usar claves de almacenamiento copiadas de un runtime anterior puede decodificarse silenciosamente a nada, porque las actualizaciones del runtime pueden renombrar o reestructurar los elementos de almacenamiento. Sumar el stake de una coldkey en todas las subredes en un solo número también es engañoso, ya que cada subred tiene su propio token alpha y tasa de conversión. Confundir el stake propio de un validador con el stake delegado es otro error común: los validadores pueden tener su propio stake, y el stake de los delegadores es independiente.

Por último, martillar un endpoint público con un bucle por coldkey puede provocar límites de tasa o tiempos de espera. Usa lecturas por lotes o lecturas por rango cuando sea posible. Para más información sobre errores de tiempo de espera, consulta Errores de tiempo de espera de RPC de Bittensor en Subtensor.

• No asumas que alpha equivale a TAO; aplica siempre la conversión del pool.
• Fija un hash de bloque para todas las lecturas en un mismo informe.
• Verifica las claves de almacenamiento contra la metadata actual del runtime.
• Reporta el stake por subred y por hotkey, no como una única suma.
• Distingue el auto-stake del validador del stake delegado.
• Usa lecturas por lotes o por rango para evitar límites de tasa.

Tabla de resultados: mide el comportamiento de tu endpoint

Usa la siguiente tabla para registrar el comportamiento observado de tu propio endpoint. Rellena los valores ejecutando el ejemplo en Python o tu propio script contra tu endpoint. Esto te ayudará a entender la latencia, la consistencia y cualquier característica de limitación de tasa.

La tabla está intencionalmente en blanco para que la completes tú. No confíes en benchmarks genéricos; mide tu propia configuración.

• URL del endpoint: [tu endpoint]
• Hash de bloque usado: [hash]
• Stake raíz (TAO): [valor]
• Stake de subred (alpha): [valor]
• Reserva de TAO: [valor]
• Reserva de alpha: [valor]
• Precio implícito de alpha (TAO): [valor]
• Hotkey delegada: [hotkey]
• Tiempo de respuesta (ms): [valor]
• Errores o límites de tasa: [notas]

Lista de verificación para la solución de problemas en lecturas de estado de staking

Si tus lecturas fallan o devuelven valores inesperados, recorre esta lista de verificación. Empieza confirmando que tu endpoint está sincronizado y que estás consultando un bloque que existe. Luego verifica que la metadata del runtime en ese bloque incluya los elementos de almacenamiento que intentas leer.

Comprueba que tus claves de almacenamiento estén codificadas correctamente para el runtime actual. Si usas una biblioteca, asegúrate de que esté actualizada con el último runtime. Si usas RPC sin procesar, revisa la codificación SCALE de la clave. La referencia del runtime de nodo y staking de Subtensor es la fuente autorizada para los elementos de almacenamiento del runtime y su codificación.

Por último, asegúrate de no mezclar alturas de bloque. Todas las lecturas de un mismo informe deben usar el mismo hash de bloque. Si encuentras tiempos de espera, considera usar un endpoint dedicado o reducir la frecuencia de solicitudes. Para opciones de acceso RPC, consulta Acceso y endpoints RPC de Bittensor (RPC Assistant).

• ¿Está el endpoint sincronizado y el hash de bloque es válido?
• ¿La metadata en el bloque incluye los elementos de almacenamiento esperados?
• ¿Están las claves de almacenamiento codificadas correctamente para el runtime actual?
• ¿Están todas las lecturas fijadas al mismo hash de bloque?
• ¿Estás alcanzando límites de tasa o tiempos de espera?
• ¿Es tu versión de la biblioteca compatible con el runtime?

Limitaciones y supuestos: economía de subredes en evolución

La economía de tokens de las subredes ha cambiado con las actualizaciones del runtime y puede seguir evolucionando. Las fórmulas y los diseños de almacenamiento descritos aquí se basan en el comportamiento documentado en el momento de escribir esto, pero debes confirmar los parámetros actuales on-chain. No codifiques de forma fija los parámetros económicos; léelos siempre del runtime. La documentación oficial de Bittensor y la referencia del runtime de nodo y staking de Subtensor son las fuentes primarias para los parámetros actuales y el comportamiento del runtime.

El ejemplo en Python asume que la interfaz de Subtensor proporciona métodos auxiliares para lecturas de stake y pool. Si esos métodos cambian, es posible que tengas que adaptar el código. El ejemplo también asume una sola subred; para múltiples subredes, itera sobre los netuids y aplica la misma lógica.

Esta guía no cubre transacciones de staking (add_stake, remove_stake) ni la gestión de delegación. Se centra únicamente en la ruta de lectura. Para acceso a nodos y detalles de red, consulta RPC de Bittensor y acceso a nodos en Finney y Red Finney de Bittensor.

• Los parámetros económicos son valores documentados; confírmalos on-chain.
• Las actualizaciones del runtime pueden cambiar los diseños de almacenamiento y los nombres de los pallets.
• La ruta de lectura es independiente de la construcción de transacciones.
• Verifica siempre contra una segunda fuente cuando sea posible.

Próximos pasos: construir paneles y auditorías de staking fiables

Para construir un panel de staking o un script de auditoría fiable, empieza usando la interfaz de Subtensor o polkadot.js para abstraer la derivación de claves de almacenamiento. Fija un hash de bloque para cada informe, lee el stake por subred y por hotkey, y calcula las conversiones de alpha a TAO a partir de las reservas del pool. Verifica de forma cruzada tus resultados con un segundo endpoint o explorador.

Para uso en producción, considera un endpoint RPC dedicado para evitar límites de tasa y garantizar un rendimiento consistente. Explora Precios de RPC y Servicio de API para ver opciones. Para más guías, visita el centro de aprendizaje de OnFinality.

Recuerda que el estado de staking de Bittensor es un vector, no un escalar. Reportarlo correctamente requiere entender la mecánica del pool y las relaciones de delegación. Con los métodos de esta guía, puedes evitar errores comunes y producir resultados precisos y verificables.

• Usa bibliotecas para la derivación y decodificación de claves.
• Fija hashes de bloque para la reproducibilidad.
• Calcula las conversiones a partir de las reservas, no de suposiciones.
• Verifica de forma cruzada con fuentes independientes.
• Considera endpoints RPC dedicados para producción.