ブロックチェーンアプリを実際に動かしてみよう！

IBM Bluemix User Group（BMXUG）リレー寄稿　第6回

4. Blockchainの4つの技術要素

Fig 6. Blockchainの4つの技術要素

4.1. Distributed Ledger

各Peerの構成

• Validating Leader：検証リーダー。以下の検証ピアの権限に加え、トランザクションの書き込みを行う
• Validating Peer：検証ピア。合意形成アルゴリズムを実行する
• Non Validating Peer：非検証ピア。通常ノード。アプリケーションへの接続のみ可能

Fig 7. Peerの構成

Validating Peerの構成

• 取引台帳
  • Blockchainそのもの
  • Transaction（Smart Contractの処理呼出）がログのように記録される
• Chaincode
  • Transactionを契機に実行されるプログラム（Goで実装）
  • 同じChaincodeが全てのVPに配布され、SandBox（Dockerコンテナ）内で実行される
  • 目的ごとに複数のChaincodeが作成される
• Key-Value Store（KVS）
  • Facebook社のRocksDBという高速書込が可能なKVS型DBを利用
  • Transactionを実行した結果得られる「最新の状態」を記録
    • Key：chaincode ID + cKey
    • Value：任意のデータ
  • 全てのVPで同一の内容を持ち、そのHash値がBlockchainに記録される
  • 変更を差分管理

4.2. Cryptography

4.2.1. 認証局（CA）、eCertとtCert

　認証局（CA）によりUserの身元を特定する証明書であるeCertや、Transactionごとの証明書tCertが発行される。

• eCert（Enrollment Certificates）：
  • Userの身元を特定する、長期的に使用される証明書
  • User、VP、NVPの全てに発行される
• tCert（Transaction Certificates）：
  • Transactionごとに発行される、短期的な証明書
  • eCertを持つUserに対して発行されるが、匿名化されており、認証局にしかその関連性は分からない
  • Transactionごとに異なるtCertを用いることで、複数のTransactionsが同一のUserに属することを隠蔽することが可能となる（IdentityとPrivacyの問題を解決）

4.3. Consensus

4.3.1. Consensus（合意形成）モデルの選択

Fig 8. Consensusモデルの例

4.4. Chaincode

4.4.1. Chaincodeの種別

• 作成、登録など
• 所有権移転、属性変更など
• 問い合わせなど

4.4.2. Chaincodeの実行内容

• 全てのValidating Peer（VP）に配布
• VPはChaincodeをDockerコンテナ上に展開して実行
• Hyperledgerにおいては「Transaction」=「Chaincode（Smart Contract）の実行」
• 資産の最新状態はKVSに保存
• 契約上の条件やルールをビジネスロジックとしてSmart Contract上に実装することにより、常に合意されたルールに基づいた処理が実行される

4.4.3. Chaincodeの処理

• Deploy：ソースコードに基づき、Chaincodeを登録（台帳への書込を伴う）
• Invoke：Chaincodeの実行、KVSへの読み書き（台帳への書込を伴う）
• Query：Chaincodeに対しデータの問い合わせ、KVSからの読み込み（台帳への書込なし）