ガス最適化トランザクションによるSmurfs' Societyのスケーリング

Alchemyとのパートナーシップでオンチェーン取引をスケールする

著者： The Smurfs' Society Team

The Smurfs' Societyは、Smurfsの公式web3プロジェクトである。このプロジェクトは招待制で完全オンチェーンのゲーミフィケーションプラットフォームであり、2022年12月にローンチし、1ヶ月足らずで30,000以上のウォレット接続と150万件のオンチェーン転送を生み出し、DappRadarによる最も利用されているアプリTOP 100の一角に入った。

この記事では、同社のCTO兼共同創業者が、大量のオンチェーン取引をスケールする上での技術的課題と、数万人のプレイヤーに滑らかで一貫したユーザー体験を届けるために、Transact APIスイートを使ってAlchemyとどのように協業しているかを取り上げる。

ブロックチェーンの文脈における「スケーラビリティ」の相対性

毎分100件の取引を「スケール」問題や大量処理の問題と捉える人はほとんどいないだろう。私自身もそうだ。以前、私は複数のデータセンターにまたがるCassandraクラスタの最適化に多くの企業と協業してきた。TB単位のデータ量、低レイテンシ、高スループットの世界だ。当時は、ブロックチェーンインフラを扱う際にこれほど少ない取引量の実現が難しいとは想像もしていなかった。

課題は二つに分かれる。

取引を物理的に実行できる必要がある
取引の正しさを保証する必要がある。より正確には、その取引の最終的なデータ整合性と正確性を保証する必要がある。

一つ目の課題への対応は、k8s上にオートスケーリング機能を備えてデプロイされた他のプラットフォームクラスタのサイジングとほぼ同じである。一つ異なる点は、負荷を分散する方法として、StatefulSet内でHDウォレットを使い、各Podに独自のウォレットを直接管理させたことだ。また、ブロックチェーンでは取引を（特定の順序ウォレットについて）順番通りに実行することが求められる点にも注意が必要だ。

二つ目の課題については、mempool内の取引がマイニングされない（ガス代の問題）状況を想像してほしい。

選択肢は以下の通りだ：

ネットワークが落ち着くのを待ち（可能であれば）、取引がマイニングされるのを待つ
新しい取引で上書きする（nonceを強制し）、ガス設定を引き上げる
単純に別のウォレットを使う

私たちのケースでは、選択肢1でも選択肢3でもあり得ない。したがって選択肢2しかなく、それ自体が複雑さを生むことになった。

以下は、Alchemyとの協業を通じてReinforced TransactionsからGas Optimized Transactionsへ移行した経験の概要である。

正確性を最大化しながら1日20,000件の取引をマイニングする

ブロックチェーンをバックボーンとして多用するアプリケーションやゲームをスケールすることが、なぜこれほど難しいのか。

1つのブロックでマイニングできる取引数に制限されているのか？
ネットワーク全体のキャパシティに制限されているのか？
ネットワークの混雑や日中特有の利用パターンに制限されているのか？
ブロックチェーン上での取引の実行方法に制限されているのか？
ガス代のボラティリティに制限されているのか？

数週間の運用と、すべての制御機構への繰り返しのイテレーションを経て、現在私たちはゲームを最適な条件で稼働させるプラットフォームを持つに至った。

ここに至るまでに乗り越えなければならなかった障壁を説明する前に、ゲームの仕組みを紹介し、ブロックチェーンの観点から自動化しているアクションとその課題の概要を説明する。その後、Alchemyとの協業によってこれらの問題をどのように解決したかを説明する。

Smurfsのオンチェーンゲームはどう動くのか

現時点でのゲームは、通常の「待機リスト」という概念を覆すもので、プレイヤーは素材を組み合わせてレシピを見つけ、ポーションを作ろうとする。そのポーションの一部はクリスタル（割引付きの確約ミントアクセス）へのアクセスを付与する。

ゲーム内で使用するすべてのアセットはNFTとして表現される。これらは、ファンジブルかつ消費可能とみなすアイテム（素材、ポーション、ブルークレイ、彫像など）についてはERC-1155トークン、ファンジブルでないアイテム（クリスタルなど）についてはERC-721トークンとなっている。

