EXE #3

1. AIを協力して作成するDapp
Recruit Lifestyle | Tomoya Honjo

2. 自己紹介
INTRODUCTION
本庄智也 リクルートライフスタイル所属
職歴
• Software Engineer (〜2016/10)
• Data Planner/BI Engineer (現在)
• Blockchain R&D
主に仕事ではデータのマネジメントやデータを活用の企画・実行
ブロックチェーン系のイベントやミートアップもたまに

3. INTRODUCTION
トークセッションEthereumのハッカソン
コミュニティ活動

4. 本日お話したいこと
INTRODUCTION
今回作ってみた
複数のプレーヤが関わるAIの構築
をCollaborativeに行う枠組みの紹介

5. AIとBlockchain
Background
出典) Blockchain EXE#1 ブロックチェーンとAI・ロボティクス・IoTの相互作用

6. Data ExchangeとBlockchain
Background
出典) http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/creating-a-successful-
internet-of-things-data-marketplace
How a digital marketplace creates value.
• Building an Ecosystem
• Opening up new monetization opportunities
• Enabling crowdsourcing
• Supporting Interoperability
• Creating a central point of “discoverability”
• Achieving consistent data quality
インセンティブに
トークンを活用

7. Dappsのアイデア
Background
(1) ブロックチェーンによって
VerifyされるAI
(2) データ提供のインセンティブ
としてのトークン
データ提供者もトークンに
よって報酬を得られて、デー
タやAIの成長がverifyされる
ブロックチェーンのアプリ
ケーション！
(3) Micro-PaymentによるUsage
Basedの利用

8. AI Share Dappsの概要
Dapps Overview
• Dapps参加の各プレーヤーが貢献に応じてリワードが得
られるような枠組みを構成するコントラクト
• AIのユーザーは、usage basedでqueryに対してマイク
ロペイメントで課金される
• AIの成長履歴がコントラクトに書き込まれており、あと
から検証できる。

9. AIの構成要素の簡易モデル
Dapps Overview
(2) データ
サイエンティスト
(1) データ
(3) AI/学習モデル
*ここでは何らかのデータで学習させた結果、出来上がったモデルを”AI”と呼んでいる
トレーニング
入力
犬です
出力
(2’) Algorithm

10. Players in the ecosystem
Dapps Overview
(3)Data Provider
(IoT/Human)
• データの提供者
• IoTデバイスや人
• n数は1千以上
(4)AITrainer
• 学習データから、
AIをトレーニング
する人
• n数は1-100
(1)Service
Provider
• 全体のグランドデザ
インをする
• モデルを動かすサー
ビスを提供
• n数は1
(2)Storage
Provider
• データを保存する
ストレージを提供
• nは1以上
*今回の実装では(1)と(2)は同じプレーヤーと想定

11. Contract Design
Dapps Overview
*今回の実装では(1)と(2)は同じプレーヤーと想定
「誰が」「どんなパラメ
タで」「誰が提供した
データで」作ったモデル
かを登録
AIRegistry
DataProviderが提供する
データのメタ情報を登録
するレジストリDataRegistry
AIの利用者とAIを動かし
ているサーバーの間の
micro paymentチャンネ
ル
EthPayment
Channel
• AIの利用料を保持する
コントラクト
• 各プレーヤの貢献度
に応じて分配
Revenue
Bank

12. Service
Provider
RevenueFund
Storage
Provider
(1)AIRegistryを
デプロイ
AIトレーナー
DataRegistryAIRegistry
EthPayment
Channel
(2-1) データを
登録
(2-2)ストレージ
に保存
4-1) モデル作成
3-2’) データ取得
3-1) 参照
参照
4-3) モデル登録
Storage
Provider 4-2) モデルの保存
UserServer
(5) PaymentChannel
をデプロイ
6-1) チャンネ
ルオープン
6-2) クエリ課金ベースで使用
6-3) チャンネ
ルクローズ
6-3’) 支払いの
転送
High-level architecture
Dapps Overview

13. Technical challenges
Dapps Overview
データプロバイダーが大量に存在しうる
エコシステムの特徴
Ethereum Computation/Storage Cost
(1) 支払い分配コスト: 支払いを分配するとき、均等に全データプロバイ
ダーに配布すると、コストが高い
(2) AIモデル登録コスト: AIモデルを登録する際、コントリビューターとな
るデータプロバイダーの指定にコストがかかる
チャレンジ

14. (1) 報酬分配コスト
Dapps Overview
全員に等しく分
配すると計算コ
ストが高い！

15. (2) AIモデルの登録コスト
Dapps Overview
モデル毎に利用した
データの提供者アドレ
スを登録するとスト
レージコストが高い

16. Solutions
Dapps Overview
(1) 報酬分配
コスト
Probabilistic Payment
多数のaddressからランダムで報酬を受け取れるaddressを選択すし、長期
で見ると均等にされてくるようにする。
(2) AIモデルの
登録コスト
Merkle Tree + Punishment
• データの提供者アドレスはマークルツリー構造で保持して、外部スト
レージに保時。ツリーのルートハッシュだけContractに記録。
• (1)で選ばれた人 (or デバイス) のアドレスをある程度信用できる誰か
(今回はサービスプロバイダー) がコントラクトにプッシュ。
• そのアドレスに不正があると判断した人は、正しいaddressとmerkle
proofを送り、チャレンジができる。Service Providerは不正した場合に、
罰を受ける。
Problem Solution

17. (1) Probabilistic Payment
Dapps Overview
0xa1..
0x22..
0x12..
0x31...
Data Providers
︙
0
1
2
n
Probabilistic
Payment
10ETH
支払い
ランダムで
1つ選択して
支払い

18. Dapps Overview
(2) Merkle Tree + Punishment
コントラクトコードを見せながら...
• Data Providerの
addressのリスト
• MerkleTreeは外部
ストレージに保存
• MerkleTreeの
ルートハッシュ
コントラクトに記録

19. Challenges ahead
Limitations
データの来歴について：
デバイスが途中でハックされた場合など、どこまでのデータが”正しいもの”
とするか。それを担保できる仕組みはあるか
→ ゼロ知識証明の応用などでできそう？
サービスプロバイダーが動かしているAIの正しさ：
Service Providerに問い合わせた場合に、その結果が確かにそのモデルによる
ものであるかを担保できるか
フリーライダー問題をどう解決するか：
Storage ProviderやAI Trainerがデータにアクセス可能。ここをTrustlessにし
たり、合意されていない利用を禁止するような構造はできるか
→ DeepMind Healthが取り組んでいるVerifiable Data Auditで解決できる？

20. (この辺詳しくなりたい)
Limitations
• Bigchain DB/IPDB
• IOTA
• Verifable Data Audit by Deep Mind Health

21. Thanks!! 
Tomoya Honjo