JP2023536163A - ブロックチェーントークン - Google Patents

Abstract

トークン取引は第１のトークン出力を含み、第１のトークン出力は第１のトークンロッキングスクリプト及び第１のトークンの額を含み、第１のトークンロッキングスクリプトは可変コンポーネント及び定数コンポーネントを含み、可変コンポーネントは支払テンプレートに埋め込まれた第１の支払アドレスを含み、定数コンポーネントはトークンメカニクスサブコンポーネントを含む。

Description

本開示は、ブロックチェーン取引を用いてトークンを送信（例えば、発行、譲渡、分割、交換、償還）する方法に関する。

ブロックチェーンは、取引を用いて基礎となるデジタル資産（underlying digital asset）の移転を可能にする。このデジタル資産は、しばしば「暗号通貨」又は「ネイティブトークン」と呼ばれる。これは、特定のブロックチェーンに固有のデジタル資産である。理解を助ける実例として、ビットコインブロックチェーンのデジタル資産はビットコインとして知られている。

ブロックチェーンを用いて移転され得る別の種類のデジタル資産は、「トークン」である。ブロックチェーン技術の文脈では、トークンは、取引内の追加のデータフィールドを用いて通常作成及び定義される。「トークンデータ」と呼ばれるこの追加データは、ブロックチェーンのユーザ又は特定のトークンプロトコルのユーザによってトークンとして解釈される。つまり、ユーザは、取引、より具体的には特定のトークンデータ（例えば、トークンプロトコルフラグ、続いて数量）を含む取引の出力部分がトークンとして解釈され、用いられることに同意する。出力を所有する者（通常は出力がロックされているアドレスのユーザを意味する）がトークンを所有する。その後、トークンは、特定のトークンプロトコルに従って、特定の目的のために使用、販売、トレード等を行うことができる。例えば、映画館のチケットがユーザにトークンを発行し、ユーザは映画館で映画を見ることの引き換えにトークンの代金を支払うか又は銀行は、顧客の米ドル預金と引き換えにトークンを発行し、が定期的な支払いで使用し、顧客はそれを通常の支払いに用いることができ、後でサードパーティは銀行でそれを米ドルに交換できる。

上述したように、ブロックチェーンを用いてトークンを作成する以前の試みでは、通常、出力スクリプトコード又は追加の別の非一時停止可能な出力にトークンデータを含めることにより取引の追加データフィールドにトークンを定義することを伴う。これらのトークンは、トークンが作られるブロックチェーンの基礎となるデジタル資産（それ自体がそのネイティブトークンから構成される）とは異なる。つまり、これらの以前のスキームに従ったトークンを含む取引は、基礎となるデジタル資産（又は「ネイティブトークン」）を通常どおり用いながら、追加のデータ構造で新たなトークンも作成していた。新たなトークンはネイティブトークンとは無関係であった。新たに作られたトークンをそれらのネイティブなトークンから切り離すには、全ての最新の試みが失敗したものを実現するために負担が大きく不必要な調整が必要であり、最終的に、意図するトークンの大規模な採用に達するのを妨げる。

本明細書で開示の１つの態様によれば、ブロックチェーン取引を用いてデジタルトークンを送信するコンピュータ実施方法が提供される。各トークンはブロックチェーンの基礎となるデジタル資産の固有の単位の単一の単位によって表される。当該方法は、第１のトークン取引を生成することと、前記第１のトークン取引をブロックチェーンネットワークに送信することと、を含む。前記第１のトークン取引は第１のトークン出力を含み、該第１のトークン出力は第１のトークンロッキングスクリプト（locking script）及び第１のトークンの額を含む。該第１のトークンロッキングスクリプトは可変コンポーネント（variable component）及び定数コンポーネント（constant component）を含む。該可変コンポーネントは、支払テンプレートに埋め込まれた第１の支払アドレスを含む。該定数コンポーネントはトークンメカニクスサブコンポーネント（token mechanics sub-component）を含み、該トークンメカニクスサブコンポーネントは、支出取引（spending transaction）の入力スクリプトであって、該入力スクリプトは、該支出取引の自身を除く全てに加えて、支出されている以前の取引出力においてロックされている額及びそれぞれのロッキングスクリプトを含む入力スクリプトと共に実行された場合、次の動作を行うように構成されている。第１の動作は、前記支出取引の入力スクリプトから１つ以上のデータ対を取得することであって、各データ対は、ｉ）前記支出取引の出力のそれぞれのロッキングスクリプトに含まれる少なくともそれぞれの支払アドレスと、ｉｉ）その出力のそれぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の対応する額とを含む。別の動作は、前記支出取引の１つ以上の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含むそれぞれのロッキングスクリプトを含むか検証することを含む。別の動作は、前記支出取引の１つ以上の出力について、前記１つ以上の出力のそれぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の合計額が、前記第１のトークンの額と等しいか検証することを含む。前記トークンメカニクスサブコンポーネントは、検証ステップのいずれかが失敗した場合、実行の間に失敗するように構成されている。

以前のトークンの試みとは異なり、本発明に係る新たに発行されたトークンは、基礎となるデジタル資産トークン自体である。つまり、ネイティブトークン自体が新たな種類のトークンに変換される。これらの新たなトークンは、それらの発行時にそれ自体にエンコードされた特定の条件の下で、基礎となるデジタル資産に変換されない限り、ネイティブトークンとしてのそれらの通常の機能をもはや行わない。

トークンが支出されるか、割り当てられるか又はさもなくば送金されて、トークンとして機能できるようにするためには、成功すべき支出取引は、その次の出力に、支出されている以前の（ＵＴＸＯ＊と呼ばれる）取引出力と同じ形式のロッキングスクリプトを有してなければならない。つまり、支出されているトークン取引出力と同様に、支出取引は、正常に送信されるようにするために、新たなトークン出力の同じ定数コンポーネントを有するロッキングスクリプトを有する出力を含まなければならない。この定数部分は、トークンの有効期間中はその償還まで変更も省略もできない。

この定数部分はトークンのコード部分であり、そのさまざまな動作の中で、トークンの性質を変換するために、１）自己不変性、２）自身の省略の不可能性及び３）最も重要なことは、トークンの額の保存、つまり、それがトークンをロックし、それらの額（全体又は一部）が（合計の出力の額が合計入力の額よりも少ない場合）マイナー（miner）手数料として漏出するか又は（発行時に自身にエンコードされた特定のアドレスに償還されない限り）独自のスマートロッキングスクリプト形式出力以外に支出されないようにする。

簡単に言えば、ネイティブトークンを正規の使用を不可能にしながら、新たに定義されたものを施行して、その性質を変化させる。

これにより、基礎となるデジタル資産の各単一の単位が再定義された単一のトークンを表し、その正規の機能を停止するという効果を有する。ビットコインブロックチェーンの例を続けると、単一のＳａｔｏｓｈｉは単一のトークンとして再定義される。トークンの所有者は、ロッキングスクリプトが全く同じ定数コンポーネントを含まない限り、トークンを別のユーザに移転するできず、これにより、新たなトークンメカニクスが施行される。ロッキングスクリプトで変更できるのは、所有権の移転に関与する、つまり、現在の所有者が、そのような標準テンプレートに含まれるアドレスに従って、トークンの一部又は全てを次の所有者に移転するできるようにする（例えば、原資産のネイティブトークンと同じ方法で用いられる）標準テンプレートであり得る可変コンポーネントだけである。

別の言い方をすると、トークンを表すためにメタデータの添付に依拠する以前の試みとは異なり、このスキームによれば、本発明のトークンは、別個のエンティティとして機能するように再構成されている、基礎となるデジタル資産の単一の単位であり、異なるルール（それら自体にエンコードされている）によって動作する。

上述したように、トークンは、基礎となるデジタル資産に再変換できる。つまり、トークンがスクリプトの上記の定数部分にエンコードされた特定の条件、例えば、所定の償還アドレスへの移動を満たす場合に限り、ネイティブトークンとして再度用いることができる。つまり、ハードコードされたユーザ又は機関（すなわち、償還先を支配するエンティティ）のみが、トークンを正規の基礎となるデジタル資産の性質に戻し、元の機能を復元することができる。

本開示の実施形態の理解を支援し、そのような実施形態がどのように実施され得るかを示すために、ほんの一例として添付の図面を参照する。
図１は、例示のトークン取引を概略的に示す。 図２は、例示のトークンロッキングスクリプトを概略的に示す。 図３Ａ及び図３Ｂは、通常のトークン取引と、アトミックスワップトークン取引との違いを概略的に示す。 図４は、発行から償還までのトークンの例示のフローを概略的に示す。

本発明の実施形態は、ブロックチェーン取引の作成及び移転を伴う。当業者であれば、ブロックチェーン技術自体に精通しているが、実施形態自体を詳細に説明する前に、ブロックチェーンの簡単な概要を先ず提供する。

ブロックチェーンは分散データベース（又は台帳）の形態であり、これまでにブロックチェーンネットワークに移転された全ての有効な取引の記録として機能する。

ブロックチェーンネットワークでブロードキャストされる有効な取引は、マイナー（マイニングノードとも呼ばれる）によってブロック単位でブロックチェーンに記録される。ブロックチェーン取引は、デジタル資産の額の管理、すなわち所有権を移譲するために用いられる。例示のブロックチェーンはビットコインブロックチェーンであり、そのデジタル資産はビットコインと呼ばれる。多くの異なるブロックチェーンが存在し、本発明は特定の実施に限定されない。各取引は、とりわけ、少なくとも１つの入力及び少なくとも１つの出力を含む。入力は、前の取引からの未使用取引出力（ＵＴＸＯ）への参照を含む。取引は、未使用取引出力（ＵＴＸＯ）を入力として用い、その値を新たな出力に分配する。出力は、その出力の値をロックするロック条件を通常含み、ロックを解除するために、特定のデータ（例えば、一連の署名又は他の情報）を新たな次の取引の入力に提供する必要がある。出力は、台帳にデータ（例えば、テキスト、画像等）を書き込むためにも用いることもできる。取引の入力は、取引の少なくとも一部に署名するデジタル署名を通常含む。したがって、一連の取引は、その作成に至るまでデジタル資産の有効な交換の全履歴をマッピングする一連のデジタル署名を含む。

ブロックチェーンは、これまでに作成されたものの中の最初ブロックである「ジェネシスブロック」から始まる。ブロックチェーンの各ブロックは、ジェネシスブロックまで遡って前のブロックを参照する。つまり、ｎ番目のブロックは、ｎ－１番目のブロックを参照し、ｎ－１番目のブロックはｎ－２番目のブロックを参照し、ジェネシスブロックに戻る。

ブロックは、ブロックチェーン取引の順序付きリスト及びブロックヘッダを含む。ブロックヘッダは、ブロックチェーン取引の順序付きリストをマークルツリーにハッシュすることによって生成されるマークルルート、タイムスタンプ、現在のブロックがその上に構築される前のブロックへの参照及び他のマイナーがブロックを有効なものとして受け入れるために必要な「プルーフオブワーク」を検証する手段を含む。その検証手段は、各ブロックに固有のハッシュパズルへの答えである。ブロックチェーンネットワークのマイニングノードによって実行されるブロックチェーンプロトコルは、これらのマイナーがパズルを解こうとする前にそれらの候補ブロックを予め構築することを要求するハッシュアルゴリズムを用いる。正しい答えがないと、新たなブロックをネットワークに提出することができない。「マイニング」のプロセスは、基本的に、現在のブロックを「解決する」答えを見つけるために次のブロックになるために競うプロセスである。各ブロックのハッシュパズルを解くのが困難であるが、有効な解が見つかると、ネットワークの残りの部分でその解が正しいことを確認するのは非常に簡単である。任意のブロックには複数の有効な解があり、解決すべきブロックのために、解のうちの１つだけを見つければよい。

