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

2023-06-25T01:58:41Z

LiveraのGreenlightのポットキャストがネットワークの将来像を考えるのに面白かったので残しておこうかなと思い。一通り確認してるけどwhisper使ってるので荒いところはご容赦
【音声本体はこちら】
SLP488 FUTURE VISIONS OF LIGHTNING, GREENLIGHT & BREEZ SDK WITH CHRISTIAN DECKER AND ROY SHEINFELD

■ゲスト
Christian Decker (Blockstream)
Roy Sheinfeld (Breez)

■テーマ

What has improved about Lightning over time
Lightning in a high fee environment
What Greenlight is
What Breez SDK is
Is anything changing on the existing Breez app?
Core-lightning contrasted with other implementations
Lightning protocol improvements

ーーーーーーーーーーーーー

ステファン　クリスチャンとロイ、ショーへようこそ。

クリスチャン　やあ、ステファン。感謝します。

ロイ　ありがとう、ステファン。

ステファン　そこで、Lightning の将来のビジョンについて、また、皆さんが明らかに Greenlight、Breeze、Breeze SDK を使って取り組んでいることについて少しお話します。それで、そうですね、少しずつ始めてみましょう。Lightningの未来はどのようになると私たちは考えていますか。私は知っています、ロイ、あなたはこのこと、このピアツーピア経済の考え方について詳しく書いています。それでは、最新の考えをいくつかお聞かせください。それはまだですか、それはまだあなたの見解ですよね？

ロイ　はい、ここ数週間で大きな変化はありませんでした。プラハからLightningが戻ってくることについては、私はこれまで以上に強気だと言えます。最近のLightningの成熟度には本当に驚かされます。私があなた、ステファン、そして皆さんと出会ったプラハの一週間は、何千人もの人々が一週間Lightningを頼りに暮らしていたと思います。したがって、プラハをマイアミでの以前のカンファレンスと比較してみると、さらには 2019 年にベルリンでクリスチャンに初めて会ったとき、何もうまくいかなかったとき、私はテクノロジーの成熟度を見て完全に驚きました。これは私が考えていること、現時点での私たちの考えと非常に一致しています。つまり、Lightningはテクノロジーの面で一定の成熟度を達成しており、次のレベルに進む準備ができています。私たちが考えている次のレベルは、ライトニング決済をより伝統的な主流のユースケースに統合し始めることです。

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

クリスチャン　いや、ロイはほぼ理解していると思う。ここに到達するまでには長い道のりがありましたが、その長い長い取り組みの結果がますます目に見えるようになっているのは間違いありません。そして、私たちは、技術的にあまり技術的ではないユーザーのオンボーディングをさらに開始しようとしているところだと思います。そして、これは非常にエキサイティングなことです。なぜなら、これを続けているのはビットコイナーの信念ではなく、実際に実際の定命のユーザーによるLightningの使用だからです。そしてそれは信じられないほどエキサイティングです。そしてロイが言ったように、ついに、エンドユーザーにとっても魅力的なパフォーマンスと成功プロファイルを手に入れることができました。そのため、これもバックグラウンドで多くの作業が行われてきましたが、最終的には使用できる段階に達し、さまざまなユースケースやさまざまな用途に向けてさまざまなユーザーによる多くの実験が見られるようになりました。信じられないほどエキサイティングな時代です。

ステファン　それで、その話題に関して、2019 年 10 月のベルリンでのライトニングカンファレンスと比較して振り返ってみると、何が改善されたと思いますか。大きな改善は何だと思いますか当時と今の間に見られる、2023年6月？Lightningの使い方における最大の改善点は何だと思いますか?

クリスチャン　時間の経過とともに小さな変更が数多く行われてきたと思いますが、それらは本質的に累積的であり、私たちがよく話題にするこれらの巨大な機能のいくつかほどエンドユーザーには見えないことがよくあります。しかし、ライトニングノードの実行は確かに容易になり、ノード自体のパフォーマンスも向上し、支払いの成功または完了までの時間とその成功率も向上したと思います。そしてそれは技術開発によるものであると同時に、ネットワーク自体の進化によるものでもあります。したがって、両方の側面において、それは非常に密接に関連しています。

ステファン　ロイ、あなたの観点から見て、大きな改善は何だと思いますか? それはただ、それはうまくいくだけですよね？

ロイ　それが私たち全員が見たいものです。ビールスタンドに行って、ビールの代金を即座に支払いたいのですが、それは機能し、待つ必要はありません。ビールを購入するまで数秒かかります。そのため、物を購入するというユースケースは、以前よりもはるかに確実に機能します。現在の状況に到達するためにバックグラウンドで多くの作業が行われていますが、まだ完璧ではありません。まだまだ改善の余地がたくさんあるような気がします。私はいつもライトニングは流動性ネットワークだと言います。したがって、流動性、ネットワーク内で見られる流動性の量、ネットワーク内で見られる投資の量という点では、過去よりもはるかに高くなっています。そして、ネットワークの流動性が高まるほど、支払いの信頼性が高まり、より多くのユーザーがネットワークを使用するようになります。したがって、テクノロジーの堅牢性と成熟度に関しては、私たちは間違いなく大きな進歩を遂げています。

