特表 2024-522634 ブロックチェーン上のトークンを検証するためのコンピュータ実装方法およびシステム

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

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

(11)【公表番号】

(43)【公表日】2024-06-21

(54)【発明の名称】ブロックチェーン上のトークンを検証するためのコンピュータ実装方法およびシステム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240614BHJP

   G06F 21/64 20130101ALI20240614BHJP

   G06F 16/28 20190101ALI20240614BHJP

【ＦＩ】

H04L9/32 200Z

G06F21/64

G06F16/28

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023575922

(86)(22)【出願日】2022-05-09

(85)【翻訳文提出日】2024-01-17

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

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

(87)【国際公開日】2022-12-15

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

(32)【優先日】2021-06-09

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】パトリック・スティーヴン・カフラン

(72)【発明者】

【氏名】オーウェン・ヴォーン

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

5B175

【Ｆターム（参考）】

5B175KA12

(57)【要約】

実施形態は、ブロックチェーン上のトークントランザクションを介して提供される1つまたは複数のトークンを検証するための改善された解を提供する。トークントランザクションは発行者によって生成され、トークントランザクションのチェーン内にリンクを形成し、このリンクは、トークンを生成するために発行者によって使用された鋳造トランザクションまで遡って追跡することができる。少なくとも1つの認定要素がチェーン内の1つまたは複数のトークントランザクションにおいて提供され、認定要素は発行者によって、またはその代理としてトークンの信頼性を認証する。検証エンティティは、鋳造トランザクションに戻るのではなく、トークンの履歴チェーンを横断して認定要素を備えるトランザクションに戻るだけで済む。追加的にまたは代替的に、本開示は、あらかじめ定められたしきい値、限界値、または指定された値に達したときに前記トークンを溶解および再鋳造するための改善された解を提供する。溶解および再鋳造は、トークンの履歴のチェーンにおける元の鋳造トランザクションに続く新しい鋳造トランザクションのブロックチェーン上での発行、あるいはその後トークン、発行者、および/あるいは新しいまたは元の鋳造トランザクションを識別するために役立つ識別子などの発行者関連コンポーネントの置換えを備え得る。

【特許請求の範囲】

【請求項1】

少なくとも1つのトークンを生成するために、少なくとも1つの発行者によって、またはその代理として使用される、少なくとも1つの鋳造トランザクションから始まるトークントランザクションのチェーンにおける要素である、トークントランザクションにおいて提供される前記少なくとも1つのトークンの信頼性を是認または証明するブロックチェーン実装方法であって、
前記トークントランザクションにおいて、前記少なくとも1つのトークンが前記少なくとも1つの発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を提供するステップを備える、ブロックチェーン実装方法。

【請求項2】

前記少なくとも1つのトークン認定要素が、
要求または命令に応答して、および/または、
少なくとも1つのあらかじめ定められたルールまたは基準に従って
前記トークントランザクションにおいて提供される、請求項1に記載の方法。

【請求項3】

前記少なくとも1つのあらかじめ定められたルールまたは基準が、トークントランザクションの前記チェーン内の前記トランザクションを識別または選択するためのしきい値、間隔、またはメトリックを指定する、請求項2に記載の方法。

【請求項4】

前記少なくとも1つの認定要素が、前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者によって前記トークントランザクションにおいて提供される、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記少なくとも1つの認定要素が、
前記少なくとも1つの発行者に知られている、または前記少なくとも1つの発行者に関連付けられる秘密のプルーフ、および/または、
暗号データであって、好ましくは、前記暗号データが、前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者に関連付けられた暗号鍵、署名、デジタル署名されたメッセージ、または他の暗号要素であるか、またはそれらを含む、暗号データ
を備える、請求項1から4のいずれか一項に記載の方法。

【請求項6】

前記少なくとも1つの認定要素が前記トークントランザクションにおいて提供され、
前記トランザクションのスクリプト内で、前記スクリプトが前記トランザクションの出力に関連付けられ、
出力のスクリプト内のメタデータとして、
前記トークントランザクションを使用不可能にする命令またはコードに従う、請求項1から5のいずれか一項に記載の方法。

【請求項7】

トークントランザクションの前記チェーン内の少なくとも1つのさらなるトークントランザクションにおいて同じまたは異なる認定要素を提供するステップを備える、請求項1から6のいずれか一項に記載の方法。

【請求項8】

ブロックチェーンにおけるトークントランザクションにおいて提供される少なくとも1つのトークンを検証するブロックチェーン実装方法であって、前記ブロックチェーンは、前記トークンを生成するために、発行者によって、またはその代理として使用される、少なくとも1つの鋳造トランザクションから始まるトークントランザクションのチェーンにおける要素であり、前記ブロックチェーン実装方法が、

前記トークンが前記発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を備えているかどうかを決定するために、前記トークントランザクションを検査するステップ、および/または、
前記トークンが前記発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を備える、前のトークントランザクションが前記チェーン内で識別されるまで、前記ブロックチェーン上のトークントランザクションの前記チェーンを前記トークントランザクションから横断するステップ
を備える、ブロックチェーン実装方法。

【請求項9】

トークントランザクションの前記チェーンを横断する前記ステップが、前記トークントランザクションが前記少なくとも1つのトークン認定要素を備えない場合、およびその場合にのみ実行される、請求項8に記載の方法。

【請求項10】

トークントランザクションの前記チェーンを横断する前記ステップが、
前記少なくとも1つのトークン認定要素を備えるかどうかを決定するために、前記チェーン内のトークントランザクションを検査するステップを備える、請求項8または9に記載の方法。

【請求項11】

前記少なくとも1つの認定要素が、
少なくとも1つの発行者に知られている、または前記少なくとも1つの発行者に関連付けられる秘密のプルーフ、および/または、
暗号データであって、好ましくは、前記暗号データが、前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者に関連付けられた暗号鍵、署名、デジタル署名されたメッセージ、または他の暗号要素であるか、またはそれらを含む、暗号データ
を備える、請求項8から10のいずれか一項に記載の方法。

【請求項12】

ブロックチェーン(150)上のトークントランザクションにおいて提供される少なくとも1つのトークンを発行するブロックチェーン実装方法であって、
あらかじめ定められたしきい値、限界値、または指定された値に達したときに前記トークンを溶解および再鋳造するステップを備える、ブロックチェーン実装方法。

【請求項13】

前記トークントランザクションが、少なくとも1つの発行者(702)によって、またはその代理として発行された少なくとも1つの鋳造トランザクションまで前記ブロックチェーン上で追跡可能である、請求項12に記載の方法。

【請求項14】

前記少なくとも1つのトークンを溶解するステップが、前記トークンがもはや有効ではないことを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備え、および/または、
前記トークンを再鋳造するステップが、前記トークンが有効であるが形式が変更されていることを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備える、請求項12または13に記載の方法。

【請求項15】

前記識別要素が、
識別子および/または暗号データである、ならびに/あるいは、
前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者に関連付けられる、ならびに/あるいは、
ブロックチェーントランザクションにおいて、前記トークントランザクションにおいて、または前記ブロックチェーン外で提供されるストレージリソースにおいて提供される、請求項14に記載の方法。

【請求項16】

供給された値と、前記しきい値、限界値、または指定された値との比較を実行することによって、前記あらかじめ定められたしきい値、限界値、または指定された値に達したかを評価するステップを備える、請求項12から15のいずれか一項に記載の方法。

【請求項17】

前記あらかじめ定められたしきい値、限界値、または指定された値が、前記少なくとも1つの発行者、または前記少なくとも1つの発行者(702)によって認可された当事者、ユーザ(703)または検証エンティティ(701)によって決定される、請求項12から16のいずれか一項に記載の方法。

【請求項18】

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

【請求項19】

コンピュータ可読ストレージ上に具体化され、1つまたは複数のプロセッサ上で実行されると、請求項1から17のいずれか一項に記載の方法を実施するように構成された、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、トークントランザクションを使用して実装されるブロックチェーンベースのトークンを検証、発行、更新、置換、または他の方法で処理するための方法およびシステムに関する。トークントランザクションは、1つまたは複数のトークン出力を備えるブロックチェーントランザクションである。本開示の実施形態は、トークン化された資産がその正当性および認可された当事者による発行を確認するために検証される必要があるシステムに関連して使用するために特に適している。実施形態は、ブロックチェーンベースの転送の効率の向上、処理要件の軽減、およびセキュリティの向上を含むがこれらに限定されない、数多くの技術的利点を提供する。

【背景技術】

【0002】

ブロックチェーンは、分散データ構造の形式を指し、ブロックチェーンの複製コピーが分散ピアツーピア(P2P)ネットワーク(以下では、「ブロックチェーンネットワーク」と呼ばれる)内の複数のノードの各々において維持され、広く宣伝される。ブロックチェーンはデータのブロックのチェーンを備え、各ブロックは1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションに戻る1つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指す。コインベーストランザクションについては、以下でさらに説明する。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含まれる。新しいブロックは、多くの場合「マイニング(mining)」と呼ばれるプロセスによって作成され、このプロセスは、複数のノードの各々が「プルーフオブワーク(proof-of-work)」を実施するために競合すること、すなわち、ブロックチェーンの新しいブロックに含まれることを待っている、順序付けされ検証された保留中のトランザクションの定義されたセットの表現に基づいて暗号パズルを解くことを含む。ブロックチェーンはいくつかのノードにおいて取り除かれる可能性があり、ブロックの公開は単なるブロックヘッダの公開を通じて実現できる点に留意されたい。

【0003】

ブロックチェーン内のトランザクションは、デジタル資産(すなわち、多数のデジタルトークン)を伝達するため、仮想化された台帳またはレジストリ内のエントリのセットを順序付けるため、タイムスタンプエントリを受信して処理するため、および/またはインデックスポインタを時間順にするための目的のうちの1つまたは複数のために使用され得る。ブロックチェーンはまた、ブロックチェーンの上に追加の機能を重ねるために利用することができる。たとえば、ブロックチェーンプロトコルは、追加のユーザデータまたはトランザクション内のデータのインデックスを記憶できる場合がある。単一のトランザクション内に記憶できる最大データ容量には事前に指定された制限がなく、したがって、ますます複雑なデータを組み込むことができる。たとえば、これは電子ドキュメントをブロックチェーンに記憶すること、あるいはオーディオデータまたはビデオデータを記憶することを行うために使用され得る。

【0004】

ブロックチェーンネットワークのノード(「マイナ」と呼ばれることが多い)は、分散トランザクションの登録および検証プロセスを実施し、これについては後で詳しく説明する。要約すると、このプロセス中に、ノードはトランザクションを検証し、有効なプルーフオブワーク解を識別しようとするブロックテンプレートにトランザクションを挿入する。有効な解が見つかると、新しいブロックがネットワークの他のノードに伝搬され、したがって、各ノードが新しいブロックをブロックチェーンに記録できるようになる。トランザクションをブロックチェーンに記録するために、ユーザ(ブロックチェーンクライアントアプリケーションなど)が、伝搬させるためにトランザクションをネットワークのノードのうちの1つに送信する。トランザクションを受信するノードは、検証されたトランザクションを新しいブロックに組み込むプルーフオブワーク解を見つけるために競合する可能性がある。各ノードは、トランザクションを有効にするための1つまたは複数の条件を含む同じノードプロトコルを強制するように構成されている。無効なトランザクションは伝搬されず、ブロックに組み込まれない。トランザクションが検証され、それによってブロックチェーン上で受け入れられると仮定すると、トランザクション(ユーザデータを含む)は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々において登録され、インデックス付けされたままになる。

【0005】

最新のブロックを作成するためにプルーフオブワークパズルを解決したノードは通常、ある額のデジタル資産、すなわち多数のトークンを分散する「コインベーストランザクション」と呼ばれる新しいトランザクションで報酬を与えられる。無効なトランザクションの検出と拒否は、ネットワークのエージェントとして機能する競合ノードのアクションによって強制され、不正行為を報告してブロックするよう促される。情報が広範に公開されるため、ユーザはノードのパフォーマンスを継続的に監査できるようになる。単なるブロックヘッダを公開することにより、参加者はブロックチェーンの継続的な整合性を確保できるようになる。

【0006】

「出力ベース」モデル(UTXOベースのモデルとも呼ばれる)では、所与のトランザクションのデータ構造は1つまたは複数の入力と1つまたは複数の出力を備える。使用可能な出力は、トランザクションの進行シーケンスから導き出されるデジタル資産の額を指定する要素を備える。使用可能出力は、UTXO(「未使用トランザクション出力(unspent transaction output)」)と呼ばれることもある。出力は、将来の出力の引換えのための条件を指定するロックスクリプトをさらに備え得る。ロックスクリプトは、デジタルトークンまたは資産を検証および転送するために必要な条件を定義する述語である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、さらに、示された出力のロックスクリプトのロックを解除するためのロック解除スクリプトを備え得る。したがって、トランザクションのペアを考えると、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定する少なくとも1つの出力を備え、出力のロックを解除する1つまたは複数の条件を定義するロックスクリプトを備える。第2のターゲットトランザクションは、第1のトランザクションの出力へのポインタを備える少なくとも1つの入力と、第1のトランザクションの出力のロックを解除するためのロック解除スクリプトとを備える。

【0007】

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

【発明の概要】

【発明が解決しようとする課題】

【0008】

上で説明したように、暗号通貨の一部(トークン)は、ブロックチェーンのプロトコルによって指定された基盤となる転送メカニズムの一部としてブロックチェーントランザクションに含まれる。しかしながら、ブロックチェーントランザクションはまた、トークン化されて台帳に表示される他の追加資産の所有権や制御を転送するために使用することもできる。本開示の実施形態は、ブロックチェーンネットワークのプロトコルによって必要とされるプロトコルレベルの暗号通貨ではなく、これらの追加トークンの処理に関する。

【0009】

トークンを発行し、使用するためにブロックチェーンを使用すること自体は新しいものではない。知られている手法は、トークンがトランザクションアウトポイントに結合されるUTXOベースの手法において、トランザクション出力を使用した、たとえば、OP_RETURNまたはOP_FALSE OP_RETURNコマンドを使用したトークンの発行を含む。ネイティブブロックチェーンシステムとより連携しているため、UTXOベースのトークンシステムは、トークンのスクリプト内スマートコントラクトなどのセキュリティに加えて、ブロックチェーンシステムのいくつかの有利な機能を共有する。また、トークン発行者が自分のトークン値をネイティブブロックチェーントークン値に固定することもできる。

【0010】

しかしながら、どのトークン化手法を採用する場合でも、認可された発行エンティティによって生成されたことを検証するために、発行されたトークンを検証する必要がある。所与のトークンを検証する必要性は、様々な理由で発生する可能性がある。たとえば、受信側は、受信したトークンが本物であることを確認したいと考える。これは通常、トークン発行者から発信されたことが知られている鋳造データの一部と、トークントランザクションにおいて提供されたデータを比較および検証できるように、トークンのトランザクション履歴を元の(鋳造)トランザクションまで遡って追跡することを含む。

【0011】

しかしながら、技術的な課題は、トークンの履歴のチェーンが時間の経過とともに増大し、ブロックチェーン上でトークンの履歴を鋳造トランザクションまで追跡するために時間と必要な処理リソースの量の点でコストがかかるほど増大する場合に発生する。したがって、特定の条件下では、トークンの履歴が非常に広範囲になり、トークンの継続使用が非現実的になり、リソースの点でコストが高すぎる場合があるまで、トークンの使用の結果として非効率性がトークンの存続期間にわたって蓄積される可能性がある。

【0012】

これが発生した場合、発行者はトークンを破棄するか、現在の形式での使用を中止し、再発行することを選択し得る。このプロセスは、法定通貨システムにおける従来のコインが時間の経過とともに何らかの形で侵害または損傷した場合に溶解するという概念に似ているため、「溶解および再鋳造(melt and re-mint)」動作と言い換えることができる。必要な数の硬貨の流通を維持するために、鋳造当局によって新たに鋳造された代替品を発行することができる。明らかに、溶解および再鋳造の必要性にはコストがかかり、発行当局のリソースを必要とするため、この動作を頻繁に実行しなければならないのは不利である。

【0013】

当技術分野で知られているように、層1ブロックチェーントークンは、スクリプトにトークン検証ルールを埋め込む。これらは、スクリプトが発行までトランザクションのチェーンを遡ってトークンの有効性を証明するように設計することができる。これは、前のトランザクションを解決策として挿入する必要があるハッシュパズルを作成することによって実現される(トランザクションIDはハッシュダイジェストであり、トランザクション自体はハッシュプレイメージである)。しかしながら、各トークントランザクションは必然的に前のトランザクションのすべてのデータを含むため、帰納的には発行までのすべての前のトランザクションを含む必要がある。これは、各トークントランザクションのサイズが累積的に増加することを意味し、チェーン内の最新のトランザクションが非常に大きくなる可能性があることを意味する。したがって、このトランザクションサイズの増加により、帯域幅とストレージの要件、および台帳への書き込みコストに関連するリソースの需要が増加する。

【0014】

したがって、少なくともこれらの理由から、トークン化プロトコルまたは基礎となるブロックチェーンプロトコルによって実装されるセキュリティ機能のいずれも損なうことなく、ブロックチェーン上のトークンの検証と発行の効率を向上させることが望ましい。

【課題を解決するための手段】

【0015】

本開示の一態様によれば、少なくとも、ブロックチェーン実装トークンの信頼性を検証、認定、および/または是認/証明する方法として定義され得る、コンピュータ実装方法が提供される。本明細書では、「認定」は、正当性または信頼性のスタンプ、起源(origin)または出所(provenance)のプルーフ、および/あるいは特定のエンティティによる著作者/作成の確認を含むと理解され得る。「検証」は、ブロックチェーン実装トークンの正当性、信頼性、起源、著作者、認定または出所のチェック、テスト、および/または確認を含むと理解され得る。いくつかの実施形態では、トークンは、トークン検証ルールがトークントランザクションのスクリプト内に埋め込まれている「層1トークン」プロトコルに従って形成および/または処理され得る。

