JP6789397B2 - コンセンサス検証方法およびデバイス - Google Patents

Description

本出願はブロックチェーン技術の分野に関し、詳細には、コンセンサス検証方法およびデバイスに関する。

ブロックチェーンネットワークは分散型台帳ネットワークとも呼ばれ、非集中化、開放性、および透明性によって特徴づけられる。各ブロックチェーンノードは、ブロックチェーンと同期する。ブロックチェーンネットワークは、ブロックチェーンノードを含む。各ブロックチェーンノードは、取引要求を始めること、および取引要求に対するコンセンサス検証に参加することの両方を行うことができる。

既存のコンセンサス検証方法は、ブロックチェーンネットワーク内の各コンセンサスノードに、取引に参加するブロックチェーンノードが取引に対する取引要求をブロードキャストするというようなものである。コンセンサスノードは、コンセンサス検証に責任があるブロックチェーンノードであり、取引要求は、取引の取引データを含む。各コンセンサスノードは、各コンセンサスノードによって行われる、取引要求に対するコンセンサス検証が成功した後、取引データをブロックチェーンに格納する。

しかし、各ブロックチェーンノードは、ブロックチェーンに格納された各取引の取引データを得るためにブロックチェーンと同期することができる。必然的に、取引に参加するブロックチェーンノードの取引データに含まれるプライバシーは、開示されやすい。

本出願の実装形態はコンセンサス検証方法およびデバイスを提供し、既存のコンセンサス検証方法を使用するときに、取引に参加するブロックチェーンノードのプライバシーが開示されやすいという問題を軽減させる。

先の技術的問題を軽減させるために、本出願の実装形態は以下のように実装される。

本出願の1つの実装形態は、コンセンサス検証方法を提供し、ここで方法は、規制ノードにより、取引要求を入手するステップであって、取引要求が、取引データ、および少なくとも1つの取引ノードの署名を含む、ステップと、取引データ、および各取引ノードの署名に基づいて、取引要求が有効であるかどうかを判断するステップと、取引要求が有効である場合、取引データに含まれる指定データに基づいてダイジェストを生成するステップと、各コンセンサスノードがコンセンサス検証を行うように、取引データに含まれるダイジェストおよび非指定データを各コンセンサスノードに送るステップと、を含む。

本出願の1つの実装形態は、コンセンサス検証デバイスを提供し、ここでデバイスは、取引要求を入手するように構成された第1の取得モジュールであって、取引要求が、取引データ、および少なくとも1つの取引ノードの署名を含む、第1の取得モジュールと、取引データ、および各取引ノードの署名に基づいて、取引要求が有効であるかどうかを判断し、取引要求が有効である場合、取引データに含まれる指定データに基づいてダイジェストを生成し、各コンセンサスノードがコンセンサス検証を行うように、取引データに含まれるダイジェストおよび非指定データを各コンセンサスノードに送るように構成された判断および処理モジュールと、を含む。

本出願の実装形態において、規制ノードには、取引要求が有効であるかどうかを検証する責任があるということが、本出願の実装形態において提供される技術的解決策からわかる。取引要求が有効である場合、規制ノードは、取引データ内の指定データに基づいてダイジェストを生成し、取引データに含まれるダイジェストおよび非指定データをコンセンサス検証のための各コンセンサスノードに送る。各コンセンサスノードは、コンセンサス検証が成功した後、ダイジェストおよび非指定データをブロックチェーンに格納する。したがって、コンセンサスノードは指定データを受け取らず、したがって指定データをブロックチェーンに格納しない。結果として、指定データは開示されない。さらにダイジェストは、ブロックチェーンに格納されない指定データが、改ざんされているかどうかを検証するために使用されることが可能である。

本出願の実装形態における技術的解決策、または既存技術における技術的解決策をさらに明確に説明するために、以下は、実装形態または既存技術を説明するために必要な添付の図面を簡単に説明する。明らかに、以下の説明における添付の図面は、本出願のいくつかの実装形態を示すにすぎないが、当業者は、それでもなお、創造的な努力をすることなく、これらの添付の図面から他の図面を導き出すことができる。

本出願の1つの実装形態による、コンセンサス検証方法を示す流れ図である。 本出願の1つの実装形態による、ブロックチェーンネットワークを示す概略図である。 本出願の1つの実装形態による、ブロックチェーンネットワークを示す概略図である。 本出願の1つの実装形態による、コンセンサス検証デバイスを示す概略図である。

本出願の実装形態は、コンセンサス検証方法およびデバイスを提供する。

本出願における技術的解決策を当業者にさらに理解させるために、以下は、本出願の実装形態における添付の図面を参照しながら、本出願の実装形態における技術的解決策を明確かつ包括的に説明する。明らかに、説明される実装形態は、本出願の実装形態のすべてではなく、いくつかにすぎない。創造的な努力なく、本出願の実装形態に基づいて当業者によって得られた他のすべての実装形態は、本出願の保護範囲に含まれる。

