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

Abstract

コンピュータが実行する方法はゲームをプレイする際に使用するゲーム要素を擬似ランダムに選択する。オラクルは、シード・データ・アイテムのセットを取得し、シード・データ・アイテムのセットは、個々のユーザーにより生成された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）)場合に特に問題である。例として、参加者がオンライン・カジノでルーレットをプレイしている場合、参加者は、カジノが、ウイニング・ポジション（即ち、番号）を公正に生成していることを信頼しなければならない。幾つかのゲームは、少なくともある程度は、ゲーム要素の特定の順序（order）に基づいて決定される。そのようなゲームの一例は、カード・ベースのゲーム、例えばポーカー、ブラックジャックなどである。ここでは、一組のトランプのうちのトランプの順序が、ゲームの結果に大きく影響する。

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

[0008] 本件で開示される一態様によれば、ゲームをプレイする際に使用するゲーム要素を擬似ランダムに選択するコンピュータが実行する方法が提供され、前記ゲームは一組のユーザーによりプレイされ、前記ゲーム要素は前記ゲームの結果を決定するために使用され、前記方法はオラクル（oracle）により実行され、前記方法は：シード・データ・アイテムのセットを取得するステップであって、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含む、ステップ；公開鍵のシーケンスを取得するステップ；ゲーム要素のリストを取得するステップであって、公開鍵の総数はゲーム要素の総数に対応している、ステップ；及びゲーム・トランザクションの第1アウトプットを生成するステップであって、前記第1アウトプットは前記公開鍵のシーケンスを含み、前記アウトプットは、少なくとも1つの擬似乱数を生成するように構成されたスクリプトを含み、前記スクリプトは、前記少なくとも1つの擬似乱数に基づいて前記公開鍵のリストを生成するように構成されており、前記公開鍵のリストにおける公開鍵の順序は、前記公開鍵のシーケンスにおける公開鍵の順序と相違している、ステップを含む
[0009] オラクルはゲーム要素のリストを取得する。ゲーム要素は、ゲーム要素のリストにおいて或る順序を有する（その順序は、ランダムに生成されていてもよい）。オラクルは、また、公開鍵のシーケンスも取得する。公開鍵は、公開鍵のシーケンスにおいて或る順序を有する。次いで、オラクルは、ゲーム・トランザクション内のスクリプトを使用して、同じ公開鍵のリストを生成する。公開鍵は、公開鍵のリストにおいて或る順序を有する（その順序は、スクリプトによって生成される1つ以上の擬似乱数によって決定される）。公開鍵のシーケンスにおける公開鍵の順序は、公開鍵のリストにおける公開鍵の順序と同じではない。ここで、ゲーム要素のリスト内の各ゲーム要素は、公開鍵のリスト内の個々の公開鍵にマッピングされることが可能である。次いで、公開鍵のシーケンスがゲームで使用される場合、公開鍵のシーケンス内の各々の公開鍵は、疑似ランダムに選択されたゲーム要素にマッピングされる。全ての公開鍵は、常に可視的（visible）であってもよいが、ユーザーは、各々の公開鍵がどのゲーム要素に対応するかを必ずしも知る必要はない。ユーザーによって生成された公開鍵に対する秘密鍵は、そのユーザーにとってシークレットであり、ユーザーがゲーム要素のオーナーシップを証明することを可能にする。

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

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

[0012] 本開示の実施形態の理解を促し、そのような実施形態がどのように実施され得るかを示すために、具体例であるに過ぎない添付の図面が参照される。
図1は、ブロックチェーンを実装するためのシステムの概略ブロック図である。 図2は、ブロックチェーンに記録され得るトランザクションの幾つかの例を模式的に示す。 図3は、ブロックチェーンを実装するための別のシステムの概略ブロック図である。 図4は、アウトプット・ベース・モデルのノード・プロトコルに従ったトランザクションを処理するためのノード・ソフトウェアの概略ブロック図である。 図5は、ブロックチェーンを用いてプロバブリー・フェアー・ゲームを実現するためのシステムの概略ブロック図である。 図6は、公開鍵のシーケンスを概略的に示す。 図7は、コミットメント・トランザクションの生成を概略的に示す。 図8は、公開鍵のシーケンスにマッピングされたゲーム要素のリストを概略的に示す。 図9は、ゲーム要素のリストを真正証明するためのマークル・ツリーを概略的に示す。 図10は、公開鍵のリストにマッピングされるゲーム要素のリストを概略的に示す。 図11は、ゲーム要素を公開鍵に擬似ランダムにマッピングするプロセスを概略的に示す。 図12は、一組のユーザーがユーザー・シードをオラクルに提供して擬似乱数を生成することを概略的に示す。 図13は、ゲーム要素を公開鍵に擬似ランダムにマッピングし、ゲーム要素のリストを真正証明するためのマークル・ツリーを生成するプロセスを概略的に示す。 図14は、コミットメント・トランザクションに対してユーザー・シードをコミットする一組のプレーヤのセットを概略的に示す。 図15は、公開鍵のリストをシャッフルするためのゲーム・トランザクションを生成するディーラーを概略的に示す。 図16は、ブラインド・ステーキング・トランザクションにインプットを提供する一組のプレーヤを概略的に示す。 図17は、フェース・ダウン・カードを表すプルーフ・トークンをプレーヤに提供するディーラーを概略的に示す。 図18は、プレ・フロップ・ベッティング・トランザクションにインプットを提供する一組のプレーヤを概略的に示す。 図19は、フェース・アップ・カードを表す秘密鍵をプレーヤに提供するディーラーを概略的に示す。 図20は、フロップ・ベッティング・トランザクションにインプットを提供する一組のプレーヤを概略的に示す。 図21は、フェース・アップ・カードを表す秘密鍵をプレーヤに提供するディーラーを概略的に示す。 図22は、ターン・ベッティング・トランザクションにインプットを提供する一組のプレーヤを概略的に示す。 図23は、フェース・アップ・カードを表す秘密鍵をプレーヤに提供するディーラーも概略的に示す。 図24は、リバー・ベッティング・トランザクションにインプットを提供する一組のプレーヤを概略的に示す。 図25は、ポーカー・ゲームにおけるショーダウンを模式的に示す。 図26は、複数のポット・プレ・フロップ・ベッティング・トランザクションにインプットを提供するプレーヤを概略的に示す。 図27は、乱数R_Nを生成するためのスクリプト<R_N>の実行フロー例を示す。 図28は、ウィニング公開鍵を選択するためのスクリプト<P_k=0>の実行フロー例を示す。

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

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

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

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

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

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

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

[0020] 何れのタイプのトランザクション・プロトコルでも、ユーザー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のネットワーク全体に伝搬される。

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

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

[0023] パズルを解いた最初のマイナー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において順序付けられたブロックに記録されるので、従ってこれはトランザクションの変更できない公の台帳を提供する。

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

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

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

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

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

[0029] 各々の当事者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つ以上の他のネットワーク化されたリソースを含んでもよい。

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

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

[0032] 各コンピュータ装備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によって使用される（ただし、それはそのサブタイプに対して定められたルールに従って異なるトランザクションのサブタイプを別様に処理し、また、異なるノードは異なる役割を担い、従ってプロトコルの様々な対応する側面を実装することができる）。

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

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

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

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

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

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

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

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

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

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

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

[0044] 図示の例では、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>を含む。如何なるデータ（又は“メッセージ”）が、有効な署名を提供するためにアリスによって署名されることを必要とするかは、ロッキング・スクリプトによって、ノード・プロトコルによって、又はこれらの組み合わせによって定められることが可能である。

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

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

[0048] 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内の別の有効なトランザクションに対する有効なインプットが既に形成されているかどうかである。

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

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

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

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

[0053] スクリプト・コードはしばしば概略的に表現される（即ち、厳密な言語ではない）ことに留意されたい。例えば、ある人は、
[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言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望ましい文書を含むことが可能である。

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

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

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

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

[0058] ノード・ソフトウェア
図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に渡す。

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

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

[0061] アウトプット・ベース・モデルでは、スクリプト・エンジン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である場合、決定エンジンは、トランザクションが有効であり、且つ十分なマイニング手数料を残すという双方を条件として、トランザクションをマイニングすることを選択するだけであってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

[0076] ステップ1. オラクルは、各プレーヤから提供されたプリ・イメージに対してY_i=H(X_i)を検証する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

両方の署名は、同じ秘密鍵S_iを使用して署名され、その結果、両方の署名が公開鍵P_iの同じ所有者に対応することを検証することができる。

[0090] P_i = S_i・G
[0091] 次いで、プレーヤは、各自のシークレットs_i’をオラクルへ、好ましくは秘密共有技術により送信する。次いで、オラクルは、次の方法で乱数R_Nを生成する。

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

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

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

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

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

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

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

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

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

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

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

[0102]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0120] 問題とするゲームに応じて、プレーヤのハンドは、これらの要素のうちの1つ以上の組み合わせを含み、それは単にDのサブ・セットである。一般に、所与のハンドの中にあるカードの順序という概念はなく、従って、カードの順列ではなく組み合わせのみに関連があることに留意されたい。そのようなハンド（hand）hの例は、次のようなものである：
[0121]
hand: h = {AD, AC, AH, KD, KS}
これは、ポーカーのようなゲームで最強のハンド（即ち、‘フル・ハウス’）に対応する。

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

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

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

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

[0127] このようにしてカードのハンドを表現することには、多くの利点がある。第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つの公開鍵で公に表現されることが可能である：

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

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

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

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

にマッピングされることができる。

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

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

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

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

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

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

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

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

