IoTへのブロックチェーンの導入

IoTへのブロックチェーンの導入 － その課題とスマートシティへの適応 － B-frontier研究所 高橋 浩

目次 IoT 向 け ｽﾏｰﾄｼﾃｨ 向 け １．ブロックチェーン導入の目的 ２．IoTへ導入の要件 ３．適応に向く領域 ４．スマートシティへの可能性 ５．今後の方向性 2

１．ブロックチェーン導入の目的 ブロックチェーン for IoT×ビジネス • 新技術は技術自体への関心から出発して、 • 適用領域拡大に伴い新技術×ビジネス段階へと 進む。 • ブロックチェーンはBitcoinから始まり、Ethereum 登場などを契機に多分野適応へと進んだ。 • また、ブロックチェーンはIoTと相性が良いとの認 識が登場し、“次世代産業創生の起爆剤”などと の期待も登場している。 • ブロックチェーン導入IoTは具体的にどんな役割 が担えるのだろうか？ 3

ブロックチェーン導入IoT先行アプリケーションで なぜブロックチェーンが使われたのか？ ・・から開始する。 アプリケーション 使用目的 採用理由 ADEPT (2015) スマート契約とネットワーク合意の活用 分散化,自律化 スマートシティ (2016) 信頼性向上とフォールトトレランス向上 信頼性 ファームウェア更 新(2016) ファームウェア検証時のデータの完全性、データ認 分散化,信頼性, 証、否認防止の確実な実施 効率化 スマートホーム (2016) 分散信頼と、IoTデバイスとそのデータへのアクセ ス制御の共通プラットフォーム化 分散化＆アクセ ス制御 VANETS(2016) 分散型自己管理システムの構築 自律性 eBusiness (2016) スマート契約に基づく透明な自己管理と自己調整 システムの実現 分散化＆自律 性 SCM(2016) 偽造できないことによるオブジェクト追跡や所有権 記録の実施 トレーサビリティ （信頼性） Slock.it(2015) 分散型管理とスマート契約実行能力の実現 自律性 ＡＤＥＰＴ：自律分散型ピアツーピア遠隔測定システム(by IBM) ＶＡＮＥＴＳ(Vehicular ad-hoc network)：自己管理車両アドホックネットワーク 4 Imran Makhdoom, et al., “Blockchain’s adoption in IoT: The challenges, and a way forward”, Journal of Network and Computer Applications 125, 251-279, 2019.

ブロックチェーン採用の理由は • 信頼性 • 分散化 • 自律化、など 5

ﾌﾞﾛｯｸﾁｪｰﾝ導入 先行IoTアプリケーションで期待されていた ブロックチェーンの特性とは・・ ｽﾏｰﾄｺﾝﾄﾗｸﾄ導入以後 自律性 信頼性 各IoTﾃﾞﾊﾞｲｽ毎に異なる フォールト トレランス データ 整合性 分散管理 分散蓄積 データ認証 監査能力 信頼フリー 操作 ログ管理 二重支出 なし 不変性 6

前頁の大半をサポートするBitcoin向け ブロックチェーンの特性 メリット フォールトトレランス 達成手段 分散公開台帳と非集中化で 中央当局または第三者による調 ネットワークノードのコンセンサスによるTX（トランザ 停不在（分散管理） クション）の検証で 中央DB不在（分散蓄積） 分散公開元帳で 監査可能で不変なTX （監査能力、不変性、二重支払 い無し） 検証済みTXをタイムスタンプ付き偽造不可ブロックチェーン に記録することで（ただし、攻撃者が51％以上のハッシュパ ワーを取得時はブロックチェーンの履歴変更でTX2回消費 の可能性が存在） 透明性（ログ管理） ブロックチェーンネットワークの全ノードがTX順序の同じ複 製維持で 信頼フリー操作 ネットワークノードによる各TXの検証で 認証と否認防止 楕円曲線デジタル署名アルゴリズム（ECDSA）を使用 したユーザー秘密鍵によるTXの署名で 疑似匿名性 公開鍵のハッシュで TXの完全性 TXのSHA-256ハッシュ取得で リプレイ攻撃に対する保護 タイムスタンプの使用で 7

また、IoTアークテクチャは分散化への動向も これらの理 由によって 集中方式 サーバー中心 分散方式 クラウド中心 ブロックチェーン ・より進んだクラウド利用にも弱点がある ・集中型による信頼性・障害対応・高コストへの懸念 Tiago M. Fernández-Caramés, Paula Fraga-Lamas, “ A Review on the Use of Blockchain for the Internet of Things”, IEEE Access · May 2018 8

