Lightning Networkが動作する仕組み

はじめに

「Bitcoin」は、ブロックチェーン上(on-chain)で実現されています。本連載で解説する「Lightning Network」は、ブロックチェーン外(off-chain)技術の1つです。この技術は、「Blockchain」を1つの階層と見なし(1st Layer)、Blockchainの上位層を作るため「2nd Layer技術」とも呼ばれます。

Lightning Networkが生まれた背景

Bitcoinでは「平均して1秒間に約7取引しかできない」と言われています。これは、以下のBitcoin仕様によるものです。

• 10分に1回程度、取引を入れるブロックを作成するように調整されている
• ブロックのサイズが固定されているため、1回に処理できる取引数に制限がある

取引数が少なく、最長10分待つことでブロックに入る(＝必要最低限な承認)のであればまだ良いのですが、ブロックに入らなかった場合は次回以降に処理されます。

基本的にブロックに入る取引は手数料の高いものが優先されます。そのため、手数料を上げた取引を行う人が増えてきます。それでもまだ処理されないと、また手数料を上げて……と、全体の取引数が増えることにより、手数料が上がってしまう傾向があります。

この問題に対しての解決がいくつか提案されています。その1つがLightning Networkです。

Lightning Networkとは

Lightning Network技術の主な特徴は「即時決済」です。ブロックチェーンを使わないため各自が送金を管理する必要があり、オンラインでないと送受金できません。その代わり、10分に1回のブロック生成とは関係なく、2nd Layer上で決済を完了させることができます。

Lighitning Network技術自体は「このようにすれば、こういうことができる」という理論です。これを実際に動かすためには、ソフトウェアとして実装する必要があります。これまでにも、いくつかソフトウェアが実装されましたが、独自仕様で作成されているソフトウェア同士は理論は同じでも実現方法が異なるため、意思疎通ができません。

そこで、ソフトウェアレベルの詳細な仕様を作成して、GitHub上に公開する「Basis of Lightning Network Technology」、略して「BOLT」と呼ばれるプロジェクトができました。

GitHubで公開されているので、見ることはもちろん、内容に問題があれば質問できますし、提案もできます。この仕様に従ったLightning Networkソフトウェアを作成すれば、同じように作られた他のソフトウェアとも通信できます。

2018年6月現在、ソフトウェアとしては「c-lightning」「eclair」「lnd」が有名です。弊社でも「ptarmigan」というソフトウェアをオープンソースで開発中です。

本連載では、BOLT仕様のLightning Networkについて、主に実現されている下記の3つの機能が「どのように解決されているのか」を解説していきます。

• 即時決済
• 送金の中継
• サーバのような中央システムを置かない

Lightning Networkの動作

Lightning Network技術の詳細は次回以降に解説するとして、まずはLightning Networkがどのように動作するのかを見ていきます。

チャネル

Lightning NetworkはBitcoinと同じく、ネットワーク上で「ノード」というソフトウェアを使います(以下、LNノード)。

LNノード間をネットワーク接続(P2P)して、送金する場合はノード間に「チャネル」を作成します。チャネルはお互いのLNノードが送金するための経路のようなもので、1つのLNノードが複数のチャネルを作成することも可能です。

チャネルはいろいろな情報を持っており、2nd Layerで送金できるBitcoinの情報も入っています。チャネルを作成するときにBitcoinを入金し、その額の範囲で送金を行います。

例えば、AさんとBさんがチャネルを開いており、それぞれAさんが「5」、Bさんが「5」のBitcoinを持っていたとします(合計「10」)。ここでAさんがBさんに「2」送金すると、AさんのBitcoin量は2減って「3」に、BさんのBitcoin量は2増えて「7」になります。AさんとBさんの配分が変わっただけで、合計は「10」のままです。

チャネルのライフサイクルは、以下のようになります。

1. チャネルをオープン
2. 送金
3. チャネルをクローズ

Lightning Networkで送金する前には、まずチャネルのオープンが必要です。一度チャネルをオープンすれば、どちらかがクローズするまで送金ができます。

チャネルを作る前に！

Bitcoinは秘密鍵、あるいはHDウォレットのパスフレーズなどがあればウォレットを復元できますが、Lightning NetworkはLNノードのソフトウェアがすべてです。まだLightning Network自体が成熟していないこともあり、ソフトウェアの不具合などでチャネル内のBitcoinが取り戻せなくなる可能性もあるため、ご注意ください。個人的には、いきなりMAINNETで使うのではなく、TESTNETで体験する方が良いと思います。

チャネルのオープン

チャネルはBitcoinの送金によって作られます。

まず、チャネルに参加する2名の「マルチシグアドレス」を作成します。マルチシグアドレスとは、複数人が管理するアドレスです。Lightning Networkでは「2-of-2」、すなわち2名で管理し、2名が署名しないとBitcoinを送金できないアドレスを作成します(Bitcoinの送金には署名が必要なため、アドレスの持ち主＝署名ができる人になる)。

