特許 7636335 擬似ランダムデータ生成のためのコンピュータで実施される方法およびシステム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-02-17

(45)【発行日】2025-02-26

(54)【発明の名称】擬似ランダムデータ生成のためのコンピュータで実施される方法およびシステム

(51)【国際特許分類】

   G09C 1/00 20060101AFI20250218BHJP

   H04L 9/32 20060101ALI20250218BHJP

   G06F 21/60 20130101ALI20250218BHJP

   G06F 21/64 20130101ALI20250218BHJP

【ＦＩ】

G09C1/00 650B

H04L9/32 200B

H04L9/32 200E

G06F21/60 360

G06F21/64

【請求項の数】 21

(21)【出願番号】P 2021547304

(86)(22)【出願日】2020-01-27

(65)【公表番号】

(43)【公表日】2022-03-31

(86)【国際出願番号】 IB2020050599

(87)【国際公開番号】W WO2020165669

(87)【国際公開日】2020-08-20

【審査請求日】2022-12-28

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

(32)【優先日】2019-02-11

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

(73)【特許権者】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】クレイグ・スティーヴン・ライト

(72)【発明者】

【氏名】ジャック・オーウェン・デイヴィーズ

【審査官】青木 重徳

(56)【参考文献】

【文献】特表２００９－５０９２５０（ＪＰ，Ａ）

【文献】特表２００８－５２９０４２（ＪＰ，Ａ）

【文献】国際公開第２０１８／０２４２４２（ＷＯ，Ａ１）

【文献】特開２００３－０７６２７２（ＪＰ，Ａ）

【文献】特開２００２－２１５０３０（ＪＰ，Ａ）

【文献】米国特許出願公開第２００７／００７１２３３（ＵＳ，Ａ１）

【文献】佐古 和恵 ほか，ブロックチェーンを用いたオンラインゲーム用公平性を検証可能な乱数発生，２０１７年 暗号と情報セキュリティシンポジウム（ＳＣＩＳ２０１７）予稿集 ［ＵＳＢ］，日本，電子情報通信学会，2017年01月24日，1F2-4，pp. 1-4

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０９Ｃ １／００

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／６０

Ｇ０６Ｆ ２１／６４

(57)【特許請求の範囲】

【請求項1】

ブロックチェーンを用いて富籤を実装するためにプロセッサにより実行される方法であって、
複数の第1の参加者デバイスの各々から少なくとも1つのそれぞれの第1のデータアイテムを備える第1のデータを受信するステップと、
第2のデータを生成するために複数の前記第1のデータアイテムを組み合わせるステップと、
第3のデータを生成するために前記第2のデータの少なくとも一部に少なくとも1つの一方向性関数を適用するステップであって、前記一方向性関数または各々の前記一方向性関数が、入力データを受信して、前記入力データに基づいて出力データを生成するように適合され、前記入力データが、前記出力データおよび前記一方向性関数から推測可能ではない、ステップと、
前記第3のデータに基づいて、複数のアイテムからあるアイテムを選択するステップであって、複数の前記第1の参加者デバイスのうちの少なくとも1つが、前記選択されたアイテムへのアクセス権を有し、複数の前記第1の参加者デバイスのうちの前記少なくとも1つが、前記富籤の当籤者を含む、ステップと、
前記ブロックチェーン内に記録されるブロックチェーントランザクションを構築するステップであって、前記ブロックチェーントランザクションが、前記富籤の当籤基金を含む、ステップと
を備え、
前記第3のデータは、ロッキングスクリプトが前記富籤の前記当籤基金を前記選択されたアイテムにロックするように、前記ブロックチェーントランザクションのロッキングスクリプト内で生成され、
前記ブロックチェーントランザクションは、前記第1のデータアイテムを含むスクリプトによって払い戻し可能である、方法。

【請求項2】

前記第1のデータが、暗号化された形式で前記第1の参加者デバイスから受信される、請求項1に記載の方法。

【請求項3】

複数の前記第1の参加者デバイスの各々から少なくとも1つのそれぞれの第4のデータアイテムを備える第4のデータを受信するステップをさらに備え、前記第4のデータアイテムまたは各々の前記第4のデータアイテムが、前記第1の参加者デバイスに対応する前記第1のデータアイテムまたは各々の前記第1のデータアイテムに少なくとも1つの一方向性関数を適用することによって生成される、請求項1または2に記載の方法。

【請求項4】

前記第4のデータを複数の前記第1の参加者デバイスに送信するステップをさらに備える、請求項3に記載の方法。

【請求項5】

少なくとも1つの前記一方向性関数がハッシュ関数である、請求項1から4のいずれか一項に記載の方法。

【請求項6】

少なくとも1つの前記一方向性関数が、暗号システムのそれぞれの公開鍵－秘密鍵ペアの公開鍵および秘密鍵を関連付ける、請求項1から5のいずれか一項に記載の方法。

【請求項7】

前記暗号システムが楕円曲線暗号システムである、請求項6に記載の方法。

【請求項8】

少なくとも1つの前記第1のデータアイテムがそれぞれの第1のデータ署名の少なくとも一部を含む、請求項1から7のいずれか一項に記載の方法。

【請求項9】

少なくとも1つの前記第1のデータアイテムがそれぞれの第1のデジタル署名の少なくとも一部を含み、前記一部が秘密鍵およびエフェメラルキーに基づく、請求項8に記載の方法。

【請求項10】

少なくとも1つのそれぞれの第2のデジタル署名を複数の前記第1の参加者デバイスの各々から受信するステップをさらに備え、前記第2のデジタル署名が、対応する前記第1のデジタル署名と同じ秘密鍵を用いて署名される、請求項9に記載の方法。

【請求項11】

複数の前記第1の参加者デバイスの各々からそれぞれの第5のデータアイテムを備える第5のデータを受信するステップをさらに備え、前記第5のデータアイテムが、対応する前記第1のデジタル署名の一部であり、前記第1のデジタル署名が、前記第5のデータアイテムを対応する前記第1のデータアイテムと組み合わせることによって構築される、請求項9または10に記載の方法。

【請求項12】

前記第5のデータを複数の前記第1の参加者デバイスに送信するステップをさらに備える、請求項11に記載の方法。

【請求項13】

少なくとも1つの前記第5のデータアイテムが、エフェメラルキーに基づく、それぞれの第1のデジタル署名の少なくとも一部を含む、請求項11または12に記載の方法。

【請求項14】

前記第3のデータの生成に続いて、前記第1のデータを複数の前記第1の参加者デバイスに送信するステップをさらに備える、請求項1から13のいずれか一項に記載の方法。

【請求項15】

前記スクリプトの実行が、前記第1のデータアイテムから前記第3のデータを再生成する、請求項1に記載の方法。

【請求項16】

前記第3のデータが、複数の前記一方向性関数によって生成される、請求項1から15のいずれか一項に記載の方法。

【請求項17】

前記第3のデータが、少なくとも1つの前記一方向性関数の繰り返される適用によって生成される、請求項1から16のいずれか一項に記載の方法。

【請求項18】

前記第3のデータが、複数の第2の参加者デバイスによって生成される、請求項1から17のいずれか一項に記載の方法。

【請求項19】

前記選択が、暗号システムの公開鍵-秘密鍵ペアの公開鍵を選択するステップを備え、少なくとも1つの前記参加者デバイスが前記ペアの秘密鍵へのアクセス権を有する、請求項1に記載の方法。

【請求項20】

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

【請求項21】

コンピュータシステムの前記プロセッサによって実行された結果として、前記コンピュータシステムに請求項1から19のいずれか一項に記載の方法を実行させるコンピュータ実行可能命令が記憶される、非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は全般に、擬似ランダムデータ生成に関し、より具体的には、擬似乱数生成に関する。本開示は、限定はされないが、ブロックチェーントランザクションのための擬似乱数生成において使用するのに特に適している。