しかし、冷静に考えると、分散システム へ切り替えのリスクは小さくない IoT BD AI ｸﾗｳﾄﾞ 垂直統合モデル リスク IoT BD AI ﾌﾞﾛｯｸ ﾁｪｰﾝ 水平分散モデル 9

焦点を当てる項目 信頼性、分散化、自律化など、より抽象度の高い目標を目 指すことになる。その決断を可能にする要因は何だろうか？ • IoTの置かれた脅威環境か – 現在、ＩｏＴデバイスは保護されていない環境で動 作していることが多い。 • IoTのセキュリティ要件 vs IoTパフォー マンス要件のバランスか – ビジネス面からの2要件トレードオフ条件考慮が 重要 • 時間軸として・・何時頃からブロック チェーン技術が導入可能かの技術進化か 10

２．IoTへ導入の要件 IoTアーキテクチャとセキュリティの課題 背景１ ゲートウェイ付き分散ネットワーク ゲートウェイ付き無線センサー ネットワーク 情報家電機器 • IoTではネットワークを介して相互接続する組み込みセンサー内蔵 異種デバイス混在環境でのセキュリティ順守などが要件 11

背景２ IoTシステムの特異性 • IoTデバイスのリソース制約は厳しい。 – データストレージ容量、処理能力、限られた電力など • バラバラなサイズ、能力、役割の異種デバイ スが混在している。 • その一方、IoTシステム全体としてのセキュリ ティ要件充足が必須な状況にある。 • 大半の適用領域ではリアルタイム性も必須で ある。 • しかも、将来的にはとんでもない規模のス ケーラビリティが求められる。 12

背景３ IoT市場はまだまだ発展途上 ① 各ＩｏＴシステムは専門性が高い。 ② ＩｏＴプラットフォームにおける一方のサイドがデバ イスなので、ネットワーク効果によるプラット フォーム拡大や寡占化が起き難い。 ③ その結果プラットフォームが乱立し、市場の断片 化が発生し易い。 ④ ビジネスモデル構造が個別化するので、工夫を 凝らしたIoTプラットフォーム活性化が必要になる。 ⑤ 唯一のIoTプラットフォームで活性化が不充分な 場合他プラットフォームとの連携が模索される。 ⑥ 但し、連携コストは高い。 ⑦ その結果、スケール化が限定される。 13 高橋 浩, “IoTプラットフォーム市場の高付加価値化 －IoTシステムはなぜスケール化が難しいのか－”, 横幹, Vol.13, No.1, 2019

IoTへブロックチェーン導入の期待は大きい IoTへブロックチェーン導入の期待効果 • 現在のＩｏＴシステムはサイロ化していることが多 いのに対して・・ ブロックチェーンをIoTに導入すると・・ 1. 全IoT機器に個別ＩＤを付与することが出来る ⇒データの出所を確立し、証明できる。 2. 資産化が出来る ⇒経済的決断ができる。 3. 独立化できる ⇒自己管理ができる。 14

IoTへブロックチェーン導入時の層構造提案は多い 仕事/機能/目的 活動とサービスの管理 アプリケーション層から受け取ったデータに基づいて、ビ ジネスモデル、グラフ、フローチャートなどの作成 ビッグデータ分析に基づく意思決定プロセスの支援 将来の行動や戦略の決定に有用な活動 サービス提供 ビジネス層へのインタフェース提供 データアクセス制御 ミドルウェア内のオブジェクトの情報処理に基づくアプリ ケーションのグローバル管理 住所と名前に基づく要求者とのサービスのペアリング 受信データの処理と決定、ネットワークワイヤプロトコル を介した必要なサービスの提供 サービス管理 他層からデータ受信して処理と計算と意思決定能力 生成されたデータのサービス管理層への転送 機器間および機器から受信機へのデータ送信 センサーから情報処理システムへのデータ転送 転送元ノードから転送先ノード/クラウドサーバーへの データ転送 センサーデータの収集 データをデジタル化してオブジェクト抽象化層に転送 物理的コンポーネント、スマート家電、電力供給業者 などの基本的ハードウェア構成など ビジネス層 ビジネス層 アプリケー ション層 アプリケー アプリケー アプリケー アプリケー ション層 ション層 ション層 ション層 ｻｰﾋﾞｽ管理 /ﾐﾄﾞﾙｳｪｱ層 ﾐﾄﾞﾙｳｪｱ層 クラウド層 ｵﾌﾞｼﾞｪｸﾄ ﾈｯﾄﾜｰｸ層 ﾈｯﾄﾜｰｸ/ﾄﾗ ﾈｯﾄﾜｰｸ層 ﾈｯﾄﾜｰｸ層 抽象化層 ﾝｽﾐｯｼｮﾝ層 ｵﾌﾞｼﾞｪｸﾄ/ 知覚層 知覚層 ｾﾝｻｰ層 知覚層/ ﾃﾞﾊﾞｲｽ層 ｾﾝｼﾝｸﾞ層 物理層 Imran Makhdoom, et al., “Blockchain’s adoption in IoT: The challenges, and a way forward”, Journal of Network and Computer Applications 125, 251-279, 2019.

