Lightning Network In Depth、パート2：HTLCと支払いルーティング

前回の記事では、支払いチャネルの作業と、それらを通過する支払いのセキュリティを確保するためのいくつかの異なる方法について詳細に説明しましたが、それでもチャンネルの有効なネットワークを構築するには十分ではありません。正直なところ、多くのチャネルを介したチェーンを通じた資金の配信を保証することはできません。 ここで、HTLC（hash-time-lock-contracts）と呼ばれるスマートコントラクトが役立ちます。 この記事では、彼らの仕事の原理を分析し、Lightningネットワークでどのように支払いが行われるかを示します。

目次

• HTLC
• ライトニングネットワークの例
• 障害のクリア
• 転送プロトコル
• 利点とユースケース
• おわりに
• リンク集

ハッシュタイムロックコントラクト（HTLC）

HTLC契約はシンプルですが、特定の「有効期限」のある支払いを作成できる非常に効果的な設計です。 おそらく既に推測したように、htlcコントラクトは2つの部分で構成されます：ハッシュチェックと特定の時間の有効期限のチェック。

ハッシュから分析を始めましょう。 HTLC支払いを作成するには、最初に秘密の Rを作成し、次にそのハッシュを計算する必要があります。 何でもシークレットとして機能できます-数字または単語、いずれの場合でも、それは単なるバイトのセットです。

H = Hash(R)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このハッシュHはロックスクリプトに含まれます。 したがって、Hによってハッシュが取得された秘密を知っている人だけが支払いを使用できます秘密Rはプリイメージとも呼ばれます。

htlc契約の2番目の部分は、支払いブロック時間の有効期限の確認です。 秘密が時間内に明らかにされず、支払いが使用されなかった場合、送信者はすべての資金を自分に返すことができます。

特定の人を対象としたHTLC支払いの例を考えてみましょう。

 # check if secret R is preimage of H HASH160 <H> EQUAL IF # check if person, who revealed secret is intended payee <Payee Public key> CHECKSIG ELSE # check if time-lock is ended <locktime> CHECKLOCKTIMEVERIFY # check that person that requested refund is original payer <Payer Public Key> CHECKSIG ENDIF
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ハッシュHのプロトタイプである正しいシークレットRを提供する場合、IFストリームに入ります。そこでさらにチェックが行われます。シークレットRを見つけた人が本当に支払いの対象者であるかどうか。 この支払いを使用するには、受信者はかなり単純なロック解除スクリプトを提供する必要があります。

 <sig> <secret R>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

提供されたシークレットRが正しくない場合、ELSEストリームに入り、割り当てられた時間が経過したかどうかが最初にチェックされ、経過した場合、支払いを送信するとすべての資金が返されます。 ELSEストリームに入るために間違ったシークレットを明示的に指定する必要があることを除いて、払い戻しのロック解除スクリプトは同じです。

 <sig> <wrong secret>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、これはHTLC契約の非常に基本的な実装であり、定期的なタイムロック支払いです。 スクリプトに任意の数の異なる条件を追加できます。たとえば、IFストリームの公開キーを削除することにより、シークレットを知っているすべての人が支払いを利用できるようにしたり、単一の署名を要求したり、multisigなどのように複数の署名を要求したりできます。

Psここでは、 CHECKLOCKTIMEVERIFYオペコードを使用しました 。これは、ロック時間を設定するために絶対値を使用します。たとえば、「この出力は＃546212のブロックに使用できません」。 それに加えて、Lightning Networkは別のより柔軟なオプションCHECKSEQUENCEVERIFYも使用し、ブロック時間を相対的に設定します。つまり、このオプションは可能です。「この出力は、トランザクションがネットワークに送信されてから1000ブロックが経過するまで使用できません。 」 。

ライトニングネットワークの例

