JP2022523643A - ブロックチェーンスマートコントラクトにおいて乱数を生成する方法 - Google Patents

Abstract

従来の方法に関連するいくつかの問題を効果的に軽減するとともに検証可能かつ改ざん不可能な乱数生成を達成する、スマートコントラクトのための、公正かつ効果的な乱数を生成する方法が開示される。開示する方法の背後にある概念は、マイナーを信頼できないものとして扱い、かつブロックチェーン内のマイナーの数が限られていることを前提とするものである。十分な動機があれば、マイナーらはコンセンサスに達してブロックを操作することができる。したがって、ここでのゴールは、検証可能で公正な乱数生成器をもたらすことである。この条件下で、スマートコントラクトの当事者のうちの少なくとも一人が信用でき、秘密情報を誤用しない限り、信頼できるブロックチェーン乱数が生成され得る。乱数の最終開示後に、当事者によってコントラクトにサブミットされた検証シグネチャを使用して、乱数計算プロセスが信用できることを確かめることができる。

Description

本出願は一般に、ブロックチェーンシステムに関し、詳細には、ブロックチェーンスマートコントラクトにおいて乱数を生成する方法に関する。

我々の住む環境は、ランダムネスに溢れている。運、確率、および運命という概念は常に、ランダムネスに密接に結び付けられてきた。人間が理解または予測できない全てのものはしばしば、ランダムと分類される。生理学的にも、我々は多くのランダムネスの中に身を置いている。雲の動きから粒子や波の挙動に至るまで、ランダムネスは至るところにある。

しかし、人間は多様なランダムな事柄にさらされており、ランダムネスに親しみがあるものの、ランダムネスを、コンピュータが使用することのできる何かに変換することは、依然として困難である。本発明者らは、コンピュータシステムにおけるランダムネスについて語るとき、実際には疑似ランダムネス、すなわち、現実世界のランダムネスを可能な限り模倣してそれをほぼ「現実のランダムネス」にすること、を意味している。

乱数は、プライバシー技術および暗号化技術において重要な役割を果たしている。乱数の重要性は、セキュアな通信チャネルの確立に表れているのみならず、通信の確認にも表れている。複数の人々が帯域幅の限られたチャネルを通じて互いに通信しようと試みる場合、乱数を利用して、メッセージをチャネルが搬送するときの妥当な順序を決定することができる。

複数の当事者がグローバルな観点でのある特定の更新についてコンセンサスに達しようと試みるブロックチェーンは、一成功使用事例である。更新は通常、1ラウンド内、すなわち周期的な離散時間間隔内に完了する。

単一ノード上では、電子的熱運動(electronic thermal motion)やユーザによるマウスの任意の移動など、いくつかの物理的な特徴を使用して、乱数を生成することができる。しかし、ブロックチェーンスマートコントラクトサンドボックス内では、予想、計算、または特定することのできない一意の乱数を取得することは容易ではない。サンドボックスアプリケーションが、外部から隔離されており、サンドボックス内部またはブロックチェーン内のデータにのみアクセスすることができるが、物理的なマシン内のデータまたは外部の世界のデータを見ることはできないというのが、その主な理由である。チェーン上のトランザクションデータには、多くのユーザが同じ期間内にブロックチェーンにアクセスするとき、かつ人間の挙動を予測することが困難である限りは、ある一定のランダムネスがあるが、特に低負荷期間の間は、必ずしもそうであるとは限らない。また、ブロックチェーンのどのユーザもみな、ブロックチェーン内に格納されているデータを閲覧することができるので、スマートコントラクトにおいてプライベートとしてマークされたデータであってもなお、外部のアプリケーションによって閲覧可能である。

乱数を生成するための式が開示されると、誰でも同じデータおよび同じ式を使用して乱数を推測することができ、したがってそれはもはやランダムではあり得ない。乱数を使用する宝くじゲームは、乱数ソースが決して操作されることがないようにしなければならず、というのも、わずかな逸脱であっても、当選結果が完全に変わってしまうためである。当選者は、かなり大きな即時賞金(instant reward)を受け取ることができるので、宝くじの結果を改ざんすることの影響もまたかなり大きい。本発明者らはまた、任意のブロックチェーンの参加ノードが乱数の生成を制御することができないようにしなければならない。したがって、ブロックチェーンコントラクトにおける単一ソースの乱数シードの使用は信用できず、というのも、乱数シードを提供する当事者が結果を偽って乱数を生成したのではないことを誰も保証することができないためである。

