JP2023504067A - ブロックチェーンを用いたプロバブリー・フェアー・ゲーム - Google Patents

Abstract

コンピュータにより実行される方法は、ゲームをプレイする際に使用するウィニング・ゲーム要素を擬似ランダムに選択する。オラクルは、シード・データ・アイテムのセットと、第1公開鍵のシーケンスとを取得し、シード・データ・アイテムのセットは1つ以上のユーザー・シード・データ・アイテムを含み、各々の第1公開鍵は第1ゲーム要素のセットのうちのそれぞれを表現している。オラクルは、アウトプット・スクリプトを含むゲーム・トランザクションのアウトプットを生成する。スクリプトは、少なくとも幾つかの第1公開鍵のシーケンスを含み、アウトプット・スクリプトは、実行されると、少なくとも1つの擬似乱数を生成し、ウィニング・キーを選択するように構成されており、擬似乱数はシード・データ・アイテムのセットに基づいており、ウィニング公開鍵は、擬似乱数に対応する第1公開鍵のシーケンス内の或る位置にある公開鍵である。［図5］

Description

[0001] 本開示は、ブロックチェーンを用いてプロバブリー・フェアー・ゲーム（provably fair games）をプレイできるようにするためにゲーム要素をランダムに生成する方法に関連する。

[0002] ブロックチェーンは分散されたデータ構造の形態を指しており、ピア・ツー・ピア（P2P）ネットワーク内の複数のノードの各々において、ブロックチェーンの重複コピーが維持される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、1つ以上のトランザクションを含む。各トランザクションは、1つ以上のブロックにわたるシーケンス内で先行するトランザクションを後方から指し示すことができる。トランザクションは、“マイニング”として知られるプロセスによって生成される新しいブロックに含まれるように、ネットワークに対してサブミットされることが可能であり、これは、“プルーフ・オブ・ワーク（proof-of-work）”を実行する、即ちブロックに含まれることを待機しているペンディング・トランザクションのプールに基づいて暗号パズルを解決する、競合する複数のマイニング・ノードの各々に関わる。

[0003] 従来、ブロックチェーン内のトランザクションは、デジタル資産、即ち、価値のストア（a store of value）として機能するデータ、を伝達するために使用されている。しかしながら、ブロックチェーンはまた、そのブロックチェーンの上に追加の機能を階層化するために使用することも可能である。例えば、ブロックチェーン・プロトコルは、トランザクションのアウトプットに追加ユーザー・データを格納することを許容する可能性がある。現代のブロックチェーンは、単一トランザクション内に格納することが可能な最大データ容量を増加させ、より複雑なデータが組み込まれることを可能にしている。例えば、それはブロックチェーン内に電子文書を、あるいはオーディオ又はビデオ・データさえ、格納するために使用される可能性がある。

[0004] ネットワーク内の各ノードは、フォワーディング、マイニング、及びストレージというの3つの役割のうちの何れか1つ、2つ、又は全ての役割を有する可能性がある。フォワーディング・ノードは、ネットワークのノード全体にトランザクションを伝搬させる。マイニング・ノードは、トランザクションのブロックへのマイニングを実行する。ストレージ・ノードはそれぞれ、ブロックチェーンのマイニングされたブロックのそれら自身のコピーを格納する。トランザクションをブロックチェーンに記録させるために、当事者は、トランザクションを、伝搬されるべきネットワークのノードのうちの1つに送信する。トランザクションを受信するマイニング・ノードは、新しいブロックに向かってトランザクションをマイニングするために競うことが可能である。各ノードは、同じノード・プロトコルを順守するように構成され、そのプロトコルは、有効化されることになるトランザクションに対する1つ以上の条件を含むであろう。無効なトランザクションは、伝搬されないか、又はブロックに向かってマイニングされないであろう。トランザクションが検証され、それによってブロックチェーンに受け入れられたと仮定すると、追加ユーザー・データは、その後、P2Pネットワークの各ノードで、変更できない公の記録として格納されたまま残る。

[0005] 運が左右するゲーム（game of chance）は、ゲームの結果が何らかのランダム化する装置によって強く影響されるゲームであり、参加者は、金銭や金銭的価値のあるものを賭けることを選ぶことができる。ゲームの結果に影響を及ぼすために使用される一般的な装置は、ダイス、トランプ、ルーレット・ホイール、入れ物から取り出された番号付きボールなどを含む。これらのゲームがオンラインでプレイされることは一般的であり、即ち、そのゲームの参加者の少なくとも一部は、物理的に同じ場所にはいない。例えば、参加者は、インターネット上でゲームをプレイすることができる。オンラインでゲームをホスティングするための専用サイトは、しばしばオンライン・カジノ（online casinos）と呼ばれる。

[0006] オンライン・カジノ(又は一般的には、オンライン・ゲーム)に伴う問題は、ランダム化装置の透明性(従って、信頼性)の欠如である。言い換えれば、結果が少なくともある程度のランダム性に依存するゲームでは、参加者は、通常、どの程度のランダム性が生じているか知ることはできない。従って、参加者は、ゲームが公正に行われているかどうかを知ることができない。これは、参加者がゲームの結果に賭けている（wagering）(即ち、ベットしている（betting）)場合に特に問題である。例として、参加者がオンライン・カジノでルーレットをプレイしている場合、参加者は、カジノが、ウィニング・ポジション（即ち、番号）を公正に生成していることを信頼しなければならない。

[0007] 従って、ゲームの結果のランダムな生成を証明するための技術を提供することが望ましい。この場合、ランダムな生成は、擬似乱数プロセス（統計的にランダムな結果を与える決定論的なプロセス）になるであろう。

[0008] 本件で開示される一態様によれば、ゲームをプレイする際に使用するウィニング・ゲーム要素（winning game element）を擬似ランダムに生成するコンピュータが実行する方法が提供され、前記ゲームは、前記ゲームの結果を決定するために使用される第1ゲーム要素のセットを含み、前記ゲームは現在のユーザーによってプレイされ、前記方法はオラクルにより実行され、前記方法は：シード・データ・アイテムのセットを取得するステップであって、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含む、ステップ；第1公開鍵のシーケンスを取得するステップであって、各々の第1公開鍵は前記第1ゲーム要素のセットのうちのそれぞれを表現している、ステップ；及びゲーム・トランザクションの第1アウトプットを生成するステップを含み、前記第1アウトプットは少なくとも幾つかの第1公開鍵のシーケンスを含むアウトプット・スクリプトを含み、前記アウトプット・スクリプトは、実行されると、少なくとも1つの第1擬似乱数を生成し、少なくとも1つの第1ウィニング・キーを選択するように構成されており、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、少なくとも1つの第1ウィニング公開鍵は、前記少なくとも1つの第1擬似乱数に対応する前記第1公開鍵のシーケンス内の或る位置にある公開鍵である。

[0009] ここで、ゲーム要素は、ゲームの結果を決定するために使用される、ゲームの任意の構成要素を指すために使用される。例えば、ゲームが結果を決定するためにトランプを使用することを含む場合、トランプはゲーム要素（又は、ゲーム要素のセットのうちの少なくとも一部）である。ゲームがダイ（1つのサイコロ）又はダイス（複数のサイコロ）を含む場合、ダイ又はダイス上の面（即ち、数字）はゲーム要素(又は、それらの少なくとも一部)である。ゲームがルーレットである場合、ゲーム要素はルーレット・ホイール上の数字であってもよい。

[0010] オラクル（即ち、ゲームにランダム性を導入する責務を有する者）は、ユーザー・シード・データ・アイテムを、現在のユーザー（現在のゲーム・プレーヤ）から取得し、ユーザー・シード・データ・アイテムは、擬似乱数を生成するために使用され、次いでゲームの結果を決定するために使用される。現在のユーザーは彼ら自身のシードを提供するので、彼／彼女は、擬似乱数が公正に生成されていること、及び擬似乱数に基づいて選択されたウィニング・ゲーム要素が公正に決定されていることを確信することができる。ここで、ユーザーが擬似乱数の生成に貢献するだけでは不十分である。むしろ、擬似乱数が何らかの合意されたルールに従って生成されていることをユーザーがチェックできるように、擬似乱数の生成が証明されなければならない。従って、オラクルはゲーム・トランザクションを生成し、そのゲーム・トランザクションは、擬似乱数を生成するためのスクリプトであって、全ての可能なゲーム要素（公開鍵を用いるスクリプトで表現される）のリストから、ウィニング公開鍵を選択するためのスクリプトを含む。オラクルは、ゲーム・トランザクションをブロックチェーン及び/又は現在のユーザーに公開することが可能であり、その結果、ユーザーはウィニング公開鍵、従ってウィニング・ゲーム要素がどのように選択されているかを知ることができる。

[0011] 本開示の実施形態の理解を促し、そのような実施形態がどのように実施され得るかを示すために、具体例であるに過ぎない添付の図面が参照される。
図1は、ブロックチェーンを実装するためのシステムの概略ブロック図である。 図2は、ブロックチェーンに記録され得るトランザクションの幾つかの例を模式的に示す。 図3は、ブロックチェーンを実装するための別のシステムの概略ブロック図である。 図4は、アウトプット・ベース・モデルのノード・プロトコルに従ったトランザクションを処理するためのノード・ソフトウェアの概略ブロック図である。 図5は、ブロックチェーンを用いてプロバブリー・フェアー・ゲームを実現するためのシステムの概略ブロック図である。 図6は、乱数R_Nを生成するためのスクリプト<R_N>の実行フロー例を示す。 図7は、ウィニング公開鍵を選択するためのスクリプト<P_k=0>の実行フロー例を示す。

[0012] 例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を概略的に示す。システム100は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク101を含む。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピア・ツー・ピア（P2P）オーバーレイ・ネットワーク106を形成するように構成される複数のノード104を含む。各ノード104はピアのコンピュータ装備を含み、ノード104のうちの異なるものは異なるピアに属する。各ノード104は、1つ以上のプロセッサ、例えば、1つ以上の中央処理ユニット（CPU）、アクセラレータ・プロセッサ、特定用途向けプロセッサ、及び／又はフィールド・プログラマブル・ゲート・アレイ（FPGA）を含む処理装置を含む。各ノードはまた、メモリ、即ち、非一時的なコンピュータ読み取り可能な媒体又はメディアの形態におけるコンピュータ読み取り可能なストレージを備える。メモリは、1つ以上のメモリ媒体、例えば、ハード・ディスクのような磁気媒体；ソリッド・ステート・ドライブ（SSD）、フラッシュ・メモリ又はEEPROMのような電子媒体；及び／又は光ディスク・ドライブのような光媒体；を使用する1つ以上のメモリ・ユニットを含んでもよい。

[0013] ブロックチェーン150は、データ151のブロックのチェーンを含み、ブロックチェーン150のそれぞれのコピーは、P2Pネットワーク160内の複数のノードのそれぞれにおいて維持される。チェーン内の各ブロック151は、1つ以上のトランザクション152を含み、ここで、この文脈におけるトランザクションは一種のデータ構造を参照する。データ構造の性質は、トランザクション・モデル又はスキームの一部として使用されるトランザクション・プロトコルのタイプに依存することになる。所与のブロックチェーンは、典型的には、全体を通じて1つの特定のトランザクション・プロトコルを使用する。1つの一般的なタイプのトランザクション・プロトコルでは、各トランザクション152のデータ構造は、少なくとも1つのインプット及び少なくとも1つのアウトプットを含む。各々のアウトプットは、ユーザー103に属するデジタル資産の量を表す分量を指定し、そのユーザーのアウトプットは暗号的にロックされている（ロックを解除してそれによって償還又は消費されるためには、そのユーザーの署名を必要とする）。各々のインプットは、先行するトランザクション152のアウトプットを後方から指し示し、それによって、トランザクションを結び付ける。

[0014] ノード104のうちの少なくとも一部は、トランザクション152を転送し、それによって伝搬させる転送ノード104Fの役割を担う。ノード104のうちの少なくとも一部は、ブロック151を採掘するマイナー104Mの役割を担う。ノード104のうちの少なくとも一部は、記憶ノード104Sの役割を担い（しばしば“フル・コピー”ノードとも呼ばれる）、各ノードは、各自それぞれのメモリに同じブロックチェーン150の各自のコピーを記憶する。各マイナー・ノード104Mはまた、ブロック151へのマイニングを待つトランザクション152のプール154を維持する。所与のノード104は、転送ノード104、マイナー104M、ストレージ・ノード104S、又はこれらのうちの2つ若しくは全ての任意の組み合わせであり得る。

[0015] 所与の現在のトランザクション152jにおいて、その（各々の）インプットは、トランザクションのシーケンスにおいて先行するトランザクション152iのアウトプットを参照するポインタを含み、それはこのアウトプットが現在のトランザクション152jにおいて償還されるか（redeem）、又は“消費される”（spent）ことを指定する。一般に、先行するトランザクションは、プール154又は任意のブロック151内の任意のトランザクションであるとすることが可能である。先行するトランザクション152iは、現在のトランザクション152jが作成される時点、又はネットワーク106へ送信される時点においてさえ必ずしも存在することを必要としないが、先行するトランザクション152iは、現在のトランザクションが有効とされるためには、存在して検証されることを必要とする。従って、本件において“先行する（preceding）”とは、ポインタによってリンクされた論理的な順序における先行を指し、必ずしも時間的な順序における作成又は送信する時間ではなく、従って、トランザクション152i、152jが順番通りではく作成又は送信されることを必ずしも排除していない（孤立トランザクションに関する説明を参照されたい）。先行するトランザクション152iは、同様に、先立つトランザクション又は先行トランザクションと呼ぶことができる。

[0016] 現在のトランザクション152jのインプットは、ユーザー103aの署名も含み、先行するトランザクション152iのそのユーザーのアウトプットはロックされる。次いで、現在のトランザクション152jのアウトプットは、新しいユーザー103bに暗号的にロックすることができる。従って、現在のトランザクション152jは、先行するトランザクション152iのインプットで定められる分量を、現在のトランザクション152jのアウトプットで定められる新しいユーザー103bへ転送することができる。ある場合には、トランザクション152は、複数のユーザー間でインプット量を分割するために、複数のアウトプットを有する可能性がある（それらのうちの1つは、変更をもたらすための、元のユーザー103aであるとすることが可能である）。場合によっては、トランザクションは複数のインプットを有し、1つ以上の先行トランザクションの複数のアウトプットからの分量を集め、現在のトランザクションの1つ以上のアウトプットへ分配し直すことも可能である。

[0017] 上記は、“アウトプット・ベース”トランザクション・プロトコルと呼ばれることがあり、時には未使用トランザクション・アウトプット（UTXO）タイプのプロトコルとも呼ばれる（アウトプットはUTXOと呼ばれる）。ユーザーのトータル残高は、ブロックチェーンで記憶されるどの1つの番号においても定められず、その代わりに、ユーザーは、ブロックチェーン151内の多くの異なるトランザクション152に散在する、そのユーザーの全てのUTXOの値を照合するために、特別な“ウォレット”アプリケーション105を必要とする。

[0018] 別のタイプのトランザクション・プロトコルは、アカウント・ベースのトランザクション・モデルの一部として、“アカウント・ベース”プロトコルと呼ばれることがある。アカウント・ベースの場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行トランザクションのUTXOを後方から参照することによって転送される分量を定めるのではなく、むしろ絶対的なアカウント残高を参照することによって定める。全てのアカウントの現在の状態は、ブロックチェーンに分散するマイナーによって記憶され、絶えず更新される。このようなシステムでは、トランザクションは、アカウントの実行中のトランザクション・タリー（tally）（“ポジション”とも呼ばれる）を使用して並べられる。この値は、送信者によって、自身の暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュ化される。更に、オプションのデータ・フィールドがトランザクションにおいて署名されてもよい。このデータ・フィールドは、例えば、以前のトランザクションIDがデータ・フィールドに含まれている場合に、以前のトランザクションを示すことが可能である。