【0016】

本開示の実施形態により、ブロックチェーンベースのトークンを迅速かつ効率的に、またブロックチェーン上のトークンの出所をブロックチェーン上の起源まで遡って追跡する必要なしに、検証することが可能になる。これにより、トークンを処理する当事者(たとえば、送信者、受信者、発行者)が広範なトークン履歴を横断して処理する必要がなくなるため、効率が大幅に向上し、必要なリソースが少なくなる。また、そのようなトークンを交換する必要性が減るか、少なくともその頻度が減るため、使用されるリソースも少なくなる。さらに、本開示の実施形態は、トークンの溶解および再鋳造またはスタンプのいずれかによって、トークントランザクションチェーンにおける最新のトランザクションのサイズのリセットを可能にする。したがって、トランザクションサイズの大幅な節約が達成される。これにより、次に、帯域幅要件、ストレージ要件、および台帳への書き込みコストが削減される。

【0017】

本方法は、トークントランザクションのチェーン内の要素であるトークントランザクションに認定要素を追加するステップを備える。「トークントランザクション」という用語は、少なくとも1つのトークンを備えるブロックチェーントランザクションを含み得、そのトークンは、任意の形式のトークン化された資産を表し、チェーン上またはオフチェーンに記憶され、トークンは、ネットワークノードによって動作される基礎となるブロックチェーンプロトコルとは異なるが、その上に実装されるトークン化プロトコルに従って形成される。

【0018】

トークントランザクションのチェーンは、発行者によって、または発行者に代わって認可された当事者によって、トークンを生成するために使用される鋳造トランザクションから始まる。鋳造トランザクション以降の各トークントランザクションは、チェーン内の次の要素(トークントランザクション)にトークンを渡す。したがって、トークンは、トークントランザクションの形式で、鋳造トランザクションに遡る追跡可能かつ不変の途切れることのない履歴をブロックチェーン台帳上に有する。その履歴のチェーンに沿った特定のトークントランザクションは認定要素を備える。有利なことに、これにより、検証者は信頼できる認定要素を含むチェーン内の最後のトークントランザクションまで履歴をたどるだけで済むため、検証/認定目的でトークンの履歴を元の(鋳造)トランザクションまで遡って追跡する必要がなくなるか、少なくとも軽減される。

【0019】

チェーン内のトークントランザクションの少なくとも1つ、一部、またはすべては、認可されたエンティティ、たとえば、トークン発行者、または発行者に代わってトークンの起源および/または正当性を証明することができる、認可または承認された認定エンティティとして信頼されている他の当事者に直接または間接的に関連付けられる検証可能なマーク、証明書、または信頼性のスタンプとして機能する認定要素を備えている。別の表現によれば、認定要素はスタンプまたは信頼性の確認と呼ばれることもある。

【0020】

認定要素は、発行者に関連付けられる、または発行者によって管理されることが知られている秘密の知識のプルーフを提供し得る。好ましい実施形態では、チェーン内のトークントランザクションのすべてではないが、1つまたは一部が認定要素を備え得る。これには、トークントランザクション内の認定要素の提供に関連付けられる処理コストがかかるため、より効率的になるという利点がある。(今後、「発行者」という用語は、発行者に代わって行動することが認可された他の当事者を含み得る)。

【0021】

いくつかの実施形態では、同じ認定要素がチェーン内の複数のトークントランザクションに提供されてもよい。しかしながら、他の実施形態では、異なる認定要素が、選択されたトークントランザクションの各々または一部に対して提供されてもよい。しかし重要なことは、トークントランザクションにおいて同じ認定要素が使用されるか異なる認定要素が使用されるかに関係なく、認定要素はトークンの起源の証明を容易にするという上記の目的に役立つ。

【0022】

1つまたは複数の実施形態では、認定要素は、発行エンティティと証明可能に関連付けることができる、または発行エンティティによって認可された暗号要素などの暗号データの形式をとる場合がある。これは、たとえば、暗号鍵、または発行者によって関連付けられていることが知られている鍵を使用して署名されたメッセージである可能性がある。当業者であれば、認定要素は、認定要素が発行者によって提供および/または認可されたこと、およびトークントランザクションにおけるその提供がトークンの出所、正当性、および/または信頼性のプルーフまたは証拠として機能することを検証エンティティが確立できるようにする任意の適切な形式をとることができることを容易に理解するであろう。

【0023】

1つまたは複数の実施形態では、認定要素は、たとえばトークンがあらかじめ定められた回数使用された(転送された)ときなど、少なくとも1つのあらかじめ定められたルールまたは基準に従ってトークントランザクションに追加され得る。基準またはルールは、発行者、トークンの所有者/受信者/管理者、または他の当事者によって決定され得る。他の実施形態では、認定要素は、要求、命令、または他の信号に応答してチェーン内のトークントランザクションに追加され得る。この後者のシナリオでは、認定要素の挿入は、規範的な方法ではなく、よりアドホックな方法で実行され得る。

【0024】

1つまたは複数の実施形態では、チェーン内でどのトークントランザクションに認定要素が追加されるかを制御または影響を与えるために、あらかじめ定められたルールまたは基準が使用される場合、認定要素は、100トランザクションごとなどのあらかじめ定められた間隔で、あるいは毎日または毎週などの指定された期間後にチェーンに含まれ得る(この場合、トークンが十分に高い頻度のトランザクションアクティビティに関与すると仮定する)。他の基準およびルールが利用されてもよいが、本質的に、本開示の特定の実施形態は、1つまたは複数のあらかじめ定められたメトリックの使用、またはチェーン(トランザクション)のどの要素に認定要素を追加するかを指定するメトリックの使用を含む。

【0025】

1つまたは複数の実施形態では、認定要素は、当技術分野で知られている任意の適切な方法でトークントランザクションに追加することができる。たとえば、一部のプロトコルでは、これはOP_RETURNの後にある場合があるが、他のプロトコルでは、OP_FALSE OP_RETURNコマンドを含むスクリプト内にある場合がある。他の実施形態では、認定要素は、トークントランザクションの出力のロックスクリプト内で提供されてもよく、および/またはメタデータとして提供されてもよい。当業者であれば、同じ有利な効果を提供するために、トークントランザクションに関連して様々な方法で、およびトランザクション内の様々な場所で、認定要素を提供できることが容易に理解されるであろう。

【0026】

本開示の別の態様によれば、ブロックチェーン実装トークンを提供するコンピュータ実装方法が提供される。長い履歴チェーンに関連する問題を軽減するために、発行者は、トークンのトランザクションにおいて提供された1つまたは複数のトークンを溶解して再鋳造し得、これにより、トークンの以前の履歴は、元の出所と信頼性の検証可能で監査可能な記録としてオンチェーンに残るが、新しい鋳造トランザクションが検証目的で元の鋳造トランザクションに取って代わる。溶解および再鋳造プロセスによって必要とされる処理リソースの量を削減するために、これは定期的な間隔で実行できるため、検証当事者にとっては鋳造トランザクションを遡って追跡するために必要な労力が軽減されるが、発行者/認証当事者にとっては溶解および再鋳造に関連付けられるオーバーヘッドも最小限に抑えられる。

【0027】

溶解および再鋳造プロセスが実行される頻度は、ボット、オラクル、または他のソフトウェアコンポーネントなどの自動リソースによって評価できる、少なくとも1つのルール、基準、またはメトリックに従ってあらかじめ決定することができる。たとえば、トークンは、指定されたしきい値、制限、または測定可能/定量化可能な値に達すると再発行され得る。これは、元のトランザクションまたは最後の鋳造トランザクション以降、ブロックチェーン上のトークンの履歴チェーンに書き込まれたトランザクションの数、またはチェーンに書き込まれたトークントランザクションのx回ごと、または定期的な時間間隔などである。これにより、トークンユーザおよび/または所有者にとって予測可能になるという利点が得られる。あるいは、溶解および再鋳造のプロセスは、アドホックまたはランダム/擬似ランダムベースで実行することもできる。

【0028】

本開示は、トークンの溶解および再鋳造に使用される特定のメカニズムに関して限定されない。一実施形態では、たとえば、トークンに関連付けられ、その履歴における前のトークントランザクションにおいて使用された識別子は、新しい識別子によって置き換えられ得る。

【0029】

追加的にまたは代替的に、実施形態は、ブロックチェーン上のトークントランザクションにおいて提供される少なくとも1つのトークンを発行するブロックチェーン実装方法を備え得る。本方法は、条件が満たされた場合にトークンを溶解および再鋳造するステップを備え得る。この条件は、たとえば、あらかじめ定められたしきい値、限界値、または指定された値に達したか、または識別されたと決定することを備え得る。これには、特定の条件下でトークンの履歴のチェーンを再開できるという利点があり、したがって、前述したような長い履歴の処理に必要なリソースが削減される。したがって、そのような実施形態は、ブロックチェーン実装転送中の記憶、処理、および時間の点で効率が向上し、トークンの信頼性の保証が維持されるため、セキュリティと詐欺に対する保護が維持される。

【0030】

そのような実施形態では、トークントランザクションは、少なくとも1つの発行者によって、またはその代理として発行された少なくとも1つの鋳造トランザクションまで遡ってブロックチェーン上で追跡可能である。少なくとも1つのトークンを溶解することは、トークンがもはや有効ではないことを示すために、識別要素、マーカ、またはデータの他の部分を提供することを備え得る。追加的にまたは代替的に、トークンを再鋳造することは、トークンが有効であることを示すために、識別要素、マーカ、またはデータの他の部分を提供することを備え得る。識別子は、トークンが再鋳造されたという表示を提供し得、および1つまたは複数の前のバージョンに対して修正された形式で提供され得る。

【0031】

識別要素は、たとえば、識別子および/または暗号データなどの任意の適切な形式をとることができる。これは、少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者に関連付けることができ、ブロックチェーントランザクションにおいて、トークントランザクションにおいて、またはブロックチェーン外で提供されるストレージリソースにおいて提供することができる。

【0032】

あらかじめ定められたしきい値、限界値、または指定された値に達したか、あるいは遭遇したかを評価するステップは、供給された値または計算された値と、しきい値、限界値、または指定された値との比較を実行するステップを備え得る。あらかじめ定められたしきい値、限界値、または指定された値は、少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者、ユーザまたは検証エンティティによって決定され得る。

【0033】

本開示の方法は、コンピューティング機器を備えるシステムにおいて実装することができる。これは、
1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置と
を備え、メモリが、処理装置上で実行されるように構成されたコードを記憶し、コードが、処理装置上にあるときに、本明細書に開示または請求されるいずれかの実施形態の方法を実施するように構成されている。

【0034】

本開示はまた、コンピュータ可読ストレージ上に具体化され、1つまたは複数のプロセッサ上で実行されると、本明細書に開示または請求されるいずれかの実施形態の方法を実行するように構成されたコンピュータプログラムも提供する。

【0035】

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

【図面の簡単な説明】

【0036】

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

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

【図3A】クライアントアプリケーションの概略ブロック図である。

【図3B】図3Aのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略的なモックアップを示す図である。

【図4A】2つのトランザクションチェーンによって分割された有向非巡回グラフとしてブロックチェーン台帳を概略的に示す図である。

【図4B】各ブロックが新しいコインベーストランザクションを含むブロックチェーンとしてのブロックチェーン台帳を概略的に示す図である。

【図5】アウトポイント署名有向非巡回グラフの例を概略的に示す図である。

【図6】ブロックチェーンネットワークに接続するトークンネットワークの例を概略的に示す図である。

【図7】本発明の実施形態を実装するための例示的なシステムを概略的に示す図である。

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

【0037】

例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示している。システム100は、パケット交換ネットワーク101、通常はインターネットなどの広域インターネットワークを備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)ネットワーク106を形成するように配置され得る複数のブロックチェーンノード104を備える。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフとして配置され得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104と高度に接続されている。

【0038】

各ブロックチェーンノード104は、ピアのコンピュータ機器を備え、ノード104のうちの異なるノードは異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)と、特定用途向け集積回路(ASIC)などのその他の機器とを備える処理装置を備える。各ノードはまた、メモリ、すなわち非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を使用する1つまたは複数のメモリユニットを備え得る。

【0039】

ブロックチェーン150は、データブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散またはブロックチェーンネットワーク106内の複数のブロックチェーンノード104の各々に維持される。上述したように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150を完全に記憶することを意味するわけではない。代わりに、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(後述)を記憶する限り、ブロックチェーン150からデータを取り除くことができる。チェーン内の各ブロック151は、1つまたは複数のトランザクション152を備え、この文脈におけるトランザクションは、ある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプによって異なる。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを使用する。1つの一般的なタイプのトランザクションプロトコルでは、各トランザクション152のデータ構造は、少なくとも1つの入力と少なくとも1つの出力を備える。各出力は、資産としてデジタル資産の数量を表す金額を指定し、その例としては、出力が暗号的にロックされているユーザ103がある(ロックを解除し、それによって償還または使用するためには、そのユーザの署名または他の解が必要である)。各入力は、先行するトランザクション152の出力を指し、それによってトランザクションがリンクされる。

【0040】

各ブロック151は、ブロック151への連続的な順序を定義するために、チェーン内で以前に作成されたブロック151を指すブロックポインタ155も備える。各トランザクション152(コインベーストランザクション以外)は、トランザクションのシーケンスへの順序を定義するために、前のトランザクションへ戻るポインタを備える(注意:トランザクション152のシーケンスは分岐することができる)。ブロック151のチェーンは、チェーン内の第1のブロックであったジェネシスブロック(Gb)153まで遡る。チェーン150内の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくジェネシスブロック153を指していた。

【0041】

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

【0042】

所与の現在のトランザクション152jにおいて、入力(または、各入力)は、トランザクションのシーケンスにおける先行するトランザクション152iの出力を参照するポインタを備え、この出力が、現在のトランザクション152jにおいて償還または「使用(spent)」されるべきであることを指定する。一般に、先行するトランザクションは、順序付きセット154内の任意のトランザクションまたは任意のブロック151である可能性がある。先行するトランザクション152iは、現在のトランザクションが有効となるために、存在し、検証される必要があるが、先行するトランザクション152iが現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも、必ずしも存在する必要はない。したがって、本明細書における「先行する(preceding)」は、ポインタによってリンクされた論理シーケンスにおける先行するもの(predecessor)を指し、必ずしも時系列における作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同に作成または送信されることを必ずしも排除するものではない(オーファントランザクションに関する以下の説明を参照)。先行するトランザクション152iは、先のトランザクション(antecedent transaction)または先行したトランザクション(predecessor transaction)と同様に呼ぶことができる。

【0043】

現在のトランザクション152jの入力はまた、入力権限、たとえば、先行するトランザクション152iの出力がロックされているユーザ103aの署名を備える。次に、現在のトランザクション152jの出力は、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行するトランザクション152iの入力において定義された額を、現在のトランザクション152jの出力において定義されたように、新しいユーザまたはエンティティ103bに転送することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(残り(change)を与えるために、そのうちの1人が元のユーザまたはエンティティ103aであり得る)間で入力額を分割するための複数の出力を有し得る。場合によっては、トランザクションはまた、1つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することができる。

【0044】

ビットコインのような出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの当事者103が、(手動で、または当事者が採用する自動プロセスによって)新しいトランザクション152jを制定したい場合、制定当事者は、そのコンピュータ端末102から受信者に新しいトランザクションを送信する。制定当事者または受信者は、最終的にこのトランザクションをネットワーク106の1つまたは複数のブロックチェーンノード104(今日では、典型的にはサーバまたはデータセンタであるが、原則として他のユーザ端末でもよい)に送信することになる。また、新しいトランザクション152jを制定する当事者103が、トランザクションをブロックチェーンノード104のうちの1つまたは複数に直接送信し、場合によっては受信者に送信しない可能性も排除されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、通常、新しいトランザクション152j内の暗号署名が、順序付けられたトランザクション152のシーケンス内で前のトランザクション152iに依存する、予想される署名と一致することをチェックすることをブロックチェーンノード104に要求する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション152jの入力に含まれる当事者103の暗号署名または他の許可が、新しいトランザクションが割り当てる先行するトランザクション152iの出力において定義された条件と一致することをチェックすることを備えてよく、この条件は通常、新しいトランザクション152jの入力における暗号署名または他の認可が、新しいトランザクションの入力がリンクされている前のトランザクション152iの出力のロックを解除することをチェックすることを少なくとも備える。条件は、先行するトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。あるいは、ブロックチェーンノードプロトコルだけによって単純に固定されてもよく、これらの組合せによるものであってもよい。いずれにしても、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用し、したがって、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送し、以下同様である。このようにして、新しいトランザクションはブロックチェーンノード104のネットワーク全体に伝搬される。

【0045】

出力ベースのモデルでは、所与の出力(たとえば、UTXO)が割り当てられているか(たとえば、使用されているか)の定義は、ブロックチェーンノードプロトコルに従って、その出力が別の後続のトランザクション152jの入力によってまだ有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、償還しようと試みる先行するトランザクション152iの出力が別のトランザクションによってまだ償還されていないことである。同様に、有効でない場合、トランザクション152jは(無効としてフラグが立てられ、警告のために伝搬されない限り)ブロックチェーン150に伝搬も記録もされない。これは、取引者が同じトランザクションの出力を複数回割り当てようとする二重支出を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重支出を防止する。ここでも、トランザクション順序が定義されているため、アカウント残高は常に単一の定義された状態にある。

【0046】

