ココネグループのブロックチェーン MOOI Network とのバックエンド連携 2023/04/25　Yuji Saito

■経歴 　CRMパッケージ企業 / SIチーム 　エンタメ系 / 自社開発企業 　株式会社ヴァリューズ 　ココネ株式会社 社会に出てプロジェクトマネジメントを含めたSIerムーブを一通り叩き込まれ、　 その後は自社開発エンジニアの道へ。 前職ではサーバーチームのリーダーとして複数事業でバックエンドの設計-実装-運 用を行い主力製品のAWS Foundational Technical Reviewの適用対応なども担当。 2022年、ご縁がありココネへ。 自己紹介　齋藤裕志（ Yuji Saito ） JANKENでのすがた 実社会でのすがた 趣味 : Sound Horizon ⛩ 2

◯ お伝えする範囲 ・自社ブロックチェーン基盤と連携する、という世の中的に珍しい開発事例 ・その説明のための前提知識など ✖ お伝えする範囲外 ・ブロックチェーン基盤側の話 ・トークンエコノミクス関連の運営の話 ・他、詳細な連携方法や通信仕様などセキュリティ担保に関わり得る内容 （※これらを期待されていた方すみません...） 本日の発表内容 3

01. MOOI Networkとは何か 02. ブロックチェーン連携をするとはどういうことなのか 03. 実際の開発に求められること ※web3関連は世の中に様々な言説が存在します。この発表では、 「web3事業に関わることになった1サーバーエンジニア」の解釈 を書いています。 目次 ✖：web3としては、これが正しい！ ◯：なるほど、そういう解釈もあるのか！ 4

01 MOOI Networkとは何か 5

MOOI Networkとは https://whitepaper.mooinetwork.io/mooi-network/whitepaper/blockchain-network klaytnのサービスチェーンとして作られ た、メタバース用のブロックチェーン。 MOOI というトークンで取引をする。 6

ココネとの関係 https://cocone.global/company ココネの同じグループ内で、ブロック チェーン開発、NFTマーケット運営を している組織があります。 7

02 ブロックチェーン連携をす るとはどういうことなのか 8

できること1 デジタルアイテムのNFTとして所有することができる サービスでNFTを発行(Mint)することができます。 MintされたNFTは、マーケットプレイスで取引が可能です。 https://jellyme.io/ 9

できること2 MOOIと交換可能なトークン（通貨）をサービス内で発行できる https://mooiswap.fi/swap MOOIと交換可能なトークン（通貨）を発行することができます。 ※トークンエコノミーと呼ばれる独自の経済圏が発生します。 10

結局何が嬉しいのか（※1開発者の見解です） ・どこかのMongoDBにdocumentとしてBinary JSONで保存 ・データが破壊/改竄をある種の信頼で守る ・逆にいうと連携の様々なコストは低い Item Data ・ブロックチェーン上で、保持状態や履歴が分散保存 ・データの破壊/改竄を技術的に守る ・連携の様々なコストは高い Own Info 従来のアイテムの保持 ブロックチェーンにおけるアイテムの保持 11

結局何が嬉しいのか（※1開発者の見解です） - 改竄が難しい保持状況＝現実世界に近い、とも言えます - 言い換えると「サービスのデータを現実と連携させて保有して いる」とも言えます 「現実との連携」、そう聞くとワクワクしてきませんか？ 12

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

イーサリアムなどのパブリックチェーンとの連携と比較すると、 以下のような要素は良い特徴と言えると思います。 1. 質問先が自社グループ内にある 2. Walletを含めて自社で保有しているため、Controllableな部分 が多い（機能開発要望などを行える） 3. 「自社グループのブロックチェーン」という楽しさ 自社で運用しているブロックチェーンを連携開発する時の特徴 14

サーバーサイドエンジニアが活躍する範囲 - 当然、連携するにあたり元データとなるサービス内のデータが ありますので、サーバーサイドの領域が深く関わります - いわゆる決済対応のような外部連携と似たような物、と考えて 差し支えありません。 周辺知識は求められますが、外部連携はどんなシステムと行っても大 体そうなると思いますので、その延長と考えれば困りません。 通信仕様 ルール 15