[0019] 何れのタイプのトランザクション・プロトコルでも、ユーザー103が新しいトランザクション152jを制定することを希望する場合、彼／彼女は、彼／彼女のコンピュータ端末102から、P2Pネットワーク106のノード104のうちの1つへ、新しいトランザクションを送信する（これは今日では、典型的には、サーバー又はデータ・センターであるが、原則として他のユーザー端末であるとすることが可能である）。このノード104は、各ノード104で適用されるノード・プロトコルに従って、トランザクションが有効であるかどうかをチェックする。ノード・プロトコルの詳細は、全体的なトランザクション・モデルを形成するとともに、対象のブロックチェーン150で使用されているトランザクション・プロトコルのタイプに対応することになる。ノード・プロトコルは、典型的には、新たなトランザクション152jにおける暗号署名が、トランザクション152の順序付けられたシーケンスにおいて先行するトランザクション152iに依存する期待される署名に一致することをチェックするように、ノード104に要求する。アウトプット・ベースの場合、これは、新しいトランザクション152jのインプットに含まれるユーザーの暗号署名が、新しいトランザクションが消費する先行トランザクション152iのアウトプットで定められる条件に合致することをチェックすることを含む可能性があり、その条件は、典型的には、新しいトランザクション152jのインプットにおける暗号署名が、新しいトランザクションのインプットが指し示す先行トランザクション152iのアウトプットをロック解除することを少なくともチェックすることを含む。幾つかのトランザクション・プロトコルでは、条件は、少なくとも部分的に、インプット及び／又はアウトプットに含まれるカスタム・スクリプトによって定められてもよい。代替的に、単にノード・プロトコルだけで解決することも可能であり、或いは、これらの組み合わせによることも可能である。何れにせよ、新しいトランザクション152jが有効であるならば、現在のノードは、P2Pネットワーク106内のノード104のうちの1つ以上の他のノードへそれを転送する。これらのノード104のうちの少なくとも一部は、転送ノード104Fとしても機能し、同じノード・プロトコルに従って同じテストを適用し、新しいトランザクション152jを1つ以上の更なるノード104へ転送すること等々を行う。このように、新しいトランザクションは、ノード104のネットワーク全体に伝搬される。

[0020] アウトプット・ベース・モデルでは、所与のアウトプット（例えば、UTXO）が消費されるかどうかの定義は、ノード・プロトコルに従って、別の前方トランザクション152jのインプットによって既に有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが消費又は償還を試みる先行トランザクション152iのアウトプットが、別の有効なトランザクションによって既に消費／償還されていないことである。ここでも、有効でない場合、トランザクション152jは、ブロックチェーンにおいて伝搬又は記録されない。これは、消費者が、同じトランザクションのアウトプットを、複数回消費しようとする二重消費から保護する。一方、アカウント・ベースのモデルは、アカウント残高を維持することによって、二重消費から保護する。ここでも、トランザクションの定められた順序が存在するので、アカウント残高は、定められた単独の状態をどの時点においても有する。

[0021] 検証に加えて、ノード104Mのうちの少なくとも一部はまた、マイニングとして知られるプロセスでトランザクションのブロックを最初に作成するために競い合い、これは“プルーフ・オブ・ワーク”によって支えられている。マイニング・ノード104Mでは、まだブロックに登場していない有効なトランザクションのプールに、新しいトランザクションが追加される。次いで、マイナーたちは、暗号パズルを解くことを試みることによって、トランザクションのプール154から、トランザクション152の新しい有効なブロック151を組み立てようと競う。典型的には、これは、“ナンス（nonce）”値を探索することを含み、その結果、ナンスはトランザクションのプール154に連結され、ハッシュ化され、ハッシュのアウトプットは所定の条件を充足する。例えば、所定の条件は、ハッシュのアウトプットが、所定の数のゼロが先行するものを有することであってもよい。ハッシュ関数の特性は、インプットに対して予測不可能なアウトプットを有することである。従って、この探索は、ブルートフォースによってのみ実行することが可能であり、従って、パズルを解こうと試みる各ノード104Mでは、かなりの量の処理リソースを消費する。

[0022] パズルを解いた最初のマイナー104Mは、それをネットワーク106へ通知し、その解をプルーフ（proof）として提供し、次いでこれはネットワーク内の他のノード104によって容易にチェックすることができる（ハッシュに対する解が与えられると、それがハッシュのアウトプットを条件に合致させていることをチェックすることは容易である)。勝者がパズルを解いたトランザクションのプール154は、次いで、そのような各ノードにおける勝者が告知した解のチェックに基づいて、ストレージ・ノード104Sとして作用するノード104のうちの少なくとも一部によって、ブロックチェーン150内の新しいブロック151として記録されるようになる。ブロック・ポインタ155はまた、チェーン内で以前に生成されたブロック151n-1を後方から指し示す新しいブロック151nにも割り当てられる。新しいブロック151を作成するために多大な労力を費やすので、及び二重支出を含む如何なるブロックも他のノード104によって拒否される可能性が高いので、プルーフ・オブ・ワークは二重支出のリスクを低減するのに役立ち、マイニング・ノード104Mは、二重支出がそれらのブロックに含まれることを許容しないように動機付けられる。いったん生成されると、ブロック151は修正されることは不可能であり、なぜなら同じプロトコルに従ってP2Pネットワーク106内の記憶ノード104Sの各々でそれが認識されて維持されるからである。ブロック・ポインタ155はまた、ブロック151に連続的な順序を課す。トランザクション152は、P2Pネットワーク106内の各々の記憶ノード104Sにおいて順序付けられたブロックに記録されるので、従ってこれはトランザクションの変更できない公の台帳を提供する。

[0023] 任意の所与の時間にパズルを解くために競い合う様々なマイナー104Mは、それらがいつ解を探索し始めたかに応じて、任意の所与の時間における採掘されていないトランザクション・プール154の様々なスナップ・ショットに基づいて、そのようにすることができることに留意されたい。それぞれのパズルを最初に解いた者が誰であれ、どのトランザクション152が次の新しいブロック151nに含まれるかを定め、採掘されていないトランザクションの現在のプール154が更新される。次いで、マイナー104Mは、新たに定められた未解決のプール154から、ブロックを生成する等のために競い続ける。また、生じる可能性のある何らかの“フォーク”を解決するためのプロトコルも存在し、これは、2人のマイナー104Mが互いの非常に短時間の間に彼らのパズルを解いて、その結果、ブロックチェーンの矛盾した見方が伝播してゆくことである。要するに、フォークのどちらの突起が伸びても、最も長い方が最終的なブロックチェーン150となる。

[0024] ほとんどのブロックチェーンでは、勝利したマイナー104Mは、（あるユーザーから別のユーザーへある分量のデジタル資産を移転する通常のトランザクションとは異なり）どこにもない新しい分量のデジタル資産を創出する特別な種類の新しいトランザクションによって自動的に報奨を受ける。従って、勝利したノードは、ある分量のデジタル資産を“採掘した”したと言われる。この特殊なタイプのトランザクションは、しばしば“ジェネレーション”トランザクションと呼ばれる。それは自動的に新しいブロック151nの一部を形成する。この報奨は、マイナー104Mがプルーフ・オブ・ワークに参加するインセンティブを与える。通常の（ジェネレーションでない）トランザクション152は、そのアウトプットの1つにおいて追加のトランザクション手数料を指定し、そのトランザクションが含まれたブロック151nを生成した勝者マイナー104Mを更に報奨する。

[0025] マイニングに関わる計算リソースに起因して、典型的には、マイナー・ノード104Mのうちの各々は少なくとも、1つ以上の物理的なサーバー・ユニット、又はデータ・センター全体さえも含むサーバーの形態をとる。各々の転送ノード104M及び／又は記憶ノード104Sは、サーバー又はデータ・センターの形態をとることも可能である。しかしながら、原則として、所与の任意のノード104は、ユーザー端末又は互いにネットワーク接続されたユーザー端末のグループ、の形態をとることができる。

[0026] 各ノード104のメモリは、それぞれの1つの役割又は複数の役割を実行し、ノード・プロトコルに従ってトランザクション152を処理するために、ノード104の処理装置で動作するように構成されたソフトウェアを記憶する。本件においてノード104に帰属する如何なるアクションも、それぞれのコンピュータ装備の処理装置上で動作するソフトウェアによって実行されてもよいことが理解されるであろう。また、本件で使用される用語“ブロックチェーン”は、一般的な技術の種類を指し、何らかの特定の専有ブロックチェーン、プロトコル又はサービスに限定されない一般的な用語である。

[0027] また、ネットワーク101に接続されるものは、消費するユーザーの役割を担う複数の当事者103各々のコンピュータ装備102である。これらは、トランザクションにおける支払人と受取人として機能するが、他の当事者の代わりに、トランザクションをマイニングしたり又は伝播させたりすることに必ずしも参加しない。それらは必ずしもマイニング・プロトコルを実行するわけではない。2つの当事者103及びそれぞれの装備102は、説明の目的で示されており：第1当事者103a及び彼／彼女の各自のコンピュータ装備102a、並びに第2当事者103b及び彼／彼女の各自のコンピュータ装備102bである。より多くのこのような当事者103及びそれら各自のコンピュータ装備102がシステムに存在し、参加する可能性があるが、便宜上、それらは図示されていないことが理解されるであろう。各々の当事者103は、個人又は組織であってもよい。純粋に例示として本件において第1当事者103aはアリス（Alice）と称され、第2当事者103bはボブ（Bob）と称されるが、これが限定ではないこと、本件におけるアリス又はボブという如何なる言及も、それぞれ“第1当事者”及び“第2当事者”で置き換えられてもよいことが理解されるであろう。

[0028] 各々の当事者103のコンピュータ装備102は、1つ以上のプロセッサ、例えば1つ以上のCPU、GPU、その他のアクセラレータ・プロセッサ、特定用途向けプロセッサ、及び／又はFPGAを含むそれぞれの処理装置を含む。各々の当事者103のコンピュータ装備102は、更に、メモリ、即ち、非一時的なコンピュータ読み取り可能な媒体又はメディアの形態におけるコンピュータ読み取り可能なストレージを含む。このメモリは、1つ以上のメモリ媒体、例えば、ハード・ディスクのような磁気媒体；SSD、フラッシュ・メモリ又はEEPROMのような電子媒体；及び／又は光学ディスク・ドライブのような光学媒体を使用する1つ以上のメモリ・ユニットを含むことが可能である。各々の当事者103のコンピュータ装備102におけるメモリは、処理装置上で動作するように構成された少なくとも1つのクライアント・アプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本件において所与の当事者103に帰属する如何なるアクションも、それぞれのコンピュータ装備102の処理装置上で動作するソフトウェアを使用して実行されてもよいことが理解されるであろう。各々の当事者103のコンピュータ装備102は、少なくとも1つのユーザー端末、例えばデスクトップ又はラップトップ・コンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブル・デバイスを含む。所与の当事者103のコンピュータ装備102は、ユーザー端末を介してアクセスされるクラウド・コンピューティング・リソースのような、1つ以上の他のネットワーク化されたリソースを含んでもよい。

[0029] クライアント・アプリケーション又はソフトウェア105は、最初に、適切なコンピュータ読み取り可能な記憶媒体又はメディア上の任意の所与の当事者103のコンピュータ装備102に提供されてもよく、例えばサーバーからダウンロードされてもよいし、又はリムーバブル・ストレージ・デバイスであって、リムーバブルSSD、フラッシュ・メモリ・キー、リムーバブルEEPROM、リムーバブル磁気ディスク・ドライブ、磁気フロッピー・ディスク又はテープ、CD又はDVD ROMのような光ディスク、又はリムーバブル光学ドライブのようなものに提供されてもよい。

[0030] クライアント・アプリケーション105は少なくとも“ウォレット（wallet）”機能を含む。これは主に2つの機能を有する。そのうちの1つは、それぞれのユーザー当事者103が、トランザクション152を作成し、署名し、送信して、ノード104のネットワーク全体にわたって伝搬させ、それによってブロックチェーン150に含まれることを可能にすることである。もう1つは、彼又は彼女が現在所有しているデジタル資産の分量をそれぞれの当事者に報告して返すことである。アウトプット・ベース・システムでは、この第2機能は、対象の当事者に属するブロックチェーン150全体に散在する様々な152トランザクションのアウトプットで定められる分量を照合することを含む。

[0031] 各コンピュータ装備102におけるクライアント・アプリケーション105のインスタンスは、P2Pネットワーク106の転送ノード104Fのうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能が、トランザクション152をネットワーク106に送信することを可能にする。クライアント105はまた、記憶ノード104のうちの1つ、一部、又は全部と連絡を取り、それぞれの当事者103が受取人である何らかのトランザクションについて、ブロックチェーン150に問い合わせを行うことができる（又は、実際、ブロックチェーン150内の他の当事者のトランザクションを検査する。なぜなら実施形態ではブロックチェーン150は、部分的に公衆の目に触れてトランザクションの信頼を提供する公の施設であるからである）。各々のコンピュータ装備102におけるウォレット機能は、トランザクション・プロトコルに従ってトランザクション152を形成し、送信するように構成される。各ノード104は、ノード・プロトコルに従ってトランザクション152を検証するように構成されたソフトウェアを実行し、転送ノード104Fの場合には、ネットワーク106全体にトランザクション152を伝播させるためにトランザクション152を転送する。トランザクション・プロトコルとノード・プロトコルは互いに対応し、所与のトランザクション・プロトコルは所与のノード・プロトコルと共に所与のトランザクション・モデルを実装する。同じトランザクション・プロトコルが、ブロックチェーン150内の全てのトランザクション152に使用される（ただし、トランザクション・プロトコルは、トランザクションの異なるサブタイプをその中で許可してもよい)。同じノード・プロトコルは、ネットワーク106内の全てのノード104によって使用される（ただし、それはそのサブタイプに対して定められたルールに従って異なるトランザクションのサブタイプを別様に処理し、また、異なるノードは異なる役割を担い、従ってプロトコルの様々な対応する側面を実装することができる）。

[0032] 上述したように、ブロックチェーン150はブロック151のチェーンを含み、各ブロック151は、上述したように、プルーフ・オブ・ワーク・プロセスによって作成された1つ以上のトランザクション152のセットを含む。各ブロック151はまた、ブロック151に対する連続的な順序を定めるように、チェーン内で以前に生成されたブロック151を後方から指し示すブロック・ポインタ155を含む。ブロックチェーン150はまた、プルーフ・オブ・ワーク・プロセスによって新しいブロックに含まれることを待機する有効なトランザクション154のプールを含む。各トランザクション152は、一連のトランザクションに対する順序を定めるように、先行するトランザクションを後方から指し示すポインタを含む（注：一連のトランザクション152のシーケンスは、分岐することが許容されている）。ブロック151のチェーンは、チェーンの先頭ブロックであったジェネシス・ブロック（Gb）153に様々な経路で戻る。チェーン150の初期において、1つ以上のオリジナル・トランザクション152は、先行トランザクションではなく、ジェネシス・ブロック153を指す。

[0033] 所与の当事者103、例えばアリスが、ブロックチェーン150に含まれるように新しいトランザクション152jを送信することを望む場合、彼女は、関連するトランザクション・プロトコルに従って（彼女のクライアント・アプリケーション105におけるウォレット機能を使用して）新しいトランザクションを形成する。次いで、彼女は、トランザクション152を、クライアント・アプリケーション105から、彼女がつながっている1つ以上の転送ノード104Fのうちの1つへ送信する。例えば、これは、アリスのコンピュータ102に最も近いか、又は最良に接続されている転送ノード104Fである可能性がある。何らかの所与のノード104が新しいトランザクション152jを受信すると、それはノード・プロトコル及び各自の役割に従ってそれを処理する。これは、最初に、新たに受信したトランザクション152jが“有効”であるための特定の条件を充足するかどうかをチェックすることを含み、その例は間もなくより詳細に説明される。幾つかのトランザクション・プロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに設定可能であってもよい。代替的に、条件は単にノード・プロトコルの組み込み機能であってもよいし、あるいはスクリプトとノード・プロトコルの組み合わせによって定められてもよい。

