Bittensor EVM JSON-RPC: Uso de la capa EVM de la red TAO

La división arquitectónica entre el RPC subtensor y la capa EVM

Bittensor está construido sobre Substrate, y su interfaz JSON-RPC nativa es el RPC subtensor. Esa superficie utiliza espacios de nombres de métodos al estilo Substrate para staking, registro de subredes, datos de metagraph y otras operaciones nativas de la cadena. Si vienes de las herramientas de Polkadot o Kusama, el RPC subtensor te resultará familiar: es la forma canónica de leer y escribir el estado específico de Bittensor.

Junto a eso, Bittensor expone una superficie JSON-RPC compatible con EVM. Esta capa refleja el vocabulario de métodos definido en la especificación JSON-RPC de Ethereum, por lo que llamadas como eth_chainId, eth_blockNumber y eth_getBalance se comportan como las herramientas de Ethereum esperan. La capa EVM no es un reemplazo del RPC subtensor; es una interfaz paralela que permite que las herramientas nativas de Ethereum se comuniquen con la porción EVM de la red.

La consecuencia práctica es que un único nodo o endpoint de proveedor de Bittensor puede servir una o ambas superficies. Algunos endpoints públicos exponen solo el RPC subtensor, otros exponen solo el JSON-RPC EVM, y algunos exponen ambos. Antes de escribir código de integración, confirma qué superficie sirve tu endpoint. La guía del nodo RPC de Bittensor cubre el lado subtensor en profundidad, mientras que este artículo se centra en la capa EVM.

• RPC subtensor: métodos al estilo Substrate para staking, subredes y datos de metagraph.
• JSON-RPC EVM: métodos al estilo Ethereum para chain ID, bloques, saldos y contratos EVM.
• El alcance del endpoint varía: algunos proveedores sirven una superficie, otros sirven ambas.

Por qué una capa EVM importa para las herramientas de Bittensor

La capa EVM reduce el costo de integración para equipos que ya usan herramientas de Ethereum. En lugar de aprender nombres de métodos y codificación de tipos específicos de Substrate, un desarrollador puede apuntar ethers.js, viem o web3.js a un endpoint JSON-RPC EVM de Bittensor y usar los mismos patrones que usa en Ethereum. Los flujos de 'agregar red' en billeteras también se simplifican: la billetera necesita una URL de RPC, un chain ID y un símbolo de moneda, todo lo cual la capa EVM puede proporcionar.

Esto importa para el despliegue de contratos y las lecturas de saldo de estilo EVM en TAO. Si la lógica de tu aplicación está escrita contra la EVM, puedes reutilizarla en Bittensor sin reescribir la capa de transporte. La documentación de ethers.js describe el patrón de conexión estándar para cualquier endpoint JSON-RPC compatible con EVM, y ese patrón se aplica aquí.

Sin embargo, la capa EVM es solo una parte de la red. Los conceptos nativos de Substrate, como las subredes, los tokens alfa y el staking, viven fuera del espacio de nombres EVM. Si tu aplicación necesita datos de metagraph u operaciones de staking, necesitarás el RPC subtensor. El artículo sobre la ruta de lectura de staking del subtensor de Bittensor cubre esa ruta de lectura en detalle.

• Reutiliza herramientas de Ethereum sin aprender detalles específicos de Substrate.
• Habilita contratos de estilo EVM y lecturas de saldo en TAO.
• Mantén la lógica de subredes y staking en el RPC subtensor.

Qué se comparte con Ethereum y qué difiere

La capa EVM comparte el vocabulario de métodos y el sobre JSON-RPC 2.0 con Ethereum. Las solicitudes usan la misma estructura {jsonrpc, method, params, id}, y las respuestas siguen la misma forma de result/error. Esto está definido por la especificación JSON-RPC 2.0 y se refleja en los métodos JSON-RPC de Ethereum. Si has escrito un cliente de Ethereum, el formato de solicitud será idéntico.

Lo que difiere es la identidad de la cadena y la red circundante. El chain ID no es el chain ID de Ethereum; es específico de Bittensor y debe confirmarse con la documentación actual de Bittensor. La denominación del token nativo es RAO/TAO en lugar de ETH, por lo que los valores de saldo devueltos por eth_getBalance están denominados en la unidad más pequeña de TAO. La configuración de la billetera debe reflejar el símbolo y los decimales correctos.

Otra diferencia es el alcance. La superficie EVM cubre solo la porción compatible con EVM de la red. El estado nativo de Substrate, incluidas las subredes y las posiciones de staking, no es accesible a través de métodos EVM. Si llamas a un método EVM esperando datos de subred, no los encontrarás. La documentación de Bittensor es la fuente autorizada sobre qué superficies se exponen y cómo se relacionan.

