Slide 1

Slide 1 text

エンジニアのためのエンタープライズブロックチェーン超⼊⾨ ブロックチェーンの技術要素と特⻑ #blockchaingig 萩野たいじ (Taiji Hagino) Sr. Developer Advocate Developer Advocacy Tokyo City Team, IBM @taiponrock

Slide 2

Slide 2 text

@taiponrock フォローはお気軽に︕ 共著: はじめてのNode-RED, DevRel Q&A 連載: ⽉間 I/O (Node-RED 実践プログラミング) 萩野 たいじ(Taiji Hagino) IBM シニアデベロッパーアドボケイト 筑波⼤学 ⾮常勤講師 Specialist in Node-RED/Node.js, Swift, Hyperledger Fabric

Slide 3

Slide 3 text

City Leader AKIRA ONISHI City Team TAIJI HAGINO KYOKO NISHITO AYA TOKURA NORIKO KATO Program Manager TOSHIO YAMASHITA Client Team YASUSHI OSONOI JUNKI SAGAWA DEVELOPER ADVOCATE in TOKYO Tokyo Team is a part of Worldwide Developer Advocate Teams!

Slide 4

Slide 4 text

ブロックチェーンの基礎技術について

Slide 5

Slide 5 text

コアとなる考え⽅が2つあります

Slide 6

Slide 6 text

ブロック 各ブロックのヘッダーには親ブロックのブロックハッシュが含まれてて、ハッシュ値が編みこまれていく 途中で改ざんすると、当該ハッシュ値が正当な値ではないことが、即座に確認可能 b(0) b(1) b(2) b(3) b(4) 0~1の間に発⽣した トランザクション 0番⽬のブロック 1番⽬のブロック 2番⽬のブロック 3番⽬のブロック ハッシュ値 ハッシュ値 ハッシュ値 未承認 トランザクション 1~2の間に発⽣した トランザクション 2~3の間に発⽣した トランザクション ハッシュ値 ハッシュ値 ハッシュ値 トランザクション = 取引

Slide 7

Slide 7 text

ハッシュ関数 同じ値が出⼒(ハッシュ値)︓同じ値の場合は、同じ値が出⼒される。1⽂字でも異なれば、原則全く無関 係の値が出⼒される。⼊⼒データを改ざんするとハッシュ値が変わるため、全く無関係の値が出⼒される ことになり、改ざんの防⽌ができる ⼀⽅向性︓ハッシュ値から、元の⼊⼒データを推測することは困難 固定出⼒値︓⼊⼒値の⻑さに関わらず、固定⻑の出⼒値が出⼒ AからBに $100送るよー AからCに $100送るよー ハッシュ関数 (SHA-256) 25F62A5A3D414EC6E209 07DF7F367F2B72625AAD E552DB64C07933F6044F C49A 7A55DDE3EEBE5AC95E8 E41A0FD1085B9241A1D9 D7FBC6F72A63BB802F64 09FD ⼊⼒データ(メッセージ) 固定⻑のハッシュ値 SHA-256は「Secure Hash Algorithm 256-bit」の略、256ビット(32バイト)⻑のハッシュ値、16進数で64桁

Slide 8

Slide 8 text

各種ブロックチェーンの技術について

Slide 9

Slide 9 text

仮想通貨型 ブロックチェーン 汎⽤型 ブロックチェーン

Slide 10

Slide 10 text

仮想通貨型 ブロックチェーン 汎⽤型 ブロックチェーン

Slide 11

Slide 11 text

Bitcoinを例に説明しますね

Slide 12

Slide 12 text

Bitcoinという仮想通貨をみんなが持ってるよ

Slide 13

Slide 13 text

AさんはBさんへ100BTC⼊⾦したよ トランザクションを発⾏したよ

Slide 14

Slide 14 text

A→B 100BTC A→B 100BTC A→B 100BTC A→B 100BTC A→B 100BTC A→B 100BTC A→B 100BTC A→B 100BTC トランザクションの結果をみんなで共有 ※実際は平⽂ではないです トランザクションの結果をみんなの台帳に書き込んだよ

Slide 15

Slide 15 text

