Blade GamesがZKゲームエンジンを発表：信頼不要のゲームを構築

業界速報

2024-03-15 18:05:13

コレクション

ZK トラストレスゲーム（Trustless Game）は、全チェーンゲームの次の波の潮流を導くでしょう。

共有する

WeChatでQRコードをスキャン

著者: Blade Research, Delphinus Lab

ZK信頼不要ゲーム（Trustless Game）が全チェーンゲームの次の波を導く。

要点：

Blade Games と Delphinus Lab は、WebAssembly と zkWASM に基づく信頼不要の zk ゲームエンジン（trustless game engine）を共同開発しました。

私たちの zk ゲームエンジンは、タワーディフェンス、RPG などの低速リアルタイムゲームカテゴリや、放置ゲーム、カード/オートチェスゲーム、インタラクティブノベルなどのゲームタイプをサポートします。簡単に言えば、ゲームのロジックを zkWASM 内で実行し（計算を処理する「zkサーバー」）、各ゲームの結果は zkSNARK 証明として生成され、公開されます。このゲームエンジンは、C++、Go、Rust などの言語をサポートしており、C# と Unity のサポートも間もなく登場します。

タワーディフェンスゲームの例を挙げると、典型的な 6 分間、100 波のモンスターのタワーディフェンスゲームでは、合計の zkSNARK 証明生成時間は約 3 分です。これは初期結果に過ぎず、私たちは証明生成時間を迅速に最適化しています。（100 万命令の ZKP 生成時間は 19 秒で、各モンスター波は 8 万命令、各ゲームは 800 万命令、8 つの zkSNARK 証明がクラウド計算端で生成される時間は約 3 分です）。

ZKVM に基づく信頼不要ゲームでは、維持コストは主に ZK 証明生成、RPC/呼び出しデータアクセスサービス、チェーン上の検証および決済費用から来ています。カンクンアップグレード（EIP 4844）が L2 で有効になるにつれて、信頼不要ゲームの運営コストは大幅に削減されました。

さらに、将来的に zkSNARK 証明の再帰（proof recursion）や Nebra の証明集約サービス（proof aggregation）を実施することで、ZKP のコストをさらに削減できます。

私たちのゲームパートナーには以下が含まれます：

Dune Factory（@BladeGamesHQ）：廃墟パンクスタイルの基地建設 + タワーディフェンス戦略ゲーム

0xPioneer：『Don't Starve』に似たマルチプレイヤーオンラインサバイバルゲーム

Craftpunk：改造可能な宇宙船とプログラム生成のマップを持つ、宇宙をテーマにしたオープンワールド RPG ゲーム

本文：

本 ZK ゲームエンジンは Blade Games と Delphinus Lab によって共同開発され、本記事は両者によって共同執筆され、より多くの Web2 ゲーム開発者や全チェーンゲーム開発者に ZK ゲームエンジンの利点と開発パスを理解してもらうことを目的としています。

これは、信頼不要の Web3 ブラウザゲーム開発に関するガイドです。（他の内容は https://www.youtube.com/watch?v=dLZbfTWLGNI で展示されており、注釈は https://delphinuslab.com/wp-content/uploads/2023/04/zksummit-presentation-zkwasm-game-1.pdf にあります）

Web3 のさらなる発展に伴い、全チェーンゲームが再び私たちの視界に入ってきました。彼らは、非中央集権性、透明性、無信頼性、コミュニティガバナンスにおいて優れていると主張しています。しかし、全チェーンゲームはブロックチェーンの非中央集権性、安全性、スケーラビリティのジレンマを引き継いでいます。これは、ゲーム開発者が全チェーンゲームの物語の中で、ゲームコンテンツ、インタラクションの頻度、非中央集権性、無信頼性、コミュニティの公平性管理の課題に直面することを意味します。

したがって、前のサイクルでは、ゲーム開発者はアーキテクチャのレベルでいくつかの妥協に達し、広く「Web2.5 ゲームアーキテクチャ」と呼ばれる実践のベストアーキテクチャを導入しました。

より正確に言えば、Web2.5 は Web3 と従来のゲームを混合した総称です。Web2.5 はゲームプレイのコンテンツを強調します。なぜなら、彼らはゲームの主要なオーディエンスがまだ Web2 に根ざしていると信じているからです。同時に、彼らはゲームに Web3 の要素（NFT、経済モデル、ゲームでの収益化）を追加して、彼らのゲームを際立たせています。

