特表2025-503334 | 知財ポータル「IP Force」

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

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

特表2025-503334ブロックチェーンスクリプトエンジン

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2025-01-31

(54)【発明の名称】ブロックチェーンスクリプトエンジン

(51)【国際特許分類】

G06F 8/71 20180101AFI20250124BHJP

【ＦＩ】

G06F8/71

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024529896

(86)(22)【出願日】2022-11-07

(85)【翻訳文提出日】2024-05-21

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

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

(87)【国際公開日】2023-06-15

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

(32)【優先日】2021-12-07

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東忠重

(74)【代理人】

【識別番号】100229448

【弁理士】

【氏名又は名称】中槇利明

(72)【発明者】

【氏名】パガニ，アレッシオ

(72)【発明者】

【氏名】タルタン，クロエ

(72)【発明者】

【氏名】ジャン，ウェイ

(72)【発明者】

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

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AE44

5B376AE51

5B376DA05

5B376DA11

(57)【要約】

第１のブロックチェーントランザクションのロックスクリプトおよび第２のブロックチェーントランザクションのロック解除スクリプトから形成されたスクリプトを実行するコンピュータ実装方法であって、スクリプトは、第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含み、方法は、ネイティブスクリプトエンジンが第１のスクリプト部分を実行するステップと、バージョン関数に遭遇すると、ネイティブスクリプトエンジンが、スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって第１のスクリプト部分が有効であるかどうかを決定するステップと、第１のスクリプト部分が有効であると決定したことに応答して、ネイティブスクリプトエンジンが、少なくともバージョン関数および第２のスクリプト部分を含むサブスクリプトを、バージョン管理されたスクリプトエンジンに供給するステップと、バージョン管理されたスクリプトエンジンがサブスクリプトを実行するステップであって、バージョン管理されたスクリプトエンジンによるサブスクリプトの実行は、第１のブロックチェーントランザクションおよび／または第２のブロックチェーントランザクションの有効性に影響を与えない、ステップとを含む方法。

【特許請求の範囲】

【請求項1】

第１のブロックチェーントランザクションのロックスクリプトおよび第２のブロックチェーントランザクションのロック解除スクリプトから形成されたスクリプトを実行するコンピュータ実装方法であって、前記スクリプトは、第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含み、前記方法は、ブロックチェーンノードによって実行され、
ネイティブスクリプトエンジンが前記第１のスクリプト部分を実行するステップと、
前記バージョン関数に遭遇すると、前記ネイティブスクリプトエンジンが、前記スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって前記第１のスクリプト部分が有効であるかどうかを決定するステップと、
前記第１のスクリプト部分が有効であると決定したことに応答して、前記ネイティブスクリプトエンジンが、少なくとも前記バージョン関数および前記第２のスクリプト部分を含むサブスクリプトを、バージョン管理されたスクリプトエンジンに供給するステップと、
前記バージョン管理されたスクリプトエンジンが前記サブスクリプトを実行するステップであって、前記バージョン管理されたスクリプトエンジンによる前記サブスクリプトの実行は、前記第１のブロックチェーントランザクションおよび／または第２のブロックチェーントランザクションの有効性に影響を与えない、ステップと
を含む方法。

【請求項2】

前記第１のスクリプト部分は、ターゲットノードプロトコルバージョン番号を含み、前記サブスクリプトは、前記ターゲットノードプロトコルバージョン番号を含む、請求項１に記載の方法。

【請求項3】

前記サブスクリプトを実行する前記ステップは、前記バージョン関数を実行するステップを含み、前記バージョン関数を実行する前記ステップは、
前記ブロックチェーンノードのノードプロトコルバージョン番号を取得するステップと、
前記ノードプロトコルバージョン番号を出力するステップであって、前記ノードプロトコルバージョン番号は、前記ブロックチェーンノードが実行するように構成された特定の機能に関連付けられる、ステップと
を含む、請求項１に記載の方法。

【請求項4】

【請求項5】

前記バージョン関数を実行する前記ステップは、
前記出力されたノードプロトコルバージョン番号が前記ターゲットノードプロトコルバージョン番号と一致する場合、前記第２のスクリプト部分を実行するステップと、
前記出力されたノードプロトコルバージョン番号が前記ターゲットノードプロトコルバージョン番号と一致しない場合、前記第２のスクリプト部分を実行しないステップと
を含む、請求項４に記載の方法。

【請求項6】

前記バージョン関数を実行する前記ステップは、
前記出力されたノードプロトコルバージョン番号が前記ターゲットノードプロトコルバージョン番号と一致する場合、前記第２のスクリプト部分を実行しないステップと、
前記出力されたノードプロトコルバージョン番号が前記ターゲットノードプロトコルバージョン番号と一致しない場合、前記第２のスクリプト部分を実行するステップと
を含む、請求項４に記載の方法。

【請求項7】

前記第２のスクリプト部分は、複数のそれぞれのバージョン関数を含み、各それぞれのバージョン関数は、それぞれのスクリプト部分に関連付けられる、請求項１に記載の方法。

【請求項8】

各それぞれのスクリプト部分は、それぞれのターゲットノードプロトコルバージョン番号に関連付けられ、前記方法は、
前記バージョン管理されたスクリプトエンジンが、前記ノードプロトコルバージョン番号に基づいて前記それぞれのスクリプト部分を実行するステップ
を含む、請求項７に記載の方法。

【請求項9】

前記サブスクリプトの前記実行の結果をユーザに出力するステップを含む、請求項１に記載の方法。

【請求項10】

前記サブスクリプトの前記実行の結果を前記ブロックチェーンに記憶するステップ
を含む、請求項１に記載の方法。

【請求項11】

複数のそれぞれの結果を取得するステップであって、各それぞれの結果は、それぞれの第１のブロックチェーントランザクションのそれぞれのロックスクリプトおよびそれぞれの第２のブロックチェーントランザクションのそれぞれのロック解除スクリプトから形成されたそれぞれのスクリプトの前記実行から取得され、前記それぞれのスクリプトは、それぞれの第１のスクリプト部分、それぞれのバージョン関数、およびそれぞれの第２のスクリプト部分を含む、ステップと、
前記複数のそれぞれの結果に基づいてマークルツリーを生成するステップと、
前記マークルツリーのマークルルートを前記ブロックチェーンに記憶するステップと
を含む、請求項１に記載の方法。

【請求項12】

前記ノードプロトコルバージョン番号を出力する前記ステップは、前記ノードプロトコルバージョン番号の固定長表現を出力するステップを含む、請求項３に記載の方法。

【請求項13】

前記第２のスクリプト部分は、ネイティブブロックチェーン言語以外の言語で書かれたコードの一部を含み、前記ブロックチェーンノードは、その言語で書かれたコードを実行するように構成される、請求項１に記載の方法。

【請求項14】

前記コードの一部は、前記ネイティブブロックチェーン言語以外のブロックチェーン言語で書かれている、請求項１３に記載の方法。

【請求項15】

前記第２のスクリプト部分は、公開鍵および／または公開鍵ハッシュに基づくロック条件を含む、請求項１に記載の方法。

【請求項16】

前記第１のトランザクションおよび前記第２のトランザクションは、それぞれトークントランザクションであり、前記ターゲットノードプロトコルバージョン番号は、トークンプロトコルに関連付けられる、請求項１に記載の方法。

【請求項17】

前記バージョン関数は、オペコードOP_VER、OP_VERIF、またはOP_VERIFNOTのうちの１つである、請求項１に記載の方法。

【請求項18】

コンピュータ機器であって、
１つまたは複数のメモリユニットを備えるメモリと、
１つまたは複数の処理ユニットを備える処理装置と
を備え、前記メモリは、前記処理装置上で実行されるように構成されたコードを記憶し、前記コードは、前記処理装置上にあるときに、請求項１に記載の方法を実行するように構成される、
コンピュータ機器。

【請求項19】

コンピュータ可読記憶装置上に具現化され、１つまたは複数のプロセッサ上で実行されると、請求項１に記載の方法を実行するように構成されたコンピュータプログラム。

【請求項20】

ネイティブスクリプトエンジンおよびバージョン管理されたスクリプトエンジンを含むブロックチェーンスクリプトエンジンであって、前記ネイティブスクリプトエンジンは、
第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含むスクリプトを実行することと、
前記バージョン関数に遭遇すると、前記スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって前記第１のスクリプト部分が有効であるかどうかを決定することと、
前記第１のスクリプト部分が有効であると決定したことに応答して、少なくとも前記バージョン関数および前記第２のスクリプト部分を含むサブスクリプトを前記バージョン管理されたスクリプトエンジンに供給することと
を行うように構成され、
前記バージョン管理されたスクリプトエンジンは、前記サブスクリプトを実行するように構成される、
ブロックチェーンスクリプトエンジン。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ブロックチェーントランザクションを実行する方法と、ブロックチェーントランザクションを実行するように構成されたブロックチェーンスクリプトエンジンとに関する。

【背景技術】

【0002】

ブロックチェーンは、分散型データ構造の形態を指し、ブロックチェーンの複製コピーが、分散型ピアツーピア（Ｐ２Ｐ）ネットワーク（以下、「ブロックチェーンネットワーク」と呼ぶ）内の複数のノードの各々において維持され、広く公開されている。ブロックチェーンはデータブロックのチェーンを含み、各ブロックは１つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の各トランザクションは、１つまたは複数のコインベーストランザクションまで遡る１つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指し示す。コインベーストランザクションについては以下でさらに説明する。ブロックチェーンネットワークにサブミットされたトランザクションは、新しいブロックに含まれる。新しいブロックは、「マイニング（mining）」と呼ばれることが多いプロセスによって作成され、このプロセスは、複数のノードの各々が「プルーフオブワーク（proof-of-work）」を実行しようと競うこと、すなわち、ブロックチェーンの新しいブロックに含まれるのを待っている、順序付けられ妥当性確認（validate）された保留中のトランザクションの表現に基づいて暗号パズルを解くことを伴う。ブロックチェーンはいくつかのノードでプルーニング（prune）され得、ブロックの公開は、単なるブロックヘッダの公開を通して達成され得ることに留意されたい。

【0003】

ブロックチェーン内のトランザクションは、デジタル資産（すなわち、いくつかのデジタルトークン）を伝達すること、仮想台帳またはレジストリにおけるエントリのセットを順序付けること、タイムスタンプエントリを受信および処理すること、および／またはインデックスポインタを時間順にすることという目的のうちの１つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンの上に追加の機能を重ねるために活用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータへのインデックスの記憶を可能にし得る。単一のトランザクション内に記憶することができる最大データ容量に対してあらかじめ指定された制限はなく、したがって、より複雑なデータを組み込むことができる。例えば、これを使用して、ブロックチェーンに電子文書を記憶したり、オーディオまたはビデオデータを記憶したりすることができる。

【0004】

ブロックチェーンネットワークのノード（「マイナー（miner）」と呼ばれることが多い）は、以下でより詳細に説明する分散型のトランザクション登録および検証プロセスを実行する。要するに、このプロセスの間に、ノードは、トランザクションを妥当性確認し、有効なプルーフオブワークの解の識別を試みるブロックテンプレートにそれらを挿入する。有効な解が見つかると、ネットワークの他のノードに新しいブロックが伝搬され、これにより、各ノードが、新しいブロックをブロックチェーンに記録することができる。トランザクションをブロックチェーンに記録させるために、ユーザ（例えば、ブロックチェーンクライアントアプリケーション）は、ネットワークのノードのうちの１つにトランザクションを送信して、伝搬させる。トランザクションを受信したノードは、妥当性確認済みトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけようと競い合い得る。各ノードは、同じノードプロトコルを実施するように構成され、そのノードプロトコルには、トランザクションが有効であるための１つまたは複数の条件が含まれる。無効なトランザクションは、伝搬もブロックへの組込みもされない。トランザクションが妥当性確認され、それによってブロックチェーン上に受け入れられたと仮定すると、トランザクション（任意のユーザデータを含む）は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々において登録およびインデックス付けされたままになる。

【0005】

プルーフオブワークパズルを解くのに成功して最新のブロックを作成したノードは、典型的には、ある額のデジタル資産、すなわちいくつかのトークンを配布する「コインベーストランザクション」と呼ばれる新しいトランザクションで報酬が与えられる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして働き、不正を報告および阻止するようにインセンティブが与えられる競合ノードのアクションによって実施される。情報の広範な公開により、ユーザは、ノードの性能を連続的に監査することができる。単なるブロックヘッダの公開により、参加者は、ブロックチェーンの継続的な完全性を確実にすることができる。

【0006】

「出力ベースの」モデル（ＵＴＸＯベースモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つまたは複数の入力と１つまたは複数の出力とを含む。任意の使用可能な出力は、トランザクションの先行するシーケンスから導出可能なデジタル資産の額を指定する要素を含む。使用可能な出力は、ＵＴＸＯ（「未使用トランザクション出力」）と呼ばれることがある。出力は、出力を将来償還するための条件を指定するロックスクリプトをさらに含み得る。ロックスクリプトは、デジタルトークンまたは資産を妥当性確認および転送するために必要な条件を定義する述語（predicate）である。トランザクション（コインベーストランザクションを除く）の各入力は、先行するトランザクションにおけるそのような出力へのポインタ（すなわち、参照）を含み、指し示された出力のロックスクリプトをロック解除するためのロック解除スクリプトをさらに含み得る。そのため、トランザクションのペアを考慮して、それらを第１のトランザクションおよび第２のトランザクション（または「ターゲット」トランザクション）と呼ぶ。第１のトランザクションは、デジタル資産の額を指定する少なくとも１つの出力を含み、出力をロック解除する１つまたは複数の条件を定義するロックスクリプトを含む。第２のターゲットトランザクションは、第１のトランザクションの出力へのポインタを含む少なくとも１つの入力と、第１のトランザクションの出力をロック解除するためのロック解除スクリプトとを含む。