トランザクション発⾏ 送⾦処理したぜー 問題ないかチェックよろ︕ 誰がブロック作るか決めようぜ︕ じゃあ、計算競争で勝ったヤツな︕ 検証計算 (※マイニングといいます) 俺たちマイナー 俺勝者︕報酬もらうぜ♪ 取引記録を検証し、計算の解(プルー フ・オブ・ワーク)と⼀緒にブロックを 作成、Bitcoin利⽤者全員に送信 マイニングの敗者がそれぞれブロックの 内容を確認 検証して問題なければブロック⽣成するぜー 作ったブロックはみんなで検証な︕ こんな3段階でブロックが作られるよ 1. 2. 3. ブロック⽣成

Slide 16

Slide 16 text

この辺注意 • 計算競争は、暗号学的ハッシュ関数を利⽤したもの • 計算競争の計算は「nonce/ナンス」を求めること • 計算競争の勝利者が取引記録を検証するのは、直前の約10分間の取引 • ブロックチェーン は、取引記録を書き込む台帳としての役割を果たすとともに、タイムスタンプとしても機能する • もし過去に遡って取引を改変しようとすると、各ブロックに含まれたプルーフオブワークをもう⼀度計算し直すことになる • それは膨⼤な⼿間が必要となり、事実上不可能 • その仕組みが仮想通貨の実⽤化に必要な要素である取引の⾮可塑性や⼆重使⽤の防⽌を⽀えている • 計算競争のインセンティブは、Bitcoinの報酬 (2019年Posで1ブロックごとに12.5BTC) • 報酬分のBTCは新規発⾏され、直近約10分間に⾏われた取引の⼿数料とともに、計算競争の勝利者のものとなる • これがあたかも⾦の採掘のようであることから、計算競争は「採掘(マイニング)」と呼ばれている • Bitcoinのソフトウェアは、おおよそ10分間で正解が出せるような難易度に調整されている • 採掘には誰でも参加できるが、勝利するためには、約10分の間に他者よりも多くのサイコロをふる⼒が必要 • つまりより多くの計算能⼒を持つほうが有利

Slide 17

Slide 17 text

ブロック⽣成と書き込み b(0) b(1) b(2) 0~1の間に発⽣した トランザクション 10分 ブロック(0) 10分 ブロック(1) 10分 ブロック(2) 10分のブロック(3) ハッシュ値 ハッシュ値 1~2の間に発⽣した トランザクション ハッシュ値 ハッシュ値 ハッシュ値 取引記録 ⼊⾦ 出⾦ 直前のブロックのハッシュ値 (ダイジェスト) ナンス 取引記録 ⼊⾦ 出⾦ ︓ ビットコインの参加者に課される「計算競争」 トランザクション・プールに⼊っている取引データ、前のブロックのハッシュ値、タイムスタンプを 「ブロック」に詰め、「ナンス」と呼ばれる適当な数を⼊れながら、そのブロックの先頭に所定の数だ け「0」が並ぶ条件を満たす「ナンス」(nonce)を発⾒する 出典: 国⽴情報学研究所ニュース [NII Today] 第69号 平成27年9⽉ 「仮想通貨の技術と課題」

Slide 18

Slide 18 text

インセンティブとマイニング ナンス値は⾃分が⾃由に変える事ができる、使い捨てのランダ ムな32ビットの値 マイニングとはナンス値を何千、何億と組み換え、1番最初に 「0」が16個並ぶのを競う作業 俺たちマイナー 新しいブロックを⽣成(未確認の取引を承認)するために以下が必要︕ ① 直前のブロックのハッシュ値 ② 新たに⽣成されるブロックに含まれる全取引データ ③ 任意の数値︓ナンス値 ④ ①〜③のハッシュ値 ④のハッシュ値の先頭に「0」が16個並ぶ数値がでたら 承認する(ブロックを⽣成する)よー︕ よし、頭に「0」が16個並ぶようになるまで任意の数値 ナンス値を計算して当ててやるぜ︕ ビットコインさん 計算競争の勝利者は⼀定額の BTCと⼿数料をGet︕ これがまるで⾦の採掘のようで あることから、計算競争は「採 掘(マイニング)」と呼ばれて いる 俺勝者︕報酬もらうぜ ♪

