Contents
インターレジャー・プロトコル（ILP）
序文
このドキュメントは、インターレジャー・プロトコル（ILP）を規定しています。 これは、RFC 791で定義されているインターネット・プロトコル（IP）の定義から大きく引き出されています。インターレジャー・プロトコルは、分散型決済プロトコルにおける10年以上の研究の成果です。 この作業は2004年にRyan Fuggerによって開始され、2008年にBitcoinの開発によって増補され、その後数多くの貢献者が関わっています。
イントロダクション
モチベーション
今日の決済ネットワークはサイロ化され、分断されています。 一つの国の中において、または送金者と受取人が同じネットワークまたは台帳にアカウントを持っている場合は、決済は比較的簡単です。 しかし、ある台帳から別の台帳への送金ができないことはよくあります。 コネクションが存在する場合は、手動、低速、または高価です。
インターレジャー・プロトコルは、送金者と受取人を中継ぎ障害のリスクから隔離しつつ、異なるデジタル資産の台帳間でのルーティング決済を規定します。 セキュアなマルチホップ決済と自動ルーティングは、異なる種類の価値のネットワークためのグローバルネットワークが、任意の送金者と任意の受取人を接続することを可能にします。
スコープ
インターレジャー・プロトコルは、相互接続された台帳のシステムを介して送金元から宛先への支払いを行うために必要な機能を提供するため、意図的に範囲が限定されています。 これには基礎となる台帳の最小限の要件が含まれており、公開鍵インフラストラクチャー、アイデンティティ、流動性管理、または決済プロトコルで一般的に見られるその他のサービスは含まれません。
インターフェース
このプロトコルは、インターレジャー環境の上位プロトコル・モジュールを介してホストから呼び出されます。インターレジャー・プロトコル・モジュールは、ローカル・レジャー・プロトコルを呼び出して、インターレジャー・ペイメントを次のコネクターまたは宛先アカウントに転送します。
例えば、シンプル・ペイメント・セットアップ・プロトコル（SPSP）モジュールは、インターレジャー・パケット内のアドレスと他のパラメータを使用してインターレジャー・モジュールを呼び出してペイメントを送信します。 インターレジャー・モジュールは、インターレジャー・パケットと共に、与えられたパラメータに従って、次のコネクタまたは宛先アカウントにトランスファーを送信します。 トランスファーおよびインターレジャー・パケットは、次のホストのインターレジャー・モジュールによって受信され、それぞれの連続する各コネクタおよび最終的に宛先のSPSPモジュールによって処理されます。
リップルの場合、例えば、インターレジャー・モジュールは、リップル・コンセンサス・レジャーに送信するためにインターレジャー・パケットを添付したリップル・トランザクションを作成するローカル・レジャー・モジュールを呼び出す。 リップルアドレスは、ローカル・レジャー・インターフェースによるインターレジャー・アドレスから生成され、リップルネットワーク内のいくつかのアカウントのアドレスになります。リップルネットワークは、他のレジャーへのコネクタに属している可能性があります。
オペレーション
インターレジャー・プロトコルの中心的な機能は、ホストのアドレッシングと異なるレジャー間の支払いを安全にすることです。
インターレジャー・ペイメントを送受信する各ホストには、インターレジャー・ヘッダー内のアドレスを使用してインターレジャー・ペイメントを宛先に送信するインターレジャー・モジュールがあります。インターレジャー・モジュールは、アドレスを解釈するための共通のルールを共有します。 モジュール（特にコネクター内）は、ルーティング決定やその他の機能のためのプロシージャも有します。
インターレジャー・プロトコルは、送金者の資金が宛先アカウントに配信されるか、送金者のアカウントに返されることを確実にするためにトランスファー・ホールドを使用します。 このメカニズムについては、概要とインターレジャー・ホワイトペーパーで詳しく説明しています。
インターレジャー・プロトコルは、各インターレジャー・ペイメントを、他のインターレジャー・ペイメントとは無関係の独立したエンティティとして扱います。 コネクションやチャネルはありません（仮想またはそれ以外）。
インターレジャー・ペイメントは、専用の有効期間または残りのホップのフィールドを伝えません。 代わりに、金額フィールドが暗黙的な生存期間として機能します。支払いが転送されるたびに、転送コネクタは入金額からいくらかの手数料を取ります。 コネクタは、インバウンド金額がILPヘッダーの宛先金額よりも少ない（必ずしも数値的に小さいとは限りませんが）価値があることを認識すると、支払いを転送することを拒否します。
定義
トランスファー
一部の資産の所有権の変更
レジャー
トランスファーを記録するシステム
コネクタ
2つのレジャー間のトランスファーを中継するシステム
ペイメント
異なるレジャー上での1つ以上のトランスファーを伴う資産の交換
概要
他のプロトコルとの関係
次の図は、プロトコル階層内のインターレジャー・プロトコルの場所を示しています:
インターレジャー・プロトコルは、一方の側でより高いレベルのend-to-endプロトコルとインタフェースし、他方の側ではローカルのレジャー・プロトコルとインタフェースします。 この文脈では、「レジャー」は、個人または組織が所有する小さなレジャーまたはBitcoinなどの大規模なパブリック・レジャーです。
オペレーションのモデル
ホールドなし（「オプティミスティック・モード」）
プロトコルは、ホールドによって提供されるセキュリティなしで使用されることがあります — 「オプティミスティック・モード」と呼ばれることもあります。ホールドなしでアプリケーションから別のアプリケーションに資金を転送するためのオペレーションのモデルは、次のシナリオで説明されています:
ソースと宛先には、単一のコネクタで接続された異なる元帳のアカウントがあると仮定します。
(1) (11)
Application Application
\ /
(2) (6) (10)
Interledger Module Interledger Module Interledger Module
\ / \ /
(3) (5) (7) (9)
LLI-1 LLI-1 LLI-2 LLI-2
\ (4) / \ (8) /
Local Ledger 1 Local Ledger 2
- 送金側アプリケーションは、金額を選択し、ローカルのインターレジャー・モジュールを呼び出してその金額をペイメントとして送信し、宛先アドレスと他のパラメータを呼び出しの引数として渡します。
- インターレジャー・モジュールは、ILPパケットを準備し、それにデータをアタッチします。 インターレジャー・モジュールは、このインターレジャー・アドレスのためのローカル・レジャー上の宛先アカウントを決定します。 この場合、それはコネクタのアカウントです。 これは、選択された金額とローカルの宛先アカウントをローカル・レジャー・インタフェースに渡します。
- ローカル・レジャー・インタフェースはローカル・レジャー・トランスファーを作成し、このトランスファーをローカル・レジャーに承認します。
- レジャーはトランスファーを実行し、コネクタに通知します。
- コネクタ・ホストのローカル・レジャー・インタフェースは通知を受け取り、それをインターレジャー・モジュールに渡します。
- コネクターのインターレジャー・モジュールは、通知からILPパケットを抜き出し、インターレジャー・アドレスから、ペイメントが2番目のレジャーの別のアカウントに転送されることを決定します。 インターレジャー・モジュールは、そのローカルで利用可能な流動性に従って金額を変換し、宛先ホストに対応する他のレジャーのローカル・アカウントを決定します。 宛先レジャーが同じILPパケットを含むトランスファーを送信するために、ローカル・レジャー・インターフェースを呼び出します。
- このローカル・レジャー・インターフェースは、ローカル・レジャー・トランスファーを作成し、それを承認します。
- レジャーはトランスファーを実行し、宛先ホストに通知します。
- 宛先ホストのローカル・レジャー・インターフェースは、通知を受け取り、それをインターレジャー・モジュールに渡します。
- インターレジャー・モジュールは、ILPパケットを抽出し、そのペイメントがこのホストのアプリケーション用であると判断します。それは、トランスファー・データをアプリケーションに渡します。
- 宛先アプリケーションは、着金の通知を受信し、それに応じてリアクションをする。
ホールドあり（「ユニバーサル・モード」）
プロトコルは、送金者の資金が送信先に配信されるか、送金者のアカウントに返されることを確実にするために、トランスファー・ホールドとともに使用される場合があります。オペレーションのモデルは次の例で説明されています:
(1,21) (11)
Application Application
\ /
(2,20) (6,16) (10,12)
Interledger Module Interledger Module Interledger Module
\ / \ /
(3,19) (5,17) (7,15) (9,13)
LLI-1 LLI-1 LLI-2 LLI-2
\ (4,18) / \ (8,14) /
Local Ledger 1 Local Ledger 2
- 送信側アプリケーションは、より高いレベルのプロトコルを使用して、アドレス、金額、および暗号条件を宛先とネゴシエートします。それは、インターレジャー・モジュールを呼び出して、これらのパラメータを使用してペイメントを送信します。
- インターレジャー・モジュールは、ILPパケットを準備し、ローカル・レジャー・トランスファーを送信するアカウントを選択し、それらをローカル・レジャー・インターフェースに渡します。
- ローカル・レジャー・インターフェースは、暗号条件を含むローカル・レジャー・トランスファーを作成し、ローカル・レジャー上でこのトランスファーを承認します。
- レジャーは、送金者の資金をホールド（保留）します。 — これは、資金をコネクタに転送しません。 — そして、コネクタに通知します。
- コネクタ・ホストのローカル・レジャー・インターフェースは通知を受け取り、それをインターレジャー・モジュールに渡します。
- コネクタのインターレジャー・モジュールは、ILPパケットを抽出し、ペイメントを転送すべきと判断します。 インターレジャー・モジュールは、送金者のトランスファーと同じ条件を含む2番目のトランスファーを送信するために宛先レジャーのローカル・レジャー・インターフェースを呼び出します。
- ローカル・レジャー・インターフェースは、暗号条件を含むローカル・レジャー・トランスファーを作成し、ローカル・レジャー上でこのトランスファーを承認します。
- レジャーは、コネクタの資金をホールド（保留）します — これは、資金を宛先に転送しません。 — そして、宛先ホストに通知します。
- 宛先ホストのローカル・レジャー・インターフェースは、通知を受け取り、それをインターレジャー・モジュールに渡します。
- インターレジャー・モジュールは、ILPパケットを抽出し、そのペイメントがこのホストのアプリケーション用であると判断します。 それは、トランスファー・データをアプリケーションに渡します。
- 宛先アプリケーションは通知を受け取り、条件フルフィルメントを保留し、資金がホールドされていることを認識します。 それは、送金者と何が合意されたかについて、着信したトランスファーの詳細を確認します。 確認が通ると、アプリケーションは条件フルフィルメントを生成し、それをインターレジャー・モジュールに渡します。
- 宛先のインターレジャー・モジュールは、フルフィルメントをローカル・レジャー・インタフェースに渡します。
- ローカル・レジャー・インターフェースは、フルフィルメントをレジャーに送信します。
- 宛先レジャーは、ホールドされたトランスファーの条件に対してフルフィルメントを検証します。 フルフィルメントが有効で、トランスファーが期限切れでない場合、レジャーはそのトランスファーを実行し、宛先ホストおよびコネクタに通知します。
- コネクタのローカル・レジャー・インターフェースは、フルフィルメントの通知を受け取り、インターレジャー・モジュールに渡します。
- コネクタのインターレジャー・モジュールは、フルフィルメントを受け取り、それをソース・レジャーに対応するローカル・レジャー・インターフェースに渡します。
- このレジャー・インターフェースは、フルフィルメントをソース・レジャーに送信します。
- ソース・レジャーは、ホールドされているトランスファーの条件に対して、フルフィルメントを検証します。 フルフィルメントが有効で、トランスファーが期限切れでない場合、レジャーはトランスファーを実行し、コネクタと送金者のホストに通知します。
- 送金者のローカル・レジャー・インターフェースは、フルフィルメント通知を受け取り、インターレジャー・モジュールに渡します。
- 送金者のインターレジャー・モジュールは、フルフィルメント通知を受け取り、それをアプリケーションに渡します。
- 送金者のアプリケーションは、フルフィルメント通知を受け取り、それに応じてリアクションをする。
機能説明
インターレジャー・プロトコルの目的は、ホストが相互に接続された複数のレジャーのセットを介して支払い（ペイメント）をルーティングできるようにすることです。 これは、宛先に到達するまで、あるインターレジャー・モジュールから別のインターレジャー・モジュールに支払いを渡すことによって行われます。 インターレジャー・モジュールは、インターレジャー・システムのホストとコネクタに存在します。 支払いは、インターレジャー・アドレスのインタープリテイションに基づいて、個々のレジャーを通じて、あるインターレジャー・モジュールから別のインターレジャー・モジュールにルーティングされます。 従って、インターレジャー・プロトコルの中心的な構成要素はインターレジャー・アドレスです。
比較的多額の支払いをルーティングする場合、ルーティング・プロセスで選択したコネクタと仲介レジャーは信頼されない可能性があります。 基礎となるレジャーによって提供されるホールドは、このリスクから送金者と受取人を保護するために使用することができます。 この場合、ILPパケットには、暗号条件と有効期限が含まれています。
アドレッシング
インターネット・プロトコルと同様に、インタレジャーは名前、アドレス、ルートを区別します。
“名前は私たちが探すものを示します。 アドレスはそれがどこにあるのかを示します。 ルートはそこに到達する方法を示します。 インターネット・プロトコルは主にアドレスを扱います。 それは、名前からアドレスへのマッピングを行うための、より高いレベル（すなわち、エンド・ツー・エンドまたはアプリケーション）のプロトコルのタスクです。“
インターレジャー・モジュールは、インターレジャー・アドレスをローカル・レジャー・アドレスに変換します。 コネクタとローカル・レジャー・インターフェースは、アドレスをインターレジャー・ルートとローカル・ルートにそれぞれ変換する役割を担います。
アドレスは、ピリオド（.）文字で区切られたセグメントからなる階層構造の文字列です。 現在のアドレス形式を将来のバージョンまたは別のバージョンと区別するために、プロトコル接頭辞 ilp: を使用する必要があります:
ilp:us.bank1.bob
インターレジャーのアドレスをローカル・レジャー・アカウントにマッピングする際は注意が必要です。 アドレスマッピングの例は、「Address Mappings」に記載されています。((TODO))
コネクタ
コネクタは、レジャー間で支払いを転送するインターレジャー・プロトコルを実装します。 コネクタはまた、ルーティングおよび他のインターレジャー制御情報を調整するための Connector to Connector Protocol (CCP) を実装します。
仕様
ILPヘッダー・フォーマット
ここでは、ILPヘッダー・フォーマットのフィールドの概要を示します:
| フィールド | タイプ | 簡単な説明 |
|---|---|---|
| version | INTEGER(0..255) | ILPプロトコルのバージョン（現在は 1） |
| destinationAddress | IlpAddress | 宛先アカウントに対応するアドレス |
| destinationAmount | IlpAmount | 宛先レジャーの資産（通貨）で指定された宛先アカウントが受け取るべき金額 |
| condition | IlpCondition | トランスファーの実行条件 |
| expiresAt | IlpTimestamp | 受取人が応じる最後のトランスファーの最大有効期限 |
version
INTEGER(0..255)
使用されているインターレジャー・プロトコルのバージョン。 このドキュメントでは、バージョン 1 について説明します。
destinationAddress
IlpAddress :== SEQUENCE OF OCTET STRING
階層的なルーティング・ラベル。
destinationAmount
IlpAmount :== SEQUENCE { mantissa INTEGER, exponent INTEGER(-128..127) }
Base 10 でエンコードされた金額。
condition
IlpCondition :== Condition</code>
draft-thomas-crypto-conditions-00 で定義されているバイナリ・フォーマットの暗号条件。
条件付きのトランスファーを処理する場合、レジャーは資金をホールドしなければなりません。資金がホールドされている間、送金者も受取人もそれらにアクセスすることはできません。条件フルフィルメントを受けると、レジャーは、資金が保留され、フルフィルメントがトランスファー条件の有効なフルフィルメントであり、トランスファーがまだ期限切れでない場合、資金を受取人に転送しなければなりません。 （「ユニバーサル・モード」）
条件（コンディション）はオプションのフィールドです。 条件が指定されていない場合、資金はトランスファーの受取人に即座に入金されます。 （「オプティミスティック・モード」）
expiresAt
IlpExpiry :== GeneralizedTime
レジャーは、条件付きのすべてのトランスファーに有効期限のタイムスタンプも含める必要がある場合があります。 レジャーは、有効期限切れのタイムスタンプを持ち、条件を持たないトランスファーを拒否する必要があります。 レジャーは、トランスファーの有効期限に達したかまたは超過し、かつ条件がまだ満たされていないトランスファーを拒否する必要があります。 トランスファーを拒否する場合、レジャーはホールドを解除し、資金を送金者が再度利用できるようにする必要があります。
ネイティブ・レジャー・サポートなしのホールド
すべてのレジャーがホールド・トランスファーをサポートするわけではありません。レジャーがホールド・トランスファーをサポートしない場合、ローカル・レジャー・トランスファーの送信者と受信者は、ホールド機能を実行するために一般的に信頼されたパーティーを選ぶことができます。これには3つのオプションがあります:
- 送信者は受信者を信頼することができます。 送信側は最初のステップで通常のトランスファーを行い、受信側は条件が時間内に満たされていない場合にトランスファーを戻します。
- 受信者は送信者を信頼することができます。 送信者は、トランスファーの意図について受信者に通知します。 受信者が有効期限前に条件のフルフィルメントを提供する場合、送信者は受信者に通常のトランスファーを行います。
- 送信者と受信者は、ローカル・レジャーにアカウントを持つ、相互に信頼できる第三者を任命することができます。 送信者は、中立的な第三者のアカウントに通常のトランスファーを行います。 最初のステップでは、中立的な第三者に属するアカウントに資金が移転されます。
ペイメント・チャネル
付録A: ASN.1 Module
付録B: IANA Considerations
ヘッダー・タイプ・レジストリ
The following initial entries should be added to the Interledger Header Type registry to be created and maintained at (the suggested URI) http://www.iana.org/assignments/interledger-header-types:
| ヘッダー・タイプID | 説明 |
|---|---|
| 0 | Interledger Protocol (ILP) |
| 1 | Optimistic Transport Protocol (OTP) |
| 2 | Universal Transport Protocol (UTP) |
| 3 | Atomic Transport Protocol (ATP) |
| 4 | Interledger Quoting Protocol (ILQP) |
注意:
本ドキュメントは、GitHubで公開されている『Interledger Protocol (ILP)』を私が個人的に翻訳したものです。注意して頂きたいのは、当方は現役のエンジニアではありませんし、Rippleについての技術的な探求心があるわけでもありません。誤訳などの間違いがあるかもしれないため、公式サイトの英語で書かれた原文もあわせて読むことをお勧めします。
＞＞XRPの価格をチェック