以下では、ブロックチェーンへの新たなブロックのマイニングを試みるプロセスを簡単に説明する。ブロックチェーン取引がマイニングノードに送信されると、先ず、ブロックチェーンネットワークのコンセンサスルールに従って検証される。取引が有効な場合、未確認取引のプールに追加される。このプールは「ｍｅｍｐｏｏｌ」と呼ばれることもある。ｍｅｍｐｏｏｌは、次のブロックにマイニングされる取引の一時的な保管場所として機能する。各マイニングノードは独自のｍｅｍｐｏｏｌを有し、特定の取引が複数のマイニングノードにブロードキャストされている場合は、２つ以上のｍｅｍｐｏｏｌに含められ得る。

マイナーは、次のブロックに含めることを意図する取引を取得し、それらをマークルツリー構造にハッシュし、結果として得られたマークルルートを候補ブロックヘッダに含める。次に、マイナーはこの候補ブロックヘッダをハッシュして、有効なプルーフオブワークを見つけることを試みる。マークルツリーは、ハッシュ値のツリー形式のデータ構造である。ブロックチェーンの文脈では、取引は、ツリーのリーフノードを形成するためにハッシュされる。リーフノードのペアが連結され、その後にハッシュされて、ツリーの上位層のノードを形成する。その層内のノードのペアは連結され、ハッシュされてツリーのさらに上位層のノードを形成する。このプロセスは、ルートノード又はマークルルートと呼ばれる１つのノードだけが残るまで繰り返される。

ハッシュ関数は、任意の長さのデータの文字列を、ハッシュ値又はハッシュダイジェストと呼ばれる固定長の一意の（事実上の０の衝突確率）値に変換する関数である。ハッシュは一方向の関数であり、そこから生成されたハッシュ値を見て入力データが何であるかを判断することは不可能であることを意味する。他方で、同じハッシュ関数を介して同じ入力データを実行し、同じハッシュを再現することは些細なことである。一部のブロックチェーンプロトコルはＳＨＡ－２５６ハッシュアルゴリズムを用い、一部のプロトコルはＳＨＡ－２５６ハッシュアルゴリズムを２回用いる。つまり、候補ブロックヘッダは同じハッシュアルゴリズムを２度通過する。

結果が、ターゲット値と呼ばれる別の値未満になるまで候補ブロックヘッダ（以下で説明するように他のデータと組み合わせて）をハッシングすることにより有効なプルーフオブワークが見つけられる。ターゲット値はブロックチェーンプロトコルによって自動的に調整されるため、ブロックチェーンネットワークが有効なプルーフオブワークを見つけるのに平均１０分かかる。

ハッシュ値を変更するためには、マイニングノードは候補ブロックヘッダに追加情報を追加しなければならない。通常、マイニングノードは２つの「ナンスフィールド」を用いてハッシュするべき値を変更し、結果として得られたハッシュ値を変更する。第１のナンスフィールドはブロックヘッダ自体に含まれ、第２のナンスフィールドは「コインベース取引」に含まれる。コインベース取引は、マイニングノードによって作成され、候補ブロックに含まれる取引である。各フィールドは、インクリメント可能なカウンタパラメータを含む。ハッシュ関数は、第１のナンスフィールドの全ての値を繰り返し、次に第２のナンスフィールドをインクリメント（又は変更）してから、第１のナンスフィールドの全ての順列を再度調べる。第２のナンスフィールドをインクリメントすることは、マークルツリーに含まれるコインベース取引のハッシュを変更するときに、マークルルートを再計算することを伴う。

マイニングノードは、ブロックの有効なプルーフオブワークハッシュ（つまり、ターゲット値よりも小さい値にハッシュする候補ブロックヘッダ）を見つけると、新たなブロックをブロックチェーンネットワークの残りの部分にブロードキャストする。ネットワーク上の他のノードは、そのブロック内の全ての取引が有効であり、ブロックにまだ含まれていない場合にのみ、この新たなブロックを受け入れる。全てのブロックにはタイムスタンプが付けられ、それに先行するブロックのハッシュを参照するため、一連のブロックが生成され、それ故に「ブロックチェーン」という用語になる。

ブロックチェーン取引をより詳細に説明する。以下の表は、一部のブロックチェーンプロトコルにしたがった典型的な取引の構造の概略図である。異なるブロックチェーンプロトコルは、異なる取引構造を用いり得ることが理解されよう。したがって、以下の説明は文脈についてのみ提供され、全ての実施形態を制限することを意図していない。

表に示すように、取引は一連のデータフィールドで構成される。その生の形態では、取引はシリアル化された一連のデータフィールドで構成され、通常は１６進数で表される。

取引は１つ以上の入力を有し、各入力は前の取引の出力を参照する。各入力は、同じ前の取引の異なる出力又は異なる取引からの出力又はそれらの組み合わせを参照し得る。各入力は、正しいデータが含まれる場合に参照された出力のロックを解除するアンロッキングスクリプト（「ＳｃｒｉｐｔＳｉｇ」と呼ばれることもある）を含む。以前の取引のロック解除された出力又はその出力に以前ロックされたデジタル資産の額が、現在の取引の出力によって用いられる（すなわち、割り当てられる）。デジタル資産のロック解除された額は、１回の出力によってその全体が使われ得るか又は現在の取引の２回以上の出力に分散され得る。

取引は１つ以上の出力も有し、入力によってロック解除されたデジタル資産の合計額を共に分配する。通常、出力値の合計は入力値の合計より小さく、その差は新たなブロックに取引を記録するマイニングノードに手数料として支払われる。出力は、支出可能（spendable）出力又は支出不能（unspendable）出力のいずれかであり得る。支出可能出力は、後の取引の入力によってロック解除するために満たす必要がある１つ以上の条件を定義するロッキングスクリプト（「ＳｃｒｉｐｔＰｕｂＫｅｙ」と呼ばれることもある）を含む。支出不能出力は、ロック解除可能なロッキングスクリプトを含まない。つまり、消費不能出力は、ロッキングスクリプトの実行を失敗させるロッキングスクリプトを含む。

本発明の実施形態は、第１の当事者（彼女を「アリス」と呼ぶ）が第２の当事者（彼を「ボブ」と呼ぶ）に１つ以上のトークンを送信することを可能にする。以下の説明の少なくとも一部は、第１の当事者であるアリスが第２の当事者であるボブにトークンを送ることに言及する。しかしながら、これは説明のみを目的としたものである。これらの実施形態は、第２の当事者であるボブが、第３の当事者、例えば商人にトークンを送信する場合にも該当する。加えて、トークンの発行者、すなわち、例えばアリスに最初にトークンを発行した当事者にも言及する。また、以下の説明のうちの少なくとも一部は「第１のトークン取引」に言及する。文脈で特に要求されない限り、第１のトークン取引はアリス、ボブ又はトークン発行者のいずれかによって作成され得る。

図４は、いくつかの当事者、例えば、トークン発行者、アリス、ボブ及び商人を含む例示のシステムを示す。「当事者」という用語は、ユーザ（例えば、アリス）を意味するものとして用いられ得るが、当事者は他の形態、例えば、企業又は他の形態の組織等のユーザの集合体の形態をとり得る。また、当事者が自律的なエンティティ、すなわち、１つ以上の条件に基づいて所定のアクションを行うエンティティであり得ることも排除しない。そのような自律的なエンティティは、当該技術分野において「エージェント」と呼ばれることがある。

図示していないが、各当事者はそれぞれのコンピュータ装置を操作する。各当事者のコンピュータ装置は、１つ以上のプロセッサ、例えば１つ以上のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ及び／又はＦＰＧＡを含むそれぞれの処理装置を含む。各当事者のコンピュータ装置は、さらにメモリ、すなわち、非一時的なコンピュータ読み取り可能媒体の形態のコンピュータ読み取り可能記憶装置をさらに含む。このメモリは、１つ以上のメモリ媒体、例えばハードディスク等の磁気媒体ＳＳＤ、フラッシュメモリ又はＥＥＰＲＯＭ等の電子媒体及び／又は光ディスクドライブ等の光学媒体を用いる１つ以上のメモリユニットを含み得る。各当事者のコンピュータ装置上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーションのそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書で特定の当事者に帰属するいかなる動作も、それぞれのコンピュータ装置の処理装置上で動作するソフトウェアを用いて行われ得ることが理解されよう。各当事者のコンピュータ装置は、少なくとも１つのユーザ端末、例えば、デスクトップ若しくはラップトップコンピュータ、タブレット、スマートフォン又はスマートウォッチ等のウェアラブル端末を含む。特定の当事者のコンピュータ装置は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソース等の１つ以上の他のネットワークリソースも含み得る。

クライアントアプリケーションは、先ず、任意の当事者のコンピュータ装置に対して、好適なコンピュータ読み取り可能媒体上で、例えばサーバからダウンロードされるか又はリムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピーディスク又はテープ、ＣＤ又はＤＶＤ－ＲＯＭ等の光ディスク又はリムーバブル光学ドライブ等のリムーバブル記憶装置上で提供される。

トークン発行者は、最初の受領者、例えばアリスにトークンを発行するパーティである。トークンは、トークン発行者によって生成された第１のトークン取引を用いてアリスに発行され得るか又はアリス自身が第１のトークン取引を生成し得る。例えば、トークン発行者及びアリスはアリスに発行されるトークンの数（及び他の適用可能な契約条件）について合意し、次いで、アリスは１つ以上のトークンを別の当事者、例えばボブに移転することにより、トークンを自身に効果的に発行できる。

アリス（又はトークン発行者）は、第１のトークン取引を生成する。トークン取引は、１つ以上の入力及び１つ以上の出力を含む。必要に応じて、入力のうちの１つは、トークン取引をブロックに記録するための手数料をマイニングノードに支払うための手数料支払として用いられ得る。取引手数料は常に必要ではないため、そのような手数料支払は必須ではない。全てのブロックチェーン取引と同様に、トークン取引は、以前の取引の出力のロックを解除するための入力を含む。第１のトークン取引の場合、前の取引の被参照出力は、少なくとも、トークンとして再構成される原資産の額を含まなければならい。図４に示すように、第１のトークンの額は１０００であるため、被参照出力は、原資産の少なくとも１０００単位の値を有してなければならない。この数は任意で選択されており、一般に任意の数が第１のトークンの額として用いられ得る。簡潔にするために、原資産の単位をＳａｔｏｓｈｉと呼ぶ。これはビットコインブロックチェーンの特定の単位であるが、これは全ての実施形態を限定するものではない。