スマートコントラクトにおける効果的かつ公正な乱数は、データ暗号化、オンラインゲーム、およびギャンブルなど、多くのブロックチェーンベースサービスの基礎となる。無支配(non-domination)を達成するために、ランダムネスプロトコルは以下の、
i)ランダム関数は常にいくつかの乱数を生成する、また
ii)ランダム関数によって生成された乱数は操作されない
という2つの態様を確実なものにする必要がある。

既知のブロックチェーン乱数生成方法としては、ブロックハッシュ、ビットコインビーコン、およびOraclizeがある。

ブロックハッシュでは、ブロックまたはトランザクションのハッシュがランダムソースとして使用される。ハッシュは決定論的なので、誰もが同じ結果を得ることになる。ブロックは、一旦ブロックチェーンに追加されるとそこに永遠に存続することができるので、どのユーザもみな、生成された数が正しいことを検証することができる。この方法を使用した宝くじサービスの例を考えられたい。プレーヤは最初に、ある特定の時間、例えば毎晩7:00PMより前に、自身の番号を配置することによってチケットを購入する。7:00PM過ぎに、チケット購入フェーズがクローズし、当選チケット番号を決定するためのものである次ステージに契約が移る。このチケットは、8:00PM過ぎにビットコインブロックチェーン上の誰しもにとってアクセス可能な最初のブロックのハッシュに基づいて計算される。7:00PMの時点では、8:00PM時点のこのブロックのハッシュを誰も予測できないことが我々には分かっており、そのことがこのサービスを妥当なものに見せている。

しかし、このハッシュは、ガーディアンブロックチェーン(guardian blockchain)のマイナーによって操作されるおそれがある。宝くじの賞金が少額であるとき、マイナーにはブロックを改ざんしようとする動機はそれほどないが、その金額が、ブロック報酬にトランザクション手数料を加えたものよりも大きい限り、マイナーがブロックハッシュに影響を及ぼして、自身が欲する数を生成し始めるおそれがある。したがって、この方法は、長間隔のランダムネス(high-interval randomness)に基づくアプリケーションにとってセキュアでない。この手法は、ゲームを終了するかどうかを決めるために乱数の即時生成を必要とするシナリオにとっても不適切である。

ビットコインビーコンでは、乱数を生成するためにビットコインブロックチェーンが使用される。ビットコインにおけるタイムスタンプおよびトランザクションは、持続可能な高エントロピーソースを含んでいる。エントロピーは、ランダムソースの「カオス」の尺度である。ソースが「カオス」であるほど、すなわちエントロピーが高いほど、生成される数を予測することは困難である。加えて、ランダム関数を決定するために、SHA256ハッシュ関数およびプルーフオブワーク(PoW)アルゴリズムが使用される。PoWは、計算集約的かつ非決定論的であり、それによって、乱数生成器(RNG)の結果が予測不可能になる。この手法は前述の手法と同じ問題を被り、というのも、この手法は、おそらくは経済的に動機付けられたマイナーが、自身が好まないブロックを故意に破棄する攻撃のリスクに、適切に対処しないためである。ブロックチェーンでは、マイナーは、プルーフオブワークアルゴリズムを実行することによって、ブロックチェーンを保護するのを助け、ビットコインの形態をとる報酬を確率的に受け取る。したがって、ランダムビーコンに対するどんな攻撃も、ビットコイン自体を攻撃することになる。したがって、この方法は、特定の範囲の金銭的コスト内でのみ保証され得る。賞金が多額である宝くじの場合、マイナーは、買収されて特定のブロックを無視するおそれがあり、それにより、ランダムネスが損なわれる。別の問題は、普通の人々(非マイナー)がこれらの乱数の生成に参加できないというものであり、それは、この方法が適切に公正な解決策ではないことを意味する。