ステファン　お二人にお聞きしたいもう 1 つの分野は、オンチェーン手数料の観点から、最近の高手数料期間を見たということです。その一部はinscriptinによって駆動され、inscriptionは退化します。しかし、これはLightningを利用した興味深い例だと思います。そして、Lightningがどうなったかという観点から、あなたがどう思うか聞きたいと思います。あなたの経験では、この最近の料金が高額な時期に、ライトニングネットワークはどうでしたか?

クリスチャン　したがって、全体的には私たちにとってポジティブな経験になったと思います。それは私たちにとって、少々強制的な任務であり、火の試練でした。そして、モデルのいくつかの部分が壊れ、他の部分は正常に動作していることに間違いなく気づきました。そして今、それらの学んだことを本質的に取り入れて応用するのは私たち次第です。そのうちの 1 つは、たとえば、コアライトニングには手数料ゼロの HTLC アンカーが存在しなかったということです。そして今、それらを入手するか、プルリクエストが完了するとすぐに入手できるようになります。また、手数料を持参するなどの手法は、将来の手数料がいくらになるかを本質的に推測する必要がないため、このような高額な手数料の時期に非常に成功しています。そして、その将来はこのような高額な手数料環境になるかもしれません。それが私たちが与えた最大の影響だと思います。また、チャンネルが確認されなかった場合、または適時に閉鎖されなかった場合、チャンネルの有効期間がどのようになるかが明確ではないというレポートもいくつか見られました。たとえば、この仕様では、2 週間後に受信したチャネルを忘れることができますが、多くのユーザーが確認しないチャネルで基本的に永遠に待機し、その後確認されましたが、そのチャネルがアクティブ化されなかったのを見てきました。、私たちの相手はすでにそのことを忘れていました。したがって、この場合、それはプロトコルであると同時にユーザビリティの問題でもあります。私たちはこれらのフィードバックをすべて収集し、これらの経験から可能な限り学ぶよう努めます。

ステファン　ロイ、あなたは最近Inscriptionについても書いたと思います。それで、inscriptionと高額な手数料環境、そしてライトニングがそれにどのように対処しているかという観点から、あなたの考えを少しだけ聞かせていただけますか?

ロイ　はい、確かに。したがって、誰もが高い手数料環境を望んでいると思います。料金の高い環境は、より安全なネットワークを意味します。私たちは、マイナーの報酬やマイナーのインセンティブの観点から、常に高額な手数料のブロックチェーン環境で暮らしたいと考えています。彼らにとって、オンチェーン取引から多くのお金を稼ぐことは非常に重要です。だからそれはポジティブなことだと思います。他にも良い意味がいくつかあると思います。1 つ目は、これはLightningの必要性を示しているだけです。ある種の誤解があると思います。明確にしてみます。Lightning はビットコインのスケーリングソリューションではありません。つまり、ビットコインブロックチェーンは実際にはスケーリングできません。Lightning は、チェーンを操作する特定のユースケースを最適化したものです。つまり、ビットコインを必要としない人は、Lightningも必要ありません。Lightning はオンチェーンのインタラクティブ性を解決するものではありません。Lightning は、オンチェーンのインタラクティブ性を最適化する予定です。したがって、ライトニングを捉える 1 つの方法として、複数のオンチェーントランザクションを 2 つのオンチェーントランザクションに圧縮する方法として、チャネルのオープンとチャネルのクローズを考えることができます。したがって、チャネルを開くと、チャネルを開いてから閉じるまでの間に無数のトランザクションが行われます。しかし、ライトニングチャネルがなかった場合は、代わりにオンチェーントランザクションを使用していたでしょう。そういう意味で、Lightningはビットコインのスケーラビリティ問題を解決する魔法の解決策ではないと人々に理解してもらいたいのです。なぜなら、ブロックチェーンは定義上拡張できないため、ビットコインのスケーラビリティ問題を解決する方法はないからです。ライトニングチャネルのこのエンティティを作成することで、オンチェーンの使用を最適化する方法です。そしてその点で、この高額な手数料環境の期間中にオンチェーントランザクションを行いたいと考えていた人は皆、今ではライトニングの必要性を理解しています。そして現在、ビットコインブローカー、ビットコイン取引所、ハードウェアウォレットから問い合わせが常に寄せられていることがわかります。今、誰もがLightningの導入を急いでいます。料金が高騰するため、Lightningインフラを整備する準備が必要であることを理解しているからです。つまり、Lightningに関しては正味のプラスです。Ordinals の実験にはもう 1 つ良い点があると思います。それは、ビットコインを交換媒体として使用する、つまりビットコインをお金として使用する別のユースケースであると人々が理解しているということです。これらの Ordinal ウィザードは、ビットコインストレージの料金をビットコインで支払っています。そして、これらのマイナーは、これらのウィザードがビットコインで支払う結果としてビットコインを稼いでいます。彼らは支払いを行っており、マイナーは費用をビットコインで支払っています。つまり、これは、ビットコインが実際の通貨として使用されることを示す別のユースケースです。彼らが何にお金を払っているのかは本当に気にしません。彼らは望むものは何でも支払うことができます。このinscriptionに実際の有用性があるかどうかはわかりません。私の個人的な考えは、彼らがやっていることには本当の価値はない、ということです。しかし、私は市場と議論したいわけではありません。彼らがこれらの JPEG に対してビットコインで支払っている限り、私は気にしません。

