特開 2024-113064 コンピュータにより実施される意思決定システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024113064

(43)【公開日】2024-08-21

(54)【発明の名称】コンピュータにより実施される意思決定システム及び方法

(51)【国際特許分類】

   H04L 9/08 20060101AFI20240814BHJP

   G09C 1/00 20060101ALI20240814BHJP

   H04L 9/32 20060101ALI20240814BHJP

【ＦＩ】

H04L9/08 C

G09C1/00 620Z

H04L9/32 200C

【審査請求】有

【請求項の数】13

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024091064

(22)【出願日】2024-06-05

(62)【分割の表示】P 2023032350の分割

【原出願日】2019-01-10

(31)【優先権主張番号】1800818.5

(32)【優先日】2018-01-18

(33)【優先権主張国・地域又は機関】GB

(71)【出願人】

【識別番号】318001991

【氏名又は名称】エヌチェーン ライセンシング アーゲー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】バルトルッチ，シルヴィア

(72)【発明者】

【氏名】ベルナト，ポーリーン

(72)【発明者】

【氏名】ジョーゼフ，ダニエル

(57)【要約】      （修正有）

【課題】ブロックチェーン上で決定を行う方法及びシステムを提供する。
【解決手段】方法は、第１公開鍵を、複数の参加者から受信し、各第１公開鍵を、参加者の可能な選択を表し、準同型特性を有する暗号演算により対応の第１秘密鍵に関連付けて結合し、可能な選択の結合に基づく可能な決定を表す第２公開鍵を生成し、第２公開鍵に対応し、参加者に通信され投票トランザクションを生成して第３公開鍵を生成する。投票トランザクションのインプットは、複数の参加者の各第１秘密鍵に対応のデジタル署名により実行可能であり、各第１秘密鍵は、参加者の選択を表し、投票トランザクションのアウトプットは、参加者の選択に基づく決定を表する。方法はまた、支払いトランザクションを、第１デジタルアセットの移転のために生成し、投票トランザクションの決定に対応する第３公開鍵に対応のデジタル署名を必要とするアウトプットを実行する。
【選択図】なし

【特許請求の範囲】

【請求項1】

ブロックチェーン上で決定を行う方法であって、前記決定は、複数の参加者の各々により行われた選択に基づき、前記方法は、
前記複数の参加者の各々において、
第１秘密鍵のセットと対応する第１公開鍵のセットとを生成するステップであって、各第１秘密鍵は前記参加者の可能な選択を表し、各第１公開鍵は準同型関数を有する暗号関数を用いて前記対応する第１秘密鍵から生成される、ステップと、
他の参加者の各々及び管理エンティティに、前記第１公開鍵のセットを提供するステップと、
前記他の参加者の各々から、各々の第１公開鍵のセットを受信するステップと、
複数の第２公開鍵を計算するステップであって、各第２公開鍵は、各参加者の各々の各々の第１公開鍵のセットからの１つのみの第１公開鍵を含む、前記第１公開鍵の組み合わせであり、各第２公開鍵は可能な決定に対応する、ステップと、
投票ブロックチェーントランザクションのアウトプットに含めるために、前記参加者の第１秘密鍵のセットのうちの、１つの第１秘密鍵を提供するステップであって、提供された第１秘密鍵は前記参加者により行われた選択に対応し、
前記投票ブロックチェーントランザクションは複数のインプットを含み、１つのインプットは前記参加者の各々に対応し、１つのインプットは前記管理エンティティに対応し、
前記アウトプットの中のスクリプトの中の秘密鍵の組み合わせは、前記第２公開鍵のうちの第１の第２公開鍵に対応し、前記スクリプトは、前記参加者により行われた選択に基づく決定を表す、ステップと、
前記投票ブロックチェーントランザクションの前記アウトプットを検査して、前記参加者の提供した第１秘密鍵を含むことをチェックするステップと、
前記投票ブロックチェーントランザクションの前記参加者の各々のインプットに署名するステップと、
を含む方法。

【請求項2】

前記管理エンティティから、複数の第３公開鍵であって、各第３公開鍵は第２公開鍵に対応する、複数の第３公開鍵と、前記第２公開鍵と前記第３公開鍵との間の対応の指示と、を受信するステップ、を更に含む請求項１に記載の方法。

【請求項3】

第１秘密鍵を提供するステップの前に、
コミットメントブロックチェーントランザクションを取得するステップであって、前記コミットメントブロックチェーントランザクションは、前記投票ブロックチェーントランザクションへの前記管理エンティティの各々のインプットに対応する第１アウトプットと、対応する第２公開鍵と第３公開鍵とのペアリングを含む第２アウトプットと、を有する、ステップと、
前記コミットメントブロックチェーントランザクションの前記第２アウトプットを検査して、前記第２アウトプットの中の前記対応する第２公開鍵と第３公開鍵とのペアリングが前記管理エンティティから受信した対応の指示と同じであることをチェックするステップと、
を更に含む請求項２に記載の方法。

【請求項4】

前記管理エンティティにおいて、前記コミットメントブロックチェーントランザクションを生成するステップ、を更に含む請求項３に記載の方法。

【請求項5】

前記管理エンティティにおいて、第１デジタルアセットを移転するための支払いブロックチェーントランザクションを生成するステップ、を更に含み、
前記支払いブロックチェーントランザクションのインプットは、前記コミットメントブロックチェーントランザクションの前記第２アウトプットに対応し、
前記支払いブロックチェーントランザクションのアウトプットの実行は、前記投票ブロックチェーントランザクションの前記決定に対応する前記第３公開鍵に対応するデジタル署名を必要とする、請求項３又は４に記載の方法。

【請求項6】

前記管理エンティティにおいて、前記支払いブロックチェーントランザクションが実行されない場合に、前記第１デジタルアセットの少なくとも一部を返金するための返金ブロックチェーントランザクションを生成するステップ、を更に含む請求項５に記載の方法。

【請求項7】

前記返金ブロックチェーントランザクションはタイムロックされる、請求項６に記載の方法。

【請求項8】

前記管理エンティティにおいて、前記投票ブロックチェーントランザクションを生成するステップ、を更に含む請求項１～７のいずれかに記載の方法。

【請求項9】

前記投票ブロックチェーントランザクションのアウトプットの中のスクリプトは、前記管理エンティティにより処理された公開鍵を更に含む、請求項１～８のいずれかに記載の方法。

【請求項10】

暗号演算は楕円曲線スカラ乗算である、請求項１～９のいずれか一項に記載の方法。

【請求項11】

請求項１～１０のいずれか一項に記載の方法を実施するコンピュータシステム。

【請求項12】

コンピュータにより実装されるシステムであって、
プロセッサと、
前記プロセッサによる実行の結果として、前記システムに請求項１～１０のいずれかに記載のコンピュータにより実施される方法を実行させる実行可能命令を含むメモリと、
を含むシステム。

【請求項13】

実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、請求項１～１０のいずれかに記載の方法を実行させる、非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、自動化された意思決定のためのシステム及び方法に関し、より詳細には、ブロックチェーンを介して行う自動化された決定に関する。本発明は、特に、ブロックチェーンを介する投票の方法における使用に適するが、これに限定されない。

【背景技術】

【0002】

本願明細書では、私たちは、全ての形式の電子的、コンピュータに基づく、分散型台帳を包含するために用語「ブロックチェーン」を使用する。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、並びにこれらの変形を含む。他のブロックチェーン実装が提案され開発されているが、ブロックチェーン技術の最も広く知られているアプリケーションは、Bitcoin台帳である。Bitcoinは、ここでは、便宜上及び説明の目的で参照されることがあるが、本発明はBitcoinブロックチェーンと共に使用することに限定されず、代替のブロックチェーン実装及びプロトコルが本発明の範囲に包含されることに留意すべきである。用語「ユーザ」は、ここでは、人間またはプロセッサに基づくリソースを表してよい。

【0003】

