Optimism & Redstone Developer Interview: The Plasma Pattern Reshapes Layer 2 (楽観主義とレッドストーン開発者インタビュー: プラズマパターンがレイヤー 2 を再形成する)

今号の特別インタビューでは、Plasma Modeのコアプロトコル開発者tdot(とRedstoneの開発者)、そしてOptimismの共同創設者Ben Jonesを招待しました。OptimismはOP Stackの中心的な推進者です。Plasma Modeは開発者がOP Stack上で構築することを可能にしますが、データをL1に公開する必要はなく、代わりに柔軟にオフチェーンデータプロバイダーに切り替えることができ、コストを節約し、スケーラビリティを向上させます。この対話では、彼らはRedstoneとOptimismの協力の起源、Plasmaの復興の重要性、実験的プロトコルを生産環境に導入する必要性、Plasma ModeとOP Stackの未来のロードマップ、そして全チェーンゲーム分野の発展に対する興奮について探求しました。

01. 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の概念を再利用し、それをrollupの上に置く理由です。ここにはいくつかの違いがあります。最大の疑問は、既存のOP Stack上でオフチェーンDAとオンチェーンデータチャレンジをどのように実現するかです。私たちの目標は、OP Stackにできるだけ少ない変更を加え、rollupパスに影響を与えないことです。なぜなら、OP Stackを使用している他のrollupチェーンの安全性に影響を与えたくないからです。

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行のコードを削減したことです。それ自体が非常に強力です。なぜなら、あなたが言った通り、これらのことは確かに難しいからです。

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

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

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

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

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

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

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

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

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

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

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

私たちは、できるだけシンプルに保つことを一時的に維持しています。これにより、レビューが簡単かつ迅速になり、OP Stackに大きな差異がなくなります。しかし、現在は、コミットメントをバッチ処理したり、それらをblobに提出したり、他の異なる方法を採用することで、より安価にするためのいくつかの最適化があります。したがって、L1のコストを削減するために、私たちはこれを確実に研究します。

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

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

Ben: それについて言うと、これ