JP7617806B2 - 分散型台帳システムにおける債務リソース管理 - Google Patents

Description

本発明は、概して分散型台帳システムに関し、より具体的にはブロックチェーンにおけるような分散型台帳システムにおける債務リソース管理に関する。

背景
現代における資産のデジタル化は、さまざまな分野において従来型システムの転換を引き起こした。そのような資産は、文学的資産、娯楽関連資産、書籍、画像、マルチメディア、知識、および、とりわけ金融および通貨資産を含み得る。ブロックチェーンおよびデジタルウォレット等の画期的な技術の到来とともに、金銭または通貨等の従来は有形の資産でさえ、今ではデジタル分野で模倣されている。このような画期的な技術の１つは、紙幣、硬貨またはその他任意の通貨単位等の有形物を模倣するために使用し得る単一のデジタル単位で表すことができる、デジタルトークンの実装である。

デジタルトークンは、紙幣または硬貨等の交換可能な通貨の挙動を模倣する交換単位である。現実世界の銀行業務システムと同様に、デジタルトークンはデジタルトークンアカウントに対応付けることができる。デジタルトークンアカウントは、デジタル台帳システムを通じて実現することができる。デジタル台帳システムまたはデジタル台帳は、システムのメモリに保存されるトランザクションのデータベースまたは記録である。クレジットトランザクションおよびデビットトランザクションは、デジタル台帳における２種類のトランザクションである。クレジットトランザクションはデジタル台帳への正の加算であり、デビットトランザクションはデジタル台帳への負の加算である。

デジタル台帳システムは、さまざまな種類のアーキテクチャで実現することができる。これらのアーキテクチャは、大まかに中央集権型アーキテクチャと非中央集権型または分散型アーキテクチャとに分類することができる。これらの異なるアーキテクチャにおいて、トランザクションの管理は、中央集権型方法または非中央集権型方法に従って行うことができる。第１の方法すなわち中央集権型方法は、中央集権型システムを使用する一般的な方法であり、このシステム内のすべてのトランザクションの記録を保持し、この記録の変更を、自身の記録に対するその他のシステムの同意なしで行う。第２の方法は、非中央集権型または分散型方法であり、複数のシステムがトランザクションの記録を保持できるようにし、記録の最も更新されたコピーに関してシステム間の合意を形成する。これは、非中央集権型システムの複数のノード間におけるビザンチンフォールトトレラント性のあるレプリケーションを保証する合意形成アルゴリズムを使用することによって実現される。分散型方法は、暗号法および合意形成アルゴリズムを使用するので、ユーザがシステム全体に対して置かなければならない信頼の量を減じるという点で、実用的である。さらに、非中央集権型方法は、１つの制御ポイントに対する依存を少なくしシステムの制御を複数のアクセスポイントに分散させ、それと同時にシステムのセキュリティを合意を使用することによって保証する。トランザクションの分散型管理を使用する非中央集権型アーキテクチャシステムの一例は、ブロックチェーンと呼ばれるデータ構造によって可能になる分散型台帳システムである。

ブロックチェーンは、リンクリスト構造などを用いてリンクされたブロックからなる追記専用のデータ構造である。１つのブロックは、ヘッダとメタデータとトランザクションリストとを含むデジタルデータに対応付けられた情報を含む。ヘッダおよびメタデータは、ソフトウェアのバージョン、このブロックに含まれるトランザクションの保全性を検証するために使用される暗号学的ハッシュ、タイムスタンプなどに関する情報を含み得る。トランザクションリストは、分散型台帳システムの状態の変化を表す個々のトランザクションを含む。ブロックチェーンシステムにおいて、ユーザは、以下「アドレス」と呼ぶ、暗号技術によって生成されたアドレスに対応付けることができる。アドレスは、ユーザ間のトランザクションに使用することができる。ブロックチェーンにおいて、クレジット残高は、アドレスに対応付けることができ、単に、そのアドレスに対するすべての収入トランザクションの合計であってもよい。ユーザは、分散型台帳システムにおいて複数のアドレスを所有することができ、その場合、このユーザの個人残高は、このユーザのすべてのアドレスの残高の合計である。

ブロックチェーンデータ構造を有する分散型台帳においてトランザクションを実現する１つの方法は、未使用トランザクションアウトプット（unspent transaction output）（ＵＴＸＯ）モデルの使用によるものである。ＵＴＸＯモデルにおいて、トランザクションはインプットとアウトプットとを有し得る。トランザクションへのインプットは、ＵＴＸＯに対するポインタとアンロックスクリプトとを含み得る。アウトプットは、総額と、対応する総額が送られるユーザのアドレスとを含む。ＵＴＸＯモデルにおけるトランザクションアウトプットが次の何らかのトランザクションのインプットとマッチングされていない場合、このアウトプットは「未使用」であり消費可能な単位として扱われる。ＵＴＸＯは、トランザクションインプットとマッチングされると、振替または消費とみなされる。したがって、ＵＴＸＯは、対応するインプットがないトランザクションアウトプットである、すなわち、マッチングされていないので消費に使用できる。このため、ＵＴＸＯは、本質的に、あるユーザに譲渡されるクレジットであり、よって、このユーザに対応するすべてのアドレスにおけるＵＴＸＯの合計が、このユーザのアカウント残高である。

しかしながら、ＵＴＸＯはデビットの概念を表すものではない。特に、トランザクションインプットを通じて決定されるデビットは、トランザクションアウトプットを通じて決定される等価の対応するクレジットなしでは、ブロックチェーンに存在しない。ある注目すべき例外は、たとえば、インプットを全く必要とせずに行われるマイニング（mining）を通じたトークンの作成である。

従来、ＵＴＸＯは、複数のアウトプットアドレスを有するトランザクションの一部となることができる。ＵＴＸＯにおける総額がトランザクションに必要な総額よりも大きい場合、ＵＴＸＯは、その額すべてを複数のアドレスに送る。トランザクションアウトプット総額の一部が、このトランザクションをカバーし、別の一部が、同一アドレスに、または、送り主に対応付けられた新たに生成されたアドレスに送られる。したがって、従来、各トランザクションインプットはトランザクションアウトプットとマッチングされる。このため、トランザクションインプットを通じて決定されるデビットは、トランザクションアウトプットを通じて決定される等価の対応するクレジットなしでは存在しない。

従来、中央集権型システムにおいて、デビットエントリは、そのもの自身で存在し、複式簿記では一般的に負債（liability）と呼ばれている。この負の金銭の存在は、債務を表すので、複雑な経済が機能するのに必要不可欠である。逆に、ほとんどの分散型台帳は通貨を実現し、通貨は負になり得ない。重要なことは、実現に成功しているほとんどの分散型台帳が、強制がないと想定して実現されている点である。強制なしでは債務の返済を保証できない。強制なしで債務を発行すると、結果としてアカウント残高が負の方向に膨らみ、分散型台帳に価値を与えないことになる。この点は、中央集権型システムにおいて台帳を実現することで簡単に解決できる。中央集権型システムは、たとえば、債務の規制および返済を保証するために、法的システム全体と連携するように設計することができる。しかしながら、債務の返済を保証する必要性と、分散型台帳が機能する通常のやり方とを両立させる方法は、ないように思われる。

したがって、中央集権型システムが保持するデジタルトークンの準備資産に頼ることなく、ブロックチェーンデータ構造を有する分散型台帳システムにおけるように、分散型方式で債務の価値を表す必要がある。

概要
いくつかの実施形態の目的は、中央集権型システムが保持する準備資産に頼ることなく分散型方式で債務の価値を表すためのシステムおよび方法を提供することである。これに加えてまたはこれに代えて、いくつかの実施形態の目的は、強制方式で債務の規制および返済を保証するためのシステムおよび方法を提供することである。

いくつかの実施形態は、債務の概念はブロックチェーンプロトコルのトップに作成できるという理解に基づいている。たとえば、一方は正のトークン（クレジットとも呼ばれる）用、もう一方は負のトークン（デビットとも呼ばれる）用である、２つのブロックチェーンを作成することができる。加えて、クレジットの概念はスマートコントラクトの助けを借りて作成することができる。しかしながら、このような二重台帳システムまたはスマートコントラクトの拡張は、不便であり、場合によっては第三者ソフトウェアに対する望ましくない依存を追加することになる。

そのために、いくつかの実施形態の目的は、クレジットトランザクションおよびデビットトランザクション双方の作成に適したブロックチェーンプロトコルを提供することである。これに加えてまたはこれに代えて、いくつかの実施形態の目的は、従来型のＵＴＸＯモデルと組み合わせることができるまたは従来型のＵＴＸＯモデルを拡張することができる、このようなブロックチェーンプロトコルを提供することである。

いくつかの実施形態は、ＵＴＸＯモデルにおけるクレジットの概念が、アウトプットがマッチングされていないトランザクションに基づいて構築される場合、拡張されたＵＴＸＯモデルにおけるデビットの概念は、インプットがマッチングされていないトランザクションに基づいて構成できる、という認識に基づいている。言い換えると、クレジットは、インプットと、マッチングされていないアウトプットとを有するトランザクションであり、デビットは、アウトプットと、マッチングされていないインプットとを有するトランザクションである。このようにして、債務トランザクションは、当然ＵＴＸＯモデルに統合することができる。

特に、マイニングを通じてクレジットを作成するためのコインベース（coinbase）トランザクションにはインプットがない。しかしながら、デビットトランザクションにはインプットがあるもののこのインプットはマッチングされていない。インプットがないことと、マッチングされていないインプットがあることとの違いは、以下の事実から明らかである。すなわち、ブロックチェーンプロトコルは、マッチングされていないインプットをマッチングすることはできるが、インプットをコインベーストランザクションとマッチングするまたはこれに追加することはできない。このようにして、このプロトコルは、単にインプットをクレジットトランザクションのアウトプットとマッチングするだけで、債務（または債務の支払い）を取り消すことができる。このような支払いは、コインベーストランザクションでは不可能であろう。

マッチングされていないインプットに基づく債務トランザクションの導入は、債務およびクレジットトランザクションを１つのプロトコルに統合する。このプロトコル内で債務を直接的に表すことにより、プロトコルの保全性が改善される。債務を実現する代替方法は、さらなる複雑さを導入し、これは、プロトコルの有用性を減じ失敗の可能性を高める。

加えて、債務トランザクションおよびクレジットトランザクションの統合により、プルーフ・オブ・ワーク（proof of work）という概念に基づいたクレジット作成／マイニングに代わるものが提供される。統合された分散型台帳のいくつかの実装例において、クレジット作成トランザクションの生成は、そのような生成に対して誰かが債務を引き受ける意思を示した場合に、可能である。このようにして、クレジット作成は、債権者によって妥当性確認される。

いくつかの実施形態は、債務－クレジットシステムを債務トークンの導入を通して実現する分散型台帳に基づいている。このシステムの価値は、債務を引き受けるというユーザの意思によって保証される。よって、このシステムは、クレジットトークン残高を生成し、同額の債務トークン残高を同時に作成する。そのために、いくつかの実施形態は、債務を作成することができる、統合されているが分散型の方式を作成するという目的に基づいている。債務の返済は強制方式で実現される。