【背景技術】

【0002】

この文書では、すべての形式の電子的なコンピュータベースの分散型台帳を含むものとして、「ブロックチェーン」という用語を使用する。これらは、コンセンサスベースのブロックチェーンおよびトランザクションチェーン技術、認可型台帳および非認可型台帳、共有台帳、ならびにこれらの変形を含む。最もよく知られるブロックチェーン技術の応用はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。便宜的に、および説明のために、本明細書ではビットコインに言及することがあるが、本開示はビットコインブロックチェーンとともに使用することに限定されず、代替のブロックチェーンの実装とプロトコルが本開示の範囲内にあることに留意されたい。「ユーザ」という用語は、本明細書では人またはプロセッサベースのリソースを指すことがある。

【0003】

ブロックチェーンは、ブロックからなるコンピュータベースの非集中型の分散型システムとして実装されるピアツーピア電子台帳であり、ブロックはトランザクションからなる。各トランザクションは、ブロックチェーンシステムの参加者間でのデジタル資産の管理権の移行を符号化するとともに、少なくとも1つの入力および少なくとも1つの出力を含む、データ構造である。各ブロックは以前のブロックのハッシュを含むので、ブロックは一緒につながれるようになり、ブロックチェーンの発足以来ブロックチェーンに書き込まれているすべてのトランザクションの恒久的で変更不可能な記録を作成する。トランザクションは、入力および出力に、スクリプトとして知られる小さいプログラムが埋め込まれており、これが、トランザクションの出力にどのようにアクセスできるか、および誰がアクセスできるかを指定する。ビットコインプラットフォームでは、これらのスクリプトは、スタックベースのスクリプト言語を使用して書かれる。

【0004】

トランザクションがブロックチェーンに書き込まれるには、トランザクションは「妥当性確認」されなければならない。ネットワークノード(マイナー)は、各トランザクションが有効であることを確実にするように作業を実行し、無効なトランザクションはネットワークから拒絶される。ノードにインストールされるソフトウェアクライアントは、ロッキングスクリプトおよびアンロッキングスクリプトを実行することによって、未使用トランザクション(UTXO)に対してこの妥当性確認作業を実行する。ロッキングスクリプトおよびアンロッキングスクリプトの実行がTRUEであると評価される場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるには、トランザクションは、i)トランザクションを受信する第1のノードによって妥当性確認されなければならず、トランザクションが妥当性確認される場合、ノードはそれをネットワークの中の他のノードに中継し、ii)マイナーによって構築された新しいブロックに追加されなければならず、iii)マイニング、すなわち過去のトランザクションの公開台帳に追加されなければならない。

【0005】

暗号通貨の実装の使用について、ブロックチェーン技術が最も広く知られるが、デジタル起業家は、ビットコインが基礎とする暗号セキュリティシステムと、ブロックチェーンに記憶できるデータとの両方を使用して、新しいシステムを実装することを模索し始めている。暗号通貨の世界に限定されない、自動化されたタスクおよび処理のためにブロックチェーンを使用できれば、とても有利であろう。そのような解決策は、ブロックチェーンの利益(たとえば、改竄防止されたイベントの恒久的な記録、分散処理など)を利用しながら、それらの応用範囲をより広くすることが可能であろう。

【0006】

国際的な富籤産業は、とりわけインターネットおよびモバイルデバイスアプリケーションの発展により、成長を続けている。

【0007】

特に富籤のオンラインプラットフォームにおいてユーザを心配させる主な問題は、サービス提供者の公平性と信用に関係している。オンライン富籤が第三者により構築されるとき、参加者は、当籤商品が存在していることにも、これまで富籤自体に操作がなかったことにも、確信を持つことができない。そのような富籤では、ユーザには、当籤者を選択するために使用される処理がランダムで安全であることの保証がない。

【0008】

これらの問題のうちの第1のもの、すなわち当籤基金の存在に対する1つの可能な解決策は、ブロックチェーンにより提供される。富籤がブロックチェーン上のマルチパーティトランザクションとして構築される場合、積立賞金が存在することをすべての参加者が検証することができ、ブロックチェーンの性質は、分散型公開台帳上にその事実の変更不可能な記録が存在することを意味する。ブロックチェーンのこの使用は、当籤金の瞬時の払い戻し、国境を超えた無制約の参加、および富籤に関与する基金を監視する能力などの、いくつかの他の問題も解決する。

【0009】

そうすると、ブロックチェーンベースの富籤において、当籤者が選択される際のランダム性とセキュリティを確保するための方法を見つけることが残される。そのような適用例のためのプラットフォームとしてブロックチェーンを使用することによって、オンライン富籤に固有の両方の主要な問題を回避することが望ましい。

【0010】

ブロックチェーンベースの富籤の最新の例のうち、K. Farris、S. Ormond-Smith、L. Hills、Quanta Whitepaper (2018)、https://www.quantaplc.im/Quanta.pdfにおいて公開されたQuantaは言及に値する。これは、N. Parkhomenko、K. Katsev、TrueFlip Whitepaper(2016)、https://trueflip.io/TrueFlip%C2%A9%20Whitepaper.pdf?newにおいて公開された、Ethereumブロックチェーン、およびTrueFlip上で運営される。TrueFlipプロトコルにおけるランダム性は、確証されたブロックハッシュを使用することによって生成され、これは、当籤番号を生成するための(オープンソース)アルゴリズムに組み込まれる。

【0011】

当籤番号をランダムに生成するために使用されるオープンソースコードなどの、非集中化および透明性の要素の存在にもかかわらず、多くのプロセスは、TrueFilpプロトコルを発明したエンティティにより管理され、多数のオフチェーントランザクションを伴う。

【0012】

一般に、まだ解決されていない主な問題の1つは、エントロピーの信頼でき検証されているソースと、ブロックチェーンの動作およびスクリプトと互換性のある暗号学的にセキュアな乱数生成器とを見つけることという問題である。

【0013】

P. Strateman、New Opcodes (2016)、https://www.elementsproject.org/elements/opcodes/において公開された、提案された"OP_DETERMINISTICRANDOM"などの新しいオペコードが、スクリプト内で乱数を生成するために使用され得ることは、想起可能である。現在提示されるこれらの解決策は問題をなくすのではなく、むしろ、良い行動への動機を与えて、前記動機は調整可能である。

【0014】

しかしながら、提案される解決策についての具体的な技術上の問題はさておき、それらのすべてが、既存のビットコインスクリプトライブラリへと新しいオペコードを導入することを必要とする点で根本的に問題がある。これは、背後にあるブロックチェーンの攻撃対象領域を増やし、富籤およびゲームのためのプラットフォームとしてそれをまとめて使用するための根拠を弱くするので、望ましくない。

【先行技術文献】

【特許文献】

【0015】

【文献】国際公開第2017/145016号

【非特許文献】

【0016】

【文献】K. Farris、S. Ormond-Smith、L. Hills、Quanta Whitepaper (2018)、https://www.quantaplc.im/Quanta.pdf

【文献】N. Parkhomenko、K. Katsev、TrueFlip Whitepaper(2016)、https://trueflip.io/TrueFlip%C2%A9%20Whitepaper.pdf?new

【文献】P. Strateman、New Opcodes (2016)、https://www.elementsproject.org/elements/opcodes/

【文献】S. Blake-Wilson、D. Brown、P. Lambert、Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), Network Working Group (2002)、https://tools.ietf.org/html/rfc3278

【発明の概要】

【発明が解決しようとする課題】

【0017】

したがって、ブロックチェーン上で使用するための、乱数を生成するための方法を提供することが望ましい。

【0018】

そのような改善された解決策がここで考案された。

【課題を解決するための手段】

【0019】

したがって、本開示によれば、添付の特許請求の範囲において定義されるような方法が提供される。

【0020】

