JP7744348B2 - シングルユーストークン - Google Patents

Description

本開示は、シングルユーストークンを発行するためにブロックチェーンを使用する方法に関する。

ブロックチェーンは、分散型データ構造の形態を指し、ブロックチェーンの複製コピーが、ピアツーピア（Ｐ２Ｐ）ネットワーク内の複数のノードの各々において維持される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは１つまたは複数のトランザクションを含む。各トランザクションは、１つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指し示し得る。トランザクションは、「マイニング」として知られるプロセスによって新しいブロックに含まれるためにネットワークにサブミットされ得、このプロセスは、複数のマイニングノードの各々が、「プルーフオブワーク」を実行しようと競うこと、すなわち、ブロックに含まれるのを待っている保留中のトランザクションのプールに基づいて暗号パズルを解くことを伴う。

従来、ブロックチェーンにおけるトランザクションは、デジタル資産、すなわち価値の蓄蔵として機能するデータを伝達するために使用される。しかしながら、ブロックチェーンは、ブロックチェーンの上に追加の機能を重ねるために活用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションの出力における追加のユーザデータの格納を可能にし得る。最新のブロックチェーンでは、単一のトランザクション内に格納可能な最大データ容量が増えており、より複雑なデータを組み込むことが可能である。例えば、これを使用して、ブロックチェーンに電子文書を格納したり、さらにはオーディオまたはビデオデータを格納したりすることができる。

ネットワーク内の各ノードは、フォワード、マイニング、および格納という３つの役割のうちのいずれか１つ、２つ、またはすべてを担うことができる。フォワーディングノードは、ネットワークのノード全体にトランザクションを伝搬する。マイニングノードは、ブロックへのトランザクションのマイニングを実行する。ストレージノードは各々が、ブロックチェーンのマイニングされたブロックのそれら自体のコピーを格納する。ブロックチェーンにトランザクションを記録させるために、当事者は、伝搬されるべきネットワークのノードのうちの１つにトランザクションを送信する。トランザクションを受信するマイニングノードは、トランザクションを新しいブロックにマイニングしようと競い合い得る。各ノードは、同じノードプロトコルを尊重するように構成され、そのノードプロトコルには、トランザクションが有効であるための１つまたは複数の条件が含まれる。無効なトランザクションは、伝搬もブロックへのマイニングもされない。トランザクションが妥当性確認（validate）され、それによってブロックチェーン上に受け入れられたと仮定すると、追加のユーザデータは、不変の公開記録としてＰ２Ｐネットワーク内のノードの各々に格納されたままになる。

いくつかのブロックチェーンプロトコルの基本的な機能の１つは、二重支出の防止である。このセキュリティ機能は、過去１０年の間、実生活のテストに耐えており、いまだに揺るぎない。二重支出ができないことが意味することの１つに、ブロックチェーントランザクションの未使用出力のシングルユースがある。本発明は、ブロックチェーントランザクション出力のシングルユース特性を利用して、ブロックチェーン上でのシングルユーストークンの発行を可能にする。シングルユーストークンは、例えば、映画のチケット、ギフトカード、アフタヌーンティーバウチャー、航空券などであり得る。実施形態は、トークンがシングルユースであることを確実にするだけでなく、記録の不変性、透明性、および監査可能性も提供する。

本明細書に開示される一態様によれば、ブロックチェーントランザクションを使用して、１つまたは複数のそれぞれのトークン償還者によって使用される１つまたは複数のシングルユーストークンを発行するコンピュータ実装方法であって、方法は、トークン発行者によって実行され、トークントランザクションを生成することと、ここで、トークントランザクションは、１つまたは複数のトークン出力であって、各トークン出力が、それぞれのシングルユーストークンを表すトークンデータを含み、各シングルユーストークンが、トークントランザクションのそれぞれの使用可能な出力に関連付けられ、各シングルユーストークンのそれぞれの有効性は、それぞれの使用可能な出力がブロックチェーンの未使用トランザクション出力セットに存在することを条件とする、１つまたは複数のトークン出力と、１つまたは複数の入力であって、入力のうちの少なくとも第１の入力が、トークン発行者の第１の公開鍵にリンクされた署名を含む、１つまたは複数の入力とを含み、ブロックチェーンに記録させるためにトークントランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信することとを含む方法が提供される。

トークン出力は、シングルユーストークンを表すデータを含むブロックチェーントランザクション（「トークントランザクション」）の出力である。シングルユーストークンは、シングルユースのみに有効なトークンであり、例えば、シングルユーストークンは、所与の製品（または製品のセット）またはサービスと１回のみ交換または償還することができる。シングルユーストークンは再利用できない。各シングルユーストークンは、トークントランザクションのそれぞれの使用可能な出力に関連付けられる（またはリンクされる）。使用可能な出力は、後のブロックチェーントランザクションを使用して使用（spend）されるまで、ブロックチェーンの未使用トランザクション出力（ＵＴＸＯ）セットに残る。トークントランザクションの使用可能な出力がＵＴＸＯセット内にある場合、関連付けられたシングルユーストークンは有効であり、使用すること、例えば、製品またはサービスと償還することができる。トークントランザクションの使用可能な出力がＵＴＸＯセット内にない場合、関連付けられたシングルユーストークンは使用済み（または失効済み）であるため、使用することができない。

本明細書に開示される別の態様によれば、１つまたは複数のトークン出力であって、各トークン出力が、それぞれのシングルユーストークンを表すトークンデータを含み、各シングルユーストークンが、トークントランザクションのそれぞれの使用可能な出力に関連付けられ、各シングルユーストークンのそれぞれの有効性は、それぞれの使用可能な出力がブロックチェーンの未使用トランザクション出力セットに存在することを条件とする、１つまたは複数のトークン出力と、１つまたは複数の入力であって、入力のうちの少なくとも第１の入力が、トークン発行者の第１の公開鍵にリンクされた署名を含む、１つまたは複数の入力とを含む、ブロックチェーンのためのトークントランザクションが提供される。

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、単なる例として添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。 ブロックチェーンを実装するための別のシステムの概略ブロック図である。 クライアントアプリケーションの概略ブロック図である。 図４Ａのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略的なモックアップである。 トランザクションを処理するためのいくつかのノードソフトウェアの概略ブロック図である。 ブロックチェーン上でシングルユーストークンを実装するためのシステムの概略ブロック図である。 患者に処方箋を発行するための例示的なシステムの要件の概略図である。 患者に処方箋を発行するための例示的なシステムにおける信頼できる機関および医療データベースの役割の概略図である。 処方者６０１が患者に処方箋を発行するための例示的なシーケンス図である。 患者が薬剤師と処方箋を償還するための例示的なシーケンス図である。

例示的なシステムの概要
図１は、一般に、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１を含む。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）オーバーレイネットワーク１０６を形成するように構成された複数のノード１０４を含む。各ノード１０４は、ピアのコンピュータ機器を含み、ノード１０４のうちの異なるものが異なるピアに属する。各ノード１０４は、１つまたは複数のプロセッサ、例えば１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備える処理装置を含む。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を使用する１つまたは複数のメモリユニットを備え得る。

ブロックチェーン１５０は、データのブロック１５１のチェーンを含み、ブロックチェーン１５０のそれぞれのコピーは、Ｐ２Ｐネットワーク１６０内の複数のノードの各々において維持される。チェーン内の各ブロック１５１は、１つまたは複数のトランザクション１５２を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、典型的には、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各標準的なトランザクション１５２のデータ構造は、少なくとも１つの入力と少なくとも１つの出力とを含む。各出力は、出力が暗号的にロックされている（ロック解除され、それによって償還または使用されるためには、そのユーザの署名を必要とする）ユーザ１０３に属するデジタル資産の量を表す額を指定する。各入力は、先行するトランザクション１５２の出力を指し示し、それによってトランザクションをリンクする。

ノード１０４のうちの少なくともいくつかは、トランザクション１５２をフォワードし、それによってそれを伝搬するフォワーディングノード１０４Ｆの役割を引き受ける。ノード１０４のうちの少なくともいくつかは、ブロック１５１をマイニングするマイナー１０４Ｍの役割を引き受ける。ノード１０４のうちの少なくともいくつかは、ストレージノード１０４Ｓ（「フルコピー」ノードと呼ばれることもある）の役割を引き受け、その各々が、同じブロックチェーン１５０のそれぞれのコピーをそれぞれのメモリに格納する。各マイナーノード１０４Ｍはまた、ブロック１５１にマイニングされるのを待っているトランザクション１５２のプール１５４を維持する。所与のノード１０４は、フォワーディングノード１０４、マイナー１０４Ｍ、ストレージノード１０４Ｓ、またはこれらのうちの２つもしくはすべての任意の組合せであり得る。

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

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

上記は、「出力ベース」トランザクションプロトコルと呼ばれ得、未使用トランザクション出力（ＵＴＸＯ）タイププロトコルと呼ばれることもある（ここでは出力はＵＴＸＯと呼ばれる）。ユーザの総残高は、ブロックチェーンに格納された任意の１つの数字で定義されるのではなく、代わりに、ユーザは、ブロックチェーン１５１内の多くの異なるトランザクション１５２全体に散在しているそのユーザのすべてのＵＴＸＯの値を照合するための特別な「ウォレット」アプリケーション１０５を必要とする。

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

いずれかのタイプのトランザクションプロトコルを用いて、ユーザ１０３が新しいトランザクション１５２ｊを成立させることを望む場合、ユーザは新しいトランザクションをユーザのコンピュータ端末１０２からＰ２Ｐネットワーク１０６のノード１０４（これは、今日では典型的にはサーバまたはデータセンタであるが、原理的には他のユーザ端末であってもよい）のうちの１つに送信する。このノード１０４は、ノード１０４の各々において適用されるノードプロトコルにしたがってトランザクションが有効であるかどうかをチェックする。ノードプロトコルの詳細は、当該ブロックチェーン１５０において使用されているトランザクションプロトコルのタイプに対応し、全体としてトランザクションモデルを形成する。ノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付けられたシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにノード１０４に求める。出力ベースの場合、これは、新しいトランザクション１５２ｊの入力に含まれるユーザの暗号署名が、新しいトランザクションが使用する先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名が、新しいトランザクションの入力が指し示す前のトランザクション１５２ｉの出力をロック解除することをチェックすることを少なくとも含む。いくつかのトランザクションプロトコルでは、条件は、入力および／または出力に含まれるカスタムスクリプトによって少なくとも部分的に定義され得る。代替的に、単にノードプロトコルのみによって固定されてもよく、またはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、現在のノードは、それをＰ２Ｐネットワーク１０６内のノード１０４のうちの１つまたは複数の他のノードにフォワードする。これらのノード１０４のうちの少なくともいくつかは、フォワーディングノード１０４Ｆとしても機能し、同じノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはノード１０４のネットワーク全体に伝搬される。

