著者：Blade Research

コア著者：wangyao、0xbrawler

目次

• なぜ「証明可能ゲーム（Provable Game）」を開発するのか？
• Blade Gamesの技術アーキテクチャ
• 1) zkwasmを用いたシンプルなタワーディフェンスゲームの開発
• 2) Zinity：Unityから直接証明可能ゲームを開発できる業界初のソリューション
• アーケードゲーム（arcade game）とERC-6551の応用
• ETHdenverで披露予定のゲーム
• 今後の開発計画および研究テーマ

本稿の執筆にあたり、Sinka、Wangyao、Will Robinson、Mohamed Fouda、LoneSCV、0xAiko、Simon Chan、Maggie Wu、James Fang、Zee各位に感謝いたします。

要点まとめ：

• ZK協プロセッサ方式は、検証可能なゲームに必要な信頼性の仮定と、魅力的なゲーム体験を実現するために必要な計算能力を提供する
• 経験豊富なゲーム開発者にとって、Solidity/CairoでのコアゲームロジックとUnityでのアニメーション/レンダリングを同期させるよりも、Unity/Unrealネイティブのソリューションが【非常に】必要である
• オンチェーンゲームおよび検証可能ゲームの将来の開発者体験は、高度にモジュール化され、プラグアンドプレイ可能な形となる（どこまでを「オンチェーン」と呼ぶか？それは開発者とユーザーが決めるべきだ）
• 今後は、信頼性の仮定・証明コスト・開発コストの間で柔軟なトレードオフを行い、開発コストを抑えた検証可能ゲームの開発が可能になると信じている

なぜ証明可能ゲームを開発するのか？

2023年は、FOCG（フルオンチェーングラム）／AW（オートノマスワールド）が盛り上がり、Mud.dev、Dojo、World Engine、Keystone、Paimaなど多くのインフラが登場した年でした。またAltlayer、Caldera、ConduitなどのRollupサービスプロバイダーも、多数の全チェーンゲーム開発者を惹きつけています。

しかし、我々が最初のオンチェーンバトルロイヤルゲーム『Loot Royale』を開発・運営し、1か月でDAU 600～800を達成する中で、重大な課題に気づきました。

ゲームロジックをすべてチェーン上に置く場合、EVM自体の限られた計算能力が、ゲーム開発における最大のボトルネックになる。

計算能力の不足により、ゲームジャンル（低計算量・シングルスレッド・非同期ゲームが中心）やユーザーエクスペリエンス（トランザクションの承認待ち、RPCからのhydration待機など）が制限されます。

具体的には、「自分のアクションがタイムリーに反映されていれば、あの攻撃が当たっていたのに」「RPCのデータ読み込みはいつ終わるの？」といったフィードバックを多くいただきました。これは変える必要があります。

プレイヤーがRPCのhydrationを待つのは本当にイライラする

さまざまな技術スタックでの開発を試みた結果、我々は「チェーン外で計算を証明できれば、その信頼性はほぼオンチェーンの計算と同等になる」と確信しました。そこで「チェーン外実行、チェーン上検証」という原則を採用し、EVMの計算能力の限界を克服します。これには以下の利点があります。

• ユーザーエクスペリエンスの改善、待ち時間の短縮
• タワーディフェンスのようなより多くの計算を要する「ミッドコア」ゲームなど、ゲームジャンルの拡大
• ゲーム内での非公開情報（hidden information）の利用支援

まず、zkwasmを使って証明可能なゲームを開発する方法について簡単に紹介します。その後、我々のzkwasm-UnityソリューションであるZinityについて説明します。これは業界で初めて、Unityから直接証明可能ゲームを開発できるようにするものです。

Blade Gamesの技術アーキテクチャ

zkwasmを用いたシンプルなタワーディフェンスゲームの開発

技術アーキテクチャは二つの部分に分けられます。第一に、RustでシンプルなPvE・PvPのタワーディフェンスゲームを開発し、zkwasmで検証を行うことです。

第二に、C#をwasmにコンパイルするコンパイラーを開発し、既存のzkwasmアーキテクチャを適切に修正することで、よりモジュール的で柔軟な証明可能ゲーム開発フレームワークを実現するというロードマップです。（zkwasmはDelphinus Labsが開発したもので、wasmコードを実行し、その実行軌跡に対してzkSNARK証明を生成するzkVMです。）