次に、このアドレスに送金します。その送金された額の範囲内で、チャネルに送金を行うことになります(仕様上の上限は約0.167BTC)。なお、Bitcoinの最小単位は「satoshi」ですが、Lightning Networkでの最小単位は「m-satoshi」、すなわち1000分の1satoshiです。

チャネルは、Bitcoinを送金したい人が入金することで作成されます。今回は、Aさんが送金したい人として説明していきます。

もし、Aさんがマルチシグアドレスに送金した後でBさんが所在不明になったり、署名する鍵をなくしてしまうと、AさんはそのBitcoinを取り戻すことができません。そのため、AさんとBさんは事前に通信を行い、先に「2-of-2アドレスに入金したBitcoinをAさんに送金する」というトランザクションを作ってしまいます。

ここで言うトランザクションとは、Bitcoin送金情報のデータです。「Bitcoinで送金した」という場合は、トランザクションがネットワークに送信されたり、ブロックチェーンのブロックに入ったりすることを指します。

Aさんは、最悪でもBitcoinを取り戻せることを確認した後で、マルチシグアドレスに送金します。送金されたBitcoinがブロックに含まれ、Bさんが指定した以上の承認数(confirmation数)に達すると、AさんとBさん間にチャネルを開いたことになります。

ただし、まだチャネルにはAさんのBitcoinしかないので、送金も「Aさん→Bさん」の方向にしかできません。

送金

Lightning Networkでの送金はBitcoinと異なります。Bitcoinの場合はトランザクションをブロックチェーンに展開してアドレスに送金しますが、Lightning Networkではノードに送金します。そして、チャネルを閉じるまでの間はLNノードがBitcoin量を管理することになります。

1. チャネル相手への送金

基本動作は、チャネル相手への送金です。

1-1. invoice取得
送金先の相手から、支払うための情報（invoice＝請求書）をもらいます。これにはLightning Networkの通信を使いません。よくあるのは、ホームページで「購入」ボタンを押すとinvoiceのデータを表示する方法です（例：Starblocks、Y'alls）。

invoiceには、送金してほしいBitcoin量や不正な送金を防ぐための「preimage-hash」(invoice発行元が持つ「preimage」という秘密データのハッシュ値。preimage-hashからpreimageを求めるのは非常に難しい)などが含まれています。

送金者はLNノードのソフトウェアにinvoiceを伝えると、あとはLNノードが自動的に送金を開始します。invoiceを取得した送金元のAさんは、数式的に安全な次の2つの手順で送金を行います。

1. HTLCの追加
2. HTLCの反映

1-2. 送金：HTLCの追加
まず、「HTLC」と呼ばれる送金額が入った情報を送ります(HTLCは送金をBitcoinスクリプトという簡易プログラムで制御する手法です)。お互いにHTLCを追加して、Aさんは「送金額の分が減る」、Bさんは「送金額の分が増える」という情報だけ追加します。

この段階では、まだBさんのBitcoin量は増えていません。AさんのBitcoin量は減っていますが、送金に失敗すれば取り戻せるようになっています。

HTLCは、invoiceに含まれているpreimage-hashで鍵をかけているような状態になっています。

1-3. 送金：HTLCの反映
HTLCを解除するためには、invoiceに含まれていたpreimage-hashの元データが必要になります。invoiceはBさんが作っているため、元データのpreimageもBさんが持っています。Bさんは相手が正しいHTLCの情報を送ってきたことを確認してpreimageの情報を相手に展開します。

Aさんは、受信したpreimageが正しいと判断すればHTLCのBitcoin量を反映します。

それぞれHTLCを反映し、HTLCを削除すると送金は完了です。送金が完了すると、チャネル内のBitcoin配分が変更されます。

2. チャネルを経由した送金

Lightning Networkの特徴として、直接チャネルを開いていないLNノードに送金できるという機能があります。複数のチャネルを経由して送金するため、いくつか条件があります。

• 送金するLNノードは送金先までのチャネルを知っている
• 送金するBitcoin量＋中継するLNノードへの手数料が必要
• 中継するそれぞれチャネルに送金するだけのBitcoin量がある
  【NGの例】
  • チャネルをどう経由しても送金先に届かない
  • どこかのLNノードが起動していない
  • 送金額よりも小さい額しか入っていないチャネルがある

ただ、これはLNノードが知っておくべき情報であり、LNノードを使用する人が把握しておく必要はありません（人力で行うのは、ほぼ無理です）。使用する人が必要な情報は「1.チャネル相手への送金」と同じです。

• 送金先からinvoiceを取得する
• invoiceをLNノードに伝える

invoiceの取得は「1.チャネル相手への送金」と同じなので、それ以降を説明します。

2-1. 経路情報の作成
送金するLNノードは、送金先までの経路情報を作成する必要があります。経路情報は以下のようなデータを含んでいます。

• 送金者から送金先までの全LNノードとチャネル
• 各LNノードが相手に支払うBitcoin量