いくつかの実施形態は、新たな債務発行トランザクションの導入に基づいている。債務は、債務のみのアドレスを導入することで実現され、債務のみのアドレスは、対応付けられたＵＴＸＯなしで総額を送ることができるアドレスである。債務発行トランザクションにおいてトランザクションが作成され、このトランザクションのトランザクションインプットは、債務のみのアドレスに向けられており、そのアンロックスクリプトは、債務引き受けに対する許可を保証する公開鍵を保持する。これは、ＵＴＸＯモデルにおける作成トランザクションに置き換わるものであり、トークンを、マッチングされていないインプットフィールドを有するトランザクションの導入によって作成する。債務発行トランザクションを処理するとき、プロトコルは、ＵＴＸＯについての検査は行わない。これはその代わりに、債権者ユーザが債務者ユーザに対して債務を発行することを認める許可について検査する。

いくつかの実施形態はトークンの作成に基づいている。システムは、債務トークンを発行する場合、常に、対応するクレジットトークンを発行し、発行される債務トークンの如何なる総額も、対応する、クレジットトークンの総額とともに発行される。トークンの作成は、債権者ユーザが所有するＵＴＸＯを作成することによって行われる。また、ＵＴＸＯの作成は、債務者が所有する債務のみのアドレスをデビットに記入することで実現される。このことは、いかなるときもシステムではクレジットおよびデビットの総額が等しいことを保証し、当事者が債務を引き受ける意思を持たない場合に命令によるクレジットまたはデビットの作成を回避する。債務のみのアドレスは、クレジットを債務発行トランザクションのみを通して送ることができる。このことは、プロトコルからの許可なしでは債務が生じ得ないことおよびクレジットトークンは作成できないことを、保証する。

このようにして、債務トークンは、債務のみのアドレスで作成され、移動させることはできない。さらに、債務トークンおよびクレジットトークンをこのやり方で作成することで、履行および支払が必要な債務をユーザが受けることを保証し、そのため、プログラム的に債務を放棄する機能は認められない。本明細書に記載の各種実施形態で説明されるように、これは、必然的に上記プロトコルによって実施される。

いくつかの実施形態は、債務トークンおよびクレジットトークンの作成について説明する。各種実施形態においてより詳細に説明されるように、クレジットトークンは自由に移動させることができる。さらに、債務トークンは、トランザクションアウトプットにおいて債務のみのアドレスでクレジットトランザクションおよび／またはクレジットトークンを送ることによって無効にすることができる。債務のみのアドレスに送られたクレジットトークンの総額は、そのアドレスに保持されている同額の債務トークンを無効にする。構造上、債務支払トランザクションはクレジットトランザクションを模倣する。債務のみのアドレスに送られるクレジットトークンは、債務のみのアドレスが負の残高を持たないことを保証する。したがって、クレジットトランザクションが、最大総額を上回るものを債務のみのアドレスに送るために開始された場合、ＵＴＸＯを伴うトランザクションが作成され、送られた総額と最大総額との差がＵＴＸＯに保存される。

いくつかの実施形態は、分散型システムにおけるユーザに対する債務のアカウンティングのための債務プールの管理について説明する。債務プールは、必要に応じてユーザに対して発行することができたとえば債務が返済されると債務の総額と同額のクレジットトークンを債務プールに送ることによって無効にされる、債務トークンを格納することができる。

いくつかの実施形態は、分散型台帳システムにおいて債務トークンおよびクレジットトークンを用いて債務を管理するためのブロックチェーンプロトコルスタックについて説明する。ブロックチェーンプロトコルは、いくつかの実施形態で説明した分散型台帳システムアーキテクチャを用いて先に述べた各種トランザクションを実現し得る。

ここに開示される実施形態について添付の図面を参照しながらさらに説明する。示されている図面は必ずしも原寸に比例しておらず、代わりに、ここに開示される実施形態の原理の説明ではほとんどの場合強調が加えられている。

いくつかの実施形態に係る分散型台帳システムの概略図を示す。 ＵＴＸＯベースのモデルにおけるトランザクションの構造の一例を示す図である。 トランザクションインプットデータ構造の一例を示す図である。 トランザクションアウトプットデータ構造の一例を示す図である。 未使用トランザクションアウトプット（ＵＴＸＯ）の一例を示す図である。 債務トランザクションの一例を示す図である。 未使用債務－クレジットトランザクションの一例を示す図である。 一部返済済みの債務トランザクションを示す図である。 フラグを有する債務トランザクションの一例を示す図である。 フラグを有するコインベーストランザクションの一例を示す図である。 債務プールにおける債務トランザクションの一例を示す図である。 クレジットトランザクションと同時の債務の作成を示す図である。 いくつかの実施形態に係るブロックチェーンのブロック構造の一例を示す図である。 公開鍵から債務のみのアドレスを生成する方法の一例を示す図である。 分散型台帳システムにおいて債務管理を実現するためのブロックチェーンプロトコルスタックを表した、一例としての図を示す。 いくつかの実施形態に係る分散型台帳システムアーキテクチャのブロック図を示す。 いくつかの実施形態に係る図８の分散型台帳システムのブロック図を示す。 いくつかの実施形態に係る債務管理を伴う分散型台帳システムの、一例としてのアーキテクチャを示す図である。 いくつかの実施形態に係る分散型台帳システムにおける債務管理の方法の、一例としてのブロック図を示す。 ネットワークに受け入れられたコインベーストランザクションを伴うブロックチェーンシステムの実施形態において発生する一連のイベントの、一例としてのブロック図を示す。 債務トランザクションが生成されるときに発生する一連のイベントの、一例としてのブロック図を示す。 債務が支払われるときに発生する一連のイベントの、一例としてのブロック図を示す。 債務トランザクションが完全に支払われるまたは債務総額よりも大きいときに発生する一連のイベントの、一例としてのブロック図を示す。

詳細な説明
本開示は、分散型または非中央集権型台帳システムアーキテクチャにおいて使用される債務－クレジットシステムを実現する方法に関する。本開示のいくつかの実施形態は、未使用トランザクションアウトプット（ＵＴＸＯ）モデルに基づく。ＵＴＸＯモデルはＵＴＸＯベースの分散型台帳システムを提供するために使用され、このシステムでは、クレジットトランザクションが債務によって裏付けられ、このシステムにおけるクレジットの合計はこのシステムにおける債務の合計と等しい。この態様のシステムにおけるクレジットとデビットとの間の関係は、クレジットの作成が、等しい債務を同時に作成する場合に限って可能であることを保証する。

ＵＴＸＯベースのシステムにおいて、ネットワークの参加者は、トランザクションを互いに送信することによって相互にやり取りすることができる。これはある程度は公開－秘密鍵暗号技術によって容易になる。このシステムにおいて各参加者は秘密鍵で表され、そこから対応する公開鍵を生成することができる。いくつかの実施形態において、マスタ公開鍵は多数の子公開鍵を生成することができ、子公開鍵の各々は対応付けられた公開鍵を有する。暗号技術および公開－秘密鍵ペアを使用することにより、セキュアなシステムアーキテクチャを提供する。暗号技術が可能にする特徴を有する現在のＵＴＸＯベースのシステムは、債務トランザクションおよび効率的な債務管理手順が欠落しているので、今もなおこのシステムで債務を効率よく表現することができない。ＵＴＸＯベースのシステムにおいて、ＵＴＸＯは、何のトランザクションアウトプットもないトランザクションである。このため、ＵＴＸＯは、ユーザがこのシステムで消費に利用できる通貨または未使用の金銭のような、未使用のリソース単位とみなすことができる。たとえば、現実世界のユーザが各種取引中に消費するために現金を財布に入れて持ち運ぶまたは金銭をその口座に持っているのと同様に、ＵＴＸＯは分散型台帳システムにおけるユーザの未使用の金銭またはクレジットである。トランザクションはクレジットの譲渡または再譲渡を表す。だからといってＵＴＸＯ構造が金銭的価値を表すものに限られる訳ではない。ＵＴＸＯベースのシステムは、たとえば個人のアイデンティティ、エネルギーの単位、および／またはチェーンストアで入手できブロックチェーンベースのリソース管理システムによって追跡される各種商品等の、その他の種類の不変データを表すことができる。

図１Ａは、いくつかの実施形態に係る分散型台帳システム１００の概略図を示す。各種実施形態において、分散型台帳システム１００は、ブロックチェーンデータ構造を有する分散型台帳においてトランザクションを実現する。そのために、分散型台帳システム１００は、メッセージを受信しこれらのメッセージを処理してブロックチェーンの１つ以上のブロック１１２、１１４および１１６にするためにブロックチェーンプロトコルを実行するように構成された、少なくとも１つのプロセッサを含む。上記１つ以上のブロック１１２～１１６はさらに分散型台帳システム１００内の複数のノードに接続されてもよく、ノードはブロックチェーンプロトコルを使用するネットワーク全体の構成単位であってもよい。複数のノードは、各ノードがネットワーク内のその他すべてのノードに接続されるように相互に接続されてもよい。さらに、各ノードは、分散型台帳システム１００においてブロックチェーンプロトコルを用いて表されるブロックチェーン全体の、自身のコピーを含むように構成されてもよい。さらに、各ノードは複数の手段で実現することができ、これらの手段は、コンピュータ、モバイルデバイス、ハンドヘルド装置、ポータブルコンピューティングデバイス、タブレット、スマートフォン、ラップトップ、スマートウェアラブルデバイスなどを含むが、これらに限定される訳ではない。各ノードは、上記１つ以上のブロック１１２～１１６によって形成されるブロックチェーンの、合意に基づくコピーを有するように構成されてもよい。

ブロックチェーンの各ブロックは、ハッシュフィールド、タイムスタンプフィールド、トランザクションルートフィールドおよびナンス（nonce）フィールドを含む複数のフィールドを含み得る。ハッシュフィールドは、各ブロックのヘッダ上に作成される、ＳＨＡ２５６暗号学的ハッシュアルゴリズム等の暗号学的ハッシュ関数を含み得る。１つ以上のブロック１１２～１１６の各々は、前のブロックのハッシュへのリファレンスを含み得る。１つ以上のブロック１１２～１１６の各々はさらに、ブロックが構築または作成された時間を記述するタイムスタンプフィールドを含み得る。各ブロックはさらに、このブロックに対応付けられたマークル（Merkle）ツリーのルートを含む、トランザクションルートを含み得る。マークルツリーは、各ブロックのデータの妥当性確認に使用することができるバイナリハッシュツリーである。トランザクションルートは、トランザクション１２６等の各ブロックのトランザクションのルートのハッシュを含み得る。各ブロックはさらに、このブロックに対応付けられた難易度ターゲット（difficulty target）アルゴリズムを解くために使用できるカウンタであってもよいナンス（１度だけ使用される数字（nonce: number only used once））フィールドを含み得る。たとえば、ナンスは、ブロックによって難易度ターゲットアルゴリズムを解く際に使用されてもよい。いくつかの実施形態において、難易度ターゲットアルゴリズムは、ブロックチェーンにおいてこのブロックチェーンの１つ以上のブロック１１２～１１６によって使用されるプルーフ・オブ・ワーク（ＰｏＷ）アルゴリズムであってもよい。

