世界で一番分かりやすい Interledger Protocol

世界の支払いを変える技術

前書き

2017年11月20日、東京・大手町で開催された Ripple’s Interledger Workshop Tokyo に参加してきました。元々、仮想通貨まわりに興味があったので関連技術である Interledger Protocol（以下 ILP）にも関心があり、実際に開発をしている Stefan Thomas や Adrian Hope-Bailie らのエンジニアの話を聞く事ができるという事で楽しみにしていました。

せっかく参加したので、この面白い技術を広く知ってもらいたいという思いでイベントで語られた内容を織り交ぜて ILP とは何なのか、ILP がどの様な未来を作るのかについて世界で一番分かりやすく書き残してみる事にしました😂

前提知識としては、「仮想通貨（暗号通貨）」が何かはおおよそ分かる、というレベルを想定しています。仮想通貨自体が全くわからないという方にはやや難しいかもしれませんので、それっぽいサイトで勉強される事をおすすめ致します。技術的な事はできるだけ噛み砕いて、しかしできるだけ省略せずに説明したいと思いますので、もし何か分からない部分があればお教え頂ければと思います。また、RFC（仕様書） やサンプルコードを確認しながらできるだけ間違いがない様に書いたつもりですが、もし何か事実として間違っている部分がありましたらこちらもお教え頂ければ幸いです。

なお、下記の様な章立てで書き進めたいと思います。

• ILP とは何か
  そもそも ILP とは一体何なのかの概略を記述します。
• 何故 ILP が必要なのか
  何故 ILP が必要なのか、この技術の存在価値、ILP が作る未来と世界観について記述します。
• ILP はどの様に機能しているか
  ILP がどの様に機能しているのか、概略よりももう少し詳細に記述します。
• ILP の広がり
  ILP は様々なところで応用が検討されており、その一例をワークショップで紹介されたプロダクトの概略を織り交ぜて記述します。
• その他のレポート
  Interledger Workshop には様々な方が参加されていたので、他にもレポートをアップされている方がいらっしゃいます。合わせて見てみると面白いと思います。

ILP とは何か

そもそも、今回参加したのは ILP と呼ばれるプロトコルについてのワークショップだった訳ですが、ILP とは何なのか一言で言うと

「異なる台帳間で価値の移動を行うためのプロトコルである」

という事になります。ただ、これだと全く何の事だか分かりませんね😂 なので、ブレークダウンして説明します。

先ずは「プロトコル」についてご説明します。プロトコルとは何なのかと言うと、データをやり取りする順番や内容を予め決めたもの、という事になると思います。つまり、人間同士も何かのやり取りをする際に共通の言語がないと会話ができない様に、コンピュータ同士もいつどういう内容をやり取りするかが決まっていないと意思疎通を行う事ができません。例えば、お金を移動したいと思ったら「誰に」「いくら」を送るか、といった内容を特定の書式に則って情報として渡してあげなければお互いに正しく処理できません。片方は「誰に」送るのかの情報が欲しいと思っている時に「いくら」送りたいかの情報を送られても困りますよね。この様な特定の書式、決まりの事をコンピュータ用語で「プロトコル」と呼んでいる訳です。よく知られている HTTP は Hypertext Tranfer Protocol の略で、直訳すると「ハイパーテキスト（サイトの記述データ）の転送のための取り決め」で、インターネットのサイトの情報をやり取りするためのプロトコルです。

次に「異なる台帳間で価値の移動を行う」という部分ですが、そもそも「台帳」ってなに？となると思います。簡単に言えば、「口座（領域とその所有権）」があり「残高」がある様なシステムを台帳と呼んでいます。例えば銀行口座の情報を保持しているシステムは台帳と呼べるでしょうし、ビットコインのシステムもあなたのアドレス（＝口座）があり、残高があるので、台帳と呼べるでしょう。Interledger の名前にもある様に、台帳はレジャー（ledger）とも呼ばれます。