• Compartido: sobre JSON-RPC 2.0 y vocabulario de métodos de Ethereum.
• Diferente: chain ID, denominación del token nativo (RAO/TAO) y alcance de la red.
• No expuesto vía EVM: subredes, tokens alfa y estado de staking.

Cómo ve una billetera a Bittensor a través de la lente EVM

Cuando agregas Bittensor a una billetera compatible con EVM como MetaMask, la billetera necesita tres piezas de información: una URL de RPC, un chain ID y un símbolo de moneda. La URL de RPC debe apuntar a un endpoint que sirva la superficie JSON-RPC EVM. El chain ID debe coincidir con el chain ID EVM de Bittensor, que debes confirmar con la documentación actual de Bittensor en lugar de asumir un valor. El símbolo de moneda suele ser TAO, con la unidad más pequeña siendo RAO.

La billetera usará entonces métodos EVM estándar para mostrar saldos y enviar transacciones. No sabe nada de subredes ni staking; esos permanecen fuera de la vista EVM de la billetera. Si también necesitas interactuar con el RPC subtensor, usarás una herramienta o endpoint separado. La guía de RPC de Bittensor (RPC Assistant) puede ayudarte a identificar el endpoint correcto para cada superficie.

Un error común es usar un endpoint solo subtensor como URL de RPC de la billetera. La billetera fallará al conectarse porque el endpoint no sirve métodos eth_*. Verifica siempre que tu endpoint elegido responda a eth_chainId antes de agregarlo a una billetera.

• La billetera necesita: URL de RPC, chain ID, símbolo de moneda.
• Confirma el chain ID con la documentación actual de Bittensor; no lo asumas.
• Los endpoints solo subtensor no funcionarán como URL de RPC de billetera.

Ejemplo ejecutable en Node.js: conexión con ethers.js

El siguiente script de Node.js usa ethers.js para conectarse a un endpoint JSON-RPC EVM de Bittensor. Llama a eth_chainId y eth_blockNumber, luego lee el saldo de una dirección dada. Reemplaza las constantes RPC_URL y ADDRESS con tus propios valores. El script imprime el chain ID, el número de bloque actual y el saldo, confirmando que el endpoint está sirviendo la superficie EVM.

Este ejemplo sigue el patrón de conexión estándar de ethers.js documentado en docs.ethers.org. Si el endpoint no sirve métodos EVM, la llamada al proveedor lanzará un error, lo cual es en sí mismo un diagnóstico útil.

// bittensor-evm-check.js
// Run with: node bittensor-evm-check.js

const { ethers } = require("ethers");

// Replace with your Bittensor EVM JSON-RPC endpoint
const RPC_URL = "https://your-bittensor-evm-endpoint";

// Replace with an address you want to inspect
const ADDRESS = "0x0000000000000000000000000000000000000000";

async function main() {
  const provider = new ethers.JsonRpcProvider(RPC_URL);

  const chainId = await provider.send("eth_chainId", []);
  console.log("eth_chainId:", chainId);

  const blockNumber = await provider.getBlockNumber();
  console.log("eth_blockNumber:", blockNumber);

  const balance = await provider.getBalance(ADDRESS);
  console.log("eth_getBalance:", balance.toString());
}

main().catch((err) => {
  console.error("EVM JSON-RPC check failed:", err.message);
  process.exit(1);
});

Ejemplo ejecutable con curl: solicitudes JSON-RPC sin procesar

Si prefieres inspeccionar las respuestas JSON-RPC sin procesar sin una biblioteca, curl funciona bien. Los siguientes comandos envían eth_chainId y eth_blockNumber a tu endpoint. Reemplaza la URL con tu endpoint JSON-RPC EVM de Bittensor. La respuesta debe ser un objeto JSON con un campo result.

Estas llamadas sin procesar son útiles para solucionar problemas porque muestran la solicitud y la respuesta exactas, incluidos los objetos de error. Si recibes un error de método no encontrado, es probable que el endpoint no sirva la superficie EVM.

# Replace with your Bittensor EVM JSON-RPC endpoint
RPC_URL="https://your-bittensor-evm-endpoint"

# eth_chainId
curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

# eth_blockNumber
curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":2}'

Tabla de resultados reproducible para tu propio endpoint

Debido a que la disponibilidad de métodos EVM y los parámetros de la cadena varían según el proveedor de RPC, debes medir contra tu propio endpoint en lugar de confiar en valores genéricos. Usa la tabla a continuación para registrar lo que observes. La columna 'Esperado' describe la forma general de una respuesta exitosa, no un valor específico. Completa la columna 'Observado' con la salida real de tu endpoint.

Ejecuta cada método al menos dos veces para confirmar la consistencia. Si un método devuelve un error, registra el mensaje de error en la columna Notas. Esta tabla se convierte en un registro reproducible de la superficie EVM de tu endpoint.

