JP7382108B2 - ブロックチェーンのための効率的な検証 - Google Patents

Description

本出願は、一般にブロックチェーン・ネットワークのためのトランザクション検証に関し、より詳細には、ブロックチェーンのための効率的な検証に関する。

台帳は、トランザクションが記録されるエントリのアカウント・ブックとして一般的に定義されている。分散型台帳は、複数のコンピュータに全体的にまたは部分的に複製される台帳である。暗号分散型台帳（ＣＤＬ）は、不可逆性（トランザクションが一旦記録されると元に戻せない）、アクセス可能性（いかなる当事者も全体的または部分的にＣＤＬにアクセス可能である）、時系列かつタイムスタンプされている（全ての当事者が、トランザクションがいつ台帳に追加されたかを知っている）、合意ベース（ネットワーク上の当事者により、典型的には満場一致で承認された場合にのみ、トランザクションが追加される）、検証可能性（全てのトランザクションが暗号により検証され得る）のこれらの特性の少なくともいくつかを有し得る。ブロックチェーンは、ＣＤＬの一例である。本明細書における説明および図面は、ブロックチェーンに関して説明されるが、本出願は、いかなるＣＤＬにも同様に適用する。

分散型台帳は、他のブロックに関する暗号ハッシュを記憶するなど暗号技術を典型的に適用する、連続的に増大するレコードのリストである。ブロックチェーンは、分散型台帳の１つの共通事例であり、情報を記憶するための公開台帳として使用され得る。ブロックチェーンは、主に金融トランザクションのために用いられるが、商品およびサービスに関する様々な情報（即ち、製品、パッケージ、状態など）を記憶し得る。非集中型方式は、非集中型ネットワークに権限および信用を与え、そのノードが連続的かつ逐次的にそれらのトランザクションを公開「ブロック」上に記録することを可能にして、ブロックチェーンと呼ばれる一意の「チェーン」を生成する。ハッシュ・コードを介した暗号法が、トランザクション元の認証を保証するために使用され、中央の仲介者を除去する。ブロックチェーンは、連続的に増大するレコードのリストをブロックチェーンのブロックに維持する分散型データベースであり、ブロックチェーンのブロックは、それらの不変性特性に起因して改ざんおよび改訂から保護される。各ブロックは、タイムスタンプおよび前のブロックへのリンクを含む。ブロックチェーンは、情報を保持し、追跡し、移転し、確認するために使用され得る。ブロックチェーンは分散型システムであるため、ブロックチェーン台帳にトランザクションを追加する前に、全てのピアが合意状態に達する必要がある。

従来、ブロックチェーン・トランザクションは、ブロックチェーン内の全てのブロックについて状態データベースに対して検証され、それは、データベースから状態データを取り出すためにかかる時間によって制限される。したがって、必要とされるものは、これらの制限を克服するためのトランザクション検証のより高速かつ効率的な形態である。

１つの例としての実施形態は、ブロックチェーン・ノードによって、メモリ内に検証データベースを生成することと、１つまたは複数のトランザクションのそれぞれをシミュレーションすることと、新規ブロック内の各トランザクションが検証データベースを用いて検証され得ると判断することと、検証データベースを用いて新規ブロック内の各トランザクションを検証することと、新規ブロックをブロックチェーンにコミットすることと、のうちの１つまたは複数を含む方法を提供し得る。検証データベースは、ブロックチェーンのための状態データベースの所定の数の直近ブロックに対応することを含む。

別の例としての実施形態は、プロセッサおよびメモリを含むシステムを提供し得る。プロセッサは、１つまたは複数のトランザクションのそれぞれをシミュレーションすることと、新規ブロック内の各トランザクションが検証データベースを用いて検証され得ると判断することと、検証データベースを用いて新規ブロック内の各トランザクションを検証することと、新規ブロックをブロックチェーンにコミットすることと、のうちの１つまたは複数を実行するように構成される。

１つの態様によれば、ブロックチェーン・ネットワークを含むシステムが提供され、ブロックチェーン・ネットワークは、ブロックチェーン・トランザクションを検証する１つまたは複数のブロックチェーン・ノードを含み、各ブロックチェーン・ノードは、プロセッサと、プロセッサに連結されるメモリ・デバイスと、を含み、メモリ・デバイスは、検証データベースを含み、検証データベースは、ブロックチェーンの所定の数の直近ブロックに対応するデータを含み、プロセッサは、１つまたは複数のトランザクションのそれぞれをシミュレーションし、新規ブロック内の各トランザクションが検証データベースを用いて検証され得ると判断し、検証データベースを用いて新規ブロック内の各トランザクションを検証し、新規ブロックをブロックチェーンにコミットするように構成される。

さらなる例としての実施形態は、プロセッサによって読み出されるときに、ブロックチェーン・ノードによって、メモリ内に検証データベースを生成することと、１つまたは複数のトランザクションのそれぞれをシミュレーションすることと、新規ブロック内の各トランザクションが検証データベースを用いて検証され得ると判断することと、検証データベースを用いて新規ブロック内の各トランザクションを検証することと、新規ブロックをブロックチェーンにコミットすることと、のうちの１つまたは複数をプロセッサに実行させる命令を含む、非一過性コンピュータ可読媒体を提供し得る。検証データベースは、ブロックチェーンのための状態データベースの所定の数の直近ブロックに対応するデータを含む。

発明の実施形態は、ここで単なる例として添付図面を参照して説明される。

例としての実施形態による、ブロックチェーンでトランザクションを効率的に検証するためのシステムのネットワーク図である。 例としての実施形態による、ブロックチェーンを用いた状態データベース・パラメータのネットワーク図である。 例としての実施形態による、資産共有シナリオのための例としてのピア・ノード・ブロックチェーン・アーキテクチャ構成を示す図である。 例としての実施形態による、例としてのピア・ノード・ブロックチェーン構成を示す図である。 例としての実施形態による、許可型ブロックチェーン・ネットワークを示す図である。 例としての実施形態による、ブロックチェーン状態シミュレーションおよび検証を実行するためのシステム・メッセージング図である。 例としての実施形態による、ブロックチェーンにおいて検証データベースを用いてトランザクションをシミュレーションおよび検証する例としての方法のフロー図である。 例としての実施形態による、ブロックチェーンにおいて分岐チェーン検証を解決する例としての方法のフロー図である。 例としての実施形態による、本明細書に説明される１つまたは複数の動作に従ってブロックチェーン上で様々な動作を実行するように構成される例としての物理インフラストラクチャを示す図である。 例としての実施形態による、ブロックチェーン上でスマート・コントラクト条件を施行するように構成される契約当事者と仲介サーバとの間の例としてのスマート・コントラクト構成を示す図である。 例としての実施形態のうちの１つまたは複数をサポートするように構成される、例としてのコンピュータ・システムを示す図である。

本コンポーネントは、本明細書において概して説明され図面に示されるように、多種多様な異なる構成において配列され設計され得ると、容易に理解される。よって、添付図面において表される、方法、装置、非一過性コンピュータ可読媒体、およびシステムのうちの少なくとも１つの実施形態の以下の詳細な説明は、特許請求されているように本出願の範囲を限定することを意図しておらず、単に選択された実施形態を表している。

本明細書全体を通して説明される、本特徴、構造、または特性は、１つまたは複数の実施形態において任意の適当なやり方で結合され得る。例えば、「例としての実施形態」、「いくつかの実施形態」という語句、または他の類似の言葉の使用は、本明細書全体を通して、実施形態に関連して説明される特定の特徴、構造、または特性が少なくとも１つの実施形態に含まれ得るという事実を指す。よって、「例としての実施形態」、「いくつかの実施形態において」、「他の実施形態において」という語句、または他の類似の言葉の出現は、本明細書全体を通して、必ずしも全てが実施形態の同一グループを指しておらず、説明される特徴、構造、または特性が、１つまたは複数の実施形態において任意の適当なやり方で結合され得る。

さらに、「メッセージ」という用語が、実施形態の説明において使用されていることがあるが、本出願は、パケット、フレーム、データグラムなどの多くの種類のネットワーク・データに適用され得る。「メッセージ」という用語は、パケット、フレーム、データグラム、およびそれらの任意の均等物も含む。さらに、ある種類のメッセージおよびシグナリングが、例示的実施形態に示されることがあるが、それらは、ある種類のメッセージに限定されず、本出願は、ある種類のシグナリングに限定されない。例としての実施形態は、方法、システム、非一過性コンピュータ可読媒体、デバイス、またはネットワーク、あるいはそれらの組み合わせを提供し、それらは、ブロックチェーンのための効率的なトランザクション検証を提供する。

