SLP488 FUTURE VISIONS OF LIGHTNING, GREENLIGHT & BREEZ SDK【Stephan Livera Podcast】2/2

2023-06-25T02:01:37Z

Part1の続き

-------------------------
ステファン　それで、思い出したと思います、ロイ、あなたが最後に番組に出演したときに、そのことについて簡単に話したと思います。そして、つい最近マット・コラロともこのことについて少し話したと思いますが、彼はこのアイデアについてしばらく話し合っていたと思います。そして、LDK の人々もこの非同期支払いのアイデアに熱心であることを私は知っています。つまり、非常に高レベルの話だと思います。単純化しすぎているかもしれませんが、私の理解では、誰かがこの支払いを開始し、その後 LSP が支払いを保留するまでエンドユーザーを支援するという考え方です。それがオンラインに戻り、支払いを受け入れる準備ができるまで、なんとか準備ができています。大体こんな感じでしょうか？

ロイ　はい、おおよそです。はい。それに伴う問題は、HODL invoiceを使用して、Lightning で非常に単純に非同期支払いを実装できるようになりました。支払者がオンラインに戻るまで支払いを保留し、その後再び支払いを保留することができます。支払いがオンラインに戻るまで。問題は、支払いを保留するとき、チャネル内で HTLC を保留するときに、ネットワーク全体の流動性がロックされてしまうことです。ええ、その通りです。したがって、非同期支払いメカニズムの秘密のソースは、支払いを支払い者 LSP 側で保留することです。支払いが支払者 LSP 側で保持されており、LSP が常にオンラインサービスであることがわかっている場合は、支払者 LSP と支払者 LSP の機能を使用して支払いを調整し、支払者または支払者がオンラインになったときに相互に通知することができます。また、流動性は支払者の LSP やチェーンの途中にロックされません。最初のホップでロックされています。支払者の LSP レベル。

ステファン　それはかなり技術的な話だと思います。しかし、結局のところ、ユーザーは、エンドユーザーが「ああ、新しい支払いを受け取ったばかりだ」という素晴らしいエクスペリエンスを得ることができます。オンラインかオフラインか、そのどれについてもあまり深く考える必要がないように。それはすべて開発者によって処理されます。それはすべて背景にあります。開発者、起業家、LSP は実際にその問題に対処しています。したがって、ユーザーはそれについて考える必要はありません。それは一種のエンドユーザーメッセージです。

ロイ　それがBreezのユーザーエクスペリエンスにおける私たちの目標のようなものです。ユーザーは何も考える必要がなく、開発者も何も考える必要がないのと同じです。それが私たちの目標のようなものです。

ステファン　うん。そして、私が理解しているところでは、私が話したいもう 1 つの分野があると思います。私が間違っていたら教えてください。しかし、この場合のエンドユーザーはルーティングノードではないと理解しています。彼は、支払いを受け取るか、支払いを行うだけのエンドユーザーです。彼は、支払いを行ったり来たりするようなルーティングノードになろうとしているわけではありません。

ロイ　これを専門用語に翻訳してみましょう。LSP とエンドユーザーの間にはプライベートチャネルがあります。これは、このチャネルが支払いのルーティングに参加しないことを意味します。そして、クリスチャン氏は Greenlight の魔法について語ることができます。なぜなら、Greenlight は、リソースやクラウドリソースの運用と最適化の方法が魔法であるからです。

クリスチャン　うん。たとえば、私たちが行っている最適化の 1 つは、署名者が存在しない場合はノードを実行し続けることに意味がないということです。新しいstateを承認する方法はありません。したがって、私たちが行うことは、基本的に、現在署名者が接続されていないためにパッシブであるノードをプリエンプトできるということです。そうすることで、システムのスケーラビリティを大幅に向上させることができ、ユーザーと共有しなければならないコストに大きな影響を与えます。したがって、はるかに簡単にスケールアップとスケールダウンができるシステムが得られます。そのためには、ユーザーが必要なときにこれらのノードが存在することを確認する必要もありますよね。そして、基本的に、ノードがリクエストされたときを検出し、オンデマンドでスケジュールするシステム (インフラストラクチャのスロットの 1 つ) を用意することでこれを実現します。また、起動には通常 0.5 秒未満かかります。そして通常は 1.5 秒以内に、ゴシップなどすべてが同期された完全に機能するノードが完成します。なぜなら、オンデマンドでノードを起動するときに発生する最大の問題の 1 つは、接続が開かれ、ゴシップの同期が開始され、ゴシップが少しずつ入ってくることです。そして、おそらく 30 分後には、完全なビューが得られるでしょう。ネットワークの。そして、支払いができるようになりました。一方、基本的に携帯電話でアプリを開くことができるようにすべてを最適化しました。そして、スプラッシュ画面が消えるまでに、ノードはすでにバックグラウンドで実行されており、リクエストを受信できるようになります。したがって、ユーザーの観点からは、本質的には常時接続のノードとなります。しかし、私たちは裏で、必要に応じてそれらをオフにしたりオンにしたりしています。また、起動時間を確実に短縮するために使用するテクニックが多数あります。しかし、開発者の観点から見ると、これらのノードは常に実行されており、すべてのライフサイクルをバックグラウンドで処理するだけです。