最後に「異なる台帳間で価値の移動を行う」ですが、例えばこの様なケースを考えてみましょう。A さんは B さんに支払いを行いたいと思っています。しかし、A さんが持っているのはビットコイン。B さんが望んでいるのは円だったとします。B さんは銀行口座を持っているものとします、言い換えるとどこかの銀行の台帳に口座があります。この時、二人は「異なる台帳」に口座がある、という事になります。

• A さんはビットコインの台帳に BTC を保持している
• B さんはどこかの銀行の台帳に円を保持している

という様な状況で、A さんが B さんに支払いを行うにはどうしたらよいでしょうか？ここで登場するのが ILP です。ILP が両者の台帳の間に入り、どの様に価値（残高）のデータを移動すればよいのかを取り持つ事で、お互いの価値の交換を可能にするという訳です。その詳しい方法については後述しますが、めでたく、A さんは BTC しか持っていないのに、B さんに円の支払いができる様になります。なんという事でしょう…😂

この様なプロトコルが、現在 Ripple 社のエンジニアやその他のメンバーにより、W3C で策定中になっています。W3C とは、World Wide Web Consortium の略で、ウェブ関係の仕様の標準化を行う世界的な組織です。実は私も興味があったので Interledger の Community Group に参加しています。個人でどういった形で貢献できるのか分かりませんが、何か貢献していきたいなと思っています。

何故 ILP が必要なのか

そもそも、何故この様なプロトコルが必要なのでしょうか。それは、一言で言うなれば

「お互いに持っている価値を交換しづらい」

という事になると思います。同じレジャー内であれば送信元口座から価値をマイナスして送信先口座の価値をプラスすればよいので価値の移動は簡単ですが、それがレジャーを超えると大抵の場合は時間的、金銭的なコストがかかりますし、レジャーをまたぐと通貨の単位が違う可能性もあります。まして国を超えた場合、最悪な場合は途中で行方不明になったり、とても不便なものとなっています。

Interledger Workshop では、次の様な例が参考として挙げられました。タンザニアの某さんは Airbnb でホストをしてお金を稼いでいた訳ですが、時には 60% 程度しか手元に残らないという事が起きていました。国際送金（レジャーや通貨の単位を越えた送金）にコストがかかっていたためです（タンザニアではわずか 2% の人しか銀行口座を持っていませんが、某さんはそれに含まれていた）。

“Airbnb sent $29 and I received only $9”

仮に某さんの銀行のレジャーが ILP に対応していたとしたら、某さんはその様な高い手数料を払う事なく稼ぎを得る事ができたはずです（厳密には ILP でも多少の手数料はかかります）。

ここで、２つの批判的視点で見てみます。

1. PayPal でいいではないか
   では PayPal にすればよいではないかという話もありますが、PayPal には送金のみしかできない地域というものが存在しており、タンザニアはその地域で、お金を受け取る事ができないのです。
2. 仮想通貨（暗号通貨）にすればいいではないか
   もう１つのクリティカルな視点としては「じゃあ仮想通貨（暗号通貨）にすればいいではないか」というものがあると思いますが、それも現実的には難しい解になります。何故なら１つの（仮想）通貨を世界中の全ての人が使うという事は現実的には難しいからです（理想的だとはしても）。世界にはいくつもの法定通貨があり、仮想通貨もあり、様々な価値を保有している人々がいます。その様な人々から、シームレスに支払いを受け付けたいのです。

つまり、様々な価値を持つ人々を１つの価値観（通貨）に縛り付けず、多様性として受け入れる器が、「異なる台帳間で価値の移動を行う ILP である」という訳です。Airbnb ではこの様な多様性への考え方として #weaccept を標榜していますが、ILP はその概念を体現する事をサポートする事になるでしょう。

少し視座を変えて、マイクロペイメントという考え方があります。非常に少額の決済を指し、非常に細かい単位の従量課金や UGC（User Generated Contents、何かのシステム上のユーザー自身が作ったコンテンツ）と相性のよい考え方です。