出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が使用されたかどうかの定義は、それがノードプロトコルにしたがって別の前方のトランザクション１５２ｊの入力によって有効に償還されたかどうかかである。トランザクションが有効であるための別の条件は、それが使用または償還しようとする先行する遷移１５２ｉの出力が、別の有効なトランザクションによってまだ使用／償還されていないことである。同様に、有効でない場合、トランザクション１５２ｊは、ブロックチェーンに伝搬も記録もされない。これは、使用者が同じトランザクションの出力を複数回使用しようとする二重支出を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重支出を防止する。ここでも、トランザクション順序が定義されているので、アカウント残高は常に単一の定義された状態にある。

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

最初にパズルを解いたマイナーノード１０４Ｍは、これをネットワーク１０６に公表し、後にネットワーク内の他のノード１０４によって容易にチェックすることができるその解を証明として提供する（ハッシュに対する解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。勝者がパズルを解いたトランザクションのプール１５４は、次いで、ストレージノード１０４Ｓとして機能するノード１０４のうちの少なくともいくつかによって、そのような各ノードにおいて勝者が公表した解をチェックしたことに基づいて、ブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークは、新たなブロック１５１を作成するのに多大な労力を要するので、二重支出のリスクを低減するのに役立ち、二重支出を含むブロックは他のノード１０４によって拒絶される可能性が高いので、マイニングノード１０４Ｍは、二重支出がそれらのブロックに含まれないようにインセンティブが与えられる。ブロック１５１は、一旦作成されると、同じプロトコルにしたがってＰ２Ｐネットワーク１０６内の格納ノード１０４Ｓの各々で認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１にシーケンシャル順序を付与する。トランザクション１５２は、Ｐ２Ｐネットワーク１０６内の各ストレージノード１０４Ｓにおいて順序付けられたブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

任意の所与の時間にパズルを解こうと競い合う異なるマイナー１０４Ｍは、それらがいつ解を探索し始めたかに応じて、任意の所与の時間におけるマイニングされていないトランザクションプール１５４の異なるスナップショットに基づいて、そうしている可能性があることに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎに含まれるかを定義し、マイニングされていないトランザクションの現在のプール１５４が更新される。次いで、マイナー１０４Ｍは、新しく定義された未処理プール１５４からブロックを作成しようと競い合い続け、以下同様である。２人のマイナー１０４Ｍが互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解が伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどのプロングが最も長く成長しても、最終的なブロックチェーン１５０となる。

ほとんどのブロックチェーンでは、勝利マイナー１０４Ｍには、（あるユーザから別のユーザにある額のデジタル資産を転送する通常のトランザクションとは対照的に）突如新しい量のデジタル資産を作成する特別な種類の新しいトランザクションで自動的に報酬が与えられる。したがって、勝者ノードは、ある量のデジタル資産を「マイニング」したといわれる。この特別なタイプのトランザクションは、「生成」トランザクションと呼ばれることがある。それは自動的に新しいブロック１５１ｎの一部を形成する。この報酬は、マイナー１０４Ｍがプルーフオブワーク競争に参加するためのインセンティブを与える。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが含まれたブロック１５１ｎを作成した勝利マイナー１０４Ｍにさらに報酬を与えるために、その出力の１つにおいて追加のトランザクション手数料を指定する。

マイニングに関与する計算リソースに起因して、典型的には、マイナーノード１０４Ｍの少なくとも各々は、１つまたは複数の物理サーバユニットを含むサーバの形態をとるか、またはデータセンタ全体の形態をとる。各フォワーディングノード１０４Ｍおよび／またはストレージノード１０４Ｓもまた、サーバまたはデータセンタの形態をとり得る。しかしながら、原則として、任意の所与のノード１０４は、一緒にネットワーク化されたユーザ端末またはユーザ端末のグループの形態をとることができる。

各ノード１０４のメモリは、そのそれぞれの１つまたは複数の役割を実行し、ノードプロトコルにしたがってトランザクション１５２を処理するために、ノード１０４の処理装置上で実行ように構成されたソフトウェアを記憶する。本明細書においてノード１０４に帰する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。また、本明細書で使用される「ブロックチェーン」という用語は、一般に、この種類の技術を指す総称であり、任意の特定の専有のブロックチェーン、プロトコルまたはサービスに限定されない。

消費ユーザの役割を果たす複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらは、トランザクションにおいて支払人および受取人として機能するが、他の当事者に代わってトランザクションのマイニングまたは伝搬に必ずしも参加するわけではない。それらは、マイニングプロトコルを必ずしも実行するわけではない。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。はるかに多くのそのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２が存在し、システムに参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと呼ばれ、第２の当事者１０３ｂはボブと呼ばれるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる参照も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。

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

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

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

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

述べたように、ブロックチェーン１５０は、ブロック１５１のチェーンを含み、各ブロック１５１は、前述したようなプルーフオブワークプロセスによって作成された１つまたは複数のトランザクション１５２のセットを含む。各ブロック１５１はまた、ブロック１５１へのシーケンシャル順序を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。ブロックチェーン１５０は、プルーフオブワークプロセスによって新しいブロックに含まれるのを待っている有効なトランザクションのプール１５４も含む。各トランザクション１５２（生成トランザクション以外）は、トランザクションのシーケンスへの順序を定義するように、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであった発生ブロック（Ｇｂ）１５３までずっと戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなく発生ブロック１５３を指し示していた。

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

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

１つまたは複数のストレージノード１０４において維持されるブロックチェーン１５０のコピー内のプール１５４に認められると、マイナーノード１０４Ｍは、新しいトランザクション１５２を含むプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のマイナー１０４Ｍは、プール１５４の古いビューに基づいてパズルを解こうと試みている可能性があるが、誰が最初に到達しても、次の新しいブロック１５１がどこで終わり新しいプール１５４がどこで開始するかを定義することとなり、最終的には、誰かが、アリスのトランザクション１５２ｊを含むプール１５４の一部についてパズルを解く）。新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは不変的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、前のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。

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

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

図２の各出力はＵＴＸＯとして示されているが、トランザクションは、追加的にまたは代替的に、１つまたは複数の使用不可能なトランザクション出力を含み得ることに留意されたい。

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

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

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

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

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

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

公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の秘密鍵でメッセージを暗号化することによってメッセージに署名した場合、アリスの公開鍵および平文のメッセージ（暗号化されていないメッセージ）が与えられると、ノード１０４などの別のエンティティは、メッセージの暗号化バージョンがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージの平文バージョンにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができる。

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

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

実際には、今日、生成トランザクションの報酬だけでは、典型的には、マイニングを動機付けるのに十分ではないので、アリスは通常、勝利マイナーに対する手数料を含む必要もある。アリスがマイナーに対する手数料を含めない場合、Ｔｘ₀は、マイナーノード１０４Ｍによって拒否される可能性が高く、したがって、技術的に有効であっても、それは依然として伝搬されず、ブロックチェーン１５０に含まれない（マイナープロトコルは、マイナー１０４Ｍが望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、マイニング手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の差が自動的に勝利マイナー１０４に与えられる。例えば、ＵＴＸＯ₀へのポインタがＴｘ₁への唯一の入力であり、Ｔｘ₁は唯一の出力ＵＴＸＯ₁を有するとする。ＵＴＸＯ₀で指定されているデジタル資産の額がＵＴＸＯ₁で指定されている額より大きい場合、その差が自動的に勝利マイナー１０４Ｍに贈られる。しかしながら、代替的にまたは追加的に、マイナー手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることは必ずしも除外されない。

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

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

スクリプトコードは、しばしば、概略的に表される（すなわち、正確な言語ではない）ことに留意されたい。例えば、[Checksig P_A]と書くと、[Checksig P_A] = OP_DUP OP_HASH160 <H(P_A)> OP_EQUALVERIFY OP_CHECKSIGを意味し得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。ＯＰ＿ＣＨＥＣＫＳＩＧ（「Checksig」とも呼ばれる）は、２つの入力（署名および公開鍵）を取り、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）を使用して署名の有効性を検証するスクリプトオペコードである。実行時に、署名（「sig」）の存在（occurrence）はスクリプトから除去されるが、ハッシュパズルなどの追加要件は、「ｓｉｇ」入力によって検証されたトランザクションに残る。別の例として、ＯＰ＿ＲＥＴＵＲＮは、トランザクション内にメタデータを格納することができ、それによってメタデータをブロックチェーン１５０に不変に記録することができる、トランザクションの使用不可能な出力を作成するためのスクリプト言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望まれる文書を含み得る。

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

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

図３は、ブロックチェーン１５０を実装するためのさらなるシステム１００を示す。システム１００は、追加の通信機能が含まれることを除いて、図１に関連して説明したものと実質的に同じである。アリスおよびボブのそれぞれのコンピュータ機器１０２ａ、１２０ｂ上のクライアントアプリケーションは、それぞれ、追加の通信機能を含む。すなわち、これは、（いずれかの当事者または第三者の指示で）アリス１０３ａがボブ１０３ｂとの別個のサイドチャネル３０１を確立することを可能にする。サイドチャネル３０１は、Ｐ２Ｐネットワークとは別でのデータの交換を可能にする。このような通信は、「オフチェーン」と呼ばれることがある。例えば、これは、当事者の一方がトランザクションをネットワーク１０６にブロードキャストすることを選択するまで、トランザクションが（まだ）ネットワークＰ２Ｐ１０６上に公開されたりチェーン１５０上に進んだりすることなくことなく、アリスとボブとの間でトランザクション１５２を交換するために使用され得る。代替的にまたは追加的に、サイドチャネル３０１は、鍵、交渉された額または条件、データコンテンツなどの任意の他のトランザクション関連データを交換するために使用され得る。