ブロックチェーンは、コンピュータに基づく非集中型の分散型システムとして実装されるピアツーピアの電子台帳であり、ブロックにより構成され、ブロックはまたトランザクションにより構成される。各トランザクションは、ブロックチェーンシステムの中の参加者間でデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、これらのブロックは一緒に繋げられて、起源以来ブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能な記録を生成する。トランザクションは、スクリプトとして知られている小さなプログラムを含む。スクリプトは、それらのインプット及びアウトプットを埋め込まれ、トランザクションのアウトプットがどのように及び誰によりアクセス可能であるかを指定する。Bitcoinプラットフォームでは、これらのスクリプトはスタックに基づくスクリプト言語を用いて記述される。

【0004】

トランザクションがブロックチェーンに書き込まれるためには、検証されなければならない。ネットワークノード（マイナー）は、無効なトランザクションがネットワークから拒否され、各トランザクションが有効であることを保証するために作業を実行する。ノードにインストールされたソフトウェアクライアントは、未使用トランザクション（unspent transaction, UTXO）のロック及びアンロックスクリプトを実行することにより、UTXOに対してこの検証作業を実行する。ロック及びアンロックスクリプトの実行が真（TRUE）と評価する場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、（ｉ）トランザクションを受信した第１ノードにより検証され、トランザクションが有効な場合には、ノードが該トランザクションをネットワーク内の他のノードに中継する、（ｉｉ）マイナーにより構築された新しいブロックに追加される、（ｉｉｉ）マイニングされる、つまり過去のトランザクションのパブリック台帳に追加される、ことが必要である。

【0005】

ブロックチェーン技術は、暗号通貨の実装の使用のために最も広く知られているが、デジタル事業家が、Bitcoinの基づく暗号セキュリティシステム及び新しいシステムを実装するためにブロックチェーンに格納できるデータの両方の使用を開発し始めている。ブロックチェーンが、暗号通貨の分野に限定されない自動化タスク及びプロセスのために使用できれば、非常に有利になる。このようなソリューションは、ブロックチェーンの利益（例えば、永久性、イベントの記録の耐タンパ性、分散型処理、等）を利用しながら、それらの用途をより多様化し得る。

【0006】

自動化された意思決定の場合には、多くの状況で、決定が要因のセットに依存するだけでなく、決定は複数のパーティの意見にも依存し得る。さらに、各パーティは、要因のうちの１つに関連する選択を行うよう指名されてよい。このような状況では、各パーティの選択は、記録され検証されること、及びパーティの個々の選択が全て最終的に行われる決定に反映されることが望ましい。例えば、来るシーズンのために製品を購入する必要のある小売店の場合、購入すべき製品の選択は仕入れ係から生じてよく、供給者の選択は上位管理部門から来てよく、会社が支払う総額は経理部門から来てよい。最終決定は、３つのパーティの各々からのインプットの反映である。

【0007】

これらの複数の層をなす決定は、特定レベルに対応する要因に関して行われる選択が他のレベルにおける他の選択に必ずしも依存しない決定木を想起させる。木を通る各々のユニークなパスは、下位決定の特定の結合に対応する。Bitcoinのような暗号通貨の分散型台帳（ブロックチェーン）は、このような意思決定のために有用であり得る幾つかの特徴を有する。これらのうちの第１のものは、ブロックチェーンがトランザクション内に含まれる動作（アクション）／データの不変の記録を提供することである。同時に、台帳の透過性は、決定プロセスの中で種々のパーティのそれぞれのインプットの検証及び確認が可能であることを意味する。

【0008】

Bitcoinのような暗号通貨において特徴付けられるスクリプト（Script）プログラミング言語は、Bitcoinトランザクションのアウトプット／トークン／コインがアクセスされる条件を決定する洗練されたルールセットの機会を与える。このスマートコントラクト能力は、コントラクトの実行の成功が複数パーティの意思決定プロトコルの中で存在する選択に依存する投票システムの設計のために使用できる。

【0009】

ブロックチェーンは、任意の種類の投票の操作を回避するために、投票及び意見が公に及び永久的に記録され得る適切な環境を構成する。この能力にも関わらず、ブロックチェーン上でセキュアな投票を生成するためには、解決すべき多数の問題がある。これらは、複数の無記名投票を防ぐことからユーザのプライバシを維持し及び信用をチェックすることまで広範囲に及ぶ。

【0010】

一例として、非集中化は、オンライン電子投票の重要な課題であり、既存の構成は、通常、悪用を防ぐが、投票又はフィードバックを検証し及び考慮するために中央当局に依存する方法で構成される。中央当局は、例えば投票と投票者との間のリンクを隠すためにブロードキャストする前に投票を再び混ぜて暗号化するミキシング機関へ投票を送信する参加者による無記名投票に対して適格の秘密性及び検証を追加するために、ブラインド署名及び準同型暗号（homomorphic encryption）のような異なる暗号プリミティブを使用してよい。

【0011】

投票提出のための非集中化暗号化方法は、中央の信頼機関への依存性を除去する。例えば、セキュアな複数パーティ計算（MultiーParty Computations：MPC）プロトコルは、その目標が、信頼できる第三者を必要とせずに、ユーザの集合が彼らの共同の秘密のインプットの関数を計算することを可能にすることであり、パーティが秘密に及びセキュアに彼らの平均投票を共同で計算することを可能にする。集約機能の効率的な計算のための１つの知られているプロトコルは、匿名投票の特定の場合に容易に移転可能なプロセスを有する。これは、「参加者のクラスタ」の使用を含む。ここで、クラスタは、木又はリングのトポロジで構造化される。ユーザの投票用紙は、更に準同型である関数により暗号化され、暗号化された値は、同じクラスタの全ての他のメンバーに通信される。各ユーザは、集約された値を計算し、これをリングの場合には次のクラスタに、又は木の場合には親クラスタに渡す。累積的に集約された値は、最終的又はルートクラスタにおいて解読される。道すがら集約される値の中の矛盾は、多数決により解決される。これは、敵対するノードが存在し特定数より少ない場合に、任意の所与のクラスタ内の大多数のノードが正直なノードであるように設計されるクラスタリングプロセスによりサポートされる。

【0012】

プロトコルは、また、投票者のプライバシを守るよう提案されている。これは、提出された無記名投票の正しさ及び参加者の誠実さを検証するために計算上高価なゼロ知識証明（zero knowledge proof）を導入することにより達成される。デポジットが悪意ある行為の場合に要求され及び没収され得るメカニズムも実施されている。

【0013】

これらのプロトコルでは、多数決を通じて勝者を決定することに基づくことが強調される。

【発明の概要】

【0014】

したがって、投票者の集合から得られる投票のユニークな結合により勝者が決定される構成を提供することが望ましい。

【0015】

したがって、本発明によると、添付の請求項において定められる方法が提供される。

【0016】

本発明によると、ブロックチェーン上で決定を行う方法であって、前記決定は、複数の参加者の各々により行われた少なくとも１つのそれぞれの選択に基づき、前記方法は、
複数の参加者の各々から、それぞれの複数の公開鍵を受信するステップであって、各々の前記第１公開鍵は、前記参加者による可能な選択を表し、準同型特性を有する暗号演算により対応する第１秘密鍵に関連付けられる、ステップと、
前記準同型特性により、前記第１公開鍵を結合して、複数の第２公開鍵を生成するステップであって、各々の前記第２公開鍵は、前記可能な選択の結合に基づく可能な決定を表す、ステップと、
前記複数の参加者の各々に、複数の第３公開鍵を通信するステップであって、各々の前記第３公開鍵は、それぞれの前記第２公開鍵に対応する、ステップと、
第１ブロックチェーントランザクションを生成するステップであって、前記第１ブロックチェーントランザクションのインプットは、複数の前記参加者の各々のそれぞれの前記第１秘密鍵に対応するそれぞれのデジタル署名を用いて実行可能なスクリプトであり、各々の前記第１秘密鍵は、前記参加者により行われた前記選択を表し、前記第１ブロックチェーントランザクションのアウトプットは、前記参加者により行われた前記選択に基づく前記決定を表すスクリプトである、ステップと、
第１デジタルアセットを移転する第２ブロックチェーントランザクションを生成するステップであって、前記第２ブロックチェーントランザクションのアウトプットの実行は、前記第１ブロックチェーントランザクションの前記決定に対応する前記第３公開鍵に対応するデジタル署名を必要とする、ステップと、
を含む方法が提供されてよい。

