Contents
インターレジャー・アーキテクチャ
このドキュメントでは、インターレジャー・アーキテクチャの概要を説明し、異なるレイヤーが互いにどのように関係しているかについて説明します。
インターレジャー・アーキテクチャは、RFC 1122、RFC 1123およびRFC 1009で説明されているインターネット・アーキテクチャに大きな影響を受けています。
これは、たたき台の案です。この文書で作られた選択肢は、単に出発点として意図されています。
イントロダクション
このドキュメントは、インターレジャー・アーキテクチャとプロトコル群の概要を提供することを目的としています。
インターレジャー・アーキテクチャ
すべての電信振替はステートフルなシステムに記録する必要があります。そうしないと、資産の同じインスタンスが2つの異なる宛先に送信され、本質的に資産が複製されます。これは二重支払いとも呼ばれます。これらのステートフルなシステムをレジャーと呼びます。
レジャーはアカウントで構成されています。アカウントとは、通常は（必ずしもそうではないが）一つの所有者に関連付けられた1種類の資産の十進数の金額を含む個々のバケットです。この金額はアカウントの残高とも呼ばれます。残高は、資産または負債を表す正数または負数です。
資産は同じレジャーのアカウント間で移動することができます。 私たちはこれらのイベントを帳簿振替または単に送金と呼んでいます。
レジャー間での資産の移転には、複数のローカル帳簿振替が必要です。 いくつかのシステムは、2つの送金の関係を把握している必要があります。 このシステムをコネクタと呼びます。 同じシステムがレジャーとコネクタの両方として機能することがあります。
インターレジャーは、独立した多様なレジャーのネットワークです。 各アカウントは特定のレジャーの一部です。 インターレジャー自体は概念的なものに過ぎません。
アーキテクチャ上の前提
レジャーに含まれる資産の種類は1つだけです。
1つのレジャー内のすべての資産が代替可能であると仮定します。 1つのレジャー内では、送信者から受信者に直接送金することができ、サードパーティーの両替人を必要としません。
銀行などの単一の組織が、異なる種類の複数の異なる資産のアカウントを管理する場合、私たちは各資産をそれぞれのレジャーに属するものとして扱います。
コネクタは、送金の状態情報を保持しません。
インターネット・ゲートウェイが接続の状態情報を保持しないのと同じように、コネクタは送金の状態情報を保持しません。すべての状態はレジャーレベルで維持され、コネクタは単にレジャーイベントに対して反応したりトリガーとなります。
これは、すべてのコネクタが必ずステートレスであることを意味するわけではありません。それは、利用可能な流動性を追跡したり、サードパーティーに代わって取引している場合は内部レジャーを保持することさえできます。しかし、私たちはそれらが送金に関する信頼できる状態を維持しないと仮定しています。
ルーティングの複雑性はコネクタ内になければなりません。
ルーティングは複雑で難しい問題であり、システムのエンドユーザーではなく、コネクタで実行する必要があります。重要な目的は、ユーザーソフトウェアを、インターレジャーのルーティング・アーキテクチャの必然的な進化によって引き起こされる変化から隔離することです。
システムは、幅広いレジャーのバリエーションを許容しなければなりません。
インターレジャーの設計の基本的な目的は、広範囲のレジャーの特性を許容することです — 例えば スループット、待ち時間、手数料、アクセス制限、信頼性、分散化。 さらに、すべてのタイプの異なる資産特性をサポートする必要があります — 例えば 可分性、代替性、利息/償還金、発行。
インターレジャー・プロトコル群
インターレジャー・アーキテクチャは4つのレイヤーに分かれています:
アプリケーション層
アプリケーション層は、インターレジャー・プロトコル群の最上位層です。 このレイヤーのプロトコルは、支払いの基本性質の交渉を担当します:
- 送り元アカウント
- 宛先アカウント
- 金額
- 条件
これらのパラメータが決定されると、アプリケーション層プロトコルは、支払いを開始するためにトランスポート層プロトコルをインスタンス化します。
アプリケーション層プロトコルには、Open Web Payment Scheme（OWPS）などのオープンプロトコルやRPSP（Ripple Payment Services Protocol）などの独自のプロトコルが含まれます。
トランスポート層
トランスポート層は、アプリケーションにエンドツーエンドのトランザクションサービスを提供します。 現時点では、3つの主要なトランスポート層プロトコルがあります:
- オプティミスティック・トランスポート・プロトコル（OTP）
- ユニバーサル・トランスポート・プロトコル（UTP）
- アトミック・トランスポート・プロトコル（ATP）
OTPは、エスクローの保護なしで単に資金を転送するシンプルなトランスポート・プロトコルです。 したがって、効率が信頼性よりも重要な非常に小さなマイクロトランザクションにのみ適しています。
UTPは、エスクローされたトランスファーを使用して、トランザクションが正常に完了していない限り、送金者のアカウントから資金が出ないことを保証します。 任意のサイズのトランザクションに適しており、デフォルトの選択肢とみなされるべきです。
ATPは、複数のレジャー間のアトミック性を保証するために、エスクローされたトランスファーと事前に合意された信頼できる公証人のセットを使用します。 セットアップは比較的高価ですが、調停の必要性を減らすために使用できます。
インターレジャー層
インターレジャーのすべてのトランスポートプロトコルは、送金リクエストについてコネクタと通信するためにインターレジャー・プロトコル（ILP）を使用します。 これには、見積もりのリクエスト、または別のレジャー上の送金のリクエストが含まれます。
インターレジャー層は、レジャー、アカウント、金額を参照する標準的な方法を定義します。 これは、ルーティングに使用されるだけでなく、見積もりを比較できるようにするためにも使用されます。
レジャー層
レジャー間の送金を容易にするために、レジャーはいくつかのAPIまたはプロトコルを実装する必要があります。 これをレジャー層と呼びます。 多くの異なる種類のレジャーに対応する多種多様なレジャー層プロトコルがあります。
レジャー層
イントロダクション
レジャー・プロトコルは、インターレジャー・トランザクションを構成する個々の送金を実行する責任があります。それらはまた、相互に通信するためにコネクタによって使用されます。レジャー層プロトコルは、レジャーの種類によって大きく異なる場合があります。例えば、セントラルレジャーは、ブロックチェーンとは異なるプロトコルを使用する可能性が高いですが、インターレジャーの目的では、両方ともレジャーであり、このアーキテクチャで定義されている同じプリミティブなオペレーションを使ってアクセスできます。
要件
ミニマルサポート
最低限のインターレジャーのサポートのために、レジャーはあるアカウントから別のアカウントに資金が移動する能力を持っていなければなりません。これにより、OTPトランザクションがこのレジャーを通過することができます。また、レジャーのUTPトランザクションとATPトランザクションを有効にするために、第三者がエスクロー・プロバイダとして振る舞えるようにします。
ベーシックサポート
基本的なインターレジャーのサポートのために、レジャーはミニマルサポートと次の要件を満たす必要があります:
レジャーは暗号エスクローを提供する必要があります。エスクローは、送金が4つの状態を持つことができることを意味します:
- Proposed — まだ何も起こっていない。
- Prepared — 資金はエスクローに保有されている。
- Executed — 送金が完了。
- Rejected — 送金がキャンセルされた。（そして、資金が送金者に返却された。）
ヒント: エスクローは、2フェーズコミットと同等の財務です。
レジャーは、エスクローのリリースを自動的にトリガするために、シンプルなSHA-256ハッシュロックの暗号エスクロー条件を検証できる必要があります。また、エスクローされた送金を自動的にロールバックするために、タイムアウトを許可する必要もあります。
レジャーは、各送金に短いメッセージまたはメモを添付することをサポートする必要があります。
フルサポート
レジャーはベーシックサポートと次の要件を満たす必要があります:
「推奨」ステータスで、すべての暗号条件のタイプをサポートする必要があります。
貸方と借方のアカウントのために追加されるメモを別々にサポートしなければならず、かなり大きなメモサイズをサポートする必要があります。
レジャーに接続されているコネクタを検出する方法をサポートする必要があります。
条件ハッシュによって履行を調べる方法をサポートする必要があります。レジャーが既にフルフィルメントを知っている実行条件を持つ（まだpreparedではない）新規送金は自動的に拒否すべきです。これは、UTPエラー・リカバリーに役立ちます。
プロトコルの例
シンプル・レジャー・プロトコル（SLP）
Simple Ledger Protocol（SLP）は、完全なインタレジャーのサポートに必要な最小限の機能を提供するために特別に開発された、RESTfulなJSONベースのプロトコルです。
SLPを使用するレジャーのリファレンス実装は、ここで見つけることができます。
ブロックチェーン・プロトコル（例 Bitcoin）
ブロックチェーンは、シングル・シャアード・ステートでコンセンサスを提供する分散型ピアツーピア・システムです。エスクローされた資金移動をサポートするブロックチェーンは、原則として、インターレジャーに接続されたレジャーとして機能することができます。
例えば、Bitcoinは、複数の貸方と借方をサポートし、SHA-256ハッシュロックされたエスクロー・トランスファーをサポートしているため、OTP/ILPとUTP/ILPインターレジャー・トランザクションに参加することができます。BitcoinのBIP-65拡張提案は、ベーシックレベルのサポートに必要なタイムアウトを提供します。
レガシー・プロトコル（例 ACH, ISO 20022）
レガシー・プロトコル（従来のプロトコル）では、しばしばエスクロー機能は提供されません。この場合、プロトコルをアップグレードするか、または非常に信頼できる参加者（例えば銀行）がエスクロー・プロバイダとして機能することができます。
プロプライエタリ・ウォレット・プロトコル（例 PayPal API）
多数のプロプライエタリなレジャーが存在します。これには、ウェブベースのウォレットやモバイルウォレットが含まれます。これらのタイプのシステムは通常、それらをインターレジャーに接続するために、それらのオペレーターによって暗号エスクロー機能を拡張することができます。
その他のプロプライエタリ・プロトコル（例 Skype API）
独自のプロトコルの中には、意図的に通常のレジャー機能を提供しないものもあります。一般的な例は、ギフトカード、ロイヤリティポイント、プリペイドアカウントなどのストアドバリューシステムです。そのようなシステムは限られたキャパシティの中でインターレジャーに接続することができます。例えば、プリペイドアカウントのレジャーは、受け取りレジャーとして機能するように設定できますが、送金または仲介レジャーとしては機能しません。
リセラーとエンドユーザーの2つのクラスのユーザーを作成し、送金者がリセラーであり、受取人がユーザーである場合にのみ送金を許可することにより、加盟店はストアドバリューシステムのように動作するインターレジャー対応のレジャーを作成できます。そのようなシステムは預金はできますが、引き出しができません。
インターレジャー層
イントロダクション
インターレジャー・プロトコル（ILP）は、異なるコネクタが相互運用可能であり、相互に連携してトランザクションをルーティングできることを保証します。
プロトコル
インターレジャー・プロトコル（ILP）
インターレジャー・トランザクションを開始するとき、送信者はローカルのレジャー層プロトコルを使用してコネクタに転送します。送信者は、この転送に、受信側のコネクタに最終宛先、送金される金額、および該当する場合は条件を通知するILPパケットを含めます。
このデータ・パケットを転送する正確な方法は、レジャー層プロトコルに依存することに注意してください。通常は、memoフィールドのトランスファーに含まれます。しかしながら、いくつかのレジャーは、ILPパケットの転送に異なる方法を指定するかもしれません。
インターレジャー・キューイング・プロトコル（ILQP）
インターレジャー・トランスファーが行われる前に、送信元は同じレジャーに接続されているコネクタから見積もりを要求します。これらの見積もり要求は、インターレジャー・キューイング・プロトコル（ILQP）を介して行われます。
送信者は見積もりをキャッシュして、同じコネクタを介して繰り返しトランスファーを送るかもしれません。
インターレジャー・コントロール・プロトコル（ILCP）
インターレジャー・コントロール・プロトコル（ILCP）は、ルーティング情報を交換し、支払いエラーを通知するためにコネクタによって使用されるプロトコルです。
TODO: add link
トランスポート層
イントロダクション
トランスポート層プロトコルは、インターレジャー・トランザクションを構成するさまざまな送信を調整する責任を負います。トランザクションの参加者に与えられる安全保証は、使用されるトランスポート・プロトコルのタイプに応じて変化します。
プロトコル
オプティミスティック・トランスポート・プロトコル（OTP）
オプティミスティック・トランスポート・プロトコル（OTP）は、トランスポート・プロトコルの簡単なケースです。単に次のコネクタに転送するだけです。コネクタは、要求された転送を行うことも、行わないこともあり、送信者はいずれにしてもお金を出します。
ほとんどの場合、OTPは適していません。しかし、若干のトランザクションが失われることが大きな問題とはならない反復的なマイクロトランザクションの場合には、意味を成すかもしれません。
TODO: Need to figure out how OTP can detect dropped transfers and adjust the route accordingly.
ユニバーサル・トランスポート・プロトコル（UTP）
ユニバーサル・トランスポート・プロトコル（UTP）は、標準で推奨されるトランポート・プロトコルです。これは、資金の配送を確実にするために、エスクローされたトランスファーのカスケード・チェーンをセットアップします。
プロトコル・フローは、インターレジャーのホワイトペーパーで説明されています。
エラー・リカバリー
UTP実行チェーンは、コネクタが条件フルフィルメントの配信に失敗した場合に中断することができます。その場合、送信者はトランザクションが失敗したと思って再試行します。再試行中、一部のコネクタは、対応するフルフィルメントを既に知っているレジャー上で Prepared のトランスファーを作成しようとします。これにより、リクエストが失敗します。コネクタはこれに気付き、何も支払わずにフルフィルメントを単に返信します。
つまり、失敗したコネクタはお金を失い、他のコネクタはお金を得ることになりますが、送信者と受信者の観点からはすべて正常に実行されています。
アトミック・トランスポート・プロトコル（ATP）
アトミック・トランスポート・プロトコル（ATP）は最も保守的ですが、標準的なインターレジャー・プロトコルの中でも最も複雑でもあります。レジャーとコネクタに加えて、公平な公証人のセットが含まれています。公証人は、トランザクションに関わる送信者、受信者、コネクタによって合意されなければなりません。
各パーティーは独自に信頼できる公証人のセットを選ぶので、重複はなく、もしあればATPを使用できません。公証人は、自動プロセスを使用して選択することも、参加者間で契約を立てたグループによって事前に選択することもできます。
プロトコル・フローはインターレジャーのホワイトペーパーで説明されています。
サブプロトコルとして
ATPは、UTPトランザクションの一部のサブプロトコルとして使用できます。これは、コネクタが次のホップとしてATPトランスファーを作成することを決定したときに起こります。それは領収書を渡すことができなくなるリスクと公証人が失敗するリスクの両方を負います。これは次のコネクタが、UTPトランスファーよりもATPトランスファーの方がより良い価格を見積もる場合には意味があります。
同様に、コネクタが次のホップにUTPを使用することを決定すると、ATPトランザクションはUTPトランザクションに変わります。それは公証人に領収書を渡すことができなくなるリスクを負います。これは、ATPが利用できない場合には意味があります。
アプリケーション層
イントロダクション
アプリケーション層プロトコルは、支払いの詳細の交換および関連する交渉を取り扱います。
シンプル・ペイメント・セットアップ・プロトコル（SPSP）
シンプル・ペイメント・セットアップ・プロトコル（SPSP）は、支払いの詳細を交渉するためのアプリケーション層プロトコルです。SPSPは、アカウントと金額の発見、条件作成、見積もり、セットアップを扱います。SPSPはWebfinger（RFC 7033）とHTTPベースのプロトコルを使用してアカウントと金額の詳細を照会し、見積もりにはILQPを、支払処理にはUTPを使用します。
プロトコルは IL-RFC 9 で説明されています。
他のアプリケーション層プロトコルを定義する
他のアプリケーション層プロトコルの作成者は、次の点を考慮する必要があります:
- Account discovery
- Amount and condition communication
- Additional details communicated in memo
- Condition types supported or required
- Transport protocol
- Incoming payment validation (amount, condition, etc.)
注意:
本ドキュメントは、GitHubで公開されている『Interledger Architecture』を私が個人的に翻訳したものです。注意して頂きたいのは、当方は現役のエンジニアではありませんし、Rippleについての技術的な探求心があるわけでもありません。誤訳などの間違いがあるかもしれないため、公式サイトの英語で書かれた原文もあわせて読むことをお勧めします。
＞＞XRPの価格をチェック