第１のトークン取引は、第１のトークン出力を含む。第１のトークン出力は、第１のトークンの額（１０００Ｓａｔｏｓｈｉ）をロックする。つまり、第１のトークン出力は、第１のＳａｔｏｓｈｉの額を新たなに定義された同じ額のトークンにロックする第１のトークンロッキングスクリプトを含む。第１のトークンロッキングスクリプトは、可変コンポーネント及び定数コンポーネントを含む。別の言い方をすると、可変コンポーネントは第１のトークンロッキングスクリプトの１つの区画（すなわち、部分）であり、定数コンポーネントは第１のトークンロッキングスクリプトの別の区画（すなわち、部分）である。その名前が示すように、可変コンポーネントはトークン取引間で変化し得るのに対して、定数コンポーネントは同じままである。

可変コンポーネントは、トークンを別の当事者に移転することができるようにするトークンロッキングスクリプトの一部である。可変コンポーネントは、支払アドレスを含む（例えば、取り囲む）支払テンプレートを含む。支払アドレスは、受領当事者の公開鍵に基づき得る。例えば、支払アドレスはＰＫＨ（public key hash）アドレス、つまり、公開鍵のハッシュ（又はダブルハッシュ）であり得る。第１のトークン取引がトークン発行者によって生成された場合、支払アドレスはアリスにリンクされる。アリスが第１のトークン取引を生成した場合、支払アドレスはアリスによって選択される。アリスは、自身にリンクされた別のアドレスを選択し得るか又は別に当事者、例えばボブ又は商人にリンクされたアドレスを選択し得る。支払アドレスは、可変コンポーネントのサブコンポーネントとして扱われ得る。可変コンポーネントは、１つ以上の追加の定数サブコンポーネントを含み得る。例えば、可変コンポーネントは、Ｐ２ＰＫＨ（pay-to-public-key-hash）形式の出力を作成するための１つ以上の定数オペコードを含み得る。

定数コンポーネントは、定数コンポーネントの定数サブコンポーネントであるトークンメカニクスサブコンポーネント（以下では短縮して「トークンサブコンポーネント」いう）を含む。トークンサブコンポーネントは、基礎となるデジタル資産をトークンとして再利用する第１のトークンロッキングスクリプトの部分である。例えば、１０００Ｓａｔｏｓｈｉを１０００個のトークンにする。トークンサブコンポーネントは、支出取引の入力からデータを取得し、少なくとも２つの検証ステップを行うように構成されている。さらに、トークンサブコンポーネントは、検証が失敗した場合にトークンロッキングスクリプトの実行を失敗させるように設定されている。つまり、いずれかの検証ステップも失敗した場合、支出取引の入力からのアンロッキングスクリプトと共にトークンロッキングスクリプトの実行が失敗する。

トークンサブコンポーネントは、有効に実行するために、支出取引の入力（具体的には、入力のアンロッキングスクリプト）が特定のデータを含むことを必要とする。支出取引の入力は支出入力とも呼ばれる。とりわけ、支出入力のアンロッキングスクリプトは支出取引の少なくとも一部、つまり、アンロッキングスクリプト自体の他に支出取引データ（ある部分はそのままで、他の部分の結果をハッシュするだけ）を含まなければならない。以降、このデータを（そのハッシュがＥＣＤＳＡ検証式の入力として機能するため）ハッシュ原像と呼ばれるか又は単に原像と呼ばれる。原像は、支出取引及び使用済みのもののフィールドと、これらの取引フィールドに基づいて生成（ハッシュ）されたデータ項目を含む。他の実施形態では、支出取引の全てのデータフィールドは、支出入力のアンロッキングスクリプトに文字通り含まれる。

トークンサブコンポーネントは、実行された場合に、原像に加えて、１つ以上のデータペアを支出入力のアンロッキングスクリプトから取得するように構成されている。各データペアは、支出取引のロッキングスクリプトの支払いアドレスと、そのロッキングスクリプトによってロックされている基礎となるデジタル資産の対応する額とを少なくとも含む。一部の例では、支出取引は１つの出力、つまり１つのロッキングスクリプトのみを含む。その場合、トークンサブコンポーネントは１つのデータペアを取得する。他の例では、支出取引は複数の出力、すなわち複数のロッキングスクリプトを含む。その場合、トークンサブコンポーネントは複数のデータペアを取得する。

必要なデータは、支払入力のアンロッキングスクリプトをパースし、データペアを抽出することにより取得され得る。これには、所定の場所でアンロッキングスクリプトにデータペアを含める必要があり得る。さらに詳細な説明を以下で提供する。

１つ以上のデータペアを取得すると、トークンサブコンポーネントは、支出取引の出力が特定の形式であるか検証するように構成されている。支出取引の少なくとも１つの出力には、所定の標準支払テンプレートの一部である所定の支払アドレスのみ又はトークン出力の定数コンポーネント（すなわち、同一の定数コンポーネント）が後続する所定の標準支払テンプレートの一部である任意のアドレスのいずれかを含まなければならない。トークンサブコンポーネントは、支出取引の２つ以上の出力が、所定の標準支払いテンプレートに埋め込まれた任意の支払アドレスを含み、その後にトークン出力の定数コンポーネントが続くかを判定及び検証し得る。支出取引は、支出取引が所定の支払いアドレス（その対応する標準テンプレートのみ）又はトークン出力の定数コンポーネントが後続する任意の支払いアドレス（その対応する標準テンプレート）を含まない１つ以上の出力を含むことを検証し得る。

トークンサブコンポーネントは、一緒に、所定の支払いアドレス又は任意の支払いアドレスと、後続の定数コンポーネントのいずれかを含む支出取引の出力によってロックされた値の合計が、第１のトークンの額と等しい（すなわち、同じ）ことを検証するようにも構成されている。所定の支払アドレス又は定数コンポーネントのいずれかを含む支出取引の出力は、スマートトークン出力と呼ばれ得る。トークンサブコンポーネントは、スマートトークン出力によってロックされたトークンの合計額が第１のトークンの額と等しいかを検証するため、それらの元又は他の使用形式への逆流を防止する。

例えば、支出取引が単一のスマートトークン出力（支出取引の第１の出力）を含む場合を考えてみる。トークンサブコンポーネントは、支出取引の第１の出力が、特定の形式を取るか又は特定のデータを含む第１のロッキングスクリプトを有するか検証するように構成されている。具体的には、第１のロッキングスクリプトは、（支払テンプレートの一部としての）所定の支払アドレス又はトークンロッキングスクリプトの定数部分が後続する（支払テンプレートの一部として）任意の支払いアドレスのいずれかを含まなければならない。２つのうちの１つだけが必要であるが、両方欠落している場合、検証は失敗する。この検証プロセスは、トークンサブコンポーネントが支出入力のアンロッキングスクリプトから支出取引の第１のロッキングスクリプトを取得しているため実現可能である。したがって、トークンサブコンポーネントは、所定の支払アドレス又は定数コンポーネントのための第１のロッキングスクリプトを検索できる。

支出取引は、上述したように複数の出力を含み得る。追加出力の一部は、スマートトークン出力でもあり得るか又はそれらを異なる目的のために用いることができる。この場合、トークンサブコンポーネントは、支出取引の２つ以上の出力が、所定の支払アドレス又はトークン取引の定数コンポーネント、すなわち、トークンロッキングスクリプトの定数コンポーネントが後続する任意の支払アドレスのいずれかを含むかを検証するように構成されている。実施に応じて、トークンサブコンポーネントは、支出取引の複数の出力の全てが、所定の支払アドレス又は定数コンポーネントを含むか検証するように構成され得る。他の例では、トークンサブコンポーネントは、複数の出力の全てではなく一部が、所定の支払アドレス又は定数コンポーネントを含むか検証するように構成され得る。例えば、トークンサブコンポーネントは、支出取引の所定の数の出力、例えば、第１の２つの出力、すなわち、支出取引において論理的に１番目に現れる２つの出力が定数コンポーネントを含むか検証し得る。

支出取引が１つのスマートトークン出力を含む例では、トークンサブコンポーネントは、支出取引の第１のロッキングスクリプトによってロックされた基礎となるデジタル資産の第１の額が、第１のトークン額（すなわち１０００Ｓａｔｏｓｈｉ）と等しいかを検証するように構成されている。ここで、第１のロッキングスクリプトを有する第１の出力は、支出取引において論理的に１番目に現れる出力である。

支出取引が複数の出力、例えば、デジタル資産の第２の額をロックする第２のロッキングスクリプトを有する第２の出力を含む場合、トークンサブコンポーネントは、第１の額と第２の額との合計が、第１のトークンの額と等しいことか検証するように構成されている。ここで、第２の出力は、支出取引において論理的に２番目に現れる出力である。一般に、支出取引が所定の支払アドレス又は定数コンポーネントのいずれかを含む複数の出力を含む場合、トークンサブコンポーネントは、それぞれの額の合計が初期トークンの額と等しいかを検証する。

このプロセスは、支出取引の任意の数の出力に対して繰り返され得る。支出取引は、支出取引の出力の全てによってロックされる、第１のトークンの額よりも大きいデジタル資産の合計をもたらし得るデジタル資産の額をロックする出力を含むことが許可され得る。この場合、トークンサブコンポーネントは、合わせて、支出取引の所定の数のスマートトークン出力が、第１のトークンの額と等しいデジタル資産の額をロックしているか検証するように構成され、非スマートトークン出力によってロックされた額は考慮されない。非スマートトークン出力は手数料変更出力（fee change output）又はアトミックスワップ出力であり得る。例えば、トークン取引の第１の２つの出力によってロックされた合計額は、第１のトークンの額と等しくなければならないのに対して、第３の出力（例えば、手数料変更出力）は、追加の入力によって資金提供される追加の額をロックし得る。なお、第３の出力は説明を目的として用いている。手数料変更出力については以下でさらに説明する。今のところ、手数料変更出力（又は別の種類の「追加出力」）がトークン出力でない場合、つまりトークンロッキングスクリプトの定数コンポーネントを含まない場合にのみことが許可されることを言えば十分である。

トークンロッキングスクリプトの定数コンポーネントは、所定の支払いアドレスを含み得る。つまり、所定の支払アドレスが定数コンポーネントにハードコードされ得るため、支出取引の第１のロッキングスクリプトに含めなければならない。所定の支払アドレスは償還アドレス、トークン以外の何か、例えばＦＩＡＴ通貨トークンのために償還されるために、トークンの一部又は全てが移されるアドレスであり得る。

上述したように、支出取引の支出入力のアンロッキングスクリプトは原像を含み得る。原像は、下記の表におけるフィールドのうちの１つ、一部又は全てを含み得る。

なお、原像の特定の構造は説明を目的として含まれており、他の構造を用いてもよい。例えば、データフィールドのサイズは、本発明を実施するために用いられている特定のブロックチェーンによって異なり得る。

これらの例では、トークンサブコンポーネントは、第１のトークン取引のトークンロッキングスクリプト（すなわち、入力のｓｃｒｉｐｔＣｏｄｅ）及び初期トークン額（すなわち、入力によって使われた出力の値）を原像から抽出することによってそれらを取得するように構成され得る。ｓｃｒｉｐｔＣｏｄｅを除く原像の全てのデータフィールドのサイズが分かっているため、トークンサブコンポーネントは、所定の位置のデータをパースし抽出することにより、必要なフィールドを抽出できる。

