ブロックチェーンゲーム共通基盤について -序章-

2024年12月14日公開 2024年12月17日更新

はじめに

これはドリコム Advent Calendar 2024 の14日目です。

自己紹介

お久しぶり、エンジニアの小川です。
三年ぶりのアドカレです。
お手柔らかにお願いいたします。

本題へ入る前に少々自分語りを。
弊社は2022年に Web3 事業への参入を発表しました。
その前後から私は Crypto 部という Web3 事業を推進する部署の所属になり、現在に至るまで Web3 関連のエンジニアリングを行っております。
主な参加プロダクトの1つとして、今年3月正式リリースしましたブロックチェーンゲーム『Eternal Crypt – Wizardry BC –』があります。

『Eternal Crypt – Wizardry BC –』について

本ゲームはブロックチェーンゲームという名の通り、ブロックチェーン上のデータを取り扱うゲームです。
BloodCrystal という仮想通貨や、本ゲーム専用の NFT が対象のデータとなります。

BloodCrystal はゲーム内では通貨として利用する事ができ、ブロックチェーン上では ERC-20 仮想通貨として取り扱われます。
今年10月16日、国内取引所に上場し、今月18日には国内販売所での取引開始を予定しております。

また、キャラクターや一部アイテムは NFT として所有する事が可能です。
NFT の二次流通マーケットである OpenSea にてゲームのキャラクターが出品されていたり、それぞれの売買履歴を確認したりなどが可能です。

ブロックチェーン上にある BloodCrystal や NFT をユーザーがゲーム内にインポートすると、手続きを経てゲーム内でそれらが利用可能になります。
逆に、ゲーム内で稼いだりゲットした BloodCrystal あるいは NFT をゲーム内からエクスポートし、手続きを経てブロックチェーン上のデータとする事も可能です。
ブロックチェーン上のデータは当然ブロックチェーンで管理されますが、インポートされた BloodCrystal や NFT はゲームサーバ上での管理に切り替わるため、「ブロックチェーン上のデータ即ちオンチェーンデータ」と「ゲームサーバ上のデータ即ちオフチェーンデータ」の接続が必要となります。

オンチェーンデータとオフチェーンデータの接続について

まず、ブロックチェーン上のデータは「トランザクション」によって変更されていきます。
トランザクションとは「アカウントから暗号的に署名された命令のことを意味する」との事です。
では命令とは何ぞやという話ですが私の言葉で表すと、「ブロックチェーン上のデータを変更する」ためのアクションが命令すなわちトランザクションです。
「AさんがBさんに100円送る」行為はAさんとBさんの持ち金が変わるのでトランザクションの作成/送信が必要となります。
「Aさんが今いくら持ってるのか確認する」行為はデータが変化しないのでトランザクション不要です。
ブロックチェーンに送られたトランザクションはマイナーやバリデーターの精査を経て、承認されると新しいブロックに積まれます。
そしてそのブロックが直近のブロックに繋がってチェーン上になっていくわけですが、ブロックはトランザクションの塊なので、ブロックが繋がるたび何かしらのデータが変わっているという事になります。
※「AさんがBさんに0円送る」みたいに何もデータを変更しないトランザクションを送信する事も可能ではありますが、特殊な事例です。

本記事における「オンチェーンデータとオフチェーンデータの接続」とは、時間と共にどんどん繋がっていくブロック、が所有しているトランザクションのうち『Eternal Crypt – Wizardry BC -』で取り扱うデータを変更するトランザクションのみを監視し、その成否によってオフチェーンデータを変更する行為を指します。

ブロックチェーンゲーム共通基盤について

ゲームの設計時、この接続処理をゲームのコアロジックから可能な限り遠くへ引き剥がしゲーム側の開発/運用負担を減らそう、という判断を下しました。
また「オンチェーンデータを監視してオフチェーンデータを管理する」機能はブロックチェーンゲーム全般で必要とされる、つまりこの機能を汎用化すれば他のブロックチェーンゲーム開発時に役立つだろうという予見があり、共通基盤として設計/実装する事となります。
こうして我々のチームはブロックチェーンゲーム共通基盤の開発を始め、その開発/運用が現在まで至る私のミッションとなりました。

ゲーム側では

ユーザーアクションにより仮想通貨または NFT のインポート/エクスポートを開始するようブロックチェーンゲーム共通基盤に要請する。
要請したインポート/エクスポートの完了を受け取ったら、それに従いゲームサーバ側のデータを変更する。

というフローが基本となります。
これは Apple や Google のアプリ内課金を参考としたフローなので、アプリ内課金を実装した経験のあるエンジニアであれば問題無くブロックチェーンゲーム共通基盤を組み込めるようにしています。

ブロックチェーンゲーム共通基盤ではインポート/エクスポートの要請から完了までの細かな面倒を見ており、 Web3 に関する処理はブロックチェーンゲーム共通基盤に集約されています。
つまり Web3 に関する処理を実装しやすい開発環境が求められました。
使用するミドルウェア等も含めて勘案した結果 TypeScript を言語として利用する Web フレームワークが良いと判断し、当時よく耳にしていた NestJS を採用しました。
NestJS は Express や Fastify のような既存の Node.js Web フレームワークを更に抽象化した Web フレームワークで、 TypeScript を標準サポートしており、ドキュメントも充実しています。

またブロックチェーンゲーム共通基盤では仮想通貨や NFT の管理を行うスマートコントラクトともやり取りする必要があり、そのためにはスマートコントラクトのコンパイル成果物が必要だったのでスマートコントラクトの開発環境も必要となりました。
こちらは当時から慣れ親しんでいた Hardhat を採用しています。
Hardhat はスマートコントラクトの開発に Solidity という言語を使用しますが、それ以外のスクリプトファイルやテストファイルには TypeScript を用いているので、開発環境のほぼ全てが TypeScript に集約されました。