JP7350845B2 - ブロックチェーン・リソースを格納するブロックチェーン通知ボード - Google Patents

Description

本願は、全般的にデータベース・ストレージ・システムに関し、特に、変更不可能な台帳の通知ボードを介してネットワーク位置情報およびその他ブロックチェーン・リソースが格納され得る、ブロックチェーンなどの非集中的データベースに関する。

集中的データベースは１つの位置にある１つの単一データベース（例えばデータベース・サーバ）にデータを格納し、維持する。この位置は、例としてデスクトップ中央処理ユニット（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、サーバＣＰＵ、またはメインフレーム・コンピュータなどの中央コンピュータであることが多い。集中的データベースに格納される情報は、典型的に、異なる複数の地点からアクセス可能である。例として、クライアント／サーバ構成に基づき、複数のユーザまたはクライアント・ワークステーションが同時に集中的データベースで作業することができる。集中的データベースは、その単一の位置が理由で、特にセキュリティ目的に関わる管理、維持、および制御が容易である。全データを格納する場所が単一であるということは、所与のデータのセットが一次レコードを１つのみ有するということも意味するので、集中的データベースの中ではデータの完全性が最大化され、データの冗長性が最小化される。これは、可能な限り正確かつ一貫したデータの維持を支援し、データ信頼性を高める。

しかしながら、集中的データベースには大きな欠点が伴う。例として、集中的データベースは単一障害点を有する。具体的には、フォールト・トレランス機構がない場合にハードウェア障害が発生すると、データベースの中のすべてのデータが失われ、全ユーザの作業が中断される。さらに、集中的データベースはネットワーク接続性への依存度が高い。結果として、インターネット接続が遅いほど、それぞれのデータベース・アクセスに必要な時間が長くなる。もう１つの欠点は、単一の位置が原因で集中的データベースが高トラフィックに直面するときのボトルネックである。さらに、集中的データベースが提供するデータへのアクセスは、データのコピーが１つしかデータベースにより維持されないことが理由で、限定的である。結果として、重大な問題をもたらしたり格納されたデータに上書きする危険を冒したりすることなく複数のユーザ・ステーションが同じ１つのデータに同時にアクセスすることはできない。さらに、中央データベース・システムが有するデータ冗長性は最低限か皆無であるため、データのセットが予期せず失われた場合、それをバックアップ・ディスク・ストレージから手動操作によって行う以外の形で取り戻すのは、非常に困難である。

ブロックチェーン・システムなどの非集中的データベースは、集中的データベースの欠点に対処できるストレージ・システムを提供する。ブロックチェーン・システムでは、複数のピア・ノードがブロックチェーンを含む分散型台帳を格納する。クライアントは、ブロックチェーンにアクセスするためにピア・ノードと相互作用する。ピア・ノードは、互いに信頼していなくてもよく、しかも、異なる利害を有する異なるエンティティにより制御されてもよい。さらに、ブロックチェーンには中央機関がない。したがって、分散型台帳に対してデータの追加または変更がされるには、ピア・ノードのコンセンサスが発生しなければならない。コンセンサスは、信頼のないピア・ノードのブロックチェーン・システムにおいて、信頼が実現されるための方策を提供する。

ブロックチェーンと通信するために、クライアントはピア・ノードにリクエストをサブミットし得る。リクエストを送信するために、クライアントはブロックチェーン・ピア・ノードの通信位置（例えばネットワーク・アドレス）を必要とする。ブロックチェーン・ピア・ノードのネットワーク・アドレス情報は、ピア・ノードまたはその他ブロックチェーン・エンティティからクライアントに伝達されて、クライアント・ノードにより内部に格納され得る。しかしながら、不正行為により問題が発生する可能性もある。ブロックチェーン・ピア・ノードは、ハイジャックされたり、完全に取って代わられたりする虞がある。別の例として、ブロックチェーン自体が取って代わられる虞もある。参照されるネットワーク・リソースの一意性および真正性は、現在の技術において不十分である。さらに、ネットワーク・アドレス情報に、ネットワーク・アドレスの変更、ピア・ノードの除去、ピア・ノードの追加、および同様のことなど正当な変更がある事態もある。よって、必要とされているのは、ブロックチェーン・システムの中での不正アクティビティを防止する、ブロックチェーン・リソースを管理するためのより信頼ある方策である。

例示の一実施形態は、ストレージと、複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ：ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｎｄｉｃａｔｏｒ）を受信するように構成されたネットワーク・インターフェースと、ブロックチェーンに関連する一意のチャネル名を特定するブロックチェーン・チャネル識別情報を特定すること、ブロックチェーン・ピア・ノードのＵＲＩの識別およびブロックチェーンのチャネル名を含むブロックチェーン・ベースのＵＲＩを生成すること、ならびに生成されたブロックチェーン・ベースのＵＲＩをストレージの中の分散型台帳上に格納することのうちの１つ以上をするように構成されたプロセッサとのうちの１つ以上を含むシステムを提供し得る。

別の例示の実施形態は、複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ）を受信するステップと、ブロックチェーンに関連する一意のチャネル名を特定するブロックチェーン・チャネル識別情報を特定するステップと、ブロックチェーン・ピア・ノードのＵＲＩの識別およびブロックチェーンに関連するチャネル名を含むブロックチェーン・ベースのＵＲＩを生成するステップと、生成されたブロックチェーン・ベースのＵＲＩを分散型台帳上に格納するステップとのうちの１つ以上を含む方法を提供し得る。

さらなる例示の実施形態は、プロセッサにより読み取られるとプロセッサに、複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ）を受信することと、ブロックチェーンに関連する一意のチャネル名を特定するブロックチェーン・チャネル識別情報を特定することと、ブロックチェーン・ピア・ノードのＵＲＩの識別およびブロックチェーンに関連するチャネル名を含むブロックチェーン・ベースのＵＲＩを生成することと、生成されたブロックチェーン・ベースのＵＲＩを分散型台帳上に格納することとのうちの１つ以上を実行させる命令を含む非一時的コンピュータ可読媒体を提供し得る。

別の例示の実施形態は、分散型台帳上に格納されたブロックチェーン・ベースの統一リソース・インジケータ（ＵＲＩ）を修正するリクエストを受信するように構成されたネットワーク・インターフェースと、ブロックチェーン・ベースのＵＲＩに対する修正の識別を含むデータ・ブロックを生成すること、およびブロックチェーン・ベースのＵＲＩに対する修正の識別を含む生成されたデータ・ブロックを、分散型台帳上のデータ・ブロックのハッシュ・リンク・チェーンの中に格納することのうちの１つ以上をするように構成されたプロセッサとのうちの１つ以上を含むコンピューティング・システムを提供し得る。

別の例示の実施形態は、分散型台帳上に格納されたブロックチェーン・ベースの統一リソース・インジケータ（ＵＲＩ）を修正するリクエストを受信するステップと、ブロックチェーン・ベースのＵＲＩに対する修正の識別を含むデータ・ブロックを生成するステップと、ブロックチェーン・ベースのＵＲＩに対する修正の識別を含む生成されたデータ・ブロックを、分散型台帳上のデータ・ブロックのハッシュ・リンク・チェーンの中に格納するステップとのうちの１つ以上を含む方法を提供し得る。

以下、添付の図面を参照しながら、単なる例として本発明の実施形態について記載する。

例示の実施形態による、ブロックチェーン通知ボードを実装するブロックチェーン・ネットワークを示す図である。 例示の実施形態による、アセット共有シナリオのためのピア・ノード・ブロックチェーン・アーキテクチャの構成を示す図である。 例示の実施形態による、ピア・ノード・ブロックチェーン構成を示す図である。 例示の実施形態による、許可型ブロックチェーン・ネットワークを示す図である。 例示の実施形態による、ブロックチェーン台帳に新たなブロックが追加されるプロセスを示す図である。 例示の実施形態による、ブロックチェーンのデータ・ブロック構造のコンテンツを示す図である。 例示の実施形態による、ブロックチェーン・リソースを格納するブロックチェーン通知ボードの例を示す図である。 例示の実施形態による、ブロックチェーン・ベースの通知ボードからリソースを読み出す通信プロセスを示す図である。 例示の実施形態による、分散型台帳上にブロックチェーン・ベースの統一リソース・インジケータ（ＵＲＩ）を格納する方法を示す図である。 例示の実施形態による、分散型台帳を介してブロックチェーン・ベースのＵＲＩを修正する方法を示す図である。 例示の実施形態による、ブロックチェーン・リソース情報をブロックチェーン通知ボード上に格納する方法を示す図である。 例示の実施形態による、ブロックチェーン通知ボードにアクセスする方法を示す図である。 例示の実施形態による、リソース・リクエストを実行するためにチェーンコードを再インスタンス化する方法を示す図である。 例示の実施形態による、ブロックチェーンを検証する方法を示す図である。 例示の実施形態による、本願明細書に記載された１つ以上の動作に従いブロックチェーンに対して様々な動作を実行するように構成された、物理的インフラストラクチャを示す図である。 例示の実施形態による、コントラクトの関係者、およびブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された仲介サーバの間の、スマート・コントラクトの構成を示す図である。 例示の実施形態による、コントラクトの関係者、およびブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された仲介サーバの間の、スマート・コントラクトの構成を示す図である。 例示の実施形態による、別の例示のブロックチェーン・ベースのスマート・コントラクト・システムを示す図である。 例示の実施形態のうちの１つ以上をサポートするように構成された例示のコンピュータ・システムを示す図である。

当然のことながら、本願明細書において、全般的に記載され図面に示されている当該のコンポーネントは、幅広い種々の構成で配置および設計され得る。よって、添付の図面に表されている、方法、装置、非一時的コンピュータ可読媒体、およびシステムのうちの少なくとも１つの実施形態についての以下の詳細な記載は、特許請求される本願の範囲を限定することを意図したものではなく、選択された実施形態を代表するにすぎない。

本明細書の全体にわたって記載される当該の機能、構造、または特徴は、１つ以上の実施形態において任意の適切な様式で組み合わせることができる。例として、語句「例示の実施形態」、「一部の実施形態」、またはその他類似の文言の使用は、本明細書の全体にわたって、実施形態に関連して記載された特定の機能、構造、または特徴が少なくとも１つの実施形態に含まれることを示す。よって、語句「例示の実施形態」、「一部の実施形態において」、「他の実施形態において」、またはその他類似の文言の出現は、本明細書の全体にわたって、すべてが必ずしも同じ実施形態のグループを参照するとは限らず、記載された機能、構造、または特徴は、１つ以上の実施形態において任意の適切な様式で組み合わせることができる。

さらに、用語「メッセージ」が実施形態の記載の中で使用されていることがあるが、その用途はパケット、フレーム、データグラムなど多数のタイプのネットワーク・データに応用されてもよい。用語「メッセージ」は、パケット、フレーム、データグラム、およびその任意の等価物も含む。さらに、特定のタイプのメッセージおよびシグナリングが例示的な実施形態において示されることがあるが、それらは特定のタイプのメッセージに限定されず、用途は特定のタイプのシグナリングに限定されない。

例示の実施形態は、ピア・ノードまたはその他エンティティの統一リソース・インジケータ（ＵＲＩ）、ジェネシス情報、タイミング情報（日付、時刻など）、チェーンコード情報、および同様のものなどのブロックチェーン・リソースを格納するブロックチェーン台帳の中の通知ボード（例えば告知板、掲示板など）を提供する、方法、システム、非一時的コンピュータ可読媒体、デバイス、もしくはネットワーク、またはそのいずれかの組み合わせを提供する。一部の実施形態において、ブロックチェーン・リソースは、新たに定義されたブロックチェーン・ベースのＵＲＩに従ってフォーマットされてもよく、これは本願明細書でＢＵＲＩ（ｂｌｏｃｋｃｈａｉｎ－ｂａｓｅｄ ＵＲＩ：ブロックチェーン・ベースのＵＲＩ）と呼ばれる。

非集中的データベースは、相互通信する複数のノードを含む分散型ストレージ・システムである。ブロックチェーンは、相互に信頼されていない関係者間でレコードを維持できる分散型台帳に似た、追加のみ可能で変更不可能なデータ構造を含む非集中的データベースの例である。信頼されていない関係者を、本願明細書ではピアまたはピア・ノードと呼ぶ。各ピアは、データベース・レコードのコピーを維持し、分散したピア間でコンセンサスに達しなければ、いずれの単一のピアもデータベース・レコードを修正できない。例として、ピアは、コンセンサス・プロトコルを実行してブロックチェーン・ストレージ・トランザクションを検証し、ストレージ・トランザクションをブロックへとグループ化し、複数ブロックのハッシュ・チェーンを構築してもよい。このプロセスは、一貫性のために必要に応じストレージ・トランザクションを順序付けすることにより台帳を形成する。パブリックまたは自由参加型のブロックチェーンでは、誰でも特定のアイデンティティなしで参加できる。パブリック・ブロックチェーンは、多くの場合、ネイティブ暗号通貨を伴い、プルーフ・オブ・ワーク（ＰｏＷ：ｐｒｏｏｆ ｏｆ ｗｏｒｋ）に基づくコンセンサスを使用する。他方、許可型ブロックチェーン・データベースは、資金、商品、情報、および同様のものを交換する企業など、共通の目的を共有するが互いを完全には信頼していないエンティティのグループの中での相互作用をセキュアにすることができるシステムを提供する。