本出願の実装形態において提供される技術的解決策が、添付の図面を参照しながら下記で詳細に説明される。

図1は、本出願の1つの実装形態による、コンセンサス検証方法を示す流れ図である。方法は以下のステップを含む。

S101。規制ノードが取引要求を入手する。

方法は規制ノードによって行われる。規制ノードは、取引を規制する責任があるブロックチェーンノードである。規制ノードは公共の信用を有し、規制ノードによって検証されたアイテムは、ネットワーク全体の中にあるブロックチェーンノードによって承認される。

ブロックチェーンネットワークにおいて、取引に参加するブロックチェーンノードは取引ノードであり、コンセンサスに参加するブロックチェーンノードはコンセンサスノードである。ブロックチェーンノードは、取引ノードとコンセンサスノードの両方であることが可能であり、取引に参加するだけでなく、取引に対するコンセンサス検証にも参加することが可能であるということを強調する価値がある。

図2は、本出願の1つの実装形態による、ブロックチェーンネットワークを示す概略図である。図2に示されるように、黒いブロックチェーンノードは規制ノードである。白いブロックチェーンノードはコンセンサスノードである。陰がつけられたノードは取引ノードであり、コンセンサス検証に参加することもできる。

本出願の本実装形態において、取引要求は、取引データ、および少なくとも1つの取引ノードの署名を含む。取引ノードは、取引において資産を支払うブロックチェーンノードであることが可能である。取引において資産を受け入れるブロックチェーンノードは、本出願において説明される取引ノードであることも可能である。説明の容易性のために、取引ノードが、取引において資産を支払うブロックチェーンノードであるという例を使用してすることによって下記で説明が行われる。さらに本出願は、取引ノードが同時にコンセンサスノードでもあるかどうかに対して制限を課すものではない。

取引データは、取引ノードの識別情報、取引において必要な資産の詳細内容、取引において必要な資産の資産番号、および取引ノードのアカウントアドレスなどの、取引の詳細データである。

本出願の本実装形態において、取引ノードの署名は、取引データに対する取引ノードによって生成され、取引ノードが取引データを承認する証拠および記録として使用される。取引ノードが参加する取引の取引データを取引ノードが承認すると、取引の証拠および記録を後に残しておくために、取引ノードは、まず、ダイジェストアルゴリズムに基づいて取引データのダイジェストを構築し、署名アルゴリズムおよび秘密鍵を通じて取引データのダイジェストをさらに処理し、取引ノードの署名を生成することができる。

複数のダイジェストアルゴリズムが存在することができるが、ダイジェストアルゴリズムの共通の特徴は、プレーンテキストを計算することによって得られたダイジェストから、以前のプレーンテキストが逆に導き出されることが不可能であるというものである、ということに留意する価値がある。プレーンテキストに対する何らかの修正がある場合、修正後のプレーンテキストを計算することによって得られたダイジェストは、異なる可能性もある。取引データのダイジェストは、各取引を識別するための、取引データの一意の識別子として使用されることが可能であるということがわかる。したがって、取引ノードが取引データに署名する場合、このことは、取引ノードが取引データを承認することを示すことができ、したがって取引データを後で拒否することを取引ノードが妨げられることが可能である。

本出願の本実装形態において、取引要求において、取引ノードの署名は、取引データ内の、取引ノードによって使用される資産の資産番号に対応する。取引ノードは、署名を使用して、取引ノードによって使用される資産の資産番号を宣言する。取引ノードは、取引ノードの署名、および取引ノードによって使用される資産番号が、例えば「資産番号001(署名A)」といった特定のデータ構造を形成するのを可能にするか、別の方法を使用して、署名と、取引ノードによって使用される資産番号との間のマッピング関係を確立することができる。間違いなく、取引ノードの署名に対応する資産番号は、必ずしも、取引ノードによって実際に所有される資産番号ではない。言い換えると、取引ノードは、別のノードによって所有される資産番号を、不当かつ詐欺的に使用することができる。リスクを回避する方法は、取引要求の有効性を検証する以下の説明の一部である。

本出願の本実装形態において、1つの取引要求は、複数の取引ノードの署名を含むことができる。すなわち、任意の取引ノードは、取引ノードの署名を収集すること、取引要求を生成すること、および取引要求を規制ノードに送ることができる。署名を収集するための方法は、取引データが取引ノード間で順序正しく送信されること、各取引ノードが取引ノードの署名を取引データに添付すること、および最後に、取引データが送信される最後の取引ノードが取引要求を生成すること、というようなものであることが可能である。一方、取引ノードは、互いの取引ノードによって送られた署名を受け取り、その後、取引要求を生成することができる。説明の容易性のために、取引要求が複数の取引ノードの署名を含む例を使用することによって下記で説明が行われる。

S102。取引データ、および各取引ノードの署名に基づいて、取引要求が有効であるかどうかを判断し、取引要求が有効である場合、ステップS103を行うか、取引要求が無効である場合、ステップS104を行う。

