知財求人 - 知財ポータルサイト「IP Force」
特表2024-512068ブロックチェーンで実行されるデータ・アプリケーションにおける改善されたシグネチャ検証方法及びシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-18
(54)【発明の名称】ブロックチェーンで実行されるデータ・アプリケーションにおける改善されたシグネチャ検証方法及びシステム
(51)【国際特許分類】
H04L 9/32 20060101AFI20240311BHJP
【ＦＩ】
H04L9/32 200Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023558738
(86)(22)【出願日】2022-03-17
(85)【翻訳文提出日】2023-11-21
(86)【国際出願番号】 EP2022057094
(87)【国際公開番号】W WO2022200193
(87)【国際公開日】2022-09-29
(31)【優先権主張番号】2104312.0
(32)【優先日】2021-03-26
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ライト，クレイグ スティーヴン
(72)【発明者】
【氏名】デイヴィーズ，ジャック
(57)【要約】
実施形態は、データ指向ブロックチェーン・アプリケーションに関して使用するための検証方法及びシステムを提供する。ブロックチェーン・プロトコルにおける従来のシグネチャ検証とは対照的に、本件で開示される実施形態は、単一のトランザクション内で、そのトランザクション内で提供されているデータのみを使用して、その場で実行される。従って、他のトランザクションから提供されるシグネチャに依存せず、リプレイ攻撃のようなエクスプロイトの可能性を防止することができる。実施形態では、これは、ロッキング・スクリプトではないトランザクションのアウトプット内にシグネチャを配置することによって達成することができる。
［図8］
［図8］
【特許請求の範囲】
【請求項1】
ブロックチェーン・トランザクション内に提供されているシグネチャを検証する方法であって：前記シグネチャを前記ブロックチェーン・トランザクション内に提供し及び／又はそれを検証するステップであって、前記シグネチャは：
前記トランザクションを一意に識別するためのトランザクション識別データを有しており；且つ
前記トランザクション内から導出可能な及び／又は取得可能なデータのみを含んでいるメッセージに基づいている、方法。
【請求項2】
請求項1に記載の方法において：i）前記メッセージはデジタル署名されている；及び／又は
ii）前記メッセージの少なくとも一部分は暗号化又はエンコードされている；及び／又は
iii）前記シグネチャは、前記トランザクション内で、アンロッキング・スクリプト以外の場所に提供されている；及び／又は
iv）前記シグネチャ及び／又はメッセージは、前記トランザクションのアウトプット内において、好ましくは前記トランザクションのロッキング・スクリプトにおいて提供される、方法。
【請求項3】
請求項1又は2に記載の方法において：i）前記トランザクション識別データは、アウトポイント又はその他のデータの部分であって前記トランザクションに一意に関連付けられるものを有するか又は関連しており；及び／又は
ii）前記トランザクション識別データは、エンコードされているか、ハッシュされているか、又は難読化されている、方法。
【請求項4】
請求項1ないし3のうちの何れか一項に記載の方法において、更に：i）前記シグネチャに関して検証処理を実行するステップ；及び／又は
ii）前記メッセージ及び公開鍵を用いて、前記シグネチャに関して検証処理を実行するステップ；
を含む、方法。
【請求項5】
請求項1ないし4のうちの何れか一項に記載の方法において：コンピュータ・ベースのリソースを用いて前記シグネチャを検証するステップ；
を含み、前記コンピュータ・ベースのリソースは、前記ブロックチェーンに関連する基本プロトコルに従ってマイニング及び／又は検証処理を実行するようには構成されていない、方法。
【請求項6】
請求項1ないし5のうちの何れか一項に記載の方法において：暗号鍵を用いて前記メッセージをデジタル署名する、エンコーディングする、又は暗号化するステップ；
を更に含む方法。
【請求項7】
請求項1ないし6のうちの何れか一項に記載の方法において：前記シグネチャの検証が成功した場合にアクションを許可し、或いは前記メッセージの検証が失敗した場合にアクションを禁止するステップ；
を更に含む方法。
【請求項8】
請求項1ないし7のうちの何れか一項に記載の方法において：前記ブロックチェーン・トランザクションは、アプリケーション・レベルのプロトコルに従って形成されている、方法。
【請求項9】
請求項8に記載の方法において、前記プロトコルは：ブロックチェーン・トランザクションの論理階層を形成するためにブロックチェーン・トランザクションの関連付けを支援するように構成されている；及び／又は
ブロックチェーンで実行されるメタネット・プロトコルである、方法。
【請求項10】
請求項1ないし9のうちの何れか一項に記載の方法において：前記シグネチャ及び公開鍵を、前記公開鍵を用いて生成された別のシグネチャと比較する際に使用するステップ；又は
前記公開鍵を別の公開鍵と比較することによって検証を実行するステップ；
を含む方法。
【請求項11】
請求項1ないし10のうちの何れか一項に記載の方法において：前記トランザクション識別データはアウトポイントを含む、方法。
【請求項12】
ブロックチェーン・トランザクションを生成又は提供するステップを含む、ブロックチェーンで実行される検証方法であって、前記ブロックチェーン・トランザクションは：i）前記トランザクションを一意に識別するためのトランザクション識別データ；及び前記トランザクション内から導出可能な及び／又は取得可能なデータのみ；を含むメッセージ；及び
ii）前記メッセージに関連付けられるか、前記メッセージに基づいているか、又は前記メッセージを用いて生成されるデジタル・シグネチャ；
を含む、方法。
【請求項13】
請求項12に記載の方法であって：i）前記トランザクションは、前記シグネチャを生成するために使用される暗号鍵に関連する公開鍵を更に有し；及び／又は
ii）前記トランザクション識別データはアウトプットを有し；及び／又は
iii）前記シグネチャは、前記公開鍵に関連付けられる暗号鍵を用いて前記メッセージをデジタル署名することによって生成され；及び／又は
iv）前記シグネチャは前記トランザクションに関連する任意のインプットの外に提供されている、方法。
【請求項14】
ブロックチェーン・トランザクション（Tx）に提供されているデジタル・シグネチャを検証する方法であって、前記ブロックチェーン・トランザクションは：検証されるべき前記デジタル・シグネチャ；
i）前記トランザクションを一意に識別するためのトランザクション識別データを有し、且つii）前記トランザクション内から導出可能な及び／又は取得可能なデータのみを含むメッセージ；及び
トランザクションID（TxID）；
プロトコル・フラグ；
任意的公開鍵（DPK）；及び
任意的トランザクションID（DTxID）を含む、方法。
【請求項15】
請求項14に記載の方法において、前記トランザクション（Tx）は、更に：記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンスを含む、方法。
【請求項16】
請求項14又は15に記載の方法において：前記記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンス、前記プロトコル・フラグ、前記任意的公開鍵（DPK）、及び／又は前記任意的トランザクションID（DTxID）は、前記トランザクションのアウトプット（UTXO）において、好ましくは前記アウトプット（UTXO）に関連するロッキング・スクリプトにおいて提供される、方法。
【請求項17】
請求項14ないし16のうちの何れか一項に記載の方法において、前記記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンス、前記プロトコル・フラグ、前記任意的公開鍵（DPK）、及び／又は前記任意的トランザクションID（DTxID）は、前記トランザクション内において、以後のトランザクションに対するインプットとして以後使用することについて、アウトプットを無効としてマーキングするスクリプト・オペコードに続く位置で提供される、方法。
【請求項18】
請求項14ないし17のうちの何れか一項に記載の方法において：前記トランザクション（Tx）は、1つ以上の属性を更に有し；好ましくは：
前記1つ以上の属性は：
i）前記トランザクション（Tx）内で提供又は参照されるデータの部分；及び／又は
ii）前記トランザクション（Tx）；
に関連付けられるキーワード、タグ、又は識別子を有する、方法。
【請求項19】
請求項13ないし17のうちの何れか一項に記載の方法において、前記トランザクション（Tx）は、更に：論理ペアレント・トランザクション（LPTx）に関連するペアレント公開鍵（PPK）を有し、前記論理ペアレント・トランザクション（LPTx）は、前記任意的トランザクションID（DTxID）によって識別され；及び
前記シグネチャは前記ペアレント公開鍵（PPK）を用いて生成される、方法。
【請求項20】
請求項13ないし18のうちの何れか一項に記載の方法において、更に：前記任意的公開鍵（DPK）及び前記トランザクションID（TxID）を用いて、ブロックチェーンにおける前記トランザクション（Tx）又は前記論理ペアレント・トランザクションを識別するステップを含む方法。
【請求項21】
請求項14ないし20のうちの何れか一項に記載の方法において、前記プロトコル・フラグは、1つ以上のブロックチェーン・トランザクションにおけるデータを探索する、格納する、及び／又は抽出するためのブロックチェーン・ベースのプロトコルに関連する及び／又は示す、方法。
【請求項22】
コンピュータ装置であって：1つ以上のメモリ・ユニットを有するメモリ；及び
1つ以上の処理ユニットを有する処理装置；
を備え、前記メモリは、前記処理装置において動作するように構成されたコードを記憶し、前記コードは、前記処理装置上にある場合に、請求項1ないし21のうちの何れか一項に記載の方法を実行するように構成されている、コンピュータ装置。
【請求項23】
請求項22に記載のコンピュータ装置において：i）ブロックチェーン・ネットワーク及び／又はブロックチェーンで実行されるシステムであるか、又はそのように構成されているか、又はそれらと相互作用するように動作し；及び／又は
ii）ハードウェア・ウォレットを有する、コンピュータ装置。
【請求項24】
コンピュータ読み取り可能な記憶装置に組み込まれたコンピュータ・プログラムであって、1つ以上のプロセッサ上で動作すると、請求項1ないし21のうちの何れか一項に記載の方法を実行するように構成されているコンピュータ・プログラム。
【請求項25】
請求項1ないし21のうちの何れか一項に記載のブロックチェーンで実行される方法であって：請求項1ないし21のうちの何れか一項に記載の方法を実行するために、ハードウェア及び／又はソフトウェアの構成要素を用いるか又は提供するステップを含み；
前記ハードウェア及び／又はソフトウェアの構成要素は：
暗号通貨ウォレット；
サーチ・エンジン；
ブロックチェーン・エクスプローラ；又は
ブラウザ
であるか又はそれらを有し、好ましくは、前記構成要素は簡易支払検証（SPV）処理を実行するように動作可能である、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、セキュリティ及び検証方法及びシステムに関連し、特に、ブロックチェーン・トランザクションに関して実行されるセキュリティ及び検証処理に関連する。
【背景技術】
【0002】
ブロックチェーンとは、分散されたデータ構造の形態を指し、ブロックチェーンの重複したコピーが、分散されたピア・ツー・ピア（peer-to-peer，P2P）ネットワーク（以下、「ブロックチェーン・ネットワーク」と言及される）内の複数のノードの各々において維持され且つ広く公表されているものである。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、1つ以上のトランザクションを含む。いわゆる「コインベースのトランザクション」（coinbase transactions）以外の各トランザクションは、シーケンス内の先行するトランザクションを後方から指し示し、そのシーケンスは、1つ以上のコインベースのトランザクションに戻る1つ以上のブロックにわたる可能性がある。コインベース・トランザクションについては以下で更に説明される。ブロックチェーン・ネットワークにサブミットされたトランザクションは、新しいブロックに含まれる。新しいブロックは、しばしば「マイニング（mining）」と呼ばれるプロセスによって生成され、これは、「プルーフ・オブ・ワーク（proof-of-work）」を実行する、即ちブロックチェーンの新しいブロックに含まれることを待機している順序付けられ且つ検証されたペンディング・トランザクションの所定のセットの表現に基づいて暗号パズルを解決する、競合する複数のノードの各々に関わる。ブロックチェーンは一部のノードで刈り取られる（pruned）可能性があり、ブロックの公表は単なるブロック・ヘッダの公表によって達成できる、ということに留意すべきである。
【0003】
ブロックチェーン内のトランザクションは、以下の目的のうちの1つ以上のために使用される可能性がある：デジタル資産（即ち、幾つかのデジタル・トークン）を伝達すること、仮想化された台帳又はレジストリ内のエントリのセットを注文すること、タイムスタンプ・エントリを受信及び処理すること、及び/又は、インデックスポインタを時間順にすること。ブロックチェーンは、ブロックチェーンのトップに追加の機能を階層化するために利用されることも可能である。例えば、ブロックチェーン・プロトコルは、トラザクションにおいて、データに対するインデックス又は追加的なユーザー・データを格納することを許容することが可能である。単一トランザクション内に格納することが可能な最大データ容量には事前に指定された制限がなく、従って、より複雑なデータをますます組み込むことが可能である。例えば、これは、ブロックチェーンに電子文書を、又はオーディオ又はビデオ・データを格納するために使用される可能性がある。
【0004】
ブロックチェーン・ネットワークのノード（しばしば「マイナー（miners）」と呼ばれる）は、分散されたトランザクションの登録と検証のプロセスを実行し、これらについては更に後述される。要するに、このプロセスの間に、ノードはトランザクションを検証し、それらをブロック・テンプレートに挿入し、それについて彼らは有効なプルーフ・オブ・ワークの解を特定することを試みる。いったん有効な解が発見されると、新たなブロックがネットワークの他のノードに伝搬され、各ノードは、新たなブロックをブロックチェーンに記録できるようになる。トランザクションをブロックチェーンに記録させるために、ユーザー（例えば、ブロックチェーン・クライアント・アプリケーション）は、伝搬されるべきネットワークのノードのうちの1つへトランザクションを送信する。トランザクションを受信するノードは、検証されたトランザクションを新たなブロックに組み込むプルーフ・オブ・ワークの解を発見するために競うことが可能である。各ノードは、同じノード・プロトコルを強制するように設定されており、このプロトコルは、トランザクションが有効であるための1つ以上の条件を含むであろう。無効なトランザクションは、ブロックに伝搬されず、組み込まれることもない。トランザクションが検証され、それによってブロックチェーンに受け入れられたと仮定すると、トランザクション（任意のユーザー・データを含む）は、ブロックチェーン・ネットワークにおける各ノードで、変更不可能な公的なレコードとして登録され且つインデックス付けされたまま残るであろう。
【0005】
プルーフ・オブ・ワーク・パズルを解くことに成功して最新のブロックを作成したノードは、典型的には、ある数量のデジタル資産、即ち、幾らかのトークンを分配する「コインベース・トランザクション」と呼ばれる新たなトランザクションによって報酬を受ける。無効なトランザクションの検出と拒否は、ネットワークのエージェントとして動作し、不正行為を報告及びブロックするインセンティブを得ている競合するノードの動作によって規制される。情報の幅広い公表は、ユーザーが、ノードのパフォーマンスを継続的に監査することを可能にする。単なるブロック・ヘッダの公表は、参加者が、ブロックチェーンの継続的な完全性を保証することを許容する。
【0006】
「アウトプット・ベース」モデル（しばしば、UTXOベース・モデルとも呼ばれる）では、所与のトランザクションのデータ構造は、1つ以上のインプットと1つ以上のアウトプットとを含む。何らかの使用可能なアウトプットは、トランザクションの処理シーケンスから導出可能なデジタル資産の数量を指定する要素を含む。使用可能なアウトプットは、UTXO（“unspent transaction output”）としばしば言及される。アウトプットは、アウトプットの将来の償還（redemption）のための条件を指定するロッキング・スクリプトを更に含むことが可能である。ロッキング・スクリプトは、デジタル・トークン又は資産を検証及び転送するために必要な条件を定義するプレディケート（predicate）である。（コインベース・トランザクション以外の）トランザクションの各インプットは、先行するトランザクションにおけるそのようなアウトプットを指すポインタ（即ち、リファレンス）を含み、更に、指し示されたアウトプットのロッキング・スクリプトをロック解除するためのアンロッキング・スクリプトを含む可能性がある。そこで、トランザクションのペアを考え、それらを第1及び第2のトランザクション（又は「ターゲット」トランザクション）と呼ぶことにする。第1のトランザクションは、デジタル資産の数量を指定する少なくとも1つのアウトプットを含み、アウトプットをロック解除する1つ以上の条件を定義するロッキング・スクリプトを含む。第2のターゲット・トランザクションは、第1のトランザクションのアウトプットに対するポインタと、第1のトランザクションのアウトプットをロック解除するためのアンロッキング・スクリプトとを含む、少なくとも1つのインプットを含む。
【0007】
このようなモデルにおいて、第2のターゲット・トランザクションがブロックチェーン・ネットワークへ送信されて、ブロックチェーン内で伝搬されて記録される場合に、各ノードで適用される有効性に関する条件のうちの或るものは、アンロッキング・スクリプトが、第1のトランザクションのロッキング・スクリプトで定義された1つ以上の条件の全てを充足することであろう。別のものは、第1のトランザクションのアウトプットが、別の先行する有効なトランザクションによって既に償還されてはいない、ということであろう。これらのうちの何れかの条件によってターゲット・トランザクションが無効であることを発見した如何なるノードも、それを伝搬せず（有効なトランザクションとして伝搬せず、おそらくは無効なトランザクションを登録する）、ブロックチェーンに記録される新たなブロックに含められることもない。
【0008】
別のタイプのトランザクション・モデルは、アカウント・ベース・モデルである。この場合、各トランザクションは、移転されるべき分量を、過去のトランザクションのシーケンスで先行するトランザクションのUTXOを参照することによってではなく、むしろ絶対的なアカウント残高を参照することによって定める。全てのアカウントの現在の状態は、ブロックチェーンに対してノードによって個々に保存され、絶えず更新される。
【0009】
上述したように、これらのブロックチェーン・モデル及びそれらの関連するプロトコルは、基本的な前提とするプラットフォームを形成するために使用されることが可能であり、そのプラットフォームにおいて、追加の機能を提供するために複雑なアプリケーション及びシステムを構築することが可能である。その結果、ブロックチェーンで実施される技術を使用して、暗号通貨の転送を越える、より広範囲に及ぶ技術的恩恵を提供することができる。ブロックチェーン及びその関連するプロトコルを、基本メカニズムとして使用する多数のより高レベルのアプリケーションが開発されており、その基本メカニズムは、トークン化された資産のようなデータやリソースの記憶及び転送を可能にする。1つのそのような例は、データを記憶し、構造化し、索引付けし、共有するために従来のインターネットに対してブロックチェーン・ベースの代替を提供する「メタネット（Metanet）」である。メタネット・プロトコルは、基本ブロックチェーン・ネットワーク及び関連するプロトコルのトップに位置する（https://bitcoinsv.io/wp-content/uploads/2020/10/The-Metanet-Technical-Summary-v1.0.pdf）。
【0010】
そのようなブロックチェーンで実施される技術は、それらが転送及び処理しているデータが、認可された者によってのみアクセスされること、及び、それらが悪意のある者によって、潜在的なセキュリティ脆弱性又は悪用に対してオープンにされていないこと、を保証する必要がある。従って、ブロックチェーン上に構築されるデータ指向アプリケーション及びシステムによって利用されることが可能な、安全で柔軟性のある効率的な検証技術に対するニーズが存在する。
【発明の概要】
【0011】
本件で開示される一態様によれば、基礎となるブロックチェーンのトップに実装されるデータ・アプリケーションによって有用に利用されることが可能なシグネチャ検証技術が提供される。そのようなアプリケーションは、時折、ブロックチェーンにおいてトランザクション内にデータを格納し、そのデータに関するシグネチャ検証（signature verification）が、その完全性（integrity）を保証するため、また、悪用や不正行為を防止するために必須である。しかしながら、シグネチャ検証は、基礎となるブロックチェーンのプロトコルに従ってトランザクション・レベルで実行されるが、このメカニズムは、データがトランザクション内にしばしば格納される方法に起因して、及び基礎となるブロックチェーン・プロトコルが、トランザクションの外で提供されるデータを含む署名されたメッセージの検証を必要とすることに起因して、データ・アプリケーション・レベルでの検証には、時折、不十分である。更に、ブロックチェーン・プロトコルは、典型的には、特定のシグネチャ方式の使用を必要とし、これは、特定のデータ指向の実装において制限的であったり又は望ましくなかったりする可能性がある。
【0012】
本開示の実施形態は、データ・アプリケーション（複数可）によって使用されるシグネチャを、入力のアンロッキング・スクリプトから、アウトプットのようなトランザクション内の何処かに再配置し、且つ、ビットコイン・スクリプト・エンジンを使用してビットコイン・ネットワークのノードによって検証されるシグネチャに関する要件を除去することによって、少なくともこれらの技術的課題を克服する。幾つかの実施形態において、シグネチャは、潜在的にはOP_RETURNのようなスクリプトの評価を終了するコマンドの後に、アウトプットのロッキング・スクリプトに移されることが可能である。シグネチャは、メッセージが配置されるトランザクションを一意に識別するデータを含むメッセージに署名することによって提供されてもよく、従って、シグネチャをトランザクションに結び付け又は関連付け、潜在的な悪用の回避を可能にする。更に、基礎となるブロックチェーン・プロトコルのシグネチャ検証メカニズムとは異なる検証技術を提供することによって、特定のシグネチャ式の使用に関する制限を回避することができる。また、処理やエネルギー要件のようなマイナーのリソースは検証に必要とされないので、効率向上性も獲得することが可能である。
【図面の簡単な説明】
【0013】
本開示の実施形態の理解を支援し、そのような実施形態がどのように実施され得るかを示すために、単なる例として、添付の図面に対する参照が行われる。
【発明を実施するための形態】
【0014】
例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク101を含む可能性がある。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピア・ツー・ピア（P2P）ネットワーク106を形成するように構成される可能性のある複数のブロックチェーン・ノード104を含む。図示されていないが、ブロックチェーン・ノード104は、ほぼ完全なグラフとして配置されてもよい。従って、各ブロックチェーン・ノード104は、他のブロックチェーン・ノード104に高度に接続されている。
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク101を含む可能性がある。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピア・ツー・ピア（P2P）ネットワーク106を形成するように構成される可能性のある複数のブロックチェーン・ノード104を含む。図示されていないが、ブロックチェーン・ノード104は、ほぼ完全なグラフとして配置されてもよい。従って、各ブロックチェーン・ノード104は、他のブロックチェーン・ノード104に高度に接続されている。
【0015】
各ノード104はピアのコンピュータ装置を含み、ノード104のうちの異なるものは異なるピアに属する。各ブロックチェーン・ノード104は、1つ以上のプロセッサ、例えば1つ以上の中央処理ユニット（CPU）、アクセラレータ・プロセッサ、アプリケーション特有のプロセッサ及び/又はフィールド・プログラマブル・ゲート・アレイ（FPGA）、及び、特定用途向け集積回路（ASIC）のような他の装置を含む処理装置を含む。各ノードはまた、メモリ、即ち、非一時的コンピュータ読み取り可能な媒体又はメディアの形態でコンピュータ読み取り可能なストレージを含む。メモリは、1つ以上のメモリ媒体、例えば、ハード・ディスクのような磁気媒体；ソリッド・ステート・ドライブ（SSD）、フラッシュ・メモリ又はEEPROMのような電子媒体；及び/又は光ディスク・ドライブのような光媒体、を使用する1つ以上のメモリ・ユニットを含んでもよい。
【0016】
ブロックチェーン150は、データ151のブロックのチェーンを含み、ブロックチェーン150のそれぞれのコピーは、分散型の又はブロックチェーン・ネットワーク106内の複数のブロックチェーン・ノード104のそれぞれで維持されている。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150を完全に記憶することを意味しない。むしろ、ブロックチェーン150は、各ブロックチェーン・ノード150が各ブロック151のブロック・ヘッダ（以下で説明される）を格納している限り、データのプルーニング（pruned）を行ってもよい。チェーン内の各ブロック151は、1つ以上のトランザクション152を含み、ここで、この文脈におけるトランザクションは、一種のデータ構造を指す。データ構造の性質は、トランザクション・モデル又は方式の一部として使用されるトランザクション・プロトコルのタイプに依存するであろう。所与のブロックチェーンは、全体を通じて1つの特定のトランザクション・プロトコルを使用するであろう。1つの一般的なタイプのトランザクション・プロトコルでは、各トランザクション152のデータ構造は、少なくとも1つのインプットと少なくとも1つのアウトプットとを含む。各々のアウトプットは、ある量のデジタル資産をプロパティ（property）として表す数量を指定し、その具体例は、ユーザー103であり、そのユーザー宛てにアウトプットが暗号的にロックされているものである（ロック解除され、それにより償還又は消費されるためにはそのユーザーのシグネチャ又はその他の解を必要とする）。各インプットは、先行するトランザクション152のアウトプットを後方から指し示し、それによって、トランザクションを結び付ける。
【0017】
各ブロック151は、また、ブロック151に至るシーケンシャルな順序を規定するように、チェーン内で先に生成されたブロック151へ戻るブロック・ポインタ155を含む。各トランザクション152（コインベース・トランザクション以外）は、トランザクションのシーケンスに対する順序を定義するために、前のトランザクションへ戻るポインタを含む（N.B.トランザクション152のシーケンスは分岐することが許容されている）。ブロック151のチェーンは、全て、チェーンの最初のブロックであったジェネシス・ブロック（genesis block，Gb）153に戻る。チェーン150にある早期の1つ以上のオリジナル・トランザクション152は、先行するトランザクションではなく、ジェネシス・ブロック153を指し示していた。
【0018】
ブロックチェーン・ノード104の各々は、トランザクション152を他のブロックチェーン・ノード104へ転送するように構成されており、それによって、トランザクション152は、ネットワーク106全体に伝搬される。各ブロックチェーン・ノード104は、ブロック151を生成し、同じブロックチェーン150のそれぞれのコピーを、それぞれのメモリに格納するように構成される。また、各ブロックチェーン・ノード104は、ブロック151に組み込まれることを待機しているトランザクション152の順序付けられたセット（又は「プール」）154も維持している。順序付けられたプール154は、しばしば「メンプール（mempool）」と呼ばれる。本件におけるこの用語は、何らかの特定のブロックチェーン、プロトコル又はモデルに限定するようには意図されていない。これは、ノード104が有効として受け入れたトランザクションであって、ノード104が同じアウトプットを消費しようとする如何なる他のトランザクションも受け入れないように義務付けられたトランザクションの順序付けられたセットを指す。
【0019】
所与の現在のトランザクション152jにおいて、その（又は各々の）インプットは、トランザクションのシーケンスにおいて先行するトランザクション152iのアウトプットを参照するポインタを含み、それは、このアウトプットが現在のトランザクション152jにおいて償還されるか、又は「消費される」予定であることを指定する。一般に、先行するトランザクションは、順序付けられたセット154又は任意のブロック151内の任意のトランザクションであるとすることが可能である。先行するトランザクション152iは、現在のトランザクション152jが作成される時点、又はネットワーク106へ送信される時点においてさえ必ずしも存在することを必要としないが、先行するトランザクション152iは、現在のトランザクションが有効であるとされるためには、存在して検証されることを必要とする。従って、本件において「先行する（preceding）」とは、ポインタによってリンクされた論理的な順序における先行を指し、必ずしも時間的な順序における作成又は送信の時間であるとは限らず、従って、トランザクション152i、152jが順番通りではく作成又は送信されることを必ずしも排除していない（孤立トランザクションに関する以下の説明を参照されたい）。先行するトランザクション152iは、同様に、先立つトランザクション又は先行トランザクションと呼ぶことができる。
【0020】
現在のトランザクション152jのインプットは、インプット認可（input authorisation）、例えば、先行するトランザクション152iのアウトプットがロックされている対象者のユーザー103aの署名も含む。次いで、現在のトランザクション152jのアウトプットは、新しいユーザー又はエンティティ103bに暗号的にロックされることが可能である。従って、現在のトランザクション152jは、先行するトランザクション152iのインプットで定められている数量を、現在のトランザクション152jのアウトプットで定められている新しいユーザー又はエンティティ103bへ転送することが可能である。ある場合には、トランザクション152は、複数のユーザー又はエンティティ間で入力量を分割するために、複数のアウトプットを有する可能性がある（それらのうちの1つは、釣り銭（change）をもたらすためにオリジナル・ユーザー又はエンティティ103aであるとすることが可能である）。場合によっては、トランザクションは複数のインプットを有し、1つ以上の先行するトランザクションの複数のアウトプットからの分量を集め、現在のトランザクションの1つ以上のアウトプットへ分配し直すことも可能である。
【0021】
ビットコインのようなアウトプット・ベースのトランザクション・プロトコルによれば、個人的なユーザー又は組織のような者103が、（マニュアルで又はその者によって使用される自動プロセスによって）新たなトランザクション152jを制定することを望む場合、制定する者（enacting party）は、新たなトランザクションをそのコンピュータ端末102から受信側へ送信する。制定する者又は受信側は、最終的には、このトランザクションをネットワーク106の1つ以上のブロックチェーン・ノード104へ送信する（今日では、通常、サーバー又はデータ・センターであるが、原理的には、他のユーザー端末であるとすることが可能である）。また、新たなトランザクション152jを制定する者103は、トランザクションを1つ以上のブロックチェーン・ノード104へ、直接的に送信することが可能であり、一部の例では、受信側に対してではないことも除外されない。トランザクションを受信するブロックチェーン・ノード104は、各ブロックチェーン・ノード104に適用されるブロックチェーン・ノード・プロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーン・ノード・プロトコルは、典型的には、新たなトランザクション152jにおける暗号署名が、期待される署名（であって、トランザクション152の順序付けられたシーケンスにおける前のトランザクション152iに依存する署名）と一致することをチェックするように、ブロックチェーン・ノード104に要求する。このようなアウトプット・ベースのトランザクション・プロトコルでは、それは、新たなトランザクション152jのインプットに含まれている者103の暗号署名又はその他の認可が、新たなトランザクションが指定している前のトランザクション152iのアウトプットで定められている条件に合致することをチェックすることを含む可能性があり、この条件は、典型的には、新たなトランザクション152jのインプットにおける暗号署名又はその他の認可が、新たなトランザクションのインプットがリンクされている先行するトランザクション152iのアウトプットをロック解除すること、を少なくともチェックすることを含む。この条件は、先行するトランザクション152iのアウトプットに含まれるスクリプトによって、少なくとも部分的に定義されてもよい。代替的に、単純にブロックチェーン・ノード・プロトコルだけで固定されることが可能であり、あるいは、これらの組み合わせによることも可能である。いずれにせよ、新たなトランザクション152jが有効である場合に、ブロックチェーン・ノード104は、ブロックチェーン・ネットワーク106内の1つ以上の他のブロックチェーン・ノード104にそれを転送する。これらの他のブロックチェーン・ノード104は、同じブロックチェーン・ノード・プロトコルに従って同じテストを適用し、従って、新たなトランザクション152jを1つ以上の更なるノード104等に転送する。このようにして、新たなトランザクションは、ブロックチェーン・ノード104のネットワーク全体に伝搬される。
【0022】
アウトプット・ベース・モデルでは、所与のアウトプット（例えば、UTXO）が指定されるか（例えば、消費されるか）どうかの定義は、ブロックチェーン・ノード・プロトコルに従って、別の前方トランザクション152jのインプットによってこれから有効に償還されるかどうかである。トランザクションが有効であるための別の条件は、償還を試みる先行トランザクション152iのアウトプットが、別のトランザクションによって既に償還されてはいないことである。また、それが有効でない場合、トランザクション152jは、（無効としてフラグが付けられ、警告のために伝搬されるのでない限り）伝搬されず、ブロックチェーン150に記録されないであろう。これは、二重の支出により、取引主体が同じトランザクションのアウトプットを複数回指定しようとすることから防ぐ。一方、アカウント・ベース・モデルは、アカウントの残高を維持することによって、二重の支出を防ぐ。この場合も、トランザクションの定められた順序が存在するので、アカウントの残高は、任意の時点で単一の定められた状態を有する。
【0023】
トランザクションを検証することに加えて、ブロックチェーン・ノード104は、「プルーフ・オブ・ワーク」によってサポートされる、一般にマイニングと呼ばれるプロセスにおいてトランザクションのブロックを最初に作成するために競い合う。ブロックチェーン・ノード104では、ブロックチェーン150に記録されたブロック151にまだ現れていない、有効なトランザクションの順序付けられたプール154に、新たなトランザクションが追加される。次いで、ブロックチェーン・ノードは、暗号パズルを解くことを試みることによって、トランザクション152の順序付けられたセット154から、トランザクションの新しい有効なブロック151を組み立てるために競い合う。典型的には、これは「ナンス（nonce）」値を探すことを含み、そのために、ナンスが保留中のトランザクションの順序付けられたプール154の表現に連結され、ハッシュ化され、かくて、ハッシュの出力が所定の条件を満たすようにする。例えば、所定の条件は、ハッシュの出力が、所定数の先行するゼロを有することであってもよい。これはプルーフ・オブ・ワーク・パズルの特定のほんの一例であるに過ぎず、他のタイプが除外されていないことに留意されたい。ハッシュ関数の特性は、その入力に対して予測不能な出力を有することである。従って、この探索は、ブルート・フォースによってのみ実行することが可能であり、従って、パズルを解こうとしている各ブロックチェーン・ノード104において、かなりの量の処理リソースを消費する。
【0024】
パズルを解いた最初のブロックチェーン・ノード104は、それをネットワーク106へ通知し、その解を証明（proof）として提供し、次いでその証明はネットワーク内の他のブロックチェーン・ノード104によって容易にチェックすることができる（ハッシュに対する解が与えられると、それがハッシュの出力を条件に合致させることをチェックすることは容易である）。最初のブロックチェーン・ノード104は、ブロックを受け入れる他のノードの閾値コンセンサスのためにブロックを伝搬させ、従って、プロトコル規則を実施する。次いで、トランザクションの順序付けられたセット154は、ブロックチェーン・ノード104の各々によって、ブロックチェーン150内の新しいブロック151として記録されるようになる。ブロック・ポインタ155はまた、新たなブロック151nにも割り当てられ、チェーン内の先に生成されたブロック151n-1の地点を指す。プルーフ・オブ・ワークの解を作成するために必要とされる、例えばハッシュの形式でのかなりの労力は、第1のノード104が、ブロックチェーン・プロトコルのルールに従うことを意図する引き金となる。そのようなルールは、以前に検証されたトランザクションと同じアウトプットをそれが割り当てている場合に、トランザクションを有効として受け入れないことを含み、あるいは二重支払として理解される。いったん生成されると、ブロック151は修正することができず、なぜなら、ブロックチェーン・ネットワーク106内のブロックチェーン・ノード104の各々でそれが認識されて維持されるからである。ブロック・ポインタ155はまた、ブロック151に逐次的な順序も課している。トランザクション152は、ネットワーク106内の各ブロックチェーン・ノード104において順序付けられたブロックに記録されるので、従ってこれは、トランザクションの変更不能な公の台帳を提供する。
【0025】
任意の所与の時間にパズルを解くために競い合う様々なブロックチェーン・ノード104は、それらがいつ解を探索し始めたかに応じて、又はトランザクションが受信された順序に応じて、任意の所与の時間におけるこれから公表されることになるトランザクション154のプールの様々なスナップ・ショットに基づいて、そのようにすることができることに留意されたい。それぞれのパズルを最初に解いた者が誰であれ、どのトランザクション152が次の新しいブロック151nにどの順序で含まれるのかを定め、未公表のトランザクションの現在のプール154が更新される。次いで、ブロックチェーン・ノード104は、未公表のトランザクション154の新たに定められた順序付けられたプールから、ブロックを生成する等のために競い続ける。また、生じる可能性のある「フォーク」を解決するためのプロトコルも存在し、これは、2つのブロックチェーン・ノード104が相次いで非常に短時間の間に彼らのパズルを解いて、その結果、ブロックチェーンの矛盾した状態（view）がノード104の間で伝播してゆくことである。要するに、フォークのどちらの突起が伸びても、最も長い方が最終的なブロックチェーン150となる。このことは、同じトランザクションが両方のフォークに現れることになるので、ネットワークのユーザー又はエージェントに影響を与えないはずであることに留意されたい。
【0026】
ビットコイン・ブロックチェーン（及び他のほとんどのブロックチェーン）によれば、新たなブロック104を首尾良く構築するノードは、デジタル資産の追加の定義された量を分配する新しい特殊な種類のトランザクションにおいて、デジタル資産の追加の受け入れられた量を新たに割り当てる能力を付与される（エージェント間、又はユーザー間のトランザクションであって、デジタル資産の分量をあるエージェント又はユーザーから他者へ転送するためのものとは対照的である）。この特殊なタイプのトランザクションは、通常、「コインベース・トランザクション」と呼ばれるが、「開始トランザクション」又は「生成トランザクション」とも呼ばれる場合もある。これは、典型的には、新たなブロック151nの最初のトランザクションを形成する。プルーフ・オブ・ワークは、新たなブロックを構築し、プロトコル規則に従って、この特別なトランザクションが後に償還されることをノードが意図する引き金となる。ブロックチェーン・プロトコル規則は、この特別なトランザクションが償還される前に、例えば100ブロックの成熟期間を必要とする可能性がある。しばしば、通常の（ジェネレーションではない）トランザクション152は、そのトランザクションが発行されたブロック151nを生成したブロックチェーン・ノード104に更に報酬を与えるために、そのアウトプットの1つにおいて追加のトランザクション手数料を指定するであろう。この手数料は、通常「取引手数料」と呼ばれ、以下で説明される。
【0027】
トランザクションの検証及び公表に関わるリソースに起因して、典型的には、ブロックチェーン・ノード104のうちの各々は少なくとも、1つ以上の物理的なサーバー・ユニット、又はデータ・センター全体さえも含むサーバーの形態をとる。しかしながら、原理的には、所与の任意のブロックチェーン・ノード104は、ユーザー端末又は互いにネットワーク接続されたユーザー端末のグループ、の形態をとることができる。
【0028】
各ブロックチェーン・ノード104のメモリは、それぞれの1つの役割又は複数の役割を実行し、ブロックチェーン・ノード・プロトコルに従ってトランザクション152を処理するために、ブロックチェーン・ノード104の処理装置において動作するように構成されたソフトウェアを記憶する。本件において、ブロックチェーン・ノード104に帰属される任意の動作は、それぞれのコンピュータ装置の処理装置上で実行されるソフトウェアによって実行されてもよい、ということが理解されるであろう。ノード・ソフトウェアは、アプリケーション・レイヤにおいて、オペレーティング・システム・レイヤ、プロトコル・レイヤのような下位レイヤにおいて、又はこれらの任意の組み合わせにおいて、1つ以上のアプリケーションに実装されてもよい。
【0029】
また、ネットワーク101に接続されるものには、消費するユーザーの役割を果たす複数の者103の各々のコンピュータ装置102もある。これらのユーザーは、ブロックチェーン・ネットワーク106とやり取りを行うことが可能であるが、トランザクションを検証したり又はブロックを構築したりすることには参加しない。これらのユーザー又はエージェント103のうちの一部は、トランザクションの送信者及び受信者として動作する可能性がある。他のユーザーは、必ずしも送信者又は受信者として動作することなく、ブロックチェーン150とやり取りを行うことが可能である。例えば、一部の者は、ブロックチェーン150のコピーを記憶する記憶エンティティとして機能する可能性がある（例えば、ブロックチェーン・ノード104から、ブロックチェーンのコピーを取得する）。
【0030】
当事者103の一部又は全部は、例えばブロックチェーン・ネットワーク106のトップにオーバーレイされるネットワークのような、異なるネットワークの一部として接続されてもよい。ブロックチェーン・ネットワークのユーザー（しばしば「クライアント」と呼ばれる）は、ブロックチェーン・ネットワーク106を含むシステムの一部と言うことは可能であるが；これらのユーザーは、ブロックチェーン・ノードに要求される役割を実行しないので、ブロックチェーン・ノード104ではない。むしろ、各当事者103は、ブロックチェーン・ネットワーク106とやり取りを行うことが可能であり、それによってブロックチェーン・ノード104に接続する（即ち、通信する）ことによって、ブロックチェーン150を利用することができる。2人の当事者103及びそれぞれの装置102は、説明のために示されており；第1の者103a及び彼／彼女のそれぞれのコンピュータ装置102a、並びに第2の者103b及び彼／彼女のそれぞれのコンピュータ装置102bである。より多くのこのような者103及び各自それぞれのコンピュータ装置102が、システム100に存在し、参加する可能性があるが、便宜上、それらは図示されていないことが理解されるであろう。各当事者103は、個人又は組織である可能性がある。純粋に例示として、第1の者103aは、本件においてアリス（Alice）と称され、第2の者103bは、ボブ（Bob）と称されるが、これは限定ではないこと、及び本件においてアリス又はボブという如何なる言及も、それぞれ「第1の者」及び「第2の者」と置き換えられてよいことが、理解されるであろう。
【0031】
各当事者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つ以上の他のネットワーク化されたリソースを含んでもよい。
【0032】
クライアント・アプリケーション105は、最初に、適切なコンピュータ読み取り可能な記憶媒体又はメディアにおいて任意の所与の当事者103のコンピュータ装置102に提供されてもよく、例えば、サーバーからダウンロードされ、又はリムーバブルSSD、フラッシュ・メモリ・キー、リムーバブルEEPROM、リムーバブル磁気ディスク・ドライブ、磁気フロッピー・ディスク又はテープ、CD又はDVD ROMのような光ディスク、又はリムーバブル光学ドライブ等のような、リムーバブル記憶デバイスに提供されてもよい。
【0033】
クライアント・アプリケーション105は、少なくとも「ウォレット（wallet）」機能を含む。これは主に2つの機能を有する。これらのうちの1つは、それぞれの当事者103が、トランザクション152を作成し、認可し（例えば、署名し）、1つ以上のビットコイン・ノード104へ送信して、ブロックチェーン・ノード104のネットワーク全体にわたって伝搬させ、それによってブロックチェーン150に含められることを可能にすることである。もう1つは、彼又は彼女が現在所有しているデジタル資産の分量をそれぞれの当事者に報告することである。アウトプット・ベース・システムでは、この第2の機能は、対象の当事者に属するブロックチェーン150全体に散在する様々なトランザクション152のアウトプットで定められる分量を照合することを含む。
【0034】
注記：様々なクライアント機能は、所与のクライアント・アプリケーション105に統合されているように述べられるかもしれないが、これは必ずしも限定ではなく、むしろ本件で説明される何れのクライアント機能も、例えば、APIを介したインターフェースにより、又は一方が他方に対するプラグ・インであることにより、2つ以上の別個のアプリケーションの一式で実装されてもよい。より一般的には、クライアント機能は、アプリケーション・レイヤ、又はオペレーティング・システムのような下位レイヤ、又はこれらの任意の組み合わせで実装されることが可能である。以下、クライアント・アプリケーション105に関して説明されるが、これは限定的ではないことが理解されるであろう。
【0035】
各コンピュータ装置102におけるクライアント・アプリケーション又はソフトウェア105のインスタンスは、ネットワーク106のブロックチェーン・ノード104の少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能が、トランザクション152をネットワーク106に送信することを可能にする。また、クライアント105は、ブロックチェーン・ノード104に連絡をとり、トランザクションの当事者103が受信者である何らかのトランザクションについて、ブロックチェーン150を照会することもできる（あるいは、実際、ブロックチェーン150内の他の当事者のトランザクションを検査し、なぜなら、実施形態において、ブロックチェーン150は、部分的に公衆の可視性によりトランザクションに信頼性を提供する公の施設であるからである）。各コンピュータ装置102におけるウォレット機能は、トランザクション・プロトコルに従ってトランザクション152を形成して送信するように構成される。上述したように、各ブロックチェーン・ノード104はソフトウェアを実行し、そのソフトウェアは、ブロックチェーン・ノード・プロトコルに従ってトランザクション152を検証し、トランザクション152を転送して、それらをブロックチェーン・ネットワーク106全体に伝播させるように構成されている。トランザクション・プロトコルとノード・プロトコルは互いに対応しており、所与のトランザクション・プロトコルは、所与のノード・プロトコルと共に所与のトランザクション・モデルを実装して行く。同じトランザクション・プロトコルが、ブロックチェーン150内の全てのトランザクション152に使用される。同じノード・プロトコルが、ネットワーク106内の全てのノード104によって使用される。
【0036】
所与の当事者103、例えばアリスが、ブロックチェーン150に含まれるように新たなトランザクション152jを送信することを望む場合、彼女は、関連するトランザクション・プロトコルに従って（彼女のクライアント・アプリケーション105におけるウォレット機能を使用して）新たなトランザクションを形成する。次いで、彼女は、トランザクション152を、クライアント・アプリケーション105から、彼女がつながっている1つ以上のブロックチェーン・ノード104へ送信する。例えば、これは、アリスのコンピュータ102に最良に接続されているブロックチェーン・ノード104である可能性がある。何らかの所与のブロックチェーン・ノード104が新たなトランザクション152jを受信すると、それはブロックチェーン・ノード・プロトコル及び各自の役割に従ってそれを処理する。これは、最初に、新たに受信したトランザクション152jが「有効」であるための特定の条件を充足するかどうかをチェックすることを含み、その事例が間もなくより詳細に説明される。幾つかのトランザクション・プロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによってピア・トランザクション・ベースで設定可能であってもよい。代替的に、条件は単にノード・プロトコルの組み込み機能であってもよいし、あるいはスクリプトとノード・プロトコルの組み合わせによって定められてもよい。
【0037】
新たに受信されたトランザクション152jが、有効であると認められるテストに合格するという条件の下で（即ち、「有効化されている（検証済み）」という条件の下で）、トランザクション152jを受信した何らかのブロックチェーン・ノード104は、新たな検証されたトランザクション152を、そのブロックチェーン・ノード104で維持されているトランザクション154の順序付けられたセットに追加するであろう。更に、トランザクション152jを受信する任意のブロックチェーン・ノード104は、検証済みトランザクション152を、ネットワーク106内の1つ以上の他のブロックチェーン・ノード104へ伝搬させて行くであろう。各ブロックチェーン・ノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、ネットワーク106全体に間もなく伝搬されるであろう、ということを意味する。
【0038】
所与のブロックチェーン・ノード104で維持される保留中のトランザクションの順序付けられたプール154に対していったん認められると、そのブロックチェーン・ノード104は、新たなトランザクション152を含むそれぞれのプール154の最新バージョンに関して、プルーフ・オブ・ワーク・パズルを解く競争を開始するであろう（他のブロックチェーン・ノード104は、トランザクション154の異なるプールに基づいてパズルを解くことを試みるかもしれないが、そこに最初に到達した者は誰であれ、最新のブロック151に含まれるトランザクションのセットを定義するであろう、ということを想起されたい）。最終的に、ブロックチェーン・ノード104は、アリスのトランザクション152jを含む順序付けられたプール154の一部に関するパズルを解くであろう。一旦、新たなトランザクション152jを含むプール154について、プルーフ・オブ・ワークが行われると、それは、変更不可能な形式で、ブロックチェーン150内のブロック151のうちの1つの一部になる。各トランザクション152は、以前のトランザクションに戻る向きのポインタを含むので、トランザクションの順序もまた、変更不可能に記録される。
【0039】
様々なブロックチェーン・ノード104は、先ず、所与のトランザクションの様々なインスタンスを受信し、従って、1つのインスタンスが新たなブロック151において公表される前に、どのインスタンスが「有効」であるかについての競合する見解を有する可能性があり、その時点で、全てのブロックチェーン・ノード104は、公表されたインスタンスが唯一の有効なインスタンスであることに同意する。ブロックチェーン・ノード104が1つのインスタンスを有効として受け入れ、次いで、第2のインスタンスがブロックチェーン150に記録されていることを発見した場合、そのブロックチェーン・ノード104はそれを受け入れなければならず、最初に受け入れたインスタンス（即ち、ブロック151で公表されていないもの）を破棄するであろう（即ち、無効として取り扱う）。
【0040】
幾つかのブロックチェーン・ネットワークによって運用される別のタイプのトランザクション・プロトコルは、アカウント・ベースのトランザクション・モデルの一部として、「アカウント・ベース」プロトコルと呼ばれることがある。アカウント・ベースの場合、各トランザクションは、過去のトランザクションのシーケンスで先行しているトランザクションのUTXOに戻る方向を指すことによって、移転される量を定めるのではなく、むしろ絶対的なアカウント残高を参照することによる。全てのアカウントの現在の状態は、そのネットワークのノードによって、ブロックチェーンとは別に格納されており、定常的に更新される。このようなシステムでは、トランザクションは、アカウントのランニング・トランザクション・タリー（running transaction tally）（いわゆる「ポジション」）を使用して順序付けられる。この値は、それらの暗号署名の一部として送信者により署名され、トランザクション参照計算の一部としてハッシュされる。更に、オプションのデータ・フィールドがトランザクションにおいて署名されてもよい。このデータ・フィールドは、例えば、前のトランザクションIDがデータ・フィールドに含まれている場合に、前のトランザクションに戻る方向を指していてもよい。
【0041】
UTXOベース・モデル
図2は、例示的なトランザクション・プロトコルを示す。これはUTXOベース・プロトコルの例である。トランザクション152（「Tx」と略す）は、ブロックチェーン150（各ブロック151は、1つ以上のトランザクション152を含む）の基本的なデータ構造である。以下、アウトプット・ベース・プロトコル又は「UTXO」ベース・プロトコルを参照することによって説明する。しかしながら、これは、全ての可能な実施形態に対する限定ではない。例示的なUTXOベースのプロトコルは、ビットコインを参照しながら説明されるが、他の例示的なブロックチェーン・ネットワークにおいて同様に実装されてもよいことに留意されたい。
図2は、例示的なトランザクション・プロトコルを示す。これはUTXOベース・プロトコルの例である。トランザクション152（「Tx」と略す）は、ブロックチェーン150（各ブロック151は、1つ以上のトランザクション152を含む）の基本的なデータ構造である。以下、アウトプット・ベース・プロトコル又は「UTXO」ベース・プロトコルを参照することによって説明する。しかしながら、これは、全ての可能な実施形態に対する限定ではない。例示的なUTXOベースのプロトコルは、ビットコインを参照しながら説明されるが、他の例示的なブロックチェーン・ネットワークにおいて同様に実装されてもよいことに留意されたい。
【0042】
UTXOベース・モデルでは、各トランザクション（「Tx」）152は、1つ以上のインプット202と1つ以上のアウトプット203を含むデータ構造を備えている。各々のアウトプット203は、未使用トランザクション・アウトプット（UTXO）を含む可能性があり、（UTXOが既に償還されたものでない場合には）これは別の新たなトランザクションのインプット202のソースとして使用することができる。UTXOは、デジタル資産の分量を指定する値を含む。これは、分配された台帳に設定されたトークン数を表す。UTXOは、また、他の情報の中でも特に、それが到来してきた元のトランザクションのトランザクションIDを含んでもよい。トランザクション・データ構造はまたヘッダ201を含んでもよく、これはインプット・フィールド202とアウトプット・フィールド203のサイズのインジケータを含む可能性がある。ヘッダ201はまた、トランザクションのIDを含んでもよい。実施形態において、トランザクションIDは、トランザクション・データのハッシュ（トランザクションID自体を除く）であり、ノード104にサブミットされた未加工トランザクション152のヘッダ201に格納される。
【0043】
例えば、アリス103aが、問題としているデジタル資産の分量を、ボブ103bに転送するトランザクション152jを作成することを望んでいるとする。図2では、アリスの新たなトランザクション152jは、「Tx1」とラベル付けされている。これは、シーケンスで先行するトランザクション152iのアウトプット203においてアリスにロックされているデジタル資産の分量を取り出して、その少なくとも一部をボブへ転送する。先行するトランザクション152iは、図2では「Tx0」とラベル付けされている。Tx0及びTx1は、単なる任意的なラベルである。これらは、必ずしも、Tx0がブロックチェーン151における最初のトランザクションであることや、Tx1がプール154内で直近の次のトランザクションであることを必ずしも意味していない。Tx1は、アリスにロックされた未使用アウトプット203を依然として有する、何らかの先行する（即ち、先立つ）トランザクションに戻る方向を指し示すことができる。
【0044】
先行トランザクションTx0は、アリスが彼女の新しいトランザクションTx1を作成する時点で、又は少なくとも彼女がそれをネットワーク106に送信する時点までに、既に検証され且つブロックチェーン150に含まれている可能性がある。それは、その時点で既にブロック151のうちの1つに含まれている可能性があり、或いは順序付けられたセット154内でまだ待機している可能性があり、その場合、新しいブロック151に速やかに含まれることになる。代替的に、Tx0及びTx1は一緒に作成されてネットワーク102へ送信されることが可能であり、或いは、ノード・プロトコルが「オーファン（orphan）」トランザクションをバッファリングすることを許容する場合、Tx0がTx1の後に送信されることさえ可能である。本件でトランザクション・シーケンスの文脈で使用される「先行」及び「後続」という用語は、トランザクションで指定されるトランザクション・ポインタ（どのトランザクションが、他のどのトランザクションに戻る方向を指すか等）によって定められるシーケンスにおけるトランザクションの順序を指す。これらは「先行」と「後行」、「祖先」と「子孫」、「親」と「子」等により同等に置換することが可能である。これは、それらが生成されたり、ネットワーク106に送信されたり、或いは任意の所与のノード104に到達したりする順序を必ずしも意味しない。それにもかかわらず、先行トランザクション（祖先トランザクション又は「親」）を指し示す後続トランザクション（子孫トランザクション又は「子」）は、親トランザクションが検証されるまで、及び親トランザクションが検証されない限り、検証されないであろう。親の前にブロックチェーン・ノード104に到着した子は、孤立（オーファン）と考えられる。ノード・プロトコル及び／又はノードの行動に応じて、それは破棄されるか又は親を待機するための一定時間にわたってバッファリングされる可能性がある。
【0045】
先行するトランザクションTx0の1つ以上のアウトプット203のうちの1つは、ここではUTXO0とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の分量を指定する値と、後続のトランザクションが検証されるために、従ってUTXOが正常に償還されるために、後続のトランザクションのインプット202においてアンロッキング・スクリプトによって充足されることを必要とする条件を定めるロッキング・スクリプトとを含む。典型的には、ロッキング・スクリプトは、特定の当事者（トランザクションに含まれている受取人）に対してその分量をロックする。即ち、ロッキング・スクリプトは、アンロッキング条件を定め、典型的には、後続トランザクションのインプットにおけるアンロッキング・スクリプトが、ある当事者の暗号シグネチャを含み、先行トランザクションはその当事者にロックされている、という条件を含む。
【0046】
ロッキング・スクリプト（scriptPubKeyとしても知られている）は、ノード・プロトコルによって認識されるドメイン固有の言語で書かれたコードの一部である。そのような言語の特定の例は、「Script」（大文字のS）と呼ばれ、これはブロックチェーン・ネットワークによって使用されている。ロッキング・スクリプトは、如何なる情報がトランザクション・アウトプット203を消費するために必要とされるか、例えば、アリスのシグネチャの条件を指定する。アンロッキング・スクリプトはトランザクションのアウトプットに登場する。アンロッキング・スクリプト（scriptSig としても知られている）は、ロッキング・スクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えばそれはボブの署名を含む可能性がある。アンロッキング・スクリプトは、トランザクションの入力202に登場する。
【0047】
図示の例では、Tx0のアウトプット203におけるUTXO0は、ロッキング・スクリプト[Checksig PA]を含み、これは、UTXO0が償還されるために（厳密には、UTXO0を償還しようとする後続のトランザクションが有効化されるために）、アリスの署名Sig PAを必要とする。[Checksig PA]は、アリスの公開鍵－秘密鍵のペアからの公開鍵PAの表現（即ち、ハッシュ）を含む。Tx1のインプット202は、（例えば、そのトランザクションID、TxID0 実施形態ではそれはトランザクションTx0全体のハッシュであるものを利用することによって）Tx0に戻る方向を指すポインタを含む。Tx1のインプット202は、Tx0の任意の他の可能なアウトプットの中でそれを識別するために、Tx0内のUTXO0を識別するインデックスを含む。Tx1のインプット202は、更に、鍵ペアからのアリスの秘密鍵を、（暗号化においては「メッセージ」と呼ばれることがある）データの所定の部分に適用してアリスによって作成された、アリスの暗号シグネチャを含むアンロッキング・スクリプト<Sig PA>を含む。有効なシグネチャを提供するためにアリスによって署名されることを必要とするデータ（又は「メッセージ」）は、ロッキング・スクリプトによって、ノード・プロトコルによって、又はこれらの組み合わせによって定められることが可能である。
【0048】
新しいトランザクションTx1がブロックチェーン・ノード104に到着すると、ノードはノード・プロトコルを適用する。これは、ロッキング・スクリプトとアンロッキング・スクリプトを一緒に実行して、アンロッキング・スクリプトがロッキング・スクリプトで定められている条件（この条件は1つ以上の基準を含む可能性がある）を充足しているかどうかをチェックすることを含む。実施形態において、これは2つのスクリプトを連結することを含む：
<Sig PA><PA>||[Checksig PA]
<Sig PA><PA>||[Checksig PA]
【0049】
ここで、「||」は連結を表し、「<・・・>」はデータをスタックの上に置くことを意味し、「[・・・]」はロッキング・スクリプト（この例では、スタック・ベース言語）によって構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて、一方を他方の後に実行してもよい。いずれにせよ、一緒に実行される場合、スクリプトは、Tx0のアウトプットにおけるロッキング・スクリプトに含まれるように、アリスの公開鍵PAを使用して、Tx1のインプットにおけるアンロッキング・スクリプトが、データのうちの期待されている部分を署名するアリスのシグネチャを含んでいることを認証する。この認証を実行するためには、データ自体の予想される部分（「メッセージ」）も含まれることを必要とする。実施形態において、署名されたデータは、Tx1の全体を含む（従って、個々の要素が包含されることを必要とせず、データの署名された部分を平文で指定し、なぜなら既に本来的に存在するからである）。
【0050】
公開－秘密（鍵）暗号化による認証の詳細は、当業者にはよく知られているであろう。基本的には、アリスが彼女の公開鍵を用いてメッセージに署名した場合、所与のアリスの公開鍵と平文のメッセージの下で、ノード104のような別のエンティティは、そのメッセージがアリスによって署名されていなければならないことを認証することができる。署名することは、典型的には、メッセージをハッシュ化し、ハッシュに署名し、シグネチャとしてメッセージにこれをタグ付けし、公開鍵の何れかの所有者がそのシグネチャを認証できるようにする。従って、本件において、データの特定の部分又はトランザクションの一部分などに署名するという如何なる言及も、実施形態では、データのその部分又はトランザクションの一部分のハッシュに署名することを意味する可能性がある、ということに留意されたい。
【0051】
Tx1内のアンロッキング・スクリプトがTx0のロッキング・スクリプト内で指定された1つ以上の条件を満たす場合（従って、図示される例では、アリスのシグネチャがTx1で提供され、認証される場合）、ブロックチェーン・ノード104は、Tx1を有効と見なす。これは、ブロックチェーン・ノード104が、待機中のトランザクションの順序付けられたプール154に、Tx1を追加することを意味する。また、ブロックチェーン・ノード104は、トランザクションTx1を、ネットワーク106内の1つ以上の他のブロックチェーン・ノード104にも転送し、その結果、それはネットワーク106全体に伝搬されるであろう。いったんTx1が検証され、ブロックチェーン150に含められると、これはTx0からのUTXO0を支払い済み（spent）として定める。Tx1は、それが未使用トランザクション・アウトプット203を消費する場合にのみ有効であり得ることに留意されたい。別のトランザクション152によって既に消費されているアウトプットを消費しようと試みる場合、Tx1は、たとえ他の全ての条件が充足されていたとしても無効となるであろう。従って、ブロックチェーン・ノード104は、先行トランザクションTx0において参照されるUTXOが既に消費されているかどうか（即ち、別の有効なトランザクションに対する有効なインプットを既に形成しているかどうか）もチェックすることを必要とする。これが、ブロックチェーン150にとってトランザクション152で定義された順序を課すことは重要である、という理由の1つである。実際には、所与のブロックチェーン・ノード104は、どのトランザクション152でどのUTXO203が消費されているかをマーキングする別個のデータベースを維持するかもしれないが、最終的にUTXOが消費されているかどうかを定めるものは、ブロックチェーン150内の別の有効なトランザクションに対する有効なインプットを既に形成しているかどうかである。
【0052】
所与のトランザクション152の全てのアウトプット203で指定される総量が、その全てのインプット202によって指し示される総量よりも大きい場合、これは、ほとんどのトランザクション・モデルにおける無効性に関する別の根拠である。従って、このようなトランザクションは、伝播されたりブロック151に含められたりはしないであろう。
【0053】
UTXOベースのトランザクション・モデルでは、所与のUTXOが全体として消費されることを必要とする、ということに留意されたい。UTXOで定められている分量のうちの一部分を「残しておく」一方、別の部分が消費される、ということはできない。しかしながら、UTXOからの分量は、次のトランザクションの複数のアウトプットの中で分けられることが可能である。例えば、Tx0のUTXO0で定められる分量は、Tx1の複数のUTXOの間で分割されることが可能である。従って、アリスが、UTXO0で定められる分量のうちの全てをボブに与えることを望まない場合、彼女は残りの分量を使って、Tx1の第2のアウトプットで自分自身に釣り銭を与えたり、或いは、別の者へ支払ったりすることができる。
【0054】
実際には、アリスは、通常、彼女のトランザクション104を首尾良くブロック151に含めたビットコイン・ノード104に対する手数料を含めることも必要とする。アリスがそのような手数料を含めていない場合、Tx0はブロックチェーン・ノード104によって拒否される可能性があり、従って技術的には妥当であるが、それは伝播されず、ブロックチェーン150に含まれない可能性がある（ノード・プロトコルは、ブロックチェーン・ノード104に対して、彼らが望まない場合に、トランザクション152を受け入れるようには強制しない）。一部のプロトコルでは、トランザクション手数料は、独自の別個のアウトプット203を必要としない（即ち、別個のUTXOを必要としない）。その代わりに、インプット202によって示される総量と所与のトランザクション152のアウトプット203で指定される総量との間の如何なる差分も、トランザクションを公表するブロックチェーン・ノード104に自動的に与えられる。例えば、UTXO0に対するポインタがTx1に対する唯一のインプットであり、Tx1は唯1つのアウトプットUTXO1を有するとする。UTXO0で指定されたデジタル資産の分量がUTXO1で指定された分量より多い場合、その差分は、プルーフ・オブ・ワークに勝利してUTXO1を含むブロックを作成したノード104に割り当てられる可能性がある。しかしながら、代替的又は追加的に、必ずしも、トランザクション手数料が、トランザクション152のUTXO203のうちの自身の1つにおいて明示的に指定できることは除外されない。
【0055】
アリスとボブのデジタル資産は、ブロックチェーン150のどこかで何らかのトランザクション152において、それらにロックされたUTXOから構成される。従って、典型的には、所与の者103の資産は、ブロックチェーン150を通じて、様々なトランザクション152のUTXO全体に分散される。ブロックチェーン150内のどこかに保存された、所与の者103の総残高を定める1つの数字は存在しない。各々の当事者にロックされ、別の前方トランザクションでまだ消費されていない全ての様々なUTXOの値を一緒にまとめることは、クライアント・アプリケーション105におけるウォレット機能の役割である。これは、任意のビットコイン・ノード104に格納されているようなブロックチェーン150のコピーを照会することによって、それを行うことができる。
【0056】
スクリプト・コードはしばしば概略的に表現される（即ち、厳密な言語を使用していない）ことに留意されたい。例えば、ある者はオペレーション・コード（オペコード）を用いて、特定の機能を表現するかもしれない。「OP_...」はScript言語の特定のオペコードを示す。一例として、OP_RETURNは、Script言語のオペコードであって、ロッキング・スクリプトの先頭でOP_FALSEが先行している場合、トランザクションの使用不能アウトプット（unspendable output）を生成し、それはトランザクション内にデータを保存することが可能であってそれによりデータをブロックチェーン150に変更不能に記録することが可能なものである。例えば、データは、ブロックチェーンに保存するように望まれる文書を含むことができる。
【0057】
典型的には、トランザクションのインプットは、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは楕円曲線secp256k1を使用するECDSAに基づいている。デジタル署名は、特定のデータに署名している。一部の実施形態では、所与のトランザクションについて、シグネチャはトランザクション・インプットの一部分、及びトランザクション・アウトプットの一部又は全部に署名しているであろう。アウトプットのうち署名している特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、通常、どのアウトプットが署名されているかを選択するためにシグネチャの末尾に含まれる4バイト・コードである（従って、署名時に定まる）。
【0058】
ロッキング・スクリプトは、典型的には当事者の公開鍵を含み、それぞれのトランザクションはその当事者にロックされる、という事実に関連して、しばしば「scriptPubKey」と呼ばれる。アンロッキング・スクリプトは、典型的には対応するシグネチャを提供する、という事実に関連して、しばしば「scriptSig」と呼ばれる。しかしながら、より一般的には、ブロックチェーン150の全てのアプリケーションにおいて、UTXOが償還される条件はシグネチャを認証することを含む、ということは必須でない。より一般的には、スクリプト言語は、任意の1つ以上の条件を定義するために使用されることが可能である。従って、より一般的な用語「ロッキング・スクリプト」及び「アンロッキング・スクリプト」が望ましいかもしれない。
【0059】
サイド・チャネル
図1に示されるように、アリスとボブのコンピュータ装置102a，102bの各々におけるクライアント・アプリケーションは、それぞれ、付加的な通信機能を含む可能性がある。この追加機能は、アリス103aが、（いずれかの当事者又は第三者の勧誘により）ボブ103bとの別個のサイド・チャネル107を確立することを可能にする。サイド・チャネル107は、ブロックチェーン・ネットワークとは別個にデータの交換を可能にする。このような通信は、しばしば「オフ・チェーン（off-chain）」通信と呼ばれる。例えば、これは、当事者のうちの1人がトランザクションをネットワーク106にブロードキャストすることを選択するまで、トランザクションがブロックチェーン・ネットワーク106に登録されたり又はチェーン150上で処理を進行させたりすることなく、アリスとボブとの間でトランザクション152をやり取りために使用されてもよい。このようにして、トランザクションを共有することは、しばしば「トランザクション・テンプレート」の共有と言及される。トランザクション・テンプレートは、完全なトランザクションを形成するために必要とされる1つ以上のインプット及び/又はアウトプットを欠いている可能性がある。代替的又は追加的に、サイド・チャネル107は、鍵、交渉された額又は期間、データ内容などのような、何らかの他のトランザクション関連データを交換するために使用されてもよい。
図1に示されるように、アリスとボブのコンピュータ装置102a，102bの各々におけるクライアント・アプリケーションは、それぞれ、付加的な通信機能を含む可能性がある。この追加機能は、アリス103aが、（いずれかの当事者又は第三者の勧誘により）ボブ103bとの別個のサイド・チャネル107を確立することを可能にする。サイド・チャネル107は、ブロックチェーン・ネットワークとは別個にデータの交換を可能にする。このような通信は、しばしば「オフ・チェーン（off-chain）」通信と呼ばれる。例えば、これは、当事者のうちの1人がトランザクションをネットワーク106にブロードキャストすることを選択するまで、トランザクションがブロックチェーン・ネットワーク106に登録されたり又はチェーン150上で処理を進行させたりすることなく、アリスとボブとの間でトランザクション152をやり取りために使用されてもよい。このようにして、トランザクションを共有することは、しばしば「トランザクション・テンプレート」の共有と言及される。トランザクション・テンプレートは、完全なトランザクションを形成するために必要とされる1つ以上のインプット及び/又はアウトプットを欠いている可能性がある。代替的又は追加的に、サイド・チャネル107は、鍵、交渉された額又は期間、データ内容などのような、何らかの他のトランザクション関連データを交換するために使用されてもよい。
【0060】
サイド・チャネル107は、ブロックチェーン・ネットワーク106と同じパケット交換ネットワーク101を介して確立されてもよい。代替的又は追加的に、サイド・チャネル301は、移動体セルラ・ネットワークのような異なるネットワークを介して、又はローカル無線ネットワークのようなローカル・エリア・ネットワークを介して、又は、アリスとボブのデバイス102a、102bの間の直接的な有線又は無線リンクを介してさえ確立することが可能である。一般に、本件のどこかで言及されているようなサイド・チャネル107は、データを交換するための1つ以上のネットワーキング技術又は通信媒体を介する何らかの1つ以上のリンク（オフ・チェーン）、即ち、ブロックチェーン・ネットワーク106から別個のものを含む可能性がある。2つ以上のリンクが使用される場合、全体としてのオフ・チェーン・リンクの束又は集まりが、サイド・チャネル107と言及されてもよい。従って、アリスとボブがサイド・チャネル107を介して特定の情報又はデータ等を交換する、と言及される場合、これは、必ずしもこれらの全てのデータが厳密に同じリンクを介して、又は同じタイプのネットワークを介してでさえ、送信されなければならないことを意味しないことに留意されたい。
【0061】
クライアント・ソフトウェア
図3Aは、目下開示されている方式の実施形態を実装するためのクライアント・アプリケーション105の実装例を示す。クライアント・アプリケーション105は、トランザクション・エンジン401とユーザー・インターフェース（UI）レイヤ402とを含む。トランザクション・エンジン401は、トランザクション152を形成すること、トランザクション及び/又はその他のデータをサイド・チャネル301を介して受信及び／又は送信すること、ブロックチェーン・ネットワーク106を介して伝搬されることになるトランザクションを1つ以上のノード104に送信すること等のような、クライアント105の前提としているトランザクション関連機能を、上述した及び間もなく詳細に説明されるような方式に従って実行するように構成されている。本件で開示される実施形態によれば、各クライアント105のトランザクション・エンジン401は機能403を含む。
図3Aは、目下開示されている方式の実施形態を実装するためのクライアント・アプリケーション105の実装例を示す。クライアント・アプリケーション105は、トランザクション・エンジン401とユーザー・インターフェース（UI）レイヤ402とを含む。トランザクション・エンジン401は、トランザクション152を形成すること、トランザクション及び/又はその他のデータをサイド・チャネル301を介して受信及び／又は送信すること、ブロックチェーン・ネットワーク106を介して伝搬されることになるトランザクションを1つ以上のノード104に送信すること等のような、クライアント105の前提としているトランザクション関連機能を、上述した及び間もなく詳細に説明されるような方式に従って実行するように構成されている。本件で開示される実施形態によれば、各クライアント105のトランザクション・エンジン401は機能403を含む。
【0062】
UIレイヤ402は、それぞれのユーザーのコンピュータ装置102のユーザー入力/出力（I／O）手段によりユーザー・インターフェースをレンダリングするように構成されており、装置102のユーザー出力手段を介してそれぞれのユーザー103に情報を出力すること、装置102のユーザー入力手段を介してそれぞれのユーザー103からの入力を受けることを含む。例えば、ユーザー出力手段は、視覚的な出力を提供するための1つ以上の表示スクリーン（タッチ式又は非タッチ式のスクリーン）、オーディオ出力を提供するための1つ以上のスピーカ、及び/又は、触覚出力を提供するための1つ以上の触覚出力デバイスなどを含むことが可能である。ユーザー入力手段は、例えば、1つ以上のタッチ・スクリーンの入力アレイ（出力手段に使用されるものと同じか又は異なるもの）；マウス、トラックパッド又はトラックボールのような1つ以上のカーソル・ベースのデバイス；会話又は音声の入力を受けるための1つ以上のマイクロホン及び会話又は音声認識アルゴリズム；手動又は身体ジェスチャの形態で入力を受けるための1つ以上のジェスチャ・ベースの入力デバイス；又は1つ以上の機械的なボタン、スイッチ又はジョイスティックなどを含むことが可能である。
【0063】
注記：本件における種々の機能は、同一のクライアント・アプリケーション105に統合されているように述べられているかもしれないが、これは、必ずしも限定ではなく、むしろ、2つ以上の別個のアプリケーション、例えば、一方が他方へのプラグ・インであったり、或いはAPI（アプリケーション・プログラミング・インターフェース）を介するインターフェースで実現されたりすることが可能である。例えば、トランザクション・エンジン401の機能は、UIレイヤ402とは別のアプリケーションで実装されてもよいし、又は、トランザクション・エンジン401のような所与のモジュールの機能は、複数のアプリケーションの間で分割されてもよい。なお、機能的に説明されているものの全部又は一部が、例えばオペレーティング・システム・レイヤで実装されることが可能である、ということは除外されていない。本件のどこかで単一の又は所与のアプリケーション105等を参照する場合、それは単なる例示であるに過ぎず、より一般的には、説明される機能は、任意の形態のソフトウェアで実施することができる、ということが理解されるであろう。
【0064】
図3Bは、アリスの装置102aにおいてクライアント・アプリケーション105aのUIレイヤ402によってレンダリングされる可能性のあるユーザー・インターフェース（UI）500のモックアップ例を示す。同様なUIが、ボブの装置102bにおけるクライアント105bによって、又は任意の他の関係者のものによって、提供されてもよいことが理解されるであろう。
【0065】
例示として、図3Bはアリスの観点からのUI 500を示している。UI 500は、ユーザー出力手段により個々のUI要素としてレンダリングされる1つ以上のUI要素501，502，502を含む可能性がある。
【0066】
例えば、UI要素は、異なるオン・スクリーン・ボタン、又はメニュー内の異なるオプション等のようなものである可能性のあるユーザー選択可能な1つ以上の要素501を含む可能性がある。ユーザー入力手段は、ユーザー103（このケースでは、アリス 103a）が、例えば、画面上のUI要素をクリックしたり又はタッチしたり、又は所望のオプションの名前を喋ったりすることにより、オプションのうちの1つを選択したり又は他の方法で操作したりすることができるように構成されている（N.B.本件で使用される用語「マニュアル」は、オートマチック（自動）との対比だけのために意図されており、必ずしも片手又は両手を使用することに限定されない）。オプションは、ユーザー（Alice）が、トランザクション内にデータを埋め込むことを可能にする。
【0067】
代替的又は追加的に、UI要素は1つ以上のデータ入力フィールド502を含むことが可能であり、そのフィールドを通じて、ユーザーはトランザクション内にデータを埋め込むことができる。これらのデータ入力フィールドは、ユーザー出力手段、例えば、オン・スクリーン（on-screen）を介してレンダリングされ、また、データは、ユーザー入力手段、例えば、キーボード又はタッチ・スクリーンを介してフィールドに入力されることが可能である。代替的に、データは、例えば音声認識に基づいて口頭で受けることが可能である。代替的又は追加的に、UI要素は、ユーザーに情報を出力するために出力される1つ以上の情報要素503を含んでもよく、例えば、これ／これらは、スクリーン上で又は聴覚的にレンダリングされることが可能である。
【0068】
種々のUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能は間もなく詳細に説明される。また、図3に示されるUI 500は、概略的なモックアップであるに過ぎず、実際には、簡潔性のために図示されていない1つ以上の更なるUI要素を含む可能性がある、ということも理解されるであろう。
【0069】
ノード・ソフトウェア
図4は、UTXO又はアウトプット・ベースのモデルの例において、ネットワーク106の各ブロックチェーン・ノード104上で実行されるノード・ソフトウェア450の例を示す。別のエンティティは、ネットワーク106におけるノード104として分類されることなく、即ち、ノード104に必要な動作を実行することなく、ノード・ソフトウェア450を動作させることが可能であることに留意されたい。ノード・ソフトウェア450は、プロトコル・エンジン451、スクリプト・エンジン452、スタック453、アプリケーション・レベル決定エンジン454、及び1つ以上のブロックチェーン関連機能モジュールのセット455を含む可能性があるが、これらに限定されない。各ノード104は、コンセンサス・モジュール455C（例えば、プルーフ・オブ・ワーク）、伝播モジュール455P、及び記憶モジュール455S（例えば、データベース）の3つ全てを含むが、これに限定されないノード・ソフトウェアを実行することが可能である。プロトコル・エンジン401は、通常、トランザクション152の様々なフィールドを認識し、ノード・プロトコルに従ってそれらを処理するように構成される。トランザクション152j（Txj）が受信され、別の先行するトランザクション152i（Txm-1）のアウトプット（例えば、UTXO）を指し示すインプットを有している場合、プロトコル・エンジン451は、Txjのアンロッキング・スクリプトを特定し、それをスクリプト・エンジン452に渡す。また、プロトコル・エンジン451は、Txjのインプットにおけるポインタに基づいて、Txiを特定して抽出する。Txiは、ブロックチェーン150上で公開されることが可能であり、その場合、プロトコル・エンジンは、ノード104に格納されたブロックチェーン150のブロック151のコピーから、Txiを抽出することが可能である。代替的に、Txiは、ブロックチェーン150上でまだ公開されていない可能性がある。その場合、プロトコル・エンジン451は、ノード104によって維持される未公開のトランザクションの順序付けられたセット154からTxiを抽出することが可能である。何れにせよ、スクリプト・エンジン451は、Txiの参照されたアウトプット内のロッキング・スクリプトを特定し、それをスクリプト・エンジン452へ渡す。
図4は、UTXO又はアウトプット・ベースのモデルの例において、ネットワーク106の各ブロックチェーン・ノード104上で実行されるノード・ソフトウェア450の例を示す。別のエンティティは、ネットワーク106におけるノード104として分類されることなく、即ち、ノード104に必要な動作を実行することなく、ノード・ソフトウェア450を動作させることが可能であることに留意されたい。ノード・ソフトウェア450は、プロトコル・エンジン451、スクリプト・エンジン452、スタック453、アプリケーション・レベル決定エンジン454、及び1つ以上のブロックチェーン関連機能モジュールのセット455を含む可能性があるが、これらに限定されない。各ノード104は、コンセンサス・モジュール455C（例えば、プルーフ・オブ・ワーク）、伝播モジュール455P、及び記憶モジュール455S（例えば、データベース）の3つ全てを含むが、これに限定されないノード・ソフトウェアを実行することが可能である。プロトコル・エンジン401は、通常、トランザクション152の様々なフィールドを認識し、ノード・プロトコルに従ってそれらを処理するように構成される。トランザクション152j（Txj）が受信され、別の先行するトランザクション152i（Txm-1）のアウトプット（例えば、UTXO）を指し示すインプットを有している場合、プロトコル・エンジン451は、Txjのアンロッキング・スクリプトを特定し、それをスクリプト・エンジン452に渡す。また、プロトコル・エンジン451は、Txjのインプットにおけるポインタに基づいて、Txiを特定して抽出する。Txiは、ブロックチェーン150上で公開されることが可能であり、その場合、プロトコル・エンジンは、ノード104に格納されたブロックチェーン150のブロック151のコピーから、Txiを抽出することが可能である。代替的に、Txiは、ブロックチェーン150上でまだ公開されていない可能性がある。その場合、プロトコル・エンジン451は、ノード104によって維持される未公開のトランザクションの順序付けられたセット154からTxiを抽出することが可能である。何れにせよ、スクリプト・エンジン451は、Txiの参照されたアウトプット内のロッキング・スクリプトを特定し、それをスクリプト・エンジン452へ渡す。
【0070】
スクリプト・エンジン452は、従って、Txjの対応するインプットからのアンロッキング・スクリプト及びTxiのロッキング・スクリプトを有する。例えば、Tx0及びTx1というラベルが付されたトランザクションが図2に示されているが、同様なことがトランザクションの任意のペアに適用可能である。スクリプト・エンジン452は、前述のように2つのスクリプトを一緒に実行し、これは、使用されているスタック・ベースのスクリプト言語（例えば、Script）に従って、スタック453上にデータを配置すること、及びスタック210からデータを取り出すことを含むであろう。
【0071】
それらのスクリプトを一緒に動作させることによって、スクリプト・エンジン452は、アンロッキング・スクリプトがロッキング・スクリプトで定められている1つ以上の基準を満たすかどうか、即ち、ロッキング・スクリプトが含まれるアウトプットを「ロック解除する（unlock）」かどうかを判定する。スクリプト・エンジン452は、アンロッキング・スクリプトが、対応するロッキング・スクリプトにおいて指定されている1つ以上の基準を満たすと判定した場合、「真（true）」という結果を返す。そうでない場合、「偽（false）」という結果を返す。
【0072】
アウトプット・ベースのモデルでは、スクリプト・エンジン452からの結果「真」は、トランザクションの有効性の条件のうちの1つである。典型的には、プロトコル・エンジン451によって評価される、同様に満足しなければならない1つ以上の更なるプロトコル・レベル条件も存在し；例えば、Txjのアウトプット（複数可）で指定されるデジタル資産の総量が、そのインプットによって指定される総量を超えていないこと、及び、Txiの指定されたアウトプットが、別の有効なトランザクションによって既に消費されたものではないことである。プロトコル・エンジン451は、スクリプト・エンジン452からの結果を、1つ以上のプロトコル・レベル条件を用いて評価し、それらが全て真である場合に限り、トランザクションTxjを正当化する。プロトコル・エンジン451は、トランザクションが有効であるかどうかの指示を、アプリケーション・レベル決定エンジン454に出力する。Txjが実際に検証されている条件の下でのみ、決定エンジン454は、コンセンサス・モジュール455C及び伝搬モジュール455Pの両方を制御して、Txjに関して各自それぞれのブロックチェーン関連機能を実行することが可能である。これは、コンセンサス・モジュール455CがTxjを、ブロック151に組み込むために、ノードのそれぞれの順序付けられたトランザクションのセット154に追加すること、及び、伝搬モジュール455Pが、Txjを、ネットワーク106内の別のブロックチェーン・ノード104に転送することを含む。オプションとして、実施形態では、アプリケーション・レベル決定エンジン454は、これらの機能の内の何れか又は両方をトリガする前に、1つ以上の追加の条件を適用することが可能である。例えば、決定エンジンは、トランザクションが有効であり、且つトランザクション手数料が十分に残っているという条件の下で、トランザクションを公表することを選択するだけであってもよい。
【0073】
また、本件における「真」及び「偽」という用語は、単一の二進数（ビット）のみの形態で表現される結果を返すことに（それは確かに1つの可能な実装形態ではあるが）必ずしも限定されない、ということに留意されたい。より一般的には、「真」は、成功又は肯定的な結果を示す任意の状態を指すことが可能であり、「偽」は、不成功又は否定的な結果を示す任意の状態を指すことが可能である。例えば、アカウント・ベースのモデルでは、「真」という結果は、シグネチャの暗黙的なプロトコル・レベルの検証と、スマート・コントラクトの追加的な肯定的なアウトプットとの組み合わせによって示されることが可能である（両方の個々の結果が真である場合に、全体的な結果は真を示していると考えられる）。
【0074】
具体的な開示内容
上述したように、各ブロックチェーン・ノード（即ち、「マイナー」）によって実装されるプロトコルは、新しいトランザクション152jで提供される暗号シグネチャが、先行するトランザクション152iにおいて指定され且つそれによって要求されるシグネチャと一致することをチェックすることを、ノード104に要求する。アウトプット・ベースのトランザクション・プロトコルでは、シグネチャ要件は、先行するトランザクションにおけるアウトプットのロッキング・スクリプトで提供され、その要件を満たすシグネチャは、新しいトランザクションにおけるインプットのアンロッキング・スクリプトで提供される。従って、ブロックチェーン・ネットワークのコンセンサス・メカニズムを構成するマイニング・ノード104は、検証サービスを実行し、また、次のトランザクションのインプットにおけるシグネチャが、指定された要件を満たさない場合には、アウトプットをロック解除する如何なる試みも拒否する。従って、従来の検証プロセスは、2つの異なるトランザクションによって別々に提供されるデータ（メッセージ）に関わり、なぜなら、検証プロセスのために3つの入力（メッセージ、秘密鍵を使用して生成されるシグネチャ、及び対応する公開鍵）が必要とされるからである。換言すれば、マイナー検証シグネチャで使用されるメッセージは、別個のトランザクションにわたって分割される／分割されることが可能である。従って、アウトプットがロックされる場合に、公開鍵と、対応する秘密鍵を用いて作成されるシグネチャとを含むロッキング・スクリプトが作成される。シグネチャを生成するために署名されるデータの部分は、ロックされるアウトプットを含むトランザクション・データ全体のハッシュ、又はその一部の何れかである。後者のケースでは、トランザクション・データのどの部分が、秘密鍵によって署名されるハッシュに含まれるかを示すために、1バイトの署名ハッシュ（SIGHASH）フラグがシグネチャに付加される。
上述したように、各ブロックチェーン・ノード（即ち、「マイナー」）によって実装されるプロトコルは、新しいトランザクション152jで提供される暗号シグネチャが、先行するトランザクション152iにおいて指定され且つそれによって要求されるシグネチャと一致することをチェックすることを、ノード104に要求する。アウトプット・ベースのトランザクション・プロトコルでは、シグネチャ要件は、先行するトランザクションにおけるアウトプットのロッキング・スクリプトで提供され、その要件を満たすシグネチャは、新しいトランザクションにおけるインプットのアンロッキング・スクリプトで提供される。従って、ブロックチェーン・ネットワークのコンセンサス・メカニズムを構成するマイニング・ノード104は、検証サービスを実行し、また、次のトランザクションのインプットにおけるシグネチャが、指定された要件を満たさない場合には、アウトプットをロック解除する如何なる試みも拒否する。従って、従来の検証プロセスは、2つの異なるトランザクションによって別々に提供されるデータ（メッセージ）に関わり、なぜなら、検証プロセスのために3つの入力（メッセージ、秘密鍵を使用して生成されるシグネチャ、及び対応する公開鍵）が必要とされるからである。換言すれば、マイナー検証シグネチャで使用されるメッセージは、別個のトランザクションにわたって分割される／分割されることが可能である。従って、アウトプットがロックされる場合に、公開鍵と、対応する秘密鍵を用いて作成されるシグネチャとを含むロッキング・スクリプトが作成される。シグネチャを生成するために署名されるデータの部分は、ロックされるアウトプットを含むトランザクション・データ全体のハッシュ、又はその一部の何れかである。後者のケースでは、トランザクション・データのどの部分が、秘密鍵によって署名されるハッシュに含まれるかを示すために、1バイトの署名ハッシュ（SIGHASH）フラグがシグネチャに付加される。
【0075】
ビットコインのSIGHASHアルゴリズムは、トランザクションを、メッセージとして知られているチャンクにセグメント化すること（「シリアル化すること」としても知られている）によってこれを達成する。これらのメッセージは、ECDSAシグネチャを使用して署名され、アンロッキング・スクリプトに含まれる。
【0076】
SIGHASHアルゴリズムの重要な特徴は、特定のトランザクション・インプットに署名するためのシリアル化されたメッセージを生成する場合に、メッセージは、典型的には、そのインプットにおいて消費される先行するロッキング・スクリプトと先行するアウトポイント（outpoint）を含む、ということである。これは重要なことであり、なぜなら、それはその特定のトランザクションに関連付け、従ってそのシグネチャが異なるトランザクション内でコピーされて使用されることを防止するからである。
【0077】
しかし、その結果、署名されることになるシリアル化されたメッセージは、典型的には、先行するロッキング・スクリプトに明示的に依存する。重要なことに、この先行するロッキング・スクリプトが、実際、先行するトランザクションの一部であったことを保証することが必要である。これは、先行するロッキング・スクリプトが、実際、生のトランザクションTxprevの一部であったことを検証することによって達成することができ、そのトランザクションのダブル・ハッシュ（double hash）はTxIDprevを生成する。
【0078】
括弧内に示されているデータ・タイプを用いるBitcoin SVで実装されているような完全なSIGHASHアルゴリズムは次のように記述される。
1．nVersion（4バイト・リトル・エンディアンにおけるもの）
2．全てのインプット・アウトポイントのシリアル化されたもののSHA256d（32バイト・ハッシュ）
・ANYONECANPAYフラグがセットされているならば、それは32バイトのゼロになるべきである。
3．全てのインプットのnSequenceのシリアル化されたものSHA256d（32バイト・ハッシュ）
・ANYONECANPAYフラグがセットされているならば、それは32バイトのゼロになるべきである。
4．使用されるアウトポイント（トランザクションIDのための32バイト + インデックスのための4バイト・リトル・エンディアン）。
5．subScriptのバイト長（ビッグ・エンディアン）
6．subScript（以下で定義される）
7．アウトプット量（Satoshi）（8バイト・リトル・エンディアン）
8．このアウトポイントのnSequence（4バイト・リトル・エンディアン）
9．全てのアウトプット量のシリアル化したもののSHA256d及びscriptPubKeys。これらはアウトプットから取られる。
・SINGLEフラグがセットされており、インプット・インデックスがアウトプットの数より小さい場合、これは、インプットと同じインデックスのscriptPubKeyを用いたアウトプットのダブルSHA256であるべきである。
・NONEフラグがセットされている場合、これは32バイトのゼロであるべきである。
10．トランザクションTのnLocktime（4バイト・リトル・エンディアン）
11．シグネチャのsighashタイプ（4バイト・リトル・エンディアン）
1．nVersion（4バイト・リトル・エンディアンにおけるもの）
2．全てのインプット・アウトポイントのシリアル化されたもののSHA256d（32バイト・ハッシュ）
・ANYONECANPAYフラグがセットされているならば、それは32バイトのゼロになるべきである。
3．全てのインプットのnSequenceのシリアル化されたものSHA256d（32バイト・ハッシュ）
・ANYONECANPAYフラグがセットされているならば、それは32バイトのゼロになるべきである。
4．使用されるアウトポイント（トランザクションIDのための32バイト + インデックスのための4バイト・リトル・エンディアン）。
5．subScriptのバイト長（ビッグ・エンディアン）
6．subScript（以下で定義される）
7．アウトプット量（Satoshi）（8バイト・リトル・エンディアン）
8．このアウトポイントのnSequence（4バイト・リトル・エンディアン）
9．全てのアウトプット量のシリアル化したもののSHA256d及びscriptPubKeys。これらはアウトプットから取られる。
・SINGLEフラグがセットされており、インプット・インデックスがアウトプットの数より小さい場合、これは、インプットと同じインデックスのscriptPubKeyを用いたアウトプットのダブルSHA256であるべきである。
・NONEフラグがセットされている場合、これは32バイトのゼロであるべきである。
10．トランザクションTのnLocktime（4バイト・リトル・エンディアン）
11．シグネチャのsighashタイプ（4バイト・リトル・エンディアン）
【0079】
上記のアルゴリズムにおけるステップ6は、先行するアンロッキング・スクリプト及びprevOutsを使用して生成されるsubScriptに依存する。先行するトランザクションとの関係は以下の通りである：
“previousScriptPubKeyから新たなsubScriptが作成される。subScriptは最新のOP_CODESEPARATOR（[実行されているもの（being executed）]であるOP_CHECKSIGの唯1つ前のもの）から始まり、previousScriptPubKeyで終わる。OP_CODESEPARATORが存在しない場合、previousScriptPubKeyはsubScriptとなる。”－これらについては、以下を参照されたい：https://wiki.bitcoinsv.io/index.php/OP_CHECKSIG
“previousScriptPubKeyから新たなsubScriptが作成される。subScriptは最新のOP_CODESEPARATOR（[実行されているもの（being executed）]であるOP_CHECKSIGの唯1つ前のもの）から始まり、previousScriptPubKeyで終わる。OP_CODESEPARATORが存在しない場合、previousScriptPubKeyはsubScriptとなる。”－これらについては、以下を参照されたい：https://wiki.bitcoinsv.io/index.php/OP_CHECKSIG
【0080】
更に、ビットコインのトップに構築されるデータ指向アプリケーションであって、ビットコイン台帳を、基礎となるデータ・レイヤとして使用するものにおいては、そのデータの信憑性（authenticity）を検証するために、（トランザクション又はアウトプットではなく）アプリケーション・データにシグネチャを適用する必要があるかもしれない。例えば、アプリケーションが、土地登記（land registry）をオン・チェーンで認証する場合、信頼できる土地登記の権限を有するか、又は登録データに公証署名（notary sign）を行うことが有益である。
【0081】
登録データの効率的な検証のために、認証されるデータと認証に使用されるシグネチャの両方が同じオン・チェーン・ビットコイン・トランザクションに存在することが有益であろう。これは、ユーザー又は検証者が1つのビットコイン・トランザクションを取得し、（i）認証されるデータを取得してその完全性をチェックすること、及び（ii）その信憑性をチェックするためにデータに対するシグネチャを検証することの両方を可能にするからである。
【0082】
理想的なケースでは、ビットコインに対するこのようなアプリケーションで使用されるデジタル・シグネチャは、以下の3つの特性を有するべきである：
・その場での検証可能性 － シグネチャは、それらを含むトランザクションから取得されたデータのみを使用して検証可能であるべきである；これは効率性をもたらし、なぜなら、検証プロセスのためのインプットを得るために必要な時間が少なく、リソースが少なくて済むからである。
・柔軟性のあるシグネチャ・アルゴリズム － シグネチャは、（例えば、量子耐性（quantum-resistance）を支援するために）アドホック・ベースで任意のシグネチャ・アルゴリズムを利用できるべきである； これは、特定の方式やアルゴリズムを利用することに制約されず、むしろ、当面のタスクの特定の特徴や要件にした技法を使用することを選択できる、より柔軟性のある多様性に富むソリューションの恩恵を提供する。
・再生不能性 － シグネチャは、1つのビットコイン・トランザクション、即ち、最初に提供されたものに対してのみ有効であるべきである；これは、セキュリティを強化し、リプレイ・エクスプロイト攻撃を回避し、シグネチャが他のトランザクションで再利用されてしまうことを防止するという恩恵を提供する。
・その場での検証可能性 － シグネチャは、それらを含むトランザクションから取得されたデータのみを使用して検証可能であるべきである；これは効率性をもたらし、なぜなら、検証プロセスのためのインプットを得るために必要な時間が少なく、リソースが少なくて済むからである。
・柔軟性のあるシグネチャ・アルゴリズム － シグネチャは、（例えば、量子耐性（quantum-resistance）を支援するために）アドホック・ベースで任意のシグネチャ・アルゴリズムを利用できるべきである； これは、特定の方式やアルゴリズムを利用することに制約されず、むしろ、当面のタスクの特定の特徴や要件にした技法を使用することを選択できる、より柔軟性のある多様性に富むソリューションの恩恵を提供する。
・再生不能性 － シグネチャは、1つのビットコイン・トランザクション、即ち、最初に提供されたものに対してのみ有効であるべきである；これは、セキュリティを強化し、リプレイ・エクスプロイト攻撃を回避し、シグネチャが他のトランザクションで再利用されてしまうことを防止するという恩恵を提供する。
【0083】
本開示の出願前においては、ビットコイン・トランザクションにおいてシグネチャを使用するこれらの特性のうちの1つ又は2つを充足することは可能であったが、3つ全てを充足してはいなかった。従って、より多様性に富む効率的で安全な策が、本開示の実施形態によって提供される。説明及び対比の目的のために、2つの例示的なケース（以下のケース1及びケース2）が提供されており、その後に、3つの特性全てを達成するために使用することが可能な本開示の好ましい実施形態（ケース3）の説明が続く。
【0084】
ケース1：スクリプト・シグネチャ（script）
ビットコイン・トランザクションにおいてデータに署名するための従来の方法は、ネットワーク上のマイナーによるトランザクション検証中にスクリプト実行によって検証されるシグネチャを入力することである。シグネチャは、先行する（消費）トランザクションTxID0のロッキング・スクリプトに提供されているシグネチャに対して検証するために、後続の（消費）トランザクションTxID1のアンロッキング・スクリプトに配置される。
ビットコイン・トランザクションにおいてデータに署名するための従来の方法は、ネットワーク上のマイナーによるトランザクション検証中にスクリプト実行によって検証されるシグネチャを入力することである。シグネチャは、先行する（消費）トランザクションTxID0のロッキング・スクリプトに提供されているシグネチャに対して検証するために、後続の（消費）トランザクションTxID1のアンロッキング・スクリプトに配置される。
【0085】
この典型的なシナリオでは、シグネチャ（signature）によって署名されるメッセージは、上述のビットコインSIGHASHアルゴリズムを使用して定式化され、シグネチャは、DERエンコーディングを用いたECDSAシグネチャである。署名されたメッセージは、先行するロッキング・スクリプトとTxID0からのアウトプット値とを含む。換言すれば、この検証動作は、先行するトランザクションから提供されるデータの使用を必要とする。これは、TxID1と呼ばれる例示的なトランザクションを示す図6に示されており、TxID1は、そのアンロッキング・スクリプトにインプット・シグネチャSigP0を含む。メッセージとして使用され且つデジタル署名されるTxID1及びTxID0（前のトランザクション）の部分は、図6において破線内に示されている。
【0086】
SIGHASHフラグが、前のトランザクションの一部を署名していることをシグネチャ（signature）に強制する、という事実は、これらのトランザクションは、TxID1の中だけから取得可能又は導出可能なデータを使用するだけで、その場で検証することはできない、ということを意味する。また、TxID0のデータの少なくとも一部が持ち込まれなければならず、完全性がチェックされる必要がある場合がある。従って、インプット・シグネチャは、上記の特性1を満たすことができない。更に、それらは、DERエンコードされたECDSAシグネチャに限定され、なぜなら、それらはネットワークのマイナーによって実装されている基礎となるブロックチェーン・プロトコルによって記述されるからであり、このことは特性2を充足することに失敗することを意味する。
【0087】
従って、ケース1は特性3のみを達成し、なぜなら、シグネチャはビットコイン・スクリプトで検証され、ブロックチェーンのトランザクション検証メカニズムは、そのシグネチャがこの方法で再生されることを許可しないからである。
【0088】
ケース2：非スクリプト・シグネチャ（data）
このケースでは、シグネチャは、付加データとしてアウトプットに加えられる。ケース1と比較すると、シグネチャは、インプットのアンロッキング・スクリプトから除去され、アウトプットに移されている。シグネチャはアウトプット内の他のデータに署名するが、シグネチャ自体は、トランザクション検証中にマイナーによって検証されることはない。
このケースでは、シグネチャは、付加データとしてアウトプットに加えられる。ケース1と比較すると、シグネチャは、インプットのアンロッキング・スクリプトから除去され、アウトプットに移されている。シグネチャはアウトプット内の他のデータに署名するが、シグネチャ自体は、トランザクション検証中にマイナーによって検証されることはない。
【0089】
シグネチャはその場で検証されることが可能であり、なぜなら、署名されたメッセージは、Tx1自体の中に完全に含まれ、Tx1自体の中で導出可能/取得可能であるからである。マイナーはシグネチャをチェックしないので、任意のデジタル・シグネチャ・アルゴリズム及び柔軟性のあるエンコーディング・フォーマットを使用することも可能である。
【0090】
しかしながら、これらのシグネチャは、トランザクションに追加される単なるデータに過ぎないので、それらを再利用するために他のトランザクションに、コピー・アンド・ペースすることが可能である。
【0091】
従って、これらのタイプのシグネチャは、特性1及び2のみを達成する。このケースを説明するために、図7は、アウトプット・シグネチャSigP0’を含む例示的なトランザクションTxID2を示している。署名されたメッセージは破線内に示されている。
【0092】
ケース3：非・再生可能シグネチャ（data）
本発明の実施形態による「非・再生可能シグネチャ（non-replayable signatures）」と言及することが可能な第3のケースを提案する。
本発明の実施形態による「非・再生可能シグネチャ（non-replayable signatures）」と言及することが可能な第3のケースを提案する。
【0093】
ケース2と同様に、これらは非スクリプト・シグネチャを含み、従って、シグネチャは、ケース1のインプットのアンロッキング・スクリプトから除去され、アウトプットに移されている。更に、ケース3は、署名されたメッセージは、それが提供されるトランザクションにそれを一意に結び付けるデータの部分を含むことを要求する。実施形態では、そのデータの部分は、トランザクション内に含まれる1つ以上のアウトポイントである。メッセージに、固有のトランザクション識別データを含めることは、そのシグネチャがTx1に関してのみ検証され、従って、後続のトランザクションでは再生できないことを意味する。これは、Tx1によって消費される各アウトポイントがTx1に固有であるからである。従って、これらのシグネチャは特性3を満たす。
【0094】
また、これらは非スクリプト・シグネチャであるので、特性1及び2も満たす。従って、この第3のケースは、データ・アプリケーション・レベルでのシグネチャ検証に使用されるオン・チェーン・デジタル・シグネチャにとって望ましい3つの特性全てを満たす。例示のために、図8はアウトプット・シグネチャSigP0”を含む例示的なトランザクションTxID3を示す。署名されたアウトプットは破線内に示されている。
【0095】
例示的なユース・ケース － メタネット・トランザクション
例示の目的で図5を参照すると、特定の実装とともに使用される実施形態を示すシナリオが提供されている。このシナリオでは、基礎となるブロックチェーンはビットコイン・ブロックチェーンであり、データ指向アプリケーションが、WO 2020/109908に実質的に開示されているようなメタネット（Metanet）プロトコルに従って形成されており、同出願の内容全体は本件に援用される。メタネット・プロトコルに関する更なる情報は以下において得ることができる：
https://wiki.bitcoinsv.io/index.php/The_Metanet
なお、より詳細な説明は、以下の「メタネットの詳細」と題するセクションにも記載されている。
例示の目的で図5を参照すると、特定の実装とともに使用される実施形態を示すシナリオが提供されている。このシナリオでは、基礎となるブロックチェーンはビットコイン・ブロックチェーンであり、データ指向アプリケーションが、WO 2020/109908に実質的に開示されているようなメタネット（Metanet）プロトコルに従って形成されており、同出願の内容全体は本件に援用される。メタネット・プロトコルに関する更なる情報は以下において得ることができる：
https://wiki.bitcoinsv.io/index.php/The_Metanet
なお、より詳細な説明は、以下の「メタネットの詳細」と題するセクションにも記載されている。
【0096】
しかしながら、要約すると、メタネットは、データを記憶し、構造化し、アクセスし、索引付けするために、インターネットに対してブロックチェーン・ベースの代替を提供するアプリケーション・レイヤ・プロトコルである。データは、我々がノードと言及することになるブロックチェーン上のトランザクションに格納される（又はトランザクションから参照される）。各メタネット・ノードは、それがメタネット・プロトコルに従って形成されており、従って、メタネット・ベース実装手段によって識別できること、を指示するためのフラグを含む。また、各メタネット・ノードは、公開鍵（DPK）及びトランザクションID（DTxID）も含み、これらは、基礎となるブロックチェーン（ビットコイン）プロトコルにより必要とされる公開鍵及びトランザクションIDに加えて且つこれらとは別個に提供される、という意味で「任意的（discretionary）」と言及することになる。メタネット・ノードのDPK及びDTxIDは、メタネット内のデータの所与の部分に対するインデックス又はアドレスとして機能するように組み合わせて使用されることが可能であり、また、データを含むノードのグラフ状の構造を形成する関連トランザクションの論理階層の構築を可能にする。このようなグラフの非常にシンプルな例が、例示の目的で図5に示されているが、更により複雑な構造を作成することができる、ということは理解されるであろう。グラフ内のノードは、エッジを介して、より上位の階層レベル及びより下位の階層レベルに構造化される。親ノード501（即ち、より下位のレベルのノード及びより上位のレベルのノードそれぞれ）から子ノード502を作成するために、それらの間のエッジが、親ノードの鍵（key）から導出された有効なシグネチャを使用して作成される。一部の実装では、子が1つ以上の親を有することが可能である。
【0097】
従って、メタネットの実装（並びにその他のブロックチェーン実装データ・アプリケーション）において、所与のノード/トランザクションのシグネチャ及び公開鍵を検証できることが重要である、ということは明らかである。上記のケース1で説明された従来のマイナー・ベースの検証では、シグネチャは、親ノード内のインプットのアンロッキング・スクリプトに配置される。
【0098】
しかしながら、マイナー検証アプローチを使用すると、それは、先行するトランザクションのアウトプットのロッキング・スクリプトからのデータを必要として、それは、検証エンティティにとって利用可能でない場合がある。リーダー/ユーザー/アプリケーションがマイナー検証アプローチ自体を明示的に実行したり又はトリガしたりしない場合、有効でないシグネチャを、ノードのトランザクションのアンロッキング・スクリプトに挿入してしまう可能性があり、ブロックチェーン・ネットワークにおけるマイナーは、それでもこれを有効なものとして受け入れるであろう。これは、アンロッキング・スクリプトの形式が、必ずしも先行するアンロッキング・スクリプトの特定の形式を示すとは限らないからである（即ち、特に、ジェネシス（Genesis）がBSVでアップグレードされた後であり、その場合、「標準」スクリプト・タイプの概念は廃止されている）。
【0099】
従って、表向きには（ostensibly）有効なシグネチャ及び公開鍵であるメタネット・ノードにおけるアンロッキング・スクリプトは、必ずしもそうであるとは限らず、確認のためにマイナー検証手法を使用して明示的にチェックされる必要がある。この明示的なチェックが行われない場合、表向きのシグネチャ（及び公開鍵）は、有効でない可能性があるか、又はシグネチャ（及び公開鍵）のように見えるようにフォーマットされた何らかのランダム・データであるに過ぎない可能性がある。その結果、有効な子ノードのように見える、見かけ上のメタネット子ノードを作成することが可能であり、なぜなら、ブロックチェーン・プロトコルの構文要件に従ってはいるが、親からの有効なシグネチャを含んでいないからである。これは、マイナーによって必ずしも拒絶されるとは限らず、なぜなら、有効でないシグネチャを含むアンロッキング・スクリプトは、特定のアンロッキング・スクリプト（例えば、ロッキング・スクリプト：OP_1 OP_DROP OP_DROP，アンロッキング・スクリプト：<Fake Signature> <Fake Public Key>）を依然として満たすことができるからである。
【0100】
従って、UTXO検証レベルでビットコイン・マイナーによって実行される従来のシグネチャ検証は、このアプリケーション・レイヤのシナリオにおいて信頼することはできない。
【0101】
本開示の実施形態は、インプットのアンロッキング・スクリプトからメタネット・シグネチャを移動させ、それをトランザクション中の他の場所（好ましくは、アウトプット）に追加し、かくて、マイナーによる検証を当てにする必要性を取り除き、次いで、トランザクションそのもの以外からのデータを、署名するメッセージに含める必要性を取り除くことによって、その潜在的な悪用を克服する。ここで、メッセージは、任意のタイプのシグネチャ方式によって署名されることが可能である。更に、新たな検証アプローチは、トランザクションに対して外的に供給されるシグネチャに依存することなく、その場で（即ち、自己完結的な方法で、トランザクション自体の中で提供されるデータのみを使用して）実行される。メタネット・シグネチャ検証を、マイナーによって実施される基礎となるプロトコルから分離することによって、セキュリティを保全するだけでなく、より柔軟性のある検証メカニズムを提供するという恩恵も得られ、なぜなら1つの指定されたタイプのシグネチャ方式を使用することに対する制限は取り除かれるからである。
【0102】
このような実施形態を使用して、メタネットのようなデータ・アプリケーションを実装するコンピュータ・ベースのリソース（例えば、アプリケーション、ボット、オラクル等）は、アンロッキング・スクリプトの外部に提供される署名されたメッセージであって、それが位置するトランザクションにそれを一意に関連付けるデータを含む署名されたメッセージに基づいて、シグネチャ検証を実行するように構成することが可能である。
【0103】
これは、ブロックチェーンで使用される従来のマイナー実行型シグネチャ検証についての重要な再構築であり、従来方法は、その名前が示すように、シグネチャをそれらの間で渡すインプットに対するアウトプットを介して、あるトランザクションを別のトランザクションに結び付ける又はチェーン化して、伝送が正しい受信者へ送信されていることを保証することを必要とする。実施形態によれば、個々のトランザクション間でシグネチャのチェーン化や依存性は存在しない。
【0104】
メタネットの詳細
データをトランザクション内に提供することによって、データをブロックチェーンにどのように挿入できるのかは、概要で説明されている。完全を期すために、図5を参照しながら、ここで、メタネット・プロトコルに関する更なる詳細を提示し、メタネット・プロトコルは、インターネットに対するブロックチェーン実装代替例において、ノードのアドレス指定、許可、及びコンテンツ・バージョン制御を可能にする論理的な方法でトランザクションを構造化するために使用することが可能である。
データをトランザクション内に提供することによって、データをブロックチェーンにどのように挿入できるのかは、概要で説明されている。完全を期すために、図5を参照しながら、ここで、メタネット・プロトコルに関する更なる詳細を提示し、メタネット・プロトコルは、インターネットに対するブロックチェーン実装代替例において、ノードのアドレス指定、許可、及びコンテンツ・バージョン制御を可能にする論理的な方法でトランザクションを構造化するために使用することが可能である。
【0105】
ここで説明される構造の目的は：
（i）異なるトランザクション内の関連コンテンツを関連付けて、データの検索、識別、及びアクセスを可能にすること
（ii）人間が読み取ることが可能なキーワード検索を使用してコンテンツの特定を可能にして、検索の速度、精度、及び効率を改善すること
（iii）ブロックチェーン内にサーバーのような構造を構築し、エミュレートすることである。
（i）異なるトランザクション内の関連コンテンツを関連付けて、データの検索、識別、及びアクセスを可能にすること
（ii）人間が読み取ることが可能なキーワード検索を使用してコンテンツの特定を可能にして、検索の速度、精度、及び効率を改善すること
（iii）ブロックチェーン内にサーバーのような構造を構築し、エミュレートすることである。
【0106】
メタネット・アプローチは、データを有向グラフ（directed graph）として構造化するものである。このグラフのノードとエッジは、以下のNodeとEdgeに対応する：
Node － メタネット・プロトコルに関連するトランザクション。ノードはコンテンツを格納する（「コンテンツ」及び「データ」という用語は、本件明細書では交換可能に使用されることが可能である）。ノードは、OP_RETURN を含むことによって作成され、OP_RETURN の直後に<Metanet Flag>が続く。各ノードには公開鍵Pnodeが割り当てられる。公開鍵とトランザクションIDとの組み合わせは、ノードのインデックスを一意に指定する：
Node － メタネット・プロトコルに関連するトランザクション。ノードはコンテンツを格納する（「コンテンツ」及び「データ」という用語は、本件明細書では交換可能に使用されることが可能である）。ノードは、OP_RETURN を含むことによって作成され、OP_RETURN の直後に<Metanet Flag>が続く。各ノードには公開鍵Pnodeが割り当てられる。公開鍵とトランザクションIDとの組み合わせは、ノードのインデックスを一意に指定する：
【0107】
【数1】
Edge － 子ノードの親ノードとの関連性（アソシエーション）。シグネチャSigPparentがメタネット・トランザクションのインプットに現れている場合、エッジが作成され、従って、親のみがエッジを作成する許可を与えることが可能である。全てのノードは、多くとも1つの親を有する可能性があり、親ノードは、任意の数の子を有する可能性がある。グラフ理論の言葉で言えば、各ノードの入次数（indegree）は最大で1であり、各ノードの出次数（outdegree）は任意である。
エッジは、メタネット・プロトコルの一側面であり、それ自体は、基礎となるブロックチェーンに関連付けられたトランザクションではない、ということに留意すべきである。
【0108】
有効なメタネット・ノード（親を伴うもの）は、以下の形式のトランザクションによって与えられる：
【0109】
【数2】
【0110】
このトランザクションは、ノード及びその親のインデックスを指定するために必要な全ての情報を含む。
【0111】
【数3】
【0112】
注記：メタネット・ノードは、1つより多い親を有することが可能であるが、説明を簡単にするために、ここでは1つの親のみを含む例を使用している。更に、少なくとも1つの親ノードのシグネチャが要求されるので、親のみが、子に至るエッジを作成することができる。<TxIDparent>フィールドが存在しないか、又は有効なメタネット・トランザクションを指し示していない場合、そのノードはオーファン（orphan）である。それは、到達することが可能なより高いレベルのノードを有しない。追加の属性が各ノードに追加されてもよい。これらは、フラグ、名称、及びキーワードを含む可能性がある。これらは以下で説明される。
【0113】
図示のように、ノード（トランザクション）のインデックスは、以下のように分解することができる：
a）公開鍵Pnode ，ノードのアドレスとして解釈される。
b）トランザクションID TxIDnode ，ノードのバージョンとして解釈される。
a）公開鍵Pnode ，ノードのアドレスとして解釈される。
b）トランザクションID TxIDnode ，ノードのバージョンとして解釈される。
【0114】
この構造化から、2つの有利な特徴が生じる：
1．バージョン制御 － 同じ公開鍵を有する2つのノードが存在する場合、我々は、最大のプルーフ・オブ・ワークを伴うトランザクションIDを有するノードを、そのノードの最新バージョンとして解釈する。ノードが異なるブロックにある場合、それはブロック高さでチェックすることが可能である。同じブロック内のトランザクションについては、これはトポロジカル・トランザクション・オーダリング・ルール（Topological Transaction Ordering Rule，TTOR）によって決定される。
1．バージョン制御 － 同じ公開鍵を有する2つのノードが存在する場合、我々は、最大のプルーフ・オブ・ワークを伴うトランザクションIDを有するノードを、そのノードの最新バージョンとして解釈する。ノードが異なるブロックにある場合、それはブロック高さでチェックすることが可能である。同じブロック内のトランザクションについては、これはトポロジカル・トランザクション・オーダリング・ルール（Topological Transaction Ordering Rule，TTOR）によって決定される。
【0115】
2．許可（permissioning）－ ノードの子は、公開鍵Pnodeの所有者が、子ノードの作成におけるトランザクション・インプットに署名する場合に限り、作成されることが可能である。従って、Pnodeは、ノードのアドレスを表すだけでなく、子ノードを作成する許可も表す。これは、意図的に、標準的なビットコイン・トランザクション、即ち、アドレスだけでなく、そのアドレスに関連付けられた許可における公開鍵に類似している。
親ノードのシグネチャはUXT0アンロッキング・スクリプトに現れるので、トランザクションがネットワークに受け入れられた時点で、標準的なマイナー検証プロセスを通じて検証される、ということに留意されたい。これは、子ノードを作成する許可が、ビットコイン・ネットワーク自体によって検証されることを意味する。
親ノードのシグネチャはUXT0アンロッキング・スクリプトに現れるので、トランザクションがネットワークに受け入れられた時点で、標準的なマイナー検証プロセスを通じて検証される、ということに留意されたい。これは、子ノードを作成する許可が、ビットコイン・ネットワーク自体によって検証されることを意味する。
【0116】
ノード及びエッジ構造は、図5に示されるように、メタネットをグラフとして視覚化することを可能にする。
【0117】
従って、メタネット・グラフの階層は、豊富なドメインのような構造が出現することを可能にする。我々は、オーファン・ノードをトップ・レベル・ドメイン（top-level domain，TLD）として解釈し、オーファン・ノードの子をサブ・ドメインとして解釈し、孫をサブ・サブ・ドメインとして解釈し、等々、子のないノードをエンド・ポイントとして解釈する。
【0118】
ドメイン名は、IDnodeとして解釈される。メタネット内の各トップ・レベル・ドメインは、ルート（root）がオーファン・ノードであり、リーフ（leaf，leaves）が子なしノードであるツリーとして考えられてもよい。メタネットそれ自体は、グラフを形成するツリーのグローバルな集まりである。メタネット・プロトコルは、何らかのノードがコンテンツ・データを含むことを規定していないが、リーフ（子なし）ノードは、データ・ツリー上の有向パスの終端を表し、従って、一般的には、コンテンツ・データを記憶するために使用されるであろう。しかしながら、コンテンツは、ツリー内の任意のノードに格納されてもよい。属性としてノードに含まれるプロトコル固有のフラグは、データ・ツリー内のノードの役割（ディスク空間、フォルダ、ファイル、又は変更の許可）を指定するために使用されることが可能である。
【0119】
インターネットは、人間が読むことが可能な名称を、インターネット・プロトコル（IP）アドレスに関連付けるために、ドメイン・ネーム・システム（Domain Name System，DNS）を使用していることを想起されたい。DNSは、ある意味では分散化されているが、実際には、政府や大企業のような少数のキー・プレーヤによって制御されている。あなたのDNSプロバイダに応じて、同じ名前があなたを異なるアドレスに導く可能性がある。この問題は、人間が読むことが可能な短い名称を、コンピュータが生成した番号にマッピングする場合に本来的に備わっている。
【0120】
メタネットは、人間が読むことが可能なトップ・レベルのドメイン名を、ルート・ノードの分散化されたインデックスIDrootにマッピングする等価な分散システムを使用する。換言すれば、1-1関数κは、人間が読むことが可能な名称を、メタネット・ルート・ノード・インデックスに、例えば次のようにマッピングする。
【0121】
【数4】
【0122】
左辺に対する入力は人間が読むことが可能なワードであり、右辺における出力はハッシュ・ダイジェストであって典型的には256ビット・データ構造となるものである。なお、PbobsblogとTxIDbobsblogも一般的には人間が読むことはできなことに留意されたい。標準IPプロトコルでは、これは、www.bobsblog.comから、ネットワーク内の対応するドメインのIPアドレスへのマッピングである。
【0123】
写像（map）κは、DNS発行ドメイン名の人間による可読性を再現する際にインターネットに対するメタネットの後方互換性を保証するための尺度として解釈されるべきであるが、メタネットの構造を提供するネーミング及びアドレス指定方式は、この写像に明示的には依存しない。
【0124】
マッピング関数κの可能性のある既存の形式は、例えば、IPFS（Interplanetary File System）で採用されているDNSLinkシステムや、OpenNICサービス（https://www.openic.org）を含む。このマッピングは、DNSの一部として、既存のTXTレコードに格納することが可能である。これは、IPFSにおけるDNSLinkに類似しており、これについては、以下を参照されたい：
https://docs.ipfs.io/guides/concepts/dnslink/
しかしながら、一般に、これらは、1-1である写像を提供するために、分散化の幾らかの要素を犠牲にし、これについては以下を参照されたい：
https://hackernoon.com/ten-terrible-attempts-to-make-the-inter-planetary-file-system-human-friendly-e4e95df0c6fa
https://docs.ipfs.io/guides/concepts/dnslink/
しかしながら、一般に、これらは、1-1である写像を提供するために、分散化の幾らかの要素を犠牲にし、これについては以下を参照されたい：
https://hackernoon.com/ten-terrible-attempts-to-make-the-inter-planetary-file-system-human-friendly-e4e95df0c6fa
【0125】
メタネット・ノードのアドレスとして使用される公開鍵は、人間が読み取ることが可能なオブジェクトではない。これは、人間のユーザーにとって、検索、参照、及び入力の動作を、誤りやすくしたり遅くしたりする可能性がある。しかしながら、人間が認識可能な公開鍵アドレス－バニティ・アドレス（vanity addresses）Pvanityを作成することが可能であり、これは、ユーザーによって直接的に解釈されることが可能な平文プレフィックス（plaintext prefix）を含む。バニティ・アドレスは従来技術においても知られている。
【0126】
このようなアドレスを作成する際の困難性は、所望のプレフィックスのキャラクタ長に依存する。これは、人間が認識可能なバニティ・アドレスが、中央発行ではない、作成する所有者の労力のみに依存するノード・アドレスとして使用されてもよい、ということを意味する。所与のプレフィックスに対して、サフィックスに残るキャラクタに起因して、多くの異なるバニティ・アドレスが存在し、従って、多くのノード・アドレスは、共通のプレフィックスを共有できる一方で、依然として一意性を保持することができる。望ましいプレフィックスを有するバニティ・アドレスの例は、例えば次のようなものである：
Pbobsblog：bobsblogHtKNngkdXEeobR76b53LETtpyT
Prefix: bobsblog
Suffix: HtKNngkdXEeobR76b53LETtpyT
Pbobsblog：bobsblogHtKNngkdXEeobR76b53LETtpyT
Prefix: bobsblog
Suffix: HtKNngkdXEeobR76b53LETtpyT
【0127】
上記のバニティ・アドレスは、名称「bobsblog」からノード・インデックスIDbobsblogへの写像を検知チェックし、アドレスによるメタネット・ノードの検索可能性を支援するために使用されることが可能である。ここで、プレフィックスは一意ではないが、アドレス全体それ自体は一意のエンティティである、ということに留意されたい。
【0128】
一緒にIDnodeを形成する、選択されたアドレスPvanityのTxIDとの組み合わせもまた有用であり、なぜなら、それはドメイン名の中央発行者が存在しないことを意味し（TxIDは、分散されたプルーフ・オブ・ワークによって生成される）、その名称はブロックチェーンそれ自体から復元可能だからである。有利なことに、インターネットDNS内に存在する障害地点はもはや存在しない。
【0129】
Metanetドメインは、既に許可システム（公開鍵）を提供しているので、所有権（ownership）を証明するために証明書（certificate）を発行する必要はない。この目的のためにブロックチェーンを利用することは、例えば、namecoin（https://namecoin.org/）において既に探索されている。しかしながら、本発明によれば、この機能のために別個のブロックチェーンを使用する必要はなく、なぜなら全てが1つのブロックチェーン内で達成されるからである。これは、本発明によって必要とされるリソース（ハードウェア、処理リソース、及びエネルギー）の量を、従来技術と比較して著しく低減する。またそれは装置及びシステム構成要素の配置の観点から言えば、全く異なるアーキテクチャを提供する。このネーミング・システムの利点は、ユーザーが、ハッシュ・ダイジェストではなく、記憶に残る言葉（例えば、会社名）によって、メタネット内のトップ・レベル・ドメインを識別することができる、ということである。また、このことはドメインの検索を高速化し、なぜならハッシュ・ダイジェストではなくキーワードを検索する方がより迅速だからである。また、入力エラーを低減し、従って、ブロックチェーン格納データのための改善された検索ツールを提供する。
【0130】
ドメイン名からノード・インデックスへの写像が存在する仮定の下で、インターネットのユニフォーム・リソース・ロケータ（Uniform Resource Locator，URL）のものに類似するリソース・ロケータを構築することが可能である。これは、メタネットURL（Metanet URL，MURL）と呼ぶことが可能であり、次の形式をとる：
【0131】
【数5】
【0132】
URLの構成要素の各々（即ち、プロトコル、ドメイン名、パス、及びファイル）は、MURLの構造にマッピングされており、オブジェクトを、ユーザーにとってより直感的に理解できるようにし、それをインターネットの既存の構造に統合できるようにする。これは、各ノードが、ドメイン・ツリー内のそのレベルで一意であるその公開鍵（アドレス）に関連付けられた名称を有する、ということを仮定している。この名称は、常に、所与のノードのMURLの右端の構成要素である。ツリー内で同じレベルにある2つのノードが同じ名称を有する場合、それらは同じ公開鍵を有することになり、従って最新バージョンが取られる。
【0133】
メタネット検索
上記は、各ノードが一意のインデックスを有し、それに起因する名前を有することが可能であるようにするメタネット・グラフ構造の実施形態を説明している。これは、MURLを使用してコンテンツが見出されることを可能にする。また、高速検索機能を可能にするために、メタネット・プロトコルは、追加のキーワードが、ノードに起因することを許容する。ノードの固定した属性（fixed attributes）は、そのインデックスと親ノードのインデックスであり、オプション属性は名称とキーワードである。
上記は、各ノードが一意のインデックスを有し、それに起因する名前を有することが可能であるようにするメタネット・グラフ構造の実施形態を説明している。これは、MURLを使用してコンテンツが見出されることを可能にする。また、高速検索機能を可能にするために、メタネット・プロトコルは、追加のキーワードが、ノードに起因することを許容する。ノードの固定した属性（fixed attributes）は、そのインデックスと親ノードのインデックスであり、オプション属性は名称とキーワードである。
【0134】
【数6】
【0135】
一例では、メタネットを検索するための実際的な方法は、先ず、ブロック・エクスプローラを使用して、ブロックチェーンを介して探索（trawl）し、メタネット・フラグを有する全てのトランザクションを特定し、それらが有効なメタネット・ノードであることをチェックし、そうである場合には、それらのインデックスとキーワードを、データベース又はその他の記憶リソースに記録することであってもよい。このデータベースは、所望のキーワードを用いてノードを効率的に検索するために使用されることが可能である。所望のキーワードを有するノードのインデックスが発見されると、そのコンテンツをブロック・エクスプローラから取り出し、閲覧することができる。また、メタネットは、ノード・トランザクションによって格納されるコンテンツのハッシュを、追加の属性として格納することによって、コンテンツ・アドレス指定可能ネットワーク（content addressable network，CAN）を組み込むことが可能である、ということに留意されたい。これは、メタネット・ノードがコンテンツ・ハッシュによってもインデックス付けされ、検索され得ることを意味する。
【0136】
ブラウザ・ウォレット・アプリケーション
メタネット・プロトコルでは、全てのデータがブロックチェーン自体に直接的に存在する、ということを想起されたい。ブロックチェーンに格納されたメタネット・データに効率的にアクセスし、表示し、対話することが可能なツール及びアプリケーションを構築することが可能である（単なる便宜上のために「ブラウザ・ウォレット」と呼ぶ）。
メタネット・プロトコルでは、全てのデータがブロックチェーン自体に直接的に存在する、ということを想起されたい。ブロックチェーンに格納されたメタネット・データに効率的にアクセスし、表示し、対話することが可能なツール及びアプリケーションを構築することが可能である（単なる便宜上のために「ブラウザ・ウォレット」と呼ぶ）。
【0137】
ブラウザ・ウォレットは、エンド・ユーザーが、ブロックチェーン上のメタネット・インフラストラクチャと対話することを可能にするように意図されたアプリケーションである。このアプリケーションは、ツリーに埋め込まれた特定のコンテンツについてのメタネット・グラフの探索的サーチ（explorative searches）を可能にするはずである。更に、ブラウザ・ウォレットは、コンテンツの検索、解読、再構成、及びキャッシング（オプション）を処理するであろう。ブラウザ・ウォレット・アプリケーションは、ネイティブの（又は外的な）ウォレットをサポートすることによって、これらの要素を、暗号通貨支払メカニズムと組み合わせる。ブラウザ・ウォレットは、以下のコア要素を含むことが可能である。
【0138】
・ブロックチェーン・サーチ・エンジン － 第三者サーチ・エンジンが、IDnode、ノード名、キーワード、ブロック高さ、及びTxIDを含む様々なインデックスによって、メタネット・ノードを照会するためのサポートである。
【0139】
・表示ウィンドウ － フル・コピー・ブロックチェーン・ピアによってブラウザに返されるコンテンツをアンパックするソフトウェアである。 これは、アクセス・トークンの解読、再結合、キャッシング、及び償還をカバーする。
【0140】
・暗号通貨ウォレット － ブロックチェーンの通貨のための専用鍵管理である。アプリケーションにとってネイティブであるか、又は外部ウォレット（ソフトウェア又はハードウェア）と通信して同期することを認可されることが可能である。標準ブロックチェーン・トランザクション並びに新しいメタネット・ノード・トランザクションを書くことが可能である。アクセス鍵及びアクセス・トークンのオン・チェーン購入を仲介することが可能である。
【0141】
・階層的な決定論的鍵管理が、暗号通貨公開鍵とメタネット・ノード・アドレスの両方に対して活用される。
【0142】
・アクセス鍵／トークン・ウォレット － 購入されたアクセス鍵又はトークンのための専用鍵管理である。 暗号通貨ウォレットを使用して、購入した鍵又はトークンを受信することは可能であるが、それらに対する許可（permissions）を有しない。 それらは、後に失効を可能にするために、ユーザーに対して隠される可能性がある。 これは、信頼できる実行環境の使用を通じて達成することが可能である。時限アクセス（Timed-access）は、ブロックチェーンと同期し、現在のブロック高さを照会することによって、安全にされることが可能である。
【0143】
メタネット・ブラウザ・ウォレットの仕様は、以下の機能を含む：
1．階層的鍵管理 － 資金を制御し、メタネット・ツリー（グラフ）を管理するために使用される鍵は、同じ階層決定論的鍵インフラストラクチャを利用し、ユーザーがそのメタネット・コンテンツに関する鍵の記録を維持する負担を軽減する。
1．階層的鍵管理 － 資金を制御し、メタネット・ツリー（グラフ）を管理するために使用される鍵は、同じ階層決定論的鍵インフラストラクチャを利用し、ユーザーがそのメタネット・コンテンツに関する鍵の記録を維持する負担を軽減する。
【0144】
2．外部暗号通貨ウォレットに対する指示 － 外部の（アプリケーションにとってネイティブではない）ウォレットを認可して同期する機能は、ブラウザ・ウォレットを、障害のポイントとして除去することによって、追加のセキュリティを可能にする。アプリケーションは、ブロックチェーン・トランザクションを書き込み、鍵を収容する外部ウォレットのシグネチャを要求し、この責任を、別個のソフトウェア又はハードウェアに委託することができる。
【0145】
3．メタネット・コンテンツの検索 － ブラウザ・ウォレットは、第三者サーチ・エンジンをサポートして照会することが可能であり、その第三者サーチ・エンジンの機能は、グローバル・データベース内のメタネット・ノード・トランザクション・データをクローリングし（crawling）、インデックス付けし、応対し、及びランキングすることを含む可能性がある。メタネット・プロトコル・フラグを含むOP_RETURNトランザクションのデータベースが構築されてもよい。これについては、以下を参照されたい
BitDB 2.0 - https://bitdb.network/.
サーチ・エンジンは、データが発見されることを可能にするノード・インデックスを用いてブラウザ・ウォレットに応対することが可能である。
BitDB 2.0 - https://bitdb.network/.
サーチ・エンジンは、データが発見されることを可能にするノード・インデックスを用いてブラウザ・ウォレットに応対することが可能である。
【0146】
4．ブロックチェーンに対するデータの読み込み及び書き込み － コンテンツを用いてブラウザに応対するためにサーチ・エンジン及びフル・ノードを使用することに加えて、暗号通貨ウォレットをサポートすることは、コンテンツが、ブラウザ・ウォレットから直接的にメタネットに書き込まれることも可能にする。
【0147】
5．データの解凍及び暗号解読 － ブラウザ・ウォレットは、暗号解読鍵を取り扱い、その場でメタネット・コンテンツに対する解凍を実行することが可能である。
【0148】
6．キャッシング・ノード識別（IDnode）－ ユニークなノード識別子は、より効率的なルックアップ及びクエリ処理のためにローカルにキャッシュされることが可能である。
【0149】
7．ウェブ・サーバーのバイパス － ノード・インデックスが与えられると、ブラウザ・ウォレットは、ノードにあるコンテンツについて、ピア・ツー・ピア（P2P）ブロックチェーン・ネットワークの任意のフル・コピー・メンバを照会することが可能である。メタネットは、オン・チェーン上にあるので、如何なるフル・コピー・ピアも、ノード及びそのコンテンツのローカル・コピーを有していなければならない。これは、ユーザーのブラウザ・ウォレットが単一のピアを照会することだけを必要とすることを意味し、これは、直接的に且つ中間ウェブ・サーバーを必要とせずに行うことができる。図15は、ブラウザ・ウォレットの概略と、そのコア機能がアプリケーションの異なるコンポーネントにわたってどのように分割されるかを示す。
【0150】
メタネット・サーチ・エンジン
ブラウザ・ウォレット・アプリケーションは、ノード識別子（IDnode）の発見のために、第三者サーチ・エンジンと通信する。第三者は、既存のインターネット・サーチ・エンジンの能力を複製するサービスを提供することが可能である。メタネット第三者サーチ・エンジンは、メタネット・プロトコル・フラグによって識別可能な、ブロックチェーンにマイニングされた全てのメタネット・トランザクションのデータベースを維持する。このデータベースは、ノード名、キーワード、TxID、及びロック高さを含むレンジ・インデックスによって、全てのメタネット・ノードをカタログ化することができる。
ブラウザ・ウォレット・アプリケーションは、ノード識別子（IDnode）の発見のために、第三者サーチ・エンジンと通信する。第三者は、既存のインターネット・サーチ・エンジンの能力を複製するサービスを提供することが可能である。メタネット第三者サーチ・エンジンは、メタネット・プロトコル・フラグによって識別可能な、ブロックチェーンにマイニングされた全てのメタネット・トランザクションのデータベースを維持する。このデータベースは、ノード名、キーワード、TxID、及びロック高さを含むレンジ・インデックスによって、全てのメタネット・ノードをカタログ化することができる。
【0151】
ブロックチェーンと継続的に同期し、トランザクション・データを標準データベース・フォーマットで維持するサービスが知られている。ブラウザ・ウォレットは、メタネット・トランザクションのクローリング、インデックス付け、サービス提供、及びランキングの責任を、そのような第三者にオフロードし、それらのサービスへの接続を、メタネット・グラフに記憶されたコンテンツを見出す際に行う。
【0152】
メタネット・データに専用のデータベースを有することによって、効率的な節約を行う可能性がある。ビットDBとは異なり、これは、全てのトランザクションに関連するデータを記憶するのではなく、メタネット・フラグを含むデータのみを記憶する。MongoDBのような非リレーショナル・データベースなどの特定のデータベースは、メタネットのグラフ構造を格納する際に、より効率的である可能性がある。これは、より高速なクエリ処理、より少ない記憶空間、及び、メタネット・ドメイン内の関連コンテンツのより効率的な関連付けを可能にするであろう。このプロセスは以下の通りである。
【0153】
1．エンド・ユーザーが、ブラウザ・ウォレット検索バーにキーワードを入力する。
【0154】
2．ブラウザ・ウォレットが、キーワード・クエリを第三者SEへ送信する。
【0155】
3．SEは、そのデータベースに対してキーワードをチェックし、関連コンテンツを含む何らかのメタネット・ノードに対するIDnodeを返す。また、第三者は、各ノードに関する他のインデックスもユーザーに返し、関連するコンテンツの提案を提供することも可能である。
【0156】
4．ブラウザ・ウォレットは、ノード識別子及びそれに関連付けられたドメイン名を使用して、MURLを構築する。
【0157】
5．ブラウザ・ウォレットは、ブロックチェーンの完全なコピーを有する任意のネットワーク・ピアからの、指定されたノードに属するコンテンツを要求する。
【0158】
6．ネットワーク・ピアは、要求されたコンテンツをブラウザ・ウォレットに供給する。ピアはブロックチェーンのコピーを有するので、それらはコンテンツのコピーも有していなければならず、従って、1つの要求のみが行われ、他のネットワーク・ピアに転送されることはない。
【0159】
コンテンツ表示 － メタネット・ブラウザ
ブラウザ・ウォレット・アプリケーションは、任意の典型的なウェブ・ブラウザが提供すべきものと同じフロント・エンド機能をエミュレートする。 これらの機能は、以下を含むが、これらに限定されない。
ブラウザ・ウォレット・アプリケーションは、任意の典型的なウェブ・ブラウザが提供すべきものと同じフロント・エンド機能をエミュレートする。 これらの機能は、以下を含むが、これらに限定されない。
【0160】
1．検索 － コンテンツを発見するためにサーチ・エンジン（SE）に対するのアクセスを提供する。
【0161】
2．抽出 － 既知のプロトコル、例えば、ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol，HTTP）を使用して、コンテンツの転送を促進するために、サーバーと通信する。
【0162】
3．解釈 － （例えば、JavaScript（登録商標）における）生コード（raw code）を解析し、実行する。
【0163】
4．レンダリング － エンド・ユーザーによって閲覧されることになる解析されたコンテンツの効率的な表示を行う。
【0164】
5．ユーザー・インターフェース（UI） － ユーザー入力のためのアクション・ボタン及びメカニズムを含む、コンテンツのやり取りのための直感的なインターフェースをユーザーに提供する。
【0165】
6．ストレージ － コンテンツに対する反復的なアクセスを改善するために、インターネット・コンテンツ、クッキー等をキャッシュするためのローカルな一時記憶機能である。
【0166】
特定の実施形態において、ウェブ・ブラウザとして機能することを担うブラウザ・ウォレット・アプリケーションのソフトウェア・コンポーネントは、ブロックチェーンに埋め込まれたメタネット・コンテンツに対して、上記の機能を実行することが可能であり、（SEを用いて）検索可能であり且つそれらの属性を用いて（ピアから）取得可能である。
【0167】
本発明の特定の実施形態によれば、ブラウザ・ウォレット・アプリケーションのウェブ・ブラウザ・ソフトウェア・コンポーネントは、所与のメタネット・コンテンツに対して実行されることを必要とする全ての動作を処理することが可能である。一般に、実行されることを必要とするそのような動作は多数存在するが、我々は、メタネット・プロトコル及びインフラストラクチャを使用するアプリケーションによって、少なくとも以下のものが実行されることを仮定する。
【0168】
・再結合（Recombination）－ メタネット・コンテンツが分割されて、複数の別個のノード・トランザクションに挿入される必要がある場合、アプリケーションは、全ての関連するノードからコンテンツを要求し、元のコンテンツを再構成する。分割されたコンテンツの順序付け及び構造は、各ノードの属性における追加のフラグを使用して、エンコードされることが可能である。
【0169】
・復元（Decompression）－ コンテンツ・データが、圧縮された形式でブロックチェーンに格納されている場合、それは、どの標準圧縮方式が使用されているかをブラウザ・ウォレットに示すためのフラグを含むべきである。アプリケーションは、このフラグに従ってコンテンツを復元するであろう。
【0170】
・暗号解読（Decryption）－ コンテンツが暗号化される場合、暗号化方式を示すために、フラグが使用されるべきである。アプリケーションは、（以下で説明されるように）その解読鍵ウォレットから鍵を探し出し、使用される暗号化方式に従って、使用するコンテンツ・データを解読する。
【0171】
コンテンツ・データに対してこれらの処理を実行する際に、所与の処理が実行される必要があることを、ブラウザ・ウォレットに知らせるために、フラグを使用することが可能である。これは、任意の他の処理に一般化され、その処理に対して、適切な<operation_flag>が、処理を適用するノードの属性の一部として含まれることが可能である。
【0172】
キャッシング
ローカル・ファイル及びクッキーのキャッシングは、典型的なウェブ・ブラウザの一般的かつ重要な機能である。また、ブラウザ・ウォレット・アプリケーションは、同様にローカル・ストレージを使用して、オプションとして、IDnode及びその他のノード属性であって関心のあるコンテンツに関連するものを保持する。これは、頻繁に訪れるメタネット・ノードからのコンテンツのより効率的なルックアップ及び検索を可能にする。メタネットは、インターネット・データをキャッシュすることに固有の問題、即ち、それが変更される可能性があり、また、プロバイダに応じてウェブ・ブラウジング・ソフトウェアによって変更されたり又は検閲されたりする可能性があるという問題を解決する。メタネット・データをキャッシュする場合に、ユーザーは、それが、ブロックチェーン上に変更不能なレコードとして当初含まれた時と同じ状態にあることを、常に、容易に検証することが可能である。
ローカル・ファイル及びクッキーのキャッシングは、典型的なウェブ・ブラウザの一般的かつ重要な機能である。また、ブラウザ・ウォレット・アプリケーションは、同様にローカル・ストレージを使用して、オプションとして、IDnode及びその他のノード属性であって関心のあるコンテンツに関連するものを保持する。これは、頻繁に訪れるメタネット・ノードからのコンテンツのより効率的なルックアップ及び検索を可能にする。メタネットは、インターネット・データをキャッシュすることに固有の問題、即ち、それが変更される可能性があり、また、プロバイダに応じてウェブ・ブラウジング・ソフトウェアによって変更されたり又は検閲されたりする可能性があるという問題を解決する。メタネット・データをキャッシュする場合に、ユーザーは、それが、ブロックチェーン上に変更不能なレコードとして当初含まれた時と同じ状態にあることを、常に、容易に検証することが可能である。
【0173】
暗号通貨ウォレット
決定論的な鍵Dkは、単一の「シード（seed）」鍵から初期化される秘密鍵（private keys）である（これについては例えば、以下を参照されたい：Andreas M. Antonopoulos, Chapter 5 in “Mastering Bitcoin” O’Reilly 2nd Ed., 2017, pp. 93-98）。シードは、マスター鍵として機能するランダムに生成された数である。シードを他のデータ、例えばインデックス番号又は「チェーン・コード」と組み合わせて決定論的な鍵を導出するために、ハッシュ関数を使用することが可能である（例えば、HD Wallets-BIP-32/BIP-44 を参照されたい）。これらの鍵は互いに関連しており、シード鍵を用いて完全に復元可能である。また、シードは、異なるウォレット実装の間でウォレットの容易なインポート/エクスポートを可能にし、ユーザーがメタネット・ブラウザ・ウォレットと併せて外部ウォレットを使用することを望む場合に、更なる自由度を与える。
決定論的な鍵Dkは、単一の「シード（seed）」鍵から初期化される秘密鍵（private keys）である（これについては例えば、以下を参照されたい：Andreas M. Antonopoulos, Chapter 5 in “Mastering Bitcoin” O’Reilly 2nd Ed., 2017, pp. 93-98）。シードは、マスター鍵として機能するランダムに生成された数である。シードを他のデータ、例えばインデックス番号又は「チェーン・コード」と組み合わせて決定論的な鍵を導出するために、ハッシュ関数を使用することが可能である（例えば、HD Wallets-BIP-32/BIP-44 を参照されたい）。これらの鍵は互いに関連しており、シード鍵を用いて完全に復元可能である。また、シードは、異なるウォレット実装の間でウォレットの容易なインポート/エクスポートを可能にし、ユーザーがメタネット・ブラウザ・ウォレットと併せて外部ウォレットを使用することを望む場合に、更なる自由度を与える。
【0174】
階層的な決定論的（hierarchical deterministic，HD）ウォレットは、決定論的な鍵の周知の導出方法である。HDウォレットでは、親の鍵が子の鍵のシーケンスを生成し、子の鍵のシーケンスが孫の鍵のシーケンスを導出する、等々である。このツリー状構造は、幾つかの鍵を管理するための強力な仕組みである。好ましい実施形態では、HDウォレットを、メタネット・アーキテクチャに組み込むことが可能である。
【0175】
有利なことに、本開示の実施形態は、従来のウェブ・ブラウザの機能を、1つ以上の暗号通貨ウォレットと直接的にマージすることができる。これは、基本的には、メタネットが、「インターネット」コンテンツに関する支払いを、エンド・ユーザーに対する配送に組み合わせる方法である。
【0176】
これを達成するために、ブラウザ・ウォレットの実施形態は、暗号通貨ウォレットとして動作する専用の内蔵ソフトウェア・コンポーネントを有してもよい。このウォレットは、アプリケーション自体に本来的なもの（native）であり、暗号通貨秘密鍵を管理し、ブラウザ・ウォレット自体の中のメタネット・コンテンツに対する支払いとして、トランザクションを認可するために使用されることが可能である。これは、アプリケーションのブラウザ・コンポーネントが、暗号解読鍵、アクセス・トークン、又はその他のものを購入することによって、メタネット・コンテンツを閲覧するために必要とされる支払いを認可するように、ウォレット・コンポーネントを促すことが可能である、ということを意味する。アプリケーションは、支払いを処理するために、外部の第三者を呼び出す必要がなく、従って、関心のあるメタネット・コンテンツは、アプリケーションによって消費され、その場で支払われる。
【0177】
ユーザーが、代わりに、外部ウォレット（ソフトウェア又はハードウェア）上でそれらの暗号通貨秘密鍵を管理又は保持したり、あるいは複数のウォレットを使用したりすることさえ望む場合には、同じ利点及び機能を、本件の実施形態によって達成することが可能である。これは、アプリケーションのネイティブ・ウォレットの代わりに、又はそれと併せて実行されてもよい。そのような実施形態では、アプリケーションは、外部ウォレットとのリンク又はペアリングを確立し、それと同期するが、ブラウザ・ウォレット自体に秘密鍵を記憶していない。その代わりに、ブラウザ・コンポーネントがコンテンツに対して支払いが行われるように促すと、アプリケーションは、選択した外部ウォレットからのデジタル・シグネチャによって認可を要求する。この認可はユーザーによって行われ、ブラウザ・ウォレットはトランザクションをブロードキャストし、有料コンテンツを閲覧することができる。
【0178】
メタネット・トランザクションの読み込み及び書き込み
メタネットの本来的な利点は、それが、支払いとコンテンツ・データの両方を記録するために同じデータ構造（ブロックチェーン）を使用することである。これは、ソフトウェア・ウォレットを使用して、単に暗号通貨の交換に基づいているトランザクションを作成することに加えて、コンテンツ・データをメタネット・インフラストラクチャに書き込むことができることを意味する。アプリケーションに内蔵されたネイティブ・ウォレットは、典型的な簡易支払検証（simplified payment verification，SPV）クライアントよりも複雑なトランザクションを、ブロックチェーンに書き込むことが可能であり、これについては、例えば、以下を参照されたい：
https://bitcoin.org/en/glossary/simplified-payment-verification
ウォレットは、ブロックチェーンに埋め込まれるコンテンツ・データを、ユーザーのコンピュータから選択することによって、アプリケーションから直接的にブロックチェーンに、メタネット・ノード・トランザクションを書き込むことを、ユーザーが選択することを可能にする。
メタネットの本来的な利点は、それが、支払いとコンテンツ・データの両方を記録するために同じデータ構造（ブロックチェーン）を使用することである。これは、ソフトウェア・ウォレットを使用して、単に暗号通貨の交換に基づいているトランザクションを作成することに加えて、コンテンツ・データをメタネット・インフラストラクチャに書き込むことができることを意味する。アプリケーションに内蔵されたネイティブ・ウォレットは、典型的な簡易支払検証（simplified payment verification，SPV）クライアントよりも複雑なトランザクションを、ブロックチェーンに書き込むことが可能であり、これについては、例えば、以下を参照されたい：
https://bitcoin.org/en/glossary/simplified-payment-verification
ウォレットは、ブロックチェーンに埋め込まれるコンテンツ・データを、ユーザーのコンピュータから選択することによって、アプリケーションから直接的にブロックチェーンに、メタネット・ノード・トランザクションを書き込むことを、ユーザーが選択することを可能にする。
【0179】
ブラウザ・ウォレット・アプリケーションは、ユーザー・インターフェース（UI）を有するので、ウォレット・コンポーネントは、ブラウザ・コンポーネント内又はユーザーのコンピュータ上の何れかで事前に構築されているコンテンツ・データを含むトランザクションを作成し、ブロードキャストすることを可能にする。この能力は、専用のウォレットにとってそれ自体での取り扱いを達成することははるかに困難である。
【0180】
アクセス鍵／トークン・ウォレット
上記から、メタネット・プロトコルに組み込まれるものは、ECCキーペア（ECC keypair）又はAES対称鍵を使用してコンテンツを暗号化する機能、及び、対応する解読鍵又はトークンを購入する機能であることを想起されたい。これらをアクセス鍵又はアクセス・トークンと言及することにする。そのような鍵/トークンは、コンテンツを閲覧又は編集すること（単独使用又はマルチインスタンス使用の何れか）の許可をユーザーに付与し、ユーザーの暗号通貨ウォレットを支配する鍵とは異なる役割を果たす（ただし、望まれる場合には、両方の目的のために同じ鍵が使用されてもよい）。この理由のために、アクセス鍵及びトークンを格納及び管理するために使用される、アプリケーションのネイティブ暗号通貨ウォレットとは別の新しいウォレットを導入することは有用である。
上記から、メタネット・プロトコルに組み込まれるものは、ECCキーペア（ECC keypair）又はAES対称鍵を使用してコンテンツを暗号化する機能、及び、対応する解読鍵又はトークンを購入する機能であることを想起されたい。これらをアクセス鍵又はアクセス・トークンと言及することにする。そのような鍵/トークンは、コンテンツを閲覧又は編集すること（単独使用又はマルチインスタンス使用の何れか）の許可をユーザーに付与し、ユーザーの暗号通貨ウォレットを支配する鍵とは異なる役割を果たす（ただし、望まれる場合には、両方の目的のために同じ鍵が使用されてもよい）。この理由のために、アクセス鍵及びトークンを格納及び管理するために使用される、アプリケーションのネイティブ暗号通貨ウォレットとは別の新しいウォレットを導入することは有用である。
【0181】
また、アクセス鍵/トークンが一定期間後に燃え尽きることを可能にすることによって、時限アクセスの概念をメタネット・コンテンツに導入することも可能である。これは、アクセス鍵/トークンが、信頼できる実行環境（Trusted Execution Environment，TEE）に格納され、ユーザーにとって直接的にアクセス可能でないことを要求することによって、達成されることが可能である。
【0182】
アクセス鍵/トークンが「燃え尽きる（burned）」可能性があるということは、それらを暗号通貨ウォレットに記憶させない動機付け要因でもあり、暗号通貨秘密鍵が燃え尽きることについてのリスクはないことを確実にする。
【0183】
暗号通貨ウォレットと同様の方法で、暗号解読鍵及びアクセス・トークンを決定論的に記憶及び管理して、効率的な処理及び配備を促進することが可能である。暗号解読鍵（例えば、ECC秘密鍵）は、マスター鍵に対する後続の追加によって生成及び復元されることが可能である一方、アクセス・トークンは、何らかの初期トークンによってシード処理が行われるハッシュ・チェーンを使用して再構築される可能性がある。
【0184】
ここで、暗号通貨ウォレットは、他のユーザーとのトランザクション処理及び新しいメタネット・ノードの作成に使用される鍵ペアの決定論的鍵生成を処理する一方、鍵/トークン・ウォレット（複数可）は、暗号通貨ウォレットによって購入された鍵及びトークンを処理している、という区別を行うことは重要である。
【0185】
ブロック高さの許可
Timelocksは、ブロック高さ許可を可能にするために、ビットコイン・スクリプト言語に含まれることが可能である。オペコード（op_code）OP_CHECKLOCKTIMEVERIFY (CLTV)は、トランザクションのアウトプット（UTXO）が使用のために許可できるブロック高さを設定する。
Timelocksは、ブロック高さ許可を可能にするために、ビットコイン・スクリプト言語に含まれることが可能である。オペコード（op_code）OP_CHECKLOCKTIMEVERIFY (CLTV)は、トランザクションのアウトプット（UTXO）が使用のために許可できるブロック高さを設定する。
【0186】
ブロック高さを許可する利点は二重にある：
1．バージョン・コントロール － メタネット・プロトコルでは、ノードの最新バージョンは、最大ブロック高さにあるノードから特定することが可能である。ブラウザ・ウォレットは、ブロック高さによってファイルの最新バージョンを表示することだけを設定することが可能であり、プルーフ・オブ・ワークのバージョン制御を可能にする。
1．バージョン・コントロール － メタネット・プロトコルでは、ノードの最新バージョンは、最大ブロック高さにあるノードから特定することが可能である。ブラウザ・ウォレットは、ブロック高さによってファイルの最新バージョンを表示することだけを設定することが可能であり、プルーフ・オブ・ワークのバージョン制御を可能にする。
【0187】
2．時限アクセス － ブラウザ・ウォレット・アプリケーションは、ユーザーによってアトミックに購入された（atomically purchased）暗号解読鍵を周期的に燃やすことが可能である。これは、閲覧者が、彼らが支払った時間的な期間の間にコンテンツ・データにアクセスできるだけであることを保証する。暗号解読鍵の複製（cloning）は、信頼できる実行環境（TEE）にそれらを格納することによって防止することができる。更に、アトミック・スワップは、（コンテンツ・データの復号化のための）決定論的な鍵Dkの購入を含む。この決定論的な鍵は公には可視的であるが、Dkと安全にエンクレーブされた秘密鍵（securely enclaved private key）との組み合わせについて署名するために、TEEを使用することが可能である。
【0188】
ブラウザ・ウォレットは、任意の外部クロック又は第三者の時間オラクルに依存するのではなく、ブロック高さを、時間に関するそれ自体のプロキシとして使用するために、ブロックチェーンの現在の状態と同期するように構成されることが可能である。
【0189】
結 論
開示された技術の他の変形又はユース・ケースは、本件の開示が与えられた場合に、当業者には明らかになるであろう。本開示の範囲は、説明された実施形態によってではなく、添付のクレームによってのみ制限される。
開示された技術の他の変形又はユース・ケースは、本件の開示が与えられた場合に、当業者には明らかになるであろう。本開示の範囲は、説明された実施形態によってではなく、添付のクレームによってのみ制限される。
【0190】
例えば、上記の幾つかの実施形態は、ビットコイン・ネットワーク106、ビットコイン・ブロックチェーン150、及びビットコイン・ノード104の観点から説明されている。しかしながら、ビットコイン・ブロックチェーンはブロックチェーン150の特定の例であり、上記の説明は一般に任意のブロックチェーンに適用されてもよいことが理解されるであろう。即ち、本発明は、ビットコイン・ブロックチェーンに決して限定されるものではない。より一般的には、ビットコイン・ネットワーク106、ビットコイン・ブロックチェーン150、及びビットコイン・ノード104への上述の如何なる参照も、それぞれブロックチェーン・ネットワーク106、ブロックチェーン150、及びブロックチェーン・ノード104に対する参照に置き換えることが可能である。ブロックチェーン、ブロックチェーン・ネットワーク、及び/又はブロックチェーン・ノードは、上述のように、ビットコイン・ブロックチェーン150、ビットコイン・ネットワーク106、及びビットコイン・ノード104の説明された特徴の一部又は全部を共有することが可能である。
【0191】
本発明の好ましい実施形態では、ブロックチェーン・ネットワーク106はビットコイン・ネットワークであり、ビットコイン・ノード104は、ブロックチェーン150のブロック151を生成、公表、伝搬、記憶する説明済みの機能の少なくとも一部又は全部を実行する。これらの機能のうちの1つ又は一部のみを実行するが、全てを実行しない他のネットワーク・エンティティ（又はネットワーク要素）が存在する可能性があることは除外されない。即ち、ネットワーク・エンティティは、ブロックを生成及び公表することなく、ブロックを伝搬及び/又は格納する機能を実行することが可能である（これらのエンティティは、必ずしも好ましいビットコイン・ネットワーク106のノードと考えられないことを想起されたい）。
【0192】
本発明の他の実施形態では、ブロックチェーン・ネットワーク106はビットコイン・ネットワークではない可能性がある。これらの実施形態では、ノードが、ブロックチェーン150のブロック151を生成、公表、伝搬、及び格納する機能の少なくとも1つ又は一部を実行できるが、全てを実行しないものであることは、除外されない。例えば、これらの他のブロックチェーン・ネットワークにおいて、「ノード」は、ブロック151を作成及び公表するように構成されているが、それらのブロック151を記憶及び／又は他のノードに伝播しないネットワーク・エンティティを参照するために使用される可能性がある。
【0193】
更に、より一般的には、上記の用語「ビットコイン・ノード」104への言及は、用語「ネットワーク・エンティティ」又は「ネットワーク要素」に置き換えられてもよく、このようなエンティティ/要素は、ブロックを作成、発行、伝搬、及び記憶する役割のうちの一部又は全部を実行するように構成される。このようなネットワーク・エンティティ/要素の機能は、ブロックチェーン・ノード104を参照して上述したのと同じ方法でハードウェアで実装することができる。
【0194】
上記の実施形態は、単なる例示として説明されているだけであることが理解されるであろう。より一般的には、以下の請求事項のうちの任意の1つ以上による方法、装置又はプログラムを提供することが可能である。
【0195】
本開示の例示的な実施形態に関連する請求事項
本開示の実施形態は、検証及び/又はセキュリティ方法/システムとして説明することが可能である。追加的又は代替的に、それらは、ブロックチェーンを介してデジタル資産の転送を制御するための方法/システムとして説明することが可能である。
請求事項1：
ブロックチェーン・トランザクション内に提供されているシグネチャを検証する方法であって：
前記シグネチャを前記ブロックチェーン・トランザクション内に提供し及び／又はそれを検証するステップであって、前記シグネチャは：
前記トランザクションを一意に識別するためのトランザクション識別データを有しており；且つ
前記トランザクション内から導出可能な及び／又は取得可能なデータのみを
を含んでいる
メッセージに基づいている。
本開示の実施形態は、検証及び/又はセキュリティ方法/システムとして説明することが可能である。追加的又は代替的に、それらは、ブロックチェーンを介してデジタル資産の転送を制御するための方法/システムとして説明することが可能である。
請求事項1：
ブロックチェーン・トランザクション内に提供されているシグネチャを検証する方法であって：
前記シグネチャを前記ブロックチェーン・トランザクション内に提供し及び／又はそれを検証するステップであって、前記シグネチャは：
前記トランザクションを一意に識別するためのトランザクション識別データを有しており；且つ
前記トランザクション内から導出可能な及び／又は取得可能なデータのみを
を含んでいる
メッセージに基づいている。
【0196】
請求事項2：
請求事項1に記載の方法において：
i）前記メッセージはデジタル署名されている；及び／又は
ii）前記メッセージの少なくとも一部分は暗号化又はエンコードされている；及び／又は
iii）前記シグネチャは、前記トランザクション内で、アンロッキング・スクリプト以外の場所に提供されている；及び／又は
iv）前記シグネチャ及び／又はメッセージは、前記トランザクションのアウトプット内で、好ましくは前記トランザクションのロッキング・スクリプトにおいて提供され；ロッキング・スクリプトは、トランザクションのアウトプット内で提供され、又はそれに関連付けられていてもよい。
請求事項1に記載の方法において：
i）前記メッセージはデジタル署名されている；及び／又は
ii）前記メッセージの少なくとも一部分は暗号化又はエンコードされている；及び／又は
iii）前記シグネチャは、前記トランザクション内で、アンロッキング・スクリプト以外の場所に提供されている；及び／又は
iv）前記シグネチャ及び／又はメッセージは、前記トランザクションのアウトプット内で、好ましくは前記トランザクションのロッキング・スクリプトにおいて提供され；ロッキング・スクリプトは、トランザクションのアウトプット内で提供され、又はそれに関連付けられていてもよい。
【0197】
請求事項3：
請求事項1又は2に記載の方法において：
i）前記トランザクション識別データは、アウトポイント又はその他のデータの部分であって前記トランザクションに一意に関連付けられるものを有するか又は関連しており；及び／又は
ii）前記トランザクション識別データは、エンコードされているか、ハッシュされているか、又は難読化されている。
請求事項1又は2に記載の方法において：
i）前記トランザクション識別データは、アウトポイント又はその他のデータの部分であって前記トランザクションに一意に関連付けられるものを有するか又は関連しており；及び／又は
ii）前記トランザクション識別データは、エンコードされているか、ハッシュされているか、又は難読化されている。
【0198】
請求事項4：
上記の請求事項の何れかによる方法において、更に：
i）前記シグネチャに関して検証処理を実行するステップ；及び／又は
ii）前記メッセージ及び公開鍵を用いて、前記シグネチャに関して検証処理を実行するステップを含む。
上記の請求事項の何れかによる方法において、更に：
i）前記シグネチャに関して検証処理を実行するステップ；及び／又は
ii）前記メッセージ及び公開鍵を用いて、前記シグネチャに関して検証処理を実行するステップを含む。
【0199】
請求事項5：
上記の請求事項の何れかによる方法において、更に：
コンピュータ・ベースのリソースを用いて前記シグネチャを検証するステップ；
を含み、前記コンピュータ・ベースのリソースは、前記ブロックチェーンに関連する基本プロトコルに従ってマイニング及び／又は検証処理を実行するようには構成されていない。
上記の請求事項の何れかによる方法において、更に：
コンピュータ・ベースのリソースを用いて前記シグネチャを検証するステップ；
を含み、前記コンピュータ・ベースのリソースは、前記ブロックチェーンに関連する基本プロトコルに従ってマイニング及び／又は検証処理を実行するようには構成されていない。
【0200】
請求事項6：
上記の請求事項の何れかによる方法において：
暗号鍵を用いて前記メッセージをデジタル署名する、エンコーディングする、又は暗号化するステップを更に含む。
上記の請求事項の何れかによる方法において：
暗号鍵を用いて前記メッセージをデジタル署名する、エンコーディングする、又は暗号化するステップを更に含む。
【0201】
請求事項7：
上記の請求事項の何れかによる方法において：
前記シグネチャの検証が成功した場合にアクションを許可し、或いは前記メッセージの検証が失敗した場合にアクションを禁止するステップを更に含む。
上記の請求事項の何れかによる方法において：
前記シグネチャの検証が成功した場合にアクションを許可し、或いは前記メッセージの検証が失敗した場合にアクションを禁止するステップを更に含む。
【0202】
請求事項8：
上記の請求事項の何れかによる方法において：
前記ブロックチェーン・トランザクションは、アプリケーション・レベルのプロトコルに従って形成されている。
上記の請求事項の何れかによる方法において：
前記ブロックチェーン・トランザクションは、アプリケーション・レベルのプロトコルに従って形成されている。
【0203】
請求事項9：
請求事項8による方法において、前記プロトコルは：
ブロックチェーン・トランザクションの論理階層を形成するためにブロックチェーン・トランザクションのアソシエーションを支援するように構成されている；及び／又は
ブロックチェーンで実行されるメタネット・プロトコルである。
請求事項8による方法において、前記プロトコルは：
ブロックチェーン・トランザクションの論理階層を形成するためにブロックチェーン・トランザクションのアソシエーションを支援するように構成されている；及び／又は
ブロックチェーンで実行されるメタネット・プロトコルである。
【0204】
請求事項10：
上記の請求事項の何れかによる方法において：
前記シグネチャ及び公開鍵を、前記公開鍵を用いて生成された別のシグネチャと比較する際に使用するステップ；又は
前記公開鍵を別の公開鍵と比較することによって検証を実行するステップを含む。
上記の請求事項の何れかによる方法において：
前記シグネチャ及び公開鍵を、前記公開鍵を用いて生成された別のシグネチャと比較する際に使用するステップ；又は
前記公開鍵を別の公開鍵と比較することによって検証を実行するステップを含む。
【0205】
請求事項11：
上記の請求事項の何れかによる方法において：
前記トランザクション識別データはアウトポイントを含む。
上記の請求事項の何れかによる方法において：
前記トランザクション識別データはアウトポイントを含む。
【0206】
請求事項12：
ブロックチェーン・トランザクションを生成又は提供するステップを含む、ブロックチェーンで実行される検証方法であって、前記ブロックチェーン・トランザクションは：
i）前記トランザクションを一意に識別するためのトランザクション識別データ；及び前記トランザクション内から導出可能な及び／又は取得可能なデータのみ；を含むメッセージ；及び
ii）前記メッセージに関連付けられるか、前記メッセージに基づいているか、又は前記メッセージを用いて生成されるデジタル・シグネチャ；を含む。
ブロックチェーン・トランザクションを生成又は提供するステップを含む、ブロックチェーンで実行される検証方法であって、前記ブロックチェーン・トランザクションは：
i）前記トランザクションを一意に識別するためのトランザクション識別データ；及び前記トランザクション内から導出可能な及び／又は取得可能なデータのみ；を含むメッセージ；及び
ii）前記メッセージに関連付けられるか、前記メッセージに基づいているか、又は前記メッセージを用いて生成されるデジタル・シグネチャ；を含む。
【0207】
請求事項12による方法において：
i）前記トランザクションは、前記シグネチャを生成するために使用される前記暗号鍵に関連する公開鍵を更に有し；及び／又は
ii）前記トランザクション識別データはアウトプットを有し；及び／又は
iii）前記シグネチャは、前記公開鍵に関連付けられている暗号鍵を用いて前記メッセージをデジタル署名することによって生成され；及び／又は
iv）前記シグネチャは前記トランザクションに関連する任意のインプットの外に提供されている。
i）前記トランザクションは、前記シグネチャを生成するために使用される前記暗号鍵に関連する公開鍵を更に有し；及び／又は
ii）前記トランザクション識別データはアウトプットを有し；及び／又は
iii）前記シグネチャは、前記公開鍵に関連付けられている暗号鍵を用いて前記メッセージをデジタル署名することによって生成され；及び／又は
iv）前記シグネチャは前記トランザクションに関連する任意のインプットの外に提供されている。
【0208】
請求事項14：
ブロックチェーン・トランザクション（Tx）に提供されているデジタル・シグネチャを検証する方法であって、前記ブロックチェーン・トランザクションは：
検証されるべき前記デジタル・シグネチャ；
i）前記トランザクションを一意に識別するためのトランザクション識別データを有し、且つii）前記トランザクション内から導出可能な及び／又は取得可能なデータのみを含むメッセージ；及び
トランザクションID（TxID）；
プロトコル・フラグ；
任意的公開鍵（discretionary public key，DPK）；及び
任意的トランザクションID（discretionary transaction ID，DTxID）を含む。
ブロックチェーン・トランザクション（Tx）に提供されているデジタル・シグネチャを検証する方法であって、前記ブロックチェーン・トランザクションは：
検証されるべき前記デジタル・シグネチャ；
i）前記トランザクションを一意に識別するためのトランザクション識別データを有し、且つii）前記トランザクション内から導出可能な及び／又は取得可能なデータのみを含むメッセージ；及び
トランザクションID（TxID）；
プロトコル・フラグ；
任意的公開鍵（discretionary public key，DPK）；及び
任意的トランザクションID（discretionary transaction ID，DTxID）を含む。
【0209】
請求事項15：
請求事項14による方法において、前記トランザクション（Tx）は、更に：
記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンスを含む。
請求事項14による方法において、前記トランザクション（Tx）は、更に：
記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンスを含む。
【0210】
請求事項16：
請求事項14又は15による方法において：
前記記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンス、前記プロトコル・フラグ、前記任意的公開鍵（DPK）、及び／又は前記任意的トランザクションID（DTxID）は、前記トランザクションのアウトプット（UTXO）内で、好ましくは前記アウトプット（UTXO）に関連するロッキング・スクリプト内で提供される。
請求事項14又は15による方法において：
前記記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンス、前記プロトコル・フラグ、前記任意的公開鍵（DPK）、及び／又は前記任意的トランザクションID（DTxID）は、前記トランザクションのアウトプット（UTXO）内で、好ましくは前記アウトプット（UTXO）に関連するロッキング・スクリプト内で提供される。
【0211】
請求事項17：
請求事項14ないし16による方法において、前記記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンス、前記プロトコル・フラグ、前記任意的公開鍵（DPK）、及び／又は前記任意的トランザクションID（DTxID）は、前記トランザクション内において、以後のトランザクションに対するインプットとして以後使用することについて、アウトプットを無効としてマーキングするスクリプト・オペコードに続く位置で提供される。
請求事項14ないし16による方法において、前記記憶されたデータの一部分又は記憶されたデータの一部分に対するリファレンス、前記プロトコル・フラグ、前記任意的公開鍵（DPK）、及び／又は前記任意的トランザクションID（DTxID）は、前記トランザクション内において、以後のトランザクションに対するインプットとして以後使用することについて、アウトプットを無効としてマーキングするスクリプト・オペコードに続く位置で提供される。
【0212】
請求事項18：
請求事項14ないし17による方法において：
前記トランザクション（Tx）は、1つ以上の属性を更に有し；
好ましくは、前記1つ以上の属性は：
i）前記トランザクション（Tx）内で提供又は参照されるデータの部分；及び／又は
ii）前記トランザクション（Tx）；
に関連付けられるキーワード、タグ、又は識別子を有する。
請求事項14ないし17による方法において：
前記トランザクション（Tx）は、1つ以上の属性を更に有し；
好ましくは、前記1つ以上の属性は：
i）前記トランザクション（Tx）内で提供又は参照されるデータの部分；及び／又は
ii）前記トランザクション（Tx）；
に関連付けられるキーワード、タグ、又は識別子を有する。
【0213】
請求事項19：
請求事項13ないし17による方法において、前記トランザクション（Tx）は、更に：
論理ペアレント・トランザクション（logical parent transaction，LPTx）に関連するペアレント公開鍵（parent public key，PPK）を有し、前記論理ペアレント・トランザクション（LPTx）は、前記任意的トランザクションID（DTxID）によって識別され；及び
前記シグネチャは前記ペアレント公開鍵（PPK）を用いて生成される。
請求事項13ないし17による方法において、前記トランザクション（Tx）は、更に：
論理ペアレント・トランザクション（logical parent transaction，LPTx）に関連するペアレント公開鍵（parent public key，PPK）を有し、前記論理ペアレント・トランザクション（LPTx）は、前記任意的トランザクションID（DTxID）によって識別され；及び
前記シグネチャは前記ペアレント公開鍵（PPK）を用いて生成される。
【0214】
請求事項21：
請求事項13ないし18による方法において、更に：
前記任意的公開鍵（DPK）及び前記トランザクションID（TxID）を用いて、ブロックチェーンにおける前記トランザクション（Tx）又は前記論理ペアレント・トランザクションを識別するステップを含む。
請求事項13ないし18による方法において、更に：
前記任意的公開鍵（DPK）及び前記トランザクションID（TxID）を用いて、ブロックチェーンにおける前記トランザクション（Tx）又は前記論理ペアレント・トランザクションを識別するステップを含む。
【0215】
請求事項21：
請求事項14ないし20による方法において、前記プロトコル・フラグは、1つ以上のブロックチェーン・トランザクションにおけるデータを探索する、格納する、及び／又は抽出するためのブロックチェーン・ベースのプロトコルに関連する及び／又はそれを示す。
請求事項14ないし20による方法において、前記プロトコル・フラグは、1つ以上のブロックチェーン・トランザクションにおけるデータを探索する、格納する、及び／又は抽出するためのブロックチェーン・ベースのプロトコルに関連する及び／又はそれを示す。
【0216】
請求事項22：
コンピュータ装置であって：
1つ以上のメモリ・ユニットを有するメモリ；及び
1つ以上の処理ユニットを有する処理装置；
を備え、前記メモリは、前記処理装置において動作するように構成されたコードを記憶し、前記コードは、前記処理装置上にある場合に、請求事項1ないし21のうちの何れかに記載の方法を実行するように構成されている。
コンピュータ装置であって：
1つ以上のメモリ・ユニットを有するメモリ；及び
1つ以上の処理ユニットを有する処理装置；
を備え、前記メモリは、前記処理装置において動作するように構成されたコードを記憶し、前記コードは、前記処理装置上にある場合に、請求事項1ないし21のうちの何れかに記載の方法を実行するように構成されている。
【0217】
請求事項23：
請求事項22によるコンピュータ装置において：
i）ブロックチェーン・ネットワーク及び／又はブロックチェーンで実行されるシステムであるか、又はそのように構成されているか、又はそれらと相互作用するように動作し；及び／又は
ii）ハードウェア・ウォレットを有している。
請求事項22によるコンピュータ装置において：
i）ブロックチェーン・ネットワーク及び／又はブロックチェーンで実行されるシステムであるか、又はそのように構成されているか、又はそれらと相互作用するように動作し；及び／又は
ii）ハードウェア・ウォレットを有している。
【0218】
請求事項24：
コンピュータ読み取り可能な記憶装置に組み込まれたコンピュータ・プログラムであって、1つ以上のプロセッサ上で動作すると、請求事項1ないし21のうちの何れかに記載の方法を実行するように構成されている。
コンピュータ読み取り可能な記憶装置に組み込まれたコンピュータ・プログラムであって、1つ以上のプロセッサ上で動作すると、請求事項1ないし21のうちの何れかに記載の方法を実行するように構成されている。
【0219】
請求事項25：
請求事項1ないし21のうちの何れかによるブロックチェーンで実行される方法であって：
請求事項1ないし21のうちの何れかを実行するために、ハードウェア及び／又はソフトウェアの構成要素を用いるか又は提供するステップを含み；
前記ハードウェア及び／又はソフトウェアの構成要素は：
暗号通貨ウォレット；
サーチ・エンジン；
ブロックチェーン・エクスプローラ；又は
ブラウザ
であるか又はそれらを有し、好ましくは、前記構成要素は簡易支払検証（simplified payment verification，SPV）処理を実行するように動作可能である。
請求事項1ないし21のうちの何れかによるブロックチェーンで実行される方法であって：
請求事項1ないし21のうちの何れかを実行するために、ハードウェア及び／又はソフトウェアの構成要素を用いるか又は提供するステップを含み；
前記ハードウェア及び／又はソフトウェアの構成要素は：
暗号通貨ウォレット；
サーチ・エンジン；
ブロックチェーン・エクスプローラ；又は
ブラウザ
であるか又はそれらを有し、好ましくは、前記構成要素は簡易支払検証（simplified payment verification，SPV）処理を実行するように動作可能である。
【0220】
本件で開示される別の態様によれば、コンピュータで実施される方法及び対応するシステムを提供することが可能である。これらは、（暗号）シグネチャを検証するための方法/システムとして説明することが可能である。シグネチャは、例えば、メタネット・プロトコルのようなブロックチェーン・ベースのプロトコルに従って形成されたトランザクション（ノード）内で使用されてもよい。メタネット・プロトコルは、実質的にはGB2007238.5又はWO 2020/109908において開示されているようなものであってもよく、これら双方の全体は本件に組み込まれる。本開示のこの態様又は他の態様に関して以下に記載される如何なる特徴も、上記で提供された1つ以上の請求事項に記載された方法と組み合わせることが可能である。
【0221】
本開示のこの態様による方法は、ブロックチェーンを介してデータの処理、格納、検索、識別、及び/又は共有を可能にしたり又は制御したりするための方法として説明されてもよい。追加的に又は代替的に、本方法は、（別個の/異なる）ブロックチェーン・トランザクション内に格納されたデータを関連付ける又はリンク付けして、当該データの識別、検索及び/又は共有を可能にする方法として説明されてもよい。追加的又は代替的に、それは、暗号シグネチャを検証するための方法として説明されてもよい。方法は、トランザクションID（TxID）を含む少なくとも1つのブロックチェーン・トランザクションを処理するステップを含む可能性があり、ブロックチェーン・トランザクション（Tx）は：
プロトコル・フラグと
任意的公開鍵（discretionary public key，DPK）と
任意的トランザクションID（discretionary transaction ID，DTxID）
を含む。
プロトコル・フラグと
任意的公開鍵（discretionary public key，DPK）と
任意的トランザクションID（discretionary transaction ID，DTxID）
を含む。
【0222】
この特徴の組み合わせは、データの部分が、ブロックチェーン上で識別されること、及び、複数のトランザクションで提供される場合に互いにリンク付け/関連付けられることを可能にする。これは、データの部分どうしの間の階層関係を反映するグラフ又はツリー状構造を構築することを可能にし、それらの処理、検索、アクセス、生成、及び共有を促進する。本件において、「共有する（sharing）」は、ノード又はユーザーに提供すること、データの一部に対するアクセス（権）を送ること、連絡すること、伝送すること、又は提供することを含む可能性がある。
【0223】
トランザクションID（TxID）は、ブロックチェーン・プロトコルの技術分野で知られているようなトランザクションの識別子であり、即ち、各ブロックチェーン・トランザクションは、基礎となるブロックチェーン・プロトコルの一部として一意のIDを有する。対照的に、任意的公開鍵（DPK）及び/又は任意的トランザクションID（DTxID）は、それらが、基礎となるブロックチェーンのプロトコルによって規定されるトランザクションの必須構成要素以外の、本発明の一部として提供されるという点で「任意的（discretionary）」である可能性がある。言い換えると、それらは、基礎となるブロックチェーン、例えばビットコインのプロトコルに従って、トランザクションが有効であるためには要求されない。追加的又は代替的に、それらは、本発明の一部として提供される追加的な必須でない項目として説明されてもよく、なぜならブロックチェーン・プロトコルはそれらを要求しないからである。
【0224】
好ましくは、プロトコル・フラグは、1つ以上のブロックチェーン・トランザクションにおいてデータを検索し、格納し、及び/又は取得するためのブロックチェーン・ベースのプロトコルに関連付けられ、及び/又はそれを示す。プロトコル・フラグは、インジケータ又はマーカー（marker）であってもよい。それは、トランザクションが所定のプロトコルに従って形成されることを示す可能性がある。これは、基礎となるブロックチェーンのプロトコル以外のプロトコルであってもよい。それは、本件で説明される任意の実施形態による検索プロトコル（即ち、本件で説明される「メタネット」プロトコルと呼ばれる可能性のあるもの）であってもよい。
【0225】
「処理」という用語は、トランザクション又はその関連データに関連する任意の処理を意味するものとして解釈される可能性があり、その処理は、生成、伝送、検証、アクセス、検索、共有、ブロックチェーン・ネットワークへのサブミット、及び/又は識別を含む。
【0226】
任意的トランザクションIDは、本発明の実施形態に従ってトランザクション（Tx）に関連付けられる識別子、ラベル、インジケータ、又はタグであってもよい。我々は、これらの用語の全てを含むように、用語「インジケータ」を使用している。当技術分野で知られており、当業者によって容易に理解されるように、ブロックチェーン上の各トランザクションは、識別子によって一意に識別され、典型的には、当技術分野でTxIDと呼ばれることに留意すべきである。TxIDは、基礎となるブロックチェーン・プロトコルの必須の、必要な、及び任意的でない部分である。この任意的でないTxIDは、本件で言及される任意的なトランザクションID（DTxID）と混同されるべきではない。
【0227】
好ましくは、ブロックチェーン・トランザクション（Tx）は、データの一部、又はデータの一部に対するリファレンスを更に含む。データの一部に対するリファレンスは、データが記憶されている位置のポインタ、アドレス、又はその他のインジケータであってもよい。データの一部は、任意のタイプのデータ又はデジタル・コンテンツ、例えば、コンピュータ実行可能アイテム、テキスト、ビデオ、画像、サウンド・ファイルなどであってもよい。データの一部は、「コンテンツ」と呼ばれる場合がある。データの一部又はそのリファレンスは、処理された形態におけるものであってもよい。例えば、それはデータの一部のハッシュ・ダイジェストであってもよい。データは、ブロックチェーン上に、又はブロックチェーン外（即ち、「オフチェーン」）に記憶されてもよい。好ましくは、データの一部又はデータの一部に対するリファレンス、プロトコル・フラグ、任意的公開鍵（DPK）及び/又は任意的トランザクションID（DTxID）は、ブロックチェーン・トランザクションのアウトプット（UTXO）内に提供される。それらのうちの1つ以上は、アウトプット（UTXO）に関連付けられたロッキング・スクリプト内で提供されてもよい。
【0228】
好ましくは、データの一部、データの一部に対するリファレンス、プロトコル・フラグ、任意的公開鍵（DPK）、及び/又は任意的トランザクションID（DTxID）は、トランザクション（Tx）内において、後続のトランザクションに対するインプットとして後で使用するためにアウトプットを無効としてマーキングするためのスクリプト・オペコードに続く位置で提供される。
【0229】
このスクリプト・オペコードは、ビットコイン・プロトコルの1つ以上の変形におけるOP_RETURNオペコードであってもよく、又は、別のブロックチェーン・プロトコルからの機能的に類似する/等価なオペコードであってもよい。
【0230】
好ましくは、トランザクション（Tx）は、1つ以上の属性を更に含む。これは、データ/コンテンツを検索するためのより詳細なアプローチを可能にする。また、属性は、「値」、「ラベル」、「タグ」、又は「識別子」と言及されてもよい。それらは、データの一部を記述するか、又は注釈を付けるために、あるいはデータの一部に関する追加情報を提供するために使用される可能性がある。
【0231】
好ましくは、1つ以上の属性は、i）トランザクション（Tx）内で提供されるか、又は参照されるデータの部分、及び/又はii）トランザクション（Tx）に関連付けられるキーワード、タグ、又は識別子を含む。
【0232】
好ましくは、トランザクション（Tx）は、任意的トランザクションID（DTxID）によって識別されるそれぞれの論理的親トランザクション（LPTx）に関連付けられた少なくとも1つの親・公開鍵（PPK）；及び、少なくとも1つの親公開鍵（PPK）を使用して生成されたシグネチャを更に含む。
【0233】
これは、トランザクションとその埋め込まれたデータとの間に論理階層が構築されることを可能にする。子ノードに関連付けられた1つの親・公開鍵が存在してもよく（即ち、子ノードは単一の親ノードを有する）、又は2つ以上の親・公開鍵が存在してもよい（即ち、子ノードは2つ以上の親を有してもよい）。従って、ブロックチェーン上の複数の関連付けられた又は論理的にリンク付けされたトランザクションは、効率的に、安全に、かつ迅速に処理されることが可能である。論理的に関連付けられたトランザクションは、ブロックチェーン上で連続したブロック高さで格納されなくてもよいが、それらは容易に且つ安全に識別及び/又はアクセスされることが可能である。好ましくは、方法は、ブロックチェーン内のトランザクション（Tx）又は論理的親トランザクションを識別するために、任意的公開鍵（DPK）及びトランザクションID（TxID）を使用するステップを更に含む。
【0234】
更に、実施形態は：トランザクションIDを含むブロックチェーン・トランザクション（Tx）に公開鍵を関連付けるステップ；トランザクションID及びトランザクション公開鍵に基づいて、ブロックチェーン・トランザクション（Tx）を検索するステップを有する可能性がある。 これは、ブロックチェーンを介してデータを記憶し、検索し、識別し、通信し、及び/又はアクセスするための改善されたソリューションを提供する。本件は、電子ネットワーク、具体的にはピア・ツー・ピア・ブロックチェーン・ネットワークにわたるデータ通信及び交換の改善を提供することが可能である。本件で説明される任意の特徴（複数可）はまた、本開示のこの実施形態に従って利用される可能性があるが（逆もまた同様）、簡潔性及び明確性のために、ここで再度引用されたり又は再現されたりはしない。それは、トランザクション（Tx）内に提供されるか、又はトランザクション（Tx）から参照されるデータの一部にアクセスするか、又は別の方法で処理するステップを更に含む可能性がある。
【0235】
公開鍵及び/又はトランザクションIDは、本件で説明されるように任意的である可能性がある。トランザクションは、トランザクションID（TxID）、プロトコル・フラグ；任意的公開鍵（DPK）；及び任意的トランザクションID（DTxID）を含むことが可能である。トランザクション（Tx）は、データの一部、又はデータの一部に対するリファレンスを更に含むことが可能である。データの一部又はデータの一部に対するリファレンス、プロトコル・フラグ、任意的公開鍵（DPK）及び/又は任意的トランザクションID（DTxID）は、アウトプット（UTXO）内に、好ましくはアウトプット（UTXO）に関連付けられたロッキング・スクリプト内に提供されることが可能である。
【0236】
データの一部、データの一部に対するリファレンス、プロトコル・フラグ、任意的公開鍵（DPK）、及び/又は任意的トランザクションID（DTxID）は、トランザクション（Tx）内において、アウトプットを無効としてマーキングするためのスクリプト・オペコードに続く位置で提供されてもよい。
【0237】
トランザクション（Tx）は1つ以上の属性を含んでもよい。1つ以上の属性は、i）トランザクション（Tx）内で提供されるか、又はトランザクション（Tx）内で参照されるデータの一部、及び/又はii）トランザクション（Tx）に関連付けられたキーワード、タグ、又は識別子を含んでもよい。
【0238】
トランザクション（Tx）は、それぞれの論理的親トランザクション（LPTx）に関連付けられた少なくとも1つの親公開鍵（PPK）であって、少なくとも1つの論理的親トランザクション（LPTx）は、任意的トランザクションID（DTxID）によって識別される、少なくとも1つの親公開鍵（PPK）；及び、それぞれの親公開鍵（PPK）を使用して生成されたシグネチャ；を含むことが可能である。
【0239】
実施形態は、ブロックチェーン内のトランザクション（Tx）又は論理的親トランザクション（複数可）を識別するために、任意的公開鍵（DPK）及びトランザクションID（TxID）を使用することを含んでもよい。これは、検索ステップ中に実行されてもよい。プロトコル・フラグは、1つ以上のブロックチェーン・トランザクションにおいてデータを検索、格納及び/又は取得するためのブロックチェーン・ベースのプロトコルに関連付けられ、及び/又は、それを示すことが可能である。
【0240】
更に、本開示の実施形態は、ブロックチェーンにおいてトランザクション（TX）を識別するステップを含み、本ステップは、ニーモニック（mnemonic）を、トランザクション（TX）に関連付けられた公開鍵（PK）；及びトランザクション（TX）のトランザクションID（TXID）にマッピングするステップを含む。
【0241】
また、ステップは、i）公開鍵（PK）及びトランザクションID（TXID）を、演算のオペランドとして使用してアウトプットを生成し、ニーモニックをアウトプットにマッピングするステップ；及び、ii）ニーモニックをマッピングする前にアウトプットをハッシュするステップ；を含むことも可能である。この処理は連結処理であってもよい。公開鍵（PK）は、人間が読み取ることが可能なプレフィックス（prefix）を含むことが可能である。
【0242】
更に、本開示の実施形態は、ブロックチェーン上のターゲット・トランザクションを特定するステップを含んでもよい。これらは、ターゲット・トランザクションを特定するために検索パスを使用することを含む可能性があり、検索パスは：
i）ルート・トランザクションに関連付けられた公開鍵（RTPK）と、ルート・トランザクションに関連付けられたID（RTID）とを含むルート・トランザクション・インデックス（RTIndex）；及び
ii）ルート・トランザクション及び/又はターゲット・トランザクションに関連付けられた少なくとも1つの属性を含む。
i）ルート・トランザクションに関連付けられた公開鍵（RTPK）と、ルート・トランザクションに関連付けられたID（RTID）とを含むルート・トランザクション・インデックス（RTIndex）；及び
ii）ルート・トランザクション及び/又はターゲット・トランザクションに関連付けられた少なくとも1つの属性を含む。
【0243】
少なくとも1つの属性はヌルであってもよい。ルート・トランザクション・インデックス（RTIndex）は、公開鍵（RTPK）及び識別子（RTID）の関数のハッシュを含む可能性がある。関数は連結（concatenation）であってもよい。属性のうちの少なくとも1つは、ルート・トランザクション又はターゲット・トランザクションに関連付けられたニーモニックであってもよい。ルート・トランザクション及び/又はターゲット・トランザクションは、プロトコル・フラグを含む可能性がある。また、実施形態は：i）ブロック・エクスプローラを使用して、ブロックチェーンにおいて、プロトコル・フラグを含む少なくとも1つのトランザクションを識別するためのステップ、及び/又はii）ブロックチェーンにおいて、プロトコル・フラグを含む少なくとも1つのトランザクションを識別し、少なくとも1つのトランザクションに関連するデータを、ブロックチェーン外リソースに格納するステップを含む可能性がある。好ましくは、少なくとも1つのトランザクションに関連するデータは：トランザクションに関連付けられた少なくとも1つのインデックス；トランザクションにリンクされた別のトランザクションに関連付けられた少なくとも1つのインデックス；及び/又はトランザクションに関連付けられたキーワードを含む。また、実施形態は、ターゲット・トランザクションに記憶された（又はターゲット・トランザクションから参照された）データの一部にアクセスすることを含む可能性がある。
【0244】
更に、本開示の実施形態は、ユーザーが、少なくとも1つのブロックチェーン・トランザクション（Tx）で提供されるデータの一部を検索し、アクセスし、閲覧し、書き込み、及び/又は取得することを可能にするように構成されたコンピュータで実施されるシステムを含む可能性があり、ここで、システムは、トランザクション（Tx）に関連付けられたトランザクションID及び公開鍵を含むトランザクション・インデックス（TXindex）に基づいて、少なくとも1つのトランザクション（Tx）を識別するように構成されている。
【0245】
システムは、ブロックチェーン検索システム内に提供されるか、又はブロックチェーン検索システムとインターフェース接続及び/又は通信するように構成された検索装置を含む可能性がある。それは、少なくとも1つの暗号通貨ウォレットを含む可能性がある。少なくとも1つのウォレットは：1）階層的決定論的鍵を生成、格納、及び/又は処理し；及び/又は2）少なくとも1つの暗号鍵及び/又は少なくとも1つのトークンを、信頼できる実行環境に格納するように構成されている可能性がある。システムは、データの一部が圧縮されている場合に、それを解凍するように構成された圧縮解除構成要素；再結合構成要素；及び/又はデータの一部が暗号化されている場合に、それを暗号解読するように構成された暗号解読構成要素を含む可能性がある。システムは、データの一部を、可聴形式及び/又は可視的形式でユーザーに提示するように構成された少なくとも1つの提示構成要素を含む可能性がある。システムは：検索パスを入力又は生成して、ブロックチェーン上の少なくとも1つのトランザクション（Tx）を特定するための手段を含む可能性があり、ここで、検索パスは：i）トランザクション・インデックス（TXindex）；及びii）トランザクション（Tx）に関連付けられた少なくとも1つの属性を含む。属性のうちの少なくとも1つは、トランザクションに関連付けられたニーモニックであってもよく；及び/又は少なくとも1つの属性はヌルであってもよい。
【0246】
システムは、暗号通貨ウォレット又はその他のリソースと通信して、暗号鍵、ブロックチェーン・トランザクション、及び/又はデジタル・シグネチャの処理、格納及び/又は生成を促進するように動作することが可能である。それは、トランザクション・インデックス（TXindex）を格納するように動作する可能性があり、好ましくは、システムは、1つより多いトランザクションについて、それぞれのトランザクション・インデックスを格納するように構成される。それは：i）データの一部にアクセスする前に、暗号通貨の一部のコントロールを宛先へ転送し；ii）データの一部に対するリクエストをブロックチェーン上のピアへ送信し；及び/又はiii）ブロックチェーン上のピアからデータの一部を受信するように動作することが可能である。データの一部に対するアクセスをコントロールするために、タイム・ロック・メカニズムを使用するように動作することが可能である。
【0247】
更に、本開示の実施形態は、資産をリソースから別のリソースへ移転するためのステップ（複数可）を提供する可能性があり、そのステップは：少なくとも1つのブロックチェーン・トランザクションに関連する完全なトランザクション・データ；及び、少なくとも1つのブロックチェーン・トランザクションの完全なマークル・パス；を、リソースから別のリソースへ送信することを含む。リソース及び/又は別のリソースは；デジタル・ウォレット、暗号通貨ウォレット、又は、軽量若しくは簡易支払いウォレット；及び/又はウォレットを含むコンピュータ・ベースのデバイス；及び/又はウォレットを含むスマート・カードを含む可能性がある。本方法は、少なくとも1つの秘密鍵；及び/又は少なくとも1つの公開鍵を、リソースの場所で又はそこにおいて記憶、受信、及び/又は生成するステップ；及び/又は少なくとも1つのブロック・ヘッダを、リソースにおいて受信するステップ；を含む可能性がある。
【0248】
本方法は：リソースが別のリソースへ転送データを提供するステップを含む可能性があり、転送データは：i）少なくとも1つの未使用ブロックチェーン・トランザクション・アウトプット（UTXO）に関するデータ；ii）少なくとも1つの未使用ブロックチェーン・トランザクション・アウトプット（UTXO）を含むトランザクションのトランザクションID（TXID）；iii）少なくとも1つの未使用ブロックチェーン・トランザクション・アウトプット（UTXO）を使用するためのシグネチャ；iv）少なくとも1つの未使用ブロックチェーン・トランザクション・アウトプット（UTXO）を含むトランザクションについてのマークル・パス；及び/又は公開鍵アドレスを含む。
【0249】
本件で開示される別の態様によれば、コンピュータ装置を含むシステムを提供することが可能であり、コンピュータ装置は：
1つ以上のメモリ・ユニットを含むメモリ；及び
1つ以上の処理ユニットを含む処理装置；
を含み、メモリは、処理装置上で動作するように構成されたコードを記憶し、コードは、処理装置上にある場合に、本件に含まれるクレーム、方法ステップ、又は実施形態のうちの何れかの方法を実行するように構成されている。
1つ以上のメモリ・ユニットを含むメモリ；及び
1つ以上の処理ユニットを含む処理装置；
を含み、メモリは、処理装置上で動作するように構成されたコードを記憶し、コードは、処理装置上にある場合に、本件に含まれるクレーム、方法ステップ、又は実施形態のうちの何れかの方法を実行するように構成されている。
【0250】
コンピュータ装置は、ブロックチェーン・ネットワーク及び/又はブロックチェーンで実施されるシステムと相互作用してもよいし、又は相互作用するように配置されたり或いは動作したりしてもよく；及び/又はハードウェア・ウォレットを含んでもよい。ウォレットは、SPV（簡易支払検証）動作を実行するように構成されていてもよい。
【0251】
また、実施形態は、コンピュータ読み取り可能なストレージにおいて具現化されたコンピュータ・プログラムであって、1つ以上のプロセッサ上で動作する場合に、本件に含まれる任意の方法、クレーム、又は実施形態を実行するように構成されたコンピュータ・プログラムも提供する。
【0252】
また、実施形態は、本件に含まれる任意のクレーム、方法、ステップ、又は実施形態を実行するためにハードウェア及び/又はソフトウェア構成要素を使用又は提供するブロックチェーンで実施される方法も提供する。ハードウェア及び/又はソフトウェア構成要素は：暗号通貨ウォレット；検索エンジン；ブロックチェーン・エクスプローラ；及び/又はブラウザであってもよいし、又はこれらを含んでもよい。構成要素は、SPV（簡易支払検証）動作を実行するように配置されてもよいし、又は動作可能であってもよい。
【0253】
本開示の実施形態は、WO2020/109908及びPCT/IB2020/050737に実質的に開示されるような1つ以上の特徴を含む可能性があり、これら双方の全体が本件に組み込まれている。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【国際調査報告】