次のオンチェーンゲームにレッドストーンを使うべきか?

ラティスチームは最近、 OPスタック (Optimism L2を動かすスタック)への新しい貢献を使用して構築された新しいL2である Redstone を発表しました。

したがって、誰もが頭に浮かぶ疑問は、「オンチェーンゲームはこのL2上に構築されるべきか、そしてそれは他のものと比較してどうか」ということです。 Paima Studiosは、複数のチェーンでゲームが稼働するオンチェーンゲームのトップビルダーの1つであるため、多くの人がPaima Studiosのチームに意見を求めており、そのニュアンスを掘り下げるために最善を尽くします。

手記

この記事を書いている時点では、レッドストーンは最近発表されたばかりです。 Web3は非常に動きの速い分野なので、Redstoneが必然的に彼らの仕事についてもっと発表するので、このブログ記事を読んでおくことをお勧めします

レッドストーンとその存在理由を理解するには、まず、市場で活発に使用されている他の代替品との比較とそのトレードオフを理解する必要があります。 特に、このブログ投稿では、レッドストーンが次に何を発表しても、レッドストーンが提案するものを理解できるように、正しいメンタルモデルを提供することに焦点を当てます。

すべての始まり

それで、あなたはオンチェーンゲームを作りたいですか? レッドストーンはイーサリアムL2であることを考えると、イーサリアムの活用をすでに決めていると仮定します。

では、なぜゲームをイーサリアムに直接デプロイできないのでしょうか? コストがかかりすぎる(執筆時点では1ゲームあたり>1ドル以上)ためであることはわかっているかもしれませんが、なぜコストがかかりすぎるか知っていますか? 主なコストは、実行コストとデータストレージコストの2つで、どちらもゲームとしては法外なコストがかかります。 ただし、CPU がハード ドライブよりも高価であるのと同様に、実行コストはストレージ コストよりも大幅に高くなります。 では、実行コストをストレージコストに変換する方法を考え出すことができるとしたらどうでしょうか。 朗報:ロールアップはまさにこれを行います。

スケーリングソリューションとしてのロールアップ

ロールアップにはさまざまな形式があり、それぞれが独自の方法で実行コストをストレージ コストに変換します。

1. オプティミスティックロールアップ:計算をオフチェーンで実行し、関数の実行に必要なすべてのデータ(データのみ、実行なし)と、ローカルで計算された結果の値とともに保存します。 実際に実行を実行するのは、あなたが投稿した結果が間違っていると誰かが信じている場合のみです(「不正の証拠」)。 \
   一般的な例: アービトラム、楽観主義
2. ZKロールアップ:計算をオフチェーンで実行し、関数の実行に必要なすべてのデータ(データのみ、実行なし)と、ローカルで計算された結果のZK証明を保存します。 \
   一般的な例:ZK Sync、Starknet、Polygon zkEVM
3. ソブリンロールアップ:計算をオフチェーンで実行し、関数の実行に必要なすべてのデータを保存します(データのみ、実行なし)。 \
   一般的な例:ロールキット、パイマエンジン

これらのソリューションを活用することで、ゲームのトランザクションコストは約0.05ドルに下がり(最新の値については l2fees を参照)、これは間違いなく正しい方向への大きな一歩です。

L2のコスト削減

これらのL2のコストを削減することが、ゲームを成功させるための鍵であることは明らかです。 ロールアップは確実に安くなっていますが(コンピューターの性能の向上、ZK技術の向上など)、主なコストはオフチェーン計算の実行ではなく、データをL1に投稿するコストです。

これに対処するために、イーサリアムは、データが一時的にのみ保存される(実際には、~2週間)データ EIP4844を保存する新しい方法を導入します(実際には、不正防止を投稿し、世界中のノードによってデータを複製するのに十分な長さです)。

ただしEIP4844いくつかの欠点があります。

• データは一時的なものです(その後もホストし続けるには、別のストレージソリューションを見つける必要があります)
• データは制限されており、ブロックあたり約2MiBに制限されています(イーサリアム上のすべてのロールアップで共有されます)

このように、コストを下げるための努力はなされていますが、ブロックチェーン空間への関心が継続的に高まっていることを考えると、オンチェーンゲームをL2で実現するには十分ではありません(採用のスピードは技術革新のスピードよりも速いです)

代替案#1:中央のサーバー(またはサーバーのセット)にデータを保存する

コストを低く抑えるための1つの選択肢は、人々があなたを信頼して運用している中央のサーバーにデータを保存し、データのハッシュのみをオンチェーンに投稿することです。 このアイデアの変形は、マルチシグとして集約された独立して動作するマシンのグループを使用することです。 このようなスキームは「データ可用性委員会」(DAC)と呼ばれ、Arbitrum Nova、Arbitrum Orbit、Polygon CDKで使用されています。

これらのスキームは、ネットワークがより中央集権化されていることと引き換えに、はるかに安価です(手数料市場を無視すると、Arbitrum Novaの場合は$ 0.001 / tx)。 主なリスクは、DACがデータのホスティングを停止すると(たとえば、DACがハッシュを投稿し、そのハッシュのデータを共有しない場合)、ネットワークが停止することです。