サイドチャネル３０１は、Ｐ２Ｐオーバーレイネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立され得る。代替的にまたは追加的に、サイドチャネル３０１は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはアリスのデバイス１０２ａとボブのデバイス１０２ｂとの間の直接の有線またはワイヤレスリンクを介して確立され得る。一般に、本明細書のどこかで参照されるサイドチャネル３０１は、「オフチェーン」すなわちＰ２Ｐオーバーレイネットワーク１０６とは別でデータを交換するための１つまたは複数のネットワーキング技術または通信媒体を介した任意の１つまたは複数のリンクを含み得る。２つ以上のリンクが使用される場合、全体としてのオフチェーンリンクの束または集合がサイドチャネル３０１と呼ばれ得る。したがって、アリスおよびボブがサイドチャネル３０１上で情報またはデータの特定の部分などを交換するといわれている場合、これは、これらのデータの部分のすべてが全く同じリンクまたは同じタイプのネットワーク上で送信されなければならないことを必ずしも意味するものではないことに留意されたい。

クライアントソフトウェア
図４Ａは、本明細書で開示される方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１とユーザインターフェース（ＵＩ）層４０２とを含む。トランザクションエンジン４０１は、上述した方式にしたがって、また、後でさらに詳細に述べるように、例えば、トランザクション１５２を定式化すること、サイドチャネル３０１を介してトランザクションおよび／もしくは他のデータを受信および／もしくは送信すること、ならびに／またはＰ２Ｐネットワーク１０６を通して伝搬されるためにトランザクションを送信することなど、クライアント１０５の基礎となるトランザクション関連機能を実装するように構成される。本明細書に開示される実施形態によれば、各クライアント１０５のトランザクションエンジン４０１は、１つまたは複数のシングルユーストークンを含むトランザクションを生成するための機能４０３を含む。

ＵＩ層４０２は、それぞれのユーザのコンピュータ機器１０２のユーザ入力／出力（Ｉ／Ｏ）手段を介してユーザインターフェースをレンダリングするように構成され、これは、機器１０２のユーザ出力手段を介してそれぞれのユーザ１０３に情報を出力すること、および機器１０２のユーザ入力手段を介してそれぞれのユーザ１０３から入力を受信することを含む。例えば、ユーザ出力手段は、視覚出力を提供するための１つまたは複数のディスプレイスクリーン（タッチスクリーンまたは非タッチスクリーン）、音声出力を提供するための１つまたは複数のスピーカ、および／または触覚出力を提供するための１つまたは複数の触覚出力デバイスなどを含み得る。ユーザ入力手段は、例えば、１つまたは複数のタッチスクリーン（出力手段に使用されるもの／それらと同じまたは異なる）の入力アレイ、マウス、トラックパッドまたはトラックボールなどの１つまたは複数のカーソルベースのデバイス、スピーチまたは音声入力を受信するための１つまたは複数のマイクロフォンおよびスピーチまたは音声認識アルゴリズム、手動または身体ジェスチャの形態で入力を受信するための１つまたは複数のジェスチャベースの入力デバイス、または１つまたは複数の機械式ボタン、スイッチまたはジョイスティックなどを含み得る。

本明細書の様々な機能は、同じクライアントアプリケーション１０５に統合されるものとして説明され得るが、これは必ずしも限定するものではなく、代わりに、２つ以上の別個のアプリケーション一式、例えば、一方が他方へのプラグインであるか、またはＡＰＩ（アプリケーションプログラミングインターフェース）を介してインターフェースするものとして実装され得ることに留意されたい。例えば、トランザクションエンジン４０１の機能は、ＵＩ層４０２とは別個のアプリケーションにおいて実装され得るか、またはトランザクションエンジン４０１などの所与のモジュールの機能は、２つ以上のアプリケーション間で分割され得る。また、説明される機能の一部または全部が、例えば、オペレーティングシステム層において実装され得ることも除外されない。本明細書のどこかで単一のまたは所与のアプリケーション１０５などを参照する場合、これは単なる例であり、より一般的には、説明される機能は任意の形態のソフトウェアで実装され得ることが理解されよう。

図４Ｂは、アリスの機器１０２ａ上のクライアントアプリケーション１０５ａのＵＩ層４０２によってレンダリングされ得るユーザインターフェース（ＵＩ）４００の例のモックアップを示す。同様のＵＩが、ボブの機器１０２ｂ上のクライアント１０５ｂによって、または任意の他の当事者のものによってレンダリングされ得ることが理解されよう。

例示として、図４Ｂは、アリスの視点からのＵＩ４００を示す。ＵＩ４００は、ユーザ出力手段を介して別個のＵＩ要素としてレンダリングされる１つまたは複数のＵＩ要素４１１、４１２、４１３を含み得る。

例えば、ＵＩ要素は、異なるスクリーン上ボタン、またはメニュー内の異なるオプションなどであり得る１つまたは複数のユーザ選択可能要素４１１を含み得る。ユーザ入力手段は、ユーザ１０３（この場合ではアリス１０３ａ）が、スクリーン上でＵＩ要素をクリックまたはタッチすること、または所望のオプションの名称を発声することなどによって、オプションのうちの１つを選択することまたは他の方法で操作することを可能にするように構成される（注意：本明細書で使用される「手動」という用語は、自動と対比するためにのみ意図されており、必ずしも１つまたは複数の手の使用に限定されない）。オプションにより、ユーザ（アリス）は、シングルユーストークンを有するトランザクションを生成すること、ならびにトークンのルール、条件（terms）および／または条件（conditions）を定義することができる。

代替的にまたは追加的に、ＵＩ要素は、ユーザがトークントランザクションを生成することができる１つまたは複数のデータ入力フィールド４１２を含み得る。これらのデータ入力フィールドは、例えば画面上に、ユーザ出力手段を介してレンダリングされ、ユーザ入力手段、例えばキーボードまたはタッチスクリーンを通してデータがフィールドに入力され得る。代替的に、データは、例えばスピーチ認識に基づいて口述で受信され得る。

代替的にまたは追加的に、ＵＩ要素は、ユーザに情報を出力するために出力される１つまたは複数の情報要素４１３を含んでもよい。例えば、これ／これらは、スクリーン上にまたは聞こえるようにレンダリングされ得る。

様々なＵＩ要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことが理解されよう。これらのＵＩ要素の機能については、後でより詳細に説明する。図４Ｂに示されるＵＩ４００は単に図式化されたモックアップであり、実際には、簡潔にするために図示されていない１つまたは複数のさらなるＵＩ要素を含み得ることも理解されよう。

ノードソフトウェア
図５は、ＵＴＸＯまたは出力ベースのモデルの例において、Ｐ２Ｐネットワーク１０６の各ノード１０４上で実行されるノードソフトウェア５００の例を示す。ノードソフトウェア５００は、プロトコルエンジン５０１と、スクリプトエンジン５０２と、スタック５０３と、アプリケーションレベル決定エンジン５０４と、１つまたは複数のブロックチェーン関連機能モジュール５０５のセットとを含む。任意の所与のノード１０４において、これらは、マイニングモジュール５０５Ｍ、フォワーディングモジュール５０５Ｆ、および格納モジュール５０５Ｓのうちのいずれか１つ、２つ、または３つすべてを含み得る（ノードの１つまたは複数の役割に応じて）。プロトコルエンジン４０１は、トランザクション１５２の異なるフィールドを認識し、ノードプロトコルにしたがってそれらを処理するように構成される。別の先行するトランザクション１５２i（Ｔｘ_m-1）の出力（例えば、ＵＴＸＯ）を指し示す入力を有するトランザクション１５２ｊ（Ｔｘ_j）が受信されると、プロトコルエンジン５０１は、Ｔｘ_j内のロック解除スクリプトを識別し、それをスクリプトエンジン５０２に渡す。プロトコルエンジン５０１はまた、Ｔｘ_jの入力内のポインタに基づいて、Ｔｘ_iを識別し、取り出す。それは、Ｔｘ_iがまだブロックチェーン１５０上にない場合には保留中のトランザクションのそれぞれのノード自体のプール１５４から、またはＴｘ_iがすでにブロックチェーン１５０上にある場合にはそれぞれのノードまたは別のノード１０４に格納されたブロックチェーン１５０内のブロック１５１のコピーからＴｘ_iを取り出し得る。いずれにしても、スクリプトエンジン５０１は、Ｔｘ_iの指し示された出力におけるロックスクリプトを識別し、これをスクリプトエンジン５０２に渡す。

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

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

出力ベースのモデルでは、スクリプトエンジン５０２からの結果「真」は、トランザクションの有効性の条件のうちの１つである。典型的には、Ｔｘ_jの出力（複数可）で指定されているデジタル資産の総額がその入力（によって指し示された総額を超えないこと、およびＴｘ_iの指し示された出力が別の有効なトランザクションによってまだ使用されていないことなど、同様に満たされなければならないプロトコルエンジン５０１によって評価される１つまたは複数のさらなるプロトコルレベル条件も存在する。プロトコルエンジン５０１は、スクリプトエンジン５０２からの結果を１つまたは複数のプロトコルレベル条件と共に評価し、それらがすべて真である場合にのみ、トランザクションＴｘ_jを妥当性確認する。プロトコルエンジン５０１は、トランザクションが有効であるかどうかの指示をアプリケーションレベル決定エンジン５０４に出力する。Ｔｘ_jが実際に妥当性確認されるという条件でのみ、決定エンジン５０４は、Ｔｘ_jに関してそれぞれのブロックチェーン関連機能を実行するために、マイニングモジュール５０５Ｍおよびフォワーディングモジュール５０５Ｆの一方または両方を制御することを選択し得る。これは、マイニングモジュール５０５Ｍが、ブロック１５１にマイニングするためにＴｘ_jをノードのそれぞれのプール１５４に追加すること、および／またはフォワーディングモジュール４５５ＦがＴｘ_jをＰ２Ｐネットワーク１０６内の別のノード１０４にフォワードすることを含み得る。しかしながら、実施形態では、決定エンジン５０４は無効なトランザクションをフォワードまたはマイニングすることを選択しないが、これは、逆に、単に有効であるという理由で有効なトランザクションのマイニングまたはフォワードをトリガする義務があることを必ずしも意味するものではないことに留意されたい。任意選択で、実施形態では、アプリケーションレベル決定エンジン５０４は、これらの機能のいずれかまたは両方をトリガする前に、１つまたは複数の追加の条件を適用し得る。例えば、ノードがマイニングノード１０４Ｍである場合、決定エンジンは、トランザクションが有効であり、かつ十分なマイニング手数料を残しているという条件でのみトランザクションをマイニングすることを選択し得る。

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