ブロックチェーンは、分散型システムであり、それは、互いに通信する複数のノードを含む。ブロックチェーンは、チェーンコード（例えばスマート・コントラクトなど）と呼ばれるプログラムを動作させ、状態および台帳データを保持し、トランザクションを実行する。いくつかのトランザクションは、チェーンコード上で呼び出される動作である。概して、ブロックチェーン・トランザクションは、典型的には、あるブロックチェーン・メンバによって「エンドース（endorse）」されなければならず、エンドースされたトランザクションのみが、ブロックチェーンにコミットされ、ブロックチェーンの状態に対する影響を有し得る。エンドースされない他のトランザクションは、無視される。管理機能およびパラメータについての１つまたは複数の特定のチェーンコードが存在してもよく、まとめてシステム・チェーンコードと呼ばれる。

ノードは、ブロックチェーン・システムの通信エンティティである。「ノード」は、異なる種類の複数のノードが同一の物理サーバ上で実行し得るという意味で、論理関数を実行し得る。ノードは、信頼できるドメイン内にグループ化され、様々な方法でそれらを制御する論理エンティティに関連付けられる。ノードは、トランザクション呼び出しをエンドーサ（endorser）（例えば、ピア）にサブミットし、トランザクション提案を順序付けサービス（例えば、順序付けノード（ordering node））にブロードキャストする、クライアントまたはサブミット・クライアント・ノードなどの異なる種類を含み得る。ノードの別の種類は、クライアントがサブミットしたトランザクションを受信し、トランザクションをコミットし、ブロックチェーン・トランザクションの台帳の状態およびコピーを維持し得るピア・ノードである。ピアは、エンドーサの役割も有し得るが、それは必須ではない。順序付けサービス・ノードまたはオーダラ（orderer）は、全てのノードについて通信サービスを実行するノードであり、トランザクションをコミットし、ブロックチェーンの世界状態を修正するときに、システム内のピア・ノードのそれぞれに対するブロードキャストなどの、配信保証を実施する。世界状態は、制御およびセットアップ情報を通常含む、初期のブロックチェーン・トランザクションについての別名である。

台帳は、ブロックチェーンの全ての状態遷移の、順番に配列された耐改ざんレコードである。状態遷移は、参加している当事者（例えば、クライアント・ノード、順序付けノード、エンドーサ・ノード、ピア・ノードなど）によってサブミットされるチェーンコード呼び出し（即ち、トランザクション）から生じ得る。トランザクションは、生成、更新、削除などの１つまたは複数のオペランドとして台帳にコミットされている資産キーバリュー・ペアのセットをもたらし得る。台帳は、不変性の、順番に配列されたレコードをブロックに記憶するために使用されるブロックチェーン（チェーンとも呼ばれる）を含む。台帳は状態データベースも含み、状態データベースは、ブロックチェーンの現在の状態を維持する。典型的には、チャネル毎に１つの台帳が存在する。各ピア・ノードは、それらがメンバであるチャネル毎に台帳のコピーを維持する。

チェーンは、ハッシュでリンクされたブロックとして構築されるトランザクション・ログであり、各ブロックは、Ｎ個のトランザクションのシーケンスを含み、Ｎは１以上である。ブロック・ヘッダは、ブロックのトランザクションのハッシュだけでなく、前のブロックのヘッダのハッシュも含む。このようにして、台帳上の全てのトランザクションが、順番に配列され、暗号によって共にリンクされ得る。したがって、ハッシュ・リンクを壊すことなく台帳データを改ざんすることはできない。最新の追加されたブロックチェーン・ブロックのハッシュは、その前に来たチェーン上のあらゆるトランザクションを表し、全てのピア・ノードが整合性および信頼性のある状態にあることを保証することを可能にしている。チェーンは、ピア・ノード・ファイル・システム（即ち、ローカルな、アタッチされたストレージ、クラウドなど）上に記憶されてもよく、ブロックチェーンの作業負荷の追加専用の性質を効率的にサポートする。

不変性台帳の現在の状態は、チェーン・トランザクション・ログに含まれる全てのキーについての最新の値を表す。現在の状態は、チャネルにとって既知の最新のキーバリューを表すため、それは、世界状態と呼ばれることがある。チェーンコード呼び出しは、台帳の現在の状態データに対してトランザクションを実行する。これらのチェーンコードの相互作用を効率的にするために、キーの最新の値が、状態データベース１２４内に記憶され得る。状態データベース１２４は、単にチェーンのトランザクション・ログ内にインデックスされたビューであってもよく、したがって、それはいかなるときでもチェーンから再生成され得る。状態データベース１２４は、ピア・ノードが起動した後、およびトランザクションが受け取られる前に、自動的に回復され得る（または必要であれば生成され得る）。

例としての実施形態は、方法、デバイス、ネットワーク、非一過性コンピュータ可読媒体、またはシステム、あるいはそれらの組み合わせを目的とし、それらは、高速トランザクション検証をサポートするブロックチェーン・ソリューションをサポートする。利益のいくつかが、新規ブロックにおいてトランザクションを検証するための新たなソリューションを提供することを含む。任意のブロックチェーンにおいて、新規ブロックがネットワークに発行されるとき、トランザクションの検証を実行することは重要なステップである。このステップは、ブロック内のどのトランザクションが有効または無効として受け取られるべきかを最終的に決定する。検証の結果は、同様に、ブロックがコミットされるときにブロックチェーンの状態がどのように変化するかを決定する。この検証ステップの実行は、ブロックチェーン・ネットワークが提供し得るトランザクションの全体スループットに対して直接的な影響を有する。本出願は、本来包括的であり、実行／エンドース／順序付け／コミット・パラダイム（Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃなどの）を実施する、ブロックチェーン技術におけるこの検証ステップに対する性能改善を可能にする。

検証が実行されるとき、コミット段階の間の技術水準は、（ディスク上に記憶され、潜在的にサイズが非常に大きい可能性がある）状態データベースにアクセスすることである。本出願は、新たな検証データベース内に制限された量のデータのみを維持することによって、検証プロセスの効率および性能を改善する新たな技術を提示する。この技術は、（時間と共に増大し続ける）ブロックチェーン内のブロックの実際の数に関わりなく、検証データベース内に所定の数の直近ブロックに対応する制限された量のデータを維持することを必要とする。この制限された量のデータのために、検証データベースは、ディスク上ではなくインメモリで潜在的に維持されてもよく、したがって、検証のためにより低速の記憶媒体にアクセスすることを回避する。

ブロックチェーンは、中央記憶装置ではなく非集中型で不変性の安全な記憶装置であるという点において従来のデータベースとは異なり、その場合に、ノードは記憶装置内のレコードに対する変更を共有しなければならない。ブロックチェーンにおいて固有であり、ブロックチェーンを実施する助けとなるいくつかの特性は、本明細書においてさらに説明される、不変性台帳、スマート・コントラクト、セキュリティ、プライバシー、非集中型、合意、エンドースメント、アクセス可能性などを含むが、これらに限定されない。様々な実施形態によれば、検証データベースは、概してブロックチェーン技術に対する改善として実施され、全てのブロックチェーン・ネットワークは、より高速のトランザクション検証から利益を受ける。

例としての実施形態の利益のうちの１つは、トランザクション検証性能および効率を改善することによるコンピューティング・システムの機能性の改善である。本明細書に説明されるブロックチェーン・ソリューションを通して、コンピューティング・システムは、検証データベースをインメモリで維持することによって新規の機能性を実行し得る。これによって、新規ブロック内のトランザクションの検証を実行するためにブロックチェーン・ノードが維持するデータの量が著しく減少する。

例としての実施形態は、従来のデータベースよりも多くの利益を提供する。例えば、ブロックチェーンにおけるトランザクション検証性能を改善することによって、様々な利点が達成される。例えば、より多くのトランザクションが、ネットワーク速度／性能またはブロックチェーン・ノード・ハードウェアを増加させることなく時間単位で検証され得る。また、そのような性能向上は、より高速なブロックチェーン・ノードまたはネットワーキング・ハードウェアを代用することによってブロックチェーン・ネットワークにコストを追加することなく達成され得る。本出願によって提供される改善は、既存のブロックチェーン・ネットワークに透過的である。