標準的な Web2.5 ゲームアーキテクチャは以下のようになります：

左側の図は、ゲームエンジンがゲームの状態機械を制御し、プレイヤーの活動に反応する様子を示しています。右側の図は、ゲーム状態の一部の変化を示し、チェーン上で最も価値のあるデータを明らかにしています。

ゲームのコアプレイは主に集中型のゲームサーバー上で実行され、最も価値のあるデータ（NFT、トークン報酬、記録など）はブロックチェーン上で追跡されます。

このアーキテクチャの利点は、ゲームサーバーが大量のユーザー取引を集中モードで処理でき、これらの取引が数秒で完了することです。さらに、集中型サーバーは複雑で持続的なゲームプレイを処理でき、通常、ネイティブブロックチェーンでこれらのプレイを処理するコストは非常に高くなります。

しかし、このアーキテクチャでは、ゲームエンジンとチェーン上のプロトコル間の通信チャネルは通常、署名によって保護されているため、信頼不要ではありません。また、ゲームコンテンツはコミュニティの合意なしに変更される可能性があり、これは時に既存のプレイヤーの既得権益を損なう可能性があります（例えば、ゲーム経済の更新、コンテンツの更新、さらには報酬制度の更新など）。

さらに、チェーン上のデータは、ブロックチェーンに渡されるデータがゲームプレイの有効な結果であるかどうかを確認するのが難しいです。サーバーは職務上の特権を利用してプレイヤーの行動を差別的に扱うことができます（例えば、ゲーム開発者のプライベートアカウントを優遇するなど）。

Web2 ゲームは通常、そのコンテンツとゲームプレイにおいて優れたパフォーマンスを示すため、バランスと公平性をゲームプロバイダーに委ねることは許容されます。しかし、Web2 ゲームが Web3 エコシステムに進出することを決定すると、経済、所有権、ゲームプロセスでの価値の捕捉に関心を持つ暗号ネイティブプレイヤーを引き付ける必要があるかもしれません。これらのプレイヤーは、ゲームを通じて豊かな結果を得るプロセスを楽しむだけでなく、ゲーム内で得た結果が一定の意味（例えば「持続可能性」）を持ち、さらには価値が増加する属性を持つことを望んでいます。相対的に、この「持続可能性」の価値増加効果への期待は、プレイヤーがゲーム内での選択をより真剣に考えることを意味します。これは、プレイヤーがゲームのルールの公平性と予測可能性に対する期待をさらに深めることを意味します。

最終的に、プレイヤーはゲームの「Web3 特性」を何らかの形で制御できることを要求します。公平性と信頼不要性の特性は、運営者やゲーム開発者によってではなく、定義されたコードのセットによって実行されるべきであり、より非中央集権的で完全にチェーン上に構築されたゲームを実現することが求められます。

これに関して、簡単な対策は、上記の図の左側のすべての内容を右側の図（ブロックチェーン）に移動させ、アーキテクチャを以下のようにすることです：

明らかに、この措置はゲームプレイの多くの「退化」を引き起こします：

プレイヤーの各アクションは、チェーン上の署名によってその承認を示さなければなりません。
ブロックチェーン上で実行されるゲームエンジンの規模は制限されます。
大量のガス費用を支払う必要があります。
プレイヤーとゲームの相互作用の頻度は、ブロックチェーンの TPS（Transaction per Second、毎秒取引数）制限に適応するために減少しなければなりません。

これは、私たちが「全チェーン哲学」を追求するために複雑で豊かなコンテンツを放棄しなければならないことを意味するのでしょうか？

ゼロ知識仮想機（ZKVM）技術が登場する前は、答えは「はい」だったかもしれません。しかし、ゼロ知識仮想機技術が広く研究され、応用されている事実を考慮すると、私たちは「第三の方法」を持つことができ、完全にチェーン上のゲームと信頼不要計算を組み合わせることができます。これはどのように実現されるのでしょうか？

ZKVM、すなわちゼロ知識仮想機は、ゼロ知識証明と仮想機技術を組み合わせた概念です。これを理解するために、以下の二つのモジュールを分解してみましょう：

ゼロ知識証明（ZKP）：これは、ある側が別の側に対して、特定の値（例えば鍵）を知っていることを証明する暗号技術であり、その値に関する情報を漏らすことはありません。ゼロ知識証明は、取引や相互作用の中でプライバシーと安全性を同時に保護することができ、実際のデータを共有することなく、主張の真実性を検証できます。
仮想機（VM）：仮想機は、物理的な意味でのコンピュータのソフトウェアシミュレーションです。これはオペレーティングシステムやアプリケーションを実行します。現実のコンピュータと同様ですが、完全にソフトウェアで実現されています。仮想機は、クラウドコンピューティングや単一のコンピュータ上で複数のオペレーティングシステムを実行するために広く使用されています。