Slide 19

Slide 19 text

コンセンサス Proof-of-Work Proof-of-Stake Proof-of-Importance 特徴 仕事量による合意形成 所有量による合意形成 重要度による合意形成 メリット 取引の改ざんに強い PoWのデメリットを解消でき る 流動性を担保(極端に貧富 の差が⽣まれない) デメリット - 電気代が⾼くつく - 51%を占有されると改ざん され得る 流動性を損なう 貧富の差が⽣まれる 極端には⽣まれないかもし れないが、貧富の格は存在 する 利⽤例 Bitcoin, Monero, Zcash ADA, NEXT, Ethereum nem コンセンサス = 取引が正しいことを合意する⽅法 Bitcoinにおいては、勝利者がまとめたブロックに対して、計算の解(Proof-of-Work)を出し、マイニングに参加し た利⽤者それぞれが内容を検証し、「問題ない」と判断すること 「問題ない」と判断されたブロックは既存のブロックと接続されて保存される コンセンサス・アルゴリズムの代表的な種類

Slide 20

Slide 20 text

その他知っておきたい⽤語 ファイナリティ︓ 計算競争のまぐれ当たりなどの不正なブロックチェーンを延ばし続けるのは極めて困難であり、正当な処理が6回続け ばトランザクションは完全に覆ることのない取り引きだと認められる考え⽅のこと フォーク︓ 同時に複数のブロックが採掘されたり悪意のあるノードがネットワークを混乱させようとしたりして、複数のブロッ クが同じブロックのあとに加えられるときに発⽣する現象 ビザンチン将軍問題︓ 善意の計算者(誠実な将軍)達の合意形成を、悪意のある計算者(裏切り者の将軍)達が乱そうとした場合に、どの ように誠実な将軍達の合意形成を守るかという問題 裏切り者の将軍がN⼈の時、誠実な将軍が2N+1⼈以上であれば、誠実な将軍同⼠の判断が⼀致可能なことが証明され ており、ブロックチェーンにおけるコンセンサス・アルゴリズムに利⽤されている

Slide 21

Slide 21 text

仮想通貨型 ブロックチェーン 汎⽤型 ブロックチェーン

Slide 22

Slide 22 text

22 © 2018 IBM Corporation 汎⽤型ブロックチェーンの4つの技術要素 スマート・ コントラクト 処理の⾃動化 セキュリティ 改ざん防⽌ プライバシー 分散台帳 同じ取引記録 を共有 コンセンサス 参加者の合意 形成による 信頼性を担保 電⼦署名や認証機能により 参加者間の匿名性を確保し たり取引内容のプライバ シーを保護する仕組み ビジネス・ロジックによる 処理の⾃動化や、柔軟な 台帳の活⽤を実現する為の 仕組み 分散ノード間で取引の完全 性をシステム的に検証し、 保障する仕組み ビジネス・ネットワーク上 の参加者間で共有される 取引データ台帳 汎⽤型ブロックチェーンは「分散台帳」「スマート・コントラクト」「コンセンサス」 「セキュリティ」の4つの技術要素で構成されてるんだぜ︕

Slide 23

Slide 23 text

23 ブロックチェーン技術の位置付け コンソーシアム /標準化団体 パブリック コンソーシアム /プライベート 暗号通貨 仮想通貨 仮想通貨 (ビジネス・ユースケース) 汎⽤的な利⽤ ビジネス向けブロックチェーン

Slide 24

Slide 24 text

24 暗号通貨 ⾮暗号通貨 パブリック型 コンソーシアム型/ プライベート型 • 誰でも参加可能 (パブリック) ü 悪意のある参加者 • 仮想通貨ベース ü 取引⼿数料の考慮 • マイニングによる合意形成 ü 処理能⼒の制約 • スマート・コントラクト (Ethereum) 許可制ブロックチェーン パブリック/仮想通貨ベース • 特定された複数の会社や組織をまたが る業務に適⽤ • スマート・コントラクト (共有されたビジネス・プロセスを 合意に基づき実⾏) • セキュリティとプライバシー • ⾼い処理性能 ü スループットとレスポンス 共有された ビジネス・ プロセス ⾼信頼の 分散台帳 Hyperledgerはビジネス向けの許可制ブロックチェーン

