マーケットメーカーのためのRipple

翻訳にあたって

『マーケットメーカーのためのRipple』は、リップル社が公式サイトで公開している『Ripple for Market Makers』を私が独自に翻訳したものです。誤訳などの間違いがあるかもしれないため、公式サイトの英語で書かれた原文もあわせて読むことをお勧めします。

原文：Ripple for Market Makers

概要

この文書は、Rippleネットワーク上でマーケットメーキングを行うための基本的な手引きを提供します。どのユーザーも手動でRipple上で通貨やその他の資産を売買するために、買いと売りの注文を出すことができます。機関投資家は、市場で有利に競争するために彼ら独自の自動化された取引戦略を開発するでしょう。

あなたは、この文書を読み進める前に、Rippleを大まかに理解するためにRippleプロトコル入門から先に読むことを望むかもしれません。

Rippleとは?

Rippleは分散型の決済システムであり、分散型の為替システムです。Rippleは通貨に依存しません。独自のネイティブ通貨であるXRPを含むすべての通貨（USD、EUR、BTCなど）をサポートします。

そのコアであるRippleネットワークはユーザーのアカウント、残高、取引に関する情報を記録する分散型のデータベースです。データベース内のこのレコードは、Rippleレジャーとして知られます。

Rippleレジャーは、銀行がアカウントや残高を管理するために一般的に利用しているデーターベースに似ています。しかしながら、中央集権化された独占的な銀行の台帳とは違い、Rippleのデータベースは、すべてのユーザー間でグローバルに共有されたコンピューターを横断して分散化されています。セントラル・オペレーターも単一障害点もありません。

世界中のRippleサーバーにより構成されるピアツービア・ネットワークが台帳を管理します。これらのサーバーは、（Ripple daemonの省略である）『rippled』として知られるソフトェアを走らせます。

各rippledサーバーは、現在の台帳の完全なコピーを各自に保有します。このようにして、誰もが台帳を閲覧したり、Rippleネットワーク上のすべてのアクティビティのレコードをみることができます。

ちょうど伝統的な銀行のネットワーク上で行われていたように、取引や決済は台帳に対する有効な変更を行うことでRipple上で実行されます。中央集権化されたネットワークオペレーターを信頼する代わりに、世界中のサーバーが台帳への変更に関して相互にコンセンサスを取り、全サーバーが常に整合性を維持するためにデータベースのそれぞれのローカルコピーを更新します。

Rippleは完全にオープンソースなので、誰もがコードを監査、改修し、いかなる団体の承認を得ることなく、あらゆる目的のためにそれを使用することができます。（但し、ユーザーは居住地域の法規制に従う必要はあります。）

ゲートウェイとRippleネットワーク上の残高

通貨はゲートウェイを通じてRippleネットワークを出入りします。『ゲートウェイ』は、通貨の入金とネットワークへのポイント払い出しをする地点です。

ゲートウェイは、顧客から預金を引き受け、代わりにRippleネットワーク上の残高を発行するビジネスです。これは伝統的な銀行の役割（預け入れと残高発行の受諾）にとてもよく似ています。

Rippleネットワーク

USD.SnapSwap、EUR.Bitstamp、BTC.BitstampなどのRipple上のすべての通貨は、特定の発行ゲートウェイを持ちます。後述するXRPはこの例外です。

ユーザーが換金のためにRippleネットワークから残高の清算によってお金を引き出したいとき、その残高を発行したゲートウェイはユーザーが保有する預け入れに対する清算の責任を負います。

実際のところ、ゲートウェイは伝統的な銀行に非常に良く似たものと見ることが出来ます。しかし、ゲートウェイはRippleネットワークへのアクセスを提供する様々なビジネスに成り得ます。ゲートウェイは、銀行、マネーサービス事業、市場（マーケットプレース）、その他どんな金融機関にも成り得ます。

ゲートウェイに関する詳細：Ripple Gateway Whitepaper

ゲートウェイのカウンターパーティー・リスク

ある機関が発行した残高を保有することは、あなたをカウンターパーティー・リスクの危険にさらします。これはRippleと伝統的な金融システムのどちらにおいても同じです。

