主なハイライト

• 今日の Lightning ユーザの大多数は、便利なカストディアルソリューションを利用しています。
• スプライシングにより、ユーザーとサービスプロバイダーは、Lightningとオンチェーンビットコインの違いを抽象化することができます。
• Lightning サービスプロバイダ (LSP) は、エンドユーザーが Lightning にアクセスするためのポータルとして機能します。
• 近い将来に開発される技術開発により、ユーザが追加のアクションを実行することなく、すべての Lightning ユーザのプライバシーが向上する可能性があります。

ライトニングネットワークは、その誕生以来、長い道のりを歩んできました。 さまざまな改善により、Lightningの支払いはほぼシームレスに機能するようになりましたが、課題がないわけではありません。 今日、ユーザーエクスペリエンスは私たちが望むところではないかもしれませんが、ビルダーとして、私たちはこれを課題として捉えたいと思っています:エクスペリエンスをレベルアップするために何をしなければならないか?

この記事では、多くの優秀な頭脳によって開発されているソリューションに基づいて、Lightning の使用体験がどのように見えるかを見ていきます。

まず、今日のユーザーエクスペリエンスとそれに関する問題点について概説します。 次に、実装されている、または積極的に開発されているテクノロジーから情報を得て、Lightningの潜在的な将来の状態を提示します。

2023年の雷の問題は何ですか?

まず、部屋の中の象に対処するために:今日のライトニングネットワーク上の取引のかなりの割合は、カストディアルウォレットによって促進されています。 ネットワーク全体のカストディアンの使用状況を大まかに評価するために Nostr の Lightning トランザクションを使用すると、トランザクションの約 90% は、ユーザーが カストディアンを信頼してキーを持つアプリケーションを介して行われます。

現在、ほとんどのユーザーがカストディアルサービスを選択するのはなぜですか? カストディアルサービスを利用するのは、利便性、シンプルなユーザエクスペリエンス、および 非カストディアル Lightning の使用に関連する課題があるためです。 Lightning の現在の課題は、次の 3 つのバケットに分類されます。

手動作業

望ましい結果を得るために、ユーザーが従来の決済方法よりも多くのアクションを取る 必要がある 場合、大多数のユーザーが興味を失う可能性があります。 その例をいくつか紹介します。

• ユーザーは、支払いを送受信するために常に接続する必要があります。現在、Lightningの支払いが失敗する主な理由は、受取人がオフラインであることであり、これはすべてのLightning支払いの約0.5〜1%で発生します
• ユーザーは、支払いを行ったり要求したりするために、テキスト、電子メール、メッセージングなどを介して帯域外で 請求書 を 相互 に共有 する必要がありますが、これは面倒なプロセスです。
• 独自の Lightningノード を運用するユーザーは、異なる チャネル に ビットコインを割り当てる ことができなければなりません。ノードやチャネルを積極的にメンテナンスしていないピアにチャネルを開くと、資金が宙ぶらりんの状態に陥る可能性があります。
  • これはLightningの資本の機会費用であり、資本が応答しないピアに割り当てられた場合、その資本を他の支払いのルーティング(およびリターンの生成)に使用することはできません。

技術的な専門知識

これらの問題には、Lightningや相互に関連するプロトコルに関する深い知識が必要ですが、平均的なLightningユーザーは追求しない可能性があります。

• Lightning ノードを設定するには、ある程度の技術的能力が必要です。LN ノードは 、ネットワークの他の部分との接続を維持するために、常にオンラインである必要があります。
  • ユーザーのノードがオフラインの場合、ビットコインが紛失したり盗まれたりするリスクがあります。
• ノードオペレーターは、 チャネル内の流動性のバランスをとる必要があります。チャンネルの あなたの側に資金 がない場合、あなたは支払い を送る ことができません。 逆に、チャネル内のすべての資金があなたの側にある場合、 支払いを受け取ることはできません。
• 支払いが失敗したり、行き詰まったりした場合、ノードオペレーターは コマンドラインインターフェイスを介して問題のトラブルシューティングに慣れている必要があります。
• ノードのバックアップは複雑で、ノードオペレーターはシードとチャネルの状態の両方を保存する必要があり、接続が失われた場合に既存のチャネルが閉じられるリスクがあります。

