BNB Chain RPC 的费用是多少，如何选择合适的方案？

快速建议：根据请求形态匹配方案

“BNB RPC 价格”通常指三种情况之一：你想要一个免费端点进行测试，你想知道在特定流量水平下托管 RPC 方案的费用，或者你正在比较按请求计费的方案与租用专用 BNB 节点。答案更多取决于你的请求组合，而非标价。

• 原型开发或低流量 dApp： 共享公共端点就足够了。从 OnFinality 公共 BNB Smart Chain 端点开始，遇到速率限制时再升级。
• 稳定、中等流量的生产应用： 按请求量或计算单元计费的托管 RPC 方案通常是最简单的选择。你按使用量付费，无需运行基础设施。
• 高吞吐量、归档或 trace 密集型工作负载： 专用 BNB 节点 提供可预测的容量，并避免当 eth_getLogs 或归档查询主导流量时按调用计费带来的意外。

如果你已经知道每月请求数以及是否需要归档数据，可以直接跳到下面的成本模型。如果不知道，下一节将展示如何估算。

实际驱动 BNB Chain RPC 成本的因素

RPC 定价不是一个单一数字。提供商根据以下因素的组合定价，而组合比标价更重要：

BNB Smart Chain 是一条 EVM 链，因此方法表面看起来很熟悉：eth_call、eth_getLogs、eth_getBalance、eth_sendRawTransaction 等等。提供商之间的成本差异通常体现在他们如何计量重型读取方法，以及归档和 trace 是捆绑还是额外收费。

估算每月 BNB Chain 请求量

在比较价格之前，先得到一个粗略数字。你不需要精确数字来做决定，只需要正确的数量级。

1. 统计你的读取路径。 钱包刷新、余额显示、代币列表和价格源各自触发一个或多个 eth_call 或 eth_getBalance 请求。
2. 乘以活跃会话数。 如果每天有 1,000 个用户，每个用户触发 20 次读取，那么仅读取每天就有 20,000 次请求。
3. 加上后台任务。 索引器、机器人和监控探针通常比面向用户的读取产生更多流量。每几秒轮询一次 eth_getLogs 会迅速累积。
4. 加上重试和故障转移。 如果你的客户端在超时时重试，实际量会高于逻辑量。

使用公共端点进行快速检查：

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

如果你正在对读取密集型路径进行基准测试，请对一批调用计时，而不是单个调用：

time for i in $(seq 1 50); do
  curl -s https://bnb.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]}' > /dev/null
done

公共端点是共享的，因此将这些数字视为下限，而非保证。它们对于确认客户端正常工作以及粗略估算很有用。

共享、托管还是专用：哪种 BNB RPC 方案适合

三种交付模式对应不同的成本结构。选择与你的工作负载匹配的行，然后在 RPC 定价 页面上确认详细信息。

OnFinality 通过托管的 RPC API 服务 和 专用节点 提供 BNB Chain RPC，因此你可以从共享方案开始，在流量证明合理时迁移到专用容量。支持的 RPC 网络 列表显示了可用的链和传输方式。

连接到 BNB Smart Chain 主网和测试网

BNB Smart Chain 主网使用链 ID 56 和原生代币 BNB。测试网使用链 ID 97 和 tBNB。在配置钱包或客户端时请保持这些设置正确，因为混淆主网和测试网设置是导致令人困惑错误的常见原因。

主网的钱包网络配置：

{
  "chainId": "0x38",
  "chainName": "BNB Smart Chain Mainnet",
  "nativeCurrency": { "name": "BNB Chain Native Token", "symbol": "BNB", "decimals": 18 },
  "rpcUrls": ["https://bnb.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://bscscan.com"]
}

对于测试网工作，使用 BNB Chain 测试网 端点和链 ID 97。测试网流量通常免费或更便宜，这使其成为在确定主网方案规模之前验证请求量的好地方。

用于主网读取的最小 viem 客户端：

import { createPublicClient, http } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: http('https://bnb.api.onfinality.io/public'),
});

const block = await client.getBlockNumber();
console.log('BNB Smart Chain head:', block);

如果你需要实时数据，BNB Chain 在托管端点上支持 WebSocket 传输。订阅会保持连接打开，因此在扩展之前请确认你的提供商如何计量它们。

何时专用 BNB 节点是更便宜的选择

当流量波动或较低时，按请求定价是高效的。当流量高且稳定，或者请求组合以昂贵方法为主时，它变得不那么高效。

专用节点通常在以下情况下有意义：