ステファン　Lightningを特効薬のようなものとみなすのではなく、最適化についてあなたが言っていたことも、正当な指摘をしていると思います。おそらくこれは、おそらく私たち全員が長年にわたって受けてきた一連の批判だと思います。それで、続けてください、クリスチャン。

クリスチャン　ロイが先ほど述べた圧縮に関するコメントに戻りますが、オフチェーンプロトコルを使用することで、力の乗数を使用していることに注目することが非常に重要だと思います。私たちはオンチェーンの能力をより有効に活用しています。しかし、スケーラビリティは、一般的にライトニングおよびオフチェーンプロトコルがビットコイン自体にもたらすものの 1 つの側面にすぎません。突然、実際にチェーンとやり取りしたい時間を選択できるようになり、希望する料金を選択できるようになりますよね? 一方的なクローズを除いて、チャネルをいつ開くか、いつ閉じるかを基本的に選択できます。そして、基本的にその時点で料金を使用することになります。これにより、チェーンインタラクションの負荷を時間空間全体に分散し、時間の経過に伴うこれらの料金の変化を本質的に平滑化することができます。しかし、これらのスケーラビリティと手数料の機会に加えて、リアルタイム支払いなど、真に斬新なユースケースをビットコイン空間にもたらす機会もありますよね。ライトニング以前は、リアルタイム支払いはできませんでした。期待して10分待つ必要があります。手数料が高ければさらに長くなります。そしてその一方で、プライバシーとの新たなトレードオフがもたらされます。一方、オンチェーン決済では、あらゆるやり取りの永続的な痕跡が残ります。オフチェーンの場合は異なります。それが良いか悪いと言っているのではありません。私が違うと言っているのは、今あなたはリアルタイムで他の人に支払いを行っていることを伝えているからです。ただし、その支払いは、あなたとやり取りしているノードとのみ共有されます。その一方で、その情報は、たとえばブロックチェーン上に永久に保存されるわけではありません。これらは、Lightningがもたらすもののさまざまな側面であり、スケーラビリティもその 1 つです。私も完全に同意します、それは特効薬ではありません、しかし、それによって、生のビットコインよりも 2 ～ 3 桁大きく成長することは簡単に可能になります。そしてそれを超えて、私のような研究者にとって、新たな鍵を握る次のステップのようなものを見つけることは再び興味深いものになります。そして私たちは最近、このような発展をかなりの数見てきました。はい、それらのいくつかについても後ほどお話したいと思います。

ステファン　ええ、もちろん。そして、ライトニングは、あなたが言ったように、一方的なクローズを除いて、チェーンに行く時間を選択できると言っても過言ではないと思います。たとえば、手数料が安いときは、私はチャンネルを皆さんに公開することができ、その後、あらゆるLightning Networkの取引を行うことができます。そしてもちろん、理想的には瞬時に稼ぐことができる人々にとっては、それはある種意味がより理にかなっています。したがって、Lightningで稼いで、その後、Lightning以上に費やすことができれば、チェーンから離れた状態をより長く続けることができ、より理にかなっています。おそらくそれが、それがより理にかなっている理由の一部でもあると思います。Lightningで稼ぐ人が増えれば、Lightningへの支出も増えるのは当然だと思います。したがって、おそらく私たちはまだそのフライホイールを実際に構築していないかもしれません、そしておそらくそれは起こるでしょう、おそらくそれは来るかもしれませんが、それは基本的に私たちが目にすることの1つです。そして、本当に興味深いもう 1 つの点は、Lightningがすでにチェーン自体から多くの負荷を取り除いている可能性があるということですよね? なぜなら、そうでなければチェーンにヒットし、ブロックされ、より高い手数料が発生したであろう数十万のトランザクションがすでに存在する可能性があるからです。しかし、そうではありません。このポッドキャストのすべての価値、ノストラのザッピング、ビットリフィルライトニング、またはその他のライトニングの使用がチェーンに移行していないため、それらはチェーンから外されていました。その意味では、すでに少なくとも少しは役に立ちましたが、将来的にはさらに役立つ可能性があります。

