1.
A Protocol for
Interledger Payments
Takaya Imai
Co-founder and CTO@United Bitcoiners Inc.
CEO@Frontier Partners LLC
日本ブロックチェーンユーザ会@株式会社CAMPFIRE
Jun/16/2017

2.
自己紹介
• 株式会社ユナイテッド・ビットコイナーズ 共同創業者&CTO
• フロンティアパートナーズ合同会社代表CEO
• マスタリングビットコイン、翻訳者代表
• 2016/7/14出版、先日電子書籍版出ました
• オープンエディション版
• https://www.bitcoinbook.info

3.
自己紹介
• バックグラウンド
• 新潟大学大学院 素粒子理論物理 博士(理)
• カカクコム
• 検索エンジン開発 検索サーバクラスタ構築運用 大規模データ処理 機械学
習 画像認識
• データタワー株式会社 代表取締役
• 株式会社ブロックチェーンハブ 技術アドバイザー

4.
経緯
資金のフルコントロール

5.
経緯
マイクロペイメントチャネル(一方向)
相手を信用する必要がない

6.
経緯
相手を信用する必要がない
マイクロペイメントチャネル(双方向)

7.
経緯
相手を信用する必要がない

8.
経緯
ゼロ知識に基づく条件付き支払い
(Zero-Knowledge Contingent Payment)
相手を信用する必要がない

9.
経緯
複数ブロックチェーンでの通貨の不可分交換
(Atomic Swap)
相手を信用する必要がない

10.
経緯
Lightning Network RFC: BOLT
(Base of Lightning Technology)

11.
経緯
Flare: Lightning Networkルーティングアルゴリズム
一度送金経路が決まると、
送金経路を信用しないといけない

12.
Som
ethin
g
ZcashEthereum
Som
ethin
g
Bitcoin
関連
…
Lightning Network
Sidechain
Atomic
Swap
Paypal
Interledger
Visa
Cosmos

13.
経緯
後日解説予定

14.
the Interledger Workshop and
Hackathon
in Berlin on 1st, 2nd June

15.
• Interoperability Boost: Ripple Sends Blockchain Transaction Across 7
Ledgers
• https://adrian.hopebailie.com/making-history-in-berlin-78f1533787f0
• http://www.coindesk.com/interoperability-boost-ripple-sends-blockchain-
transaction-across-7-different-ledgers/

16.
ホワイトペーパー
• 2015年02月28日
• Lightning Networkホワイトペーパー公開
• 2015月10月09日
• Interledgerホワイトペーパー公開
• 今回紹介 http://interledger.org/interledger.pdf
• Rippleとは関係ない

17.
解決したい問題点
• ある機関・企業が送金を仲介するためには
• 十分な資金が必要
• 顧客の資金を盗まないための担保が必要(許可制
など)
• このため、これができる機関・企業は限られ、送金
できる通貨・ポイントなどは限られてしまう

18.
解決したい問題点
https://www.slideshare.net/Interledger/interledger-workshop-berlin-1-june-2017

19.
解決したい問題点
• エスクローのtrustless化
送金元 送金先
第三者機関
1, 購入
2, 送金依頼
3, 送金
4, 預かり済み報告
5, 発送
6, 預かり金解除許可7, 預かり金送金
普通のエスクロー

20.
解決したい問題点
• Apple payなど既存の支払い方法を用いつつ、暗号
通貨も法定通貨も自由に行き来するためには、どの
ようなプロトコルが必要だろうか？

21.
構成要素
• Sender: 送金元
• Recipient: 送金先
• Connector: 異なるledgerを繋いで支払いを繋ぐ仲介者
• Ledger: エスクローに使うブロックチェーン
• エスクロー: 資金の条件付き固定
• Notary: 支払い完了を監視する公証人
Notary Notary Notary Notary

22.
送金方法の種類
• Atomic Mode
• 送金元と送金先の間にいくつもコネクタがあった
としても、送金が成功するか、失敗して資金が戻
るかのいずれかの状態に落ち着く
• Universal Mode
• 公証人が選出できなかった場合

23.
通常の２者間支払い

24.
通常のエスクロー方法

25.
Interledgerでの方法

26.
状態の遷移

27.
公証人の選出
Notary Notary Notary Notary
各コネクタ、Senderが選出した公証人の中で
共通している公証人を選ぶ

28.
Atomic Modeでの関連図

29.
公証人による
支払いの完了判定
• 送金先は一つ前のコネクターのエスクローが完了してい
ることを確認し、R_ReceiptSignatureを全ての公証人に
送る。
• 全ての公証人が制限時間前にR_ReceiptSignatureを受け
取った場合、送金先および全てのコネクタに
R_ReceiptSignatureとD_Executeメッセージを送る。
• 一つでも制限時間を超えてしまった場合は、送金先およ
び全てのコネクタにD_Abortメッセージを送る。

30.
リファレンス
• https://adrian.hopebailie.com/making-history-in-berlin-78f1533787f0
• https://www.slideshare.net/Interledger/interledger-workshop-berlin-1-june-2017
• http://www.coindesk.com/consensus-2017-blockchain-tech-leaders-predict-interoperable-future/
• Interledger Payment App Example
• https://github.com/Shopify/interledger-payment-app-example
• Thunder, Lightning and Interledger
• https://medium.com/@ahopebailie/thunder-lightning-and-interledger-ceae9b5d92b4
• 現在のRFC詳細
• ホワイトペーパーからさらに詳細化されたRFCは以下にあります。ホワイトペーパーに記載のない具体的な
点は以下を確認してみてください。
• https://github.com/interledger/rfcs

31.
Thanks