Oraclizeは、スマートコントラクトおよびブロックチェーンアプリケーション用のデータを提供するデータプロバイダである。現実世界の多くの状況が、ブロックチェーンの外部からデータが取得されることを必要としているが、スマートコントラクトの性質は、この問題の解決の助けにはならない。Oraclizeが、このゴールの達成を助けることができる。Oraclizeは、中継物として、(Wolfram Alpha、IPFSなどの)外部ソースからデータを収集し、次いでそのデータを、必要なアプリケーションにパスする。乱数に関しては、Oraclizeは、random.orgからデータを抽出してブロックチェーンに入れる。この解決策の中心にあるのは、中央集権化されたデータサービスである。いわゆる信憑性証明を通じて、抽出された数が本物であり改ざんされていないことを、誰もが検証できると考えられている。明らかに、このモデルでは、人々はOraclizeを信頼するだけでなく、データプロバイダ、例えば前述のケースではrandom.orgも信頼している。しかし、信頼できる当事者に依拠することは、ブロックチェーン技術の背後にある中核原理のうちの1つと相反しており、というのも、中央集権化されたサービスはいつ使えなくなってもおかしくないためである。これにより、高いセキュリティを必要とし、ブロックチェーン上の当事者間に信頼関係のないアプリケーションにとって、Oraclizeは効率の悪いものとなっている。

したがって、前述の方法の問題を軽減するとともに検証可能かつ改ざん不可能な乱数生成を達成するための改善された方法が必要とされている。

一実施形態では、本発明は、前述の方法の問題を効果的に回避するとともに検証可能かつ改ざん不可能な乱数生成を達成することのできる、スマートコントラクトのための、公正かつ効果的な乱数を生成する方法を提供する。

本発明の一実施形態によれば、ブロックチェーン上での複数のユーザ間のスマートコントラクトのための、乱数を生成する方法が提供される。方法は、各ユーザに乱数シードをローカルに生成させることと、各ユーザに、対応する公開鍵を有する秘密鍵を用いて乱数シードに署名することによって、シグネチャを生成させることと、各ユーザに、シグネチャをスマートコントラクトに別々にサブミットさせることと、スマートコントラクトを使用して、各ユーザのシグネチャを各ユーザの対応する公開鍵を用いて検証することと、スマートコントラクトを介して、シグネチャをブロックチェーンのカレントブロックに格納することと、各ユーザに、少なくとも事前定義の期間待機させ、次いで、各ユーザによって生成された乱数シードをサブミットさせることと、スマートコントラクトを介して、各ユーザによってサブミットされた乱数シードをそれぞれ、対応するシグネチャとの整合を確認することによって検証することと、各ユーザからの全ての乱数シードが受領された後に、スマートコントラクトを介して、各ユーザのそれらのシードから取得されたシードおよびカレントブロックのハッシュを用いて乱数を計算することとを含む。カレントブロックのハッシュを得る際に、それらのシードが全てすでに生成されているので、それらのシードまたはブロックコンテンツをそれ以上操作することは不可能であり、それにより、マイナーがカレントブロックを変更するのを阻止する。

図において、本発明の実施形態をほんの一例として示す。

本発明の一実施形態の典型例である、RNGコントラクトによって乱数を生成するためのプロセスの簡易概略図である。 図1のRNGコントラクトによって生成された乱数をユーザが検証する様子を示す簡易概略図である。

上述したように、本発明は、前述の方法の問題を効果的に回避するとともに検証可能かつ改ざん不可能な乱数生成を達成することのできる、スマートコントラクトのための、公正かつ効果的な乱数を生成する方法を提案する。

本発明のさまざまな実施形態についての説明を以下に行う。本開示では、「1つの(a)」または「1つの(an)」という語の使用は、本明細書において「備える」という用語とともに使用されるとき、「1つの(one)」を意味することができるが、それは「1つまたは複数の」、「少なくとも1つの」、および「1つまたは1つよりも多くの」の意味とも矛盾しない。単数形で表現される任意の要素は、その複数形も包含する。複数形で表現される任意の要素は、その単数形も包含する。「複数」という用語は、本明細書では、1つよりも多くを意味し、例えば2つ以上、3つ以上、4つ以上などを意味する。「上部」、「底部」、「上方の」、「下方の」、「縦に」、および「横に」など、方向を示す用語は、相対的参照を行うことを目的として使用されているにすぎず、任意の物品を、使用の際にどのように配置すべきか、またはアセンブリ内にもしくは環境に対してどのように取り付けるべきかに対する、いかなる限定も示唆するものではない。

