Bitcoin RPC 端点与 API 访问：如何连接到 Bitcoin 网络？

Bitcoin 的 RPC 层与大多数 EVM 开发者所期望的 JSON-RPC 接口工作方式不同。如果你正在构建钱包、区块浏览器、支付处理器或交易工具，你需要先了解哪种访问模式适合你的工作负载，然后再选择端点。本页将介绍实际可用的选项：Bitcoin Core JSON-RPC、索引 API、公共端点，以及像 OnFinality 这样的托管节点服务。

哪种 Bitcoin 访问模式适合你的工作负载？

首先确定你的应用实际需要做什么。Bitcoin Core 暴露了 JSON-RPC 接口，但它主要面向节点运营者和钱包软件设计，而不是面向高层级的地址查询。许多团队在尝试查询地址余额时才发现这一点，因为 getbalance 只返回节点自身钱包的余额。

使用下表将你的工作负载映射到正确的访问模式。

如果你的工作负载是读密集型且以地址为中心，带索引的托管 RPC API 通常是最快的路径。如果你需要对节点配置、钱包状态或 ZMQ 通知进行完全控制，专用 Bitcoin 节点更合适。OnFinality 为包括 Bitcoin 在内的受支持网络提供 RPC API 访问 和 专用节点。

Bitcoin Core JSON-RPC：它是什么，不是什么

Bitcoin Core 包含一个 JSON-RPC 服务器，mainnet 默认监听端口 8332。它支持广泛的方法，用于区块链数据、原始交易、mempool 检查和钱包操作。然而，它并不是通用索引器。像 getblock、getrawtransaction 和 gettxout 这样的方法可以按预期工作，但没有原生的 getAddressBalance 或 getAddressHistory 方法。

要查询地址级数据，你要么在 Bitcoin Core 旁边运行索引器（例如 Electrum server、Esplora 或自定义索引），要么使用已经构建了该索引层的提供商。这是来自 Ethereum 风格 RPC 的开发者最常见的困惑来源。

对 Bitcoin 节点的基本 JSON-RPC 请求如下所示：

curl --user "rpcuser:rpcpassword" \
  --data-binary '{"jsonrpc":"1.0","id":"onf","method":"getblockchaininfo","params":[]}' \
  -H 'content-type: text/plain;' \
  http://127.0.0.1:8332/

响应包括链高度、验证进度和软分叉状态。对于托管端点，将本地 URL 替换为你的基础设施提供商提供的端点，并使用他们指定的身份验证方法。

链设置和节点配置一览

Bitcoin 的网络参数是稳定的，但在连接任何工具之前，你应该确认它们。下表总结了 mainnet 的默认值。

对于 testnet，RPC 端口是 18332，地址使用不同的前缀。如果你正在测试集成，请先使用 testnet 或 signet，然后再迁移到 mainnet。OnFinality 的 Bitcoin 网络页面 列出了支持的访问选项以及任何 testnet 可用性。

公共端点 vs 托管 RPC vs 专用节点

一旦你了解了工作负载，下一个决定就是你想运营多少基础设施。公共 Bitcoin 端点对于快速实验很有用，但它们通常会对请求进行速率限制、缺少地址索引，并且不提供可用性保证。托管 RPC 提供商增加了身份验证、监控和支持，而专用节点则为你提供具有自定义配置的私有实例。

OnFinality 的托管 RPC API 专为希望获得稳定端点而无需运行全节点的团队设计。如果你需要钱包 RPC、自定义 bitcoin.conf 设置或 ZMQ 区块通知，专用节点 是合适的选择。你可以查看 RPC 定价，根据预期请求量比较选项。

连接并验证到 Bitcoin RPC 端点

Bitcoin Core 默认使用 HTTP 基本身份验证。当你连接到托管端点时，提供商会提供凭据或 API 密钥。下面的示例展示了使用环境变量的通用连接模式，你可以将其适配为提供商提供的凭据。