ステファン　そこには秘密のソースが少しあります。LSP に関して言えば、もう 1 つの側面はユーザーとしての側面だと思います。たとえば、今日 Lightning Network で独自の Lightning ノードをセットアップしたい場合、それはあなたではありません。始めたばかりの時点では、最も接続されているノードにはなりません。したがって、確実に支払いをしたり受け取ったりしたい場合は、理想的には、十分に接続されたユーザーである必要があるという側面があります。それでは、Greenlight および Breeze SDK コンテキストではどのように機能するのでしょうか? ユーザーはすでに十分に接続されている LSP に便乗しているようなものだからです。そういう考えですか？そうしないと、あなたは... ユーザーとしてセットアップしたときに、基本的に受信チャネルが不良であったり、十分なチャネルや接続がなかったりする場合、優れた信頼性の高い LSP がなければ、支払いエクスペリエンスが素晴らしいものにならない可能性があります。

ロイ　はい。したがって、LSP 部分の 1 つが最も重要です。LSP の機能の 1 つは、エンドユーザーにチャネルを開くための流動性を提供することです。ただし、信頼性の高い支払いを促進するには、LSP がネットワーク、つまり外部のライトニングネットワークに適切に接続されている必要があります。したがって、LSP が他のノード、ネットワーク内の他のパブリックノードに確実に接続されていない場合、それは不良 LSP であり、支払いを正常に処理するには別の LSP を選択する必要があります。

ステファン　そうか。明確にしておきますが、この場合の LSP は、この場合、Breeze が LSP として機能しているということですか? それとも、Greenlight によってさまざまな LSP を選択できるようになるのでしょうか? それはどのように機能するのでしょうか?

ロイ　Breeze SDK、Breeze SDK での実装方法である Greenlight はエンドユーザーノードです。Breeze がデフォルトの LSP ですが、他の LSP を使用できるようにオープンプロトコルを使用しています。したがって、実際には Breeze LSP を使用する必要はありません。ユーザーが選択して使用できる、競争力のある信頼できるサービスを提供できることを願っています。開発者は Breeze LSP の使用を選択します。ただし、別の LSP を選択することもできます。Breeze LSP でも、他の LSP 用にいくつかのオプションをすでに提供しています。ただし、LSP エンティティは Greenlight から分離されています。このトポロジのGreenlightは、LSP へのプライベートチャネルで接続されているエンドユーザーノードを表します。また、LSP は、エンドユーザーノードに流動性を提供するだけでなく、それが理にかなっている場合には、外部のライトニングネットワークへの接続も提供します。

クリスチャン　その通り。そうですね、Greenlight 側では、プロバイダーにはほとんど依存しませんが、個人的には、その寿命の長さと Breeze が長年にわたって収集してきた運用経験を考慮すると、Breeze LSP を好みます。それは間違いありません。Breezeさんとコラボできて本当に良かったです。しかし、私たちの観点からすると、開発者またはエンドユーザーが入手できるのは、標準のCore Lightning ノードです。また、Core Lightning ノードで実行できることはすべて、Greenlight ノードでも実行できます。ただし、2 つの小さな例外があると思います。ユーザーが提供するプラグインのようにプラグインを統合する方法については、まだ明確な計画がありません。そしてそれが唯一の制限です。しかし、私たちはそれにも取り組んでいます。

ステファン　うん。私たちがここにいる間に、Core Lightning 実装と他のものと比較した議論を聞くだけでも興味深いかもしれません。例として、高速ノードを備えた LDK、高速グラフ同期について人々が話しているのを知っているので、そう呼ばれていると思います。そして、ご存知のとおり、LND、明らかに、ロイ、あなたはすでに現在のブリーズで LND を持っています。では、コア Lightning は他の実装とどのように比較できるのでしょうか?

ロイ　Christian がこの質問に答える前に、もしよろしければ、ノードという用語をわかりやすく説明したいと思います。さまざまなトレードオフについて賢明な議論を行うために、Lightning ノード全般について話す必要があります。どのソリューションを選択しても、常にトレードオフが存在します。そして、開発者に、リスナーがトレードオフを理解できるようにメンタルモデルを提供するために、ノードという用語を複数の部分に分解する必要があると思います。そして、各部分について個別に話すことができます。わかりませんが、信頼の最小化、プライバシー、その他の影響についてのトレードオフは何ですか? ブレイクダウンしたいと思います。ビジョンの観点から見ても、Lightning の文脈でノードという用語を使用することはますます少なくなると思います。私はそうではないと思います。ノードがすべての機能を提供しない世界はすでに見えています。これは、Lightning のすべてのニーズがノードと呼ばれるこのエンティティで提供されるモノリシック環境ではありません。では、ライトニングノードとは何でしょうか? それを 4 つの部分に分けてみましょう。署名は一部であると言えます。人々はトランザクションへの署名を Lightning ノードの機能の一部として考えています。チャネル状態管理は、Lightning ノードの 2 番目の機能の 2 番目の部分です。オンチェーンのインタラクション、オンチェーンの変更を追跡できることは、Lightning ノードの 3 番目の部分です。そして、ゴシップまたは Lightning ネットワーク通知、これは Lightning ノード機能の 4 番目の種類の部分です。クリスチャン、何か見逃したかな？

クリスチャン　いいえ、それがすべてだと思います。

ロイ　わかった。CLM のコンテキストではなく、Greenlight のコンテキストで言えば、Greenlight は、実行が非常に困難なオンチェーン同期とグラフ同期を採用したという意味で魔法です。モバイルデバイス上のエンドユーザーノード。チェーンを常にクエリする必要がある場合、または Lightning ネットワークのゴシップから常に更新を取得する必要がある場合は、それを別の操作にオフロードします。次に、各ユーザーノードがクラウド内で独自のチャネル状態を管理します。つまり、チャネル管理はクラウドで処理されます。署名はユーザーのデバイス内で行われます。したがって、Lightning ノードの 4 つの機能の 4 つの部分のうち、残りは 1 つになります。したがって、その意味で Greenlight が Lightning ノードであるかどうかは哲学的な問題です。それで、私がそれをどうするかがわかります。これらのハイブリッドアプローチでは、ノードという実際の概念はもう存在しないと思います。この点に関しては LDK について話すこともできますが、クリスチャンの話をさせてください。