アービトラムに関する特記事項

Arbitrum がリストに 2 回表示される理由が気になるかもしれません。 Arbitrumは現在、主に3つのサービスを提供しています。

• Arbitrum One(イーサリアム上のデータを含む完全なロールアップであるメインのアービトラムネットワーク)
• Arbitrum Nova (DACを使用するL2)
• Arbitrum Orbit (Arbitrum OneのL3を作成するためのスタック)

ご覧のとおり、Novaの問題は、ゲームにDeFiを活用する良い方法がないことです(ユーザーは(Nova -> ETH L1 -> One)にアクセスして、ブリッジのためだけにガスに多額の費用を費やす必要があります)が、新しいOrbitスタックでは簡単に移行できます(Orbit -> One)。 さらに、OrbitはL3を作成するためのスタックであるため、独自のDACを強化するXai Gamesなどの既存のL3を使用したり、独自のL3をスピンアップしたりできます(ただし、イーサリアムとの唯一の接続が時折ハッシュを投稿するゲーム固有のL3がある場合は、web2.5の方が良いと言えるでしょう)

代替案#2:別の分散型ネットワークにデータを保存する

Celestia、Avail、EigenDAなどの他のプロジェクトは、メインネットの帯域幅が制限された状態でEIP4844が実装されるのを待つのではなく、同様のコンセプトを別のチェーン(「データ可用性(DA)レイヤー」と呼ばれる)として実装することを決定し、純粋にこのユースケースに焦点を当てることで、イーサリアムメインネットがサポートする予定よりも高いデータ制限を提供します。 これらのプラットフォームはスマートコントラクトをサポートしておらず、代わりに純粋にL2のデータレイヤーとして使用することを目的としています。

特筆すべきは、Celestiaのデータを含むOPスタックと、Celestiaのデータを含むArbitrum Orbitを作成することができることです。 これにはいくつかのトレードオフがあります。

1. 信託。 ロールアップは、イーサリアム上のセキュリティのためにDAレイヤーに依存するようになりました(ただし、DACよりも優れていることは間違いありません)
2. 費用。 ロールアップは、セキュリティのためにDAネットワークに支払う必要があります(DAレイヤーのネイティブトークンで支払う必要があります)
3. 速度。 セレスティアのブロック時間は15秒、アベイルズのブロック時間は20秒です。 たとえば、データは、Celestia の blobstream コントラクトを使用して EVM にブリッジする前に、Celestia に落ち着く必要があります。 ただし、すべてのL2は一般的にイーサリアムが実際に提供できるよりも速いブロック時間をエミュレートするため、この点を鵜呑みにしないでください(Arbitrumがこれよりも速いブロック時間を使用しているにもかかわらず、イーサリアムのブロック時間はわずか15秒です)。

この種のセットアップは、Mantle(OP Stack + EigenLayer DA)とManta Pacific(OP Stack + Celestia)で特に使用されています。 これらのコストはまだ明らかになっていませんが、Celestia チームは約 0.001ドルと主張しており、DAレイヤー上のストレージのコスト(EVM側の手数料市場からの実行コストと比較して)は最小限であることを意味します。

代替案#3:チャレンジ可能なDACにデータを格納する

最後に、レッドストーンが何を提供しているかについて話すことができます。 DAレイヤーにデータを保存するトレードオフが気に入らないが、DACの集中化が気に入らない場合は、代わりにDACを構築して、データを利用可能にしなかった場合に委員会を金銭的に罰することができます。

これが何を意味するのかを理解するために、DACプロトコルがどのように機能するかの流れを見ていきましょう。

データの書き方

1. Sequencer for Redstone がトランザクションを受け取る
2. シーケンサは、保存するデータをDACに送信します
3. DAC は、データが格納されているという確認応答を返します
4. シーケンサーは、データのハッシュを L1 にポストします

データの読み方

1. イーサリアムチェーンを同期し、ロールアップコントラクトに送信されたハッシュを探す
2. DAC からのハッシュのデータを照会する
3. このデータに基づいて L2 の状態を計算します

では、レッドストーンは何を変えるのでしょうか

データを読み取るときに、データが利用できない場合は、DACがデータを利用可能にしていない(つまり、データがサーバーからダウンロードできない)と主張して、DACに異議を唱えることができます。

すべての人に正直に話すように適切にインセンティブを与えるために、次のスラッシングルールを設定しました。

1. チャレンジャーが不正な場合(データが実際に利用可能だった場合)、彼らはスラッシュされます(そうでなければ、すべてのブロックに挑戦することでネットワークを経済的に攻撃する可能性があります)
2. DCA が不正な場合(データが使用できない場合)、DCA はスラッシュされます。

これは簡単な解決策のように思えますが、問題が発生した場合に誰が過失を犯しているのかを把握するのが難しいです。 次のシナリオを考えてみましょう。

