STYLYとNFT
もう去年の話になりますが、2022年10月15日にSTYLYではNFT関連の機能が実装され、OpenSeaを介して、XR作品の取引が出来るようになりました。
現在、NFTとして出品する機能は提供されていませんが、MetaMaskと連携を行い、Ethereumのwalletと連携する機能があります。これによりSTYLYのXR作品のNFTのコレクションを表示できます。
STYLYではこのような機能に関しても自動テストを書いています。ネット上にはあまり知見が書かれていない内容なので、これを紹介したいと思います。
MetaMaskをどのようにシミュレートするか?
特に説明なく話していましたが、MetaMaskについて説明します。
Chromeプラグインの説明によると、
ブラウザにあるイーサリアムウォレット
EthereumのID管理プラグイン MetaMaskは、Ethereumを用いる分散型アプリケーション(DApps)にアクセスしやすくするためのプラグインです。あらゆるウェブサイトのJavascript のコンテキストに対して、EthereumのWeb3 APIを提供し、 それによって分散型アプリがブロックチェーンのデータをブラウザから読むことができるようになります。
とあり、AndroidやiPhone用アプリもあります。いわゆるウォレットと呼ばれる、Ethereumという仮想通貨を入れておく財布アプリのようなものです。
今回、自動テストをすることを考えると、このMetamaskが行っているwallet登録と同じ動作をする必要があります。そこで、ナイーブに考えるとすると、
- 自動テスト内でChromeを立ち上げる
- ChromeにMetamask用のプラグインを導入する
- Metamaskにテスト用のwallet情報(秘密鍵など)を登録する
- Chromeを操作し、Galleryに対し、walletの登録作業を行う。
というフローになります。おそらく多くの方が考えているとおり、うまくいかないでしょう。
まず今回テストしたいのは、"wallet登録のAPI"です。そのようなサーバーサイドのAPIのテストに対し、このためだけに、Chromeをインストールし実行するのは非常にコスト高です。また、4.ではGalleryを操作しているので、APIサーバーに加えて、フロントエンド側のサーバーも建てる必要があります。最近では、Playwrightなど、E2Eテストの環境は整ってきましたが、個人的にはまだ動作が不安定な印象があります。そこに、加えてChromeプラグインをインストール、セットアップするのはとても大変だと思われます。
このように、wallet登録のAPIテストを行うにあたって、Chromeを実行し、Metamaskのプラグインをインストールし自動テストを実行するのは、現実的ではないと分かります。
wallet登録とは何をしているのか?
前節では、MetaMaskのChromeプラグインを自動テスト内で動かすのは現実的ではない。という話を書きました。それを受けて、では、そもそもwallet登録とは何をしているのか?という話になります。
STYLYのwallet登録はおおむね以下のようなフローとなっています。
ある署名用のデータを用意し、それをMetamaskに対し、データの署名を求めます。これはmetamaskのpersonal_signという機能を使って実現できます。そうすることでMetamaskから署名データが返却されます。ブラウザでは、このデータと署名データをAPIへ送ります。API側では、データと署名データの組から、署名に利用したwalletアドレスを抽出します。これは、web3.jsであれば、web3.eth.accounts.recoverやethers.jsであれば、ethers.utils.verifyMessageで実装可能です。そして、最後に抽出したwalletアドレスをDBへ保存する。というフローになります。
とどのつまり、
- ethereum walletを作成
- ethereum walletで署名する
ということが出来れば、MetaMaskと似た動作をシミュレーションすることが可能であると考えられます。
PHPとWeb3の現状
STYLYのAPIはPHPで実装されています。そのため、Ethereum周りのテストをするにおいても、PHPで利用できるライブラリがある方が嬉しいです。しかし、Ethereumのエコシステムはjavascript周りが強く、web3.jsやethers.jsなどの方が有名です。もう1年ほど前の記憶なので、このあたりの記憶が曖昧なのですが、PHPで利用できるライブラリは
の3種ぐらいしか見当たりませんでした。ethereum-phpは最終更新が2021年11月と少し古く、web3、web3.phpはどれもドキュメントが少なく動作が判然せず、学習コストが高そうである。という問題がありました。そのため、 PHPのネイティブでEthereum周りの機能を利用するのはかなり難易度が高そうである。 という認識になりました。
gethとの連携
今回、スマートコントラクトやweb3の周りをやるにあたって、自分の蔵書を読み直しました。
スマートコントラクト本格入門―FinTechとブロックチェーンが作り出す近未来がわかる
はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門
以上の2冊を読みましたが、かなり古めの本です。というのも、2017年頃にスマートコントラクト周りに興味があり、本を買ったまま読まずに積んでいた本になります。これらを読んでいると、概ねgethというGo言語で実装されたEthereum系のツールを使っていました。そのため、このgeth周りにヒントは無いか?と思い、調査を開始しました。
gethのJSON-RPC server
gethのドキュメントをよく読んでいくと、JSON-RPC Sreverというセクションが見つかります。これは、特定のjsonをREST APIを通じてリクエストすることでgethの機能を利用することが出来ます。
その中に、personal Namespaceという章があります。この機能を利用すると、REST APIを通じて、Walletの作成や、署名というものが可能になります。(ただ、そろそろdeprecatedのようですが・・・)
このJSON-RPC機能はデフォルトではオンになっていないため、自分でgethの起動オプションを調整してやる必要があります。STYLYの開発環境では以下の様な設定にしています。
geth --http --http.addr 0.0.0.0 --http.api personal,eth,debug --nodiscover --dev --http.vhosts '*'
例えば、Walletの作成は、persnal_newAccountを使います。パスワードを設定して呼び出し、返り値としてWalletのアドレスが手に入ります。
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method": "personal_newAccount", "params": ["password"],"id":1111}' localhost:8550 -v
署名に関しては、personal_signを用いて、署名したいデータ(message)、アカウントのアドレス、パスワードを指定して呼び出し、署名が返ってきます。
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method": "personal_sign", "params": ["message","account","password"],"id":1111}' localhost:8550 -v
このようにREST API経由でgethのwallet作成機能、署名が利用できます。これであれば、PHP側から機能の利用が可能となります。
PHPとgethのテストプロセスでの融合
これまでの内容で、REST APIでgethの機能が呼び出すことが可能になりました。PHPではGuzzleなどのHTTPリクエストが出来るライブラリを用いて、リクエストすればよいことが分かります。しかし、新たな問題があります。それは、テスト実行前にgethをhttpサーバーとして立ち上げる必要があります。また、CIにおいてgethをどのようにインストールするのか?という問題もあります。STYLYではどのようにこの辺りを解決しているか。というとdocker composeです。以前の記事にも書きましたが、STYLYのAPIの開発環境では、docker composeで複数のコンテナを起動しています。そして、gethは公式のDockerイメージが公開されています。
なぜgethを選んだのか。というとこのあたりのDocker周りのエコシステムも整備されているので、既存のSTYLYとの技術スタックとの相性も良く、CIで安定的にテストが実行できています。
gethのバグ?
しかし、gethに絶妙なバグ?があって、STYLYで使っているテスト用の署名の関数は以下の様になっています。
public function sign(string $message, string $account, string $password): string
{
usleep(100000);
return $this->callJsonRpc("personal_sign", [$message, $account, $password]);
}
このように微妙に0.1秒待つような実装になっています。
これはどういうことか。というと、データを署名したいとき、まず初めに、gethに対してpersonal_newAccountを用いて、walletの作成を依頼します。その返り値からwalletのアドレスを取り出し、今度は、personal_signを用いて、署名を依頼します。そうすると、walletが存在しない旨のエラーメッセージが発生しました。
これは予測でしかないのですが、gethのwallet情報はDBではなく、ただのファイルに書いているようです。そのため、高速にリクエストすると、ファイルシステムの反映が追い付かず、署名の時にwallet情報が無い扱いになってしまってエラーになっているようでした。したがって、0.1秒スリープを入れることで、ファイルシステムへの反映を十分に待って、リクエストをするようにしていました。 最新のgethだと発生しないかもしれませんが、少なくとも私が実装していた2022年10月ごろ(v1.10系)にはそういったバグが発生していました。
おそらくですが、こういう風なテストの用途で高速にリクエストをするユーザーが少なかったがために見落とされてたのではないかなーと思います。
「うちのシステムは特殊だから」を言い訳にしない。
このNFT関連のシステムは非常にハードでした。はっきりと言えば門外漢の分野であり、そのテストに関連うする知見はほぼ世の中に無いようなシステムです。そんなシステムをどうやってテストすればよいのか?というのは、課題でした。
MetaMaskでどのようにログインを実装するか。と言ったことは、チュートリアルなどもあり、比較的難易度の低い内容ではあります。しかし、その中身がどうなっているのか。というところは、さらに深く実装を知る必要があり、またその内容をどのように自動テストに組み込むか。というのは、かなり難易度の高い実装となるでしょう。
「うちのシステムは特殊だから自動テスト出来ない」
と思いがちですが、なんとか頭をひねればなんとかなるものです。こんなに特殊なシステムでもなんとかなるものなので、思考停止せず自動テストに取り組むと良いと思います。
宣伝
PsychicVRLabではUnityエンジニア・サーバーサイドエンジニアを募集しています!!ご応募お待ちしています!!