ペイメントチャネルのネットワークにおけるルーティング
この章では、ルーティングと呼ばれるプロセスによって、ペイメントチャネルがどのように接続され、ペイメントチャネルのネットワークを形成することができるかを最終的に解明する。具体的には、ルーティング層の最初の部分である「原子的で信頼性のないマルチホップ契約」プロトコルを見ていくことにする。これは、LightningプロトコルスイートにおけるAtomic payment routingに示されているように、プロトコルスイートのアウトラインによって強調されている。
https://scrapbox.io/files/631f0af40c1efd001d186c39.png
図1:「Lightning」プロトコルスイートにおけるアトミックペイメントルーティング Lightningプロトコルスイートにおけるアトミックペイメントルーティング
支払いのルーティング
このセクションでは、ゲームセッションをストリーミングしながらファンから寄付を受け取るゲーマー、Dina の視点からルーティングについて検討します。
ルーティングされた支払いチャネルの革新により、Dina は、彼女にチップを渡したいファン一人ひとりとの個別のチャネルを維持することなく、チップを受け取ることができます。その視聴者からDinaへの十分な資金がある経路が存在する限り、彼女はそのファンから支払いを受けることができるのです。
ライトニング・ネットワークでディナに(中略)直接接続されているファンでは、ライトニング・ノード間のさまざまな支払い経路によって作られる可能性のあるネットワーク・レイアウトを見ることができます。この図の中の誰もが、パスを構築することでDinaに支払いを送ることができます。ファン4がDinaに支払いを送りたい場合を想像してください。それを実現するためのパスがわかりますか?ファン4は、ファン3、ボブ、チャンを経由してディナに支払いをルーティングすることができます。同様に、アリスはボブとチャンを経由してディナに支払いをルーティングすることができます。
https://scrapbox.io/files/631f0b313b5183001d328ca8.png
図2. Lightning Network上でDinaに(中略)直接接続されたファンたち
ファンからディナまでの経路にあるノードは、支払いをルーティングする文脈ではルーティングノードと呼ばれる仲介役である。ルーティングノードとDinaのファンが操作するノードの間に機能的な違いはない。どのライトニングノードも、そのペイメントチャネル間で支払いをルーティングすることができる。
重要なのは、ルーティングノードは、ファンからディナへの支払いをルーティングしている間に資金を盗むことができないことです。さらに、ルーティング・ノードはルーティング・プロセスに参加している間にお金を失うことはできません。ルーティング・ノードは、仲介役を務めることでルーティング料を請求することができるが、その必要はなく、無料で支払いをルーティングすることも可能である。
もう1つの重要な点は、オニオンルーティングを使用しているため、仲介ノードは経路上で先行する1つのノードと後続する1つのノードのみを明示的に認識することである。彼らは、誰が支払いの送信者と受信者であるかは必ずしも知りません。このため、ファンは、個人情報を漏らすことなく、また盗難の危険性もなく、ディナへの支払いに仲介ノードを利用することができる。
このように、一連の支払いチャネルをエンドツーエンドのセキュリティで接続するプロセスと、支払いを転送するノードへのインセンティブ構造が、ライトニング・ネットワークの重要なイノベーションの1つです。
本章では、ライトニング・ネットワークにおけるルーティングの仕組みに踏み込み、ネットワーク上を支払いがどのように流れていくのかについて詳しく説明します。まず、ルーティングの概念を明確にし、経路探索の概念と比較します(これらはしばしば混同され、同じように使用されます)。次に、フェアネスプロトコルを構築する。これは、支払いをルーティングするために使用されるアトミックでトラストレスのないマルチホッププロトコルである。このフェアネスプロトコルがどのように機能するかを示すために、4人の間で金貨を転送する物理的な等価物を使用する。最後に、現在ライトニング・ネットワークで使われている原子・信頼・マルチホップ・プロトコルの実装を紹介します。これは、ハッシュタイムロックコントラクト(HTLC)と呼ばれるものです。
ルーティングとパスファインディングの比較
ルーティングの概念と経路探索の概念を分けて考えることが重要です。この2つの概念はしばしば混同され、ルーティングという用語が両方の概念を表すのに使われることがある。先に進む前に、この曖昧さを取り除きましょう。
経路探索とは、path_findingで説明されているように、送信者Aから受信者Bに接続する、支払いチャネルからなる連続した経路を見つけ、選択するプロセスである。
ルーティングとは、ある地点Aから別の地点Bへ、経路探索によって事前に選択された経路を経由して支払いを転送しようとする、ネットワーク上の一連の相互作用のことである。ルーティングは、経路上で支払いを送信する能動的なプロセスであり、その経路に沿ったすべての仲介ノードの協力が必要である。
重要な経験則は、アリスとボブの間に経路が存在しても(おそらく複数存在しても)、支払いを送るためのアクティブな経路が存在しない可能性があることです。1つの例は、AliceとBobを接続するすべてのノードが現在オフラインである シナリオである。この例では、チャネルグラフを調べて、アリスからボブへの一連の支払チャネルを接続することができるため、経路が存在する。しかし、仲介ノードがオフラインであるため、支払いは送信できず、したがって、経路は存在しない。
決済チャンネルのネットワーク化
原子的な信頼性のないマルチホップ決済の概念に入る前に、例を挙げて説明しよう。前の章でアリスは、オープンチャネルのボブからコーヒーを購入した。今、アリスはゲーマーであるディナのライブストリームを見ていて、ライトニングネットワークを通じてディナに5万サトシのチップを送りたいと考えている。しかし、アリスはディナとの直接のチャンネルを持っていません。アリスはどうすればいいのでしょうか?
アリスはディナと直接チャネルを開くことができます。しかし、それには流動性とオンチェーン手数料が必要で、チップの価値より高くなる可能性があります。代わりに、アリスはディナに直接チャンネルを開くことなく、既存のオープンチャンネルを使用してディナにチップを送ることができます。これは、アリスからディナにチップを送るのに十分なチャンネルの経路が存在する限り、可能なことです。
A network of payment channels between Alice and Dina で見ることができるように、アリスはコーヒーショップのオーナーであるボブとの間にオープンなチャネルを持っています。ボブもまた、コーヒーショップで使用している販売時点情報管理システムで彼を助けているソフトウェア開発者チャンとオープンなチャネルを持っています。チャンはディナがプレイするゲームを開発する大手のソフトウェア会社のオーナーでもあり、彼らはすでにディナがゲームのライセンスやゲーム内アイテムの支払いに使用するオープンチャンネルを持っている。
https://scrapbox.io/files/631f0c8093203c002020d9e6.png
図3. アリスとディーナの間の支払いチャネルのネットワーク
アリスからディナへの経路は、ボブとチャンを仲介ルーティング・ノードとして使用することが可能である。アリスはこの経路からルートを作り、それを使ってディナに数千サトシのチップを送り、その支払いはボブとチャンによって転送されるようにすることができます。基本的に、アリスはボブに支払い、ボブはチャンに支払い、チャンはディナに支払います。アリスからディナへの直接のチャンネルは必要ありません。
主な課題は、ボブやチャンが、アリスがディナに届けたいお金を盗むのを防ぐ方法でこれを行うことです。
ルーティング "の物理的な例
ライトニング・ネットワークがどのようにルーティング中の支払いを保護するかを理解するために、現実世界における金貨による物理的な支払いのルーティングの例と比較することができます。
アリスがディナに金貨10枚を渡したいのですが、ディナに直接アクセスできないとします。しかし、アリスはボブを知っており、ボブはディナを知っているチャンを知っているので、ボブとチャンに助けを求めることにした。これは、Alice wants to pay Dina 10 gold coins で示されている。
https://scrapbox.io/files/631f0d1688e6de0023bf1955.png
図4. アリスはディナに金貨10枚を払いたい
アリスはディナに支払うためにボブにチャンに支払うことができますが、コインを受け取った後、ボブやチャンがコインを持ち逃げしないようにどうやって確認するのでしょうか? 物理的な世界では、契約は一連の支払いを安全に行うために使うことができます。
アリスはボブと次のような契約を交わすことができる。
私アリスは、あなたがチャンに金貨を渡したら、ボブ君に金貨10枚を渡します。
この契約は抽象的には良いのですが、現実の世界では、アリスはボブが契約を破って、捕まらないことを願うかもしれないというリスクを負っています。仮にボブが捕まって起訴されたとしても、アリスはボブが破産して10枚の金貨を返せなくなるかもしれないというリスクに直面する。これらの問題が魔法のように解決されるとして、このような契約を利用して、私たちの望む結果、ディナにコインを届けることを達成する方法はまだ不明である。
そこで、これらの問題を考慮した上で、契約書を改良してみましょう。
私アリスは、あなたがチャンに10枚の金貨を渡したことを私に証明できれば、ボブであるあなたに10枚の金貨を払い戻します(例えば、領収書によって)。
なぜボブはそのような契約にサインしなければならないのかと思うかもしれない。彼はChanにお金を払わなければなりませんが、最終的には交換から何も得られず、アリスが彼に弁償しないかもしれないリスクを負っています。ボブはディナに支払うためにチャンに同じような契約を申し出ることができるが、同様にチャンはそれを受け入れる理由がない。
リスクはさておき、ボブとチャンはすでに10枚の金貨を送ることができるはずで、そうでなければ契約に参加することはできないだろう。
このように、ボブとチャンはこの契約に同意するためにリスクと機会費用の両方に直面しており、それを受け入れるためには補償が必要である。
そこでアリスは、ボブとチャンが自分の支払いをディナに送れば、金貨1枚ずつの手数料を支払うと提案し、この契約を魅力的なものにすることができる。
そうすると、契約はこうなる。
私アリスは、あなたが11枚の金貨をチャンに渡したことを私に証明できれば、ボブ君に12枚の金貨を払い戻します。
アリスは今ボブに12枚の金貨を約束した。ディナに渡す金貨が10枚、手数料が2枚です。彼女はボブが11枚をChanに転送したことを証明できれば、12枚を約束する。差額の金貨1枚が、ボブがこの支払いに協力することで得られる手数料となります。アリスがボブに支払い、ボブがチャンに支払い、チャンがディナに支払うと、この取り決めにより、10枚の金貨がボブとチャンを経由してディナに渡ることがわかります。
https://scrapbox.io/files/631f0d780ec0af0023ebcfef.png
図5. アリスがボブに支払い、ボブがチャンに支払い、チャンがディナに支払う
まだ信頼の問題があり、アリスかボブのどちらかが契約を守らないというリスクがあるため、すべての当事者はエスクローサービスを使うことにしました。交換の開始時に、アリスはこの12枚の金貨をエスクローに「預ける」ことができ、ボブがチャンに11枚の金貨を支払ったことを証明してから支払われることになる。
このエスクローサービスは理想化されたもので、他のリスク(カウンターパーティーリスクなど)は導入されていない。後ほど、エスクローをビットコインのスマートコントラクトに置き換える方法について見ていきます。とりあえず、誰もがこのエスクローサービスを信頼していると仮定しよう。
ライトニングネットワークでは、レシート(支払いの証明)は、ディナだけが知っている秘密という形をとることができる。実際には、この秘密は他の人が推測できないほど大きな乱数(典型的には256ビットを使ってエンコードされた、とてもとても大きな数です!)になるでしょう。
ディナはこの秘密の値Rを乱数発生器から生成する。
そして、次のように契約自体に秘密のSHA-256ハッシュを含めることで、秘密を契約にコミットすることができる。
H = SHA-256(R)
この支払の秘密のハッシュを、支払ハッシュと呼ぶ。支払いを「アンロック」する秘密は、支払い秘密(payment secret)と呼ばれる。
今のところ、単純に、Dina の秘密は単にテキスト行であると仮定する。Dinas secret」とする。この秘密のメッセージは、支払秘密または支払前イメージと呼ばれます。
この秘密を「コミット」するために、DinaはSHA-256ハッシュを計算するが、これを16進数で符号化すると、次のように表示される。
0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3
アリスの支払いを容易にするために、Dinaは支払いシークレットと支払いハッシュを作成し、支払いハッシュをアリスに送ります。Dina sends the hashed secret to Aliceでは、Dinaが電子メールやテキストメッセージなどの外部チャネル(破線)を介してAliceに支払いハッシュを送信していることがわかります。
https://scrapbox.io/files/631f0de688e6de0023bf244e.png
図6. Dinaはハッシュ化された秘密をAliceに送る
アリスは秘密を知らないが、支払いの証明として秘密のハッシュを使うように契約を書き換えることができる。
私アリスは、もしあなたが私に057596というハッシュを持つ有効なメッセージを見せることができれば、ボブであるあなたに12枚の金貨を払い戻します......。このメッセージは、Dinaと同様の契約を結ばなければならないChanと同様の契約を結ぶことで入手できます。あなたが払い戻しを受けることを保証するために、次の契約を設定する前に、信頼できるエスクローに12金貨を提供します。
この新しい契約は、アリスをボブがチャンに転送しないことから守り、ボブをアリスから払い戻されないことから守り、ディナの秘密のハッシュによって、ディナが最終的に支払われたことを証明することを保証する。
ボブとアリスが契約に合意し、アリスが12枚の金貨を預けたというメッセージをエスクローから受け取った後、ボブはチャンと同様の契約を交渉することができる。
ボブはサービス料として1枚の金貨を受け取っているので、チャンがディナに支払ったという証拠を見せると、ボブは11枚の金貨をチャンに転送するだけであることに注意。同様に、Chanも手数料を要求し、Dinaに約束の10枚の金貨を支払ったことを証明したら、11枚の金貨を受け取ることを期待します。
ボブとチャンの契約はこうなる。
私、ボブは、あなたが057596というハッシュ値を持つ有効なメッセージを私に見せることができれば、あなた、チャンに11枚の金貨を払い戻します......。このメッセージは、Dinaと同様の契約を結ぶことで入手できます。この11枚の金貨は、あなたが次の契約をする前に、信頼できるエスクローに渡しておくことで、確実に払い戻しを受けることができる。
チャンはエスクローからボブが11枚の金貨を預けたというメッセージを受け取ると、ディナと同じような契約を結ぶ。
私、Chanは、あなたが057596というハッシュ値を持つ有効なメッセージを私に見せることができれば、Dinaに10枚の金貨を払い戻します......。秘密を明かした後に払い戻されることを保証するために、私は信頼できるエスクローに金貨10枚を提供する。
これですべてが整った。アリスはボブと契約し、12枚の金貨をエスクローに預けている。ボブはチャンと契約しており、11枚の金貨をエスクローに預けています。ChanはDinaと契約しており、10枚の金貨をエスクローに預けています。Dinaは、支払いの証明として確立したハッシュのプリ画像である秘密を明らかにすることができる。
DinaはDinasの秘密をChanに送る
Chanは、Dinasの秘密のハッシュが057596であることを確認する...。Chanはこれで支払いの証明を得たので、エスクローサービスにDinaに金貨10枚を渡すように指示します。
Chanは今度はBobに秘密を教える。Bobはそれを確認し、エスクローサービスに11枚の金貨をChanに渡すよう指示する。
ボブは今度はアリスに秘密を教える。アリスはそれを確認し、金貨12枚をボブに渡すようエスクローに指示する。
これですべての契約が成立した。アリスは合計12枚の金貨を支払い、そのうち1枚をボブが受け取り、1枚をChanが受け取り、10枚をDinaが受け取りました。このように契約が連鎖しているため、ボブとチャンは先にエスクローに預けたので、お金を持ち逃げすることはできませんでした。
しかし、まだ1つ問題が残っている。もしディナが自分の秘密のプリ画像を公開することを拒否したら、チャン、ボブ、アリスは全員エスクローにコインを預けたまま払い戻しを受けられないことになる。そして同様に、もし他の誰かがその秘密を伝えなかった場合、同じことが起こります。つまり、誰もアリスからお金を盗むことはできませんが、誰もが自分のお金を永久にエスクローに預けたままにしておくことになるのです。
幸運なことに、これは契約に期限を設けることで解決できます。
ある期限までに契約が履行されなければ、契約は失効し、エスクローサービスはお金を最初に預けた人に返すように、契約を修正すればいいのです。この期限をタイムロックと呼んでいます。
手付金は一定期間エスクローサービスにロックされ、支払い証明が提出されなくても最終的には解放される。
このことを考慮し、アリスとボブの間の契約は、もう一度新しい条項で修正される。
ボブは契約締結後24時間以内に秘密を提示しなければならない。もしボブがこの時間までに秘密を提供しなければ、アリスの預金はエスクローサービスによって払い戻され、契約は無効となる。
ボブはもちろん、今度は24時間以内に支払いの証明を受け取れるようにしなければならない。たとえチャンにうまく支払えたとしても、支払証明を受け取るのが24時間より遅ければ、払い戻されることはない。そのリスクを排除するために、ボブはチャンにさらに短い期限を与えなければならない。
そこで、ボブはチャンとの契約を次のように変更する。
チャンは契約締結後22時間以内に秘密を提示しなければならない。もし、チャンがこの時間までに秘密を提供しなければ、ボブの手付金はエスクロー・サービスによって払い戻され、契約は無効となる。
ご想像の通り、チャンはディナとの契約も変更することになった。
ディナは契約締結後20時間以内に秘密を明かさなければならない。もし、ディナがこの時間までに秘密を明かさなければ、チャンの手付金はエスクロー・サービスによって払い戻され、契約は無効となる。
このような契約の連鎖によって、24時間後に、アリス→ボブ→チャン→ディナの順に支払いが成功するか、失敗して全員に払い戻されるかが保証されるのである。契約が失敗するか成功するか、その中間はないのです。
ライトニングネットワークの文脈では、この「all or nothing」特性を原子性と呼んでいます。
エスクローが信頼に足るものであり、その義務を忠実に果たしている限り、その過程でコインを盗まれることはないのです。
この経路が機能する前提条件は、経路上のすべての関係者が、必要な一連の預金を満たすだけの資金を持っていることです。
これは些細なことのように思えるが、この要件が実はLNノードにとってより困難な問題の一つであることを、本章の後半で説明する。支払いの規模が大きくなるにつれて、徐々に難しくなる。さらに、当事者はエスクローにロックされている間、お金を使うことができない。
したがって、支払いを転送するユーザーは、お金をロックするための機会コストに直面し、これは最終的に、前述の例で見たように、ルーティング手数料によって弁済される。
物理的な支払いルーティングの例を見たので、これをサードパーティのエスクローを必要とせずにビットコインブロックチェーンに実装する方法を見ていきます。そのために、Bitcoin Scriptを使って参加者間のコントラクトをセットアップします。サードパーティーのエスクローを、公平性プロトコルを実装したスマートコントラクトに置き換えます。そのコンセプトを分解して、実装してみましょう
フェアネスプロトコル
本書の第1章で見たように、ビットコインの革新性は、暗号プリミティブを使って、第三者(仲介者)への信頼を信頼プロトコルに置き換えたフェアネスプロトコルを実装できることです。
金貨の例では、当事者のうち誰かが義務を放棄するのを防ぐためにエスクローサービスが必要でした。暗号化された公正プロトコルの革新的技術により、エスクローサービスをプロトコルに置き換えることができるようになりました。
私たちが作りたい公平性プロトコルの特性は
信頼性のない操作
ルート型決済の参加者は、お互いに、あるいは仲介者や第三者を信頼する必要はない。その代わり、参加者はプロトコルを信頼し、不正行為から身を守る。
原子性
決済が完全に実行されるか、失敗して全員が返金されるかのどちらかである。仲介者がルーティングされた支払いを回収し、次のホップに転送しない可能性はない。したがって、仲介者は不正行為や窃盗をすることができない。
マルチホップ
システムのセキュリティは、1つの支払いチャネルの両端間の支払いと同様に、複数の支払いチャネルを経由した支払いにもエンドツーエンドで拡張されます。
オプションで追加できる特性は、支払い全体の原子性を維持しながら、支払いを複数の部分に分割する能力である。これらはマルチパートペイメント(MPP)と呼ばれ、mppでさらに検討される。
アトミックトラストレスマルチホップペイメントの実装
ビットコインスクリプトは柔軟性が高いため、原子性、トラストレス操作、およびマルチホップ・セキュリティの特性を持つ公正プロトコルを実装する方法は多数あります。特定の実装を選択することは、プライバシー、効率、および複雑さの間の特定のトレードオフに依存します。
現在、ライトニングネットワークで使用されているルーティングの公正プロトコルは、ハッシュタイムロックコントラクト(HTLC)と呼ばれています。HTLCは、本章の金貨の例で見たように、支払いのロックを解除する秘密としてハッシュプリイメージを使用します。支払いの受け手は、ランダムな秘密番号を生成し、そのハッシュを計算する。ハッシュが支払いの条件となり、秘密が明かされると、すべての参加者は入ってきた支払いを換金することができる。HTLCはアトミック性、トラストレス動作、マルチホップ・セキュリティなどの特徴を備えている。
また、ルーティングを実現する仕組みとして、PTLC(Point Time-Locked Contract)が提案されています。PTLCもアトミティ、トラストレス、マルチホップ・セキュリティを実現するが、より効率的でプライバシーに配慮した実装となる。PTLCの効率的な実装は、シュナー署名と呼ばれる新しいデジタル署名アルゴリズムに依存しており、これは2021年にビットコインで有効化されると予想されています。
チップの例を見直す
この章の最初の部分に出てきた例をもう一度見てみましょう。アリスはディナにライトニング払いでチップを渡したいと思っています。アリスはディナに50,000サトシをチップとして送りたいとします。
アリスがディナに支払うには、アリスはディナのノードがライトニングの請求書を生成する必要があります。これについては、invoicesで詳しく説明します。ここでは、DinaがチップのLightningインボイスを作成できるウェブサイトを持っていると仮定します。
Lightningの支払いは、keysendという機能を使って請求書を発行せずに送ることができます。ここでは、よりシンプルな請求書を使った支払いフローを説明します。
アリスがDinaのサイトを訪問し、フォームに5万サトシの金額を入力すると、それに対してDinaのLightningノードがLightning請求書という形で5万サトシの支払い要求を生成します。このやりとりは、Alice requests an invoice from Dina's websiteに示すように、ウェブ上で、ライトニングネットワークの外で行われます。
https://scrapbox.io/files/631f101cda01fc0023328a96.png
図7. アリスがDinaのウェブサイトから請求書を要求する
前の例で見たように、アリスはDinaへの直接の支払いチャネルを持っていないと仮定する。代わりに、アリスはボブへのチャンネルを持ち、ボブはチャンへのチャンネルを持ち、チャンはディナへのチャンネルを持っている。Dinaに支払うために、アリスはDinaに接続する経路を見つけなければならない。そのステップについてはpath_findingで詳しく説明します。今のところ、アリスが利用可能なチャンネルについての情報を集め、 ボブやチャンを経由して自分からディナへのパスがあることを確認できたと仮定しましょう。
注意
Bob と Chan が自分たちのノードを経由して支払いをするために、 ちょっとした報酬を期待しているのを覚えていますか? アリスはDinaに50,000 satoshisを払いたいのですが、次のセクションで見るように、彼女はBobに50,200 satoshisを送ります。余分な200サトシは、ボブとチャンにそれぞれ100サトシをルーティングフィーとして支払う。
さて、アリスのノードはライトニングの支払いを構築することができます。次のセクションでは、アリスのノードがDinaに支払うためにHTLCを構築し、そのHTLCがアリスからDinaへの経路に沿ってどのように転送されるかについて見ていきます。
HTLCのオンチェーン決済とオフチェーン決済の比較
ライトニングネットワークの目的は、オフチェーン取引でもオンチェーン取引と同じように信頼されるようにすることで、誰も不正をすることができないからです。誰も不正できない理由は、参加者の誰もがいつでもオフチェーン取引をオンチェーンに持ち込むことができるからです。各オフチェーン取引は、いつでもビットコインブロックチェーンに提出できる状態になっています。このように、ビットコインのブロックチェーンは、必要に応じて紛争解決や最終決済のメカニズムとして機能するのです。
どんな取引でもいつでもオンチェーンに持ち込めるという事実だけで、まさにそれらの取引はすべてオフチェーンにしておくことができるのです。遡及権があることが分かっていれば、他の参加者と協力し続けることができ、オンチェーン決済や余分な手数料の必要性を回避することができるのです。
この後のすべての例では、これらの取引はいつでもオンチェーンで行えると仮定します。参加者はオフチェーンにすることを選択するが、取引のオンチェーン採掘によって高い手数料と遅延が発生する以外、システムの機能には何の違いもない。この例は、すべての取引がオンチェーンであってもオフチェーンであっても同じように機能する。
ハッシュタイムロックコントラクト
このセクションでは、HTLCがどのように機能するかを説明する。
HTLCの最初の部分はハッシュである。これは、暗号ハッシュ・アルゴリズムを使ってランダムに生成される秘密をコミットすることを指す。この秘密を知ることで、支払いの償還が可能になる。暗号ハッシュ関数は、誰もが秘密の前景を推測することは不可能だが、ハッシュを検証することは容易であり、支払い条件を解決する前景は1つだけであることを保証している。
アリスがディナから支払いのハッシュを受け取る場面では、アリスがディナからライトニングの請求書を受け取っているのがわかる。その請求書の中には、ディナが暗号化した支払いハッシュがあり、それはディナのノードが生成した秘密の暗号ハッシュである。Dinaの秘密は、支払いプリ画像と呼ばれています。支払いハッシュは、支払いをDinaにルーティングするために使用できる識別子として機能する。支払いプリ画像は、支払いが完了すると、領収書や支払い証明書として機能する。
https://scrapbox.io/files/631f10f9da01fc00233293ec.png
図8. アリスはディナから支払いハッシュを取得する
ライトニングネットワークでは、Dinaの支払いプリ画像はDinas secretのようなフレーズではなく、Dinaのノードで生成された乱数になります。その乱数をRと呼ぶことにする。
Dinaのノードは、Rの暗号ハッシュを次のように計算する。
H = SHA-256(R)
この式で、Hはハッシュまたは支払いハッシュであり、Rは秘密または支払いプリ画像である。
暗号ハッシュ関数の使用は、信頼性の高い運用を保証する一つの要素である。決済の仲介者は、誰も秘密を推測したり、偽造したりできないことを知っているので、お互いを信頼する必要がありません。
ビットコインスクリプトのHTLC
金貨の例では、アリスはこのようなエスクローで強制される契約をしていました。
アリスはボブに12枚の金貨を払い戻しますが、もしあなたが以下のハッシュを持つ有効なメッセージを示すことができれば、その金貨はボブに支払われます。0575...f6b3。ボブには、契約締結後24時間以内に秘密を提示する権利がある。もしボブがこの時間までに秘密を提示しなければ、アリスの預金はエスクローサービスによって払い戻され、契約は無効となる。
これをBitcoin ScriptでHTLCとして実装するとどうなるか見てみましょう。HTLC implemented in Bitcoin Script (BOLT 3)では、現在ライトニングネットワークで使われているHTLC Bitcoin Scriptを見ています。この定義は、BOLT 3 の Transactions に記載されています。
code:htlc
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
うわー、複雑そう でも心配しないでください、一歩ずつ簡略化していきます。
現在ライトニングネットワークで使われているビットコインスクリプトは、オンチェーンスペース効率に最適化されているため非常に複雑で、非常にコンパクトですが読みにくいものとなっています。
以下では、スクリプトの主要な要素に焦点を当て、実際にLightningで使用されているものとは若干異なる簡略化されたスクリプトを紹介することにします。
HTLCの主要部分は、HTLC implemented in Bitcoin Script (BOLT 3)の10行目にあります。ゼロから作り上げていきましょう
決済のプリ画像とハッシュ検証
HTLCの核となるのはハッシュで、受取人が支払い前画像を知っていれば支払いが可能です。アリスは支払いを特定の支払いハッシュにロックし、ボブは資金を請求するために支払いプリマージュを提示しなければなりません。ビットコインシステムは、ボブの支払画像が正しいことを、それをハッシュ化し、その結果をアリスが資金をロックするために使った支払ハッシュと比較することで検証できます。
HTLCのこの部分は、ビットコインスクリプトで以下のように実装することができます。
OP_SHA256 <H> OP_EQUAL
アリスは上記のロックスクリプトで50,200サトシを支払うトランザクション出力を作成することができる。<H>をDinaが提供したハッシュ値0575...f6b3に置き換える。それから、アリスはこの取引に署名し、ボブに提供することができる。
アリスは50,200satoshiのHTLCをBobに提供する。
OP_SHA256 0575...f6b3 OP_EQUAL
ボブはディナの秘密を知るまでこのHTLCを使うことができないので、HTLCを使うことはボブがディナへの支払いをすべて履行することが条件となる。
ボブがディナの秘密を知ったら、ボブは秘密のプリ画像値Rを含むロック解除スクリプトでこの出力を使うことができる。
ロック解除スクリプトとロックスクリプトを組み合わせると、次のような出力が得られる。
<R> OP_SHA256 <H> OP_EQUAL
ビットコインスクリプトエンジンは、このスクリプトを次のように評価します。
1. R はスタックにプッシュされます。
2. OP_SHA256演算子はスタックから値Rを取り出し、それをハッシュ化し、その結果H~R~をスタックにプッシュします。
3. H がスタックにプッシュされる。
4. OP_EQUAL 演算子は H と H~R~ を比較します。それらが等しい場合、結果は TRUE となり、スクリプトは完了し、支払いは確認される。
アリスからディナへのHTLCの延長
Alice は次に Dina に到達するように HTLC をネットワーク全体に拡張します。
HTLCのネットワークへの伝播では、アリスからディナまでネットワークに伝搬されたHTLCを見ることができます。アリスはボブに50,200satoshiのHTLCを渡しました。ボブは50,100サトシのHTLCを作り、それをChanに渡すことができる。
ボブは、チャンがシークレットをブロードキャストしなければボブのHTLCを換金できないことを知っており、その時点でボブはアリスのHTLCを換金するためにシークレットを使用することができる。これは、HTLCのエンドツーエンドの原子性を保証するため、本当に重要なポイントである。HTLCを使用するために、ある人は秘密を明かす必要があり、それによって他の人も自分のHTLCを使用することが可能になる。すべての HTLC が使用可能であるか、どの HTLC も使用不可能であるかのどちらかである。
アリスのHTLCはボブがチャンに渡したHTLCより100サトシ多いので、この支払いが完了すればボブはルーティングフィーとして100サトシを獲得することになる。
ボブはリスクを取らず、アリスやチャンを信用しない。その代わり、Bobは署名された取引と秘密がビットコインのブロックチェーン上で換金可能であることを信頼しているのである。
https://scrapbox.io/files/631f1233c0dad8001d1ee271.png
図 9. HTLCをネットワークに伝搬させる
同様に,ChanはDinaに50,000 HTLCを拡張することができる.彼は何も危険を冒していないし、BobやDinaを信頼しているわけでもない。HTLCを償還するために、Dinaは秘密をブロードキャストしなければならず、Chanはそれを使ってBobのHTLCを償還することができる。また、Chanはルーティング料として100サトシを得ることになる。
秘密のバックプロパゲーション
DinaがChanから50,000 HTLCを受け取ると、今度は報酬を得ることができる。Dinaは単純にこのHTLCをオンチェーンでコミットし、支出のトランザクションで秘密を明かせばそれを使うことができる。あるいは、DinaはChanに秘密を教えることで、Chanとのチャンネル残高を更新することができる。取引手数料を負担してまでオンチェーンに移行する理由はない。そこで、代わりにDinaはChanに秘密を送り、2人はDinaへの5万サトシのライトニング支払いを反映させるためにチャンネル残高を更新することに同意します。Dina settles Chan's HTLC off-chain には、Dina が Chan に秘密を渡し、それによって HTLC を達成したことが示されている。
https://scrapbox.io/files/631f12ecfa35710021255608.png
図10. DinaがChanのHTLCをオフチェーンで決済。
Dinaのチャンネル残高が5万サトシから10万サトシになったことに注目してください。Chanのチャネル残高は200,000 satoshiから150,000 satoshiに減少しています。チャネルの容量は変わっていませんが、5万がChanのチャネル側からDinaのチャネル側に移動しています。
Chanは今、秘密を手に入れ、Dinaに5万サトシを支払いました。なぜなら、この秘密によって、ChanはBobから50,100 HTLCを受け取ることができるからである。Chanには、そのHTLCをオンチェーンでコミットし、ビットコインブロックチェーン上で秘密を明かすことでそれを使うという選択肢がある。しかし、Dinaと同様、彼は取引手数料を避けたいと考えている。そこで、彼はその秘密をボブに送り、ボブからチャンへの50,100サトシのライトニング支払いを反映させるため、両者のチャンネル残高を更新させる。ChanがBobのHTLCをオフチェーンで決済する場面では、ChanがBobに秘密を送り、その見返りとして支払いを受けているのがわかる。
https://scrapbox.io/files/631f131f020dee001d68a032.png
図11. ChanはBobのHTLCをオフチェーンで決済する。
ChanはDinaに50,000 satoshiを支払い、Bobから50,100 satoshiを受け取りました。つまり、Chanのチャンネル残高は100サトシ増えており、これはルーティングフィーとして獲得したものである。
ボブも今、秘密を持っています。彼はそれを使ってアリスのHTLCをオンチェーンで使うことができる。あるいは、アリスとのチャネルでHTLCを決済することで、取引手数料を避けることができる。ボブがアリスのHTLCをオフチェーンで決済する場合、ボブはアリスに秘密を送り、彼らはアリスからボブへの50,200 satoshiライトニング支払いを反映するためにチャンネル残高を更新することがわかる。
https://scrapbox.io/files/631f134867c538001f918ec0.png
図12. ボブがアリスのHTLCをオフチェーンで決済
BobはAliceから50,200 satoshiを受け取り、Chanに50,100 satoshiを支払ったので、彼のチャンネル残高にはルーティングフィーから100 satoshiが追加された状態になっている。
アリスは秘密を受け取り、50,200satoshiのHTLCを決済した。このシークレットは、Dinaがその特定の支払いハッシュに対して支払いを受けたことを証明する領収書として使用することができる。
最終的なチャンネル残高には、AliceからDinaへの支払いと、各ホップで支払われたルーティングフィーが反映されています。(支払後のチャンネル残高に示すとおりです。
https://scrapbox.io/files/631f135b22ef4c0023759034.png
図13. 支払い後のチャンネル残高