ロイ　そうですね、21satsのzapがチェーンに送られるとは思いません。したがって、ユースケースは 2 つあると思います。1 つは、Lightningがなければチェーン内で実行されたであろうトランザクションです。ライトニング専用のユースケースや、ポッドキャスティングのザップなどのバリュー・フォー・バリューを中心としたリアルタイム決済のユースケースなど、一種の新しいユースケースがあります。間違いなく、人々はトランザクションの数を認識していないと思います。それはLightningの中で実行されます。現在、月間トランザクション数は数千万件に達していると思います。もしLightningが確実に存在しなければ、この量のかなりの量がチェーンに送られたでしょう。クリスチャンがチェーンにいつヒットするかを選択することについて述べたことの別の技術的な例は、それが私たちの使用法、または単に私たちの使用法ではなく、zero confirmation channelの使用法です。エンドユーザーは、オープントランザクションがいつチェーン内で実行されたオープンチャネルトランザクションであるかを実際には選択しません。トランザクションがいつ確認されるかを選択するのは LSP であり、LSP はチャネルを確認したいときはいつでも料金を変更できます。したがって、高料金環境によって高料金環境を軽減する別の方法は、実際には問題ではありません。LSP にとって問題となるのは、料金の変動性です。環境が一貫して高い場合は、1 つの緩和戦略が必要になるというわけではありません。手数料が常に高騰しており、非常に不安定な環境の場合は、小さな挑戦が必要です。LSP の場合は扱いがさらに難しくなります。

ステファン　うん。わかりました、素晴らしいです。それで、皆さんが構築しているものについて少し話しましょう。クリスチャン、あなたは明らかに、Blockstream が提供する新しいサービスである Greenlightに深く関わっていることは知っています。そして、前回あなたが番組に出演したときも、そのことについて話したと思います。しかし明らかに、それ以来バックグラウンドで多くの開発が進行していると確信しています。それでは、概要だけ説明していただけますか?Greenlightとは何ですか? どうなるでしょうか？

クリスチャン　そこで私たちは、ある時点で、ユーザーを特にビットコインとライトニングにオンボーディングする方法が本質的にほとんど破綻していることに気づきました。コミュニティとして私たちは安全面で誤りを犯す傾向があり、それは間違いなく行く道です。しかし、これは、「おい、ここにマニュアルがある、それを読んでください」と言われている多くのユーザーにとっては不快なことかもしれません。そして 2 番目のマニュアル、それが Lightning マニュアルです。そしてLightningマニュアルの安全性です。そして、これらをすべて読んだ後にのみ、最初のビットコインに触れることができます。そして、ユーザーは最初のマニュアルを半分まで読んだところで、今のところビットコインとライトニングを学ぶだけで終わってしまうという理由で諦めてしまうかもしれません。したがって、その設定を逆転させて、Lightning で何ができるかを最初に示し、その後で、その背後にあるテクノロジが何であるか、安全に行う方法について学習するよう強制または奨励する必要があると思います。独自のインフラストラクチャを管理します。そこで私たちが疑問に思ったのは、Lightning ノードを実行するときに注意すべき詳細がたくさんあるということです。データベースをどのように保護しますか? 鍵をどのように保護しますか? watchtowerを使用してチェーン上のフットプリントをどのように確保しますか? ノードがオンラインであることなどをどのように確認しますか? これらすべての操作上の側面は、新規ユーザーにとって非常に圧倒される可能性があります。そこで私たちが考えたのは、どうすればその責任の一端を担うことができるだろうかということでした。私たちの側では、ユーザーの資金には一切触れずに、私たちは、使いやすさの点で保管ソリューションと競合できるシステムを作りたいと考えていました。しかし、私たちはそれを保管したくないのです。そこで、その一部はノード、つまり Lightning ノード自体であり、キーやノードを制御している人物と同じ種類の制御ドメインである必要はない、という考えが浮かび上がりました。したがって、私たちがやったことは、基本的にノードをセットアップすることです。私たちは、「わかりました、ここにはクライアントと自己完結型の署名者があり、ユーザーがアプリストアからアプリをインストールするのと同じくらい簡単に実行できるようになりました」と言いました。さらに、実際に実行してノードをセットアップし、そのノードを実行して、そのノードで危険な操作が行われないようにするという、より複雑な運用面があります。Lightning ノードのバックアップを実行することさえ危険であることを覚えておいてください。つまり、Greenlight とは本質的に、「OK、私たちがデータベースを管理します、私たちがwatchtowerを管理します、私たちがノードを管理します、そしてアプリ開発者としてあなたに与えるか、それとも終わりです」という思考プロセスの終わりです。ユーザーの場合、基本的にクライアントとして機能するライブラリを提供します。これにより、ノードを操作できるようになり、署名者としても機能します。これは基本的に、資金には決して手を出さないものの、多くのユーザーにとって不快なインフラ管理を実行できることを意味します。したがって、ユーザーが Lightning の使用に十分な経験を積んだら、今度は、Lightning ノードの実行方法について教育するために、より多くの情報を提供できるようになります。そして最終的に、私たちの目標は、彼らを独自のインフラストラクチャにオフボードすることです。なぜなら、彼らは完全に自己主権のビットコインユーザーであり、安全にそうするための経験と知識を持っているからです。