1. シーケンサーは、実際のデータを共有せずにハッシュを投稿します
2. 誰かがシーケンサーに挑戦
3. シーケンサーは、課題を見て、データを利用可能にします

チェーンをリアルタイムで監視していなかった外部のオブザーバーであれば、データは利用可能に見えるので(事後にDACに問い合わせると期待通りのデータが得られます)、挑戦者は嘘をついていたように見えますが、そうではありません。

この問題の解決策が、シーケンサーがゲームだけのために嘘をつかないと仮定することであるならば、代わりに標準のDACを使用してみてはいかがでしょうか。 さらに、シーケンサーが正直であると仮定すると、共有シーケンサーの「スーパーチェーン」の概念とうまく調和せず、アセットは共有シーケンサーを使用してOPスタックチェーン間で転送できません(したがって、レッドストーンがL3として展開されていない限り、Arbitrum Novaと同じ問題が発生します)

ラティスのチームがこれにどう対処するかは、より多くのドキュメントやロードマップ情報が利用可能になるにつれて、注目すべき重要なポイントになります。

代替案#4:ZKを使用する

レッドストーンに影響するデータ共有されない問題(データ保留攻撃)は、オプティミスティックロールアップに限ったことではないことに注意してください。 データがオフチェーンに保存されているZKロールアップ(「バリディウム」と呼ばれる)も同じ問題に悩まされているため、人々は一般的にロールアップ(すべてのデータをチェーンに投稿する)に関心があります。

したがって、ZKロールアップは、一般的に、ゲームのデータコストを安全に削減するのには役立ちません。 これらは、他の多くの方法でゲームのスケーリングに役立つことは間違いありませんが (より多くの計算をユーザーのローカル マシンに移動する、再帰的証明を使用してロールアップ スタイルまたはステート チャネル スタイルで多くのインタラクションをバッチ処理するなど)、これは今後の投稿のトピックです。

Solidity自体に問題がある場合、ゲームのコストをさらに低くするにはどうすればよいですか?​

このブログ記事では、ストレージコストの処理方法について説明しました。 ただし、一部のゲームはCPUに制限がある場合があります(中央集権的なEVMチェーンで実行されている場合でも、動作します)。 このような場合は、Sovereign ロールアップを使用して、Paima Engine を使用して EVM の限界を超えてゲームをスケーリングすることに関心があるかもしれません。

Paima Engineを使用すると、アプリケーション固有のステートマシンをJavascriptで作成し、任意のEVMチェーン(Redstoneを含む)にデプロイできます。 これらのソブリン ロールアップは EVM 情報 (MUD エンジン データを含む) にアクセスできるため、ゲームのあらゆる部分をより速く、より安価に実行するための優れた方法として機能します。

結論

結論として、データコストの削減は、オンチェーンゲームのコストを下げるための最も重要なステップです。 現在、さまざまなトレードオフを持つさまざまな既存のソリューションが存在し、Redstoneは標準のDACよりも安全であると宣伝していますが、それが意味のある安全性であるかどうか、そしてその違いがDAレイヤーに裏打ちされたソリューションの実行可能な代替手段となるのに十分な意味があるかどうかはまだわかりません。 データの上に計算をスケーリングする必要があるプロジェクトには、Paima Engineのようなソリューションが存在します。

最後の免責事項として、レッドストーンの詳細はまだ完全には発表されていないことを覚えておいてください。 このブログ記事は、彼らの将来の発表を理解するための適切なメンタルモデルを提供するはずなので、心を開いて、彼らが今後何を提案するかを見てみましょう。

パイマ スタジオズ (Paima Studios)

2022年4月に設立されたPaima Studiosは、オンチェーンゲーム、ゲーミフィケーション、自律的な世界の構築を可能にする新しいレイヤー2技術を使用して構築されたWeb3エンジンであるPaima Engineのコア開発者です。 Paima Engineは、Web2スキルで使用でき、ユーザーや開発者を一般的なWeb3のリスクやハッキングにさらさないため、Web3に参入するための安全で簡単な方法です。

• Paima Engine コードベース: https://github.com/PaimaStudios/paima-engine
• Paima ドキュメント: https://docs.paimastudios.com/
• パイマテンプレート: https://github.com/PaimaStudios/paima-game-templates
• Paima NPM パッケージ: <a href="https://www.npmjs.com/package/ @paima /sdk"">https://www.npmjs.com/package/@paima/sdk

また、ソーシャルメディアから詳細を学ぶこともできます。

• ユーチューブ: <a href="https://www.youtube.com/ @paimastudios "">https://www.youtube.com/@paimastudios
• 不和: http://discord.gg/jZ59ArVaxv
• Reddit: https://reddit.com/r/paima
• ツイッター: https://twitter.com/PaimaStudios

一緒に働きませんか? お問い合わせページからお気軽にお問い合わせください https://paimastudios.com/contact/

免責事項：

1. この記事は[blog.paimastudios]からの転載です。 すべての著作権は原作者[paimastudios]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。