【0007】

そのようなモデルでは、第２のターゲットトランザクションがブロックチェーンネットワークに送信されて伝搬されブロックチェーンに記録されるとき、各ノードで適用される有効性の基準のうちの１つは、ロック解除スクリプトが第１のトランザクションのロックスクリプトで定義された１つまたは複数の条件のすべてを満たすことである。もう１つは、第１のトランザクションの出力が別の先の有効なトランザクションによってまだ償還されていないということである。これらの条件のいずれかにしたがってターゲットトランザクションが無効であることを発見したノードは、（無効なトランザクションを登録するために伝搬する可能性はあるが、有効なトランザクションとしては）それを伝搬することも、ブロックチェーンに記録されるように新しいブロックにそれを含めることもしない。

【0008】

トランザクションモデルの別のタイプは、アカウントベースのモデルである。このケースでは、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にノードによって記憶され、絶えず更新される。

【発明の概要】

【0009】

ブロックチェーンは、そのインフラストラクチャ上に様々なアプリケーションが構築されることができるように設計される。いくつかのブロックチェーンノードは、システムにセキュリティを提供するだけでなく、スマートコントラクトを実行する能力などの追加の機能およびユーティリティも提供する。すべてのノードがこれらの追加の機能を提供するわけではなく、異なるノードが異なるタイプまたはレベルのそのような機能をサポートし得る。

【0010】

ブロックチェーンノードは、ノードプロトコルバージョン番号またはバージョン番号を使用して、追加の機能を提供するそれらの能力をシグナリングし得る。各バージョン番号は、特定の機能に関連付けられ得る。言い換えると、ブロックチェーンノードは、特定のプロトコルの一部として機能を実装するように構成され得る。例えば、プロトコルは、スマートコンタクトプロトコル、またはトークンプロトコル、またはトランザクションを妥当性確認するための特定のプロトコルであり得る。別の例として、ブロックチェーンノードは、ブロックチェーンに固有ではないコード（例えば、PythonまたはJava）を実行し、上記コードを実行した結果を返す（すなわち、出力する）ように構成され得る。

【0011】

ブロックチェーンプロトコルは、トランザクションのためのスクリプト言語を使用し得る。スクリプトは、本質的に、データまたは命令であり得る要素のリストである。命令は、文献では、スクリプトワード、オペコード、コマンド、または関数と呼ばれる。オペコード（オペレーションコードの略）は、スクリプト内のデータに対して所定の動作を実行する。スクリプトは、バージョン関数（ここで、関数は、オペコードなどの命令のタイプを意味するために一般的に使用される）と、それに続く、スクリプトを実行しているブロックチェーンノードに関連付けられたノードプロトコルバージョン番号に応じて、実行されるだけの、または特定の方法で実行されるスクリプトの部分とを含み得る。

【0012】

ノードバージョニングの導入、すなわち、異なるノードがそれらの能力に応じてスクリプトの一部を異なって実行することを可能にすることは、ノードが、ネイティブブロックチェーンプロトコルに加えて、自身のプロトコルにしたがってトランザクションを異なるように閲覧および妥当性確認することを可能にすることによって、ブロックチェーンネットワークのノードの能力を大幅に増加させることができる。追加の機能は、任意のスマートコントラクトの実行からいくつかの特定のトランザクションの妥当性確認まで、チェスのゲームから資産の交換まで、または妥当性確認のためのカスタマイズされたルールまで、多岐にわたり得る。

【0013】

しかしながら、スクリプトの実行により、１つ（または複数）のブロックチェーンノードがトランザクションを有効とみなし、別のブロックチェーンノードがトランザクションを無効とみなす場合、問題が生じる。これは、ブロックチェーンネットワークの分割、すなわちブロックチェーンフォークを作成することになる。これは、例えば、ブロックチェーンノードがスクリプトの一部を実行する能力を有するが、他方は有していない場合に起こり得る。これは、両方のノードがスクリプト全体を実行する能力を有するが、ノードがそれらのバージョン番号に応じてスクリプトを異なるように実行する場合にも起こり得る。

【0014】

ブロックチェーンフォークは、セキュリティの観点から問題がある。フォークは、いくつかのブロックチェーンノードに、ブロックチェーンの１つのバージョンで「マイニング」させ、一方、他のノードは、異なるバージョン、例えば、トランザクションが有効であるとみなされる１つのバージョン、および同じトランザクションが無効であるとみなされる１つのバージョンでマイニングする。ここで、ブロックチェーン上のマイニングとは、新しいブロックをチェーンに追加しようとすることを意味する。これは、いずれかのチェーン上で費やされるハッシュレートを低減する。ハッシュレートが減少するにつれて、悪意のあるアクティビティ、例えば、ハッシュレートの５１％を制御するエンティティがブロックチェーンを操作することができる、いわゆる５１％攻撃の可能性が増加する。ブロックチェーンフォークはまた、いくつかのノードに、最終的に他のノードに失われることになるチェーンのバージョン上のリソース（例えば、時間、労力、および処理能力）を浪費させるので、問題がある。

【0015】

したがって、ブロックチェーンノードが、ネットワークを分割させることなく、それらの能力に応じてトランザクションを異なって実行することができることが望ましい。

【0016】

本明細書に開示される一態様によれば、第１のブロックチェーントランザクションのロックスクリプトおよび第２のブロックチェーントランザクションのロック解除スクリプトから形成されたスクリプトを実行するコンピュータ実装方法が提供され、ここにおいて、スクリプトは、第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含み、方法は、ネイティブスクリプトエンジンが第１のスクリプト部分を実行するステップと、バージョン関数に遭遇すると、ネイティブスクリプトエンジンが、スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって第１のスクリプト部分が有効であるかどうかを決定するステップと、第１のスクリプト部分が有効であると決定したことに応答して、ネイティブスクリプトエンジンが、少なくともバージョン関数および第２のスクリプト部分を含むサブスクリプトを、バージョン管理されたスクリプトエンジンに供給するステップと、バージョン管理されたスクリプトエンジンがサブスクリプトを実行するステップであって、バージョン管理されたスクリプトエンジンによるサブスクリプトの実行は、第１のブロックチェーントランザクションおよび／または第２のブロックチェーントランザクションの有効性に影響を与えない、ステップとを含む。

【0017】

本明細書に開示される別の態様によれば、ネイティブスクリプトエンジンおよびバージョン管理されたスクリプトエンジンを含むブロックチェーンスクリプトエンジンが提供され、ここにおいて、ネイティブスクリプトエンジンは、第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含むスクリプトを実行することと、バージョン関数に遭遇すると、スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって第１のスクリプト部分が有効であるかどうかを決定することと、第１のスクリプト部分が有効であると決定したことに応答して、少なくともバージョン関数および第２のスクリプト部分を含むサブスクリプトをバージョン管理されたスクリプトエンジンに供給することとを行うように構成され、バージョン管理されたスクリプトエンジンは、サブスクリプトを実行するように構成される。

【0018】

従来、ブロックチェーンノードは、ネイティブスクリプトエンジンを使用して全体を実行する。ここでは、バージョン管理された分岐、すなわち、バージョン関数に続いて実行されるスクリプトの部分を処理するために、追加のスクリプトエンジン（バージョン管理されたスクリプトエンジン）が導入される。ネイティブスクリプトエンジンは、バージョン関数を検出すると、スクリプトの実行を終了する。実行されたスクリプトの有効性がチェックされる。実行されたスクリプトが無効である場合、トランザクションは無効にされる。実行されたスクリプトが有効である場合、スクリプトの残りの部分は、バージョン管理されたスクリプトエンジンに送られて実行される。ネイティブスクリプトエンジンのみが、スクリプトの有効性、したがって、トランザクションの有効性に影響を与える。したがって、異なるノードがスクリプトの残りの部分を異なって実行した場合であっても、すべてのノードは、トランザクションの有効性に関して同じコンセンサス（consensus）に達することとなるので、フォークを防止する。

【0019】

バージョン関数は、以下では「OP_VER」と呼ばれることに留意されたい。しかしながら、本開示は、その特定のラベルを有する機能（例えば、オペコード）に限定されるものではない。より一般的には、実施形態は、ブロックチェーンスクリプト言語の「OP_VER」に関して説明されるが、スクリプトエンジン（すなわち、スクリプトインタープリタ）によって呼び出されると、本明細書で説明されるようなバージョン関数に起因するアクションを引き起こす任意の機能（例えば、オペコード）を使用して、同じ教示を実装することができる。

【図面の簡単な説明】

【0020】

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、単なる例として、添付の図面を参照する。

【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。

【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。

【図3】トランザクションを処理するためのいくつかのノードソフトウェアの概略ブロック図である。

【図4】本明細書に説明される実施形態を実装するためのシステムの概略ブロック図である。

【図5】デュアルスクリプトエンジンによって実行されるバージョン管理されたスクリプトのレイアウトを概略的に示す。

【図6】例示的なトークントランザクションを概略的に示す。

【図7】例示的なトークントランザクションを概略的に示す。

【図8】例示的なトークントランザクションを概略的に示す。

【図9】例示的なトークントランザクションを概略的に示す。

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

【0021】

１．例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１で構成され得る。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）ネットワーク１０６を形成するように構成され得る複数のブロックチェーンノード１０４を含む。図示されていないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして構成され得る。したがって、各ブロックチェーンノード１０４は、他のブロックチェーンノード１０４に高度に接続される。

【0022】

各ブロックチェーンノード１０４は、ピアのコンピュータ機器を含み、ノード１０４の異なるものは、異なるピアに属する。各ブロックチェーンノード１０４は、１つまたは複数のプロセッサ、例えば、１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ならびに特定用途向け集積回路（ＡＳＩＣ）などの他の機器を含む処理装置を備える。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。

【0023】

ブロックチェーン１５０は、データブロック１５１のチェーンを含み、ブロックチェーン１５０のそれぞれのコピーは、分散型またはブロックチェーンネットワーク１０６内の複数のブロックチェーンノード１０４の各々で維持される。上述したように、ブロックチェーン１５０のコピーを維持することは、ブロックチェーン１５０を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン１５０は、各ブロックチェーンノード１５０が各ブロック１５１のブロックヘッダ（後述する）を記憶している限り、データがプルーニングされ得る。チェーン内の各ブロック１５１は、１つまたは複数のトランザクション１５２を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つの入力および少なくとも１つの出力を含む。各出力は、プロパティとしてデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされている（ロック解除され、それによって償還または使用されるためにはそのユーザの署名または他の解決策を必要とする）ユーザ１０３である。各入力は、先行するトランザクション１５２の出力を指し示し、それによってトランザクションをリンクする。

【0024】

各ブロック１５１はまた、ブロック１５１への順番を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。各トランザクション１５２（コインベーストランザクション以外）は、トランザクションのシーケンスへの順序を定義するために、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであったジェネシスブロック（Ｇｂ：genesis block）１５３まで戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示していた。

【0025】

ブロックチェーンノード１０４の各々は、トランザクション１５２を他のブロックチェーンノード１０４にフォワードし、それによってトランザクション１５２をネットワーク１０６全体に伝搬させるように構成される。各ブロックチェーンノード１０４は、ブロック１５１を作成し、同じブロックチェーン１５０のそれぞれのコピーをそれらのそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待っているトランザクション１５２の順序付きセット（またはプール）１５４を維持する。順序付きプール１５４は、「メムプール（mempool）」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図するものではない。これは、ノード１０４が有効であるとして受け入れたトランザクションの順序付きセットを指し、それに対して、ノード１０４は、同じ出力を使用しようとする他のトランザクションを受け入れないように義務付けられている。

【0026】

所与の現在のトランザクション１５２ｊにおいて、その入力（または各入力）は、トランザクションのシーケンスにおける先行するトランザクション１５２ｉの出力を参照するポインタを含み、この出力が現在のトランザクション１５２ｊにおいて償還または「使用」されるべきであることを指定する。使用することまたは償還することは、必ずしも金融資産の移転を意味するものではないが、それは確かに１つの一般的な用途である。より一般的には、使用することは、出力を消費すること、または別の以降の（onward）トランザクションにおける１つまたは複数の出力にそれを割り当てることとして説明され得る。一般に、先行するトランザクションは、順序付きセット１５４または任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２ｉは、現在のトランザクションが有効となるためには存在および妥当性確認される必要があるが、先行するトランザクション１５２ｉは、現在のトランザクション１５２ｊが作成されるときまたはネットワーク１０６に送信されるときに必ずしも存在する必要はない。したがって、本明細書における「先行する（preceding）」は、ポインタによってリンクされた論理シーケンスにおける先行するものを指し、必ずしも時間シーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション１５２ｉ、１５２ｊが順不同に作成または送信されることを必ずしも除外するものではない（オーファントランザクションに関する以下の説明を参照）。先行するトランザクション１５２ｉは、同様に、先のトランザクション（antecedent transaction）または先行したトランザクション（predecessor transaction）とも呼ばれる。

