知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-07-27
(54)【発明の名称】ブロックチェーン上の合意
(51)【国際特許分類】
H04L 9/32 20060101AFI20230720BHJP
【ＦＩ】
H04L9/32 200Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022577705
(86)(22)【出願日】2021-05-17
(85)【翻訳文提出日】2023-02-15
(86)【国際出願番号】 EP2021062944
(87)【国際公開番号】W WO2021254703
(87)【国際公開日】2021-12-23
(31)【優先権主張番号】2009232.6
(32)【優先日】2020-06-17
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ジャック・オーウェン・デイヴィーズ
(72)【発明者】
【氏名】ダニエル・ジョセフ
(72)【発明者】
【氏名】クレイグ・スティーヴン・ライト
(57)【要約】
要求側と確認側との間の合意をブロックチェーンに記録するコンピュータによって実施される方法であって、要求側によって実行され、要求トランザクションを生成するステップであって、要求トランザクションが、要求側によって署名された入力、および少なくとも、要求側と確認側との両者に知られている第1のデータアイテムに基づく暗号パズルを含む第1の出力を含み、第1のデータアイテムが、合意を表す、ステップと、要求トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法。
【特許請求の範囲】
【請求項1】
要求側と確認側との間の合意をブロックチェーンに記録するコンピュータによって実施される方法であって、前記要求側によって実行され、要求トランザクションを生成するステップであって、
前記要求トランザクションが、前記要求側によって署名された入力、および少なくとも、前記要求側と前記確認側との両者に知られている第1のデータアイテムに基づく暗号パズルを含む第1の出力を含み、
前記第1のデータアイテムが、前記合意を表す、ステップと、
前記要求トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップと
を含む、コンピュータによって実施される方法。
【請求項2】
前記第1のデータアイテムが、前記合意を含むか、または前記第1のデータアイテムが、少なくとも前記合意のハッシュを含む、請求項1に記載の方法。
【請求項3】
前記第1の出力が、前記要求側と前記確認側との両者に知られている第2のデータアイテムに基づく第2の暗号パズルを含み、前記第2のデータアイテムが、前記要求側の識別子を表す、請求項1または請求項2に記載の方法。
【請求項4】
前記要求トランザクションが、1つまたは複数の追加のデータアイテムを含み、前記1つまたは複数の追加のデータアイテムが、前記合意の二重ハッシュ、
前記要求側の識別子の二重ハッシュ、
前記要求トランザクションが前記合意の要求を表すことを示すインジケータ、および
広告トランザクションが前記合意の広告を表すことを示すインジケータを含む前記広告トランザクションへの参照
のうちの1つ、いくつか、またはすべてを含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記要求トランザクションが、前記追加のデータアイテムのうちの1つ、いくつか、またはすべてを含む第2の出力を含む、請求項4に記載の方法。
【請求項6】
前記第1の出力が、返金トランザクションの入力が前記要求側および/または前記確認側に関連するそれぞれの署名を含むことを条件として、前記返金トランザクションの前記入力によってロックを解除されるように構成される、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記第1の出力が、複数署名ロックスクリプトを含む、請求項6に記載の方法。
【請求項8】
返金トランザクションを取得するステップであって、前記返金トランザクションが、前記要求トランザクションの前記第1の出力を参照し、前記要求側および/または前記確認側に関連するそれぞれの署名を含む入力を含み、
前記返金トランザクションが、前記要求側にロックされた出力を含む、ステップと、
前記返金トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップと
を含む、請求項6または請求項7に記載の方法。
【請求項9】
前記返金トランザクションの署名されていないバージョンを生成するステップと、前記返金トランザクションの署名されていないバージョンを前記確認側に送信するステップと
を含む、請求項8に記載の方法。
【請求項10】
前記返金トランザクションを取得する前記ステップが、前記確認側に関連する前記それぞれの署名を含む前記入力を含む前記返金トランザクションのバージョンを受信するステップと、
前記要求側に関連する前記それぞれの署名を用いて前記入力に署名するステップと
を含む、請求項9に記載の方法。
【請求項11】
前記返金トランザクションが、指定された時間が過ぎる前に前記返金トランザクションが前記ブロックチェーン上で公開されることを防止するように構成された時間制限を含む、請求項8から10のいずれか一項に記載の方法。
【請求項12】
前記要求トランザクションの前記第1の出力が、ロックスクリプトに、セパレータオペコード、それに続く前記第1のデータアイテムに基づく前記暗号パズル、それに続く署名チェックオペコードを含む、請求項1から11のいずれか一項に記載の方法。
【請求項13】
前記暗号パズルが、一方向性関数を含む、請求項1から12のいずれか一項に記載の方法。
【請求項14】
前記暗号パズルが、ハッシュパズル、プライベート鍵パズル、またはrパズルのうちの1つを含む、請求項1から13のいずれか一項に記載の方法。
【請求項15】
ブロックチェーンを使用して要求側と確認側との間の合意を記録するコンピュータによって実施される方法であって、前記確認側によって実行され、確認トランザクションを生成するステップであって、
前記確認トランザクションが、要求トランザクションの出力を参照する入力を含み、
前記要求トランザクションの前記出力が、前記要求側と前記確認側との両者に知られており、前記合意を表す第1のデータアイテムに基づく暗号パズルを含み、
前記確認トランザクションの前記入力が、前記第1のデータアイテムを含む、ステップと、
前記確認トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップと
を含む、コンピュータによって実施される方法。
【請求項16】
前記確認トランザクションの前記入力が、前記確認側に関連する署名を含む、請求項15に記載の方法。
【請求項17】
前記要求トランザクションの第1の出力が、ロックスクリプトに、セパレータオペコード、それに続く前記第1のデータアイテムに基づく前記暗号パズル、それに続く署名チェックオペコードを含み、前記確認側に関連する前記署名が、前記セパレータオペコードの後に位置するデータのみに署名するように構成される、請求項16に記載の方法。
【請求項18】
前記要求トランザクションの前記出力が、前記要求側と前記確認側との両者に知られており、前記要求側の識別子を表す第2のデータアイテムに基づく暗号パズルを含み、前記確認トランザクションの前記入力が、前記第2のデータアイテムを含む、請求項16または請求項17に記載の方法。
【請求項19】
前記確認トランザクションが、前記確認側にロックされた出力を含む、請求項15から18のいずれか一項に記載の方法。
【請求項20】
取消トランザクションを生成するステップであって、前記取消トランザクションが、前記確認トランザクションの前記出力のロックを解除するように構成された入力を含む、ステップと、
前記取消トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップと
を含む、請求項19に記載の方法。
【請求項21】
広告トランザクションを生成するステップであって、前記広告トランザクションが、少なくとも、前記確認側によって署名された第1の入力、ならびに少なくとも、前記合意の表現および前記合意の暗号化されたバージョンの一方または両方を含む第1の出力を含む、ステップと、
前記広告トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップと
を含む、請求項15から20のいずれか一項に記載の方法。
【請求項22】
前記合意の前記表現が、前記合意のハッシュを含み、または前記合意の前記表現が、前記合意の二重ハッシュを含む、請求項21に記載の方法。
【請求項23】
前記第1の出力が、前記広告トランザクションが前記合意の広告であることを示すインジケータを含む、請求項21または請求項22に記載の方法。
【請求項24】
前記広告トランザクションが、1つまたは複数の追加の入力を含み、それぞれの追加の入力が、異なる関係者によって署名される、請求項21から23のいずれか一項に記載の方法。
【請求項25】
前記広告トランザクションが、前記確認側にロックされた第2の出力を含む、請求項21から24のいずれか一項に記載の方法。
【請求項26】
更新トランザクションを生成するステップであって、前記更新トランザクションが、前記広告トランザクションの前記第2の出力のロックを解除するように構成された入力、ならびに少なくとも、更新された合意の表現および前記更新された合意の暗号化されたバージョンの一方または両方を含む第1の出力を含む、ステップと、
前記更新トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップと
を含む、請求項25に記載の方法。
【請求項27】
前記合意が、ライセンス契約であり、知的財産に関するライセンス契約を含む、請求項1から26のいずれか一項に記載の方法。
【請求項28】
1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置であって、前記メモリが、前記処理装置上で実行されるように構成されたコードを記憶し、前記コードが、前記処理装置上で実行されると、請求項1から27のいずれか一項に記載の方法を実行するように構成される、処理装置と
を含むコンピュータ機器。
【請求項29】
コンピュータ可読ストレージ上に記憶され、コンピュータ機器上で実行されると、請求項1から27のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、要求側(requesting party)と確認側(confirming party)との間の合意をブロックチェーンに記録する方法に関し、より詳細には、両者による合意への承諾を証明することに関する。
【背景技術】
【0002】
ブロックチェーンは、分散型データ構造の形態を指し、分散型ピアツーピア(P2P)ネットワーク(以下、「ブロックチェーンネットワーク」と呼ばれる)の複数のノードの各々においてブロックチェーンの複製が維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックが、1つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション(coinbase transaction)」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまで、1つまたは複数のブロックに及ぶ可能性があるシーケンス内の先行トランザクションを後ろ向きに指し示す。コインベーストランザクションは、下で検討される。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含められる。新しいブロックは、多くの場合「マイニング」と呼ばれるプロセスによって作成され、マイニングは、複数のノードの各々が「プルーフオブワーク」、すなわち、ブロックチェーンの新しいブロックに含まれるのを待っている順序付けられた承認済みの保留トランザクションの定義されたセットの表現に基づく暗号パズルを解くことを競い合って実行することを含む。ブロックチェーンはノードにおいて刈り込まれる場合があり、ブロックの公開は単なるブロックヘッダの公開によって実現され得ることに留意されたい。
【0003】
ブロックチェーンにおけるトランザクションは、以下、すなわち、デジタル資産(すなわち、多数のデジタルトークン)の伝達、仮想台帳もしくはレジストリのジャーナルエントリ(journal entry)のセットの順序付け、タイムスタンプエントリの受信および処理、ならびに/またはインデックスポインタの時間順序付け(time-order)のうちの1つまたは複数を実行するために使用される。ブロックチェーンは、ブロックチェーンの上にさらなる機能を積み重ねるために利用されることも可能である。ブロックチェーンのプロトコルは、追加のユーザデータまたはトランザクション内のデータへのインデックスの記憶を可能にする場合がある。単一のトランザクションに記憶され得る最大データ容量に対する予め規定された制限はなく、したがって、より一層複雑なデータが組み込まれ得る。たとえば、これは、電子文書をブロックチェーンに記憶するため、またはオーディオもしくはビデオデータを記憶するために使用されてよい。
【0004】
ブロックチェーンネットワークのノード(多くの場合「マイナー」と呼ばれる)は、下で詳細に説明される分散型トランザクション登録および検証プロセスを実行する。要約すると、このプロセス中に、ノードは、トランザクションを承認し、それらが有効なプルーフオブワークの解を特定しようとするブロックテンプレートにトランザクションを挿入する。有効な解が見つかると、新しいブロックが、ネットワークのその他のノードに伝播され、したがって、各ノードがブロックチェーンに新しいブロックを記録することを可能にする。ブロックチェーンにトランザクションを記録させるために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)は、伝播されるようにネットワークのノードのうちの1つにトランザクションを送信する。トランザクションを受信するノードは、承認されたトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけるために競争してよい。各ノードは、トランザクションが有効であるための1つまたは複数の条件を含む同じノードプロトコルを施行するように構成される。無効なトランザクションは伝播されず、ブロックに組み込まれることもない。トランザクションが承認され、それによってブロックチェーンに受け入れられると仮定すると、トランザクション(任意のユーザデータを含む)は、したがって、不変の公的記録としてブロックチェーンネットワークのノードの各々に登録され、インデックス付けされたままとなる。
【0005】
プルーフオブワークのパズルを解いて最新のブロックを作ることに成功したノードは、概して、ある額のデジタル資産、すなわち、いくつかのトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションによって報酬を与えられる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして働く競い合うノードのアクションによって施行され、不正行為を報告し、ブロックするようにインセンティブを与えられる。情報の広範な公開は、ユーザがノードの性能を継続的に監査することを可能にする。単なるブロックヘッダの公開は、参加者がブロックチェーンの継続している完全性を保証することを可能にする。
【0006】
「出力ベース」のモデル(UTXOベースのモデルと呼ばれることもある)において、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を含む。すべての消費可能な出力は、トランザクションの進行中のシーケンスから導出可能なデジタル資産の額を指定する要素を含む。消費可能な出力は、UTXO(「未使用トランザクション出力(unspent transaction output)」)と呼ばれることもある。出力は、出力の将来の履行(redemption)の条件を指定するロックスクリプトをさらに含んでよい。ロックスクリプトは、デジタルトークン資産を承認し、送金するために必要な条件を定義するプレディケート(predicate)である。(コインベーストランザクション以外の)トランザクションの各入力は、先行トランザクションのそのような出力へのポインタ(すなわち、参照)を含み、指し示される出力のロックスクリプトを解除するためのロック解除スクリプトをさらに含んでよい。そこで、一対のトランザクションを考え、それらを第1のトランザクションおよび第2のトランザクション(または「目標」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定する少なくとも1つの出力を含み、出力のロックを解除する1つまたは複数の条件を定義するロックスクリプトを含む。第2の、目標トランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力のロックを解除するためのロック解除スクリプトとを含む少なくとも1つの入力を含む。
【0007】
そのようなモデルにおいては、第2の、目標トランザクションがブロックチェーン内で伝播され、記録されるようにブロックチェーンネットワークに送信されるとき、各ノードで適用される有効性の基準のうちの1つは、ロック解除スクリプトが第1のトランザクションのロックスクリプトにおいて定義された1つまたは複数の条件のすべてを満たすことである。別の基準は、第1のトランザクションの出力が、別の以前の有効なトランザクションによって既に履行されていないことである。これらの条件のいずれかに従って目標トランザクションが無効であることが分かったすべてのノードは、そのトランザクションを伝播せず(有効なトランザクションとしては、ただし、場合によっては無効なトランザクションを登録するために伝播する)、そのトランザクションをブロックチェーンに記録されるように新しいブロックに含めることもない。
【0008】
代替的な種類のトランザクションモデルは、アカウントベースのモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のノードによって記憶され、絶えず更新される。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】PCT/IB2020/053807
【特許文献2】WO2020065460
【非特許文献】
【0010】
【非特許文献1】https://wiki.bitcoinsv.io/index.php/OP_CHECKSIG
【非特許文献2】https://wiki.bitcoinsv.io/index.php/OP_CODESEPARATOR
【発明の概要】
【課題を解決するための手段】
【0011】
ブロックチェーンは、二者間の合意(たとえば、法的契約)を記録するために使用され得る。たとえば、合意は、トランザクションに含められてよく、トランザクションは、ブロックチェーンネットワークに提出されるとき、ブロックチェーン上で公開される。これは有用であるが、両者が合意についての両者の明示的な承諾または承認を与えたことを証拠立てることができることが有益である。この「承諾の証明(proof of consent)」は、契約の執行、紛争の解決などのために合意の両方の関係者によって使用されてよい。
【0012】
本明細書において開示される1つの態様によれば、要求側と確認側との間の合意をブロックチェーンに記録するコンピュータによって実施される方法であって、要求側によって実行され、要求トランザクションを生成するステップであって、要求トランザクションが、要求側によって署名された入力、および少なくとも、要求側と確認側との両者に知られている第1のデータアイテムに基づく暗号パズルを含む第1の出力を含み、第1のデータアイテムが、合意を表す、ステップと、要求トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法が提供される。
【0013】
本明細書において開示される1つの態様によれば、ブロックチェーンを使用して要求側と確認側との間の合意を記録するコンピュータによって実施される方法であって、確認側によって実行され、確認トランザクションを生成するステップであって、確認トランザクションが、要求トランザクションの出力を参照する入力を含み、要求トランザクションの出力が、要求側と確認側との両者に知られており、合意を表す第1のデータアイテムに基づく暗号パズルを含み、確認トランザクションの入力が、第1のデータアイテムを含む、ステップと、確認トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法が提供される。
【0014】
要求側(たとえば、Alice)は、解かれるために、Aliceが確認側(たとえば、Bob)との間で結びたい合意の知識を必要とする暗号パズルを設定する。すなわち、Aliceによってブロックチェーンネットワークに提出された要求トランザクションは、暗号パズルを含む出力を含む。出力がロックを解除されるためには、出力を参照するBobのトランザクションの入力が、暗号パズルの解を含まなければならない。例として、暗号パズルは、Bobが合意のハッシュを提供すること、または代替的な例として、合意自体を提供すること要求するハッシュパズルであってよい。
【0015】
合意を受け入れるために、Bobは、暗号パズルの解を含む入力を含む確認トランザクションを生成する。暗号パズルの性質が原因で、Aliceのパズルは、一意の解、たとえば、合意または合意のハッシュによってのみロックを解除される。したがって、一意の解を提供することによって、Bobは、合意に自分の承諾を与える。一方で、AliceおよびBobが実際には(たとえば、異なる条項または条件を有する)異なる合意を結びたがっているとすると、Bobの解は、Aliceのパズルのロックを解除しないであろう。これは、AliceとBobとの両方に、要求された合意が確認されていないことを警告する。
【0016】
本発明の特定のユースケースは、ライセンス契約、たとえば、知的財産(IP)のライセンス付与の分野である。Bobは、IPの所有者である可能性があり、Aliceは、IPのライセンスを付与したい可能性がある。Aliceは、ブロックチェーンネットワークに要求トランザクションを提出することによってIPのライセンスを要求することができる。要求トランザクションは、IPのライセンス契約(LA)に基づく暗号パズルを含み、たとえば、ハッシュパズルが、LAの二重ハッシュを含んでよい。Bobは、LAの条項の下でAliceにIPのライセンスを付与することに同意する場合、暗号パズルの解、たとえば、LAのハッシュを含む確認トランザクションをブロックチェーンネットワークに提出する。要求および確認トランザクションのブロックチェーン上での公開は、両者によるLAへの相互の承諾の不変の記録として働く。
【0017】
ライセンシーが要求トランザクションを生成し、ライセンサーが確認トランザクションを生成するという観点で説明されたが、役割が逆にされる可能性も排除されないことに留意されたい。すなわち、ライセンサーが、LAの申し出として働く要求トランザクションを生成してよく、ライセンシーが、LAの受け入れとして働く確認トランザクションを生成してよい。
【0018】
本開示の実施形態の理解を助け、そのような実施形態がどのようにして実施されてよいかを示すために、添付の図面が、例としてのみ参照される。
【図面の簡単な説明】
【0019】
【図1】ブロックチェーンを実装するためのシステムの概略的なブロック図である。
【図2】ブロックチェーンに記録されてよいトランザクションのいくつかの例を概略的に示す図である。
【図3A】クライアントアプリケーションの概略的なブロック図である。
【図4】本発明の実施形態を実施するためのシステムの概略的なブロック図である。
【図5】本発明の一部の実施形態を実施するためのトランザクションの例示的なフローを概略的に示す図である。
【図6】例示的な広告(advertisement)トランザクションを概略的に示す図である。
【図7】例示的な要求トランザクションを概略的に示す図である。
【図8】例示的な確認トランザクションを概略的に示す図である。
【図9】例示的な更新トランザクションを概略的に示す図である。
【図10】例示的な返金(refund)トランザクションを概略的に示す図である。
【図11】本発明の一部の実施形態を実施するための例示的なシーケンス図である。
【発明を実施するための形態】
【0020】
例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。
【0021】
各ブロックチェーンノード104は、ピアのコンピュータ機器を含み、ノード104のうちの異なるノードは、異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などのその他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをも含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。
【0022】
ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク106の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。そうではなく、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(下で検討される)を記憶する限り、ブロックチェーン150は、データを刈り込まれる場合がある。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルの種類に依存する。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを使用する。1つのよくある種類のトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、財産としてのデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされるユーザ103である(ロックを解除され、それによって、履行または消費されるためにはそのユーザの署名またはその他の解決策を必要とする)。各入力は、先行トランザクション152の出力を後ろ向きに指し示し、それによって、トランザクションをリンクする。
【0023】
各ブロック151は、ブロック151までの連続的な順序を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。(コインベーストランザクション以外)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153までさかのぼる。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。
【0024】
ブロックチェーンノード104の各々は、トランザクション152をその他のブロックチェーンノード104に転送し、それによって、トランザクション152をネットワーク106全体に伝播させるように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれらのブロックチェーンノード104のそれぞれのメモリに記憶するように構成される。また、各ブロックチェーンノード104は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられたセット154を維持する。順序付けられたセット154は、多くの場合「メムプール(mempool)」と呼ばれる。本明細書におけるこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルにも限定するように意図されていない。この用語は、ノード104が有効であるものとして受け入れ、ノード104が同じ出力を消費しようとするいかなるその他のトランザクションも受け入れないことを義務付けられるトランザクションの順序付けられたセットを指す。
【0025】
所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことを指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない(孤児(orphan)トランザクションに関する下の議論を参照されたい)。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。
【0026】
現在のトランザクション152jの入力は、入力の認可、たとえば、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。そして今度は、現在のトランザクション152jの出力が、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行トランザクション152iの入力で定義された額を、現在のトランザクション152jの出力で定義されたように新しいユーザまたはエンティティ103bに送金することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、お釣りを渡すために元のユーザまたはエンティティ103aである可能性がある)の間で入力額を分けるために複数の出力を有する場合がある。場合によっては、トランザクションは、1つまたは複数の先行トランザクションの複数の出力からの金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することも可能である。
【0027】
ビットコインのような出力ベースのトランザクションプロトコルによれば、ユーザまたはマシンなどのエンティティ103が新しいトランザクション152jを定めたいとき、エンティティは、そのコンピュータ端末102から受取人に新しいトランザクションを送信する。エンティティまたは受取人は、最終的に、このトランザクションを(現在では概してサーバまたはデータセンターであるが、原理的にはその他のユーザ端末である可能性がある)ネットワーク106のブロックチェーンノード104のうちの1つまたは複数に送信する。また、新しいトランザクション152jを定めるエンティティ103が、トランザクションをブロックチェーンノード104のうちの1つまたは複数に送信し、一部の例においては、受取人に送信しない可能性があることも除外されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、概して、新しいトランザクション152jの暗号署名が、トランザクション152の順序付けられたシーケンス内の前のトランザクション152iに依存する期待される署名と一致することをブロックチェーンノード104がチェックすることを要求する。そのような出力ベースのトランザクションプロトコルにおいて、これは、新しいトランザクション152jの入力に含まれるエンティティ103の暗号署名またはその他の認可が、新しいトランザクションが割り振る先行トランザクション152iの出力で定義された条件と一致することをチェックすることを含む場合があり、この条件は、概して、少なくとも、新しいトランザクション152jの入力の暗号署名またはその他の認可が、新しいトランザクションの入力がリンクされる前のトランザクション152iの出力のロックを解除することをチェックすることを含む。条件は、先行トランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義されてよい。代替的に、条件は、単にブロックチェーンノードプロトコルのみによって決められている可能性があり、またはこれらの組合せによる可能性がある。いずれにせよ、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106の1つまたは複数のその他のブロックチェーンノード104に転送する。これらのその他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用し、したがって、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送し、以下同様である。このようにして、新しいトランザクションは、ブロックチェーンノード104のネットワーク全体に伝播される。
【0028】
出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り振られるかどうかの定義は、その出力がブロックチェーンノードプロトコルに従って別のオンワードトランザクション(onward transaction)152jの入力によって既に有効に履行されたかどうかということである。トランザクションが有効であるための別の条件は、それが割り振ろうとまたは履行しようと試みる先行トランザクション152iの出力が別のトランザクションによって既に割り振られて/履行されていないことである。やはり、有効でない場合、トランザクション152jは(警告のために無効であるものとしてフラグを立てられ、伝播されるのでない限り)伝播されず、ブロックチェーン150に記録されない。これは、トランザクションを行う者が同じトランザクションの出力を2回以上割り振ろうとする二重支払いを防ぐ。一方、アカウントベースのモデルは、アカウントの残高を維持することによって二重支払いを防止する。やはり、トランザクションの定義された順序が存在するので、アカウントの残高は、常に単一の定義された状態を有する。
【0029】
トランザクションを承認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうとさらに競争する。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたセット154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスがトランザクションの順序付けられたセット154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他のパズルは除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード104において相当大量の処理リソースを消費する。
【0030】
パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークのその他のブロックチェーンノード104によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード104は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード104の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード104の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に承認されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク106のブロックチェーンノード104の各々において認識され、維持されるので、修正され得ない。また、ブロックポインタ155は、ブロック151に連続的な順序を付与する。トランザクション152がネットワーク106の各ブロックチェーンノード104の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。
【0031】
任意の所与の時間にパズルを解こうと競争している異なるブロックチェーンノード104は、それらのブロックチェーンノード104がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションの順序付けられたセット154の異なるスナップショットに基づいてそうしている場合があることに留意されたい。最初にそれらのそれぞれのパズルを解いた者は誰でも、どのトランザクション152が次の新しいブロック151nにどの順番で含まれるかを定義し、未公開のトランザクションの現在のセット154が、更新される。それから、ブロックチェーンノード104は、未公開のトランザクションの新たに定義された未処理の順序付けられたセット154からブロックを作成しようと競争を続け、以下同様である。発生する可能性があるすべての「フォーク(fork)」を解決するためのプロトコルも存在し、フォークは、ブロックチェーンの相反するビュー(view)がノード104の間で伝播されるように、2つのブロックチェーンノード104が互いに非常に短い時間内にそれらのブロックチェーンノード104のパズルを解く地点である。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最終的なブロックチェーン150となる。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであることに留意されたい。
【0032】
ビットコインブロックチェーン(およびほとんどのその他のブロックチェーン)によれば、新しいブロック104を成功裏に構築するノードは、(ある額のデジタル資産をあるエージェントまたはユーザから別のエージェントまたはユーザに送金するエージェント間またはユーザ間トランザクションとは対照的に)定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて認められた額のデジタル資産を割り振る能力を付与される。この特別な種類のトランザクションは、通常「コインベーストランザクション」と呼ばれるが、「イニシエーション(initiation)トランザクション」と呼ばれる場合もある。この特別な種類のトランザクションは、概して、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクショが後で履行されることを可能にするプロトコルの規則に従うという、新しいブロックを構築するノードの意図を知らせる。ブロックチェーンプロトコルの規則は、この特別なトランザクションが履行される前に、満期期間(maturity period)、たとえば、100ブロックを必要とする場合がある。多くの場合、通常の(非生成(non-generation))トランザクション152は、トランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加の取引手数料も指定する。この手数料は、通常「取引手数料」と呼ばれ、下で検討される。
【0033】
トランザクションの承認および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード104の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード104は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。
【0034】
各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそのそれぞれの1つの役割または複数の役割を実行し、トランザクション152を処理するために、ブロックチェーンノード104の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード104に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行されてよいことが理解されるであろう。ノードソフトウェアは、アプリケーションレイヤの1つもしくは複数のアプリケーションに、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより下位のレイヤに、またはこれらの任意の組合せで実装されてよい。
【0035】
ネットワーク101にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワークとインタラクションする場合があるが、トランザクションおよびブロックの承認、構築、または伝播には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合がある。その他のユーザは、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。
【0036】
関係者103の一部またはすべては、異なるネットワーク、たとえば、ブロックチェーンネットワーク106の上に重ねられたネットワークの一部として接続される場合がある。ブロックチェーンネットワークのユーザ(多くの場合「クライアント」と呼ばれる)は、ブロックチェーンネットワークを含むシステムの一部であると言われる場合があるが、これらのユーザは、ブロックチェーンノードに必要とされる役割を果たさないので、ブロックチェーンノード104ではない。その代わりに、各関係者103は、ブロックチェーンネットワーク106とインタラクションし、それによって、ブロックチェーンノード106に接続すること(すなわち、通信すること)によりブロックチェーン150を利用してよい。例示を目的として、2人の関係者103およびそれらのそれぞれの機器102、すなわち、第1の関係者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の関係者103bおよびそのそれぞれのコンピュータ機器102bが示される。多くのさらなるそのような関係者103およびそれらのそれぞれのコンピュータ機器102が存在し、システム100に参加していてよいが、便宜上、それらは図示されていないことは理解されるであろう。各関係者103は、個人または組織である場合がある。純粋に例示のために、第1の関係者103aは、本明細書においてはAliceと呼ばれ、第2の関係者103bは、Bobと呼ばれるが、これは限定的でなく、AliceまたはBobに対する本明細書のすべての言及は、それぞれ「第1の関係者」および「第2の関係者」によって置き換えられてよいことが理解されるであろう。
【0037】
各関係者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえば、1つまたは複数のCPU、GPU、その他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを含むそれぞれの処理装置を含む。各関係者103のコンピュータ機器102は、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに含む。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。各関係者103のコンピュータ機器102のメモリは、処理装置上で実行されるように配置された少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の関係者103に帰せられるすべてのアクションは、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実行されてよいことが理解されるであろう。各関係者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の関係者103のコンピュータ機器102は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの1つまたは複数のその他のネットワーク化されたリソースも含む場合がある。
【0038】
クライアントアプリケーション105は、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103のコンピュータ機器102に提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。
【0039】
クライアントアプリケーション105は、少なくとも「ウォレット」機能を含む。これは、2つの主な機能を有する。これらのうちの一方は、それぞれの関係者103が、トランザクション152を作成し、承認し(たとえば、署名し)、その後ブロックチェーンノード104のネットワーク全体に伝播され、それによって、ブロックチェーン150に含められるように1つまたは複数のビットコインノード104に送信することを可能にすることである。他方は、それぞれの関係者が現在所有しているデジタル資産の額の報告をその関係者に返すことである。出力ベースのシステムにおいて、この第2の機能は、問題にしている関係者に属する、ブロックチェーン150全体に散在する様々なトランザクション152の出力に定義された額を照合することを含む。
【0040】
注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIによってインターフェースをとる、または1つがそれ以外に対するプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。
【0041】
各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能なように結合される。これは、クライアント105のウォレット機能がネットワーク106にトランザクション152を送信することを可能にする。また、クライアント105は、それぞれの関係者103が受信者である任意のトランザクションに関してブロックチェーン150に問い合わせる(または実施形態において、ブロックチェーン150は、その公開された可視性(public visibility)によって部分的にトランザクションに対する信頼を提供する公共機関(public facility)であるので、ブロックチェーン150内のその他の関係者のトランザクションを確かに検査する)ためにブロックチェーンノード104に連絡することができる。各コンピュータ機器102のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を組み立て、送信するように構成される。上述のように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を承認し、ブロックチェーンネットワーク106全体にトランザクション152を伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは、互いに対応し、所与のトランザクションプロトコルが、所与のノードプロトコルと一緒になって、所与のトランザクションモデルを実装する。ブロックチェーン150のすべてのトランザクション152のために、同じトランザクションプロトコルが使用される。ネットワーク106のすべてのノード104によって同じノードプロトコルが使用される。
【0042】
所与の関係者103、たとえば、Aliceが、ブロックチェーン150に含められるように新しいトランザクション152jを送信したいとき、その関係者103は、(その関係者103のクライアントアプリケーション105のウォレット機能を使用して)関連するトランザクションプロトコルに従って新しいトランザクションを組み立てる。そして、その関係者103は、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最良に接続されているブロックチェーンノード104である可能性がある。任意の所与のブロックチェーンノード104は、新しいトランザクション152jを受信するとき、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってその新しいトランザクション152jを処理する。これは、新しく受信されたトランザクション152jが「有効」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例は、まもなくより詳細に検討される。一部のトランザクションプロトコルにおいて、承認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能である場合がある。代替的に、条件は、単にノードプロトコルの組み込まれた特徴であるか、またはスクリプトとノードプロトコルとの組合せによって定義される可能性がある。
【0043】
新たに受信されたトランザクション152jが有効とみなされるためのテストに合格することを条件に(すなわち、新たに受信されたトランザクション152jが「承認される」ことを条件に)、トランザクション152jを受信するすべてのブロックチェーンノード104は、そのブロックチェーンノード104において維持されるトランザクション154の順序付けられたセットに、新しい承認されたトランザクション152を追加する。さらに、トランザクション152jを受信するすべてのブロックチェーンノード104は、承認されたトランザクション152をネットワーク106の1つまたは複数のその他のブロックチェーンノード104に向かって伝播させる。各ブロックチェーンノード104が同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、トランザクション152jがネットワーク106全体にすぐに伝播されることを意味する。
【0044】
所与のブロックチェーンノード104において維持されるトランザクションの順序付けられたセット154に入れられると、そのブロックチェーンノード104は、新しいトランザクション152を含むトランザクションのそれらのそれぞれの順序付けられたセット154の最新バージョンに関するプルーフオブワークのパズルを解く競い合いを開始する(その他のブロックチェーンノード104はトランザクションの異なる順序付けられたセット154に基づくパズルを解こうとしている可能性があるが、誰であれ最初に成功する者が最新のブロック151に含まれるトランザクションの順序付けられたセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたセット154の一部に関するパズルを解く)。新しいトランザクション152jを含む順序付けられたセット154に関してプルーフオブワークが行われると、順序付けられたセット154は、変更不可能であるようにしてブロックチェーン150のブロック151のうちの1つの一部となる。各トランザクション152は、それ以前のトランザクションに戻るポインタを含み、したがって、トランザクションの順序も変更不可能であるようにして記録される。
【0045】
異なるブロックチェーンノード104は、最初に、所与のトランザクションの異なるインスタンスを受信し、したがって、1つのインスタンスが新しいブロック151で公開される前は、どのインスタンスが「有効」であるかについての相反するビューを有する可能性があり、1つのインスタンスが新しいブロック151で公開された時点で、すべてのブロックチェーンノード104は、公開されたインスタンスが唯一の有効なインスタンスであると合意する。ブロックチェーンノード104が1つのインスタンスを有効であるものとして受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されたことを発見する場合、そのブロックチェーンノード104は、これを受け入れなければならず、そのブロックチェーンノード104が最初に受け入れたインスタンス(すなわち、ブロック151で公開されなかったインスタンス)を破棄する(すなわち、無効であるものとして扱う)。
【0046】
一部のブロックチェーンネットワークによって運用される代替的な種類のトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」のプロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムにおいて、トランザクションは、アカウントの実行中の取引勘定(running transaction tally)(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、送信者によって送信者の暗号署名の一部として署名され、トランザクション参照計算(transaction reference calculation)の一部としてハッシュされる。さらに、オプションのデータフィールドが、トランザクションに署名される場合もある。このデータフィールドは、たとえば、前のトランザクションIDがデータフィールドに含まれる場合、前のトランザクションを後ろ向きに指し示す場合がある。
【0047】
UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は、1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、すべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルは、ビットコインに関連して説明されるが、その他の例示的なブロックチェーンネットワークに同様に実装されてよいことに留意されたい。
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は、1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、すべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルは、ビットコインに関連して説明されるが、その他の例示的なブロックチェーンネットワークに同様に実装されてよいことに留意されたい。
【0048】
UTXOベースのモデルにおいて、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を含むデータ構造を含む。各出力203は、未使用トランザクション出力(UTXO)を含んでよく、UTXOは、(UTXOが既に履行されていない場合)別の新しいトランザクションの入力202のソースとして使用され得る。UTXOは、デジタル資産の額を指定する値を含む。これは、分散台帳上のトークンの設定された数を表す。UTXOは、情報の中でもとりわけ、そのUTXOが由来するトランザクションのトランザクションIDも含んでよい。トランザクションデータ構造は、入力フィールド202および出力フィールド203のサイズのインジケータを含む場合があるヘッダ201も含んでよい。ヘッダ201は、トランザクションのIDも含んでよい。実施形態において、トランザクションIDは、(トランザクションID自体を除く)トランザクションデータのハッシュであり、ノード104に提出される生のトランザクション152のヘッダ201に記憶される。
【0049】
Alice103aが、問題にしているデジタル資産の額をBob103bに送金するトランザクション152jを作成したいものとする。図2において、Aliceの新しいトランザクション152jは、「Tx1」とラベル付けされている。トランザクション152jは、シーケンス内の先行トランザクション152iの出力203においてAliceにロックされているデジタル資産の額を取得し、このうちの少なくとも一部をBobに送金する。先行トランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、任意のラベルであるに過ぎない。それらは、必ずしも、Tx0がブロックチェーン151の最初のトランザクションであることも、Tx1がプール154内のすぐ次のトランザクションであることも意味しない。Tx1は、Aliceにロックされた未使用の出力203をまだ持っている任意の先行する(すなわち、先祖)トランザクションを後ろ向きに指し示す可能性がある。
【0050】
先行トランザクションTx0は、Aliceが自身の新しいトランザクションTx1を作成するときに、または少なくともAliceがその新しいトランザクションTx1をネットワーク106に送信するまでに、既に承認され、ブロックチェーン150のブロック151に含められている可能性がある。先行トランザクションTx0は、そのとき、既にブロック151のうちの1つに含められている可能性があり、または順序付けられたセット154内でまだ待っている可能性があり、その場合は、先行トランザクションTx0は、すぐに新しいブロック151に含められる。代替的に、Tx0およびTx1は、一緒に作成され、ネットワーク106に送信される可能性があり、またはノードプロトコルが「孤児」トランザクションをバッファリングすることを許す場合、Tx0がTx1の後に送信される可能性さえある。本明細書においてトランザクションのシーケンスの文脈で使用される用語「先行」および「後続」は、トランザクションにおいて指定されたトランザクションポインタによって定義されるシーケンス内のトランザクションの順序(どのトランザクションがどのその他のトランザクションを後ろ向きに指し示すかなど)を指す。それらの用語は、「先任者」および「後任者」、または「先祖」および「子孫」、「親」および「子」などによって等しく置き換えられる可能性がある。それは、必ずしも、それらのトランザクションが作成される、ネットワーク106に送信される、または任意の所与のブロックチェーンノード104に到着する順序を示唆しない。しかしながら、先行トランザクション(先祖トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまで、また承認されない限り、承認されない。その親の前にブロックチェーンノード104に到着する子は、孤児とみなされる。その子は、ノードプロトコルおよび/またはノードの挙動に応じて、廃棄されるか、または親を待つために特定の時間バッファリングされる場合がある。
【0051】
先行トランザクションTx0の1つまたは複数の出力203のうちの1つは、ここではUTXO0とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが承認され、したがって、UTXOが成功裏に履行されるために後続のトランザクションの入力202内のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。概して、ロックスクリプトは、額を特定の関係者(そのロックスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、概して、後続のトランザクションの入力のロック解除スクリプトが先行トランザクションがロックされている関係者の暗号署名を含むという条件を含むロック解除条件を定義する。
【0052】
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で記述されたコード片である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、どの情報がトランザクション出力203を消費するために必要とされるか、たとえば、Aliceの署名の必要を指定する。ロック解除スクリプトは、トランザクションの出力に現れる。ロック解除スクリプト(別名scriptSig)は、ロックスクリプトの基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で記述されたコード片である。たとえば、ロック解除スクリプトは、Bobの署名を含む場合がある。ロック解除スクリプトは、トランザクションの入力202に現れる。
【0053】
したがって、図示された例において、Tx0の出力203のUTXO0は、UTXO0が履行されるために(厳密には、UTXO0を履行しようと試みる後続のトランザクションが有効であるために)Aliceの署名Sig PAを必要とするロックスクリプト[Checksig PA]を含む。[Checksig PA]は、Aliceの公開-プライベート鍵のペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、(たとえば、実施形態においてはトランザクションTx0全体のハッシュであるTx0トランザクションID、TxID0によって、)Tx0を後ろ向きに指し示すポインタを含む。Tx1の入力202は、Tx0の任意のその他の可能な出力の中でUTXO0を特定するために、Tx0内のUTXO0を特定するインデックスを含む。Tx1の入力202は、さらに、Aliceが鍵ペアからの自身のプライベート鍵をデータの予め定義された部分(暗号技術においては「メッセージ」と呼ばれることがある)に適用することによって作成されたAliceの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにAliceによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義される場合がある。
【0054】
新しいトランザクションTx1がブロックチェーンノード104に到着するとき、ノードは、ノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトにおいて定義された条件(この条件は1つまたは複数の基準を含む場合がある)を満たすかどうかをチェックすることを含む。実施形態において、これは、2つのスクリプトを連結すること、すなわち、
<Sig PA> <PA> || [Checksig PA]
を含み、「||」は、連結を表し、「<...>」は、スタックにデータを置くことを意味し、「[...]」は、ロックスクリプト(この例においては、スタックベースの言語)によって含まれる関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順々に実行されてよい。いずれにせよ、一緒に実行されるとき、スクリプトは、Tx0の出力のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx1の入力のロック解除スクリプトがデータの期待される部分に署名するAliceの署名を含むことを認証する。データの期待される部分自体(「メッセージ」)も、この認証を実行するために含められる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、平文のデータの署名された部分を指定する別個の要素は、それが既に本質的に存在するので含められる必要がない)。
<Sig PA> <PA> || [Checksig PA]
を含み、「||」は、連結を表し、「<...>」は、スタックにデータを置くことを意味し、「[...]」は、ロックスクリプト(この例においては、スタックベースの言語)によって含まれる関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順々に実行されてよい。いずれにせよ、一緒に実行されるとき、スクリプトは、Tx0の出力のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx1の入力のロック解除スクリプトがデータの期待される部分に署名するAliceの署名を含むことを認証する。データの期待される部分自体(「メッセージ」)も、この認証を実行するために含められる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、平文のデータの署名された部分を指定する別個の要素は、それが既に本質的に存在するので含められる必要がない)。
【0055】
公開-プライベート暗号技術による認証の詳細は、当業者によく知られているであろう。基本的に、Aliceが自身のプライベート鍵を使用してメッセージに署名した場合、Aliceの公開鍵および平文のメッセージがあれば、ノード104などの別のエンティティは、そのメッセージがAliceによって署名されたに違いないことを認証することができる。署名は、通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって、公開鍵のすべての保有者が署名を認証することを可能にする。したがって、特定のデータまたはトランザクションの一部などに署名することへの本明細書におけるすべての言及は、実施形態においては、そのデータまたはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
【0056】
Tx1のロック解除スクリプトがTx0のロックスクリプトにおいて指定された1つまたは複数の条件を満たす場合(したがって、図示された例では、Aliceの署名がTx1において提供され、認証される場合)、ブロックチェーンノード104、はTx1を有効とみなす。これは、ブロックチェーンノード104が、Tx1をトランザクションの順序付けられたセット154に追加することを意味する。また、ブロックチェーンノード104は、トランザクションTx1がネットワーク106全体に伝播されるように、ネットワーク106の1つまたは複数のその他のブロックチェーンノード104にトランザクションTx1を転送する。Tx1が承認され、ブロックチェーン150に含められると、これは、Tx0からのUTXO0を使用済みとして定義する。Tx1は、未使用トランザクション出力203を消費する場合にのみ有効であり得ることに留意されたい。Tx1が別のトランザクション152によって既に消費された出力を消費しようと試みる場合、Tx1は、たとえすべてのその他の条件が満たされるとしても無効となる。したがって、ブロックチェーンノード104は、先行トランザクションTx0の参照されたUTXOが既に消費されているかどうか(すなわち、そのUTXOが別の有効なトランザクションへの有効な入力を既に形成したかどうか)をチェックする必要もある。これは、ブロックチェーン150がトランザクション152に定義された順序を付与することが重要である理由の1つである。実際には、所与のブロックチェーンノード104は、どのトランザクション152のどのUTXO203が消費されたかを示す別個のデータベースを維持する場合があるが、結局、UTXOが消費されたかどうかを定義するのは、それがブロックチェーン150内の別の有効なトランザクションへの有効な入力を既に形成したかどうかということである。
【0057】
所与のトランザクション152のすべての出力203において指定された総額が、そのトランザクション152のすべての入力202によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効の別の根拠となる。したがって、そのようなトランザクションは、伝播されず、ブロック151に含められることもない。
【0058】
UTXOベースのトランザクションモデルにおいて、所与のUTXOは、丸ごと使用される必要があることに留意されたい。所与のUTXOは、UTXOにおいて使用済みとして定義された額の一部分を「残しておく」ことができない一方で、別の部分が消費される。ただし、UTXOからの額は、次のトランザクションの複数の出力の間で分けられ得る。たとえば、Tx0のUTXO0において定義された額が、Tx1の複数のUTXOの間で分けられ得る。したがって、Aliceは、BobにUTXO0において定義された額のすべてを与えたくない場合、残りを使ってTx1の第2の出力において自分自身にお釣りを与えるかまたは別の関係者に支払いをすることができる。
【0059】
実際には、Aliceは、通常さらに、自分のトランザクション104を公開するビットコインノードへの手数料も含める必要がある。Aliceがそのような手数料を含めない場合、Tx0は、ブロックチェーンノード104によって拒否される場合があり、したがって、厳密に言えば有効であるが、伝播されず、ブロックチェーン150に含められない場合がある(ノードプロトコルは、ブロックチェーンノード104が望まない場合に、ブロックチェーンノード104にトランザクション152を受け入れるように強制しない)。一部のプロトコルにおいて、取引手数料は、それ自体の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。その代わりに、所与のトランザクション152の入力202によって指し示される総額と出力203において指定される総額との間のすべての差が、そのトランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1が1つの出力UTXO1のみを有するものとする。UTXO0において指定されたデジタル資産の額がUTXO1において指定された額よりも大きい場合、UTXO1を含むブロックを公開するノード104によって、差が割り振られてよい。しかし、代替的または追加的に、取引手数料がトランザクション152のUTXO203のうちのそれ自体のUTXO203において明示的に指定される可能性があることは、必ずしも除外されない。
【0060】
AliceおよびBobのデジタル資産は、ブロックチェーン150の任意の場所の任意のトランザクション152においてAliceおよびBobにロックされたUTXOから成る。したがって、典型的には、所与の関係者103の資産は、ブロックチェーン150全体の様々なトランザクション152のUTXO全体に散在している。ブロックチェーン150のどこにも、所与の関係者103の総残高を定義する1つの数字は記憶されていない。それぞれの関係者にロックされ、別のオンワードトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を照合することは、クライアントアプリケーション105内のウォレット機能の役割である。ウォレット機能は、ビットコインノード104のいずれかに記憶されたブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。
【0061】
スクリプトコードは、概略的に表現されることが多い(つまり、正確な言語を使用しない)ことに留意されたい。たとえば、特定の機能を表現するためにオペレーションコード(オペコード)を使用する場合がある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの始めにOP_FALSEが先にあるとき、トランザクション内にデータを記憶することができ、それによって、ブロックチェーン150にデータを変更不可能であるようにして記録することができるトランザクションの消費不可能な出力を作成するScript言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を含む可能性がある。
【0062】
概して、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。一部の実施形態において、所与のトランザクションに関して、署名は、トランザクション入力の一部と、トランザクション出力の一部またはすべてに署名する。署名が署名する出力の特定の部分は、SIGHASHフラグに応じて決まる。SIGHASHフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名する時点で決まっている)4バイトのコードである。
【0063】
ロックスクリプトは、概してそれがそれぞれのトランザクションがロックされている関係者の公開鍵を含むという事実を示して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、通常、それが対応する署名を供給するという事実を示して、「scriptSig」と呼ばれることがある。しかし、より広く、UTXOが履行されるための条件が署名を認証することを含むことは、ブロックチェーン150のすべての応用において必須ではない。より広く、スクリプト言語が、任意の1つまたは複数の条件を定義するために使用される可能性がある。したがって、より広い用語「ロックスクリプト」および「ロック解除スクリプト」が、好ましい場合がある。
【0064】
図1に示されたように、AliceおよびBobのコンピュータ機器102a、120bの各々のクライアントアプリケーションは、追加の通信機能を含む場合がある。この追加の機能は、Alice103aが、(どちらかの関係者または第三者の勧めによって)Bob103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別にデータのやりとりを可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、関係者の一方がトランザクション152をネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されていない、またはチェーン150に向かって進んでいない状態で、AliceとBobとの間でトランザクション152をやりとりするために使用される場合がある。このようにしてトランザクションを共有することは、「トランザクションテンプレート(transaction template)」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる1つまたは複数の入力および/または出力を欠いている場合がある。代替的または追加的に、サイドチャネル107は、鍵、交渉された額または条項、データ内容などの任意のその他のトランザクション関連データをやりとりするために使用される場合がある。
【0065】
サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立されてよい。代替的または追加的に、サイドチャネル107は、モバイルセルラネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはAliceおよびBobのデバイス102a、102bの間の直接有線もしくは無線リンクなどの異なるネットワークを介して確立されてよい。概して、本明細書のどこで言及されるサイドチャネル107も、「オフチェーン」、すなわち、ブロックチェーンネットワーク106とは別でデータをやりとりするための1つまたは複数のネットワーキングテクノロジーまたは通信媒体を介した任意の1つまたは複数のリンクを含んでよい。2つ以上のリンクが使用される場合、オフチェーンリンクの束または集合が全体としてサイドチャネル107と呼ばれる場合がある。したがって、AliceおよびBobがサイドチャネル107を介して特定の情報またはデータなどをやりとりすると言われる場合、これは、これらのデータすべてがまったく同じリンクまたはさらには同じ種類のネットワーク上で送信されなければならないことを必ずしも示唆しないことに留意されたい。
【0066】
クライアントソフトウェア
図3Aは、今開示されている方式の実施形態を実施するためのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を含む。トランザクションエンジン401は、上で検討された方式に従っておよびまもなくさらに詳細に検討されるように、トランザクション152を組み立てること、サイドチャネル107を介してトランザクションおよび/もしくはその他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて伝播するように1つもしくは複数のノード104にトランザクションを送信することなどの、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。本明細書において開示される実施形態によれば、各クライアント105のトランザクションエンジン401は、下で検討されるように、要求トランザクション、確認トランザクション、返金トランザクション、取消(revocation)トランザクション、更新トランザクション、および広告トランザクションのうちの1つ、いくつか、またはすべてを生成するための機能403を含む。
図3Aは、今開示されている方式の実施形態を実施するためのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を含む。トランザクションエンジン401は、上で検討された方式に従っておよびまもなくさらに詳細に検討されるように、トランザクション152を組み立てること、サイドチャネル107を介してトランザクションおよび/もしくはその他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて伝播するように1つもしくは複数のノード104にトランザクションを送信することなどの、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。本明細書において開示される実施形態によれば、各クライアント105のトランザクションエンジン401は、下で検討されるように、要求トランザクション、確認トランザクション、返金トランザクション、取消(revocation)トランザクション、更新トランザクション、および広告トランザクションのうちの1つ、いくつか、またはすべてを生成するための機能403を含む。
【0067】
UIレイヤ402は、機器102のユーザ出力手段を介してそれぞれのユーザ103に情報を出力すること、および機器102のユーザ入力手段を介してそれぞれのユーザ103から返ってくる入力を受け取ることを含め、それぞれのユーザのコンピュータ機器102のユーザ入力/出力(I/O)手段を介してユーザインターフェースを提供するように構成される。たとえば、ユーザ出力手段は、視覚的出力を提供するための1つもしくは複数のディスプレイスクリーン(タッチスクリーンもしくは非タッチスクリーン)、音声出力を提供するための1つもしくは複数のスピーカ、および/または触覚的出力を提供するための1つもしくは複数の触覚出力デバイスなどを含む可能性がある。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーン(出力手段に使用されるものと同じもしくは異なる)、マウス、トラックパッド、もしくはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、スピーチもしくは発声入力を受け取るための1つもしくは複数のマイクロフォンおよび音声もしくは声認識アルゴリズム、手もしくは体のジェスチャの形態の入力を受け取るための1つもしくは複数のジェスチャベースの入力デバイス、または1つもしくは複数の機械式ボタン、スイッチ、もしくはジョイスティックなどの入力アレイ(input array)を含む可能性がある。
【0068】
注:本明細書における様々な機能は同じクライアントアプリケーション105に統合されるものとして説明される場合があるが、これは、必ずしも限定的ではなく、その代わりに、それらの機能は、たとえば、一方が他方に対するプラグインであるか、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースをとる、2つ以上の異なるアプリケーションのスイートに実装される可能性がある。たとえば、トランザクションエンジン401の機能は、UIレイヤ402とは別個のアプリケーションに実装されてよく、またはトランザクションエンジン401などの所与のモジュールの機能は、2つ以上のアプリケーションの間で分けられる可能性がある。説明される機能の一部またはすべてが、たとえば、オペレーティングシステムレイヤに実装される可能性があることも排除されない。本明細書の任意の箇所で単一のまたは所与のアプリケーション105などへの言及がなされる場合、これは単なる例示であり、より広く、説明された機能は任意の形態のソフトウェアで実装される可能性があることが理解されるであろう。
【0069】
図3Bは、Aliceの機器102aのクライアントアプリケーション105aのUIレイヤ402によってレンダリングされる場合があるユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、Bobの機器102bのクライアント105b、または任意のその他の関係者の機器のクライアントによってレンダリングされてよいことは理解されるであろう。
【0070】
例示として、図3Bは、Aliceの観点でUI500を示す。UI500は、ユーザ出力手段を介して異なるUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を含んでよい。
【0071】
たとえば、UI要素は、異なる画面上のボタン、またはメニューの異なる選択肢などである場合がある1つまたは複数のユーザが選択可能な要素501を含んでよい。ユーザ入力手段は、ユーザ103(この場合、Alice103a)が、画面上のUI要素をクリックもしくはタッチするか、または所望の選択肢の名前を言うことによるなどして、選択肢のうちの1つを選択するかまたはそれ以外の方法で操作することを可能にするように配置される(本明細書において使用される用語「手動」は、自動と対照を成すことを意図されているに過ぎず、必ずしも1つの手または複数の手の使用に限定されないことに注意されたい)。選択肢は、下で検討されるように、ユーザが要求トランザクション、確認トランザクション、返金トランザクション、取消トランザクション、更新トランザクション、および広告トランザクションのうちの1つ、いくつか、またはすべてに必要とされるデータを含めることを可能にする。
【0072】
代替的または追加的に、UI要素は、1つまたは複数のデータ入力フィールド502を含んでよく、それらのデータ入力フィールド502を通じて、ユーザは、上述のデータを入力することができる。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえば、画面上にレンダリングされ、データは、ユーザ入力手段、たとえば、キーボードまたはタッチスクリーンを通じてフィールドに入力され得る。代替的に、データは、たとえば、音声認識に基づいて口述でデータを受け取る可能性がある。
【0073】
代替的または追加的に、UI要素は、ユーザに対して情報を出力するための1つまたは複数の情報要素503の出力を含んでよい。たとえば、これ/これらは、画面上にまたは聞こえるようにレンダリングされる可能性がある。
【0074】
様々なUI要素をレンダリングし、選択肢を選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能は、まもなくより詳細に検討される。図3に示されたUI500は図式化されたモックアップであるに過ぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を含む場合があることも理解されるであろう。
【0075】
準備
暗号学的ハッシュ関数
ハッシュ関数は、任意の長さのデータを固定長の文字列にマッピングする手段として、ブロックチェーンの実装において広く使用されている。概して、暗号学的ハッシュ関数が、これが安全に行われること、およびこれらのハッシュ関数の出力が一意であることを保証するために使用される。概して、ハッシュ関数は、以下の特性を持つ場合に、暗号学的に安全であると考えられる。
1. 原像計算困難性(pre-image resistant) -- h = H(m)が与えられたとして、mを求めることが計算上困難である。
2. 第2原像計算困難性(second pre-image resistant) -- h = H(m)およびmが与えられたとして、H(m') = hであるようなm'を求めることが計算上困難である。
3. 衝突耐性(collision resistant) -- H(m) = H(m')であるようなメッセージmおよびm'のペアを求めることが計算上困難である。
暗号学的ハッシュ関数
ハッシュ関数は、任意の長さのデータを固定長の文字列にマッピングする手段として、ブロックチェーンの実装において広く使用されている。概して、暗号学的ハッシュ関数が、これが安全に行われること、およびこれらのハッシュ関数の出力が一意であることを保証するために使用される。概して、ハッシュ関数は、以下の特性を持つ場合に、暗号学的に安全であると考えられる。
1. 原像計算困難性(pre-image resistant) -- h = H(m)が与えられたとして、mを求めることが計算上困難である。
2. 第2原像計算困難性(second pre-image resistant) -- h = H(m)およびmが与えられたとして、H(m') = hであるようなm'を求めることが計算上困難である。
3. 衝突耐性(collision resistant) -- H(m) = H(m')であるようなメッセージmおよびm'のペアを求めることが計算上困難である。
【0076】
ブロックチェーン150上で、トランザクション識別子TxIDは、通常、SHA-256暗号学的ハッシュ関数を使用して生成され、したがって、ハッシュ関数のダイジェストの特性を継承する。
【0077】
ハッシュパズル
ロックスクリプトの構築で使用されるよくある技術は、ハッシュパズルである。これらのパズルは、割り振る者(assignor)によって設定された所与のハッシュダイジェストH(X)の正しい原像Xを提供するように割り振られる者(assignee)に強制する、スクリプトで記述された単純なチャレンジ(challenge)である。これらのパズルは、以下のように記述される。
[Hash Puzzle H(X)] = OP_SHA256 <H(X)> OP_EQUAL
ロックスクリプトの構築で使用されるよくある技術は、ハッシュパズルである。これらのパズルは、割り振る者(assignor)によって設定された所与のハッシュダイジェストH(X)の正しい原像Xを提供するように割り振られる者(assignee)に強制する、スクリプトで記述された単純なチャレンジ(challenge)である。これらのパズルは、以下のように記述される。
[Hash Puzzle H(X)] = OP_SHA256 <H(X)> OP_EQUAL
【0078】
ブロックチェーンへのデータの記憶
ブロックチェーンテクノロジーの採用が、これをサポートするためのスケーリングインフラストラクチャ(scaling infrastructure)と一緒に拡大するにつれて、ブロックチェーン150上に大量のデータを挿入することへの関心が高まっている。ブロックチェーントランザクション152の様々なフィールドの使用を通じて、ブロックチェーン150にデータを記憶することは確かに可能である。ブロックチェーン150へのデータの記憶は、大まかに、2つの方法のうちの一方、消費不可能なOP_RETURNオペコードを使用するか、またはOP_DROPステートメントを使用するかのどちらかで行われ得る。
ブロックチェーンテクノロジーの採用が、これをサポートするためのスケーリングインフラストラクチャ(scaling infrastructure)と一緒に拡大するにつれて、ブロックチェーン150上に大量のデータを挿入することへの関心が高まっている。ブロックチェーントランザクション152の様々なフィールドの使用を通じて、ブロックチェーン150にデータを記憶することは確かに可能である。ブロックチェーン150へのデータの記憶は、大まかに、2つの方法のうちの一方、消費不可能なOP_RETURNオペコードを使用するか、またはOP_DROPステートメントを使用するかのどちらかで行われ得る。
【0079】
一部のブロックチェーンプロトコルによれば、OP_RETURNがスクリプトの実行を失敗させるので、OP_RETURNオペコードによって印を付けられたトランザクション出力は、消費不可能であることが証明可能な出力(provably unspendable output)として知られる。その他のブロックチェーンプロトコルによれば、トランザクション出力は、オペコードOP_FALSE OP_RETURN、またはOP_0 OP_RETURNによって出力に印を付けることによって消費不可能であることが証明可能であるようにされる。本明細書において使用されるとき、「OP_RETURN」は、「OP_FALSE OP_RETURN」または「OP_0 OP_RETURN」の省略表現として使用される。したがって、そのようなオペコードの後の任意のデータを以下の種類のロックスクリプトに記憶することが可能である。
OP_RETURN <D>
ブロックチェーンノード104がOP_RETURNオペコードに続くすべてのスクリプトを実行することは要件ではなく、つまり、データを記憶するこの方法は、スクリプトの一部に記憶されたデータに通常適用されるいかなるフォーマット要件も満たす必要がないという利点を有する。
OP_RETURN <D>
ブロックチェーンノード104がOP_RETURNオペコードに続くすべてのスクリプトを実行することは要件ではなく、つまり、データを記憶するこの方法は、スクリプトの一部に記憶されたデータに通常適用されるいかなるフォーマット要件も満たす必要がないという利点を有する。
【0080】
ブロックチェーントランザクション152にデータを記憶するために使用され得る代替的な方法は、OP_DROPオペコードを使用することである。これは、
OP_PUSHDATA D OP_DROP
の形式のロックまたはロック解除スクリプトにおいて使用されることが可能であり、これは、通常、
<D> OP_DROP
のように、OP_PUSHDATAオペコードを、スタックにプッシュされるデータ要素を囲む山括弧に置き換えることによってより簡単に表現される。
OP_PUSHDATA D OP_DROP
の形式のロックまたはロック解除スクリプトにおいて使用されることが可能であり、これは、通常、
<D> OP_DROP
のように、OP_PUSHDATAオペコードを、スタックにプッシュされるデータ要素を囲む山括弧に置き換えることによってより簡単に表現される。
【0081】
しかし、そのようなスクリプトに記憶されたデータは、スクリプトの実行およびトランザクションの承認によって組み込まれるスクリプトレベルのチェックの対象であることに留意されたい。
【0082】
複数署名スクリプトの使用
n個中m個の特定の公開鍵に対応する任意のn個中m個の署名を提供することによってロックを解除され得るトランザクションロックスクリプトを構築することが可能である。そのような複数署名トランザクションのロックスクリプトの条件は、以下のように記述される。
[CheckMultisig m-of-n] = OP_m <P1> ... <Pn> OP_n OP_CHECKMULTISIG
この複数署名ロックスクリプトは、公開鍵P1 ... Pnのサブセットをその他のデータに置き換えることによって、データを埋め込むために使用され得る。複数署名ロックスクリプトは、1つの有効な公開鍵Pのみを用いて、n-1個のデータ要素を埋め込むために使用され得る。これは、以下のように概略的に記述される。
[CheckMultisig 1-of-n] = OP_1 <P> <D1> ... <Dn-1> OP_n OP_CHECKMULTISIG
n個中m個の特定の公開鍵に対応する任意のn個中m個の署名を提供することによってロックを解除され得るトランザクションロックスクリプトを構築することが可能である。そのような複数署名トランザクションのロックスクリプトの条件は、以下のように記述される。
[CheckMultisig m-of-n] = OP_m <P1> ... <Pn> OP_n OP_CHECKMULTISIG
この複数署名ロックスクリプトは、公開鍵P1 ... Pnのサブセットをその他のデータに置き換えることによって、データを埋め込むために使用され得る。複数署名ロックスクリプトは、1つの有効な公開鍵Pのみを用いて、n-1個のデータ要素を埋め込むために使用され得る。これは、以下のように概略的に記述される。
[CheckMultisig 1-of-n] = OP_1 <P> <D1> ... <Dn-1> OP_n OP_CHECKMULTISIG
【0083】
ブロックチェーン上の合意
図4は、本発明の実施形態を実装するための例示的なシステム400を示す。示されるように、システム400は、要求側401、確認側402、およびブロックチェーンネットワーク106(すなわち、1つまたは複数のブロックチェーンノード104)を含む。実施形態によれば、要求側401は、要求トランザクションを生成し、要求トランザクションをブロックチェーンネットワーク106に提出する(またはそうでなければ要求トランザクションをブロックチェーンネットワーク106に提出させる)ように構成される。確認側402は、確認トランザクションを生成し、確認トランザクションをブロックチェーンネットワーク106に提出する(またはそうでなければ確認トランザクションをブロックチェーンネットワーク106に提出させる)ように構成される。図4にやはり示されるように、確認側402は、広告トランザクションを生成し、広告トランザクションをブロックチェーンネットワーク106に提出する場合もある。一部の例において、要求側401および確認側402は、オフチェーンの通信方法を使用して通信する場合がある。
図4は、本発明の実施形態を実装するための例示的なシステム400を示す。示されるように、システム400は、要求側401、確認側402、およびブロックチェーンネットワーク106(すなわち、1つまたは複数のブロックチェーンノード104)を含む。実施形態によれば、要求側401は、要求トランザクションを生成し、要求トランザクションをブロックチェーンネットワーク106に提出する(またはそうでなければ要求トランザクションをブロックチェーンネットワーク106に提出させる)ように構成される。確認側402は、確認トランザクションを生成し、確認トランザクションをブロックチェーンネットワーク106に提出する(またはそうでなければ確認トランザクションをブロックチェーンネットワーク106に提出させる)ように構成される。図4にやはり示されるように、確認側402は、広告トランザクションを生成し、広告トランザクションをブロックチェーンネットワーク106に提出する場合もある。一部の例において、要求側401および確認側402は、オフチェーンの通信方法を使用して通信する場合がある。
【0084】
要求側401および確認側402は、上述のAlice103aおよび/またはBob103bに関連するアクションの一部またはすべてを実行してよい。たとえば、要求側401が、Alice103aと同等とみなされてよく、確認側402が、Bob103bと同等とみなされてよく、またはその逆であってもよい。その意味で、要求側401および確認側402の各々は、それぞれのクライアントアプリケーション105が実行されるそれぞれのコンピューティング機器102を運用してよい。要求側401または確認側402によって実行されるものとして説明されるすべてのアクションは、それらのそれぞれのクライアントアプリケーション105によって、またはより広く、それらのそれぞれのコンピューティング機器102によって実行されてよいことが理解されるであろう。
【0085】
実施形態において、要求側401は、確認側402と合意を結ぶことを希望する。要求側401は、確認側402が、要求側401によって望まれる合意とまったく同じ合意に同意することを保証したい。そのようにするために、要求側は、要求トランザクションを生成する。要求トランザクションは、ブロックチェーントランザクションである。要求トランザクションは、1つまたは複数の入力および1つまたは複数の出力を含む。少なくとも1つの出力(第1の出力)は、合意に基づくハッシュパズルを含む。より広く、ハッシュパズルは、合意を表すデータアイテム(第1のデータアイテム)に基づく。ここで、第1のデータアイテムは、合意を符号化するかまたはそうでなければ圧縮する場合があり、たとえば、第1のデータアイテムは、少なくとも合意(および任意で追加データ)のハッシュを含んでよい。その他の例において、第1のデータアイテムは、合意を含む(たとえば、合意である)場合がある。
【0086】
一部の例において、両者の間の「合意」は、静的な情報、たとえば、標準約款(standard terms and conditions)、秘密保持契約、任意のユーザによって署名される権利放棄(waiver)などに基づく場合がある。言い換えると、合意は、関係者の一方だけによって生成されてよい。
【0087】
その他の例において、合意は、両者によって生成される場合がある。すなわち、要求側と確認側との両者が、どちらかの関係者によって提案された初期バージョンに基づいていた可能性がある合意、たとえば、交渉された契約にそれぞれ寄与した可能性がある。
【0088】
要求トランザクションに含まれるハッシュパズルは、いずれの場合も合意の最終形態に基づく。合意の最終形態は、(下でより詳細に検討される)広告された契約と同じであってよい。代替的に、最終形態は、要求側401、確認側402、および/または独立した第三者による調停、交渉などの結果であった可能性がある。
【0089】
第1のデータアイテムは、要求側401と確認側402との両者に知られている。すなわち、要求側401と確認側402との両者が、第1のデータアイテムによって表される合意にアクセスすることができる。
【0090】
第1のデータアイテムAのハッシュパズルは、以下の形式をとる場合がある。
[Hash Puzzle H(A)] = OP_SHA256 <H(A)> OP_EQUAL
オペコードOP_SHA256は、SHA-256ハッシュ関数を使用して入力をハッシュするように構成される。概して、ハッシュパズルは、異なるハッシュ関数を使用して入力をハッシュするように構成されたオペコードを含む場合がある。たとえば、上記のハッシュパズルのOP_SHA256オペコードは、OP_RIPEMD160、OP_SHA1、OP_HASH160、OP_HASH256、または利用可能になる可能性がある任意のその他のハッシュオペコードのうちの任意の1つに置き換えられてよい。
[Hash Puzzle H(A)] = OP_SHA256 <H(A)> OP_EQUAL
オペコードOP_SHA256は、SHA-256ハッシュ関数を使用して入力をハッシュするように構成される。概して、ハッシュパズルは、異なるハッシュ関数を使用して入力をハッシュするように構成されたオペコードを含む場合がある。たとえば、上記のハッシュパズルのOP_SHA256オペコードは、OP_RIPEMD160、OP_SHA1、OP_HASH160、OP_HASH256、または利用可能になる可能性がある任意のその他のハッシュオペコードのうちの任意の1つに置き換えられてよい。
【0091】
上述のように、後のトランザクションの入力スクリプトと一緒に実行されるとき、ハッシュパズルは、入力スクリプトが第1のデータアイテムAを含むことを要求する。
【0092】
要求トランザクションは、要求側401によって生成された、たとえば、要求側401によって所有されるプライベート鍵を使用して生成された署名を含む入力を含んでよい。署名は、要求トランザクションの1つもしくは複数の入力および/または1つもしくは複数の出力に署名する場合がある。
【0093】
一部の例において、要求トランザクションの第1の出力は、1つまたは複数の追加のハッシュパズルを含む場合がある。たとえば、合意の対象(第2のデータアイテム)に基づくハッシュパズルが、第1の出力に含められる場合がある。ここで、合意の対象は、任意の形態、たとえば、画像ファイル、ビデオファイル、オーディオファイル、テキスト文書、コンピュータコードなどの形態をとる場合がある。より広く、第2のデータアイテムは、合意の条項の下で提供される(たとえば、購入されるまたはライセンスを与えられる)ことになる内容を表す場合がある。第2のデータアイテムは、内容そのものを含むか、または少なくとも内容のハッシュを含む場合がある。
【0094】
追加的または代替的に、第1の出力は、要求側401の識別子を表す第3のデータアイテムに基づくハッシュパズルを含む場合がある。たとえば、識別子は、要求側401によって所有されるプライベート鍵に対応する公開鍵であってよい。識別子は、より普通の形態、たとえば、名前、住所、電子メールアドレスなどの形式をとる場合がある。第3のデータは、識別子を含む場合があり、または第3のデータアイテムは、少なくとも識別子のハッシュを含む場合がある。
【0095】
ロックを解除されるために、第1の出力のロックを解除しようと試みる入力が、公開鍵に対応する確認側402によって所有されるプライベート鍵に基づいて生成された署名を含まなければならないように、要求側401は、さらに、第1の出力を確認側402の公開鍵にロックしてよい。
【0096】
要求トランザクションは、1つまたは複数のデータ要素をさらに含んでよい。たとえば、要求トランザクションは、以下、すなわち、合意のハッシュ、合意の二重ハッシュ、要求側の識別子のハッシュ、要求側の識別子の二重ハッシュ、確認側の識別子のハッシュ、確認側の識別子の二重ハッシュ、要求トランザクションが要求トランザクションであることを示すインジケータ(たとえば、フラグ)、および(下で検討される)広告トランザクションへの参照(たとえば、そのTxID)のうちの1つ、いくつか、またはすべてを含んでよい。データ要素の一部またはすべては、たとえば、OP_DROPステートメントを使用して第1の出力に含められてよい。データ要素の一部またはすべては、第2の出力に含められてよい。第2の出力は、消費不可能な出力、たとえば、OP_RETURNの出力である場合がある。
【0097】
一部の例において、第1の出力は、第1の出力が2つ以上の方法でロックを解除されることを可能にするスクリプトの追加の部分を含んでよい。たとえば、第1の出力は、if-elseステートメント(または同等のもの)を含んでよい。if-elseステートメントの第1の分岐が、上述のハッシュパズルを含む場合がある。第2の分岐は、公開鍵、たとえば、要求側401の公開鍵または確認側402の公開鍵にロックされる場合がある。たとえば、要求側402の公開鍵にロックされた出力は、P2PKまたはP2PKHの出力であってよい。一部の例において、第2の分岐は、要求側の公開鍵および確認側の公開鍵のうちの1つまたは複数にロックされる複数署名スクリプトを含む場合がある。
【0098】
要求側401は、要求トランザクションを1つまたは複数のブロックチェーンノード104に送信する。要求側401は、その代わりに、1つまたは複数のブロックチェーンノード104に転送するための別の関係者(たとえば、確認側402)に要求トランザクションを送信する場合がある。要求トランザクションが、有効なトランザクションであるためのブロックチェーンプロトコルの要件を満たすと仮定すると、要求トランザクションは、ブロックチェーン150上で公開される。
【0099】
確認側402は、要求トランザクションへの参照、たとえば、要求トランザクションのトランザクション識別子を取得する。確認側402は、確認トランザクションを生成する。確認トランザクションは、1つまたは複数の入力および1つまたは複数の出力を含む。確認トランザクションの第1の入力は、要求トランザクションの第1の出力を参照する。第1の入力は、第1のデータアイテムに基づくハッシュパズルの解を含む。すなわち、第1の入力は、第1のデータアイテムを含む。
【0100】
確認トランザクションの第1の入力は、要求トランザクションが1つまたは複数の追加のハッシュパズルを含む場合、1つまたは複数の追加の解も含んでよい。たとえば、確認トランザクションの第1の入力は、第2のデータアイテムおよび/または第3のデータアイテムを含む場合がある。
【0101】
確認トランザクションの第1の入力は、たとえば、要求トランザクションの第1の出力が対応する公開鍵にロックされている場合、確認側402によって所有されるプライベート鍵により生成された署名も含んでよい。
【0102】
確認トランザクションは、確認側の公開鍵にロックされた第1の出力を含んでよい。たとえば、出力は、P2PKまたはP2PKHの出力である。公開鍵は、要求トランザクションの第1の出力がロックされている同じ公開鍵でよいが、好ましくは、異なる公開鍵である。
【0103】
確認側402は、要求トランザクションを1つまたは複数のブロックチェーンノード104に送信する。確認側402は、その代わりに、1つまたは複数のブロックチェーンノード104に転送するための別の関係者(たとえば、要求側401)に要求トランザクションを送信する場合がある。確認トランザクションが有効なトランザクションであるためのブロックチェーンプロトコルの要件を満たすと仮定すると、確認トランザクションの第1の入力が要求トランザクションの第1の出力のロックを解除するために必要とされるデータを含む場合、要求トランザクションは、ブロックチェーン150上で公開される。
【0104】
確認トランザクションは、ブロックチェーン150上で公開されると、要求側401と確認側402との両者による合意への相互の承諾を証拠立てる。相互の承諾は、確認トランザクションがハッシュパズルの解を含む場合に公開されるという意味で確認され、そのためには、要求側401と確認側402との両者が、同じ合意に基づいて生成される同じ第1データアイテムを有していなければならない。
【0105】
上で検討されたように、要求トランザクションと確認トランザクションとの両方は、要求側401および確認側402によってそれぞれ生成されたそれぞれの署名を含んでよい。すなわち、要求トランザクションは、入力に、要求トランザクションの一部またはすべてに署名する署名を含んでよい。同様に、確認トランザクションは、入力に、確認トランザクションの一部またはすべてに署名する署名を含んでよい。
【0106】
好ましくは、要求側の署名は、要求トランザクション、すなわち、ハッシュパズルを含むトランザクションの第1の出力を含むメッセージに署名し、確認側の署名は、要求トランザクションの第1入力、すなわち、確認トランザクションの第1の出力を参照し、ロックを解除する入力を含むメッセージに署名する。
【0107】
これらの署名は、合意の紙のコピーに署名するのと同様に、合意自体に署名することと解釈されてよい。それは、確認側の署名によって署名されたメッセージが、概して、要求トランザクションの第1の出力スクリプトも必然的に含まなければならないからである。これは、署名が実際には両方とも要求トランザクションの第1の出力(または少なくとも第1の出力のロックスクリプト)に署名することを意味する。さらなる情報に関しては、https://wiki.bitcoinsv.io/index.php/OP_CHECKSIGを参照されたい。OP_CHECKSIGは、ECDSA署名を検証するオペコードである。OP_CHECKSIGは、スタックから2つの入力、公開鍵(スタックの一番上にある)、およびsighashフラグと連結されたそのDER_CANONISEDフォーマットのECDSA署名を取得する。OP_CHECKSIGは、署名のチェックが合格かまたは不合格かに基づいて、スタックにtrueまたはfalseを出力する。
【0108】
署名はそれ自体に署名し得ない、すなわち、署名は、通常、署名が含まれる入力スクリプトに署名しないので、確認トランザクションの第1の入力のデータ、たとえば、H(IP)またはH(LA)は、概して、確認側の署名によって署名されないことに留意されたい。
【0109】
この概念は、事実上、二者の両者が同じメッセージに(少なくとも部分的に)署名することを強制し、両者が署名するメッセージの部分は、合意の表現を含む。
【0110】
一部の例において、要求トランザクションの第1の出力は、ロックスクリプトの一部を分離するように構成された1つまたは複数のオペコードを含む場合がある。1つのそのようなオペコードは、OP_CODESEPERATOR(OCS)である。たとえば、https://wiki.bitcoinsv.io/index.php/OP_CODESEPARATORを参照されたい。OCSは、確認側402が、署名するために要求トランザクションの第1の出力から合意(または合意の表現、たとえば、第1のデータアイテムの二重ハッシュまたはハッシュパズル全体)のみを選択することを可能にするために使用され得る。たとえば、第1のデータアイテムに基づくハッシュパズルが、OCSオペコードとOP_CHECKSIGオペコードとの間に配置される場合がある。これは、OCSオペコードとOP_CHECKSIGオペコードとの間のデータが、確認トランザクションの第1の入力に含まれる署名によって署名されることを可能にする。
【0111】
要求トランザクションの第1の出力に含まれてよい2つの例示的なロックスクリプトが、以下で与えられる。第1の例においては、OP_CODESEPARATORが、第三者が前のロックスクリプトの一部だけに署名するのを助けるために使用される。代替的な例において、ロックスクリプトは、確認側にとって関心のあるトランザクションの一部にのみに確認側が署名することを可能にする。
(要求トランザクション内の)ロックスクリプト:
OP_CHECKSIGVERIFY <H(LA)> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG
(確認トランザクション内の)ロック解除スクリプト:
<Sig B> <PK B> <Sig A> <PK A>
説明:
- PK Aは、確認側の公開鍵であってよい
- <Sig A>は 「<H(LA)> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG」を含むメッセージに署名する
- PK Bは、第三者の公開鍵、たとえば、著作権弁護士または証人であってよい
- <Sig B>は、上記の括弧内のスクリプトの全体を含まないメッセージに署名する
- OP_CODESEPARATORは、<Sig B>がOP_CODESEPARATORの左側の前のロックスクリプトのいずれにも署名する必要がないことを保証する
または、代替的に、
(要求トランザクション内の)ロックスクリプト:
OP_CHECKSIGVERIFY <OTHER DATA> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG <H(LA)>
(確認トランザクション内の)ロック解除スクリプト:
<Sig A> <PK A> <Sig B> <PK B>
説明:
- これは、第1のシナリオに似ているが、署名者の順序が入れ替えられており、ロックスクリプトは、確認側が署名する必要のない何らかの<OTHER DATA>を含む。
- <OTHER DATA>は、たとえば、証人によって署名される必要があるが、主署名者(chief signatory)(すなわち、確認側)によって署名される必要がない証人の宣言(witness declaration)であってよい。
- <Sig B>(第三者、たとえば、著作権弁護士、証人などによる署名)は、要求トランザクションの出力から取得されたスクリプト「OP_CHECKSIGVERIFY <OTHER DATA> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG <H(LA)>」全体に署名する。
- <Sig A>(確認側による署名)は、関心のあるビット<H(LA)>を含むが、<OTHER DATA>を除外する、要求出力スクリプトの「OP_CHECKSIG <H(LA)>」の部分のみを含むメッセージに署名する。
(要求トランザクション内の)ロックスクリプト:
OP_CHECKSIGVERIFY <H(LA)> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG
(確認トランザクション内の)ロック解除スクリプト:
<Sig B> <PK B> <Sig A> <PK A>
説明:
- PK Aは、確認側の公開鍵であってよい
- <Sig A>は 「<H(LA)> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG」を含むメッセージに署名する
- PK Bは、第三者の公開鍵、たとえば、著作権弁護士または証人であってよい
- <Sig B>は、上記の括弧内のスクリプトの全体を含まないメッセージに署名する
- OP_CODESEPARATORは、<Sig B>がOP_CODESEPARATORの左側の前のロックスクリプトのいずれにも署名する必要がないことを保証する
または、代替的に、
(要求トランザクション内の)ロックスクリプト:
OP_CHECKSIGVERIFY <OTHER DATA> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG <H(LA)>
(確認トランザクション内の)ロック解除スクリプト:
<Sig A> <PK A> <Sig B> <PK B>
説明:
- これは、第1のシナリオに似ているが、署名者の順序が入れ替えられており、ロックスクリプトは、確認側が署名する必要のない何らかの<OTHER DATA>を含む。
- <OTHER DATA>は、たとえば、証人によって署名される必要があるが、主署名者(chief signatory)(すなわち、確認側)によって署名される必要がない証人の宣言(witness declaration)であってよい。
- <Sig B>(第三者、たとえば、著作権弁護士、証人などによる署名)は、要求トランザクションの出力から取得されたスクリプト「OP_CHECKSIGVERIFY <OTHER DATA> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG <H(LA)>」全体に署名する。
- <Sig A>(確認側による署名)は、関心のあるビット<H(LA)>を含むが、<OTHER DATA>を除外する、要求出力スクリプトの「OP_CHECKSIG <H(LA)>」の部分のみを含むメッセージに署名する。
【0112】
一部の実施形態において、要求側401は、要求トランザクションの第1の出力のロックを解除するために返金(またはキャンセル)トランザクションを生成してよい。これは、ブロックチェーン上の未使用トランザクション出力(UTXO)のセットから第1の出力を削除する効果がある。これは、確認側402がハッシュパズルを解くことによって第1の出力のロックを解除することを防止する効果もある。
【0113】
要求トランザクションの第1の出力が要求側401の公開鍵にロックされているロックスクリプトの分岐を含む場合、返金トランザクションの第1の入力は、対応するプライベート鍵を使用して生成された署名を含む場合がある。要求トランザクションの第1の出力が複数の公開鍵にロックされているロックスクリプト(たとえば、複数署名スクリプト)の分岐を含む場合、返金トランザクションの第1の入力は、複数の署名、たとえば、要求側401によって所有されるプライベート鍵を使用して生成された署名と、確認側402によって所有されるプライベート鍵を使用して生成された署名を含む場合がある。
【0114】
一部の例において、要求側401は、要求トランザクションの第1の出力を参照する入力を含む返金トランザクションテンプレートを生成し、それから、返金トランザクションを確認側402に送信してよい。そして次に、確認側は、返金トランザクションの第1の入力に署名を追加し、署名されたトランザクションを要求トランザクションに返金してよい。そのとき、要求側401は、要求トランザクションの第1の入力に署名を含めてよい。要求側401が合意の要求をキャンセルしたいとき、要求側401は、完了した返金トランザクションを、ブロックチェーンネットワーク106に、またはブロックチェーンネットワーク106に転送するための別の関係者に送信する。
【0115】
任意の特徴として、返金トランザクションは、時間制限(または時間ロック)を含んでよい。時間制限は、指定された期間が経過するまで、返金トランザクションがブロックチェーン150に公開されることを防止するように構成される。たとえば、時間制限は、それより前に返金トランザクションが公開され得ない時間(たとえば、UNIX時間で測定される)を設定してよい。代替的に、時間制限は、それより前に返金トランザクションが公開され得ないブロック(たとえば、ブロックの高さで測定される)を設定してよい。
【0116】
同様に、確認側402は、確認トランザクションの第1の出力のロックを解除するために取消トランザクションを生成してよい。確認トランザクションの第1の出力が確認側402の公開鍵にロックされている場合、取消トランザクションの第1の入力は、対応するプライベート鍵を使用して生成された署名を含む場合がある。取消トランザクションは、要求側401と確認側402との間の合意の取消と解釈される。したがって、確認側402が合意を取り消したいとき、確認側402は、取消トランザクションを、ブロックチェーンネットワーク106に、またはブロックチェーンネットワーク106に転送するための別の関係者に送信する。
【0117】
一部の実施形態において、確認側402は、たとえば、合意を広告するために、広告トランザクションを生成してよい。広告トランザクションは、1つまたは複数の入力および1つまたは複数の出力を有する。少なくとも入力のうちの第1の入力は、確認側402によって所有されるプライベート鍵を使用して生成された署名を含む。上述のように、確認側402は、確認側402が生成するすべての署名に同じプライベート鍵を使用してよく、または確認側402は、確認側402が生成する1つもしくは複数の署名に異なるプライベート鍵を使用してよい。広告トランザクションは、合意の表現および/または合意の暗号化されたバージョンを含む第1の出力も含む。
【0118】
合意の表現は、合意のハッシュまたは合意の二重ハッシュであってよい。合意は、その他の方法で表されてよい。暗号化されたバージョンは、確認側402によって所有される公開鍵、または要求側401によって所有される公開鍵を用いて合意を暗号化することによって生成される場合がある。一部の例において、合意は、両者によって所有される鍵、たとえば、対称鍵を用いて暗号化される場合がある。一部の例において、出力は、合意自体を含んでよい。
【0119】
広告トランザクションは、それぞれの関係者、たとえば、広告された契約の追加的な関係者によって所有されるプライベート鍵を使用して生成された署名をそれぞれが含む1つまたは複数の追加の入力を含んでよい。
【0120】
広告トランザクションは、広告トランザクションが合意の広告であることを示すインジケータ(たとえば、フラグ)を含んでよい。インジケータは、広告トランザクションの第1の出力または異なる出力に含まれてよい。広告トランザクションの第1の出力(または異なる出力)は、合意の対象の表現(たとえば、ハッシュもしくは二重ハッシュ)および/または暗号化されたバージョンを含んでよい。一部の例において、出力は、合意の対象自体を含んでよい。
【0121】
広告トランザクションは、確認側402の公開鍵にロックされる出力(たとえば、第1の出力または異なる第2の出力)を含んでよい。たとえば、確認側402の公開鍵にロックされた出力は、P2PKまたはP2PKHの出力であってよい。
【0122】
合意を広告するために、確認側402は、広告トランザクションを、ブロックチェーンネットワーク106に、またはブロックチェーンネットワーク106に転送するための別の関係者に送信する。
【0123】
追加的または代替的に、確認側402は、オフチェーンで、すなわち、ブロックチェーンネットワーク106を使用せずに、合意(または潜在的合意)を広告してよい。たとえば、確認側402は、たとえば、サイドチャネル107を介して要求側401に直接(潜在的な)合意を送信してよい。別の例として、確認側402は、ウェブサイト、たとえば、会社のウェブサイト、ソーシャルメディアサイトなどで(潜在的な)合意を広告してよい。確認側402が要求側401に対面でまたは電話で合意について知らせることも排除されない。
【0124】
合意がどのように広告されるかにかかわらず、広告された合意は、ハッシュパズルが基づいている最終合意と同じである場合があり、または同じでない場合がある。たとえば、広告トランザクションに含まれる広告された合意は、要求トランザクションのロックスクリプトおよび確認トランザクションのロック解除スクリプトにおいて使用される「最終合意」と異なる場合がある。
【0125】
たとえば、最終合意は、出発点として使用される初期合意に基づく可能性があり、1回または複数回の修正を経た可能性があり、たとえば、
最終合意=合意+交渉された追加
または、代替的に、
最終合意=合意+交渉された追加-交渉された削除
=合意+交渉された変更
である可能性がある。
最終合意=合意+交渉された追加
または、代替的に、
最終合意=合意+交渉された追加-交渉された削除
=合意+交渉された変更
である可能性がある。
【0126】
ハッシュパズルは、合意が広告されるのではなく、依頼され、確認される時点で合意の最終形態がいったい何なのかの相互理解を強制するために重要である。
【0127】
確認側402は、広告された合意を更新したい、すなわち、合意の1つまたは複数の条項を変更したい可能性がある。そのようにするために、確認側402は、広告トランザクションの第2の出力を参照し、ロックを解除する入力を含む更新トランザクションを生成する。したがって、更新トランザクションの入力は、広告トランザクションの出力がロックされている公開鍵に対応するプライベート鍵を使用して生成された署名を含んでよい。更新トランザクションは、更新された合意の表現および/または暗号化されたバージョンを含む出力も含む。更新トランザクションは、更新トランザクションが更新された合意の広告であることを示すインジケータ(たとえば、フラグ)を含んでよい。一部の例において、出力は、更新された合意を含んでよい。合意を更新するために、確認側402は、更新トランザクションを、ブロックチェーンネットワーク106に、またはブロックチェーンネットワーク106に転送するための別の関係者に送信する。
【0128】
上述の実施形態においては、ハッシュパズルの例が用いられたが、概して、「ハッシュパズル」に対するすべての言及は、「暗号パズル」に置き換えられてよいことに留意されたい。すなわち、ハッシュパズルは、暗号パズルの例であり、本発明の実施形態は、任意の形態の暗号パズルを使用してよい。概して、暗号パズルは、任意の一方向性関数を含んでよい。たとえば、上述のように、暗号パズルは、ハッシュ関数を含むハッシュパズルである場合がある。
【0129】
その他の例において、暗号パズルは、rパズル(r-puzzle)またはrチャレンジ(r-challenge)である場合がある。rパズルはPCT/IB2020/053807に詳細に説明されており、読者はこれを参照されたい。以降、rパズルの簡単な説明が与えられる。
【0130】
rパズルは、チャレンジ(すなわち、パズル)の基礎としてECDSA署名のr部分に対応する参照値に基づく。参照値は、要求トランザクションのロックを解除するために確認トランザクションが指定されたr部分を含む署名を含む(すなわち、確認トランザクションのロック解除スクリプトに)ことを要求するチャレンジとして要求トランザクションのロックスクリプトに含まれる。確認トランザクションにおいてrパズルの解を提供することによって、これは、確認側が対応する一時(ephemeral)鍵kを知っていたに違いないことを、ただし、確認トランザクションにおいてkを明らかにする必要なしに証明する。したがって、kは、一時プライベート鍵として使用されることが可能であり、rは、対応する一時公開鍵のように働く。
【0131】
言い換えると、rパズルは、楕円曲線デジタル署名アルゴリズムECDSAの検証関数に基づく知識証明(knowledge proof)である。要求トランザクションのロックスクリプトは、第1のECDSA署名のr部分の参照インスタンスを指定する要素を含む。確認トランザクションは、少なくとも第1のECDSA署名のs部分を含む情報と、第1の公開鍵とを含み、第1のECDSA署名は、第1の公開鍵に対応する第1のプライベート鍵に基づいてメッセージに署名し、メッセージは、確認トランザクションの一部である。要求トランザクションは、第1のECDSA署名に適用されるECDSAの検証関数が、第2の確認トランザクションにおいて受信されたメッセージと、取得された第1の公開鍵とが与えられたとして、確認トランザクションにおいて受信されたs部分が要求トランザクションによって指定されたr部分の参照インスタンスに対応することを検証するという条件でロックを解除される。
【0132】
要求トランザクションに含まれる要素は、r部分の参照インスタンス自体であってもよく、またはその変換結果、たとえば、r部分を含む構成要素のハッシュであってよい(ハッシュされる構成要素は、たとえば、単にr部分自体に等しい可能性があり、もしくはその他のデータ値dと連結される可能性がある)。したがって、この文脈における「指定された」は、必ずしも明示的な値を含むことを意味しないことに留意されたい(ただし、それが1つの可能な実装であることは間違いない)。より広く、要素は、ECDSAの検証アルゴリズムに従って、s部分の提出されたインスタンスが参照インスタンスに有効に対応するかどうかをチェックすることを可能にする、r部分の参照インスタンスに等しいかまたはr部分の参照インスタンスから導出された任意の要素(たとえば、そのハッシュ)を指し得る。
【0133】
「rパズルの解」は、確認側が一時鍵kを知っていたに違いないことを証明する(kの知識なしに解が提供されることが可能であったとは考えられない)。一時鍵は、合意に基づいて生成されるか、またはそうでなければ合意を表す可能性がある。
【0134】
ハッシュパズルの機能は、一時乱数値であってよいECDSA署名のr部分を利用することによってエミュレートされ得る。ECDSA署名は、2つの主要な部分rおよびsから成る。当業者によく知られているように、r = [k・G]xである。通常のハッシュパズルh = H(d)の代わりに、楕円曲線の加算の逆を求めることの困難さは、本明細書においてrパズルと呼ばれる類似のパズルを形成することができる。このパズルを解くためには、解の値kを取得する必要があり、kは、rに対応する一時鍵である。
【0135】
通常のハッシュパズルでは、リスクは、パズルを解くときにブロックチェーン上にdを明かすことである。しかし、rパズルでは、kは明かされない。その代わりに、rが明かされ、署名と併せてrから、kの知識が証明され得る。
【0136】
ハッシュパズルの機能をエミュレートするために、rパズルの作成者は、kが固定サイズでなければならない一方、ハッシュパズルの原像データは任意の長さであることが可能である(およびハッシュ関数の1つの特性は、入力データの長さに関係なく固定長の値を出力することである)ので、まず、何らかのその他の原像データをハッシュして値kを得てよい。たとえば、長さが256ビットであるプライベート鍵/一時鍵を使用する場合、rパズルの原像データが、kを得るためにハッシュされるべきである。しかし、代替的に、kの何らかの好適な長さの値が選択され、それ自体直接、秘密値として使用される可能性がある(すなわち、何らかのその他の先行する原像からそれを導出する必要はない)。
【0137】
スクリプト言語において、OP_CHECKSIGオペコードは、スタック上に署名および公開鍵を必要とする(公開鍵がスタックの一番上にあり、署名がそのすぐ下にある)。rパズルに関して、スクリプトは、提供された署名のr値がrパズルのチャレンジに使用された同じr値であることをチェックするように構成される。言い換えると、スクリプトは、(OP_CHECKSIGを通して)署名が公開鍵に関して有効であることをチェックするだけでなく、前もってブロックチェーン上で公開されるべきであるrパズルのr値を使用して署名が作成されていることを確認する。
【0138】
次に、rパズルのいくつかの例示的な実装が、検討される。どの場合も、証明者、たとえば、Bobが、Tx2の一部に署名することによって署名(r, s)を作成済みである。この形態の署名は、時に「sig」と呼ばれる場合もある。暗号署名の文脈では、署名された部分が、「メッセージ」(m)とも呼ばれる。署名された部分(メッセージ)mは、少なくとも、結果として生じる支払いをBobにロックするTx2の出力を含む。2つ以上の出力がある場合、mは、出力の一部またはすべてを含む場合がある。mは、使用される場合、locktimeなどのその他の部分を含んでもよい。しかし、mは、通常、ロック解除スクリプト自体を除外する(およびもちろん、少なくとも署名自体を除外しなければならない)。メッセージmとして署名されるTx2の一部は、Sighashによって設定される可能性があり、またはデフォルト、もしくはプロトコルの決まった特徴である可能性がある。
【0139】
単純な実装において、Tx1のロックスクリプトは、ここではr'とラベル付けされる参照インスタンスまたはr部分を含む。この方法において、Tx2のロック解除スクリプトは、少なくとも、Bobの署名のs部分を含みさえすればよい。Tx2のロック解除スクリプトは、Bobがmに署名するために使用したプライベート鍵Vに対応する公開鍵Pも含んでよい。Tx1のロックスクリプトは、ノード104のスクリプトエンジンによって実行されるときに、Tx2のロック解除スクリプトからsおよびPを取得し、以下の動作、すなわち、
I) R' = Hsig(m)s-1・G + r's-1・P、および
II) [R']x = r'をチェックする
を実行するように構成され、r'は、Tx1のロックスクリプトから取得され、sおよびmは、Tx2のロック解除スクリプトから取得される。Bobの公開鍵Pが、Tx2のロック解除スクリプトから取得されてもよく、またはその他の手段によって知られてよい。Hsigは、第1のECDSA署名を生成する際にmをハッシュするために使用されたハッシュ関数である。Hsigは、任意の形態のハッシュ関数であってよい。それがどのような形態であれ、このハッシュ関数の形態(種類)は予め決まっており、両者に知られていると仮定されてよい。Gは、決まった公に知られているベクトル値である。
I) R' = Hsig(m)s-1・G + r's-1・P、および
II) [R']x = r'をチェックする
を実行するように構成され、r'は、Tx1のロックスクリプトから取得され、sおよびmは、Tx2のロック解除スクリプトから取得される。Bobの公開鍵Pが、Tx2のロック解除スクリプトから取得されてもよく、またはその他の手段によって知られてよい。Hsigは、第1のECDSA署名を生成する際にmをハッシュするために使用されたハッシュ関数である。Hsigは、任意の形態のハッシュ関数であってよい。それがどのような形態であれ、このハッシュ関数の形態(種類)は予め決まっており、両者に知られていると仮定されてよい。Gは、決まった公に知られているベクトル値である。
【0140】
ロックスクリプトは、前記チェックが真であることを条件に「真」の結果を返すが、それ以外の場合は「偽」の結果を返すように構成される。UTXOの場合、ロック解除スクリプトと一緒にロックスクリプトを実行した真(すなわち成功)の結果が、トランザクションの有効性の要件である。したがって、Tx2の有効性は、rパズルの結果の代理として使用され得る。言い換えると、Tx2の有効性は、rパズルの解を提供することを条件とする。すなわち、Bobがrパズルに合格しない場合、BobのトランザクションTx2は、ネットワーク106上を伝播されず、ブロックチェーン150に記録もされない(および、Tx1の出力において定義されたいかなる支払いも履行されない)。
【0141】
この例は数学的な意味では最も単純である可能性があるが、これは、必ずしも、任意の所与のノードプロトコルまたはスクリプト言語と統合するのが最も簡単であることを意味しない。消費する者が<r, s>および<P>とは対照的にロック解除スクリプトにおいて<s>および<P>のみを提供する場合、スクリプトは、これを考慮しなければならない。動作I)～II)は、標準的なChecksig型オペコードの動作ではない。OP_CHECKSIGオペコードは、署名がDERフォーマットであることを期待し、したがって、<s>値のみがロック解除スクリプトにおいて提供される場合、DERフォーマットの有効な署名を生成するためにロックスクリプトにいくつかの追加のオペコード(連結するためのOP_CATなど)が必要になる。すべての可能な実施形態において、Tx2にPを含めることは必須ではないことにも留意されたい。実際には、メッセージmおよび(r, s)またはこの場合には(r', s)の知識から、公開鍵の2つの可能な値Pおよび-Pを計算することが可能である(しかし、どちらがどちらなのかを知ることは不可能である)。そのとき、2つの検証が、どちらが正しい方であるのかを特定するために使用されることが可能であり、または代替的に、1ビットのフラグが、2つの可能な解のうちのどちらを使用すべきかを知らせるためにTx2に含められることが可能である。
【0142】
その他の例において、暗号パズルは、プライベート鍵パズル(private key puzzle)である場合がある。プライベート鍵パズルは、WO2020065460に詳細に説明されており、読者はこれを参照されたい。以降、プライベート鍵パズルの簡単な説明が与えられる。
【0143】
プライベート鍵パズルは、所与の公開鍵P1のプライベート鍵S1を露出する入力が与えられる場合に真と評価されるロック解除スクリプトの関数である。この形態のパズルは、楕円曲線暗号(ECC)の公開/プライベート鍵ペアの代数的特性を利用することを可能にするので望ましい。
【0144】
ECCのプライベート鍵
【0145】
【数1】
【0146】
および対応する公開鍵P1を考え、nは、楕円曲線の基底点(base point)Gの位数(order)である。公開鍵およびプライベート鍵は、式
P1 = S1・G
によって関連付けられ、演算子「・」は、楕円曲線の点の乗算を表す。P1が与えられたとして、たとえ楕円曲線のパラメータが知られているとしても、S1を決定するのは計算上困難な問題である。事実上、一方向性の決定的(deterministic)な関数
S1 → P1
が存在する。
P1 = S1・G
によって関連付けられ、演算子「・」は、楕円曲線の点の乗算を表す。P1が与えられたとして、たとえ楕円曲線のパラメータが知られているとしても、S1を決定するのは計算上困難な問題である。事実上、一方向性の決定的(deterministic)な関数
S1 → P1
が存在する。
【0147】
ハッシュパズルと等価なものが、公開/プライベート鍵ペアに関して構築され得る。このプライベート鍵パズルは、対応するプライベート鍵<S1>に基づいて働く場合に真と評価される関数<Solve P1>である。つまり、
<S1><Solve P1> = TRUE
これは、楕円曲線の点の乗算を実行する演算子(たとえば、オペコード)を必要とする。そのような演算子は、以下で「OP_ECMULT」とラベル付けされる。これは、楕円曲線上の点、たとえば、生成元(generator point)Gが正の整数、たとえば、
<S1><Solve P1> = TRUE
これは、楕円曲線の点の乗算を実行する演算子(たとえば、オペコード)を必要とする。そのような演算子は、以下で「OP_ECMULT」とラベル付けされる。これは、楕円曲線上の点、たとえば、生成元(generator point)Gが正の整数、たとえば、
【0148】
【数2】
【0149】
を乗じられることを意味する。つまり、
<S1> <G> OP_ECMULT = <P1>
この場合、プライベート鍵パズルは、以下によって与えられる。
<Solve P1> = <G> OP_ECMULT <P1> OP_EQUALLVERIFY
<S1> <G> OP_ECMULT = <P1>
この場合、プライベート鍵パズルは、以下によって与えられる。
<Solve P1> = <G> OP_ECMULT <P1> OP_EQUALLVERIFY
【0150】
現在、OP_ECMULTの機能を実行することができる単一のオペコードは一部のスクリプト言語(たとえば、Script)に存在しないが、そのような関数を作成し、含めることは些細なことである。さらに、それらの言語は、Script内で楕円曲線の乗算を実行するため、すなわち、その他の演算子を使用してOP_ECMULTを構築するために必要とされるすべての演算子を含む。
【0151】
プライベート鍵が合意に基づいて生成されるかまたは合意を表す場合、プライベート鍵パズルが成功裏に解かれるためには、確認側と要求側との両者が、合意についての同じ知識を必要とすることが分かる。
【0152】
ブロックチェーンライセンス付与プロトコル
本発明は、ブロックチェーン150を使用してライセンス付与プロトコルを実装するために使用されてよい。ブロックチェーンライセンス付与プロトコル(BLP)は、ライセンス契約(LA)を分散された方法で処理するためのシステムの必要とされる機能のすべてを提供するためにプロトコルによって組み合わされる2つの要素を含む。これらの2つの要素は、二者間ハッシュパズル合意(bilateral hash puzzle agreement)、および異なるトランザクションタイプのシステムである。二者間ハッシュパズル合意は、ハッシュパズルの形態で各関係者の承諾を証拠立てることによって、複数の関係者の間でLAの条項の合意を容易にする。トランザクションタイプのシステムは、トランザクションのシステムがライセンス契約の発行および管理に関連する中核機能を記述することができるような方法で、ブロックチェーンネットワーク106上で二者間ハッシュパズル合意を実装するために使用され得る。
本発明は、ブロックチェーン150を使用してライセンス付与プロトコルを実装するために使用されてよい。ブロックチェーンライセンス付与プロトコル(BLP)は、ライセンス契約(LA)を分散された方法で処理するためのシステムの必要とされる機能のすべてを提供するためにプロトコルによって組み合わされる2つの要素を含む。これらの2つの要素は、二者間ハッシュパズル合意(bilateral hash puzzle agreement)、および異なるトランザクションタイプのシステムである。二者間ハッシュパズル合意は、ハッシュパズルの形態で各関係者の承諾を証拠立てることによって、複数の関係者の間でLAの条項の合意を容易にする。トランザクションタイプのシステムは、トランザクションのシステムがライセンス契約の発行および管理に関連する中核機能を記述することができるような方法で、ブロックチェーンネットワーク106上で二者間ハッシュパズル合意を実装するために使用され得る。
【0153】
ハッシュパズルは、通常、関係者が秘密原像(secret preimage)またはデータの知識を有することを証明するように関係者に強制するための知識証明として使用される。一方、本発明は、2人の関係者が公開原像(public preimage)またはデータの相互の承諾および理解を表明することを保証するための承諾証明(consent proof)としてハッシュパズルを使用する。BLPの文脈で、この公開原像は、ライセンス契約の条項自体である。
【0154】
典型的なハッシュパズルにおいて、利用される重要な特性は、ハッシュ関数の原像計算困難性である。これは、
[Hash Puzzle H(X)] = OP_SHA256 <H(X)> OP_EQUAL
の形態のハッシュパズルロックスクリプトに関して、消費する者がロック解除スクリプトの一部として原像Xを明かす時点まで、原像Xが秘密のままであることが意図されているからである。
[Hash Puzzle H(X)] = OP_SHA256 <H(X)> OP_EQUAL
の形態のハッシュパズルロックスクリプトに関して、消費する者がロック解除スクリプトの一部として原像Xを明かす時点まで、原像Xが秘密のままであることが意図されているからである。
【0155】
そのようなロックスクリプトが暗号学的に安全であるために、ハッシュ関数Hの原像計算困難性に頼り、つまり、H(X)が与えられたとして、Xを見つけることが計算上実行不可能であるべきである。これは、チャレンジが、秘密Xを含まずに公開でブロードキャストされることが可能であり、所望の消費者だけが、値Xを取得すると、この方法でロックされた資金を履行することができることを保証する。
【0156】
逆に、二者間ハッシュパズル合意において、利用される重要な特性は、第2原像計算困難性の特性である。つまり、所与のチャレンジH(X)およびXの知識に関して、
H(X') = H(X)かつX'≠X
であるようなX'を見つけることが計算上実行不可能であるべきである。
H(X') = H(X)かつX'≠X
であるようなX'を見つけることが計算上実行不可能であるべきである。
【0157】
AliceとBobとの間の二者間ハッシュパズル合意(BHPA)に関して、二者のうち一方が、
[Hash Puzzle H(A)] = OP_SHA256 <H(A)> OP_EQUAL
を含むロックスクリプトを構築することが意図されており、Aは合意の条項を表し、Aのデータ全体が公開され得る。
[Hash Puzzle H(A)] = OP_SHA256 <H(A)> OP_EQUAL
を含むロックスクリプトを構築することが意図されており、Aは合意の条項を表し、Aのデータ全体が公開され得る。
【0158】
これは、合意の詳細が事前に両者によって知られ得ることを意味する。このロックスクリプトを含むトランザクションの構築および公開は、AliceがBobへの申し出を作成することと解釈される。それから、第2の関係者Bobは、Aliceによってなされた厳密な申し出を受け入れることを表明する方法として、ロック解除スクリプトがAを含むようにして、このチャレンジに対処することができる。重要な違いは、Aが合意の条項を表すので、それが事前に両者に知らされるべきであり、したがって、秘密として扱われないことである。条項は、公共のリソースから適合される可能性さえあり、したがって、Aは、合意に達しようと試みる二者の外部の第三者にとって誰でも知り得る知識(public knowledge)である可能性がある。
【0159】
したがって、意図されていない第三者によるAの入手を防止するために原像計算困難性に頼るのではなく、BLPは、BobがAliceによって提示された条項を本当に受け入れたい場合にのみそれらの条項に同意することができることを保証するために第2原像計算困難性に依拠する。
【0160】
二者間ハッシュパズル合意を実装するために単純なハッシュパズルを転用する動機を表現するために、承諾の証明というフレーズが使用される。BHPAは、二者が単一のデータ、すなわち、ハッシュの原像に対する二者の相互の承諾を表明するための有効な手段である。言い換えると、Bobがチャレンジ[Hash Puzzle H(A)]として運ばれるAliceの申し出を見る場合、Bobは、
H(A') = H(A)かつA'≠A
が両方同時に成り立つような何らかの代替的な合意の詳細A'を生成することができないので、Aliceが行った申し出の受け入れを表明することしかできない。
H(A') = H(A)かつA'≠A
が両方同時に成り立つような何らかの代替的な合意の詳細A'を生成することができないので、Aliceが行った申し出の受け入れを表明することしかできない。
【0161】
これは、ハッシュパズルを使用して二者間の合意を実装する以下の2つの主要な利点を巧妙に有する。
1. Aliceが自身の選んだ条項に基づく申し出Aをする場合、Aliceが、後で、Bobの選んだ条項に基づく代替的な申し出A'に不用意に拘束されるようになることはあり得ない。
2. Bobが、自分が受け入れて構わない申し出の条項Aを公開する場合、Bobは、Aliceなどの多くの第1の関係者によってなされた申し出の自身の受け入れを確認するプロセスを自動化する可能性がある。
1. Aliceが自身の選んだ条項に基づく申し出Aをする場合、Aliceが、後で、Bobの選んだ条項に基づく代替的な申し出A'に不用意に拘束されるようになることはあり得ない。
2. Bobが、自分が受け入れて構わない申し出の条項Aを公開する場合、Bobは、Aliceなどの多くの第1の関係者によってなされた申し出の自身の受け入れを確認するプロセスを自動化する可能性がある。
【0162】
Bobが[Hash Puzzle H(A)]を満たす申し出だけが受け入れられるように自動化する場合、Bobは、代替的な条件A'に不用意に自動的に同意してしまう危険を冒さない。
【0163】
BLPは、BHPAによって達成される承諾の証明が、公開台帳に変更不可能であるようにして記録され、かつライセンシーとライセンサーとの両方がそれらの承諾を証明するライセンス契約の条項の下で価値の交換に関連するデジタル資産を割り振るために必要とされる消費条件の一部として含められ得るような方法でBHPAを実装するためにブロックチェーン150を利用する。
【0164】
次のセクションは、IPのオンワードライセンス付与(onward licensing)および商業化を含む多くのユースケースに適用され得る強力なライセンス契約プラットフォームを促進するために、二者間ハッシュパズル合意が複数のブロックチェーントランザクションのシステムにどのようにして統合され得るかを示す。
【0165】
BLPは、BHPAにおいて所与原像の二重ハッシュを使用することに関わるいくつかの追加的な利点も利用する。BHPAのチャレンジは、以下の形態、すなわち、
[Hash Puzzle H2(A)] = OP_SHA256 <H2(A)> OP_EQUAL
の形態をとり、Aは、関心のあるデータ(たとえば、ライセンス契約)である。これらのチャレンジは、原像のハッシュH(A)を提供することによって満たされ得るので、大きな契約書または文書に関連するストレージの負担を減らすのに有用である。
[Hash Puzzle H2(A)] = OP_SHA256 <H2(A)> OP_EQUAL
の形態をとり、Aは、関心のあるデータ(たとえば、ライセンス契約)である。これらのチャレンジは、原像のハッシュH(A)を提供することによって満たされ得るので、大きな契約書または文書に関連するストレージの負担を減らすのに有用である。
【0166】
両者がAにアクセスすることができると仮定すると、これは、Aにおいて指定された条項への承諾の証明を実現する際に同じ効果を、ただし、関係者が全データをブロックチェーンに記憶し、ブロードキャストすることを要求することなく有する。
【0167】
BLPは、BLPの「アクションタイプ」と考えられ得る5つの構成可能なブロックチェーントランザクションを指定する。これらのトランザクションは、ライセンス契約(LA)を含むシナリオの大部分に関連するBLPの5つの機能にマッピングされ得る。これらの機能は、次のとおりである。
・ライセンス条項の広告、
・購入/ライセンスの要求、
・購入/ライセンスの確認、
・ライセンス条項の更新、および
・返金
・ライセンス条項の広告、
・購入/ライセンスの要求、
・購入/ライセンスの確認、
・ライセンス条項の更新、および
・返金
【0168】
各トランザクションタイプのそれぞれの機能を実現する際のそれらのトランザクションタイプの詳細な責任が、下の表に記載されている。トランザクションタイプのすべてが必須なわけでないことは理解されるであろう。下の例においては、買い手が、要求側401に相当し、著作権者(copyright authority)が、確認側402に相当する。これは、すべての例に当てはまるとは限らないことに留意されたい。つまり、確認側402(確認トランザクションを生成する関係者)は、IPを所有する同じ関係者である必要はない。用語「著作権者」は、単にラベルとして使用されており、著作権者に関連するアクションを実行する関係者がIPの著作権を所有していなければならないことを必ずしも意味しないことにも留意されたい。
【0169】
広告トランザクション(TA)
広告トランザクションは、IPの文書およびIPのライセンス契約を提供するために使用される。IPの生データ自体がトランザクションに記憶されてよく、または好ましい場合は、IPの暗号化されたバージョンが記憶されてよい。しかし、IPまたはLAの生の形態または暗号化された形態をトランザクションに含めることは必要ではない(または文脈によっては望ましい)。その代わりに、IP/LAの一意識別子が、トランザクションに記憶される。この識別子は、前述のように、IPの生の内容の二重ハッシュとして表される可能性がある。場合によっては、関係者が正確なIP/LAを知って行動していることを確認するために、関係者がロック解除スクリプト内でIP/LAの原像を提供しなければならないという事実が原因で、二重ハッシュが、(シングルハッシュ(single hash)の代わりに)使用され得る。IP/LAの一意識別子が実際のIP/LAのハッシュであったならば、ハッシュの原像のブロックチェーン上での提供は、「生」のIP/LAの提供となる。これは、前述のように、好ましくない可能性がある。二重ハッシュを使うことは、原像を提供することがハッシュ、生のIP/LAを明らかにしない何かを提供することであることを意味する。
広告トランザクションは、IPの文書およびIPのライセンス契約を提供するために使用される。IPの生データ自体がトランザクションに記憶されてよく、または好ましい場合は、IPの暗号化されたバージョンが記憶されてよい。しかし、IPまたはLAの生の形態または暗号化された形態をトランザクションに含めることは必要ではない(または文脈によっては望ましい)。その代わりに、IP/LAの一意識別子が、トランザクションに記憶される。この識別子は、前述のように、IPの生の内容の二重ハッシュとして表される可能性がある。場合によっては、関係者が正確なIP/LAを知って行動していることを確認するために、関係者がロック解除スクリプト内でIP/LAの原像を提供しなければならないという事実が原因で、二重ハッシュが、(シングルハッシュ(single hash)の代わりに)使用され得る。IP/LAの一意識別子が実際のIP/LAのハッシュであったならば、ハッシュの原像のブロックチェーン上での提供は、「生」のIP/LAの提供となる。これは、前述のように、好ましくない可能性がある。二重ハッシュを使うことは、原像を提供することがハッシュ、生のIP/LAを明らかにしない何かを提供することであることを意味する。
【0170】
このトランザクションは、IPに対して法的権限を有することが知られている少なくとも1人の権限者によって署名されることが期待される。これは、IPの作成者自身、または他者、たとえば、音楽レーベルの代わりにIPのライセンス付与を管理する第三者の著作権者(CA)である可能性がある。
【0171】
購入トランザクション(TP)
購入トランザクション(要求トランザクションとも呼ばれる)は、IPのライセンスを付与したいエンティティが、広告されたライセンス契約の条件の下で、IPの指定された所有者/著作権者にそれらのトークンを割り振るトランザクションである。要求トランザクションは、ライセンスを付与したいIPへの参照を含む。要求トランザクションは、IPにユーザライセンスを自動的に付与しないことに留意されたい。要求トランザクションは、「IPのライセンスを付与する要求」と、ライセンスのコストとして広告されたトークンの買い手によるエスクローとの正式な表現である。CAは、依然として、ライセンス契約が拘束力があるとみなされる前に、ライセンスを受け入れる必要がある。
購入トランザクション(要求トランザクションとも呼ばれる)は、IPのライセンスを付与したいエンティティが、広告されたライセンス契約の条件の下で、IPの指定された所有者/著作権者にそれらのトークンを割り振るトランザクションである。要求トランザクションは、ライセンスを付与したいIPへの参照を含む。要求トランザクションは、IPにユーザライセンスを自動的に付与しないことに留意されたい。要求トランザクションは、「IPのライセンスを付与する要求」と、ライセンスのコストとして広告されたトークンの買い手によるエスクローとの正式な表現である。CAは、依然として、ライセンス契約が拘束力があるとみなされる前に、ライセンスを受け入れる必要がある。
【0172】
確認トランザクション(TC)
確認トランザクションは、IPの著作権者が要求側のトークンを受け入れ、参照されるライセンス契約の条項のとおりにIPを使用する権利を当事者に正式に付与するトランザクションである。
確認トランザクションは、IPの著作権者が要求側のトークンを受け入れ、参照されるライセンス契約の条項のとおりにIPを使用する権利を当事者に正式に付与するトランザクションである。
【0173】
更新トランザクション(TU)
更新トランザクションは、既存のライセンス契約に更新が必要な場合に使用するように意図される。様々な理由(抜け穴を塞ぐ、規制を満たす、コストを更新するなど)で、ライセンス契約に略述された条項は、訂正のために変更される必要がある場合がある。更新トランザクションは、既存の広告トランザクションの実行可能な出力を消費し、それ自体、広告トランザクションが有するLAおよびIPデータを含む。言い換えると、更新トランザクションは、「既存の広告/更新トランザクションの実行可能な出力を消費する広告トランザクション」とみなされ得る。更新トランザクションが広告トランザクションの出力を消費した後、その前の広告トランザクションの条項および条件は、CAまたは潜在的なライセンシーによってもはや有効であるとみなされない可能性がある。
更新トランザクションは、既存のライセンス契約に更新が必要な場合に使用するように意図される。様々な理由(抜け穴を塞ぐ、規制を満たす、コストを更新するなど)で、ライセンス契約に略述された条項は、訂正のために変更される必要がある場合がある。更新トランザクションは、既存の広告トランザクションの実行可能な出力を消費し、それ自体、広告トランザクションが有するLAおよびIPデータを含む。言い換えると、更新トランザクションは、「既存の広告/更新トランザクションの実行可能な出力を消費する広告トランザクション」とみなされ得る。更新トランザクションが広告トランザクションの出力を消費した後、その前の広告トランザクションの条項および条件は、CAまたは潜在的なライセンシーによってもはや有効であるとみなされない可能性がある。
【0174】
返金トランザクション(TR)
返金トランザクションは、要求トランザクションによってIPのライセンスを付与することに興味を表明する関係者が、指定された時点の前に、当事者がライセンスを付与されたことをCAが確認しない場合、その関係者の資金を返金させることができるトランザクションである。CAは、要求トランザクションの実行可能な出力を消費することで「確認」したであろう。返金トランザクションは、任意であるが、推奨される。
返金トランザクションは、要求トランザクションによってIPのライセンスを付与することに興味を表明する関係者が、指定された時点の前に、当事者がライセンスを付与されたことをCAが確認しない場合、その関係者の資金を返金させることができるトランザクションである。CAは、要求トランザクションの実行可能な出力を消費することで「確認」したであろう。返金トランザクションは、任意であるが、推奨される。
【0175】
図6は、特にそれがその入力および出力に関連するときの例示的な広告トランザクションTAを概略的に示す。トランザクションの少なくとも1つの入力は、IPの権利の正当な所有者/管理者として受け入れられる人物によって署名される。この人物は、著作権者(Copyright Authority)(CA)と呼ばれる。トランザクションへのその他の署名者がいる場合がある。これらは、トランザクションがプロモーションしているIPのライセンス契約に承認を与えることが適切と考えるIPのその他の利害関係者からの署名された入力である。これらは、利害関係者{Pi: i∈[1, n]}である。
【0176】
広告トランザクションにおいて示される2つの出力が存在する。合意されているのが基本的にペア(<H2(IP)>, <H2(LA)>)であるというOP_RETURNの出力表現が最初に参照され、これらのデータがOP_RETURNの出力スクリプトに記憶される。OP_RETURNの出力のためのスクリプトは、スクリプトの正常な実行の構成要素として「処理され」ず、したがって、OP_RETURNに従うスクリプトは、トランザクションにデータを含めるために使用され得ることに留意されたい。OP_RETURNのスクリプトに含まれる別のアイテムは、図6に<Adv ID>として示される広告識別子である。これは、既存のまたは潜在的な利害関係者に、トランザクションがIPおよびそのライセンス契約のプロモーションおよび/または表現を表すことを知らせる目印として著作権者によって選択され、公開される識別子である。当事者は、これらの特殊な「広告」トランザクションを見つけるために、この識別子を含むトランザクションに関してブロックチェーン150を解析することができる。
【0177】
3つのデータ<H2(IP)>、<H2(LA)>、および<Adv ID>の他に、任意で含まれるその他のデータが存在する場合がある。いくつかが、図6に示されている。図に表示されているのは、以下である。
- IP: これは、実際にライセンスを付与されているIPの生データである。その除外の理由は、プライバシーの問題または空間の節約の問題に関する場合がある。生のIP(またはLA)自体がブロックチェーン150上に存在しない場合、望ましいとみなされるように、生のファイルが「オフライン」でアクセス可能であることが期待される。
- e(IP): ブロックチェーン150上でIP自体を公開したくない場合、その代わりに、暗号化されたバージョンe(IP)がブロックチェーン150に置かれてよい。誰がIPを復号することができるかについては、制限が課される。
- LA: IPを律する生のライセンス契約(Licensing Agreement)も、トランザクションに含められ得る。
- e(LA): 好ましい場合、LAの暗号化されたバージョンが、ブロックチェーン150に含められてよい。
- 追加の情報が、OP_RETURNに含められ得る。
- IP: これは、実際にライセンスを付与されているIPの生データである。その除外の理由は、プライバシーの問題または空間の節約の問題に関する場合がある。生のIP(またはLA)自体がブロックチェーン150上に存在しない場合、望ましいとみなされるように、生のファイルが「オフライン」でアクセス可能であることが期待される。
- e(IP): ブロックチェーン150上でIP自体を公開したくない場合、その代わりに、暗号化されたバージョンe(IP)がブロックチェーン150に置かれてよい。誰がIPを復号することができるかについては、制限が課される。
- LA: IPを律する生のライセンス契約(Licensing Agreement)も、トランザクションに含められ得る。
- e(LA): 好ましい場合、LAの暗号化されたバージョンが、ブロックチェーン150に含められてよい。
- 追加の情報が、OP_RETURNに含められ得る。
【0178】
第2の出力(アクティブ出力と呼ばれる)は、広告トランザクションの入力からのデジタル資産が「送信」される出力である。この出力を消費することは、著作権者の署名を必要とする。この署名は、σCA(TU)のように示され、σCAは、CAによって作成されたデジタル署名を表し、TU(更新トランザクション)は、署名されているものである。広告トランザクションは、デジタル資産を自分自身に割り振り、つまり、結果として、CAは、いつでも好きなときにその出力を割り振ることができる。これが存在することは、CAがLAを取り消すかまたは更新することを可能にする。(ライセンス付与サービスのすべての参加者による相互理解により)広告トランザクションの未使用出力(UTXO)をアクティブで有効なLAとして扱うことによって、CAは、アクティブ出力の出力を消費することによりトランザクションを取り消すかまたは更新することができる。単純な取消は、LAが参照されるIPに関してもはや有効とみなされないことを知らせる広告トランザクションの出力の消費である。更新は、CAがそのUTXOを新しい広告トランザクションへのCAの入力として利用する箇所であるのに対して、新しい広告トランザクションは、更新されたLA(H2(LAv2.0))を含むことを期待される。「更新」は、IPの既存のライセンス契約を取り消しかつ更新する。(そのようにする法的合意がない限り)CAによるLAの取消または更新は、LAのそのバージョンの以前の購入を自動的に行わないことに留意されたい。
【0179】
図7は、例示的な購入(または要求)トランザクションを示す。購入トランザクションTPは、IPの購入/ライセンス付与に関心のある者が、その購入に必要とされるデジタル資産を割り振るために利用するトランザクションである。購入トランザクションは、図7に示されるように、要求側の署名を含む少なくとも1つの入力を有する。このデジタル署名σBuy(TP)は、購入トランザクションに署名する。広告トランザクションと同様に、購入トランザクションは、トランザクション内のデータの記憶を必要とする。この例において、データは、OP_RETURNの出力に記憶される。データは、以下を含む。
- H2(IP): これは、購入されるIP/コモディティの二重ハッシュとして表現される、買い手が関心のあるIP/コモディティの一意識別子である。
- H2(LA): これは、関連するLAの二重ハッシュである。
- H2(Buy): これは、買い手の識別子の二重ハッシュである。IDは、買い手の公開鍵または任意のその他の正式な識別情報である可能性がある。
- H2(IP): これは、購入されるIP/コモディティの二重ハッシュとして表現される、買い手が関心のあるIP/コモディティの一意識別子である。
- H2(LA): これは、関連するLAの二重ハッシュである。
- H2(Buy): これは、買い手の識別子の二重ハッシュである。IDは、買い手の公開鍵または任意のその他の正式な識別情報である可能性がある。
【0180】
広告トランザクションと同様に、OP_RETURNのスクリプトは、購入識別子<Purchase ID>を含む。これは、すべての既存のライセンシーまたはライセンサーに、これがIP/コモディティのライセンスの購入に対する関係者の正式な関心を表すトランザクションであることを知らせる公開された合意された識別子である。OP_RETURNのスクリプト内の別のアイテムは、図7に<Adv ID>として示される広告識別子である。これは、既存のまたは潜在的な利害関係者に、トランザクションがIPおよびそのLAのプロモーションおよび/または表現を表すことを知らせる目印として著作権者によって選択され、公開される識別子である。当事者は、これらの特殊な「広告」トランザクションを見つけるために、この識別子を含むトランザクションに関してブロックチェーン150を解析することができる。
【0181】
さらに、その他の種々雑多なおよび/または任意のデータが含まれる可能性がある。Adv Tr Refは、そのようなデータの例であり、関心のあるIPおよびそのLAをプロモーションしたまたは「収容した(housed)」ブロックチェーン広告トランザクションのハッシュである。含めるための適用可能であるが任意であるデータの別の例は、図において<Proof>として表された達成の証明(proof of accomplishment)である。ライセンスの獲得は、買い手が何かを達成したこと、たとえば、運転手がその運転免許試験に合格することを必要とする場合がある。証明は、達成を表す信頼できる外部の関係者によって作成された署名または証明書の形態である可能性がある。
【0182】
購入トランザクションの第2の出力は、買い手がIPのライセンスを付与されることを正式に確認するために成功裏に実行される必要があるスクリプトを含む。買い手は、スクリプトが成功裏に実行されるための2つの方法が存在するようにこのスクリプトを構築する。
【0183】
第1の方法(方法A)は、(CAであることが予想される)出力によってロックされたデジタル資産の成功した割り振る者がCAの署名、IPのハッシュ(H(IP))、ライセンス契約のハッシュ(H(LA))、および買い手の識別子のハッシュ(H(Buy))を提供しなければならない方法である。CAが消費スクリプトにこれらの4つのデータを含めるならば、これは、CAがその特定の個人/機関に、LAの規定された条項および条件の下で、規定されたIPのライセンスを付与することの正式な確認として働く。
【0184】
第2の方法(方法B)は、CAと買い手との両方の署名を必要とする。この方法の目的は、返金トランザクションの使用を組み込む可能性のためである。返金トランザクションは、たとえば、所与の時間が経過した後、買い手がコミットされた(committed)デジタル資産を自分自身に戻してよいトランザクションである。買い手は、買い手がブロックチェーン150に購入トランザクションを提出する前に、返金トランザクションが少なくともCAによって署名されることを保証する。
【0185】
このトランザクションTPの重要性は、その消費可能な出力が、ライセンス契約(またはそのそれぞれのハッシュ)を提供しなければならない買い手によって満たされるべき二者間ハッシュパズル合意(BHPA)を設定することである。事実上、このトランザクションは、ライセンサー(CA)が契約の条項を承諾することの証明を提供するBHPAの「第1の側面」である。
【0186】
図8は、例示的な確認トランザクションを示す。確認トランザクションは、CAが買い手にIPのライセンスを確かに付与していることをCAが確認するトランザクションである。確認トランザクションは、購入トランザクションの実行可能な出力を成功裏に消費することによってこれを確認する。これは、CAが自分の署名σCA(TC)、IPのハッシュH(IP)、ライセンス契約のハッシュH(LA)、および買い手のIDのハッシュH(Buy)を提供することを要求する。CAは、任意の入ってくるデジタル資産がどこに割り振られるかを判断する。
【0187】
広告トランザクションおよび購入トランザクションと同様に、確認トランザクションは、トランザクションがBLPの確認トランザクションであることを当事者に示す、<Conf ID>とラベル付けされた識別子を含んでよい。さらに、IP/コモディティがデジタルであり、暗号化によって保護される場合があるシナリオにおいて、CAは、この時点で買い手に復号鍵を提供してよい。特定の実装においては、(i)暗号化されたデータ、(ii)暗号化/復号鍵のどちらかまたは両方をブロックチェーンに記憶することが望ましい場合もあり、それらの位置が、BLPのトランザクションによって参照される場合もある。
【0188】
取消がBLPに組み込まれている場合、確認トランザクションの実行可能な出力が割り振られていないことが、ライセンスがまだアクティブであることを示す場合がある。出力が割り振られていない場合、ライセンスは、アクティブであると解釈される。一部の実装は、確認トランザクションの実行可能な出力を消費する際にCAに単独の権限を与える場合があるが、場合によっては、関係者は、買い手のライセンスを取り消すために複数の関係者の署名が必要であることが適切と考える可能性がある。これらの追加の署名は、図8においては署名σCA2(T*)によって表され、T*は、TCの消費可能な出力を消費する後続のトランザクションを表す。
【0189】
このトランザクションTCの重要性は、その入力がライセンス契約かまたはそのハッシュかのどちらかを提供することによってBHPAを満たすことである。事実上、これは、買い手が契約の条項を承諾することの証明を提供するBHPAの「第2の側面」である。
【0190】
図9は、例示的な更新トランザクションを示す。更新トランザクションは、2つの機能を提供するために使用され、ライセンス契約の非推奨または使われなくなった以前のバージョンを取り消すために使用されることが可能であり、以前のバージョンを置き換えるための契約の更新されたバージョン(LAv2.0)を確立するために使用されることも可能である。更新トランザクションは、主に、更新トランザクションが前の広告トランザクションの実行可能な出力のロックを解除するという事実によって特徴付けられる。更新トランザクションは、CAによって署名される(更新トランザクションの)入力が前の広告/更新トランザクションの「実行可能な」出力からのものであるという重要な特徴を持つ広告トランザクションのバージョンと解釈され得る。
【0191】
図10は、例示的な返金トランザクションを示す。返金トランザクションは、購入トランザクションからの資金を買い手に返金するトランザクションである。これは、CAが指定された時間の前にライセンスを確認または付与する(すなわち、購入トランザクションの実行可能な出力を消費すること)に失敗する場合である。この時間が経過した場合、返金トランザクションは、ブロックチェーン150に成功裏に提出され得る。返金トランザクションの正常な提出に対する時間制限は、ブロックチェーントランザクションのnLockTimeフィールドに値sを割り振ることによって有効化される場合がある。nLockTimeは、指定された時間が経過した後にのみトランザクションが実行可能になることを可能にするトランザクションパラメータである。値sは、絶対値であり、UNIX時間またはブロックの高さで指定される。
【0192】
図示されていないが、BLPの設計に含まれてよい第6のトランザクションは、取消トランザクションTRのトランザクションである。このトランザクションは、IP管理者または規制当局が、以前に買い手に付与されたライセンスを撤回する必要があると考える場合に利用される。このライセンスの取消の必要性は、所定の期間が経過したこと、または買い手がLAによって指定された条項および契約の1つもしくは複数の点に違反したことが原因である場合がある。
【0193】
取消は、様々な方法で果たされる場合がある。実施の例は、確認トランザクションの出力が、ライセンスが取り消されたか否かを表すために利用される例である。規定された出力が消費される場合、買い手のライセンスは、取り消されたとみなされる。出力が消費されないままである場合、ライセンスは、有効であるとみなされる。この手法においては、確認トランザクションを作成し、署名するCAが、公正に失効を判断することを委ねられる。失効の信頼性をさらに高めるために、出力の割り振りは、その他の信頼できる当局または規制機関からの署名を必要とするように設計されてよい。
【0194】
図5は、ブロックチェーンライセンス付与プロトコルの基本となるシステムの基礎を形成する上述の5つの主要なトランザクションと、これらのトランザクションがリンクされる方法とを示す。縞模様ある四角は、データを含むOP_RETURNの出力である。実線の矢印は、出力の割り振りを示す。トランザクションの左側の四角は入力であり、右側の四角は出力である。時計は、時間的にロックされたトランザクションを表し、LA'は、LAの更新されたバージョンである。
【0195】
図11は、BLPのための例示的なシーケンスを示す。示されるように、CAは、ブロックチェーン150に広告トランザクションを送信する。買い手は、LAに関心を示し、CAは、肯定的に応じ、たとえば、買い手にIPのライセンスを付与することに暫定的に同意する。それから、買い手は、購入トランザクションおよび返金トランザクションを作成する。買い手は、署名されていない返金トランザクションをCAに送信し、CAは、トランザクションに署名し、それを買い手に返す。署名された返金トランザクションを受信した後、買い手は、購入トランザクションをブロックチェーン150に提出する。CAは、ブロックチェーン150に確認トランザクションを送信することによって合意を確認する。あるいは、買い手は、署名された返金トランザクションをブロックチェーン150に送信することによって、IPのライセンスを付与する要求を取り消す可能性がある。CAが申し出られた合意を更新したい場合、CAは、ブロックチェーン150に更新を送信する。
【0196】
BLPのユースケース
上記の例は知的財産(IP)のライセンス付与へのその応用にはっきりと焦点を当てているが、ブロックチェーンライセンス付与プロトコル(BLP)は、様々な合意の種類のために使用されてよい。同じ技術の、すなわち、二者間ハッシュパズル合意(BHPA)、および特定のユースケースにカスタマイズされたトランザクションのセットを利用する多くのその他の潜在的な応用が存在する。そのようなユースケースは、以下を含んでよい。
・オンチェーンで直接IPのライセンスを付与すること、
・公開ライセンス(public license)の配布および管理、ならびに
・サプライチェーンの了承(supply chain acknowledgement)
上記の例は知的財産(IP)のライセンス付与へのその応用にはっきりと焦点を当てているが、ブロックチェーンライセンス付与プロトコル(BLP)は、様々な合意の種類のために使用されてよい。同じ技術の、すなわち、二者間ハッシュパズル合意(BHPA)、および特定のユースケースにカスタマイズされたトランザクションのセットを利用する多くのその他の潜在的な応用が存在する。そのようなユースケースは、以下を含んでよい。
・オンチェーンで直接IPのライセンスを付与すること、
・公開ライセンス(public license)の配布および管理、ならびに
・サプライチェーンの了承(supply chain acknowledgement)
【0197】
オンチェーンでのIPのライセンス付与
BLPのユースケースは、それら自体がクリエイターの知的財産であるデジタルコンテンツおよびメディアの独立したクリエイターがブロックチェーン150を使用してそれらのクリエイターの作品のライセンスを付与することである。BLPを使用するここでの重要な利点は、ブロックチェーン自体のネイティブのデジタル資産インフラストラクチャを使用して直接収益化され得るデジタルコンテンツのための独自のライセンス契約をクリエイターが確立することを可能にすることである。たとえば、BLPを利用して自身の楽曲のライセンスを付与したい音楽アーティストのAliceが行う場合があるステップを考える。
1. 楽曲(IP)を作成し、ブロックチェーン上でそれを一意に表現する。
2. Aliceの楽曲を使用するためのLAを定義し、これは、個々の曲またはアルバムのレベルまでのより詳細な契約をともなう場合がある。これらの契約は、Aliceの楽曲の異なる種類の使用に関して異なる条件を定義してよい。
3. BLPを使用してオンチェーンでLAを確立する。
4. リスナー(listener)が、個々の場合に応じて、Aliceの楽曲を聞く/再利用する/配信するためのライセンスを購入する。
BLPのユースケースは、それら自体がクリエイターの知的財産であるデジタルコンテンツおよびメディアの独立したクリエイターがブロックチェーン150を使用してそれらのクリエイターの作品のライセンスを付与することである。BLPを使用するここでの重要な利点は、ブロックチェーン自体のネイティブのデジタル資産インフラストラクチャを使用して直接収益化され得るデジタルコンテンツのための独自のライセンス契約をクリエイターが確立することを可能にすることである。たとえば、BLPを利用して自身の楽曲のライセンスを付与したい音楽アーティストのAliceが行う場合があるステップを考える。
1. 楽曲(IP)を作成し、ブロックチェーン上でそれを一意に表現する。
2. Aliceの楽曲を使用するためのLAを定義し、これは、個々の曲またはアルバムのレベルまでのより詳細な契約をともなう場合がある。これらの契約は、Aliceの楽曲の異なる種類の使用に関して異なる条件を定義してよい。
3. BLPを使用してオンチェーンでLAを確立する。
4. リスナー(listener)が、個々の場合に応じて、Aliceの楽曲を聞く/再利用する/配信するためのライセンスを購入する。
【0198】
Aliceは、ユーザ(すなわち、ライセンシー)との合意に至るプロセスを第三者が仲介することを要求せず、その理由は、これがBLPのBHPAの態様を利用して施行され、それが両者の承諾のデジタル署名された証明をさらに残すからである。このユースケースの利点は、BHPAにおける承諾の証明が、個々のユーザへの楽曲のライセンス付与に関連するデジタル資産の移動に結びつけられており、それが、ユーザがサービス/利用規約に同意すると直ちにAliceが支払いを受けることを可能にすることである。これは、長期間のサブスクリプションを約束しなければならないのではなく、LAの詳細に応じて曲ごとにまたは聞く度に少額のマイクロペイメントを使用して細かくコンテンツに対する支払いが可能であるというユーザにとっての利点も有する。
【0199】
規制ライセンスの配布
BLPのメカニズムは、規制当局または政府機関によって付与するライセンスの定義、発行、および処理に特に適している可能性もある。そのようなライセンスは、テレビライセンス、アルコールを提供するライセンス、または特定の種類の車両を運転するライセンスを含む場合がある。BLPは、これらのライセンスに通常必要とされる発行、購入、更新、および取消の必要な機能を提供する。この場合、問題にしているライセンスが、規制機関(ライセンサー)がユーザまたは会社(ライセンシー)に特定の商品、サービス、および活動を使用するかまたは提供するかのどちらかを行う権限を付与することに関連付けられるので、BLPを「知的財産」に結びつける必要はない可能性がある。
BLPのメカニズムは、規制当局または政府機関によって付与するライセンスの定義、発行、および処理に特に適している可能性もある。そのようなライセンスは、テレビライセンス、アルコールを提供するライセンス、または特定の種類の車両を運転するライセンスを含む場合がある。BLPは、これらのライセンスに通常必要とされる発行、購入、更新、および取消の必要な機能を提供する。この場合、問題にしているライセンスが、規制機関(ライセンサー)がユーザまたは会社(ライセンシー)に特定の商品、サービス、および活動を使用するかまたは提供するかのどちらかを行う権限を付与することに関連付けられるので、BLPを「知的財産」に結びつける必要はない可能性がある。
【0200】
サプライチェーンの了承
BLPと、特にシステムの基盤となるBHPAとの潜在的な拡大された応用は、複雑なサプライチェーンで使用するためのものである。ここでの概念は、BHPAによって提供される承諾の証明が、サプライチェーンにおける「了承の証明(proof of acknowledgement)」として使用されることになることである。サプライチェーンの文脈において、了承の証明は、そのサプライチェーンの所与の利害関係者または参加者が、特定の価値、またはその利害関係者もしくは参加者が特定のタスクを実行するべきであるという通知を受け取ったときに、自身の責任を了承したことの証明である。このシナリオにおけるBHPAの使用は、指示または商品を受け取る利害関係者と、指示または商品を与えるサプライチェーンの利害関係者との両者が、これが発生する状況に同意するという証拠を提供するので有利である。これは、サプライチェーンにおける利害関係者の合意を証拠立てることに似ている。BLPは、標準的な利害関係者の合意を、ブロックチェーンを使用してこれらの合意のすべてが証明可能であるようにして証拠立てられ、一緒にリンクされることを保証することによってこれらの合意が「オンザフライ」で作成され、受け入れられることを可能にすることにより改善する。
BLPと、特にシステムの基盤となるBHPAとの潜在的な拡大された応用は、複雑なサプライチェーンで使用するためのものである。ここでの概念は、BHPAによって提供される承諾の証明が、サプライチェーンにおける「了承の証明(proof of acknowledgement)」として使用されることになることである。サプライチェーンの文脈において、了承の証明は、そのサプライチェーンの所与の利害関係者または参加者が、特定の価値、またはその利害関係者もしくは参加者が特定のタスクを実行するべきであるという通知を受け取ったときに、自身の責任を了承したことの証明である。このシナリオにおけるBHPAの使用は、指示または商品を受け取る利害関係者と、指示または商品を与えるサプライチェーンの利害関係者との両者が、これが発生する状況に同意するという証拠を提供するので有利である。これは、サプライチェーンにおける利害関係者の合意を証拠立てることに似ている。BLPは、標準的な利害関係者の合意を、ブロックチェーンを使用してこれらの合意のすべてが証明可能であるようにして証拠立てられ、一緒にリンクされることを保証することによってこれらの合意が「オンザフライ」で作成され、受け入れられることを可能にすることにより改善する。
【0201】
サプライチェーンの場合にBLPを実装する際は、BLPトランザクションの複数のそのようなセットを一緒に連結して、サプライチェーン自体を模倣することが望ましい場合がある。単純に利害関係者間の特定の合意に関連するBLPトランザクションの1つのセットを次のセットに接続することは、トランザクション間の消費のリンクを強制することによって実現され得る。
【0202】
結論
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
【0203】
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104の観点で説明された。しかし、ビットコインブロックチェーンは、ブロックチェーン150の1つの特定の例であり、上の説明は、任意のブロックチェーンに広く当てはまる可能性があることが理解されるであろう。すなわち、本発明は、ビットコインブロックチェーンに決して限定されない。より広く、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のすべての言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104への言及に置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された特性の一部またはすべてを共有する場合がある。
【0204】
本発明の好ましい実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークであり、ビットコインノード104が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。これらの機能のうちの1つまたは一部だけを実行するが、すべては実行しないその他のネットワークエンティティ(またはネットワーク要素)が存在する可能性があることは、排除されない。すなわち、ネットワークエンティティが、ブロックを作成および公開することなく、ブロックを伝播および/または記憶する機能を実行する場合がある(これらのエンティティは、好ましいビットコインネットワーク106のノードとはみなされないことを思い出されたい)。
【0205】
本発明の好ましくない実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークはない可能性がある。これらの実施形態においては、ノードが、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたは一部を実行するが、すべては実行しない場合があることは排除されない。たとえば、それらのその他のブロックチェーンネットワーク上で、「ノード」は、ブロック151を作成および公開するように構成されるが、それらのブロック151を記憶および/またはその他のノードに伝播するように構成されないネットワークエンティティを指すために使用される場合がある。
【0206】
さらに一層広く、上記の用語「ビットコインノード」104へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックの作成し、発行し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関連して上で説明された同じ方法でハードウェアに実装されてよい。
【0207】
上記の実施形態は、例としてだけ説明されたことが理解されるであろう。より広く、以下のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供されてよい。
【0208】
ステートメント1.
要求側と確認側との間の合意をブロックチェーンに記録するコンピュータによって実施される方法であって、要求側によって実行され、
要求トランザクションを生成するステップであって、要求トランザクションが、要求側によって署名された入力、および少なくとも、要求側と確認側との両者に知られている第1のデータアイテムに基づく暗号パズルを含む第1の出力を含み、第1のデータアイテムが、合意を表す、ステップと、
要求トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法。
要求側と確認側との間の合意をブロックチェーンに記録するコンピュータによって実施される方法であって、要求側によって実行され、
要求トランザクションを生成するステップであって、要求トランザクションが、要求側によって署名された入力、および少なくとも、要求側と確認側との両者に知られている第1のデータアイテムに基づく暗号パズルを含む第1の出力を含み、第1のデータアイテムが、合意を表す、ステップと、
要求トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法。
【0209】
前記送信させるステップは、要求トランザクションをブロックチェーンノードに直接、またはブロックチェーンノードに転送するための別の関係者(たとえば、確認側)に送信することを含んでよい。
【0210】
一部の実施形態において、入力が第1の出力のロックを解除するための少なくとも1つの条件は、入力がデータアイテムを含まなければならないことである。
【0211】
概して、第1のデータアイテムによって表される合意は、要求側と確認側との間の任意の契約、条約、盟約、協定、商取引、和解、取り決め、誓約、同盟、販売などであってよい。しかし、合意は、公開鍵ではない。
【0212】
ステートメント2.
第1のデータアイテムが、合意を含むか、または第1のデータアイテムが、少なくとも合意のハッシュを含むステートメント1の方法。
第1のデータアイテムが、合意を含むか、または第1のデータアイテムが、少なくとも合意のハッシュを含むステートメント1の方法。
【0213】
ステートメント3.
第1の出力が、要求側と確認側との両者に知られている第2のデータアイテムに基づく第2の暗号パズルを含み、第2のデータアイテムが、要求側の識別子を表すステートメント1またはステートメント2の方法。
第1の出力が、要求側と確認側との両者に知られている第2のデータアイテムに基づく第2の暗号パズルを含み、第2のデータアイテムが、要求側の識別子を表すステートメント1またはステートメント2の方法。
【0214】
第2のデータアイテムは、識別子を含む場合があり、または第2のデータアイテムは、識別子のハッシュを含む場合がある。
【0215】
ステートメント4.
要求トランザクションが、1つまたは複数の追加のデータアイテムを含み、1つまたは複数の追加のデータアイテムが、
合意の二重ハッシュ、
要求側の識別子の二重ハッシュ、
要求トランザクションが合意の要求を表すことを示すインジケータ、および
広告トランザクションが合意の広告を表すことを示すインジケータを含む広告トランザクションへの参照
のうちの1つ、いくつか、またはすべてを含むいずれかの前述のステートメントの方法。
要求トランザクションが、1つまたは複数の追加のデータアイテムを含み、1つまたは複数の追加のデータアイテムが、
合意の二重ハッシュ、
要求側の識別子の二重ハッシュ、
要求トランザクションが合意の要求を表すことを示すインジケータ、および
広告トランザクションが合意の広告を表すことを示すインジケータを含む広告トランザクションへの参照
のうちの1つ、いくつか、またはすべてを含むいずれかの前述のステートメントの方法。
【0216】
ステートメント5.
要求トランザクションが、追加のデータアイテムのうちの1つ、いくつか、またはすべてを含む第2の出力を含むステートメント4の方法。
要求トランザクションが、追加のデータアイテムのうちの1つ、いくつか、またはすべてを含む第2の出力を含むステートメント4の方法。
【0217】
第2の出力は、消費不可能な出力である場合がある。
【0218】
ステートメント6.
第1の出力が、返金トランザクションの入力が要求側および/または確認側に関連するそれぞれの署名を含むことを条件として返金トランザクションの入力によってロックを解除されるように構成されるいずれかの前述のステートメントの方法。
第1の出力が、返金トランザクションの入力が要求側および/または確認側に関連するそれぞれの署名を含むことを条件として返金トランザクションの入力によってロックを解除されるように構成されるいずれかの前述のステートメントの方法。
【0219】
ステートメント7.
第1の出力が、複数署名ロックスクリプトを含むステートメント6の方法。
第1の出力が、複数署名ロックスクリプトを含むステートメント6の方法。
【0220】
ステートメント8.
返金トランザクションを取得するステップであって、返金トランザクションが、要求トランザクションの第1の出力を参照し、要求側および/または確認側に関連するそれぞれの署名を含む入力を含み、返金トランザクションが、要求側にロックされた出力を含む、ステップと、
返金トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント6またはステートメント7の方法。
返金トランザクションを取得するステップであって、返金トランザクションが、要求トランザクションの第1の出力を参照し、要求側および/または確認側に関連するそれぞれの署名を含む入力を含み、返金トランザクションが、要求側にロックされた出力を含む、ステップと、
返金トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント6またはステートメント7の方法。
【0221】
たとえば、返金トランザクションの出力は、要求側の公開鍵にロックされてよい。
【0222】
ステートメント9.
返金トランザクションの署名されていないバージョンを生成するステップと、
返金トランザクションの署名されていないバージョンを確認側に送信するステップとを含むステートメント8の方法。
返金トランザクションの署名されていないバージョンを生成するステップと、
返金トランザクションの署名されていないバージョンを確認側に送信するステップとを含むステートメント8の方法。
【0223】
ステートメント10.
前記返金トランザクションを取得するステップが、
確認側に関連するそれぞれの署名を含む入力を含む返金トランザクションのバージョンを受信することと、
要求側に関連するそれぞれの署名を用いて入力に署名することとを含むステートメント9の方法。
前記返金トランザクションを取得するステップが、
確認側に関連するそれぞれの署名を含む入力を含む返金トランザクションのバージョンを受信することと、
要求側に関連するそれぞれの署名を用いて入力に署名することとを含むステートメント9の方法。
【0224】
ステートメント11.
返金トランザクションが、指定された時間が過ぎる前に返金トランザクションがブロックチェーン上で公開されることを防止するように構成された時間制限を含むステートメント8から10のいずれかの方法。
返金トランザクションが、指定された時間が過ぎる前に返金トランザクションがブロックチェーン上で公開されることを防止するように構成された時間制限を含むステートメント8から10のいずれかの方法。
【0225】
指定された時間は、たとえば、UNIX時間やブロックの高さで測定される場合がある。
【0226】
ステートメント12.
要求トランザクションの第1の出力が、ロックスクリプトに、セパレータオペコード、それに続く第1のデータアイテムに基づく暗号パズル、それに続く署名チェックオペコードを含むいずれかの前述のステートメントの方法。
要求トランザクションの第1の出力が、ロックスクリプトに、セパレータオペコード、それに続く第1のデータアイテムに基づく暗号パズル、それに続く署名チェックオペコードを含むいずれかの前述のステートメントの方法。
【0227】
たとえば、セパレータオペコードは、OP_CODESEPERATORであってよく、署名チェックオペコードは、OP_CHECKSIGであってよい。暗号パズルだけでないさらなるデータが、セパレータオペコードの後に含まれてよいことに留意されたい。暗号パズルは、必ずしもセパレータオペコードの直後である必要はなく、署名チェックオペコードの直前である必要もない。同様に、確認側によって署名される必要がないいくつかのデータが、セパレータオペコードの前に含まれる場合がある。言い換えると、確認側がロックスクリプトのすべてに署名する必要がないという望ましい効果を得るためには、署名されていないデータが、OP_CODESEPARATORの前になければならない。
【0228】
ステートメント13.
暗号パズルが、一方向性関数を含むいずれかの前述のステートメントの方法。
暗号パズルが、一方向性関数を含むいずれかの前述のステートメントの方法。
【0229】
ステートメント14.
暗号パズルが、ハッシュパズル、プライベート鍵パズル、またはrパズルのうちの1つを含むいずれかの前述のステートメントの方法。
暗号パズルが、ハッシュパズル、プライベート鍵パズル、またはrパズルのうちの1つを含むいずれかの前述のステートメントの方法。
【0230】
一部の例において、第2の暗号パズルは、ハッシュパズル、プライベート鍵パズル、またはrパズルのうちの1つを含んでよい。第1の暗号パズルおよび第2の暗号パズルは、同じ種類のパズルまたは異なる種類のパズルを含んでよい。
【0231】
ステートメント15.
ブロックチェーンを使用して要求側と確認側との間の合意を記録するコンピュータによって実施される方法であって、確認側によって実行され、
確認トランザクションを生成するステップであって、確認トランザクションが、要求トランザクションの出力を参照する入力を含み、要求トランザクションの出力が、要求側と確認側との両者に知られており、合意を表す第1のデータアイテムに基づく暗号パズルを含み、確認トランザクションの入力が、第1のデータアイテムを含む、ステップと、
確認トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法。
ブロックチェーンを使用して要求側と確認側との間の合意を記録するコンピュータによって実施される方法であって、確認側によって実行され、
確認トランザクションを生成するステップであって、確認トランザクションが、要求トランザクションの出力を参照する入力を含み、要求トランザクションの出力が、要求側と確認側との両者に知られており、合意を表す第1のデータアイテムに基づく暗号パズルを含み、確認トランザクションの入力が、第1のデータアイテムを含む、ステップと、
確認トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含む、コンピュータによって実施される方法。
【0232】
前記送信させるステップは、確認トランザクションをブロックチェーンノードに直接、またはブロックチェーンノードに転送するための別の関係者(たとえば、要求側)に送信することを含んでよい。
【0233】
ステートメント16.
確認トランザクションの入力が、確認側に関連する署名を含むステートメント15の方法。
確認トランザクションの入力が、確認側に関連する署名を含むステートメント15の方法。
【0234】
ステートメント17.
要求トランザクションの第1の出力が、ロックスクリプトに、セパレータオペコード、それに続く第1のデータアイテムに基づく暗号パズル、それに続く署名チェックオペコードを含み、確認側に関連する署名が、セパレータオペコードの後に位置するデータのみに署名するように構成されるステートメント16の方法。
要求トランザクションの第1の出力が、ロックスクリプトに、セパレータオペコード、それに続く第1のデータアイテムに基づく暗号パズル、それに続く署名チェックオペコードを含み、確認側に関連する署名が、セパレータオペコードの後に位置するデータのみに署名するように構成されるステートメント16の方法。
【0235】
署名チェックオペコード、たとえば、OP_CHECKSIGは、第2のトランザクションの入力の署名が、第2のトランザクションの入力によって参照される第1のトランザクションの出力に含まれる公開鍵に対応するプライベート鍵を使用してメッセージに署名したことをチェックする(すなわち、検証する)ように構成されてよいことに留意されたい。
【0236】
ステートメント18.
要求トランザクションの出力が、要求側と確認側との両者に知られており、要求側の識別子を表す第2のデータアイテムに基づく暗号パズルを含み、確認トランザクションの入力が、第2のデータアイテムを含むステートメント16またはステートメント17の方法。
要求トランザクションの出力が、要求側と確認側との両者に知られており、要求側の識別子を表す第2のデータアイテムに基づく暗号パズルを含み、確認トランザクションの入力が、第2のデータアイテムを含むステートメント16またはステートメント17の方法。
【0237】
ステートメント19.
確認トランザクションが、確認側にロックされた出力を含むステートメント15から18のいずれかの方法。
確認トランザクションが、確認側にロックされた出力を含むステートメント15から18のいずれかの方法。
【0238】
確認トランザクションの出力は、確認側に関連する公開鍵にロックされてよい。
【0239】
ステートメント20.
取消トランザクションを生成するステップであって、取消トランザクションが、確認トランザクションの出力のロックを解除するように構成された入力を含む、ステップと、
取消トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント19の方法。
取消トランザクションを生成するステップであって、取消トランザクションが、確認トランザクションの出力のロックを解除するように構成された入力を含む、ステップと、
取消トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント19の方法。
【0240】
取消トランザクションの入力は、確認側に関連する署名を含んでよい。
【0241】
ステートメント21.
広告トランザクションを生成するステップであって、広告トランザクションが、少なくとも、確認側によって署名された第1の入力、ならびに少なくとも、合意の表現および合意の暗号化されたバージョンの一方または両方を含む第1の出力を含む、ステップと、
広告トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント15から20のいずれかの方法。
広告トランザクションを生成するステップであって、広告トランザクションが、少なくとも、確認側によって署名された第1の入力、ならびに少なくとも、合意の表現および合意の暗号化されたバージョンの一方または両方を含む第1の出力を含む、ステップと、
広告トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント15から20のいずれかの方法。
【0242】
第1の出力は、消費不可能な出力である場合がある。
【0243】
ステートメント22.
合意の表現が、合意のハッシュを含み、または合意の表現が、合意の二重ハッシュを含むステートメント21の方法。
合意の表現が、合意のハッシュを含み、または合意の表現が、合意の二重ハッシュを含むステートメント21の方法。
【0244】
ステートメント23.
第1の出力が、広告トランザクションが合意の広告であることを示すインジケータを含むステートメント21またはステートメント22の方法。
第1の出力が、広告トランザクションが合意の広告であることを示すインジケータを含むステートメント21またはステートメント22の方法。
【0245】
ステートメント24.
広告トランザクションが、1つまたは複数の追加の入力を含み、それぞれの追加の入力が、異なる関係者によって署名されるステートメント21から23のいずれかの方法。
広告トランザクションが、1つまたは複数の追加の入力を含み、それぞれの追加の入力が、異なる関係者によって署名されるステートメント21から23のいずれかの方法。
【0246】
ステートメント25.
広告トランザクションが、確認側にロックされた第2の出力を含むステートメント21から24のいずれかの方法。
広告トランザクションが、確認側にロックされた第2の出力を含むステートメント21から24のいずれかの方法。
【0247】
広告トランザクションの第2の出力は、確認側に関連する公開鍵にロックされてよい。第2の出力は、第1の出力と比較して、異なる出力である可能性があり、または異なる出力でない可能性がある。
【0248】
ステートメント26.
更新トランザクションを生成するステップであって、更新トランザクションが、広告トランザクションの第2の出力のロックを解除するように構成された入力、ならびに少なくとも、更新された合意の表現および更新された合意の暗号化されたバージョンの一方または両方を含む第1の出力を含む、ステップと、
更新トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント25の方法。
更新トランザクションを生成するステップであって、更新トランザクションが、広告トランザクションの第2の出力のロックを解除するように構成された入力、ならびに少なくとも、更新された合意の表現および更新された合意の暗号化されたバージョンの一方または両方を含む第1の出力を含む、ステップと、
更新トランザクションが1つまたは複数のブロックチェーンノードに送信されるようにするステップとを含むステートメント25の方法。
【0249】
ステートメント27.
合意が、ライセンス契約、たとえば、知的財産に関するライセンス契約であるいずれかの前述のステートメントの方法。
合意が、ライセンス契約、たとえば、知的財産に関するライセンス契約であるいずれかの前述のステートメントの方法。
【0250】
ステートメント28.
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、メモリが、処理装置上で実行されるように配置されたコードを記憶し、コードが、処理装置上にあるときに、ステートメント1から27のいずれかの方法を実行するように構成される、処理装置とを含むコンピュータ機器。
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、メモリが、処理装置上で実行されるように配置されたコードを記憶し、コードが、処理装置上にあるときに、ステートメント1から27のいずれかの方法を実行するように構成される、処理装置とを含むコンピュータ機器。
【0251】
ステートメント29.
コンピュータ可読ストレージ上に具現化され、コンピュータ機器上で実行されるときに、ステートメント1から27のいずれかの方法を実行するように構成されたコンピュータプログラム。
コンピュータ可読ストレージ上に具現化され、コンピュータ機器上で実行されるときに、ステートメント1から27のいずれかの方法を実行するように構成されたコンピュータプログラム。
【0252】
本明細書において開示された別の態様によれば、要求側および確認側のアクションを含む方法が提供される可能性がある。
【0253】
本明細書において開示された別の態様によれば、要求側および確認側のコンピュータ機器を含むシステムが提供される可能性がある。
【符号の説明】
【0254】
100 システム
101 パケット交換ネットワーク
102 コンピュータ端末、コンピュータ機器、機器
102a コンピュータ機器
102b コンピュータ機器
103 ユーザ、エージェント、関係者
103a ユーザ、第1の関係者
103b 新しいユーザまたはエンティティ、第2の関係者
104 ブロックチェーンノード、ビットコインノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、ビットコインネットワーク、ブロックチェーンネットワーク
107 サイドチャネル
150 ブロックチェーン、ビットコインブロックチェーン
151 データのブロック
152 トランザクション
152i 先行トランザクション
152j 現在のトランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット
155 ブロックポインタ
201 ヘッダ
202 入力
203 出力
400 システム
401 トランザクションエンジン、要求側
402 ユーザインターフェース(UI)レイヤ、確認側
403 機能
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素
101 パケット交換ネットワーク
102 コンピュータ端末、コンピュータ機器、機器
102a コンピュータ機器
102b コンピュータ機器
103 ユーザ、エージェント、関係者
103a ユーザ、第1の関係者
103b 新しいユーザまたはエンティティ、第2の関係者
104 ブロックチェーンノード、ビットコインノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、ビットコインネットワーク、ブロックチェーンネットワーク
107 サイドチャネル
150 ブロックチェーン、ビットコインブロックチェーン
151 データのブロック
152 トランザクション
152i 先行トランザクション
152j 現在のトランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット
155 ブロックポインタ
201 ヘッダ
202 入力
203 出力
400 システム
401 トランザクションエンジン、要求側
402 ユーザインターフェース(UI)レイヤ、確認側
403 機能
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【国際調査報告】