本開示によれば、データを擬似ランダムに生成する方法が提供されてもよく、この方法は、
複数の第1の参加者の各々から少なくとも1つのそれぞれの第1のデータアイテムを備える第1のデータを受信するステップと、
第2のデータを生成するために複数の前記第1のデータアイテムを組み合わせるステップと、
第3のデータを生成するために前記第2のデータの少なくとも一部に少なくとも1つの一方向性関数を適用するステップとを備え、その一方向性関数または各々の前記一方向性関数は、前記入力データに基づいて入力データを受信して出力データを生成するように適合され、前記入力データは、前記出力データおよび前記一方向性関数から推測可能ではない。

【0021】

複数の第1の参加者からのデータに少なくとも1つの一方向性関数を適用することによって、これは、第3のデータが第1の参加者のいずれによっても予測されることが不可能であり、したがって擬似ランダムであるという利点をもたらす。ブロックチェーントランザクションの場合、これは、大きな計算オーバーヘッドなしで擬似ランダムデータ/乱数生成を可能にするというさらなる利点をもたらす。

【0022】

前記第1のデータは、暗号化された形式で前記第1の参加者によって受信されてもよい。

【0023】

これは、セキュアな通信を提供することによってセキュリティを高めるという利点をもたらす。

【0024】

方法はさらに、複数の前記第1の参加者の各々から少なくとも1つのそれぞれの第4のデータアイテムを備える第4のデータを受信するステップを備えてもよく、その第4のデータアイテムまたは各々の前記第4のデータアイテムは、前記第1の参加者に対応するその第1のデータアイテムまたは各々のそれぞれの前記第1のデータアイテムに少なくとも1つの一方向性関数を適用することによって生成される。

【0025】

これは、第1のデータアイテムが変えられていないことを検証することによって、セキュリティを高めることを可能にするという利点をもたらす。

【0026】

方法はさらに、前記第4のデータを複数の前記第1の参加者に送信するステップを備えてもよい。

【0027】

これは、前記第1のデータが変えられていないことを前記第1の参加者が独立に確認することを可能にするという利点をもたらす。

【0028】

少なくとも1つの前記一方向性関数はハッシュ関数であってもよい。

【0029】

少なくとも1つの前記一方向性関数は、暗号システムのそれぞれの公開鍵-秘密鍵ペアの公開鍵および秘密鍵を関連付けてもよい。

【0030】

暗号システムは、楕円曲線暗号システムであってもよい。

【0031】

ブロックチェーントランザクションの場合、これは、他の目的で利用可能なハッシュ関数が容易に使用されることを可能にするという利点をもたらす。

【0032】

少なくとも1つの前記第1のデータアイテムは、それぞれの第1のデジタル署名の少なくとも一部を含んでもよい。

【0033】

これは、デジタル署名アルゴリズムによるランダム整数生成が使用されることを可能にし、それにより、上で定義された方法により生成されるランダム性に加えて、前記第1のデータアイテムの生成にランダム性が追加されることも可能にするという利点をもたらす。

【0034】

少なくとも1つの前記第1のデータアイテムは、秘密鍵およびエフェメラルキーに基づく、それぞれの第1のデジタル署名の少なくとも一部を含んでもよい。

【0035】

方法はさらに、少なくとも1つのそれぞれの第2のデジタル署名を複数の前記第1の参加者の各々から受信するステップを備えてもよく、前記第2のデジタル署名は、対応する前記第1のデジタル署名と同じ秘密鍵を用いて署名される。

【0036】

これは、第1のデジタル署名と第2のデジタル署名の両方が同じ秘密鍵を使用して署名されたことの検証が行われることを可能にし、それにより、第1のデータが変えられていないことの検証を可能にするという利点をもたらす。また、ブロックチェーントランザクションの場合、スクリプトにおいてデジタル署名アルゴリズムを使用して、署名検証が容易に行われ得る。

【0037】

方法はさらに、複数の前記第1の参加者の各々からそれぞれの第5のデータアイテムを備える第5のデータを受信するステップを備えてもよく、前記第5のデータアイテムが対応する前記第1のデジタル署名の一部であり、前記第1のデジタル署名が、前記第5のデータアイテムを対応する前記第1のデータアイテムと組み合わせることによって構築される。

【0038】

方法はさらに、前記第5のデータを複数の前記第1の参加者に送信するステップを備えてもよい。

【0039】

これは、前記第1のデータアイテムが変えられていないことを各々の第1の参加者が独立に確認することを可能にするという利点をもたらす。

【0040】

少なくとも1つの前記第5のデータアイテムは、エフェメラルキーに基づく、それぞれの第1のデジタル署名の少なくとも一部を含んでもよい。

【0041】

これは、ブロックチェーンスクリプトの中のデジタル署名アルゴリズムによって容易に生成されるという利点をもたらし、第1のデータの生成にさらなるランダム性を追加することによってセキュリティをさらに高める。

【0042】

方法はさらに、前記第3のデータの生成に続いて、前記第1のデータを複数の前記第1の参加者に送信するステップを備えてもよい。

【0043】

これは、第3のデータを生成するための機構が検証されることを可能にするという利点をもたらす。

【0044】

第3のデータは、前記第1のデータアイテムを含むスクリプトによって払い戻し可能なブロックチェーントランザクションの一部を形成してもよい。

【0045】

これは、スクリプトが実行されると、ブロックチェーン上で前記第1のデータアイテムを自動的に公開状態にし、それにより、第3のデータの生成のプロセスを自動的に検証可能にするという利点をもたらす。

【0046】

前記スクリプトの実行は、前記第1のデータアイテムから前記第3のデータを再生成してもよい。

【0047】

これは、第3のデータを生成するプロセスの効率的な検証という利点をもたらす。

【0048】

第3のデータは、複数の前記一方向性関数によって生成されてもよい。

【0049】

これは、セキュリティを高めるという利点をもたらす。

【0050】

第3のデータは、少なくとも1つの前記一方向性関数の繰り返される適用によって生成されてもよい。

【0051】

これは、セキュリティを高めるという利点をもたらす。

【0052】

第3のデータは、複数の第2の参加者によって生成されてもよい。

【0053】

これはセキュリティを高めるという利点をもたらし、それは、単一の信頼できる第2の参加者が、プロセスの実行の成功を可能にするのに十分なランダム性を提供するからである。

【0054】

方法はさらに、前記第3のデータに基づいて、複数のアイテムからあるアイテムを選択するステップを備えてもよい。

【0055】

前記選択は、暗号システムの公開鍵-秘密鍵ペアの公開鍵を選択するステップを備えてもよく、少なくとも1つの前記参加者は前記ペアの秘密鍵へのアクセス権を有する。

【0056】

本開示はシステムも提供し、このシステムは、
プロセッサと、
プロセッサによる実行の結果として、本明細書において説明されるコンピュータで実施される方法の任意の実施形態をシステムに実行させる、実行可能命令を含むメモリと
を備える。

【0057】

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

【0058】

本開示のこれらおよび他の態様は、本明細書において説明される実施形態から明らかになり、それを参照して解明される。本開示の実施形態は、ここで単なる例として、添付の図面を参照して説明される。

【図面の簡単な説明】

【0059】

【図1】本開示を具現化する方法を使用して数を擬似ランダムに生成するためのビットコインスクリプトの図である。

【図2】本開示を具現化するブロックチェーン富籤の開始トランザクションの図である。

【図3】本開示を具現化するブロックチェーン富籤のオラクルトランザクションの図である。

【図4】本開示のさらなる実施形態のブロックチェーン富籤のオラクルトランザクションの図である。

【図5】本開示を具現化するブロックチェーン富籤の当籤金払い戻しトランザクションの図である。

【図6】図4のオラクルトランザクションによって阻害される基金を払い戻すためのビットコインスクリプトの図である。

【図7】様々な実施形態が実施され得るコンピューティング環境を示す概略図である。

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

【0060】

ブロックチェーン上でのランダム性

【0061】