金融危機で私たちが学んだように、チェースのドル預金残高とキプロス銀行のドル預金残高は必ずしも等価ではありません。預金残高は事実上、単なる銀行やゲートウェイの預金者への払い戻しの約束に過ぎません。銀行は彼らの顧客への返金の義務を負っているのです。これはしばしば虚飾されるが、銀行預金残高（そしてRipple上のゲートウェイの残高）は厳密には負債の手形です。

ユーザーは信用してお金を貸せるゲートウェイの預金を保有すべきです。なぜなら、残高はゲートウェイの債務返済の約束以外のなにものでもないからです。

ユーザーは、残高を保有するために手動で特定のゲートウェイに対する『トラストを確立する』必要があります。トラストラインの確立は、あなたがそのゲートウェイのカウンターパーティー・リスクを承諾し、その残高を保有したいという意思をRippleネットワークに知らせます。

トラストラインの確立

トラストは特定の金額が確立されるため、無制限ではありません。あなたはABC銀行で25万ドルまで保有したいかもしれませんが、XYZ銀行では1万ユーロまでしか保有したくないかもしれません。

残高の取引

Rippleユーザーは、ゲートウェイの残高を譲渡することによって、互いに支払いを行うことができます。これにはユーザー同士が直接お互いをトラストする必要はありません。ユーザーは、残高を保有するために互いに共通のゲートウェイをトラストする必要があるだけです。

例えば、USDのためにゲートウェイXYZをトラストする2人は、ユーザー間での直接的なトラストやカウンターパーティー・リスク無しで、互いにUSDでの送金を行うことができます。

もし、あなたが従業員との間で振り込み制度を利用していたなら、あなたはこのシステムに慣れ親しんでいます。あなたは事実上、あなたの銀行への開かれたトラストラインを有しています。これは、あなたの従業員はあなたの銀行に100ドルの返済義務を負わせることで、あなたに100ドルを支払うことができることを意味しています。

XRP: Rippleネットワークのネイティブ通貨

XRP（”リップルズ”とも発音される）は、Rippleネットワークのネイティブ通貨です。ドルやユーロとは違い、XRPは生来のデジタル資産であり、Ripple内にのみ存在します。1000億XRPがRipple Ledger内にプログラムされ、Rippleプロトコルのルール上、それ以上は発行されることがありません。

XRPはRipple内で唯一の資産となる通貨です。Ripple内の他の全ての通貨は残高として存在しており、これはゲートウェイの負債であることを意味します。この資産と負債の違いが数学に基づく通貨の一つの革命的な性質です。

なぜならXRPは負債ではなく資産であるため、ユーザーは第三者のカウンターパーティーリスクを負うことを承諾することなく、USD残高を送金する代わりにXRPで価値の交換を行うことができるのです。

ちょうどEURがUSDに対して自由に交換できるのと同じように、XRPはネットワーク内の他の通貨に対して自由に交換できます。ドル、ユーロ、ポンド、ビットコインなどに対して変動するXRPの市場価格が存在します。価格は需要と供給により変動します。

金やドル紙幣のように、XRPは実態価値を有しません。それは単に誰かがそれで支払いたいと思うだけの価値です。

価値の保存や両替の媒体として、RippleのユーザーがXRPを採用する必要はありません。事実、私たちは殆どのユーザーがXRPを保有せずにUSD、EUR、JPYやその他の伝統的な通貨で取引を続けると予想しています。

では、なぜXRPが作られたのでしょうか？ XRPはネットワークの機能性を支える道具です。それは、ネットワーク・セキュリティとブリッジ通貨の役割という2つの特徴的なネットワーク機能を果たすために存在します。これらのそれぞれの機能については、セクション8と9で論じます。

マーケットメーカーの役割

すべてのユーザーがRippleの分散型取引所で通貨を取引するために買い注文と売り注文を出すことができます。マーケットメーカーは、Bid/Askスプレッドを得るために買いと売りの両方の注文を出すことで市場に流動性を提供します。

マーケットメーカーは、共有されたトラストが存在しない場合に、ユーザー間の決済を手助けする重要な役割をします。下図のマーケットメーカーは、ゲートウェイABCのUSD残高とゲートウェイXYZのEUR残高を両替するために価格を提示しています。

EUR/USD の取引をするマーケットメーカー

この機能を満たすためには、マーケットメーカーは両方のゲートウェイの確立されたトラストラインを有し、残高を保有する必要があります。