表２に示すように、原像は支出取引の出力のハッシュ（ｈａｓｈＯｕｔｐｕｔｓ）を含み得る。これは各出力のハッシュ、つまりロッキングスクリプトによってロックされた値及びロッキングスクリプト自体である。そのため、支出取引が１つの出力を含む場合、ｈａｓｈＯｕｔｐｕｔｓは１つのロッキングスクリプトと連結された１つの値のハッシュを含む。支出取引が２つの出力を含む場合、各値ロッキングスクリプトのペアが連結され、ハッシュされてｈａｓｈＯｕｔｐｕｔｓを形成する。トークンサブコンポーネントは、例えば、特定の位置でデータをパース、抽出することにより、原像からｈａｓｈＯｕｔｐｕｔｓを抽出し得る。

支出取引のアンロッキングスクリプトは、上述したように１つ以上のデータペアを含む。各データペアは値及びロッキングスクリプトを含むことを思い出されたい。トークンサブコンポーネントは、独自のバージョンのｈａｓｈＯｕｔｐｕｔｓを生成、つまり、１つ以上のデータペアのハッシュを生成し、生成されたハッシュは原像から抽出されたハッシュ（すなわち、ｈａｓｈＯｕｔｐｕｔｓ）と等しいか検証するように構成され得る。これは、支出ユーザ、例えば、アリス又はボブが支出取引のアンロッキングスクリプトに正しいデータペアを含めたかを検証するためになされ得る。

一部の例では、トークンサブコンポーネントは、支出取引のアンロッキングスクリプトに含まれる原像が正しく生成されたか、つまり、原像のデータフィールドが支出取引の実際のデータフィールドに対応しているかを検証するように構成され得る。システムのユーザが支出取引を正しく生成できることを信頼できないと考えられる場合に必要である。これを行うために、トークンサブコンポーネントは、その独自のバージョンの支出取引の予想される原像、例えば、表２のデータフィールドの全てを含むものを生成する。そして、トークンサブコンポーネントは、支出取引のアンロッキングスクリプトから抽出された原像が、トークンサブコンポーネントによって生成された原像と合致するかを検証できる。

支出取引のアンロッキングスクリプトに含まれる原像が正しいかを検証するための１つの方法は、当該技術分野でＯＰ＿ＰＵＳＨ＿ＴＸとして知られている擬似オペコードを用いることである。しかしながら、同等のオペコード、より一般的には、ＯＰ＿ＰＵＳＨ＿ＴＸと同等の機能を行う任意の同等のコードを代わりに用いてもよい。

一般に、トークンサブコンポーネントは、アンロッキングスクリプトからの原像及び秘密鍵を用いてデジタル署名（例えば、ＥＣＤＳＡ署名）を生成するように構成され得る。秘密鍵は、支出取引のアンロッキングスクリプトに含まれている。次に、トークンサブコンポーネントは、生成された原像（すなわち、トークンサブコンポーネントによって生成された原像）及び秘密鍵に対応する公開鍵に対して検証された場合にデジタル署名が有効な署名であるかを検証する。公開鍵は、支出取引のアンロッキングスクリプトにも含まれている。デジタル署名は、２つの原像が完全に一致する場合にのみ有効となる。使用される秘密鍵は、ブロックチェーンに記録されることによって公開されるため、「ダミー」
の秘密鍵、つまり、公開された場合に他のデータ又はブロックチェーン取引の安全性を損わないものを用いるべきである。しかしながら、一般的には、任意の秘密鍵、例えば、任意のランダムキーを用いることができる。この署名チェックは、署名を検証するためにＯＰ＿ＣＨＥＣＫＳＩＧオペコードを利用することにより行うことができる。ＯＰ＿ＣＨＥＣＫＳＩＧは、署名が現在の取引、つまりこの場合の支出取引のためのものである場合にのみ成功する（つまり、正常に実行される）オペコードである。

支出取引の出力に戻って、トークンサブコンポーネントは、支出取引の出力（具体的にはそれらのそれぞれのロッキングスクリプト）が所定の種類、つまり形式のそれぞれの支払アドレスを含むか検証するように構成され得る。それぞれの支払アドレスは、トークン取引の可変コンポーネントに含まれる支払アドレスと同じ種類でなければならないことが好ましい。支払アドレスはＰＫＨアドレスでなければならないことがより好ましい。これは、支払アドレス自体のみに基づいて検証され得るか又は支払アドレスと、１つ以上の追加データ項目、例えば、支払アドレスのいずれかの側の１つ以上のオペコード又は他のデータに基づいて検証され得る。例えば、Ｐ２ＰＫＨ出力は、出力においてチェックされ得る特定の追加データを含む。

定数コンポーネントのトークンサブコンポーネントについて説明してきた。定数コンポーネントは、定数データサブコンポーネント（以下では短縮して「データサブコンポーネント」という）を含み得る。一般に、データサブコンポーネントは、各トークン出力に格納されるべき任意のデータを含み得る。例えば、データサブコンポーネントは、トークンプロトコル識別子、例えば、トークンが特定のプロトコルのものであること示す、例えば、トークンがＦＩＡＴ通貨を表すフラグを含む。それに加えて又は代替的に、データサブコンポーネントは、ブロックチェーンに記録される取引（「トークン発行取引」と呼ばれる）の取引識別子（ＴｘＩＤ）を含み得る。同様に、トークン発行取引には一般に任意のデータ、例えばトークン発行者によって発行されたトークン発行契約及び／又は初期トークン額を含み得る。データサブコンポーネントは、ＯＰ＿ＲＥＴＵＲＮオペコード又は同等の機能を行うコードの後に含められ得る。

上記の説明は、主に初期トークン取引及び支出取引に関連する。以下では、それ自体がトークン取引である支出取引を詳細に説明する。支出取引は、「支出取引」という用語を、第１のトークン取引の出力を参照する後の取引のためにとっておけるように、「第１のトークン取引」と呼ぶ。

図１を参照ながら第１のトークン取引を説明する。図１に示すように、第１のトークン取引１００は、取引識別子（Ｔｏｋｅｎ ＴｘＩＤ）、１つ以上の入力１０４及び１つ以上の出力１０６を含む。各入力１０４は入力値１０８及びアンロッキングスクリプト１１０を含む。なお、図１は概略図である。入力１０４自体は入力値１０８を含んでいない。むしろ、入力１０４は、前の出力の未使用取引出力（ＵＴＸＯ）へのポインタ（例えば、ＴＸＩＤ及びＶＯＵＴ）を含み、該前の出力は、入力値１０８と呼ばれる値１０８をロックしている。しかしながら、それぞれのアンロッキングスクリプト１１０によってロック解除された値１０８を、説明を目的として示す。各出力１０６は、出力値１１２及びロッキングスクリプト１１４を含む。

第１のトークン取引１００の出力１０６については、支出取引を参照して既に上記で説明してきたため、最初に説明する。トークン取引１００は、第１のトークン出力（「償還／トークン出力」）を含む。第１のトークン出力を図２に示す。図２に示すように、また、上記で既に説明したように、第１のトークン出力２００は、可変コンポーネント２０２及び定数コンポーネント２０４を含む。定数コンポーネント２０４は、トークンメカニクスサブコンポーネント２０６と、この例では定数データサブコンポーネント２０８とを含む。

可変コンポーネント２０２には、第１のトークンの額（例えば、７００トークン）が割り当てられている当事者のそれぞれの支払アドレスを含む。トークンサブコンポーネント２０６は、上述した検証ステップの一部又は全てを行うように構成されている。例えば、トークンサブコンポーネント２０６は、支出取引の所定の数（例えば、１又２）の出力によってロックされるべきデジタル資産の総額が、第１のトークンの額（７００トークン）と等しいかを検証するように構成されている。第１のトークン出力２００のトークンサブコンポーネント２０６は、第１のトークン出力２００のロック解除を試みる後の支出取引の入力が、償還支払アドレスを含む通常の支払テンプレート又は可変コンポーネント２０２及び定数コンポーネント２０４を含む第１のトークン出力２００のフォーマット全体のいずれを含むかも検証するようにも設定されている。一般に、トークンサブコンポーネント２０６は、上述の検証技術のいずれかを行うように構成され得る。

第１のトークン取引１００は、第２のトークン出力も含み得る。第２のトークン出力は、それぞれの可変コンポーネント及びそれぞれの定数コンポーネントも含む。第２のトークン出力の可変コンポーネントは、第１のトークン出力２００の可変コンポーネント２０２と比べて異なる支払アドレスを含み得る。第２のトークン出力のトークンサブコンポーネントは、検証が異なる支出取引、つまり、第２のトークン出力を参照する入力を有する取引である点を除いて、第１のトークン出力２００のトークンサブコンポーネント２０６と同じ検証ステップを行うように構成されている。つまり、第１のトークン取引１００は２つ以上の出力を有し、それらの出力のそれぞれは異なる支出取引により使用（ロック解除）できる。例えば、第２のトークン出力のトークンサブコンポーネントは、支出取引の所定の数（例えば、１又２）の出力によってロックされたデジタル資産の総額が第２のトークンの額（３００）と等しいか検証するように構成されている。

第１のトークン取引１００は、それぞれのトークンの額の合計が（取引の入力のＴＸＩＤフィールドによって参照される）第１のトークン出力でロックされた額（１０００トークン）と厳密に等しい限り、使用すること試みる任意の数のトークン出力を含み得る。

第１のトークン取引１００は手数料変更出力を含み得る。この出力により、手数料変更（Ｘ－δ）を手数料変更支払アドレスに戻すことができる。図１の例では、取引手数料（δ）を支払うのに入力値（Ｘ）を有する手数料支払入力が用いられる。

それに加えて又は代替的に、第１のトークン取引１００はアトミックスワップ出力を含み得る。アトミックスワップ出力については以下で説明する。

図１の例では、第１のトークン取引１００はトークン入力を含む。トークン入力は、上記で詳述した支出入力と同等である。より具体的には、トークン入力は、前のトークン取引、例えば初期トークン取引のトークン出力を参照する。この例では、被参照トークン出力は１０００トークンをロックする。トークン入力は、第１のトークン取引２００の各出力１０６のためのそれぞれのデータペアを含む、第１のトークン取引のそれ以外の全てを含む。つまり、この例では、トークン入力は３つの値（７００、３００、Ｘ－δ）と、対応する３つの支払アドレス（トークンロッキングスクリプト（「償還／トークン出力」、「トークン出力（分割）」、「手数料変更/アトミックスワップ」）のそれぞれから１つずつ）を含む。値１１２及び支払アドレスは、第１のトークンの額（７００）の後に第１のトークン出力ロッキングスクリプトからの支払アドレスが続き、その後に第２のトークンの額（３００）、第２の出力ロッキングスクリプトからの対応する支払アドレス等が続くように対にされ得る。トークン入力は、被参照トークン出力をロック解除するための署名、すなわち、被参照トークン出力の可変コンポーネントに含まれる支払アドレスに対応する署名も含む。アリスがトークンを移転する場合、アリスの署名が支出取引の入力に含まれる。一部の例では、単なる支払アドレスの代わりに、ロッキングスクリプト全体を入力に含むことができる（すなわち、データペアの一部として）。

