Hyperledger Fabricを学ぶ（４回目）　「Peer」について

こんにちは。

このブログでは、ブロックチェーン関連を中心としたテック系の情報の紹介をしております。

この連載では、オープンソースのブロックチェーンプラットフォーム「Hyperledger Fabric」について、少しずつ勉強を進めてゆきます。

自分なりに公式のドキュメントを噛み砕きながら、分かり易くまとめて行きたいと思います。

１回目から３回目までは、Hyperledger Fabricの基本的な構成要素である「Peer」「CA」「Orderer」の概要と、ブロックチェーンにデータが書き込まれるまでの流れについて、簡単に説明してきました。

今回からは「Peer」「CA」「Orderer」について、もう少し詳細に説明をして行きたいと思います。

Peerの構造

Peerは一つのブロックチェーンネットワークの中で複数存在しています。

ブロックチェーンの基礎のなかでお話ししましたが、ブロックチェーンでは、同じ内容の台帳を複数の端末に分散して保持しています。

Hyperledger Fabricでは、複数のPeerが同一の台帳データを保持し、分散台帳の構造を実現しているのです。

Peerの中には「台帳」と台帳にアクセスするための「チェーンコード」の二つが含まれています。

アプリケーションとの接続

アプリケーションはブロックチェーンにトランザクション（取引情報など）を書き込むために、Peerへトランザクションを送信します。

台帳の保有

Peerの台帳の中にはさらに「ステートDB」と「ブロックチェーン」が含まれています。

チェーンコードの実行履歴がブロックチェーンに記録され、トランザクションを書き込んだ最新の台帳の情報がステートDBに記録されます。

Hyperledger Fabricでは、アプリケーションから台帳の情報を参照・書き込みを行う際、全ての取引履歴を紹介する必要はありません。

最新の情報を保持したステートDBにアクセスすることで、高速に処理を完了することができます。

チェーンコードの実行

チェーンコードは台帳へのアクセスが唯一許可されたプログラムです。

アプリケーションは、このチェーンコードを実行することで台帳の情報にアクセスすることができます。

例えば、A さんの資産を B さんに渡すと行った実際の処理を全て、チェーンコードに記載しています。

チェーンコードに特定の決められた処理だけを記述しておくことで、台帳への不正な処理を防げるようになっています。

また、チェーンコードもブロックチェーンネットワーク内のPeerで同じものが保持されています。


今回はPeerについて、少し細かくお話しました。

次回はOrdererについてお話します。