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

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

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

特表2024-525888ブロックチェーントランザクションに対する条件の強制
<>
  • 特表-ブロックチェーントランザクションに対する条件の強制 図1
  • 特表-ブロックチェーントランザクションに対する条件の強制 図2
  • 特表-ブロックチェーントランザクションに対する条件の強制 図3A
  • 特表-ブロックチェーントランザクションに対する条件の強制 図3B
  • 特表-ブロックチェーントランザクションに対する条件の強制 図4
  • 特表-ブロックチェーントランザクションに対する条件の強制 図5
  • 特表-ブロックチェーントランザクションに対する条件の強制 図6
  • 特表-ブロックチェーントランザクションに対する条件の強制 図7
  • 特表-ブロックチェーントランザクションに対する条件の強制 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-07-12
(54)【発明の名称】ブロックチェーントランザクションに対する条件の強制
(51)【国際特許分類】
   H04L 9/32 20060101AFI20240705BHJP
【FI】
H04L9/32 200Z
H04L9/32 200B
H04L9/32 200E
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024503453
(86)(22)【出願日】2022-06-20
(85)【翻訳文提出日】2024-03-08
(86)【国際出願番号】 EP2022066649
(87)【国際公開番号】W WO2023001461
(87)【国際公開日】2023-01-26
(31)【優先権主張番号】2110348.6
(32)【優先日】2021-07-19
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ウェイ・ジャン
(57)【要約】
第1のブロックチェーントランザクションを使用して第2のブロックチェーントランザクションに対して条件を強制するコンピュータ実施方法であって、条件のうちの第1の条件が、第2のトランザクションの第1のロック解除スクリプトが第1のトランザクションの第1のロックスクリプトとともに実行されるときに、第2のトランザクションの表現がメモリに出力されることであり、表現が、第2のトランザクションの複数のフィールドおよび第1のトランザクションの第1の出力に基づき、方法が、第1のトランザクションを生成するステップであって、第1のトランザクションが、第1の出力を含み、第1の出力が、第1のロックスクリプトを含み、第1のロックスクリプトが、メッセージサブスクリプト、署名サブスクリプト、プライベート鍵に対応する公開鍵、および検証サブスクリプトを含む、ステップを含む、コンピュータ実施方法。
【特許請求の範囲】
【請求項1】
第1のブロックチェーントランザクションを使用して第2のブロックチェーントランザクションに対して条件を強制するコンピュータ実施方法であって、前記条件のうちの第1の条件が、前記第2のトランザクションの第1のロック解除スクリプトが前記第1のトランザクションの第1のロックスクリプトとともに実行されるときに、前記第2のトランザクションの表現がメモリに出力されることであり、前記表現が、前記第2のトランザクションの複数のフィールドおよび前記第1のトランザクションの第1の出力に基づき、前記方法が、
前記第1のトランザクションを生成するステップであって、前記第1のトランザクションが、第1の出力を含み、前記第1の出力が、前記第1のロックスクリプトを含み、前記第1のロックスクリプトが、
実行されるときに、前記第2のトランザクションを表す候補メッセージをメモリに出力するように構成されたメッセージサブスクリプトであって、前記候補メッセージが、前記第1のトランザクションおよび前記第2のトランザクションの複数の候補フィールドに基づき、前記候補フィールドのうちの1つまたは複数が、前記第2のトランザクションの前記第1のロック解除スクリプトに含まれ、前記メッセージサブスクリプトが、前記候補フィールドのそれぞれのセットに基づいて前記候補メッセージの1つまたは複数のそれぞれの部分を生成し、前記候補メッセージの異なるそれぞれの部分として候補フィールドの前記それぞれのセットのうちの少なくとも1つを再利用するように構成される、メッセージサブスクリプトと、
実行されるときに署名を生成するように構成された署名サブスクリプトであって、前記署名が、少なくとも、前記候補メッセージ、プライベート鍵、および一時プライベート鍵の関数である、署名サブスクリプトと、
前記プライベート鍵に対応する公開鍵と、
実行されるときに、i)前記第2のトランザクションを表す目標メッセージを構築することであって、前記目標メッセージが、前記第2のトランザクションの複数のフィールドおよび前記第1のトランザクションの前記第1の出力に基づく、構築すること、ならびにii)前記公開鍵を使用して、前記署名が前記目標メッセージに有効であることを検証することであって、前記署名が前記目標メッセージに有効であることを検証することが、前記目標メッセージが前記候補メッセージと一致することを検証し、それによって、メモリに出力された前記候補メッセージが前記第2のトランザクションの前記表現であるという条件を強制する、検証することを行うように構成された検証サブスクリプトとを含む、ステップを含む、コンピュータ実施方法。
【請求項2】
前記候補メッセージの前記それぞれの部分のうちの1つが、前記第2のトランザクションの1つまたは複数の出力のハッシュを含み、
前記候補フィールドの第1のそれぞれのセットが、a)前記第1のトランザクションの前記第1のロックスクリプトのそれぞれの長さ、およびb)前記第1のトランザクションの前記第1のロックスクリプトを含み、
前記メッセージサブスクリプトが、実行されるときに、候補フィールドa)およびb)に基づいて前記1つまたは複数の出力の前記ハッシュを生成し、それによって、前記第2のトランザクションの第1の出力が前記第1のトランザクションの前記第1のロックスクリプトを含むという条件を強制するように構成される、請求項1に記載の方法。
【請求項3】
前記候補フィールドの前記第1のそれぞれのセットが、c)前記第1のトランザクションの前記第1のロックスクリプトによってロックされたそれぞれの値を含み、
前記メッセージサブスクリプトが、実行されるときに、候補フィールドa)、b)、およびc)に基づいて前記1つまたは複数の出力の前記ハッシュを生成し、それによって、前記第2のトランザクションの第1の出力が前記第1のトランザクションの前記第1の出力を含むという条件を強制するように構成される、請求項2に記載の方法。
【請求項4】
前記メッセージサブスクリプトが、前記候補メッセージの前記1つまたは複数のそれぞれの部分のうちの少なくとも1つを前記メモリに出力するように構成される、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記メッセージサブスクリプトが、実行されるときに、候補フィールドのうちの前記少なくとも1つまたは候補フィールドの前記それぞれのセットを、前記候補メッセージの前記異なるそれぞれの部分として再利用されるように前記候補メッセージの一部として複製するように構成される、請求項1から4のいずれか一項に記載の方法。
【請求項6】
前記第1のロックスクリプトが、実行されるときに前記署名を識別符号化規則DERフォーマットの署名に変換するように構成されたDERサブスクリプトを含み、前記公開鍵を使用して、前記署名が前記目標メッセージに有効であることを検証することが、前記公開鍵を使用して、前記DERフォーマットの署名が前記メッセージに有効であることを検証することを含む、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記署名サブスクリプトが、前記第2のトランザクションの前記複数のフィールドのうちのどれが前記目標メッセージの基礎を形成するべきかを指定する署名フラグを含み、前記検証サブスクリプトが、前記署名フラグに基づいて前記目標メッセージを構築するように構成される、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記署名フラグが、前記第2のトランザクションの各入力および各出力が前記目標メッセージの前記基礎を形成するべきであることを指定する、請求項7に記載の方法。
【請求項9】
前記署名フラグが、a)前記第2のトランザクションの前記第1のロック解除スクリプトを含む第1の入力と、b)前記第1の入力とペアにされる前記第2の第1の出力とが前記目標メッセージの前記基礎を形成するべきであることを指定する、請求項7に記載の方法。
【請求項10】
前記候補フィールドのうちの1つまたは複数が、前記第1のトランザクションの前記第1のロックスクリプトに含まれる、請求項1から9のいずれか一項に記載の方法。
【請求項11】
以下の候補フィールド、すなわち、
- 前記第2のトランザクションのバージョン番号、
- 前記第1のトランザクションの前記第1のロックスクリプトの長さ、
- 前記第1のトランザクションの前記第1のロックスクリプトの値、
- 前記第2のトランザクションの第1の入力のシーケンス番号、
- 前記第2のトランザクションのロック時間、
- 前記第2のトランザクションの前記第1のロック解除スクリプトの署名フラグ
のうちの1つまたは複数が、前記第1のトランザクションの前記第1のロックスクリプトに含まれる、請求項10に記載の方法。
【請求項12】
前記第2のトランザクションを表す前記候補メッセージが、前記第2のトランザクションの1つまたは複数のそれぞれの候補フィールドのそれぞれのセットに基づく1つまたは複数のそれぞれのデータ項目を含む、請求項1から11のいずれか一項に記載の方法。
【請求項13】
前記1つまたは複数のそれぞれのデータ項目が、
- 前記第2のトランザクションの入力シーケンス番号のハッシュ、
- 前記第2のトランザクションの組み合わされた出力のハッシュ
のうちの1つまたは複数を含む、請求項12に記載の方法。
【請求項14】
前記メモリが、スタックベースのメモリである、請求項1から13のいずれか一項に記載の方法。
【請求項15】
署名検証サブスクリプトが、OP_CHECKSIGVERIFYオペコードおよびOP_CHECKSIGオペコードの少なくとも一方を含む、請求項14に記載の方法。
【請求項16】
前記第1のトランザクションをブロックチェーンネットワークの1つまたは複数のノードに利用可能にするステップを含む、請求項1から15のいずれか一項に記載の方法。
【請求項17】
前記第1のトランザクションを、前記第2のトランザクションを生成するために関係者に利用可能にするステップを含む、請求項1から16のいずれか一項に記載の方法。
【請求項18】
前記一時プライベート鍵が、1に等しいものと前記第1のロックスクリプトによって決められ、および/または前記一時プライベート鍵が、前記プライベート鍵と等しいものと決められる、請求項1から17のいずれか一項に記載の方法。
【請求項19】
前記プライベート鍵が、1に等しいものと前記第1のロックスクリプトによって決められる、請求項18に記載の方法。
【請求項20】
前記署名が、s = k-1(z + ra) mod nの形態であり、kが、前記一時プライベート鍵であり、aが、前記プライベート鍵であり、zが、前記候補メッセージのハッシュであり、nが、楕円曲線の生成元Gの整数位数であり、rが、一時公開鍵のx座標のモジュロnである、請求項18または請求項19に記載の方法。
【請求項21】
前記署名が、s = z + Gx mod nの形態であり、Gxが、楕円曲線の生成元Gのx座標であり、Gが、一時公開鍵と前記公開鍵との両方である、請求項18または請求項18に従属する、請求項のいずれか一項に記載の方法。
【請求項22】
前記署名サブスクリプトが、Gxおよびnのそれぞれの値を含み、前記署名が、Gxおよびnの前記それぞれの値に基づいて生成される、請求項21に記載の方法。
【請求項23】
スタックベースのメモリが、主スタックおよび代替スタックを含み、前記第1のロックスクリプトが、Gxおよびnのそれぞれの値を2回以上使用するように構成され、前記第1のロックスクリプトが、実行されるときに、Gxおよびnの前記それぞれの値を前記代替スタックに出力し、初回以外にGxおよびnの前記それぞれの値が必要とされるたびに、Gxおよびnの前記それぞれの値を前記代替スタックから取得するように構成される、請求項21および請求項22に記載の方法。
【請求項24】
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、前記メモリが、前記処理装置上で実行されるように配置されたコードを記憶し、前記コードが、前記処理装置上にあるときに、請求項1から23のいずれか一項に記載の方法を実行するように構成される、処理装置とを含む、コンピュータ機器。
【請求項25】
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、請求項1から23のいずれか一項に記載の方法を実行するように構成された、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ブロックチェーントランザクションに対して条件を強制する方法に関する。より詳細には、第1のブロックチェーントランザクションが、第2の異なるブロックチェーントランザクションに対して1つまたは複数の条件を強制するために使用される。
【背景技術】
【0002】
ブロックチェーンは、分散型データ構造の形態を指し、分散型ピアツーピア(P2P)ネットワーク(以下、「ブロックチェーンネットワーク」と呼ばれる)の複数のノードの各々においてブロックチェーンの複製が維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックが、1つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションに戻る1つまたは複数のブロックに及ぶ可能性があるシーケンス内の先行トランザクションを後ろ向きに指し示す。コインベーストランザクションは、下でさらに検討される。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含められる。新しいブロックは、多くの場合「マイニング」と呼ばれるプロセスによって作成され、マイニングは、複数のノードの各々が「プルーフオブワーク」、すなわち、ブロックチェーンの新しいブロックに含められるのを待っている順序付けられた承認済みの保留トランザクションの定義されたセットの表現に基づく暗号パズルを解くことを競い合って実行することを含む。ブロックチェーンは一部のノードにおいて刈り込まれる場合があり、ブロックの公開は単なるブロックヘッダの公開によって実現され得ることに留意されたい。
【0003】
ブロックチェーンにおけるトランザクションは、以下の目的、すなわち、デジタル資産(すなわち、いくつかのデジタルトークン)の伝達、仮想台帳もしくはレジストリのエントリのセットの順序付け、タイムスタンプエントリの受信および処理、ならびに/またはインデックスポインタの時間順序付け(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/IB2018/053335
【特許文献2】PCT/IB2018/053337
【特許文献3】PCT/IB2018/053339
【特許文献4】PCT/IB2018/053336
【特許文献5】PCT/IB2018/056430
【特許文献6】PCT/IB2018/056432
【特許文献7】PCT/IB2018/056431
【発明の概要】
【課題を解決するための手段】
【0010】
別のトランザクションを使用してブロックチェーントランザクションに対して条件を強制するための既存の技術が、存在する。たとえば、以前のトランザクションの出力のロックを解除しようと試みる将来のトランザクションの入力および/または出力に対して条件を強制することが可能であり、それによって以前のトランザクションの出力は、少なくとも部分的に、それらの条件を強制する責任を負う。条件は、たとえば、将来のトランザクションの入力および/または出力が特定のデータを含むかまたは特定のフォーマットであることを含む場合がある。
【0011】
将来のトランザクションに対して条件を強制するために使用される1つの技術は、「PUSHTX」または「OP_PUSHTX」として広く知られている。PUSHTXは、擬似オペコードであり、すなわち、PUSHTXは、ブロックチェーンスクリプト言語(たとえば、Script)の単一のオペコードではなく、むしろ、実行されるときに動作の対応する集合を実行するように一緒に構成されるオペコード(またはより広く関数)の集合である。PUSHTX技術は、国際特許出願PCT/IB2018/053335、PCT/IB2018/053337、PCT/IB2018/053339、PCT/IB2018/053336、PCT/IB2018/056430、PCT/IB2018/056432、およびPCT/IB2018/056431において最初に開示された。PUSHTXの中核的な考えは、スタック上のデータ要素に対してスクリプト内で署名を生成し、OP_CHECKSIGを呼び出して署名を検証することである。署名が合格する場合、それは、OP_CHECKSIGによって構築されたメッセージが、スタックにプッシュされたデータ要素と同一であることを示唆する。したがって、それは、現在の消費するトランザクション(spending transaction)(すなわち、以前のトランザクションの出力のロックを解除する将来のトランザクション)をスタックにプッシュする効果を実現する。現在のトランザクションをスタックにプッシュすることは、たとえば、現在のトランザクションの特定のフィールド(入力、出力、ロック時間(locktime)など)が特定のデータ、値、オペコード、スクリプトなどを含むことをチェックすることによって、条件の強制を可能にする。
【0012】
本開示は、PUSHTX技術のいくつかの最適化を提供する。しかし、トランザクションをスタックにプッシュするためのその他の類似の技術が存在し、当業者がそれらに精通していること、および本開示の実施形態が、PUSHTXだけでなく、それらの技術のいずれにも広く適用される場合があることを理解されたい。
【0013】
本明細書において開示される一態様によれば、第1のブロックチェーントランザクションを使用して第2のブロックチェーントランザクションに対して条件を強制するコンピュータ実施方法であって、条件のうちの第1の条件が、第2のトランザクションの第1のロック解除スクリプトが第1のトランザクションの第1のロックスクリプトとともに実行されるときに、第2のトランザクションの表現がメモリに出力されることであり、表現が、第2のトランザクションの複数のフィールドおよび第1のトランザクションの第1の出力に基づき、方法が、第1のトランザクションを生成するステップであって、第1のトランザクションが、第1の出力を含み、第1の出力が、第1のロックスクリプトを含み、第1のロックスクリプトが、実行されるときに、第2のトランザクションを表す候補メッセージをメモリに出力するように構成されたメッセージサブスクリプトであって、候補メッセージが、第1のトランザクションおよび第2のトランザクションの複数の候補フィールドに基づき、候補フィールドのうちの1つまたは複数が、第2のトランザクションの第1のロック解除スクリプトに含まれ、メッセージサブスクリプトが、候補フィールドのそれぞれのセットに基づいて候補メッセージの1つまたは複数のそれぞれの部分を生成し、候補メッセージの異なるそれぞれの部分として候補フィールドのそれぞれのセットのうちの少なくとも1つを再利用するように構成される、メッセージサブスクリプトと、実行されるときに署名を生成するように構成された署名サブスクリプトであって、署名が、少なくとも、候補メッセージ、プライベート鍵、および一時(ephemeral)プライベート鍵の関数である、署名サブスクリプトと、プライベート鍵に対応する公開鍵と、実行されるときに、i)第2のトランザクションを表す目標メッセージを構築することであって、目標メッセージが、第2のトランザクションの複数のフィールドおよび第1のトランザクションの第1の出力に基づく、構築すること、ならびにii)公開鍵を使用して、署名が目標メッセージに有効であることを検証することであって、署名が目標メッセージに有効であることを検証することが、目標メッセージが候補メッセージと一致することを検証し、それによって、メモリに出力された候補メッセージが第2のトランザクションの表現であるという条件を強制する、検証することを行うように構成された検証サブスクリプトとを含む、ステップを含む、コンピュータ実施方法が、提供される。
【0014】
第1のトランザクションのロックスクリプトおよび第2のトランザクションのロック解除スクリプトは、第2のトランザクションの承認中に実行される。第1のトランザクションのロックスクリプトは、それぞれが1つまたは複数の動作を実行するように構成された一連のサブスクリプトを含む。サブスクリプトは、関数(たとえば、オペコード)の特定のセットと、任意で、データ項目、たとえば、公開鍵または公開鍵のハッシュのセットとのラベルであるに過ぎない。
【0015】
メッセージサブスクリプトは、候補メッセージをメモリ、たとえば、スタックに出力するように構成される。メッセージは、それが正しく構成された場合、本明細書において「目標メッセージ」と呼ばれる別のメッセージと一致するという意味で「候補メッセージ」である。候補メッセージは、第2のトランザクションの候補の複数のフィールド(たとえば、入力、出力など)(たとえば、第2のトランザクションのすべてのフィールド)と、第1のトランザクションの候補の第1の出力、すなわち、第1のロックスクリプトを含む出力とに基づく。ここで、フィールドおよび出力は、それらが(第1のトランザクションのロックスクリプトかまたは第2のトランザクションのロック解除スクリプトかのどちらかに)データ項目として含まれ、第1および第2のトランザクションの正しいフィールドであると主張されるという意味で「候補」である。たとえば、ロックスクリプトの候補の長さが、第2のトランザクションのロック解除スクリプトに含まれる場合がある。
【0016】
署名サブスクリプトは、候補メッセージ、プライベート鍵、および一時プライベート鍵に基づいてデジタル署名(たとえば、ECDSA署名)を生成するように構成される。一時プライベート鍵は、一部の実施形態において、1に等しいものと決められる場合がある。通常、一時プライベート鍵は、大きな数であり、一時プライベート鍵が署名の生成中に概して数回必要とされることを考慮すると、一時プライベート鍵を1に決めることは、ロックスクリプトのストレージサイズを削減し、署名生成プロセスを簡素化する。一時プライベート鍵を含むすべての数学演算が些細なものになるので、署名生成プロセスが簡素化される。署名サブスクリプトは、プライベート鍵と一時プライベート鍵との両方を1に等しいものと決めることによって、より一層最適化される場合がある。これは、さらにロックスクリプトのストレージサイズを削減し、署名生成プロセスの計算複雑性を減らす。追加的または代替的な実施形態において、一時プライベート鍵およびプライベート鍵は、同じ値(必ずしも値1ではないが、上述のようにそれはもちろん選択肢である)に等しいものとロックスクリプトにおいて決められる。これらの実施形態は、同様の理由で大幅な節約を提供する。後述されるように、本開示の発明者は、第1または第2のトランザクションのセキュリティを損なうことなくこれらの節約が可能であることを認識した。
【0017】
(場合によっては単一の関数、たとえば、オペコードであってよい)署名検証サブスクリプトは、第1および第2のトランザクションの実際のフィールド、たとえば、第1のトランザクションの実際の第1の出力、第2のトランザクションの実際の出力などに基づいて目標メッセージを構築するように構成される。また、署名検証サブスクリプトは、署名サブスクリプトによって生成された署名が目標メッセージに有効であることを検証する。署名が有効である場合、候補メッセージは、必然的に目標メッセージと同じである。したがって、メモリに出力された候補メッセージは、第2のトランザクションの表現である目標メッセージである。言い換えると、署名のチェックに合格することは、2つのメッセージが同一である場合にのみ可能であり、したがって、署名を検証することは、候補メッセージおよび目標メッセージが等しいことを検証する。
【0018】
第2のトランザクションをメモリ(たとえば、スタック)に出力した後、さらなる条件を強制するために、さらなるチェックが行われ得る。たとえば、本開示の実施形態は、永続的強制ロックスクリプト(PELS: perpetually enforcing locking script)を構築するために使用されてよく、PELSは、ロックスクリプトを含む出力から生じるトランザクションのチェーンのすべての将来のトランザクションに対して何らかの1つの条件または複数の条件を強制するロックスクリプトである。たとえば、PELSは、消費するトランザクションのロックスクリプトがそのPELS自体と同じであることを強制するために使用されてよい。PELSは、送信者(すなわち、PELSの最初のインスタンスを含むトランザクションの作成者)にとって特に有用であり、なぜなら、送信者が、すべての将来の消費するトランザクションが送信者がロックスクリプトに示した規則に従うことを保証され得るからである。すべての規則違反は、スクリプトの実行の観点でトランザクションの承認を無効にする。事実上、送信者は、承認作業をブロックチェーンノードに委任することによって、すべての将来のトランザクションから手を引くことができる。
【0019】
本開示は、候補メッセージの一部を表す候補フィールドの1つまたは複数のセットが、候補メッセージの異なる部分を構築するために再利用され得ることを認める。これは、候補フィールドの1つまたは複数のセットが、複数回含められるのではなく、第1のトランザクションのロックスクリプトまたは第2のトランザクションのロック解除スクリプトに1回だけ含められればよいので、大幅なスペースの節約を提供する。候補フィールドの1つまたは複数のセットの再利用のさらなる効果は、第2のトランザクションに対してさらなる条件が強制されてよいことである。たとえば、上述のように、候補メッセージは、条件を強制するロックスクリプトを含む第1のトランザクションの出力に基づく。ロック解除スクリプトは、第1のトランザクションの出力を表す候補フィールドのセット(たとえば、値およびロックスクリプト)を含んでよい。メッセージサブスクリプトは、第2のトランザクションの出力を構築するために、候補フィールドのセットを複製してよい。署名の検証が合格する場合、候補メッセージは、目標メッセージと同じでなければならず、したがって、第2のトランザクションは、第1のトランザクションの出力と一致する出力を含まなければならない。言い換えると、第2のトランザクションが有効とみなされるためには、第1のトランザクションの出力が、第2のトランザクションの出力として含まれなければならない。同じ技術が、第2のトランザクションの候補(または実際の)フィールドの同じセットを含むかまたはその同じセットに基づいて生成される候補メッセージ(および、したがって、目標メッセージ)の任意の部分に適用されてよい。
【0020】
本開示の実施形態の理解を助け、そのような実施形態がどのようにして実施されてよいかを示すために、添付の図面が、例としてのみ参照される。
【図面の簡単な説明】
【0021】
図1】ブロックチェーンを実装するためのシステムの概略的なブロック図である。
図2】ブロックチェーンに記録されてよいトランザクションのいくつかの例を概略的に示す図である。
図3A】クライアントアプリケーションの概略的なブロック図である。
図3B図3Aのクライアントアプリケーションによって提示されてよい例示的なユーザインターフェースの概略的なモックアップの図である。
図4】トランザクションを処理するためのあるノードソフトウェアの概略的なブロック図である。
図5】本開示の実施形態を実装するための例示的システムの概略的なブロック図である。
図6】第2のトランザクションに対して条件を強制するように構成された第1のトランザクションの例を示す図である。
図7】第2のトランザクションの例を示す図である。
図8】第1のトランザクションが候補メッセージの一部を別の部分から生成するように最適化されている、第2のトランザクションの例を示す図である。
【発明を実施するための形態】
【0022】
1. 例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークを含んでよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。
【0023】
各ブロックチェーンノード104は、ピアのコンピュータ機器を含み、ノード104のうちの異なるノードは、異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央演算処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などのその他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージも含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。
【0024】
ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク106の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。そうではなく、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(下で検討される)を記憶する限り、ブロックチェーン150は、データを刈り込まれる場合がある。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルの種類に依存する。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを使用する。1つのよくある種類のトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、財産としてのデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされるユーザ103である(ロックを解除され、それによって、履行または消費されるためにはそのユーザの署名またはその他の解決策を必要とする)。各入力は、先行トランザクション152の出力を後ろ向きに指し示し、それによって、トランザクションをリンクする。
【0025】
各ブロック151は、ブロック151までの発生順を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。(コインベーストランザクション以外の)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153までさかのぼる。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。
【0026】
ブロックチェーンノード104の各々は、トランザクション152をその他のブロックチェーンノード104に転送し、それによって、トランザクション152をネットワーク106全体に伝播させるように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれらのブロックチェーンノード104のそれぞれのメモリに記憶するように構成される。また、各ブロックチェーンノード104は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられたセット(または「プール」)154を維持する。順序付けられたプール154は、多くの場合「メムプール(mempool)」と呼ばれる。本明細書におけるこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルにも限定するように意図されていない。この用語は、ノード104が有効であるものとして受け入れ、ノード104が同じ出力を消費しようと試みるいかなるその他のトランザクションも受け入れないことを義務付けられるトランザクションの順序付けられたセットを指す。
【0027】
所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことになると指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも必ずしも存在する必要がないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない(孤児(orphan)トランザクションに関する下の検討を参照されたい)。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。
【0028】
現在のトランザクション152jの入力は、入力の認可、たとえば、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。そして今度は、現在のトランザクション152jの出力が、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行トランザクション152iの入力において定義された額を、現在のトランザクション152jの出力において定義されたように新しいユーザまたはエンティティ103bに送金することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、お釣りを渡すために元のユーザまたはエンティティ103aである可能性がある)の間で入力額を分けるために複数の出力を有する場合がある。場合によっては、トランザクションは、1つまたは複数の先行トランザクションの複数の出力からの金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することも可能である。
【0029】
ビットコインのような出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの関係者103が(手動でかまたは関係者によって採用された自動化されたプロセスによってかのどちらかで)新しいトランザクション152jを実行に移したいとき、実行に移す者は、自分のコンピュータ端末102から受取人に新しいトランザクションを送信する。実行に移す者または受取人は、最終的に、このトランザクションを(現在は概してサーバまたはデータセンターであるが、原理的にはその他のユーザ端末である可能性がある)ネットワーク106のブロックチェーンノード104のうちの1つまたは複数に送信する。また、新しいトランザクション152jを実行に移す関係者103が、トランザクションをブロックチェーンノード104のうちの1つまたは複数に直接送信し、一部の例においては、受取人に送信しない可能性があることも除外されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、概して、新しいトランザクション152jの暗号署名が、トランザクション152の順序付けられたシーケンス内の前のトランザクション152iに依存する期待される署名と一致することをブロックチェーンノード104がチェックすることを要求する。そのような出力ベースのトランザクションプロトコルにおいて、これは、新しいトランザクション152jの入力に含まれる関係者103の暗号署名またはその他の認可が、新しいトランザクションが割り振る先行トランザクション152iの出力において定義された条件と一致することをチェックすることを含む場合があり、この条件は、概して、少なくとも、新しいトランザクション152jの入力の暗号署名またはその他の認可が、新しいトランザクションの入力がリンクされる前のトランザクション152iの出力のロックを解除することをチェックすることを含む。条件は、先行トランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義されてよい。代替的に、条件は、単にブロックチェーンノードプロトコルのみによって決められる可能性があり、またはこれらの組合せに起因する可能性がある。いずれにせよ、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、その新しいトランザクション152jをブロックチェーンネットワーク106の1つまたは複数のその他のブロックチェーンノード104に転送する。これらのその他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用し、したがって、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送し、以下同様である。このようにして、新しいトランザクションは、ブロックチェーンノード104のネットワーク全体に伝播される。
【0030】
出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り振られる(たとえば、消費される)かどうかの定義は、その出力がブロックチェーンノードプロトコルに従って別のオンワードトランザクション(onward transaction)152jの入力によって既に有効に履行されたかどうかということである。トランザクションが有効であるための別の条件は、それが履行しようと試みる先行トランザクション152iの出力が別のトランザクションによって既に履行されていないことである。やはり、有効でない場合、トランザクション152jは(警告のために無効であるものとしてフラグを立てられ、伝播されるのでない限り)伝播されず、ブロックチェーン150に記録されない。これは、トランザクションを行う者が同じトランザクションの出力を2回以上割り振ろうとする二重支払いを防ぐ。一方、アカウントベースのモデルは、アカウントの残高を維持することによって二重支払いを防止する。やはり、トランザクションの定義された順序が存在するので、アカウントの残高は、常に単一の定義された状態を有する。
【0031】
トランザクションを承認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうとさらに競争する。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたプール154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスが保留トランザクションの順序付けられたプール154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他の種類は除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード104において相当大量の処理リソースを消費し得る。
【0032】
パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークのその他のブロックチェーンノード104によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード104は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード104の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード104の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に承認されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク106のブロックチェーンノード104の各々において認識され、維持されるので、修正され得ない。また、ブロックポインタ155は、ブロック151に発生順を付与する。トランザクション152がネットワーク106の各ブロックチェーンノード104の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。
【0033】
任意の所与の時間にパズルを解こうと競争する異なるブロックチェーンノード104は、それらのブロックチェーンノード104がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションのプール154の異なるスナップショットに基づいてそうしている場合があることに留意されたい。最初にそれらのそれぞれのパズルを解いた者は誰でも、どのトランザクション152が次の新しいブロック151nにどの順序で含まれるかを定義し、未公開トランザクションの現在のプール154が、更新される。それから、ブロックチェーンノード104は、未公開トランザクションの新たに定義された順序付けられたプール154からブロックを作成しようと競争を続け、以下同様である。発生する可能性があるすべての「フォーク(fork)」を解決するためのプロトコルも存在し、フォークは、ブロックチェーンの相反するビュー(view)がノード104の間で伝播されるように、2つのブロックチェーンノード104が互いに非常に短い時間内にそれらのブロックチェーンノード104のパズルを解く地点である。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最終的なブロックチェーン150となる。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであることに留意されたい。
【0034】
ビットコインブロックチェーン(およびほとんどのその他のブロックチェーン)によれば、新しいブロック104を成功裏に構築するノードは、(ある額のデジタル資産をあるエージェントまたはユーザから別のエージェントまたはユーザに送金するエージェント間またはユーザ間トランザクションとは対照的に)追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて追加の認められた額のデジタル資産を新たに割り振る能力を付与される。この特別な種類のトランザクションは、通常「コインベーストランザクション」と呼ばれるが、「イニシエーショントランザクション(initiation transaction)」または「生成トランザクション(generation transaction)」と呼ばれる場合もある。この特別な種類のトランザクションは、概して、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で履行されることを可能にするプロトコルの規則に従うという、新しいブロックを構築するノードの意図を知らせる。ブロックチェーンプロトコルの規則は、この特別なトランザクションが履行されてよい前に、満期期間(maturity period)、たとえば、100ブロックを必要とする場合がある。多くの場合、通常の(非生成(non-generation))トランザクション152は、トランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加の取引手数料も指定する。この手数料は、通常「取引手数料」と呼ばれ、下で検討される。
【0035】
トランザクションの承認および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード104の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはそれどころかデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード104は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。
【0036】
各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそのそれぞれの1つの役割または複数の役割を実行し、トランザクション152を処理するために、ブロックチェーンノード104の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード104に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行されてよいことが理解されるであろう。ノードソフトウェアは、アプリケーションレイヤの1つもしくは複数のアプリケーションに、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより下位のレイヤに、またはこれらの任意の組合せで実装されてよい。
【0037】
ネットワーク101にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワーク106とインタラクションする場合があるが、トランザクションの承認またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合がある。その他のユーザは、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。
【0038】
関係者103の一部またはすべては、異なるネットワーク、たとえば、ブロックチェーンネットワーク106の上に重ねられたネットワークの一部として接続される場合がある。ブロックチェーンネットワークのユーザ(多くの場合「クライアント」と呼ばれる)は、ブロックチェーンネットワーク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の関係者」によって置き換えられてよいことが理解されるであろう。
【0039】
各関係者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つまたは複数のその他のネットワーク化されたリソースも含む場合がある。
【0040】
クライアントアプリケーション105は、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103のコンピュータ機器102に提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。
【0041】
クライアントアプリケーション105は、少なくとも「ウォレット」機能を含む。これは、2つの主な機能を有する。これらのうちの一方は、それぞれの関係者103が、トランザクション152を作成し、認可し(たとえば、署名し)、その後ブロックチェーンノード104のネットワーク全体に伝播され、それによって、ブロックチェーン150に含められるように1つまたは複数のビットコインノード104に送信することを可能にすることである。他方は、それぞれの関係者が現在所有しているデジタル資産の額の報告をその関係者に返すことである。出力ベースのシステムにおいて、この第2の機能は、問題にしている関係者に属する、ブロックチェーン150全体に散在する様々なトランザクション152の出力に定義された額を照合することを含む。
【0042】
注: 様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIを介してインターフェースをとる、または1つがそれ以外のプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。
【0043】
各コンピュータ機器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によって、同じノードプロトコルが使用される。
【0044】
所与の関係者103、たとえば、Aliceは、ブロックチェーン150に含められるように新しいトランザクション152jを送信したいとき、(自分のクライアントアプリケーション105のウォレット機能を使用して)関連するトランザクションプロトコルに従って新しいトランザクションを組み立てる。そして、その関係者103は、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最良に接続されているブロックチェーンノード104である可能性がある。任意の所与のブロックチェーンノード104は、新しいトランザクション152jを受信するとき、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってその新しいトランザクション152jを処理する。これは、新しく受信されたトランザクション152jが「有効」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例は、まもなくより詳細に検討される。一部のトランザクションプロトコルにおいて、承認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能である場合がある。代替的に、条件は、単にノードプロトコルの組み込まれた特徴であるか、またはスクリプトとノードプロトコルとの組合せによって定義される可能性がある。
【0045】
新しく受信されたトランザクション152jが有効とみなされるためのテストに合格することを条件に(すなわち、新しく受信されたトランザクション152jが「承認される」ことを条件に)、トランザクション152jを受信するすべてのブロックチェーンノード104は、そのブロックチェーンノード104において維持されるトランザクション154の順序付けられたセットに、新しい承認されたトランザクション152を追加する。さらに、トランザクション152jを受信するすべてのブロックチェーンノード104は、承認されたトランザクション152をネットワーク106の1つまたは複数のその他のブロックチェーンノード104に向かって伝播させる。各ブロックチェーンノード104が同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、トランザクション152jがネットワーク106全体にすぐに伝播されることを意味する。
【0046】
所与のブロックチェーンノード104において維持される保留トランザクションの順序付けられたプール154に入れられると、そのブロックチェーンノード104は、新しいトランザクション152を含む154のそれらのそれぞれのプールの最新バージョンに関するプルーフオブワークのパズルを解く競い合いを開始する(その他のブロックチェーンノード104はトランザクションの異なるプール154に基づくパズルを解こうとしている可能性があるが、誰であれ最初に成功する者が最新のブロック151に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたプール154の一部に関するパズルを解く)。新しいトランザクション152jを含むプール154に関してプルーフオブワークが行われると、プール154は、不変的にブロックチェーン150のブロック151のうちの1つの一部となる。各トランザクション152は、以前のトランザクションに戻るポインタを含み、したがって、トランザクションの順序も不変的に記録される。
【0047】
異なるブロックチェーンノード104は、最初に、所与のトランザクションの異なるインスタンスを受信し、したがって、1つのインスタンスが新しいブロック151で公開される前は、どのインスタンスが「有効」であるかについての相反するビューを有する可能性があり、1つのインスタンスが新しいブロック151で公開された時点で、すべてのブロックチェーンノード104は、公開されたインスタンスが唯一の有効なインスタンスであると合意する。ブロックチェーンノード104が1つのインスタンスを有効であるものとして受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されたことを発見する場合、そのブロックチェーンノード104は、これを受け入れなければならず、そのブロックチェーンノード104が最初に受け入れたインスタンス(すなわち、ブロック151で公開されなかったインスタンス)を破棄する(すなわち、無効であるものとして扱う)。
【0048】
一部のブロックチェーンネットワークによって運用される代替的な種類のトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」のプロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムにおいて、トランザクションは、アカウントの実行中の取引勘定(running transaction tally)(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、送信者によって送信者の暗号署名の一部として署名され、トランザクション参照計算(transaction reference calculation)の一部としてハッシュされる。さらに、任意のデータフィールドが、トランザクションに割り振られる場合もある。このデータフィールドは、たとえば、前のトランザクションIDがデータフィールドに含まれる場合、前のトランザクションを後ろ向きに指し示す場合がある。
【0049】
2. UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は、1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、すべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルは、ビットコインに関連して説明されるが、その他の例示的なブロックチェーンネットワークに同様に実装されてよいことに留意されたい。
【0050】
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に記憶される。
【0051】
Alice103aが、問題にしているデジタル資産の額をBob103bに送金するトランザクション152jを作成したいものとする。図2において、Aliceの新しいトランザクション152jは、「Tx1」とラベル付けされている。トランザクション152jは、シーケンス内の先行トランザクション152iの出力203においてAliceにロックされているデジタル資産の額を取得し、このうちの少なくとも一部をBobに送金する。先行トランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、任意のラベルであるに過ぎない。それらは、必ずしも、Tx0がブロックチェーン151の最初のトランザクションであることも、Tx1がプール154内のすぐ次のトランザクションであることも意味しない。Tx1は、Aliceにロックされた未使用の出力203をまだ持っている任意の先行(すなわち、先祖)トランザクションを後ろ向きに指し示す可能性がある。
【0052】
先行トランザクションTx0は、Aliceが自分の新しいトランザクションTx1を作成するときに、または少なくともAliceがその新しいトランザクションTx1をネットワーク106に送信するまでに、既に承認され、ブロックチェーン150のブロック151に含められた可能性がある。先行トランザクションTx0は、そのとき、既にブロック151のうちの1つに含められた可能性があり、または順序付けられたセット154内でまだ待っている可能性があり、その場合は、先行トランザクションTx0は、すぐに新しいブロック151に含められる。代替的に、Tx0およびTx1は、一緒に作成され、ネットワーク106に送信される可能性があり、またはノードプロトコルが「孤児」トランザクションをバッファリングすることを許す場合、Tx0がTx1の後に送信される可能性さえある。本明細書においてトランザクションのシーケンスの文脈で使用される用語「先行」および「後続」は、トランザクションにおいて指定されたトランザクションポインタによって定義されるシーケンス内のトランザクションの順序(どのトランザクションがどのその他のトランザクションを後ろ向きに指し示すかなど)を指す。それらの用語は、「先任者」および「後任者(successor)」、または「先祖」および「子孫(descendant)」、「親」および「子」などによって等しく置き換えられる可能性がある。それは、必ずしも、それらのトランザクションが作成される、ネットワーク106に送信される、または任意の所与のブロックチェーンノード104に到着する順序を示唆しない。しかしながら、先行トランザクション(先祖トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまで、および親トランザクションが承認されない限り、承認されない。その親の前にブロックチェーンノード104に到着する子は、孤児とみなされる。その子は、ノードプロトコルおよび/またはノードの挙動に応じて、廃棄されるか、または親を待つために特定の時間バッファリングされる場合がある。
【0053】
先行トランザクションTx0の1つまたは複数の出力203のうちの1つは、ここではUTXO0とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが承認され、したがって、UTXOが成功裏に履行されるために後続のトランザクションの入力202内のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。概して、ロックスクリプトは、額を特定の関係者(そのロックスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、概して、後続のトランザクションの入力のロック解除スクリプトが先行トランザクションがロックされている関係者の暗号署名を含むという条件を含むロック解除条件を定義する。
【0054】
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で記述されたコード片である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、どの情報がトランザクション出力203を消費するために必要とされるか、たとえば、Aliceの署名の必要を指定する。ロック解除スクリプトは、トランザクションの入力に現れる。ロック解除スクリプト(別名scriptSig)は、ロックスクリプトの基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で記述されたコード片である。たとえば、ロック解除スクリプトは、Bobの署名を含む場合がある。ロック解除スクリプトは、トランザクションの入力202に現れる。
【0055】
したがって、図示された例において、Tx0の出力203のUTXO0は、UTXO0が履行されるために(厳密には、UTXO0を履行しようと試みる後続のトランザクションが有効であるために)Aliceの署名Sig PAを必要とするロックスクリプト[Checksig PA]を含む。[Checksig PA]は、Aliceの公開-プライベート鍵ペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、(たとえば、実施形態においてはトランザクションTx0全体のハッシュであるそのトランザクションID、TxID0によって)Tx1を後ろ向きに指し示すポインタを含む。Tx1の入力202は、Tx0の任意のその他の可能な出力の中でUTXO0を特定するために、Tx0内のUTXO0を特定するインデックスを含む。Tx1の入力202は、Aliceが鍵ペアからの自分のプライベート鍵をデータの予め定義された部分(暗号技術においては「メッセージ」と呼ばれることがある)に適用することによって作成されたAliceの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにAliceによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義される場合がある。
【0056】
新しいトランザクションTx1がブロックチェーンノード104に到着するとき、ノードは、ノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトにおいて定義された条件(この条件は1つまたは複数の基準を含む場合がある)を満たすかどうかをチェックすることを含む。実施形態において、これは、2つのスクリプトを連結すること、すなわち、
<Sig PA> <PA> || [Checksig PA]
を含み、「||」は、連結を表し、「<...>」は、スタックにデータを置くことを意味し、「[...]」は、ロックスクリプト(この例においては、スタックベースの言語)によって含まれる関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順々に実行されてよい。いずれにせよ、一緒に実行されるとき、スクリプトは、Tx0の出力のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx1の入力のロック解除スクリプトがデータの期待される部分に署名するAliceの署名を含むことを認証する。データの期待される部分自体(「メッセージ」)も、この認証を実行するために含められる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、平文のデータの署名された部分を指定する別個の要素は、それが既に本質的に存在するので含められる必要がない)。
【0057】
公開-プライベート暗号技術による認証の詳細は、当業者によく知られているであろう。基本的に、Aliceが自分のプライベート鍵を使用してメッセージに署名した場合、Aliceの公開鍵および平文のメッセージがあれば、ノード104のなどの別のエンティティは、そのメッセージがAliceによって署名されたに違いないことを認証することができる。署名は、通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって、公開鍵のすべての保有者が署名を認証することを可能にする。したがって、特定のデータまたはトランザクションの一部などに署名することへの本明細書におけるすべての言及は、実施形態においては、そのデータまたはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
【0058】
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内の別の有効なトランザクションへの有効な入力を既に形成したかどうかということである。
【0059】
所与のトランザクション152のすべての出力203において指定された総額が、そのトランザクション152のすべての入力202によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効の別の根拠となる。したがって、そのようなトランザクションは、伝播されず、ブロック151に含められることもない。
【0060】
UTXOベースのトランザクションモデルにおいて、所与のUTXOは、丸ごと消費される必要があることに留意されたい。所与のUTXOは、UTXOにおいて使用済みとして定義された額の一部分が消費される一方で、別の部分を「残しておく」ことはできない。ただし、UTXOからの額は、次のトランザクションの複数の出力の間で分けられ得る。たとえば、Tx0のUTXO0において定義された額が、Tx1の複数のUTXOの間で分けられ得る。したがって、Aliceは、BobにUTXO0において定義された額のすべてを与えたくない場合、残りを使用してTx1の第2の出力において自分自身にお釣りを与えるかまたは別の関係者に支払いをすることができる。
【0061】
実際には、Aliceは、通常さらに、ブロック151に自分のトランザクション104を成功裏に含めるビットコインノード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において明示的に指定される可能性があることは、必ずしも除外されない。
【0062】
AliceおよびBobのデジタル資産は、ブロックチェーン150の任意の場所の任意のトランザクション152においてAliceおよびBobにロックされたUTXOから成る。したがって、典型的には、所与の関係者103の資産は、ブロックチェーン150全体の様々なトランザクション152のUTXO全体に散在している。ブロックチェーン150のどこにも、所与の関係者103の総残高を定義する1つの数字は記憶されていない。それぞれの関係者にロックされ、別のオンワードトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を照合することは、クライアントアプリケーション105内のウォレット機能の役割である。ウォレット機能は、ビットコインノード104のいずれかに記憶されたブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。
【0063】
スクリプトコードは、概略的に(つまり、正確な言語を使用せずに)表現されることが多いことに留意されたい。たとえば、特定の機能を表現するためにオペレーションコード(オペコード)を使用する場合がある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの始めにOP_FALSEが先にあるとき、トランザクション内にデータを記憶することができ、それによって、ブロックチェーン150にデータを不変的に記録することができるトランザクションの消費不可能な出力を作成するScript言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を含む可能性がある。
【0064】
概して、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。一部の実施形態において、所与のトランザクションに関して、署名は、トランザクション入力の一部と、トランザクション出力の一部またはすべてに署名する。署名が署名する出力の特定の部分は、SIGHASHフラグに応じて決まる。SIGHASHフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名する時点で決まっている)4バイトのコードである。
【0065】
ロックスクリプトは、概してそれがそれぞれのトランザクションがロックされている関係者の公開鍵を含むという事実を示して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、通常、それが対応する署名を供給するという事実を示して、「scriptSig」と呼ばれることがある。しかし、より広く、UTXOが履行されるための条件が署名を認証することを含むことは、ブロックチェーン150のすべての応用において必須ではない。より広く、スクリプト言語が、任意の1つまたは複数の条件を定義するために使用される可能性がある。したがって、より広い用語「ロックスクリプト」および「ロック解除スクリプト」が、好ましい場合がある。
【0066】
3. サイドチャネル
図1に示されたように、AliceおよびBobのコンピュータ機器102a、102bの各々のクライアントアプリケーションは、それぞれ、追加の通信機能を含む場合がある。この追加の機能は、Alice103aが、(どちらかの関係者または第三者の勧めによって)Bob103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別にデータのやりとりを可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、関係者の一方がトランザクション152をネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されていない、またはチェーン150に向かって進んでいない状態で、AliceとBobとの間でトランザクション152をやりとりするために使用される場合がある。このようにしてトランザクションを共有することは、「トランザクションテンプレート(transaction template)」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる1つまたは複数の入力および/または出力を欠いている場合がある。代替的または追加的に、サイドチャネル107は、鍵、交渉された額または条項、データ内容などの任意のその他のトランザクション関連データをやりとりするために使用される場合がある。
【0067】
サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立されてよい。代替的または追加的に、サイドチャネル107は、モバイルセルラネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはそれどころかAliceおよびBobのデバイス102a、102bの間の直接有線もしくは無線リンクなどの異なるネットワークを介して確立されてよい。概して、本明細書のどこで言及されるサイドチャネル107も、「オフチェーン」、すなわち、ブロックチェーンネットワーク106とは別でデータをやりとりするための1つまたは複数のネットワーキングテクノロジーまたは通信媒体を介した任意の1つまたは複数のリンクを含んでよい。2つ以上のリンクが使用される場合、オフチェーンリンクの束または集合が全体としてサイドチャネル107と呼ばれる場合がある。したがって、AliceおよびBobがサイドチャネル107を介して特定の情報またはデータなどをやりとりすると言われる場合、これは、これらのデータすべてがまったく同じリンクまたはそれどころか同じ種類のネットワーク上で送信されなければならないことを必ずしも示唆しないことに留意されたい。
【0068】
4. クライアントソフトウェア
図3Aは、今開示されている方式の実施形態を実施するためのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を含む。トランザクションエンジン401は、上で検討された方式に従っておよびまもなくさらに詳細に検討されるように、トランザクション152を組み立てること、サイドチャネル107を介してトランザクションおよび/もしくはその他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて伝播するように1つもしくは複数のノード104にトランザクションを送信することなどの、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。
【0069】
UIレイヤ402は、機器102のユーザ出力手段を介してそれぞれのユーザ103に情報を出力すること、および機器102のユーザ入力手段を介してそれぞれのユーザ103から返ってくる入力を受け取ることを含め、それぞれのユーザのコンピュータ機器102のユーザ入力/出力(I/O)手段を介してユーザインターフェースを提供するように構成される。たとえば、ユーザ出力手段は、視覚的出力を提供するための1つもしくは複数のディスプレイスクリーン(タッチスクリーンもしくは非タッチスクリーン)、音声出力を提供するための1つもしくは複数のスピーカ、および/または触覚的出力を提供するための1つもしくは複数の触覚出力デバイスなどを含む可能性がある。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーン(出力手段に使用されるものと同じもしくは異なる)、マウス、トラックパッド、もしくはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、スピーチもしくは発声入力を受け取るための1つもしくは複数のマイクロフォンおよび音声もしくは声認識アルゴリズム、手もしくは体のジェスチャの形態の入力を受け取るための1つもしくは複数のジェスチャベースの入力デバイス、または1つもしくは複数の機械式ボタン、スイッチ、もしくはジョイスティックなどの入力アレイ(input array)を含む可能性がある。
【0070】
注: 本明細書における様々な機能は同じクライアントアプリケーション105に統合されるものとして説明される場合があるが、これは、必ずしも限定的ではなく、その代わりに、それらの機能は、たとえば、1つがそれ以外のプラグインであるか、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースをとる、2つ以上の異なるアプリケーションのスイートに実装される可能性がある。たとえば、トランザクションエンジン401の機能は、UIレイヤ402とは別個のアプリケーションに実装されてよく、またはトランザクションエンジン401などの所与のモジュールの機能は、2つ以上のアプリケーションの間で分けられる可能性がある。説明される機能の一部またはすべてが、たとえば、オペレーティングシステムレイヤに実装される可能性があることも排除されない。本明細書の任意の箇所で単一のまたは所与のアプリケーション105などへの言及がなされる場合、これは単なる例示であり、より広く、説明された機能は任意の形態のソフトウェアで実装される可能性があることが理解されるであろう。
【0071】
図3Bは、Aliceの機器102aのクライアントアプリケーション105aのUIレイヤ402によってレンダリングされる場合があるユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、Bobの機器102bのクライアント105b、または任意のその他の関係者の機器のクライアントによってレンダリングされてよいことは理解されるであろう。
【0072】
例示として、図3Bは、Aliceの観点でUI500を示す。UI500は、ユーザ出力手段を介して異なるUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を含んでよい。
【0073】
たとえば、UI要素は、異なる画面上のボタン、またはメニューの異なる選択肢などである場合がある1つまたは複数のユーザが選択可能な要素501を含んでよい。ユーザ入力手段は、ユーザ103(この場合、Alice103a)が、画面上のUI要素をクリックもしくはタッチするか、または所望の選択肢の名前を言うことによるなどして、選択肢のうちの1つを選択するかまたはそれ以外の方法で操作することを可能にするように配置される(本明細書において使用される用語「手動」は、自動と対照を成すことを意図されているに過ぎず、必ずしも1つの手または複数の手の使用に限定しないことに注意されたい)。
【0074】
代替的または追加的に、UI要素は、1つまたは複数のデータ入力フィールド502を含んでよい。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえば、画面上にレンダリングされ、データは、ユーザ入力手段、たとえば、キーボードまたはタッチスクリーンを通じてフィールドに入力され得る。代替的に、データは、たとえば、音声認識に基づいて口述で受け取られる可能性がある。
【0075】
代替的または追加的に、UI要素は、ユーザに対して情報を出力するための1つまたは複数の情報要素503の出力を含んでよい。たとえば、これ/これらは、画面上にまたは聞こえるようにレンダリングされる可能性がある。
【0076】
様々なUI要素をレンダリングし、選択肢を選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能は、まもなくより詳細に検討される。図3に示されたUI500は図式化されたモックアップであるに過ぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を含む場合があることも理解されるであろう。
【0077】
5. ノードソフトウェア
図4は、UTXOまたは出力ベースのモデルの例において、ネットワーク106の各ブロックチェーンノード104上で実行されるノードソフトウェア450の例を示す。別のエンティティが、ネットワーク106上でノード104として分類されることなく、すなわち、ノード104の必要とされるアクションを実行することなく、ノードソフトウェア450を実行する場合があることに留意されたい。ノードソフトウェア450は、プロトコルエンジン451、スクリプトエンジン452、スタック453、アプリケーションレベル判断エンジン454、および1つまたは複数のブロックチェーン関連機能モジュール455のセットを含んでよいがこれらに限定されない。各ノード104は、コンセンサスモジュール455C(たとえば、プルーフオブワーク)、伝播モジュール455P、およびストレージモジュール455S(たとえば、データベース)の3つすべてを含むがこれらに限定されないノードソフトウェアを実行してよい。プロトコルエンジン451は、典型的には、トランザクション152の異なるフィールドを認識し、ノードプロトコルにしたがってそれらのフィールドを処理するように構成される。別の先行トランザクション152i(Txm-1)の出力(たとえば、UTXO)を指し示す入力を有するトランザクション152j(Txj)が受信されるとき、プロトコルエンジン451は、Txjのロック解除スクリプトを特定し、そのロック解除スクリプトをスクリプトエンジン452に渡す。また、プロトコルエンジン451は、Txjの入力のポインタに基づいてTxiを特定し、取り出す。Txiは、ブロックチェーン150上で公開されている場合があり、その場合、プロトコルエンジンは、ノード104に記憶されたブロックチェーン150のブロック151のコピーからTxiを取り出してよい。代替的に、Txiは、ブロックチェーン150上でまだ公開されていない場合がある。その場合、プロトコルエンジン451は、ノード104によって維持される未公開トランザクションの順序付けられたセット154からTxiを取り出してよい。いずれにせよ、プロトコルエンジン451は、Txiの参照された出力のロックスクリプトを特定し、これをスクリプトエンジン452に渡す。
【0078】
したがって、スクリプトエンジン452は、Txiのロックスクリプトと、Txjの対応する入力からのロック解除スクリプトとを有する。たとえば、Tx0およびTx1とラベル付けされたトランザクションが図2に示されるが、同じことがトランザクションのどのペアにも当てはまる可能性がある。スクリプトエンジン452は、既に検討されたように2つのスクリプトを一緒に実行し、これは、使用されているスタックベースのスクリプト言語(たとえば、Script)に従って、スタック453にデータを入れることと、スタック453からデータを取り出すこととを含む。
【0079】
スクリプトを一緒に実行することによって、スクリプトエンジン452は、ロック解除スクリプトがロックスクリプトにおいて定義された1つまたは複数の基準を満たすか否か -- すなわち、ロック解除スクリプトがロックスクリプトが含まれる出力の「ロックを解除する」かどうか -- を判定する。スクリプトエンジン452は、この判定の結果をプロトコルエンジン451に返す。スクリプトエンジン452は、ロック解除スクリプトが対応するロックスクリプトにおいて指定された1つまたは複数の基準を満たすと判定する場合、結果「真」を返す。それ以外の場合、スクリプトエンジン452は、結果「偽」を返す。
【0080】
出力ベースのモデルにおいて、スクリプトエンジン452からの結果「真」は、トランザクションの有効性の条件のうちの1つである。概して、Txjの出力において指定されたデジタル資産の総額がTxjの入力によって指し示された総額を超えないこと、およびTxiの指し示された出力が別の有効なトランザクションによって既に消費されていないことなどの、同様に満たされなければならない、プロトコルエンジン451によって評価される1つまたは複数のさらなるプロトコルレベルの条件も存在する。プロトコルエンジン451は、スクリプトエンジン452からの結果を1つまたは複数のプロトコルレベルの条件と一緒に評価し、それらがすべて真である場合にのみ、トランザクションTxjを承認する。プロトコルエンジン451は、トランザクションが有効であるかどうかのインジケーションをアプリケーションレベル判断エンジン454に出力する。Txjが確かに承認されるという条件でのみ、判断エンジン454は、コンセンサスモジュール455Cと伝播モジュール455Pとの両方を制御して、Txjに関してそれらのそれぞれのブロックチェーン関連機能を実行することを選択してよい。これは、コンセンサスモジュール455Cが、ブロック151に組み込むためのトランザクションのノードのそれぞれの順序付けられたセット154にTxjを追加することと、伝播モジュール455Pが、Txjをネットワーク106の別のブロックチェーンノード104に転送することとを含む。任意で、実施形態において、アプリケーションレベル判断エンジン454は、これらの機能のどちらかまたは両方をトリガする前に、1つまたは複数の追加の条件を適用する場合がある。たとえば、判断エンジンは、トランザクションが有効であり、かつ十分な取引手数料を残すという条件でのみ、トランザクションを公開することを選択する場合がある。
【0081】
本明細書における用語「真」および「偽」は必ずしも2進数1桁(ビット)のみの形態で表された結果を返すことに限定しないが、それは確かに1つの可能な実装であることにも留意されたい。より広く、「真」は、成功したまたは肯定的な結果を示す任意の状態を指すことが可能であり、「偽」は、失敗したまたは非肯定的な結果を示す任意の状態を指すことが可能である。たとえば、アカウントベースのモデルにおいて、「真」の結果は、署名の暗黙的なプロトコルレベルの承認とスマートコントラクトの追加の肯定的な出力との組合せによって示される可能性がある(個々の結果が両方とも真である場合に、全体の結果が真を知らせるとみなされる)。
【0082】
6. ブロックチェーントランザクションに対する条件の強制
本開示の実施形態は、あるトランザクションが別のトランザクションに対して条件を強制する(すなわち、課す)ことを可能にする。条件を強制するトランザクションは、「第1のトランザクション」と呼ばれ、条件を適用されているトランザクションは、「第2のトランザクション」と呼ばれる。条件は、条件が満たされない限り、トランザクションの承認中にブロックチェーンノード104によって第2のトランザクションが正常に承認されないという意味で強制される。図5は、前記実施形態を実装するための例示的なシステムを示す。示されるように、システムは、第1のトランザクションを生成するように構成された第1関係者と、第2のトランザクションを生成するように構成された第2の関係者と、ブロックチェーンネットワーク106の1つまたは複数のブロックチェーンノードとを含む。便宜上、第1の関係者は、Alice103aと呼ばれ、第2の関係者は、Bob103bと呼ばれる。概して、第1の関係者と第2の関係者との両方が、Alice103aおよび/またはBob103bによって実行されるものとして上で説明されたアクションのいずれかを実行するように構成されてよい。システムは、その他のエンティティ(図示せず)、たとえば、追加のユーザを含む場合がある。
【0083】
述べられたように、Alice103aは、第1のトランザクションを生成するように構成される。第1のトランザクションは、第1の出力を含む。第1の出力は、必ずしも、第1のトランザクションの出力のリストの中で論理的に最初に現れる必要はないが、それは、1つの可能性である。第1の出力は、ロックスクリプトを含み、そのロックスクリプトは、「第1のロックスクリプト」と呼ばれる。第1のロックスクリプトは、この例示的なシナリオにおいては第2のトランザクションである、第1の出力のロックを解除しようと試みているすべてのトランザクションに対して1つまたは複数の条件を強制するように構成される。それらの条件のうちの少なくとも1つは、第2のトランザクションの実行(たとえば、承認)中に第2のトランザクションの表現がメモリに出力されることである。すなわち、第1のトランザクション(および特に第1のトランザクションの第1のロックスクリプト)は、第2のトランザクションのロック解除スクリプトが第1のロックスクリプトとともに実行されるときに、第2のトランザクションの表現がメモリに出力されることを保証する効果を有する。便宜上、第1のトランザクションの第1のロックスクリプトと一緒に実行される第2のトランザクションのロック解除スクリプトは、第2のトランザクションの第1の入力に含まれる「第1のロック解除スクリプト」と呼ばれる。第1の入力は、必ずしも、第2のトランザクションの入力のリストの中で論理的に最初に現れる必要はないが、それは、1つの可能性である。
【0084】
第2のトランザクションの表現は、トランザクションがその一部を形成する特定のブロックチェーンに応じて異なってよい。概して、第2のトランザクションの表現は、第2のトランザクションの複数のフィールドおよび第1のトランザクションの第1の出力に基づく。言い換えると、現在のトランザクションの表現は、現在のトランザクションと、ロックを解除されている、つまり、消費、割り振り、送金などされている前のトランザクションの出力との両方に基づく。下でさらに検討されるように、第2のトランザクションの表現をメモリに出力することは、第2のトランザクションの一部またはすべてに対してチェックが実行されることを可能にし、したがって、さらなる条件が、たとえば、それらの条件が満たされたことをチェックし、それらの条件が満たされなかった場合はトランザクションの実行を失敗させることによって強制されてよい。
【0085】
第1のロックスクリプトは、メモリに出力される表現が確かに第2のトランザクションの正確な表現であることを保証するように一緒に構成されるサブスクリプトを含む。
【0086】
サブスクリプトのうちの第1のサブスクリプトは、「メッセージサブスクリプト」と呼ばれる。メッセージサブスクリプトは、第1のロックスクリプトの中で論理的に最初に現れる場合があり、または第1のロックスクリプトの前に現れる、第1のロックスクリプトに含まれるその他のサブスクリプトが存在する場合がある。メッセージサブスクリプトは、候補メッセージをメモリに出力するように構成される。候補メッセージは、第1のトランザクションの「候補の第1の出力」だけでなく、第2のトランザクションのいくつかの「候補フィールド」にも基づく。候補メッセージは、それがメモリに出力される時点では、候補メッセージが第2のトランザクションの実際のフィールドおよび第1のトランザクションの実際の第1の出力に基づいて構築されたことがまだ分からない(または、少なくともスクリプト内でまだ検証されていない)という意味で「候補」である。候補フィールドおよび候補の第1の出力は、同様の意味で、すなわち、スクリプト内で検証されるまで、それらが正しいことが分からないという意味で候補である。
【0087】
候補フィールドの少なくとも一部は、第2のトランザクションの第1のロック解除スクリプトに含まれる。各候補フィールドは、別々のデータ項目である場合があり、またはデータ項目は、2つ以上の候補フィールドを含む場合がある。候補の第1の出力の一部またはすべて(たとえば、第1の出力に割り振られた値、第1の出力の第1のロックスクリプト、第1の出力の第1のロックスクリプトの長さ)も、第1のロック解除スクリプトに含まれる場合がある。一部の実施形態においては、第2のトランザクションの候補フィールドのうちの1つまたは複数が、第1のトランザクションの第1のロックスクリプトに含まれる場合がある。下で検討されるように、第1のロックスクリプトに含まれる、候補メッセージが基づくすべての候補フィールドは、必然的に第2のトランザクションに含まれなければならない。したがって、第2のトランザクションがそれらの候補フィールドを含まなければならないという条件が強制されてよい。例として、第1のロックスクリプトは、候補メッセージが基づく候補ロック時間を含むことによって、第2のトランザクションのロック時間を決める場合がある。任意で、候補の第1の出力の(すべてではなく)一部が、第1のトランザクションの第1の出力に含まれる場合がある。
【0088】
メッセージサブスクリプトは、候補メッセージの一部またはすべてを構築するように構成される。たとえば、メッセージサブスクリプトは、第1のロックスクリプトおよび/または第1のロック解除スクリプトに含まれる1つまたは複数のデータ項目を組み合わせる(たとえば、連結する)場合があり、各データ項目は、1つもしくは複数の候補フィールドおよび/または候補の第1の出力(の一部)を含む。より詳細には、メッセージサブスクリプトは、1つまたは複数の候補フィールドに基づいて候補メッセージの一部を構築し、それらの1つまたは複数の候補フィールドのうちの少なくとも一部を候補メッセージの異なる部分として再利用するように構成される。たとえば、1つまたは複数の候補フィールドは、複製され、候補メッセージの一部を構築するために使用され、それから、メッセージの異なる部分として使用されてよい(またはメッセージの異なる部分を構築するために使用されてよい)。例として、候補フィールドのセット(たとえば、候補出力値および候補ロックスクリプト)が、第2のトランザクションの候補の前の出力(すなわち、第1のトランザクションの第1の出力)を表す候補メッセージの一部として使用され、第2のトランザクションの候補出力として再利用される場合がある。この例において、候補メッセージは、第2のトランザクションの出力の候補ハッシュを含む場合があり、したがって、メッセージサブスクリプトは、候補フィールドの再利用されたセットをハッシュする場合がある。メッセージサブスクリプトは、候補フィールドの単一のセットを再利用するか、または候補フィールドの複数のセットを再利用するように構成されてよい。これは、メッセージのフォーマットに応じて決まる。
【0089】
第1のロックスクリプトは、候補メッセージに基づいて署名を生成するように構成される署名サブスクリプトも含む。また、署名は、プライベート鍵および一時プライベート鍵に基づいて生成され、それらの鍵は、両方とも、第1のロックスクリプトによって決められる(たとえば、第1のロックスクリプトの一部として含まれる)。署名は、ECDSA署名であってよい。プライベート鍵および一時プライベート鍵は、第1のロックスクリプトによって「決められる」ために、必ずしも第1のロックスクリプトに含まれる必要はないことに留意されたい。たとえば、第1のロックスクリプトは、プライベート鍵および/または一時プライベート鍵に基づく値を含む場合があり、したがって、その値が、そのプライベート鍵および/または一時プライベート鍵を決める。一時プライベート鍵は、任意の数であってよく、好ましくは小さな数であってよい。たとえば、一時プライベート鍵は、1に等しいものと決められる場合がある。これは、通常256ビットの整数である通常の一時プライベート鍵に比べて大幅なスペースの節約を提供する。加えて、概して任意の数であってよいプライベート鍵も、1に等しいものと決められ、したがって、さらなるスペースの節約を提供してよい(プライベート鍵も通常は256ビットの整数である)。プライベート鍵と一時プライベート鍵との両方が両方とも1に等しいものと決められることの代替として、それらの鍵が互いに等しいものと決められる場合があり、たとえば、両方とも値2または別の小さな数をとる場合がある。両方の鍵に同じ値が使用されるので、署名生成プロセスが簡素化される。
【0090】
第1のロックスクリプトは、検証サブスクリプトも含む。検証サブスクリプトは、第2のトランザクションを表す目標メッセージを構築するように構成される。目標メッセージは、第2のトランザクションの複数のフィールドに基づく。目標メッセージは、第2のトランザクションの実際のフィールド、すなわち、第2のトランザクション自体から取得されたか、または第2のトランザクションに基づいて生成された実際のフィールドに基づく。目標メッセージは、候補メッセージと同じ、第2のトランザクションのフィールドのセットに基づく。たとえば、候補メッセージおよび目標メッセージは、第2のトランザクションの1つまたは複数の入力に基づく場合がある。また、目標メッセージは、第1のトランザクションの実際の第1の出力、すなわち、第1のトランザクション自体から取得された実際の第1の出力に基づく。
【0091】
検証サブスクリプトは、署名サブスクリプトによって生成された署名が目標メッセージの有効な署名であることを検証するようにも構成される。署名は、プライベート鍵に対応する公開鍵を使用して承認される。公開鍵は、たとえば、検証サブスクリプトの一部として第1のロックスクリプトに含まれる。(候補メッセージに基づいて生成された)署名が目標メッセージの有効な署名である場合、候補メッセージおよび目標メッセージが同じメッセージであり、したがって、候補メッセージが第2のトランザクションの実際のフィールドおよび第1のトランザクションの実際の第1の出力に基づいているということになる。したがって、メッセージサブスクリプトによってメモリに出力される候補メッセージは第2のトランザクションの表現であり、スクリプトの実行中に第2のトランザクションの表現がメモリに出力されるという条件が満たされる。逆に、署名の検証が失敗する場合、候補メッセージは目標メッセージと同じでなく、したがって、第2のトランザクションの必要とされる表現ではない。
【0092】
まとめると、Alice103aは、ロックスクリプトを有するトランザクションを作成し、それによって、ロックスクリプトのロックが解除されるためには、実行中に消費するトランザクションの表現がメモリ(たとえば、スタック)に出力されなければならない。メモリがスタックベースである例において、検証サブスクリプトは、署名が目標メッセージに有効であることを検証するように構成されるOP_CHECKSIGまたはOP_CHECKSIGVERIFYオペコードを含んでよい。OP_CHECKSIGは、署名が有効である(1)のかまたは有効でない(0)のかに応じて、スタックに1または0を出力する。0は、署名が有効でないことを示す。OP_CHECKSIGVERIFYは、出力を消費し、それが0である場合、実行を失敗させる。
【0093】
第2のトランザクションが有効であるためには、そのとき、検証サブスクリプトによって構築された目標メッセージが、メッセージサブスクリプトによって構築された候補メッセージと一致しなければならないことが分かる。したがって、候補メッセージの異なる部分を構築するために(または候補メッセージの異なる部分として)再利用される候補フィールドのセットが第1のトランザクションのフィールドである場合、それらは、第2のトランザクションのフィールドでもなければならない。これは、目標メッセージが第2のトランザクションの実際のフィールドに基づくからである。したがって、本開示は、第1のトランザクションの一部(たとえば、ロックスクリプト、値、出力など)が第2のトランザクションの同じ部分としても現れることを保証するために使用されてよい。言い換えると、第2のトランザクションの一部が、第1のトランザクションの一部と同じでなければならない。概して、第2のトランザクションの1つまたは複数の部分が、第1のトランザクションの1つまたは複数の部分と同じであることを強制されてよい。
【0094】
上述のように、署名は、ECDSA署名を含んでよい。当業者は、ECDSA署名自体について精通しているであろう。署名は、s = k-1(z + ra) mod nの形態をとってよく、kは、一時プライベート鍵であり、aは、プライベート鍵であり、zは、候補メッセージのハッシュであり、nは、楕円曲線の生成元(generator point)Gの整数位数(integer order)であり、rは、一時公開鍵のx座標のモジュロnである。やはり上で述べられたように、一時プライベート鍵kは、署名の生成を最適化するために1に設定されてよい。署名の生成をさらに最適化するために、プライベート鍵aも、1に設定されてよい。
【0095】
プライベート鍵と一時プライベート鍵との両方を1に決めることは、署名がs = z + Gx mod nの形態をとることを可能にし、Gxは、楕円曲線の生成元Gのx座標である。これは、Gが一時プライベート鍵とプライベート鍵との両方であるという効果を有する。第1のロックスクリプト(たとえば、署名サブスクリプト)は、Gxおよびnのそれぞれの値を含んでよく、それらの値に基づいて署名を生成するように構成されてよい。
【0096】
一部の例において、署名サブスクリプトは、Gxおよびnの値を2回以上使用するように構成される場合がある。メモリがスタックベースである例においては、Gxおよびnを第1のロックスクリプトに複数回含めるのではなく、スペースを節約するために、第1のロックスクリプト(たとえば、署名サブスクリプト)が、Gxおよびnの値を代替スタック(すなわち、第1のロックスクリプトが最初に置かれる主スタック以外のスタック)に出力し、必要とされるときに代替スタックからGxおよびnの値を取り出すように構成される場合がある。
【0097】
プライベート鍵と一時プライベート鍵との両方が同じ値として決められるとき、たとえその値が1でなくても、節約は行われる。それは、署名がECDSA署名または同等の方式の形態をとるとき、署名が一時プライベート鍵の逆数およびプライベート鍵に基づいて計算されるからである。したがって、両方の鍵を同じ値に決めることは、乗算が打ち消される効果を有し、したがって、プロセスから2つの数学演算を取り除く。したがって、スクリプトにおける署名の計算が、簡素化される。さらに、「a=k」による節約は、圧縮された公開鍵Gxが署名のrと同じであり、したがって、(たとえば、下で検討されるようにaltスタック(alt stack)を利用することによって)同じ値が2回使用され得ることにも起因する。
【0098】
ブロックチェーンネットワーク106の特定のブロックチェーンプロトコルによっては、署名サブスクリプトによって生成された署名は、たとえば、検証サブスクリプトによって検証されるために、さらなる処理を必要とする場合がある。たとえば、検証サブスクリプトは、署名が特定のフォーマットであることを要求する署名検証関数(たとえば、オペコード)を含む場合がある。例として、署名は、識別符号化規則(DER: distinguishing encoding rules)に従ってフォーマットされる必要がある場合がある。これらの例において、第1のロックスクリプトは、署名サブスクリプトによって生成された署名をDERフォーマットの署名に変換するように構成されたDERサブスクリプトを含んでよい。DERサブスクリプトは、署名サブスクリプトの一部である場合がある。検証サブスクリプトは、(上述のように、一部の例においては生成元Gである場合がある)公開鍵を使用してDERフォーマットの署名を検証するように構成されてよい。
【0099】
一部の例において、署名サブスクリプトは、署名フラグを含む場合があり、署名サブスクリプトは、生成された署名および署名フラグを関連付ける(たとえば、連結する)ように構成されてよい。署名フラグは、当技術分野においては「sighashフラグ」と呼ばれることがある。署名フラグは、トランザクションのどの部分が署名によって署名されるかを示す。たとえば、署名フラグは、特定の入力および/もしくは出力のみが署名によって署名されること、またはトランザクション全体が署名によって署名されることを示す場合がある。これらの例において、検証サブスクリプトは、署名フラグに基づいて目標メッセージを構築するように構成される。つまり、検証サブスクリプトは、署名サブスクリプトに含まれる署名フラグに応じて、第2のトランザクションの特定の部分に基づいて目標メッセージを構築するように構成される。署名サブスクリプトによって有効な署名とみなされるためには、第2のトランザクションの第1のロック解除スクリプト(および任意で第1のトランザクションの第1のロックスクリプト)に含まれる候補フィールドが、目標メッセージと一致する候補メッセージをもたらさなければならない。言い換えると、候補メッセージは、第2のトランザクションの、目標メッセージと同じ部分に基づいていなければならず、それらの部分は、署名フラグによって指示される。
【0100】
例として、署名フラグは、目標メッセージが第2のトランザクションの各入力および各出力に基づくべきであることを示す場合がある。この場合、署名フラグ(たとえば、sighashフラグ)は、ALLであってよい。別の例として、署名フラグは、目標メッセージが、第1のロック解除スクリプトを含む第2のトランザクションの入力と、第2のトランザクションの対応する出力とにのみに基づくべきであることを示す場合がある。この場合、署名フラグ(たとえば、sighashフラグ)は、SINGLE|ANYONECANPAYであってよい。
【0101】
下の表は、候補(および目標)メッセージの例示的なフォーマットを提供する。候補(および目標)メッセージは、表の項目を連結したものであってよい。項目は、表の対応する番号に基づく順序で現れる場合があり、たとえば、候補(および目標)メッセージは、バージョン番号で始まり、sighashフラグで終わる場合がある。これは単なる例であり、すべての例において限定的であるように意図されていないことに留意されたい。たとえば、項目は、異なる順序で連結される場合があり、または候補(および目標)メッセージは、以下の項目の一部を含むが、すべては含まない場合がある。
【0102】
【表1】
【0103】
この例において、「前の」ロックスクリプトは、第1のトランザクションの第1のロックスクリプトを指す。すべてのその他の項目は、第2のトランザクション自体から取得されるか、または第2のトランザクション自体に基づく。表は、項目が第1のロックスクリプトにおいて決められてよいか否かも示す。たとえば、前の(つまり、第1の)ロックスクリプトを第1のロックスクリプト自体において決めることはできない。第1のロックスクリプトは、ロックスクリプトにおいて決めることが可能な上記の項目のいずれかを含んでよい。データ項目の一部は、第1または第2のトランザクションのフィールドであり(たとえば、「ロック時間」は第2のトランザクションのフィールドである)、一方、データ項目の一部は、第1または第2のトランザクションの1つまたは複数のフィールドに基づく(たとえば、「出力のハッシュ」は、第2のトランザクションの出力に基づき、各出力は、第2のトランザクションのフィールドである)ことに留意されたい。
【0104】
上で検討されたように、第1のロックスクリプトは、第2のトランザクションの第1のロック解除スクリプトに含まれる候補フィールドのうちの1つまたは複数に基づいて、候補メッセージの一部(たとえば、上の表の項目のうちの1つ)を構築するように構成される。つまり、第1のロック解除スクリプトは、候補フィールドのセットを含んでよく、第1のロックスクリプトは、候補フィールドのそのセットを候補メッセージの異なる部分として再利用しながら、候補メッセージの一部を生成するために候補フィールドのそのセットを処理してよい(これは、組合せ、連結、またはハッシュなどのうちの1つまたは複数を含む場合がある)。たとえば、第2のトランザクションの第1のロック解除スクリプトは、第2のトランザクションの候補出力を表すデータ項目を候補フィールドとして含む場合があり、第1のトランザクションの第1のロックスクリプトは、候補出力を、(第1のトランザクションの第1の出力を表す)上の表の項目5、6、および7として、また、(第2のトランザクションの出力のハッシュを表す)上の表の項目9を構築するために使用する場合がある。これを行うために、第1のロックスクリプト(というよりも、メッセージサブスクリプト)が、項目5、6、および7を組み合わせ、ハッシュして、項目9を生成する場合がある。これは、第1のトランザクションの第1の出力が第2のトランザクションの出力とまったく同じであるという条件を強制する。
【0105】
これは、フィールドの同じセットに基づく場合がある候補メッセージのどの部分にも広く当てはまることに留意されたい。たとえば、メッセージサブスクリプトは、前のロックスクリプトの候補値を再利用することなく、候補ロックスクリプトを前のロックスクリプト(項目7)として再利用し、出力のハッシュ(項目9)を生成するように構成される場合がある。これは、第2のトランザクションが第1のトランザクションの第1のロックスクリプトを含む出力を含まなければならないが、出力の値は(ブロックチェーンプロトコルの規則の範囲内で)自由に選択され得るという条件を強制する。
【0106】
7. 例示的な実装
以下で、説明された実施形態の例示的な実装を説明する。
【0107】
7.1 スクリプト内での署名の生成
第1のトランザクションの第1のロックスクリプトの1つの機能は、所与のメッセージmの署名を生成することである。下のスクリプトセグメントは第1のロックスクリプトの一部であり、入力データは、将来のトランザクションのロック解除スクリプト内にあるか、または第1のロックスクリプトにハードコードされているかのどちらかであることが可能である。
[sign]:= OP_HASH256 k-1 OP_MUL k-1ra OP_ADD n OP_MOD r [toDER] SIGHASH_FLAG OP_SWAP OP_CAT
入力データ: m
【0108】
ロックスクリプトの一部としてのスクリプトセグメント[sign](上では「署名サブスクリプト」と呼ばれた)は、一時鍵kとプライベート鍵aとの両方を決める場合がある。誰でも[sign]を使用して有効な署名を生成することができるが、焦点は入力mにある。要件は、いかなる所与の消費するトランザクションに関しても、OP_CHECKSIGに合格し得るmのただ1つの値が存在することである。プライベート鍵または公開鍵が決められない場合、トランザクションは安全でなくなる。詳細は、第8節にも見つけられ得る。一時鍵kが決められない場合、誰でも異なるkを使用して異なるトランザクションIDを持つ有効なトランザクションを作成することが可能であり、これは、一部のユースケース(use case)においては望ましくない。
【0109】
署名のsの値は、s = k-1(z + ra) mod nとして計算されてよい。署名を真正性のために使用していないので、プライベート鍵aおよび一時鍵kは、自由に選択され、公開され得る。この緩和されたケースを考えると、k-1 mod nおよびk-1ra mod nを予め計算し、それらをロックスクリプトに含めて、署名の生成を大幅に軽くすることができる。さらに、kおよびaに1などの小さな値を選択することができ、それらは毎回同じであることが可能である。k = a = 1である場合、s = z + Gx mod nであり、Gxは、生成元Gのx座標である。圧縮された公開鍵も、Gxになる。[sign]の定義は、以下のように書き直され得る。
[sign]:= OP_HASH256 Gx OP_ADD n OP_MOD Gx [toDER] SIGHASH_FLAG OP_SWAP OP_CAT
【0110】
スクリプトセグメント[toDER]は、ペア(r, s)を、OP_CHECKSIGによって受け入れられる規範的DERフォーマットに変換することになる。それは、トランザクションIDの展性(malleability)を避けるために、sが0からn/2までの間の範囲内にあることを強制する。
【0111】
[sign]のSIGHASH_FLAGは、消費するトランザクションのどの部分がスタックにプッシュされるべきかを指定するために使用されることに留意されたい。フラグALLは、すべての入力および出力がメッセージmに含まれることを要求し、一方、SINGLE|ANYONECANPAYは、このロックスクリプトに対応する入力およびそのペアとなる出力がmに含まれることを要求する。
【0112】
入力mでスクリプトセグメントOP_DUP [sign] < PK >を実行した後、底から頂上までのスタックは、[m, Sig, PK]のように見える。OP_CEHCKSIGVERIFYの呼び出しは、署名および公開鍵を消費し、mをスタックの頂上に残す。検証が成功する場合、スタックに残されたメッセージmが、消費するトランザクションの正確な表現であると確信し得る。
【0113】
7.2 スクリプト内でのメッセージの構築
そのシリアライズされたフォーマットの署名されたメッセージは、シリアライズされたトランザクションとは異なる。後者は、トランザクションについてのすべての情報を公表し、一方、署名されたメッセージは、トランザクションについての何らかの情報を意図せずハッシュ値に隠し、消費されている出力についての何らかの情報、すなわち、その出力の値およびその出力のロックスクリプトを提供する。メッセージmは、ロックスクリプト自体と、将来の消費するトランザクションに関する何らかの未知の情報とを含むので、ロックスクリプトに完全に埋め込まれ得ない。フィールドのうちの一部、たとえば、バージョン、シーケンス番号、ロック時間などだけが、ロックスクリプトにおいて明示的に強制され得る。メッセージmは、ロック解除スクリプトにおいてその全体が提供されるか、またはロック解除スクリプトからのいくつかの入力およびロックスクリプトからの命令を用いてスクリプトにおいて構築されるかのどちらかである。後者は、消費するトランザクションの観点から見てより制約的であるので、後者に焦点を当てる。上の第6節の表は、メッセージのすべてのデータフィールドと、それらがロックスクリプトにおいて決められるべきまたは決められ得るかどうかとを捉える。
【0114】
以降、表のデータフィールドは、項目1、2、3などと呼ばれる。ロックスクリプトに項目を含めることが任意であるとき、その項目がロックまたはロック解除スクリプトにおいて提供されるかどうかは、ユースケースに応じて決まる。ロックスクリプトを作成する時点でデータが利用可能であるかまたは知られている場合、それらのデータはロックスクリプトに含められ得るというのが原則である。考慮すべき別の点は、トランザクションのサイズおよびその消費するトランザクションである。ロックスクリプトとロック解除スクリプトとの間でデータをシフトすることによって、2つのトランザクションの送信者の間で取引手数料のコストの一部をシフトすることができる。
【0115】
循環参照が原因で実行不可能と言うとき、粒度(granularity)がデータフィールドに設定されることに留意されたい。たとえば、部分的なロックスクリプトまたはそれどころか部分的なトランザクションID(たとえば、最初の2バイトを固定し、ナンスフィールドでの反復を許す)が、必要に応じてロックスクリプトにおいて決められ得る。
【0116】
焦点はメッセージmを構築することであるが、目標は、mを使用して現在のトランザクションの異なるフィールドに対して値を強制することである。ハッシュ値、すなわち、項目9の背後にあるデータを強制するために、ロックスクリプトは、原像を要求し、スクリプト内でそれをハッシュし、それから、スクリプト内で署名されるメッセージを構築するように設計されるべきである。項目9を例にとると、現在のトランザクションにおいて出力を強制するために、以下のようにし得る。
[outputsRequest]:= OP_DUP OP_HASH256 OP_ROT OP_SWAP OP_CAT <項目10および11> OP_CAT
入力データ: <項目1から8> <現在のトランザクションのシリアライズされた出力>
【0117】
(「メッセージサブスクリプト」の一部であってよい)スクリプトセグメント[outputsRequest]は、スタック上の項目1から8およびシリアライズされた出力を取得して項目9を構築し、項目10および11と連結してスクリプト内でメッセージmを取得する。[outputsRequest]の後に[sign] <Gx> OP_CHECKSIGVERIFYを呼び出し、検証に合格することによって、スタックの頂上に残されたシリアライズされた出力が現在のトランザクションの出力の真の表現であると確信し得る。
【0118】
比較のために<項目1から7>のコピーをスタックに残しておくことも、非常に有用である。これは、スクリプトセグメントを以下のように修正することによって実現され得る。
[outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <項目8> OP_CAT OP_SWAP OP_CAT <項目10および11> OP_CAT
入力データ: <項目1から7> <現在のトランザクションのシリアライズされた出力>
【0119】
修正された[outputsRequest]を入力データに対して実行した後、メッセージを消費するために[sign] <Gx> OP_CHECKSIGVERIFYを呼び出すことができる。スタックは、頂上に現在のシリアライズされた出力を有し、それに続いて<項目1から7>を有する。
【0120】
<項目1から7>のように、連続する項目がまとめてグループ化されると、より簡単である。それらの項目は、すべてロック解除スクリプト内にあるか、またはすべてロックスクリプトにおいて決められるかのどちらかである。しかし、より複雑なスクリプトを持つという潜在的な代償を払えば、よりきめ細かい手法が利用可能である。
【0121】
現在の出力のためのシリアライズのフォーマットは、以下であることに留意されたい。
a. 出力の値8バイトの(リトルエンディアン)、
b. ロックスクリプトの長さ、
c. ロックスクリプト、および
d. 2つ以上の出力がある場合は、シリアライズされた出力を順序正しく連結する。
【0122】
署名されたメッセージの前の出力(項目5から7)のシリアライズのフォーマットは、以下である。
a. ロックスクリプトの長さ、
b. ロックスクリプト、および
c. 出力の値8バイト(リトルエンディアン)。
【0123】
下の例においては、前の出力を現在の消費するトランザクションの出力と比較し、それらが同一であることを強制する。2つのフォーマットは、比較のためのロックスクリプトを設計するために有用である。
【0124】
7.3 永続的強制ロックスクリプト
Aliceがルート認証局(CA)であり、Bobが下位CAであるものとする。Aliceは、Bobが証明書の証明(attestation)としてトランザクションをオンチェーンで公開することを要求する何らかの作業をBobに委任する。Aliceは、Bobに出力を他のことに消費してほしくない。したがって、Aliceは、すべての後続の消費するトランザクションが、決まった[P2PKH Bob]ロックスクリプトおよび決まった出力値を有すること強制する。Bobは、有効な署名を生成することができるので、出力を消費することができるが、同額を自分に送る以外にいかなる出力も選択することができない。
【0125】
Aliceは、図6に示されるように最初のトランザクションを構築する。
【0126】
スクリプトセグメントは、以下に定義される。
[outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <項目8> OP_CAT OP_SWAP OP_CAT <項目10および11> OP_CAT
[sign]:= OP_HASH256 Gx OP_ADD n OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT Gcompressed
[toDER]:= [toCanonical][concatenations]
[toCanonical]:= OP_DUP n/2 OP_GREATERTHAN OP_IF n OP_SWAP OP_SUB OP_ENDIF
[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT <0220||Gx> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
【0127】
ロックスクリプトの長さは、(7+12) + (6 + 32 + 32 + 33) + (6 + 32 + 32) + (11) + (15 + 34) + (14 + 20) = 286 = 0x011eである。
【0128】
項目8は、0xFFFFFFFFである場合があり、項目10は、0x00000000である場合があり、項目11は、0x41000000である場合があることに留意されたい。
【0129】
トランザクションを消費するために、Bobは、図7に示されるように消費するトランザクションを作成する。図7を参照すると、入力のData1は、項目1から7を表し、以下のように記述され得る。
010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044TxID000000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}e803000000000000
【0130】
【表2】
【0131】
Data2は、TxID1の出力(値 || ロックスクリプト長 || ロックスクリプト)を表し、以下のように記述され得る。
e803000000000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
【0132】
TxID1の承認中に実行される完全なスクリプトは、以下である。
<SigB> <PKB> <Data1> <Data2> [outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
【0133】
最初のOP_CHECKSIGVERIFYの後、スタック上(頂上の右端)に< SigB > < PKB > < Data1 > < Data2 >を持つ。
【0134】
【表3】
【0135】
TxID1のサイズは、バージョン + ロック時間 + 入力 + 出力 = 4 + 4 + (36 + 72 + 33 + 104 + 287 + 8 + 287 + 8 + 4) + (8 + 287) = 1142バイトである。
【0136】
現在の設定を考慮して、Bobは、取引手数料を賄うために自身の入力を追加することができる。Aliceがスクリプトセグメント[sign]においてSIGHASH_SINGLE|ANYONECANPAYを使用する場合、Bobは、お釣りをもらうための別の出力を追加することができる。これは、Aliceのロックスクリプトによる強制を事実上永続的にする。これをAliceとBobとの間のスマートコントラクトと考えることが可能である。
【0137】
ロックスクリプトが取引手数料を考慮に入れることも可能である。ステップ3の後、スタックの一番上の要素は、前の出力からの値である。ステップ4の連結の前に<TxFee> OP_SUBを追加することによって、Bobが前の出力から取引手数料を支払うことを可能にする。これは、消費につれて出力の値を減らすことにつながり、それは、Bobが資格を与えられる消費の総数を設定するので、望ましい特徴として働き得る。
【0138】
7.4 最適化
Data1がData2を含むとき、Data1からData2を構築することができる。言い換えると、現在の出力が以前の出力と同一であると仮定し、前の出力を使用してメッセージを構築する。そのメッセージがOP_CHECKSIGに合格する場合、2つの出力は同一でなければならない。[outputsRequest]のスクリプトセグメントは、以下のように書き直され得る。
[outputsRequest]:= OP_2DUP OP_CAT OP_TOALTSTACK OP_SWAP OP_CAT OP_HASH256 <項目8> OP_SWAP OP_CAT OP_FROMALTSTACK OP_SWAP OP_CAT OP_CAT <項目10および11> OP_CAT
入力データ: <項目1から4> <項目5および6> <項目7>
【0139】
この新しい[outputsRequest]を用いて、TxID0およびTxID1のロックスクリプトを
[outputsRequest][sign] OP_CHECKSIGVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG
のように更新し、ロック解除スクリプトを< SigB > < PKB > < Data1 > < Data2 > < Data3 >のように更新し、Data1は、項目1から4、すなわち、
010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044TxID000000000
であり、Data2は、項目5および6、すなわち、
011b{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP <0x68> OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160 <H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}
であり、Data3は、項目7、すなわち、e803000000000000である。
【0140】
TxID1のサイズは、941バイトである。ステップバイステップの実行が、以下に与えられ、ステップ1から5は、[outputsRequest]からのものである。
【0141】
【表4】
【0142】
Gxおよびnを記憶するためにaltスタックを使用することによって、さらなる改善がなされ得る。Gxおよびnの各々は、32バイトのサイズである。GcompressはGxであり、
【0143】
【数1】
【0144】
がnから導出され得るので、いくつかのオペコードを使用してaltスタックからそれらを参照することができる。
前:
[sign]:= OP_HASH256 Gx OP_ADD n OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT Gx
[toDER]:= [toCanonical][concatenations]
[toCanonical]:= OP_DUP n/2 OP_GREATERTHAN OP_IF n OP_SWAP OP_SUB OP_ENDIF
[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT <0220||G_x> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
後:
[sign]:= OP_HASH256 Gx OP_DUP OP_TOALTSTACK OP_ADD n OP_DUP OP_TOALTSTACK OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT OP_FROMALTSTACK
[toDER]:= [toCanonical][concatenations]
[toCanonical]:= OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_2 OP_DIV OP_GREATERTHAN OP_IF OP_FROMALTSTACK OP_SWAP OP_SUB OP_ENDIF
[concatenations]:= OP_SIZE OP_DUP <0x24> OP_ADD <0x30> OP_SWAP OP_CAT <0220> OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT
【0145】
15個のオペコードを追加し、Gxの2つのインスタンスおよびnの2つのインスタンスを削除した。節約の総量は、(32×2 + 32×2) - 15 = 113バイトである。したがって、消費するトランザクションTxID1のサイズは、828バイトまでさらに削減され得る。
【0146】
図8は、消費するトランザクションの最適化されたバージョンを示す。
【0147】
8. セキュリティ分析
主張(assertion)1: (r, s)が公開鍵Pに関してメッセージmとm'との両方に対する有効な署名である場合、m = m'である。
証明: z = hash(m)およびz' = hash(m')とする。
u = zs-1 mod n、u' = z's-1 mod n、およびv = rs-1 mod nとする。
したがって、[uG + vP]x = [u'G + vP]x = r mod nを得る。
⇒ uG = u'G
⇒ u = u' mod n
⇒ z = z' mod n
⇒ m = m'
【0148】
主張2: 公開鍵Pはロックスクリプトにおいて決められなければならない。
根拠(reasoning):
Pが決められず、(r, s)がPに関してmに対する有効な署名であると仮定する。
z' = hash(m')、u' = z's-1、およびv = rs-1とする。
u'G + vP' = RであるようなP'を求めたい。
P' = v-1(R - u'G)
今や(r, s)は、P'に関してm'に対して有効である。
したがって、Pはロックスクリプトにおいて決められなければならない。
【0149】
主張3: kはロックスクリプトにおいて決められるべきである。
根拠:
(r, s)が、Pに関してmに対してロックスクリプトにおいて生成された有効な署名であると仮定する。
kがロックスクリプトにおいて決められず、ロック解除スクリプトにおいて提供されると仮定する。
そのとき、敵対者は、
1. 消費するトランザクションを横取りすることができ、
2. ロック解除スクリプトにおいてkをk'で置き換えることができる。
そして、ロックスクリプトにおいて生成された(r', s')が、Pに関してmに対する有効な署名となる。
トランザクションは引き続き有効であるが、トランザクションIDが変更される。
【0150】
主張4: sighashフラグはロックスクリプトにおいて決められるべきである。
根拠:
(r, s)が、Pに関してmに対してロックスクリプトにおいて生成された有効な署名であると仮定する。
sighashフラグがロックスクリプトにおいて決められず、ロック解除スクリプトにおいて提供されると仮定する。
1. 消費するトランザクションを横取りする
2. sighashフラグを変更する
3. それに応じてメッセージmをm'に更新する
あるユースケースにおいて、これは、トランザクションを無効にする。たとえば、ロックスクリプトは、sighashフラグ「ALL」によって複数の入力および出力を期待し、フラグを他のいずれのものに変更することも、スクリプトの実行を無効にする。
その他のユースケースにおいて、これは、トランザクションを無効にすることなくトランザクションIDを変更する。たとえば、ロックスクリプトは、その消費するトランザクションの出力に対する条件のみ強制し、「ANYONECANPAY」を追加または削除することが、トランザクションを無効にしないが、トランザクションIDを変更する。
【0151】
9. 例示的なスクリプト
テストは、1415バイトのサイズの消費するトランザクションを実現することが可能であることを示した。オーバーヘッドは、主にエンディアンの反転から生じる。32バイト列は、そのエンディアンを反転させるために124バイトのオペコードを必要とし、一部の例では、ロックスクリプトにおいて2つの列のエンディアンを反転させることが必要である。ロックスクリプトは、ロック解除スクリプトと出力との両方に現れる。したがって、我々の実装におけるエンディアンによる合計のオーバーヘッドは、500バイトを超えている。我々は、簡単にするために、我々の現在の実装においてはGxおよびnを記憶するためにAltスタックを使用しなかった。これは、我々に合計で200バイト節約させるであろう。
【0152】
9.1 ロックスクリプト1(LS1) - generateSigおよびcheckSig
"aa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac"
入力: 第6節の表に示された、署名のためのシリアライズされたトランザクションメッセージ。
【0153】
ロックスクリプトは、メッセージmを取得し、
1. mに対してdouble SHA256を行ってzを取得し、
2. zのエンディアンを反転させ、
3. zが負数と解釈されないことを保証するために0x00を加え、
4. OP_BIN2NUMを呼び出してzに対する最小限の符号化を得て(ステップ3が冗長性を導入するときの場合に対処する)、
5. s = z + Gx mod nを計算し、
6. s > n/2である場合、sをn - sに変換し、
7. sの長さを取得し、
8. sのエンディアンを反転させ(32バイト)、
9. sの長さが32より長い場合、もう1バイト反転させ、
10. DER署名の全長(0x24 + sの長さ)を計算し、
11. DER接頭辞0x30を加え、
12. r = Gxを連結し、
13. sを連結し、
14. sighashフラグ「ALL」を連結し、
15. 圧縮された公開鍵をプッシュし、
16. OP_CHECKSIGを呼び出す。
【0154】
9.2 ロックスクリプト2(LS2) - constructMsg + LS1 + P2PKH
"6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac"
入力: <Sig> <PK> <項目1から4> <項目5および6> <項目7>
【0155】
ロックスクリプトは、3つのPUSHDATA動作で、署名と公開鍵とのペア、および第6節の表にあるような項目1から7を取得し、
1. 前の値を取得し、新しい出力値を計算し(決まった取引手数料を引く)、
2. 前のロックスクリプトを、新しい出力のための新しいロックスクリプトとして取得し、
3. 新しい出力値と新しいロックスクリプトとを連結して新しい出力を取得し、
4. 新しい出力にdouble SHA256を行って、出力のハッシュ(項目9)を取得し、
5. シーケンス番号(項目8)をプッシュし、
6. 連結してメッセージ列(項目1から9)を得て、
7. ロック時間およびsighashフラグ(項目10および11)をプッシュし、
8. 連結して署名されるメッセージmを取得し、
9. OP_CHECKSIGVERIFYをともなうLS1を呼び出し、
10. PKに関してSigをチェックするためにP2PKHを呼び出す。
【0156】
9.3 トランザクション0 - ジェネシストランザクション
{
"txid": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
"hash": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
"version": 1,
"size": 730,
"locktime": 0,
"vin": [
{
"txid": "52685bdbaae5c76887c23cee699bc48f293192a313c19b9fad4c77b993655df5",
"vout": 0,
"scriptSig": {
"asm": "3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a5[ALL|FORKID] 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
"hex": "473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a541210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 49.99999388,
"n": 0,
"scriptPubKey": {
"asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT 0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM 9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 2 OP_DIV OP_GREATERTHAN OP_IF 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT 022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIGVERIFY OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac",
"type": "nonstandard"
}
}
],
"hex": "0100000001f55d6593b9774cad9f9bc113a39231298fc49b69ee3cc28768c7e5aadb5b6852000000006a473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a541210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ffffffff019cef052a01000000fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac00000000"
}
【0157】
9.4 トランザクション1 - 消費するトランザクション
{
"txid": "c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8",
"hash": "c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8",
"version": 1,
"size": 1415,
"locktime": 0,
"vin": [
{
"txid": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34",
"vout": 0,
"scriptSig": {
"asm": "3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed34[ALL|FORKID] 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 01000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b98800000000 fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac 9cef052a01000000",
"hex": "473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed3441210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817984c6801000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b988000000004d3502fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac089cef052a01000000"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 49.99998876,
"n": 0,
"scriptPubKey": {
"asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT 0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM 9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 2 OP_DIV OP_GREATERTHAN OP_IF 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT 022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIGVERIFY OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "6e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac",
"type": "nonstandard"
}
}
],
"hex": "010000000134ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b98800000000fd1503473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817980220388bd5f619c02287145cf0bb3bc440f883b09e35e67a4adcf50635800219ed3441210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817984c6801000000fb472de1f838d9560dc7b19b1ab62b0c6ed60580779017d3cd32d22bcc051ce13bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504434ca0c37a8bcb75db331e9fbc34b976fd93738a70cf883b264c0a40111d4b988000000004d3502fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac089cef052a01000000ffffffff019ced052a01000000fd32026e810200029458807c7eaa04ffffffff7c7e7e7e7e0800000000410000007eaa517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e01007e81209817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be799321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00977621414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff005296a06321414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff007c946882766b6b517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f517f6c0120a063517f687c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e7c7e6c0120a0637c7e68827601249301307c7e23022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798027e7c7e7c7e01417e210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ad76a914751e76e8199196d454941c45d1b3a323f1433bd688ac00000000"
}
【0158】
10. 結論
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
【0159】
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104の観点で説明された。しかし、ビットコインブロックチェーンは、ブロックチェーン150の1つの特定の例であり、上の説明は、任意のブロックチェーンに広く当てはまる可能性があることが理解されるであろう。すなわち、本発明は、ビットコインブロックチェーンに決して限定されない。より広く、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のすべての言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104への言及に置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された特性の一部またはすべてを共有する場合がある。
【0160】
本発明の好ましい実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークであり、ビットコインノード104が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。これらの機能のうちの1つまたは一部だけを実行するが、すべては実行しないその他のネットワークエンティティ(またはネットワーク要素)が存在する可能性があることは、排除されない。すなわち、ネットワークエンティティが、ブロックを作成および公開することなく、ブロックを伝播および/または記憶する機能を実行する場合がある(これらのエンティティは、好ましいビットコインネットワーク106のノードとはみなされないことを思い出されたい)。
【0161】
本発明のその他の実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークではない場合がある。これらの実施形態においては、ノードが、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたは一部を実行するが、すべては実行しない場合があることは排除されない。たとえば、それらのその他のブロックチェーンネットワーク上で、「ノード」は、ブロック151を作成および公開するように構成されるが、それらのブロック151を記憶および/またはその他のノードに伝播するように構成されないネットワークエンティティを指すために用いられる場合がある。
【0162】
さらに一層広く、上記の用語「ビットコインノード」104へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関連して上で説明された同じ方法でハードウェアに実装されてよい。
【0163】
上記の実施形態は、例としてだけ説明されたことが理解されるであろう。より広く、以下のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供されてよい。
【0164】
ステートメント1.
第1のブロックチェーントランザクションを使用して第2のブロックチェーントランザクションに対して条件を強制するコンピュータ実施方法であって、条件のうちの第1の条件が、第2のトランザクションの第1のロック解除スクリプトが第1のトランザクションの第1のロックスクリプトとともに実行されるときに、第2のトランザクションの表現がメモリに出力されることであり、表現が、第2のトランザクションの複数のフィールドおよび第1のトランザクションの第1の出力に基づき、方法が、
第1のトランザクションを生成するステップであって、第1のトランザクションが、第1の出力を含み、第1の出力が、第1のロックスクリプトを含み、第1のロックスクリプトが、
実行されるときに、第2のトランザクションを表す候補メッセージをメモリに出力するように構成されたメッセージサブスクリプトであって、候補メッセージが、第1のトランザクションおよび第2のトランザクションの複数の候補フィールドに基づき、候補フィールドのうちの1つまたは複数が、第2のトランザクションの第1のロック解除スクリプトに含まれ、メッセージサブスクリプトが、候補フィールドのそれぞれのセットに基づいて候補メッセージの1つまたは複数のそれぞれの部分を生成し、候補メッセージの異なるそれぞれの部分として候補フィールドのそれぞれのセットのうちの少なくとも1つを再利用するように構成される、メッセージサブスクリプトと、
実行されるときに署名を生成するように構成された署名サブスクリプトであって、署名が、少なくとも、候補メッセージ、プライベート鍵、および一時プライベート鍵の関数である、署名サブスクリプトと、
プライベート鍵に対応する公開鍵と、
実行されるときに、i)第2のトランザクションを表す目標メッセージを構築することであって、目標メッセージが、第2のトランザクションの複数のフィールドおよび第1のトランザクションの第1の出力に基づく、構築すること、ならびにii)公開鍵を使用して、署名が目標メッセージに有効であることを検証することであって、署名が目標メッセージに有効であることを検証することが、目標メッセージが候補メッセージと一致することを検証し、それによって、メモリに出力された候補メッセージが第2のトランザクションの表現であるという条件を強制する、検証することを行うように構成された検証サブスクリプトとを含む、ステップを含む、コンピュータ実施方法。
【0165】
目標メッセージが候補メッセージと一致し、候補メッセージが第2のトランザクションの表現であることを検証することは、署名が目標メッセージに有効であることの結果である。
【0166】
ステートメント2.
候補メッセージの前記それぞれの部分のうちの1つが、第2のトランザクションの1つまたは複数の出力のハッシュを含み、
候補フィールドの第1のそれぞれのセットが、a)第1のトランザクションの第1のロックスクリプトのそれぞれの長さ、およびb)第1のトランザクションの第1のロックスクリプトを含み、
メッセージサブスクリプトが、実行されるときに、候補フィールドa)およびb)に基づいて1つまたは複数の出力のハッシュを生成し、それによって、第2のトランザクションの第1の出力が第1のトランザクションの第1のロックスクリプトを含むという条件を強制するように構成されるステートメント1の方法。
【0167】
ステートメント3.
候補フィールドの第1のそれぞれのセットが、c)第1のトランザクションの第1のロックスクリプトによってロックされたそれぞれの値を含み、
メッセージサブスクリプトが、実行されるときに、候補フィールドa)、b)、およびc)に基づいて1つまたは複数の出力のハッシュを生成し、それによって、第2のトランザクションの第1の出力が第1のトランザクションの第1の出力を含むという条件を強制するように構成されるステートメント2の方法。
【0168】
ステートメント4.
メッセージサブスクリプトが、候補メッセージの1つまたは複数のそれぞれの部分のうちの少なくとも1つをメモリに出力するように構成されるいずれかの前述のステートメントの方法。
【0169】
ステートメント5.
メッセージサブスクリプトが、実行されるときに、候補フィールドのうちの少なくとも1つまたは候補フィールドのそれぞれのセットを、候補メッセージの異なるそれぞれの部分として再利用されるように候補メッセージの一部として複製するように構成されるいずれかの前述のステートメントの方法。
【0170】
ステートメント6.
第1のロックスクリプトが、実行されるときに署名を識別符号化規則DERフォーマットの署名に変換するように構成されたDERサブスクリプトを含み、公開鍵を使用して、署名が目標メッセージに有効であることを検証することが、公開鍵を使用して、DERフォーマットの署名がメッセージに有効であることを検証することを含むいずれかの前述のステートメントの方法。
【0171】
ステートメント7.
署名サブスクリプトが、第2のトランザクションの複数のフィールドのうちのどれが目標メッセージの基礎を形成するべきかを指定する署名フラグを含み、検証サブスクリプトが、署名フラグに基づいて目標メッセージを構築するように構成されるいずれかの前述のステートメントの方法。
【0172】
ステートメント8.
署名フラグが、第2のトランザクションの各入力および各出力が目標メッセージの基礎を形成するべきであることを指定するステートメント7の方法。
【0173】
ステートメント9.
署名フラグが、a)第2のトランザクションの第1のロック解除スクリプトを含む第1の入力と、b)第1の入力とペアにされる第2の第1の出力とが目標メッセージの基礎を形成するべきであることを指定するステートメント7の方法。
【0174】
ステートメント10.
候補フィールドのうちの1つまたは複数が、第1のトランザクションの第1のロックスクリプトに含まれるいずれかの前述のステートメントの方法。
【0175】
ステートメント11.
以下の候補フィールド、すなわち、
- 第2のトランザクションのバージョン番号、
- 第1のトランザクションの第1のロックスクリプトの長さ、
- 第1のトランザクションの第1のロックスクリプトの値、
- 第2のトランザクションの第1の入力のシーケンス番号、
- 第2のトランザクションのロック時間、
- 第2のトランザクションの第1のロック解除スクリプトの署名フラグ
のうちの1つまたは複数が、第1のトランザクションの第1のロックスクリプトに含まれるステートメント10の方法。
【0176】
ステートメント12.
第2のトランザクションを表す候補メッセージが、第2のトランザクションの1つまたは複数のそれぞれの候補フィールドのそれぞれのセットに基づく1つまたは複数のそれぞれのデータ項目を含むいずれかの前述のステートメントの方法。
【0177】
ステートメント13.
1つまたは複数のそれぞれのデータ項目が、
- 第2のトランザクションの入力シーケンス番号のハッシュ、
- 第2のトランザクションの組み合わされた出力のハッシュ
のうちの1つまたは複数を含むステートメント12の方法。
【0178】
ステートメント14.
メモリが、スタックベースのメモリであるいずれかの前述のステートメントの方法。
【0179】
ステートメント15.
署名検証サブスクリプトが、OP_CHECKSIGVERIFYオペコードおよびOP_CHECKSIGオペコードの少なくとも一方を含むステートメント14の方法。
【0180】
ステートメント16.
第1のトランザクションをブロックチェーンネットワークの1つまたは複数のノードに利用可能にするステップを含むいずれかの前述のステートメントの方法。
【0181】
ステートメント17.
第1のトランザクションを、第2のトランザクションを生成するために関係者に利用可能にするステップを含むいずれかの前述のステートメントの方法。
【0182】
ステートメント18.
一時プライベート鍵が、1に等しいものと第1のロックスクリプトによって決められ、および/または一時プライベート鍵が、プライベート鍵と等しいものと決められるいずれかの前述のステートメントの方法。
【0183】
ステートメント19.
プライベート鍵が、1に等しいものと第1のロックスクリプトによって決められるステートメント17の方法。
【0184】
ステートメント20.
署名が、s = k-1(z + ra) mod nの形態であり、kが、一時プライベート鍵であり、aが、プライベート鍵であり、zが、候補メッセージのハッシュであり、nが、楕円曲線の生成元Gの整数位数であり、rが、一時公開鍵のx座標のモジュロnであるステートメント18またはステートメント19の方法。
【0185】
ステートメント21.
署名が、s = z + Gx mod nの形態であり、Gxが、楕円曲線の生成元Gのx座標であり、Gが、一時公開鍵と公開鍵との両方であるステートメント18またはそれに従属するいずれかのステートメントの方法。
【0186】
ステートメント22.
署名サブスクリプトが、Gxおよびnのそれぞれの値を含み、署名が、Gxおよびnのそれぞれの値に基づいて生成されるステートメント21の方法。
【0187】
ステートメント23.
スタックベースのメモリが、主スタックおよび代替スタックを含み、第1のロックスクリプトが、Gxおよびnのそれぞれの値を2回以上使用するように構成され、第1のロックスクリプトが、実行されるときに、Gxおよびnのそれぞれの値を代替スタックに出力し、初回以外にGxおよびnのそれぞれの値が必要とされるたびに、Gxおよびnのそれぞれの値を代替スタックから取得するように構成されるステートメント21およびステートメント22の方法。
【0188】
ステートメント24.
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、メモリが、処理装置上で実行されるように配置されたコードを記憶し、コードが、処理装置上にあるときに、ステートメント1から23のいずれかの方法を実行するように構成される、処理装置とを含むコンピュータ機器。
【0189】
ステートメント25.
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、ステートメント1から23のいずれかの方法を実行するように構成されたコンピュータプログラム。
【符号の説明】
【0190】
100 システム
101 パケット交換ネットワーク
102 コンピュータ端末、コンピュータ機器
102a コンピュータ機器
102b コンピュータ機器
103 ユーザ、関係者、エージェント
103a ユーザ、第1の関係者、Alice
103b 新しいユーザまたはエンティティ、第2の関係者、Bob
104 ブロックチェーンノード、ビットコインノード
105 クライアントアプリケーション
105a クライアントアプリケーション
105b クライアント
106 ピアツーピア(P2P)ネットワーク、ブロックチェーンネットワーク、ビットコインネットワーク
107 サイドチャネル
150 ブロックチェーン、ビットコインブロックチェーン
151 データのブロック
151n-1 前に作成されたブロック
151n 新しいブロック
152 トランザクション
152i 先行トランザクション
152j 現在のトランザクション、オンワードトランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット(または「プール」)
155 ブロックポインタ
201 ヘッダ
202 入力
203 出力
401 トランザクションエンジン
402 ユーザインターフェース(UI)レイヤ
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル判断エンジン
455 ブロックチェーン関連機能モジュール
455C コンセンサスモジュール
455P 伝播モジュール
455S ストレージモジュール
500 ユーザインターフェース(UI)
501 UI要素、ユーザが選択可能な要素
502 UI要素、データ入力フィールド
503 情報要素
図1
図2
図3A
図3B
図4
図5
図6
図7
図8
【手続補正書】
【提出日】2024-03-19
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
第1のブロックチェーントランザクションを使用して第2のブロックチェーントランザクションに対して条件を強制するコンピュータ実施方法であって、前記条件のうちの第1の条件が、第2のトランザクションの第1のロック解除スクリプトが第1のトランザクションの第1のロックスクリプトとともに実行されるときに、前記第2のトランザクションの表現がメモリに出力されることであり、前記表現が、前記第2のトランザクションの複数のフィールドおよび前記第1のトランザクションの第1の出力に基づき、前記コンピュータ実施方法が、
前記第1のトランザクションを生成するステップであって、前記第1のトランザクションが、第1の出力を含み、前記第1の出力が、前記第1のロックスクリプトを含み、前記第1のロックスクリプトが、
実行されるときに、前記第2のトランザクションを表す候補メッセージをメモリに出力するように構成されたメッセージサブスクリプトであって、前記候補メッセージが、前記第1のトランザクションおよび前記第2のトランザクションの複数の候補フィールドに基づき、前記候補フィールドのうちの1つまたは複数が、前記第2のトランザクションの前記第1のロック解除スクリプトに含まれ、前記メッセージサブスクリプトが、前記候補フィールドのそれぞれのセットに基づいて前記候補メッセージの1つまたは複数のそれぞれの部分を生成し、前記候補メッセージの異なるそれぞれの部分として候補フィールドの前記それぞれのセットのうちの少なくとも1つを再利用するように構成される、メッセージサブスクリプトと、
実行されるときに署名を生成するように構成された署名サブスクリプトであって、前記署名が、少なくとも、前記候補メッセージ、プライベート鍵、および一時プライベート鍵の関数である、署名サブスクリプトと、
前記プライベート鍵に対応する公開鍵と、
実行されるときに、i)前記第2のトランザクションを表す目標メッセージを構築することであって、前記目標メッセージが、前記第2のトランザクションの複数のフィールドおよび前記第1のトランザクションの前記第1の出力に基づく、構築すること、ならびにii)前記公開鍵を使用して、前記署名が前記目標メッセージに有効であることを検証することであって、前記署名が前記目標メッセージに有効であることを検証することが、前記目標メッセージが前記候補メッセージと一致することを検証し、それによって、メモリに出力された前記候補メッセージが前記第2のトランザクションの前記表現であるという条件を強制する、検証することを行うように構成された検証サブスクリプトとを含む、ステップを含む、コンピュータ実施方法。
【請求項2】
前記候補メッセージの前記それぞれの部分のうちの1つが、前記第2のトランザクションの1つまたは複数の出力のハッシュを含み、
前記候補フィールドの第1のそれぞれのセットが、a)前記第1のトランザクションの前記第1のロックスクリプトのそれぞれの長さ、およびb)前記第1のトランザクションの前記第1のロックスクリプトを含み、
前記メッセージサブスクリプトが、実行されるときに、候補フィールドa)およびb)に基づいて前記1つまたは複数の出力の前記ハッシュを生成し、それによって、前記第2のトランザクションの第1の出力が前記第1のトランザクションの前記第1のロックスクリプトを含むという条件を強制するように構成される、請求項1に記載の方法。
【請求項3】
前記候補フィールドの前記第1のそれぞれのセットが、c)前記第1のトランザクションの前記第1のロックスクリプトによってロックされたそれぞれの値を含み、
前記メッセージサブスクリプトが、実行されるときに、候補フィールドa)、b)、およびc)に基づいて前記1つまたは複数の出力の前記ハッシュを生成し、それによって、前記第2のトランザクションの第1の出力が前記第1のトランザクションの前記第1の出力を含むという条件を強制するように構成される、請求項2に記載の方法。
【請求項4】
前記メッセージサブスクリプトが、前記候補メッセージの前記1つまたは複数のそれぞれの部分のうちの少なくとも1つを前記メモリに出力するように構成される、請求項1に記載の方法。
【請求項5】
前記メッセージサブスクリプトが、実行されるときに、候補フィールドのうちの前記それぞれのセットの前記少なくとも1つを、前記候補メッセージの前記異なるそれぞれの部分として再利用されるように前記候補メッセージの一部として複製するように構成される、請求項1に記載の方法。
【請求項6】
前記第1のロックスクリプトが、実行されるときに前記署名を識別符号化規則DERフォーマットの署名に変換するように構成されたDERサブスクリプトを含み、前記公開鍵を使用して、前記署名が前記目標メッセージに有効であることを検証することが、前記公開鍵を使用して、前記DERフォーマットの署名が前記目標メッセージに有効であることを検証することを含む、請求項1に記載の方法。
【請求項7】
前記署名サブスクリプトが、前記第2のトランザクションの前記複数のフィールドのうちのどれが前記目標メッセージの基礎を形成するべきかを指定する署名フラグを含み、前記検証サブスクリプトが、前記署名フラグに基づいて前記目標メッセージを構築するように構成される、請求項1に記載の方法。
【請求項8】
前記署名フラグが、前記第2のトランザクションの各入力および各出力が前記目標メッセージの前記基礎を形成するべきであることを指定する、請求項7に記載の方法。
【請求項9】
前記署名フラグが、a)前記第2のトランザクションの前記第1のロック解除スクリプトを含む第1の入力と、b)前記第1の入力とペアにされる前記第2のトランザクションの第1の出力とが前記目標メッセージの前記基礎を形成するべきであることを指定する、請求項7に記載の方法。
【請求項10】
前記候補フィールドのうちの1つまたは複数が、前記第1のトランザクションの前記第1のロックスクリプトに含まれる、請求項1に記載の方法。
【請求項11】
以下の候補フィールド、すなわち、
- 前記第2のトランザクションのバージョン番号、
- 前記第1のトランザクションの前記第1のロックスクリプトの長さ、
- 前記第1のトランザクションの前記第1のロックスクリプトの値、
- 前記第2のトランザクションの第1の入力のシーケンス番号、
- 前記第2のトランザクションのロック時間、
- 前記第2のトランザクションの前記第1のロック解除スクリプトの署名フラグ
のうちの1つまたは複数が、前記第1のトランザクションの前記第1のロックスクリプトに含まれる、請求項10に記載の方法。
【請求項12】
前記第2のトランザクションを表す前記候補メッセージが、前記第2のトランザクションの1つまたは複数のそれぞれの候補フィールドのそれぞれのセットに基づく1つまたは複数のそれぞれのデータ項目を含む、請求項1に記載の方法。
【請求項13】
前記1つまたは複数のそれぞれのデータ項目が、
- 前記第2のトランザクションの入力シーケンス番号のハッシュ、
- 前記第2のトランザクションの組み合わされた出力のハッシュ
のうちの1つまたは複数を含む、請求項12に記載の方法。
【請求項14】
前記メモリが、スタックベースのメモリである、請求項1に記載の方法。
【請求項15】
前記検証サブスクリプトが、OP_CHECKSIGVERIFYオペコードおよびOP_CHECKSIGオペコードの少なくとも一方を含む、請求項14に記載の方法。
【請求項16】
前記第1のトランザクションをブロックチェーンネットワークの1つまたは複数のノードに利用可能にするステップを含む、請求項1に記載の方法。
【請求項17】
前記第1のトランザクションを、前記第2のトランザクションを生成するために関係者に利用可能にするステップを含む、請求項1に記載の方法。
【請求項18】
前記一時プライベート鍵が、1に等しいものと前記第1のロックスクリプトによって決められ、および/または前記一時プライベート鍵が、前記プライベート鍵と等しいものと決められる、請求項1に記載の方法。
【請求項19】
前記プライベート鍵が、1に等しいものと前記第1のロックスクリプトによって決められる、請求項18に記載の方法。
【請求項20】
前記署名が、s = k-1(z + ra) mod nの形態であり、kが、前記一時プライベート鍵であり、aが、前記プライベート鍵であり、zが、前記候補メッセージのハッシュであり、nが、楕円曲線の生成元Gの整数位数であり、rが、一時公開鍵のx座標のモジュロnである、請求項18に記載の方法。
【請求項21】
前記署名が、s = z + Gx mod nの形態であり、Gxが、楕円曲線の生成元Gのx座標であり、Gが、一時公開鍵と前記公開鍵との両方である、請求項18に記載の方法。
【請求項22】
前記署名サブスクリプトが、Gxおよびnのそれぞれの値を含み、前記署名が、Gxおよびnの前記それぞれの値に基づいて生成される、請求項21に記載の方法。
【請求項23】
スタックベースのメモリが、主スタックおよび代替スタックを含み、前記第1のロックスクリプトが、Gxおよびnのそれぞれの値を2回以上使用するように構成され、前記第1のロックスクリプトが、実行されるときに、Gxおよびnの前記それぞれの値を前記代替スタックに出力し、初回以外にGxおよびnの前記それぞれの値が必要とされるたびに、Gxおよびnの前記それぞれの値を前記代替スタックから取得するように構成される、請求項21に記載の方法。
【請求項24】
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置であって、前記メモリが、前記処理装置上で実行されるように配置されたコードを記憶し、前記コードが、前記処理装置上にあるときに、請求項1から23のいずれか一項に記載の方法を実行するように構成される、処理装置とを含む、コンピュータ機器。
【請求項25】
コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されるときに、請求項1から23のいずれか一項に記載の方法を実行するように構成された、コンピュータプログラム。
【国際調査報告】