4. Blockchainの4つの技術要素
4.1. Distributed Ledger
各Peerの構成
- Validating Leader：検証リーダー。以下の検証ピアの権限に加え、トランザクションの書き込みを行う
- Validating Peer：検証ピア。合意形成アルゴリズムを実行する
- Non Validating 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（合意形成）モデルの選択
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からの読み込み（台帳への書込なし）