[0140] ゲーム要素のオン・チェーン・リオーダリング
以下、一組のトランプをチェーン上でシャッフルすることをシミュレートする方法例を説明する。“シャッフルされたデッキ”は、プロバブリー・フェアー・ゲームが、プレイされることを可能にするために使用することができる。説明されているように、52個の固有の鍵ペアは、一組のトランプ内の52個の固有のアイテムと1対1のマッピングで割り当てられることが可能であり、これは、ブロックチェーン・スクリプトにおける連続したスタック要素の単純なリストとして表現することができる。

[0141] 乱数R_Nは、k個の擬似乱数n₁, n₂, ..., n_kを生成するために使用され、kは、デッキに関して公正にシャッフルされたとみなされるために実行されなければならないカード・ローリング操作の最小数を示す‘シャッフリング・パラメータ’である。一組のトランプは、次に、スクリプトで‘ローリング’操作を実行することによってシャッフルされる。これを実装するために、以下の2つのスクリプト部分を使用することができる。

ここで、X₀, X₁, ..., X_NはN個の事前にコミットされた値のセットであり、1つの値は、一般に、ゲームにおけるN人のプレーヤ各々によって事前にコミットされており、ここで、H⁰(R_N)=R_Nである。＜R_N>は、擬似乱数を生成する任意のスクリプトで置き換えられてもよいことに留意されたい。

[0142] ランダム化スクリプトをk回実行すると、k個の公開鍵がランダムに選択され、スタックのトップに配置される。即ち、ランダム化スクリプトが一度実行されると、ランダムに選択された公開鍵がスタックのトップに配置される。ランダム化スクリプトが2回目に実行されると、ランダムに選択された2番目の公開鍵がスタックのトップに（即ち、以前に選択された公開鍵の上に）配置される。このプロセスは、必要とされるランダム・レベルに応じて、必要な回数だけ繰り返すことができる。従って、<P₁><P₂>...<P_N> がトランプにマッピングされる場合に、<P_k>を何度も実行することは、トランプのデッキをシャッフルする効果を有することが分かる。

[0143] スクリプトでランダム化スクリプトをk回実行することは、以下のアルゴリズムを使用して実行されることが可能である。

[0144] オン・チェーン部分シャッフル・アルゴリズム(φ(n))
入力：{P₁, P₂, ..., P₅₁, P₅₂}, n
1. キーのリスト{P₁, P₂, ..., P₅₁, P₅₂}を使用して、部分的なロッキング・スクリプト<P₁><P₂>...<P₅₂>を生成する；
2. 別の部分的なロッキング・スクリプトを計算する：<P_n>；
3. 2の部分的なロッキング・スクリプト2を含むロッキング・スクリプトに対して有効なアンロッキング・スクリプトを実行することにより、部分的なシャッフル・ステップを実行する。
出力：{P₁, P₂, ..., P₅₂, P_n}
[0145] オン・チェーン完全シャッフル・アルゴリズム(Φ(n,k))
この方法は、上記の部分シャッフル・アルゴリズムの繰り返し適用を含む。部分シャッフルはk回実行され、ここで、kは、‘プロバブリー・フェアー’に関する実装者の条件を充足するために何回の部分シャッフルが要求されるかを決定するパラメータである。
入力：{P₁, P₂, ..., P₅₁, P₅₂}, n = R_N, k
1. For (i=0, i≦k, i++) {
φ(i)を実行
}
出力：{P_α, P_β, ..., P_γ, P_nk}
[0146] ここで、本開示の実施形態を図5を参照しながら説明する。図5は、ゲームをプレイするためのシステムを示す。一般に、ゲームは、任意数のN人のユーザー501（即ち、プレーヤ）によりプレイされる可能性があり、各ユーザー501が各自のコンピュータ機器を操作するが、図5では図示の便宜上3人のユーザーしか示されていない。ゲームは、ゲーム・オラクル502、例えばゲームのプレーヤではない第三者、によって実施される。ゲーム・オラクル502は、個々のコンピュータ装置を操作することができる。オラクル502は、スマート・コントラクト又は自律エージェントであってもよい。即ち、オラクル502は、本件で説明される実施形態を実施するように意図されるコンピュータ・プロトコルであってもよい。図5はオラクル502を示しており、オラクルは、各ユーザー501から各ユーザー・シードを取得し、コミットメント・トランザクションTx_Commitとゲーム・トランザクションTx_gameを、ブロックチェーン150に含めるためにブロックチェーン・ネットワーク106へ送信する。また、図5は、ユーザー501bが、ウィニング償還トランザクション（“redeem”のラベルが付されているもの）を、ブロックチェーン・ネットワーク106へ送信していることを示す。前述のトランザクションは以下で説明される。

[0147] 各ユーザー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のような光ディスク、又はリムーバブル光学ドライブに提供されたりしてもよい。

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

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

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

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

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

[0153] 場合によってはユーザーのシード（又はそのシードのハッシュ）はそれぞれの署名で署名されない場合があることに留意されたい。即ち、ハッシュ方法が使用され、各ユーザー501が各自のシードの各自それぞれのハッシュを、コミット・トランザクションTx_Commitのそれぞれの入力に、各自の署名と共に追加する場合、ユーザーの署名は必ずしもそれらのハッシュに署名していなくてもよい。これは、必要とされる場合に、コミット・トランザクションTx_Commitが紛争解決に必要な情報を含んでいない問題を招き、なぜならその場合ハッシュはユーザーによって署名されないからである。しかしながら、ユーザーの正しいハッシュが、擬似乱数を生成するためにオラクル502によって使用されていなかった場合、ユーザー501はこれに容易に気付き（ゲーム・トランザクションTx_gameがブロックチェーンに対してマイニングされるため）、その問題を報告し、及び/又は同じオラクル502を使用してゲームをプレイすることを中止するであろう。従って、提案されたプロトコルの透明性は、ユーザーによって提供される実際のシード（又はそのハッシュ）を使用するように、オラクル502にインセンティブを与える。

[0154] また、署名方法がユーザー・シードを真正証明するために使用されるならば、それは軽減され、なぜなら署名自体がコミットメントTx_Commitであるからである、ということにも留意されたい。

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

[0156] オラクル502は、公開鍵のシーケンスを取得する。各キーは、それぞれのゲーム要素を表すために使用される。オラクル502は、少なくとも幾つかの公開鍵をユーザー501から取得することができる。各ユーザー501は、1つ以上（好ましくは2つ）の公開鍵をオラクル502へ提供することができる。オラクル 502は、ゲーム要素の総数を表現するのに必要な残りの公開鍵（又は公開鍵の最小割り当て）を生成する。

[0157] オラクル502は、ゲーミング・トランザクション（以下、シャッフリング・トランザクションとも呼ばれる）を生成する。ゲーミング・トランザクションのアウトプットは、公開鍵のシーケンスと、シードに基づいて少なくとも1つの擬似乱数を生成するように構成されたスクリプトの一部とを含む。また、アウトプットは、少なくとも1つの擬似乱数に基づいて、（公開鍵のリストを生成することによって）公開鍵のシーケンスを並べ替えるように構成されたスクリプトの一部も含む（公開鍵のリスト内の公開鍵の順序は、公開鍵のシーケンス内の公開鍵の順序と厳密には一致していない）。公開鍵のシーケンスからの公開鍵の選択については上述したとおりである。スクリプトは、消費することが可能なアウトプット又は消費することが不可能なアウトプット（例えば、OP_RETURNアウトプット）に含まれる可能性があることに留意されたい。スクリプトは、スクリプトが実行された場合に、スクリプトの結果として生じることになるリオーダリングの証拠として機能します。

[0158] スクリプトの一部分は、公開鍵のうちの1つを第1擬似乱数に基づいて選択し、選択した公開鍵をリストの先頭に配置し、従って、公開鍵の初期シーケンスをリオーダリングすることができる。このプロセスは、複数回繰り返される可能性があり、それにより、各繰り返しによって、公開鍵は、新しく生成された擬似乱数に基づいて選択され、公開鍵のリストの先頭に配置される。公開鍵のシーケンスから公開鍵を繰り返し選択することは、上述のとおりである。

[0159] リオーダリング・プロセス（即ち、公開鍵のリストの生成）の後に、公開鍵のシーケンス内の第1公開鍵（即ち、オラクル 502によって取得された公開鍵のシーケンスの先頭にある公開鍵）は、リオーダリング・プロセスの後に、オラクル 502によって取得されたゲーム要素のリスト内の第1ゲーム要素ではないゲーム要素にマッピングされるであろう。これは、最初の擬似乱数は、最初の公開鍵が選択される結果をもたらさないことを仮定している。一般に、公開鍵のシーケンス内の少なくとも1つの公開鍵は、ゲーム要素のリスト内で異なる位置（即ち、インデックス）にあるゲーム要素にマッピングされる。たとえとしてトランプを使用すると、1つの擬似乱数に基づいて公開鍵のリストを生成することは、トランプ・カードのデッキから1つのカードを選択し、デッキにおいてその位置を変更することに似ている。30個の擬似乱数に基づいて公開鍵のリストを生成することは、一組のトランプから30枚のカードを選択し、デッキ内のそれらの位置を変更することに似ている。

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

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

[0162] オラクル502は、ゲーミング・トランザクションをユーザーへ送信することができる。例えば、ゲーミング・トランザクションは、通信チャネルを介して送信されてもよいし、又はブロックチェーン150に含めるために、ブロックチェーン・ネットワーク106にブロードキャストされてもよい。

[0163] オラクル502は、公開鍵のリスト内の公開鍵を、ゲーム要素のリスト内のゲーム要素にマッピングすることを含む写像を生成することができる。換言すれば、オラクル 502は、公開鍵のリストと、それらの公開鍵がマッピングされるゲーム要素のリストとを生成する。ゲーム要素のリストは、ランダムに生成されてもよい。オラクル502は、マッピングのハッシュを生成することができ、オプションとして、ブロックチェーン・トランザクション、例えばゲーム・トランザクションTx_gameにマッピングのハッシュを含めることができる。

