Optimism の共同創設者と Plasma Mode の開発者が、OP Stack の改善とスケーリングの未来について話し合います

#開発者の開発者:TDOTとベンジョーンズの会話

今期の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の未来のロードマップ、そして全チェーンゲーム分野の発展に対する期待について探求しました。

01. プラズマモードで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上で有効なセキュリティモデルを見つけることに決めました。

これが、私たちがいくつかの古いPlasmaの概念を再利用し、それをrollupの上に置く理由です。いくつかの違いがあります。最大の疑問は、既存のOP Stack上でオフチェーンDAとオンチェーンデータチャレンジをどのように実現するかです。私たちの目標は、OP Stackにできるだけ少ない変更を加え、rollupパスに影響を与えないことです。なぜなら、私たちはOP Stackを使用している他のrollupチェーンのセキュリティに影響を与えたくないからです。

ロールアップを設計するとき、あなたは「もし誰かがデータ生成プロセスを変更して他の場所にデータを保存したらどうなるだろう？」とは考えないでしょう。これらの変更があっても、OP Stackは依然として非常に強力で、すぐに使える効果があります。これが私たちが行った最初の変更です。

その後、私たちはこれらのチャレンジを作成するための契約を作成する必要があります。データを強制的にオンチェーンにするためのDAチャレンジがあります。これはプロセスに契約を統合する第二のステップです。私たちは派生プロセスの中で全体の統合システムを構築しなければなりません。そうすれば、チャレンジが解決される過程でデータがオンチェーンに提出される場合に備えて、チェーン外のDAソースとL1 DAチャレンジ契約の両方からデータを派生させることができます。

これが事の要点です。非常に複雑ですが、私たちは物事の優雅さと堅実さを保ちたいと考えています。同時に、これは比較的簡単な概念です。私たちはすべてを再発明したり、全体のOP Stackを変更しようとはしていませんが、複雑な環境の中で物事をシンプルに保つことを試みています。全体として、これは非常にクールなエンジニアリングの旅です。

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が他の人によって使用されているだけでなく、私たちが最初に試みたが非常に混乱して未熟な抽象的な方法で行ったことに進化しているのを見るのは本当に驚くべきことです。私たちは完全なサイクルを完了し、あなたたちはそれに関して素晴らしい抽象を作り出し、それを合理的で理にかなった方法で機能させました。これは本当にクールです。

02.最も重要なのは、できるだけ早く生産環境に入ることです

tdot: Plasmaモードには依然としていくつかの課題と未解決の問題があり、私たちはそれを解決するために努力しています。重要なのは、どのようにして10年もの時間を無駄にせずに済むかということです。私の言いたいことがわかりますよね？私たちは、成果を提供できる段階にできるだけ早く到達する必要があります。

これが私たちの考えです。私たちはすでにMUDに基づいて開発された多くのアプリケーションを持っており、すぐにメインネットを立ち上げたいと考えています。これらのゲームのために、できるだけ早くメインネットを準備する必要があります。人々はすでに待っており、準備が整っています。これらのアプリケーションを実行するために、すぐに立ち上げて動作するチェーンが必要です。そうすることで、私たちが問題を解決する間にこれらのアプリケーションが並行して成長し、さらに良くなることができます。研究開発から生産の安定性を実現するには長い時間がかかります。

何かをメインネットにローンチし、無許可で堅牢かつ安全にするには、多くの時間を費やす必要があります。我々がこの目標を達成するプロセス全体を見るのは非常に驚くべきことです。だからこそ、私たちは高度なアジリティを維持する必要があります。物事が多すぎるのです。全体のエコシステムは非常に速く進化しています。私は、誰もが大量の革新を提供していると思います。だからこそ、あなたは追いつかなければならず、しかし安全性やパフォーマンスで妥協してはいけません。そうでなければ、システムは機能しません。

Ben: あるいは技術的負担についてです。あなたが言及した最小限の変更の原則は、私たちがBedrockの書き直しを行う際の核心的な理念の一つです。私はエンドツーエンドの書き直しについて話しましたが、もっと重要なのは、約50,000行のコードを削減したことです。それ自体が非常に強力です。あなたが言った通り、これらのことは確かに難しいです。

コードが一行増えるごとに、実稼働環境から遠ざかり、実地テストを通過することが難しくなり、より多くのエラーが発生する機会をもたらします。ですので、このプロセスを推進するために皆さんが尽力してくださったこと、特にOP Stackの新しい運用モードへの貢献に感謝しています。

tdot: OP Stackは、こうした事柄を迅速に進める方法を確かに創造しました。皆を調整するのは非常に難しいです、なぜなら私たちは明らかに異なる2つの会社だからです。Latticeでは、私たちはゲーム、ゲームエンジン、そして1つのチェーンを構築しています。