運に基づくゲームアルゴリズムをビットコインスクリプトに入れることを可能にするために、ランダムプロセスをブロックチェーンに組み込むための新しい方法を着想することが望ましい。これは、提示される方法が、スクリプトにおいて生成され使用されるべき乱数の以下の性質を確実にしなければならないことを意味する。
(1)予測不可能: 結果を決定するために使用されるべき乱数は、基金が運ベースのイベントにコミットされる前に予測可能であるべきではない。
(2)決定論的: 生成される乱数は、最初の生成の後のすべての時間において同じ入力から再現可能でなければならない。
(3)検証可能: すべてのノードが生成された数について合意するように、すべてのノードが選ばれた乱数を再現して検証することが可能でなければならない。

【0062】

本出願において提案される方法は、ブロックチェーン上での乱数の生成において上記のすべての性質が維持されることを確実にする。「ビットコイン」という用語は、本明細書では、ビットコインプロトコルから派生するプロトコルのすべての変形を含むものとして使用される。

【0063】

基本的な概念

【0064】

擬似乱数生成器

【0065】

一般に、乱数は、真にランダムまたは擬似ランダムという2つのカテゴリに該当する。行われるべき区別は、真のランダム性は達成が非常に難しく自然の営みまたは電子的なノイズに通常は依存するということである。

【0066】

代替的に、擬似ランダム性は、擬似乱数N_kのシーケンスを生成するためのアルゴリズムを初期化するために単一の高エントロピーシード値V_Seed(真にランダム)を使用することによって達成され、kは乱数生成器V_Seed→(N₁,N₂,…,N_k)の周期である。

【0067】

最も実用的な応用では、擬似乱数生成器は、それらの性質が適している場合に使用される。ランダム性がブロックチェーンに組み込まれている場合、擬似乱数生成のための機構は暗号学的にセキュアであることも必要とされる。これは、通常の定義によりCSPRNG(暗号学的セキュア擬似乱数生成器)と呼ばれる。

【0068】

一般に、CSPRNGは決定論的であるので、V_Seedを知っている何者によっても検証可能な数のシーケンスを生成する。そのような生成器は、2つの主要な問題を除き、ブロックチェーンの応用の目的に適している。

【0069】

第1に、長いアルゴリズムが、既知のCSPRNGからビットコインスクリプト言語へと組み込まれる必要があり、これは、計算オーバーヘッドを増やし、アルゴリズムによって生成される乱数が機能する機会を制限する。

【0070】

加えて、真にランダムであるものとして分類されるのに十分なエントロピーを有するシード値V_Seedを提供することが可能であるかという問題がまだある。現在、そのようなシードをスクリプト内で生成するための機構も、生成される乱数が予測不可能であるという要件(1)を満たすような方法で払い戻しスクリプトへの入力として外部シードを使用するための機構も存在しない。

【0071】

ハッシュ関数

【0072】

ブロックチェーンの構築は、ハッシュ関数の使用と、その固有の性質に左右される。ビットコイントランザクションの場合、ハッシュ関数Hは、任意のデータ構造Xをとり256ビットの数

【数1】

を出力する一方向性の決定論的な関数として定義される。

【0073】

【数2】

【0074】

SHA-256などのハッシュ関数は、一方向性のランダムオラクルとして振る舞うという事実を理解されたい。つまり、ハッシュYがユーザに知られていない原像Xから計算される場合、ユーザがXを発見するのは計算的に難しい。

【0075】

ハッシュ関数の性質は、単一のビットのみの値が異なる、2つの256ビットのデータ構造のハッシュが、完全に無関係であるものとして扱われ得るというものである。言い換えると、ユーザが原像の全体を知らない限り、ハッシュ値は、ユーザに関して真の乱数として振る舞う。

【0076】

これは、入力される原像Xの全体を管理下に置く関係者が1人もいないという仮定のもとで、ハッシュ値Y、またはその何らかの関数を単に用いて、それを、生成されることが意図される単一の乱数Rとして扱うことが可能であることを意味する。
未知のXに対して、R:= R and:=Y=H(X)

【0077】

それを拡張すると、(k+1)-ランダム値の乱数シーケンスS_Rが、同じ引数を使用して初期乱数R₀の繰り返されるハッシュにより生成されることがある。
R₀=H(X₀); R₁=H(R₀); R_k=H(R_k-1)
S_R=(R₀,R₁,…,R_k)

【0078】

ハッシュ関数は決定論的であるので、あらゆる関係者が、使用される具体的なハッシュ関数およびシードとして働く初期の原像X₀の知識のみで、シーケンスS_R全体を再現することがあることに留意されたい。

【0079】

ランダムシーケンスが生成されるときにこの初期の原像が公開される場合、あらゆるノードが、シーケンスがこの原像に対応することを独立に検証してもよい。

【0080】

そうすると、乱数を生成することに関与するどの1人の関係者も初期の原像X₀の全体を操作できないことを条件とした場合にのみ、上記の基準(1)および(2)を満たすスクリプト内で使用されるべき乱数シーケンスを生成するために、ハッシュ関数が使用されてもよいことが明らかである。

【0081】

代替的な一方向性関数

【0082】

一般に、「ハッシュ関数」という用語が、より広い関数の分類の中で、特定のタイプの一方向性関数を指すために本出願において使用され、それは、ハッシュ関数がビットコインスクリプトにおいて既存のオペコードを有するからである。しかしながら、本明細書のハッシュ関数の任意の事例の代わりに、代替の一方向性関数が使用され得ることが着想可能である。2つの例は、
1. 楕円曲線(EC)点乗算 - 秘密鍵からEC公開鍵を生成するために使用される関数E(x)=x・G、ここでGは楕円曲線の基点であり、"・"はEC点乗算の演算子である。xを与えられるとE(x)を計算することは簡単であるが、E(x)を与えられてGを決定することは計算的に難しいので、これは一方向性関数である。
2. Rabin関数 - 関数R(x)=x² mod N、ここでpとqをともに素数として、N=pqである。平方R(x) modulo Nを発見するのは簡単であるが、R(x)とNを与えられて平方根±xを発見するのは、Nを因数分解してpとqを発見するのと同じくらい難しく、これは計算的に困難である。

【0083】

デジタル署名

【0084】

自分の秘密鍵S_Aを使用してメッセージハッシュH(m)のためのデジタル署名を作成することを望む、プレーヤAliceを考える。Aliceは、ECC(secp256k1規格によって定義されるような楕円曲線を使用する、楕円曲線暗号)に従って、自分の秘密鍵と関連付けられる公開鍵P_Aを有し、Gは次数nの楕円曲線の基点である。
P_A=S_A・G

【0085】

作成される必要のある、デジタル署名の2つの成分rおよびsがある。Aliceは、乱数

【0086】

【数3】

【0087】

としてエフェメラルキーを生成し、これを使用して、署名の部分rを
(R_x,R_y)=k・G
r=R_x
として導出する。

【0088】

次いで、署名の部分sが、このrから、Aliceの秘密鍵、Aliceのハッシュされたメッセージ、およびエフェメラルキーと組み合わせて、
s=k^-1 (H(m)+S_A*r) mod n
として導出される。

【0089】

rとsを連結することによって、メッセージハッシュのECDSAデジタル署名として知られるデータ構造が作成される。
Sig P_A=(r,s)

【0090】

値rとsが別々に与えられると、演算子OP_CATを使用して、完全な署名がビットコインスクリプトにおいて構築されてもよい。署名が再構築されるとき、それは、ビットコインスクリプトにおいて使用されるべき標準的なDER(S. Blake-Wilson、D. Brown、P. Lambert、Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), Network Working Group (2002)において開示される、Distinguished Encoding Rules、https://tools.ietf.org/html/rfc3278)フォーマット[付録5.1]でなければならない。この点は、乱数を生成するために以下で論じられる署名方法を使用するときに重要になる。

【0091】