【0027】

現在のトランザクション１５２ｊの入力はまた、入力認可、例えば、先行するトランザクション１５２ｉの出力がロックされている対象のユーザ１０３ａの署名を含む。次に、現在のトランザクション１５２ｊの出力は、新しいユーザまたはエンティティ１０３ｂに暗号的にロックされ得る。したがって、現在のトランザクション１５２ｊは、先行するトランザクション１５２ｉの入力において定義された額を、現在のトランザクション１５２ｊの出力において定義されたように、新しいユーザまたはエンティティ１０３ｂに転送することができる。いくつかのケースでは、トランザクション１５２は、複数のユーザまたはエンティティ（そのうちの１つは残り（change）を与えるために元のユーザまたはエンティティ１０３ａであり得る）間で入力額を分割するために複数の出力を有し得る。いくつかのケースでは、トランザクションはまた、１つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの１つまたは複数の出力に再分配するために複数の入力を有することができる。

【0028】

ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは組織などの当事者１０３が（手動でまたは当事者によって採用される自動プロセスによって）新しいトランザクション１５２ｊを制定することを望むとき、制定を行う当事者は、新しいトランザクションをそのコンピュータ端末１０２から受信者に送信する。制定を行う当事者または受信者は、最終的に、このトランザクションをネットワーク１０６のブロックチェーンノード１０４の１つまたは複数（これは、現在では、典型的にはサーバまたはデータセンタであるが、原則として他のユーザ端末であってもよい）に送信する。新しいトランザクション１５２ｊを制定する当事者１０３がトランザクションをブロックチェーンノード１０４の１つまたは複数に直接送信し、いくつかの例では、受信者に送信しないことも除外されない。トランザクションを受信するブロックチェーンノード１０４は、ブロックチェーンノード１０４の各々で適用されるブロックチェーンノードプロトコルにしたがって、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付きシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにブロックチェーンノード１０４に要求する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション１５２ｊの入力に含まれる当事者１０３の暗号署名または他の認可が、新しいトランザクションが使用する（または「割り当てる」）先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名または他の認可が、新しいトランザクションの入力がリンクされている前のトランザクション１５２ｉの出力をロック解除することを少なくともチェックすることを含む。条件は、先行するトランザクション１５２ｉの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替的に、それは、単にブロックチェーンノードプロトコルのみによって固定されてもよいし、これらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、ブロックチェーンノード１０４は、それをブロックチェーンネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードする。これらの他のブロックチェーンノード１０４は、同じブロックチェーンノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはブロックチェーンノード１０４のネットワーク全体に伝搬される。

【0029】

出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が割り当てられる（または、「使用される」）かどうかの定義は、それがブロックチェーンノードプロトコルにしたがって別の以降のトランザクション１５２ｊの入力によって有効に償還されたかどうかである。トランザクションが有効であるための別の条件は、それが償還しようとする先行するトランザクション１５２ｉの出力が、別のトランザクションによってまだ償還されていないことである。この場合も同様に、有効ではない場合、トランザクション１５２ｊは、（無効としてフラグ付けされ、警告のために伝搬されない限り）伝搬されることも、ブロックチェーン１５０内に記録されることもない。これは、トランザクタ（transactor）が同じトランザクションの出力を複数回割り当てようとする二重使用（double-spending）を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重使用を防止する。ここでも、トランザクション順序が定義されているので、アカウント残高は常に単一の定義された状態にある。

【0030】

トランザクションを妥当性確認することに加えて、ブロックチェーンノード１０４はまた、「プルーフオブワーク」によって支持される、一般にマイニングと呼ばれるプロセスにおいてトランザクションのブロックを最初に作成しようと競い合う。ブロックチェーンノード１０４において、新しいトランザクションが、ブロックチェーン１５０上に記録されたブロック１５１内にまだ現れていない有効なトランザクションの順序付きプール１５４に追加される。次いで、ブロックチェーンノードは、暗号パズルを解こうとすることで、トランザクションの順序付きセット１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てようと競い合う。典型的には、これは、ナンスが保留中のトランザクションの順序付きプール１５４の表現と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。例えば、所定の条件とは、ハッシュの出力が特定の所定の数の先行ゼロを有することであり得る。これは、プルーフオブワークパズルの１つの特定のタイプにすぎず、他のタイプが除外されないことに留意されたい。ハッシュ関数のプロパティは、その入力に対して予測不可能な出力を持つことである。したがって、この探索は、総当たりでしか実行することができないので、パズルを解こうとしている各ブロックチェーンノード１０４でかなりの量の処理リソースを消費する。

【0031】

最初にパズルを解いたブロックチェーンノード１０４は、これをネットワーク１０６に公表し、後にネットワーク内の他のブロックチェーンノード１０４によって容易にチェックすることができるその解をプルーフとして提供する（ハッシュに対する解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。この最初のブロックチェーンノード１０４は、ブロックを、このブロックを受け入れる他のノードのしきい値コンセンサスに伝搬し、プロトコルルールを施行する。次いで、トランザクションの順序付きセット１５４は、ブロックチェーンノード１０４の各々によってブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークの解を作成するために必要とされる、例えばハッシュの形態の、かなりの量の労力は、ブロックチェーンプロトコルのルールに従うという最初のノード１０４の意図を示す。そのようなルールは、前に妥当性確認されたトランザクションと同じ出力の使用または割当てを行った場合にトランザクションを有効として受け入れること（別名二重使用としても知られている）を行わないことを含む。ブロック１５１は、一旦作成されると、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々において認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１に順番を付与する。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

【0032】

任意の所与の時間にパズルを解こうと競い合う異なるブロックチェーンノード１０４は、それらがいつ解を探索し始めたかまたはトランザクションが受信された順序に応じて、任意の所与の時間に、まだ公開されていないトランザクションのプール１５４の異なるスナップショットに基づいてそれを行っていてもよいことに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎにどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール１５４が更新される。次いで、ブロックチェーンノード１０４は、新たに定義された、公開されていないトランザクションの順序付きプール１５４からブロックを作成しようと競い合い続け、以下同様である。２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解がノード１０４間で伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどちらのプロングでも最も長く成長した方が、確定的なブロックチェーン１５０となる。同じトランザクションが両方のフォークに現れるので、これがネットワークのユーザまたはエージェントに影響を与えないことに留意されたい。

【0033】

ビットコインブロックチェーン（およびほとんどの他のブロックチェーン）によれば、新しいブロック１０４の構築に成功したノードには、（あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を転送するエージェント間またはユーザ間のトランザクションとは対照的に）追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、受け入れられた追加の額のデジタル資産を新たに割り当てる能力が与えられる。この特別なタイプのトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション（initiation transaction）」または「生成トランザクション（generation transaction）」と称されることもある。これは典型的に、新しいブロック１５１ｎの最初のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードが、この特別なトランザクションが後に償還されることを可能にするプロトコルルールに従うという意図を示す。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還され得る前に、満期期間、例えば１００個のブロックを必要とし得る。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが公開されたブロック１５１ｎを作成したブロックチェーンノード１０４にさらに報酬を与えるために、その出力のうちの１つにおいて追加のトランザクション手数料を指定する。この手数料は通常「トランザクション手数料」と呼ばれ、以下で説明される。

【0034】

トランザクション妥当性確認および公開に関与するリソースに起因して、典型的には、ブロックチェーンノード１０４の少なくとも各々は、１つまたは複数の物理サーバユニットで構成されるサーバの形態をとるか、さらにはデータセンタ全体の形態をとる。しかしながら、原則として、任意の所与のブロックチェーンノード１０４は、ユーザ端末または互いにネットワーク化されたユーザ端末のグループの形態をとることができる。

【0035】

各ブロックチェーンノード１０４のメモリは、そのそれぞれの１つまたは複数の役割を実行し、ブロックチェーンノードプロトコルにしたがってトランザクション１５２を処理するために、ブロックチェーンノード１０４の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード１０４に帰する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーション層、またはオペレーティングシステム層もしくはプロトコル層などの下位層、またはこれらの任意の組合せにおける１つまたは複数のアプリケーションにおいて実装され得る。

【0036】

消費ユーザの役割を担う複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらのユーザは、ブロックチェーンネットワーク１０６と対話し得るが、トランザクションの妥当性確認にもブロックの構築にも参加しない。これらのユーザまたはエージェント１０３のうちのいくつかは、トランザクションの送信者および受信者として動作し得る。他のユーザは、必ずしも送信者または受信者として動作することなくブロックチェーン１５０と対話し得る。例えば、いくつかの当事者は、ブロックチェーン１５０のコピーを記憶する（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）ストレージエンティティとして動作し得る。

【0037】

当事者１０３のうちのいくつかまたはすべては、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上にオーバーレイされたネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれことが多い）は、ブロックチェーンネットワーク１０６を含むシステムの一部であるといえるが、これらのユーザは、ブロックチェーンノードに要求される役割を果たさないので、ブロックチェーンノード１０４ではない。代わりに、各当事者１０３はブロックチェーンネットワーク１０６と対話してもよく、それによって、ブロックチェーンノード１０６に接続する（すなわち通信する）ことでブロックチェーン１５０を利用し得る。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。そのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２ははるかに多く存在し、システム１００に参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと呼ばれ、第２の当事者１０３ｂはボブと呼ばれるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。

【0038】

各当事者１０３のコンピュータ機器１０２は、１つまたは複数のプロセッサ、例えば、１つまたは複数のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および／またはＦＰＧＡを含むそれぞれの処理装置を備える。各当事者１０３のコンピュータ機器１０２は、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに備える。このメモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。各当事者１０３のコンピュータ機器１０２上のメモリは、処理装置上で実行されるように構成された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の当事者１０３に帰する任意のアクションは、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各当事者１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の当事者１０３のコンピュータ機器１０２はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの１つまたは複数の他のネットワーク化されたリソースを含み得る。

【0039】

クライアントアプリケーション１０５は、最初に、１つまたは複数の適切なコンピュータ可読ストレージ上で任意の所与の当事者１０３のコンピュータ機器１０２に提供され得、例えば、サーバからダウンロードされ得るか、またはリムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、ＣＤもしくはＤＶＤＲＯＭなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブル記憶デバイス上で提供され得る。

【0040】

クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これは２つの主要な機能を有する。これらのうちの１つは、それぞれの当事者１０３が、トランザクション１５２を作成し、認可し（例えば署名し）、１つまたは複数のビットコインノード１０４に送信することを可能にして、トランザクション１５２をブロックチェーンノード１０４のネットワーク全体に伝搬させ、それによってブロックチェーン１５０に含まれるようにすることである。もう１つは、それぞれの当事者に、その当事者が現在所有しているデジタル資産の額を報告することである。出力ベースのシステムでは、この第２の機能は、当該当事者に属するブロックチェーン１５０全体に散在している様々なトランザクション１５２の出力において定義された額を照合することを含む。

【0041】

様々なクライアント機能が、所与のクライアントアプリケーション１０５に統合されるものとして説明され得るが、必ずしもこれに限定されるものではなく、代わりに、本明細書で説明される任意のクライアント機能は、例えば、ＡＰＩを介してインターフェースする、または一方が他方へのプラグインである２つ以上の別個のアプリケーション一式において実装され得ることに留意されたい。より一般的には、クライアント機能は、アプリケーション層もしくはオペレーティングシステムなどの下位層、またはこれらの任意の組合せにおいて実装され得る。以下では、クライアントアプリケーション１０５に関して説明するが、これに限定されないことが理解されよう。

【0042】

各コンピュータ機器１０２上のクライアントアプリケーションまたはソフトウェア１０５のインスタンスは、ネットワーク１０６のブロックチェーンノード１０４のうちの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能はトランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５はまた、それぞれの当事者１０３が受信者である任意のトランザクションについてブロックチェーン１５０にクエリを行うためにブロックチェーンノード１０４にコンタクトすることができる（または、実施形態では、ブロックチェーン１５０は、部分的にその公開性（public visibility）を通じてトランザクションにおける信頼を提供する公共施設であるので、実際にブロックチェーン１５０における他の当事者のトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルにしたがってトランザクション１５２を定式化し、送信するように構成される。上述したように、各ブロックチェーンノード１０４は、ブロックチェーンノードプロトコルにしたがってトランザクション１５２を妥当性確認し、トランザクション１５２をフォワードして、それらをブロックチェーンネットワーク１０６全体に伝搬するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルに従い（go with）、一緒に所与のトランザクションモデルを実装する。ブロックチェーン１５０内のすべてのトランザクション１５２に対して同じトランザクションプロトコルが使用される。ネットワーク１０６内のすべてのノード１０４によって同じノードプロトコルが使用される。

【0043】

