前回の記事で、ライトニングネットワーク(1)に直面する主な課題私たちは、ライトニングネットワークの発展を制限する主要な要因の1つである流動性について議論しました。流動性の問題は、2つの側面にさらに分解されます。1つはネットワーク全体の流動性不足であり、ライトニングネットワークノードの構築と維持の障壁を下げ、追加のインセンティブメカニズムを導入する必要があります。もう1つは流動性分配の問題です。現在、サブマリンスワップ、チャネルステッチング、マルチパスペイメント、ライトニングプール、流動性広告、ループペイメントなどの解決策がライトニングネットワークで最適化されています。
今日は、ライトニングネットワークが現在直面している他の課題と、コミュニティが提案した革新的な解決策について引き続き取り上げます。
高いスループット、低レイテンシ、低コスト、プライバシー機能を備えたLightning Networkは、仮想通貨の支払いに最適な選択肢となり、P2P経済を構築するための重要な支払いインフラとして機能しています。2021年、エルサルバドルがビットコインを法定通貨として採用したことに続いて、Lightning Networkの適用範囲が大幅に拡大し、支払いの数と金額が急増し、ネットワーク内には82,000以上の支払いチャネルが存在しました。
Source: https://mempool.space/graphs/lightning/capacity
しかし、過去2年間で、ライトニングネットワークの発展トレンドにいくつかの変化がありました。上記のデータチャートから、ライトニングネットワークの資金の成長率が鈍化していることがわかります。さらに注目すべきは、チャネルの数さえ減少していることです。この現象は、ライトニングネットワークが急速な拡大の後、新たな課題に直面していることを反映しています。
現在、BTCはBitcoin Lightning Network内で主要な通貨です。しかし、BTCが交換手段として直面する最大の課題の1つは、その価格の大幅な変動です。この不安定さは、長い間Lightning Networkの普及における主要な障壁となってきました。Lightning Networkを本当に一般家庭に普及させ、日常的な小額で頻繁な支払いのための優先的な方法にするためには、特にステーブルコインのサポートを導入することが不可欠です。実際の生活では、安定した価値の通貨を日常取引に使用することに人々は慣れています。
これに対処するため、2024年7月23日、Lightning Labsは、複数資産をサポートする初の本番ネットバージョンのLightning Networkを公式に導入し、Lightning NetworkにTaproot Assetsを正式に導入しました。 Taproot Assetsは、ビットコイン上の資産発行プロトコルであり、発行された資産をLightning Networkの支払いチャネルに預け入れ、既存のLightning Networkを介して転送することができます。 複数資産をサポートするLightning Networkの本番ネットバージョンの開始は、ビットコインLightning Networkでのステーブルコインの正式なサポートを示し、Lightning Networkを介したグローバルな即時決済の外国為替取引や安定したコインを使用した商品の購入などのアプリケーションの可能性を切り拓きました。
画像:ライトニングネットワークでは、アリスがUSDステーブルコインを送信し、ボブがEURステーブルコインを受け取ります。
さらに、Nervos CKBは、Lightning Network向けにFiber Networkを展開しました。これにより、CKBブロックチェーンの柔軟性を活用して、Stable++のような分散型プロトコルによって鋳造されたBitcoinネイティブのステーブルコインを含むユーザー定義資産をネイティブにサポートできます。9月にリリースされた完全機能テストバージョンでは、開発者はすでにFiber Networkを使用してBitcoinネイティブのステーブルコインRUSDをテストすることができます。
私たちは、ライトニングネットワークとステーブルコインの統合が強力な相乗効果を生み出し、ライトニングネットワークの活性化と暗号通貨決済の日常生活への普及を促進すると信じています。
Lightning Networkの技術的な進歩にもかかわらず、従来の支払い体験と比較して、ユーザーエクスペリエンスの改善の余地がまだあります。主な課題には以下があります:
Users are required to remain online when receiving or sending payments on the Lightning Network. This is because Lightning Network payments involve changing the state of funds in a channel that is shared with others, meaning both parties must be online to alter the state of the funds together. One major reason for payment failures in the Lightning Network is that the recipient is offline. From a user experience standpoint, this is a significant design flaw. In contrast, traditional payment methods (such as bank transfers) and blockchain payments (like on-chain USDT transfers) do not require the recipient to be online; transactions can be completed simply by knowing the recipient’s account or address.
現在の主要な解決策は、Lightning Network Service Providers (LSPs) を導入することです。 LSPs はオフラインユーザーの代わりに支払いを受け取ることができ、厳格な「オンラインであり続ける」必要性をなくします。 この解決策により、Lightning Network のユーザーエクスペリエンスは既存の支払方法に近づき、実用性と利便性を大幅に向上させます。
ただし、この解決策は新しい課題も導入します。信頼の前提条件です。ユーザーは、彼らが選んだライトニングネットワークサービスプロバイダーに一定の信頼を置く必要があります。第三者への依存は、分散化の元の意図にやや反するものであり、一部のユーザーの間で懸念を引き起こす可能性があります。
Lightning Networkにおける請求書は支払いを要求するための主要ツールです。支払いの受け手によって生成され、イニシエーターが取引を完了するために必要なすべての情報を提供します。請求書は、支払いアプリで一般的に見られる「支払いコード」に簡単にたとえることができます。
現在、ライトニングネットワークのデフォルトの請求書は 1 回限りの使用のみで、1 回の支払いのハッシュ値とその金額が含まれています。支払いが成功するか、請求書がタイムアウトすると、請求書は無効になります。このメカニズムでは、支払いのたびに新しい請求書を生成、コピー、貼り付け、支払者に送信する必要があるため、面倒なプロセスになります。この設計は、特定のシナリオでのユーザー エクスペリエンスに大きく影響します。たとえば、支払いQRコード(WeChatやAlipayのQRコードなど)を表示することに慣れているマーチャントは、ライトニングネットワークの使用が面倒だと感じるでしょう。特に繁忙期には、請求書を頻繁に生成して共有する必要があるため、効率が大幅に低下し、通常の業務に影響を与えることさえあります。
これに対処するために、ビットコインコミュニティはいくつかの解決策を提案しています:
ライトニングネットワークノードのnode_idは変更されず、支払い者に露出されるため、Keysendはそれを静的エンドポイントとして扱います。この方法には重要な利点があります。追加のプロトコルサポートを必要とせずに、完全にライトニングネットワークのアーキテクチャに依存しています。その欠点は、受取人のノード、チャネル、およびチャネルのUTXOなどの機密データが露出されるため、プライバシー保護が弱くなります。
しかし、Keysendの実用性は広く認識されており、ほとんどのライトニングネットワーククライアントは既にKeysend機能を実装しています。
LNURL-payは、ユーザーが複数の支払いを受け取ることができる静的なQRコードを作成することを可能にする標準です。これにより、ユーザーエクスペリエンスが大幅に向上します。ワークフローは次のとおりです:
Lightning Addressは、ユーザーのQRコード(LNURL-pay)をメールアドレスに似たURLにエンコードすることで、このプロセスをさらに最適化します。他のユーザーがこのURLにアクセスすると、システムは自動的にLNURL-payのリクエストを返し、支払いフロー全体を簡素化します。
LNURL機能を実装しているほとんどのウォレットは、現在はカストディアルモードで動作していることに注意する価値があります。これらのウォレットサービスは、ユーザーにライトニングアドレスを割り当て、簡単に支払いを受け取ることができるようにします。このアプローチは利便性を提供する一方で、一定の中央集権化をもたらすため、利便性と分散化のトレードオフを考慮する必要があります。
BOLT12は、ウェブサーバーに頼らずにLNURLで提供される機能の一部を実現することを目指した、Lightning Networkの技術仕様の新しい提案です。BOLT12はまだLightning Networkの技術的基盤であるBOLTにマージされていませんが、ほとんどの開発者から支持を得ています。LNURLに比べてBOLT12の主なハイライトは、他のネットワークプロトコルや通信方法に依存することなく、Lightning Networkプロトコル内で実装できることです。
上記で言及された全体的な流動性問題や流動性分配問題に加えて、前の記事、そしてこの記事で説明したステーブルコインのサポートの欠如により、ライトニングネットワーク内のユーザーエクスペリエンスには多くの改善すべき領域があります。ライトニングネットワークの開発パスは、他にも多くの課題に直面しています。たとえば、ビットコインライトニングネットワークで使用されているLNペナルティメカニズムは、複雑さを増すだけでなく、ストレージの負担も課します。提案された改善であるeltooを実装するには、ビットコインのソフトフォークと新しい署名ハッシュタイプの導入が必要です。同様に、HTLCに関するプライバシーの懸念は、他のブロックチェーンのライトニングネットワークに最初に実装される可能性のあるPTLCを通じて改善される可能性があります。
道は困難ですが、継続的な技術革新と持続的なコミュニティの取り組みによって、これらの障害は最終的に克服されるでしょう。私たちは、ライトニングネットワークが普及の目標に近づいていると信じる理由は十分にあります。それは暗号通貨の支払いを変革するだけでなく、グローバルな金融イノベーションの重要なドライバーになる可能性もあります。
前回の記事で、ライトニングネットワーク(1)に直面する主な課題私たちは、ライトニングネットワークの発展を制限する主要な要因の1つである流動性について議論しました。流動性の問題は、2つの側面にさらに分解されます。1つはネットワーク全体の流動性不足であり、ライトニングネットワークノードの構築と維持の障壁を下げ、追加のインセンティブメカニズムを導入する必要があります。もう1つは流動性分配の問題です。現在、サブマリンスワップ、チャネルステッチング、マルチパスペイメント、ライトニングプール、流動性広告、ループペイメントなどの解決策がライトニングネットワークで最適化されています。
今日は、ライトニングネットワークが現在直面している他の課題と、コミュニティが提案した革新的な解決策について引き続き取り上げます。
高いスループット、低レイテンシ、低コスト、プライバシー機能を備えたLightning Networkは、仮想通貨の支払いに最適な選択肢となり、P2P経済を構築するための重要な支払いインフラとして機能しています。2021年、エルサルバドルがビットコインを法定通貨として採用したことに続いて、Lightning Networkの適用範囲が大幅に拡大し、支払いの数と金額が急増し、ネットワーク内には82,000以上の支払いチャネルが存在しました。
Source: https://mempool.space/graphs/lightning/capacity
しかし、過去2年間で、ライトニングネットワークの発展トレンドにいくつかの変化がありました。上記のデータチャートから、ライトニングネットワークの資金の成長率が鈍化していることがわかります。さらに注目すべきは、チャネルの数さえ減少していることです。この現象は、ライトニングネットワークが急速な拡大の後、新たな課題に直面していることを反映しています。
現在、BTCはBitcoin Lightning Network内で主要な通貨です。しかし、BTCが交換手段として直面する最大の課題の1つは、その価格の大幅な変動です。この不安定さは、長い間Lightning Networkの普及における主要な障壁となってきました。Lightning Networkを本当に一般家庭に普及させ、日常的な小額で頻繁な支払いのための優先的な方法にするためには、特にステーブルコインのサポートを導入することが不可欠です。実際の生活では、安定した価値の通貨を日常取引に使用することに人々は慣れています。
これに対処するため、2024年7月23日、Lightning Labsは、複数資産をサポートする初の本番ネットバージョンのLightning Networkを公式に導入し、Lightning NetworkにTaproot Assetsを正式に導入しました。 Taproot Assetsは、ビットコイン上の資産発行プロトコルであり、発行された資産をLightning Networkの支払いチャネルに預け入れ、既存のLightning Networkを介して転送することができます。 複数資産をサポートするLightning Networkの本番ネットバージョンの開始は、ビットコインLightning Networkでのステーブルコインの正式なサポートを示し、Lightning Networkを介したグローバルな即時決済の外国為替取引や安定したコインを使用した商品の購入などのアプリケーションの可能性を切り拓きました。
画像:ライトニングネットワークでは、アリスがUSDステーブルコインを送信し、ボブがEURステーブルコインを受け取ります。
さらに、Nervos CKBは、Lightning Network向けにFiber Networkを展開しました。これにより、CKBブロックチェーンの柔軟性を活用して、Stable++のような分散型プロトコルによって鋳造されたBitcoinネイティブのステーブルコインを含むユーザー定義資産をネイティブにサポートできます。9月にリリースされた完全機能テストバージョンでは、開発者はすでにFiber Networkを使用してBitcoinネイティブのステーブルコインRUSDをテストすることができます。
私たちは、ライトニングネットワークとステーブルコインの統合が強力な相乗効果を生み出し、ライトニングネットワークの活性化と暗号通貨決済の日常生活への普及を促進すると信じています。
Lightning Networkの技術的な進歩にもかかわらず、従来の支払い体験と比較して、ユーザーエクスペリエンスの改善の余地がまだあります。主な課題には以下があります:
Users are required to remain online when receiving or sending payments on the Lightning Network. This is because Lightning Network payments involve changing the state of funds in a channel that is shared with others, meaning both parties must be online to alter the state of the funds together. One major reason for payment failures in the Lightning Network is that the recipient is offline. From a user experience standpoint, this is a significant design flaw. In contrast, traditional payment methods (such as bank transfers) and blockchain payments (like on-chain USDT transfers) do not require the recipient to be online; transactions can be completed simply by knowing the recipient’s account or address.
現在の主要な解決策は、Lightning Network Service Providers (LSPs) を導入することです。 LSPs はオフラインユーザーの代わりに支払いを受け取ることができ、厳格な「オンラインであり続ける」必要性をなくします。 この解決策により、Lightning Network のユーザーエクスペリエンスは既存の支払方法に近づき、実用性と利便性を大幅に向上させます。
ただし、この解決策は新しい課題も導入します。信頼の前提条件です。ユーザーは、彼らが選んだライトニングネットワークサービスプロバイダーに一定の信頼を置く必要があります。第三者への依存は、分散化の元の意図にやや反するものであり、一部のユーザーの間で懸念を引き起こす可能性があります。
Lightning Networkにおける請求書は支払いを要求するための主要ツールです。支払いの受け手によって生成され、イニシエーターが取引を完了するために必要なすべての情報を提供します。請求書は、支払いアプリで一般的に見られる「支払いコード」に簡単にたとえることができます。
現在、ライトニングネットワークのデフォルトの請求書は 1 回限りの使用のみで、1 回の支払いのハッシュ値とその金額が含まれています。支払いが成功するか、請求書がタイムアウトすると、請求書は無効になります。このメカニズムでは、支払いのたびに新しい請求書を生成、コピー、貼り付け、支払者に送信する必要があるため、面倒なプロセスになります。この設計は、特定のシナリオでのユーザー エクスペリエンスに大きく影響します。たとえば、支払いQRコード(WeChatやAlipayのQRコードなど)を表示することに慣れているマーチャントは、ライトニングネットワークの使用が面倒だと感じるでしょう。特に繁忙期には、請求書を頻繁に生成して共有する必要があるため、効率が大幅に低下し、通常の業務に影響を与えることさえあります。
これに対処するために、ビットコインコミュニティはいくつかの解決策を提案しています:
ライトニングネットワークノードのnode_idは変更されず、支払い者に露出されるため、Keysendはそれを静的エンドポイントとして扱います。この方法には重要な利点があります。追加のプロトコルサポートを必要とせずに、完全にライトニングネットワークのアーキテクチャに依存しています。その欠点は、受取人のノード、チャネル、およびチャネルのUTXOなどの機密データが露出されるため、プライバシー保護が弱くなります。
しかし、Keysendの実用性は広く認識されており、ほとんどのライトニングネットワーククライアントは既にKeysend機能を実装しています。
LNURL-payは、ユーザーが複数の支払いを受け取ることができる静的なQRコードを作成することを可能にする標準です。これにより、ユーザーエクスペリエンスが大幅に向上します。ワークフローは次のとおりです:
Lightning Addressは、ユーザーのQRコード(LNURL-pay)をメールアドレスに似たURLにエンコードすることで、このプロセスをさらに最適化します。他のユーザーがこのURLにアクセスすると、システムは自動的にLNURL-payのリクエストを返し、支払いフロー全体を簡素化します。
LNURL機能を実装しているほとんどのウォレットは、現在はカストディアルモードで動作していることに注意する価値があります。これらのウォレットサービスは、ユーザーにライトニングアドレスを割り当て、簡単に支払いを受け取ることができるようにします。このアプローチは利便性を提供する一方で、一定の中央集権化をもたらすため、利便性と分散化のトレードオフを考慮する必要があります。
BOLT12は、ウェブサーバーに頼らずにLNURLで提供される機能の一部を実現することを目指した、Lightning Networkの技術仕様の新しい提案です。BOLT12はまだLightning Networkの技術的基盤であるBOLTにマージされていませんが、ほとんどの開発者から支持を得ています。LNURLに比べてBOLT12の主なハイライトは、他のネットワークプロトコルや通信方法に依存することなく、Lightning Networkプロトコル内で実装できることです。
上記で言及された全体的な流動性問題や流動性分配問題に加えて、前の記事、そしてこの記事で説明したステーブルコインのサポートの欠如により、ライトニングネットワーク内のユーザーエクスペリエンスには多くの改善すべき領域があります。ライトニングネットワークの開発パスは、他にも多くの課題に直面しています。たとえば、ビットコインライトニングネットワークで使用されているLNペナルティメカニズムは、複雑さを増すだけでなく、ストレージの負担も課します。提案された改善であるeltooを実装するには、ビットコインのソフトフォークと新しい署名ハッシュタイプの導入が必要です。同様に、HTLCに関するプライバシーの懸念は、他のブロックチェーンのライトニングネットワークに最初に実装される可能性のあるPTLCを通じて改善される可能性があります。
道は困難ですが、継続的な技術革新と持続的なコミュニティの取り組みによって、これらの障害は最終的に克服されるでしょう。私たちは、ライトニングネットワークが普及の目標に近づいていると信じる理由は十分にあります。それは暗号通貨の支払いを変革するだけでなく、グローバルな金融イノベーションの重要なドライバーになる可能性もあります。