代表的ブロックチェーンプラットフォーム比較 Features Bitcoin Ethereum Hyperledger-Fabric 完全に開発された 〇 〇 〇 マイナー参加可能 Public Public, Private, Hybrid Private 信用不要運用 〇 〇 Trusted validator nodes 複数のアプリケーション 金融分野のみ 〇 〇 コンセンサスルール PoW PoW, PoS PBFT/SIEVE コンセンサス終了性 × × 〇 ブロックチェーンフォーク 〇 〇 × 少ない手数料 × × オプショナルに可能 スマートコントラクトの実行 × 〇 〇 TXの整合性と認証 〇 〇 〇 データの機密性 × × 〇 ID管理 × × 〇 鍵管理 × × 〇（CAを通じて） ユーザ認証 デジタル署名 デジタル署名 登録証明書に基づく デバイス認証 × × × 攻撃に対する脆弱性 51%, linking attacks 51% > 1/3故障ノード TXスループット 7 TPS 8-9 TPS >3500 TPS TX単一確認における待ち時間 10 分 15–20 秒 Bitcoin, Ethereumより短い スケーラブルであるか？ × × × 16

IoT向けで現在お薦めのコンセンサスルール PoW 適応分野 金融 PoS 各種 PoET 各種 PBFT DBFT IOTA 各種 各種 金融(現在) ｴﾈﾙｷﾞｰｺｽﾄ 高い （PoWに比 （PoWに比 して）低い して）低い 低い 低い 良好 計算ｺｽﾄ （PoWに比 （PoWに比 して）低い して）低い 高い（ｺ ﾐｭﾆｹｰ ｼｮﾝ複 雑） 低い 低い 即時 即時 確率的 短い 短い 短い 許可有り 無し両方 許可有 り 許可有 許可無し(現 り 在) 必要 （Ex.Intel SGX) 不要 不要 高い 合意最終性 確率的 確率的 TX検証時の 長い 遅延 ﾌﾞﾛｯｸﾁｪｰﾝ のﾀｲﾌﾟ （PoWに比 （PoWに比 し）短い し）短い 許可無 許可有り し 無し両方 特殊ﾊｰﾄﾞが 必須で 不要 必要 はない Bitcoin 確率的 Ethereum HyperledgerFabric 不要 17 Imran Makhdoom, et al., “Blockchain’s adoption in IoT: The challenges, and a way forward”, Journal of Network and Computer Applications 125, 251-279, 2019.

ブロックチェーン for IoT 課題は多い • • • • • 合意できるIoT参照モデルがない。 IoTに最適なコンセンサスルールが無い。 パフォーマンスが低い。 スケーラビリティが低い。 IoTセキュリティが完全でない。 18

ﾌﾞﾛｯｸﾁｪｰﾝﾌﾟﾗｯﾄﾌｫｰﾑ中心 ブロックチェーン for IoT 現状評価 要件と実現レベル間には大きなギャップがある。 • 加えて、集中型の既存IoTシステム（多くはク ラウドベース。最近急速に進展）との優劣比較 が殆ど整理されていない。 – 比較対象ＩｏＴシステムの例 • クラウド系：グーグルのクラウドIoTプラットフォーム、 AWSのIoT Coreサービス、マイクロソフトのAzure IoT、 Armのペリオンなど • 個別システム： （スマートホーム）GoogleのＮｅｓｔ、（ス マートシティ）AlibabaのCloud City Link、など 19

３．適応に向く領域 非常にハードルが高い要件 • 異種デバイスの混在に対応し、 • リソース制約のあるデバイスも含めた全体として 高度なIoTセキュリティを実現し、 • スケーラブルでリアルタイム性能が良く安くて安 全なシステムの構築が目標。 • これらのことを、標準が全体としては完備してい ないことを前提に、 • 変化する市場ニーズに対応する時々のソリュー ションを継続的に提供して行くことが求められる。 20