経路情報は送金経路のLNノードを中継して渡していくことになりますが、途中のLNノードに情報を見られたり、改ざんされたりしないように、送金元の人が暗号化します。そして、経路情報を中継するLNノードは自分が次のLNノードに送金するための情報だけを解読できる仕組みになっています。

経路情報に必要なLNノードやチャネルの情報を集めるために、接続されたLNノード間で常にメッセージを交換し合っています。新しくLNノードと接続すると、自分が知っている他のLNノードやチャネルの情報を交換します。そして、新しい情報が追加されるたびに情報交換をしていきます。

送金の中継手数料も、交換する情報の中に含まれています。送金者は、最初の送金額に各LNノードに支払う手数料も含めます。中継するLNノードは、受け取ることになる額と、次のLNノードへの送金額の差を手数料として受け取ります。経路によって送金額が変わってくるということになります。

2-2. 送金の中継
経路情報を作成すると、まず送金先のLNノードから最初の中継LNノードに送信します。受信した中継LNノードは、解読して、また次の中継ノードに送信し……を繰り返し、送金先のLNノードまで繰り返します(最初の中継LNノードが送金先のLNノードと同じだった場合が「1.チャネル相手への送金」です)。

各チャネルの間で、HTLCの追加と反映を行っています。「1.チャネル相手への送金」では説明しませんでしたが、HTLCには時間制限があります。すなわち、期限内に何らかの処理をしないと、送金先であってもBitcoinを手に入れられなくなります。

時間制限が付けられているのは、中継をしたLNノードが途中で処理を放置しても、タイムアウトすれば送金者に戻ってくるようにするためです。「タイムアウトするまでに送金を終わらせよう(終わらせないと損をする)」というインセンティブを与える側面もあります。

再送

Bitcoinでは、送金先のアドレスが分かっていれば、相手の状態に関係なく送金ができます。しかし、Lightning Networkでは相手のLNノードに送金を行うため、ネットワーク上にLNノードが存在していなければ送金ができません。「存在する」とは、送金するタイミングでLNノードがオンラインになっているという意味です。

また、送金先のLNノードがオンラインでも、送金を中継するLNノードのどこかがオフラインになっている可能性があります。そのような場合は別の経路を作って送金し、オンラインになっている最後のLNノードまでは中継が進みます。

しかし、それ以上は経路に沿って進めないため、中継元のLNノードにエラーを返します。エラーを受信したLNノードは同じように送信してきたLNノードにエラーを返します。これを繰り返し、最終的には送金元までエラーが通知され、その経路での送金は中止されます(時間切れの場合とは異なりHTLCも元に戻ります)。

Lightning Networkの仕様に再送の規定はありません。途中の経路が原因で送金できないのであれば、ほとんどのLNノードは自動的に別の経路を作って送金するでしょう。通行できなかったチャネルを計算から外して経路を作り直し、新しい経路で送金を開始すれば再送になります。

悪意のある行動

Lightning Networkでは「即時決済が可能」という言い方をしていますが、「いつでもチャネルをクローズしさえすればBitcoinとして使用できる状態を維持している」という言い方もできます。LNノード内部では、送金するたびにチャネル内のBitcoin量をお互いに配分するトランザクションを作成しており、そのトランザクションをブロックチェーンに展開すれば、それぞれの手元にBitcoinが戻ってきます。

送金前のトランザクションは破棄するルールですが、データとしては手元に存在しています。もし送金者が「送金をなかったことにしてしまいたい」と考え、Bitcoin量が減る前の古いトランザクションをブロックチェーンに展開したらどうなるでしょうか。ソフトウェアを改造して、そういうことをしてしまう人がいるかもしれません。

このような行動を取られた場合の対策も、仕様として考慮されています。「お互いに配分するトランザクション」と解説しましたが、相手のアドレスに直接送金するようにはなっておらず、条件によって送金先が変わるようなBitcoinスクリプトになっています。

もしAさんが最新ではない配分のトランザクションをブロックチェーンに展開すると、Bさんがチャネルの全額を受け取れるように作られています。悪いことをすると、損をするのです。

チャネルのクローズ

チャネルの内容をブロックチェーンに展開すると、チャネルをクローズしたことになります。クローズの方法には、次の3種類があります。

Mutual Close

• お互いのLNノードが合意してクローズする
• 他のクローズ方法と比較して手数料が低く、使用できるまでの期間が一番短い

Unilateral Close

• 片方のLNノードが一方的にクローズする(相手のLNノードと通信できなくなった場合など)
• Mutual Closeできなかった場合にやむなく使う

Revoked Transaction Close

• 「悪意のある行動」で説明したように、古いトランザクション(revoked transactionは「破棄されたトランザクション」)でクローズする
• クローズした人が損をするが、クローズされた方に行動が必要

おわりに

今回は、Lightning Networkの動作概要を解説しました。次回以降は、数回にわたってLightning Networkで使用されている技術を個別にピックアップし、解説していきます。