
Fiberの包括的解説:CKB上にライトニングネットワークを接続する壮大な実験
TechFlow厳選深潮セレクト

Fiberの包括的解説:CKB上にライトニングネットワークを接続する壮大な実験
これはFiberに関するリサーチレポートの中で最も体系的である可能性がある。
執筆:Faust & Nickqiao、Geek Web3
8月23日、CKB公式がCKB上に構築されたライトニングネットワーク方式——Fiber Network(ファイバーネットワーク)を発表した。このニュースは瞬く間にコミュニティ内で話題となり、CKBの価格は1日で約30%急騰した。反響が大きかった理由は、主にライトニングネットワーク自体が持つ強力なストーリー性に加え、CKBのFiberが従来のライトニングネットワークに対して複数の技術的改善を実施している点にある。
たとえば、FiberはCKBやBTC、ステーブルコインなど複数の資産タイプをネイティブにサポートできる。また、CKBの手数料はBTCよりもはるかに低く、応答速度も速いため、Fiberはユーザーエクスペリエンス(UX)面での飛躍的な進化を実現できる。さらにプライバシーおよびセキュリティ面でも多くの最適化が行われている。
さらに重要なのは、FiberとBTCのライトニングネットワークが相互接続でき、より大きなP2Pネットワークを形成できる点である。過去のオフラインイベントにおいて、CKBチームはFiberとライトニングネットワークに合計10万の物理ノードを設置し、P2P決済ネットワークの完成度と発展を促進すると宣言した。これはまさに前例のない壮大なビジョンといえる。

もしCKBチームのこのビジョンが将来実現すれば、それはライトニングネットワークだけでなく、CKBおよびビットコインエコシステム全体にとって非常に大きな好材料となるだろう。mempoolのデータによると、現在のBTCライトニングネットワークには3億ドル以上の資金が配置されており、ノード数は約1.2万、それらの間には約5万の支払いチャネルが構築されている。

また、spendmybtc.comを見れば、ライトニングネットワークによる支払いを受け入れる店舗がますます増えていることがわかる。BTCの認知度が高まるにつれ、ライトニングネットワークやFiberのようなオンチェーン外決済ソリューションの勢いもますます強くなるだろう。
こうした背景から、『Geek Web3』ではFiberの技術的仕組みについて体系的に解説するため、本レポートを作成した。FiberはCKB上で実装されたライトニングネットワーク型のソリューションであり、基本原理はビットコインのライトニングネットワークと類似しているものの、多くの細部で改善が加えられている。
Fiberの全体アーキテクチャは以下の4つの主要コンポーネントから構成される:支払いチャネル、WatchTower(見張り塔)、マルチホップルーティング、クロスドメイン決済。まず、その中でも最も重要な「支払いチャネル」について詳しく説明する。
ライトニングネットワークとFiberの基盤:支払いチャネル
支払いチャネルの本質は、送金/取引をすべてオフチェーンで処理し、一定期間後に最終状態をオンチェーンに提出して「決済」を行うことにある。取引が即時にオフチェーンで完了するため、BTCなどのメインチェーンのパフォーマンス制限から解放されることができる。
仮にAliceとBobが共同でチャネルを開設し、まずオンチェーンでマルチシグアカウントを作成して資金を入金するとする。例えばAliceとBobがそれぞれ100単位を入金し、オフチェーンチャネル内での初期残高とする。その後、双方はチャネル内で複数回の送金を行い、チャネル終了時に最終的な残高をオンチェーンに同期させ、マルチシグアカウントを通じて両者に支払いを行う(=「決済」)。