所与の当事者１０３、例えばアリスが、ブロックチェーン１５０に含まれるべき新しいトランザクション１５２ｊを送信することを望むとき、アリスは、関連トランザクションプロトコルにしたがって（アリスのクライアントアプリケーション１０５内のウォレット機能を使用して）新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション１０５から、アリスが接続されている１つまたは複数のブロックチェーンノード１０４にトランザクション１５２を送信する。例えば、これは、アリスのコンピュータ１０２に最良に接続されたブロックチェーンノード１０４であり得る。任意の所与のブロックチェーンノード１０４は、新しいトランザクション１５２ｊを受信すると、ブロックチェーンノードプロトコルおよびそのそれぞれの役割にしたがってそれを処理する。これには、新たに受信されたトランザクション１５２ｊが「有効」であるための特定の条件を満たすかを最初にチェックすることが含まれ、その例については、以下でより詳細に説明する。いくつかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替的に、条件は、単にノードプロトコルの組込み特徴であってもよいし、スクリプトとノードプロトコルとの組合せによって定義されてもよい。

【0044】

新たに受信されたトランザクション１５２ｊが、有効であるとみなされるためのテストにパスすることを条件として（すなわち、それが「妥当性確認される」ことを条件として）、トランザクション１５２ｊを受信する任意のブロックチェーンノード１０４は、そのブロックチェーンノード１０４において維持されるトランザクションの順序付きセット１５４に新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２ｊを受信する任意のブロックチェーンノード１０４は、妥当性確認済みトランザクション１５２をネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４に伝搬する。各ブロックチェーンノード１０４は同じプロトコルを適用するので、トランザクション１５２ｊが有効であると仮定すると、これは、ネットワーク１０６全体にわたってすぐに伝搬されることを意味する。

【0045】

所与のブロックチェーンノード１０４において維持される保留中のトランザクションの順序付きプール１５４に承認されると、そのブロックチェーンノード１０４は、新しいトランザクション１５２を含むそれぞれのプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のブロックチェーンノード１０４が、トランザクションの異なるプール１５４に基づいてパズルを解こうと試みている可能性があるが、どのノードでも最初に解いたものが、最新のブロック１５１に含まれるトランザクションのセットを定義することを想起されたい。最終的に、ブロックチェーンノード１０４は、アリスのトランザクション１５２ｊを含む順序付きプール１５４の一部についてパズルを解くことになる。）新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは普遍的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、先のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。

【0046】

異なるブロックチェーンノード１０４は、最初、所与のトランザクションの異なるインスタンスを受信し得るので、１つのインスタンスが新しいブロック１５１において公開される（この時点で、公開されたインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード１０４が同意している）までは、どのインスタンスが「有効」であるかについて相反する見解を有する。ブロックチェーンノード１０４が１つのインスタンスを有効として受け入れ、次いで、別のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、そのブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（すなわち、ブロック１５１で公開されていないもの）を破棄する（すなわち、無効として扱う）。

【0047】

いくつかのブロックチェーンネットワークによって運用される代替タイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと呼ばれ得る。アカウントベースのケースでは、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー（「ポジション」とも呼ばれる）を使用して順序付けられる。この値は、送信者によってその暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。加えて、トランザクションにおけるオプションのデータフィールドも署名され得る。このデータフィールドは、例えば、前のトランザクションＩＤがデータフィールドに含まれている場合、前のトランザクションを指し示し得る。

【0048】

２．ＵＴＸＯベースのモデル
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されるものではない。例示的なＵＴＸＯベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実装され得ることに留意されたい。

【0049】

ＵＴＸＯベースのモデルでは、各トランザクション（「Ｔｘ」）１５２は、１つまたは複数の入力２０２および１つまたは複数の出力２０３を含むデータ構造を含む。各出力２０３は、未使用トランザクション出力（ＵＴＸＯ）を含み得、これは、（ＵＴＸＯがまだ償還されていない場合）別の新しいトランザクションの入力２０２のソースとして使用され得る。ＵＴＸＯは、デジタル資産の額を指定する値を含む。これは、分散型台帳上のトークンの設定数を表す。ＵＴＸＯはまた、他の情報の中でも、元となるトランザクションのトランザクションＩＤを含み得る。トランザクションデータ構造は、入力フィールド（複数可）２０２および出力フィールド（複数可）２０３のサイズを示すインジケータを含み得るヘッダ２０１も含み得る。ヘッダ２０１はまた、トランザクションのＩＤを含み得る。実施形態では、トランザクションＩＤは、（トランザクションＩＤ自体を除く）トランザクションデータのハッシュであり、ノード１０４にサブミットされる生のトランザクション１５２のヘッダ２０１に記憶される。

【0050】

アリス１０３ａが、当該デジタル資産の額をボブ１０３ｂに転送するトランザクション１５２ｊを作成することを望むとする。図２では、アリスの新しいトランザクション１５２ｊは「Ｔｘ_１」とラベル付けされている。これは、シーケンス内の先行するトランザクション１５２ｉの出力２０３においてアリスにロックされたデジタル資産の額をとり、これのうちの少なくとも一部をボブに転送する。先行するトランザクション１５２ｉは、図２では「Ｔｘ_０」とラベル付けされている。Ｔｘ_０およびＴｘ_１は、単なる任意のラベルである。それらは、Ｔｘ_０がブロックチェーン１５１内の最初のトランザクションであること、またはＴｘ_１がプール１５４内のすぐ次のトランザクションであることを必ずしも意味するものではない。Ｔｘ_１は、アリスにロックされた未使用の出力２０３を依然として有する任意の先行する（すなわち先の）トランザクションを指し示すことができる。

【0051】

先行するトランザクションＴｘ_０は、アリスが新しいトランザクションＴｘ_１を作成した時点では、または少なくともアリスがそれをネットワーク１０６に送信する時点までには、すでに妥当性確認されブロックチェーン１５０のブロック１５１に含まれている可能性がある。それは、その時点でブロック１５１のうちの１つにすでに含まれていてもよいし、順序付きセット１５４で依然として待機していてもよく、このケースでは、すぐに新しいブロック１５１に含まれることになる。代替的に、Ｔｘ_０およびＴｘ_１を作成してネットワーク１０６に一緒に送信することもできるし、ノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合には、Ｔｘ_０をＴｘ_１の後に送信することさえもできる。トランザクションのシーケンスの文脈において本明細書で使用される「先行する」および「後続する」という用語は、トランザクション内で指定されているトランザクションポインタ（どのトランザクションがどの他のトランザクションを指し示すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、同様に、「先行するもの（predecessor）」および「後続するもの（successor）」、または「先の（antecedent）」および「後の（descendant）」、「親（parent）」および「子（child）」などと置き換えられ得る。これは、それらの作成、ネットワーク１０６への送信、または任意の所与のブロックチェーンノード１０４への到着の順序を必ずしも意味するものではない。それにもかかわらず、先行するトランザクション（先のトランザクションまたは「親」）を指し示す後続するトランザクション（後のトランザクションまたは「子」）は、親トランザクションが妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード１０４に到着する子は、オーファンとみなされる。それは、ノードプロトコルおよび／またはノード挙動に応じて、親を待つために特定の時間バッファされるかまたは破棄され得る。

【0052】

先行するトランザクションＴｘ_０の１つまたは複数の出力２０３のうちの１つは、本明細書ではＵＴＸＯ_０とラベル付けされた特定のＵＴＸＯを含む。各ＵＴＸＯは、ＵＴＸＯによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを含み、ロックスクリプトは、後続するトランザクションが妥当性確認され、したがってＵＴＸＯが正常に償還されるために、後続するトランザクションの入力２０２内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者（それが含まれるトランザクションの受益者）にロックする。すなわち、ロックスクリプトは、典型的には、後続するトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を含むロック解除条件を定義する。

【0053】

ロックスクリプト（通称scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの一部分である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「スクリプト（Script）」（大文字Ｓ）と呼ばれる。ロックスクリプトは、トランザクション出力２０３を使用するためにどの情報が必要とされるか、例えばアリスの署名の必要性、を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト（通称scriptSig）は、ロックスクリプト基準を満たすのに必要な情報を提供するドメイン固有言語で書かれたコードの一部分である。例えば、それはボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力２０２に現れる。

【0054】

つまり、図示の例では、Ｔｘ_０の出力２０３内のＵＴＸＯ_０は、ＵＴＸＯ_０が償還されるために（厳密には、ＵＴＸＯ_０を償還しようとする後続するトランザクションが有効となるために）アリスの署名Sig P_Aを必要とするロックスクリプト[Checksig P_A]を含む。[Checksig P_A]は、アリスの公開鍵－私有鍵ペアの公開鍵Ｐ_Ａの表現（すなわち、ハッシュ）を含む。Ｔｘ_１の入力２０２は、（例えば、実施形態ではトランザクションＴｘ_０全体のハッシュであるそのトランザクションＩＤ、ＴｘＩＤ_０によって）Ｔｘ_１を指し示すポインタを含む。Ｔｘ_１の入力２０２は、Ｔｘ_０の任意の他の可能な出力の中からＵＴＸＯ_０を識別するために、Ｔｘ_０内のＵＴＸＯ_０を識別するインデックスを含む。Ｔｘ_１の入力２０２は、アリスが鍵ペアのアリスの私有鍵をデータの所定の部分（暗号では「メッセージ」と呼ばれることもある）に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト<Sig P_A>をさらに含む。有効な署名を提供するためにアリスによって署名される必要があるデータ（または「メッセージ」）は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

【0055】

新しいトランザクションＴｘ_１がブロックチェーンノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトで定義されている条件（この条件は１つまたは複数の基準を含み得る）を満たすかどうかをチェックすることを含む。実施形態では、これは２つのスクリプトを連結することを含む：
<Sig P_A> <P_A> || [Checksig P_A]
ここで、「||」は連結を表し、「<…>」はデータをスタックに置くことを意味し、「[…]」はロックスクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されると、スクリプトは、Ｔｘ_０の出力内のロックスクリプトに含まれるようなアリスの公開鍵Ｐ_Ａを使用して、Ｔｘ_１の入力内のロック解除スクリプトが、データの予想される部分に署名するアリスの署名を含むことを認証する。この認証を実行するためには、データの予想される部分自体（「メッセージ」）も含まれる必要がある。諸実施形態では、署名されるデータはＴｘ_１の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要がない）。

【0056】

公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の私有鍵を使用してメッセージに署名した場合、アリスの公開鍵および平文のメッセージが与えられると、ノード１０４などの別のエンティティは、メッセージがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができるようになる。したがって、データの特定の部分またはトランザクションの一部などに署名することへの本明細書におけるいかなる参照も、実施形態では、データのその部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。

【0057】

Ｔｘ_１内のロック解除スクリプトが、Ｔｘ_０のロックスクリプト内で指定されている１つまたは複数の条件を満たす場合（つまり、図示の例では、アリスの署名がＴｘ_１内で提供され、認証された場合）、ブロックチェーンノード１０４は、Ｔｘ_１が有効であるとみなす。これは、ブロックチェーンノード１０４が、保留中のトランザクションの順序付きプール１５４にＴｘ_１を追加することとなることを意味する。ブロックチェーンノード１０４はまた、トランザクションＴｘ_１をネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードして、トランザクションＴｘ_１がネットワーク１０６全体に伝搬されるようにする。Ｔｘ_１が妥当性確認されてブロックチェーン１５０に含まれると、これは、Ｔｘ_０からのＵＴＸＯ_０を使用済みとして定義する。Ｔｘ_１は、未使用トランザクション出力２０３を使用する場合にのみ有効になり得ることに留意されたい。別のトランザクション１５２によってすでに使用された出力を使用しようとする場合、Ｔｘ_１は、他のすべての条件が満たされたとしても無効になる。したがって、ブロックチェーンノード１０４はまた、先行するトランザクションＴｘ_０内の参照されたＵＴＸＯがすでに使用済みであるかどうか（すなわち、それが別の有効なトランザクションへの有効な入力をすでに形成したかどうか）をチェックする必要がある。これは、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である理由の１つである。実際には、所与のブロックチェーンノード１０４は、どのトランザクション１５２内のどのＵＴＸＯ２０３が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、ＵＴＸＯが使用されたかどうかを定義するものは、ブロックチェーン１５０内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。

【0058】

所与のトランザクション１５２のすべての出力２０３において指定された総額が、そのすべての入力２０２によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効性の別の根拠となる。そのため、そのようなトランザクションは、伝搬されることも、ブロック１５１に含まれることもない。

【0059】

ＵＴＸＯベースのトランザクションモデルでは、所与のＵＴＸＯが全体として使用される必要があることに留意されたい。ＵＴＸＯにおいて使用済みとして定義された額の一部は、別の一部が使用されている間、「残す」ことはできない。しかしながら、次のトランザクションの複数の出力間でＵＴＸＯからの額を分割することはできる。例えば、Ｔｘ_０内のＵＴＸＯ_０において定義された額を、Ｔｘ_１内の複数のＵＴＸＯ間で分割することができる。したがって、アリスが、ＵＴＸＯ_０において定義された額のすべてをボブに与えたくない場合、アリスは、リマインダを使用して、Ｔｘ_１の第２の出力において自分自身に残りを与えるか、または別の当事者に支払うことができる。

【0060】