ﾌﾞﾛｯｸﾁｪｰﾝｲﾝﾌﾗｽﾄﾗｸﾁｬ 加えてインフラストラクチャの状況が厳しい ブロックチェーンインフラストラクチャの状況 • IEEE 802.15.4, 802.11a/b/g/n,p • LoRa, ZigBee, NBIoT, SigFoxなど • オープンスタンダードあるいは デファクトスタンダードなもの 低帯域幅・低電力の無線通信機器を介して インターネットやゲートウェイ機器に接続 • 各種市販IoT機器 • 各種ｾﾝｻｰ内蔵機 器 IoTデバイスは千差万別で、リ ソースにも制約があるため、クリ ティカルマスのインフラが登場する 状況にはほど遠い。 民生用IoT機器およびｾﾝ ｻｰ内蔵デバイスなど 既存ＩＴインフラ、特にスマホなどは、ク リティカルマスに規模拡大し、インフラと vs して機能する強力な計算とネットワー キングデバイスとなった。 21 金融分野（および既存IT環境）はこちらに近い

ブロックチェーンインフラストラクチャは 一段と難しい問題をクローズアップさせる • デバイスが多様で、 • 通信手段が多様で、 • クリティカルマスのインフラが不在 例えIoT機器に統一IDが付与されても、これを どのようにして広域的に活用するか？ また、ブロックチェーンプラットフォームのス ケーラビリティ問題とどのように折り合いをつ けるか？ 22

ブロックチェーン視点でのIoTセキュリティ要件は多々あるが IoT ｾｷｭﾘﾃｨ要件 有無 ﾌﾞﾛｯｸﾁｪｰﾝ技術 信頼フリーの運用 〇 全て実現 分散ストレージ 〇 全て実現 非集中の制御 〇 全て実現 データの整合性（Integrity） 〇 全て実現 データ認証 〇 全て実現 データの機密性/プライバシー 〇 Hyperledger-Fabric 仮名（Pseudonymous） IDs 〇 全て実現（仮名IDに基づく） プライバシー保護計算 × ユーザー登録（Enrolment） 〇 Hyperledger-Fabric アイデンティティ管理 〇 Hyperledger-Fabric ユーザ認証 〇 全て実現 ユーザ認可（Authorization） 〇 Hyperledger-Fabric キー管理（キー発行と失効） 〇 Hyperledger-Fabric 制限付きネットワークアクセス 〇 Ethereum & Hyperledger-Fabric デバイス認証 × ソフトウェアの整合性チェック × ランタイム/同期ソフトウェア更新 × 侵害されたデバイスの検出 × IoT中心の合意プロトコル × IoT重視のTX検証ルール × 合意の最終性（Consensus Finality） 〇 Hyperledger-Fabric フォーク無し 〇 Hyperledger-Fabric 23

ブロックチェーン視点でのIoTパフォーマンス要件は多々あるが IoT ﾊﾟﾌｫｰﾏﾝｽ要件 有無 ﾌﾞﾛｯｸﾁｪｰﾝ技術 自律システム 有り Ethereum & Hyperledger-Fabric （スマート契約に基づい て） TX確認における低遅延 有り Hyperledger-Fabric 通信の複雑さが少ない 有り Bitcoin, Ethereum, IOTA スケーラビリティ △ IOTA -（ネットワークサイ ズが大きくなると、TXの確 認レートが上がることにより) 有り印が付く場合でも達成水準は不充分 24

ﾌﾞﾛｯｸﾁｪｰﾝ導入 先行IoTアプリケーションからの示唆(再録) ブロックチェーン導入IoT先行アプリケーションの比較ポイント “なぜブロックチェーンは使われたのか？”に 加えて・・ ① どのブロックチェーンプラットフォームが使 われているか？ ② 従来のどのような問題が解決されたか？ ③ ブロックチェーンのどのような問題が解決 されたか？ 25