【0017】

これは、参加者が、第１ブロックチェーントランザクションにより表される決定が該参加者により行われた選択を考慮にいれることをチェックすることを可能にし、それにより、参加者の全員をよりよく代表する決定を行うという利点を提供する。また、決定が第３公開鍵により検証されることを可能にするという利点も提供される。

【0018】

前記第１ブロックチェーントランザクションのインプットは、管理者により処理された第４公開鍵によりアクセス可能なスクリプトであってよい。

【0019】

これは、決定の投票プロセスの監督及び／又は制御を可能にするという利点を提供する。

【0020】

前記第１ブロックチェーントランザクションのアウトプットは、管理者により処理された第５公開鍵に対応するデジタル署名によりアクセス可能なマルチ署名スクリプトであってよい。

【0021】

これは、トランザクションがブロックチェーン上で容易に伝播する形式であることを可能にするという利点を提供する。

【0022】

複数の前記第１秘密鍵は、前記マルチ署名スクリプトの公開鍵フィールドに格納されてよい。

【0023】

これは、データがトランザクションに格納されブロックチェーン上で容易に送信されることを可能にするという利点を提供する。

【0024】

方法は、前記第１ブロックチェーントランザクションのそれぞれのインプットに対応する少なくとも１つのアウトプットを有する第３ブロックチェーントランザクションを生成するステップ、を更に含んでよい。

【0025】

前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットの実行は、それぞれの前記第１秘密鍵に対応する少なくとも１つのデジタル署名を要求してよい。

【0026】

前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットの実行は、少なくとも１つの秘密鍵を要求してよい。

【0027】

これは、参加者を参加者の選択により直接的に接続し、及びパーティが他のパーティにより行われた選択の知識と独立にトランザクションに署名できるようにするという利点を提供する。

【0028】

前記第３ブロックチェーントランザクションの少なくとも１つのアウトプットは、前記第１公開鍵に対応する前記暗号演算を適用するスクリプトであってよい。

【0029】

方法は、暗号化形式で前記参加者からの前記秘密鍵を受信するステップを更に含んでよい。

【0030】

前記第２ブロックチェーントランザクションが実行されない場合、前記第１デジタルアセットの少なくとも一部を返金する第４ブロックチェーントランザクションを生成するステップ、を更に含んでよい。

【0031】

前記第４ブロックチェーントランザクションはタイムロックされてよい。

【0032】

前記準同型演算は、楕円曲線スカラ乗算であってよい。

【0033】

本発明は、
プロセッサと、プロセッサによる実行の結果として、システムに本願明細書に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、
を含むシステムも提供する。

【0034】

本発明は、実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、本願明細書に記載のコンピュータにより実施される方法を実行させる、非一時的コンピュータ可読記憶媒体も提供する。

【0035】

本発明の上述の及び他の態様は、本願明細書に記載の実施形態から明らかであり、及びそれを参照して教示される。本発明の実施形態は、単なる例を用いて及び添付の図面を参照して以下に説明される。

【図面の簡単な説明】

【0036】

【図1】本発明を実施する方法において使用するための決定木を示す。

【図2】図２の決定木の結果セットを示す。

【図3】本発明を実施する方法における公開鍵の可能な要約を示す。

【図4】本発明を実施する方法からのブロックチェーントランザクションを示す。

【図5】図４のコミットメントトランザクションを示す。

【図6】図４の投票トランザクションを示す。

【図7】図４の支払いトランザクションを示す。

【図8】図４の返金トランザクションを示す。

【図9】図５のコミットメントトランザクションのアウトプットスクリプトを示す。

【図10】本発明を実施する方法のフローチャートを示す。

【図11】本発明の更なる実施形態のブロックチェーントランザクションを示す。

【図12】図１１のコミットメントトランザクションを示す。

【図13】本発明の更なる実施形態のフローチャートを示す。

【図14】種々の実施形態が実装できるコンピューティング環境を示す概略図である。

【発明を実施するための形態】

【0037】

＜EC鍵ペアの準同型性＞
提案する複数要因複数パーティ（multi－factor multi－party：MFMP）の決定プロトコルの早い段階でユーザのシークレット値を隠すために、本願において楕円曲線（Elliptic Curve：EC）暗号化を利用する理由は、ECの秘密－公開鍵間駅の準同型特性（homomorphic property）［６］のためである。
x_１G+x_２G=(x_１+x_２)G
ｘは秘密鍵であり、GはECの起点（base point）であり、xGはｘの対応する公開鍵である。

【0038】

より一般的には、ここで、E(x)=ｘG、
E(m+n)=E(m)+E(n)
これに対して準同型ハッシュ関数（及び／又は暗号関数）が存在する：
H(m+n)=H(m)+H(n)
これらの準同型ハッシュ関数も、EC暗号準同型秘密－公開鍵関係がMFMPプロトコルに対して行う何らかの鍵機能を達成する。

【0039】

また、本願では加算が利用されるが、準同型特性は加算のためでなくてよい。つまり、本願の貢献は、ハッシュ／暗号関数の準同型特性が他の演算子のためである場合に、達成できる。一例として、演算子が乗算であり、以下を検討する。
H(mn)=H(m)×H(n)
ここで、H()はハッシュ／暗号関数である。

【0040】

より一般的には、演算子が一般的な演算子（○の中に＋）である場合、次式の通りである：

【数1】

ここで、H()はハッシュ／暗号関数である。

【0041】

したがって、このような場合には、演算子がMFMPプロトコルの設計に等価に適用され、準同型性が活動し始める。

【0042】

＜データ記憶としてのm－of－nマルチ署名スクリプト＞
Bitcoinトランザクションがメタデータの記憶のために専用のフィールドを有しない場合、MFMPプロトコルの成功は、パーティが責任を割り当てられている決定要因に対して該パーティにより行われた選択を記録するための適切な位置を見付けることに依存する。

【0043】

MFMPプロトコルの提案される設計では、投票は、m－of－nマルチ署名（マルチシグネチャ、multisig）トランザクションのBitcoinのスクリプトを用いて格納される。これらのマルチ署名要素は、最初にBitcoinスクリプトに組み込まれ、その結果、１つより多くの鍵がBitcoinトランザクションに権限を与えることを要求する。

【0044】

m－of－nマルチ署名スクリプトは、以下のフォーマットを取る。
OP_０ Sig１ Sig２ … NumSigs Pub１ Pub２ Pub３ Pub４ … NumKeys OP_CHECKMULTSIG

【0045】

ここで、コンテンツNumSigs Pub１ Pub２ Pub３ Pub４ … NumKeys OP_CHECKMULTSIGは、アウトプットスクリプト<scriptPubKey>のものであってよく、コンテンツOP_０ Sig１ Sig２はインプットスクリプト<scriptSig>のものであってよい。<scriptPubKey>は、トランザクションアウトプットを利用可能にするためのルールセットである。<scriptSig>は、<scriptPubKey>を満たすことを要求されるコンテンツである。

【0046】

NumSigは必要な署名の数であり、NumKeysは可能な署名の数であり、PubXは署名SigXに対応する公開鍵である。

【0047】

このスクリプトはm－of－n署名を意図しているが、RedeemスクリプトのPubX要素は、メタデータの格納として使用するために適切であり得る。

【0048】

一例として、２－of－４マルチ署名スクリプトが示され、ここで、公開鍵のために予約された４個のデータ要素のうち、２個がメタデータを格納するために利用される。スクリプトは、以下のフォーマットを取る。
OP_０ SigA SigB OP_２ meta１ meta２ PubA PubB OP_４ OP_CHECKMULTSIG
これらのメタデータ要素は、決定全体のうちの特定の要因について決定する責任のあるパーティの暗号化された投票のセットを代表し得る。

