Blade GamesがZKゲームエンジンをリリース：非信頼型ゲームの構築へ

2024.03.15

共有先

TechFlow厳選深潮セレクト

Blade GamesがZKゲームエンジンをリリース：非信頼型ゲームの構築へ

ZK非信頼ゲーム（Trustless Game）は、フルチェーンゲームの次なる波を牽引する。

2024.03.15 - 10:53:37

gameFi

Web3業界の深掘り報道に専念し潮流を洞察

ZK非信頼ゲーム（Trustless Game）は、フルチェーンゲームの次なる波を牽引する。

執筆：Blade Research、Delphinus Lab

要点まとめ：

Blade Games と Delphinus Lab は、WebAssembly および zkWASM を基盤とする信頼不要な（trustless）ゲームエンジンを共同開発しました。

本zkゲームエンジンは、タワーディフェンスやRPGといった低速リアルタイムゲーム、およびプレースメントゲーム、カード／オートチェスゲーム、インタラクティブノベルなどに対応可能です。簡単に言えば、ゲームロジックをzkWASM内（計算処理を行う「zkサーバー」）で実行し、各ゲームセッションの結果に対してzkSNARK証明を生成してブロックチェーン上に提出します。また、C++、Go、Rustなどの言語をサポートしており、将来的にはC#およびUnityもサポート予定です。

タワーディフェンスゲームの例では、典型的な6分間・100ウェーブのゲームにおいて、zkSNARK証明の生成時間は約3分です。これは初期段階の結果であり、現在さらなる最適化を進めています。（100万命令に対するZKP生成時間は19秒、1ウェーブあたり約8万命令、1ゲームあたり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ブラウザゲーム開発に関するガイドです。（関連内容はYouTubeでも紹介されており、関連リンクあり）

Web3の進展に伴い、フルチェーンゲームが再び注目を集めています。これらは分散性、透明性、非中央集権性、コミュニティガバナンスにおいて優位性を謳っています。しかし同時に、フルチェーンゲームはブロックチェーンが抱える分散性・安全性・拡張性のジレンマも引き継いでいます。つまり、ゲーム開発者はゲームコンテンツ、ユーザーとのインタラクション頻度、分散化、信頼不要性、公平性の管理という課題に直面しています。

そのため、前回のサイクルでは、開発者たちはアーキテクチャの側面で妥協を余儀なくされ、「Web2.5ゲームアーキテクチャ」と呼ばれる実用的なベストプラクティスが広く採用されました。

より正確に言えば、Web2.5とはWeb3と従来型ゲームを融合した総合概念です。Web2.5はゲームプレイのコンテンツに重点を置きます。なぜなら、ゲームの主要なユーザーベースは依然としてWeb2に根ざしていると考えられているためです。同時に、NFT、経済モデル、Play-to-EarnといったWeb3要素を取り入れることで、自社のゲームを差別化しています。

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

左側の図は、ゲームエンジンがゲームのステートマシンを制御し、プレイヤーの行動に応答する様子を示しています。右側の図は、ゲーム状態の一部が変化し、ブロックチェーン上に価値のあるデータが記録されることを示しています。

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

このアーキテクチャの利点は、ゲームサーバーが多数のユーザー取引を集中モードで処理でき、数秒以内に完了できる点にあります。また、複雑かつ継続的なゲームプレイも処理可能で、これはネイティブブロックチェーン上で処理する場合に比べてコストが非常に高くなるため、現実的です。

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

さらに、オンチェーンデータからは、ブロックチェーンに送信されたデータが実際にゲームプレイの正当な結果であるかを検証することが困難です。サーバー側が便宜上、特定のアカウント（例えば運営者のプライベートアカウント）に有利な処理を行うことも理論的に可能です。

従来のWeb2ゲームはコンテンツとゲームプレイの質が高いため、バランスと公正性をゲーム提供者に委ねることは許容できます。しかし、Web2ゲームがWeb3エコシステムに参入する際には、経済、所有権、価値獲得に敏感な暗号資産原住民層を惹きつける必要があります。彼らは単にゲームを通じて豊かな成果を得るだけでなく、その成果が一定の意味（例：「持続可能性」）を持ち、価値が増加することを期待します。こうした「持続可能性」への期待が高まれば、プレイヤーは自分のゲーム内選択に真剣に向き合うようになり、意思決定コストが上がるため、ゲームルールの公平性と予測可能性に対する要求も高まります。

最終的には、プレイヤーはゲームの「Web3的特性」— すなわち、公平性と信頼不要性 — を何らかの形で制御したいと考えるでしょう。これらの特性は運営者／開発者ではなく、コードによって自動実行されるべきであり、より分散化され、完全にオンチェーンで構築されたゲームが必要とされます。

