如何在 UTXO 链上构建:Bitcoin、Litecoin、Dogecoin 与 Bitcoin Cash

最后更新：2026年5月26日2 分钟阅读

Bitcoin 没有账户余额。它从来都没有。Litecoin、Dogecoin、Bitcoin Cash 也没有。这四条链共享一种源自 2009 年的设计，叫做 UTXO 模型，它取代了每个 Ethereum 和 Solana 开发者都习以为常的“每个地址一行”的状态机模型。这个模型在协议层是可行的。但在应用层会出问题：你的应用需要的每一个基本查询要么不存在，要么必须由外部索引器重新组装出来。

这就是为什么在 UTXO 链上开发的团队多年来一直在拼凑基础设施：一个提供商用于 RPC，另一个用于索引读取，第三个用于 webhooks，剩下的空白靠自己写代码补上。我们的 UTXO 套件把这一切整合进一个平台，覆盖全部四条链，使用你在 EVM 和 Solana 上已经在用的同一个仪表盘、API 密钥和计量系统。

UTXO 链有什么不同？

UTXO 意为“未花费的交易输出”（unspent transaction output）。每一笔 Bitcoin 交易都会消耗一个或多个输出作为输入，并创建新的输出。一个钱包的“余额”并不存储在链上任何地方，而是通过汇总该钱包控制的、尚未被花费的所有输出计算得出。Bitcoin 开发者指南明确指出：“当你的 Bitcoin 钱包告诉你有 10,000 聪的余额时，实际上意味着你有 10,000 聪分布在一个或多个 UTXO 中等待被使用。”

举一个具体例子。Alice 控制三个 UTXO：0.4 BTC、0.3 BTC 和 0.2 BTC。她向 Bob 发送 0.5 BTC。这笔交易会完全消耗她的 0.4 BTC 和 0.3 BTC 输出，为 Bob 创建一个 0.5 BTC 的输出，将约 0.1999 BTC 作为找零返还到 Alice 控制的一个新地址，剩余约 0.0001 BTC 作为矿工费。0.2 BTC 的那个 UTXO 不受影响。UTXO 是原子性的，你无法部分花费一个 UTXO。

与基于账户的链相比，差异十分明显：