ブロックチェーンは、非集中的ストレージ・スキームに適合する、「スマート・コントラクト」または「チェーンコード」と呼ばれる任意プログラマブル論理を動作させる。一部の事例において、システム・チェーンコードと呼ばれる、管理機能およびパラメータのための特殊なチェーンコードが存在することもある。スマート・コントラクトは、ブロックチェーン・データベースの改ざん防止特性と、エンドースメントまたはエンドースメント・ポリシーと呼ばれるノード間の基礎的な合意とを活用する、信頼された分散型アプリケーションである。概して、ブロックチェーン・トランザクションは、ブロックチェーンにコミットされる前に典型的には「エンドース」されなければならず、エンドースされないトランザクションは無視される。典型的なエンドースメント・ポリシーでは、チェーンコードが、エンドースメントに必須のピア・ノードのセットの形でトランザクションのためのエンドーサを指定できる。クライアントが、エンドースメント・ポリシーにおいて指定されたピアにトランザクションを送信すると、トランザクションを検証するためにトランザクションが実行される。検証後、トランザクションは順序付け段階に入り、コンセンサス・プロトコルが使用されて、ブロックへとグループ化されたエンドース済みのトランザクションの順序付けされたシーケンスがもたらされる。

ノードとは、ブロックチェーン・システムの通信エンティティである。「ノード」は、異なるタイプの複数のノードが同じ物理的サーバ上で実行され得るという意味で、論理機能を実行し得る。ノードは、信頼できるドメイン内でグループ化され、様々な形でそれらのノードを制御する論理エンティティに関連する。ノードには、トランザクション呼び出しをエンドーサ（例えばピア）にサブミットし、トランザクション提案を順序付けサービス（例えば順序付けノード）にブローキャストするクライアントまたはサブミット・クライアント・ノードなど、様々なタイプが含まれ得る。別のタイプのノードは、クライアントがサブミットしたトランザクションを受信し、トランザクションをコミットし、ブロックチェーン・トランザクションの台帳の状態およびコピーを維持することができるピア・ノードである。ピアはエンドーサの役割を持つこともできるが、これは必要条件ではない。順序付けサービス・ノードまたはオーダラは、すべてのノードのために通信サービスを実行するノードであり、トランザクションをコミットするとき、およびブロックチェーンのワールド状態を修正するときの、システム内のそれぞれのピア・ノードへのブロードキャストなどの配信保証を実装し、ワールド状態は、通常は制御情報および設定情報を含む初期ブロックチェーン・トランザクションの別の名前である。

台帳は、ブロックチェーンのすべての状態遷移の、配列された改ざん防止機能付きのレコードである。状態遷移は、参加している関係者（例えばクライアント・ノード、順序付けノード、エンドーサ・ノード、ピア・ノードなど）によってサブミットされたチェーンコード呼び出し（すなわちトランザクション）から生じ得る。トランザクションは、作成、更新、削除、および同様のものなどの１つ以上のオペランドとして台帳にコミットされるアセットのキーと値のペアのセットをもたらし得る。台帳は、配列された変更不可能なレコードをブロックに格納するために使用されるブロックチェーン（チェーンとも呼ばれる）を含む。台帳は、ブロックチェーンの現在の状態を維持する状態データベースも含む。通常は、チャネルごとに１つの台帳がある。各ピア・ノードは、それらがメンバーになっている各チャネルに対して台帳のコピーを維持する。

チェーンとは、ハッシュ・リンク・ブロックとして構造化されたトランザクション・ログであり、各ブロックはＮ個のトランザクションのシーケンスを含み、Ｎは１以上である。ブロック・ヘッダは、ブロックのトランザクションのハッシュ、および前のブロックのヘッダのハッシュを含む。このようにして、台帳に対するすべてのトランザクションが配列され、暗号で互いにリンクされ得る。したがって、ハッシュ・リンクを壊さずに台帳データを改ざんすることはできない。最も最近追加されたブロックチェーンのブロックのハッシュは、それ以前に発生したチェーンに対するすべてのトランザクションを表し、すべてのピア・ノードが一貫し、信頼された状態にあることを保証できるようになっている。チェーンは、ブロックチェーン・ワークロードの追加のみ可能な性質を効率的にサポートするピア・ノードのファイル・システム（すなわちローカル、接続型ストレージ、クラウドなど）に格納され得る。

変更不可能な台帳の現在の状態は、チェーン・トランザクション・ログに含まれるすべてのキーの最新の値を表す。現在の状態は、チャネルに知られている最新のキーの値を表すため、ワールド状態と呼ばれることもある。チェーンコード呼び出しは、台帳の現在の状態のデータに対してトランザクションを実行する。このようなチェーンコードの相互作用を効率的にするために、キーの最新の値が状態データベースに格納され得る。状態データベースは、単にチェーンのトランザクション・ログへのインデックス付きビューとすることもでき、したがって、いつでもチェーンから再生成できる。状態データベースは、ピア・ノードの起動時、トランザクションが受け取られる前に自動的に回復（必要な場合は生成）され得る。

本願は、ブロックチェーンを保持する分散型台帳上にブロックチェーン・リソースを格納することに関する。特に本願は、ブロックチェーン・ピア・ノード・リソースの情報の追加、修正、削除、および同様のことが可能な通知ボードを分散型台帳を介して実装する。通知ボードは、ブロックチェーンのピア・ノード間で複製されてもよい。本願明細書に記載された解決策の利点の一部として、変更不可能な台帳の中にブロックチェーンの各ピア・ノードのブロックチェーン・ベースのＵＲＩ（ＢＵＲＩ）を格納することによる、ブロックチェーン・ネットワークの信頼の向上が挙げられる。本願明細書における例は、リソース参照システムを改良する。

関連するＵＲＩベースのリソース参照メカニズムでは、ＵＲＩによりポイントされるリソースが、変更または削除されることがある。もう１つの問題として、ＵＲＩは、リソース・サーバがダウンしている場合、またはリソースが他のサーバに移動された場合に、ダングリング参照となり得る。例示の実施形態により説明されるＢＵＲＩベースのリソース参照メカニズムでは、メカニズムがブロックチェーンの分散型台帳を使用してリソースおよびリソースを参照するためのブロックチェーン・ベースのＵＲＩ（ブロックチェーンの各ピア・ノードに格納されたリソースを特定できる）を格納するので、ＢＵＲＩによりポイントされるリソースは変更されない。例として、ＢＵＲＩは、ブロックチェーンを特定するジェネシス情報（例えば一意のストリングなど）、ピアＵＲＩ、ブロックチェーン・チャネルＩＤ、チェーンコードＩＤ、チェーンコード・バージョン、ＢＵＲＩが通知ボードに追加された時刻、および同様のものを含んでもよい。各ピア・ノードが、それ自体のＢＵＲＩを有してもよい。

一般に、ブロックチェーンの各ピア・ノードは、その台帳上に同じコンテンツ・データを有する。したがって、ブロックチェーンのメンバーである各ピア・ノードがコンテンツにアクセスできる。例示の実施形態において、ブロックチェーンのピア・ノードのすべてのＵＲＩが、それぞれのピア・ノードの通知ボードの中にセットとして格納され得る。一部の実施形態において、通知ボードは、ワールド状態データベース（状態データベースとも呼ばれる）の中に生成および実装されてもよい。これは、リソース参照ネットワーク・システムの信頼を向上させることができ、ダングリング参照の問題を防ぐことができる。ＢＵＲＩは、すべてのピア・ノードに対して構築され、格納されてもよく、あらゆるピア・ノードにおいて格納されて、信頼できて一貫性があり、サーバ移行に対して堅固なリソース参照システムの構築を可能にし得る。システムはさらに、システムが所与のＢＵＲＩのリソースを決定的な形で返すという意味で、決定的とされ得る。すべてのピア・ノードがダウンしているか、または改ざんされている場合は別であるが、ブロックチェーンにおいては、そのような場合が発生する可能性は比較的低い。したがって、一般に、ブロックチェーンにおいて実行されるすべてのスマート・コントラクト（またはチェーンコード）は決定的でなければならないので、ＢＵＲＩベースのリソース参照システムは、他のブロックチェーンのチェーンコードから呼び出されることが可能である。

ブロックチェーンが従来のデータベースと異なるのは、ブロックチェーンが中央ストレージではなくむしろ非集中的、変更不可能、かつセキュアなストレージであり、ノードがストレージ内のレコードに対する変更を共有しなければならないという点にある。ブロックチェーンに内在し、ブロックチェーンの実装に役立つ一部の特性としては、変更不可能な台帳、スマート・コントラクト、セキュリティ、プライバシー、非集中、コンセンサス、エンドースメント、アクセス可能性、および同様のものが挙げられるが、これらに限定はされず、これらについては本願明細書にさらに記載される。様々な側面によれば、ＢＵＲＩを格納する通知ボードは、ブロックチェーンの変更不可能性、スマート・コントラクト、プライバシー、および非集中的かつ分散型の特性を含む、ブロックチェーンの様々な特性により実装される。通知ボードは、ブロックチェーンも格納する分散型台帳上に格納されてもよいが、通知ボードは、ブロックチェーンとは独立して格納されてもよい。

分散型台帳は、変更不可能であるので、特定の時点にキーに格納されたＢＵＲＩコンテンツを読み出すことができる。さらに、ブロックチェーン内のすべてのデータは高い説明可能性を有するので、通知ボードのあらゆるデータは説明可能なデータである。例として、各情報を誰がポストしたのかをチェックすることができる。スマート・コントラクトは、データをポストするため、データを修正（追加、削除、ＢＵＲＩを変更など）するため、およびデータを読み出すために、通知ボードと相互作用するべく使用され得る。一般に、ブロックチェーンに格納されるデータはバイト・データである。スマート・コントラクトは、参照されるバイト・データのエンコードおよびポストされたバイト・データのデコードを担当する必要がある。同じバイト・データが参照される場合でも、実際に参照されて読み出される値は、データ読み出しのためのスマート・コントラクトが変化するのに伴い変化し得る。したがって、ＢＵＲＩは、通知ボードにアクセスするために使用されるチェーンコードのチェーンコード・バージョン（スマート・コントラクト・バージョン）についての情報を含む。通知ボードを通して、ポストされた情報に誰がアクセスするかを制限することも可能である。通知ボードおよびＢＵＲＩリソースは、各分散型ピア・ノードに格納され、各ピア・ノードは、リソースの証人となることができる。したがって、信頼を構築するため、または堅固な通知ボードを構築するために、集中的なデータ格納ノードは不要である。一部の事例において、情報が通知ボードにポストされる前に、情報は、指定されたピア・ノードによりチェックされることが可能である。このチェックは、ブロックチェーンのコンセンサスにより実装できる。ハイパーレッジャー・ファブリックでは、情報をポストすることの、スマート・コントラクトに関するエンドースメント・ポリシーを使用して、コンセンサスが実装される。

例示の実施形態は、ブロックチェーンに特有である。言い換えれば、集中的データベースでは１つのエンティティがデータベースに追加および格納されるソフトウェアに対する制御権を有するので、例示の実施形態は集中的データベースを介して実行することはできない。対照的に、ブロックチェーンは非集中的であり、中央機関を有しない。したがって、信頼および説明可能性を保証するために追加の方策が実装されなければならない。従来のブロックチェーンの欠点の１つは、使用されているチェーンコードが正確であるという確証も、ブロックチェーン・ネットワーク・アドレスが正確であるという確証も持てないことである。本願明細書に記載されるＢＵＲＩは、たとえネットワーク・アドレス、チェーンコードＩＤ、チェーンコード・バージョン、および同様のものが変化しても、ブロックチェーンがブロックチェーン台帳上の一意のリソースを指定できるようにする。

図１は、例示の実施形態による、ブロックチェーン通知ボードを実装するブロックチェーン・ネットワーク１００を示す。図１を参照する。ブロックチェーン・ネットワーク１００は、ネットワーク１４０を通して相互に接続された複数のピア・ノード１２０～１２３および順序付けノード１３０を含む。複数のピア・ノード１２０～１２３は、ブロックチェーンおよびワールド状態データベースを含む分散型台帳を格納する。各ピア・ノード１２０～１２３は、クライアントからデータを受信し、（例えばブロックチェーンのデータに対する読み取り、書き込み、修正、削除などのため）トランザクションを提案してもよい。ここで、順序付けノード１３０は、トランザクションをブロックへと順序付けして、各ピア・ノード１２０～１２３に格納されたブロックチェーン上での格納のためにそれぞれのピア・ノード１２０～１２３にブロックを送信し得る。このようにして、各ピア・ノード１２０～１２３がブロックチェーンの同じコピーを有するべきである。

