(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-12-26
(54)【発明の名称】機密データのブロック
(51)【国際特許分類】
H04L 9/32 20060101AFI20231219BHJP
【ＦＩ】
H04L9/32 200C
H04L9/32 200Z
H04L9/32 200E
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023537942
(86)(22)【出願日】2021-12-22
(85)【翻訳文提出日】2023-07-19
(86)【国際出願番号】 IB2021062201
(87)【国際公開番号】W WO2022137173
(87)【国際公開日】2022-06-30
(31)【優先権主張番号】2020414.5
(32)【優先日】2020-12-22
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】キラス，メフメット サビル
(72)【発明者】
【氏名】リウ，ワイ
(72)【発明者】
【氏名】ヴォーン，オーウェン
(57)【要約】
メッセージ内の機密データをブロックする方法であって、コンピューティング装置上で実行され、前記メッセージのコピーを作成するステップと、少なくとも１つのゼロ知識証明を生成し、前記少なくとも１つのゼロ知識証明の各々を生成することは、前記コピーのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列を取得することと、前記少なくとも１つの機密ビットに所定の値を割り当てることで、前記コピーの前記ビットを変更することにより、公開ビット列を計算することと、秘密ビット列を決定することであって、前記秘密ビット列は、前記少なくとも１つの機密ビットを含み、かつ、前記コピーの前記ビットが、前記公開ビット列、前記マスクビット列及び前記秘密ビット列を用いたビットごとの論理計算の出力と等しいという要件を満たすことと、前記メッセージのコピー又はその一部をハッシングして出力ハッシュ値を生成することと、前記公開ビット列、前記マスクビット列、前記出力ハッシュ値、前記秘密ビット列を用いてゼロ知識証明を生成することと、を含む、ステップと、前記コピーから前記少なくとも１つの機密ビットの各々を削除して、変更されたメッセージを生成するステップと、前記少なくとも１つの出力ハッシュ値、及び受信者が前記変更されたメッセージが有効であることを証明できるようにするための前記少なくとも１つのゼロ知識証明とともに、前記変更されたメッセージを前記受信者に出力するステップと、を含む方法。
【特許請求の範囲】
【請求項1】
メッセージ内の機密データをブロックする方法であって、コンピューティング装置上で実行され、前記メッセージのコピーを作成するステップと、
少なくとも１つのゼロ知識証明を生成し、前記少なくとも１つのゼロ知識証明の各々を生成することは、
前記コピーのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列を取得することと、
前記少なくとも１つの機密ビットに所定の値を割り当てることで、前記コピーの前記ビットを変更することにより、公開ビット列を計算することと、
秘密ビット列を決定することであって、前記秘密ビット列は、前記少なくとも１つの機密ビットを含み、かつ、前記コピーの前記ビットが、前記公開ビット列、前記マスクビット列及び前記秘密ビット列を用いたビットごとの論理計算の出力と等しいという要件を満たすことと、
前記メッセージのコピー又はその一部をハッシングして出力ハッシュ値を生成することと、
前記公開ビット列、前記マスクビット列、前記出力ハッシュ値、前記秘密ビット列を用いてゼロ知識証明を生成することと、
を含む、ステップと、
前記コピーから前記少なくとも１つの機密ビットの各々を削除して、変更されたメッセージを生成するステップと、
前記少なくとも１つの出力ハッシュ値、及び受信者が前記変更されたメッセージが有効であることを証明できるようにするための前記少なくとも１つのゼロ知識証明とともに、前記変更されたメッセージを前記受信者に出力するステップと、
を含む方法。
【請求項2】
少なくとも１つのゼロ知識証明を生成する前に、前記コピーが、ハッシングするときに使用されるハッシュ関数によって定義される入力メッセージサイズの正の整数倍の長さを持つように、前記メッセージのコピーをパディングするステップと、前記コピーの長さが前記ハッシュ関数によって定義される前記入力メッセージサイズに対応する場合、前記メッセージのコピーをハッシングすることによって単一のゼロ知識証明が生成され、公開初期化ベクトルを使用して前記出力ハッシュ値を生成するステップと、
を更に含む請求項１に記載の方法。
【請求項3】
少なくとも１つのゼロ知識証明を生成する前に、前記コピーが、ハッシングに使用されるハッシュ関数によって定義される入力メッセージサイズの正の整数倍の長さを持つように、前記メッセージのコピーをパディングするステップ、を更に含み、パディング後の前記コピーの長さが、前記ハッシュ関数によって定義される前記入力メッセージサイズよりも大きい場合、前記方法は、
前記ハッシュ関数によって定義される前記入力メッセージサイズに対応する長さを各々持つ複数のメッセージブロックに、前記メッセージのコピーを分割するステップと、
機密データを含む１つ以上のメッセージブロックを識別するステップと、
を含み、
機密データを含む前記１つ以上のメッセージブロックの各々に対してゼロ知識証明が生成される、請求項１に記載の方法。
【請求項4】
前記少なくとも１つのゼロ知識証明のうちの１つ以上について、前記コピーのビットは、前記１つ以上のメッセージブロックのうちのメッセージブロックのビットに対応し、前記ゼロ知識証明は、前記メッセージブロックをハッシングして出力ハッシュ値を生成することによって生成される、請求項３に記載の方法。
【請求項5】
前記複数のメッセージブロックは、第１メッセージブロックと１つ以上の更なるメッセージブロックを含み、前記第１メッセージブロックが機密データを含む場合、前記第１メッセージブロックのハッシングには公開初期化ベクトルが使用され、前記更なるメッセージブロックが機密データを含む場合、前記更なるメッセージブロックのハッシングには、前記更なるメッセージブロックの直前のメッセージブロックのハッシングからの出力ハッシュ値が使用される、請求項４に記載の方法。
【請求項6】
前記複数のメッセージブロックのうちの幾つかのメッセージブロックが機密データを含み、前記方法は、前記幾つかのメッセージブロックの各々についてゼロ知識証明を並列に生成するステップ、を含む請求項３に記載の方法。
【請求項7】
前記少なくとも１つのゼロ知識証明のうちの１つについて、前記コピーのビットは、マージされたブロックのビットに対応し、前記マージされたブロックは、機密データを各々含む複数の隣接するメッセージブロックを含み、前記ゼロ知識証明は、前記マージされたブロックの中の各メッセージブロックを反復的にハッシングすることによって生成され、出力ハッシュ値は、最後のメッセージブロックの直前にある前記複数の隣接するメッセージブロックのうちのメッセージブロックのハッシングからの出力ハッシュ値を使用して、前記マージされたブロックのうちの前記最後のメッセージブロックをハッシングすることによって生成される、請求項３に記載の方法。
【請求項8】
機密データを含むメッセージブロックが、所定の閾値未満の数の機密ビットを含むことを識別するステップと、前記メッセージブロックを、機密データを含む少なくとも１つの隣接するメッセージブロックとマージして、マージされたブロックを生成するステップと、
を更に含む請求項７に記載の方法。
【請求項9】
前記所定の閾値は、前記ハッシュ関数の衝突耐性によって定義される、請求項８に記載の方法。
【請求項10】
前記秘密ビット列は、前記コピーの前記ビットが、（i）公開ビット列と（ii）前記マスクビット列と前記秘密ビット列のビット毎のAND計算の結果とのビット毎のXOR計算に等しいという要件を満たす、請求項１に記載の方法。
【請求項11】
前記マスクビット列を取得することが、メモリから前記マスクビット列を読み出すことを含む、請求項１に記載の方法。
【請求項12】
前記マスクビット列を取得することが、前記メッセージのコピーのビット内の少なくとも１つの機密ビットの位置を特定することと、
前記コピー内の前記少なくとも１つの機密ビットの位置を特定するマスクビット列を生成することと、
を含む、請求項１に記載の方法。
【請求項13】
前記少なくとも１つのマスクビット列を前記受信者に出力するステップ、を更に含む請求項１に記載の方法。
【請求項14】
前記出力するステップは、前記少なくとも１つの出力ハッシュ値、前記少なくとも１つの公開ビット列、及び前記少なくとも１つのゼロ知識証明とともに、前記受信者に関連付けられたリモート装置に前記変更されたメッセージを送信することを含む、請求項１に記載の方法。
【請求項15】
前記メッセージはブロックチェーントランザクションデータを含み、前記変更されたメッセージは変更されたブロックチェーントランザクションデータを含む、請求項１４に記載の方法。
【請求項16】
前記コンピューティング装置はブロックチェーンネットワーク内のブロックチェーンノードである、請求項１５に記載の方法。
【請求項17】
前記ブロックチェーントランザクションデータは、ブロックチェーントランザクションをブロックチェーンに記録することを要求するクライアント装置から受信され、前記リモート装置は、前記ブロックチェーンネットワーク内の更なるブロックチェーンノードであり、前記変更されたブロックチェーントランザクションデータが前記ブロックチェーンネットワーク内での伝播のために前記更なるブロックチェーンノードに送信される、請求項１６に記載の方法。
【請求項18】
前記リモート装置は前記ブロックチェーンネットワーク内の更なるブロックチェーンノードであり、前記方法は、ブロックチェーントランザクションを受信するステップと、
ブロックチェーンに記録されるべきブロックを生成するステップであって、前記ブロックは、前記変更されたブロックチェーントランザクションデータを含む、ステップと、
前記変更されたブロックチェーントランザクションデータを含む前記ブロックを前記ブロックチェーンネットワーク内の前記更なるブロックチェーンノードに送信するステップと、
を含む請求項１６に記載の方法。
【請求項19】
前記コンピューティング装置はブロックチェーンネットワークの外部にあり、前記リモート装置はクライアント装置である、請求項１５に記載の方法。
【請求項20】
ブロックチェーンに記録されたブロックを受信するステップであって、前記ブロックは前記ブロックチェーントランザクションデータを含む、ステップ、を含む請求項１６又は１９に記載の方法。
【請求項21】
前記ブロックを受信するステップに応答して、前記生成するステップ、前記削除するステップ、前記送信するステップが行われる、請求項２０に記載の方法。
【請求項22】
前記生成するステッ及び前記削除するステップは、前記ブロックを受信することに応答して行われ、前記送信するステップは、前記リモート装置からの前記ブロックに対する要求を受信することに応答して行われる、請求項２０に記載の方法。
【請求項23】
前記リモート装置からの前記ブロックに対する要求を受信するステップに応答して、前記生成するステップ、前記削除するステップ、前記送信するステップが行われる、請求項２０に記載の方法。
【請求項24】
前記少なくとも１つのゼロ知識証明がzkSNARK（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）証明である、請求項１に記載の方法。
【請求項25】
前記ゼロ知識証明を生成するステップは、証明鍵を使用することを更に含む、請求項２４に記載の方法。
【請求項26】
更に、前記変更されたメッセージの生成後、メモリから前記メッセージを削除し、前記変更されたメッセージをメモリに格納するステップ、を更に含む請求項１に記載の方法。
【請求項27】
コンピュータ可読記憶装置上に具現化されたコンピュータプログラムであって、コンピュータ機器上で実行すると請求項１に記載の方法を実行するよう構成される、コンピュータプログラム。
【請求項28】
プロセッサとメモリを含むコンピュータ装置であり、前記メモリは、前記プロセッサによって実行されると前記コンピュータ装置に請求項１に記載の方法を実行させる命令を格納している、コンピュータ装置。
【請求項29】
変更されたメッセージが有効であることを検証する方法であって、前記変更されたメッセージは元のメッセージから機密データを除去したものに対応し、前記方法は、コンピュータ装置上で実行され、前記変更されたメッセージを取得するステップであって、前記変更されたメッセージが、前記元のメッセージの各機密ビットに所定の値を割り当てたものに対応する、ステップと、
前記変更されたメッセージの出力ハッシュ値を取得し、前記コンピューティング装置のメモリに格納されたデータを使用して前記出力ハッシュ値を検証するステップと、
送信側装置から、前記変更されたメッセージのビットに関連する少なくとも１つのゼロ知識証明を受信するステップと、
以下：（i）前記ゼロ知識証明を生成するために使用された秘密ビット列を導出するために、前記送信側装置により使用された、ビットごとの論理計算の知識、又はそれに関連する検証鍵、（ii）前記変更されたメッセージのビット、（iii）前記変更されたメッセージのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列、（iv）前記変更されたメッセージのビットのハッシュ値又はその一部、及び（v）前記変更されたメッセージのビットの入力ハッシュ値、を使用して前記少なくとも１つのゼロ知識証明の各々を検証するステップと、
を含む方法。
【請求項30】
前記変更されたメッセージを取得するステップが、前記変更されたメッセージを前記送信側装置から受信することを含む、請求項２９に記載の方法。
【請求項31】
前記変更されたメッセージを取得するステップが、前記元のメッセージの公開ビットのみを含む、前記元のメッセージのバージョンを受信することと、
前記元のメッセージの前記バージョンと前記マスクビット列を使用して、前記変更されたメッセージを生成するステップと、
を含む、請求項２９に記載の方法。
【請求項32】
前記変更されたメッセージのビットは、変更されたメッセージ全体に対応し、前記変更されたメッセージは、前記変更されたメッセージの出力ハッシュ値を生成するために使用されるハッシュ関数によって定義される入力メッセージサイズに対応する長さを持つ、請求項２９に記載の方法。
【請求項33】
前記変更されたメッセージは、複数のメッセージブロックを含み、前記出力ハッシュ値は、前記複数のメッセージブロックのうちの最後のメッセージブロックのハッシュであり、前記複数のメッセージブロックは、前記出力ハッシュ値を生成するために使用されるハッシュ関数によって定義される入力メッセージサイズに対応する長さを持つ、請求項２９に記載の方法。
【請求項34】
前記変更されたメッセージのビットは、前記複数のメッセージブロックのいずれかに対応する、請求項３３に記載の方法。
【請求項35】
マージされたブロックは、機密データを含む複数の隣接するメッセージブロックを含み、前記ゼロ知識証明を検証するステップは、前記マージされたブロックの最後のメッセージブロックのハッシュ値を使用する、請求項２９に記載の方法。
【請求項36】
前記元のメッセージがブロックチェーントランザクションであり、前記コンピューティング装置のメモリに格納されたデータが、前記ブロックチェーントランザクションに関連付けられたトランザクション識別子であり、出力ハッシュ値を検証するステップは、前記出力ハッシュ値をハッシングし、ハッシングの出力を前記トランザクション識別子と比較することを含む、請求項２９に記載の方法。
【請求項37】
前記変更されたメッセージのビットに関連付けられた複数のゼロ知識証明は、前記送信側装置から受信され、前記複数のゼロ知識証明を検証するステップは並行して行われる、請求項２９に記載の方法。
【請求項38】
コンピュータ可読記憶装置上に具現化されたコンピュータプログラムであって、コンピュータ装置上で実行すると請求項２９に記載の方法を実行するよう構成される、コンピュータプログラム。
【請求項39】
プロセッサとメモリを含むコンピュータ装置であり、前記メモリは、前記プロセッサによって実行されると前記コンピュータ装置に請求項２９に記載の方法を実行させる命令を格納している、コンピュータ装置。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、メッセージ内の機密データをブロックすることに関する。
【背景技術】
【0002】
ブロックチェーンとは、分散型ピアツーピア（P２P）ネットワーク（以下で「ブロックチェーンネットワーク」とも呼ばれる）内の複数のノードの各々において、ブロックチェーンの重複コピーが維持され広く公表される、分散データ構造の形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは１つ以上のトランザクションを含む。所謂「コインベーストランザクション」以外の各トランザクションは、シーケンス内の先行するトランザクションをポイントする。シーケンスは、１つ以上のコインベーストランザクションまで遡る１つ以上のブロックに跨がってよい。コインベーストランザクションは以下で更に議論される。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含まれる。新しいブロックは、「マイニング」として知られる処理により生成される。「マイニング」は、複数のノードの各々が「proof-of-work」を実行するために競争する、つまり、ブロックチェーンの新しいブロックに含まれることを待っている順序付き及び妥当性確認済みの保留中のトランザクションの定義されたセットの提示に基づき、暗号パズルを解くことを含む。留意すべきことに、ブロックチェーンは幾つかのノードにおいてプルーニング（pruned）されてよく、ブロックの公開はブロックヘッダのみの公開を通じて達成できる。
【0003】
ブロックチェーン内のトランザクションは、以下の目的：デジタルアセット（つまり、多数のデジタルトークン）を運ぶこと、仮想台帳又はレジストリの中のエントリのセットを順序付けること、タイムスタンプエントリを受信し処理すること、及び／又はインデックスポインタを時系列にすること、のうちの１つ以上のために使用できる。ブロックチェーンの上に追加の機能をレイヤ化するために、ブロックチェーンを利用することもできる。例えば、ブロックチェーンプロトコルは、トランザクション内のデータに追加のユーザデータ又はインデックスを格納できるようにし得る。単一トランザクション内に格納できる最大データ容量に対する予め指定された限度は存在しない。従って、より複雑なデータを組み込むことができる。例えば、これは、ブロックチェーン内に電子文書（electronic document）、或いはオーディオ若しくはビデオデータを格納するために使用され得る。
【0004】
ブロックチェーンネットワークのノード（「マイナー」と呼ばれることがある）は、以下に詳細に説明する分散型トランザクション登録及び検証処理を実行する。つまり、この処理の間、ノードは、トランザクションの妥当性確認を行い、それらをブロックテンプレイトに挿入し、それに対して有効なproof-of-work解を特定しようと試みる。有効な解が見付かると、新しいブロックはネットワークの他のノードへと伝播され、それにより、各ノードがブロックチェーンに新しいブロックを記録できるようになる。トランザクションをブロックチェーンに記録させるために、ユーザ（例えば、ブロックチェーンクライアントアプリケーション）は、伝播させるために、ネットワークのノードの１つにトランザクションを送信する。トランザクションを受信したノードは、proof-of-work解を見付けるために競争し、妥当性確認されたトランザクションを新しいブロックに組み込む。各ノードは、トランザクションが有効であるための１つ以上の条件を含む同じノードプロトコルを実施するよう構成される。無効なトランザクションは、伝播されず、ブロックに組み込まれることもない。トランザクションが妥当性確認され、それによってブロックチェーンに受け入れられたと仮定すると、（任意のユーザデータを含む）トランザクションは、従って、不変の公開レコードとしてブロックチェーンネットワークの各ノードに登録されインデックスされたままである。
【0005】
最新のブロックを生成するためにproof-of-workパズルを解くことに成功したノードは、標準的に、デジタルアセットの新しい量、つまりトークンの数を生成する「コインベーストランザクション（coinbase transaction）」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出及び拒否は、ネットワークのエージェントとして動作し及び不法行為を報告及び阻止するよう奨励される競合ノードの動作により実施される。情報の広範な公開により、ユーザはノードの性能を継続的に監査できる。単なるブロックヘッダの公開により、参加者はブロックチェーンの現下の完全性を保証できる。
【0006】
「アウトプットベースの」モデル（UTXOに基づくモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つ以上のインプット及び１つ以上のアウトプットを含む。任意の使用可能アウトプットは、先行するトランザクションシーケンスから導出可能なデジタルアセットの量を指定する要素を含む。使用可能アウトプットは、時にUTXO（unspent transaction output、未使用トランザクションアウトプット）と呼ばれる。アウトプットは、アウトプットの将来の償還（redemption）のための条件を指定するロックスクリプトを更に含んでよい。ロックスクリプトは、デジタルトークン又はアセットを妥当性確認し及び移転するために必要な条件を定義する述部（predicate）である。（コインベーストランザクション以外の）トランザクションの各インプットは、先行するトランザクション内のそのようなアウトプットへのポインタ（つまり参照）を含み、ポイントされたアウトプットのロックスクリプトをアンロックするためのアンロックスクリプトを更に含んでよい。従って、トランザクションのペアを考えるとき、それらを、第１トランザクション及び第２トランザクション（又は「ターゲット」トランザクション）と呼ぶ。第１トランザクションは、デジタルアセットの量を指定する、及びアウトプットをアンロックする１つ以上の条件を定義するロックスクリプトを含む、少なくとも１つのアウトプットを含む。第２ターゲットトランザクションは、第１トランザクションのアウトプットへのポインタと、第１トランザクションのアウトプットをアンロックするためのアンロックスクリプトとを含む、少なくとも１つのインプットを含む。
【0007】
このようなモデルでは、第２ターゲットトランザクションがブロックチェーンで伝播され記録されるブロックチェーンネットワークに送られるとき、各ノードで適用される有効性の基準の１つは、アンロックスクリプトが第１トランザクションのロックスクリプトで定義された１つ以上の条件のすべてを満たすことである。もう１つは、第１トランザクションのアウトプットが、別の前の有効なトランザクションによって未だ償還されていないことである。これらの条件のうちのいずれかに従いターゲットトランザクションが無効であると分かった任意のノードは、該トランザクションを（有効なトランザクションとして）伝搬させず（しかし、無効なトランザクションを登録する場合がある）、ブロックチェーンに記録させるために新しいブロックに含めることもしない。
【0008】
トランザクションモデルの代替のタイプは、アカウントに基づくモデルである。この場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。すべてのアカウントの現在の状態は、ブロックチェーンと分離してノードによって保管され、絶えず更新される。
【発明の概要】
【0009】
ブロックチェーン（例えばビットコインブロックチェーン）の不変性は、公開台帳にアップロードされたデータはすべて検閲されないことを意味すると考えられてきた。ビットコイントランザクション内の一部のデータペイロード（例えば、銀行口座番号、パスポート番号）の配布が管理当局によってブロックされているシナリオでは、ビットコインネットワークの参加者は、データがネットワーク全体に伝播されるのをブロックするか、同じデータがネットワーク全体に拡散するのを許可するかのジレンマに直面する。前者のケースではブロックチェーンの不変性が破られるが、後者のケースでは他の参加者に害を及ぼすことになり、データを共有する参加者に法的な結果をもたらす可能性がある。
【0010】
本開示の実施例では、ブロックチェーンの不変性を維持しながら、ブロックチェーントランザクションの一部の（必要に応じて多い又は少ない）データをブロックするメカニズムが提供される。つまり、データがブロックされているにもかかわらず、参加者はブロックチェーンの履歴の完全性を検証することができる。
【0011】
本開示の実施例は、ブロックチェーントランザクションの任意のフィールドの任意の部分に含まれる機密データをブロックする（すなわち、隠す）ために使用することができる。例えば、本開示の実施例は、ブロックチェーントランザクションのOP_FALSE OP_RETURNフィールドに含まれる機密データをブロックするために使用することができる。
【0012】
ゼロ知識証明（Zero-Knowledge Proof （ZKP））とは、証明者として知られるパーティが、ステートメントが真実であるという事実以外の情報を明らかにすることなく、検証者として知られる別のパーティに対して、そのステートメントが真実であることを証明することができる方法である。本開示の実施例では、１つ以上のZKPが生成され、変更されたメッセージの有効性を証明するために必要な機密データを明らかにすることなく、（機密データが削除された）変更されたメッセージが依然として有効であるという証明を提供する。すなわち、「ゼロ知識証明」という用語は、ここでは、機密／秘密データに関する情報が明らかにされない証明者と検証者との間の知識の証明を意味するために使用される。ブロックチェーントランザクションのコンテキストでは、ZKPは、「これらのフィールドは、所与のトランザクションIDを持つトランザクションの一部である」というステートメントを証明するために使用されるが、ステートメントを証明するために必要な情報、つまりブロックされたデータを提供する必要はない。従って、ブロックされたデータを開示せずに、変更されたブロックチェーントランザクションアウトプットの妥当性を検証することができる。
【0013】
本明細書に開示される一態様によると、メッセージ内の機密データをブロックする方法であって、コンピューティング装置上で実行され、
前記メッセージのコピーを作成するステップと、
少なくとも１つのゼロ知識証明を生成し、前記少なくとも１つのゼロ知識証明の各々を生成することは、
前記コピーのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列を取得することと、
前記少なくとも１つの機密ビットに所定の値を割り当てることで、前記コピーの前記ビットを変更することにより、公開ビット列を計算することと、
秘密ビット列を決定することであって、前記秘密ビット列は、前記少なくとも１つの機密ビットを含み、かつ、前記コピーの前記ビットが、前記公開ビット列、前記マスクビット列及び前記秘密ビット列を用いたビットごとの論理計算の出力と等しいという要件を満たすことと、
前記メッセージのコピー又はその一部をハッシングして出力ハッシュ値を生成することと、
前記公開ビット列、前記マスクビット列、前記出力ハッシュ値、前記秘密ビット列を用いてゼロ知識証明を生成することと、
を含む、ステップと、
前記コピーから前記少なくとも１つの機密ビットの各々を削除して、変更されたメッセージを生成するステップと、
前記少なくとも１つの出力ハッシュ値、及び受信者が前記変更されたメッセージが有効であることを証明できるようにするための前記少なくとも１つのゼロ知識証明とともに、前記変更されたメッセージを前記受信者に出力するステップと、
を含む方法が提供される。
前記メッセージのコピーを作成するステップと、
少なくとも１つのゼロ知識証明を生成し、前記少なくとも１つのゼロ知識証明の各々を生成することは、
前記コピーのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列を取得することと、
前記少なくとも１つの機密ビットに所定の値を割り当てることで、前記コピーの前記ビットを変更することにより、公開ビット列を計算することと、
秘密ビット列を決定することであって、前記秘密ビット列は、前記少なくとも１つの機密ビットを含み、かつ、前記コピーの前記ビットが、前記公開ビット列、前記マスクビット列及び前記秘密ビット列を用いたビットごとの論理計算の出力と等しいという要件を満たすことと、
前記メッセージのコピー又はその一部をハッシングして出力ハッシュ値を生成することと、
前記公開ビット列、前記マスクビット列、前記出力ハッシュ値、前記秘密ビット列を用いてゼロ知識証明を生成することと、
を含む、ステップと、
前記コピーから前記少なくとも１つの機密ビットの各々を削除して、変更されたメッセージを生成するステップと、
前記少なくとも１つの出力ハッシュ値、及び受信者が前記変更されたメッセージが有効であることを証明できるようにするための前記少なくとも１つのゼロ知識証明とともに、前記変更されたメッセージを前記受信者に出力するステップと、
を含む方法が提供される。
【0014】
本明細書に開示される一態様によると、変更されたメッセージが有効であることを検証する方法であって、前記変更されたメッセージは元のメッセージから機密データを除去したものに対応し、前記方法は、コンピュータ装置上で実行され、
前記変更されたメッセージを取得するステップであって、前記変更されたメッセージが、前記元のメッセージの各機密ビットに所定の値を割り当てたものに対応する、ステップと、
前記変更されたメッセージの出力ハッシュ値を取得し、前記コンピューティング装置のメモリに格納されたデータを使用して前記出力ハッシュ値を検証するステップと、
送信側装置から、前記変更されたメッセージのビットに関連する少なくとも１つのゼロ知識証明を受信するステップと、
以下：（i）前記ゼロ知識証明を生成するために使用された秘密ビット列を導出するために、前記送信側装置により使用された、ビットごとの論理計算の知識、又はそれに関連する検証鍵、（ii）前記変更されたメッセージのビット、（iii）前記変更されたメッセージのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列、（iv）前記変更されたメッセージのビットのハッシュ値又はその一部、及び（v）前記変更されたメッセージのビットの入力ハッシュ値、を使用して前記少なくとも１つのゼロ知識証明の各々を検証するステップと、
を含む方法が提供される。
前記変更されたメッセージを取得するステップであって、前記変更されたメッセージが、前記元のメッセージの各機密ビットに所定の値を割り当てたものに対応する、ステップと、
前記変更されたメッセージの出力ハッシュ値を取得し、前記コンピューティング装置のメモリに格納されたデータを使用して前記出力ハッシュ値を検証するステップと、
送信側装置から、前記変更されたメッセージのビットに関連する少なくとも１つのゼロ知識証明を受信するステップと、
以下：（i）前記ゼロ知識証明を生成するために使用された秘密ビット列を導出するために、前記送信側装置により使用された、ビットごとの論理計算の知識、又はそれに関連する検証鍵、（ii）前記変更されたメッセージのビット、（iii）前記変更されたメッセージのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列、（iv）前記変更されたメッセージのビットのハッシュ値又はその一部、及び（v）前記変更されたメッセージのビットの入力ハッシュ値、を使用して前記少なくとも１つのゼロ知識証明の各々を検証するステップと、
を含む方法が提供される。
【0015】
本明細書ではブロックチェーントランザクションであるメッセージに関連して実施形態が記述されているが、本開示の実施形態は、ビットコイン及び他のブロックチェーンの文脈の外に拡張され、任意の長さのメッセージの任意の部分をブロックするために使用することができる。以下に説明するように、実施形態は、同時実行（すなわち並列計算）によって、大きなデータサイズのメッセージの一部を効率的にブロックすることができる。
【図面の簡単な説明】
【0016】
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ以下の添付の図面を参照する:
【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。
【図2】ブロックチェーンに記録されるトランザクションの幾つかの例を概略的に示す。
【図3A】クライアントアプリケーションの概略ブロック図である。
【図4】トランザクションを処理するための特定のノードソフトウェアの概略ブロック図である。
【図5】ハッシュ関数の入力と出力を示している。
【図6A】メッセージ内のデータをブロックするプロセスを示している。
【図6B】メッセージ内のデータをブロックするプロセスを示している。
【図6C】メッセージ内のデータをブロックするプロセスを示している。
【図6D】メッセージ内のデータをブロックするプロセスを示している。
【図7】変更されたメッセージの生成を示している。
【図8】単一の圧縮を適用するゼロ知識証明を生成するために使用される回路を示している。
【図9】複数のラウンドの圧縮を適用する少なくとも１ゼロ知識証明を生成するために使用される回路を示している。
【図10A】変更されたメッセージが有効であることを検証するプロセスを示している。
【図10B】変更されたメッセージが有効であることを検証するプロセスを示している。
【発明を実施するための形態】
【0017】
例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク１０１を含んでよい。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（P２P）ネットワーク１０６を形成するように配置され得る複数のブロックチェーンノード１０４を含む。図示されないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして配置されてよい。各ブロックチェーンノード１０４は、従って、他のブロックチェーンノード１０４と高度に結合される。
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク１０１を含んでよい。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（P２P）ネットワーク１０６を形成するように配置され得る複数のブロックチェーンノード１０４を含む。図示されないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして配置されてよい。各ブロックチェーンノード１０４は、従って、他のブロックチェーンノード１０４と高度に結合される。
【0018】
各ブロックチェーンノード１０４は、異なるピアに属するノード１０４のうちの異なるノード１０４を有す、ピアのコンピュータ装置を含む。各ブロックチェーンノード１０４は、１つ以上のプロセッサ、例えば、１つ以上の中央処理装置（CPU）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はフィールドプログラマブルゲートアレイ（FPGA）、及び特定用途向け集積回路（ASIC）のような他の機器を含む処理装置を含む。各ノードはまた、メモリ、すなわち、非一時的コンピュータ読み取り可能媒体又は媒体の形態のコンピュータ読み取り可能記憶装置を備える。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、固体ドライブ（solid-state drive （SSD））、フラッシュメモリ又はEEPROMなどの電子媒体、及び／又は光ディスクドライブなどの光学的媒体を使用する１つ以上のメモリユニットを含んでもよい。
【0019】
ブロックチェーン１５０は、データのブロック１５１のチェーンを含み、ブロックチェーン１５０の各々のコピーは、分散型又はブロックチェーンネットワーク１０６内の複数のノード１０４の各々において維持される。上述のように、ブロックチェーン１５０のコピーを維持することは、必ずしも、ブロックチェーン１５０全体を格納することを意味しない。代わりに、各ブロックチェーンノード１５０が各ブロック１５１のブロックヘッダ（後述する）を格納する限り、ブロックチェーン１５０からデータを取り除くことができる。チェーン内の各ブロック１５１は、１つ以上のトランザクション１５２を含み、ここでは、この文脈におけるトランザクションは、一種のデータ構造を参照する。データ構造の性質は、トランザクションモデル又はスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して、１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各アウトプットは、資産としてのデジタルアセットの量を表す量を指定する。この例では、アウトプットが暗号的にロックされているのはユーザ１０３である（ロックを解除し、それによって償還又は使用するために、そのユーザの署名又は他の解を必要とする）。各インプットは、先行するトランザクション１５２のアウトプットを指し示し、それによって、トランザクションをリンクする。
【0020】
各ブロック１５１は、また、ブロック１５１への逐次的順序を定義するように、チェーン内の先に生成されたブロック１５１を遡ってポイントするブロックポインタ１５５を含む。（コインベーストランザクション以外の）各トランザクション１５２は、トランザクションのシーケンスに順序を定義するために、前のトランザクションへのポインタを含む（注：トランザクション１５２のシーケンスは、分岐することが許される）。ブロック１５１のチェーンは、チェーンの第１ブロックであったジェネシスブロック（genesis block （Gb））１５３にまで戻る。チェーン１５０の初期に１つ以上のオリジナルトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示した。
【0021】
ブロックチェーンノード１０４の各々はトランザクション１５２を他のブロックチェーンノード１０４へ転送し、それにより、ネットワーク１０６に渡りトランザクション１５２を伝播させるよう構成される。各ブロックチェーンノード１０４は、ブロック１５１を生成し、同じブロックチェーン１５０の各々のコピーを自身の各々のメモリに格納するよう構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待つトランザクション１５２の順序付きセット（又はプール）１５４を維持する。順序付きプール１５４は、時に「メモプール（mempool）」と呼ばれる。この用語は、本願明細書では、任意の特定のブロックチェーン、プロトコル、又はモデルに限定されない。それは、ノード１０４が有効であるとして受け付けた、及びノード１０４が同じアウトプットを使用しようと試みる他のトランザクションを受け付けないよう義務付けられたトランザクションの順序付きセットを表す。
【0022】
所与の現在のトランザクション１５２jにおいて、インプット（又はその各々）は、トランザクションのシーケンスの中の先行トランザクション１５２iのアウトプットを参照するポインタを含み、このアウトプットが現在のトランザクション１５２jにおいて償還されるか又は「使用される（spent）」ことを指定する。一般に、先行するトランザクションは、順序付きセット１５４又は任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２iは、必ずしも、現在のトランザクション１５２jが生成された又はネットワーク１０６へ送信されたときに存在する必要はないが、先行するトランザクション１５２iは、現在のトランザクションが有効であるために存在し妥当性確認されている必要がある。従って、本願明細書で「先行する」は、ポインタによりリンクされた論理的シーケンスの中で先行するものを表し、必ずしも時系列の中での生成又は送信の時間を表さない。従って、それは、必ずしも、トランザクション１５２i,１５２jが順不同で生成され又は送信されることを排除しない（以下の親のない（orphan）トランザクションに関する議論を参照する）。先行するトランザクション１５２iは、等しく、祖先（antecedent）又は先行（predecessor）トランザクションと呼ばれ得る。
【0023】
現在のトランザクション１５２jのインプットは、インプット認可、例えば先行するトランザクション１５２iのアウトプットがロックされているユーザ１０３aの署名も含む。次に、現在のトランザクション１５２jのアウトプットは、新しいユーザ又はエンティティ１０３bに暗号的にロックすることができる。従って、現在のトランザクション１５２jは、先行するトランザクション１５２iのインプットに定義された量を、現在のトランザクション１５２jのアウトプットに定義された新しいユーザ又はエンティティ１０３bに移転することができる。ある場合には、トランザクション１５２は、複数のユーザ又はエンティティ間でインプット量を分割するために複数のアウトプットを有してもよいエンティティ（そのうちの１つは、お釣りを与えるために、元のユーザ又はエンティティ１０３aであってもよい）。幾つかの場合には、トランザクションが複数のインプットを有し、１つ以上の先行するトランザクションの複数のアウトプットから量をまとめ、現在のトランザクションの１つ以上のアウトプットに再分配することもできる。
【0024】
ビットコインのようなアウトプットに基づくトランザクションプロトコルによると、個人ユーザ又は組織のようなエンティティ１０３は、（手動で又はパーティにより利用されている自動処理によって）新しいトランザクション１５２jに作用したいとき、作用側エンティティは新しいトランザクションを自身のコンピュータ端末１０２から受信側へ送信する。作用側パーティ又は受信側は、結局、このトランザクションをネットワーク１０６のブロックチェーンノード１０４のうちの１つ以上（これらは、今日では、標準的にサーバ又はデータセンタであるが、原理的に他のユーザ端末も可能である）へと送信する。幾つかの例では、新しいトランザクション１５２jに作用するパーティ１０３が、トランザクションを、受信側ではなくブロックチェーンノード１０４のうちの１つ以上へと直接送信し得ることも排除されない。トランザクションを受信するブロックチェーンノード１０４は、各ブロックチェーンノード１０４に適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、ブロックチェーンノード１０４に、新しいトランザクション１５２j内の暗号署名が、トランザクション１５２の順序付きシーケンスの中の前のトランザクション１５２iに依存する、期待される署名と一致することをチェックすることを要求する。このようなアウトプットに基づくトランザクションプロトコルの場合、これは、新しいトランザクション１５２jのインプットに含まれるパーティ１０３の暗号署名又は他の認証が、新しいトランザクションが割り当てる先行するトランザクション１５２jのアウトプットに定義された条件と一致することをチェックすることを含んでよく、この条件は、典型的には、新しいトランザクション１５２jのインプット内の暗号署名又は他の認証が、新しいトランザクションのインプットがリンクされた前のトランザクション１５２iのアウトプットをアンロックすることを少なくともチェックすることを含む。条件は、先行するトランザクション１５２iのアウトプットに含まれるスクリプトにより少なくとも部分的に定義されてよい。あるいは、単にブロックチェーンノードプロトコルだけで固定することもできるし、あるいは、これらの組み合わせによることもある。いずれにせよ、新しいトランザクション１５２jが有効であれば、ブロックチェーンノード１０４は、新しいトランザクションをブロックチェーンネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に転送する。これらの他のブロックチェーンノード１０４は、同じノードプロトコルに従って同じテストを適用し、新しいトランザクション１５２jを１つ以上のさらなるノード１０４に転送し、以下で同様である。このようにして、新しいトランザクションは、ブロックチェーンノード１０４のネットワーク全体に伝播される。
【0025】
アウトプットベースのモデルでは、与えられ割り当てアウトプット（例えば、UTXO）が割り当てられる（例えば使用される）かどうかの定義は、ブロックチェーンノードプロトコルに従って別の今後の（onward）トランザクション１５２jのインプットによって既に有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが償還を試みる先行するトランザクション１５２iのアウトプットが、別のトランザクションによって未だ償還されていことである。ここでも、有効でない場合、トランザクション１５２jは、（無効であるとしてフラグが立てられ変更するために伝播されない限り）ブロックチェーン１５０に伝播又は記録されない。これは、取引者が同じトランザクションのアウトプットを複数回割り当てようとする二重支出を防ぐ。一方、アカウントベースモデルは、口座残高を維持することによって、二重支出を防ぐ。この場合も、トランザクションの順序が定義されているため、口座残高は、一度に単一の定義された状態を有する。
【0026】
妥当性確認トランザクションに加えて、ブロックチェーンノード１０４は、また、「proof -of -work」により支えられているマイニングと呼ばれるプロセスで、トランザクションのブロックを最初に作成するために競合する。ブロックチェーンノード１０４では、ブロックチェーン１５０に記録されたブロック１５１にまだ現れていない有効なトランザクションの順序付きプール１５４に新しいトランザクションが追加される。ブロックチェーンノードは、次に、暗号パズルを解くことを試みることにより、トランザクションの順序付きセット１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てるために競争する。これは、典型的には、ノンス（nonce）が保留トランザクションの順序付きプール１５４の表現と連結され、ハッシュされるときに、ハッシュのアウトプットが所定の条件を満たすような「ノンス」値を探すことを含む。例えば、所定の条件は、ハッシュのアウトプットが、所定の数の先頭ゼロを有することであってもよい。これは、単に１つの特定の種類のproof-of-workパズルであり、他の種類が排除されないことに留意する。ハッシュ関数の特性は、インプットに関して予測不可能なアウトプットを持つことである。従って、この探索は、ブルートフォースによってのみ実行することができ、従って、パズルを解決しようとしている各ブロックチェーンノード１０４において、相当量の処理リソースを消費する。
【0027】
パズルを解いた第１ブロックチェーンノード１０４は、これをネットワーク１０６に通知し、その解を証明として提供する。この解は、ネットワーク内の他のブロックチェーンノード１０４によって簡単にチェックすることができる（ハッシュに対する解が与えられれば、ハッシュのアウトプットが条件を満たすことを確認することは簡単である）。第１ブロックチェーンノード１０４は、該ブロックを受け入れる閾値の他のノードの合意に、ブロックを伝播させ、従ってプロトコルルールを実施する。トランザクションの順序付きセット１５４は、次に、ブロックチェーンノード１０４の各々により、ブロックチェーン１５０内の新しいブロック１５１として記録されるようになる。また、新しいブロック１５１nにはブロックポインタ１５５が割り当てられ、チェーン内で前に作成されたブロック１５１n-１を指すようになっている。proof-of-work解を生成するために必要とされる例えばハッシュの形式の有意な量の労力が、ブロックチェーンプロトコルのルールに従うという第１ノード１０４の意図をシグナリングする。そのようなルールは、前に妥当性確認されたトランザクションと同じアウトプットを割り当てる場合に有効としてトランザクションを受け付けないこと、或いは二重支払いとして知られいることを含む。一旦生成されると、ブロック１５１は、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々で認識され、維持されるので、修正することができない。また、ブロックポインタ１５５は、ブロック１５１に順序を課す。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。
【0028】
パズルを解決するために常に競争している異なるブロックチェーンノード１０４は、いつ解を探し始めたか、又はトランザクションが受信された順序によって、いつでも未だ公開されていないトランザクションのプール１５４の異なるスナップショットに基づいてパズルを解いているかもしれないことに留意する。パズルを解く者は誰でも、最初に次の新しいブロック１５１nに含まれるトランザクション１５２を定義し、その順序で、未公開のトランザクションの現在のプール１５４が更新される。そして、ブロックチェーンノード１０４は、新たに定義された未公開トランザクションの順序付きプール１５４からブロックを作り出すために、競争を続ける。また、生じ得る「分岐（フォーク、fork）」を解決するためのプロトコルも存在する。これは、２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解き、ブロックチェーンの矛盾したビューがノード１０４の間で伝播する場合である。要するに、分岐の枝が伸びるときは常に、最長のものが最終的なブロックチェーン１５０になる。これは、同じトランザクションが両方の分岐に現れるので、ネットワークのユーザ又はエージェントに影響しないことに留意する。
【0029】
ビットコインブロックチェーン（及び殆どの他のブロックチェーン）によると、新しいブロック１０４を構成するのに成功したノードは、デジタルアセットの追加の定義された量を分配する新しい特別な種類のトランザクションの中でデジタルアセットの追加の承認された量を新たに割り当てる能力を与えられる（１人のエージェント又はユーザから別のエージェント又はユーザへとデジタルアセットの量を移転するエージェント間又はユーザ間トランザクションと異なる）。この特別な種類のトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始（initiation）トランザクション」又は「生成（generation）トランザクション」とも呼ばれることがある。それは標準に新しいブロック１５１nの第１トランザクションを形成する。proof-of-workは、この特別なトランザクションが後に償還できるように、新しいブロックを構成したノードがプロトコルルールに従うことを意図していることをシグナリングする。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還できる前に、満期、例えば１００ブロックを必要としてよい。通常の（非生成）トランザクション１５２は、そのアウトプットの１つに追加のトランザクション料を指定し、そのトランザクションが公開されたブロック１５１nを生成したブロックチェーンノード１０４にさらに報酬を与えることが多い。この手数料は、通常、「トランザクション料」と呼ばれ、後述する。
【0030】
トランザクションの妥当性確認及び公開に関連するリソースのために、典型的には、少なくともブロックチェーンノード１０４の各々は、１つ以上の物理的サーバユニットを含むサーバ、又はデータセンタ全体の形態をとる。しかしながら、原理的に、任意の所与のブロックチェーンノード１０４は、ユーザ端末又は互いにネットワーク接続されたユーザ端末又はユーザ端末のグループの形態をとることができる。
【0031】
各ブロックチェーンノード１０４のメモリは、各々の１つ以上の役割を実行し、ブロックチェーンノードプロトコルに従ってトランザクション１５２を処理するために、ブロックチェーンノード１０４の処理装置上で動作するように構成されたソフトウェアを記憶する。ブロックチェーンノード１０４に属するいずれの動作も、各々のコンピュータ装置の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーションレイヤにおける１つ以上のアプリケーション、又はオペレーティングシステムレイヤ若しくはプロトコルレイヤのような下位レイヤ、又はこれらの任意の組合せの中に実装されてよい。
【0032】
また、ネットワーク１０１には、消費者ユーザの役割を果たす複数のパーティ１０３の各々のコンピュータ装置１０２も接続されている。これらのユーザは、ブロックチェーンネットワークと相互作用できるが、トランザクションの妥当性確認及びブロックの構築には参加しない。これらのユーザ又はエージェントのうちの一部は、トランザクションにおいて送信側及び受信側として動作してよい。他のユーザは、必ずしも送信側又は受信側として動作することなく、ブロックチェーン１５０と相互作用してよい。例えば、幾つかのパーティは、ブロックチェーン１５０のコピーを格納する（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）記憶エンティティとして動作してよい。
【0033】
パーティ１０３の一部又は全部は、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上に重ねられたネットワークの部分として結合されてよい。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれることが多い）は、ブロックチェーンネットワーク１０６を含むシステムの部分であると言うことができる。しかしながら、これらのユーザは、ブロックチェーンノードの要求される役割を実行しないので、ブロックチェーンノード１０４ではない。代わりに、各パーティ１０３は、ブロックチェーンネットワーク１０６と相互作用し、それにより、ブロックチェーンノード１０６に結合する（つまり通信する）ことにより、ブロックチェーン１５０を利用してよい。２つのパーティ１０３及び各々の機器１０２は、説明のために示されており、第１パーティ１０３a及びその各々のコンピュータ機器１０２a、ならびに第２パーティ１０３b及びその各々のコンピュータ機器１０２bである。より多くのこのようなパーティ１０３及びそれらの各々のコンピュータ機器１０２がシステム１００に存在し、参加することができるが、便宜上、それらは図示されていないことが理解されよう。各パーティ１０３は、個人又は組織であってもよい。純粋に例示として、第１パーティ１０３ａは、本明細書においてAliceと称され、第２パーティ１０３ｂは、Bobと称されるが、これは限定的なものではなく、本明細書においてAlice又はBobという言及は、各々「第１パーティ」及び「第２パーティ」と置き換えることができることは理解されるであろう。
【0034】
各パーティ１０３のコンピュータ機器１０２は、１つ以上のプロセッサ、例えば、１つ以上のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び／又はFPGAを備える各々の処理装置を備える。各パーティ１０３のコンピュータ機器１０２は、さらに、メモリ、すなわち、非一時的コンピュータ読み取り可能媒体又は媒体の形態のコンピュータ読み取り可能記憶装置を備える。このメモリは、１つ以上のメモリ媒体、例えば、ハードディスクのような磁気媒体、SSD、フラッシュメモリ又はEEPROMのような電子媒体、及び／又は光学ディスクドライブのような光学媒体を使用する１つ以上のメモリユニットを含むことができる。各パーティ１０３のコンピュータ機器１０２上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーション１０５の各々のインスタンスを含むソフトウェアを記憶する。本明細書で与えられたパーティ１０３に帰属するいずれのアクションも、各々のコンピュータ装置１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各パーティ１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えばデスクトップ又はラップトップコンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブルデバイスを備えている。所与のパーティ１０３のコンピュータ装置１０２は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースのような、１つ以上の他のネットワーク化されたリソースを含んでもよい。
【0035】
クライアントアプリケーション１０５は、最初に、１つ以上の適切なコンピュータ読み取り可能な記憶媒体、例えばサーバからダウンロードされたもの、又はリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスク又はテープ、光ディスク、例えばCD又はDVD ROM、又はリムーバブル光学ドライブなどのリムーバブル記憶装置上で、任意の所与のパーティ１０３のコンピュータ機器１０２に提供され得る。
【0036】
クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これには主に２つの機能を有する。これらのうちの１つは、各々のパーティ１０３が、ブロックチェーンノード１０４のネットワーク全体にわたって伝播され、それによってブロックチェーン１５０に含まれるべきトランザクション１５２を作成し、認可し（例えば署名し）、送信することを可能にすることである。もう１つは、現在所有しているデジタルアセットの量を各々のパーティに報告することである。アウトプットベースのシステムでは、この第２機能は、当該パーティに属するブロックチェーン１５０全体に散在する様々なトランザクション１５２のアウトプットの中で定義される量を照合することを含む。
【0037】
注：種々のクライアント機能が所与のクライアントアプリケーション１０５に統合されるとして説明されることがあるが、これは、必ずしも限定的ではなく、代わりに、本願明細書に記載される任意のクライアント機能が２つ以上の異なるアプリケーションのスーツに実装されてよく、例えばAPIを介してインタフェースし、又は一方が他方へのプラグインである。より一般的には、クライアント機能は、アプリケーションレイヤ、又はオペレーティングシステムのような下位レイヤ、又はこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション１０５の観点で説明されるが、これは限定的ではないことが理解される。
【0038】
各コンピュータ機器１０２上のクライアントアプリケーション又はソフトウェア１０５のインスタンスは、ネットワーク１０６のブロックチェーンノード１０４の少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能は、トランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５は、また、ブロックチェーンノード１０４にコンタクトして、各々のパーティ１０３が受信側である任意のトランザクションについてブロックチェーン１５０に問い合わせることができる（又は、実施形態では、ブロックチェーン１５０は、部分的にその公開視認性を通じてトランザクションの信頼を提供する公開的設備であるため、実際には、ブロックチェーン１５０内の他のパーティのトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルに従ってトランザクション１５２を形成し、送信するように構成される。上述のように、各ブロックチェーンノード１０４は、ブロックチェーンノードプロトコルに従いトランザクション１５２を妥当性確認し、トランザクション１５２をブロックチェーンネットワーク１０６全体に渡り伝播させるために、トランザクション１５２を転送するよう構成されるソフトウェアを実行する。トランザクションプロトコルとノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に所与のトランザクションモデルを実装する。同じトランザクションプロトコルは、ブロックチェーン１５０内の全部のトランザクション１５２について使用される。同じノードプロトコルは、ネットワーク１０６内の全部のノード１０４について使用される。
【0039】
所与のパーティ１０３、例えばAliceがブロックチェーン１５０に含まれる新たなトランザクション１５２jを送信したいと望む場合、彼女は関連するトランザクションプロトコルに従って（彼女のクライアントアプリケーション１０５のウォレット機能を使用して）新たなトランザクションを作成する（formulate）。彼女は、次に、クライアントアプリケーション１０５からトランザクション１５２を、彼女が接続されている１つ以上のブロックチェーンノード１０４に送信する。例えば、これは、Aliceのコンピュータ１０２に最も良好に接続されているブロックチェーンノード１０４であってもよい。任意の所与のブロックチェーンノード１０４が新しいトランザクション１５２jを受信すると、ブロックチェーンノードプロトコル及びその各々の役割に従って、それを処理する。これは、最初に、新たに受信されたトランザクション１５２jが「有効」であるための特定の条件を満たしているかどうかをチェックすることを含み、その例については、簡単に詳述する。幾つかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であってよい。或いは、条件は単にノードプロトコルの組み込み機能であってもよく、或いはスクリプトとノードプロトコルの組み合わせによって定義されてもよい。
【0040】
新たに受信されたトランザクション１５２jが、有効であると見なされるテストに合格したという条件で（すなわち、「妥当性確認された」という条件で）、トランザクション１５２jを受信した任意のブロックチェーンノード１０４は、そのブロックチェーンノード１０４に維持されているブロックチェーンの順序付きセット１５４に、新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２jを受信する任意のブロックチェーンノード１０４は、妥当性確認済みトランザクション１５２をネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に伝播する。各ブロックチェーンノード１０４は同じプロトコルを適用するので、トランザクション１５２jが有効であると仮定すると、これは、ネットワーク１０６全体に間もなく伝播されることを意味する。
【0041】
所与のブロックチェーンノード１０４において維持される保留中トランザクションの順序付きプール１５４に入れられると、該ブロックチェーンノード１０４は、新しいトランザクション１５２を含む、彼ら各々のトランザクションのプールの最新バージョンについて、proof-of-workパズルを解く競争を開始する（他のブロックチェーンノード１０４は、トランザクションの異なるプール１５４に基づきパズルを解こうとしているが、誰であっても１番の者が、最新のブロック１５１に含まれるトランザクションのセットを定義することに留意する。）。最終的に、ブロックチェーンノード１０４は、Aliceのトランザクション１５２jを含む順序付きプール１５４の一部についてパズルを解くだろう。）。一旦、新しいトランザクション１５２jを含むプール１５４についてproof-of-workが行われると、それはブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、以前のトランザクションへのポインタから構成されるので、トランザクションの順序もまた、不変的に記録される。
【0042】
異なるブロックチェーンノード１０４は、最初に所与のトランザクションの異なるインスタンスを受信する可能性があり、従って、１つのインスタンスが公開（Publishing）されて新しいブロック１５１になる前に、どのインスタンスが「有効」であるかについて矛盾するビューを有することがあり、その時点で、全部のブロックチェーンノード１０４は公開されたインスタンスのみが有効なインスタンスであることに合意する。ブロックチェーンノード１０４が１つのインスタンスを有効であるとして受け入れ、次に第２インスタンスがブロックチェーン１５０に記録されていることを発見した場合、該ブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（つまり未だブロック１５１の中で公開されていないもの）を破棄する（つまり、無効であるとして扱う）。
【0043】
アカウントベースのトランザクションモデルの一部として、幾つかのブロックチェーンネットワークにより運用される別のタイプのトランザクションプロトコルを「アカウントベース」のプロトコルと呼ぶことがある。アカウントベースの場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。すべてのアカウントの現在の状態は、ブロックチェーンと分離して、ネットワークのノードにより格納され、絶えず更新される。このようなシステムでは、トランザクションは、アカウントの連続したトランザクション記録（いわゆる「ポジション」）を用いて発注される。この値は、送信者により彼らの暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。さらに、任意的なデータフィールドもトランザクションに署名することができる。このデータフィールドは、例えば、前のトランザクションIDがデータフィールドに含まれている場合、前のトランザクションを遡ってポイントしてよい。
【0044】
UTXOベースのモデル
図２は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション１５２（「Tx」と略す）は、ブロックチェーン１５０（各ブロック１５１は１つ以上のトランザクション１５２を含む）の基本的なデータ構造である。以下は、アウトプットベース又は「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、全ての可能な実施形態に限定されるものではない。例示的なUTXOベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実施できることに留意する。
図２は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション１５２（「Tx」と略す）は、ブロックチェーン１５０（各ブロック１５１は１つ以上のトランザクション１５２を含む）の基本的なデータ構造である。以下は、アウトプットベース又は「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、全ての可能な実施形態に限定されるものではない。例示的なUTXOベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実施できることに留意する。
【0045】
UTXOベースのモデルでは、各トランザクション（「Tx」）１５２は、１つ以上のインプット２０２及び１つ以上のアウトプット２０３を含むデータ構造を含む。各アウトプット２０３は、未使用トランザクションアウトプット（UTXO）を含んでもよく、これは、別の新しいトランザクションのインプット２０２のソースとして使用することができる（UTXOが未だ償還されていない場合）。UTXOは、デジタルアセットの量を指定する値を含む。これは、分散型台帳上のトークンの設定数を表す。また、他の情報の中でも、UTXOは、それが由来するトランザクションのトランザクションIDも含んでよい。トランザクションデータ構造はまた、ヘッダ２０１も含んでよく、ヘッダ２０１は、インプットフィールド２０２及びアウトプットフィールド２０３のサイズの指示子を含んでもよい。ヘッダ２０１は、トランザクションのIDも含んでもよい。実施形態において、トランザクションIDは、トランザクションデータ（トランザクションID自体を除く）のハッシュであり、ノード１０４に提出された未処理トランザクション１５２のヘッダ２０１に格納される。
【0046】
例えばAlice１０３aは、問題のデジタルアセットの量をBob１０３bに移転するトランザクション１５２jを作成したいと考えているとする。図２において、Aliceの新しいトランザクション１５２jは「Tx１」とラベル付けされている。これは、Aliceにロックされているデジタルアセットの量を、シーケンス内の先行するトランザクション１５２iのアウトプット２０３に取り入れ、その少なくとも一部をBobに移転する。先行するトランザクション１５２iは、図２において「Tx０」とラベル付けされている。Tx０とTx１は、単なる任意のラベルある。これらは、必ずしも、Tx０がブロックチェーン１５１の第１トランザクションであること、又は、Tx１がプール１５４の直ぐ次のトランザクションであることを意味しない。Tx１は、まだAliceにロックされた未使用アウトプット２０３を有する任意の先行する（つまり祖先）トランザクションのいずれかを指し示すことができる。
【0047】
先行するトランザクションTx０は、Aliceがその新しいトランザクションTx１を作成するとき、又は少なくとも彼女がそれをネットワーク１０６に送信するときまでに、既に検証され、ブロックチェーン１５０のブロック１５１に含まれていてもよい。それは、その時点で既にブロック１５１のうちの１つに含まれていてもよく、あるいは、順序付きセット１５４内でまだ待機していてもよく、その場合、新しいブロック１５１にすぐに含まれることになる。或いは、Tx０及びTx１が生成されネットワーク１０６に送信されることができ、或いは、ノードプロトコルが「孤児（orphan）」トランザクションのバッファリングを許容する場合にはTx１の後にTx０が送信されることもできる。ここでトランザクションのシーケンスの文脈で使用される「先行する」及び「後の」という用語は、トランザクション内で指定されたトランザクションポインタ（どのトランザクションがどの他のトランザクションを指すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、「先行する」及び「相続する」又は「祖先」及び「子孫」、「親」及び「子」、等により、等しく置き換えられ得る。これは、必ずしも、それらが作成され、ネットワーク１０６に送られ、又は任意の所与のブロックチェーンノード１０４に到達する順序を意味しない。それにもかかわらず、先行するトランザクション（祖先トランザクション又は「親」）を指す後続のトランザクション（子孫トランザクション又は「子」）は、親トランザクションが妥当性確認されない限り、妥当性確認されない。親の前にブロックチェーンノード１０４に到着した子は孤児とみなされる。それは、ノードプロトコル及び／又はノードの行動に応じて、親を待つために特定の時間、破棄又はバッファリングされることがある。
【0048】
先行するトランザクションTx０の１つ以上のアウトプット２０３のうちの１つは、本明細書でUTXO０とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタルアセットの量を指定する値と、後続のトランザクションが検証されるために、従ってUTXOが正常に償還されるために、後続のトランザクションのインプット２０２の中のアンロックスクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。典型的には、ロックスクリプトは、特定のパーティ（それが含まれているトランザクションの受益者）に量をロックする。すなわち、ロックスクリプトは、標準的に以下のようなアンロック条件を定義する：後続のトランザクションのインプット内のアンロックスクリプトは、先行するトランザクションがロックされたパーティの暗号署名を含む。
【0049】
ロックスクリプト（別名scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの一部である。そのような言語の特定の例は、ブロックチェーンネットワークにより使用される「スクリプト」（Script，大文字S）と呼ばれる。ロックスクリプトは、トランザクションアウトプット２０３を消費するために必要な情報、例えば、Aliceの署名の必要条件を指定する。トランザクションのアウトプットには、アンロックスクリプトが現れる。アンロックスクリプト（別名：scriptSig）は、ロックスクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えば、Bobの署名を含んでもよい。アンロックスクリプトは、トランザクションのインプット２０２に現れる。
【0050】
図示の例では、Tx０のアウトプット２０３のUTXO０は、ロックスクリプト[Checksig PA]を含み、これは、UTXO０が償還されるために（厳密には、UTXO０を償還しようとする後続のトランザクションが有効であるために）、Aliceの署名Sig PAを必要とする。[Checksig PA]は、Aliceの公開－秘密鍵ペアからの公開鍵PAの表現（つまりハッシュ）を含む。Tx１のインプット２０２は、Tx１を指すポインタ（例えば、そのトランザクションID、実施形態ではトランザクションTx０全体のハッシュであるTxID０）を含む。Tx１のインプット２０２は、Tx０の任意の他の可能なアウトプットの中でそれを識別するために、Tx０内のUTXO０を識別するインデックスを含む。Tx１のインプット２０２は、さらに、Aliceが鍵ペアからのAliceの秘密鍵をデータの所定の部分（暗号において「メッセージ」と呼ばれることもある）に適用することによって作成された、Aliceの暗号署名を含むアンロックスクリプト<SigPA>を含む。有効な署名を提供するためにAliceが署名する必要があるデータ（又は「メッセージ」）は、ロックスクリプトにより、又はノードプロトコルにより、又はこれらの組み合わせによって定義され得る。
【0051】
新しいトランザクションTx１がノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトとアンロックスクリプトを一緒に実行して、アンロックスクリプトがロックスクリプトで定義されている条件（この条件は１つ以上の基準を含むことができる）を満たしているかどうかをチェックすることを含む。実施形態では、これは、２つのスクリプトの連結を含む。
ここで、「||」は連結を表し、「<...>」はスタックにデータを配置することを意味し、「[...]」はロックスクリプトに含まれる機能である（本例では、スタックベースの言語）。同等に、スクリプトは。、スクリプトを連結するのではなく共通のスタックにより１つずつ実行されてよい。いずれにせよ、一緒に実行する場合、スクリプトは、Tx０のアウトプットのロックスクリプトに含まれるように、Aliceの公開鍵PAを使用して、Tx１のインプットのアンロックスクリプトが、データの期待される部分に署名するAliceの署名を含むことを認証する。また、データの期待部分（「メッセージ」）も、この認証を実行するために含まれる必要がある。実施形態において、署名されたデータは、Tx１の全体を含む（従って、平文のデータの署名された部分がすでに本質的に存在するので、それを指定する別個の要素を含める必要がない）。
【数1】
【0052】
公開－秘密暗号法による認証の詳細は、当業者には周知であろう。基本的に、Aliceが彼女の秘密鍵を用いてメッセージに署名した場合、Aliceの公開鍵とそのメッセージが平文ならば、ノード１０４のような別のエンティティは、そのメッセージがAliceによって署名されていなければならないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、署名としてメッセージにこれをタグ付けすることによって、公開鍵の所有者が署名を認証することを可能にする。従って、実施形態では、特定のデータ片又はトランザクションの部分等に署名するという言及は、データ片又はトランザクションの部分のハッシュに署名することを意味し得る。
【0053】
Tx１のアンロックスクリプトが、Tx０のロックスクリプトで指定された１つ以上の条件を満たす場合（例では、Aliceの署名がTx１で提供され、認証されている場合）、ブロックチェーンノード１０４は、Tx１が有効であるとみなす。これは、ブロックチェーンノード１０４がTx１を保留トランザクションの順序付きプール１５４に追加することを意味する。ブロックチェーンノード１０４は、トランザクションTx１をネットワーク１０６内の１つ以上の他のブロックチェーンノード１０４に転送し、それによって、それがネットワーク１０６全体に伝播されることになる。一旦、Tx１が妥当性確認され、ブロックチェーン１５０に含まれると、これは、Tx０からのUTXO０を消費したものとして定義する。Tx１は、未使用トランザクションアウトプット２０３を使用する場合にのみ有効であることに留意されたい。別のトランザクション１５２によって既に消費されたアウトプットを消費しようとする場合、Tx１は、たとえ他のすべての条件が満たされていても無効となる。従って、ブロックチェーンノード１０４は、先行するトランザクションTx０において参照されたUTXOが既に消費されているかどうか（既に別の有効なトランザクションへの有効なインプットを形成しているかどうか）もチェックする必要がある。これが、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である理由の１つである。実際には、所与のブロックチェーンノード１０４は、トランザクション１５２が消費されたUTXO２０３をマークする別個のデータベースを維持することができるが、最終的には、UTXOが消費されたかどうかを定義するのは、ブロックチェーン１５０内の別の有効なトランザクションへの有効なインプットを既に形成しているかどうかである。
【0054】
所与のトランザクション１５２の全部のアウトプット２０３の中で指定された総量が全部のそのインプット２０２により指される総量より大きい場合、これは、殆どのトランザクションモデルにおいて無効の別の基礎である。従って、このようなトランザクションは、伝播されず、ブロック１５１に含まれることもない。
【0055】
UTXOベースのトランザクションモデルでは、所定のUTXOを全体として使用する必要があることに注意する。UTXOで定義されている量のうち、別の分量が消費されている一方で、ある分量を「残しておく」ことはできない。ただし、UTXOからの量は、次のトランザクションの複数のアウトプットに分割できる。例えば、Tx０のUTXO０で定義された量は、Tx１の複数のUTXOに分割できる。従って、AliceがBobにUTXO０で定義された量の全てを与えることを望まない場合、彼女は残りの量を使って、Tx１の第２アウトプットの中で自分自身にお釣りを与えるか、又は別のパーティに支払うことができる。
【0056】
特に、Aliceは、通常、彼女のトランザクション１０４をブロック１５１に含めることに成功したビットコインノード１０４のための手数料も含める必要がある。Aliceがそのような手数料を含まない場合、Tx０はブロックチェーンノード１０４によって拒否される可能性が高く、したがって、技術的には有効であるが、それは伝播されず、ブロックチェーン１５０に含まれない（ノードプロトコルは、彼らが望まない場合には、ブロックチェーンノード１０４にトランザクション１５２を受け入れることを強制しない）。一部のプロトコルでは、トランザクション手数料は、独自の別個のアウトプット２０３を必要としない（すなわち、別個のUTXOを必要としない）。代わりに、インプット２０２によって示される総量と、所与のトランザクション１５２のアウトプット２０３で指定される総量との間の差は、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、UTXO０へのポインタがTx１への唯一のインプットであり、Tx１は１つのアウトプットUTXO１しか持っていないとする。UTXO０で指定されたデジタルアセットの量がUTXO１で指定された量より多い場合、その差は、UTXO１を含むブロックを生成するproof-of-work競争の勝者であるノード１０４により割り当てられてよい。しかし、代替的又は追加的に、必ずしも、トランザクション１５２のUTXO２０３のうちの独自のものにおいて、トランザクション手数料を明示的に指定できることは除外されない。
【0057】
Alice及びBobのデジタルアセットは、ブロックチェーン１５０内の任意のトランザクション１５２の中で彼らにロックされたUTXOで構成されている。従って、典型的には、所与のパーティ１０３のアセットは、ブロックチェーン１５０を通して、様々なトランザクション１５２のUTXO全体に分散される。ブロックチェーン１５０内のどこにも、所与のパーティ１０３の総残高を定義する１つの数値は記憶されていない。各パーティへのロックされた、別の将来の（onward）トランザクションに未だ使用されていない全ての様々なUTXOの値をまとめることは、クライアントアプリケーション１０５におけるウォレット機能の役割である。ビットコインノード１０４のいずれかに格納されたブロックチェーン１５０のコピーをクエリすることにより、これを行うことができる。
【0058】
スクリプトコードは、概略的に表現されることが多い（すなわち、正確な言語を用いない）ことに注意する。例えば、特定の機能を表現するオペレーションコード（opcode、オペコード）を使用してよい。「OP_....」は、スクリプト言語の特定のオペコードを表す。例として、OP_RETURNは、ロックスクリプトの始めにあるOP_FALSEが先行するとき、トランザクション内にデータを格納することができ、それによってデータをブロックチェーン１５０に不変に記録することができるトランザクションの使用不可能アウトプットを生成するためのスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに格納することが望ましい文書を含むことができる。
【0059】
通常、トランザクションのインプットは、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは楕円曲線secp２５６k１を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。幾つかの実施形態では、所与のトランザクションについて、署名はトランザクションインプットの一部、及びトランザクションアウトプットの全部又は一部に署名する。署名するアウトプットの特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは、通常、署名の最後に含まれる４バイトのコードであり、どのアウトプットが署名されるかを選択する（従って、署名の時点で固定される）。
【0060】
ロックスクリプトは、通常、各々のトランザクションがロックされているパーティの公開鍵を含んでいることを表す「scriptPubKey」と呼ばれることがある。アンロックスクリプトは、通常、対応する署名を提供することを表す「scriptSig」と呼ばれることがある。しかし、より一般的には、UTXOが償還される条件が署名を認証することを含むことは、ブロックチェーン１５０の全てのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語は、任意の１つ以上の条件を定義するために使用され得る。したがって、より一般的な用語「ロックスクリプト」及び「アンロックスクリプト」が好ましい。
【0061】
クライアントソフトウェア
図３Aは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１と、ユーザインタフェース（UI）レイヤ４０２と、を含む。トランザクションエンジン４０１は、クライアント１０５の基礎トランザクション関連機能、例えばトランザクション１５２を形成し、ブロックチェーンネットワーク１０６を介して伝播されるように１つ以上のノード１０４にトランザクションを送信するように、上述したスキームに従って、さらに詳細に説明するように、構成される。
図３Aは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１と、ユーザインタフェース（UI）レイヤ４０２と、を含む。トランザクションエンジン４０１は、クライアント１０５の基礎トランザクション関連機能、例えばトランザクション１５２を形成し、ブロックチェーンネットワーク１０６を介して伝播されるように１つ以上のノード１０４にトランザクションを送信するように、上述したスキームに従って、さらに詳細に説明するように、構成される。
【0062】
UIレイヤ４０２は、各々のユーザコンピュータ機器１０２のユーザ入力／出力（I/O）手段を介して、機器１０２のユーザ出力手段により各々のユーザ１０３へ情報を出力すること及び機器１０２のユーザ入力手段により各々のユーザ１０３から入力を受信することを含む、ユーザインタフェースをレンダリングするよう構成される。例えば、ユーザ出力手段は、視覚的出力を提供する１つ以上のディスプレイスクリーン（タッチ又は非タッチスクリーン）、オーディオ出力を提供する１つ以上のスピーカ、及び／又は触覚出力を提供する１つ以上の触覚出力装置、等を含み得る。ユーザ入力手段は、例えば、１つ又は複数のタッチスクリーンの入力アレイ（出力手段に使用されるものと同じか又は異なる）、マウス、トラックパッド又はトラックボールなどの１つ又は複数のカーソルベースの装置、音声又は声の入力を受け取るための１つ又は複数のマイクロフォン及び音声認識アルゴリズム、手動又は身体のジェスチャの形態で入力を受け取るための１つ又は複数のジェスチャベースの入力装置、又は１つ又は複数の機械的ボタン、スイッチ又はジョイスティックなどを含むことができる。
【0063】
注：本明細書における種々の機能は、同一のクライアントアプリケーション１０５に統合されていると記述することができるが、これは、必ずしも限定するものではなく、代わりに、２つ以上の別個のアプリケーション、例えば、一方が他方へのプラグインであるか、又はAPI（アプリケーションプログラミングインタフェース）を介したインタフェースで実装することができる。例えば、トランザクションエンジン４０１の機能は、UIレイヤ４０２と別個のアプリケーション、又は所与のモジュールの機能に実装されてよく、トランザクションエンジン４０１が１つより多くのアプリケーションの間で分割されてよい。また、記載の機能の一部又は全部が、例えばオペレーティングシステムレイヤに実装されることを除外しない。本願明細書のどこかで、単一の又は所与のアプリケーション１０５等を参照する場合、これが単に例としてであること、より一般的には、記載の機能が任意の形式のソフトウェアで実装され得ることが理解される。
【0064】
図３Bは、Aliceの機器１０２a上のクライアントアプリケーション１０５aのUI層４０２によりレンダリングされてよいユーザインタフェース（UI）５００の例の模擬表示を与える。同様のUIが、任意の他のパーティのクライアント１０５b、Bobの機器１０２b、又は任意の他のパーティの機器によりレンダリングされてよいことが理解される。
【0065】
例示として、図３Bは、Aliceの観点からUI５００を示す。UI５００は、ユーザ出力手段を介して別個のUI要素として描画される１つ以上のUI要素５０１、５０２、５０２を含んでもよい。
【0066】
例えば、UI要素は、例えば、画面上の異なるボタン、又はメニュー内の異なるオプション等の１つ以上のユーザ選択可能要素５０１を含むことができる。ユーザ入力手段は、スクリーン上のUI要素をクリック若しくはタッチすることにより、又は所望のオプションの名称を発話することにより、ユーザ１０３（この場合にはAlice１０３a）がオプションのうちの１つを選択又は操作できるよう構成される（注：ここで使用される「手動（manual）」は単に自動の反対を意味し、必ずしも手の使用に限定されない）。オプションは、ユーザ（Alice）がトランザクション１５２を形成し、トランザクションを１つ以上のノード１０４に送信して、ブロックチェーンネットワーク１０６を介して伝播させることを可能にする。
【0067】
代替又は追加で、UI要素は、１つ以上のデータエントリフィールド５０２を含むことができ、これを通じて、ユーザはトランザクション１５２を形成し、トランザクションを１つ以上のノード１０４に送信して、ブロックチェーンネットワーク１０６を介して伝播させることができる。これらのデータエントリフィールドは、ユーザ出力手段、例えば、オンスクリーンを介してレンダリングされ、データは、ユーザ入力手段、例えば、キーボード又はタッチスクリーンを介してフィールドに入力することができる。あるいは、データは、例えば、音声認識に基づいて口頭で受信され得る。
【0068】
代替的又は追加的に、UI要素は、ユーザに情報を出力するために出力される１つ以上の情報要素５０３を含んでもよい。例えば、これ／これらは、スクリーン上に描画されるか、又は可聴でレンダリングされることがある。
【0069】
例えば、この／これらは、スクリーン上に描画されるか、又は可聴で描画されることがある。これらのUI要素の機能は、間もなく更に詳細に議論される。また、図３に示されたUI５００は、単に概略的なモックアップであり、実際には、１つ以上のさらなるUIエレメントを含んでもよく、これは、簡潔さのために示されていないことが理解される。
【0070】
ノードソフトウェア
図４は、UTXO又はアウトプットに基づくモデルの例における、ネットワーク１０６の各ブロックチェーンノード１０４で実行され得るノードソフトウェア４５０の例を示す。別のエンティティが、ネットワーク１０６上でノード１０４として分類されずに、つまり、ノード１０４に必要なアクションを実行せずに、ノードソフトウェア４５０を実行できることに注意する。ノードソフトウェア４５０は、プロトコルエンジン４５１、スクリプトエンジン４５２、スタック４５３、アプリケーションレベルの決定エンジン４５４、及び１つ以上のブロックチェーン関連機能モジュールのセット４５５を含んでよいが、それらに限定されない。各ノード１０４は、合意モジュール４５５C（例えば、proof-of-work）、伝播モジュール４５５P、及びストレージモジュール４５５S（例えば、データベース）の３つすべてを含むが、これらに限定されないノードソフトウェアを実行できる。プロトコルエンジン４０１は、標準的に、トランザクション１５２の異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。トランザクション１５２j（Txj）が受信され、別の先行するトランザクション１５２i（Txm-１）のアウトプット（例えばUTXO）をポイントするインプットを有するとき、プロトコルエンジン４５１は、Txj内のアンロックスクリプトを識別し、それをスクリプトエンジン４５２に渡す。プロトコルエンジン４５１は、更に、Txjのインプットの中のポインタに基づき、Txiを識別し検索する。Txiはブロックチェーン１５０上で公開されてよい。この場合、プロトコルエンジンは、ノード１０４に格納されているブロックチェーン１５０のブロック１５１のコピーからTxiを取得できる。又は、Txiは、まだブロックチェーン１５０上で公開されていない可能性がある。その場合、プロトコルエンジン４５１は、ノード１５４によって保持されている未公開トランザクションの順序付きセット１５４からTxiを取得することができる。いずれの方法も、スクリプトエンジン４５１は、Txiの参照されるアウトプットの中のロックスクリプトを識別し、これをスクリプトエンジン４５２に渡す。
図４は、UTXO又はアウトプットに基づくモデルの例における、ネットワーク１０６の各ブロックチェーンノード１０４で実行され得るノードソフトウェア４５０の例を示す。別のエンティティが、ネットワーク１０６上でノード１０４として分類されずに、つまり、ノード１０４に必要なアクションを実行せずに、ノードソフトウェア４５０を実行できることに注意する。ノードソフトウェア４５０は、プロトコルエンジン４５１、スクリプトエンジン４５２、スタック４５３、アプリケーションレベルの決定エンジン４５４、及び１つ以上のブロックチェーン関連機能モジュールのセット４５５を含んでよいが、それらに限定されない。各ノード１０４は、合意モジュール４５５C（例えば、proof-of-work）、伝播モジュール４５５P、及びストレージモジュール４５５S（例えば、データベース）の３つすべてを含むが、これらに限定されないノードソフトウェアを実行できる。プロトコルエンジン４０１は、標準的に、トランザクション１５２の異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。トランザクション１５２j（Txj）が受信され、別の先行するトランザクション１５２i（Txm-１）のアウトプット（例えばUTXO）をポイントするインプットを有するとき、プロトコルエンジン４５１は、Txj内のアンロックスクリプトを識別し、それをスクリプトエンジン４５２に渡す。プロトコルエンジン４５１は、更に、Txjのインプットの中のポインタに基づき、Txiを識別し検索する。Txiはブロックチェーン１５０上で公開されてよい。この場合、プロトコルエンジンは、ノード１０４に格納されているブロックチェーン１５０のブロック１５１のコピーからTxiを取得できる。又は、Txiは、まだブロックチェーン１５０上で公開されていない可能性がある。その場合、プロトコルエンジン４５１は、ノード１５４によって保持されている未公開トランザクションの順序付きセット１５４からTxiを取得することができる。いずれの方法も、スクリプトエンジン４５１は、Txiの参照されるアウトプットの中のロックスクリプトを識別し、これをスクリプトエンジン４５２に渡す。
【0071】
スクリプトエンジン４５２は、従って、Txiのロックスクリプト、及びTxj対応するインプットからのアンロックスクリプトを有する。例えば、Tx０及びTx１が図２に示されるが、同じことがトランザクションの任意のペアに適用され得る。スクリプトエンジン４５２は、前述のように２つのスクリプトを一緒に実行し、これらは、使用されているスタックに基づくスクリプト言語（例えばScript）に従い、スタック４５３にデータを置くことと、データを検索することとを含む。
【0072】
スクリプトを一緒に実行することにより、スクリプトエンジン４５２は、アンロックスクリプトがロックスクリプトの中で定義された１つ以上の基準を満たすか否か、つまり、それがロックスクリプトが含まれるアウトプットを「アンロック」するか否かを決定する。スクリプトエンジン４５２は、この決定の結果をプロトコルエンジン４５１に返す。スクリプトエンジン４５２は、アンロックスクリプトは対応するロックスクリプトの中で指定された１つ以上の基準を満たすと決定した場合、結果「真」を返す。その他の場合、それは結果「偽」を返す。
【0073】
アウトプットに基づくモデルでは、スクリプトエンジン４５２からの結果「真」は、トランザクションの有効性についての条件のうちの１つである。標準的に、同様に満たされなければならない、プロトコルエンジン４５１により評価される１つ以上の更なるプロトコルレベルの条件が更にあり、Txjのアウトプットの中で指定されたデジタルアセットの総量がそのインプットによりポイントされる総量を超えないこと、Txiのポイントされるアウトプットは別の有効なトランザクションにより未だ使用されていないこと、等である。プロトコルエンジン４５１は、１つ以上のプロトコルレベルの条件と一緒にスクリプトエンジン４５２からの結果を評価し、それら全部が真である場合、トランザクションTxjを妥当性確認する。プロトコルエンジン４５１は、トランザクションが有効であるかどうかの指示を、アプリケーションレベル決定エンジン４５４に出力する。Txjが実際に妥当性確認されたことのみを条件として、決定エンジン４５４は、合意モジュール４５５C及び伝播モジュール４５５Pの一方又は両方を、それらの各々のブロックチェーンに関連する機能をTxjに関して実行するよう制御することを選択してよい。これは、ブロック１５１に組み込むためにノードの各々の順序付きトランザクションセット１５４にTxjを追加する合意モジュール４５５Cと、ネットワーク１０６内の別のブロックチェーンノード１０４にTxjを転送する伝播モジュール４５５Pを含む。任意的に、実施形態では、アプリケーションレベル決定エンジン４５４は、これらの機能のうちのいずれか又は両方をトリガする前に、１つ以上の追加条件を適用してよい。例えば、決定エンジンは、トランザクションがだとうせされたこと、及び十分なトランザクション手数料が残されることの両方を条件としてのみ、トランザクションを公開することを選択してよい。
【0074】
用語「真（true）」及び「偽（false）」は、本願明細書では、必ずしも単一の２進数字（ビット）のみの形式で表現される結果を返すことに限定しないが、それは勿論１つの可能な実装であることに留意する。より一般的には、「真」は、成功又は肯定的な結果を示す任意の状態を表すことができ、「偽」は、不成功又は非肯定的な結果を示す任意の状態を表すことができる。例えば、アカウントに基づくモデルでは、「真」の結果は、署名の暗示的なプロトコルレベルの検証と、スマートコントラクトの追加の肯定的なアウトプットとの組合せにより示され得る（全体の結果は、両方の個々の結果が真である場合に、真を伝達すると考えられる）。
【0075】
データのブロック
前述のように、スクリプトパターンOP_FALSE OP_RETURNは、ブロックチェーンにアップロードされるデータを使用不可能な出力に含めることを容易にする。これを実現するために、ユーザは通常、アップロードするデータのサイズに応じた少額の料金を支払う。例えば、BitcoinSVでは、トランザクションデータのペイロードサイズは事実上無制限であるため、ユーザは単純なテキストからフルビデオまで何でもアップロードできる。他のブロックチェーンでは、スクリプトパターンOP_RETURNのみを使用してアウトプットを使用不可能にすることができる。
前述のように、スクリプトパターンOP_FALSE OP_RETURNは、ブロックチェーンにアップロードされるデータを使用不可能な出力に含めることを容易にする。これを実現するために、ユーザは通常、アップロードするデータのサイズに応じた少額の料金を支払う。例えば、BitcoinSVでは、トランザクションデータのペイロードサイズは事実上無制限であるため、ユーザは単純なテキストからフルビデオまで何でもアップロードできる。他のブロックチェーンでは、スクリプトパターンOP_RETURNのみを使用してアウトプットを使用不可能にすることができる。
【0076】
スクリプトオペコードOP_RETURNと、任意のデータを元帳に格納するために使用できるスクリプトオペコードOP_FALSE OP_RETURNの組み合わせは、ブロックチェーンのサイズの増加につながり、完全なデータを格納する必要のあるブロックチェーンノードのディスクスペースを消費してしまう。
【0077】
ビットコイントランザクション内の一部のデータペイロード（例えば、銀行口座番号、パスポート番号）の配布が管理当局によってブロックされているシナリオでは、一見、これは大きな問題ではない。ペイロードは使用不可能なアウトプット内にあるため、このデータをブロックしてもコインの移動は制限されないのである。従って、UTXOセットはこのアクションの影響を受けない。ただし、第３者がUTXOセットを検証する必要がある場合は、問題が提起される。これは、トランザクションID（トランザクション内のすべてのデータのダブルハッシュと等しい）を生成するために、トランザクションのすべてのフィールドが必要であるためである。従って、ブロックされたデータがないと、第３者はトランザクションの使用可能なアウトプットの完全性を妥当性確認できない。また、ブロックヘッダに格納されているすべてのトランザクションのMerkleルートを計算するときにトランザクションIDが必要になるため、第３者はトランザクションを含むブロックを妥当性確認できない。例えば新たなマイナーがビットコインネットワークに参入した場合に、この問題に直面する。彼らはブロックチェーン全体をダウンロードし、UTXOセットを構築するためにすべてのトランザクションを妥当性確認しなければならない。彼らは、すべてのデータが彼らに利用可能であり、それが改ざんされていない場合、及びその場合にのみ、これを行うことができる。これは、ブロックチェーンの不変性と呼ばれるものである。
【0078】
本開示の実施形態により、ネットワーク参加者は、ブロックチェーンの履歴の完全性を検証することが可能でありながら、データをブロックすることができる。本開示の実施形態は、ブロックチェーントランザクション又はその一部に存在するデータをブロックするために使用できる。
【0079】
図５は、初期化ベクトルと入力メッセージ（preimage）を入力として受け取り、ハッシュ出力（ハッシュダイジェスト）を提供するハッシュ関数を示している。ハッシュ関数Hは、任意のサイズのデータを固定サイズのデータにマッピングする関数である。すなわち、kビットのハッシュ関数Hは次のように定義される関数である：
ここで、kは正の整数である。
【数2】
【0080】
暗号化ハッシュ関数には、次のプロパティが必要である：
－決定性（Deterministic）：ハッシュ関数は、同じプリイメージに対して同じダイジェストを生成する必要がある。
－速度：ハッシュダイジェストは、迅速に計算できる必要がある。
－一方向（プリイメージ耐性）：ダイジェストが与えられた場合に、プリイメージを見つけることは不可能である必要がある。
－弱い衝突耐性（第２プリイメージ耐性）：ハッシュ値が与えられた場合、同じハッシュを生成する任意のメッセージを生成することは不可能である必要がある。
－強い衝突耐性：２つのプリイメージが同じハッシュを生じることは実現不可能である必要がある。
－拡散：プリイメージの少なくとも１ビットが変更されると、ダイジェスト内の各ビットが５０％の確率で変更される。
－決定性（Deterministic）：ハッシュ関数は、同じプリイメージに対して同じダイジェストを生成する必要がある。
－速度：ハッシュダイジェストは、迅速に計算できる必要がある。
－一方向（プリイメージ耐性）：ダイジェストが与えられた場合に、プリイメージを見つけることは不可能である必要がある。
－弱い衝突耐性（第２プリイメージ耐性）：ハッシュ値が与えられた場合、同じハッシュを生成する任意のメッセージを生成することは不可能である必要がある。
－強い衝突耐性：２つのプリイメージが同じハッシュを生じることは実現不可能である必要がある。
－拡散：プリイメージの少なくとも１ビットが変更されると、ダイジェスト内の各ビットが５０％の確率で変更される。
【0081】
ハッシュ関数は、一部のデータの完全性をチェックする方法を提供する。ハッシュダイジェストのプリイメージとして与えられたデータについて、人はそのデータの現在のハッシュダイジェストを以前のものと比較することによって、後でそのデータの完全性をチェックすることができる。
【0082】
通常、ハッシュ出力を妥当性確認するために、第３者は入力メッセージのすべての内容を必要とする。本開示の実施形態は、第３者は、メッセージの機密部分にアクセスすることなく、ハッシュ出力が有効であることを妥当性確認することができる。「機密」データとは、ここでは、ユーザ又は管理主体がブロックする可能性のあるデータを指す。機密データには、ユーザにとってプライベートなもの（例えば、銀行口座番号、パスポート番号）、違法なもの、悪意のあるもの、中傷的なもの、見苦しいものなどがある。図５に示すように、既知の技術とは対照的に、本開示の実施例では、入力メッセージ（プリイメージ）を使用して、公開メッセージ、機密メッセージ、及び入力メッセージ内の公開ビットと機密ビットの位置を識別するマスクを決定する。機密メッセージは、入力が論理回路への入力として提供される（入力として公開メッセージとマスクも受信する）ときに、論理回路が出力として入力メッセージ（プリイメージ）をハッシュ関数に提供するように決定される。以下でより詳細に説明するように、論理回路への入力は、入力メッセージ内の他のデータを公衆にアクセス可能にしながら、入力メッセージの機密ビットをブロック／非表示にできるゼロ知識証明を生成するために使用される。入力メッセージ内の任意の場所にある機密ビットは、受信者からブロック／非表示にすることができる。本開示の実施形態は、人が異なるマスクを生成して、同じデータの異なる部分の情報を異なる時間に異なるエンティティに選択的に開示することを可能にする柔軟性を可能にする。
【0083】
図６A～Dは、本開示の実施形態による、メッセージ内のデータをブロックするためのプロセス６００を示すフローチャートである。プロセス６００は、コンピューティング装置により実行されてよい。
【0084】
本開示の実施形態は、まず、ブロックチェーントランザクションデータを含むメッセージと、ブロックチェーンノード１０４によって実行されるプロセス６００を参照して説明される。これらの例では、メッセージは、１つ以上のブロックチェーントランザクションの全部又は一部である場合がある。
【0085】
ステップS６０２で、ブロックチェーンノード１０４は、ブロックチェーントランザクションの形式でメッセージを受信し、ステップS６０４で、ここでRealContentと呼ばれるブロックチェーントランザクションのコピーを作成する。図７に示すように、RealContentの長さはLビットである。このコピーは実際のデータとして伝えられるが、ブロックチェーンノード１０４は、その特定のコピーで実際に表示されるべき情報を制御する。
【0086】
ステップS６０４で、ブロックチェーンノード１０４は、ハッシュアルゴリズムに従ってメッセージ文字列RealContentをパディングビット７０２でパディングし、ここではRealContentPadと呼ばれるメッセージ文字列を生成する。パディングの結果、メッセージ文字列RealContentPadは、ハッシュアルゴリズムによって定義された入力メッセージサイズの正の整数倍の長さを持つ。ハッシュアルゴリズムの一例は、SHA２５６ハッシュ関数である。
【0087】
ビットコインに関しては、SHA２５６ハッシュ関数を使用してトランザクションのTxIDを導出する。特に、トランザクションID（Transaction ID、TxID）は、シリアル化されたビットコイントランザクション（例えば、３２ビットバージョン、３２ビットLockTime、トランザクションインプットのリスト、Dataを含むトランザクションアウトプットのリスト）のダブルSHA２５６ハッシュ（又はSHA２５６d=SHA２５６（SHA２５６（.）））である。
【0088】
SHA２５６の圧縮関数は次のとおりである：
ここで、２５６ビットのチェーン値と５１２ビットのメッセージブロックを２５６ビットの出力値に圧縮する。従って、図７に示すように、メッセージ文字列RealContentPadの長さは５１２nビットであり、nは正の整数である。
【数3】
【0089】
メッセージRealContentの長さがlであり、４４７ビット以下であると仮定すると、ステップS６０４で実行されるパディングは、RealContentの末尾に値が１の単一ビットを追加することを含む。次に、k個の０のビットが追加される。ここで、kは、式l+１+k=４４８mod５１２の最小の正の解である。最後に、バイナリ形式で記述されたメッセージ長lの表現である６４ビットのブロックが追加される。例えば、メッセージRealContentの長さが２４ビットであるとする。メッセージRealContentは最初に１でパディングされ、次に４４８-（２４+１）=４２３個の０のビットが６４ビットブロックと共に追加されて、RealContentが５１２ビットのパディングされたメッセージRealContentPadに変換される。
【0090】
一般的なハッシュ関数は、反復的なアプローチ（Merkle-Damgard構築として知られている）に従って、より長いメッセージM（４４８ビット以上）を処理する。これは、Mをk個のビットのn個のブロックに分割する。すなわち：
個々のメッセージブロックは、次式のように定義される圧縮関数によって繰り返し処理される。
ここで、m、kは正の整数値、kはチェーン値のサイズ、mはメッセージブロックのサイズを表す。
【数4】
【数5】
【0091】
RealContentPadの長さが５１２ビットの場合（ステップS６０８を参照）、プロセス６００は図６Bに示すステップS６１０に進む。
【0092】
ステップS６１０で、ブロックチェーンノード１０４は、５１２ビットのパディングされたメッセージRealContentPadのビットの中の少なくとも１つの機密ビットの場所を識別する。ブロックチェーンノード１０４は、ブロックチェーンノード１０４のメモリをクエリすることによってステップS６１０を実行する。
【0093】
例えば、ブロックチェーンノード１０４のメモリには、以前に機密と識別されたコンテンツに対応する１つ以上のビット列が格納されている場合がある。
【0094】
別の例では、ブロックチェーンノード１０４のメモリに、機密データを定義する１つ以上の事前に定義されたルールが格納されている場合がある。例えば、メモリには、特定のドメイン名を含む任意のURLをブロックする必要があることを示す事前に定義されたルールが格納されている場合がある。別の例では、「パスポート番号」という単語の後に続く９桁の数字をブロックする必要があるという事前に定義されたルールがメモリに格納されている場合がある。
【0095】
ステップS６１２で、ブロックチェーンノード１０４はマスクビット列Maskを生成する。これは、５１２ビットのパディングされたメッセージRealContentPad内の公開ビット（複数可）と機密ビット（複数可）の位置を識別する。特に、ブロックチェーンノード１０４は、次式に従ってマスクビット列Maskを生成する：
【数6】
【0096】
他の実施形態では、ステップS６１０及びS６１２の代替として、ブロックチェーンノード１０４は、ブロックチェーンノード１０４のメモリからマスクビット列を読み出すことによって、マスクビット列Maskを取得することができる。マスクビット列Maskの取得方法にかかわらず、この実施形態では、マスクビット列Maskの長さは５１２ビットである。
【0097】
ステップS６１４で、ブロックチェーンノード１０４は、すべての機密ビットに同じ所定値（例えば、０又は１）を割り当て、公開ビット値を保持することでRealContentPadを変更することによって、公開ビット列PublicDataを計算する。従って、この実施形態では、公開ビット列PublicDataの長さは５１２ビットである。公開ビット列PublicDataがどのように計算されるかを説明するために、ここでは、すべての機密ビットに０の値を割り当てることによってRealContentPadを変更することを参照するが、これは単なる例である。
【0098】
ステップ６１４で、ブロックチェーンノード１０４は、機密ビット列SecretDataも計算する。これは５１２ビットの長さを持ち、機密ビットを含む。ブロックチェーンノード１０４は、RealContentPadを取得し、そこに含まれる機密ビットを保持することによって、秘密ビット列SecretDataを計算することができ、SecretDataの残りのビットは任意の値を取ることができる。
【0099】
秘密ビット列SecretDataは、RealContentPadが、公開ビット列PublicData、及び秘密ビット列SecretDataとマスクビット列Maskを入力として使用するビット毎の論理計算（複数の論理演算を含む）の出力と等しいという要件を満たしている。
【0100】
一例として、秘密ビット列SecretDataは、次の要件を満たす場合がある：
【数7】
【0101】
特に、秘密ビット列SecretDataは、RealContentPadが（i）公開ビット列と、（ii）マスクビット列と秘密ビット列のビットごとのAND計算の結果と、のビットごとのXOR計算に等しいという要件を満たす。この構成は、図８に破線で示された回路の一部として示されている。上記で説明し、図８に示したものとは別の論理回路構成が可能であることは、論理回路構成が入力として（i）公開ビット列PublicData、（ii）秘密ビット列SecretData、及び（iii）マスクビット列Mask、を取り込み、及びそこに含まれるビットごとの論理演算が出力としてRealContentPadを提供することを前提としている。
【0102】
ステップS６１６で、ブロックチェーンノード１０４は、メッセージ文字列RealContentPadをハッシングすることによってハッシュ値Hashvalueを計算する。ここで、Hashvalue=SHA２５６（RealContentPad）である。ステップS６１６で使用される公開初期化ベクトルHi
０は、SHA２５６ハッシュアルゴリズムが使用される場合の実施形態では、Secure Hash Standard（SHS）からのものになる。SHA２５６の場合、初期ハッシュ値Hi
０は、次の８個の３２ビットワードで構成されるものとする：
【数8】
【0103】
ステップS６１８で、ブロックチェーンノード１０４は、以下を使用してゼロ知識証明を生成する：
公開ビット列、PublicData、
マスクビット列、Mask、
出力ハッシュ値、Hashvalue、
秘密ビット列、SecretData。
公開ビット列、PublicData、
マスクビット列、Mask、
出力ハッシュ値、Hashvalue、
秘密ビット列、SecretData。
【0104】
ゼロ知識証明（Zero-Knowledge Proofs （ZKP））は、暗号の構成ブロックであり、パーティ（証明者）が、ステートメントの真実であること以外の情報を明らかにすることなく、ステートメントが真実であることを別のパーティ（検証者）に証明することを可能にする。
【0105】
ステップS６１８で生成されたゼロ知識証明は、証明者がステートメントの妥当性を証明するだけでなく、秘密の情報について何も明らかにすることなく、それを知っていることを保証する証明の一種である。
【0106】
対話型のゼロ知識証明は証明者と検証者の間の相互作用を必要とするが、証明者がステートメントが真であることを検証者に納得させるために「証明（プルーフ、proof）」と呼ばれるメッセージを１つだけ生成する非対話型ゼロ知識（Non-Interactive Zero-Knowledge）証明も存在する。ステップS６１８で生成されるゼロ知識証明はNIZK証明である可能性がある。
【0107】
zkSNARK（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）は、簡潔で証明が非常に短く検証が容易なNIZKの知識証明である。ステートメントは、ステートメントの証明を生成するために使用される論理回路によって表される。最も効率的な構成では、検証者は単に定数のグループ操作を実行する。ステップS６１８で生成されるゼロ知識証明はzkSNARK証明である可能性がある。
【0108】
ステップS６１８で生成されたゼロ知識証明がzkSNARK証明である例では、zkSNARK証明の生成で証明鍵（ブロックチェーンノード１０４のメモリから読み出される）が追加で使用される。
【0109】
zkSNARKプロトコルは、一般に次の３つのフェーズで構成される。
ａ．設定（Setup）ステートメントが与えられると、代数回路生成、R１CS（Rank-１ Constraint System）、QAP（Quadratic Span Programs）などの幾つかの内部ステップを通じて、証明鍵と検証鍵のペアが計算される。これらにアクセスすると攻撃が発生する可能性があるため、プライベート情報は破棄され、二度と存在しないようにする必要がある。
ｂ．証明生成（Proof generation）公開情報、証明鍵、公開及び非公開入力を与えられると、証明者は、証明を生成して検証者に送信する。
ｃ．検証（Verification）公開情報、検証鍵、及び公開入力が与えられると、検証者は検証を実行する。
ａ．設定（Setup）ステートメントが与えられると、代数回路生成、R１CS（Rank-１ Constraint System）、QAP（Quadratic Span Programs）などの幾つかの内部ステップを通じて、証明鍵と検証鍵のペアが計算される。これらにアクセスすると攻撃が発生する可能性があるため、プライベート情報は破棄され、二度と存在しないようにする必要がある。
ｂ．証明生成（Proof generation）公開情報、証明鍵、公開及び非公開入力を与えられると、証明者は、証明を生成して検証者に送信する。
ｃ．検証（Verification）公開情報、検証鍵、及び公開入力が与えられると、検証者は検証を実行する。
【0110】
zkSNARKプロトコルは、次のプロパティを満たす必要がある。
完全性（Completeness）：ステートメントが真であり、検証者と証明者が正直である場合、証明は受け入れられる。
健全性（Soundness）：ステートメントが偽であれば、不正な証明者は無視できる確率を除いて、それが真実であることを正直な検証者に納得させることができない。
ゼロ知識（Zero-Knowledge）：ゼロ知識証明は、ステートメントの真実以外の情報を検証者に明らかにしない。
簡潔（Succinct）：証明は回路サイズよりも短く、検証者は回路サイズよりも少ない数の暗号操作を行う必要がある。
非対話型（Non-Interactive）：証明は１ステップのみで検証者に送信される。
知識の引数（Arguments of Knowledge）：証明は計算上健全であると見なされる。すなわち、（量子コンピュータのような）無制限の証明者は、検出されることなく虚偽のステートメントを証明できる。
知識（Knowledge）：証明者は確かに証拠（witness）を知っており、証拠（これはステートメントを証明するために必要な秘密の入力である）にアクセスすることなく証明を構成することはできない。すなわち、証明者と対話して証拠を出力する抽出アルゴリズムが存在する。
完全性（Completeness）：ステートメントが真であり、検証者と証明者が正直である場合、証明は受け入れられる。
健全性（Soundness）：ステートメントが偽であれば、不正な証明者は無視できる確率を除いて、それが真実であることを正直な検証者に納得させることができない。
ゼロ知識（Zero-Knowledge）：ゼロ知識証明は、ステートメントの真実以外の情報を検証者に明らかにしない。
簡潔（Succinct）：証明は回路サイズよりも短く、検証者は回路サイズよりも少ない数の暗号操作を行う必要がある。
非対話型（Non-Interactive）：証明は１ステップのみで検証者に送信される。
知識の引数（Arguments of Knowledge）：証明は計算上健全であると見なされる。すなわち、（量子コンピュータのような）無制限の証明者は、検出されることなく虚偽のステートメントを証明できる。
知識（Knowledge）：証明者は確かに証拠（witness）を知っており、証拠（これはステートメントを証明するために必要な秘密の入力である）にアクセスすることなく証明を構成することはできない。すなわち、証明者と対話して証拠を出力する抽出アルゴリズムが存在する。
【0111】
ステップS６１８で生成されるゼロ知識証明は、マルチパーティ計算（multi-party computation （MPC））ベースのゼロ知識証明（例えば、zkBOO）、zkSNARK、STARK、又はBulletproofなど、他の任意の既知のタイプのゼロ知識証明であってもよい。
【0112】
当業者に知られているように、証明鍵及び検証鍵はzkSNARKのコンテキスト内で機能するが、MPCベースの証明（zkBOOなど）、STARK、又はBulletproofなどの他のタイプのゼロ知識証明では機能しない。
【0113】
ステップS６２０で、ブロックチェーンノード１０４はメッセージ文字列RealContentPadから機密ビットを削除し、変更されたメッセージ（例えば、変更されたブロックチェーントランザクション）RealContentPublicを生成する。一例では、ブロックチェーンノード１０４は、すべての機密ビットに同じ所定値（例えば、０）を割り当て、RealContentPadの公開ビット値を保持することによって、ステップS６２０を実行する。RealContentPadが５１２ビットに等しい長さを持つこの例では、変更されたメッセージRealContentPublicも５１２ビットに等しい長さを持つことが理解される。
【0114】
変更されたメッセージ（例えば、変更されたブロックチェーントランザクション）が生成されると、元のメッセージはコンピューティング装置のメモリから削除され、変更されたメッセージに置き換えられる場合がある。代替として、元のメッセージは、変更されたメッセージ（例えば、変更されたブロックチェーントランザクション）の生成後にコンピューティング装置のメモリに保持される場合がある。
【0115】
変更されたブロックチェーントランザクションRealContentPublicは、次に受信者に出力される。例えば、変更されたブロックチェーントランザクションRealContentPublicは、ブロックチェーンネットワーク１０６内の受信者ブロックチェーンノード１０４に送信される場合がある。
【0116】
受信者ブロックチェーンノード１０４が、変更されたブロックチェーントランザクションRealContentPublicが有効であることを証明できるようにするために、ブロックチェーンノード１０４は更に次のものを送信する：
ゼロ知識証明、
出力ハッシュ値、Hashvalue。
ゼロ知識証明、
出力ハッシュ値、Hashvalue。
【0117】
マスクビット列Maskが公衆に知られている場合、ブロックチェーンノード１０４がマスクビット列Maskを受信者ブロックチェーンノード１０４に送信する必要はない。しかし、マスクビット列Maskが公衆に知られていない場合、ブロックチェーンノード１０４はマスクビット列Maskを受信者ブロックチェーンノード１０４に更に送信する。
【0118】
図１０Aに、RealContentPublicが５１２ビット長の場合に検証者コンピューティング装置によって実行される検証プロセス１０００を示す。コンピューティング装置が受信者ブロックチェーンノード１０４である実施形態では、ステップS１００２で、受信者ブロックチェーンノード１０４は変更されたブロックチェーントランザクションRealContentPublicを取得する。一例では、受信者ブロックチェーンノード１０４は、変更されたブロックチェーントランザクションRealContentPublicを、（プロセス６００を実行する）送信者ブロックチェーンノード１０４から受信する。変更されたブロックチェーントランザクションRealContentPublicの長さが５１２ビット（ステップS１００４で決定される）の場合、プロセス１０００はステップS１００６に進む。
【0119】
ステップS１００６で、受信者ブロックチェーンノード１０４は、出力ハッシュ値HashvalueのSHA２５６ハッシュを計算することによって出力ハッシュ値Hashvalueを検証し、SHA２５６（Hashvalue）が変更されたブロックチェーントランザクションRealContentPublicに関連付けられた公開トランザクションIDと等しいことを確認する。この検証が失敗した場合、プロセス１０００は終了する。受信者ブロックチェーンノード１０４が出力ハッシュ値Hashvalueの検証に成功した場合、プロセス１０００はステップS１００８に進む。
【0120】
ステップS１００８で、受信者ブロックチェーンノード１０４は、以下を使用してゼロ知識証明を検証する：
ゼロ知識証明、
変更されたメッセージ、RealContentPublic、
ステップS６１６で使用される入力ハッシュ値（このシナリオでは、初期化ベクトルHi ０）、
出力ハッシュ値、Hashvalue、
マスクビット列、Mask。
ゼロ知識証明、
変更されたメッセージ、RealContentPublic、
ステップS６１６で使用される入力ハッシュ値（このシナリオでは、初期化ベクトルHi ０）、
出力ハッシュ値、Hashvalue、
マスクビット列、Mask。
【0121】
受信者ブロックチェーンノードがゼロ知識証明の検証に成功した場合、受信者ブロックチェーンノード１０４は、変更されたブロックチェーントランザクションRealContentPublicが有効であることを検証できる。
【0122】
ステップS６１８で生成されたゼロ知識証明がzkSNARK証明である例では、zkSNARK証明の検証で検証鍵（受信者ブロックチェーンノード１０４のメモリから読み出される）が追加で使用される。
【0123】
当業者に知られているように、ゼロ知識証明の検証は、入力情報を使用した１つ以上のチェックを含み、検証の出力は、ゼロ知識証明が有効であるか無効であるかを示す決定である。実行されるチェックは、ゼロ知識証明の種類に固有であり、当業者に知られている。すべての種類のゼロ知識証明について、検証者は、すべてのチェックが合格した場合にのみ、ゼロ知識証明を受け入れる。
【0124】
zkSNARK証明のコンテキストでは、回路（例えば、図８に示す）は設定フェーズ中に使用されているため、設定パラメータ（証明鍵と検証鍵）によって、専用回路が実際に使用されていることが保証される。証明者は、証明鍵と回路を使用してzkSNARK証明を生成する。検証者は検証鍵を使用してチェックを実行する。検証鍵は、検証者が回路を直接使用せずに、事前に定義されたステートメント（回路を意味する）が実際に妥当性確認されていることを検証者に保証する。対照的に、Bulletproofのコンテキストでは、証明者と検証者は最初に回路について合意する。次に、回路に基づいて、証明者は証明を生成し、それを妥当性確認のために検証者に送信する。検証者は、証明を妥当性確認するために回路の知識も使用する。その他のMPCベースの証明は、検証者が検証プロセスで回路を直接使用したという点で、Bulletproofと似ている。
【0125】
ステップS１００６とS１００８は任意の順序で実行できるが、ステップS１００６はステップS１００８よりも実行する計算量が少ないため、ステップS１００６を最初に実行してから、ステップS１００６のチェックが成功した場合にのみ、ステップS１００８に進む方が有利である。
【0126】
以下では、マスクビット列Maskの効果を説明するための簡単な例を参照する。AliceがRealContent="１１０１１０１１"を持っていると仮定する。ここで、第１４ビット"１１０１"は彼女が他の人と共有できる彼女の公開データに対応し、"１０１１"は彼女の秘密データである。また、AliceはRealContentをBobと共有する必要があるが、第１４ビットのみを開示したいとする。従って、この特定の例では、Mask="００００１１１１"となる。また、Bobが以下を知っているとする：
【数9】
【0127】
マスクビット列Maskがなければ、構成は次のようになる：
【数10】
【0128】
Aliceが不誠実であれば、公開データについてBobに次のように嘘をつくことができる（例えば、１１０１を０１１０に変更する）。
１．Aliceは偽の公開データをPublicData=０１１０００００として選択し、それによって機密ビット「１０１１」の各々が０に設定されている。
２．彼女はまた、８ビット１０１１１０１１全体を秘密データとして選択する。
ａ．１１０１１０１１=０１１０００００XOR１０１１１０１１であり、回路の出力ハッシュ値は実際のOutput=SHA２５６（１１０１１０１１）と同じになることに注意する。
従って、マスクがなければ、証明がまだ有効である間、彼女はデータの公開部分について嘘をつくことができる。
１．Aliceは偽の公開データをPublicData=０１１０００００として選択し、それによって機密ビット「１０１１」の各々が０に設定されている。
２．彼女はまた、８ビット１０１１１０１１全体を秘密データとして選択する。
ａ．１１０１１０１１=０１１０００００XOR１０１１１０１１であり、回路の出力ハッシュ値は実際のOutput=SHA２５６（１１０１１０１１）と同じになることに注意する。
従って、マスクがなければ、証明がまだ有効である間、彼女はデータの公開部分について嘘をつくことができる。
【0129】
しかし、マスクが使用されていて公に知られている場合、次の理由でこの攻撃は不可能になる。
ａ．彼女は偽の入力PublicData=０１１０００００を選択し、Bobと共有する。１０１１１０１１は部分的に偽物である秘密データである（すなわち、左端の４ビット）。
ｂ．Bobはマスク値００００１１１１を知っている。
ｃ．０１１０００００、００００１１１１、及びOutput（=SHA２５６（１１０１１０１１））が与えられると、次式の理由で、zkSNARK証明はBobによって検証されない：
従って、不正なAliceは、検出されずにコンテンツを操作することはできない。
ａ．彼女は偽の入力PublicData=０１１０００００を選択し、Bobと共有する。１０１１１０１１は部分的に偽物である秘密データである（すなわち、左端の４ビット）。
ｂ．Bobはマスク値００００１１１１を知っている。
ｃ．０１１０００００、００００１１１１、及びOutput（=SHA２５６（１１０１１０１１））が与えられると、次式の理由で、zkSNARK証明はBobによって検証されない：
【数11】
【0130】
上記の例では、"１０１１"の各機密ビットが０に設定されるが、これは単なる例である。別の方法として、"１０１１"の各機密ビットをPublicData=０１１０１１１１のように１に設定することもできる。これにより、論理計算は次のように変更される：
ゼロを使用した上記のシナリオの結果は：
０１１０１１１１ AND NOT（００００１１１１）
これは以下の通りになる：
０１１０ ００００
【数12】
０１１０１１１１ AND NOT（００００１１１１）
これは以下の通りになる：
０１１０ ００００
【0131】
ただし、各機密ビットを１に設定すると、追加の操作（AND）が必要になるため、各機密ビットを０に設定するよりも効率が悪くなる。
【0132】
ここで、図６Aを再び参照する。
【0133】
RealContentPadの長さが５１２ビットより長い場合、つまり５１２nビットの長さを有し、n≧２である場合（ステップS６０８を参照）、プロセス６００は図６Bに示すステップS６２２に進む。つまり、RealContentのサイズが４４７ビットを超える場合、プロセス６００は図６cに示すステップS６２２に進む。
【0134】
ステップS６２２で、ブロックチェーンノード１０４は、メッセージ文字列RealContentPadを、ハッシュ関数によって定義された入力メッセージサイズに対応する５１２ビットの長さを各々持つ複数のメッセージブロックRealContentiに分割する。
【数13】
【0135】
図７は、RealContentPadが３０７２ビット長で、５１２ビット長の６つのメッセージブロックに分割される例を示している。
【0136】
ステップS６２４でiの値を１に設定し、ステップS６２６でブロックチェーンノード１０４がRealContentiを読み出す。１回目のステップS６２６が実行されると、ブロックチェーンノード１０４は第１５１２ビットメッセージブロックRealContent１を読み出すことが分かる。
【0137】
ステップS６２８で、ブロックチェーンノード１０４は入力ハッシュ値を読み出す。１回目のステップS６２８が実行されると、ブロックチェーンノード１０４は、SHA２５６ハッシュアルゴリズムが使用される場合の実施形態では、Secure Hash Standard（SHS）からの事前に決定された公開初期化ベクトルを読み出すことが理解されるだろう。その後の回でステップS６２８が実行されると、ブロックチェーンノード１０４は以前の出力ハッシュ値、すなわちHashvaluei-１を読み出す。SHA２５６アルゴリズムのコンテキストでは、入力ハッシュ値の長さは２５６ビットである。
【0138】
ステップS６３０で、ブロックチェーンノード１０４は、メッセージブロックRealContentiをハッシングすることによってハッシュ値Hashvalueiを計算する。ここで、Hashvaluei=SHA２５６（RealContenti）である。ステップS６２８で読み出された入力ハッシュ値は、ステップS６３０で実行される圧縮で使用される。ハッシュ値Hashvaluei-１は、次回にステップS６２８が実行されるときに入力ハッシュ値として読み出される。例えば、ハッシュ値Hashvalue１は、第２メッセージブロックRealContent２の圧縮の入力ハッシュ値として使用される。
【0139】
メッセージブロックRealContentiが機密ビットを含まない（ステップS６３２で決定される）場合、プロセスは図６Dに示すステップS６４４に進む。処理する機密データで構成されるメッセージブロックが更にある場合（ステップS６４４で決定）、プロセスはステップS６４６に進み、ここでブロックチェーンノード１０４はiの値を１つ増やし、プロセス６００はステップS６２６にループバックし、ここでブロックチェーンノード１０４は次のRealContentiを読み出す。
【0140】
メッセージブロックRealContentiが機密ビットを含む（ステップS６３２で決定される）場合、ブロックチェーンノード１０４は、図６Dに示すステップS６３４、S６３６、S６３８、S６４０、及びS６４２を実行する。S６３４、S６３６、S６３８、S６４０、及びS６４２は、S６１０、S６１２、S６１４、S６１８、及びS６２０に相当する。
【0141】
ステップS６４２で、ブロックチェーンノード１０４はRealContentPadからRealContentiの機密ビットを削除する。一例では、ブロックチェーンノード１０４は、RealContentPad内のすべての機密ビットに同じ所定値（例えば、０）を割り当て、RealContentPadの公開ビット値を保持することによって、ステップS６４２を実行する。
【0142】
ステップS６３４及びS６３６の代替として、ブロックチェーンノード１０４は、ブロックチェーンノード１０４のメモリからマスクビット列を読み出すことによって、マスクビット列Maskiを取得することができる。マスクビット列Maskiの取得方法にかかわらず、この実施形態では、マスクビット列Maskiの長さは５１２ビットである。
【0143】
ステップS６４２が実行された後、プロセス６００は前述のステップS６４４に進む。
【0144】
処理する機密データを含むメッセージブロックがこれ以上ない場合（ステップS６４４で決定される）、プロセス６００は終了する。プロセス６００の終了時に、ブロックチェーンノード１０４は、変更されたメッセージ（例えば、変更されたブロックチェーントランザクション）RealContentPublicを生成するために、メッセージ文字列RealContentPadからすべての機密ビットを削除している。
【0145】
上記のことから明らかなように、プロセス６００では、第１メッセージブロックRealContent１の圧縮に、SHA２５６ハッシュアルゴリズムが使用されている場合の実施形態では、Secure Hash Standard（SHS）からのものとなる、事前に決定された公開初期化ベクトルX０が使用されている。第１圧縮のダイジェスト（digest）Hashvalue１は、第２メッセージブロックRealContent２の圧縮で、入力ハッシュ値X１として使用される。第２圧縮のダイジェスト（digest）Hashvalue２は、第３メッセージブロックRealContent３の圧縮で、入力ハッシュ値X２として使用され、以下同様である。図９は、前述のこの再帰的ハッシングの回路例を示している。前述のように、シークレットビット列SecretDataiを導出するために使用される正確なビット単位の論理演算は、図９に示すものと異なる場合がある。各メッセージブロックについて、PublicDatai、Maski、及びSecretDataiの長さは５１２ビットであるため、ビット単位の論理計算の最終出力RealContentiの長さは５１２ビットになる。
【0146】
上記から明らかなように、機密ビットを含む任意のメッセージブロックRealContentiのプロセス６００では、ブロックチェーンノード１０４は次を使用してゼロ知識証明を生成する：
公開ビット列、PublicDatai、
マスクビット列、Maski、
出力ハッシュ値、Hashvaluei、
秘密ビット列SecretDatai。
公開ビット列、PublicDatai、
マスクビット列、Maski、
出力ハッシュ値、Hashvaluei、
秘密ビット列SecretDatai。
【0147】
ステップS６４０で生成されたゼロ知識証明がzkSNARK証明である例では、zkSNARK証明の生成で証明鍵（ブロックチェーンノード１０４のメモリから読み出される）が追加で使用される。
【0148】
複数のメッセージブロックが機密データを持つシナリオでは、図６C及び６Dは反復プロセスを示しているが、幾つかの実施形態では証明生成プロセスは並行して実行される。これらの実施形態では、各メッセージブロックは、前のブロックのハッシングされた出力（ダイジェスト）に対応する入力ハッシュ値（又は、第１メッセージブロックの場合は前述のように事前に決定された初期化ベクトルX０）を使用してハッシングされる。機密データを含むメッセージブロックに関連付けられた計算されたハッシュ値Hashvalueiを使用して、これらのメッセージブロックのゼロ知識証明を互いに独立して並列に生成することができる。この並列実行では、十分な計算リソースがあると仮定して、単一のゼロ知識証明を生成するのにかかる時間と同じ時間でN個のゼロ知識証明を作成できる。この並列証明生成は、大きなメッセージを効率的に処理できるという利点がある。
【0149】
変更されたブロックチェーントランザクションRealContentPublicは、次に受信者に出力される。例えば、変更されたブロックチェーントランザクションRealContentPublicは、ブロックチェーンネットワーク１０６内の受信者ブロックチェーンノード１０４に送信される場合がある。
【0150】
受信者ブロックチェーンノード１０４が、変更されたブロックチェーントランザクションRealContentPublicが有効であることを証明できるようにするために、ブロックチェーンノード１０４は機密ビットを含むRealContenti毎に、更に次のものを送信する：
ゼロ知識証明、
出力ハッシュ値、Hashvaluei。
ゼロ知識証明、
出力ハッシュ値、Hashvaluei。
【0151】
マスクビット列Maskiが公衆に知られている場合、ブロックチェーンノード１０４がマスクビット列Maskiを受信者ブロックチェーンノード１０４に送信する必要はない。しかし、マスクビット列Maskiが公衆に知られていない場合、ブロックチェーンノード１０４はマスクビット列Maskiを受信者ブロックチェーンノード１０４に更に送信する。
【0152】
図１０Bに、RealContentPublicが５１２ビット長を超える（すなわち、５１２nビットの長さを持ち、n≧２である）場合に、検証者コンピューティング装置によって実行される検証プロセス１０５０を示す。
【0153】
ステップS１０１０で、コンピューティング装置（例えば、受信者ブロックチェーンノード１０４）は、RealContentPublicの最後のメッセージブロックRealContenttのハッシュ値Hashvaluetを取得し、HashvaluetのSHA２５６ハッシュを計算して、SHA２５６（Hashvaluet）が変更されたブロックチェーントランザクションRealContentPublicに関連付けられた公開トランザクションIDと等しいことを確認する。
【0154】
最後のメッセージブロックRealContenttが機密ビットを含む例では、受信者ブロックチェーンノード１０４は、送信者コンピューティング装置から最後のメッセージブロックのハッシュ値Hashvaluetを受信する。最後のメッセージブロックRealContenttが機密ビットを含まない例では、受信者ブロックチェーンノード１０４は、送信者コンピューティング装置から最後のメッセージブロックRealContenttのハッシュ値Hashvaluetを受信する場合がある。代替として、受信者ブロックチェーンノード１０４は、最後のメッセージブロックRealContenttのSHA２５６ハッシュを（前のメッセージブロックRealContentt－１のハッシングからの出力ハッシュ値を入力ハッシュ値として使用して）計算して、出力ハッシュ値Hashvaluetを生成する場合がある。
【0155】
この検証が失敗した場合、プロセス１０５０は終了する。ステップS１０１０は、処理するメッセージブロックがなくなったら、プロセス１０５０の最後に実行できるが、ステップS１０１０がゼロ知識証明検証よりも実行する計算量が少ないため、ステップS１０１０を最初に実行してから、ステップS１０１０のチェックが成功した場合にのみ、ゼロ知識証明検証の実行に進む方が有利である。
【0156】
受信者ブロックチェーンノード１０４が出力ハッシュ値Hashvaluetの検証に成功した場合、プロセス１０００はステップS１０１２に進む。
【0157】
ステップS１０１２で、ブロックチェーンノード１０４は、メッセージ文字列RealContentPublicを、ハッシュ関数によって定義された入力メッセージサイズに対応する５１２ビットの長さを各々持つ複数のメッセージブロックRealContentiに分割する。
【数14】
【0158】
ステップS１０１４でiの値を１に設定し、ステップS１０１６でブロックチェーンノード１０４がRealContentiを読み出す。１回目のステップS６２６が実行されると、ブロックチェーンノード１０４は第１５１２ビットメッセージブロックRealContent１を読み出すことが分かる。
【0159】
ステップS１０１８で、ブロックチェーンノード１０４はマスクビット列Maskiを使用して、メッセージブロックRealContentiに機密ビットが存在するかどうかを決定する。
【0160】
メッセージブロックRealContentiが機密ビットを含まない場合、プロセス１０５０はステップS１０２０に進み、受信者ブロックチェーンノード１０４が入力ハッシュ値を読み出す。１回目のステップS１０２０が実行されると、ブロックチェーンノード１０４は、SHA２５６ハッシュアルゴリズムが使用される場合の実施形態では、Secure Hash Standard（SHS）からの事前に決定された公開初期化ベクトルを読み出すことが理解されるだろう。その後の回でステップS１０２０が実行されると、ブロックチェーンノード１０４は以前の出力ハッシュ値、すなわちHashvaluei-１を読み出す。
【0161】
ステップS１０２２で、ブロックチェーンノード１０４は、メッセージブロックRealContentiをハッシングすることによってハッシュ値Hashvalueiを計算する。ここで、Hashvaluei=SHA２５６（RealContenti）である。ステップS１０２０で読み出された入力ハッシュ値は、ステップS１０２２で実行される圧縮で使用される。
【0162】
メッセージブロックRealContentiが機密ビットを含む場合、プロセス１０５０はステップS１０２４に進み、受信者ブロックチェーンノード１０４が、RealContentiについて以下を用いてゼロ知識証明を検証する：
RealContentiのゼロ知識証明、
メッセージブロックRealContenti、
出力ハッシュ値、Hashvaluei。
RealContentiのゼロ知識証明、
メッセージブロックRealContenti、
出力ハッシュ値、Hashvaluei。
【0163】
RealContentiの入力ハッシュ値（Hashvaluei-１）、すなわち前のブロックのハッシングされた出力（ダイジェスト）、
変更されたメッセージの圧縮に使用される入力ハッシュ値、
マスクビット列、Maski、
ステップS６４０で生成されたゼロ知識証明がzkSNARK証明である例では、zkSNARK証明の検証で検証鍵（受信者ブロックチェーンノード１０４のメモリから読み出される）が追加で使用される。
変更されたメッセージの圧縮に使用される入力ハッシュ値、
マスクビット列、Maski、
ステップS６４０で生成されたゼロ知識証明がzkSNARK証明である例では、zkSNARK証明の検証で検証鍵（受信者ブロックチェーンノード１０４のメモリから読み出される）が追加で使用される。
【0164】
前述のように、ステップS１０２０はステップs１０２２の前に実行することが望ましいが、ステップ１０２０とS１０２２は任意の順序で実行することができる。
【0165】
処理するメッセージブロックが更にある場合（ステップS１０２５で決定される）、プロセスはステップS１０２６に進み、ここでブロックチェーンノード１０４はiの値を１つ増やし、プロセス１０５０はステップS１０１６にループバックし、ここでブロックチェーンノード１０４は次のRealContentiを読み出す。
【0166】
受信者ブロックチェーンノードがゼロ知識証明の各々の検証に成功した場合、受信者ブロックチェーンノード１０４は、変更されたブロックチェーントランザクションRealContentPublicが有効であることを検証できる。
【0167】
複数のメッセージブロックが機密データを持つシナリオでは、図１０Bは反復プロセスを示しているが、幾つかの実施形態では証明検証プロセスは並行して実行される。前述のように、機密ビットを含む各メッセージブロックRealContentiについて、受信者ブロックチェーンノード１０４は、そのメッセージブロックのゼロ知識証明と、そのメッセージブロックの出力ハッシュ値Hashvalueiを持っている。ブロックチェーンノード１０４は、前のブロックのハッシングされた出力（ダイジェスト）に対応する入力ハッシュ値（又は、第１メッセージブロックの場合は前述のように事前に定義された初期化ベクトルX０）を使用してメッセージブロックをハッシングすることで、機密データを含まないブロックの残りのハッシュ値Hashvalueiを計算できる。すべてのハッシュ値Hashvalueiが計算されると、ステップS１０２４で実行された機密データを含むメッセージブロックに関連付けられたゼロ知識証明の各検証を並行して実行できる。この並列実行では、十分な計算リソースがあると仮定して、単一のゼロ知識証明を検証するのにかかる時間と同じ時間でN個のゼロ知識証明を検証できる。
【0168】
図７は、RealContentPadの長さが３０７２で、６つのメッセージブロックRealContent１～RealContent６に分割されている例を示している。図７の例では、メッセージブロックRealContent４とRealContent５が機密ビット７０４を含む。
【0169】
プロセス６００を実装することで、公開データRealContent１～RealContent３を含む各メッセージブロックがハッシングされ、各々の出力ハッシュ値が生成されるが、これらには公開データのみが含まれるため、メッセージブロックRealContent１～RealContent３のゼロ知識証明は生成されない。
【0170】
メッセージブロックRealContent４は機密データを含むため、ブロックチェーンノード１０４は以下を使用してRealContent４のゼロ知識証明を生成する：
公開ビット列、PublicData４、
マスクビット列、Mask４、
出力ハッシュ値、Hashvalue４（メッセージブロックRealContent３の圧縮のダイジェストHashvalue３を入力ハッシュ値として計算される）、
秘密ビット列、SecretData４、
ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
公開ビット列、PublicData４、
マスクビット列、Mask４、
出力ハッシュ値、Hashvalue４（メッセージブロックRealContent３の圧縮のダイジェストHashvalue３を入力ハッシュ値として計算される）、
秘密ビット列、SecretData４、
ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
【0171】
メッセージブロックRealContent５は機密データを含むため、ブロックチェーンノード１０４は以下を使用してRealContent５のゼロ知識証明を生成する：
公開ビット列、PublicData５、
マスクビット列、Mask５、
出力ハッシュ値、Hashvalue５（メッセージブロックRealContent４の圧縮のダイジェストHashvalue４を入力ハッシュ値として計算される）、
秘密ビット列、SecretData５、
ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
公開ビット列、PublicData５、
マスクビット列、Mask５、
出力ハッシュ値、Hashvalue５（メッセージブロックRealContent４の圧縮のダイジェストHashvalue４を入力ハッシュ値として計算される）、
秘密ビット列、SecretData５、
ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
【0172】
プロセス６００の最後に、RealContentPadから機密ビット７０４が削除され、変更されたブロックチェーントランザクションRealContentPublicが生成される。
【0173】
変更されたブロックチェーントランザクションRealContentPublicは、次に受信者に出力される。例えば、変更されたブロックチェーントランザクションRealContentPublicは、ブロックチェーンネットワーク１０６内の受信者ブロックチェーンノード１０４に送信される場合がある。
【0174】
受信者ブロックチェーンノード１０４が、変更されたブロックチェーントランザクションRealContentPublicが有効であることを証明できるようにするために、ブロックチェーンノード１０４は更に次のものを送信する：
RealContent４のゼロ知識証明、
出力ハッシュ値、Hashvalue４、
RealContent５のゼロ知識証明、
出力ハッシュ値、Hashvalue５。
RealContent４のゼロ知識証明、
出力ハッシュ値、Hashvalue４、
RealContent５のゼロ知識証明、
出力ハッシュ値、Hashvalue５。
【0175】
マスクビット列Mask４が公衆に知られている場合、ブロックチェーンノード１０４がマスクビット列Mask４を受信者ブロックチェーンノード１０４に送信する必要はない。しかし、マスクビット列Mask４が公衆に知られていない場合、ブロックチェーンノード１０４はマスクビット列Mask４を受信者ブロックチェーンノード１０４に更に送信する。同様に、マスクビット列Mask５が公衆に知られている場合、ブロックチェーンノード１０４がマスクビット列Mask５を受信者ブロックチェーンノード１０４に送信する必要はない。しかし、マスクビット列Mask５が公衆に知られていない場合、ブロックチェーンノード１０４はマスクビット列Mask５を受信者ブロックチェーンノード１０４に更に送信する。
【0176】
変更されたブロックチェーントランザクションRealContentPublicが有効であることを確認するために、受信者ブロックチェーンノード１０４は、第１メッセージブロックRealContent１の圧縮で、SHA２５６ハッシュアルゴリズムが使用されている場合の実施形態ではSecure Hash Standard （SHS）からの事前に定義された公開初期化ベクトルX０を使用する。第１圧縮のダイジェストHashvalue１は、第２メッセージブロックRealContent２の圧縮で、入力ハッシュ値X１として使用される。第２圧縮のダイジェストHashvalue２は、第３メッセージブロックRealContent３の圧縮で、入力ハッシュ値X２として使用される。
【0177】
受信者ブロックチェーンノード１０４は、以下を使用してRealContent４のゼロ知識証明を検証する：
RealContent４のゼロ知識証明、
RealContentPadのメッセージブロックRealContent４、
出力ハッシュ値、Hashvalue４、
RealContent４の入力ハッシュ値（Hashvalue３）、すなわち前のブロックのハッシングされた出力（ダイジェスト）、
マスクビット列、Mask４、
受信者ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
RealContent４のゼロ知識証明、
RealContentPadのメッセージブロックRealContent４、
出力ハッシュ値、Hashvalue４、
RealContent４の入力ハッシュ値（Hashvalue３）、すなわち前のブロックのハッシングされた出力（ダイジェスト）、
マスクビット列、Mask４、
受信者ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
【0178】
受信者ブロックチェーンノード１０４は、以下を使用してRealContent５のゼロ知識証明を検証する：
RealContent５のゼロ知識証明、
RealContentPadのメッセージブロックRealContent５、
出力ハッシュ値、Hashvalue５、
RealContent５の入力ハッシュ値（Hashvalue４）、すなわち前のブロックのハッシングされた出力（ダイジェスト）、
マスクビット列、Mask５、
受信者ブロックチェーンノード１０４のメモリから読み出された検証鍵（ゼロ知識証明がzkSNARK証明である場合）。
RealContent５のゼロ知識証明、
RealContentPadのメッセージブロックRealContent５、
出力ハッシュ値、Hashvalue５、
RealContent５の入力ハッシュ値（Hashvalue４）、すなわち前のブロックのハッシングされた出力（ダイジェスト）、
マスクビット列、Mask５、
受信者ブロックチェーンノード１０４のメモリから読み出された検証鍵（ゼロ知識証明がzkSNARK証明である場合）。
【0179】
この例では、最後のメッセージブロックRealContent６が機密データを含まないため、受信者ブロックチェーンノード１０４は、（第５メッセージブロックRealContent５に関連付けられた出力ハッシュ値Hashvalue５を入力ハッシュ値として使用して）最後のメッセージブロックRealContent６のSHA２５６ハッシュを計算して、出力ハッシュ値Hashvalue６を生成できる。
【0180】
次に、受信者ブロックチェーンノード１０４は、Hashvalue６のSHA２５６ハッシュを計算して、SHA２５６（Hashvalue６）が変更されたブロックチェーントランザクションRealContentPublicに関連付けられた公開トランザクションIDと等しいことを確認する。
【0181】
一方、図６Cと図６Dは、機密データを含む各メッセージブロックに対するゼロ知識証明の生成を示している。他の実施形態では、機密データを含むRealContentPadの隣接するメッセージブロックをマージでき、マージされたブロックに対して１つのゼロ知識証明が生成される。
【0182】
図７の例に戻ると、RealContentPadが３０７２の長さを持ち、６つのメッセージブロックRealContent１～RealContent６に分割され、メッセージブロックRealContent４とRealContent５が機密ビット７０４を含む。これらの他の実施形態では、ブロックチェーンノード１０４はRealContent４とRealContent５を連結することによって１０２４ビットのマージされたブロックを生成する。つまり、RealContentmerged=RealContent４││RealContent５である。
【0183】
これらの他の実施形態では、ブロックチェーンノード１０４は、以下を使用してマージされたブロックのゼロ知識証明を生成する：
機密ビットにゼロ値を割り当て、公開ビット値を保持することによって、RealContentmergedを変更することによって計算される公開ビット列PublicDatamerged。この例では、PublicDataの長さは１０２４ビットである。
マスクビット列Maskmergedは、マージされたブロックRealContentmerged内の機密ビットの位置を識別する。この例では、Maskmerged=Mask４||Mask５（連結された）であるため、Maskmergedの長さは１０２４ビットである。
マージされたブロックRealContentmerged内の最後のメッセージブロックのハッシュ値。この例では出力ハッシュ値Hashvalue５（メッセージブロックRealContent４の圧縮のダイジェストHashvalue４を入力ハッシュ値として使用して計算される）。ここで、最後のメッセージブロックはマージされたブロックRealContentmergedの一部である。
マージされたブロックRealContentmergedの機密ビットを含むシークレットビット列SecretDatamerged。ブロックチェーンノード１０４は、RealContentmergedを取得し、そこに含まれる機密ビットを保持することによって秘密ビット列SecretDatamergedを計算する。SecretDataｖの残りのビットは任意の値を取ることができる。シークレットビット列SecretDatamergedは、次の要件を満たしている。
この例では、SecretDatamergedの長さは１０２４ビットである。
ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
機密ビットにゼロ値を割り当て、公開ビット値を保持することによって、RealContentmergedを変更することによって計算される公開ビット列PublicDatamerged。この例では、PublicDataの長さは１０２４ビットである。
マスクビット列Maskmergedは、マージされたブロックRealContentmerged内の機密ビットの位置を識別する。この例では、Maskmerged=Mask４||Mask５（連結された）であるため、Maskmergedの長さは１０２４ビットである。
マージされたブロックRealContentmerged内の最後のメッセージブロックのハッシュ値。この例では出力ハッシュ値Hashvalue５（メッセージブロックRealContent４の圧縮のダイジェストHashvalue４を入力ハッシュ値として使用して計算される）。ここで、最後のメッセージブロックはマージされたブロックRealContentmergedの一部である。
マージされたブロックRealContentmergedの機密ビットを含むシークレットビット列SecretDatamerged。ブロックチェーンノード１０４は、RealContentmergedを取得し、そこに含まれる機密ビットを保持することによって秘密ビット列SecretDatamergedを計算する。SecretDataｖの残りのビットは任意の値を取ることができる。シークレットビット列SecretDatamergedは、次の要件を満たしている。
【数15】
ブロックチェーンノード１０４のメモリから読み出された証明鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
【0184】
受信者ブロックチェーンノード１０４は、以下を使用してRealContentmergedのゼロ知識証明を検証する：
RealContentmergedのゼロ知識証明、
マージされたブロック、RealContentmerged、
マージされたブロックRealContentmergedの入力ハッシュ値、この例ではHashvalue３、
出力ハッシュ値、Hashvalue５、
マスクビット列、Maskmerged、
受信者ブロックチェーンノード１０４のメモリから読み出された検証鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
RealContentmergedのゼロ知識証明、
マージされたブロック、RealContentmerged、
マージされたブロックRealContentmergedの入力ハッシュ値、この例ではHashvalue３、
出力ハッシュ値、Hashvalue５、
マスクビット列、Maskmerged、
受信者ブロックチェーンノード１０４のメモリから読み出された検証鍵（zkSNARK証明のようにゼロ知識証明が信頼できる設定を使用する場合）。
【0185】
受信者ブロックチェーンノード１０４は、第３メッセージブロックRealContent３をハッシングするハッシュ出力を知り、これをRealContentmergedへの入力ハッシュ値として使用する。Hashvalue５であるRealContentmergedのハッシングは、第６メッセージブロックRealContent６の圧縮の入力ハッシュ値として使用される。
【0186】
隣接するブロックをマージする上記の手法は、メッセージブロックRealContentiに十分なエントロピーがないため、メッセージブロックRealContentiに存在する機密ビットを取得するために悪意のあるパーティによる総当たり攻撃を受ける可能性がある場合に使用できる。メッセージブロックRealContenti内の機密ビットの数が所定の閾値未満の場合、メッセージブロックRealContentiは十分なエントロピーを持っていないと見なされることがある。所定の閾値は、本開示の実施形態で使用されるハッシュ関数に関連する衝突耐性セキュリティレベルであってもよい。例えば、SHA２５６ハッシュ関数に関連する衝突耐性セキュリティレベルは１２８ビットである。これは、総当たり攻撃でシステムを破壊するには最大２１２８が必要であることを意味する。
【0187】
従って、本開示の実施形態では、ブロックチェーンノード１０４は、機密データを含むメッセージブロックが、事前に設定された閾値未満の数の機密ビットを含むことを識別し、そのメッセージブロックを、機密データを含む少なくとも１つの隣接するメッセージブロックとマージして、マージされたブロックRealContentmergedを生成するように構成することができる。このマージは、マージされたブロックRealContentmerged内の機密ビットの数が事前に設定された閾値を超えるように実装できる。
【0188】
例えば、５１２ビットのメッセージブロックRealContent４に５６個の機密ビットが含まれ、５１２ビットのメッセージブロックRealContent５に１００個の機密ビットが含まれている場合、RealContentmergedはSHA２５６ハッシュ関数に関連付けられている１２８ビットの衝突耐性セキュリティレベルを超える１５６個の機密ビットを含む。
【0189】
（２つのメッセージブロックを連結して生成される）マージされたブロックに対して単一のゼロ知識証明を生成するために発生する計算コストは、２つのメッセージブロックの各々に対してゼロ知識証明を生成するために発生する計算コストと同じだが、単一のゼロ知識証明の生成にかかる時間は倍になる。これは、元のコンテンツからのすべての中間状態（ハッシュ値）を含むすべての必要な入力があるため、２つのメッセージブロックの各々に対してゼロ知識証明を生成することは並列に計算でき、つまり各ブロックを独立して計算できるためである。
【0190】
更に、ブロックチェーンノード１０４は、機密データを含むメッセージブロックが、事前に設定された閾値未満の数の機密ビットを含むことを識別し、エントロピーを増加させるために、公開ビットの１つ以上を機密ビットとして指定するように構成できる。
【0191】
前述のように、メッセージは、コンピューティング装置によって受信されるブロックチェーントランザクションである可能性がある。
【0192】
一例の実装では、コンピューティング装置はブロックチェーンノード１０４である。ブロックチェーンノード１０４は、ブロックチェーンネットワーク１０６のユーザのコンピュータ端末１０２からブロックチェーントランザクションを受け取ることができる。コンピュータ端末１０２は、ブロックチェーントランザクションの伝播とブロックチェーンへの記録を要求する。ブロックチェーンノード１０４は、変更されたブロックチェーントランザクションを検証するために必要な情報により変更されたブロックチェーントランザクションを、ネットワーク１０６内の他のブロックチェーンノード１０４に伝播する前に、ブロックチェーントランザクションから機密データを削除するために、ここで説明する方法を実行することができる。
【0193】
別の実装では、コンピューティング装置はブロックチェーンノード１０４である。ブロックチェーンノード１０４は、ブロックチェーンネットワーク１０６のユーザのコンピュータ端末１０２又は別のブロックチェーンノード１０４からブロックチェーントランザクションを受け取ることができ、それにより、トランザクションがブロックチェーンに記録される。受信したトランザクションをメモプール（mempool）に追加する前に、ブロックチェーンノード１０４は、ここで説明する方法を実行して、ブロックチェーントランザクションから機密データを削除することができる。変更されたブロックチェーントランザクションは、次にメモプールに追加される。ブロックチェーンノード１０４が有効なproof-of-workソリューションを識別すると、ブロックチェーンノード１０４によって、変更されたブロックチェーントランザクションを含む新しいブロックチェーンブロック１５１が生成される。その後、新しいブロック１５１は、変更されたブロックチェーントランザクションの正確性を妥当性確認するために必要な情報と共にネットワークの他のノードに伝播されるため、各ノードは新しいブロック１５１をブロックチェーンに記録できる。
【0194】
別の実装例では、コンピューティング装置は、別のブロックチェーンノード１０４からブロックチェーンに記録されたブロック１５１を受信する場合がある。このブロックは、トランザクションを含む。
【0195】
コンピューティング装置は、例えばブロックチェーンノード１０４であってよい。ブロック１５１の受信に応答して、ブロックチェーンノード１０４は、ここで説明する方法を実行して、ブロックチェーントランザクションから機密データを削除することができる。変更されたブロックチェーントランザクションを含むブロック１５１は、次に、変更されたブロックチェーントランザクションの正確性を妥当性確認するために必要な情報と共にネットワークの他のノードに送信されるため、各ノードは新しいブロック１５１をブロックチェーンに記録できる。代替として、ブロックチェーンノード１０４は、受信者ブロックチェーンノード１０４からブロック１５１の要求を受信することに応答して、変更されたブロックチェーントランザクションを含むブロック１５１と、変更されたブロックチェーントランザクションを妥当性確認するために必要な情報を受信者ブロックチェーンノード１０４に送信する。例えば、受信者ブロックチェーンノード１０４は、ブロックチェーン全体をダウンロードし、UTXOセットを構築するためにすべてのトランザクションを妥当性確認する必要があるビットコインネットワークに入った新しいマイナーである可能性がある。
【0196】
上記の変形では、ブロック１５１の受信に応答して、ブロックチェーンノード１０４がブロックをメモリに格納する場合がある。ブロックチェーンノード１０４は、受信者ブロックチェーンノード１０４からブロックの要求を受信することに応答して、ここで説明する方法を実行して、ブロックチェーントランザクションから機密データを削除することができる。変更されたブロックチェーントランザクションを含むブロックは、次に、変更されたブロックチェーントランザクションの正確性を妥当性確認するために必要な情報と共にネットワークの他のノードに送信される。例えば、受信者ブロックチェーンノード１０４は、ブロックチェーン全体をダウンロードし、UTXOセットを構築するためにすべてのトランザクションを妥当性確認する必要があるビットコインネットワークに入った新しいマイナーである可能性がある。
【0197】
別の実装例では、コンピューティング装置はブロックチェーンネットワーク１０６上のブロックチェーンノード１０４ではない（つまり、ブロックチェーンネットワーク１０６上のアクティブノードではない）。つまり、コンピューティング装置はブロックチェーンネットワーク１０６の外部にある。コンピューティング装置は、例えばブロックチェーンネットワーク１０６に結合されてよい。コンピューティング装置は、ブロックチェーン１５０のコピーを保持し、ブロックチェーンデータ（例えばブロックチェーン１５０に記録されたブロック１５１）をクライアント装置１０２に提供する。コンピューティング装置は、ブロックチェーンノード１０４の１つ以上からブロックチェーン１５０に記録されたブロックを受信する場合がある。ブロックの受信に応答して、コンピューティング装置は、ここに説明する方法を実行して、ブロックチェーントランザクションから機密データを削除することができる。変更されたブロックチェーントランザクションを含むブロックは、次に、変更されたブロックチェーントランザクションの正確性を妥当性確認するために必要な情報と共にクライアント装置に送信される。代替として、コンピューティング装置は、クライアント装置からブロックの要求を受信することに応答して、変更されたブロックチェーントランザクションを含むブロックと、変更されたブロックチェーントランザクションを妥当性確認するために必要な情報を、クライアント装置に送信する。上記の変形では、ブロックの受信に応答して、コンピューティング装置がブロックをメモリに格納する場合がある。コンピューティング装置は、クライアント装置からブロックの要求を受信することに応答して、ここで説明する方法を実行して、ブロックチェーントランザクションから機密データを削除することができる。変更されたブロックチェーントランザクションを含むブロックは、次に、変更されたブロックチェーントランザクションの正確性を妥当性確認するために必要な情報と共にクライアント装置に送信される。
【0198】
ここでは、コンピューティング装置のメモリからマスクビット列を取得することによって、コンピューティング装置がマスクビット列を取得できる例について説明する。これは、政府機関又は規制機関が、ブロックチェーンに既に記録されているブロックのトランザクションが機密（例えば違法）データを含むことを識別する場合に可能になる可能性がある。このシナリオでは、政府／規制機関は、トランザクションIDとマスクビット列をコンピューティング装置、例えばネットワーク１０６のブロックチェーンノード１０４に公開できる。
【0199】
本明細書ではブロックチェーントランザクションであるメッセージに関連して実施形態が記述されているが、本開示の実施形態は、ビットコイン及び他のブロックチェーンの文脈の外に拡張され、ハッシュプリイメージの任意の部分をブロックするために使用することができる。
【0200】
一例として、メッセージは人のパスポート情報である場合がある。つまり、RealContentPadが３０７２の長さを持ち、６つのメッセージブロックRealContent１～RealContent６に分割されている図７の例では、各メッセージブロックは、各々、その人のID属性（例えば、氏名、生年月日、出生地、パスポート番号、発行日、有効期限）を含む。
【0201】
この例では、メッセージブロックRealContent１～RealContent６は、最後のメッセージブロックRealContent６のハッシュ値Hashvalue６に対する政府の署名とともに、電子パスポートに保存できる。電子パスポートは、データの保存と処理のための埋め込み集積回路（例えば、コンピューティング装置）を含む物理パスポート文書の形式である場合がある。つまり、物理パスポート文書上の埋め込み集積回路は、本開示の実施形態を実行するように構成することができる。
【0202】
あるいは、電子パスポートは、コンピューティング装置（例えば、携帯電話）のメモリに保存される電子パスポート文書の形式であってもよい。これは、e-Passportなど、すでに発行されている政府の資格情報から取得できる仮想モバイルIDにすることができる。このe-Passportは、電話やトークンなどのモバイル装置に安全に読み込むことができる。
【0203】
メッセージブロックRealContent４及びRealContent５が機密ビットを含む場合、コンピューティング装置は、ここで説明する方法を実行して、パスポート情報のコピーから機密データを削除し、元のパスポート情報の選択された属性のみを含む変更されたパスポート情報を生成することができる。その後、変更されたパスポート情報は、変更されたパスポート情報を妥当性確認するために必要な情報と共に受信者に出力される。例えば、コンピューティング装置は、変更されたパスポート情報を妥当性確認するために必要な情報と共に、変更されたパスポート情報をリモート装置（例えば空港のコンピュータ端末）に送信する場合がある。別の例では、コンピューティング装置は、変更されたパスポート情報と、変更されたパスポート情報を妥当性確認するために必要な情報をコンピューティング装置のディスプレイに出力し、表示された情報を受信者が検証できるようにする場合がある。
【0204】
変更されたメッセージ（例えば、変更されたパスポート情報）が生成されると、元のメッセージ（人のパスポート情報）は、後で他のエンティティとの検証に必要になるため、メモリから削除されない。
【0205】
リモート装置が変更されたパスポート情報が有効であることを証明できるようにするために、コンピューティング装置は更に、機密ビットを含むRealContentiごとに、次のものを送信する：
ゼロ知識証明、
出力ハッシュ値、Hashvaluei。
ゼロ知識証明、
出力ハッシュ値、Hashvaluei。
【0206】
マスクビット列Maskiが公衆に知られている場合、ブロックチェーンノード１０４がマスクビット列Maskiをリモート装置に送信する必要はない。しかし、マスクビット列Maskiが公衆に知られていない場合、コンピューティング装置はマスクビット列Maskiをリモート装置に更に送信する。
【0207】
リモート装置は、プロセス１０５０を使用して、変更されたパスポート情報が有効であることをプロセス１０５０を使用して、以下により検証できる：
１）RealContentPadの最後のメッセージブロックのハッシュ値Hashvaluetを取得し、取得したハッシュ値Hashvaluetをリモート装置のメモリに事前に保存された信頼できるハッシュ値と比較して、Hashvaluetがリモート装置のメモリに事前に保存された信頼できるハッシュ値と等しいことを確認する。この例では、Hashvaluetは最後のメッセージブロックRealContent６のハッシュ値Hashvalue６に対応している。従って、ビットコインのシナリオ（ステップS１０１０を参照して前述した）では、それが信頼される値であるトランザクションIDであるのに対し、パスポート情報のコンテキストでは、信頼される値はリモート装置のメモリに事前に保存された信頼されるハッシュ値である。
１）RealContentPadの最後のメッセージブロックのハッシュ値Hashvaluetを取得し、取得したハッシュ値Hashvaluetをリモート装置のメモリに事前に保存された信頼できるハッシュ値と比較して、Hashvaluetがリモート装置のメモリに事前に保存された信頼できるハッシュ値と等しいことを確認する。この例では、Hashvaluetは最後のメッセージブロックRealContent６のハッシュ値Hashvalue６に対応している。従って、ビットコインのシナリオ（ステップS１０１０を参照して前述した）では、それが信頼される値であるトランザクションIDであるのに対し、パスポート情報のコンテキストでは、信頼される値はリモート装置のメモリに事前に保存された信頼されるハッシュ値である。
【0208】
前述のように、最終的なメッセージブロックが機密ビットを含む場合、コンピューティング装置はHashvaluetをリモート装置に送信する。最終的なメッセージブロックが機密ビットを含まない場合、コンピューティング装置は実行する検証プロセスからHashvaluetを取得できるため、コンピューティング装置がHashvaluetをリモート装置に送信する必要はない。
【0209】
２）以下を使用して、RealContentiごとにゼロ知識証明を検証する：
RealContentiのゼロ知識証明、
RealContenti出力ハッシュ値、Hashvaluei、
RealContentiの初期化ベクトル（Hashvaluei-１）、マスクビット列、Maski、
リモート装置のメモリから読み出された検証鍵（ゼロ知識証明がzkSNARK証明である場合）。
RealContentiのゼロ知識証明、
RealContenti出力ハッシュ値、Hashvaluei、
RealContentiの初期化ベクトル（Hashvaluei-１）、マスクビット列、Maski、
リモート装置のメモリから読み出された検証鍵（ゼロ知識証明がzkSNARK証明である場合）。
【0210】
その他の例も可能である。例えば、本開示の実施形態は、個人の居住地及び／又は手書きの署名などの他の情報を開示することなく、（例えば、１８歳以上であることを証明するために）運転免許証に保存された幾つかの情報を選択的に開示することを可能にする。運転免許証は、物理的な書類やカードであってもよいし、コンピュータ装置のメモリに電子的に保存されていてもよい。
【0211】
別の例では、本開示の実施形態は、IDカードに保存されている幾つかの情報の選択的開示を可能にし、他の情報を開示することなく、ある人がロンドンの居住者であることを証明する。IDカードは、物理的なオブジェクトであってもよいし、コンピュータ装置のメモリに電子的に保存されていてもよい。
【0212】
本開示の実施形態は、人が異なるマスクを生成して、同じデータの異なる部分の情報を異なる時間に異なるエンティティに選択的に開示することを可能にする柔軟性を可能にする。
【0213】
結論
開示された技術の他の変形例又は使用事例は、本明細書で開示されると、当業者に明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。
開示された技術の他の変形例又は使用事例は、本明細書で開示されると、当業者に明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。
【0214】
例えば、実施形態はSHA２５６ハッシュ関数（ここではハッシュアルゴリズムとも呼ばれる）を参照して上述されてきたが、本開示の実施形態は任意のハッシュ関数を利用することができる。単なる例として、Pedersen又はMiMCハッシュ関数のような他の種類のハッシュ関数を使用することができる。
【0215】
更に、本開示の実施形態は、特定の種類のゼロ知識証明を使用することに限定されない。単なる例として、ゼロ知識証明は、Jens Grothによる論文「On the size of pairing-based non-interactive arguments. In Advances in Cryptology」-EUROCRYPT ２０１６-３５th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May ８-１２, ２０１６, Proceedings, PartII, pages ３０５－３２６, ２０１６に示されているアルゴリズムを利用することができる。
【0216】
ステップS６２０及びS６４２でのRealContentPadからの機密ビットの削除は、すべての機密ビットに同じ所定値（例えば、０）を割り当て、RealContentPadの公開ビット値を保持することに関して説明されているが、他の実施形態では、これらのステップは、RealContentPadのこの変更されたバージョンが公開ビットのみを含むように、RealContentPadから機密ビットの場所を完全に削除することを含む場合がある。その後、RealContentPadの変更されたバージョンのメッセージ文字列が受信者に出力される。例えば、RealContentPublicの変更されたバージョンは、ブロックチェーンネットワーク１０６内の受信者ブロックチェーンノード１０４に送信される場合がある。従って、これらの例では、受信者ブロックチェーンノード１０４は、（プロセス６００を実行した）送信者ブロックチェーンノード１０４から変更されたブロックチェーントランザクションRealContentPublicを受信するのではなく、RealContentPadの変更されたバージョンとマスクビット列Maskを使用して、変更されたブロックチェーントランザクションRealContentPublic（すべての機密ビットが同じ所定の値を割り当てられている）を再構築できる。
【0217】
上述の幾つかの実施形態は、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０、及びビットコインノード１０４の観点で説明された。しかしながら、ビットコインブロックチェーンは、ブロックチェーン１５０の１つの特定の例であり、上述の説明は任意のブロックチェーンに一般的に適用されてよいことが理解される。つまり、本発明は、ビットコインブロックチェーンに何ら限定されない。より一般的には、上述のビットコインネットワーク１０６、ビットコインブロックチェーン１５０、及びビットコインノード１０４への言及は、ブロックチェーンネットワーク１０６、ブロックチェーン１５０、及びブロックチェーンノード１０４により各々置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、及び／又はブロックチェーンノードは、ビットコインブロックチェーン１５０、ビットコインネットワーク１０６、及びビットコインノード１０４の上述の特性の一部又は全部を共有してよい。
【0218】
本発明の好適な実施形態では、ブロックチェーンネットワーク１０６は、ビットコインネットワークであり、ビットコインノード１０４はブロックチェーン１５０のブロック１５１を生成し、公開し、伝播し、及び格納する上述の機能の少なくとも全部を実行する。これらの機能の全部ではなく１つ又は一部のみを実行する他のネットワークエンティティ（又はネットワーク要素）が存在することが除外されない。つまり、ネットワークエンティティは、ブロックを伝播し及び／又は格納する機能を実行してよいが、ブロックを生成し公開しなくてよい（これらのエンティティが好適なビットコインネットワーク１０６のノードと見なされないことを思い出してほしい）。
【0219】
本発明の他の実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を生成し、公開し、伝播し、及び格納する機能の全部ではなく少なくとも１つ又は一部を実行してよいことが除外されない。例えば、これらの他のブロックチェーンネットワークでは、「ノード」は、ブロック１５１を生成し公開するよう構成されるが該ブロック１５１を格納し及び／又は他のノードに伝播しないネットワークエンティティを表すために使用されてよい。
【0220】
更に一般的には、上述の用語「ビットコインノード」１０４の言及は、用語「ネットワークエンティティ」又は「ネットワーク要素」と置き換えられてよい。このようなエンティティ／要素は、ブロックを生成し、公開し、伝播し、及び格納する役割のうちの一部又は全部を実行するよう構成される。そのようなネットワークエンティティ／要素の機能は、ハードウェアで、ブロックチェーンノード１０４を参照して上述したのと同じ方法で実装されてよい。
【0221】
上記の実施形態は、単なる例示として説明したものであることが理解されるであろう。より一般的には、以下の記述のうちの任意の１つ以上に従った方法、装置又はプログラムが提供され得る。
【0222】
本開示の側面は、以下の条項を参照して以下に定義される。
【0223】
（項１）
メッセージ内の機密データをブロックする方法であって、コンピューティング装置上で実行され、
前記メッセージのコピーを作成するステップと、
少なくとも１つのゼロ知識証明を生成し、前記少なくとも１つのゼロ知識証明の各々を生成することは、
前記コピーのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列を取得することと、
前記少なくとも１つの機密ビットに所定の値を割り当てることで、前記コピーの前記ビットを変更することにより、公開ビット列を計算することと、
秘密ビット列を決定することであって、前記秘密ビット列は、前記少なくとも１つの機密ビットを含み、かつ、前記コピーの前記ビットが、前記公開ビット列、前記マスクビット列及び前記秘密ビット列を用いたビットごとの論理計算の出力と等しいという要件を満たすことと、
前記メッセージのコピー又はその一部をハッシングして出力ハッシュ値を生成することと、
前記公開ビット列、前記マスクビット列、前記出力ハッシュ値、前記秘密ビット列を用いてゼロ知識証明を生成することと、
を含む、ステップと、
前記コピーから前記少なくとも１つの機密ビットの各々を削除して、変更されたメッセージを生成するステップと、
前記少なくとも１つの出力ハッシュ値、及び受信者が前記変更されたメッセージが有効であることを証明できるようにするための前記少なくとも１つのゼロ知識証明とともに、前記変更されたメッセージを前記受信者に出力するステップと、
を含む方法。
メッセージ内の機密データをブロックする方法であって、コンピューティング装置上で実行され、
前記メッセージのコピーを作成するステップと、
少なくとも１つのゼロ知識証明を生成し、前記少なくとも１つのゼロ知識証明の各々を生成することは、
前記コピーのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列を取得することと、
前記少なくとも１つの機密ビットに所定の値を割り当てることで、前記コピーの前記ビットを変更することにより、公開ビット列を計算することと、
秘密ビット列を決定することであって、前記秘密ビット列は、前記少なくとも１つの機密ビットを含み、かつ、前記コピーの前記ビットが、前記公開ビット列、前記マスクビット列及び前記秘密ビット列を用いたビットごとの論理計算の出力と等しいという要件を満たすことと、
前記メッセージのコピー又はその一部をハッシングして出力ハッシュ値を生成することと、
前記公開ビット列、前記マスクビット列、前記出力ハッシュ値、前記秘密ビット列を用いてゼロ知識証明を生成することと、
を含む、ステップと、
前記コピーから前記少なくとも１つの機密ビットの各々を削除して、変更されたメッセージを生成するステップと、
前記少なくとも１つの出力ハッシュ値、及び受信者が前記変更されたメッセージが有効であることを証明できるようにするための前記少なくとも１つのゼロ知識証明とともに、前記変更されたメッセージを前記受信者に出力するステップと、
を含む方法。
【0224】
（項２）
少なくとも１つのゼロ知識証明を生成する前に、前記コピーが、ハッシングするときに使用されるハッシュ関数によって定義される入力メッセージサイズの正の整数倍の長さを持つように、前記メッセージのコピーをパディングするステップと、
前記コピーの長さが前記ハッシュ関数によって定義される前記入力メッセージサイズに対応する場合、前記メッセージのコピーをハッシングすることによって単一のゼロ知識証明が生成され、公開初期化ベクトルを使用して前記出力ハッシュ値を生成するステップと、
を更に含む項１に記載の方法。
少なくとも１つのゼロ知識証明を生成する前に、前記コピーが、ハッシングするときに使用されるハッシュ関数によって定義される入力メッセージサイズの正の整数倍の長さを持つように、前記メッセージのコピーをパディングするステップと、
前記コピーの長さが前記ハッシュ関数によって定義される前記入力メッセージサイズに対応する場合、前記メッセージのコピーをハッシングすることによって単一のゼロ知識証明が生成され、公開初期化ベクトルを使用して前記出力ハッシュ値を生成するステップと、
を更に含む項１に記載の方法。
【0225】
（項３）
少なくとも１つのゼロ知識証明を生成する前に、前記コピーが、ハッシングに使用されるハッシュ関数によって定義される入力メッセージサイズの正の整数倍の長さを持つように、前記メッセージのコピーをパディングするステップ、を更に含み、
パディング後の前記コピーの長さが、前記ハッシュ関数によって定義される前記入力メッセージサイズよりも大きい場合、前記方法は、
前記ハッシュ関数によって定義される前記入力メッセージサイズに対応する長さを各々持つ複数のメッセージブロックに、前記メッセージのコピーを分割するステップと、
機密データを含む１つ以上のメッセージブロックを識別するステップと、
を含み、
機密データを含む前記１つ以上のメッセージブロックの各々に対してゼロ知識証明が生成される、項１に記載の方法。
少なくとも１つのゼロ知識証明を生成する前に、前記コピーが、ハッシングに使用されるハッシュ関数によって定義される入力メッセージサイズの正の整数倍の長さを持つように、前記メッセージのコピーをパディングするステップ、を更に含み、
パディング後の前記コピーの長さが、前記ハッシュ関数によって定義される前記入力メッセージサイズよりも大きい場合、前記方法は、
前記ハッシュ関数によって定義される前記入力メッセージサイズに対応する長さを各々持つ複数のメッセージブロックに、前記メッセージのコピーを分割するステップと、
機密データを含む１つ以上のメッセージブロックを識別するステップと、
を含み、
機密データを含む前記１つ以上のメッセージブロックの各々に対してゼロ知識証明が生成される、項１に記載の方法。
【0226】
（項４）
前記少なくとも１つのゼロ知識証明のうちの１つ以上について、前記コピーのビットは、前記１つ以上のメッセージブロックのうちのメッセージブロックのビットに対応し、前記ゼロ知識証明は、前記メッセージブロックをハッシングして出力ハッシュ値を生成することによって生成される、項３に記載の方法。
前記少なくとも１つのゼロ知識証明のうちの１つ以上について、前記コピーのビットは、前記１つ以上のメッセージブロックのうちのメッセージブロックのビットに対応し、前記ゼロ知識証明は、前記メッセージブロックをハッシングして出力ハッシュ値を生成することによって生成される、項３に記載の方法。
【0227】
（項５）
前記複数のメッセージブロックは、第１メッセージブロックと１つ以上の更なるメッセージブロックを含み、前記第１メッセージブロックが機密データを含む場合、前記第１メッセージブロックのハッシングには公開初期化ベクトルが使用され、前記更なるメッセージブロックが機密データを含む場合、前記更なるメッセージブロックのハッシングには、前記更なるメッセージブロックの直前のメッセージブロックのハッシングから出力されるハッシュ値が使用される、項４に記載の方法。
前記複数のメッセージブロックは、第１メッセージブロックと１つ以上の更なるメッセージブロックを含み、前記第１メッセージブロックが機密データを含む場合、前記第１メッセージブロックのハッシングには公開初期化ベクトルが使用され、前記更なるメッセージブロックが機密データを含む場合、前記更なるメッセージブロックのハッシングには、前記更なるメッセージブロックの直前のメッセージブロックのハッシングから出力されるハッシュ値が使用される、項４に記載の方法。
【0228】
（項６）
前記複数のメッセージブロックのうちの幾つかのメッセージブロックが機密データを含み、前記方法は、前記幾つかのメッセージブロックの各々についてゼロ知識証明を並列に生成するステップ、を含む項３～５のいずれかに記載の方法。
前記複数のメッセージブロックのうちの幾つかのメッセージブロックが機密データを含み、前記方法は、前記幾つかのメッセージブロックの各々についてゼロ知識証明を並列に生成するステップ、を含む項３～５のいずれかに記載の方法。
【0229】
（項７）
前記少なくとも１つのゼロ知識証明のうちの１つについて、前記コピーのビットは、マージされたブロックのビットに対応し、前記マージされたブロックは、機密データを各々含む複数の隣接するメッセージブロックを含み、前記ゼロ知識証明は、前記マージされたブロックの中の各メッセージブロックを反復的にハッシングすることによって生成され、出力ハッシュ値は、終了メッセージブロックの直前にある前記複数の隣接するメッセージブロックのうちのメッセージブロックをハッシングすることから出力されるハッシュ値を使用して、前記マージされたブロックのうちの前記終了メッセージブロックをハッシングすることによって生成される、項３～６のいずれかに記載の方法。
前記少なくとも１つのゼロ知識証明のうちの１つについて、前記コピーのビットは、マージされたブロックのビットに対応し、前記マージされたブロックは、機密データを各々含む複数の隣接するメッセージブロックを含み、前記ゼロ知識証明は、前記マージされたブロックの中の各メッセージブロックを反復的にハッシングすることによって生成され、出力ハッシュ値は、終了メッセージブロックの直前にある前記複数の隣接するメッセージブロックのうちのメッセージブロックをハッシングすることから出力されるハッシュ値を使用して、前記マージされたブロックのうちの前記終了メッセージブロックをハッシングすることによって生成される、項３～６のいずれかに記載の方法。
【0230】
（項８）
機密データを含むメッセージブロックが、所定の閾値未満の数の機密ビットを含むことを識別するステップと、
前記メッセージブロックを、機密データを含む少なくとも１つの隣接するメッセージブロックとマージして、マージされたブロックを生成するステップと、
を更に含む項７に記載の方法。
機密データを含むメッセージブロックが、所定の閾値未満の数の機密ビットを含むことを識別するステップと、
前記メッセージブロックを、機密データを含む少なくとも１つの隣接するメッセージブロックとマージして、マージされたブロックを生成するステップと、
を更に含む項７に記載の方法。
【0231】
（項９）
前記所定の閾値は、前記ハッシュ関数の衝突耐性によって定義される、項８に記載の方法。
前記所定の閾値は、前記ハッシュ関数の衝突耐性によって定義される、項８に記載の方法。
【0232】
（項１０）
前記秘密ビット列は、前記コピーの前記ビットが、（i）公開ビット列と（ii）前記マスクビット列と前記秘密ビット列のビット毎のAND計算の結果とのビット毎のXOR計算に等しいという要件を満たす、項１～９のいずれかに記載の方法。
前記秘密ビット列は、前記コピーの前記ビットが、（i）公開ビット列と（ii）前記マスクビット列と前記秘密ビット列のビット毎のAND計算の結果とのビット毎のXOR計算に等しいという要件を満たす、項１～９のいずれかに記載の方法。
【0233】
（項１１）
前記マスクビット列を取得することが、メモリから前記マスクビット列を読み出すことを含む、項１～１０のいずれかに記載の方法。
前記マスクビット列を取得することが、メモリから前記マスクビット列を読み出すことを含む、項１～１０のいずれかに記載の方法。
【0234】
（項１２）
前記マスクビット列を取得することが、
前記メッセージのコピーのビット内の少なくとも１つの機密ビットの位置を特定することと、
前記コピー内の前記少なくとも１つの機密ビットの位置を特定するマスクビット列を生成することと、
を含む、項１～１０のいずれかに記載の方法。
前記マスクビット列を取得することが、
前記メッセージのコピーのビット内の少なくとも１つの機密ビットの位置を特定することと、
前記コピー内の前記少なくとも１つの機密ビットの位置を特定するマスクビット列を生成することと、
を含む、項１～１０のいずれかに記載の方法。
【0235】
（項１３）
前記少なくとも１つのマスクビット列を前記受信者に出力するステップ、を更に含む項１～１２のいずれかに記載の方法。
前記少なくとも１つのマスクビット列を前記受信者に出力するステップ、を更に含む項１～１２のいずれかに記載の方法。
【0236】
（項１４）
前記出力するステップは、前記少なくとも１つの出力ハッシュ値、前記少なくとも１つの公開ビット列、及び前記少なくとも１つのゼロ知識証明とともに、前記受信者に関連付けられたリモート装置に前記変更されたメッセージを送信することを含む、項１～１６のいずれかに記載の方法。
前記出力するステップは、前記少なくとも１つの出力ハッシュ値、前記少なくとも１つの公開ビット列、及び前記少なくとも１つのゼロ知識証明とともに、前記受信者に関連付けられたリモート装置に前記変更されたメッセージを送信することを含む、項１～１６のいずれかに記載の方法。
【0237】
（項１５）
前記メッセージはブロックチェーントランザクションデータを含み、前記変更されたメッセージは変更されたブロックチェーントランザクションデータを含む、項１３に記載の方法。
前記メッセージはブロックチェーントランザクションデータを含み、前記変更されたメッセージは変更されたブロックチェーントランザクションデータを含む、項１３に記載の方法。
【0238】
（項１６）
前記コンピューティング装置はブロックチェーンネットワーク内のブロックチェーンノードである、項１４に記載の方法。
前記コンピューティング装置はブロックチェーンネットワーク内のブロックチェーンノードである、項１４に記載の方法。
【0239】
（項１７）
前記ブロックチェーントランザクションデータは、前記ブロックチェーントランザクションをブロックチェーンに記録することを要求するクライアント装置から受信され、前記リモート装置は、前記ブロックチェーンネットワーク内の更なるブロックチェーンノードであり、前記変更されたブロックチェーントランザクションデータが前記ブロックチェーンネットワーク内での伝播のために前記更なるブロックチェーンノードに送信される、項１６に記載の方法。
前記ブロックチェーントランザクションデータは、前記ブロックチェーントランザクションをブロックチェーンに記録することを要求するクライアント装置から受信され、前記リモート装置は、前記ブロックチェーンネットワーク内の更なるブロックチェーンノードであり、前記変更されたブロックチェーントランザクションデータが前記ブロックチェーンネットワーク内での伝播のために前記更なるブロックチェーンノードに送信される、項１６に記載の方法。
【0240】
（項１８）
前記リモート装置は前記ブロックチェーンネットワーク内の更なるブロックチェーンノードであり、前記方法は、
前記ブロックチェーントランザクションを受信するステップと、
ブロックチェーンに記録されるべきブロックを生成するステップであって、前記ブロックは、前記変更されたブロックチェーントランザクションデータを含む、ステップと、
前記変更されたブロックチェーントランザクションデータを含む前記ブロックを前記ブロックチェーンネットワーク内の前記更なるブロックチェーンノードに送信するステップと、
を含む項１～１５のいずれかに記載の方法。
前記リモート装置は前記ブロックチェーンネットワーク内の更なるブロックチェーンノードであり、前記方法は、
前記ブロックチェーントランザクションを受信するステップと、
ブロックチェーンに記録されるべきブロックを生成するステップであって、前記ブロックは、前記変更されたブロックチェーントランザクションデータを含む、ステップと、
前記変更されたブロックチェーントランザクションデータを含む前記ブロックを前記ブロックチェーンネットワーク内の前記更なるブロックチェーンノードに送信するステップと、
を含む項１～１５のいずれかに記載の方法。
【0241】
（項１９）
前記コンピューティング装置はブロックチェーンネットワークの外部にあり、前記リモート装置はクライアント装置である、項１５に記載の方法。
前記コンピューティング装置はブロックチェーンネットワークの外部にあり、前記リモート装置はクライアント装置である、項１５に記載の方法。
【0242】
（項２０）
ブロックチェーンに記録されたブロックを受信するステップであって、前記ブロックは前記ブロックチェーンのトランザクションデータを含む、ステップ、を含む項１６又は１９に記載の方法。
ブロックチェーンに記録されたブロックを受信するステップであって、前記ブロックは前記ブロックチェーンのトランザクションデータを含む、ステップ、を含む項１６又は１９に記載の方法。
【0243】
（項２１）
前記ブロックを受信するステップに応答して、前記生成するステップ、前記削除するステップ、前記送信するステップが行われる、項２０に記載の方法。
前記ブロックを受信するステップに応答して、前記生成するステップ、前記削除するステップ、前記送信するステップが行われる、項２０に記載の方法。
【0244】
（項２２）
前記生成するステッ及び前記削除するステップは、前記ブロックを受信することに応答して行われ、前記送信するステップは、前記リモート装置からの前記ブロックに対する要求を受信することに応答して行われる、項２０に記載の方法。
前記生成するステッ及び前記削除するステップは、前記ブロックを受信することに応答して行われ、前記送信するステップは、前記リモート装置からの前記ブロックに対する要求を受信することに応答して行われる、項２０に記載の方法。
【0245】
（項２３）
前記リモート装置からの前記ブロックに対する要求を受信するステップに応答して、生成するステップ、削除するステップ、送信するステップが行われる、項２０に記載の方法。
前記リモート装置からの前記ブロックに対する要求を受信するステップに応答して、生成するステップ、削除するステップ、送信するステップが行われる、項２０に記載の方法。
【0246】
（項２４）
少なくとも１つのゼロ知識証明がzkSNARK（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）証明である、項１～２３のいずれかに記載の方法。
少なくとも１つのゼロ知識証明がzkSNARK（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）証明である、項１～２３のいずれかに記載の方法。
【0247】
（項２５）
前記ゼロ知識証明を生成するステップは、証明鍵を使用することを更に含む、項２４に記載の方法。
前記ゼロ知識証明を生成するステップは、証明鍵を使用することを更に含む、項２４に記載の方法。
【0248】
（項２６）
更に、前記変更されたメッセージの生成後、メモリから前記メッセージを削除し、前記変更されたメッセージをメモリに格納するステップ、を更に含む項１～２５のいずれかに記載の方法。
更に、前記変更されたメッセージの生成後、メモリから前記メッセージを削除し、前記変更されたメッセージをメモリに格納するステップ、を更に含む項１～２５のいずれかに記載の方法。
【0249】
（項２７）
コンピュータ可読記憶装置上に具現化されたコンピュータプログラムであって、コンピュータ機器上で実行すると項１～２６のいずれかに記載の方法を実行するよう構成される、コンピュータプログラム。
コンピュータ可読記憶装置上に具現化されたコンピュータプログラムであって、コンピュータ機器上で実行すると項１～２６のいずれかに記載の方法を実行するよう構成される、コンピュータプログラム。
【0250】
（項２８）
プロセッサとメモリを含むコンピュータ装置であり、前記メモリは、前記プロセッサによって実行されると前記コンピュータ装置に項１～２６のいずれかに記載の方法を実行させる命令を格納する、コンピュータ装置。
プロセッサとメモリを含むコンピュータ装置であり、前記メモリは、前記プロセッサによって実行されると前記コンピュータ装置に項１～２６のいずれかに記載の方法を実行させる命令を格納する、コンピュータ装置。
【0251】
（項２９）
変更されたメッセージが有効であることを検証する方法であって、前記変更されたメッセージは元のメッセージから機密データを除去したものに対応し、前記方法は、コンピュータ装置上で実行され、
前記変更されたメッセージを取得するステップであって、前記変更されたメッセージが、前記元のメッセージの各機密ビットに所定の値を割り当てたものに対応する、ステップと、
前記変更されたメッセージの出力ハッシュ値を取得し、前記コンピューティング装置のメモリに格納されたデータを使用して前記出力ハッシュ値を検証するステップと、
送信側装置から、前記変更されたメッセージのビットに関連する少なくとも１つのゼロ知識証明を受信するステップと、
以下：（i）前記ゼロ知識証明を生成するために使用された秘密ビット列を導出するために、前記送信側装置により使用された、ビットごとの論理計算の知識、又はそれに関連する検証鍵、（ii）前記変更されたメッセージのビット、（iii）前記変更されたメッセージのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列、（iv）前記変更されたメッセージのビットのハッシュ値又はその一部、及び（v）前記変更されたメッセージのビットの入力ハッシュ値、を使用して前記少なくとも１つのゼロ知識証明の各々を検証するステップと、
を含む方法。
変更されたメッセージが有効であることを検証する方法であって、前記変更されたメッセージは元のメッセージから機密データを除去したものに対応し、前記方法は、コンピュータ装置上で実行され、
前記変更されたメッセージを取得するステップであって、前記変更されたメッセージが、前記元のメッセージの各機密ビットに所定の値を割り当てたものに対応する、ステップと、
前記変更されたメッセージの出力ハッシュ値を取得し、前記コンピューティング装置のメモリに格納されたデータを使用して前記出力ハッシュ値を検証するステップと、
送信側装置から、前記変更されたメッセージのビットに関連する少なくとも１つのゼロ知識証明を受信するステップと、
以下：（i）前記ゼロ知識証明を生成するために使用された秘密ビット列を導出するために、前記送信側装置により使用された、ビットごとの論理計算の知識、又はそれに関連する検証鍵、（ii）前記変更されたメッセージのビット、（iii）前記変更されたメッセージのビット内の少なくとも１つの機密ビットの位置を特定するマスクビット列、（iv）前記変更されたメッセージのビットのハッシュ値又はその一部、及び（v）前記変更されたメッセージのビットの入力ハッシュ値、を使用して前記少なくとも１つのゼロ知識証明の各々を検証するステップと、
を含む方法。
【0252】
（項３０）
前記変更されたメッセージを取得するステップが、前記変更されたメッセージを前記送信側装置から受信することを含む、項２９に記載の方法。
前記変更されたメッセージを取得するステップが、前記変更されたメッセージを前記送信側装置から受信することを含む、項２９に記載の方法。
【0253】
（項３１）
前記変更されたメッセージを取得するステップが、
前記元のメッセージの公開ビットのみを含む、前記元のメッセージのバージョンを受信することと、
前記元のメッセージの前記バージョンと前記マスクビット列を使用して、前記変更されたメッセージを生成するステップと、
を含む、項２９に記載の方法。
前記変更されたメッセージを取得するステップが、
前記元のメッセージの公開ビットのみを含む、前記元のメッセージのバージョンを受信することと、
前記元のメッセージの前記バージョンと前記マスクビット列を使用して、前記変更されたメッセージを生成するステップと、
を含む、項２９に記載の方法。
【0254】
（項３２）
前記変更されたメッセージのビットは、変更されたメッセージ全体に対応し、前記変更されたメッセージは、前記変更されたメッセージの出力ハッシュ値を生成するために使用されるハッシュ関数によって定義される入力メッセージサイズに対応する長さを持つ、項２９～３１のいずれかに記載の方法。
前記変更されたメッセージのビットは、変更されたメッセージ全体に対応し、前記変更されたメッセージは、前記変更されたメッセージの出力ハッシュ値を生成するために使用されるハッシュ関数によって定義される入力メッセージサイズに対応する長さを持つ、項２９～３１のいずれかに記載の方法。
【0255】
（項３３）
前記変更されたメッセージは、複数のメッセージブロックを含み、前記出力ハッシュ値は、前記複数のメッセージブロックのうちの終了メッセージブロックのハッシュであり、前記複数のメッセージブロックは、前記出力ハッシュ値を生成するために使用されるハッシュ関数によって定義される入力メッセージサイズに対応する長さを持つ、項２９～３１のいずれかに記載の方法。
前記変更されたメッセージは、複数のメッセージブロックを含み、前記出力ハッシュ値は、前記複数のメッセージブロックのうちの終了メッセージブロックのハッシュであり、前記複数のメッセージブロックは、前記出力ハッシュ値を生成するために使用されるハッシュ関数によって定義される入力メッセージサイズに対応する長さを持つ、項２９～３１のいずれかに記載の方法。
【0256】
（項３４）
前記変更されたメッセージのビットは、前記複数のメッセージブロックのいずれかに対応する、項３３に記載の方法。
前記変更されたメッセージのビットは、前記複数のメッセージブロックのいずれかに対応する、項３３に記載の方法。
【0257】
（項３５）
前記コピーのビットは、マージされたブロックのビットに対応し、前記マージされたブロックは、機密データを含む複数の隣接するメッセージブロックを含み、前記ゼロ知識証明を検証するステップは、前記マージされたブロックの終了メッセージブロックのハッシュ値を使用する、項２９～３１のいずれかに記載の方法。
前記コピーのビットは、マージされたブロックのビットに対応し、前記マージされたブロックは、機密データを含む複数の隣接するメッセージブロックを含み、前記ゼロ知識証明を検証するステップは、前記マージされたブロックの終了メッセージブロックのハッシュ値を使用する、項２９～３１のいずれかに記載の方法。
【0258】
（項３６）
前記元のメッセージがブロックチェーントランザクションであり、前記コンピューティング装置のメモリに格納されたデータが、前記ブロックチェーントランザクションに関連付けられたトランザクション識別子であり、出力ハッシュ値を検証するステップは、前記出力ハッシュ値をハッシングし、ハッシングの出力を前記トランザクション識別子と比較することを含む、項２９～３５のいずれかに記載の方法。
前記元のメッセージがブロックチェーントランザクションであり、前記コンピューティング装置のメモリに格納されたデータが、前記ブロックチェーントランザクションに関連付けられたトランザクション識別子であり、出力ハッシュ値を検証するステップは、前記出力ハッシュ値をハッシングし、ハッシングの出力を前記トランザクション識別子と比較することを含む、項２９～３５のいずれかに記載の方法。
【0259】
（項３７）
前記変更されたメッセージのビットに関連付けられた複数のゼロ知識証明は、前記送信側装置から受信され、前記複数のゼロ知識証明を検証するステップは並行して行われる、項２９～３６のいずれかに記載の方法。
前記変更されたメッセージのビットに関連付けられた複数のゼロ知識証明は、前記送信側装置から受信され、前記複数のゼロ知識証明を検証するステップは並行して行われる、項２９～３６のいずれかに記載の方法。
【0260】
（項３８）
コンピュータ可読記憶装置上に具現化されたコンピュータプログラムであって、コンピュータ機器上で実行すると項２９～３７のいずれかに記載の方法を実行するよう構成される、コンピュータプログラム。
コンピュータ可読記憶装置上に具現化されたコンピュータプログラムであって、コンピュータ機器上で実行すると項２９～３７のいずれかに記載の方法を実行するよう構成される、コンピュータプログラム。
【0261】
（項３９）
プロセッサとメモリを含むコンピュータ装置であり、前記メモリは、前記プロセッサによって実行されると前記コンピュータ装置に項２９～３７のいずれかに記載の方法を実行させる命令を格納する、コンピュータ装置。
プロセッサとメモリを含むコンピュータ装置であり、前記メモリは、前記プロセッサによって実行されると前記コンピュータ装置に項２９～３７のいずれかに記載の方法を実行させる命令を格納する、コンピュータ装置。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6A】
【図6B】
【図6C】
【図6D】
【図7】
【図8】
【図9】
【図10A】
【図10B】
【国際調査報告】