Web3ゲームのゲーム内経済バックエンドを低コストで回す
Web3ゲームのゲーム内経済では、プレイヤーの在庫表示、ゲーム内アクションのオンチェーン処理、アイテムの法定通貨換算での値付けを、ゲームループの高頻度なpollingに耐えるコストで回す必要があります。ここでは、balancesとdecoded logsによる在庫表示、mint/取引/報酬のbuild/sign/broadcast、spot価格でのfiat換算値付けを、1本のkeyの上に組み立て、credit消費を低く保つ構成を示します。
課題
ゲーム内アイテムはコントラクトごとにイベントの構造が異なり、在庫を正確に表示するにはABIを保守し続ける負担が生じがちです。また、mint・取引・報酬付与といったアクションをオンチェーンに反映するたびにトランザクションを組み立てる処理も必要になります。さらにやっかいなのがコストです。ゲームループは表示のために高頻度でpollingするため、価格や残高の読み取りを素朴に実装すると、リクエスト量に比例してコストが膨らみます。
- Balances / portfolio / net-worthC2
- Decoded transactions / logsC2
- Build / sign / broadcastC2
- Spot / OHLCVC1
balancesとdecoded logsで在庫をABI保守なしに表示する
プレイヤーの在庫は、balancesとdecoded logsを組み合わせて表示します。ログがデコード済みで得られるため、コントラクトごとのABIを自前で保守し続ける必要がありません。新しいアイテムコントラクトを追加しても、在庫表示側のデコード実装を都度書き足さずに済み、運用の負担が一定に保たれます。
ゲーム内アクションをbuild/sign/broadcastで反映する
mint・取引・報酬付与といったゲーム内アクションは、build/sign/broadcastの流れでオンチェーンに反映します。署名はクライアント側に残るため、keyがプレイヤーの秘密鍵を預かることはありません。トランザクション組み立ての定型処理を共通化でき、アクションごとに個別のRPC実装を積み上げずに済みます。
spot価格をキャッシュして高頻度pollingのコストを抑える
アイテムのfiat換算値付けにはspot価格を使います。spotは最も安いtierで、表示間隔ごとにキャッシュする前提で扱えるため、ゲームループが高頻度でpollingしてもcredit消費を低く保てます。多数の同時接続プレイヤーに価格を配信する場面でもコストが跳ね上がりにくい構成です。
この構成が提供するもの
- balancesとdecoded logsで在庫を表示し、コントラクトごとのABI保守から解放される。
- mint/取引/報酬をbuild/sign/broadcastで反映しつつ、署名はクライアント側に残る。
- spot価格を表示間隔ごとにキャッシュし、高頻度pollingでもcredit消費を低く抑えられる。
よくある質問
アイテムのコントラクトが増えるたびにABIを保守する必要がありますか。
decoded logsを使うため、ログはデコード済みで取得できます。在庫表示のためにコントラクトごとのABIを自前で保守し続ける必要はなく、アイテムを追加しても表示側の実装負担が増えにくい構成です。
ゲームループで頻繁に価格を取得するとcreditを使い切りませんか。
spotは最安tierで、表示間隔ごとにキャッシュする前提で扱えます。高頻度のpollingでも読み取り回数に対してcredit消費を低く抑えられるよう設計できます。
チャージして、キーを取得し、リリース。
セルフサーブ。暗号資産またはカードで支払い。クレジットで従量課金——重いプリミティブは高く、単純なものは安価。
APIキーを取得