本出願の本実装形態において、取引要求の有効性を検証するための複数の方法が存在する。例えば、ケース1において、規制ノードは、規制ノードによって格納される各取引ノードの信用記録に基づいて、署名する各取引ノードの信用力を採点することができ、各取引ノードの信用力の点数が所定の点数より低い場合、取引要求が無効であると判断するか、各取引ノードの信用力の点数が所定の点数以上である場合、取引要求が有効であると判断する。別の例として、ケース2において、規制ノードは一方で、取引データ、各取引ノードの署名、および各取引ノードの公開鍵を使用して、取引ノードが、取引データを改ざんしているか、別の人物の資産を詐欺的に使用しているかを検証することができる。間違いなく、取引要求の有効性を検証する他のケースが存在することが可能である。詳細は、簡略化のために、ここでは省略される。

ケース2において、規制ノードは、各取引ノードの公開鍵を予め保持することができ、または取引要求は、各取引ノードの公開鍵を含むことができる。各取引ノードの公開鍵は、取引ノードの署名を復号して、取引データのダイジェストを得るために使用されることが可能であり、このことにより、署名者が取引データを改ざんしているかどうかを検証する。取引ノードによって提供された公開鍵を使用することによって取引ノードの署名を復号することによって規制ノードによって得られた復号結果が取引データのダイジェストと矛盾する場合、このことは、別のブロックチェーンノードの秘密鍵を詐欺的に使用することによって取引ノードが署名を生成しているということ、または取引ノードが取引データを改ざんしているということ、およびしたがって取引要求が無効であるということを示す。取引要求の有効性は、取引ノードが取引データを改ざんしていない場合、後でさらに検証されることが可能である。

本出願の本実装形態において、その後の有効性検証は、取引ノードが別の人物の資産を詐欺的に使用しているかどうかを検証することを含むことができる。一般的なブロックチェーンネットワークにおいて、各ブロックチェーンノードによって所有される資産の資産番号は、ブロックチェーンノードの公開鍵と関連付けられ、外部に開示された識別情報の特徴としての役割を果たす、ブロックチェーンノードの公開鍵は、ブロックチェーンノードの識別情報を一意に識別することができる。言い換えると、ブロックチェーンノードの公開鍵と関連付けられた資産番号は、ブロックチェーンノードによって実際に所有される資産番号である。

したがって、本出願の本実装形態において、規制ノードは、各取引ノードの公開鍵に基づいて各取引ノードによって実際に所有される資産の資産番号を決定し、その後、取引データ内の取引ノードの署名に対応する資産番号(取引ノードによって使用される資産番号)を、取引ノードによって実際に所有される資産番号と比較して、別のブロックチェーンノードによって所有される資産番号を取引ノードが不当かつ詐欺的に使用しているかどうかを判断する。別のブロックチェーンノードによって所有される資産番号を少なくとも1つの取引ノードが不当かつ詐欺的に使用している場合、取引要求は無効である。各取引ノードによって使用される資産番号が、取引ノードによって所有される資産番号である場合、取引要求は有効である。

結論として、規制ノードが取引要求の有効性を検証するケース2において、進行式に(in a progressive way)検証が行われ、取引要求が有効であると判断するために、以下の2つの態様が連続的に確認される必要があるということがわかる。1.取引データが改ざんされていない。2.別のブロックチェーンノードによって所有される資産番号を取引ノードが詐欺的に使用していない。

S103。取引データ内のプライバシーデータに基づいてプライバシーダイジェストを生成し、各コンセンサスノードがコンセンサス検証を行うように、取引データ内のプライバシーダイジェストおよび非プライバシーデータを各コンセンサスノードに送る。

本出願の本実装形態において、指定データはプライバシーデータであることが可能であり、非指定データは非プライバシーデータであることが可能である。プライバシーデータは、取引ノードのプライバシーを含み、取引ノードによって指定され、規制ノードに通知されることが可能であり、また規制ノードによって指定されることが可能である。例えば、プライバシーデータは、取引ノードのプライバシーとみなされる取引ノードの識別情報、資産の詳細内容、およびアカウントアドレス等を含むことができる。

上述のように、プレーンテキストは、プレーンテキストのダイジェストから逆に導き出されることが不可能である。したがって、プライバシーデータに対するダイジェストが生成された後、ダイジェストは、信頼できるブロックチェーンに格納されることが可能であり、プライバシーデータは、プライバシーデータの信頼できる証拠および記録が残されることが可能なように、またプライバシーデータが保護されることが可能なように、隠されることが可能である。

ダイジェストおよび非プライバシーデータを受け取った後、各コンセンサスノードは、例えば非プライバシーデータに基づいてコンセンサス検証を行うことができ、非プライバシーデータ内の資産番号に基づいて、重複支出があるかどうかを検証することができる。コンセンサス検証が成功すると、プライバシーダイジェストおよび非プライバシーデータは、ブロックチェーンに格納される。取引要求の有効性は、規制ノードによって予め検証され、保証される。

