今回はMOLD teamが進めているMOLDEX のコンセプト及び交換プロトコルの概要ついて簡単に紹介する。
DEXとは何かを知りたい方は前回の記事を参考にされたい。
MOLDEXのコンセプト
現在、Cryptokittiesをはじめとして、ERC721をベースとしたデジタルアセットはたくさんあるが、今後ブロックチェーンゲームの真価が発揮されるのは、キャラクターのみではなくゲーム内のアイテムまでブロックチェーン上で取引される時であると考えられる。そのためには、Fungible tokenで表現されたゲーム内アイテムとNon-Fungible tokenで表現されたゲームキャラクターの両方を自由に交換できるプロトコルが必要になってくる。Fungible tokenは、単にERC20のような通貨として流通している形式をとるもののみではなく、ERC1155の規格に沿って表現することも可能であるので、今後ますます利用される機会が出てくると予想される。
※ERC1155の仕組み及び革新性については次回の記事を参照のこと。
MOLDEXでは、Fungible tokenと Non-Fungible tokenの両方をサポートすることで、ERC20及びERC721の規格に沿った既存の分散型取引所とは違った立ち位置に立つことができる。
また、MOLDEXは、ブロックチェーンベースの決済と組み合わせて、トラストレスで、リアルタイムの、ハイスループットの取引を提供する。MOLDEX側で取引の照合とEthereumへのtransactionの送信を一元管理することで、ユーザーは、取引がネットワークで承認されるを待たずに継続的に取引し、かつ、一度に複数の注文を処理したり、Gasをかけることなく直ちに注文をキャンセルしたりすることも可能になる。
MOLDEXの特徴
MOLDEXは、スマートコントラクト、トレーディングエンジン、およびトランザクション処理の仲介で構成されている。スマートコントラクト上では、すべての資産を信頼できる方法で保管し、デジタルアセットの交換を実行する。また、すべての取引は、ユーザーの秘密鍵によって承認される必要があるので、運営側の不正使用はもちろん、第三者による取引偽造といった問題を引き起こす可能性は低いと言える。
他の分散型取引所とは異なり、MOLDEXのスマートコントラクトは、取引所のみが署名済み取引をEthereum に送信することを許可されるように設計されている。これにより、MOLDEXは取引の処理順序を制御し、注文のマッチングを最終決済から切り離すことができるため、ユーザーが取引するとorderbookがリアルタイムで更新される。同時に、ユーザーの秘密鍵はスマートコントラクト上における取引を許可するために使用され、この承認により、MOLDEX側が未承認の取引を開始するのを防ぐことができる。
ユーザーの署名つきの注文は、注文のマッチングを管理するトレーディングシステムに渡される。Ethereum上で各取引が正しい順番で採掘され、スマートコントラクト上での残高が取引残高と同期していることを保証するために順番に注文ペアの交換transactionを発行する(トランザクション処理の仲介)。トランザクションの順番を制御することにより、MOLDEXは集中型交換のスピードとUXを、DEXのセキュリティと監査可能性と組み合わせて提供することができる。
上記の特徴を踏まえると、MOLDEXには次のような性質があるといえる。
trustless
分散型取引所で大切なことは、秘密鍵の管理をユーザーが行うことである。MOLDEXでは、スマートコントラクトへのdeposit及びwithdrawはユーザーが直接行うほか、注文を出す場合も秘密鍵での署名を求める仕組みであるため、ユーザーは、取引所側を信頼しなくても不正がないアセットの交換を実現することができる。
取引が速い
オンチェーンでマッチングを行う従来の分散型の取引所では、取引のたびに注文がブロックに取り込まれるのを待つ必要があるため、実用には堪え難い設計になっていた。しかし、MOLDEXの場合は、注文のマッチングはあくまでオフチェーンで行い、実際のアセットの交換に関してはブロックチェーンを活用するので、ユーザーから見るとリアルタイムで取引しているようなUXを作ることができる。
orderbookの更新が速い
同様に、orderbookの更新に関しても既存のデータベースを活用することで、ほぼリアルタイムでの更新を可能にすることができる。
キャンセルにGasがかからない
ユーザーは注文するときに、注文データに署名を求められるが、その注文自体は売買注文がマッチングするまでは、データベースで管理される。したがって、キャンセルするまでに画面を凝視して待ったり、キャンセルするためだけにGasを支払ったりする必要ない。
複数注文が可能
MOLDEXでは、大量のアセットを一気に購入するのを可能にする複数注文に対応している。ただし、transactionはマッチした売り買い注文のペアごとに発行される。
Ethereum上でのAssetsの全ての取引が可能
MOLDEXのコンセプトを実現するためにも、次のERC規格に則ったtokenの交換を可能にする。
- ERC20
- ERC721
- ERC1155
MOLDEXでの取引フロー
次に、実際にMOLDEX上で取引が行われるときの流れについて見ていく。下図は、MOLDEX上で実行される取引の様子を簡易的に示したものである。
0. 新規登録
まず、ユーザーは、Ethereumのアドレスを新規作成するかimportして、自分で設定したpasswordとともにMOLDEXに新規登録する。もちろん、中央集権的な取引所と違ってアドレスの秘密鍵の管理はユーザー自身が行う。
- deposit
MAKER、TAKERともにスマートコントラクトに直接depositする。depositしたアセットはいつでもwithdrawすることができる。 - データベースに反映
スマートコントラクトを参照してMAKERとTAKERの残高を管理するデータベースを更新する。 - MAKERの注文
MAKERは、任意の価格及び数量で、注文を出すことができる。MAKERは、自身の秘密鍵で注文データに署名してサーバーに送る。もし、一定期間経過しても取引が成立しない場合は、自動的にMAKERの注文は無効になる。 - 注文データの検証とDBへの保存
サーバー側でMAKERの署名が正しいか、 データが十分か(残高があるか)などの検証する。例えば、Aさんの署名データがAさんのアドレスと一致しない場合、その注文は不正な注文データとして棄却されるので、秘密鍵を共有しない限り他人がAさんになりすまして注文をすることはできない仕組みになっている。検証が済み、正しい注文データであることが確認されるとデータベースに格納される。 - TAKERの注文
TAKERは、MAKERが設定した板情報と価格が一致する注文を出す。
任意の価格で注文を出したい場合は、MAKERとして注文を出す。 - 注文データの検証
サーバー側でTAKERの署名が正しいか、 データが十分か(残高があるか)などの検証する。 - マッチング
検証済みのTAKERの注文は、取引のマッチングエンジンを通して、データベースから取得したMAKERの注文とペアを作る。マッチングの詳細は次章参照のこと。 - データベースの更新
マッチングした取引注文ペア及びユーザーの残高の更新を行う。この時点で実際にはEthereumのブロックチェーン上で取引が成立したわけではないが、注文状態をオフチェーンで管理しているためユーザーは即座に次の取引に移ることができる。また、取引が不成立の場合はその状態がDBに記録される。 - アセットの交換実行
MAKERとTAKERの注文がマッチした場合に、サーバー側からスマートコントラクトのtrade関数を実行する。 - スマートコントラクトの状態更新
Ethereumネットワーク上で取引が承認されて、アセットの交換が終了し、walletの中身も無事更新される。
※ここでは、先に注文を出した人をMAKER、その注文にぶつかるように逆サイドから注文を出した人はTAKERと呼ぶことにする。
取引のマッチングシステムについて
強力な取引プラットフォームは、マッチングエンジンとも呼ばれる効率的な注文割り当てアルゴリズムを中心に構築される。このアルゴリズムはあらゆる交換の中核として機能する。
MOLDEXでは、もっともシンプルなアルゴリズムであるFIFOのPrice-Time-Priorityアルゴリズムを採用する。
まずは、マッチングエンジンの基本的な概念を理解するために次のようなモデルで考えてみよう。
- Order
MOLDEXにおけるTAKERの注文にあたる。 - Orderbook
MOLDEXにおけるMAKERの注文の集合にあたる。 - Trade
Orderbookの注文と一致するOrderはTradeとして処理される。MOLDEXの場合は、この後一致したペアがEthereumのネットワークにブロードキャストされる。 - Unmatched Order
Orderbookの注文と一致しないOrder、または、一部だけTradeとして処理されて余ったOrderは、Unmatched OrderとしてOrderbookに追加される。
OrderがOrderbookと完全に一致する場合
マッチングエンジンは常に特定の注文に対して利用可能な最良の価格を見つけようとする。この場合は、Buy 1@100の注文にとって、安く取引できるSell 1@99がマッチし、マッチしなかったSell 1@100はorderbookに残る。
OrderがOrderbookと部分的に一致する場合
Buy 4@100 の注文に対して、Sell 1@99及びSell 2@100のOrderがマッチする。残りのBuy 1@100は、マッチする売り注文はないので、Orderbookに追加される。
OrderがOrderbookと全く一致しない場合
Orderbookの注文と全く一致しない場合は、MAKERとしてそのままOrderbookに追加される。
FIFO
複数の注文が現在の注文と一致する可能性がある場合、システム的にはどちら注文とマッチングさせるか不明瞭になってしまう。そのため、上記の価格を基準にしたアルゴリズムに加えて、FIFO(First In First Out)の概念を導入すると次のようになる。
すなわち、同じ値段の注文に関しては、注文した時の時間が古い方が優先的に処理されるので、Price-Time-Priorityでは、価格、時間の順に並べてマッチングさせていることがわかる。
まとめ
急速に変化するブロックチェーン技術周りで、安定したプロトコルが定着するのには時間がかかるので、すぐにMOLDEXの交換プロトコルが広がることは考えにくい。また、現状FungibleなアセットとNon-Fungibleなアセット両方をブロックチェーン上に乗せているÐapps自体ほぼ皆無なので、そもそもMOLDEXの交換プロトコルの需要の有無が問題になるのは自明である。しかしながら、将来的に、2nd Layerの技術が実用化されるなどのブレイクスルーが起き、大量のアセットの取引を捌くことができるインフラが整ったとしたら、MOLDEXが提案するようなプロトコルは必然的に必要とされるだろう。したがって、今は将来の需要に応えるためのプロトコルを研究・開発している段階といえる。MOLD teamでも、今後とも将来的なGameのあり方を模索するとともに、必要とされるであろう機能やプロトコルの開発にあたっていきたい。
次回：ERC1155の仕様と革新性について
— — — — — — — — — — — — — — — -
Cosmos Gaming Hub Project(旧MOLD Project)
CEO & Co-Founder
朝野 巧己
全てのゲーム愛好家に最高のエンターテイメントを届けるために