USD保有者がEURで送金する

マーケットメーカーを通じた支払いの中継により、Rippleユーザーは彼らが保有しない通貨で互いに支払いをすることができます。私たちの例では、マーケットメーカーがUSD残高を保有するユーザーにEURで支払いをすることを可能にします。

Rippleでは、誰も欲しないリスクに晒されません。マーケットメーカーが価格リスク、カウンターパーティー・リスク、ゲートウェイ間の資産をリバランスするコストを請け負うため、他のユーザーがそれらを請け負う必要はありません。

パスファインディング・アルゴリズム

Rippleのパスファインディング・アルゴリズムは、Rippleネットワークを横断する２通貨間の最も安いパスを探索します。ここで言う『最も安い』が意味するのは、支払いの送金者にとって最小のBID/ASKコストを負うパスです。

パスファインディング: EUR から KRW

流動的な通貨の交差において、最も安いパスは、しばしば1人のマーケットメーカーを通じた直接的な”ワンホップ”のパスになります。しかしながら、Rippleのパスファインディング機能は、たとえそれが複数の媒介通貨を通じたより複雑な経路であっても最も安いパスを探索します。

ユーザーはレギングリスクにさらされません。Rippleは、マルチホップのパスを最小単位の単一のトランザクションとして実行します。なぜなら、Rippleのトランザクションは分散型台帳に対する単なる更新だからです。マルチレッグは、同一のレジャーアップデート中にそれらすべてを含み、同時に実行されることが可能です。

媒介通貨としてのXRP

ゲートウェイの残高は、Ripple内の個別の異なる資産として取引されるため、通貨ペア数はマーケットメーカーにとって直ぐに管理不能になります。各ゲートウェイは独自のUSD、EURを保有するので、潜在的な交差数は膨大になり得ます。

すべての可能な通貨/ゲートウェイの組み合わせの相場を作る代わりに、XRPはマーケットメーカーにとっての便利なブリッジング・ツールとして振る舞うことができます。もし、すべての通貨がXRPに対して流動性を持っているなら、その通貨は他のすべての通貨に対しても流動性を持っています。

XRPとの相場形成のブリッジングは必須ではなく、単に便利な機能です。もしマーケットメーカーが好むのであれば、彼らは直接 EUR.bitstamp/USD.snapswap の相場を作ることができます。

金融市場での『ブリッジ通貨』または『媒介通貨』としてのこの役割は、伝統的にUSDが果たしてきました。Rippleネットワーク内では、XRPを選択する機能的な理由があります。XRPはネイティブな（残高/負債とは対照的な）デジタル資産であるため、XRPはカウンターパーティーのトラストを必要としない唯一のRipple内の資産です。そのため、XRPはマーケットメーカー間で摩擦なく交換することができるのです。さらに、カウンターパーティーを持たないため、XRPにはそれに付随するサードパーティー手数料がかかることがありません。

媒介通貨としてのXRP

Ripple内のXRPは、あなたの手の中にあるゴールドのようなものです。XRPはカウンターパーティーのない資産であり、外部のゲートウェイ間のブリッジ通貨として役割を果たします。これはFX市場におけるUSDの役割に似ています。

XRPはRippleに対してネイティブであり、これはインターネットに対してネイティブであることを意味します。インターネットのように、それはグローバルでボーダーレスです。世界中にXRPを送るために国際的な通貨両替所は必要ありませんし、それに関連するコストの負担もありません。

XRPはネットワークを保護する

ブリッジ通貨としての役割を提供することに加えて、XRPはネットワークを保護する極めて重要な役割を果たします。

Rippleネットワークはアカウントの共有台帳に基づいているため、悪意のある攻撃者がネットワークを過負荷状態するために、（偽装アカウントのような）『レジャー・スパム』や（偽装取引のような）トランザクション・スパムを大量に作成するかもしれません。これは台帳を管理不能なサイズにする原因となり、正当な取引を迅速に処理するためのネットワークの機能を妨げる可能性があります。

台帳への過剰な不正入力からネットワークを保護するために、各Rippleアカウントはレジャー・エントリーを作成するための少額のXRPの予約金を保有することを要求されます。この準備金は現在のところ20XRP必要で、これは（2013年12月現在で）約0.50ドルに相当します。この要求は、潜在的な攻撃者がネットワークを攻撃するための大量の不正アカウントを収集することを防ぎますが、正規ユーザーとっては無視できる金額となるように意図されています。