Slide 25

Slide 25 text

25 Hyperledger Fabric Project • Hyperledger Fabric とはブロックチェーン・フレームワークの実装であり、The Linux Foundation が主催するHyperledger project の ⼀つ • Foundation ではモジュラー型のアーキテクチャーでの業務やソリューションの開発を⽬指している – コンセンサス、メンバーシップ・ サービスなどをプラグアンドプレイでことを想定 • Hyperledger Fabricではコンテナ技術を活⽤し、”チェーンコード”と呼ばれるスマートコントラクト(アプリケーションロジック)を稼 働させる。Hyperledger Fabric は最初、Digital Asset及びIBM から最初のハッカソンの結果として提供された

Slide 26

Slide 26 text

26 主要ブロックチェーン技術の⽐較 Bitcoinくん Ethereumくん Fabricくん • 暗号通貨・仮想通貨向けだよー • Bitcoin開発者が管理してるよー • マイニングでコンセンサス取るよー • 誰でも参加できるよー • データのスナップショット持ってないよー • スマートコントラクトは書けないよー • 汎⽤(エンタープライズ向け)だよー • Linux Foundationが管理してるよー • Raftとかでコンセンサス取るよー • 証明書持ってないと参加できないよー • データのスナップショット持ってるよー • スマートコントラクトJSとかで書けるよー • 汎⽤だけど仮想通貨もあるよー • Ethereum開発者が管理してるよー • マイニングでコンセンサス取るよー • 参加者はオープンにもできるし限定もできるよー • データのスナップショット持ってるよー • スマートコントラクト書けるけどSolidityだよー

Slide 27

Slide 27 text

Hyperledger Fabricを例に説明しますね

Slide 28

Slide 28 text

ある組織内で⾞の所有者を管理するよ

Slide 29

Slide 29 text

社⽤⾞のXXXは AさんからBさんへ所有者が変わったよ トランザクションを発⾏したよ

Slide 30

Slide 30 text

A→B メーカー︓〇〇 ⾞種︓XXX トランザクションの結果をみんなで共有 ※実際は平⽂ではないです トランザクションの結果をみんなの台帳に書き込んだよ A→B メーカー︓〇〇 ⾞種︓XXX A→B メーカー︓〇〇 ⾞種︓XXX A→B メーカー︓〇〇 ⾞種︓XXX A→B メーカー︓〇〇 ⾞種︓XXX A→B メーカー︓〇〇 ⾞種︓XXX A→B メーカー︓〇〇 ⾞種︓XXX A→B メーカー︓〇〇 ⾞種︓XXX

Slide 31

Slide 31 text

トランザクション依頼 所有権移転したぜー 問題ないかチェックよろ︕ スマート・コントラクト実⾏︕ 確認終えたら署名してな︕ 検証 (スマート・コントラクト実⾏) 俺たちPeerの中でも 選ばれし者 エンドーサー 俺Orderer (順序付けする⼈) トランザクションのコミット順を決定 実⾏するためのバッチを送信 参加者達がトランザクションを コミットして各⾃のブロックを⽣成 トランザクション実⾏するよ︕ こんな5段階でブロックが作られるよ 1. 2. 4. 俺クライアント 署名の数が条件満たしたら トランザクションをサブミット︕ 3. 確認したよー 確認してねー 俺たちPeer ブロック作るよー 5.

Slide 32

Slide 32 text

33 Hyperledger Fabricのコンポーネント ORDERER MSP (CA局) PEER Hyperledger Fabricはこいつら(コンポーネント)でブロックチェーンネットワークを 形成するんだぜ 台帳を持ち、スマートコントラクトを実⾏するノード トランザクションの順番を整理し、 ブロックを作成するノード 証明書を発⾏し、参加者の⾝元を管理するサービス 標準の認証局はFabric CAノード クライアント Hyperledger Fabricにトランザクションを発⾏する アプリケーション 組織(Org) 複数のPeerをまとめたグループ ※MSP = Membership Service Provider ※CA = Certification Authority Hyperledger Fabricネットワークのコンポーネント ユーザーの 登録/認証 ③Tx結果を送信 MSP (CA局) PEER ORDERER クライアント ①Tx承認要求/ 実⾏ ②Tx承認/ 結果送信 ④ブロックを配布 組織(Org) MSP (CA局) 各コンポーネントの関係性

