7月12日に開催された「TOKYO BLOCKCHAIN TECH MEETUP 2022」の“ブロックチェーンエンジニア勉強会”について3部に分けてレポートします。
喜多智也（きた ともや）氏
株式会社モバイルファクトリー Tech Lead
2018年、株式会社モバイルファクトリーに新卒のエンジニアとして入社。入社当時に立ち上がったブロックチェーンチームに所属中。学生の頃に触っていたフロントエンドに始まり、入社後はバックエンド、クラウド、ブロックチェーンなど様々な領域での開発に取り組んでいる。現在はNFTマーケットプレイスの「ユニマ」とNFTサービス構築支援プラットフォームの「ユニキス ガレージ」のテックリードとして開発運用に携わる。休日はスプラトゥーンや技術の素振りに取り組むことが多い。
芹川葵（せりかわ あおい）氏
no plan株式会社 Co-founder/CTO
面白法人カヤックでエンジニアとして働いた後、フリーランスエンジニアとして独立。その後カヤック時代の友人である岡室庄悟氏とno plan株式会社を設立し、CTOに就任。ブロックチェーンのリサーチ、事業開発等の統括的役割に携わる。
楢崎弘二（ならざき こうじ）氏
株式会社bitFlyer システム開発部副部長 暗号資産開発チームリーダー
Ruby、PHP、Node等のプログラマーや、金融・医療に関わるSEを経験した後、2017年に株式会社bitFlyerに入社。仮想通貨チームにて開発をリードし、2020年12月より現職のシステム開発部・副部長に就任。
クラウドKMSの活用
喜多氏：『クラウドKMSの活用』というタイトルで発表をします。まず自己紹介です。＠odan3240というIDで、空の画像のアイコンでTwitterをやっています。最近の興味ですが、ソフトウェアエンジニアとして普段はバックエンドでTypeScript書いたり、コントラクト周りの調査をしています。最近はOpenSeaが出したSeaportというプロトコルや、さきほどの登壇内容と被りますがMeta Transactionの仕様を読んだり、コントラクトウォレットのサーベイ（大規模調査）をやっていました。
弊社の宣伝です。自分は株式会社モバイルファクトリーという会社でソフトウェアエンジニアをやっています。主に開発しているサービスがユニキス ガレージというサービスとユニマ（Uniqys マーケットプレイス）というサービスを開発しています。今日はエンジニアの方が多いので前者の方に関心が強いと思うので、前者の話をします。こちらはトークンを生成できるSaaSです。WebUIからトークンを生成できるだけではなく、API経由でもトークンを生成できるので、既存サービスのインテグレーションが可能なサービスです。
本題です。まず「Webサービス開発で秘密鍵管理をどうするのか？」です。
ブロックチェーン周りの開発をされたことがある方なら何割かは経験があると思います。サービスの要件によってバックエンドでトランザクションを送信するような要件が存在する場合に、バックエンドで秘密鍵を何かしらの方法で持って、その秘密鍵を使ってトランザクションを送信する処理です。
例えばこれはNode.jsの例ですが、環境変数で管理するという方法がまず一つ考えられます。これはセキュリティ的にちょっと危ないなという部分があります。なぜかというと秘密鍵は単なる文字列なので、ハッキングがあって流出した場合に誰かがこっそり秘密鍵をMetaMaskなどにインポートできてしまうのです。その状態で自由に鍵を使えるし、それがどういう経緯で使われたか追跡することができないようになっています。
話は変わりますがクラウドにはKMSというサービスがあり、キーマネジメントサービスと言って様々な鍵を管理しています。偶然なのか狙っているのか分からないですが、イーサリアムが使用している楕円曲線暗号のsecp256k1形式の鍵をサポートしています。これの何が良いかというと、これはAWSのドキュメントですが現場のエンジニアもAWSの従業員も含めて、平文の秘密鍵に誰もアクセスできないという特性があります。さらにクラウドのAPI呼び出しは監査ログとしてクラウド側に何時何分にどういうAPIを使用しましたというログが残るのです。このような点で、先ほどの環境変数による管理より良いと考えています。
ここからは自分が作っているOSS（オープンソースソフトウェア）のライブラリの紹介です。クラウドのKMSのAPIとクリプト系のライブラリの中間の接着剤、それを繋ぐようなライブラリを作っています。
これを使うと先程のコードはこのような感じになって、最終的にはこの辺りでトランザクションを送信するイメージです。クラウド上にある秘密鍵を使ってトランザクションを送信できるようになります。このkeyIdは、このidを知っていてもこのkeyIdに対する権限がないと使用できない仕組みですので、とても安全にトランザクションの署名をすることができます。
ライブラリや対応クラウドは今このような感じで、よく使われているweb3.jsやethersなどに対応しています。最近Hardhat対応を研究中です。クラウドもAWSとGCPのKMSを使って、ethers.jsなどでトランザクションを送信することができます。
まとめです。環境変数で生の秘密鍵を開発すると、不安要素があるという話をしました。クラウドのKMSを使うと、その辺りを安全にできます。それを組み合わせるためのライブラリを作っていますという話でした。以上です。
【参考URL】
登壇資料：https://speakerdeck.com/odanado/tokyo-blockchain-tech-meetup-2022
cloud-cryptographic-walletのGitHub：https://github.com/odanado/cloud-cryptographic-wallet
NFTのインデクシングとGraphQLのすゝめ
芹川氏：『NFTのインデクシングとGraphQLのすゝめ』ということで、芹川が発表させていただきます。よろしくお願いします。
今日話すことも含めて自己紹介です。私は芹川と申しまして、猫のアイコンでTwitterなどではserinuntiusという名前でやっております。『no plan inc.』という場所でCTOをしており、JPYCの技術顧問もさせていただいております。
NFTのインデクシングとは何ぞやということですが、NFTが持っている情報や付随する情報を検索しやすいようにDBに入れることと勝手に僕は定義しました。
なぜインデクシングが必要になるかですが、一般的にNFTの情報にアクセスする時にはコントラクトに入っている、このようなview関数を叩くことが多いと思います。例えば、ownerOf関数だとトークンIDを渡したらownerが返ってくる。トークンURIもそのような形です。
情報が欲しくなったときにview関数を叩きまくるというのは、現実的ではないと思っております。ちょっとしたサービスならいいですが、大規模なサービスだとノードの負担になってしまいます。例えば皆さんInfuraやAlchemyを使われていると思いますが、そういうもののコストも増えてしまいます。それと、時間もかかっていますね。
ERC1155の対応の闇という話もあります。1155の闇ですが、ERC721みたいにownerOfという関数が生えておりません。ですので、view関数だけではトークンIDの所有者情報を調べることはできません。
あともう1つ、個人的に嫌なのがnameという関数が生えていないのも、結構だるいなと思っています。ノードの情報だけでは何のコントラクトなのか分かりづらくて嫌です。ERC721は規格としてマストになっているわけではないですが、OpenZeppelinのERC721Metadataが継承されて普及されているので、大体取れるような気がしております。
ではどのようにインデクシングしていくのかですが、闇の魔術に対する防衛術をお教えしようと思います。
EVMには皆さんご存知だと思いますが「event」という概念があります。ノードに対してイベントをリッスンしておくことで、コントラクトからイベントが発火した時に任意の処理を実行できる仕組みです。例えばERC721だとTransferというイベントがあり、indexedというキーワードを付けると、その変数は検索できるようになります。eth_getLogsというAPIを呼び出すことによってイベントを取得できるようになっています。イベントの面白いところはどのブロック高でそのイベントが発生したかという情報が取れる状態になっている点です。
ERC721の場合です。1ブロック目からこのTransferをずっと追っていけば、誰が何のIDのトークンを持っているかがわかるようになります。最後に同期したブロック高をDBに入れておいて、次回以降はその差分の更新だけでいいのです。
例えば今が100ブロック目だとして、0から100ブロックまで同期して1時間後にまた同期しようと思ったら、その100ブロックから進んだブロックだけでいいのです。非常に効率的だと思います。
ERC1155の場合はTransferのイベントが2つあり、少し厄介です。このTransferSingleというイベントとTransferBatch。文字通り複数の送信に対応しているイベントがあるので、その2つのイベントをまとめてインデクシングしていく必要があります。これも1ブロック目から順番に追っていけばいいです。
GraphQLが結構良いよということで、先ほどインデクシングした情報をDBに保管して、GraphQLで返すように実装してみました。良いなと思ったのが、GraphQLで作っておくと、型付のクライアントが自動生成できるので、サーバーもクライアントもTypeScriptで実装していますが、クライアントの型が付くので便利でした。NestJSやPlanetScaleというDB、あとPrismaというORMやGCPのCloud Runあたりで実装しています。この辺り全部気を使って実装していくのはとても非効率だと思っているのですが、多分今は各社さんがキャッシュしている状態です。
これはかなり非効率で、実は現在、全部弊社がまとめてインデクシングしておくのでAPI投げてくれれば大丈夫ですよというSaaSを作っております。まだ仮ですが『NFT GraphQL API』として発表しようと思っています。よくこのようなサービスにありがちですが、面倒くさい点が、いろいろなEVMの互換のチェーンに対応していないところです。弊社にご依頼いただければ気軽に追加したいと思います。
実装コストやノードのメンテナンスコストを考えるとコスパが良すぎたり、「誰か作ってほしいな」と思いながら僕たちは作っていました。変なサービスだとボラティリティの高い草コインを払わされるようですが、日本円で払えます。
こちらはもう少しでリリース予定です。QRコードからフォームを用意しており、送っていただければ折り返しご連絡差し上げますので、是非ご興味ありましたらアクセスして登録していただければいいなと思います。
【参考URL】
登壇資料：https://t.co/8QgAPbMCNY
NFT GraphQL APIの申込：https://t.co/KBcSptNTli
EIP721：https://eips.ethereum.org/EIPS/eip-721
EIP1155：https://eips.ethereum.org/EIPS/eip-1155
OpenZeppelin – IERC721.sol：https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol
OpenZeppelin – IERC1155.sol：https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC1155/IERC1155.sol
暗号資産取引所のブロックチェーンエンジニアリング概要
楢崎氏：こんばんは。bitFlyerでシステム開発部の副部長をしております楢崎と申します。本日は『暗号資産取引所のブロックチェーンエンジニアリング概要』ということで、今まで登壇していただいた皆さんがお話しされた内容と比べかなりゆるふわな感じです。
本登壇のターゲットとしてはブロックチェーンに興味ある方全般としています。実際に皆さん、中央集権的な取引所を使われたことがある方であれば、入出コインをされたことがあると思います。そういった中でどういったものが動いているのかみたいな辺りをさらっと知っていただたければと思います。
私自身の自己紹介ですが、2017年、ちょうど暗号資産バブルの少し前ぐらいにジョインして「ビットコインすごいな」「仮想通貨すごいな」と思いました。最初はフルスタックのエンジニアとしてbitFlyerのいろいろなプロジェクトに関わって、主に暗号資産関係のサービスの開発に従事しておりました。
私事ですがbitFlyer入社後に結婚して2児の父になり、2回育休を取っています。今0歳と3歳の子どもが家にいます。bitFlyerと聞くと、bitFlyerという取引所と、bitFlyer Blockchainというプライベートブロックチェーンを開発している会社が思いつくかと思いますが、本日はパブリックブロックチェーンでお客様に入出コイン機能を提供している前者側としてお話させていただきます。
まず「暗号資産エンジニアって何をやっているの？」ですが、かなり多岐にわたっておりまして、インフラレイヤーのようなところからAppDevといったところはもちろんのこと、暗号資産について知ることも含まれます。具体的にはフルノードの運用や、ブロックチェーンからトランザクション情報を取り出す機能や電子署名系の実装、オフラインウォレットなどについてもと本当に多岐にわたっているかと思います。新規コインを取引所が追加するというニュースを目にされる機会もあると思いますが、こういった新規コインの上場や、ハードフォーク対応でもプロジェクトを担当することになります。
新しいブロックチェーンの調査業務も要所要所で入ってきて非常に楽しいこともあります。かなり様々なレイヤーを見なくてはいけません。それぞれのプロフェッショナルがいて、そのレイヤーを極めてもらったり、いろいろなスタックの知識や能力を研鑽できる場所だと思います。
フルノードの運用という点で、次のトークテーマと被るところもありますが、我々はMicrosoft Azureをプラットフォームとして使っており、主にAzure VMやKubernetesを使っています。
他社の人が作ったサードパーティのブロックチェーン実装になるので、日々アップデートがないか、破壊的変更がないかというのは常にフィードして調査しています。フルノードの安定稼働に関しては、キャパシティプランニングとしてメモリをどのくらい使うか、ディスクをどのくらい使うか、スピードがのれくらい出るか、冗長構成をどうやっていくか、かなりインフラエンジニア的な能力が問われます。
またいろいろなブロックチェーンの実装プロジェクトがあり、やはり栄枯盛衰があります。例えば弊社ではクライアントにParityのOpenEthereumを使っていましたが、The Mergeが前に使えなくなったので代わりを探さなければいけないなど、「ああでもない、こうでもない」といった葛藤もありました。
アプリケーション開発者も当然居ますから、ブロックチェーントランザクションに電子署名するような機能の開発や、ブロックチェーンからデータを取り出すアプリケーションの開発をやっていますが、2014年の創業以来、自社開発をしています。我々はAzureを使っていますが、サーバーレス技術『Azure Functions』といったものを使っています。
暗号資産ごとに実装は疎結合になっていて、マイクロサービスアーキテクチャ的なところをやっています。ブロックチェーンの技術は本当にいろいろあるので、今日はイーサリアムに特化した話が多いと思いますが、いろいろなブロックチェーンのことを知らないといけないところがかなりチャレンジングだと思います。
秘密鍵の管理は、先ほどKMSの話が出ましたが、AzureにあるKey Vaultを使ってAzure Active Directoryでアクセスレベルなどを定義していますが、ssp2561k1のcurveは対応しているのですがED25519は対応していないので、少し工夫しなくてはいけません。あとはHD walletを構成して複数のアドレスを簡単に管理できるようにしたり、オフラインウォレットは別の仕組みを0ベースで構築しています。
中央集権取引所で最も問われることの一つはセキュリティだと思います。過去にもセキュリティに関するインシデントが起こっています。我々も常に非常に警戒をしています。Azure Active Directoryのような認証基盤を使ってきちんとAuthentication・Authorizationをやっていく。あとは、脆弱性診断を常に行い、コードアセスメントで必ず開発するフェーズに入り込んでいく。IaaSだったらセキュリティも我々の責任の下になるので、脆弱性スキャナーで毎日モニタリングしています。本当にセキュリティスタンダードを作ってはPDCA（品質管理など業務管理における継続的な改善方法）を回して、より企画段階でセキュリティホールを潰すようなシフトレフトで常に運用しています。
まとめに入ります。ブロックチェーンに関して、ノード運用からアプリケーション開発、ウォレット開発までEnd to endで開発しているから非常にチャレンジングな会社です！一緒に仕事してみたい人を絶賛募集中ですので是非お声がけください！
Web掲載のない非公開求人もございます。詳細は以下の転職相談よりお問い合わせください。
