Bittensor RPC 端点：连接到 OpenTensor 基金会网络

Bittensor 是一个去中心化的机器学习网络，由 OpenTensor 基金会协调，运行在 Finney 主网上。矿工在子网上注册模型，验证者对这些模型进行评分，TAO 根据网络的激励机制在它们之间流动。如果您正在构建仪表板、子网浏览器、验证者工具或矿工监控脚本，您需要读写该链——这意味着您需要一个 RPC 端点。

本页面侧重于实践方面：如何通过 JSON-RPC 连接到 Bittensor，在选择端点之前需要检查什么，以及随着子网和流量的增长如何保持集成的稳定性。本文面向已经了解基于 Substrate 的链的基础知识，并希望获得可用的连接以及明确决定公共、共享和专用基础设施之间选择的开发者。

哪种 Bittensor 端点适合您的工作负载？

在复制端点之前，请将其与您的应用程序实际执行的操作相匹配。Bittensor 的流量很不寻常，因为其中大量是对子网状态、元图数据和质押余额的读取密集型轮询，而且频率通常很高。

如果您的工作负载是探索性的——每天运行几次的脚本——公共端点通常足以开始。如果您运行的是面向许多用户的仪表板、每隔几秒轮询一次的监控循环，或者需要历史状态的索引器，那么共享或专用端点将使您免于本文后面描述的故障模式。

OnFinality 通过 HTTP 和 WebSocket 提供 Bittensor (Finney) RPC，以及一系列其他支持的 RPC 网络。您可以在 RPC 定价页面比较计划，或者如果您需要可预测的容量，可以迁移到具有隔离资源的专用节点。

链设置一览

Bittensor 是一个基于 Substrate 的链，因此它使用标准的 Substrate JSON-RPC 接口，而不是以太坊 JSON-RPC 方法集。在配置钱包、SDK 和监控工具时，请将这些设置放在手边。

由于原生货币使用 9 位小数，在 planck 风格整数和人类可读值之间转换时，请记住将 TAO 金额乘以 1e9。Bittensor 工具中一个常见的错误是在显示原始余额时没有进行缩放，这使得质押和排放数字看起来差了九个数量级。

进行您的第一次 JSON-RPC 调用

Substrate 链暴露了一小部分大多数工具依赖的核心方法。从健康检查和链身份读取开始，以确认您的端点处于活动状态并指向正确的网络。

# 确认节点健康且已同步
curl -s https://bittensor-finney.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_health","params":[]}'

# 读取链名称以验证您在 Finney 主网上
curl -s https://bittensor-finney.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_chain","params":[]}'

健康的响应返回 isSyncing: false 和一个对等节点计数。如果 isSyncing 为 true，则节点仍在追赶，读取可能已过时——不要将其状态视为最终状态。

对于应用程序代码，Polkadot.js API 是与 Bittensor 通信的最常见方式。它为您处理元数据、类型注册表和 SCALE 编码，这很重要，因为原始的 state_getStorage 调用需要您了解存储键和类型。

import { ApiPromise, WsProvider } from '@polkadot/api';

const provider = new WsProvider('wss://bittensor-finney.api.onfinality.io/public-ws');
const api = await ApiPromise.create({ provider });

const [chain, health] = await Promise.all([
  api.rpc.system.chain(),
  api.rpc.system.health(),
]);

console.log('Chain:', chain.toString());
console.log('Syncing:', health.isSyncing.toString());

// 读取当前区块号
const header = await api.rpc.chain.getHeader();
console.log('Latest block:', header.number.toNumber());

连接后，您可以通过运行时模块查询子网和质押状态。确切的存储键和调用名称取决于当前运行时，因此请始终从实时元数据中读取它们，而不是硬编码旧教程中的值。

读取子网和元图数据

大多数 Bittensor 应用程序关心子网级别的数据：哪些神经元已注册，它们的激励和排放值是什么，以及质押如何分布。这些数据存在于运行时存储中，最好通过 API 的类型化查询而不是原始存储键来访问。

// 遍历子网上注册的神经元（结构取决于运行时版本）
const entries = await api.query.subtensorModule.neurons.entries(1);

for (const [key, value] of entries) {
  const uid = key.args[1].toString();
  console.log('UID:', uid, 'Incentive:', value.incentive.toString());
}

两个实用说明。首先，元图读取可能很大——遍历繁忙子网上的每个神经元会返回大量数据，因此在运行时允许的情况下进行分页或过滤。其次，子网标识符和模块名称在运行时升级中发生了变化。固定您的客户端库版本，并在每次网络升级后进行测试，因为重命名的存储项会静默地破坏以前可以工作的查询。

用于实时数据的 WebSocket 订阅

如果您正在构建任何对新块或事件做出反应的东西——警报机器人、实时仪表板、监视注册变化的矿工——通过 HTTP 轮询将无法很好地扩展。请改用 WebSocket 订阅。