const axios = require('axios');

const rpcUrl = process.env.BITCOIN_RPC_URL; // e.g., https://your-endpoint.example.com
const rpcUser = process.env.BITCOIN_RPC_USER;
const rpcPass = process.env.BITCOIN_RPC_PASS;

async function callBitcoinRpc(method, params = []) {
  const response = await axios.post(
    rpcUrl,
    { jsonrpc: '1.0', id: 'onf', method, params },
    {
      auth: { username: rpcUser, password: rpcPass },
      headers: { 'content-type': 'text/plain;' },
    }
  );
  return response.data.result;
}

callBitcoinRpc('getblockcount').then(console.log);

对于基于 API 密钥的提供商，将 auth 对象替换为所需的标头，例如 Authorization: Bearer <token>。始终将凭据排除在客户端代码之外，并在凭据泄露时轮换它们。

常见故障模式以及如何调试它们

Bitcoin RPC 错误通常是明确的，但原因可能并不明显。下表将常见症状映射到可能的修复方法。

如果你使用的是托管提供商，请先确认你所需的方法受支持。一些提供商只暴露 Bitcoin Core 方法的一个子集。OnFinality 的文档和支持渠道可以确认你的计划的方法可用性。

何时使用托管 Bitcoin RPC 提供商

当你的团队希望专注于应用逻辑而不是节点运营时，托管提供商是合理的选择。运行 Bitcoin 全节点需要磁盘空间、带宽、初始同步时间和持续监控。对于没有专职基础设施人员的团队，托管端点可以降低运营风险。

OnFinality 为一系列网络提供 RPC API 访问和专用节点基础设施。对于 Bitcoin，你可以使用托管 API 进行标准 JSON-RPC 调用，或者如果你需要自定义配置，可以请求专用节点。查看 支持的 RPC 网络 了解可用性，查看 RPC 定价 了解计划详情。如果你仍在评估提供商，关于 如何选择 RPC 提供商 的指南涵盖了方法支持、故障转移和监控等标准。

关键要点

• Bitcoin 通过 Bitcoin Core 使用 JSON-RPC，而不是 EVM 风格 RPC；地址级查询需要索引器或具有索引的提供商。
• 在连接之前，确认链设置，例如 mainnet 的 RPC 端口 8332 和地址前缀。
• 公共端点适合原型；托管 RPC API 和专用节点更适合生产工作负载。
• 身份验证通常是 HTTP 基本身份验证或 API 密钥；将凭据保留在服务器端。
• 像 -32601 和 -28 这样的常见错误通常指向方法可用性或同步状态。
• OnFinality 为 Bitcoin 提供托管 RPC API 和专用节点选项；查看 Bitcoin 网络页面 了解详情。

常见问题

Bitcoin 使用 JSON-RPC 吗？

是的。Bitcoin Core 为节点操作、钱包功能和区块链查询暴露 JSON-RPC 接口。它与 Ethereum 的 JSON-RPC 不同，并且默认不包含地址索引。

我可以使用 Bitcoin RPC 查询地址余额吗？

不能直接使用标准 Bitcoin Core 节点查询。你需要索引器或提供地址级 API 的提供商。一些托管服务包含此索引层。

Bitcoin RPC 使用什么端口？

Mainnet 默认使用端口 8332。Testnet 使用 18332。托管提供商可能使用端口 443 上的 HTTPS。

如何广播 Bitcoin 交易？

使用 sendrawtransaction 方法，并提供已签名的原始交易十六进制。节点将验证并将其转发到网络。

专用 Bitcoin 节点比共享端点更好吗？

这取决于你的工作负载。专用节点让你完全控制配置、钱包状态和索引，但需要更多运维工作。共享托管端点对于标准读取和广播操作更简单。

在哪里可以找到 OnFinality 的 Bitcoin RPC 详情？

访问 Bitcoin 网络页面 了解支持的访问选项，或查看 RPC 定价 和 支持的 RPC 网络。