これら二つを組み合わせて考えると、ゼロ知識仮想機（ZKVM）は、プログラムや契約を実行できる仮想機であり、ゼロ知識証明のプライバシーと安全性の利点を提供します。これは、私たちが zkVM 内でゲームエンジン（またはゲームサーバー）を実行し、zkVM を使用して ZK 証明を生成し、ブロックチェーンに対して状態の異なるデータの実行結果がゲームロジックによって強制されていることを証明できることを意味します。したがって、ゲームサーバーは、基盤となるブロックチェーンに送信されるデータを調整することができません。

このことを考慮すると、全チェーンゲームの統合アーキテクチャは以下のようになります：

私たちはこのような信頼不要の全チェーンゲームを「Trustless Game」と呼びます。

2. Trustless Game を開発する際に考慮すべき要素

2.1 初心者向けガイド

ゲーム開発は通常、複雑な技術、貴重な創造性、プロジェクト管理などの問題を伴うため、困難な作業と見なされます。ZKVM 技術を Trustless Game に適用する際に考慮すべき要素は以下の通りです：

技術的複雑性： Trustless Game では、ゲームのロジックをゲームの視覚化から分離する必要があり、ロジックは決定論的でなければなりません。これにより、ZKVM が証明を生成できるようになります。さらに、証明は実行される言語セグメント上で生成されるため、ゲーム開発者はゲームプレイを実行セグメントに分割し、定期的にチェーン上の契約と同期して実行する必要があります。

アートとデザイン： 一般的に、アーティストやデザイナーの仕事は、Trustless Game と他のゲームの間で異なることはありません。なぜなら、彼らの作業内容は証明されるべきロジックには含まれないからです。Trustless Game では、視覚化の開発はゲームの全体的な状態に基づいて行われ、UI/UX もプレイヤーの活動を収集するためのツールとして使用されます。

全体的なゲーム体験： 一般的な全チェーンゲームとは異なり、プレイヤーは毎回の移動時にチェーン上の行動を署名する必要がなく、これにより「頻繁な相互作用型ゲーム」を作成する可能性が高まります。これは、プレイヤーが頻繁に相互作用することを必要としたり奨励したりするゲームを指します。

しかし、ZKVM の証明生成時間の制約により、高頻度の相互作用は ZKVM で実行される Trustless Game では依然として実現不可能です。例えば、RTS（リアルタイムストラテジー）や MOBA（DOTA など）では、プレイヤーはユニットやリソースを継続的に操作し、戦略を調整して対戦相手を打ち負かす必要があります。このタイプのゲームは ZKVM に基づいて開発するのが難しいです。

相対的に、シミュレーションゲームや放置/農場ゲームでは、プレイヤーは定期的にリソースを配分したり、市場行動に参加したり、キャラクターを操作してゲーム内で成長を実現する必要があります。このようなゲームジャンルは、Trustless Game に非常に適しています。

さらに、インタラクティブストーリーゲームやビジュアルノベルも良い選択肢です。このようなゲームは持続的な相互作用を必要としないかもしれませんが、プレイヤーを引き付け、物語を形成し、プレイヤーの選択によって引き起こされる結果を確認するために頻繁な相互作用を奨励するために、絶えず出現する意思決定ポイントを通じてプレイヤーを魅了します。

次に、マネタイズと持続可能性について話しましょう。

一般的に、ゲームのコンテンツは時間の経過とともに進化し、新しいプレイヤーを引き付け、古いプレイヤーを保持します。これにより、ゲームプレイのロジックが動的になり、ZKVM で実行されるプログラムに影響を与えます。これにより、検証契約が変更され、更新が必要になる可能性があります。

ZK 検証が必要な契約の頻繁な変更を回避する方法は以下の二つです：