ブロックチェーンは、関与するいかなる記録もすべての後続ブロックの変更なしでは遡及的に変更できないように、多数のコンピュータでトランザクションを記録するのに使用される、非中央集権型で、分散型で、たいていは公開のデジタル台帳である。これにより、参加者は、独立してかつ比較的低コストでトランザクションを検証および監査することができる。ブロックチェーンデータベースは、複数のノードからなるピアツーピアネットワークおよび分散型タイムスタンプサーバを用いて自律的に管理される。これらは、自己利益の集まりによって促進されるマスコラボレーションによって認証される。このような設計は、データセキュリティに関する参加者の不信感が取るに足らないものであるロバストなワークフローを容易にする。ブロックチェーンを使用することで、デジタル資産から無限の再現性という特徴は取り除かれる。これにより、確実に、価値の各単位が１度だけ振り替えられて二重支払という長年にわたる問題を解決する。

各種実施形態において、ブロックチェーンプロトコルは、ＵＴＸＯモデルの使用を通じて実現される。そのために、メッセージが、ブロックチェーンに含まれることになるトランザクション１２６に対応付けられ、この対応付けは、このトランザクションのインプットおよびアウトプットを、近隣のトランザクション１２６と、このトランザクションのインプットが前のトランザクションのアウトプットとマッチングされこのトランザクションのアウトプットが次のトランザクションのインプットとマッチングされるように、マッチングする。プロセッサは、メッセージの処理中にさまざまな種類のトランザクション１２８を生成するように構成されており、上記種類のトランザクションは、次のトランザクションとマッチングされるように構成された、マッチングされていないアウトプットを有するクレジットトランザクション１１８と、前のトランザクションとマッチングされるように構成された、マッチングされていないインプットを有するデビットトランザクション１２０と、マッチングされたインプットとマッチングされたアウトプットとを有する振替トランザクション１２２とを含む。振替トランザクション１２２は、未使用の債務－クレジットトランザクションおよび／または一部返済済みの債務トランザクションなどといった、異なる種類のものであってもよい。ある実装例において、異なる種類のトランザクション１２８は、任意でコインベーストランザクション１２４を含み得る。

いくつかの実施形態の目的は、中央集権型システムが保持する準備資産に頼ることなく分散型方式で債務の価値を表すためのシステムおよび方法を提供することである。これに加えてまたはこれに代えて、いくつかの実施形態の目的は、強制方式で債務の規制および返済を保証するためのシステムおよび方法を提供することである。

いくつかの実施形態は、デビットの概念はブロックチェーンプロトコルのトップに作成できるという理解に基づいている。たとえば、一方は正のトークン（クレジットとも呼ばれる）用、もう一方は負のトークン（デビットとも呼ばれる）用である、２つのブロックチェーンを作成することができる。加えて、クレジットの概念はスマートコントラクトの助けを借りて作成することができる。しかしながら、このような二重台帳システムまたはスマートコントラクトの拡張は、不便であり、場合によっては第三者ソフトウェアに対する望ましくない依存を追加することになる。

そのために、いくつかの実施形態の目的は、クレジットトランザクションおよびデビットトランザクション双方の作成に適したブロックチェーンプロトコルを提供することである。これに加えてまたはこれに代えて、いくつかの実施形態の目的は、従来型のＵＴＸＯモデルと組み合わせることができるまたは従来型のＵＴＸＯモデルを拡張することができる、このようなブロックチェーンプロトコルを提供することである。

いくつかの実施形態は、ＵＴＸＯモデルにおけるクレジットの概念が、アウトプットがマッチングされていないトランザクションに基づいて構築される場合、拡張されたＵＴＸＯモデルにおけるデビットの概念は、インプットがマッチングされていないトランザクションに基づいて構成できる、という認識に基づいている。言い換えると、クレジットは、インプットと、マッチングされていないアウトプットとを有するトランザクションであり、デビットは、アウトプットと、マッチングされていないインプットとを有するトランザクションである。これらのトランザクションを実現するように構成された分散型台帳システムにおいて、アウトプットと、マッチングされていないインプットとを有するこのようなトランザクションを、債務トランザクションと呼んでもよい。このようにして、債務トランザクションは当然ＵＴＸＯモデルに統合することができる。債務トランザクションを、マッチングされていないインプットに基づいて導入することにより、債務およびクレジットトランザクションが１つのプロトコルに統合される。このプロトコル内で債務を直接的に表現することにより、プロトコルの保全性が改善される。債務を実現するための代替方法は、さらなる複雑さを導入し、そうすると、プロトコルの有用性は低下し故障の可能性が高くなる。

そのために、トランザクションの構造は、インプット／アウトプットの関係から利点を得る。たとえば、クレジットトランザクションは、次のトランザクションとマッチングされるように構成されたマッチングされていないアウトプットを有するように生成される。同様に、デビットトランザクションは、前のトランザクションとマッチングされるように構成されたマッチングされていないインプットを有するように生成される。振替トランザクションが、マッチングされたインプットとマッチングされたアウトプットとを有するように生成される。振替トランザクションは、クレジットをデビットトランザクションに連結することおよびその逆を行うことが可能である。

たとえば、本明細書で使用される、次のトランザクションとマッチングされるように構成されたマッチングされていないアウトプットを有するクレジットトランザクションは、分散型台帳システム１００が、（クレジットトランザクションがブロックチェーンに追加された後に）プロセッサによって実行されるとクレジットトランザクションのアウトプットを指し示すインプットを有する別のトランザクションを生成する実行可能なコードを格納していることを、意味する。このトランザクションを本明細書では次のトランザクションと呼ぶ。なぜなら、これは、クレジットトランザクションよりも遅く作成され、クレジットトランザクションのアウトプットを通してクレジットトランザクションに連結される、すなわち、ＵＴＸＯが後続の連結として示すやり方で連結されるからである。

本明細書で使用される、前のトランザクションとマッチングされるように構成されたマッチングされていないインプットを有するデビットトランザクションは、分散型台帳システム１００が、（デビットトランザクションがブロックチェーンに追加された後に）プロセッサによって実行されるとデビットトランザクションのインプットを指し示すアウトプットを有する別のトランザクションを生成する実行可能なコードを格納していることを、意味する。この別のトランザクションを本明細書で前のトランザクションと呼び、たとえ上記前のトランザクションがデビットトランザクションの後でブロックチェーンに追加されたとしても、前のトランザクションと呼ぶ。なぜなら、上記前のトランザクションは、デビットトランザクションに、そのインプットを通して連結される、すなわちＵＴＸＯが先行する連結として示すやり方で連結されるからである。このようにして、債務トランザクションは、従来型のＵＴＸＯモデルと組み合わせるまたはこれを拡張することができるブロックチェーンプロトコルに統合される。

図１Ｂは、ＵＴＸＯモデルベースのシステムにおけるトランザクション１３０の構造の一例を示す。この一例としてのトランザクションの構造は、ネットワークがブロックチェーンプロトコルのさまざまな有効バージョンを扱うことができるようにするバージョン番号１３２を含む。これはまた、図１Ｃでより詳細に示される、ＵＴＸＯを指し示すために使用され、クレジットのソースを表すデータ構造である、インプット１３４および／またはトランザクションインプット１３４のコンテナを含む。これはまた、クレジットをロックスクリプトの形態で別の受取人に振り替えるために使用されるデータ構造であるアウトプット１３６および／またはトランザクションアウトプット１３６のコンテナを含む。この一例としてのトランザクション１３０の構造はまた、分散型台帳システム等のシステムにトランザクションを追加できる最も早い時間を指定するロック時間１３８を含む。いくつかの実施形態において、分散型台帳システムは、図１Ａに関連して述べたブロックチェーンプロトコルに基づく分散型台帳システム１００のようなブロックチェーンシステムである。このようなブロックチェーンシステムにおいて、ロック時間１３８は、Ｕｎｉｘ（登録商標）エポック（Unix Epoch）タイムスタンプの時間またはブロック高さであってもよく、これは、図１Ａに関して述べた１つ以上のブロック１１２～１１６等のうちのブロックにトランザクションを含めることを考えることができるようになる前にブロックチェーン内に存在していなければないブロックの数を表す。いくつかの実施形態において、ロック時間１３８は、ブロックチェーンのあるブロックを更新するために分散型台帳のどのコピーを使用すべきかに関するブロックチェーンシステム内の異なるノード間の合意に基づいて定められてもよい。このような場合、最長のブロックシーケンスが、ブロックチェーンの最も更新されたコピーとして選択されてもよく、ロック時間１３８は、この最長のブロックシーケンスに基づいて更新されてもよい。ブロックチェーンシステムを用いることにより、トランザクション構造１３０によって定められるトランザクションを実行することができる。次に、トランザクション構造１３０を図１Ｃとの関連でさらに詳細に説明する。

図１Ｃは、図１Ｂに記載されているトランザクションインプット１３４のようなトランザクションインプットデータ構造１４０の一例を示す。トランザクションインプットデータ構造１４０は、消費されるＵＴＸＯを含むトランザクションに対するポインタを含み得る、トランザクションハッシュ１４２を含み得る。トランザクションインプットデータ構造１４０はさらにアウトプットインデックス１４４を含み、アウトプットインデックス１４４は、消費されるＵＴＸＯのインデックス番号を含む。トランザクションインプットデータ構造１４０はさらに、アンロックスクリプトのサイズをバイトで指定するのに使用できるアンロックスクリプトサイズ１４６を指定するためのフィールドを含む。また、トランザクションインプットデータ構造１４０はさらに、トランザクションハッシュ１４２のポインタが指し示すＵＴＸＯのロックスクリプトの条件を満たすスクリプトを含む、アンロックスクリプト１４８を含む。アンロックスクリプト１４８は、トランザクションインプットデータ構造１４０に対応付けられたＵＴＸＯを消費する条件を指定するのに使用することができる。図１Ｄに示されるトランザクションアウトプットとともに説明されるように、アンロックスクリプト１４８と、対応するロックスクリプトとの組み合わせを用いることにより、トランザクションインプットデータ構造１４０に対応付けられたトランザクションの妥当性確認を行う。具体的には、アンロックスクリプト１４８をロックスクリプトと並行して実行することにより、アンロックスクリプト１４８において指定されたＵＴＸＯを消費する条件をトランザクションが満たすことを確認できる。アンロックスクリプトのいくつかの例は、Ｐ２ＰＫＨ（Pay to Public Key Hash）またはＰ２ＳＨ（Pay to Script Hash）を含み得る。これらのアンロックスクリプトを用いることにより、トランザクションインプット構造１４０に対応付けられたＵＴＸＯを消費するために解かねばならない可能性がある暗号パズルを指定する。たとえば、Ｐ２ＰＫＨアンロックスクリプトは、通常は受取人のアドレスである公開鍵のハッシュを指定することができ、秘密鍵を所有する公開鍵の所有者は、これを正確に解くことができる。アンロックスクリプトの妥当性確認に使用し得るロックスクリプトは、図１Ｄに詳細に示されるトランザクションアウトプットデータ構造のような、対応するトランザクションアウトプットデータ構造にある。