具体例として、初期状態でそれぞれ100単位ずつ保有していたのが、AliceがBobに50単位送金し、さらに10単位送金、その後BobがAliceに30単位返金した場合、最終的な残高はAlice:70、Bob:130となる。二人の合計残高は変わらないことに注意しよう。図中の算盤の珠が往復する例がこれをよく示している。
もしいずれか一方がチャネルを終了すれば、現在の残高(Alice:70、Bob:130)をオンチェーンに反映させ、マルチシグアカウント内の200単位をそれぞれの残高に応じて分配し、決済を完了する。一見シンプルなプロセスに見えるが、実際には多くの複雑なケースを考慮する必要がある。
まず、相手がいつチャネルを終了するかは事前にわからない。前述の例では、Bobは2回目の送金後に終了することも、1回目後に終了することも可能であり、支払いチャネルは参加者の自由な終了を許容する。この仕組みを実現するには、いつ誰かが終了してもよい前提で設計されねばならず、つまり任意の時点でいずれか一方が最新の残高をオンチェーンに提出して決済できるようにしなければならない。
そこで登場するのが「コミットメントトランザクション(Commitment Transaction)」である。コミットメントトランザクションとは、チャネル内の両者の最新残高を宣言するものであり、各送金ごとに新しいコミットメントトランザクションが生成される。チャネルを終了したい場合は、最新のコミットメントトランザクションをオンチェーンに提出することで、自分の受け取るべき金額をマルチシグアカウントから引き出すことができる。

ここで重要なポイントを整理しておく:コミットメントトランザクションはチャネル内の残高をオンチェーンで決済するために使用され、どちらの当事者も常に最新のコミットメントトランザクションをオンチェーンに提出してチャネルを終了できる。
しかし、ここには重大な悪用リスクがある:Bobが古い(無効な)残高とコミットメントトランザクションをオンチェーンに提出する可能性だ。例えば、図中のCommit Tx3生成後、Bobの残高は130だが、利益を得るために古いCommit Tx2を提出し、自身の残高を160と偽る。これは典型的な「二重支払い(ダブルスペンディング)」攻撃である。
このような二重支払いを防ぐためには、適切なペナルティメカニズムが必要であり、その設計こそが1対1の支払いチャネルの核となる部分である。チャネル設計では、もしいずれかの当事者が無効な状態またはコミットメントトランザクションをオンチェーンに提出した場合、成功するどころか、相手にすべての資金を奪われる結果となる。
この仕組みには「非対称コミットメントトランザクション」と「取り消し鍵(Revocation Key)」という2つの重要な概念が関与する。まず、「非対称コミットメントトランザクション」について説明しよう。前述のCommit Tx3を例にとると、下図がコミットメントトランザクションのイメージである:

このコミットメントトランザクションはBobが作成し、Aliceに送信して処理させるものである。図の通り、これはマルチシグアカウント内の70単位をAliceに、130単位をBobに送るというBTC送金トランザクションだが、資金のアンロック条件が「非対称」になっており、Alice側の制約が厳しく、Bobに有利になっている。
AliceがBobから受け取ったコミットメントトランザクションに対して自分の署名を追加すれば、2/2マルチシグ要件を満たし、自らこの「コミットメントトランザクション」をオンチェーンに提出してチャネルを終了できる。そうしない限り、チャネル内で継続して取引を続けることも可能だ。
ここで注意すべきは、このコミットメントトランザクションはBobが主体的に作成したものであり、条件はAliceにとって不利であるため、Aliceはそれを受諾または拒否するしかない。そのため、Aliceにもある程度のコントロール権を与える仕組みが必要になる。支払いチャネルの設計では、「自分にとって不利な」コミットメントトランザクションをオンチェーンに提出できるのはAlice本人だけである。なぜなら、コミットメントトランザクションは2/2マルチシグが必要で、Bobがローカルで作成したトランザクションには自分の署名しかなく、Aliceの署名がないためだ。
そして、Aliceは「Bobの署名のみを受け取り、自分の署名を彼に渡さない」ことができる。これは、他人と共同署名が必要な不利な契約書において、相手が先に署名してあなたに渡したとしても、あなたが署名を返さなければ契約は成立しないのと同じである。あなたが契約を有効化したい場合は署名して公開すればよいし、そうでなければ署名せず、あるいは公開しない。前述の例では、AliceがBobを抑制できる仕組みになっていることがわかる。

次に核心部分に入る:チャネル内で送金が発生するたびに、一対のコミットメントトランザクションが生成され、互いに鏡像のように対称的な2つのバージョンが存在する。以下のような形である。AliceとBobはそれぞれ自分に有利なコミットメントトランザクションを作成し、残高や終了時の受け取り額を宣言した上で、相手にその内容を送って処理させる。
興味深いのは、この2つのコミットメントトランザクションが宣言する「終了時の受け取り額」は同じだが、引き出し条件が異なる点にある。これが前述の「非対称コミットメントトランザクション」の由来である。