最終的にすべてのコンポーネントを分解したので、全体像、つまりLightningネットワークの仕組みを見てみましょう。 この例では、5人の参加者がいます。アリス、ボブ、キャロル、ダイアナ、エリックは、各チャンネルで2つのビットコインの残高を持ち、当事者の1人であるお互いにオープンな支払いチャンネルを持っています。 したがって、チャネルのチェーンを使用して、アリスからエリックへの支払いを試みます。

アリスがErica 1ビットコインを転送したいとします。 ただし、ご覧のとおり、これらはチャネルによって直接接続されておらず、新しいチャネルを開くには時間とお金がかかります。 幸いなことに、アリスはLightningネットワークに接続されており、一連のHTLC契約を使用して間接的な支払いを行うことができます。 これがどのように起こるかのステップを見てみましょう。

1. エリックは秘密のRを作成し、ハッシュをアリスに渡します（彼は誰にも秘密を見せません）。
2. アリスは、1.003の量で事前に10ブロックのこのロックを使用してHTLCを作成します。 追加の0.003は、チェーンに参加した中間メンバーへの報酬として使用されます。 したがって、アリスはHTLCの1.003 BTC残高を次のルールでロックします。「アリスは、10ブロック以内に秘密の Rを知るとボブ1.003ビットコインを支払います。そうでなければ、資金はアリスに戻ります。」 チャネルバランスは、コミットトランザクションによって変更され、現在、ボブの2 BTC、アリスの0.997、HTLCでロックされた1.003を表しています。
3. ボブは、アリスのコミットトランザクション（それらの間のチャネルに送信されたHTLC）を手に入れて、彼とキャロルの間のチャネルに、1.002 BTCの量のHTLCを作成し、9ブロック先にロックします。 その際、彼はアリスが使用したのと同じハッシュを使用します。 ボブは、キャロルが送信したHTLCのロックを解除するためにRの秘密を見つける必要があることを知っており、キャロルはすぐに彼を認識します。つまり、アリスが送信した1.003 BTCのロックを解除できます。 キャロルがRを見つけられない場合、ボブとアリスの資金は、ロックの有効期限が切れた後、単に彼らに戻ります。 また、ボブが送った金額は、受け取った金額よりも0.001少ないことに注意してください。これは、ボブがチェーンに参加するために取った手数料です。 ボブとキャロルの間のチャネルバランスは、キャロルが2 BTC、ボブが0.998 BTC、HTLCでロックされた1.002 BTCになりました。
4. ボブのコミットトランザクションを受け取ったキャロルは、1.001 BTCの量でダイアナとのチャネルに（ボブが使用するハッシュを使用して）HTLCを作成し、8ブロックでブロックされます。 ダイアナが8ブロックのRシークレットを見つけてHTLCをアンロックして1.001 BTCを取得できる場合、キャロルはシークレットも見つけます。つまり、ボブから送られた1.002 BTCをアンロックして0.001 BTCを獲得できます。 キャロルとダイアナのチャンネルバランスは現在：2ダイアナのBTC、キャロルの0.999 BTC、1.001 BTCはHTLCでロックされています。
5. 最後に、ダイアナは1 BTCの量で7ブロックのロックでHTLC（すべて同じハッシュを使用）を彼女のチャネルに送信します。 現在、チャネルのバランスは、Ericが2 BTC、Dianaが1 BTC、HTLCでロックされている1 BTCです。
6. これで、チェーンの終わりに到達しました。 Ericは、すべてのHTLCコミットトランザクションでハッシュが使用されたシークレットRを持っているため、Dianaから送信されたHTLCのロックを解除し、1 BTCを取得できます。 エリックは、秘密を使用して資金を受け取るとすぐに、それをダイアナに明らかにします。 現在、エリックとダイアナのチャンネルバランスは、エリックが3 BTC、ダイアナが1 BTCです。
7. 秘密を受け取ったダイアナは、キャロルによって送信された1.001 BTCのロックを解除し、それによって秘密を彼女に明らかにします。 現在のチャネルバランスは、ダイアナでは3.001 BTC、キャロルでは0.999 BTCです。
8. 秘密を受け取ったキャロルは、ボブから送信された1.002 BTCのロックを解除し、秘密を明らかにします。 それらの間のチャネルバランスは、キャロルでは3.002 BTC、ボブでは0.998です。
9. 最後のステップで、ボブはシークレットを使用して彼とアリスの間のチャネルで1.003 BTCをシークレットにします。 現在のチャネルバランスは、ボブが3.003 BTC、アリスが0.997です。

