プラットフォームとしてのブロックチェーン

プラットフォームとしての ブロックチェーン -IoTへの導入を例にインフラ連携も考慮してｰ B-frontier研究所 代表 高橋 浩

目次 • • • • • • • • はじめに：検討の枠組み IoTへ導入の要件 ブロックチェーンプラットフォームとは インフラストラクチャの状況 IoTへのブロックチェーン適応 先行アプリケーションからの示唆 ブロックチェーン採用を妨げる課題への対応 今後の方向性 2

はじめに：検討の枠組み はじめに • ＩｏＴベースのサービスは指数関数的に成長 • 2020年までに世界経済に7.1兆ドルもの価値 創成との予想も • しかし、同時に、ＩｏＴデバイスは膨大な数のセ キュリティとプライバシー問題に対して脆弱 • このような状況にブロックチェーンは有力なメ カニズムを提供と期待されている。 • ブロックチェーン視点で、IoTにフォーカスした 包括的分析が必要である。 3

ブロックチェーンのメリット ブロックチェーンのタイプ IoT向けブロックチェーン 現 状 の 確 認 IoTブロックチェーンベースのアプリケーション IoT向け要件とIoTアプリケーション IoTへブロックチェーン本格採用時の課題 今後の方向性 今 後 に 向 け た 検 討 4

主として焦点を当てる項目 • IoTの置かれた脅威環境 – 現在、ＩｏＴデバイスは殆ど保護されていない環境 で動作している。 • IoTのセキュリティ要件とパフォーマンス要件 • ブロックチェーン技術の進歩がIoTに与える影 響 • 今後の取組みへの示唆 本PPT資料は主に下記論文を参考にして独自に作成 Imran Makhdoom, et al., “Blockchain’s adoption in IoT: The challenges, and a way forward”, Journal of Network and 5 Computer Applications 125, 251-279 (2019).

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

IoTでも有用なブロックチェーンの特性 ｽﾏｰﾄｺﾝﾄﾗｸﾄ導入以後 自律運用 信頼性 各IoTﾃﾞﾊﾞｲｽ毎に異なる フォールト トレランス データ 整合性 分散管理 分散蓄積 データ認証 監査能力 信頼フリー 操作 ログ管理 二重支出 なし 不変性 7

ブロックチェーンのタイプ パブリックブロックチェーンとプライベートブロックチェーン パブリック（許可なし）ブロックチェーン プライベート（許可）ブロックチェーン 許可なしで参加可能 許可された者が参加 ノードIDが知られていない（仮名ID使用） ノードIDが知られている 無制限のノード数 限られた数のノード数 データのプライバシー保護が少ない データセキュリティに利用可能なオプショ ンが存在 貧弱なコンセンサス最終性 即時のコンセンサス最終性（BFTベース ブロックチェーンの場合） 低いTXスループット 高いTXスループット 優れたスケーラビリティ（マイナーノード の数に関連して） 貧弱なスケーラビリティ（BFTベースブロッ クチェーンの場合） 51％攻撃に脆弱（PoW・PoSブロック チェーンの場合） ノード共謀（collusion）に脆弱（BFTベース ブロックチェーンの場合） 8

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

IoTアーキテクチャとセキュリティの課題（概念図） ゲートウェイ付き分散ネットワーク ゲートウェイ付き無線センサー ネットワーク 情報家電機器 • IoTではネットワークを介して相互接続する組み込みセンサー保有 異種デバイス包含環境でのセキュリティの順守などが必須条件 10

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

平均的なIoTシステムの状態 ① 各IoTプラットフォームは、おおむねデバイスと ユーザ間の接続と相互作用を可能にしてはい るが、・・ ② IoTプラットフォーム間の相互作用は限られて おり、高コストのまま ③ その結果、規模拡大の事例は少なく、顕著なビ ジネスモデル登場は顕在化していない。 現在のプラットフォーム ローカルベースプラットフォーム クラウドベースプラットフォーム 12 J Mineraud, O Mazhelis, X Su, S Tarkoma, “A gap analysis of Internet-of-Things platforms”, Computer Communications 89, 5-16, 2016