前述の通り、各コミットメントトランザクションは2/2マルチシグで初めて有効になる。Bobがローカルで作成した自分に有利なコミットメントトランザクションは2/2マルチシグを満たしておらず、2/2マルチシグを満たすトランザクションはAliceの手元にある。そのため、Bobはそれを提出できない。提出できるのはAliceだけである。これにより均衡が保たれる。逆の場合も同様である。
このようにして、AliceとBobは自分にとって不利なコミットメントトランザクションしか主動的に提出できない。どちらか一方がコミットメントトランザクションをオンチェーンに提出して有効化すれば、チャネルは閉鎖される。では、冒頭で述べた「二重支払い」のケースに戻って、もし誰かが無効なコミットメントトランザクションをオンチェーンに提出したらどうなるだろうか?
ここで「取り消し鍵(Revocation Key)」の出番である。もしBobが無効なコミットメントトランザクションをオンチェーンに提出した場合、Aliceは取り消し鍵を使ってBobの受け取り分を差し押さえられる。
下図を見てみよう。最新のコミットメントトランザクションがCommit Tx3、Commit Tx2が無効であるとする。もしBobが無効なTx2をオンチェーンに提出した場合、AliceはTx2の取り消し鍵を利用してBobの資金を引き出すことができる(ただし、時間ロックの範囲内で行動する必要がある)。

一方、最新のTx3については、Aliceはその取り消し鍵を持っていない。Tx4が出現して初めて、AliceはTx3の取り消し鍵を取得できる。これは公開鍵暗号とUTXOの特性によって決まっており、詳細な実装原理については紙面の都合上割愛する。
結論として覚えておこう:Bobが無効なコミットメントトランザクションをオンチェーンに提出すれば、Aliceは取り消し鍵を使ってBobの資金を奪える。逆にAliceが悪意を持てば、Bobも同様に報復できる。このようにして、1対1の支払いチャネルは二重支払いを効果的に防止でき、参加者が合理的であれば、誰も悪用を試みることはない。
支払いチャネルに関して、CKB上のFiberはビットコインのライトニングネットワークに比べ大幅な最適化を実現している。CKB、BTC、RGB++ステーブルコインなど多種の資産をネイティブにサポートできる点が挙げられる。一方、ライトニングネットワークはビットコインのみをネイティブにサポートしており、Taproot Assets導入後も非BTC資産はネイティブにサポートされず、ステーブルコインは間接的にしかサポートできない。


画像出典:Dapangdun
さらに、Fiberが依存するレイヤー1ブロックチェーンはCKBであるため、チャネルの開設・終了にかかる手数料は非常に低く、BTCライトニングネットワークのようにユーザーの手数料を大きく削ることは起こらない。これはUX面での顕著な優位性である。
24時間体制の警備員:WatchTower(見張り塔)
前述の取り消し鍵には問題がある:チャネル参加者は常に相手の動きを監視し、相手がこっそり無効なコミットメントトランザクションをオンチェーンに提出しないようにしなければならない。しかし、誰もが24時間オンラインでいることは不可能である。もしオフライン中に相手が悪意を働いたらどうなるのか?
この課題に対し、Fiberとビットコインのライトニングネットワークには、ユーザーの代わりに24時間体制でオンチェーン活動を監視するWatchTower(見張り塔)という設計がある。チャネル内で誰かが無効なコミットメントトランザクションを提出した場合、WatchTowerが迅速に対処し、チャネルと資金の安全性を確保する。
具体的には、各無効なコミットメントトランザクションについて、AliceまたはBobは事前に対応するペナルティトランザクションを構築し(取り消し鍵を使って無効なコミットメントトランザクションを処理し、受益者を自分自身に設定)、そのペナルティトランザクションのプレーンテキストをWatchTowerに送信する。一旦WatchTowerが誰かが無効なコミットメントトランザクションをオンチェーンに提出したことを検知すれば、直ちにペナルティトランザクションもオンチェーンに提出し、適切に罰則を適用する。