一方、本明細書で説明される改善は、ブロックチェーン技術およびブロックチェーン・インフラストラクチャに固有であるため、従来のデータベースは、例としての実施形態を実施するために使用されることはない。したがって、例としての実施形態は、ブロックチェーンのための効率的な検証の当技術分野／領域における問題点に対する特定のソリューションを提供する。

図１Ａは、例としての実施形態による、ブロックチェーンでトランザクションを効率的に検証するためのシステムの論理ネットワーク図を示す。多くのブロックチェーン・システムにおいてブロック・コミットの間、トランザクション検証は、性能ボトルネックのうちの１つである。これは、主に、検証プロセスが、データベースの現在の状態に対してトランザクションを検証するために、データベースに対して大量のランダムな読み出しを引き起こすためである。これは、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃにおいて現在実施されている検証方式を反映する。本出願は、はるかに小さなデータ・セットに対して検証が実行されることを可能にすることによって、この検証プロセスをより一層効率的にするシステムおよび方法を導入する。小さなデータ・セットは、インメモリで維持されてもよく、したがってディスクまたはより低速の主記憶装置にアクセスすることを回避し得る。

ブロックチェーン・トランザクションは、「begin_tran」および「commit_tran」というステートメントによってマークされる境界で囲まれた照会および更新ステートメントのシーケンスを含む。「begin_tran」というステートメントは、トランザクションのシミュレーション開始に相当し、「commit_tran」というステートメントは、トランザクションの検証およびコミットに相当する。しかしながら、ブロックチェーンの分散型の性質のために、シミュレーションは、１つまたは複数のノードにおいて実行され、検証およびコミットは、全てのノード上で実行される。トランザクションの持続期間中（即ち、「begin_tran」と「commit_tran」との間であり、それは、それぞれ「シミュレーション」および「コミット」である）、トランザクションが照会を一回よりも多く実行する場合、照会結果は変化するべきではない。これは、直列化可能トランザクション分離レベルと呼ばれる。しかしながら、何らかの他のトランザクションが、第１のトランザクションの「begin_tran」と「commit_tran」との間にデータ変更を行う場合、第１のトランザクションは、同じ照会について異なる結果を受信し得る。第２の照会については、それは、追加のエントリを受信することとなり、その場合、追加のエントリはファントム・エントリと呼ばれる。

図１Ａを参照すると、ネットワーク１００は、状態データベース１２４を含み、状態データベース１２４は、ブロックチェーン内の全てのブロックについての現在の状態１２０を記憶する。図１Ａは、状態０ １２０Ａ、状態１ １２０Ｂ、状態２ １２０Ｃ～状態Ｌ １２０Ｌ、状態Ｍ １２０Ｍ、および状態Ｎ １２０Ｎを含むブロックチェーンを示している。このように、例示されるブロックチェーンには、Ｎ個の状態１２０がある。各状態１２０について、対応するブロック（図示せず）があり、ブロックは、検証されたトランザクションを記憶し、状態１２０は、全ての一意なキーについて＜キー，値＞のタプルの集合を記憶する。「キー」は、ブロックのうちのいずれかにおけるライトセットのいずれかに存在するキーを表し、「値」は、ブロックチェーン内の有効トランザクション（ライトセットを含む）におけるキーの直近の発生に存在する値を表す。例えば、キー「バランス」が、異なるブロック（＜「バランスＡ」：３０＞としてブロック＃１、＜「バランスＢ」：５０＞としてブロック＃２０、＜「バランスＣ」：７０＞としてブロック＃４５）内の３つの有効トランザクションに存在する場合、状態データベース１２４においてキー「バランス」が、（直近ブロックから）値７０と共に１度だけ出現し得る。

ネットワーク１００は、また、検証データベース１１６を含み、検証データベース１１６は、状態データベース１２４のサブセットを記憶する。サブセットは、所定の数の直近ブロック１２８に対応する。図１Ａは、状態Ｌ １２０Ｌ、状態Ｍ １２０Ｍ、および状態Ｎ １２０Ｎについての状態情報を記憶する検証データベース１１６を示している。よって、示される例では、検証データベース１１６内に３つの状態１２０が示されている。状態１２０に等しい数のブロック（図示せず）が存在すると、概して理解されるべきである。実際の実施形態では、検証データベース１１６内に３つより多くの状態１２０、１００個の状態１２０などが概して存在する。検証データベース１１６に対応するブロックの所定の数は、ブロックチェーン・ネットワークまたはネットワーク１００の性能、ブロック内のトランザクションの数、ならびに検証データベース１１６内の状態１２０を記憶するために使用されるメモリのサイズおよび性能を含む、多くの要因に依存する。

トランザクション１０４のシミュレーション１０８は、そのシミュレーション１０８の間にトランザクション１０４によって実行される照会１１２Ａの結果に影響を受けることがないため、検証データベース１１６は、最後の数ブロックによって引き起こされる状態変化１２０を含み、検証１５６の間、ブロックチェーン・ネットワークは、（他のコミットされたトランザクション１６０によって）もたらされる状態変化を確認する。検証データベース１１６に関連するのは、最小高さ１６４であり、最小高さ１６４は、検証データベース１１６内の最も古いブロック１２０の位置を識別するマーカである。図１Ａでは、最小高さ１６４は、状態Ｌ １２０Ｌに現在対応し、より多くのブロックがブロックチェーンに追加され、状態１２０が状態データベース１２４に追加されるときに、上向きに調整される。

（Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃにおいて実施されるような）従来のブロックチェーン検証構成において、ブロック内に存在するトランザクションの検証中に、照会（シミュレーション中にトランザクションによって実行される）が、結果が同じであることを確認するために状態データベース１２４に対して実行される。これに対して、本出願は、検証を効率的に実行するために、著しく小さなデータ・セット（検証データベース１１６）をメモリ内に維持する。

トランザクション提案１０４は、状態データベース１２４に対するシミュレーション照会１１２Ａとしてシミュレーション１０８により実行される。シミュレーション１０８の間、トランザクションは、完全に実行されるが、状態データベース１２４に対するいかなる変更もコミットされない。その代わりに、それらは、バイナリ形式で記録されバンドルされる。これは、リード－ライトセットと呼ばれる。リードセットは、トランザクションによって読み出されたデータ項目およびトランザクションによって実行された照会についての情報を含む。ライトセットは、トランザクションが更新したいデータ項目についての情報を含む。

状態データベース１２４は、シミュレーション１０８にリードセット１３２を提供し、それは、後の検証のためにシミュレーション結果１３６を一時的に記憶する。一実施形態では、検証データベース１１６は、ディスクまたは他の大規模記憶装置ではなく、ブロックチェーン・ノード・メモリに提供される。別の実施形態では、検証データベース１１６は、ディスクまたは他の大規模記憶装置ではなく、ブロックチェーン・ノードＳＳＤメモリ（ソリッド・ステート・ディスク）内に提供される。

それぞれの参加しているブロックチェーン・ノードは、トランザクション１４４に署名することによってシミュレーションされたトランザクション１３６をエンドースする。署名されたトランザクション１４４は、オーダラ１４８に移送され、オーダラ１４８は、署名されたトランザクション１４４を実行順序で置く。次に、順序付けされたトランザクション１５２は、検証１５６を実行するブロックチェーン・ノードに送信される。検証１５６の間、検証照会１１２Ｂは、検証データベース１１６に提示される。検証データベース１１６は、全てのデータ項目についてのバージョン数を含む結果で応答する。結果は、シミュレーション結果１３６と比較される。それらが合致する場合、検証は成功であり、順序付けされたトランザクション１５６は、新規ブロック（図示されない）内でグループ化され、新たな状態は、コミットされた状態１６０になる。

新規ブロック１２０がブロックチェーンにコミットされるとき、それは、最新ブロック１２０として状態データベース１２４に追加され、最新ブロック１２０は、図１Ａにおける状態Ｏ １２０Ｏに対応する。新たな状態１２０もまた、最も古い状態（状態Ｌ １２０Ｌ）を削除した後、状態Ｏ １２０Ｏとして検証データベース１１６に追加される。最小高さ１６４は、状態Ｌ １２０Ｌの代わりに状態Ｍ １２０Ｍを検証データベース１１６内の最も古い状態１２０として反映するように調整される。