[0164] オラクル502は、ゲーム要素のシーケンスを表現するためにマークル・ツリー（Merkle tree）（又はその変形）を生成することができる。マークル・ツリーは技術的によく知られているので、ここでは次のこと以外を詳細には説明しない：マークル・ツリーは、全てのリーフ・ノードがデータ・ブロックのハッシュであり、且つ全ての非リーフ・ノードが子ノードのハッシュのハッシュであるツリーであり、この場合において、マークル・ツリーは単一のルートノード（又はルート・ハッシュ）で表される。オラクル502によって生成されるマークル・ツリーは、各ペアのリーフ・ノードのうちの一方のリーフ・ノードとして、それぞれのゲーム要素のハッシュを有し、各ペアのリーフ・ノードのうちの他方のリード・ノードとして、それぞれのプルーフ・トークン（真正証明トークン）のハッシュを有する。各プルーフ・トークンは、ゲーム要素のシーケンスにおける位置を表現する。従って、ゲーム要素のリストにおける最初のゲーム要素は、ゲーム要素のリストにおける最初の位置を表現するプルーフ・トークンとペアにされる、等々。マークル・ツリーは、オラクル502が、ゲーム要素のリスト内のゲーム要素の順序を真正証明することを可能にする。オラクル502は、ルート・ノードをチェーン上で公表してもよいし、あるいは、好ましくはゲームの前に、ルート・ハッシュをユーザーに利用可能にしてもよい。ルート・ハッシュは、コミット・トランザクションTx_Commitに含まれる可能性がある
[0165] 幾つかの例では、オラクル502は、各ユーザーに、ゲームをプレイする際に使用するための1つ以上のゲーム要素を提供する可能性がある。ユーザー501にゲーム要素を提供するために、オラクル502は各ユーザー501に一組のプルーフ・トークンを送ることができる。ユーザー501が1つ以上の公開鍵を生成し、それらをオラクル 502に提供している例では、オラクル 502は、それら1つ以上の公開鍵に（リオーダリング・プロセスの後で）マッピングされたゲーム要素に対応するプルーフ・トークンを、ユーザー501に送ることができる。即ち、ユーザーの公開鍵がゲーム要素のシーケンス内で17番目のゲーム要素にマッピングされる場合、オラクル 502は、17番目のプルーフ・トークン（即ち、マークル・ツリーにおける17番目のリーフ・ノード・ペアにおけるプルーフ・トークン）を、ユーザー501に送ることができる。また、オラクル502は、各ユーザーに送られる各プルーフ・トークンによって表現されるゲーム要素を指し示すもの（indication）を各ユーザーに送ることもできる。指し示すものは、所与のユーザー501のみが、各自の生成された公開鍵にマッピングされたゲーム要素を認識するように、プライベートに（例えば、安全な通信チャネルを介して）送信されてもよい。

[0166] オラクル502はまた、例えば要求に応じて、それぞれのユーザーに送られたそれぞれのプルーフ・トークンによって示されるそれぞれのゲーム要素に対するそれぞれのマークル経路を、1人以上のユーザーに提供してもよい。即ち、オラクル502が、ゲーム要素のシーケンスにおいて第1ゲーム要素とペアにされている第1プルーフ・トークンを、第2ユーザー501bへ送る場合に、オラクル502は、第1ゲーム要素が実際にマークル・ツリー内の第1リーフ・ノードによって表現されていることを証明するために、マークル経路を第2ユーザー501bへ送ってもよい。

[0167] オラクル502は、1人以上のユーザーに、それぞれの第2セットのプルーフ・トークンを送信することができる。第2セットのプルーフ・トークンの各々は、ユーザーが対応する秘密鍵を有しない公開鍵にマッピングされたゲーム要素に対応する。代わりに、オラクル 502は、これらの秘密鍵をユーザーに送信する。これは、ユーザーが、ゲーム要素のそれぞれの組み合わせを表現する、それぞれの勝利の可能性がある公開－秘密鍵ペアを生成することを可能にする。即ち、所与のユーザー501は、そのユーザー501が既にアクセス可能な秘密鍵（即ち、そのユーザーにより生成された公開鍵に対応する秘密鍵）と、オラクル 502から受信した1つ以上の秘密鍵との組み合わせに基づいて、勝利の可能性がある秘密鍵を生成することができる。

[0168] オラクル502は、ウィニング公開鍵にロックされたアウトプットを含む支払トランザクションを生成することができる。ウィニング公開鍵は、ユーザーにより生成されるそれぞれの勝利の可能性がある公開鍵のうちの1つである。オラクル502は、全ての公開鍵にアクセスできるので、オラクル502は、ウィニング公開鍵を生成することができる。オラクル502は、ゲームのルールに基づいて、ウィニング公開鍵を生成し、例えば、勝利の可能性がある公開鍵のうちの特定のものが、ゲーム要素の勝利組み合わせを表現していると判断することができる。

[0169] ユース・ケース例
プロバブリー・フェアー・ポーカー
ポーカーのハンドを演じるために、52個のキー・ペアが生成され、各キー・ペアは、最終的には標準的なトランプ一組からのカードに割り当てられる。そのハンドでウィニング・プレーヤ501は、ウィニング・ハンドのキーP_hにロックされたUTXOを償還することによって、勝利（即ち、賭けた資金）を最終的に償還し、そのキーは上述したように一緒に加算されたウィニング・ハンドの5つの公開鍵を含む。例えば、ウィニング・ハンドが‘フル・ハウス’である場合、ウィニング・ハンドは、次のように構築される：

[0170] 本開示は、ウィニング・プレーヤのみが、そのハンドに関する対応する秘密鍵
s_h = s_AD + s_AC + s_AH + s_KD + s_KS
で署名することによって、勝利を償還する能力を持つことを保証する。従って、ウィニング・プレーヤだけがウィニング・ハンドに対応する全ての秘密鍵を知ることが必要であり、従ってウィニング・プレーヤだけがP_hに対して署名する能力を有し、勝利を償還する。

[0171] オラクル 502（例えば、ディーラー）も、その他の何れの非ウィニング・プレーヤも、これらのキーの5つ全てについての知識を有するべきではない。これは、各プレーヤ501が各プレーヤ501に配られたカードに割り当てられた各自自身のキーを選択するキー生成ラウンドが存在することを保証にすることによって達成される。

[0172] ポーカーのハンドを初期化すること
初期化の段階は、何らかのカードが配られたり、ポーカーのハンドでベッティング（betting）を開始したりする前に行うものであり、3つのステップを含む：
1. キー生成
2. コミットメント段階
3. シャッフル段階
[0173] このプロセスは、ポーカーの新しいハンドがプレイされるたびに実行される。

[0174]
1. キー生成
ゲームがプレイされる前に、必要とされる52個のキー・ペアは、以下のように、図6に示すように設定される。

[0175]
1. N人のプレーヤ各々は、ディーラー（オラクル 502）に公開鍵のペアP_r,1, P_r,2を送り、それらに対応する秘密鍵S_r,1, S_r,2はr番目のプレーヤに対してのみ知られている。これは、全部で2N個の公開鍵を構成し、最大N=23人のプレーヤである（又は、カードが“burned”とされる場合には、N=22人のプレーヤ）。 これらのキー・ペアは、プレーヤのそれぞれのフェース・ダウン・カード（“ホール（hole）”カード）に対応する。

2. ディーラーは、デッキ内の残りのカードをカバーするために、最小限でM=52-2N個のキー・ペアを生成する。ゲームの開始時に、ディーラーは、これらのキー・ペアの公開及び秘密鍵の両方を知っており、ディーラーのみが秘密鍵を知っている。キー・ペアは、テーブルの中央にある5つのフェース・アップ・カード（“コミュニティ”カード）に対応する。

[0176] プレーヤ501が自身の2つのキー・ペアを生成することを要求する理由は、ディーラーでさえ、プレーヤのフェース・ダウン・カード（“ホール”カード）に対応するプライベート・キーを知らないという事実に起因して、プレーヤのみがゲームの終了時に勝利を一方的に償還できることを、それが保証するであろうということである。

[0177] このキー生成段階は、ゲームの前に以下のような52個のキー・ペアのリストをもたらす：

[0178]
2. コミットメント段階
初期化の次のステップは、コミットメント・トランザクションTx_Commitを作成することである：
・ ディーラーは、先ず、カード要素のランダムな順序Ω（即ち、ゲーム要素のリスト）とランダム・ハッシュ・プリイメージX₀をコミットし、これら双方はこの時点でディーラーに対してのみ知られている。

・ N人のプレーヤの各々は、ランダム・ハッシュ・プリイメージX₁, X₂, ..., X_Nをコミットし、それら各々はこの時点でそれぞれのプレーヤのみに知られている。

・ ディーラーは、トランザクション全体に署名し、マイニングされるようにそれをブロードキャストすることによって、トランザクションを完了する。

[0179] このトランザクションは、オン・チェーン乱数発生器にシードを与えるために使用されるハッシュ・プリイメージのセットX₁, X₂, ..., X_Nに対してコミットするだけでなく、一組のカード内の要素のランダムな順序Ω（即ち、ゲーム要素のリスト）に対してディーラーをコミットするためにも使用される。このランダムな順序は、後に、一方向写像γ
γ：カード要素 → 公開鍵
を形成し、これは各プレーヤ501がポーカーのハンドの中で何れの‘カード’に‘賭けたか’を決定することになる。

[0180] 更に、このトランザクションは、オラクル502によって生成される公開鍵P52-2Nに対してもコミットしており、これは、プレーヤがインプットを署名することによって参加開始した後に、オラクル502がキー・ペアを変更できないことを意味する。これは、図7に示すように、変化するSIGHASHフラグを使用することによって強制される。