Fiberはチャネル参加者のプライバシー保護のため、ユーザーがWatchTowerに送るのは「無効なコミットメントトランザクションのハッシュ+ペナルティトランザクションのプレーンテキスト」のみである。これにより、WatchTowerは最初はコミットメントトランザクションの中身を知らず、ハッシュ値しか知らない。無効なコミットメントトランザクションが実際にオンチェーンに提出されるまで、WatchTowerは中身を見ることができず、その後に初めて中身を確認し、続けてペナルティトランザクションを提出する。この仕組みにより、悪意ある行為が実際に発生しない限り、WatchTowerはチャネル参加者の取引履歴を知ることはない(仮に知ったとしても、1回分の取引しか見えない)。
ここで、Fiberがビットコインのライトニングネットワークに対して行った改善点に触れておく。上述の取り消し鍵に基づくペナルティメカニズムは「LN-Penalty」と呼ばれるが、ビットコインのライトニングネットワークにおけるLN-Penaltyには明らかな欠点がある:WatchTowerはすべての無効なコミットメントトランザクションのハッシュと対応する取り消し鍵を保存しなければならず、大きなストレージ負荷を生む。
2018年、ビットコインコミュニティはこの問題を解決する「eltoo」という提案を行ったが、SIGHASH_ANYPREVOUTオペコードのサポートを目的としたハードフォークが必要であった。そのアイデアは、無効なコミットメントトランザクションがオンチェーンに提出された場合、最新のコミットメントトランザクションが自動的にペナルティを科すというもので、ユーザーは最新のコミットメントトランザクションのみを保持すればよい。しかし、SIGHASH_ANYPREVOUTオペコードは未だにアクティベートされておらず、この案は実現していない。
一方、FiberはDaricプロトコルを実装し、取り消し鍵の設計を変更することで、同一の取り消し鍵を複数の無効なコミットメントトランザクションに適用できるようにした。これにより、WatchTowerおよびユーザークライアントのストレージ負荷を大幅に削減できる。
ネットワークの交通網:マルチホップルーティングとHTLC/PTLC
ここまで説明した支払いチャネルは1対1の取引に限定されるが、ライトニングネットワークはマルチホップ決済をサポートしており、中間ノードを介して直接チャネルを結んでいない二者間でも送金が可能になる。例えば、AliceとKenにチャネルがなくても、Ken-Bob間、Bob-Alice間にチャネルがあれば、Bobを中間者としてAliceとKenの間で送金が行える。このように、「マルチホップルーティング」とは複数の中間者を経由して送金経路を構築することを指す。
マルチホップルーティングはネットワークの柔軟性とカバレッジを高める。ただし、送信者はすべての公開ノードおよびチャネルの状態を把握する必要がある。Fiberでは、すべての公開チャネルおよびネットワーク構造が完全に公開されており、どのノードも他のノードが持つネットワーク情報を知ることができる。ライトニングネットワークのネットワーク状態は常に変化するため、FiberではDijkstraの最短経路アルゴリズムを用いて最短ルートを探索し、中間者数を最小限に抑えながら両者間の送金経路を構築する。

ただし、中間ノードの信用問題を解決する必要がある:中間者が誠実かどうかをどう保証するか。前述の例で、AliceとKenの間に中間者Bobがいるとき、AliceがKenに100単位送金しようとしているが、Bobがそのお金を横取りする可能性がある。これを防ぐ仕組みとして、HTLCおよびPTLCが導入されている。
仮にAliceがDanielに100単位を送金したいが、両者の間にはチャネルがないとする。AliceはBobとCarolという2人の仲介者を経由してDanielに送金できることを発見した。この際、HTLCを支払いチャネルとして利用する。まずAliceがDanielにリクエストを送り、DanielはAliceにハッシュrを送るが、Aliceはrに対応する平文Rを知らない。