各トランザクションが処理されるごとに 0.00001XRP（米ドル換算でおよそ10万分の1セント）が破棄されます。これは誰かによって徴収される手数料ではなく、XRPは破棄されて存在しなくなります。このトランザクション手数料もまた、ユーザーにとっては無視できる程度であるように設計されています。しかし、DOS攻撃時のようにネットワークが高負荷になる状況においては、この手数料は急速に上昇します。

この設計の目的は、攻撃者を瞬時に破産させ、ネットワークが円滑に機能のを維持することです。Rippleネットワークに対する攻撃はすぐに高価な代償となりますが、正規ユーザーにとってのコストは事実上『無料』であり続けます。

この設計は、副作用としてXRPの需要に帰着します。ネットワークにアクセスするために、ユーザーは少額ではありますがいくらかのXRPを必要とします。ネットワークが成長すれば、この需要はそれとともに増大します。

実行速度

Ripple内のトランザクションは、クローズされたレジャーに取り込まれる瞬間に実行されるとともに完全に処理されます。新しいレジャーは、おおむね2～20秒ごとにクローズします。私たちは、アクティブな市場においては、レジャーは3秒ごとにクローズされるであろうと予想しています。トランザクションが欠如していても、ネットワークが正常に動作していることと残高が有効であることを証明するために、レジャーは20秒ごとにクローズします。

Rippleは明らかに高頻度プラットフォームではありません。トランザクション待ち時間は、世界中のサーバーが通信して取引と決済に関するコンセンサスを取るために必要とする時間の機能です。

待ち時間の数秒は、超低の待ち時間の金融市場に慣れたトレーダーにとっては永遠のように思われるかもしれませんが、このアーキテクチャは実際にはすべての市場参加者に、物理的な位置ではない、より高いレベルのプレイフィールドを提供します。なぜなら、Rippleの取引はグローバルに分散化されており、中央の取引付近に配置されることによる不公平な速度におけるアドバンテージを得ることができないからです。単純にトレーダーが同一地点に集合する中心点がありません。

つまり、Rippleは他の取引プラットフォームより遅いかもしれませんが、それはおそらく間違いなく既存の取引と比べてより公平なシステムであるということです。

オーダー待ち行列

Ripple上のすべてのオーダーはタイムスタンプを受け取ります。もし、2つのオーダーが同じ指値を持っている場合、早いタイムスタンプが遅いタイムスタンプより高い実行優先順位を得ます。

もし、複数の同じ指値のオーダーが同じタイムスタンプであった場合、それらはアルゴリズム的にタイムスタンプされますが、公平性のため順序は予測不可能です。分散型の取引システム上で、どのオーダーが先になるかを正確に確定することは難しいため、これは必要です。伝統的な中央集権的な取引と同様に、オーダーがそれ以外に競いあう中心的な場所はありません。

統合プロセス

手動取引

私たちは、新規のユーザはRippleの取引の流れを実践的に理解するために、最初は手動取引でのマーケットメーキングに興味を持つことを推奨します。

1. アカウントを作成してXRPを入金する。

2. Rippleゲートウェイへのトラストを確立する。

3. クライアントの取引タブから、オーダーブックに売買注文を出す。

競合のマーケットメーキング機関は、おそらく自動化された方法を使うでしょう。その統合ステップは以下で述べます。

Rippleサーバーを走らせる

殆どのマーケットメーカーは彼ら自身がローカルにホストする rippledサーバーを走らせることを選択します。Rippleサーバーを走らせることは、あなたのビジネスに完全なRippleネットワークへの速くて信頼できる安全なアクセスを提供します。もし、あなたが自身のサーバーを走らせないのであれば、あなたはレジャーへのアクセスのために第三者のサーバーに頼ることになります。

あなたは、RippleのGithubリポジトリで rippled のセットアップのための、ステップバイステップのインストラクションを見つけることができます。

マーケットメーカーはJSONフォーマットでサーバーにコマンドを送ります。rippledサーバーは、自身ですべての必要なピアツーピア・ネットワーク全体の通信を処理します。