ステファン　少しだけまとめます。したがって、Greenlight は本質的に、Blockstream がそのユーザーまたは開発者のためにクラウドノードを実行しているようなものです。これは実際に開発者が使用している可能性があるため、開発者にとってより関連性があるとします。そして、そのアイデアは、「ブロックはどこですか?」に関するデータを提供するクラウドノードインフラストラクチャを実行しているということです。ブロックチェーンの状態はどうなっているのでしょうか? 騙されたり色々なことがある場合のwatchtowerは何ですか？しかし、重要なのは、Breeze のようなスマホアプリであろうと、このようなものであろうと、クライアントのデバイス内に存在することです。しかし、Blockstream と Greenlight は開発者向けのインフラストラクチャを実行しており、開発者はユーザーが Lightning にすぐに乗り込めるよう支援しています。それがゲームやアプリなどの一部であっても。

クリスチャン　その通りです。うん。そして、アプリ開発者にとっての大きな利点は、Lightning の専門家である必要がないことです。なぜなら、Lightning ノードをアプリケーションにバンドルすると、突然、それを駆動する方法、自動化する方法、安全性を確保する方法を知らなければならなくなるからです。Greenlight を使用すると、これらすべては基本的に API を呼び出し、アプリ内で小さなソフトウェアを実行することに集約されます。アクティブな管理は必要ありません。

ステファン　ロイ、あなたの話を少し聞いてみましょう。明らかに、あなたは Breeze のチームを率いています。あなたはこれを持っています、ご存知の通り、Breeze ウォレット、これは素晴らしいものです。これで、Breeze SDK が手に入りました。それで、まずそれについて少し説明していただけますか。そして、既存の Breeze に何が起こっているのか、ちょっと待ってほしいと思っているユーザーのために説明していただけますか? それは消えていくのでしょうか、それとも残っているのでしょうか？

ロイ　はい、Breeze は現在 5 周年を迎えているように見えますが、この 5 年間で私が学んだことがあるとすれば、ユーザーは気にしていないということです。正直に言いましょう。私たちがエコーチャンバーに住んでいるようなものです。私たちはビットコイナーです。私たちは気にします。私たちは鍵を大切にしています。私たちは主権を大切にしています。私たちは自分たちの自由を大切にしています。しかし、大多数のユーザーはまったく気にしません。しかし、彼らが気にしているのはビットコインの有用性であり、私たちがビットコイン分野での取り組みで過去に証明したことは、エンドユーザーに有用性を提供できるということです。これは、販売者が銀行口座を必要とせずに支払いを受け取れるようにする POS インターフェイスを通じてこれを実現しました。私たちのポッドキャストプレーヤーを使用すると、ユーザーはピアツーピアのみ、仲介者なし、中間の第三者が取り分を取得することなく、satsをあなたのようなポッドキャスターにストリーミングできることが証明されました。したがって、私はピアツーピア経済には多くの価値があると強く信じています。このようなインターフェイスを Breeze アプリケーションに追加するたびに、トランザクション数、スループット、ユーザー数が急増しました。したがって、当然のことながら、私たちの進化における次のステップは、非保管型 Lightning をサービスとして提供するために構築したインフラストラクチャを提供し、他の開発者や他の企業に Lightning 支払いを自社のスタックに統合するために提供することでした。独自のソリューションに導きます。そこに焦点を当てたいと理解し、SDK を実装するプラットフォームとして Greenlight を選択しました。これは、モバイルデバイス上でフル機能のノードを実行する際に私たち自身が経験した問題があるためです。これについては後ほど説明します。。しかし、同じノードに対して複数のアプリを実行できる Greenlight のようなプラットフォームを使用することには、隠れた利点もあります。基本的に、これは複数のアプリから Lightning 残高を再利用できることを意味します。そして、Breeze が SDK を作成しているのであれば、その SDK を使用しているすべてのアプリが同じユーザー残高を操作できるようになり、法定通貨経済や法定通貨の世界で得ているのと同じユーザーエクスペリエンスを模倣できるようになるのはごく自然なことです。 Uber、Netflix、Spotify にクレジットカードを入れるだけです。これらすべてのアプリケーションは同じバランスで相互作用します。Spotify 用の別の銀行口座はありません。Uber 用の別の銀行口座はありません。そして、Lightning で現在見られる分散したユーザーエクスペリエンス。stacker News を補充する必要があり、Fountain を補充する必要があり、Breeze と Phoenix を補充する必要があり、さまざまなサービスとやり取りするためにさまざまな残高を使用する必要があります。私たちはこれも SDK の一部として解決したいと考えました。クラウドにノードがあり、キーがユーザーのデバイス上にある Lightning ノードを実行するためのハイブリッドアプローチが、このユーザーエクスペリエンスの提供に役立ちます。あなたの質問に答えると、LND ベースの現在の Breeze アプリは廃止されません。これを廃止するつもりはありません。メンテナンスしております。私たちはこれからも開発を続けます。これは、市場のニーズを理解するためのサンドボックスのようなものです。おそらく、Taproot Assetを試してみることにします。おそらく、現在の Breeze アプリで他の機能を実験することになるでしょう。ただし、Greenlight ベースの別のウォレットを用意します。すでにベータ版の準備が整っています。Greenlight にはいくつかの問題があり、Greenlight ベータ版の正式な発表を待っています。ただし、Greenlight に対して同じユーザー、同じ Breeze ユーザーエクスペリエンスを提供する別のアプリを用意する予定です。そして、Breeze SDK を使用して Greenlight やその他のアプリケーションのスタックの残りの部分と対話する例が、現在現場や市場に存在する予定であり、すでに存在しています。

