ライトニング ネットワークを理解する --- ビットコインの双方向支払いチャネルの構築

原題:「 Popular Science | Understanding Lightning Network, Part-1: Building a Bidirection Payment Channel for Bitcoin 」、著者 AARON VAN WIRDUM
ライトニング ネットワークは、おそらくビットコイン ブロックチェーンで最も期待されているイノベーションです (編集者注: 原文は 2016 年に書かれました)。この支払いスキームは、1 年以上前に Joseph Poon 氏と Tadge Dryja 氏によって最初に提案されたもので、ユーザーが無制限のトランザクションをオフチェーンに送信できるようにサポートし、コストが非常に低く、ビットコイン ネットワークによって提供されるセキュリティも借りることができると主張しています。
少なくとも 3 社 (Poon と Dryja の Lightning、Blockstream、Blockchain) がこのテクノロジーの実装を開発しています。しかし、「マイクロペイメントの未来」がどのようにしてビットコインの可能性を解き放つのかを理解しているのは、狭い技術者の範囲外にはほとんどいない。
この一連の記事では、Bitcoin Magazine はライトニング ネットワークの最も基本的な構成要素を列挙し、これらをどのように組み合わせて次期プロトコルであるライトニング ネットワークを形成できるかを示します。
このシリーズの最初の記事では、必要なモジュールをリストし、それらを組み合わせて「スマート コントラクト」を作成する方法を示します。この概念は、ライトニング ネットワークの最初の前提である双方向支払いチャネルを理解するために使用できます。
(ヒント: ビットコインに精通している読者は、これらのモジュールの紹介をスキップしてかまいません。)
モジュール #1: 未確認のトランザクション
ビットコイン プロトコルの中心となるのは、いわゆる「トランザクション」の概念です。一般に、トランザクションは常に別の先行トランザクションに関連付けられており、将来のトランザクションでも使用できます。各トランザクションは、ビットコインの転送元アドレスを指す入力と、ビットコインの受信元アドレスを指す出力で構成されます。さらに、ビットコインを送信するには、送信者が入力アドレスの「所有権」を持っていることを証明するデジタル署名の提供など、入力が特定の条件を満たしている必要があります。同時に、出力はこれらのビットコインが将来使用されるための新しい条件も確立します。これは、後続のトランザクションが発行されるときに満たされる必要があります。
(翻訳者注: ビットコインを額面付きの小切手と考えてください。使用すると、小切手自体が資金源となり、使用後に新しい小切手が形成されます。したがって、各小切手には、この小切手を形成するトランザクションがあり、は前のトランザクションであり、これらのチェックが再度使用されると、そのトランザクションを後続のトランザクションと呼ぶことができます。)
画像の説明

- (訳者注: 図に示すように、ビットコインは小切手のように分割することができ、その流通は明確なチェーンを形成します。) -
モジュール #2: 二重支出の防止
ライトニング ネットワークに必要な 2 番目のモジュールについては、おそらく多くの説明は不要でしょう。これはおそらく、ビットコイン プロトコル自体の存在理由、つまり複数の支払いに対する保護手段だからです。 2 つのトランザクション (または入力) が同じ出力に依存している場合、そのうちの 1 つだけがネットワーク全体によって確認されます。
覚えておいてください: 未確認のトランザクション間に競合があったとしても、最終的に確認されるのは 1 つだけです。

モジュール #3: マルチシグ
ライトニング ネットワークの 3 番目のモジュールであるマルチシグネチャ アドレスもよく知られています。 (より広義には、P2SH アドレス (スクリプト ハッシュ アドレス)。)
名前が示すように、マルチシグネチャ アドレスは、「ロックを解除」してビットコインを使用するために複数の秘密キーが必要なアドレスです。マルチシグネチャアドレスの条件はさまざまな方法で設定できます。たとえば、3 つの秘密キーのうち 2 つがビットコインの転送に参加すること、または他の数量要件 (2/5、3/4 など) を要求することができます。
ライトニング ネットワークでは通常、2-2 マルチシグネチャ要件が使用されます。このようなアドレスからビットコインを転送するには、これら 2 つの秘密鍵に関連する 2 つの署名を提供する必要があり、1 つ少ないと機能しません。

