空谷に吼える

ブロックチェーン／DLTまわりのなにかしらを書いていく所存

Hyperledger Fabricの主な構成要素をざっくりと解説

Hyperledger Fabric 解説 ブロックチェーン

ていうか前回コンセンサスの話する前に先にこっちを書いておくべきだった、てっとり早くアクセス数を稼ごうとしてコンセンサスの話を始めてしまった、はんせいしています

なんの話

  • Hyperledger Fabricのトランザクション、コンセンサスを理解する前提として必要な部分だけに絞って構成要素をざっくりと説明

内容

前回のエントリで「HLFのコンセンサスの概要を学んでいきましょう！！！！」みたいな話をしたけども、もしかすると紹介した記事を読んでいて「PeerとかOrdering ServiceとかChaincodeとかいきなり出てきて意味がわからない、たすけてくれ」というひともいると思います。それはアーキテクチャとかコンポーネントをある程度まで先にわかってないとだめなのにいきなりコンセンサスのお勉強をしたからです。あなたはそのあたりを先にわかっておくことによりたすかることができる

というわけでちょう大づかみに構成要素を説明します。ただしおれはシンプルに生きていきたい、なのでここではコンセンサスの理解に必要ないっぽいCAノード、MSP、Organizationの話はしないぞ

Peerノード

台帳（分散台帳の1コピー）を保持し、また、Chaincodeによる台帳の照会、更新を実行します。

台帳（Ledger)

State DBとブロックチェーンのふたつのデータストアから成り立つKey-Value Store（のようなもの）です。ひとによってはブロックチェーン部分だけを指してLedgerと呼んでいたりもしますが、公式ドキュメントではふたつそろってLedgerと呼んでいるっぽい

State DB（a.k.a. World State）

Keyの現在のValueを格納しています。HLFをState MachineとみなしたときのStateにあたる要素であり、いわゆるデータベースなソフトウェアを使っているのでState DBという名前です、わかりやすいですね
素のHLFではPeerノード組み込みのLevelDBか、Peerノード外部に置かれるCouchDBを選択できます。

ブロックチェーン

KeyのValueの履歴およびトランザクション履歴を格納しています。ここの部分がBlockchainです、というのは言わなくてもわかりますね

Ordering Service

ひとつまたは複数のOrdererノードから構成されるサービスです。トランザクションの順序を確定してブロックを生成し、Peerノードに配布します。順序付け（ordering）するからOrdering Serviceであり、命令（order）するからではない
求める耐障害性、堅牢性に応じてSoloとかKafkaとかの構成を選べます。

Chaincode

台帳に対して照会、更新などを行うビジネスロジック、いわゆるスマートコントラクトですね。Peerノードごとにインストールしておき、クライアントからのリクエストに応じてPeerノードが実行します。
開発言語としては、Golang、Node.jsに加えHLFv1.3からはJavaがサポートされています。

チャネル（Channel）

分散台帳を共有する範囲です。Peer間のデータの共有はチャネルによって分断されます。

  • あるチャネルにはn個のPeerノードを所属させることができ、そのチャネルに所属するPeerノードの間で分散台帳が共有されます。ということは、チャネルごとに台帳が存在する、ということになります。
  • あるPeerノードは複数のチャネルに所属することができます。つまり、Peerノードは所属しているチャネルの数の分だけの台帳を保持することになります。
  • あるチャネルは単一のOrdering Service（NOT単一のOrdererノード）に所属します
  • あるOrdering Serviceは複数のチャネルを担当することができます。

おススメお勉強情報

ここまで読んできたことであなたはHLFの構成要素がだいたいわかっています、だいたいわかったあとに↓を読み進めていくことでめっちゃわかるようになります。
おれはだいたいわかってればいいんだというひとは読まなくてもおｋ