図１Ｂは、例としての実施形態による、ブロックチェーンを用いた状態データベース・パラメータの別の論理ネットワーク図を示す。図１Ｂを参照すると、ネットワーク１００は、状態データベース１２４を含み、状態データベース１２４は、ブロックチェーン内の各ブロックに対応する状態１２０を含む。シミュレーション１０８の間に、シミュレーション高さ１７０は、状態データベース１２４内の最新状態１２０を観測することによって、それぞれのシミュレーションするブロックチェーン・ノードにより判断される。図１Ｂに示される例では、シミュレーション高さ１７０は、状態Ｌ １２０Ｌに対応する。

その後で、新規ブロックについてのトランザクションが検証される。検証の一部として、検証高さ１７４は、再び状態データベース１２４内の最新状態１２０を観測することによって、それぞれの検証するブロックチェーン・ノードにより判断される。図１Ｂに示される例では、検証高さ１７４は、状態Ｎ １２０Ｎに対応する。シミュレーションに続くある時に検証が発生するため、追加のブロックは、状態データベース１２４内のより多くの対応する状態１２０で、ブロックチェーンにコミットされてもよい。したがって、図１Ｂに示されるように、検証の間状態データベース１２４内にはＮ個の状態１２０Ｎが存在するが、シミュレーションの間はＬ個の状態１２０Ｌが存在する。

図２Ａは、例としての実施形態による、ブロックチェーン・アーキテクチャ構成２００を示す。図２Ａを参照すると、ブロックチェーン・アーキテクチャ２００は、あるブロックチェーン要素、例えばブロックチェーン・ノードのグループ２０２を含み得る。ブロックチェーン・ノード２０２は、１つまたは複数のノード２０４～２１０を含み得る（これらのノードは単なる例として示されている）。これらのノードは、ブロックチェーン・トランザクション追加および検証プロセス（合意）などのいくつかの活動に参加する。ブロックチェーン・ノード２０４～２１０のうちの１つまたは複数は、トランザクションをエンドースしてもよく、アーキテクチャ２００内の全てのブロックチェーン・ノードに順序付けサービスを提供し得る。ブロックチェーン・ノードは、ブロックチェーン認証を開始し、ブロックチェーン層２１６に記憶されるブロックチェーン不変性台帳に書き込みしようとしてもよく、そのコピーもまた、支持物理インフラストラクチャ２１４上に記憶され得る。ブロックチェーン構成は、１つまたは複数のアプリケーション２２４を含んでもよく、アプリケーション２２４は、記憶されたプログラム／アプリケーション・コード２２０（例えば、チェーンコード、スマート・コントラクトなど）にアクセスし実行するために、アプリケーション・プログラミング・インターフェース（ＡＰＩ）２２２にリンクされる。プログラム／アプリケーション・コード２２０は、参加者によって求められるカスタマイズされた構成に従って生成されてもよく、それ自体の状態を維持し、それ自体の資産を制御し、外部情報を受信し得る。これは、トランザクションとして展開され、分散型台帳に付加することによって、全てのブロックチェーン・ノード２０４～２１０上にインストールされ得る。

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

図２Ａのブロックチェーン・アーキテクチャ構成は、公開された１つまたは複数のインターフェースおよび提供されるサービスを介して、ブロックチェーン・プラットフォーム２１２によってプログラム／アプリケーション・コード２２０を処理および実行し得る。コード２２０は、ブロックチェーン資産を制御し得る。例えば、コード２２０は、データを記憶および移転してもよく、スマート・コントラクトの形態でノード２０４～２１０によって実行されてもよく、その実行の影響を受ける条件または他のコード要素とチェーンコードを関連付けられてもよい。非限定的な例として、スマート・コントラクトは、変更、更新などの影響を受けるリマインダ、更新、または他の通知、あるいはそれらの組み合わせを実行するために生成され得る。スマート・コントラクト自体は、認可およびアクセス要件、ならびに台帳の使用に関連するルールを識別するために使用され得る。例えば、遮断されるシミュレーション照会２２６は、ブロックチェーン層２１６に含まれる１つまたは複数の処理エンティティ（例えば、仮想機械）によって処理され得る。シミュレーション結果２２８は、状態データベース１２４のシミュレーション高さ１７０を含み得る。物理インフラストラクチャ２１４は、本明細書で説明されるデータまたは情報のいずれかを取り出すために利用され得る。

チェーンコード内で、スマート・コントラクトは、高レベル・アプリケーションおよびプログラミング言語を介して生成されてもよく、次いでブロックチェーン内のブロックに書き込まれてもよい。スマート・コントラクトは、ブロックチェーン（例えば、ブロックチェーン・ピアの分散型ネットワーク）を用いて登録される、記憶される、または複製される、あるいはそれらの組み合わせである実行可能コードを含み得る。トランザクションは、スマート・コントラクトに関連付けられた条件が満たされていることに応答して実行され得るスマート・コントラクト・コードの実行である。スマート・コントラクトの実行は、デジタル・ブロックチェーン台帳の状態に対する信頼性のある修正をトリガし得る。スマート・コントラクト実行により生じるブロックチェーン台帳への修正は、１つまたは複数の合意プロトコルを通してブロックチェーン・ピアの分散型ネットワーク全体で自動的に複製され得る。

スマート・コントラクトは、キーバリュー・ペアのフォーマットでブロックチェーンにデータを書き込み得る。さらに、スマート・コントラクト・コードは、ブロックチェーンに記憶された値を読み出し、アプリケーション動作においてそれらを使用し得る。スマート・コントラクト・コードは、様々な論理演算の出力をブロックチェーン内に書き込み得る。コードは、仮想機械または他のコンピューティング・プラットフォームにおいて一時データ構造を生成するために使用され得る。ブロックチェーンに書き込まれたデータは、公開であってもよく、または秘密として暗号化され維持されてもよく、あるいはその両方であってもよい。スマート・コントラクトによって使用され／生成される一時データは、供給される実行環境によってメモリ内に保持され、次いでブロックチェーンに必要なデータが識別された時点で削除される。

チェーンコードは、追加の特徴と共に、スマート・コントラクトのコード解釈を含み得る。本明細書で説明されるように、チェーンコードは、コンピューティング・ネットワーク上に展開されるプログラム・コードであってもよく、そこで、チェーンコードは合意プロセス中にチェーン・バリデータによって共に実行され検証される。チェーンコードは、ハッシュを受信し、以前記憶された特徴抽出器の使用により生成されるデータ・テンプレートに関連付けられたハッシュをブロックチェーンから取り出す。ハッシュ識別子のハッシュと記憶された識別子テンプレート・データから生成されるハッシュとが合致する場合、チェーンコードは、認可キーを要求されたサービスに送信する。チェーンコードは、暗号の詳細に関連するブロックチェーン・データに書き込み得る。図２Ａにおいて、状態データベース１２４に対するシミュレーション照会は、ボックス２２６において遮断される。１つの機能は、ボックス２２８内にシミュレーション高さを含むシミュレーション結果を提供することであってもよく、シミュレーション結果は、ノード２０４～２１０のうちの１つまたは複数に提供され得る。

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

再び図２Ｂを参照すると、クライアント・ノード２６０は、ピア・ノード２８１への要求を構築し送信することによって、トランザクション２９１を開始する。ピア・ノード２８１は、エンドーサである。クライアント２６０は、ＮＯＤＥ、ＪＡＶＡ（登録商標）、ＰＹＴＨＯＮなどのサポートされるソフトウェア開発キット（ＳＤＫ）を活用するアプリケーションを含んでもよく、それは、利用可能なＡＰＩを利用してトランザクション提案を生成する。データが読み出され得る、または台帳に書き込まれ得る（資産についての新たなキーバリュー・ペアを書き込む）、あるいはその両方であるように、提案は、チェーンコード関数を呼び出すための要求である。ＳＤＫは、トランザクション提案を適切に設計されたフォーマット（例えば、リモート・プロシージャ・コール（ＲＰＣ）上のプロトコル・バッファ）にパッケージ化し、トランザクション提案についての一意の署名を作り出すためにクライアントの暗号による信用証明書を取るためのシム（Ｓｈｉｍ）の役割をし得る。Ｊａｖａ（登録商標）およびＪａｖａ（登録商標）に基づく商標およびロゴは、Ｏｒａｃｌｅまたはその関連会社、あるいはその両方の商標または登録商標である。

