# DEVS ON DEVS: TDOT と Ben Jones に話しかける"この特別なDevs on Devsの回では、Plasma Modeのコアプロトコル開発者tdot(、そしてRedstoneの開発者)、さらにOptimismの共同創設者Ben Jonesを招待しました。OptimismはOP Stackの主要な推進者です。Plasma Modeは、開発者がOP Stack上で構築することを可能にしますが、データをL1に公開する必要がなく、柔軟にオフチェーンデータプロバイダーに切り替えることができるため、コストを節約し、スケーラビリティを向上させることができます。対話の中で、彼らはRedstoneとOptimismの協力の起源、Plasmaの復活の重要性、実験的プロトコルを生産環境に導入する必要性、Plasma ModeとOP Stackの未来のロードマップ、そして全チェーンゲーム分野の発展に対する彼らの興奮について探討しました。"## Plasmaモードを使用してOPスタックを改善する方法Ben: OP Stackの改善プロセスはどのようなものですか?tdot: 私は約1年前にLatticeに参加し、Plasma Modeを専門に担当しています。目標は非常に明確です: 私たちは多くのMUDアプリケーションを持っており、それらは大量のガスを消費し、同時に大量のデータをチェーン上に置こうとしていますので、これらのニーズをサポートしつつも安価な解決策が必要です。LatticeチームはOP Stackでいくつかの実験を行い、いくつかのオンチェーンワールドをプロトタイプ化してOP Stackに展開しました。私たちはOP Stackが非常に使いやすいことを発見しました。そこで私たちは自問しました、「どうすればもっと安くなるのか?」基本的な仮定は「私たちはOPスタックが最もEthereumの理念に合致し、完全にEVMと互換性のあるフレームワークだと考えています。」メインネットで動作するものはOPスタックでも同様に動作するため、理想的な解決策です。しかし、私たちはそれをもっと安くしたいと考えています。当時、calldataは依然としてOP Stackチェーンのデータ可用性(DA)のソースであり、非常に高価でした。したがって、私たちは明らかにcalldataを使用してL2を立ち上げることはできませんでした。私たちの全チェーンゲームとMUD世界はより高いスループットを必要とします。そこで、他のデータ可用性(Alt DA)のソリューションを試みることに決めました。実際、最初のOP StackのドキュメントではAlt DAを探求することがすでに言及されていました。そこで私たちは自問しました、「オフチェーンDAから始めたらどうなるだろう?」私たちは、全てのセキュリティモデルとすべての内容がL1イーサリアムに依存できることを望んでいます。したがって、他のAlt DAソリューションを避け、データを中央集権的なDAストレージに保存し、L1上で有効なセキュリティモデルを見つけることに決めました。これが、なぜ私たちがいくつかの古いPlasmaの概念を再利用し、それをrollupの上に置く必要があるのかという理由です。ここにはいくつかの違いがあります。最大の疑問は、既存のOP Stack上でオフチェーンDAとオンチェーンデータチャレンジをどのように実現するかです。私たちの目標は、OP Stackをできるだけ変更せず、rollupの経路に影響を与えないことです。なぜなら、私たちはOP Stackを使用する他のrollupチェーンのセキュリティに影響を与えたくないからです。ロールアップを設計する際に、「もし誰かがデータ生成プロセスを変更して、他の場所からデータを保存したらどうなるだろう?」とは考えないでしょう。これらの変更があっても、OP Stackは依然として非常に強力で、すぐに使える効果があります。これが私たちが行った最初の変更です。その後、これらのチャレンジを作成するために契約を作成する必要があります。データを強制的にブロックチェーンに上げるためのDAチャレンジがあります。これはプロセスに契約を統合する第二のステップです。派生プロセスで全体の統合システムを構築しなければならず、そうすることで、外部のDAソースとL1 DAチャレンジ契約からデータを派生させることができ、チャレンジ解決プロセス中にデータがブロックチェーンに提出される場合に備えます。これが事の要点です。非常に複雑ですが、私たちは物事の優雅さと堅実さを維持したいと考えています。同時に、これは比較的シンプルな概念です。私たちはすべてを再発明したり、全体のOPスタックを変更しようとはしていませんが、複雑な環境の中で物事をシンプルに保つことを試みています。したがって、全体としてこれは非常にクールなエンジニアリングの旅です。ベン: 私はOPの観点から話すことができます。あなたはLatticeの初期の作業についていくつか言及しました。ちょうどその時、私たちOptimismはほぼ全体のOP Stackをエンドツーエンドで書き直しました。このリリースを私たちはBedrockと呼んでいます。基本的に、rollupを構築して2年後、私たちは一歩引いて、「さて、学んだすべての経験を最大限に活用するには、どのようになるだろうか?」と考えました。これが最終的にBedrockと呼ばれるコードベースに進化し、私たちのネットワークに対する最大のアップグレードです。その時、私たちはあなたたちとOPCraftというプロジェクトで協力しました。私はBiomesがその精神的な後継者だと思います。これは私たちがチェーン上で最も楽しく遊んだ瞬間です。同時に、他の人々もOP Stackを使って開発できるため、私たちはホッとしました。過去数年間で、スケーリングのもう一つの重要な転機は、多くの人々がチェーンを運営できるようになったことだと思います。これは、大規模で複雑なコードベースを開発した人だけができることではありません。私たちが協力し始めたとき、他の人がこのコードベースを引き継ぎ、素晴らしいことを成し遂げるのを見るのは非常に心強いことです。それが実際のアプリケーションでPlasmaに拡張されるのを見るのは本当にクールです。その歴史について少し話すこともできます。OptimismがOptimismになる前、私たちは実際にPlasmaと呼ばれる技術を研究していました。当時、私たちが引き受けたタスクは、当時のスケーリングコミュニティの能力をはるかに超えていました。初期のPlasma設計で見られる設計は、今日のPlasmaとは直接的な対応関係がないかもしれません。今日のPlasmaははるかに簡単です。私たちは状態検証の証明と挑戦をデータの挑戦から分けて考えます。最終的に、私たちは数年前にRollupsがPlasmaよりもはるかに簡単であることを認識しました。その時、コミュニティの結論は「Plasmaは死んだ」というものでした。これはあの時期のイーサリアムのスケーリングの歴史における一つのジョークです。しかし、私たちは常に「プラズマは死んでいない、ただ私たちは最初にもっと簡単なタスクを試すことができる」と考えてきました。今、私たちは異なる用語を使っています。例えば、当時は(exits)のような概念がありましたが、今振り返ってみると、「ああ、それは追加のステップを含むデータの可用性の課題だった」と言えます。ですから、OPスタックが他の人によって使用されているだけでなく、私たちが最初に試みたものが非常に混乱していて未熟な抽象的な方法で進化したことを見るのは本当に驚くべきことです。私たちは完全なサイクルを完了しました、そしてあなたたちはそれらの周りで素晴らしい抽象を作り、それを合理的かつ理性的な方法で機能させました。これは本当にクールです。## 最も重要なのは、できるだけ早く本番環境に入ることです。tdot: Plasmaモードには依然としていくつかの課題と未解決の問題があり、私たちはそれを解決するために取り組んでいます。重要なのは、どのようにして10年もの時間を浪費せずに済むかということです。私の言っていることがわかりますね?私たちは、成果を提供できる段階にできるだけ早く到達する必要があります。これが私たちの考えです。私たちはすでにMUDに基づいて開発された多くのアプリケーションを持っており、すぐにメインネットを立ち上げたいと考えています。これらのゲームのためにできるだけ早くメインネットを準備する必要があります。人々はすでに待っており、準備ができています。すべてのアプリケーションを運営するために、迅速に立ち上げて機能するチェーンが必要です。そうすることで、我々が問題を解決している間に、これらのアプリが並行して発展し、より良くなることができます。研究開発から生産の安定性を実現するまでには長い時間がかかります。何かをメインネットにローンチし、無許可で堅牢かつ安全にするためには、多くの時間がかかります。この目標を達成する過程を見ることは本当に驚くべきことです。だからこそ、高い敏捷性を維持する必要があります。なぜなら、物事が多すぎるからです。全体のエコシステムは非常に速く発展しています。私は、誰もが多くの革新を提供していると思います。だからこそ、あなたは追いつかなければならないのですが、安全性とパフォーマンスを妥協してはいけません。そうでないと、システムは機能しなくなります。ベン: あるいは技術的負担のことです。あなたが言及した最小限の変更の原則は、私たちがBedrockの書き直しを行う際の核心的な理念の一つです。私はエンドツーエンドの書き直し全体について話しましたが、もっと重要なのは、約50,000行のコードを削減したことです。これはそれ自体非常に力強いです。あなたが言う通り、これらのことは確かに難しいです。コードが1行増えるたびに、あなたは本番環境から遠ざかり、実戦テストを通過することがより難しくなり、エラーの機会が増えてしまいます。だからこそ、私たちはこのプロセスを推進するためにあなた方が尽力してくださったこと、特にOP Stackの新しい操作モードに貢献してくださったことに非常に感謝しています。tdot: OP Stackは確かにこのようなことを迅速に進める方法を創造しました。皆を調整するのは非常に困難です。なぜなら、私たちは明らかに異なる2つの会社だからです。Latticeでは、私たちはゲーム、ゲームエンジン、そしてチェーンを構築しています。そして、あなたたちは何百ものものを構築しており、定期的にこれらの製品を納品しています。調整の観点から見ると、これは本当に簡単ではありません。ベン: はい、確かにまだ長い道のりがあります。しかし、これこそがモジュール化の核心的な魅力です。私にとって、OPスタックの観点から見ると、これは最もエキサイティングなことの一つであり、現在Redstone上で構築されている素晴らしいゲームやバーチャルワールドを考慮しなくても良いです。純粋にOPスタックの観点から見ると、これは多くの優れたコア開発者が参加してこのスタックを改善していることを証明する非常に強力な例であり、素晴らしいことです。これは初めてです。あなたは1つの重要なブール値を通じてシステムの特性を大きく変えることができます。完全にそれを成し遂げるには、あなたが言うように、確かにまだ長い道のりがあります。しかし、ほぼそれを効率的に実現するには、モジュール化のサポートが必要ですよね?私たちにとって、あなたたちがL2 Gethを再編成することなくそれを実現したのを見るのは本当に安心です。私にとって、これはモジュール化が機能していることを証明しています。tdot: 現在の状況は良くなりました。この例から見ると、皆さんはすべてのものを独立した小さなモジュールに変え、調整や属性変更ができるようにしました。ですので、どんな新機能が統合されるのか非常に楽しみにしています。私たちが以前心配していたのは、すべてのOP Stackの変更を含むフォークがあり、それをメインラインに統合する必要があることでした。その時私たちは「うわぁ、すべてを審査するのは大変だ」と思っていました。私たちはそれをより小さな部分に分解しなければなりませんでしたが、全体のプロセスは非常にスムーズに進みました。私たちとチームの協力の雰囲気はとても良く、審査プロセスも楽しいものでした。それは非常に自然に感じました。そして、審査といくつかの潜在的な問題を解決する面で、このプロセスは非常に迅速に進みました。すべては予想外にスムーズでした。ベン:これは本当に素晴らしいです。今年の私たちの一つの重点は、OP Stackのために貢献の道を作ることです。だから、皆さんがテストに参加し、これらのプロセスを推進してくれたことに非常に感謝しています。これらのプロセスが耐え難いものでないこと、そしていくつかの成果を得られたことを嬉しく思います。これについて言えば、あなたの視点から見ると、次の仕事はどのように進展すると思いますか?あなたが次に最も楽しみにしている開発は何ですか?tdot: さまざまな異なる作業方向があります。主に障害証明メカニズムとの統合です。私たちは、全体の技術スタックを非中央集権化し、その許可不要の特性を増強するために、漸進的なアプローチを採用しています。最終的な目標は、許可不要および強制退出などの機能を実現することです。私たちはこの究極の目標を持っており、安全性を保ちながら徐々に実現しています。1つの課題は、時にはメインネットに上がらない方が簡単であることです。なぜなら、それによりハードフォークを行う必要がなくなるからです。あなたは、「ああ、すべてが完全に準備が整うまでリリースを待てば、ハードフォークをする必要もなく、技術的な負担もない」と思うかもしれません。しかし、メインネットを迅速に立ち上げたい場合は、これらの複雑なアップグレードを処理し、頻繁にリリースする必要があります。これを実現し、高い可用性を維持することは常に課題です。故障証明メカニズムとこれらすべての部分が整った後、Plasmaモデルに関して多くのアップグレードがあると思います。バルクコミットメントの提出に関しては、まだ最適化の余地があると思います。現在、私たちは非常にシンプルに行っていますが、各トランザクションに対して1つのコミットメントがあります。そして、コミットメントはオフチェーンで保存された入力データのハッシュ値にすぎません。私たちは、できるだけシンプルな状態を維持しており、これによりレビューが簡単かつ迅速に行えるようになり、OPスタックには大きな違いはありません。しかし、現在、コミットメントをバッチ処理したり、それらをblobに提出したり、他の異なる方法を採用することで、コストを削減できる最適化がいくつかあります。したがって、L1のコストを削減するためにこれを研究するつもりです。これは私たちにとって非常に興奮することです。もちろん、私たちはすべての相互運用性に関連するコンテンツが到来することを非常に楽しみにしており、すべてのチェーン間で相互作用できるようになります。これはユーザーにとって大きな進歩となるでしょう。これらの作業は確実に皆さんによって実現される必要があります。しかし、私たちはPlasmaモードでこれらがどのようなものであり、異なるセキュリティ仮定を持つのかを理解したいと思っています。Ben: これについて言えば、OP Stackのモジュール化に対するもう一つの試練になるでしょう。あなたは提
Optimism の共同制作者が Plasma Mode の開発者と OP Stack の未来について語ります
DEVS ON DEVS: TDOT と Ben Jones に話しかける
"この特別なDevs on Devsの回では、Plasma Modeのコアプロトコル開発者tdot(、そしてRedstoneの開発者)、さらにOptimismの共同創設者Ben Jonesを招待しました。OptimismはOP Stackの主要な推進者です。Plasma Modeは、開発者がOP Stack上で構築することを可能にしますが、データをL1に公開する必要がなく、柔軟にオフチェーンデータプロバイダーに切り替えることができるため、コストを節約し、スケーラビリティを向上させることができます。対話の中で、彼らはRedstoneとOptimismの協力の起源、Plasmaの復活の重要性、実験的プロトコルを生産環境に導入する必要性、Plasma ModeとOP Stackの未来のロードマップ、そして全チェーンゲーム分野の発展に対する彼らの興奮について探討しました。"
Plasmaモードを使用してOPスタックを改善する方法
Ben: OP Stackの改善プロセスはどのようなものですか?
tdot: 私は約1年前にLatticeに参加し、Plasma Modeを専門に担当しています。目標は非常に明確です: 私たちは多くのMUDアプリケーションを持っており、それらは大量のガスを消費し、同時に大量のデータをチェーン上に置こうとしていますので、これらのニーズをサポートしつつも安価な解決策が必要です。LatticeチームはOP Stackでいくつかの実験を行い、いくつかのオンチェーンワールドをプロトタイプ化してOP Stackに展開しました。私たちはOP Stackが非常に使いやすいことを発見しました。
そこで私たちは自問しました、「どうすればもっと安くなるのか?」基本的な仮定は「私たちはOPスタックが最もEthereumの理念に合致し、完全にEVMと互換性のあるフレームワークだと考えています。」メインネットで動作するものはOPスタックでも同様に動作するため、理想的な解決策です。しかし、私たちはそれをもっと安くしたいと考えています。
当時、calldataは依然としてOP Stackチェーンのデータ可用性(DA)のソースであり、非常に高価でした。したがって、私たちは明らかにcalldataを使用してL2を立ち上げることはできませんでした。私たちの全チェーンゲームとMUD世界はより高いスループットを必要とします。そこで、他のデータ可用性(Alt DA)のソリューションを試みることに決めました。実際、最初のOP StackのドキュメントではAlt DAを探求することがすでに言及されていました。
そこで私たちは自問しました、「オフチェーンDAから始めたらどうなるだろう?」私たちは、全てのセキュリティモデルとすべての内容がL1イーサリアムに依存できることを望んでいます。したがって、他のAlt DAソリューションを避け、データを中央集権的なDAストレージに保存し、L1上で有効なセキュリティモデルを見つけることに決めました。
これが、なぜ私たちがいくつかの古いPlasmaの概念を再利用し、それをrollupの上に置く必要があるのかという理由です。ここにはいくつかの違いがあります。最大の疑問は、既存のOP Stack上でオフチェーンDAとオンチェーンデータチャレンジをどのように実現するかです。私たちの目標は、OP Stackをできるだけ変更せず、rollupの経路に影響を与えないことです。なぜなら、私たちはOP Stackを使用する他のrollupチェーンのセキュリティに影響を与えたくないからです。
ロールアップを設計する際に、「もし誰かがデータ生成プロセスを変更して、他の場所からデータを保存したらどうなるだろう?」とは考えないでしょう。これらの変更があっても、OP Stackは依然として非常に強力で、すぐに使える効果があります。これが私たちが行った最初の変更です。
その後、これらのチャレンジを作成するために契約を作成する必要があります。データを強制的にブロックチェーンに上げるためのDAチャレンジがあります。これはプロセスに契約を統合する第二のステップです。派生プロセスで全体の統合システムを構築しなければならず、そうすることで、外部のDAソースとL1 DAチャレンジ契約からデータを派生させることができ、チャレンジ解決プロセス中にデータがブロックチェーンに提出される場合に備えます。
これが事の要点です。非常に複雑ですが、私たちは物事の優雅さと堅実さを維持したいと考えています。同時に、これは比較的シンプルな概念です。私たちはすべてを再発明したり、全体のOPスタックを変更しようとはしていませんが、複雑な環境の中で物事をシンプルに保つことを試みています。したがって、全体としてこれは非常にクールなエンジニアリングの旅です。
ベン: 私はOPの観点から話すことができます。あなたはLatticeの初期の作業についていくつか言及しました。ちょうどその時、私たちOptimismはほぼ全体のOP Stackをエンドツーエンドで書き直しました。このリリースを私たちはBedrockと呼んでいます。
基本的に、rollupを構築して2年後、私たちは一歩引いて、「さて、学んだすべての経験を最大限に活用するには、どのようになるだろうか?」と考えました。これが最終的にBedrockと呼ばれるコードベースに進化し、私たちのネットワークに対する最大のアップグレードです。
その時、私たちはあなたたちとOPCraftというプロジェクトで協力しました。私はBiomesがその精神的な後継者だと思います。これは私たちがチェーン上で最も楽しく遊んだ瞬間です。同時に、他の人々もOP Stackを使って開発できるため、私たちはホッとしました。過去数年間で、スケーリングのもう一つの重要な転機は、多くの人々がチェーンを運営できるようになったことだと思います。
これは、大規模で複雑なコードベースを開発した人だけができることではありません。私たちが協力し始めたとき、他の人がこのコードベースを引き継ぎ、素晴らしいことを成し遂げるのを見るのは非常に心強いことです。それが実際のアプリケーションでPlasmaに拡張されるのを見るのは本当にクールです。その歴史について少し話すこともできます。
OptimismがOptimismになる前、私たちは実際にPlasmaと呼ばれる技術を研究していました。当時、私たちが引き受けたタスクは、当時のスケーリングコミュニティの能力をはるかに超えていました。初期のPlasma設計で見られる設計は、今日のPlasmaとは直接的な対応関係がないかもしれません。
今日のPlasmaははるかに簡単です。私たちは状態検証の証明と挑戦をデータの挑戦から分けて考えます。最終的に、私たちは数年前にRollupsがPlasmaよりもはるかに簡単であることを認識しました。その時、コミュニティの結論は「Plasmaは死んだ」というものでした。これはあの時期のイーサリアムのスケーリングの歴史における一つのジョークです。
しかし、私たちは常に「プラズマは死んでいない、ただ私たちは最初にもっと簡単なタスクを試すことができる」と考えてきました。今、私たちは異なる用語を使っています。例えば、当時は(exits)のような概念がありましたが、今振り返ってみると、「ああ、それは追加のステップを含むデータの可用性の課題だった」と言えます。ですから、OPスタックが他の人によって使用されているだけでなく、私たちが最初に試みたものが非常に混乱していて未熟な抽象的な方法で進化したことを見るのは本当に驚くべきことです。私たちは完全なサイクルを完了しました、そしてあなたたちはそれらの周りで素晴らしい抽象を作り、それを合理的かつ理性的な方法で機能させました。これは本当にクールです。
最も重要なのは、できるだけ早く本番環境に入ることです。
tdot: Plasmaモードには依然としていくつかの課題と未解決の問題があり、私たちはそれを解決するために取り組んでいます。重要なのは、どのようにして10年もの時間を浪費せずに済むかということです。私の言っていることがわかりますね?私たちは、成果を提供できる段階にできるだけ早く到達する必要があります。
これが私たちの考えです。私たちはすでにMUDに基づいて開発された多くのアプリケーションを持っており、すぐにメインネットを立ち上げたいと考えています。これらのゲームのためにできるだけ早くメインネットを準備する必要があります。人々はすでに待っており、準備ができています。すべてのアプリケーションを運営するために、迅速に立ち上げて機能するチェーンが必要です。そうすることで、我々が問題を解決している間に、これらのアプリが並行して発展し、より良くなることができます。研究開発から生産の安定性を実現するまでには長い時間がかかります。
何かをメインネットにローンチし、無許可で堅牢かつ安全にするためには、多くの時間がかかります。この目標を達成する過程を見ることは本当に驚くべきことです。だからこそ、高い敏捷性を維持する必要があります。なぜなら、物事が多すぎるからです。全体のエコシステムは非常に速く発展しています。私は、誰もが多くの革新を提供していると思います。だからこそ、あなたは追いつかなければならないのですが、安全性とパフォーマンスを妥協してはいけません。そうでないと、システムは機能しなくなります。
ベン: あるいは技術的負担のことです。あなたが言及した最小限の変更の原則は、私たちがBedrockの書き直しを行う際の核心的な理念の一つです。私はエンドツーエンドの書き直し全体について話しましたが、もっと重要なのは、約50,000行のコードを削減したことです。これはそれ自体非常に力強いです。あなたが言う通り、これらのことは確かに難しいです。
コードが1行増えるたびに、あなたは本番環境から遠ざかり、実戦テストを通過することがより難しくなり、エラーの機会が増えてしまいます。だからこそ、私たちはこのプロセスを推進するためにあなた方が尽力してくださったこと、特にOP Stackの新しい操作モードに貢献してくださったことに非常に感謝しています。
tdot: OP Stackは確かにこのようなことを迅速に進める方法を創造しました。皆を調整するのは非常に困難です。なぜなら、私たちは明らかに異なる2つの会社だからです。Latticeでは、私たちはゲーム、ゲームエンジン、そしてチェーンを構築しています。
そして、あなたたちは何百ものものを構築しており、定期的にこれらの製品を納品しています。調整の観点から見ると、これは本当に簡単ではありません。
ベン: はい、確かにまだ長い道のりがあります。しかし、これこそがモジュール化の核心的な魅力です。私にとって、OPスタックの観点から見ると、これは最もエキサイティングなことの一つであり、現在Redstone上で構築されている素晴らしいゲームやバーチャルワールドを考慮しなくても良いです。純粋にOPスタックの観点から見ると、これは多くの優れたコア開発者が参加してこのスタックを改善していることを証明する非常に強力な例であり、素晴らしいことです。
これは初めてです。あなたは1つの重要なブール値を通じてシステムの特性を大きく変えることができます。完全にそれを成し遂げるには、あなたが言うように、確かにまだ長い道のりがあります。しかし、ほぼそれを効率的に実現するには、モジュール化のサポートが必要ですよね?私たちにとって、あなたたちがL2 Gethを再編成することなくそれを実現したのを見るのは本当に安心です。私にとって、これはモジュール化が機能していることを証明しています。
tdot: 現在の状況は良くなりました。この例から見ると、皆さんはすべてのものを独立した小さなモジュールに変え、調整や属性変更ができるようにしました。ですので、どんな新機能が統合されるのか非常に楽しみにしています。私たちが以前心配していたのは、すべてのOP Stackの変更を含むフォークがあり、それをメインラインに統合する必要があることでした。その時私たちは「うわぁ、すべてを審査するのは大変だ」と思っていました。
私たちはそれをより小さな部分に分解しなければなりませんでしたが、全体のプロセスは非常にスムーズに進みました。私たちとチームの協力の雰囲気はとても良く、審査プロセスも楽しいものでした。それは非常に自然に感じました。そして、審査といくつかの潜在的な問題を解決する面で、このプロセスは非常に迅速に進みました。すべては予想外にスムーズでした。
ベン:これは本当に素晴らしいです。今年の私たちの一つの重点は、OP Stackのために貢献の道を作ることです。だから、皆さんがテストに参加し、これらのプロセスを推進してくれたことに非常に感謝しています。これらのプロセスが耐え難いものでないこと、そしていくつかの成果を得られたことを嬉しく思います。これについて言えば、あなたの視点から見ると、次の仕事はどのように進展すると思いますか?あなたが次に最も楽しみにしている開発は何ですか?
tdot: さまざまな異なる作業方向があります。主に障害証明メカニズムとの統合です。私たちは、全体の技術スタックを非中央集権化し、その許可不要の特性を増強するために、漸進的なアプローチを採用しています。最終的な目標は、許可不要および強制退出などの機能を実現することです。
私たちはこの究極の目標を持っており、安全性を保ちながら徐々に実現しています。1つの課題は、時にはメインネットに上がらない方が簡単であることです。なぜなら、それによりハードフォークを行う必要がなくなるからです。あなたは、「ああ、すべてが完全に準備が整うまでリリースを待てば、ハードフォークをする必要もなく、技術的な負担もない」と思うかもしれません。しかし、メインネットを迅速に立ち上げたい場合は、これらの複雑なアップグレードを処理し、頻繁にリリースする必要があります。これを実現し、高い可用性を維持することは常に課題です。
故障証明メカニズムとこれらすべての部分が整った後、Plasmaモデルに関して多くのアップグレードがあると思います。バルクコミットメントの提出に関しては、まだ最適化の余地があると思います。現在、私たちは非常にシンプルに行っていますが、各トランザクションに対して1つのコミットメントがあります。そして、コミットメントはオフチェーンで保存された入力データのハッシュ値にすぎません。
私たちは、できるだけシンプルな状態を維持しており、これによりレビューが簡単かつ迅速に行えるようになり、OPスタックには大きな違いはありません。しかし、現在、コミットメントをバッチ処理したり、それらをblobに提出したり、他の異なる方法を採用することで、コストを削減できる最適化がいくつかあります。したがって、L1のコストを削減するためにこれを研究するつもりです。
これは私たちにとって非常に興奮することです。もちろん、私たちはすべての相互運用性に関連するコンテンツが到来することを非常に楽しみにしており、すべてのチェーン間で相互作用できるようになります。これはユーザーにとって大きな進歩となるでしょう。
これらの作業は確実に皆さんによって実現される必要があります。しかし、私たちはPlasmaモードでこれらがどのようなものであり、異なるセキュリティ仮定を持つのかを理解したいと思っています。
Ben: これについて言えば、OP Stackのモジュール化に対するもう一つの試練になるでしょう。あなたは提