[0181] このようなコミットメント・トランザクションTx_Commitの例は図7に示されている。このトランザクションを作成することは、ポーカー・テーブルで席につくための‘バイイン’（buying in）に似ていることに留意されたい。また、このトランザクションについての多くの異なる変形が存在する可能性があることにも留意すべきである。例えば、ハッシュ化されたプリイメージH(X₀), H(X₁), ..., H(X_N)としてコミットされたコミット済みの値は、代替的に、アウトプット（又は、アウトプットのセット）においてにコミットされている可能性がある。

[0182] このトランザクションの各部分が構成される順序は重要である。インプットは、好ましくは、ディーラーがトランザクションに署名し、初期カード順序Ω（ゲーム要素のリスト）を真正証明することを、何らかのプレーヤ501が自身のインプットに署名してゲームに‘参加’する前に行うように、（トップからダウンへ向かう）順序で生成されるべきである。

[0183] このトランザクションを作成する際の処理の順序もまた重要であり、なぜならこの順序は、ゲーム内でカードが‘賭けられる’順序（ゲーム要素のシーケンス）を定義するために使用されることになるからである。コミットメント・トランザクションTx_Commitに基づいてディーリング・カードの順序を定義するしきたりは、以下のとおりである：
1. 2つの‘ホール’（hole）カードが最初に、そして次の順序で賭けられる：
a. 1度目にテーブルを一巡する：P₁, P₃, P₅,..., P_2N-1
b. 2度目にテーブルを一巡する：P₂, P₄, P₆,..., P_2N
2. 5つの‘コミュニティ’カードがその後次の順序で賭けられる：
a. 手札配布，フロップ：P_2N+1, P_2N+2, P_2N+3
b. 手札配布，ターン ：P_2N+4
c. 手札配布，リバー ：P_2N+5
[0184] ポーカーのゲームでは、合計2N+5枚のカードだけが必要とされ、そのうちの5枚だけがキー・ペアに」対応し、ディーラーによって生成されることを必要とする点に留意されたい。しかしながら、ディーラーは、最終的なNの値が分かる前に、キー・ペアのリストP52-2N,..., P52を真正証明しなければならないという事実に起因して、ディーラーは少なくとも48枚のそのような公開鍵（即ち、2人のプレーヤの場合）を含む、ということを要求することは賢明なことであり、現実にはそのうちの5つのみが賭けられるであろう。

[0185] キーに対するカードの割り当て
前述したように、この最初の順序Ωは、写像γの半分を形成する。

γ：カード要素 → 公開鍵
カードが公開鍵として取り扱われる順序、即ち公開鍵のシーケンス（上記参照）は既に決定されているので、カード要素の公開鍵へのマッピングは、上述の順序に従って、実際にどのカードがプレーヤに賭けられているかを決定することになる。写像γの形態は図8に示されている。

[0186] 実際のポーカー・ゲームをシミュレートするためには、明らかに、カード要素のキーへの割り当てランダム化されていないければならない。これは以下の原理を用いて達成される：。

1. カード要素の初期順序（写像γのLHS；ゲーム要素のリスト）は、ディーラーによって最初にランダムに選択される。これは、全ての公開鍵が生成又は順序付けされる前に行われる。

2. 写像γのRHSを占める公開鍵のリストは、段階1（キー生成；ゲーム要素のシーケンス）で生成されたキーである。それらは、初めに、P₁に対してi=1、P₂に対してi=2、...、P₅₂に対してi=52となるような単純な順序で与えられる。

3. ポーカーのハンドに使用される写像の最終形態は、ランダム化前のカード要素（γのLHS）を固定したまま、公開鍵のリストを生成するために公開鍵（γのRHS）の順序をシャッフルすることによって生成される。

RHSにおける公開鍵は、以下で説明されるようにシャッフリング段階でランダム化される。

[0187] 真正証明：
上記のように、ディーラーはカード要素のセット（写像γのLHS）を事前にランダム化し、要素のこのランダム化された順序（リスト）は、ハンドの残りの部分について固定されたままでなければならない。これは、最初の順序Ωが、チェーン上のハッシュ値として真正証明されることを確実にすることによって達成することができる。このように、ハッシュ関数の一方向特性は、要素の事前にランダム化された順序が固定されたままでなければならないことを保証し、なぜならハッシュ・プリイメージに対する如何なる変更も、当初に真正証明されたハッシュに変更をもたらすことになるからである。

[0188] 写像に対する真正証明は、それをマークル・ツリー（又はマークル・ツリーの変形）としてエンコードすることで、各カード要素が真正証明トークン（attestation token）Tとペアにされ、リーフの各ペアが左から右へ走るインデックスi=1, i=2, ..., i=52を有することによって、達成することができる。インデックスiは、オラクル502によってランダム化されるように、事前にシャッフルされたデッキ（一組のトランプ）内のカード要素の深さに対応する。

[0189] 図9に示されているように、カード要素のディーラーによる当初の順序Ωを真正証明するために使用できるマークル・ツリーは、以下のようにして構成することができる：
1. オラクル502は、最終的な写像γの左側を形成することになるカード要素のランダムな初期順序Ωを生成し、その写像はどのキー・ペアがどのカード要素に対応するかを決定することになる。

2. オラクル502は、ディーラーによって選択されたように、標準的な一組のトランプのカード要素の初期順序を格納するバイナリ・マークル・ツリー（図9に示されるもの）を作成する：
a. ディーラーは、真正証明トークンT₁, T₂, ..., T₅₂として使用される52個の乱数のセットを生成する。

b. リーフのi番目の各ペアは、プルーフ・トークンT_iとペアにされたカード要素（例えば、7H）として構成される。52個のプルーフ・トークンが存在し、各カードに対して1つあり、これにより、ディーラーは、プレーヤ501に対して、他の如何なるカードとも無関係に、所与のカード要素の当初のインデックスi（ディーラーのランダム化された初期順序）を真正証明することができる。

[0190] 例えば、ディーラーは、カード要素QSが初期順序（ゲーム要素のリスト）における位置i=34に備わっていたことを、初期順序における他の如何なるカード要素の位置に関する如何なる追加情報も明らかにすることなく、証明することができる。

[0191]
3. 真正証明マークル・ツリーのルートは、チェーン上に記憶され、オラクル502によって（例えば、デジタル署名によって）真正証明される。これは、ディーラーによって署名されたコミットメント・トランザクションTx_Commitに格納されたハッシュ・ダイジェスト（即ち、マークル・ルート）として現れてもよい。

[0192] 初期順序で登場する配布されたカードが、最終決定された写像γにおけるプレーヤの公開鍵のインデックスに対応する場所にあるインデックスを単に証明することによって、ディーラーが、カードを、プレーヤの事前に生成された公開鍵に対して‘配る（deal）’ことを可能にする点で、上述の方法で構築されたマークル・ツリーは、ポーカーのゲームをプレイする要件に整合している。この文脈における説得力のある証明は、プレーヤ501に真正証明トークンとマークル経路とが提供されることに対応し、マークル経路は、カード要素がクレームされた初期インデックスを有していたことを証明する。

[0193] 言い換えれば、ディーラーがカード要素の初期順序Ωを真正証明し、第1プレーヤ501が、彼の生成したキーP₁,P₂に対応するカードを配布され、全ての公開鍵P₁,P₂,...,P₅₂の順序が（公開鍵のリストの中で）ランダムにシャッフルされた場合、プレーヤ501は、以下の方法で、彼の2枚のカードを配布される：
[0194]
1. プレーヤ501は、公開鍵の公知のランダム化された順序（公開鍵のリスト）のインデックス値をチェックして、彼の鍵がP₁については位置i=31及びP₂については位置i=17にそれぞれあることを見出す。公開鍵のこのランダム化された順序を生成する方法は、次のセクション（シャッフリング段階）で示される。

2. ディーラーは、プレーヤ501に、インデックス位置i=17, i=31に対応するカード要素（例えばAD及び６C）を提供する。これらは、写像γによって決定されるキーP₁, P₂に対応しなければならない。

3. カード要素AD, 6Cが実際にカードP1, P2に対応していることを、AD, 6Cがそれぞれ位置i=31, i=17にあることのエビデンスを次のようにして提供することによって、ディーラーはプレーヤ501に提供する：
a. プルーフ・トランザクションT31, T17を提供する；及び
b. AD, 6Cに対するマークル経路を提供する。
この概念は図10に概説されている。

[0195]
3. シャッフル段階
これまでのセクションは、コミットメント段階が、ポーカーのゲームを開始することに対して複数のアイテムをコミットする方法を説明している：
・ ディーラーは、カード要素の初期順序Ω（ゲーム要素のリスト）をコミットする；
・ ディーラーとプレーヤは、配布されたカードの順序（公開鍵の順序）をコミットする；
・ ディーラーは、ランダムなシークレット値x₀をコミットする；及び
・ N人の各プレーヤは、ランダムなシークレット値X₁, X₂,..., X_Nをコミットする。

[0196] カード要素の初期順序ΩとシークレットのリストX₀, X₁, X₂,..., X_Nのリストとをコミットする理由は、これが、ランダムなカード・キー割り振りを、証明可能に公正な方法で実行されることを可能にする、必要なコミットされた情報であるからである。

[0197] このプロバブリー・フェアーなランダム割り振りが達成される方法は、カード要素とキーとの間のマッピング，γ：カード要素 → 公開鍵 の注意深い構築によって達成され、それによって、使用される最終的なマッピングが証明可能に擬似ランダムであることを保証する。この擬似ランダム写像の作成は図11で概説されている。

[0198] 図11で概説されるプロセスは、以前のセクションで部分的には既に説明されている。完全を期するために、以下、そのプロセスを改めて要約する：
1. ディーラーは、写像の初期状態のLHSに表示される、カード要素のシークレットな初期順序Ωと乱数を生成する。ディーラーはまた、これをチェーン上で真正証明する。

