跳至內容
0%

如何在 UTXO 鏈上開發:Bitcoin、Litecoin、Dogecoin 與 Bitcoin Cash

作者:Uttam Singh

最後更新:2026年5月26日2 分鐘閱讀
漸層網格背景上的 Bitcoin、Litecoin 和 Dogecoin 圖示

比特幣沒有帳戶餘額,從來就沒有。萊特幣、狗狗幣、比特幣現金也都沒有。這四條鏈共享一個 2009 年設計的 UTXO model,取代了每個 Ethereum 和 Solana 開發者都習以為常的「每個地址一列」狀態機。這個模型在協定層級可以運作,但到了應用層就出問題:你的應用程式需要的每個基本查詢,不是不存在,就是得靠外部索引器重新組合出來。

這就是為什麼在 UTXO 鏈上開發的團隊多年來都得自己拼湊基礎設施:一個 RPC 提供者、另一個索引讀取提供者、第三個 webhook 提供者,再加上自己寫程式碼補缺口。我們的 UTXO 套件把這些全部整合成單一平台,涵蓋這四條鏈,使用你在 EVM 和 Solana 上已經在用的同一套儀表板、API 金鑰與計量系統。

UTXO 鏈有什麼不同?

UTXO 代表「未花費交易輸出」(unspent transaction output)。每筆比特幣交易會消耗一個或多個輸出作為輸入,並產生新的輸出。錢包的「餘額」不會儲存在鏈上任何地方,而是把該錢包控制的、尚未被花費的所有輸出加總計算出來的。Bitcoin developer guide 說得很明確:「當你的比特幣錢包告訴你有 10,000 satoshi 的餘額時,實際上是指你有 10,000 satoshi 分散在一個或多個 UTXO 中等著被使用。」

舉個具體例子。Alice 控制三個 UTXO:0.4 BTC、0.3 BTC、0.2 BTC。她要轉 0.5 BTC 給 Bob。這筆交易會完全消耗她的 0.4 和 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 Core 儲存區塊與交易,但不維護地址對交易的索引。核心開發者明確拒絕新增這個功能,正如一位維護者所說:「地址索引本質上無法擴展,因為它會隨區塊鏈大小線性成長。」他們的立場是,地址索引應該交給外部服務處理。所以每個需要顯示餘額、列出使用者交易紀錄、或監控收款的比特幣應用程式,都得架在索引器之上——一種監控鏈上活動並維護可查詢的地址、交易與 UTXO 資料庫的服務。唯一的問題只在於由誰來營運。大多數團隊選擇使用代管的區塊鏈節點供應商,而不是自己架設基礎設施。

錢包不是只有一個地址,而是成千上萬個

重複使用同一個地址,會把所有輸入與輸出都連結到同一個身分。所以慣例是每次收款都用一個新地址,透過 BIP 32 定義的分層確定性(HD)金鑰從單一種子衍生出來。持有一個企業 xpub(一種擴展公鑰,能從單一根金鑰衍生出一整套收款地址,而不會洩漏花費用的私鑰)的交易所,可以給每位客戶顯示一個全新衍生的存款地址。自我託管錢包也能從 12 個字的種子重新計算出它控制的每一個 UTXO。問題在於:索引器必須依序衍生地址並全部監控,由 BIP 44 的 20 個地址間隔限制決定何時停止。一旦跳過 20 個地址,索引器就會以為你結束了——這正是現實中「我的資金去哪了」客訴工單的真正成因。

手續費按大小計費,不是按金額計費

計費單位是每虛擬位元組的 satoshi 數。一個把 100 個小額 UTXO 合併成一個輸出的錢包,付的手續費會與這 100 個輸入成正比,與移動的金額無關。費率估算取決於記憶池狀態,每分鐘都在變動。卡住的交易可以用 replace-by-fee (BIP 125) 或 child-pays-for-parent 加速確認。這些在概念上都不難,但全都是你原本得自己寫的實際生產程式碼。

最終性是機率性的

比特幣區塊可能被競爭區塊重組出主鏈。一旦發生,被移出區塊中的所有交易都會回到記憶池,原本「已花費」的輸出重新變成未花費狀態。你的索引器必須乾淨地回滾,否則會把錯誤的餘額回傳給你的應用程式。應用程式會用確認數門檻來自我保護:低額付款用 1 個確認,歷史慣例用 6 個確認,大額交易所存款用 30 個以上確認。萊特幣與狗狗幣的區塊時間較短(LTC 為 2.5 分鐘,DOGE 為 1 分鐘),所以同樣數量的確認數買到的實際時間安全性較低。

地址格式一直在變