したがって、アリスは彼らの間に新しいチャンネルを開くことなくエリック1 BTCを支払いました。 チェーンの参加者は誰もお互いを信頼する義務がなく、「仲介者」としてのサービスを提供するために、0.001 BTCのコミッションを獲得しました。 チェーンの誰かが自分の役割を果たせなかった場合、誰も資金を失うことはなく、一時的に（ブロックの時点で）凍結するだけです。

障害のクリア

この例では、すべてが順調に進みましたが、実際にはすべてがマーフィーの法則に従います。何かが破れた場合はそうなるので、Lightning Networkの「保護」メカニズムの動作を分析しましょう。

明らかに、資金が配信されるチェーンが長いほど、資金が最後に到達しない可能性が高くなります。一部の参加者はチャネルを閉じることができ、一部は単にインターネットを切断できます。 何かがうまくいかなかったイベントには2つのオプションを検討してください。

壊れたチャンネル

最初のケースでは、資金がチェーンの最後に正常に到達したが、反対の経路（シークレットがチェーンの最初に戻る必要がある場合）で問題が発生しました-参加者の1人が拒否したか、協力できませんでした-この例では、これはボブです。

チェーンが彼女に届くとすぐに、ダイアナはすぐに秘密を使ってお金を取り、同時にそれをキャロルに明らかにします。 キャロルもボブからお金を受け取りたいと思っていますが、彼は答えないので、リスクを避けるために、チャネルの最後のコミットトランザクション（先にボブが送信したHTLC契約）をブロックチェーンに送信し、シークレットを使用して資金を受け取ります。 この場合、ボブはまだ連絡を取ってアリスからお金を集めるために3日間あります（トランザクションがブロックチェーンに行ったので、彼はそれを簡単に見つけてRを見ることができます）、そうでなければ、この期間の後、彼女はすべてを返すことができます自己資金。

ご覧のとおり、この場合、チェーンの参加者の1人が何らかの理由で失敗した場合、彼だけがお金を失うことができ、残りはすべて安全です。

再ルート

2番目のケースでは、参加者の1人が操作不能であるために、資金がチェーンの最後に達していない状況を考慮します。 今ではキャロルです。

最初の最も明白な方法は、HTLC契約のブロック時間が終了するまで待つことです。資金を返して新しい支払いを送信することができます。

しかし、アリスが急いでいる場合はどうでしょうか？ もちろん、資金が戻って別のチェーンで既に1回の支払いを送信するまで待つことはできませんが、キャロルが突然戻った場合、彼はボブに連絡してチェーンを終了しますか？ この場合、アリスは2倍の金額を送ります。

本当に、操作が失敗するたびに、新しい操作を送信する前に待たなければならないのですか？ 幸いなことに、ロックが終了するまで待たないために、以前の支払いを「リセット」できます。 これを行うには、Diana（資金の受取人）は、初回と同じハッシュを使用して、相当額の支払いをAliceに送信する必要があり、チェーンはまったく同じであってはなりません。 今、キャロルが戻って仕事の彼女の部分を完了すると、お金はただ行き来します。 したがって、失敗した支払いはキャンセルされたと見なされ、別のチェーンを通じて穏やかに新しい支払いを送信できます。

支払額

アリスが最初の支払いを「キャンセル」し、新しい支払いを送信できるようになったとしても、資金がそこで凍結されているという事実は変わらず、彼女は操作を繰り返すのに十分なお金がないかもしれないので、Lightning Networkに送信することをお勧めします1つのHTLCに少量。 コミットトランザクションはブロックチェーンを「ヒット」しないため、金額を非常に小さな部分に分割できます。 したがって、チェーンが機能しなくなるとすぐに、最後に送信された支払いのごく一部のみが凍結されたままになります。