例えば、何か有益なサイトを見る時に 1 円、何か有益なイラストを得る時に 100 円、といったイメージです。これまではある程度の量・まとまりや期間に対して、まとまった支払いを行うというのが普通でした。何故なら決済はそれなりにコストも時間もかかるので、まとめて行った方がよかったからです。

しかし、ILP を使えば（コネクタの手数料が十分小さいという前提で）マイクロペイメント、しかも通貨を跨いだマイクロペイメントが可能になります。例えば私が海外の誰かのサイトを見る時に $0.01 を円で支払う、といったイメージです。アフリカの誰かがチーターの狩りをストリーミングして、言葉は同時通訳の字幕、これを10分1円で視聴する。ワクワクしますね。見てみたいです。支払いのためにわざわざカードを登録して…1000円払って…となると二の足を踏んでしまいますが、ブラウザでワンクリックで1円だったら？私だったら見ると思います。そんな人は世界に1万人くらいはいそうな気がしますし、そうするとこのストリーマーは10分で1万円を得る事ができます。なんだかこのサービス自分で作りたくなってきました😂

インターネットにより情報は流通する様になりました。次に価値もインターネットにより繋がったら、価値あるコンテンツを提供できる人が世界中から評価され、相手の通貨が何であろうと、自分が普段使う通貨で対価を得る事ができる。世界中の価値あるサービスを通貨に関係なく享受する。そんな世界がもうすぐやってくるでしょう。この様な世界観を IoV（Internet of Value）と呼んでいます。

ILP はどの様に機能しているか

では、この ILP が内部的にどの様に機能しているのかについて記述します。先ずは細かい事はともかく、図でざっと全体を概観してみましょう。

Interledger Overview

この図では、ビットコインを持っている A さんが円をメインにしている B さんに支払いを行いたい例を示しています。レジャーについては前述の通りなので問題ないと思いますが、新しい大きな要素として水色の「コネクタ」というものがありますね。これは大事な要素なので後でご説明します。今はいったんこのレジャーとレジャーをコネクタが繋いでいる、という全体の繋がり方を見て頂ければと思います。

では、ILP がどうやってレジャーを超えた価値の移動をするのかを一言で言うと

「コネクタが接続している両方のレジャーに持っている口座を使い、それぞれレジャー内の口座で価値を移動する」

という事になります。はい。何を言っているのか分かりませんね😂 本来はもっと複雑なフローになるのですが、あえてものすごく簡略化して言うと、

1. レジャー 1（Bitcoin レジャー）上の A さんの口座（Account A）からコネクタ 1 の口座（Account C1）に BTC を移動する
2. レジャー 2（XRP レジャー）上のコネクタ 1 の口座（Account C1）からコネクタ 2 の口座（Account C2）に XRP を移動する
3. レジャー 3（銀行Ａレジャー）上のコネクタ 2 の口座（Account C2）から B さんの口座（Account B）に円を移動する

という流れです。A さんからは BTC が減りました。B さんには円が増えました。しかし、コネクタ 1 は XRP は減ったものの、同量だけ BTC が増えています。同様に、コネクタ 2 は円は減ったものの、同量だけ XRP が増えています。厳密に言うとコネクタは交換レートを設定でき、微量ながら手数料を得る事ができるので全く同じ価値ではありませんが、ほぼ同じです。この様な流れで、コネクタは価値が減る事なく（手数料分だけ増えて）A さんから B さんへ価値の移動がなされる事になります。

何故この様な面倒な事を行っているか、逆に「こうしなかったらどうなるのだろう？」と考えると、分かりやすいです。A さんが B さんのレジャーに、「お金送りたいから B さんの口座に1000円入れといて？」と言ったとして、B さんのレジャーは B さんの口座に+1000円する事はできません。その様なお金はデータ上増えただけであって、銀行Ａはそんなお金は実態として持っていないからです。ではどうしたらよいのか、考えられる方法は３つあります。