そこで考えられるシンプルな解決策は、前述の図の左側すべてを右側（ブロックチェーン）に移動させ、以下のようなアーキテクチャにすることです：

明らかに、このアプローチはゲームプレイの多くの「劣化」を引き起こします：

プレイヤーのすべての行動を、オンチェーン署名で承認を示す必要がある
ブロックチェーン上で動作するゲームエンジンの規模に制限がかかる
多額のガス代が発生する
ブロックチェーンのTPS（毎秒取引数）制限に合わせ、プレイヤーとゲームのインタラクション頻度を減らさなければならない

これは、複雑だが豊かなコンテンツを捨てて「フルチェーン哲学」を追求しなければならないことを意味するのでしょうか？

ゼロ知識仮想マシン（ZKVM）技術が登場する前であれば、答えは「はい」だったかもしれません。しかし、現在ZKVM技術は広く研究・応用されつつあるため、「第3の道」、つまり完全オンチェーンゲームと信頼不要な計算を組み合わせることが可能になりました。どのように実現するのでしょうか？

ZKVM（Zero-Knowledge Virtual Machine）とは、ゼロ知識証明と仮想マシン技術を統合した概念です。これを理解するために、以下の2つのモジュールに分解しましょう：

ゼロ知識証明（ZKP）：ある当事者が他の当事者に対して、ある値（例：鍵）を知っていることを、その値の情報を一切明かさずに証明できる暗号技術です。ZKPは取引やインタラクション中にプライバシーとセキュリティを両立できます。なぜなら、実際のデータを共有せずに命題の真偽を検証できるからです。
仮想マシン（VM）：物理的なコンピュータをソフトウェアで模倣したもの。オペレーティングシステムやアプリケーションを実行できます。実際のコンピュータと同じように振る舞いますが、完全にソフトウェア上で実装されています。クラウドコンピューティングや、単一PC上で複数OSを動作させるために広く利用されています。

これらを組み合わせると、ZKVMとはまず仮想マシンであり、プログラムやコントラクトを実行しつつ、ゼロ知識証明のプライバシーとセキュリティの利点を提供します。つまり、ゲームエンジン（またはゲームサーバー）をzkVM内で実行し、その実行結果についてブロックチェーンにZK証明を提出することで、どのデータがゲームロジックに基づいて処理されたのかを検証できます。これにより、ゲームサーバーがブロックチェーンに送信するデータを恣意的に改変できなくなります。

このような観点から、フルチェーンゲームの統合アーキテクチャは次のようになります：

このような信頼不要なフルチェーンゲームを、我々は「Trustless Game（信頼不要ゲーム）」と呼びます。

2. Trustless Game開発時に考慮すべき要素

2.1 初心者向け注意点

ゲーム開発は一般的に困難とされています。技術的複雑さ、創造性、プロジェクト管理などが絡むためです。ZKVM技術をTrustless Gameに適用する場合、以下の要素を考慮する必要があります：

技術的複雑さ：Trustless Gameでは、ゲームロジックとビジュアル表示を分離する必要があり、さらにロジックは決定論的（deterministic）でなければなりません。なぜなら、ZKVMが証明を生成するためです。また、証明は実行されるコードセグメントごとに生成されるため、開発者はゲームプレイを複数のセグメントに分割し、定期的にオンチェーンコントラクトと同期する必要があります。

アートとデザイン：アーティストやデザイナーの作業内容は、Trustless Gameであっても他と変わりません。なぜなら、彼らの作業は証明対象のロジックに含まれないからです。ただし、ビジュアル開発はゲームのグローバルステートに基づいて行われるべきであり、UI/UXはプレイヤーのアクション収集ツールとしても機能します。

全体的なゲーム体験：一般的なフルチェーンゲームとは異なり、プレイヤーは毎回の行動をオンチェーン署名する必要がないため、「頻繁なインタラクションを要するゲーム」の開発が可能になります。これは、プレイヤーが頻繁に操作を行うことを前提としたゲームタイプです。

しかし、ZKVMの証明生成時間の制約により、RTS（リアルタイムストラテジー）やMOBA（例：DOTA）のような高頻度インタラクションを要するゲームは、現時点ではZKVM上で開発することが困難です。これらのゲームではプレイヤーが継続的にユニットやリソースを操作し、戦略を調整する必要があるため、実現が難しいのです。

一方で、シミュレーションゲームや放置／ファーム系ゲームでは、プレイヤーが定期的にリソースを配分したり、市場参加やキャラ操作を通じて成長を目指すため、Trustless Gameに非常に適しています。

