Hyperledger Fabric v1.0で いったい何が変わったのか? 第1回 Peer-Ordererモデル

Hyperledger Fabric v1.0で いったい何が変わったのか? 第1回 Peer-Ordererモデル

はじめに


これから3回にわたり、Hyperledger Fabric v0.6とv1.0の違いを技術的に解説していきたいと思います。

v1.0ではv0.6がもつスケーラビリティとプライバシーにかかわる課題解決のため以下変更が実施されました。
  • 第1回: スケーラビリティ
    • v0.6では全ノードが合意形成とChaincode実行を実施
    • v1.0ではChaincodeの実行管理をする「Peer」と、トランザクションの順序整列をする「Orderer」に分類、トランザクションの並列/分散処理を実現
  • 第2回: プライバシー
    • v0.6では全ノードが全Chaincodeを閲覧可能
    • v1.0ではどのノードでどのChaincode実行に関与するかを制御可能
  • 第3回:認証(authentication)・権限認可(authorization)
    • 上記実現のため、認証・権限認可およびID管理が変更


第1回は上記スケーラビリティについて解説します。

本記事は、過去にコンセンサス・ベイスが主宰していたオンラインサロンの記事です。記事は2017年~2018年にかけて執筆されたため、一部は、既に古くなっている可能性があります。あらかじめご了承ください。

Peer-Ordererモデル


ブロックチェーンにおけるコンセンサスとは、ブロックを構成するトランザクション実行にかかわる申請・署名・整列・確認・委任という一連の検証過程を意味します。
  • 申請(propose):トランザクションの実行を申請すること
  • 署名(sign):トランザクションを検証、実行結果を署名すること
  • 整列(order):トランザクションをブロックに整列すること
  • 確認(validate):ブロックの正当性を確認すること
  • 委任(commit):ブロックのledgerへの追加を委任すること


v1.0ではこの5つの検証過程を2つの役割に分類しています。

検証における2つの役割
  • 承認(endorsement):申請(propose)・署名(sign)
  • 合意(consensus):整列(order)・確認(validate)・委任(commit)


v0.6のPBFT(Practical Byzantine Fault Tolelance、分散合意形成アルゴリズム)では全ノードがコンセンサスとChaincode実行の全てを担っていましたが、v1.0では効率的処理をめざし以下2種類のノードに上記2つの役割とトランザクション処理を分担させています。

2種類のノードと役割
  • Peer:承認(endorsement)、Chaincode実行、ledger管理
  • Orderer:合意(consensus)

では以下7つのステップからなるトランザクション処理例をもとに2種類のノードの役割を確認していきましょう。
  • (1/7) クライアントアプリケーションがChaincode Aの実行を担当するPeer E0にトランザクション実行を申請(propose)します。
  • (2/7) Peer E0は上記トランザクションを検証、実行結果(Chaincode A実行に必要なデータを紐付)に署名(sign)しクライアントアプリケーションに結果を通知します。
  • (3/7)  クライアントアプリケーションはポリシーにて追加署名が必要となっているPeer E1とE2に追加署名を要求します。
  • (4/7) Peer E1とE2は署名結果をクライアントアプリケーションに通知します。
  • (5/7) クライアントアプリケーションはトランザクションを生成しOrderer Cに配信します。
  • (6/7) Orderer Cは受信したトランザクションをブロックに整列(order)、検証(validate)し、ポリシーで決められたPeerへledgerへの追加を委任(commit)します。
  • (7/7) Peerは受信したブロックを検証し、ledgerに追加します。

なお、図中のE:Endorsing PeerとはPeerを、C:Consensus ServiceとはOrdererを、Smart ContractとはChaincodeのことをそれぞれ意味しています。


(1/7) クライアントアプリケーションがChaincode Aの実行を担当するPeer E0にトランザクション実行を申請(propose)します。



サンプルトランザクション (1/7)

(HyperledgerMeetupDec6.2016.pdfより抜粋)


(2/7) Peer E0は上記トランザクションを検証、実行結果(Chaincode A実行に必要なデータを紐付)に署名(sign)しクライアントアプリケーションに結果を通知します。



サンプルトランザクション (2/7)

(HyperledgerMeetupDec6.2016.pdfより抜粋)


(3/7)  クライアントアプリケーションはポリシーにて追加署名が必要となっているPeer E1とE2に追加署名を要求します。



サンプルトランザクション (3/7)
(HyperledgerMeetupDec6.2016.pdfより抜粋)


(4/7) Peer E1とE2は署名結果をクライアントアプリケーションに通知します。



サンプルトランザクション (4/7)

 (HyperledgerMeetupDec6.2016.pdfより抜粋)


(5/7) クライアントアプリケーションはトランザクションを生成しOrderer Cに配信します。



サンプルトランザクション (5/7)

(HyperledgerMeetupDec6.2016.pdfより抜粋)


(6/7) Orderer Cは受信したトランザクションをブロックに整列(order)、検証(validate)し、ポリシーで決められたPeerへledgerへの追加を委任(commit)します。



サンプルトランザクション (6/7)

 (HyperledgerMeetupDec6.2016.pdfより抜粋)


(7/7) Peerは受信したブロックを検証し、ledgerに追加します。



サンプルトランザクション (7/7)

 (HyperledgerMeetupDec6.2016.pdfより抜粋)

なお、トランザクションをブロックに整列するためのOrderer-Peer間のメッセージングにはKafka(pub-sub型メッセージングシステム)を利用しています。

免責事項:


本記事に掲載されている記事の内容につきましては、正しい情報を提供することに務めてはおりますが、提供している記事の内容及び参考資料からいかなる損失や損害などの被害が発生したとしても、弊社では責任を負いかねます。実施される際には、法律事務所にご相談ください。

技術・サービス・実装方法等のレビュー、その他解説・分析・意見につきましてはblock-chani.jp運営者の個人的見解です。正確性・正当性を保証するものではありません。本記事掲載の記事内容のご利用は読者様個人の判断により自己責任でお願いいたします。

参考資料:


・Docs » Welcome to Fabric
http://hyperledger-fabric.readthedocs.io/en/latest/index.html
・Hyperledger Fabric V1 – Meetup
http://files.meetup.com/19726545/HyperledgerMeetupDec6.2016.pdf
・Hyperledger Fabric 1.0 概要、第1回Hyperledger Tokyo Meetup 2017年3月16日講演

株式会社日立製作所 山田仁志夫、Hitachi America 大島訓

・エンタープライズ・ブロックチェーンに求められるセキュリティ要件とIBMの取組み
 2017年6月27日講演 日本IBM株式会社 野村幸平

会社紹介


弊社(コンセンサス・ベイス株式会社)は、2015年設立の国内で最も古いブロックチェーン専門企業です。これまでに、大手企業の顧客を中心に、日本トップクラスのブロックチェーンの開発・コンサルティング実績があります。ブロックチェーンに関わるビジネスコンサル・システム開発・教育・講演などありました、お気軽にお問い合わせください。

会社ホームページ
https://www.consensus-base.com/

ブロックチェーンの専門企業で働いてみませんか?

当サイトを運営するコンセンサス・ベイス株式会社では、エンジニア、プロジェクトマネージャー、ライターなど、様々なポジションで一緒に働いてくださる仲間を募集しています。

ブロックチェーン業界にチャレンジしてみたいあなたのご応募をお待ちしております!

Hyperledger Fabricカテゴリの最新記事