技術的欠陥

Lightningのテクノロジーはまだ完全には開発されていません。 いくつかの技術的な問題はまだ解決する必要があります。

• 中央集権的なサーバーに依存しない、 標準化されたユーザーフレンドリーな方法で は、まだ決済方法がありません。
  • 例としては、統一された QR コードや ペイニム タイプのエクスペリエンスがあります。
  • LNURLとLightningアドレスはオプションですが、これらはまだどこかでサーバーを実行している誰かに依存しているため、回避策です。
• Lightning ノードは常にオンラインである必要があるため、 署名キーもオンライン (ホット) である必要があります。 これは、あらゆる規模で差し迫ったセキュリティ上の懸念を引き起こします。
• チャネルの開閉にかかるコストは、 オンチェーン手数料に直接関係しています。需要が高い時期には、料金が急速に上昇し、 チャネルが高価になります。
  • これを回避するには、ユーザーは手数料の急上昇に先立ってチャネルを設定する必要がありますが、チャネルを開くタイミングを決定することは重要な決定です。
• Lightning のプライバシーは最適ではありません。
  • ライトニングネットワークで支払いをリクエストするときは、常にノードのIPアドレスなどの情報を開示します。
  • 送信者は(一般的に)受信者よりもプライバシーが優れていますが、取引の過程で情報を公開します。
  • Lightningノードが相互に通信する方法に基づいて、第三者はオンチェーンのチャネルファンディングトランザクションに関連する UTXO を簡単に決定できます。 大規模になると、この監視動作はネットワークの 匿名化を解除する効果 があります。

これらの問題のすべてではないにしても、ほとんどが解決されたとき、Lightning はどのように見えるでしょうか?

2025 年の Lightning ユーザエクスペリエンス

次のセクションでは、Lightning のユーザエクスペリエンスの潜在的な将来の状態について説明します。 これは、ユーザが将来 Lightning をどのように操作するかを示す正確なロードマップではなく、ネットワークの特定のアップグレードによって 可能になる可能性のあるユーザエクスペリエンスの予測です。

スプライシングにより、Lightning がユーザに見えなくなる

今後数年間で 、スプライシング がLightningウォレットの大部分に実装されると予想されますが、これはネットワーク参加者にとってどのような意味を持つのでしょうか?

ノードオペレーターは、希望のサイズを達成するためにチャネルを閉じてから再開する代わりに、 オンチェーン料金を過剰に支払うことなく、チャネルに資金を追加および削除できます。 チャネルのサイズ変更が手頃な価格になるため、ノードオペレーター(またはノードオペレーターに代わって動作するソフトウェア)は、チャネルを管理するためのより細かい制御が可能になり、その結果、支払いがより頻繁に成功するようになります。

Lightning サービスプロバイダ (LSP と呼ばれる) も、チャネルのサイズ変更によるコスト削減の恩恵を受け、 ユーザのプライバシーレベルを高めることができます。 ユーザーのプライバシーを最適化しようとするLSPは、 ユーザーの資金を 1つのバッチチャネルオープントランザクションに結合して、資金の出所を難読化することができます。

スプライシングが標準になり、ライトニングとビットコインの間の移動が安価で簡単になると、ユーザーにとってオンチェーンとオフチェーンの資金の区別がなくなるため、 ウォレットは統一された残高を表示します。

オンチェーン手数料が高いシナリオでは、LSPは サイドチェーンで スプライシングとアトミックリバランスを組み合わせることで、ユーザーのチャネルを安価に管理することができます 。たとえば、 液体。

Lightning サービスプロバイダが参入障壁を下げる

LSPは、ユーザーから複雑さを抽象化できるため、近い将来、ユーザーエクスペリエンスの重要なコンポーネントになる可能性があります。さらに、LSP はノードを実行するための資本要件を削減します。これらは、ネットワークへのユーザーのポータルとして機能します。

ライトニングの魔法は即時決済ですが、支払いの失敗やその他の緊張感はユーザーエクスペリエンスを損ないます。 LSP がサーバやノード自体などのインフラストラクチャを運用することで、ユーザは Lightning と簡単に連携できます。 LSPは、ユーザーが自分の資金をコントロールできるが、ノードとのインターフェースは持たないノード・ イン・ザ・クラウド・モデル を提供することで、 ユーザーとインフラストラクチャとのやり取りをなくす ことができます。また、モバイルでバッテリーの消費量が少ない「ライト」バージョンのサービス、または両方のモデルの組み合わせを提供することもできます。