ステファン　基本的に Breeze はそのままでアプリを継続しますが、新しい Breeze SDK もあります。それは開発者を助けています。したがって、この会話は、ある種のライトニングサービスを提供しようとしている開発者やビルダー、そして起業家自身であるリスナーにとって非常に有益です。それで、私たちがそこにいる間に、それがあなたの顧客にとってどのように見えるかについて少し話しましょう。なぜなら、あなたの顧客はエンドユーザーではないかもしれないからです。顧客は、エンドユーザーに提供したいものを構築している開発者または起業家のようなものです。それは、ゲームアプリであっても、他のアプリであっても同じかもしれません。彼らが Greenlight または Breeze を使用し、そのサービスをエンドカスタマー、エンドユーザーに提供したい場合に、それがどのようなものになるかを簡単に説明していただけますか?

ロイ　はい、間違いなく。したがって、Breeze SDK は、あらゆるLightningのニーズに対応する非常にシンプルなドロップインソリューションとなることを目指しています。クリスチャン氏が述べたように、Blockstream はライトニングの使用に関するエンドユーザー部分を簡素化するために Greenlight を構築しました。しかし、それはパズルの 1 ピースにすぎません。他にも、導入すべきインフラストラクチャは他にもあります。フル機能の Lightning ソリューションを提供したい場合は、現在の状況を考慮する必要がある要素が他にもあります。Greenlight を利用したエンドユーザーノードは、パズルの 1 ピースです。パズルのもう 1 つのピースは、LSP の使用です。簡素化するには流動性プロバイダーが必要です。要約すると、LSP は、ISP がユーザーをインターネットに接続するのとまったく同じように、エンドユーザーを魔法のようにライトニングネットワークに接続するエンティティです。技術的な観点から見ると、2 つのエンドユーザーノードに対してチャネルを開きます。したがって、ソリューションの一部として LSP が必要です。そして、Breeze SDK は LSP サービスをカプセル化するだけでなく、しかし、これはオープン LSP モデルをカプセル化しており、開発者が当社の LSP サービスまたは他の LSP サービスを使用できるようにします。私たちは Synonym などの企業と LSP 標準を推進しています。これには、オンチェーンの相互運用性も含まれます。これは、オンチェーンのアドレスに資金を送受信し、オフチェーンの残高に交換する機能を意味します。したがって、オンチェーンアドレスに資金を送信してライトニングチャネルにこれらの資金を保持するか、ライトニング残高を介してオンチェーンアドレスに資金を送信します。これは、SDK が提供する非常に重要なサービスでもあります。そして、私たちが提供するもう1つのサービスは、法定通貨経済とのギャップを埋めるために、サードパーティの法定通貨のオンランプ、オフランプと提携しています。つまり、あなたが開発者、ゲーム開発者、ソーシャルネットワーク開発者、ウォレット開発者、フィンテック開発者、暗号通貨開発者であれば、ライトニング決済を独自のソリューションに統合したい場合、私たちが提供するのは、支払いの送信、支払いの送信、支払いの受け取りを行うための非常にシンプルな API です。また、基盤となるインフラストラクチャやすべてが舞台裏でどのように機能するかについて考える必要はありません。これは、私たちがLightningと対話する方法における本当に、本当に画期的な進歩です。

ステファン　つまり、最も筋金入りの Lightning 開発者は、自分で何かをして独自の開発をしたいと考えているのかもしれない、というふうに要約できると思います。しかし、実際のところ、あなたが 1 層または 2 層外側にいて、開発者であるかもしれないが、筋金入りのビットコインライトニング担当者ではない、あるいは、たとえそうであったとしても、それを実行したくないだけである場合は、あなた自身、それがおそらくあなたにとって役立つところですよね？

ロイ　あなたにとって役に立つと思います、たとえあなたが筋金入りのビットコイン開発者であっても、これは非常に役立つと思います。なぜなら、Breez SDK は本質的にオープンソースコードであり、パズルのすべてのピースを接続するグルーコードだからです。そして、部分をリッピングして置き換えて、部分の 1 つを制御したり、このグルーコードに貢献したりしたい場合は、それが可能です。これは、パズルのすべてのピースを非常に合理化された API に接続するオープンソースコードです。したがって、あなたがビットコインの筋金入りの開発者であれば、このインターフェースに多くの価値を見出すことができると思います。

ステファン　したがって、これは例のようなものかもしれません。おそらく、あなたが独自のライブラリを作成する代わりに既存のライブラリを使用したいウォレット開発者であると例えることもできます。おそらくこれは良いたとえだと思いますよね?

