著者: Viktor Bunin、Coinbase クラウド プロトコル エキスパート コンパイラー: Qianwen、ChainCatcherしばらくLightning（後のLightning Network）を使っていませんでした。最後にこの作業に時間を費やしたのは 2019 年で、エリザベス スタークや他のコミュニティ リーダーと協力してベルリンで最初のライトニング ネットワーク カンファレンスを開催しました。それ以来、私は他のプロトコルの作業にほとんどの時間を費やしており、エリザベスのような人々とは今でも友達ですが、ライトニング ネットワークが実際にどのように機能するかについての理解は低下しています。改めて調べてみると、それは私だけではなく、ほとんどの友達も同様であることがわかりました。この記事は、ライトニング ネットワークを最近使用していない人向けです。私や私が見た他の人たちの誤解について議論します。何か良い点を見逃した場合は、Twitter に連絡してください。#### **誤解 1: ライトニング ネットワークを無制限に使用するには、独自のノードを実行する必要があるため、一般のユーザーはモバイル デバイスを使用できません。 **これは数年前には当てはまりましたが、現在ではユーザーはアンマネージド ライト クライアントを通じてモバイル デバイス上で Lightning Network を使用できるようになりました。ユーザーは常に自分のキーを管理しており、Lightning Light Client でのウォレット エクスペリエンスは、Ethereum を使用するときに RPC 経由で Alchemy または Infura を呼び出すのと同じです。#### **誤解 2: Lightning 支払いを成功させるには、送信者と受信者が同時にオンラインである必要があります (オフライン/同期支払いは不可)。 **この状況は依然として存在しますが、いくつかの優れた回避策があります。非保管型 Lightning モバイルウォレットは、ウォレットがフォアグラウンドで実行されていない場合でも、バックグラウンドタスクまたは電話通知を通じて支払いを受け取ることができます。ただし、このアプローチはモバイル オペレーティング システムによって制限されます。最新のオペレーティング システムでは、バッテリーを節約するためにバックグラウンド アプリによる計算量が制限されています。数回の LN 支払いを受け取るのは問題ありませんが、短期間にあまりに多くの LN 支払いを受け取ると、計算上の制約により有効期限が切れ始めます。長期的には、Lightning Network プロトコルの開発者は、任意の長さのトラストレス レイテンシーを可能にする Async Payments 仕様に取り組んでいます。基本的に、支払いは送信者のノードから入金されますが、受信者のノードがオフラインになった場合、支払いは受信者がオンラインに戻るまで送信者の LSP (ライトニング ネットワーク/流動性サービス プロバイダー、通常はウォレット自体によって実行されます) に残ります。 ** このアップグレードは来年行われる予定ですが、正式な開始日はまだありません。 **ただし、これには参加しているウォレットに LSP が含まれている必要があり、ネットワーク全体のソリューションとしての採用が妨げられる可能性があります。#### **誤解 3: ライトニング ネットワークでは、チャネルを開くには、両方のユーザーが同じ量の BTC をチャネルに投資する必要があります。 **これは当てはまりません。ほとんどの Lightning Network クライアントでは、チャネルはデフォルトで一方向に開かれているため、送信者のみがチャネルに資金を投資する必要があり、受取人はまったく新しい空のアドレスにすることができます。この誤解は、例で一貫して双方向の資金調達チャネルに言及しているライトニング ネットワーク ホワイト ペーパーに由来しています。実はこれは興味深い裏話に基づいているんです。初期の支払いチャネル (Spilman) では、一方向の支払いのみが許可されていました。ライトニング ネットワークの革新性は、二重資金と双方向支払いの実現にあり、チャネルには有効期限がありません。おそらくこれが、Lightning Network の論文でこれほど焦点が当てられている理由です。これは、当時知られていたプロトコル設計と比較して重要な発明でした。#### **誤解 4: ライトニング ネットワークでは、ユーザーは特定の単一目的の請求書を指定する必要があり、これはひどいユーザー エクスペリエンスです。 **確かに最初はそうでした。しかし、Lightning Network アドレスを使用すると、基本的には Lightning Network の ENS になります。これらは lnurl-pay によって有効になり、ユーザーは金額や期間に関係なく、Lightning Network 経由で BTC を viktor@example.com に送信できるようになります。#### **誤解 5: ユーザーは BTC を送金する際、ビットコインとライトニング ネットワークを理解して選択する必要があります。 **以前もそうだったはずだ。しかし、今は違います。現在では、オンチェーンのアドレスとライトニングネットワークの請求書をきちんとバンドルする統合 QR コードがあり、送信側ウォレットが正しいルートを選択できるようになりました。 CashApp を開き、[ビットコイン] タブに移動します。 Cash App は Lightning Network をサポートしていますが、Lightning Network を選択するオプションがないことに注意してください。統一されたQRコードを使用しているためです。ただし、これは単一残高の問題を解決するものではありません。ユーザーの BTC 残高は依然としてオンチェーンで分割され、ライトニング ネットワークに送られる可能性があります。この問題は、サブマリンスワップやスプライシングによってある程度解決できますが、私の長期的な見方では、ユーザーはこれが問題であることさえ認識せず、ウォレットや他のベンダーが処理するためにライトニングネットワークが存在することにも気づかないでしょう。スムーズなユーザー エクスペリエンスの下に隠れている根本的な複雑さ。#### **誤解 #6: ライトニング ネットワークは資本効率が悪く、したがって実行不可能です。 **この議論はデリケートなものなので、私はできる限り中立でいようと思います。ライトニング ネットワークはハブアンドスポーク モデルを使用します。ネットワークのハブ間部分は、取引所、保管ウォレット、LSP、最適なルーティング ノード間の大規模チャネルの「ユニットあたりの資本配分」比率が高いため、資本効率が非常に高くなります。ただし、ライトニング ネットワークの資本の非効率性はエッジ、つまり非管理ユーザーにあります。保管用の Lightning ユーザーの場合、ウォレットは他のハブとの大規模なチャネルを維持し、ユーザー残高の内部会計を実行するだけで済みます。非保管ユーザーの場合、ウォレットはユーザーごとに個別のオープンな資金調達チャネルを維持する必要があります。課題は、これらのチャネル全体で継続的な流動性の配分と管理をどのように維持するかです。具体的な例を挙げると、非保管ウォレット ユーザーがライトニング ネットワーク経由で友人に 0.1 BTC を送信したいと考えています。ウォレットプロバイダーと途中のすべてのノードとの間のチャネルに十分な流動性があると仮定すると、支払いは成功します。しかし、現在、ウォレットには問題があります。ウォレット側のチャネルに 0.1 BTC があり、ユーザーが支払いを受け取らない場合 (チャネルのバランスが再調整される)、この 0.1 BTC はそこでアイドル状態になり、ウォレット プロバイダーの効率が低下します。この時点で、ウォレットプロバイダーは、流動性を維持するか、チャネルを閉じる（ユーザーエクスペリエンスが低下する）かチャネルを接合する（ユーザーには見えない）ことで流動性を引き出すかを決定する必要があります。非保管ユーザーにとって、この限界資本の非効率問題は非常に厄介な最適化問題であり、取引の規模にかかわらず、客観的には口座ベースのモデルよりも悪い問題です。ただし、これは解決できない問題ではありません。不可能でない限り、成功する必要があります。これはビットコイン開発者コミュニティのモットーでもあります。資本の最適化の難しさに加えて、すべてのスプライシングやチャネルの閉鎖などにはオンチェーントランザクションが必要となるため、チャネルと流動性の管理に関連するコストからも別の課題が生じます。ビットコインのセキュリティ予算は取引手数料の大幅な増加に依存していますが、取引手数料が30ドルから60ドルに上昇すると、大規模なチャネル管理には法外なコストがかかり、管理されていないライトニングネットワークを世界人口の大部分が利用できなくなる可能性があります。ホスト型 Lightning ウォレットは現在、組み込まれたインセンティブにより有利ですが、オムニバス アカウント モデルによりチャネル管理の頻度がはるかに低くなるため、オンチェーン手数料が増加するにつれてさらに成長する可能性があります。コミュニティはこの問題を修正し、保管されていない Lightning ウォレットがネットワーク上で引き続き第一級の存在であり続けることを保証するために懸命に取り組んでいますが、明確な解決策はまだありません。Lightning Network がシンプルでシームレス、完全に抽象化されるまでには、まだ長い道のりがあります。エッジケースはまだ多く、管理されていないユーザーはまだ究極のユーザー エクスペリエンスを享受できていません。しかし、多くの問題はすでに解決されており、今後数年間でさらに多くの問題が解決されるでしょう。稲妻が来たので、雷ははるか遠くにあるでしょうか？
ビットコインのライトニングネットワークに関する6つの誤解を明らかにする
著者: Viktor Bunin、Coinbase クラウド プロトコル エキスパート コンパイラー: Qianwen、ChainCatcher
しばらくLightning（後のLightning Network）を使っていませんでした。
最後にこの作業に時間を費やしたのは 2019 年で、エリザベス スタークや他のコミュニティ リーダーと協力してベルリンで最初のライトニング ネットワーク カンファレンスを開催しました。それ以来、私は他のプロトコルの作業にほとんどの時間を費やしており、エリザベスのような人々とは今でも友達ですが、ライトニング ネットワークが実際にどのように機能するかについての理解は低下しています。改めて調べてみると、それは私だけではなく、ほとんどの友達も同様であることがわかりました。
この記事は、ライトニング ネットワークを最近使用していない人向けです。私や私が見た他の人たちの誤解について議論します。何か良い点を見逃した場合は、Twitter に連絡してください。
**誤解 1: ライトニング ネットワークを無制限に使用するには、独自のノードを実行する必要があるため、一般のユーザーはモバイル デバイスを使用できません。 **
これは数年前には当てはまりましたが、現在ではユーザーはアンマネージド ライト クライアントを通じてモバイル デバイス上で Lightning Network を使用できるようになりました。ユーザーは常に自分のキーを管理しており、Lightning Light Client でのウォレット エクスペリエンスは、Ethereum を使用するときに RPC 経由で Alchemy または Infura を呼び出すのと同じです。
**誤解 2: Lightning 支払いを成功させるには、送信者と受信者が同時にオンラインである必要があります (オフライン/同期支払いは不可)。 **
この状況は依然として存在しますが、いくつかの優れた回避策があります。非保管型 Lightning モバイルウォレットは、ウォレットがフォアグラウンドで実行されていない場合でも、バックグラウンドタスクまたは電話通知を通じて支払いを受け取ることができます。ただし、このアプローチはモバイル オペレーティング システムによって制限されます。最新のオペレーティング システムでは、バッテリーを節約するためにバックグラウンド アプリによる計算量が制限されています。数回の LN 支払いを受け取るのは問題ありませんが、短期間にあまりに多くの LN 支払いを受け取ると、計算上の制約により有効期限が切れ始めます。
長期的には、Lightning Network プロトコルの開発者は、任意の長さのトラストレス レイテンシーを可能にする Async Payments 仕様に取り組んでいます。基本的に、支払いは送信者のノードから入金されますが、受信者のノードがオフラインになった場合、支払いは受信者がオンラインに戻るまで送信者の LSP (ライトニング ネットワーク/流動性サービス プロバイダー、通常はウォレット自体によって実行されます) に残ります。 ** このアップグレードは来年行われる予定ですが、正式な開始日はまだありません。 **ただし、これには参加しているウォレットに LSP が含まれている必要があり、ネットワーク全体のソリューションとしての採用が妨げられる可能性があります。
**誤解 3: ライトニング ネットワークでは、チャネルを開くには、両方のユーザーが同じ量の BTC をチャネルに投資する必要があります。 **
これは当てはまりません。ほとんどの Lightning Network クライアントでは、チャネルはデフォルトで一方向に開かれているため、送信者のみがチャネルに資金を投資する必要があり、受取人はまったく新しい空のアドレスにすることができます。この誤解は、例で一貫して双方向の資金調達チャネルに言及しているライトニング ネットワーク ホワイト ペーパーに由来しています。
実はこれは興味深い裏話に基づいているんです。初期の支払いチャネル (Spilman) では、一方向の支払いのみが許可されていました。ライトニング ネットワークの革新性は、二重資金と双方向支払いの実現にあり、チャネルには有効期限がありません。おそらくこれが、Lightning Network の論文でこれほど焦点が当てられている理由です。これは、当時知られていたプロトコル設計と比較して重要な発明でした。
**誤解 4: ライトニング ネットワークでは、ユーザーは特定の単一目的の請求書を指定する必要があり、これはひどいユーザー エクスペリエンスです。 **
確かに最初はそうでした。しかし、Lightning Network アドレスを使用すると、基本的には Lightning Network の ENS になります。これらは lnurl-pay によって有効になり、ユーザーは金額や期間に関係なく、Lightning Network 経由で BTC を viktor@example.com に送信できるようになります。
**誤解 5: ユーザーは BTC を送金する際、ビットコインとライトニング ネットワークを理解して選択する必要があります。 **
以前もそうだったはずだ。しかし、今は違います。現在では、オンチェーンのアドレスとライトニングネットワークの請求書をきちんとバンドルする統合 QR コードがあり、送信側ウォレットが正しいルートを選択できるようになりました。 CashApp を開き、[ビットコイン] タブに移動します。 Cash App は Lightning Network をサポートしていますが、Lightning Network を選択するオプションがないことに注意してください。統一されたQRコードを使用しているためです。
ただし、これは単一残高の問題を解決するものではありません。ユーザーの BTC 残高は依然としてオンチェーンで分割され、ライトニング ネットワークに送られる可能性があります。この問題は、サブマリンスワップやスプライシングによってある程度解決できますが、私の長期的な見方では、ユーザーはこれが問題であることさえ認識せず、ウォレットや他のベンダーが処理するためにライトニングネットワークが存在することにも気づかないでしょう。スムーズなユーザー エクスペリエンスの下に隠れている根本的な複雑さ。
**誤解 #6: ライトニング ネットワークは資本効率が悪く、したがって実行不可能です。 **
この議論はデリケートなものなので、私はできる限り中立でいようと思います。
ライトニング ネットワークはハブアンドスポーク モデルを使用します。ネットワークのハブ間部分は、取引所、保管ウォレット、LSP、最適なルーティング ノード間の大規模チャネルの「ユニットあたりの資本配分」比率が高いため、資本効率が非常に高くなります。
ただし、ライトニング ネットワークの資本の非効率性はエッジ、つまり非管理ユーザーにあります。保管用の Lightning ユーザーの場合、ウォレットは他のハブとの大規模なチャネルを維持し、ユーザー残高の内部会計を実行するだけで済みます。非保管ユーザーの場合、ウォレットはユーザーごとに個別のオープンな資金調達チャネルを維持する必要があります。課題は、これらのチャネル全体で継続的な流動性の配分と管理をどのように維持するかです。
具体的な例を挙げると、非保管ウォレット ユーザーがライトニング ネットワーク経由で友人に 0.1 BTC を送信したいと考えています。ウォレットプロバイダーと途中のすべてのノードとの間のチャネルに十分な流動性があると仮定すると、支払いは成功します。しかし、現在、ウォレットには問題があります。ウォレット側のチャネルに 0.1 BTC があり、ユーザーが支払いを受け取らない場合 (チャネルのバランスが再調整される)、この 0.1 BTC はそこでアイドル状態になり、ウォレット プロバイダーの効率が低下します。この時点で、ウォレットプロバイダーは、流動性を維持するか、チャネルを閉じる（ユーザーエクスペリエンスが低下する）かチャネルを接合する（ユーザーには見えない）ことで流動性を引き出すかを決定する必要があります。
非保管ユーザーにとって、この限界資本の非効率問題は非常に厄介な最適化問題であり、取引の規模にかかわらず、客観的には口座ベースのモデルよりも悪い問題です。ただし、これは解決できない問題ではありません。不可能でない限り、成功する必要があります。これはビットコイン開発者コミュニティのモットーでもあります。
資本の最適化の難しさに加えて、すべてのスプライシングやチャネルの閉鎖などにはオンチェーントランザクションが必要となるため、チャネルと流動性の管理に関連するコストからも別の課題が生じます。ビットコインのセキュリティ予算は取引手数料の大幅な増加に依存していますが、取引手数料が30ドルから60ドルに上昇すると、大規模なチャネル管理には法外なコストがかかり、管理されていないライトニングネットワークを世界人口の大部分が利用できなくなる可能性があります。ホスト型 Lightning ウォレットは現在、組み込まれたインセンティブにより有利ですが、オムニバス アカウント モデルによりチャネル管理の頻度がはるかに低くなるため、オンチェーン手数料が増加するにつれてさらに成長する可能性があります。コミュニティはこの問題を修正し、保管されていない Lightning ウォレットがネットワーク上で引き続き第一級の存在であり続けることを保証するために懸命に取り組んでいますが、明確な解決策はまだありません。
Lightning Network がシンプルでシームレス、完全に抽象化されるまでには、まだ長い道のりがあります。エッジケースはまだ多く、管理されていないユーザーはまだ究極のユーザー エクスペリエンスを享受できていません。しかし、多くの問題はすでに解決されており、今後数年間でさらに多くの問題が解決されるでしょう。稲妻が来たので、雷ははるか遠くにあるでしょうか？