様々な実施形態によれば、それぞれのピア・ノード１２０～１２３は、ブロックチェーン通知ボード（ＢＣＮＢ：ｂｌｏｃｋｃｈａｉｎ ｎｏｔｉｆｉｃａｔｉｏｎ ｂｏａｒｄ）とも呼ばれる通知ボード１２０Ａ～１２３Ａを含んでもよい。各ＢＣＮＢは、ブロックチェーンに関連するブロックチェーン・リソース情報を格納できる。例として、通知ボード１２０Ａ～１２３Ａは、ブロックチェーンも含む分散型台帳上に格納されてもよい。一例において、通知ボード１２０Ａ～１２３Ａは、ワールド状態データベースの中に実装されてもよいが、実施形態はそれに限定されない。通知ボードは、ピア・ノードＵＲＩ、ジェネシス情報、チャネル情報、チェーンコード情報、時刻情報、および同様のものなどの情報が格納される掲示板として機能してもよい。さらに、通知ボード１２０Ａ～１２３Ａのコンテンツに対して加えられる任意の変更が、ブロックチェーンのデータ・ブロックの中に格納されることが可能であり、それにより、時間が経つにつれて、ブロックチェーン・リソースに対する変更の変更不可能なレコードが提供される。

ブロックチェーンに対してトランザクションをするために、クライアント１１０は、ブロックチェーン・ピア・ノード１２０～１２３のいずれかにアクセスしてもよい。例として、クライアント１１０がブロックチェーンに登録するか、またはその他の形で情報をリクエストすると、初めにクライアントに、参加しているブロックチェーン・ピア・ノードのＢＵＲＩのリストが提供されてもよい。ブロックチェーンから現在のブロックチェーン・ピア・ノード情報を読み出すために、クライアント１１０は、ブロックチェーン・ベースのＵＲＩ（ＢＵＲＩ）リクエストをブロックチェーン・ピア・ノードにサブミットしてもよい。この例では、クライアント１１０は、ＢＵＲＩリクエストをブロックチェーン・ピア・ノード１２２にサブミットする。それに応答して、ピア・ノード１２２は、通知ボード１２２Ａにアクセスして、ブロックチェーン・ピアの現在のリストまたはセット（およびそれらのネットワーク位置情報）を読み出してもよい。通知ボード１２２Ａにアクセスするために、ピア・ノード１２２は、通知ボード１２２Ａから情報を読み出すチェーンコードを実行してもよい。ピア・ノード１２２は、通知ボード１２２Ａから読み出されたブロックチェーン・ピア情報（例えば現在のピア・ノードのＢＵＲＩのセット）をクライアント・ノード１１０に提供し、それによって、クライアント・ノード１１０がブロックチェーンのメンバーである現在のブロックチェーン・ピア（例えばピア・ノード１２０～１２３）と相互作用できるようにしてもよい。

各ピア・ノード１２０～１２３は、フロント・エンド・システムとして通知ボード・アプリケーション／システムを有してもよい。通知ボード・アプリケーションは、ＲＥＳＴアクセスを通してＢＵＲＩを受信することができる。通知ボード・システムにおいて、ＢＵＲＩを受信した後、分散型台帳上に格納された通知ボードからデータを読み出すためにスマート・コントラクト（チェーンコード）が実行される。ブロックチェーン・ベースの通知ボード・ネットワーク１００に参加している各ピア・ノード１２０～１２３は、ネットワークに参加しているすべてのピア・ノードのＢＵＲＩのセットを提供する機能性を有してもよい。各ピア・ノードは、他のピア・ノードがまだネットワークに参加していることを定期的にチェックしてもよい。ピア・ノードの変更が検出されると（例えばピアの除去、ピアの追加、ピアのＵＲＩの変更など）、変更情報が１つ以上のピア・ノードにより検出されて、通知ボード・ネットワーク１００に参加している他のピア・ノードに通知されてもよい。通知が届いた後、各ピア・ノードは、変更に基づき、参加しているピア・ノードのＢＵＲＩのセットを更新する。各ピア・ノードは、情報を通知ボード・ジェネシスＣＡ（ＮＢＣＡ：ｎｏｔｉｃｅ－ｂｏａｒｄ－ｇｅｎｅｓｉｓ－ＣＡ）にレポートしてもよい。

一方、各クライアント・アプリケーション（例えばクライアント１１０）は、通知ボード・ネットワーク１００に加わっている一部のピア・ノードのＵＲＩのセットを有することができる。クライアント・アプリケーションはさらに、オフチェーン・ストレージおよび同様のものなど、参照されるリソースのＢＵＲＩのセットを格納することができる。クライアント・アプリケーションは、ピア・ノードの機能を呼び出すことにより、有効なピアＵＲＩを定期的に自動で更新することができ、この機能は、参加しているピア・ノードのＵＲＩを含むＢＵＲＩのセットを返す。

ＢＵＲＩは、たとえリソースの変更を表示／格納するスマート・コントラクト（チェーンコード）の時刻およびバージョンが後に変更された場合でも、システムがブロックチェーン上の一意のリソースを指定できるようにする。ブロックチェーン・ピア・ノードがＢＵＲＩリクエストを受信すると、ブロックチェーン・ピア・ノードは、ＢＵＲＩが生成された時に使用されたピア・ノードのチェーンコードＩＤおよびチェーンコード・バージョンを特定してもよい。したがって、ピア・ノードは、ＢＵＲＩが生成された時のチェーンコード・バージョンを再インスタンス化して、ＢＵＲＩリクエストを実行し、通知ボードにアクセスしてもよい。さらに、ピア・ノードはさらに、ＢＵＲＩの時点で以前格納された値により、実行中にチェーンコードにより読み取られる読み取りセットのキーの値を置き換えてもよい。したがって、チェーンコードの後のバージョンが望まれない形で追加または操作されることからの不正またはエラーを防止できる。従来のブロックチェーンでは、システムは、ブロックチェーン・システムに格納されたリソースを参照するために、チェーンコードの時刻値またはバージョンを使用することができない。

例示の実施形態において、ブロックチェーンのそれぞれのピア・ノードが、個別の通知ボードを介して、すべてのピア・ノードのピアＵＲＩ情報を格納してもよい。各ピア・ノードはさらに、同じ情報を含むピア・ノードのＢＵＲＩをクライアント・アプリケーションに提供する能力も有してもよい。これは、クライアント・アプリケーションが、有効な情報を参照するように有効なＢＵＲＩを自動的に更新して、ダングリング参照を回避できるようにする。従来のブロックチェーンには、通常、通知ボードのコンテンツを参照するために、識別子を更新する情報をクライアント・アプリケーションに提供する機能がない。結果として、クライアント・アプリケーションは、そのような情報を自ら管理しなければならない。

スマート・コントラクト機能性（および順序を表すＲＥＳＴウェブ・ベースのシステム）を備えた従来のブロックチェーンは、通常、状態ＤＢ（またはワールド状態ＤＢ）を有し、これはブロックチェーンのキーの値の最新コンテンツを格納する。例として、状態ＤＢがキーの値のストアである場合、各キーの各値は、時間が経つにつれて更新および変更されることが可能である。したがって、所与のキーのリソースの値は、時間によって変更される可能性がある。これは、順序を表す識別子（例えばＵＲＩ）により特定される値が、時間が経つにつれて変更され得ることを意味する。ここで、ＢＵＲＩの中の「時刻」変数は、識別子（ＢＵＲＩ）が、時間が経つにつれて一意のリソースを特定することを可能にする。順序を表すブロックチェーンは、一連のトランザクション・データ（ブロックチェーン・データ）を有し、これは通常、状態ＤＢの各キーの読み取り・書き込みセット、およびトランザクション開始時刻を有する。したがって、例示の実施形態は、ＢＵＲＩ（時刻情報を含む）を使用して、ＢＵＲＩにおける所与の時点それぞれでの、各キーの値を得ることができる。例として、ピア・ノードは、状態データベースに格納された現在の値を実行するのではなく、ＢＵＲＩに含まれるタイミング情報に基づき以前のキーの値に置き換え、それにより、チェーンコードの実行が正しいデータに対して実行されることを保証することができる。

図２Ａは、例示の実施形態によるブロックチェーン・アーキテクチャの構成２００を示す。図２Ａを参照する。ブロックチェーン・アーキテクチャ２００は、特定のブロックチェーン構成要素、例としてブロックチェーン・ノード２０２のグループを含んでもよい。ブロックチェーン・ノード２０２は、１つ以上のノード２０４～２１０を含んでもよい（これら４つのノードは例としてのみ示されている）。これらのノードは、ブロックチェーン・トランザクションの追加および検証プロセス（コンセンサス）など、いくつかのアクティビティに参加する。ブロックチェーン・ノード２０４～２１０の１つ以上は、エンドースメント・ポリシーに基づきトランザクションをエンドースしてもよく、アーキテクチャ２００の中のすべてのブロックチェーン・ノードに対して順序付けサービスを提供してもよい。ブロックチェーン・ノードは、ブロックチェーン認証を開始して、ブロックチェーン・レイヤ２１６に格納されたブロックチェーンの変更不可能な台帳への書き込みをしようとすることができ、そのコピーは、基盤となる物理的インフラストラクチャ２１４にも格納されてもよい。ブロックチェーンの構成は、格納されたプログラム／アプリケーション・コード２２０（例えばチェーンコード、スマート・コントラクトなど）にアクセスして実行するためのアプリケーション・プログラミング・インターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅｓ）２２２にリンクされた１つ以上のアプリケーション２２４を含んでもよく、プログラム／アプリケーション・コード２２０は、参加者によって求められるカスタマイズされた構成に従って作成でき、それら自体の状態を維持し、それら自体のアセットを制御し、外部情報を受信することができる。これは、すべてのブロックチェーン・ノード２０４～２１０上で、分散型台帳に追加することによって、トランザクションとしてデプロイし、インストールすることができる。

ブロックチェーン・ベースまたはプラットフォーム２１２は、新たなトランザクションの受信および格納、ならびにデータ・エントリにアクセスしようとしている監査人へのアクセス提供のために使用され得る、ブロックチェーン・データ、サービス（例えば暗号信用サービス、仮想実行環境など）、および基盤となる物理的コンピュータ・インフラストラクチャの様々なレイヤを含んでもよい。ブロックチェーン・レイヤ２１６は、プログラム・コードを処理して物理的インフラストラクチャ２１４を使うために必要な仮想実行環境へのアクセスを提供するインターフェースを公開してもよい。暗号信用サービス２１８は、アセット交換トランザクションなどのトランザクションを確認し、情報をプライベートに保つために使用されてもよい。

図２Ａのブロックチェーン・アーキテクチャの構成は、ブロックチェーン・プラットフォーム２１２によって公開される１つ以上のインターフェースおよび提供されるサービスを介して、プログラム／アプリケーション・コード２２０を処理および実行してもよい。コード２２０は、ブロックチェーンのアセットを制御してもよい。例として、コード２２０は、データを格納および転送することができ、スマート・コントラクトおよび条件を伴う関連するチェーンコードまたはその実行の対象になる他のコード要素の形態で、ノード２０４～２１０によって実行されてもよい。非限定的な例として、スマート・コントラクトは、リマインダ、更新、もしくはその他変更、更新などの対象となる通知、またはそのいずれかの組み合わせを実行するために作成されてもよい。スマート・コントラクト自体を、権限付与およびアクセスの要件ならびに台帳の使用に関連するルールを特定するために使用することができる。例として、読み取りセット２２６は、ブロックチェーン・レイヤ２１６に含まれる１つ以上の処理エンティティ（例えば仮想マシン）により処理されてもよい。書き込みセット２２８は、キーの値に対する変更を含んでもよい。物理的インフラストラクチャ２１４は、本願明細書に記載されたデータまたは情報のいずれかを読み出すために利用されてもよい。

チェーンコードの中に、高水準のアプリケーションおよびプログラミング言語によりスマート・コントラクトが作成され、その後、ブロックチェーン内のブロックに書き込まれてもよい。スマート・コントラクトは、ブロックチェーン（例えばブロックチェーン・ピアの分散型ネットワーク）を用いて登録、格納、もしくは複製、またはそのいずれかの組み合わせをされる実行可能コードを含んでもよい。トランザクションは、スマート・コントラクトに関連する条件が満足されることに応答して実行可能な、スマート・コントラクト・コードの実行である。スマート・コントラクトの実行は、デジタル・ブロックチェーン台帳の状態に対する信頼される修正（単数または複数）をトリガしてもよい。スマート・コントラクトの実行によって生じたブロックチェーン台帳に対する修正（単数または複数）は、１つ以上のコンセンサス・プロトコルを通してブロックチェーン・ピアの分散型ネットワーク全体に自動的に複製されてもよい。