図１に示すように、第１のトークン取引１００は手数料支払入力を含む。手数料支払入力は、個別の前の通常の非トークン取引出力の出力を参照し、第１のトークン取引１００をブロックに含めるためにマイニングノードに支払われる手数料を含む。手数料支払入力は、参照する出力の要件に応じて、少なくとも１つのデジタル署名を含む。一部の例では、デジタル署名は、第１のトークン取引１００のトークン入力によって参照されるトークン出力の所有者によって生成される。例えば、アリスが１０００トークンのうちの７００をボブに、３００のトークンを商人に送信する場合、アリスはその取引に資金を提供する。その場合、手数料支払入力にアリスの署名が含まれる。しかしながら、異なる当事者、例えばボブが、ボブにロックされたＵＴＸＯをロック解除することにより、取引に資金を提供し得ることは排除されない。この場合、ボブの署名が手数料支払入力に含まれる。アトミックスワップ出力は前述のとおりで、マイナーの手数料支払入力は（トークンのための）支払の追加タスクを有する。この例では、ボブは、手数料／「トークン購入」入力に自身の署名を含めることにより取引に資金を提供し、「手数料変更」／「アトミックスワップ」出力がボブにロックされる。つまり、「手数料変更」／「アトミックスワップ」出力は、ボブにリンクされた支払アドレス、例えばボブが所有する公開鍵のハッシュを含む。

アトミックスワップを強制するために、アリスは手数料／「トークン購入」支払入力を除く完全な取引を作成する。次に、ボブは手数料／「トークン購入」支払入力を作成し追加する。これを行う１つの方法は、アリスが自身の入力（すなわち、トークン入力）と、２つの対応する出力とを、別の当事者に入力を追加することを可能にｓｉｇｈａｓｈフラグ（例えば、ＡＬＬ｜ＡＮＹＯＮＥＣＡＮＰＡＹ）で署名することである。次に、ボブは別のｓｉｇｈａｓｈフラグ（例えば、ＡＬＬ－取引全体を確定し、それ以上の追加を許可しない）を有する入力を追加する。

図３Ａ及び図３Ｂは、アトミックスワップの概念をより詳細に示す。実線の矢印は必須の入力及び出力を示し、破線の矢印は任意の入力及び出力を示す。取引への入力は図の左側に示し、取引の出力は右側に示す。図３Ａは、図１と同様の取引を概略的に示す。この例示のトークン取引は、前のトークン取引のトークン出力をロック解除するアリスによって生成されたトークン入力と共に、取引手数料（取引をブロックに記録するためにマイニングノードによって取られる手数料）の資金調達のための手数料支払入力を含む。トークン取引は、２００のようにトークン形式に含まれているボブのアドレスにロックされたボブに送信されるトークン出力と共に、通常の支払形式（手数料入力支払と取引手数料との差であると出力で特定された変更）で自身のアドレスにロックされたアリスに変更を支払う手数料変更出力も含む。

図３Ｂは例示のアトミックスワップ取引を示す。ボブのトークン出力は、図３Ａと同じ方法で生成される。アリスは、前のトークン取引のトークン出力をロック解除するためにトークン入力を再度生成するが、今回彼女は取引を「ＡＬＬ／ＡＮＹＯＮＥＣＡＮＰＡＹ」のｓｉｇｈａｓｈフラグで署名する。これは、アリスの署名がこの１つの入力、つまり、ｓｉｇｈａｓｈフラグで署名された入力支出トークン出力以外の全ての出力に署名することを意味する。残りの入力は除外される。このｓｉｇｈａｓｈフラグは、誰でも他の入力を追加又は削除できるようにするため、誰でも取引に資金を出すことができるが、それらの宛先及び額を変更することはできない。これにより、ボブは自分の支払入力のみを追加することができ、これはマイナーの手数料も含む。ボブは署名を含み、「ＡＬＬ」のｓｉｇｈａｓｈフラグでサインする。これは、ボブの署名が全ての入力及び出力にサインし、全ての要素をさらなる可能性のある変更から保護することを意味する。この例では、第２の出力は、ボブの入力によって追加されたこれからアリスに支払われる。これはアトミックスワップを強制する効果があるため、ボブがトークンの代金をアリスに支払った場合に限り、トークンがボブに送信される。ボブが取引のいずれの要素にも満足しない場合、彼は単に署名を提供しないため、トークンはボブのアドレスに移動せず、アリスは支払いを受けない。同様に、ボブはアリスによって作成及び署名された入力及び出力を変更できないため、アリスはアリスによって設定された支払い条件が満たされた場合にのみボブがトークンを受け取ることができることが保証される。

図４は、発行から償還までのトークンの例示の流れを示す。流れは一般的に上から下に向う。任意の第１のステップとして、トークン発行者と初期受領者であるアリスとの間で法的契約が作成される。契約は、トークンがどのように償還されるかを含むトークンの取引条件と、初期のトークンの額（例えば、１０００）を規定し得る。その後、トークン発行者は第１のトークン取引を作成し、トークンをアリスに送信し得る。あるいは、アリスが第１のトークン取引を作成し、そのうちの一部又は全部を別のユーザ、例えばボブに又はアリス自身に送信し得る。図４では、アリスがトークンの全てをボブに送信する。つまり、トークンの全ては、ボブの支払アドレスに送信される１つのトークン出力に割り当てられる。次に、ボブは２つのトークン出力を有するトークン取引を作成する。第１のトークン出力は、商人の支払アドレスに３００個のトークンを送信する。第２のトークン出力は、ボブの別の支払アドレスであり得るボブの支払アドレスに７００個のトークンを送信する。次に、商人は３００個のトークンを、つまり、トークンを償還支払アドレスに送信することにより償還する。次に、ボブは最初に５００個のトークンを償還し、残りの２００個のトークンをボブにリンクされた別の支払アドレスに送信する。最後に、ボブは２００個のトークンを償還する。なお、各取引において、受け取るトークンの額と送信されるトークンの額は一致する。

上記で本発明の実施形態を一般的に説明してきた。次に、本発明の特定の実施を説明する。この特定の例は、フィアット通貨を表すトークンの観点から主に説明する。すなわち、トークンは法定ペッグされたトークンである。しかしながら、これは本発明の多くの使用例の１つにすぎない。さらに、この例はビットコインブロックチェーンを用いて実施されることを意図している。しかしながら、一般的には任意のアウトプットベース（例えば、ＵＴＸＯベース）のブロックチェーンを用いてもよく、ビットコインブロックチェーンはその中の１つの特定の例である。

この例によれば、トークンはビットコイン、より具体的にはＳａｔｏｓｈｉ又はＳａｔｏｓｈｉ単位と呼ばれるビットコインの基本単位を用いて表される。トークン出力は、単一のトークン（例えば、イベント、映画館のチケット、バスのチケット等のユーティリティトークン）を表す単一のＳａｔｏｓｈｉを含み得る。そのため、このトークンは分けることができず、ライフサイクルの間は分割できない。又は、トークン出力は、複数のトークンのエンベロープ（例えば、米ドルにペッグされたトークンは１トークンが１米ドルセントを表す）を表す複数のＳａｔｏｓｈｉを含み得る。

トークン出力は可変部分及び定数部分を含む。可変部分は、ＥＣＤＳＡの使用を通じてビットコイン（すなわち、Ｓａｔｏｓｈｉ）の所有を渡す通常のビットコイン支払テンプレートと同じである。定数部分は、トークンの有効期間を通して変更も省略もできない。

１Ｓａｔｏｓｈｉ自体よりも安いか又は高い何かを表すことができるという事実に関わらず、各Ｓａｔｏｓｈｉはトークンを表し、通常の機能を停止する。アリスは、この厳密なテンプレートを自身の次のトークン取引におけるロッキングスクリプトとして保持しない限り、トークンをボブに移転することができない。可変部分の所有アドレスしか変更できない。

なお、これは、メタデータを用いて出力をトークン出力として解釈する以前のトークンの試みと同じではない。本発明は、ビットコインとしての通常の使用に関するＳａｔｏｓｈｉのメカニズムを根本的に変更する。

可変部分は、意図的にトークンロッキングスクリプトの一番最初にあり、通常支払テンプレート、例えばＰ２ＰＫＨテンプレートにすぎない。これは、既存のブロックチェーンクライアントアプリケーション及びブラウザに最大の互換性を提供し、（テンプレートにラップされた）
支払アドレスを、現在の方法で検索及び特定できるようにする。

トークンメカニクス部分は少なくとも３つの条件を強制する。第１に、トークンの使用は、新たな所有アドレスを除いて、次のＵＴＸＯが使用されたＵＴＸＯとまったく同じロッキングスクリプトを有する場合にのみ可能である。第２に、通常のビットコインロッキングスクリプトテンプレート（例えば、Ｐ２ＰＫＨ、Ｐ２ＰＫ等）による取引による支出は、所定の償還支払アドレスを含むＰ２ＰＫＨでない限り失敗する。所定の償還支払アドレスは、アリスに発行される契約に含まれ、トークンロッキングスクリプトにハードコードされている。トークン発行者が自身にリンクされたアドレスに償還アドレスを設定した場合、これは、発行者のみが資産を表すＳａｔｏｓｈｉを、例えば米ドル、金等の表された資産を解放することにより、元の通常のＳａｔｏｓｈｉとしての使用に戻すことができることを意味する。これは、トークンを承認不要なもの（permissionless）にする。第３に、トークンを動かす場合、現在の未使用トークン出力（ＵＴＸＯ）のトークン出力におけるＳａｔｏｓｈｉの額は、支出取引（例えば、償還又は次のトークン取引）のトークン出力のＳａｔｏｓｈｉの額と厳密に同じであるか又は２つ以上のトークンのセットに分割（その合計額はＵＴＸＯの元の額と等しくなければならない）されなければならない。例えば、トークンは支出取引の２つの出力に分割でき、２つの出力のロッキングスクリプトは、使用されているＵＴＸＯのロッキングスクリプトと（可変部分のアドレスを除いて）同一である。

これらのステートフルな取引で推し進められる状態は、ホップ毎に更新される所有アドレスと（トークンのエンベロープの場合のみ）トークンの額であり、分割によって減少し得る。

定数データ部分には２つのフィールドを有する。１つのフィールドはトークンプロトコル識別子、例えば、フィアットペッグされたトークンのトークンプロトコルフラグを含む。識別子は、トークンの種類を指定するために用いられる。第２のフィールドは、特別な取引へのポインタ（ＴｘＩＤ）であり、そこには、ａ）トークンの属性及び発行に関連する全ての法的規約、条件、ライセンス及び任意の他の必要な情報を伴う（例えば、発行主体とクライアントとの間での）初期発行契約と、ｂ）後続の取引（発行取引になる）でトークンに変換されるべき所定の厳密なＳａｔｏｓｈｉの残高とを運ぶ
定数データフィールドは単なるデータ添付としてＯＰ＿ＲＥＴＵＲＮオペコードの後ろに置かれて、スクリプト評価の間にスクリプトコードの一部としての実行の試みが回避される。つまり、定数データは、ＯＰ＿ＲＥＴＵＲＮ取引で検索を行うアプリ及びブラウザの最大限の互換性のために、ロッキングスクリプトの最後で且つＯＰ＿ＲＥＴＵＲＮオペコードの直後に含まれることが好ましい。