クリスチャン　まず第一に、すべての実装には存在理由があり、それぞれが優れた独自のアプリケーションがあると思います。これから説明するさまざまなトレードオフは、フロントエンドでのトレードオフですよね? バックエンドでは、互換性を維持し、できるだけ多くの機能を共有することを常に目指しています。そのため、バックエンドではコラボレーションが行われ、フロントエンドでは競争が行われます。そして、異なる実装間の違いのほとんどは、純粋に以前の経験によって色付けされています。したがって、出身地によっては、どちらかのオプションを好む場合があります。たとえば、Core Lightning と LND を比較してみましょう。私たちは非常に早い段階で、個々のパーツを交換できるモジュラーシステムを導入したいと決定しました。そして、Unix の哲学に従い、すべてのパーツが 1 つのことだけを実行し、それを適切に実行できるようにしたいと考えました。そして、それはまさに、ロイが話していた、互いに影響し合い、複雑にノードを構成するさまざまな部分の階層のようなものが由来する場所ですよね? そのため、非常に早い段階で、署名者を独自のプロセスに分割していました。そして、このモジュール構造を使用することで、オープンソースプロジェクトである標準の Core Lightning を実際に利用することができ、コマンドライン引数を微調整するだけで、個々のパーツを交換することができます。たとえば、署名者は単にメインプロセスからリクエストを受信し、それをユーザーのデバイスに送信し、そこで検証されて署名者に注入されます。そしてまた同じルートを戻ります。この種のモジュール性は、私たちが非常に早い段階で実験したものであり、今日では非常に満足しています。一方、LND は少し異なるアプローチをとっており、「基本的に開梱すればそこにすべてが揃っているシステムが欲しいのですよね?」と言います。Core Lightning は、「もう少しカスタマイズしたいかもしれない、ここにはすべてのツールがあります」という方向に進んでいます。しかし、箱から出してすぐの完成度はそれほど高くありません。一方、LDKはさらに一歩進んで、主にライブラリからスタートしました。そのため、彼らは現在、すべての要素を組み合わせた実装を行っていますが、本質的にすべての詳細を選択できるモジュール性の極限に達しています。また、Core Lightning では部分を正しく接続するにはある程度の知識が必要ですが、LDK 部分を正しく接続するには開発者である必要があります。また、デフォルトや動作などに関して Core Lightning で行った選択の多くは、LDK でカスタマイズできますし、カスタマイズする必要があります。そうは言っても、LDK は、知識があれば、Lightning ノードまたは Lightning ノード用のコンポーネントを構築するための優れた環境です。おそらく、私たちは検証中の Lightning 署名者チームと協力して、Greenlight で使用している署名者を構築していることを述べておく必要があるでしょう。そして、検証する Lightning 署名者は、たとえば、LDK 上に構築されたそのようなプロジェクトの 1 つです。したがって、非常に粒度が細かいことは、「何を作りたいかというアイデアがあり、それをまとめるスキルがある」という場合には、大きな利点にもなり得ます。そして、4 番目の実装である Eclair は、使用するデプロイメントに応じて、さらにすぐに使えるものになります。Eclair と Phoenix は、私がこれまで見た中で最も簡単な Android ウォレットです。そして、彼らの LSP も最も古いものの 1 つです。そのため、彼らはウォレットと LSP を運用するのが非常に上手です。そして、あなたが見たかどうかはわかりませんが、しかし、彼らは最近、ノードをどのように保護するかについて優れたブログ投稿を公開したばかりです。署名者がどこに座るのか、また署名がどのように機能するのかについては、同じ用語がたくさん出てきます。そこで私たちは、2 つの異なる出発点から出発して、非常に似たデザインに到達するという、ちょっとした収束進化を経験しました。はい、それがここのエコシステムのほとんどです。

ステファン　それは素晴らしい概要です。それと興味深いのですが、モバイルノードの将来について何か考えはありますか。たとえば、私は知っていますが、ロイ、あなたはノードという用語が少し混ざってきていると言ってましたね。しかし、皆さんは、現在の Breeze のような、LDLND バージョンのようなモバイルノードの将来について何か考えていますか? ほら、その将来性はどこにありますか？それは時間の経過とともに減少し、この種のサービスでサポートされるアプローチに近づくと思いますか? それとも、モバイルの Lightning Node ウォレットやアプリケーションなどにはまだ将来があると思いますか?

ロイ　そうですね、繰り返しますが、すべてはどこで実行するか、どの部分をどこで実行するかについての実装の詳細のようなものになると思います。LDK、ほんの一例、そしてもう一つLDK、素晴らしいプロジェクトを叫ぶ場所のようなものだと思います。私たちは実際に、Christian が SDK で言及したライブラリのいくつかを使用しています。素晴らしいプロジェクト。たとえば、LDK は、Greenlight のようなクラウドファーストのアプローチではなく、モバイルファーストのアプローチをとっているようなものです。ただし、裏では、今すぐモバイルデバイス上で LDK ノードを実行したい場合、オンチェーン同期とゴシップ同期を外部のサードパーティサービスにオフロードする必要があります。したがって、署名者とチャネル状態が残ります。また、チャネル状態に関しても、クラウド同期のコンポーネントとなる VSS を追加する予定です。したがって、チャネル状態自体はクラウドに同期されます。したがって、各コンポーネントがどこで実行されているかの境界線はすでに曖昧になっており、将来的にはさらに曖昧になると思います。言及したいことが 1 つあります。現在、LDK とモバイルで LDK ノードを実行している Breeze が持つ利点の 1 つは、プライバシーの観点から見ると、支払い先を認識する主体が存在しないため、モバイルノードの方がプライバシーが優れているという事実です。 Greenlight には機能があり、Christian は拡張できますが、このプライバシーアプリケーションを軽減することを目的とした Oblivious Send と呼ばれます。しかし現時点では、支払い先を誰も知らないため、プライバシーの観点からはモバイルノードを使用して実行する方が優れています。そうだ、