トランザクションの検証に加えて、ブロックチェーンノード104はまた、「プルーフオブワーク」によってサポートされる、一般にマイニングと呼ばれるプロセスにおいてトランザクションのブロックを最初に作成しようと競合する。ブロックチェーンノード104において、新しいトランザクションが、ブロックチェーン150上に記録されたブロック151にまだ現れていない有効なトランザクションの順序付きプール154に追加される。次いで、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、順序付けられたトランザクションのセット154からトランザクション152の新しい有効なブロック151を組み立てようと競合する。通常、これは、ノンスが保留中のトランザクション154の順序付きプールの表現と連結されハッシュされたときに、ハッシュの出力があらかじめ定められた条件を満たすような「ノンス」値を検索することを備える。たとえば、あらかじめ定められた条件は、ハッシュの出力があらかじめ定義された数の先行ゼロを有することであってもよい。これは、プルーフオブワークパズルの特定のタイプの1つにすぎず、他のタイプが除外されるわけではない点に留意されたい。ハッシュ関数の特性は、その入力に対して予測不可能な出力を有することである。したがって、この検索は総当りしか実施することができず、したがって、パズルを解こうとしている各ブロックチェーンノード104においてかなりの量の処理リソースを消費する。

【0047】

最初にパズルを解いたブロックチェーンノード104は、これをネットワーク106に公表し、その解を、ネットワーク内の他のブロックチェーンノード104によって容易にチェックできるプルーフとして提供する。(ハッシュに対する解が与えられると、それによってハッシュの出力が条件を満たすかどうかをチェックするのは簡単である)。第1のブロックチェーンノード104は、ブロックを受け入れてプロトコルルールを強制する他のノードのしきい値コンセンサスまでブロックを伝搬する。次いで、トランザクションの順序付きセット154は、ブロックチェーンノード104の各々によって、ブロックチェーン150内に新しいブロック151として記録されるようになる。ブロックポインタ155も、チェーン内で以前に作成されたブロック151n-1を指す新しいブロック151nに割り当てられる。プルーフオブワーク解を作成するために必要な、たとえばハッシュの形態のかなりの量の労力は、ブロックチェーンプロトコルの規則に従うという第1のノード104の意図を信号で伝える。そのようなルールは、以前に検証されたトランザクションと同じ出力が割り当てられている場合、トランザクションを有効なものとして受け入れないことを含み、これは二重支出とも呼ばれる。ブロック151は、一度作成されると、ブロックチェーンネットワーク106内のブロックチェーンノード104の各々において認識され維持されるため、修正することができない。また、ブロックポインタ155は、ブロック151に連続的な順序を課す。トランザクション152は、ネットワーク106内の各ブロックチェーンノード104の順序付けされたブロックに記録されるため、これは、トランザクションの不変の公開台帳を提供する。

【0048】

パズルを解決するために常に競合している異なるブロックチェーンノード104は、それらがいつ解の検索を開始したか、またはトランザクションが受信された順序に応じて、常に未公開トランザクションのプール154の異なるスナップショットに基づいて実施している可能性がある点に留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション152が次の新しいブロック151nにどのような順序で含まれるかを最初に定義し、未公開トランザクションの現在のプール154が更新される。次いで、ブロックチェーンノード104は、新たに定義された未公開トランザクション154の順序付きプールからブロックを作成するために競合を続け、以下同様である。発生する可能性のある任意の「フォーク(fork)」を解決するためのプロトコルも存在し、フォークとは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解決し、ブロックチェーンの矛盾するビューがノード104間で伝搬されるようにするものである。つまり、最も長く成長するフォークの分岐が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるため、これはネットワークのユーザまたはエージェントに影響を与えないはずである点に留意されたい。

【0049】

ビットコインブロックチェーン(および、他のほとんどのブロックチェーン)によると、(あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を転送するエージェント間またはユーザ間のトランザクションとは対照的に)新しいブロック104の構築に成功したノードには、追加の規定額のデジタル資産を分散する新しい特別な種類のトランザクションにおいて、追加の受入れ額のデジタル資産を新たに割り当てる能力が与えられる。この特別なタイプのトランザクションは通常「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」と呼ばれることもある。これは通常、新しいブロック151nの第1のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードがプロトコルルールに従う意図を通知し、この特別なトランザクションを後で償還できるようにする。ブロックチェーンプロトコルのルールは、この特別なトランザクションが償還され得る前に、たとえば100ブロックなどの満期期間が必要とする場合がある。多くの場合、通常の(非生成)トランザクション152は、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクション手数料も指定する。この手数料は通常「トランザクション手数料(transaction fee)」と呼ばれ、後で説明する。

【0050】

トランザクションの検証および公開に関係するリソースに起因して、通常、ブロックチェーンノード104の少なくとも各々は、1つまたは複数の物理サーバユニットを備えるサーバの形態をとるか、またはデータセンタ全体の形態をとる。しかしながら、原則として、任意の所与のブロックチェーンノード104は、一緒にネットワーク化されたユーザ端末またはユーザ端末のグループの形態をとることができる。

【0051】

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

【0052】

ネットワーク101には、消費ユーザの役割を担う複数の当事者103の各々のコンピュータ機器102も接続されている。これらのユーザは、ブロックチェーンネットワーク106と対話し得るが、トランザクションの検証またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として機能する場合がある。他のユーザは、必ずしも送信者または受信者として行動することなく、ブロックチェーン150と対話し得る。たとえば、一部の当事者は、ブロックチェーン150のコピーを記憶するストレージエンティティとして機能してもよい(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)。

【0053】

当事者103の一部またはすべては、異なるネットワーク、たとえばブロックチェーンネットワーク106の上にオーバーレイされるネットワークの一部として接続されてもよい。ブロックチェーンネットワークのユーザ(しばしば「クライアント(clients)」と呼ばれる)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われる場合があるが、これらのユーザは、ブロックチェーンノードに必要な役割を実施しないため、ブロックチェーンノード104ではない。代わりに、各当事者103は、ブロックチェーンネットワーク106と対話し、それによって、ブロックチェーンノード106に接続する(すなわち、通信する)ことによってブロックチェーン150を利用し得る。2人の当事者103およびそのそれぞれの機器102、すなわち第1の当事者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の当事者103bおよびそのそれぞれのコンピュータ機器102bが、例示の目的で示されている。はるかに多くのそのような当事者103およびそれぞれのコンピュータ機器102が存在し、システム100に参加し得るが、便宜上、それらは図示されていないことが理解されるであろう。各当事者103は、個人であってもよく、組織であってもよい。純粋に例示として、本明細書では第1の当事者103aをアリスと呼び、第2の当事者103bをボブと呼ぶが、これに限定されるものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第1の当事者(first party)」および「第2の当事者(second party)」と置き換えられ得ることが理解されるであろう。

【0054】

各当事者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえばプロセッサ、たとえば、1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを備えるそれぞれの処理装置を備える。各当事者103のコンピュータ機器102は、メモリ、すなわち非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに備える。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を使用する1つまたは複数のメモリユニットを備え得る。各当事者103のコンピュータ機器102上のメモリは、処理装置上で実行されるように構成された少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを備えるソフトウェアを記憶する。本明細書において所与の当事者103に起因する任意のアクションは、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実施され得ることが理解されるであろう。各当事者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえば、デスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、あるいはスマートウォッチなどのウェアラブルデバイスを備える。所与の当事者103のコンピュータ機器102はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク化されたリソースを備え得る。

【0055】

クライアントアプリケーション105は、最初に、適切なコンピュータ可読記憶媒体上で任意の当事者103のコンピュータ機器102に提供されてよく、たとえば、サーバからダウンロードされるか、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスドライブ、磁気フロッピーディスクまたはテープ、CDまたはDVD ROMなどの光ディスク、あるいはリムーバブル光ドライブなどのリムーバブルストレージデバイスにおいて提供される。

【0056】

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

【0057】

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

【0058】

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これにより、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信できるようになる。クライアント105はまた、それぞれの当事者103が受信者であるトランザクションについてブロックチェーン150にクエリを行うために、ブロックチェーンノード104に連絡することができる(または、実施形態では、ブロックチェーン150は、部分的にその公開可視性を通じてトランザクションにおける信頼性を提供する公共施設であるため、実際にブロックチェーン150内の他の当事者のトランザクションを検査する)。各コンピュータ機器102上のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を定式化し、送信するように構成されている。上で述べたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を検証するように構成されたソフトウェアを実行し、トランザクション152をブロックチェーンネットワーク106全体に伝搬させるためにそれを転送するように構成される。トランザクションプロトコルとノードプロトコルは互いに対応しており、所与のトランザクションプロトコルは所与のノードプロトコルとともに進行し、一緒に所与のトランザクションモデルを実装する。ブロックチェーン150内のすべてのトランザクション152に対して同じトランザクションプロトコルが使用される。同じノードプロトコルが、ネットワーク106内のすべてのノード104によって使用される。

【0059】

所与の当事者103、たとえばアリスが、ブロックチェーン150に含まれるべき新しいトランザクション152jを送信したい場合、アリスは、関連するトランザクションプロトコルに従って(アリスのクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション105から、アリスが接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これは、アリスのコンピュータ102に最良に接続されているブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信すると、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってそれを処理する。これは、新しく受信されたトランザクション152jが「有効(valid)」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例についてはすぐに詳しく説明する。一部のトランザクションプロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによって、トランザクションごとに設定可能であり得る。あるいは、条件は単にノードプロトコルの組込み機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。

【0060】

新たに受信されたトランザクション152jが有効であるとみなされるためのテストに合格することを条件として(すなわち、「検証される(validated)」ことを条件として)、トランザクション152jを受信する任意のブロックチェーンノード104は、そのブロックチェーンノード104において維持されるトランザクション154の順序付けられたセットに新しい検証されたトランザクション152を追加する。さらに、トランザクション152jを受信する任意のブロックチェーンノード104は、検証されたトランザクション152をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に伝搬する。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがすぐにネットワーク106全体に伝搬されることを意味する。

【0061】

所与のブロックチェーンノード104において維持される保留中のトランザクション154の順序付きプールへの参加が認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新バージョンにおいてプルーフオブワークパズルを解こうと競合し始める。(他のブロックチェーンノード104は、異なるトランザクションプール154に基づいてパズルを解こうとしている可能性があるが、誰が最初に到達しても、最新のブロック151に含まれるトランザクションのセットを定義することになる可能性があることを思い出されたい。最終的には、ブロックチェーンノード104が、アリスのトランザクション152jを含む順序付けされたプール154の一部についてパズルを解くことになる)。新しいトランザクション152jを含むプール154に対してプルーフオブワークが行われると、それは不変的にブロックチェーン150内のブロック151の1つの一部となる。各トランザクション152は前のトランザクションへ戻るポインタを備えるため、トランザクションの順序も不変的に記録される。

【0062】

異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスを最初に受信し得、したがって、1つのインスタンスが新しいブロック151において公開される前に、どのインスタンスが「有効」であるかについて矛盾する見解を有し、その時点で、すべてのブロックチェーンノード104は、公開されたインスタンスが唯一の有効なインスタンスであることに同意する。ブロックチェーンノード104が1つのインスタンスを有効なものとして受け入れ、次いで、第2のインスタンスがブロックチェーン150に記録されていることを発見した場合、そのブロックチェーンノード104はこれを受け入れなければならず、最初に受け入れたインスタンス(すなわち、ブロック151において公開されていないもの)を破棄する(すなわち、無効なものとして扱う)ことになる。

【0063】

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

【0064】

UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示している。これは、UTXOベースのプロトコルの一例である。トランザクション152(「Tx」と略記される)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は1つまたは複数のトランザクション152を含む)。以下では、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかしながら、これはすべての可能な実施形態に限定されない。UTXOベースの例示的なプロトコルはビットコインを参照して説明されているが、他の例示的なブロックチェーンネットワークにおいても同様に実装できる点に留意されたい。

【0065】

UTXOベースのモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を備えるデータ構造を備える。各出力203は、未使用のトランザクション出力(UTXO)を備え得、これは、(UTXOがまだ償還されていない場合)別の新しいトランザクションの入力202のソースとして使用され得る。UTXOは、デジタル資産の額を指定する値を含む。これは、分散台帳上のトークンの設定数を表す。UTXOはまた、他の情報の中でも特に、元となるトランザクションのトランザクションIDを含み得る。トランザクションデータ構造は、入力フィールド202および出力フィールド203のサイズを示すインジケータを備え得るヘッダ201も備え得る。ヘッダ201はまた、トランザクションのIDを含み得る。実施形態では、トランザクションIDは、(トランザクションID自体を除く)トランザクションデータのハッシュであり、ノード104に提出される生のトランザクション152のヘッダ201に記憶される。

【0066】

アリス103aが、当該デジタル資産の額をボブ103bに転送するトランザクション152jを作成したいと仮定する。図2では、アリスの新しいトランザクション152jには「Tx₁」とラベル付けされている。これは、シーケンス内の先行するトランザクション152iの出力203においてアリスにロックされたデジタル資産の額を取り、これのうちの少なくとも一部をボブに転送する。先行するトランザクション152iは、図2では「Tx₀」とラベル付けされている。Tx₀とTx₁は単なる任意のラベルである。それらは、Tx₀がブロックチェーン151内の最初のトランザクションであることも、Tx₁がプール154内のすぐ次のトランザクションであることも必ずしも意味するものではない。Tx₁は、アリスにロックされた未使用の出力203を依然として有する先行する(すなわち、先の)トランザクションを指すことができる。

【0067】

先行するトランザクションTx₀は、アリスが新しいトランザクションTx₁を作成した時点では、または少なくともアリスがそれをネットワーク106に送信する時点までには、すでに検証されており、ブロックチェーン150のブロック151に含まれている可能性がある。それは、その時点ですでにブロック151のうちの1つに含まれている可能性もあり、順序付きセット154内でまだ待機している可能性もあり、その場合、すぐに新しいブロック151に含まれることになる。あるいは、Tx₀とTx₁を作成して一緒にネットワーク106に送信することもでき、ノードプロトコルが「オーファン(Tx₀)」トランザクションのバッファリングを許可する場合には、Tx₀をTx₁の後に送信することさえもできる。本明細書でトランザクションのシーケンスの文脈において使用される「先行する(preceding)」および「後続の(subsequent)」という用語は、トランザクション内で指定されているトランザクションポインタ(どのトランザクションが他のどのトランザクションを指すかなど)によって定義されるシーケンス内のトランザクションの順序を指す。これらは、「先行するもの(predecessor)」と「後続するもの(successor)」、または「先の(antecedent)」と「後の(descendant)」、「親(parent)」と「子(child)」などに同等に置き換えることもできる。それは、それらが作成され、ネットワーク106に送信され、または任意の所与のブロックチェーンノード104に到着する順序を必ずしも含意するものではない。それにもかかわらず、先行するトランザクション(先のトランザクションまたは「親」)を指す後続のトランザクション(後のトランザクションまたは「子」)は、親トランザクションが検証されるまで、および検証されない限り検証されない。親よりも先にブロックチェーンノード104に到着する子は、オーファンとみなされる。ノードプロトコルおよび/またはノードの挙動に応じて、親を待つために特定の時間、破棄またはバッファリングされ得る。