そしてあなたたちは何百ものものを構築し、それらの製品を定期的に納品しています。調整の観点から見ると、これは本当に容易ではありません。

Ben: はい、確かにまだ長い道のりがあります。しかし、これがモジュール化の核心的な魅力です。私にとって、OP Stackの観点から見ると、これは最もエキサイティングなことの一つであり、今Redstoneで構築されている素晴らしいゲームやバーチャルワールドはさておきです。純粋にOP Stackの観点から見ると、これは多くの優れたコア開発者が参加し、このスタックを改善してきたことを証明する非常に強力な例です。これは本当に素晴らしいことです。

これは初めてのことで、1つの重要なブール値を使ってシステムの属性を大きく変更することができます。完全にそれを実現することは、あなたが言うように、確かにまだ長い道のりがあります。しかし、ほぼ効果的にそれを達成するためには、モジュール化のサポートが必要ですよね？私たちにとって、例えばL2 Gethを再構築することなく、あなたたちがそれを実現したのを見るのは本当に安心しました。私にとって、これはモジュール化が機能していることを証明しています。

tdot: 今の状況は良くなりました。この例から見ると、あなたたちはすべてのものを独立した小さなモジュールに変えて、調整や属性の変更ができるようにしました。だから、どんな新機能が統合されるのか、とても楽しみです。私たちが以前心配していたのは、すべてのOP Stackの変更を含むフォークがあり、それをメインブランチに統合する必要があったことです。その時、私たちは「なんてこった、すべてをレビューするのは狂気だろう」と思っていました。

私たちはそれをより小さな部分に分解しなければなりませんでしたが、全体のプロセスは非常に順調に進みました。私たちとチームの協力の雰囲気は非常に良かったので、レビューのプロセスも楽しかったです。これは非常に自然に感じました。また、レビューといくつかの潜在的な問題を解決する点において、このプロセスは非常に速く進んだと思います。すべてが予想外にスムーズでした。

Ben: これは本当に素晴らしいことです。今年の私たちの重点の1つは、OP Stackのために貢献の道を作ることです。それで、テストに参加してこれらのプロセスを推進してくれて本当に感謝しています。これらのプロセスが負担にならなかったこと、そして私たちがいくつかの成果を上げたことにとても嬉しく思います。これについて言うと、あなたの視点から見て、次にこの作業はどのように進展すると思いますか？あなたが次に最も期待している開発は何ですか？

tdot: さまざまな異なる作業方向があります。主に障害証明機構との統合です。私たちは、全体の技術スタックを非中央集権化し、その無許可性を高めるために、漸進的なアプローチを採用しています。最終目標は、無許可や強制退出などの機能を実現することです。

私たちはこの究極の目標を持っており、安全性を保ちながら段階的に実現しています。一つの課題は、時にはメインネットに上場しない方が簡単であることです。なぜなら、その場合、ハードフォークを行う必要がないからです。あなたは考えるかもしれません、「ああ、すべてが完全に準備が整ったらリリースすればいいので、ハードフォークを行う必要もなく、技術的な負担もない。」しかし、メインネットを迅速に立ち上げたいのであれば、これらの複雑なアップグレードに対処し、頻繁にリリースする必要があります。これを達成し、高い可用性を維持することは常に課題です。

故障証明メカニズムとこれらの部分が準備整った後、Plasmaモデルの面で多くのアップグレードがあると考えています。バッチ提出のコミットメントに関しては、まだ最適化の余地があると思います。現在、私たちは非常にシンプルに行っており、各取引に対して一つのコミットメントがあります。そして、コミットメントはオフチェーンで保存された入力データのハッシュ値に過ぎません。

私たちは現在できるだけシンプルさを保っています。これにより、レビューが簡単かつ迅速に行える上、OP Stackに大きな差異はありません。しかし、現在はコストを下げるためのいくつかの最適化が可能です。たとえば、コミットメントをバッチ処理したり、それらをblobに提出したり、他のさまざまな方法を採用することができます。したがって、私たちはL1のコストを削減するためにこの点を必ず調査します。

これは私たちにとって非常に興奮することです。もちろん、私たちはすべての相互運用性に関連するコンテンツを楽しみにしており、すべてのチェーン間で相互作用できることを期待しています。これがユーザーにとって大きな進歩になることを理解することが重要です。

これらの多くの作業は確実に皆さんによって実現される必要があります。しかし、私たちはこれらがPlasmaモードでどのようなものであり、異なるセキュリティ仮定を持つのかを理解したいと考えています。

Ben: それについて言うと、これはOP Stackについてです