ILPワークショップ東京
日時：２０１７年１１月２０日（月） 午後４時～午後９時（JST）
場所：〒100-0004 東京都千代田区大手町１丁目９－２ 大手町フィナンシャルシティグランキューブ３F
デモ編
デモ① 非金融系でのILP利用 町浩二、大竹祐貴（トライデントアーツ）
デモ② 新しい収益モデル（APIコール課金）
デモ③ APIコール課金を利用したファイルサーバー “unhash”
デモ④ “Codius”とAPIコール課金による収支管理の自動化
Stefan Thomas, Ben Sharafian（Ripple社）
デモ① 非金融系でのILP利用
【ポイント】
- 2つの異なるブロックチェーン間で支払いを実証した。
- 非金融系でのILP利用。
- “Hyperledger Fabric 1.0”から、“Enterprise Ethereum Quorum”への送金。
【ユースケース】
KDDIはブロックチェーン技術を活用し、携帯電話の店頭修理申し込みから完了までの工程における、リアルタイムな情報共有およびオペレーション効率化の可能性を検証している。さらに「スマートコントラクト」により、修理事業とは別事業であるリユースサービスなど異なる事業者間におけるシステム連携の可能性を技術検証している。具体的には、携帯電話の修理の際、修理価格、機種変更価格、中古市場価格など異なるシステム間の情報をプログラムが自動判別し最適な契約が行えるかを検証する。
※KDDIプレスリリース
http://news.kddi.com/kddi/corporate/newsrelease/2017/09/27/2694.html
今回のデモはこの検証実験のうち、修理事業で修理した携帯電話を中古販売(リユース)事業にて販売することを想定して、中古販売事業（Hyperledger Fabric 1.0を実装）から修理事業（Enterprise Ethereum Quorumを実装）への送金のデモを行った。KDDIと共同。
スマホの修理のネットワーク(Ethereum利用)と中古販売のネットワーク(HL Fabric利用)が存在すると想定する。従来は、壊れた携帯電話をユーザーが修理に持ってきて修理代金を払って返却してもらう。一方、新しい形では、修理したものをユーザーが中古市場へ直接売却する。これによってユーザーはただ修理代金を払うのではなく、中古市場に直接接続して販売することが可能。一方、携帯電話会社としては故障を期にユーザーが他の会社に乗り換えることを抑制して、新しい携帯電話を買ってもらいやすい環境を作ることができる。
下図では情報がブロックチェーン間でやり取りされる。中古市場で買い手が付いたら、即決済まで持って行く。KDDIもノードとして参加し、販売チャネル（販売店）がノードとしてそれぞれ参加している。今回のデモは、図中の④にあたる、中古販売ネットワーク(HL Fabric)から修理ネットワーク(Ethereum Quorum)に送金をする部分をデモする。
送金フロー（デモは図中の④の部分）
Hyperledger Fabric ⇒ エスクロー付きのコネクター ⇒ Ethereum Quorum
FabricもQuorumもブロックチェーンの台帳になるが、内部を参照することが難しいので、今回はNode js Web Applicationを使って、取引実行とデータ参照を行う。
今回のデモでは以下の2つの操作を行う。
- Preparation (ILPの送金前準備)
実際に支払いはされずに資金がエスクローにホールドされる。 - Execution (実際の送金)
ホールドされていた資金が実際に送金される。
【実演】
 修理の台帳のアプリケーション |
 中古販売の台帳のアプリケーション |
修理のプラットフォームでBobが壊れた携帯電話を販売する。
中古販売のプラットフォームでAliceがその携帯電話を購入し、送金。
1. Preparation
修理アプリは管理者でログインすると、各人の残高の一覧が見える。
Aliceが中古販売アプリにログインすると、Aliceの残高が見える。
 修理アプリの残高一覧（Bob含む） |
 中古販売アプリのAliceの残高 |