2. N人のプレーヤは、合計2N個の公開－秘密鍵のペアを生成し、それぞれ2つずつ、初期コミットメント・トランザクションTx_Commitにおける各自の位置によって決定される初期順序が与えられる。シンプルな初期順序は、写像の初期状態のRHSに反映される。

3. 乱数R_Nはin-scriptを使用して生成される。数字は、例えば、R_N=H(X₀||X₁||...||X_N)のような、全てのコミットされたシークレット値X₀, X₁, X₂,..., X_Nのハッシュ・コンビネーションとして生成される。これは、全てのプレーヤとディーラーとが共謀しない限り、プレーヤ501は全ての部分的なプリイメージ値を前もって知ることができないという条件で、乱数は、全てのプレーヤとディーラーの観点から見て擬似乱数であることを意味する。

4. 乱数R_Nは、写像のRHSにおける公開鍵の順序をシャッフルして、公開鍵のリストを生成するために使用される。この結果は、ポーカーのハンドに関して確立される52個の公開鍵に対する、カード要素のランダムにシャッフルされた割り当て（即ち、マッピングγ）である。

[0199] 乱数生成の詳細：
乱数R_Nが、どのように生成され、52個の公開鍵のリストをシャッフルするために使用されるかについてのプロセスの豊富な詳細は、以下のように図12に示されている：
[0200]
1. 段階2（コミットメント段階）で説明されているように、コミットメント・トランザクションが作成され、ブロックチェーン上でマイニングされる。

2. 各プレーヤ（j番目）は、コミットされた値H(X_j)に対応するシークレット値X_jをディーラーに送信する。これに応じて、ディーラーは、彼らのシークレット値X₀を公に分配することによって応じることができる。

3. オラクル502は、例えばR_N = H(X₀||X₁||...||X_N) のように、コミットされたシークレットの関数を使用して乱数R_Nを計算する。

4. オラクル502は、シャッフリング・トランザクションTx_Shuffleを作成、署名、及びブロードキャストする。

[0201] シャッフリング・トランザクションは、上述のように、オン・チェーン・デッキ・シャッフル・アルゴリズムΦ(R_N, k)を実行する。本質的にこれはまさに、順序P₁, P₂,..., P₅₂の公開鍵から開始して、スクリプトで部分シャッフル・サブ・ルーチンφ(R_N)を繰り返し適用することによって、公開鍵の1つをスタックのトップに繰り返しロールするスクリプトの実行である。プロバブリー・フェアー・ポーカーの場合にこのシャッフルを実行するアウトプット・スクリプトの具体例は以下のとおりである：

[0202] ここでは、以下のスクリプト定義を用いて、ランダム公開鍵をスタックのトップにk回ロールしている：

[0203] シャッフリング・トランザクションTx_Shuffleの具体例は、以下のように示される。

[0204] このトランザクションにおけるロッキング・スクリプトは、以下の効果を有する：
・ 公開鍵P₁, P₂,..., P_Nがスタックにプッシュされる。

・ 乱数R_Nが生成され、スタックにプッシュされる。

・ 乱数R_Nは複製され、k回ハッシュされ、結果は毎回スタックにプッシュされる。これは、擬似ランダム・シーケンスH¹(R_N), H²(R_N), ..., H^k(R_N)を生成する。

・ RNの冗長な余分なコピーが、メインスタックから落とされる。

・ 導出された各々の擬似乱数は、オルトスタック（altstack）から拾われ、キーをメインスタックのトップにロールするために使用される。

・ スクリプトは、次いで、標準のP2PKH署名チェックを実行するために、全てのキーをドロップにするか、又はそれらをオルトスタックに送信することができる。

・ P2PKH署名チェックが実行される。ゲームのベッティング・ポット（又は場）に対応するキー・ペアが、支払トランザクションに署名するために使用されることを要求する。

スクリプトを実行した結果、公開鍵P1, P2, ..., PNのセットがスクリプトにおいてシャッフルされ、次いで、資金は、ディーラー又はカジノによって管理される、ポーカーのそのハンドに対するポットを表現するキー・ペアにロックされる。

[0205]
リキャップ
プロバブリー・フェアー・ポーカーのハンドをプレイする前に実行される初期化プロセスは、図13に要約されている。証明可能な公正さを確保するための鍵は、カード要素をキー・ペアに割り当てるために使用される写像γが、以下の性質を有することを確認すること：
・ 公開鍵のランダムにシャッフルされた公の順序（写像のRHS）；
・ ディーラーにのみ知られているカード要素のシークレットな初期順序Ω；及び
・ カードの割り当てを証明するためのシークレットな初期順序Ωの真正証明
[0206] プロバブリー・フェアーのハンドをプレイすること
以下、上述の技術を使用する、プロバブリー・フェアー・ポーカーハンドをプレイするN=5人のプレーヤの具体例を説明する。

[0207] ステップ0： ハンドの初期化
これは、事前ハンド初期化段階であり、上記の段階2で説明した全てのステップを実行すべきである。これは図14及び15に示されている。

[0208] 上位概念で要約すると、これは、コミットメント・トランザクションTx_Commitの作成、乱数R_Nの作成、及び公開鍵の順序をシャッフルするシャッフリング・トランザクションTx_shuffle（即ち、ゲーム・トランザクションTx_game）の作成を含む。前述したように、これは、カード要素と公開鍵との間の写像γがどのように構築されるかに起因して、各プレーヤ501に配布されるカードをシャッフルすることと事実上同じである。

[0209] ステップ1：ブラインドを賭ける
ディーラーの左側にいる1番目と2番目のプレーヤは、それぞれ‘スモール・ブラインド’と‘ビッグ・ブラインド’に指定される。彼らは、図16に示すように、小さな及び大きなブラインド値をポットに直接的に支払う、強制的なベッティング・トランザクションTx_Blindsに参加するように要求される。

[0210] ステップ2：ホール・カードを配る
各プレーヤのフェース・ダウン・カード（“ホール”カード）を配るステップは、ディーラー502が、各プレーヤ501に対して、ハンドの初期化（ステップ0）の際に彼らが提供した2つの公開キーに、2つのカード要素がマッピングされたことを、単に伝えることによって行われる。

[0211] ディーラー502が彼らに正しいカード要素を与えていることを各プレーヤ501に納得させるために、ディーラー502は、各プレーヤ501に、配布されたカード要素に対する個々のプルーフ・トークンも提供しなければならず、プルーフ・トークンは、これらのカード要素の初期位置が、初期化の際にディーラー502が最初に選択してコミットしたカード要素のリストの中で何であったかを証明する。このステップは図17に示されている。

[0212] カード要素は公正に配布されていることを証明する
以上を言い換えると、ステップ0で彼らが選んだ2つの公開鍵にカード要素が割り当てられていることを、プレーヤ501に証明する必要がある。これは、プレーヤ1（j=1）に対して、彼が生成した公開鍵P₁, P₂が、ディーラー502によって彼らに配布されたカード要素に実際に割り当てられていること（前の例ではそれぞれAD→P₁，6C→P₂であったこと）を、証明する必要があることを意味する。従って、プレーヤ501は、この事実を証明するために、カード要素AD, 6Cの各々に対して1つのプルーフ・トークン2つを必要とする。トークンは、それぞれT^j=1,1=T_AD及びT^j=1,2=T_6Cとラベル付けされる。

[0213] しかしながら、プレーヤ501に提供されるプルーフ・トークンT_AD, T_6Cは、それ自体では、それらが正しいカード要素で配布されたことをプレーヤ1（j=1）に納得させるには不十分である。また、トークンの位置がカード要素のリスト内で期待されるインデックス(i)に対応することを証明するために、これらのプルーフ・トークンのそれぞれのマークル経路も必要となるであろう。

[0214] プレーヤ1は、公開鍵のランダム化されたリスト中の2つの公開鍵P₁, P₂のインデックス位置を、シャッフリング・トランザクションTx_Shuffleによって生成されるので、それらが公にシャッフルされて以来、知っていることを想起されたい。先の例では、これらのキーがP₁については位置i=31及びP₂については位置i=17にそれぞれシャッフルされると説明されていた。

[0215] プレーヤ1の公開鍵P₁, P₂に対する所与のこれらのインデックス位置i=31, i=17とマッピングAD, 6Cの下で、以下のステップは、彼らの公開鍵に対応する正しいカード要素が配布されていることを、プレーヤ1に納得させることができる：
1. P₁のパブリック・インデックスを取得し、これはi=31である。

2. ディーラーが主張している、ADであるこのカードにマッピングされているカード要素を取得する。

3. カード要素ADに対応するプルーフ・トークンT^j=1,1=T_ADを取得する。

4. T_AD又はADの何れかに対するマークル経路を取得する（これらはT_AD, ADと同等であり、リーフ・ノード・パートナーであり、従ってリーフ・データ自体ではない同じマークル経路を有することに留意されたい）。

5. T_AD, ADと取得したマークル経路を使用して、マークル証明を実行する。この証明は以下のことを検証する：
a. T_ADとADの双方は、ディーラーの真正証明マークル・ルート（Tx_Commitでマイニングされたもの）によって真正証明されたデータ要素のセットのうちの一部である；及び
b. T_ADとADは、実際に、真正証明マークル・ツリーにおいてパートナーを組んでいるハッシュである。

6. T_ADとADが、マークル・ツリーの31番目のリーフ・ノード・ペア、即ち、真正証明マークル・ツリーの61番目及び62番目のリーフに対応していることを検証する。これは、次のようにして行うことができる：
a. ステップ5で提供されたマークル・プルーフの構造を分析するか；又は
b. 代替的なマークル・ツリー構造が真正証明マークル・ツリーに使用されていた場合、リーフ・データに付加された明示的なインデックス（又は類似のもの）をチェックする。