シングルユーストークン
図６は、ブロックチェーントランザクションを使用してシングルユーストークンを発行する方法を提供する本発明の実施形態を実装するための例示的なシステム６００を示す。示されるように、トークン発行者６０１は、トークントランザクションＴｘ_tokenを生成し、ブロックチェーン１５０に記録されるようにトークントランザクションＴｘ_tokenをブロックチェーンネットワーク１０６に送信する。トークントランザクションＴｘ_tokenは、シングルユーストークン、すなわちシングルユーストークンを表すデータを含む少なくとも１つの出力を含む。トークントランザクションＴｘ_tokenはまた、トークン発行者６０１の署名、すなわちトークン発行者の公開鍵に対応する秘密鍵に基づいて生成されたデジタル署名を含む入力を含む。署名は、シングルユーストークンを含む出力のうちの１つ、いくつか、またはすべてに署名する。トークン償還者６０２は、トークントランザクションＴｘ_token内のシングルユーストークンを償還する償還トランザクションＴｘ_redeemを生成し、ブロックチェーン１５０に記録されるように償還トランザクションＴｘ_redeemをブロックチェーンネットワーク１０６に送信する。

トークン発行者６０１は、図１～図３を参照してアリス１０３ａと呼ばれる当事者と同じであってもよい。すなわち、トークン発行者６０１は、クライアントアプリケーション１０５ａを実行するコンピュータ機器１０２ａを動作させ得、アリス１０３ａに帰する任意の動作を実行し得る。同様に、トークン償還者６０２は、図１～図３を参照してボブ１０３ａと呼ばれる当事者と同じであってもよい。すなわち、トークン償還者６０２は、クライアントアプリケーション１０５ｂを実行するコンピュータ機器１０２ｂを動作させ得、ボブ１０３ｂに帰する任意の動作を実行し得る。

いくつかの例では、図６に示すように、トークン発行者６０１は、シングルユーストークンの償還と引き換えに有形資産をトークン償還者６０２に発行する当事者である。例えば、トークン発行者６０１は、商品および／またはサービスのサプライヤであり得、トークン償還者６０２は、そのサプライヤの顧客であり得る。トークン発行者６０１は、トークン償還者にトークンを発行し、トークン償還者６０２がトークンを使用するとき、トークン発行者６０１は、引き換えにトークン償還者６０２に何かを与える。

他の例では、トークン発行者６０１は、シングルユーストークンの償還と引き換えに無形資産をトークン償還者６０２に発行する当事者である。シングルユーストークンは、無形資産の所有権を表し得る。例えば、シングルユーストークンは、償還トランザクションＴｘ_redeemを介してシングルユーストークンを償還することによってトークン償還者６０２が投じることができる投票の所有権を表し得る。

いくつかの例では、トークン償還者６０２は、シングルユーストークンが使用されるときに第三者（図６には図示せず）に資産を提供し得る。例えば、第三者は、シングルユーストランザクションの償還に必要とされる情報（例えば、トークントランザクションのトランザクション識別子ＴｘＩＤ）をトークン償還者６０２に提供し得、引き換えに、トークン償還者６０２は、その第三者に商品またはサービスを提供する。これの利点は、償還トランザクションが、第三者が商品またはサービスを受け取ったことの不変の記録として機能することである。

トークントランザクションは、１つまたは複数のシングルユーストークンを含む。各シングルユーストークンは、トークントランザクションの別個の出力に含まれ、各シングルユーストークンは、トークントランザクションの別個の使用可能な出力に関連付けられる。したがって、トークントランザクションがブロックチェーンネットワーク１０６のノードに送信され、ブロックチェーン１５０に記録されるとき、各シングルユーストークンは、別個の未使用トランザクション出力（ＵＴＸＯ）にリンクされる。ＵＴＸＯベースのブロックチェーンは、本来、シングルユーストランザクションの特性を有する。マイニングノードは、トランザクションの二重支出がないことを確実にするようにインセンティブが与えられる。したがって、ＵＴＸＯにリンクされた任意のトークンが２回以上使用されることはない。

トークン（すなわちトークンデータ）は暗号化され得る。例えば、トークンデータは、トークン発行者６０１またはトークン償還者６０２の秘密鍵、またはトークン発行者６０１およびトークン償還者６０２の両方に知られている共通のシークレットを使用して暗号化され得る。代替的に、トークンは、トークンデータのハッシュであってもよい。

トークンをＵＴＸＯにリンクする（または関連付ける）ための方法は２つある。第１に、シングルユーストークンは、トークントランザクションの使用不可能な出力、例えばＯＰ＿ＲＥＴＵＲＮペイロード内に埋め込まれ得る。使用不可能な出力は、使用することができない、すなわちロック解除されない。この第１の方法は、トークンをＵＴＸＯに間接的にリンクまたは関連付ける。以下の表は、使用不可能な出力内にシングルユーストークンを埋め込むトークントランザクションを示す。

トークン発行者６０１は、トランザクションを生成し、トークンを発行することができる。トランザクションは、少なくとも１つの入力と２つの出力とを有する。第１の出力は、使用可能な出力である。第１の出力のステータスは、シングルユーストークンの有効性を表す。第１の出力が使用済みである場合、トークンは使用されたものと見なされる。第１の出力が未使用である場合、トークンは依然として使用に有効である。出力は、ＴＸＩＤ₁||０と識別され得る。第２の出力は、トークンに関するすべての情報を含む使用不可能な出力である。例えば、トークン発行者６０１は、トークンの諸条件を第２の出力に入れ得る。

入力、より正確には入力内の署名は、２つの出力をリンクする。トークン発行者６０１は、トランザクションに署名して、第１の出力が第２の出力に関連付けられている（すなわち、リンクされている）ことを認め得る。

「[何らかのロックスクリプト]」の一例は、以下の通りである：
OP_HASH256 <h₁> OP_EQUALVERIFY [P2PKH P_A]
ここで、ｈ₁はＯＰ＿ＲＥＴＵＲＮペイロードのハッシュ値であり、Ｐ_Aはトークン償還者６０２または第三者の公開鍵である。ロックスクリプトにハッシュパズルを含めることにより、トークンとＵＴＸＯとの間のリンケージが強化される。

トークン発行者６０１は、トークントランザクションのトランザクション識別子をトークン償還者６０２に発行し得る。

第２に、シングルユーストークンは、トークントランザクションの使用可能な出力内に埋め込まれ得る。したがって、トークンは、使用可能な出力内にトークンが含まれるという点で、使用可能な出力に直接関連付けられる。例えば、トークンは、ＯＰ＿ＰＵＳＨＤＡＴＡオペコードとＯＰ＿ＤＲＯＰオペコードとの間に配置され得る。オペコードは、トランザクションのロックスクリプトまたはロック解除スクリプト内に含まれるデータに対して動作するオペレーションコードである。例えば、オペコードは、スタック（例えば、代替スタック）にデータをプッシュ（すなわち、追加）し、スタックからデータをドロップ（すなわち、除去）し、またはスタック上のデータに対して関数（例えば、加算、減算、ハッシュなど）を実行し得る。当業者は、オペコード自体に精通しているであろう。第２の方法は、シングルユーストークンをＵＴＸＯと直接リンクする。第１の方法（すなわち、トークンを使用不可能な出力とリンクすること）とは異なり、リンケージのレベルは、トランザクションレベルではなく出力レベルである。以下の表は、使用可能な出力内にシングルユーストークンを埋め込むトークントランザクションを示す。

この特定の例示的なトランザクションは、１つの入力と１つの出力とを有する。出力は、ロックスクリプト内のトークンに関する情報を含む。入力は、トークンとＵＴＸＯとの間のリンケージを認めるトークン発行者６０１からの署名を含む。前述のように、ＵＴＸＯが使用済みである場合、トークンは使用され、再び使用することはできない。ＵＴＸＯが未使用である場合、トークンは依然として使用に有効である。

ロックスクリプトの一例を以下に示す：
<Token Data> OP_DROP [1-out-2 MultiSig K_issuer PK_A]

ロックスクリプトの最後の部分は、トークン発行者６０１またはトークン償還者６０２のいずれかがＵＴＸＯを使用することを可能にするためのものである。トークン償還者６０２がトークンを使用する場合、トークンの使用または償還を反映するためにＵＴＸＯを使うことが期待される。トークン発行者６０１はまた、トークンが使用または失効されたことを示すためにＵＴＸＯを使用する当事者にもなり得る。より高度なロックスクリプトを使用して、異なる要件のシナリオに適合させることができる。

トークン発行者６０１は、トークントランザクションのトランザクション識別子をトークン償還者６０２に発行し得る。トークン発行者６０１はまた、トークントランザクションの特定の出力の識別子を提供し得る。

これらの実施形態では、単一のトークントランザクションが複数のシングルユーストークンを含むことができる。すなわち、トークントランザクションは、それぞれがシングルユーストークンを含む複数の使用可能な出力を含み得る。各トークンは、それが含まれる使用可能な出力（ＵＴＸＯ）に関連付けられる。したがって、所与のトークンの有効性は、出力がＵＴＸＯセット内にあること、すなわち出力が使用されたか否かのみに依存する。

