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 Stack がイーサリアムの理念に最も合致し、EVM と完全に互換性のあるフレームワークだと考えています。」メインネットで動作するものは同様に OP Stack 上でも動作することが理想的な解決策です。しかし、私たちはそれをもっと安くしたいと考えています。

その時、calldata はまだ OP Stack チェーンのデータの可用性(DA)のソースであり、非常に高価でした。したがって、私たちは明らかに calldata を使用して L2 を立ち上げることはできませんでした。私たちの全体的なチェーンゲームと MUD 世界はより高いスループットを必要としています。したがって、私たちは他のデータの可用性(Alt DA)のソリューションを試みることに決めました。実際、最初の OP Stack ドキュメントでは Alt DA の探索について言及されていました。

そこで私たちは自問しました。「もしオフチェーンDAから始めたらどうなるのか？」私たちは、全体のセキュリティモデルとすべてがL1イーサリアムに依存できることを望んでいます。したがって、他のAlt DAソリューションを避け、データを集中型DAストレージに保存することに決め、その後L1で有効なセキュリティモデルを見つけることにしました。

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

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

その後、これらのチャレンジを作成するための契約を記述する必要があります。データをチェーン上に強制的に載せるためのDAチャレンジがあります。これは第2ステップであり、契約をプロセスに統合します。派生プロセスで全体の統合システムを構築する必要があり、そうすることで、オフチェーンの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は死んでいない、ただ私たちはまずはもっと簡単なタスクを試してみることができる」と考えてきました。今、私たちは異なる用語を使用しています。例えば、その時には(exits)のような概念があり、今振り返ると「おお、それは追加のステップを伴うデータの可用性の課題だった」と言えるでしょう。だから、OP Stackが他の人によって使用されているだけでなく、私たちが最初に試みたことが非常に混乱していて未熟な抽象の方法で進化しているのを見るのは本当に驚くべきことです。私たちは完全なサイクルを完了しました、そしてあなたたちはそれに素晴らしい抽象を作り、それを合理的で理にかなった方法で機能させました。本当にクールです。

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

tdot: プラズマモードにはまだいくつかの課題や未解決の問題が存在しており、私たちはそれを解決するために努力しています。重要なのは、10年もの時間を無駄にしない方法です。私の言いたいことがわかりますか？私たちはできるだけ早く成果を出せる段階に達する必要があります。

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

何かをメインネットにローンチし、許可なしで堅固かつ安全にするには、多くの時間がかかります。この目標を達成する過程を見るのは本当に驚くべきことです。これが、私たちが非常に敏捷である必要がある理由です。物事があまりにも多いからです。全体のエコシステムは非常に速く進化しています。私は、誰もが大量の革新を提供していると思います。だからこそ、あなたはついていかなければなりませんが、安全性とパフォーマンスを妥協してはいけません。そうでなければ、システムは機能しません。

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

コードが1行増えるごとに、生産環境から遠ざかり、実戦テストを行うことがさらに難しくなり、エラーの機会が増えることになります。ですので、このプロセスを推進するために皆さんが行ったすべての努力、特にOP Stackの新しい操作モードへの貢献に心から感謝します。

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

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

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

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

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

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

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

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

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

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

私たちはできるだけシンプルに保つことにします。そうすれば、レビューが簡単かつ迅速に行え、OP Stack に大きな違いはありません。しかし、現在は、コミットメントをバッチ処理したり、それらを blob に提出したり、他の方法を採用したりすることで、よりコストを削減できる最適化がいくつかあります。