取引構造自体に関して、トークン取引の出力は、ｉ）償還のための通常出力、ｉｉ）トークン出力又はｉｉｉ）手数料変更、アトミックスワップ等に用いられる通常出力の３つの種類のうちの１つを取り得る。

一例として、アリスは、法的に認可されたエンティティに、自身に代わって１０００個のトークンの発行を依頼し、エンティティに自身の支払アドレスを提供し得る。エンティティは、要求された額（この場合は１０００）に対応する、予め割り当てられた額のＳａｔｏｓｈｉを含む支出可能取引の形式で契約を作成する。契約の条項、条件及びライセンスには、アリスが必要とするアクション（例えば、エンティティへの相当額のフィアット通貨の送金）が記載されており、アリスが署名を追加できるように、ＡＬＬ｜ＡＮＹＯＮＥＣＡＮＰＡＹフラグ等でエンティティによって署名されている。アリスが契約に署名し、ブロックチェーンに公開し、記載されている必要なアクション（フィアット額の送金）を行うと、エンティティはアリスに代わってトークンを彼女の支払アドレスに発行する。アリスは、トークンを一度に又はトークンの一部を使用／支出／送金できる。後続の所有者は任意でトークンを償還できるため、トークンは承認不要となる。

トークン出力の定数部分に戻って、定数部分は大まかに２つの部分を含む。第１の部分はＯＰ＿ＰＵＳＨ＿ＴＸを実施し、スクリプト実行内の現在の取引のフィールドへのアクセスに関与する。第２の部分はトークンロジックである。

ｓｉｇｈａｓｈ原像については上記で説明してきた。ＯＰ＿ＰＵＳＨ＿ＴＸは、現在の取引に対応する原像のＥＣＤＳＡ署名、つまり、実行されたスクリプト内でアクセスされるためにアンロッキングスクリプトに押し込まれたトークン出力のロック解除を行う支出取引を行う。ＯＰ＿ＰＵＳＨ＿ＴＸは、署名の検証のためにＯＰ＿ＣＨＥＣＫＳＩＧを最終的に呼び出す。この内部ＥＣＤＳＡ署名は、公にアクセス可能な任意の秘密鍵対（１つの一時的な対、１つの定数対）を用いて行われるため、トークン所有リレーに用いられるものとは無関係であるべきである。また、この場合のＯＰ＿ＣＨＥＣＫＳＩＧは、呼び出されると、実際の以前及び現在の取引フィールドからＥＣＤＳＡ検証のための独自の原像を構築するため、バリデータとして機能する。そのため、実際のフィールドが、アンロッキングスクリプトに押し込まれたものと同一であること（又はないこと）に応じて失敗又は成功する。

トークンロジックは、ビットコインのＳａｔｏｓｈｉをトークンに変換する。これを行うには、コードはＳａｔｏｓｈｉの支出を制御するために、以前の取引のＳａｔｏｓｈｉの値（額）（すなわち、トークンを含む未支出の出力）及び現在の取引のＳａｔｏｓｈｉの値（すなわち、支出取引）へのアクセスを必要とする。コードは、出力ロッキングスクリプトの形式を制御するために、以前及び現在のロッキングスクリプトにアクセスする必要もある。

現在の（支出）取引のアンロッキングスクリプトにプッシュされた原像が、実際の現在の取引の原像と同じであることが検証されると、この入力によって支出される出力のｓｃｒｉｐｔＣｏｄｅ及びｖａｌｕｅ並びにｈａｓｈＯｕｔｐｕｔｓを含む関連フィールドの全てを抽出するためにパースされる。以前のＵＴＸＯ（すなわち、支出されたもの）の値（すなわち、額）及びロッキングスクリプトは原像にそのまま提供されるものの、（それらの新たな値と組み合わされた）新たなに作成された出力のロッキングスクリプトのハッシュの結果のみが利用可能である。そのため、これらの新たな出力のロッキングスクリプトと、それに対応する値とは、呼び出された場合にＯＰ＿ＣＨＥＣＫＳＩＧが構築するものと同一であることが以前に証明された原像のｈａｓｈＯｕｔｐｕｔｓフィールドに対して次に検証される支出取引のアンロッキングスクリプト内の原像の隣に置かれるべきである。

取引の以前及び次の出力についての全てのロッキングスクリプト及びそれらの値（すなわち、額）の全てが実行中のコードによってアクセス可能になると、トークン規則を施行できる。

以下の例示の規則が施行され得る。特定のユースケースに応じて、他の追加の又は代替的な規則が施行されることが理解されよう。この例では、以下が許可される。
１．償還機能：トークンの性質をＳａｔｏｓｈｉの固有なもの、すなわち基礎となるデジタル資産に戻し得るハードコードされたアドレスを定義するために用いられる。
２．トークンの額を最大で２つの可能な出力に分割すること。
３．追加の入力によりマイナー手数料支払から変更を受信するためのＰ２ＰＫＨ形式を有するか又は「アトミックスワップ」の場合にトークンの売り手によりお金を受け取るための第３の任意の出力。

より具体的に述べると、規則は以下のとおりである。
１．トークン取引の第１の出力は、
ａ）償還：必須のハードコードされた償還アドレスを含む標準のＰ２ＰＫＨテンプレート、又は
ｂ）トークンリレー：以前の出力形式と同一のスマートトークンロッキングスクリプト
ためのみに用いられる。
２．第２の出力は、トークン分割の場合のための任意のものであり、故にスマートトークンタイプのみである。加えて、
ａ）存在する場合、その出力の額と第１の出力の額との合計は、支出されているＵＴＸＯにおける額と等しくなければならない。
ｂ）それ以外の場合、第１の出力の額は、支出されているＵＴＸＯにおける額と等しくなければならない。
３．第３の出力は、標準のＰ２ＰＫＨテンプレートのみとなる（アドレスは任意）。存在する場合、（すなわち、追加の入力を用いてなされる）トークン操作の支払の変更のために用いられる。

なお、Ｐ２ＰＫＨテンプレートは取引出力スクリプトであり、ＶａｒＩｎｔ（次のスクリプトの長さを指定）０ｘ１９が先行するアンロッキングスクリプトに押し込まれた場合、その２５バイトの長さにより、１６進数形式では「０ｘ７６ａ９１４＋ＰＫＨ＋０ｘ８８ａｃ」になる。ＰＫＨは公開鍵ハッシュアドレスである。

これらの規則を施行するための例示の擬似コードを提供する。

下記のコードは、ビットコインスクリプト言語での実際の例示の実施を示す。この実施では、上記の擬似コード関数定義と同じ順序（左から右に）でアンロッキングスクリプトパラメータが用いられた。これは、左端がスタックに先ずプッシュされたことを意味する。ハードコードされた償還関数アドレスは、ロッキングスクリプトの「定数コード」部分の第１のフィールドになるように置かれるため、（ＥＣＤＳＡ署名検証を行う可変部分を考慮しない場合）アンロッキングスクリプトデータの直後にスタックにプッシュされる。

なお、このスクリプトの実施は、（ビットコインにおける現在の手数料支払はＴＸサイズのみに依存するため）時間ではなくスペースに最適化されている。

結論
上記の実施形態は例示のために説明してきたことが理解されよう。

より一般的には、本明細書に開示の一態様によれば、ブロックチェーン取引を用いてデジタルトークンを送信するコンピュータ実施方法が提供され、各トークンはブロックチェーンの基礎となるデジタル資産の固有の単位の単一の単位によって表され、当該方法は、第１のトークン取引を生成することと、前記第１のトークン取引をブロックチェーンネットワークに送信することと、を含み、前記第１のトークン取引は第１のトークン出力を含み、該第１のトークン出力は第１のトークンロッキングスクリプト及び第１のトークンの額を含み、該第１のトークンロッキングスクリプトは可変コンポーネント及び定数コンポーネントを含み、該可変コンポーネントは、支払テンプレートに埋め込まれた第１の支払アドレスを含み、該定数コンポーネントはトークンメカニクスサブコンポーネントを含み、該トークンメカニクスサブコンポーネントは、支出取引の入力スクリプトであって、該入力スクリプトは、該支出取引の自身を除く全てに加えて、支出されている以前の取引出力においてロックされている額及びそれぞれのロッキングスクリプトを含む入力スクリプトと共に実行された場合、前記支出取引の入力スクリプトから１つ以上のデータ対を取得することであって、各データ対は、ｉ）前記支出取引の出力のそれぞれのロッキングスクリプトに含まれる少なくともそれぞれの支払アドレスと、ｉｉ）その出力のそれぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の対応する額とを含む、ことと、前記支出取引の１つ以上の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含むそれぞれのロッキングスクリプトを含むか検証することと、前記支出取引の１つ以上の出力について、前記１つ以上の出力のそれぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の合計額が、前記第１のトークンの額と等しいか検証することと、を行うように構成され、前記トークンメカニクスサブコンポーネントは、検証ステップのいずれかが失敗した場合、実行の間に失敗するように構成されている。

支出取引は、第１のロッキングスクリプト形式を含む少なくとも１つの出力を含む。支出取引は２つ以上の出力、例えば、それぞれのロッキングスクリプト形式を有する第２の出力及び第３の出力を含み得る。取引が成功するためには、これらの支出取引の新たな出力の全てのロッキングスクリプトが、支出されている以前の取引の出力と同じスマートトークン形式を有するか又は所定の償還アドレスを有する標準支払テンプレートを有する必要がある。唯一の例外は任意の出力（例えば、最後の出力）であり、そのロッキングスクリプトは、例えば、必要に応じてマイナーの手数料支払からの変更又はアトミックスワップの支払受領のために用いられる任意のアドレスを有する標準支払テンプレートでなければならない。支出取引の入力は、各出力のためのデータ対及び取引全体のｓｉｇｈａｓｈ原像を含むべきであり、そのハッシュの結果はＥＣＤＳＡの検証式の入力としての役割を果たす。トークンメカニクスサブコンポーネントは、この仮定に基づいて動作するように構成されている。仮定が満たされない場合、トークンメカニクスサブコンポーネントの実行は失敗し、如何なるトークンの操作が不可能になる。

これは、支出取引が、支出が試みられる出力の第１のトークンロッキングスクリプトの定数コンポーネントを含まない追加の任意のマイナー手数料変更出力を有する場合にも当てはまる。そのような任意の出力でロックされたネイティブトークンは、ある取引から別の取引を介して新たに定義されたトークンの保存額の一部ではない。

支出取引の一部は生の形式で入力スクリプトに含まれるのに対して、他の部分はそれらのハッシュの結果として含まれる。

各支払アドレスは、支払テンプレートに埋め込まれ得る。

実施形態では、前記支出取引は、第１のロッキングスクリプトを含む第１の出力と、第２のロッキングスクリプトを含む第２の出力とを含み、前記トークンメカニクスサブコンポーネントは、前記支出取引の前記第１の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含む第１のロッキングスクリプトを含むか検証することと、存在する場合に、前記支出取引の前記第２の出力が、ａ）所定の支払アドレスを含むそれぞれの標準支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外の任意のアドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含む第２のロッキングスクリプトを含むか検証することと、前記第２の出力が存在する場合に、前記支出取引の前記第１のロッキングスクリプト及び前記第２のロッキングスクリプトによってロックされている、前記デジタル資産の合計額が前記第１のトークンの額と等しいか検証することと、を行うように構成されている。