①、②、③の全体概要 ①ブロック チェーンプ ラットフォー ム ②解決され た問題 ③解決され たブロック チェーンの 問題 ADEPT ｽﾏｰﾄｼﾃｨ ﾌｧｰﾑｳｪｱ 更新 ｽﾏｰﾄﾎｰﾑ VANETS eBusiness SCM Slock.it Ethereu m 明確にされ ていない （独 自？） PoWコン センサス保 有独自 PoWコン センサス未 使用独自 Ethereu m Ethereu m IBMﾌﾞﾛｯｸ ﾁｪｰﾝﾌﾟﾗｯﾄ ﾌｫｰﾑ (Hyperledg er-Fabric) Ethereu m 一元化機 関、単一 障害点、 ユーザー/ データのプ ライバシー、 相互作用 起因エラー への対応 異種デバイ スから受信 したデータ を共有する のが困難 だった状況 を解決 サイバー攻 撃の影響 を軽減し、 ネットワー クの輻輳 問題を回 避 IoTデータ のアクセス 制御、デー タの機密 性、整合 性、可用 性、DDoS 攻撃に対し て保護と保 証 集中管理 とプライバ シー問題の 解決 集中管理 と透過的 データ共有 /サービス における問 題の解決 集中型 データベー スの脆弱 性の解決 製品のアク セス制御と 手動による 受け渡しの ための集中 管理と人 的介入問 題の解決 スケーラビ リティ問題 の解決 （ブロック チェーンサ イズに関 連） マイニング における PoW使用 回避による 計算集約 度、TX確 認における 待ち時間、 エネルギー 消費の解 決 特に無し 特に無し 特に無し ブロック内 でマイニン グされる TX数の減 少によるス ケーラビリ ティ問題の 解決 ユーザー/ 特に無し データのプ ライバシー、 ID管理、 データに対 するユー ザーアクセ ス制御、ス ケーラビリ ティ 26 Imran Makhdoom, et al., “Blockchain’s adoption in IoT: The challenges, and a way forward”, Journal of Network and Computer Applications 125, 251-279, 2019.

ブロックチェーンプラットフォームの選択 • Ethereumの利用率が高いのは事実だが、 • 特に、スケーラビリティが必要と思われるス マートシティ、ファームウェア更新、スマート ホームなどでは独自が目立つ。 従って、ブロックチェーン適応領域の分 類が重要になる。（現状ではこのよう な試みは殆ど行われていない。） 27

Slock.it スマートコントラクトを利用したIoTデバイスサービスの管理 ・借りる ・入金 ・開く/再開＆閉じる ﾌﾞﾛｯｸﾁｪｰﾝ ｻｰﾊﾞｰ ・Slock / Itemの登録 ・入金と料金の設定 ・開閉（制限あり） ｽﾏｰﾄ ｺﾝﾄﾗｸﾄ 組み込み機器（ブロックチェーンクライアントソフトウェア） Rasberry Pi • トークンによるスマート電 子ロックシステム • • • トークンは暗号通貨を使用 通貨はEthereum上で購入 何か借りたいSlock所有者は、 電子ドアロックへ時間限定アク セス値を設定 利害関係者は、Slockを識別し、 要求された金額を支払い、適 切に署名されたメッセージを介 してロック解除 • Intel Edison Samsung Artik S ・Bluetooth ・Z-Wave ・Zigbee ・電源ソケット ・ドア ・洗濯機 ・その他のスマート家電 2015年9月創業 本社：ドイツ・ザクセン州 従業員数10名以下 パートナーにはサムソン、 Microsoftなども 28

代表的IoTアプリケーションのスケッチ （スマートシティの例） • 何十万ものIoTノードからセンサーデータ発生 • 一日に数百万トランザクションの処理が必要かも • 急激に増加するデータの蓄積への対応 – IoTデバイスのストレージ容量制約などと関係 取引料金でマイクロペイメントあるいは特別の選 択肢提供が必要か？ IoT機器/データのHW/SW障害あるいは人的ミ スによる破損などへの対応が必要か？ 各種IoTデバイス中のファームウェア、ソフトウェア の同期更新の仕組みが必要か？ 29

領域分類の試み１：セキュリティ要件×パフォーマンス要件： ① Everledger社によ るダイヤモンド認証 セキュリティ要件 高い ③ ② Slock.it 2015年創業 本社：ロンドン 2017年段階で既に登 録ダイヤ数100万個 スマートシティ ファームウェア更新 スマートホーム ＳＣＭ IoTシステムへのブロック チェーン導入 低い パフォーマンス要件 【既存IoTシステム】 低い 高い

領域分類の試み２：スケール要件×コスト要件 スケール要件 ④ 広い ブロックチェーン型IoTシステム スケール重視（＋信頼性） タイプ１：スマートシティ(p.24） さほどでもない クラウド型各種IoTシステム AWS-IoT Asure-IoT ペリオンIoT、など コスト要件 シビア（廉価に） C/S型各種IoTシステム 【既存IoTシステム】 ブロックチェーン型IoTシステム コスト重視（＋信頼性） タイプ２：スマートシティ（地域活性標準形） 導入は多数展開でも 参考 ⑤ 狭い DeNAの配車サー ビス「タクベル」 ：白ラベル・プ ラットフォーム

ブロックチェーン適応領域分類の試み(続) • （前頁図式に加えて）ブロックチェーンインフラ ストラクチャのパターン化が必要になる。 • 加えて、これとブロックチェーンプラットフォーム のパターン化による領域分類とのクロス分析 （適応領域の細分化）が必要になる。 • また、その他の領域分類指標の抽出も必要に なる。例： – スケーラビリティ問題回避の手法として、ブロック チェーンのインターネット化の提案がある（by Fabian Vogelsteller) – このような手法の向く領域の特定が必要になる。 32