方法

【0092】

ブロックチェーンを使用して乱数を生成するための提案される一般的な方法には、3つの変形がある。各方法は、乱数を作成することに参加する複数の関係者を伴う。

【0093】

第1の方法は、セキュアな乱数を生成するためにハッシュ原像の組合せを使用するが、第2の方法は、いくつかの署名からのs成分の組合せを使用する。最後に、2つの方法のハイブリッドが提案される。

【0094】

各々の場合において、セキュアなランダム整数R_N∈{0,N-1}を生成することが意図される。

【0095】

ハッシュ方法

【0096】

プレーヤの形式のN人の第1の参加者がいて、その各々が自分の固有の公開ハッシュ値Y_i=H(X_i)を作り、各プレーヤが自分の固有の秘密原像X_iの形式の第1のデータアイテムを選ぶことが規定されることを考える。ハッシュ関数の性質は、公開ハッシュ値の知識を与えられてもいずれのプレーヤも別の原像を推測できないという想定を可能にする。

【0097】

プレーヤは次いで、オラクルの形式で秘密原像X_iを第2の参加者に送信する(方法は、ブラインドまたはそれ以外という、両方のタイプのオラクルへと一般化される)。これは、たとえば、国際公開第2017/145016号において概説されるような秘密値分散技法を介して行われ得るが、原像をオラクルに通信するためのセキュアチャネルまたは機構を提供するあらゆる方法が使用され得る。

【0098】

オラクルが次いで、以下の方法を介して乱数R_Nを生成する。

【0099】

1. オラクルが、各プレーヤによって提供される原像に対してY_i=H(X_i)であることを検証する。

【0100】

ハッシュ値は、原像がオラクルに送信される前にすでに公開されていることを思い出されたい。これは、元々各プレーヤによって供給されるような正しい原像を、オラクルが提供されることを確実にする。ブロックチェーン上では、これらの公開値は変更不可能であるので、原像を送信した後にプレーヤによって変更されることは不可能である。

【0101】

この検証ステップは、すべてのプレーヤが選ばれた秘密原像をオラクルに供給するまで、オラクルが乱数を生成することに進まないことを確実にする。

【0102】

2. オラクルがR_Nを

【数4】

として計算する

【0103】

すべてのN個の元の原像値X_iをどのプレーヤも知らないこと条件とした場合にのみ、R_Nは1人1人のプレーヤに関する乱数であることを、上記から思い出されたい。
この方法では、すべての原像が、プレーヤによって秘密に保たれ、オラクルへセキュアに通信される。これは、関係するすべてのプレーヤを管理下に置かない限り、悪意のある関係者がすべてのこれらの入力を知る可能性がある方法がないことを意味する。この場合、敵対者は、自分のみにより使用される乱数を操作するだけであろう。

【0104】

最低1人の本物のプレーヤがいるすべての他のシナリオにおいて、ハッシュ関数の説明された性質は、敵対者が有利な方法でR_Nを操作できないことを意味する。これは、敵対者がすべてのN-1人の他のプレーヤを管理下に置くときでも当てはまる。したがって、いずれの関係者もこの方法により生成される乱数に影響を与えて、別の関係者に悪影響を及ぼし得る方法はない。原像X_iの加法"+"加算がこの事例において使用されており、それは、これがビットコインスクリプトにおいて実装するのが簡単であるが、上記の加算と類似する、連結などの異なる演算子を連続で使用することが可能であるからであることに留意されたい。

【0105】

そうすると、(1)プロセスに関与するいずれの関係者にも予測不可能であり、かつ(2)決定論的なプロセスを介して再現可能であるように生成される、乱数R_Nがある。上述の最終的な要件である、乱数が(3)検証可能であることも満たされることが、以下で示される。拡張として、乱数シーケンスは、R_Nの繰り返されるハッシュによってオラクルによっても生成されてもよい。

【0106】

署名方法

【0107】

ここで、その各々が、署名Sig P_iと、そのs'成分が秘密に保たれる第2の署名Sig P_i'の一部を形成するランダム値r_i'とを公開する、N人のプレーヤの形式の第1の参加者を考える。
Sig P_i=(r_i,s_i)
Sig P_i'=(r_i', s_i')

【0108】

両方の署名が公開鍵P_iの同じ所有者に対応することが検証され得るように、同じ秘密鍵S_iを使用して両方の署名が(上で言及された同じECDSA規格によって)署名されることが重要である。
P_i=S_i・G

【0109】

プレーヤは次いで、自分の秘密s_i'値の形式である第1のデータアイテムをオラクルの形式である第2の参加者に送信し、これはやはり、たとえば国際公開第2017/145016号において概説されるような秘密共有方法を介して、または別様にセキュアに行われる。

【0110】

オラクルが次いで、以下の方法を介して乱数R_Nを生成する。

【0111】

1. オラクルが、Sig P_i'を構築し、それが各プレーヤに対するSig P_iと同じエンティティに対応することを検証する。
この第2の署名は、付録1に示されるようなDER規格を使用して、公開r_i'値を秘密s_i'値と連結することによって構築される。オラクルは次いで、両方の署名に標準的なECDSA署名検証アルゴリズムを適用し、それらが公開鍵P_iの所有者によって共通に署名されたことを確証する。これは、別の関係者が、所与のr_i'値のための自分の固有の署名を提供することによって乱数に影響を及ぼすことができないことを確実にする。

【0112】

2. オラクルがR_Nを

【数5】

として計算する
オラクルが、第1のデータアイテムの合計の形式で第2のデータを生成し、次いで、第2のデータのハッシュの形式で第3のデータを生成する。これは、ECCにおいて秘密鍵から公開鍵を生成する一方向のプロセスとの一方向性ハッシュ関数の類似性により、上で説明されたハッシュ方法において概説される同じ性質を受け継ぐ。

【0113】

置換Y_i→P_iおよびX_i→s_i'が行われる場合、類似性は明らかであり、上で説明されたハッシュ方法のステップ2において提示されるコメントは、この場合にも当てはまる。

【0114】

上で説明されたハッシュ方法のように、ここで、関与するあらゆる関係者に対して予測不可能であり、かつ検証可能であるような方法で、乱数R_Nが生成され、上で概説された基準(1)および(2)を満たす。

【0115】

署名方法およびハッシュ方法は、互いに直接類似しており、乱数生成のためのそれぞれの方法の主要な特性を共有することが明らかにされるべきである。具体的には、両方の方法が、それぞれハッシュ方法および署名方法のためのX_iおよびs_i'という、秘密値を生成することを各ユーザが担当することを必要とする。ここで署名方法を使用するさらなる利点は、秘密を選ぶ動作はECDSA手順のもとですでに標準化されているが、任意のハッシュ原像を選ぶことは標準化されていないということである。

【0116】

署名方法において、オラクルに送信される秘密値s_i'を直接検証するための方法は、それに付随した主要な署名Sig P_i=(r_i,s_i)との比較により、対応する公開値r_i'の元の提案者により提供されている。この検証は、ハッシュ方法における唯一の暗黙的な検証である。

【0117】

スクリプト内でのR_Nの計算

【0118】

両方の方式において、乱数R_Nは、(1)予測不可能であることと(2)決定論的であることとの両方であるという、上で概説された要件を満たしている。乱数が(3)検証可能であるという第3の基準を本開示の方法がどのように満たすかが、以下で詳しく説明される。

【0119】

これは、R_Nが正しい方法で生成されていることを、すべてのネットワークピアが独立に検証する方法がなければならないことを意味する。これは、R_N自体が計算されてトランザクションのロッキングスクリプトにおいて使用されることを要求することによって達成される。このようにして、すべての以前は秘密であったs_i'値が、このスクリプトの一部としてブロックチェーン上で公開され、これは、ハッシュ関数Σ_is_i'の入力原像を構築することによって乱数を誰でも検証できることを意味する。
以下の形式のスクリプトが、所望のランダム整数R_N∈{0,N-1}を生成するために使用されるものとして提案される。
<R_N>=<s₁'> <s₂'>…<s_N'> OP_ADD…OP_ADD OP_HASH256 <N> OP_MOD
ここで、演算子"OP_ADD"のN-1回の使用と、N個の秘密値がある。

