従来では、ビットコインネットワークにおいてビットコインの送金を行うには、送金毎にトランザクションを作り、ノードが検証し、ブロックに追加され、そのブロックがブロックチェーンに追加され承認されるという一連の流れが必要でした。
しかし、ライトニングネットワークが実装されると、ピア同士でチャネルを作ることが可能になり、そのチャネル内での送金はオフチェーンで行われます。つまり、上記のようにトランザクションをブロックチェーンに書き込む必要はないのです。
これにより、即時性のある送金、手数料の大幅な減少、スケーラビリティ問題への対策などさまざまな恩恵を享受することが可能になります。
そこで当記事では、ライトニングネットワーク全体を俯瞰的に見た場合の仕組み、そしてライトニングネットワークのチャネル内部の仕組み、そしてライトニングネットワークのメリットと問題点についてお伝えしていきます。
ライトニングネットワークの仕組み
上記で「オフチェーン」という言葉が出てきましたが、これは「オンチェーン」の対義語です。つまり、ブロックチェーンに記録されないトランザクションのことを言います。それでは、オフチェーンでのトランザクションはどこに記録されているのでしょうか。
これは、ネットワークにサーバーを立てて保存するわけでも、ノードのローカル環境に保存するわけでもなく、ライトニングネットワークにおいてはチャネル内の「状態」という形で保存されます。
ライトニングネットワークでは、まず参加するピアの間にチャネルを開きます。そのチャネルを通してバリューをやり取りするのです。バリューとは、ハッシュ関数に入れるための値です。このバリューを1回送るごとにチャネル内の状態が変化します。バリューを1回送ると、前の状態は破棄され、それに上書きする形で最新状態が出来上がるのです。
そして、このチャネルを閉じると最新状態のみがブロックチェーンに記録されるので、ライトニングネットワークはオフチェーン処理言われます。
つまり、ライトニングネットワークはチャネルの外側から見れば、バリューをやり取りするだけでビットコインがやり取りでき、最終的な状態をオンチェーン処理していることになります。
このようにライトニングネットワークは非常にシンプルに見えますが、チャネル内部ではHTLCというタイムロックを使った条件分岐によりトラストレスなやり取りが実現しています。そこで、チャネル内部の仕組みを見ていきましょう。
前提：タイムロック(Time-Locks)
ライトニングネットワークではタイムロックが非常に重要な役割を果たします。タイムロックとは、ある条件が満たされるまでトランザクションがブロードキャストされない、つまりビットコインを送ることができないことです。
タイムロックは、この条件によってCLTV(Check Lock Time Verify)とCSV(Check Sequence Verify)の２種類に分けることができます。CLTVは絶対的な時間やブロック高などの条件、一方、CSVは相対的な条件を指定することができます。
例えば、CLTVは「2018年1月10日14時までトランザクションをロックする」、CSVの場合は「今から２週間後までトランザクションをロックする」といった条件指定をすることができます。
また、ビットコインにおけるトランザクション、マルチシグ、ハッシュ関数についての基礎的な知識も必要になるのでこちらの記事も併せてご覧ください。
ビットコインおけるトランザクションスクリプトの仕組みとその種類
２者間での双方向ペイメントチャネル
ビットコインネットワーク全体で行われるライトニングネットワークについて紹介する前に、２者間のみでのペイメントチャネルについて考えていきます。
このペイメントチャネルでは、アリスとボブの間でビットコインのやり取りが行われる状況を考えます。ボブがアリスに1BTCを送り、その後やっぱりボブが返金して欲しいというシンプルな状況を考えていきましょう。
ボブ→アリス：1BTC
まず、アリスとボブがペイメントチャネルを開くためにそれぞれ5BTCずつ2-of-2マルチシグアドレスAに送金（デポジット）します。
これをOpening transactionと言い、ペイメントチャネルの最初のトランザクションになるのでブロードキャストされブロックに記録されます。また、このマルチシグアドレスAに預けられた10BTCを引き出すにはアリスとボブが持っている両方の秘密鍵が必要です。
続いて、ボブはマルチシグアドレスAから２つ目のマルチシグアドレスBへ6BTC、ボブ自身のアドレスへ4BTC送るトランザクションを作ります。
このトランザクションはCommitment transaction（コミットメントトランザクション）と言い、ネットワークにブロードキャストされないのでブロックに書き込まれることはありません。（ボブはアリスだけに対してこのトランザクションを送ります。）つまりオフチェーンでのトランザクションになるのです。
マルチシグアドレスBの挙動は少し変わっていて、前述したCSVロックがされているので、例えば以下の２つの条件でのみアンロックすることができます。
- 100ブロック後にアリスはアンロックできる（アリスは6BTCを手に入れれる）
- アリスが持っている秘密鍵を手に入れることでボブはアンロックできる（ボブは6BTCを手に入れる）
当然、この段階でボブはアリスの秘密鍵を持っていないのでマルチシグアドレスBをアンロックすることができません。
この間にアリスは正反対のコミットメントトランザクションを作ります。つまり、マルチシグアドレスAからマルチシグアドレスCへ4BTC、アリス自身へ6BTC送るトランザクションを作ります。このマルチシグアドレスCも当然CSVロックされているのでボブがすぐにアンロックして4BTCを手に入れることはできません。
今の状況を整理すると以下の図のようになります。
アリスとボブがマルチシグアドレスAに5BTCずつデポジットしたOpening transactionのみがブロックに記録されていて、それ以降のコミットメントトランザクションはブロードキャストしていないので、ブロックに記録されていないことに注意してください。
もちろん両者はこの時点でコミットメントトランザクションに署名しブロードキャストさせることも可能です。アリスが署名した場合は、ボブはすぐに4BTCを手に入れることができますが、アリスが6BTCを手に入れるためにはその時点からブロックチェーンにブロックが100個追加されるまで待たなければなりません。
反対に、ボブが署名した場合はアリスはすぐに6BTCを手に入れることができますが、ボブが4BTCを手に入れるためには100個ブロックが追加されるまで待つ必要があります。
アリス→ボブ：1BTC
ボブはアリスに送金した1BTCを返してほしくなりました。そこで開いているペイメントチャネルの更新を行います。
そのためにまず、両者は上記のコミットメントトランザクションを互いに5BTCが得られるように再度行います。このとき使用する秘密鍵は前のコミットメントトランザクションで使用した秘密鍵とは異なるものを使う必要があります。
続いて、以前のコミットメントトランザクションで使った秘密鍵を互いに渡します。
この後、アリスが以前のコミットメントトランザクションをブロードキャストさせようとしたらどうなるでしょうか。この場合、ボブはアリスの秘密鍵を知っているので10BTC全てを手に入れることができてしまいます。
なぜなら、CSVロックされているのでアリスは自身のアドレスに6BTC送るために100ブロック追加されるまで待たなくてはならないからです。その間に、ボブはアリスの秘密鍵を使って6BTCを手に入れることができてしまいます。
逆に、ボブが以前のコミットメントトランザクションをブロードキャストさせようとした場合も、CSVロックが解除される時間を利用してアリスが10BTCを得ることができてしまうのです。
なので、このような状況だと両者は以前のコミットメントトランザクションはブロードキャストすることができず、最新のコミットメントトランザクションのみがブロードキャストされることになります。
HTLCを使った３者間でのペイメントチャネル
「HTLC」という特別なタイムロックを理解するために、上記の２社間でのペイメントチャネルを応用した３者間でのペイメントチャネルを見ていきましょう。HTLCでは、CLTVのアンロックのために署名とハッシュ元のバリューが必要になります。
ここでは、ボブを介してアリスがキャロルに10BTC送るケースを考えていきましょう。
- キャロルはある値（バリュー）を作り、それをハッシュ関数に通すことでハッシュ値を得ます。
- ハッシュ値をアリスに渡します。（ハッシュ関数は不可逆なのでハッシュ値からバリューを得ることができません。なのでアリスはバリューは分かりません。）
- アリスはボブにハッシュ値を渡します。
- キャロルはボブにバリューを渡します。
- その代わりにボブはキャロルに10BTCを渡します。
- ボブはキャロルからもらったバリューをアリスに送ります
- アリスはバリューとハッシュ値を照合し一致していたら10BTCをボブに送ります。（そのバリューが本当にキャロルによって作られたか確認）
大筋はこのようにしてまずボブがキャロルに10BTCを送り、その後アリスがボブに10BTC送ることで結果的にアリスがキャロルに10BTCを送っていることになります。
しかし、上記の流れではボブはアリスはキャロルを信用しなくてはいけなくトラストレスなP2Pネットワークにはなりません。なぜなら、ボブがキャロルに10BTCを送ったら本当にキャロルはバリューを送ってくれるか分からないですし、ボブがアリスにバリューを送ったら本当にアリスは10BTCを送ってくれるか分からないからです。
そこでHTLCを使います。ボブがアリスにバリューを渡し、アリスがボブに10BTCを渡す部分を見ていきましょう。
アリスはボブに直接10BTCを送るのではなく、HTLCでロックされたマルチシグアドレスに送ります。このマルチシグは以下の条件でアンロックすることができます。
- ボブの署名とバリュー
- アリスの署名（ただしCLTVでロック）
バリューを持っているボブであればすぐに10BTCを受け取ることができますが、アリスの場合はCLTVでタイムロックされているので例えば２週間後にしか受け取れないということになります。なので、もしアリスが10BTCを先に受け取ろうとしても２週間待たなくてはならないので、その間にボブは署名とバリューを使って10BTCを引き出すことができます。
また、もしボブがキャロルからバリューをもらっていない場合は、ボブは10BTCを引き出すことができないので２週間後、アリスに10BTCは返金されることになるのです。
このHTLCをキャロルとボブ間での取引にも使用することでボブはトラストレスなネットワークを作ることが可能になります。
ただし、ボブはアリスからバリューを要求される前に、キャロルからバリューをもらっておかなければならないことに注意しましょう。もし、キャロルからバリューをもらう前にアリスからバリューを要求されたら、ボブはもっていないバリューを要求されている状態になってしまいます。
なので、ボブとキャロル間のHTLCはアリスとボブ間のHTLCより前に期限切れになるようにセットしておかなければなりません。例えば、ボブとキャロル間のHTLCは10日間、アリスとボブ間のHTLCは14日間といった感じです。このようにすることで、ボブがキャロルからバリューをもらう前にアリスとのHTLCが期限切れになってしまうのを防ぐことができます。
ちなみにこれがHTLCが相対的な条件であるCSVではなく、絶対的に時間などを指定することができるCLTVを使っている理由です。
ライトニングネットワーク
ここまで見てきた、アリスとボブのペイメントチャネル、そしてアリスとボブとキャロルでのペイメントチャネルを応用してライトニングネットワークのチャネル内部を理解することができます。
まずは、最初と同じように互いに5BTCをマルチシグにデポジットしOpening transactionを作った状況を考えます。
上記と同じように、このマルチシグからのトランザクションアウトプットはアリスまたはボブとタイムロックされたマルチシグになります。
しかし、ここではひとつ新しいアウトプットを追加します。このアウトプットはHTLCであり例えば、アリス：ボブ（マルチシグ）：HTLC＝4：5：1のようにアウトプットをセットします。
このHTLCをアンロックする方法は以下の３つです。
- ボブはボブ自身の署名とハッシュ元のバリューでアンロックできる（CSVでタイムロック）（ボブへ）
- アリスはボブの秘密鍵でアンロックできる（アリスへ）
- HTLCで使われているCLTVの期限切れでアンロック（アリスへ）
１番目のアンロック方法でCSVでタイムロックされている理由は、このコミットメントトランザクションが古くなったときにボブがビットコインを取り出す前にアリスがビットコインを取り出せるようにするためです。
つまり、ボブが悪意を持ってこのコミットメントトランザクションを実行しようとした場合はアリスは２番目の方法でビットコインを手に入れることができます。
３番目の方法は、ボブがバリューを手に入れていなかったときにビットコインがアリスに戻ることを可能にしています。
全体の流れを整理しましょう。まずアリスとボブのそれぞれの署名だけで半分有効なコミットメントトランザクションが存在することになります。（2-0f-2のマルチシグなので）
アリスがコミットメントトランザクションを実行したら、すぐにアリスはボブに５BTCを送ることになります。そして、CSVのタイムロックが切れたとき（例えば100ブロック後）に自分自身に送った4BTCが届きます。
さらに、CLTVで決められた期間の間（例えば2週間）にボブは自身が持っているバリューを使ってHTLCのアウトプットである1BTCを手に入れることができます。もし、ボブがバリューを使わなければアリスに1BTCが返金されることになります。
対して、ボブもコミットメントトランザクションを実行し、すぐにボブはアリスに4BTCを送ることになります。そして、CSVのタイムロックが切れたときに自分自身に送った5BTCが届きます。さらに、ボブはバリューを使うことで上記のように1BTCを手に入れることが可能です。
この一連のコミットメントトランザクションはボブが作ったものでしたが、上図のようにアリスも正反対のコミットメントトランザクションを作ることでライトニングネットワークのチャネルが完成します！
つまり、このような状況のときボブは受け取ったバリューを使うだけで1BTCを送るためにチャネルの状態を更新することが可能です。
チャネルの中では上記のような複雑な流れや条件分岐が発生していますが、アリスとボブはそのチャネルの「外側」からバリューのやり取りでBTCのやり取りを行い、チャネル内の状態を更新できることになります。
HTLCで定めた期限の間だけこのチャネルは開いており、何回でも状態を更新させることが可能です。さらに、ボブとアリスだけでなく、このチャネルを他のピアとも開くことでライトニングネットワークが出来上がります。
チャネルを閉じる
ライトニングネットワークがイノベーティブなのは、上記の全てのやり取りでブロックチェーンが必要ないということです。つまり、ブロックチェーンに記録されることなくオフチェーンで実行されているのです。
やり取りを終えた最後にこのチャネルを閉じることで、最終的なトランザクションをブロックチェーンに記録するだけでいいのです。
チャネルを閉じるためには単にチャネル内での最終的なトランザクションをブロードキャストするだけです。これにより、チャネル内で起こった過去のコミットメントトランザクションはブロードキャストされず、最新の状態のみがブロックチェーンにトランザクションとして反映されるのです。
ライトニングネットワークのメリット
ここまでライトニングネットワークのチャネル外部と内部から見た仕組みについて解説しました。このようなライトニングネットワークでは、高速な送金、マイクロペイメント、スケーラビリティ、クロスブロックチェーンへの応用などのメリットが得られます。
高速な送金
ビットコインのブロック生成時間は約10分間であり、ブロックに含まれるトランザクションが「正しい」と承認されるためには一般的にその後に６個のブロックが追加されるまで待つ必要があります。つまり１時間もの時間が必要になるのです。
一方、ライトニングネットワークを使えば、上述のように途中の取引は全てオフチェーンで行われ、ブロックの承認を待つ必要はありません。つまり、即時的な送金が可能になるのです。
マイクロペイメント
ライトニングネットワークを使うことでビットコインでのマイクロペイメント、つまり0.00000001BTCまでの少額の支払いが可能になります。通常のトランザクションアウトプットでは最小サイズが決まっており、ライトニングネットワークの場合と比べて数百倍の額となってしまいます。
さらに、トランザクション手数料が存在するのでビットコインのマイクロペイメントは非現実的でした。しかし、ライトニングネットワークの導入によりオフチェーンでの処理が可能になると、手数料がチャネルを開くための１回分で済むので大幅に減少します。
スケーラビリティ
ビットコインやイーサリアムで大きな問題となっているスケーラビリティ問題への対策にもなります。なぜなら、ライトニングネットワークの途中のトランザクションはオフチェーンで行われ、ブロックチェーンにはデータとして書き込まれないのでその分、データ量を節約できるからです。
例えば、ライトニングネットワークのチャネル内で100回取引が行われたとしてもブロックに書き込まれるトランザクションは１つのみです。
ライトニングネットワークの課題・問題点
上述したように、ビットコインネットワークにおいてさまざまなイノベーションを起こすことが期待されているライトニングネットワークですが、実装にあたっては現時点でさまざまな課題や問題点が指摘されています。
まずあげられる課題が、非分散化ネットワークになってしまう可能性です。
(source: Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution)
上図における左２つのようにネットワークが特定のノードにハブ化された状態になってしまうことが考えられます。形を見ても分かるようにこれでははとても分散化されたネットワークであるとは言えません。
ビットコインネットワークのような巨大なネットワークでライトニングネットワークが使われるためには、特定のノードにチャネルが到達するためにたくさんの数のチャネルを開く必要があります。そのために、「ターゲットまでの適したルートをいかに見つけるか」という課題があります。
また、ライトニングネットワークで中継するノードは「貸付」をしなくてはいけません。上記の３者間でのペイメントチャネルで解説した通り、アリス→ボブ→キャロルと10BTCが送金されるとき、まさにこの流れでビットコインが移動するのではなく、まずボブ→キャロルで10BTCが移動し、その後アリス→ボブで10BTCが送られます。
つまり、ライトニングネットワークで中継するノードはルーティングのためにビットコインを貸し出す必要があるのです。巨大なネットワークでライトニングネットワークを作ると、このような継続的な貸付が問題化することが予想されます。
つまり現状では、さらにルーティングに関して工夫を施さないとライトニングネットワークが機能しなくなっていまうのです。
また、ビットコインだけでなくイーサリアムにおいてもライトニングネットワークと同様の仕組みでライトニングネットワークというプロジェクトが開発されています。
参考：イーサリアムにおけるライデンネットワークの仕組みと問題点
Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution：数学的な証明の元、ライトニングネットワークのさまざまな問題点について指摘されています。