【0068】

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、本明細書ではUTXO₀とラベル付けされている特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを備え、ロックスクリプトは、後続のトランザクションが検証され、したがって、UTXOが正常に償還されるために、後続のトランザクションの入力202内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者(それが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を備えるロック解除条件を定義する。

【0069】

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

【0070】

つまり、図示される例では、Tx₀の出力203内のUTXO₀は、UTXO₀が償還されるために(厳密には、UTXO₀を償還しようとする後続のトランザクションが有効となるために)アリスの署名Sig P_Aを必要とするロックスクリプト[Checksig P_A]を備える。[Checksig P_A]は、アリスの公開鍵-秘密鍵ペアからの公開鍵P_Aの表現(すなわち、ハッシュ)を含む。Tx₁の入力202は、(たとえば、実施形態ではトランザクションTx₀全体のハッシュであるそのトランザクションID、TxID₀によって)Tx₁を指し示すポインタを備える。Tx₁の入力202は、Tx₀の任意の他の可能な出力の中から、UTXO₀を識別するために、Tx₀内のUTXO₀を識別するインデックスを備える。Tx₁の入力202は、アリスが鍵ペアからのアリスの秘密鍵をデータのあらかじめ定義された部分(暗号では「メッセージ」と呼ばれることもある)に適用することによって作成された、アリスの暗号署名を備えるロック解除スクリプト<Sig P_A>をさらに備える。有効な署名を提供するためにアリスによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

【0071】

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

【0072】

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

【0073】

Tx₁内のロック解除スクリプトが、Tx₀のロックスクリプト内で指定されている1つまたは複数の条件を満たす場合(つまり、図示される例では、アリスの署名がTx₁内で提供され、認証された場合)、ブロックチェーンノード104は、Tx₁が有効であるとみなす。これは、ブロックチェーンノード104が保留中のトランザクション154の順序付きプールにTx₁を追加することを意味する。ブロックチェーンノード104はまた、トランザクションTx₁をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送し、その結果、トランザクションがネットワーク106全体に伝搬されるようにする。Tx₁が検証されてブロックチェーン150に含まれると、これは、Tx₀からのUTXO₀を使用済みと定義する。Tx₁は、未使用のトランザクション出力203を使用する場合にのみ有効であり得る点に留意されたい。別のトランザクション152によってすでに使用された出力を使用しようとする場合、Tx₁は、他のすべての条件が満たされたとしても無効になる。したがって、ブロックチェーンノード104はまた、先行するトランザクションTx₀内の参照されたUTXOがすでに使用済みであるかどうか(すなわち、別の有効なトランザクションへの有効な入力をすでに形成しているかどうか)をチェックする必要がある。これは、ブロックチェーン150がトランザクション152に定義された順序を課すことが重要である1つの理由である。実際には、所与のノード104は、どのトランザクション152内のどのUTXO203が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、UTXOが使用されたかどうかを定義するものは、ブロックチェーン150内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。

【0074】

所与のトランザクション152のすべての出力203において指定された合計金額が、そのすべての入力202によって指定された合計金額より大きい場合、これはほとんどのトランザクションモデルにおける無効のもう1つの根拠になる。したがって、そのようなトランザクションは伝搬されず、ブロック151にも含まれない。

【0075】

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

【0076】

実際には、アリスは通常、自分のトランザクション104をブロック151に含めることに成功したビットコインノード104に対する手数料を含む必要もある。アリスがそのような手数料を含めない場合、Tx₀は、ブロックチェーンノード104によって拒否される可能性があり、したがって、技術的には有効であっても、伝搬されず、ブロックチェーン150に含められない可能性がある(ノードプロトコルは、ブロックチェーンノード104が望まない場合にトランザクション152を受け入れることを強制しない)。いくつかのプロトコルでは、トランザクション手数料は、それ自体の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指定された合計金額と、所与のトランザクション152の出力203において指定された合計金額との差は、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO₀へのポインタがTx₁への唯一の入力であり、Tx₁は唯一の出力UTXO₁を有するとする。UTXO₀において指定されているデジタル資産の額がUTXO₁において指定されている額より大きい場合、その差がUTXO₁を含むブロックを作成するためにプルーフオブワークレースに勝ったノード104によって割り当てられ得る。しかしながら、代替的にまたは追加的に、トランザクション手数料がトランザクション152のUTXO203のうちのそれ自体の1つにおいて明示的に指定され得ることは、必ずしも除外されるものではない。

【0077】

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

【0078】

スクリプトコードは、しばしば、概略的に表される(すなわち、正確な言語を使用していない)点に留意されたい。たとえば、特定の機能を表すためにオペレーションコード(オペコード)を使用し得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。一例として、OP_RETURNは、ロックスクリプトの開始時にOP_FALSEが前に置かれると、トランザクション内にデータを記憶することができ、それによってデータをブロックチェーン150に不変的に記録することができる、トランザクションの出力を作成するスクリプト言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。

【0079】

通常、トランザクションの入力は、公開鍵P_Aに対応するデジタル署名を含む。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータの一部分に署名する。いくつかの実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の一部または全部に署名する。署名された出力の特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる4バイトコードである(したがって、署名時に固定される)。

【0080】

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

【0081】

サイドチャネル
図1に示されるように、アリスおよびボブの各々のコンピュータ機器102a、120b上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、(いずれかの当事者または第三者の指示で)アリス103aがボブ103bとの別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別でのデータの交換を可能にする。そのような通信は、「オフチェーン(off-chain)」通信と呼ばれることがある。たとえば、これは、当事者の一方がトランザクションをネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されたり、チェーン150上に進んだりすることなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。この方法でトランザクションを共有することは、「トランザクションテンプレート」の共有と呼ばれることもある。トランザクションテンプレートには、完全なトランザクションを形成するために必要な1つまたは複数の入力および/または出力が欠けている場合がある。代替的にまたは追加的に、サイドチャネル107は、鍵、交渉された額または条件、データコンテンツなどの任意の他のトランザクション関連データを交換するために使用され得る。

【0082】

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

【0083】

クライアントソフトウェア
図3Aは、現在開示されている方式の実施形態を実装するためのクライアントアプリケーション105の例示的な実装形態を示している。クライアントアプリケーション105は、トランザクションエンジン401とユーザインターフェース(UI)層402を備える。トランザクションエンジン401は、トランザクション152を定式化することと、サイドチャネル301を介してトランザクションおよび/または他のデータを受信および/または送信することと、ならびに/あるいは上記で説明し、すぐにさらに詳細に説明する方式に従って、ブロックチェーンネットワーク106を通じて伝搬されるべき1つまたは複数のノード104にトランザクションを送信することとを行うためなどに、クライアント105の基礎となるトランザクション関連機能を実装するように構成される。本明細書に開示される実施形態によれば、各クライアント105のトランザクションエンジン401は、トークントランザクションを生成するように構成された機能403を備え得る。

【0084】

UI層402は、機器102のユーザ出力手段を介して各ユーザ103に情報を出力することと、機器102のユーザ入力手段を介して各ユーザ103から入力を受信することとを含む、各ユーザのコンピュータ機器102のユーザ入力/出力(I/O)手段を介して、ユーザインターフェースをレンダリングするように構成される。たとえば、ユーザ出力手段は、視覚出力を提供するための1つまたは複数のディスプレイスクリーン(タッチスクリーンまたは非タッチスクリーン)、オーディオ出力を提供するための1つまたは複数のスピーカ、および/または触覚出力を提供するための1つまたは複数の触覚出力デバイスなどを備えることができる。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーン(出力手段のために使用されるものと同じまたは異なるもの)の入力アレイ、マウス、トラックパッド、またはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、スピーチもしくは音声入力を受信するための1つもしくは複数のマイクおよびスピーチもしくは音声認識アルゴリズム、手動もしくは身体的なジェスチャの形式で入力を受信するための1つもしくは複数のジェスチャベースの入力デバイス、あるいは1つもしくは複数の機械的なボタン、スイッチ、またはジョイスティックなどを備えることができる。

【0085】

注:本明細書における様々な機能は、同じクライアントアプリケーション105に統合されるものとして説明される場合があるが、これは必ずしも限定されるものではなく、代わりに、それらは、2つ以上の別個のアプリケーションのスイートにおいて実装することができ、たとえば、1つはもう1つのプラグインであるか、API(アプリケーションプログラミングインターフェース)を介して接続されている。たとえば、トランザクションエンジン401の機能は、UI層402とは別個のアプリケーションで実装されてもよく、トランザクションエンジン401などの所与のモジュールの機能は、複数のアプリケーションに分割されてもよい。また、説明された機能の一部またはすべてが、たとえばオペレーティングシステム層において実装される可能性も排除されない。本明細書のどこかで単一のまたは所与のアプリケーション105などについて言及する場合、これは単なる例であり、より一般的には、説明される機能は任意の形式のソフトウェアで実装することができることが理解されるであろう。

【0086】

図3Bは、アリスの機器102a上のクライアントアプリケーション105aのUI層402によってレンダリングされ得るユーザインターフェース(UI)500の一例のモックアップを示している。同様のUIが、ボブの機器102b上のクライアント105b、または他の当事者の機器によってレンダリングされ得ることが理解されるであろう。

【0087】

例として、図3Bは、アリスの視点からのUI500を示している。UI500は、ユーザ出力手段を介して別個のUI要素としてレンダリングされる1つまたは複数のUI要素501、502、503を備え得る。

【0088】

たとえば、UI要素は、異なるスクリーン上のボタン、またはメニュー内の異なるオプションなどであり得る、1つまたは複数のユーザ選択可能な要素501を備え得る。ユーザ入力手段は、ユーザ103(この場合、アリス103a)が、スクリーン上のUI要素をクリックまたはタッチすること、または所望のオプションの名前を話すことなどによって、オプションのうちの1つを選択または動作できるように構成される(注意:本明細書で使用する「手動(manual)」という用語は、自動との対比のみを意味しており、必ずしも片手または両手の使用に限定するものではない)。

【0089】

代替的にまたは追加的に、UI要素は、1つまたは複数のデータ入力フィールド502を備え得る。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえばスクリーン上でレンダリングされ、データは、ユーザ入力手段、たとえばキーボードまたはタッチスクリーンを通じてフィールドに入力することができる。あるいは、データは、たとえばスピーチ認識に基づいて口頭で受信することもできる。

【0090】

代替的にまたは追加的に、UI要素は、ユーザに情報を出力するために出力される1つまたは複数の情報要素503を備え得る。たとえば、これ/これらはスクリーン上に、または可聴式にレンダリングすることができる。

【0091】

様々なUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能についてはすぐに詳しく説明する。また、図3に示されるUI500は、模式化されたモックアップにすぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を備え得ることも理解されよう。

【0092】

有向非巡回グラフとしてのブロックチェーン
ビットコイン台帳は、データ構造がブロックのチェーンとして考えられるブロックチェーンとして広く参照されている。しかしながら、トランザクションを(ブロックではなく)基本要素として考えると、ビットコイン台帳を有向非巡回グラフとみなすことができることがわかる。このセクションでは、ビットコイン有向非巡回グラフ(BDAG)の正式な定義と、BDAGの特殊なタイプのサブグラフについて説明する。

【0093】

定義-ビットコイン有向非巡回グラフ
ビットコイン有向非巡回グラフ(BDAG)はDAGであり、
1.ノードはビットコイントランザクションであり、
2.少なくとも1つの出力が第1のノードから第2のノードに割り当てられる(使用される)場合、あるノードから別のノードへの有向エッジが確立される。

【0094】

トランザクションの有向サイクルはそれらの入力内のトランザクションIDの巡回参照を意味するため、グラフは非巡回になるが、これは不可能である点に留意されたい。
定義に基づいて、いくつかの特性を強調表示することができる。
1.各ノードは最大でn個の外向きエッジを有することができ、nは、このノードによって表されるトランザクション内の使用可能な出力の数である。
2.コインベースノードには内向きのエッジがない、および
3.任意のノードから開始し、エッジの反対方向にたどるパスは、1つまたは複数のコインベースノードにおいて終了する必要がある。

【0095】

BDAGの例が図4Aに示されている。図4Bは、ブロックチェーン構造がBDAGにスタンプされたときのBDAGを示している。

【0096】

定義-トランザクションパス
BDAG内のノードAからノードBへのトランザクションパスは、ノードN₀、N₁、…、N_tのセットであり、
1.N₀はノードAであり、N_tはノードBであり、
2.すべてのi=0,1,…,t-1に対して、N_iからN_i+1への有向エッジが存在し、
3.tはパスの長さとして定義される。

【0097】

定義-トランザクションチェーン
トランザクションチェーンは、接続されているBDAGのサブグラフである。すなわち、サブグラフ内のどのノードのペアにも、エッジの方向を無視した2つのノード間にパスが存在する。BDAG内のすべてのトランザクションチェーンがBDAGのパーティションを形成する点に留意されたい。

【0098】

図4Aのように、2つのトランザクションチェーンがある。第1のトランザクションチェーンは2つのコインベーストランザクションから始まり、2つのトランザクションチェーンのマージと考えることができ、一方、第2のトランザクションチェーンは1つのコインベーストランザクションから始まり、より単純な構造を有している。

【0099】

上記の例はビットコイン台帳(すなわち、ビットコインブロックチェーン)を参照しているが、同じ定義が他のUTXOスタイルのブロックチェーンに適用される点に留意されたい。

【0100】

トークンの検証/認証
本発明の実施形態は、トークントランザクションの検証に関する。図7は、本開示のいくつかの実施形態が使用され得る例示的なシステム700を示している。しかしながら、本発明は、この例示的なシステムのみでの使用に限定されず、ブロックチェーントークンの認定のためのより一般化された解を提供し、本発明は、トークンを生成および/または処理するために使用されるトークン化方法またはプロトコルの種類に関して限定されない。

【0101】

図7に示されるように、例示的なトークン化システム700は、検証エンティティ701、トークン発行者702、1人または複数のトークンユーザ703a、703b、およびブロックチェーンネットワーク106を備える。図7には2人のトークンユーザ703a、703bだけが示されているが、一般に、システム700は任意の数のトークンユーザ703を備え得る点に留意されたい。トークン発行者702および1人または複数のトークンユーザ703の各々は、図1から図3を参照して説明したように、アリス103aまたはボブ103bの形態をとり得る。すなわち、トークン発行者702およびトークンユーザ703の各々は、アリス103aおよび/またはボブ103bによって実行される動作の一部またはすべてを実行するように構成され得る。

【0102】

検証エンティティ701は、いくつかの形式のうちの1つをとり得、その詳細については以下で説明する。しかしながら、一般に、検証エンティティ701は、1つまたは複数のプロセッサ、たとえば、1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを備える処理装置を備えるコンピュータ機器を動作し得る。コンピュータ機器は、メモリ、すなわち非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに備える。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を使用する1つまたは複数のメモリユニットを備え得る。コンピュータ機器上のメモリは、処理装置上で実行されるように構成された少なくとも1つのクライアントアプリケーションのそれぞれのインスタンスを備え得るソフトウェアを記憶する。本明細書において検証エンティティ701に起因する任意のアクションは、コンピュータ機器の処理装置上で実行されるソフトウェアを使用して実施され得ることが理解されるであろう。検証エンティティ701のコンピュータ機器は、少なくとも1つのユーザ端末、たとえば、デスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、あるいはスマートウォッチなどのウェアラブルデバイスを備え得る。検証エンティティ701のコンピュータ機器はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク化されたリソースを備え得る。クライアントアプリケーションは、最初に、適切なコンピュータ可読記憶媒体上で検証エンティティ701のコンピュータ機器に提供されてよく、たとえば、サーバからダウンロードされるか、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスドライブ、磁気フロッピーディスクまたはテープ、CDまたはDVD ROMなどの光ディスク、あるいはリムーバブル光ドライブなどのリムーバブルストレージデバイスにおいて提供される。

【0103】

検証エンティティ701は、トークントランザクションを検証するように構成されている。検証エンティティ701は、鋳造トランザクションにアクセスすることができる。鋳造トランザクションは、一定量のトークンを鋳造、すなわち発行する。鋳造トランザクションは、トークン発行者702によって署名されてもよく(すなわち、鋳造トランザクションは、トークン発行者702によって所有される発行公開鍵にリンクされた署名を備える入力を含み得る)、トークンの初期量をロックする出力を備える。他の例では、鋳造トランザクションには、異なる形式の暗号データ、たとえば、鋳造用の公開鍵、トークン発行者によって署名されたメッセージ、トークン発行者によって暗号化されたメッセージなどを含み得る。一般に、鋳造トランザクションは暗号化「鋳造」データを含む。暗号データは、暗号スキームの一部として使用されるデータである。鋳造データは、トークンの鋳造に関連付けられることが知られている公開情報である。鋳造トランザクションは、それぞれのトークンの初期量をロックする複数の出力を含み得る。鋳造トランザクションはブロックチェーン150に記録される。検証エンティティ701はブロックチェーン150から鋳造トランザクションにアクセスしてもよく、検証エンティティ701は鋳造トランザクションをローカルに記憶してもよい。いくつかの例では、鋳造データは知識プルーフ、たとえばハッシュパズルまたはr-パズルであり得る。知識プルーフを解決する、すなわちロックを解除するためには、データの知識が必要である。

【0104】

検証エンティティ701は、「ターゲットトークントランザクション」、すなわち、検証エンティティ701によって検証されるトークントランザクションを取得する。ターゲットトークントランザクションは、トークンユーザ703によって検証エンティティ701に提出され得る。または、ターゲットトークントランザクションは、異なる検証エンティティ701によって検証エンティティに提出されてもよい。すなわち、システム700は、複数の検証エンティティ、たとえば図6のトークンサーバ601とトークンクライアントを備え得る。ターゲットトランザクションは、他の方法で取得されてもよい。

【0105】

ターゲットトークントランザクションが有効なトークントランザクションであるためには、それが鋳造トランザクションに戻るトランザクションチェーンの一部である必要がある。すなわち、ターゲットトランザクションは、鋳造トランザクションの出力を参照する(すなわち、使用する)か、鋳造トランザクションに戻るトランザクションチェーンの一部である前のトークントランザクションを参照する入力を含む必要がある。後者の場合、前のトランザクションは、鋳造トランザクションの出力を参照する入力、または鋳造トランザクションに戻るトランザクションチェーンの一部である前のトークントランザクションを参照する入力を含んでいる必要がある。言い換えれば、前のトークントランザクションの参照出力を追跡すると、最終的にはトークントランザクションにつながる必要がある。

【0106】

検証エンティティ701は、参照された出力の前記追跡を実行することによってターゲットトランザクションのトークンを検証するように構成され得る。あるいは、検証エンティティ701は、以下で説明するように、第1の条件を検証するためのより効率的なプロセスを実行し得る。

【0107】

一旦検証されると、すなわち、ターゲットトークントランザクションにおけるトークンの信頼性が確立されると、検証エンティティ701は、ターゲットトークントランザクションをブロックチェーンネットワーク106に提出し得る。すなわち、トークンユーザ703aは、ブロックチェーンプロトコルに従ってネットワーク検証のためにターゲットトークントランザクションを検証エンティティに提出し得、ターゲットトークントランザクションが有効に形成されるという条件で、検証エンティティ701は、台帳に含めるためにターゲットトークントランザクションをブロックチェーンネットワーク106に転送する。

【0108】

検証エンティティ701は、ターゲットトークントランザクションが有効なブロックチェーントランザクションであるという確認を取得し得る。たとえば、検証エンティティ701は、ターゲットトークントランザクションがブロックチェーン150上のブロック151において公開されたという確認を取得し得る。検証エンティティ701は、ターゲットトークントランザクションがブロック151において公開されたことを検証するために、ブロックチェーンノード104からマークルプルーフを取得し得る。ターゲットトークントランザクションが有効なブロックチェーントランザクションであることが確認されると、検証エンティティ701は、ターゲットトークントランザクションを有効なトークントランザクションのリストに記録し得る。検証エンティティ701は、ターゲットトークントランザクションが有効なブロックチェーントランザクションであるという確認を取得する前に、ターゲットトークントランザクションを有効なトークントランザクションのリストに記録し得る点に留意されたい。検証エンティティ701は、ターゲットトークントランザクションが有効なブロックチェーントランザクションではない場合、リストからターゲットトークントランザクションを削除することを選択し得る。

【0109】

いくつかの例では、ターゲットトークントランザクションを検証した後、検証エンティティ701は、ターゲットトークントランザクションをブロックチェーンネットワーク106に提出する前に、ターゲットトークントランザクションに署名し得る。たとえば、ターゲットトークントランザクションは不完全である可能性があり、検証エンティティ701は、検証エンティティの署名、すなわち、検証エンティティ701によって所有される公開鍵にリンクされた署名を備える入力を含めることによって、ターゲットトークントランザクションを完了し得る。この署名は、ターゲットトークントランザクションが検証されたことを示す。いくつかの例では、入力は、手数料支払い入力、すなわち、ブロック151においてトランザクションを公開するブロックチェーンノード104によって収集されたトランザクション手数料を支払う入力であってもよい。そのような入力は、「非トークン入力」の一例である。

【0110】

ターゲットトークントランザクションには、1つまたは複数の非トークン出力を備え得る。たとえば、非トークン出力は、手数料支払い入力とトランザクション手数料との間の差額を、トランザクション手数料を支払うエンティティに返すために使用され得る。非トークン出力は他の目的に使用される場合がある。ターゲットトークントランザクションが1つまたは複数の非トークン出力を備える場合、ターゲットトークントランザクションは、有効なトークントランザクションとみなされるために第3の条件を満たす必要がある。検証エンティティ701は、ターゲットトークントランザクションのトークン出力によってロックされているトークンの合計量が、ターゲットトークントランザクションのトークン入力によって参照される出力によってロックされているトークンの合計量より大きくないことを検証するように構成されている。

【0111】

いくつかの例では、検証エンティティ701はまた、鋳造トランザクションを検証し得る。たとえば、検証エンティティ701は、鋳造トランザクションが、トークン発行者702に関連付けられる鋳造用の公開鍵にリンクされた署名を備えることを検証し得る。

【0112】

検証エンティティ701は、トークントランザクション(たとえば、ターゲットトークントランザクション)が有効なトークントランザクションであるかどうかを確認するために、要求エンティティ(たとえば、トークンユーザ703b)から要求を受信し得る。検証エンティティ701は、トークントランザクションが有効なトークントランザクションであることを検証し、トークントランザクションが有効である場合、要求エンティティに有効なトークントランザクションであることを通知する応答を要求エンティティに提出し得る。この要求と応答プロセスについては、以下で詳しく説明する。

【0113】

トークンサーバ
いくつかの実施形態では、検証エンティティ701は、「トークンサーバ」601を備え得る。すなわち、検証エンティティ701は、検証エンティティ701のアクションを実行するように構成されたサーバの形態をとる(または、含む)ことができる。トークンサーバ601は、有効なトークントランザクション、すなわち、前に検証されたトークントランザクションの記録(たとえば、データベース)を記憶し得る。これらのトークントランザクションは、トークンサーバ601によって、または異なるエンティティによって検証されている可能性がある。いくつかの例では、トークンサーバ601は、すべての有効なトランザクションの記録を記憶し得る。

【0114】

これらの実施形態では、トークンサーバ601は、参照されたトランザクションが有効なトークントランザクションの記録に存在するかどうかを決定することによって、たとえば、参照されたトランザクションのトランザクションIDの検索を実行することによって、ターゲットトークントランザクションのトークン入力が、前に検証されたトークントランザクションの出力を参照していることを検証し得る。

【0115】

いくつかの例では、トークンサーバ601は「トークンブロック」を構築し得る。トークンブロックは、ブロックチェーンブロック151といくつかの類似点を共有する。トークンブロックは、トークンブロックヘッダと有効なトークントランザクションのリスト(または、少なくとも有効なトークントランザクションのそれぞれの識別子)を備える。ターゲットトークントランザクションは、検証されると、現在の(すなわち、最新の)トークンブロックに含まれ得る。所与のトークンブロックのトークンブロックヘッダは、そのトークンブロック内のトークントランザクションのセットに基づいて計算されたマークルルートを備える。以下で説明するように、ブロックヘッダは追加のフィールドを備え得る。

【0116】

ブロックチェーンブロック151と同様に、トークンブロックのブロックヘッダは、トークンブロックのシーケンス(すなわち、チェーン)における前のトークンブロックへのポインタを備え得る。ポインタは、前のトークンブロックのブロックヘッダのハッシュ(たとえば、ダブルハッシュ)の形式をとり得る。ポインタは、第1の(すなわち、第1に作成される)トークンブロックまで遡って追跡する。

【0117】

トークンサーバ601は、ブロックチェーンブロック151ごとに1つのトークンブロックを構築し得る。すなわち、トークンブロックは、所与のトークンブロック内のトランザクション(具体的には、トークントランザクション)に基づいて構築され得る。トークンブロックは、対応するブロックチェーンブロック151が公開される前に構築されてもよく(たとえば、ブロックチェーンブロック151に含まれるトークントランザクションがトークンサーバ601によってネットワーク106に送信された場合)、ブロックチェーンブロック151が公開された後に構築されてもよい(たとえば、トークンサーバ601は、トークントランザクションについてブロックチェーンブロック151をスキャンし得る)。

【0118】

任意で、トークンブロックの一部またはすべてが1つまたは複数の署名を備える場合がある。署名は、トークンブロックのそれぞれのブロックヘッダに含まれ得る。たとえば、トークンサーバ601は、トークンブロックが実際にトークンサーバ601によって構築されたことを確認するための署名を含み得る。署名されたメッセージは、トークンブロックの一部またはすべてを備え得る。いくつかの例では、トークン発行者702および/あるいは1つまたは複数の追加のエンティティ(たとえば、監査人、政府機関、または他の公的エンティティ)は、それぞれの署名を含み得る。

【0119】

トークンブロックの記録を保持するだけでなく、トークンサーバ601は、1つまたは複数のトークンブロックを(たとえば、定期的にまたは要求に応じて)要求エンティティ、たとえばトークンユーザ703bまたはトークン発行者702に送信し得る。要求エンティティは、トークン発行者702、トークンユーザ703、または異なる検証エンティティ(たとえば、以下で説明するトークンライトクライアント)であり得る。トークンサーバ601は、完全なトークンブロックを送信してもよく、トークンブロックヘッダのみを送信してもよい。

【0120】

場合によっては、トークンサーバ601は、有効なトークントランザクションの存在および完全性を検証するために、簡略化されたトークン検証方法の一部としてトークンブロックヘッダ(および、任意で完全なトークンブロック)を送信し得る。トランザクションの完全性を検証すると、トランザクション内のデータが改ざんされていないことが保証される。たとえば、要求エンティティ(たとえば、トークンユーザ703b)は、トークントランザクションが有効であることを検証したい場合がある。問題のトークントランザクションは、現在のトークントランザクション、たとえば、ターゲットトークントランザクションの入力によって参照されるトークントランザクションである可能性がある。参照されたトークントランザクションが有効であることを確認するために、トークンサーバ601は、トークンブロック内の参照されたトークントランザクションの存在を検証するためのマークルプルーフを要求エンティティに提供し得る。マークルプルーフは当業者には知られている。要求エンティティに送信されるマークルプルーフは、ハッシュのシーケンスを含む。参照されたトークントランザクションはハッシュ化され、次いでシーケンス内の第1のハッシュと連結され、次いでその結果がハッシュ化される。次いで、次の結果がシーケンス内の次のハッシュ(存在する場合)と連結され、次いでその結果がハッシュ化される。シーケンス内の各ハッシュは、左または右のインジケータを有する。左か右かは、マークルプルーフの第1の数値として提供できる単一のインデックスによって決定することができる。このプロセスは、シーケンス内の各ハッシュが使用されるまで繰り返される。最終ハッシュがトークンブロックのトークンブロックヘッダに含まれるマークルルートと等しい場合、参照されたトークントランザクションはトークンブロックに含まれる。トークンブロックには有効なトークントランザクションのみが含まれるため、参照されるトークントランザクションは有効である必要があり、参照されるトランザクション内のデータは修正されていない必要がある。

【0121】

トークンライトクライアント
いくつかの実施形態では、検証エンティティ701は、「トークンライトクライアント」602aを備え得る。すなわち、検証エンティティ701は、検証エンティティ701のアクションを実行するように構成されたクライアントアプリケーションの形式をとり(または含み)得る。トークンサーバ601は、有効なトークントランザクション、すなわち、以前に検証されたトークントランザクションの記録(たとえば、データベース)を記憶し得る。これらのトークントランザクションは、トークンライトクライアント602aまたは異なるエンティティによって検証されている可能性がある。

【0122】

トークンライトクライアント602aは、有効なトークントランザクションのトランザクション識別子の記録とともに、トークンブロックヘッダの記録を維持する。トークンライトクライアント602aはまた、有効なトークントランザクションの各トークン出力のトークン値およびインデックスの記録を記憶する。たとえば、記録は、TxID||index||valueの形式の複数のデータ項目を備え得る。トークンブロックヘッダは、要求時および/または各トークンブロックがトークンサーバ601によって構築されるときに、トークンサーバ601から取得され得る。いくつかの例では、トークンブロックヘッダは、トークンライトクライアント602aによって構築されたトークンブロックであってもよい。

【0123】

トークンライトクライアント602aは、記録を使用して受信したトークントランザクションを検証し得る。たとえば、トークンライトクライアント602aは、ターゲットトランザクションのトークン入力によって参照されるトークン出力が記録に記憶されていることを検証し得る。たとえば、トークンライトクライアント602aは、レコード内の参照されたTxID||index||valueの検索を実行する。ターゲットトークントランザクションが有効である(すなわち、有効性に関する1つまたは複数の条件を満たす)場合、トークンライトクライアント602aは、ターゲットトランザクションのトークン出力を記録に追加し得る。いくつかの例では、トークンライトクライアント602aは、参照されたトークン出力を記録から削除し得る。

【0124】

トークンライトクライアント602aは、トークンユーザ703からトークントランザクションを受信し、そのトークントランザクションを検証し、次いでそれらをブロックチェーンネットワーク106および/またはトークンサーバ601に提出し得る。

【0125】

トークンサーバ601と同様に、トークンライトクライアント602aもトークンブロックを構築し得る。これらのトークンブロックは、トークンサーバ601によって構築されたものと同じ形式をとり得る。たとえば、トークンライトクライアント602aは、トークンユーザ703からトークントランザクションを受信し、それらのトークントランザクションに基づいてトークンブロックを構築し得る。トークンライトクライアント602aはまた、トークンライトクライアント602aの異なるインスタンスに送信され、次いで、トークンライトクライアント602aに転送されるか、ブロックチェーン150から取得される(他のトークンライトクライアントによってブロックチェーンネットワーク106に提出された後)トークントランザクションをトークンブロックに含み得る。トークンサーバ601と同様に、トークンライトクライアント602aは、ブロックチェーン150の新たに公開されたブロックごとにトークンブロックを構築し得る。

【0126】

いくつかの例では、トークンライトクライアント602aは、たとえば、トークンサーバ601によって検証するために、構築したトークンブロックをトークンサーバ601に送信し得る。トークンサーバ601は、そのようなトークンブロックのトークンブロックヘッダにその署名を追加し、それらをトークンライトクライアント602aに返すことができる。いくつかの例では、トークンライトクライアント602aは、トークンサーバ601からトークンブロックを受信し得る。たとえば、トークンライトクライアント602aは、ブロックチェーンネットワーク106への接続を一時的に失い、したがってその間トークンブロックを構築できない場合がある。

【0127】

トークンサーバ601と同様に、場合によっては、トークンライトクライアント602aは、有効なトークントランザクションの存在を検証するために、簡略化されたトークン検証方法の一部としてトークンブロックヘッダ(および、任意で完全なトークンブロック)を送信し得る。同様のシナリオが適用され、トークンライトクライアント602aは、ブロックヘッダと、対応するトークンブロックに含まれる有効なトークントランザクションのマークルプルーフを要求エンティティ(たとえば、トークンユーザ703)に送信する。マークルプルーフがブロックヘッダに含まれるマークルルートに到達した場合、そのトークントランザクションはトークンブロックに含まれることが確認でき、したがって有効なトークントランザクションであることが確認できる。

【0128】

トークンUTXOクライアント
図6に示されるように、システムは、1つまたは複数のトークンUTXOクライアント602bを備え得る。これらのクライアントアプリケーションはまた、トークントランザクションを検証するように構成されている。すなわち、検証エンティティ701は、トークンUTXOクライアントアプリケーション602bの形態をとり得る。トークンUTXOクライアントは、1つのトークンスナップショットの記録を保持する。トークンスナップショットは、トークンUTXOのセットを備える。各トークンUTXOは、トークントランザクションの未使用のトークン出力である。各トークンスナップショットは、異なる時点においてトークンUTXOのセットをキャプチャする。

【0129】

トークンスナップショットの一部またはすべては、トークンUTXOクライアント602bによって構築される。一部は、トークンUTXOクライアント602bの異なるインスタンスから受信されてもよく、トークンサーバ601から受信されてもよい。場合によっては、トークンサーバ601は、トークンスナップショットを構築し、たとえば、トークンUTXOクライアント602bがブロックチェーンネットワーク106への接続を失ったことに応答して、それをトークンUTXOクライアント602bに送信し得る。トークンスナップショットは、ブロックチェーン上のトークンUTXOを追跡すること、すなわち、どのトークン出力が後のブロックチェーントランザクション(トークンまたは非トークン)によってまだ有効に使用されていないかを追跡することによって構築され得る。

【0130】

トークンUTXOクライアント602bは、ターゲットトークントランザクションの各トークン入力が、前のトークントランザクション(鋳造トランザクションであり得る)のそれぞれの未使用のトークン出力を参照していることを検証することによって、トークントランザクション、たとえばターゲットトークントランザクションを検証するように構成されている。トークンUTXOクライアント602bは、参照されたトークン出力が最新のトークンスナップショットに存在することを検証することによってこれを行う。

【0131】

トークントランザクションを検証すると、トークンUTXOクライアント602bは、トークントランザクションをブロックチェーンネットワーク106および/またはトークンサーバ601に送信し得る。トークンUTXOクライアント602bは、ターゲットトランザクションのトークン出力を含むが、参照されたトークン出力を含まない新しいトークンスナップショットを構築し得る。

【0132】

トークンUTXOクライアント602bはまた、有効なトークン出力の存在を検証するために、簡略化されたトークン検証方法を実行し得る。各トークンUTXOスナップショットは、スナップショットに記憶されたトークンUTXOに基づいて計算されたマークルルートを備え得る。トークン出力の存在を検証するために、トークンUTXOクライアント602bは、所与のトークンUTXOを現在のトークンスナップショットのマークルルートにリンクするマークルパスを要求エンティティ(たとえば、トークンユーザ703)に送信し得る。マークルルートは、葉が次のいずれかの形式をとるマークルツリーに対して構築され得る点に留意されたい。
1.TxID||index
2.TxID||index||value
3.TxID||index||locking script||value

【0133】

例示的なトークンシステム
次に、例示的なトークンシステムについて説明する。トークンフレームワークの一部の機能はオプションであり、本発明の実施形態の特定の実装形態に基づいて他の変形が選択され得ることが理解されるであろう。例示的なフレームワークによれば、ブロックチェーントランザクションにはダスト制限が課され、トークンの値はネイティブブロックチェーントークンにペグされ、トークン固有のデータがロックスクリプトにプッシュされることはない。

【0134】

セットアップトランザクション
トークン発行者702は、セットアップトランザクションを発行し得る。トークン発行者702が国の通貨を表すトークンを発行したいと仮定する。これは、トークンシステムの多くの考えられる使用事例のうちの1つにすぎない点に留意されたい。トークン発行者702は、セットアップトランザクション内の使用不可能(たとえば、OP_FALSE OP_RETURN)ペイロードにおいてオンチェーンのトークンの仕様を公開することを選択することができる。あるいは、その記録がユーザおよび一般大衆によって信頼されている限り、仕様はウェブサイトまたは任意の他の適切な公的記録において公開され得る。これにより、トークン発行者702はトークンチェーンを一般に公開し、トークンのルールを証明できるようになる。論争が生じた場合には、トークン発行者702を含むトークンユーザ703は、論争を解決するために仕様を参照することができる。仕様は公開会社の記事またはトークンシステムの契約条件と考えることができる。この仕様は、ERC-20標準、トークン化された標準、またはトークン発行者が適切と考える任意のカスタマイズされた標準を参照することができる。トークンチェーンがプライベートである場合、完全性を確認するために、仕様をハッシュ値で公開することができる。

【0135】

セットアップトランザクションの例を以下に示す。

【表1】

上記で、<Specification>は以下であり得る。

【表2】

【0136】

トークン発行者702は、セットアップトランザクションに署名し、発行公開鍵を含む。セットアップトランザクションは、トークン発行者702によって所有される未使用トランザクション出力(UTXO)を参照し得る。同様に、セットアップトランザクションの出力は、任意の公開鍵、たとえば、トークン発行者702によって所有される異なる公開鍵にロックされ得る。

【0137】

上記の仕様は説明のみを目的としている点に留意されたい。トークン発行者702は、このセットアップトランザクションにトークンシステムに関するすべての詳細を含めることができる。一般に、仕様は、トークンシステムが技術的に堅牢であり、法的に準拠していることを実証することを目的としている。

【0138】

例示的な仕様では、3つの公開鍵が明示的に示されている。PK_mintはトークンを鋳造するために使用され、PK_meltはコインを溶解するために使用され、PK_Auditはトークンシステムのコンプライアンスを証明するために使用される。3つの公開鍵はすべて、セットアップトランザクションの入力におけるトークン発行者702からの署名によって証明される。公開鍵の代わりに、または公開鍵とともに、他のタイプの鋳造データが仕様に含まれ得る。

【0139】

トークン発行者702は、より洗練されたアクセス制御構造を提供するために、さらに多くの公開鍵を追加することができる。たとえば、トランザクションバリデータ701用の公開鍵が存在してもよく、その場合、トークントランザクションは、ブロックチェーンネットワーク106に送信される前にバリデータ701によって検証され、署名されてもよい。トークン発行者702は、トークンシステムが進化するにつれて、認証された公開鍵の階層構造を作成するために、マスタ証明書公開鍵を追加することもできる。以下で説明するように、トランザクション手数料の支払い専用の公開鍵が存在する場合もある。

【0140】

例示的なフレームワークでは、トークンはネイティブブロックチェーントークンにペグされている。簡潔にするために、本明細書ではビットコインの例が使用されるが、これがすべての実施形態を限定するものではないことを理解されたい。その場合、ビットコインとトークンの間には固定の変換レートが存在する。これは為替レートではない点に留意されたい。これは、単にトークン値を便宜的に表現したものにすぎない。たとえば、1000satoshi(sats)は1GBPを表し得る。したがって、出力として10,000satsを有するトークントランザクションの場合、トークン出力は10GBPのトークン値を有することになる。本稿執筆時点ではダスト制限が546satoshiであるため、ペギング比率を1:ダスト制限に定義する方が便利である可能性がある点に留意されたい。ここで、1は、トークンの割り切れない最小単位である。

【0141】

この例では、仕様は準備金発行比率を含み得る点に留意されたい。これは、トークン発行者702がその財務能力を超えるトークンを発行できないことを示唆している。トークン発行者702はまた、GBPトークンの発行を許可されるために中央銀行から有効なライセンスを取得する必要がある場合がある。管轄フィールドでは、トークンシステムが規制される場所を指定することができ、関連する法律を適用することができる。これらのコンプライアンスは第三者によって監査されてよく、監査結果は透明性を確保するためにチェーン上に置かれる場合がある。一般に、金融エンティティまたはトークン発行者に対する従来の手法はすべて、例示的なトークンフレームワークに統合することができる。ルール、規制、または法律の施行は、オンチェーンとオフチェーンの性質の組合せとすることができる。

【0142】

鋳造トランザクション
トークンを鋳造するために、トークン発行者702は鋳造トランザクションを構築する。以下に例を示す。

【表3】

【0143】

この例示的なトランザクションは、トークン発行者702によって準備され、公開鍵PK_mintによって検証できる署名を含む1つの入力を有する。鋳造トランザクションは、異なる形式の暗号データ、たとえば、署名または暗号化されたメッセージを含み得る。TxID_setupの仕様に従って、このトランザクションはx₁ GBトークンを鋳造し、それらはPK₁の所有者に割り当てられる。

【0144】

トランザクション手数料は、mint outpoint-1000x₁の値であり、ここでは、鋳造アウトポイントが、トランザクション手数料と第1の出力の値の両方をカバーするために正確な金額を有するようにトークン発行者702によって準備されたと仮定される。トランザクション手数料の詳細については、以下で説明する。

【0145】

ブロックチェーントランザクションは、次の場合にトークン鋳造トランザクションとして定義される。
1.トランザクション内のすべての入力が、鋳造用の公開鍵によって検証できる署名を含む、および
2.それは有効なブロックチェーントランザクションである。

【0146】

この定義の意味するところは、ビットコインが鋳造用の公開鍵で色分けされているということである。次いで、色は、鋳造トランザクションまたは複数の鋳造トランザクションから始まるトランザクションチェーン全体を通じて保存される。ブロックチェーントランザクションがトークントランザクションであるかどうかをチェックするには、トランザクションチェーンを介して鋳造トランザクションまで遡って追跡することができる。しかしながら、これは技術的な課題を引き起こす可能性があるため、以下で説明するように、これらの問題を軽減または排除するために本開示の実施形態が提供される。

【0147】

トークン発行者702は、トークンの需要を満たすために複数のそのようなトランザクションを構築することができる。この場合、鋳造できるトークンの数は、トークン発行者702が有するビットコインの数と仕様におけるルールによって制限される。

【0148】

使用トランザクション
鋳造トランザクションがブロックチェーン150上で公開されると、鋳造トランザクションのトークン出力がロックされている公開鍵を所有するトークンユーザ703は、トークンを使用することができる。

【0149】

TxID_mintを使用する次のトランザクションTxID_spendについて考えてみる。

【表4】

【0150】

このトランザクションには、公開鍵PK_mintへの明示的な参照はない。このトランザクションをトークントランザクションとして識別するために、入力において参照されるトランザクション、TxID_mintまで遡って追跡する必要がある。TxID_mintをローカルに、またはブロックチェーンネットワーク106から取得することによって、それが有効なトークン鋳造トランザクションであること、したがってTxID_spentがトークントランザクションであることを検証することができる。トークントランザクションを検証するために、次の3つの主要なチェックが必要である。
1.入力において参照されているアウトポイントは未使用である、
2.出力値は入力値以下である、および、
3.署名は有効である(または、スクリプトの検証が成功している)。

【0151】

これらすべてのチェックは通常のブロックチェーントランザクションの検証と同時に行われる点に留意されたい。したがって、すべてのチェックをブロックチェーンノード104に委任することができる。要約すると、従来、トークントランザクションの検証は次の2つのステップのみで構成される。
1.入力がトークン鋳造トランザクションまで遡って追跡することができることをチェックする、および、
2.ブロックチェーンノードから、トークンはブロックチェーンが有効であるという確認を取得する。

【0152】

しかしながら、本開示の実施形態は、以下に説明するような修正を提供する。

【0153】

トランザクション手数料
トランザクション手数料が処理され得る方法は3つある。第1はトークンのみの手法である。トークントランザクション検証における簡素性を維持し、トークントランザクションがトークンの入力と出力のみで構成されることを保証するために、トークンのごく一部をバーンさせることによってトランザクション手数料を支払うことができる。TxID_spendに示されるように、PK₁の所有者はx₂ GBPトークンをPK₂の所有者に転送する。トランザクション手数料1000(x₁-x₂)は、実質的に(x₁-x₂)個のトークンをバーンする。トークンユーザの場合、これはトークン転送の手数料と考えることができる。トークン発行者にとって、これはシステム内のトークンの数が使用量に応じて減少することを意味する。これは、自然に価値が下がるある種のトークンにとって望ましい機能である可能性がある。一方、これがトークン発行者702にとって問題である場合、トランザクション手数料を補うために新しいトークンを時々鋳造することができる。

【0154】

手数料ゼロのトランザクションがブロックチェーンノード104に受け入れられる場合、トークントランザクションに対する手数料の支払いの問題は解消される。しかしながら、トークン発行者702は、ビジネス契約を介して法定通貨でオフチェーンのブロックチェーンノード104に支払わなければならない場合がある。この場合、トークン発行者702は事実上、トークンユーザ703にトランザクション手数料を支払っていることになる。

【0155】

第2は公開鍵手法である。もう1つの可能性は、トークントランザクションにおける入力の目的を示すために公開鍵を使用することである。この場合、トークン発行者702は、セットアップトランザクションにおける仕様に手数料支払い公開鍵またはそれらのセットを導入することができる。手数料支払い公開鍵は、トークン発行者によって所有され、トークンウォレットに配布することができる。このアイデアは、正確な金額のトランザクション手数料をカバーするために、すべてのトークン使用トランザクションにも1つの入力を追加することである。以下に例を示す。

【表5】

【0156】

手数料アウトポイントは、トークン鋳造トランザクションまで遡って追跡することができないという意味で、トークン入力ではない点に留意されたい。しかしながら、ロック解除スクリプト内の公開鍵は、トークン発行者702によって認証された有効な公開鍵として識別できるため、手数料アウトポイントはトークントランザクションを無効にするものではない。より柔軟にするために、トークン発行者はユーザが手数料支払い公開鍵を登録できるようにする場合がある。認証された手数料支払い公開鍵のリストは、仕様の更新バージョンにおいて公開することができる。

【0157】

この手法の利点は、トークントランザクションの出力がすべてトークン出力であることである。これにより、検証が簡単になる。トークン発行者702として、手数料支払い入力をトークン転送の承認として使用することも可能である。トークンユーザ703は、最初に部分トランザクションを構築する。トークン発行者702またはウォレットソフトウェアは、トランザクションを完了するために手数料入力を追加することによってトランザクションを承認する。この追加の承認プロセスはまた、ユーザが誤ってトークンをバーンさせることを防ぐ。

【0158】

トークンのみの手法に関して、この手法には2つの欠点がある。
1.いくつかの追加チェックを導入する必要がある。
a.手数料公開鍵が仕様に含まれていることをチェックする。
b.出力の値がトークン入力の値と等しい(または、それ以下)ことをチェックする。これは、トークンユーザが手数料支払い入力から一部のビットコインを「借りる」ことによってトークン出力値をつり上げないようにするためである。トークンのみの手法では、入力はトークン入力のみで構成されるため、チェックは合計出力値が合計入力値以下であるかどうかと同じであり、これをブロックチェーンノード104に委任することができる。
2.手数料アウトポイントは、トランザクション手数料を支払うための正確な金額を含む必要がある。非トークン出力は許可されていないため、変更は収集できない。このため、トークンユーザまたはトークン発行者は、トークンを転送する前に手数料アウトポイントを準備する必要がある。

【0159】

1bによって生じるオーバーヘッドは計算の点では無視することができるが、それがもたらす利点は、トークンの誤ったバーンを防ぐという点で非常に重要である。第2の欠点は、トークントランザクション要求ごとに適切な手数料アウトポイントを提供するために、トークン発行者702によって所有される手数料アウトポイントプールまたはサーバを有することによっても軽減することができる。

【0160】

第3は、SIGHASH_SINGLE手法である。ここでの目標は、トランザクション手数料の支払いにおける柔軟性の欠如に対処し、同時にトークンと非トークンの出力の混乱を解消することである。トランザクション手数料の支払いと一部の変更の収集には、トークントランザクションからの1つの入力と1つの出力だけが必要であることがわかる。この入力と出力のペアをリンクするためにSIGHASH_SINGLEを使用し、出力を他の出力と区別できるようにすることができる。

【0161】

SIGHASH_SINGLEは、署名によって署名されたメッセージが、署名を含む入力と同じインデックスを有する出力を除くすべての出力を除外することを示すために、署名に付加されたフラグである。他のブロックチェーンは同じ目的で異なる署名フラグを使用し得、SIGHASH_SINGLEは説明のための例としてのみ使用される点に留意されたい。これは、署名された出力のインデックスが同じままであれば、署名を無効にすることなくトランザクションに出力を追加または修正できることを意味する。SIGHASH_NONEが含まれていないため、入力を追加または修正することはできない。

【0162】

使用トランザクションを構築するために、ユーザはウォレットソフトウェア、またはトランザクション手数料に資金を提供するエンティティ(ユーザ自身でも可能)にトークン入力を提出し、たとえば、TxID_mint||0である。次いで、不完全なトランザクションは次のように構築される。

【表6】

署名Sig_feeは、

【数1】

に示されているすべての入力と第1の出力に署名している点に留意されたい。

【0163】

不完全なトランザクションを受信または構築すると、ユーザ703は任意の数のトークン出力を追加することによってトランザクションを完了し、更新されたトランザクションに署名する。

【表7】

【0164】

このトランザクションでは、署名Sig₁がすべての入力と出力に署名する。値については次の式がある。
トランザクション手数料=手数料アウトポイントの値-z
x₁=x₂+x₃

【0165】

手数料支払い入力とトークン入力を区別する方法はいくつかある。
1.入力がトークン出力であるかどうかをチェックする。参照用のトークンアウトポイントのリストがない場合、これは非常に困難になる。手数料のアウトポイントから遡って追跡し始めると、否定的な結論に達するまでに長い時間がかかる可能性がある。
2.第1の入力が常に手数料支払い入力になるように定義する。これはウォレットソフトウェアの一部として実装することができる。
3.SIGHASH_SINGLEを使用して入力を手数料支払い入力として定義する。これは、他のトークン入力でSIGHASH_SINGLEを使用できないことを意味する。

【0166】

手数料支払い入力とトークン入力を区別できると仮定すると、非トークン出力を識別するためには、出力のインデックスが手数料支払い入力のインデックスと同じかどうかをチェックするだけである。

【0167】

しかしながら、SIGHASH SINGLEが手数料支払い入力にフラグを立てるために使用されると仮定すると(方法3)、手数料支払い入力を識別せずに非トークン出力を直接識別することができる。出力ごとに、その出力に署名した署名の数をカウントすることができる。非トークン出力は、手数料支払い入力からの追加の署名が常に少なくとも1つあるため、署名の数が最も多くなる。

【0168】

トークン出力のこの機能は、アウトポイントレベルにおいて別のタイプの有向非巡回グラフを誘発する。

【0169】

アウトポイント署名有向非巡回グラフ(O-S DAG)
アウトポイント署名有向非巡回グラフはDAGであり、
1.ノードはブロックチェーントランザクションのアウトポイントであり、
2.第2のノードが、第1のノードを割り当てる(使用する)ために必要な署名によって署名されたメッセージの一部である場合、あるノードから別のノードへの有向エッジが確立される。

【0170】

大まかに言えば、ノードとしてアウトポイントがあり、エッジとして署名がある。O-S DAG内のすべてのエッジは、ブロックチェーントランザクション内で確立される。図5は、例として

【数2】

を使用したO-S DAGの例を示している。

【0171】

このSIGHASH_SINGL手法の利点は、トランザクション手数料を支払う際に柔軟性を提供できることである。

【0172】

非トークン入力のセキュリティ
トランザクション手数料を支払うために、トークントランザクションに非トークン入力を導入した。これらの非トークン入力は、トークン出力の値をつり上げるために誤って、または悪意を持って使用され得る。どれらのトークントランザクションが無効であるとみなされることを確認するために、チェックを実装する必要がある。

【0173】

トークントランザクションのsatoshiにおける入力値の合計をVI_token+VI_non-tokenと仮定すると、出力値の合計がVO_token+VO_non-tokenであり、トランザクション手数料がV_feeであり、以下を有する。
VO_token+VO_non-token+V_fee=VI_token+VI_non-token

【0174】

VO_token=VI_tokenであることが予想される。しかしながら、トークンユーザはVO_non-tokenまたはV_feeのいずれかからいくつかのsatoshiを取得することができる。すなわち、以下のとおりである。
VO'_token+VO'_non-token+V'_fee=VO_token+VO_non-token+V_fee
上式で、VO'_token>VO_token、およびVO'_non-token+V'_fee<VO_non-token+V_feeである。

【0175】

ブロックチェーントランザクションとしてはまだ有効である。トークントランザクションとしては無効とみなされる。トークントランザクションのペアの例を以下に示す。

【表8】

【表9】

【0176】

第1のトランザクションは、トークン出力がトークン入力と同じ値を持ち、手数料入力と手数料出力との間の差が2000satoshiのトランザクション手数料を示すという意味でトークン有効である。第2のトランザクションは、トークン出力がトークン入力よりも大きいという意味でトークンが無効である。しかしながら、インプットの合計値とアウトプットの合計値の差は、1000satoshiのトランザクション手数料を示す。このトランザクションはブロックチェーンが有効であり、ブロックチェーンノードによって受け入れられる。したがって、このトランザクションが公開されると、1000satoshiによって表されるトークンの価値が失われることになる。

【0177】

トークンのみの手法と公開鍵手法において、トークンの入力と出力が完了した後に手数料支払い入力を追加する必要がある。したがって、手数料支払いエンティティ(トークン発行者またはウォレットソフトウェア)は、トークントランザクションに署名する前にチェックを強制することができる。トークンをバーンさせてしまうため、ユーザがこのように意図的にトークン出力をつり上げるインセンティブがない点に留意されたい。一方で、偶発的な間違いはブロックチェーン上に不変に記録される。トークンユーザは、そのアクシデントが本物であることをトークン発行者に示し得、発行者はユーザに払い戻すために新しいトークンを鋳造することを選択し得る。しかしながら、あらゆる偶発的な間違いを避けることが依然として重要である。

【0178】

トークントランザクションの有効性
トークンの鋳造方法と使用方法について説明した。これで、トークントランザクションの有効性について包括的な定義を与えることができる。

【0179】

定義-トークンアウトポイント
アウトポイントTxID||Indexは、次の場合にトークンアウトポイントである。
1.トランザクションTxIDがトークン鋳造トランザクションである、または
2.トークン鋳造トランザクションからトランザクションTxIDへのトランザクションパスが存在する、および
3.インデックスは、手数料支払い入力または非トークン入力のインデックスに対応しない。

【0180】

定義-トークントランザクションの有効性
トークントランザクションは、それが有効なトークン鋳造トランザクションである場合、または以下である場合、有効である。
1.ブロックチェーンが有効である、
2.入力の少なくとも1つがトークンアウトポイントを参照する、および、
3.トークン出力の合計値がトークン入力の合計値以下である。

【0181】

上記の定義を考慮すると、ブロックチェーントランザクションごとに、それを鋳造トランザクションまたはコインベーストランザクションまで遡って追跡する必要がある。最終的に鋳造トランザクションになる場合、そのトランザクションはトークントランザクションである。鋳造トランザクションを識別せずにコインベーストランザクションになった場合、そのトランザクションはトークントランザクションではない。トークンシステムが拡張されると、トークントランザクションを識別して検証することが困難になる場合がある。これを改善する1つの方法は、知られている有効なトークントランザクションの記録を保持することである。バリデータは、鋳造トランザクションまで遡って追跡する代わりに、知られている有効なトークントランザクションにおいて停止することができる。さらに、バリデータが未使用のトークンアウトポイントの信頼できるセットにアクセスできる場合、追跡をセットのメンバーシップをチェックする検索動作に置き換えることができる。

【0182】

トークンシステムのスケーラビリティに対処するために、トークントランザクションの検証を最適化するためのいくつかのオプションを提案する。すべてのトークントランザクションの記録を保持するトークンサーバ601の説明から始める。次いで、トークンシステムのライトクライアントの説明につながる記録上のブロック構造を提案する。効率をさらに向上させるために、トークンUTXOスナップショットを利用するトークンクライアントを利用することができる。

【0183】

定義-トークンサーバ
トークンサーバ601は次の要件を満たす必要がある。
1.トークントランザクションを検証することができる、および
2.ブロックチェーンネットワークに接続している。

【0184】

最初の要件は、ブロックチェーントランザクションの入力がトークン入力であることを認識するために、トークンサーバ601がトークンシステムに関する何らかの情報を記憶する必要があることを意味する。これを達成するには多くの方法がある。

【0185】

最も簡単な方法は、トークン設定トランザクションをトークン仕様および後続のすべてのトークントランザクションとともに記憶することである。トークンサーバ601は、入力内の公開鍵および対応する署名をチェックすることによって、トランザクションがトークン鋳造トランザクションであるかどうかをまずチェックする。トークン鋳造トランザクションではない場合、トークンサーバ601は、ブロックチェーントランザクションの入力が過去のトークントランザクションからのものであるかどうかをチェックする。チェックに合格した場合、トークンサーバ601は、以下に定義されるようにトークントランザクションの検証を開始することができる。

【0186】

ダブル使用チェックはブロックチェーンノードによって提供され、トークンクライアントにとってはオプションである点に留意されたい。トークンサーバ601がトランザクションの有効性に関する一部のチェックをブロックチェーンノードに委任する場合、ノードはネットワークからの有効性の確認を待つ必要がある。したがって、定義には第2の要件がある。

【0187】

署名検証をフォーマットチェックに置き換えることも可能であり、実装がより効率的になる。このアイデアは、公開鍵が入力において与えられたときに、対応する署名も存在することを保証し、署名の検証をブロックチェーンノードに委任することである。これは、ロックスクリプトが標準のP2PKHであり、入力内のロック解除スクリプトが1つの公開鍵と1つの署名だけを含んでいる場合に実現することができる。他の一般的なスクリプトを許可する場合があり、スクリプトに問題がある場合は署名検証に戻ることができる。

【0188】

トークンブロック
トークンサーバ601に記憶されるデータの構造に関して、ブロックチェーンシステムを模倣し、トークンブロックの概念を導入することができる。これにより、次のセクションにおいてトークンライトクライアント602aの概念を導入できるようになる。トークンブロックの定義の例を以下に示す。

【0189】

定義-トークンブロック
トークンブロックは、ブロックヘッダと有効なトークントランザクションのリストを備える。ブロックヘッダには、次のフィールドの一部またはすべてを含み得る。
1.バージョンは、このブロックがどのトークンシステムに属しているかを示す、
2.前のブロックヘッダハッシュは、前のトークンブロックヘッダのダブルSHA256値であり、ジェネシストークンブロックでは空である、
3.マークルルートは、そのトークンブロック内のトークントランザクションに基づいて計算される、
4.ビットコインブロックの高さは、すべてのトークントランザクションがどのビットコインブロックからのものであるかを示す、
5.トランザクション数は、トークンブロックに含まれるトークントランザクションの総数を示す。

【0190】

各署名者がブロックの有効性を検証したことを示すために、デジタル署名のリストを各トークンブロックに追加することができ、トークンブロックは次の場合に有効である。
1.すべてのトランザクションはトークンが有効である、
2.すべてのトランザクションは、ブロックチェーンブロックの高さによって指定されたブロックチェーンブロックからのものである、
3.前のトークンブロックヘッダのハッシュ値を含む、
4.トークントランザクションのマークルルートが正しく計算されている、
5.トランザクション数が正しい。

【0191】

新しいブロックチェーンブロックが公開されるとすぐに、トークンブロックがトークンサーバ601として構築される。たとえば、新しく公開されたブロックチェーンブロックがあるとする。

【表10】

【0192】

トークンサーバ601は、トークンブロックを次のように構築する。

【表11】

【0193】

1.ブロックがどのトークンシステムに属しているかを示すために、バージョンフィールドを使用する。
2.前のブロックのハッシュは、前のブロックヘッダのハッシュ値になる。ここではプルーフオブワークは必要ない点に留意されたい。
3.マークルルートは、トークンブロックに含まれるトランザクションから計算される。別の方法は、ビットコインマークルルートを使用することである。
4.すべてのトークントランザクションがどのビットコインブロックに属しているかを示すために、ビットコインブロックの高さと呼ばれる新しいフィールドを使用する。
5.トランザクション数は、トークンブロック内に存在するトランザクションの数を示す。
6.トランザクションの完全なリストがトランザクションフィールドに表示される。
7.署名フィールドを使用すると、エンティティはブロックヘッダに署名するデジタル署名を追加できるようになる。これは、トークン発行者または委任者からの署名である可能性がある。署名は、トークンブロックが正常に検証された後にのみ追加されるべきである。

【0194】

トークンブロックヘッダは、トークンブロックにおける最初の5つのフィールドを備える点に留意されたい。

【0195】

ブロックチェーンブロックごとに存在できるトークンブロックは最大1つだけであり、トークンブロックに2つの異なるブロックチェーンブロックからのトランザクションのセットを含めることはできない。

【0196】

トークンシステムに必要なプルーフオブワークはない。しかしながら、トークンシステムに関するすべての情報はブロックチェーン台帳から取得できるため、トークンシステムのセキュリティはブロックチェーンシステムから継承される。ブロックに追加された署名は、トークンブロック検証のショートカットを提供する。しかしながら、ユーザが署名者を信頼しない場合でも、依然として独自にブロックを検証することができる。トークンブロックの検証に必要な情報はすべて、ブロックチェーン台帳で公開されており、利用可能である。一方、トークンブロックが公的に検証できることを考えると、署名者は無効なトークンブロックに署名しないように動機付けられる。

【0197】

一般的な懸念は、まれに時折発生するオーファンブロックである。実際、トークンシステムはブロックチェーンシステムと同様に再編成の対象となる。より多くのプルーフオブワークを持つ別の長いチェーンが存在するために、有効なブロックがオーファンになると、そのブロック内にあり、他の長いチェーンには含まれていないすべてのトランザクションがそれらの未公開ステータスに戻る。トークンステータスにも同じことが当てはまる。しかしながら、多くの場合と同様、競合するチェーン上のトランザクションは同一であるため、誠実なユーザと誠実なブロックチェーンノードは再組織化の影響を受けない。トークン発行者は、トークンシステムに関する正確な最新のビューを把握するためには、トークンシステムを維持するトークンサーバ601がネットワークの大部分に接続されていることを確認する必要がある。

【0198】

トークン検証を最適化するために、トークントランザクションのストレージを最小限に抑え、検索の効率を向上させようとすることができる。ビットコインライトクライアントに相当するものとして、トークンライトクライアント602aを導入する。

【0199】

トークンライトクライアント
トークンライトクライアント602aは、以下を維持するトークンクライアントである。
1.トークンセットアップトランザクション、
2.トークンブロックヘッダ、
3.トランザクションID内のトークントランザクション、および
4.記憶されているトランザクションIDごとのトークン値と各出力のインデックス。

【0200】

最後の2つの項目は、TxID||index||value形式の文字列に連結することができる。トークンライトクライアント602aは、トークントランザクション検証およびトークンブロック構築が可能である。

【0201】

トークントランザクションがトークンライトクライアント602aに送信されると、以下のステップを実行する。
1.入力内の公開鍵をトークン仕様の公開鍵と比較することによって、トークントランザクションが鋳造トランザクションであるかどうかをチェックする。
2.鋳造トランザクションではない場合、入力ごとに、参照されたアウトポイントがローカルに記憶されているトークンアウトポイントと一致するかどうかをチェックする。
3.一致する場合、すべてのトークン出力を識別し、トークン入力の合計値がトークン出力の合計値と等しい(または、それより大きい)ことをチェックする。

【0202】

チェックに合格した場合、トークンライトクライアント602aは、そのトークン出力ごとにトランザクションをTxID||index||value||flagとして保存する。フラグは、対応するトランザクション出力(TxID||index)が使用済みか未使用かを示す。次いで、トークントランザクションはさらなるチェックのためにブロックチェーンネットワークに送信される。

【0203】

トークンライトクライアント602aがブロックチェーンノードからトランザクションが有効であるか受け入れられたという確認を取得すると、トークンライトクライアント602aは次のトークンブロックにトランザクションを含めることができる。新しいブロックチェーンブロックが公開されると、トークンライトクライアント602aは対応するトークンブロックを構築することができる。トークンブロックを構築するために完全なトランザクションデータを有する必要はない点に留意されたい。トランザクションIDだけがあれば十分である。さらに、ブロックを構築するために必要なプルーフオブワークはない。すべてが正しく計算され記録されていることをダブルチェックすることが賢明な場合がある。トークンブロックは、トークン発行者からの署名を得ることによって完成させることができる。

【0204】

トークンUTXOクライアント
使用済みのトークントランザクションまたはトークンアウトポイントを記憶する必要がない場合があることを観察することによって、トークンシステムをさらに改善することができる。このセクションでは、上述のようにトークンサーバ601を維持し、トークンUTXOクライアント602bの概念を導入する。トークンUTXOクライアント602bは、すべての未使用トークンアウトポイントを追跡する責任を負い、これにより、トークントランザクションの識別と検証の効率が向上する。何か問題が発生した場合、トークンシステムは常にトークンサーバ601に戻ることができる。

【0205】

定義-トークンUTXOスナップショット
トークンUTXOスナップショットは、スナップショットヘッダとアウトポイントのセットとを備える。スナップショットヘッダは5つのフィールドを含む。
1.バージョンは、このスナップショットがどのトークンチェーンに属しているかを示す、
2.以前のスナップショットヘッダのハッシュは、以前のトークンスナップショットヘッダのダブルSHA256値である、
3.マークルルートは、トークンUTXOセット内のすべてのアウトポイントにおいて計算される、
4.ビットコインブロックの高さは、トークンUTXOセットがどのビットコインブロックまで派生するかを示す、
5.アウトポイントカウントは、トークンUTXOセット内のアウトポイントの総数を示す。

【0206】

トークンサーバ601および/またはトークンUTXOクライアント602bは、トークンUTXOスナップショットのリストを構築し、保持することができる。以下に例を示す。

【表12】

【0207】

この解の利点は、トークンクライアントがトークントランザクションを検証し、次のトークンUTXOスナップショットを構築するために必要なすべての情報を含むため、トークンクライアントとして最新のトークンUTXOスナップショットのみを記憶することを選択できることである。ブロックチェーントランザクションを受信する際、トークンクライアントは入力内のアウトポイントを検索し、それらが最新のトークンUTXOセットに含まれているかどうかをチェックするだけで済む。存在する場合、それらは有効なトークン入力である。トークンクライアントはダブル使用状態をチェックしない点に留意されたい。このチェックはブロックチェーンノードによって行われる。これは、UTXOベースのトークンシステムの主な利点の1つである。

【0208】

欠点は、最新のトークンUTXOスナップショットが破損している場合、トークンUTXOクライアント602bが利用可能な最後のトークンUTXOスナップショットを取得し、次いで後続のブロックチェーンブロックまたはトークンブロックが最新のスナップショットをブロックごとに導出する必要があることである。この場合、トークンサーバは必要な情報の信頼できるソースになる。

【0209】

最新のUTXOスナップショットが失われる潜在的なリスクをさらに軽減するために、トークン発行者は、トークンシステムを維持するために複数のトークンサーバと少数のトークンUTXOクライアントを有することを選択することができる。1つのトークンUTXOクライアント602bに障害が発生した場合、他のUTXOクライアントは、トークンシステムの中断のない実行を維持しながら、迅速な回復のための情報を提供することができる。

【0210】

図6は、トークンネットワークの例を示している。要約すると、トークンネットワークは、
・すべてのトークン関連トランザクションを記憶し、それらをブロックに構造化するトークンサーバ601、
・すべてのトークンアウトポイントおよびそれらの対応する値を記憶する1つまたは複数のトークンライトクライアント602a、
・すべての未使用のトークンアウトポイントおよびそれらの対応する値を記憶する1つまたは複数のトークンUTXOクライアント602b
の一部またはすべてを備える。

【0211】

それらはすべて、効率を向上させるためにトークントランザクションを検証し、チェックポイント(たとえば、トークンブロックまたはトークンUTXOスナップショット)を作成することができる。

【0212】

トークン検証の改善
上で説明したように、ブロックチェーントランザクションがトークントランザクションであるかどうかをチェックするために、トランザクションチェーンを介して鋳造トランザクションまで遡って追跡することができる。しかしながら、時間の経過とともにトークンの履歴チェーンの長さが増加すると、追跡および比較動作に必要なリソースが増大するため、システムが大規模な場合はこれを行うのは難しい場合がある。以下の技法は、本明細書で説明した「トークンブロック」および「トークンライトクライアント」手法に加えて、またはできればその代替として使用することができる。

【0213】

図7を参照すると、本開示の実施形態は、鋳造トランザクションまで遡って追跡する必要を回避するメカニズムを提供する。代わりに、少なくとも1つのトークン検証/認定要素が、鋳造トランザクションに続くある時点でトークントランザクションチェーンに挿入されるため、検証エンティティ701は、所与のまたは現在のトークントランザクション(上記のターゲットトークントランザクションなど)から識別可能な認定要素まで遡って追跡するだけでよい。1つの手法によれば、チェーン内の各トークントランザクションは、それが運ぶトークンを認証するために発行者によってスタンプすることができる。しかしながら、これは、発行者702および検証/使用当事者701、703に代わって多大なリソースを必要とする可能性がある。したがって、好ましい実施形態では、チェーンに認定要素が定期的にスタンプされ、チェーンをその起源に遡って横断する必要性が軽減されるとともに、チェーン内のすべてのトランザクションにスタンプを押す必要性が軽減されるようになる。定期的なスタンプのもう1つの利点は、オフラインのトークントランザクションの使用を可能にすることである。これは、インターネットおよび他のネットワークを介する接続が利用できない状況において非常に有利である。たとえば、飛行機内、または接続が不可能な地理的位置において行われるトランザクションや転送などである。そのようなオフライン転送は、発行者がすべてのトランザクションにスタンプを押す必要がある従来技術の手法では不可能である。
トークン認定要素は、トークントランザクションにおいて提供される少なくとも1つのトークンが発行者702によって、またはその代理として生成されたことを証明する。いくつかの実施形態では、トークントランザクションは1つのトークンを備えるが、他の実施形態では、トークントランザクションは複数のトークンを備え得る。これ以降、参照を容易にするために、単数形のトークンを参照する。同様に、1つまたは複数の認定要素がトークントランザクションにおいて提供され得、トークン、トークントランザクション、および/または認定要素は、1つまたは複数の鋳造トランザクションを使用して1つまたは複数の発行者によって発行され得る。しかしながら、便宜上、これらを単数形で参照する。

【0214】

いくつかの実施形態では、少なくとも1つのトークン認定要素が、要求または命令に応答してトークントランザクションにおいて提供される。要求または命令は、トークンユーザ703、あるいはトークンの意図された受信者、あるいは発行者702またはそれらの代理人、あるいは何らかの他の当事者から発信される可能性がある。追加的にまたは代替的に、認定要素は、少なくとも1つのあらかじめ定められたルールまたは基準に従ってトークントランザクションに提供することができる。ルール/基準の実行または評価は自動化することができ、検証エンティティ701によって、またはその代理として実行され得るソフトウェアベースのコンポーネントによって実行することができる。少なくとも1つのあらかじめ定められたルールまたは基準は、たとえば、トークントランザクションのチェーン内のトランザクションを識別または選択するためのしきい値、間隔、またはメトリックを指定して、次いで、認定要素は、発行者、または発行者702によってそれを行うことを認可されたエンティティによってそれに挿入されるようにすることができる。

【0215】

認定要素は、トークンが発行者702によって合法的に形成されたという点で、トークンが本物であることを示す何らかの形の証拠を備える。このようにして、トークントランザクション内のトークンを正当化し、トランザクション内に存在することは、検証プロセス中に鋳造トランザクションの代わりとして機能する。したがって、認定要素は、たとえば、発行者に知られている、または発行者に関連付けられる秘密のプルーフ、および/または暗号データなどのこの役割を果たす任意の適切な形式をとることができる。暗号データは、暗号鍵、署名、デジタル署名されたメッセージ、あるいは発行者または発行者によって認可されたもしくは発行者に関連付けられる当事者に関連付けられる他の暗号要素を備える場合がある。基本的に、認定要素は、発行者/認可された当事者に属する、または発行者/認可された当事者のみに知られていると信頼できる証拠を提供する。

【0216】

認定要素は、様々な場所および/または形式で、少なくとも1つのトークントランザクションにおいて提供することができる。たとえば、他の命令のOP_RETURNの後など、命令またはコードに続く位置においてトランザクションに挿入することができる。スクリプト内の別の場所に提供したり、および/またはメタデータとして提供したりすることができる。

【0217】

トークントランザクションのチェーンは、トークンの使用および送信を通じて時間の経過とともに成長するため、台帳150に追加されると、新しいトークントランザクションに同じまたは異なる認定要素が提供される。したがって、チェーンは、連続したトークントランザクションにおいて、またはできれば一定の間隔で提供される複数の認定要素を備え得る。認証されたトークントランザクションが間隔をあけて配置されている場合、それらのトランザクション間の間隔は、前述のルールまたは基準によって定義され得る。たとえば、認定要素は、台帳150上のトークントランザクションのx回ごとに提供され得る。間隔を決定するための他のメトリックは、容易に考案され実装され得る。あるいは、認定要素は、ランダムまたはアドホックに基づいて、または(前述のように)要求、命令、または監視される状態などのトリガイベントに応じてチェーンに挿入され得る。監視される状態は、ブロックチェーン上またはブロックチェーン外にあるエンティティ、リソース、または状態に関連し得る。

【0218】

認定要素は、特定のトークントランザクション内のトークンが実際に発行者702によって発行されたものであることを検証または認定する必要があるエンティティまたは当事者によって利用することができる。これは、たとえば、検証エンティティ701、またはユーザ703、またはトークンクライアント602bであり得る。従来、そのような当事者は、実際に発行元によって生成されたことを検証するために、トランザクションチェーンを鋳造トランザクションまで遡って追跡することによってトークンの出所を確立する必要があるが、本開示の実施形態により、検証当事者は、トークントランザクションから、トークン認定要素を備える前のトークントランザクションまでのみ、トークントランザクションのチェーンを横断することができる。これにより、エネルギー、時間、および処理リソースが大幅に節約される。

【0219】

本開示の実施形態は、トークンの溶解および再鋳造に関する特徴を備え得る。これらの機能は、上で説明した検証技法に加えて、またはそれと並行して、またはそれと併せて提供され得る。そのような実施形態によれば、上記のように、少なくとも1つのトークンは、ブロックチェーン(150)上のトークントランザクションにおいて提供され、発行当事者702によって、またはその代理として元の鋳造トランザクションにおいて生成される。有利なことに、トークンは溶解され、再鋳造される。いくつかの実施形態では、これはアドホックランダムまたは擬似ランダムベースで実行され得るが、好ましい実施形態では、あらかじめ定められたしきい値、限界値、または指定された値に達したときに実行される。ある表現形式によれば、溶解は、トークンまたはトークントランザクションを修正すること、あるいはトークンがもはや有効である、または発行者702によって証明/認証されているとはみなされなくなるようなオフチェーン動作を実行することとして説明することができる。ある表現形式によれば、再鋳造は、トークンまたはトークントランザクションを修正すること、またはトークンが有効なままであるか、または発行者702によって証明/認証されたままであるが、修正または他の動作の実行が検証できるように、何らかのオフチェーン動作を実行することとして説明することができる。トークンは有効なままであり、発行者702によって承認されているが、その有効性は異なる形式で再び反映される。以前の形式ではもはや有効ではない。

【0220】

溶解する動作は、トークンがもはや有効ではないことを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備えることができる。溶解および再鋳造に使用される特定のメカニズムは、関連する実装形態に依存するが、1つの例示的な実施形態では、トークンがもはや有効ではないことを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備えることができる。再鋳造するステップは、トークンが有効であるが形式が変更されていることを示すために、識別要素、マーカ、またはデータの他の部分を提供することを含む、様々な方法で実行することができる。

【0221】

識別要素は、識別子、および/または、たとえば暗号鍵、署名、署名付きメッセージなどの暗号データを含む様々な形式をとることができる。好ましくは、識別要素は、少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者に関連付けられ、認可された発行者による承認または発行として機能する。識別要素は、ブロックチェーントランザクションにおいて、できればトークントランザクションにおいて、またはブロックチェーンから離れて提供されるストレージリソースにおいて提供することができる。

【0222】

あらかじめ定められたしきい値、限界値、または指定された値は、いつ達したかを決定するために、発行者または他の当事者によって監視することができる。これは、供給された値と比較することを含み得る。発行者または他の当事者が、しきい値に達したか、それを超えたと決定した場合、溶解および/または再鋳造動作を実行することができる。これにより、上で説明したように、必要なリソースを削減し、効率が向上するという利点が得られる。いくつかの実施形態では、あらかじめ定められたしきい値、限界値、または指定された値は、発行者または検証エンティティ(701)によって、またはその代理として決定される。

【0223】

結論
開示された技法の他の変形または使用事例は、本明細書の開示が与えられれば、当業者には明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。

【0224】

たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン150の特定の一例であり、上記の説明は一般に任意のブロックチェーンに適用し得ることが理解されるであろう。すなわち、本発明は決してビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に対する上記の言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104の言及と置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のように、ビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の記載された特性のうちのいくつか、またはすべてを共有し得る。

【0225】

本発明の好ましい実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成、公開、伝搬、および記憶する上述の機能の少なくともすべてを実施する。これらの機能のすべてではなく、1つまたは一部のみを実施する他のネットワークエンティティ(または、ネットワーク要素)が存在する可能性も排除されない。すなわち、ネットワークエンティティは、ブロックを作成および公開することなく、ブロックを伝搬および/または記憶する機能を実施し得る(これらのエンティティは、好ましいビットコインネットワーク106のノードとはみなされないことを思い出されたい)。

【0226】

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

【0227】

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

【0228】

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

【0229】

本明細書で開示される別の態様によれば、トークンサーバ、トークンUTXOクライアント、およびトークンライトクライアントの一部またはすべてのアクションを備える方法が提供され得る。

【0230】

本明細書で開示される別の態様によれば、トークンサーバ、トークンUTXOクライアント、およびトークンライトクライアントのコンピュータ機器を備えるシステムが提供され得る。

【0231】

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

【0232】

ステートメント1.少なくとも1つのトークンを生成するために、少なくとも1つの発行者によって、またはその代理として使用される、少なくとも1つの鋳造トランザクションから始まるトークントランザクションのチェーンにおける要素である、トークントランザクションにおいて提供される少なくとも1つのトークンの信頼性を是認または証明するブロックチェーン実装方法であって、
トークントランザクションにおいて、少なくとも1つのトークンが少なくとも1つの発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を提供するステップを備える、ブロックチェーン実装方法。

【0233】

ステートメント2.少なくとも1つのトークン認定要素が、
要求または命令に応答して、および/または、
少なくとも1つのあらかじめ定められたルールまたは基準に従って
トークントランザクションにおいて提供される、ステートメント1に記載の方法。

【0234】

ステートメント3.少なくとも1つのあらかじめ定められたルールまたは基準が、トークントランザクションのチェーン内のトランザクションを識別または選択するためのしきい値、間隔、またはメトリックを指定する、ステートメント2に記載の方法。

【0235】

ステートメント4.少なくとも1つの認定要素が、少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者によってトークントランザクションにおいて提供される、ステートメント1から3のいずれか1つに記載の方法。

【0236】

ステートメント5.少なくとも1つの認定要素が、
少なくとも1つの発行者に知られている、または少なくとも1つの発行者に関連付けられる秘密のプルーフ、および/または、
暗号データであって、好ましくは、暗号データが、少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者に関連付けられた暗号鍵、署名、デジタル署名されたメッセージ、または他の暗号要素であるか、またはそれらを含む、暗号データ
を備える、ステートメント1から4のいずれか1つに記載の方法。

【0237】

ステートメント6.少なくとも1つの認定要素がトークントランザクションにおいて提供され、
トークントランザクションを使用不可能にする命令またはコードに従う(たとえば、一部のブロックチェーンプロトコルにおけるOP_RETURNステートメント)、またはトランザクションのスクリプト内で、スクリプトがトランザクションの出力に関連付けられる、ステートメント1から5のいずれか1つに記載の方法。

【0238】

ステートメント7.トークントランザクションのチェーン内の少なくとも1つのさらなるトークントランザクションにおいて同じまたは異なる認定要素を提供するステップを備える、ステートメント1から6のいずれか1つに記載の方法。

【0239】

ステートメント8.トークンを生成するために、発行者によって、またはその代理として使用される、少なくとも1つの鋳造トランザクションから始まるトークントランザクションのチェーンにおける要素である、ブロックチェーンにおけるトークントランザクションにおいて提供される少なくとも1つのトークンを検証するブロックチェーン実装方法であって、
トークンが発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を備えているかどうかを決定するために、トークントランザクションを検査するステップ、および/または、
トークンが発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を備える、前のトークントランザクションがチェーン内で識別されるまで、ブロックチェーン上のトークントランザクションのチェーンをトークントランザクションから横断するステップ
を備える、ブロックチェーン実装方法。

【0240】

ステートメント9.トークントランザクションのチェーンを横断するステップが、トークントランザクションが少なくとも1つのトークン認定要素を備えない場合、およびその場合にのみ実行される、ステートメント8に記載の方法。

【0241】

ステートメント10.トークントランザクションのチェーンを横断するステップが、
少なくとも1つのトークン認定要素を備えるかどうかを決定するために、チェーン内のトークントランザクションを検査するステップを備える、ステートメント8または9に記載の方法。

【0242】

ステートメント11.少なくとも1つの認定要素が、
少なくとも1つの発行者に知られている、または少なくとも1つの発行者に関連付けられる秘密のプルーフ、および/または、
暗号データであって、好ましくは、暗号データが、少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者に関連付けられた暗号鍵、署名、デジタル署名されたメッセージ、または他の暗号要素であるか、またはそれらを含む、暗号データ
を備える、ステートメント8から10のいずれか1つに記載の方法。

【0243】

ステートメント12.ブロックチェーン(150)上のトークントランザクションにおいて提供される少なくとも1つのトークンを発行するブロックチェーン実装方法であって、
あらかじめ定められたしきい値、限界値、または指定された値に達したときにトークンを溶解および再鋳造するステップを備える、ブロックチェーン実装方法。

【0244】

ステートメント13.トークントランザクションが、少なくとも1つの発行者(702)によって、またはその代理として発行された少なくとも1つの鋳造トランザクションまでブロックチェーン上で追跡可能である、ステートメント12に記載の方法。

【0245】

ステートメント14.
少なくとも1つのトークンを溶解するステップが、トークンがもはや有効ではないことを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備え、および/または、
トークンを再鋳造するステップが、トークンが有効であるが形式が変更されていることを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備える、ステートメント12または13に記載の方法。

【0246】

ステートメント15.識別要素が、
識別子および/または暗号データである、ならびに/あるいは、
少なくとも1つの発行者、または少なくとも1つの発行者によって認可された当事者に関連付けられる、ならびに/あるいは、
ブロックチェーントランザクションにおいて、トークントランザクションにおいて、またはブロックチェーン外で提供されるストレージリソースにおいて提供される、ステートメント14に記載の方法。

【0247】

ステートメント16.供給された値と、しきい値、限界値、または指定された値との比較を実行することによって、あらかじめ定められたしきい値、限界値、または指定された値に達したかを評価するステップを備える、ステートメント12から15のいずれか1つに記載の方法。

【0248】

ステートメント17.あらかじめ定められたしきい値、限界値、または指定された値は、少なくとも1つの発行者、または少なくとも1つの発行者(702)によって認可された当事者、ユーザ(703)または検証エンティティ(701)によって決定される、ステートメント12から16のいずれか1つに記載の方法。

【0249】

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

【0250】

ステートメント19.コンピュータ可読ストレージ上に具体化され、1つまたは複数のプロセッサ上で実行されると、ステートメント1から17のいずれか1つに記載の方法を実施するように構成された、コンピュータプログラム。

【符号の説明】

【0251】

100 システム
101 パケット交換ネットワーク
102 コンピュータ機器
102a コンピュータ機器
102b コンピュータ機器
103 当事者
103a ユーザ
103a アリス
103a 第1の当事者
103b 第2の当事者
103b ボブ
104 ビットコインノード
104 ブロックチェーンノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク
106 ブロックチェーンネットワーク
107 サイドチャネル
150 ブロックチェーン
150 台帳
151 データブロック
151 新しいブロック
151 ブロックチェーンブロック
151n-1 ブロック
152 トランザクション
152i 先行するトランザクション
152j 現在のトランザクション
153 ジェネシスブロック(Gb)
154 順序付きセット(または「プール」)
155 ブロックポインタ
201 ヘッダ
202 入力
202 入力フィールド
203 出力
203 出力フィールド
401 トランザクションエンジン
402 ユーザインターフェース(UI)層
403 機能
500 ユーザインターフェース(UI)
501 UI要素
501 ユーザ選択可能な要素
502 UI要素
502 データ入力フィールド
503 UI要素
503 情報要素
601 トークンサーバ
602a トークンライトクライアント
602b トークンクライアント
602b トークンUTXOクライアント
602b トークンUTXOクライアントアプリケーション
700 システム
700 トークン化システム
701 検証エンティティ
701 トランザクションバリデータ
702 トークン発行者
702 発行当事者
703 トークンユーザ
703a トークンユーザ
703b トークンユーザ

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【手続補正書】

【提出日】2024-02-09

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

少なくとも1つのトークンを生成するために、少なくとも1つの発行者によって、またはその代理として使用される、少なくとも1つの鋳造トランザクションから始まるトークントランザクションのチェーンにおける要素である、トークントランザクションにおいて提供される前記少なくとも1つのトークンの信頼性を是認または証明するブロックチェーン実装方法であって、
前記トークントランザクションにおいて、前記少なくとも1つのトークンが前記少なくとも1つの発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を提供するステップを備える、ブロックチェーン実装方法。

【請求項2】

前記少なくとも1つのトークン認定要素が、
要求または命令に応答して、および/または、
少なくとも1つのあらかじめ定められたルールまたは基準に従って
前記トークントランザクションにおいて提供される、請求項1に記載の方法。

【請求項3】

前記少なくとも1つのあらかじめ定められたルールまたは基準が、トークントランザクションの前記チェーン内の前記トランザクションを識別または選択するためのしきい値、間隔、またはメトリックを指定する、請求項2に記載の方法。

【請求項4】

前記少なくとも1つのトークン認定要素が、前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者によって前記トークントランザクションにおいて提供される、請求項1に記載の方法。

【請求項5】

前記少なくとも1つのトークン認定要素が、
前記少なくとも1つの発行者に知られている、または前記少なくとも1つの発行者に関連付けられる秘密のプルーフ、および/または、
暗号データであって、好ましくは、前記暗号データが、前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者に関連付けられた暗号鍵、署名、デジタル署名されたメッセージ、または他の暗号要素であるか、またはそれらを含む、暗号データ
を備える、請求項1に記載の方法。

【請求項6】

前記少なくとも1つのトークン認定要素が前記トークントランザクションにおいて提供され、
前記トランザクションのスクリプト内で、前記スクリプトが前記トランザクションの出力に関連付けられ、
出力のスクリプト内のメタデータとして、
前記トークントランザクションを使用不可能にする命令またはコードに従う、請求項1に記載の方法。

【請求項7】

トークントランザクションの前記チェーン内の少なくとも1つのさらなるトークントランザクションにおいて同じまたは異なる認定要素を提供するステップを備える、請求項1に記載の方法。

【請求項8】

ブロックチェーンにおけるトークントランザクションにおいて提供される少なくとも1つのトークンを検証するブロックチェーン実装方法であって、前記ブロックチェーンは、前記トークンを生成するために、発行者によって、またはその代理として使用される、少なくとも1つの鋳造トランザクションから始まるトークントランザクションのチェーンにおける要素であり、前記ブロックチェーン実装方法が、
前記トークンが前記発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を備えているかどうかを決定するために、前記トークントランザクションを検査するステップ、および/または、
前記トークンが前記発行者によって、またはその代理として生成されたことを証明する少なくとも1つのトークン認定要素を備える、前のトークントランザクションが前記チェーン内で識別されるまで、前記ブロックチェーン上のトークントランザクションの前記チェーンを前記トークントランザクションから横断するステップ
を備える、ブロックチェーン実装方法。

【請求項9】

トークントランザクションの前記チェーンを横断する前記ステップが、前記トークントランザクションが前記少なくとも1つのトークン認定要素を備えない場合、およびその場合にのみ実行される、請求項8に記載の方法。

【請求項10】

トークントランザクションの前記チェーンを横断する前記ステップが、
前記少なくとも1つのトークン認定要素を備えるかどうかを決定するために、前記チェーン内のトークントランザクションを検査するステップを備える、請求項8に記載の方法。

【請求項11】

前記少なくとも1つのトークン認定要素が、
少なくとも1つの発行者に知られている、または前記少なくとも1つの発行者に関連付けられる秘密のプルーフ、および/または、
暗号データであって、好ましくは、前記暗号データが、前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者に関連付けられた暗号鍵、署名、デジタル署名されたメッセージ、または他の暗号要素であるか、またはそれらを含む、暗号データ
を備える、請求項8に記載の方法。

【請求項12】

ブロックチェーン(150)上のトークントランザクションにおいて提供される少なくとも1つのトークンを発行するブロックチェーン実装方法であって、
あらかじめ定められたしきい値、限界値、または指定された値に達したときに前記トークンを溶解および再鋳造するステップを備える、ブロックチェーン実装方法。

【請求項13】

前記トークントランザクションが、少なくとも1つの発行者(702)によって、またはその代理として発行された少なくとも1つの鋳造トランザクションまで前記ブロックチェーン上で追跡可能である、請求項12に記載の方法。

【請求項14】

前記少なくとも1つのトークンを溶解するステップが、前記トークンがもはや有効ではないことを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備え、および/または、
前記トークンを再鋳造するステップが、前記トークンが有効であるが形式が変更されていることを示すために、識別要素、マーカ、またはデータの他の部分を提供するステップを備える、請求項13に記載の方法。

【請求項15】

前記識別要素が、
識別子および/または暗号データである、ならびに/あるいは、
前記少なくとも1つの発行者、または前記少なくとも1つの発行者によって認可された当事者に関連付けられる、ならびに/あるいは、
ブロックチェーントランザクションにおいて、前記トークントランザクションにおいて、または前記ブロックチェーン外で提供されるストレージリソースにおいて提供される、請求項14に記載の方法。

【請求項16】

供給された値と、前記しきい値、限界値、または指定された値との比較を実行することによって、前記あらかじめ定められたしきい値、限界値、または指定された値に達したかを評価するステップを備える、請求項12に記載の方法。

【請求項17】

前記あらかじめ定められたしきい値、限界値、または指定された値が、前記少なくとも1つの発行者、または前記少なくとも1つの発行者(702)によって認可された当事者、ユーザ(703)または検証エンティティ(701)によって決定される、請求項13に記載の方法。

【請求項18】

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

【請求項19】

コンピュータ可読ストレージ上に具体化され、1つまたは複数のプロセッサ上で実行されると、請求項1から17のいずれか一項に記載の方法を実施するように構成された、コンピュータプログラム。

【国際調査報告】