より進んだクラウド利用にも弱点がある クラウドとブロックチェーンの特徴比較 クラウド ブロックチェーン 集中アーキテクチャ 分散管理 信頼はクラウドプロバイダーに依拠 信頼はネットワークで分散対応 単一障害点（クラウドプロバイダー によるデータ操作の可能性） 全マイナーノードとフルノードにブロックチェーン 状態を複製所有する分散アーキテクチャ データ操作に対して脆弱 不変 未承認のデータ共有が発生し易い スマートコントラクトに基づくユーザー定義のア クセス制御依存 クラウドプロバイダーの管理下にあ るユーザーデータ スマートコントラクトを通じてユーザー/デバイス 間で自律的データ共有 ユーザーはクラウド内TXについて完 偽造不可のイベントとTXログ維持で完全な透明 全に明確ではない 性保有 IoTの高いデータ可用性と低遅延の 要件には理想的でない ブロックチェーンのフルコピー格納のマイナー ノードに関して、エッジストレージとコンピュー ティングを提供 高価なインフラ （クラウドに比し）より安価 13

今後、基本アークテクチャは分散化の方向へ 過去、現在から未来の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 14

ブロックチェーンプラットフォームとは ブロックチェーン導入時の IoTアーキテクチャは • IoT製品の標準化が欠如しているた め、世界はまだ単一のIoT参照モデ ルに同意できていない。 • 幾つかの提案論文はある（次頁）。 15

幾つかの試みは存在する 論文名 Al-Fuqaha et al., “Internet of things: a survey on enabling Ｒ１ technologies, protocols, and applications”, IEEE Commun. Surv. Tutor. 17 (4), 2015. Kumar et al., “Security in internet of things: challenges,solutions Ｒ2 and future directions”,IEEE 49th HICSS, 2016. Khari et al., “Internet of Things: proposed Ｒ3 security aspects for digitizing the world”, 3rd INDIACom, 2016. Khan et al., “Future Internet: the internet of things architecture, Ｒ4 possible applications and key challenges”, IEEE 10th FIT, 2012. Qiu et al., “How can heterogeneous Internet of things build our Ｒ5 future: a survey”, IEEE Commun. Surv.Tutorials 20 (3), 2018. 16

IoTへブロックチェーン適応時の層構造 仕事/機能/目的 活動とサービスの管理 アプリケーション層から受け取ったデータに基づいて、ビ ジネスモデル、グラフ、フローチャートなどの作成 ビッグデータ分析に基づく意思決定プロセスの支援 将来の行動や戦略の決定に有用な活動 サービス提供 ビジネス層へのインタフェース提供 データアクセス制御 ミドルウェア内のオブジェクトの情報処理に基づくアプリ ケーションのグローバル管理 住所と名前に基づく要求者とのサービスのペアリング 受信データの処理と決定、ネットワークワイヤプロトコル を介した必要なサービスの提供 サービス管理 他層からデータ受信して処理と計算と意思決定能力 生成されたデータのサービス管理層への転送 機器間および機器から受信機へのデータ送信 センサーから情報処理システムへのデータ転送 転送元ノードから転送先ノード/クラウドサーバーへの データ転送 センサーデータの収集 データをデジタル化してオブジェクト抽象化層に転送 ビジネス層 ビジネス層 アプリケー ション層 アプリケー アプリケー アプリケー アプリケー ション層 ション層 ション層 ション層 ｻｰﾋﾞｽ管理 /ﾐﾄﾞﾙｳｪｱ層 ﾐﾄﾞﾙｳｪｱ層 クラウド層 ｵﾌﾞｼﾞｪｸﾄ ﾈｯﾄﾜｰｸ層 ﾈｯﾄﾜｰｸ/ﾄﾗ ﾈｯﾄﾜｰｸ層 ﾈｯﾄﾜｰｸ層 抽象化層 ﾝｽﾐｯｼｮﾝ層 ｵﾌﾞｼﾞｪｸﾄ/ 知覚層 物理的コンポーネント、スマート家電、電力供給業者 などの基本的ハードウェア構成など 知覚層 ｾﾝｻｰ層 知覚層/ ﾃﾞﾊﾞｲｽ層 ｾﾝｼﾝｸﾞ層 物理層 Ｒ１ Al-Fuqaha et al., 2015 Ｒ2 Ｒ3 Ｒ4 Ｒ5 Kumar et al., 2016 Khari et al., 2016 Khan et al., 2012 Qiu et al., 2018

代表的ブロックチェーンプラットフォームの比較 Features Bitcoin Ethereum IoTに親和性のある方式 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より短い スケーラブルであるか？ × × × 18

現状で最も相応しそうなプラットフォームは • Hyperledger-FabricがIoT要件の多 くを満たしているようには思われる。 – データの機密性（ Ethereumは無し） – ID管理（ Ethereumは無し） – 鍵管理（ Ethereumは無し） – ユーザー認証 – TXスループット（ Ethereumよりも高い） – TX確認の待ち時間（ Ethereumよりも短い） しかし、パフォーマンス要件などは依然として低水準 19