【0049】

一例として、１－of－７マルチ署名スクリプトが示され、ここで、公開鍵のために予約された７個のデータ要素のうち、５個が投票を格納するために利用され、２個が本物の（genuine）公開鍵を格納するために利用される。

【0050】

スクリプトは、以下のフォーマットを取る。
OP_０ SigB OP_１ ν_１ ν_２ ν_３ ν_４ ν_５ PubA PubB OP_７ OP_CHECKMULTSIG

【0051】

＜楕円曲線有限体演算及びオペコード＞
Bitcoinスクリプトの２００のオペコード制限が除去された場合、及び無効にされたオペコードが再び有効にされた場合、Bitcoinプロトコルは楕円曲線（Elliptic Curve：EC）有限体演算（Finite Field Arithmetic）を実行することが分かっている。

【0052】

明確化のために、楕円曲線は、次式により記述される点の集合である。
y^２≡x^３+ax+b(mod p)
ここで、

【数2】

pは素数（prime）である。

【0053】

本願の目的のために、Bitcoinスクリプトの中で要求されるEC演算機能は、「スカラによる点乗算」である。これは、以下のような演算である。

【数3】

ここで、nは自然数であり、Pは楕円曲線上の点であり、+はEC上の点の加算のための演算子である。

【0054】

スカラ乗算は、また、特定のECグループ演算である、点加算（Point Addition）及び点２倍算（Point Doubling）を必要とする。
・点加算（Point Addition）、P+Q：この演算により、EC上の新しい点を、曲線の交差の否定として計算する。これは、R=P+Qと記述できる。
・点２倍算（Point Doubling）、P+P：点加算を用いて、Pの点の２倍を計算できる。これは、R=P+P=２Pと記述できる。

【0055】

より具体的には、２つの点P(x_１,y_１)及びQ(x_２,y_２)が与えられると、EC上で、
P+Q=(x_３,y_３)
ここで、
x_３=m^２－x_１－x_２mod p
y_３=m(x_１－x_３)－y_１mod p
及び

【数4】

乗算Q=kGをもたらすECオペコードを利用する。このオペコードはOP_ECPMULTという名称である。言い換えると、OP_ECPMULTは、符号化された楕円曲線点及び数値を取り入れ、スカラにより楕円曲線乗算を実行する。これは、符号化された楕円曲線点として結果を出力する。

【0056】

＜複数要因複数パーティ決定プロトコル＞
＜概要＞
MFMPプロトコルは、決定木を想起させる意思決定システムを実現する。複数要因複数パーティ決定木では、木の各レベル（ルートノードがレベル１である）は特定の「パーティ及び要因」を表し、各ノードのブランチの各々は特定の要因に関してパーティの行う選択を表す。図１は、本願のMFMPプロトコルと同一基準の決定木を示す。図中の各ノードは、「パーティ及び要因（party－and－factor’）」を表し、ノード間の各リンク／エッジは、要因に関連するオプションである。図示の決定木では、n=３個の要因（及びn個のパーティ）が存在し、各要因はm=２個のオプションを提供する。MFMPプロトコルでは、mは、必要に応じて又は適切な場合には、要因毎に変化してよい。

【0057】

一般に、各「パーティ及び要因」はノードU_iにより表され、ここで、iはパーティが決定を行う要因を表し、例えば、U_Aは要因Aに基づき決定を行うパーティを表す。各要因aについて、オプションのセット{k_a,j:∈[０,m_a]}があり、パーティはこれから選択してよく、ここで、m_aはオプションの数である。O_k個のノードは、可能な決定、又はパーティの選択の結合から生じる結果（Outcomes）を表す。それぞれのパーティにより選択されたオプションは、決定木の中の結果O_Xへ向かうパスを形成する。

【0058】

MFMPプロトコルは、要因についての選択のセットが、別のパーティにより行われた選択にかかわらず、同じままであるシナリオにのみ応じる。{k_a,j}は{k_b,j}と独立である。例えば、図１で、k_A,１又はk_A,２がU_Aにより選択されたかに関わらず、U_Bに利用可能なオプションはk_B,１及びk_B,２のままである。これは、単に対称的な決定木をもたらす。

【0059】

多数決が勝者を決定する他の投票プロトコルとは反対に、MFMPプロトコルでは、投票のユニークな結合が誰が勝つか（どんな結果か）を決定する。１つのパーティによる「投票」は、特定の結果O_iについての投票ではなく、「可能な結果のセット」についての投票である。図１から、U_Aがk_A,１を投票した場合、これは、結果セット{O_１,O_２,O_３,O_４}に対する選択を表す。
・U_Bがk_B,１を投票した場合、これは、結果セット{O_１,O_２,O_５,O_６}に対する選択を表す。
・U_Cがk_C,２を投票した場合、これは、結果セット{O_２,O_４,O_６,O_８}に対する選択を表す。

【0060】

３つのパーティのシークレット値結合(k_A,１,k_B,１,k_C,２)の結果は、結果O_２の３つのセットの交点（intersection）である（図２を参照）。

【0061】

＜プロトコルの詳細＞
＜管理者（Supervisor）＞
MFMPプロトコルは、管理者（Supervisor）と呼ばれる管理エンティティの使用により実行されるよう設計される。この管理者は、複数要因複数パーティ決定が行われるエンティティ、及び／又はプロトコルの実行を監督する責任を与えられたエンティティ、例えば会社のCEOであることが期待される。この管理者は、意思決定プロセスの最終結果に資金を供給するためにコインを提供する者であってもよい。この管理者は、トランザクション構成し、適切な場合にはトランザクションインプットの署名し、及び適切な順序で、適時的情報で、トランザクションを生成しブロックチェーンに提出する責任を有する。

【0062】

管理者は、また、決定関連要因に関して行われ得る可能な選択のセット及び対応する結果を、説明し、確立し、又は各投票パーティと交渉する。

【0063】

＜初期化及び鍵＞
全てのパーティは、Bitcoinで使用される標準化された楕円曲線、secp２５６k１、及び以下を含む関連するパラメータのセットに合意する：
G：次数q:q×G=０を有する楕円曲線上の起点、
q：大きな素数。

【0064】

意思決定プロセスで要因に割り当てられた各パーティについて、該パーティは、彼ら自身でシークレットk_a,i値のセットを生成するよう依頼される。ここで、aは決定要因を表し、iは該決定要因のオプションのセットのうちの１つを表す。このセットの中には、m_a個のシークレットk_a,i値がある。k_a,i値は、０<k_a,i<qを満たす。

【0065】

各パーティは、プロトコルのこの時点で、それ自体のそれぞれのk_a,i値を秘密に保持することを期待される。各k_a,i値について、パーティU_aは、対応する公開鍵の値Q_a,i=k_a,iGを計算する。

【0066】

＜階層構造及びまとめ＞
各パーティは、それ自体のそれぞれの公開鍵{Q_a,i}を、（管理者を含む）全ての他のパーティと共有する。各パーティは、彼らの公開鍵のどれがパーティの割り当てられた要因に関連する選択肢のセットのうちのどの要素に対応するかについて、管理者と合意する。全ての他のパーティからの公開鍵により、パーティは、（彼らの個々について、）公開鍵を合計する全ての可能な結合を計算する。ここで、合計の中にはn個の要素があり、合計の各要素は、異なる投票パーティの公開鍵である。合計は、決定鍵階層構造の可能なパスに沿って公開鍵を加算することに対応する（図３）。また、「EC鍵ペアの準同型性」の章で上述したように、加算以外の準同型性関数及び／又は演算子が使用されてよい。

【0067】