1. A さんが実際に銀行Ａに現実の円のお金を B さんのために入金する
   インターネットで便利に行いたいので、これは却下です。
2. A さんが持っている A さんのレジャー上の価値の秘密鍵を B さんにあげる
   例えば A さんの口座から派生したサブ口座の様なものを作り、その口座にお金を移動し、その口座のパスワード（残高を使用できる権利）を B さんに安全に渡す事ができれば B さんは価値を得る事にはなりますが、B さんのレジャー上の単位（円）で得る事ができず、A さんのレジャーを使う事を強制されてしまうので却下です。
3. 銀行Ａ内にある誰かのお金を借りて B さんの口座に入金する
   これであればネット上で行う事ができ、かつ B さんのレジャー上の単位で B さんが価値を得る事ができます（ただし、どうにかして借りた分は返さなければいけませんが）。これだ！

という訳で、この３番目の案をレジャーをまたいで連続的に行っているというのが、ILP の原理原則になります。なお、上の図では XRP レジャーを挟んでいますが、例えとして入れただけで必ずしも挟まなければいけないという訳ではありませんし、逆にさらに間にいくつかのレジャーが入ってくる可能性もあります。何回ホップする（またぐ）かは、状況次第になります。

疲れましたね！😂
紅茶でも飲んで休憩して下さい！☕️

さて、大枠の動きが分かったところでもう少し詳細に見てみましょう。おおよそ、ILP を理解する上で重要な機能は以下の様なものだと考えています。実際のフローはこれらを理解した上での方が理解しやすいでしょう。

1. プロトコルレイヤーとプロトコル群
2. アドレッシングとルーティング
3. クオーティング
4. Hashed-Timelock Agreements (HTLAs)

これらを見た後に、順を追って見ていきましょう。

１）まずはプロトコルレイヤーですが、これはつまりプロトコルが階層（レイヤー）構造になっているという事です。階層構造とはどういう事かと言うと、基本的な機能を提供するものほど下層に、応用的な機能を提供するものほど上層に配置する事で、機能の分離を行い、再利用性と拡張性を実現しているという事です。

ILP のプロトコルレイヤー。Interledger Workshop のスライドから引用。

もう少し詳しく言うと、例えば ILP の場合は先ほどの図の様にコネクタが価値を仲介してあげる事で末端から末端に価値の送信ができている訳ですが、支払いを構成している送信者、受信者、コネクタ達が一体となってできるだけ失敗しない支払いを実現する仕組み（HTLAs・後述）を導入しています。この様な仕組みはどの様な支払いであっても使える汎用的な機能なので、これらに関する機能を提供するもののみを扱うプロトコルを先ずは定義して、どの様な支払いにおいても汎用的に利用できるものとしておきます。つまり、ILP を通じて状況に応じた様々な支払いを行いたい、それ専用のプロトコルを定義したいと思った時に、これらの基本的な機能を再度各々が定義しなくていい様にしておきます。これが再利用性です。

さらに上層では、これはあくまで将来的な例ですが、何か税金に関する処理を加えたいと思ったとします。低レイヤーでは「何か拡張したくなったらここにデータを入れてね」というスペースを用意してあるので、そこにデータを入れます。この様に、後々のためを考えて上位レイヤーで独自の拡張ができる様に低レイヤーを設計しておく事で、拡張性を実現しています。

また、エンジニアあるあるなのが一気にドカンと大きな機能を定義してしまい本当はその中のある部分は切り出して再利用可能なのに閉じたものにしてしまい、他の機能でも似た様なものを実装しなければいけないという現象ですが、ILP では機能を細分化して様々なプロトコルとして定義しています。以下はその一例です。

• Interledger Payment Request Protocol（IPR）
• Pre-Shared Key Transport Protocol（PSK）
• Simple Payment Setup Protocol（SPSP）
• Interledger Quoting Protocol (ILQP)
• Connector-To-Connector Protocol (CCP)