• 你的每月请求量足够高，以至于基于使用量的计费超过固定节点成本。
• 你依赖归档查询或 trace 方法，这些在共享方案上计量很重。
• 在可预测的峰值期间（如代币发行或计划空投领取窗口）需要一致的容量。
• 你希望将延迟敏感的读取与其他租户的流量隔离。

专用节点通常不是原型的正确首次购买。从共享开始，测量，然后在数字证明合理时迁移。如果你正在决定是运行自己的 BNB 节点还是租用一个，构建与购买的权衡 值得一读。

在不影响可靠性的情况下降低 BNB RPC 成本

大多数团队可以在更改方案之前削减开支。以下是最重要的杠杆：

• 批量请求。 JSON-RPC 批处理在一个 HTTP 请求中发送多个调用，减少开销并通常减少计费单元。
• 积极缓存。 余额和代币元数据变化缓慢；在客户端或边缘层缓存它们。
• 调整 eth_getLogs 范围。 宽区块范围费用高昂。缩小范围并分页。
• 使用 WebSocket 进行订阅而不是轮询。 在循环中轮询 eth_blockNumber 是最常见的浪费请求来源之一。
• 分离读写路径。 通过专用路径发送交易，使延迟敏感的写入远离批量读取。
• 添加故障转移，而非重复。 用于故障转移的第二个端点是好的；运行两条完整流量路径会使成本翻倍且无益处。

一个简单的监控探针可以帮助你及早发现失控的请求量：

#!/usr/bin/env bash
# Log head height and response time every minute
START=$(date +%s%3N)
HEAD=$(curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | grep -o '"result":"[^"]*"')
END=$(date +%s%3N)
echo "$(date -u +%FT%TZ) head=$HEAD latency_ms=$((END-START))"

常见的定价和计费陷阱

• 基于平均值估算。 峰值每秒请求数比月平均值更能驱动容量和成本。按峰值规划。
• 忘记后台任务。 索引器和机器人通常比面向用户的读取花费更多。
• 假设归档已包含。 历史状态查询需要归档节点；在构建依赖它们的特性之前确认。
• 忽略重试风暴。 在超时时积极重试的客户端可能在事件期间使计费量成倍增加。
• 混淆主网和测试网。 错误的链 ID 或错误的端点会产生看起来像提供商问题但实际上是配置错误的错误。
• 过度配置故障转移。 一个备用端点通常就足够了；两条活动路径会使成本翻倍。

关键要点

• BNB Chain RPC 价格由请求量、方法权重、归档和 trace 访问、WebSocket 订阅以及是否租用专用容量驱动。
• 共享公共端点适合原型；托管方案适合变化的生产流量；专用节点适合高吞吐量、归档或 trace 密集型工作负载。
• 在比较方案之前，估算你的每月请求量和峰值每秒请求数。
• BNB Smart Chain 主网是链 ID 56；测试网是链 ID 97。保持设置分开。
• 批处理、缓存、缩小 eth_getLogs 范围以及 WebSocket 订阅是在不影响可靠性的情况下降低成本的最快方法。
• OnFinality 通过托管的 RPC API 服务 和 专用节点 提供 BNB Chain RPC；查看 RPC 定价 和 支持的 RPC 网络 了解当前选项。

常见问题

有免费的 BNB Chain RPC 端点吗？

有。OnFinality 为 BNB Smart Chain 主网和测试网发布了一个共享公共端点。它有限速且是共享的，因此适合原型和低流量使用，而非生产流量。

BNB Chain RPC 如何定价？

托管方案通常按请求量或计算单元计费，较重的方法和归档或 trace 访问采用不同的计量方式。专用节点按节点计费，容量固定。查看 RPC 定价 了解当前详情。

何时应从共享端点迁移到专用 BNB 节点？

当你的稳定请求量使得基于使用量的计费比固定节点更昂贵时，或者当你依赖在共享方案上计量很重的归档或 trace 方法时。

BNB Chain RPC 支持 WebSocket 吗？

BNB Smart Chain 在托管端点上支持 HTTP 和 WebSocket 传输。订阅会保持连接打开，因此请确认你的提供商如何计量它们。

BNB Smart Chain 使用什么链 ID？

主网使用链 ID 56 和 BNB 原生代币。测试网使用链 ID 97 和 tBNB。查看 BNB Chain 和 BNB Chain 测试网 了解端点详情。

我可以在不更换提供商的情况下减少 BNB RPC 账单吗？

通常可以。批量请求、缓存变化缓慢的数据、缩小 eth_getLogs 范围以及用 WebSocket 订阅替代轮询，通常可以显著减少计费量。