7. プレーヤ1の公開鍵のうちの第2のもの、即ちP₂について、ステップ1-6を繰り返す。

[0216] 上記のステップを実行することは、カードAD, 6Cのマッピングは、ランダム化された写像γの最終形態における公開鍵P₁, P₂に実際に対応していることを、プレーヤ1が検証することと同等である。

[0217] ステップ3：第1ベッティング・ラウンド（プレ・フロップ・ベッティング）
各プレーヤのフェース・ダウン・カード・ペア（“ホール”カード）は、ステップ2において、検証可能にランダムで公正な方法で配布される。次のステップは、プレ・フロップ・ベッティング・ラウンド（pre-flop betting round）のためのベッティング・トランザクション、即ちTx_Preflopを構築するシンプルなステップである。このトランザクションは、このラウンドで賭けたいと思う全てのプレーヤによって署名され、‘フォールド(folds)’する如何なるプレーヤも、トランザクションに署名しない。このトランザクションは1つのアウトプットを有し、賭けた資金の総額をポットに支払う。

[0218] 図18は、プレーヤのそれぞれのホール・カード公開鍵P₁, P₂,..., P₁₀に対応する秘密鍵S₁, S₂,..., S₁₀を示している。これは、ステップ2でカード要素を割り当てられた公開鍵に対応する秘密鍵を所有するプレーヤのみが、その公開鍵に署名できることになる、という事実を表現している。

[0219] また、この時点では、各プレーヤは、各自自身の公開鍵へのカード要素のマッピングのみを知っており、他の如何なるプレーヤの公開鍵へのカード要素のマッピングは知っておらず、このことは、全員のカードがこの時点では‘フェース・ダウン’にされていることと整合している。また、全ての公開鍵は、カード要素のそれらへのマッピングが各プレーヤによって私的に保持されているにもかかわらず、ビジブルであり、このことは、公開鍵が、セキュリティを損なうことなく、常にビジブルであるように許容されるという原則に合致していることに留意されたい。

[0220]
ステップ4. ディーリング・ザ・フロップ
図19に示されているように、いったんプリフロップ・ベッティング・トランザクションTxPreflopがマイニングされ、全ての同意しているプレーヤのベットがハンドの継続にコミットされると、ディーラーはここでフロップ・カードを配布することができる。

フロップ・カードは‘フェース・アップ’され、これは、ディーラー502が、フロップ・カードに対応する真正証明（プルーフ）トークンを、対応するマークル・プルーフと共に公に提供しなければならないことを意味する。これは、全てのプレーヤがステップ2で概説したアクションを実行することを許容し、このことは、デフロップ公開鍵にマッピングされていることをディーラーが明らかにしたカード要素が正当にマッピングされていることを、テーブルについている全てのプレーヤに納得させるのに十分である。

[0221] ディーラーはまた、フロップ・カードの秘密鍵S₁₁, S₁₂, S₁₃を提供する。これは、各プレーヤが、公開鍵P₁₁, P₁₂, P₁₃に関して後にメッセージに署名することを可能にする。これは、ウィニング・ハンドを表現するために単一の公開鍵を構築し、その後にウィニング・ハンド公開鍵に対するアウトプットをロックする場合に重要になる。本質的には、ウィニング・プレーヤが、後にウィニング・ハンド秘密鍵に対するメッセージに署名できるようにするためには、全ての‘コミュニティ’カード（即ち、テーブルの中央でフェース・アップされているカード）に対する秘密鍵を公開することを必要とし、ウィニング・ハンド秘密鍵は、コミュニティ・カードとウィニング・プレーヤのホール・カードの組み合わせから構成されることになる。

[0222] 例えば、ウィニング・ハンドが、3つのコミュニティ・カード（その秘密鍵はテーブルについている全てのプレーヤに知られている）と、2つのホール・カード（その秘密鍵は、1人のウィニング・プレーヤによって保持されている）とで構成される場合に、テーブルについている誰もが、次のようなウィニング・ハンド公開鍵を構築できることになるが、

正当な勝者のみが、ウィニング秘密鍵S_{winning hand}を構築し、P_{winning hand}に制約されたアウトプットを償還することができ、なぜなら勝者のみが、次のようなホール秘密鍵を知っているからである：

[0223] ステップ5. 第2ベッティング・ラウンド（プレ・ターン）
図20に示されているように、このステップは‘ターン’カード（第4コミュニティ・カード）の配布に先行する、もう1つのベッティング・ラウンドである。このステップは、ステップ3と同じロジックと理論的根拠に従い、結果として、資金をポットに支払うベッティング・トランザクションTx_Preturnを構築することになる。

[0224] ステップ6. ディーリング・ザ・ターン
図21に示されているように、このステップは‘ターン’カードを、第4のフェース・アップされたコミュニティ・カードとして配布することを含む。このステップは、ステップ4と同じロジックと理論的根拠を含み、それは、ディーラーがターン・カードのプルーフ・トークンと、プルーフ・トークンのマークル・プルーフと、ターン・カードの公開鍵に対応する秘密鍵S₁₄とを公表したことを意味する。

[0225] ステップ7. 第3ベッティング・ラウンド（プレ・リバー）
図22に示されているように、このステップは‘リバー’カード（第5コミュニティ・カード）の配布に先行する、もう1つのベッティング・ラウンドである。このステップは、ステップ3及び5と同じロジックと理論的根拠に従い、結果として、資金をポットに支払うベッティング・トランザクションTx_Preriverを構築することになる。

[0226] ステップ8. ディーリング・ザ・リバー
図23に示されているように、このステップは、単に、‘リバー’カードを第5のフェース・アップされたコミュニティ・カードとして配布することを含む。このステップは、ステップ4及び6と同じロジックと理論的根拠を含み、それはディーラーがターン・カードのプルーフ・トークンと、プルーフ・トークンのマークル・プルーフと、ターン・カードの公開鍵に対応する秘密鍵S₁₄を公表したことを意味する。

[0227] ステップ9. 第4（及び最終）ベッティング・ラウンド（ポスト・リバー）
図24に示されているように、このステップは、‘リバー’カード（第5コミュニティ・カード）を配布することに続く、もう1つのベッティング・ラウンドである。このステップは、ステップ3、5、7と同じロジックと理論的根拠に従い、結果として、資金をポットに支払うベッティング・トランザクションTx_Postriverを構築することになる。

[0228] ステップ10. ショーダウン
図25に示されているように、全てのベッティング・ラウンドとそれら各々のトランザクションがブロックチェーンにコミットされると、まだゲームに参加しているプレーヤ（即ち、最後ベッティング・トランザクションTx_Postflopに署名したプレーヤ）のハンドの強さを比較することによって、ポーカーのハンドは完結することができる。

[0229] ディーラー502は、テーブルの中央にある各コミュニティ・カードのマッピングに関し、プルーフ・トークンと対応するマークル・プルーフを既に提供しており、これは、全てのプレーヤ501がこれらのマッピングを既に納得していることを意味する。

[0230] 実行されるように残っていることは、ディーラーが、ショーダウンでフェース・アップにひっくり返された全てのカードに対するプルーフ・トークンとそれに対応するマークル・プルーフとをここで公表することであり、これは、カード要素のホール・カードへのマッピングを公けにし、全てのプレーヤ（フォールドしている者を含む）によって検証可能にする。

[0231] 上記の図の場合、これは、プレーヤ1（j=1）とプレーヤ4（j=4）のホール・カードを表現する公開鍵に対するカード要素のマッピングが、今や明らかにされなければならないことを意味する。これらホール・カードに対する秘密鍵S₁, S₂, S₇, S₈が公に明らかにされる時点はなく、なぜならそれらは個々のプレーヤにのみ知られているからであることに留意されたい。

[0232] 勝利の償還：
今やディーラーは、それぞれのベッティング・トランザクションのインプットの全てを、1つのウィニング償還トランザクションに集約することによって、ポットが所有する資金全部を送金するトランザクションを構築することができる。ディーラーはまた、ハンドP_winに対するウィニング公開鍵を構築することができ、ウィニング償還トランザクションTx_winningsにおいて、ディーラーは資金をその公開鍵にロックする。

[0233] ウィニング公開鍵P_winは、どのプレーヤによっても構築できるが、勝者（このケースではプレーヤ1）だけが、S_winを用いて有効なデジタル署名を作成することによって、P_winにロックされているUTXOを償還するためにウィニング秘密鍵S_winを構築することが可能である、ということを再度強調しておく。

[0234] ショーダウンなしにハンドを決定すること
ここで提示されるプロバブリー・フェアーなNプレーヤ・プロトコル実装の重要な側面は、カード要素のキーのランダム化されたマッピングに関する情報は、必要とされる限りにおいて、
ランダム化写像γ：カード要素 → 公開鍵
を使用することによってのみ明らかにされる、ということである。

[0235] 言い換えれば、ディーラーは、カード要素の公開鍵へのマッピングを、以下の場合に明らかにするだけである：
・ディーラーがホール・カードを各プレーヤに配布している場合；
・ディーラーがコミュニティ・カードを公に全てのプレーヤに配布している場合；又は
・ディーラーが、ショーダウンの際に、プレーヤ各自のホール・カードを公開するように要求された場合。

[0236] 重要なことに、これは、ポーカーのハンドの最後にショーダウンが要求される場合に、プレーヤのホール・カードは明らかにされることを必要とするだけである、ということを意味する。

[0237] これは、ショーダウンを行うことなく、即ち、ショーダウンにおいてカード要素のホール・ホールへのマッピングを明らかにすることなく、ディーラーはプロバブリー・フェアーなNプレーヤの特定のハンドを決定できることを意味する。