図３に示した例から、公開鍵の可能な合計は（どのパーティが計算を行うかに関わらず）、以下の通りである：
O_１=Q_A,１+Q_B,１+Q_C,１
O_２=Q_A,１+Q_B,１+Q_C,２
…
O_７=Q_A,２+Q_B,２+Q_C,１
O_８=Q_A,２+Q_B,２+Q_C,２
各パーティは、各合計がどのように取得されるかの記録を保持することを期待される。これを行うことにより、各パーティは、（Q_a,iを介して）自身のシークレットk_a,i値のうちのどれが特定のO_i個の結果値を得るのに利用されたかを知る。

【0068】

例えば、パーティU_Aは、要因Aについて、彼／彼女が「１」を選択する又は選択した場合（Q_A,１を介してk_A,iにより表される）、彼／彼女の選択k_A,iを考慮に入れる結果が、O_１,O_２,O_３,及びO_４になり得ることを知っている。

【0069】

「EC鍵ペアの準同型性」の章で上述したEC秘密－公開鍵関係の準同型特性により、結果O_xについて、n個の要因／パーティが存在し、以下の通りであることに留意する：
O_x=Q_A,i+Q_B,j+…+Q_n,k
=k_A,iG+k_B,jG+…k_n,kG
=(k_A,i+k_B,j+…k_n,k)G
nka,i_a,i個の値の合計は、sν_xとラベル付けされる。したがって、
sν_x=k_A,i+k_B,j+…k_n,k
及び：
O_x=sν_xG

【0070】

管理者の責任は、MFMPインスタンスの各O_x結果に直接関連付けられるべき新しい公開鍵／アドレスS_Xを各投票パーティに通信することである。これはペアのセット{(O_x,S_x)}になり、ここで、セット{O_x}はセット{S_x}と全単射（bijective with）である。数学的に、全単射、全単射関数、又は１対１対応は、２つの集合の要素の間の関数であり、一方の集合の各要素は他方の集合の正確に１つの要素と対にされ、他方の集合の各要素は最初の集合の正確に１つの要素と対にされ、その結果、対にされない要素が存在しないことであることが、当業者により理解される。公開鍵S_xは、必ずしも管理者自身に属しないが、結果に関する義務を実行することを任された別個の個人により所有されてよい。公開鍵を「所有すべき」人物、又は人物に「属する」公開鍵について、この文脈では、人物が公開鍵に対応する秘密鍵の知識を有することを意味する。

【0071】

特定の要因に関して特定の方法で投票する場合、可能な結果の自身のセットを知っている各パーティは、コミットメントトランザクションを調べて、エスクロースクリプト内のO_x値に関連するオプションが正しい公開鍵S_xと対にされていることを保証する。その結果、両方の公開鍵は、アクセスされるべきエスクロー資金またはトークンに順に署名する必要がある。基本的に、パーティは、コミットメントトランザクションのエスクローアウトプット内で意思決定プロセスの可能な結果O_xのうちの１つが（管理者との先の合意に従い）正しいS_xに結びつけられている場合、自身の投票を提供しないことを選択してよい。

【0072】

＜実施形態１：トランザクション及び選択文書化＞
MFMPプロトコルは、４個のコアトランザクション、つまりコミットメントトランザクションT_C、支払いトランザクションT_P、返金トランザクションT_R、及び投票トランザクションT_V、に基づき構築される。図４に、これら４個のトランザクションの境界が示される。

【0073】

図４では、各トランザクションは、丸角を有する長方形により表される。トランザクションのインプット及びアウトプットは、基本長方形により示される。インプットはトランザクションの左半分に示され、一方、アウトプットはトランザクションの右半分に示される。インプット及びアウトプットの長方形のラベルは、それぞれ「コインのソース（source of coins）」及び「意図された受信者」の公開鍵のものである。例えば、S_aは、投票トランザクションのための資金源であると同時に、コミットメントトランザクションの資金の受信者である。本例では、人物の公開鍵は、人物自身のラベルとして使用されてよい。Escアウトプット／インプットは、アウトプット－インプットが１つの特定のアドレス／公開鍵に向けられないが、明言された基準を満たす能力に基づき異なる鍵によりアクセス可能であるという例外である。

【0074】

＜コミットメントトランザクション＞
コミットメントトランザクションT_C（図４及び５を参照）は、MFMPプロトコルの主要トランザクションであり、そのインプットとして、全ての投票パーティの選択を表す１つの結果に資金提供するためのコインFuを含む。これらの資金は、管理者Sと題されたエンティティ／個人からであると想定される。一例として、この管理者は、会社の財務に責任のある、会社のCEO又は会計係／出納官であり得る。S_aとラベル付けされたアドレスから、管理者がこれらの資金を提供する。

【0075】

コミットメントトランザクションは、少なくとも２つのアウトプットを有することが期待される。これらのうちの１つ目は、管理者に属する第２アドレスへ転送される僅かな料金のものである。このアウトプットアドレスは、コミットメントトランザクションをブロックチェーンに格納された情報を利用する投票トランザクションにリンクするための、保管人（stakeholders）にとっての容易な手段として利用される。これらの資金のアドレスは、管理者により所有される第２アドレスS_bである。

【0076】

コミットメントトランザクションの第２アウトプットは、ある量のコインを預託（エスクロー、escrow）するものである。ここで、決定木の「勝者の」結果は、これらのエスクローされたコインを受信する（又はそれらから資金供給される）。資金が特定のアウトプットアドレス／公開鍵に対して直接排他的ではないが、これらの資金を可能なアドレスのセットのうちの１つへ移転させるこのアウトプットのBitcoinスクリプトに付加された条件を有するとき、このアウトプットは、「エスクロー」されていると記載される。ここで、コインが許可される最終的なアドレスは、スクリプトで規定された基準が満たされることに依存する。

【0077】

このスクリプトは、参加パーティの必要なk_a,i値が利用可能である場合、条件セットがエスクローされたコインへのアクセスを与えるだけのものである。より具体的には、エスクロー資金のアウトプットアドレスの選択のためのスクリプト内の基準は、署名が公開鍵O_x及びS_xについて生成されることである。ここで、
O_x=sν_xG
sν_x=k_A,i+k_B,j+…k_n,k
S_xは結果O_xと対にされたユニークなアウトプットアドレスである。

【0078】

＜投票トランザクション＞
投票トランザクションT_V（図４及び６を参照）は、パーティの署名した決定要因に関して該パーティの行った選択を記録することを担う。

【0079】

この投票トランザクションは、コミットメントトランザクションのS_bアウトプットを投票トランザクションのインプットとして用いることにより、コミットメントトランザクションに「リンクされる」。ここで、S_bは管理者により制御される第２アドレスである。このリンクは３つの目的を提供する。

【0080】

・T_C及びT_Vをリンクする。両方の（投票及びコミットメント）トランザクションの間で共有されるアドレスは、保管人がブロックチェーン内で前述の２つのトランザクションのうちの一方を発見した場合に、保管人が他方のトランザクションを容易に読み出すことを可能にする。コミットメントトランザクションは投票トランザクションより前にブロックチェーン上に置かれることに留意する。したがって、コミットメントトランザクションは、投票トランザクションが共に存在することなく、ブロックチェーン上に存在してよいが、逆はない。
・関連付けを記録する。このリンクは、コミットメントトランザクション及びそのエスクロー資金とパーティにより投じられた投票との間の文書化された関連付けを提供する。
・管理者の認可。（投票トランザクションの）インプットS_bに署名する管理者がパーティの投票の管理者の受諾の正式な表現として機能するとき、投票トランザクション内のインプットとして含まれる管理者のアドレスは、管理者に、投じられている投票に対する管理の要素を与える。

【0081】

投票トランザクション自体は、管理者により構成され、次にパーティに渡されることが期待され、その結果、各パーティは、彼らの投票をトランザクションに追加してよい。投票はk_a,i値である。m－of－nマルチ署名スクリプト内の公開鍵のために予約されたフィールドは、投票トランザクション内の投票を格納するために使用される。このスクリプトは、投票トランザクションのアウトプットスクリプト<scriptPubKey>として使用される。Bitcoinでは、<scriptPubKey>はトランザクションアウトプットを利用させるルールセットであることが、当業者に知られている。<scriptSig>は、<scriptPubKey>を満たすことを要求されるコンテンツである。