• Método: eth_chainId | Esperado: chain ID en cadena hexadecimal | Observado: [completar] | Endpoint: [completar] | Notas: [completar]
• Método: eth_blockNumber | Esperado: número de bloque en cadena hexadecimal | Observado: [completar] | Endpoint: [completar] | Notas: [completar]
• Método: eth_getBalance | Esperado: saldo en cadena hexadecimal en RAO | Observado: [completar] | Endpoint: [completar] | Notas: [completar]
• Método: eth_getBlockByNumber | Esperado: objeto de bloque o null | Observado: [completar] | Endpoint: [completar] | Notas: [completar]
• Método: net_version | Esperado: cadena de ID de red | Observado: [completar] | Endpoint: [completar] | Notas: [completar]

Limitaciones y compensaciones de la capa EVM de Bittensor

La capa EVM no es un equivalente completo de Ethereum. La disponibilidad de métodos difiere de Ethereum, y los precompilados pueden no estar presentes o comportarse de manera diferente. Algunos métodos que funcionan en Ethereum pueden devolver errores o respuestas no compatibles en Bittensor. Este es un comportamiento documentado que varía según el proveedor, por lo que debes probar los métodos específicos que necesita tu aplicación.

La capa EVM no expone datos de subredes ni de staking. Si tu aplicación necesita información de metagraph, saldos de tokens alfa u operaciones de staking, debes usar el RPC subtensor. El artículo sobre la ruta de lectura de staking del subtensor de Bittensor explica cómo leer esos datos.

El chain ID y los parámetros del endpoint deben confirmarse con la documentación actual de Bittensor en lugar de asumirse. Algunos endpoints públicos sirven solo una de las dos superficies, por lo que es posible que necesites endpoints separados para operaciones EVM y subtensor. Al comparar opciones de protocolo, el artículo JSON-RPC vs gRPC vs REST proporciona contexto sobre las compensaciones de transporte.

• La disponibilidad de métodos y los precompilados difieren de Ethereum y varían según el proveedor.
• No hay datos de subredes ni de staking a través de métodos EVM.
• El chain ID y los parámetros del endpoint deben confirmarse con la documentación actual.
• Algunos endpoints sirven solo una superficie.

Solución de problemas comunes de conexión JSON-RPC EVM

Si tu script de ethers.js falla con un error de conexión, primero verifica que la URL de RPC sea correcta y accesible. Un endpoint solo subtensor no responderá a eth_chainId. Prueba el ejemplo de curl anterior para ver la respuesta sin procesar. Si recibes un error de método no encontrado, el endpoint no sirve la superficie EVM.

Si el chain ID devuelto no coincide con lo que esperabas, no asumas que está mal. Confirma el chain ID EVM actual de Bittensor en la documentación de Bittensor. Los chain IDs pueden cambiar o diferir entre testnet y mainnet. De manera similar, si los valores de saldo parecen inusuales, recuerda que están denominados en RAO, la unidad más pequeña de TAO, no en TAO mismo.

Si un método específico falla mientras otros tienen éxito, es posible que tu proveedor no admita ese método. Regístralo en tu tabla de resultados y verifica si se necesita un método o proveedor alternativo. Para una referencia más amplia sobre el vocabulario de métodos EVM, consulta la referencia de métodos JSON-RPC de Monad, que cubre el mismo conjunto de métodos al estilo Ethereum.

• Verifica que la URL de RPC sea accesible y sirva métodos EVM.
• El error de método no encontrado indica un endpoint solo subtensor.
• Confirma el chain ID con la documentación actual de Bittensor.
• El saldo está en RAO, no en TAO.

Próximos pasos para construir sobre Bittensor EVM

Una vez que hayas verificado que tu endpoint sirve la superficie EVM, puedes integrarlo en tu aplicación. Usa ethers.js, viem o web3.js como lo harías en Ethereum. Para el despliegue de contratos, asegúrate de que tu cadena de herramientas esté configurada con el chain ID y la URL de RPC correctos. Prueba en una testnet antes de la mainnet si está disponible.

Para cargas de trabajo en producción, considera un proveedor de RPC gestionado que ofrezca ambas superficies. La página de la red Bittensor de OnFinality describe los endpoints y servicios disponibles. También puedes revisar los precios de RPC y el servicio de API para opciones de escala y soporte.

Para profundizar tu comprensión del lado subtensor, lee la guía del nodo RPC de Bittensor y la ruta de lectura de staking del subtensor de Bittensor. Para una visión más amplia de los recursos de OnFinality Learn, visita el centro de aprendizaje de OnFinality.

• Integra el endpoint EVM verificado en tu aplicación.
• Usa proveedores gestionados para escala de producción.
• Lee las guías del subtensor para operaciones no EVM.