---
title: "UTXOチェーンでの開発方法：Bitcoin、Litecoin、Dogecoin、Bitcoin Cash"
description: "開発者向けUTXOチェーン解説：Bitcoin、Litecoin、Dogecoin、Bitcoin CashがEVMとどう違うか、必要なインフラは何か、Alchemyがそれをどう提供するか。"
---

# UTXOチェーンでの開発方法：Bitcoin、Litecoin、Dogecoin、Bitcoin Cash

<ImageBlock
  src="https://media.alchemy.com/blog/alchemy-bitcoin-support-hero.png"
  alt="グラデーショングリッド背景に配置されたBitcoin、Litecoin、Dogecoinのアイコン"
  width={1024}
  height={480}
  priority
/>

Bitcoinにはアカウント残高がない。最初からなかった。Litecoin、Dogecoin、Bitcoin Cashも同様だ。この4つのチェーンは、[UTXOモデル](https://www.alchemy.com/docs/bitcoin/utxo)という2009年設計のモデルを共有している。これはEthereumやSolanaの開発者が当たり前と考えている「アドレスごとに1行」というステートマシンとは異なるものだ。このモデルはプロトコルレベルではうまく機能する。しかしアプリケーション層では破綻する。アプリが必要とする基本的なクエリのほとんどが存在しないか、外部インデクサーによって再構成しなければならないからだ。

そのため、UTXOチェーン上で開発するチームは、何年もかけてインフラをつなぎ合わせてきた。RPC用に1つのプロバイダー、インデックス済みの読み取り用に別のプロバイダー、Webhook用にさらに別のプロバイダー、そして隙間を埋めるための独自コード。私たちのUTXOバンドルは、これを4つのチェーンすべてにまたがる単一のプラットフォームへと集約する。[EVM](https://www.alchemy.com/overviews/what-is-the-ethereum-virtual-machine-evm)や[Solana](https://www.alchemy.com/solana)で使っているのと同じダッシュボード、APIキー、メータリングの上で。

## UTXOチェーンの何が違うのか?

UTXOは「unspent transaction output(未使用トランザクション出力)」の略だ。すべてのBitcoinトランザクションは1つ以上の出力を入力として消費し、新しい出力を作る。ウォレットの「残高」はチェーン上のどこにも保存されていない。そのウォレットが管理する、まだ使われていないすべての出力を合計することで計算される。[Bitcoin developer guide](https://developer.bitcoin.org/devguide/transactions.html)はこれを明確に述べている。「あなたのBitcoinウォレットが10,000サトシの残高があると告げるとき、それが実際に意味しているのは、10,000サトシが1つ以上のUTXOの中で待機しているということだ」。

具体例を示す。Aliceは0.4 BTC、0.3 BTC、0.2 BTCという3つのUTXOを管理している。彼女はBobに0.5 BTCを送る。このトランザクションは0.4 BTCと0.3 BTCの出力を全額消費し、Bob宛に0.5 BTCの出力を作り、Aliceが管理する新しいアドレスへのお釣りとして約0.1999 BTCを返し、約0.0001 BTCをマイナー手数料として残す。0.2 BTCのUTXOは手つかずのままだ。UTXOはアトミックであり、一部だけを使うことはできない。

アカウントベースのチェーンとの対比は鮮明だ。

<EmbeddedTable
  table={{
    columns: [
      { key: "feature", width: 180, title: "Feature", dataType: "object" },
      {
        key: "accountBased",
        width: 280,
        title: "Account-based (Ethereum)",
        dataType: "object",
      },
      { key: "utxo", width: 300, title: "UTXO (Bitcoin)", dataType: "object" },
    ],
    data: [
      {
        feature: { title: "State", tooltip: "", icon: "" },
        accountBased: {
          title: "One balance per address",
          tooltip: "",
          icon: "",
        },
        utxo: {
          title: "A set of unspent outputs, each with a locking script",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        feature: { title: '"Balance" query', tooltip: "", icon: "" },
        accountBased: {
          title: "Direct read from state trie",
          tooltip: "",
          icon: "",
        },
        utxo: {
          title: "Sum of unspent outputs the wallet controls",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        feature: { title: "Atomicity", tooltip: "", icon: "" },
        accountBased: {
          title: "A single tx mutates two balances",
          tooltip: "",
          icon: "",
        },
        utxo: {
          title: "A single tx consumes N inputs and creates M outputs",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        feature: { title: "Privacy default", tooltip: "", icon: "" },
        accountBased: { title: "Same address for life", tooltip: "", icon: "" },
        utxo: {
          title: "New address per transaction is the convention",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        feature: { title: "Parallel validation", tooltip: "", icon: "" },
        accountBased: {
          title: "Hard (every tx touches shared state)",
          tooltip: "",
          icon: "",
        },
        utxo: {
          title: "Easy (independent outputs don't conflict)",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        feature: { title: "Replay protection", tooltip: "", icon: "" },
        accountBased: {
          title: "Nonces per account",
          tooltip: "",
          icon: "",
        },
        utxo: {
          title: "Each output can only be referenced once",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
    ],
  }}
/>

[Litecoin](https://www.alchemy.com/rpc/litecoin)、[Dogecoin](https://www.alchemy.com/rpc/dogecoin)、[Bitcoin Cash](https://www.alchemy.com/rpc/bitcoin-cash)はすべてこのモデルを継承している。これらはBitcoinのコードベースをフォークし、ブロックタイムといくつかのパラメータを調整して公開された。同じメンタルモデルと同じ種類のインフラが、この4つのチェーンすべてに適用される。

## なぜ開発者が気にするのか?

その違いは哲学的なものではない。ほとんどのチームが作業量を過小評価してしまう具体的な箇所に現れる。

### ノードにアドレスの残高を尋ねることはできない

Bitcoin Coreはブロックとトランザクションを保存する。アドレスとトランザクションの対応インデックスは維持しない。Coreの開発者は、あるメンテナーの言葉を借りれば「アドレスインデックスはブロックチェーンのサイズに比例して線形に増加するため本質的にスケールしない」という理由で、インデックスの追加を[明示的に拒んできた](https://bitcoincore.reviews/14053)。彼らの立場は、アドレスインデックスは外部サービスの領分だというものだ。そのため、残高の表示、ユーザーのトランザクション一覧、入金の監視を必要とするすべてのBitcoinアプリは、インデクサー — チェーンを監視し、アドレス、トランザクション、UTXOのクエリ可能なデータベースを維持するサービス — の上に構築される。問題は誰がそれを運用するかだけだ。ほとんどのチームは、自前のインフラを立ち上げる代わりに[ホスト型のブロックチェーンノードプロバイダー](https://www.alchemy.com/overviews/blockchain-node-providers)を利用する。

### ウォレットは1つのアドレスではなく、何千ものアドレスを持つ

アドレスを使い回すと、すべての入力と出力が1つのアイデンティティに紐づいてしまう。そのため、受け取りごとに1つのアドレスを使うのが慣例であり、これは[BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)で定義された階層的決定性(HD)鍵によって単一のシードから導出される。1つの企業用xpub(秘密鍵を公開せずに単一のルートから受け取りアドレスのツリーを導出できる拡張公開鍵)を保有する取引所は、すべての顧客に新たに導出した入金アドレスを表示できる。セルフカストディのウォレットは、12単語のシードから管理しているすべてのUTXOを再計算できる。ただし注意点がある。インデクサーはアドレスを順番に導出して監視しなければならず、いつ止めるかは[BIP 44の20アドレスのギャップリミット](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)によって決まる。20個のアドレスを飛ばすと、インデクサーはそこで終わったと判断してしまい、これが「資金がどこに行ったのか」という問い合わせの実際の原因になる。

### 手数料は価値ではなくサイズで決まる

単位はサトシ毎仮想バイトだ。100個の小さなUTXOを1つの出力に統合するウォレットは、移動する金額の大小にかかわらず、その100個の入力に比例した手数料を支払う。手数料の見積もりはメンプール依存で、分単位で変動する。詰まったトランザクションは[replace-by-fee(BIP 125)](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki)や[child-pays-for-parent](https://bitcoinops.org/en/topics/cpfp/)で引き上げられる。これらはどれも概念的に難しくはない。だがすべて、自分で書かなければならなくなる本物のプロダクションコードだ。

### ファイナリティは確率的

Bitcoinのブロックは、競合するブロックによってチェーンから外され、再編成されることがある。それが起きると、外されたブロックに含まれていたすべてのトランザクションはメンプールに戻る。「使用済み」だった出力は再び未使用に戻る。インデクサーはこれをきれいに巻き戻さなければならず、さもなければアプリに誤った残高を渡してしまう。アプリは確認数のしきい値で自衛する。低額決済なら1確認、歴史的な標準なら6確認、大口の取引所への入金なら30確認以上といった具合だ。LitecoinとDogecoinはブロックタイムが短い(LTCは2.5分、DOGEは1分)ため、同じ確認数でも実時間ベースの安全性は低くなる。

### アドレス形式は変わり続ける

Bitcoinはこれまで3回のアドレス形式アップグレードを、以前の形式を廃止することなく行ってきた。2012年のP2SH、2017年のSegWit、2021年のTaprootだ。現在ネットワーク上には4つの系統が共存している。レガシーP2PKH(`1...`)、ネスト型SegWit P2SH(`3...`)、ネイティブSegWit P2WPKH(`bc1q...`)、Taproot P2TR(`bc1p...`)だ。1入力2出力のP2WPKHトランザクションはおよそ[141仮想バイト](https://learnmeabitcoin.com/technical/transaction/size/)であるのに対し、同等のP2PKHトランザクションは約226 vBであり、形式の選択は手数料に直接影響する。本番環境のウォレットやエクスプローラーはこの4つすべてをサポートしなければならない。

Bitcoin上で開発するすべてのチームは、最初の四半期のかなりの部分をこのリストに費やしている。そのほとんどは、実際に出荷しようとしているプロダクトとは無関係だ。

## AlchemyはUTXOチェーンをどうサポートするのか?

私たちは[Bitcoin](https://www.alchemy.com/rpc/bitcoin)、[Litecoin](https://www.alchemy.com/rpc/litecoin)、[Dogecoin](https://www.alchemy.com/rpc/dogecoin)、[Bitcoin Cash](https://www.alchemy.com/rpc/bitcoin-cash)を、EthereumやSolana、[その他のチェーンディレクトリ](https://www.alchemy.com/rpc)と同じプラットフォーム上でサポートする。同じAPIキー。同じダッシュボード。同じメータリングモデル。同じWebhook。すべての機能がすべてのティアで提供される。

ローンチ時点で提供されるもの:

- **生のJSON-RPCパススルー**: `-txindex=1`で動作するフルノードに対して、標準的なBitcoin Coreのメソッド(`getblock`、`getrawtransaction`、`estimatesmartfee`、`sendrawtransaction`、その他すべて)を提供する。
- **インデックス済みREST API**: アドレス残高、UTXO検索、ページネーション対応のトランザクション履歴、詳細情報付きトランザクション、使用状況を提供する。Bitcoin Coreがネイティブには答えられないクエリを、ミリ秒単位で返す。
- **xpubおよびディスクリプタの追跡**: 4つのチェーンすべてで対応。出力ディスクリプタは1つの鍵からアドレスをどう導出するかを指定するもので、私たちはBIP 44、49、84、86のツリーと標準的な20アドレスのギャップリミットにわたる導出処理を行う。残高、UTXO、履歴のクエリは、最初に送信した1つのアドレスだけでなく、導出されたアドレス全体の集合に対して実行される。
- **WebSocketサブスクリプション**: 確認済みトランザクション、アドレスのアクティビティ、新規ブロック、reorg通知に対応し、ストリームごとに確認数のしきい値を設定できる。
- **生のブロードキャストを超えたトランザクション操作**: 高速・中速・低速の段階に分けた(メンプールを考慮した)手数料見積もり、未署名トランザクションの構築、コンパイル、検証、ブロードキャスト。
- **互換ラッパー**: Blockbookスタイルの`bb_*`メソッド(QuickNodeの形式)とBlockdaemonスタイルの`bd_*`メソッドシグネチャに対応し、既存のインテグレーションをHTTP呼び出しの変更だけで移行できる。

コードにすると次のようになる。ノードがサポートするあらゆる処理に対する生のJSON-RPC:

<CodeSnippet
  language="bash"
  code={`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:

<CodeSnippet
  language="bash"
  code={`# 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`}
/>

リアルタイム更新のための永続的な接続:

<CodeSnippet
  language="javascript"
  code={`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](https://www.alchemy.com/docs/reference/bitcoin-api-quickstart)と[Bitcoin JSON-RPC reference](https://www.alchemy.com/docs/bitcoin/bitcoin-api-overview)にある。UTXOの状態がアカウントの状態とどう異なるかをより深く理解したい場合は、[UTXO vs. account model docs](https://www.alchemy.com/docs/utxo-vs-account-models)がプロトコルレベルの仕組みを扱っている。

## 既存のものとは何が違うのか?

もし現在Bitcoin上で開発しているなら、おそらく3つのプロバイダーのいずれかを使っているだろう。それぞれに欠けている部分がある。

<EmbeddedTable
  table={{
    columns: [
      {
        key: "capability",
        width: 260,
        title: "Capability",
        dataType: "object",
      },
      { key: "alchemy", width: 190, title: "Alchemy", dataType: "object" },
      { key: "quicknode", width: 230, title: "QuickNode", dataType: "object" },
      {
        key: "blockdaemon",
        width: 210,
        title: "Blockdaemon",
        dataType: "object",
      },
      {
        key: "blockcypher",
        width: 210,
        title: "Blockcypher",
        dataType: "object",
      },
    ],
    data: [
      {
        capability: {
          title: "BTC indexed reads (balance, UTXO, tx history)",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "Yes", tooltip: "", icon: "" },
        quicknode: { title: "Yes", tooltip: "", icon: "" },
        blockdaemon: { title: "Yes", tooltip: "", icon: "" },
        blockcypher: { title: "Yes", tooltip: "", icon: "" },
        id: 0,
      },
      {
        capability: { title: "LTC + BCH indexed reads", tooltip: "", icon: "" },
        alchemy: { title: "Yes", tooltip: "", icon: "" },
        quicknode: { title: "Yes", tooltip: "", icon: "" },
        blockdaemon: { title: "Partial", tooltip: "", icon: "" },
        blockcypher: { title: "Yes", tooltip: "", icon: "" },
        id: 1,
      },
      {
        capability: { title: "DOGE indexed reads", tooltip: "", icon: "" },
        alchemy: { title: "Yes", tooltip: "", icon: "" },
        quicknode: { title: "Blockbook add-on (paid)", tooltip: "", icon: "" },
        blockdaemon: { title: "Partial", tooltip: "", icon: "" },
        blockcypher: { title: "Yes", tooltip: "", icon: "" },
        id: 2,
      },
      {
        capability: {
          title: "xpub / descriptor tracking",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "All four chains", tooltip: "", icon: "" },
        quicknode: {
          title: "BTC, LTC, BCH (DOGE via paid add-on)",
          tooltip: "",
          icon: "",
        },
        blockdaemon: { title: "Not documented", tooltip: "", icon: "" },
        blockcypher: {
          title: "HD Wallets (BTC, LTC, DOGE)",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        capability: { title: "WebSocket subscriptions", tooltip: "", icon: "" },
        alchemy: { title: "Yes", tooltip: "", icon: "" },
        quicknode: { title: "Yes", tooltip: "", icon: "" },
        blockdaemon: { title: "Limited", tooltip: "", icon: "" },
        blockcypher: { title: "Yes", tooltip: "", icon: "" },
        id: 4,
      },
      {
        capability: {
          title:
            "Transaction operations (construct, compile, verify, broadcast)",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "BTC, LTC, BCH", tooltip: "", icon: "" },
        quicknode: {
          title: "Broadcast + decode (raw RPC)",
          tooltip: "",
          icon: "",
        },
        blockdaemon: {
          title: "Full lifecycle (Wallet Transact)",
          tooltip: "",
          icon: "",
        },
        blockcypher: { title: "Yes", tooltip: "", icon: "" },
        id: 5,
      },
      {
        capability: {
          title:
            "Migration-compat wrappers (<code>bb_*</code>, <code>bd_*</code>)",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "Yes", tooltip: "", icon: "" },
        quicknode: { title: "N/A", tooltip: "", icon: "" },
        blockdaemon: { title: "N/A", tooltip: "", icon: "" },
        blockcypher: { title: "N/A", tooltip: "", icon: "" },
        id: 6,
      },
      {
        capability: {
          title: "Unified dashboard with EVM and Solana",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "Yes", tooltip: "", icon: "" },
        quicknode: { title: "No", tooltip: "", icon: "" },
        blockdaemon: { title: "No", tooltip: "", icon: "" },
        blockcypher: { title: "No", tooltip: "", icon: "" },
        id: 7,
      },
    ],
  }}
/>

開発者にとって変わる点は3つある。

### 1社のベンダー、1つのインテグレーション、1枚の請求書

すでに[Ethereum](https://www.alchemy.com/ethereum)、[Base](https://www.alchemy.com/base)、[Polygon](https://www.alchemy.com/polygon)、[Solana](https://www.alchemy.com/solana)でAlchemyを使っているなら、Bitcoinの追加は調達プロジェクトではない。有効にするだけのチェーンだ。同じAPIキー、同じメータリング、同じWebhook配信モデル、同じダッシュボード。UTXOチェーンで何年も標準とされてきたマルチベンダー構成は、単一のインテグレーションに集約される。

### 4つのチェーン、1つの機能セット

既存のプロバイダーはそれぞれ、これらのチェーンと機能の組み合わせのいくつかをカバーしているが、そのカバー範囲は均一ではない。QuickNodeはBTC、LTC、BCHでBlockbookのインデックス済み読み取りとxpub追跡を提供しているが、DogecoinのBlockbookは別料金の有料アドオンだ。Blockcypherは、`wallets/hd`を通じてBTC、LTC、DOGEでHD Walletsを提供する。BlockdaemonのWallet Transact APIは4つのチェーンすべてでトランザクション構築をカバーする。各チームは結局、自分たちが必要とする特定の機能とチェーンの組み合わせをサポートするプロバイダーをユースケースごとに選び、残りを独自コードでつなぎ合わせることになる。私たちはxpub追跡、インデックス済み読み取り、トランザクション操作、WebSocketサブスクリプションをBitcoin、Litecoin、Dogecoin、Bitcoin Cashにわたって1つのバンドルとして提供する。チェーンごとのアドオンや機能の分割はない。

### 移行はHTTP呼び出しの変更であり、再設計ではない

Blockbookスタイルの`bb_*`メソッド(QuickNodeの形式)とBlockdaemonスタイルの`bd_*`メソッドに対する互換ラッパーによって、既存のインテグレーションはリクエストの形式を保ったまま移行できる。変わるのはホストだけだ。呼び出し箇所を書き換える必要はない。Blockcypherのレガシーなrestインターフェースを使っているチームについては、リクエスト形式自体は変わる(私たちは異なる形式のREST GETを使用する)が、基盤となるデータモデルは同じだ。ローンチ時には、Blockcypher、QuickNode Blockbook、Blockdaemonのそれぞれについてのセクションを含む、統合された[UTXO migration guide](https://www.alchemy.com/docs/bitcoin/utxo-migration-guide)を提供する。

開発者にとってのメリットを一言でまとめると、つなぎ合わせるべきインフラが減り、管理すべきプロバイダーが減り、「Bitcoinサポートが必要だ」から実際に出荷するまでの道のりが速くなる、ということだ。

## AlchemyでBitcoinを使って構築する

Bitcoin、Litecoin、Dogecoin、Bitcoin Cashは、Ethereum、Solana、その他100以上のチェーンと並んでAlchemy上ですでに稼働している。PAYGの開発者は初日からダッシュボードでチェーンを追加できる。契約もウェイトリストも最低利用条件もない。エンタープライズ顧客は、既存のコンピュートユニット割り当ての中でUTXOチェーンを利用できる。機能の全容については[Bitcoin support launch announcement](https://www.alchemy.com/blog/alchemy-now-supports-bitcoin)を参照してほしい。

[Alchemyダッシュボード](https://dashboard.alchemy.com/)でエンドポイントを作成し、クエリを始めるか、エンタープライズ向けのインテグレーション支援とカスタム価格については[営業に問い合わせ](https://www.alchemy.com/contact-sales)てほしい。