Feature	Account-based (Ethereum)	UTXO (Bitcoin)
State	One balance per address	A set of unspent outputs, each with a locking script
"Balance" query	Direct read from state trie	Sum of unspent outputs the wallet controls
Atomicity	A single tx mutates two balances	A single tx consumes N inputs and creates M outputs
Privacy default	Same address for life	New address per transaction is the convention
Parallel validation	Hard (every tx touches shared state)	Easy (independent outputs don't conflict)
Replay protection	Nonces per account	Each output can only be referenced once

Litecoin、Dogecoin 和 Bitcoin Cash 都继承了这一模型。它们分叉自 Bitcoin 的代码库，调整了出块时间和一些参数后就上线了。同样的思维模型和同一类基础设施可以服务这四条链。

开发者为什么要关心这个？

这些差异并非停留在理论层面，它们体现在具体的地方——大多数团队都会低估这部分工作量。

你无法向节点查询一个地址的余额

Bitcoin Core 存储区块和交易，但不维护地址到交易的索引。核心开发者明确拒绝添加这样的索引，正如一位维护者所说：“地址索引本质上是不可扩展的，因为它会随着区块链规模线性增长。”他们的立场是：地址索引应该由外部服务来做。因此，每一个需要展示余额、列出用户交易记录或监听收款的 Bitcoin 应用，都要依赖一个索引器：一种监听链上数据并维护地址、交易和 UTXO 可查询数据库的服务。唯一的问题是由谁来运行它。大多数团队选择使用托管的区块链节点提供商，而不是自建这套基础设施。

钱包不是只有一个地址，而是成千上万个

重复使用一个地址会把所有输入和输出关联到同一个身份下。因此惯例是每次收款使用一个新地址，这些地址通过 BIP 32 定义的分层确定性（HD）密钥从单一种子派生而来。一个持有公司级 xpub（扩展公钥，可以从单一根密钥派生出一整棵收款地址树，而不暴露能够花费资金的私钥）的交易所，可以为每位客户展示一个新生成的存款地址。一个自托管钱包可以从一个 12 个单词的种子重新计算出它控制的每一个 UTXO。问题在于：索引器必须按顺序派生地址并全部监听，由 BIP 44 的 20 地址间隔限制决定何时停止。如果跳过了 20 个地址，索引器就会认为已经派生完毕——这正是现实中“我的资金去哪了”类工单的成因之一。

手续费按大小计费，而非按金额计费

计费单位是每虚拟字节的聪数。一个将 100 个小额 UTXO 合并为一个输出的钱包，需要支付与这 100 个输入数量成比例的手续费，与转移的金额无关。费率估算依赖内存池状态，每分钟都在变化。卡住的交易可以通过 replace-by-fee（BIP 125）或 child-pays-for-parent 来加速确认。这些概念本身都不难，但都是需要你自己写出来的真实生产代码。

最终性是概率性的

一个 Bitcoin 区块可能被竞争区块重组出主链。这种情况发生时，被替换区块中的每一笔交易都会回到内存池中，之前“已花费”的输出会重新变为未花费状态。你的索引器必须干净地回滚，否则就会给应用返回错误的余额。应用通过确认数阈值来自我保护：低价值付款用 1 次确认，历史上的标准是 6 次确认，大额交易所存款用 30 次以上确认。Litecoin 和 Dogecoin 的出块时间更短（LTC 为 2.5 分钟，DOGE 为 1 分钟），因此相同数量的确认数提供的实际时间安全性更低。

地址格式一直在变化

Bitcoin 已经推出过三次地址格式升级，且没有淘汰之前的格式：2012 年的 P2SH，2017 年的 SegWit，以及 2021 年的 Taproot。如今网络中同时存在四种地址格式：传统 P2PKH（1...）、嵌套 SegWit P2SH（3...）、原生 SegWit P2WPKH（bc1q...），以及 Taproot P2TR（bc1p...）。一笔 1 输入、2 输出的 P2WPKH 交易大约是 141 个虚拟字节，而等效的 P2PKH 交易约为 226 vB，因此格式选择直接影响手续费。生产环境中的钱包和浏览器都必须支持全部四种格式。

每一个在 Bitcoin 上构建的团队，都会在第一个季度里花大量时间处理这份清单，而其中大部分工作与他们真正要做的产品毫无关系。

Alchemy 如何支持 UTXO 链？

我们在同一个平台上支持 Bitcoin、Litecoin、Dogecoin 和 Bitcoin Cash，与 Ethereum、Solana 以及链目录中的其余部分共用同一套体系。相同的 API 密钥，相同的仪表盘，相同的计量模型，相同的 webhooks。每一项功能在每个套餐层级都可用。

发布时提供的功能：

原始 JSON-RPC 直通，连接到以 -txindex=1 运行的全节点，支持每一个标准 Bitcoin Core 方法（getblock、getrawtransaction、estimatesmartfee、sendrawtransaction 等）。
索引化的 REST API，用于地址余额、UTXO 查询、分页交易历史、增强版交易详情，以及花费状态查询——这些都是 Bitcoin Core 原生无法回答的查询，现在能以毫秒级响应给出答案。
xpub 和 descriptor 追踪，覆盖全部四条链。输出 descriptor 指定如何从一个密钥派生地址；我们负责处理 BIP 44、49、84 和 86 这几种派生树以及标准的 20 地址间隔限制。余额、UTXO 和历史查询会针对完整的派生地址集运行，而不仅仅是你提交的第一个地址。
WebSocket 订阅，用于已确认交易、地址活动、新区块和重组通知，每个数据流都可配置确认数阈值。
除原始广播外的交易操作：分级的手续费估算（快速、中速、慢速，基于内存池状态）、未签名交易构建、编译、验证和广播。
兼容层封装，支持 Blockbook 风格的 bb_*（QuickNode 的形态）以及 Blockdaemon 风格的 bd_* 方法签名，使现有集成只需修改 HTTP 调用即可迁移。

用代码来说明就是这样。任何节点支持的方法都可以用原始 JSON-RPC：

bash

Copied

curl -X POST https://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY \
-H "Content-Type: application/json" \
-d '{
  "jsonrpc": "1.0",
  "id": "1",
  "method": "estimatesmartfee",
  "params": [6]
}'

Bitcoin Core 原生无法回答的查询用 REST：

bash

Copied

# Address balance, tx history, and UTXOs
curl https://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY/addresses/bc1q.../balance

# Watch an entire xpub or descriptor (no gap-limit logic to maintain)

curl https://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY/accounts/zpub.../utxos

持久连接用于实时更新：