ミドルウェアの特性 • 殆どのミドルウェアサービスは相互運用性に 負の影響を与える独自プロトコールを使用し ている模様 • 背景には下記などが考えられる。 • IoTは従来のITネットワークと異なり、エンドデ バイスで利用可能なリソースレベルが極端に 低いデバイスが混在する。 • その結果、従来のITシステム（Ex.スマホ）のよ うに、リソースを気にせずに多様なセキュリ ティプロトコールで保護することなどが出来な い状況にある。 20

インフラストラクチャの状況 既存のデジタルインフラストラクチャの例 • • • • • • インターネット データセンター IEEE 802.11 USB、など スマートフォン タブレットなど オープンスタンダードのもの 民生用デバイスなど 特に、スマホなどは、クリティカルマスに規模拡大 し、インフラストラクチャとして機能する強力な計算と ネットワーキングデバイスになった。 21

ブロックチェーンインフラストラクチャの状況 • IEEE 802.15.4, 802.11a/b/g/n,p • LoRa, ZigBee, NBIoT, SugFoxなど • オープンスタンダードあるいは デファクトスタンダードなもの 低帯域幅・低電力の無線通信機器を介して インターネットやゲートウェイ機器に接続 • 各種市販IoT機器 • 各種ｾﾝｻｰ内蔵機 器 民生用IoT機器およびｾﾝ ｻｰ内蔵デバイスなど IoTデバイスは千差万別で、リソースにも制約があるた め、クリティカルマスのインフラが発生する状況に 22 はほど遠い。

IoT向けブロックチェーンプラットフォームとブロック チェーンインフラストラクチャ同時考慮の視点から • 民生用IoT機器などは、アプリケーション固有 の機能やその基盤としてのOSが欠如してい る。 • その結果、データ内容やそれを伝送する際 のフォーマットが多様化している。 • 従って、あらゆるタイプのIoTデバイスとシス テムに適合する標準セキュリティプロトコー ルの開発などは極めて困難か不可能に近い と考えられる。 23

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

現在の技術水準の例（１） ADEPTは、役割と計算能力が異なる3種類のIoTデバイス（ライト・ピア、 スタンダード・ピア、ピア・エクスチェンジ）を区別して提供している。 ADEPTは、安全で、スケーラブルで、自律的なピアツーピアIoTのために考案 IBM, 2015. Adept: an Internet of Things Practitioner Perspective. Tech. rep. 25

現在の技術水準の例（２） ｽﾏｰﾄﾎｰﾑ向けに提案された軽量ブロックチェーンベースアーキテクチャ Ali Dorri et al., “Blockchain for IoT Security and Privacy: The Case Study of a Smart Home”, Proceedings of the IEEE 2nd Workshop on Security, Privacy, and Trust26 in the Internet of Things (PERCOM) Hawaii, 2017.

現在の技術水準の例（２続） 軽量ブロックチェーンベースのIoTアーキテクチャ • ブロックチェーンのセキュリティとプライバシーを 維持しながらIoTの要件に適合したものにするた めに、階層構造と分散型の信頼を提供している。 • 全体を、スマートホーム、クラウドストレージ、オー バーレイの3つのコア層で構成する。 • IoTデバイスはスマートホーム層内に配置され、 SHM（スマートホームマネジャー）によって集中 管理される。 • スマートホームは、サービスプロバイダ、クラウ ドストレージ、およびユーザーのスマートフォン/ パーソナルコンピュータとともに、オーバーレイ ネットワークを構成する。 27

現在の技術水準の例（３） IoT eビジネスモデル：４つの要素から成る D C B 操作モード A 構成要素 Yu Zhang et al., “The IoT electric business model: Using blockchain technology for the internet of things”, Peer-to-Peer Networking and Applications, 2016. 28

現在の技術水準の例（３続） ４つの要素の概要 A)エンティティ：DAC＊と人間から成る。それ等 は条件に従って自動的にIoT製品を検索し購 入する。＊：DAC:decentralized autonomous corporations（分散自律型企業） B)コモディティ：従来のコモディティだけでなく、 センサーデータやスマートプロパティも含む。 C)オペレーションモード： IoT e-ビジネスプロセス のガイドライン。トランザクション開始から契 約終了までの全段階を設計する。 D)トランザクションモード： IoT e-ビジネスシステ ムの中核。第三者の助けを借りずにP2P取 引を完了させる。 29