転送プロトコル

また、Lightning Networkの非常に重要な特性に言及する価値があります。支払いチェーンに関するすべての情報は完全に匿名です。 これは、チェーンの各参加者が自分の「サイト」についてのみ知っていることを意味します。たとえば、キャロルの場合、支払いはボブからダイアナへの送金のように見えますが、ボブがアリスからお金を受け取ったこと、またはダイアナがさらに送金する必要があることを知りませんエリックへのお金。

Lightningは、 Sphinxメッセージ暗号化プロトコルを使用して、そのようなメッセージをパッケージ化します。 これを使用して、Aliceはチェーンの各セクションを暗号化の「レイヤー」でラップし、チェーンの最後から開始します。 彼女は、公開キーを使用してエリックのメッセージを暗号化します。 このメッセージは、Dianaのメッセージに含まれています。Dianaのキーで暗号化され、DianaのメッセージはCarolのメッセージに含まれ、対応するキーで再び暗号化され、チェーンの最初まで続きます。 したがって、ボブは自分宛てのメッセージの最上位層のみを復号化でき、キャロルなどにメッセージを送信します。各段階で、必要な情報のみが送信されます：送信する資金の量、手数料の量、ブロック時間など。

また、メッセージの重みによってチェーンの長さを推測できないようにするために、20人がチェーンに参加しているように、メッセージのサイズは常に固定されています。 最後の参加者を除く各参加者は、同じサイズのメッセージを見て、さらに20人の参加者がいると考えます。

利点とユースケース

もちろん、多くの人が考えるように、Lightning Networkの利点はビットコインのスケーリングだけに限定されません。 Lightningが提供するいくつかの機会を見てみましょう。

• インスタントトランザクション 。 照明を使用すると、トランザクションはほとんど瞬時に行われます。 これにより、ビットコインでコーヒー代を支払うことが可能になります。
• 仲裁 現時点では、取引を確認するために3〜6ブロックが必要なため、ある取引所から別の取引所への迅速な送金は不可能です。 取引所が稲妻を使用している場合、ユーザーは即座に資金を転送できるため、裁定取引が可能になります。 また、取引所は、資金を保管するために「コールド」ウォレットを保持する必要がないため、盗難の可能性が大幅に減少します。
• マイクロペイメント 。 ビットコインの取引手数料が高すぎるため、少額の支払いができません。 誰かが同じまたはそれ以下を転送するために0.001を支払うことを望む可能性は低いです。 Lightningを使用すると、任意の金額を即座に転送できるため、たとえばメガバイト単位でオンラインで支払うことができます。
• 金融スマート契約およびトランザクション 。 金融契約は特に時間に敏感であり、多くの場合、多くの計算が必要です。 それらのほとんどを「外に出す」ことで、ブロックチェーンに書き込むことなく、非常に複雑なトランザクションと契約を作成する機会が得られます。
• クロスチェーン支払い 。 異なるコンセンサスルールを持つブロックチェーンに同様のハッシュ関数がある場合、それらの間でトランザクションを実行することが可能です。 同時に、参加者はお互いを信頼したり、仲介者を使用したりする必要はありません。
• プライバシー 支払いが行われているチェーンの参加者は送信者または受信者を見ることができないため、Lightningのトランザクションはビットコインブロックチェーンよりもはるかに匿名です。

おわりに

これで、Lightning Networkの分析を終了します。 次の記事では、HTLCコントラクトを使用してビットコインとライトコイン間のクロスチェーンアトミックスワップを使用する方法について説明します。

リンク集

• Lightning Networkパート1：支払いチャネル
• 「ビットコインをマスターする」-アンドレアス・M・アントノプロス
• ライトニングネットワークホワイトペーパー
• ダミーの隔離された証人