その後、AliceはBobとのチャネル内でHTLCを用いて支払い条項を設定する:AliceはBobに102単位を支払うが、Bobは30分以内に秘密鍵Rを提示しなければならず、提示できなければAliceは資金を撤回できる。同様に、BobもCarolに対してHTLCを設定:BobはCarolに101単位を支払い、Carolは25分以内にRを提示しなければならず、できなければBobが資金を撤回できる。
Carolも同様に、Danielとのチャネル内でHTLCを設定:Carolは100単位を支払うが、Danielは20分以内にRの平文を提示しなければならず、できなければCarolが資金を回収できる。
Danielは、Carolが要求する鍵Rが実はAliceが求めているものだと理解する。なぜなら、Rの内容に関心を持つのはAlice以外にいないからである。そこでDanielは協力し、CarolにRを伝え、100単位を受け取る。これにより、Aliceの目標(Danielに100単位を送る)は達成される。
その後の流れも容易に想像できる:CarolがRをBobに伝え、101単位を受け取る。BobがRをAliceに伝え、102単位を受け取る。各者の損得を観察すると、Aliceは102単位損し、BobとCarolはそれぞれ1単位の純益を得ており、Danielは100単位を得た。ここでBobとCarolが得た1単位ずつが、Aliceから徴収された手数料である。

仮に上記の送金経路で誰かが止まった場合(例えばCarolがRを下流のBobに伝えなかった場合)、Bobに損失は発生しない:時間が過ぎれば、BobはHTLCを撤回できる。Aliceについても同様である。
しかし、ライトニングネットワークにも問題がある:経路が長すぎると不具合が起きやすい。中間者が多すぎると、支払いの信頼性が低下する。ある中間者がオフラインだったり、特定のHTLCを構築するのに十分な残高を持っていなかったり(前述の例では各中間者は少なくとも100以上の残高が必要)すると、送金経路全体が失敗する可能性がある。したがって、中間ノードが増えるたびにエラーの可能性が高まる。
さらに、HTLCはプライバシー漏洩のリスクがある。「オニオンルーティング」によりある程度のプライバシー保護は可能であり、各ホップのルーティング情報を暗号化することで、発信者Alice以外は隣接する前後の相手しか知らず、完全な経路は不明となる。しかし、実際にはHTLCの関連性が推測されやすい。神の視点で次の経路を見てみよう。

BobとDanielが同一実体が管理する2つのノードだと仮定し、毎日多くのHTLCを受け取っているとする。彼らは、AliceとCarolがHTLCを送るたびに、要求される秘密鍵が常に一致しており、Danielの下流のEveが常に鍵Rの内容を知っていることに気づく。そのため、DanielとBobは、AliceとEveの間に支払い経路が存在すると推測できる。なぜなら、常に同じ鍵に関連しているからである。これにより、AliceとEveの関係を推定し、監視をかけることが可能になる。
この問題に対し、FiberはHTLCをベースにプライバシーを改良したPTLCを採用している。PTLCでは、経路内の各ステップで異なる鍵が使用されるため、観測者が要求される鍵だけを見て関連性を判断することは困難になる。PTLCとオニオンルーティングを組み合わせることで、Fiberはプライバシー保護型支払いの理想形となる。
さらに、従来のライトニングネットワークには「代替トランザクション循環攻撃(replacement cycling attack)」という脆弱性があり、中間者の資産が盗まれる可能性がある。この発見により、開発者のAntoine Riardですらライトニングネットワークの開発から離れたほどである。現時点でもビットコインのライトニングネットワークには根本的な対策がなく、大きな課題となっている。
これに対してCKBチームは、トランザクションプールレベルでの改良により、Fiberはこの攻撃を回避できるようにしている。代替トランザクション循環攻撃およびその解決策は非常に複雑であるため、本稿ではこれ以上詳述しない。興味のある読者はBTCStudyの関連記事やCKB公式資料を参照されたい。