シングルユーストークンに関連付けられた使用可能な出力のうちの１つ、いくつか、またはすべて（シングルユーストークンを含むか否かにかかわらず）は、トークン発行者６０１の公開鍵および／またはトークン償還者６０２の公開鍵にロックされ得る。例えば、使用可能な出力は、トークン発行者６０１の公開鍵、またはトークン償還者６０２の公開鍵、または第三者の公開鍵にロックされたpay-to-public-key-hash（Ｐ２ＰＫＨ）出力であり得る。Ｐ２ＰＫＨ出力は、公開鍵のハッシュ（公開鍵ハッシュ）を含み、償還トランザクションの入力が、必ずしもその順序である必要はないが、公開鍵ハッシュにハッシュする公開鍵を、その公開鍵を使用して生成された署名と共に含むことを必要とする。代替的に、使用可能な出力は、トークン発行者６０１およびトークン償還者６０２のそれぞれの公開鍵の一方または両方にロックされたマルチシグネチャ出力であってもよい。マルチシグネチャ出力は、全部でｍ個の公開鍵を含むｎ－ｏｆ－ｍ出力であり、償還トランザクションの入力が、マルチシグネチャ出力内の公開鍵に対応する（すなわち、それ対応する秘密鍵に基づいて生成される）少なくともｎ個の署名を含むことを必要とする。同じ公開鍵が出力に２回以上含まれてもよい。

いくつかの例では、使用可能な出力は、シングルユーストークンのハッシュを含み得る。トークントランザクションが複数のトークンを含む実施形態では、各使用可能な出力は、そのそれぞれのトークンのハッシュを含み得る。使用可能な出力は、償還トランザクションの入力が、ハッシュのプレイメージ、すなわちトークンデータを含むことを必要とし得る。

いくつかの例では、トークン発行者６０１は、トークントランザクションに署名する唯一の当事者であり得る。例えば、トークン発行者６０１は、トランザクション全体に署名する単一の入力を含む。別の例として、トークン発行者は、単一の入力内に複数の署名を含み得る。各署名は、異なる署名フラグを有し得、すなわち、各署名は、異なる数の入力および／または出力に署名し得、したがって、異なるメッセージに署名し得る。署名フラグは、署名がトランザクションのどの部分に署名するかを示す。デフォルトはＳＩＧＨＡＳＨ＿ＡＬＬであり、トランザクションのすべての部分に署名する。トランザクションの署名されていない部分は修正され得る。ＳＩＧＨＡＳＨ＿ＮＯＮＥは、入力のみ署名され、誰でも出力を追加または変更できることをシグナリングする。ＳＩＧＨＡＳＨ＿ＳＩＮＧＬＥは、すべての入力および対応する出力が署名され、すなわち、第１の入力内の署名が第１の出力に署名することをシグナリングする。

トークン発行者６０１はまた、複数の入力を含み得、それぞれが別個の出力に署名する。トークン発行者６０１は、代わりに、複数の入力を含み得、ここで、１つの入力に署名するものと、すべての入力に署名するものがある。後述するように、トランザクションの異なる部分に署名するために異なる署名フラグが使用され得る。

トークン発行者６０１がトークントランザクションに複数の署名を含む場合（それらが同じ入力に含まれるか異なる入力に含まれるかにかかわらず）、署名は、互いにリンクされた公開鍵に基づいて生成され得る。例えば、第２の公開鍵は、第１の公開鍵、例えば証明された公開鍵に基づいて生成され得、第１および第２の公開鍵（またはむしろ対応する秘密鍵）は、複数の署名、すなわち、第１の公開鍵に基づく第１の署名および第２の公開鍵に基づく第２の署名を生成するために使用される。代替的に、第２の公開鍵は、第１の公開鍵を第３の公開鍵（例えば、証明された公開鍵）に追加することによって生成されてもよく、第１および第２の公開鍵（またはむしろ対応する秘密鍵）は、複数の署名を生成するために使用される。

他の例では、トークン発行者６０１は、トークントランザクションに署名する１つまたは複数の入力を含め得、異なる当事者（例えば、第２のトークン発行者）も、トークントランザクションに署名する１つまたは複数の入力を含め得る。例えば、第２のトークン発行者は、トークントランザクションに署名することによって、トークンを発行する権限を第１のトークン発行者６０１に与えることができる。

第２の異なるトークン発行者は、入力に第２のトークン発行者の署名を含めるトークントランザクションテンプレートを生成し得る。次いで、第２のトークン発行者は、第１のトークン発行者６０１の署名を含む入力を追加する第１のトークン発行者６０１にテンプレートトランザクションを送信し得る。

シングルユーストークンを更新またはキャンセルするために、トークン発行者６０１は、それぞれ更新トランザクションまたはキャンセルトランザクションを生成し得る。更新トランザクションまたはキャンセルトランザクションの入力は、更新またはキャンセルされるべきトークンに関連付けられた出力を参照し、参照された出力をロック解除するために必要なデータ、例えば署名、プレイメージなどを含む。トークンが更新される場合、更新トランザクションは、更新されたシングルユーストークンを含む。トークンがキャンセルされる場合、キャンセルトランザクションは、トークンがキャンセルされたことをシグナリングするデータを含む。

例示的な使用事例１－医療処方箋
以下は、トレーサビリティおよび患者の秘密保持を達成するためにオンチェーンでどのようにして医療処方箋が発行され得るかを説明する。

主要のアクタ
・ 患者
・ 処方者
・ 薬剤師
・ 信頼できる機関
・ 医療データベース（Medical_DB）

主要段階
・ 処方者が自身のクレデンシャルを登録
・ 処方者が処方トランザクション（すなわちトークントランザクション）に署名
・ 患者が処方箋を償還／薬剤師が処方箋を調剤
・ 処方者が処方箋をキャンセルまたは修正

要件
１．患者のアイデンティティ（identity）の秘密保持：公開されているおよび非認可アクタは、患者ＩＤを処方箋とリンクさせることができるべきではない。
２．患者は、自身の個人識別可能情報を正すまたは消去する権利を有することができる。
３．処方者は、患者のアイデンティティをチェックすることができるべきである。
４．処方箋は、認可された処方者によってのみ発行されるべきである。薬剤師および監査人は、この許可をチェックすることができるべきである。
５．認可されたシステムアクタは、安全な方法で患者の処方履歴にアクセスすることができるべきである。
６．薬使用データベースまたは在庫データベースをチェックすることができ、過剰使用を検出するべきである。
７．処方者、薬剤師、および患者などのアクタは、それに応じて認証および認可されるべきである。
８．認可された処方者は、まだ調剤も償還もされていない処方箋を修正／キャンセルすることができるべきである。
９．処方箋は、認可された薬剤師によってのみ調剤されるべきである。
１０．処方者は、患者が通信に関与することなく、患者の指名の薬局に処方箋を直接送信することができる。

例示的なシステムの要件を図７に示す。

通常、処方箋データは個人識別情報（ＰＩＩ：personal identifying information）を含む。典型的な処方箋には以下が含まれ得る：
・ 患者の名前、生年月日、住所
・ 薬の名前および数量
・ 患者および薬剤師のための注意事項
・ 処方箋の日付
・ 処方者の名前

ブロックチェーン上に処方箋データをアップロードすることで、一般にブロックチェーンデータストレージの可用性、不変性、および透明性の特徴から利益を享受する。最も重要なのは、ブロックチェーンが二重支出を防止する能力である。個人識別情報（ＰＩＩ）は、公開されている許可不要のブロックチェーン上に保持されるべきではない。患者の秘密保持も別の重要な法的要件であり、これは、認可されたアクセスのみがＰＩＩに与えられることを意味する。これらの要件を満たすソリューションは、ＰＩＩではない処方箋データの一部のみをブロックチェーンに格納することである。これは、以下の特徴を有する：
１）患者の名前、生年月日、および住所などのＰＩＩはブロックチェーン上に格納されない
２）薬の名前および数量などのＰＩＩではない処方箋データ、ならびに処方箋の日付はチェーンに格納される
３）患者のウォレットは、異なるトランザクションに対して異なる受信アドレス、すなわちワンタイムアドレスＰ_OTAを使用することができる
４）患者のアイデンティティとそれらのトランザクションアドレスとの間のリンクは、オフチェーンで、信頼できるサーバ上に保持される。薬剤師または処方者が患者のＩＤを認証する必要がある場合、アドレスが患者のウォレットに由来するかどうかをチェックする必要がある。次いで、信頼できるサーバは、認可されたアクタに対して患者を識別および／または認証することとなる。

これにより、監査可能性、可用性、および完全性を提供するシステムを有しながらも、すべての使用事例の要件が満たされるであろう。加えて、信頼できる機関は、以下のタスクを実行し得る：
１．ユーザ（患者、処方者、および薬剤師を含む）の登録。これは、識別、認証、および認可チェックを実行することを含む。
２．ユーザの公開鍵証明書の管理。これは、ユーザのアイデンティティおよび役割をそれらの公開鍵にマッピングする証明書、認可された範囲（例えばユーザが処方することを許可された薬）をユーザに提供する証明書、ならびに病院およびMedical_DBなどの他のエンティティのための証明書に署名すること、更新すること、および失効させることを含む。
３．患者のアイデンティティとそれらのウォレットアドレスとをマッピングするデータへのアクセスの制御。このデータはMedical_DBに格納される。

Medical_DB８０２は、信頼できる機関８０１によって管理される安全なデータベースである。Medical_DBは、以下の機能を実行する：
１．患者のアイデンティティとそれらの公開鍵との間のリンクを格納する。これは、患者のＰＩＩおよび患者のトランザクションの履歴を格納することを含む。
２．トランザクション処方箋作成中に処方箋チェックを行う。これらは以下をチェックすることを含む：
ａ．処方者の認可
ｂ．患者の識別および認証
ｃ．患者の病歴。
３．処方箋がチェックにパスした場合、Medical_DB８０２は、処方トランザクションに、処方者６０１と共同署名する。
４．ブロックチェーンと対話して、患者の病歴を抽出する。

信頼できる機関およびMedical_DB８０２の使用事例図が図８に示されている。

説明されるシステムでは、認可されたアクタが、それらの役割および属性にしたがって異なるアクションを行うことができる。これは、事実上、属性ベースのアクセス制御モデルである。例えば：
・ 処方者は患者の病歴を検索することができる
・ 処方者は患者の識別情報（identification）をチェックし、認証チェックを実行することができる
・ 処方者は処方トランザクションを作成し署名することができる
・ 患者は自身の処方履歴をチェックすることができる
・ 患者は、償還トランザクションに共同署名することができる。