スマート・コントラクトは、データをキーと値のペアの形式でブロックチェーンに書き込んでもよい。さらにスマート・コントラクト・コードは、ブロックチェーンに格納された値を読み取り、それらをアプリケーションの動作において使用することができる。スマート・コントラクト・コードは、様々な論理演算の出力をブロックチェーンに書き込むことができる。コードは、仮想マシンまたはその他コンピューティング・プラットフォーム内の一時的データ構造を作成するために使用されてもよい。ブロックチェーンに書き込まれるデータは、パブリックとされること、もしくは暗号化されてプライベートとして維持されること、またはその両方が可能である。スマート・コントラクトによって使用／生成される一時的データは、提供される実行環境によってメモリ内に保持され、その後、ブロックチェーンに必要なデータが特定されると削除される。

チェーンコードは、追加機能とともに、スマート・コントラクトのコード解釈を含んでもよい。本明細書に記載されているように、チェーンコードは、コンピューティング・ネットワーク上にデプロイされるプログラム・コードとすることができ、コードはコンセンサス・プロセス中にチェーン・バリデータによって一緒に実行され、検証される。チェーンコードは、ハッシュを受信し、以前に格納された特徴の抽出器を使用することで作成されたデータ・テンプレートに関連するハッシュをブロックチェーンから読み出す。ハッシュ識別子のハッシュと、格納された識別子テンプレート・データから作成されたハッシュとが一致すれば、チェーンコードは、権限付与キーを、リクエストされたサービスに送信する。チェーンコードは、暗号の詳細に関連するデータをブロックチェーンに書き込んでもよい。

図２Ｂは、例示の実施形態に従った、ブロックチェーンのノード間のトランザクション・フロー２５０の例を示す。図２Ｂを参照する。トランザクション・フローは、アプリケーション・クライアント・ノード２６０によってエンドース・ピア・ノード２８１に送信されるトランザクション提案２９１を含んでもよい。エンドース・ピア２８１は、クライアントの署名を確認し、チェーンコード関数を実行してトランザクションを開始してもよい。出力は、チェーンコードの結果、チェーンコードにおいて読み取られたキー／値のバージョンのセット（読み取りセット）、およびチェーンコードにおいて書き込まれたキー／値のセット（書き込みセット）を含んでもよい。提案応答２９２が、承認される場合はエンドースメント署名とともに、クライアント２６０に返送される。クライアント２６０は、エンドースメントをトランザクションのペイロード２９３にまとめて、順序付けサービス・ノード２８４にブロードキャストする。次に順序付けサービス・ノード２８４は、順序付けしたトランザクションをブロックとしてチャネル上のすべてのピア２８１～２８３に配信する。ブロックチェーンへのコミットの前に、各ピア２８１～２８３はトランザクションを検証してもよい。例としてピアは、指定されたピアの正しい割り当てが結果に署名し、トランザクションのペイロード２９３に対する署名を認証したことを保証するために、エンドースメント・ポリシーをチェックしてもよい。

クライアント・ノード２６０は、リクエストを構築してエンドーサであるピア・ノード２８１に送信することによって、トランザクション２９１を開始してもよい。エンドーサは複数であってもよいが、便宜上ここでは１つ示す。クライアント２６０は、ＮＯＤＥ、ＪＡＶＡ（Ｒ）、ＰＹＴＨＯＮ、および同様のものなどのサポートされているソフトウェア開発キット（ＳＤＫ：ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）を利用するアプリケーションを含んでもよく、このアプリケーションは、利用可能なＡＰＩを利用してトランザクション提案を生成する。トランザクション提案２９１は、台帳に対してデータの読み取りもしくは書き込み（すなわちアセットの新しいキーと値のペアを書き込むこと）、またはその両方をできるように、チェーンコード関数を呼び出すためのリクエストである。ＳＤＫは、トランザクション提案を、適切に設計された形式にパッケージ化するためのシムとして機能し（例えば遠隔手続呼び出し（ＲＰＣ：ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ）を経由するプロトコル・バッファ）、クライアントの暗号認証情報を得て、トランザクション提案のための一意の署名をもたらしてもよい。

それに応答して、エンドース・ピア・ノード２８１は、（ａ）トランザクション提案が適切に形成されていること、（ｂ）トランザクションが過去にすでにサブミットされていないこと（リプレイ・アタック保護）、（ｃ）署名が有効であること、および（ｄ）そのチャネルに対する提案された動作を実行するための適切な権限がサブミッタ（本例ではクライアント２６０）に付与されていることを確認してもよい。エンドース・ピア・ノード２８１は、トランザクション提案の入力を、呼び出されるチェーンコード関数への引数として得てもよい。次に、チェーンコードが現在の状態データベースに対して実行され、応答値、読み取りセット、および書き込みセットを含むトランザクション結果がもたらされる。ただしこの時点では、台帳に対する更新は行われない。２９２において、値のセットがエンドース・ピア・ノード２８１の署名とともに提案応答２９２としてクライアント２６０のＳＤＫに返され、ＳＤＫが、アプリケーションが使用するためのペイロードを構文解析する。

それに応答して、クライアント２６０のアプリケーションが、エンドース・ピアの署名を検査／確認し、提案応答を比較して、提案応答が同じであるかどうかを判断する。チェーンコードが単に台帳にクエリを行った場合は、アプリケーションはクエリ応答を検査し、通常は、トランザクションを順序付けサービス・ノード２８４にサブミットしないであろう。クライアント・アプリケーションが、台帳を更新するためにトランザクションを順序付けサービス・ノード２８４にサブミットしようとする場合、アプリケーションは、サブミットする前に、指定されたエンドースメント・ポリシーが満たされているかどうか（すなわちトランザクションに必要なすべてのピア・ノードがトランザクションをエンドースしたかどうか）を判断する。ここでクライアントは、トランザクションの複数の関係者のうちの１つのみを含んでもよい。この事例では、各クライアントは、それ自体のエンドース・ノードを有してもよく、各エンドース・ノードがトランザクションをエンドースする必要がある。このアーキテクチャでは、たとえアプリケーションが応答を検査しないことを選択するか、または別の形でエンドースされていないトランザクションを転送する場合でも、エンドースメント・ポリシーがピアによってなお実施され、コミット検証フェーズで確認されるようになっている。

検査に成功した後、ステップ２９３で、クライアント２６０が、エンドースメントをトランザクションにまとめ、順序付けノード２８４へのトランザクション・メッセージの中でトランザクション提案および応答をブロードキャストする。トランザクションは、読み取り／書き込みセット、エンドース・ピアの署名、およびチャネルＩＤを含んでもよい。順序付けノード２８４は、その動作を実行するためにトランザクションのコンテンツ全体を検査する必要はなく、代わりに順序付けノード２８４は、単にトランザクションをネットワーク内のすべてのチャネルから受信して、チャネル別に時系列順に順序付けし、チャネルごとにトランザクションのブロックを作成すればよい。

トランザクションのブロックは、順序付けノード２８４からチャネル上のすべてのピア・ノード２８１～２８３に配信される。任意のエンドースメント・ポリシーが満たされていることを保証するため、および読み取りセットがトランザクションの実行によって生成されて以来、読み取りセットの変数に関して台帳の状態に対する変更がないことを保証するために、ブロックの中のトランザクション２９４が検証される。ブロック内のトランザクションは、有効または無効としてタグ付けされる。さらにステップ２９５で、各ピア・ノード２８１～２８３は、ブロックをチャネルのチェーンに追加し、有効なトランザクションそれぞれについて、書き込みセットが現在の状態データベースにコミットされる。トランザクション（呼び出し）が変更不可能なようにチェーンに追加されたことをクライアント・アプリケーションに通知するため、ならびにトランザクションが有効にされたか、または無効にされたかを通知するために、イベントが発せられる。

図３は、分散型の非集中的ピア・ツー・ピア・アーキテクチャ、ならびにユーザの役割および許可を管理する認証局３１８を特徴とする許可型ブロックチェーン・ネットワーク３００の例を示す。本例では、ブロックチェーン・ユーザ３０２が、トランザクションを許可型ブロックチェーン・ネットワーク３１０にサブミットしてもよい。本例では、トランザクションは、デプロイ、呼び出し、またはクエリとすることができ、ＳＤＫを利用するクライアント側のアプリケーションを通して、またはＲＥＳＴ ＡＰＩを通して直接的に、または同様の形で発行されてもよい。信頼できるビジネス・ネットワークは、監査人（例として米国の株式市場における証券取引委員会）などの規制者システム３１４にアクセスを提供してもよい。一方、ノードのブロックチェーン・ネットワーク運用者システム３０８は、規制者システム３１４を「監査人」として登録し、ブロックチェーン・ユーザ３０２を「クライアント」として登録するなどの、メンバーの許可を管理する。監査人は、台帳のクエリのみに制限できる一方、クライアントには、特定のタイプのチェーンコードのデプロイ、呼び出し、およびクエリを行うための権限を付与できるであろう。

ブロックチェーン開発者システム３１６は、チェーンコードおよびクライアント側アプリケーションを書く。ブロックチェーン開発者システム３１６は、ＲＥＳＴインターフェースを介してチェーンコードをネットワークに直接デプロイすることができる。従来のデータ・ソース３３０からの認証情報をチェーンコードに含めるために、開発者システム３１６は、アウト・オブ・バンド接続を使用してデータにアクセスすることができるであろう。本例では、ブロックチェーン・ユーザ３０２は、ピア・ノード３１２を介してネットワークに接続する。ピア・ノード３１２は、任意のトランザクションを開始する前に、ユーザの登録およびトランザクション証明書を認証局３１８から読み出す。一部の事例において、ブロックチェーン・ユーザは、許可型ブロックチェーン・ネットワーク３１０上でトランザクションを行うために、このようなデジタル証明書を所有していなければならない。一方、チェーンコードを駆動しようとするユーザは、従来のデータ・ソース３３０上の自身の認証情報の確認を行うよう要求されてもよい。ユーザの権限付与を確かめるために、チェーンコードは、従来の処理プラットフォーム３２０を介してこのデータへのアウト・オブ・バンド接続を使用することができる。

図４Ａは、例示の実施形態による、分散型台帳４２０に新たなブロックが追加されるプロセス４００を示し、図４Ｂは、例示の実施形態による、ブロックチェーンのブロック構造４４０のコンテンツを示す。図４Ａを参照する。クライアント（図示せず）は、トランザクションをブロックチェーン・ノード４１１、４１２、もしくは４１３、またはそのいずれかの組み合わせにサブミットしてもよい。クライアントは、ブロックチェーンに対するアクティビティを規定する、任意のソースから受信される命令であってもよい。例として、クライアントは、ブロックチェーンのトランザクションを提案するデバイス、人、またはエンティティなどのリクエスタに代わって動作するアプリケーション（ＳＤＫに基づく）であってもよい。複数のブロックチェーン・ピア（例えばブロックチェーン・ノード４１１、４１２、および４１３）は、ブロックチェーン・ネットワークの状態および分散型台帳４２０のコピーを維持してもよい。

クライアントにより提案されたトランザクションをシミュレーションしてエンドースするエンドース・ピア、エンドースメントの確認、トランザクションの検証、および分散型台帳４２０へのトランザクションのコミットをするコミット・ピアを含む、種々のタイプのブロックチェーン・ノード／ピアが、ブロックチェーン・ネットワークに存在してもよい。本例において、ブロックチェーン・ノード４１１、４１２、および４１３は、エンドーサ・ノード、コミッタ・ノード、または両方の役割を実行してもよい。

分散型台帳４２０は、配列された変更不可能なレコードをブロックに格納するブロックチェーン４３０、およびブロックチェーン４３０の現在の状態（キーの値）を維持する状態データベース４５０（現在のワールド状態）を含む。チャネルごとに１つの分散型台帳４２０が存在してもよく、各ピアは、それがメンバーである各チャネルの分散型台帳４２０の、自己のコピーを維持する。ブロックチェーン４３０は、ハッシュ・リンク・ブロックとして構造化されたトランザクション・ログであり、各ブロックはＮ個のトランザクションのシーケンスを含む。ブロック（例えばブロック４４０）は、図４Ｂに示されているものなど、様々なコンポーネントを含んでもよい。ブロックのリンク（図４Ａでは矢印により示されている）は、前のブロックのヘッダのハッシュを現在のブロックのブロック・ヘッダの中に追加することにより生成されてもよい。このようにして、ブロックチェーン４３０に対するすべてのトランザクションが、配列され、暗号によって互いにリンクされ、ハッシュ・リンクを壊さずにブロックチェーン・データを改ざんすることが防止される。さらに、リンクにより、ブロックチェーン４３０の中の最新ブロックは、それに先行したあらゆるトランザクションを表す。ブロックチェーン４３０は、追加のみ可能なブロックチェーン・ワークロードをサポートするピア・ファイル・システム（ローカルまたは接続型ストレージ）上に格納されてもよい。