「備える」、「有する」、「含む」、および「収容する」という用語、ならびにそれらの文法的変形は、包含的またはオープンエンドであり、記載されていない追加の要素および/または方法ステップを除外しない。「本質的に～からなる」という用語は、本明細書において、構成、使用、または方法に関連して使用されるとき、追加の要素、方法ステップ、または追加の要素と方法ステップの両方が存在し得るが、これらが追加されても、記載された構成、方法、または使用が機能する様式には実質的に影響が及ばない、ということを意味する。「～からなる」という用語は、本明細書において、構成、使用、または方法に関連して使用されるとき、追加の要素および/または方法ステップの存在を除外する。

「ブロックチェーン」とは、コンピューティングデバイスのパブリックまたはプライベートのピアツーピアネットワーク内でトランザクションを記録する、改ざん明示性を備えた(tamper-evident)共有のデジタル台帳である。台帳は、暗号学的ハッシュによりリンクされたブロック(cryptographic hash-linked block)からなる成長し続ける連続したチェーンとして維持される。

「ノード」とは、ブロックチェーンネットワーク上のデバイスである。デバイスは、典型的には、プロセッサ可読命令をその上に有したメモリを含むプロセッサ可読媒体に相互接続されたプロセッサを有する、コンピュータである。

加えて、「第1の」、「第2の」、「第3の」などという用語は、説明を目的として使用されているにすぎず、相対的重要性を示すまたは意味するものと解釈することはできない。

本発明の説明においては、「取り付けられた」、「リンクされた」、および「接続された」という用語は、別段の明示的な定めおよび制限のない限り、広義に解釈すべきであることにも留意されたい。例えば、それは固定の接続であってもよく、組立て式の接続であってもよく、一体に接続されてもよく、それはハードワイヤードであってもよく、ソフトワイヤードであってもよく、それは直接的に接続されてもよく、中継物を通じて間接的に接続されてもよい。技術専門家にとって、上記の用語の本発明における具体的意味は、文脈の中で理解することができる。

本発明の実施形態を示す図面においては、同じまたは類似の参照ラベルが、同じまたは類似の部分に対応する。本発明の説明においては、「複数の」の意味は、別段の指定のない限り、2つ以上を意味することに留意されたい。「上」、「下」、「左」、「右」、「内部」、「外部」、「前端」、「後端」、「頭部」、「尾部」という用語の方向または位置、すなわち図面に示す配向または位置関係は、示されたデバイスまたは要素が特定の配向を有し、特定の配向で構築され、動作しなければならないということを示すまたは意味するのではなく、本発明の説明の便宜を図り、説明を簡易にするためのものにすぎず、したがって、本発明を限定するものとして使用することはできない。

例示的方法の背後にある概念は、「マイナーは信頼できない」、かつブロックチェーン内のマイナーの数は限られている、という本質を取り入れたものである。十分な動機があれば、マイナーらはコンセンサスに達してブロックを操作することができる。したがって、ここでのゴールは、検証可能で公正なRNG(乱数生成器)をもたらすことである。この条件下で、スマートコントラクトの当事者のうちの少なくとも一人が信用でき、その人物が秘密情報を誤用しない限り、信頼できるブロックチェーン乱数が生成され得る。乱数の最終開示後に、本発明者らは、当事者によってサブミットされた検証シグネチャを使用して、乱数計算プロセスが信用できることを確かめることもできる。

本発明の一態様によれば、ランダム生成コントラクトにN人の参加ユーザがいると仮定すると、プロセス全体を以下のステップを使用して定義することができる。

各ユーザが、乱数シードをローカルに生成し、自身のローカル秘密鍵を用いてこの乱数シードに署名する。

各ユーザが、シグネチャをRNGスマートコントラクトに別々にサブミットする。

コントラクトが、サブミットされたシグネチャをユーザの公開鍵を用いて検証し、それが正しいユーザによって生成されたことを確認する。次いで、コントラクトはシグネチャをブロックに格納する。

各ユーザが、少なくとも1ブロック期間待機し、乱数シードをサブミットする。これは、確実に乱数シードがそのシグネチャと同じブロック内に出現しないようにするためである。

コントラクトが、サブミットされた乱数シードを検証し、それがシグネチャと整合していることを確認する。