比特幣已經推出三次地址格式升級,且都沒有淘汰舊格式:2012 年的 P2SH、2017 年的 SegWit、2021 年的 Taproot。目前網路上同時存在四種地址家族:傳統 P2PKH (1...)、巢狀 SegWit P2SH (3...)、原生 SegWit P2WPKH (bc1q...)、以及 Taproot P2TR (bc1p...)。一筆 1 輸入、2 輸出的 P2WPKH 交易大約是 141 個虛擬位元組,相對地等效的 P2PKH 交易約為 226 vB,所以格式選擇會直接影響手續費。正式環境的錢包與瀏覽器必須支援全部四種格式。

每個在比特幣上開發的團隊,第一季都會花掉一大段時間處理這份清單。而這大部分都跟他們要交付的產品本身無關。

Alchemy 如何支援 UTXO 鏈?

我們在同一個平台上支援 Bitcoin、Litecoin、Dogecoin 和 Bitcoin Cash,與 Ethereum、Solana 及其他鏈目錄並列。同樣的 API 金鑰、同樣的儀表板、同樣的計量模式、同樣的 webhook。每個方案都提供全部功能。

上線時提供的功能:

  • 原生 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

持續連線用於即時更新:

javascript
Copied
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 quickstart 與 Bitcoin JSON-RPC reference 中。想深入了解 UTXO 狀態與帳戶狀態的差異,可參考我們的 UTXO vs. account model docs,內容涵蓋協定層級的運作機制。

這跟市面上其他方案有什麼不同?

如果你今天已經在比特幣上開發,大概正在使用以下三家供應商之一,而每一家都有缺口:

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,加入比特幣並不是一個採購專案,而是一條鏈的開關。同樣的 API 金鑰、同樣的計量方式、同樣的 webhook 交付模式、同樣的儀表板。多年來在 UTXO 鏈上已成慣例的多供應商配置,整合成了單一套系統。

四條鏈,一套功能

每個現有供應商都涵蓋這些鏈與功能的某種組合,但涵蓋程度並不一致。QuickNode 在 BTC、LTC、BCH 上提供 Blockbook 索引讀取與 xpub 追蹤;Dogecoin 的 Blockbook 則是另外付費的附加功能。Blockcypher 透過 wallets/hd 提供 BTC、LTC、DOGE 的 HD Wallets。Blockdaemon 的 Wallet Transact API 涵蓋全部四條鏈的交易建構。各團隊最終得依照自己需要的特定功能與鏈組合,逐一比對哪個供應商支援,剩下的再自己寫程式碼補上。我們在單一套件中提供 Bitcoin、Litecoin、Dogecoin 與 Bitcoin Cash 的 xpub 追蹤、索引讀取、交易操作與 WebSocket 訂閱,沒有按鏈附加收費或功能拆分。

遷移只是改 HTTP 呼叫,不用重新架構

針對 Blockbook 風格的 bb_* 方法(QuickNode 的格式)與 Blockdaemon 風格的 bd_* 方法提供相容性包裝層,代表你既有的整合可以維持原本的請求格式。你改的是主機位址,不用重寫呼叫端的程式碼。對於還在用 Blockcypher 舊版 REST 介面的團隊而言,請求格式確實會改變(我們用格式不同的 REST GET),但底層的資料模型是一致的。我們在上線時提供整合的UTXO migration guide,分別涵蓋 Blockcypher、QuickNode Blockbook 與 Blockdaemon 的遷移章節。

對開發者來說,好處可以濃縮成一句話:需要拼湊的基礎設施更少、要管理的供應商更少,從「我們需要比特幣支援」到真正交付所花的時間更短。

用 Alchemy 在比特幣上開發

Bitcoin、Litecoin、Dogecoin 和 Bitcoin Cash 現已在 Alchemy 上線,與 Ethereum、Solana 及 100 多條其他鏈並列。PAYG 開發者第一天就能從儀表板新增這些鏈,不需要合約、不需要候補名單、也沒有最低消費門檻。Enterprise 客戶可以在既有的計算單位額度中使用 UTXO 鏈。完整功能細節請參閱 the Bitcoin support launch announcement。

到 Alchemy dashboard 建立一個端點並開始查詢,或是聯絡業務取得企業整合支援與客製化報價。

Alchemy 電子報

搶先掌握最新發布消息

訂閱我們的電子報

取得 Alchemy 最新產品更新與資源

A
O
D
+
超過 80,000 名訂閱者

輸入您的電子郵件地址,即表示您同意接收我們的行銷通訊與產品更新。您了解 Alchemy 會依照我們的隱私權聲明處理所收到的資訊。您可以隨時取消訂閱。