[0238] これは重要なことであり、なぜならそれは、本件で提示されるプロバブリー・フェアーNプレーヤ・ポーカーの実装は、ブラッフィング（bluffing）を実現するために必要とされる情報の非対称性も保持しているからであり、ブラッフィングは当然にポーカーの本質的な側面である。

[0239] 言い換えれば、それは、テーブルについている他の全てのプレーヤがフォールドする結果、プレーヤがハンドに勝つことができることを意味する。この場合、ウィニング・プレーヤは、彼自身のホール・カードを明らかにすることを必要とせず、従って、プレーヤが首位をブラフしていたかどうかを漏洩することなく、フォールドしている他のプレーヤによって、勝っているようにだますことができる。

[0240] カード要素のディーラーの初期順序に対して真正証明するためにマークル・ツリーを使用することは、他のプレーヤの公開鍵にマッピングされているカードを明らかにすることなく、どのプレーヤの異議も、他の何れのプレーヤの異議と無関係に解決できることを保証する。

[0241] 例えば、プレーヤ1が、ディーラーから受け取ったカードに異議を唱えている場合、ディーラーは、（プルーフ・トークン及びマークル・プルーフを用いて）彼のカードは正しくマッピングされていることを、カード要素の、他のプレーヤのカード又は実際にはデッキ内の他の何らかのカードへのマッピング、に関する如何なる情報も明らかにすることなく、彼らがプレイしているかどうかによらず、証明することができる。これは明らかに重要であり、なぜなら、それは、一組のトランプの状態に関する情報を、1人のプレーヤに漏洩させるリスクを軽減するからであり、そうでなければ、テーブルについている他のプレーヤに対して不公平な優位性を彼らに与えることになってしまうからである。

[0242] 複数ポットの呼び出し
図26は、本件で提示されるプロバブリー・フェアーNプレーヤ・ポーカー実装の別の態様を示し、これは、ディーラーが、異なるポットに対応する異なる公開鍵を確立することによって、複数のポットを追跡することを可能にし、これは幾つもの有用なことを行えるようにする。

[0243] 第1に、ディーラーは、ハンドの間、各ポットの資金に対する管理を委任することができる。例えば‘低い価値のポット’及び‘高い価値のポット’のように、大きく変動する総価値のポットが複数存在する場合に、本件は、ディーラーが、高い価値のポットに対する管理を、より安全なシステムに委任することができ、これは、‘ハイ・ローラー’（high-rollers）だけがアクセス可能な特別な機能であってもよい。

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

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

[0246] ステートメント2.
ステートメント1の方法において、アウトプットのスクリプトは、複数の擬似乱数を生成するように、且つ複数の擬似乱数のうちの1つ、数個、又は全てに基づいて公開鍵のリストを生成するように構成されている。

[0247] ステートメント3.
ステートメント1又はステートメント2の方法において、前記アウトプットのスクリプトは、個々の擬似乱数の各々について、前記公開鍵のシーケンス内で前記個々の擬似乱数に対応する位置にある公開鍵を選択し、選択した公開鍵を、前記公開鍵のリストの先頭に配置することによって、前記公開鍵のリストを生成するように構成されている。

[0248] ステートメント4.
上記の任意のステートメントの方法において、写像を生成するステップを更に含み、前記写像は、前記公開鍵のリスト内の公開鍵を、前記ゲーム要素のリスト内のゲーム要素にマッピングすることを含む。

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

[0250] ステートメント6.
上記の任意のステートメントの方法において、前記公開鍵のシーケンスは公開鍵の1つ以上の第1セットを含み、前記公開鍵の第1セットのうちの少なくとも1つは個々のユーザーによって生成されている。

[0251] ステートメント7.
ステートメント6の方法において、前記公開鍵のシーケンスを取得するステップは、前記公開鍵の1つ以上の第1セットを、前記個々のユーザーから取得するステップを含む。

[0252] ステートメント8.
ステートメント6又はステートメント7の方法において、前記公開鍵のシーケンスは公開鍵の第2セットを含み、前記公開鍵の第2セットは前記オラクルにより生成されている。

[0253] ステートメント9.
上記の任意のステートメントの方法において、
前記ゲーム要素のリスト内のゲーム要素の各々について、個々のプルーフ・トークンを生成するステップを含み、前記プルーフ・トークンは、前記ゲーム要素のリスト内の前記ゲーム要素の個々の位置を表現している。

[0254] ステートメント10.
上記の任意のステートメントの方法において、前記ゲーム要素のリストのハッシュを生成するステップを含む。

前記ゲーム要素のリストのハッシュを生成するステップは、マークル・ツリーを生成するステップを含んでもよく、マークル・ツリーのリーフ・ノードのうちの少なくとも一部は、ゲーム要素のうちの各自のものを含む。

[0255] ステートメント11.
ステートメント10の方法において、前記ゲーム要素のリストのハッシュを生成するステップは：
マークル・ツリーを生成するステップを含み、前記マークル・ツリーは複数のリーフ・ノード・ペアを含み、各々のリーフ・ノード・ペアは第1リーフ・ノードと第2リーフ・ノードを含み、各リーフ・ノード・ペアにおける第1リーフ・ノードの各々は、ハッシュ関数を個々のゲーム要素に適用することによって生成され、各リーフ・ノード・ペアにおける第2リーフ・ノードの各々は、ハッシュ関数を個々のプルーフ・トークンに適用することによって生成され、前記第1リーフ・ノードは前記ゲーム要素のリストに従って並べられる。

[0256] ステートメント12.
ステートメント11の方法において、コミットメント・トランザクションを生成するステップを含み、前記コミットメント・トランザクションは、前記マークル・ツリーのルート・ノードを含んでいる。

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

[0258] ステートメント14.
上記の任意のステートメントの方法において、前記シード・データ・アイテムのセットは、前記オラクルにより生成されたオラクル・シード・データ・アイテムを含んでいる。

[0259] ステートメント15.
上記の任意のステートメントの方法において、個々の擬似乱数の各々は：
個々のハッシュ関数を、前記シード・データ・アイテムのセットの組み合わせに適用して個々のハッシュ結果を生成し；且つ
前記ゲーム要素のリスト内のゲーム要素の総数に基づいて或る数に前記個々のハッシュ結果をマッピングする；
ことによって生成される。

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

[0261] ステートメント17.
ステートメント15又はステートメント16の方法において、個々のハッシュ関数を適用するステップは、同じハッシュ関数を異なる回数適用するステップを含む。

[0262] ステートメント18.
ステートメント12又はそれに従属する任意のステートメントの方法において、前記コミットメント・トランザクションは、前記シード・データ・アイテムのセットを含む。

[0263] ステートメント19.
ステートメント18の方法において、前記コミットメント・トランザクションはインプットのセットを含み、個々のインプットの各々は、前記シード・データ・アイテムのセットのうちの各々のハッシュを含む。

[0264] ステートメント20.
ステートメント9又はそれに従属する任意のステートメントの方法において：
前記個々のユーザーの第1セットの各々に対して、前記プルーフ・トークンの個々の第1セットと、前記個々のプルーフ・トークンの各々によって表現される個々の位置にある前記個々のゲーム要素を指し示すものとを送信するステップを含む。

[0265] ステートメント21.
ステートメント9又はそれに従属する任意のステートメントの方法において：
前記個々のユーザーの第1セットのうちの1つ以上に対して、前記プルーフ・トークンの1つ以上の第2セットと、前記個々のプルーフ・トークンの各々によって表現される前記ゲーム要素のリストにおける個々の位置にある前記個々のゲーム要素を指し示すものとを送信するステップ；及び
前記個々のユーザーの第1セットのうちの1つ以上の各々に対して、及び前記プルーフ・トークンの1つ以上の第2セットにおけるプルーフ・トークンの各々について、秘密鍵の1つ以上のセットを送信するステップであって、各々の秘密鍵は、前記個々のプルーフ・トークンによって表現される前記ゲーム要素のリストにおける前記個々の位置にある前記個々のゲーム要素にマッピングされる個々の公開鍵に対応している、ステップを含む。

[0266] ステートメント22.
ステートメント11、ステートメント20、又はステートメント21の方法において：
個々のユーザーの各々に対して、個々のユーザーに送信される各プルーフ・トークンとペアにされる各ゲーム要素に対するマークル経路を送信するステップを含む。

[0267] ステートメント23.
ステートメント20ないし22のうちの何れかの方法において：
支払トランザクションを生成するステップを含み、前記支払トランザクションは、ウィニング公開鍵に対してロックされており、前記ウィニング公開鍵は公開鍵の組み合わせに基づいて生成され、前記公開鍵の組み合わせのうちの各々は、前記第1セットのユーザーのうちの少なくとも1人のユーザーに送信された個々のプルーフ・トークンによって表現される個々のゲーム要素にマッピングされている。

[0268] 即ち、公開鍵の組み合わせを生成するために使用される各々の公開鍵は、ゲーム要素にマッピングされており、組み合わせそれ自体がゲーム要素にマッピングされるのではない。

[0269] ステートメント24.
上記の任意のステートメントの方法において、前記ゲームはポーカーであり、前記ゲーム要素はトランプを表現している。

[0270] ステートメント25.
ブロックチェーンに含めるブロックチェーン・トランザクションであって：
トランザクションはアウトプットを含み、第1アウトプットは公開鍵のシーケンスを含み、前記アウトプットは、少なくとも1つの擬似乱数を生成するように構成されたスクリプトを含み、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ上のユーザー・シード・データ・アイテムを含み、前記スクリプトは、前記少なくとも1つの擬似乱数に基づいて公開鍵のリストを生成するように構成されており、前記公開鍵のリストにおける公開鍵の順序は、前記公開鍵のシーケンスにおける公開鍵の順序と比較して相違しており、公開鍵の総数はゲーム要素の総数に対応している。

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

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

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

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

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

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

Claims (28)