それに応答して、エンドーシング・ピア・ノード２８１は、（ａ）トランザクション提案がうまく形成されること、（ｂ）トランザクションが既に過去にサブミットされていないこと（リプレイ・アタック防御）、（ｃ）署名が有効であること、（ｄ）サブミッタ（例におけるクライアント２６０）が提案された動作をそのチャネル上で実行するように適切に認可されていること、を確認し得る。エンドーシング・ピア・ノード２８１は、呼び出されたチェーンコード関数への引数としてトランザクション提案入力を取り得る。チェーンコードは、次いで、応答値、リードセット、およびライトセットを含むトランザクション結果を作り出すために現在の状態データベースに対して実行される。しかしながら、この時点では台帳に更新は行われない。２９２において、値のセットは、エンドーシング・ピア・ノード２８１の署名と共に、消費するアプリケーションについてのペイロードを解析するクライアント２６０のＳＤＫに提案応答２９２として渡される。

それに応答して、クライアント２６０のアプリケーションは、エンドーシング・ピアの署名を検査／確認し、提案応答が同一であるかどうかを判断するために提案応答を比較する。チェーンコードが台帳に照会のみをした場合、アプリケーションは、クエリ応答を検査し、典型的には順序付けノード・サービス２８４にトランザクションをサブミットしない。クライアント・アプリケーションが、台帳を更新するために順序付けノード・サービス２８４にトランザクションをサブミットする予定である場合、指定されたエンドースメント・ポリシーがサブミットの前に満たされている（即ち、トランザクションに必要な全てのピア・ノードがトランザクションをエンドースした）かどうかを、アプリケーションが判断する。ここで、クライアントは、トランザクションに対する複数の当事者のうちの１つだけを含み得る。この場合、各クライアントが、それ自体のエンドーシング・ノードを有してもよく、各エンドーシング・ノードは、トランザクションをエンドースする必要がある。アーキテクチャは、アプリケーションが、応答を検査しないように選択するか、またはエンドースされていないトランザクションを転送する場合であっても、エンドースメント・ポリシーが依然としてピアによって施行され、コミット検証段階において支持されるようにする。

検査成功後、ステップ２９３において、クライアント２６０は、エンドースメントをトランザクション内に集め、トランザクション・メッセージ内のトランザクション提案および応答を順序付けノード２８４にブロードキャストする。トランザクションは、リードセット／ライトセット、エンドーシング・ピアの署名、およびチャネルＩＤを含み得る。順序付けノード２８４は、その動作を実行するためにトランザクションの内容全体を検査する必要はなく、その代わりに、順序付けノード２８４は、ネットワーク内の全てのチャネルからトランザクションを単に受信し、チャネルによって時系列にそれらを順序付けし、チャネル毎にトランザクションのブロックを生成し得る。

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

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

ブロックチェーン開発者システム３１６は、チェーンコードおよびクライアント側アプリケーションを書き込む。ブロックチェーン開発者システム３１６は、ＲＥＳＴインターフェースを通してネットワークに直接チェーンコードを展開し得る。従来のデータ・ソース３３０からの信用証明書をチェーンコードに含めるために、開発者システム３１６は、帯域外接続を使用して、データにアクセスし得る。この例では、ブロックチェーン・ユーザ３０２は、ピア・ノード３１２を通してネットワークに接続する。任意のトランザクションを続行する前に、ピア・ノード３１２は、証明書権限３１８からユーザの登録およびトランザクション証明書を取り出す。いくつかの場合において、ブロックチェーン・ユーザは、許可型ブロックチェーン・ネットワーク３１０上で取引するために、これらのデジタル証明書を所有しなければならない。一方、チェーンコードを駆動しようとするユーザは、従来のデータ・ソース３３０上で彼らの信用証明書を確認することを必要とされ得る。ユーザの認可を確かめるために、チェーンコードは、従来の処理プラットフォーム３２０を通してこのデータへの帯域外接続を使用し得る。

図４は、例としての実施形態による、ブロックチェーン状態シミュレーションおよび検証を実行するためのシステム・メッセージング図を示す。図４を参照すると、システム図４００が、１つまたは複数のブロックチェーン・ノード４１０、状態データベース４２０、および検証データベース４３０を含む。状態データベース４２０は、概して、ブロックチェーン・ノード４１０によってアクセスされるディスクベースの記憶デバイス上に記憶されるが、検証データベース４３０は、概してブロックチェーン・ノード４１０によって制御されるシステムＲＡＭまたはソリッド・ステート・デバイス（ＳＳＤ）を含む半導体ベースの記憶デバイス上に記憶される。半導体ベースの記憶デバイスは、ディスクベースの記憶デバイスよりも高速の性能特性を有すると知られている。

ブロックチェーン・ノード４１０は、まず、検証データベース４３０を生成する。状態情報は、状態データベース４２０から検証データベース４３０に移送４１６される。状態情報４１６は、ブロックチェーンについての所定の数の直近ブロックに対応する。検証データベース４３０が開設されると、ブロックチェーン・ノード４１０は、ブロックチェーン・トランザクション４２５を受信し得る。ブロックチェーンについての直近ブロックの所定の数は、検証データベース４３０に割り当てられることが可能なメモリ量、メモリの性能、メモリと比較した状態データベース４２０の性能、および新規ブロックを生成するのに影響があり得るタイミング要件に依存する変数である。

検証データベース４３０は、最小高さ１６４を含み、最小高さ１６４は、検証データベース４３０において利用可能なデータを有する最も古いブロック（即ち、最も古い状態１２０）の高さである。ブロックチェーン・ノード４１０は、各トランザクションのシミュレーション高さが検証データベース４３０に維持されるデータに対応する最小高さ１６４以上であることを確認することによって、新規ブロック内の各トランザクションが検証データベース４３０を用いて検証され得ると判断する。

トランザクション４２５を受信することに応答して、ブロックチェーン・ノード４１０は、トランザクション４３５をシミュレーションする。ブロックチェーン・ノード４１０が状態データベース４２０への照会４３６を遮断し、ブロックチェーン・ノード４１０へのシミュレーション結果４３７をレビューするときに、トランザクションはシミュレーションされる。一実施形態では、ブロックチェーン・ノード４１０は、各シミュレーションされたトランザクション４３５についてブロックチェーン高さを判断する。ブロックチェーン高さは、シミュレーション時点におけるブロックチェーン内のブロックの数であり、シミュレーション高さ１７０をブロックチェーン高さの最小値として設定する。別の実施形態では、ブロックチェーン・ノード４１０は、シミュレーション高さ１７０を複数のトランザクションについての最小ブロックチェーン高さとして設定する。別の実施形態では、ブロックチェーン・ノード４１０は、各シミュレーションされるトランザクションについてブロックチェーン高さを判断し、各シミュレーションされるトランザクションについて状態データベース１２４に対する１つまたは複数の照会を遮断し、１つまたは複数のデータ・バージョンを取得し、１つまたは複数のデータ・バージョンの最大データ・バージョンをシミュレーション高さ１７０として選択する。

次に、ブロックチェーン・ノード４１０は、トランザクション４４０を検証する。ブロックチェーン・ノード４１０は、検証データベース４３０から検証データ４４１を要求し、検証データベースは、それに応答して検証結果４４２を提供する。検証４４０は、シミュレーション４３５の間に状態データベース・スナップショットの識別を記録することと、シミュレーション４３５と検証４４０との間で状態データベース４２０に差異があるかどうかを検出することと、を含む。検証４４０の間、ブロックチェーン・ノード４１０は、状態データベース４２０内のファントム項目（phantom item）を識別し、トランザクションについて１つまたは複数のファントム項目を識別することに応答して、トランザクションを無効として記録する。ファントム項目は、反復される項目である。

シミュレーション結果４３７が検証結果４４２と一貫している場合、ブロックチェーン・ノード４１０は、ブロックチェーンへの状態更新をコミットする。トランザクションは、ブロック（図示せず）に記憶され、状態データベースは、更新４５１され、検証データベースは、更新４５２される。ブロックチェーン・ノード４１０は、新規ブロック内の有効トランザクションについての書き込みを状態データベース４２０および検証データベース４３０の両方へ更新として適用し、検証データベース４３０内の最も古いブロックに対応するデータを削除し、検証データベース４３０に維持されるデータに対応するブロックを反映するように最小高さ１６４を調整する。状態データベース４２０、検証データベース４３０、およびブロックがコミットされた更新を含むと、コミット段階が完了する。