実際には、アリスはまた、通常、アリスのトランザクション１０４をブロック１５１に成功裏に含めるビットコインノード１０４に対する手数料を含める必要がある。アリスがそのような手数料を含めない場合、Ｔｘ_０は、ブロックチェーンノード１０４によって拒否され得、したがって、技術的に有効であっても、伝搬されず、ブロックチェーン１５０に含まれない可能性がある（ノードプロトコルは、ブロックチェーンノード１０４が望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、トランザクション手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の任意の差が、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、ＵＴＸＯ_０へのポインタがＴｘ_１への唯一の入力であり、Ｔｘ_１は唯一の出力ＵＴＸＯ_１を有するとする。ＵＴＸＯ_０において指定されたデジタル資産の額がＵＴＸＯ_１において指定された額よりも大きい場合、その差分は、ＵＴＸＯ_１を含むブロックを作成するためのプルーフオブワーク競争に勝つノード１０４によって割り当てられ得る（または、使用され得る）。しかしながら、代替的にまたは追加的に、トランザクション手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることは必ずしも除外されない。

【0061】

アリスおよびボブのデジタル資産は、ブロックチェーン１５０内のどこかで任意のトランザクション１５２においてそれらにロックされたＵＴＸＯから構成される。したがって、典型的には、所与の当事者１０３の資産は、ブロックチェーン１５０全体にわたる様々なトランザクション１５２のＵＴＸＯ全体に散在している。ブロックチェーン１５０内のどこにも、所与の当事者１０３の総残高を定義する数字は記憶されない。クライアントアプリケーション１０５におけるウォレット機能の役割は、それぞれの当事者にロックされ、別の以降のトランザクションでまだ使用されていない様々なＵＴＸＯのすべての値を一緒に照合することである。これは、ビットコインノード１０４のいずれかに記憶されたブロックチェーン１５０のコピーにクエリを行うことによって行うことができる。

【0062】

スクリプトコードは、多くの場合、概略的に（すなわち、正確な言語を使用せずに）表されることに留意されたい。例えば、特定の機能を表すためにオペレーションコード（オペコード）が使用され得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの最初にOP_FALSEが先行するときに、トランザクション内にデータを記憶することができ、それによってデータをブロックチェーン１５０内に不変的に記録することができる、トランザクションの使用不可能な出力を作成するスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに記憶することが望まれる文書を含み得る。

【0063】

典型的には、トランザクションの入力は、公開鍵Ｐ_Ａに対応するデジタル署名を含む。実施形態において、これは、楕円曲線ｓｅｃｐ２５６ｋ１を使用するＥＣＤＳＡに基づく。デジタル署名は、データの特定の一部分に署名する。いくつかの実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の一部または全部に署名する。署名された出力の特定の部分は、ＳＩＧＨＡＳＨフラグに依存する。ＳＩＧＨＡＳＨフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる４バイトコードである（したがって、署名時に固定される）。

【0064】

ロックスクリプトは、典型的には、それぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には、それが対応する署名を供給するという事実を指して「scriptSig」と呼ばれることがある。しかしながら、より一般的には、ＵＴＸＯが償還されるための条件が署名を認証することを含むことは、ブロックチェーン１５０のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、任意の１つまたは複数の条件を定義することができる。したがって、より一般的な用語「ロックスクリプト」および「ロック解除スクリプト」が好まれ得る。

【0065】

３．ノードソフトウェア
図４は、ＵＴＸＯまたは出力ベースのモデルの例において、ネットワーク１０６の各ブロックチェーンノード１０４上で実行されるノードソフトウェア４５０の例を示す。別のエンティティは、ネットワーク１０６上のノード１０４として分類されることなく、すなわちノード１０４に必要なアクションを実行することなく、ノードソフトウェア４５０を実行し得ることに留意されたい。ノードソフトウェア４５０は、プロトコルエンジン４５１、スクリプトエンジン４５２、スタック４５３、アプリケーションレベル決定エンジン４５４、および１つまたは複数のブロックチェーン関連機能モジュール４５５のセットを含み得るが、これらに限定されない。各ノード１０４は、コンセンサスモジュール４５５Ｃ（例えば、プルーフオブワーク）、伝搬モジュール４５５Ｐ、およびストレージモジュール４５５Ｓ（例えば、データベース）の３つすべてを含むがこれらに限定されないノードソフトウェアを実行し得る。プロトコルエンジン４０１は、典型的には、トランザクション１５２の異なるフィールドを認識し、ノードプロトコルにしたがってそれらを処理するように構成される。別の先行するトランザクション１５２ｉ（Ｔｘ_ｍ－１）の出力（例えば、ＵＴＸＯ）を指し示す入力を有するトランザクション１５２ｊ（Ｔｘ_ｊ）が受信されると、プロトコルエンジン４５１は、Ｔｘ_ｊ内のロック解除スクリプトを識別し、それをスクリプトエンジン４５２に渡す。プロトコルエンジン４５１はまた、Ｔｘ_ｊの入力におけるポインタに基づいてＴｘ_ｉを識別し、取り出す。Ｔｘ_ｉは、ブロックチェーン１５０上で公開され得、この場合、プロトコルエンジンは、ノード１０４において記憶されたブロックチェーン１５０のブロック１５１のコピーからＴｘ_ｉを取り出し得る。代替的に、Ｔｘ_ｉは、ブロックチェーン１５０上でまだ公開されていなくてもよい。この場合、プロトコルエンジン４５１は、ノード１０４によって維持される未公開のトランザクションの順序付きセット１５４からＴｘ_ｉを取り出し得る。いずれにしても、スクリプトエンジン４５１は、Ｔｘ_ｉの参照された出力内のロックスクリプトを識別し、これをスクリプトエンジン４５２に渡す。

【0066】

したがって、スクリプトエンジン４５２は、Ｔｘ_ｉのロックスクリプトと、Ｔｘ_ｊの対応する入力からのロック解除スクリプトとを有する。例えば、図２にはＴｘ_０およびＴｘ_１とラベル付けされたトランザクションが示されているが、トランザクションの任意のペアについても同じことが適用され得る。スクリプトエンジン４５２は、前述したように２つのスクリプトを一緒に実行し、これは、使用されているスタックベースのスクリプト言語（例えば、Script）にしたがって、スタック４５３上にデータを配置し、そこからデータを取り出すことを含む。

【0067】

スクリプトを一緒に実行することによって、スクリプトエンジン４５２は、ロック解除スクリプトがロックスクリプトにおいて定義された１つまたは複数の基準を満たすか否か、すなわち、ロックスクリプトが含まれる出力を「ロック解除」するか？を決定する。スクリプトエンジン４５２は、この決定の結果をプロトコルエンジン４５１に返す。スクリプトエンジン４５２は、ロック解除スクリプトが、対応するロックスクリプトで指定されている１つまたは複数の基準を満たすと決定した場合、結果「真」を返す。そうでなければ、結果「偽」を返す。

【0068】

出力ベースのモデルでは、スクリプトエンジン４５２からの結果「真」は、トランザクションの有効性の条件のうちの１つである。典型的には、Ｔｘ_ｊの出力（複数可）で指定されているデジタル資産の総額がその入力によって指し示された総額を超えないこと、およびＴｘ_ｉの指し示された出力が別の有効なトランザクションによってまだ使用されていないことなど、同様に満たされなければならないプロトコルエンジンプロトコルエンジン４５１によって評価される１つまたは複数のさらなるプロトコルレベル条件も存在する。プロトコルエンジン４５１は、スクリプトエンジン４５２からの結果を１つまたは複数のプロトコルレベル条件とともに評価し、それらがすべて真である場合にのみ、トランザクションＴｘ_ｊを妥当性確認する。プロトコルエンジン４５１は、トランザクションが有効であるかどうかの指示をアプリケーションレベル決定エンジン４５４に出力する。Ｔｘ_ｊが実際に妥当性確認されるという条件でのみ、決定エンジン４５４は、Ｔｘ_ｊに関してそれぞれのブロックチェーン関連機能を実行するために、コンセンサスモジュール４５５Ｃおよび伝搬モジュール４５５Ｐの両方を制御することを選択し得る。これは、コンセンサスモジュール４５５Ｃが、ブロック１５１に組み込むために、ノードの、トランザクション１５４のそれぞれの順序付きセットにＴｘ_ｊを追加すること、および伝搬モジュール４５５Ｐが、ネットワーク１０６内の別のブロックチェーンノード１０４にＴｘ_ｊをフォワードすることを含む。オプションで、実施形態では、アプリケーションレベル決定エンジン４５４は、これらの機能の一方または両方をトリガする前に、１つまたは複数の追加の条件を適用し得る。例えば、決定エンジンは、トランザクションが有効であり、かつ十分なトランザクション手数料を残しているという条件でのみ、トランザクションを公開することを選択し得る。

【0069】

本明細書における「真」および「偽」という用語は、単一の２進数（ビット）のみの形態で表される結果を返すことに必ずしも限定されないが、それは確かに１つの可能な実装形態であることにも留意されたい。より一般的には、「真」は、成功または肯定的な結果を示す任意の状態を指すことができ、「偽」は、不成功または非肯定的な結果を示す任意の状態を指すことができる。例えば、アカウントベースのモデルでは、「真」の結果は署名の暗黙的なプロトコルレベルの妥当性確認と、スマートコントラクトの追加の肯定的な出力との組合せによって示され得る（個々の結果の両方が真である場合、全体の結果が真を示すとみなされる）。

【0070】

４．OP_VER
ブロックサイズの拡大およびトランザクションスループットの増大により、ブロックチェーンエコシステム内のブロックチェーンベースのアプリケーションの数が大幅に増加した。これらの新しいアプリケーションの多くは、デジタル資産の基本的な転送を超えるサービスを提供し、したがって、外部の妥当性確認または解釈プロセスに依拠する。ブロックチェーンノード（マイナー）の妥当性確認は、これらのデジタル資産を使用することの妥当性に関するが、外部の妥当性確認により、企業は、より複雑な目的のためにブロックチェーン能力を活用するアプリケーションおよびサービスを作成することができる。そのようなプロセスの例には、メタネットなどのオーバーレイネットワークの作成、トークンシステムなどの商品およびサービス表現、ならびにその他多くのものが含まれる。多数のオーバーレイサービスは、ブロックプロデューサおよびブロックチェーン企業に専門的なサービスを提供するよう促し、その結果、事実上のブロックチェーンコミュニティおよび階層化されたネットワークトポロジーが作成された。

【0071】

企業および開発者が階層化ネットワークを活用するための１つの手法は、オペコードOP_VERおよびそれに関連するオペコードOP_VERIF、OP_VERNOTIFの使用を含む。これらのバージョン固有のオペコードにより、ネットワーク内のノードは、ネイティブビットコインプロトコルに加えて、自身のプロトコルにしたがって異なってトランザクションを閲覧および妥当性確認することができる。

【0072】

オペコードOP_VERを使用して、ノードは、トランザクション妥当性確認と並行して新しい機能を提供することができる。それらのノードバージョン番号をブロードキャストすることによって、ノードは、それらがどのサービスを提供するかを公衆に効果的にブロードキャストする。これは、任意のスマートコントラクトの実行から、ゲーム、資産の交換、または妥当性確認のためのカスタマイズされたルールのセットなどの特定のトランザクションの妥当性確認まで、多岐にわたり得る。

【表1】

【0073】

OP_VERが有効にされると、ブロックプロデューサ（すなわち、マイナー）は、ネイティブブロックチェーンプロトコルに加えて、どのオーバーレイプロトコル（複数可）をサポートするかを選択することができる。より具体的には、すべてのトランザクションは、妥当性確認のためにオーバーレイプロトコルに渡され得る前に、ブロックチェーンが有効でなければならない。

【0074】

OP_VERIFを使用するロックスクリプトは、次のように定義することができる：

【表2】

【0075】

ノードバージョン番号「０ｘ２ａｂｃ」を有するカスタムスマートコントラクトを実行するオーバーレイプロトコルをサポートするマイナー、例えばミシェルを考える。ミシェルは、これを自身の構成ファイル設定に「NODE_VERSION＝0x2abc」として反映する。ユーザ、例えばボブが、トランザクションの一部として自身のカスタムコントラクトを妥当性確認させたい場合、ボブは、上記で提案されたフォーマットを使用してロックスクリプトを有するアウトポイントを使用するトランザクションを作成する。ミシェルがボブのトランザクションを受信すると、オペコードOP_VERIFは、ミシェルのノードバージョン番号を検出し、それをロックスクリプト内のバージョン番号と比較する。バージョンが一致するので、カスタムスマートコントラクトトランザクションが読み取られ、妥当性確認される。すなわち、分岐１および分岐２の両方が実行される。非参加のマイナーがボブのトランザクションを受信する場合、それらのノードバージョン番号は一致しないので、第２の分岐のコンテンツをスキップし、ボブのトランザクションを、分岐１のみが実行される標準的なトランザクションとして扱う。OP_VERへの呼出しを含むトランザクションが使用されるときに従う可能性のある例示的な論理フローは、次のとおりであり得る：

【数1】

【0076】

バージョン固有のコンテンツの結果を代替スタック（alt stack）に移動させること（ステップ４）で、すべてのアクタが正直であるとき、トランザクション妥当性確認結果が決定論的となり、マイナーのノードバージョンから独立していることが保証される。しかしながら、悪意のあるユーザまたは計算バグにより、バージョン固有の分岐の結果がメインスタック（main stack）に残ることがある（ステップ１～３）。これは、OP_VERトランザクションが一部のノードに対しては有効であるが、他のノードに対しては有効でない可能性があるので、ネットワークパーティショニングの可能性をもたらす。