クリスチャン　プライバシーの話に移りますが、Greenlight ノードは資金にはアクセスできませんが、ログにはアクセスできるのは事実です。そしてそれは間違いなく私たちにとって懸念事項です。そして私たちはそれを可能な限り最小限に抑えたいと考えています。ロイが述べたように、私たちはインフラ上で実行されているノードと共有される情報を最小限に抑えるための多くの技術を検討しています。Oblivious Send もこれらのメカニズムの 1 つです。もう一つはトランポリンです。つまり、本質的に、Oblivious Send でやろうとしていることは、請求書をサーバーに送信し、サーバーがルートを計算するのではなく、次に、それらのルートを使用してオニオンを構築し、それらのオニオンを転送することで、代わりにゴシップを携帯電話で実行されているユーザーのウォレットに同期します。次に、電話自体がルートを計算してオニオンを作成し、それらのオニオンをサーバー上で実行されているノードに注入します。つまり、私たちが目にしているのは、本質的には暗号化された情報の塊だけです。目的地が誰なのかは分かりません。送金される正確な金額はわかりません。何が起こっているのかについての説明はわかりません。つまり、これは基本的に、多数の HTLC で構成される支払いプロセスをクライアント側に移すことになります。これは、Core lightning の pay コマンド自体が、たとえばプラグインとしてまったく同じことを実行しているため、可能です。したがって、これらすべての部分を計算し、ノードにオニオンを挿入して、その情報をノード自体から隠す機能がすでに備わっています。一方、トランポリンは、ノードに「おい、ほら、目的地が誰なのかを私たちの代わりに Breeze に伝えたいのか?」を伝えるときに使用するもう 1 つのメカニズムです。大丈夫。請求書を含む 1 つの大きな HTLC を Breeze に転送するよう指示してください。その後、オンラインノードまたは LSP が実際に支払いを宛先にルーティングする処理を担当します。したがって、これらは私たちから情報を隠すことができるさまざまな構造であり、私たちはGreenlightで提供できるプライバシーを高めることを検討しています。しかし、逆に言えば、ログにアクセスできることは、Corelightning 開発者としての決定を知らせるのに役立ちます。それは間違いなく私たちの目標の 1 つでもありますこれは、私たちが行った運用経験の一部を取り上げ、Core lightning のプログラミング中に行った仮定が正しかったかどうかを確認するためです。そのため、私たちは現在、支払いの送金方法やゴシップの管理方法などを最適化できる、閉じたフィードバックループを持っています。基本的には、何が起こっているか、そして変更をデプロイした後に意図した効果があるかどうかについて、より広い視野とより広範なサンプルを得ることができます。したがって、それは少しトレードオフです。しかし、結局のところ、私たちはその情報を望んでいません。そしてそれが、できるだけ多くのユーザーが最終的にはボードを離れることを望んでいる理由でもあります。携帯電話にノードがあることと、反対側が Greenlight にノードがあることを混同しないようにしましょう。しかし、Greenlight を使用すると、一度ボードから離れると、自分の情報も完全にコントロールできるようになります。したがって、新しいユーザーはオフボードするまで一時的に情報を共有していると私は考えています。そして、私たちはこの情報をオープンソースプロジェクトの最適化に使用できるようにし、それが全員にとっての利点となるようにします。ここで、電話機上にノードがあるか、サーバー上にノードがあるかという質問に戻りますが、これらは多かれ少なかれ哲学的な質問ですよね。最適な展開を選択してください。おそらく、Greenlight であれ、リモート接続する自宅の自己ホスト型ノードであれ、サーバー支援型のものを使用するので、それが私の絶対的な好みの設定であることは想像できるでしょう。私たちは、どこかにリモートするオプションが優れていると考えています。しかし、それは意見です。なぜそれが優れていると考えるのか、例をいくつか挙げることができます。つまり、本質的には複数のフロントエンドを使用できるということになります。ロイが言ったように、このポッドキャスティング 2.0 アプリをテストしたいだけであれば、他のアプリを閉じて、そこから資金を排出し、ポッドキャスティング 2.0 アプリに資金を供給し、チャンネルを作成し、セットアップをすべて完了する必要はありません。そして、ああ、これは醜いアプリだということがわかりました。私はもう一方の方が好きでしたね。あなたの携帯電話の状態全体は基本的にあなたのプライベートシードで推測されるので、私たちはより良い回復ストーリーを持っています。24 単語を持っている限り、セーリング事故やボート事故で携帯電話を紛失しても大丈夫です。その後、別の携帯電話を手に取り、24 単語を入力すると、実行中のノードへのアクセスを回復することができます。どこか別の場所。したがって、突然、ボート事故から安全になります。それが純プラスか純マイナスかは皆さんに判断してもらいます。しかし、私自身も船員なので、携帯電話を船外に投げ捨てても、別の場所ですぐに回復できるという快適さがとても気に入っています。

ステファン　ということは、Greenlight はユーザーのバックアップも扱っているのではないかと思いますね?

