Kyuzan NFT Marketplace
ERC721規格のNon-Fungible Token (NFT) をC2Cで取引できる多機能マーケットプレイスの提供
こんにちは、株式会社Kyuzanの小宮山です。
本記事では、我々がブロックチェーン事業者向けに開発した「Kyuzan NFT Marketplace」を紹介し、そのシステム構成や開発した上で得たTipsを共有します。より詳細な情報を知りたい方や実際に動いているデモを見たい方は気軽にHPかメールにてご連絡ください。
オンチェーンのみで作るマーケットプレイスと比べ、OpenSeaやKyuzan NFT Marketplaceのように「Gas削減のためにオフチェーン要素を組み込んだ多機能なマーケットプレイス」は、どうしても大規模なシステムになってしまいます。ブロックチェーン上でデジタルアセットとしてトークンを発行したいと考えている事業者様やプロダクト開発者様に本システムを自社のシステムに組み込める形で技術提供できればと思います。
目次
- Kyuzan NFT Marketplace とは
1.1. Tokenの出品
1.2. Tokenの購入
1.3. Tokenへのオファー
1.4. その他の機能 - システム構成
2.1. 構成要素 - 開発から得たTips
3.1. システム設計
3.2. 取引のシーケンス図 - まとめ
- おまけ: Kyuzan Blockchain Studio
1. Kyuzan NFT Marketplaceとは
Kyuzan NFT Marketplaceは、OpenSeaのようにユーザー同士がERC721準拠のNFT(Non-Fungible Token)を取引するためのマーケットプレイスです。利用するには、MetaMaskやTrust Walletのようなブラウザの機能を拡張するEthereumウォレットが必要です。
1.1. Tokenの出品
1.1.1. 固定価格
固定価格販売では、売り手はTokenの価格と販売期間を指定して、Tokenを出品します。 期間内に買い手が現れない場合、Tokenの出品はキャンセルされます。
1.1.2. ダッチオークション
ダッチオークションは、時間の経過とともにTokenの価格が下がっていく販売方法です。 これはTokenの適正価格がわかりづらい場合に有効で、NFTの販売時によく利用されています。 ダッチオークションでは、売り手はTokenの初期価格と最終価格、また、価格が最終価格まで推移する期間を指定してToken出品します。
1.1.3. イングリッシュオークション
イングリッシュオークションは、いわゆる「オークション」として一般に認知されている販売方法で、売り手は初期価格とオークション期間を入力してTokenを出品します。 Tokenの価格は買い手の入札によって引き上げられていき、オークション期間が終了した時点で最高額を入札していた人が落札できます。
1.2. Tokenの購入
出品されているTokenは、誰でも購入することができます。
固定価格・ダッチオークションで出品されたTokenは、購入者がETHを入金した瞬間に取引が完了します。
イングリッシュオークションで出品されたTokenは、オークション期間が終了すると、自動的に取引が完了します。
1.3. Tokenへのオファー
自分が欲しい「出品されていない」Tokenに対してオファーを出すことができます。 そのオファーがTokenの持ち主によって承認されれば取引が成立します。
これは、デジタルアセット(ここではTokenと同義)がブロックチェーンで管理されることによって実現した特徴です。ブロックチェーンを使うことによって、全てのユーザーは出品されたアセットだけではなく「出品されていないアセット」をも見ることができるようになり、それらのアセットにオファーを出せるようになりました。
1.4 その他の機能
1.4.1. ソート・フィルタ
自分の欲しいモンスターを見つけるために、ソートとフィルタの機能を実装しています。
1.4.2. Like
TokenにはLikeをつけることができます。 Likeの数は、Tokenの価値が市場に決められる際の、1つの指標となります。
1.4.3. Transaction履歴
Tokenが取引された記録を見ることができます。
1.4.4. お知らせ
出品したTokenが買われたタイミングなど、決められたタイミングでお知らせする機能があります。
2. システム構成
2.1. 構成要素
クライアント（Marketplace Client）
ユーザーは、Ethereumウォレットが内蔵されたブラウザを使ってマーケットプレイスにアクセスします。
マーケットプレイス (Marketplace)
マーケットプレイスはGoogle Cloud Platform上に構築されており、以下の４つの要素で構成されています。
- フロントエンド (server front-end)
クライアントが実際にアクセスする部分です。 - バックエンド サーバー (server back-end)
フロントエンドにAPIを提供しています。 - バックエンド ワーカー (worker)
ブロックチェーン側の監視をし、データベースの状態を適切に保ちます。GAEのstandard環境はリクエスト時にインスタンスを立ち上げる仕組みのため、workerにはflexible環境を使用する必要があります。 - データベース (db)
出品情報やトークンの情報を管理しています。
マーケットプレイス コントラクト (Marketplace Contract)
マーケットプレイスのオンチェーン要素です。
Kyuzan NFT Marketplaceは、出品をはじめ多くの処理をオフチェーンで実現しています。一方で、ETHとNFTの交換を不可分に実行したい「取引の確定」時などは、このコントラクトを使ってオンチェーンで処理します。
キーマネージャー (Key Manager)
オフチェーン要素を持ったMarketplaceには、取引の仲介役であるRelayerが存在します。そのRelayerのイーサリアムアカウントを安全にクラウド上で使用するために、キーマネージャーを使って管理しています。
この「クラウド上で秘密鍵を安全に扱う」機能はマーケットプレイスに限ったものではないため、マイクロサービスとして切り分けてあります。
ブロックチェーン エクスプローラー (Blockchain Explorer)
ブロックチェーン上のデータを見ることは、速さ・検索しやすさの両面でデータベース上のデータを見るよりも大変です。
ブロックチェーンエクスプローラーは、指定したコントラクトを常に監視することで、データベース上にコントラクトのデータをコピーし続けます。こうすることで、他のサービスは直接ブロックチェーンを見る必要がなくなり、オンチェーン情報を簡単かつ迅速に参照することができるようになります。
この部分も、マーケットプレイスに限ったものではないため、マイクロサービスとして切り分けてあります。
ERC721トークン (ERC721 Contracts)
イーサリアムのNFT規格であるERC721に準拠したトークンが、マーケットプレイスでの取引対象となります。
3. 開発から得たTips
3.1. システム設計
NFTのマーケットプレイスには様々な種類があります。どのような目的でマーケットプレイスを設計するかによって、システム設計が大きく異なってくることが分かりました。
3.1.1. NFTマーケットプレイスの分類
NFTのマーケットプレイスには様々な種類がありますが、それらを分類する上での重要な要素の１つに「gasがどこで発生するか」があります。
Ethereumというブロックチェーンの特性上、１つの処理を行うたびにgasと呼ばれる手数料を払う必要がありますが、これはコスト的にもUX的にもユーザーにストレスを与えます。たとえば、出品したり取り下げたりするたびに手数料を取られてしまうのでは、積極的なTokenの売買が行われなくなる可能性があります。このように「gasがどこで発生するか」による分類は、ある意味「使いやすさ」による分類とも言えるかもしれません。
このgasの発生による使いづらさを解決するために、多くのマーケットプレイスはオフチェーン要素を取り入れています。
例えば、流通量が世界一のマーケットプレイスであるOpenSeaは、初めは全てオンチェーンで実装されていましたが、今では一部の機能がオフチェーンとなり、gasの発生箇所を減らしています。
一方で、オフチェーン要素を増やしてgasを削減することは、開発コストを大幅に引き上げます。まず、ブロックチェーンという堅牢なシステムを放棄することで、自分たちで十分に堅牢なシステムを作り直す必要が出てきます。また、データとロジックがブロックチェーン上とサーバー上の両方に存在することになるため、それらの整合性を保つ仕組みも必要になります。そのため、ブロックチェーン以外にも多くの専門知識が必要になり、開発工数が増えるだけでなく、それらを開発できる人材も限られてきます。
別の重要な分類要素として、「非中央集権性」があります。多くの仮想通貨取引所では、それぞれのユーザーのwalletを取引所が管理していますが、それに対し、ほとんど全てのNFTマーケットプレイスでは、ユーザー自身が自分の秘密鍵を管理しています。このように「秘密鍵をユーザー自身が管理する」取引所をDEX(Decentralized Exchange)と呼びます。このDEXという言葉には注意が必要で、それは、DEXだからといって、完全に「非中央集権で、中央管理者がいない」わけではない点です。実際にOpenSeaやRareBitsといった有名なNFTマーケットプレイスもDEXではありますが、UX向上のために、その一部を中央管理者がサーバー上で運営しています。
現状のマーケットプレイスにおいて、UXと非中央集権性はトレードオフであり、その部分をどう設計するかで、それぞれのマーケットプレイスの特色が決まってきます。
3.1.2 Kyuzan NFT Marketplaceの設計方針
Kyuzan NFT Marketplaceは、「1番使いやすいマーケットプレイス」を設計の指針とし、非中央集権性にはある程度目をつむっています。
そのため、出品や出品の取り下げといった細かい部分にgasがかからないように、適宜オフチェーン要素を取り入れています。
一方で、イングリッシュオークションはオンチェーンでの実装がメインで、出品や入札にはその都度gasがかかります。これは、「gasがいちいち発生する」問題よりも、「落札されたのにETHが支払われない」問題や「落札してETHを支払ったのにTokenが送られてこない」問題のほうが優先して解決すべき課題だと思ったからです。そのために、イングリッシュオークションでは、売り手は出品時にdepositの入金が必要であり、買い手は入札時に入金が必要です。これらはオンチェーンで行われるため、そこには当然gasも発生します。
これらの設計は全て「1番使いやすいマーケットプレイス」という設計方針に基づいており、これから追加実装することがあれば、それらの実装も全てこの設計方針にのっとっていく予定です。
例えば、現状のマーケットプレイスの使いづらさとして、値段ソートが機能していない点があげられると思います。OpenSeaで1番高いCryptoKittiesのTokenを探そうとしても、誰かが出品したTokenが10,000,000,000ETHで表示されたりしてしまいます。これは明らかにソートが機能していない状態であり、「使いやすい」マーケットプレイスにとっては解決すべき課題です。
解決策としては、Tokenの価格を分析し、「過去に売れた価格の2倍以上の値段はつけられない」などといった制約をつけることが考えられますが、この方法も実現するにはまた工夫が必要そうです。
3.2. 取引のシーケンス図
以下は、固定価格取引におけるシーケンス図です。このシーケンス図を追いながら、いくつかの開発Tipsを示します。
3.2.1 出品
図中のCreateListingが出品の処理です。本システムでは、１つ１つの取引をListingと呼んでいます。
ポイントは、対象のERC721トークンにおいて、SellerがRelayer(Serverが持つアカウント)にisApprovedForAllがtrueかを確認している点です。この値はERC721の規格で定められており、これがtrueであれば、RelayerはSellerが持つTokenを自由にTransferすることができます。
これを確認した上で、サーバー上に出品情報を記録しています。
3.2.2 購入
図中のBuyingListingが購入の処理です。
1つ目のポイントは、ServerがBuyerに対してRelayerのsignatureを含んだraw transactionを渡している点です。これによって、最終的にTransactionにSignしBroadcastするのはBuyerであっても、Relayerが指定した(と証明できる)情報をコントラクトまで届けることができます。ここにTokenの価格などを仕込んでおくことで、SellerによってRelayerに伝えられた適切な価格での取引が実現されます。
これらの技術的な説明は別の記事でしているので、そちらを参照して見てください。
2つ目のポイントは、BuyerがExchangeContractから受け取ったtransaction hash(取引IDとして利用)をサーバーに返して処理が終了している点です。Ethereum上の処理には30秒ほどの時間がかかるため、この時点で取引はまだ完了していないのですが、この長い待ち時間で通信が途切れてしまう可能性を考慮して、その後についてはworkerに任せています。
3.2.3. workerによる取引完了の確認
3.2.2で示したように、取引完了の確認はworkerによってなされます(図中のProcessBuying)。記録されたtransaction hashを追うことで、pending状態だった取引の完了を検知します。
この他にも、workerはTokenのTransferや、isApprovedForAllの状態変化なども監視しています。出品中のTokenに対してこれらの処理がなされると、正常に取引ができなくなるので、これらを監視し、発見され次第出品を取り消すようにしています。
3.2.4 イングリッシュオークションとオファー
ダッチオークションもこのシーケンス図とほとんど同じ流れになりますが、イングリッシュオークションとオファーについては、基本的にはオンチェーンでおこなっているため、処理の流れが異なります。
本記事での詳しい説明は割愛しますが、以下のポイントだけは、押さえておくといいと思います。
Metamaskに「signしたtransactionをブロードキャストせずに返す (web3.eth.signTransaction)」機能は実装されていない。
We don’t and won’t support signing a transaction without submitting it, because it becomes a giant footgun in terms of nonce calculation inside MetaMask.
この制約はMetamaskに限らずほとんどのdAppsブラウザに当てはまるため、「オファーする段階で、buyerがsignした購入transactionをサーバーが受け取っておき、サーバー上でオファーが成立したらそのtransactionをbroadcastする」といった設計が不可能になります。
以上、簡単にですが、開発時のTipsをいくつか共有させてもらいました。
4. まとめ
本記事では、Kyuzan NFT Marketplaceの概要、システム構成、その開発を通じて得たTipsを紹介しました。この記事が、NFTマーケットプレイスの仕組みを理解する手助けになってくれたら幸いです。
一方で、この記事の中では紹介しきれなかった内容も多数ありますので、今後もこういった記事という形で共有していけたらいいなと思います。
このようなNFT向けのマーケットプレイスやオークションシステムにご興味がある方はこちらまで気軽にご連絡ください。
5. おまけ: Kyuzan Blockchain Studio
Kyuzanは東京を拠点としたブロックチェーンスタートアップです。
我々のミッションは「ブロックチェーン技術を実際のビジネスに取り入れる」ことで、日々、実用的なプロダクトの企画・研究・開発をおこなっています。
これらの取り組みは Kyuzan Blockchain Studio という形で、大企業からスタートアップまで全てのみなさまに開かれておりますので、興味のある方はぜひご連絡下さい。
contact@kyuzan.com
特に、既存のビジネスで強みを持った方々と、Kyuzanのブロックチェーン技術・デザインを掛け合わせて、まだ世界に事例の無い独創的なプロダクトを作りたいと思っています。よろしくお願いします。