図５Ａは、例としての実施形態による、ブロックチェーンにおいて検証データベースを用いてトランザクションをシミュレーションおよび検証する例としての方法のフロー図５００を示す。図５Ａを参照すると、方法５００は、示されるステップのうちの１つまたは複数を含み得る。ブロック５０４において、ブロックチェーン・ノードは、検証データベース１１６を生成する。検証データベース１１６は、ブロックチェーンのための状態データベース１２４から生成され、所定の数の直近ブロックに対応する状態情報を含む。検証データベース１１６は、状態データベース１２４よりも高速なメモリに記憶され、それによって、従来のシステムよりも高速なトランザクション検証がもたらされる。

ブロック５０８において、受信されるトランザクションは、ブロックチェーン・ノードによってシミュレーションされる。状態データベース１２４に対する照会は遮断され、データ項目についての情報が、照会の結果として返される。一実施形態において、データ項目は、１つまたは複数のトランザクションについてのシミュレーション高さを含み得る。シミュレーション高さは、トランザクションのシミュレーション時点におけるブロックチェーン内のブロック数に対応する。

ブロック５１２において、ブロックチェーン・ノードは、各トランザクションが検証データベース１１６を用いて検証され得ると判断する。これは、検証データベース１１６が、より大きな、かつ低速の状態データベース１２４の代わりにトランザクション検証のために使用されることを可能にし、それがより少ないトランザクション検証時間をもたらす。

ブロック５１６において、新規ブロック内の各トランザクションは、検証データベース１１６を用いて検証される。一実施形態では、検証は、検証高さ１７４とシミュレーション高さ１７０とを比較することを含み、検証高さ１７４は、検証時点におけるブロックチェーン内のブロック数に対応する。

ブロック５２０において、新たに検証されたブロックが、ブロックチェーンにコミットされる。状態データベース１２４は、新規ブロックに対応して付加された新たな状態１２０を有する。新規ブロックに対応する新たな状態１２０が検証データベース１１６に追加される一方で、検証データベースにおける最も古い状態１２０は、削除される。これは、所定の数の直近ブロックに対応するいくつかの状態１２０を記憶するように検証データベース１１６を維持する。最後に、最小高さ１６４のパラメータが、検証データベース１１６における最も古い状態１２０の高さを反映するように更新される。

図５Ｂは、例としての実施形態による、ブロックチェーンにおいて分岐チェーン検証を解決する例としての方法のフロー図５５０を示す。図５Ｂを参照すると、方法５５０は、また、以下のステップのうちの１つまたは複数を含み得る。

ブロック５５４において、ブロックチェーン・ネットワークは、ブロックチェーンに分起点を生成する新規ブロックを識別する。アプリケーションが複数の有効トランザクション履歴または分岐チェーンの間で選択しなければならないとき、合意ソフトウェア・アプリケーションのユーザは、典型的には警告される。これは、分岐するブロックチェーンの存在が、二重使用の目的でトランザクション履歴を変更するための他のユーザによる意図的な攻撃を示し得るためである。

ブロック５５８において、ブロックチェーン・ネットワークは、ブロックチェーン検証権限（validating authority）の制限されたセットを定義する。ブロックチェーン検証権限（ＶＡ）の制限されたセットは、ブロックが作り出された時点で各ブロックについて定義され、これらの検証権限は、そのブロックを起点とする任意の分岐点の曖昧性を回避するために使用される。

ブロック５６２において、ブロックチェーン・ネットワークは、検証権限のパーセンテージに基づいて分岐チェーンを評価する。検証権限のセット内の各検証権限は、完全な検証権限セットのうちの結合された権限の指定パーセンテージを占めるように理解され得る。分岐チェーンは、各分岐チェーンを承認している検証権限のパーセンテージによって評価される。

ブロック５６６において、ブロックチェーン・ネットワークは、最高パーセンテージを有する分岐チェーンを合意チェーンとして割り当てる。検証権限承認のパーセンテージは、分岐チェーンの幅と呼ばれ得る。最高パーセント承認を有する分岐チェーンは、最も幅の広いチェーンと考えられ、（チェーンが全ての他の合意ルールに従うと仮定して）合意チェーンとして受け取られる。分岐点を評価し、かつ特定の権限が分岐チェーンに署名しているとき、同一権限を有する同一の分岐チェーンに再び署名することによって、幅は増加しない。

ブロック５７０において、ブロックチェーン・ネットワークは、検証権限のサブセットを用いて新規ブロックを検証する。検証権限リストは、最高ランクの選択されたブロック署名者の小さなグループのように小さくてもよい。検証権限リストが小さいことによって、分岐点を比較する際のチェックがより速くなり、台帳への変更を確認するのがより早くなり、結果としてより高速のトランザクション／ブロック検証がもたらされる。

図６Ａは、例としての実施形態による動作の例としての方法のうちの１つまたは複数に従って、ブロックチェーン上の様々な動作を実行するように構成される例としての物理インフラストラクチャを示す。図６Ａを参照すると、例としての構成６００Ａは、ブロックチェーン６２０およびスマート・コントラクト６３０を有する物理インフラストラクチャ６１０を含み、それは、例としての実施形態のうちのいずれかに含まれる動作ステップ６１２のいずれかを実行し得る。ステップ／動作６１２は、１つまたは複数のフロー図またはロジック図あるいはその両方において説明され、または示されるステップのうちの１つまたは複数を含み得る。ステップは、コンピュータ・システム構成の物理インフラストラクチャ６１０上に存在する、１つまたは複数のスマート・コントラクト６３０またはブロックチェーン６２０あるいはその両方に書き込まれ、または読み出される、出力または書き込み情報を表し得る。データは、実行されたスマート・コントラクト６３０またはブロックチェーン６２０あるいはその両方から出力され得る。物理インフラストラクチャ６１０は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリ、または無線通信デバイス、あるいはそれらの組み合わせを含み得る。

図６Ｂは、例としての実施形態による、ブロックチェーン上のスマート・コントラクト条件を施行するように構成される契約当事者と仲介サーバとの間の例としてのスマート・コントラクト構成を示す。図６Ｂを参照すると、構成６５０は、１つまたは複数のユーザ・デバイス６５２または６５６あるいはその両方を明示的に識別するスマート・コントラクト６３０によって駆動される、通信セッション、資産移転セッション、またはプロセスもしくは手続きを表し得る。実行、動作、およびスマート・コントラクト実行の結果が、サーバ６５４によって管理され得る。スマート・コントラクト６３０の内容は、スマート・コントラクト・トランザクションに対する当事者であるエンティティ６５２および６５６のうちの１つまたは複数によるデジタル署名を必要とし得る。スマート・コントラクト実行の結果は、ブロックチェーン・トランザクションとしてブロックチェーンに書き込まれ得る。

上記実施形態は、ハードウェアにおいて、プロセッサにより実行されるコンピュータ・プログラムにおいて、ファームウェアにおいて、または上記の組み合わせにおいて実施され得る。コンピュータ・プログラムは、記憶媒体などのコンピュータ可読媒体上で具現化され得る。例えば、コンピュータ・プログラムは、ランダム・アクセス・メモリ（「ＲＡＭ」）、フラッシュ・メモリ、読み出し専用メモリ（「ＲＯＭ」）、消去可能プログラマブル読み出し専用メモリ（「ＥＰＲＯＭ」）、電気的消去可能プログラマブル読み出し専用メモリ（「ＥＥＰＲＯＭ（登録商標）」）、レジスタ、ハード・ディスク、リムーバブル・ディスク、コンパクト・ディスク読み出し専用メモリ（「ＣＤ－ＲＯＭ」）、または当技術分野において既知の任意の他の形態の記憶媒体に存在し得る。

プロセッサが記憶媒体から情報を読み出し、かつ情報を書き込み得るように、例示的記憶媒体は、プロセッサに連結され得る。代替的には、記憶媒体が、プロセッサと一体であってもよい。プロセッサおよび記憶媒体は、特定用途向け集積回路（「ＡＳＩＣ」）に存在してもよい。代替的には、プロセッサおよび記憶媒体は、個別のコンポーネントとして存在してもよい。例えば、図７は、例としてのコンピュータ・システム・アーキテクチャ７００を示し、それは、上述したコンポーネントのうちのいずれかを表してもよく、または上述したコンポーネントのうちのいずれかにおいて一体化されてもよい、などである。