【0082】

k_a,i値を含むm－of－nスクリプトを含む投票トランザクションの現在バージョンは、ここで、管理者へ返される。パーティにより提供されるnk_a,i値のセットを所有する管理者は、(k_A,i+k_B,j+…k_n,k)Gが計算された階層構造からのO_x個の結果のうちの１つに等しいかどうかを決定することにより、投票を検証し得る。

【0083】

投票の結合が検証される場合、管理者は、投票トランザクションのアウトプットスクリプト<scriptPubKey>のm－of－nマルチ署名スクリプトに、公開鍵S_aを追加する。これは管理者の主要公開鍵（「アドレス」）であり、管理者は、投票トランザクションのアウトプットでコインのうちの幾らかを使用したいと望む、任意のトランザクションの<scriptSig>のS_aに対する署名を生成することを期待される。

【0084】

このアウトプットを使用するトランザクションのインプットスクリプトと結合される投票トランザクションのアウトプットスクリプトの一例は、以下に示される。
OP_０ Sig S_aOP_１k_A,Ik_B,jk_C,kPubS_aOP_４OP_CHECKMULTSIG
<scriptPubKey>のこの１－of－４マルチ署名は、要因A、B、Ｃに責任のあるパーティにより投じられた３つの投票を含み、公開鍵S_aも含む。

【0085】

投票トランザクションの現在バージョンは、次に、各パーティへ再送信される。各パーティは、彼／彼女の投票がアウトプットスクリプトの最終バージョンに含まれていることを確認し、トランザクションへの彼／彼女のインプットに署名して、投票トランザクションの彼らの認可を表す。つまり、彼らは、彼らの投票が投票トランザクションに含まれていることを承認する。管理者は、投票トランザクションへの彼のインプットに署名し、次に、投票トランザクションはブロックチェーンへと提出される。

【0086】

代替として、各パーティは、セキュアな方法で彼らの投票を管理者に通信してよい。管理者は、次に、全ての投票を投票トランザクションのアウトプットスクリプトに追加し、次に、このトランザクションを種々のパーティのそれぞれのインプット署名のために、該種々のパーティへ送信する。

【0087】

以下に留意すべきである。
・各パーティが投票トランザクションへの彼らのインプットのために利用する／貢献する資金／コインは、最小限、又は僅かな料金である。投票トランザクションは、資金の移転と言うよりは、投票の不変の記録という意味が大きい。
・Bitcoinプロトコルの現在バージョンでは、マルチ署名アウトプットにおいて許容可能な公開鍵の最大数は１５である。この理由から、説明したm－of－nマルチ署名スクリプトが許容し得る最大投票（投票者）数は１４である（１５個の空間のうちの１つが管理者の公開鍵S_aのために予約されることに留意する）。複数の冗長なm－of－nマルチ署名（サブ）スクリプトを含む、より手の込んだスクリプトは、より多くの投票を組み込むよう構成されてよいが、スクリプトの最大サイズは１０キロバイト[７]であり、トランザクションコストはトランザクションのサイズに依存することに留意する。
・適用可能な場合には、管理者もは決定に関連する要因に基づき投票を行ってよい。

【0088】

＜支払いトランザクション＞
支払いトランザクションT_P（図４及び７を参照）は、コミットメントトランザクション（図４及び５を参照）のEscアウトプットでエスクローされたコインへのアクセスに成功し得るトランザクションである。このトランザクションは、そのインプットスクリプト<scriptSig>内に２つの署名を含む。１つ目は公開鍵O_xに対する署名であり、
(k_A,i+k_B,j+…k_n,k)G=O_x
各k_a,iは異なる決定関連要因のためのものである。

【0089】

スクリプト内に存在するk_a,i値のユニークな結合は、誰（公開－秘密鍵対の所有者）がEscコインにアクセスできるかの決定要素である。これらのk_a,i値は、ブロックチェーン上で利用可能な投票トランザクションから読み出されてよい。

【0090】

支払いトランザクションのインプットスクリプト内の２つ目の署名は、O_xを管理する責任を割り当てられた個人の公開鍵である公開鍵S_xのためのものである。これは、必ずしも、プロトコルの主要な管理者（S_a及びS_bの所有者）ではないが、任意の別の認可された個人であり得る。さらに、適切な場合には、特にセキュリティ／制御目的で、第３の署名が、支払いトランザクションのインプットスクリプトのために要求されてよい。ここで、第３の署名は、主要な管理者のものである。

【0091】

支払いトランザクションのインプットが成功裏に署名された場合、コミットメントトランザクションのエスクローされたコインは、結果O_xに関連する受信者アドレスR_xへ移動できる。支払いトランザクションは、投票トランザクションの後に、ブロックチェーンに提出される。

【0092】

＜返金トランザクション＞
返金トランザクション（図４及び８）は、エスクロー資金を、コミットメントトランザクションに資金貢献した全てのパーティ（管理者又はその他）に返すトランザクションである。これは、プロトコルの参加者が然るべく行動しなかった場合のフェールセーフ手段として見える。重要なことに、この返金トランザクションは、特定時点（Unix時間又はブロック高）が経過した後まで、ブロックチェーンにより受け入れられることを防ぐnTimeLock値を含む。

【0093】

返金トランザクションのインプットスクリプトは、コミットメントトランザクションのエスクローされたアウトプットスクリプト内で利用可能なオプションのうちの１つを満たし得るデータを含む。このデータは、（エスクロー資金をコミットした）主要な管理者及び他の保管人の署名であってよい。全ての他の保管人は、コミットメントトランザクションが管理者によりブロックチェーンに提出される前に、返金トランザクションに署名しなければならない。これは、失敗した場合に、管理者が全てのコミットしたエスクロー資金を回収できることを保証する。

【0094】

返金トランザクションは、任意的なトランザクションであり、MFMPプロトコルインスタンスの支払いトランザクションが提出されなかった場合に、ブロックチェーンに提出できるだけである。さらに、返金トランザクションは、特定時点の後にのみ、提出できる。このことに留意すると、返金トランザクションのnTimeLock値は、コミットメントトランザクションが時間Tに提出された後に、以下のための十分な時間が与えられるように、選択されなければならない：
・投票が得られること
・投票トランザクションがブロックチェーンにコミットされること
・投票トランザクションがブロックチェーンの中で発見されること
・支払いトランザクションが生成され、ブロックチェーンに提出されること。

【0095】

全てを達成するために指定された時間（範囲）は、sとラベル付けされる。返金トランザクションのnTimeLock値は、少なくとも以下であってよい：
nTimeLock=T+s
時間nTimeLock値は、秒又はブロック高で定義できることに留意する。

【0096】

＜エスクロー関連スクリプト＞
＜アウトプットスクリプト：コミットメントトランザクションエスクロー＞
コミットメントトランザクションのエスクロー資金は、可能な方法のセットについて、エスクロー資金がアクセスされ／請求され／使用されることを可能にするスタックに基づくスクリプト言語により「保護」されることが期待される。エスクロー資金にアクセスするこれらの方法の各々は、資金が回収されるために満たされなければならない関連する基準セットを有する。エスクロースクリプトは、基本的に、場合分け文の中の各オプションがエスクロー資金にアクセスする異なる方法である、場合分け文のセットを表すように見える。t個のオプションがあると仮定すると、これらのオプションのうちのtー１個について（１つの基準は返金署名に関連付けられる）、各場合の基準は（少なくとも）以下である：
ECDSA署名は、(k_A,i+k_B,j+…k_n,k)G=O_xの公開鍵アドレスのために生成されるべきである、
且つ
ECDSA署名は、O_xの管理役の誰かの公開鍵S_xのために生成されるべきである。

【0097】

