Devs on Devs: tdot と Ben Jones の対談

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

OP Stackを改善するためのPlasmaモードの使い方

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 Stackは非常に強力で、すぐに使える効果があります。これが私たちの最初の変更です。

その後、私たちはこれらのチャレンジを作成するための契約を作成する必要があります。データを強制的にチェーン上に移すためのDAチャレンジがあります。これはプロセスに契約を統合するための第二ステップです。私たちは派生プロセスで全体の統合システムを構築しなければなりません。これにより、チャレンジ解決プロセス中にデータがチェーン上に提出される場合に備えて、チェーン外のDAソースとL1 DAチャレンジ契約からデータを派生させることができます。

これが事の要点です。非常に複雑ですが、私たちは事を優雅かつ堅実に保ちたいと考えています。同時に、これは比較的簡単な概念です。私たちはすべてを再発明したり、全体のOPスタックを変更したりしようとはせず、複雑な環境の中で物事をシンプルに保つことを試みています。したがって、全体としてこれは非常にクールなエンジニアリングの旅です。

Ben: OPの観点からお話しできます。あなたはLatticeの初期の作業について言及しましたが、ちょうどその時期に、私たちはほぼ全てのOP Stackをエンドツーエンドで書き直しました。このリリースを私たちはBedrockと呼んでいます。

基本的に、rollupを構築してから2年後、私たちは一歩引いて考えました。「さて、学んだすべての経験を最大限に活かすとしたら、それはどのようなものになるでしょうか？」これが最終的にBedrockと呼ばれるコードベースに進化しました。これは私たちがネットワークに行った最大のアップグレードです。

その時、私たちはあなたたちとOPCraftというプロジェクトで協力しました。私はBiomesがその精神的後継者だと思います。これは私たちがチェーン上で最も楽しんだ経験です。同時に、他の人たちもOP Stackを使って開発できるので、私たちはほっとしました。過去数年の間に、スケーリングのもう一つの重要な転換点は、多くの人々がチェーンを運営できることだと思います。

大規模で複雑なコードベースを開発した人だけがこれを実現できるわけではありません。私たちが協力を始めたとき、他の人がこのコードベースを引き継ぎ、素晴らしいことを成し遂げるのを見るのは大きな励みです。そして、この状況が実際のアプリケーションでPlasmaに拡張されるのを見るのは、本当にクールです。その歴史について少しお話ししてもいいかもしれません。

ある有名なLayer 2プロジェクトが設立される前に、私たちは実際にPlasmaと呼ばれる技術を研究していました。当時、私たちが担っていたタスクは、当時のスケーリングコミュニティの能力をはるかに超えていました。初期のPlasma設計で見られるデザインは、今日のPlasmaとは直接的な対応関係がないかもしれません。

今日のプラズマはずっと簡単です。我々は状態検証の証明とチャレンジをデータのチャレンジとは別に見ています。最終的に、数年前に我々はロールアップがプラズマよりもずっと簡単であることを認識しました。その時、コミュニティの結論は「プラズマは死んだ」でした。これはその時期のイーサリアムスケーリングの歴史における一つのジョークです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私たちはできるだけシンプルに保ち、レビューが簡単かつ迅速に行えるようにし、OP Stackに大きな差異がないようにします。しかし、現在、コミットメントをバッチ処理したり、それらを提出することで、より安価にするためのいくつかの最適化が可能です。