02/22(金) は「JDDStudy #5 ブロックチェーンとILP」に参加してきました。
会場は Japan Digital Design 株式会社 さん。
東京駅まで歩いて10分位という場所柄、広さは程よくタイトな感じですが、カジュアルでかっこいいスペースです。 後ろにはこたつ席もあって、なんか不思議な空間ですね（笑）
目次
JDDStudy とは
前回の参加報告を参照してください。
スケジュール
| 時間 | タイトル |
|---|---|
| 19:00～19:10 開演 |
【オープニング】Japan Digital Designについて Japan Digital Design 上原 さん |
| 19:10～19:30 第1部 |
ILP のプロトコルスタックとその関連性 Japan Digital Design 中山太雅 さん |
| 19:30～19:50 第2部 |
ブロックチェーン基盤ソフトウェアの横串性能検証の結果、および開発を通じたノウハウ 三菱UFJインフォメーションテクノロジー 尾根田 倫太郎 さん |
| 19:50～20:00 第3部 |
Zaifから流出したMonacoinの追跡＆Cryptoassets Governance Taskforceの取り組み Japan Digital Design CTO 楠正憲 さん |
| 20:00～20:10 休憩 |
|
| 20:10～21:00 第4部 |
対談：尾根田 倫太郎 さん×楠正憲 さん 会場を交えたディスカッション |
| 21:00～21:20 第5部 |
懇親会 |
| 21:30頃 | 閉会 |
内容
当日のツイートはトゥギャられています。素早い仕事だ。
ライブ配信された動画が公開されています。 雰囲気が伝わると思いますので、こちらもぜひ。
Japan Digital Designについて
Japan Digital Design 上原 さん
以下、個人メモ。
Japan Digital Design
| 金融グループを取り巻く現状 | MUFGでの期待 |
|---|---|
| GAFAやLINE、楽天といったDisrupter (既存の業界を混乱、分裂し、新たな価値を提供するもの) による新規参入 |
外部人材・知見によるStrategic Ailityの発揮 新たなUX |
| ▼競合激化▼ | ▲市場拡大▲ |
| MUFG | MUFG＋Japan Digital Design |
| ▲規制強化▲ | ▼参入障壁▼ |
| 本人確認、個人情報、Anti Money Londaring、安定的規制強化 といったコンプライアンスの要請 |
投資済みの強固なインフラ MUFGの潜在的資産活用(事務、データ、許認可、B/S) |
アプローチ
- 多様な経歴、素養、働き方を受け入れる
(ICT. VB経験者、兼業、フリーランス、外国人) - 新デバイス技術に先陣を切って挑戦
(Al事業化、認証事業化、IoTデバイス試作、中国戦略) - 地銀と協働し、全国視点の商品開発
(高齢化、キャッシュレス、労働力減、情報流通)
外部人材の積極採用
地銀35行とのパートナーシップ
実際にどんなことをやっているか？
- レガシーの活用
- AIファイナンス
- AIスコアリングモデル
- ビジネスモデルの進化
- for MUFG
- for All Banks
- for ASIA
- AWS上にセキュアな環境を自前で構築
- コストを投資に ーインフラのPaaS化ー
- 環境をコンテナ化
- MUFGグループ
- 地銀各行
- 海外子銀行
- 3rd Party(連携)
- アカウントをJDD傘下で払い出し、従量課金
感想
- 前回も思ったけど、やっていることは色々面白そうだなと思いました。
- プラットフォームを作って乗ってもらうというのは結構壮大な計画。スピード感とバリューが見合うかが興味深いと思いました。
- ハードの開発ができるのは面白いですね。うまく流用できるものがあると爆発的に伸びそう。
ILP のプロトコルスタックとその関連性
Japan Digital Design 中山太雅 さん
以下、個人メモ。
ILP とは一体何なのか？
ILP (=Interledger Protocol) とは
一言で言うと異なる台帳間で価値を移動するためのプロトコル
なぜILPが必要か？
基本的な思想
全世界の人が単一の台帳を使うのは無理という前提に立っている。
この前提で価値を簡単に相手に届けたい
例えば
- 価値の管理主体や単位が異なる場合に安全に自分の価値を届けたい
- このデータのやり取りを仲介してくれるのが ILP
Connector
複数コネクタを使って連続的に価値をホップさせていくこともできる。
価値のインターネット(VALUE Internet of Value)
RFC のお手伝いをした話
RFC とは？
- 技術的な仕様を記したドキュメントの事
- 全世界に公開され、誰でも閲覧できる
ILP の仕様
ILP の RFC は W3C の Interledger Payments Community Group の RFC。
何故手伝おうと思ったのか？
実際に手伝ったもの
- Dynamic Configuration Protocol
- Relationship between Protocols
- Route Broadcasting Protocol
Route Broadcasting Protocolはまだマージされていない
ILP の全体像と責務
よく見るプロトコルスタックの画像
これだけだとプログラムとしての動きを理解するのが難しい
分からない
- 実際誰がどう接続しているのか
- IP レイヤーのどこで動いているのか
- 各プロトコルのデータ構造
コネクションは大きく３つ存在
パケットの構造
- rfcs/0023-bilateral-transfer-protocol.md at master · interledger/rfcs · GitHub
- rfcs/0027-interledger-protocol-4.md at master · interledger/rfcs · GitHub
- rfcs/0029-stream.md at master · interledger/rfcs · GitHub
- rfcs/0031-dynamic-configuration-protocol.md at master · interledger/rfcs · GitHub
- rfcs/0033-relationship-between-protocols.md at master · interledger/rfcs · GitHub
- rfcs/asn1 at master · interledger/rfcs · GitHub
- Canonical OER
最新動向
コネクタをスケールするための構造
- これまでは WebSocket 一本前提だった
- 理想は１つの ILP アドレスに対して複数のコネクタインスタンスを立てられる構造
ILPv4 について
感想
- ILP、知らなかったけどとても面白かった。
- 短時間で聞くには話のスコープとボリュームが大きかったので、機会を見てもう少し調べてみたい。
- 他のものとの比較があると、もう少しイメージがしやすかったかも。
ブロックチェーン基盤ソフトウェアの横串性能検証の結果、および開発を通じたノウハウ
三菱UFJインフォメーションテクノロジー 尾根田 倫太郎 さん
[資料は公開されたら追記します]
以下、個人メモ。
検証条件(共通部分)
| クラウド環境 | AWS Tokyo Region |
|---|---|
| インスタンスタイプ | m5.large 2vCPU 8GBメモリ 10Gbps |
| スマートコントラクトの処理内容 | 口座Aから口座Bへの送金(振替) |
| 計測項目 | 1. 1件あたりの処理時間 2. 秒間スループット |
Hyperledger Fabric 1.4 性能検証結果
ネットワーク構成
処理シーケンス
送金1件あたりの処理時間
サーバープロセス多重度に対するスループット
Corda Enterprise 3.1 性能検証結果
ネットワーク構成
処理シーケンス
経過時間に対するスループット
送金1件あたりの処理時間
サーバープロセス多重度に対するスループット
Quorum 2.1 性能検証結果
https://www.jpmorgan.co.jp/country/JP/JA/Quorum
ネットワーク構成
処理シーケンス
送金1件あたりの処理時間
サーバープロセス多重度に対するスループット
まとめ
| Hyperledger Fabric 1.4 | Corda Enterprise 3.1 | Quorum 2.1 | |
|---|---|---|---|
| アプリケーションサーバ プロセス多重度 |
1800多重の場合 | 6多重の場合 | 30多重の場合 |
| 送金1件あたりの処理時間 | 平均3.,209ms | 平均1,013ms | 平均104ms |
| スループット | 平均449件/秒 | 平均4.7件/秒 | 平均265件/秒 |
| 並列送金依頼の性能向上 | ○ | × | ○ |
| 送金1件あたりの処理時間の散乱度 | 小 | 大 | 小 |
| 開発容易性 (検証環境やスマートコントラクト開発を独力で遂行できたか) |
ベンダーのサポート無しでは環境構築、スマートコントラクト開発共に困難。 | ドキュメントが豊富であり、独カで環境構築、開発が可能 | 環境構築は難易度高い。スマートコントラクトの開発は容易。 |
※平均値は、最大多重度の計測結果から算出。
感想
- こういう検証をきちんとするのは良いなと思った。
- 環境構築の容易さは求めていないものも有るのかなと思いつつ、構築できなければ評価も採用もできないですね。
- 性能検証なので使わなかったのだと思いますが、実際の運用ではコンテナ化したインスタンスも使うと思うので、そういう検証もしていたら聞いてみたいと思いました。
- 環境構築手順などはお金をかけて得たものなので難しいとは思いますが、ハマりどころやポイントなどが公開されたら読んでみたいな、と思いました。
Zaifから流出したMonacoinの追跡＆Cryptoassets Governance Taskforceの取り組み
Japan Digital Design CTO 楠正憲 さん
www.slideshare.net
Blockchain関連でhackathonを実施されたという話が最初にありました。
datablockchainhack.connpass.com
以下、個人メモ。
こちらの話と、事件が起きて以降の動きについてがありました。
事件が起きて以降の動きは省略してあります。
仮想通貨の交換業者やPFを狙った主なサイバー攻撃
Zaif事件
monacoin追跡hackathon
10月20日から動き始めたmonacoin
感想
- この逆探知のニュースがネットなどに流れた日に前回の JDD Studyがあったので、その後どうなったのかに興味がありました。
- 逆探知自体は、まだ解析しきれていない部分も残っているということだったので、続報が気になります。
- 解析にインターンの人が関わっているという話もあって、面白い人材が集まっているんだなと思いました。
- メモには書きませんでしたが、事件以降の政府や国際機関の動向のような話もあって、面白かったです。
- 個人的には、ウォレット周りは普及の鍵のような気がするので興味を持っています。
対談：尾根田 倫太郎×楠正憲
三菱UFJインフォメーションテクノロジー 尾根田 倫太郎 さん
Japan Digital Design 楠正憲 さん
このタイミングで食べ物と飲み物が提供され、立食形式で対談を聞く形になりました。 自分は相変わらずノンアルコールで。食べ物、美味しかったです。
Youtubeの中継動画がスクリーンに映し出されていましたが、これはとても良かったです。 (対談している二人が座っていて観客が立っているので姿が見えないという声を参加者の方が上げていて、急遽実施されたようですが)
まとめ
内容が濃かったので、レポートを書くのに少し時間がかかってしまいました。 個人的には、これまであまり見てこなかった分野の話なので、知らない話も多くとても刺激を受けました。 比較的新しい分野でもありますし、開発がまさに今されているところなので、今後も追っていければいいなと思います。 こういうイベントを実施できる、というのも Japan Digital Design さんの強みなんだと改めて理解しました。
毎回のことですが、講演者、スタッフ、参加者の皆様、ありがとうございました！