Slide 33

Slide 33 text

34 分散台帳 ビジネス・ネットワーク上の参加者間で共有される取引データ台帳

Slide 34

Slide 34 text

35 台帳は、主に以下の2種類の構成要素から成り⽴ってるよ︕ 台帳の構成要素 説明 ブロック • ブロックをハッシュ値でつないだ、過去の記録の改ざんができない構 造を持つデータ。 • トランザクション(スマート・コントラクトの処理呼び出し)がログ のように記録される ワールドステート • トランザクションを実⾏した結果得られる、「最新の状態」を記録。 • すべての検証ノードで同⼀の内容をもち、整合性をとるためにハッ シュ値がブロックチェーンに記録される 分散台帳

Slide 35

Slide 35 text

36 分散台帳とスマートコントラクトの関係 ワールドステート (最新の状態を管理) ブロックチェーン ブロック(取引履歴を管理) … 呼び出し 開発 開発 各起動毎に記録 アプリケーション 台帳 読み込み/書き込み ブロックチェーン 開発者 スマート・コントラクト Peerの役割 ・アプリケーションとの接続 ・台帳の保持 ・スマート・コントラクトを実⾏ Peer イベント 出⼒ 出⼒

Slide 36

Slide 36 text

37 スマート・コントラクト ビジネスロジックによる処理の⾃動化や、柔軟な台帳の活⽤を実現する為の仕組み

Slide 37

Slide 37 text

38 1990年代にNick Szaboという法学者・暗号学者によって最初に提唱 • ⾃動販売機の例 狭義〜広義でいろいろな説明(⾒⽅)がある︓ • プログラムコード︓ビジネス・ルールのプログラム化 • 契約(コントラクト)の⾃動執⾏ • 執⾏条件と契約内容を事前に定義し、条件に合致 したイベントが発⽣すると⾃動執⾏する • DAO(Decentralized Autonomous Organization) 実現のための主要概念 契約に基づく取引内容をプログラムで定義し、契約条件の確認や履⾏を⾃動で 実⾏する仕組みだよ︕ スマート・コントラクト

Slide 38

Slide 38 text

39 Aさん (クライアント) トランザクションを発⾏ (= 所有権移転処理の呼び出し) Hyperledger Fabricではチェーンコードという形でスマートコントラクトを実装 チェーンコードに処理プログラムを記述する トランザクション AからBに 資産xyz123を移転 Hyperledger Fabricネットワーク AさんのPeer チェーンコード 処理(プログラム): •作成 …........ •所有権移転 …...... •属性変更 …....... 資産ID:xyz123 ・所有者︓A-san ・タイプ: ⾃動⾞ ・登録情報: xxxxxx CさんのPeer2 チェーンコード 処理(プログラム): •作成 …........ •所有権移転 …...... •属性変更 …....... 資産ID:xyz123 ・所有者︓ A-san ・タイプ: ⾃動⾞ ・登録情報: xxxxxx BさんのPeer3 チェーンコード 処理(プログラム): •作成 …........ •所有権移転 …...... •属性変更 …....... 資産ID:xyz123 ・所有者︓ A-san ・タイプ: ⾃動⾞ ・登録情報: xxxxxx プログラム⾔語は JavaScript, Typescriptなどに対応 Bさん (クライアント) Orderer CA(認証局) スマート・コントラクト (Hyperledger Fabricの例)

Slide 39

Slide 39 text

40 コンセンサス 分散ノード間で取引の完全性をシステム的に検証し保障する仕組み

Slide 40

Slide 40 text