クリスチャン　ええ、その通りです。そのため、実際にバックアップを作成し、ユーザーが暗号化された形式でオフボードしたい場合に提供します。そして、シードフレーズを使用するだけで、このパッケージ全体を復号化し、そのバックアップに対して新しいCore Lightning ノードを起動できます。そして、基本的に、中断したところから正確に再開します。

ロイ　ステファン、同様のハイブリッドアプローチのサーバー支援ソフトウェアが LDK からも登場すると思います。大規模なバックアップ、マルチデバイス環境のような機能、マルチアプリ環境を実現するには、サーバー支援ソフトウェアが必要です。したがって、繰り返しになりますが、すべてが何であるかについては非常に曖昧になると思います。おそらくこの投稿からわかることは、これ以上のノードは存在しないということです。デバイスごとに異なるサービスが異なる構成になっているだけです。

クリスチャン　そして私たちの間にはたくさんの交流があります。前に述べたロイと同様に、LDK 担当者は、ソフトウェアの複数のインスタンス間で状態を同期するために VSS と呼ばれるシステムを構築しています。そしてそれは私たち自身のニーズに応えたものです。前に、必要な数の署名者を 1 つのノードに接続できると述べましたが、署名者はステートレスではないからです。そこで、「OK、これが私の現在の状態です」と言える署名者状態同期プロトコルが必要でした。そして、すべての署名者はリクエストとともにその状態のコピーを取得します。その状態を検証し、その状態をフィードバックします。それは私たちが構築しなければならないと分かっていたものです。そして、LDK の担当者と話したところ、彼らはさらに一歩進んで、実際にノード全体を同期したいと考えていることがわかりました。一方、私たちは単に署名者の状態を同期するだけで、おそらくその方が簡単だと思いますが、それがどのように行われるか見てみましょう。判明した。

ステファン　そうですね、ここでの興味深い示唆の 1 つは、願わくばそれです。これについては先ほど話しましたが、カストディアリズムとノンカストディアリズム、そしておそらくビジネスケースとそれに関連する法的規制リスクの低減について話しました。ですから、カストディアルアダプションとノンカストディアルアダプションについて多くの人が話していると思います。そして、この種のソフトウェアとこの種の構築は、より多くの人がノンカストディアルになるのに役立つと言えるでしょう。なぜなら、今日では、彼らはカストディアルユーザーであるさまざまなサービスを利用している可能性があるからです。つまり、ビットコインの世界だけでも、stacker.news があり、そこに少しの保管残高があるかもしれません。そこに保管残高のあるFountainアプリがある可能性があります。別のアプリに少額の保管残高が入っている可能性があります。それが変わる可能性はどのように考えていますか? よりノンカストディアルなものになる可能性はあると思いますか？

ロイ　Greenlight の取り組みを行っている Christian も、Breeze SDK の取り組みを行っている Breeze も、私たちが行っていることすべてにおいて、管理的な Lightning などというものは存在しません。ライトニングはビットコインです。ビットコインは保管されません。それ以外の用語は、単なる煙と鏡だと思います。すべては... ビットコインを交換媒体として使用したい場合は、Lightning が必要です。Lightningを行う方法はノンカストディアル型Lightningのみです。そして、私たちが行っているすべての取り組みは、世界中で Lightning の使用を促進することです。Lightning をノンカストディアルな方法で使用していない場合、それはある意味では Bitcoin さえ使用していないことを意味します。したがって、Greenlight インフラストラクチャを通じて Breeze SDK で提供できるユーザーエクスペリエンスは、Breeze ウォレットで現在提供しているユーザーエクスペリエンスよりも優れていることは間違いなく、これは素晴らしいことです。そして、フェニックスがやっていることは素晴らしいことです。そして、人々はこれら両方のウォレットが処理するトランザクションの量とスループットに驚かれると思います。そして、現在 Twitter 界に存在するすべての統計やあらゆる不祥事は完全な不祥事です。エンドユーザーによる Lightning のノンカストディアル的な使用法は数多くあります。そして、私たちの SDK と Greenlight が行っている仕事、LDK が行っている仕事は、Lightning を次のレベルに引き上げると思います。そして、すでに Mutiny ウォレットでその例を見ることができます。すべてのサービスがより優れた非保管インフラストラクチャを使用し、非保管 Lightning がエンドユーザー製品の実装における最初のデフォルトソリューションになるという未来には程遠いと思います。私たちはその未来に非常に近づいていると思います。

ステファン　そこで気になるのですが、それでは、セルフカストディアルを行う意味があるために、それを超える必要があるしきい値はあると思いますか? なぜなら、より高い料金環境に移行したとします。ある時点で私たちが見たこの最近の急騰では、次のブロックに入る料金は法定通貨換算で、vByte あたり 500 sats、または約 50 ドルだったと思います。再び強気相場が起きた場合、価格が上昇してブロックスペース市場がさらに混雑した場合、一定のしきい値があると思いますか。それを超えると自己管理が困難になる特定のしきい値があると思いますか?

ロイ　必ず合理的な価格が存在します。mempool にコンジャンクションがあり、オンチェーントランザクションの需要が多い場合、Lightning に対する需要が増えると推測されるだけです。ですので、何としてもチャンネルを開設した方が良いでしょう。それが、前に述べた理由です。課題は、高額な手数料環境ではなく、変動しやすい手数料環境です。なぜなら、一定の高額な手数料環境では、複数のビットコイン取引を行う場合、ライトニングチャネルを開くことが常に理にかなっているからです。。オンチェーンよりもオフチェーンで行う方がコストを節約できるため、オンチェーンで行うよりも Lightning で行う方が良いでしょう。したがって、ビットコインに興味があるのは常に理にかなっています。ビットコインに興味がないのなら、それは意味がありません。トランザクションを実行するために、USDT や別のトークンなどの別のソリューションを見つけてください。ビットコインを使用したい場合、手数料の支出を最適化する方法はライトニングのみです。

