OP Stackイノベーターの対話:Plasma Modeがチェーンゲームの未来をどのように変えるか

#開発者の開発者: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パスに影響を与えないことです。他のrollupチェーンの安全性に影響を与えたくないからです。

rollupを設計する際に、「もし誰かがデータ生成プロセスを変更して他の場所からデータを保存したらどうなるか？」とは考えませんよね？たとえこれらの変更があっても、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が他の人によって使用されているだけでなく、私たちが最初に試みたことが非常に混乱していて未熟な抽象的な方法で進化しているのを見るのは本当に驚くべきことです。私たちは完全なサイクルを完了し、それらを中心に素晴らしい抽象が行われ、合理的かつ理にかなった方法で機能するようになりました。これは本当にクールです。

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

tdot: Plasmaモードには依然としていくつかの課題と未解決の問題が存在し、私たちはそれらの解決に取り組んでいます。重要なのは、どのようにして10年もの時間を無駄にしないかということです。分かりますよね？私たちは早急に成果を出せる段階に到達する必要があります。

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

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

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

コードが1行増えるごとに、プロダクション環境から遠ざかり、実戦テストを通過することがより困難になり、エラーの機会が増えてしまいます。ですので、このプロセスを推進するための皆さんの努力、特にOP Stackの新しい操作モードへの貢献に非常に感謝しています。

tdot: OP Stackは確かに、このようなことを迅速に進める方法を生み出しました。明らかに私たちは異なる2つの会社であるため、みんなを調整するのは非常に困難です。Latticeでは、私たちはゲーム、ゲームエンジン、そしてチェーンを構築しています。

そして、あなたたちは何百ものものを構築しており、定期的にこれらの製品を提供しています。調整の観点から見ると、これは本当に非常に難しいことです。

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

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

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

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

Ben: これは本当に素晴らしいことです。今年の私たちの重点の一つは、OP Stackのための貢献パスを作成することです。ですので、テストに参加してこれらのプロセスを推進してくれた皆さんに非常に感謝しています。これらのプロセスが耐え難いものではなく、いくつかの成果を上げられたことを嬉しく思います。さて、これについてですが、あなたの視点から見ると、この次の作業はどのように展開すると思いますか？次に最も楽しみにしている開発は何ですか？

tdot: さまざまな異なる作業方向があります。主に障害証明メカニズムとの統合に関するものです。私たちは、全体の技術スタックを分散化し、その無許可特性を増加させるために、漸進的なアプローチを採用しています。最終的な目標は、無許可で強制退出などの機能を実現することです。

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

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

私たちは一時的にできるだけシンプルに保ち、これにより審査が簡単かつ迅速に行えるようにし、OP Stackに大きな違いをもたらさないようにしています。しかし、現在はいくつかの最適化が可能で、たとえばコミットメントをバッチ処理したり、それらをblobに送信したり、他の異なる方法を採用したりすることで、コストを下げることができます。したがって、L1のコストを削減するために、この点を必ず検討します。

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

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

ベン: