TL;DR
分散型取引所を構築するためのプロトコルである0x Protocolを用いて分散型取引所を創ることができます。その分散型取引所の戦略は大きく分けて、Matching, Open Orderbook, Quote Provider, Reserve Manager の4つがあります。実際に分散化取引所を創る際には、製作者がどの戦略を取るべきかを検討しなければなりません。本稿ではそれらのメリット、デメリットを解説します。ちなみに僕自身が作っている分散型取引所ではOpen Orderbookを採用しています。 ご意見、改善点などあればTwitterでご連絡ください。
Matching
前項でも書きましたが、オーダーを出す人（Maker）はオーダーのフォーマット内のパラメーターであるTakerを指定することにより、特定の人（Taker）しか受け取れないようにすることが可能です。Matching戦略では、MakerがリレイヤーのアドレスをTakerパラメーター内に指定をすることによってリレイヤーしか受け取れないようにします。
※ リレイヤーに関してはindivさんのこちらの記事を参考にしてください。
複数のオーダーをうけとったリレイヤーが需要と供給のマッチするオーダーを見つけbatchFillOrdersもしくは batchFillOrKillOrdersコマンドを実行することによって両者のトークンが交換されます。
例
- Aliceが「1WETH 売って、1000ZRXほしい」というorderAをリレーヤーCharlieに送る。
- Bobは「1000ZRX 売って、1WETHほしい」とリレーヤーCharlieに送る。
- Charlieは
batchFillOrKillOrders(orderA, 1000, orderB, 1)をcallし、Aliceの1WETHとBobの1000ZRXが交換される。
メリット
- リレイヤーのみが交換のコマンドを実行できるので、複数のTakerが同時に同じオーダーを署名するコンフリクトが起こることがない。
- リレイヤーはいつオーダーが実行されるかをしることができるので、オーダーブックのアップデートがより早くでき、リアルタイムトレードがよりスムーズに可能になる。
- gasコストをリレイヤーが持つことになるので、トレーダー視点ではよいUXとなる。
デメリット
- 多少の集権性が残る。リレイヤーはオーダーをマッチングすることを強制されていないので、手数料によってのみインセンティブ付されている。
- 成り行きの注文をすることがむずかしい。
- オーダーがスマートコントラクトによって生成されていないので、0x上のDAppsや他のリレイヤーと流動性が共有できない。
Open Orderbook
リレイヤーはTakerのパラメーターが0x0000000000000000000000000000000000000000となっているオーダーを受けつけブロードキャストします。トレーダーはローカルの環境でそのオーダーに署名をしてEthereum Nodeに送ります。
例
- Aliceが「1WETH 売って、1000ZRXほしい」というorderAをリレーヤーCharlieに送る。
- Bobがそのオーダーを、Charlieのオーダーブックの中から見つけて、Bobが「fillOrder(orderA, 1000)」をコールする。Bobの1000ZRXは1WETHと交換。
メリット
- 安いかつ、最もトラストレスな取引。3rdパーティーがオーダーブックにアクセスしやすい。
- オーダーが他のリレイヤーをシェアできる。
- 外部のdAppsがオーダーの流動性を使える。
- 外部のおスマートコントラクトと連携できる。
- リレイヤーにとってはgasがユーザー持ちなので負担にならない。
デメリット
- トレーディングの量が多くなると、同じオーダーをfillしたり衝突が多くなる。衝突を狙った攻撃が多くなる。
Quote provider
リレイヤーが流動性を提供するパターンです。トレーダーが署名をしたオーダーをリレイヤーに送ることでリレイヤーが自身で確保しているトークンもしくは外部の流動性を用いてfillをします。
例
- リレーヤーCharlieは 1000ZRX / 1WETHのレートで買いたいと表明する。
- Aliceが 10000ZRX売って、10WETHを買うオーダーAをリレーヤーCharlieに送る。
- CharlieはfillOrder(orderA, 10000)をコールし、10WETHとAliceの10000ZRXが交換される。
メリット
- トレーダーとレート交渉を署名前にオフチェーンで行うことができる。
- オーダーが署名された後にリレイヤーは外部の流動性を使うオプションがある。
デメリット
- トレーダーの署名後、リレイヤーのfillが義務ではない。（これはMatchingの時と一緒。）
- アトミックマッチング機能が追加されるまではリレイヤーはトークンのリザーブが必要であったが、この機能は実装済み。
Reserve manager
リレイヤーが独自で流動性を確保する方法です。takerのパラメーターを0x0000000000000000000000000000000000000000に設定したオーダーの有効期限を短くして頻繁にブロードキャストする方法です。これはOpen Orderboookと併用して使うことができ、自分のプロダクトでも採用を検討しています。
例
- リレーヤーのAliceが「100WETH売りたい、100000ZRXほしい」というorderAを45秒の有効期限でブロードキャストする。
- BobがfillOrder(orderA, 1000)をコール
- Bobの1000ZRXとリレーヤーAliceの1 WETHを交換する。
- 別件で、CharlieはfillOrder(orderA, 2000)をコール
- Charlieの2000ZRXと、2WETHを交換する。
メリット
- トレーダーへオーダーの流動性を確保するために有効な手段。
- ブロードキャストはoff-cahinでできるので負担は大きくない。
デメリット
- Open Order Bookと同様の課題が有る。
- リザーブ用に大量のトークンを保有しておく必要がある。
ネクストステップ
それぞれの戦略における法的見解（持論）を書きたいと思っています。専門家の方ともぜひ議論させていただきたいです。