図９は、（８個の点を特徴とする）エスクロー場合分け文を表すBitcoinアウトプットスクリプトの高レベルバージョンを示す。(cond_i)は満たされる必要のある基準／条件を表し、[Do_i]は、(cond_i)が真と評価された場合に実行されるべき動作を表す。

【0098】

より具体的にいうと、これはアウトプットスクリプトに関連するので、２つのECSDA署名の必要性を表すために使用されてよい条件(cond_i)が、以下のような２－of－２マルチ署名（サブ）スクリプトのものである：
OP_２ PubO_x PubS_x OP_２ OP_CHECKMULTSIG
．．．
ここで、PubO_x=(k_A,i+k_B,j+…k_n,k)G及びPub S_xは、結果O_xに割り当てられたエンティティの公開鍵である。

【0099】

スクリプトの各[Do_i]要素が実行するよう依頼される動作は、(cond_i)が真と評価されるとすると、スタックの一番上に値１/TRUEを預ける（deposit）ことである。Bitcoinスクリプトはスタックに基づく言語であること、及びスクリプト実行の完了後にスタックの一番上にある「真（TRUE）」の値はスクリプトが成功裏に実行されたことを意味することが、当業者に理解される。

【0100】

＜インプットスクリプト：支払いトランザクション＞
コミットメントトランザクションのエスクローされたアウトプットのコインに成功裏にアクセスするために、これは、エスクローされたアウトプットのアウトプットスクリプト<scriptPubKey>が支払いトランザクションのインプットスクリプト<scriptSig>と結合されるとき、結合されたスクリプトが成功裏に実行すること、つまりスタックの一番上に１/TRUEを生成することを要求する。

【0101】

少なくとも１つのデータ要素<data_i>がインプットスクリプトに含まれなければならない。該インプットスクリプトは、アウトプットスクリプトのif文のうちの少なくとも１つが真であることをもたらし、最終的には、結合されたインプット及びアウトプットスクリプトを真と評価することをもたらす。

【0102】

留意すべきことに、<data_i>はデータの複数のフィールドを表してよい。一例として、<data_i>は、２－of－２マルチ署名スクリプトの３つの値、つまり<op_０><sigO_x><sigS_c>の結合であってよい。

【0103】

また留意すべきことに、オプションが考慮されることに依存して、適切な場合には、一部の冗長データ<bd_datai>も、インプットスクリプトに含まれてよい。<bd_dti>、「bad data」は、(cond_i)により処理されるとき、アウトプットとして０/FALSEを生成することを保証するデータを表すことを意味する。<data_i>と同様に、<bd_dti>は服すの個々のデータ要素から構成されてよい。実際に、<bd_dti>は、<data_i>のような同じ数のデータ要素で構成されることが期待される。

【0104】

＜MFMPフローチャート＞
図１０は、複数要因複数パーティ（Multi－factor multi－party）の投票プロトコルの一般的概要を示す。

【0105】

図１１～１３に、本発明の更なる実施形態の構成を示す。

【0106】

＜実施形態２：トランザクション及び選択文書化＞
本実施形態は、第１の実施形態の複数要因複数パーティと以下の点で異なる：第１の実施形態はパーティの投票を、投票トランザクションのm－of－nマルチ署名アウトプットスクリプトに含まれる投票の結合されたセットとして記録したが、本実施形態は、投票パーティに、投票トランザクションのインプットスクリプトの引数として彼らの投票を含めることにより、彼らの投票を開示するよう依頼する。こうすることにより、これは、パーティを彼らの投票により直接的に接続し、及びパーティが他のパーティの投票の知識と独立にトランザクションに署名できるようにするという利点を提供する。

【0107】

第１の実施形態では、種々のパーティの投票は、投票トランザクションのm－of－nマルチ署名スクリプトに格納された。彼らの投票が投票トランザクション内に提示される及び／又は文書化されることの確認を示すために、各パーティ（例えば、図１１のパーティA、B、C）は、投票トランザクションの彼らの対応するインプットに署名する。この署名はこのような確認として見えるが、どの投票がどの参加者に属するかは、ブロックチェーン内に文書化されない。この情報は、幾つかのシナリオにおいて有用であり得る。同時に、全てのパーティが彼らの投票をm－of－nマルチ署名アウトプットスクリプトに与えるまで、パーティは投票トランザクションに署名できない。

【0108】

第２の実施形態は、第１の実施形態の複数要因複数パーティ意思決定プロトコルの変形を導入する。該変形は、パーティの記憶装置に対して記述された制限、及び該プロトコルの投票トランザクション内の投票の確認を解決する。投票トランザクションのインプットとして使用される資金にアクセスするために、パーティが彼らの投票を開示することを、該パーティに強制することにより、これを行う。

【0109】

これを達成するために、Bitcoinスクリプトの中に、楕円曲線（Elliptic Curve：EC）「スカラによる点乗算」を可能にするオペコードが存在するとする。これは、また、Bitcoinスクリプトの２００オペコード制限が除去されること、及び無効にされたオペコードが再有効化されることを要求する。楕円曲線（EC）暗号法における秘密－公開鍵関係の準同型性特性を含む本実施形態で利用される技術は、提案されるオペコードと共に、以上に詳細に説明された。

【0110】

本実施形態の提案されるオペコードは、投票が格納される（投票）トランザクションの要素、その後、投票が提示されたことの確認として、「いつ、どのように」署名を開始できるかについて、第１の実施形態のMFMPプロトコルと異なる。

【0111】

＜コミットメントトランザクション＞
第１の実施形態による場合におけるように、第２の実施形態は、４個のコアトランザクション、つまりコミットメントトランザクションT_C、支払いトランザクションT_P、返金トランザクションT_R、及び投票トランザクションT_V、に基づき構築される。図１１に、これら４個のトランザクションの境界が示される。

【0112】

＜コミットメントトランザクション＞
本実施形態のコミットメントトランザクションは、図１１及び１２に示されるように、本実施形態のコミットメントトランザクションが少なくとも４個のアウトプットを有することを期待される点が、第１の実施形態のものと異なる。第１アウトプットは、管理者に属する第２アドレスS_bへ移転される僅かな料金のものである。このアウトプットアドレスは、コミットメントトランザクションをブロックチェーンに格納された情報を利用する投票トランザクションにリンクするための、保管人（stakeholders）にとっての容易な手段として利用される。更に重要なことに、これらのアウトプットは投票トランザクションへのインプットであり、署名を必要とするインプットであるので、これは、管理者に投票トランザクションに対する権限を与える方法として機能する。

【0113】

コミットメントトランザクションの第２アウトプットは、第１の実施形態の場合におけるように、ある量のコインを預託（エスクロー、escrow）するものである。ここで、決定木の「勝者の」結果は、これらのエスクローされたコインを受信する（又はそれらから資金供給される）。

【0114】

第２の実施形態は、他のアウトプット（これらのうち、少なくとも２が存在する）が投票パーティ、例えば図１１及び１２のパーティA、B、及びCに属する公共アドレスへのものであるという点で第１の実施形態と更に異なる。これらのアウトプットは、資金にアクセスするために、パーティが彼らそれぞれの投票（及び公開鍵Aに対する署名）を生成するよう要求されるよう設計されるべきである。一例として、パーティAがコミットメントトランザクションのAアウトプットを使用しようとした場合、彼／彼女は、投票トランザクションのインプットスクリプトに公開鍵Q_A,i=k_A,iGを含むこと、したがって、ブロックチェーン上で彼らの投票k_A,iを公開することが必要である。

【0115】

パーティが彼らに割り当てられた要因に関連する幾つかの方法で投票してよいならば、投票パーティ（例えばパーティA）のコミットメントトランザクションのアウトプットスクリプト<scriptPubKey>は資金にアクセスするための幾つかのオプションを含まなければならず、該オプションの各々は、投票パーティのためのオプションのうちの１つに基づく。図９を参照して説明した、複数オプションの（ifーelseでネストされた）高レベルスクリプトの構造を用いて、オプションからの資金の支払いを可能にする条件(cond_i)のBitcoinスクリプトは、以下の通りである：
<Basepoint G> OP_ECPMULT <Q_A,i> OP_EQUALVERIFY <pubA> OP_CHECKSIG
このスクリプトは、「楕円曲線有限体演算及びオペコード」の章で上述した提案したオペコードOP_ECPMULTを利用することが分かる。