図１Ｄは、トランザクションアウトプットデータ構造１３６のようなトランザクションアウトプットデータ構造１５０の一例を示す。これは、送られる価値の総額１５２をバイトで含む。総額１５２は、トランザクションインプットにおける利用可能な総額以下の、デジタル通貨のある総額である。いくつかの実施形態は、総額をデジタルトークンで指定することができる。トランザクションアウトプットデータ構造１５０はまた、バイトで表されるロックスクリプトのサイズであるロックスクリプトサイズ１５４を指定するフィールドを含む。トランザクションアウトプットデータ構造１５０はまた、総額を送るために満たす必要がある条件を指定するロックスクリプト１５６を含む。ロックスクリプト１５６およびアンロックスクリプト１４８を一緒に実行することにより、トランザクションインプット１４０およびトランザクションアウトプット１５０により定められたＵＴＸＯの妥当性確認を行うことができる。

図２はＵＴＸＯ２１０の一例を示す。ＵＴＸＯはトランザクションアウトプットがないトランザクションであり、そのため、ＵＴＸＯ２１０のトランザクション構造は、空のトランザクションアウトプット２１６を有する。ＵＴＸＯでは、指定された受取人もロックスクリプトもない。このことは、このトランザクションが、消費される可能性がある潜在的クレジットであることを、意味する。ＵＴＸＯは、システム内のすべてのＵＴＸＯのインメモリコンテナである、一般的にメモリプールとも呼ばれているトランザクションプールで、保持される。ＵＴＸＯベースのシステムにおいて、メモリプールは、システム内の消費（または再譲渡）に利用できる総クレジットを表す。ＵＴＸＯは、メモリプール内に存在するのであってブロックチェーンにはない。なぜなら、クレジットの譲渡をまだ記録していないからである。ＵＴＸＯトランザクション構造２１０はさらに、バージョン番号２１２等のその他のフィールドを含み得る。ＵＴＸＯ２１０はまたインプットフィールド２１４を含み、このインプットフィールドは、１つ以上のインプットを含み得るものであり、１つ以上のトランザクション等のトランザクションによって消費される総額を表し、したがって、いわばＵＴＸＯ２１０において消費するのに利用できる通貨またはクレジットまたは通貨トークンの総額を表す。ＵＴＸＯ２１０はまた、分散型台帳システムまたはブロックチェーン等のシステムにトランザクションを追加できる最も早い時間を定めるロック時間フィールド２１８を含む。

上記トランザクションに加えて、ＵＴＸＯベースのシステムは、ブロックチェーンシステムの各ブロックの最初のトランザクションであるコインベーストランザクション１２４等のコインベーストランザクションを含む。ブロックチェーンにはインプットなしのトランザクションが含まれており、これらは如何なる形態のメモリプールにも存在しない。コインベーストランザクションは、ブロックチェーンおよびそれに対応付けられたプロトコルが、ブロックの妥当性確認に成功したマイナー（miner）に報酬を与えるメカニズムである。マイナーは、ブロックチェーンシステムの参加者であり、ブロックチェーンに含めるのに有効なブロックを提案し、これらのブロックがプロトコルによって受け入れられた場合は報酬を受ける。コインベーストランザクションは、ブロックチェーンにおいてマイナーが受けた報酬を記録する。コインベーストランザクションは、インプットは有しないがアウトプットを有し、ブロックチェーン内のブロックに含まれ記録される。さまざまな実施形態が開示する分散型台帳システムは、コインベーストランザクション以外に、債務トランザクションと呼ばれる別の種類のトランザクションを提供する。いくつかの実施形態において、分散型台帳システムは、債務（debt）トランザクションおよびコインベース（coinbase）トランザクションの双方を含み得る。これは、トランザクションが債務トランザクションである場合はそれぞれ値０および１を保持しトランザクションがコインベーストランザクションである場合はそれぞれ値１および０を保持する、ｆＣｏｉｎｂａｓｅおよびｆＤｅｂｔＴｒａｎｓというフラグを導入することで、解決できる。

図３Ａは債務トランザクション構造３１０の一例を示す。先に述べたように、債務トランザクションは、拡張ＵＴＸＯモデルベースの分散型台帳システムにおいて、マッチングされていないアウトプットを有するクレジットトランザクションおよびマッチングされていないインプットを有するデビットトランザクションという概念によって実現される。そのために、債務トランザクション構造３１０は、バージョン番号フィールド３１２とロック時間フィールド３１８とを含み、これらは、図１Ｂとの関連で先に述べたバージョン番号１３２およびロック時間１３８のフィールドと同様である。債務トランザクション構図３１０はまた、最初はマッチングされていないインプットフィールド３１４を含む。図１Ｂとの関連で述べたように、インプットフィールド３１４は一般的に、現在のトランザクションの親、すなわちトランザクションにおけるクレジットのソースを識別するために使用される。債務トランザクション構造３１０のインプットフィールド３１４はマッチングされておらず、したがって、債務トランザクション構造３１０が表している債務トランザクションは、クレジットを、意図する受取人に、親ソースに十分なクレジットがなくても送ることができる。

さらに、いくつかの実施形態において、債務トランザクションは、総額が等しいクレジットトランザクションをこの債務トランザクションと同時に作成することを必要とする。このトランザクションを債務－クレジットトランザクションと呼ぶ。債務－クレジットトランザクションのトランザクションインプットは、クレジットの作成元である、元の債務トランザクションを指し示す。債務－クレジットトランザクションのアウトプットはマッチングされていないままである。これらにはトランザクションインプットと、マッチングされていないトランザクションアウトプットとがあるので、債務－クレジットトランザクションは、ブロックチェーンプロトコルによってＵＴＸＯとして扱われ、債務者は、このトランザクションを、意図する受取人をアドレスの形態でトランザクションアウトプットのロックスクリプトに記録することにより、通常通りに消費することができる。債務－クレジットトランザクションは、クレジットトランザクションと同様にネットワークにブロードキャストされ、ブロックチェーンプロトコルによってメモリプールに追加される。

図３Ｂは未使用債務－クレジットトランザクション３７０の一例を示す。トランザクション構造３７０は、債務トランザクションへのポインタを有するインプットフィールド３７４を示しており、これはクレジットトランザクションの作成に使用されたものである。未使用債務－クレジットトランザクションはまた、バージョン３７２とロック時間３７８とを含む。未使用債務－クレジットトランザクション３７０のアウトプットフィールド３７６は空である。債務－クレジットトランザクション３７０は、クレジットＵＴＸＯ２１０と同一のトランザクション構造を有し、そのため、プロトコルはこれを同一のやり方で扱う。

本明細書に開示される分散型台帳システムにおけるもう１つの種類のトランザクションは、図１Ａのさまざまな種類のトランザクション１２８との関連で既に述べたような、図３Ｃに示される一部返済済みの債務トランザクションである。債務の一部返済は、債務者が送るクレジットが元の債務総額未満であるときに発生する。一部か全部かに関係なく、返済のメカニズムは、ＵＴＸＯを債務トランザクションのインプットに割り当てることからなる。すなわち、債務者は、ＵＴＸＯを、返済義務がある債務トランザクションのトランザクションハッシュを、クレジット（支払）ＵＴＸＯのロックスクリプトおいて指定することにより、債務トランザクションに送る。クレジット返済トランザクションはネットワークにブロードキャストされる。各ノードは、クレジット返済トランザクションを受けると、トランザクションの妥当性確認の際に、ロックスクリプトを検査することにより、アドレスが、その債務プール内の債務トランザクションのハッシュと一致するか否かを判断する。一致していれば、プロトコルは、クレジット（返済）ＵＴＸＯのロックスクリプトを債務のみのアドレスに置き換え、クレジット返済ＵＴＸＯを、最終的なクレジット発生の元である、債務トランザクションへのインプットとして、記録する。

図３Ｃは、一部が返済された債務トランザクションを、一部返済済みの債務トランザクション構造３５０を有するものとして示す。一部返済済みの債務トランザクション構造３５０は、バージョンフィールド３５２と、クレジットトランザクションへのポインタフィールド３５４または空ではなくクレジットトランザクションを指し示すインプットフィールド３５４と、債務受取人の公開鍵フィールド３５６と、ロック時間フィールド３５８とを含む。バージョン３５２およびロック時間３５８フィールドは、先に述べたものと同じ機能を有する。

一部返済済みの債務トランザクション構造３５０のインプットフィールド３５４において、支払いが部分的なものである場合、クレジット返済ＵＴＸＯのロックスクリプトが、元の債務のみのアドレスに置き換えられ、次に、妥当性確認のためおよび１つ以上のブロック１１２～１１６に含めるために、ブロードキャストされる。一部返済済みの債務トランザクション３５０のインプット３５４は次に、先に述べたやり方で更新されるが、債務プールに残る。債務は、債務トランザクションのトランザクションインプットおよびトランザクションアウトプットの合計が等しい場合に返済されたとみなされる。これは、債務トランザクションのトランザクションインプットにおいて参照されるＵＴＸＯの総額すべてを合計し、債務トランザクションのトランザクションアウトプットの総額すべてを合計し、これらが等しいことを確かめることにより、行うことができる。債務トランザクションは、返済されると債務プールから削除される。このやり方で分散型台帳システムにおける債務を管理することについては後に図１２Ａ～図１２Ｄとの関連で説明する。

以下の図４Ａで述べるように、債務が債務トランザクションの生成を通じて作成されると、新たに生成された債務トランザクションは、その他のノードにブロードキャストされ、債務プールに追加される（５６２）。同時に生成された債務－クレジットトランザクションも、その他のノードにブロードキャストされ、メモリプールに追加される。

図４Ａは、上記ブロックチェーンプロトコルのある実施形態に係る、債務トランザクションおよびコインベーストランザクションの双方が可能な債務トランザクション構造４１０を示す。債務トランザクション構造４１０は、バージョンフィールド４１２と、ロック時間フィールド４１８と、空であるインプットフィールド４１４と、債務受取人の公開鍵４１６と、２つのフラグとしてｆＣｏｉｎｂａｓｅフラグ４２０およびｆＤｅｂｔＴｒａｎｓフラグ４２２とを含む。ｆＣｏｉｎＢａｓｅフラグは、これがコインベーストランザクションであるか否かを識別するために使用される。ｆＣｏｉｎＢａｓｅフラグ４２０が０にセットされた場合、トランザクションはコインベーストランザクションではない。これに加えてまたはこれに代えて、債務トランザクション４１０は、フラグとしてｆＤｅｂｔＴｒａｎｓフラグ４２２を含むことにより、トランザクションが債務トランザクションであるか否かを識別することができる。ｆＤｅｂｔＴｒａｎｓフラグ４２２が１にセットされる場合、このトランザクションは債務トランザクションである。

図４Ｂは、いくつかの実施形態に係るコインベーストランザクション構造４３０を示す。コインベーストランザクション構造４３０は、通常の意味の、フィールドバージョン４３２と、別のフィールドロック時間４３８とを含む。コインベーストランザクション構造４３０が表しているコインベーストランザクションのインプットは、空であるインプットフィールド４３４と、ブロック報酬額およびブロックの公開鍵とを含むアウトプットフィールド４３６とを含む。さらに、コインベーストランザクション構造４３０は、１にセットされたフラグｆＣｏｉｎＢａｓｅフラグ４４０と、０にセットされたｆＤｅｂｔＴｒａｎｓフラグ４４２とを含むことにより、トランザクション構造４３０が表しているトランザクションがコインベーストランザクションであることを示す。コインベーストランザクションの生成と管理については後に図１２Ａとの関連で説明する。