したがって、取引に対するコンセンサス検証は完了する。ブロックチェーンに格納されたダイジェストは、取引ノード間の争いを解決するために、取引ノードによって主張されるプライバシーデータが真であるかどうかを検証するために使用されることが可能である。

本出願の本実装形態において、規制ノードは、各取引ノードの署名を各コンセンサスノードにさらに送ることができ、その結果、各コンセンサスノードによって行われる、取引に対するコンセンサス検証が成功した後、コンセンサスノードは、各取引ノードが署名を後で拒否するのを防ぐために、各取引ノードの署名もブロックチェーンに格納する。

さらに本出願の本実装形態において、規制ノードは、取引要求が有効である場合、取引データまたは取引データに含まれる指定データを格納することを少なくとも1つの取引ノードに命令することができる。間違いなく、一方、規制ノードは、各コンセンサスノードによって行われる、取引に対するコンセンサス検証が成功した後、およびダイジェストがブロックチェーンに格納された後、取引ノードに対応するプライベートデータベースに取引データまたは指定データを格納することを少なくとも1つの取引ノードに命令することができる。結論として、各取引ノードは、各取引ノード自体によって指定データまたは取引データを格納する。本出願において実装形態は限定されない。

取引ノードは、取引ノードによって格納された指定データを密かに改ざんすることができるが、ブロックチェーンに格納されたダイジェストは、指定データの信憑性を検証するためにいつでも使用され、このことにより、取引ノードによって指定データを密かに改ざんすることによって引き起こされるリスクを回避することができる。

図3は、本出願の1つの実装形態による、ブロックチェーンネットワークを示す概略図である。図に示されるように、ブロックチェーンネットワークにおいて、各ブロックチェーンノードはブロックチェーンを維持し、各ブロックチェーンノードは、ブロックチェーンノードが参加する取引のプライバシーデータを格納するための自分自身のプライベートデータベースを有する。取引Aに対して、取引Aに参加するブロックチェーンノード(取引ノード)のプライベートデータベースのみが、取引Aに対応するプライバシーデータを格納し、取引Aに参加しないブロックチェーンノード(非取引ノード)のプライベートデータベースは、取引Aに対応するプライバシーデータを格納しない。

S104。取引要求を拒否する。

図1に示されたコンセンサス検証方法によれば、規制ノードは、取引要求が有効であるかどうかを検証する責任がある。取引要求が有効である場合、規制ノードは、取引データ内の指定データに基づいてダイジェストを生成し、取引データに含まれるダイジェストおよび非指定データをコンセンサス検証のための各コンセンサスノードに送る。各コンセンサスノードは、コンセンサス検証が成功した後、ダイジェストおよび非指定データをブロックチェーンに格納する。したがって、コンセンサスノードは指定データを受け取らず、したがって指定データをブロックチェーンに格納しない。結果として、指定データは開示されない。さらにダイジェストは、ブロックチェーンに格納されない指定データが改ざんされていないかどうかを検証するために使用されることが可能である。

さらに、コンソーシアムブロックチェーンネットワークなどの特定のブロックチェーンネットワークに対して、コンソーシアムブロックチェーンネットワーク内の各ブロックチェーンノードは、証明機関によって発行されたデジタル証明書を有し、ここで、デジタル証明書は、ブロックチェーンノードの本物の識別情報を保証するために使用される。デジタル証明書は、ブロックチェーンノードの識別情報(ID)、および公開鍵を含む。重要なことには、一般的なブロックチェーンネットワークとは異なり、コンソーシアムブロックチェーンネットワークにおいて、ブロックチェーンノードによって所有される資産番号は、ブロックチェーンノードのIDと関連付けられる。

コンソーシアムブロックチェーンネットワークの応用シナリオにおいて、規制ノードは、取引ノードのデジタル証明書を入手し、取引ノードのデジタル証明書、各取引ノードの署名、および取引データに基づいて、取引要求が有効であるかどうかを判断することができる。

規制ノードは、取引ノードのデジタル証明書に含まれる公開鍵に基づいて各取引ノードの署名を復号すること、および各取引ノードに対応する復号結果が取引データのダイジェストと同じであると判断するとき、各取引ノードのデジタル証明書に含まれる識別情報に基づいて識別情報に対応する資産番号を決定すること、前記資産番号を、取引ノードによって所有される資産番号として使用すること、ならびに各取引ノードによって所有される資産番号、各取引ノードの署名、および取引データに基づいて、取引要求が有効であるかどうかを判断すること、または少なくとも1つの取引ノードに対応する復号結果が取引データのダイジェストとは異なると判断するとき、取引要求が無効であると判断することができる。