この様に、ILP はなにか単一の「Interledger Protocol」という大きなプロトコルで成り立っている訳ではなく、様々な細かな機能を定義したプロトコルの集まり（=プロトコル群、プロトコルスイート）として、全体で Interledger Protocol というレジャーを超えた価値の移動を行う仕組みを定義しているのです。

２）次にアドレッシングですが、これは ILP 上で口座を特定するための口座番号の仕組みで、インターネットのアドレスを連想すると分かりやすいかと思います。例えば、

g.crypto.xrp.ra5nK24KXen9AHvsdFTKHSANinZseWnPcX

といったものが ILP 上の口座アドレスになります。これが何を指しているかと言うとグローバルなネットワークの（テスト用ではない本番環境）、暗号通貨の、Ripple の開発したレジャーの XRP という通貨の ra5… という口座という事になります。この様な形にしておくと全世界の人がどの様なレジャーに口座を持っていようとも一意に特定可能になります。将来的には、あなたの銀行口座にも ILP のアドレスが割り当てられる事になるかもしれませんね。そう遠くない未来にそうなるでしょう。また、このアドレスにはトランザクション ID（処理を一意に特定するための ID）も割り当てられる事になっており、この人の、この取引のための口座に入金したい、といった指定が可能になります。

ここで先ほどの図を思い出して頂きたいのですが、コネクタはお互いにいくつも接続されていました。コネクタはどの様なアドレスの場合はどのコネクタに支払いデータを送ればよいのかという対応表を持っています。この様なデータの道のりを示す対応表なのでルーティングテーブルと呼ばれています。例えば、g.us. で始まるアドレスの場合はこのコネクタに、g.jp. で始まるアドレスの場合はこのコネクタにお願いする、といったイメージです（ドットまでを区切りとします）。こうする事で仮にネットワークの全体像を知っていなかったとしても支払いデータを送る事ができる様になります。

３）次にクオーティングですが、これは簡単に言えば見積もりです。何を見積もるかと言うとコネクタに支払う手数料です。コネクタは片方のアカウントに得られる価値と、片方のアカウントから出ていく価値に任意の差をつける事ができ、これがコネクタの手数料になります。

例えば、上図ではレジャー 1 のアカウント A から 1 BTC がアカウント C1 に移動しました。しかし、レジャー 2 のアカウント C1 からアカウント C2 には 0.9 BTC 相当の XRP しか移動しなかったとします。この時の 0.1 BTC 相当の価値の差がコネクタの手数料となり、コネクタの口座上で増えていく事になります。ちなみにこの 0.1 BTC は今では 100,000 円というとんでもない価値ですが、これはあくまで例ですので、実際にはそんな法外な手数料にはならないでしょう。

この様な手数料がどれくらかかるのかの見積もりを行うには ILP では方法が３つ用意されています。

1. QuoteBySourceRequest = 自分が支払う金額を固定し、手数料を引いていくら相手に支払えるかを取得する
2. QuoteByDestinationRequest = いくら相手に支払うかを固定し、手数料を含めていくら自分が支払うかを取得する
3. QuoteLiquidityRequest = 特定の相手に支払おうと思った時に、どれくらいの交換レートになるのかの変換式（区分線形関数）を取得する

ただし、見積もりを行ったからと言って必ずしもその支払いを実行しなければいけない訳ではなく、先ずはこれを行った上で納得できるものなのかどうか支払い側が判断する事になります。

４）最後に、Hashed-Timelock Agreements (HTLAs) について見てみます。これは先ほどあった支払いを構成している送信者、受信者、コネクタ達が一体となってできるだけ失敗しない支払いを実現する仕組みです。失敗とは何かと言うと、一部の人は価値を移動したのに一部の人はしない、という事を指します。つまり、全体として価値が全員（送信者、受信者、コネクタ達）分移動するか、もしくは全くしない事を目指します。

どうやってこれを行うかと言うと、

1. 価値の移動を行おうと思ったら確実に行える様にレジャーに預けて、価値を準備状態にする（いざ移動を行うタイミングになって実はもうない、という事を避けるため）
2. 受け取り側の号令でのみ価値の移動を開始できる様にし、第三者は途中で勝手に価値を移動する事はできない