Aliceが支払い。中古販売アプリでBobのアドレスと支払金額”1,000”を入力し、支払実行ボタンを押す。これでまず資金がエスクローにホールドされる。（この時のエスクローはKDDI）
これでAliceの残高が1,000減った。
Escrowのステータスを見ると、FromはAliceでToがKDDIになっている。ここではKDDIがコネクタになり、中古販売の台帳ではKDDIに支払われる。State: Preparedになっている。Destination（Bob）のアドレスがセットされた状態。
修理アプリを見ると、修理プラットフォーム内のKDDIから1,000が引かれ、これがホールドされる。
2. Execution
修理側でExecutionを実行。
修理アプリでBobが1000増える。
中古販売アプリでAliceは1000引かれた状態のまま。これで完了。
実利用ではConditionも記されていく。
【発表者のコメント】
4つの階層構造※になっていて、各層の役割が明確・シンプルだったので、開発する側としてはやりやすかった。ILPとは関係ないが、Quorum, Fabric 1.0のネットワークを動く環境にするところで苦労した。
※4つの階層構造
※トライデントアーツ 2018年からILPサービスプロバイダという事業を始める。非金融でアジアに限定。
デモ② APIコールに課金
【ポイント】
- 広告やサブスクリプションとは異なる、オンラインサービスの新しい収益モデルを提案
- APIコール(アプリケーションの機能呼び出し)自体に課金。
- 良いサービスのアイデアさえあれば、収益モデルを考える必要なく開発に集中できる。
- ユーザーに新しく登録をしてもらう等、収益まわりのわずらわしい手続きを省略できる。
【ユースケース】
Ninaという人がAIを開発した。世界中の人にこれを使ってもらいたい。
ただがんばって開発したので、これを無料で提供するのではなく、どうにか収益にしたい。
2016年まではAIで収益をあげようと思ったら、どうやってマネタイズするかを考える必要があった。例えば広告ベースだったり、サブスクリプション（定期使用料）だったり。あるいはモバイルアプリでアプリ内課金をしたり、ユーザーデータを販売したりするといった方法が考えられる。ここではNinaはサブスクリプションを選択したとする。
ただ、そうするとユーザーにユーザー登録をしてもらわなければならない。そしてユーザーのデータベースを用意する必要もある。
さらには入金ができるようにするにはアクワイアラー（加盟店）と契約したり、クレジットカード会社や銀行振込との手続きが必要だったりする。カードネットワークも必要になるし、複数の加盟店と契約するとなると間に決済代行会社が入ってくる。
さらにNinaはモバイルマネーからの入金も期待しているため、別の決済代行会社も必要になる。また仮想通貨からも入金を期待している場合はさらに他の業者との契約が必要になるだろう。
ということで2016年のNinaはイライラしていたわけだが、そこに対して私たちはILPを活用してもっと簡単な方法を提案することができる。その例が、APIコール（アプリケーションの機能の呼び出し）に対して支払うオープンな標準の支払方法である。
オープンで標準の支払方法なのでその標準をサポートしていれば、ユーザーがどのような支払プロバイダを使っていてもNinaは気にする必要がない。また、これを利用すればユーザー登録・ユーザーデータベース・サブスクリプション課金のような手続きは一切不要になる。そして収益はAPIがコールされる度に入ってくる。
【利用する技術】
私たちは、Interledgerのリファレンシャルアーキテクチャである”Interledger js”というものを作った。これはオープンソースでGithubに行けば見つけることができる。またJS Foundationから資金サポートを受けている。
今回のデモでは、Interledger jsから2つのモジュールを利用する。“koa-ilp”と”ilp-curl”。
Nina側のサーバーは入金を受けるためにkoa-ilpを使用。koaを使っているユーザーなら簡単に支払手段をhttpのエンドポイントに追加することができる。
ユーザー側はリップル社が開発したilp-curlを利用する。支払に対応したhttpクライアントであり、有料のAPIをコールすることができる。
【発表者のコメント】
APIを有料にできるということは、起業家がアイデア・サービスから収益をえることができることを意味している。それまでは良いアイデアがあっても良いビジネスモデルが必要だった。一方、レストラン経営だったら良いレストランのアイデアがあったら、食べた人からお金を貰えばいいだけなので収益モデルをどうしようかといったことで悩むことはない。これと同じことがオンラインのサービスでも当てはまるような収益の形が必要になる。それが実現できれば起業家は良いオンラインサービスを開発することに集中でき、広告にしようかサブスクリプションにしようかと考えたり、それに関わる様々な手続きに手間を割く必要がなくなる。
【実演】
Ninaのアプリケーションを開く。
これは単純なkoa APIで、AIをホスティングする。まだ決済機能は無い。
AIのロジックは見ての通り非常に複雑。
まずは送金無しでどのように動くか見てみよう。
定義したエンドポイントに質問をする。すると正解らしい答えが表示されている。
ただしこれには支払が実装されていないので、このままではNinaにとって良くない。支払の手段が必要。
次に支払を受けられるバージョンを開く。
決済を受けられるバージョン。前のとほとんど同じだが、支払を受けるコードが追加されている。
支払額は1,000ナノドル。koa-ilpモジュールを利用しており、Interledgerネットワークにプラグインしている。
ではこれを走らせてみよう。
この場合は動かなかった。これは支払の詳細を提供していないため。
ここでトークンIDを規定したコールを投げる。
まだ支払っていないので、実際に支払を行うツールに切り替える。
これがilp-curlツール。httpにおいてそのフローの中で自動的に支払を行う。
実行するとリクエストの中から支払の詳細をマーキングし、ILPのトランザクションを行う。実際に入金されると結果が表示されている。
デモ③ APIコール課金を利用したファイルサーバー “unhash”
【ポイント】
- 前のデモで提案されたAPIコールへの課金という支払手段を広く応用。
- 有料APIコールのファイルサーバー”unhash”をリップル社が開発。
- また自分に最適なファイルサーバーを提案してくれるサービス”Council”を作成。有料のAPIコール。
- 2,3日で開発できた。
【ユースケース】
Ninaは開発したAIにファイルサイズの大きい画像ファイルを含ませたい。そのためにファイルサーバーにファイルをアップロードしてホスティングしたい。そこでリップル社はUnhashという新しいサービスを開発した。
これはUnhashという名のサーバーでファイルをホスティングするサービス。前のデモのようにAPIコールに対して課金。アップロードされたファイルは誰でもダウンロードすることができる。
ただしNinaはいろいろなファイルサーバーがある中からUnhashサーバーを選択する必要がある。しかし、いろいろな有料サービスの中からどれを選ぶかを探すのには手間がかかる。
そこでリップル社は新しくCouncilというツールを用意した。これは多様なサービスの中から自分に合ったサービスを選んで教えてくれるサービス。これもAPIコール毎に課金されるサービス。
これまではCouncilのような助言サービスが”適切な”助言をするのには問題があった。というのはAPIコール課金のようなユーザーに”簡単に”課金する方法がなかったので、助言サービスはキックバックを受けられる所のサーバーを薦めてしまいがちで、適切な助言が与えられにくい状況にあった。
ILPがあればユーザー側がリクエストに対して支払うことができる。つまり助言サービスにとって、収益源がキックバック元ではなくユーザーになるので、ユーザーにとって本当に最良の提案をするようになる。またこれによって、ファイルサーバーのようなサービス側には自然と競争が生まれる。
NinaはCouncilサーバーにAPIコールでどのサーバーが良いかを尋ね、Councilサーバーから回答を受け取る。これで無事Ninaは自分に最も合ったサーバー、つまりunhashサーバーを提案された。
そしてNinaはunhashサーバーにAPIコール毎に支払ってファイルをアップロードすることに成功。NinaのAIのユーザーも無事にファイルをダウンロードすることが可能。
【発表者のコメント】
Unhashはファイルをホスティングする非常にパワフルなツールである。ちなみにこのunhashサーバーを構築するのに2,3日しかかからなかった。今回のデモでは１つのサーバーにアップロードすることを見せているが、標準化されたコードを利用するため50のサーバーに手間なくアップロードすることが可能。他の方法として例えば、分散台帳プロトコルだったり、独自のトークンを発行したり、独自にICOを行ったりするのがあるが、果たしてホスティングするのに独自のトークンを使う理由はあるのだろうか？実際にはホスティング会社は電気代やその他の維持費を捻出する必要があるが、トークンにはそういった物は加味されていない。ユーザー側としてもそのサービスを利用する時にサービス独自のトークンを保有あるいは取得する必要があるのは不便であり、ユーザー毎に好きなトークンが利用できたり、あるいは単純に自国の通貨をそのまま使えるほうがいいいはずだ。将来は、このような特殊なトークンではなく、ILPを使った汎用トークンが好まれるだろう。様々なトークンを生み出すよりも、ILPを使って単純でかつ汎用性の高いサービスを提供できるはずだ。
【実演】
NinaはCouncilサーバーにILP-curlで繋いで、どのサーバーにすればいいか尋ねる。前のデモと同じようにilp-curlを使ってリクエストから支払の詳細を取り出し、支払を行って、サーバーから回答を得る。答えはunhashサーバー。
unhashサーバーを薦められたNinaは、次に同じくilp-curlを使って、unhashサーバーにファイルをアップロードする。ハッシュ値が返ってくる。
以下は新しいバージョンのAIのコード。コードの中でCouncilに対してどのunhashサーバーがいいか質問している。また先ほど得たハッシュ値も入っている。
では実際にAIに質問してみる。
問: “最も双方向性のあるプロトコルは何？”
答: ”Interledger”。 添付画像の情報も出力された。
添付画像をダウンロードしてみた。
デモ④ “Codius”とAPIコール課金による収支管理の自動化
【ポイント】
- Codius上にAPIコール課金のAIを走らせる。
- Codiusを使ってAPI課金の受取り、手数料支払いを自動で行い、ツイートbotに定期的に広告を出してもらう。
- Codiusの凄いところはこれまでのデモと同様、同一のツールで全てできること。他のサービスにログインしたり、他のユーザーインタフェース(UI)を介したりする必要はない。１つのツールで済む。
【ユースケース】
デモ③で示したAIを更に高度なものにしていく。Codiusはリップル社が3年前に発表したもの。当時からCodiusにはワクワクしていたが、構築には至らなかった。なぜならば当時はまだILPが存在していなかったから。
Codiusというのはインタラクティブサービスをホスティングするサービス（スマートコントラクト）。前のデモではファイルをunhashがホスティングしていたが、ここからはファイルをAPIでホスティングしていく。
さらにILPを使うことでホスティングに対して支払うことができる。過去のCodiusに無かったのが、このような支払いの標準となるものだった。
Unhashの時と同じように、ホスティングしているCodiusに有料のAPIコールを送る。NinaのAIがCodius上で実行されている。（図のリングの部分。）
前と同じように、ユーザー側も有料のAPIコールを送ってAIに送ってレスポンスを得ることができる状態。
AIは他のサービスにAPIコールを送ることができる。例えばTwitterサービスに有料APIコールを送ることで広告を出したり。
ここからさらに面白くなってくる。
ここまで全部ILPで支払いが実現できているので、Ninaがしてきたホスティングに対する支払いも含めて送金の全てをAIに代わりにやらせることが可能になる。つまり金銭の授受に関することは全てAIに任せてしまい、Ninaは売買の管理について何もしなくて良くなる。
具体的には、ユーザーはAIにAPI使用料金を払って、AIはホスティングサービス・Twitterなど全てのサービスへの使用料の支払いを自動的に行ってくれる。
これは非常にシンプルな例だが、これがさらに拡大すると面白いことになるだろう。
例えば、テック企業が様々なAPIプロバイダや製品ごとの異なる請求書を処理するのに数週間という時間を浪費していたが、これを全てILP経由でAIを使った自動化に組み込んでしまえば、収入・支出の管理の手間が大幅に減少する。
【発表者のコメント】
Codiusはコードを多くの人に使ってもらうのにとても強力な方法である。今回のデモでは１つのサーバーにアップロードするものだが、100のサーバーにもアップロードができる。これは、スマートコントラクターに対して競合させる環境を突然作ることができたことを意味している。また他のスマートコントラクトのように独自の言語でのみ扱えるといった形ではなく、自分たちの好きな言語を使って構築できることも大きなメリットである。
ILPによってブロックチェーンの環境が全く様変わりすると私たちは思っている。ILPで支払のプロトコルを「抽象化」することにより、非常に柔軟性がありシンプルなサービスをどんどん出すことができる。
【実演】
まずAIをCodiusにアップロードする。
Dockerファイル。
Dockerイメージや変数をどう使うかの仕様。
AIをCodiusにアップロードする。やるのはilp-curlコールを作るだけ。
Codiusの凄いところはunhashやcouncilのように同じツールで全てできること。他のサービスにログインしたり、他のユーザーインタフェース(UI)を介したりする必要はない。１つのツールで済む。
アップロードし終わったら数秒で実行開始される。サービスのホスティングが始まって、そこにリンクいくためのURLが表示される。
表示されたURLを入力してAIに質問をする。前と同じく答えが出てきた。今回のコードは前のデモと同じだが、今回はCodiusを通して自動化されているので人間が実行する必要はない。
次にCodiusが自動的にTwitterへ広告を出すところも見てみる。
Twitterへ投げるAPIキーを難読化したファイル”Twittius”。これをCodiusにアップロードする。
※”Twittius”とはTwitterとCodiusを組合せた名前。
アップロードされると数秒以内で実行開始。
広告料が支払われて、Twittius Botというアカウントに広告が出る。
次に人間が毎回支払を実行しなくてもCodiusが自動的にTwitterに広告を出すのを実演する。
“Crontract” (= Crone + Codius Contract)というツールを作った。これを使ってTwitterに自動的にかつ定期的に広告を出稿する。ここで「広告料の支払い」「ilp-curl」「ツイートする内容」が記されている。これをアップロード。
“Crontract”でジョブの実行が始まると、数分おきに広告をリピートするようになる。
実際にTwitter上への広告が定期的に表示されているのを確認。