IoTへのブロックチェーン導入(中間まとめ) • 現時点でブロックチェーン導入で実用的に有 利な領域は結構限定される。 • しかし、今後を考えると、スケール化＆低コス ト化、その源泉の分散化・信頼性アーキテク チャは超魅力的！ • 一般解を想定するにはまだ未成熟で暫く時間 が掛かる。 • ターゲットを絞って（独自）プロジェクト推進 or 大規模研究（階層化モデル研究など）が進行 中と認識する。 【集中型と分散型の最適ミックス形態など】 33

４．スマートシティへの可能性 https://www.e-zigurat.com/innovation-school/blog/blockchain-and-smart-cities/ ブロックチェーンとスマートシティ スマートシティの・・・・・・・ 「スマート」意思決 定に対する市民への 報い ユニバーサル IDカード ローカルコマースの 優先順位付け IoTデバイスの セキュリティ ・・から考える ① ② 土地、財産、住宅 管理 スマートデバイスの 相互運用性 ユニバーサルデータスト レージプラットフォーム ④ 各部門の透明性 ⑤ ③ 公共交通機関の改 善（MaaS的） 都市計画 ④ エネルギー、水、汚染 管理 キーレス署名インター フェース 34

• https://www.e-zigurat.com/innovation-school/blog/blockchain-and-smart-cities/

スマートシティへの取組み姿勢 • 金融系とIoT系が混在している。 – 実現手法や実現可能性は一般に異なる。 • トータルビジョンに価値が有る面があるが、 ビッグプロジェクト情報の咀嚼・評価には注意 が必要かもしれない。 – ビッグネームは膨大な予算と威信をかけて、有望 技術面で先行したい思惑がある。 – 研究パワー投入で現状課題突破の意識も強い。 • また、システムの肝が明記（公開）されないこ ともある。 • 従って、単なるサーベイでは済まない！ – 探索的視点からの取組みが必要である。 35

IoT/金融混在系 ユースケース事例 探索的視点からの取組み分析例 公共交通機関の改善(MaaS的) Block-VN：スマートシティ向け分散型ブロックチェーンベース 車両ネットワークアーキテクチャ • インテリジェントで安全で分散型の自律型輸送シ ステム構築が目標 – – – – 共有がスマートシティの主要資産の1つ（カーシェア） よりスマートな車両、より安全で疲れにくい運転 イベントデータレコーダ（EDR）の搭載 大規模ストレージデバイスを備えたPCと車両用ス マートアプリケーションを装備 – 将来の課題にも対応 – ノードの移植性や自動車間での仮想マシン移動も P. K. Sharma et al., “Block-VN: A Distributed Blockchain Based Vehicular Network Architecture in Smart City”, J Inf Process Syst, Vol.13,36 No.1, pp.184~195, February 2017.

ユースケース事例(続) 車両は他の車両 と共有して安全な 方法でネットワー クを構築 Block-VNの概観 このメカニズム で、フォールトト レランス、分散 操作、管理サー ビス、プライバ シー、セキュリ ティを実現 赤丸の付いた車両ノードは、リクエスト/レスポンス要求を処理するマイナーノード 残りは普通ノード。普通ノードはマイナーノードにサービス要求メッセージ送信可能

ユースケース事例(続) Block-VNモデルアーキテクチャ 自動車部門は詳細情 報を失効機関に提供 自動車部門（製造業者） 失効機関 失効機関は、どの車両をマ イナーノードにするかの権限 を保有 Block-VNへ の車両の出入 りが存在 Block-VN 補足： Public型。透明性は高いがス ピードなどに難点 （Ｐｒｉｖａｔｅ型にしてパフォーマ ンス、スケーラビリティ、セキュ リティに重点を置く方が良い場 失効機関は、どの車両をマイナー 合もありうる） ノードにするかの権限を保有 38

