Optimism と tdot が OP スタックの最適化と Plasma モデルの革新について議論

#開発者の開発者: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スタックを変更したりすることは試みず、複雑な環境の中で物事をシンプルに保つことを試みています。したがって、全体としてこれは非常にクールなエンジニアリングの旅です。

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のリライトを行う際の核心的な理念の1つです。私はエンドツーエンドのリライト全体について話しましたが、もっと重要なのは、私たちが約50,000行のコードを削減したことです。これはそれ自体で非常に力強いことです。なぜなら、あなたが言う通り、これらのことは確かに難しいからです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ベン: それについて言うと、