【0120】

本出願において提示される応用では、<R_N>がこのスクリプトを指すために使用される。このスクリプトは、ハッシュ原像、部分的な署名、およびこれらの組合せを含む、一般化された秘密値のために使用され得ることに留意されたい。図1は、このスクリプトが乱数を生成するためにどのように使用されるかを示す。

【0121】

トランザクションのための完全な払い戻しスクリプトは、各原像が正しいコミットされたハッシュに対応すること、各々の秘密署名の構成要素が公開の構成要素と組み合わさって予想される署名を形成すること、および各々の供給された値が正しいプレーヤから来たことの検証を含み得る[付録2]。

【0122】

組み合わせられた方法

【0123】

これまでに提示された方法は、生成される乱数の結果に影響を及ぼすことを試みる悪意のある関係者に対して堅牢である。しかしながら、生成される乱数のセキュリティおよび予測不可能性を高めるために、ハッシュ方法および署名方法が拡張されて組み合わせられることがある多くの方法がある。

【0124】

2つの方法の最も簡単な組合せは、各プレーヤが、ハッシュ値Y_iと署名Sig P_i、ランダム値r_i'、およびそれらの公開鍵P_iを公開することである。次いで、オラクルがランダム値を

【数6】

として生成してもよく、各プレーヤは、二次的な署名Sig P_i'=(r_i',s_i')を内密に計算している。"+"演算子は、本出願におけるすべての加算のための加法または連結であり得る。加法または連結演算子"+"はここで、XORなどの別の演算子による別の実装において置き換えられ得ることにも留意されたい。

【0125】

2つの方法のうちの1つを個別に拡張することが代わりに望まれる場合、複数のオラクルが呼び出されてプレーヤが各々複数のハッシュ値Y_iまたは二次的なr_i'値を提供することを、課すことが可能である。たとえば、2つのオラクルがハッシュ方法を使用して呼び出される場合、乱数R_Nは

【数7】

として計算されてもよく、第1のオラクルは、原像の1つのセットの合計X_i,1を第2のオラクルに送信し、第2のオラクルは、原像の第2のセットの合計X_i,2にこれを加算して、乱数を計算する。

【0126】

いくつかのオラクルを呼び出すことによって、オラクルが悪意のあるユーザによりどうにかして買収されるリスクがなくなる。多数のオラクルにこれを拡張することで、より大きい計算および時間のオーバーヘッドと引き換えに、すべてのオラクルが共謀するリスクが減る。これらの方法は、乱数がセキュアにかつ予測不可能に生成されるには、単一のオラクルが本物であるだけでよいことを確実にすることに留意されたい。

【0127】

適用例

【0128】

本出願において説明される乱数生成の方法のために、使用事例が説明される。第1の適用例は、「ハウス」の役を務める関係者がいるシナリオといないシナリオの両方において考慮される、N人のプレーヤが関与するブロックチェーン富籤の文脈においてである。第2の適用例は、N面のサトシダイスゲームに対するものであり、プレーヤはハウスのいる単純な運のゲームに参加する。ブロックチェーンを使用して乱数を生成することのより一般的な用途が考えられる。

【0129】

富籤

【0130】

関連する公開鍵P_i、∀i∈{1,N}を伴うN人のプレーヤのグループを考える。これらのプレーヤが関与する富籤が構築され、当籤基金はランダムに選択された公開鍵P_Wの所有者にロックされる。

【0131】

富籤の構造は、3つのトランザクション
(i)開始トランザクション
(ii)オラクルトランザクション
(iii)当籤金払い戻しトランザクション
を備え、当籤基金をP_Wにロックするために使用される乱数のセキュアな生成のために1つのオラクルを呼び出す。

【0132】

そのような富籤では、各プレーヤが1/Nの確率でN×xビットコインを獲得する等しい可能性を有することが保証され、xは富籤券の最初の買付値である。
当籤した関係者が自分の賞金を請求しない場合に当籤基金を回収してもよい、「ハウス」が富籤の一部として含まれるような事例も、別に考えられる。
この場合、各プレーヤは、1/(N+1)の確率でr+(N×x)ビットコインを獲得する可能性を有し、rはハウスの買付寄与である。

【0133】

開始トランザクション

【0134】

1. 各プレーヤは、ブロックチェーン富籤券の買付として、開始トランザクションにxビットコインという共通の価値を寄付する。
このトランザクションは、N個の入力および1個の出力を備え、すべての参加者のためのブロックチェーン富籤券の販売のデジタル地点を表す。

【0135】

2. 買付に加えて、各プレーヤは、標準的なOP_DROPステートメントに存在する公開値を入力として含める。
この値は、使用されるべき乱数生成方法に依存する。

【0136】

この実装形態では、署名方法が使用されるので、供給される値はランダム値r_i'であり、これは、そのs_i'成分が秘密に保たれる署名Sig P_i'=(r_i',s_i')を形成する。

【0137】

3. 最後に、各プレーヤが自分の公開鍵P_iおよびそれに対応する署名Sig P_i=(r_i,s_i)を提供する。
これは、トランザクションが単一のrN×x出力を生成するのに十分な入力を含むまで、すべてのプレーヤについて行われる。この出力は、オラクルP_Oに対応する公開鍵に支払われる。

【0138】

開始トランザクションの構造が図2に示される。

【0139】

オラクルトランザクション

【0140】

各プレーヤが自分の秘密s_i'をオラクルに送信する。

【0141】

オラクルは、開始トランザクションが発生する前であっても取り決められる。それは、信用される第三者、目的をもって構築されたTEE(信用される実行環境、特定の機能のための既知のコードを実行するために目的をもって構築されたハードウェア、または何らかの他の形式のオラクル)であってもよい。

【0142】

2. オラクルが、各々の二次的な署名Sig P_i'=(r_i',s_i')および各々の主要な署名Sig P_i=(r_i,s_i)が、公開鍵P_iと関連付けられる同じ鍵のペアに対応することを確認する。

【0143】

3. オラクルがトランザクションを構築する。
このトランザクションは、その唯一の入力として開始トランザクションのUTXOを使用し、N×xビットコインの基金全体を単一の当籤した公開鍵にロックする。当籤鍵P_Wは、このオラクルトランザクションのロッキングスクリプト内で生成される乱数R_Nを使用して、ランダムに選択される。

【0144】

以下で示され、<P_W>によっても表記される、図3の出力スクリプトが、N個の参加する鍵P_iのセットから当籤公開鍵をランダムに選択するために使用される。それは以前のスクリプト<R_N>によってシードされ、<R_N>は当籤鍵を選ぶ乱数をその場で計算する。
<P_W>=<P₁> <P₂>…<P_N> <R_N> OP_ROLL OP_TOALTSTACK OP_DROP…OP_DROP OP_FROMALTSTACK
ここで、演算子"OP_DROP"のN-1回の使用と、N個の公開鍵がある。

【0145】

ロッキングスクリプトの最初の2行において、参加している公開鍵のセットが、スクリプトの<R_N>部分によって生成される値に従って操作される。そうすると、スクリプトは単に署名Sig P_Wを必要とする。オラクルトランザクションのロッキングスクリプトは単に、当籤公開鍵P_Wの所有者によって、署名されるべき当籤基金を阻害する。このロッキングスクリプトに公開鍵が現れる順序は、それらが開始トランザクションに現れる順序と一貫していなければならず、そうでなければ、オラクルが公開鍵を並べ替えることによって結果を操作できることに留意されたい。

【0146】

ハウスのいる富籤

【0147】