ユースケース事例(続) Block-VNのサービスシナリオ • ＳｍａｒｔＰａｙ： – 車両情報から自動車の燃料が足りるか判断 – 有利なガソリンスタンドをピックアップ – 自動支払い – 適切な駐車場の探索 – 駐車料金支払い • ＳｍａｒｔＳｈａｒｅ： – 自家用車の所有者は、同様のコースに向かう他 の人に空席を付与（リアルタイムのライドシェア） – Uber、Lyftなどと異なり分散型で実施 39

上記探索的分析例からの示唆 • 結局、金融的価値（支払い手段の効率化、支 払いの自動化、など）の付与に行き着くのか • そうなれば、前提としてのIoT機器の統一ID付 与も生きてくるかも。 • あらゆるものの資産化にも展望が拓けてくる • しかし、これの実現のためには、あらゆるセン サー取得データの価値に対するマイクロペイ メントのような機能が廉価・広域に利用可能 な環境が必要になる。 40

スマートシティへの可能性（中間まとめ） • 現状で共通インフラ基盤の構築は不可能 公共交通 – 絞り込み過ぎては「スマートシティ」でなくなる。 – ビジョン先行で象徴的実験システムではPoC化 夢と実用性を兼備したプロジェクト企画とブラ ンド確立に独自の工夫が必要 – デザイン力、資金力、研究力、技術力結集（例： オープン化、コンペなども） 時間（技術の進歩）を味方にすることも重要 41

今後の方向性 まずはIoT分野にフォーカスしてみると・・ IoTにフィットするコンセンサス ルールは難しい 暗号通貨向け要件とは明確に異なる。 セキュリティ系の要件例： • • • • • • • IoT重視のTX検証ルール パフォーマンス系の要件例： • 低遅延時間 シビル攻撃の回復力 • 低計算コスト 合意の最終性（即時） • 低エネルギーコスト フォーク回避 • 通信の複雑さが少ない 最大障害ノード数を許容 デバイスの整合性チェック 42 DoS攻撃の回避

ブロックチェーンとIoTデバイスの統合も難物 • 当面はフォグコン ピューティングのコ ンポーネント活用 が現実的か？ • 異種IoTデバイス からデータをブロッ クチェーンに送信 する方法の設計・ 開発も必要 フォグコンピューティングを使用したブロック チェーンとIoTデバイスの統合概念図 43

https://www.fierceelectronics.com/components/smart-sensors-fulfilling-promise-iot IoTの約束を果たすスマートセンサー の例 セキュリティ エコシステム サービス Stage5 インターネットゲート ウェイ、データ獲得 システム センサー/ アクチュエーター データセンター/ クラウド エッジIT ブロック チェーン 基本的にア ナログデー タソース デバイス、 機械、人、 道具、車、 動物、衣服、 おもちゃ、環 境、ビル、な ど 解析 管理 制御 解析 管理 制御 解析 管理 制御 解析 管理 制御 システム構築までには様々なプロセスがある。 特定ニーズ向けソリューション実現でかなりの個別化（カスタマイズ）が発生する。44 ブロックチェーンがstage5となるか、stage4の入れ替えとなるかは未知数

• https://www.fierceelectronics.com/components/smart-sensors-fulfilling-promise-iot

スマートシティ全体を考えてみると・・ スマートシティへの取組み(まとめ) 機能例など （ビ ア プジ リネ ス ） サ（ ーＤ Ｂ ビ層 ス） ローカルコマースの順位付け 公共交通機関の改善 キーレス署名インターフェース 従来 企 業 α 土地、財産、住宅管理 各部門の透明性 スマートデバイスの相互運用性 ユニバーサルデータスト レージプラットフォーム 企 業 α スマートシティ（複雑なエコシステム型） 企業１ PL型企業A 企業２ ・・ 企業３ 企業４ PL（BC）型企業B ・・ PL（BC）型企業C 企業５ 企業１ PL（BC）型企業D 企業７ 企業１ 企業４ 企業９ 企業10 企業６ 企業８ 企業11 ・・ ・・ ・・ （通 製信 品層 ） IoTデバイスのセキュリティ Ethereum α 企業12 PL型企業E Ehereum 企業13 ・・ （物 部理 品層 ） エネルギー、水、汚染管理 企 業 企業4 企業10 PL型企業D 企業14 ・・ エネルギー、水、汚染管理 各種IoTデバイス Nestサーモスタット 企 業 α 企業15 企業16 企業17 ・・ 垂直統合型 様々なプラットフォームの相互運用やスケーラビリティとパフォーマンスのバランス調整が行われる。 45 各種インターフェースのUXなどに新たな工夫が必要とされる。