ブロックチェーン連携の流れ（すさまじくざっくり書いたもの） ①Mint（ミント） サービス側でアイテムを削除(封印)し、ブロックチェーンにデータを書き込む Mint Burn Item Data Own Info Item Data Burn Info ②Burn（バーン） ブロックチェーン上でデータを利用不可能にし、サービス側でアイテムを利用可能に ※実際の処理の流れはもっと複雑で、順序も上記とは異なる場合があります。 16

開発時の注意ポイント〜防がないといけない不具合 ・サービス内でNFT化が可能なものは、現実の資産へと連携され ていくため「想定以上にアイテムが発行されてしまう状況」を防 ぐ必要があります。 ・根本的な設計は（今回の発表内容ではない）トークンエコノミ クスで設計してゆきますが、エンジニアとしては不具合によって それを崩さないことが必要となります。 サービスとして致命傷となる不具合の種類が、 今までのサービスよりも1つ増える 17

対策の例 ・Transaction機構をしっかり使う ・Redisなども踏まえた、徹底的な排他制御 ・ミューテーションテスト（っぽいもの）によりテストのカバ レッジを上げる 18

・WriteConflict問題を極力回避するDocument設計にすること ・バージョンが古すぎると利用できないので注意 ・日本での適用事例など情報が少ない（気がする） MongoDB with Transaction ・今回はMongoDBを採用しました ・複数のDocumentを跨いで更新できると（当然）不整合による不 具合は減ってゆきます。 ・MongoDBのTransaction機能を使いました Point 19

WriteConflict問題 ・更新対象がTransaction中はロックされる（これは当然） ・ロック中にそのDocumentにTransactionで処理しようとすると、5msだけ待って エラーとなる（なんやて） A’s Item A’s Status B’s Item B’s Item Shared Info Shared Status ◯ Transaction 1 ◯ Transaction 2 ◯ Transaction 1 ✖ Transaction 2 ERROR https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.maxTransactionLockRequestTimeoutMillis 20

・「同時に更新される」ようなコレクション設計をしていると、開発 後半で詰む。 ・今回で言うと「バトル」や「ランキング」と言う要素が、人を跨い で共通のDocumentを同時操作的に更新するため、回避に工夫が必要と なった ・このような要素が入る部分は、特に負荷テストが必須 ※例えばMySQLなどによるロックなどの注意点と近しいものではある が、MySQLのInnoDBの同様の値のデフォルトは50秒なので問題はそう そう起きないことが多い（と思う） WriteConflict問題 21

Redisによる同時実行ロック ・基本的に同じ人が異なる操作を同時にはしない設計想定にして おくと、問答無用で同時実行の制御を行える ・Redisはシングルスレッドであるため、シンプルながらこの手の 制御を行わせると強力に働く 22

ミューテーションテスト（っぽいもの）によりテストのカバレッジを上げる ・今回の要件において、外部通信が複雑に発生する ・特にネットワークエラーなど、結合テストなどでも確認が難し いものについて、全てテストしていく必要がある case 内容 エラーキー １ NFTをMintingする通信の関数1 mutation1 ２ NFTをMintingする通信の関数2 mutation2 ３ … … mutation2:(userid‐A) mutation2:(userid‐B) mutation1:(userid‐C) →設定すると故意にエラーを発生させるような仕組みを作成 →以下の例だと例えば userAは必ずNFTのMinting通信の関数2で失敗するようになる 23

結果・効果 ・リリースして見ると、やはりアクセスが多いと発生するエッジ ケースがあったが、事前に全てテスト済みのものだった ・カオスエンジニアリングでも解決できそうだが、too muchにも 感じ、、、もっと効率の良い手段があれば知りたい 24

まとめ・感想 ・web3との「連携する側」の場合、技術的に必要度合いが高いの は、従来の外部連携開発としてのサーバーサイドの経験 ・自社グループにweb3の組織があると知識部分も自然と埋められる 仲間と連携して新しいことにチャレンジ出来るのはとても楽しい！ 25

ご清聴ありがとうございました 26