図５Ａは、一実施形態に係る、未払債務トランザクションを管理するための債務プール５００における債務トランザクションの一例を示す。債務プール５００は、債務トランザクション５０１、５０３、および５０７を格納する。新たな債務トランザクション５０９が作成されると、債務プール５００に入れられる（５１１）。債務プール５００は、まだ完全に返済されていないすべての債務トランザクションを含む。債務トランザクション５０５は、完済されると債務プール５００から削除される（５１３）。債務プールから削除された（５１３）、完済されたトランザクション５０５は、プロトコルによって有効トランザクションとみなされ、したがってブロックチェーンを含むブロックに含めることができる。

図５Ｂは、一実施形態に係る、クレジットと同時に債務が作成されることを示す。この実施形態において、債務トランザクション５５０が作成されると、同時に債務－クレジットトランザクション５５２が作成される。新たに生成された債務トランザクションは、その他のノードにブロードキャストされ、債務プール５６１に追加される（５６０）。同時に作成された、そのインプットが債務トランザクション５５０を指し示す（５５４）債務－クレジットトランザクション５５２は、その他のノードにブロードキャストされ、分散型台帳システムのメモリプール５６３に追加される。債務トランザクションを債務プール５００に追加することおよびそこから削除することについては、後に図１２Ｂ～図１２Ｄとの関連で詳細に説明する。上記各種トランザクションは、メッセージを受信しこれらのメッセージをブロックチェーンの１つ以上のブロックになるように処理するためのブロックチェーンプロトコルの実現を可能にするように構成されてもよく、メッセージは、ブロックチェーンに含まれることになるトランザクションに対応付けられ、この対応付けは、このトランザクションのインプットおよびアウトプットを、このトランザクションのインプットが前のトランザクションのアウトプットとマッチングされこのトランザクションのアウトプットが次のトランザクションのインプットとマッチングされるように、近傍のトランザクションとマッチングさせることにより、行われる。上記１つ以上のブロックの構造の説明は既に図１Ａで述べているが、ブロックチェーンプロトコルおよびそれに対応付けられたブロック構造のより詳細な説明を、下記の図６Ａとの関連で述べる。

先に述べたように、分散型台帳システムは、ブロックのハッシュチェーンであるブロックチェーンとして知られているデータ構造によって可能になる。ブロックチェーンは、第１のまたは起源ブロックで始まり、ブロックチェーンに追加される各ブロックは、前のブロックのハッシュを含む。ブロックチェーンにおけるブロックの構造について、図６Ａとの関連で詳細に説明する。

図６Ａは、いくつかの実施形態に係るブロックチェーン構造のブロック６１０の構造を示す。ブロックは、このブロック６１０のサイズをバイトで示すフィールドである、ブロックサイズのフィールド６１２を含む。さらに、このブロック６１０はまた、前のブロックを参照し現在のブロックをサマライズするデータ構造であるブロックヘッダ６１４を含む。

ブロックヘッダ６１４は、ブロックチェーンで使用されるプロトコルのバージョンを追跡するために使用されるバージョン番号を含む（プロトコルのアップグレードを可能にする）。これはまた、ブロックを前のブロックとリンクさせる、前のブロックのハッシュを含む。これはまた、ブロック６１０に含まれるトランザクションの保全性検査に使用されるマークルツリーのルートのハッシュであるマークルルートを含む。ブロックチェーンにおけるトランザクションは、バイナリハッシュツリーまたはマークルツリーの形態で保存される。また、ブロックヘッダ６１４は、ブロックの作成時間のタイムスタンプを含む。いくつかの例において、ブロックヘッダ６１４にはその他のフィールドがある。たとえば、プルーフ・オブ・ワーク（ＰｏＷ）プロトコルに基づいたブロックチェーンシステムにおいて、ブロックヘッダ６１４は、ブロック間の時間およびナンスを制御する特定のプロトコルが設定する難易度ターゲットを含み、これは、現在のブロックのハッシュが難易度ターゲットを満たすようにするためにＰｏＷベースのプロトコルが使用するフィールドである。ブロックは、ブロックチェーンプロトコルが決定した基準を満たす場合に有効とみなされる。ブロック妥当性確認基準の例は、ブロックデータ構造が構文的に有効であること、すなわち、これらが、プロトコルで定められたフィールドを含むこと、ブロックタイムスタンプが未来の２時間未満であること、ブロックサイズが許容可能な限度内であること、最初のトランザクションが唯一のコインベーストランザクションであること、または、ブロックに含まれるすべてのトランザクションが有効であることなどを含む。ＰｏＷベースのブロックチェーンプロトコルにおいて、ブロックは、このブロックのハッシュが難易度ターゲットを満たす場合に有効とみなされる。他方、トランザクションは、特定の実装で定められた基準を満たす場合に有効とみなされる。一種のブロックチェーンシステムであるビットコインからのこのような基準の例は、メモリプール内に一致するトランザクションが存在することを含み、バイトで表されるトランザクションサイズは、ブロックの最大サイズを規定する、独立して定められた値であるＭＡＸ＿ＢＬＯＣＫ＿ＳＩＺＥと呼ばれるパラメータよりも小さく、ｎＬｏｃｋＴｉｍｅと呼ばれるパラメータ（これも図１Ｂ～図４Ｂに関連して先に述べた通り）は、その他の基準のうちでもパラメータＩＮＴ＿ＭＡＸによって定められた値以下である。さらに、ブロック６１０はまた、ブロック６１０に含まれるトランザクションのカウントである、トラザクションカウンタ６１６からなる。

ブロック６１０における次のフィールドはトランザクション６３０である。このフィールドのサイズは可変であってもよく、いくつかの実施形態において、このフィールドは、ブロック６１０におけるすべてのトランザクションのデジタル指紋を含み得る。トランザクション６３０は、コインベーストランザクション６３２およびその他のトランザクション６３４のうちの１つ以上であってもよく、その他のトランザクションは、クレジットトランザクション、クレジット－債務トランザクション、および完済債務トランザクションを含む。たとえば、トランザクション６３０は、図１Ａとの関連で述べた、クレジットトランザクション１１８、デビットトランザクション１２０、振替トランザクションおよびコインベーストランザクション１２４を含み得る。トランザクションは、ブロックチェーンネットワークのベースを形成し、ブロックチェーンネットワークの１以上の参加者間で実行される。

ブロックチェーンネットワークの参加者はノードと呼ばれる。すべてのノードは、ブロックチェーンのコピー、トランザクション、およびトランザクションプール等のインメモリデータ構造を含む。分散型台帳システムにおいて、すべてのノードは、トランザクションと１つ以上のブロックとを検証するプロセスを実行する。トランザクションまたはブロックが有効であれば、これをネットワーク内のその他のノードに転送してもよい。このことは、ブロックチェーンネットワークを通してブロック／トランザクションを伝搬することとして知られている。すべてのノードがブロックおよびトランザクションの正当性について妥当性確認するが、特化されたいくつかのノードのみがブロックの作成を通してトランザクションをファイナライズする。これらのノードは、ブロック作成者として知られており、新たなブロックの作成を担っている。これらは、ノードがそのブロックチェーンのコピー追加する、新たなブロックを提案し作成する。ノードは、トランザクション総額とノード識別子とを含むトランザクションを実行する。ノードがサポートしている各種トランザクションは先に述べた通りである。本明細書に開示されるシステムおよび方法は、ブロックチェーンプロトコルを用いて実行される債務トランザクションを、インプットとして親トランザクションを持っていなくても、提供することができる。

図６Ｂは、いくつかの実施形態に係る、公開鍵を用いて債務のみのアドレスを生成する方法の概略図の一例を示す。アドレスが債務のみであることを表すために、異なる実施形態は異なる実装例を使用した。たとえば、一実施形態は、債務のみのアドレスを、Ｂａｓｅ５８Ｃｈｅｃｋベースのアドレス生成システムにおいてＢａｓｅ５８Ｃｈｅｃｋバージョンプレフィックスを値ｄに設定する（６５０）ことによって実装する。すなわち、公開鍵Ｋが与えられると、対応する債務アドレスは以下を設定することによって生成できる。

この例において、クレジットアドレスは適切なやり方で生成される。

いくつかのＵＴＸＯベースのプロトコルにおいて、アドレスは、システム内のクレジットの受取人を表す。たとえば、ＵＴＸＯベースのプロトコルは、クレジットを、トランザクションアウトプットのロックスクリプトフィールドにおいてクレジットのある受取人を表すアドレスを指定することにより、譲渡することができる。アドレスは、一人の受取人を表すことができる。これに加えてまたはこれに代えて、アドレスは、クレジットの消費のために満たされねばならないより複雑な条件を表すことができる。ＵＴＸＯベースのプロトコルは、十分なクレジットを有するアドレスから、ＵＴＸＯすなわち既存のＵＴＸＯを介して、クレジットが消費されることを要求してもよい。

各種実施形態のシステムおよび方法に関連して開示された債務－クレジットＵＴＸＯベースのシステムにおいて、債務のみのアドレスは、総額を、債務アドレスに対応付けられたＵＴＸＯを有することなく送ることができるアドレスである。債務－クレジットＵＴＸＯベースのシステムが、参加者を、債務を引き受けるための条件を満たしたとみなした場合、債務－クレジットＵＴＸＯベースのシステムは、対応付けられたアドレスに譲渡される債務を生成する。債務を引き受ける条件の一例は、債務－クレジットネットワーク自体への参加によるものであり、これは、ネットワークが債務を参加者に譲渡することについての暗黙の合意を形成し得る。事実上無制限の債務総額を引き受けることによりクレジットを自在に生成することができる中央銀行の場合を考慮されたい。参加者が債務を引き受ける条件のもう１つの例は、参加者が、債務に対して要求されるクレジットの特定の総額を既に所有していることである。銀行が所有する債務の総額が、その銀行が所有するクレジットの総額の倍数である、フラクショナルリザーブバンキング（fractional reserve banking）の場合を考慮されたい。

債務－クレジットＵＴＸＯベースのシステムにおいて、債務は、図３Ａ、図４Ａおよび図４Ｂで述べたような、マッチングされていないトランザクションインプットを有するトランザクションとして実現される。本明細書に開示される債務－クレジットＵＴＸＯベースのシステムに対応付けられたブロックチェーンプロトコルは、最初に、債務を表す債務トランザクションを生成する。これは、トランザクションインプットなしのトランザクションである。この債務トランザクションのトランザクションアウトプットは、債務の期間に従って記入され、このアウトプットにおける「総額」フィールドは債務総額であり、ロックスクリプトは債務の受取人のアドレスを含む。債務をこのようにして表すことで、図５Ａに示されるように債務プール内で債務を直接表す機会を提供する。