ブロックチェーン４３０および分散型台帳４２０の現在の状態は、状態データベース４５０に格納されてもよい。ここで、現在の状態のデータは、ブロックチェーン４３０のチェーン・トランザクション・ログにこれまで含まれたすべてのキーの最新の値を表す。チェーンコード呼び出しは、状態データベース４５０の現在の状態に対してトランザクションを実行する。こうしたチェーンコードの相互作用を極めて効率的にするために、すべてのキーの最新の値が状態データベース４５０に格納されてもよい。状態データベース４５０は、ブロックチェーン４３０のトランザクション・ログへのインデックス付きビューを含んでもよく、したがって、いつでもチェーンから再生成できる。状態データベース４５０は、ピアの起動時、トランザクションが受け取られる前に、自動的に回復（必要な場合は生成）されてもよい。

エンドース・ノードは、クライアントからトランザクションを受信して、シミュレーションされた結果に基づきトランザクションをエンドースする。エンドース・ノードは、トランザクションの提案をシミュレーションするスマート・コントラクトを保持する。トランザクションをエンドースする必要があるノードは、チェーンコードの中で指定され得るエンドースメント・ポリシーによって決まる。エンドースメント・ポリシーの例は、「エンドース・ピアの過半数がトランザクションをエンドースしなければならない」である。異なるチャネルは、異なるエンドースメント・ポリシーを有してもよい。エンドースされたトランザクションは、クライアント・アプリケーションから順序付けサービス４１０に転送される。

順序付けサービス４１０は、エンドースされたトランザクションを受け取り、それらをブロックへと順序付け、ブロックをコミット・ピアに配信する。例として、順序付けサービス４１０は、トランザクションの閾値に達した場合、またはタイマがタイムアウトした場合、または別の条件で、新たなブロックを開始してもよい。図４Ａの例において、ブロックチェーン・ノード４１２は、ブロックチェーン４３０上に格納される新たなデータ・ブロック４４０を受信したコミット・ピアである。

順序付けサービス４１０は、オーダラのクラスタで構成されてもよい。順序付けサービス４１０は、トランザクション、スマート・コントラクトを処理せず、共有台帳を維持しない。代わりに、順序付けサービス４１０は、エンドースされたトランザクションを受け取り、それらのトランザクションが分散型台帳４２０にコミットされる順序を指定してもよい。ブロックチェーン・ネットワークのアーキテクチャは、「順序付け」の特定の実装（例えばＳｏｌｏ、Ｋａｆｋａ、ＢＦＴなど）がプラグイン可能なコンポーネントとなるように設計されてもよい。

トランザクションは、一貫した順序で分散型台帳４２０に書き込まれる。トランザクションの順序は、状態データベース４５０に対する更新がネットワークにコミットされるときに有効であることを保証するように定められる。順序付けが暗号パズルを解くこと、またはマイニングにより発生する暗号通貨ブロックチェーン・システム（例えばビットコインなど）と異なり、本例では、分散型台帳４２０の関係者が、そのネットワークに最もふさわしい順序付けメカニズムを選べばよい。

順序付けサービス４１０が新たなブロック４４０を初期設定すると、新たなブロック４４０は、コミット・ピア（例えばブロックチェーン・ノード４１１、４１２、および４１３）にブロードキャストされてもよい。それに応答して、各コミット・ピアは、読み取りセットおよび書き込みセットがなお状態データベース４５０における現在のワールド状態と一致することを確かめるためのチェックを行うことで、新たなブロック４４０の中のトランザクションを検証する。具体的には、コミット・ピアは、エンドーサがトランザクションをシミュレーションしたときに存在した読み取られたデータが、状態データベース４５０における現在のワールド状態と同一であるかどうかを判断することができる。コミット・ピアがトランザクションを検証すると、トランザクションは分散型台帳４２０上のブロックチェーン４３０に書き込まれ、状態データベース４５０は読み取り・書き込みセットからの書き込みデータを用いて更新される。トランザクションが失敗した場合、つまりコミット・ピアが、読み取り・書き込みセットが状態データベース４５０における現在のワールド状態と一致しないことを発見した場合、ブロックへと順序付けされたトランザクションはなおブロックに含められるが、無効とマークされて状態データベース４５０は更新されない。

図４Ｂを参照する。分散型台帳４２０のブロックチェーン４３０上に格納されているブロック４４０（データ・ブロックとも呼ばれる）は、ブロック・ヘッダ４４２、ブロック・データ４４４、およびブロック・メタデータ４４６などの複数のデータ・セグメントを含んでもよい。当然のことながら、ブロック４４０およびそのコンテンツなど、図４Ｂに示されている様々なブロックおよびそれらのコンテンツは、単に例示を目的としたものであり、例示の実施形態の範囲を限定する意図はない。一部の事例において、ブロック・ヘッダ４４２およびブロック・メタデータ４４６はどちらも、トランザクション・データを格納するブロック・データ４４４よりも小さくてもよいが、これは必須条件ではない。ブロック４４０は、ブロック・データ４４４の中にＮ個のトランザクション（例えば１００、５００、１０００、２０００、３０００など）のトランザクション情報を格納してもよい。ブロック４４０はさらに、ブロック・ヘッダ４４２の中に（例えば図４Ａのブロックチェーン４３０上の）以前のブロックへのリンクを含んでもよい。具体的には、ブロック・ヘッダ４４２は、以前のブロックのヘッダのハッシュを含んでもよい。ブロック・ヘッダ４４２はさらに、一意のブロック番号、現在のブロック４４０のブロック・データ４４４のハッシュ、および同様のものを含んでもよい。ブロック４４０のブロック番号は、一意であり、ゼロから始まる昇順／連番で付与されてもよい。ブロックチェーンの中の第１のブロックは、ジェネシス・ブロックと呼ばれることもあり、ブロックチェーン、そのメンバー、その中に格納されたデータなどについての情報を含む。

ブロック・データ４４４は、ブロック４４０の中に記録されている各トランザクションのトランザクション情報を格納してもよい。例として、ブロック・データ４４４の中に格納されたトランザクション・データは、トランザクションのタイプ、バージョン、タイムスタンプ、分散型台帳４２０のチャネルＩＤ、トランザクションＩＤ、エポック、ペイロードの可視性、チェーンコード・パス（デプロイｔｘ）、チェーンコード名、チェーンコード・バージョン、入力（チェーンコードおよび関数）、公開鍵および証明書などのクライアント（作成者）アイデンティティ、クライアントの署名、エンドーサのアイデンティティ、エンドーサの署名、提案のハッシュ、チェーンコード・イベント、応答状態、名前空間、読み取りセット（トランザクションにより読み取られたキーおよびバージョンのリストなど）、書き込みセット（キーおよび値のリストなど）、開始キー、終了キー、キーのリスト、マークル・ツリー・クエリ・サマリ、および同様のもののうちの１つ以上を含んでもよい。トランザクション・データは、Ｎ個のトランザクションのそれぞれについて格納されてもよい。

様々な実施形態によれば、ブロック４４０のブロック・データ４４４のセクションはさらに、ブロックチェーン通知ボードに対する修正、更新、削除、追加、またはその他変更についての情報を格納してもよい。例として、ブロック・データ４４４は、ピアＵＲＩに対する変更を特定する修正されたＢＵＲＩ情報４４５および同様のものを格納してもよい。さらに、ＢＵＲＩ情報４４５は、ブロックチェーン・チャネルＩＤ情報、チェーンコード情報、ジェネシス情報、修正のタイミング、および同様のものを含んでもよい。したがって、ＢＵＲＩ情報４４５に対する修正は、ブロックチェーンとは独立して、ただしブロックチェーンと同じ分散型台帳上に格納される通知ボードに加えて、ブロックチェーン（すなわちハッシュ・リンクされたブロックのチェーン）の中に格納されてもよい。

ブロック・メタデータ４４６は、（例えばバイト・アレイなどとして）メタデータの複数のフィールドを格納してもよい。メタデータ・フィールドは、ブロック作成に対する署名、最後の構成ブロックへの参照、ブロックの中の有効および無効なトランザクションを特定するトランザクション・フィルタ、ブロックを順序付けした順序付けサービスの存在した最後のオフセット、および同様のものを含んでもよい。署名、最後の構成ブロック、およびオーダラのメタデータは、順序付けサービス４１０により追加されてもよい。一方、ブロックのコミット・ノード（ブロックチェーン・ノード４１２など）は、エンドースメント・ポリシー、読み取り／書き込みセットの確認、および同様のものに基づく有効性／無効性情報を追加してもよい。トランザクション・フィルタは、ブロック・データ４４４の中のトランザクションの数と等しいサイズのバイト・アレイ、およびトランザクションが有効／無効のいずれであったかを特定する検証コードを含んでもよい。

図４Ｃは、例示の実施形態による、ブロックチェーン・リソースを格納するブロックチェーン通知ボード４５２の例を示す。本例では、ブロックチェーン通知ボード４５２は、図４Ａに示された分散型台帳４２０のワールド状態データベース４５０を介して実装される。ブロックチェーン４３０の現在のメンバーである各ピア・ノードに関する、複数の属性４５４（すなわちリソース）が格納されてもよい。本例では、ピアＡのＢＵＲＩ４５６およびピアＢのＢＵＲＩ４５８を含む２つのＢＵＲＩレコードが示されているが、格納されているＢＵＲＩの数および属性のタイプは単に例示を目的としたものである。

図４Ｃの例では、属性４５４は、ジェネシス情報、ピアＵＲＩ、チャネル名、チェーンコードＩＤ（ＣＣＩＤ：ｃｈａｉｎｃｏｄｅ ＩＤ）、チェーンコード・バージョン（ＣＣＶＥＲ：ｃｈａｉｎｃｏｄｅ ｖｅｒｓｉｏｎ）、チェーンコードに含まれる引数（ＡＲＧＳ：ａｒｇｕｍｅｎｔｓ）、およびＢＵＲＩが通知ボード４５２に追加された時刻を含む。例として、ジェネシス情報は、例えば新たなブロックチェーン・ネットワークを作成した組織またはユーザのＩＤのハッシュ値、作成時刻、作成時の組織システムの地理的位置（経度、緯度など）などの、一意のストリング値を含んでもよい。ジェネシス情報は、ブロックチェーン・ネットワークを指定してもよい。

ピアＵＲＩは、ブロックチェーンの一部であるブロックチェーン・ピア・ノードのネットワーク位置を含む。チャネル名は、ブロックチェーンのチャネル名である。ハイパーレッジャー・ファブリック・ブロックチェーンは、チャネルを有する。異なるチャネルは、異なるデータ・セットを格納する。各ピア・ノードは、複数のチャネルに属することができる。ＣＣＩＤは、チェーンコードＩＤであり、スマート・コントラクトＩＤとも呼ばれる。チェーンコード（スマート・コントラクト）は、一意のＩＤを有する。ＣＣＶＥＲは、時間が経つにつれて更新可能なチェーンコード・バージョンである。ＡＲＧは、チェーンコードの引数を表し、チェーンコードの関数名を含んでもよい。引数は、一連のバイト・データを含んでもよい。時刻は、リソース（例えばＢＵＲＩ）が通知ボード４５２に追加された時点である。通知ボード上のリソースは（ブロックチェーンに基づき）時間が経つにつれて変化する。

図４Ｄは、例示の実施形態による、ブロックチェーン・ベースの通知ボードからリソースを読み出す通信プロセス４８０を示す。図４Ｄを参照する。４８１において、クライアント・アプリケーション４６０が、ピア・ノード４７０のピアＵＲＩを（例えばブロックチェーンの以前に受信されたＢＵＲＩ情報から）選択し、ブロックチェーンのピア・ノードについての情報を求めるＢＵＲＩリクエストをサブミットする。ピアＵＲＩセットは、ブロックチェーン・ベースの通知ボードに参加するピア・ノードのＵＲＩを含む。ここで、クライアント・アプリケーション４６０は、選択されたピアＵＲＩと、参照されるリソースの他の情報とを使用してＢＵＲＩリクエストを構築してもよい。したがって、クライアント・アプリケーション４６０は、４８１のＢＵＲＩリクエストに含まれるピアＵＲＩに基づき、ピア・ノード４７０の通知ボード・システム（通知ボード・アプリケーション４７２、通知ボード・ジェネシス認証局４７４、分散型台帳４７６など）にアクセスできる。選択されたピアＵＲＩのピア・ノードがない場合、クライアント・アプリケーション４６０は、別のピアＵＲＩを選択して、利用可能なピアＵＲＩが発見されるまで繰り返してもよい。しかし、ピア・ノードが機能しているピアＵＲＩがない場合、データ参照は失敗する。

