
全チェーンゲームの新章:ZKWASMで証明可能なゲームを開発
TechFlow厳選深潮セレクト

全チェーンゲームの新章:ZKWASMで証明可能なゲームを開発
もしゲームロジックをすべてブロックチェーン上に置く場合、EVM 自体の限られた計算能力がゲーム開発における最大のボトルネックとなる。
著者: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のゲーム応用に関する議論、または共に働きたい方に向け、ぜひご連絡ください!
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