ステファン　クリスチャン、何か付け加えることはありますか？

クリスチャン　そこで、私はカストディアルと非カストディアルの話に戻り、おそらく 1 つの側面を付け加えたいと思います。それは、ビットコインコミュニティとして、ユーザーが非カストディアルソリューションよりもカストディアルソリューションを選択したことを非難したり恥じたりする傾向があるということです。しかし、カストディアルオプションの方が使いやすいこともよくあります。なぜなら、カストディアルオプションにはそれほど複雑な要素がないからです。そして、Greenlight では、基本的に、ノンカストディアルの性質をどこまで押し進めることができるかを確認することが目標の 1 つでした。なぜなら、できる限り簡単ではないものの、できる限り簡単なシステムを作りたいからです。そして私はビットコイナーなので、ユーザーの資金を保持し続けるのは絶対に快適ではありません。したがって、カストディアルのオプションがあることは、私にとっては決して快適ではありません。しかし、ユーザーがより使いやすいカストディアルオプションを選択する可能性があることには問題ありません。それはユーザーにとってマイナスなことではなく、私がユーザビリティに欠けているので改善する必要があると受け止めるべきです。そして、願わくば、「単に使いやすかっただけ」という言い訳がもはや有効な言い訳にならないように、ユーザー向けのカストディアルソリューションに近づき、競合できるようになることを願っています。なぜなら、サービスのプロバイダーとして私たちにできる唯一のことは、これらのユーザーに、彼らが取っているトレードオフを確実に認識させることだからです。また、ユーザーが本業に取り組み、契約上の義務がある可能性のあるカストディアルソリューションを選択することを希望する場合は、それで問題ありません。しかし、私たちはいつも、ノンカストディアルなシステムを作りたいと思っていました。カストディアンと競争するのは私たち次第であり、よく分からないユーザーに怒鳴ることはありません。

ステファン　そうか。うん。人々が話題にする興味深い分野の 1 つは、ライトニングアドレスのようなものだと思います。それはあなたたち二人ともよく知っていると思います。そしてさらに以前に、非同期支払いについて話していました。それが答えの一部だと思います。

ロイ　おそらくBOLT12 は、おそらくノンカストディアルが答えの一部である可能性があります... これは非同期支払いの一部であり、ライトニングアドレスもサポートできるようになります。ノンカストディアル環境でライトニングアドレスをサポートする際の主な課題は、オフラインで受信できるかどうかです。HTTP サーバーの実行には他にも依存関係があり、これらを軽減または外部化することで、エンドユーザーにトレードオフをより適切に伝えることができます。それは脇に置いておきましょう。たとえば、Breeze アプリが現在ライトニングアドレスをサポートしていない理由は、ユーザーがオフラインのときに資金を送金する信頼できる方法がないためです。これがライトニングアドレスの主な使用例です。青信号環境でのモバイル通知によるものであっても、非同期決済の実装で予想されるプロトコルの変更によるものであっても、適切なインフラストラクチャを整備できれば、ライトニングアドレスはノンカストディアルな方法で実装されます。

ステファン　そこで、より一般的かつ広範囲にライトニングプロトコルに関する話題に移り、皆さんが最も興奮していること、プロトコルに導入されることを最も望んでいることを知りたいと思っています。

クリスチャン　上記のすべて。

ロイ　非同期支払いについては触れました。現在、スタックレス決済やチャネルジャミングに関する探査、研究、議論が行われている分野があり、それはライトニングにとって非常に重要だと思います。したがって、スタックレス決済は重要だと思います。私にとって非同期支払いは最優先事項です。そして、支払いの信頼性の向上は常に研究され、改善されているものだと思います。LND がルーティングアルゴリズムで行っている作業について、エールを送ります。ルーティングの信頼性には改善の余地があると思います。

クリスチャン　うん。信頼性に関しては間違いなく同意する必要があり、René Picard の最小コストフローソリューションと超過支払いソリューションについて言及する価値はあります。したがって、これらはすべて進行中の実験であり、私たちはそれらを実際にテストするためのインフラストラクチャを構築することでそれらの取り組みをサポートし、A と B のどちらが優れているかを確認するための検証指標のようなものを提供したいと考えています。もちろん、それらに加えて、オールディーズ、スプライシング、今で言うところの Eltooまたは LN シンメトリーも持っています。そして、どちらも順調に進んでいます。できればすぐに手に入れることができると思います。スプライシングによりチャネル資金の管理が容易になり、チャネルと L2 から支払うだけで済み、もちろん LN 対称であるため、オフチェーンからオンチェーンにホッピングするようなことが過去のものになる可能性があります。これは、ライトニングチャネルを構築する方法に関する別の提案です。しかし、それを超えて、マルチパーティチャネルを構築し、現在の更新メカニズムが抱える欠点の一部を排除する方法が重要です。前述したように、バックアップは危険であり、現在のプロトコルでは状態を追跡するのがかなり難しいという問題があります。それは LN 対称性によって大幅に単純化されています。でも、そうですね、しばらくの間、私の欲しいものリストには同じものがいくつかありました。そしてそのうちのいくつかは確実に実現しつつあります。だからそれを楽しみにしています。そしてもちろん、非同期決済はオフライン決済を可能にするために必要なソリューションであるため、大きな前進です。そして、きっぱりと。