IoTへのブロックチェーン適応（部分的まとめ） • 環境に応じて選択できる複数手段の提供が必 要な状況にある。 • リソース制約の程度吸収を織り込んだ適応分野 対応の階層モデル構築が必要である。 • スマートコントラクトの適用範囲や適応法、適応 分野対応への個別対応も必要である。 • 各種状況に対応する具体的メニューが出てきて いるが、決定的な汎用手段が登場している訳で はない。 ⇒寧ろ、細分化が一段と進行している。 30

先行アプリケーションからの示唆 先行アプリケーションからの示唆 アプリケーションの比較ポイント ① なぜブロックチェーンが使われるのか？ ② どのブロックチェーンプラットフォームが使 われているか？ ③ 従来のどのような問題が解決されたか？ ④ ブロックチェーンのどのような問題が解決 されたか？ 31

代表的アプリケーションと ①:ブロックチェーンが使われる目的 アプリケーション 使用目的 関連ページ ADEPT (2015) スマート契約とネットワーク合意の活用のため p.25 スマートシティ (2016) 信頼性の向上とフォールトトレランス向上のため p.36 ファームウェア 更新(2016) ファームウェア検証中のデータの完全性、データ認証、 否認防止を確実にするため スマートホーム (2016) 分散信頼と、IoTデバイスとそのデータへのアクセス 制御共通プラットフォーム化を図るため VANETS(2016) 分散型自己管理システム構築のため eBusiness (2016) スマート契約に基づく透明な自己管理と自己調整シ ステム実現のため SCM(2016) 偽造できないことでオブジェクト追跡や所有権記録を 行うため Slock.it(2015) 分散型管理とスマート契約実行能力の実現のため Enigma(2015) 分散型管理のため p.26,p.27 p.28,p.29 p.34,p.35 32

①、②、③、④の全体像 ADEPT ｽﾏｰﾄｼ ﾃｨ ﾌｧｰﾑｳｪ ｱ更新 ｽﾏｰﾄﾎｰ ﾑ VANETS eBusines s SCM Slock.it Enigma スマート契 約とネット ワーク合意 の活用のた め 信頼性の向 上とフォール トトレランス 向上のため ファームウェ ア検証中 データの完 全性、デー タ認証、否 認防止確実 実施のため 分散信頼と、 IoTデバイ スとデータへ のアクセス 制御共通プ ラットフォー ム化のため 分散型自己 管理システ ム構築のた め スマート契 約に基づく 透明な自己 管理と自己 調整システ ムの実現の ため 偽造できな いことでオブ ジェクト追跡、 所有権記録 実施のため 分散型管理 とスマート契 約実行能力 実現のため 分散型管理 のため Ethere um 明確にさ れていな い（独 自？） PoWコン センサス 保有独自 PoWコン センサス 未使用独 自 Ethere um Ethere um IBMﾌﾞﾛｯｸ ﾁｪｰﾝﾌﾟﾗｯ ﾄﾌｫｰﾑ (Hyperled ger-Fabric) Ethere um 独自 ③解決さ れた問題 一元化機関 /エンティティ、 単一障害点、 ユーザー/ データのプラ イバシー、相 互作用で引 き起こされる エラーへの 信頼回復 異種デバイ スから受信 したデータを 共有するの が困難だっ た状況を解 決 サイバー攻 撃の影響を 軽減し、ネッ トワークの 輻輳問題を 回避 IoTデータ へのアクセス 制御、デー タの機密性、 整合性、可 用性を DDoS攻撃 に対して保 護と共に保 証 集中管理と プライバシー の問題の解 決 集中管理と 透過的デー タ共有/サー ビスにおける 問題の解決 集中型デー タベースの 脆弱性の解 決 製品のアク セス制御と 手動による 受け渡しの ための集中 管理と人的 介入問題の 解決 共有と分散 計算中の データプライ バシーの解 決 特に無し スケーラビリ ティ問題の 解決（ブ ロックチェー ンサイズに関 連） マイニングに おけるPoW 使用回避に よる計算集 約度、TX確 認における 待ち時間、 エネルギー 消費の解決 特に無し 特に無し 特に無し ④解決さ れたブ ロック チェーン の問題 ユーザー/ データのプラ イバシー、 ID管理、 データに対 するユーザー アクセス制 御、スケーラ ビリティ ブロック内で マイニングさ れるTX数の 減少による スケーラビリ ティ問題の 解決 実際のデー タをオフ チェーン DHTに保存 することによ るスケーラビ リティ問題の 解決 ①ブロッ クチェー ンが使わ れる理由 ②ブロッ クチェー ンプラット フォーム 33

