Frequently Asked Questions

Endorsement

エンドースメントアーキテクチャ:

質問:トランザクションをエンドースするために、ネットワーク内にいくつのピアが必要ですか？
回答:エンドースするために必要なピアの数は、チェーンコード定義で指定しているエンドースメントポリシーによって決まります。
質問:アプリケーションクライアントは、全てのピアに接続する必要がありますか？
回答:クライアントは、チェーンコードのエンドースメントポリシーで求められるより多くのピアに接続する必要があります。

Security & Access Control

質問:

どのようにしてデータのプライバシーを確保するのでしょうか？
回答:

データプライバシーには様々な側面があります。1つ目は、ネットワークをチャネルに分割する方法です。チャネルは認可された参加者のサブセットで、チャネルにデプロイされたチェーンコードでデータを閲覧することができます。

2つ目は、 チャネル内の他の組織から台帳データをプライベートに保つ private-data を使用する方法です。プライベートデータコレクションは、チャネルを分割することなく、同一チャネル内の組織のサブセットで、プライベートデータのエンドース、コミットとクエリを実現します。チャネル内の他の参加者はデータのハッシュ値を受け取ります。詳しい情報は、 Using Private Data in Fabric チュートリアルセクションを参照してください。また、 when to use private data instead of a channel セクションでは、キーコンセプトを説明しています。

3つ目は、プライベートデータを使用してデータをハッシュ化する代わりに、チェーンコードの呼び出し前にクライアントアプリケーションでデータをハッシュ化、もしくは暗号化する方法です。データをハッシュ化した場合、元データを共有する方法を用意する必要があります。また、データを暗号化した場合、復号するための鍵を共有する方法を用意する必要があります。

4つ目は、チェーンコードロジックにアクセス制御を設けて、組織内の明確なロールでデータアクセスを制限する方法です。

5つ目は、ピアのファイルシステムを用いて台帳データを暗号化し、さらにTLSを用いて送信データを暗号化する方法です。
質問:

ordererは、トランザクションデータを閲覧できますか？
回答:

ordererは、アプリケーションクライアントが送信したエンドースされたトランザクションを受信します。エンドースされたペイロードは、読み込みセットと書き込みセットを含み、その中にチェーンコードの実行結果を保持します。ordererはトランザクション送信者のアイデンティティ検証とトランザクションの順序付けのみを行うため、エンドースされたトランザクションの中身を確認しません。

もしデータをordererに閲覧されたくない場合は、Fabricのプライベートデータを用いてください。また、チェーンコードを呼び出す前に、クライアントアプリケーションでデータをハッシュ化もしくは暗号化する方法もあります。データを暗号化した場合は、復号鍵を渡す方法が必要です。

Application-side Programming Model

質問:

アプリケーションクライアントは、どのようにしてトランザクションの実行結果を知りますか？
回答:

トランザクションシミュレーション結果は、提案応答としてエンドーサーによってクライアントに返されます。エンドーサーが複数存在する場合、クライアントは全ての応答が同一かどうかをチェックし、順序付けとコミットメントのために結果とエンドースメントを送信します。最終的にコミットピアはトランザクションを検証し、クライアントはSDKで構築されるイベントを通して結果を知ることができます。
質問:

どのようにして台帳データをクエリできますか？
回答:

チェーンコードでは、キーを基にクエリできます。キーは範囲を指定してクエリでき、コンポジットキーは複数のパラメータに対して同様のクエリができます。コンポジットキーとしてownerとasset_idを使用した場合、特定のownerが保有する全てのアセットをクエリできます。これらのキーを基にしたクエリは、台帳を更新するトランザクションと同様に台帳の読み込みにも使用できます。

チェーンコードでアセットデータをJSONとして扱い、ステートデータベースとしてCouchDBを使用した場合、チェーンコードでCouchDBのJSONクエリ言語を使用することでチェーンコードデータバリューに対して複雑でリッチなクエリを使用できます。アプリケーションクライアントは読み込みのみのクエリを実行できますが、レスポンスはオーダリングサービスへトランザクションの一部として送信されません。
質問:

データの来歴を確認するために、どのようにして履歴データをクエリできますか？
回答:

チェーンコードAPIの GetHistoryForKey() を使用して、キーに対するバリューの履歴を取得できます。
質問:

ブロック処理でリカバリし、キャッチアップしているピアにクエリした場合、クエリ結果の正しさをどのように担保するのでしょうか？
回答:

クライアントから複数のピアにクエリし、ブロックの高さとクエリ結果を比較し、ブロックの高さがより高いピアを選ぶ形で良いです。

Chaincode (Smart Contracts and Digital Assets)

質問:

Hyperledger Fabricは、スマートコントラクトのロジックをサポートしていますか？
回答:

はい。この機能は Chaincode (チェーンコード) と呼ばれ、スマートコントラクトの関数やアルゴリズムを意味します。