const provider = new WsProvider('wss://bittensor-finney.api.onfinality.io/public-ws');
const api = await ApiPromise.create({ provider });

// 对每个新区块做出反应
const unsub = await api.rpc.chain.subscribeNewHeads((header) => {
  console.log('New block:', header.number.toNumber());
});

// 对包含的特定事件做出反应
const unsubEvents = await api.query.system.events((events) => {
  events.forEach(({ event }) => {
    if (api.events.subtensorModule?.RegistrationAllowed?.is(event)) {
      console.log('Registration event detected');
    }
  });
});

WebSocket 连接会断开。网络波动、笔记本电脑休眠以及负载均衡器回收连接。始终实现带有退避的重连逻辑，并在重连后重新订阅。一个静默停止传递区块的订阅比错误更糟糕，因为您的应用程序会继续在过时的数据上运行。

常见故障模式及如何调试

大多数 Bittensor RPC 问题都属于几种模式。以下是如何识别和修复它们。

一个快速的诊断习惯：当出现问题时，在两个不同的端点上查询 system_health 和 chain_getHeader 并进行比较。如果区块高度不同，则存在同步或滞后问题，而不是代码中的错误。

评估 Bittensor RPC 提供商

一旦您超越了快速原型，端点就成为生产环境的一部分。这些是真正对 Bittensor 工作负载重要的标准。

OnFinality 将 Bittensor (Finney) RPC 作为更广泛网络组合的一部分运行，因此您可以将 Substrate 和 EVM 集成保持在一致的工具上。如果您想将此与其他链和提供商进行比较，如何选择 RPC 提供商文章介绍了通用评估框架。

Bittensor 基础设施：构建还是购买

运行自己的 Bittensor 节点可以给您完全控制权，但会带来真实的运营成本：链历史的磁盘空间、持续的同步和升级维护、监控以及调试 Substrate 问题的专业知识。对于产品是子网、矿工或分析工具的团队来说，这通常是远离实际交付内容的时间。

托管 RPC 端点消除了大部分开销。您获得与 Finney 主网的维护连接、HTTP 和 WebSocket 访问，以及出现问题时支持路径。权衡是您依赖提供商来保证可用性和速率限制，这就是上述评估标准重要的原因。

中间路径是专用节点：为您的工作负载提供隔离资源，而无需自己运行硬件的负担。当您的流量可预测且很高，或者共享速率限制开始干扰您的轮询循环时，这通常是正确的步骤。

关键要点

• Bittensor 运行在 Finney 主网上，使用 HTTP 和 WebSocket 上的 Substrate JSON-RPC，而不是以太坊方法集。
• 将您的端点选择与工作负载匹配：探索性脚本可以使用公共端点，而仪表板、监控器和索引器需要共享或专用容量。
• 在信任端点之前，始终验证 system_health 和 system_chain，并在出现陈旧情况时比较端点之间的区块高度。
• 将 TAO 值乘以 1e9，并从实时元数据读取存储键，因为运行时升级会重命名模块和存储项。
• 使用 WebSocket 订阅获取实时数据，并始终实现带有退避的重连逻辑。
• 根据传输支持、归档访问、吞吐量、速率限制透明度、升级处理和故障转移来评估提供商。

常见问题

Bittensor 是 EVM 链吗？

不是。Bittensor 是一个基于 Substrate 的链，因此它使用 Substrate JSON-RPC 方法，如 system_health、chain_getHeader 和 state_getStorage。像 eth_getBalance 这样的以太坊工具在这里不适用；请改用 Polkadot.js API 或其他 Substrate 客户端。

Bittensor 和 Finney 有什么区别？

Bittensor 是网络和项目，而 Finney 是主网的名称。当您连接到 Bittensor RPC 端点时，您连接的是 Finney 主网并读取其链状态。

我可以在生产环境中使用公共 RPC 端点吗？

公共端点适用于原型设计和低频脚本。对于生产仪表板、监控循环或索引器，共享或专用端点提供更可预测的吞吐量，并且更少受到速率限制的意外影响。

为什么我的 TAO 余额看起来不对？

TAO 使用 9 位小数。如果您显示原始整数值而没有乘以 1e9，余额和排放将显得过大。在向用户显示值之前，请始终进行转换。

如何获取实时 Bittensor 数据？

使用 WebSocket 端点并订阅新块头或系统事件。实现带有退避的重连逻辑，并在每次重连后重新订阅，以免您的应用程序在过时数据上运行。

在哪里可以找到 OnFinality 的 Bittensor 端点详细信息？

请参阅 Bittensor 网络页面了解端点和传输详细信息，并访问 RPC 定价页面比较计划。完整链列表可在支持的 RPC 网络页面上找到。