全ての乱数シードが受領された後に、コントラクトが、シード(ユーザA、ユーザB....ユーザN)およびカレントブロックのブロックハッシュを用いて乱数を計算する。カレントブロックのハッシュコードを得る際に、全ての乱数シードがすでに生成されているので、乱数シードまたはブロックコンテンツをそれ以上操作することは不可能である。これにより、マイナーがブロックチェーン内のブロックを変更するのを阻止することが可能である。

一実施形態における例示的なステップのセットについて、下で図1を参照して説明する。

ステップ101において:バンカー(BANKER)がスマートコントラクトに、乱数生成の新たなラウンドを開始するように通知する。

ステップ102において:ユーザAがコントラクトからカレントブロックIDを入手する。

ステップ103において:ユーザAが、ローカルソフトウェアまたはハードウェアデバイスによって、ローカル乱数シードを生成する。

ステップ104において:ユーザAが、ユーザAの秘密鍵を用いて乱数シードおよびブロックIDに署名する。乱数シードおよびカレントブロックの識別子(ブロックID)のうちの1つまたは複数を入力として使用するPretty Good Privacy(PGP)などの暗号化プログラムが使用されてよく、その結果、例えば、シグネチャ = PGP (乱数シード、ブロックID)となる。

ステップ105において:ユーザAが、RNGスマートコントラクトを呼び出し、シグネチャをスマートコントラクトにサブミットする。

ステップ106において:スマートコントラクトが、シグネチャをユーザAの公開鍵を用いて検証し、シグネチャをチェーンのブロックに格納する。

ステップ107において:ユーザAが1ブロック期間よりも長い時間期間待機する。これは、確実にシグネチャの格納が乱数シードより少なくとも1ブロック前に行われるようにするためである。

ステップ108において:ユーザAが、シグネチャを生成するのにそれが使用した乱数シードおよびブロックIDを、RNGスマートコントラクトにサブミットする。

ステップ109において:スマートコントラクトがこの乱数シードを検証し、先行してサブミットされたシグネチャとその乱数シードが整合していることを確認する。

ステップ110において:スマートコントラクトが、次式:RAND(0) = HASH(RandomSeed (ユーザA))を使用して一時的な乱数を計算する。

ステップ111において:ユーザNが、ローカルソフトウェアまたはハードウェアデバイスによって、ローカル乱数シードを生成する。

ステップ112において:ユーザNが、ユーザNの秘密鍵を用いて乱数シードおよびブロックIDに署名する:シグネチャ = PGP (乱数シード、ブロックID)。

ステップ113において:ユーザNが、RNGスマートコントラクトを呼び出し、シグネチャをスマートコントラクトにサブミットする。

ステップ114において:スマートコントラクトが、シグネチャをユーザNの公開鍵を用いて検証し、シグネチャをチェーンのブロックに格納する。

ステップ115において:ユーザNが1ブロック期間よりも長い時間期間待機する。これは、確実にシグネチャの格納が乱数シードより少なくとも1ブロック前に行われるようにするためである。

ステップ116において:ユーザNが、シグネチャを生成するのにそれが使用した乱数シードおよびブロックIDを、RNGスマートコントラクトにサブミットする。

ステップ117において:スマートコントラクトがこの乱数シードを検証し、先行してサブミットされたシグネチャとその乱数シードが整合していることを確認する。パッケージ複製攻撃(package replication attack)を阻止するために、本発明者らはブロックIDも検証し、それがカレントブロックから5ブロック以内にあることを確認する必要がある。

ステップ118において:スマートコントラクトが、次式:RAND(N) = HASH(RAND(N-1) XOR RandomSeed (ユーザA))、ただしRAND(N-1)は先行するステップにおいて生成された一時的な乱数である、を使用して一時的な乱数を計算する。乱数シードをサブミットする必要のある、より多くのユーザがいる場合、ステップ111へのループを継続する。他の実施形態では、その代わりにRandomseed (ユーザN)が使用されてよい。

ステップ119において:全ての参加者が自身の乱数シードをサブミットした場合、コントラクトは、カレントブロックのハッシュ値を得て、次式:RAND(N+1) = HASH( RAND(N) XOR BLOCKHASH)を用いて乱数を再計算し、RAND(N+1)を最終結果として開示する。

