---
title: "ガス最適化トランザクションによるSmurfs' Societyのスケーリング"
description: "Smurfs' Societyは、ガス価格が大きく変動する期間においてPolygon上でのトランザクションのマイニングを保証するため、Alchemyのガス最適化トランザクションを使用しました。"
---
## Alchemyとのパートナーシップでオンチェーン取引をスケールする
**著者：** **The Smurfs' Society Team**
[The Smurfs' Society](https://thesmurfssociety.com/)は、Smurfsの公式web3プロジェクトである。このプロジェクトは招待制で完全オンチェーンのゲーミフィケーションプラットフォームであり、2022年12月にローンチし、1ヶ月足らずで30,000以上のウォレット接続と150万件のオンチェーン転送を生み出し、DappRadarによる最も利用されているアプリTOP 100の一角に入った。
この記事では、同社のCTO兼共同創業者が、大量のオンチェーン取引をスケールする上での技術的課題と、数万人のプレイヤーに滑らかで一貫したユーザー体験を届けるために、[Transact APIスイート](https://www.alchemy.com/transact)を使ってAlchemyとどのように協業しているかを取り上げる。
## **ブロックチェーンの文脈における「スケーラビリティ」の相対性**
毎分100件の取引を「スケール」問題や大量処理の問題と捉える人はほとんどいないだろう。私自身もそうだ。以前、私は複数のデータセンターにまたがるCassandraクラスタの最適化に多くの企業と協業してきた。TB単位のデータ量、低レイテンシ、高スループットの世界だ。当時は、ブロックチェーンインフラを扱う際にこれほど少ない取引量の実現が難しいとは想像もしていなかった。
課題は二つに分かれる。
1. 取引を物理的に実行できる必要がある
1. [取引の正しさを保証する](https://alchemy.com/blog/data-accuracy)必要がある。より正確には、その取引の最終的なデータ整合性と正確性を保証する必要がある。
一つ目の課題への対応は、k8s上にオートスケーリング機能を備えてデプロイされた他のプラットフォームクラスタのサイジングとほぼ同じである。一つ異なる点は、負荷を分散する方法として、StatefulSet内でHDウォレットを使い、各Podに独自のウォレットを直接管理させたことだ。また、ブロックチェーンでは取引を（特定の順序ウォレットについて）順番通りに実行することが求められる点にも注意が必要だ。
二つ目の課題については、[mempool内の取引](https://www.alchemy.com/overviews/transaction-propagation)がマイニングされない（ガス代の問題）状況を想像してほしい。
**選択肢は以下の通りだ：**
1. ネットワークが落ち着くのを待ち（可能であれば）、取引がマイニングされるのを待つ
1. 新しい取引で上書きする（nonceを強制し）、ガス設定を引き上げる
1. 単純に別のウォレットを使う
私たちのケースでは、選択肢1でも選択肢3でもあり得ない。したがって選択肢2しかなく、それ自体が複雑さを生むことになった。
以下は、Alchemyとの協業を通じて[Reinforced Transactions](https://www.alchemy.com/docs/reference/mev-protection)から[Gas Optimized Transactions](https://www.alchemy.com/docs/reference/mev-protection)へ移行した経験の概要である。
### **正確性を最大化しながら1日20,000件の取引をマイニングする**
ブロックチェーンをバックボーンとして多用するアプリケーションやゲームをスケールすることが、なぜこれほど難しいのか。
- 1つのブロックでマイニングできる取引数に制限されているのか？
- ネットワーク全体のキャパシティに制限されているのか？
- ネットワークの混雑や日中特有の利用パターンに制限されているのか？
- ブロックチェーン上での取引の実行方法に制限されているのか？
- ガス代のボラティリティに制限されているのか？
数週間の運用と、すべての制御機構への繰り返しのイテレーションを経て、現在私たちはゲームを最適な条件で稼働させるプラットフォームを持つに至った。
ここに至るまでに乗り越えなければならなかった障壁を説明する前に、ゲームの仕組みを紹介し、ブロックチェーンの観点から自動化しているアクションとその課題の概要を説明する。その後、Alchemyとの協業によってこれらの問題をどのように解決したかを説明する。
## **Smurfsのオンチェーンゲームはどう動くのか**
現時点でのゲームは、通常の「待機リスト」という概念を覆すもので、プレイヤーは素材を組み合わせてレシピを見つけ、ポーションを作ろうとする。そのポーションの一部はクリスタル（割引付きの確約ミントアクセス）へのアクセスを付与する。
ゲーム内で使用するすべてのアセットはNFTとして表現される。これらは、ファンジブルかつ消費可能とみなすアイテム（素材、ポーション、ブルークレイ、彫像など）についてはERC-1155トークン、ファンジブルでないアイテム（クリスタルなど）についてはERC-721トークンとなっている。
### Smurfsゲームでのインタラクション
以下は、ゲームを動かすために私たちのプラットフォームがPolygonネットワークと行うインタラクションである。
1. **素材で構成されたドロップボックスの受け取り** - プレイヤーは毎日3つの素材が入ったボックスを受け取るよう促される
1. **彫像のミント（ゲームの中心コンポーネント）** - すべてのプレイヤーはゲーム内のアクションを完了するために1体所持する必要がある。彫像はプレイヤーがゲームにログインすると無料で付与される。彫像の役割については、ゲームの後半で発表される予定だ。
1. **クレイのバーン** - レシピに挑戦したプレイヤーが失敗した場合、ブルークレイが1個バーンされる
一方、プレイヤーはPolygonネットワーク上で1つの操作のみを行う。
1. **レシピのミックス** - プレイヤーは3つの素材を組み合わせてレシピを作るよう促される（この場合、ガス代を支払うのはプレイヤー自身である）。
最初の2つの機能については、試行した取引が長時間マイニングされなかったとしても、ゲームへの実質的な影響なく、完全に非同期な方式で動作させることができる。もちろん体験の観点からは、この時間をできるだけ短くしたいというのが私たちの希望だ。
クレイのバーンはもう少し難しく、実装上の選択はゲーム自体の仕様に大きく左右された。プレイヤーが実際にレシピを提案するとき、プレイヤーはミックスに使いたいすべての素材を含むEIP-712構造体に署名する。以下に示すように、3時間の期限付きだ。
この署名は、関連するミックスでレシピが見つからなかった場合のバーン許可として使われる。そして、私たちはプレイヤーに代わってこのburnClay取引を実行し、それに伴う取引手数料を負担する。
**ここから、複数の状態を管理する必要がある：**
1. 取引が移送中の状態 - オフチェーンに保存 -\> オンチェーンへ移行中。突合のために使用する。
1. 取引がmempool内にあり、マイニングされるのを待っている状態 - この遷移状態では、ユーザーが保有していると想定しているものと、実際に処理されているものとを突合する必要がある - しかもどれだけ時間がかかるかの保証はない
1. 取引がマイニングされた状態 - 画面に表示されているブルークレイの数量がこの時点で正確になる。この状態が最終状態であり、課題は生じない - ブロックチェーンが信頼できる情報源だからだ
1. 取引はマイニングされたが、中止扱いとされる状態
### Smurfsチームが Polygon を選んだ理由
理想的には、操作の正確性とゲーム体験を保証するために、すべての状態が1分以内に収束することを期待する。このユースケースについては、ゲーミフィケーションフェーズにはPolygonネットワークを使うことにした。以下は、[Polygonをネットワークとして選ぶ](https://www.alchemy.com/polygon)際に重視した基準の一部である。
- 反応性のための高速なファイナリティ時間
- 運用コスト管理のための取引手数料の低さ
- 長期的なビジョンのためのEthereumとの相互運用性
**私たちの課題：整合性を最大化しながら1日20,000件の取引をマイニングする**
## **高い成功率を維持しながらPolygonのガス変動の影響を抑える**
Polygonは混雑することがあり、それが先に述べた各種アクションに遅延を加えることで私たちに直接影響を及ぼす。これに対処するための基本的な手段がいくつかある。
1. **シャーディング** - 複数のウォレットでブロックチェーンとやり取りする。稼働中のウォレットがある限り（DBのコネクションプールに似ている）、取引を処理できる。
1. **強気の価格設定** - 取引が確実に時間内に処理されるよう、[優先手数料（EIP-1559）](https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum)へのインセンティブを引き上げることができる。
私たちの初期のセットアップは、[**Reinforced transaction**](https://www.alchemy.com/docs/reference/mev-protection)ソリューションを使い、取引のファイナライズ時間を最適化するためにガス代について市場価格より強気の値付けをするというものだった。
この2枚のスクリーンショットは数分間隔（約5分）で撮影されたものだ。非常に短い時間枠でガス代が大きく変動していることが分かるが、これは私たちに直接影響する。ガス価格の市場ボラティリティが急上昇すれば、私たちの取引はそこで詰まり、ウォレットの1つをブロックしてしまうのだ。
### ガス代が変動する期間にPolygonの取引を最適化する方法
ガス代が変動する期間の取引最適化に向けて、以下に取り組み始めた。
- アプリケーションにレジリエンスを追加し、取引の状態をより長い期間にわたって正確に追跡する
- 兆候が現れたときに追跡し、アラートを出す - メッセージが処理されるまでの時間を追跡することでこれを実現した
**ミクロで見てすべてが順調に見えるとき、こうなる：**
**そしてマクロレベルで見ると、事態はさらに興味深いものになる：**
まれに、メッセージの滞留時間が200秒近くに達することもあった（上記の例は最も厳しかった日の一つのものだ）。このギャップが大きくなりすぎると、プレイヤーがそれに気づき始める。最も分かりやすい兆候は、ブルークレイのカウンターが減らないことだ。
最悪の日には、Polygonのアップグレード後、一部の取引がマイニングされなかったため、ゲームを30分間停止せざるを得なかった。
それ以来、私たちはAlchemyと積極的に協業し、彼らの新しい提供機能の1つでこの課題に取り組んでいる。私たちは[**Gas Optimized transactions**](https://www.alchemy.com/docs/reference/mev-protection)のベータに参加することにした。
**Gas Optimized transactionsが約束するのは、予測不能な外れ値の管理だ。**
ガス代を決めるハードコードされたロジックで単一の取引に署名する代わりに、異なるガス価格条件の5つや10つの取引に署名し、nonceの価格を自動的にエスカレートさせる作業をAlchemyに任せられるとしたらどうだろうか。
私たちのケースでは、以下のエスカレーションポリシーを採用することにした：1.25、1.5、1.75、2、2.25、2.5
これまでのところ、良い結果を得ている。
すでに複数の最適化を実行し、システム上で実際に稼働しているのを確認している。Alchemyチームとの協業を今後も続けていくことを楽しみにしている。特に、問題が起きた日の迅速な対応と素早い折り返しの対応には個人的に感謝したい。正しいパートナーを選ぶことがすべてだ！
Smurfily（スマーフらしく）、
The Smurfs' Society team