Smurfsゲームでのインタラクション

以下は、ゲームを動かすために私たちのプラットフォームがPolygonネットワークと行うインタラクションである。

素材で構成されたドロップボックスの受け取り - プレイヤーは毎日3つの素材が入ったボックスを受け取るよう促される
彫像のミント（ゲームの中心コンポーネント） - すべてのプレイヤーはゲーム内のアクションを完了するために1体所持する必要がある。彫像はプレイヤーがゲームにログインすると無料で付与される。彫像の役割については、ゲームの後半で発表される予定だ。
クレイのバーン - レシピに挑戦したプレイヤーが失敗した場合、ブルークレイが1個バーンされる

一方、プレイヤーはPolygonネットワーク上で1つの操作のみを行う。

レシピのミックス - プレイヤーは3つの素材を組み合わせてレシピを作るよう促される（この場合、ガス代を支払うのはプレイヤー自身である）。

3体のスマーフが材料を混ぜ合わせてレシピを作るSmurfs' Societyのゲーム画面 — 図1: プレイヤーがレシピを調合している様子

最初の2つの機能については、試行した取引が長時間マイニングされなかったとしても、ゲームへの実質的な影響なく、完全に非同期な方式で動作させることができる。もちろん体験の観点からは、この時間をできるだけ短くしたいというのが私たちの希望だ。

クレイのバーンはもう少し難しく、実装上の選択はゲーム自体の仕様に大きく左右された。プレイヤーが実際にレシピを提案するとき、プレイヤーはミックスに使いたいすべての素材を含むEIP-712構造体に署名する。以下に示すように、3時間の期限付きだ。

この署名は、関連するミックスでレシピが見つからなかった場合のバーン許可として使われる。そして、私たちはプレイヤーに代わってこのburnClay取引を実行し、それに伴う取引手数料を負担する。

ここから、複数の状態を管理する必要がある：

取引が移送中の状態 - オフチェーンに保存 -> オンチェーンへ移行中。突合のために使用する。
取引がmempool内にあり、マイニングされるのを待っている状態 - この遷移状態では、ユーザーが保有していると想定しているものと、実際に処理されているものとを突合する必要がある - しかもどれだけ時間がかかるかの保証はない
取引がマイニングされた状態 - 画面に表示されているブルークレイの数量がこの時点で正確になる。この状態が最終状態であり、課題は生じない - ブロックチェーンが信頼できる情報源だからだ
取引はマイニングされたが、中止扱いとされる状態

Smurfsチームが Polygon を選んだ理由

理想的には、操作の正確性とゲーム体験を保証するために、すべての状態が1分以内に収束することを期待する。このユースケースについては、ゲーミフィケーションフェーズにはPolygonネットワークを使うことにした。以下は、Polygonをネットワークとして選ぶ際に重視した基準の一部である。

反応性のための高速なファイナリティ時間
運用コスト管理のための取引手数料の低さ
長期的なビジョンのためのEthereumとの相互運用性

私たちの課題：整合性を最大化しながら1日20,000件の取引をマイニングする

Free video demo

Alchemyダッシュボードの実際の動作を見る

30分のガイド付きウォークスルー: ダッシュボードの全ツールをライブで実演

Watch the demo

高い成功率を維持しながらPolygonのガス変動の影響を抑える

Polygonは混雑することがあり、それが先に述べた各種アクションに遅延を加えることで私たちに直接影響を及ぼす。これに対処するための基本的な手段がいくつかある。

シャーディング - 複数のウォレットでブロックチェーンとやり取りする。稼働中のウォレットがある限り（DBのコネクションプールに似ている）、取引を処理できる。
強気の価格設定 - 取引が確実に時間内に処理されるよう、優先手数料（EIP-1559）へのインセンティブを引き上げることができる。

私たちの初期のセットアップは、Reinforced transactionソリューションを使い、取引のファイナライズ時間を最適化するためにガス代について市場価格より強気の値付けをするというものだった。