1.乱数プロセスのセキュリティ検証:
1.1. シナリオ1:ブロックチェーン乱数生成プロセスのユーザによる検証
ブロックチェーン上の任意のユーザが、RNGコントラクトにおいて各ユーザによって提供された乱数シードおよびシグネチャを、ブロックチェーン上のデータを通じて取得することができる。ユーザは、最終ブロックのハッシュ値を取得することができる。上式を使用することによって、RAND(N+1)を計算することができ、スマートコントラクトによって計算された乱数を比較および検証することができる。

図2は、RNGコントラクトによって生成された乱数をユーザAが検証する様子を示す。

1.2. シナリオ2:マイナーらがブロックチェーンレコードを共同で改ざんするのを阻止する
ユーザによる提供物を収容している乱数シードブロックをマイナーが破棄しようと試みていることが発見される。ユーザが乱数シードシグネチャを先行するブロック内にサブミットしたので、ユーザによってさらにサブミットされた乱数シードは、検証をパスするには、その前にサブミットされたシグネチャと矛盾がないようでなければならない。加えて、各ステップの乱数は、実時間で計算および保存される。最終検証結果が各ステップにおける乱数シードの計算結果とは矛盾がある場合、それは、少なくとも1つまたは複数のユーザレコードが破棄または改ざんされた可能性があることを意味し、その不正行為は早晩発見されることになる。

1.3. シナリオ3:ユーザBがユーザAの要求をリプレイすることによって偽の乱数シードをサブミットするのを阻止する
ユーザは、ユーザ自身の乱数シードをサブミットするとき、最初に署名済み結果をサブミットし、次いで、シグネチャが計算された後に乱数シードおよびブロックIDをサブミットする必要がある。本発明者らのブロックチェーン性能の想定では、スマートコントラクトは、全ての計算を、ユーザによる情報のサブミッションから6ブロックサイクル以内に実施することができる。したがって、スマートコントラクトによって取得されたカレントブロックIDとユーザによりサブミットされた乱数シードの生成ブロックIDとの間の差は、6ブロック未満である必要がある。この値を上回る場合、それは、ユーザが要求をずっと以前にサブミットしたことを意味し、要求はリプレイ攻撃の可能性があり、したがってそれは無効な要求である。

1.4. シナリオ4:ユーザが自身の意図を満たす乱数を偶然見いだすのを阻止する
乱数シードを提供した最終ユーザは、理論的には、他の全てのユーザのシードおよびシグネチャを取得し、自身の意図を満たす乱数を偶然見いだそうと試みることが可能である。最終ユーザがユーザ自身の乱数を提供した後で、スマートコントラクトはカレントブロックのハッシュ値も取り込んで、乱数演算に参加する。このユーザは、乱数を計算しているときにブロックから退出しない(ユーザは最初にシグネチャをサブミットし、次いで乱数シードをサブミットしなければならない)ので、カレントブロックのハッシュ値を予測することができず、したがって、所望の乱数シードを偶然見いだすことはできない。

例1:
本プログラムを、提案するブロックチェーン賭けゲームに従って妥当性確認した。これは、誰もが一連のゲーム内で入札することができ、各ラウンドが先行するラウンドよりも大きくなければならないという制限のある、オークション入札ゲームである。ゲームは、ランダムなNラウンドまたはN時間後に終了する。

このゲームは、ゲームが終了できるかどうかを判定するための実時間乱数を生成すべく、各ユーザの入札を必要とする。既存のブロックチェーン乱数ルールによれば、宝くじの乱数は、全てのユーザの賭けが完了した後に生成されるか、またはカレントブロックによるブロック情報を使用して計算されなければならない。この観点から、前もって生成された乱数は、ランダムネスなく漏れるおそれがある。したがって、このゲームでは、ゲームの要件を満たす乱数を生成することは困難である。

本方法では、ゲームルールの要件を満たす乱数を効果的に生成することができる。ゲームが開始するとき、開始者が乱数シードを提供する。

各ラウンドのプレーヤが、次のルールに従って入札する:最初にローカル乱数シードを取得し、次いで、ユーザの秘密鍵を用いて、シグネチャをカレントラウンドの入札とともに配置する。クライアントは、コントラクトを2回呼び出す必要があり、1回は、カレントラウンドの入札およびシグネチャを報告するためである。次いで、1ブロックの遅延後に、乱数シードを報告するためにコントラクトが再度呼び出される。

