特表 2024-527174 コンピュータで実施される方法およびシステム

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

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

(11)【公表番号】

(43)【公表日】2024-07-22

(54)【発明の名称】コンピュータで実施される方法およびシステム

(51)【国際特許分類】

   G06F 21/64 20130101AFI20240712BHJP

   G06F 9/46 20060101ALI20240712BHJP

   G06F 16/182 20190101ALI20240712BHJP

   G06F 16/28 20190101ALI20240712BHJP

【ＦＩ】

G06F21/64

G06F9/46 430

G06F16/182

G06F16/28

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023543423

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

(85)【翻訳文提出日】2023-07-19

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

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

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

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

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

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．ＪＡＶＡ

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

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

(72)【発明者】

【氏名】リッキー・チャールズ・ランド

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

5B175

【Ｆターム（参考）】

5B175AA01

(57)【要約】

本開示は、データセットのブロックチェーンに記憶された表現を検証するためのコンピュータで実施される方法に関する。方法は、オンチェーンデータセットへのデータセット参照を取得するステップを備え、オンチェーンデータセットは、ブロックチェーンに記憶され、トランザクションを搬送するデータを備え、トランザクションを搬送する各データは、オフチェーンデータセットに記憶されたイベントを示すデータを備える。方法は、オンチェーンデータセットを調査するステップと、オンチェーンデータセットの中のトランザクションを搬送する各データに対して、オフチェーンデータセットの中のイベントを示すデータがオフチェーンデータセットの中のイベントと関連付けられると判定するステップと、オンチェーンデータセットおよびオフチェーンデータセットが互いに対応することを検証するステップとを含む。

【特許請求の範囲】

【請求項1】

ブロックチェーンに記憶されたデータセットの表現を検証するためのコンピュータで実施される方法であって、
オンチェーンデータセットへのデータセット参照を取得するステップであって、前記オンチェーンデータセットが、前記ブロックチェーンに記憶され、かつトランザクションを搬送するデータを備え、トランザクションを搬送する各データが、オフチェーンデータセットに記憶されたイベントを示すデータを備えるステップと、
前記オンチェーンデータセットを調査するステップと、前記オンチェーンデータセットの中のトランザクションを搬送する各データに対して、
前記オフチェーンデータセットの中のイベントを示す前記データが前記オフチェーンデータセットの中のイベントと関連付けられると判定するステップと、
前記オンチェーンデータセットおよび前記オフチェーンデータセットが互いに対応することを検証するステップと
を備える、方法。

【請求項2】

前記オフチェーンデータセットの中の前記データアイテムが、少なくとも原像および前記原像のダイジェストを備える、請求項1に記載のコンピュータで実施される方法。

【請求項3】

前記オフチェーンデータセットの前記データを示す前記データが、前記オフチェーンデータセットの中のデータアイテムの原像のダイジェストを備える、請求項2に記載のコンピュータで実施される方法。

【請求項4】

前記オフチェーンデータセットの中の前記データアイテムを示す前記データが前記オフチェーンデータセットの中のデータアイテムと関連付けられると前記判定するステップが、
前記オンチェーンデータアイテムの前記原像と同じダイジェストをもつ前記オフチェーンデータセットの中のデータアイテムを見つけるステップを備える、請求項3に記載のコンピュータで実施される方法。

【請求項5】

前記オフチェーンデータセットの前記データアイテムを示す前記データが加えて、前記オフチェーンデータセットのデータアイテムの原像を備える、請求項2から4のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項6】

前記オフチェーンデータセットの中の前記データアイテムを示す前記データが前記オフチェーンデータセットの中のデータアイテムと関連付けられると前記判定するステップが、
前記オンチェーンデータアイテムと同じ原像をもつ前記オフチェーンデータセットの中のデータアイテムを見つけるステップを備える、請求項5に記載のコンピュータで実施される方法。

【請求項7】

前記オフチェーンデータセットの前記データアイテムを示す前記データがさらにイベントのハッシュを備える、請求項2から6のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項8】

前記オフチェーンデータセットの中の前記データアイテムを示す前記データが前記オフチェーンデータセットの中のデータアイテムと関連付けられると前記判定するステップが、
イベントの同じハッシュを有する前記オフチェーンデータセットの中のデータアイテムを見つけるステップを備える、請求項7に記載のコンピュータで実施される方法。

【請求項9】

前記オフチェーンデータセットの前記データアイテムを示す前記データがさらに、前記イベントおよび/または前記イベントのサブセクションを備える、請求項2から8のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項10】

前記オフチェーンデータセットの中の前記データアイテムを示す前記データが前記オフチェーンデータセットの中のデータアイテムと関連付けられると前記判定するステップが、
同じイベントおよび/または前記イベントのサブセクションを有する前記オフチェーンデータセットの中のデータアイテムを見つけるステップを備える、請求項7に記載のコンピュータで実施される方法。

【請求項11】

前記原像が、前記オフチェーンデータセットの中の先行するデータアイテムの前記原像のダイジェストを備える、請求項2から10のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項12】

前記オンチェーンデータセットの中の各トランザクションが、トランザクションのチェーンが形成されるようにさらなるトランザクションへのトランザクション参照を備える、請求項1から11のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項13】

前記オンチェーンデータセットを調査するステップが、
前記オンチェーンデータセットの中の所与のトランザクションを取得するステップと、
前記所与のトランザクションの中の第1のトランザクション参照に基づいて、またはさらなるトランザクションの中の第2のトランザクション参照に基づいて、さらなるトランザクションを取得するステップと
を備える、請求項12に記載のコンピュータで実施される方法。

【請求項14】

前記オンチェーンデータセットへの前記データセット参照が、トランザクションの前記チェーンの中の最初または最後のトランザクションへの参照である、請求項12または13に記載のコンピュータで実施される方法。

【請求項15】

前記オンチェーンデータセットへの前記データセット参照が、トランザクションの前記チェーンの中の前記最初または最後のトランザクションのトランザクションidを備える、請求項12から14のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項16】

前記オンチェーンデータセットへの前記データセット参照が、前記最初のトランザクションのブロックidを備える、請求項12から15のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項17】

前記オフチェーンデータセットの中のデータアイテムを取得するステップをさらに備える、請求項1から16のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項18】

前記オフチェーンデータセットの各データアイテムが、データベースにアクセスすることによって、および/または前記データベースを実質的にミラーリングするデータストレージにアクセスすることによって取得される、請求項1から17のいずれか一項または複数項に記載のコンピュータで実施される方法。

【請求項19】

プロセッサおよびメモリを備え、前記メモリが、前記プロセッサによる実行の結果として、請求項1から18のいずれか一項または複数項に記載のコンピュータで実施される方法を前記デバイスに実行させる実行可能命令を含む、デバイス。

【請求項20】

前記オンチェーンデータセットおよびオフチェーンデータセットを監査するように構成される請求項19に記載のデバイスと、
前記監査の結果を受信するように構成される第三者のデバイスと
を備える、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、1名または複数のクライアントのための、分散型台帳に関連する1つまたは複数のサービスのプラットフォーム、すなわちブロックチェーンを実装するための方法とシステムに関する。より具体的には、本開示は、限定はされないが、ブロックチェーンに関連するデータストレージの提供およびデータストレージの検証に関する。

【背景技術】

【0002】

ブロックチェーンとは、ある形式の分散型データ構造を指し、ブロックチェーンの複製は、分散型ピアツーピア(P2P)ネットワーク(以下では「ブロックチェーンネットワーク」と呼ばれる)の中の複数のノードの各々において維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを備え、各ブロックは、1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまでの1つまたは複数のブロックにまたがり得るシーケンスの中の先行するトランザクションを指し示す。コインベーストランザクションは以下で論じられる。ブロックチェーンネットワークに出されるトランザクションは、新しいブロックに含まれる。新しいブロックは「マイニング」と呼ばれることが多い処理により作成され、これは、複数のノードの各々が競争して「プルーフオブワーク」を実行すること、すなわち、ブロックチェーンの新しいブロックに含められることを待機している、順序付けられ妥当性確認された未処理のトランザクションの定められたセットの表現に基づいて、暗号パズルを解くことを伴う。ブロックチェーンはノードにおいて枝刈りされてもよく、ブロックの公開はブロックヘッダだけの公開により達成され得ることに留意されたい。

【0003】

ブロックチェーンにおけるトランザクションは、デジタル資産(すなわち、ある数のデジタルトークン)を運ぶこと、仮想化された台帳もしくは登録簿の仕訳のセットを順序付けること、タイムスタンプエントリを受信して処理すること、および/またはインデックスポインタを時間的に順序付けることのうちの、1つまたは複数を実行するために使用される。ブロックチェーンは、ブロックチェーンに追加の機能を重ねるためにも利用され得る。ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータに対するインデックスの記憶を可能にし得る。単一のトランザクションに記憶され得る最大のデータ容量にはあらかじめ指定された限界はないので、ますます複雑になるデータを組み込むことができる。たとえば、これは、ブロックチェーンの中の電子文書、またはオーディオデータもしくはビデオデータを記憶するために使用され得る。

【0004】

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

【0005】

最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは通常、ある額のデジタル資産、すなわちある数のトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出および拒絶は、ネットワークのエージェントとして活動し不正を報告して阻止する動機のある、競合するノードの活動によって実施される。情報を広く公開することで、ユーザはノードの実績を継続的に監査することが可能になる。ブロックヘッダのみの公開により、参加者はブロックチェーンの完全性が継続中であることを確実にすることが可能になる。

【0006】

「出力ベース」モデル(UTXOベースのモデルと呼ばれることがある)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。あらゆる消費可能な出力は、トランザクションの先行するシーケンスから導出可能であるデジタル資産の額を指定する要素を備える。消費可能な出力は、UTXO(「未消費トランザクション出力」)と呼ばれることがある。出力はさらに、出力のさらなる引き換えのための条件を指定するロッキングスクリプトを備え得る。ロッキングスクリプトは、デジタルトークンまたは資産を妥当性確認して移すために必要な条件を定義する述部である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、指し示された出力のロッキングスクリプトをアンロックするためのアンロッキングスクリプトをさらに備え得る。よって、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「標的」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定し、出力をアンロッキンングする1つまたは複数の条件を定義するロッキングスクリプトを備える、少なくとも1つの出力を備える。第2の標的トランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力をアンロックするためのアンロッキングスクリプトとを備える、少なくとも1つの入力を備える。

【0007】

そのようなモデルでは、第2の標的トランザクションが、ブロックチェーンにおいて広められて記録されるようにブロックチェーンネットワークに送信されるとき、各ノードにおいて適用される有効性の基準の1つは、アンロッキングスクリプトが第1のトランザクションのロッキングスクリプトにおいて定義される1つまたは複数の条件のすべてを満たすというものである。別の基準は、第1のトランザクションの出力が別のより前の有効なトランザクションによってまだ引き換えられていないということである。これらの条件のいずれかに従って標的トランザクションが無効であることを見出したいずれのノードも、トランザクションを広めず(場合によっては無効なトランザクションを登録するために有効なトランザクションとして広めない)、またブロックチェーンに記録されるべき新しいブロックにトランザクションを含めない。

【0008】

代替的なタイプのトランザクションモデルは、アカウントベースモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別のノードによって記憶され、定期的に更新される。

【0009】

現在の研究の一分野は、「スマートコントラクト」の実装のためにブロックチェーンを使用することである。これらは、機械可読の契約または合意の条件の実行を自動化するように設計されるコンピュータプログラムである。自然言語で書かれる従来の契約とは異なり、スマートコントラクトは機械実行可能プログラムであり、これは、結果を生み出すために入力を処理することができるルールを備え、そしてこのルールにより、それらの結果に依存して行為が実行されることが可能になる。ブロックチェーン関連の別の関心分野は、ブロックチェーンを介して現実世界のエンティティを表現して移すために「トークン」(または「カラードコイン」)を使用することである。取り扱いに注意を要する可能性のある、または秘密である可能性のあるアイテムをトークンによって表現することができ、トークンは認識可能な意味または値を有しない。したがって、トークンは、ブロックチェーンから現実世界のアイテムが参照されることを可能にする識別子として機能する。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】英国特許出願第2013929.1号

【特許文献2】英国特許出願第2102217.3号

【特許文献3】英国特許出願第2106950.5号

【特許文献4】英国特許出願第2102314.8号

【特許文献5】英国特許出願第2002285.1号

【発明の概要】

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

【0011】

