如何在 UTXO 鏈上開發:Bitcoin、Litecoin、Dogecoin 與 Bitcoin Cash
作者:Uttam Singh

比特幣沒有帳戶餘額,從來就沒有。萊特幣、狗狗幣、比特幣現金也都沒有。這四條鏈共享一個 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。
與帳戶制鏈的對比十分明顯:
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:
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:
# 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持續連線用於即時更新:
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,內容涵蓋協定層級的運作機制。
這跟市面上其他方案有什麼不同?
如果你今天已經在比特幣上開發,大概正在使用以下三家供應商之一,而每一家都有缺口:
對開發者來說,有三件事會不同。
單一供應商、單一整合、單一帳單
如果你已經在 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 最新產品更新與資源
輸入您的電子郵件地址,即表示您同意接收我們的行銷通訊與產品更新。您了解 Alchemy 會依照我們的隱私權聲明處理所收到的資訊。您可以隨時取消訂閱。