41 クライアント Peer (Endorser) Chaincode Peer (Endorser) Chaincode Peer (Endorser) Chaincode Orderer クライアント Peer Ledger Peer Ledger Peer Ledger 処理の流れ 1. クライアン トがTx proposal を サ ブミット 2. Peer (endorser) がチェーンコードを 実⾏し、結果に署名 をしてクライアント に戻す 3. クライアント は、 Endorsement Policy を満たす数 のendorsement を集めたのち、Tx をサブミット 4. OrdererがTxの 順番を定義し、1 ブロック分のバッ チを送る 5. 各peerがTxをコミットする 前に検証 • Endorsement policyを充⾜してい るか︖ • Tx間の衝突がない か︖ 検証後、台帳に書込み コンセンサス = エンドースメント + オーダリング + バリデーション • ノードの役割を分離 エンドーサー オーダラー コミッター • Endorsement Policy チェーンコードを検証す るPeerを指定可能 • スケーラビリティを確 保 コンセンサスでのPeer間 のやりとりを抑制 コンセンサス

Slide 41

Slide 41 text

42 コンセンサス 管理者 無し 複数企業 単⼀企業 ネットワーク形態 パブリック型 コンソーシアム型 プライベート型 P2Pへの参加 ⾃由 許可制 不特定、悪意のある参加者を含 む可能性がある 参加者の⾝元が判明しており、信頼できる コンセンサス⽅式 Proof-of-Work(mining) など 分散コンセンサス形成アルゴリズム • 電⼒消費が多い • ファイナリティがない • 51%攻撃問題 • 軽量、⾼速、低消費電⼒ • ファイナリティがある トランザクション 処理時間 ⻑い(例︓10分) 短い(例︓数秒) 代表的なユースケース 仮想通貨 サプライチェーンでの取引など ビジネスネットワークでの使⽤ 実装例 Bitcoin, Ethereum Hyperledger コンセンサスとは︖ ・更新する情報が正しいこと ・更新後に、それぞれのノードのデータが同⼀になること

Slide 42

Slide 42 text

43 セキュリティ 電⼦署名や認証機能により参加者間の匿名性を確保したり 取引内容のプライバシーを保護する仕組み

Slide 43

Slide 43 text

44 • メンバーシップ・サービス – アイデンティティー管理、アクセス制御を実施 • エンロールメント証明書(Ecert) – ユーザーの⾝元を特定する証明書 • 許可制アクセス – Ecertで署名され、出所が明らかなトランザク ションのみ実⾏ - エンロールメント - 証明書(Ecert)の要求 Hyperledger Fabric ブロックチェーン ユーザー A 利⽤ Ecert トランザクションを起動 (Ecertで署名) エンロールメント証明書 (Ecert) U U 利⽤ ü Client Application SDK Client Application SDK メンバーシップ サービスプロバイダAPI 認証局 ブロックチェーン ユーザー B トランザクションを起動 (Ecertで署名) エンロールメント 証明書 (Ecert) ブロックチェーンネットワークに参加できるのは 認証局が発⾏した証明書を持ってるユーザーだけだよ︕ 認証局

Slide 44

Slide 44 text

45 Hyperledger Fabricだと、台帳の共有範囲を設定することができ、 データのプライバシーを強化することができるよー セキュリティ(プライバシー) チャネル ⼀部の参加者によるプライベートな データ共有が可能なんだぜ︕ チャネル1(全員) チャネル2(A社、C社、D社のみ) 台帳X 台帳X 台帳X 台帳X 台帳Y 台帳Y 台帳Y チェーン コードX チェーン コードX チェーン コードX チェーン コードX チェーン コードY チェーン コードY チェーン コードY A社 Peer B社 Peer C社 Peer D社 Peer 台帳Z チェーン コードZ チャネル3(B社、C社、D社のみ) 台帳Z チェーン コードZ 台帳Z チェーン コードZ

Slide 45

Slide 45 text

46 セキュリティ(プライバシー) チャネル ※図はイメージです Mクロソフト Oラクル Iビーエム Channel 1 Channel 2 Channel 3

Slide 46

Slide 46 text