上で言及された例またはシナリオは、永続的で耐改竄性のあるイベントの記録を提供するためにブロックチェーンの利点を利用しながら、クライアント、クライアントエンティティ、コンピューティングデバイス、またはクライアントに関連する端末が、たとえばBSV(Bitcoin Satoshi's Vision)ブロックチェーンによって使用される、楕円曲線デジタル署名アルゴリズム(ECDSA)のための暗号鍵を管理する、デジタル資産を管理するための機能を実装するためのデジタルウォレットなどの、ソフトウェアおよび/またはハードウェア、もしくはプロセッサ/モジュールを、含むことまたは実装することを必要とする。加えて、クライアントデバイスが、ブロックチェーントランザクションの構築を実施してBSVライブラリへのアクセス権を有することが可能であることも必要である。したがって、クライアントは、そのような機能を実装するための処理を含む必要があるだけではなく、スマートコントラクトまたは現実世界の資産のトランザクションを表すトークンに関するデータおよび/またはデジタル資産を送り、受け取り、見るためにブロックチェーンネットワークを利用できる前に、そのようなプロセスのために適切なセキュリティ対策が実施されることを確実にする必要もある。

【0012】

したがって、計算能力が高いかどうかにかかわらず、あらゆるクライアントが、計算的におよび機能的によりわずらわしくないような、簡単で、高速で、正確で、信頼性があり、セキュアな方式で、ブロックチェーンに関連する有用なアプリケーションに瞬時にアクセスしてそれと対話することを可能にする、セキュアで、複雑ではなく、ユーザフレンドリーで、効率的で、ロバストな技法を実施することが望まれる。より具体的には、クライアントに関連するあらゆるデータ、イベント、またはデジタル資産が、瞬時にかつセキュアにマイニングされ、またはブロックチェーンへと容易に書き込まれ得ることを、あらゆるクライアントコンピューティングデバイスが確実にすることを可能にし、それにより、必要に応じて作成し、書き込み、更新し、読み取り、または見ることができる、データの恒久的で耐改竄性があり監査可能な記録を提供するような、複数のブロックチェーンに関連するサービスまたはアプリケーションのための共通のプラットフォームまたはインターフェースを提供するために、分散型台帳(ブロックチェーン)技術、ならびにセキュリティ、透明性、記録の信頼性の向上という利点を利用することが望まれる。

【0013】

そのような改善された解決策が考案された。本開示は、1つまたは複数の技法を提案することによって上記の技術的な問題に対処し、それにより、クライアントに関連するデータまたは情報は、そのようなクライアントが、ブロックチェーンに関連するすべての利点を活かすことがそれでも可能でありながら、ブロックチェーンを使用するためのどのような処理または機能を実装する必要もなく、ブロックチェーンに関連する1つまたは複数のサービスのためのアプリケーションプログラミングインターフェース(API)を提供する、方法、デバイス、およびシステムによって、簡単に、セキュアに、かつ瞬時にブロックチェーンへと書き込まれ、またはそれから取得されることがある。

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

【0014】

第1の態様において、本開示は、ブロックチェーン上のストリームのステータスを維持するための、方法、デバイス、およびシステムを提案する。より詳細には、第1の態様の方法は、ストリーム作成メッセージを受信するステップであって、ストリーム作成メッセージがトリガのための条件の標示を備える、ステップと、トリガ条件が満たされたことに基づいて、ストリームの状態を示すデータを取得するステップと、ストリームの状態を示すデータを備える付加トランザクションを生成するステップを行うステップとを備える。

【0015】

第2の態様において、本開示は、データセットのブロックチェーンに記憶された表現を検証するための、方法、デバイス、およびシステムを提案する。より詳細には、第2の態様の方法は、オンチェーンデータセットへの参照を取得するステップであって、オンチェーンデータセットがブロックチェーンに記憶されており、トランザクションを搬送するデータを備え、トランザクションを搬送する各データが、オフチェーンデータセットの中のイベントを示すデータを備えるステップと、オンチェーンデータセットを調査するステップと、オンチェーンデータセットの中のトランザクションを搬送する各データに対して、オフチェーンデータセットの中のイベントを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップと、オンチェーンデータセットとオフチェーンデータセットが互いに対応すること検証するステップとを備える。

【0016】

第3の態様では、本開示は、データセットのブロックチェーンに記憶された表現を作成して検証するための、方法、デバイス、およびシステムを提案する。より詳細には、第3の態様の方法は、第1の態様による方法を使用してオンチェーンデータセットを生成するステップと、第2の態様によるオンチェーンデータセットを検証するステップとを備える。

【0017】

ここで、開示される方法のいくつかの具体的な構成要素および実施形態が、添付の図面を参照して例として説明され、同様の参照番号は同様の特徴を指す。

【図面の簡単な説明】

【0018】

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

【図2】例示的なトランザクションプロトコルを示す図である。

【図3A】クライアントアプリケーションおよびそのユーザインターフェースの例示的な実装形態を示す図である。

【図3B】クライアントアプリケーションおよびそのユーザインターフェースの例示的な実装形態を示す図である。

【図4】ネットワークの各ブロックチェーンノード上で実行されるノードソフトウェアの例を示す図である。

【図5】プラットフォームプロセッサ、データベース、およびブロックチェーンネットワークへのイベントデータの提出を示す概略図である。

【図6A】イベントストリームの現在の状態をブロックチェーンに出すための方法を示すフローチャートである。

【図6B】タイマ条件が満たされることに関連するデータおよび/またはプロセスフローを示すシーケンス図である。

【図7A】トランザクションのチェーンを示す概略図である。

【図7B】例示的なトランザクションの概略図である。

【図7C】例示的なトランザクションの概略図である。

【図8】ブロックチェーンにおいて表されるデータセットの検証を示す概略図である。

【図9】オフチェーンの記憶されたイベントストリームを用いてオンチェーンデータセットを検証するための方法を示すフローチャートである。

【図10】ある態様による、ブロックチェーンに関連する複数のサービスのためのプラットフォームの概要を示す概略図である。

【図11】ある態様による、ブロックチェーンに関連する複数のサービスのプラットフォームの構成要素を示す概略図である。

【図12】本開示の様々な態様および実施形態が実装され得るコンピューティング環境を示す概略図である。

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

【0019】

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

【0020】

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

【0021】

ブロックチェーン150はデータのブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散ネットワークまたはブロックチェーンネットワーク160の中の複数のブロックチェーンノード104の各々において維持される。上で言及されたように、ブロックチェーン150のコピーを維持することは、ブロックチェーン150を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン150は、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(以下で論じられる)を記憶する限り、データを枝刈りされ得る。チェーンの中の各ブロック151は1つまたは複数のトランザクション152を備え、この文脈においてトランザクションはある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、1つの特定のトランザクションプロトコルを全体で使用する。ある一般的なタイプのトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を備える。各出力は、ある数量のデジタル資産を表す額を財産として指定し、その例は、出力が暗号によりにロックされる対象であるユーザ103である(アンロック、および引き換えまたは消費のために、そのユーザの署名または他のソリューションを必要とする)。各入力は、先行するトランザクション152の出力を指し示し、それによりそれらのトランザクションをつなぐ。

【0022】

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

【0023】

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

【0024】

所与の現在のトランザクション152jにおいて、入力(または各入力)は、トランザクションのシーケンスの中の先行するトランザクション152iの出力を参照するポインタを備え、これは、この出力が現在のトランザクション152jにおいて引き換えられる、または「消費される」ことになることを指定する。一般に、先行するトランザクションは、順序付けられたセット154または任意のブロック151における任意のトランザクションであり得る。先行するトランザクション152iは、現在のトランザクション152iが作成される時点で、またはネットワーク106に送信される時点ですら、必ずしも存在する必要はないが、現在のトランザクションが有効になるためには、先行するトランザクション152iが存在して妥当性確認される必要がある。したがって、本明細書における「先行する」は、ポインタにより連結される論理シーケンスにおいて先行するものを指し、時間的な順序における作成または送信の時間を必ずしも指さず、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも排除しない(オーファントランザクションについての以下の議論を参照)。先行するトランザクション152iは同様に、祖先トランザクションまたは先行者トランザクションと呼ばれ得る。

【0025】

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

【0026】

ビットコインなどの出力ベースのトランザクションプロトコルによれば、ユーザまたは機械などのエンティティ103が新しいトランザクション152jを実施することを望むとき、エンティティはそのコンピュータ端末102から受信者に新しいトランザクションを送信する。エンティティまたは受信者は最終的に、このトランザクションをネットワーク106のブロックチェーンノード104(これは今日では通常はサーバまたはデータセンターであるが、原理的には他のユーザ端末であってもよい)のうちの1つまたは複数に送信する。新しいトランザクション152jを実施するエンティティ103がトランザクションをブロックチェーンノード104のうちの1つまたは複数に送信でき、いくつかの例では受信者に送信できないことも、排除されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかを確認する。ブロックチェーンノードプロトコルは通常、新しいトランザクション152jの中の暗号署名が予想される署名と一致することをブロックチェーンノード104が確かめることを必要とし、予想される署名は、トランザクション152の順序付けられたシーケンスの中の以前のトランザクション152iに依存する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション152jの入力に含まれるエンティティ103の暗号署名または他の承認が、新しいトランザクションが割り当てる先行するトランザクション152iの出力において定義される条件と一致することを確かめることを備えることがあり、この条件は通常、新しいトランザクション152jの入力の中の暗号署名または他の承認が、新しいトランザクションの入力がつなげられる以前のトランザクション152iの出力をアンロックすることを、少なくとも確かめることを備える。この条件は、先行するトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。

【0027】

代替として、それは単純にブロックチェーンノードプロトコルだけによって固定されてもよく、または、それはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じ試験を適用し、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送するなどする。このようにして、新しいトランザクションが、ブロックチェーンノード104のネットワーク全体に伝搬される。

【0028】

出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り当てられるかどうかの定義は、それがブロックチェーンノードプロトコルに従って別の前方のトランザクション152jの入力によりすでに有効に引き換えられているかどうかである。トランザクションが有効になるための別の条件は、そのトランザクションが割り当てることまたは引き換えることを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ割り当てられていない/引き換えられていないことである。やはり、有効ではない場合、トランザクション152jは、ブロックチェーン150において広められず(無効であるものとしてフラグを立てられて警告のために広められない限り)、または記録されない。これは、取引者が同じトランザクションの出力を一度より多く割り当てることを試みるような、二重消費から守る。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重消費から守る。やはり、トランザクションの定められた順序があるので、アカウント残高は任意のある時間において単一の定められた状態を有する。

【0029】

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

【0030】

パズルを解こうとする第1のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークの中の他のブロックチェーンノード104によって容易に確かめられ得る証明として解を提供する(ハッシュへの解が与えられると、それによりハッシュの出力が条件を満たすようになることを確かめるのは単純である)。第1のブロックチェーンノード104は、ブロックを受け入れしたがってプロトコルルールを実施する、他のノードの閾値コンセンサスにブロックを伝搬させる。トランザクションの順序付けられたセット154は次いで、ブロックチェーンノード104の各々によってブロックチェーン150の中の新しいブロック151として記録されるようになる。ブロックポインタ155はまた、チェーンの中の以前に作成されたブロック151n-1を指し示す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要とされる、たとえばハッシュの形式の大量の労力は、ブロックチェーンプロトコルのルールに従うという第1のノードの104の意図を示すものである。そのようなルールは、以前に妥当性確認されたトランザクションと同じ出力を割り当てる場合(これは別様に二重消費として知られている)、有効であるものとしてトランザクションを受け入れないことを含む。作成されると、ブロック151を改変することはできず、それは、ブロック151が、ブロックチェーンネットワーク106の中のブロックチェーンノード104の各々において認識され維持されるからである。ブロックポインタ155はまた、逐次的な順序をブロック151に課す。トランザクション152は、ネットワーク106の中の各ブロックチェーンノード104において順序付けられるブロックに記録されるので、これはトランザクションのイミュータブルな公開台帳を提供する。

【0031】

任意の所与の時間において競ってパズルを解く異なるブロックチェーンノード104は、それらのブロックチェーンノードがいつ解の探索を始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間におけるまだ公開されていないトランザクション154の順序付けられたセットの異なるスナップショットに基づいて、競ってパズルを解いていることがあることに留意されたい。それぞれのパズルを最初に解いた者が、どのトランザクション152が次の新しいブロック151nに含まれるか、およびどの順序で含まれるかを定義し、公開されていないトランザクションの現在のセット154は更新される。ブロックチェーンノード104は次いで、公開されていないトランザクション154の新しく定義された傑出した順序付けられたセットからブロックを競って作成し続け、以下同様である。生じ得るあらゆる「フォーク」を解決するためのプロトコルも存在し、これは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解き、その結果、ブロックチェーンの矛盾する景色がノード104間で伝搬されるようになる状況である。つまり、フォークの先端がより長く成長した方が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるので、これはネットワークのユーザまたはエージェントに影響しないはずであることに留意されたい。

【0032】

ビットコインブロックチェーン(および大半の他のブロックチェーン)によれば、新しいブロック104を構築することに成功するノードは、(あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を移す、エージェント間またはユーザ間のトランザクションとは対照的に)定められた数量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、許容される額のデジタル資産を割り当てる能力を与えられる。この特別なタイプのトランザクションは普通、「コインベーストランザクション」と呼ばれるが、「開始トランザクション」とも呼ばれ得る。それは通常、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で引き換えられることを可能にするプロトコルルールに従うという、新しいブロックを構築するノードの意図を示すものである。ブロックチェーンプロトコルルールは、この特別なトランザクションを引き換えられるようになるまで、成熟期間、たとえば100ブロックを必要とし得る。しばしば、通常の(非生成)トランザクション152はまた、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクションフィーを指定する。この料金は普通は「トランザクションフィー」と呼ばれ、以下で論じられる。

【0033】

トランザクションの妥当性確認および公開に関与するリソースにより、典型的にはブロックチェーンノード104の少なくとも各々が、1つまたは複数の物理サーバユニットを備えるサーバという形態をとり、またはデータセンター全体という形態すらとる。しかしながら、原理的には、あらゆる所与のブロックチェーンノード104は、一緒にネットワーク接続されたユーザ端末またはユーザ端末のグループという形態をとり得る。

【0034】

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

【0035】

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

【0036】

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

【0037】

各関係者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つまたは複数の他のネットワーク接続されたリソースを備え得る。

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

所与の関係者103、たとえばAliceが、新しいトランザクション152jをブロックチェーン150に含まれるように送信することを望むとき、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを編成する。彼女は次いで、クライアントアプリケーション105から、彼女が接続されている1つまたは複数のブロックチェーンノード104に、トランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最善に接続されるブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信するとき、ブロックチェーンノード104は、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従って、新しいトランザクション152jを扱う。これは、新しく受信されたトランザクション152jが「有効」であるための何らかの条件を満たすかどうかをまず確かめることを備え、その例がまもなくより詳しく論じられる。一部のトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替として、この条件は単に、ノードプロトコルの内蔵機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。

【0043】

新しく受信されるトランザクション152jが有効であるものとしてみなされるように試験に合格する条件(すなわち、それが「妥当性確認される」条件)のもとで、トランザクション152jを受信する任意のブロックチェーンノード104が、新しい妥当性確認されたトランザクション152をそのブロックチェーンノード104に維持されているトランザクションの順序付けられたセット154に追加する。さらに、トランザクション152jを受信するあらゆるブロックチェーンノード104は、妥当性確認されたトランザクション152以降をネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に伝搬させる。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがまもなくネットワーク106全体に伝搬されることを意味する。

【0044】

所与のブロックチェーンノード104において維持されるトランザクションの順序付けられたセット154の利用を認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むトランザクションのそれぞれの順序付けられたセット154の最新のバージョンについてのプルーフオブワークパズルを競って解き始める(他のブロックチェーンノード104が、トランザクションの異なる順序付けられたセット154に基づいてパズルを解こうとしていることがあるが、最初にたどり着いた者が最新のブロック1511に含まれるトランザクションの順序付けられたセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたセット154の一部のためのパズルを解く)。プルーフオブワークが、新しいトランザクション152jを含む順序付けられたセット154に対して行われると、それはイミュータブルに、ブロックチェーン150の中のブロック151のうちの1つの一部になる。各トランザクション152は、より前のトランザクションへのポインタを備えるので、トランザクションの順序もイミュータブルに記録される。

【0045】

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

【0046】

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

【0047】

UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と省略される)は、ブロックチェーン150の基本データ構造である(各ブロック151は1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルに言及して説明される。しかしながら、これはすべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルはビットコインに言及して説明されるが、それは他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。

【0048】

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

【0049】

Alice 103aが、対象のある額のデジタル資産をBob 103bに移すトランザクション152jを作成することを望んでいるとする。図2において、Aliceの新しいトランザクション152jは「Tx₁」とラベリングされる。Tx₁は、シーケンスの中の先行するトランザクション152iの出力203においてAliceにロックされるデジタル資産の額をとり、その少なくとも一部をBobに移す。先行するトランザクション152iは、図2では「Tx₀」とラベリングされる。Tx₀およびTx₁は任意のラベルにすぎない。それらは、Tx₀がブロックチェーン151の最初のトランザクションであることを必ずしも意味せず、Tx₁がプール154の中のすぐ次のトランザクションであることも意味しない。Tx₁は、Aliceにロックされている未消費の出力203をまだ有するあらゆる先行する(すなわち、祖先)トランザクションを指し示し得る。

【0050】

先行するトランザクションTx₀は、Aliceが新しいトランザクションTx₁を作成するとき、または少なくとも彼女がそれをネットワーク106に送信するときにはすでに、ブロックチェーン150のブロック151において妥当性確認されそれに含まれていることがある。それは、その時点ですでにブロック151のうちの1つに含まれていることがあり、または、順序付けられたセット154においてまだ待機していることがあり、その場合、それは新しいブロック151にまもなく含められる。代替として、Tx₀およびTx₁は、一緒に作成されてネットワーク106に送信されてもよく、または、ノードプロトコルが「オーファン」トランザクションのバッファリングを許容する場合、Tx₀がTx₁の後に送信されることすらあってもよい。トランザクションのシーケンスの文脈で本明細書において使用される「先行する」および「後続の」という用語は、トランザクションにおいて指定されるトランザクションポインタによって定義されるようなシーケンスにおけるトランザクションの順序を指す(どのトランザクションがどの他のトランザクションを指し示すか、など)。それらは、「先行者」および「後継者」、または「祖先」および「子孫」、「親」および「子」などにより等しく置き換えられ得る。これは、それらが作成される順序、ネットワーク106に送信される順序、または任意の所与のブロックチェーンノード104に到達する順序を必ずしも示唆しない。それでも、先行するトランザクション(祖先トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが妥当性確認されるまでは、かつ妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード104に到達する子は、オーファンであるとみなされる。それは、ノードプロトコルおよび/またはノード挙動に応じて、廃棄され、または親を待機するためにある時間の間バッファリングされ得る。

【0051】

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、ここでUTX0₀とラベリングされる特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが妥当性確認されるようにするために、したがってUTXOの引き換えが成功するために、後続のトランザクションの入力202におけるアンロッキングスクリプトによって満たされなければならない条件を定義するロッキンスクリプトとを備える。通常、ロッキングスクリプトは、額を特定の関係者(ロッキングスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロッキングスクリプトはアンロッキング条件を定義し、その条件は通常、後続のトランザクションの入力におけるアンロッキングスクリプトが、先行するトランザクションがロックされる対象である関係者の暗号署名を備えるという条件を備える。

【0052】

ロッキングスクリプト(scriptPubKeyとしても知られている)は、ノードプロトコルによって認識される分野特有の言語で書かれるコードである。そのような言語の具体的な例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロッキングスクリプトは、トランザクション出力203を消費するためにどの情報が必要とされるか、たとえば、Aliceの署名の要件を指定する。アンロッキングスクリプトは、トランザクションの出力に現れる。アンロッキングスクリプト(scriptSigとしても知られている)は、ロッキングスクリプト基準を満たすために必要とされる情報を提供する分野特有の言語で書かれるコードである。たとえば、それはBobの署名を含み得る。アンロッキングスクリプトはトランザクションの入力202に現れる。

【0053】

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

【0054】

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

【0055】

公開-秘密暗号による認証の詳細は、当業者には馴染みがある。基本的に、Aliceが自身の秘密鍵を使用してメッセージに署名した場合、平文のAliceの公開鍵およびメッセージを与えられると、ノード104などの別のエンティティは、メッセージがAliceによって署名されたに違いないことを認証することが可能である。署名することは通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージへとタグ付けすることで、公開鍵のあらゆる保有者が署名を認証することを可能にすることを備える。したがって、本明細書における、特定のデータまたはトランザクションの一部に署名することなどへのあらゆる言及は、実施形態では、そのデータまたはトランザクション一部のハッシュに署名することを意味することに留意されたい。

【0056】

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

【0057】

所与のトランザクション152のすべての出力203において指定される総額が、すべてのその入力202によって指し示される総額より大きい場合、これもまた、大半のトランザクションモデルにおいて、無効であることの根拠になる。したがって、そのようなトランザクションは、広められず、ブロック151にも含められない。

【0058】

UTXOベースのトランザクションモデルにおいて、所与のUTXOは全体として消費される必要があることに留意されたい。それは、消費されるものとしてUTXOにおいて定義される額の一部を、別の一部が消費されながら「置き去りにする」ことができない。しかしながら、UTXOからの額は、次のトランザクションの複数の出力の間で分割され得る。たとえば、Tx₀の中のUTXO₀において定義される額は、Tx₁の中の複数のUTX₀間で分割され得る。したがって、AliceがUTXO₀において定義される額のすべてをBobに与えることを望まない場合、彼女はリマインダーを使用してTx₁の第2の出力の残金を自分に与え、または別の関係者に支払うことができる。

【0059】

実際には、Aliceは普通は、自分のトランザクション104を公開するビットコインノードに対する料金を含める必要がある。Aliceがそのような料金を含めない場合、Tx₀はブロックチェーンノード104によって拒絶されてもよく、したがって、技術的には有効であっても、広められず、ブロックチェーン150に含められなくてもよい(ノードプロトコルは、ブロックチェーンノード104がトランザクション152を受け入れることを望まない場合、それを強いることはない)。一部のプロトコルでは、トランザクションフィーは、固有の別々の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総額と所与のトランザクション152の出力203において指定される総額とのあらゆる差が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO₀へのポインタがTx₁への唯一の入力であり、Tx₁が唯一の出力UTXO₁を有するとする。UTXO₀において指定されるデジタル資産の額がUTXO₁において指定される額より大きい場合、その差は、UTXO₁を含むブロックを公開するノード104によって割り当てられ得る。しかしながら、代替または追加として、トランザクションフィーが、トランザクション152のUTXO203のうちの自身固有のUTXOにおいて明示的に指定され得ることは、必ずしも排除されない。

【0060】

AliceおよびBobのデジタル資産は、ブロックチェーン150のどこかにある任意のトランザクション152において彼らにロックされるUTXOからなる。したがって、通常は、所与の関係者103の資産は、ブロックチェーン150全体の、様々なトランザクション152のUTXO全体に分散している。所与の関係者103の総残高を定義する1つの数字が、ブロックチェーン150のどこかに保管されているということはない。それぞれの関係者にロックされており、別のその先のトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を一緒に照合することが、クライアントアプリケーション150のウォレット機能の役割である。そのウォレット機能は、ビットコインノード104のいずれかに記憶されたようなブロックチェーン150のコピーをクエリすることによって、これを行うことができる。

【0061】

スクリプトコードはしばしば、概略的(すなわち、厳密な言語を使用せずに)に表現されることに留意されたい。たとえば、特定の関数を表すためにオペレーションコード(オペコード)を使用することがある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロッキングスクリプトの最初おいてOP_FALSEが前にあるとトランザクション内のデータを記憶できるトランザクションの消費不可能な出力を生み出し、それによりブロックチェーン150にデータをイミュータブルに記録するような、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

図3Bは、Aliceの機器102a上のクライアントアプリケーション105aのUI層352によってレンダリングされ得るユーザインターフェース(UI)360の例のモックアップを与える。同様のUIが、Bobの機器102bクライアント105b、または任意の他の関係者の機器のクライアントによってレンダリングされ得ることが理解されるだろう。

【0070】

例示として、図3BはAliceの視点からのUI360を示す。UI360は、ユーザ出力手段を介して別個のUI要素としてレンダリングされる1つまたは複数のUI要素362、362、363を備え得る。

【0071】

たとえば、UI要素は、1つまたは複数のユーザ選択可能要素362を備えてもよく、これは、様々なオンスクリーンボタン、またはメニューの中の様々なオプションなどであってもよい。ユーザ入力手段は、ユーザ103(この場合はAlice 103a)が、画面上のUI要素をクリックもしくはタッチすること、または望ましいオプションの名前を話すことなどによって、オプションのうちの1つを選択し、または別様に操作することを可能にするようになされる(本明細書において使用される「手動の」という用語は、自動であることと対比させることのみを意図しており、手を使用することに必ずしも限定しない)。

【0072】

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

【0073】

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

【0074】

様々なUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段は、有形ではないことが理解されるだろう。これらのUI要素の機能は、まもなくより詳しく論じられる。図3に示されるUI360は、概略的なモックアップにすぎず、実際には、それは1つまたは複数のさらなるUI要素を備えてもよく、これは簡潔にするために示されていないことも理解されるだろう。

【0075】

ノードソフトウェア
図4は、UTXOベースまたは出力ベースのモデルの例では、ネットワーク106の各ブロックチェーンノード104で実行されるノードソフトウェア450の例を示す。別のエンティティは、ネットワーク106のノード104として分類されることなく、すなわち、ノード104に必要とされる活動を実行することなく、ノードソフトウェア450を実行し得ることに留意されたい。ノードソフトウェア450は、限定はされないが、プロトコルエンジン451、スクリプトエンジン452、スタック453、アプリケーションレベル決定エンジン454、および1つまたは複数のブロックチェーン関連機能モジュール455のセットを含み得る。各ノード104は、コンセンサスモジュール455C(たとえば、プルーフオブワーク)、伝播モジュール455P、および記憶モジュール455S(たとえば、データベース)の3つすべてを含むがそれらに限定されない、ノードソフトウェアを実行し得る。プロトコルエンジン351は通常、トランザクション152の様々なフィールドを認識し、ノードプロトコルに従ってそれらを処理するように構成される。別の先行するトランザクション152i(Tx_m-1)の出力(たとえば、UTXO)を指し示す入力を有するトランザクション152j(Tx_j)が受信されるとき、プロトコルエンジン451は、Tx_jにおいてアンロッキングスクリプトを特定し、それをスクリプトエンジン452に渡す。プロトコルエンジン451はまた、Tx_jの入力の中のポインタに基づいて、Tx_iを特定して取り出す。Tx_iはブロックチェーン150上で公開されてもよく、この場合、プロトコルエンジンは、ノード104に記憶されたブロックチェーン150のブロック151のコピーからTx_iを取り出し得る。代替として、Tx_iはまだブロックチェーン150上で公開されていないことがある。その場合、プロトコルエンジン451は、ノード104によって維持される公開されていないトランザクションの順序付けられたセット154からTx_iを取り出し得る。いずれにしても、スクリプトエンジン451は、Tx_iの参照された出力においてロッキングスクリプトを特定し、これをスクリプトエンジン452に渡す。

【0076】

したがって、スクリプトエンジン452は、Tx_iのロッキングスクリプトおよびTx_jの対応する入力からのアンロッキングスクリプトを有する。たとえば、Tx₀およびTx₁とラベリングされたトランザクションが図2に示されているが、同じことがトランザクションの任意のペアに当てはまり得る。スクリプトエンジン452は、前に論じられたように2つのスクリプトを一緒に実行し、これは、使用されているスタックベースのスクリプト言語(たとえば、Script)に従って、データをスタック453に置き、スタック453からデータを取り出すことを含む。

【0077】

スクリプトを一緒に実行することによって、スクリプトエンジン452は、ロッキングスクリプトにおいて定義される1つまたは複数の基準をアンロッキングスクリプトが満たすかどうか、すなわち、ロッキングスクリプトが含まれる出力をアンロッキングスクリプトが「アンロック」するかどうかを決定する。スクリプトエンジン452は、この決定の結果をプロトコルエンジン451に返す。アンロッキングスクリプトが対応するロッキングスクリプトにおいて指定される1つまたは複数の基準を満たすとスクリプトエンジン452が決定する場合、それは「真」という結果を返す。それ以外の場合、それは「偽」という結果を返す。

【0078】

出力ベースのモデルにおいて、スクリプトエンジン452からの「真」という結果は、トランザクションが有効であるための条件の1つである。通常、やはり満たされなければならないプロトコルエンジン451により評価される1つまたは複数のさらなるプロトコルレベル条件もある。それは、Tx_jの出力において指定されるデジタル資産の総額が入力によって指し示される総額を超えないこと、およびTx_iの指し示される出力が別の有効なトランザクションによってまだ消費されていないことなどである。プロトコルエンジン451は、スクリプトエンジン452からの結果を1つまたは複数のプロトコルレベル条件と一緒に評価して、それらがすべて真である場合にのみ、トランザクションTx_jを妥当性確認する。プロトコルエンジン451は、トランザクションが有効であるかどうかの標示を、アプリケーションレベル決定エンジン454に出力する。Tx_jが実際に妥当性確認されるという条件のもとで、決定エンジン454は、Tx_jに関してそれぞれのブロックチェーン関連機能を実行するようにコンセンサスモジュール455Cと伝播モジュール455Pの両方を制御することを選び得る。これは、コンセンサスモジュール455Cが、ブロック151に組み込むためにTx_jをトランザクションのノードのそれぞれの順序付けられたセット154に追加することと、伝播モジュール455Pが、Tx_jをネットワーク106の中の別のブロックチェーンノード104に転送することとを備える。オプションで、実施形態では、アプリケーションレベル決定エンジン454は、これらの機能のいずれかまたは両方を起動する前に、1つまたは複数の追加の条件を適用し得る。たとえば、決定エンジンは、トランザクションが有効でありかつ十分なトランザクションフィーを残すという条件のもとでのみ、トランザクションを公開することを選び得る。

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

イベントストリームのブロックチェーン記憶
本開示の第1の態様は全般に、ブロックチェーンに関連する複数のサービスを提供するプラットフォームの一部として、イベントストリームのブロックチェーン記憶を提供することに関する。プラットフォームは、方法を行い、複数のクライアントのために提供され、アプリケーションプログラミングインターフェス(API)に関連する少なくとも1つのプラットフォームプロセッサによって実装される。

【0086】

方法は、ストリーム作成メッセージを受信するステップであって、ストリーム作成メッセージがトリガのための条件の標示を備えるステップと、トリガ条件が満たされたことに基づいて、ストリームの状態を示すデータを取得するステップ、およびストリームの状態を示すデータを備える付加トランザクションを生成するステップを行うステップとを備える。

【0087】

方法は、好ましくは、付加トランザクションを生成した後で、ブロックチェーンにブロードキャストされるように付加トランザクションを整えるステップが行われることを備える。

【0088】

有利には、現在のストリーム状態を表すトランザクションの生成(およびその後の提出)のためのトリガを提供することによって、ストリームのブロックチェーン表現がどれだけ新しい必要があるかについてのより大きな柔軟性と選択可能性が達成される。クライアントは、イベントストリームを作成すると、要件に応じてトリガの態様を選択することができる。

【0089】

いくつかの実施形態では、方法はさらに、トリガ条件の再発生を監視するステップを備える。

【0090】

より長期間のイベントストリームでは、トリガ条件は複数回発生することがある。追加のトリガ条件がいつ満たされるかを監視することによって、オンチェーンデータセットが必要なときに更新される。

【0091】

いくつかの実施形態では、方法はさらに、トリガのための条件の標示に基づくデータを少なくとも備える初期トランザクションを生成する(およびオプションでブロードキャストする)ステップを備える。いくつかの実施形態では、トリガのための条件の標示に基づくデータは、初期トランザクションの出力に記憶される。いくつかの実施形態では、付加トランザクションは、初期トランザクションまたは前の付加トランザクションの出力を消費する入力を備える。好ましくは、トリガのための条件の標示に基づくデータが、トリガのための条件の標示である。

【0092】

有利には、初期トランザクションまたは付加トランザクションの中の先行する付加トランザクションの出力を消費することによって、各イベントが発生する順序がブロックチェーン上で保存される。あるトランザクションが、まだブロックの一部ではない、または少なくとも同じブロックの一部ではないトランザクションに由来する場合、そのトランザクションをブロックチェーンに含めることはできない。順序の保存は、関係者がイベントストリームの現在の状態を知ることに関心がある場合、終わりまで消費チェーンを調査するだけでよいという点で有利である。未消費の出力を伴うトランザクションが最後のトランザクションであるかどうかを決定するためにさらなる確認は必要とされないため、計算リソースを節約することができる。

【0093】

そのような消費関係のさらなる利点は、「オンチェーンデータセットの調査」という見出しのもとで以下で論じられるような、オンチェーンデータセットの調査可能性である。

【0094】

いくつかの実施形態では、ストリームの状態を示すデータは、付加トランザクションの出力に記憶される。好ましくは、OP_RETURNオペコードが使用される。より好ましくは、データはOP_RETURNオペコードの後に記憶される。

【0095】

有利には、ブロックチェーントランザクションの既存の特徴を別の目的で利用すること(トランザクションの出力の上述の使用およびOP_RETURNオペコードの使用など)は、マイナーまたはブロックチェーンに関連する他のブロックチェーン処理デバイスが、すでに備えているものを超えるどのような技術的能力も必要としないことを意味する。

【0096】

いくつかの実施形態では、トリガ条件は、ストリームが完成したことを示すメッセージの受信、経過時間、経過時間と閾値時間の比較、および/または受信されたイベントの数とイベントの閾値の数との比較のうちの任意の1つまたは複数に基づく。

【0097】

有利には、異なるトリガシステムが、異なるクライアントの需要のために提供され、クライアントによって選択され得る。

【0098】

いくつかの実施形態では、経過時間は、先行するトリガ条件が満たされてからの時間、および/または作成メッセージが受信されてからの時間に基づく。いくつかの実施形態では、作成メッセージはさらに閾値時間を備える。

【0099】

好ましくは上述の特徴を使用して、ブロックチェーンへのトランザクションの提出をイベントストリームの更新から分離することは、以下を含むいくつかの利点をもたらす。
発生したイベントの厳密な数を隠すこと。たとえば、ストリームが50イベントごとにオンチェーンで更新されることが知られている場合、第三者は、あらゆるオンチェーン付加トランザクションを数え、そのカウントを50と乗じるだけで、イベントの総数の概観を得る。関連するスマートコントラクトによっては、これは第三者に機密情報を漏洩することがある。および、
イベントストリームが自身のオンチェーン提出を追跡している場合に、イベントストリームに出されるあらゆるイベントが、別のイベントの作成を、したがって別のイベントトランザクションをトリガし、以下同様となるような、あらゆるループの発生を防ぐこと。

【0100】

いくつかの実施形態では、受信されるイベントの数は、先行するトリガ条件が満たされてから受信されたイベントの数および/または作成メッセージが受信されてから受信されたイベントの数に基づく。いくつかの実施形態では、作成メッセージはイベントの閾値の数を備える。いくつかの実施形態では、イベントの閾値の数は1である。いくつかの実施形態では、イベントの閾値の数は1より大きい。

【0101】

いくつかの実施形態では、トリガ条件は、経過時間と閾値時間の比較だけに基づく。いくつかの実施形態では、トリガ条件は、受信されたイベントの数とイベントの閾値の数との比較だけに基づく。

【0102】

いくつかの実施形態では、ストリームの状態は、ストリームの最新のイベントの原像のハッシュを備える。いくつかの実施形態では、ストリームの状態は、ストリームの最新のイベントの原像を備える。いくつかの実施形態では、ストリームの状態は、ストリームの最新のイベントのデータを示すデータを備える。いくつかの実施形態では、ストリームの最新のイベントのデータを示すデータは、ストリームの最新のイベントのデータのハッシュを備える。いくつかの実施形態では、ストリームの最新のイベントのデータを示すデータは、ストリームの最新のイベントのデータである。好ましくは、原像はストリームの最新のイベントのメタデータを備える。

【0103】

これらの技術的な特徴の利点は、全体的に、しかし特に、「ストリームの現在の状態」という見出しのもとで与えられる。

【0104】

いくつかの実施形態では、ストリーム作成メッセージは、ストリームの状態を示すデータのフォーマットの標示を備える。

【0105】

有利には、ストリーム状態データのフォーマットの標示を、ブロックチェーン自体に毎回記録される通りに提供することによって、ブロックチェーンに記憶された通りにデータを妥当性確認し、監査し、または読み取ることを望む第三者は、オンチェーンデータセットの残りを適切に読み取るために、初期トランザクションを見つけるだけでよい。ブロックチェーンに存在するものを超える、さらなる情報の復号、または他の関係者、データストア、もしくはデバイスとの通信は不要である。

【0106】

いくつかの実施形態では、方法はさらに、付加トランザクションのメタデータを用いてオフチェーンデータベースを更新するステップを備える。いくつかの実施形態では、メタデータは、ブロックチェーン上のトランザクションを特定するため、ブロックチェーン上のブロックにおけるトランザクションの存在を検証するため、またはブロックチェーンにトランザクションが含まれることの証明を構築するために使用される。

【0107】

好ましくは、メタデータは、付加トランザクションのトランザクションid、付加トランザクションへの入力のサブセット、付加トランザクションが含まれるブロックのブロックヘッダ、付加トランザクションが含まれるブロックのブロックid、付加トランザクションに関連するタイムスタンプ、および付加トランザクションのトランザクションidのための兄弟ハッシュのアレイの任意の1つまたは複数を備える。より好ましくは、メタデータは、付加トランザクションのトランザクションid、付加トランザクションが含まれるブロックのブロックヘッダ、およびトランザクションidのための兄弟ハッシュのアレイを備える。

【0108】

いくつかの実施形態では、方法はさらに、イベントをストリームに追加せよとの要求を受信するステップであって、要求がイベントデータおよびオーバーライドフラグを備える、ステップと、イベントデータを示すデータを備えるさらなる付加トランザクションを生成するステップと、ブロックチェーンにブロードキャストされるように付加トランザクションを整えるステップとを備える。

【0109】

有利には、ブロックチェーンに存在の証明を記憶することは、セキュリティを高め、データがオンチェーンデータセットの中にあるべきであるときにデータが存在することを検証するためのより簡単な手段を監査者に提供する。

【0110】

第1の態様によれば、デバイスはプロセッサおよびメモリを備え、メモリは、プロセッサの実行の結果として、上で説明されたコンピュータで実施される方法をデバイスに実行させる実行可能命令を含む。

【0111】

また第1の態様によれば、システムは、上で説明された上記のデバイスによるプラットフォームプロセッサと、プラットフォームプロセッサにイベントデータを出すように構成されるクライアントデバイスとを備える。

【0112】

有利には、第1の態様において上で説明されたような方法、デバイス、およびシステムは、クライアントが、どれだけの情報を、情報をどれだけ頻繁に、およびどの情報をブロックチェーンに記憶することを望むかを選択することを可能にする。各々の異なる方法および記憶のデータタイプの利益と利点が、以下で説明される。

【0113】

図5は、イベントデータがデータベースに記憶されること、およびイベントデータを示すデータがブロックチェーンに記憶されることを可能にするための、本開示の第1の態様によるシステム500に関する。オプションで、表現は、イベントデータ自体、イベントデータのダイジェスト、および/またはイベントデータへの参照である。本実施形態におけるイベントデータは、イベントストリームに関する。

【0114】

イベントストリームは、順番に実行されるイベントの厳密なシーケンスのログを提供し、ブロックチェーン上で少なくとも部分的に実装される。いくつかの実施形態では、イベントストリームは、ブロックチェーンを使用して、および/またはオフチェーンデータベースにおいて実装される。イベントストリームは、決定性有限オートマトン(DFA)などの有限ステートマシン(FSM)を表現または追跡してもよく、これは、よく知られているコンピューティング用語であり、有限の数の状態を有するシステムを表し、所与の時間において1つだけの状態にあってもよく、ある段階から次の段階に遷移するための遷移関数またはトリガイベントを伴う。いくつかの実施形態では、そのようなイベントストリームは、技術的なプロセスのための制御手段または技法を表すのに有用である。

【0115】

本態様に関連する開示は、FSMであってもよいスマートコントラクトを、前記イベントストリームの使用法として提供する。すぐ下で論じられるように、これは例として与えられ、他のものが当業者に明らかであろう。

【0116】

イベントストリームは、ブロックチェーン上の機械可読契約またはスマートコントラクトを表し、有利には、スマートコントラクトの過去と現在の入力のイミュータブルな記録がブロックチェーンに書き込まれる。これらの入力がリプレイされるとき、それはスマートコントラクトの決定性状態をもたらす。したがって、イベントストリームはスマートコントラクトと関連付けられ、かつ/またはその逆である。イベントストリームは、順番通りのデータロガー、オフチェーンのためのトラッカー、現実世界、状態の固定されたセットを有するプロセス、または現実世界のオフチェーンプロセスに提供される入力のシーケンス(オプションで前記入力の結果を伴う)とも関連付けられてもよい。スマートコントラクト以外の他のシステムも、イミュータブルなFSMまたはDFAを有利に使用してもよいことを当業者は理解するだろう。

【0117】

システム500は、サービスのためのAPIに関連するプラットフォームプロセッサ504と対話するように構成されるクライアント502を備える。プラットフォームプロセッサ504は、例示を簡単にするためにモノリシックサーバとして本明細書で説明される。それは、単一のサーバ、メインフレーム、サーバの集合体、マイクロサービス、マイクロサービスの集合体、クラウドサービス、先行するおよび/または他のコンピューティングプラットフォームの任意の組合せとして実装されてもよいことを、当業者は理解するだろう。

【0118】

クライアント502は、プラットフォームプロセッサのAPIを介してプラットフォームプロセッサ504と通信する(510)。この態様のこの例では、クライアント502は、イベントストリームを少なくとも作成し、更新し、完成させるように構成される。nChain Holdings Ltdにより2020年9月4日に出願された英国特許出願第2013929.1号は、イベントストリームを使用してスマートコントラクトおよび/または任意の他の適用例を管理するために使用されてもよい、プラットフォームプロセッサの説明のための例を提供する。

【0119】

プラットフォームプロセッサ504は、任意の所与の時間にそれぞれのイベントストリームに記録されるような、スマートコントラクトの現在の状態を記憶し、更新し、提供し、および/または示すように構成される、スナップショットインスタンスデータベース506と関連付けられる。複数のクライアントのうちのある所与のクライアントに関連するスマートコントラクトごとに、1つのイベントストリームしかない。いくつかの実施形態では、複数のクライアントの各クライアントは、それぞれのクライアントに関連する特定のスマートコントラクトを特定するために使用されてもよいアカウントまたは識別子と関連付けられてもよい。プラットフォームプロセッサ504は、各イベントストリームに関連する記録イベントデータを少なくとも記憶し、それにアクセスし、それを更新できるように、データベース506と通信する(512)ように構成される。

【0120】

プラットフォームプロセッサ504は、イベントストリームの表現をブロックチェーンへと記憶するように構成される。したがって、プラットフォームプロセッサ504は、ブロックチェーンネットワーク101と通信する(514)ように構成される。その例が図1を参照して上で説明されているブロックチェーンネットワーク101は、トランザクションの関連するイベントデータ(または前記イベントデータを表すデータ)をブロックチェーンに記憶する。例示的なトランザクションは、図2を参照して上で説明される。

【0121】

プラットフォームプロセッサ504は、データをブロックチェーンネットワーク101に出すことと、データをブロックチェーンネットワーク101から読み取ることの両方を行うように構成される。オプションで、プラットフォームプロセッサ504は、ブロックチェーンデータについてネットワークノードに尋ねる必要がないように、ブロックチェーンの自身固有のコピー(オプションで枝刈りされた)を維持する。

【0122】

図6Aを参照すると、オンチェーンデータセットにおいてオフチェーンデータセットの表現を維持する方法600が示されている。データセットはイベントのセットであり、イベントの各々のソースは、それを作成するクライアント、および/またはクライアントによって権限が委任されている任意の関係者である。

【0123】

この態様および図6Aを参照して例として使用されるデータセットは、好ましくは、オフチェーンデータベースまたは他のデータストア手段に完全に記憶される。好ましい実施形態では、ブロックチェーンに記憶されるイベントのサブセットを示すデータ。ブロックチェーンに記憶される各トランザクションは好ましくはストリームの状態を表し、より好ましくは、ストリームの状態は最新のイベントを指す。

【0124】

この方法は、好ましくはプラットフォームプロセッサ504によって実行され、クライアントが新しいイベントストリームを作成することを望むたびに実行される。好ましくは、方法は、イベントストリームがアクティブである限り機能する。クライアント502はオプションで、イベントストリームをいつ完成させて閉じるかについての標示をプラットフォームプロセッサ504に与える。

【0125】

まず、イベントストリームを作成せよとのメッセージが受信されると、イベントストリームが作成される(602)。このメッセージはオプションで、API要求の形式であり、クライアント502に由来する。作成メッセージは、いつデータがブロックチェーンに記憶されるべきであるか、およびデータのどのフォーマットが記憶されるべきかの条件の標示を備える。これらの条件は、ある点においてトリガするので、「トリガのための条件」または「トリガ条件」であるとも考えられ得る。

【0126】

オプションで、初期トランザクションが作成され、この時点でブロックチェーンに出される。初期トランザクション660は、好ましくは図7Cを参照して説明されるような形式である。トリガのための条件および記憶されるべきデータのタイプは、初期トランザクションに記憶される。

【0127】

ストリームの作成またはストリーム作成メッセージの受信により、トリガ条件が満たされるとき(604)、トランザクションがブロックチェーンに追加される。オプションで、トリガ条件が満たされるまで方法は待機する。この文脈における「待機する」は、好ましくは、満たされるべき条件をプロセスが能動的に探す必要がないように、中断システムに関する。代替または追加として、待機は、条件が満たされたかどうかを確認するために、ポーリングを使用することに関する。

【0128】

トリガ条件が満たされると、イベントストリームの現在の状態が取得される(606)。ストリームの現在の状態のフォーマットおよび内容ならびに/またはストリームの現在の状態を示すデータは、「ストリームの現在の状態」という見出しのもとで以下でさらに詳しく説明される。

【0129】

付加トランザクションが生成され(608)、それは現在のストリーム状態を示すデータを備える。付加トランザクションは、好ましくは図7Bを参照して説明されたような形式であり、ストリームの現在の状態を示すデータは、付加トランザクションのペイロード出力に記憶される。付加トランザクションはさらに、図7Aおよび図7Bを参照して論じられるような現在のイベントストリームに関するブロックチェーンに出される、前のトランザクションの出力を消費する入力を備える。したがって、生成ステップはさらに、トランザクションのチェーンの中の最新のトランザクションへの参照を取得することを備え、この参照は好ましくは先行するトランザクションのダスト出力点である。

【0130】

付加トランザクションは、ブロックチェーンへの追加のためにブロックチェーンネットワーク101にブロードキャストされるように整えられる(610)。付加トランザクションのブロードキャストをこのように整えることは好ましくは、ブロックチェーンに含めるためにデータをブロックチェーンノードに出すように構成されるさらなるスレッド、プロセス、またはデバイスに付加トランザクションを送信することを備える。この送信は、好ましくは図6Bを参照して説明されるようにメッセージバスを使用して行われる。

【0131】

生成および付加ステップはオプションで、別個のスレッド、プロセス、またはデバイスにおいて同期せずに行われる。例として、これは、図6Bを参照して説明されるようにメッセージバスを使用して行われる。

【0132】

方法は、最初に戻り、トリガ条件が再び満たされるのを待つ。オプションで、方法は追加で、完成メッセージが受信されるのを、および/または完成条件が満たされるのを待つ。完成条件はオプションで、トリガ条件と同様に作成メッセージに含まれる。

【0133】

図6Bは、本態様の例示的なプロセス612に関する。この例示的な実施形態では、タイマに基づくトリガ条件が使用される。示される例示的なプロセス612は、プラットフォームプロセッサ504によって実行または実施されてもよい。

【0134】

図示されるようなプロセスの前に、タイマが始動すると、ステップ614においてプロセスが呼び起こされるように、タイマが確立される。次いで、現在のストリーム状態が取得される(616)。これは、データベース506から取得される。オプションで、現在のストリーム状態が処理される。

【0135】

現在のストリーム状態は、メッセージバスを介してブロックチェーンに発行される(618)。メッセージバス上の発行メッセージにより、さらなるサービスまたはプロセスがストリーム状態データを取り込み、ブロックチェーンに出す。

【0136】

オプションで、ストリーム状態を備えるトランザクションが、ブロックに含まれていると、および/またはブロックチェーン上で確認されると(確認とは通常、6つのブロックが前記トランザクションの含有の後に追加されたことを意味する)、トランザクションのメタデータおよび/またはトランザクション自体が取得される(620)。トランザクションのメタデータは、「オンチェーンメタデータを用いたオフチェーンデータセットの更新」という見出しのもとで以下でより詳しく説明される。

【0137】

トランザクションのメタデータがデータベースに記憶される(622)。オプションで、ストリーム状態がイベントストリームの最新のイベントである場合、イベントデータベースエントリは、トランザクションメタデータで更新され、および/またはイベントデータベースエントリは、ブロックチェーンに出されたおよび/またはブロックチェーン上で確認されたとタグ付けされる。

【0138】

トリガ条件が再び満たされるときに最新のイベントがすでにブロックチェーンに出されている場合、同じ最新のイベントがブロックチェーンに再び出される。

【0139】

代替として、トリガ条件が満たされ、新しいイベントデータが存在せず、現在の最新のイベントがすでにブロックチェーン上にあるものとタグ付けされている場合に、新しいトランザクションが作成されず、プロセスがさらなるトリガを待つように、データベースにおけるタグおよび/またはトランザクションデータの存在が使用される。

【0140】

ダストのチェーン
図7Aを参照すると、トランザクション638の例示的なチェーン(「ダストのチェーン」としても知られている)が示される。トランザクションのチェーンは、互いに関連するいくつかのトランザクション660、640、640a、640b、662を備える。第1のトランザクション660は、初期トランザクションであり、チェーンについてのメタデータを備える。チェーンは、いくつかの付加トランザクション640、640a、640bも備え、好ましくは、それらはオフチェーンデータベースに記憶されたイベントデータを示すデータを備える。付加トランザクション640、640a、640b、および最後のトランザクション662は、それらに先行するトランザクションからの出力に関連する入力も備えるので、消費関係を確立する(図7Aにおいて矢印として表されている)。この入力は出力点の形式であり、出力点はトランザクションidおよび出力のインデックスである。この入力は、前のトランザクションからのトランザクション出力を消費する。例として、ビットコインプロトコルに関して、上記の「UTXOベースのモデル」という見出しのもとで説明されたように、かつ図2を参照すると、出力は未消費トランザクション出力(UTXO)であり、入力はUTXOへの参照を備える。したがって、各トランザクション(最初を除く)は、消費関係を介したダストのチェーンにおける前のトランザクションへの後方参照を備える。初期トランザクションは、図7Cを参照して以下で説明されるように、資金提供UTXOへの後方参照を備える入力を備える。この資金提供UTXOは、ダストのチェーンの一部であるとみなされないが、それはダストのチェーンに関するデータまたはメタデータを記憶しないからである。

【0141】

ダストのチェーンは、ビットコインの入力および出力の壊れていないチェーンであり、これはここでは、シーケンスの中の各ブロックチェーントランザクションの、その直前のトランザクションに対する消費依存性を課すために使用される。本開示のブロックチェーントランザクションの文脈における「ダスト」は、低いまたは非常に小さい値の出力を有するデジタル資産または暗号通貨のための消費可能なトランザクションであるものと理解され、すなわち、その値はブロックチェーンにおける出力をマイニングするためのフィーよりはるかに少ないことがある。

【0142】

トランザクションにおいてダスト出力を使用することは、トランザクションが、Event Streamなどの順序付けられた追加専用のデータストレージシステムについて発生するにつれて、すべてのトランザクションのイミュータブルで逐次的な記録を維持するために有利かつ重要である。その理由は、トランザクションをブロックチェーンに投稿することによって、すべてのブロックチェーントランザクションはタイムスタンプを押され、ブロックチェーン上で確認されるとまたはブロックチェーンに追加されると特定の順序にとどまるが、これは、それらの逐次的な順序の保存を保証しないからである。これは、トランザクションが異なる時間にブロックへとマイニングされることがあるから、および/または同じブロック内であってもトランザクションの順序が異なっているからである。シーケンスの中の次のトランザクションの最初の入力によって消費されるダスト出力を使用することで、有利には、トランザクションの順序が経時的に追跡され、イベント自体とイベントの逐次的な順序の両方の耐改竄性のある記録が作成されることが確実になる。これは、ブロックへとマイニングされると、シーケンスの中の前のトランザクションから次のトランザクションへのダストの支払いが、ビットコインプロトコルルールに従って、ペイロードと呼ばれ以下で論じられるような埋め込まれたデータ搬送要素のシーケンスを並べ替えることができずそして挿入または削除が起こり得ないことを確実にするからであり、そのような並べ替え、挿入または削除は、イベントストリームが危険にさらされていることが即座に明白になることなくシーケンスを変更する可能性がある。いくつかの実施形態では、ビットコインプロトコルに内在する二重消費防止機構が、異なるトランザクション入力と出力との間での暗号通貨(たとえば、ダスト)の移動がトポロジカルな順序にとどまることを確実にする。ダストトランザクションのチェーン形成は、トポロジカルな順序付けを利用して、ブロック間およびブロック内のトランザクション(およびしたがって関連するイベントおよびデータ)の順序の保存をもたらす。したがって、これは、順序付けられた追加専用のデータアイテムストレージの完全性を高める。さらに、ダストは、マイナーが処理する意思のある最小の出力である。悪意のある第三者が所与のユーザための秘密鍵を保有していた場合、その第三者はダストチェーンをフォークすることは可能ではない。これは、ダスト出力(たとえば、各出力に対して273 satoshis)を分割しようとするあらゆる試みがマイナーにより無視されるからである。

【0143】

こうして、ブロックチェーントランザクション638は、トランザクションの有向グラフを形成する。グラフの方向は、エッジにより示されるように、シーケンスの中の前のトランザクションから次のトランザクションに向かう、一方向であるものとみなされ得ることに留意されたい(図7Aにおいて矢印として示される、特に矢印は参照が指している方向を示し、すなわちTx_n+1はTx_nの出力点を備える入力を備える。これは、時間およびデータがどのように前に進んでいるかについて反対の方向である)。このグラフは、トランザクション間の消費関係によって作成される。これらの消費関係は、あるタイプの参照であるものとしてみなされ得る。

【0144】

図7Bおよび図7Cを参照すると、データ追加トランザクション640a、640b、最初のトランザクション660、および最後のトランザクション662の例示的なブロックチェーントランザクションフォーマットが示されている。これらはブロックチェーントランザクションであるので、それらは図2を参照して説明されるトランザクション152i、152jに構造が類似しているが、本発明のこの態様に関連する特定の構成要素を備える。入力および出力の厳密な順序は具体的ではなく、代替の順序が使用されてもよい。この順序は、好ましくは所与のチェーン上で一貫している。

【0145】

各イベントに関連するデータは、各トランザクションの一部としてペイロードに記憶される。トランザクションに「記憶」されるべきデータペイロードおよび/または他のデータ(初期トランザクションについてのトリガ条件など)が、トランザクションの消費不可能なOP_RETURN出力に保持される。これは、ブロックチェーンに任意のデータを書き込むために、かつまた、無効であるものとしてトランザクション出力をマークするために使用され得る、Scriptオペコードである。別の例として、OP_RETURNは、トランザクション内のメタデータなどのデータを記憶し、それによりブロックチェーンにメタデータをイミュータブルに記録できる、トランザクションの消費不可能な出力を作成するためのScript言語のオペコードである。

【0146】

図7Bは、2つのデータ追加トランザクション640a、640bを示す。これらの例示的なデータ追加トランザクション640a、640bは、時間的に続けて、かつダストのチェーンにおいて到来する。第1のトランザクション640aのダスト出力644aは、第2のトランザクション640bのダスト入力646bにおいて参照される(すなわち、それによって消費される)。第1のトランザクション640aのダスト出力644aへの第2のトランザクション640bの参照のダスト入力646bは、第1のトランザクションのトランザクションid 648aとUTXOのインデックスの両方を備え、そのインデックスはこの例示的な場合には0である(それがリストの中で最初であり、ゼロインデクシングが使用されるので)。

【0147】

トランザクション640a、640b、660、662のすべてが、資金提供入力648a、648b、648c、648dを備える。これらの資金提供入力648a、648b、648c、648dは、コンピューティングデバイスがこれらのトランザクションを管理し、作成し、ブロックチェーンに出すことによって提供される。資金提供入力の全体の値は、マイナーが確実にトランザクションを選んでそれをブロックに含めるのを助けるために、トランザクションフィー(マイナーの料金と呼ばれることがある)を含むように選択される。資金提供サービスは、全体の値が入力であるが十分であることを確実にするために、1つまたは複数の入力を提供し得る。トランザクションフィーは可変であり、ネットワークの負荷に依存する。トランザクションフィーは、バイト毎サトシ(またはブロックチェーンシステムが使用する任意のコイン/トークン)を単位とし得る(サトシは1ビットコインの1億分の1である)。したがって、ペイロードが大きい場合、料金も大きくなければならず、資金提供入力はそれに従って調整される。UTXOモデルの結果として、支払われる全体の料金は、入力において参照されるUTXOと、出力のUTXOの両方の値によって左右される。オプションで、トランザクションフィーを含めることによる残高が、残金出力650a、b、c、dを介して、これらのトランザクションを管理し、作成し、ブロックチェーンに出す同じコンピューティングデバイスへ、戻される。資金提供入力および前記資金提供入力に起因する残金は、浮動残高として機能し、前記資金提供サービスによって管理される。

【0148】

最初のトランザクション660および最後のトランザクション662はまた、ストリームメタデータ664、666を備える。最初のストリームメタデータは、ダストのチェーンの維持に関連する値を備える。最後のトランザクション662のメタデータ666は、このトランザクションがチェーンにおいて最後であることを示すための情報を備える。好ましくは、最後のトランザクションのメタデータ666は、最初のトランザクション660のトランザクションid 648cも備える。

【0149】

データ追加トランザクション640aと640bの両方がそれぞれ、ペイロード642a、642bを備える。本態様のいくつかの実施形態では、n+1トランザクション640bのペイロード642bは、先行するnトランザクション642aのペイロード642aへの参照を備える。

【0150】

ストリームの現在の状態
図6Aを参照して上で論じられたように、ストリームの現在の状態および/またはストリームの現在の状態を示すデータが、付加トランザクションの出力に記憶される。好ましくは、ストリームの現在の状態は、イベントストリームにおける最新のイベントを用いて表される。一実施形態では、最新のイベントを示すデータは、以下のペイロードの形式である。これは説明のための例として提供され、修正を備えるいくつかの実施形態が以下で論じられる。
Payload_n=[preimage_n][streamDigest_n][...]
ここで、小文字nは現在のトランザクションを表すために使用され、n-1は先行するトランザクションである。好ましくは、ペイロードは以下の形式でトランザクションの出力のスクリプトに記憶される。
OP_FALSE OP_RETURN OP_PUSHDATA1 <preimage> 0x20 <streamDigest> [0x20 <data digest> | OP_PUSHDATAN <data>]

【0151】

原像は、現在のトランザクション、イベント、またはイベントストリーム状態、および以前のトランザクション、イベント、またはイベントストリームの状態のメタデータを備える。例示を目的に、イベントストリームの状態が以下で使用される。先行するトランザクション、以前に受信されたイベント、またはイベントストリームの以前の状態が使用されてもよく、オプションでそれらはすべて同じものであってもよいことを、当業者は理解するだろう。

【0152】

「ストリームの前の状態」または「ストリームの先行する状態」が使用されるが、これは、オフチェーンデータセットに記録されるようなイベントストリーム状態を指す。オプションで、これはまた、ストリーム状態へのすべてのイベント/更新がオンチェーンで記録される場合、オンチェーンデータセットと同じであってもよい。

【0153】

原像はオプションで、以下のフィールドのうちのいずれか1つまたは複数を備える。
・txidcreate:チェーンの最初のトランザクションへの参照、好ましくはチェーンの最初のトランザクションのトランザクションid、
・index:データまたはイベントのインデックス、
・whenRecorded:トランザクションおよび/またはデータアイテムの作成に関連する時間、
・dataDigest_n:オフチェーンで記憶された(およびオプションでペイロードのイベントデータ表現([...])でトランザクションに記憶された)ようなイベントデータのハッシュ、および
・streamDigest_n-1:イベントストリームの先行する状態の原像のハッシュ(イベントストリームの先行する状態のストリームダイジェスト、またはストリームダイジェスト参照とも記述される)または最初のトランザクションのシード(最初のトランザクションがstreamDigestを備えないのでトランザクションがチェーンの2番目のトランザクションである場合)。

【0154】

ストリームダイジェスト(streamDigest)は原像(preimage)のハッシュである。

【0155】

オプションで、streamDigestはまた、ソルト化される。固有の値であるソルトは、イベントストリームに関連する各トランザクションに対してランダムに生成されてもよい。ソルトはオプションで、オフチェーンで記憶される。データをソルト化することは、何も明らかにせず、ブレーンウォレット攻撃などの総当たり原像攻撃を防ぐという利点をもたらす。

【0156】

ソルト化されたハッシュのさらなる例示的な特徴と使用法が、nChain Holdings Limited名義で2021年2月17日に出願された英国特許出願第2102217.3号の明細書全体で論じられる。

【0157】

ペイロードのイベントデータ表現セクション([...])はオプションで、ブロックチェーンに記憶されるべきデータアイテムを備える。データアイテムは、
・ブロックチェーンに記憶されるべきデータ自体、
・データのハッシュ、
・ブロックチェーンに記憶されるべきデータのサブセクション、または
・何もないおよび/または空
のうちの1つであってもよい。

【0158】

特に、preimageは、イベントデータのハッシュ(dataDigest)とイベントストリームの先行する状態のstreamDigestの両方を備える。こうして、ハッシュのチェーンは、イベントストリームの中の先行するイベント(前のイベントだけではなく、トランザクション作成を含むあらゆる先行するイベント)からのデータが何らかの方法で改変される場合、異なるpreimageが生じ、したがってstreamDigestが異なるように、構築される。異なるstreamDigestにより、次のイベントアイテムも、異なる原像を有し、したがって異なるstreamDigestを有するので、以下のstreamDigestsのすべてにおける連鎖的な変化が、より前のイベントアイテムのあらゆる改変から生じる。したがって、preimagesにおけるstreamDigestsの後方参照は、何者かが先行するイベントアイテムを改竄したかどうかを特定するための機構を提供し、それは、streamDigestsが再計算され更新される必要があるからである。

【0159】

この特徴を、ブロックチェーン上のトランザクションは確認されるとイミュータブルであるという事実と結びつけて、トランザクションが確認されてからいずれかのイベントアイテムが改変されたかどうかを特定することが可能である。本機構のさらなる利点は、完全なイベントが不要であり、イベントのstreamDigestしか必要としないことである。またさらに、前のイベントの改竄を検出するために、データセット全体を必要とはしない。ブロックチェーンに記憶されたあらゆるイベントのstreamDigestを取り込み、それをオフチェーンデータベースと比較するだけで、streamDigestを備えるトランザクションがブロックチェーン上で確認される前に、いずれかのイベントが改変されたかどうかを確認するには十分である。「イベントストリームブロックチェーン検証」という見出しのもとで、検証がさらに説明される。

【0160】

ペイロードのイベントデータ表現セクションに記憶されたデータのタイプは、イベントストリームの構成に依存する。メッセージ作成は、クライアントが選択することを望む方法およびデータ記憶タイプを備える。onFinalise、checkpoint、およびonEventという、クライアントが選択できる3つの異なる方法がある。これらの異なる方法は、データがどれだけ頻繁にブロックチェーンに出されるかを調整し、「トリガ条件」の見出しのもとでさらに論じられる。

【0161】

少なくともonEvent方法では、attest、notarise、およびpubliciseという3つの異なるデータ記憶タイプが可能である。attestは、イベントを見つけることができるように、および/またはイベントがデータベースに記憶されたデータもしくはクライアントによって記憶されたデータで検証され得るように、最小限の量のデータを提供する。好ましくは、attestはstreamDigestのみを記憶する。notariseデータ記憶タイプは、どのようなデータも記憶せず、dataDigest(すなわち、ハッシュまたはソルト化されたハッシュ)とstreamDigestの両方を記憶する。いくつかの実施形態では、preimageも存在してもよい。publiciseデータ記憶タイプは、イベントデータ自体を記憶し、データが大きい場合、2つ以上のトランザクションにまたがって記憶する。checkpoint方法は、ブロックチェーンにデータを記憶しない。好ましくは、checkpoint方法はstreamDigestを記憶する。いくつかの実施形態では、preimageも存在する。代替として、checkpoint方法は3つの異なるデータタイプも使用する。以下の表は、上記の概要を与える。

【0162】

【表1】

【0163】

トリガ条件
上で言及されたように、3つの異なる方法は、データがどれだけ頻繁にブロックチェーンに出されるかを変える。イベントストリームの中のイベント(およびイベントデータ)のすべてを備えるオフチェーンデータセット、およびサブセットを示すデータを備えるオンチェーンデータセットまたはオフチェーンデータセットの少なくともサブセットという、少なくとも2つのデータセットが作成される。

【0164】

onFinalise方法では、トランザクション作成およびトランザクション完成を除き、ブロックチェーンにトランザクションは出されない。したがって、onFinalise方法のトリガ条件は、ストリームを終了せよとのメッセージの受信である。したがって、オンチェーンデータセットは2つのアイテムしか備えない。

【0165】

イベントストリームの中のイベントが公にされるべきではない状況(短期間にしかわたらない投票システムなどにおける)では、onFinalise方法が使用されてもよい。onFinalise方法は、トランザクション作成およびトランザクション完成以外に、いずれのイベント関連のデータもブロックチェーンに記憶しない。終結すると、最後のトランザクションは、投票についてのメタデータまたは統計(総数など)を備え得る。トランザクション完成における最後のstreamDigestは、上で論じられたように、チェーン全体が改竄されていないことを検証するために使用され得る。

【0166】

onEvent方法では、オフチェーンデータベースに追加されるあらゆるイベントが、ブロックチェーン上でそれを表すデータも有する。ブロックチェーンに記憶されるデータのタイプは、上で論じられたようなデータ記憶タイプに依存する。onEventでは、トリガ条件はイベントの受信である。したがって、イベントが受信もしくは作成されるたびに、またはイベントストリームが更新されるといつでも、プラットフォームプロセッサによる、ブロックチェーンへのイベントの追加がトリガする。プラットフォームプロセッサは、データタイプ(attest、notarise、およびpublicise)を見て、ブロックチェーンに追加するのに適切なデータを生成する。このonEvent実施形態のためのオンチェーンデータセットは、オフチェーンデータセットにも存在するあらゆるアイテムを備える。しかしながら、同じデータは存在しないことがある。たとえば、attestデータタイプが使用される場合、実際のイベントデータはオンチェーンに存在せず、各イベントのstreamDigestしかない。

【0167】

イベント発生の存在および/またはイベントの実際の内容が公に重要である場合、onEvent方法が使用されてもよい。この方法の例示的な使用法は、正当入札(honest tender)プロセスである。この例示的な事例では、入札が行われたかどうか、および誰により行われたかを知るのが、公の関心事である。公開ブロックチェーンにおけるイベントの存在は、この目的を果たす。オプションで、記憶されるべきデータタイプに応じて、イベントの内容も存在してもよく、したがって入札イベントのより多くを公のものにする。入札を秘密に保つ必要がある場合、notariseおよび/またはattestデータタイプが、イベントの内容を隠すために使用され得る。

【0168】

checkpoint方法では、2つの例示的な実施形態のトリガ条件が提供される。第1は時間に基づき(図6Bの例において簡単に論じられたように)、および第2は受信されたイベントの数に基づく(あらゆるイベントではなくn個ごとのイベントであることを除き、onEvent方法と違わない)。この実施形態におけるオンチェーンデータセットは、オフチェーンデータセットにおけるアイテムの少なくともいくつか(またはオプションですべて)を備える。しかしながら、同じデータは存在しないことがある。たとえば、checkpoint方法のデータ記憶タイプは、実際のイベントデータを備えず、各イベントのstreamDigestを含む。いくつかの場合、preimageが含まれてもよい。

【0169】

データを記憶しないこと、またはデータの表現すら記憶しないことは、ブロックチェーンに出されるトランザクションのサイズを減らす。トランザクションフィーは通常、トランザクションのサイズに基づいて計算されるので、これは、本明細書全体で説明されるように、イミュータブルなブロックチェーン上でイベントストリームが少なくとも部分的に表されるという利点ももたらしながら、プラットフォームプロセッサおよび/またはクライアントの金銭を節約する。同様に、イベントの一部分だけを出すことは、トランザクション全体、ブロックチェーンに記憶されたデータ全体を減らすこと、および関与するすべての関係者の金銭を節約することについての、同様の利点をもたらす。

【0170】

上記に加えて、たとえばcheckpointまたはonFinaliseで、トランザクションのサイズの低減およびデータをブロックチェーンへより低頻度で出すことは、前記トランザクションの関連するカーボンフットプリントの低減をもたらす。より大きいトランザクションサイズでは、より大きな処理が必要になる。プルーフオブワークコンセンサス機構が使用される場合(Bitcoinおよびその派生物など)、このエネルギー節約は特に重要であり、それは、前記コンセンサス機構が計算集約的であり、したがって大量のカーボンフットプリントをもたらし得るエネルギー集約的なプロセスであるからである。

【0171】

トランザクションがブロックチェーンに出されるときに常にイベントがトリガする事例では、onEvent方法を使用すると(および/またはcheckpoint方法が閾値を0または1にするように構成されるとき、そうするとonEvent方法と同じまたは同様のデータがブロックチェーンに出されるようになる)、無限ループが発生し得る。最初のトランザクションが出されるとき(何がそれを引き起こすかにかかわらず)、onEvent機構によりさらなるトランザクションがブロックチェーンに出され、それによりさらに別のイベントがブロックチェーンに出され、これが無限に続くので、無限ループが生じる。この問題は、以下で説明されるようなトリガ機構を使用することによって回避され得る。以下で説明されるトリガ機構のいずれかを使用することによって、この問題は完全に回避される。

【0172】

方法(onEvent、checkpoint、およびonFinalise)のすべてのさらなる利点が、「イベントストリームブロックチェーン検証」という見出しのもとで以下で説明されるような検証に関して明らかにされる。

【0173】

時間に基づくトリガ条件は、ブロックチェーンイベントストリームが所与の時間間隔で更新されるような条件である。時間間隔は、クライアントによって設定され、メッセージ作成におけるパラメータである。好ましくは、時間間隔は定数であり、イベントストリームの存続期間全体で変化しない。

【0174】

時間に基づくトリガ条件はオプションで、言語レベルのタイマ、たとえばJavaのTimerおよびTimerTaskを使用して実装される。Javaの例について続けると、タイマに基づくトリガ条件が使用されるべきであることと、ブロックチェーンへのイベント提出とイベント提出の間で待機する具体的な時間も存在する(たとえば、毎分)こととの標示を備えるメッセージ作成が受信される。Timerは、イベント提出とイベント提出の間で待機する具体的な時間に従ったある期間においてトリガするように確立される。TimerTaskも、現在のイベントストリーム状態を取得し、その現在のイベントストリーム状態がブロックチェーンに出されるようにするように確立される。Timerがトリガするたびに、TimerTaskが実行される。例示的な疑似Javaコードは次のようであってもよい。
final long period = 1000L * 60L; //メッセージ作成から1分
public void updateBlockchain_timerBasedTrigger() {
TimerTask repeatedTask = new TimerTask() {
public void run() {
//ストリームの状態を示すデータを取得する
//前記データを備えるトランザクションを生成する
//トランザクションをブロックチェーンにブロードキャストする
};
}
Timer timer = new Timer("Event Stream Update");
timer.scheduleAtFixedRate(repeatedTask, new Date(), period);
}

【0175】

代替として、cronなどのオペレーティングシステムレベルスケジューラが使用される。5分ごとに実行するように設定する例示的なcrontabは次のようであり得る。
* /5 * * * * /usr/bin/java MyClass.TimerTask()

【0176】

ここで提供される2つの例以外に、タイマに基づく実行を確立するためのさらなる方法があることを、当業者は理解するだろう。これらは、タイマに基づくトリガを実施するためのあり得る方法を当業者が理解するための例として与えられるにすぎない。

【0177】

上記のタイマに基づくトリガ条件の代わりに、またはそれに加えて、受信されるイベントの数に基づくトリガ条件が使用される。イベントの所与の数がメッセージ作成において設定される(たとえば、10)。この所与の数は、ブロックチェーンへの更新をトリガするためのイベントの閾値の数であるとみなされる。イベントが受信されるたびに、以前のオンチェーンストリーム更新から(またはオンチェーンストリーム更新がまだ行われていない場合、メッセージ作成が受信されてから)受信されるイベントの総数が、イベントの閾値の数と比較される。その比較に基づいて、オンチェーンデータセットが更新される。この比較は好ましくは、受信されるイベントの数がイベントの閾値の数以上であるかどうかに基づく。例示的な疑似Javaコードは次のようであってもよい(ここで、numberOfEventsBasedTriggerは、イベントが受信されるたびに、またはイベントストリームが別様に更新されるたびに呼び出される)。
final int thresholdEventReceived = 10; //メッセージ作成から
static int numberEventsReceived = 0;
public void numberOfEventsBasedTrigger() {
Task repeatedTask = new Task() {
public void run() {
//ストリームの状態を示すデータを取得する
//前記データを備えるトランザクションを生成する
//トランザクションをブロックチェーンにブロードキャストする
};
};
numberEventsReceived += 1;
if (numberEventsReceived >= thresholdEventReceived) {
repeatedTask.run();
numberEventsReceived = 0;
}
}

【0178】

好ましくは、1つのトリガ条件のみが可能である(タイマに基づく、またはイベントの数に基づく)。代替として、両方のトリガ条件を使用することができ、そうすると、トリガ条件のいずれかが満たされるたびに、オンチェーンデータセットが更新される。

【0179】

上記の例における「ストリームの状態を示すデータを取得する」ステップは、好ましくは、最新のイベントを取得し、streamDigestを、およびいくつかの実施形態では、最新のイベントストリームのpreimageも、抽出または生成することである。「前記データを備えるトランザクションを生成する」および「トランザクションをブロードキャストする」ステップは、好ましくは、上記の方法と同期せずに、かつ異なるスレッド、プロセス、またはデバイスにおいて、プラットフォームサービスがトランザクションをブロックチェーンに出すためのメッセージをメッセージバスに送信することを備える。これらのステップは実質的に、図6Aを参照して説明されるような方法のステップと同じであり、または似ており、前記方法の例として提供される。

【0180】

オプションで、checkpoint方法がデータフォーマットオプション(attest、notarise、およびpublicise)も備える場合、データは適切なスキームに従ってフォーマットされる。

【0181】

オンチェーンメタデータを用いたオフチェーンデータセットの更新
トランザクションがブロックチェーン上でブロードキャストされ、および/またはブロックチェーン上で確認されると、オプションで、オフチェーンデータベースがトランザクションのメタデータを用いて更新される。こうして、データベースへのアクセスが検証されたユーザは、ブロックチェーン上で表されるようなデータセットをより簡単に見つけることができる。これは、検証の目的に有用であることがある。

【0182】

オプションで、メタデータは、ブロックチェーン上のブロックにおけるトランザクションの存在を検証するために使用される。オプションで、メタデータは、ブロックチェーンにトランザクションが含まれることの証明を構築するために使用される。

【0183】

トランザクションのメタデータは、付加トランザクションのトランザクションid、付加トランザクションへの入力のサブセット、付加トランザクションが記憶されるブロックヘッダ、付加トランザクションが記憶されるブロックid、付加トランザクションに関連するタイムスタンプ、および付加トランザクションのトランザクションidのための兄弟ハッシュのアレイのうちの任意の1つまたは複数であってもよい。

【0184】

好ましくは、含有の証明はマークル木証明である。マークル木証明は、木として編成される既知の認証されたデータ構造である。各データブロックのハッシュは、基本層または葉の上のノード、および木または枝のあらゆる内部ノードに記憶され、その2つの子ノードのハッシュから計算される暗号学的ハッシュを含む。木の最上位ノードおよびマークル根は、木がどのデータセットから構築されたかを一意に特定する。したがって、マークル木は効率的な含有証明を可能にし、マイナーまたは証明者ノードは、あるデータブロックが認証されたデータセットの一部であることを、監査パスとともに証明を提出者または検証者ノードに送信することによって、提出者または検証者ノードに示す。監査パスは、提出者がデータセット全体を明らかにするのを必要とすることなく、マークル根を再計算するのに必要なノードハッシュを含む。Bitcoin SVでは、ブロックに含まれるトランザクションはマークル木に記憶される。

【0185】

好ましくは、トランザクションのメタデータは、付加トランザクションのトランザクション識別子(TxID)、ブロックチェーントランザクションが含まれるブロックのブロックヘッダ、およびトランザクション識別子(TxID)のための兄弟ハッシュのアレイを備える。兄弟ハッシュのアレイは、前記監査パスを構築するために使用されるので、証明に含まれる。ハッシュはマークル含有証明と呼ばれる。

【0186】

好ましくは、ブロックヘッダは独立に、含有証明から(すなわち含有証明の一部であるblockhashを使用して)ソースする。ヘッダは、ブロックチェーン自体から独立に入手可能であり、または、2021年5月14日に出願された英国特許出願第2106950.5号において説明されるHeaders Clientを使用することによって入手可能である。

【0187】

監査者は、示されたヘッダが実際に最長のチェーンの一部であることを確実にすべきである。

【0188】

含有証明のさらなる例示的な特徴および使用法が、nChain Holdings Limited名義で2021年2月17日に出願された英国特許出願第2102217.3号の明細書全体で論じられる。

【0189】

Checkpoint Now
checkpointまたはonFinalise方法が使用される場合、オプションのcheckpointNowフラグがオプションで使用される。新しいイベントがオフチェーンデータセットへの(および場合によっては、適切なトリガ条件が満たされる場合にはオンチェーンデータセットへの)記憶のために受信されるとき、checkpointNowフラグがオプションで設定され得る。フラグが設定される場合、それは、トリガ条件が満たされているかどうかにかかわらず、受信されたイベントに関連するデータがオンチェーンデータセットに記憶されるようにする。checkは、データがオンチェーンデータセットに追加されるようにするためにcheckpointing方法にオーバーライドするので、オーバーライドフラグであるとみなされ得る。

【0190】

したがって、イベントストリームに追加すべきイベントを受信すると、フラグが設定されている場合、イベントデータ、またはイベントデータに基づくデータが、オンチェーンデータセットに追加される。

【0191】

オンチェーンデータセットに含まれるべきデータのタイプは、データフォーマットオプション(attest、notarise、およびpublicise)に依存する。

【0192】

有利なことに、これは、重要なデータまたはイベントが監査のためにオンチェーンデータセットにコミットされることを許可または要求するためのより多くの自由を、データをイベントストリームに出すクライアントに与える。重要なイベントは、イベントストリームのための特定のマイルストーンを通ることを含み得るので、データが記憶されることは、関連する有限ステートマシンまたはスマートコントラクトにおける特定の状態への到達をもたらす。

【0193】

この技術的な特徴が可能にし得る別の有利な使用法は、checkpoint方法が捉えない可能性のある特定の重要な時間にストリームが解決されるのを可能にすることである。たとえば、checkpoint方法が、毎日日中にデータをオンチェーンデータセットに追加するために使用されるが、クライアントが、(会計報告の目的で)会計年度の最終日の深夜に現在のイベントが記録されることを望む場合、クライアントは単に、深夜の前に出す最後のイベントにcheckpointNowフラグを追加し、それは、設定されているあらゆる以前のcheckpointトリガ条件とは無関係に、監査者による調査のためにオンチェーンデータセットに追加される。

【0194】

イベントストリームブロックチェーン検証
本開示の第2の態様は全般に、ブロックチェーンに関連する複数のサービスを提供するプラットフォームの一部としての、オンチェーンデータセットおよびオフチェーンデータセットの検証のコンピュータで実施される方法に関する。プラットフォームは、複数のクライアントのために提供され、アプリケーションプログラミングインターフェース(API)と関連付けられる少なくとも1つのプラットフォームプロセッサによって実装される。

【0195】

データセットのブロックチェーンに記憶された表現を検証するためのコンピュータで実施される方法は、オンチェーンデータセットへの参照を取得するステップであって、オンチェーンデータセットが、ブロックチェーンに記憶され、トランザクションを搬送するデータを備え、トランザクションを搬送する各データが、オフチェーンデータセットに記憶されたイベントを示すデータを備えるステップと、オンチェーンデータセットを調査するステップと、オンチェーンデータセットの中のトランザクションを搬送する各データに対して、オフチェーンデータセットの中のイベントを示すデータがオフチェーンデータセットの中のイベントと関連付けられると判定するステップと、オンチェーンデータセットおよびオフチェーンデータセットが互いに対応することを検証するステップとを備える。

【0196】

好ましくは、ブロックチェーンは公開ブロックチェーンである。有利なことに、公開ブロックチェーンおよび/または第三者がブロックチェーンを読み取ることを可能にする能力をもつブロックチェーンでは、あらゆる関心をもっている関係者が、データを出したかどうか、データを記憶しているかどうか、または完全な第三者であるかどうかにかかわらず、オンチェーンデータセットおよびオフチェーンデータセットを、それらが互いに対応することを確実にするために監査することができる。特に、本発明の方法は第三者がトラストレスの様式でデータを検証できるようにする方法を提供する。ブロックチェーン自体のイミュータビリティが、ブロックチェーンへの提出の後にイベント関連データを改変することがほとんど不可能であるような、イベントを示すデータを記憶するための方法をもたらす。

【0197】

いくつかの実施形態では、オフチェーンデータセットの中のデータアイテムは、少なくとも原像および原像のダイジェストを備える。好ましくは、オフチェーンデータセットのデータを示すデータは、オフチェーンデータセットの中のデータアイテムの原像のダイジェストを備える。より好ましくは、オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップは、オンチェーンデータアイテムの原像の同じダイジェストを用いてオフチェーンデータセットの中のデータアイテムを見つけることを備える。

【0198】

好ましくは、原像は、各データアイテムと関連付けられる、関連するイベントのメタデータを備える。

【0199】

有利なことに、原像のダイジェストは、オフチェーンデータの存在証明として機能する。原像のダイジェスト(説明全体でstreamDigestと呼ばれる)のみを使用することで、関心をもつ第三者は、前記ダイジェストへとハッシュする原像を有する対応するイベントを見つけようとすることができる。ここで使用されるダイジェストは一方向のダイジェストであるので、悪意をもったクライアントまたは記憶提供者が、意図されている「良い」イベントデータと同じダイジェストを有する「悪い」イベントデータを見つけてそれで代用するのは、法外なほど計算的に困難である。一致するダイジェストをもつそのようなイベントを見つけることができる場合、監査者は改竄がないことの妥当性について確信することができる。ブロックチェーンのイミュータビリティはさらに、悪意のあるブロックチェーンマイナーが過去データを改竄する能力を制約するので、このセキュリティを高める。

【0200】

イベントデータ自体と比較してサイズがはるかに小さいダイジェストのみを使用して、イベントデータの全体を検証できるという点に、さらなる利点を見出すことができる。それは、ブロックチェーン上のデータおよび処理能力を節約するので、イベント関連のトランザクションに対して動作する、またはそれを記憶する、あらゆる関連するブロックチェーンデバイスまたはプロセスのカーボンフットプリントを減らす。

【0201】

いくつかの実施形態では、オフチェーンデータセットのデータアイテムを示すデータは追加で、オフチェーンデータセットのデータアイテムの原像を備える。好ましくは、オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップは、オンチェーンデータアイテムと同じ原像をもつオフチェーンデータセットの中のデータアイテムを見つけることを備える。

【0202】

いくつかの実施形態では、オフチェーンデータセットのデータアイテムを示すデータはさらに、イベントのハッシュを備える。好ましくは、オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップは、イベントの同じハッシュを有するオフチェーンデータセットの中のデータアイテムを見つけることを備える。

【0203】

有利なことに、イベントの原像および/またはイベント自体のハッシュの存在は、オンチェーンデータセットおよびオフチェーンデータセットのより細かい検証を可能にする。原像のダイジェストは、データが改竄されているかどうかを、イベントの原像および/またはハッシュを使用することによって確認することができるが、検証者は、オンチェーンイベントのどの部分が改竄されたかを確認することができる。

【0204】

いくつかの実施形態では、オフチェーンデータセットのデータアイテムを示すデータはさらに、イベントおよび/またはイベントのサブセクションを備える。好ましくは、オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップは、同じイベントおよび/またはイベントのサブセクションを有するオフチェーンデータセットの中のデータアイテムを見つけることを備える。

【0205】

有利なことに、イベントデータ自体により、検証者は、前記イベントデータを使用するあらゆるスマートコントラクト、有限ステートマシン、または他のプロセスを検証することができる。検証者は、データが正当であることを検証できるだけではなく、データを書き込むクライアントがデータを使用するのを望むのと同様のまたは同じ方法でデータを使用することもできる。より細かい検証についての上記と同じ利点も当てはまる。

【0206】

いくつかの実施形態では、原像は、オフチェーンデータセットの中の先行するデータアイテムの原像のダイジェストを備える。

【0207】

有利なことに、ハッシュのこの連鎖した記憶は、過去データを改変しようと試みる悪意のある者に対抗するさらなる強みをもたらす。先行するイベントに依存する各原像があると、過去のイベントの改変は、その後に記憶されるあらゆるすべてのイベントの原像の改変へと伝播する。この伝播は、イベントが変更される点から前方に、チェーン全体にわたるダイジェストの変化として現れる。

【0208】

いくつかの実施形態では、オンチェーンデータセットの中の各トランザクションはさらなるトランザクションへの参照を備えるので、トランザクションのチェーンが形成される。好ましくは、オンチェーンデータセットを調査することは、オンチェーンデータセットの中の所与のトランザクションを取得することと、所与のトランザクションの中の最初の参照に基づいて、またはさらなるトランザクションの中の2番目の参照に基づいて、そのさらなるトランザクションを取得することとを備える。オプションで、オンチェーンデータセットへの参照は、トランザクションのチェーンの中の最初または最後のトランザクションへの参照である。オプションで、オンチェーンデータセットへの参照は、トランザクションのチェーンの中の最初または最後のトランザクションのトランザクションidを備える。オプションで、オンチェーンデータセットへの参照は、最初のトランザクションのブロックidを備える。

【0209】

有利なことに、各トランザクション参照が互いにチェーンのような方式で存在することは、トランザクションに消費順序を強制する。この順序は、たとえば、オンチェーンのイベントがオフチェーンのイベントと同じ順序であることを確認するために、検証の目的で使用され得る。さらなる利点は、トランザクションのチェーンの調査可能性である。これらのトランザクションは、どのようなさらなるインデクシング情報または他の追加の情報も用いずに、トランザクション情報(すなわち、消費出力点)のみを使用して調査され得る。

【0210】

いくつかの実施形態では、方法は、オフチェーンデータセットの中のデータアイテムを取得するステップを備える。いくつかの実施形態では、オフチェーンデータセットの各データアイテムは、データベースにアクセスすることによって、および/またはデータベースを実質的にミラーリングするデータストレージにアクセスすることによって取得される。

【0211】

有利なことに、データベースを実質的にミラーリングするデータストレージにアクセスすることで、監査者は、過去データを検証するためのデータアクセス呼び出しにより、現在使用されている可能性のあるデータベースに過剰な負荷をかける必要がない。

【0212】

また第2の態様によれば、デバイスはプロセッサおよびメモリを備え、メモリは、プロセッサによる実行の結果として、上で説明されたようなコンピュータで実施される方法をデバイスに実行させる実行可能命令を含む。

【0213】

また第2の態様によれば、システムは、オンチェーンデータセットおよびオフチェーンデータセットを監査するように構成される上で説明されたようなデバイスと、監査の結果を受信するように構成される第三者デバイスとを備える。

【0214】

図8を参照すると、第2の態様によるシステム800は、図5を参照して説明されたような構成要素と同じまたは同様の構成要素で示される。重要である場合、同じまたは同様のデバイスもしくは通信チャネルが使用されることを示すために、図5から図8で同じ参照番号が使用されている。クライアントデバイス502は、プラットフォームプロセッサ504と通信しており(510)、ブロックチェーンネットワーク101と通信しており(802)、クライアントデータベース804と通信している(806)。プラットフォームプロセッサ504は、ブロックチェーンネットワーク101と通信しており(514)、プラットフォームデータベース506と通信している(514)。

【0215】

クライアント502はブロックチェーンネットワーク101と通信している(802)ので、ブロックチェーンの中のブロックおよび/もしくはトランザクションをダウンロードし、ならびに/またはそれらについてネットワークの中のノードに尋ねることが可能である。オプションで、クライアント502はブロックチェーンのローカルコピーを記憶する。クライアント502は、ブロックチェーンネットワーク101と通信している間、この態様の目的で、ブロックチェーンに含めるためのデータを出すように構成されない。

【0216】

クライアント502はオプションで、プラットフォームプロセッサ504に出されるデータを記憶するために、クライアントデータベース(またはデータストア)804と通信している(806)。この場合、イベントデータセットは、クライアントデータベース804およびプラットフォームサービスデータベース506という少なくとも2つの場所に記憶される。またさらに、ブロックチェーンは、オプションでデータベースの完全な再現であるイベントデータセットのオンチェーン表現を記憶する。オプションで、データセットは、クライアントデータベース804にクライアント504によって全体が記憶はされず、オフチェーンデータセットの中の各イベントは、プラットフォームプロセッサ504を介して取得される。

【0217】

図9を参照すると、イベントデータセットを検証する方法900が示される。この方法は、イベントデータセットを監査する方法ともみなされ得る。データセットはイベントのセットであり、各イベントのソースは、それを作成するクライアントおよび/またはクライアントによって権限が委任された任意の関係者である。検証はクライアントによって行われるものとして提示されているが、クライアント、プラットフォームプロセッサ、および他の第三者を含むあらゆる関係者も、ブロックチェーン(これは通常は公開であるが、常にではない)とオフチェーンデータセットの両方への読み取りアクセス権を有する限り、前記方法を行うことができることを、当業者は理解するだろう。第三者は、プラットフォームプロセッサのデータベースへの委任された読み取りアクセス権を介して(プラットフォームプロセッサのAPIを介して)、および/またはデータセットの自身のストレージからクライアントによって提供される、データセットへのアクセス権を有する。第三者はオプションで監査者である。

【0218】

第1のステップ902において、クライアントは、オフチェーンデータセットを用いて検証することを望んでいるオンチェーンデータセットへの参照を取得する。オンチェーンデータセットは好ましくは、各トランザクションが隣接するトランザクションへの参照を備えるように、トランザクションのチェーンとして記憶される。好ましくは、オンチェーンデータセットへの参照は、トランザクションのチェーンの中のトランザクションの1つのトランザクションidである。より好ましくは、オンチェーンデータセットへの参照は、トランザクションのチェーンの中の最初または最後のトランザクションへの参照である。好ましくは、トランザクションのチェーンは、上記の図7A、図7B、および図7Cを参照して説明されるようなものである。

【0219】

代替として、オンチェーンデータセットへの参照は、トランザクション参照のリストへの参照である。

【0220】

オンチェーンデータセットへの参照が取得されると、オンチェーンデータセットの一部であるトランザクションが調査され(904)、または別様に取得される。調査の方法は、トランザクションが記憶された構造に依存する。「オンチェーンデータセットの調査」という見出しのもとで、さらなる詳細が以下で提供される。

【0221】

オンチェーンデータセットの中のトランザクションを搬送する各データは、オフチェーンデータベースに記憶されるべきイベントを示すデータを備える。これらのオンチェーン表現がブロックチェーンにどのように記憶されるかの好ましい方法は、「イベントストリームのブロックチェーン記憶」という見出しのもとで上で説明され、トランザクションを搬送する各データは、図7Bを参照して上で説明されたような付加トランザクションである。この例では、イベントのすべてのサブセットがオンチェーンデータセットにおいて表される。上で説明されたように、付加トランザクションは、原像のハッシュ、原像、イベントデータのハッシュ、およびイベントデータのうちの任意の1つまたは複数などの、オフチェーンデータセットの中のイベントを示す異なるタイプのデータを備え得る。異なるデータタイプおよび構造が、「オフチェーンデータセットに記憶されたイベントを示すデータ」という見出しのもとでより詳しく説明される。

【0222】

オンチェーンデータセットの中のトランザクションを搬送する各データに対して、オンチェーントランザクションに存在するデータがオフチェーンデータセットの中のイベントと関連付けられるという決定が行われる。このステップは、トランザクションおよび/またはトランザクション内に含まれるデータがオフチェーンデータセットの中のイベントを正当に表すかどうかを検証することになるので、検証ステップであるとみなされ得る。検証/関連付けステップは、オンチェーントランザクションに存在するデータに対応するイベントがオフチェーンデータセットに存在することと、それが前記オフチェーンイベントについて正当であることとを確認することを備える。検証はオプションで、データの比較、タイムスタンプの比較、および/または任意の他の利用可能なメタデータの比較を含む。

【0223】

特に、オフチェーンイベントのすべてが常にオンチェーントランザクションにおいて表されるとは限らないので、方法は、オンチェーンの記憶されたイベントのすべてが正当であることを確認しているだけである。たとえば、checkpoint方法が上で説明されたように使用されるとき、トリガ条件はオプションで、イベントのすべてがオンチェーンデータセットにおいて表されるわけではないように設定される。

【0224】

少なくともこれらのオンチェーンデータセット検証に基づいて、オンチェーンデータセット全体がオフチェーンデータセットを表すかどうかについての決定。これは、オンチェーンデータセットおよびオフチェーンデータセットが互いに対応することを検証することとしても記述され得る。好ましくは、いくつかの実施形態では、オンチェーンデータセットがオフチェーンデータセットを正当に表すためには、トランザクションを搬送するオンチェーンデータのすべてが、オフチェーンデータセットの中の関連するイベントを有し、その関連するイベントがオンチェーントランザクションによって正当に表される。

【0225】

好ましくは、他の実施形態では、すなわち時間に基づく(トリガ)checkpointでは、オンチェーントランザクションは、直接のオフチェーンイベントをもたないことがある。この場合、オンチェーントランザクションは、最後の書き込まれたイベントと関連付けられてもよい。しかしながら、連続する時間期間と時間期間との間に新しいイベントが追加されない場合、オンチェーンstreamDigestは変更されない。これは、その期間の間に活動がないことを示唆する。streamDigestはストリームのあらゆるビットを包含するので、StreamDigestがオンチェーンで書き込まれるときに必ず、それはその時間より前に書き込まれたすべてのデータの完全性を保護する。

【0226】

オンチェーンデータセットおよびオフチェーンデータセットの検証906はまた、オフチェーンデータセットとのオンチェーンデータセットに記憶されたメタデータの比較を備えてもよい。好ましくは、オンチェーンデータセットのメタデータは、オンチェーンデータセットの中の最初のおよび/または最後のトランザクションに記憶される。たとえば、2つのデータセットが同じであること、または適度に近いことを確実にするために、それらの間で完成時間が比較されてもよい。イベントの総数は最後のトランザクションに記憶されてもよく、これはオフチェーンデータセットの中の総数と比較されてもよい。

【0227】

あらゆる関係者が、本明細書で説明される方法およびシステムを使用して、様々な使用事例およびデータタイプに応じて、以下のうちの任意の1つまたは複数を確認することができる。
・データセットが、含まれるべき要素のみを含むか?
・データセットが、含まれるべきすべての要素を含むか?
・各要素のデータが忠実に記録されているか?
・イベントの順序が忠実に記録されているか?
・各イベントの時間が忠実に記録されているか?

【0228】

好ましくは、検証ステップ906は、オンチェーンデータセットおよび/またはオフチェーンデータセットの両方について以下の任意の1つまたは複数を検証するステップを備える。
データセットが、含まれるべき要素のみを含む、
データセットが、含まれるべきすべての要素を含む、
各データセットのデータが互いと比較して正しく記録されている、
データセットの中のイベントの順序が正しい、および
データセットの中の各イベントの時間が正しい。

【0229】

好ましくは、オフチェーンデータセットはイベントのすべてを備え、オンチェーンデータセットはイベントのサブセットを備える。

【0230】

好ましくは、検証ステップは、オフチェーンデータセットを調査するステップと、オンチェーンデータセットに記録されるべきすべてのイベントがそこに記録されていることを検証するステップとを備える。

【0231】

いくつかの実施形態では、オンチェーンデータセットの調査は、対応するオンチェーンイベントを有するべきオフチェーンイベントを見つけたことに応答して行われてもよい。すなわち、オンチェーンで含まれるべき値があることを検証するためにオフチェーンデータセットについて反復する場合、これは、前記イベントを見つけるためのオンチェーンデータセットの前記調査をトリガする。この調査は、順序ならびに任意の他の検証ステップ(データ完全性または時間など)が追加で確認されるように増分的であってもよく、または、オンチェーンデータセットに存在する各イベントについて確認するためにオンチェーンのデータセットの最初から開始してもよい。

【0232】

他の実施形態では、オンチェーン調査では、ブロックチェーンが事前に完全にインデクシングされており、ストリームの中のトランザクションが1つずつフェッチされるのが好ましいことがある。

【0233】

実施形態では、checkpoint方法および(ソルト化された)公証、すなわちnotariseのいくつかの実施形態についてそうであることがあるように、preimageがオンチェーンで書き込まれない場合、予想されるデータが適切に考慮されていることを証明する計算を実行するのに不十分なオンチェーンデータしかないことがある。これは、監査者または検証者が、すなわち原像を備えるメタデータのために、プラットフォームから欠けている情報を取得しなければならないことがあることを意味する。metadata_nは、stream seed、streamDigest_n、whenRecorded_n、event index n、delegatedWriter index、salt_n、およびオプションでevent data_nのコピーを含む。監査者エンティティがいずれのブロックチェーントランザクションも読み取る必要がないことは好ましい。

【0234】

有利なことに、いくつかの実施形態では、プラットフォームは、完全なトランザクションデータ、マークル含有証明(ハッシュのアレイ)、および完全なトランザクションデータを含むブロックのヘッダのblockhashを提供してもよい。完全なトランザクションデータは、その出力の1つに少なくともstreamDigestを常に含む。

【0235】

この場合、監査または検証プロセスは以下のステップを備えてもよい。
A.あらゆるイベントのオフチェーン記録を最初からフェッチする。
・記録は、event metadata_nとオンチェーントランザクションのコピーを足したもの(txn_n)、OP_RETURNのために使用される出力インデックス(out_i)、およびマークル含有証明(P_n)(もしあれば)を含む。
B.preimageの構築において使用するためにEventStreamに送信される元のデータを準備する。
・H_n:=sha256(data_n|salt)
C.H_nおよびプラットフォームから返された情報を使用して、preimage_n(メタデータ要素whenRecorded_n、delegated writer index、event index nを含む)およびstreamDigest_n-1を前の原像の計算から構築する。
・preimage₀に対して、streamDigest_n-1は「シード」値(やはりメタデータにおいて返される)により置き換えられる。
・streamDigest_nを計算する。
・計算されたstreamDigest_nをmetadata_nにおいて供給されるstreamDigestと比較する。
・同一である場合、これは、streamDigest_nの作成を引き起こしたdata_nおよびインデックス0からn-1のストリーム全体が変更されていないことの証明としてみなされ得る。
D.P_nが含まれる場合、streamDigest_nがオンチェーンで記録されていることを妥当性確認することに進む。
・txn_nのout_iにおいて保持されるデータキャリア出力(すなわち、streamDigest_e)を抽出する。
・フォーマットはop_false op_return 0x20 <streamDigest_e>である。
・計算されたstreamDigest_nを抽出されたstreamDigest_eと比較する。
・同一である場合、これは、streamDigest_nがtxn_nの一部であることの証明としてみなされ得る。
E.マークル根を計算する。
・H_D:=sha256(sha256(data_n))を計算する。
・マークル根R_n:=merkle(H_D,P_n(nodes))を計算する。
F.ブロックヘッダを得る。
・metadata_n.blockhashをHeaders Clientに送信して実際のヘッダH_Bを取得する。
・metadata_n.blockhashは、適用されるハッシュに応じて、sha256(H_B)またはsha256(sha256(H_B))を使用してもよい。言い換えると、blockhashは任意のハッシュ関数を使用することができ、sha256またはsha256(sha256(header))は例である。
G.H_B(merkleRoot)をR_nと比較する。
・同一である場合、それは、txn_nがblockhashと一致するハッシュを有するブロックの一部であることを証明する。
・したがって、これは、data_nが指定されたインデックスおよび時間においてEventStreamに証明可能に追加されたことの証明としてみなされ得る。

【0236】

好ましくは、検証ステップが、オンチェーンデータセットが含むべきイベントのすべてを備えることを検証するステップを備える場合、方法は、オンチェーンメタデータを備えるオフチェーンイベントを見つけるステップと、各イベントに対して、メタデータがイベントを表すオンチェーントランザクションに正しく対応することを検証するステップとを備える。好ましくは、メタデータは、ブロックチェーンへの含有の証明を備える。より好ましくは、検証のステップは、証明が正しいことを検証するステップを備える。いくつかの例では、上で言及されたように(監査プロセスのステップを参照されたい)、実際には、ユーザはプラットフォームプロセッサから証明書を取得し、この証明書は、それらのトランザクション、トランザクションID、対応するブロックID、マークル根、および含有証明を含む。この情報がオフチェーンで記憶されていれば、トランザクションがその中にあるとされているブロックのマークル根と同じマークル根をTx IDおよびマークル含有証明が提供したかどうかを確認することによって、その情報を独立に検証することが可能であろう。

【0237】

好ましくは、メタデータおよび/または含有の証明は、「オンチェーンメタデータを用いたオフチェーンデータセットの更新」という見出しのもとでの議論を参照して説明される通りである。

【0238】

この方法900はオプションで、上で説明された方法500によって作成されるような、イベントストリームをオフチェーンおよびオンチェーンで検証するために使用される。

【0239】

オンチェーンで記憶されるイベントを示すデータがオフチェーンで記憶されることを検証する際、検証デバイスはオフチェーンデータセットも取得する。検証者(クライアント502、プラットフォームプロセッサ504、または第三者の監査者)は、オフチェーンデータセットの中の各アイテムを1つずつ取得し、またはデータセットを全体として取得する。通常、クライアント502は、それまで書き込んでいたオフチェーンデータセットへの読み取りアクセス権を有する。オプションで、検証プロセスの前または間に、クライアントはオフチェーンデータセット全体を取得するので、プラットフォームプロセッサ504への複数の要求が必要ではないように検証ステップを行うことができ、こうして時間と帯域幅を節約する。代替として、検証者が検証することを望んでいる各オンチェーントランザクションに対して、プラットフォームプロセッサ504への要求が、現在のオンチェーントランザクションに関連するオフチェーンで記憶されたイベントについて行われる。

【0240】

上記の追加または代替として、クライアント502がプラットフォームプロセッサ504へ書き込んでいる者であった(および/またはデータがプラットフォームプロセッサ504へ送信されていたのでクライアント502がそのデータを見ることができた)場合、クライアント502は、書き込まれている通りにデータを記憶するので、クライアント504は、自身のデータベース804にデータベースの自身のバージョンを維持する。こうすると、プラットフォームプロセッサ504に追加のメッセージが送信される必要はない。クライアント502が第三者にデータを検証してもらいたい場合、自身の記憶されたバージョン(もしあれば)を提供するか、または第三者に読み取りアクセス権を委任することができる。

【0241】

最後に、検証者はオプションで、オンチェーンデータセットがオフチェーンデータセットを正当に表すかどうかに関して行われる決定を伝送する。この決定は、検証を行うように要求した関係者および/または任意の他の関心をもつ関係者に伝送される。

【0242】

オンチェーンデータセットの調査
検証方法900において上で論じられた調査ステップ904において、オンチェーンデータセットが調査される。調査方法は、オンチェーンデータセットが記憶されたタイプおよびフォーマットに依存する。以下では、様々なオンチェーンフォーマットに対するいくつかの例示的な実施形態と、それらを調査するあり得る方法が提供される。様々なデータ構造に対する調査方法が可能であってもよいことを当業者は理解するだろう。

【0243】

上で論じられたように、オンチェーントランザクションは好ましくは、各トランザクションが隣接トランザクションへの参照を備えるようにチェーンの中にあり、より好ましくは、どちらの方向にもその参照をたどることができる。すなわち、トランザクションAがトランザクションBへの参照を備える場合、トランザクションAからトランザクションBへの参照をたどることに加えて、トランザクションBから、トランザクションAに(逆に)参照をたどることができる。さらにより好ましくは、そのトランザクションは「ダストのチェーン」という見出しのもとで上で説明されたようなダストのチェーンを形成する。ダストのこのチェーンの中の各トランザクション(最初を除く)は、前のトランザクションの出力点を消費する形式で後方参照を備える。

【0244】

チェーンを前方に調査するために、「ダスト出力」644a、b、cの出力点が取り込まれ、その出力を消費するトランザクションが、操作対象の次のトランザクションになる。このステップは、チェーンの終わりに達するまで繰り返し行われる。

【0245】

チェーンを後方に調査するために、「ダスト入力」646a、b、dに記憶された出力点が取り出される。その出力点の中のトランザクションidは、チェーンの前のトランザクションのトランザクションidである。そのidをもつトランザクションが見つけられる。これらのステップは、チェーンの最初に達するまで繰り返し行われる。

【0246】

したがって、オンチェーンデータセットがトランザクションのチェーンの形式である場合、オンチェーンデータセットの調査は、オンチェーントランザクションのすべてを調査するまで、各トランザクションが備える参照をたどることを備える。上で示されたように、チェーンの任意のトランザクションから、参照をたどることによって前方または後方に調査することが可能である。したがって、いずれの開始点からもチェーン全体を調査することが可能である。オンチェーンデータセットへの参照がチェーンの中間のトランザクションである場合、セット全体を調査するために、検証者は、最初または最後のトランザクションに達するまで一方の方向に調査し、次いで、チェーンの中間の同じトランザクションから他方の方向に再び調査する。

【0247】

代替として、オンチェーンデータセットへの参照が、オフチェーンで記憶されたイベントに関するトランザクションのリストへの参照であるとき、好ましくは、トランザクション参照は、オンチェーンデータセット上の各トランザクションのトランザクションid、およびより好ましくは、ブロックidならびにトランザクションidである。

【0248】

トランザクションidだけを用いて、ブロックチェーンの中のトランザクションのすべてを反復することにより(またはすべてのトランザクションをすでにインデクシングしたブロックチェーンサービスを使用して)トランザクションを見つけることができる。ブロックidを用いると、クライアントは、適切なブロックを見つけるだけでよく、次いで、トランザクションの履歴全体ではなく、前記ブロックの中のトランザクションのみを反復する。したがって、オンチェーンデータセットを調査することは、トランザクションidを介して各トランザクションを調べることを備える。

【0249】

ダストのチェーンのさらなる例示的な特徴、およびどのようにそれらを調査するかが、nChain Holdings Limited名義で2021年2月18日に出願された英国特許出願第2102314.8号の明細書全体で論じられている。これらのダストのチェーンの特徴は、データを搬送しない「チェンジアウトおよびチェンジイントランザクション」とデータ(ならびに他のイベントストリーム上のデータ)を搬送する「ランデブートランザクション」を含む。これらのタイプのトランザクションを調査するための方法も、その明細書で開示されている。

【0250】

オフチェーンデータセットに記憶されたイベントを示すデータ
上で論じられたように、オンチェーンデータセットの中のトランザクションは、オフチェーンデータセットの中のイベントを示すデータを備える。オフチェーンデータセットの中のイベントを示すデータは、それがイベントを一意に特定できるようなものであり、好ましくは、プラットフォームプロセッサ504またはブロックチェーンへ出されてからイベントに関連するデータおよび/またはメタデータが変更されていないという検証を行えるような情報を提供する。特に、イベントを示すデータを備えるトランザクションがブロックチェーン上で確認されると、ブロックチェーンのトランザクションがイミュータブルであるという特徴により、データはイミュータブルであるとみなされる。

【0251】

好ましくは、オフチェーンデータセットの中のイベントを示すデータは、上記の「ストリームの現在の状態」という見出しのもとで説明されたような実施形態の1つの形式である。したがって、イベントを示すデータは、以下のタイプの任意の1つまたは複数であってもよい。いくつかの実施形態では、これは、preimage、StreamDigest、H(data)、およびdataの1つまたは複数のすべてのあり得る組合せを含んでもよい。
・[streamDigest_n]
・[streamDigest_n][H(data_n)]
・[streamDigest_n][data_n]
・[preimage_n][streamDigest_n]
・[preimage_n][streamDigest_n][H(data_n)]
・[preimage_n][streamDigest_n][data_n]
・[preimage_n][streamDigest_n][split(data_n), 1 of 2]
・[preimage_n][streamDigest_n][split(data_n), 2 of 2]

【0252】

これは、以下の方式でも説明され得る。オプションで、イベントを示すデータはイベントのstreamDigestを備え、streamDigestはイベントのpreimageのハッシュである。オプションで、イベントを示すデータはさらにイベントのpreimageを備える。オプションで、イベントを示すデータはさらに、イベントに関連するデータのハッシュを備える。追加または代替として、イベントを示すデータはイベントデータを備える。オプションで、イベントデータが単一のトランザクションに対して大きすぎる場合、イベントデータは2つ以上のトランザクションに分割される。

【0253】

好ましくは、検証者は、データが記憶されたフォーマットを特定し、存在するデータを用いてデータを検証するための適切なステップを使用するように構成される。様々なデータタイプを検証するためにとられる例示的なステップが、以下で説明される。

【0254】

イベントを示すデータがstreamDigestしか備えない場合、それでもこれは、イベントを一意に特定するのに十分である。いくつかの実施形態では、これは、元のデータ、それがいつ記録されたか、および前と後に来たイベントに対するストリームにおけるその場所を特定することを含む。イベントを示すこのデータに関連するイベントを見つけるために、オフチェーンデータセットの中を探して、同じstreamDigestをもつイベントを見つける。好ましくは、オフチェーンデータセットは、各イベントのためのstreamDigestを記憶する。代替として、オフチェーンデータセットはこの情報を記憶せず、イベントストリームの中の各イベントのpreimageが構築され(まだ存在しない場合)、それが同じstreamDigestを有するか異なるstreamDigestを有するかを決定するためにハッシュされる。streamDigestは、イベントの「存在の証明」の一形式であるとみなされ得る。

【0255】

上で説明されたように、streamDigestはpreimageのハッシュであり、preimageはデータのハッシュを備える。同じstreamDigestをもつイベントを見つけることは、イベントデータが変更されていないことを検証することとしても機能し、それは、データが変更されていれば、streamDigestも変化しているはずだからである。またさらに、preimageは、以前のイベントのstreamDigestも備える。ハッシュのこのチェーンを仮定すると、所与のトランザクションおよびイベントを検証することは、すべての以前のイベントのデータが改変されていないことも検証する。

【0256】

データタイプのすべてが少なくともstreamDigestを備えるので、これらのステップは存在するあらゆるデータタイプのために使用され得る。

【0257】

データタイプがstreamDigestに加えてpreimageを備える場合、オフチェーンイベントを探すことはより簡単になり得る。preimageは、ストリームにおけるイベントのインデックスを備える。したがって、同じstreamDigestを有するイベントを見つける(preimageを構築し、それをハッシュしてオフチェーンデータセットの中の各イベントのためのstreamDigestを見つけることを伴うことがあるプロセス)代わりに、preimageにおいて提供されるインデックスにおけるイベントが見つかるまで各イベントを反復して数える(特に、比較は必要ではなく、インデックスを数えるだけ)という、より時間的および計算的に効率的な方法が使用される。イベントがアレイおよび/またはインデクシングされたデータベースに記憶される場合、イベントは反復される必要はなく、検証者はそのインデックスに直接ジャンプすることができ、それは、メモリにおけるその場所が直接計算可能であり、および/またはすでに知られているからである。

【0258】

原像は、オンチェーンデータがオフチェーンイベントを正当に表すことを検証するために、さらなる詳細を備えてもよい。たとえば、preimageのwhenRecordedメンバーがオプションで、イベントがデータベースに記録されたときと比較される。これらの時間は、同じであるか、または十分類似していなければならない。

【0259】

データタイプがデータのハッシュまたはデータ自体を備える場合(2つ以上のトランザクションに分割されるかどうかにかかわらず)、これも検証者によって検証されるので、オフチェーンと同じデータがオンチェーンに存在する。

【0260】

ある代替の実施形態では、本開示は、上で言及されたダストのチェーンへの参照なしで、イベントのストリームがオンチェーンで忠実に表されていることを検証することに関する。この場合、原像なしで上で説明された”attest”または”notarise”を使用することで、トランザクションサイズ、したがってトランザクションコスト(すなわち、マイナーフィー)が最小限になる。そのような最小限のトランザクションは、単一の資金提供入力および単一のOP_RETURN出力を有する。トランザクションサイズは事前に知られているので、「残金」出力が必要とされないように、入手可能となるようにUTXO資金提供値をあらかじめ整えることが可能である。そのような実施形態は、各トランザクションの構築の同期を必要としないことがある。attestおよびnotariseのいくつかの例のように、preimageがオンチェーンでもない場合。preimageメタデータはオフチェーンのソースから取得され得るので、これは、この代替的な実施形態においてイベントの順序の検証のために使用され得る。

【0261】

プラットフォームシステム
さらなる態様によれば、先行する態様の方法およびシステムのいずれか1つまたは複数が、第1の態様において説明されたようなオンチェーンおよびオフチェーンデータストレージならびに/または第2の態様におけるオンチェーンおよびオフチェーンデータストレージの検証を提供するための以下で説明されるようなプラットフォームプロセッサとともに使用されてもよい。このさらなる態様は、BSVブロックチェーンなどのブロックチェーンネットワークを使用して、ソフトウェアで制御される技術システムまたはスマートコントラクトの管理などの、現実世界での有用なビジネスおよび技術への応用を迅速に行うことを有利に可能にする、Platform as a Service (Paas)およびSoftware as a Service (Saas)の提供であり得る。

【0262】

システムの高水準の概略図を示す、プラットフォームサービスの概要を図10において見ることができる。プラットフォームサービスは、API1508を提供するプラットフォームプロセッサ1500を有し、サービスはAPI1508を介して1つまたは複数のクライアントによってアクセスされ得る。

【0263】

この図に示されるようなプラットフォームサービス1500は、3つの群のサービスからなり、ユーザおよび組織が、クライアント側でブロックチェーンベースのソフトウェア、知識、またはライブラリを実際に実装することなく、ブロックチェーンの固有の性質によりもたらされる利点を簡単にかつセキュアに利用することを可能にすることを目的とする。
- チェーンの用途を商品データ台帳として簡略化することを目的とするデータサービス1502。好ましくは、データサービスは、ブロックチェーンへのデータの書き込みおよびブロックチェーンからのデータの読み取りを実施するために、本明細書において提供されるデータ構造および方法を使用する。
- ビットコインSVなどのデジタル資産によって裏付けられる一般化された計算ネットワークを提供することを目的とする計算サービス1504。
- ビットコインSVなどのデジタル資産を使用してトランザクションを行うための企業クラスの能力を提供するコマースサービス1506。
APIはウェブサービスとして実装されるので、APIにおいてクライアントからHTTPSプロトコルを介して、またはそれを使用して、要求が受信され得る。要求されるサービスは次いで、背後のソフトウェア1510を使用して1つまたは複数のサービスモジュールまたは処理リソース1502～1506によって実装され、そのような背後のソフトウェア1510は、ブロックチェーンに関連し、すなわち、ブロックチェーンに関連するトランザクションを作成し、処理し、出すための、リソース、ライブラリ、および/またはキー管理ウォレットの実装形態を実装するためのものである。処理されると、トランザクションは、(任意のそのような機能またはトランザクションライブラリを実装するクライアントの代わりに)ブロックチェーンネットワーク1512に出され得る。最大で、クライアントは、暗号通貨もしくは何らかの他のデジタル資産に関連するデジタルウォレットなどを実装することがあり、または実装することができるが、これは必須ではなく、それは、プラットフォームサービス1500は、クライアントのためのデジタル資産を提供して管理することも可能であり得るからである。

【0264】

図11は、ブロックチェーンに関連する複数のサービスのより粗い概略図を提供し、これは、提供されるサービスの1つまたは複数にそれを介してアクセスすることができるAPIに関連するプラットフォーム1600によって実装され得る。この図11において見られるように、データサービス1602は、データ書き込みサービス1602aおよびデータ読み取りサービス1602bを含み得る。イベントストリームおよび/またはデータライタはオプションで、図6Aにおいて説明されるような方法600を実施する。同様に、(図9において説明されるような検証方法900などのように)データアーカイブにアクセスすることを望むクライアントおよび/または第三者は、データリーダ1602bを使用してもよい。イベントストリームのさらなる詳細は、英国特許出願第2002285.1号(2020年2月19日にnChain Holdings Limitedの名義で出願された)の図4から図8を参照して論じられ、参照によって本明細書に組み込まれる。データ書き込みサービス1602aは、簡単で、セキュアで、最適化された方式で、クライアントがブロックチェーンへとデータを書き込むことを可能にする。データ読み取りサービス1602bは、クライアントがクエリを送信することを可能にし、これはブロックチェーンに記憶されたデータを返す。これは、クライアントがアドホックにもしくは定期的に、すなわちある時間枠内にブロックチェーンから読み取ることを望むデータのタイプを、または、ブロックチェーン1610において処理される関係するもしくは関係しないイベントもしくは文書に関連するデータのタイプをあらかじめ定義できるような、フィルタリングされたストリームを使用することであり得る。データアーカイブ機能が、指定されたイベントまたは契約のための以前のトランザクションのログへのアクセスを可能にする。

【0265】

プラットフォーム1600の計算サービス1606は、スマートコントラクトに関連するアプリケーション1606aおよびフレームワーク1606bを含み、これらは、いくつかの実施形態では、ブロックチェーン1610においてステートマシンとして表され得る。計算サービス1606はデータサービス1602と相互作用し、それは、データが入力される必要があり、結果があらゆるそのような計算のためにクライアントに提供される必要があるからである。

【0266】

コマースサービス1604は、ベストインクラスのセキュリティの実践および技術に基づく、ブロックチェーン1610を調査するための企業ウォレット1604aを介した企業クラスの能力の提供を担う。たとえば、いくつかの実施形態では、企業ウォレットは、1より多くの人物またはユーザまたはアカウントが、定められた基準、すなわちあらかじめ定められた限界を超える大きい値の暗号通貨に関連する基準を満たすトランザクションを承認する必要があり得るとき、ブロックチェーントランザクション処理を可能にするための機能を実装し得る。企業ウォレットはまた、別のリソースを表す暗号通貨またはトークンなどの大量のデジタル資産を移動するための、署名の閾値の数および/または署名のタイプを実装するための機能を含み得る。次いで、これらの資産の移動は、そのような企業ウォレットの実装形態によって適用される基準に基づく処理に従って、ブロックチェーン上で表現され得る。

【0267】

SPVサービス1608(簡略化された支払検証)は、マイナーノードを実行しないのでブロックチェーンからの情報を必要とするがそれへの直接のリンクを含まない、適用例である。そのようなSPVサービス1608は、軽量のクライアントが、ブロックチェーン1610全体をダウンロードすることなく、トランザクションがブロックチェーンに含まれることを検証することを可能にする。

【0268】

プラットフォームデバイス
ここで図12を見ると、本開示の少なくとも一実施形態を実践するために使用され得るコンピューティングデバイス2600の例示的な簡略化されたブロック図が提供される。様々な実施形態において、コンピューティングデバイス2600は、上で示され説明されたシステムまたは方法のいずれかを実装するために使用され得る。たとえば、コンピューティングデバイス2600は、図5もしくは図8のシステム500、800の1つまたは複数の構成要素として使用されるように構成されてもよく、または、コンピューティングデバイス2600は、所与のユーザに関連するクライアントエンティティ、データベース要求および/もしくは提出を行うクライアントエンティティ、プラットフォームプロセッサ、ならびに/またはデータベースマネージャとして構成されてもよい。したがって、コンピューティングデバイス2600は、ポータブルコンピューティングデバイス、パーソナルコンピュータ、または任意の電子コンピューティングデバイスであり得る。図12に示されるように、コンピューティングデバイス2600は、メインメモリ2608および永続的ストレージ2610を含むストレージサブシステム2606と通信するように構成され得る、1つまたは複数のレベルのキャッシュメモリおよびメモリコントローラ(集合的に2602とラベリングされる)を伴う1つまたは複数のプロセッサを含み得る。メインメモリ2608は、示されるようなダイナミックランダムアクセスメモリ(DRAM)2618および読み取り専用メモリ(ROM)2620を含み得る。ストレージサブシステム2606およびキャッシュメモリ2602は、本開示において説明されるようなトランザクションおよびブロックに関連する詳細などの、情報の記憶のために使用され得る。プロセッサ2602は、本開示において説明されるような任意の実施形態のステップまたは機能を提供するために利用され得る。

【0269】

プロセッサ2602はまた、1つまたは複数のユーザインターフェース入力デバイス2612、1つまたは複数のユーザインターフェース出力デバイス2614、およびネットワークインターフェースサブシステム2616と通信することができる。

【0270】

バスサブシステム2604は、コンピューティングデバイス2600の様々な構成要素およびサブシステムが意図されたように互いに通信することを可能にするための機構を提供し得る。バスサブシステム2604は単一のバスとして概略的に示されているが、バスサブシステムの代替の実施形態は複数のバスを利用してもよい。

【0271】

ネットワークインターフェースサブシステム2616は、他のコンピューティングデバイスおよびネットワークへのインターフェースを提供し得る。ネットワークインターフェースサブシステム2616は、コンピューティングデバイス2600からの他のシステムからデータを受信し、それにデータを送信するための、インターフェースとして働き得る。たとえば、ネットワークインターフェースサブシステム2616は、データ技術者がデータセンターなどの遠隔の位置にいる間にデータをデバイスに送信してデータをデバイスから受信することが可能になり得るように、データ技術者がデバイスをネットワークに接続することを可能にし得る。

【0272】

ユーザインターフェース入力デバイス2612は、キーボード、統合されたマウス、トラックボール、タッチパッド、またはグラフィクスタブレットなどのポインティングデバイス、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンなどのオーディオ入力デバイス、および他のタイプの入力デバイスなどの1つまたは複数のユーザ入力デバイスを含み得る。一般に、「入力デバイス」という用語の使用は、情報をコンピューティングデバイス2600に入力するためのすべてのあり得るタイプのデバイスおよび機構を含むことが意図されている。

【0273】

1つまたは複数のユーザインターフェース出力デバイス2614は、ディスプレイサブシステム、プリンタ、またはオーディオ出力デバイスなどの非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)、発光ダイオード(LED)ディスプレイ、もしくはプロジェクションなどのフラットパネルデバイス、または他のディスプレイデバイスであり得る。一般に、「出力デバイス」という用語の使用は、コンピューティングデバイス2600から情報を出力するための任意の可能なタイプのデバイスおよび機構を含むことが意図される。1つまたは複数のユーザインターフェース出力デバイス2614は、たとえば、説明されるプロセスおよびその変形を実行するアプリケーションとのユーザ対話を、そのような対話が適切であり得るときに支援するための、ユーザインターフェースを提示するために使用され得る。

【0274】

ストレージサブシステム2606は、本開示の少なくとも1つの実施形態の機能を提供し得る基本的なプログラミングおよびデータ構築物を記憶するための、コンピュータ可読記憶媒体を提供し得る。アプリケーション(プログラム、コードモジュール、命令)は、1つまたは複数のプロセッサによって実行されると、本開示の1つまたは複数の実施形態の機能を提供してもよく、ストレージサブシステム2606に記憶されてもよい。これらのアプリケーションモジュールまたは命令は、1つまたは複数のプロセッサ2602によって実行され得る。ストレージサブシステム2606は、本開示に従って使用されるデータを記憶するためのリポジトリを追加で提供し得る。たとえば、メインメモリ2608およびキャッシュメモリ2602は、プログラムおよびデータのための揮発性ストレージを提供し得る。永続性ストレージ2610は、プログラムおよびデータのための永続的(不揮発性)ストレージを提供することができ、フラッシュメモリ、1つまたは複数のソリッドステートドライブ、1つまたは複数の磁気ハードディスクドライブ、関連するリムーバブルメディアを伴う1つまたは複数のフロッピーディスクドライブ、関連するリムーバブルメディアを伴う1つまたは複数の光学ドライブ(たとえば、CD-ROMまたはDVDまたはBlue-Ray)、および他の同様の記憶媒体を含み得る。そのようなプログラムおよびデータは、本開示において説明されるような1つまたは複数の実施形態のステップを実行するためのプログラム、ならびに本開示において説明されるようなトランザクションおよびブロックに関連するデータを含み得る。

【0275】

コンピューティングデバイス2600は、ポータブルコンピュータデバイス、タブレットコンピュータ、ワークステーション、または以下で説明される任意の他のデバイスを含む、様々なタイプであり得る。加えて、コンピューティングデバイス2600は、1つまたは複数のポート(たとえば、USB、ヘッドフォンジャック、Lightningコネクタなど)を通じてコンピューティングデバイス2600に接続され得る別のデバイスを含み得る。コンピューティングデバイス2600に接続され得るデバイスは、光ファイバコネクタを受け入れるように構成される複数のポートを含み得る。したがって、このデバイスは、処理のために、デバイスをコンピューティングデバイス2600に接続するポートを通じて送信され得る電気信号に、光信号を変換するように構成され得る。コンピュータおよびネットワークの変化し続ける性質により、図12に示されるコンピューティングデバイス2600の説明は、デバイスの好ましい実施形態を示すことが目的の具体的な例として意図されているにすぎない。図12に示されるシステムより多数または少数の構成要素を有する多くの他の構成が可能である。

【0276】

例-機器活動ログ
ハイエンド機器の製造業者は、その顧客の機器の重要な活動ログにアクセスできることを望む。これは、保証またはサービス提供契約の一部であってもよい。ログを分析することによって、製造業者は、機器が最大の効率で動作していることを確実にするための予防的なステップをとることが可能になることがある。製造業者は、checkpoint方法を使用して、各製品群のための個々のEvent Streamを構成してもよい。機器は、登録以降に、その製品寿命の間重要なイベントのログを自動的にとる。製造業者は、ハートビート、動作時間、重要な部品の交換、適した材料の使用などを含む、あらゆる活動を遠隔で監視することができる。

【0277】

checkpoint方法を使用して、関心対象の個々のデータ点のアクセスのために、大量のデータをオフチェーンデータベースに記憶することができ、製造業者が、データが更新されていることを確認できるが、データ自体には関心をもたないように、オンチェーンデータセットがハートビートモニタとして使用される。

【0278】

上で説明された様々な方法は、コンピュータプログラムによって実装され得る。コンピュータプログラムは、上で説明された様々な方法のうちの1つまたは複数の機能を実行するようにコンピュータに命令するようになされるコンピュータコードを含み得る。そのような方法を実行するためのコンピュータプログラムおよび/またはコードは、1つまたは複数のコンピュータ可読媒体、またはより一般的にはコンピュータプログラム製品で、コンピュータなどの装置に提供され得る。コンピュータ可読媒体は、一時的または非一時的であり得る。1つまたは複数のコンピュータ可読媒体は、データ送信のために、たとえばインターネットを介したコードのダウンロードのために、たとえば、電子的な、磁気的な、光学的な、電磁的な、赤外線の、もしくは半導体のシステム、または伝播媒体であり得る。代替として、1つまたは複数のコンピュータ可読媒体は、半導体またはソリッドステートメモリ、磁気テープ、リムーバブルコンピュータディスケット、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、固い磁気ディスク、および、CD-ROM、CD-R/W、またはDVDなどの光学ディスクなどの、1つまたは複数の物理的コンピュータ可読媒体の形式をとり得る。

【0279】

ある実装形態では、本明細書で説明されるモジュール、構成要素、および他の特徴は、個別の構成要素として実装され、または、ASIC、FPGA、DSP、もしくは同様のデバイスなどの、ハードウェア構成要素の機能に統合され得る。

【0280】

加えて、モジュールおよび構成要素は、ファームウェアまたはハードウェアデバイス内の機能回路として実装され得る。さらに、モジュールおよび構成要素は、ハードウェアデバイスとソフトウェア構成要素の任意の組合せで、またはソフトウェアのみ(たとえば、機械可読媒体または送信媒体に記憶され、もしくは別様に具現化されるコード)で実装され得る。

【0281】

特に別様に述べられない限り、以下の議論から明らかなように、説明全体で、「決定する」、「提供する」、「算出する」、「計算する」、「特定する」、「組み合わせる」、「確立する」、「送信する」、「受信する」、「記憶する」、「推定する」、「確かめる」、「取得する」などの語を利用した議論は、コンピュータシステムのレジスタおよびメモリ内の物理(電気的な)量として表されるデータを、コンピュータシステムメモリまたはレジスタまたは他のそのような情報の記憶、送信、もしくは表示デバイス内の物理量として同様に表される他のデータへと操作して変換する、コンピュータシステムまたは同様の電子コンピューティングデバイスの活動および処理を指すことが理解されるだろう。

【0282】

本明細書および特許請求の範囲において使用される「備える(comprising)」という用語は、「少なくとも一部～からなる」を意味する。「備える」という用語を含む本明細書および特許請求の範囲における各々の陳述を解釈するとき、その用語の後にあるもの以外の特徴も存在していてもよい。「備える(comprise)」および「備える(comprises)」などの関連する用語も、同じように解釈されるべきである。

【0283】

本明細書において使用される場合、「および/または」という用語は、「および」もしくは「または」または両方を意味する。

【0284】

本明細書において使用される場合、名詞の後の「(s)」は、名詞の複数形および/または単数形を意味する。

【0285】

単数形での要素の言及は、複数形でそのような要素に言及することを排除せず、その逆も当てはまる。

【0286】

列挙される実施形態
以下の条項は、本開示に関連する例として、および本開示のさらなる理解を助けるために与えられる。

【0287】

1.データセットのブロックチェーンに記憶された表現を検証するためのコンピュータで実施される方法であって、
オンチェーンデータセットへのデータセット参照を取得するステップであって、オンチェーンデータセットが、ブロックチェーンに記憶され、トランザクションを搬送するデータを備え、トランザクションを搬送する各データが、オフチェーンデータセットに記憶されたイベントを示すデータを備えるステップと、
オンチェーンデータセットを調査するステップと、オンチェーンデータセットの中のトランザクションを搬送する各データに対して、
オフチェーンデータセットの中のイベントを示すデータがオフチェーンデータセットの中のイベントと関連付けられると判定するステップと、
オンチェーンデータセットおよびオフチェーンデータセットが互いに対応することを検証するステップとを備える、方法。

【0288】

2.オフチェーンデータセットの中のデータアイテムが、少なくとも原像および原像のダイジェストを備える、条項1によるコンピュータで実施される方法。

【0289】

3.オフチェーンデータセットのデータを示すデータが、オフチェーンデータセットの中のデータアイテムの原像のダイジェストを備える、条項2によるコンピュータで実施される方法。

【0290】

4.オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップが、
オンチェーンデータアイテムの原像と同じダイジェストをもつオフチェーンデータセットの中のデータアイテムを見つけるステップを備える、条項3によるコンピュータで実施される方法。

【0291】

5.オフチェーンデータセットのデータアイテムを示すデータが加えて、オフチェーンデータセットのデータアイテムの原像を備える、条項2から4のいずれか1つまたは複数によるコンピュータで実施される方法。

【0292】

6.オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップが、
オンチェーンデータアイテムと同じ原像をもつオフチェーンデータセットの中のデータアイテムを見つけるステップを備える、条項5によるコンピュータで実施される方法。

【0293】

7.オフチェーンデータセットのデータアイテムを示すデータがさらにイベントのハッシュを備える、条項2から6のいずれか1つまたは複数によるコンピュータで実施される方法。

【0294】

8.オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップが、
イベントの同じハッシュを有するオフチェーンデータセットの中のデータアイテムを見つけるステップを備える、条項7によるコンピュータで実施される方法。

【0295】

9.オフチェーンデータセットのデータアイテムを示すデータがさらに、イベントおよび/またはイベントのサブセクションを備える、条項2から8のいずれか1つまたは複数によるコンピュータで実施される方法。

【0296】

10.オフチェーンデータセットの中のデータアイテムを示すデータがオフチェーンデータセットの中のデータアイテムと関連付けられると判定するステップが、
同じイベントおよび/またはイベントのサブセクションを有するオフチェーンデータセットの中のデータアイテムを見つけるステップを備える、条項7によるコンピュータで実施される方法。

【0297】

11.原像が、オフチェーンデータセットの中の先行するデータアイテムの原像のダイジェストを備える、条項2から10のいずれか1つまたは複数によるコンピュータで実施される方法。

【0298】

12.オンチェーンデータセットの中の各トランザクションが、トランザクションのチェーンが形成されるようにさらなるトランザクションへのトランザクション参照を備える、先行する条項のいずれか1つまたは複数によるコンピュータで実施される方法。

【0299】

13.オンチェーンデータセットを調査するステップが、
オンチェーンデータセットの中の所与のトランザクションを取得するステップと、
所与のトランザクションの中の第1のトランザクション参照に基づいて、またはさらなるトランザクションの中の第2のトランザクション参照に基づいて、さらなるトランザクションを取得するステップとを備える、条項12によるコンピュータで実施される方法。

【0300】

14.オンチェーンデータセットへのデータセット参照が、トランザクションのチェーンの中の最初または最後のトランザクションへの参照である、条項12または13によるコンピュータで実施される方法。

【0301】

15.オンチェーンデータセットへのデータセット参照が、トランザクションのチェーンの中の最初または最後のトランザクションのトランザクションidを備える、条項12から14のいずれか1つまたは複数によるコンピュータで実施される方法。

【0302】

16.オンチェーンデータセットへのデータセット参照が、最初のトランザクションのブロックidを備える、条項12から15のいずれか1つまたは複数によるコンピュータで実施される方法。

【0303】

17.オフチェーンデータセットの中のデータアイテムを取得するステップをさらに備える、先行する条項のいずれか1つまたは複数によるコンピュータで実施される方法。

【0304】

18.オフチェーンデータセットの各データアイテムが、データベースにアクセスすることによって、および/またはデータベースを実質的にミラーリングするデータストレージにアクセスすることによって取得される、先行する条項のいずれか1つまたは複数によるコンピュータで実施される方法。

【0305】

19.プロセッサおよびメモリを備え、メモリが、プロセッサによる実行の結果として、先行する条項のいずれか1つまたは複数に記載のコンピュータで実施される方法をデバイスに実行させる実行可能命令を含む、デバイス。

【0306】

20.オンチェーンデータセットおよびオフチェーンデータセットを監査するように構成される条項19のデバイスと、
監査の結果を受信するように構成される第三者のデバイスとを備える、システム。

【0307】

上記の説明は、限定的ではなく例示的であることが意図されていることを理解されたい。上記の説明を読んで理解すれば、多くの他の実装形態が当業者に明らかになるだろう。本開示は、特定の例示的な実装形態を参照して説明されたが、本開示は、説明された実装形態に限定されず、添付の特許請求の範囲内の修正および変更とともに実践され得ることが認識されるだろう。したがって、明細書および図面は、限定するものではなく例示するものであるとみなされるべきである。したがって、本開示の範囲は、添付の特許請求の範囲に関連して、そのような請求項が権利を与えられる均等物の完全な範囲とともに決定されるべきである。

【符号の説明】

【0308】

100 システム
101 パケット交換ネットワーク、ブロックチェーンネットワーク
102 コンピュータ端末、コンピュータ機器
103 ユーザ、関係者
104 ブロックチェーンノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク
150 ブロックチェーン
151 ブロック
152 トランザクション
153 ジェネシスブロック
201 ヘッダ
202 入力フィールド
203 出力フィールド
301 サイドチャネル
351 トランザクションエンジン
352 ユーザインターフェース(UI)層
360 ユーザインターフェース(UI)、クライアントアプリ
362 UI要素、データエントリフィールド
363 UI要素、情報要素
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル決定エンジン
455 ブロックチェーン関連機能モジュール
502 クライアント
504 プラットフォームプロセッサ
506 データベース
644 ダスト出力
646 ダスト入力
648 資金提供入力
650 残金出力
660 最初のトランザクション
662 最後のトランザクション
664 ストリームメタデータ
666 ストリームメタデータ
1500 プラットフォームプロセッサ、プラットフォームサービス
1502 データサービス
1504 計算サービス
1506 コマースサービス
1508 プラットフォームAPI
1510 ブロックチェーンノードソフトウェア
1512 ブロックチェーンネットワーク
1600 プラットフォーム
1602 データサービス
1604 コマースサービス
1606 計算サービス
1608 SPVサービス
1610 ブロックチェーン
2600 コンピューティングデバイス
2602 プロセッサ
2604 バスサブシステム
2606 ストレージサブシステム
2608 メインメモリ、メモリサブシステム
2610 ファイルストレージサブシステム、永続的ストレージ
2612 ユーザインターフェース入力デバイス
2614 ユーザインターフェース出力デバイス
2616 ネットワークインターフェースサブシステム
2618 ダイナミックランダムアクセスメモリ(DRAM)
2620 読み取り専用メモリ(ROM)
2624 クロック

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6A】

【図6B】

【図7A】

【図7B】

【図7C】

【図8】

【図9】

【図10】

【図11】

【図12】

【国際調査報告】