ブロックチェーンプロトコル内で債務を直接表すことにより、ブロックチェーンプロトコルの保全性を改善する。債務を実現する代替方法は、さらなる複雑さを導入し、これは、プロトコルの有用性を減じ失敗の可能性を高める。債務を実現するための、普及している非中央集権型方法は、コンピュータコードによって実施される契約であるスマートコントラクトを用いる。スマートコントラクトは、プロトコルを操作し共通プログラミング言語を解釈およびコンパイルするノードによって可能にされる。このような言語の一例は、イーサリアム（Ethereum）ブロックチェーンが使用するＳｏｌｉｄｉｔｙである。Ｓｏｌｉｄｉｔｙは、Ｃ＋＋等の他のコンピュータ言語のような汎用性がなく、その点が制限になる。実施形態は、何らかの特定のコンピュータ言語に限定されないので、Ｃ＋＋または所望のその他任意のプログラミング言語で記述されたスマートコントラクトに適用することができる。債務を表すためにその他のメカニズムを使用すると、不必要な複雑さが加わり、ＣＰＵサイクル、コンピュータメモリ、ネットワーク帯域幅などの形態の、追加の不必要な計算リソースが必要になる。これは、無駄なことであり、ブロックチェーンのサイズが相当なものになったときには大問題になり得る。逆に、本明細書に開示される債務－クレジットＵＴＸＯベースのシステムでは、システム内で債務を直接表すことで、債務をシステム内において自然なやり方で操作することができる。

図７は、分散型台帳システムにおいて債務を実現するための、債務－クレジットＵＴＸＯベースのシステムの債務ベースのブロックチェーンプロトコルスタックを示す、一例としての図を示す。債務ベースのブロックチェーンプロトコルスタック７０２は、インフラストラクチャ層７１２と、オーバレイネットワーク層７１４と、プロトコル層７１６と、テクノロジー層７１８と、アプリケーション層７２０とを含む。ブロックチェーンプロトコルスタック７０２は、債務ベースのブロックチェーンプロトコルスタック７０２が定める債務ベースのブロックチェーンプロトコルに従って各種トランザクションを行うように構成し得る各種ノード７２２と通信することができる。債務ベースのプロトコルを、債務ベースのブロックチェーンプロトコルのクライアント７３２に対応付けられたユーザであってもよいノード７２２が使用してもよく、クライアントは、サービスプロバイダ、１ユーザ、小売チェーン、銀行、金融機関などであってもよい。いくつかの実施形態において、クライアント７３２は、１つ以上のノード７２２と同じであってもよい。そのために、クライアント７３２およびノード７２２は、１つのエンティティとして表すことができる。

インフラストラクチャ層７１２は、各種デバイスの管理のため、および、基礎となる接続デバイス、モデム、ルータ、バスインターフェイスシステムなどのような接続のために、使用することができる、物理インターフェイス層であってもよい。オーバレイネットワーク層７１４は、ネットワーク７４２等の既存のネットワークに対してオーバレイネットワークとして作用するブロックチェーンの実現のために使用される。

プロトコル層７１６は、たとえばブロックの最も更新されたコピーでブロックチェーンを更新するために、各種ノード７２２間の合意を形成するためのメカニズムの構築に使用されてもよい、合意プロトコル７５２モジュールを含み得る。それ以外に、プロトコル層７１６は、さまざまな参加アルゴリズム、仮想メモリ管理、フォールト・リカバリ管理機能などをカバーするために使用されてもよい。プロトコル層７１６は、プルーフ・オブ・ワーク（ＰＯＷ）、プルーフ・オブ・経過時間（proof of elapsed time）（ＰＯＥＴ）、委任プルーフ・オブ・ステーク（delegated proof of stake）（ＤＰＯＳ）、ビザンチン合意（byzantine agreement）（ＢＡ）、プルーフ・オブ・ヒストリー（proof of history）（ＰＯＨ）などのようなアルゴリズムを含み得る。

テクノロジー層７１８も同様に、各種サービスを提供することにより、トランザクション管理、クレジットおよび債務トークンの管理、債務プールおよび債務のみのアドレスの作成および管理、インプットトランザクションおよびアウトプットトランザクション等のトランザクションの記録の保持などを提供するために使用することができる。テクノロジー層７１８はさらに、仮想メモリ管理、ブロックチェーン更新フィード管理、スマートコントラクト、ウォレットなどの機能を提供するために使用することができる。

アプリケーション層７２０は、債務ベースのブロックチェーンプロトコルのインターフェイス管理機能を提供するために使用することができる。いくつかの実施形態は、非中央集権型アプリケーション、アプリケーションホスティング特徴および各種ユーザインターフェイスメカニズムに対して使用し得る、ｄＡｐｐブラウザの場合のような、ブラウザ管理を含むアプリケーション層７２０を提供するために使用することができる。アプリケーション層７２０は、いくつかの実施形態において、分散型台帳システムをサービスとしてのソフトウェア（ＳａａＳ）アーキテクチャでクライアント７３２に提供するために使用することもできる。アプリケーション層７２０は、クライアントシステムがブロックチェーンネットワーク上でピアツーピアサーバネットワークを用いて接続できるようにする、非中央集権型アプリケーションまたはｄＡｐｐｓに対するサポートを提供することもできる。

債務ベースのブロックチェーンスタック７０２は、図８に関して説明する分散型台帳システムを実現するのに役立ち得る。

図８は、いくつかの実施形態に係る、分散型台帳システムアーキテクチャ８０２のブロック図を示す。分散型台帳システムアーキテクチャ８０２は、ネットワーク８１８を介して通信可能に接続される、分散型台帳システム８１２と、１つ以上のデータベース８１４と、クライアント８１６とを含む。分散型台帳アーキテクチャ８０２は、図７に記載の債務ベースのブロックチェーンプロトコルスタック７０２を実現するように構成することができる。したがって、分散型台帳システム８１２は、債務ベースのブロックチェーンプロトコルスタック７０２を提供するのに必要な債務トランザクションおよび債務のみのアドレスを提供することができる。以下、分散型台帳システム８１２を、同義で、債務ベースの分散型台帳システム８１２と呼ぶ場合がある。債務ベースの分散型台帳システム８１２のクライアント８１６は、ブロックチェーンによって可能にされるネットワークのサービスにアクセスする必要がある１以上のサービスプロバイダのうちのいずれかであってもよい。たとえば、クライアント８１６は、金融サービスプロバイダ、銀行、小売商、エネルギーサービス企業、サプライチェーンベンダー、製造部、行政または規制機関などのうちの１つ以上を含み得る。クライアント８１６はさらに、債務ベースの分散型台帳システム８１２の参加者またはノードとして機能し得る、そのサービスの複数の顧客またはユーザを含み得る。これらのノードは、債務ベースの分散型台帳システム８１２によって実現され債務管理機能を提供できる、ブロックチェーンプロトコルスタック７０２のユーザとしての、図７との関連で先に述べたノード７２２と同様であってもよい。債務ベースの分散型台帳システム８１２は、図１Ａ～図４Ｂとの関連で先に述べたトランザクションをサポートし、かつ、図５Ａ～図７に開示されるブロックチェーンネットワークの債務管理機能との関連で述べた特徴およびコンポーネントのすべてをサポートする。

また、債務ベースの分散型台帳システム８１２はデータベース８１４を含んでいてもよく、このデータベースは、リレーショナルアーキテクチャ等の、ブロックチェーンアーキテクチャ以外の別のアーキテクチャに基づくデータベースであってもよく、サーバ情報、第三者リソース、外部規制およびコンプライアンス関連情報などのような、クライアント情報以外のその他の情報を含み得る。分散型台帳アーキテクチャ８０２におけるすべてのコンポーネントは、ネットワーク８１８を介して通信可能に接続することができる。ネットワーク８１８は、有線ネットワークまたは無線ネットワークのいずれであってもよい。債務ベースの分散型台帳システム８１２について、図９との関連で内部コンポーネントの概要を提供するために、より詳細に説明する。

図９は、いくつかの実施形態に係る、図８の債務ベースの分散型台帳システム８１２のブロック図を示す。分散型台帳システム８１２は、プロセッサ９１２と、債務プール９１８を含むメモリ９１４と、通信インターフェイス９１６とを含む。

プロセッサ９１２は、シングルコアプロセッサ、マルチコアプロセッサ、コンピューティングクラスタ、または任意の数のその他の構成であってもよい。プロセッサ９１２は、バスを通して、Ｉ／Ｏデバイスおよびハードウェア等の１つ以上の通信インターフェイス９１６システムに接続される。Ｉ／Ｏデバイスは、コンピュータ、ラップトップ、ハンドヘルド装置、モバイルデバイス、スマートフォン、デスクトップ、ＰＤＡ、メディアデバイス、ナビゲーション機器などのうちのいずれか１つを含み得る。

メモリ９１４は、ランダムアクセスメモリ（ＲＡＭ）、読出専用メモリ（ＲＯＭ）、フラッシュメモリ、またはその他任意の適切なメモリシステムを含み得る。メモリ９１４は、債務ベースの分散型台帳システム８１２におけるすべての未処理の債務トランザクションの記録を含む債務プール９１８を含む。債務が返済されると、その対応する債務トランザクションが債務プール９１８から削除され、債務が引き受けられるたびに新たなトランザクションが債務プール９１８に追加される。債務トランザクション以外に、メモリは、クレジットトランザクション、債務クレジットトランザクションなどのようなその他のトランザクションすべての記録を保持するように構成されてもよい。これらのトランザクションは、図５Ｂに関連して述べたメモリプールに保存されてもよい。メモリプールおよび債務プールは、いくつかの実施形態ではメモリ９１４内の別々の部分として保存されてもよい。

図１０は、いくつかの実施形態に係る、債務ベースの分散型台帳システム１００２の、一例としてのアーキテクチャを示す。債務管理特徴を有する分散型台帳システム１００２は、ノード１０１０および１０１２を含み、各ノードは、自身の分散型台帳９０２のコピーを有し、また、ブロックチェーンオーバレイネットワーク１０１４に通信可能に接続される。分散型台帳システム１００２はまた、ネットワーク８１８およびクライアント８１６を含む。分散型台帳システム１００２に示されるノードの数は、例示のために２つだけであるが、さまざまな実施形態の範囲から逸脱することなく任意の数のノードを分散型台帳システム１００２に追加することができる。ノード１０１０および１０１２を、図８で述べた債務ベースのブロックチェーンプロトコルを用いて相互通信するように使用してもよい。たとえば、ノード１０１０は、メッセージを債務ベースの分散型台帳システム９０２に送信するように構成されてもよく、分散型台帳システム９０２は、これらのメッセージを、分散型台帳システム１００２を用いて債務管理を提供するために、受信および処理するように構成されてもよい。いくつかの実施形態において、分散型台帳システム１００２および債務ベースの分散型台帳システム９０２は同一であってもよい。

ノード１０１０および１０１２は、上記各種トランザクション、たとえば、債務トランザクション３１０または４１０、一部返済済みの債務トランザクション３５０、未使用の債務クレジットトランザクション３７０を実行するように、またはコインベースのトランザクション４３０でさえ実行するように、構成されてもよい。分散型台帳システム１００２は、これらのトランザクションを用いて債務管理を提供するように構成されてもよい。