また、インタラクティブストーリーゲームやビジュアルノベルも好適です。これらは継続的な操作を必要としないものの、決断ポイントを通じて物語を形成し、プレイヤーの選択がもたらす結果を確認するための繰り返しインタラクションを促します。

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

一般に、ゲームのコンテンツは時間とともに進化し、新規プレイヤーを惹きつけ、既存プレイヤーを維持する必要があります。これによりゲームロジックが動的になり、ZKVM上で動作するプログラムにも影響を与えます。その結果、検証コントラクトの変更や更新が必要になる可能性があります。

ZK検証対象のコントラクトを頻繁に変更しなくて済むようにするには、以下の2つの方法があります：

ゲームプレイの変更：ゲームプレイに抽象的なプロトコル層を設け、動的な要素を「ルール」として定義します。これにより、開発者はこれらのルールセットをオンチェーンに保存し、ハッシュとしてコミットできます。ゲームエンジンは実行前に、現在のルールセットのハッシュがコミットと一致するか確認し、それに基づいて動作します。
報酬システムの変更：報酬システムをゲームプレイとは独立したレイヤーとして扱います。報酬アルゴリズムを、ゲームプレイ中に発生するイベントのコールバックとしてみなすことで、報酬処理をオンチェーンに配置し、ゲームイベントに応じて呼び出すことができます。

例えば、以下のようなゲームループを考えます：

zkgame {

// Game logic

output(events)

}

このイベントは証明のインスタンスとなります。よって、コントラクトにコールバックを追加できます：

2.2 ゲームロジックの実行場所

ゲームロジックは主に2つの場所で実行されます：フロントエンドまたはサーバーサイドです。

フロントエンドにロジックを置くことは、クライアント－サーバー（Client-Server）構造に比べてアーキテクチャを簡素化します。この方法では、フロントエンドがゲームをシミュレートし、実行トレースを構築した後にゼロ知識証明（zk-proof）を生成します。その後、ローカルのzk-proverまたはリモート証明サービスを使ってZKVM向けのZK証明を生成し、それを基盤チェーンにアップロードして決済コントラクトをトリガーします。

一方、サーバーサイドにロジックを置くことは、ゲームシミュレーションとユーザーインタラクションを専用のコンポーネント（ゲームサーバー）に移転することを意味します。これにより、以下の点で全体的なゲーム体験が向上します：

同期性の高いゲームプレイ：サーバーサイドのシミュレーションにより、すべてのプレイヤーが可能な限り同期した形でゲームを体験できます。多人数プレイでは、接続されたすべてのクライアント上で一貫したゲームステートを持つことが、公平で競争的な体験にとって不可欠です。
リソース管理の最適化：フロントエンドはコンテンツのレンダリングとUI/UXに集中でき、サーバーは集中型の順序コントローラーおよびMerkle木の提供者として機能できます。

履歴データを必要とせず、順序ロジックが比較的単純な単人PVEゲーム（または多人数PVPゲーム）では、すべてをフロントエンドに置くのが良い選択です。一方、多人数SLG（シミュレーションゲーム）やAW（Autonomous World）のような複雑なゲームでは、サーバーサイドの方が性能が優れます。

2.3 ゲーム開発アーキテクチャの選択

伝統的なゲーム開発とZKVMを統合するため、ツール選択を慎重に行う必要があります。

1. 開発言語

まず、C#、Rust、C、C++、Goといった従来のプログラミング言語を使用するか、ZKVM専用の言語を使用するかを決定する必要があります。

従来の言語のバックエンドバイトコードは通常MIPS、WASM、RISC-V、x86です。多くのZKVMがこれらを直接サポートしていないため、プログラムがRISC-Vバイトコードにコンパイルできる場合はRisc0を、WASMにコンパイルできる場合はzkWASMを基盤ZKVMとして選択できます。

WebAssembly（WASM）は、C、C++、Rustなどの高級言語のコンパイル先となる低レベルバイトコード形式です。ネットワーク上でほぼネイティブ速度でコードを実行することを目的としています。WebAssemblyは、Webアプリケーションのセキュリティや速度を犠牲にせずに、Webブラウザ上でパフォーマンスが重要なコードを実行する手段を提供します。JavaScript以外の言語を活用できる点で、現代のWeb技術スタックの重要な一部です。

2. ゲームエンジン

プログラミング言語を選んだ後、その言語に基づいたゲームエンジンを選択できます。ZKVM専用言語を選んだ場合、成熟したフレームワークが存在しない可能性があるため、独自のゲーム開発フレームワークを作成する必要があるかもしれません。一方、Rust、C、TypeScriptなどの言語では多数の選択肢があり、特にUnityやCocos2Dを推奨します。

3. 証明生成コスト