[0034] 新たに受信されたトランザクション152jが、有効であると認められるテストに合格するという条件の下で（即ち、“有効化されている”という条件の下で）、トランザクション152jを受信した任意の記憶ノード104Sは、新たに有効とされたトランザクション152を、そのノード104Sで維持されているブロックチェーン150のコピー内のプール154に追加する。更に、トランザクション152jを受信する任意の転送ノード104Fは、検証されたトランザクション152を、P2Pネットワーク106内の1つ以上の他のノード104へ前方に伝搬させるであろう。各々の転送ノード104Fは同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、P2Pネットワーク106全体に間もなく伝搬されるであろうということを意味する。

[0035] 1つ以上のストレージ・ノード104で維持されるブロックチェーン150のコピー内のプール154に対していったん認められると、マイナー・ノード104Mは、新しいトランザクション152を含むプール154の最新バージョンに関するプルーフ・オブ・ワーク・パズルを解くために競争を開始する（他のマイナー104Mは、依然として、プール154の古い見解に基づいてパズルを解こうとするかもしれないが、そこに最初に到達した者は誰でも、次の新しいブロック151が終了して新しいプール154が始まる場所を定め、最終的には、誰かが、アリスのトランザクション152jを含むプール154の一部に対するパズルを解くであろう）。一旦、新しいトランザクション152jを含むプール154についてプルーフ・オブ・ワークが行われると、それは、変更不可能な方法で、ブロックチェーン150内のブロック151のうちの1つの一部となる。各々のトランザクション152は、以前のトランザクションへのポインタを含むので、トランザクションの順序もまた、変更不可能に記録される。

[0036] UTXOベース・モデル
図2は、例示的なトランザクション・プロトコルを示す。これはUTXOベース・プロトコルの例である。トランザクション152（“Tx”と略す）は、ブロックチェーン150（各ブロック151は1つ以上のトランザクション152を含む）の基本的なデータ構造である。以下、アウトプット・ベース・プロトコル又は“UTXO”ベース・プロトコルを参照することによって説明する。しかしながら、これは全ての可能な実施形態に対する限定ではない。

[0037] UTXOベース・モデルでは、各トランザクション（“Tx”）152は、1つ以上のインプット202と1つ以上のアウトプット203を含むデータ構造を含む。各々のアウトプット203は、未使用トランザクション・アウトプット（UTXO）を含む可能性があり、（UTXOがまだ償還されていない場合には）これは別の新しいトランザクションのインプット202のソースとして使用することができる。UTXOは、デジタル資産（価値のストア）の分量を指定する。また、他の情報の中でも、それが到来してきた元のトランザクションのトランザクションIDを含んでもよい。トランザクション・データ構造はまたヘッダ201を含んでもよく、インプット・フィールド202とアウトプット・フィールド203のサイズのインジケータを含む可能性がある。ヘッダ201はまた、トランザクションのIDを含んでもよい。実施形態において、トランザクションIDは、トランザクション・データのハッシュ（トランザクションID自体を除く）であり、マイナー104Mにサブミットされた未加工トランザクション152のヘッダ201に格納される。

[0038] 図2における各アウトプットはUTXOとして示されているが、トランザクションは、追加的又は代替的に、1つ以上のアンスペンダブル・トランザクション・アウトプットを含んでもよいことに留意されたい。

[0039] アリス103aは、問題としているデジタル資産の分量を、ボブ103bに転送するトランザクション152jを作成することを希望しているとする。図2では、アリスの新しいトランザクション152jは、“Tx₁”とラベル付けされる。これは、シーケンスで先行するトランザクション152iのアウトプット203においてアリスにロックされているデジタル資産の分量を取って、そのうちの少なくとも一部をボブへ転送する。先行トランザクション152iは、図2では“Tx₀”とラベル付けされている。Tx₀及びTx₁は、単なる任意的なラベルである。これらは、Tx₀がブロックチェーン151における最初のトランザクションであること、又は、Tx₁がプール154内で直近の次のトランザクションであることを必ずしも意味していない。Tx₁は、アリスにロックされた未使用アウトプット203を依然として有する、何らかの先行する（即ち、先立つ）トランザクションを後方から指し示すことができる。

[0040] 先行トランザクションTx₀は、アリスが彼女の新しいトランザクションTx₁を作成する時点、又は少なくとも彼女がそれをネットワーク106へ送信する時点までに、既に検証され且つブロックチェーン150に含まれている可能性がある。それは、その時点で既にブロック151のうちの1つに含まれている可能性があり、或いはプール154内でまだ待機している可能性があり、その場合、新しいブロック151に速やかに含まれることになる。代替的に、ノード・プロトコルが“オーファン”（orphan）トランザクションをバッファリングすることを許容する場合、Tx₀及びTx₁は一緒に作成されてネットワーク102へ送信することが可能であり、或いはTx₀がTx₁の後に送信されることさえ可能である。本件でトランザクション・シーケンスの文脈で使用される“先行”及び“後続”という用語は、トランザクションで指定されるトランザクション・ポインタ（どのトランザクションが、他のどのトランザクションを後方から指すか等）によって定められるシーケンスにおけるトランザクションの順序を指す。これらは“先行”と“後行”、“祖先”と“子孫”、“親”と“子”等により同等に置換することが可能である。これは、それらが生成されたり、ネットワーク106に送信されたり、又は任意の所与のノード104に到達したりする順序を必ずしも意味しない。それにもかかわらず、先行トランザクション（祖先トランザクション又は“親”）を指し示す後続トランザクション（子孫トランザクション又は“子”）は、親トランザクションが検証されるまで、及び親トランザクションが検証されない限り、検証されないであろう。親の前にノード104に到着した子は、孤立（オーファン）と考えられる。ノード・プロトコル及び／又はマイナーの行動に応じて、それは破棄されるか又は親を待機するまでの一定時間にわたってバッファリングされる可能性がある。

[0041] 先行トランザクションTx₀の1つ以上のアウトプット203のうちの1つは、本件ではUTXO₀とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の分量を指定する値と、後続のトランザクションが検証されるために、従ってUTXOが首尾良く償還されるために、後続のトランザクションのインプット202におけるアンロッキング・スクリプトによって充足されることを必要とする条件を定めるロッキング・スクリプトとを含む。典型的には、ロッキング・スクリプトは、特定の当事者（トランザクションに含まれている受取人）に対する分量をロックする。即ち、ロッキング・スクリプトは、アンロッキング条件を定め、典型的には、後続トランザクションのインプットにおけるアンロッキング・スクリプトが、先行トランザクションがロックされる当事者の暗号署名を含むという条件を含む。

[0042] ロッキング・スクリプト（scriptPubKeyとしても知られている）は、ノード・プロトコルによって認識されるドメイン固有の言語で書かれるコードの一部である。そのような言語の特定の例は、“Script”（大文字のS）と呼ばれるものである。ロッキング・スクリプトは、如何なる情報がトランザクション・アウトプット203を消費するために必要とされるか、例えばアリスの署名の条件を指定する。アンロッキング・スクリプトはトランザクションのアウトプットに登場する。アンロッキング・スクリプト（scriptSigとしても知られている）は、ロッキング・スクリプトの基準を満たすために必要とされる情報を提供するドメイン固有の言語で書かれたコードの一部である。例えばそれはボブの署名を含む可能性がある。アンロッキング・スクリプトは、トランザクションのインプット202に登場する。

[0043] 図示の例では、Tx₀のアウトプット203におけるUTXO₀は、ロッキング・スクリプト[Checksig P_A]を含み、これは、UTXO₀が償還されるために（厳密には、UTXO₀を償還しようとする後続のトランザクションが有効化されるために）、アリスの署名Sig P_Aを必要とする。[Checksig P_A]は、アリスの公開_秘密鍵ペアからの公開鍵P_Aを含む。Tx₁のインプット202は、Tx₁を指すポインタ（例えば、そのトランザクションID、TxID₀を利用することによって、実施形態ではそれはトランザクションTx₀全体のハッシュである）を含む。Tx₁のインプット202は、Tx₀の任意の他の可能なアウトプットの中でそれを識別するために、Tx₀内のUTXO₀を識別するインデックスを含む。Tx₁のインプット202は、更に、キー・ペアからのアリスの秘密鍵を、データの所定の部分（暗号化における“メッセージ”と呼ばれることもある）に適用してアリスによって作成された、アリスの暗号署名を含むアンロッキング・スクリプト<Sig P_A>を含む。如何なるデータ（又は“メッセージ”）が、有効な署名を提供するためにアリスによって署名されることを必要とするかは、ロッキング・スクリプトによって、ノード・プロトコルによって、又はこれらの組み合わせによって定められることが可能である。

[0044] 新しいトランザクションTx₁がノード104に到着すると、ノードはノード・プロトコルを適用する。これは、ロッキング・スクリプトとアンロッキング・スクリプトを一緒に実行して、アンロッキング・スクリプトがロッキング・スクリプトで定められている条件（この条件は1つ以上の基準を含む可能性がある）を充足しているかどうかをチェックすることを含む。実施形態において、これは2つのスクリプトを連結することを含む：
<Sig P_A><P_A>||[Checksig P_A]

[0045] ここで、“||”は連結を表し、“<...>”はデータをスタックの上に置くことを意味し、“[...]”はアンロッキング・スクリプト（この例では、スタック・ベース言語）によって構築される関数である。同様に、スクリプトは、スクリプトを連結するのではなく、共通のスタックで、交互に実行してもよい。いずれにせよ、一緒に実行される場合、スクリプトは、Tx₀のアウトプットにおけるロッキング・スクリプトに含まれるように、アリスの公開鍵P_Aを使用して、Tx₁のインプットにおけるロッキング・スクリプトが、データの予想される部分を署名するアリスの署名を含んでいることを認証する。この認証を実行するためには、データ自体の予想される部分（“メッセージ”）もTx₀に含まれることを必要とする。実施形態において、署名されたデータは、Tx₀の全体を含む（従って、個々の要素は包含されることを必要とし、データの署名された部分を平文で指定し、なぜなら既に本来的に存在するからである）。

[0046] 公開_秘密暗号による認証の詳細は、当業者にはよく知られているであろう。基本的には、アリスがプライベート・キーでメッセージを暗号化することによってメッセージに署名した場合、アリスの公開鍵と平文（暗号化されていないメッセージ）におけるメッセージが与えられると、ノード104のような別のエンティティは、そのメッセージの暗号化されたバージョンがアリスによって署名されていなければならないことを認証することができる。署名は、典型的には、メッセージをハッシュ化し、ハッシュに署名し、署名としてメッセージのクリア・バージョンにこれをタグ付けし、公開鍵の任意の所有者が署名を認証することを可能にする。

[0047] Tx₁のアンロッキング・スクリプトが、Tx₀のロッキング・スクリプトで指定された1つ以上の条件を満たす場合（図示の例では、アリスの署名がTx₁で提供され、認証される場合）、ノード104は、Tx₁を有効であるとみなす。それがマイニング・ノード104Mである場合、これは、プルーフ・オブ・ワークを待機するトランザクションのプール154にそれを追加することを意味する。それが転送ノード104Fである場合、それはトランザクションTx₁をネットワーク106内の1つ以上の他のノード104へ転送し、その結果、それがネットワーク全体に伝播されるであろう。いったんTx₁が検証され、ブロックチェーン150に含まれると、これはTx₀からのUTXO₀を消費済として定める。Tx₁は、それが未使用トランザクション・アウトプット203を消費する場合にのみ有効である可能性があることに留意されたい。別のトランザクション152によって既に消費されているアウトプットを消費しようとするならば、Tx₁は、たとえ他の全ての条件が充足されていたとしても無効となるであろう。従って、ノード104は、先行トランザクションTx₀において参照されるUTX_Oが既に消費されているかどうか（別の有効なトランザクションに対する有効なインプットを既に形成しているかどうか）もチェックすることを必要とする。これが、ブロックチェーン150にとって、トランザクション152に定義された順序を課すことは重要であることの理由の1つである。実際には、所与のノード104は、どのトランザクション152でどのUTXO203が消費されているかをマーキングする個々のデータベースを維持してもよいが、最終的にUTXOが消費されているかどうかを定めるものは、ブロックチェーン150内の別の有効なトランザクションに対する有効なインプットが既に形成されているかどうかである。

[0048] UTXOベースのトランザクション・モデルでは、所定のUTXOが全体として消費されることを必要とすることに留意されたい。UTXOで定められている分量のうちの一部分を“残しておく”一方、別の部分が消費される、ということはできない。しかしながら、UTXOの分量が次のトランザクションの複数のアウトプットの間で分割されることは可能である。例えば、Tx₀におけるUTXO₀で定められる分量は、Tx₁における複数のUTXOの間で分割されることが可能である。従って、アリスが、UTXO₀で定められる分量のうちの全てをボブに与えることを望まない場合、彼女は残りの分量を使って、Tx₁の第2アウトプットで自分自身に釣り銭を与えたり、別の当事者へ支払ったりすることができる。

[0049] 実際には、アリスは、通常、勝利したマイナーに対する手数料を含めることを必要とし、なぜなら、今日ではジェネレーション・トランザクションの報酬だけでは、典型的には、マイニングを動機付けるのに十分ではないからである。アリスがマイナーのための手数料を含めていない場合、Tx₀はマイナー・ノード104Mによって拒否される可能性が高く、従って、技術的には妥当であるが、それはまだ伝播されず、ブロックチェーン150に含まれないことになるであろう（マイナー・プロトコルは、マイナー104Mに、彼らが希望しない場合には、トランザクション152を受け入れるよう強制していない）。一部のプロトコルでは、マイニング手数料は、独自の別個のアウトプット203を必要としない（即ち、別個のUTXOを必要としない）。その代わりに、インプット202によって示される総量と所与のトランザクション152のアウトプット203で指定される総量との間の如何なる差分も、勝利したマイナー104に自動的に与えられる。例えば、UTXO₀に対するポインタがTx₁に対する唯一のインプットであり、Tx₁は唯1つのアウトプットUTXO₁を有するとする。UTXO₀で指定されたデジタル資産の分量がUTXO₁で指定された分量より多い場合、その差分は勝利したマイナー104Mへ自動的に向かう。しかしながら、代替的又は追加的に、マイナー手数料が、トランザクション152のUTXO203のうちの自身の1つにおいて明示的に指定できることは必ずしも除外されない。

[0050] また、所与のトランザクション152の全てのアウトプット203で指定される合計量が、その全てのインプット202で指定された合計量よりも大きい場合、これは、ほとんどのトランザクション・モデルにおいて無効性の別の根拠であることにも留意されたい。従って、このようなトランザクションは、ブロック151へ伝搬されたり、マイニングされたりしないであろう。

[0051] アリスとボブのデジタル資産は、ブロックチェーン150のどこかで何らかのトランザクション152において、それらにロックされた未使用UTXOから構成される。従って、典型的には、所与の当事者103の資産は、ブロックチェーン150を通じて、様々なトランザクション152のUTXO全体に分散される。ブロックチェーン150内のどこにも、所与の当事者103の総残高を定める1つの数字は記憶されていない。各々の当事者にロックされ、別の前方トランザクションでまだ消費されていない全ての様々なUTXOの値を一緒にまとめることは、クライアント・アプリケーション105におけるウォレット機能の役割である。これは、何らかの記憶ノード104S、例えば各々の当事者のコンピュータ装備102に最も近接しているか、又は最良に接続されている記憶ノード104S、に記憶されたブロックチェーン150のコピーを問い合わせることによって行うことができる。