実施形態では、前記トークンメカニクスコンポーネントは、前記支出取引の前記第１のロッキングスクリプトが、所定の支払アドレスを含む前記標準支払スクリプトテンプレートを含まない場合、前記第１のロッキングスクリプトが、前記所定の支払アドレス以外の支払アドレスを含むそれぞれの可変コンポーネントと、支出されている以前の取引の前記第１のトークンロッキングスクリプトの対応する定数コンポーネントと同一の、後続の前記定数コンポーネントとを含むか検証すること、及び／又は前記支出取引の前記第２のロッキングスクリプトが存在する場合、前記第２のロッキングスクリプトが、任意の支払アドレスを含むそれぞれの可変コンポーネントと、後続の、支出されている以前の取引の前記第１のトークンロッキングスクリプトの対応する定数コンポーネントと同一の、後続の前記定数コンポーネントとを含むか検証すること、を行うように構成され得る。

実施形態では、定数コンポーネントは所定の支払アドレスを含み得る。

つまり、所定のアドレスは定数部分にハードコードされている。

実施形態では、前記支出取引の入力スクリプトはｓｉｇｈａｓｈ原像を含んでもよく、該原像は前記第１のトークンロッキングスクリプト及び前記第１のトークンの額を含み、前記トークンメカニクスサブコンポーネントは、前記検証ステップを行うために、前記第１のトークンロッキングスクリプト及び支出されている前記出力の前記第１のトークンの額の両方を、前記原像から抽出すること、を行うように構成されている。

支出取引の入力に含まれる第１のトークンロッキングスクリプトは、支出が試みられている出力のロッキングスクリプトであり、その時点で実行されているものと同一である。支出取引の入力に含まれる第１のトークンの額は、支出が試みられている出力に保持されている値である。

実施形態では、前記原像は、１つ以上のデータ対の連結のハッシュを含んでもよく、各データ対は、前記支出取引のそれぞれのロッキングスクリプトからのそれぞれの支払アドレスと、該それぞれのロッキングスクリプトによってロックされている対応する額とを含み、前記トークンメカニクスサブコンポーネントは、前記原像から前記１つ以上のデータ対の連結のハッシュを抽出することと、前記１つ以上のデータ対に基づいてハッシュを生成することと、前記生成されたハッシュが前記抽出されたハッシュと等しいか検証することと、を行うように構成されている。

支出取引の出力の形式に応じて、１つ以上の「対応する額」のうちの１つ以上はネイティブトークン、例えば、任意の変更又は「アトミックスワップ」支払受領のための出力であってもよく、対応する額の１つ以上は、例えば、償還又はトークン出力のための再定義されたトークンであり得る。

実施形態では、前記ハッシュを生成するために用いられる前記１つ以上のデータ対は、前記入力スクリプトから取得されるか又は前記以前の出力ロッキングスクリプトの入力アドレス及び額の対を前記原像から取得することによって構築され得る。

「ハッシュ」への言及は、「ダブルｓｈａ２５６ハッシュ」と同等であり得る。一般に、同じハッシュ関数が一貫して用いられる限り、任意のハッシュ関数が用いられ得る。

実施形態では、前記トークンメカニクスサブコンポーネントは、前記支出取引データの原像を生成することと、前記支出取引データの前記生成された原像が、前記支出取引の前記入力内に含まれる前記原像と等しいか検証することと、を行うように構成され得る。

実施形態では、前記支出取引の前記入力は、ダミー秘密鍵と、対応するダミー公開鍵とを含んでもよく、前記トークンメカニクスサブコンポーネントは、前記支出取引の前記生成された原像が、前記支出取引の前記入力に含まれる前記原像と等しいかを、前記ダミー秘密鍵及び前記支出取引の前記入力に含まれる前記原像のハッシュを用いてデジタル署名を生成することと、前記デジタル署名が、前記ダミー公開鍵及び前記支出取引の前記生成された原像のハッシュに対して検証された場合に有効な署名か検証することとを行うことにより検証するように構成されている。

例えば、ＥＣＤＳＡ署名を生成するための特定の署名アルゴリズムに応じて、一時的なダミー秘密鍵が必要になり得る。

例えば、トークンメカニクスのサブコンポーネントは、生成された原像の前記検証を行うように構成されたＯＰ＿ＰＵＳＨ＿ＴＸ擬似オペコード実施を含み得る。

実施形態では、前記トークンメカニクスサブコンポーネントは、前記支出取引のそれぞれのロッキングスクリプトに含まれる前記それぞれの支払アドレスが、前記第１のトークン出力の前記可変コンポーネントに含まれる前記第１の支払アドレスと同じ種類であるか検証すること、を行うように構成され得る。

加えて、トークンメカニクスサブコンポーネントは、支出取引のそれぞれの出力が、第１のトークン出力に含まれる支払スクリプトテンプレートと同じ種類のそれぞれの支払スクリプトテンプレート、例えばＰ２ＰＫＨロッキングスクリプトを含むかを検証するように構成され得る。

実施形態では、前記第１の支払アドレスの種類は公開鍵ハッシュアドレスであり得る。

実施形態では、前記第１のトークンの額は、前記基礎となるデジタル資産の単一の単位を含み得る。

実施形態では、前記第１のトークンの額は、前記基礎となるデジタル資産の複数の単位を含み得る。

実施形態では、前記定数コンポーネントはデータサブコンポーネントを含み、該データサブコンポーネントは、トークンプロトコル識別子、及びトークン発行取引の識別子であって、該トークン発行取引は、ｉ）トークン発行者と初期トークン受領者との間の発行契約及びｉｉ）初期トークン額の一方又は両方を含む、トークン発行取引の識別子のうちの一方又は両方を含み得る。

定数不変データサブコンポーネントは、ＯＰ＿ＲＥＴＵＲＮオペコードの後に置かれ得る。

実施形態では、前記支出取引は、第３のロッキングスクリプトと、対応する第３の額とを含む第３の出力を含んでもよく、前記トークンメカニクスサブコンポーネントは、前記第３のロッキングスクリプトが、所定の支払タイプテンプレートのそれぞれの支払アドレス、例えば、Ｐ２ＰＫＨ支払テンプレートのＰＫＨアドレスと、それぞれの対応する額とを含むか検証するように構成されている。

実施形態では、前記第１のトークン取引は、以前のトークン取引のそれぞれのトークン出力を支出する第１のトークン入力を含み、該第１のトークン入力は、前記第１のトークン取引のそれ自体を除く全て（all but itself）と、支出された前記以前のトークン取引のそれぞれの額及びそれぞれのロッキングスクリプトと、少なくとも１つ以上のデータ対であって、各データ対は、前記第１のトークン取引のそれぞれのロッキングスクリプトに含まれる支払アドレスと、該それぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の対応する額とを少なくとも含む、少なくとも１つ以上のデータ対と、を含む.

実施形態では、前記第１のトークン取引は第２のトークン出力を含み、該第２のトークン出力は第２のトークンロッキングスクリプトと第２のトークンの額とを含み、該第２のトークンロッキングスクリプトはそれぞれの可変コンポーネント及びそれぞれの定数コンポーネントを含み、該それぞれの可変コンポーネントは第２の支払アドレスを含み、該それぞれの定数コンポーネントは前記第１のトークンロッキングスクリプトの前記定数コンポーネントと合致する

実施形態では、前記第１のトークン取引は第３の出力を含み、該第３の出力は第３の支払アドレスを含み得る。

実施形態では、前記第１のトークン入力は、第１の当事者によって生成された第１の署名を含み、前記第１のトークン取引は第２の入力を含み、該第２の入力は、第２の当事者によって生成された第２の署名を含み、前記第１のトークン取引は支払テンプレートに含まれる支払アドレスを含む支払出力を含み、該支払アドレスは前記第１の当事者にリンクされている。

支払出力は、販売したトークンについて第２の当事者から支払を受領するために第１の当事者にリンクされている。

本明細書で開示の別の態様によれば、１つ以上のメモリユニットを含むメモリと、
１つ以上の処理ユニットを含む処理装置であって、前記メモリは、該処理装置上で実行されるように構成されたコードを記憶し、該コードは、前記処理装置上にある場合に、上述の実施形態のいずれかの方法が行われるように構成されている、処理装置と、を含むコンピュータ機器が提供される。

本明細書で開示の別の態様によれば、コンピュータ読み取り可能記憶装置上で具現化されるコンピュータプログラムであって、コンピュータ機器上で実行された場合に、上述の実施形態のいずれかの方法が行われるように構成されている、コンピュータプログラムが提供される。

本明細書で開示の別の態様によれば、第１のトークン出力を含むトークン取引が提供され、該第１のトークン出力は、第１のトークンロッキングスクリプト及び第１のトークンの額を含み、該第１のトークンロッキングスクリプトは、可変コンポーネント及び定数コンポーネントを含み、該可変コンポーネントは支払テンプレートに埋め込まれた第１の支払アドレスを含み、該定数コンポーネントはトークンメカニクスサブコンポーネントを含み、前記トークンメカニクスサブコンポーネントは、支出取引の入力スクリプトであって、該入力スクリプトは、該支出取引のそれ以外の全てと、支出されている以前の取引出力においてロックされている額及びそれぞれのロッキングスクリプトを含む、入力スクリプトと共に実行された場合に、前記支出取引の入力スクリプトから１つ以上のデータ対を取得することであって、各データ対は、ｉ）前記支出取引出力のそれぞれのロッキングスクリプトに含まれる少なくともそれぞれの支払アドレスと、ｉｉ）その出力のそれぞれのロッキングスクリプトによってロックされている、基礎となるデジタル資産の対応する額とを含む、ことと、前記支出取引の１つ以上の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含むそれぞれのロッキングスクリプトを含むかを検証することと、前記支出取引の１つ以上の出力について、前記１つ以上の出力のそれぞれのロッキングスクリプトによってロックされている、基礎となるデジタル資産の合計額が、前記第１のトークンの額と等しいかを検証することと、を行うように構成され、前記トークンメカニクスサブコンポーネントは、検証ステップのいずれかが失敗した場合、実行の間に失敗するように構成されている。

本明細書で開示の別の態様によれば、前記トークン取引が記憶されたコンピュータ読み取り可能記憶媒体が提供される。

開示の技術の他の変種又は使用事例は、本明細書の開示が与えられた場合に当業者に明らかになり得る。開示の範囲は、説明した実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

Claims (23)

