DEVS ON DEVS: TDOT と BEN JONES の対談

この特別な「開発者から開発者へ」のセクションでは、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チェーンの安全性に影響を与えたくないからです。

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

その後、これらのチャレンジを作成するために契約を作成する必要があります。データを強制的にオンチェーン化するための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は死んだ」というものでした。これはその時期のEthereumスケーリングの歴史における一つのジョークです。

しかし、私たちは常に「Plasmaは死んでいない、単に私たちはまずより簡単なタスクを試すことができる」と考えていました。今、私たちは異なる用語を使用しています。例えば、当時は退出（exits）などの概念がありましたが、今振り返ってみると、「ああ、それは追加のステップを伴うデータの可用性の課題だった」と言うことができます。ですから、OP Stackが他の人によって使用されているだけでなく、非常に混乱し、未熟な抽象的な方法で行おうとしていたことへと進化しているのを見るのは本当に驚くべきことです。私たちは完全なサイクルを完了し、あなたたちはそれらの周りで素晴らしい抽象を作り出し、それを合理的で理にかなった方法で機能させました。これは本当にクールです。

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

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

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

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

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

コードを1行追加するたびに、実稼働環境から遠ざかり、実戦テストを受けることが難しくなり、エラーの機会が増えます。ですので、私たちはこのプロセスを推進するために皆さんが尽力してくださったこと、特にOP Stackの新しい操作モードへの貢献に非常に感謝しています。

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

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

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

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

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

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

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

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

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

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

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

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

多くのこれらの作業は確かにあなたたちによって実現されなければなりません。しかし、私たちはこれらがPlasmaモードでどのようなものかを理解したいと考えています。