Slock.it • 適当なトークンを運ぶデバイスによって ロックを解除できるスマート電子ロック • トークンはEtherと呼ばれる暗号通貨を 使用 • Etherはスマートコントラクトに最適化さ れたEthereum上で購入可能 • 家や車を借りたいSlock所有者は、電子 ドアロックへ時間限定アクセスの値を設 定 • 利害関係者は、Slockを識別し、Etherで 要求された金額を支払い、適切に署名 されたメッセージを介してロックを解除 34

Slock.it（続） スマートコントラクトを利用したIoTデバイスサービスの管理 ・借りる ・入金 ・開く/再開＆閉じる ﾌﾞﾛｯｸﾁｪｰﾝ ｻｰﾊﾞｰ ・Slock / Itemの登録 ・入金と料金の設定 ・開閉（制限あり） ｽﾏｰﾄ ｺﾝﾄﾗｸﾄ 組み込み機器（ブロックチェーンクライアントソフトウェア） Rasberry Pi Intel Edison Samsung Artik S ・Bluetooth ・Z-Wave ・Zigbee ・電源ソケット ・ドア ・洗濯機 ・その他のスマート家電 35

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

先行アプリケーションからの示唆（部分的まとめ） • 全てのアプリケーションがEthereum、 Hyperledgerなどのオープンソースブロック チェインを使用している訳ではない。 • 9種中3種のアプリケーションは個別ニーズに 合わせて設計された独自ブロックチェーンを 使用している。 • 先進的アプリケーションとブロックチェーン技 術進歩の同時並行的開発や取組みが必要な 状況にある。 37

ブロックチェーン採用を妨げる課題への対応 ブロックチェーン本格採用に必要な要件 IoTセキュリティ要件 IoTパフォーマンス要件 IoT指向コンセンサスルール p.39 • 多様な条件有り • 相対的にはHyperledger -Fabricがより多く条件充足 • しかし、全体としては残存課 題有り • 本質的対応は未 p.40 • 現状ではPBFTが望まし いが、完全対応では無い p.41 要件アプリケーション充足状況 • 本質的対応は未 p.42 38

ブロックチェーン視点での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 39

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

現状のコンセンサスルールの中でのお薦め候補 PoW 適応分野 金融 PoS 各種 PoET 各種 PBFT DBFT IOTA 各種 各種 金融(現在) ｴﾈﾙｷﾞｰｺｽﾄ 高い （PoWに比 （PoWに比 して）低い して）低い 低い 低い 良好 計算ｺｽﾄ （PoWに比 （PoWに比 して）低い して）低い 高い（ｺ ﾐｭﾆｹｰ ｼｮﾝ複 雑） 低い 低い 即時 即時 確率的 短い 短い 短い 許可有り 無し両方 許可有 り 許可有 許可無し(現 り 在) 必要 （Ex.Intel SGX) 不要 不要 高い 合意終了性 確率的 確率的 TX検証時の 長い 遅延 ﾌﾞﾛｯｸﾁｪｰﾝ のﾀｲﾌﾟ 確率的 （PoWに比 （PoWに比 し）短い し）短い 許可無 許可有り し 無し両方 特殊ﾊｰﾄﾞが 必須で 不要 必要 はない HyperledgerFabric 不要 41