４８１においてリソース・リクエストを受信するのに応答して、通知ボード・アプリケーション４７２は、４８２において、通知ボード・ジェネシスＣＡ（ＮＢＣＡ）にアクセスすることにより、ＢＵＲＩリソース・リクエストに含まれるジェネシス情報が一意かつ有効であることをチェックしてもよく、ＮＢＣＡは、通知ボード・ジェネシス情報を管理し、現在ブロックチェーンに参加しているピア・ノードのピアＵＲＩの各セットを登録する。このチェックのリクエストに応答して、ＮＢＣＡ４７４は、４８３において、登録されたすべてのピア・ノードが参加ピア・ノードの一貫した履歴を有し、ピアＵＲＩが現在のピア・ノード参加者の登録されたセットに含まれることをチェックする。なお、ＮＢＣＡは、データ・コンテンツの証明はしないが、代わりにブロックチェーン上のすべてのピア・ノードのジェネシス情報を証明する。特に、ＮＢＣＡ４７４は、ジェネシス情報が一意であり、ジェネシス情報を含む各ピア・ノードが有効な参加者セット（ピアＵＲＩ）を有することを証明してもよい。成功すれば、４８４においてＮＢＣＡは、真正性の証明を通知ボード・アプリケーション４７２に返す。

それに応答して、４８５～４８７において通知ボード・アプリケーション４７２は、ＢＵＲＩリクエストに含まれたバージョンＣＣＶＥＲのＣＩＤのチェーンコード（スマート・コントラクト）を使用することで、ＢＵＲＩリクエストにより示された時刻の時点でのピア・ノードのチャネルに基づき、通知ボード（すなわち分散型台帳４７６上）に格納されたデータにアクセスしてもよい。この事例では、４８８においてチェーンコードは、ＢＵＲＩリクエストのリソースを、ジェネシス情報についての証明とともに返し、通知ボード・システムは、ブロックチェーン・ベースの通知ボードを含むブロックチェーンの中の、現在参加しているすべてのピア・ノードのピアＵＲＩの最新セットを含むとよいＢＵＲＩのリソースを返す。したがって、クライアント・アプリケーション４６０は、通知システムを介して分散型台帳４７６からブロックチェーン・リソースを読み出し、その内部のピアＵＲＩのセットを、ピアＵＲＩの最新セットを使用して更新することができる。

様々な実施形態によれば、４８５においてピア・ノード４７０の通知ボード・アプリケーション４７２は、ＢＵＲＩリクエスト４８１により示され、ピア・ノード４７０に格納されている、所与のチェーンコードＩＤ（ＣＣＩＤ）およびチェーンコードの所与のバージョン（ＣＣＶＥＲ）に基づき、チェーンコードを再インスタンス化してもよい。一部の実施形態において、ピア・ノードの通知ボード・アプリケーション４７２はさらに、４８１において受信されたＢＵＲＩリクエストに含まれる時刻に基づき、４８６において、再インスタンス化されたチェーンコードの読み取りセットを再計算して、再計算された読み取りセットに置き換えてもよい。本例において、読み取りセットは、チェーンコードの実行中に値が読み取られるキーのセットを含んでもよい。したがって、ピア・ノード４７０の通知ボード・アプリケーション４７２は、キーの値の現在の値を、ＢＵＲＩにより特定された時点からのキーの値に置き換えて、４８７においてチェーンコードを実行し、分散型台帳４７６上の通知ボードから返される値を得る。

図５Ａは、例示の実施形態による、分散型台帳上にブロックチェーン・ベースの統一リソース・インジケータ（ＵＲＩ）を格納する方法５１０を示す。例として、方法５１０は、ブロックチェーン通知ボードを実装し得るブロックチェーン・ピア・ノードにより実行されてもよい。図５Ａを参照する。５１１にて、方法は、複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ）を受信することを含んでもよい。ＵＲＩは、ブロックチェーン・ピア・ノードのネットワーク・アドレスを特定してもよい。一部の実施形態において、ＵＲＩは、ブロックチェーンに関連するブロックチェーン・ピア・ノードのほか、オフチェーン・ストレージ、サードパーティ・サービス、または同様のものなど、別のリソースであってもよい。

方法は、５１２において、ブロックチェーン・ピア・ノードがアクセス可能なブロックチェーンに関連する一意のチャネル名を特定する、ブロックチェーン・チャネル識別情報を特定することを含んでもよい。方法は、５１３において、ブロックチェーン・ピア・ノードのＵＲＩの識別およびブロックチェーンのチャネル名を含む、ブロックチェーン・ベースのＵＲＩを生成することと、５１４において、生成されたブロックチェーン・ベースのＵＲＩを分散型台帳上に格納することとを含んでもよい。チャネル識別情報は、ブロックチェーンに特有とされてもよい。

一部の実施形態では、５１２において特定することは、ブロックチェーンのジェネシス情報を特定することをさらに含んでもよく、５１３において生成することは、ブロックチェーンのジェネシス情報の識別を含むようにブロックチェーン・ベースのＵＲＩを生成することをさらに含んでもよい。例として、ジェネシス情報は、ブロックチェーンのイニシエータの識別を含んでもよい。一部の実施形態では、５１２において特定することは、ブロックチェーンのチェーンコード情報を特定することをさらに含んでもよく、５１３において生成することは、ブロックチェーンのチェーンコード情報の識別を含むようにブロックチェーン・ベースのＵＲＩを生成することをさらに含んでもよい。例として、ブロックチェーンのチェーンコード情報は、チェーンコードＩＤ、チェーンコード・バージョン、およびチェーンコードの中に含まれる引数のうちの１つ以上を含んでもよい。チェーンコードは、（例えばワールド状態データベースの中など）分散型台帳上に格納されたブロックチェーン通知ボードにアクセスするために使用されてもよい。

一部の実施形態では、５１３において生成することは、ブロックチェーン・ベースのＵＲＩが生成された時刻の識別を含むようにブロックチェーン・ベースのＵＲＩを生成することをさらに含んでもよい。一部の実施形態において、方法５１１は、第２のブロックチェーン・ピア・ノードのＵＲＩの識別およびブロックチェーンのチャネル名の識別を含む第２のブロックチェーン・ベースのＵＲＩを生成することと、第２のブロックチェーン・ベースのＵＲＩを分散型台帳上に格納することとをさらに含んでもよい。

図５Ｂは、例示の実施形態による、分散型台帳を介してブロックチェーン・ベースのＵＲＩを修正する方法５２０を示す。例として、方法５２０は、ブロックチェーン通知ボードを実装するブロックチェーン・ピア・ノードにより実行されてもよい。図５Ｂを参照する。方法は、５２１において、分散型台帳上に格納されたブロックチェーン・ベースの統一リソース・インジケータ（ＵＲＩ）を修正するリクエストを受信することを含んでもよい。リクエストは、定期的な間隔で、または無作為に、または同様の形で、ブロックチェーン・ピア・ノードに渡されてもよい。一部の例では、方法は、リクエストを受信しなくてもよいが、ブロックチェーン・ピアのセットに対して発生するブロックチェーン・ピアのＵＲＩの変更、ブロックチェーン・ピアの除去、ブロックチェーン・ピアの追加、または同様のことなどの検出に基づき自動的に修正をトリガしてもよい。

方法は、５２２において、ブロックチェーン・ベースのＵＲＩに対する修正の識別を含むデータ・ブロックを生成することを含んでもよく、方法は、５２３において、ブロックチェーン・ベースのＵＲＩに対する修正の識別を含む生成されたデータ・ブロックを、分散型台帳上のデータ・ブロックのハッシュ・リンク・チェーンの中に格納することを含んでもよい。一部の実施形態において、方法は、ブロックチェーン・ベースのＵＲＩに対する修正に基づき、分散型台帳にアクセスできるブロックチェーン・ピアのセットを更新することをさらに含んでもよい。

一部の実施形態において、データ・ブロックに格納されたブロックチェーン・ベースのＵＲＩは、分散型台帳のブロックチェーン、チェーンコード情報、チャネル情報、時刻値、ジェネシス情報、および同様のものにアクセスできる１つ以上のブロックチェーン・ピア・ノードのＵＲＩを含んでもよい。一部の実施形態において、ブロックチェーン・ベースのＵＲＩを修正するリクエストは、ブロックチェーン・ベースのＵＲＩを分散型台帳から削除するリクエストを含んでもよい。別の例として、ブロックチェーン・ベースのＵＲＩを修正するリクエストは、ブロックチェーン・ベースのＵＲＩの中に含まれるブロックチェーン・ピア・ノードのＵＲＩを修正するリクエストを含んでもよい。

図５Ｃは、例示の実施形態による、ブロックチェーン・リソース情報をブロックチェーン通知ボード上に格納する方法５３０を示す。例として、方法５３０は、ブロックチェーン通知ボードを実装するブロックチェーン・ピア・ノードにより実行されてもよい。図５Ｃを参照する。方法は、５３１において、ブロックチェーンに関連する複数のブロックチェーン・システム・リソースの中からの或るブロックチェーン・システム・リソースの、一意の識別子を受信することを含んでもよい。例として、ブロックチェーン・システム・リソースは、ブロックチェーンにアクセスできるブロックチェーン・ピア・ノードと、ブロックチェーンとともに使用されるデータを格納するオフチェーン・ストレージ・ノードとのうちの１つ以上を含んでもよい。一部の実施形態において、一意の識別子は、ブロックチェーン・システム・リソースの統一リソース・インジケータ（ＵＲＩ）、ブロックチェーンのジェネシス情報、チェーンコード情報、ブロックチェーンのチャネル情報、時刻情報、および同様のもののうちの１つ以上を含んでもよい。

方法は、５３２において、ブロックチェーンを含む分散型台帳上に格納されブロックチェーンとは独立して実装される、ブロックチェーンの通知ボードを生成することを含んでもよい。例として、通知ボードは、ブロックチェーンのメンバーである各ブロックチェーン・ピア・ノードの間に分散される、分散型台帳上に格納されてもよい。通知ボードは、分散型台帳上のワールド状態データベースを介して実装されてもよい。方法は、５３３において、ブロックチェーン・リソースの一意の識別子およびブロックチェーンＩＤを分散型台帳上の通知ボードの中に格納することを含んでもよい。通知ボードは、ブロックチェーンのメンバーである複数のブロックチェーン・ピア・ノードの中の個々のピア・ノードそれぞれの一意の識別子（例えばＢＵＲＩなど）を格納してもよい。

図５Ｄは、例示の実施形態による、ブロックチェーン通知ボードにアクセスする方法５４０を示す。例として、方法５４０は、ブロックチェーン通知ボードを実装するブロックチェーン・ピア・ノードにより実行されてもよい。図５Ｄを参照する。５４１において、方法は、ブロックチェーンに関連して、クライアント・ノードからブロックチェーン・システム・リソースについての情報のリクエストを受信することを含んでもよい。ここで、リクエストは、ブロックチェーン・ピア・ノード情報、もしくはそのほかオフチェーン・ストレージなどのブロックチェーンの一部であるデバイスおよびシステム、またはその両方、ならびに同様のもののリクエストを含んでもよい。

方法は、５４２において、ブロックチェーンを含む分散型台帳上に格納されブロックチェーンとは独立して実装される、ブロックチェーンの通知ボードから、ブロックチェーン・システム・リソースの一意の識別子を読み出すことと、５４３において、通知ボードから読み出されたブロックチェーン・システム・リソースの一意の識別子をクライアント・ノードに送信することとを含んでもよい。例として、ブロックチェーン・システム・リソースは、ブロックチェーンにアクセスできるブロックチェーン・ピア・ノードと、ブロックチェーンとともに使用されるデータを格納するオフチェーン・ストレージ・ノードとのうちの１つ以上を含んでもよい。一部の実施形態において、一意の識別子は、ブロックチェーン・システム・リソースの統一リソース・インジケータ（ＵＲＩ）、ブロックチェーンのチャネル情報、ブロックチェーンのジェネシス情報、データを通知ボードから読み出すためのチェーンコード情報、通知ボード上の格納の時刻情報、および同様のものを含んでもよい。一部の実施形態において、通知ボードは、ブロックチェーンにアクセスする権限を付与された複数のブロックチェーン・ピア・ノードそれぞれの一意の識別子を格納してもよい。

図５Ｅは、例示の実施形態による、リソース・リクエストを実行するためにチェーンコードを再インスタンス化する方法５５０を示す。例として、方法５５０は、ブロックチェーン通知ボードを実装するブロックチェーン・ピア・ノードにより実行されてもよい。図５Ｅを参照する。５５１において、方法は、クライアントからリソース・リクエストを受信することを含んでもよい。例として、リソース・リクエストは、ブロックチェーンにアクセスするために利用可能なブロックチェーン・ピアのブロックチェーン・ネットワーク位置情報のリクエストであってもよい。方法は、５５２において、リソース・リクエストに関連する一意のチェーンコード識別子を特定することを含んでもよい。例として、一意のチェーンコード識別子は、ブロックチェーン・ピアのＵＲＩ情報、ブロックチェーンのチャネル情報、チェーンコード情報、ジェネシス情報、時刻情報、および同様のものを含むＢＵＲＩを含んでもよい。一部の実施形態において、特定することは、再インスタンス化するチェーンコードのバージョンを、一意のチェーンコード識別子に含まれたチェーンコードＩＤおよびチェーンコード・バージョンに基づき特定することを含んでもよい。