より多くの資本をLightningに移行する場合、ユーザーは、アプリケーションに 一連の12または24単語 を入力するなど、 使い慣れた方法でノードまたはウォレットを復元 できる必要があります。サービスプロバイダーは、ユーザーがLightning Walletの 暗号化されたバックアップを クラウドに保存できるようにします。 万が一、ユーザーのデバイスが壊れたり、侵害されたりした場合、暗号化されたクラウドバックアップを新しいデバイスに簡単にインポートできます。

方程式から手作業の除去

ビットコイン(またはその他の新しいテクノロジー)の恩恵を受けるために追加の手順を踏む必要がある場合、採用プロセスのある時点でドロップオフする可能性があります。

解決策が必要な現在の問題のコンテキストでは、LSPは オフラインユーザー向けの支払いを受け入れる ことで「常時オンライン」の要件を解決 し、UXを既存の決済ソリューションに近づけることができます。

ビットコイン開発者がより多くの資金を利用できるようになるにつれて、ユーザーが外部サービスを利用せずに独立して支払いを受け入れることを可能にするソリューションがさらに登場する可能性があります。

Lightning Addresses のような現在の支払い ID は、ほとんどの場合、サービス可能ですが、保管されています。ユーザーは、 再利用可能なQRコードを交換して、 第三者に依存することなく支払いを受け取ることができる必要があります。 再利用性は極めて重要で、請求書のコピー、貼り付け、取引先への送付は手順が多すぎます。 シンプルなソリューションが利用できることで、すべての Lightning ユーザにメリットがもたらされます。

画像情報ソース: https://bolt12.org/

上の画像の小さくてシンプルなQRコードは オファー と呼ばれ、 ウォレットはユーザーの指示なしに支払いフローの一部を要求する請求書を処理できます。 オファーのもう一つの利点は、通貨、ベンダー名、数量制限、受取ウォレットに到達するためのルートなどの情報を含めることができることです。

ほとんどの人はシンプルなオンボーディングプロセスを好み、サービスプロバイダーにセットアップを任せる可能性が高いことを意味します。 その一例が Fedimint プロトコルで、いわゆる電子マネーミントを管理する人々のグループです。 このモデルは、 より優れたプライバシー と、相続管理、プライベート マイニングプール 、分散型紛争解決、合成ドルエクスポージャーなどの一連の追加 製品とサービス を提供します。Lightning はこれらのコミュニティに組み込まれているため、ユーザは自分の裁量でフェデレーションを即座に脱退でき、そのためのコストはほとんどかかりません。

Lightning の標準としてのプライバシー

ユーザのプライバシーを Lightning の標準機能にするには、プライバシーを有効にするテクノロジがユーザから見えないようにする必要があります (つまり、ユーザがプライバシーの恩恵を受けるためにアクションを実行する必要がないようにする必要があります)。 アプリケーション開発者やサービスプロバイダーは、オンチェーントランザクションとLightningトランザクションを分離するなど、舞台裏で決定を下す必要があります。

ライトニングネットワーク監視の妨害

オンチェーントランザクションがLightningチャネルのオープン/クローズであるかどうかを評価することは、新しいテクノロジーが他のビットコイントランザクションとまったく同じに見えるようになるため、非常に困難になります。より多くのTaprootテクノロジーが実装されるにつれて、署名アグリゲーションなどの機能は、支払いチャネルに関する情報や、トランザクションに関与する可能性のあるユーザーの数を隠すことができます。

Taprootがウォレットに広く実装されていれば、ユーザーは ピアグループ外で支払いを行う際に、より多くのプライバシー を得ることができます。 現在、1つの支払いID(支払いの ハッシュ )があり、宛先へのルート上の断続的な各ノードによって認識されています。 Taprootが署名を処理する方法の側面を使用して、ルートに沿って 「ダミー」の支払いIDを作成し 、送信者と受信者だけが支払いを明確に理解できるようにすることができます。

