Ethereumブロックチェーン上の分散型取引所のためのプロトコル 0x Project

0x Projectのホワイトペーパーを元に作成しています。

特徴

イーサリアムのブロックチェーン上でERC20規約のトークンの取引をトラストレスにできるようになります。
また、手軽にdApp(分散型アプリケーション)に取引所のような機能を盛り込めるようにもなります。

0xのプロトコルをベースにdAppを構築すると、公共の資金プールへのアクセスと独自の資金プールの構築が可能になります。
そのようなdAppは利用者に対して、取引額に応じて手数料を請求することもできます。

背景

イーサリアムのスマートコントラクトが誕生で、今までできなかった他のブロックチェーン(トークン)との取引も可能になりました。
一方で、中央集権的な取引所ではGOXする可能性があり、実際にGOXしている取引所もいくつかあります。

0xはイーサリアムネットワーク上の分散型取引所のためのオープンプロトコルです。
スマートコントラクトのアクセスシステムを利用しているので、複数のdApp上で共通のインフラのように動作することが可能です。
オープンプロトコルは、dAppのユーザーからは認知されないようにdApp内に取り込むことができます。

オープンプロトコルはdAppのユーザーに認知されない

既存の分散型取引所

中央集権型取引所では発注を変更したり、キャンセルしたりしてもガス料金は不要ですが、分散型取引所での取引ではオーダーの変更とキャンセルではガス料金が発生します。
それは、中央集権型取引所とは異なり、分散型取引所の多くはオーダーをする度にブロックチェーンに書き込む形態(オンチェーン)だからです。

AMM(Automated market maker)

オンチェーンの売買板(オーダーブック)の代わりに取引金額調整モデルを使ってオフチェーンで取引をします。
取引金額が提示されているため、いつでも取引できますがその分スプレッドが追加された価格となるので、既存の取引所と比べると悪い価格(買い手にとっては高く、売り手にとっては安く)となります。

State channels

チャンネルの参加者間で行われた取引はチャンネルが閉じるまでオーダーブックに書き込まれないようになっています。
しかし、全員がオンラインで取引しなくてはいけない上に、参加者全員を信頼しなければいけないという問題があります。

仕様

全体像

0x 全体像

0xでは、オフチェーンでオーダーのやり取りをして、決済の時はオンチェーンで行います。

まずはじめにMakerがDEXからのアクセスを許可し(1)、Makerが取引レートと取引の有効期限を含めたTokenAとTokenBの交換のオーダーを作成して(2)、任意のコミュニケーションツールでオーダーにブロードキャストします(3)。

次に、Takerはオーダーを受け取り、取引をするか決めます(4)。

取引に応じる場合はDEXがTakerのTokenBにアクセスすることを許容します(5)。

そして、DEXにMakerのサインがあるオーダーを提出し(6)、DEXがサインの有無や取引の有効期限が切れていないこと、オーダーがまだ実行されていないことを確認して取引を実行します(7)。

Point-to-Pointオーダー

Point-to-Pointオーダーは二者間での取引です。
取引は任意のコミュニケーションツールで実行されます。

任意のコミュニケーションツールにはemailやFacebook message、whisperなどが利用されます。
フォーマットは以下のような構成になっています。

table1

ブロードキャストオーダー

オンチェーンの取引所での取引はオーダーの作成や実行にお金がかかります。
現在使われているプロトコルでは、この費用を支払うインセンティブ設定がなされていません。

そこで、ブロードキャストを通じてオーダーする手法を取り入れることで、全ての取引に手数料のインセンティブ設計を見直すことができます。
取引所の場合だと、取引所自身はトレードを行いませんが、ブロードキャストの場合はオーダーブックを調整する人も手数料を受け取るために取引に参加するためトラストレスに取引を実行できます。
取引に参加するRelayerは取引の実行をせず、取引の実行をするのはTakerです。

Point-to-Pointオーダーとの違いはTakerが誰になるか決まっておらず、任意のTakerとの取引となるところです。

figure3

取引の流れは、まずRelayerが取引のスケジュールとトランザクションの手数料の受け取りアドレスを提示します(1)。

MakerがfeeA(Makerが支払う手数料)とfeeB(Takerが支払う手数料)を決め、秘密鍵でサインしてオーダーを作成します(2)。

そして、MakerはサインしたオーダーをRelayerに送り(3)、Relayerがオーダーに異常がないか、要求する手数料を満たしているか確認し、満足のいくものだった場合はオーダーブックに書き込みます(4)。

Takerはアップデートされたオーダーを受け取り(5)、Takerは契約を締結してイーサリアムネットワークに提出します(6)。

Point-to-PointオーダーのフォーマットにfeeAfeeBfeeRecipientが追加されます。

table2

手数料はRelayerがオーダーブックに書き込むまでは、自由に変更することができます。
また、手数料の形式も多数あり、固定額割合ベース取引額ベースなどがあります。

自由度は高く、複数のRelayerが一つの取引に参加することも可能です。

スマートコントラクト

イーサリアムネットワーク上のプロトコルとして実装しているので、ガス料金以外の料金は発生しません
取引に複数のTakerによる取引も可能です。

例えば、購入したい金額が大きい時などは、金額を複数のTakerに割り振って取引する方法が考えられます。
既述の通り、Makerにより取引の期日が決められます。

問題点

取引の期日は一度決定してしまうと変更不可能です。
取引をキャンセルする場合もガス料金が発生します。

Makerがキャンセル、Takerが契約履行を同時に行なった場合、どちらかのガス料金が無駄になってしまいます。
これはどちらか一方の取引(キャンセルか契約履行)がマイニングされた時に、もう一方のガス料金が無駄になります。

イーサリアムネットワーク上で取引が増加すればするほど、この問題は顕著になってきます。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です