５５３において、方法は、一意のチェーンコード識別子に基づくチェーンコードのバージョンを再インスタンス化することを含んでもよい。例として、再インスタンス化は、コンピューティング・ノードにおいて後に実装されたチェーンコードのいかなるバージョンも無視してよい。方法は、５５４において、結果を生成するために、チェーンコードの再インスタンス化されたバージョンに基づきリソース・リクエストを実行することと、５５５において、結果をクライアントに送信することとを含んでもよい。一部の実施形態において、実行することは、ブロックチェーン・ベースのＵＲＩに含まれた時刻に基づき、一意の識別子に含まれた時刻値に関連する以前のキーの値が現在の値と置き換えられた、チェーンコードにより読み取られ／実行される読み取りセットを生成することを、さらに含んでもよい。例として、結果は、ブロックチェーンのメンバーである複数のピア・ノードの現在のブロックチェーン・ベースのＵＲＩのセットを特定してもよい。

図５Ｆは、例示の実施形態による、ブロックチェーンを検証する方法５６０を示す。例として、方法５６０は、ブロックチェーン通知ボードを実装するブロックチェーン・ピア・ノードにより実行されてもよい。図５Ｆを参照する。方法は、５６１において、ブロックチェーンに関連するリクエストを受信することを含んでもよい。リクエストは、ブロックチェーンのメンバーであるブロックチェーン・ピア・ノードについての情報のリクエストを含んでもよい。

方法は、５６２において、リクエストに関連する一意のブロックチェーン識別子を特定することを含んでもよく、一意のブロックチェーン識別子は、ブロックチェーンの一意のジェネシス値を含む。例として、ブロックチェーンの一意のジェネシス値は、ブロックチェーンのイニシエータの識別値、ブロックチェーンが作成された時刻値、およびブロックチェーンの作成に関連する地理的位置値のうちの１つ以上を含んでもよい。

方法は、５６３において、分散型台帳の中に格納されたジェネシス情報に基づき、一意のジェネシス値が有効であるかどうかを判断することを含んでもよく、方法は、５６４において、一意のジェネシス値が有効であるとの判断に応答して、一意のジェネシス値の真正性の証明をアプリケーションに送信することをさらに含んでもよい。一部の実施形態において、判断することは、ブロックチェーン格納リクエストの一意のジェネシス値がブロックチェーン・ピア・ノードにより格納されたジェネシス値情報と同じであるかどうかをチェックすることを含んでもよい。例として、以前格納されたジェネシス値情報は、ブロックチェーンを含む分散型台帳の中に含まれる通知ボード上に格納されていてもよい。一部の実施形態において、方法は、ブロックチェーンの一意のジェネシス値が無効であると判断するのに応答して、格納リクエストが実行されるのを防止することを含んでもよい。

図６Ａは、例示の実施形態による例示の動作の方法のうちの１つ以上に従いブロックチェーンに対して様々な動作を実行するように構成された、例示の物理的インフラストラクチャを示す。図６Ａを参照する。例示の構成６００は、ブロックチェーン６２０およびスマート・コントラクト６３０を備えた物理的インフラストラクチャ６１０を含み、物理的インフラストラクチャ６１０は、例示の実施形態のいずれかに含まれた動作ステップ６１２のいずれかを実行してもよい。ステップ／動作６１２は、１つ以上のフロー図もしくは論理図またはその両方に記載され、または示されたステップのうちの１つ以上を含んでもよい。各ステップは、コンピュータ・システム構成の物理的インフラストラクチャ６１０上に存在する１つ以上のスマート・コントラクト６３０もしくはブロックチェーン６２０またはその両方に書き込まれる、またはそこから読み取られる、出力された、または書き込まれた情報を表し得る。実行されたスマート・コントラクト６３０もしくはブロックチェーン６２０またはその両方から、データが出力されてもよい。物理的インフラストラクチャ６１０は、１つ以上のコンピュータ、サーバ、プロセッサ、メモリ、もしくは無線通信デバイス、またはそのいずれかの組み合わせを含んでもよい。一部の実施形態において、チェーンコードとも呼ばれるスマート・コントラクト６３０は、ブロックチェーン通知ボードからブロックチェーン・リソース情報を読み出すために実行されてもよい。

図６Ｂは、例示の実施形態による、コントラクトの関係者、およびブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された仲介サーバの間の、例示のスマート・コントラクトの構成を示す。図６Ｂを参照する。構成６５０は、１つ以上のユーザ・デバイス６５２もしくは６５６またはその両方を明示的に特定するスマート・コントラクト６３０によって駆動される、通信セッション、アセット転送セッション、またはプロセスもしくは手順を表し得る。スマート・コントラクトの実行、動作、および実行結果は、サーバ６５４によって管理されてもよい。スマート・コントラクト６３０のコンテンツは、スマート・コントラクト・トランザクションの関係者であるエンティティ６５２および６５６のうちの１つ以上によるデジタル署名を要求してもよい。スマート・コントラクトの実行結果は、ブロックチェーン・トランザクションとしてブロックチェーンに書き込まれてもよい。様々な実施形態によれば、本願明細書に記載されたエンドースメント・プロセスの実行は、ブロックチェーン・ピアによる検証チェックの間にスマート・コントラクト６３０の１つ以上の関数（ビジネス・ルール）が満足されることを確認してもよい。

図６Ｃは、例示の実施形態による、コントラクトの関係者、およびブロックチェーンに対してスマート・コントラクトの条件を実施するように構成された仲介サーバの間の、例示のスマート・コントラクトの構成を示す。図６Ｃを参照する。構成６５０は、１つ以上のユーザ・デバイス６５２もしくは６５６またはその両方を明示的に特定するスマート・コントラクト６３０によって駆動される、通信セッション、アセット転送セッション、またはプロセスもしくは手順を表し得る。スマート・コントラクトの実行、動作、および実行結果は、サーバ６５４によって管理されてもよい。スマート・コントラクト６３０のコンテンツは、スマート・コントラクト・トランザクションの関係者であるエンティティ６５２および６５６のうちの１つ以上によるデジタル署名を要求してもよい。スマート・コントラクトの実行結果は、ブロックチェーン・トランザクションとしてブロックチェーン６２０に書き込まれてもよい。スマート・コントラクト６３０は、ブロックチェーン６２０上に存在し、ブロックチェーン６２０は、１つ以上のコンピュータ、サーバ、プロセッサ、メモリ、もしくは無線通信デバイス、またはそのいずれかの組み合わせに存在してもよい。

図６Ｄは、例示の実施形態による、ブロックチェーンの論理およびデータにアクセスするための共通インターフェースを示す。図６Ｄの例を参照する。アプリケーション・プログラミング・インターフェース（ＡＰＩ）ゲートウェイ６６２は、ブロックチェーン論理（例えばスマート・コントラクト６３０またはその他チェーンコード）およびデータ（例えば分散型台帳など）にアクセスするための共通インターフェースを提供する。本例において、ＡＰＩゲートウェイ６６２は、１つ以上のエンティティ６５２および６５６をブロックチェーン・ピア（すなわちサーバ６５４）に接続することによりブロックチェーンに対してトランザクション（呼び出し、クエリなど）を実行するための共通インターフェースである。一部の実施形態において、ＡＰＩゲートウェイ６６２は、様々な実施形態により記載されたブロックチェーン通知ボード上に格納されるブロックチェーン・リソース・データへのアクセスを提供してもよい。サーバ６５４は、ワールド状態および分散型台帳のコピーを保持し、クライアント６５２および６５６が、ワールド状態に関するデータのクエリを行うこと、ならびにブロックチェーン・ネットワークへとトランザクションをサブミットすることを可能にする、ブロックチェーン・ネットワーク・ピア・コンポーネントであり、ブロックチェーン・ネットワークでは、スマート・コントラクト６３０およびエンドースメント・ポリシーに応じてエンドース・ピアがスマート・コントラクト６３０を実行する。一部の実施形態において、ワールド状態は、ＢＵＲＩなどのブロックチェーン・リソース情報を格納するブロックチェーン通知ボードを含んでもよい。ブロックチェーン通知ボードは、１つ以上のスマート・コントラクト６３０によりアクセスされてもよい。

上記の実施形態は、ハードウェア、プロセッサによって実行されるコンピュータ・プログラム、ファームウェア、または上記のものの組み合わせにおいて実装されてもよい。コンピュータ・プログラムは、ストレージ媒体などのコンピュータ可読媒体上で具現化されてもよい。例として、コンピュータ・プログラムは、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュ・メモリ、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、電子的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ：ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、レジスタ、ハード・ディスク、リムーバブル・ディスク、コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：ｃｏｍｐａｃｔ ｄｉｓｋ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、またはその他当該技術分野で既知の任意の形態のストレージ媒体に存在してもよい。

例示のストレージ媒体は、プロセッサがストレージ媒体から情報を読み取り、ストレージ媒体に情報を書き込むことができるように、プロセッサに結合されてもよい。代案として、ストレージ媒体はプロセッサと一体とされてもよい。プロセッサおよびストレージ媒体は、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）に存在してもよい。代案として、プロセッサおよびストレージ媒体は、個別のコンポーネントとして存在してもよい。例として、図７は、前述したコンポーネントのいずれかなどを表し得る、またはそれに統合され得る、例示のコンピュータ・システム・アーキテクチャ７００を示す。

図７は、本願明細書に記載された本願の実施形態の使用または機能性の範囲に関して、いかなる限定を示唆することも意図していない。いずれにせよ、コンピューティング・ノード７００には、上記に記載された機能性のいずれかの実装もしくは実行またはその両方ができる。例として、コンピューティング・ノード７００は、図５Ａ～図５Ｆに示され、それらに関して記載された方法５１０～５６０のいずれを実行してもよい。

コンピューティング・ノード７００内には、コンピュータ・システム／サーバ７０２があり、これは、多数のほかの汎用または専用コンピューティング・システム環境もしくは構成とともに動作可能である。コンピュータ・システム／サーバ７０２とともに使用するのに適していると考えられる周知のコンピューティング・システム、環境、もしくは構成、またはそのいずれかの組み合わせの例としては、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムもしくはデバイスのいずれかを含む分散型クラウド・コンピューティング環境、ならびに同様のものが挙げられるが、これらに限定はされない。

コンピュータ・システム／サーバ７０２については、コンピュータ・システムによって実行されるプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的文脈において記載することができる。一般に、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含んでもよい。コンピュータ・システム／サーバ７０２は、通信ネットワークを介してリンクされているリモート処理デバイスによってタスクが実行される、分散型クラウド・コンピューティング環境において実施されてもよい。分散型クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ・デバイスを含むローカルおよびリモート両方のコンピュータ・システム・ストレージ媒体に位置してもよい。

図７に示されているように、クラウド・コンピューティング・ノード７００内のコンピュータ・システム／サーバ７０２は、汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム／サーバ７０２のコンポーネントは、１つ以上のプロセッサまたは処理ユニット７０４、システム・メモリ７０６、およびシステム・メモリ７０６を含む様々なシステム・コンポーネントをプロセッサ７０４に結合するバスを含み得るが、これらに限定はされない。

バスは、メモリ・バスまたはメモリ・コントローラ、周辺機器用バス、アクセラレーテッド・グラフィックス・ポート、および様々なバス・アーキテクチャのいずれかを使用するプロセッサもしくはローカル・バスを含む、いくつかのタイプのバス構造のうち、任意のもの１つ以上を表す。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ：Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ：Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ：Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ：Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカル・バス、およびペリフェラル・コンポーネント・インターコネクト（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。

コンピュータ・システム／サーバ７０２は、典型的には、様々なコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ７０２によってアクセス可能な任意の利用可能な媒体とされればよく、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両方を含む。一実施形態において、システム・メモリ７０６は、他の図面のフロー図を実装する。システム・メモリ７０６は、ランダム・アクセス・メモリ（ＲＡＭ）７１０もしくはキャッシュ・メモリ７１２またはその両方など、揮発性メモリの形態のコンピュータ・システム可読媒体を含むことができる。このほか、コンピュータ・システム／サーバ７０２はさらに、リムーバブル／非リムーバブルの揮発性／不揮発性コンピュータ・システム・ストレージ媒体を含んでもよい。単なる例として、非リムーバブルの不揮発性磁気媒体（図示はしておらず、典型的には「ハード・ドライブ」と呼ばれる）からの読み取りおよびそれに対する書き込みのために、ストレージ・システム７１４を提供することができる。図示されてはいないが、リムーバブル不揮発性磁気ディスク（例えば「フレキシブル・ディスク」）からの読み取りおよびそれに対する書き込みのための磁気ディスク・ドライブ、およびＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、またはその他の光媒体などのリムーバブル不揮発性光ディスクからの読み取りまたはそれに対する書き込みのための光ディスク・ドライブを提供することができる。そのような場合には、それぞれを、１つ以上のデータ媒体インターフェースによってバスに接続できる。さらに図示し、後述するように、メモリ７０６は、本願の様々な実施形態の機能を実行するよう構成されたプログラム・モジュールのセット（例えば少なくとも１つ）を有する少なくとも１つのプログラム製品を含んでもよい。