さらに規制ノードは、取引データ内の各取引ノードの署名に対応する資産番号を取引ノードの署名に基づいて決定することと、前記資産番号を、取引ノードによって使用される資産番号として使用することと、取引ノードによって所有される資産番号が、取引ノードによって使用される少なくとも1つの資産番号を含まない場合、取引ノードが無効であると判断すること、または取引ノードによって所有される資産番号が、取引ノードによって使用されるすべての資産番号を含む場合、取引ノードが有効であると判断することと、少なくとも1つの取引ノードが無効であるとき、取引要求が無効であると判断すること、またはすべての取引ノードが有効であるとき、取引要求が有効であると判断することと、が可能である。

取引ノードが有効であるということは、不当で違法な行為(別の人物の署名を詐欺的に使用すること、または別の人物の資産を詐欺的に使用することなど)を取引ノードが行っていないということを意味する。現在の取引において、取引ノードによって使用される少なくとも1つの資産番号が、取引ノードによって所有される資産番号ではないということが判断されるとき、別の人物の資産番号を詐欺的に使用する違法な行為を取引ノードが行っており、したがって無効であるとみなされることが可能である。

言い換えると、コンソーシアムブロックチェーンネットワークの応用シナリオにおいて、取引ノードは、取引ノードの公開鍵の代わりに、取引ノードのデジタル証明書を規制ノードに提供する。さらに、取引ノードによって実際に所有される資産番号は、取引ノードのIDに基づいて確認される必要がある。したがって、規制ノードが、取引要求の有効性を検証するために確認する必要がある上述の2つの態様(1.取引データが改ざんしていない。2.取引ノードが、別のブロックチェーンノードによって所有される資産番号を詐欺的に使用していない)にわずかな相違があることがある。

規制ノードは、まず、取引ノードのデジタル証明書に含まれる公開鍵に基づいて各取引ノードの署名を復号しようと試みる。復号結果が取引データのダイジェストと一致している場合、このことは、取引ノードが取引データを改ざんしていないことを示す。すべての取引ノードの識別情報が真であると判断した後、規制ノードは、取引ノードのデジタル証明書に含まれるIDに対応する資産番号(すなわち、取引ノードによって実際に所有される資産番号)に基づいて、取引データ内の各取引ノードの署名に対応する資産番号(すなわち、取引における各取引ノードによって使用される資産番号)が、取引ノードの資産番号であるかどうかを判断し続けることができる。このことは、取引ノードが別の人物の資産番号を詐欺的に使用していない場合、取引要求が有効であるということを示す。

コンソーシアムブロックチェーンネットワークの応用シナリオにおいて、取引ノードのデジタル証明書に含まれる取引ノードのIDは、実際に取引ノードのプライバシーであるということを強調する価値がある。本出願の本実装形態において、規制ノードは、取引ノードのデジタル証明書をコンセンサスノードに送らず、このことにより、取引ノードのIDが開示されないことを保証する。

図1に示されたコンセンサス検証方法に基づいて、本出願の1つの実装形態は、それに対応して、コンセンサス検証デバイスをさらに提供する。図4に示されるように、デバイスは、取引要求を入手するように構成された第1の取得モジュール401であって、取引要求が、取引データ、および少なくとも1つの取引ノードの署名を含む、第1の取得モジュール401と、取引データ、および各取引ノードの署名に基づいて、取引要求が有効であるかどうかを判断すること、ならびに取引要求が有効である場合、取引データに含まれる指定データに基づいてダイジェストを生成すること、ならびに各コンセンサスノードがコンセンサス検証を行うように、取引データに含まれるダイジェストおよび非指定データを各コンセンサスノードに送ること、を行うように構成された判断および処理モジュール402と、を含む。

デバイスは、取引要求が無効である場合、取引要求を拒否するように構成された拒否モジュール403をさらに含む。

デバイスは、取引データ、および各取引ノードの署名に基づいて、取引要求が有効であるかどうかが判断される前に、各取引ノードのデジタル証明書を入手するように構成された第2の取得モジュール404をさらに含む。

判断および処理モジュール402は、取引データ、各取引ノードの署名、および各取引ノードのデジタル証明書に基づいて、取引要求が有効であるかどうかを判断するように構成される。

判断および処理モジュール402は、取引ノードのデジタル証明書に含まれる公開鍵に基づいて各取引ノードの署名を復号すること、および各取引ノードに対応する復号結果が取引データのダイジェストと同じであると判断すると、各取引ノードのデジタル証明書に含まれる識別情報に基づいて識別情報に対応する資産番号を決定すること、前記資産番号を、取引ノードによって所有される資産番号として使用すること、ならびに各取引ノードによって所有される資産番号、各取引ノードの署名、および取引データに基づいて、取引要求が有効であるかどうかを判断すること、または少なくとも1つの取引ノードに対応する復号結果が取引データのダイジェストとは異なると判断すると、取引要求が無効であると判断すること、を行うように構成される。

