はじめに
本ページは設計文書シリーズのL2 #10 — エコシステム設計（Layer 2・サイドチェーン）である。ビットコインの基盤チェーンの周囲に成長したエコシステムを扱う。決済チャネルネットワーク、連合型サイドチェーン、オンチェーンエンベロープ構造、協調的マイニングアーキテクチャー。これらのシステムが共有するのは、ビットコインのコンセンサスルールが維持する最多ワークチェーンという単一の依存関係のみである。実行場所、前提とする信頼モデル、L1への決済方法は、システムによって根本的に異なる。
重要な分類上の注意。OrdinalsとInscriptionsは一般的な議論で「レイヤー2」に分類されることがある。しかしそうではない。これらはL1エンベロープ構造であり、オンチェーンのWitness空間に直接埋め込まれ、すべてのフルノードによって検証され(過去のブロックデータを剪定していないノードでは保存も続く)、L1コンセンサスルールに従うデータである。本ページではこの区別を全体を通して維持する。Inscriptionは決済出力と同じ方法でブロックウェイトを占有する。Lightningの支払いはそうではない。
サトシ時代の実装（v0.1、2009年1月）と現行のBitcoin Core（v27以降基準）で挙動が異なる場合は、両方を記す。
1. エコシステム層マップ
以下の図は、主要なエコシステムコンポーネントをビットコインの基盤チェーンとの関係によって分類する。縦軸は信頼と決済距離を表す。スタックの上位にあるシステムほどL1への決済頻度が低く、追加の信頼前提を導入する可能性がある。
| 層 | 決済 | 信頼モデル | 例 |
|---|---|---|---|
| L1基盤チェーン | 毎ブロック（コンセンサスで強制） | トラストレス — すべてのフルノードが検証 | トランザクション、Ordinals/Inscriptions、OP_RETURNデータ |
| ブリッジ | オンチェーンの開設/閉鎖トランザクション | トラストレス（チャネル）または連合型（ペグ） | 2-of-2ファンディング出力、Liquid連合マルチシグ |
| L2オフチェーン | L1への定期的な決済 | さまざま — チャネル相手方、連合、マージマイニング | Lightning Network、Liquid、RSK |
| インフラストラクチャー | 運用上のもの — コンセンサスとは無関係 | オペレーターとのサービスレベルの信頼 | マイニングプール、ブロックエクスプローラー、取引所 |
2. Lightning Networkの設計
Lightning Networkはルーティング型決済チャネルネットワークである。2者が共有のオンチェーン出力に資金をロックし、ブロックチェーンに触れることなく残高を更新するために署名済みだが未ブロードキャストのトランザクションを交換する。支払いはハッシュタイムロックコントラクト (HTLC) を使用して複数のチャネルを経由してルーティングされ、直接のチャネルがなくても任意のLightningユーザーが他の任意のLightningユーザーに支払いを行える。
チャネルライフサイクル
プロトコルの用語で言えば、ファンディングは2-of-2マルチシグトランザクションであり、残高を更新するたびに新しいコミットメントトランザクションを交換して直前のものを失効させ、強制クローズが紛争に至るのは相手方が失効済み(すでに置き換えられた)コミットメント状態をブロードキャストした場合だけだ。
マルチホップ決済ルーティング (HTLC)
アリスがボブを中継者としてキャロルに支払う場合、支払いは原子的にロックするHTLCの連鎖を使用する。すべてのホップが決済されるか、どれも決済されないかのいずれかである。
プロトコルの用語で言えば、インボイスにはH = SHA-256(R) が含まれ、各HTLCスクリプトは出力をRにハッシュロックしつつ、受取人へ向かうほどタイムロックを短くする(アリス→ボブは40ブロック、ボブ→キャロルは20ブロック)ため、外側の区間が内側より短い導火線になることはない。成功側の経路では、Rをオンチェーン(または協調的にオフチェーン)で明かすことだけが、各区間の出力を請求する方法だ。Rが最後まで明かされなければ、各区間はタイムロック満了後にそれぞれ自分自身のHTLCタイムアウト返金へと切り替わる。
Lightning Networkの特性
| 特性 | 設計上の選択 |
|---|---|
| ファンディング | L1上の2-of-2マルチシグ出力; 開設に1つのオンチェーントランザクションが必要 |
| 容量 | ファンディング出力の額に制限される; オンチェーン預入額を超えられない |
| 更新 | オフチェーン: 当事者が署名済みコミットメントトランザクションを交換; ブロック確認不要 |
| 失効 | 古い状態は失効鍵を共有して失効させる; 失効済み状態をブロードキャストするとペナルティーが発動 |
| ルーティング | オニオン暗号化HTLCパスによるソースルーティング（BOLT 4）; 送信者がルートを選択 |
| プライバシー | 中継ノードは自身のホップのみを見る; 送信者と受信者はルーティングノードから秘匿される |
| ファイナリティー | 成功した支払いではサブ秒; 紛争解決にはタイムロック付きのオンチェーン決済が必要 |
| L1依存性 | OP_CHECKLOCKTIMEVERIFY、OP_CHECKSEQUENCEVERIFY、およびSegWit展性修正（BIP 141）に依存 |
L1前提条件
Lightning Networkはサトシのv0.1実装上では動作できなかった。ビットコインの基盤チェーンに、リリース後で追加された3つの要素に依存している:
| 前提条件 | BIP | 有効化 | Lightningが必要とする理由 |
|---|---|---|---|
| SegWit | BIP 141 | 2017 | トランザクション展性を修正 — 子トランザクション（コミットメントトランザクション）がファンディングtxidを確認前に参照でき、txidが変更されるリスクがない |
| CLTV | BIP 65 | 2015 | OP_CHECKLOCKTIMEVERIFYがHTLC返金パスで絶対タイムロックを強制 |
| CSV | BIP 68/112 | 2016 | OP_CHECKSEQUENCEVERIFYが失効遅延ウィンドウの相対タイムロックを強制 |
CLTVのオペコードはLightning専用に考案されたものではない。元々の仕様はピーター・トッドによるBIP 65の提案で規定されたものであり、後に非対話型のペイメントチャネルが依拠するタイムロックの基盤技術として採用された。
チャネルの開設・協調クローズ・強制クローズは、いずれも今なお、貨幣設計ページが記述する手数料市場でブロック領域を奪い合うオンチェーン・トランザクションである。Lightningがオフチェーンへ移すのは決済の量であって、チャネルの始まりと終わりを画する決済トランザクションそのものではない。
3. サイドチェーン: Liquidと連合型ペグ
サイドチェーンはビットコインにペグされた別のブロックチェーンである。コインがメインチェーンからサイドチェーンへ（ペグイン）、そして逆方向へ（ペグアウト）ブリッジ機構を通じて移動する。サイドチェーンはBTC建ての価値を使用しながら、独自のブロック時間、トランザクション形式、機能セットを定義できる。
ペグイン / ペグアウトフロー（Liquid）
サイドチェーン比較
| 特性 | Liquid Network | RSK (Rootstock) |
|---|---|---|
| コンセンサス | 連合型（ファンクショナリーコンソーシアムがブロックに署名） | ビットコインとマージマイニング（同じPoWが両チェーンを保護） |
| ブロック時間 | 約60秒 | 約30秒 |
| ペグ機構 | m-of-n連合マルチシグ（Liquidファンクショナリー） | m-of-n連合（PowPegハードウェアセキュリティーモジュール） |
| ペグイン確認数 | 102ビットコインブロック（約17時間） | 100ビットコインブロック（約17時間） |
| 信頼前提 | 連合メンバーの正直な多数派 | 連合の正直な多数派 + マージマイニングのハッシュレート |
| 追加機能 | 秘匿トランザクション、発行資産 | EVM互換スマートコントラクト |
| ネイティブ資産 | L-BTC（BTCと1:1のペグ） | RBTC（BTCと1:1のペグ） |
| トレードオフ | 連合の信頼と引き換えにファイナリティーの速さとプライバシー | 連合の信頼と引き換えにスマートコントラクト機能 |
トラストレスな双方向ペグがない理由。ビットコインのスクリプトシステムは、他のチェーンのプルーフオブワークや状態遷移を検証できない。完全にトラストレスな双方向ペグにはサイドチェーンのコンセンサスルールの検証ロジックを追加するソフトフォークが必要であり、提案はされている（Drivechain / BIP 300）が有効化されていない。既存のサイドチェーンはしたがって連合マルチシグをブリッジとして使用し、L1には存在しない信頼前提を導入している。
4. L1拡張: OrdinalsとInscriptions
OrdinalsとInscriptionsはレイヤー2ではない。ビットコインのL1コンセンサスルール内で完全に動作し、既存のWitness空間を使用して任意データを個々のサトシに埋め込む。すべてのフルノードがこのデータを正規ブロックの一部として処理・検証し、剪定していないノードでは無期限に保存し続ける。
InscriptionsがWitness空間を使用する仕組み
スクリプトの用語で言えば、エンベロープはTapscriptのWitness内にある、実行されないOP_FALSE OP_IF … OP_ENDIFの分岐だ。コードとして実行されることは一度もないが、そのすべてのバイトはノードが直列化を解いて検証し、ブロックウェイトに算入するWitnessの一部であり続ける。
Ordinal理論: サトシレベルの識別
Ordinalプロトコルは、マイニングされた順序に基づいてすべてのサトシに連番を割り当てる。この番号付けは慣習層にすぎず、ビットコインプロトコル自体は個々のサトシを区別しない。Ordinal対応ソフトウェアは、入力サトシを出力サトシに先入れ先出し (FIFO) でマッピングすることでトランザクション間のサトシの動きを追跡する。
| 概念 | 仕組み | コンセンサス上の位置付け |
|---|---|---|
| Ordinal番号 | マイニング順に各サトシに割り当てられる連番 | 慣習のみ — ビットコインのコンセンサスはすべてのサトシを同一に扱う |
| Inscription | Tapscript Witness内のOP_FALSE OP_IF ... OP_ENDIFエンベロープに埋め込まれた任意データ（画像、テキスト、JSON） | コンセンサス上有効 — データは有効なWitnessの一部でブロックウェイトにカウントされる |
| サトシ追跡 | 入力サトシを出力位置にFIFOで割り当て | 慣習のみ — オフチェーンインデクサーの解釈に依存 |
| 希少性モデル | 半減期と難易度調整に対する位置に基づく名前付き希少性階層（コモン、アンコモン、レア、エピック、レジェンダリー、ミシック） | 慣習のみ — オンチェーンでの強制なし |
Ordinals/InscriptionsがL2でない理由
| 基準 | L2システム（Lightning、サイドチェーン） | Ordinals/Inscriptions |
|---|---|---|
| 実行場所 | オフチェーン（別の状態マシンまたはチャネル） | オンチェーン（標準的なTapscript Witness実行） |
| ブロックウェイト消費 | なし（開設/閉鎖トランザクションのみがL1に触れる） | 全量 — すべてのバイトが4 MWU制限にカウントされる |
| フルノードのストレージ | チャネル更新についてはなし; サイドチェーンブロックは別途保存 | ブロックの一部としてすべてのビットコインフルノードが保存 |
| コンセンサス検証 | L1はアンカートランザクションのみを検証 | L1がスクリプト実行の一部としてエンベロープ全体を検証 |
| 決済モデル | L1への定期的な決済 | 決済不要 — すでにL1上にある |
5. マイニングプール
ソロマイニングは2011年頃から個人の参加者にとって現実的ではなくなった。マイニングプールによりマイナーはハッシュレートを合算し、共同でブロックを発見し、報酬を比例配分できる。プールはインフラストラクチャー層の参加者であり、コンセンサスルールを変更しないが、ブロックテンプレート構築権限をプールオペレーターに集中させる。どのトランザクションを収録し、どの手数料率順で並べるかというテンプレートそのものは、貨幣設計ページが記述するのと同じ手数料市場のオークションから組み立てられる。プールが変えるのは誰がそれを組み立てるかであって、その背後の規則ではない。これは、サトシの設計思想と現在の実態を扱う分析記事がマイニング軸で追跡する漂流の技術的な中身でもある。「1 CPU = 1票」が、以下で説明するStratumと支払いプロトコルを走らせる少数のプールへと集約していく過程だ。
プールアーキテクチャー
実際には、シェアの難易度ターゲットはネットワーク本来のターゲットよりずっと低く設定される。マイナーが1分間に何件も提出できるほど易しく、コーディネーターにハッシュレートを測るための安定した証拠の流れを与える。一方、本物のブロックを解くターゲットは、プール全体を通してもまれにしか満たされない。
プールプロトコル: Stratum v1とStratum v2
| 特性 | Stratum v1（2012） | Stratum v2（2023年以降） |
|---|---|---|
| テンプレート構築 | プールがブロックテンプレートを構築; マイナーはヘッダーをハッシュ | マイナーが独自のテンプレートを構築可能（ジョブ宣言プロトコル） |
| トランスポート | 平文JSON（TCP経由） | バイナリーフレーミング、オプションでノイズプロトコル暗号化 |
| トランザクション選択 | プールオペレーターが含めるトランザクションを選択 | ジョブ宣言あり: 個々のマイナーがトランザクションを選択 |
| 検閲耐性 | プールオペレーターがブロック内容の唯一の決定権を持つ | マイナーが独立にブロック内容を構築可能 |
| 効率 | 帯域幅が大きい（JSON符号化のオーバーヘッド） | 帯域幅が小さい（バイナリー符号化） |
| 普及状況 | 2025年時点でほぼ普遍的 | 拡大中; Demand Pool（DMND）はこれを土台にする。Oceanは検討したうえで、独自のテンプレートの仕組みDATUMを作った（2024年） |
報酬分配方式
| 方式 | 仕組み | マイナーにとっての変動 |
|---|---|---|
| PPS（シェアごと支払い） | プールがブロック発見の有無にかかわらず有効なシェアごとに固定額を支払う | 変動ゼロ — プールがすべてのリスクを吸収 |
| FPPS（完全シェアごと支払い） | PPSと同様だが推定トランザクション手数料もシェアごとに分配 | 変動ゼロ — 手数料構成要素を含む |
| PPLNS（直近Nシェアに比例して支払い） | ブロック発見前のウィンドウ内に提出されたシェアに比例して報酬を分配 | 変動が大きい — 支払いはプールのブロック発見に依存 |
| ソロ（プール経由） | マイナーのシェアがブロックを解いた場合にブロック報酬全額を受領; それ以外は何もなし | 最大変動 — プールインフラストラクチャーを使うソロマイニングと同等 |
6. エコシステム層の比較
以下の表は、本ページで扱った4つのエコシステムカテゴリーを、一貫した設計特性のセットに対して構造的に比較する。
| 特性 | Lightning Network | Liquid（サイドチェーン） | Ordinals/Inscriptions | マイニングプール |
|---|---|---|---|---|
| 層の分類 | L2（オフチェーン） | L2（別チェーン） | L1（オンチェーンエンベロープ） | インフラストラクチャー |
| 信頼モデル | チャネル相手方（紛争付きのトラストレス） | 連合（m-of-nマルチシグ） | トラストレス（コンセンサス検証済み） | プールオペレーター（報酬サイクル中はカストディアル） |
| L1ブロックウェイト | 最小（開設/閉鎖のみ） | 最小（ペグイン/ペグアウトのみ） | 全量（すべてのバイトがオンチェーン） | 該当なし — プールはL1ブロックを生成 |
| トランザクションスループット | 毎秒数百万（理論値） | Liquidのブロックの大きさに制約（1分に1ブロック） | L1ブロックウェイトに制約 | 該当なし |
| ファイナリティー | サブ秒（支払い） | 約120秒（2 Liquidブロック） | 約60分（6ビットコイン確認） | 該当なし |
| プライバシー | オニオンルーティング（送信者/受信者が中継者から秘匿） | 秘匿トランザクション（金額が秘匿） | 完全公開（オンチェーンデータ） | プールにより異なる |
| 必要なソフトフォーク | SegWit（BIP 141）、CLTV（BIP 65）、CSV（BIP 68/112） | なし（連合は標準マルチシグを使用） | Taproot（BIP 341）（Tapscriptエンベロープ用） | なし |
| 障害モード | チャネルをオンチェーンで強制閉鎖; 資金は回復可能 | 連合障害: 定足数が回復するまでペグアウト不可 | 該当なし — データは不変にオンチェーン | プールがオフラインに: マイナーはプールを切り替え; 資金損失なし |
7. 本ページの範囲
本ページではエコシステム層のシステムを設計レベルで解説した。以下のトピックは範囲外であり、設計文書シリーズ内のそれぞれのドメインページで扱う:
- トランザクション構造とUTXOモデル: Lightningチャネルとサイドチェーンペグの基盤となるL1プリミティブ。トランザクション設計ページで解説。
- TaprootとTapscriptの仕組み: Witnessプログラムとスクリプトパス支払いがオペコードレベルでどのように動作するか。トランザクション設計ページで解説。
- P2Pゴシップとブロック中継: トランザクションとブロックがマイナーやLightningノードに到達する前にネットワーク上でどのように伝搬するか。P2Pネットワーク設計ページで解説。
- プルーフオブワークと難易度調整: すべてのエコシステム層が依存する基盤チェーンを保護するコンセンサス機構。コンセンサス設計ページで解説。
- 手数料市場とブロックテンプレート構築: トランザクションの収録優先度を決定する経済的ダイナミクス。貨幣設計ページで扱う。