この適用例では、「ハウス」の役を務める関係者のいない、N人のプレーヤの富籤が構築されている。この概念をそのような富籤に拡張して、基金がビットコインエコシステムにおいて単純に失われず浪費されないようにすることが、望ましいことがある。たとえば、1人の関係者が富籤を構築することを望み、ユーザインターフェースをセットアップすること、オラクルをインスタンス化すること、または参加者を集めることなどの、関係するオーバーヘッドを引き受けることによって、ハウスとしての行動を提供する場合、その関係者はそうすることの動機を与えられることを望むことがある。この動機は、富籤の当籤基金をハウスに送るような、タイムアウト機構の形式であり得る。この富籤を実装することは、N人のプレーヤがxビットコインを寄付し、ハウスがrビットコインを寄付することを伴う。図4に記載される形式をとるようにオラクルトランザクションが修正された場合、ハウスは、何らかの合意されたタイムアウト期間ΔT_Eの後、当籤基金全体を回収して自分の公開鍵P_Hに支払うことが可能である。

【0148】

図4のオラクルトランザクションでは、ロッキングスクリプトは、タイムアウトフェールセーフを含むように修正されており、これは、当籤した関係者が合意された時間より前に自分の賞金を請求しない場合、ハウスの役を務める関係者が富籤の基金を費やすことを可能にする。青で強調されるロッキングスクリプトの部分は、これが行われることを可能にする。ハウスを含むこのタイプのブロックチェーン富籤では、各プレーヤは、1/(N+1)の確率でr+(N×x)ビットコインを獲得する可能性を有し、rはハウスの買付寄与である。ハウスを富籤に追加するというこの概念は、様々な国の国営富籤などの、必ずしも当籤者のいない富籤にも、ハウスに対応する公開鍵のセットを含めることによって拡張され得る。これらの鍵のうちの1つが選択される場合、富籤はロールオーバーする。

【0149】

当籤金の払い戻し

【0150】

オラクルトランザクションがブロックチェーン上に記録されると、当籤した公開鍵P_Wの所有者は、当籤基金を費やしてもよい。このタイプの有効なトランザクションが図5に示される。

【0151】

このトランザクションのアンロッキングスクリプトは、当籤した公開鍵に対応する署名Sig P_Wを備える。オラクルトランザクションによって阻害される基金をアンロックするとき、払い戻しトランザクション(scriptSig)へのこの入力は、以前のオラクルにより構築されたトランザクションのロッキングスクリプト(scriptPubKey)と一緒に実行される。これらの2つのスクリプトの組合せが図6に示されており、当籤したプレーヤが、当籤した公開鍵P_Wに対応する署名を単に提供することによって、N×xビットコインの当籤基金を費やすことができることを実証している。

【0152】

N面のサトシダイス

【0153】

本出願の方法の第2の適用例は、ディーラーと1人のプレーヤとを備えるゲームである。このゲームは、N面のサイコロを振った結果をプレーヤが正しく推測することと等価である。明らかに、このゲームは単に、上で概説されたような一般的なブロックチェーン富籤の適用例の関係者が2人の場合である。ここで、一方の関係者はディーラーとして行動し、他方はプレーヤとして行動する。

【0154】

このシナリオでは、以下の手順が、このゲームがどのようにプレーされるかを説明する。

【0155】

1. プレーヤが自分の推測c∈{0,N-1}を行う。この推測は
c=H(X_P) mod N
として計算される。

【0156】

2. 開始トランザクションが、プレーヤからのY_P=H(X_P)と、
その原像がN面のサトシダイスが振られることを表す試行Tの結果を決定するための入力パラメータになるY_D=H(X_D)とをコミットする。このトランザクションは、オラクルに支払われ、プレーヤにより賭けられる額xビットコインと、ディーラーにより賭けられる当籤払い戻し額Rビットコインとの両方を含む。

【0157】

3. 原像X_pおよびX_Dが、国際公開第2017/145016号において概説されるものなどの、秘密値分散技法を使用してオラクルに送信される。
オラクルは次いで、ゲーム基金を当籤した公開鍵P_Wにロックするトランザクションを構築する。

【0158】

これは、一般的な富籤の場合と同じ方法で行われるが、1つだけの公開鍵Pがプレーヤに属しており、N-1個の公開鍵D_i∀i∈{1,N-1}がディーラーに属している。サトシダイスを振った結果Tは、ロッキングスクリプトにおいて計算され、
T=H(X_P+X_D) mod N
によって計算される。

【0159】

4. c=Tである場合、プレーヤは、オラクルトランザクションの出力を費やすことによって、当籤基金x+Rビットコインを払い戻すことができる。それ以外の場合、当籤基金はディーラーによって払い戻し可能である。

【0160】

本出願においてより前に提示された議論により、乱数R_N:=Tの生成に成功しており、これは、基準(1)～(3)を満たし、運のゲームの結果を決定するために使用されている。上で説明されたハッシュ方法は、推測がプレーヤの好みへより簡単に適合されることを可能にするので、本出願により適していることがあることに留意されたい。

【0161】

平均的には、プレーヤは、最大でN個の任意の原像X_Pのハッシュを、プレーヤの望まれる推測値に到達する前に計算することがあり、これらは次いで、ゲームにコミットされ得る。この方法でセットアップされる運のゲームは、1/Nの確率でx+Rビットコインを獲得する確率をプレーヤに与え、関連する利得Rはxの関数であってもよい。

【0162】

他の生成器をシードすること

【0163】

乱数がどのようにスクリプト内で、かつビットコインブロックチェーンプロトコルを使用してセキュアに生成され得るかが、上で示された。提示される富籤の適用例では、これらの乱数を、別のところで、すなわち、何らかのオフチェーンの目的で使用するのではなく、トランザクションにおいて直ちに関数のために使用することが提案されている。

【0164】