報告された乱数シードをコントラクトにおいて取得した後に、シードがそのユーザによって生成されたこと、また付け値と対になっていることを確認するために、コントラクト検証が実施される。

スマートコントラクトは、式RAND(N) = HASH(RAND(N-1) XOR BLOCKHASH)を使用して、カレントラウンドの乱数を計算し、乱数がゲーム終了条件を満たすかどうかを判断する。カレントゲーム終了条件が満たされた場合、ゲームは終了し、勝者が選択される。

ゲーム終了条件が満たされていない場合、ゲームは、次ラウンドの付け値を求めてステップ2に進む。

例2:
本乱数生成器は、51%攻撃の阻止を助けることができるので、セキュアな銀行トランザクションで使用するのに理想的である。このタイプの攻撃では、不正なマイナーが、利益を得る、例えば同じ暗号通貨を2回消費できる力を得るため、またはブロックチェーンのインテグリティに疑念を抱かせるため、トランザクションを取り消そうと試みる。本RNGでは、乱数シードが受領された後に、コントラクトが、シード(ユーザA、ユーザB...ユーザN)およびカレントブロックのブロックハッシュを用いて乱数を計算する。乱数シードがすでに生成されているので、ブロックコンテンツをそれ以上操作することは不可能であり、各参加者に乱数シードを再送するように頼むこともまた不可能である。シードは、トランザクションが完了した後に明らかにされ、それにより、トランザクションが正しいことが検証される。コンテンツを修正しようとする試みの結果、トランザクションが失敗することになる。

51%攻撃に対する標準的な防御は、Nブロック待機してからトランザクションのオブジェクトを公開するというものである。本RNGは、少なくとも1ブロック以上6ブロック以下の待機期間を必要とし、それにより、トランザクションのインテグリティを確実なものにしている。必要な乱数シードに矛盾がないことを実証しないブロックは、検証をパスせず、それによって、トランザクションが失敗する。要求される時間フレーム内に行われないトランザクションも失敗する。最終検証結果が各ステップにおける乱数シードの計算結果とは矛盾があるときに、ブロックの改ざんを想定することができる。ブロックチェーンの民主主義では、最長のブロックチェーンが正しいブロックチェーンであると規定されているので、悪意のある行為者は、正当なブロックチェーンの先を行くには、無類のハッシュパワーを必要とすることになる。

以上、ほんの一例として、本発明の実施形態について説明してきたが、特許請求の範囲に記載の範囲から逸脱することなく多くの変形および置換が可能なので、添付の特許請求の範囲によって定められる本発明は、例示的実施形態についての上記の説明中に記載された特定の詳細によって限定すべきではないことを理解されたい。

101～120 ステップ

Claims (18)

1. ブロックチェーン上での複数のユーザ間のスマートコントラクトのための、乱数を生成する方法であって、
   a)前記複数のユーザのうちの各ユーザに、乱数シードをローカルに生成させるステップと、
   b)前記各ユーザに、対応する公開鍵を有する秘密鍵を用いて前記乱数シードに署名することによって、シグネチャを生成させるステップと、
   c)前記各ユーザに、前記シグネチャを前記スマートコントラクトに別々にサブミットさせるステップと、
   d)前記スマートコントラクトを使用して、前記各ユーザの前記シグネチャを前記各ユーザの対応する公開鍵を用いて検証するステップと、
   e)前記スマートコントラクトを介して、前記シグネチャを前記ブロックチェーンのカレントブロックに格納するステップと、
   f)前記各ユーザに、少なくとも事前定義の期間待機させ、次いで、前記各ユーザによって生成された前記乱数シードをサブミットさせるステップと、
   g)前記スマートコントラクトを介して、前記各ユーザによってサブミットされた前記乱数シードをそれぞれ、前記対応するシグネチャとの整合を確認することによって検証するステップと、
   h)前記各ユーザからの全ての乱数シードが受領された後に、前記スマートコントラクトを介して、前記各ユーザのそれらのシードから取得されたシードおよびカレントブロックのハッシュを用いて乱数を計算するステップと
   を含み、
   前記カレントブロックの前記ハッシュを得る際に、前記それらのシードが全てすでに生成されているので、前記それらのシードまたはブロックコンテンツをそれ以上操作することは不可能であり、それにより、マイナーが前記カレントブロックを変更するのを阻止する、
   方法。