モジュール #4: タイムロック
4 番目のモジュールはタイムロックです。タイムロック機能は出力にロック条件を設定し、将来の特定の時間が経過した後にのみこれらのビットコインを使用できるようにします(つまり、トランザクションへの入力として使用できます)。
時間ロックには 2 つのタイプがあります: 1) CheckLockTimeVerify (CLTV) と呼ばれる絶対時間ロック、2) 相対時間ロック、CheckSequenceVerify (CSV)。 CLTV は、将来の (おそらく) 特定の日付、つまり特定の日時、または特定のブロックの高さまでビットコインをロックしますが、CSV は相対時間のみを使用します。 CVS 出力がチェーンにアップロードされるとき、出力が使用される前に、一定のブロック数を待機する必要があります。

モジュール #5: ハッシュとシークレット
5 番目で最後のモジュールである暗号化は、ビットコイン自体の最も基本的なモジュールでもあります。ただし、Lightning Network では使用方法が異なります。
つまり、「秘密の値」とは、コンピューターが無数の激しい計算を行ったとしても、推測することはほとんど不可能な、非常に長くてユニークな数値の文字列です。そして、特別な計算を通じて、この秘密の値を「ハッシュ値」と呼ばれる別の数値に「分割」することができます。ここが興味深い点です。秘密の値を知っている人はそのハッシュ値を簡単に計算できますが、その逆は真ではなく、ハッシュ値を使って秘密の値を元に戻すことはできません。
ビットコイン ブロックチェーンでは、このメカニズムを再び「ビットコインのロック」に使用できます (実際、ビットコインのロックはビットコイン プロトコルの仕組みです)。たとえば、出力にハッシュ値を含め、後続のトランザクションで、そのハッシュ値に対応するシークレット値が含まれている場合にのみ出力を使用するように要求できます。

最初の課題: 双方向の支払いチャネル
Lightning Network が登場する前から、すでに「支払いチャネル」という概念がありました。標準の支払いチャネルは専用に構築されているため、制限があり、一方向のチャネルです。アリスはオフチェーンでボブへのドビー支払いを開始できますが、ボブは同じチャネルを使用してアリスに支払うことはできません。
ライトニング ネットワークの重要な機能は、Poon と Dryja によって提案されたトラストレスな双方向支払いチャネルです。
オープンチャネル
双方向の支払いチャネルを確立するには、まず関係する双方がチャネルを開くための取引について合意に達する必要があります。この開始トランザクションにより、各ユーザーがこのチャネルに入金するビットコインの量が決まります。
アリスがボブに 1 btc を送信したいとします。両者は将来的に頻繁にやり取りを行うことが予想されたため、双方向の決済チャネルを開設することにしました。 (チャネルで 1 btc を送信するのはおそらく少し多すぎます。結局のところ、どのチャネルもマイクロペイメントにはおそらくより便利です。しかし、それは完全に実行可能です。)
チャネルを開くために、アリスとボブはそれぞれ 5 btc を 2-2 マルチシグネチャ アドレスに送信します。これが「チャネル開設トランザクション」です。このアドレスのお金は、アリスとボブが同じ取引に署名した場合にのみ使用できます。
さらに、アリスとボットはそれぞれシークレット値 (つまり、数値の文字列) を作成し、ハッシュを交換します。
ここで、アリスはチャネル開設トランザクションの後続トランザクションを作成します。これが「コミットメント トランザクション」です。このコミットメント トランザクションでは、アリスは 4 btc を自分自身に送信し、6 btc を 2 番目のマルチシグネチャ アドレスに送信します。このマルチシグネチャ アドレスはさらに興味深いです: ボブはこのアドレスを単独でロック解除できますが、お待ちください (アリスのトランザクション 1-00 ブロック後)チェーン上では、ボブはその中のお金を使うことができます (これは相対的な時間ロックです); アリスも、ボブからの贈り物に対応するハッシュ値を持っていれば、このアドレスを単独で開くことができます。 (もちろん、アリスはこの秘密の値についてまったく知りません。彼女が持っているのはボブが与えたハッシュ値だけです。したがって、それは表面上のものにすぎません。) (翻訳者注: つまり、この 2 番目のマルチシグネチャ アドレスは、タイム ロックとハッシュ ロックの両方です。 。)
アリスはコミットトランザクションに署名します。しかし、彼女は取引をブロードキャストしません!代わりに、彼女はトランザクションをボブに送信するだけです。
同時に、ボブはまったく対称的な操作も行います。彼はまた、コミットメントトランザクションを作成し、6 btc を自分に送信し、4 btc を新しいマルチシグネチャアドレスに送信しました。アリスは 1000 ブロック待った後に単独でアドレスのロックを解除することも、ボブがアリスの秘密の値を使用してアドレスのロックを解除することもできます。
ボブはトランザクションに署名し、アリスに送信します。
これらのコミットメント トランザクションとハッシュ値を交換した後、それらは一緒に署名し、チェーンにアップロードできるようにチャネル開始トランザクションをブロードキャストします。これで、双方向の支払いチャネルが開設されました。
チャネルを開いた後、アリスとボブは両方とも、ローカルから取得した部分的に有効なコミットメント トランザクションに署名してブロードキャストできます。アリスがブロードキャストすると (ボブが彼女にコミットメント トランザクションを送信すると)、ボブはすぐに 6 btc を取得します。 Bod がブロードキャストすると、Alice は直ちに 4 btc を取得します。しかし、トランザクションに署名してブロードキャストする側は、後続のマルチ署名アドレスのロックを解除して残りのビットコインを取り出すまで、1000 ブロック待つ必要があります。