チェーンコードはネットワーク上にデプロイされたプログラマティックなコードで、合意形成プロセスにおいてチェーン検証者が一緒に実行し検証します。開発者は、ビジネスコントラクト、アセット定義や共同で管理する分散アプリケーションを開発するためにチェーンコードを使用します。
質問:

どのようにしてビジネスコントラクトを作成できますか？
回答:

ビジネスコントラクトを開発する方法は2つあります。1つ目は、チェーンコードのスタンドアロンインスタンスに個別のコントラクトを実装する方法です。2つ目はより効果的で、非中央集権的アプリケーションを開発するためにチェーンコードを使用する方法です。これにより、1つもしくは複数タイプのビジネスコントラクトのライフサイクルを管理し、エンドユーザーがコントラクトのインスタンスをアプリケーション内でインスタンス化できます。
質問:

どのようにしてアセットを作成できますか？
回答:

ビジネスルールであるチェーンコードとデジタルトークンであるアセットを設計するためにメンバーシップサービスを、それらを管理するロジックと同様に使用します。

ブロックチェーンでアセットを定義する主な方法は2つあります。1つ目はステートレスなUTXOモデルで、アカウント残高を過去のトランザクションを基に作成する方法です。2つ目はアカウントモデルで、台帳上のステートストレージにアカウント残高を記録する方法です。

どちらの方法も、利点と欠点があります。ブロックチェーン技術はどちらか一方を推奨しているわけではなく、要求に応じて両方の方法を容易に実装することを担保します。
質問:

チェーンコードを作成するために、どの言語がサポートされていますか？
回答:

チェーンコードはどのプログラミング言語でも作成でき、コンテナで実行されます。現在は、Go、Node.jsとJavaがサポートされています。
質問:

Hyperledger Fabricは、ネイティブな通貨がありますか？
回答:

いいえ、ありません。しかし、チェーンネットワークでネイティブな通貨を必要とする場合、チェーンコードを用いて独自のネイティブな通貨を開発できます。ネイティブな通貨の共通属性は取引量であり、チェーン上でトランザクションが処理される度にチェーンコードで定義した通貨が取引されます。

Differences in Most Recent Releases

質問:リリース毎の差分をどのページで確認できますか？
回答:後続リリースとの差分は、 Releases に纏められています。
質問:このページに回答がない技術的な内容は、どこで質問できますか？
回答:StackOverflow で質問してください。

Ordering Service

質問:オーダリングサービスを起動している状況で、コンセンサスアルゴリズムを変更することはできますか？
回答:その状況でコンセンサスアルゴリズムを変更することはサポートしていません。
質問:ordererシステムチャネルとは何ですか？
回答:ordererシステムチャネル（オーダリングシステムチャネルとも呼ばれる）は、ordererを初期起動した際に作成されるチャネルです。チャネル作成を統合するために使用されます。ordererシステムチャネルは、コンソーシアムと新規チャネルの初期設定を定義します。チャネル作成時に、コンソーシアムの組織定義である、 /Channel グループの値とポリシーを、 /Channel/Orderer グループの値とポリシーと同様に、新規初期チャネル定義の形式で全て統合します。
質問:アプリケーションチャネルを更新する場合、ordererシステムチャネルも更新すべきですか？
回答:一度アプリケーションチャネルを作成すると、ordererシステムチャネルを含めた他のチャネルとは無関係な形で管理されます。変更内容によっては、他のチャネルに反映すべきものとすべきでないものがあります。一般的に、MSPの変更は全てのチャネルに同期され、ポリシーの変更は特定のチャネルにのみ反映されます。
質問:オーダーリングとアプリケーション、2つのロールを持った組織を運用できますか？
回答:できますが、非推奨な設定です。デフォルトでは、 /Channel/Orderer/BlockValidation のポリシーにより、有効なオーダーリング組織の証明書を持つ組織は、ブロックに署名できます。オーダーリングとアプリケーション、2つのロールを持った組織を運用する場合、オーダリングの権限を持ったサブセットにブロック署名者を制限するポリシーに変更すべきです。
質問:Fabric向けにコンセンサスを実装したいのですが、どこから始めたらいいでしょうか？
回答:コンセンサスプラグインは、 consensus package で定義された Consenter と Chain インタフェースを実装する必要があります。ここには、raftを使用していないプラグインがあります。実装内容に応じて、学習すると良いでしょう。オーダリングサービスのコードは、 orderer package にあります。
質問:ネットワークを立ち上げた後、バッチタイムアウトなどのオーダリングサービスの設定を変えたいのですが、何をしたら良いでしょうか？
回答:これは、ネットワーク再設定に該当します。詳しくは、 configtxlator トピックを参照してください。

BFT

質問:BFTバージョンのオーダリングサービスは、いつから使用可能になりますか？
回答:明確な時期は設定されていません。2.x系のサイクルの間はリリース、すなわちFabricのマイナーバージョンアップグレードに注力します。