1. ゲームをプレイする際に使用するゲーム要素を擬似ランダムに選択するコンピュータが実行する方法であって、前記ゲームは一組のユーザーによりプレイされ、前記ゲーム要素は前記ゲームの結果を決定するために使用され、前記方法はオラクルにより実行され、前記方法は：
   シード・データ・アイテムのセットを取得するステップであって、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含む、ステップ；
   公開鍵のシーケンスを取得するステップ；
   ゲーム要素のリストを取得するステップであって、公開鍵の総数はゲーム要素の総数に対応している、ステップ；及び
   ゲーム・トランザクションの第1アウトプットを生成するステップであって、前記ゲーム・トランザクションはブロックチェーン・トランザクションであり、前記第1アウトプットは前記公開鍵のシーケンスを含み、前記アウトプットは、少なくとも1つの擬似乱数を生成するように構成されたスクリプトを含み、前記少なくとも1つの擬似乱数は前記シード・データ・アイテムのセットに基づいており、前記スクリプトは、前記少なくとも1つの擬似乱数に基づいて前記公開鍵のリストを生成するように構成されており、前記公開鍵のリストにおける公開鍵の順序は、前記公開鍵のシーケンスにおける公開鍵の順序と相違している、ステップ；
   を含む方法。
2. 請求項1に記載の方法において、前記ゲーム・トランザクションを、前記個々のユーザーのうちの1人以上及び／又は前記ブロックチェーン・ネットワークに送信するステップを更に含む、方法。
3. 請求項1又は請求項2に記載の方法において、前記アウトプットのスクリプトは、複数の擬似乱数を生成するように、且つ前記複数の擬似乱数のうちの1つ、数個、又は全てに基づいて前記公開鍵のリストを生成するように構成されている、方法。
4. 請求項1ないし3のうちの何れか一項に記載の方法において、前記アウトプットのスクリプトは、個々の擬似乱数の各々について、前記公開鍵のシーケンス内で前記個々の擬似乱数に対応する位置にある公開鍵を選択し、選択した公開鍵を、前記公開鍵のリストの先頭に配置することによって、前記公開鍵のリストを生成するように構成されている、方法。
5. 請求項1ないし4のうちの何れか一項に記載の方法において、写像を生成するステップを更に含み、前記写像は、前記公開鍵のリスト内の公開鍵を、前記ゲーム要素のリスト内のゲーム要素にマッピングするステップを含む、方法。
6. 請求項1ないし5のうちの何れか一項に記載の方法において、前記公開鍵のシーケンスは公開鍵の1つ以上の第1セットを含み、前記公開鍵の第1セットのうちの少なくとも1つは個々のユーザーによって生成されている、方法。
7. 請求項6に記載の方法において、前記公開鍵のシーケンスを取得するステップは、前記公開鍵の1つ以上の第1セットを、前記個々のユーザーから取得するステップを含む、方法。
8. 請求項6又は請求項7に記載の方法において、前記公開鍵のシーケンスは公開鍵の第2セットを含み、前記公開鍵の第2セットは前記オラクルにより生成されている、方法。
9. 請求項1ないし8のうちの何れか一項に記載の方法において：
   前記ゲーム要素のリスト内のゲーム要素の各々について、個々のプルーフ・トークンを生成するステップを含み、前記プルーフ・トークンは、前記ゲーム要素のリスト内の前記ゲーム要素の個々の位置を表現している、方法。
10. 請求項1ないし9のうちの何れか一項に記載の方法において、前記ゲーム要素のリストのハッシュを生成するステップを含む方法。
11. 請求項10に記載の方法において、前記ゲーム要素のリストのハッシュを生成するステップは：
    マークル・ツリーを生成するステップを含み、前記マークル・ツリーは複数のリーフ・ノード・ペアを含み、各々のリーフ・ノード・ペアは第1リーフ・ノードと第2リーフ・ノードを含み、各リーフ・ノード・ペアにおける第1リーフ・ノードの各々は、ハッシュ関数を個々のゲーム要素に適用することによって生成され、各リーフ・ノード・ペアにおける第2リーフ・ノードの各々は、ハッシュ関数を個々のプルーフ・トークンに適用することによって生成され、前記第1リーフ・ノードは前記ゲーム要素のリストに従って並べられる、方法。
12. 請求項11に記載の方法において、コミットメント・トランザクションを生成するステップを含み、前記コミットメント・トランザクションは、ブロックチェーン・トランザクションであり、前記マークル・ツリーのルート・ノードを含んでいる、方法。
13. 請求項12に記載の方法において、前記コミットメント・トランザクションを、前記個々のユーザーのうちの1人以上及び／又は前記ブロックチェーン・ネットワークに送信するステップを含む、方法。
14. 請求項1ないし13のうちの何れか一項に記載の方法において、前記シード・データ・アイテムのセットは、前記オラクルにより生成されたオラクル・シード・データ・アイテムを含んでいる、方法。
15. 請求項1ないし14のうちの何れか一項に記載の方法において、個々の擬似乱数の各々は：
    個々のハッシュ関数を、前記シード・データ・アイテムのセットの組み合わせに適用して個々のハッシュ結果を生成し；且つ
    前記ゲーム要素のリスト内のゲーム要素の総数に基づいて或る数に前記個々のハッシュ結果をマッピングする；
    ことによって生成される、方法。
16. 請求項15に記載の方法において、前記個々のハッシュ結果についての前記マッピングするステップは、前記総数を法とする、前記個々のハッシュ結果のモジュロ演算を行うステップを含む、方法。
17. 請求項15又は請求項16に記載の方法において、個々のハッシュ関数を適用するステップは、同じハッシュ関数を異なる回数適用するステップを含む、方法。
18. 請求項12又は請求項12に従属する請求項のうちの何れか一項に記載の方法において、前記コミットメント・トランザクションは、前記シード・データ・アイテムのセットを含む、方法。
19. 請求項18に記載の方法において、前記コミットメント・トランザクションはインプットのセットを含み、個々のインプットの各々は、前記シード・データ・アイテムのセットのうちの各々のハッシュを含む、方法。
20. 請求項9又は請求項9に従属する請求項のうちの何れか一項に記載の方法において：
    前記個々のユーザーの第1セットの各々に対して、前記プルーフ・トークンの個々の第1セットと、前記個々のプルーフ・トークンの各々によって表現される個々の位置にある前記個々のゲーム要素を指し示すものとを送信するステップを含む方法。
21. 請求項9又は請求項9に従属する請求項のうちの何れか一項に記載の方法において：
    前記個々のユーザーの第1セットのうちの1つ以上に対して、前記プルーフ・トークンの1つ以上の第2セットと、前記個々のプルーフ・トークンの各々によって表現される前記ゲーム要素のリストにおける個々の位置にある前記個々のゲーム要素を指し示すものとを送信するステップ；及び
    前記個々のユーザーの第1セットのうちの1つ以上の各々に対して、及び前記プルーフ・トークンの1つ以上の第2セットにおけるプルーフ・トークンの各々について、秘密鍵の1つ以上のセットを送信するステップであって、各々の秘密鍵は、前記個々のプルーフ・トークンによって表現される前記ゲーム要素のリストにおける前記個々の位置にある前記個々のゲーム要素にマッピングされる個々の公開鍵に対応している、ステップ；
    を含む方法。
22. 請求項11、請求項20、又は請求項21に記載の方法において：
    個々のユーザーの各々に対して、個々のユーザーに送信される各プルーフ・トークンとペアにされる各ゲーム要素に対するマークル経路を送信するステップを含む方法。
23. 請求項20ないし22のうちの何れか一項に記載の方法において：
    支払トランザクションを生成するステップを含み、前記支払トランザクションは、ウィニング公開鍵に対してロックされたブロックチェーン・トランザクションであり、前記ウィニング公開鍵は公開鍵の組み合わせに基づいて生成され、前記公開鍵の組み合わせのうちの各々は、前記第1セットのユーザーのうちの少なくとも1人のユーザーに送信された個々のプルーフ・トークンによって表現される個々のゲーム要素にマッピングされている、方法。
24. 請求項1ないし23のうちの何れか一項に記載の方法において、前記ゲームはポーカーであり、前記ゲーム要素はトランプを表現している、方法。
25. ブロックチェーンに含めるブロックチェーン・トランザクションであって：
    トランザクションはアウトプットを含み、第1アウトプットは公開鍵のシーケンスを含み、前記アウトプットは、少なくとも1つの擬似乱数を生成するように構成されたスクリプトを含み、前記少なくとも1つの第1擬似乱数は前記シード・データ・アイテムのセットに基づいており、前記シード・データ・アイテムのセットは、個々のユーザーにより生成された1つ以上のユーザー・シード・データ・アイテムを含み、前記スクリプトは、前記少なくとも1つの擬似乱数に基づいて公開鍵のリストを生成するように構成されており、前記公開鍵のリストにおける公開鍵の順序は、前記公開鍵のシーケンスにおける公開鍵の順序と相違しており、公開鍵の総数はゲーム要素の総数に対応している、トランザクション。
26. 請求項25に記載のトランザクションを格納したコンピュータ読み取り可能な記憶媒体。
27. コンピュータ装置であって：
    1つ以上のメモリ・ユニットを含むメモリ；及び
    1つ以上の処理ユニットを含む処理装置；
    を含み、前記メモリは前記処理装置において動作するように構成されたコードを格納しており、前記コードは、前記処理装置において実行されると、請求項1ないし24のうちの何れか一項に記載の方法を実行させるように構成されている、コンピュータ装置。
28. コンピュータ読み取り可能な記憶媒体に組み込まれるコンピュータ・プログラムであって、請求項27に記載のコンピュータ装置において実行されると、請求項1ないし24のうちの何れか一項に記載の方法を実行させるように構成されているコンピュータ・プログラム。

Images