本出願において説明される方法は、セキュアな合意ベースのトランスペアレントなプロトコルを通じて、乱数を生成する最も簡単な事例へと一般化される。
たとえば、単一の関係者または組織が、オフチェーンプロセスをシードするために乱数を生成することを望む場合、それらは、本文書で提示された方法のうちの1つまたは複数を使用してそれを行ってもよい。関係者は続いて、単に、富籤の適用例のために使用されるものと同様のトランザクションフローを構築し、しかし、プロセスのグローバルな入力および出力に大量の基金を関連付けない。このようにして、関係者は、機構、シード(すなわち、秘密値s_i'の線形結合)、および結果が、ブロックチェーン公開台帳にすべてトランスペアレントに記録されるような方法で、乱数R_NまたはシーケンスS_Rを生成するために、ブロックチェーンを使用してもよい。

【0165】

ここで図7を見ると、本開示の少なくとも1つの実施形態を実践するために使用されてもよい、コンピューティングデバイス2600の説明のための簡略化されたブロック図が与えられる。様々な実施形態において、コンピューティングデバイス2600は、上で例示され説明されたシステムのいずれかを実装するために使用されてもよい。たとえば、コンピューティングデバイス2600は、データサーバ、ウェブサーバ、ポータブルコンピューティングデバイス、パーソナルコンピュータ、または任意の電子コンピューティングデバイスとして使用するために構成されてもよい。図7に示されるように、コンピューティングデバイス2600は、メインメモリ2608および永続ストレージ2610を含むストレージサブシステム2606と通信するように構成され得る1つまたは複数のレベルのキャッシュメモリおよびメモリコントローラを伴う、1つまたは複数のプロセッサ(まとめて2602と表記される)を含んでもよい。示されるように、メインメモリ2608は、ダイナミックランダムアクセスメモリ(DRAM)2618と読取専用メモリ(ROM)2620とを含み得る。ストレージサブシステム2606およびキャッシュメモリ2602は、本開示において説明されるようなトランザクションおよびブロックと関連付けられる詳細などの、情報の記憶のために使用されてもよい。プロセッサ2602は、本開示において説明されるような任意の実施形態のステップまたは機能を提供するために利用されてもよい。

【0166】

プロセッサ2602はまた、1つまたは複数のユーザインターフェース入力デバイス2612、1つまたは複数のユーザインターフェース出力デバイス2614、およびネットワークインターフェースサブシステム2616とも通信することができる。

【0167】

バスサブシステム2604は、コンピューティングデバイス2600の様々な構成要素およびサブシステムが意図されるように互いに通信することを可能にするための機構を提供してもよい。バスサブシステム2604は、単一のバスとして概略的に示されるが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。

【0168】

ネットワークインターフェースサブシステム2616は、他のコンピューティングデバイスおよびネットワークへのインターフェースを提供してもよい。ネットワークインターフェースサブシステム2616は、コンピューティングデバイス2600からデータを受信し、それから他のシステムにデータを伝送するためのインターフェースとして働いてもよい。たとえば、ネットワークインターフェースサブシステム2616は、データ技術者がデバイスをネットワークに接続することを可能にすることがあるので、データ技術者がデータセンタなどの離れた位置にいる間にデータをデバイスに伝送してデバイスからデータを受信することが可能であることがある。

【0169】

ユーザインターフェース入力デバイス2612は、キーボード、統合されたマウス、トラックボール、タッチパッド、またはグラフィクスタブレットなどのポインティングデバイス、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンなどのオーディオ入力デバイス、および他のタイプの入力デバイスなどの、1つまたは複数のユーザ入力デバイスを含んでもよい。一般に、「入力デバイス」という用語の使用は、コンピューティングデバイス2600に情報を入力するためのすべての可能なタイプのデバイスおよび機構を含むことが意図されている。

【0170】

1つまたは複数のユーザインターフェース出力デバイス2614は、ディスプレイサブシステム、プリンタ、またはオーディオ出力デバイスなどの非視覚的ディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)などのフラットパネルデバイス、発光ダイオード(LED)ディスプレイ、またはプロジェクションデバイスもしくは他のディスプレイデバイスであってもよい。一般に、「出力デバイス」という用語の使用は、コンピューティングデバイス2600から情報を出力するためのすべての可能なタイプのデバイスおよび機構を含むことが意図されている。1つまたは複数のユーザインターフェース出力デバイス2614は、たとえば、説明されるプロセスおよびその変形を実行するアプリケーションとのユーザの対話を、そのような対話が適切である可能性があるときに促進するための、ユーザインターフェースを提示するために使用されてもよい。

【0171】

ストレージサブシステム2606は、本開示の少なくとも1つの実施形態の機能を提供してもよい基本的なプログラミングおよびデータ構造物を記憶するための、コンピュータ可読記憶媒体を提供してもよい。アプリケーション(プログラム、コードモジュール、命令)は、1つまたは複数のプロセッサによって実行されると、本開示の1つまたは複数の実施形態の機能を提供してもよく、ストレージサブシステム2606に記憶されてもよい。これらのアプリケーションモジュールまたは命令は、1つまたは複数のプロセッサ2602によって実行されてもよい。ストレージサブシステム2606は追加で、本開示に従って使用されるデータを記憶するためのリポジトリを提供してもよい。たとえば、メインメモリ2608およびキャッシュメモリ2602は、プログラムおよびデータのための揮発性ストレージを提供することができる。永続ストレージ2610は、プログラムおよびデータのための永続(不揮発性)ストレージを提供することができ、フラッシュメモリ、1つまたは複数のソリッドステートドライブ、1つまたは複数の磁気ハードディスクドライブ、関連するリムーバブルメディアを伴う1つまたは複数のフロッピーディスクドライブ、関連するリムーバブルメディアを伴う1つまたは複数の光学ドライブ(たとえば、CD-ROMまたはDVDまたはBlue-Ray)ドライブ、および他の同様のストレージメディアを含んでもよい。そのようなプログラムおよびデータは、本開示において説明されるような1つまたは複数の実施形態のステップを行うためのプログラム、ならびに、本開示において説明されるようなトランザクションおよびブロックと関連付けられるデータを含み得る。

【0172】

コンピューティングデバイス2600は、ポータブルコンピュータデバイス、タブレットコンピュータ、ワークステーション、または以下で説明される任意の他のデバイスを含む、様々なタイプであってもよい。加えて、コンピューティングデバイス2600は、1つまたは複数のポート(たとえば、USB、ヘッドフォンジャック、Lightningコネクタなど)を通じてコンピューティングデバイス2600に接続されてもよい別のデバイスを含んでもよい。コンピューティングデバイス2600に接続されてもよいデバイスは、光ファイバコネクタを受け入れるように構成される複数のポートを含んでもよい。したがって、このデバイスは、処理のためにデバイスをコンピューティングデバイス2600に接続するポートを通じて伝送されてもよい電気信号へと、光信号を変換するように構成されてもよい。コンピュータとネットワークの変化し続ける性質により、図7に図示されるコンピューティングデバイス2600の説明は、デバイスの好ましい実施形態を例示するための具体的な例として意図されているにすぎない。図7に図示されるシステムより多数または少数の構成要素を有する多くの他の構成が可能である。

【0173】

上で言及された実施形態は本開示を限定するのではなく例示すること、および、添付の特許請求の範囲により定義されるような本開示の範囲から逸脱することなく、当業者が多くの代替的な実施形態を設計することが可能であることに、留意されたい。請求項において、括弧の中に置かれたあらゆる参照符号は、請求項を限定するものとして解釈されるべきではない。「備える(comprising)」および「備える(comprises)」などの語は、任意の請求項または明細書に列挙されるもの以外の要素またはステップの存在を全体として排除するものではない。本明細書では、「備える(comprises)」は「含む(includes)またはからなる(consists of)」を意味し、「備える(comprising)」は「含む(including)またはからなる(consisting of)」を意味する。単数形での要素への言及は、そのような要素の複数形での言及を排除せず、その逆も当てはまる。本開示は、いくつかの別個の要素を備えるハードウェアによって、および適切にプログラムされたコンピュータによって実装されてもよい。いくつかの手段を列挙するデバイスの請求項において、これらの手段のいくつかは、ハードウェアの1つの同じアイテムによって具現化されてもよい。ある対策が相互に異なる従属請求項に記載されているという単なる事実は、これらの対策の組合せを使用して利益を得ることができないことを示すものではない。

【0174】

付録

【0175】

1. 署名のDER符号化

【0176】

【表1】

【0177】

2. 検証スクリプト

【0178】

i. 原像検証

【0179】

以下のスクリプトは、スクリプト内プロセスとして、供給された原像X_iの各々が正しいプリコミットされたハッシュ値Y_iに対応することを検証するために使用され得る。
<Verify 1>=<Y₁> <X₁> OP_SHA256 OP_EQUAL…<Y_N> <X_N> OP_SHA256 OP_EQUAL

【0180】

ii. 署名検証

【0181】

以下のスクリプトは、やはりスクリプト内プロセスとして、供給される二次的な署名Sig P_i'と初期の署名Sig P_iの各々が、ともに公開鍵P_iに対応することを検証するために使用され得る。
<Verify 2>=<P₁> OP_DUP <Sig P₁> OP_SWAP OP_CHECKSIG <s₁'> <r₁'> OP_CAT OP_SWAP OP_CHECKSIG…<P₁> OP_DUP <Sig P_N> OP_SWAP OP_CHECKSIG <s_N'> <r_N'> OP_CAT OP_SWAP OP_CHECKSIG

【符号の説明】

【0182】

2600 コンピューティングデバイス
2602 プロセッサ
2604 バスサブシステム
2606 ストレージサブシステム
2608 メインメモリ
2610 永続ストレージ
2612 ユーザインターフェース入力デバイス
2614 ユーザインターフェース出力デバイス
2616 ネットワークインターフェースサブシステム
2618 DRAM
2620 ROM

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】