javascriptCopied
const ws = new WebSocket("wss://bitcoin-mainnet.g.alchemy.com/v2/YOUR_API_KEY");
ws.send(JSON.stringify({
method: "subscribeAddressActivity",
params: { address: "bc1q...", confirmations: 6 },
}));

完整的参考文档，包括每一个端点以及迁移兼容层的方法列表，都在我们的 Bitcoin API 快速入门和 Bitcoin JSON-RPC 参考文档中。关于 UTXO 状态与账户状态差异更深入的解读，可以参考我们的 UTXO 与账户模型对比文档，其中涵盖了协议层的具体机制。

与市面上的方案相比有什么不同？

如果你今天已经在 Bitcoin 上做开发，你可能在使用以下三种提供商之一，每一种都存在缺口：

Capability	Alchemy	QuickNode	Blockdaemon	Blockcypher
BTC indexed reads (balance, UTXO, tx history)	Yes	Yes	Yes	Yes
LTC + BCH indexed reads	Yes	Yes	Partial	Yes
DOGE indexed reads	Yes	Blockbook add-on (paid)	Partial	Yes
xpub / descriptor tracking	All four chains	BTC, LTC, BCH (DOGE via paid add-on)	Not documented	HD Wallets (BTC, LTC, DOGE)
WebSocket subscriptions	Yes	Yes	Limited	Yes
Transaction operations (construct, compile, verify, broadcast)	BTC, LTC, BCH	Broadcast + decode (raw RPC)	Full lifecycle (Wallet Transact)	Yes
Migration-compat wrappers (`bb_`, `bd_`)	Yes	N/A	N/A	N/A
Unified dashboard with EVM and Solana	Yes	No	No	No

对开发者来说，有三点发生了变化。

一个供应商，一次集成，一份账单

如果你已经在 Alchemy 上使用 Ethereum、Base、Polygon 或 Solana，那么接入 Bitcoin 不需要走采购流程，只是打开一条链而已。同样的 API 密钥，同样的计量方式，同样的 webhooks 交付模型，同样的仪表盘。多年来在 UTXO 链上标配的多供应商配置，被整合成了一次集成。

四条链，一套功能集

现有的每个提供商都覆盖了这些链和功能的某种组合，但覆盖程度并不均衡。QuickNode 在 BTC、LTC 和 BCH 上提供 Blockbook 索引读取和 xpub 追踪；Dogecoin 的 Blockbook 则是单独的付费附加项。Blockcypher 通过 wallets/hd 在 BTC、LTC 和 DOGE 上提供 HD 钱包功能。Blockdaemon 的 Wallet Transact API 覆盖了全部四条链的交易构建。各团队最终不得不根据每个使用场景去匹配支持相应功能和链组合的提供商，再用自定义代码拼接剩下的部分。我们在一个套件中，跨 Bitcoin、Litecoin、Dogecoin 和 Bitcoin Cash 提供了 xpub 追踪、索引化读取、交易操作和 WebSocket 订阅，没有按链附加收费，也没有功能拆分。

迁移只是修改 HTTP 调用，而非重新架构

针对 Blockbook 风格 bb_* 方法（QuickNode 的形态）和 Blockdaemon 风格 bd_* 方法的兼容层封装，意味着你现有集成的请求结构保持不变。你只需要更换主机地址，而不必重写调用代码。对于使用 Blockcypher 旧版 REST 接口的团队来说，请求格式确实会发生变化（我们使用带有不同结构的 REST GET），但底层数据模型是一致的。我们在发布时提供了一份整合的 UTXO 迁移指南，分别涵盖 Blockcypher、QuickNode Blockbook 和 Blockdaemon 的迁移内容。

对开发者来说的好处可以归结为一句话：需要拼接的基础设施更少，需要管理的供应商更少，从“我们需要支持 Bitcoin”到实际上线的路径更快。

用 Alchemy 在 Bitcoin 上构建

Bitcoin、Litecoin、Dogecoin 和 Bitcoin Cash 现已与 Ethereum、Solana 以及其他 100 多条链一起在 Alchemy 上线。PAYG 开发者第一天就可以从仪表盘添加这些链，无需签合同、无需排队等待、无最低承诺。企业客户可以在现有计算单元额度内使用 UTXO 链。阅读 Bitcoin 支持发布公告了解完整的功能详情。

在 Alchemy 仪表盘中创建一个端点，开始查询，或联系销售团队获取企业级集成支持和定制报价。