ステファン　興味深いですね。あなたたちは両方ともスプライシングについて言及しました。Dusty Demon がそれに取り組んでいることは知っています。彼はそれについていくつかの話し合いを行っている。私は彼が BGC++ とマイアミで開催された Bitcoin 2023 でそれについて講演しているのを見ました。これは興味深いことです。なぜなら、LSP の観点からすると、たとえばそのユーザーの資本の管理が容易になるからです。そして、ユーザーにとっては、そうする必要がなくなり、より簡単になるのです。おそらく、チャンネルを切り替えたり、常に新しいチャンネルを設定したりする必要がなくなり、少し楽になるのではないかと思います。それがスプライシングの主な利点の1つだと思います。

ロイ　具体的なユースケースに合わせて簡略化してみます。つまり、流動性管理は、ルーティングノードと LSP にとって常に課題となります。流動性管理の改善、流動性を最適化するためのツールセットは、LSP ビジネスを成功させるために非常に重要です。したがって、ツールセットに含まれるツールが増えれば増えるほど、流動性を最適化し、実際に必要な場所に流動性を効率的に割り当てることができます。具体的な使用例として、LSP がエンドユーザーノードとのチャネルを開くとします。ユーザーは数回の支払いを行っており、流動性が十分にあるため、ユーザーはチャネルを使用してライトニングを使用するのをやめたようです。これで、チャネルの LSP 側で活用されていない流動性が得られます。スプライシングは、この流動性を閉鎖せずに他のチャネルに再割り当てする方法です。したがって、現時点では、これを行うには、ユーザーチャネルを閉じる必要があります。これは、クローズドチャネルに対処するためにエンドユーザーに UX への影響があることを意味します。資金はチェーンに戻されるため、ユーザーは自分のチェーン資金をどうするかを決める必要があります。代わりに、スプライスアウトツールを使用すると、未使用の流動性を再割り当てすることができます。エンドユーザー側ではなくLSP側にある流動性を別のチャネル、うまくいけばライトニングで実際にアクティブではないユーザーよりもアクティブになる別のユーザーに再割り当てします。なぜなら、結局のところ、ライトニングに固有のビジネスモデルは、ライトニング料金を得るためにチャネルを可能な限り再利用することだからです。もう一つの具体的な例は、クリスチャンが言及したようなものです。ちなみに、スワップは常にエンドユーザーのツールボックスの一部になると思います。しかし、ユーザーがオンチェーンアドレスを支払うために接続したいと思うのは、それほど簡単なことではありません。ユーザーがチャネルを開いたままにしておき、その後のインバウンド流動性が必要な場合には、スワップが理にかなっていると思います。したがって、それはそれほど簡単ではありませんが、間違いなく、たとえば次のような能力があります。スワップせずに直接チャンネルを開き、オンチェーン残高からチャンネルを接続します。これは間違いなく、ユーザーエクスペリエンスを向上させるためにツールセットに必要なもう1つのツールです。そうすれば、サブマリンスワップのようにチャンネルを切り替える必要はありません。そして、既存のチャネルからすべての資金を流出させたり、リバース・サブマリン・スワップを行わずに送金したりするツールを提供することさえ、別のツールです。したがって、接合は非常に重要です。ちなみに、まだ言及していないかもしれませんが、流動性管理はまだ進行中のトピックです。マイナス手数料を導入するという提案もあります。発信手数料に加えて着信手数料を追加するという提案もあります。したがって、流動性配分全般についてはさらに改善が見られると思います。

ステファン　つまり、LSP とウォレットプロバイダー用のツールボックスにさらに多くのツールが含まれているということだと思います。これは、LSP としてのコストを下げるのに役立つかもしれません。その結果、その一部はエンドユーザーの節約に回せるかもしれません。おそらく、LSP には適切なツールセットがないため、今日ユーザーは一定の料金を支払っているのでしょう。彼らが必要としているもの。したがって、長期的には、すぐにはではないかもしれませんが、長期的には、LSP 間に競争力学が見られることになるでしょう。そしておそらく、それによって手数料がわずかに下がる可能性があると言えます。

ロイ　絶対。そして、それはコストをカバーすることではありません。LSP は非常に儲かるビジネスになるでしょう。それはお金を稼ぐことです。それは収益を生み出すことです。ライトニングネットワークのトラフィックを増強することで収益が得られます。この防御動作と同様に、Lightning ではコストを節約するために採用されています。防御的になる必要はありません...それは節約ではありません。それは稼ぐことです。適切なインセンティブを導入する必要があります。誰もがお金を稼ぐ必要があります。私たちは、より多くの収益を得るために、Lightning トラフィックを増強したいと考えています。その代わりに、私は自由市場を信じています。その代わり、さまざまな LSP がエンドユーザーをめぐって競合する競争環境が生まれるため、エンドユーザーのコストが削減されます。

クリスチャン　ここではインセンティブが非常に調整されています。

ステファン　それで、クリスチャン、あなたの観点から、LN-Symmetryとその利点のいくつかについて少し言及したと思います。それで、おそらく、何か最新の考えはありますか、それとも基本的には、Eltooまたは LN-Symmetryを持つことで得られる利点を提供するための準備やチェックテンプレートの検証などを確認したいということと同じですか。バックアップの点でメリットがあり、将来的にはこのマルチパーティチャネルのアイデアが得られる可能性があります。