【0077】

書き込みの時点では、OP_VERおよびそれに関連するオペコードOP_VERIF、OP_VERNOTIFはまだ実装されていない。これらのバージョン固有のコードは、追加のチェックをトリガすることによってブロックチェーントランザクションにおける追加の機能を可能にし、その結果は、代替スタック（ALT stack）に書き込まれ得る。しかしながら、悪意のあるユーザにより、バージョン固有の分岐の結果がメインスタックに戻されるトランザクションが作成された場合、ネイティブ妥当性確認プロセス中に不一致（inconsistency）が生じることとなる。そのようなトランザクションが標準的な（バージョン管理されていない）ノードによって公開されたブロックに挿入された場合、その不一致は、ネットワークのパーティションへと変わる。

【0078】

以下のスクリプトを考える：
TRUE 0x12ab OP_VERIF FALSE OP_ENDIF

【0079】

標準的なノードは、このスクリプトをＴＲＵＥと評価し、一方、バージョン固有のノード（バージョン番号０ｘ１２ａｂを有する）は、このスクリプトをＦＡＬＳＥと評価する。スクリプトについての見解の不一致により、トランザクションの有効性についての見解が不一致になり、これによりさらにネットワークのパーティショニングが起こる。攻撃者は、この脆弱性を悪用して、ネットワークをパーティショニングする目的でトランザクションを作成することができ、その結果、上記で説明したセキュリティ上の欠陥および非効率性が生じる。

【0080】

したがって、オペコードのOP_VERファミリーの処理の改善が必要であることが認識される。

【0081】

５.バージョン管理されたスクリプトエンジン
図４は、本開示の実施形態による、ブロックチェーンスクリプトを実行するための例示的なシステム４００を示す。システム４００は、ブロックチェーンノード１０４と、１人以上のユーザ、例えばアリス１０３ａおよびボブ１０３ｂとを含む。ブロックチェーンノードは、第１のトランザクションおよび第２のトランザクションを、例えばアリス１０３ａおよびボブ１０３ｂからそれぞれ取得するように構成される。代替的に、第１および／または第２のトランザクションは、異なるノード１０４から、またはブロックチェーン１５０から直接、取得されてもよい。

【0082】

第２のトランザクションは、第１のトランザクションの出力を参照する入力を含み、したがって、第２のトランザクションのロック解除スクリプトは、第１のトランザクションのロックスクリプトをロック解除しようとする。第２のトランザクションを妥当性確認するために、ノード１０４は、第２のトランザクションのロック解除スクリプトを第１のトランザクションのロックスクリプトと並行して実行する。いくつかのブロックチェーンプロトコルによれば、ロック解除スクリプトが最初に実行され、続いてロックスクリプトが実行される。他のプロトコルは、ロックスクリプトを最初に実行してもよい。

【0083】

ブロックチェーンノード１０４は、ネイティブスクリプトエンジン、例えば、図３を参照して説明したスクリプトエンジン４５２を有する。ネイティブスクリプトエンジンは、トランザクションを実行するために使用される。より具体的には、ネイティブスクリプトエンジンは、トランザクションのロック解除スクリプトおよびロックスクリプトを実行するために使用される。トランザクションが受信されると、受信されたトランザクションの入力のロック解除スクリプトと、その入力によって参照されるトランザクション出力のロックスクリプトとを使用して、スクリプトが形成される。従来、ネイティブスクリプトエンジンは、スクリプト全体を実行するか、または少なくともスクリプト全体を実行しようとする。この実行は、例えば、無効な要素（例えば、関数）に遭遇した場合、早期に終了し得る。別の例として、リターン関数（例えば、OP_RETURN）に遭遇した場合に、スクリプトの実行は終了し得る。スクリプトが早期に終了した場合、残りのスクリプトは実行されない。

【0084】

本開示によれば、ブロックチェーンノード１０４は、ネイティブスクリプトエンジンに加えて、バージョン管理されたスクリプトエンジンも有する。バージョン管理されたスクリプトエンジンは、ブロックチェーンスクリプトを実行するように構成される。ネイティブスクリプトエンジンとバージョン管理されたスクリプトエンジンとの違いは、バージョン管理されたスクリプトエンジンによるスクリプトの実行が、トランザクション（すなわち、ロック解除スクリプトを含むトランザクションまたはロックスクリプトを含むトランザクション）の有効性に影響を与えないことである。

【0085】

ネイティブスクリプトエンジンおよび／またはバージョン管理されたスクリプトエンジンは、完全にソフトウェアで、完全にハードウェアで、またはソフトウェア構成要素とハードウェア構成要素の両方の組合せを使用して実装され得る。

【0086】

ネイティブスクリプトエンジンがバージョン関数に遭遇する（すなわち、検出する）と、ネイティブスクリプトエンジンは、スクリプトの実行を終了し、実行されたスクリプト、すなわち、バージョン関数まで実行されたスクリプト（バージョン関数は含まない）に基づいて、トランザクションが有効であるかどうかを決定するように構成される。トランザクションが有効である場合、ネイティブスクリプトエンジンは、未実行のスクリプト（バージョン関数を含む）をバージョン管理されたスクリプトエンジンに送信する。次いで、バージョン管理されたスクリプトエンジンは、残りのスクリプトを実行する。残りのスクリプトは、「バージョン管理されたスクリプト」と呼ばれることがある。バージョン管理されたスクリプトエンジンは、バージョン関数の扱いを除いて、ネイティブスクリプトエンジンと同じ方法でスクリプトを実行する。バージョン管理されたスクリプトエンジンがバージョン関数に遭遇した場合、バージョン管理されたスクリプトエンジンは、バージョン関数を実行する。

【0087】

トランザクションがネイティブスクリプトエンジンによって無効であると決定された場合、トランザクションは拒否され、残りのスクリプトはバージョン管理されたスクリプトエンジンに送信されない。

【0088】

バージョンオペコードに遭遇したときにネイティブスクリプトエンジンによるスクリプトの実行を終了することによって、各ブロックチェーンノード１０４は、トランザクションが有効であるか無効であるかについて同じ見解を有することになる。これは、各ブロックチェーンノード１０４のネイティブスクリプトエンジンが同じ方法でスクリプトを実行し、トランザクション有効性がネイティブスクリプトエンジンによってのみ影響され、バージョン管理されたスクリプトエンジンによっては影響されないからである。したがって、バージョン管理されたスクリプトエンジンによる残りのスクリプトの実行の結果は、トランザクションの有効性に影響を与えることなく、ノード１０４間で異なり得る。これにより、異なるノードは、ネットワークパーティショニングを引き起こすことなく、スクリプトの部分を異なって（例えば、それらの能力に依存して）実行することができる。

【0089】

実行されるスクリプト全体は、第１のトランザクションのロックスクリプトおよび第２のトランザクションのロック解除スクリプトから形成される（第１および第２は任意のラベルである）。スクリプト全体は、第１のスクリプト部分と、バージョン関数と、第２の部分とをこの順序で含む。一般に、バージョン関数は、第１のトランザクションのロックスクリプトまたは第２のトランザクションのロック解除スクリプトに由来し得る（すなわち、その一部として含まれ得る）が、前者の可能性の方が高い。ネイティブスクリプトエンジンは、第１のスクリプト部分、すなわち、ネイティブスクリプトエンジンまでのスクリプトの部分のみを実行する。ネイティブスクリプトエンジンがバージョン関数に遭遇すると、ネイティブスクリプトエンジンは、バージョン管理されたスクリプトエンジンに、バージョン関数および第２のスクリプト部分を含むサブスクリプトを供給する。このプロセスを図５に概略的に示す。

【0090】

いくつかの例では、第１のスクリプト部分は、ターゲットバージョン番号を表すデータ要素を含み得る。これらの例では、バージョン管理されたスクリプトエンジンに供給されるサブスクリプトは、ターゲットバージョン番号も含む。ネイティブスクリプトエンジンは、例えば、データ要素のフォーマット、サイズ、タイプなどのうちの１つまたは複数に基づいて、データ要素がターゲットバージョン番号であることを知り得る。代替的に、ネイティブスクリプトエンジンは、バージョン番号に隣接する（例えば、先行する）データ要素をターゲットバージョン番号として解釈し、このデータ要素をサブスクリプトの一部として含んでもよい。ターゲットバージョン番号は、サブスクリプトを作成するときにネイティブエンジンによって実行時に提供されることに留意されたい。すなわち、ネイティブエンジンは、サブスクリプトを作成するとき、サブスクリプトをバージョン管理されたエンジンに供給する前にターゲットバージョン番号を追加する。

【0091】

いくつかの例では、バージョン管理されたスクリプトエンジンがバージョン関数を実行するとき、バージョン管理されたスクリプトエンジンは、ブロックチェーンノード１０４のバージョン番号を（例えば、ノード１０４のメモリから）取得し、バージョン番号を、例えばスタックに出力するように構成される。一般に、バージョン番号は、任意のタイプのメモリ、すなわちコンピュータ可読ストレージに記憶され得る。バージョン番号は、ブロックチェーンノード１０４が提供するように構成された特定のプロトコル、すなわち機能または能力を示す。

【0092】

バージョン番号は、整数を使用して表されることに限定されず、代わりに、文字と整数の両方から構成され得ることに留意されたい。例えば、バージョン番号は１６進数で表されてもよい。

【0093】

いくつかの例では、ブロックチェーンノード１０４は、メモリから取得されたバージョンの代わりに、バージョン番号の固定長表現を出力し得る。例えば、記憶されたバージョン番号は、より長い長さ（例えば、６バイト）であってもよいが、最初の４バイトのみが出力される。

【0094】

バージョン管理されたスクリプトエンジンは、取得されたバージョン番号を、サブスクリプトの一部としてネイティブスクリプトエンジンによって供給されたターゲットバージョン番号と比較し得る。サブスクリプト（具体的には、第２のスクリプト部分）の実行は、取得されたバージョン番号とターゲットバージョン番号とが一致するか否かに依存し得る。例えば、第２のスクリプト部分は、バージョン番号が一致する場合にのみ実行され得る。代替的に、第２のスクリプトは、バージョン番号が一致しない場合にのみ実行されてもよい。

【0095】

いくつかの例では、第２のスクリプト部分自体が、それぞれのスクリプト部分（すなわち、第２のスクリプト部分のそれぞれのセクション）およびそれぞれのターゲットバージョン番号にそれぞれ関連付けられた１つまたは複数のバージョン関数を含み得る。バージョン管理されたスクリプトエンジンは、関連付けられたそれぞれのターゲットバージョン番号に基づいて各それぞれのスクリプト部分を実行するように構成され得る。例えば、それぞれのスクリプト部分は、それぞれのターゲットバージョン番号が、ブロックチェーンノード１０４に関連付けられたバージョン番号と一致する場合にのみ実行され得る。代替的に、それぞれのスクリプト部分は、それぞれのターゲットバージョン番号が、ブロックチェーンノード１０４に関連付けられたバージョン番号と一致しない場合にのみ実行されてもよい。いくつかのそれぞれの部分が実行され（例えば、一致するバージョン番号のために）、いくつかのそれぞれのスクリプト部分が実行されない（例えば、一致しないバージョン番号のために）場合、またはその逆の場合もあり得る。

【0096】

ブロックチェーンノード１０４は、第２のスクリプト部分を実行した結果および／または第２のスクリプト部分のそれぞれのスクリプト部分を実行したそれぞれの結果を、例えばメモリに、スタックに、１人以上のユーザ１０３ａ、１０３ｂに、またはブロックチェーンに出力するように構成され得る。例えば、結果（複数可）は、ブロックチェーントランザクションの出力（例えば、OP_RETURN出力）に含まれ得る。

【0097】

いくつかの例では、ブロックチェーンノード１０４は複数の結果を取得し得、各結果は、それぞれのバージョン管理されたスクリプトを実行した結果である。ブロックチェーンノード１０４は、結果をマークルツリーのそれぞれのリーフとして使用してマークルツリーを構築し、マークルツリーのルートをブロックチェーン上に、例えばOP_RETURN出力の一部として記憶し得る。バージョン管理されたスクリプトは、何らかの方法で関連している可能性があり、例えば、トークンプロトコルなどの同じレイヤ２プロトコルまたはアプリケーションに関連し得る。

【0098】

一般に、バージョン管理されたスクリプトは、任意のタイプのスクリプトまたはコードを含み得る。例えば、バージョン管理されたスクリプトは、ネイティブブロックチェーンスクリプト言語で書かれたスクリプト、例えばScript、の一部を含み得る。言い換えると、コードの一部は、任意のブロックチェーンノードが実行するように構成されたネイティブスクリプト言語のデータおよび／またはオペコードを含み得る。例えば、Ｐ２ＰＫＨ（pay-to-public-key-hash）出力の場合のように、コードの一部は、ロック解除スクリプトが対応する公開鍵および署名を含むことを要求するブロックチェーンアドレスおよびスクリプトを含み得る。

【0099】

