1. 背景
現在、ブロックチェーンはその根幹で精力的に開発が進められ、応用しようとしている段階にあります。ブロックチェーンをビジネス分類すると、パブリックチェーン（BTC/ETH/EOS）、コンソーシアムチェーン（Hyperledger Fabric）、プライベートチェーン（個人利用）に大別されます。
パブリックチェーンは通貨圏と結びついたものとして理解でき、筆者が携わってきた業界でもある。現在の天王朝の通貨圏政策は、推進するものでも反対するものでもないと言える。近年、国はブロックチェーンの開発を奨励しており、これは実際にアライアンスチェーンにとって大きな励ましの信号となっています。
アライアンスチェーンの出発点は、一部の業界におけるトレーサビリティ、トラストレス性、オープン性、透明性の問題を解決することであるため、システムインセンティブにいわゆるトークン（トークン）はある程度必要ありません。チェーンはライセンスメカニズムを導入しているため、そのアーキテクチャはほとんどのパブリックチェーンとは大きく異なります。最近、私自身の仕事上の問題からこのプロジェクトに連絡して知りましたHyperledger Fabric。したがって、既存の情報とソースコードから始めて、プロジェクトの構造と詳細を分析します。
2. データとソースコード
2.1. hyperledger-fabric Github リポジトリ2.2
. hyperledger-fabric 開発者ドキュメント
3. 全体構成
3.1 システムアーキテクチャ
4. コードのディレクトリ構造
以下は、ファブリック 2.0コードのディレクトリ構造と機能の説明です。
wujinquan@wujinquandeMacBook-Pro ~/workspace/gospace/src/github.com/hyperledger/fabric tree -L 1
.
├── CHANGELOG.md
├── CODEOWNERS
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Gopkg.lock
├── Gopkg.toml
├── LICENSE
├── MAINTAINERS.md
├── Makefile
├── README.md
├── SECURITY.md
├── bccsp //密码学相关,用于签名、加密等
├── ci //常用脚本文件
├── ci.properties
├── cmd //项目命令行，可从此目录入手了解整个项目,包含节点的启动、功能配置、停止等操作
├── common //公用代码
├── core //项目的核心代码，包含包括权限控制、 chaincode 、committer、 endorser、 ledger、 等功能 代码实现
├── discovery //为客户端程序提供服务发现的功能
├── docker-env.mk
├── docs
├── go.mod
├── gossip //是 Fabric 在节点间达成最终一致性， 实现的信息传播的模块
├── gotools.mk
├── idemix
├── images
├── integration
├── internal
├── msp //全称为 Membership service provider ，为 Fabric 提供成员服务
├── orderer //进行全局的交易排序以及切块
├── pkg
├── protoutil
├── release_notes
├── sampleconfig//配置示例
├── scripts //常见脚本
├── test-pyramid.png
├── testingInfo.rst
├── tox.ini
├── vagrant
└── vendor //Golang 第三方包管理器
21 directories, 18 files
wujinquan@wujinquandeMacBook-Pro ~/workspace/gospace/src/github.com/hyperledger/fabric
5. ノードの概念
ノード: ブロックチェーンの通信エンティティであり、論理的な概念であり、異なるタイプの複数のノードを同じ物理サーバー上で実行できます。ノードには主に 4 つのタイプがあります。
5.1 クライアントノード
クライアントは、ブロックチェーン ネットワークと通信するために、特定のピア ノードまたは順序付けサービス ノードに接続する必要があります。クライアントはトランザクション提案をエンドーサー ノード (エンドーサー) に送信し、十分なエンドースメントが収集されると、トランザクション提案がソート サービス ノードにブロードキャストされ、ブロックのソートと生成が行われます。
5.2 ノードピア
ピア ノードは、その役割に応じてコミッター、エンドーサー、リーダー、アンカーに分類できます。
5.2.1 アカウンティングノード
すべてのピアノードは簿記ノード (コミッター) であり、順序付けサービス ノード ブロック内のトランザクションを検証し、状態と台帳 (レジャー) のコピーを維持する責任があります。ノードはトランザクションを含むブロックを注文者ノードから定期的に取得し、これらのブロックを発行して検証した後、これらのブロックはブロックチェーンに追加されます。コミッター ノードは構成ファイルでは構成できません。現在のクライアントまたはコマンド ラインがトランザクション リクエストを開始するときに、関連するコミッター ノードを手動で指定する必要があります。複数の簿記ノードが存在する場合があります。
5.2.2 承認ノード
一部のノードはトランザクションを実行し、結果に署名して承認し、エンドーサーとして機能します。承認ノードは、特定のチェーンコードにバインドされる動的ロールです。各チェーンコードは、インスタンス化されるときに承認ポリシーを設定し、トランザクションが有効になる前にどのノードがトランザクションを承認するかを指定します。また、アプリケーションがトランザクション承認リクエストを開始したときのみ承認ノードとなり、それ以外の場合はトランザクションの検証とアカウントの維持のみを行う通常の会計ノードとなります。承認ノードは構成ファイルを通じて指定することはできませんが、トランザクション要求を開始するクライアントによって指定されます。複数の承認ノードが存在する場合があります。
5.2.3 アンカーノード
ピア ノードはアンカー ノード (アンカー ピア) になることもでき、アンカー ノードは主に、組織を代表して他の組織と情報を交換する責任を負います。各組織には組織にとって非常に重要なアンカーノードがあり、アンカーノードに問題があると、現在の組織は他の組織と連絡が取れなくなります。アンカーノードの構成情報は、configtxgenモジュールの構成ファイルconfigtx.yamlに設定されます。アンカー ノードは 1 つだけ存在できます。
5.2.4 マスターノード
ピア ノードは、並べ替えサービス ノードと通信できるマスター ノード (リーダー ピア) になることもでき、並べ替えサービス ノードから最新のブロックを取得して組織内で同期する責任を負います。組織全体でマスター ノードは 1 つだけ存在できます。
5.3 サービスノードの順序付けのソート
承認署名を含むトランザクションを受信し、パッケージ化されていないトランザクションをソートしてブロックを生成し、ピアノードにブロードキャストします。順序付けサービスはアトミック ブロードキャストを提供します。これにより、同じチェーン上のノードが同じ情報を受け取り、同じ論理順序を持つことが保証されます。
5.4 CAノード
Fabric1.0の認証局はサーバーとクライアントで構成されます。CA ノードはクライアントから登録アプリケーションを受け取り、ユーザーがログインして ID 証明書を取得するための登録パスワードを返します。ブロックチェーン上のすべての操作にはユーザー ID の検証が必要です。
6. お取引の流れ
これまでの記事では、Fabricプロジェクトがどのように機能するかをまだ紹介していませんが、パブリック チェーンであれ、アライアンス チェーンであれ、実際には基本的なトランザクション プロセスが全体のプロセスの大部分を占めています。したがって、トランザクションから開始してブロックチェーンを分析することが最善の方法です。この観点からチェーン全体を見ると、コンテキストがかなり明確に把握できます。
Fabric通常のトランザクション プロセスは、ファブリック ネットワーク全体が構築され、正常に動作していることを前提としており、ユーザーは組織の認証局 (CA) に登録および登録されており、同時にネットワーク検証のために取得された暗号化されたマテリアルが取得されます。チェーン コードはノードとネットワークにインストールされ、チャネル上でインスタンス化されるチェーンコードには、一連のトランザクション命令を定義し、どのノードがトランザクションを承認する必要があるかを示すチェーンコードの承認ポリシーを設定するロジックが含まれています。
上図に示すように、トランザクションは基本的に次の 8 つのステップに分けることができます。
6.1 取引提案の提出
アプリケーション（クライアントノード）がトランザクション提案を構築した後（トランザクション提案には、このトランザクションで呼び出される契約識別子、契約メソッドとパラメータ情報、クライアントの署名などが含まれます）、承認ポリシーに従って承認ノードが選択されます。取引提案を実行し、承認署名を続行します。承認ピアは、チェーンコード内の承認ポリシーによって指定されたノードです。通常の状況では、実行後の承認ノードの結果は一貫しており、結果上の承認ノードの署名のみが異なります。
6.2 提案の実施をシミュレーションし、それを承認する
エンドースメント ノードは、トランザクション提案を受信した後、いくつかの検証を実行します。検証に合格した後、エンドースメント ノードは、現在の台帳データに基づいてチェーンコード内のビジネス ロジックをシミュレートして実行し、読み書きセット (RwSet) を生成します。シミュレーション実行中は台帳データは更新されません。次に、承認ノードはこれらの読み書きセットに署名して提案応答 (提案応答) を生成し、それがアプリケーションに返されます。
6.3 トランザクションの裏書収集（シミュレーション実行結果の返却）
アプリケーションは提案応答を受信した後、承認ノードの署名を検証します (すべてのノードは、メッセージを受信するときにメッセージの正当性を検証する必要があります)。チェーンコードが台帳クエリ操作のみを実行する場合、アプリケーションはクエリ応答をチェックするだけでよく、トランザクションを順序付けサービス ノードに送信しません。チェーンコードが台帳を呼び出す場合、台帳を更新するためにトランザクションを並べ替えサービスに送信する必要があります (送信する前に、承認ポリシーが満たされているかどうかが判断されます)。
6.4 トランザクションリクエストを作成して順序付けサービスノードに送信する
アプリケーションはすべてのエンドースメント ノードの署名を受信した後、SDK を呼び出してエンドースメント署名に基づいてトランザクションを生成し、それを順序付けサービス ノードにブロードキャストします。トランザクション生成のプロセスは非常に簡単で、すべてのエンドースメントノードの実行結果が完全に一致していることを確認し、トランザクション提案、提案応答、エンドースメント署名をパッケージ化してトランザクションを生成するだけです。
6.5 ソートサービスノードはトランザクションをソートし、ブロックを生成します
ソートサービスノードは、ネットワーク内のすべてのチャネルによって送信されたトランザクション情報を受信し、トランザクションエンベロープを読み取ってチャネル名を取得し、各チャネルでのトランザクションの受信時刻の順序に従ってトランザクション情報をソートします（マルチチャネル分離）。ブロックを生成します。(このプロセス中、仕分けサービス ノードはトランザクションが正しいかどうかは気にせず、仕分けと梱包のみを担当します。トランザクションの正当性はステップ 7 で検証されます)
6.6 順序付けサービスノードがブロックをマスターノードにブロードキャストする
ソートサービスノードはブロックを生成した後、それをチャネル上のさまざまな組織のマスターノードにブロードキャストします。
6.7 会計ノードはブロックの内容を検証し、台帳に書き込みます。
すべてのピアノードはアカウンティング ノードであり、ノードがチャネルに参加した台帳データを記録します。会計ノードは、仕分けサービス ノードによって生成されたブロックを受信すると、ブロック トランザクションの有効性を検証し、それをローカル台帳に送信して、ブロックを生成するイベントを生成します。ブロック イベントをリッスンするアプリケーションは、後続の処理を実行します。(設定ブロックを受信すると、キャッシュされた設定情報が更新されます)
6.8 マスターノードは組織内の最新のブロックを同期します
トランザクションが無効な場合、ブロックも更新されますが、ワールド状態は更新されません。(ブロックには操作ステートメントが格納され、ワールド ステートには処理されたデータが格納されます)