クリスチャン　はい。したがって、Eltooに関する前回の議論は、ほぼ最新の内容であると思います。このメカニズムを構築するための要素を得るには、APO またはCHECKTEMPLATEVERIFYとCHECKSIGFROMSTACK のようなものが必要です。悲しいことに、CHECKTEMPLATEVERIFYだけでは十分ではありません。これは多くの人が最初に誤解したことであり、ちなみに私もそうでした。したがって、残念ながら、CHECKTEMPLATEVERIFYを取得する場合は、CHECKSIGFROMSTACKが必要です。しかし、これらの提案は両方とも非常に一致しており、どちらも Eltoo を有効にするだけでなく、しかし、私が聞いた限りでは、Burak の Ark、または Ark の改良版とも言えます。それで、遅かれ早かれそれらを手に入れることができると思います。その間、あなたが最近話したグレッグは、もちろんLiquid、Elements、Liquidの上に構築された概念実証に取り組んでいると思います。そしてそれはかなりきれいに見えます。そして、彼が明らかにしたすべての詳細と、Eltooの設計中に私が問題を 10,000 フィートの鳥瞰図から見たときに見えなかった種類の小さなハードルのすべては、間違いなく大きな勝利であり、一度得たものは再利用できます。 APO または CTV。したがって、私はそれらを入手できると楽観的であり、入手した時点でこのスタックを構築する方法についての知識を得ることができます。彼らはバックグラウンドで煮詰めてきましたが、これがビットコインにとって正しい方法だと思います。新しい機能を入手するのに最も早い方法ではないかもしれませんが、最も安全な方法です。したがって、煮詰める時間を長くすればするほど、どのような代替案があるのか、提案のそれぞれをどのように改善できるのか、そしてこれらの提案のどれが使いやすさを最大化し、ビットコインに導入するリスクを最小限に抑えることができるのかについてのアイデアが深まります。あの道の先にある。ということで、今の状態にはとても満足しています。たくさんの実験が行われ、かなり良いものになりました。それにも関わらず、私たちはまだ APO と CTV を持っていませんが、必ず手に入れます。

ステファン　うん。そうですね、そう願いましょう。それも面白いと思います。たとえば、グレッグがElementsとLiquidについてやろうとしているように、人々がそれを証明する時間はあるでしょう。そしてそれは、人々にとって、それが商業的需要があること、それが安全であることなどを証明することになるでしょう。きっともっと仕事があるでしょう。それでは、この辺で終わらせていただきたいと思います。そうですね、たくさんのことについて話してきたと思いますが、重要なアイデアのいくつかを要約する必要があるとしたら、基本的に、ライトニングはチェーンの使用を最適化するのに役立ちます。Greenlight は基本的に、ノードの実行を支援する Blockstream のサービスです。ただし、ロイのおっしゃるように、最近ではノードという用語が少し混乱してきています。そのため、Greenlight のアイデアは、ビルダー、開発者、起業家にとって役立ちます。ライトニングサービスを構築したい場合は、Greenlight をクラウドノードとして使用できますが、ユーザーは依然として自分の携帯電話などに自分のキーを保持しています。そして、Breeze SDK はパッケージ化された Greenlight のようなもので、Lightningのことについてはあまり考えず、自分の能力と構築しているものだけに集中したい人を簡単にします。これが私の非常に高度な理解だと思います。最後に何か他に言及したいことはありますか?

ロイ　繰り返しになりますが、私はビットコインを基盤とする時期が来たと考えています。ここではジョンの用語を盗用しています。ビットコインをベースにして構築してみましょう。Greenlight、LDK、Breeze SDK で現在提供されているツールを使用すると、ライトニングの専門家でない人でも、ライトニングの支払いを自分のスタックに統合することが非常に簡単になると思います。私はLightningに関して非常に強気です。エコシステムの成熟度がわかります。私たちが得ている牽引力と、ビットコインとライトニングに接しており、ライトニング支払いを独自のソリューションに統合したいと考えている視聴者から得られるリードがわかります。今がその時だ。待つ必要はありません。それで、行って実験してください。スタックに関する情報を得るために、どのような媒体でも私に連絡を取ることができます。しかし、今がその時です。うん

クリスチャン　これ以上にうまく言えなかったでしょう。私たちは皆、ビットコインに基づいて構築しています。したがって、Greenlight または Breeze SDK を試してみたい場合は、どちらかに連絡してください。簡単なツアー、必要なアクセス、サポートを提供します。信じられないほど興奮しました。ロイ氏が言うように、私たちは、私たちが気づいていないさまざまなユースケースが突然現れるのを見てきました。ラスティ・ラッセルがいつも言うように、私たちは小さな部屋で何かを構築しているエンジニアです。しかし、実際に革新を行っている人々は、ユーザーに見える興味深いものを実際に構築しており、これらの新しいエクスペリエンスを発明しているのです。そのため、新しくて革新的なものが登場すると、私たちはいつも驚かれます。驚きを与え続けてください。

ロイ　そして、私たちはまだ何も見ていません。つまり、現時点では、エコシステムがエコシステムの状態であるということは、Lightning の既存のソリューションが既存の法定通貨ソリューションを模倣しようとしているようなものです。プログラマブルで、許可の必要がなく、アクセス可能なお金に対するイノベーションの力のイノベーションでは、ユーザーエクスペリエンスと、人間が一般的に価値と対話する方法にそれがもたらす可能性のある変革を実際に見ていないと思います。ですから、今後もできることはたくさんあると思います。次に何が起こるか楽しみです。

ステファン　素晴らしい。そうですね、見てください、私たちは多くのことについて徹底的に話してきたと思います。できればリスナーはそこから何らかの価値を感じ取って、外に出て何かを構築したり、ビットコインとライトニングの宣伝に協力したりする準備ができていることを願っています。すべてのリンクはショーノートに記載されています。ということで、リンクを貼っておきます。そして、クリスチャンとロイ、今日はご参加いただきありがとうございます。ご利用いただき誠にありがとうございます。有益で勉強になる内容だと思っていただければ幸いです。stephanelivera.com にアクセスし、Lightning をベースにした構築に興味がある人々とこの番組を共有してください。聞いてくれてありがとう、シタデルでお会いしましょう。