ビットコインを生産する可能性のあるビットコインサーバーとは違い、Rippleサーバーを走らせることによる直接的な利益はありません。Rippleサーバーを走らせても直接的にXRPは生産されません。Rippleサーバーは、ネットワークのセキュリティとパフォーマンスの向上を支援することを望む人達だけでなく、ネットワークへの安全なアクセスを求める人達によって運用されます。

RippledサーバーAPI

あなたはサーバーとの情報のやりとりを行うためにJSONメッセージを使用します。メッセージには2つの大きなカテゴリがあります。

1. サーバーやレジャーの現在の状態に関する情報を返すクエリー。

2. サーバーやレジャーの状態を変更するトランザクション。

すべてのJSONメッセージのドキュメントはここにあります。: https://ripple.com/wiki/JSON_Messages JSON
データフォーマットのルールはここに記されています。: https://ripple.com/wiki/JSON_format
トランザクションタイプとフォーマットはここにリストされています。: https://ripple.com/wiki/Transactions
RippleのAPIツールは rippledコマンドとそれに関連するサーバーのリアルタイムのレスポンスの例を提供します。: https://ripple.com/tools/api

Websockets vs RPC

メッセージは、単体のRPCコールを作成するか、または永続的なWebsocketコネクションを開くことのどちらでもサーバーを通過することができます。個別のJSONリクエストとレスポンスは、通信とチャネルの両方で同じデータフォーマットを使います。

Websocketを選択するか RPC を選択するかはマーケットメーカー次第です。その選択は、既存のビジネスサーバーが記述された言語や開発チームのスキルにしばしば依存します。Websocketはよりモダンなインターフェースで、規模が大きいビジネスにより適しています。また、それはユーザーインターフェースの動的なアップデートも可能にします。RPCの静的な性質は、迅速な実験を容易にします。

より高いレベルのインターフェース

ripple-lib

Ripple Labsは、詳細を送るローレベル・メッセージを抜き出したripple-lib と呼ばれる javascriptライブラリを提供します。このライブラリは、Rippleと情報のやりとりを行うブラウザベースのユーザーインターフェースのために役立ちます。また、node.js でビジネスサーバーを記述するのにも役立ちます。

もし、あなたが javascript 以外の言語で開発を行っているのなら、ripple-lib はあなたの実装のベースとなる有益なリファレンス実装の役割をするでしょう。 https://github.com/ripple/ripple-lib

コマンドライン

rippled は、あなたのサーバーへのRPCリクエストの送信を簡略化するコマンドライン・インターフェースも提供します。”verbose”オプションを使ったコマンドの送信は、JSONリクエストの構文を学ぶための簡単な方法を提供します。

Ripple RESTful API

ripple-rest API の利用は、RESTful なウェブインターフェースを通じたRippleシステムへのアクセスを容易にします。殆どのマーケットプロフェッショナルは、前のセクションで述べたWebsocketを通じたRippledサーバーへの直接的なアクセスより、より直感的であるripple-restのシンタックスを求めます。

APIドキュメントはこちらで提供されています。: https://dev.ripple.com/ と https://github.com/ripple/ripple-rest

ripple-restを利用するためには、あなたはripple-rest APIが動作しているサーバーを走らせることと、アクセスすることの両方が求められます。こちらに稼働中のテストサーバーがあります。 https://ripple-rest.herokuapp.com

ripple-rest API はウェブインターフェースのための次の一般的な様式に従います。The ripple-rest API conforms to the following general behavior for a web interface:

HTTPメソッドが、あなたが何をしようとしているか特定します。一般的に、HTTP GETリクエストは情報の取得に使われます。これに対し、HTTP POSTリクエストは情報の変更と送信に利用されます。

あなたはをURL内の要求のリソースを含んだHTTP（またはHTTPS）リクエストをAPIエンドポイントに対してを行います。

もし、より複雑な情報の送信が必要であれば、HTTP POSTリクエストのボディ内にJSONフォーマットのデータとして含めることができます。

最後にサーバーは、200（OK）のHTTPステータスコードと application/json の Content-Type を返します。レスポンスのボディは、エンドポイントによって返される情報を含んだJSONフォーマットのオブジェクトになります。

返されたJSONオブジェクトは、リクエストが成功したかどうかを示すsuccessフィールドを含みます。