ロイ　うん。または、LSP、別のスワップサービス、または別のフィアットオンランプを使用しています。Greenlight ではなく、Greenlight を自分でホストしたいか、代わりにボルトを使用したいかは異なります。このミックス、マッチはすべてBreez SDK のコンテキスト内で行うことができます。

ステファン　うん。クリスチャン、続けて。

クリスチャン　うん。ハードコアなビットコイン開発者にとっても興味深いかもしれないという点に戻りますが、Breeze SDK をベースに構築し、推移的に Greenlight をベースに構築すると、実際には非カストディアルビットコイン開発者を構築することになることに留意する必要があります。自分でシステムを作るんですよね？あなたが Lightning の専門家で、Lightning アプリケーションを構築したい場合でも、非保管的な方法でノードを実行できるようにする必要があります。そのインフラストラクチャがない場合、突然、あなたはアプリユーザー全員の管理者になります。ユーザーがあなただけであれば問題ないかもしれません。しかし、ほとんどのアプリ開発者は、私たちと同じように、ユーザーのキーを保持することに快適さを感じていないのではないかと思います。つまり、箱から出してすぐに得られるものは、Breeze SDK が提供する追加サービスを取り除いたときに、その下にある Greenlight が本質的にサービスとしてのライトニングノードになるかどうかだけです。つまり、得られるのは、プログラミングできる API です。アプリユーザーの資金を管理することはできません。ユーザーはキーが保管される唯一の場所であるため、資金を管理します。したがって、あなたはその責任を負いません。また、アプリ開発者が Greenlight 上で構築するのをより容易にする追加機能が多数あります。そのうちの 1 つは、たとえば、それは、ユーザーを透過的にオフボーディングするためのメカニズムがあるということです。そのため、Greenlight に対抗してアプリケーションをプログラムする一方で、ユーザーは後で、「ノードに対する力をもっと増やしたい」と判断する可能性があります。もっとコントロールしたい、または興味がある。これが内部でどのように機能するかを見てみたいと思います。それで彼らは船から降りるかもしれない。ただし、基本的にそのノードとペアになっているすべてのアプリケーションは、新しいノードを指すように再構成する必要があります。ファイアウォールのポートなどを開く必要があります。そして、基本的にすべてのノードがstaticアドレスを持ち、それが当社のインフラ上で実行されているか、競合他社で実行されているか、またはユーザー自身の自宅で実行されているかに関係なく、アクセスできるシステムを考え出しました。それでたくさんあるんですが、アプリ開発者にとってこれらの優れたユーザビリティ機能の多くは、複雑さを隠し、人々が遭遇する可能性のあるさまざまな問題から抽象化することを利用して、アプリ開発者がインフラストラクチャの構築を開始したり、Lightning となどなど。

ロイ　このソリューションの保管上の側面について 1 つだけ言及しておきたいと思います。ここではイデオロギーの話ではありません。まあ、これはイデオロギーの問題かもしれませんが、今日の市場での顧客との会話からわかるように、過去数か月の非保管はもはや問題ではありません。これは現在の規制環境に非常に関連しています。米国および EU における最新の規制の進展により、金融機関にはユーザーのキーを保持しないよう多大なプレッシャーがかかっています。また、ユーザーエクスペリエンスの観点からも、保管ソリューションを作成することの意味がわかります。したがって、恣意的な管轄区域が保管上の解決策から除外されていることがわかります。取引所やブローカー、フィンテックソリューションなどと実際に話し合いを行っていなかった過去とは異なり、KYC と AML の要件に関しては多くの軋轢が生じています。過去数か月間、これらの機関やベンダーが私たちのところに来て、非保管ソリューションを求めてくる傾向が見られます。つまり、非保管であることは、もはやビットコインのようなハードコアなものではありません。規制環境を緩和するために、人々が非保管のソリューションを積極的に探しているという非常に具体的な傾向があると思います。つまり、言い換えれば、非集中型であることは、分散化のイデオロギーのようなものではなく、ビジネスケースのようなものだと言えます。

ステファン　つまり、顧客の資金を保持することはリスクですよね？そして、非保管システムを作るということは、単に自分が持っていなかった資金を失うことはできないという考えにすぎません。

クリスチャン　したがって、非保管ソリューションを選択することで、実際には、攻撃者が攻撃したいかもしれない貯金箱になることからビジネスを補償することになります。そして、Greenlight サービスの運営者であっても、資金を使って何もできないことには細心の注意を払っていますよね。なぜなら、署名者はあらゆる操作を独自に検証し、「はい、これは実際には」であることを検証するからです。これはユーザーのアクションによってトリガーされ、サインオフしている状態の変更は実際にユーザーの意図と一致します。これはクローズドシステムであるため、ノードは接続と調整の部分にすぎませんが、クライアント、フロントエンド、署名者が基本的にすべての決定をここで行います。