ゲームプレイの変更：ゲームプレイのためのプロトコル層を抽象化し、ゲームのこれらの動的特性をルールとして定義します。こうすることで、開発者はこれらのルールセットをチェーン上に保存し、これらのルールをチェーン上のハッシュに提出できます。同時に、ゲームエンジンがゲームロジックを実行する際に、現在のルールセットのハッシュが約束と一致するかどうかを最初に確認し、それに応じて行動します。
決済の変更：報酬システムはゲームプレイ自体の独立した層として機能できます。すべての報酬アルゴリズムをゲームプレイ中に生成される特定のイベントのコールバックとして扱うことができます。こうすることで、報酬コールバックをチェーン上に置き、ゲームイベントに基づいてこれらのコールバックを呼び出すことができます。

例えば、以下のゲームループがあります：

zkgame {

// ゲームロジック

output(events)

}

生成されたイベントは、実行の証明インスタンスとなります。したがって、ゲームプレイの信頼不要の ZK 証明は以下のコードです：

fn execution(cs: Vec\<command>) {

for command in cs {

global_state = handler(command);

}

ゲーム中に、コントローラーが送信した最後のコマンドを特定するのは難しく、すべてのコマンド処理を単一の ZK 証明にまとめるのは困難です。したがって、最良の方法は、コマンドを複数の部分に分割し、それらを証明し、次にそれらをバッチ処理して単一の証明を生成し、チェーン上でさらに検証することです。

注：上記の方法には二つの欠落した部分があります：

各実行セグメント間の状態の連続性をどのように確保するか
異なるゲームクライアントからのコントローラーが相互に干渉する場合、どのようにマルチプレイヤーの同時出現シーンを処理するか

次の章では、マルチプレイヤーのシリアル化とデータの可用性について簡単に紹介します。各テーマは深く掘り下げることができるため、他の個別のノートでより詳細な内容を提供する予定です。

4. マルチプレイヤーゲームにおけるユーザーインタラクションのシリアル化

モジュラーブロックチェーンの文脈において、シリアライザーは、インタラクションが最終的に確認される前にそれを並べ替える責任を持つコンポーネントまたはノードです。モジュラーブロックチェーンアーキテクチャは、ブロックチェーン機能の異なるレイヤー（例えば、実行、コンセンサス、データの可用性）を異なるコンポーネントに分離します。このアプローチは、各レイヤーを独立して最適化できるようにすることで、スケーラビリティ、安全性、効率を向上させることを目的としています。

マルチプレイヤーゲームを開発する際にも、異なるユーザー間のインタラクションを並べ替えるのを助けるコンポーネントが必要です。したがって、モジュラーブロックチェーンのシリアライザーという用語を二次使用します。

ゲームには低遅延が必要なため、迅速な並べ替え結果を生成する集中型シリアライザーを選択するのが最善です。ゲームエンジンは、並べ替えられたトランザクションを取得しながら、シリアライザーと密接に連携することもできます。

単一プレイヤーインタラクションプロトコル

ここでは（下図参照）、プレイヤーの視点からインタラクションプロトコルを説明します。ユーザー取引では、ユーザーは自分の入力を説明し、公共入力と証明入力を通じて自分の身元を証明します。これらの入力は以下のレイアウトを持つことができます：

公共入力と証明入力：

インタラクション処理ロジック：

pub fn zkmain() -> i64 {

let mut hasher = Sha256::new();

// コマンドの長さを取得

let commandslen = unsafe {wasminput(0)};

// すべてのコマンドを処理し、

// 将来の署名検証のためにコマンドをハッシュ化

for _ in 0..commands_len {

let command = unsafe {wasm_input(0)};

hasher.update(command.tolebytes());

step(command);

}

let msghash = hasher.finalize();

let pk = unsafe {BabyJubjubPoint {

x: U256([

wasm_input(0),

]),

y: U256([

wasm_input(0),

]),

}};

zkwasmrustsdk::dbg!("process sig\n");

let sig = unsafe {JubjubSignature {

sig_r: BabyJubjubPoint {

x: U256([

wasm_input(0),

]),

y: U256([

wasm_input(0),

]),

sig_s: [

wasm_input(0),

]

}};

let msghash_u64 = [

u64::frombebytes(msghash[24..32].try_into().unwrap()),

u64::frombebytes(msghash[16..24].try_into().unwrap()),

u64::frombebytes(msghash[8..16].try_into().unwrap()),

u64::frombebytes(msghash[0..8].try_into().unwrap()),

];

sig.verify(\&pk, \&msghash_u64);

5. コスト分析

5.1 コストの概要

ZKVM に基づく信頼不要の全チェーンゲームでは、主な維持コストは ZK 証明生成、迅速なデータ RPC サービス、呼び出しデータアクセスサービス、チェーン上の検証および決済費用から来ています。カンクンアップグレード（EIP 4844）が L2 で有効になるにつれて、信頼不要ゲームの運営コストは大幅に削減されました。さらに、将来的に zkSNARK 証明の再帰（proof recursion）や Nebra の証明集約サービス（proof aggregation）を実施することで、ZKP のコストをさらに削減できます。

5.2 ZK 証明生成コスト

まず、ZKVM はアプリケーションを実行し、実行トレース（execution trace）を生成します。このトレースは基本的なものであり、ZKVM は以下を証明する必要があります：

このトレースが ZKVM がサポートするバイトコードの意味を強制したこと
通常、ZKVM 自体は無状態（stateless）です。ゲームの有状態ストレージ（stateful storage）をサポートするために、データの設定と取得をメルクル証明に変換するアイデアを利用しています。
ZKVM は通常、実行トレースを複数のセグメントに分割し、それぞれに対して証明を生成します。これらの証明はバッチ処理され、最終的に検証可能な単一の証明が生成されます。

私たちが使用している ZKVM が、メルクル証明を処理するためにプリコンパイルされた命令をシステムコール（または ZKWASM のホスト API）として使用していると仮定します。ZK 証明を生成する全体的なコストは以下のようになります：

証明コスト = ZKVMGuest 証明コスト + メルクル証明コスト + バッチ処理証明コスト（ BatchProofCost ）

通常、等式の右側の第一項と第三項は、純粋な ZK 証明を除いて追加のコストを引き起こしません。しかし、第二項のコストには微妙な点があり、いくつかのデータストレージサービスのサポートが必要です。

メルクル証明の構成要素を振り返ってみましょう：

メルクルツリーの設定

私たちは全体のデータをブロックに抽象化し、それぞれを個別にハッシュ処理します。これらのハッシュはターゲットツリーの葉ノードとなります。次に、葉ノードのペアをハッシュ処理して次のレベルのノードを形成し、このプロセスを繰り返して最上部に一つのハッシュが残るまで続けます。これをメルクルルートと呼びます。メルクルルートは、ツリー内のすべてのデータブロックの唯一の表現です。

データ包含証明

この証明は、問題の特定のデータブロック、そのハッシュ、およびメルクルツリーからの少量の追加ハッシュで構成されます。これらの追加のハッシュは、検証者がデータセットのメルクルルートを独立して計算できるために必要な最小限の値です。

検証証明：

検証者はデータセットのメルクルルートを知っていますが、必ずしもその中のすべてのデータの検証者を知っているわけではありません。彼は提供されたデータブロックと追加のハッシュを使用して、メルクルルートへのハッシュパスを再構築します。計算されたメルクルルートが既知のメルクルルートと一致すれば、証明は有効であり、そのデータブロックがデータセットの一部であり、改ざんされていないことが確認されます。

状態を持つ ZK ゲームを維持するには、メルクルデータベースが必要で、メルクルツリーの葉を追跡し、迅速なデータクエリサービスを提供します。このサービスは、データの変更頻度が非常に高く、アクセス（読み取り/書き込み）の需要も高いため、完全にチェーン上でホストされることはほとんどありません。

取引が完了すると、呼び出しデータと最終状態（新しいメルクルツリーのルートによって表される）はアクセス可能である必要があります。これは通常、DA レイヤーまたはチェーン上の txdata ストレージを通じて実現されます。

5.3 データコスト

Blade Games の分析に基づき、ZKWASM、Eth Storage、BNB Greenfield DA ストレージコスト計算機（https://dcellar.io/pricing-calculator）および Google Cloud ストレージ計算機（https://cloud.google.com/products/calculator）を参考にすると、以下の結論が得られます：zk 協調処理器方式を使用して 5,000 人のプレイヤー（彼らが休むことなくプレイしていると仮定すると、実際の DAU は 5,000 よりもはるかに高いです）のチェーン上ゲームを運営する場合、月間コストは約 90,000 ドルであり、このコストは高防御、反 DDOS の MMORPG ゲームサーバーのコストに類似しています。

Blade Games の見積もり方法は以下の通りです：彼らは Unity で公開されたユーザーイベントをバイナリコードに変換し、ZKWASM 内で実行します（ZKWASM は Delphinuslab によって開発された WASM バイトコードをサポートする ZKVM です）。次に、ZKWASM は実行トレースを生成し、圧縮されたトレースを DA レイヤーに公開し、同時に彼らはチェーン上にトレースハッシュを公開し、デジタル署名で不変性を検証します。

ETHstorage と zkwasm のテスト実行に基づくと、1 秒間の wasm バイナリファイルを実行すると、100 万行のトレースが生成され、各行のサイズは 40 バイトです。

私たちは、すべてのトレースをチェーン上で証明するか、トレースを保存するかを選択できます。ユーザーが結果に異議を唱える場合は、証明を行います。

すべてのトレースを証明する ZK 方法

すべてのトレースを証明することを選択した場合、100 万バイトコードは単一の RTX4090 グラフィックカード上で約 25 秒かかり、コストは 0.5 セント（コストは 1 ドルあたり 2000M 命令）になる可能性があります。このソリューションでは、コストは主に証明能力費用、チェーン上の検証費用、および DA の呼び出しデータストレージ費用から来ます。この方法を使用して、毎時 1000 億トレースのマルチプレイヤーゲームをサポートすると、毎時約 50 ドル（毎月 36,000 ドル）の証明コストがかかります。

詐欺証明方法

5000 人のプレイヤーがいると仮定し、各プレイヤーが平均して 2 時間連続してプレイし、各プレイヤーが毎時 86.4 万億トレースを生成するとします。したがって、毎日のストレージ消費量は 60 秒 * 60 分 * 2 時間 * 5000 人のプレイヤー * 100 万バイトコード = 36,000,000,000,000 トレースです。ETHstorage と zkwasm のテストによると、各トレースのストレージ消費量は 40 バイトです。したがって、5,000 人のプレイヤーがいるゲーム（平均オンライン時間 2 時間）では、毎日 1,440TB のストレージスペースを消費します。

合理的な比率で 10 倍圧縮されたトレースを考慮すると、毎日 144TB の Google Cloud ストレージスペースを消費し、これは月間で 4,320TB に相当し、コストは約 90,120 ドル/月（アーカイブストレージ層では、標準ストレージ層はより高いデータアクセス頻度を許可し、コストは月額 185,000 ドルになります）。さらに、BNB Greenfield で署名データを保存するコストは、1GB あたり 0.0001 BNB、約 0.03 ドルです。この方法では、オブザーバーノードがトレースの整合性を確認し、不誠実な取引を報告するために ZKFraud 証明をトリガーできます。

上記の議論に基づいて、次の結論が得られます：大規模なプレイヤーゲームの運営コストは、高防御の反 DDOS MMORPG ゲームサーバーのコストに類似しています。

6. コンテンツのアップグレードとモジュールプロトコル

成功したゲームは通常、動的なゲームコンテンツを持ち、定期的にエンジンを更新する必要があります。これは、暗号ネイティブコミュニティで人気の「コードは法律」という理念と矛盾するように見えます。

しかし、この課題には潜在的な解決策があります。

メンテナブルなルールをブロックチェーン上に置く設計パターンを採用することで、ゲームプレイのアップグレードや変更がこれらの基本ルールに準拠することを保証できます。ゲームアーキテクチャの文脈におけるこのテーマの複雑性を考慮し、以下の図を使用して簡潔に説明します：

7. 結論

zkVM と関連インフラの登場により、全チェーンゲーム開発者は複雑で豊かなコンテンツと「全チェーン哲学」を両立できるようになります。私たちは、このような「信頼不要ゲーム」が広範な市場の展望と空間を持つと考えています。

zkVM とモジュラーな実行レイヤーの概念を組み合わせることで、ゲームの市場戦略（GTM）も非常に柔軟になります。ゲームプレイヤーが Eigenlayer、zkWASM、Berachain などの人気プロジェクトと同時に相互作用し、エアドロップを受け取り、ゲーム内自体の利益を得ることができることを想像してみてください。これはゲームの早期冷スタートに大きな助けをもたらすでしょう。

読者の「開発コストは依然として高いのか？」という疑問に対して、私たちは、ZKVM に基づく信頼不要ゲームでは、カンクンアップグレード（EIP 4844）が L2 で有効になり、再帰証明、証明集約の適用、そして zkVM 自体の最適化により、信頼不要ゲームの運営コストが大幅に削減されていると考えています。Trustless Game の開発に興味がある場合は、Twitter（bladegamesHQ）で DM を送ってください。私たちは、ゲーム開発、コード、GTM に関する支援を提供します。

Trustless Game の開発に興味がある場合は、Twitter（bladegamesHQ）で DM を送ってください。私たちは、ゲーム開発、コード、GTM に関する支援を提供します。