【0116】

(cond_i)が満たされるために、投票パーティAは要素<data i>を含める必要がある。
<<Sig A> <k_A,i>>
ここで、sig Aは公開鍵Aの署名であり、k_A,iはパーティAの投票である。

【0117】

留意すべきことに、パーティAの投票は、アクセスするパーティAの、コミットメントトランザクションのアウトプットの処理の一部として<data i>の中で開示される。

【0118】

＜投票トランザクション＞
第２の実施形態の投票トランザクション（図１１を参照）は、コミットメントトランザクションのS_bアウトプット及び投票パーティのアウトプットを通じて、コミットメントトランザクションに「リンクされる」。コミットメントトランザクションのこれらのアウトプットは、投票トランザクションのインプットである。

【0119】

投票トランザクション自体は、管理者により構成され、次にパーティに渡されることが期待され、その結果、各パーティは、それぞれのインプットに署名してよい。自身の投票トランザクションへのインプットに署名するパーティは、該パーティの投票k_a,iが開示されることを、（上述のコミットメントトランザクションから）思い出すべきである。

【0120】

管理者は、投票トランザクションへの彼のインプットに署名し、次に、投票トランザクションはブロックチェーンへと提出される。

【0121】

留意すべきことに、各パーティが投票トランザクションへの彼らのインプットのために利用する／貢献するコインは、最小限、又は僅かな料金である。投票トランザクションは、資金の移転と言うよりは、投票の不変の記録という意味が大きい。

【0122】

図１３は、複数要因複数パーティの投票プロトコルの一般的概要を示す。

【0123】

図１４を参照すると、本開示の少なくとも一実施形態を実施するために使用され得るコンピューティング装置２６００の説明のための簡略ブロック図が提供される。種々の実施形態で、コンピューティング装置２６００は、上述の図示のシステムのうちのいずれかを実装するために使用されてよい。例えば、コンピューティング装置２６００は、データサーバ、ウェブサーバ、ポータブルコンピューティング装置、パーソナルコンピュータ、又は任意の電子コンピューティング装置として使用するために構成されてよい。図１４に示すように、コンピューティング装置２６００は、主メモリ２６０８及び永久記憶装置２６１０を含む記憶サブシステム２６０６と通信するよう構成され得る１つ以上のレベルのキャッシュメモリ及びメモリ制御部（集合的に２６０２とラベル付けされる）を備える１つ以上のプロセッサを含んでよい。主メモリ２６０８は、図示のように、動的ランダムアクセスメモリ（ＤＲＡＭ）２６１８及び読み出し専用メモリ（ＲＯＭ）２６２０を含み得る。記憶サブシステム２６０６及びキャッシュメモリ２６０２は、本開示で説明されたようなトランザクション及びブロックに関連付けられた詳細事項のような情報の記憶のために使用されてよい。プロセッサ２６０２は、本開示で説明されたような任意の実施形態のステップ又は機能を提供するために利用されてよい。

【0124】

プロセッサ２６０２は、１つ以上のユーザインタフェース入力装置２６１２、１つ以上のユーザインタフェース出力装置２６１４、及びネットワークインタフェースサブシステム２６１６とも通信できる。

【0125】

バスサブシステム２６０４は、コンピューティング装置２６００の種々のコンポーネント及びサブシステムが意図した通りに互いに通信できるようにするメカニズムを提供してよい。バスサブシステム２６０４は、単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は、複数のバスを利用してよい。

【0126】

ネットワークインタフェースサブシステム２６１６は、他のコンピューティング装置及びネットワークへのインタフェースを提供してよい。ネットワークインタフェースサブシステム２６１６は、幾つかの実施形態では、コンピューティング装置２６００の他のシステムからデータを受信し及びそれへデータを送信するインタフェースとして機能してよい。例えば、ネットワークインタフェースサブシステム２６１６は、データ技術者が、装置をネットワークに接続することを可能にする。その結果、データ技術者は、データセンタのような遠隔地にいがなら、データを装置へ送信し、データを装置から受信できる。

【0127】

ユーザインタフェース入力装置２６１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのような指示装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含んでよい。通常、用語「入力装置」の使用は、コンピューティング装置２６００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。

【0128】

１つ以上のユーザインタフェース出力装置２６１４は、ディスプレイサブシステム、プリンタ、又は音声出力装置のような非視覚的ディスプレイ、等を含んでよい。ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面装置、又は他のディスプレイ装置を含んでよい。通常、用語「出力装置」の使用は、コンピューティング装置２６００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置２６１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用されてよい。

【0129】

記憶サブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構造を記憶するコンピュータ可読記憶媒体を提供してよい。アプリケーション（例えば、プログラム、コードモジュール、命令）は、１つ以上のプロセッサにより実行されると、本開示の１つ以上の実施形態の機能を提供し、記憶サブシステム２６０６に格納されてよい。これらのアプリケーションモジュール又は命令は、１つ以上のプロセッサ２６０２により実行されてよい。記憶サブシステム２６０６は、更に、本開示に従い使用されるデータを格納するレポジトリを提供する。例えば、主メモリ２６０８及びキャッシュメモリ２６０２は、プログラム及びデータのための揮発性記憶を提供できる。永久記憶装置２６１０は、プログラム及びデータの永久（不揮発性）記憶を提供でき、磁気ハードディスクドライブ、取り外し可能媒体に関連付けられた１つ以上のフロッピディスクドライブ、取り外し可能媒体に関連付けられた１つ以上の光ドライブ（例えば、ＣＤ－ＲＯＭ、又はＤＶＤ、又はＢｌｕｅ－Ｒａｙ）ドライブ、及び他の同様の記憶媒体を含んでよい。このようなプログラム及びデータは、本開示に記載した１つ以上の実施形態のステップを実行するためのプログラム、及び本開示に記載したトランザクション及びブロックに関連付けられたデータを含み得る。

【0130】

コンピューティング装置２６００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのものであってよい。さらに、コンピューティング装置２６００は、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置２６００に接続可能な別の装置を含み得る。コンピューティング装置２６００に接続され得る装置は、光ファイバコネクタを受けるよう構成される複数のポートを含んでよい。したがって、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置２６００に送信される電気信号に変換するよう構成されてよい。コンピュータ及びネットワークの絶えず変化する特性により、図１４に示したコンピューティング装置２６００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図１４に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。

【0131】

上述の実施形態は、本発明を限定するのではなく、説明すること、及び当業者は添付の特許請求の範囲により定められる本発明の範囲から逸脱することなく多くの代替的実施形態を考案できることに留意すべきである。特許請求の範囲において、括弧内の任意の参照符号は、請求項を限定することを意図しない。用語「有する」及び「含む」（comprising、comprises）等は、任意の請求項又は明細書全体に列挙されたもの以外の要素またはステップの存在を排除しない。本願明細書では、「有する」は「有する又は構成される」を意味し、「含む」は「含む又は構成される」を意味する。要素の単数の参照は、該要素の複数の参照を排除しない。逆も同様である。本発明は、幾つかの別個の要素を含むハードウェアにより、及び適切にプログラムされたコンピュータにより、実装できる。幾つかの手段を列挙する装置クレームでは、これらの手段のうちの幾つかは、１つの同じハードウェアアイテムにより具現化されてよい。単に特定の手段が相互に異なる従属請求項に記載されるという事実は、これらの手段の組み合わせが有利に使用されないことを示さない。

【0132】

参考文献
表１

【表1】

【符号の説明】

【0133】

T_C コミットメントトランザクション
T_P 支払いトランザクション
T_R 返金トランザクション
T_V 投票トランザクション

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【外国語明細書】