ステファン　うん。それで、LSP、ライトニングサービスプロバイダーということになると、今日のユーザーは、例として、今日の Breeze にあるように、資金を受け取ることができ、いわゆるオンザフライチャネルを作成することに慣れていると思います。。では、Greenlight と Breeze SDK にも同様のコンセプトはあるのでしょうか?

ロイ　全く同じコンセプトです。既存の Breeze アプリのようにユーザーノードをモバイルデバイス上で実行するのではなく、ノードは Greenlight 環境上で実行されます。LSP が HTLC をインターセプトし、Greenlight ノードへのチャネルをオンザフライで開きます。Greenlight ノードは、モバイルデバイスのエンドユーザーにチャネルオープントランザクションへの署名を要求し、すべてのサイクルが完了します。

ステファン　そして、私も同様です、それはおそらく別の質問でもあります。なぜなら、秘密鍵が電話機にある場合、電話機を起動したり、電話機がオンラインで利用可能であることを確認したりするのにどのように対処しますか? Lightning でわかるように、チャネル状態の更新に署名できる必要があります。では、それにどう対処すればよいのでしょうか？

クリスチャン　つまり、これにアプローチする方法には基本的に 3 つの異なるレベルがあるということです。最初のレベルは、現在私たちが現在使用しているレベルであり、基本的にウォレットがオープンしていることを前提としています。それは明らかに最も単純で単純なメカニズムです。そして、それは通常、私たちがピアツーピアのやり取りをするとき、または私がバーに行ってビールを支払うような対面でのやり取りをするときはいつでも一致します。請求書を支払うためにアプリを開いていますよね? そして、支払いが完了するまで、その分間は開いたままにするか、バックグラウンドで実行したままにします。また、友人に素早く支払いを送って、それがいかに簡単でうまくいくかを示したい場合は、もちろん彼はそうします、彼と私はアプリを開いたままにします。そして、同じことが販売時点にも当てはまります。販売時点ではアプリが開いている可能性があります。そして、署名者が存在します。さて、これはある種のご都合主義的な見方ですよね？アプリが開いているので、それを使用してみませんか? 2 番目の反復は、これも現在既に行っていることですが、ロイが前に述べたように、単一のノードに必要な数のクライアントを接続できます。複数の署名者にも同じことが当てはまります。したがって、単一のノードに任意の数の署名者を接続できます。そして、1 つが存在する限り、変更を承認することができます。つまり、これは、これについての思考の多頭のヒドラモデルのようなものです。そして、私たちは、基本的にあなたとあなたの家族のために機能するスタンドアロンの署名者を自宅で実行するセットアップを実験しています。そして、それは 24 時間 7 日オンラインであり、基本的にノードを再起動するだけで署名者がノードに接続され、再び完全に動作できるようになります。そして 3 回目の反復では、基本的にアプリ開発者に連絡して、「署名者が必要です」と言えるようにすることがロードマップにあります。そのノードについてアプリユーザーに連絡してキックスタートする方法をご存知ですか? セットアップの複雑さに応じて、それはモバイル通知である場合もあれば、どこかで起動しているコンテナである場合もあります。ただしこの場合、基本的には、独自のアプリケーションにアクセスする方法を最もよく知っているアプリ開発者に従うことになります。そして、通知がどの程度信頼できるかについてはロイに話してもらいましょう。

ロイ　そこで、トランザクションの受信時にサインオフするメカニズムとしてモバイル通知を実際に実装しました。まだ生産されていません。まだ順番待ち中です。まだテスト中ですがAndroidでは問題ありません。問題は iOS のみにあります。iOS では、いつものように、トランザクション署名または CPU 時間を 30 秒与えます。そして今のところ、Greenlight は非常に信頼できると感じています。そのため、既存の Breeze アプリでは、ネットワークの信頼性と組み合わせて LND ノードの起動時に LND ノードを使用していたため、オフライン受信を実装するメカニズムとして通知を実装することができませんでした。iOS の CPU 要件を満たすのは非常に困難でした。しかし、署名部分自体からノードの操作を切り離す Greenlight では、30 秒の CPU 時間が非常に信頼できることがわかり、すぐに出荷する予定です。私は、これが Lightning の非同期支払いまたはオフライン支払いの範囲外のソリューションであるという事実が好きではありません。したがって、Lightning を自給自足する必要があると思います。そのため、私たちは非同期支払いをプロトコルレベルで実装するためのいくつかのボルトを含む非同期支払いと呼ばれるプロトコルを推進しようとしています。ボルト 11 が必要で、トランポリンの支払いが必要で、オニオンメッセージが必要で、支払いを保留して後で解放できるという別の仕様も必要です。しかし、少なくとも 4 つの主要な実装のうち 3 つの実装がこれらの仕様に積極的に取り組んでいるということではコンセンサスがあると思います。したがって、Lightning プロトコル自体に非同期支払いを実装できる機能が登場することを非常に期待しています。そしてそれが起こるまでに数年も待つ必要はありません。年末にかけて熟成されると思います。できれば24の初めに、少なくとも、Lightning プロトコルでの非同期支払いの最初の実装が見られるでしょう

------------

Part2へ