図７は、本明細書で説明されるアプリケーションの実施形態の使用または機能性の範囲に関するいかなる限定も示唆することを意図しない。それにかかわらず、コンピューティング・ノード７００は、実装されること、または上述した機能性のいずれかを実行すること、あるいはその両方が可能である。

コンピューティング・ノード７００には、コンピュータ・システム／サーバ７０２が存在し、コンピュータ・システム／サーバ７０２は、多数の他の汎用または専用コンピューティング・システム環境または構成を用いて動作可能である。コンピュータ・システム／サーバ７０２を用いた使用に適当であり得る周知のコンピューティング・システム、環境、または構成、あるいはそれらの組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式またはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル家電、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記システムまたはデバイスのいずれかを含む分散型クラウド・コンピューティング環境などを含むが、これらに限定されない。

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

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

バスは、メモリ・バスまたはメモリ・コントローラ、周辺バス、高速グラフィック・ポート、および多様なバス・アーキテクチャのいずれかを使用するプロセッサまたはローカル・バスを含む、複数種類のバス構造のいずれかの１つまたは複数を表す。限定ではなく例として、そのようなアーキテクチャは、インダストリ・スタンダード・アーキテクチャ（ＩＳＡ）・バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）・バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）・ローカル・バス、およびペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）・バスを含む。

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

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

当業者に理解されるように、本出願の態様は、システム、方法、またはコンピュータ・プログラム製品として具現化され得る。したがって、本出願の態様は、完全なハードウェア実施形態、完全なソフトウェア実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書で「回路」、「モジュール」、もしくは「システム」と全て概して呼ばれ得るソフトウェアおよびハードウェア態様を組み合わせた実施形態の形態を取ってもよい。さらに、本出願の態様は、その上で具現化されるコンピュータ可読プログラム・コードを有する、１つまたは複数のコンピュータ可読媒体において具現化されるコンピュータ・プログラム製品の形態を取ってもよい。

コンピュータ・システム／サーバ７０２は、また、キーボード、ポインティング・デバイス、ディスプレイ７２２などの１つもしくは複数の外部デバイス７２０、ユーザがコンピュータ・システム／サーバ７０２と対話することを可能にする１つもしくは複数のデバイス、またはコンピュータ・システム／サーバ７０２が１つもしくは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（例えば、ネットワーク・カード、モデムなど）、あるいはそれらの組み合わせと通信し得る。このような通信は、Ｉ／Ｏインターフェース７２４を介して発生し得る。さらに、コンピュータ・システム／サーバ７０２は、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用ワイド・エリア・ネットワーク（ＷＡＮ）、または公衆ネットワーク（例えば、インターネット）、あるいはそれらの組み合わせなどの１つまたは複数のネットワークと、ネットワーク・アダプタ７２６を介して通信し得る。図示されるように、ネットワーク・アダプタ７２６は、バスを介してコンピュータ・システム／サーバ７０２の他のコンポーネントと通信する。図示されないが、他のハードウェア・コンポーネントまたはソフトウェア・コンポーネント、あるいはその両方が、コンピュータ・システム／サーバ７０２と併せて使用され得ると理解されるべきである。例は、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ記憶システムなどを含むが、これらに限定されない。

システム、方法、および非一過性コンピュータ可読媒体のうちの少なくとも１つの例としての実施形態は、添付図面に示され、前述の詳細な説明に記載されているが、本出願は、開示される実施形態に限定されず、以下の特許請求の範囲によって明記され定義されるように、多数の再配列、修正、および代用が可能であると理解されたい。例えば、様々な図面のシステムのケイパビリティは、本明細書に説明されるモジュールもしくはコンポーネントのうちの１つもしくは複数によって、または分散型アーキテクチャにおいて実行されてもよく、送信機、受信機、またはその両方の対を含んでもよい。例えば、個々のモジュールによって実行される機能性の全てまたは一部が、これらのモジュールのうちの１つまたは複数によって実行され得る。さらに、本明細書に説明される機能性は、様々な時に、かつ様々なイベントに関連して、モジュールまたはコンポーネントの内部または外部で実行され得る。また、様々なモジュール間で送信される情報は、データ・ネットワーク、インターネット、音声ネットワーク、インターネット・プロトコル・ネットワーク、無線デバイス、有線デバイスのうちの少なくとも１つを介して、または複数のプロトコルを介して、あるいはその両方を介して、モジュール間で送信され得る。また、モジュールのいずれかによって送信または受信されるメッセージは、直接、または他のモジュールの１つもしくは複数を介して、あるいはその両方で、送信または受信され得る。

「システム」は、パーソナル・コンピュータ、サーバ、コンソール、携帯情報端末（ＰＤＡ）、携帯電話、タブレット・コンピューティング・デバイス、スマートフォン、または任意の他の適当なコンピューティング・デバイス、あるいはデバイスの組み合わせとして具現化され得ると、当業者は理解するであろう。「システム」によって実行される上述の機能を提示することは、いかなる方法でも本出願の範囲を限定することを意図しておらず、多くの実施形態のうちの一例を提供することを意図している。実際に、本明細書において開示された方法、システム、および装置は、コンピューティング技術と一貫した局所型および分散型形態で実施され得る。

本明細書において説明されたシステム特徴のうちのいくつかが、より詳細にはそれらの実施の独立性を強調するために、モジュールとして提示されていることに留意すべきである。例えば、モジュールは、カスタム超大規模集積（ＶＬＳＩ）回路またはゲート・アレイ、論理チップなどのオフザシェルフ半導体、トランジスタ、または他の個別のコンポーネントを含むハードウェア回路として実施され得る。モジュールは、また、フィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ・ロジック、プログラマブル論理デバイス、グラフィック処理ユニットなどのプログラマブル・ハードウェア・デバイスにおいて実施され得る。

モジュールは、また、様々な種類のプロセッサによる実行のためにソフトウェアにおいて少なくとも部分的に実施され得る。実行可能コードの識別されるユニットは、例えば、オブジェクト、手続き、または関数として組織され得るコンピュータ命令の１つまたは複数の物理または論理ブロックを含み得る。それにもかかわらず、識別されるモジュールの実行可能ファイルは、物理的に共に位置されなくともよいが、論理的に接合されるときに、モジュールを含み、モジュールについての述べられた目的を達成する、異なる位置に記憶された別個の命令を含んでもよい。さらに、モジュールは、コンピュータ可読媒体上に記憶されてもよく、コンピュータ可読媒体は、例えば、ハード・ディスク・ドライブ、フラッシュ・デバイス、ランダム・アクセス・メモリ（ＲＡＭ）、テープ、またはデータを記憶するために使用される任意の他のそのような媒体であってもよい。

実際に、実行可能コードのモジュールは、単一の命令または多数の命令であってもよく、複数の異なるコード・セグメントにわたって、異なるプログラムの間に、かつ複数のメモリ・デバイスにわたって分散されてもよい。同様に、動作データは、モジュール内において本明細書に識別され、例示されてもよく、任意の適当な形態で具現化され、任意の適当な種類のデータ構造内に編成されてもよい。動作データは、単一のデータ・セットとして収集されてもよく、または異なる記憶デバイスを含む異なる位置にわたって分散されてもよく、かつ単にシステムまたはネットワーク上の電子信号として少なくとも部分的に存在してもよい。

本出願のコンポーネントは、本明細書において概して説明され図面に示されるように、多種多様な異なる構成において配列され設計され得ると、容易に理解されるであろう。したがって、実施形態の詳細な説明は、特許請求されているように本出願の範囲を限定することを意図しておらず、単に本出願の選択された実施形態を表している。

上記は、異なる順序のステップで実施されてもよく、または開示されたものとは異なる構成におけるハードウェア要素で実施されてもよく、あるいはその両方であってもよいと、当業者は容易に理解するであろう。したがって、本出願は、これらの好適な実施形態に基づいて説明されているが、ある修正、変形、および代替的な構造が明らかであることが、当業者には明らかであろう。

本出願の好適な実施形態が説明されてきたが、説明された実施形態が単なる例示であり、本出願の範囲は、均等物およびそれに対する修正（例えば、プロトコル、ハードウェア・デバイス、ソフトウェア・プラットフォームなど）の全範囲と共に考慮されるときに、添付の特許請求の範囲のみによって定義されるものと理解されるべきである。