図９および図１０は、処方者（トークン発行者６０１）およびMedical_DB８０２が患者６０２に処方箋を発行する場合の例示的なシーケンス図を示す。この例では、Medical_DB８０２は、処方者６０１を認証し、処方トランザクションに処方者６０１と共同署名する信頼できる機関であると仮定される。患者（トークン償還者６０２）は処方箋を償還し、薬剤師は処方箋を調剤する。すなわち、患者６０２は、処方トランザクション（トークントランザクション）を使用することによって処方箋を回収する。

より詳細には、図９に示すように、処方者６０１は、最初に、患者６０２からウォレットアドレスを取得する。Medical_DB８０２と認証し、処方箋がチェックされ検証された後、処方者６０１およびMedical_DB８０２は、シングルユース処方箋を含む処方トランザクション（トークントランザクションに相当）を生成する。処方者６０１およびMedical_DB８０２の両方は、それぞれの署名をトランザクションに含める。次いで、処方者６０１は、処方トランザクションをブロックチェーンにサブミットする。

図１０に示すように、患者６０２は、処方箋を含む処方トランザクションを薬剤師１００１に提供する。薬剤師は、Medical_DB８０２の署名をチェックする。薬剤師１００１は、患者６０２にウォレットアドレスを提供し、次いで、患者６０２は、薬剤師のウォレットアドレスに送信される償還トランザクションを生成する。薬剤師１００１は、償還トランザクションに署名することもできる。患者６０２または薬剤師１００１は、償還トランザクションをブロックチェーンにサブミットし、引き換えに、薬剤師は、処方薬を患者６０２に提供する。

いくつかの例では、処方者（トークン発行者６０１）は、信頼できる機関に、例えば、処方者を登録し、許可された薬のセットに対して処方者を認可するオンチェーンの認証局（ＣＡ）８０１に登録する必要があり得る。ブロックチェーンを使用してそのようなシステムを実現することができる様々な方法がある。ＣＡ８０１は、トランザクション
内の処方者の証明書を認証および認可する。証明書の鍵は、そのトランザクション
出力が未使用である限り有効である。証明書の更新および失効は、トランザクション出力を使用することによって行われる。

処方者アリス６０１が自身のウォレットの証明を受けるために、以下を実行する：

アリスは、１つの公開鍵のみがＣＡによって証明されることを必要とする。他のすべての鍵は証明可能な方法でリンクされ得る。
は、ネットワークに自由にブロードキャストされ得る。これがトランザクションへの署名に使用されることはない。

公開鍵証明書の公開鍵にリンク可能なデジタル署名を、以下ではリンク可能な署名と呼ぶ。署名者は、２つのデジタル署名を使用してメッセージに署名するためにリンク可能な署名を使用し、その公開鍵は、上述したようにＰ_Aiおよび
である。リンク可能なデジタル署名のセットは、以下の形態であり得る；

好ましくは、ＳＩＧＨＡＳＨフラグは、２つのＯＰ＿ＣＨＥＣＫＳＩＧにおいて同じであるべきではなく、同じ場合には、安全なランダム鍵生成器が適切に実装されない実装形態において署名者の秘密鍵を危険にさらす可能性がある。

以下では、リンク可能な署名という用語は、上記の形態のうちの１つを指す。証明トランザクション
は、以下のように、信頼できる機関によって生成され得る。

登録トランザクションを参照する例示的な処方トランザクションが以下に示される。

処方者アリスは、リンク可能な署名のペアを使用してＴｘＩＤ_{prescription-1}に署名する。アリスは、自身の有効な
への参照をＯＰ＿ＲＥＴＵＲＮ出力に挿入する。アリスは処方箋データも挿入する。

ＴｘＩＤ_{prescription-1}の第１の出力は、処方箋を償還するときに患者によって使用されるか、またはそれを失効させるときに処方者によって使用される。ＴｘＩＤ_{prescription-1}が認可された処方者によって署名されているかどうかをチェックするために、当事者（例えば薬剤師）は以下を実行する：

［患者の署名または処方者のリンク可能な署名によって使用可能なロックスクリプト]の例は、以下であり得る：
<m=1><P_{_A}><P_POTA> <n=2>OP_CHECKMULTISIGVERIFY
ここで、＜Ｐ_POTA＞は患者６０２のワンタイムアドレスであり、Ｐ_Aは処方者に属する。

［患者の署名または処方者のリンク可能な署名によって使用可能なロックスクリプト]の例は、以下であり得る：

処方トランザクションは、追加の信頼できる機関の署名（すなわち、第２の異なるトークン発行者）で生成され得る。処方トランザクションは、処方者６０１および「Medical DB」８０２と呼ばれる信頼できるエンティティによって署名される。この例では、処方者の署名は、検証するために薬剤師に知られていなくてもよい。したがって、薬剤師は、処方箋が認可された処方者によって署名されていることをチェックするために、Medical_DB署名に依存し得る。このシナリオは、図９および図１０で説明しているものである。一般に、Medical_DB署名は、以下のいずれかを証明するために使用され得る：
・ 認可された処方者によってトランザクションが処方されていること
・ トランザクション処方箋が償還可能であること
・ 患者が認証されること
・ 患者の病歴がチェックされていること

次いで、処方トランザクションは、以下によって与えられ得る：

トークン発行者の識別アドレスにより、薬剤師１００１は、トークン発行者／または信頼できる機関を識別することができる。これにより、薬剤師１００１は、処方箋がそのエンティティによって認可されていることをチェックすることができる。処方者６０１または患者のいずれかが、ＴｘＩＤ_prescription||０を使用することができる。処方者６０１は、それを使用して処方箋をキャンセルまたは更新し、患者６０２はそれを使用して処方箋を償還する。

患者６０２が薬剤師から自身の処方トランザクションを償還すると、償還トランザクションが作成される。その入力の１つは、ＴｘＩＤ_prescription||０内の使用可能な出力である。償還トランザクションは、患者６０２および薬剤師によって署名され得る。患者６０２は、プライバシーを保護するためにリンク可能な署名を使用して署名しないことに留意されたい。以下のトランザクションが生成され得る。

処方トランザクションがオンチェーンのＣＡを仮定している場合、薬剤師は以下のことをチェックする必要があるであろう：

時々、処方トランザクションをキャンセルまたは更新する必要がある場合がある。トークンデータが（ＯＰ＿ＲＥＴＵＲＮを使用して）使用不可能なトランザクション出力に埋め込まれていると仮定すると、トランザクションＴｘＩＤ_prescription||０の使用可能な出力を使用することによって、処方箋のキャンセルまたは更新が行われる。

処方箋のキャンセルは、処方トランザクションＴｘＩＤ_prescription||０が使用され、使用トランザクションの出力におけるフラグ「キャンセル」が処方箋のキャンセルを確認すると達成される。

処方箋の変更は、ＴｘＩＤ_prescription||０を使用し、使用トランザクションの出力にフラグ「更新」を有することによって達成され得る。新しい処方箋が出力に挿入される。フラグ「更新」を有するトランザクションが償還のために受け入れられるためには、それは、処方者のリンク可能な署名によって署名され、Medical_DBのリンク可能な署名によって共同署名されなければならない。

トークンデータが使用可能な出力に埋め込まれている場合、キャンセルおよび更新は、その出力を使用することによって達成される。

薬の処方および調剤の両方について１つのトランザクションを有することも可能である。このシナリオでは、処方者６０１は、ＳＩＧＨＡＳＨフラグSingle|AnyoneCanPayを使用してトランザクションに署名することができる。次いで、トランザクションは、患者６０２にオフチェーンで渡される。薬を調剤するとき、薬剤師のウォレットアドレスが出力に追加される。薬剤師はまた、トランザクションに署名しなければならず、したがって、自身の入力を追加しなければならないであろう。このトランザクションは、薬剤師１００１と処方者６０１との間の対話を必要とする場合がある。患者６０２に自分で選択した薬局を指名させ、その薬局に処方箋を直接送信することも可能である。このような構成の利点は、処方箋を注文して準備する時間を薬局が十分確保することができ、よりタイムリーに消耗品を管理することができることである。

この使用事例は、ブロックチェーンを活用して、監査可能であり、利用可能であり、不変である処方箋を記録するためのシステムを提供する。誰でも容易にブロックチェーンデータにアクセス可能であり、誰でもブロックチェーンをダウンロードすることができる。処方箋は、処方箋フラグの使用により、ブロックチェーン内で容易に識別され得る。これらの２つの点を組み合わせることは、不必要な障壁または許可なしに、誰でも単一セットの記録から処方箋メタデータを監視することができることを意味する。「分類された薬」の使用を監査することは、監査可能性を有する必要性に対する特定の動機付けであるが、プロトコルにより、すべての処方箋の監査可能性が有効になる。

説明した例は、以下の特徴を有する。
・ 薬の名前および数量ならびにそれらの処方箋の日付は、患者のアイデンティティなしに監査することができる。
・ 薬（分類されていようとなかろうと）は、処方者のアイデンティティおよび／または処方者６０１を認証および認可した医療機関に、反論不可能な方法でリンクされ得る。
・ オフチェーンのＰＩＩ患者データを組み合わせることによって、認可された人物に制御されたアクセスを許可して、患者の処方履歴をチェックすることができる。これらのチェックは、緊急事態の場合、および患者の病状により特定のタイプの処方が許可されない場合に極めて重要であり得る。
・ 処方者は、処方者が発行した薬、および処方者がそのような薬を発行する権限を与えられているかどうかに対してチェックされ得る。
・ 患者は、処方者および薬剤師ならびに任意の他の認可されたアクタによってプライバシーに配慮した方法で識別および認証され得る。これは、患者の個人データがパブリックドメイン上でアクセス可能になる危険を冒すことなく行われる。
・ 処方者と処方箋に共同署名するMedical_DBは、１）処方者６０１が資格を与えられ認可されていること、２）患者が適切に識別され認証されていること、および３）患者の処方履歴が署名されたトランザクション処方箋に対してチェックされていることを保証する。Medical_DB８０２は、それ自身のチェックが監査される。システムの透明性は、任意の間違った設定または間違った挙動が検出され、そのソースまで追跡され得ることを確実にする。
・ ポリシーが自動化され得、システムは、違反の場合に追跡し、フラグを立て、警報を発するように構成される。
・ 以下のように、処方箋の発行中に実施されるようにポリシーを自動化することができる：
－ 認可された処方者６０１からの追加の署名が必要とされる場合を除き、特定の薬から、妊娠中の患者および一部の疾患を持つ患者をブラックリストに載せること、および／または
－ 特定の量を超えて投与されないようにまたは他の薬と一緒に投与されないように薬をブラックリストに載せることと。

