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