といった流れです。

具体的には、下記の様なフローになります。

1. 送信者から受信者の間でコネクタを含めて送信に必要になる価値を各々の対応するレジャー内の escrow（エスクロー、一時的に取り出せない領域）に入れます。この時、エスクローには condition と呼ばれるものとタイムアウト時間が設定され、fulfillment という特定のデータを与えられた時のみ左図の②のフローに入り、価値が移動します。また、fulfillment が与えられずにタイムアウトを迎えた場合には自動的に左図の③のフローに入り、価値は元のアカウントに戻る事になります。この図には１つのレジャーしかありませんが、送信者と受信者の間にある全てのレジャーで同じ事が行われます。このエスクローに入れて価値の移動の準備をする事をプリペア（prepare）、準備がなされた状態をホールド状態（on hold）と言います。
2. 全ての価値がホールドされたら、受信者は fulfillment と呼ばれる受け取り証の様なものを発行します。これをレジャーに渡す事で condition と照合されて価値が移動し、受信者は価値を得る事になります。fulfillment を受け取ったレジャーは、それを次のコネクタに渡します。すると、次のレジャーに繋がっていたレジャーが価値を移動するので、そのコネクタは価値を得る事になります。次のコネクタは、さらにそのコネクタが繋がった先のレジャーに fulfillment を渡します。この様に価値の移動が受け取り側から送り側に伝搬していく事になります。コネクタは価値を移動して欲しいので、fulfillment を次に渡していきます（それが自分の価値になるので）が、fulfillment は受信者しか生成できず（厳密に言うと PSK を使うと違うが、割愛）、第三者が condition から fulfillment を推測して生成する事は困難なので、受信者が受け取っていないのであれば移動は行われず、途中でズルをして価値の移動を起こさせる事はできない仕組みになっています。

この様に、ホールド状態を作ってから移動するという二重の価値の移動プロセスを経るので two-phase-commit とも呼ばれます。

fulfillment と condition の生成には内部的にハッシュ関数（あるデータから別のデータが生成される関数の事）が使用されており、これにタイムアウトを組み合わせているので Hashed-Timelock と呼ばれています。

なお、ここで万が一レジャーが信用ならないものだった場合には fulfillment を送ったのにホールドから移動してくれないという事が起こり得ますが、これは ILP でも既知のリスクとしており、マネジメント可能であるという位置づけになっています（接続するレジャーは自分で選べるため）。

ここまでで一通り、重要な機能については理解ができたと思います。実際の支払いでこれらがどういう流れで使われるかと言うと、下記の様なイメージです。

1. プロトコルレイヤー上層の SPSP というプロトコルを使い、受け取り者の情報（ILP アドレスや通貨の単位）を取得する
2. 手数料を見積もる（クオーティング）
3. ホールドする（escrow に condition と制限時間付きで預ける）
4. 実行する（受け取り者が fulfillment を送る）

この時、情報はルーティングテーブルに従って送信されるイメージです。これで、一通りの実行がイメージできるのではないかと思います。

ILP の広がり

ILP は柔軟でプログラム可能な支払いを提供するので、様々なプロダクトへの応用が検討されています。その一例として、WebPayments への応用、API をマイクロペイメンツ（少額の決済）で実行可能にする仕組み、さらに Web 上でプログラムを実行する基盤を提供する Codius、KDDI とトライデントアーツ社からは Ethereum と Hyperledger を ILP で接続したサービスといったものも開発されています。私もデモで見た程度しか分からないので詳細は省略しますが、分かる範囲でその概略をご紹介します。

• WebPayments への応用

これは前に私の別のブログでも書きましたが、今 WebPayments というブラウザ上での支払いを簡単に行える様にする仕組みが作られており、その中の一部として ILP を通じた支払いに対応する予定があります。