要件に対する各アプリケーション充足状況(Gap分析） ｱﾌﾟﾘｹｰｼｮﾝ ADEPT 要件 ｽﾏｰﾄｼ ﾌｧｰﾑｳｪ ﾃｨ ｱ更新 ｽﾏｰﾄ ﾎｰﾑ VANET S eBusi ness SCM Slock.i t Enigm a × IoT中心合意 ﾌﾟﾛﾄｺｰﾙ × × × × × × × × IoT重視のTX 検証ﾙｰﾙ × × × × × × × × ｽｹｰﾗﾋﾞﾘﾃｨ 安全なﾃﾞﾊﾞｲ ｽ統合 ＊1：ブロックチェーンにファームウェアファイルを保存しないことによって 〇 × 〇＊1 〇＊2 × × × 〇＊3 × ＊3：１ブロック内で マイニングされるTX数 を制限することによって ＊2：クラウドストレージにデバイスのデータを保存することによって × × × × × 〇＊4 ﾃﾞﾊﾞｲｽ侵害 に対する保 護 ＊4：デバイスから外部へのデータの流れを制限することによって 安全なﾌｧｰﾑ ｳｪｱ更新 〇 ﾃﾞｰﾀｾｷｭﾘﾃｨ 〇 〇 〇 〇 〇 ﾌﾟﾗｲﾊﾞｼｰ保 護計算 〇：要件充足。充足している例は少ない。 42

ブロックチェーン採用を妨げる課題への対応 （部分的まとめ） • IoTへのブロックチェーン導入の要件はシビア で対応未の項目が残存している。 • 先行アプリケーションの要件充足も低水準に ある。 • 特に、IoT重視のコンセンサスルール、TX検証 ルール、IoTデバイスとの安全な統合など、本 格採用に重要な機能は未対応のままである。 • 全体としてはブロックチェーン本格採用はま だ時期尚早のようにも思われる。 43

今後の方向性 基本認識 • “IoTは自律的デジタル化経済の未来”と想定 されているが、 • このような段階に到達するには、設計段階と 開発段階の双方で概念的変革の受け入れが 必要なように思われる。 • 自律的デジタル世界の将来の要件を満たす 安全なブロックチェーンベースのIoTシステム 設計＆開発が不可欠である。 • また、将来のIoTシステムは既存のIoTテクノロ ジーとの互換性も考慮されるべきである。 44

IoT環境にフィットするコンセンサス プロトコールはまだ無い 暗号通貨向け要件とは明確に異なる。 • セキュリティ系の要件例： • パフォーマンス系の要件 • IoT重視のTX検証ルール • シビル攻撃に対する回復 力 • 合意の最終性 • フォークを避ける • 最大障害ノード数を許容 • デバイスの整合性チェック • DoS攻撃を回避する 例： • • • • 低レイテンシ 低計算コスト 低エネルギーコスト 通信の複雑さが少ない 45

IoT系のTXは独特であり、従来型とは 明確に区別する必要がある 仮想的に例示（スマートホームの例） • 部屋に暖炉があったとする。 • カメラまたは任意のセンサーも、その部屋に 人間の存在を検知した場合に限り点火すべき である。 • センサーの読み取り値が環境に依存して検証 され、単独では検証されないことを意味する。 （これに類する多様な場面が想定される） 46

ブロックチェーンとIoTデバイスとの統合 • 感知装置のような市販のIoT機器は費用対効 果のため安全な実行環境を持っていない。 • 従って、デバイスの正当性保証のため、頻繁 にチェックルーチンの実行が必要になる。 • 当然、リソース制約されたIoTデバイスはマイ ナーノードやフルノードとしての使用は不可 • 結果的に現行はクラウドに依存している。 • 既存IoTシステムから将来のIoTシステムへス ムーズな移行を確実にする準備が必要にな る。 47

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

暫定まとめ • IoT指向の理想的コンセンサスルール創造も 重要だが、 • そのような候補が登場したとしても、あらゆる IoTデバイスへの普及・浸透には新たな困難 が予想される。 • なかなか共通の将来ビジョンは描けない。 – Apple iPhoneのような寡占モデルは考え難い。 • 多分、現在のシステムよりもより複雑なエコシ ステムの登場か？ • エコシステムのパートナー間の新たな摺り合 わせや、各種インターフェースのUX/実現手 段などにも新たなチャンス到来か？ 49

ぶっちゃけ荒っぽく将来を推測すると – 「英アーム、IoTで想定外の苦戦」、「英アーム、 IoT端末向け自社 プラットフォームに幅広いソフトウエアメーカーを引きつけられず 苦慮」などの記事も登場 • IoTにブロックチェーン導入の試みでは、一般論としての解は見つかっ ていないが（Everledger社によるダイヤモンド認証など）成功例も登場 • IoT市場の断片化は酷く、Apple流のプラットフォーム化は根本的に難 しいが、「中長期的にIoTの未来に疑いを抱く」状況でないのは世界的 合意 ビジネスアプローチに変質が迫られているのでは？（仮説） – 【参考】新薬の開発が難しくなったと言われる。従来とは圧倒的に 異なるレベルの化合物組合せ爆発を乗りきる手法や方策が求め られる（例えば新薬ベンチャーの買収、市場獲得のためのM&A、 組合せ爆発をコントロールするために量子コンピュータ活用など）。 IoTはビジネスモデル発見の組合せ爆発に見舞われていると捉えれば、 従来とは異なる取組みの必要性が迫っているということか？ 50