プログラム・モジュール７１８のセット（少なくとも１つ）を有するプログラム／ユーティリティ７１６は、限定ではなく例として、オペレーティング・システム、１つ以上のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データと同様にメモリ７０６に格納されてもよい。オペレーティング・システム、１つ以上のアプリケーション・プログラム、その他プログラム・モジュール、およびプログラム・データ、またはその何らかの組み合わせはそれぞれ、ネットワーキング環境の実装を含んでもよい。プログラム・モジュール７１８は、概して、本願明細書に記載された本願の様々な実施形態の機能もしくは手順またはその両方を実行する。

当業者には当然のことながら、本願の各側面は、システム、方法、またはコンピュータ・プログラム製品として具現化されてもよい。したがって、本願の各側面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本願明細書においてすべて概して「回路」、「モジュール」、または「システム」と呼ばれ得る、ソフトウェアおよびハードウェアの側面を兼ね備えた実施形態の形態をとってもよい。さらに、本願の各側面は、コンピュータ可読プログラム・コードが具現化された１つ以上のコンピュータ可読媒体（単数または複数）において具現化された、コンピュータ・プログラム製品の形態をとることもできる。

コンピュータ・システム／サーバ７０２はさらに、キーボード、ポインティング・デバイス、ディスプレイ７２２などの１つ以上の外部デバイス７２０、ユーザがコンピュータ・システム／サーバ７０２と相互作用できるようにする１つ以上のデバイス、もしくはコンピュータ・システム／サーバ７０２が１つ以上の他のコンピューティング・デバイスと通信できるようにする任意のデバイス（例えばネットワーク・カード、モデムなど）、またはそのいずれかの組み合わせと通信してもよい。そのような通信は、Ｉ／Ｏインターフェース７２４を介して生じてもよい。さらに、コンピュータ・システム／サーバ７０２は、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、一般的な広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、もしくはパブリック・ネットワーク（例えばインターネット）、またはそのいずれかの組み合わせなどの１つ以上のネットワークと、ネットワーク・アダプタ７２６を介して通信できる。図示されているように、ネットワーク・アダプタ７２６は、コンピュータ・システム／サーバ７０２の他のコンポーネントとバスを介して通信する。図示されてはいないが、当然のことながら、他のハードウェアもしくはソフトウェアまたはその両方のコンポーネントが、コンピュータ・システム／サーバ７０２とともに使用され得るであろう。例としてはマイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが挙げられるが、これらに限定はされない。

システム、方法、および非一時的コンピュータ可読媒体のうちの少なくとも１つの例示的な実施形態が添付の図面に示され、前述の詳細な説明の中に記載されたが、当然のことながら本願は、記載された実施形態に限定されず、添付の特許請求の範囲により記載および定義される多数の再構成、修正、および置き換えが可能である。例として、様々な図面のシステムの機能は、本願明細書に記載されたモジュールもしくはコンポーネントのうちの１つ以上によって、または分散型アーキテクチャにおいて実行することができ、送信器、受信器、またはその両方のペアを含んでもよい。例として、個々のモジュールによって実行される機能性の全部または一部は、それらのモジュールのうちの１つ以上によって実行されてもよい。さらに、本明細書に記載された機能性は、様々な時間に、様々なイベントに関して、モジュールまたはコンポーネントの内部または外部で実行されてもよい。さらに、様々なモジュール間で送信される情報は、データ・ネットワーク、インターネット、音声ネットワーク、インターネット・プロトコル・ネットワーク、無線デバイス、有線デバイスのうちの少なくとも１つを介して、もしくは複数のプロトコルを介して、またはそのいずれかの組み合わせを介して、モジュール間で送信できる。さらに、モジュールのいずれかによって送信または受信されるメッセージは、直接的に、もしくは他のモジュールのうちの１つ以上を介して、またはその両方によって、送信または受信されてもよい。

当業者には当然のことながら、「システム」は、パーソナル・コンピュータ、サーバ、コンソール、携帯情報端末（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、携帯電話、タブレット・コンピューティング・デバイス、スマートフォン、もしくはその他任意の適切なコンピューティング・デバイス、または複数デバイスの組み合わせとして具現化できるであろう。上述の機能を「システム」によって実行されているものとして提示することで、本願の範囲を限定する意図は決してなく、多数の実施形態の一例を示すことが意図されている。実際、本願明細書で開示された方法、システム、および装置は、コンピューティング技術と整合する局所的および分散型の形態で実装されてもよい。

なお、本願明細書に記載されたシステムの特徴の一部は、それらの実装の独立性を特に強調するためにモジュールとして提示されている。例として、モジュールは、カスタム超大規模集積（ＶＬＳＩ：ｖｅｒｙ ｌａｒｇｅ－ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ）回路もしくはゲート・アレイ、論理チップなどの市販の半導体、トランジスタ、またはその他個別のコンポーネントを含むハードウェア回路として実装されてもよい。モジュールはさらに、フィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ論理、プログラマブル論理デバイス、グラフィックス処理ユニット、または同様のものなど、プログラマブル・ハードウェア・デバイスにおいて実装されてもよい。

モジュールはさらに、様々なタイプのプロセッサによって実行されるソフトウェアにおいて少なくとも部分的に実装されてもよい。例えば、実行可能コードの特定されたユニットは、例えばオブジェクト、プロシージャ、または関数として編成され得るコンピュータ命令の１つ以上の物理的または論理的ブロックを含んでもよい。それでも、特定されたモジュールの実行ファイルは、物理的に一緒に配置される必要はなく、異なる位置に格納された異種の命令を含んでもよく、それらの命令は、論理的に一緒にされた場合にモジュールを構成し、モジュールの規定された目的を達成する。さらに、モジュールはコンピュータ可読媒体に格納されてもよく、このコンピュータ可読媒体は例えば、ハード・ディスク・ドライブ、フラッシュ・デバイス、ランダム・アクセス・メモリ（ＲＡＭ）、テープ、またはその他データの格納に使用される任意の媒体とされてもよい。

実際、実行可能コードのモジュールは、単一の命令または多数の命令とすることができ、いくつかの異なるコード・セグメントにわたり分散されても、異なるプログラム間に分散されても、いくつかのメモリ・デバイスにまたがって分散されてもよい。同様に、動作データは、本願明細書においてモジュールの中に特定されて示され得るが、任意の適切な形態で具現化されて任意の適切なタイプのデータ構造の中で編成されてもよい。動作データは、単一のデータ・セットとしてまとめられてもよく、または別々のストレージ・デバイスを含む別々の位置に分散されてもよく、さらに単にシステムまたはネットワーク上の電子信号として少なくとも部分的に存在してもよい。

当然のことながら、本願明細書において、全般的に記載され図面に示されている本願のコンポーネントは、幅広い種々の構成で配置および設計され得る。よって、実施形態についての詳細な記載は、特許請求される本願の範囲を限定することを意図したものではなく、本願の選択された実施形態を代表するにすぎない。

当業者には当然のことながら、上記は、他の順序のステップを用いて、もしくは開示されたものとは異なる構成のハードウェア構成要素を用いて、またはその両方の形で実施されてもよい。したがって、本願は、これらの好適な実施形態に基づいて記載されたが、当業者には当然のことながら、特定の変更、バリエーション、および代わりの構造は明らかであると考えられる。

本願の好適な実施形態が説明されたが、当然のことながら、記載された実施形態は単なる例であり、あらゆる種類のそれらの等価物およびそれらに対する変更（例えばプロトコル、ハードウェア・デバイス、ソフトウェア・プラットフォームなど）とともに考えた場合の添付の特許請求の範囲のみによって本願の範囲は定義されるべきである。

Claims (15)

1. ストレージと、
   複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ）を受信するように構成されたネットワーク・インターフェースと、
   前記ブロックチェーンに関連する一意のチャネル名を特定するブロックチェーン・チャネル識別情報を特定し、前記ブロックチェーン・ピア・ノードの前記ＵＲＩの識別および前記ブロックチェーンの前記チャネル名を含むブロックチェーン・ベースのＵＲＩを生成し、前記生成されたブロックチェーン・ベースのＵＲＩを前記ストレージの中の分散型台帳上に格納するように構成されたプロセッサとを含むコンピューティング・ノード。
2. 前記プロセッサは、前記ブロックチェーンのジェネシス情報を特定し、前記ブロックチェーンの前記ジェネシス情報の識別を含むように前記ブロックチェーン・ベースのＵＲＩを生成するように構成される、請求項１に記載のコンピューティング・ノード。
3. 前記ジェネシス情報は、前記ブロックチェーンのイニシエータの識別を含む、請求項２に記載のコンピューティング・ノード。
4. 前記プロセッサにより生成された前記ブロックチェーン・ベースのＵＲＩは、前記ブロックチェーン・ベースのＵＲＩが生成された時刻の識別をさらに含む、請求項１ないし請求項３のいずれかに記載のコンピューティング・ノード。
5. 前記プロセッサは、前記ブロックチェーンのチェーンコード情報を特定し、前記ブロックチェーンの前記チェーンコード情報の識別を含むように前記ブロックチェーン・ベースのＵＲＩを生成するようにさらに構成される、請求項１ないし請求項４のいずれかに記載のコンピューティング・ノード。
6. 前記チェーンコード情報は、チェーンコードＩＤと、チェーンコード・バージョンと、チェーンコードの中に含まれる、関数名を含む引数とのうちの１つ以上を含む、請求項５に記載のコンピューティング・ノード。
7. 前記プロセッサは、第２のブロックチェーン・ピア・ノードのＵＲＩの識別および前記ブロックチェーンの前記チャネル名の識別を含む第２のブロックチェーン・ベースのＵＲＩを生成し、前記第２のブロックチェーン・ベースのＵＲＩを前記ストレージの前記分散型台帳の中に格納するようにさらに構成される、請求項１ないし請求項６のいずれかに記載のコンピューティング・ノード。
8. コンピューティング・ノードにより実行される方法であり、
   複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ）を受信するステップと、
   前記ブロックチェーンに関連する一意のチャネル名を特定するブロックチェーン・チャネル識別情報を特定するステップと、
   前記ブロックチェーン・ピア・ノードの前記ＵＲＩの識別および前記ブロックチェーンに関連する前記チャネル名を含むブロックチェーン・ベースのＵＲＩを生成するステップと、
   前記生成されたブロックチェーン・ベースのＵＲＩを分散型台帳上に格納するステップと
   を含む方法。
9. 前記特定するステップは、前記ブロックチェーンのジェネシス情報を特定するステップをさらに含み、前記生成するステップは、前記ブロックチェーンの前記ジェネシス情報の識別を含むように前記ブロックチェーン・ベースのＵＲＩを生成するステップをさらに含む、請求項８に記載の方法。
10. 前記ジェネシス情報は、前記ブロックチェーンのイニシエータの識別を含む、請求項９に記載の方法。
11. 前記生成するステップは、前記ブロックチェーン・ベースのＵＲＩが生成された時刻の識別を含むように前記ブロックチェーン・ベースのＵＲＩを生成するステップをさらに含む、請求項８ないし請求項１０のいずれかに記載の方法。
12. 前記特定するステップは、前記ブロックチェーンのチェーンコード情報を特定するステップをさらに含み、前記生成するステップは、前記ブロックチェーンの前記チェーンコード情報の識別を含むように前記ブロックチェーン・ベースのＵＲＩを生成するステップをさらに含む、請求項８ないし請求項１１のいずれかに記載の方法。
13. 前記チェーンコード情報は、チェーンコードＩＤと、チェーンコード・バージョンと、チェーンコードの中に含まれる、関数名を含む引数とのうちの１つ以上を含む、請求項１２に記載の方法。
14. 第２のブロックチェーン・ピア・ノードのＵＲＩの識別および前記ブロックチェーンの前記チャネル名の識別を含む第２のブロックチェーン・ベースのＵＲＩを生成するステップと、前記第２のブロックチェーン・ベースのＵＲＩを前記分散型台帳上に格納するステップとをさらに含む、請求項８ないし請求項１３のいずれかに記載の方法。
15. プロセッサにより読み取られると前記プロセッサに、
    複数のブロックチェーン・ピア・ノード間に分散されたブロックチェーンにアクセスできるブロックチェーン・ピア・ノードの統一リソース・インジケータ（ＵＲＩ）を受信するステップと、
    前記ブロックチェーンに関連する一意のチャネル名を特定するブロックチェーン・チャネル識別情報を特定するステップと、
    前記ブロックチェーン・ピア・ノードの前記ＵＲＩの識別および前記ブロックチェーンの前記チャネル名を含むブロックチェーン・ベースのＵＲＩを生成するステップと、
    前記生成されたブロックチェーン・ベースのＵＲＩを分散型台帳上に格納するステップと
    を含む方法を実行させるコンピュータ・プログラム。

Images