通常、証明コストは100万命令あたりの証明時間で測定されます。したがって、これはゲームプレイの実行トレース（各インタラクションの命令数）、バックエンドバイトコードの長さ、およびZKVMの証明性能に依存します。単純な命令セットの場合、数秒で100万命令の証明を生成できるZKVMもあります（Miden）。複雑な命令セット（RISCV 32bit、WASM 64bit）では、GPU使用時で12秒（Risc0）～約30秒（zkWASM）程度かかります。

3. ZKWASMにおけるフルチェーンゲームのMVC（Model-View-Controller）パターン

3.1 MVC（Model-View-Controller）パターンの概要

MVC（Model-View-Controller）パターンは通常Web／企業アプリ開発に関連付けられますが、ゲーム開発にも応用可能です（ただし調整が必要です）。以下にMVCコンポーネントがゲーム開発でどのように機能するかを説明します：

モデル（Model）：

ゲーム開発におけるモデルは、ゲームのデータとロジックを表します。これにはゲームステート（スコア、レベル、プレイヤーステータスなど）、ゲームオブジェクト、ゲーム世界を管理するルールが含まれます。モデルはゲームのデータとステートを管理し、通常はそれらがどのように表示されるかを知りません。

ビュー（View）：

ビューは、ゲームステートをプレイヤーに提示する役割を担います。ゲームグラフィックスのレンダリング、サウンド再生、スコア、ライフバー、メニューなどのUI要素表示が含まれます。ビューはモデルを監視し、ゲーム世界の視覚的・聴覚的表現を更新します。多くのゲームエンジンでは、ビューはレンダリングエンジンやUIシステムにカプセル化されています。

コントローラー（Controller）：

コントローラーは、キーボード、マウス、ゲームパッドなどの入力デバイスからのユーザー入力を解釈し、ゲーム内のアクションに変換します。例えば、ジャンプボタンを押すと、コントローラーがその入力を処理し、モデルにアクションを伝えます。ゲーム内では、コントローラーは入力デバイスとゲームロジックの中継役を果たします。

ゲーム開発におけるMVCの利点：

関心の分離：MVCはコードを整理し、ゲームロジックとUIを分離できるため、開発が容易になり、メンテナンス性が向上します。
柔軟性：同じモデルに対して異なるビューを作成できます。複数の視点や、さまざまな表示モードをサポートするゲームに有用です。
ZK対応性：ゲームロジックと表示を分離することで、モデルだけが信頼不要に実行される部分になります。モデルをZKWASM内に配置すれば、コアゲームメカニズムが自然に証明されます。

3.2 ZKWASMにおけるゲームエンジンの設定

コントローラーがモデルに接続され、一連のハンドラーを持っていると仮定します。次に、コントローラーとハンドラーにコマンドのエンコード／デコード層を追加できます：

3.3 ゲームプレイ証明の生成

ゲームプレイの一部を、一連のハンドラー呼び出しと見なすことができます。したがって、信頼不要なZK証明は以下のコードで表されます：

fn execution(cs: Vec<command>) {

for command in cs {

global_state = handler(command);

}

ゲーム中では、コントローラーが送信する最後のコマンドを特定するのは難しく、すべてのコマンド処理を単一のZK証明に含めることも困難です。そのため、コマンドを複数のセグメントに分割して個別に証明し、その後バッチ処理して単一の証明を生成し、オンチェーンで検証するのが最適な手法です。

注：上記の方法には以下の2つの未解決課題があります：

各実行セグメント間のステート連続性をどう保証するか
異なるゲームクライアントからのコントローラーが干渉する場合、多人数同時シーンをどう処理するか

次の章では、多人数シーケンシング（sequencing）とデータ可用性（DA）について簡単に紹介します。各テーマは深掘り可能ですが、詳細は別の資料で提供する予定です。

4. 多人数ゲームにおけるユーザーインタラクションのシーケンシング

モジュラー型ブロックチェーンの文脈では、シーケンサー（sequencer）は、インタラクションが最終確定される前にその順序を決定するコンポーネントまたはノードです。モジュラー型ブロックチェーンアーキテクチャは、ブロックチェーン機能の異なるレイヤー（実行、コンセンサス、データ可用性など）を別々のコンポーネントに分割します。このアプローチは、各レイヤーが独立して最適化されることで、スケーラビリティ、セキュリティ、効率性を向上させることを目的としています。

多人数ゲームを開発する際も、異なるユーザー間のインタラクションを順序付けるコンポーネントが必要です。そこで、モジュラー型ブロックチェーンの「シーケンシング」という用語を再利用します。

ゲームには低遅延が求められるため、迅速な順序付け結果を出す集中型シーケンサーを選ぶのが望ましいです。ゲームエンジンはシーケンサーと密接に連携し、順序付けられたトランザクションを取得できます。