[0052] スクリプト・コードはしばしば概略的に表現される（即ち、厳密な言語ではない）ことに留意されたい。例えば、ある人は、
[Checksig P_A] = OP_DUP OP_HASH160 <H(P_A)> OP_EQUALVERIFY OP_CHECKSIG
を意味するように、[Checksig P_A] と書くかもしれない。“OP_...”はスクリプト言語の特定のオペコードを示す。OP_CHECKSIG（“Checksig”とも呼ばれる）は、2つのインプット（署名と公開鍵）を取り、楕円曲線デジタル署名アルゴリズム（ECDSA）を使用して署名の妥当性を検証するScriptオペコードである。ランタイムにおいて、何らかの署名（‘sig’）の発生はスクリプトから削除されるが、ハッシュ・パズルのような追加的な条件は、‘sig’インプットによって検証されるトランザクションに残る。別の例として、OP_RETURNは、トランザクション内にメタデータを格納することができ、それによってメタデータを変更不可能にブロックチェーン150に記録することが可能なトランザクションの消費不能なアウトプット（unspendable output）を生成するためのScript言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望ましい文書を含むことが可能である。

[0053] 署名P_Aはデジタル署名である。実施形態において、これは楕円曲線secp256k1を使用するECDSAに基づいている。デジタル署名は、特定のデータに署名する。実施形態において、所与のトランザクションについて、署名は、トランザクション・インプットの一部、及びトランザクション・アウトプットの全部又は一部に署名するであろう。それが署名するアウトプットの特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、署名の最後に含まれる4バイトのコードであり、どのアウトプットが署名されるのかを選択する（従って、署名の時点で確定される）。

[0054] ロッキング・スクリプトはしばしば“scriptPubKey”と呼ばれ、それぞれのトランザクションがロックされている参加者の公開鍵を含んでいるという事実を示す。アンロッキング・スクリプトはしばしば“scriptSig”と呼ばれ、対応する署名を提供するという事実を示す。しかしながら、より一般的には、UTXOが償還される条件が、署名を認証することを含む、ということはブロックチェーン150の全てのアプリケーションで必須なことではない。より一般的には、スクリプト言語は、任意の1つ以上の条件を定めるために使用されることが可能である。従って、より一般的な用語である“ロッキング・スクリプト”及び“アンロッキング・スクリプト”が好ましいかもしれない。

[0055] オプショナル・サイド・チャネル
図3は、ブロックチェーン150を実装するための別のシステム100を示す。システム100は、追加の通信機能が含まれることを除いて、図1に関連して説明したものと実質的に同じである。アリスとボブのコンピュータ装備102a、120b各々におけるクライアント・アプリケーションはそれぞれ付加的な通信機能を含む。即ち、それは、アリス103aが（何れかの当事者又は第三者の誘いにより）ボブ103bとの別個のサイド・チャネル301を確立することを可能にする。サイド・チャネル301は、P2Pネットワークとは別にデータの交換を可能にする。このような通信はしばしば“オフ・チェーン”（off-chain）と呼ばれる。例えばこれは、当事者の一方がそれをネットワーク106にブロードキャストすることを選択するまで、トランザクションが（未だ）ネットワークP2P 106上で公表されることなく、又はチェーン150上で進行させることなく、アリスとボブの間でトランザクション152を交換するために使用することができる。代替的又は追加的に、サイド・チャネル301は、キー、交渉された金額又は条件、データ内容などのような何らかの他のトランザクション関連データを交換するために使用することができる。

[0056] サイド・チャネル301は、P2Pオーバーレイ・ネットワーク106と同じパケット交換ネットワーク101を介して確立されてもよい。代替的又は追加的に、サイド・チャネル301は、移動体セルラ・ネットワークのような異なるネットワークを介して、又はローカル無線ネットワークのようなローカル・エリア・ネットワークを介して、又はアリスとボブのデバイス102a,102bの間の直接的な有線又は無線リンクを介してさえも、確立することができる。一般に、本明細書の何処かで言及されるようなサイド・チャネル301は、“オフ・チェーン”で、即ちP2Pオーバーレイ・ネットワーク106とは別に、データを交換するための1つ以上のネットワーク技術又は通信媒体を介する任意の1つ以上のリンクを含んでもよい。1つより多いリンクが使用される場合、オフ・チェーン・リンクの束又は集まりは、全体として、サイド・チャネル301と言及されてもよい。従って、アリスとボブがサイド・チャネル301を介して特定の情報又はデータ等を交換する、と言及される場合、それは、これらのデータの全てが厳密に同じリンクを介して又は同じタイプのネットワークでさえそれを介して送信されなければならないことを必ずしも意味しないことに留意されたい。

[0057] ノード・ソフトウェア
図4は、UTXO又はアウトプット・ベース・モデルの例において、P2Pネットワーク106の各ノード104上で実行されるノード・ソフトウェア400の例を示す。ノード・ソフトウェア400は、プロトコル・エンジン401、スクリプト・エンジン402、スタック403、アプリケーション・レベル決定エンジン404、及び1つ以上のブロックチェーン関連機能モジュール405のセットを含む。任意の所与のノード104において、これらは：（ノードの1つの役割又は複数の役割に応じて）マイニング・モジュール405M、転送モジュール405F、及び記憶モジュール405Sのうちの何れか1つ、2つ、又は3つ全てを含む可能性がある。プロトコル・エンジン401は、ノード・プロトコルに従って、トランザクション152の様々なフィールドを認識し、それらを処理するように構成される。トランザクション152m（Tx_m）が受信され、それが別の先行するトランザクション152m-1（Tx_m-1）のアウトプット（又は、UTXO）を指し示すインプットを有する場合、プロトコル・エンジン401はTx_m内のアンロッキング・スクリプトを識別し、それをスクリプト・エンジン402に渡す。プロトコル・エンジン401はまた、Tx_mのインプットの内のポインタに基づいて、Tx_m-1を識別及び探索する。それは、Tx_m-1がまだブロックチェーン150上にない場合には、ペンディング・トランザクションの各自のノードの自身のプール154から、又は、Tx_m-1が既にブロックチェーン150上にある場合には、各ノード又は他のノード104に記憶されたブロックチェーン150内のブロック151のコピーから、Tx_m-1を取り出すことができる。いずれにせよ、スクリプト・エンジン401は、指し示されたTx_m-1のアウトプット内のロッキング・スクリプトを識別し、これをスクリプト・エンジン402に渡す。

[0058] 従って、スクリプト・エンジン402は、Tx_m-1のロッキング・スクリプトとTx_mの対応するインプットからのアンロッキング・スクリプトとを有する。例えば、Tx₁とTx₂が図4に示されているが、同様のことは、例えばTx₀とTx₁等のような任意のペアのトランザクションにも当てはまる可能性がある。スクリプト・エンジン402は前述のように2つのスクリプトを一緒に実行し、それは、使用されるスタック・ベースのスクリプト言語（例えば、Script）に従って、データをスタック403に配置し、スタック403からデータを取り出すことを含むであろう。

[0059] スクリプトを一緒に実行することによって、スクリプト・エンジン402は、アンロッキング・スクリプトがロッキング・スクリプトで定められる1つ以上の基準を充足するかどうか、即ち、ロッキング・スクリプトが含まれているアウトプットを“ロック解除”するか？を判断する。スクリプト・エンジン402は、この決定の結果をプロトコル・エンジン401に返す。スクリプト・エンジン402は、アンロッキング・スクリプトが、対応するロッキング・スクリプトで指定される1つ以上の基準を充足している、と判断した場合には、結果“真（true）”を返す。そうでない場合には、結果“偽（false）”を返す。

[0060] アウトプット・ベース・モデルでは、スクリプト・エンジン402からの“真”の結果は、トランザクションの有効性に関する条件の1つである。典型的には、更に充足されることを要する、プロトコル・エンジン401によって評価される1つ以上の更なるプロトコル・レベルの条件も存在し；例えば、Tx_mのアウトプットで指定されるデジタル資産の総量が、そのインプットによって指し示される総量を超えないこと、及びTx_m-1の指し示されたアウトプットが、別の有効なトランザクションによってまだ消費されていないことである。プロトコル・エンジン401は、スクリプト・エンジン402からの結果を、1つ以上のプロトコル・レベル条件と共に評価し、それらが全て真である場合にのみ、トランザクションTx_mを有効化する。プロトコル・エンジン401は、トランザクションがアプリケーション・レベル決定エンジン404に対して有効であるかどうかの指示を出力する。Tx_mが実際に有効化された条件のみで、決定エンジン404は、Tx_mに関する各自のブロックチェーン関連機能を実行するために、マイニング・モジュール405M及び転送モジュール405Fの一方又は両方を制御するように選択することができる。これは、ブロック151へのマイニングのためにノードのそれぞれのプール154にTx_mを追加するマイニング・モジュール405M、及び／又はP2Pネットワーク106内の別のノード104へTx_mを転送する転送モジュール405Fを含む可能性がある。しかしながら、実施形態において、決定エンジン404は、無効なトランザクションを転送したり又はマイニングしたりすることを選択しないであろうが、これは、逆に、それが有効であるという理由のみで、有効なトランザクションのマイニング又は転送をトリガするよう強いることを必ずしも意味しないことに留意されたい。オプションとして、実施形態において、決定エンジン404は、これらの機能の一方又は双方をトリガする前に、1つ以上の追加的な条件を適用することができる。例えば、ノードがマイニング・ノード104Mである場合、決定エンジンは、トランザクションが有効であり、且つ十分なマイニング手数料を残すという双方を条件として、トランザクションをマイニングすることを選択するだけであってもよい。

[0061] また、本件において“真”及び“偽”という用語は、必ずしも単一の2進数（ビット）の形式のみで表される結果を返すことに限定されないが、それは確かに1つの可能な実装であることにも留意されたい。より一般的には、“真”は成功又は肯定的な結果を示す任意の状態を指し、“偽”は失敗又は否定的な結果を示す任意の状態を指す可能性がある。例えば、アカウント・ベース・モデル（図4には示されていない）においては、“真”の結果は、ノード104による署名の暗黙のプロトコル・レベルの検証と、スマート契約の追加の肯定的なアウトプットとの組み合わせによって示されることが可能である（全体の結果は、個々の両方の結果が真であれば真を伝えていると見なされる）。

[0062] 乱数生成
ハッシュ関数は乱数を生成するために使用することができる。ブロックチェーンの構築は、典型的には、ハッシュ関数の使用とそれらの固有の特性に基づいている。ここでハッシュ関数Hは、任意のデータ構造Xをとり、固定数のビット又はシンボルを有する数（例えば、下記の256ビットの数）を出力する一方向の決定論的な関数として定義される：

[0063] SHA-256のようなハッシュ関数は一方向ランダム・オラクルとして動作する。即ち、ハッシュYがユーザーに知られていないプリ・イメージXから計算される場合、ユーザーがXを発見することは計算上困難である。

[0064] ハッシュ関数の特性は、1ビットの値のみが異なる2つの固定長出力データ構造（例えば、256ビットデータ構造）のハッシュは、完全に無関係として扱えることである。言い換えれば、ハッシュ値は、そのユーザーがプリ・イメージ全体を知らない限り、ユーザーにとって真の乱数として振る舞う。

[0065] これは、ハッシュ値Y - 又は何らかのその関数 - をとることによって、それは単独の乱数Rとして取り扱うことが可能であることを意味し、ただし、単一の者が入力プリ・イメージX全体に対する支配権を有しないことを仮定する。

[0066] 拡張により、（k+1）個の乱数の乱数シーケンスS_Rは、同じ引数を使用して初期乱数R₀を繰り返しハッシュすることによって生成されることが可能である。

[0067] ハッシュ関数は決定論的であるので、誰もが、使用される特定のハッシュ関数と、ここではシードとして機能する初期プリ・イメージX₀との知識のみを用いて、シーケンスS_R全体を再生することができる。

[0068] ランダム・シーケンスが生成される場合に、この初期プリ・イメージが公に生成されるならば、任意のノードが、シーケンスはこのプリ・イメージに対応することを独立に検証することができる。従って、乱数を生成することに関与する単一の者が初期プリ・イメージX₀全体を操作できないことを条件として、ハッシュ関数は乱数シーケンスを生成するために使用されてもよい、ということは明らかである。

[0069] 一般に、用語‘ハッシュ関数’は、固定サイズの出力を伴う任意のタイプの一方向関数を指すために使用される。ハッシュ関数は、スクリプト言語において既存のop_codeを有する。しかしながら、本件で開示される技術は、スクリプトにおける実装に限定されない。更に、代替的な一方向関数が、ハッシュ関数の任意のインスタンスの代わりに使用されることが可能である。2つの例がある：
[0070] i）楕円曲線（EC）点乗算 - 関数E（x）= x・G；これは、EC公開鍵を秘密鍵から生成するために使用され、Gは楕円曲線の基点であり、‘・’はEC点乗算演算子である。これは、所与のx，Gの下でE(x)を計算することは容易であるが、所与のE(x)，Gの下でxを決定することは計算上困難であるような一方向関数である。

[0071] ii）ラビン関数（Rabin function）- ラビン関数R(x) = x² mod N；ここで、N=pqであり、p,qは素数である。R(x)の二乗 modulo Nを見出すことは容易であるが、所与のR(x)の下で平方根±xを見出すことは、素数p,qを発見するためにNを因子分解することと同程度に困難であり、これは計算上困難である。

[0072] 以下、ブロックチェーンを使用して乱数を生成するための3つのバリエーションを説明する。各々の方法は、乱数を作成するために協働する複数のパーティ（当事者、参加者、関係者）を含む。第1方法は、セキュアな乱数を生成するためにハッシュ・プリ・イメージの組み合わせを使用し、第2方法は、幾つかの署名からsコンポーネントの組み合わせを使用する。第3方法は、2つの方法のハイブリッドである。各々の方法はセキュアな乱数R_N∈{0, N-1}を生成する。

[0073] 第1方法：ハッシュ方法
N人のプレーヤを考察する。それぞれは独自のハッシュ値Y_i=H(X_i)を公開している。ここで、それぞれのプレーヤは独自のシークレットなプリ・イメージX_iを選んでいることを条件としている。ハッシュ関数の特性から、所与の公のハッシュ値の知識の下で、どのプレーヤも他者のプリ・イメージを推測できない、ということを仮定することができる。

[0074] 次いで、プレーヤは自分のシークレットなプリ・イメージX_iをオラクル（信頼できる第三者）に送る。これは、シークレット値の分散技術により行うことが可能であるが、より一般的には、必要とするこの方法は、何らかの安全なチャネル又は仕組みを使用して、プリ・イメージをオラクルへ伝えることができる。次いで、オラクルは次の方法で乱数R_Nを生成する。

[0075] ステップ1. オラクルは、各プレーヤから提供されたプリ・イメージに対してY_i=H(X_i)を検証する。ハッシュ値は、プリ・イメージがオラクルに送信される前に、既に公開されている。これは、オラクルが、各プレーヤが元々提供した正しいプリ・イメージの供給を受けることを保証する。ブロックチェーンでは、これらの公開値は不変であり、従ってプリ・イメージを送信した後に、プレーヤが変更することはできない。この検証ステップは、全てのプレーヤが、彼らの選択したシークレットなプリ・イメージとともにそれを提供するまで、オラクルは乱数の生成に進まないことを保証する。

[0076] ステップ2. オラクルは、次のようにしてR_Nを計算する。

R_Nは、オリジナルのプリ・イメージ値X_iのN個全てを知っているプレーヤはいないという条件で、各々の及び全員のプレーヤに関して乱数である。全てのプリ・イメージは、プレーヤによりシークレットに保持され、オラクルへ安全に伝えられる。これは、悪意のある者が、関係する全てのプレーヤを支配しない限り、これら全ての入力を知ることはできないことを意味する。この場合、敵対者は、自らだけで使用する乱数にささいな操作を行うことになるであろう。

[0077] 他の全てのシナリオでは、最低1人の真のプレーヤが存在しており、ハッシュ関数の説明済みの特性は、彼らが有意義な方法でR_Nを操作できないことを意味する。これは、たとえ敵対者がN-1人全員の他のプレーヤを支配している場合でさえ当てはまる。簡単に言えば、この方法によって生成された乱数に影響を及ぼす方法は誰にとっても存在せず、他者に敵対的に影響を及ぼすことはできない。

[0078] プリ・イメージX_iの加法的な‘+’加算が、Scriptで実装できるように使用されてもよいが、連結のような異なる演算子を、上記の加算と同様に直列的に使用することも可能である。

