cocone engineering

こんにちは！CTO室のKです！
最近、暑くなったり寒くなったりと体調不良になりやすい時期ですが、みなさん気をつけてお過ごしください。

 

さて、本記事では2023年4月25日に行われました「cocone TECH TALK vol.6」にてお話しされたお三方の内容を、それぞれ前編・中編・後編の3つに分けてまとめてさせていただいております。

 

今回はその中の中編となります！
ブロックチェーンに関わる話とのことで、どんなものなのか気になるところです！

 

---

 

本日の発表内容

お伝えする範囲としては、

• 自社ブロックチェーン基盤と連携する、という世の中的に珍しい開発事例
• その説明のための前提意識など

があります。

 

また、以下は発表範囲外のものになります。

• ブロックチェーン基盤側の話
• トークンエコノミクス関連の運営の話
• 他、詳細な連携方法や通信仕様などセキュリティ担保に関わり得る内容

 

MOOI NetWorkとは

MOOI NetWorkとはklaytnという、ブロックチェーンのサービスチェーンとして作られた、メタバース用のブロックチェーンであり、MOOIというトークンを用いて取引を行います。

ココネとの関係

 

 

弊社グループの中には、ブロックチェーンの基盤開発や、実際のNFTのマーケットを運用している「POST VOYAGER」という組織があり、社内グループと連携して業務を行っています。
※Webサイトは大幅リニューアルされてしまっています。

ブロックチェーン連繋をするとはどういうことか

ブロックチェーン連携においてできることを大きく2つ挙げていきます。

(1)NFTを所有・発行

 

 

まず一つ目は、サービスでデジタルアイテムをNFTとして発行することができることです。
MintされたNFTはマーケットプレイス上でMOOIを用いて取引することができます。

 

(2)MOOIと交換可能なトークンをサービス内で発行

 

次に2つ目は、MOOIと交換可能なトークンをサービス内で発行できることです。
ゲーム内通貨は今までのゲームでもあったかと思いますが、それをさらに実際の経済まで交換可能にした通貨を発行できるようになりました。
それにより、トークンエコノミーと呼ばれる独自の経済圏が発生します。

 

 

スライドではMongoDBとブロックチェーンによる、アイテムの保持の違いを表しております。

 

従来のアイテムの保持はMongoDBを扱っており、連携時の様々なコストは低いのですが、データの破壊・改竄をある種の信頼で守っているのみでした。

 

しかし、ブロックチェーンによるアイテム保持は連携時のコストは高いものの、分散保存することによりデータの破壊・改竄を技術的に守ることができます。

実際の開発に求められること

自社のブロックチェーン連携開発の特徴

自社で運用しているブロックチェーンを連携開発するときの特徴として以下の3つがあります。

 

• 質問先が自社グループ内にある
• Walletを含めて自社で保有しているため、Controllableな部分が多い（機能開発要望などを行える）
• 「自社グループのブロックチェーン」という楽しさ

 

イーサリアムなどのパブリックチェーンとの連携と比較するとこれらは良い特徴と言えると思います。

サーバーサイドエンジニアが活躍する範囲

連携するにあたって元データとなるサービス内のデータがありますので、当然サーバーサイドの領域が深く関わります。いわゆる決済対応のような外部連携と似たようなもの、と考えて差し支えありません。

 

周辺知識も求められますが、外部連携はどんなシステムでも必要になっていきますので、その延長と考えてもらえれば困ることはありません。

ブロックチェーン連携の流れ

 

 

「Mint」では
サービス側 → ブロックチェーン側
「Burn」では
ブロックチェーン側 → サービス側
といった流れでアイテムのデータを連携しています。

 

この時の注意点としてNFT化できるアイテムは現実の資産へと連携されていくため、「想定以上にアイテムが発行されてしまう状況」を防ぐ必要があります。

 

根本的な設計はトークンエコノミクスで設計していきますが、エンジニアとしては不具合によって設計を崩さないように気を付ける必要があります。

対策の例

対策の例として3つほど挙げていきます。

(1)Transaction機能において

MongoDBのTransaction機能を使いました。この時に気を付けることとして、

 

• WriteConflictが起きないようなDocument設定にする
• 古いと利用できないバージョンもあるので注意

があります。

 

 

ここで、WriteConflictについて説明していきたいと思います。

 

更新対象がTransaction中の時はロックされます。この時、ロック中に同じDocumentに対してTransactionで処理しようとするとMongoDBでは5msでWriteConflictが起きます。

 

今回で言うと「バトル」や「ランキング」という要素が、人を跨いで共通のDocumentを同時に更新します。このような要素がある場合、負荷テストをする必要があります。

(2)Redisのような徹底的な排他的制御

基本的に同じ人が異なる操作を同時にしない設定想定にしておくと、問答無用で同時実行の制御を行えます。

 

そして、Redisはシングルスレッドであるため、この手の制御を行わせると強力に働かせることができます。

(3)ミューテーションテストによりテストのカバレッジをあげる

 

今回の要件において、外部連携でも複雑に通信が発生しています。
特にネットワークエラーなど結合テストなどでも確認が難しいものについて全てテストしておく必要があります。

 

そこで、スライドの図のように、エラーコードを全て発生させてユーザーと紐付け、このユーザーでアクセスすると必ずNFTのMinting通信のこの関数でエラーが起きる、という仕組みを作成しました。

まとめ

Web3との「連携する側」の場合、技術的に必要度合いが高いのは、従来の外部連携開発としてのサーバーサイドの経験です。
また、自社グループにWeb3の組織があると知識部分も自然と埋められるのがよい点です。

 

開発において、Web3の最新の知識を仲間と連携してチャレンジできるのはとても楽しかったです。

スライド

 

---

 

新卒の所感

今回はブロックチェーン連携開発についてお話ししてくださいました。ブロックチェーンは聞いたことがあるくらいで具体的にどのようなものなのかはわかりませんでした。今回のお話で少しではありますが知ることができてよかったです。

 

自社での連携開発はメリットがあり、良いですね！
問題の対処として事前に問題の対策を全て挙げておけばいざ問題が起きた時に対処がしやすいというのはクライアントエンジニアとしても大切なことですね。

 

今後メタバースは成長していくものと思われますので、メタバースに関連してブロックチェーンの知識を持っておくのは良いかもしれません。

 

---

 

ここまで読んでくださり、ありがとうございました！
後編では「Kotlin バックエンドアーキテクチャ of アバターサービス」というテーマでお届けします！
こちらからお読みください！
【cocone TECH TALK VOL6・後編】 Kotlin バックエンドアーキテクチャ of アバターサービス

 

また、前編では「リアルタイム対戦xバックエンドアーキテクチャというテーマでお届けしました！
まだ読んでいない方は是非こちらからお読みください！
【cocone TECH TALK VOL6・前編】リアルタイム対戦xバックエンドアーキテクチャ