Claims (16)

1. 方法であって、
   ブロックチェーン・ノードが、メモリ内に検証データベースを生成するステップであって、前記検証データベースが、ブロックチェーンのための状態データベースの一部から得られる、前記ブロックチェーンの所定の数の直近ブロックに対応する状態データを含む、前記生成するステップと、
   前記ブロックチェーン・ノードが、１つまたは複数のトランザクションのそれぞれをシミュレーションするステップと、
   前記ブロックチェーン・ノードが、前記検証データベースに維持される前記状態データに対応する最も古いブロックの位置を識別する情報に基づいて、新規ブロック内の各トランザクションが前記検証データベースを用いて検証され得ると判断するステップと、
   前記ブロックチェーン・ノードが、前記検証データベースを用いて前記新規ブロック内の各トランザクションを検証するステップと、
   前記ブロックチェーン・ノードが、前記新規ブロックを前記ブロックチェーンにコミットし、前記検証データベースを更新するステップと、
   を含む、方法。
2. 前記検証データベースを生成するステップが、
   前記検証データベースに前記状態データを含めるための前記所定の数の直近ブロックを判断するステップと、
   前記ブロックチェーンの前記所定の数の直近ブロックの状態情報を、前記状態データベースから前記状態データベースが記憶される記憶媒体より高速な記憶媒体に前記状態データとして移行するステップと、
   を含む、請求項１に記載の方法。
3. 前記１つまたは複数のトランザクションのそれぞれをシミュレーションするステップが、
   それぞれのシミュレーションされたトランザクションについての前記ブロックチェーンの高さを判断するステップであって、前記ブロックチェーンの前記高さが、シミュレーション時における前記ブロックチェーン内のブロックの数に対応する、前記判断するステップと、
   シミュレーション高さを、前記ブロックチェーンの前記高さであるとして設定するステップと
   シミュレーションされたトランザクションのそれぞれについて前記状態データベースに対する１つまたは複数の照会をインターセプトするステップと、
   前記１つまたは複数の照会に応答した１つまたは複数のデータ・バージョンを取得するステップと、
   前記１つまたは複数のデータ・バージョンの最大のデータ・バージョンを前記シミュレーション高さとして選択するステップと、
   のうちの１つを含む、請求項１または２に記載の方法。
4. 前記検証データベースが、最小高さを含み、前記最小高さが、前記検証データベースに状態データを有する最も古いブロックの高さであり、前記新規ブロック内の各トランザクションが前記検証データベースを用いて検証され得ると判断するステップが、
   前記位置を識別する情報に基づくこととして、各トランザクションの前記シミュレーション高さが前記最小高さ以上であることを確認するステップを含む、請求項３に記載の方法。
5. 前記新規ブロックを前記ブロックチェーンにコミットするステップが、
   前記新規ブロック内の有効トランザクションについての書き込みを前記検証データベースおよび前記状態データベースに適用して状態を更新するステップと、
   前記検証データベースにおける最も古いブロックに対応するデータを削除するステップと、
   前記適用するステップおよび前記削除するステップの結果、前記検証データベースにおいて維持されるようになる状態データに対応する前記所定の数のブロックを反映して前記最小高さを調整するステップと、
   を含む、請求項４に記載の方法。
6. 前記ブロックチェーン・ノードが、前記検証データベースに対して検証を実行することによって検証されているトランザクションについて前記状態データベース内のファントム項目を識別するステップと、
   前記ブロックチェーン・ノードが、前記トランザクションについての１つまたは複数のファントム項目を識別するステップに応答して、トランザクションを無効として記録するステップと、
   をさらに含む、請求項５に記載の方法。
7. 前記新規ブロック内の各トランザクションを検証するステップが、
   トランザクションがシミュレーションされる間に、前記状態データベースのスナップショットの識別を記録するステップと、
   前記トランザクションのシミュレーションと後続するトランザクションの検証との間で前記状態データベースに差異があるかどうかを検出するステップと、
   を含む、請求項５または６に記載の方法。
8. システムであって、
   ブロックチェーン・ネットワークを備え、前記ブロックチェーン・ネットワークが、
   ブロックチェーン・トランザクションを検証する１つまたは複数のブロックチェーン・ノードを含み、各ブロックチェーン・ノードが、
   プロセッサと、
   前記プロセッサに連結されるメモリ・デバイスと
   を含み、前記メモリ・デバイスが、
   検証データベースを含み、前記検証データベースが、
   ブロックチェーンのための状態データベースの一部から得られる、前記ブロックチェーンの所定の数の直近ブロックに対応する状態データを含み、
   前記プロセッサが、
   １つまたは複数のトランザクションのそれぞれをシミュレーションし、
   前記検証データベースに維持される前記状態データに対応する最も古いブロックの位置を識別する情報に基づいて、新規ブロック内の各トランザクションが前記検証データベースを用いて検証され得ると判断し、
   前記検証データベースを用いて前記新規ブロック内の各トランザクションを検証し、
   前記新規ブロックを前記ブロックチェーンにコミットし、前記検証データベースを更新する
   ように構成される、システム。
9. 前記検証データベースが、前記状態データベースが記憶される記憶媒体よりも高速な記憶媒体上に記憶され、前記状態データベースが、前記ブロックチェーン内の全てのブロックに対応する状態データを記憶する、請求項８に記載のシステム。
10. 前記プロセッサによって前記１つまたは複数のトランザクションのそれぞれをシミュレーションすることは、前記プロセッサが、
    それぞれのシミュレーションされたトランザクションについての前記ブロックチェーンの高さを判断することであって、前記ブロックチェーンの前記高さが、シミュレーション時における前記ブロックチェーン内のブロックの数に対応する、前記判断することと、
    シミュレーション高さを、前記ブロックチェーンの前記高さであるとして設定することと、
    シミュレーションされたトランザクションのそれぞれについて前記状態データベースに対する１つまたは複数の照会をインターセプトすることと、
    前記１つまたは複数の照会に応答した１つまたは複数のデータ・バージョンを取得することと、
    前記１つまたは複数のデータ・バージョンの最大のデータ・バージョンを前記シミュレーション高さとして選択することと、
    のうちの１つを行うように構成されることを含む、請求項９に記載のシステム。
11. 前記検証データベースが、最小高さを含み、前記最小高さが、前記検証データベースに状態データを有する最も古いブロックの高さに対応し、前記１つまたは複数のブロックチェーン・ノードによって、前記新規ブロック内の各トランザクションが前記検証データベースを用いて検証され得ると判断することは、
    前記位置を識別する情報に基づくこととして、前記１つまたは複数のブロックチェーン・ノードが、各トランザクションの前記シミュレーション高さが前記最小高さ以上であることを確認するように構成されることを含む、請求項１０に記載のシステム。
12. 前記プロセッサが前記新規ブロックを前記ブロックチェーンにコミットすることは、前記プロセッサが、
    前記新規ブロック内の有効トランザクションについての書き込みを前記検証データベースおよび前記状態データベースに適用して状態を更新し、
    前記検証データベースの最も古いブロックに対応するデータを削除し、
    前記適用および前記削除の結果、前記検証データベースにおいて維持されるようになる状態データに対応する前記所定の数のブロックを反映して前記最小高さを調整する、
    ように構成されることを含む、請求項１１に記載のシステム。
13. 前記プロセッサが、
    トランザクションが前記検証データベースに対して検証される間に、前記状態データベース内のファントム項目を識別し、
    前記プロセッサが前記トランザクションについての１つまたは複数のファントム項目を識別することに応答して、トランザクションを無効として記録する、
    ようにさらに構成される、請求項１２に記載のシステム。
14. 前記プロセッサが前記新規ブロック内の各トランザクションを検証することは、前記プロセッサが、
    １つまたは複数のトランザクションがシミュレーションされる間に、前記状態データベースのスナップショットの識別を記録し、
    前記トランザクションのシミュレーションと後続するトランザクションの検証との間で前記状態データベースに差異があるかどうかを検出する、
    ように構成されることを含む、請求項１２または１３に記載のシステム。
15. コンピュータ・プログラムであって、請求項１ないし７のいずれか１項に記載の方法の各ステップをコンピュータに実行させるための、コンピュータ・プログラム。
16. 請求項１５に記載のコンピュータ・プログラムを記録した、コンピュータ可読記憶媒体。

Images