[0079] 乱数R_Nは、(1)プロセスに関係する任意の者にとって予測不可能であり、且つ(2)決定論的なプロセスで再現可能な方法で生成される。

[0080] 説明されているように、拡張は、オラクルによるR_Nの繰り返されるハッシュ化によって、乱数シーケンスが生成されてもよい、ということである。

[0081] 第2方法：署名方法
プレーヤのアリス（Alice）を想定し、アリスは彼女の秘密鍵S_Aを使用してメッセージ・ハッシュH(m)のデジタル署名を作成することを希望している。アリスは、ECCに従って通常の方法で秘密鍵に関連付けられた公開鍵P_Aを有しており、ここで、Gは次数nの楕円曲線の基点である。

P_A=S_A・G
[0082] 作成されることを必要とするデジタル署名の2成分：rとsがある。アリスは、一時的な鍵を乱数k，

として生成し、それを用いて署名のr部分を導出する。

(R_x, R_y) = k・G
r = R_x
[0083] 次いで、署名のs部分はそこからアリスの秘密鍵、彼女のハッシュ・メッセージ、及び一時的な鍵の組み合わせにより、以下のようにして導出される：

[0084] rとsを連結することにより、メッセージ・ハッシュのECDSAデジタル署名として知られるデータ構造が作成される。

[0085] 値rとsが別々に与えられると、完全な署名をスクリプトで構成することができる。

[0086] ここで、N人のプレーヤを想定し、彼ら各々の署名Sig Piと乱数r_i’を公開しており、r_i’は第2署名Sig P_i’の一部分を形成し、第2署名のs’部分はシークレットに保たれる。

両方の署名は、同じ秘密鍵S_iを使用して署名され、その結果、両方の署名が公開鍵P_iの同じ所有者に対応することを検証することができる。
P_i = S_i・G
[0087] 次いで、プレーヤは、各自のシークレットs_i’をオラクルへ、好ましくは秘密共有技術により送信する。次いで、オラクルは、次の方法で乱数R_Nを生成する。

[0088] ステップ1. オラクル は、Sig P_i’を構成し、それが各プレーヤのSig P_iと同じエンティティに対応することを検証する。

[0089] この第2署名は、DER（distinguished encoding rules）規格を使用して、公開値r_i’を秘密値s_i’と連結することによって構成される。オラクルは、標準的なECDSA署名検証アルゴリズムを、双方の署名に適用し、それらが公開鍵P_iの所有者によって共通に署名されていたことを確認する。これは、所与の値r_i’に対して各自自身の署名を提供することによって、他者が乱数に影響を及ぼすことができないことを保証する。

[0090] ステップ2. オラクルは、次のようにしてR_Nを計算する。

[0091] これは、ECCの秘密鍵から公開鍵を生成する一方向プロセスとの、一方向ハッシュ関数の類推に起因して、ハッシュ方法で説明したのと同じ特性を継承する。

[0092] Y_i→P_i及びX_i→s_i’という置換は、第1方法と第2方法の間で類似性をもたらす。

[0093] 乱数R_Nは、ハッシュ方法と同様に、関与する誰にも予測不可能であって検証可能な方法で生成される。署名方法とハッシュ方法は互いに直接的に類似しており、乱数生成に関するそれぞれの方法の本質的な性質を共有していることは、明らかにされておくべきである。

特に、両方法は、ハッシュ及び署名方法それぞれに関してシークレット値；X_i及びs_i’を生成する責任があることを、各ユーザーに要求する。ここで、署名方法を使用する主な利点は、シークレットを選ぶ行為がECDSA手続きの下で既に標準化されているが、任意のハッシュ・プリ・イメージを選ぶことはそうではない、ということである。

[0094] また、署名方法では、オラクルに送られたシークレット値s_i’が、対応する公開値の元の提案者によって提供されていることを、それに付随するプライマリ署名Sig P_i=(r_i,s_i)と比較することによって、直接的に検証する方法もある。この検証は、ハッシュ法における暗黙的なものにすぎない。

[0095] 何れの形態においても、乱数R_Nは、予測不可能であって且つ決定論的であるという要件を満たしている。乱数はまた検証可能であり、これは、R_Nが正しい方法で生成されていることを、全てのネットワーク・ピアが独立に検証する方法が必要であることを意する。これは、R_Nそれ自体が計算され、トランザクションのロッキング・スクリプトで使用されることを要求することによって達成される。

[0096] このようにして、以前の全てのシークレット値si’は、このスクリプトの一部としてブロックチェーン上で公開され、これは、誰でもハッシュ関数Σ_is_i’の入力プリ・イメージを構築することによって、乱数を検証できることを意味する。

[0097] 以下のスクリプトは、ランダム整数R_N∈{0,N-1}を生成するために使用されてもよい。

ここでは、オペレータ‘OP_ADD’のN-1人のユーザーとN個のシークレット値が存在する。

[0098] このスクリプトは、ハッシュ・プリ・イメージ、部分的な署名、及びこれらの組み合わせ、を含む一般化されたシークレット値に使用できることに留意されたい。

[0099] トランザクションの完全な償還スクリプトは、各プリ・イメージが正しいコミット済みハッシュに対応していること、各々のシークレット署名コンポーネントが公開コンポーネントと組み合わせられて、期待される署名を形成していること、及び、各々の提供された値が正しいプレーヤから到来していること、を検証することを含む可能性がある。

[0100] 第3方法：組み合わせ方法
上記に提示した方法は、生成された乱数の結果に影響を与えようとする悪意のある者に対してロバストである。しかしながら、生成された乱数のセキュリティと予測不可能性を改善するために、ハッシュ方法と署名方法を拡張して組み合わせる多くの方法が存在する。

[0101] 2つの方法の最も単純な組み合わせは、各プレーヤがハッシュ値Y_iと、署名Sig P_iと、ランダム値r_i’と、それらの公開鍵P_iを公表することであろう。オラクルは、次のようにしてランダム値を生成することができる。

ここで、各プレーヤは、セカンダリ署名Sig P_i’=(r_i’,s_i’)もプライベートに計算している。ここでの追加演算子‘+’は、別の実装では、連結やXORのような別の演算子によって置き換えられる可能性があることに留意されたい。

[0102] 図6は、乱数R_Nを生成するためのスクリプト<R_N>の例示的な実行フローを示す。

[0103] 2つの方法のうちの1つを個別に拡張するために、複数のオラクルが使用されてもよく、プレーヤはそれぞれ、複数のハッシュ値Y_i又はセカンダリ値r_i’を提供してもよい。例えば、ハッシュ方法を使用する2つのオラクルがある場合、乱数RNは、次のようにして計算されてもよい。

ここで、第1のオラクルは、第1セットのプリ・イメージX_i,1の合計を第2のオラクルへ送信し、第2のオラクルはそれを第2セットのプリ・イメージの合計に加算して乱数を計算する。
複数のオラクルを使用することによって、悪意のあるユーザーによって何らかの方法で悪影響を受けたオラクルによるリスクは排除される。これを多数のオラクルへ拡張することは、より多くの計算や時間的なオーバーヘッドを犠牲にして、全てのオラクルが共謀するリスクを減らす。乱数が安全に且つ予測不可能に生成されるためには、ただ一つのオラクルが真正であることを必要とする。

[0104] ブロックチェーンを用いるプロバブリー・フェアー・ゲーム
‘プロバブリー・フェアー（provably fair）’という用語は、ゲームの文献で広く使われるようになったが、十分には定義されていない。文献上、正式な定義に乏しい状況の下で、本件では、プロバブリー・フェアー・ゲームをチェーン上で実施することを議論する際に、以下の定義を使用する。

[0105] 定義1：厳格でない証明可能な公正さ
開始及び終了状態はチェーン上に存在するが（オン・チェーン）、中間状態遷移を定義するロジックはチェーン外に存在する（オフ・チェーン）ことが可能であり、それは例えば、信頼された（監査可能な）オラクルによって実装される。オフ・チェーンの監査済みロジックを適用するだけで、初期状態が最終状態に至ることができるならば、そのゲームはプロバブリー・フェアーである。

[0106] 定義2：厳格な証明可能な公正さ
事実上、全てのゲーム・ロジックは、プロバブリー・フェアーなオン・チェーンであるように示され、各々の状態遷移は、例えばブロックチェーン・スクリプト言語を用いて、チェーン上で実装され、証明され、実施される。

[0107] ゲーム要素のキー・ベース表現
本件で使用されるように、“ゲーム要素”という用語は、ゲームの結果を少なくとも部分的に決定するゲームの性質に言及するために使用される。例えば、ポーカー、ブラックジャック、ラミー（rummy）等のカードのゲームでは、ゲーム要素はトランプである。ルーレットのゲームでは、ゲーム要素は、ルーレット・ホイールを構成する数字である。スロット・マシンでは、ゲーム要素は、スロット・マシン・リールのシンボルである。当業者は、任意の特定のゲームのどの特徴が“ゲーム要素”であると考えられるかを理解するであろう。

[0108] 本開示は、ゲームのゲーム要素を、キーとして、例えば暗号化の秘密鍵－公開鍵のペアとしてエンコードするメカニズムを提供する。以下の実施例は、トランプをエンコードするための技術を説明するが、同じ技術が他のタイプのゲーム要素に適用されてもよいことは理解されるであろう。

[0109] ほとんどのカード・ゲームでは、特定のゲームの結果は、各プレーヤに属するカードのセット又は‘ハンド（hand）’によって決定される。カードのハンド（役）の質は、ゲーム依存性であり、プレーヤ（達）にとって公知であるゲームのルール又はロジックによって決定されることになる。従って、特定のゲームの勝者（達）は、ゲームのルールに従って、カードの最良の「ハンド」を持っているプレーヤ（達）となる傾向がある。

[0110] 標準的なトランプ一組は、52枚の固有のカードのセットであり、4つの異なるスーツ（suits）－ダイヤ(D)、クラブ(C)、ハート(H)、スペード(S)－により形成され、それら各々は2, 3, 4,..., 10, J, Q, K, Aの値を含む。従って、カード一組は、52枚の固有の要素を有する集合Dとして取り扱うことができる：

[0111] 問題とするゲームに応じて、プレーヤのハンドは、これらの要素のうちの1つ以上の組み合わせを含み、それは単にDのサブ・セットである。一般に、所与のハンドの中にあるカードの順序という概念はなく、従って、カードの順列ではなく組み合わせのみに関連があることに留意されたい。そのようなハンド（hand）hの例は、次のようなものである：

hand: h = {AD, AC, AH, KD, KS}
これは、ポーカーのようなゲームで最強のハンド（即ち、‘フル・ハウス’）に対応する。

[0112] ‘ハンド’の概念は、ランダムなキー・ペアのセットを、デッキ（deck）D（一組のトランプ）内の各カードに割り当てることによって、マルチ・プレーヤ・カード・ゲームで利用することができる。ECCキー・ペアのような非対称キー・ペアを選択することによって、カード一組を表す、データ・アイテムの2つの新しいのセットを生成することができ、それらは、秘密鍵の集合Sと対応する公開鍵の集合Pである：

[0113] 秘密－公開鍵ペアは、デッキ内の各カードが固有の鍵ペアによって表現されるように生成される。

[0114] トランプ一組にマッピングされる関連する秘密及び公開データのこれらのセットを使用して、ハンドの固有の表現を、コンパクトで効率的な方法で構築することができる。例えば、上記から、ハンドhは、Dのうちの5要素のサブ・セットではなく、単一の秘密鍵又は単一の公開鍵の何れかを使用して表現されることが可能である：

ここで、二項演算子‘（+）’（円の中に+があるもの）は、楕円曲線点加算を表現し、演算子‘+’は加算を表現する。

[0115] このようにしてカードのハンドを表現することには、多くの利点がある。第1に、固有の表現が、公開データ（即ち、公開鍵）、秘密データ（即ち、秘密鍵）、又は2つの混合の何れかから生成されることが可能である。これは、カード・ゲームの可視性を維持するような方法で、ウィニング・ハンド（winning hands）を生成することを可能にする。例えば、テーブルの中央にある3つのフェース・アップ・カードと、プレーヤに属する2つのフェース・ダウン・カードの組み合わせとして、ポーカーのハンドが生成されるのと同じ方法で、上記のハンドP_hを、3つの‘公開’鍵と2つの‘秘密’鍵から生成することができる。この場合、3つのパブリックにビジブルな鍵はそれぞれカードA_D、K_D、K_Sを表現するP_AD、P_KD、P_KSとすることが可能である一方、1人のプレーヤに対してプライベートにビジブルな秘密鍵はそれぞれA_C、K_Sを表現するS_AC、S_KSとすることが可能である。次に、以下に示すように、プレーヤのハンドにある2つのフェース・ダウン・カードを開示する必要性なしに、ハンドは、1つの公開鍵で公に表現されることが可能である：

[0116] 第2に、秘密－公開鍵ペアの準同型加法構造（homomorphic, additive structure）を用いることによって、ハンドは、よりコンパクトに表現されることが可能である。即ち、n枚のカードを含むハンドは、y個の秘密鍵（即ち、y×256ビットのデータ）又はz個の公開鍵（即ち、z×33バイトのデータ）の何れかを含み、ここで、y+z=nであり、単一の秘密鍵s_h又は単一の公開鍵p_hは、それぞれ256ビット又は33バイトのデータのみを含む。

[0117] 第3に、カードのハンド全体を表現する鍵に、資金を送るロッキング・スクリプトを構築することができ、その結果、スクリプトは、ウィニング・ハンドの知識を完全に証明することを、資金使用者に要求する。プレーヤがフェース・ダウン・カードを有するゲームでは、そのようなスクリプトを使用してロックされた資金は、自分のカードに対応するキーを知っている正当な勝者によってのみ償還される。

[0118] カード以外の他のゲームにも同じ教示内容が適用される可能性がある。例えば、サイコロの面のそれぞれが、個々の秘密－公開鍵ペアによって表現されてもよい。6面サイコロは、次の集合にマッピングされてもよい：

[0119] 1つのサイコロの複数ロールの結果に依存するゲーム、例えばクラップス（craps）では、組み合わされた結果が1つのキーで表現される。例示的な具体例として、クラップスのゲームは、プレーヤが2つのサイコロを振ることを含み、ゲームの結果は、出目の合計スコアに依存する。合計スコアは、公開鍵P_score：

[0120] 同様のマッピングは、スロット・マシンのシンボルに対して構成されてもよい。スロット・マシンは、少なくとも1つのリールを含むが、より典型的には、3つ又は5つのリールを含む。各リールは、複数のシンボル、例えば22シンボルを含む。従って、各リール上のシンボルは、1組の公開－秘密鍵ペアによって表されてもよく、各々の可能な結果（即ち、各リールからのシンボルの組み合わせ）が、単一の秘密鍵又は公開鍵によって表現されることを可能にする。

[0121] ゲーム要素のオン・チェーン選択
多くのゲーム、特に偶然のゲームは、ある程度、ランダムな選択やゲーム要素の結果に依存している。例えば、トランプのゲーム（例えば、ポーカー）では、個々のプレーヤに対して私的に、又は全てのプレーヤに対して公に、各自のカードが、典型的にはシャッフルされたデッキのトップから引かれ、デッキのシャッフルは、引かれるカードにランダム性を導入する。同様に、ルーレット・ゲームの結果は、ルーレット・ボールとルーレット・ホイールとの間のランダムな相互作用に依存し、その結果、ボールはホイール上の予測不可能な位置（即ち、数）に着地する。また、ダイス・ゲームは、サイコロとサイコロが振られる表面との間のランダムな相互作用に依存する。

[0122] 本開示は、プロバブリー・フェアー・ゲームを可能にするために、ゲーム要素がチェーン上でランダム化され得ることを認めている。各ゲーム要素は、それぞれの公開鍵によって表現される。ロッキング・スクリプトは、プレイされるゲームの特定のゲーム要素を表現するために要求される公開鍵のセットを含むように構成され、ランダム・シードは、“乱数生成”の下で前述の方法の1つに従って生成されることが可能なものであり、公開鍵のうちの1つを、ウィニング公開鍵としてランダムに選択するために使用される。