IoTの成長/進化とともに登場する新たなスマートシティの例 ハイブリッドネットワークアーキテクチャ ｽﾏｰﾄﾎｰﾑ ｽﾏｰﾄ病院 コアネットワークの分 散アーキテクチャ ｽﾏｰﾄ交通手段 ｽﾏｰﾄ産業 最下位エッジネットワー クの集中アーキテクチャ ｽﾏｰﾄ駐車 エッジネットワークの分 散アーキテクチャ ｽﾏｰﾄﾓｰﾙ ①グローバルに分散＆ローカルに集中（信頼性、効率、スケーラビリティを並立） ②エッジノードは低遅延＆NW帯域幅使用のリアルタイム処理を実現 ③エッジノードで前処理したデータはコアネットワークに転送 ④信頼性の定量化と管理の困難性をPoW修正ルールで解決 Pradip Kumar Sharma and Jong Hyuk Park, “Blockchain based hybrid network architecture for the smart city” Future Generation Computer Systems 86 (2018) 650–655.

前頁のスマート交通手段 が更に階層化されることも レンタカーシナリオの例 （AI活用も視野） IoT、オンボード診断 （OBD）、その他のレ ンタカー関連データが 近くのモバイルエッジ ノードに送信され共有 ブロックチェーンは、 運転者と車のプロ ファイルを、メンテナ ンス、事故、移動、 その他の不変データ 履歴とともに保存 保険会社 ブロックチェー ンのためのエッ ジ間共有台帳 ネットワーク 共有ブロック チェーン元帳 エッジに移行さ れるデータ AIネットワーク に対するエッジ 分散ＡＩ ゲートウェイ メーカー/ ディーラー メインテナンス サービス提供者 ｸﾗｲｱﾝﾄ 執行 機関 分散ＡＩ ゲートウェイ AIネットワークでその 他の自動車関係者と も重要な情報を共有 ブロックチェーン AI相互作用 自動車保険に 関連する様々 なソースから のIoTデータ IoT、5G、フォ グネットワークを 備えたスマート シティ 47 Abdur Rahman et al., “Blockchain and IoT-Based Cognitive Edge Framework for Sharing Economy Services in a Smart City”, IEEE Vol.7, 18611-18621, 2019.

スマートシティへの取組み(まとめ続) システム構築力 1. ブロックチェーン導入によって、クラウド版IoTシス テムとどのように差別化するのかのポイントの明 確化が必要である。 2. 価値を実現する方式（コンセンサスルール、セ キュリティ方式など）とそれを評価する手段（性能 やコストなど）の明確化が必要である。 3. 各サービスを融合させた場合、スマートシステム として発生するトレードオフ条件の明確化と最適 点決定の判断基準が必要である。 例：①垂直（集中） vs 水平（分散）、②オープン化度合い、③権限維持重視 vs ネット ワーク（規模）拡大重視、④多くの標準に準拠 vs 自己開発（標準）も採用、など 4. オープン性と相互運用性への配慮が必要である。 48

スマートシティへの取組み(まとめ続) 設計力・構想力 1. 当該スマートシティ向けの新たなアーキテク チャ設計が必要である。 2. 個別技術の進化だけでなく、それらを吸収し トータルサービス価値を創造するフレームワー クが必要である。 3. 市民（ユーザー）との共創で登場するアプリ ケーション群の継続・維持などのプラットフォー ム設計力と価値醸成が必要である。 4. トレードオフ条件の最適化発見などのツール （シミュレータなど）が必要である。 例：①エッジコンピューティングの効果、②選択したコンセンサスルールのパフォーマンス、など 5. 将来環境でのビジネス構想力が必要である。

ブロックチェーン for IoT×ビジネス • ブロックチェーンが保有する夢のようなビ ジョンやアプリケーションを巧みに引き寄せ ながら、具体的実現のパスをデザインする 挑戦の場が登場している。 • これらへの挑戦の延長で、GAFAモデル （集中型）の次のビジネスモデル（分散 型）構築に繋がる新たな勃興が発生す るだろう。 50

• IoTへのブロックチェーン導入の神髄は、やはり、 IoT系においても、Public型で、金融由来の付加価 値付与ということになるのではないだろうか • この状況を実現するには、低廉価センサーなどを 含む全IoT機器で収集されたデータに金銭的価値 が付与され、マイクロペイメントが実現されるよう な世界の到来が必要になる。 • 但し、ブロックチェーンにはスケーラビリティの限 界がある為、多様な技術の進化とともに、適応が 相応しい最適適応領域の発見も重要になる。 • また、既存世界の全面入れ替えは難しく、既存世 界との共存の世界到来と想定される。そこで、両 者の役割分担のデザインも重要になる。 51