判断および処理モジュール402は、取引データ内の各取引ノードの署名に対応する資産番号を取引ノードの署名に基づいて決定することと、前記資産番号を、取引ノードによって使用される資産番号として使用することと、取引ノードによって所有される資産番号が、取引ノードによって使用される少なくとも1つの資産番号を含まない場合、取引ノードが無効であると判断すること、または取引ノードによって所有される資産番号が、取引ノードによって使用されるすべての資産番号を含む場合、取引ノードが有効であると判断することと、少なくとも1つの取引ノードが無効であるとき、取引要求が無効であると判断すること、またはすべての取引ノードが有効であるとき、取引要求が有効であると判断することと、を行うように構成される。

デバイスは、取引要求が有効である場合、取引データまたは取引データに含まれる指定データを格納することを少なくとも1つの取引ノードに命令するように構成された通知モジュール405をさらに含む。

1990年代において、技術的な改良が、ハードウェア改良(例えば、ダイオード、トランジスタ、またはスイッチなどの回路構造に対する改良)であるか、ソフトウェア改良(方法手順に対する改良)であるかは、明確に区別されることが可能である。しかし、技術が発展するにつれて、多くの方法手順に対する現在の改良は、ハードウェア回路構造への直接的な改良とみなされることが可能である。設計者は通常、改良された方法手順をハードウェア回路にプログラムし、対応するハードウェア回路構造を得る。したがって方法手順は、ハードウェアエンティティモジュールを使用することによって改良されることが可能である。例えば、プログラマブルロジックデバイス(PLD:programmable logic device)(例えば、フィールドプログラマブルゲートアレイ(FPGA))はこのような集積回路であり、PLDの論理機能は、デバイスプログラミングを通じてユーザによって決定される。設計者はプログラミングを行い、特定用途向け集積回路チップを設計して製造することをチップ製造業者にリクエストすることなく、デジタルシステムをPLDに「統合する」。さらに、現在のところ、集積回路チップを手動で製造する代わりに、「ロジックコンパイラ」ソフトウェアを使用することによって、このようなプログラミングが主として実装される。ロジックコンパイラソフトウェアは、プログラムを開発するため、および書くために使用されるソフトウェアコンパイラに類似している。元のコードは、コンパイルのための特定のプログラミング言語で書かれる必要がある。言語は、ハードウェア記述言語(HDL:hardware description language)と呼ばれる。Advanced Boolean Expression Language(ABEL)、Altera Hardware Description Language(AHDL)、Confluence、Cornell University Programming Language(CUPL)、HDCal、Java(登録商標) Hardware Description Language(JHDL)、Lava、Lola、MyHDL、PALASM、およびRuby Hardware Description Language(RHDL)など、多くのHDLがある。超高速集積回路ハードウェア記述言語(VHDL:very-high-speed integrated circuit hardware description language)およびVerilogが最も一般的に使用される。いくつかの説明されたハードウェア記述言語を使用することによって方法手順が論理的にプログラムされ、集積回路にプログラムされると、論理的な方法手順を実装するハードウェア回路が容易に得られることが可能であるということも当業者は理解するはずである。

コントローラは、任意の妥当な方法を使用することによって実装されることが可能である。例えば、コントローラは、マイクロプロセッサもしくはプロセッサ、およびマイクロプロセッサもしくはプロセッサ、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブルロジックコントローラ、またはビルトインマイクロコントローラによって実行されることが可能な(ソフトウェアもしくはファームウェアなどの)コンピュータ可読プログラムコードを格納するコンピュータ可読媒体であることが可能である。コントローラの例は、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、およびSilicone Labs C8051F320などのマイクロプロセッサを含むがこれらに限定されない。メモリコントローラは、メモリの制御ロジックの一部として実装されることも可能である。コンピュータ可読プログラムコードを使用することによってコントローラを実装することの他に、ロジックプログラミングは、論理ゲート、スイッチ、特定用途向け集積回路、プログラマブルロジックコントローラ、およびビルトインマイクロコントローラの形で同じ機能をコントローラが実装できるようにするための方法ステップに対して行われることが可能であるということも当業者は知っている。したがってコントローラは、ハードウェア構成要素とみなされることが可能であり、コントローラに含まれ、様々な機能を実装するように構成されたデバイスは、ハードウェア構成要素内の構造とみなされることも可能である。または様々な機能を実装するように構成されたデバイスは、方法を実装するソフトウェアモジュールと、ハードウェア構成要素内の構造の両方とみなされることさえ可能である。

先の実装形態において示されたシステム、デバイス、モジュール、またはユニットは、コンピュータチップまたはエンティティを使用することによって実装されることが可能であり、また一定の機能を有する製品を使用することによって実装されることが可能である。典型的な実行デバイスはコンピュータである。コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、セルラー電話、カメラフォン、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、eメールデバイス、ゲーム機、タブレット型コンピュータ、ウェアラブルデバイス、またはこれらのデバイスのいずれかの組合せであることが可能である。

説明の容易性のために、上記のデバイスは、様々なユニットに機能を分割することによって説明される。間違いなく、本出願が実行されると、ユニットの機能が、1つまたは複数のソフトウェアおよび/またはハードウェアにおいて実行されることが可能である。