[0123] <P_k=0>で示される以下のランダム化スクリプトは、N個の公開鍵P_iのセットからランダムに公開鍵を選択するために使用され、各々の公開鍵P_iは個々のゲーム要素を表現している。ランダム化スクリプトは、乱数によりシード設定され、例えば、以前に提示されたスクリプト<R_N>は、その場で乱数を計算する。

ここで、オペレータ‘OP_DROP’の(N-1)ユーザーとN 個の公開鍵が存在する。

[0124] オペコードOP_ROLLは、オペコードに先行する番号に等しいスタック上の位置にあるアイテムを、スタックのトップに移動させる。例えば、オペコードOP_ROLLが数3に続く場合、スタックの3番目のアイテムがスタックのトップに移動させられる。

[0125] 従って、公開鍵のセットは、サブ・スクリプト<R_N>によって生成された値に従って操作される。このスクリプトは、ランダムな公開鍵、従ってランダムなゲーム要素が、ゲームで使用するために選択されることを可能にする。例えば、ランダムに選択されたゲーム要素は、ルーレット・ホイールの当たり結果であってもよい。

[0126] 図7は、ウィニング公開鍵を選択するためのスクリプト<P_k=0>の実行フロー例を示す。この場合、ゲーム・トランザクション（後述）の出力スクリプトは、償還トランザクション（後述）のインプット・スクリプトと共に実行され、インプット・スクリプトは、ウィニング公開鍵に対応する署名を含む。

[0127] ここで、本開示の実施形態を図5を参照しながら説明する。図5は、ゲームをプレイするためのシステムを示す。一般に、ゲームは、任意数のN人のユーザー501（即ち、プレーヤ）によりプレイされる可能性があり、各ユーザー501が各自のコンピュータ機器を操作するが、図5では図示の便宜上単独のユーザーしか示されていない。ゲームは、ゲーム・オラクル502、即ちゲームのプレーヤではない第三者、によって実施される。ゲーム・オラクルは、スマート・コントラクト又は自律エージェントであってもよい。例えば、ゲーム・オラクルは、ゲーム・オラクルに帰属するアクションを実施するように構成されるコンピュータ・プロトコルであってもよい。ゲーム・オラクル502は個々のコンピュータ装置を操作することができる。図5はオラクル502を示しており、オラクルは、ユーザー501からユーザー・シードを取得し、コミットメント・トランザクションとゲーム・トランザクションを、ブロックチェーン150に含めるためにブロックチェーン・ネットワーク106へ送信する。また、図5は、ユーザー501が、ウィニング償還トランザクションを、ブロックチェーン・ネットワーク106へ送信していることを示す。前述のトランザクションは以下で説明される。

[0128] 各ユーザー501とゲーム・オラクル502（該当する場合）のコンピュータ装置は、1つ以上のプロセッサ、例えば1つ以上のCPU、GPU、その他のアクセラレータ・プロセッサ、アプリケーション固有のプロセッサ、及び/又はFPGA、を含む各自の処理装置を有する。各ユーザー501とゲーム・オラクル502のコンピュータ装置は、更に、メモリ、即ち、非一時的なコンピュータ読み取り可能な媒体又はメディアの形態のコンピュータ読み取り可能な記憶装置を備える。このメモリは、1つ以上の記憶媒体、例えば、ハード・ディスクのような磁気媒体；SSD、フラッシュ・メモリ又はEEPROMのような電子媒体；及び/又は光学ディスク・ドライブのような光学媒体を使用する1つ以上のメモリ・ユニットを含む可能性がある。各ユーザー501とゲーム・オラクル502のコンピュータ装置におけるメモリは、処理装置上で動作するように配置された少なくとも1つのクライアント・アプリケーションのそれぞれのインスタンスを含むソフトウェアを記憶する。本件において所与のユーザー501又はゲーム・オラクル502に帰属する如何なる動作も、それぞれのコンピュータ装置の処理装置上で実行されるソフトウェアを使用して実行されてもよいことが理解されよう。各ユーザー501のコンピュータ装置は、少なくとも1つのユーザー端末、例えばデスクトップ又はラップトップ・コンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブル・デバイスを含む。所与のユーザー501又はゲーム・オラクル502のコンピュータ装置は、ユーザー端末を介してアクセスされるクラウド・コンピューティング・リソースのような、1つ以上の他のネットワーク化されたリソースを含んでもよい。クライアント・アプリケーション又はソフトウェアは、当初に、所与の任意のユーザー501又はゲーム・オラクル502に対して、適切なコンピュータ読取可能な記憶媒体又はメディアに、例えばサーバーからダウンロードされたり、又はリムーバブルSSDのようなリムーバブル・ストレージ・デバイス、フラッシュ・メモリ・キー、リムーバブルEEPROM、リムーバブル磁気ディスク・ドライブ、磁気フロッピー・ディスク又はテープ、CD又はDVD ROMのような光ディスク、又はリムーバブル光学ドライブに提供されたりしてもよい。

[0129] ここでは別々に説明されているが、ユーザー501は、図1ないし図3で説明されたものと同じユーザー103であってもよいことに留意されたい。

[0130] 幾つかの例では、ユーザー501（即ち、ユーザーのコンピュータ装置）は、ブロックチェーン150に対してトランザクションを生成及び/又は送信することができる。更に、ユーザーのコンピュータ装置は、ブロックチェーン150からトランザクションを読み込むことができる。一般に、ユーザー501は、図1ないし図3を参照して説明したように、アリス103a及び/又はボブ103bに帰属する何らかのアクションを実行してもよい。

[0131] 同様に、ゲーム・オラクル502のコンピュータ装置は、トランザクションをブロックチェーン150から読み込み、トランザクションをブロックチェーン150へ送信するように構成される。

[0132] ユーザー501は、ユーザー・シードと呼ばれるそれぞれのデータ・アイテムを生成する。ユーザー・シードは、上記のように乱数を生成するための第1、第2又は第3方法のうちの何れに従って生成されてもよい。例えば、ユーザー・シードは、それぞれのハッシュ又はデジタル署名のそれぞれのコンポーネントであってもよい。幾つかの例では、ゲーム・オラクル502は、以下でオラクル・シードと呼ばれるシード・データ・アイテムも生成する。

[0133] ゲーム・オラクル502は、ユーザー・シード（又はそのハッシュ）を取得する。ゲーム・オラクル502は、ユーザー・シード（又はそのハッシュ）を、例えば（安全な）通信チャネルを介して、各ユーザー501から直接的に取得してもよい。代替的に、ユーザーは、例えばウェブサイト上で、又はブロックチェーン150に対して、彼らのユーザー・シード（又はそのハッシュ）を公表することができる。即ち、ユーザー・シード（又はそのハッシュ）は、ユーザー501又はゲーム・オラクル502によってブロックチェーン150に送信されるブロックチェーン・トランザクションに含まれてもよい。例えば、ユーザー501は、トランザクション（以下、コミット・トランザクションと言及される）にインプット（及びオプションとして、アウトプット）を追加することができ、ユーザー・シード（又はそのハッシュ）は、ユーザーがコミット・トランザクションに追加したインプット及び/又はアウトプットに含まれる。

[0134] オラクルがオラクル・シードも提供する例では、オラクル502は、オラクル・シード（又はそのハッシュ）を含むコミットメント・トランザクションを生成し、次いでコミットメント・トランザクションをユーザー501へに送信することができる。ユーザーは、次いで、そのユーザー・シード（又はそのハッシュ）をコミットメント・トランザクションに追加し、各自のデジタル署名で各自のインプットに署名する。ユーザーが各自のインプットを加えると、オラクル502はコミットメント・トランザクション全体に署名し、コミットメント・トランザクションをブロックチェーン・ネットワーク106へ送信することができる。この意味において、オラクル502は、以後にユーザー501へ送信される部分的なコミットメント・トランザクションを生成することができる。

[0135] ゲーム・オラクル502は、公開鍵のシーケンスを取得する。各々の公開鍵は、それぞれのゲーム要素を表現する。ゲーム要素の公開鍵としての表現は上述したとおりである。ゲーム・オラクル502は、公開鍵のシーケンスを生成することができる。代替的に、ユーザー501は、1つ以上の公開鍵を生成することができ、ゲーム・オラクル502も必要に応じて残りの公開鍵を生成する。例えば、ユーザー501は、ウィニング・ゲーム要素であろうと彼らが予想したゲーム要素、例えばウィニング・ゲーム要素であることにユーザー501が賭けているゲーム要素、に対応する公開鍵を提供することができる。

[0136] 幾つかの例では、オラクル502は、各々の公開鍵をそれぞれのゲーム要素にマッピングし、そのマッピングを公開することができる。他の例では、オラクル502は、ハッシュ関数をマッピングに適用してマッピング・ハッシュ（mapping hash）を生成し、次いで、そのマッピング・ハッシュを公表することができる。マッピング又はマッピング・ハッシュを公表することは、マッピング又はマッピング・ハッシュをユーザー501へ送信することを含んでもよい。別の例として、オラクルは、トランザクション、例えばコミットメント・トランザクションにおけるマッピング又はマッピング・ハッシュを含んでもよい。好ましくは、マッピング及びオラクル・シード（又はそれらのハッシュ）は、ユーザーが彼らのユーザー・シードを提供する前に、ユーザー502に知られている。

[0137] ゲーム・オラクル502がシード・データ・アイテム（又はそのハッシュ）と公開鍵のシーケンスとを取得した場合、ゲーム・オラクル502は、ゲーム・トランザクションを生成する。ゲーム・トランザクションは、アウトプット・スクリプトを含む少なくとも1つのアウトプットを有する。アウトプット・スクリプトは、シード・データ・アイテム（又はそのハッシュ）のセットに基づいて擬似乱数を生成するためのスクリプトの一部及び公開鍵のシーケンスを含む。幾つかの例では、擬似乱数は、ゲーム・トランザクションの前に生成され、アウトプット・スクリプトに配置される（この場合、擬似乱数を生成するためのスクリプトの部分は、単に擬似乱数であることに留意されたい）。しかしながら、スクリプトの部分は、シード・データ・アイテムのセット（又はハッシュのセット）を含み、スクリプトにおいて擬似乱数を生成することが好ましい。ゲーム・トランザクションは、コミットメント・トランザクションのアウトプットを消費する可能性がある。

[0138] スクリプトにおける擬似乱数の生成は、上記で一般的に説明されている。アウトプット・スクリプトは、シード・データ・アイテム（又はハッシュ）のセットを組み合わせ（例えば、合計）し、その組み合わせのハッシュをとることができる。次いでに、組み合わせのハッシュ（以下、ハッシュ結果と呼ぶ）は、擬似乱数として使用するための数にマッピングされ、マッピングは、公開鍵によって表現されるゲーム要素の総数、即ち、公開鍵のシーケンスにおける公開鍵の総数、
に基づいている。マッピングを実装する方法の1つは、ハッシュ結果に対してモジュロ演算を実行することであり、モジュロ演算を実行することは、ハッシュ結果についての余り（modulus）をとるために公開鍵の総数を使用する。

[0139] 同様に、公開鍵のシーケンスからの公開鍵の選択は、上記に説明されている。アウトプット・スクリプトは、乱数を使用して、公開鍵のシーケンス内の公開鍵の1つを選択し、従って、選択された公開鍵によって表現されるゲーム要素は擬似ランダムに選択される。

[0140] ゲーム・トランザクションのアウトプットは、選択された公開鍵（ウィニング開鍵）にロックされることが可能である。即ち、ゲーム・トランザクションのアウトプットをアンロックするためには、ウィニング公開鍵に対応する秘密鍵の知識が要求される。ユーザーがウィニング公開鍵を生成している例（即ち、ユーザー501が特定のゲーム要素を表現するための公開鍵を提供しており、その公開鍵がウィニング公開鍵として選択されている例）では、ユーザー501は既に秘密鍵に対するアクセスを有しており、従って、ゲーム・トランザクションのアウトプットをロック解除することができる。オラクルがウィニング公開鍵を生成した例（即ち、オラクル502が、ウィニング公開鍵として以後に選択された公開鍵を生成していた例）では、オラクル502は、ゲームをプレイする1人以上のユーザー501へ秘密鍵を送信することができる。

[0141] 幾つかの例では、ゲーム・トランザクションのアウトプットは、ウィニング公開鍵に依存する公開鍵の幾つかのセットのうちの1つにロックされる可能性がある。即ち、第1公開鍵がウィニング公開鍵として選択された場合に、アウトプットは、公開鍵の第1セット（1つの公開鍵又は複数の公開鍵であってもよい）にロックされてもよく、別の第2公開鍵がウィニング公開鍵として選択された場合に、アウトプットは、公開鍵の第2セット（1つの公開鍵又は複数の公開鍵であってもよい）にロックされてもよい。公開鍵の第1セットは、ユーザー公開鍵のセット、即ち、ユーザーが、対応する秘密鍵へのアクセスを有する公開鍵であってもよい。公開鍵の第2セットは、オラクル公開鍵のセット、即ち、オラクル502が、対応する秘密鍵へのアクセスを有する公開鍵であってもよい。

[0142] 幾つかの例において、ゲームの結果は、1つより多いゲーム要素に基づいて決定されてもよい。例えば、スロット・マシンでは、ゲームの結果は、典型的には、複数のリール上のそれぞれのシンボルに依存する。このようなゲームの場合、オラクルは、ゲーム要素の各セットについて、公開鍵のシーケンスを取得してもよい。公開鍵の2つ以上のシーケンスは、同一のゲーム要素を表現してもよい（例えば、スロット・マシン上の2つのリールは、同一のシンボルから構成されてもよい）。代替的に、公開鍵の各シーケンスは、異なるゲーム要素を表現してもよい（例えば、1つのシーケンスは数字のセットを表現し、1つのシーケンスは色のセットを表現してもよい）。ゲーム要素のセット数にかかわらず、公開鍵の対応するシーケンスの各々は、同一のゲーム要素を表現する複数の公開鍵を含んでいてもよく、換言すれば、所与のゲーム要素が、1つより多い公開鍵（同一の公開鍵であってもなくてもよい）によって表現されてもよい。

[0143] オラクルは、公開鍵の各シーケンスから1つずつ、複数のウィニング公開鍵を選択するようにゲーム・トランザクションが構成されるように、それを生成することができる。即ち、アウトプット・スクリプトは、複数の擬似乱数を生成するように構成され、各々は、同じセットのシード・データ・アイテムに基づいて生成される。次いで、各々の擬似乱数は、公開鍵の各シーケンスから公開鍵を選択するために使用される。

[0144] 幾つかの例では、オラクルは、ゲーム・トランザクションを生成することに先立って、複数の擬似乱数を生成し、複数の擬似乱数をゲーム・トランザクションのアウトプットに挿入する。しかしながら、好ましくは、擬似乱数はスクリプトで生成される。スクリプトで1つの擬似乱数を生成するために使用されたのと同じ技術が、1つ以上の追加の擬似乱数を生成するために、1回以上追加的に使用されることが可能である。即ち、第1乱数を生成するために、アウトプット・スクリプトは、シード・データ・アイテム（又はハッシュ）のセットを組み合わせ（例えば、合計し）、組み合わせたものに第1ハッシュ関数を適用することができる。次いで、組み合わせのハッシュ（以下、第1ハッシュ結果と称する）が、第1擬似乱数として使用するための数にマッピングされ、マッピングは、公開鍵の第1シーケンスによって表現されるゲーム要素の総数、換言すれば、公開鍵の第1シーケンスにおける公開鍵の総数、に基づいている。第2擬似乱数を生成するために、アウトプット・スクリプトは、シード・データ・アイテム（又はハッシュ）のセットを組み合わせ（例えば、合計し）、組み合わせたものに第2ハッシュ関数を適用することができる。次いで、組み合わせのハッシュ（以下、第2ハッシュ結果と称する）が、第2擬似乱数として使用するための数にマッピングされ、マッピングは、公開鍵の第2シーケンスによって表現されるゲーム要素の総数、換言すれば、公開鍵の第2シーケンスにおける公開鍵の総数、に基づいている。第1及び第2ハッシュ関数は、同じハッシュ関数又は異なるハッシュ関数であってもよい。ここで、異なるハッシュ関数は、同じハッシュ関数を複数回適用するものであってもよい。