説明されるシステムは、薬局に薬を供給するサプライヤから患者６０２までずっと薬の追跡を提供するために使用され得る。これは以下のことを提案する。
・ 新しい薬が到着すると、薬のサプライヤ（トークン発行者）および薬剤師（第２のトークン発行者）は、トランザクションＴｘＩＤ_supply（トークントランザクション）を発行することとなる。ＴｘＩＤ_supplyは、リンク可能な署名を使用して、両方によって署名される。
・ トランザクションＴｘＩＤ_supplyは、薬剤師が受け取る薬のコードおよび数量についてのデータ（トークンデータ）を含むであろう。
・ トランザクション使用可能な出力は、償還トランザクションを使用して薬剤師の署名によって使用可能である。
・ 薬剤師によって保持される薬の在庫は、ＴｘＩＤ_redeemにおける数量からＴｘＩＤ_supplyにおける薬の数量を減算することによっていつでも計算され得る。

例示的な使用事例２－駐車
駐車場管理者、チャーリー（トークン発行者６０１）が顧客に駐車トークンを発行したいと仮定する。第１のステップは、チャーリーが、上記の２つの方法のうちの１つを使用して駐車トークンのリストを作成すること、すなわち、トークンを使用可能な出力または使用不可能な出力に含めることである。一般性を失うことなく、以下の例は、使用可能な出力にトークンを有するトークントランザクションを使用する。
アリスが車を１０時間駐車したい場合、チャーリーは以下のトランザクション（償還トランザクション）を作成する。
ここで、ＴＸＩＤ₃||０はチャーリーが生成した駐車トークンの１つを表し、ｈ_Aはアリスの車両登録番号のハッシュ値である。チャーリーは、毎回ハッシュ値を一意にするためにタイムスタンプを追加することができる。

アリスが出口でこのトランザクションを提示すると、ゲートキーパは以下を実行する:
１．入力において参照されるアウトポイントが未使用であることをチェック、
２．入力における署名の有効性をチェック、
３．車両登録番号のハッシュ値が出力のハッシュ値と一致するかをチェック、
４．アリスの実際の駐車時間の代金を請求するために新しいバージョンの（最大シーケンス番号を有するトランザクション）を作成。

アリスが１０時間を超えて駐車した場合、アリスが駐車場を離れる前に、ＴＸＩＤ₄が有効になり、マイナーによって受け入れられることに留意されたい。これによりチェック１が失敗に終わる。アリスが１０時間未満駐車した場合、ＴＸＩＤ₄は、そのロック時間により無効である。したがって、入力において参照されるアウトポイントは、依然としてまだ未使用である（チェック１がパスする）。チェック２および３の両方が良好である場合、ゲートキーパは最終トランザクションを作成する。

上記のトランザクションは、アリスが他の手段で駐車料金を支払うことを仮定している。しかしながら、アリスからのもう１つの入力をＴＸＩＤ₄に追加することによって、支払いを駐車トークンシステムに統合することができる。

２つのトランザクションのうちの第１のトランザクションにおいて、アリスは１０時間の駐車料金を支払う。後に、駐車が１０時間未満であった場合、アリスは依然としてトランザクションを更新することができ、実際に駐車した時間分だけの料金を支払う。また、アリスにＴＸＩＤ₄への署名を行わせることによって、それを使用して、アリスが前述の時間に実際に駐車場に入ったことを証明することができ、それは＜ｈ_A＞に含まれることに留意されたい。すなわち、アリスまたはチャーリーは、駐車場に入った時間に異議を唱えたい場合、それを使用することができる。

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

ステートメント１．ブロックチェーントランザクションを使用して、１つまたは複数のそれぞれのトークン償還者によって使用される１つまたは複数のシングルユーストークンを発行するコンピュータ実装方法であって、方法は、トークン発行者によって実行され、トークントランザクションを生成することと、ここで、トークントランザクションは、１つまたは複数のトークン出力であって、各トークン出力が、それぞれのシングルユーストークンを表すトークンデータを含み、各シングルユーストークンが、トークントランザクションのそれぞれの使用可能な出力に関連付けられ、各シングルユーストークンのそれぞれの有効性は、それぞれの使用可能な出力がブロックチェーンの未使用トランザクション出力セットに存在することを条件とする、１つまたは複数のトークン出力と、１つまたは複数の入力であって、入力のうちの少なくとも第１の入力が、トークン発行者の第１の公開鍵にリンクされた署名を含む、１つまたは複数の入力とを含み、ブロックチェーンに記録させるためにトークントランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信することとを含む方法。

ステートメン２．トークントランザクションが複数のトークン出力を含む、請求項１に記載の方法。

ステートメント３．各シングルユーストークンは、各トークン出力がそれぞれの使用可能なトランザクション出力であるという点で、それぞれの使用可能な出力に関連付けられる、ステートメント１またはステートメント２に記載の方法。

ステートメント４．１つまたは複数のトークン出力のうちの１つまたは複数はｍ－ｏｆ－ｎマルチシグネチャ出力であり、各ｍ－ｏｆ－ｎマルチシグネチャ出力は、トークン償還トランザクションの入力によってロック解除されるために、トークン償還トランザクションの入力が、ｎ個の公開鍵のそれぞれにリンクされた少なくともｍ個の署名を含まなければならないように構成される、ステートメント３に記載の方法。

ステートメント５．各ｍ－ｏｆ－ｎマルチシグネチャ出力は、トークン償還トランザクションの入力が、トークン償還者の第２の公開鍵にリンクされた署名および／またはトークン発行者の公開鍵にリンクされた署名を含むことを必要とする、ステートメント４に記載の方法。

第２の公開鍵は、第１の公開鍵と同じであってもよい。代替的に、第１の公開鍵と第２の公開鍵とは、異なる公開鍵であってもよい。

ステートメント６．１つまたは複数のトークン出力のうちの１つまたは複数は、２つ以上の代替条件を定義するそれぞれのｉｆ－ｅｌｓｅステートメントを含み、各代替条件は、トークン償還トランザクションの入力によってロック解除されるために、トークントランザクションの入力が定義された条件を満たさなければならないように構成される、ステートメント３から５のいずれかに記載の方法。

ステートメント７．トークントランザクションが単一のトークン出力を含み、トークン出力が使用不可能な出力である、ステートメント１に記載の方法。

ステートメント８．単一のトークン出力のシングルユーストークンに関連付けられた使用可能な出力は、トークン償還トランザクションの入力によってロック解除されるために、トークン償還トランザクションの入力が、トークン償還者の公開鍵にリンクされた署名および／またはトークン発行者の第２の公開鍵にリンクされた署名を含まなければならないように構成されたｍ－ｏｆ－ｎマルチシグネチャ出力である、ステートメント７に記載の方法。

ステートメント９．それぞれのトークン出力のシングルユーストークンに関連付けられたそれぞれの使用可能な出力は、トークン償還トランザクションの入力によってロック解除されるために、トークン償還トランザクションの入力がトークン償還者の公開鍵および／またはトークン発行者の第２の公開鍵を含まなければならないように構成されたpay-to-public-key-hash出力である、先行ステートメントのいずれかに記載の方法。

ステートメント１０．それぞれのトークン出力のシングルユーストークンに関連付けられたそれぞれの使用可能な出力は、そのシングルユーストークンを表すトークンデータのハッシュを含む、ステートメント９に記載の方法。

ステートメント１１．トークントランザクションは複数の入力を含み、複数の入力のうちの少なくとも１つは、第２の異なるトークン発行者の公開鍵にリンクされた署名を含む、先行ステートメントのいずれかに記載の方法。

ステートメント１２．トークントランザクションは複数の入力を含み、複数の入力のうちの少なくとも１つは、トークン発行者の第３の公開鍵にリンクされた署名を含み、第１の公開鍵および第３の公開鍵は互いにリンクされる、先行ステートメントのいずれかに記載の方法。

ステートメント１３．トークントランザクションの入力のうちの第１の入力は、トークン発行者の第３の公開鍵にリンクされた署名を含み、第１の公開鍵および第３の公開鍵は互いにリンクされる、先行ステートメントのいずれかに記載の方法。

ステートメント１４．第１の公開鍵および第３の公開鍵はトークン発行者の第２の公開鍵にリンクされる、ステートメント１２またはステートメント１３に記載の方法。

ステートメント１５．第２の公開鍵は証明された公開鍵である、ステートメント１４に記載の方法。

ステートメント１６．トークントランザクションは複数の入力を含み、複数のトークン入力のうちの少なくとも１つは、トークン償還者の公開鍵にリンクされた署名を含む、先行ステートメントのいずれかに記載の方法。

ステートメント１７．第２の異なるトークン発行者またはトークン償還者からトークントランザクションテンプレートを受信することと、トークントランザクションテンプレートに基づいてトークントランザクションを生成することとを含む、先行ステートメントのいずれかに記載の方法。

ステートメント１８．それぞれのシングルユーストークンを表すトークンデータは、トークン発行者の第１の公開鍵または発行者の第１の公開鍵にリンクされた証明された公開鍵を含む証明トランザクションへの参照を含む、先行ステートメントのいずれかに記載の方法。

ステートメント１９．トークン更新トランザクションを生成することと、ここで、トークン更新トランザクションは、トークントランザクションの１つまたは複数のトークン出力のうちの１つを参照する入力を含み、トークン更新トランザクションはトークン更新出力を含み、トークン更新出力は、トークントランザクションの参照された入力のそれぞれのシングルユーストークンの更新されたバージョンを表すトークンデータを含み、ブロックチェーンに記録させるために、トークン更新トランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信することとを含む、先行ステートメントのいずれかに記載の方法。