図１１は、いくつかの実施形態に係る、分散型台帳システムにおける債務管理の方法１１００の、一例としてのブロック図を示す。この方法１１００は、１１１０においてクレジットトランザクションを生成することを含む。たとえば、クレジットトランザクションは、ＵＴＸＯベースのシステムにおけるクレジットトランザクションと同一であってもよい。クレジットトランザクションは、インプットとアウトプットとの両方を有し得るものであり、インプットはクレジットの送り主を指し示すことができ、アウトプットはクレジットの受取人を指し示すことができる。この方法はさらに、１１２０においてクレジット振替トランザクションを生成することを含み得る。クレジット振替トランザクションは、ノード１０１０および１０１２のような少なくとも２つのノードが関与するトランザクションであってもよい。クレジットの、ノード１０１０からノード１０１２への振替は、ノード１０１２で受信されるクレジットトランザクションのインプットフィールドにノード１０１０のアドレスを記載し、ノード１０１０で発生する対応するデビットトランザクションのアウトプットフィールドにノード１０１２のアドレスを記載することで、行うことができる。クレジット振替の特別な場合として、ノード１０１０は利用できる十分なクレジットまたは消費可能なＵＴＸＯの額を有しておらずしたがってこのクレジット振替を実行するために債務を引き受ける必要がある場合を挙げることができる。この場合、１１３０において、インプットとしての親トランザクションがないデビットトランザクションが生成される。ノード１０１０が債務を必要とする場合、１１３０で生成されるデビットトランザクションのアウトプットはノード１０１０を指し示すことになる。同時に、生成された債務トランザクションは債務プール５００のような債務プールに追加されてもよい。さらに、対応するトランザクションが生成されると、債務ベースの分散型台帳システム９０２のようなブロックチェーンシステムは、１１４０において、生成されたトランザクションによって更新されてもよい。これに加えてまたはこれに代えて、分散型台帳システム９０２はまた、図１２Ａ～図１２Ｄを参照しながらさらに説明するように、コインベーストランザクションに対応付けられた一連のイベントを記述する各種メッセージを交換することを含み得る。

図１２Ａは、ネットワークに受け入れられたコインベーストランザクションを伴うブロックチェーンシステムの実施形態において発生する一連のイベントを記述する方法１２００の、一例としてのブロック図を示す。このような実施形態は、たとえばマイニングベースのブロックチェーンシステムで起こり得る。図１Ａおよび図４Ｂで述べたコインベーストランザクション１２４のようなコインベーストランザクションが生成された場合、方法１２００は、ステップ１２０１において、コインベーストランザクションに対応付けられた１つ以上のブロックの妥当性確認を行うことを含み得る。ブロックは、妥当性確認基準を満たすと、１２０３においてネットワークに受け入れられる。さらに、妥当性確認されたブロックまたは妥当性確認された１つ以上のブロックは、次に、１２０５においてネットワーク内のすべてのノードに伝搬される。コインベーストランザクションは、マッチングされていないインプットおよびアウトプットを有するトランザクションなので、アウトプット、すなわちクレジットトランザクションを表すＵＴＸＯは、１２０７において各ノードのメモリプール内に移される、すなわち、ＵＴＸＯデータ構造は、１つ以上のノードのうちの各ノードのメモリプールに保存される。そうすると、メモリプールにおいて一度、ＵＴＸＯにおけるアンロックスクリプトを解くことができるコインベース報酬の受取人による使用が可能になる。

図１２Ｂは、債務トランザクションが生成されたときに発生する一連のイベントを記述する方法１２１０の、一例としてのブロック図を示す。これは、１２１１においてユーザが債務生成要求を開始したときに始まる。いくつかの実施形態において、許可を要求する行為は、債務トランザクションの開始を試みる行為である可能性があり、プロトコルは、ユーザがそうするのに十分な許可を持っているか否かを判断する。その他の可能な実施形態は、ユーザが許可を得るために受けねばならない特殊な特権を備えたノードを含み得る。１２１３において許可がユーザによって検証されると、次に、１２１５において債務トランザクションが債務－クレジットトランザクションとともに生成され、１２１５においてネットワークに伝搬される。次に、１２１７において各ノードが債務トランザクションをその債務プールに追加する。債務－クレジットトランザクションは、有効なクレジットトランザクションであり、ブロックに含める候補である。したがって、１２１９において、有効なトランザクションは対応するブロックに対応付けられる。適切に対応付けが行われて初めて、ブロックは、トランザクションをブロックチェーン上のブロックに含めることで、ブロックチェーンに記録される。さらに、１２２０において、債務トランザクションのアウトプットは、すべてのノードにより、メモリプールに移される。

図１２Ｃは、債務トランザクションが支払われるときに発生する一連のイベントを記述する方法１２４０の、一例としてのブロック図を示す。いくつかの実施形態において、ユーザがある債務を返済すると決断してもよく、ユーザは、これを、債務トランザクションにおける未処理の債務の合計未満である額を含むクレジットトランザクションを、債務トラザクションに、債務トランザクションのハッシュをロックスクリプトに指定することによって送ることで、行う。分散型台帳システムは、このようなトランザクションの交換が発生したときに、送信アドレスが債務のみのアドレスと一致するか否かを検査することによって１２４１で始まる方法１２４０に記載されている一連のイベントを実行するように構成されてもよい。債務のみのアドレスが検査されると、１２４３において、これはネットワーク内の複数のノードにブロードキャストされる。複数のノードは、このクレジット返済トランザクションを受けると、１２４５において、ロックスクリプトの検査を実行することにより、アドレスが、それぞれの債務プール内の債務トランザクションのハッシュと一致するか否かを判断する。一致する場合、この方法は、１２４７において、クレジット（返済）ＵＴＸＯのロックスクリプトを債務のみのアドレスに置き換え、クレジット返済ＵＴＸＯを、対応するノードの債務プール内にある、最終的にクレジットが生成されるソースとなる、債務トランザクションへのインプットとして記録する（１２４７）。その後、１２４９において、この方法は、債務が完全に返済されたか否かを、インプットに含まれる額を合計しこれをアウトプットにおける額の合計と比較することによって検査することを含む。インプットの合計がアウトプットの合計未満である場合は、１２５１において何もしない。そうすると、各ノード上の編集後のクレジット返済トランザクションは、ブロックに含まれる候補である有効なトランザクションである。最後に、１２５３において、返済は、ネットワークに首尾よく受け入れられブロックチェーンの一部となったブロックに含められたときに、恒久的なものであるとみなされる。

図１２Ｄは、債務トランザクションが完全に支払われるときに発生する方法１２６０の一連のイベントの、一例としてのブロック図を示す。方法１２６０は、１２６１において、債務トランザクションに対応付けられた第１の総額と、複数の親クレジットトランザクションの各親トランザクションに対応付けられた個々の総額を合計して得られた第２の総額との差を求めることを含む。さらに１２６３において、この差に等しいアウトプット総額を生成することができる。いくつかの実施形態において、この差額を、ロックスクリプトに記入されている総額および変更アドレスに記入することにより、インプットの合計をアウトプットの合計と等しくすることができる。次に、ブロックチェーンプロトコルは、この債務トランザクションは支払われたものと認識することができ、そうすると、債務トランザクションは有効トランザクションと認識されブロックに含める候補になる。したがって、１２６５において、返済済みのアウトプット総額に対応付けられた、生成された返済済みの債務トランザクションが、対応付けのために送信されしたがって１つ以上のブロックに含められる（１２６５）。債務トランザクションが、受け入れられたブロックに含められることでブロックチェーンに記録されると、次に、１２６７において、債務トランザクションは債務プールから削除される。

いくつかの実施形態は、許可に基づいた債務トランザクション作成を提供し、よって、債務ベースの分散型台帳システム９０２における全債務を容易に管理することができ、債務の返済を保証することもできる。さらに、許可は、新たな債務トランザクションの作成時に、債務プールに既に存在している債務トランザクションを参照することにより、与えることができる。いくつかの実施形態は、債務ベースの分散型台帳システム９０２が許可を内部管理するものとする。また、いくつかの実施形態は、新たな債務トランザクションの作成に対する許可を管理するための外部機関または第三者を提供することもできる。上記各種実施形態における債務の生成および管理により、本明細書に開示されるシステムおよび方法は、ＵＴＸＯベースのシステムに勝るさまざまな利点を提供することができる。

上記段落に開示されているシステムおよび方法のさまざまな技術的利点は、上述のさまざまな方法体系から明らかである。具体的には、開示されている、分散型台帳において債務を表すためのシステムおよび方法は、このような機能が欠落している分散型台帳システムの制限を克服する。本明細書に記載の方法体系は、例示という目的のためにクレジットおよび債務トークンという観点から説明しているが、本明細書に記載の分散型台帳システムが、本開示の精神および範囲から逸脱することなく、各種応用分野において役立つことを意図し得る場合には交換単位としてのトークンであってもよい。

上述の分散型債務管理システムは、エネルギー部門、金融機関、銀行、小売用途、不動産用途、サプライチェーンシステムにおける在庫追跡などを含むがこれらに限定されないさまざまな種類の用途に使用することができる。

上述の債務管理のためのブロックチェーンベースの分散型台帳システムは、エネルギー単位の取引に使用することができる。クレジットおよび債務トークンは、それぞれ、消費されたエネルギーまたは必要なエネルギーのデータを表すために使用することができ、分散型台帳システム８０２を用いて取引することができる。クレジットトークンは、消費エネルギーの課金および計測関数の予測に使用することができるのに対し、債務トークンは、エネルギー部門における料金支払、入札、需要予測関数などに使用することができる。ブロックチェーンベースの分散型台帳システム８０２は、非集中型エネルギー取引、排出取引、グリーン証書の形態の報酬およびインセンティブ、グリッドおよびマイクログリッド管理、エネルギーソリューションにおけるＩｏＴに基づいたスマートオートメーション、ユーザ中心またはユーザ定義のスマートコントラクト、電気ｅモビリティなどのような、エネルギー部門におけるその他の同様の機能に使用することもできる。

ブロックチェーンベースの分散型台帳システム８０２は、サプライチェーン管理ソリューションにおいて在庫追跡および管理のために使用することもできる。ブロックチェーンベースの分散型台帳システム８０２を用いて、在庫の各品目を、識別子に対応付けてもよく、保存、保護、および追跡してもよい。

ブロックチェーンベースの分散型台帳システム８０２は、小売、銀行業務、オンラインショッピング、モバイル決済などのようなさまざまな部門で使用することができる、報酬およびインセンティブに基づいたロイヤルティソリューションを実現するために使用することもできる。債務トークンはさらに、小売チェーンサプライヤーによって生成され、その顧客が購入トランザクションを実行するときに購入トランザクションの実行時に引き換えることができる、報酬クーポンを表すために使用することができる。

ブロックチェーンベースの分散型台帳システム８０２はさらに、食品テクノロジー部門において、品質管理、保証、規制条件管理などに使用することができる。クライアントによる食品安全基準違反が発生するたびに、債務トークンの形態のペナルティトークンを発行することができ、これは、ペナルティのしきい値に達した後であってさらにトランザクションが行われる前に返済されなければならない。食品テクノロジー部門における上記およびその他のこのような用途は、食品テクノロジー部門における品質保証、品質管理、および透明性の確保に役立ち得る。

ブロックチェーンベースの分散型台帳システム９０２は、医療記録保存、医師評価管理、およびロバストな医療エコシステムの可用性を保証するためのフィードバック関連アクティビティのために使用することもできる。当業者は、ブロックチェーンベースの分散型台帳システム８０２の上記およびその他の用途を実施することができる。

