IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン ホールディングス リミテッドの特許一覧

特許7600260ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置
<>
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図1
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図2
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図3
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図4
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図5
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図6
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図7
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図8
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図9
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図10
  • 特許-ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置 図11
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-06
(45)【発行日】2024-12-16
(54)【発明の名称】ブロックチェーンネットワークにおいてブロックを伝播する方法及び装置
(51)【国際特許分類】
   H04L 9/32 20060101AFI20241209BHJP
   G06F 21/64 20130101ALI20241209BHJP
   G06Q 20/38 20120101ALI20241209BHJP
【FI】
H04L9/32 200Z
G06F21/64
G06Q20/38 310
【請求項の数】 15
(21)【出願番号】P 2022560012
(86)(22)【出願日】2021-04-06
(65)【公表番号】
(43)【公表日】2023-05-23
(86)【国際出願番号】 EP2021058933
(87)【国際公開番号】W WO2021198532
(87)【国際公開日】2021-10-07
【審査請求日】2024-03-08
(31)【優先権主張番号】2004978.9
(32)【優先日】2020-04-03
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】コフラン,スティーヴン,パトリック
【審査官】中里 裕正
(56)【参考文献】
【文献】特開2019-008791(JP,A)
【文献】特表2019-532419(JP,A)
【文献】米国特許出願公開第2019/0303935(US,A1)
【文献】中国特許出願公開第110808839(CN,A)
【文献】KARAME, G. O. and ANDROULAKI, E.,Double-Spending Fast Payments in Bitcoin,The Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS'12),2012年10月,pp.906-917
【文献】PODOLANKO, J. P., MING, J. and WRIGHT, M.,Countering Double-Spend Attacks on Bitcoin Fast-Pay Transactions,Workshop on Technology and Consumer Protection (ConPro ’17),2017年05月25日,pp.1-7,<https://www.ieee-security.org/TC/SPW2017/ConPro/index.html>,[2024年10月29日検索]
【文献】NICOLAS, K. and WANG, Y.,A novel double spending attack countermeasure in blockchain,2019 IEEE 10th Annual Ubiquitous Computing, Electronics & Mobile Communication Conference (UEMCON),2019年10月,pp.383-388
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
G06F 21/64
G06Q 20/38
JSTPlus/JMEDPlus/JST7580(JDreamIII)
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
ブロックチェーンネットワークにおいて二重支払い試行通知を中継する、コンピュータにより実施される方法であって、前記方法は、
前記ブロックチェーンネットワークのノードから、二重支払い通知を受信するステップであって、前記二重支払い通知は、2つのトランザクション識別子を含み、マイナー識別子により署名されている、ステップと、
前記2つのトランザクション識別子に対応する2つのトランザクションのトランザクションデータを取得するステップと、
前記2つのトランザクションが少なくとも1つの一致するインプットを有するかどうかを決定するステップであって、
前記2つのトランザクションが少なくとも1つの一致するインプットを有する場合、前記二重支払い通知を有効であると識別し、その結果、前記ブロックチェーンネットワーク上で少なくとも1つの他のノードへ前記二重支払い通知を送信し、
前記2つのトランザクションが少なくとも1つの一致するインプットを有しない場合、前記二重支払い通知を無効であると識別し、その結果、前記ブロックチェーンネットワーク上で前記二重支払い通知を伝播させない、ステップと、
を含む方法。
【請求項2】
前記2つのトランザクションが少なくとも1つの一致するインプットを有するかどうかを決定するステップの前に、前記マイナー識別子を妥当性確認するステップ、を更に含む請求項1に記載の方法。
【請求項3】
前記二重支払い通知は前記マイナー識別子を含み、前記マイナー識別子はマイナー公開鍵を含み、
前記マイナー識別子を妥当性確認するステップは、
前記マイナー公開鍵の公開を含むコインベーストランザクションまで前記マイナー識別子をトレースするステップと、
前記マイナー公開鍵を用いて前記二重支払い通知に対する署名を検証するステップと、
を含む、請求項2に記載の方法。
【請求項4】
前記2つのトランザクションのトランザクションデータを取得するステップの前に、前記二重支払い通知が妥当性確認されるべきであると決定するステップ、を更に含む請求項1に記載の方法。
【請求項5】
前記二重支払い通知が妥当性確認されるべきであると決定するステップは、
ランダム値を生成するステップと、
前記ランダム値が妥当性確認閾値より低いと決定するステップと、
を含む、請求項4に記載の方法。
【請求項6】
前記ブロックチェーンネットワーク上で前記二重支払い通知を送信するステップは、
送信する前に、前記二重支払い通知に署名を追加するステップを更に含む、請求項1に記載の方法。
【請求項7】
署名を追加するステップは、
最大数より少ない署名が前記二重支払い通知に追加されていると決定するステップを含む、請求項6に記載の方法。
【請求項8】
前記2つのトランザクションが少なくとも1つの一致するインプットを有しない場合、否認通知を生成し送信するステップ、を更に含む請求項1に記載の方法。
【請求項9】
前記否認通知は、少なくとも前記二重支払い通知の識別子を含み、生成することは、現在ノード署名を追加することを含む、請求項8に記載の方法。
【請求項10】
前記現在ノード署名は、現在ノードマイナー識別子に基づき生成される、請求項9に記載の方法。
【請求項11】
別のノードから否認通知を受信するステップであって、前記否認通知は、前記二重支払い通知の識別子を含み、第2マイナー識別子により署名される、ステップ、
を更に含む請求項1に記載の方法。
【請求項12】
前記マイナー識別子及び前記第2マイナー識別子に関連付けられた評判スコアを取得し、取得することと、相対的な評判スコアに基づき前記2つのトランザクションが少なくとも1つの一致するインプットを有するかどうかを決定することとを実行することにより、前記二重支払い通知が妥当性確認されるべきであると決定するステップ、
を更に含む請求項11に記載の方法。
【請求項13】
前記トランザクションデータを取得するステップは、メモプールからトランザクションのうちの1つのトランザクションデータを読み出し、別のノードから他のトランザクションのコピーを要求するステップを含む、請求項1に記載の方法。
【請求項14】
ブロックチェーンネットワークにおいて二重支払い試行通知を中継するコンピューティング装置であって、前記コンピューティング装置は、
1つ以上のプロセッサと、
メモリと、
前記メモリに格納されたコンピュータ実行可能命令であって、前記1つ以上のプロセッサにより実行されると、前記プロセッサに請求項1~13のいずれか一項に記載の方法を実行させる、コンピュータ実行可能命令と、
を含むコンピューティング装置。
【請求項15】
ブロックチェーンネットワークにおける二重支払い試行通知を中継するためのプロセッサ実行可能命令を格納しているコンピュータ可読媒体であって、前記プロセッサ実行可能命令は、1つ以上のプロセッサにより実行されると、前記プロセッサに請求項1~13のいずれか一項に記載の方法を実行させる、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ブロックチェーンネットワークに関し、特に、ブロックチェーンネットワークにおいて試行される二重支払いの検出に関する。
【背景技術】
【0002】
暗号通貨のような真のデジタルアセットの生成及び使用に対する主な障害の1つは、「二重支払い」の問題である。つまり、アセット(コイン、等)がデジタルであるとき、それは容易にコピーされ、1つより多くの受信者へ移転されたと主張される。従って、殆どのそのようなシステムは、歴史的に移転を規制し、二重支払いを防ぐために、第三者の信頼できる仲介を必要としてきた。BitcoinSV(商標)プロトコルにより実証されたようなビットコインネットワークのようなブロックチェーンモデルの上に構築された暗号通貨は、非集中化合意、及びトランザクションの有効性の条件のうちの1つとして二重支払いを防ぐプロトコルを通じて、二重支払いの問題を解決する。具体的に、トランザクションを受信する各ノードは、多数の有効性基準の遵守についてトランザクションを評価する。これは、トランザクションのインプットが、存在する、未使用である(未使用トランザクションアウトプット(unspent transaction output (UTXO))の中にある)、及びノードにより既に観察された未確定トランザクションへのインプットとして使用されていない、確認を待っているメモプール内に置かれている、という事実を含む。使用された又は未確定トランザクションへのインプットの中で使用されたインプットを使用する第2トランザクションが受信された場合、ノードは第2トランザクションを無効であるとして破棄し、それをブロックチェーンネットワーク上で伝播させない。
【0003】
これは二重支払いを防ぐが、二重支払い試行が生じたという事実も隠してしまう。第1トランザクションに関連する元のマーチャント及び/又はユーザは、第2トランザクションがそれを知った第1ノードセットにより消され破棄されてしまった場合、企てられた二重支払いの発生を認識できない。これは、悪意ある活動又は主体の検出、及び予防若しくは懲罰的措置の実装を妨げてしまう。
【0004】
1つの選択肢は、二重支払いトランザクションを検出するノードに、トランザクションが無効であると決定されたという事実にも拘わらず、トランザクションを転送させるよう、プロトコルを変更することである。その結果、ネットワーク内の他のノードは、無効なトランザクションも知ることができ、元のマーチャントノードは企てられた二重支払いを認識できるようになる。このような変更の問題点は、ネットワークを無効な二重支払いトランザクションで溢れさせ、そのようなトランザクションの作成者に殆ど又は全くコストをかけずに、各ノードが評価し無効と検出する処理を実行する必要があるサービス拒否攻撃のような、潜在的な攻撃にブロックチェーンネットワークを公開することである。
【図面の簡単な説明】
【0005】
例として、本願の例示的な実施形態を示す以下の添付の図面を参照する。
【0006】
図1】ブロックチェーンにマイナーアイデンティティを登録する1つの簡単な例示的な方法を、フローチャートの形式で示す。
【0007】
図2】マイナーアイデンティティを登録するために高速取消オプションを設定する例示的な方法を、フローチャートの形式で示す。
【0008】
図3】ブロックチェーンにマイナーアイデンティティを記録する1つの例示的な方法を、フローチャートの形式で示す。
【0009】
図4】マイナーアイデンティティを検証する例示的な方法を、フローチャートの形式で示す。
【0010】
図5】ブロックチェーンに作業履歴を記録する1つの例示的な方法を示す。
【0011】
図6】ブロックチェーンを用いて作業履歴を検証する例示的な方法を示す。
【0012】
図7】記録された作業履歴に基づきマイニングノードの評判スコアを決定する例示的な方法を示す。
【0013】
図8】マイニングノードのようなコンピューティングノードの簡易な例をブロック図形式で示す。
【0014】
図9】二重支払い通知を生成する方法の一例を、フローチャートの形式で示す。
【0015】
図10】二重支払い通知を中継する方法の一例を、フローチャートの形式で示す。
【0016】
図11】二重支払い通知と否認通知との間の衝突を解決する方法の一例を、フローチャートの形式で示す。
【0017】
図中の同様の参照符号は同様の要素及び特徴を示すために使用される。
【発明を実施するための形態】
【0018】
一態様では、ブロックチェーンネットワークにおける二重支払い試行通知を中継する、コンピュータにより実施される方法が提供され得る。前記方法は、
前記ブロックチェーンネットワークのノードから、二重支払い通知を受信するステップであって、前記二重支払い通知は、2つのトランザクション識別子を含み、マイナー識別子により署名されている、ステップと、
前記2つのトランザクション識別子に対応する2つのトランザクションのトランザクションデータを取得するステップと、
前記2つのトランザクションが少なくとも1つの一致するインプットを有するかどうかを決定するステップであって、
前記2つのトランザクションが少なくとも1つの一致するインプットを有する場合、前記二重支払い通知を有効であると識別し、その結果、前記ブロックチェーンネットワーク上で少なくとも1つの他のノードへ前記二重支払い通知を送信し、
前記2つのトランザクションが少なくとも1つの一致するインプットを有しない場合、前記二重支払い通知を無効であると識別し、その結果、前記ブロックチェーンネットワーク上で前記二重支払い通知を伝播させない、ステップと、
を含む。
【0019】
幾つかの実装では、前記方法は、前記2つのトランザクションが少なくとも1つの一致するインプットを有するかどうかを決定するステップの前に、前記マイナー識別子を妥当性確認するステップ、を更に含んでよい。幾つかの場合には、前記二重支払い通知は前記マイナー識別子を含み、前記マイナー識別子はマイナー公開鍵を含んでよく、
前記マイナー識別子を妥当性確認するステップは、
前記マイナー公開鍵の公開を含むコインベーストランザクションまで前記マイナー識別子をトレースするステップと、
前記マイナー公開鍵を用いて前記二重支払い通知に対する署名を検証するステップと、
を含んでよい。
【0020】
幾つかの実装では、前記方法は、前記2つのトランザクションのトランザクションデータを取得するステップの前に、前記二重支払い通知が妥当性確認されるべきであると決定するステップ、を更に含んでよい。幾つかの場合には、前記二重支払い通知が妥当性確認されるべきであると決定するステップは、
ランダム値を生成するステップと、
前記ランダム値が妥当性確認閾値より低いと決定するステップと、
を含んでよい。
【0021】
幾つかの実装では、前記ブロックチェーンネットワーク上で前記二重支払い通知を送信するステップは、
送信する前に、前記二重支払い通知に署名を追加するステップを更に含んでよい。幾つかの場合には、署名を追加するステップは、
最大数より少ない署名が前記二重支払い通知に追加されていると決定するステップを含む。
【0022】
幾つかの実装では、前記方法は、前記2つのトランザクションが少なくとも1つの一致するインプットを有しない場合、否認通知を生成し送信するステップ、を更に含んでよい。幾つかの場合には、前記否認通知は、少なくとも前記二重支払い通知の識別子を含み、生成することは、現在ノード署名を追加することを含んでよい。幾つかの場合には、前記現在ノード署名は、現在ノードマイナー識別子に基づき生成される。
【0023】
幾つかの実装では、別のノードから否認通知を受信するステップであって、前記否認通知は、前記二重支払い通知の識別子を含み、第2マイナー識別子により署名される、ステップ、
を更に含んでよい。幾つかの場合には、前記方法は、前記マイナー識別子及び前記第2マイナー識別子に関連付けられた評判スコアを取得し、取得することと、相対的評判スコアに基づき前記2つのトランザクションが少なくとも1つの一致するインプットを有するかどうかを決定することとを実行することにより、前記二重支払い通知が妥当性確認されるべきであると決定するステップ、
を更に含んでよい。
【0024】
幾つかの実装では、前記トランザクションデータを取得するステップは、メモプールからトランザクションのうちの1つのトランザクションデータを読み出し、別のノードから他のトランザクションのコピーを要求するステップを含んでよい。
【0025】
別の態様では、ブロックチェーンネットワークにおける二重支払い試行通知を中継する、コンピューティング装置が提供され得る。前記コンピューティング装置は、メモリと、1つ以上のプロセッサと、実行されると前記プロセッサに本願明細書に記載の方法のうちの1つ以上を実行させるコンピュータ実行可能命令と、を含んでよい。
【0026】
更に別の態様では、ブロックチェーンネットワークにおける二重支払い試行通知を中継するためのプロセッサ実行可能命令を格納しているコンピュータ可読媒体であって、前記プロセッサ実行可能命令は、1つ以上のプロセッサにより実行されると、前記プロセッサに本願明細書に記載の方法のうちの少なくとも1つを実行させる、コンピュータ可読媒体が提供され得る。
【0027】
本開示の他の例示的な実施形態は、図面と関連して以下の詳細な説明を読むことから当業者に明らかになるだろう。
【0028】
本願では、用語「及び/又は」は、列挙された要素単独、任意の一部の組合せ、又は要素の全部、を含む列挙された要素の全部の可能な組合せ及び一部の組合せをカバーすることを意図しており、必ずしも追加要素を排除しない。
【0029】
本願では、用語「...又は...のうちの少なくとも1つ」は、列挙された要素単独、任意の一部の組合せ、又は要素の全部、を含む列挙された要素の全部の可能な組合せ及び一部の組合せをカバーすることを意図しており、必ずしも追加要素を排除せず、必ずしも全部の要素を必要としない。
【0030】
本願は、任意のデータセット又は「メッセージ」に適用されるとユニークな固定長英数字文字列を決定論的に(deterministically)生成する多数の暗号ハッシュ関数のうちの任意の1つを含むことを意図している、ハッシング(hashing)又はハッシュ(hash)関数を参照する。ハッシュ関数の結果は、ハッシュ値、フィンガープリント、ハッシュ結果、又はそれらの均等物と呼ばれてよい。例は、限定ではないが、SHA-2、SHA-3、及びBLAKE2を含む。
【0031】
本願明細書では、用語「ブロックチェーン」は、全ての形式の電子的な、コンピュータに基づく、分散型台帳を包含すると理解される。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、並びにこれらの変形を含む。他のブロックチェーン実装が提案され開発されているが、ブロックチェーン技術の最も広く知られているアプリケーションは、Bitcoin台帳である。Bitcoin SVプロトコルにより例示されるBitcoinは、ここでは、便宜上及び説明の目的で参照されることがあるが、本発明はBitcoinブロックチェーンと共に使用することに限定されず、代替のブロックチェーン実装及びプロトコルが本発明の範囲に包含されることに留意すべきである。
【0032】
ブロックチェーンは、コンピュータに基づく非集中型の分散型システムを用いて実装されるピアツーピアの電子台帳である。ブロックチェーンはブロックで構成され、ブロックはまた、トランザクションで構成される。各トランザクションは、特に、ブロックチェーンシステムの中の参加者間でデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも1つのインプット及び少なくとも1つのアウトプットを含む。各ブロックヘッダは、マークル(Merkle)ルートの形式のようなブロックのコンテンツの要約を含み、各ブロックヘッダは前のブロックヘッダのハッシュを含む。その結果、ブロックは一緒に繋がれるようになり、永久の変更不可能な、開始以来ブロックチェーンに書き込まれた全部のトランザクションのレコードを生成する。トランザクションは、スクリプトとして知られている小さなプログラムを含む。スクリプトは、それらのインプット及びアウトプットを埋め込まれ、トランザクションのアウトプットがどのように及び誰によりアクセス可能であるかを指定する。Bitcoinプラットフォームでは、これらのスクリプトはスタックに基づくスクリプト言語を用いて記述される。
【0033】
ブロックチェーンは、ノードのネットワークにより実装される。各ノードは、ネットワーク接続と適用可能なブロックチェーンプトロコルを実行する実行ソフトウェアとを有するコンピューティング装置である。ノードは、トランザクションを検証し、それらをネットワーク内の他のノードへ伝播させる。「マイニングノード」又は「マイナー」と呼ばれる専用ネットワークノードは、未確定のトランザクション、つまり保留中のトランザクションのセットを集めて、ブロックにし、該ブロックを「マイニング」しようとする。マイニングは、これらの例では、ネットワーク内の他のマイナーが彼らの各々のブロックのproof-of-workを解くことに成功する前に、proof-of-work(POW)を解くことを表す。Bitcoinの例では、POWは、結果が採掘難易度(difficultly)パラメータにより設定された閾値より下になるまで、ノンス(nonce)を含むブロックヘッダをハッシングすることを含む。ノンスは、繰り返されインクリメントされ、結果が閾値より下になるまで、又は別のマイナーが成功したノンスをマイナーが受信するまで、ハッシングが繰り返される。マイニング処理における変形は、当業者によく知られている。
【0034】
チェックされる事柄の中でも特に、トランザクションを検証するとき、ノードは、トランザクションへのインプットが有効であるかどうかを決定する。特に、ノードは、アンロックスクリプトが真と評価するかどうかを評価し、インプットが前のトランザクションからの「未使用トランザクションアウトプット」(unspent transaction output (UTXO))を参照するかどうかを決定する。幾つかのノードは、参照されるトランザクションアウトプットがUTXOセットの中にあるか否かの高速な決定を可能にするために、UTXOの実行中リスト又はセットを維持してよい。トランザクションは、幾つかの実装ではトランザクションのハッシュである自身のユニークなトランザクション識別子TxIDにより識別されてよい。幾つかのトランザクションは、1つより多くのアウトプットを有してよく、従って、ユニークなトランザクション「アウトポイント」は、TxID及びインデックスにより識別されてよい。ここで、インデックスは、トランザクションからのアウトプットの順序付きセットの中のアウトプットのうちの1つを指す。トランザクションアウトプット(例えば、アウトポイント)がUTXOセットの中に存在する場合、該トランザクションのアウトプットは「未使用(unspent)」であり、インプットとして機能することが可能である。ノードは、トランザクションインプットが、マイニング済みブロックに含まれることを待っている未確定トランザクションのメモプールの中にある以前に受信したトランザクションへのインプットとして既に使用されているかどうかも評価する。既に使用されている場合、第2の受信したトランザクションは、ノードにより無効であると見なされ、メモプールに含まれず、ネットワーク上に伝播されない。
【0035】
電子マネーシステムのよく知られた課題のうちの1つは、「二重支払い」問題である。つまり、金銭又は他のアセットがデジタルトークン又は他のデジタルデータとして表されるとき、メカニズムは、そのデジタルトークン又は他のデータの保持者が、単にそれを複製すること、及びそれを2つの異なる受信者への支払いとして提供することを防がなければならない。Bitcoinブロックチェーンは、ネットワークの分散型ノードにトランザクション及びブロックに対する種々の妥当性確認チェックを実行させることにより、二重支払い攻撃を防ごうとしている。ブロックを有効として受け付けるためのproof-of-work要件及び合意に基づくプロトコルは、どのブロックも、以前に使用されたインプットを含むトランザクション、又は同じインプットを使用することを意図したトランザクションのペアを含まないことを保証する。第2トランザクションがノードにより受信され、第2トランザクションが、使用された又は未確定トランザクションへのインプットの中で使用されたインプットを使用する場合、ノードは第2トランザクションを無効であるとして破棄し、それをブロックチェーンネットワーク上で伝播させない。これは二重支払いを防ぐが、二重支払い試行が生じたという事実も隠してしまう。第1トランザクションに関連する元のマーチャント及び/又はユーザは、第2トランザクションがそれを知った第1ノードセットにより消され破棄されてしまった場合、企てられた二重支払いの発生を認識できない。これは、悪意ある活動又は主体の検出、及び予防若しくは懲罰的措置の実装を妨害してしまう。
【0036】
1つの選択肢は、二重支払いトランザクションを検出するノードに、トランザクションが無効であると決定されたという事実にも拘わらず、トランザクションを転送させるよう、プロトコルを変更することである。その結果、ネットワーク内の他のノードは、無効なトランザクションも知ることができ、元のマーチャントノードは企てられた二重支払いを認識できるようになる。このような変更の問題点は、ネットワークを無効な二重支払いトランザクションで溢れさせ、そのようなトランザクションの作成者に殆ど又は全くコストをかけずに、各ノードが評価し無効と検出する処理を実行する必要があるサービス拒否攻撃のような、潜在的な攻撃にブロックチェーンネットワークを公開することである。
【0037】
従って、二重支払い試行を検出する1つの選択肢は、新しい未確定トランザクションに関連する潜在的な二重支払いを識別するブロックチェーンノードが、ネットワーク上の残りのノードに、潜在的な二重支払い攻撃に関して通知するが、完全な二重支払いトランザクション自体を必ずしも転送しないことである。これは、ネットワーク内の他のノードに、第2トランザクションに対するトランザクション検証ステップを実行させる計算作業の負担を課すことを回避し得る。更に、ネットワークのノードは、試行された二重支払いの通知を受信し得る。
【0038】
これは、ノードが必ずしも第2トランザクションの完全な妥当性確認を実行する必要がないので、フラディング攻撃の可能な影響を低減することができるが、二重支払いの悪意ある通知の可能性を残したままであり、殆ど又は全くコストをかけずにネットワークを通知で溢れさせる可能性も残したままである。
【0039】
従って、本願の少なくとも1つの態様によると、二重支払い通知は、特定のインプットに関連して見られる第1二重支払いについてのみ送信される。これは、同じインプットの二重支払いにおける複数の試行に関する複数の通知でネットワークを溢れさせることを回避できる。更に、通知は、元のトランザクション及び主張された二重支払いトランザクションのトランザクション識別子(TXID)を含む。通知は、トランザクションが識別されたときのタイムスタンプを更に含んでよい。これは、第2の適時の(second-in-time)トランザクションが非常に大きく構成される可能性を回避する。
【0040】
ここに記載される通知処理は、二重支払い試行が生じた事実の適時の流布を保証する。二重支払い試行が生じたことを認識することは、同じインプットの1回の二重支払い試行が生じたことを認識するよりも、ネットワークにとって一層有用である。従って、最初の発生のみが、二重支払い通知に含まれればよい。
【0041】
上述の処理は、悪意あるノードが偽の二重支払い通知を生成し送信する攻撃にネットワークを開放したままになり得ることが分かる。従って、本願の別の態様によると、二重支払い通知が、ノード識別子により署名される。特に、二重支払い通知は、マイナー識別子により署名されてよい。マイナー識別子は、公開鍵の形式の識別子であってよい。マイナー識別子は、マイニングノードに関連付けられ有効性チェックトランザクションをチェックすることにより取り消されない検証可能なマイナーIDであってよい。マイナーIDは、マイニングノードによりマイニングされたコインベーストランザクションを用いて確立されてよい。マイナーID、可能な実装処理、及び使用例の幾つかの例の詳細な説明は、後述される。
【0042】
従って、適正な二重支払い通知は、検証可能なマイナー識別子により署名されてよい。そのような通知を受信するノードは、二重支払い通知が適正であると決定することを条件として、マイナーIDが有効であることを検証してよい。ノードは、二重支払いがトランザクションの一方又は両方のコピーを要求することにより発生したことを更に検証してよい(ノードは、ローカルメモプールの中にトランザクションのうちの1つを既に有している場合がある)。ノードが、二重支払い試行が生じたことを検証した場合、それをネットワーク内の他のノードに渡す前に、自身の署名を通知に追加してよい。これは、追加の独立の確認を有する通知を提供することができ、更に、二重支払い通知が適正であることの保証を後続のノードに提供する。
【0043】
中間ノードが二重支払い通知を受信し、トランザクションデータから、申し立てられた二重支払い通知が偽物であると決定した場合、中間ノードは、二重支払い通知を拒否する否認メッセージを生成しブロードキャストしてよい。これは、悪意のあるマイニングノードが偽の二重支払い通知を生成するのを阻止するのに役立つ可能性がある。通知がそのマイナーIDに関連付けられているため、偽の通知の発見と公開は、そのマイナーIDに関連付けられた評判に悪影響を与える可能性があるためである。これは、ネットワークのノードによって維持される評判スコア又はその他のメトリックに反映され得る。この意味で、本願明細書に記載される通知及び否認処理は、ノードが高い評判スコアを維持する必要があることを利用して、帯域幅及び計算リソースのようなネットワーク容量を浪費する可能性のある否定的活動を阻止する。
【0044】
図9を参照すると、ブロックチェーンネットワーク内で二重支払い試行通知を生成する例示的な方法900がフローチャート形式で示される。方法900は、幾つかの例では、マイニングノードにより実行されてよい。方法900は、メモリに格納されたプロセッサ実行可能命令により実施されてよい。プロセッサ実行可能命令は、プロセッサにより実行されると、プロセッサに、後述する動作を実行させる。
【0045】
方法900は、動作902で、マイニングノードであってよいノードがトランザクションを受信すると、開始される。通常、ノードは、トランザクション妥当性確認チェックを実行して、トランザクションが適用可能なブロックチェーンプロトコルの要件を満たすことを確認する。これらのチェックのうちの1つは、動作904により示されるように、トランザクションへのインプットがメモプールの中の別のトランザクションへのインプットとして未だ現れていないことである。メモプールは、ノードによりローカルに維持されてよく、又は利用可能でありアクセス可能であってよいが、特別なノードにより維持される。メモプールは、幾つかの実施形態では、データベース又は分散型データベースであってよい。
【0046】
トランザクションが、そのインプットの各々が未だメモプールの中の別のトランザクションへのインプットではないことを含む、妥当性確認要件を満たす場合、動作906により示されるように、ノードは、メモプールに受信したトランザクションを追加し、それをブロックチェーンネットワーク上の他のノードへと伝播させる。しかしながら、受信したトランザクションへのインプットのうちの1つが、メモプールの中の以前に受信したトランザクションへのインプットとして識別される場合、方法900は、動作908に進み、そこで、ノードは、同じインプットと関連して二重支払い通知を既に知ってるかどうかを評価する。既に知っている場合、トランザクションは破棄され、方法900は、動作902に戻り、次の受信トランザクションを評価する。前述のように、二重支払い通知は特定のインプットに関して1回だけ送信され、同じインプットに対する二重支払い試行のフラッディングに関連する通知でネットワークが溢れるのを回避する。
【0047】
これが攻撃された(impugned)インプットに関する二重支払いの最初の検出である場合、動作910で、ノードは二重支払い通知を生成する。この例の二重支払い通知には、メモプール内の先に受信したトランザクションのトランザクション識別子、二重支払いと思われる後に受信したトランザクションのトランザクション識別子、及び2つの各トランザクションに関連付けられたタイムスタンプが含まれている。二重支払い通知には、さらにノード識別子が含まれる。この例では、ノードがマイニングノードである場合、ノード識別子はマイナーIDである。特に、二重支払い通知には、マイニングノードが二重支払い通知を生成したことを明白に証明するマイナーID署名が含まれている。以下で説明するように、マイナーIDはコインベーストランザクションでブロックチェーンに記録され、関連する有効性チェックトランザクションをチェックして、そのアウトプットが未使用トランザクションアウトプットデータベースに残っていることを確認することで、他のノードによって有効であることが簡単に検証される。マイナーIDにより二重支払い通知に署名することで、マイニングノードは通知に自身の識別子を与え、それによって通知の信頼性に自身の評判を添える。
【0048】
マイニングノードは、申し立てられた二重支払いトランザクションをローカルメモリにさらに格納してよいことに注意する。トランザクションが妥当性確認されておらず、候補ブロックに含めることができないため、マイニングノードは二重支払い通知を自身のメモプールに格納しない。しかしながら、トランザクションのコピーをメモリに保持して、マイニングノードが、二重支払いの試行が発生したことを検証している他のノードに、疑わしい二重支払いトランザクションのコピーを提供できるようにすることができる。この目的のために、マイニングノードは、申し立てられた二重支払いトランザクションに割り当てられた他のメモリ記憶領域のデータ構造を維持することができる。
【0049】
動作912では、マイニングノードはブロックチェーンネットワークに二重支払い通知を伝播する。
【0050】
図10を参照すると、ブロックチェーンネットワーク内で二重支払い試行通知を中継する例示的な方法1000がフローチャート形式で示される。方法1000は、幾つかの例では、ブロックチェーンネットワークにより実行されてよい。ノードは、フルノード、マイニングノード、ストレージ及び妥当性確認ノード、又はその他のタイプのネットワークノードであってよい。方法1000は、メモリに格納されたプロセッサ実行可能命令により実施されてよい。プロセッサ実行可能命令は、プロセッサにより実行されると、プロセッサに、後述する動作を実行させる。
【0051】
方法1000は、ノードが動作1002でブロックチェーンネットワークを介して二重支払い通知を受信することで開始する。上述のように、二重支払い通知は、マイナー識別子又は等価なノード識別子によりデジタル方式で署名されてよい。動作1004では、ノードは通知が署名されていることと、マイナーIDが有効であることを確認できる。これは、署名の検証とマイナーIDの妥当性確認が含まれる場合がある。マイナーIDの妥当性確認には、マイナーIDがブロックチェーン上のコインベーストランザクションに含まれていること、及び関連する有効性チェックトランザクションがUTXOデータベース内のアウトプットを有することの検証が含まれる場合があり、これによりマイナーIDが取り消されていないことが確認される。マイナーIDを検証できない場合、ノードは二重支払い通知を破棄することがある。
【0052】
マイナーIDが検証された場合、動作1006でノードは二重支払い通知の有効性をチェックするかどうかを判断できる。この例では、ネットワークの計算負荷を軽減し、通知の伝播速度を向上させるために、ネットワークのノードの一部だけが通知の有効性をチェックする。この例では、比率はノードの約10%になるが、他の実装では他の比率を使用できる。動作1006での決定は、乱数生成と、閾値が乱数空間の10%に設定されている場合に、乱数が閾値未満かどうかのチェックに基づいて行うことができる。妥当性チェックを実行するノードのランダムなサブセットを確率的に選択するために、他のメカニズムを使用することもできる。
【0053】
ノードが通知の有効性をチェックしないと判断された場合、方法1000は動作1018に進み、二重支払い通知をブロックチェーンネットワーク上にさらに伝播する。それ以外の場合、方法1000は動作1008に進み、ノードは申し立てられた二重支払いトランザクションを取得する。いずれかのトランザクションがノードのメモプールに存在する可能性がある。欠落したトランザクションは、二重支払い通知を生成したマイニングノードから取得できる。幾つかの例示的な実装では、ノードは「getdata」メッセージを使用して、マイニングノードからのトランザクションのコピーを要求する場合がある。
【0054】
ノードが両方のトランザクションを有すると、ノードは動作1010で示されているように、インプットを比較することによって、それらが実際に試行された二重支払いであることを検証できる。そうでない場合、ノードは動作1012で否認メッセージを生成してよい。否認メッセージの例について、さらに説明する。この例では、否認メッセージは二重支払い通知の信頼性に異議を唱えるメッセージと考えることができる。ノードはブロックチェーンネットワーク上で否認メッセージをブロードキャストし、二重支払い通知の伝播を見送ることができる。
【0055】
ノードが動作1010で、二重支払い通知に記述されている二重支払い試行が事実であることを検証した場合、二重支払い通知をブロックチェーンネットワーク上でさらに伝播しよい。幾つかの例では、ノードは、通知を検証したことを他のノードへの信号として、自身の署名を二重支払い通知に追加する場合がある。二重支払い通知のサイズの肥大化を防ぐために、付加される署名の数は、実装によっては最大で制限される場合がある。したがって、動作1014で、ノードは付加された署名の数が最大に達したかどうかを評価してよい。そうでない場合は、動作1016でノードが二重支払い通知に自身の署名を追加する。どちらの場合も、ノードは動作1018でブロックチェーンネットワーク上の他のノードに二重支払い通知を伝播する。
【0056】
このようにして、二重支払い通知はブロックチェーンネットワーク上で伝播され、同時に少なくとも一部のブロックチェーンノードによって妥当性確認及び検証される。マイニングノードが二重支払い通知を受信し、例えばMerchantAPIを介して以前にマーチャントノードから直接トランザクションのいずれかを受信した場合、常に検証動作を実行して二重支払いの申し立てを検証し、検証された場合は、申し立てられた二重支払いに関してマーチャントノードに通知することができる。これにより、マーチャントノードは、トランザクションに何らかの潜在的な問題がある可能性があることを通知し、マーチャントノードがメッセージやその他の通知をマーチャント装置に出力する可能性がある。マーチャントノードは、MerchantAPIを使用して、後続又はより頻繁にqueryTransactionStatusチェックを実行できる。
【0057】
前述のように、ブロックチェーンノードが二重支払い通知の二重支払い申し立てが虚偽であると判断した場合、否認通知を生成して送信してよい。否認通知は、ブロックチェーンノードが、二重支払いとされる2つのトランザクションが共通のインプットを共有していないことを識別したことを示している。トランザクションが受信される順序や、そのうちのどれが二重支払い攻撃であるかは、ノードによって異なる場合があるため、参照しない。否認メッセージには、一例として、元の二重支払い通知の内容、及び否認メッセージを生成するノードからの公開鍵と署名が含まれる場合がある。ノードがマイニングノードの場合、公開鍵と署名はマイナーIDであってよい。
【0058】
二重支払い通知と否認通知を受け取るブロックチェーンネットワーク内の別のノードは、どちらが正しいかを判断する立場にある。もちろん、トランザクションのコピーを入手し、二重支払い試行が発生したかどうかを自身で検証することで、そうすることができる。ネットワークの潜在的な計算と帯域幅の負担を軽減するために、ノードは、通知を額面どおりに受け入れるか検証を実行するかを決定するために、マイナーIDと関連する評判スコアに部分的に依存する、どの通知が正しいかを決定する処理に従うことができる。この処理では、少なくとも一部のノードが二重支払いの申し立ての検証を実行する。
【0059】
図11を参照すると、ブロックチェーンネットワーク内で二重支払いの主張と否認の競合を解決する例示的な方法1100がフローチャート形式で示される。方法1100は、幾つかの例では、ブロックチェーンネットワークにより実行されてよい。ノードは、フルノード、マイニングノード、ストレージ及び妥当性確認ノード、又はその他のタイプのネットワークノードであってよい。方法1100は、メモリに格納されたプロセッサ実行可能命令により実施されてよい。プロセッサ実行可能命令は、プロセッサにより実行されると、プロセッサに、後述する動作を実行させる。
【0060】
ノードは、動作1102で二重支払い通知と否認通知を受信する。場合によっては、ノードだけ(又は最初のもの)が否認通知を受信するが、否認通知には二重支払い通知のコピーが含まれることがある。この例では、第1マイニングノードによって二重支払い通知が生成され、第2マイニングノードによって否認通知が生成されている。
【0061】
動作1104では、ノードは先ず、二重支払い通知と否認通知に署名したノード識別子が有効であることを検証できる。つまり、第1マイニングノードのマイナーIDと第2マイニングノードのマイナーIDが有効であり、取り消されていないことを確認できる。第1マイニングノードのマイナーIDが有効で、第2マイニングノードのマイナーIDが無効である場合、動作1106で、ノードは二重支払い通知を「受け入れ」、否認通知を拒否できる。これには、図10に関して前述したような、二重支払い通知に関する妥当性確認処理の実行が含まれる。第1マイニングノードのマイナーIDが無効で、第2マイニングノードのマイナーIDが有効である場合、動作1106で、ノードは否認通知を「受け入れ」、二重支払い通知を拒否できる。
【0062】
両方のマイナーIDが正当なものである場合、ノードはどちらのマイニングノードが正しいかを判断する必要がある。つまり、二重支払いを主張しているもの、又は、二重支払いを主張しているものが偽物である。一実装では、ノードは単に独立してトランザクションデータを取得し、試行された二重支払いが発生したかどうかを判断する。ただし、この例では、ネットワークノードの計算負荷を軽減するために、ネットワーク内のすべてのノードが必ずしもそうする必要はないため、ノードは最初に二重支払いの申し立てを検証する必要があるかどうかを判断してよい。検証するかどうかを判断するために、この例では、ノードはマイニングノードに関連付けられている評判スコアを利用して、独立して検証する必要がある可能性に影響を与える。例えば、動作1110では、ノードは第1及び第2マイニングノードのマイナーIDに評判スコアが関連付けられているかどうかを評価できる。場合によっては、ブロックチェーンネットワークがマイニングノードの評判スコアを追跡するように設定されていることがある。マイナーIDに関連して以下で説明するように、評判スコアは、マイニングノードの作業履歴、つまりマイニングされたブロック又はブロックのマイニングで消費された計算リソースを反映する場合がある。ただし、幾つかの実装では、合意に基づき評判スコアに影響を与えるために他の要因が使用される場合がある。例えば、誤った通知の検出は、ネットワークによって合意に基づき確認された場合、マイニングノードの評判スコアに悪影響を及ぼす可能性がある。反対にネットワークによって合意に基づき確認された否認通知の公開のような積極的な動作は、マイニングノードの評判スコアに好ましい影響を及ぼす可能性がある。
【0063】
動作1112では、ノードはいずれかのマイニングノードが評判スコア(又はデフォルトの評判スコア、つまり履歴なし)を有しないかどうかを評価できる。両方のマイニングノードが評判スコアを有する場合、又はどちらのマイニングノードも評判スコアを有しない場合、ノードは競合を解決する必要があるかどうかを判断するために評判に依存できないため、二重支払いの申し立てが正しいかどうかを常に検証する可能性がある。動作1118は検証動作を反映している。さらに、ノードのいずれかが正しくないため、動作1120に反映されているように、そのノードの評判スコアが存在する場合には、それを調整する必要がある。しかしながら、動作1112では、マイニングノードの一方に評判スコアがあり、もう一方にはないことが分かるので、動作1114では、ノードは二重支払いの申し立てを検証するかどうかを判断できる。この決定は、例えば、ネットワーク上のノードのランダムに選択されたサブセットのみが、二重支払い通知が正しいかどうかを評価できるというように、図10の動作1010での決定に似ているかもしれない。他のノードは、マイニングノードには評判スコアが危険にさらされているため、評判スコアを持つマイニングノードによって発行された通知又は告知が最も正しい可能性が高いことを受け入れてよい。この意味で、「受け入れ」には、受け入れられた通知をさらに伝播することと、拒否された通知を伝播しないことが含まれてよい。
【0064】
上記の方法1100の例は、二重支払い通知と否認通知の競合を解決する方法の一例の実装であることが理解されるだろう。さらに、特定の動作は、方法1100の動作に重大な影響を与えることなく、異なる順序で変更、置換、又は実行することができることが理解される。ノードは、相対的な評判スコア、評判スコアの欠如、通知又は告知に対する追加のノード署名者の数、又はこれらの組み合わせに基づいて、二重支払い通知を検証するかどうかを決定して競合を解決するために、様々な手法を使用できる。
【0065】
上記の処理の例では、通知の送信を提案している。多くのブロックチェーンシステムでは、通知、データ転送、要求などのために所定の構文を使用して、ノード間でデータが交換される。ここで検討されている通知の種類の非限定的な例の概要を次に示す。
【0066】
二重支払い通知には、次のようなメッセージ構造と構文がある。
【数1】
【0067】
マイナー識別署名ブロックは、次のように構造化できる。
【数2】
【0068】
さらなる例として、二重支払いの申し立てに関する否認通知は、次の形式をとることができる。
【数3】
【0069】
上記の例は例示的であり、他の実装は異なる構文を持つ可能性があることが理解されるだろう。
【0070】
また、幾つかの実装では、二重支払い通知及び/又は否認通知処理は、二重支払いトランザクションが閾値サイズより大きい場合に選択的に適用されてよいことも理解される。コンパクトで検証が容易な小規模な二重支払いトランザクションの場合、マイニングノードはブロックチェーンネットワークを介してそのトランザクションを伝播することを選択できる。そのために、新しいインベントリ(inventory)タイプDOUBLE_SPENDを定義して、二重支払いトランザクションの可用性をマークし、適切に検証されたトランザクションと区別することができる。その場合でも、ノードはネットワークに過度の負荷をかけないように、ランダムベースで二重支払いトランザクションを頻繁に要求することを選択する場合がある。場合によっては10%の閾値を使用することもある。そのレベルであっても、ノードは複数のDOUBLE_SPENDインベントリメッセージを見ており、トランザクションに疑いを投げかけ、その状態が潜在的な二重支払い攻撃であることを確認し、マーチャントノードに通知するだけで十分である。
【0071】
検証可能なマイナーアイデンティティの確立
上述のように、マイナーは、コインベーストランザクションの中にマイナーアイデンティティの宣言を含むブロックをマイニングすることにより、マイナーアイデンティティを確立してよい。新たにマイニングされたブロックの有効性及びその中の全部のトランザクションの有効性は、ブロックチェーンネットワークにより確認される。コインベーストランザクションの中のマイニングノードの自身のマイナーアイデンティティの包含は、proof-of-workにより裏打ちされたアイデンティティの宣言である。以下の例におけるマイナーアイデンティティは、公開鍵である。第三者CAは、マイニングノードとその宣言された公開鍵との間の関連付けを検証する必要がない。なぜなら、関連付けはブロックチェーンネットワーク及びproof-of-workにより裏打ちされるからである。
【0072】
マイナーアイデンティティの可能な取消を実現するために、例えば、対応する秘密鍵が損なわれた場合、マイナーは先ず有効性チェックトランザクションを生成し、その中でマイナーアイデンティティが宣言され、それについてマイナーにより制御されるアウトプットがある。コインベーストランザクションは、この有効性チェックトランザクションへの参照を含んでよい。別のノードにより実行されるアイデンティティ検証動作の部分は、有効性チェックトランザクションがマイナーにより制御されるアウトプットの移転を通じて「取り消され」ていないことを確認することであってよい。つまり、マイナーは、有効性チェックトランザクションのアウトプットを「使用する」ことにより、それにより、それを未使用トランザクション(unspent transaction (UXTO))セットから除去することにより、自身のマイナーアイデンティティを無効にしてよい。これは、マイナーアイデンティティを取り消すために新しいブロックをマイニングすることに依存しない高速取消メカニズムを提供する。
【0073】
図1を参照すると、ブロックチェーンネットワークにおいてマイナーアイデンティティを確立する1つの例示的な方法100をフローチャートの形式で図示する。方法100は、設定動作102と、登録動作104と、を含む。設定動作102は、有効性チェックトランザクション(validity-check transaction (VCT))を生成し伝播させることを含む。VCTは、任意のインプットと2つのアウトプットとを含む。1つのアウトプットは、マイナーにより制御されるアウトプットであり、任意のトークンをマイナーにより制御されるアドレスに割り当てる。VCTの第2アウトプットは、本例ではマイナーにより選択された公開鍵PKIDであるマイナーアイデンティティを含む情報フィールドを含む。マイナーは、対応する秘密鍵skIDを保持する。情報フィールドは、Bitcoinに基づく実装のOP_RETURNフィールドであってよい。マイナーアイデンティティ(例えば、マイナーID)は、本例では、公開鍵PKIDである。
【0074】
VCTは、ブロックチェーンネットワーク上を伝播し、最終的にはマイニング済みブロックへの包含により確定される。その結果、VCTはオンチェーンになる。
【0075】
登録動作104は、マイニングノードが新しいブロックをマイニングすることに成功することを含む。ブロックをマイニングすることは、未確定トランザクションのメモプールから選択された複数のトランザクションを含む候補ブロックを組み立てることを含む。マイニングノードは、更に、コインベーストランザクションを自身の候補ブロックに挿入する。マイニングノードは、次に、採掘難易度設定より低いハッシュを見付けるために、ヘッダ内のノンスを繰り返し増大し、ブロックヘッダをハッシングすることにより、ブロックをマイニングしようとする。別のマイニングノードが成功した場合、マイナーは、他のマイニングノードの新しいブロックが有効であることを検証し、次に、新しい候補ブロックを生成し、再び試行する。
【0076】
動作104で、マイニングノードは新しいブロックをマイニングすることに成功し、新しいブロックはコインベーストランザクションを含む。コインベーストランザクションは、それ自体が、マイナーアイデンティティ、例えばPKIDを含み及びVCTへの参照を含む。参照は、VCTのトランザクション識別子、例えばTxIDVCTであってよい。
【0077】
マイニングノードがマイナーアイデンティティを宣言するコインベーストランザクションを含むブロックをマイニングすることに成功すると、それは、自身のマイナーアイデンティティを確立することに成功している。アイデンティティは、検証可能であり、マイニングノードにより、必要に応じて、証明可能且つ追跡可能な方法で、取り消され又は更新できる。更に、アイデンティティ及びマイニングノードとのその関連付けは、proof-of-workにより裏打ちされ、ネットワークによりセキュアにされ、第三者が証明機関における信頼を要求することなく、マイナーアイデンティティ(例えば、その公開鍵PKID)に依存することを可能にする。マイナーアイデンティティは、次に、特に、マイナーアクティビティを追跡すること、マイナーアイデンティティ又は状態を証明すること、マイナーとのセキュアな暗号化通信を確立する又は従事すること、及び様々な目的のためにマイナーをランク付けすること、を含む多数の目的のために使用されてよい。
【0078】
図2も参照すると、マイナーアイデンティティを確立する方法100で使用されてよい1つの例示的な設定方法200を示す。方法は、本例では、マイニングノードにより実行される。
【0079】
動作202及び304で、マイニングノードは、秘密鍵sskIDを選択し、対応する公開鍵PKIDを見付ける。公開鍵PKIDはマイナー識別子である。
【0080】
動作206で、マイニングノードは、次に、任意のインプットと、2個のアウトプットと、を含む有効性チェックトランザクションを生成する。インプットは、任意のUTXOであってよく、該UTXOについて、マイニングノードは対応する秘密鍵を保持する。つまり、任意のUTXOはマイナーにより制御される。多くの実装では、インプットは、VCTがブロックに含まれることを保証するためにVCTに関連付けられたトランザクションコストを相殺するのに十分なコイン又はトークン量であってよい。幾つかの実装では、最小トークン量はポリシにより確立されてよい。
【0081】
アウトプットのうちの1つは、マイニングノードにより制御されるアドレスへのアウトプットである。つまり、アウトプットは、マイニングノードが関連するロックスクリプトをアンロックできるようにする、マイニングノードが対応する秘密鍵を保持するアドレスへのものである。幾つかの例では、アウトプットアドレスは、PKVCTとラベル付けされてよく、PKVCTはマイニングノードにより選択された任意の公開鍵であり、PKVCTについて、マイニングノードが対応する秘密鍵を保持する。アウトプットは、例えば、マイニングノードにより選択され制御される公開鍵ハッシュ(例えば、Bitcoinアドレス)への移転を指定するP2PKH(pay to public key hash)演算であってよい。
【0082】
他のアウトプットは、情報が挿入されてよい非運用情報フィールドを含む。特に、フィールドは、マイナー識別子を含む。Bitcoinに基づく実装では、アウトプットは、OP_RETURNオペコードを使用して、情報フィールドを提供してよい。
【0083】
非運用情報フィールドが、その用語が理解されるように、必ずしもトランザクションの「アウトプット」として実装されないトランザクション内の情報を公開する目的で、トランザクションに含まれてよいブロックチェーンプトロコルがあってよい。しかしながら、情報フィールドを参照するこれらの例における用語「アウトプット」は、代替ブロックチェーンプロトコルにそのような可能な実装を含むことを意図している。
【0084】
動作206でVCTが生成されると、動作208で、マイニングノードは、次にVCTをブロックチェーンネットワーク上で伝播させる。当業者は、VCTの伝播が、トランザクションを検証し及び次にそれをVCTが接続された全部の他のノードへ送信するネットワークの各ノードに関与してよく、その結果、トランザクションが全ブロックチェーンネットワークを通じて迅速に伝播されることを理解する。未確定トランザクションとして、それはメモプールに挿入される。該メモプールから、個々のマイニングノードは、候補ブロックに包含するためにトランザクションを選択する。従って、それは、マイニング済みブロックへの包含により、最終的に「確定」される。動作210で、マイニングノードは、VCTがマイニング済みブロックに含まれることにより、確定されるかどうかを評価する。確定されると、動作212で、マイニングノードは、トランザクション識別子TxIDVCTを記録する。マイニングノードは、幾つかの実装では、VCTがマイニングされる前に、トランザクション識別子を記録してよいことが理解される。
【0085】
ブロックチェーンのVCT部分により、PKVCTへのその第1アウトプットは、マイニングノードが該アウトプットに関連付けられたトークンを移動する/移転することを選択するまで、「未使用」アウトプットのUXTOセットの部分を形成する。このUXTOは、有効性チェックトランザクションとして機能する。それがUTXOセットの部分である限り、VCT内のマイナー識別子は有効のままであり取り消されない。それがUTXOセットの中に存在しなくなると直ぐに、VCT内のマイナー識別子はもはや有効ではない。
【0086】
図3も参照すると、マイナーアイデンティティを確立する方法100で使用されてよい1つの例示的な登録方法300を示す。方法は、本例では、マイニングノードにより実行される。方法300は、マイナー識別子に関連付けられた有効性チェックトランザクションを生成する設定動作が既に生じていると仮定する。
【0087】
動作302で、マイニングノードは候補ブロックを生成する。候補ブロックは、未確定トランザクションのメモプールから選択された多数のトランザクションを含む。動作304により反映されるように、マイニングノードは、次に、候補ブロックにコインベーストランザクションを挿入する。コインベーストランザクションは、マイニングノードのために所定数の新しいトークン又はコインをマイニングすることに加えて、マイナー識別子PKID及びVCTへの参照.を含む情報フィールドを含む。参照は、トランザクション識別子TxIDVCTであってよい。情報フィールドは、例えばOP_RETURNコード又は式を用いて提供されてよい。
【0088】
マイナー識別子及びVCTへの参照に加えて情報フィールドは、追加情報を含んでよい。例えば、それは、どんなアクションがコインベーストランザクションにより実装されているかを示すアクション識別子又はコードを含んでよい。この例では、アクションは、「登録」であってよく、マイニングノードがそのマイナー識別子を公に登録していることを示す。それは、代替として、署名を含んでもよい。例として、署名は、情報フィールドの残りの部分の署名であってよい。例えば、
【数4】
ここで、VCTはTxIDVCTであり、Miner IDはPKIDである。
【0089】
このコインベーストランザクションを有する候補ブロックが生成されると、動作306により示されるように、マイニングノードは、ブロックをマイニングしようとする。それは、また、動作308により示されるように、競争しているノードが別のブロックをマイニングするのに成功するかどうかを評価する。競争しているノードがブロックをマイニングする競争に勝つと、マイニングノードは、他のブロックを評価し、それをブロックチェーンに追加し、動作302に戻って新しい候補ブロックを構築し再び挑戦する。
【0090】
マイニングノードが候補ブロックのマイニングに成功した場合、それは、コインベーストランザクションのトランザクション識別子TxIDREGを記録する。代替として、それが1つのコインベーストランザクションのみを含むので、ブロック数にだけ注意すればよく、他のノードはブロック数に基づき識別できることに留意する。
【0091】
登録コインベーストランザクションを有するブロックをマイニングすることに成功すると、マイニングノードは、自身のマイナー識別子を登録することに成功し、それをブロックチェーン上に発行する。マイナー識別子、例えば公開鍵PKIDを受信した別のノードは、公開鍵が有効であり、マイニングノードに関連付けられていることを、別個の証明機関への信頼に依存することなく、検証してよい。
【0092】
図4は、本願の態様に従い、ノードがマイナー識別子を検証するために実行し得る1つの例示的な方法400をフローチャートの形式で示す。ノードは、マイナー識別子PKIDを検証すべき、ブロックチェーン内の又は外の任意のノードである。検証は、例えば、マイナーからの要求を検証する又は認可すること、マイナーとの通信セッションを確立すること、又は公開鍵PKIDの有効性及びそのマイニングノードとの関連付けを証明すること、の部分として生じてよい。
【0093】
動作402で、ノードは、マイナーID(PKID)及び登録トランザクション識別子(TxIDREG、又は幾つかの例では、登録コインベーストランザクションが現れるブロック数)を受信し又は検索する。動作402は、マイニングノードが署名したと主張するメッセージを検索し又は受信することを更に含んでよい。メッセージm及び署名σmは、マイニングノードにより提供されてよい。幾つかの例では、メッセージ及びその署名は、マイニングノードにより、そのアイデンティティの証明として提供される又は発行されるデジタル証明の部分であってよい。
【0094】
動作404で、ノードは、登録トランザクション識別子TxIDREG.に基づき、ブロックチェーンから登録コインベーストランザクションを検索する。動作406で、それは、次に、登録コインベーストランザクション内の特定のデータを検証し又は確認する。例えば、ノードは、OP_RETURNフィールドをパースして、コインベーストランザクションからの該フィールド内の情報を抽出してよい。パースした情報から、それは、VCTトランザクション識別子TxIDVCTを取得する。それは、OP_RETURNフィールドがマイニングノードにより提供された同じ公開鍵PKIDを含むこと、及び「アクション」が「登録」であることを確認してよい。
【0095】
動作408で、登録コインベーストランザクション内で発行されたVCTトランザクション識別子から、ノードは、VCTを検索してよい。動作410により示されるように、ノードは、VCT内のOP_RETURNフィールドが同じ公開鍵PKIDを有することを確認してよい。それは、次に、VCTの他のアウトプットが「未使用」のままであるかどうか、つまり、利用可能なアウトプットポイントのうちのUTXOセットの部分を残していることを評価してよい。これは、直接に又は中間ノードを通じて、UXTOセットデータベースをクエリすることを含んでよい。クエリは、トランザクション識別子TxIDVCTを含んでよいアウトポイント識別子、及びどのアウトプットかを示すインデックスに基づいてよい。アウトプットがUXTOセット内に現れない場合、マイナー識別子は、取り消された又は置き換えられているので、無効である。従って、検証は失敗する。
【0096】
しかしながら、アウトポイントがUXTOセット内にある場合、動作414で、ノードは、PKIDを、マイニングノードの検証済み公開鍵として取り扱ってよく、PKIDを用いてマイニングノードの署名を検証して、マイニングノードの署名を確認してよい。動作414は、ノードがコインベーストランザクションのOP_RETURNフィールド内にある署名を確認すること、又は存在する場合には、メッセージmに対する署名σmを確認すること、又はその両方を含んでよいことに留意する。明らかに、署名チェックが失敗した場合、意図されたマイニングノードは、対応する秘密鍵の保持者として検証できず、検証は失敗する。署名チェックが成功した場合、マイニングノードは、マイニング識別子、つまり検証された登録された公開鍵PKIDに関連付けられたマイニングノードとして検証される。
【0097】
上述のように、登録されたマイナーIDは、UXTOセットからVCTの第1アウトプットを除去することにより取り消すことができる。これは、そのアウトプットを、任意の他のトランザクションへのインプットとして用いることにより、「使用する」ことを通じて行われる。これは、該第1アウトプットに割り当てられた任意のトークンを、取消トランザクション内の新しいアドレスへと移転することを含んでよい。取消トランザクションの生成及び伝播は、検証ノードがUXTOセット内のアウトプットを特定することができなくなるので、マイナーIDの任意の検証を失敗させるのに十分である。しかしながら、マイナーは、更に、自身の次のマイニングされるブロックのためのコインベーストランザクションにOP_RETURNフィールドを含めることにより、取消を登録してよい。一例では、OP_RETURNは、アクション「取消」、及びマイナーIDを含んでよい。幾つかの実装では、それは、登録トランザクション及び取消トランザクションの両方のトランザクション識別子、及び署名を更に含んでよい。
【0098】
多くの場合には、マイナーIDをその秘密鍵を損なうことにより単に取り消すのではなく、マイニングノードは、自身のマイナーIDを「更新」又は置き換えたいと望むことがある。これは、秘密鍵の開示又は窃盗に起因してよく、又は鍵マテリアルの定期的な更新を保証するために、リスク管理の部分として定期的に行われてよい。
【0099】
古いマイナーIDである PKID-OLDを更新するために、マイニングノードは、先ず、新しい公開鍵PKID-NEWのために新しいVCTを生成する。その処理から、マイニングノードは、新しいVCTトランザクション識別子TxIDVCT-NEWを取得する。マイニングノードは、次に、新しいコインベーストランザクションを有する新しいブロックをマイニングして、新しいマイナーIDを登録する。しかしながら、それを古いID及び古いIDの任意の作業履歴にリンクするために、マイナーはアクション「更新(Update ID)」又は「ID更新(Update ID)」を使用して、コインベーストランザクションがマイナーIDの最初の登録ではなく、前のマイナーIDを置き換えることであることをシグナリングしてよい。更新コインベーストランザクション内のOP_RETURNフィールドの内容は、以下を含んでよい:
【数5】
【0100】
本例では、更新動作は、マイニングノードが最大3個の署名を供給することを含み、1つは古いIDに関連し、1つは古いVCTに関連し、1つは新しいマイナーIDに関連する、ことが理解される。幾つかの例では、古いVCT署名は含まれなくてよい。
【0101】
また、マイニングノードは、何らかの他のトランザクションへのインプットとしての、古いVCTからのアウトプットの使用を通じて、前のマイナーIDを無効にしてよいことが理解される。一例では、アウトプットは、新しいVCTへのインプットであってよい。別の例では、マイニングノードは、ブロックをマイニングすることに成功して更新マイナーIDを登録するまで、別個の取消トランザクションを伝播させて自身の古いマイナーIDを無効にするのを、待ってよい。
【0102】
上述のシステムを用いると、マイナーは、自身の証明可能な識別子をブロックチェーン上で確立し登録することができる。それをマイニング済みブロックのコインベーストランザクション内に含めることにより、マイナーは、自身が善意のマイニングノードであることを証明し、識別子及び関連するマテリアルの有効性はproof-of-workにより裏打ちされる。VCTは、必要な場合には、高速取消のためのメカニズムを提供する。幾つかの例示的な実装では、VCTは、ポリシにより、少なくとも所定のトークン又はコイン値がアウトプットに割り当てられ、それによりproof-of-workをproof-of-stakeにより補強する必要があってよい。有利なことに、上述のシステムは、信頼機関への信頼の必要を回避し、マイニングノードの追加作業を含まず、ブロックに僅かな追加データしか含まない。
【0103】
上述の登録システム及び方法は、マイナーがアイデンティティを証明することを可能にし、別のノードが信頼機関に依存することなく検証可能なデジタル証明をマイニングノードに提供する。更に、後述するように、マイナー識別子は、マイナーによりマイニングされるブロックからのコインベーストランザクションを一緒に証明可能に繋げるために使用されてよい。これは、マイナーに、彼らのマイナーIDに関連付けられた検証可能な作業履歴を提供する。この作業履歴は、マイナー状態、特定のリソースにアクセスするための資格付与、何らかの目的のためのマイナーの階層構造内のランク付け、等を含む多数の事柄を確立するときに有用であってよい。以下の説明では、この作業履歴は、「評判証明(proof of reputation)」システムと呼ばれてよい。
【0104】
評判証明(proof of reputation)
一態様では、本願は、ブロックチェーン上にマイナー作業履歴を記録する及びマイナー作業履歴を検証する方法及びシステムを提供する。説明されるように、以下の例では、作業履歴は、マイニングノードによりマイニングされるブロック内のリンクされたコインベーストランザクションのチェーンにより記録される。作業履歴は、幾つかの実装では、マイニングノードの評判スコアを決定するために使用されてよい。評判スコアは、例としてマイナー投票動作を含む多数の用途で使用されてよい。
【0105】
後述する実装のうちの幾つかでは、コインベースドキュメントは、各々、情報フィールド内にマイナー識別子を含む。マイナー識別子は、幾つかの実装では、上述の方法及びシステムを用いて確立され検証可能であってよい。しかしながら、幾つかの実装では、他の技術又はシステムが、マイナー識別子を確立するために、及び検証目的で使用されてよい。従って、以下に説明される作業履歴及びproof-of-reputationの例は、必ずしも、全部の実装において上述のマイナー識別子登録処理の使用を必要としない。
【0106】
上述のように、マイナー識別子を登録する1つのメカニズムは、マイナー識別子を、関連するマイニングノードによりマイニングされたブロックのコインベーストランザクションに入れることである。マイナー識別子は、コインベーストランザクション内のOP_RETURNフィールドのような情報フィールドに現れてよい。情報フィールドは、署名又は他のデータを更に含んでよい。上述のように、幾つかの実装では、情報フィールドは、有効性チェックトランザクションへの参照を含んでよい。これは、マイナー識別子が取り消されていない他者による、マイナー識別子の高速取消及び簡易検証を可能にする。
【0107】
コインベーストランザクションは、更に、マイニングノードの作業履歴を記録するために、登録されたマイナー識別子と関連して利用されてよい。図5は、ブロックチェーンにマイナー作業履歴を記録する1つの例示的な方法500を、フローチャートの形式で示す。方法500は、マイナー識別子に関連付けられたマイニングノードにより実行される。マイナー識別子は公開鍵であってよく、マイニングノードは該公開鍵の対応する秘密鍵を保持しており、つまりマイナー識別子はPKIDであってよい。
【0108】
方法500は、動作502で、マイナー識別子を登録するステップを含む。上述のように、登録動作は、マイニングノードによりマイニングされるブロック内の登録コインベーストランザクション内でマイナー識別子を発行することを含む。
【0109】
動作504で、マイニングノードは、新しいブロックをマイニングしようとし続ける。特に、マイニングノードは、新しい候補ブロックを構築し、マイナー識別子を含む情報フィールドを含むコインベーストランザクションを挿入する。コインベーストランザクションの情報フィールドは、同じマイナーによりマイニングされるブロック内の前のコインベーストランザクションへの参照を更に含む。該前のコインベーストランザクションは、最近にマイニングされたブロックであり、コインベーストランザクションはマイナー識別子を含む。第2ブロックがマイニングされる場合、参照は登録コインベーストランザクションへのものである。該マイニングノードからの後にマイニングされるブロックは、最近にマイニングされたブロックのコインベーストランザクションへの参照によりリンクされたコインベーストランザクションを、それらがマイニングされた順序に含む。参照は、例えば、コインベーストランザクションのトランザクション識別子、例えばTxIDであってよい。幾つかの例では、参照は、ノードがブロック内のコインベーストランザクションを識別し得ることに基づき、コインベーストランザクションを含むブロック番号へのものであってよい。幾つかの例では、参照は、TxID及びコインベーストランザクションのアウトプットのうちの1つ、特にOP_RETURNアウトプットを指すインデックスを含む「アウトポイント」であってよい。
【0110】
幾つかの実装では、情報フィールドは追加情報を含む。例えば、情報フィールドは、マイニングノードからの最近マイニングされたブロックからのコインベーストランザクションへの参照に加えて、マイニングノードによりマイニングされた全ての後続のブロックの中の登録コインベーストランザクションへの参照を含んでよい。別の例として、情報フィールドは、マイナー識別子に基づき、つまりマイナー識別子に関連付けられた秘密鍵を用いて生成されたデジタル署名を含んでよい。デジタル署名は、例えば情報フィールドに含まれる参照のものであってよい。
【0111】
動作504で、コインベーストランザクションを有する候補ブロックが生成されると、動作506で、マイニングノードは、該ブロックをマイニングしようとする。動作508で、マイニングノードは、更に、別のマイニングノードからの新しいブロックの通知の受信をモニタする。別のノードが新しいブロックを見付けるのに成功した場合、マイニングノードは、動作510で適用可能なブロックチェーンプロトコルに従い新しいブロックが有効であることを検証し、ブロックチェーンに該新しいブロックを追加する。マイニングノードが、別のノードから新しいブロックの通知を受信する前に、候補ブロックをマイニングすることに成功した場合、動作512で、マイニングノードは、ブロックチェーンネットワーク上の候補ブロックのマイニングの成功を迅速に伝播させ、該新しいブロックをブロックチェーンに追加する。ブロックチェーン上の新しいブロックがマイニングノード又は別のノードに由来するかに拘わらず、新しいブロックが見付かると、マイニングノードは、動作504へ戻り、新しい候補ブロックを構築して再び挑戦する。
【0112】
明らかに、上述のサイクルは、マイニングノードが新しいブロックをマイニングするのに時に成功するならば、最近のブロックから元の登録コインベーストランザクションへと戻る、マイニングノードによりマイニングされたブロックをリンクするリンクされたコインベーストランザクションのチェーンをもたらす。OP_RETURNデータはブロックチェーン上で見えるので、各々がマイナー識別子を含むコインベーストランザクションのリンクされたセットは、マイニングノードの作業履歴の公開記録として直ちに識別可能である。
【0113】
図6を参照すると、ブロックチェーンからのマイナー作業履歴を検証する1つの例示的な方法600示す。方法600は、ノードのブロックチェーンネットワークの一部であるか否かに拘わらず、任意のコンピューティングノードにより実行されてよい。
【0114】
動作602で、コンピューティングノードは、コインベーストランザクションを識別する。この識別は、多数の可能な方法で生じてよい。例えば、マイニングノードは、自身の意図されたアイデンティティ及びコインベーストランザクションのトランザクション識別子を有するコンピューティングノードを提供してよい。トランザクション識別子は、マイニングノードにより生成された最近マイニングされたコインベーストランザクションを指してよい。幾つかの状況では、マイニングノードは、参加、投票、通信する要求と関連して、又はマイニングノードが特にアイデンティティ及び作業履歴の関連する評判を有することの表明(assertion)の部分として、この情報をコンピューティングノードに提供してよい。この表明は、同じ方法により、マイニングノードにより発行されてよく、コンピューティングノードは、評判からの情報にアクセスし及び検索してよい。コンテキスト又はメカニズムに無関係に、コンピューティングノードは、特定のコインベーストランザクションを特定のマイニングノードの意図された作業履歴の部分として識別する情報を取得する。
【0115】
動作604で、コンピューティングノードは、コインベーストランザクションが、情報フィールド内にマイナー識別子を含むかどうかを評価する。多くの状況では、コンピューティングノードは、マイニングノードの意図された識別子を取得しており、動作604は、同じ識別子がコインベーストランザクション内に現れることを確認することを含んでよい。否の場合、コインベーストランザクションは意図されたマイナーアイデンティティについて作業履歴を検証しないので、方法600は失敗する。
【0116】
動作606で、コンピューティングノードは、更に、コインベーストランザクションの情報フィールドが前のコインベーストランザクションへの参照を含むかどうかを決定する。参照は、例えば、TxID番号であってよい。幾つかの例では、参照は、コインベーストランザクションが発見されるべきブロックを識別するブロック数又は高であってよく、或いは前のコインベーストランザクションのアウトポイントであってよい。参照が存在し、前の(低いブロック高の)マイニングされたコインベーストランザクションへのものである場合、動作608で、コンピューティングノードは、該コインベーストランザクションのコピーをブロックチェーンから検索し、動作604に戻り、それがマイナー識別子及び前のコインベーストランザクションを指すことを確認する。この方法では、コンピューティング装置は、マイニングされた順序の中の前のものにリンクされるコインベーストランザクションの情報フィールドの中の参照を用いて、コインベーストランザクションのリンクされたセットを通じて逆にトレースする。
【0117】
動作606で、コインベーストランザクションのうちの1つが前のコインベーストランザクションへの参照を含まない場合、コンピューティングノードは、それが登録コインベーストランザクション、つまりチェーン内の最初であるかどうかを評価する。それらは、登録コインベーストランザクションであるという指示を含み得る、例えば「Action: Registration」又は等価コード又は指示子を含み得る情報フィールドから検証可能であってよい。幾つかの例では、代替又は追加で、それは、チェーン内の全部の他のコインベーストランザクションがそれを登録コインベーストランザクションとして識別することに基づき、検証されてよい。それが登録コインベーストランザクションではない場合、チェーンは壊され、方法600は作業履歴を検証することに失敗する。是である場合、作業履歴は識別され、動作612で、コンピューティングノードは、マイナー識別子を検証することに進んでよい。上述のように、幾つかの実施形態では、これは、有効性チェックトランザクション及び可憐する検証処理を利用することを含んでよい。
【0118】
上述の処理は、一例として、第三者コンピューティングノードが、特定のマイニングノードが特定の作業履歴を有することを検証できるようにする。つまり、コンピューティングノードは、マイニングノードの作業履歴を直ちにトレースでき、これは、マイニングノードに検証可能な評判証明を提供する。有効なブロックを生成する長い履歴を有するマイニングノードは、作業履歴が僅かしか又は全く有しないマイニングノードよりも、信頼でき、重要であり、信頼する価値があり、委任され、又は投資されると考えられる。これに基づき、「proof-of-work」は、どのブロックが有効であるか及びどのマイナーが計算能力へのその投資に対して現在報酬を受けているかを決定するために機能するだけでなく、計算能力に投資するためのマイナー評判及び特定のブロックチェーンを構築するための委任の土台を補強するよう機能する。
【0119】
マイニング処理は、目標採掘難易度閾値より低いブロックヘッダハッシュを探求することを含む。探求は、ヘッダ内のノンス値をインクリメントし、ブロックヘッダをハッシングし、ハッシュ結果が採掘難易度閾値より低い数値をもたらすかどうかを評価し、そうでない場合には、ノンス値をインクリメントして再び挑戦することを含む。採掘難易度閾値は、プロトコルにより設定され、約10分毎にブロックを生じるよう、ブロックチェーンプロトコルに基づき周期的に調整される。調整は、ブロックチェーンネットワークがネットワーク内のハッシュパワー全体の中の変化を考慮するように生じる。ハッシュパワーが追加されると、採掘難易度は、高速過ぎる及び簡単過ぎる生成にならないことを保証するよう変更される。Bitcoin Coreプロトコルでは、例えば、採掘難易度は2016ブロック(約14日間)に調整される。Bitcoin Cash又はBitcoin SVプロトコルでは、採掘難易度は例えば144ブロックに調整される。
【0120】
ブロックヘッダは、フィールド、そのブロックのために使用される現在採掘難易度閾値を指定するnBitsフィールドを含む。採掘難易度閾値は、基数256の科学的表記(base 256 scientific notation)で表現される。したがって、A=aaaaが4バイトの場合、ターゲットTは次のように定義される:
【数6】
【0121】
aの値は、目標が常に2256より小さく維持されることを保証するために、0≦a≦34の範囲内になければならない。
従って、32バイト文字列として表現できる。SHA256関数がランダムオラクルのように振る舞うとすると(つまり、SHA256出力がランダムな256ビット文字列であり、各ビットが他のビットと独立して等しく1又は0である可能性がある)、ブロックヘッダハッシュがトライアルnNonce値について目標を下回る可能性は次の通りである:
【数7】
【0122】
本願の別の態様では、評判スコアは、マイニングノードについて、その検証された作業履歴に基づき決定されてよい。上述のように、作業履歴は、マイニングノードとそのマイナー識別子と該マイニングノードによりマイニングされたブロックのセットとの間の関連付けを証明するリンクされたコインベースドキュメントのチェーンにより表現されてよい。
【0123】
1つの例示的な実装では、マイニングノードの評判スコアは、マイニングしたブロックの数、つまりリンクされたコインベースドキュメントの数に基づき決定される。この例は、ブロックチェーン履歴の中の任意のポイントにある任意のブロックに、それがリンクされたコインベーストランザクションを介してマイニングされたブロックのチェーンの一部を形成するならば、等しく重み付けを提供する。
【0124】
別の例示的な実装では、評判スコアは、マイニングされたブロックの重み付けされた数に基づき決定されてよい。つまり、各ブロックは、それに関連付けられた重みを有してよい。1つの例示的な実装では、重みはブロック高に基づいてよい。例えば、1つの実装は、古いブロックよりも大きな重みを与えることであってよい。別の例では、実装は、より最近のブロックに、より大きな重みを与えることであってよい。
【0125】
別の実装は、ブロックに割り当てられた重みは、ブロック採掘難易度に基づいてよい。つまり、低い採掘難易度閾値を有する、つまり平均でマイニングするためのより大きなハッシュパワーを必要とするブロックは、評判スコアの決定において、より大きな重みを与えられてよい。そのような実装の一例では、評判スコアは、リンクされたコインベースドキュメントのチェーンの中のコインベースドキュメントのうちの1つを含む各ブロックの目標採掘難易度の関数として決定されてよい。
【0126】
例として、マイナー評判スコアがRepIDであり、ブロックiの目標採掘難易度がTiであり、作業履歴の中のブロック数がBである場合、マイナー評判スコアは、以下のように計算されてよい:
【数8】
【0127】
幾つかの例では、評判スコアは、作業履歴全体に基づいてよく、又は最近のブロックの最大数までのウィンドウに基づいてよい、つまり「ローリング」評判スコアである。幾つかの例では、ウィンドウは、ブロックチェーン高、例えば、現在ブロックチェーン高のブロック数Xの範囲内に含まれる作業履歴からの任意のブロックに基づいてよい。
【0128】
幾つかの例示的な実装では現在評判スコアは、マイニングノードにより計算され、各コインベーストランザクションの情報フィールドに含まれてよい。
【0129】
幾つかの例では、評判スコアは、正規化され、例えば、評判スコアを最大評判スコア、例えばブロックチェーン又はウィンドウ内の全部のブロックから生じる評判スコアにより除算してよい。これは、全部の評判スコアが0と1の間であることを保証する。
【0130】
図7を参照すると、マイニングノードの評判スコアを決定する例示的な方法700を示す。例示的な方法700は、マイニングノードにより、別のブロックチェーンノードにより、又はブロックチェーンネットワークの外部のコンピューティングノードにより実行されてよい。
【0131】
動作702で、特定のマイニングノードにういてリンクされたコインベーストランザクションのチェーンは、例えば図6に関して上述したようにトレースされる。コインベーストランザクションをトレースすることから、マイニングノードの作業履歴が識別される。動作704で、コインベーストランザクションのうちの1つを含む各ブロックの採掘難易度閾値が決定される。次に、動作706で、マイニングノードの評判スコアは、採掘難易度閾値のセットに関数を適用することにより決定される。上述のように、これは、採掘難易度閾値(又はそれらの逆数)を加算することを含んでよい。追加又は代替として、重み付けた関数により適用されてよい。結果は、マイニングノードの評判スコアであり、動作708の出力である。
【0132】
評判スコアは、多数のシナリオで使用され得るブロックチェーンへのマイニングノードの貢献の定量化可能な指標である。有利なことに、マイナーアイデンティティ及びその関連付けられた評判スコアを決定し評価する全部のデータは、ブロックチェーンから公衆に利用可能であり、proof-of-workにより裏打ちされたブロックチェーンの不変特性のおかげで検証される。悪意ある振る舞いを防ぐために、マイニングノードの評判スコアは、マイニングブロックを通じてのみ、つまり、ブロックチェーンネットワークの安定性への肯定的貢献を通じて、向上できる。
【0133】
評判スコアは、マイニングノードが自身のマイナー識別子を含め、コインベースドキュメント内の前のブロックにリンクすることにより開発される。コインベースドキュメントの内容は、マイニングノードの制御にありマイニングノードが評判を構築するために第三者検証若しくは証明に依存する必要がないことを意味する。更に、マイニングノードは、評判を偽造又は改ざんできない。
【0134】
関連するマイナー識別子を有するマイニングノードの評判スコアを検証可能に決定する能力は、多数の用途で使用できる。例えば、特定のプロトコル又は活動に参加する資格は、特定の経歴を有するマイナーのみが関与することを許可するために、最小閾値評判スコアを有するマイニングノードに基づき予測されてよい。別の可能な用途は、投票である。特に、基礎にあるブロックチェーンプロトコルに変更が提案されると、マイナーは、投票を提出することを任され、その投票は何らかの方法で重み付けされてよい。1つの選択肢は、評判スコアに基づき投票を重み付けすることである。それにより、マイナーが既存のブロックチェーンを構築するためにより多くの作業を行っていることに基づき、より高い評判スコア有するマイナーにより大きな重みを与える。
【0135】
ブロックチェーンで使用された1つの例示的な投票方式は、マイナーが投票できる時間ウィンドウを開き、次に該時間ウィンドウの間にマイニングされたブロックに基づき投票を勘定することを含む。これは、時間ウィンドウの間に最大ハッシュパワーを有するマイナーに最も多くの投票を提供し、貢献の履歴を考慮しない。これは、「ハッシュ戦争」を生じることがあり、「レンタルハッシュ(rented hash)」に対してシステムを脆弱にする。これは、投票結果を歪曲することに関心のあるマイナーが、ウィンドウ中のブロックチェーンのハッシュパワーを支配するために、膨大な量の計算能力をブロックチェーンに一時的にコミットするが、長期に渡りブロックチェーンにそのような量の計算能力をコミットするリソース又は関心を有しないことである。幾つかの例では、「レンタルハッシュ」は、それがリソースの非経済的な割り当てであるという点で持続可能であるが、投票の結果を強制するために該マイナーにコストを生じる。マイナーは、従って、該マイナーのブロックチェーンへの実際の関与及び投資に比例しない投票への影響力を取得する。
【0136】
一例では、マイナーが投票する処理は、マイニングノードが、彼らがマイナー識別子、例えばPKID及び関連する評判スコアRepIDを登録したならば、参加することを可能にしてよい。投票は、開始時間から終了時間までの(又は開始ブロック高から終了ブロック高までの)合意した時間ウィンドウに渡り生じる。任意の投票についてウィンドウ及びタイミングについての合意を達成するメカニズムは、オンチェーン又はオフチェーンであってよい。
【0137】
投票を投じるために、マイニングノードは、投票ウィンドウの間にブロックをマイニングしなければならない。ブロックの中で、マイナーは、コインベーストランザクション内に、自身のマイナー識別子及び自身の最近のコインベーストランザクションへの参照を挿入する。マイナーは、更に、幾つかの実装では、自身の計算した評判スコアを含めてよい。マイニングノードは、投票信号も含んでよい。投票に依存して、信号は、2進値「はい/いいえ」又は「賛成/反対」であってよく、又は3個以上の選択肢の間の選択のような複数値の信号、3個以上の選択肢のランク付け、等であってよい。幾つかの例では、コインベーストランザクションは、マイナー識別子に対応する秘密鍵に基づき、デジタル署名を更に含んでよい。デジタル署名は、コインベーストランザクション内の情報フィールドの他のコンテンツに渡ってよい。
【0138】
幾つかの実装では、単一のマイナーは、投票ウィンドウの間に複数回投票する資格があってよい。幾つかの他の実装では、マイナーあたり、つまり可憐するマイナー識別子PKIDあたり、1回のみの投票が許可される。後者の場合、マイナーが投票を投じることを意図する1個より多くのブロックをマイニングする場合、どれをカウントすべきかを決定するためにポリシが適用されてよい。例えば、ポリシは、最も早い(最も低いブロック高)の投票を取り入れるものであってよい。代替として、ポリシは、最後の(最も高いブロック高)の投票を取り入れるものであってよく、マイナーがウィンドウ中に彼らの投票を変更することを許容する。
【0139】
任意の投票モニタは、上述のようにマイナー識別子を検証することにより、及び上述のように該マイナー識別子に関連付けられた評判スコアを検証することにより、投票が有効であると検証してよい。署名が投票コインベーストランザクションの部分として要求される場合、それは、別のマイナーが悪意を持ってブロックをマイニングすること及び彼らのPKIDを使用して別のマイナーの投票を投じると称することに対して保護する。投票ウィンドウが終了した後に、全部の情報はブロックチェーンに記録され検証できるので、任意の観察者は、選択肢毎に評判スコアで加重された投票票を加算することにより、結果を決定してよい。
【0140】
現在及び将来のブロックデータではなく、履歴ブロックデータを使用して投票を集計することにより、投票は、比較的短い時間期間に渡り行うことができ、その間、チェーンワークを正確に反映するために、投票重みが十分なproof-of-workデータを用いて計算される。これは、投票重みが一時的なハッシュバーストにより乱されるリスクを有しないで、比較的短い投票期間を可能にする。
【0141】
しかしながら、投票は、新しいブロックをマイニングするためにPKIDを要求するので、マイナーが投票を投じることができるために、十分な時間が与えられなければならない。10分間のブロック時間を想定すると、PKIDを有するマイナーがx%のネットワークハッシュレートを有する場合、t時間のうちに少なくとも1つのブロックをマイニングする可能性は、以下の通りである:
【数9】
【0142】
以下の表1は、種々のx及びtについてPを与える。
【表1】
【0143】
上記の表から、PKIDが1%しかネットワークハッシュレートを有しない場合でも、72時間の投票期間が、彼らが投票ブロックをマイニング可能であることをほぼ保証する。
【0144】
可能なハッシュ戦争シナリオの少なくとも1つの例示的なモデルでは、上述の評判システムは、レンタルハッシュの有効性を低下させることを示すことができる。その結果、攻撃者が14日間にわたりネットワークの75%を支配した場合でも、攻撃者は投票権の23%しか蓄積できない。
【0145】
種々の上述の例示的な方法の上述の動作のうちの一部又は全部は示されたものと異なる順序で実行されてよいこと、及び/又はそれらの方法の全体的な動作を変更することなく同時に実行されてよいことが理解される。
【0146】
図8を参照すると、本願の例に従う、簡易コンピューティング装置800をブロック図の形式で示す。コンピューティング装置800は、上述の機能のうちの1つ以上を実行してよい。コンピューティング装置800は、例えばマイニングノードであってよい。幾つかの実装では、コンピューティング装置800は、例えばマイナー識別子、マイナー作業履歴、マイナー評判スコア、又はマイナー投票ブロック、のようなブロックチェーンに記録されるデータを検証するよう動作する非マイニングノードであってよい。
【0147】
コンピューティング装置800は、1つ以上のマイクロプロセッサ、特定用途向け集積回路(ASIC)、マイクロコントローラ、又は同様のコンピュータ処理装置を含んでよいプロセッサ802を含む。コンピューティング装置800は、値、変数、及び幾つかの例ではプロセッサ実行可能プログラム命令を格納するための永久及び非永久メモリを含んでよいメモリ804と、ネットワークインタフェース806と、を更に含んでよい。
【0148】
コンピューティング装置800は、実行されるとプロセッサ802に本願明細書に記載の機能又は動作のうちの1つ以上を実行させるプロセッサ実行可能命令を含むプロセッサ実行可能アプリケーション808を含んでよい。
【0149】
上述の種々の実施形態は、単なる例であり、本願の範囲を限定することを意味しない。本願の意図された範囲内にある変形のように、ここに記載された種々の技術革新は、当業者に明らかである。特に、上述の例示的な実施形態のうちの1つ以上からの特徴は、以上に明示的に示されない特徴の部分結合を含む代替の例示的な実施形態を生成するために選択されてよい。更に、上述の例示的な実施形態のうちの1つ以上からの特徴は、以上に明示的に示されない特徴の結合を含む代替の例示的な実施形態を生成するために選択され結合されてよい。このような結合及び部分結合に適する特徴は、本願の全体的吟味により当業者に直ちに明らかになるだろう。本願明細書及び請求項に記載された主題は、あらゆる適切な技術的変更をカバーし包含する。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11