ステートメント２０．トークンキャンセルトランザクションを生成することと、ここで、トークンキャンセルトランザクションは、トークントランザクションの１つまたは複数のトークン出力のうちの１つを参照する入力を含み、トークンキャンセルトランザクションはトークンキャンセル出力を含み、トークンキャンセル出力は、トークントランザクションの参照された入力のそれぞれのシングルユーストークンのキャンセルされたバージョンを表すトークンデータを含み、ブロックチェーンに記録させるために、トークンキャンセルトランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信することとを含む、先行ステートメントのいずれかに記載の方法。

ステートメント２１．トークントランザクションのトランザクション識別子をトークン償還者に送信すること、および／または、それぞれのシングルユーストークンに関連付けられた１つまたは複数のそれぞれの使用可能な出力のそれぞれのトランザクション出力識別子をトークン償還者に送信することを含む、先行ステートメントのいずれかに記載の方法。

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

ステートメント２３．コンピュータ可読ストレージ上に具現化され、ステートメント２２に記載のコンピュータ機器上で実行されると、ステートメント１から２１のいずれかに記載の方法を実行するように構成されたコンピュータプログラム。

ステートメント２４．１つまたは複数のトークン出力であって、各トークン出力が、それぞれのシングルユーストークンを表すトークンデータを含み、各シングルユーストークンが、トークントランザクションのそれぞれの使用可能な出力に関連付けられ、各シングルユーストークンのそれぞれの有効性は、それぞれの使用可能な出力がブロックチェーンの未使用トランザクション出力セットに存在することを条件とする、１つまたは複数のトークン出力と、１つまたは複数の入力であって、入力のうちの少なくとも第１の入力が、トークン発行者の第１の公開鍵にリンクされた署名を含む、１つまたは複数の入力とを含む、ブロックチェーンのためのトークントランザクション。

ステートメント２５．ステートメント２４に記載のトークントランザクションを記憶したコンピュータ可読記憶媒体。

本明細書に開示される教示の別の態様によれば、トークン発行者およびトークン償還者の動作を含む方法が提供され得る。

本明細書に開示される教示の別の態様によれば、トークン発行者およびトークン償還者のコンピュータ機器を備えるシステムが提供され得る。

他の変形形態は、本明細書の開示が与えられれば、当業者に明らかになり得る。本開示の範囲は、開示された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

Claims (21)

1. ブロックチェーントランザクションを使用して、１つまたは複数のそれぞれのトークン償還者によって使用される１つまたは複数のシングルユーストークンを発行するコンピュータ実装方法であって、前記方法は、トークン発行者によって実行され、
   トークントランザクションを生成するステップであって、前記トークントランザクションは、
   １つまたは複数のトークン出力であって、各トークン出力が、それぞれのシングルユーストークンを表すトークンデータを含み、各シングルユーストークンが、前記トークントランザクションのそれぞれの使用可能な出力に関連付けられ、各シングルユーストークンのそれぞれの有効性は、前記それぞれの使用可能な出力がブロックチェーンの未使用トランザクション出力セットに存在することを条件とする、１つまたは複数のトークン出力と、
   １つまたは複数の入力であって、前記入力のうちの少なくとも第１の入力が、前記トークン発行者の第１の公開鍵に対応する秘密鍵に基づいて生成された署名を含み、少なくとも１つの入力は、前記トークン発行者の第３の公開鍵に対応する秘密鍵に基づいて生成された署名を含み、前記第１の公開鍵および前記第３の公開鍵は互いにリンクされ、前記第１の公開鍵および前記第３の公開鍵は前記トークン発行者の第２の公開鍵にリンクされ、前記第２の公開鍵は証明された公開鍵である、１つまたは複数の入力と
   を含む、ステップと、
   前記ブロックチェーンに記録させるために前記トークントランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信するステップと
   を含む方法。
2. 前記トークントランザクションが複数のトークン出力を含む、請求項１に記載の方法。
3. 各シングルユーストークンは、各トークン出力が前記それぞれの使用可能なトランザクション出力であるという点で、前記それぞれの使用可能な出力に関連付けられる、請求項１または２に記載の方法。
4. 前記１つまたは複数のトークン出力のうちの１つまたは複数はｍ－ｏｆ－ｎマルチシグネチャ出力であり、各ｍ－ｏｆ－ｎマルチシグネチャ出力は、トークン償還トランザクションの入力によってロック解除されるために、前記トークン償還トランザクションの前記入力が、ｎ個の公開鍵のそれぞれに対応する秘密鍵に基づいて生成された少なくともｍ個の署名を含まなければならないように構成される、請求項３に記載の方法。
5. 各ｍ－ｏｆ－ｎマルチシグネチャ出力は、前記トークン償還トランザクションの前記入力が、トークン償還者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名および／または前記トークン発行者の前記第１または第３の公開鍵に対応する秘密鍵に基づいて生成された署名を含むことを必要とする、請求項４に記載の方法。
6. 前記１つまたは複数のトークン出力のうちの１つまたは複数は、２つ以上の代替条件を定義するそれぞれのｉｆ－ｅｌｓｅステートメントを含み、各代替条件は、トークン償還トランザクションの入力によってロック解除されるために、前記トークントランザクションの前記入力が前記定義された条件を満たさなければならないように構成される、請求項３から５のいずれか一項に記載の方法。
7. 前記トークントランザクションが単一のトークン出力を含み、前記トークン出力が使用不可能な出力である、請求項１に記載の方法。
8. 前記単一のトークン出力の前記シングルユーストークンに関連付けられた前記使用可能な出力は、トークン償還トランザクションの入力によってロック解除されるために、前記トークン償還トランザクションの前記入力が、トークン償還者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名および／または前記トークン発行者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名を含まなければならないように構成されたｍ－ｏｆ－ｎマルチシグネチャ出力である、請求項７に記載の方法。
9. 前記それぞれのトークン出力の前記シングルユーストークンに関連付けられた前記それぞれの使用可能な出力は、トークン償還トランザクションの入力によってロック解除されるために、前記トークン償還トランザクションの前記入力がトークン償還者の第２の公開鍵および／または前記トークン発行者の前記第２の公開鍵を含まなければならないように構成されたpay-to-public-key-hash出力である、請求項１から８のいずれか一項に記載の方法。
10. 前記それぞれのトークン出力の前記シングルユーストークンに関連付けられた前記それぞれの使用可能な出力は、そのシングルユーストークンを表す前記トークンデータのハッシュを含む、請求項９に記載の方法。
11. 前記トークントランザクションは複数の入力を含み、前記複数の入力のうちの少なくとも１つは、第２の異なるトークン発行者の公開鍵に対応する秘密鍵に基づいて生成された署名を含む、請求項１から１０のいずれか一項に記載の方法。
12. 前記トークントランザクションは複数の入力を含む、請求項１から１１のいずれか一項に記載の方法。
13. 前記トークントランザクションの前記入力のうちの前記第１の入力は、前記トークン発行者の前記第３の公開鍵に対応する秘密鍵に基づいて生成された署名を含む、請求項１から１２のいずれか一項に記載の方法。
14. 前記トークントランザクションは複数の入力を含み、前記複数のトークン入力のうちの少なくとも１つは、トークン償還者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名を含む、請求項１から１３のいずれか一項に記載の方法。
15. 第２の異なるトークン発行者または前記トークン償還者からトークントランザクションテンプレートを受信するステップと、
    前記トークントランザクションテンプレートに基づいて前記トークントランザクションを生成するステップと
    を含む、請求項１から１４のいずれか一項に記載の方法。
16. それぞれのシングルユーストークンを表す前記トークンデータは、前記トークン発行者の前記第１の公開鍵または前記トークン発行者の前記第１の公開鍵にリンクされた前記証明された公開鍵を含む証明トランザクションへの参照を含む、請求項１から１５のいずれか一項に記載の方法。
17. トークン更新トランザクションを生成するステップであって、前記トークン更新トランザクションは、前記トークントランザクションの前記１つまたは複数のトークン出力のうちの１つを参照する入力を含み、前記トークン更新トランザクションはトークン更新出力を含み、前記トークン更新出力は、前記トークントランザクションの前記参照された入力の前記それぞれのシングルユーストークンの更新されたバージョンを表すトークンデータを含む、ステップと、
    前記ブロックチェーンに記録させるために、前記トークン更新トランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信するステップと
    を含む、請求項１から１６のいずれか一項に記載の方法。
18. トークンキャンセルトランザクションを生成するステップであって、前記トークンキャンセルトランザクションは、前記トークントランザクションの前記１つまたは複数のトークン出力のうちの１つを参照する入力を含み、前記トークンキャンセルトランザクションはトークンキャンセル出力を含み、前記トークンキャンセル出力は、前記トークントランザクションの前記参照された入力の前記それぞれのシングルユーストークンのキャンセルされたバージョンを表すトークンデータを含む、ステップと、
    前記ブロックチェーンに記録させるために、前記トークンキャンセルトランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信するステップと
    を含む、請求項１から１７のいずれか一項に記載の方法。
19. 前記トークントランザクションのトランザクション識別子を前記トークン償還者に送信するステップ、および／または、
    それぞれのシングルユーストークンに関連付けられた１つまたは複数のそれぞれの使用可能な出力のそれぞれのトランザクション出力識別子を前記トークン償還者に送信するステップ
    を含む、請求項１から１８のいずれか一項に記載の方法。
20. コンピュータ機器であって、
    １つまたは複数のメモリユニットを備えるメモリと、
    １つまたは複数の処理ユニットを備える処理装置と
    を備え、前記メモリは、前記処理装置上で実行されるように構成されたコードを記憶し、前記コードは、前記処理装置上にあるときに、請求項１から１９のいずれか一項に記載の方法を実行するように構成される、コンピュータ機器。
21. コンピュータ可読ストレージ上に具現化され、請求項２０に記載のコンピュータ機器上で実行されると、請求項１から１９のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。