PvEの例から始めましょう。RustとBevy Engineでゲームを開発しています。

Rustは簡単にwasmにコンパイルでき、zkwasm VMで処理される前にwasmイメージを生成できます。その後、実行軌跡をデータ可用性レイヤー（Data Availability Layer）に公開して後から証明するか、あるいは即座に証明を行い、zkSNARK証明をチェーン上に送信することも可能です（RTX4090 GPU一枚で約45秒で100万ガス規模の証明を処理可能。これは比較的ゆっくりとしたペースのタワーディフェンスゲームにとっては十分な速度です）。

ゲームの流れは以下のように分解されます。

• プレイヤーがマップ設定を確定し、関連情報をチェーン上にコミットする
• Rustコード内で一ラウンドの戦闘を実行。関連するexecution traceはzkwasmによって証明され、プレイヤーがzk証明をチェーン上に提出する
• 次の波のモンスターが出現。プレイヤーは以前のタワー設定を維持するか、新たなコミットを再提出するかを選択可能
• 各ラウンドの戦闘中はタワー設定を変更できない。マップ設定を変更したい場合は、再度新しいコミットを提出できる

（プレイヤーがマップ設定を確定し、zkwasmの出力をチェーン上に提出）

（Rustコード内で一ラウンドの戦闘を実行。対応するexecution traceはzkwasmで証明され、プレイヤーがzk証明をチェーン上に提出）

Zinity：Unityから直接検証可能ゲームを開発できる最初のソリューション

多くのゲーム開発者にとって、オンチェーンゲームを開発することは、Solidity、Rust、Cairoなどを学ぶ必要があることを意味します。つまり、彼らが慣れ親しんだC#の使用をやめなければならないのです。さらに、Unityエンジンのレンダリング・アニメーションと、Mud/DojoベースのSolidity/Cairoのゲームロジックを統合しようとすると、非常に手間がかかります。

我々は、zk協プロセッサとUnityネイティブを活用した、オンチェーンゲーム向けの「zkServer」開発フレームワークを発表します。これをZinityと呼びます。

ゲームコードは以下のように分離されます。

1）コアロジック（攻撃、ロットボックス、ユニット座標など）

2）それ以外のコード。これら両方のコードをC#からwasmにコンパイルし、コアゲームロジックはzkwasmランタイムで実行され、残りのコードは通常のC#ランタイムで実行されます。両者間の通信は、メッセージ処理プロトコルによって行われます。

zkWASMは、「プレイヤーAが時刻Xに座標(x,y)にタワーを設置した」といった行動をバイナリコードとして証明します。新しいゲームが始まると初期ゲーム状態を取得し、進行とともにzkwasmはさらなるプレイヤー入力を証明・計算します。ゲーム終了時には、ハッシュ値付きの新しいゲーム状態と対応する実行軌跡（execution trace）が生成されます。

実行軌跡全体をEigenlayer/Celestia/Avail/Greenfieldなどのデータ可用性レイヤー（DA layer）に公開するか、あるいはハッシュ値のみをDA層に保存し、軌跡自体はクラウドストレージに保管することも可能です。さらに、ファルトプルーフ方式による検証のために、チャレンジ期間も設計します。

また、重要な経済的価値を持つゲーム結果については、ユーザーがゲーム全体のzk証明を生成し、DA層に直接公開することも選択できます。

最後に、すべてのプロセスはUnity SDK（アニメーション・レンダリング除く）またはCLIツールとして統合され、ツールチェーン全体をガイドします。

このソリューションはUnity/Unreal/Godotなどの他のゲームエンジンにも拡張可能であり、将来的には他のzkVM（RiscZeroなど）や各種DA層（Eigenlayer/Celestiaなど）との統合も計画しています。

このアプローチにより、Web2のゲーム開発者やゲームスタジオを含む、より広範なオンチェーンゲーム／検証可能ゲーム開発者コミュニティを大きく拡大できます。

ERC-6551を活用したオンチェーンアーケード＋タワーディフェンスゲームプレイ