ただし、これが支払いチャネルの重要なトリックです。つまり、取得したコミットメント トランザクションに署名したりブロードキャストしたりしないのです。
(訳者注:最初にコミットメントトランザクションをやりとりしてからチャネル開設トランザクションをブロードキャストするのは、相手による不正行為を避けるためであり、コミットメントトランザクションを取得した後はブロードキャストする必要がなく、安全性の保証も得られる。 )
チャンネルを更新する
その後、ボブは 1 btc をアリスに送り返し、このチャネルの状態を更新して 5:5 状態に戻すことを希望します。これを達成するには、アリスとボブは 2 つのことを行う必要があります。
まず第一に、両当事者は上記のプロセスを再度実行する必要があります (トランザクションはチェーンに記録されているため、トランザクションを開始する部分を除く)。今回は、アリスとボブの両方が互いに 5 btc を割り当て、両方ともそのマルチシグネチャ アドレスに 5 btc を割り当てます。これらの後続のマルチシグネチャ アドレスの条件は同様ですが、すべて新しいシークレット値を生成する必要がある点が異なります。アリスとボブの両方が新しいハッシュ値を提供します。両方とも独自の新しいコミットメント トランザクションに署名し、相互に送信します。
次に、アリスとボブの両方が、最初の秘密値 (最初のコミットメント トランザクションで使用される値) を互いに渡します。
この時点で、アリスとボブは両方とも最新のコミットメント トランザクションに署名してブロードキャストできます。対戦相手はすぐに 5 btc を取得しますが、自分自身をブロードキャストする場合は 1000 ブロック待つ必要があります。このようにして、チャネルの状態が更新されます。
しかし、ボブが古いコミットされたトランザクションをブロードキャストするのを妨げているのは何でしょうか?そのコミットトランザクションは彼に6 btcを割り当てることになりますが、これは5 btcを超えています...
もちろん、ボブを止めるのは、彼の最初の秘密の値、つまり彼がすでにアリスに与えた値です。
なぜなら、アリスはすでにボブの最初の秘密値を知っているため、この時点では、ボブは、古いコミットメント トランザクションに好きなように署名したりブロードキャストしたりすることができなくなります。ボブが古いコミットメントトランザクション(アリスが彼に与えたもの)に署名してブロードキャストした場合、彼はすぐに4ビットコインをアリスに送信します...そして彼自身がそれを要求するまでに1000ブロック待つ必要がありますが、アリスはすでに彼の秘密を知っていましたそれだけの価値があるので、彼女はこの時間を利用して残りの 6 btc を先制して引き出すことができます。
そして、ボブもアリスの秘密値を持っているため、ボブにも同じことが当てはまります。アリスが古いコミットメントトランザクションに署名してブロードキャストしたい場合、ボブは彼女がチャネルに入れたすべてのビットコインを盗むことができます。
これは、アリスとボブの両方がいたずらをするのではなく、最新の状態のみをブロードキャストするようにインセンティブを再編成することを意味します。

さて、双方向の支払いチャネルを用意したら、それを支払いネットワークに拡張する必要があります。これが 2 番目の記事の主題です。
熱心なフィードバックをくださった Rusty Russell と Joseph Poon に感謝します。


