流動性の芸術：どのようなビットコイン・オフチェーンスケーリングネットワークが必要とされているのか？
TechFlow厳選深潮セレクト
流動性の芸術：どのようなビットコイン・オフチェーンスケーリングネットワークが必要とされているのか？
本稿は流動性の拡張という視点から、チャネルネットワークの進化の歴史と今後の将来の発展動向について考察する。
Web3業界の深掘り報道に専念し潮流を洞察著者：Ben，Discoco Labs Founder
序論
長年にわたり、私は一つの問いを考えてきました。「Bitcoinネイティブなスケーリングの本質的なロジックとは何か？」です。
Lightning Network（以下、LN）を深く研究し、非カストディ型ビジネスをLN上に実装しようとした際、いくつかの点で不協和音を感じました。二者的チャネルは理論上非常に高い取引スループットを持つ一方で、実際の運用・使用における課題は予想以上に多く存在します。特に、LNが当初目指したマイクロペイメント分野での成果は芳しくなく、その最大の原因は「流動性」にあります。現在では多くの「流動性改善インフラ」が登場していますが、依然として期待される効果には届いていません。
本稿執筆中に、業界で知られる自前管理型LNウォレット「Mutiny Wallet」が運営終了を発表し、それに連動する流動性サービスプロバイダー（LSP）も同時に終了しました。自前管理ウォレットとLSPの協働モデルは、長らくLNの将来における重要方向性とされてきたため、この出来事は再びその未来に対する不安を強めています。そこで本稿では、「流動性拡張」という視点から、チャネルネットワークの進化の歴史と今後の展望について考察していきます。
1. 現在のLightning Networkの問題点
Bitcoinのブロック容量は限定されており、平均約10分間隔でのブロック生成は、「世界規模のP2Pキャッシュシステム」という目標から見れば明らかに不足しています。このため、ブロック空間の消費が少なく、迅速に決済可能で、かつBitcoinネイティブであるスケーリングソリューションが急務でした。こうして誕生したのがLightning Networkです。
LNは、オンチェーンで資産をロックした上で、オフチェーンでのコミットメントトランザクションの交換を「取引完了」と見なす仕組みです。これが「即時支払い」と称される所以です。Bitcoinメインチェーンの10分待ちという確認時間と比較すれば、小額支払いのシナリオにおいては、まさに頭痛の種を解決したと言えるでしょう。
しかし、LNの実際の展開と利用過程において、次第に複数の問題が浮上してきました。本稿では以下の4つの核心的課題をまとめます。
1.1 ノード運用の難易度が高い
現行のLNはP2P環境下でのペナルティトランザクションによるゲーム理論モデルに基づいています。相手が不利な旧状態をオンチェーンに提出しないよう監視するため、WatchTowerが常時オンラインである必要があります。つまりユーザー自身がノードを維持しなければなりません。また、ペナルティ用の秘密鍵やコミットメントトランザクションデータもローカルに保存する必要があり、結果としてノード運用のハードルと教育コストが非常に高くなります。
1.2 高いインタラクティブ性
LNにおけるインタラクティブ性とは、取引中にユーザーが行う一連の相互操作を指します。これは署名、コミットメントトランザクションの交換、ペナルティ秘密鍵の管理などを含みます。例えば、オフチェーンの状態更新ごとに、両当事者は同時オンラインで新しいコミットメントトランザクションに署名し交換する必要があります。これはユーザーにとって厳しい要件です。さらに、HTLCやマルチホップによる複雑性は、多人数間のやり取りにおいて克服が難しい課題となっています。
1.3 資本効率が低い
二者的チャネルのLN-Penaltyメカニズムは、まるでユーザー自身が銀行口座を開設し、準備金を自ら用意しなければならないようなものです。典型的な問題は、受取側もチャネルの流動性を確保しなければならず、資本効率が極めて低い点です。また、エッジにあるチャネルの流動性は十分に活用されないケースも多く見られます。
1.4 チャネル管理コストが高い
P2Pチャネルでは、流動性の不均衡が非常に起こりやすく、ユーザーは潜水艦スワップやチャネルスプライシングなどのツールに依存せざるを得ません。しかし、これらの技術は元のFundingTxを調整するために追加のオンチェーン取引を必要とします。すべての調整手段は高コストであり、特に手数料が上昇している時期には無視できない負担となります。
Layer2技術を使って安価な取引をしているはずのユーザーが、突然メインチェーンのオンチェーン手数料を何回も支払う羽目になる状況を想像してください。これはまさに「手数料刺客」とも言える状況であり、メインチェーンの手数料が上がるほどこの矛盾は顕著になります。
こうした問題は、LNの実際の普及状況にも明確に表れています：ユーザーの伸びが鈍化しており、新規ユーザーの多くはカストディ型ソリューションを選んでいます。以下の統計グラフからそれが見て取れます。
新規Lightning Networkユーザーにおけるカストディ型・非カストディ型ウォレット選択数の統計
これは当然のことです。一般ユーザーにとって、自らノードやチャネルを維持することはあまりに困難だからです。
2. 私たちが求めるBitcoinオフチェーンスケーリングネットワークとは？
Lightning Networkホワイトペーパー抜粋
Lightning Networkホワイトペーパーによると、全世界の人が年2回チャネルを開閉すると、最終的にビットコインブロック容量は133MBまで拡大する必要があります。現在のビットコインメインネットはブロックサイズ1MB、SegWitを使用したP2TRアドレスでも4MB程度であり、差は歴然です。さらに、実際には流動性調整のための技術（潜水艦スワップ、チャネルスプライシングなど）も追加のオンチェーン取引を必要とするため、ブロックスペース不足の問題は現実シナリオではさらに深刻です。
つまり、現行のLNは短期的には大規模C向けユーザーのニーズを満たせず、長期的にもビットコインのブロック容量制限によりスケーリングの潜在能力が大きく制約されていることがわかります。
ここに新たな疑問が生まれます：私たちは一体、どのようなBitcoinオフチェーンスケーリングネットワークを必要としているのでしょうか？
2.1 Lightning Networkの現状
LNの現在の限界を理解するには、その設計原理に立ち返る必要があります。
現在のLNモデルは「LN-Penalty」とも呼ばれ、ペナルティトランザクションに基づく二者的チャネルモデルです。その安全性は、ユーザーがローカルに保持する相手を牽制するトランザクションおよびペナルティ秘密鍵、そしてビットコインチェーンを常に監視することに依存しています。これにより、相手の行動を常に監視下に置くことができます。
このような設計では、ユーザーが自らノードを運営することは避けられません。ローカル保管とWatchTower機能は不可欠だからです。先述の通り、何度も強調してきました。
資本効率と通信効率の観点から見ると、現在LNで一般的なのは、LSPがスーパーノードを中核に流動性を提供し、ユーザーがそのスーパーノードとチャネルを結ぶ形です。これは本来のP2P網状モデルからすでに逸脱しており、自然な進化の結果、古典的なハブアンドスポークモデルに戻っています。
以下の図をご覧ください。左が理想のLN、右が現実のLNの姿です。
2.2 C向け理想的オフチェーンスケーリングネットワークの特徴
それでは、C向けユーザーが本当に求めるBitcoinオフチェーンスケーリングネットワークに必要な特性を考えてみましょう：
-
P2Pモデルではなく、ユーザーが自らノードを維持する必要がなく、セキュリティと利便性の両立が可能なこと
-
支払い時に双方が同時オンラインである必要がなく、片方がオフラインでも非同期操作が可能なこと
-
資本効率を高めつつ、非カストディの要件を満たすこと
-
低コストで効率的な流動性管理メカニズムを持ち、ユーザー自身が流動性を管理する必要がないこと
これらの目標に基づき、本稿では読者とともにBitcoinオフチェーンスケーリングネットワークの将来像を探っていきます。
3. BTCネイティブスケーリングの進化の道
まず明確にしておくべきは、現行のLN設計の中心となる「LN-Penalty」メカニズムにおいて、状態更新の基盤は以下の要素にあることです：
-
コミットメントトランザクションの保管と継続的監視
-
多人数協力のマルチホップメカニズム（HTLC/PTLC）
これらは現在のLN設計の基礎であり、直接的にノード設計の複雑さを引き起こしています：
-
複雑な暗号通信インタラクション
-
ローカルでのコミットメントトランザクションとペナルティ秘密鍵の保管
-
チャネル存続中、中断できないWatchTowerの稼働
こうした問題は、「LN-Penalty」に代わるより軽量な状態更新メカニズムの採用を検討させるきっかけとなりました。こうした文脈の中で、BIP118（SIGHASH_ANYPREVOUT）が代替案として注目されています。
3.1 LN-Symmetry：状態更新にバージョン管理を導入
BIP118はSIGHASH_ANYPREVOUT署名方式の導入を提案しています。これはトランザクションの入力が直前の出力を完全に指定する必要がなく、署名を変えずに前回のトランザクションを更新できるようにします。この設計により、「LN-Penalty」よりもノード間の暗号通信の複雑さとストレージ要件が大幅に削減されます。SIGHASH_ANYPREVOUTは論文eltoo: A Simple Layer2 Protocol for Bitcoinに由来し、最近のLN開発議論では、この改良版モデルは「LN-Symmetry」と呼ばれるようになりました。
ただし、LN-Symmetryはローカルでのコミットメントトランザクションの保管負荷を低下させたものの、監視の必要性までは排除していません。Eltooではコミットメントトランザクションや秘密鍵の交換は不要ですが、参加者が古い状態をオンチェーンに提出した場合、他方はリアルタイムで監視し、最新の状態トランザクションを速やかに提出して置き換える必要があります。この監視タスクには依然として従来のWatchTowerが必要です。ただしここでの目的は「罰則」ではなく「状態の置き換え」です。ユーザーは依然として自らノードを維持する必要があります。
さらに、LN-SymmetryでもHTLC/PTLCのような多人数協力メカニズムが必要であり、従来のLNノード設計と同様に、通信負担が重いままです。
つまり、全体的な効果として、LN-Symmetryによる体験改善は限定的であり、私たちが目指すゴールにはまだ遠く及ばないのです。
さらなる改善のために、本稿では次の段階の方向性を示します：Shared UTXOです。
3.2 CoinPool：多人数チャネルのインタラクティブ性と流動性要求の削減
Shared UTXOの概念を最初に提唱した論文はCoinPool: efficient off-chain payment pools for Bitcoinです。その核心的目標は、SIGHASH_ANYPREVOUTのバージョン更新メカニズムをさらに発展させ、多人数間のインタラクション問題を解決することです。
LN-Symmetry設計では、Eltooによる新しい状態更新メカニズムにより、P2Pチャネルの状態管理が確かに簡素化されました。しかし、多人数協力になると、インタラクションの複雑さは依然として残り、特にマルチホップペイメント（HTLC/PTLC）では密接な調整と複数回の暗号通信が必要です。
CoinPoolの革新点は、Shared UTXOモデルを用い、複数の参加者が同じバージョン管理付きUTXO上で協力できることです。これにより、参加者は複雑なHTLC/PTLCメカニズムに頼らず、共通のUTXOの状態を共同でコミット・管理できます。主な利点は以下の通りです：
-
多人数チャネルのインタラクション複雑性を大幅に低減：すべての参加者が同じUTXOを共有するため、バージョン更新に署名することで合意が成立し、複数のオンチェーン取引や複雑なオフチェーンインタラクションが不要になります。これにより多人数チャネルの管理がより効率的になります。
-
オフチェーン更新メカニズムがより直接的になる：この設計では、オフチェーンの状態更新は、複数参加者による特定バージョンのUTXOへの共同署名で行われます。この方法は状態更新のプロセスを簡素化し、参加者間の依存関係と潜在的な衝突ポイントをさらに削減します。
-
独立した流動性要求の排除：Shared UTXOモデルにより、複数の参加者は実質的に同じ流動性プールを共有し、各参加者が個別に十分な流動性を維持する必要がなくなります。多人数協力型CoinPool設計では、流動性要求を大幅に削減または再分配できます。参加者は共有UTXO内の流動性を使って支払いを行い、自らのチャネルに大量の資金をロックする必要がありません。これにより資金利用効率が向上し、個々の参加者の資金負担が軽減されます。
CoinPoolはShared UTXOを通じて、多人数チャネルのインタラクション複雑性を合理的レベルまで低減しながら、システムの安全性と効率性を維持することに成功しました。さらに重要なのは、各参加者の独立した流動性要求への依存を減らし、多人数協力に軽量で柔軟なソリューションを提供した点です。これにより、従来のLNモデルが抱えていた多人数インタラクションと流動性管理の限界を突破しました。
しかし、これほど優れたソリューションがなぜ未だに大規模に採用されていないのでしょうか？その根本的な理由はどこにあるのでしょうか？
3.3 なぜCoinPoolは実際に実装されていないのか？
CoinPoolは多数の利点を持ち、理想的なスケーリングモデルと見なされていますが、必要なソフトフォークアップグレードが多すぎて、私たちの生きている間にビットコインネットワークに実装される可能性は極めて低いです。CoinPoolがソフトフォークアップグレードを必要とする主な点は以下の2つです：
3.3.1 状態更新メカニズムのアップグレード
CoinPoolはEltoo設計に基づいており、状態更新メカニズムとしてソフトフォークによる新しい署名方式SIGHASH_ANYPREVOUT（APO）の導入が必要です。しかし、ビットコインのソフトフォークアップグレードは進行が遅く、CoinPoolに必要な技術は現実に適用することが困難です。
3.3.2 Shared UTXOには契約簡略化操作が必要
前述の通り、Shared UTXOの各状態更新には、そのUTXOの特定バージョンを共有するすべての参加者の署名収集が必要です。このプロセスで一方がオフラインになると、システム全体が停止します。つまり「ライブネス（liveness）」が非常に低いのです。この課題を克服するには、協力がなくても低コストでShared UTXOを更新できるメカニズムが必要です。
CoinPool論文ではOP_MERKLESUBを提案し、Merkle木構造によって特定参加者の状態を検証・更新しようとしました。このアイデアは理論的には可能ですが、他のMerkle木ベースのスマートコントラクトと同様に、実装が複雑で汎用的・再利用可能なコントラクトを作るのが困難です。たとえば**OP_TAPLEAFUPDATEVERIFY(TLUV)**のようなものも同様です。また、非協力的な参加者をShared UTXOから直接除外するOP_EVICTのような機能は単一用途過ぎて、ビットコインネットワークのアップグレードで承認される見込みは薄いです。
こうしたコントラクト提案の中、OP_CheckTemplateVerify（CTV）が注目を集め始めています。Merkle木を直接構築・検証するのではなく、CTVは事前に定義されたトランザクションテンプレートによる支出制限を行います。CTVは実装がシンプルであり、トランザクションのコミットメントチェーンを通じて、オンチェーンのUTXOで一連のオフチェーンUTXOをコミットできます。こうしてオンチェーンでコミットされたオフチェーンUTXOこそがVirtual UTXO（VTXO）の起源です。
こうしたコントラクトの中でも、CTVはシンプルで汎用性が高いことから最も支持されています。CTVの強力な機能はCoinPoolのようなアイデアを実現できるだけでなく、Rollupにも応用可能です。毎回OP_CATでZKP-MerkleStateを検証し、スクリプト内で対応するLayer2状態をコミットしたShared UTXOがあれば、真の意味でのBitcoin ZK-Rollupが構築できます。
以上から、CoinPoolの実装が直面する主要な問題は、軽量な状態更新メカニズム（APO）とShared UTXO操作コードの導入が必要だが、いずれもビットコインのソフトフォークアップグレードを要する点にあります。そのため、CoinPool論文が発表されてから多年経過しても、依然として「紙上の構想」に留まっているのです。
3.4 Bitcoin Clique：オフチェーンでの二重支出防止プリミティブ2-AS
前述のCoinPoolモデルでは、実現にはソフトフォークアップグレードが必要なAPOメカニズムに依存しており、短期間での実現は困難です。もしビットコインのソフトフォークアップグレードに依存しない、新しいオフチェーン二重支出防止プリミティブがあれば、実装の問題は大きく解決されます。
SIGHASH_ANYPREVOUTの本質的役割は、二重支出を防ぐオフチェーン状態更新メカニズムを提供することです。この考え方に基づき、等価な暗号学的プリミティブが見つかれば、オフチェーン状態更新の問題を解決でき、ビットコインのオペコード更新の必要性を回避できます。Bitcoin Cliqueという論文の登場は新たな光をもたらしました。この論文は、2-shot-adaptor-signature（2-AS）という新しい暗号学的プリミティブを導入し、オフチェーンでの二重支出防止に新たなソリューションを提示しています。
2-ASはSchnorrアダプタ署名に基づく暗号学的プリミティブです。2-ASを理解するには、まずSchnorr署名とアダプタ署名の基本を把握する必要があります。
3.4.1 Schnorr署名
Schnorr署名は線形性を持ち、複数の署名を一つにまとめる（集約）ことができます。簡単に言えば、複数の署名$S_1$と$S_2$は加算により$S=S_1+S_2$という一つの署名に集約でき、検証時の公開鍵も$P = P_1 + P_2$のように集約できます。
3.4.2 アダプタ署名
アダプタ署名にはGen、PSign、PVrfy、Adapt、Extractといった基本ステップがあります。2-ASを理解する上で特に重要なのはPSignとExtractです。
本稿では暗号学的詳細よりも用途を中心に解説します。要するに、二人が共同で署名を確定したい場合、相手のアダプタ（通常は公開鍵）を署名の一部として用い、そのアダプタに対応する秘密鍵（シークレット）を持つ者が、PSignによって残りの部分署名を補完（Adapt）できます。これだけならMuSigと似ていませんか？しかしアダプタ署名の特徴はExtractにあります。つまり、完全な署名が公開された後、当初PSignを発行した側は、完全署名・部分署名・アダプタ（公開鍵）から対応するシークレット（秘密鍵）を抽出できます。
3.4.3 二つの融合：2-AS
Schnorr署名とアダプタ署名の特性を理解した上で、その融合である2-ASを見てみましょう。
あるVTXOがあり、オフチェーンで二重支出時に没収（ペナルティ）できるようにしたいと仮定します。次のように設計できます：
-
まず、ペナルティ出力を作成します。これを解除できる公開鍵は「ペナルティ公開鍵」です。ユーザーが二重支出を行った場合、サービスプロバイダーがこれを没収できます。
-
取引相手同士がアダプタ署名でオフチェーン取引を共同確認します。ユーザーが同じ入力を2回使えば、その出力はサービスプロバイダーによって没収されます。
-
ユーザーは状態更新ごとに、ペナルティ出力用の公開鍵を生成する必要があります。このペナルティ公開鍵は、事前に決められた2組の公開鍵をSchnorr署名の加算で構成します。
つまり、各取引前に使用する公開鍵・秘密鍵ペアを決定し、事前にペナルティ出力を生成しておきます。二重支出が発生すれば、サービスプロバイダーは2回のアダプタ署名から、ペナルティ出力の秘密鍵を取得できます。
3.4.4 Bitcoin Cliqueの長所と短所
Bitcoin Cliqueは完璧ではありません。その欠点は、オフチェーン状態更新時に、新しいペナルティ公開鍵を構築するための2-AS鍵を不断に交換する必要がある点です。また、この方式はCoinPool設計に基づき、2-AS鍵の交換と新バージョンUTXOの検証署名を行うため、状態更新時には全員がオンラインである必要があります。つまり通信の複雑さとインタラクティブ性は依然として高いのです。
最も重要な点は、このモデルがStateChainに類似しており、オフチェーンで移転するのはあるUTXOの所有権であるため、2-ASのようなdouble-spend-prevent signatureシステムではオフチェーン支払いでのお釣り処理が不可能になり、応用範囲が非常に限定される点です。
さらに、使いやすいSharedUTXOメカニズムとソフトフォーク不要のオフチェーン二重支出防止プリミティブがあっても、UTXOの新状態更新には全員がオンラインで確認する必要があります。これは状態更新に関与しない人々にもオンラインを求めることになり、不合理です。また、完全に流動性要求を排除することも望ましくありません。流動性の潤滑がない支払い方式ではお釣りが扱えず、退出問題のため、全員の額面が同じでなければなりません。
したがって、現時点では非チャネル型で動的額面対応かつUTXOベースのオフチェーンスケーリングソリューションは存在しません。かつてイーサリアムもこの道で苦悩し、「Plasmaトラップ」と呼ばれました。関連研究は論文『Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma』を参照してください。
問題点と教訓をまとめます：
-
動的額面支払い（お釣り対応）のためには流動性の潤滑が必要：チャネル設計を維持すべきであり、退出問題も回避できます。
-
全参加者の同時オンライン依存を減らす：オフチェーンネットワークの状態更新ごとに全ユーザーがオンラインである必要はありません。Shared UTXOの更新は関係者だけでオンライン協力すればよいのです。
以上の認識に基づき、本稿はさらに最適化されたソリューションを探求していきます。
3.5 チャネルファクトリーと仮想チャネル
これまでの議論で、チャネル設計を維持する必要性と、Shared UTXOがもたらすオフチェーンでの低コストメリットの両方を認識しました。ここで、LN分野で長く議論されてきた「チャネルファクトリー（Channel Factory）」という概念が視野に入ります。
以前触れたように、オンチェーンUTXOによってコミットされたオフチェーンUTXOはVirtual UTXO（VTXO）と呼ばれます。このオフチェーンのVTXOをチャネルのFundingTxとして使うと、「仮想チャネル（Virtual Channel）」という新しい概念が得られます。このShared UTXO内のオフチェーン仮想チャネルはVirtual HTLCで接続されます。すべてがオフチェーンに「仮想化」されます。これは理想的な解決策のように見えます。流動性調整など大部分の機能をオフチェーンで実現でき、LNのスケーリング問題は解決したかに思えます。
しかし、現実はそんなに甘くないのでしょうか？
Shared UTXOの特性を継承しているため、チャネルファクトリーは複数ユーザーの協力が必要です。開設・閉鎖の際に、どれか一人でも協力できない（例：オフライン、無反応）と、ファクトリー全体の機能に影響が出ます。チャネルファクトリーは複数人による状態更新署名を伴うため、一方が同期しない、あるいは悪意のある行動をとると、他のユーザーがチャネルを正常に閉鎖して資金を引き出せなくなる可能性があります。
また、この設計の問題も明らかです。チャネル開閉コストは下げられますが、チャネル間のセキュリティモデルは依然としてコミットメントトランザクションとHTLCに依存しています。そのため、通信とインタラクションの問題は依然として存在し、実装の複雑さは現行のLN-Penaltyよりも高い可能性さえあります。
3.6 ARK JoinPoolと一時的チャネル
チャネルファクトリーの事例から、Shared UTXOに基づくチャネル設計では、従来の「LN-Penalty」チャネル設計を踏襲すべきではないが、以下のチャネルの利点は維持すべきだと結論づけられます：
-
流動性による動的額面対応
-
退出が容易であること
この考えに基づき、JoinPoolを利用した一時的チャネル設計が登場しました。それがARK Protocolです。
3.6.1 JoinPool：関係者だけが更新に参加
前述の通り、CoinPoolは多人数のオフチェーン協力によるスケーリングに大きな可能性を示しました。流動性やマルチホップ、HTLCといった複雑で故障しやすい設計が不要になります。しかし、CoinPoolモデルの最大の問題はユーザーのオンライン要求です。Shared UTXO内の全ユーザーがオフチェーン状態更新時にオンラインでなければならないのです。たとえ一部ユーザーの状態が変わっていなくても、検証と署名のためにオンラインである必要があります。これにより、ユーザーが自らノードを運営しなければならない問題は避けられません。
この難題を解決するために、新たなモデルであるJoinPoolが提案されました。JoinPoolのShared UTXOにおける考え方とは、ユーザーがオフチェーン状態を更新する際に、そのUTXOの新状態を表すShared UTXOに「参加（join）」するというものです。これにより、他人の取引時に無関係なユーザーがオンラインである必要がなくなります。つまり、JoinPool設計では、ユーザーは取引が必要なときだけオンラインになればよいのです。
しかし、誰もが理解している通り、LNノードを常時稼働させる必要があるのは、秘密鍵をオンラインにして署名できるようにするだけでなく、各チャネルメンバーが相手が不利なコミットメントトランザクションをオンチェーンに提出していないかをWatchTowerで継続的に監視する必要があるからです。これが解決すべき第二の問題です。
3.6.2 WatchTowerの責務移転：ユーザーが自らノードを維持する必要なし
従来のLN-Penalty設計では、各ユーザーが自らWatchTowerを構築し、相手が古い状態をオンチェーンに提出した場合に罰則を加える必要があります。この旧モデルでは、すべての取引相手が同等のLNノードであり、毎回異なるノードとチャネルを開いて取引します。しかし、ARKでは、すべてのユーザーはASP（ARK Service Provider）とやり取りし、他のユーザーと直接やり取りしません。
ASPにとって、ユーザーのオフチェーンVTXOが一度取引されると、放棄トランザクションに署名します。なぜなら、理想的にはユーザーのオフチェーンVTXOはオンチェーンに提出されることなく、次々と引用されて次の取引に使われるからです。もしVTXOがオフチェーンで取引された後にオンチェーンに提出された場合、それはユーザーによる二重支出であり、ASPは当初ユーザーがオフチェーンで署名した放棄トランザクションを使って、ユーザーのオンチェーン資金を没収します。ASPは過去に登場したすべてのVTXOを監視し、オフチェーンで既に使われたVTXOがオンチェーンで悪意を持って退出されないようにします。
これにより、WatchTowerの運営責任が一般ユーザーからオペレーターに移りました。LNと比べると、これは巨大な進歩です。ついに、一般ユーザーが自らノードを運営して安全を保つ必要がなくなったのです。
他のユーザーのノード運営を最適化するソリューションのまとめ：
-
Lightning Networkノードのクラウドホスティング
一部のソリューションは、クラウドプラットフォーム上でLNノードを動作させ、ユーザーのノード運営の敷居を下げようとしています。しかし、この方式は本質的にLNのセキュリティ前提に反しています。LN技術では、秘密鍵とコミットメントトランザクションの保管が多くの場面で同様に重要です。そのため、単にリモート秘密鍵を使うだけでは安全性が保証できません。
本質的に、この方式は二者的ゲームを「自分」「取引相手」「クラウドホスティング事業者」の三者的ゲームに変えてしまいます。自分が取引相手と取引した後、状態がオンチェーンに上がっていない間に、クラウドホスティング事業者がクラウド上のノードからコミットメントトランザクションを削除すれば、取引相手は自分にとって有利な状態をオンチェーンに上げることができます。このようなクラウドノードホスティング方式では、クラウドプラットフォームと取引相手が結託して悪事を働くリスクがあります。
-
CRAB および Sleepy CRAB
Aumayrらが提案したCRAB (Channel Resistant Against Bribery)プロトコルは、追加の担保品とマイナーへのインセンティブ付与を組み合わせて、特にユーザーがオフラインの場合の支払いチャネルの安全性を確保します。このメカニズムはサードパーティWatchTowerへの依存を減らします。しかし、この担保品メカニズムは「入金流動性」問題をさらに悪化させます。ユーザーはオフチェーンネットワークに参加する際に、取引目的とは無関係の資金をロックしなければならず、安全性は確保されても、資金の流動性と効率が犠牲になります。また、この方式でもユーザーが自らノードを運営する必要があります。オンライン要件が緩和されるだけです。
3.6.3 一時的チャネル：ユーザーが自らチャネル流動性を管理する必要なし
なぜASPプロバイダーはJoinPoolのチャネルに流動性を注入してくれるのか？それは、ユーザーがARKネットワークのVTXOを使用するには、まず自分のUTXOをオペレーターと共にマルチシグアドレスに預け入れ（FundingTxに類似）、VTXOと引き換えなければならないからです。本質的に、ユーザーのオフチェーン取引は常にオペレーターの資金を使っているのですが、その代わりに、以前自分とオペレーターで共有していたマルチシグの資金を譲渡しているのです。
ARKのチャネルが「一時的チャネル」と呼ばれるのは、単方向性と一回限りの資金注入という2つの特徴を持っているからです。
-
単方向性：単方向チャネル内では、資金は指定された送信者から受信者にのみ移動します。
-
一回限りの資金注入：ARKチャネルは一度だけ資金を注入すればよいです。注入後は、チャネルの流動性を維持する必要はありません。
このような一時的チャネル設計により、資金注入後はチャネルの再バランスなどの調整が不要になります。LNと比べて、ユーザーはチャネル流動性を気にする必要がなく、流動性提供者もチャネル流動性を維持する必要がありません。チャネル内で唯一変化するのはユーザーの退出イベントだけです。
3.6.4 ARKプロトコルのまとめ
以上を総合すると、ARK Protocolの設計はLNと比べてユーザーエクスペリエンスにおいて驚異的な進歩を遂げていることが明確にわかります：
-
ユーザーが自らノードを維持する必要がない
-
ユーザーが自らチャネル流動性を管理する必要がない。入金流動性問題なし
-
非同期インタラクションをサポート。双方が同時オンラインである必要なし
4. Bitcoinネイティブスケーリングのパラダイムシフト
前述の研究を通じて、Shared UTXOに基づく複数のオフチェーンスケーリングソリューションを探索しました。Shared UTXOの設計目的は流動性問題の解決でしたが、プロトコルの進化とともに、当初は期待していなかったが夢見たかった多くの利点が偶然に得られました。
これは、Bitcoinオフチェーンスケーリングが新たな発展方向に入ったことを示しており、従来のLNモデルと比べるとパラダイムシフトと言えます：
-
P2Pモデルから、信頼不要なオペレーターの導入へ
オフチェーンスケーリングネットワークのロジックは、当初のLNの「ユーザー対ユーザー」の二者的ゲームモデルから、徐々に「ユーザー対オペレーター」のゲームモデルへと進化しています。違いは、ユーザーがこの第三者のオペレーターを「信頼する必要がない」点です。
-
ユーザーが自らノード設備を維持して資産を守る必要がない
従来のLN-PenaltyモデルやCRABなどの最新研究は、ユーザーが自ら担保品を提供して資金を守ることに依存しており、チャネル存続期間中はオンラインでノードを運営する必要があります。しかし、将来のソリューションではこれらの操作は不要になります。さらに重要なのは、これらのプロセスが依然として非カストディである点です。ユーザーは常に資産の支配権を保持しています。
-
流動性管理の責務がユーザーからオペレーターへ移転
従来のLN-Penaltyモデルや改良設計では、ユーザーが自らチャネル内の流動性を調整する必要があります。特に流動性が不均衡になると、一定の専門知識が必要で、LSP（流動性サービスプロバイダー）がいないと操作が複雑になります。しかし、流動性管理の責務が第三者オペレーターに移転すれば、ユーザーは流動性管理を心配する必要がなくなります。これによりユーザーエクスペリエンスが大幅に簡素化され、ネットワーク参加の障壁が撤去されます。
-
資本効率と潜在能力が飛躍的に向上
新しいプロトコル設計はすべてP2POOLモデルに向かっており、資本効率は現行のLNと根本的に異なります。LN-Penaltyモデルでは、ユーザーがLNチャネルを開く際に自ら流動性を提供しなければなりませんが、これらのチャネルの流動性は大部分の時間が遊休状態です（支払いは頻繁ではなく、均等に分布もしません）。結果として、ユーザーの資金が有効活用されていません。しかし、新しいプロトコル設計のトレンドでは、流動性がプールに集中して統一管理されるため、将来的なDeFiシーンに無限の可能性を提供します。
このパラダイムシフトは、流動性管理こそがBitcoinネイティブオフチェーンスケーリング進化の本質であり、今後も続く進化の中心的テーマであることを示しています。
今後、技術の進歩と新たなソリューションの登場とともに、Bitcoinのオフチェーンスケーリングの道はさらに明るい発展を見せるでしょう。我々はこの分野での研究をさらに深めていきます。読者の皆さま、今後の成果にご期待ください。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@blapta