本開示の実装形態は、方法、システム、またはコンピュータプログラム製品として提供されることが可能であるということを当業者は理解するはずである。したがって本開示は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアの組合せによる実装形態の形式を使用することができる。さらに本開示は、コンピュータ使用可能プログラムコードを含む(ディスクメモリ、CD-ROM、光メモリ、等を含むがこれらに限定されない)1つまたは複数のコンピュータ使用可能ストレージ媒体上に実装されるコンピュータプログラム製品の形式を使用することができる。

本開示は、本開示の実装形態に基づいて、方法、デバイス(システム)、およびコンピュータプログラム製品の流れ図および/またはブロック図を参照しながら説明される。コンピュータプログラム命令は、流れ図および/またはブロック図における各処理および/または各ブロック、ならびに流れ図および/またはブロック図における処理および/またはブロックの組合せを実行するために使用されることが可能であるということに留意する価値がある。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、ビルトインプロセッサ、または機械を生成するための別のプログラマブルデータ処理デバイスのプロセッサに提供されることが可能であり、その結果、コンピュータ、または別のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行するためのデバイスを生成する。

コンピュータまたは別のプログラマブルデータ処理デバイスに、特定の方式で動くように命令することができる、これらのコンピュータプログラム命令は、コンピュータ可読メモリに格納されることが可能であり、その結果、コンピュータ可読メモリに格納された命令は、命令デバイスを含むアーチファクトを生成する。命令デバイスは、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行する。

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイス上にロードされることが可能であり、その結果、コンピュータまたは別のプログラマブルデバイス上で一連の動作ならびに動作およびステップが行われ、このことにより、コンピュータ実行処理を生成する。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、流れ図における1つもしくは複数の処理における特定の機能、および/またはブロック図における1つもしくは複数のブロックにおける特定の機能を実行するためのステップを提供する。

典型的な構成において、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。

メモリは、非持続的メモリ、ランダムアクセスメモリ(RAM)、不揮発性メモリ、および/または例えばリードオンリメモリ(ROM)もしくはフラッシュメモリ(フラッシュRAM)といった、コンピュータ可読媒体内にある別の形式を含むことができる。メモリは、コンピュータ可読媒体の例である。

コンピュータ可読媒体は、任意の方法または技術を使用することによって情報を格納することができる持続的媒体、非持続的媒体、可動媒体、および非可動媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであることが可能である。コンピュータストレージ媒体の例は、パラメータランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、電気的消去可能プログラマブルリードオンリメモリ(EEPROM)、フラッシュメモリもしくは別のメモリ技術、コンパクトディスクリードオンリメモリ(CD-ROM)、デジタル多用途ディスク(DVD)もしくは別の光ストレージ、カセット磁気テープ、磁気テープ/磁気ディスクストレージもしくは別の磁気ストレージデバイス、または他の任意の非送信媒体を含むがこれらに限定されない。コンピュータストレージ媒体は、コンピューティングデバイスによってアクセス可能な情報を格納するために使用されることが可能である。本明細書における定義に基づくと、コンピュータ可読媒体は、変調されたデータ信号および担体などの一時コンピュータ可読媒体(一時媒体)を含まない。

用語「含む(include)」、「備える(comprise)」、またはこれらの他の任意の変形物は、非排他的な包含をカバーすることを意図するものであるので、要素の一覧を含む処理、方法、製品、もしくはデバイスは、これらの要素を含むだけでなく、明確に挙げられていない他の要素も含むということ、またはこのような処理、方法、製品、もしくはデバイスに固有の要素をさらに含むということにさらに留意する価値がある。さらなる制限なく、「〜を含む(includes a ...)」の前にある要素は、要素を含む処理、方法、製品、またはデバイスにおけるさらなる同一要素の存在を排除しない。

本出願の1つの実装形態は、方法、システム、またはコンピュータプログラム製品として提供されることが可能であるということを当業者は理解するはずである。したがって本出願は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアの組合せによる実装形態の形式を使用することができる。さらに本出願は、コンピュータ使用可能プログラムコードを含む(ディスクメモリ、CD-ROM、光メモリ、等を含むがこれらに限定されない)1つまたは複数のコンピュータ使用可能ストレージ媒体上に実装されるコンピュータプログラム製品の形式を使用することができる。

本出願は、例えばプログラムモジュールといった、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明されることが可能である。一般に、プログラムモジュールは、特定のタスクを実行するか、特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。本出願は、分散コンピューティング環境において実践されることも可能である。分散コンピューティング環境において、タスクは、通信ネットワークを通じて接続されたリモート処理デバイスによって行われる。分散コンピューティング環境において、プログラムモジュールは、ストレージデバイスを含む、ローカルとリモート両方のコンピュータストレージ媒体に配置されることが可能である。