他の例では、バージョン管理されたスクリプトは、非ネイティブスクリプト言語、すなわち、異なるブロックチェーンに対してネイティブなスクリプト言語で書かれたスクリプトの一部を含み得る。例えば、ネイティブスクリプト言語は、ビットコインブロックチェーンに対してネイティブであってもよく、非ネイティブスクリプト言語は、Ｅｔｅｒｅｕｍブロックチェーンに対してネイティブであってもよい。

【0100】

いくつかの例では、バージョン管理されたスクリプトは、非ブロックチェーン言語、すなわち、いずれのブロックチェーンにも固有でない言語で書かれたコードを含み得る。例えば、コードの一部は、Ｃ、Ｃ＋＋、Ｇｏ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）などのプログラミング言語を使用して書かれてもよい。

【0101】

６.バージョン管理されたスクリプトエンジン＆OP_VER
このセクションは、OP_VERオペコードのファミリーのうちの１つであるバージョン関数のコンテキストにおいて、説明される実施形態のさらなる例を提供する。OP_VERは、ネイティブスクリプトエンジンによるスクリプト実行の終了およびバージョン管理されたスクリプトエンジンによるスクリプト実行のトリガをトリガするために使用され得るバージョン関数の一例にすぎないことを認識されたい。

【0102】

バージョン管理されたスクリプトエンジンをデュアル検証スクリプトエンジンの一部として使用することで、OP_VERコードのファミリーの実装および使用に大きな制限を課すことなく、ネットワークパーティショニングを防止する。デュアル検証スクリプトエンジンは、これらのバージョン固有のオペコードが、スクリプト内のバージョン管理された分岐のためのデフォルトの妥当性確認エンジンであり、バージョン固有のオーバーレイ妥当性確認を容易にする、本明細書ではバージョン管理されたエンジン（versioned engine）と呼ばれる独立した妥当性確認エンジンを使用することを必要とする。ネイティブエンジン（native engine）という用語は、ネイティブ妥当性確認エンジンを指す。ブロックチェーントランザクションの妥当性確認中、オペコードは、ネイティブエンジンによって順次実行される。第１のOP_VERまたは関連するオペコードに遭遇すると、ネイティブエンジンは終了し、この実行の有効性がネイティブエンジンによってチェックされる。ネイティブ実行が有効であるとみなされる場合、バージョン管理されたエンジンがインスタンス化される（そうでない場合、プロセス全体が終了し、トランザクションが拒否される）。

【0103】

バージョン管理されたエンジンは、トランザクションがブロックチェーンプロトコルにしたがって有効であるかどうかを決定することも影響を及ぼすこともない。バージョン管理されたエンジンからの実行結果は、ネイティブブロックチェーンプロトコルとは独立して解釈され、アプリケーション固有であり得る。

【0104】

バージョン管理されたエンジンは、OP_VERおよびそれに関連するオペコードを除いて、ネイティブエンジンと同じスクリプトルールに従い得る。これは、任意のバージョン管理された分岐が将来リプレイされ得ることを確実にする。代替として、バージョン管理されたエンジンは、ノードバージョン番号によって指定される任意のコードを実行し得る。この手法は、大きな柔軟性を提供する。

【0105】

要約すると、OP_VERに対するこのデュアルエンジン手法は、スクリプト内の標準分岐からバージョン管理された分岐を分離することによって、トランザクションの有効性に関する一貫した見解を提供する。さらに、バージョン管理されたエンジンは、ネイティブエンジンが終了した後にのみインスタンス化されるので、追加のメモリを必要としない。

【0106】

共通のネイティブ妥当性確認プロセスにより、ネットワークをパーティショニングするリスクなしにオンチェーンでトランザクションを公開することができ、バージョン固有の妥当性確認プロセスを使用することで、アプリケーション固有のノードのコミュニティを作成することができる。すなわち、すべてのノードは、ネイティブプロトコルにしたがってトランザクションを妥当性確認するが、ノードのサブセットのみが、それらのノードバージョン番号によって指定される特定のアプリケーションおよびサービス、例えばトークン、スマートコントラクト、またはスニペットを妥当性確認する。

【0107】

OP_VER、OP_VERIF、およびOP_VERNOTIFは、バージョン管理されたエンジンにおいて常に実行されるので、ネイティブエンジンは、これらのオペコードのうちの１つに遭遇した際に、いくつかの特定のステップを実行しなければならない。これをデュアルエンジン妥当性確認（ＤＥＶ）ルールと呼ぶ。

【0108】

バージョニング関連オペコードのネイティブ妥当性確認プロセスは、次の通りである：

【数2】

【0109】

次いで、サブスクリプトに含まれるすべての残りのバージョニング関連オペコードが、バージョン管理されたエンジンにおいて実行される。

【0110】

バージョン管理されたエンジンにおけるバージョニング関連オペコードの挙動は、次の通りである：

【数3】

【0111】

論理的な観点からは、<0x2abc> OP_VERIFは、OP_VER <0x2abc> OP_EQUAL OP_IFと等価である。しかしながら、実行の観点からは、それらがネイティブエンジンにおいて実行されるときに、言及する価値のある差異が存在する：OP_VERIFは、メインスタックから１つの要素を消費するが、OP_VERは消費しない。

【0112】

上記の論理にしたがって、ロックスクリプト内のコードの標準分岐およびバージョン管理された分岐を、例えば以下に示すように、同じスクリプト内に含めることができる。

【表3】

【0113】

特定のブロックチェーンプロトコルに依存して、有効なトランザクションを有するために、標準分岐は、任意のバージョニングオペコードの前に現れることが必要とされ得る。

【0114】

スクリプトを直ちに終了させる任意のオペコード（例えば、OP_RETURN）の挙動は変更されないままであり、それにより、ネイティブエンジンとバージョン管理されたエンジンの両方でスクリプト全体を終了させることに留意されたい。

【0115】

各ノードには最大で１つのバージョン番号が割り当てられるが、単一のバージョン番号で、バージョン管理されたコードの２つ以上の分岐へのアクセスを提供し得る。以下のロックスクリプトを考える。OP_VER 0x1 OP_EQUAL OP_IF <…>
OP_VER 0x2 OP_EQUAL OP_NOTIF <…＞

【0116】

ここで、異なる条件文の使用は、両方の分岐がバージョン番号０ｘ１を有するノードによって実行されることを意味する。

【0117】

次に、バージョン番号０ｘ１を有するノードの観点からのＤＥＶプロセスの２つの例について説明する。第１の例では、OP_VERを使用して、バージョン管理されたエンジン内の所定の数に１を加算し、第２の例では、OP_VERIFを使用して、同じ結果を達成する。

【0118】

OP_VERを使用した例：
ロックスクリプトは次の通りである：

【数4】

【0119】

ロック解除スクリプトは次の通りである：
<Sig><PubKey＞

【0120】

ロック解除スクリプトとロックスクリプトの連結は、次のように妥当性確認されるスクリプトを与える：

【数5】

【0121】

標準分岐の終わりに、ネイティブエンジンのメインスタックの最上部は、署名チェックの結果（例えば、真）を含む：

【表4】

OP_VERに遭遇すると、ネイティブエンジンは終了する。サブスクリプトは、次のように作成される：

【数6】

【0122】

バージョン管理されたエンジンは、サブスクリプトを実行するためにインスタンス化される。

【表5】

【0123】

サブスクリプトの実行は、OP_VERで始まり、これは、バージョン管理されたエンジン内のノードのバージョン番号（例えば０ｘ１）をプッシュする。

【表6】

【0124】

妥当性確認されるべき残りのサブスクリプトは次の通りである：
0x1 OP_EQUAL OP_IF OP_5 OP_1ADD OP_ENDIF

【0125】

ここで、０ｘ１が、バージョン管理されたメインスタックにプッシュされる：

【表7】

【0126】

残りのサブスクリプト：
OP_EQUAL OP_IF OP_5 OP_1ADD OP_ENDIF

【0127】

OP_EQUALオペコードが実行され、結果がスタックに書き込まれる：

【表8】

【0128】

残りのスクリプト：
OP_IF OP_5 OP_1ADD OP_ENDIF

【0129】

残りのオペコードが実行される。OP_IFは、バージョン管理されたスタック内の最上位の要素を消費し、残りのオペコードが消費され、結果がバージョン管理されたスタックに書き込まれる：

【表9】

【0130】

ネットワーク内のすべてのノードに対するスクリプト妥当性確認結果は、次の通りである：

【数7】

【0131】

OP_VERIFを使用した例：
ロックスクリプト：

【数8】

【0132】

ロック解除スクリプトは次の通りである：
<Sig><PubKey＞

【0133】

したがって、妥当性確認されるスクリプトは、次の通りである：

【数9】

【0134】

標準分岐の終わりに、メインスタックの最上部は、署名チェックの結果（例えば、真）を含み、次いで、０ｘ１がスタックにプッシュされる。両方のエンジンのメインスタックの状態は、次の通りである：

【表10】

【0135】

OP_VERIFに遭遇すると、メインスタック上の最上位の要素が消費され、記憶される。その後、ネイティブエンジンは終了する。実行が有効であるので、サブスクリプトは、次のように作成される：

【数10】

【0136】

バージョン管理されたエンジンは、サブスクリプトを実行するためにインスタンス化される。

【表11】

【0137】

０ｘ１は、バージョン管理されたエンジンのメインスタックにプッシュされる。

【表12】

【0138】

OP_VERIFは、OP_VER OP_EQUAL OP_IFとして実行され、実行はOP_5 OP_1 OP_ADDへと続く。

【表13】

【0139】

スクリプト妥当性確認結果は、次の通りである：

【数11】

【0140】

上記の例で説明されたデュアル妥当性確認は、次のように一般化され得る。バージョニング関連オペコードを含むトランザクションを妥当性確認するとき、以下の論理フローに従う：

【数12】

【0141】

OP_VERファミリーの使用および機能は、複数のバージョン番号を含むスクリプトを容易にするように拡張され得る。例えば、次の通りである：

【表14】

【0142】

ネイティブエンジンからの妥当性確認結果は、トランザクションをブロック内で公開することができるかどうかを決定するが、バージョン管理されたエンジンからの妥当性確認結果は、トランザクションの公開に影響を与えない。しかしながら、バージョン管理されたエンジンからの妥当性確認結果が記録される場合、ネイティブ妥当性確認がＴＲＵＥを与える場合にのみバージョン管理されたエンジンをインスタンス化することができるので、トランザクションは有効でなければならない。したがって、バージョン管理された妥当性確認結果の任意のオフチェーン記録について、公開されたトランザクションを識別し、スクリプトの実行をリプレイして、同じ結果を得ることができる。将来の任意の所与の時間にスクリプトをリプレイするこの能力は、OP_VERベースのアプリケーションおよびサービスをより透過的かつ監査可能なものとし、したがって、より信頼できるものにする。

【0143】

より便利にするために、バージョン管理された妥当性確認結果（すなわち、OP_VERに続くスクリプトを実行した結果）の記録は、OP_RETURNペイロードとしてトランザクションにおいて公開されてもよいし、そのマークルルートをビットコイントランザクションにおいて公開することができるマークルツリーに統合されてもよい。これは、ノード１０４、アプリケーションもしくはサービスプロバイダ、または専用のサードパーティによって行うことができる。関連するスクリプトの実行をリプレイすることによってすべての結果を公的に得ることができるので、結果に対して不正を行うことはないであろう。例えば、OP_VERベースのトークンシステムでは、トークン発行者は、少なくとも６ブロックの深さであるすべてのトークントランザクションを収集し、バージョン管理された妥当性確認結果から流通中のトークンの割振りなどのシステム状態を導出し、発行者自身が署名したトランザクションでシステム状態を公開することができる。

【0144】

以下では、トークントランザクションがトークン固有のバージョン番号を使用して実装されるユースケースについて説明する。共生（commensal）トークンチェーンは、トークン値をビットコインにペグし、バージョン管理された分岐を使用してトークンルールを妥当性確認する。各トークンチェーンは専用のノードバージョン番号を有し、各トークントランザクションは、１つのタイプのトークンのみを表す。

【0145】

このセクションでは、異なるトークンチェーンからのトークンを１つのトランザクションにマージする方法、およびその後にそれらを分割する方法を説明する。すべてのトークン発行者が、共生トークンチェーンを使用してトークンを発行し、管理するトークンプラットフォームがあると仮定する。トークンは、このプラットフォーム上で金融商品として取引することができる。トランザクションの交換を簡単にするために、トークンを取引するための基準通貨は不換通貨と仮定され、ブロックチェーンに対して独立して決済される（基準通貨がビットコインである場合、ビットコインプラットフォームにおいてトークントランザクションを示すために追加の入力－出力ペアが必要とされる）。トークントランザクションがトークン有効であることをチェックした後、ビットコイン有効にするためにトークントランザクションにサインオフする信頼できるオラクルが存在すると仮定される。オラクルは、有効なトークントランザクションに対する署名の提供を保証し、トークン無効である有効なトランザクションを作成することによってトークンをバーンしないという意味で信頼できる。詳細については、以下のトランザクションの例で説明する。

【0146】

アリスをトークン発行者とする。アリスは、ノードバージョン番号を０ｘａａａａに設定してアリスのトークンを表すビットコインノード、例えばナタリーと提携することができる。ボブを別のトークン発行者とし、ボブは、ノードバージョン番号を０ｘｂｂｂｂに設定してボブのトークンを表す異なるビットコインノード、例えばミュシャと提携する。