[0145] 第1ウィニング公開鍵を選択するための同じ技術が、1つ以上の追加のウィニング公開鍵を選択するために使用される。即ち、ゲーム・トランザクションは、公開鍵の各シーケンスと、対応する擬似乱数に基づいて各シーケンスから公開鍵を選択するために使用されるスクリプトの対応する部分とを含む。即ち、ウィニング公開鍵は、第1擬似乱数に基づいて公開鍵の第1シーケンスから選択され、ウィニング公開鍵は、第2擬似乱数に基づいて公開鍵の第2シーケンスから選択される、等々である
[0146] ゲーム・トランザクションのアウトプット・スクリプトは、選択されたウィニング公開鍵に基づいて、アウトプットを1つ以上の公開鍵にロックすることができる。即ち、ゲーム・トランザクションのアウトプットは、ウィニング公開鍵に依存して公開鍵のセットにロックされることが可能である。即ち、1つ以上の予測された公開鍵がウィニング公開鍵として選択される場合、アウトプットは、1つ以上のユーザー公開鍵（対応する秘密鍵をユーザーが有するか又は送信される公開鍵）にロックされてもよい。アウトプット・スクリプトは、償還トランザクションのインプットが、1つ以上の所定の公開鍵に対応する秘密鍵を使用して生成された署名を含むこと、をチェックすることができる。アウトプット・スクリプトは、マルチ署名アウトプットであってもよく、即ち、償還トランザクションのインプットは、予測された公開鍵に対応するそれぞれの秘密鍵によって生成される所定の数の署名を含まなければならない。予測された公開鍵は、ユーザー501によってオラクル502へ提供されてもよく、又はユーザー501は、所定の公開鍵を生成するオラクルのために、予測されたゲーム要素をオラクルに提供してもよい。

[0147] 一方、1つ以上の予測された公開鍵がウィニング公開鍵として選択されていない場合、アウトプットは、1つ以上のユーザー公開鍵に対応する秘密鍵によってロック解除することはできない。例えば、アウトプットは、公開鍵の異なるセット（例えば、オラクルの公開鍵）にロックされてもよい。

[0148] ユース・ケース例
ユース・ケース1：プロバブリー・フェアー・スロット・マシン
以下、ブロックチェーンにおいてプロバブリー・フェアー・スロット・マシンを実現するためのプロセスをステップ毎に説明する。ロッキング・スクリプトは、1つのリール・スロット・マシンをモデル化しており、2つの公開鍵（プレイヤーとハウスに属するもの）だけが仮想リールに現れる。これは、スクリプト内のスロットのゲーム・ロジックを説明するための単純化されたモデルであることに留意されたい。実際のオンライン・スロットは、以下の最初の例で示される50：50よりも複雑なウィニング・オッズ及び多くのシンボルを有しており、この点については後の例で更に発展される。

[0149] プロセス：
1. オラクルは、部分的に完成したコミットメント・トランザクションTx_Commit内のオラクル・シードのハッシュ・ダイジェストH(X₀)をコミットする。

2. ユーザーは、賭け金xとユーザー・シードのハッシュ・ダイジェストH(X₁)とを入力してトランザクションTx_Commitを完成させる。これは、ユーザーがオラクルのハッシュ・コミットを見たことをユーザーが確認し、それに署名することによってその事実を真正証明するという順序を保証する。代替的に、ユーザーは先ずそれらのシードを提供してもよい。各シードは、アンスペンダブル・アウトプット（例えば、OP_RETURNアウトプット）で提供されます。

3. ハウスSig P₀とプレーヤSig P₁の双方により署名されて真正証明されると、Tx_Commitはブロックチェーン上でマイニングされる。オラクルに対するユーザーのコミットメント・トランザクションは以下のように示される。この例では、オラクルからの第1インプットは、SIGHASH | ANYONECANPAYフラグを使用する一方、ユーザーからの第2インプットは、SIGHASHALLフラグを使用してトランザクションをファイナライズしてブロードキャストする。[0150]

4. ユーザーは、ユーザー・シード（プリイメージX₁）を安全なオフ・チェーン通信チャネルを介して、オラクルの擬似乱数発生器（PRNG）へに送信する。

5. オラクルは、上述のハッシュ方法に従って、オラクルとユーザー・シードの両方H(X₀ + X₁)を使用して、スクリプトにおいて乱数を計算する。この計算は一般化された形式で以下のように与えられる：

ここで、i = 0, 1,..., Nは、ハウス（i = 0）と各プレーヤ（i = 1,..., N）を通じて循環し、rはスロットの各リール上の位置（即ち、シンボル）の数に対応する。擬似乱数を生成する別の方法（例えば、署名方法又は組み合わせ方法）が使用されてもよい。

6. スロット・マシン・スピン・トランザクションTx_Spin（ゲーム・トランザクション）は、UTXOをTx_Commitから消費するオラクルによって設定される。スピン・トランザクションは、ゲーム要素を表現する公開鍵のシーケンスを含む（この単純化された例では、2つしかない）。

7. オラクルの資金は、Tx_Spinに対するセカンダリ・インプットとして追加される。

8. Tx_Spinのロッキング・スクリプトは、ゲーム・ロジックを含み、これは、r個の公開鍵で表現されるr個のシンボルのリストから、ウィニング・シンボルを選び出す。

[0151] Tx_Spinの簡単な例を以下に示す。ユーザーの公開鍵が乱数によって選ばれる場合、トータルの資金はその鍵に制約される。ユーザーの成功したスピンに続くウィニング償還トランザクションも、以下に示される。

[0152] 3リール・スロット
伝統的に、スロット・マシンは、3つ以上のリールを備えている。前のセクションにおけるシンプルな例は、k>1リールをモデル化するように拡張することが可能であり、その場合、トータルでk+1個の乱数が要求される。これは、オンライン・スロット・マシンは、典型的には、スピン、即ちスロット・マシンのプレーヤによるターン・オンを表現する乱数R_Nに加えて、リールごとに1つの固有の乱数を使用するからである。オラクルは、乱数をj回ハッシュすることによって、j番目のリールについて固有の乱数を生成することができる。従って、スピンを組み込んだk個のリール・スロットの一般的な計算は、次のように書くことができる：

[0153] 以下は、3リールのスロット・マシンに対するスピン・トランザクションTx_Spinを示し、この場合、ユーザーのウィニング結果は、各リールの仮想スピンから選び出された3つの合致するウィニング公開鍵に起因する。この例では、任意の公開鍵のセットP_a, P_b, P_c,..., P_zが、以下のスクリプトを使用して実行される各リールのシンボルを表現するために使用される。

[0154] また、ウィニング償還トランザクションも以下ように示される。

[0155] ウィニング・オッズ：
典型的な重み付けされたスロットは、各リールにおいて22個の実際のポジションを有する。32、64、128、256、512ストップを含む仮想リールでは、各々のポジション（ジャックポットを除く）は、1つより多いポジションにマッピングされることが多い。リールが全て同じ方法でセットされていると仮定すると、64ストップのバーチャル・リールの場合、ジャックポットを当てるオッズは、実際には64³、つまり262,144のうちの1回である。本件の実装は、これらのシンボルを表現するために公開鍵を使用するので、プレーヤは、ハウスがスピンの前にマッピングを公表しない限り、何個の鍵が同じシンボルにマッピングされているのかを知ることはできないであろう。Tx_Spinにおけるロッキング・スクリプトは、キーの任意のマッチング組み合わせに対して資金をプレーヤにリリースするので、オラクルは、選択したマッピングやウィニング・オッズを明らかにする必要なしに、仮想リールのオッズを、スクリプトで複製することができる。しかしながら、プレーヤがこの情報を要求した場合、ハウスは、サーバーとクライアントのシードと共に、コミットメント・トランザクションTx_Commitのヌル・データ・アウトプットにおけるマッピング<H(Mapping)>のハッシュ・ダイジェストを真正証明することができる。

[0156] ユーザーは、鍵生成プロセスに貢献することが可能であり、従って、r個の鍵のリストに関連する1つ以上の秘密鍵を所有することができる。この場合、ユーザーは、（例えば、簡略化された1リール・スロットの例に示されているように）償還トランザクションにおいて勝利した秘密_公開鍵ペアから導出される署名を簡単に提供することができる。3リール・スロットのユース・ケースの場合、これは、TxSpinロッキング・スクリプトの2番目の部分における条件ステートメントを次のように変更ことになる：

[0157] プログレッシブ・ジャックポット：
スロット・マシンは、通常、オラクルに対してユーザーである。しかしながら、スロット又はカジノのネットワークに渡る単一のジャックポットに全てがリンクされた異なるスロット・マシンで、N人のプレーヤがプレイすることができる。この場合、プレイの順序は、どの単一ユーザーがジャックポット全体を主張できるのかを決定するために重要である。前述のプロバブリー・フェアー方法を使用してこれを記録するために、各ユーザー・シードは、各プレーヤのインプットが全てのTx_Commitの中でブロックチェーンに対して常に連続的に真正証明されるように、全ての以前のユーザーのハッシュ・ダイジェストH(X₁||X₂||・・・||X_N)と連結されてもよい。新しいオラクル・シードX₀は常に生成され、ユーザーのインプットに加えられ、その結果、ハウスは各スピンの乱数生成に貢献することに留意されたい。ユーザーがジャックポットに当たると、ハッシュ・ダイジェストは、スクラッチからスタートするようにリフレッシュされることが可能である。

[0158] X-of-Yボーナス・スポット：
公開鍵のリストから選択されるX-of-Y公開鍵に関する賭けのコミットメントは、m-of-n Multisigを使用して行うことができる。この例では、ユーザーは自身の選択のシンボルを割り当てられた公開鍵を生成する。シンボルの当たりの組み合わせが選択された場合、ユーザーは、m-of-n Multisigを使用して資金をロック解除することができる。以下、例示的なスピン・トランザクションを示す。この場合において、3リールのスロット・マシンのスピンで選出される2-of-3 Paシンボルに関してユーザーが賭けを行う。

[0159] multisig要件は、一組の条件IF又はELSEステートメント内に含まれる一組のP2PKH（pay to public key hash, P2PKH）スクリプトから構築することも可能である。下記のロッキング・スクリプトは、以下のように最後のリール・スピンの後に実行されるであろう：

[0160] 上記のロッキング・スクリプトにおけるゲーム・ロジックのステップ毎の説明を行う：
1. 第1スタック・アイテムがP_aに等しいかどうかをチェックする。

a. yesである場合、第2スタック・アイテムがP_aに等しいかどうかをチェックする。

i. yesである場合、資金をP_aにロックする。

ii. noである場合、トップのスタック・アイテムを除去し、第3スタック・アイテムがP_aに等しいかどうかをチェックする。

1. yesである場合、資金をP_aにロックする。

2. noである場合、資金をハウスP₀にロックする。

b. noである場合、トップのスタック・アイテムを除去し、第2スタック・アイテムがP_aに等しいかどうかをチェックする。

i. yesである場合、第3スタック・アイテムがP_aに等しいかどうかをチェックする。

1. yesである場合、資金をP_aにロックする。

2. noである場合、資金をハウスP₀にロックする。

[0161] ユース・ケース2：プロバブリー・フェアー・ルーレット
この例では、ルーレット・ホイール上の37個のポジション（0-36の数字）が、37個の公開鍵にマッピングされる。このマッピングのハッシュ・ダイジェストは、コミットメント・トランザクションTx_Commitでチェーン上で公開されることが可能である。同じゲーム・ロジックは、上述のスロット・マシンの例にも適用されており、ユーザーは、ハウスに対してプレイし、仮想ルーレット・ホイールのスピンは、プロバブリー・フェアー乱数を用いて選択されるウィニング・ポジションを決定する。

[0162] ゲーム・ロジックの主な相違は、ルーレット・ホイールの周りでプレイするユーザーが、特定の結果、例えば、ウィニング・ポジションについての数字、数字の種々のグループ、数字が奇数か偶数か、高いか低いか、又は色（黒又は赤）に賭けることになる点にある。ウィニングのオッズは、これらのグルーピングに加えて、プレーヤの賭ける額に依存する。従って、スピン・トランザクションにおいてオラクルから拠出された資金は、これらのオッズを反映するために使用されることが可能である。プレーヤが数字7に賭けているスピン・トランザクションの例を以下に示す。

[0163] P₇が実際にウィニング・ポジションであるならば、資金は、プレーヤの署名<Sig(P₁)> <P₁>で簡単にロック解除することができる。しかしながら、プレーヤがP7の秘密鍵を所有している場合（及びオラクルが残りの全てのキーについてはの秘密鍵を所有している場合）、ロッキング・スクリプトは次のようにシンプルに書くことができる：

[0164] 例えば「奇数」のような数字のグループに賭けているユーザーは、彼らが奇数の公開鍵に関連する18個の秘密鍵のうちの1つを所有している場合、複数署名アドレスに制約されている資金を償還することができる：

[0165] P₁₁というウィニング・ポジションについては、上記のスピンのウィニング償還トランザクションは、以下のような形態をとるであろう： [0166]

[0167]
まとめ
上記の実施形態は、単なる例示として説明されていることが理解されるであろう。より一般的には、以下のステートメントのうちの任意の1つ以上に従う方法、装置又はプログラムを提供することが可能である。

[0168] ステートメント1.
ゲームをプレイする際に使用するウィニング・ゲーム要素を擬似ランダムに生成するコンピュータが実行する方法であって、前記ゲームは、前記ゲームの結果を決定するために使用される第1ゲーム要素のセットを含み、前記ゲームは現在のユーザーによってプレイされ、前記方法はオラクルにより実行され、前記方法は：
シード・データ・アイテムのセットを取得するステップであって、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含む、ステップ；
第1公開鍵のシーケンスを取得するステップであって、各々の第1公開鍵は前記第1ゲーム要素のセットのうちのそれぞれを表現している、ステップ；及び
ゲーム・トランザクションの第1アウトプットを生成するステップであって、前記第1アウトプットは少なくとも幾つかの第1公開鍵のシーケンスを含むアウトプット・スクリプトを含み、前記アウトプット・スクリプトは、実行されると、少なくとも1つの第1擬似乱数を生成し、少なくとも1つの第1ウィニング・キーを選択するように構成されており、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、少なくとも1つの第1ウィニング公開鍵は、前記少なくとも1つの第1擬似乱数に対応する前記第1公開鍵のシーケンス内の或る位置にある公開鍵である、ステップを含む。

[0169] ステートメント2.
ステートメント1の方法において、前記シード・データ・アイテムのセットは、前記オラクルにより生成されたオラクル・シード・データ・アイテムを含む。

[0170] ステートメント3.
ステートメント1又はステートメント2の方法において：
コミットメント・トランザクションを生成するステップであって、前記コミットメント・トランザクションは、前記オラクル・シード・データ・アイテムを含むブロックチェーン・トランザクションである、ステップ；及び
前記コミットメント・トランザクションを、前記個々のユーザーのうちの現在のユーザーへ送信するステップを含む。

[0171] ステートメント4.
ステートメント1又はステートメント2の方法において：
コミットメント・トランザクションを取得するステップであって、前記コミットメント・トランザクションは、前記現在のユーザーにより生成された前記ユーザー・シード・データ・アイテムを含む、ステップ；及び
前記コミットメント・トランザクションを、ブロックチェーンに含めるためにブロックチェーン・ネットワークへ送信するステップを含む。

[0172] ステートメント5.
ステートメント3又はステートメント4の方法において、前記ゲーム・トランザクションは、前記コミットメント・トランザクションの第1アウトプットをロック解除するように構成された第1インプットを含む。