2. 前記事前定義の期間が少なくとも1ブロック期間である、請求項1に記載の方法。
3. 前記複数のユーザのうちの各ユーザに、乱数シードをローカルに生成させる前記ステップが、前記各ユーザのローカルソフトウェアおよびハードウェアデバイスのうちの1つまたは複数によって実施される、請求項1に記載の方法。
4. 前記複数のユーザのうちの各ユーザに、乱数シードをローカルに生成させる前記ステップの前に、各ユーザに、前記コントラクトからブロックの第1の識別子(第1のブロックID)を入手させるステップをさらに含む、請求項1に記載の方法。
5. 前記各ユーザにシグネチャを生成させる前記ステップが、前記秘密鍵を用いて前記乱数シードおよび前記第1のブロックIDに署名するステップを含む、請求項4に記載の方法。
6. 前記スマートコントラクトを介して、前記各ユーザによってサブミットされた前記乱数シードをそれぞれ、前記対応するシグネチャとの整合を確認することによって検証する前記ステップが、前記第1のブロックIDがカレントブロック識別子から所定のブロック数以内にあることを確認することを含む、請求項5に記載の方法。
7. 前記所定のブロック数が5である、請求項6に記載の方法。
8. 前記スマートコントラクトを介して、前記各ユーザの前記それらのシードから取得されたシードおよびカレントブロックのハッシュを用いて乱数を計算する前記ステップが、前記乱数を、
   RAND(N+1) = HASH( RAND(N) XOR BLOCKHASH)
   に設定することを含み、
   ただし、RAND(N) = HASH(RAND(N-1) XOR RandomSeed (ユーザA))であり、
   BLOCKHASHは、前記カレントブロックの前記ハッシュであり、
   ユーザAは、前記複数のユーザのうちの第1のユーザであり、
   RandomSeed (ユーザA)は、前記複数のユーザのうちの前記第1のユーザによって生成された乱数シードである、
   請求項7に記載の方法。
9. RAND(0) = HASH(RandomSeed (ユーザA))である、請求項8に記載の方法。
10. 前記各ユーザに、少なくとも事前定義の期間待機させ、次いで、前記各ユーザの乱数シードをサブミットさせる前記ステップが、確実に前記各ユーザの前記乱数シードが前記各ユーザのシグネチャと同じカレントブロック内に出現しないようにする、請求項1に記載の方法。
11. ローカル秘密鍵を用いて前記乱数シードに署名する前記ステップが、前記乱数シードおよび前記カレントブロックの識別子のうちの1つまたは複数を入力として使用する暗号化プログラムを利用することを含む、請求項1に記載の方法。
12. 前記複数のユーザのうちのいずれか1人が、前記複数のユーザのそれぞれによって提供された前記乱数シードおよび前記シグネチャを、前記ブロックチェーン上のデータを通じて取得することができる、請求項1に記載の方法。
13. 前記暗号化プログラムがPretty Good Privacy(PGP)である、請求項11に記載の方法。
14. 前記事前定義の期間が、少なくとも1ブロック期間以上6ブロック期間以下である、請求項2に記載の方法。
15. 前記複数のユーザが、第1のユーザ、第2のユーザ、およびバンカーを含む、請求項1に記載の方法。
16. ブロックチェーン上での複数のユーザ間のスマートコントラクトによって生成された第1の乱数を検証する方法であって、
    a)前記スマートコントラクトによって生成された第1の乱数を取得するステップと、
    b)前記ブロックチェーンの最終ブロックハッシュを受領するステップと、
    c)第2の乱数を計算するステップと、
    d)前記第1の乱数を前記第2の乱数と比較するステップと
    を含む、方法。
17. 前記複数のユーザが、第1のユーザ、第2のユーザ、およびバンカーを含む、請求項16に記載の方法。
18. 前記複数のユーザのうちのいずれか1人が、前記複数のユーザのそれぞれによって提供された乱数シードおよびシグネチャを、前記ブロックチェーン上のデータを通じて取得することができる、請求項16に記載の方法。

Images