Hyperledgerの概要説明資料作成のための覚え書きとして。今回はそのプロジェクトの一つのうちのFabricの概要についてまとめてみる。本記事内の引用文は以下サイトのグーグル翻訳結果を気になるところのみ修正して載せています。
http://hyperledger-fabric.readthedocs.io/en/latest/fabric_model.html#assets
Fabricは以下の要素で構成されている。
- アセット
- チェーンコード
- 元帳機能
- チャネルによるプライバシー
- セキュリティ＆メンバーシップサービス
- コンセンサス
アセット
資産は、有形資産（不動産およびハードウェア）から無形資産（契約および知的財産）までさまざまです。クライアント側のjavascriptでAssetsを簡単に定義し、付属のFabric Composerツールを使用してFabricアプリケーションで使用することができ ます。Fabricは、未使用のトランザクション出力を使用して、後続のトランザクションの入力として資産を交換する機能をサポートします。アセット（およびアセットレジストリ）はFabricにキーと値のペアの集合として存在し、状態の変化はチャネル元帳上のトランザクションとして記録されます。Fabricでは、任意のアセットをバイナリ形式またはJSON形式で表現できます。
UTXOを使ったアセットの交換が可能ということからBlockchainの特徴を引き継いでいることがわかります。またアセットのやりとりが元帳に記録されるというとこも特筆すべきことではないですね。データ形式もまた然りです。
チェーンコード
チェーンコードは、資産を定義するソフトウェアであり、資産を修正するための取引指示書である。言い換えれば、それはビジネスロジックです。チェーンコードは、キー値ペアまたは他の状態データベース情報の読み取りまたは変更のための規則を強制します。チェーンコード機能は、元帳の現在の状態データベースに対して実行され、トランザクション提案によって開始されます。チェーンコードの実行により、ネットワークに送信され、すべてのピアの元帳に適用される一連のキー値書き込み（書き込みセット）が行われます。
ここで言われているチェーンコードはトランザクションの指示をするためのプログラムコードという理解で良いと思います。一般的にGO言語が使われています。
元帳機能
元帳は、ファブリック内のすべての状態遷移の順序付けられた耐タンパー性の記録です。状態遷移は、参加者によって提出されたチェーンコード呼び出し（「トランザクション」）の結果です。各トランザクションでは、元帳に作成、更新、または削除としてコミットされている一連の資産キーと値のペアが生成されます。
元帳は、不変のシーケンシングされたレコードをブロックに格納するブロックチェイン（「チェーン」）と、現在のファブリック状態を維持するための状態データベースで構成されています。チャネルごとに1つの元帳があります。各ピアは、メンバーである各チャネルの元帳のコピーを保持します。
”耐タンパー性”という意味を知らない言葉が出てきたので調べてみた。
耐タンパー性とは、コンピュータシステムの内部構造の解析のしにくさ、見破られにくさのことである。
http://www.weblio.jp/content/%E8%80%90%E3%82%BF%E3%83%B3%E3%83%91%E3%83%BC%E6%80%A7
それ以外に特筆すべきことはなさそうです。
チャネルによるプライバシー
ファブリックは、チャネルごとに不変の元帳を使用するだけでなく、資産の現在の状態（つまり、キー値の更新）を操作および変更できるチェーンコードを使用します。元帳はチャネルの範囲内に存在し、ネットワーク全体で共有することができます（すべての参加者が1つの共通チャネルで運用されていると仮定して）。または、特定の参加者のみを含むように民営化できます。
ここでいうチャネルとはネットワークのことかなと思います。つまり同一ネットワーク内にいない場合は元帳を捜査・変更するためのチェーンコードを使用できないということでしょう。しかし気になるのは”特定の参加者のみを・・・”というところですね。これは参加ノードの管理機能に言及していると取れますが、果たしてこの機能を持つシステムが分散システムと言えるのかは疑問ですね。
後者のシナリオでは、これらの参加者は別々のチャネルを作成し、それによってトランザクションと元帳を分離/分離します。Fabricは、完全な透明性とプライバシーの間のギャップを橋渡しするシナリオを解決します。チェーンコードは、読み取りと書き込みを実行するために資産状態にアクセスする必要のあるピアにのみインストールされます（つまり、チェーンコードがピアにインストールされていないと、元帳と適切にインターフェイスできません）。データをさらに難読化するために、チェーンコード内の値は、元帳に追加する前にSHA0-256などの一般的な暗号アルゴリズムを使用して暗号化することができます（一部またはその全てを）。
ここでは先述したネットワークを複数作成することができるのでその中で使用されるトランザクションと元帳を別々にすることができるといっています。 気になるのはチェーンコードがインストールされていないと元帳との相互関係が築けないというとこです。今までこのドキュメントから見てきた中身から元帳にアクセするために以下のことが必要と言えると思います。
- ネットワークへの参加
- チェーンコードのインストール
これらをどう管理するのかが注目したいところですね。
セキュリティ＆メンバーシップサービス
Hyperledger Fabricは、すべての参加者が身元を知っているトランザクションネットワークの基盤となります。公開鍵インフラストラクチャは、組織、ネットワークコンポーネント、エンドユーザーまたはクライアントアプリケーションに関連付けられた暗号証明書を生成するために使用されます。その結果、より広範なネットワークとチャネルレベルでデータアクセス制御を操作し、管理することができます。Fabricのこの「許可された」概念は、チャネルの存在と機能と相まって、プライバシーと機密性が重要な懸案事項であるシナリオに役立ちます。
暗号化の実装、Fabricで使用されている署名、検証、認証の手法について、Fabric CAのセクションを参照してください。
ここでは言っていることがざっくりしているので述べられているようにCAのセクションを今後じっくり見て見ましょう。
コンセンサス
分散元帳技術では、コンセンサスは最近、単一の機能内で特定のアルゴリズムと同義語になっています。しかし、コンセンサスは単に取引の順序に同意するだけでなく、提案と承認、発注、検証、コミットメントまでのトランザクションフロー全体の基本的な役割を通じて、Hyperbelger Fabricで強調されています。要約すると、コンセンサスは、ブロックを構成する一連のトランザクションの正当性の完全サークル検証と定義されます。
結構大事なことが書かれてるかなという印象。コンセンサスはトランザクション検証のみならず全ての振る舞いで適用されるアルゴリズムということですかね。
合意は、ブロックのトランザクションの順序と結果が明示的なポリシー基準のチェックを満たしたときに最終的に達成されます。これらのチェックとバランスは、トランザクションのライフサイクル中に行われ、特定のメンバーが特定のトランザクションクラスを推薦する必要があることを指示する保証ポリシーの使用や、これらのポリシーが強制され、維持されることを確実にするシステムチェーンコードが含まれます。コミットメントの前に、同業者はこれらのシステムチェーンコードを使用して、十分な裏書きが存在し、それらが適切なエンティティから派生していることを確認します。さらに、トランザクションを含むブロックが元帳に追加される前に、元帳の現在の状態が合意または承認されたバージョンチェックが行われます。
ネットワーク内のあるメンバーが推奨された機能を使うことを強制・維持させるチェーンコードがコンセンサスの中には含まれており、ネットワーク内のエンティティは既に存在しているチェーンがそのチェーンコードが実行されているという裏付けを確認できるということですね。ブロックを繋げる際のバージョンチェックなどは既存のブロックチェーンと変わらない気がします。
多数の承認、妥当性検査、バージョン管理のチェックに加えて、トランザクションフローのすべての方向で進行中のID検証も行われます。アクセス制御リストは、ネットワークの階層層（チャネルへのサービスの注文）に実装され、トランザクション提案が異なるアーキテクチャのコンポーネントを通過すると、ペイロードは繰り返し署名、検証、認証されます。結論として、コンセンサスは取引の一連の合意された順序にのみ制限されるのではなく、提案からコミットメントまでのトランザクションの進行中に行われる進行中の検証の副産物として達成される最も重要な特性です。
とまぁざっとこんな感じですね。概念的な話なのでよくわからないこともあるのですが今回の発見としてはFabricとしての全く新しい技術アイテムは今の所なさそうなのが分かったことですね。
