はじめに
今回はAbacus社のDaniel氏によるライトニングネットワーク2.0についての見解を参考に、ライトニングネットワークが抱える問題とその解決策のダイジェストとして書いています。各解決策のコンセプトを簡潔に書いており、技術的な詳細は末尾の参考欄に日本語解説ページのリンクを載せてあるので、詳細をじっくり読みたい方はそちらを参考にしてください。
[toc]
ライトニングの問題を3つのカテゴリへ
ライトニングが抱える問題を大きく3つのカテゴリへ分けると以下のようになります。
- 限られたコイン量しか送受信できない流動性の低さ
- 限られた相手しか送受信できないルーティングの低さ
- ノードを常にオンラインに保つ必要がある難しさ
以下にそれぞれの問題と解決策について紹介していきます。
問題1 チャネル間の流動性
ライトニングは2者間で送受信できるコイン容量を決めます。例えばアリスとボブの間で以下のチャネルがあったとします。この場合、アリスはボブへ2BTC送金可能ですが、それ以上のコインの送金はできません。
- Alice 2–0 Bob
また、アリスがボブへ2BTC送金した場合（以下の図を参照）は、アリスはボブへ送金できなくなり、一度チャネルを閉じて新たらしチャネルを開く必要があります。
- Alice 0–2 Bob
このようにライトニングネットワークはコインの流動性が低いという問題を抱えています。そこで、以下に流動性の低さを解決するいくつかの案を紹介します。
AMP（エーエムピー）
複数のチャネルを一つのチャネルと見たてて相手に送金する仕組みです。例えば、アリスがボブとキャロルに対してそれぞれ0.5BTCのチャネルがあり、またボブ、キャロルはデビッドに対して0.5BTCのチャネルがあるとします。通常だとアリスがデビットへ1BTCを送金することはできません（ボブへもキャロルへも1BTCぶんのチャネルが無いため）。AMPは、アリスが持つ2つのチャネルと、デビッドが持つ2つのチャネルを、まとめて1つのチャネルとみなすことで、1BTCをデビッドへ送金することを可能にします。
Splicing（スプライシング）
ライトニングネットワークを使用するには、あらかじめ相手と資金の容量を決める必要があります。例えば、アリスがボブへ1BTCのチャネルを開設すると、アリスがボブへ最大で1BTCしか送金できません。もしアリスが1BTC送金した場合、彼女はそれ以上何もすることができません（ボブが送り返してくることを除いて）。また、アリスは残っているBTCをオンチェーン決済したい場合もあるでしょう。このような状況で、チャネルを閉鎖することなく、ライトニングの資金をチャージしたり、オンチェーン決済することを可能にするのがスプライシングです。
Submarine Swap（サブマリンスワップ）
オンチェーンとオフチェーンの資金交換の橋渡しをする仕組みです。アリスはオンチェーンのビットコインを持っており、ボブはライトニングネットワーク上（オフチェーン）にビットコインがあるとします。ここでアリスがボブの持つオンチェーンのビットコインアドレスへ送金し、ボブはアリスがもつライトニングネットワークのアドレスへ送金します。ここで暗号トリックを使うことでお互いが不正せずにそれぞれの資金を送金することができます。
Channel Factories（チャネルファクトリー）
ブロックチェーンとライトニングネットワークの間にもう1階層新たに入れようと提案しているのがこのチャネルファクトリーの面白いところです。通常のライトニングのFunding Txは1：1のマルチシグですが、チャネルファクトリーではN：Nのマルチシグを使います。例えば、アリス、ボブ、キャロル、デイビッドの4人がそれぞれ2BTCをデポジットします。
- アリス：2
- ボブ：2
- キャロル：2
- デイビッド：2
次に、アリスとキャロルの間でチャネルを開くことを決めたとします。そこで2人は2：2マルチシグのFunding Txを作り、これをボブ、デイビッドへブロードキャストします（ブロックチェーンにはブロードキャストしません！）。
- アリス：1
- ボブ：2
- キャロル：1
- デイビッド：2
- アリス／キャロル：2（←ここがペイメントチャネルとなる）
この時点でアリスとキャロルは、他の誰（この場合ボブとデイビッド）とも干渉せず2BTC上で送受信することができます（これはライトニングと同じですね）。さらに、ボブとキャロル間で取引をしたい場合、先と同様に2者間で2BTCのFunding Txを作り、皆へブロードキャストします（再度、ブロックチェーンへはブロードキャストしません）。そうすると以下のような状態になります。
- アリス：1
- ボブ：1
- キャロル：０
- デイビッド：2
- アリス／キャロル：2（←ここがペイメントチャネルとなる）
- ボブ／キャロル：2（←ここもペイメントチャネルとなる）
ここでチャネルファクトリの良い所が分かります。それは、キャロルはアリスとボブに対しての2つのチャネルを開設しましたが、ブロックチェーンにブロードキャストしたのは最初の4：4マルチシグの1回だけです。このように一旦、N：Nマルチシグを挟むことで、その上にライトニングネットワークのような2者間ペイメントチャネルを開くことがコストなしで可能になります。
Duplex Micropayment Channels（デュプレックスマイクロペイメント）
DMCはChristian DeckerとRoger Wattenhoferによって提唱されたビットコインのスケーリング案の1つです。ペイメントチャネルで重要なのは、「どうやって最新状態の残高のみをブロックチェーンに書き込むか」です。ライトニングネットワークの答えは、「もし古い状態の残高をブロードキャストしたらペナルティとしてすべての残高を没収する」ことです。それと異なりDMCの答えは、「最新の残高をブロードキャストできる期間を設け、それ以外の古い残高は無効とする」ことです。
アリスとボブはそれぞれ1BTCをデポジットしてチャネルを開設したとします。ライトニングの双方向ペイメントチャネルと違い、DMCは一方向ペイメントチャネルです。2者間で2つのチャネルを持ちイメージです。アリスとボブはそれぞれのチャネルで相手に1BTC分送金が可能です。さらにこのチャネルにはタイムロックが設定してあります（本例は100日）。これは100日後にこのトランザクションは有効となり、ブロックチェーンにブロードキャストすることができます。
1 — 0
Alice Bob Timelock = 100 days
0 — 1
ここで例えば、アリスがボブへ1BTC送金し、ボブがアリスへ0.5BTC送金したとすると以下のような残高になります（アリスは0.5BTC、ボブは1.5BTC）。アリスは0.5BTC持っているのに、アリスー＞ボブのチャネルは０：1でアリスは送金できません。
0 — 1
Alice Bob Timelock = 100 days
0.5 — 0.5
そこで、お互いのチャネル残高を”リセット”して新しいチャネルを作ります。ここで重要なのがTimelockを減らし、先のチャネル状態を無効にすることです。これでアリスはボブへ0.5BTCを送金することが可能になりました。
0.5 — 0
Alice Bob Timelock = 99 days
0 — 1.5
DMCの欠点としては、リセットの回数が有限であることです。本例では100回のリセットが上限となります。リセットが上限に達した場合は、”リフレッシュ”をすることで、Timelockの上限を0日から100日へ戻すことができますが、このリフレッシュをするにはオンチェーンのトランザクションを作る必要があり、これがライトニングネットワークと比べた時の欠点です。しかし、複数人が強調する必要があるチャネルファクトリを考える際には、ペナルティーを課すライトニングより、タイムシーケンスを使って古い取引を無効にするDMCの方が有効だと思われます。
Payment Loops（ペイメントループ）
ボブは以下のようなペイメントチャネルを持っており、チャネルバランスの均衡をとりたいと思ったとします。
Alice 0–2 Bob 0–2 Carol
| |
+ – – – OTHERS – – – +
そこで、ボブはBob – Alice – OTHERS – Carol – Bobという経路を取って自分自身に支払いをすることで、以下のような資金のリバランスをとることができます。これをペイメントループといい、とても簡単に、早くリバランスをすることができます。
Alice 1–1 Bob 1–1 Carol
| |
+ – – – OTHERS – – – +
問題2 安定したルート状態
P2Pネットワークでのルーティングはライトニングネットワークだけの問題ではなく、一般的な問題として考えることができます。そのため、ライトニング専用のルーティングアルゴリズムを特段考える必要はないと予想されています。とは言っても、実際にライトニングのためのアルゴリズム案は発表されており、それがFlareです。
Flare（フレア）
概要としては、自ノードの近隣ノードとビーコンノードと呼ばれるランダムに選ばれたノード群の近隣ノード情報をルーティングテーブルとして持つことで、全ノード情報を保持することなく特定ノードの経路を効率的に発見できるというものです。
問題3 ノードの稼働率
ペイメントシステムは常にインターネットと繋がっている必要があります。特にライトニングネットワークにおいてのインターネット接続状態は、他ノードからの送金の中継や支払い受付、資金の安全性を保つために必要不可欠です。ここでは、「ライトニングではオンチェーンを監視しないと資金が盗まれてしまう」というセキュリティの問題に対する解決策を紹介します。
WatchTower（ウォッチタワー）
自身のライトニングノードまたはウォレットが数日間オフラインになり、チャネルの相手方が古い取引残高をブロックチェーンにブロードキャストし資金をちょろまかそうとする場合に、第3者がそれを監視、対処してれるセキュリティ対策の仕組みです。
Compact Block Filter（コンパクトブロックフィルター）
ライトニングネットワークもビットコインも一番安全な方法は、フルノードを稼動させ常にトランザクションを検証することですが、これは一般ユーザーにとっては負荷が大きすぎます。ビットコインにはホワイトペーパーでも書かれているSPVという仕組みがあり、ハッシュ木のブロックヘッダー（マークルルート）と検証するトランザクションを使うことで、そのブロックに自分の取引データが入っているかを検証する方法があります。しかし、ライトニングの場合はこの逆で、自分の取引データ（コミットメントトランザクション）が入っていないかを検証する必要があります。
そこでCompact Block Filterを使うとこの種の検証が可能になります。このコンセプトは、あるフィルターがされたブロックをノードから受信し、その中に自身に関する取引データが存在しないかを検証します。Compact Block Filterではあるパターンにマッチしているのに、マッチしていないと判断する検知漏れ（False Negative）はありませんが、あるパターンにマッチしていないのに、マッチしていると判断する誤検知（False Positive）の可能性があります。つまり、「このブロックには自分の取引データはない」という判断は確実にできますが、「このブロックには自分のデータが入っていないのに、入っている」という判断をする可能性もあります。ただ、後者の場合は、そのブロックの全データを受信し、検証すれば良いのです。Compact Block Filterを使うことで、ウォレットなど軽量クライアントでもしっかりとデータ検証をすることが可能になり、セキュリティ水準を保つことができるでしょう。
Eltoo（エルトゥー）
ライトニングネットワークは、お互い悪意ある行為（古い残高状態をブロードキャストし資金をちょろまかす）をすると、全額没収されるというペナルティを課すことで悪意ある行為を抑止しています。上記でも書いたように、もし自身が数日間オフラインになっていて、ウォッチタワーも機能していなかった場合、相手方に悪意ある行為を許してしまいます。そこで提案されたのが、古い残高のトランザクションを無効にしブロードキャストできなくするEltooです。
最後に
以上がライトニングネットワークが抱えている問題と解決案でした。ライトニングが今後発展していくためには今回紹介したような問題を解決することはとても重要です。それと同時に、ライトニングを使えるような魅力的なサービスやウォレットも必要です。インターネットがベース技術ならびにアプリケーションの2軸で発展していったように、ライトニングもコア技術ならびにLappsの両方が今後ますます発展していくことに期待しています。
参考
[0] Lightning Network 2.0
[1] AMP
[2] Splicing
[3] Submarine Swap
[4] Channel Factories
[5] Duplex Micropayment Channels
[6] Payment Loops
[7] Flare
[8] WatchTower
[9] Compact Block Filters
[10] Eltoo
Lightning Blog 