本明細書は、具体例としての実施形態を提供しているにすぎず、本開示の範囲、利用可能性、または構成を限定することを意図していない。むしろ、具体例としての実施形態の以下の説明は、具体例としての１つ以上の実施形態を実現することを可能にする説明を当業者に提供するであろう。添付されている請求項に記載の、開示されている主題の精神および範囲から逸脱することなく、要素の機能および構成に対して行い得る、さまざまな変更が意図されている。

具体的な詳細は、実施形態の完全な理解を提供するために本明細書において提供される。しかしながら、当業者は、これらの具体的な詳細がなくても実施形態は実施し得ることを理解できる。たとえば、開示されている主題におけるシステム、プロセス、およびその他の要素は、実施形態を不必要な詳細で不明瞭にしないようにするために、ブロック図の形態で構成要素として示されてもよい。他の例では、実施形態を不明瞭にすることを避けるために、周知のプロセス、構造、および技術を、不必要な詳細なしで示すことがある。さらに、各種図面における同様の参照番号および名称は同様の要素を示す。

また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明することもできる。フローチャートは動作を逐次プロセスとして説明することができるが、動作の多くは並列または同時に実行することができる。加えて、動作の順序を並べ替えてもよい。プロセスは、その動作が完了したときに終了してもよいが、論じられていないまたは図に含まれていない追加のステップを有していてもよい。さらに、具体的に記載されているいずれかのプロセスにおけるすべての動作が、すべての実施形態において起こり得る訳ではない。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応する場合、この関数の終了は、この関数が呼び出し関数または主関数に戻ることに対応していてもよい。

さらに、開示されている主題の実施形態は、少なくとも部分的に、手動または自動のいずれかで実現し得るものである。手動または自動による実現は、マシン、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組み合わせの使用を通じて、実行または少なくとも支援し得るものである。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実現される場合、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、機械可読媒体に格納されてもよい。プロセッサ（複数のプロセッサ）が、必要なタスクを実行してもよい。

Claims (20)

1. 分散型台帳システムであって、
   少なくとも１つのプロセッサを備え、前記少なくとも１つのプロセッサは、命令を実行することにより、メッセージを受信しこれらのメッセージを処理してブロックチェーンの１つ以上のブロックにするためのブロックチェーンプロトコルを実現するように構成されており、メッセージは、前記ブロックチェーンに含まれることになるトランザクションに対応付けられ、前記対応付けは、前記トランザクションのインプットを前のトランザクションのアウトプットとマッチングさせ前記トランザクションのアウトプットを次のトランザクションのインプットとマッチングさせるように、前記トランザクションのインプットおよびアウトプットを近隣のトランザクションとマッチングさせることにより、行われ、前記少なくとも１つのプロセッサは、前記メッセージの処理中に、動作を実行することにより、異なる種類のトランザクションを生成するように構成されており、前記異なる種類のトランザクションは、
   前記次のトランザクションとマッチングされるように構成されたマッチングされていないアウトプットを有するクレジットトランザクションと、
   前記前のトランザクションとマッチングされるように構成されたマッチングされていないインプットを有するデビットトランザクションと、
   マッチングされたインプットとマッチングされたアウトプットとを有する振替トランザクションとを含む、分散型台帳システム。
2. 前記少なくとも１つのプロセッサはさらに、前記動作を実行することにより、
   前記ブロックチェーンプロトコルの１つ以上のブロックに対応付けられたコインベーストランザクションを生成し、
   前記生成したコインベーストランザクションの前記１つ以上のブロックを妥当性確認基準に基づいて妥当性確認を行い、
   前記ブロックチェーンプロトコルにおける前記生成したコインベーストランザクションの前記１つ以上のブロックを前記妥当性確認に基づいて受け入れ、
   前記生成したコインベーストランザクションの前記１つ以上のブロックを、前記ブロックチェーンプロトコルに対応付けられた複数のノードに伝搬し、
   伝搬した前記１つ以上のブロックに対応付けられたＵＴＸＯを、前記複数のノードのうちの各ノードのメモリプールに保存する
   ように、構成されている、請求項１に記載の分散型台帳システム。
3. 前記少なくとも１つのプロセッサはさらに、前記動作を実行することにより、
   債務トランザクションの作成を開始し、
   前記債務トランザクションの作成に対応付けられた１つ以上の許可に基づいて前記債務トランザクションを検証し、
   前記債務トランザクションに対応付けられた債務クレジットトランザクションを生成し、
   前記債務トランザクションおよび前記債務クレジットトランザクションを、前記ブロックチェーンプロトコルに対応付けられた複数のノードに伝搬し、
   伝搬した前記債務トランザクションおよび前記債務クレジットトランザクションを、前記ブロックチェーンプロトコルにおける対応するブロックに対応付ける
   ように、構成されている、請求項１に記載の分散型台帳システム。
4. 前記ブロックチェーンプロトコルを実行するために、前記少なくとも１つのプロセッサはさらに、前記動作を実行することにより、前記分散型台帳システムにおける未処理のすべての債務を、前記複数のノードのうちの各ノードの債務プールに保持するように、構成されている、請求項３に記載の分散型台帳システム。
5. 前記ブロックチェーンプロトコルを実行するために、前記少なくとも１つのプロセッサはさらに、前記動作を実行することにより、未処理の債務に対応付けられた債務トランザクションを、クレジットトランザクションを指し示すインプットが前記債務トランザクションに割り当てられた後に、前記債務プールから削除するように構成されている、請求項４に記載の分散型台帳システム。
6. 前記ブロックチェーンプロトコルを実行するために、前記少なくとも１つのプロセッサはさらに、前記動作を実行することにより、前記債務トランザクションのインプットを、複数の親クレジットトランザクションでポピュレートするように構成されている、請求項５に記載の分散型台帳システム。
7. 前記ブロックチェーンプロトコルを実行するために、前記少なくとも１つのプロセッサはさらに、前記動作を実行することにより、
   前記債務トランザクションに対応付けられた第１の総額と前記複数の親クレジットトランザクションに対応付けられた第２の総額との差を求めるように構成されており、前記第２の総額は、前記複数の親クレジットトランザクションのうちの各親トランザクションに対応付けられた個々の総額を合計することによって得られ、
   アウトプット総額に対応付けられた返済済み債務トランザクションを生成し、
   前記返済済み債務トランザクションを前記債務トランザクションに対応付けられた１つ以上のブロックに伝搬し、
   前記１つ以上のブロックに対応付けられた妥当性確認基準に基づいて前記返済済み債務トランザクションを検証し、
   前記妥当性確認基準が満たされたことに基づいて、前記返済済み債務トランザクションを前記債務プールから削除する
   ように、構成されている、請求項６に記載の分散型台帳システム。
8. 前記分散型台帳システムはクライアントに対して作動的に結合され、
   前記クライアントは債務トランザクションをネットワークにブロードキャストするように構成されている、請求項１に記載の分散型台帳システム。
9. 前記債務トランザクションは債務のみのアドレスに対応付けられる、請求項３に記載の分散型台帳システム。
10. 前記債務トランザクションは、前記デビットトランザクションのアウトプットによって満たされる必要がある条件を指定するロックスクリプトを含む、請求項３に記載の分散型台帳システム。
11. 前記条件は、前記アウトプットが消費されることを可能にする基準に対応付けられている、請求項１０に記載の分散型台帳システム。
12. 分散型台帳のための方法であって、前記方法は少なくとも１つのプロセッサを使用し、前記少なくとも１つのプロセッサは、メッセージを受信しこれらのメッセージを処理してブロックチェーンの１つ以上のブロックにするためのブロックチェーンプロトコルを実行するように構成されており、メッセージは、前記ブロックチェーンに含まれることになるトランザクションに対応付けられ、前記プロセッサは、前記メッセージの処理中に、前記方法の、異なる種類のトランザクションを生成するように構成されており、前記方法は、
    次のトランザクションとマッチングされるように構成されたマッチングされていないアウトプットを有するクレジットトランザクションを生成するステップと、
    前のトランザクションとマッチングされるように構成されたマッチングされていないインプットを有するデビットトランザクションを生成するステップと、
    マッチングされたインプットとマッチングされたアウトプットとを有する振替トランザクションを生成するステップとを含む、方法。
13. 前記ブロックチェーンプロトコルの１つ以上のブロックに対応付けられたコインベーストランザクションを生成するステップと、
    前記生成したコインベーストランザクションの前記１つ以上のブロックを妥当性確認基準に基づいて妥当性確認を行うステップと、
    前記ブロックチェーンプロトコルにおける前記生成したコインベーストランザクションの前記１つ以上のブロックを前記妥当性確認に基づいて受け入れるステップと、
    前記生成したコインベーストランザクションの前記１つ以上のブロックを、前記ブロックチェーンプロトコルに対応付けられた複数のノードに伝搬するステップと、
    伝搬した前記１つ以上のブロックに対応付けられたＵＴＸＯを、前記複数のノードのうちの各ノードのメモリプールに保存するステップとをさらに含む、請求項１２に記載の方法。
14. 債務トランザクションの作成を開始するステップと、
    前記デビットトランザクションの作成に対応付けられた１つ以上の許可に基づいて前記債務トランザクションを検証するステップと、
    前記デビットトランザクションに対応付けられた債務クレジットトランザクションを生成するステップと、
    前記債務トランザクションおよび前記債務クレジットトランザクションを、前記ブロックチェーンプロトコルに対応付けられた複数のノードに伝搬するステップと、
    伝搬した前記債務トランザクションおよび前記債務クレジットトランザクションを、前記ブロックチェーンプロトコルにおける対応するブロックに対応付けるステップとをさらに含む、請求項１２に記載の方法。
15. 前記分散型台帳における未処理のすべての債務を債務プールに保持するステップをさらに含む、請求項１２に記載の方法。
16. 未処理の債務に対応付けられた債務トランザクションを、クレジットトランザクションを指し示すインプットが前記債務トランザクションに割り当てられた後に、前記債務プールから削除するステップをさらに含む、請求項１５に記載の方法。
17. 前記債務トランザクションのインプットを、複数の親クレジットトランザクションでポピュレートするステップをさらに含む、請求項１６に記載の方法。
18. 前記債務トランザクションに対応付けられた第１の総額と前記複数の親クレジットトランザクションに対応付けられた第２の総額との差を求めるステップをさらに含み、前記第２の総額は、前記複数の親クレジットトランザクションのうちの各親トランザクションに対応付けられた個々の総額を合計することによって得られ、
    アウトプット総額に対応付けられた返済済み債務トランザクションを生成するステップと、
    前記返済済み債務トランザクションを前記債務トランザクションに対応付けられた１つ以上のブロックに伝搬するステップと、
    前記１つ以上のブロックに対応付けられた妥当性確認基準に基づいて前記返済済み債務トランザクションを検証するステップと、
    前記妥当性確認基準が満たされたことに基づいて、前記返済済み債務トランザクションを前記債務プールから削除するステップとをさらに含む、請求項１７に記載の方法。
19. 前記債務トランザクションに対応付けられるアドレスは、債務のみのアドレスである、請求項１４に記載の方法。
20. 前記債務トランザクションはロックスクリプトを含み、前記ロックスクリプトは、前記アウトプットによって満たされる必要がある条件を含む前記ロックスクリプトに対応する債務者を指定し、前記条件は、前記アウトプットが消費されることを可能にする基準に対応付けられている、請求項１６に記載の方法。

Images