[0173] ステートメント6.
ステートメント1ないし5のうちの何れかの方法において、前記第1擬似乱数は：
第1ハッシュ結果を生成するために、前記シード・データ・アイテムのセットの組み合わせに、第1ハッシュ関数を適用するステップ；及び
前記第1ゲーム要素のセットにおける第1ゲーム要素の総数に基づいて或る数に前記第1ハッシュ結果をマッピングするステップ；
により生成される。

[0174] ステートメント7.
ステートメント6の方法において、前記マッピングするステップは、前記第1総数を第1の法とする、前記第1ハッシュ結果の第1モジュロ演算を行うステップを含む。

[0175] ステートメント8.
上記のステートメントのうちの何れかの方法において：
公開鍵のシーケンスとそれら公開鍵により表現される個々の第1ゲーム要素とのマッピングにハッシュ関数を適用することによって、マッピング・ハッシュを生成するステップ；
前記マッピング・ハッシュを、少なくとも前記現在のユーザーに利用可能にするステップを含む。

[0176] ステートメント9.
ステートメント8の方法において、前記マッピング・ハッシュを利用可能にするステップは、前記ブロックチェーンに含めるためのトランザクションに、前記マッピング・ハッシュを含めることを含む。

[0177] ステートメント10.
上記のステートメントのうちの何れかの方法において、前記シード・データ・アイテムのセットを取得するステップは、前記個々のユーザー・シード・データ・アイテムを、個々のユーザーから取得するステップを含む。

[0178] ステートメント11.
上記のステートメントのうちの何れかの方法において、前記第1公開鍵のシーケンスを取得するステップは、1つ以上の第1公開鍵を、前記現在のユーザーから取得するステップを含む。

[0179] ステートメント12.
上記のステートメントのうちの何れかの方法において、前記第1アウトプット・スクリプトは、実行されると、前記第1アウトプットを前記第1ウィニング公開鍵にロックするように構成されている。

[0180] ステートメント13.
ステートメント13の方法において、前記ウィニング公開鍵に対応する秘密鍵を、前記現在のユーザーへ送信するステップを含む。

[0181] ステートメント14.
ステートメント1ないし12のうちの何れかの方法において、前記第1アウトプット・スクリプトは、実行されると、前記第1アウトプットを、a）前記現在のユーザーに関連付けられた1つ以上のユーザー公開鍵、又はb)前記オラクルに関連付けられたオラクル公開鍵にロックするように構成されており、前記第1アウトプットは、前記第1ウィニング公開鍵に基づいて、a）前記1つ以上のユーザー公開鍵、又はb)前記オラクル公開鍵にロックされる。

[0182] ステートメント15.
ステートメント1ないし11のうちの何れかの方法において、前記ゲームは、前記ゲームの前記結果を決定するために使用される第2ゲーム要素のセットを含み、前記方法は：
第2公開鍵のシーケンスを取得するステップであって、各々の第2公開鍵は前記第2ゲーム要素のセットのうちのそれぞれを表現している、ステップ；
を含み、前記アウトプット・スクリプトは、実行されると、第2擬似乱数を生成し、前記第2擬似乱数に対応する前記第2公開鍵のシーケンス内の或る位置にある公開鍵を、第2ウィニング公開鍵として選択するように構成されており、前記第2擬似乱数は前記シード・データ・アイテムのセットに基づいている。

[0183] ステートメント16.
ステートメント16の方法において、前記第2擬似乱数は：
第2ハッシュ結果を生成するために、前記シード・データ・アイテムのセットの組み合わせに、第2ハッシュ関数を適用するステップ；及び
前記第2ゲーム要素のセットにおける第2ゲーム要素の総数に基づいて或る数に前記第2ハッシュ結果をマッピングするステップ；
により生成される。

[0184] ステートメント17.
ステートメント16の方法において、前記第2ハッシュ結果をマッピングするステップは、前記第2総数を第2の法とする、前記第2ハッシュ結果の第2モジュロ演算を行うステップを含む。

[0185] ステートメント18.
ステートメント15ないし17のうちの何れかの方法において、前記第1アウトプット・スクリプトは、実行されると、前記第1アウトプットを、a）前記現在のユーザーに関連付けられた1つ以上のユーザー公開鍵、又はb)オラクル公開鍵にロックするように構成されており、前記第1アウトプットは、少なくとも前記第2ウィニング公開鍵に対応する前記第1ウィニング公開鍵に基づいて、a）前記1つ以上のユーザー公開鍵、又はb)前記オラクル公開鍵にロックされる。

[0186] ステートメント19.
ステートメント19の方法において、前記第1アウトプット・スクリプトは、a）1つ以上のユーザー公開鍵に前記第1アウトプットをロックするマルチ・シグネチャ・スクリプトを含む。

[0187] ステートメント20.
ステートメント1ないし20のうちの何れかの方法において、1つ以上の第1公開鍵は同じ第1ゲーム要素を表現し、及び／又は1つ以上の第2公開鍵は同じ第2ゲーム要素を表現している。

[0188] ステートメント21.
上記のステートメントのうちの何れかの方法において、前記ゲーム・トランザクションを、前記1人以上の個々のユーザー及び／又はブロックチェーン・ネットワークへ送信するステップを含む。

[0189] ステートメント22.
ブロックチェーンに含めるためのトランザクションであって：
前記トランザクションはアウトプットを含み、アウトプットは公開鍵のシーケンスを含み、各々の公開鍵はゲーム要素のセットのうちのそれぞれを表現し、前記アウトプット・スクリプトは、少なくとも1つの第1擬似乱数を生成するように構成されており、し、少なくとも1つの第1ウィニング・キーを選択するように構成されており、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含み、前記アウトプット・スクリプトは、少なくとも1つの第1ウィニング公開鍵を選択するように構成されており、少なくとも1つの第1ウィニング公開鍵は、前記少なくとも1つの第1擬似乱数に対応する前記第1公開鍵のシーケンス内の或る位置にある公開鍵である。

[0190] ステートメント23.
ステートメント22のトランザクションを格納したコンピュータ読み取り可能な記憶媒体。

[0191] ステートメント24.
コンピュータ装置であって：
1つ以上のメモリ・ユニットを含むメモリ；及び
1つ以上の処理ユニットを含む処理装置；
を含み、前記メモリは前記処理装置において動作するように構成されたコードを格納しており、前記コードは、前記処理装置において実行されると、ステートメント1ないし21のうちの何れかの方法を実行させるように構成されている。

[0192] ステートメント25.
コンピュータ読み取り可能な記憶媒体に組み込まれるコンピュータ・プログラムであって、ステートメント24のコンピュータ装置において実行されると、ステートメント1ないし21のうちの何れかの方法を実行させるように構成されているコンピュータ・プログラム。

[0193] 本件で開示された教示の別の態様によれば、オラクルとユーザーの動作を含む方法が提供されてもよい。

[0194] 本件で開示された教示の別の態様によれば、ユーザーとオラクルのコンピュータ装置を含むシステムが提供されてもよい。

[0195] 本件の開示が与えられれば、他の変形は当業者にとって明らかになるであろう。本開示の範囲は、開示された実施形態によっては限定されず、添付のクレームによってのみ限定される。

Claims (25)

1. ゲームをプレイする際に使用するウィニング・ゲーム要素を擬似ランダムに生成するコンピュータが実行する方法であって、前記ゲームは、前記ゲームの結果を決定するために使用される第1ゲーム要素のセットを含み、前記ゲームは1人以上の個々のユーザーによってプレイされ、前記方法はオラクルにより実行され、前記方法は：
   シード・データ・アイテムのセットを取得するステップであって、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含む、ステップ；
   第1公開鍵のシーケンスを取得するステップであって、各々の第1公開鍵は前記第1ゲーム要素のセットのうちのそれぞれを表現している、ステップ；
   ゲーム・トランザクションの第1アウトプットを生成するステップであって、前記ゲーム・トランザクションはブロックチェーン・トランザクションであり、前記第1アウトプットは少なくとも幾つかの第1公開鍵のシーケンスを含むアウトプット・スクリプトを含み、前記アウトプット・スクリプトは、実行されると、少なくとも1つの第1擬似乱数を生成し、少なくとも1つの第1ウィニング・キーを選択するように構成されており、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、少なくとも1つの第1ウィニング公開鍵は、前記少なくとも1つの第1擬似乱数に対応する前記第1公開鍵のシーケンス内の或る位置にある公開鍵である、ステップ；
   を含む方法。
2. 請求項1に記載の方法において、前記ゲーム・トランザクションを、前記1人以上の個々のユーザー及び／又はブロックチェーン・ネットワークへ送信するステップを更に含む、方法。
3. 請求項1又は請求項2に記載の方法において、前記シード・データ・アイテムのセットは、前記オラクルにより生成されたオラクル・シード・データ・アイテムを含む、方法。
4. 請求項1ないし3のうちの何れか一項に記載の方法において：
   コミットメント・トランザクションを生成するステップであって、前記コミットメント・トランザクションは、前記オラクル・シード・データ・アイテムを含むブロックチェーン・トランザクションである、ステップ；及び
   前記コミットメント・トランザクションを、前記個々のユーザーのうちの現在のユーザーへ送信するステップ；
   を含む方法。
5. 請求項1ないし3のうちの何れか一項に記載の方法において：
   コミットメント・トランザクションを取得するステップであって、前記コミットメント・トランザクションは、前記現在のユーザーにより生成された前記ユーザー・シード・データ・アイテムを含む、ステップ；及び
   前記コミットメント・トランザクションを、ブロックチェーンに含めるためにブロックチェーン・ネットワークへ送信するステップ；
   を含む方法。
6. 請求項4又は請求項5に記載の方法において、前記ゲーム・トランザクションは、前記コミットメント・トランザクションの第1アウトプットをロック解除するように構成された第1インプットを含む、方法。
7. 請求項1ないし6のうちの何れか一項に記載の方法において、前記第1擬似乱数は：
   第1ハッシュ結果を生成するために、前記シード・データ・アイテムのセットの組み合わせに、第1ハッシュ関数を適用するステップ；及び
   前記第1ゲーム要素のセットにおける第1ゲーム要素の総数に基づいて或る数に前記第1ハッシュ結果をマッピングするステップ；
   により生成される、方法。
8. 請求項7に記載の方法において、前記第1ハッシュ結果をマッピングするステップは、前記第1総数を第1の法とする、前記第1ハッシュ結果の第1モジュロ演算を行うステップを含む、方法。
9. 請求項1ないし8のうちの何れか一項に記載の方法において：
   公開鍵のシーケンスとそれら公開鍵により表現される個々の第1ゲーム要素とのマッピングにハッシュ関数を適用することによって、マッピング・ハッシュを生成するステップ；
   前記マッピング・ハッシュを、少なくとも前記現在のユーザーに利用可能にするステップ；
   を含む方法。
10. 請求項9に記載の方法において、前記マッピング・ハッシュを利用可能にするステップは、前記ブロックチェーンに含めるためのトランザクションに、前記マッピング・ハッシュを含めることを含む、方法。
11. 請求項1ないし10のうちの何れか一項に記載の方法において、前記シード・データ・アイテムのセットを取得するステップは、前記個々のユーザー・シード・データ・アイテムを、個々のユーザーから取得するステップを含む、方法。
12. 請求項1ないし11のうちの何れか一項に記載の方法において、前記第1公開鍵のシーケンスを取得するステップは、1つ以上の第1公開鍵を、前記現在のユーザーから取得するステップを含む、方法。
13. 請求項1ないし12のうちの何れか一項に記載の方法において、前記第1アウトプット・スクリプトは、実行されると、前記第1アウトプットを前記第1ウィニング公開鍵にロックするように構成されている、方法。
14. 請求項13に記載の方法において、前記ウィニング公開鍵に対応する秘密鍵を、前記現在のユーザーへ送信するステップを含む方法。
15. 請求項1ないし12のうちの何れか一項に記載の方法において、前記第1アウトプット・スクリプトは、実行されると、前記第1アウトプットを、a）前記現在のユーザーに関連付けられた1つ以上のユーザー公開鍵、又はb)前記オラクルに関連付けられたオラクル公開鍵にロックするように構成されており、前記第1アウトプットは、前記第1ウィニング公開鍵に基づいて、a）前記1つ以上のユーザー公開鍵、又はb)前記オラクル公開鍵にロックされる、方法。
16. 請求項1ないし12のうちの何れか一項に記載の方法において、前記ゲームは、前記ゲームの前記結果を決定するために使用される第2ゲーム要素のセットを含み、前記方法は：
    第2公開鍵のシーケンスを取得するステップであって、各々の第2公開鍵は前記第2ゲーム要素のセットのうちのそれぞれを表現している、ステップ；
    を含み、前記アウトプット・スクリプトは、実行されると、第2擬似乱数を生成し、前記第2擬似乱数に対応する前記第2公開鍵のシーケンス内の或る位置にある公開鍵を、第2ウィニング公開鍵として選択するように構成されており、前記第2擬似乱数は前記シード・データ・アイテムのセットに基づいている、方法。
17. 請求項16に記載の方法において、前記第2擬似乱数は：
    第2ハッシュ結果を生成するために、前記シード・データ・アイテムのセットの組み合わせに、第2ハッシュ関数を適用するステップ；及び
    前記第2ゲーム要素のセットにおける第2ゲーム要素の総数に基づいて或る数に前記第2ハッシュ結果をマッピングするステップ；
    により生成される、方法。
18. 請求項17に記載の方法において、前記第2ハッシュ結果をマッピングするステップは、前記第2総数を第2の法とする、前記第2ハッシュ結果の第2モジュロ演算を行うステップを含む、方法。
19. 請求項16ないし18のうちの何れか一項に記載の方法において、前記第1アウトプット・スクリプトは、実行されると、前記第1アウトプットを、a）前記現在のユーザーに関連付けられた1つ以上のユーザー公開鍵、又はb)オラクル公開鍵にロックするように構成されており、前記第1アウトプットは、少なくとも前記第2ウィニング公開鍵に対応する前記第1ウィニング公開鍵に基づいて、a）前記1つ以上のユーザー公開鍵、又はb)前記オラクル公開鍵にロックされる、方法。
20. 請求項19に記載の方法において、前記第1アウトプット・スクリプトは、a）1つ以上のユーザー公開鍵に前記第1アウトプットをロックするマルチ・シグネチャ・スクリプトを含む、方法。
21. 請求項1ないし20のうちの何れか一項に記載の方法において、1つ以上の第1公開鍵は同じ第1ゲーム要素を表現し、及び／又は1つ以上の第2公開鍵は同じ第2ゲーム要素を表現している、方法。
22. ブロックチェーンに含めるブロックチェーン・トランザクションであって：
    トランザクションはアウトプットを含み、前記アウトプットは公開鍵のシーケンスを含むアウトプット・スクリプトを含み、各々の公開鍵はゲーム要素のセットのうちのそれぞれを表現し、前記アウトプット・スクリプトは、少なくとも1つの第1擬似乱数を生成するように構成されており、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含み、前記アウトプット・スクリプトは、少なくとも1つの第1ウィニング公開鍵を選択するように構成されており、少なくとも1つの第1ウィニング公開鍵は、前記少なくとも1つの第1擬似乱数に対応する前記第1公開鍵のシーケンス内の或る位置にある公開鍵である、トランザクション。
23. 請求項22に記載のトランザクションを格納したコンピュータ読み取り可能な記憶媒体。
24. コンピュータ装置であって：
    1つ以上のメモリ・ユニットを含むメモリ；及び
    1つ以上の処理ユニットを含む処理装置；
    を含み、前記メモリは前記処理装置において動作するように構成されたコードを格納しており、前記コードは、前記処理装置において実行されると、請求項1ないし21のうちの何れか一項に記載の方法を実行させるように構成されている、コンピュータ装置。
25. コンピュータ読み取り可能な記憶媒体に組み込まれるコンピュータ・プログラムであって、コンピュータ装置において実行されると、請求項1ないし21のうちの何れか一項に記載の方法を実行させるように構成されているコンピュータ・プログラム。

Images