総じて、プライバシーやセキュリティの観点からも、Fiberは従来のライトニングネットワークに対して大幅な改善を実現している。
Fiberとビットコインライトニングネットワーク間のクロスドメインアトミックペイメント
HTLCおよびPTLCを利用することで、Fiberはビットコインのライトニングネットワークとクロスドメイン決済を実現でき、かつ「クロスドメイン操作のアトミック性」を保証できる。つまり、関連するすべてのステップが成功するか、すべて失敗するかのいずれかであり、部分的成功・部分的失敗は発生しない。
クロスドメインのアトミック性が確保されれば、クロスドメインによる資産損失のリスクがなくなるため、Fiberとビットコインのライトニングネットワークを相互接続できる。例えば、Fiberとライトニングネットワークが混在するネットワーク内で支払い経路を構築し、Fiber内から直接BTCライトニングネットワークのユーザーに送金できる(受取人はBTCに限る)。また、Fiber内でCKBやRGB++資産を使って、BTCライトニングネットワーク上で等価のビットコインと交換することも可能である。
簡単な原理を説明しよう。AliceがFiberネットワーク内でノードを運営し、Bobがビットコインのライトニングネットワーク内でノードを運営しているとする。AliceがBobに資金を送りたい場合、中継業者Ingridを通じてこの送金を実現できる。IngridはFiberおよびBTCライトニングネットワークの両方でノードを運営し、送金経路の中間者として機能する。

Bobが1BTCを受け取りたい場合、AliceはIngridと為替レートを調整し、1CKBで1BTCと交換するとする。AliceはFiber内でIngridに1.1CKBを送金し、IngridはBTCライトニングネットワーク内でBobに1BTCを送金し、0.1CKBを手数料として保持する。
具体的な操作方法としては、AliceとBobがIngridを介して支払い経路(Alice→Ingrid→Bob)を構築し、HTLCを使用する。この点については前述と同様の理屈である。Bobが資金を受け取るには、Ingridに秘密鍵Rの内容を伝える必要がある。IngridがRを取得すれば、AliceがHTLCにロックした資金を解放できる。
注意すべきは、BTCライトニングネットワークとFiber内で発生するこれら2つのクロスドメイン操作はアトミックであること。つまり、2つのHTLCが同時に解放されるか、どちらも解放されないかのいずれかであり、Aliceが支払ったのにBobが受け取れないといった事態は発生しない。
(実際、中間者IngridはRを知った後でAliceのHTLCを解放しない選択もできるが、その場合の損失はIngrid自身に及ぶため、ユーザーAliceにとっては安全である。Fiberの設計はユーザーにとって安全である。)
この方式により、第三者を信頼することなく、異なるP2Pネットワーク間での送金がほぼ一切の改修なしに実現できる。
FiberがBTCライトニングネットワークに対して持つその他の利点
前述の通り、FiberはCKBネイティブ資産およびRGB++資産(特にステーブルコイン)をサポートしており、即時決済シーンでの潜在能力が非常に高く、日常的な小額決済ニーズに適している。
さらに、ビットコインのライトニングネットワークには「流動性管理」という主要な課題がある。前述の通り、支払いチャネル内の総残高は固定されている。片方の残高が尽きると、相手に送金できなくなる。この場合、相手からまず送金を受けたり、新たな資金を注入したり、新しいチャネルを開設する必要がある。

さらに、複雑なマルチホップネットワークでは、中間ノードの残高不足により送金が失敗する可能性がある。これがライトニングネットワークの痛点の一つであり、対策としては効率的な流動性注入手段を提供し、ほとんどのノードが随時資金を注入できるようにすることである。
しかし、BTCライトニングネットワークでは、流動性の注入、チャネルの開設・終了はすべてBTCチェーン上で行われるため、BTCネットワークの手数料が極めて高い場合、支払いチャネルのUXに悪影響を及ぼす。例えば、容量100ドルのチャネルを開設するのに10ドルの手数料がかかった場合、初期段階で資金の10%を失うことになり、大多数のユーザーにとって受け入れがたい。流動性注入についても同様である。
これに対してFiberは顕著な優位性を持つ。まず、CKBのTPSはBTCよりもはるかに高く、手数料はセント単位にまで下げられる。さらに、流動性不足による送金不能の問題に対応するため、FiberはMercury Layerと提携し、新たなソリューションを導入予定であり、流動性注入をオンチェーン操作から解放し、UXとコストの問題を解決する。

以上により、Fiberの全体技術アーキテクチャを体系的に整理した。Fiberとビットコインのライトニングネットワークの大まかな比較は上図の通りである。Fiberおよびライトニングネットワーク自体が非常に多くの知識を含んでおり、単一の記事ではすべてを網羅することは難しい。今後、我々はライトニングネットワークおよびFiberに関するシリーズ記事を展開していく予定である。ぜひご期待いただきたい。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














