(57)【要約】  ブロックチェーン上で決定を行う方法が開示される。第１公開鍵は、複数の参加者（A，B，B）の各々から受信され、各第１公開鍵は、参加者による可能な選択を表し、準同型特性を有する暗号演算により対応する第１秘密鍵に関連付けられる。第１公開鍵は、結合されて、第２公開鍵を生成する。ここで、各第２公開鍵は、可能な選択の結合に基づく可能な決定を表す。第３公開鍵は、第２公開鍵に対応するものであり、参加者に通信される。投票ブロックチェーントランザクションが生成され（TCvoting）、投票トランザクションのインプットは、複数の参加者の各々の第１秘密鍵に対応するデジタル署名により実行可能なスクリプトであり、各第１秘密鍵は参加者により行われた選択を表す。投票トランザクションのアウトプットは、参加者により行われた選択に基づく決定を表すスクリプトである。支払いブロックチェーントランザクション（TPpayment）は、第１デジタルアセットを移転するために生成され、支払いトランザクションのアウトプットの実行は、投票トランザクションの決定に対応する第３公開鍵に対応するデジタル署名を必要とする。
2021511535.tif 000002
【特許請求の範囲】
【請求項１】
ブロックチェーン上で決定を行う方法であって、前記決定は、複数の参加者の各々により行われた少なくとも１つのそれぞれの選択に基づき、前記方法は、
複数の参加者の各々から、それぞれの複数の第１公開鍵を受信するステップであって、各々の前記第１公開鍵は、前記参加者による可能な選択を表し、準同型特性を有する暗号演算により対応する第１秘密鍵に関連付けられる、ステップと、
前記準同型特性により、前記第１公開鍵を結合して、複数の第２公開鍵を生成するステップであって、各々の前記第２公開鍵は、前記可能な選択の結合に基づく可能な決定を表す、ステップと、
前記複数の参加者の各々に、複数の第３公開鍵を通信するステップであって、各々の前記第３公開鍵は、それぞれの前記第２公開鍵に対応する、ステップと、
第１ブロックチェーントランザクションを生成するステップであって、前記第１ブロックチェーントランザクションのインプットは、複数の前記参加者の各々のそれぞれの前記第１秘密鍵に対応するそれぞれのデジタル署名を用いて実行可能なスクリプトであり、各々の前記第１秘密鍵は、前記参加者により行われた前記選択を表し、前記第１ブロックチェーントランザクションのアウトプットは、前記参加者により行われた前記選択に基づく前記決定を表すスクリプトである、ステップと、
第１デジタルアセットを移転する第２ブロックチェーントランザクションを生成するステップであって、前記第２ブロックチェーントランザクションのアウトプットの実行は、前記第１ブロックチェーントランザクションの前記決定に対応する前記第３公開鍵に対応するデジタル署名を必要とする、ステップと、
を含む方法。
【請求項２】
前記第１ブロックチェーントランザクションのインプットは、管理者により処理された第４公開鍵によりアクセス可能なスクリプトである、請求項１に記載の方法。
【請求項３】
前記第１ブロックチェーントランザクションのアウトプットは、管理者により処理された第５公開鍵によりアクセス可能なマルチ署名スクリプトである、請求項１又は２に記載の方法。
【請求項４】
複数の前記第１秘密鍵は、前記マルチ署名スクリプトの公開鍵フィールドに格納される、請求項３に記載の方法。
【請求項５】
前記第１ブロックチェーントランザクションのそれぞれのインプットに対応する少なくとも１つのアウトプットを有する第３ブロックチェーントランザクションを生成するステップ、を更に含む請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットの実行は、それぞれの前記第１秘密鍵に対応する少なくとも１つのデジタル署名を要求する、請求項５に記載の方法。
【請求項７】
前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットの実行は、少なくとも１つの秘密鍵を要求する、請求項５又は６に記載の方法。
【請求項８】
前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットは、前記第１公開鍵に対応する前記暗号演算を適用するスクリプトである、請求項７に記載の方法。
【請求項９】
前記参加者から暗号化形式で前記第１秘密鍵を受信するステップ、を更に含む請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記第２ブロックチェーントランザクションが実行されない場合、前記第１デジタルアセットの少なくとも一部を返金する第４ブロックチェーントランザクションを生成するステップ、を更に含む請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記第４ブロックチェーントランザクションはタイムロックされる、請求項１０に記載の方法。
【請求項１２】
前記暗号演算は楕円曲線スカラ乗算である、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１３】
請求項１乃至１２のいずれか一項に記載の方法を実施するコンピュータシステム。
【請求項１４】
コンピュータにより実装されるシステムであって、
プロセッサと、
前記プロセッサによる実行の結果として、前記システムに請求項１乃至１３のいずれか一項に記載のコンピュータにより実施される方法の任意の実施形態を実行させる実行可能命令を含むメモリと、
を含むシステム。
【請求項１５】
実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、請求項１乃至１３のいずれか一項に記載の方法を実行させる、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、自動化された意思決定のためのシステム及び方法に関し、より詳細には、ブロックチェーンを介して行う自動化された決定に関する。本発明は、特に、ブロックチェーンを介する投票の方法における使用に適するが、これに限定されない。
【背景技術】
【０００２】
本願明細書では、私たちは、全ての形式の電子的、コンピュータに基づく、分散型台帳を包含するために用語「ブロックチェーン」を使用する。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、並びにこれらの変形を含む。他のブロックチェーン実装が提案され開発されているが、ブロックチェーン技術の最も広く知られているアプリケーションは、Bitcoin台帳である。Bitcoinは、ここでは、便宜上及び説明の目的で参照されることがあるが、本発明はBitcoinブロックチェーンと共に使用することに限定されず、代替のブロックチェーン実装及びプロトコルが本発明の範囲に包含されることに留意すべきである。用語「ユーザ」は、ここでは、人間またはプロセッサに基づくリソースを表してよい。
【０００３】
ブロックチェーンは、コンピュータに基づく非集中型の分散型システムとして実装されるピアツーピアの電子台帳であり、ブロックにより構成され、ブロックはまたトランザクションにより構成される。各トランザクションは、ブロックチェーンシステムの中の参加者間でデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、これらのブロックは一緒に繋げられて、起源以来ブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能な記録を生成する。トランザクションは、スクリプトとして知られている小さなプログラムを含む。スクリプトは、それらのインプット及びアウトプットを埋め込まれ、トランザクションのアウトプットがどのように及び誰によりアクセス可能であるかを指定する。Bitcoinプラットフォームでは、これらのスクリプトはスタックに基づくスクリプト言語を用いて記述される。
【０００４】
トランザクションがブロックチェーンに書き込まれるためには、検証されなければならない。ネットワークノード（マイナー）は、無効なトランザクションがネットワークから拒否され、各トランザクションが有効であることを保証するために作業を実行する。ノードにインストールされたソフトウェアクライアントは、未使用トランザクション（unspent  transaction,  UTXO）のロック及びアンロックスクリプトを実行することにより、UTXOに対してこの検証作業を実行する。ロック及びアンロックスクリプトの実行が真（TRUE）と評価する場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、（ｉ）トランザクションを受信した第１ノードにより検証され、トランザクションが有効な場合には、ノードが該トランザクションをネットワーク内の他のノードに中継する、（ｉｉ）マイナーにより構築された新しいブロックに追加される、（ｉｉｉ）マイニングされる、つまり過去のトランザクションのパブリック台帳に追加される、ことが必要である。
【０００５】
ブロックチェーン技術は、暗号通貨の実装の使用のために最も広く知られているが、デジタル事業家が、Bitcoinの基づく暗号セキュリティシステム及び新しいシステムを実装するためにブロックチェーンに格納できるデータの両方の使用を開発し始めている。ブロックチェーンが、暗号通貨の分野に限定されない自動化タスク及びプロセスのために使用できれば、非常に有利になる。このようなソリューションは、ブロックチェーンの利益（例えば、永久性、イベントの記録の耐タンパ性、分散型処理、等）を利用しながら、それらの用途をより多様化し得る。
【０００６】
自動化された意思決定の場合には、多くの状況で、決定が要因のセットに依存するだけでなく、決定は複数のパーティの意見にも依存し得る。さらに、各パーティは、要因のうちの１つに関連する選択を行うよう指名されてよい。このような状況では、各パーティの選択は、記録され検証されること、及びパーティの個々の選択が全て最終的に行われる決定に反映されることが望ましい。例えば、来るシーズンのために製品を購入する必要のある小売店の場合、購入すべき製品の選択は仕入れ係から生じてよく、供給者の選択は上位管理部門から来てよく、会社が支払う総額は経理部門から来てよい。最終決定は、３つのパーティの各々からのインプットの反映である。
【０００７】
これらの複数の層をなす決定は、特定レベルに対応する要因に関して行われる選択が他のレベルにおける他の選択に必ずしも依存しない決定木を想起させる。木を通る各々のユニークなパスは、下位決定の特定の結合に対応する。Bitcoinのような暗号通貨の分散型台帳（ブロックチェーン）は、このような意思決定のために有用であり得る幾つかの特徴を有する。これらのうちの第１のものは、ブロックチェーンがトランザクション内に含まれる動作（アクション）／データの不変の記録を提供することである。同時に、台帳の透過性は、決定プロセスの中で種々のパーティのそれぞれのインプットの検証及び確認が可能であることを意味する。
【０００８】
Bitcoinのような暗号通貨において特徴付けられるスクリプト（Script）プログラミング言語は、Bitcoinトランザクションのアウトプット／トークン／コインがアクセスされる条件を決定する洗練されたルールセットの機会を与える。このスマートコントラクト能力は、コントラクトの実行の成功が複数パーティの意思決定プロトコルの中で存在する選択に依存する投票システムの設計のために使用できる。
【０００９】
ブロックチェーンは、任意の種類の投票の操作を回避するために、投票及び意見が公に及び永久的に記録され得る適切な環境を構成する。この能力にも関わらず、ブロックチェーン上でセキュアな投票を生成するためには、解決すべき多数の問題がある。これらは、複数の無記名投票を防ぐことからユーザのプライバシを維持し及び信用をチェックすることまで広範囲に及ぶ。
【００１０】
一例として、非集中化は、オンライン電子投票の重要な課題であり、既存の構成は、通常、悪用を防ぐが、投票又はフィードバックを検証し及び考慮するために中央当局に依存する方法で構成される。中央当局は、例えば投票と投票者との間のリンクを隠すためにブロードキャストする前に投票を再び混ぜて暗号化するミキシング機関へ投票を送信する参加者による無記名投票に対して適格の秘密性及び検証を追加するために、ブラインド署名及び準同型暗号（homomorphic  encryption）のような異なる暗号プリミティブを使用してよい。
【００１１】
投票提出のための非集中化暗号化方法は、中央の信頼機関への依存性を除去する。例えば、セキュアな複数パーティ計算（MultiーParty  Computations：MPC）プロトコルは、その目標が、信頼できる第三者を必要とせずに、ユーザの集合が彼らの共同の秘密のインプットの関数を計算することを可能にすることであり、パーティが秘密に及びセキュアに彼らの平均投票を共同で計算することを可能にする。集約機能の効率的な計算のための１つの知られているプロトコルは、匿名投票の特定の場合に容易に移転可能なプロセスを有する。これは、「参加者のクラスタ」の使用を含む。ここで、クラスタは、木又はリングのトポロジで構造化される。ユーザの投票用紙は、更に準同型である関数により暗号化され、暗号化された値は、同じクラスタの全ての他のメンバーに通信される。各ユーザは、集約された値を計算し、これをリングの場合には次のクラスタに、又は木の場合には親クラスタに渡す。累積的に集約された値は、最終的又はルートクラスタにおいて解読される。道すがら集約される値の中の矛盾は、多数決により解決される。これは、敵対するノードが存在し特定数より少ない場合に、任意の所与のクラスタ内の大多数のノードが正直なノードであるように設計されるクラスタリングプロセスによりサポートされる。
【００１２】
プロトコルは、また、投票者のプライバシを守るよう提案されている。これは、提出された無記名投票の正しさ及び参加者の誠実さを検証するために計算上高価なゼロ知識証明（zero  knowledge  proof）を導入することにより達成される。デポジットが悪意ある行為の場合に要求され及び没収され得るメカニズムも実施されている。
【００１３】
これらのプロトコルでは、多数決を通じて勝者を決定することに基づくことが強調される。
【発明の概要】
【００１４】
したがって、投票者の集合から得られる投票のユニークな結合により勝者が決定される構成を提供することが望ましい。
【００１５】
したがって、本発明によると、添付の請求項において定められる方法が提供される。
【００１６】
本発明によると、ブロックチェーン上で決定を行う方法であって、前記決定は、複数の参加者の各々により行われた少なくとも１つのそれぞれの選択に基づき、前記方法は、
複数の参加者の各々から、それぞれの複数の公開鍵を受信するステップであって、各々の前記第１公開鍵は、前記参加者による可能な選択を表し、準同型特性を有する暗号演算により対応する第１秘密鍵に関連付けられる、ステップと、
前記準同型特性により、前記第１公開鍵を結合して、複数の第２公開鍵を生成するステップであって、各々の前記第２公開鍵は、前記可能な選択の結合に基づく可能な決定を表す、ステップと、
前記複数の参加者の各々に、複数の第３公開鍵を通信するステップであって、各々の前記第３公開鍵は、それぞれの前記第２公開鍵に対応する、ステップと、
第１ブロックチェーントランザクションを生成するステップであって、前記第１ブロックチェーントランザクションのインプットは、複数の前記参加者の各々のそれぞれの前記第１秘密鍵に対応するそれぞれのデジタル署名を用いて実行可能なスクリプトであり、各々の前記第１秘密鍵は、前記参加者により行われた前記選択を表し、前記第１ブロックチェーントランザクションのアウトプットは、前記参加者により行われた前記選択に基づく前記決定を表すスクリプトである、ステップと、
第１デジタルアセットを移転する第２ブロックチェーントランザクションを生成するステップであって、前記第２ブロックチェーントランザクションのアウトプットの実行は、前記第１ブロックチェーントランザクションの前記決定に対応する前記第３公開鍵に対応するデジタル署名を必要とする、ステップと、
を含む方法が提供されてよい。
【００１７】
これは、参加者が、第１ブロックチェーントランザクションにより表される決定が該参加者により行われた選択を考慮にいれることをチェックすることを可能にし、それにより、参加者の全員をよりよく代表する決定を行うという利点を提供する。また、決定が第３公開鍵により検証されることを可能にするという利点も提供される。
【００１８】
前記第１ブロックチェーントランザクションのインプットは、管理者により処理された第４公開鍵によりアクセス可能なスクリプトであってよい。
【００１９】
これは、決定の投票プロセスの監督及び／又は制御を可能にするという利点を提供する。
【００２０】
前記第１ブロックチェーントランザクションのアウトプットは、管理者により処理された第５公開鍵に対応するデジタル署名によりアクセス可能なマルチ署名スクリプトであってよい。
【００２１】
これは、トランザクションがブロックチェーン上で容易に伝播する形式であることを可能にするという利点を提供する。
【００２２】
複数の前記第１秘密鍵は、前記マルチ署名スクリプトの公開鍵フィールドに格納されてよい。
【００２３】
これは、データがトランザクションに格納されブロックチェーン上で容易に送信されることを可能にするという利点を提供する。
【００２４】
方法は、前記第１ブロックチェーントランザクションのそれぞれのインプットに対応する少なくとも１つのアウトプットを有する第３ブロックチェーントランザクションを生成するステップ、を更に含んでよい。
【００２５】
前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットの実行は、それぞれの前記第１秘密鍵に対応する少なくとも１つのデジタル署名を要求してよい。
【００２６】
前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットの実行は、少なくとも１つの秘密鍵を要求してよい。
【００２７】
これは、参加者を参加者の選択により直接的に接続し、及びパーティが他のパーティにより行われた選択の知識と独立にトランザクションに署名できるようにするという利点を提供する。
【００２８】
前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットは、前記第１公開鍵に対応する前記暗号演算を適用するスクリプトであってよい。
【００２９】
方法は、暗号化形式で前記参加者からの前記秘密鍵を受信するステップを更に含んでよい。
【００３０】
前記第２ブロックチェーントランザクションが実行されない場合、前記第１デジタルアセットの少なくとも一部を返金する第４ブロックチェーントランザクションを生成するステップ、を更に含んでよい。
【００３１】
前記第４ブロックチェーントランザクションはタイムロックされてよい。
【００３２】
前記準同型演算は、楕円曲線スカラ乗算であってよい。
【００３３】
本発明は、
プロセッサと、プロセッサによる実行の結果として、システムに本願明細書に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、
を含むシステムも提供する。
【００３４】
本発明は、実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、本願明細書に記載のコンピュータにより実施される方法を実行させる、非一時的コンピュータ可読記憶媒体も提供する。
【００３５】
本発明の上述の及び他の態様は、本願明細書に記載の実施形態から明らかであり、及びそれを参照して教示される。本発明の実施形態は、単なる例を用いて及び添付の図面を参照して以下に説明される。
【図面の簡単な説明】
【００３６】
【図１】本発明を実施する方法において使用するための決定木を示す。
【図２】図２の決定木の結果セットを示す。
【図３】本発明を実施する方法における公開鍵の可能な要約を示す。
【図４】本発明を実施する方法からのブロックチェーントランザクションを示す。
【図５】図４のコミットメントトランザクションを示す。
【図６】図４の投票トランザクションを示す。
【図７】図４の支払いトランザクションを示す。
【図８】図４の返金トランザクションを示す。
【図９】図５のコミットメントトランザクションのアウトプットスクリプトを示す。
【図１０】本発明を実施する方法のフローチャートを示す。
【図１１】本発明の更なる実施形態のブロックチェーントランザクションを示す。
【図１２】図１１のコミットメントトランザクションを示す。
【図１３】本発明の更なる実施形態のフローチャートを示す。
【図１４】種々の実施形態が実装できるコンピューティング環境を示す概略図である。
【発明を実施するための形態】
【００３７】
＜EC鍵ペアの準同型性＞
提案する複数要因複数パーティ（multi−factor  multi−party：MFMP）の決定プロトコルの早い段階でユーザのシークレット値を隠すために、本願において楕円曲線（Elliptic  Curve：EC）暗号化を利用する理由は、ECの秘密−公開鍵間駅の準同型特性（homomorphic  property）［６］のためである。
x１G+x２G=(x１+x２)G
ｘは秘密鍵であり、GはECの起点（base  point）であり、xGはｘの対応する公開鍵である。
【００３８】
より一般的には、ここで、E(x)=ｘG、
E(m+n)=E(m)+E(n)
これに対して準同型ハッシュ関数（及び／又は暗号関数）が存在する：
H(m+n)=H(m)+H(n)
これらの準同型ハッシュ関数も、EC暗号準同型秘密−公開鍵関係がMFMPプロトコルに対して行う何らかの鍵機能を達成する。
【００３９】
また、本願では加算が利用されるが、準同型特性は加算のためでなくてよい。つまり、本願の貢献は、ハッシュ／暗号関数の準同型特性が他の演算子のためである場合に、達成できる。一例として、演算子が乗算であり、以下を検討する。
H(mn)=H(m)×H(n)
ここで、H()はハッシュ／暗号関数である。
【００４０】
より一般的には、演算子が一般的な演算子（○の中に＋）である場合、次式の通りである：
【数１】
2021511535.tif 000003
ここで、H()はハッシュ／暗号関数である。
【００４１】
したがって、このような場合には、演算子がMFMPプロトコルの設計に等価に適用され、準同型性が活動し始める。
【００４２】
＜データ記憶としてのm−of−nマルチ署名スクリプト＞
Bitcoinトランザクションがメタデータの記憶のために専用のフィールドを有しない場合、MFMPプロトコルの成功は、パーティが責任を割り当てられている決定要因に対して該パーティにより行われた選択を記録するための適切な位置を見付けることに依存する。
【００４３】
MFMPプロトコルの提案される設計では、投票は、m−of−nマルチ署名（マルチシグネチャ、multisig）トランザクションのBitcoinのスクリプトを用いて格納される。これらのマルチ署名要素は、最初にBitcoinスクリプトに組み込まれ、その結果、１つより多くの鍵がBitcoinトランザクションに権限を与えることを要求する。
【００４４】
m−of−nマルチ署名スクリプトは、以下のフォーマットを取る。
OP_０  Sig１  Sig２  …  NumSigs  Pub１  Pub２  Pub３  Pub４  …  NumKeys  OP_CHECKMULTSIG
【００４５】
ここで、コンテンツNumSigs  Pub１  Pub２  Pub３  Pub４  …  NumKeys  OP_CHECKMULTSIGは、アウトプットスクリプト<scriptPubKey>のものであってよく、コンテンツOP_０  Sig１  Sig２はインプットスクリプト<scriptSig>のものであってよい。<scriptPubKey>は、トランザクションアウトプットを利用可能にするためのルールセットである。<scriptSig>は、<scriptPubKey>を満たすことを要求されるコンテンツである。
【００４６】
NumSigは必要な署名の数であり、NumKeysは可能な署名の数であり、PubXは署名SigXに対応する公開鍵である。
【００４７】
このスクリプトはm−of−n署名を意図しているが、RedeemスクリプトのPubX要素は、メタデータの格納として使用するために適切であり得る。
【００４８】
一例として、２−of−４マルチ署名スクリプトが示され、ここで、公開鍵のために予約された４個のデータ要素のうち、２個がメタデータを格納するために利用される。スクリプトは、以下のフォーマットを取る。
OP_０  SigA  SigB  OP_２  meta１  meta２  PubA  PubB  OP_４  OP_CHECKMULTSIG
これらのメタデータ要素は、決定全体のうちの特定の要因について決定する責任のあるパーティの暗号化された投票のセットを代表し得る。
【００４９】
一例として、１−of−７マルチ署名スクリプトが示され、ここで、公開鍵のために予約された７個のデータ要素のうち、５個が投票を格納するために利用され、２個が本物の（genuine）公開鍵を格納するために利用される。
【００５０】
スクリプトは、以下のフォーマットを取る。
OP_０  SigB  OP_１  ν１  ν２  ν３  ν４  ν５  PubA  PubB  OP_７  OP_CHECKMULTSIG
【００５１】
＜楕円曲線有限体演算及びオペコード＞
Bitcoinスクリプトの２００のオペコード制限が除去された場合、及び無効にされたオペコードが再び有効にされた場合、Bitcoinプロトコルは楕円曲線（Elliptic  Curve：EC）有限体演算（Finite  Field  Arithmetic）を実行することが分かっている。
【００５２】
明確化のために、楕円曲線は、次式により記述される点の集合である。
y２≡x３+ax+b(mod  p)
ここで、
【数２】
2021511535.tif 000004
pは素数（prime）である。
【００５３】
本願の目的のために、Bitcoinスクリプトの中で要求されるEC演算機能は、「スカラによる点乗算」である。これは、以下のような演算である。
【数３】
2021511535.tif 000005
ここで、nは自然数であり、Pは楕円曲線上の点であり、+はEC上の点の加算のための演算子である。
【００５４】
スカラ乗算は、また、特定のECグループ演算である、点加算（Point  Addition）及び点２倍算（Point  Doubling）を必要とする。
・点加算（Point  Addition）、P+Q：この演算により、EC上の新しい点を、曲線の交差の否定として計算する。これは、R=P+Qと記述できる。
・点２倍算（Point  Doubling）、P+P：点加算を用いて、Pの点の２倍を計算できる。これは、R=P+P=２Pと記述できる。
【００５５】
より具体的には、２つの点P(x１,y１)及びQ(x２,y２)が与えられると、EC上で、
P+Q=(x３,y３)
ここで、
x３=m２−x１−x２mod  p
y３=m(x１−x３)−y１mod  p
及び
【数４】
2021511535.tif 000006
乗算Q=kGをもたらすECオペコードを利用する。このオペコードはOP_ECPMULTという名称である。言い換えると、OP_ECPMULTは、符号化された楕円曲線点及び数値を取り入れ、スカラにより楕円曲線乗算を実行する。これは、符号化された楕円曲線点として結果を出力する。
【００５６】
＜複数要因複数パーティ決定プロトコル＞
＜概要＞
MFMPプロトコルは、決定木を想起させる意思決定システムを実現する。複数要因複数パーティ決定木では、木の各レベル（ルートノードがレベル１である）は特定の「パーティ及び要因」を表し、各ノードのブランチの各々は特定の要因に関してパーティの行う選択を表す。図１は、本願のMFMPプロトコルと同一基準の決定木を示す。図中の各ノードは、「パーティ及び要因（party−and−factor’）」を表し、ノード間の各リンク／エッジは、要因に関連するオプションである。図示の決定木では、n=３個の要因（及びn個のパーティ）が存在し、各要因はm=２個のオプションを提供する。MFMPプロトコルでは、mは、必要に応じて又は適切な場合には、要因毎に変化してよい。
【００５７】
一般に、各「パーティ及び要因」はノードUiにより表され、ここで、iはパーティが決定を行う要因を表し、例えば、UAは要因Aに基づき決定を行うパーティを表す。各要因aについて、オプションのセット{ka,j:∈[０,ma]}があり、パーティはこれから選択してよく、ここで、maはオプションの数である。Ok個のノードは、可能な決定、又はパーティの選択の結合から生じる結果（Outcomes）を表す。それぞれのパーティにより選択されたオプションは、決定木の中の結果OXへ向かうパスを形成する。
【００５８】
MFMPプロトコルは、要因についての選択のセットが、別のパーティにより行われた選択にかかわらず、同じままであるシナリオにのみ応じる。{ka,j}は{kb,j}と独立である。例えば、図１で、kA,１又はkA,２がUAにより選択されたかに関わらず、UBに利用可能なオプションはkB,１及びkB,２のままである。これは、単に対称的な決定木をもたらす。
【００５９】
多数決が勝者を決定する他の投票プロトコルとは反対に、MFMPプロトコルでは、投票のユニークな結合が誰が勝つか（どんな結果か）を決定する。１つのパーティによる「投票」は、特定の結果Oiについての投票ではなく、「可能な結果のセット」についての投票である。図１から、UAがkA,１を投票した場合、これは、結果セット{O１,O２,O３,O４}に対する選択を表す。
・UBがkB,１を投票した場合、これは、結果セット{O１,O２,O５,O６}に対する選択を表す。
・UCがkC,２を投票した場合、これは、結果セット{O２,O４,O６,O８}に対する選択を表す。
【００６０】
３つのパーティのシークレット値結合(kA,１,kB,１,kC,２)の結果は、結果O２の３つのセットの交点（intersection）である（図２を参照）。
【００６１】
＜プロトコルの詳細＞
＜管理者（Supervisor）＞
MFMPプロトコルは、管理者（Supervisor）と呼ばれる管理エンティティの使用により実行されるよう設計される。この管理者は、複数要因複数パーティ決定が行われるエンティティ、及び／又はプロトコルの実行を監督する責任を与えられたエンティティ、例えば会社のCEOであることが期待される。この管理者は、意思決定プロセスの最終結果に資金を供給するためにコインを提供する者であってもよい。この管理者は、トランザクション構成し、適切な場合にはトランザクションインプットの署名し、及び適切な順序で、適時的情報で、トランザクションを生成しブロックチェーンに提出する責任を有する。
【００６２】
管理者は、また、決定関連要因に関して行われ得る可能な選択のセット及び対応する結果を、説明し、確立し、又は各投票パーティと交渉する。
【００６３】
＜初期化及び鍵＞
全てのパーティは、Bitcoinで使用される標準化された楕円曲線、secp２５６k１、及び以下を含む関連するパラメータのセットに合意する：
G：次数q:q×G=０を有する楕円曲線上の起点、
q：大きな素数。
【００６４】
意思決定プロセスで要因に割り当てられた各パーティについて、該パーティは、彼ら自身でシークレットka,i値のセットを生成するよう依頼される。ここで、aは決定要因を表し、iは該決定要因のオプションのセットのうちの１つを表す。このセットの中には、ma個のシークレットka,i値がある。ka,i値は、０<ka,i<qを満たす。
【００６５】
各パーティは、プロトコルのこの時点で、それ自体のそれぞれのka,i値を秘密に保持することを期待される。各ka,i値について、パーティUaは、対応する公開鍵の値Qa,i=ka,iGを計算する。
【００６６】
＜階層構造及びまとめ＞
各パーティは、それ自体のそれぞれの公開鍵{Qa,i}を、（管理者を含む）全ての他のパーティと共有する。各パーティは、彼らの公開鍵のどれがパーティの割り当てられた要因に関連する選択肢のセットのうちのどの要素に対応するかについて、管理者と合意する。全ての他のパーティからの公開鍵により、パーティは、（彼らの個々について、）公開鍵を合計する全ての可能な結合を計算する。ここで、合計の中にはn個の要素があり、合計の各要素は、異なる投票パーティの公開鍵である。合計は、決定鍵階層構造の可能なパスに沿って公開鍵を加算することに対応する（図３）。また、「EC鍵ペアの準同型性」の章で上述したように、加算以外の準同型性関数及び／又は演算子が使用されてよい。
【００６７】
図３に示した例から、公開鍵の可能な合計は（どのパーティが計算を行うかに関わらず）、以下の通りである：
O１=QA,１+QB,１+QC,１
O２=QA,１+QB,１+QC,２
…
O７=QA,２+QB,２+QC,１
O８=QA,２+QB,２+QC,２
各パーティは、各合計がどのように取得されるかの記録を保持することを期待される。これを行うことにより、各パーティは、（Qa,iを介して）自身のシークレットka,i値のうちのどれが特定のOi個の結果値を得るのに利用されたかを知る。
【００６８】
例えば、パーティUAは、要因Aについて、彼／彼女が「１」を選択する又は選択した場合（QA,１を介してkA,iにより表される）、彼／彼女の選択kA,iを考慮に入れる結果が、O１,O２,O３,及びO４になり得ることを知っている。
【００６９】
「EC鍵ペアの準同型性」の章で上述したEC秘密−公開鍵関係の準同型特性により、結果Oxについて、n個の要因／パーティが存在し、以下の通りであることに留意する：
Ox=QA,i+QB,j+…+Qn,k
=kA,iG+kB,jG+…kn,kG
=(kA,i+kB,j+…kn,k)G
nka,ia,i個の値の合計は、sνxとラベル付けされる。したがって、
sνx=kA,i+kB,j+…kn,k
及び：
Ox=sνxG
【００７０】
管理者の責任は、MFMPインスタンスの各Ox結果に直接関連付けられるべき新しい公開鍵／アドレスSXを各投票パーティに通信することである。これはペアのセット{(Ox,Sx)}になり、ここで、セット{Ox}はセット{Sx}と全単射（bijective  with）である。数学的に、全単射、全単射関数、又は１対１対応は、２つの集合の要素の間の関数であり、一方の集合の各要素は他方の集合の正確に１つの要素と対にされ、他方の集合の各要素は最初の集合の正確に１つの要素と対にされ、その結果、対にされない要素が存在しないことであることが、当業者により理解される。公開鍵Sxは、必ずしも管理者自身に属しないが、結果に関する義務を実行することを任された別個の個人により所有されてよい。公開鍵を「所有すべき」人物、又は人物に「属する」公開鍵について、この文脈では、人物が公開鍵に対応する秘密鍵の知識を有することを意味する。
【００７１】
特定の要因に関して特定の方法で投票する場合、可能な結果の自身のセットを知っている各パーティは、コミットメントトランザクションを調べて、エスクロースクリプト内のOx値に関連するオプションが正しい公開鍵Sxと対にされていることを保証する。その結果、両方の公開鍵は、アクセスされるべきエスクロー資金またはトークンに順に署名する必要がある。基本的に、パーティは、コミットメントトランザクションのエスクローアウトプット内で意思決定プロセスの可能な結果Oxのうちの１つが（管理者との先の合意に従い）正しいSxに結びつけられている場合、自身の投票を提供しないことを選択してよい。
【００７２】
＜実施形態１：トランザクション及び選択文書化＞
MFMPプロトコルは、４個のコアトランザクション、つまりコミットメントトランザクションTC、支払いトランザクションTP、返金トランザクションTR、及び投票トランザクションTV、に基づき構築される。図４に、これら４個のトランザクションの境界が示される。
【００７３】
図４では、各トランザクションは、丸角を有する長方形により表される。トランザクションのインプット及びアウトプットは、基本長方形により示される。インプットはトランザクションの左半分に示され、一方、アウトプットはトランザクションの右半分に示される。インプット及びアウトプットの長方形のラベルは、それぞれ「コインのソース（source  of  coins）」及び「意図された受信者」の公開鍵のものである。例えば、Saは、投票トランザクションのための資金源であると同時に、コミットメントトランザクションの資金の受信者である。本例では、人物の公開鍵は、人物自身のラベルとして使用されてよい。Escアウトプット／インプットは、アウトプット−インプットが１つの特定のアドレス／公開鍵に向けられないが、明言された基準を満たす能力に基づき異なる鍵によりアクセス可能であるという例外である。
【００７４】
＜コミットメントトランザクション＞
コミットメントトランザクションTC（図４及び５を参照）は、MFMPプロトコルの主要トランザクションであり、そのインプットとして、全ての投票パーティの選択を表す１つの結果に資金提供するためのコインFuを含む。これらの資金は、管理者Sと題されたエンティティ／個人からであると想定される。一例として、この管理者は、会社の財務に責任のある、会社のCEO又は会計係／出納官であり得る。Saとラベル付けされたアドレスから、管理者がこれらの資金を提供する。
【００７５】
コミットメントトランザクションは、少なくとも２つのアウトプットを有することが期待される。これらのうちの１つ目は、管理者に属する第２アドレスへ転送される僅かな料金のものである。このアウトプットアドレスは、コミットメントトランザクションをブロックチェーンに格納された情報を利用する投票トランザクションにリンクするための、保管人（stakeholders）にとっての容易な手段として利用される。これらの資金のアドレスは、管理者により所有される第２アドレスSbである。
【００７６】
コミットメントトランザクションの第２アウトプットは、ある量のコインを預託（エスクロー、escrow）するものである。ここで、決定木の「勝者の」結果は、これらのエスクローされたコインを受信する（又はそれらから資金供給される）。資金が特定のアウトプットアドレス／公開鍵に対して直接排他的ではないが、これらの資金を可能なアドレスのセットのうちの１つへ移転させるこのアウトプットのBitcoinスクリプトに付加された条件を有するとき、このアウトプットは、「エスクロー」されていると記載される。ここで、コインが許可される最終的なアドレスは、スクリプトで規定された基準が満たされることに依存する。
【００７７】
このスクリプトは、参加パーティの必要なka,i値が利用可能である場合、条件セットがエスクローされたコインへのアクセスを与えるだけのものである。より具体的には、エスクロー資金のアウトプットアドレスの選択のためのスクリプト内の基準は、署名が公開鍵Ox及びSxについて生成されることである。ここで、
Ox=sνxG
sνx=kA,i+kB,j+…kn,k
Sxは結果Oxと対にされたユニークなアウトプットアドレスである。
【００７８】
＜投票トランザクション＞
投票トランザクションTV（図４及び６を参照）は、パーティの署名した決定要因に関して該パーティの行った選択を記録することを担う。
【００７９】
この投票トランザクションは、コミットメントトランザクションのSbアウトプットを投票トランザクションのインプットとして用いることにより、コミットメントトランザクションに「リンクされる」。ここで、Sbは管理者により制御される第２アドレスである。このリンクは３つの目的を提供する。
【００８０】
・TC及びTVをリンクする。両方の（投票及びコミットメント）トランザクションの間で共有されるアドレスは、保管人がブロックチェーン内で前述の２つのトランザクションのうちの一方を発見した場合に、保管人が他方のトランザクションを容易に読み出すことを可能にする。コミットメントトランザクションは投票トランザクションより前にブロックチェーン上に置かれることに留意する。したがって、コミットメントトランザクションは、投票トランザクションが共に存在することなく、ブロックチェーン上に存在してよいが、逆はない。
・関連付けを記録する。このリンクは、コミットメントトランザクション及びそのエスクロー資金とパーティにより投じられた投票との間の文書化された関連付けを提供する。
・管理者の認可。（投票トランザクションの）インプットSbに署名する管理者がパーティの投票の管理者の受諾の正式な表現として機能するとき、投票トランザクション内のインプットとして含まれる管理者のアドレスは、管理者に、投じられている投票に対する管理の要素を与える。
【００８１】
投票トランザクション自体は、管理者により構成され、次にパーティに渡されることが期待され、その結果、各パーティは、彼らの投票をトランザクションに追加してよい。投票はka,i値である。m−of−nマルチ署名スクリプト内の公開鍵のために予約されたフィールドは、投票トランザクション内の投票を格納するために使用される。このスクリプトは、投票トランザクションのアウトプットスクリプト<scriptPubKey>として使用される。Bitcoinでは、<scriptPubKey>はトランザクションアウトプットを利用させるルールセットであることが、当業者に知られている。<scriptSig>は、<scriptPubKey>を満たすことを要求されるコンテンツである。
【００８２】
ka,i値を含むm−of−nスクリプトを含む投票トランザクションの現在バージョンは、ここで、管理者へ返される。パーティにより提供されるnka,i値のセットを所有する管理者は、(kA,i+kB,j+…kn,k)Gが計算された階層構造からのOx個の結果のうちの１つに等しいかどうかを決定することにより、投票を検証し得る。
【００８３】
投票の結合が検証される場合、管理者は、投票トランザクションのアウトプットスクリプト<scriptPubKey>のm−of−nマルチ署名スクリプトに、公開鍵Saを追加する。これは管理者の主要公開鍵（「アドレス」）であり、管理者は、投票トランザクションのアウトプットでコインのうちの幾らかを使用したいと望む、任意のトランザクションの<scriptSig>のSaに対する署名を生成することを期待される。
【００８４】
このアウトプットを使用するトランザクションのインプットスクリプトと結合される投票トランザクションのアウトプットスクリプトの一例は、以下に示される。
OP_０  Sig  SaOP_１kA,IkB,jkC,kPubSaOP_４OP_CHECKMULTSIG
<scriptPubKey>のこの１−of−４マルチ署名は、要因A、B、Ｃに責任のあるパーティにより投じられた３つの投票を含み、公開鍵Saも含む。
【００８５】
投票トランザクションの現在バージョンは、次に、各パーティへ再送信される。各パーティは、彼／彼女の投票がアウトプットスクリプトの最終バージョンに含まれていることを確認し、トランザクションへの彼／彼女のインプットに署名して、投票トランザクションの彼らの認可を表す。つまり、彼らは、彼らの投票が投票トランザクションに含まれていることを承認する。管理者は、投票トランザクションへの彼のインプットに署名し、次に、投票トランザクションはブロックチェーンへと提出される。
【００８６】
代替として、各パーティは、セキュアな方法で彼らの投票を管理者に通信してよい。管理者は、次に、全ての投票を投票トランザクションのアウトプットスクリプトに追加し、次に、このトランザクションを種々のパーティのそれぞれのインプット署名のために、該種々のパーティへ送信する。
【００８７】
以下に留意すべきである。
・各パーティが投票トランザクションへの彼らのインプットのために利用する／貢献する資金／コインは、最小限、又は僅かな料金である。投票トランザクションは、資金の移転と言うよりは、投票の不変の記録という意味が大きい。
・Bitcoinプロトコルの現在バージョンでは、マルチ署名アウトプットにおいて許容可能な公開鍵の最大数は１５である。この理由から、説明したm−of−nマルチ署名スクリプトが許容し得る最大投票（投票者）数は１４である（１５個の空間のうちの１つが管理者の公開鍵Saのために予約されることに留意する）。複数の冗長なm−of−nマルチ署名（サブ）スクリプトを含む、より手の込んだスクリプトは、より多くの投票を組み込むよう構成されてよいが、スクリプトの最大サイズは１０キロバイト[７]であり、トランザクションコストはトランザクションのサイズに依存することに留意する。
・適用可能な場合には、管理者もは決定に関連する要因に基づき投票を行ってよい。
【００８８】
＜支払いトランザクション＞
支払いトランザクションTP（図４及び７を参照）は、コミットメントトランザクション（図４及び５を参照）のEscアウトプットでエスクローされたコインへのアクセスに成功し得るトランザクションである。このトランザクションは、そのインプットスクリプト<scriptSig>内に２つの署名を含む。１つ目は公開鍵Oxに対する署名であり、
(kA,i+kB,j+…kn,k)G=Ox
各ka,iは異なる決定関連要因のためのものである。
【００８９】
スクリプト内に存在するka,i値のユニークな結合は、誰（公開−秘密鍵対の所有者）がEscコインにアクセスできるかの決定要素である。これらのka,i値は、ブロックチェーン上で利用可能な投票トランザクションから読み出されてよい。
【００９０】
支払いトランザクションのインプットスクリプト内の２つ目の署名は、Oxを管理する責任を割り当てられた個人の公開鍵である公開鍵Sxのためのものである。これは、必ずしも、プロトコルの主要な管理者（Sa及びSbの所有者）ではないが、任意の別の認可された個人であり得る。さらに、適切な場合には、特にセキュリティ／制御目的で、第３の署名が、支払いトランザクションのインプットスクリプトのために要求されてよい。ここで、第３の署名は、主要な管理者のものである。
【００９１】
支払いトランザクションのインプットが成功裏に署名された場合、コミットメントトランザクションのエスクローされたコインは、結果Oxに関連する受信者アドレスRxへ移動できる。支払いトランザクションは、投票トランザクションの後に、ブロックチェーンに提出される。
【００９２】
＜返金トランザクション＞
返金トランザクション（図４及び８）は、エスクロー資金を、コミットメントトランザクションに資金貢献した全てのパーティ（管理者又はその他）に返すトランザクションである。これは、プロトコルの参加者が然るべく行動しなかった場合のフェールセーフ手段として見える。重要なことに、この返金トランザクションは、特定時点（Unix時間又はブロック高）が経過した後まで、ブロックチェーンにより受け入れられることを防ぐnTimeLock値を含む。
【００９３】
返金トランザクションのインプットスクリプトは、コミットメントトランザクションのエスクローされたアウトプットスクリプト内で利用可能なオプションのうちの１つを満たし得るデータを含む。このデータは、（エスクロー資金をコミットした）主要な管理者及び他の保管人の署名であってよい。全ての他の保管人は、コミットメントトランザクションが管理者によりブロックチェーンに提出される前に、返金トランザクションに署名しなければならない。これは、失敗した場合に、管理者が全てのコミットしたエスクロー資金を回収できることを保証する。
【００９４】
返金トランザクションは、任意的なトランザクションであり、MFMPプロトコルインスタンスの支払いトランザクションが提出されなかった場合に、ブロックチェーンに提出できるだけである。さらに、返金トランザクションは、特定時点の後にのみ、提出できる。このことに留意すると、返金トランザクションのnTimeLock値は、コミットメントトランザクションが時間Tに提出された後に、以下のための十分な時間が与えられるように、選択されなければならない：
・投票が得られること
・投票トランザクションがブロックチェーンにコミットされること
・投票トランザクションがブロックチェーンの中で発見されること
・支払いトランザクションが生成され、ブロックチェーンに提出されること。
【００９５】
全てを達成するために指定された時間（範囲）は、sとラベル付けされる。返金トランザクションのnTimeLock値は、少なくとも以下であってよい：
nTimeLock=T+s
時間nTimeLock値は、秒又はブロック高で定義できることに留意する。
【００９６】
＜エスクロー関連スクリプト＞
＜アウトプットスクリプト：コミットメントトランザクションエスクロー＞
コミットメントトランザクションのエスクロー資金は、可能な方法のセットについて、エスクロー資金がアクセスされ／請求され／使用されることを可能にするスタックに基づくスクリプト言語により「保護」されることが期待される。エスクロー資金にアクセスするこれらの方法の各々は、資金が回収されるために満たされなければならない関連する基準セットを有する。エスクロースクリプトは、基本的に、場合分け文の中の各オプションがエスクロー資金にアクセスする異なる方法である、場合分け文のセットを表すように見える。t個のオプションがあると仮定すると、これらのオプションのうちのtー１個について（１つの基準は返金署名に関連付けられる）、各場合の基準は（少なくとも）以下である：
ECDSA署名は、(kA,i+kB,j+…kn,k)G=Oxの公開鍵アドレスのために生成されるべきである、
且つ
ECDSA署名は、Oxの管理役の誰かの公開鍵Sxのために生成されるべきである。
【００９７】
図９は、（８個の点を特徴とする）エスクロー場合分け文を表すBitcoinアウトプットスクリプトの高レベルバージョンを示す。(cond_i)は満たされる必要のある基準／条件を表し、[Do_i]は、(cond_i)が真と評価された場合に実行されるべき動作を表す。
【００９８】
より具体的にいうと、これはアウトプットスクリプトに関連するので、２つのECSDA署名の必要性を表すために使用されてよい条件(cond_i)が、以下のような２−of−２マルチ署名（サブ）スクリプトのものである：
OP_２  PubOx  PubSx  OP_２  OP_CHECKMULTSIG
．．．
ここで、PubOx=(kA,i+kB,j+…kn,k)G及びPub  Sxは、結果Oxに割り当てられたエンティティの公開鍵である。
【００９９】
スクリプトの各[Do_i]要素が実行するよう依頼される動作は、(cond_i)が真と評価されるとすると、スタックの一番上に値１/TRUEを預ける（deposit）ことである。Bitcoinスクリプトはスタックに基づく言語であること、及びスクリプト実行の完了後にスタックの一番上にある「真（TRUE）」の値はスクリプトが成功裏に実行されたことを意味することが、当業者に理解される。
【０１００】
＜インプットスクリプト：支払いトランザクション＞
コミットメントトランザクションのエスクローされたアウトプットのコインに成功裏にアクセスするために、これは、エスクローされたアウトプットのアウトプットスクリプト<scriptPubKey>が支払いトランザクションのインプットスクリプト<scriptSig>と結合されるとき、結合されたスクリプトが成功裏に実行すること、つまりスタックの一番上に１/TRUEを生成することを要求する。
【０１０１】
少なくとも１つのデータ要素<data_i>がインプットスクリプトに含まれなければならない。該インプットスクリプトは、アウトプットスクリプトのif文のうちの少なくとも１つが真であることをもたらし、最終的には、結合されたインプット及びアウトプットスクリプトを真と評価することをもたらす。
【０１０２】
留意すべきことに、<data_i>はデータの複数のフィールドを表してよい。一例として、<data_i>は、２−of−２マルチ署名スクリプトの３つの値、つまり<op_０><sigOx><sigSc>の結合であってよい。
【０１０３】
また留意すべきことに、オプションが考慮されることに依存して、適切な場合には、一部の冗長データ<bd_datai>も、インプットスクリプトに含まれてよい。<bd_dti>、「bad  data」は、(cond_i)により処理されるとき、アウトプットとして０/FALSEを生成することを保証するデータを表すことを意味する。<data_i>と同様に、<bd_dti>は服すの個々のデータ要素から構成されてよい。実際に、<bd_dti>は、<data_i>のような同じ数のデータ要素で構成されることが期待される。
【０１０４】
＜MFMPフローチャート＞
図１０は、複数要因複数パーティ（Multi−factor  multi−party）の投票プロトコルの一般的概要を示す。
【０１０５】
図１１〜１３に、本発明の更なる実施形態の構成を示す。
【０１０６】
＜実施形態２：トランザクション及び選択文書化＞
本実施形態は、第１の実施形態の複数要因複数パーティと以下の点で異なる：第１の実施形態はパーティの投票を、投票トランザクションのm−of−nマルチ署名アウトプットスクリプトに含まれる投票の結合されたセットとして記録したが、本実施形態は、投票パーティに、投票トランザクションのインプットスクリプトの引数として彼らの投票を含めることにより、彼らの投票を開示するよう依頼する。こうすることにより、これは、パーティを彼らの投票により直接的に接続し、及びパーティが他のパーティの投票の知識と独立にトランザクションに署名できるようにするという利点を提供する。
【０１０７】
第１の実施形態では、種々のパーティの投票は、投票トランザクションのm−of−nマルチ署名スクリプトに格納された。彼らの投票が投票トランザクション内に提示される及び／又は文書化されることの確認を示すために、各パーティ（例えば、図１１のパーティA、B、C）は、投票トランザクションの彼らの対応するインプットに署名する。この署名はこのような確認として見えるが、どの投票がどの参加者に属するかは、ブロックチェーン内に文書化されない。この情報は、幾つかのシナリオにおいて有用であり得る。同時に、全てのパーティが彼らの投票をm−of−nマルチ署名アウトプットスクリプトに与えるまで、パーティは投票トランザクションに署名できない。
【０１０８】
第２の実施形態は、第１の実施形態の複数要因複数パーティ意思決定プロトコルの変形を導入する。該変形は、パーティの記憶装置に対して記述された制限、及び該プロトコルの投票トランザクション内の投票の確認を解決する。投票トランザクションのインプットとして使用される資金にアクセスするために、パーティが彼らの投票を開示することを、該パーティに強制することにより、これを行う。
【０１０９】
これを達成するために、Bitcoinスクリプトの中に、楕円曲線（Elliptic  Curve：EC）「スカラによる点乗算」を可能にするオペコードが存在するとする。これは、また、Bitcoinスクリプトの２００オペコード制限が除去されること、及び無効にされたオペコードが再有効化されることを要求する。楕円曲線（EC）暗号法における秘密−公開鍵関係の準同型性特性を含む本実施形態で利用される技術は、提案されるオペコードと共に、以上に詳細に説明された。
【０１１０】
本実施形態の提案されるオペコードは、投票が格納される（投票）トランザクションの要素、その後、投票が提示されたことの確認として、「いつ、どのように」署名を開始できるかについて、第１の実施形態のMFMPプロトコルと異なる。
【０１１１】
＜コミットメントトランザクション＞
第１の実施形態による場合におけるように、第２の実施形態は、４個のコアトランザクション、つまりコミットメントトランザクションTC、支払いトランザクションTP、返金トランザクションTR、及び投票トランザクションTV、に基づき構築される。図１１に、これら４個のトランザクションの境界が示される。
【０１１２】
＜コミットメントトランザクション＞
本実施形態のコミットメントトランザクションは、図１１及び１２に示されるように、本実施形態のコミットメントトランザクションが少なくとも４個のアウトプットを有することを期待される点が、第１の実施形態のものと異なる。第１アウトプットは、管理者に属する第２アドレスSbへ移転される僅かな料金のものである。このアウトプットアドレスは、コミットメントトランザクションをブロックチェーンに格納された情報を利用する投票トランザクションにリンクするための、保管人（stakeholders）にとっての容易な手段として利用される。更に重要なことに、これらのアウトプットは投票トランザクションへのインプットであり、署名を必要とするインプットであるので、これは、管理者に投票トランザクションに対する権限を与える方法として機能する。
【０１１３】
コミットメントトランザクションの第２アウトプットは、第１の実施形態の場合におけるように、ある量のコインを預託（エスクロー、escrow）するものである。ここで、決定木の「勝者の」結果は、これらのエスクローされたコインを受信する（又はそれらから資金供給される）。
【０１１４】
第２の実施形態は、他のアウトプット（これらのうち、少なくとも２が存在する）が投票パーティ、例えば図１１及び１２のパーティA、B、及びCに属する公共アドレスへのものであるという点で第１の実施形態と更に異なる。これらのアウトプットは、資金にアクセスするために、パーティが彼らそれぞれの投票（及び公開鍵Aに対する署名）を生成するよう要求されるよう設計されるべきである。一例として、パーティAがコミットメントトランザクションのAアウトプットを使用しようとした場合、彼／彼女は、投票トランザクションのインプットスクリプトに公開鍵QA,i=kA,iGを含むこと、したがって、ブロックチェーン上で彼らの投票kA,iを公開することが必要である。
【０１１５】
パーティが彼らに割り当てられた要因に関連する幾つかの方法で投票してよいならば、投票パーティ（例えばパーティA）のコミットメントトランザクションのアウトプットスクリプト<scriptPubKey>は資金にアクセスするための幾つかのオプションを含まなければならず、該オプションの各々は、投票パーティのためのオプションのうちの１つに基づく。図９を参照して説明した、複数オプションの（ifーelseでネストされた）高レベルスクリプトの構造を用いて、オプションからの資金の支払いを可能にする条件(cond_i)のBitcoinスクリプトは、以下の通りである：
<Basepoint  G>  OP_ECPMULT  <QA,i>  OP_EQUALVERIFY  <pubA>  OP_CHECKSIG
このスクリプトは、「楕円曲線有限体演算及びオペコード」の章で上述した提案したオペコードOP_ECPMULTを利用することが分かる。
【０１１６】
(cond_i)が満たされるために、投票パーティAは要素<data  i>を含める必要がある。
<<Sig  A>  <kA,i>>
ここで、sig  Aは公開鍵Aの署名であり、kA,iはパーティAの投票である。
【０１１７】
留意すべきことに、パーティAの投票は、アクセスするパーティAの、コミットメントトランザクションのアウトプットの処理の一部として<data  i>の中で開示される。
【０１１８】
＜投票トランザクション＞
第２の実施形態の投票トランザクション（図１１を参照）は、コミットメントトランザクションのSbアウトプット及び投票パーティのアウトプットを通じて、コミットメントトランザクションに「リンクされる」。コミットメントトランザクションのこれらのアウトプットは、投票トランザクションのインプットである。
【０１１９】
投票トランザクション自体は、管理者により構成され、次にパーティに渡されることが期待され、その結果、各パーティは、それぞれのインプットに署名してよい。自身の投票トランザクションへのインプットに署名するパーティは、該パーティの投票ka,iが開示されることを、（上述のコミットメントトランザクションから）思い出すべきである。
【０１２０】
管理者は、投票トランザクションへの彼のインプットに署名し、次に、投票トランザクションはブロックチェーンへと提出される。
【０１２１】
留意すべきことに、各パーティが投票トランザクションへの彼らのインプットのために利用する／貢献するコインは、最小限、又は僅かな料金である。投票トランザクションは、資金の移転と言うよりは、投票の不変の記録という意味が大きい。
【０１２２】
図１３は、複数要因複数パーティの投票プロトコルの一般的概要を示す。
【０１２３】
図１４を参照すると、本開示の少なくとも一実施形態を実施するために使用され得るコンピューティング装置２６００の説明のための簡略ブロック図が提供される。種々の実施形態で、コンピューティング装置２６００は、上述の図示のシステムのうちのいずれかを実装するために使用されてよい。例えば、コンピューティング装置２６００は、データサーバ、ウェブサーバ、ポータブルコンピューティング装置、パーソナルコンピュータ、又は任意の電子コンピューティング装置として使用するために構成されてよい。図１４に示すように、コンピューティング装置２６００は、主メモリ２６０８及び永久記憶装置２６１０を含む記憶サブシステム２６０６と通信するよう構成され得る１つ以上のレベルのキャッシュメモリ及びメモリ制御部（集合的に２６０２とラベル付けされる）を備える１つ以上のプロセッサを含んでよい。主メモリ２６０８は、図示のように、動的ランダムアクセスメモリ（ＤＲＡＭ）２６１８及び読み出し専用メモリ（ＲＯＭ）２６２０を含み得る。記憶サブシステム２６０６及びキャッシュメモリ２６０２は、本開示で説明されたようなトランザクション及びブロックに関連付けられた詳細事項のような情報の記憶のために使用されてよい。プロセッサ２６０２は、本開示で説明されたような任意の実施形態のステップ又は機能を提供するために利用されてよい。
【０１２４】
プロセッサ２６０２は、１つ以上のユーザインタフェース入力装置２６１２、１つ以上のユーザインタフェース出力装置２６１４、及びネットワークインタフェースサブシステム２６１６とも通信できる。
【０１２５】
バスサブシステム２６０４は、コンピューティング装置２６００の種々のコンポーネント及びサブシステムが意図した通りに互いに通信できるようにするメカニズムを提供してよい。バスサブシステム２６０４は、単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は、複数のバスを利用してよい。
【０１２６】
ネットワークインタフェースサブシステム２６１６は、他のコンピューティング装置及びネットワークへのインタフェースを提供してよい。ネットワークインタフェースサブシステム２６１６は、幾つかの実施形態では、コンピューティング装置２６００の他のシステムからデータを受信し及びそれへデータを送信するインタフェースとして機能してよい。例えば、ネットワークインタフェースサブシステム２６１６は、データ技術者が、装置をネットワークに接続することを可能にする。その結果、データ技術者は、データセンタのような遠隔地にいがなら、データを装置へ送信し、データを装置から受信できる。
【０１２７】
ユーザインタフェース入力装置２６１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのような指示装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含んでよい。通常、用語「入力装置」の使用は、コンピューティング装置２６００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。
【０１２８】
１つ以上のユーザインタフェース出力装置２６１４は、ディスプレイサブシステム、プリンタ、又は音声出力装置のような非視覚的ディスプレイ、等を含んでよい。ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面装置、又は他のディスプレイ装置を含んでよい。通常、用語「出力装置」の使用は、コンピューティング装置２６００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置２６１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用されてよい。
【０１２９】
記憶サブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構造を記憶するコンピュータ可読記憶媒体を提供してよい。アプリケーション（例えば、プログラム、コードモジュール、命令）は、１つ以上のプロセッサにより実行されると、本開示の１つ以上の実施形態の機能を提供し、記憶サブシステム２６０６に格納されてよい。これらのアプリケーションモジュール又は命令は、１つ以上のプロセッサ２６０２により実行されてよい。記憶サブシステム２６０６は、更に、本開示に従い使用されるデータを格納するレポジトリを提供する。例えば、主メモリ２６０８及びキャッシュメモリ２６０２は、プログラム及びデータのための揮発性記憶を提供できる。永久記憶装置２６１０は、プログラム及びデータの永久（不揮発性）記憶を提供でき、磁気ハードディスクドライブ、取り外し可能媒体に関連付けられた１つ以上のフロッピディスクドライブ、取り外し可能媒体に関連付けられた１つ以上の光ドライブ（例えば、ＣＤ−ＲＯＭ、又はＤＶＤ、又はＢｌｕｅ−Ｒａｙ）ドライブ、及び他の同様の記憶媒体を含んでよい。このようなプログラム及びデータは、本開示に記載した１つ以上の実施形態のステップを実行するためのプログラム、及び本開示に記載したトランザクション及びブロックに関連付けられたデータを含み得る。
【０１３０】
コンピューティング装置２６００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのものであってよい。さらに、コンピューティング装置２６００は、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置２６００に接続可能な別の装置を含み得る。コンピューティング装置２６００に接続され得る装置は、光ファイバコネクタを受けるよう構成される複数のポートを含んでよい。したがって、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置２６００に送信される電気信号に変換するよう構成されてよい。コンピュータ及びネットワークの絶えず変化する特性により、図１４に示したコンピューティング装置２６００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図１４に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。
【０１３１】
上述の実施形態は、本発明を限定するのではなく、説明すること、及び当業者は添付の特許請求の範囲により定められる本発明の範囲から逸脱することなく多くの代替的実施形態を考案できることに留意すべきである。特許請求の範囲において、括弧内の任意の参照符号は、請求項を限定することを意図しない。用語「有する」及び「含む」（comprising、comprises）等は、任意の請求項又は明細書全体に列挙されたもの以外の要素またはステップの存在を排除しない。本願明細書では、「有する」は「有する又は構成される」を意味し、「含む」は「含む又は構成される」を意味する。要素の単数の参照は、該要素の複数の参照を排除しない。逆も同様である。本発明は、幾つかの別個の要素を含むハードウェアにより、及び適切にプログラムされたコンピュータにより、実装できる。幾つかの手段を列挙する装置クレームでは、これらの手段のうちの幾つかは、１つの同じハードウェアアイテムにより具現化されてよい。単に特定の手段が相互に異なる従属請求項に記載されるという事実は、これらの手段の組み合わせが有利に使用されないことを示さない。
【０１３２】
参考文献
表１
【表１】
2021511535.tif 000007
【図１】
2021511535.tif 000008
【図２】
2021511535.tif 000009
【図３】
2021511535.tif 000010
【図４】
2021511535.tif 000011
【図５】
2021511535.tif 000012
【図６】
2021511535.tif 000013
【図７】
2021511535.tif 000014
【図８】
2021511535.tif 000015
【図９】
2021511535.tif 000016
【図１０】
2021511535.tif 000017
【図１１】
2021511535.tif 000018
【図１２】
2021511535.tif 000019
【図１３】
2021511535.tif 000020
【図１４】
2021511535.tif 000021
【国際調査報告】
2021511535.tif 000022
2021511535.tif 000023