本明細書における実装形態は進行式に(in a progressive way)説明される。実装形態の同じまたは類似の部分に対して、実装形態に対する参照が行われることが可能である。各実装形態は、他の実装形態との相違を重点的に取り扱う。特に、システムの実装形態は、方法の実装形態に基本的に類似しており、したがって簡単に説明される。関連部分に対しては、方法の実装形態における関連説明に対する参照が行われることが可能である。

先の実装形態は本出願の実装形態であり、本出願を限定することを意図するものではない。当業者は、本出願に対する様々な修正および変更を行うことができる。本出願の精神および原理から逸脱することなく行われる任意の修正、同等の置換、または改良は、本出願における特許請求の範囲の範囲に含まれる。

401 第1の取得モジュール
402 判断および処理モジュール
403 拒否モジュール
404 第2の取得モジュール
405 通知モジュール

Claims (12)

1. 規制ノードにより、取引要求を入手するステップであって、前記取引要求が、取引データ、および少なくとも1つの取引ノードの署名を含む、ステップと、
   前記取引データ内の前記少なくとも1つの取引ノードの前記署名に対応する資産番号を前記署名に基づいて決定するステップと、
   前記資産番号を、前記少なくとも1つの取引ノードに割り当てるステップと、
   前記取引データ、前記署名、および前記資産番号に基づいて、前記取引要求が有効であるかどうかを判断するステップと、
   前記取引要求が有効であるという判断に応答して、前記取引データに含まれる指定データに基づいてダイジェストを生成するステップと、
   それぞれのコンセンサスノードがコンセンサス検証を行うように、前記取引データに含まれる前記ダイジェストおよび非指定データを前記それぞれのコンセンサスノードに送るステップと、
   を含む、コンセンサス検証のための方法。
2. 前記取引要求が無効であるという判断に応答して、前記取引要求を拒否するステップ
   をさらに含む、請求項1に記載の方法。
3. 前記取引要求が有効であるかどうかを判断するステップの前に、
   前記少なくとも1つの取引ノードのデジタル証明書を入手するステップ
   を含む、請求項1に記載の方法。
4. 前記取引要求が有効であるかどうかを判断するステップが、
   前記取引データ、前記少なくとも1つの取引ノードの前記署名、および前記少なくとも1つの取引ノードの前記デジタル証明書に基づいて、前記取引要求が有効であるかどうかを判断するステップ
   を含む、請求項3に記載の方法。
5. 前記取引要求が有効であるかどうかを判断するステップが、
   前記取引ノードの前記デジタル証明書に含まれる公開鍵に基づいて前記少なくとも1つの取引ノードの前記署名を復号するステップと、
   前記少なくとも1つの取引ノードに対応する復号結果が前記取引データの前記ダイジェストと同じであるという判断に応答して、前記少なくとも1つの取引ノードの前記デジタル証明書に含まれる識別情報に基づいて前記識別情報に対応する資産番号を決定するステップと、
   前記資産番号を、前記取引ノードによって所有される取引資産番号として決定するステップと、
   を含む、請求項3に記載の方法。
6. 前記少なくとも1つの取引ノードによって所有される前記資産番号、前記少なくとも1つの取引ノードの前記署名、および前記取引データに基づいて、前記取引要求が有効であるかどうかを判断するステップ、または、
   少なくとも1つの取引ノードに対応する復号結果が前記取引データの前記ダイジェストとは異なると判断するとき、前記取引要求が無効であると判断するステップ、
   をさらに含む、請求項5に記載の方法。
7. 前記取引要求が有効であるかどうかを判断するステップが、
   前記取引ノードによって所有される前記資産番号が、前記取引ノードによって使用される少なくとも1つの資産番号を含まないという判断に応答して、前記取引ノードが無効であると判断するステップ、または、
   前記取引ノードによって所有される前記資産番号が、前記取引ノードによって使用されるすべての資産番号を含むという判断に応答して、前記取引ノードが有効であると判断するステップ、
   を含む、請求項6に記載の方法。
8. 前記取引要求が有効であるかどうかを判断するステップが、
   少なくとも1つの取引ノードが無効であるという判断に応答して、前記取引要求が無効であると判断するステップ、または
   すべての取引ノードが有効であるという判断に応答して、前記取引要求が有効であると判断するステップ、
   を含む、請求項7に記載の方法。
9. 前記取引要求が有効であるという判断に応答して、前記取引データ、または前記取引データに含まれる前記指定データを格納することを前記少なくとも1つの取引ノードに命令するステップ
   をさらに含む、請求項1に記載の方法。
10. 前記規制ノードが、アイテムを検証することによって取引を規制するように構成されたブロックチェーンネットワークのノードであり、前記規制ノードによって検証されたアイテムが、前記ブロックチェーンネットワークの複数のブロックチェーンノードによって承認される、請求項1に記載の方法。
11. 前記ブロックチェーンネットワークが、コンソーシアムブロックチェーンネットワークを含む、請求項10に記載の方法。
12. 請求項1から11のいずれか一項に記載の方法を実行するように構成された複数のモジュールを備える、コンセンサス検証のためのデバイス。