さらに、我々は証明可能ゲームを中心としたオンチェーンアーケードの概念も模索しています。例えば、プレイヤーがタワー／砲台／障害物の配置をチェーン上に提出し、別のプレイヤーがモンスターやミニオンの編成を提出してステージを攻略しようとするPvP形式です。戦闘結果はローカルで計算され、その結果の正当性を証明するzk-SNARK証明だけがチェーン上に提出されます。これにより、ステージ突破の方法がチェーン上で公開されることなく保たれます。

ERC-6551（トークンバインドアカウント）により、これらのPvP対戦は自律型アーケード（autonomous arcade）となります。部屋を作成するプレイヤーはスマートコントラクトに報酬を預け入れ、挑戦者は固定の参加料を支払い、それが賞金プールに蓄積されます。ステージを成功裏にクリアしたプレイヤーに報酬が与えられ、特にトップ10のプレイヤーには一定割合の賞金が分配されます。

我々はこの自律型アーケードのアイデアを積極的に検討しており、Twitter（@BladeGamesHQ）での議論を歓迎しています。今後発表する記事では、タワーディフェンスゲームのPvP事例について詳しく解説する予定です。

ETHdenverで披露するゲーム

ETHdenverでは、証明可能なゲームのデモを披露する予定です。このゲームはRustとReactで開発され、zkwasm上で動作します。Twitterでご連絡いただければ、早期プレイリストに追加いたします！

結論と今後の展開

• ZK協プロセッサ方式は、検証可能なゲームに必要な信頼性の仮定と、魅力的なゲーム体験を実現するために必要な計算能力を提供する
• 経験豊かなゲーム開発者にとって、（非常に）Unity/Unrealネイティブのソリューションが必要であり、Solidity/CairoのコアゲームロジックとUnityのアニメーション/レンダリングを統合する必要はない
• オンチェーンゲームおよび検証可能ゲームの将来の開発者体験は、高度にモジュール化され、プラグアンドプレイ可能なものとなる（どこまでを「オンチェーン」と呼ぶか？それは開発者とユーザーが決めること）
• 今後は、信頼性の仮定・証明コスト・開発コストの間で柔軟なトレードオフを行い、検証可能ゲームを開発できるようになると信じている

我々のZinityソリューションは、Web2およびWeb3の開発者が証明可能ゲームをスムーズに開発できる体験を提供します。さまざまなゲームエンジン、DAレイヤー、zkVMを自由に組み合わせられるプラグアンドプレイ方式により、開発体験の柔軟性が大幅に向上すると考えています。

我々が描く将来の開発者体験はこうです。Zinityは証明可能ゲームに対して「柔軟性（elasticity）」を提供し、Crypto開発者やWeb2ゲーム開発者に、プラグアンドプレイ可能な開発オプションを提供します。

例えば、開発者はRustでコアゲームロジックを書き、C#とUnityで残りの部分を開発し、実行軌跡やそのハッシュをチェーン上にコミットして、ZKPの生成を後回しにできます。これにより、開発コストと証明コストの両方が大幅に削減されます。

このような柔軟なモデルにより、開発者はC#とUnity内部で初期のゲームアイデアを迅速にテストし、その後「どの程度オンチェーンにするか」を反復的に決定できます（どこまでを「オンチェーン」と呼ぶか？それは開発者とユーザーが決めるべき）。また、ゲームデザインとブロックチェーン性能のトレードオフを事前にストレステストすることも可能になります。

自社のゲーム開発や様々な技術スタックのテストを通じて、より良いゲームフローとUIUXを得るためには、経験豊富なWeb2ゲーム開発者が証明可能ゲームの開発に参加することが不可欠だと気づきました。そのため、我々は独自の先駆的ソリューションを提案し、より広いオンチェーンゲーム開発者コミュニティに貢献したいと考えています。

我々はzkwasmと証明可能ゲーム開発に関する多くの内容を執筆しており、現在も継続中の作業があります。主なトピックは以下の通りです。

• 証明可能ゲーム向けにzkwasmを改造（進行中）
• 本手法のDAコストおよび証明コストの見積もり（完了）
• 証明可能ゲームのmodding、相互運用性、オンチェーン無許可インタラクション（進行中）
• 関連する証明可能ゲームの設計思想（進行中）

証明可能ゲームの開発、zkVMのゲーム応用に関する議論、または共に働きたい方に向け、ぜひご連絡ください！