47 更に⾼いプライバシー保護を実現する機能だよ︕ Private Data Collection • プライベートなデータは通常のブロッ クとは別に管理 • 同⼀チャネル内でも、⼀部のピアだけ がプライベート・データを受け取るよ うに設定可能 • それ以外のピアや順序付けサービス (Orderer)には、データのハッシュ 値だけが渡され、台帳に記録される ブロック プライベート ステートDB プライベート・ブロック ⼀時データ (プライベート・トランザクション、実⾏結果RWset) ステートDB ブロック 順序付け サービス (Orderer) クライアント・ アプリケーショ ン 1. プライベート・ トランザクション提 案 4. トランザクショ ンと結果のハッ シュ値のみを返却 ステートDB チェーンコード ブロック プライベート ステートDB プライベート・ブロック ⼀時データ (プライベート・トランザクション、実⾏結果RWset) ステートDB 2. チェーンコード実⾏ 3.プライベート データを⼀時デー タストアに保存し、 権限のあるピアに だけP2Pプロトコ ルで共有 5. ハッシュ値 6. ⼀ブロック分の トランザクション (ハッシュ値の み)を配信 ピア(エンドーサー) ピア(コミッター) 8. 権限のないピアは、 ハッシュ値だけを記録

Slide 47

Slide 47 text

48 セキュリティ(プライバシー) チャネル ※図はイメージです Mクロソフト Oラクル Iビーエム Channel 1 俺知ってる︕ 俺知ってる︕ 何の話︖ 何の話︖ つまり、そういうことだ

Slide 48

Slide 48 text

49 アプリケーション開発

Slide 49

Slide 49 text

50 アプリケーション開発での環境 チェーンコード、クライアントアプリケーションのSDKが⽤意されている ブロックチェーンI/F SDK(HFC)for Node.js アプリケーション メイン Web I/F Hyperledger Fabric Peer 台帳 Peer Peer チェーン コード チェーン コード チェーン コード 台帳 台帳 Node.jsクライアントアプリケ ーション express ブロックチェーン基盤 チェーンコード開発 VSCode Extension JavaScript, Typescript, Java, Go,.. SDK(HFC)によるブロックチェーンアプリケーシ ョン開発 ・Peerの追加 ・チャネルの作成 ・チェーンコードのデプロイ ・トランザクションの発⾏… etc.. etc.. 開発 トランザクション

Slide 50

Slide 50 text

51 まとめ – 結局ブロックチェーンとは︖

Slide 51

Slide 51 text

Database Blockchain RDB Smart Contract Stored Procedure Client Application アプリケーションを⽀えるデータベースという位置づけ 消すことの出来ない全トランザクション履歴を持つ → トレーサビリティにすぐれてる ネットワーク参加者全員で台帳という形でデータを共有 → 不正・改ざん 仮想通貨向けと汎⽤がある

Slide 52

Slide 52 text

おすすめ情報 ■Web連載「Hyperledger Fabric⼊⾨」シリーズ︓ 第 1 回: 基本的な構成 第 2 回: Peer/チャネル/Endorsement Policy の解説 第 3 回: コンセンサス/Ordering Service/Kafka/Zookeeper 第 4 回: Membership Service Provider 第 5 回: チェーンコードの書き⽅ 第 6 回: Hyperledger Fabric v1.4 のプログラミングモデル ■公式ドキュメント︓ https://hyperledger-fabric.readthedocs.io/en/latest/

Slide 53

Slide 53 text

イベント案内 https://ibm-developer.connpass.com/event/172414/ https://ibm.biz/BdqfUf IBM Cloud無料アカウント

Slide 54

Slide 54 text

Thanks 55 github.com/taijihagino Taiji HAGINO Sr. Developer Advocate IBM facebook.com/taiponrock linkedin.com/taiponrock @taiponrock

Slide 55

Slide 55 text

ご注意 この資料に含まれる情報は可能な限り正確を期しておりますが、⽇本アイ・ビー・エム株式会社の正式なレビューを受けておらず、当資 料に記載された内容に関して⽇本アイ・ビー・エム株式会社は何ら保証するものではありません。従って、この情報の利⽤またはこれら の技法の実施はひとえに使⽤者の責任において為されるものであり、資料の内容によって受けたいかなる被害に関しても⼀切の補償をす るものではありません。 また、IBM、IBMロゴ、およびibm.comは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。 他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。 現時点でのIBMの商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。当資料をコピー等で複製すること は、⽇本アイ・ビー・エム・システムズ・エンジニアリング株式会社および執筆者の承諾なしではできません。また、当資料に記載され た製品名または会社名はそれぞれの各社の商標または登録商標です。