具体的には、例えばショッピングサイトで支払いを行おうと思った時に支払いウィンドウの様なものが現れ、そこで支払い方法として ILP を選択すると対応するアプリが表示され、ILP 経由で決済が行われる、といったイメージです。あなたは ILP に対応した銀行口座、ビットコインのアカウント、XRP のアカウントなどがあれば相手が望む通貨が何であろうと、支払いが行える様になります。何故なら上述の様にコネクタが自動的に通貨の価値を変換してくれるからです。

これが実装されて ILP と共に稼働する様になると、仮想通貨での支払いも一気に身近になるのではないでしょうか。何故なら、相手側は自分のレジャー（円など）で支払いを受け付ければいいからです。

• API とマイクロペイメンツ

マイクロペイメンツは前述しましたが、Interledger Workshop では実際にその例として、ネット上の API を呼び出し単位で課金する様なデモが行われました。API とは何かと言うと何らかの機能を提供する際の呼び出し規約（ある意味プロトコルの様なもの）ですが、インターネット上には「こういう URL でアクセスすると、こういうデータを返してあげるよ」という サービスが存在します。こういったものを API と呼んでおり、例えばとある日時の URL でアクセスするとその日の天気図を画像で返してくれる、といったイメージです。この様に何らかの価値がある API を作ったとして、タダで公開するのはややもったいないものがあります。

そんな時に ILP を組み合わせると、1回の呼び出しは1円でいいよ、という作り方ができます。作り手も使い手も余計なデータ（例えばクレジットカードの情報など）をやりとりする事なく、価値を簡単に移動し、それによってサービスを提供する事ができます。繰り返しますがその通貨が何であるかは問題になりません。

ワークショップでは実際に API 呼び出しを有料で行う ilp-curl（curl を ILP に対応させたもの。curl はこちらを参照）やファイルをホスティングする unhash などがデモされました。

• Codius

また、Codius というプロジェクトもデモされました。こちらは上記の様な API サービスなどのプログラムを実行するための環境ですが、通常ではクレジットカード支払いなどで AWS（Amazon Web Service）を借りたりする訳ですが、Codius 上ではサービスが実行された対価をホスティング費用として支払うといった様にお互いに支払いをし合う事で自動的に処理できる様になっている様です。様ですと書いたのは、デモではその様な話でしたがコードレベルで理解できていないので、いったんこういった表現に留めておきたいと思います。詳しくは公式サイトなどを参照してみて下さい。

• KDDI とトライデントアーツ社の試み

Interleder Workshop では、KDDI とトライデントアーツ社で開発を行っている Ethereum と Hyperledger を ILP で繋ぐプロジェクトのデモも行われました。こちらも、私は Ethereum と Hyperledger にあまり詳しくないので詳細は割愛したいと思います。参考までに、下記の記事によく書かれていますので、こちらを参照するとよいかと思います。

トライデントアーツがKDDIと共同開発/リップルのILPを活用したサービス

その他のレポート

Interledger Workshop には様々な方が参加されていました。ここにいくつか載せておきますので、合わせて参照されると面白いと思います。

ILP(インターレジャープロトコル)とは/ILPでXRPは使用されるのか？

Ripple社CTO Stephan Thomas氏へのインタビュー

ステファンは私も実際に話をさせてもらいましたが（つたない英語で…）、とてもおおらかで気の利く人柄で、インテグリティってやつを感じてしまいました😂 彼の過去のお話が載っていて、とても面白い記事です。

ILPワークショップ東京 レポート（デモ編）

有名な Ripple 総合まとめのサイトです。私写真を撮るのをサボってしまったのですが（汗）こちらには写真もたくさんあり、彼らが使っていたスライドの内容が分かりやすいです。

関連リンク

• interledger.org Interledger Protocol 自体のサイト
• interledgerjs/ilp JavaScript での Interledger のサンプル実装。このリポジトリは処理の全体像が分かりやすいので参考までに置いておきます
• Ripple ILP の発明元であり開発にメインで参加している Ripple のサイト