Lightning ユーザは、支払いが意図した宛先に到達するまでの 正確なルートを気にしたり、知る必要さえありません が、現在、支払いパス上のノードは支払いの送信元を確認できます。 カナディアン・フリーダム・コンボイの物語を通じて、 私たちは、政府が資金を差し押さえ、不換紙幣の銀行口座を閉鎖し、反対の声を上げる個人を検閲することができるし、そうするであろうことを見てきました。

LSPは、ルート構築の仲介者として機能するサービスを提供することで、 Lightningトランザクションのソースを匿名化 できます。 このように、LSP は構築したルートの部分のみを認識し、送信者は他の部分を認識します。中間ノードと目的地は、ルート全体に対して「盲目」になります。 このモデルでは、堅牢なセキュリティが提供され、ユーザーが関与する必要はまったくありません。

Lightning を VPN として使用する

ウォレットは、プライバシーを強化する方法で創造性を発揮することができます。 たとえば、 ウォレットとLSPは、ユーザーの「請求書仲介者」として機能する可能性があります。ウォレットは請求書を作成して LSP に転送し、LSP は支払いを完了します。 受取人には、LSP から支払いを受けているように見え、このようにして、送信者は慣れ親しんだ支払いフローを中断することなく、より高いレベルのプライバシーを実現します。 Mutiny Walletの共同設立者であるTony Giorgio 氏は、この種のアプローチにより、ウォレットユーザーは LSPの他のすべてのユーザーに紛れ込むことができると指摘しています。

Lightning ユーザの一部は、LSP を通すことで実現できるよりも堅牢なプライバシーを求めています。 トランザクションの難読化は、プライバシーを高めるための試行錯誤された方法ですが、これにはユーザーの手動操作が必要であり、オンチェーンではコストがかかる可能性があります。 LSP はすでにサーバーを実行しているため、 ユーザーに協調的なトランザクション調整サービスを提供するのに適した立場にあります。 サービスプロバイダーは、ユーザーがチャネル を開いたり閉じたり、チャネル容量を増減したり(前述のようにスプライシングのセクションで説明)、ユーザーが 商品やサービスにお金を払ったりするときに、プライバシーを強化するチェックポイントを作成できます。

Lightning が E コマースをレベルアップ

ベンダーは、Lightning 経由で行われたトランザクションの返品期間を顧客に提供できます。顧客はチェックアウト時に 特別な種類の請求書 を支払いますが、商品またはサービスが提供される時まで取引を「取り消す」機能を保持します。 これは、以前は Lightning では不可能でした。

セキュリティは機関導入の鍵

より多くの機関がライトニングネットワークに参加するためには、 オフラインのコールドストレージからライトニングチャネルに資金を簡単に移動できる必要があります。 Taprootチャネルは、セキュリティを損なうことなく、このユースケースを可能にします。

さらに、 機関投資家がLightningに多額の資金を保有することがより安全になります。 彼らは、 インターネットに接続されたウォレット のリスクから身を守るのに役立つ 特別なデバイス を使用できるようになります。

結論

Lightningは、即時決済で支払いを行う上での有用性を実証していますが、確かに問題点があることを認識する必要があります。 それでも、ネットワーク参加者は、UXのハードルの解決が進んでいることについて楽観的になるはずです。 世界で最も才能のある開発者 の何人かは、エクスペリエンスを向上させるためにたゆまぬ努力をしています。

より多くの技術的ソリューションが登場し、ネットワークにより多くの資本が投資されるにつれて、Lightning Service Providerは、エンドユーザーから複雑さを抽象化する上でより大きな役割を果たすようになる可能性があります。 テクノロジーの進歩は、セルフホストユーザーにも同様に利益をもたらし、ネットワーク全体を It Just Works エクスペリエンスに近づけます。

Lightning にはワクワクすることがたくさんあります。この記事で紹介した将来の予測はすべて、現在取り組んでいるソリューションから情報を得ています。 開発者や起業家がユーザーエクスペリエンスの最適化に注力すればするほど、より多くの参加者と資本がネットワークに参加し、すべての人のエクスペリエンスが向上します。

免責事項：

1. この記事は[Superscrypt]からの転載です。 すべての著作権は原作者[Jacob Ko]に帰属します。 この転載に異議がある場合は、Gate Learnチームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。