1. ブロックチェーン取引を用いてデジタルトークンを送信するコンピュータ実施方法であって、各トークンはブロックチェーンの基礎となるデジタル資産の固有の単位の単一の単位によって表され、当該方法は、
   第１のトークン取引を生成することと、
   前記第１のトークン取引をブロックチェーンネットワークに送信することと、
   を含み、
   前記第１のトークン取引は第１のトークン出力を含み、該第１のトークン出力は第１のトークンロッキングスクリプト及び第１のトークンの額を含み、該第１のトークンロッキングスクリプトは可変コンポーネント及び定数コンポーネントを含み、該可変コンポーネントは、支払テンプレートに埋め込まれた第１の支払アドレスを含み、該定数コンポーネントはトークンメカニクスサブコンポーネントを含み、該トークンメカニクスサブコンポーネントは、支出取引の入力スクリプトであって、該入力スクリプトは、該支出取引の自身を除く全てに加えて、支出されている以前の取引出力においてロックされている額及びそれぞれのロッキングスクリプトを含む入力スクリプトと共に実行された場合、
   前記支出取引の入力スクリプトから１つ以上のデータ対を取得することであって、各データ対は、ｉ）前記支出取引の出力のそれぞれのロッキングスクリプトに含まれる少なくともそれぞれの支払アドレスと、ｉｉ）その出力のそれぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の対応する額とを含む、ことと、
   前記支出取引の１つ以上の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含むそれぞれのロッキングスクリプトを含むか検証することと、
   前記支出取引の１つ以上の出力について、前記１つ以上の出力のそれぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の合計額が、前記第１のトークンの額と等しいか検証することと、
   を行うように構成され、
   前記トークンメカニクスサブコンポーネントは、検証ステップのいずれかが失敗した場合、実行の間に失敗するように構成されている、方法。
2. 前記支出取引は、第１のロッキングスクリプトを含む第１の出力と、第２のロッキングスクリプトを含む第２の出力とを含み、前記トークンメカニクスサブコンポーネントは、
   前記支出取引の前記第１の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含む第１のロッキングスクリプトを含むか検証することと、
   存在する場合に、前記支出取引の前記第２の出力が、ａ）所定の支払アドレスを含むそれぞれの標準支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外の任意のアドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含む第２のロッキングスクリプトを含むか検証することと、
   前記第２の出力が存在する場合に、前記支出取引の前記第１のロッキングスクリプト及び前記第２のロッキングスクリプトによってロックされている、前記デジタル資産の合計額が前記第１のトークンの額と等しいか検証することと、
   を行うように構成されている、請求項１に記載の方法。
3. 前記トークンメカニクスコンポーネントは、
   前記支出取引の前記第１のロッキングスクリプトが、所定の支払アドレスを含む前記標準支払スクリプトテンプレートを含まない場合、前記第１のロッキングスクリプトが、前記所定の支払アドレス以外の支払アドレスを含むそれぞれの可変コンポーネントと、支出されている以前の取引の前記第１のトークンロッキングスクリプトの対応する定数コンポーネントと同一の、後続の前記定数コンポーネントとを含むか検証すること、及び／又は
   前記支出取引の前記第２のロッキングスクリプトが存在する場合、前記第２のロッキングスクリプトが、任意の支払アドレスを含むそれぞれの可変コンポーネントと、後続の、支出されている以前の取引の前記第１のトークンロッキングスクリプトの対応する定数コンポーネントと同一の、後続の前記定数コンポーネントとを含むか検証すること、
   を行うように構成されている、請求項１又は２に記載の方法。
4. 前記定数コンポーネントは、前記所定の支払アドレスを含む、請求項１乃至３のいずれか一項に記載の方法。
5. 前記支出取引の入力スクリプトはｓｉｇｈａｓｈ原像を含み、該原像は前記第１のトークンロッキングスクリプト及び前記第１のトークンの額を含み、前記トークンメカニクスサブコンポーネントは、
   前記検証ステップを行うために、前記第１のトークンロッキングスクリプト及び支出されている前記出力の前記第１のトークンの額の両方を、前記原像から抽出すること、
   を行うように構成されている、請求項１乃至４のいずれか一項に記載の方法。
6. 前記原像は、１つ以上のデータ対の連結のハッシュを含み、各データ対は、前記支出取引のそれぞれのロッキングスクリプトからのそれぞれの支払アドレスと、該それぞれのロッキングスクリプトによってロックされている対応する額とを含み、前記トークンメカニクスサブコンポーネントは、
   前記原像から前記１つ以上のデータ対の連結のハッシュを抽出することと、
   前記１つ以上のデータ対に基づいてハッシュを生成することと、
   前記生成されたハッシュが前記抽出されたハッシュと等しいか検証することと、
   を行うように構成されている、請求項５に記載の方法。
7. 前記ハッシュを生成するために用いられる前記１つ以上のデータ対は、前記入力スクリプトから取得されるか又は前記以前の出力ロッキングスクリプトの入力アドレス及び額の対を前記原像から取得することによって構築される、請求項６に記載の方法。
8. 前記トークンメカニクスサブコンポーネントは、
   前記支出取引データの原像を生成することと、
   前記支出取引データの前記生成された原像が、前記支出取引の前記入力内に含まれる前記原像と等しいか検証することと、
   を行うように構成されている、請求項５乃至７のいずれか一項に記載の方法。
9. 前記支出取引の前記入力は、ダミー秘密鍵と、対応するダミー公開鍵とを含み、前記トークンメカニクスサブコンポーネントは、
   前記支出取引の前記生成された原像が、前記支出取引の前記入力に含まれる前記原像と等しいかを、
   前記ダミー秘密鍵及び前記支出取引の前記入力に含まれる前記原像のハッシュを用いてデジタル署名を生成することと、
   前記デジタル署名が、前記ダミー公開鍵及び前記支出取引の前記生成された原像のハッシュに対して検証された場合に有効な署名か検証することと、
   を行うことにより検証するように構成されている、請求項８に記載の方法。
10. 前記トークンメカニクスサブコンポーネントは、
    前記支出取引のそれぞれのロッキングスクリプトに含まれる前記それぞれの支払アドレスが、前記第１のトークン出力の前記可変コンポーネントに含まれる前記第１の支払アドレスと同じ種類であるか検証すること、
    を行うように構成されている、請求項１乃至９のいずれか一項に記載の方法。
11. 前記第１の支払アドレスの種類は公開鍵ハッシュアドレスである、請求項１乃至９のいずれか一項に記載の方法。
12. 前記第１のトークンの額は、前記基礎となるデジタル資産の単一の単位を含む、請求項１乃至１１のいずれか一項に記載の方法。
13. 前記第１のトークンの額は、前記基礎となるデジタル資産の複数の単位を含む、請求項１乃至１１のいずれか一項に記載の方法。
14. 前記定数コンポーネントはデータサブコンポーネントを含み、該データサブコンポーネントは、
    トークンプロトコル識別子、及び
    トークン発行取引の識別子であって、該トークン発行取引は、ｉ）トークン発行者と初期トークン受領者との間の発行契約及びｉｉ）初期トークン額の一方又は両方を含む、トークン発行取引の識別子
    のうちの一方又は両方を含む、請求項１乃至１３のいずれか一項に記載の方法。
15. 前記支出取引は、第３のロッキングスクリプトと、対応する第３の額とを含む第３の出力を含み、前記トークンメカニクスサブコンポーネントは、
    前記第３のロッキングスクリプトが、所定の支払タイプテンプレートのそれぞれの支払アドレスと、それぞれの対応する額とを含むか検証すること、
    を行うように構成されている、請求項２又はそれに従属する請求項のいずれか一項に記載の方法。
16. 前記第１のトークン取引は、以前のトークン取引のそれぞれのトークン出力を支出する第１のトークン入力を含み、該第１のトークン入力は、
    前記第１のトークン取引のそれ自体を除く全てと、支出された前記以前のトークン取引のそれぞれの額及びそれぞれのロッキングスクリプトと、
    少なくとも１つ以上のデータ対であって、各データ対は、前記第１のトークン取引のそれぞれのロッキングスクリプトに含まれる支払アドレスと、該それぞれのロッキングスクリプトによってロックされている、前記基礎となるデジタル資産の対応する額とを少なくとも含む、少なくとも１つ以上のデータ対と、
    を含む、請求項１乃至１５のいずれか一項に記載の方法。
17. 前記第１のトークン取引は第２のトークン出力を含み、該第２のトークン出力は第２のトークンロッキングスクリプトと第２のトークンの額とを含み、該第２のトークンロッキングスクリプトはそれぞれの可変コンポーネント及びそれぞれの定数コンポーネントを含み、該それぞれの可変コンポーネントは第２の支払アドレスを含み、該それぞれの定数コンポーネントは前記第１のトークンロッキングスクリプトの前記定数コンポーネントと合致する、請求項１６に記載の方法。
18. 前記第１のトークン取引は第３の出力を含み、該第３の出力は第３の支払アドレスを含む、請求項１７に記載の方法。
19. 前記第１のトークン入力は、第１の当事者によって生成された第１の署名を含み、前記第１のトークン取引は第２の入力を含み、該第２の入力は、第２の当事者によって生成された第２の署名を含み、前記第１のトークン取引は支払テンプレートに含まれる支払アドレスを含む支払出力を含み、該支払アドレスは前記第１の当事者にリンクされている、請求項１６乃至１８のいずれか一項に記載の方法。
20. １つ以上のメモリユニットを含むメモリと、
    １つ以上の処理ユニットを含む処理装置であって、前記メモリは、該処理装置上で実行されるように構成されたコードを記憶し、該コードは、前記処理装置上にある場合に、請求項１乃至１９のいずれかの方法が行われるように構成されている、処理装置と、
    を含むコンピュータ機器。
21. コンピュータ読み取り可能記憶装置上で具現化されるコンピュータプログラムであって、コンピュータ機器上で実行された場合に、請求項１乃至１９のいずれかの方法が行われるように構成されている、コンピュータプログラム。
22. 第１のトークン出力を含むトークン取引であって、該第１のトークン出力は、第１のトークンロッキングスクリプト及び第１のトークンの額を含み、該第１のトークンロッキングスクリプトは、可変コンポーネント及び定数コンポーネントを含み、該可変コンポーネントは支払テンプレートに埋め込まれた第１の支払アドレスを含み、該定数コンポーネントはトークンメカニクスサブコンポーネントを含み、前記トークンメカニクスサブコンポーネントは、支出取引の入力スクリプトであって、該入力スクリプトは、該支出取引のそれ以外の全てと、支出されている以前の取引出力においてロックされている額及びそれぞれのロッキングスクリプトを含む、入力スクリプトと共に実行された場合に、
    前記支出取引の入力スクリプトから１つ以上のデータ対を取得することであって、各データ対は、ｉ）前記支出取引出力のそれぞれのロッキングスクリプトに含まれる少なくともそれぞれの支払アドレスと、ｉｉ）その出力のそれぞれのロッキングスクリプトによってロックされている、基礎となるデジタル資産の対応する額とを含む、ことと、
    前記支出取引の１つ以上の出力が、ａ）所定の支払アドレスを含むそれぞれの支払スクリプトテンプレート又はｂ）前記所定の支払アドレス以外のそれぞれの支払アドレスを含むそれぞれの可変コンポーネントと、後続の前記定数コンポーネントとを含むそれぞれのロッキングスクリプトを含むかを検証することと、
    前記支出取引の１つ以上の出力について、前記１つ以上の出力のそれぞれのロッキングスクリプトによってロックされている、基礎となるデジタル資産の合計額が、前記第１のトークンの額と等しいかを検証することと、
    を行うように構成され、
    前記トークンメカニクスサブコンポーネントは、検証ステップのいずれかが失敗した場合、実行の間に失敗するように構成されている、トークン取引。
23. 請求項２２に記載のトークン取引が記憶されたコンピュータ読み取り可能記憶媒体。