【0147】

アリスのトークンから開始して、アリスは、１０００ユニットのトークンを投資家イワンに発行するためにトークン発行トランザクションを作成する。これは、ＩＴＯ（initial token offering）とみなされ得る。アリスのトランザクションを図６に示す。トークン値は、ビットコイントランザクションにおけるサトシの数に固定され、そのため、１トークン単位は１サトシに等しいことに留意されたい。トークン転送は、バージョン管理された分岐で捕捉されるが、標準分岐は、トークン転送を搬送するために有効なビットコイントランザクションを作成する。同様に、ボブは、ボブの１０００ユニットのトークンを別の投資家イヴァンカに発行する。ボブのトランザクションを図７に示す。

【0148】

ここで、フレッドを、アリスのトークンとボブのトークンの両方に関心があるファンドマネージャーであると仮定する。フレッドは、それぞれアイバンおよびイヴァンカから１０００ユニットのトークンを購入する。これらのトークンの転送は、図８に示すように、単一のトランザクションでキャプチャすることができる。ここで、フレッドのトークンポートフォリオは、異なるタイプのトークンの転送を組み合わせるトランザクションの１つの出力によってキャプチャされる。アリスのトークンをある程度評価した後、フレッドは、図９に示すトランザクションを使用して、それらをフェリックスに売ることを決定する。

【0149】

ノード１０４はＴｘＩＤ_１の出力における両方のバージョン管理された分岐を妥当性確認しないので、フレッドのデジタル署名の２つのコピーを必要としないことに留意されたい。この時点で、アリスのトークンチェーンの状態は、ＴｘＩＤ_Ａ、ＴｘＩＤ_１、およびＴｘＩＤ_２に基づいてナタリーによって維持され、ボブのトークンチェーンの状態は、ＴｘＩＤ_Ｂ、ＴｘＩＤ_１、およびＴｘＩＤ_２に基づいてミュシャによって維持される。

【0150】

公開される前にトランザクションをインターセプトすることができる敵対者は、トランザクションがビットコイン有効でありながらもトークン無効になるように、トークントランザクションの入力内のロック解除スクリプトを変更する可能性がある。例えば、敵対者は、バージョン管理された分岐によって検証されるロック解除スクリプト内の署名、すなわち、ＴｘＩＤ_２内の<Sig_Fred><PK_Fred>を変更または除去することができる。このタイプの攻撃は、トークンサービスを事実上拒否または妨害する。そのような攻撃を軽減する１つの方法は、オラクルが、ビットコインノードとユーザとの間のセキュアな通信チャネルであるｍＡＰＩを介して、バージョン管理されたノードにトランザクションを送信することである。トークントランザクションを受信した後、ノード１０４は、それらのトークントランザクションを含むブロックの有効なブロックヘッダが見つかった後にのみトークントランザクションを伝搬する。

【0151】

このユースケースは、１つの出力中に複数のバージョン番号を有することが有利であることを実証する。この利点は、トークンプラットフォームの各ユーザが、保持しているトークンのタイプの数に関係なく、いつでも１つのトランザクション出力を管理するだけでよいことである。

【0152】

６．さらなる備考
開示される技法の他の変形形態またはユースケースは、本明細書の開示が与えられると、当業者には明らかになり得る。本開示の範囲は、説明された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

【0153】

例えば、上記のいくつかの実施形態は、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０およびビットコインノード１０４に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン１５０の１つの特定の例であり、上記の説明は一般に任意のブロックチェーンに適用されてもよいことが理解されるであろう。すなわち、本発明はビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０およびビットコインノード１０４への上記の任意の参照は、それぞれブロックチェーンネットワーク１０６、ブロックチェーン１５０およびブロックチェーンノード１０４への参照に置き換えられてもよい。ブロックチェーン、ブロックチェーンネットワークおよび／またはブロックチェーンノードは、上記で説明したようなビットコインブロックチェーン１５０、ビットコインネットワーク１０６およびビットコインノード１０４の説明されたプロパティの一部またはすべてを共有してもよい。

【0154】

本発明の好ましい実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークであり、ビットコインノード１０４は、ブロックチェーン１５０のブロック１５１を作成、公開、伝搬、および記憶する説明した機能を少なくともすべて実行する。これらの機能のすべてではなく１つまたはいくつかのみを実行する他のネットワークエンティティ（またはネットワーク要素）が存在し得ることは除外されない。すなわち、ネットワークエンティティは、ブロックを作成および公開することなしに、ブロックを伝搬および／または記憶する機能を実行し得る（これらのエンティティが好ましいビットコインネットワーク１０６のノードとみなされないことを想起されたい）。

【0155】

本発明の他の実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を作成、公開、伝搬、および記憶する機能のうちの少なくとも１つまたはすべてではないがいくつかを実行してもよいことは除外されない。例えば、それらの他のブロックチェーンネットワーク上では、「ノード」は、ブロック１５１を作成および公開はするが、それらのブロック１５１を記憶および／または他のノードへの伝搬はしないように構成されたネットワークエンティティを指すために使用され得る。

【0156】

さらにより一般的には、上記の「ビットコインノード」１０４という用語へのいかなる言及も、「ネットワークエンティティ」または「ネットワーク要素」という用語と置き換えラレ絵、そのようなエンティティ／要素は、ブロックを作成、公開、伝搬、および記憶する役割の一部または全部を実行するように構成される。そのようなネットワークエンティティ／要素の機能は、ブロックチェーンノード１０４を参照して上記で説明したものと同じ方法でハードウェアに実装されてもよい。

【0157】

上記の実施形態は、単なる例として説明されていることが理解されるであろう。より一般的には、以下のステートメントのうちの任意の１つまたは複数による方法、装置、またはプログラムが提供され得る。

【0158】

＜ステートメント１＞第１のブロックチェーントランザクションのロックスクリプトおよび第２のブロックチェーントランザクションのロック解除スクリプトから形成されたスクリプトを実行するコンピュータ実装方法であって、スクリプトは、第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含み、方法は、ブロックチェーンノードによって実行され、
ネイティブスクリプトエンジンが第１のスクリプト部分を実行するステップと、
バージョン関数に遭遇すると、ネイティブスクリプトエンジンが、スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって第１のスクリプト部分が有効であるかどうかを決定するステップと、
第１のスクリプト部分が有効であると決定したことに応答して、ネイティブスクリプトエンジンが、少なくともバージョン関数および第２のスクリプト部分を含むサブスクリプトを、バージョン管理されたスクリプトエンジンに供給するステップと、
バージョン管理されたスクリプトエンジンがサブスクリプトを実行するステップであって、バージョン管理されたスクリプトエンジンによるサブスクリプトの実行は、第１のブロックチェーントランザクションおよび／または第２のブロックチェーントランザクションの有効性に影響を与えない、ステップと
を含む方法。

【0159】

＜ステートメント２＞第１のスクリプト部分は、ターゲットノードプロトコルバージョン番号を含み、サブスクリプトは、ターゲットノードプロトコルバージョン番号を含む、ステートメント１に記載の方法。

【0160】

＜ステートメント３＞サブスクリプトを実行する上記ステップは、バージョン関数を実行するステップを含み、バージョン関数を実行する上記ステップは、
ブロックチェーンノードのノードプロトコルバージョン番号を取得するステップと、
ノードプロトコルバージョン番号を出力するステップであって、ノードプロトコルバージョン番号は、ブロックチェーンノードが実行するように構成された特定の機能に関連付けられる、ステップと
を含む、ステートメント１またはステートメント２に記載の方法。

【0161】

＜ステートメント４＞バージョン関数を実行する上記ステップは、出力されたノードプロトコルバージョン番号がターゲットノードプロトコルバージョン番号と一致するかどうかを決定するステップを含む、ステートメント２およびステートメント３に記載の方法。

【0162】

＜ステートメント５＞バージョン関数を実行する上記ステップは、
出力されたノードプロトコルバージョン番号がターゲットノードプロトコルバージョン番号と一致する場合、第２のスクリプト部分を実行するステップと、
出力されたノードプロトコルバージョン番号がターゲットノードプロトコルバージョン番号と一致しない場合、第２のスクリプト部分を実行しないステップと
を含む、ステートメント４に記載の方法。

【0163】

＜ステートメント６＞バージョン関数を実行する上記ステップは、
出力されたノードプロトコルバージョン番号がターゲットノードプロトコルバージョン番号と一致する場合、第２のスクリプト部分を実行しないステップと、
出力されたノードプロトコルバージョン番号がターゲットノードプロトコルバージョン番号と一致しない場合、第２のスクリプト部分を実行するステップと
を含む、ステートメント４に記載の方法。

【0164】

＜ステートメント７＞第２のスクリプト部分は、複数のそれぞれのバージョン関数を含み、各それぞれのバージョン関数は、それぞれのスクリプト部分に関連付けられる、いずれかの先行するステートメントに記載の方法。

【0165】

＜ステートメント８＞各それぞれのスクリプト部分は、それぞれのターゲットノードプロトコルバージョン番号に関連付けられ、方法は、
バージョン管理されたスクリプトエンジンが、ノードプロトコルバージョン番号に基づいてそれぞれのスクリプト部分を実行するステップ
を含む、ステートメント７に記載の方法。

【0166】

＜ステートメント９＞サブスクリプトの上記実行の結果をユーザに出力するステップを含む、いずれかの先行するステートメントに記載の方法。

【0167】

＜ステートメント１０＞サブスクリプトの上記実行の結果をブロックチェーンに記憶するステップ
を含む、いずれかの先行するステートメントに記載の方法。

【0168】

＜ステートメント１１＞複数のそれぞれの結果を取得するステップであって、各それぞれの結果は、それぞれの第１のブロックチェーントランザクションのそれぞれのロックスクリプトおよびそれぞれの第２のブロックチェーントランザクションのそれぞれのロック解除スクリプトから形成されたそれぞれのスクリプトの実行から取得され、それぞれのスクリプトは、それぞれの第１のスクリプト部分、それぞれのバージョン関数、およびそれぞれの第２のスクリプト部分を含む、ステップと、
複数のそれぞれの結果に基づいてマークルツリーを生成するステップと、
マークルツリーのマークルルートをブロックチェーンに記憶するステップと
を含む、いずれかの先行するステートメントに記載の方法。

【0169】

＜ステートメント１２＞ノードプロトコルバージョン番号を出力する上記ステップは、ノードプロトコルバージョン番号の固定長表現を出力するステップを含む、ステートメント３またはそれに従属する任意のステートメントの方法。

【0170】

＜ステートメント１３＞第２のスクリプト部分は、ネイティブブロックチェーン言語以外の言語で書かれたコードの一部を含み、ブロックチェーンノードは、その言語で書かれたコードを実行するように構成される、いずれかの先行するステートメントに記載の方法。

【0171】

＜ステートメント１４＞コードの一部は、ネイティブブロックチェーン言語以外のブロックチェーン言語で書かれている、ステートメント１３に記載の方法。

【0172】

＜ステートメント１５＞第２のスクリプト部分は、公開鍵および／または公開鍵ハッシュに基づくロック条件を含む、ステートメント１から１２のいずれかに記載の方法。

【0173】

＜ステートメント１６＞第１のトランザクションおよび第２のトランザクションは、それぞれトークントランザクションであり、ターゲットノードプロトコルバージョン番号は、トークンプロトコルに関連付けられる、いずれかの先行するステートメントに記載の方法。

【0174】

＜ステートメント１７＞バージョン関数は、オペコードOP_VER、OP_VERIF、またはOP_VERIFNOTのうちの１つである、いずれかの先行するステートメントに記載の方法。

【0175】

＜ステートメント１８＞コンピュータ機器であって、
１つまたは複数のメモリユニットを備えるメモリと、
１つまたは複数の処理ユニットを備える処理装置と
を備え、メモリは、処理装置上で実行されるように構成されたコードを記憶し、コードは、処理装置上にあるときに、いずれかの先行するステートメントに記載の方法を実行するように構成される、
コンピュータ機器。

【0176】

＜ステートメント１９＞コンピュータ可読記憶装置上に具現化され、１つまたは複数のプロセッサ上で実行されると、ステートメント１から１７のいずれかに記載の方法を実行するように構成されたコンピュータプログラム。

【0177】

＜ステートメント２０＞ネイティブスクリプトエンジンおよびバージョン管理されたスクリプトエンジンを含むブロックチェーンスクリプトエンジンであって、ネイティブスクリプトエンジンは、
第１のスクリプト部分、バージョン関数、および第２のスクリプト部分を含むスクリプトを実行することと、
バージョン関数に遭遇すると、スクリプトの実行を終了し、ブロックチェーンプロトコルにしたがって第１のスクリプト部分が有効であるかどうかを決定することと、
第１のスクリプト部分が有効であると決定したことに応答して、少なくともバージョン関数および第２のスクリプト部分を含むサブスクリプトをバージョン管理されたスクリプトエンジンに供給することと
を行うように構成され、
バージョン管理されたスクリプトエンジンは、サブスクリプトを実行するように構成される、
ブロックチェーンスクリプトエンジン。

【図1】