JP2019514089A - ブロックチェーンにより施行される洗練された取引のためのレジストリ及び自動管理方法 - Google Patents

Abstract

本発明は、トークン化、ブロックチェーン、及びスマートコントラクト（smart contract）技術の分野に関する。本発明は、取引の自動管理を簡易化する技術的構成を提供する。本発明は、取引の記憶のためのコンピュータに基づくレポジトリを用いる方法及びシステムを含む。取引は、次に、ブロックチェーン上のトランザクションにより表現される。トランザクションのスクリプトの中のメタデータは、取引のハッシュ、及びレポジトリ内の場所を識別する手段を含む。トランザクションは、自身の状態をオープン（つまり、終了していない）取引として示す未使用アウトプット（ＵＴＸＯ）も含む。取引は、後の時点で、例えばｎＬｏｃｋＴｉｍｅ＋ＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ（ＣＬＴＶ）を用いてアウトプットを使用することにより終了される。この概念を他の技術及び計算コンポーネントと組み合わせることにより、本発明は、取引の更新又はロールオーバ、又は取引をサブ取引若しくは条件に分割するような種々のタスクを実施する強力なメカニズムを提供できる。さらに、取引の状態及び存在はブロックチェーンによる証明なので、これは、永久的に、公に可視の且つ変更不可能な、取引のレコードを提供する。

Description

本発明は、概して、コンピュータプロトコルに関し、より詳細には、例えば取引に関するような条件制御されたプロセスの検証、施行、及び／又は実行に関する。本発明は、特に、ブロックチェーンネットワークと共に使用することに適し、洗練された取引を促進するために使用できる。

ブロックチェーンは、不変ブロックにより構成される、非集中型の、分散型コンピュータシステムである。また、不変ブロックはトランザクションにより構成される。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションのレコードを生成する。トランザクションは、そのインプット及びアウトプットに組み込まれるスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。各未使用トランザクション（ＵＴＸＯとして参照される）は、新トランザクションへのインプットとして使用可能である。

最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装が本発明の範囲に含まれることに留意すべきである。

ブロックチェーン技術は、暗号通貨の実装の使用のために知られている。しかしながら、更に近年は、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステムの使用、及びブロックチェーンに格納可能なデータの両者を探索し始めている。これらは、限定ではないが、以下を含む：
・メタデータを格納する。
・デジタルトークンを実施する。
・取引を実施する及び管理する。

近年の取引管理に伴う主な問題のうちの１つは、アドホックである傾向があり、手動で維持されている取引のローカルストア及びコピーを伴うことである。結果として、「スマートコントラクト（smart contracts）」として知られるコンピュータプロトコルは、それらが部分的に又は全体的に取引の自動施行又は実行を可能にできるので、注目を集め始めている。スマートコントラクトは、セキュリティ向上及びトランザクションコスト低減のような利益を提供できる。しかしながら、これらの取引が変更できないことを保証することを目的とする既知の技術的ソリューションが存在する一方で、取引の有効性、つまり依然としてオープンか又は終了しているか、を調べるために一般に認められた公の登録所は存在しない。

したがって、取引の存在の公の可視性を制御できるコンピュータにより実施されるメカニズムを提供し、及び自動化方法で（つまり、人間による管理ではなく機械により）取引のような実行に基づく処理を管理し、施行し、及び維持する関連パーティの能力を実現することが望ましい。重要なことに、このメカニズムは、取引の中で定められた動作についての制御条件及びトリガを指定する技術的能力を提供し得る。

留意すべきことに、本願明細書に定められ及び記載される本発明は、言葉の正当な意味で、取引と共に使用することに限定されない。取引は、文書、ファイル、又は指定条件下でトリガされ得る動作セットを定める他のメカニズムであって良い。制御条件は、公然と満たされて良い。本発明は、法的又は商業的指向の状況における使用に限定されると考えられるべきではない。用語「取引」は、このような限定的意味に解釈されるべきではない。例えば、取引は、鉄道若しくは航空機又はコンサート会場のチケットであって良く、チケットには、バリアのアンロックを提供するための機械可読バーコードのようなアクセスコードが印刷される。

したがって、添付の請求項に定められるように、本願明細書において発明が提供される。

本発明の態様によると、取引の可視性及び／又は実行を制御するコンピュータにより実施される方法であって、前記方法は、
（ａ）コンピュータに基づくレポジトリ上に又はその中に取引を格納するステップと、
（ｂ）ブロックチェーンにトランザクションをブロードキャストするステップであって、前記トランザクションは、
ｉ）少なくとも１つの未使用アウトプット（ＵＴＸＯ）、及び、
ｉｉ）前記取引の格納された場所を示す識別子を有するメタデータ、を有する、ステップと、
（ｃ）前記取引を、
前記取引に関連付けられた前のキーに関連するデータを用いて、新しいキーを生成し、
前記新しいキー、前記取引の前記場所、前記取引のハッシュを有するスクリプトを生成し、
前記スクリプトに通貨額を支払う、
ことにより、更新する又はロールオンするステップと、
を含む方法が提供される。

取引に関連付けられた前のキーに関連するデータを用いて新しいキーを生成し、新しいキーと取引の場所と取引のハッシュとを含むスクリプトを生成し、及びスクリプトに通貨額を支払うことにより、取引を更新し又はロールオンすることにより、これは、新しいキーが前のキーに関連するので、許可されたパーティが更新又はロールオンされる取引との自身の接続により、確実性又はプライバシの損失を伴わずに、元の取引を閲覧できるという利益をもたらす。更新又はロールオンされる取引に関連付けられたキーは元の取引のキーに関連付けられるので、コンピュータに基づくオフチェーン（つまり、ブロックチェーンの部分を形成しない）レポジトリに取引を格納することにより、確実性又はプライバシの損失を伴わずに、メモリ及び処理容量が削減できるという更なる利益がもたらされる。

「ロールオーバ」の状況では、ＵＴＸＯが使用されて、それを「新しい」ロールオンされる取引に送る。しかしながら、ロック時間の前にアウトプットを使用することにより、したがって取引全体を取り消すことにより、既存の取引を取り消すことが可能であって良い。

本発明は、取引の可視性及び／又は実行を制御するコンピュータにより実施される方法及びシステムを提供できる。「可視性」は、取引の存在及び／又は内容がどのように及び誰に利用可能か又はアクセス可能かを意味し得る。取引は「スマートコントラクト（smart contract）」であって良い。方法は自動スマートコントラクト方法であって良い。これは、取引の存在、有効性、及び／又は実行を監視する処理を自動化する方法であって良い。取引はブロックチェーントランザクションの少なくとも部分の形式で表現できるので、本発明は、トークン化方法／システムとして参照されて良い。トランザクションの中のメタデータは、取引を表現し及び／又はアクセスするために使用される、ブロックチェーンにより実施されるトークンを提供して良い。

本発明は、レポジトリ（記録簿）への取引の記憶を可能にする方法／システムを提供し得る。ここで、取引のハッシュは、取引を見付けるための検索キーとして使用できる。

方法は、
コンピュータに基づくレポジトリ上に又はその中に取引を格納するステップと、
ブロックチェーンへトランザクションをブロードキャストするステップであって、前記トランザクションは、
ｉ）少なくとも１つの未使用アウトプット（ＵＴＸＯ）、及び、
ｉｉ）前記取引の格納された場所を示す識別子を有するメタデータ、を含む、ステップと、
を含んで良い。

取引は、ＵＴＸＯがブロックチェーン上で使用されるまで、公開され又は有効であると解釈されて良い。ブロックチェーンは、ビットコインブロックチェーンであって良く、又はそうでなくて良い。これは、ＵＴＸＯにより表現されるようなブロックチェーン上の取引の状態又は有効性を表現する新規なメカニズムの利益をもたらす。

方法は、オフチェーンのコンピュータにより実施される処理、エージェント、又は他のエンティティを用いて、ブロックチェーンの状態を観察し、及びアウトプットが現在未使用か否かに基づき特定の方法で振る舞うステップを含んで良い。処理は、未使用アウトプットを、取引の状態の指示子として解釈するよう構成されて良い。言い換えると、アウトプットがブロックチェーン上のＵＴＸＯリスト内に残る、つまりトランザクションが未使用のままである間、これは、メタデータにより指される又は参照される取引の有効性又は「公開」状態を示すために使用されて良い。取引は、ＵＴＸＯが使用されると、完了された（終了された）と考えられて良い。この条件は、取引の中で記述されて良い。しかしながら、ＵＴＸＯが使用されると、メタデータは、取引へのポインタ又は参照及び取引のハッシュを含み続けることが可能であるので、取引はその機能を保持できる。

方法は、取引の存在を公表するステップを含んで良い。これは、以下のステップにより達成できる。
・取引発行人は、新しい取引文書を作成し、これをレポジトリに公表する。該文書の格納場所及びセキュアなハッシュが、後の使用のために格納されて良い。
・ｎ人のうちのｍ人のマルチシグネチャ構造で、取引文書がセキュアであることを保証するＲｅｄｅｅｍＳｃｒｉｐｔを生成する。ここで、
− ｍは少なくとも１であり、
− ｎはｍとメタデータブロック数の和である。
・少なくとも１つの公開鍵をスクリプトに含める。これは、取引発行人の公開鍵であって良い。しかしながら、他の署名も要求されて良い。
・望ましくはＰ２ＳＨトランザクションを通じて、通貨額、例えばビットコインをスクリプトに支払う。
・トランザクションがブロックチェーンに公表されるまで待機し、公表されたトランザクションのトランザクションＩＤを抽出する。
・ロック時間を取引の有効期限に設定して新しいトランザクションを生成し、トランザクションから公開鍵ハッシュへアウトプットを払い戻す。又は、
ローリング期間取引について、自動計算エージェントを用いて、ブロックチェーン上のトランザクションを検出し、それを新しい取引にローリングするためのコードをトリガする前に取引有効期限まで待機する。又は、
完了に基づく取引について（ここで、ｙ個のエンティティのうちのｘ個のエンティティが、取引が満たされたことに合意する）、ｎ人のうちのｍ人のマルチシグネチャトランザクションを生成し、完了すると共同署名するために、それをこれらのエンティティに発行する。

レポジトリは、オフブロック記憶リソースであって良い。言い換えると、レポジトリは、ブロックチェーン自体の部分を形成しなくて良い。コンピュータに基づくレポジトリは、サーバであって良く又はそれを含んで良い。レポジトリは、データベース又はコンピュータに基づくリソース上に設けられた他の記憶設備であって良い。レポジトリは、インデックス付けされて良く、検索可能である。レポジトリは、分散ハッシュテーブルを含んで良い。取引は、分散ハッシュテーブル（Distributed Hash Table：ＤＨＴ）の中に又はそれに関連付けられて格納されて良い。

トランザクションは、決定性Ｒｅｄｅｅｍ又はロッキングスクリプトアドレスを更に含んで良い。アドレスは、Ｐ２ＳＨ（pay−to−script−hash）アドレスであって良い。したがって、取引の存在（又は取引の中の定められた要素）は、取引の発行人により決定され又は提供され得るｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈアドレス、及び／又は取引のメタデータを用いて、ブロックチェーンに公表されるトランザクションを用いて公衆に利用可能にされて良い。

方法は、アウトプット（ＵＴＸＯ）を使用するためにブロックチェーンに（更なる）トランザクションをブロードキャストすることにより、取引を終了するステップ、を更に含んで良い。更なるトランザクションは、アウトプット（ＵＴＸＯ）であるインプット、及び、署名と前記メタデータと公開鍵とを含むアンロックスクリプト、を有して良い。

これは、アウトプットを使用するために、ブロックチェーントランザクションの使用により、取引の自動終了の利益をもたらし得る。

取引は、ｉ）少なくとも１つの条件、ｉｉ）条件の評価に実行が依存する少なくとも１つのアクション、を定めて良い。条件は、真又は偽に評価可能なテストであって良い。条件は、取引（例えば、条項（clause））の部分であって良い。条件の完了又は実行は、取引の達成のために要求されて良い。条件は、真と評価された場合に、完了されて良い。

メタデータは、ｉ）取引がコンピュータに基づくレポジトリに格納された場所のアドレス又はアドレスの提示、及び／又は、ｉｉ）取引のハッシュ、を有して良い。

方法は、ブロックチェーン状態を観察するステップを含んで良い。これは、ＵＴＸＯを含むトランザクションを見付けるためにブロックチェーンを検索するステップを含んで良い。これは、未使用トランザクションＵＴＸＯがブロックチェーンの未使用トランザクションアウトプットのリストの中にあるか否かを決定することにより、取引が終了しているか否かを調べるステップ、を含んで良い。この監視する又は調べる処理は、自動化されて良い。これは、適切にプログラムされたコンピューティングエージェント又はリソースにより実行されて良い。これは、実質的に以下に「本発明と共に使用するための説明のための計算エージェント」と題される章に記載される通りであり得る。エージェントは、ＵＴＸＯの使用又は未使用状態に基づきアクションを実行して良い。したがって、ＵＴＸＯの状態は、オフブロック計算エージェントの振る舞いを制御し又はそれに影響して良い。

方法は、指定日及び／又は時間にアウトプットを使用する指示を含むトランザクションをブロックチェーンにブロードキャストするステップを含んで良い。指示はＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ指示であって良い。

取引の内容の一部又は全部へのアクセスは、少なくとも１つの指定された許可パーティに制限されて良い。言い換えると、取引の一部又は全部にアクセスする又はそれを閲覧するために、許可が必要とされて良い。幾つかの実施形態では、保護メカニズムが取引自体に適用されて良い。例えば、ファイルの１又は複数の部分が保護されて良いが、全体的な内容は公開されて良い。この部分的保護は、取引の中の情報の暗号化、並びに、取引の内容に対する変更を検出するハッシュ、の両方に適用されて良い。

取引は、取引を実施するために決定性有限オートマン（Deterministic Finite Automaton：ＤＦＡ）を有して良い。決定性有限オートマンは、コード化スキームを用いて定められて良い。決定性有限オートマンは、
ｉ）望ましくはスクリプト言語を用いる、少なくとも１つのブロックチェーントランザクション、
ｉｉ）ブロックチェーンの状態を監視するよう構成された計算エージェント（これは、以下の「本発明と共に使用するための説明のための計算エージェント」と題される章に記載され得る）、及び／又は、
ｉｉｉ）デジタルウォレットに対する指示セット、を用いて実施されて良い。

本発明の別の態様によると、取引の可視性及び／又は実行を制御するコンピュータにより実施される方法であって、前記方法は、
（ａ）コンピュータに基づくレポジトリ上に又はその中に取引を格納するステップと、
（ｂ）ブロックチェーンにトランザクションをブロードキャストするステップであって、前記トランザクションは、
ｉ）少なくとも１つの未使用アウトプット（ＵＴＸＯ）、及び、
ｉｉ）前記取引の格納された場所を示す識別子を有するメタデータ、を有する、ステップと、
（ｃ）前記取引から導出されるサブ取引を生成するステップであって、前記サブ取引は、決定性アドレスに関連付けられ、
ｉｉｉ）シードを用いて導出された新しい公開鍵を用いて、
ｉｖ）前記取引への参照と共に前記レポジトリ上に又はその中に前記サブ取引を格納し、前記参照を含むスクリプトを有するトランザクションを前記ブロックチェーンにブロードキャストし、及び／又は、
ｖ）既存の取引のメタデータに前記サブ取引への参照を追加する、
ことにより生成される、ステップと、
を含む方法が提供される。

取引から導出されるサブ取引を生成するステップであって、サブ取引は決定性アドレスに関連付けられ、シードを用いて導出された新しい公開鍵を用いて、取引への参照と共にレポジトリ上に又はその中にサブ取引を格納し、参照を含むスクリプトを有するトランザクションをブロックチェーンにブロードキャストし、及び／又は、既存の取引のメタデータにサブ取引への参照を追加する、ことにより生成される、ステップにより、これは、サブ取引が元の取引に暗号によって結合されるので、確実性又はプライバシの損失を伴わずに、サブ取引が独立に管理可能であるという利点を提供する。さらに、サブ取引をオフブロックレポジトリに格納することにより、メモリ及び処理リソースが最小化できる。

方法は、ブロックチェーンを監視するために及び／又は取引内容に基づきアクションを実行するために、コンピュータに基づくエージェントの使用を含み得る。このようなエージェントは、実質的に以下に「本発明と共に使用するための説明のための計算エージェント」と題される章に記載される通りであり得る。

本発明は、上述の方法ステップのうちのいずれか又は本願明細書に記載の方法の任意の実施形態を実行するよう構成された、コンピュータにより実施されるシステムを更に提供し得る。本発明は、取引の可視性及び／又は実行を制御するコンピュータにより実施されるシステムであって、前記システムは、
取引を格納するよう構成されたコンピュータに基づくレポジトリと、
トランザクションを有するブロックチェーンであって、前記トランザクションは、
ｉ）少なくとも１つのアウトプット（ＵＴＸＯ）、及び、
ｉｉ）前記取引の格納された場所を表す識別子を有するメタデータ、
を有する、ブロックチェーンと、
を含むシステムを提供し得る。

メタデータは、取引のハッシュを更に格納して良い。取引はスマートコントラクト（smart contract）であって良い。

レポジトリは、データベースを有して良い。これは、ＤＨＴを有して良い。これは、インデックス付けされ、検索可能であって良い。これは、取引へのアクセスを制御するために少なくとも１つのセキュリティメカニズムを有して良い。

システムは、的セルに構成された計算に基づくエンティティ又はエージェントを更に有して良い。エージェントは、ブロックチェーンを監視し及び／又は検索するよう構成されて良い。これは、ブロックチェーンの状態に基づき、少なくとも１つのアクションを実行するよう構成されて良い。これは、ＵＴＸＯが使用されたか否かを決定するよう構成されて良い。これは、ＵＴＸＯが使用されたか否かに基づき１又は複数のアクションを実行するよう構成されて良い。

ある実施形態又は態様に関連して本願明細書に記載された任意の特徴は、任意の他の実施形態又は態様に関連して使用されても良い。例えば、方法に関連して記載されて任意の特徴は、システムに関連して使用されて良く、逆も同様である。

本発明により提供され得る利益のうちの幾つかの非限定的リストがここで提供される。

本発明は、ここでは「取引（contracts）」として参照される場合のある構造化制御条件の自動管理を簡略化する技術的構成を提供し得る。これは、また、疑義の生じた場合に、取引の状態に合意することを容易にする。本発明は、取引の有効性のコンピュータによる自動決定を可能にする方法で、取引のセキュアな公開されたレコードを保持し、及び検証により許可エンティティに取引の詳細を公開するメカニズムも提供し得る。したがって、本発明は、知的な方法でリソースへのアクセスを許可し又は禁止する、セキュリティの向上した制御メカニズムを提供し得る。

本発明は、コンピュータシステムを介して聴衆に取引を公表する能力も提供し、取引の詳細が認定エンティティだけに制限可能であるが、取引の存在の知識が公衆に知られるようにする。言い換えると、ＡとＢとの間に取引が存在することを誰もが知ることができ、これは公に検証可能であるが、その存在以外の全ては認定パーティ（標準的にＡ及びＢだけ）に制限される。

これは、取引が時間で制限される（つまり、特定時間後に又は所与の日付で取引が終了する）、条件で制限される（つまり、取引の中で指定された成果物が満たされると、取引が終了する）、又は制限のない（つまり、取引を終了すべき通知期間と共に取引がロールオンし続ける）ことを可能にする、コンピュータにより実施されるメカニズムも提供する。

これは、該取引を公に終了するための通知を提供するメカニズムを提供し得る。例えば、期間終了を「制定する」ために、使用されるトランザクションの中でｎＬｏｃｋＴｉｍｅ＋ＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ（ＣＬＴＶ）を用いる。

これは、区分化されるべき取引の異なる側面に渡る制御を可能にする決定性の方法で、サブ取引の階層を構造化するメカニズムを提供し得る。例えば、技術の発展過程において、要求段階は、発展段階と異なる制御トリガセットを有することがある。

本発明がブロックチェーンプラットフォーム上で実施され、ブロックチェーンの機能を拡張して、技術的に異なる方法で使用可能になるとき、本発明は改良されたブロックチェーンシステム又はプラットフォームを提供し得る。

本発明は、例えばデジタルアクセスのために、任意の未使用トランザクション（ＵＴＸＯ）をスマートコントラクトにするために使用できる。例えば、消費者がある期間中にサービスにアクセスするために商人に支払うシナリオを考える。商人の支払アドレスがスマートコントラクトとして実施される場合、本発明は、サービスのためのアクセス制御メカニズムを実装するために使用できる。金銭が支払われたこと、及び期間の終了時に商人のアカウントに価値を運び去るために自動化処理が使用されることを保証するために、チェックが行われ得る。

本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
種々の取引関連タスクを実施するために、ブロックチェーントランザクションが本発明の実施形態によりどのように使用できるかの概要を示す。 ２つの状態：（ｉ）取引が開かれている、及び（ｉｉ）取引が閉じられている、を有する単純な状態機械を示す。 図２Ａのシナリオのためのメタデータ定義を示す。メタデータは、（ビットコイン）トランザクションアウトプット上で伝達され、取引場所及び（ハッシュにより）有効性の証明を指定する。 図２Ａ及び２Ｂのシナリオに関連する、最初にブロックチェーン上に取引（のハッシュ）を格納する「発行（issuance）」トランザクションを示す。 ビットコインを使用することにより、図２Ａ〜２Ｃの取引を取り消す。 隠された所有権を有する資産が生成されブロックチェーンに公表されるシナリオのための説明のためのメタデータを示す。 図３Ａの資産に「資金を供給する」説明のためのトランザクションを示す。つまり、幾つかのビットコインを資産の公開鍵に入れて、資産が（図３Ｃに示す公表トランザクションのような）自身のトランザクションに資金供給するようにする 図３Ａ及び３Ｂの資産の公表のための説明のためのブロックチェーントランザクションを示す。 図３Ａ、Ｂ、及びＣに関連する取引を閉鎖するための説明のためのトランザクションを示す。取引の取り消しが要求されると、ＵＴＸＯが使用される。このシナリオでは、要件は、資産及び署名すべき資産の隠された所有者の両者のためである。 賃貸借取引を含むシナリオのための説明のための状態機械モデルを示す。 図４Ａのシナリオのための説明のためのメタデータを示す。 図４Ａ及び４Ｂの資産の所有権をブロックチェーンに公表するための説明のためのトランザクションを示す。 取引がロールオンされるシナリオのための説明のための状態機械モデルを示す。 図５Ａのシナリオのための説明のためのメタデータを示す。 図５Ａ及び５Ｂの初期取引及び取引の初期ロールオーバをブロックチェーンに公表するために使用され得る説明のためのトランザクションを示す。 図５Ａ及び５Ｂの初期取引及び取引の初期ロールオーバをブロックチェーンに公表するために使用され得る説明のためのトランザクションを示す。 図５Ａ〜５Ｄの取引の終了のための説明のためのトランザクションを示す。 取引条件付けを含むシナリオのための説明のための状態機械モデルである。 図６Ａのシナリオのための説明のためのメタデータを示す。 初期取引及び２つのサブ取引を生成し、それらを公表するために使用され得る、説明のためのトランザクションを示す。 初期取引及び２つのサブ取引を生成し、それらを公表するために使用され得る、説明のためのトランザクションを示す。 初期取引及び２つのサブ取引を生成し、それらを公表するために使用され得る、説明のためのトランザクションを示す。 図６Ａ〜６Ｃのシナリオに関連して使用するための説明のためのトランザクションを示す。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。 親キーからサブキーを導出する技術の種々の態様を示す。本技術は、本発明の態様と関連して使用することに適する。

ブロックチェーンに構築されるスマートコントラクトは、ビットコイントランザクションに（つまり、ロック／アンロックスクリプトの中に）直接埋め込まれるロジックを通じて、及び／又は外部のコンピュータに基づくアプリケーションを通じて、施行できる。このような外部のコンピュータに基づくアプリケーションは、「エージェント」、「オラクル」、又は「ボット」として参照される場合がある。さらに、幾つかの取引条件は、ｎＬｏｃｋＴｉｍｅフィールドのような他のビットコイントランザクション要素を通じて施行可能である。

本願明細書に記載される発明では、取引は、取引を表すブロックチェーン上に有効な未使用トランザクションアウトプットＵＴＸＯが存在する限り、事実上残っていると解釈される。この未使用状態は、取引自体の中の条件又は諸規定により振る舞いが制御される種々のメカニズム（例えば、プログラムされた計算エージェント）の結果として影響を受け変更され得ることが理解される。例えば、取引は、該取引が特定日に終了すること、又は該取引が特定値が指定閾に達すると終了することを規定する。

取引を表現するために未使用トランザクションアウトプットを使用するこの原理は、暗号化技術のような他の特徴と組み合わせて使用できる。これは、複雑なシナリオ及び活動の実施を可能にする。事実上、未署名トランザクションアウトプットＵＴＸＯに関するコンテキスト、及び自身を使用可能にするスクリプト内の関連メタデータは、該トランザクションが、取引の正式な詳細を含むオフチェーンレポジトリへのポインタ又は参照として作用することを可能にする。ここで、「オフチェーン」は、ブロックチェーン自体の部分ではないことを意味する。これは、ブロックチェーンを検査することにより取引が終了しているか又は未だ有効／公開されているかを決定するために、誰もがソフトウェアに基づくコンポーネント又はツールを使用できるようにするメカニズムを提供する。取引が終了すると、これは、トランザクション内の使用済みアウトプットとしてブロックチェーンに記録され、これは公開検査のために利用可能である。ブロックチェーントランザクションは、取引の存在及び現在状態の恒久的、変更不可能、且つ公開されたレコードになる。

レポジトリ（「レジストリ」又は「レジスタ」とも呼ばれる）は、例えば分散ハッシュテーブル（distributed hash table：ＤＨＴ）を含む種々の方法で実装されて良い。取引のハッシュが生成され、メタデータとしてブロックチェーントランザクション内に格納され、ブロックチェーンから取引を参照するための検索キーとして機能できる。取引の場所への参照も、トランザクションメタデータ内で提供される。例えば、レポジトリのＵＲＬが提供されて良い。メタデータが公衆の閲覧に付されている間、取引自体は、部分的に保護されなくて良く又はされて良い。

ＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ（ＣＬＴＶ）のような標準的なビットコインの特徴は、取引が、将来のある時点での正式な自動終了を有することを可能にする。ブロックチェーンの使用は、この終了日をセキュアな（変更不可能な）公開レコードの問題にすることを可能にする。この概念は、以下に記載する複数の暗号鍵の使用と組み合わせて、明示的に取り消されない限り、ＣＬＴＶモデルが取引を自動的にロールオンする又は更新することを可能にする。

決定性サブキーの使用は、本願明細書に記載のトークン化メカニズムと組み合わせて、取引に対してサブ取引又はスケジュールが生成されることを可能にする。

さらに、オフブロック計算エージェント（オラクル）の使用は、取引条件付けが信頼できる第三者により構築され及び偏光されることを可能にする。これは、エージェントのアクションが、取引定義の中で提供される条件（例えば「ＩＦ」ステートメント）により影響され得ることを意味する。

＜主な用語＞
以下の用語が本願明細書で使用され得る。
・取引発行人：
このエンティティは、取引のブロックチェーンへの公表を担う主体を表す。
・関心パーティ：
このエンティティは、特定の取引が未だ場にあるか否かを決定する必要があり得る又は取引の細目を決定する必要があり得る主体を表す。
・レポジトリ：
このエンティティは、ブロックチェーンのスマートコントラクトが参照する取引の構造化表現を安全に保管する／格納する場所を表す。
・取引相手：
このエンティティは、特定取引の相手を表す。多くの場合、このエンティティは存在しないことに留意する。
・取引：
これは、レポジトリ内に格納された構造化文書又はファイルであり、ブロックチェーンから参照される。取引は、任意の種類の取引又は合意であり得る。これは、例えば、金融取引、権利証書、サービス取引、等を含み得る。取引は、その内容の観点で公開又は秘密であり得る。取引は、コード化スキームを用いる構造化方法で表現されるという点で、形式化される。

＜取引モデル＞
取引モデルの基本要素は以下の通りである：
・コード化スキームは、任意の種類の取引の完全な記述を可能にする。スキームは、新しい構成であって良く、又はＸＢＲＬ、ＸＭＬ、ＪＳＯＮ（等）のような既存の設備を使用して良い。
・取引を実施するためのＤＦＡ（決定性有限オートマン、Deterministic Finite Automaton）は、コード化スキームの中で完全に定義できる。これは、以下から構成される。
− パラメータのセット、これのパラメータを供給すべき場所、
− 状態定義のセット、
− 遷移のトリガ及び遷移中に従うルールを含む、状態間の遷移のセット、
− ルール定義テーブル。
・取引のこのインスタンスのための特定パラメータの定義。
・取引を安全に保管し保護するためのメカニズム。
・取引を、正式な法律の言語で人間に可読にする「ブラウザ」。
・コード化スキームをオラクルコード及び／又はビットコインスクリプトのようなスクリプトに変換する「コンパイラ」。

＜取引の実施＞
取引がレポジトリに登録されると、関連アドレス、例えばＵＲＬ及びハッシュは、チェーン上のトランザクションを制御トランザクション自体に関連付けるために、ブロックチェーントランザクション内のメタデータとして使用可能である。これは、種々の形式で実施できるが、適切なコード化スキームは、完全のために以下の「コード化スキーム」と題された章で提供される。

取引定義に含まれるＤＦＡがどのように実施できるかに関する多数の異なる方法が存在する。
・ブロックチェーントランザクション又はトランザクションシーケンスとして。種々の形式のＤＦＡが、ビットコインスクリプト言語の中で直接実施されて良い。当業者はこれを理解し、本発明はＤＦＡがブロックチェーントランザクションにより実施される方法に関して限定されない。
・エージェントに基づく（例えば、オラクル）プロセス又はプロセスシーケンスとして。以下の「本発明と共に使用するための説明のための計算エージェント」と題された章は、ブロックチェーン及び可能な他の外部ソースを監視するために適切なエージェントを定義し及び実行する基本処理を記載する。
・スマートウォレットに対する指示セットとして。この内容では、スマートウォレットは、トランザクションインプットのブロックチェーントランザクションへの割り当てのような特定取引条件を処理可能なローカルなオラクル処理を事実上簡略化する。

所与の取引定義は、上述の３つのメカニズムの混合として実施でき、各取引状態トランザクションは事実上別個の実施であることに留意する。

関連トランザクション／コードを手作業で作ることを含む、取引定義から実施を生成する多数の方法が存在する。

＜取引の存在の公表＞
取引の存在（又は取引の中の定義された要素）を公表するために、トランザクションＴｘは、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ（Ｐ２ＳＨ）アドレスを用いてブロックチェーンに公表される。Ｐ２ＳＨトランザクションは、トランザクションが送信されるために、受け手が、スクリプトハッシュに適合するスクリプト、及びスクリプト評価を真にマークするデータを提供しなければならないものである。本発明の実施形態に関連して、ｐａｙ−ｔｏ−ｓｃｒｉｐｔ−ｈａｓｈ（Ｐ２ＳＨ）は、直ちに以下から決定できる。
− 取引の発行人、及び、
− 取引のメタデータ。

本発明の幾つかの実施形態に従い、未使用トランザクションは、取引状態の指示子として解釈できる。オフチェーン処理は、ブロックチェーンを監視し、アウトプットが未使用か否かに基づき特定方法で振る舞うよう構成され得る。言い換えると、このアウトプットがブロックチェーン上のＵＴＸＯリスト内に残る（つまりトランザクションが未使用のままである）間、これは、メタデータにより指される又は参照される取引の有効性を示す。取引は、このアウトプットが使用されると、完了されたと考えられる。ＵＴＸＯが存在する限り（取引が有効／公開されたままである）この状態は、取引自体の状態であり得る。しかしながら、他の実施形態では代替の終了条件が適切な場合があるので、これはプロトコルの必須規定ではない。トランザクションが使用された後でも（したがって、ＵＴＸＯリストの中にもはや存在しない）、該トランザクションは永久にブロックチェーン上に存在したままであり、取引へのポインタ又は参照、及び取引のハッシュを保持したままである。したがって、使用された後でもトランザクションはその機能を保持し得る。

＜サブ取引／条件＞
サブ取引は、既存取引に直接関連する取引である。条件は、取引条件に適合するために満たされなければならない、既存取引の中の条項（clause）である。

本発明の実施形態に従い、サブ取引及び条件の両者は、同じ方法で、つまり決定性ｒｅｄｅｅｍスクリプトアドレスを有するＵＴＸＯとして実装される取引として、実施できる。両方の場合に、エンティティは、ＵＴＸＯが使用されるとき完了すると解釈できる（ある条件の場合には、これは、該条件が満足されていることを示す）。上述のように、メタデータは、レポジトリ内のエンティティの場所へのポインタ又は参照、及びそのハッシュも依然として含む。したがって、他の実施形態では、取引上指定された条件に依存して、アウトプットが使用された後でも、サブ取引又は条件は存在したままであり、及び機能を保持したままであって良い。

条件又はサブ取引の決定性アドレスを生成するために使用可能な多数のメカニズムが存在する。
− シード情報を用いて新しい公開鍵を導出する。
− レポジトリ内にあるマスタ取引への参照と有し、これをメタデータ参照として使用する、サブ取引を生成し公表する。
− 既存取引のメタデータへの参照を条件／サブ取引に追加する。

＜取引の安全な保管＞
取引の正式表現（つまり、取引内容を指定する文書又はファイル）は、特定取引の正式な必要に依存して種々の方法で安全に保管され得る。しかしながら、全ての場合に、取引の存在の公開レコードが、メタデータレコードに含まれるブロックチェーンに公表される（特定のメタデータ構造の詳細については「コード化スキーム」と題された章を参照する）。

このブロックチェーンレコードから、認定エンティティは、トランザクションが公表されてから正式表現が変更されていないことを決定するためのハッシュと一緒に、正式表現の場所を知ることができる。

しかしながら、多数の方法を通じて正式表現自体を更に安全に保管することが可能である。
− 文書レポジトリ自体が、アクセス制御メカニズムを提示可能である。
− 取引自体が、関連復号鍵へのアクセスを有するこれらのエンティティへのアクセスを制限する標準的な暗号化技術を通じて安全に保管できる。

多くの場合、取引自体は、取引について部分的保護を有する。例えば、ファイル内の幾つかのセクションは保護されて良く、一方で、全体的内容は公開される。例えば、固定利率ローンをどのように実施するかの詳細は公開されるが、そのローンを誰が、いくら、及びどんな率で組んだかという知識は取引パーティにだけ知られる。

この部分的保護は、取引の中の情報の暗号化、並びに、取引の内容に対する変更を検出するハッシュ、の両方に適用される。

多数の取引について、取引の詳細はその寿命に渡り変更され得る。これは、取引自体の再発行を要求すべきではない。これは、取引のサブセットに渡るハッシュの範囲を決定することにより達成できる。これが有用であり得る一例は、契約型投資信託の実施においてである。契約型投資信託を支える取引は変化してはならないが、構成単位の受益者は取引の売りを通じて変更され得る。一実施形態では、変化の記録は、サブ取引を用いて達成できる。

＜取引の終了＞
ブロックチェーンは永久的な変更不可能なトランザクションのレコードを提供するので、取引は、単に関連する取引文書を削除することにより終了できない。これは、セキュアな取引レポジトリが、多数の標準的メカニズムを通じてサポートされるブロックチェーン自体と同じ記憶装置及び維持ルールを有しなければならないことを意味する。これは、ソリューションが、ブロックチェーンレコードを通じて直接に取引の終了を検出するメカニズムを提示しなければならないことを意味する。

終了の方法は、取引の中の条件として定められ、様々な方法で施行できる。これらの方法の全部は、本発明により概念的にカバーされる。本発明の好適な実施形態では、終了は、取引を表すＵＴＸＯの使用を通じて取り扱われる。

多数の取引種類について、取引の終了は、取引自体の公開と同時に公表され得る。実際上、２つのトランザクションが生成される。第１トランザクションは、取引を公表し、取引を表すトランザクションアウトプットを得るためである。第２トランザクションは、該アウトプットを使用するためである。この第２トランザクションは、所与の将来の日（取引の終わりを表す）にアウトプットを使用するために該トランザクションに設定されたＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙを有する。

上述のように、これは私達の標準的方法であるが、唯一の方法ではない。

この自動使用は、取引のロールリングオンをサポートするために拡張できる（例えば、取引が取り消されない場合、該取引は更に１２ヶ月の間、自動的に延長される）。この状況では、ＵＴＸＯが使用されて、それを「新しい」ロールオンされる取引に送る。しかしながら、ロック時間の前にアウトプットを使用することにより、したがって取引全体を取り消すことにより、古い取引を取り消すことが可能である。

＜使用例モデル＞
図１は、本発明の実施形態による使用例モデルの概観を示す。この説明のための使用例モデルは、ビットコインスクリプト内のＤＦＡの要素を直接実施するために、標準的なビットコイントランザクションがどのように使用できるかを示す。主要な使用例の例が、説明を目的としてここに提供される。

＜取引の生成＞
取引発行人（本例では１次主体である）は、一般的可視性のためにブロックチェーンに取引を公表したいと望む。この処理は、表１に概略を示される。

以下に詳述される、２つの主要な実施形態又は本シナリオの変形が存在する。
・既存取引からサブ取引を生成する。
・既存取引を新しい取引へロールオーバする（既存取引を更新する）。

＜サブ取引の生成＞
この状況では、取引発行人は、既存取引からサブ取引を生成したいと望む。この処理は、表２に概略を示される。

１又は複数の実施形態によると、サブ取引は独立に監視されて良い。例えば、測量士からの承認の要求される不動産建造取引を検討する。取引は「subject to sign−off by <x>」と記載する。これを実施するために、ステップ１５０．６０が生成され、署名すべき＜ｘ＞へ巡回させられる。ＲｅｐａｙＳｃｒｉｐｔは、時間制限されていないが、要求される署名者が＜ｘ＞であるｎ人のうちのｍ人のマルチシグネチャ要素として生成される。幾つかの実施形態では、トランザクションは、２つのアウトプット：＜ｘ＞への手数料、及びステップ１５０．５０で生成されたＵＴＸＯの支払、を有する。

＜例示的な使用例：既存取引のロールオーバ＞
本使用例では、取引発行人は、既存取引を新しい取引にロールオーバしたいと望む。表３に説明のための処理が提供される。

＜例：取引のチェック＞
本使用例では、関心パーティが、彼（彼女）の問い合わせている活動をカバーする取引が存在することを確認したいと望む。このような処理は、表４に示される。

上述の主な変化は、関心パーティが、何らかのルートを通じて取引を支配するトランザクションに気付いていることを想定している（通常、関心パーティが取引発行人又は取引相手である場合である）。しかしながら、取引文書及び取引発行人の知識へのアクセスを有する任意のエンティティは、以下によりチェックできる：
・ＵＴＸＯトランザクションのＲｅｄｅｅｍＳｃｒｉｐｔを導出する、及び、
・ＲｅｄｅｅｍＳｃｒｉｐｔハッシュに適合するＵＴＸＯを見付けるためにブロックチェーンをスキャンする。

＜例：取引の終了＞
この使用例では、取引発行人又は取引相手は、既存取引を閉じたいと望む。この処理は、表５に概略を示される。

＜取引条件＞
上述と同じメカニズムが、チェックポイントのような所与の取引の中の条件を監視するために使用できる。例えば、取引が１００ＢＴＣの価値であると決定され、２０ＢＴＣがチェックポイント１〜５で支払われるべきである場合、上述のサブ取引モデルは、マスタ取引及び５個のサブ取引を導出するために使用できる。これらのサブ取引の各々は、（例えば公証人、又は同様の者のような）同じ又は異なる署名者を用いて完了としてマークできる。この方法では、公開レコードが維持でき、取引に付属する条件が満たされたことを示す。次に、この概念を、処理、又は取引が完了としてマークされると２０ＢＴＣの支払をトリガするために使用可能なアプリケーション（「ボット」）と組み合わせることが可能である。

説明を目的として、本発明が使用され得るアプリケーションのうちの幾つかを示す幾つかの例示的なシナリオが以下に提供される。これらのシナリオの全てで、取引自体の内容は、無関係且つ非限定的であると考えられる。

＜例示的シナリオ１：資産の公開レジストリ＞
本シナリオでは、ボブは、彼の資産（例えば、彼の家）所有権をブロックチェーンに公表することを決定する。この段階で他に行うことはない。次に後続のトランザクションで使用され得るものは単に資産である。この状況では、取引について終了日は存在しない。図２Ａは、２つの状態：（ｉ）取引が開かれている、及び（ｉｉ）取引が閉じられている、を有する単純な状態機械を示す。図２Ｂは、ビットコイントランザクションアウトプット上で伝達され、取引場所及び（ハッシュにより）有効性の証明を指定する、メタデータ定義を示す。図２Ｃは、ブロックチェーンに取引を最初に格納した「発行」トランザクションを示す（しかしながら、これは実際には、実際の取引ではなく、ハッシュを格納するだけである）。図２Ｄは、ビットコインを使用することにより取引を取り消す。

＜例示的シナリオ２：隠された所有権を有する資産の生成及びレジストリ＞
これは、シナリオ１の僅かに拡張されたバージョンであり、ボブは、ブロックチェーンに資産を公表したいと望むが、彼の所有権を直接明かすことを望まない。

この状況では、ボブは、先ず、資産を表現するために、彼の公開鍵からサブキーを生成する。このサブキーは、次に、資産の詳細の部分としてブロックチェーン上で公開される。ここでも、この状況では、資産について終了日は存在しない。（詳細な例は、サブキーが生成され得る１つの方法について以下に提供される。「サブキー生成の方法」と題された以下の章を参照する。）
本シナリオの状態機械は、図２Ａに示すようなシナリオ１の状態機械と同じである。図３Ａは、本シナリオのためのメタデータ定義を示す。メタデータは、ビットコイントランザクションアウトプット上で伝達され、取引場所及び（ハッシュにより）有効性の証明を指定する。図３Ｂは、アセットに「資金を供給する」ためのトランザクションを示す。つまり、幾つかのビットコインを資産の公開鍵に入れて、資産が（図３Ｃに示す公開トランザクションのような）自身のトランザクションに資金供給できるようにする。図３Ｂは、ビットコイントランザクションではないので、ボブによる資産サブキーの生成を示さない。

図３Ｃは、資産の公開のためのブロックチェーントランザクションを示す。図３Ｄは、取引の閉鎖のためのトランザクションを示す。取引の取り消しが要求されると、ＵＴＸＯが使用される。この状況では、要件は、資産及び署名すべき資産の隠された所有者の両者のためである。

＜例示的シナリオ３：賃貸借取引＞
この説明のための状況では、ボブは、３年間の固定期間の間、イブと賃貸借取引を組む。取引の条項は、支払数を指定する。支払の詳細は、本発明に関して関係ない。しかしながら、取引は破棄条項を有しない固定条項を有する。

これは、図４Ａに示すような単純な状態機械モデルを有する。図４Ｂは、本シナリオのためのメタデータを示す。図４Ｃは、資産の所有権をブロックチェーン上で公表するためのトランザクションを示す。先ず、ボブが資産に何らかの資金を供給し、次に、資産が自身を公表する。

＜例示的シナリオ４：取引のローリング＞
この説明のための状況では、ボブは、ローリング年率ベースでイブから家を借りることを決定する。ここで、彼は、更新日に賃貸借を取り消すために２ヶ月前に通知を提供する必要がある。その他の場合には、自動継続される。これは、図５Ａに示すような単純な状態機械モデルを有する。図５Ｂは、本シナリオのためのメタデータを示す。図５Ｃは、初期取引及び取引の初期ロールオーバをブロックチェーン上に公表するためのトランザクションを示す。

最初の年の後に、ボブは、賃貸借を継続し、終了しない。ＥＶＥ−Ｓ３−Ｔ２は公表された直後に、自動計算エージェントにより取り上げられ、もう１年継続される。留意すべきことに、これはイブ自身の内部ロジックを用いてイブにより行われることも可能である。

２年目の後に、ボブは、賃貸借を終了することを選択し、ＥＶＥ−Ｓ３−Ｔ３と同じインプットを用いてトランザクションを提出する。しかしながら、このトランザクションは未だ提出されていないので、インプットは未使用であり、ボブのトランザクションが最初にブロックチェーン上に公表された場合、ＥＶＥ−Ｓ３−Ｔ３を無効にしてしまう。含まれる額は些細であるが、ボットは、アウトプットがイブの公開鍵ハッシュに向けられない限り（又は取引が実際に何を記載しても）、トランザクションに連署しない。ボブの取引の終了のためのトランザクションは図５Ｄに示される。

＜例示的シナリオ５：取引条件付き＞
この説明のための状況では、ボブは、新しい不動産を供給するために建築業者のプールと契約に入り、独立した承認を必要とする取引の中の多数の条件を指定する（第１条件は、ローカルの計画当局からの計画の認可である）。これは、図６Ａに示すような単純な状態機械モデルを有する。図６Ｂは、本シナリオのためのメタデータを示す。図６Ｃは、ボブが、（場合によっては後述するサブキー生成技術を用いて、間ｒねんサブキーを導出した後に）初期取引及び２つのサブ取引を生成し、それらを公表するトランザクションを示す。図６Ｄは、計画許可が承認されるときのためのトランザクションを示す。

＜コード化スキーム＞
取引を参照するために使用されるメタデータは、様々な方法でフォーマット化できる。しかしながら、適切なコード化スキームがここに記載される。

取引の定める権利が取引の保持者又は所有者に贈与される場合、取引は転送可能である。非転送可能取引の一例は、参加者が指名される取引である。つまり、権利が、取引の保持者ではなく特定の指名されたエンティティに贈与される。転送可能取引だけが、このコード化スキームで議論される。

トークンは、取引により贈与される権利を詳述する又は定める特定取引を表す。本発明に従い、トークンは、ビットコイントランザクションの形式の取引の表現である。

このコード化方法は、３つのパラメータ又はデータアイテムを有するメタデータを使用する。このデータは、以下を示し得る：
ｉ）取引の下で利用可能な株（share、持分）の量
（これは、本願明細書で「ＮｕｍＳｈａｒｅｓ」と呼ばれることがある）、
ｉｉ）送り手から少なくとも１つの受け手へ転送されるべき転送単位の量（これは、「ＳｈａｒｅＶａｌ」と呼ばれることがある）、
ｉｉｉ）転送単位の量の値を計算するための因子（これは、「ペギングレート（pegging rate）」と呼ばれることがある）。

このコード化スキームの利点は、上述の３つのパラメータだけを用いて、ブロックチェーン上のトークンとして取引をカプセル化又は表現するために使用できることである。実際に、取引は、これらの３つのデータアイテムのうちの最小限を用いて指定できる。このコード化スキームは任意の種類の転送可能取引のために使用可能なので、共通アルゴリズムが考案され適用され得る。これらのメタデータアイテムの更なる詳細は、以下に提供される。

分割可能トークンは、トランザクションアウトプット上の値が、複数のトークンに渡り（つまり、複数のトランザクションに渡り）割り当てられるより小さな量に細分化され得るものである。典型は、トークン化されたフィアット通貨である。分割可能取引は、非ゼロペギングレート（PeggingRate）を指定する取引として定められる。分割可能取引では、トランザクションアウトプットの中で転送されるトークン化された値は、ペギングレートにより基礎ビットコイン（bitcoin：ＢＴＣ）値に結び付けられる。つまり、取引ａｈ、ペギングレートの観点で、保持者の権利を指定する。非分割可能トークンでは、ペギングレートが存在せず、取引は、固定値の観点で、保持者の権利を指定する（例えば、「この取引は、正確に＄１０００で換金できる」という無記名債券、又は「この取引は１ヘアカットと交換可能である」という商品引換券のように）。非」分割可能取引では、基礎トランザクションＢＴＣ値は取引値と無関係である。

表現「基礎ＢＴＣ値」は、トランザクションアウトプットに付加されるビットコイン額（ＢＴＣ）を表す。ビットコインプロトコルでは、各トランザクションアウトプットは、有効と考えられる非ゼロＢＴＣ額を有しなければならない。実際には、ＢＴＣ額は、記述時に現在５４６サトシに設定される設定最小値（「ダスト（dust）」）より大きくなければならい。１ビットコインは、１００百万サトシに等しいと定められる。ビットコイントランザクションは本願明細書では所有権の交換を助ける手段としてのみ使用されるので、実際の基礎ＢＴＣ額は任意である。真の値は、取引仕様の中にある。理論上、全てのトークンは、ダストにより伝達され得る。

本発明のコード化スキームに従い、具体的に、分割可能トークンでは、基礎ＢＴＣ値は次の意味：ペギングレートにより取引値との関係を運ぶ、を有する。ペギングレートは、それ自体任意であり、基礎ＢＴＣ額を小さく保つために選択される。単にダストを有する基礎となる各トークントランザクションではなく、ペギングレートを使用する理由は、本発明のプロトコルが可視性を実現するからである。トークンが幾つかの小さな額のトランザクションアウトプットに分けられるとき、元の取引を調整する必要がない。むしろ、各細分化トークンの取引値は、単に、ペギングレート及び基礎ＢＴＣ値の細分化された額に基づき計算される。

限定トークンは、ＮｕｍＳｈａｒｅｓと呼ばれる量により定められる固定非ゼロの株数により合計発行値が固定された（又は「限定された」）トークンである。したがって、限定取引の下では更なる株は発行されない。例えば、競走馬の共同所有権のための取引は、競走馬の１００％に限定される（例えば、それぞれ１％で１００個の株、又はそれぞれ１０％で１０個の株、等）。非限定取引は、例えば要求額のフィアット通貨を彼らの引当金（Reserve Account）に追加することにより、発行人が株の更なる発行を引き受け可能であることを意味する。ＮｕｍＳｈａｒｅｓは、全ての取引に明示的に記載されなければならない。限定取引は、ＮｕｍＳｈａｒｅｓ＞０を有しなければならない。非限定取引は、ＮｕｍＳｈａｒｅｓ＝０を設定することにより示される。

典型的な例は、準備預金口座に保持される合計値が存在する約束手形（つまり未償還トークン）の合計値に一致するようにする、通貨準備（金準備と類似する）である。この概念は、通貨準備を超えて、在庫ストックにまで拡大する。例えば、認可印刷Ｔシャツトークンの発行人は、１０，０００枚のＴシャツの在庫で開始して良く、これらの１０，０００枚のＴシャツを表す分割可能トークンを発行して良い（ここで、各株＝１枚のＴシャツを表す）。元のトークンは細分化でき、各細分化トークンは、ペギングレートにより定められるトランザクションアウトプットの基礎ＢＴＣ値に従い、Ｔシャツの枚数に償還可能である。しかしながら、需要が増大する場合、発行人は更なる株を発行することを決定して良い（つまり、更に１０，０００枚だけ流通株数を増大する）。このような場合には、更なる発行を引き受けるために、発行人の準備口座（つまり、在庫倉庫）に更に１０，０００枚のＴシャツを預けることが、発行人の義務である。したがって、在庫にあるＴシャツの合計枚数は、常に、合計未償還株数である（ここで、在庫は「準備口座」として作用する）。

ペギングレートは、分割可能取引にのみ適用される。ここで、（ＳｈａｒｅＶａｌと呼ばれる量により表される）株の値は、基礎ＢＴＣ額に固定される。例えば、取引は、発行人が基礎１ＢＴＣ毎に＄１０，０００のレートでトークンを償還することを約束すると指定して良い。これは、（例えば）１５，４００サトシのトークン化された基礎アウトプット値を有するトランザクションが＄１．５４で償還可能であることを意味し得る。ペギングレートについて０の値は、取引が非分割可能であることを示す（つまり、無記名債券のように、全体のみが転送可能である）。ペギングレートが０に設定されると（非分割可能トークンを意味する）、基礎ＢＴＣ値は、取引値と無関係であり、任意の額に設定可能である。通常、この場合には、運用コストを最小化するために、基礎ＢＴＣ額を可能な限り小さく保つ（つまり、ダストに設定する）ことが望ましい。

ＮｕｍＳｈａｒｅｓは、（限定）取引の下で利用可能な合計（固定）株数である。限定取引では、ＮｕｍＳｈａｒｅｓは、ゼロより大きい全体数でなければならない。非限定取引では、いつでも（引き受けられるならば）より多くの株が発行可能なので、ＮｕｍＳｈａｒｅｓは固定されない。これは、値を０に設定することにより示される。

株は、転送単位として定められ、ＳｈａｒｅＶａｌはその単位の値である。例えば、フィアット通貨では、転送単位は１セントに設定されて良い。あるいは、例えば、転送単位は５０セントに設定されて良く、この場合には、転送は５０セントの「ロット」でのみ実行できる。ＳｈａｒｅＶａｌは、パーセンテージとしても表現できる。例えば、ブリーダが競走馬を１０個の等しい株で売りたいと望む場合、ＳｈａｒｅＶａｌ＝０を設定１０％である。ＳｈａｒｅＶａｌは０より大きくなければならず、且つ取引において定められなければならない。

ＴｏｔａｌＩｓｓｕａｎｃｅは、発行された株の合計値を表す。この値は限定取引にのみ関連する。非限定取引については、発行は固定されず、より多くの株が発行されて良い。株がパーセンテージとして表現される場合、定義によりＴｏｔａｌＩｓｓｕａｎｃｅ＝０を設定１００％である。

限定取引では、ＮｕｍＳｈａｒｅｓ、ＳｈａｒｅＶａｌ、及びＴｏｔａｌＩｓｓｕａｎｃｅは、以下のように関連する。

ＮｕｍＳｈａｒｅｓ×ＳｈａｒｅＶａｌ＝ＴｏｔａｌＩｓｓｕａｎｃｅ
ＴｏｔａｌＩｓｓｕａｎｃｅの０の値は、非限定取引であることを意味する。非限定取引の一例は、フィアット通貨である（したがって、ＴｏｔａｌＩｓｓｕａｎｃｅは０に設定される）。限定取引の例は、（ｉ）限定版記念硬貨（１０００個鋳造され、１株＝１硬貨である）、ＴｏｔａｌＩｓｓｕａｎｃｅ＝１０００×１＝１０００個の硬貨、（ｉｉ）入場券のある会場の席、ＴｏｔａｌＩｓｓｕａｎｃｅ＝利用可能な合計席数、である。

流通は、未使用トークンの合計値として定められる（つまり、ＵＴＸＯ（未使用トランザクションアウトプット）の中のトランザクションにより決定される）。全部の未使用トランザクションの完全な集合は、全てのビットコインノードに利用可能なリストの中に保持される。例えば、発行人が最初に＄１０，０００をフィアット通貨型のトークンとして発行し、時間を経て＄５５００の価値のトークンが償還された場合、流通＝＄４５００である（未償還トークンの値である）。この値は、関連する準備口座の差引残高に調整されるべきである。

＜サブキー生成の方法＞
以上では、表３及び例示的なシナリオは、元の（マスタ）キーからサブキーを生成することが有利である状況を参照した。これが実行され得る１つの方法を説明するために、これを達成する方法が以下に提供される。

図７は、通信ネットワーク５を介して第２ノード７と通信する第１ノード３を含むシステム１を示す。第１ノード３は関連する第１処理装置２３を有し、及び第２ノード５は関連する第２処理装置２７を有する。第１及び第２ノード３、７は、コンピュータ、電話機、タブレットコンピュータ、モバイル通信装置、コンピュータサーバ、等のような電子装置を含んで良い。一例では、第１ノード３はクライアント（ユーザ）装置であって良く、第２ノード７はサーバであって良い。サーバは、デジタルウォレットプロバイダのサーバであって良い。

第１ノード３は、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を有する第１非対称暗号対に関連付けられる。第２ノード７は、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び第２ノードマスタ公開鍵（Ｐ_１Ｓ）を有する第２非対称暗号対に関連付けられる。言い換えると、第１及び第２ノードは、それぞれ、個々の公開−秘密鍵対を保有する。

個々の第１及び第２ノード３、７の第１及び第２非対称暗号対は、ウォレットの登録のような登録処理中に生成されて良い。各ノードの公開鍵は、通信ネットワーク５に渡るように、公に共有されて良い。

第１ノード３及び第２ノード７の両者において共通シークレット（common secret：ＳＣ）を決定するために、ノード３、７は、通信ネットワーク５を介して秘密鍵を通信することなく、それぞれ方法３００、４００のステップを実行する。

第１ノード３により実行される方法３００は、少なくとも第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び生成器値（Generator Value：ＧＶ）に基づき、第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定するステップ３３０を含む。生成器値は、第１ノードと第２ノードとの間で共有されるメッセージ（Ｍ）に基づいて良い。これは、以下に詳述するように、通信ネットワーク５を介してメッセージを共有するステップを含んで良い。方法３００は、少なくとも第２ノードマスタ公開鍵（Ｐ_１Ｓ）及び生成器値（Generator Value：ＧＶ）に基づき、第２ノード第２公開鍵（Ｐ_２Ｓ）を決定するステップ３７０を更に含む。方法３００は、第１ノード第２秘密鍵（Ｖ_２Ｃ）及び第２ノード第２公開鍵（Ｐ_２Ｓ）に基づき、共通シークレット（common secret：ＣＳ）を決定するステップ３８０を含む。

重要なことに、同じ共通シークレット（ＣＳ）が、方法４００により第２ノード７においても決定できる。方法４００は、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及び生成器値（Generator Value：ＧＶ）に基づき、第１ノード第２公開鍵（Ｐ_２Ｃ）を決定するステップ４３０を含む。方法４００は、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び生成器値（Generator Value：ＧＶ）に基づき、第２ノード第２秘密鍵（Ｖ_２Ｓ）を決定するステップ４７０を更に含む。方法４００は、第２ノード第２秘密鍵（Ｖ_２Ｓ）及び第１ノード第２公開鍵（Ｐ_２Ｃ）に基づき、共通シークレット（common secret：ＣＳ）を決定するステップ４８０を含む。

通信ネットワーク５は、ローカルエリアネットワーク、ワイドエリアネットワーク、セルラネットワーク、無線通信ネットワーク、インターネット、等を含んで良い。これらのネットワークでは、データは電気線、光ファイバ、又は無線のような通信媒体を介して送信されて良く、登頂者１１による様な盗聴を受けやすい場合がある。方法３００、４００は、通信ネットワーク５を介して共通シークレットを送信することなく、第１ノード３及び第２ノード７が共通シークレットを両方とも独立して決定できるようにする。

したがって、１つの利点は、安全でない可能性のある通信ネットワーク５を介して秘密鍵を送信する必要を有しないで、共通シークレット（ＣＳ）が安全に且つ各ノードにより独立して決定できることである。また、共通シークレットは、秘密鍵として（又は秘密鍵の基礎として）使用されて良い。

方法３００、４００は、追加ステップを含んで良い。図１１を参照する。方法３００は、第１ノード３において、メッセージ（Ｍ）及び第１ノード第２秘密鍵（Ｖ_２Ｃ）に基づき、署名メッセージ（ＳＭ１）を生成するステップを含んで良い。方法３００は、第１署名メッセージ（ＳＭ１）を通信ネットワークを介して第２ノード７へ送信するステップ３６０を更に含む。一方、第２ノード７は、第１署名メッセージ（ＳＭ１）を受信するステップ４４０を実行して良い。方法４００は、第１署名メッセージ（ＳＭ２）を第１ノード第２公開鍵（Ｐ２Ｃ）により検証するステップ４５０、及び第１署名メッセージ（ＳＭ１）を検証するステップの結果に基づき第１ノード３を認証するステップ４６０を更に含む。有利なことに、これは、第２ノード７が、（第１署名メッセージが生成された場所である）意図された第１ノードが第１ノード３であることを認証することを可能にする。これは、第１ノード３だけが、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）へのアクセスを有する、したがって、第１ノード３だけが、第１署名メッセージ（ＳＭ１）を生成するための第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定できるという仮定に基づく。理解されるべきことに、同様に、第２署名メッセージ（ＳＭ２）は、第２ノード７において生成され、第１ノード３へ送信され得る。したがって、ピアツーピアシナリオにおけるように、第１ノード３は、第２ノード７を認証できる。

第１ノードと第２ノードの間のメッセージ（Ｍ）の共有は、様々な方法で達成されて良い。一例では、メッセージは、第１ノード３において生成されて良く、次に通信ネットワーク５を介して第２ノード７へ送信される。代替として、メッセージは、第２ノード７において生成されて良く、次に通信ネットワーク５を介して第１ノード３へ送信される。幾つかの例では、メッセージ（Ｍ）は公開されて良く、したがってセキュアでないネットワーク５を介して送信されて良い。１又は複数のメッセージ（Ｍ）は、データストア１３、１７、１９に格納されて良い。当業者は、メッセージの共有が様々な方法で達成できることを理解する。

有利なことに、共通シークレット（ＣＳ）の再生成を可能にするレコードは、そのレコード自体が秘密に格納され又はセキュアに送信される必要がなく、保持され得る。

＜登録の方法１００、２００＞
登録の方法１００、２００の一例は、図９を参照して記載される。図９では、方法１００は第１ノード３により実行され、方法２００は第２ノード７により実行される。これは、それぞれ第１ノード３及び第２ノード７のために第１及び第２非対称暗号対を確立するステップを含む。

非対称暗号対は、公開鍵暗号化で使用されるような、関連付けられた秘密鍵及び公開鍵を含む。本例では、非対称暗号対は、楕円曲線暗号システム（Elliptic Curve Cryptography：ＥＣＣ）及び楕円曲線演算の特性を用いて生成される。

方法１００、２００では、これは、共通ＥＣＣシステムに合意している１１０、２１０、且つ基点（Ｇ）を用いる、第１ノード及び第２ノードを含む（注：基点は、共通生成器として参照され得るが、用語「基点」は、生成器値ＧＶとの混同を避けるために使用される）。一例では、共通ＥＣＣシステムは、ビットコインにより使用されるＥＣＣシステムであるｓｅｃｐ２５６Ｋ１に基づいて良い。基点（Ｇ）は、選択され、ランダムに生成され、又は割り当てられて良い。

ここで第１ノード３について考えると、方法１００は、共通ＥＣＣシステム及び基点（Ｇ）を解決するステップ１１０を含む。これは、第２ノード７又は第３ノード９から、共通ＥＣＣシステム及び基点を受信するステップを含んで良い。代替として、ユーザインタフェース１５は、第１ノード３に関連付けられる。これにより、ユーザは、共通ＥＣＣシステム及び／又は基点（Ｇ）を選択的に提供できる。更に別の代替案では、共通ＥＣＣシステム及び／又は基点（Ｇ）の一方又は両方が、第１ノード３によりランダムに選択されて良い。第１ノード３は、通信ネットワーク５を介して、基点（Ｇ）と共に共通ＥＣＣシステムを使用することを示す通知を、第２ノード７へ送信して良い。また、第２ノード７は、共通ＥＣＣシステム及び基点（Ｇ）の使用に対する肯定応答を示す通知を送信することにより、解決して良い２１０。

方法１００は、第１ノード３が、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を有する第１非対称暗号対を生成するステップ１２０を更に含む。これは、共通ＥＣＣシステムの中で指定された許容範囲の中のランダム整数に少なくとも部分的に基づき、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）を生成するステップを含む。これは、次式に従い第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び基点（Ｇ）の楕円曲線点乗算に基づき、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を決定するステップを更に含む。
Ｐ_１Ｃ＝Ｖ_１Ｃ×Ｇ （式１）
したがって、第１非対称暗号対は、以下を含む：
Ｖ_１Ｃ：第１ノードにより秘密に保持される第１ノードマスタ秘密鍵。
Ｐ_１Ｃ：公に知らされる第１ノードマスタ公開鍵。

第１ノード３は、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）を、第１ノード３に関連付けられた第１データストア１３に格納して良い。セキュリティのために、第１ノードマスタ秘密鍵（Ｖ_１Ｃ）は、鍵が秘密のままであることを保証するために、第１データストア１３のセキュアな部分に格納されて良い。

方法１００は、図９に示すように、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を通信ネットワーク５を介して第２ノード７へ送信するステップ１３０を更に含む。第２ノード７は、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を受信すると２２０、第１ノードマスタ公開鍵（Ｐ_１Ｃ）を第２ノード７に関連付けられた第２データストア１７に格納して良い２３０。

第１ノード３と同様に、第２ノード７の方法２００は、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び第２ノードマスタ公開鍵（Ｐ_１Ｓ）を有する第２非対称暗号対を生成するステップ２４０を含む。第２ノードマスタ秘密鍵（Ｖ_１Ｓ）も、許容範囲内のランダム整数である。また、第２ノードマスタ公開鍵（Ｐ_１Ｓ）は、次式により決定される。
Ｐ_１Ｓ＝Ｖ_１Ｓ×Ｇ （式２）
したがって、第２非対称暗号対は、以下を含む：
Ｖ_１Ｓ：第２ノードにより秘密に保持される第２ノードマスタ秘密鍵。
Ｐ_１Ｓ：公に知らされる第２ノードマスタ公開鍵。

第２ノード７は、第２非対称暗号対を第２データストア１７に格納して良い。方法２００は、第２ノードマスタ公開鍵（Ｐ_１Ｓ）を第１ノード３へ送信するステップ２５０を更に含む。また、第１ノード３は、第２ノードマスタ公開鍵（Ｐ_１Ｓ）を受信し１４０、格納して良い１５０。

理解されるべきことに、幾つかの代案では、それぞれの公開マスタ鍵は、受信され、（信頼できる第三者のような）第３ノード９に関連付けられた第３データストア１９に格納されて良い。これは、認証機関のような、公開ディレクトリとして動作する第三者を含んで良い。したがって、幾つかの例では、第１ノードマスタ公開鍵（Ｐ_１Ｃ）は、共通シークレット（ＣＳ）が要求されるときだけ、第２ノード７により要求され受信されて良い（逆も同様である）。

登録ステップは、初期設定として１度生じるだけで良い。

＜セッション開始及び第１ノード３による共通シークレットの決定＞
共通シークレット（ＣＳ）を決定する一例は、図１０を参照してここに記載される。共通シークレット（ＣＳ）は、第１ノード３と第２ノード７との間の特定のセッション、時間、トランザクション、又は他の目的のために使用されて良く、同じ共通シークレット（ＣＳ）を使用することが望ましい又はセキュアでなくて良い。したがって、共通シークレット（ＣＳ）は、異なるセッション、時間、トランザクション、等の間で変更されて良い。

以下は、上述したセキュアな送信技術の説明のために提供される。

［メッセージ（Ｍ）を生成する３１０］
本例では、第１ノード３により実行される方法３００は、メッセージ（Ｍ）を生成するステップ３１０を含む。メッセージ（Ｍ）は、ランダム、疑似ランダム、又はユーザ定義であって良い。一例では、メッセージ（Ｍ）は、Ｕｎｉｘ時間又はノンス（及び任意の値）に基づく。例えば、メッセージ（Ｍ）は次のように与えられ得る。
メッセージ（Ｍ）＝Ｕｎｉｘ時間＋ノンス （式３）
幾つかの例では、メッセージ（Ｍ）は任意である。しかしながら、理解されるべきことに、メッセージ（Ｍ）は、幾つかのアプリケーションで有用であり得る（Ｕｎｉｘ時間、等のような）選択的値を有して良い。

方法３００は、メッセージ（Ｍ）を通信ネットワーク５を介して第２ノード７へ送信するステップ３１５を含む。メッセージ（Ｍ）は秘密鍵についての情報を含まないので、メッセージ（Ｍ）は、セキュアでないネットワークを介して送信されて良い。

［生成器値（ＧＶ）を決定する３２０］
方法３００は、メッセージ（Ｍ）に基づき生成器値（Generator Value：ＧＶ）を決定するステップ３２０を更に含む。本例では、これは、メッセージの暗号ハッシュを決定するステップを含む。暗号ハッシュアルゴリズムの一例は、２５６ビット発生器値（ＧＶ）を生成するためにＳＨＡ−２５６を含む。つまり、
ＧＶ＝ＳＨＡ−２５６（Ｍ） （式４）
理解されるべきことに、他のハッシュアルゴリズムが使用されて良い。これは、セキュアなハッシュアルゴリズム（Secure Hash Algorithm：ＳＨＡ）ファミリの中の他のハッシュアルゴリズムを含んで良い。幾つかの特定の例は、ＳＨＡ３−２２４、ＳＨＡ３−２５６、ＳＨＡ３−３８４、ＳＨＡ３−５１２、ＳＨＡＫＥ１２８、ＳＨＡＫＥ２５６を含むＳＨＡ−３サブセットの中のインスタンスを含む。他のハッシュアルゴリズムは、ＲＩＰＥＭＤ（RACE Integrity Primitives Evaluation Message Digest）ファミリの中のアルゴリズムを含んで良い。特定の例は、ＲＩＰＥＭＤ−１６０を含んで良い。他のハッシュ関数は、Ｚｅｍｏｒ−Ｔｉｌｌｉｃｈハッシュ関数及びナップサック・ハッシュ関数に基づくファミリを含んで良い。

［第１ノード第２秘密鍵を決定する３３０］
方法３００は、次に、第２ノードマスタ秘密鍵（Ｖ_１Ｃ）及び生成器値（ＧＶ）に基づき、第１ノード第２秘密鍵（Ｖ_２Ｃ）を決定するステップ３３０を含む。これは、次式に従い第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び生成器値（ＧＶ）のスカラ加算に基づき得る。
Ｖ_２Ｃ＝Ｖ_１Ｃ＋ＧＶ （式５）

したがって、第１ノード第２秘密鍵（Ｖ_２Ｃ）は、ランダム値ではないが、代わりに第１ノードマスタ秘密鍵から確定的に導出される。暗号対の中の対応する公開鍵、つまり第１ノード第２公開鍵（Ｐ_２Ｃ）は、以下の関係を有する。
Ｐ_２Ｃ＝Ｖ_２Ｃ×Ｇ （式６）

式５から式６にＶ_２Ｃを代入すると、次式を得る。
Ｐ_２Ｃ＝（Ｖ_１Ｃ＋ＧＶ）×Ｇ （式７）
ここで、「＋」演算子はスカラ加算を表し、「×」演算子は楕円曲線点乗算を表す。楕円曲線暗号代数は、分配的であり、式７は次式のように表すことができる。
Ｐ_２Ｃ＝Ｖ_１Ｃ×Ｇ＋ＧＶ×Ｇ （式８）

最後に、（式１）は（式７）に代入され、次式を得る。
Ｐ_２Ｃ＝Ｐ_１Ｃ＋ＧＶ×Ｇ （式９．１）
Ｐ_２Ｃ＝Ｐ_１Ｃ＋ＳＨＡ−２５６（Ｍ）×Ｇ （式９．２）
式８〜９．２において、「＋」演算子は楕円曲線点加算を表す。したがって、対応する第１ノード第２公開鍵（Ｐ_２Ｃ）は、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及びメッセージ（Ｍ）の導出可能な所与の知識であり得る。方法４００に関して以下に更に詳述するように、第２ノード７は、第１ノード第２公開鍵（Ｐ_２Ｃ）を独立に決定するために、このような知識を有して良い。

［メッセージ及び第１ノード第２秘密鍵に基づき、第１署名メッセージ（ＳＭ１）を生成する３５０］
方法３００は、メッセージ（Ｍ）及び決定した第１ノード第２秘密鍵（Ｖ_２Ｃ）に基づき、第１署名メッセージ（ＳＭ１）を生成するステップ３５０を更に含む。署名メッセージを生成するステップは、メッセージ（Ｍ）にデジタル方式で署名するために、デジタル署名アルゴリズムを適用するステップを含む。一例では、これは、第１署名メッセージ（ＳＭ１）を得るために、楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm：ＥＣＤＳＡ）の中でメッセージに第１ノード第２秘密鍵（Ｖ_２Ｃ）を適用するステップを含む。ＥＣＤＳＡの例は、ｓｅｃｐ２５６ｋ１、ｓｅｃｐ２５６ｒ１、ｓｅｃｐ３８４ｒ１、ｓｅ３ｃｐ５２１ｒ１を有するＥＣＣシステムに基づくものを含む。

第１署名メッセージ（ＳＭ１）は、第２ノード７において対応する第１ノード第２公開鍵（Ｐ_２Ｃ）により検証できる。第１署名メッセージ（ＳＭ１）のこの検証は、第１ノード３を認証するために第２ノード７により使用されて良い。これは、方法４００において以下に議論される。

［第２ノード第２公開鍵を決定する３７０’］
第１ノード３は、次に、第２ノード第２公開鍵（Ｐ_２Ｓ）を決定して良い３７０。上述のように、第２ノード第２公開鍵（Ｐ_２Ｓ）は、少なくとも第２ノードマスタ公開鍵（Ｐ_１Ｓ）及び生成器値（ＧＶ）に基づいて良い。本例では、公開鍵は、基点（Ｇ）との楕円曲線点乗算により秘密鍵として決定されるので３７０’、第２ノード第２公開鍵（Ｐ_２Ｓ）は、式６と同様に次のように表すことができる。
Ｐ_２Ｓ＝Ｖ_２Ｓ×Ｇ （式１０．１）
Ｐ_２Ｓ＝Ｐ_１Ｓ＋ＧＶ×Ｇ （式１０．２）
式１０．２の数学的証明は、第１ノード第２公開鍵（Ｐ_２Ｃ）について式９．１を導出するために上述したものと同じである。理解されるべきことに、第１ノード３は、第２ノード７と独立に第２ノード第２公開鍵を決定できる３７０。

［第１ノード３において共通シークレットを決定する３８０］
第１ノード３は、次に、第１ノード第２秘密鍵（Ｖ_２Ｃ）及び決定した第２ノード第２公開鍵（Ｐ_２Ｓ）に基づき、共通シークレット（ＣＳ）を決定して良い３８０。共通シークレット（ＣＳ）は、第１ノード３により次式により決定されて良い。
Ｓ＝Ｖ_２Ｃ×Ｐ_２Ｓ （式１１）

＜第２ノード７において実行される方法４００＞
第２ノード７において実行される対応する方法４００が、ここで説明される。理解されるべきことに、これらのステップのうちの幾つかは、第１ノード３により実行された上述のステップと同様である。

方法４００は、メッセージ（Ｍ）を通信ネットワーク５を介して第１ノード３から受信するステップ４１０を含む。これは、ステップ３１５において第１ノード３により送信されたメッセージ（Ｍ）を含んで良い。第２ノード７は、次に、メッセージ（Ｍ）に基づき生成器値（ＧＶ）を決定する４２０。第２ノード７により生成器値（ＧＶ）を決定するステップ４２０は、上述の第１ノードにより実行されるステップ３２０と同様である。本例では、第２ノード７は、第１ノード３と独立の、この決定するステップ４２０を実行する。

次のステップは、第１ノードマスタ公開鍵（Ｐ_１Ｃ）及び生成器値（ＧＶ）に基づき、第１ノード第２公開鍵（Ｐ_２Ｃ）を決定するステップ４３０を含む。本例では、公開鍵は、基点（Ｇ）との楕円曲線点乗算により秘密鍵として決定されるので４３０’、第１ノード第２公開鍵（Ｐ_２Ｃ）は、式９と同様に次のように表すことができる。
Ｐ_２Ｃ＝Ｖ_２Ｃ×Ｇ （式１２．１）
Ｐ_２Ｃ＝Ｐ_１Ｃ＋ＧＶ×Ｇ （式１２．２）

式１２．１及び１２．２の数学的証明は、式１０．１及び１０．２について上述したものと同じである。

［第２ノード７が第１ノード３を認証する］
方法４００は、未確認第１ノード３が第１ノード３であることを認証するために、第２ノード７により実行されるステップを含んで良い。上述のように、これは、第１ノード３から第１署名メッセージ（ＳＭ１）を受信するステップ４４０を含む。第２ノード７は、次に、ステップ４３０で決定された第１ノード第２公開鍵（Ｐ_２Ｃ）により第１署名メッセージ（ＳＭ１）の署名を検証して良い４５０。

デジタル署名の検証は、上述の楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm：ＥＣＤＳＡ）に従い行われて良い。重要なことに、第１ノード第２秘密鍵（Ｖ_２Ｃ）により署名された第１署名メッセージ（ＳＭ１）は、Ｖ_２Ｃ及びＰ_２Ｃが暗号対を形成するので、対応する第１ノード第２公開鍵（Ｐ_２Ｃ）によってのみ正しく検証されるべきである。これらの鍵は、第１ノード３の登録で生成された第１ノードマスタ秘密鍵（Ｖ_１Ｃ）及び第１ノードマスタ公開鍵（Ｐ_１Ｃ）において確定するので、第１署名メッセージ（ＳＭ１）の検証は、第１署名メッセージ（ＳＭ１）を送信する未確認第１ノードが登録中と同じ第１ノード３であることを認証する基礎として使用できる。したがって、第２ノード７は、第１署名メッセージを検証するステップ（４５０）の結果に基づき、第１ノード３を認証するステップ（４６０）を更に実行して良い。

［第２ノード７が共通シークレットを決定する］
方法４００は、第２ノード７が、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び生成器値（ＧＶ）に基づき、第２ノード第２秘密鍵（Ｖ_２Ｓ）を決定するステップ４７０を更に含んで良い。第１ノード３により実行されるステップ３３０と同様に、第２ノード第２秘密鍵（Ｖ_２Ｓ）は、次式に従い、第２ノードマスタ秘密鍵（Ｖ_１Ｓ）及び生成器値（ＧＶ）のスカラ加算に基づき得る。
Ｖ_２Ｓ＝Ｖ_１Ｓ＋ＧＶ （式１３．１）
Ｖ_２Ｓ＝Ｖ_１Ｓ＋ＳＨＡ−２５６（Ｍ） （式１３．２）

第２ノード７は、次に、第１ノード３と独立して、次式に基づき、第２ノード第２秘密鍵（Ｖ_２Ｓ）及び第１ノード第２公開鍵（Ｐ_２Ｃ）に基づき、共通シークレット（ＣＳ）を決定して良い４８０。
Ｓ＝Ｖ_２Ｓ×Ｐ_２Ｃ （式１４）

［第１ノード３及び第２ノード７により決定された共通シークレット（ＣＳ）の証明］
第１ノード３により決定された共通シークレット（ＣＳ）は、第２ノード７において決定された共通シークレット（ＣＳ）と同じである。式１１及び式１４が同じ共通シークレット（ＣＳ）を提供することの数学的証明が、ここで記載される。

第１ノード３により決定された共通シークレット（ＣＳ）を考えると、次のように式１０．１は式１１に代入できる。
Ｓ＝Ｖ_２Ｃ×Ｐ_２Ｓ （式１１）
Ｓ＝Ｖ_２Ｃ×（Ｖ_２Ｓ×Ｇ）
Ｓ＝（Ｖ_２Ｃ×Ｖ_２Ｓ）×Ｇ （式１５）

第２ノード７により決定された共通シークレット（ＣＳ）を考えると、次のように式１２．１は式１４に代入できる。
Ｓ＝Ｖ_２Ｓ×Ｐ_２Ｃ （式１４）
Ｓ＝Ｖ_２Ｓ×（Ｖ_２Ｃ×Ｇ）
Ｓ＝（Ｖ_２Ｓ×Ｖ_２Ｃ）×Ｇ （式１６）

ＥＣＣ代数学は可換性なので、次の通り式１５及び式１６は等価である。
Ｓ＝（Ｖ_２Ｃ×Ｖ_２Ｓ）×Ｇ＝（Ｖ_２Ｓ×Ｖ_２Ｃ）×Ｇ （式１７）

［共通シークレット（ＣＳ）及び秘密鍵］
共通シークレット（ＣＳ）は、ここで、第１ノード３と第２ノード７との間のセキュアな通信のために、対称鍵アルゴリズムにおいて、秘密鍵として又は秘密鍵の基礎として、使用できる。

共通シークレット（ＣＳ）は、楕円曲線点（ｘ_Ｓ，ｙ_Ｓ）の形式であって良い。これは、ノード３、７により合意された標準的な公に知られた演算を用いて、標準的な鍵フォーマットに変換されて良い。例えば、ｘ_Ｓ値は、ＡＥＳ_２５６暗号鍵として使用され得る２５６ビットの整数であって良い。これは、更に、１６０ビットの長さの鍵を必要とする任意のアプリケーションのために、ＲＩＰＥＭＤ１６０を用いて１６０ビットの整数に変換され得る。

共通シークレット（ＣＳ）は、必要に応じて決定されて良い。重要なことに、共通シークレット（ＣＳ）はメッセージ（Ｍ）に基づき再決定できるので、第１ノード３は共通シークレット（ＣＳ）を格納する必要がない。幾つかの例では、使用されるメッセージ（Ｍ）は、マスタ秘密鍵のために要求されるのと同レベルのセキュリティを有しないデータストア１３、１７、１９（又は他のデータストア）に格納されて良い。幾つかの例では、メッセージ（Ｍ）は公に利用可能であって良い。

しかしながら、幾つかのアプリケーションに依存して、共通シークレット（ＣＳ）が第１ノードマスタ秘密鍵（Ｖ_１Ｃ）と同じくらいセキュアに保たれるならば、共通シークレット（ＣＳ）は、第１ノードに関連付けられた第１データストア（Ｘ）に格納され得る。

有利なことに、この技術は、単一のマスタキー暗号対に基づき、複数のセキュアな秘密鍵に対応し得る複数の共通シークレットを決定するために使用できる。

＜生成器値（鍵）の階層構造＞
例えば、一連の連続する生成器値（ＧＶ）が決定されて良い。ここで、各連続ＧＶは、前の生成器値（ＧＶ）に基づき決定されて良い。例えば、連続する専用鍵を生成するためにステップ３１０〜３７０、４１０〜４７０を繰り返す代わりに、ノード間の事前合意により、生成器値の階層構造を確立するために、前に使用された生成器値（ＧＶ）が両方のパーティにより繰り返し再ハッシュされ得る。実際に、メッセージ（Ｍ）のハッシュに基づく生成器値は、次世代生成器値（ＧＶ’）のための次世代メッセージ（Ｍ’）になり得る。これを行うことは、計算されるべき共有シークレットの連続生成を可能にし、更なるプロトコルにより確立される送信、特に共通シークレットを生成する毎に複数のメッセージの送信の必要がない。次世代共通シークレット（ＣＳ’）は、以下のように計算できる。

先ず、第１ノード３及び第２ノード７の両者が、次世代生成器値（ＧＶ’）を独立して決定する。これは、ステップ３２０及び４２０と同様であるが、次式により適応される。

Ｍ’＝ＳＨＡ−２５６（Ｍ） （式１８）
ＧＶ’＝ＳＨＡ−２５６（Ｍ’） （式１９．１）
ＧＶ’＝ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ）） （式１９．２）

第１ノード３は、次に、次世代の第２ノード第２公開鍵（Ｐ_２Ｓ’）及び第１ノード第２秘密鍵（Ｖ_２Ｃ’）を上述のステップ３７０及び３３０と同様であるが次式により適応され、決定して良い。
Ｐ_２Ｓ’＝Ｐ_１Ｓ＋ＧＶ’×Ｇ （式２０．１）
Ｖ_２Ｃ’＝Ｖ_１Ｃ＋ＧＶ’ （式２０．２）

第２ノード７は、次に、次世代の第１ノード第２公開鍵（Ｐ_２Ｃ’）及び第２ノード第２秘密鍵（Ｖ_２Ｓ’）を上述のステップ４３０及び４７０と同様であるが次式により適応され、決定して良い。
Ｐ_２Ｃ’＝Ｐ_１Ｃ＋ＧＶ’×Ｇ （式２１．１）
Ｖ_２Ｓ’＝Ｖ_１Ｓ＋ＧＶ’ （式２１．２）

第１ノード３及び第２ノード７は、次に、それぞれ、次世代共通シークレット（ＣＳ’）を決定して良い。特に、第１ノード３は、次式により次世代共通シークレット（ＣＳ’）を決定する。
ＣＳ’＝Ｖ_２Ｃ’×Ｐ_２Ｓ’ （式２２）

第２ノード７は、次式により次世代共通シークレット（ＣＳ’）を決定する。
ＣＳ’＝Ｖ_２Ｓ’×Ｐ_２Ｃ’ （式２３）
更なる世代（ＣＳ’’、ＣＳ’’’、等）は、チェーン階層構造を生成するために同じ方法で計算できる。この技術は、第１ノード３及び第２ノード７の両者が元のメッセージ（Ｍ）又は最初に計算された生成器値（ＧＶ）、及びそれがどのノードに関連するか、を見失わないことを要求する。これは公に知られた情報なので、この情報の保有に関してセキュリティ問題は存在しない。したがって、この情報は、（ハッシュ値を公開鍵にリンクする）「ハッシュテーブル」に保持され、（例えばＴｏｒｒｅｎｔを用いて）ネットワーク５に渡り自由に配布されて良い。さらに、階層構造内の任意の個々の共通シークレット（ＣＳ）が今までに解決されていない場合、これは、秘密鍵Ｖ_１Ｃ、Ｖ_１Ｓがセキュアなままであるならば、階層構造の中の任意の他の共通シークレットのセキュリティに影響しない。

＜鍵の木構造＞
上述のようなチェーン（線形）階層構造と同様に、木構造の形式の階層構造が生成できる。木構造によると、認証鍵、暗号鍵、署名鍵、支払鍵、等のような異なる目的の様々な鍵が決定されて良い。それにより、これらの鍵は、全て単一のセキュアに維持されるマスタキーにリンクされる。これは、種々の異なる鍵を有する木構造９０１を示す図１２に図示される。これらの各々は、別のパーティと共有されるシークレットを生成するために使用できる。枝分かれする木は、幾つかの方法で達成でき、それらのうちの３つが以下に記載される。

（ｉ）マスタキー・スポーニング
チェーン階層構造では、乗算した再ハッシュしたメッセージを元のマスタキーに加算することにより、各々の新しい「リンク」（公開／秘密鍵ペア）が生成される。例えば（明確性のため、第１ノード３の秘密鍵のみを示す）、
Ｖ_２Ｃ＝Ｖ_１Ｃ＋ＳＨＡ−２５６（Ｍ） （式２４）
Ｖ_２Ｃ’＝Ｖ_１Ｃ＋ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ）） （式２５）
Ｖ_２Ｃ’’＝Ｖ_１Ｃ＋ＳＨＡ−２５６（ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ））） （式２６）
等である。

枝を生成するために、任意の鍵がサブマスタキーとして使用できる。例えば、Ｖ_２Ｃ’は、正規のマスタキーに対して行われるように、ハッシュを加算することにより、サブマスタキー（Ｖ_３Ｃ）として使用できる。
Ｖ_３Ｃ＝Ｖ_２Ｃ’＋ＳＨＡ−２５６（Ｍ） （式２７）

サブマスタキー（Ｖ_３Ｃ）は、それ自体が、次世代鍵（Ｖ_３Ｃ’）を有して良い。例えば次式の通りである。
Ｖ_３Ｃ’＝Ｖ_２Ｃ’＋ＳＨＡ−２５６（ＳＨＡ−２５６（Ｍ）） （式２８）

これは、図１３に示すマスタキー・スポーニング（spawning）方法を用いて、木構造９０３を提供する。

（ｉｉ）論理的関連付け
この方法では、木の中の全てのノード（公開／秘密鍵ペア）は、チェーンとして（又は任意の他の方法で）生成され、木の中のノード間の論理的関係は、ポインタを用いて木の中の各ノードが木の中の自身の親ノードに単純に関連付けられるテーブルにより維持される。したがって、ポインタは、セッションの共通シークレットキー（ＣＳ）を決定するために、関連する公開／秘密鍵ペアを決定するために使用できる。

（ｉｉｉ）メッセージ多様性
新しい公開／秘密鍵ペアは、チェーン又は木の任意のポイントに新しいメッセージを導入することにより、生成できる。メッセージ自体は、任意であって良く、又は何らかの意味若しくは関数を伝達して良い（例えば、それは、「現実の」銀行口座番号に関連して良い、等である）。新しい公開／秘密鍵ペアを形成するためのこのような新しいメッセージがセキュアに保持されることが望ましい場合がある。

＜本発明と共に使用するための説明のための計算エージェント＞
本発明は、取引処理の自動化された態様を実行するために、計算リソース又はエージェントを利用できる。適切なエージェントの一例が以下に提供されるが、他の実装が使用されて良い。

エージェントは、チューリング（Turing）機械の実装において非消去可能テープとしてブロックチェーンを使用して、ブロックチェーンと連携して動作して良い。このエージェントは、ブロックチェーンネットワークと並列に実行し、（ループ）処理の実行を監督し及び扱う。ループ処理は、例えば装置又はシステムの処理又は制御の自動化のような所与のタスクを実行するよう設計される。この並列リソースは、ブロックチェーンの状態を監視し、トランザクションをブロックチェーンに書き込ませることができる。ある意味で、これは、ブロックチェーンをチューリング機械の非消去可能テープとして利用し、以下の定義及び特徴を有する。
１．ブロックチェーンは、チューリング機械のテープとして作用する。ブロックチェーンの中の各トランザクションは、テープ上のセルを表す。このセルは、有限なアルファベットからの記号を含み得る。
２．テープヘッドは、ブロックチェーン上に既に書き込まれているブロックから情報を読み出すことができる。
３．テープヘッドは、多くのトランザクションを含む新しいブロックを、ブロックチェーンの終わりに書き込むことができる。しかしながら、それらは、既に存在するブロックに書き込むことができない、このように、ブロックチェーンテープは非消去可能である。
４．各トランザクションのマルチシグネチャのＰ２ＳＨ（pay−to−script−hash）トランザクションの部分として格納され得る。

エージェントに重要な機能は、ブロックチェーンの現在状態を監視する自動エンティティとして作用することである。これは更に、任意のオフブロックソースから、信号又は入力を受信できる。ブロックチェーン状態及び／又は受信した入力に依存して、エージェントは特定動作を実行して良い。エージェントは、どの動作が実行されるべきかを決定する。これらは、「現実世界」（つまり、オフブロック）の中の作用、及び／又（新しいトランザクションを生成する及びブロードキャストするような）はブロックチェーンに対する作用を含んで良く又は含まなくて良い。エージェントが取る作用は、ブロックチェーン状態によりトリガされて良い。エージェントは、更に、ビットコインネットワークにブロードキャストされるべき次のトランザクションセットについて決定し、後にブロックチェーンに書き込んで良い。

エージェントの作用は、並列に且つ同時にブロックチェーン（例えば、ビットコイン）ネットワークに対して実行する。ある意味で、これは、ブロックチェーン（例えば、ビットコイン）スクリプトの機能を格納する。この連続監視は、結合されたエージェント及びブロックチェーンシステムチューリング完全（Turing Complete）を作成する「ループ」制御フロー構成を実施する。

チューリング機械は、以下の２つのスタックを含む。
・データスタック：これは、上述のようにブロックチェーンにより表される。
・制御スタック：これは、エージェント機能により表される。これは、繰り返し制御フロー機能に関連する情報を格納する。

制御スタックのデータスタックからの分離は、無限ループがビットコイン中核で生じることを防ぎ、サービス拒否攻撃を軽減するという利点を提供する。

エージェントは、任意の種類のループ構成（例えば、ＦＯＲ−ＮＥＸＴ、ＲＥＰＥＡＴ ＵＮＴＩＬ、等）によりループ可能なサブルーチンを管理し及び実行する。本願明細書に記載の説明のための実施形態は、「繰り返し（ｒｅｐｅａｔ）」構成の一例を用いる処理を含む。ユーザは、インデックス（ｉ）及び限界（Ｊ）を指定して良い。これらはそれぞれ、現在の反復番号（標準的に０から開始してカウントされる）、及び繰り返しループの合計反復数、を表す。

各反復について、
１．インデックスが１だけ増大する。終了条件については、インデックスが限界に達すると、反復は停止する。
２．「if condition then action（［条件］ならば［動作］する）」（ＩＣＴＡ）文を含むコードブロックが実行される。動作は、ブロックチェーン上の又は外の任意の動作であって良い。
３．このサブルーチンの暗号ハッシュが計算される。これは、トランザクションの部分としてブロックチェーンに格納できる。ハッシュは各コードにユニークなので、どのコードが使用されているかの検証を可能にする。

ループ本体は、コードブロックを含む。各コードブロックは、「if condition then action（［条件］ならば［動作］する）」（ＩＣＴＡ）文を含む。これは、以下に一致するトランザクションについて、ブロックチェーンの現在状態を監視する。
・開始又はトリガ条件（例えば、特定日に達したとき）、
・繰り返し条件（つまり、前の反復に関連付けられたメタデータ又はハッシュ）、
・停止条件（つまり、ループの最後の反復）。

ＩＣＴＡ文は、エージェントが、ブロックチェーンの現在状態に基づき、次のトランザクションについて決定することを可能にする。次のトランザクションを生成することは、トランザクションをビットコインネットワークにブロードキャストすること、及び新しいトランザクションをブロックチェーンに書き込むことを含む。これは、この反復が実行されたことの記録として作用する。トランザクションがブロックチェーンに書き込まれると、マネジャは、続いて、前の反復が実行されブロックチェーンに書き込まれたことを知り、次の反復を実行するだろう。後者は、インデックス（ｉ）がコードブロックの中で指定された限度（Ｊ）に達するとき、繰り返しループが存在するまで継続する。

各トランザクションは、再利用可能な方法で、ブロックチェーンに保存される。ビットコイン実装では、トランザクションの中の各署名は、ＳＩＧＨＡＳＨフラグを付加される。このフラグは、異なる値を取ることができる。これらの値の各々は、この署名の所有者の関与無しに、トランザクションの他の部分が変更され得るか否かを示す。再利用可能トランザクションは、トランザクションインプットのうちの１つの中にＳＩＧＨＡＳＨフラグ「ＳｉｇＨａｓｈ＿ＡｎｙｏｎｅＣａｎＰａｙ」を有する。これは、誰もがトランザクションのインプットに貢献することを許容する。このパラメータは、エージェントのＩＣＴＡ関数が、複数回、異なるインプットで、実行され且つ繰り返されることを可能にする。この関数の使用は、例えば再利用トランザクションの複製により、認可パーティに制限できる。

ＩＣＴＡコードブロックの「If condition」部分は、任意の種類の条件を監視できる。これは、他のプログラミング言語（例えば、Ｃ、Ｃ＋＋、Ｊａｖｅ）と同様であり、ブロックチェーンに格納された情報に限定されない。例えば、これは、日付及び時間（つまり、特定の日時に達したとき）を監視し、又は天気（つまり、気温が１０℃より低く且つ雨が降っているとき）を監視し、取引又は信用の条件（つまり、企業Ａが企業Ｂを買うとき）を監視し得る。

ＩＣＴＡコードブロックの「Then action」部分は、多数の動作を実行できる。本発明は、取り得る動作の数又は種類に関して限定されない。動作は、ブロックチェーン上のトランザクションに限定されないが、動作に関連するメタデータを含むトランザクションは、ブロックチェーンに書き込まれて良い。

メタデータは、任意の形式であり得る。しかしながら、一実施形態では、メタデータは、動作に関連するより多くのデータ又は指示を含むファイルへのハイパーリンクを格納して良い。メタデータは、動作に関連するより多くのデータ又は指示を含むハッシュテーブルへのハイパーリンク、及びハッシュテーブルに対する検索キーとして作用する動作のハッシュの両方を格納して良い。

エージェントの制御スタックは、各ユーザの必要に特化した多数の方法で実装できる。例えば、制御スタックの繰り返しループは、任意のチューリング完全言語に基づき得る。言語の１つの可能な選択は、Ｆｏｒｔｈ型スタックに基づく言語である。この言語を使用する利点は、制御スタックを、既知であり且つ広く使用されているビットコインスクリプトとプログラミング型において一貫性を保つことである。

＜ビットコインスクリプトの交互形式スタック（Alternate Stack）をデータ記憶空間として使用する＞
ビットコインスクリプトは、コマンド、更に呼び出されるオペコード、を含む。これらは、ユーザが、データを「ａｌｔ ｓｔａｃｋ」として知られる交互形式スタックに移動させることを可能にする。

オペコードは、次の通りである。
・ＯＰ＿ＴＯＡＬＴＳＴＡＣＫ。これは、データを主スタックの最上部からａｌｔ ｓｔａｃｋの最上部に移動させる。
・ＯＰ＿ＦＲＯＭＡＬＴＳＴＡＣＫ。これは、データをａｌｔ ｓｔａｃｋの最上部から主スタックの最上部に移動させる。

これは、計算機にデータを格納させる「記憶（memory）」機能と同様に、中間計算ステップからのデータをａｌｔ ｓｔａｃｋに格納させる。一実施形態では、ａｌｔ ｓｔａｃｋは、小さな計算タスクを解決するようビットコインスクリプトを構成するために、及び結果を計算に返すために、使用される。

＜エージェントを管理するためにコードレジスタを使用する＞
エージェントは、また、自身の所有し且つ実行する全てのコードのレジストリを管理する。このレジストリは、特定キーを特定値にマッピングするルックアップテーブル又は辞書のように構造化される。キー及び値ペアは、それぞれ、コードブロックのハッシュ（Ｈ_１）及びコードが格納された場所のＩＰｖ６アドレスにより表される。キーＨ_１を用いてコードブロックを読み出すために、ルックアップテーブルが使用されて、関連する値（これは、コードの格納されている場所である）を読み出し、及びそれに応じてソースコードを読み出す。コードレジストリの実装は変化し得る。

＜エージェントのコードのトランザクションメタデータ、及びループの再スポーニング＞
特定の反復でエージェントのループを再スポーニングするために必要な情報は、ブロックチェーンに記録されたトランザクションの中にメタデータとして格納される。

このように、ブロックチェーン上のトランザクションは、エージェント上で実行されているループの所与の反復に関する情報を格納し、又はそれへのアクセスを提供する。この情報は、ループに関連付けられた任意の変数の値、例えばインデックスｉ、及び任意の他の必要な情報、例えばコードブロック内で使用されるパラメータの値又は更に要求される情報がアクセス可能な場所の位置関連データ、を含み得る。

メタデータ自体は、トランザクションの中のマルチシグネチャのＰ２ＳＨ（pay−to−script−hash）スクリプトの部分として格納される。トランザクションと共に記録されたメタデータは、コードが過去にどのように実行されたかのオーディットトレイルを記録する能力も与える。

エージェントが各反復で繰り返しループコードブロックを再スポーニングできる幾つかの方法が存在する。コードブロックは、エージェント自体にハードコードされて良く、又は秘密に若しくは公に利用可能なファイルに格納でき、又は、秘密若しくは公開ハッシュテーブルファイル上のエントリとして格納され得る、又はこれらの組み合わせである。コードブロックは、ハードコードされた変数に固定され、又は固定であるが、移植可能なパラメータを含み得る。パラメータは、任意のデータフォーマットの単一値であって良く、又は小さなコードチャンクであって良く、又はそれらの組み合わせであって良い。パラメータは、トランザクション（例えば、ビットコイントランザクション）の中のメタデータから、又は内部データベース又は秘密／公開ファイル又はハッシュテーブル又はこれらの任意の組み合わせのような外部ソースから、直接に該パラメータを読み出すことにより移植され得る。パラメータ値の外部ソースへのポインタは、トランザクションの中のメタデータに格納されて良い。

以下のステップは、エージェントがｉ番目の反復で繰り返しループコードブロックをどのように再スポーニングできるかの一例を提供する。本例では、コードレジストリは、ハッシュテーブルである。これにより、ハッシュ値がテーブルの検索キーとして作用し、トランザクション上のメタデータに格納される。
１．エージェントは、コードレジストリ内のエントリに一致するコードブロックのハッシュを含むトランザクションについて、ブロックチェーンを監視する。
２．エージェントは、対応するハッシュ（Ｈ_１）を含むトランザクションを見付ける。
３．エージェントは、「メタデータ−ＣｏｄｅＨａｓｈ」を読み出し、Ｈ_１を得るためにＣｏｄｅＨａｓｈフィールドを得て、Ｈ_１を用いてコード（Ｃ_１）を読み出す。ＲＩＰＥＭＤ−１６０（ＳＨＡ２５６（Ｃ_１））がＨ_１に等しい場合、コードは変化しておらず、安全に次のステップに進める。
４．エージェントは、インデックスＩを格納する「メタデータ−ＣｏｄｅＨａｓｈ」を読み出し、ｉ番目の反復でコードを再スポーニングする。言い換えると、ループが、適切な反復で「リロード」される。
５．メタデータの発生元を検証するために、ユーザの署名がＰ２ＳＨコマンドに含まれる。
６．これらのデータがループのこの反復のために必要な場合、エージェントは、「メタデータ−ＯｕｔｐｕｔＨａｓｈ」及び「メタデータ−ＯｕｔｐｕｔＰｏｉｎｔｅｒ」を読み出し、前のステップのアウトプットを検索する。

留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する（comprising又はcomprises）」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する（comprises）」は「含む（includes）又は構成される（consists of）」を意味し、「有する（comprising）」は「含む（including）又は構成される（including of）」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、１つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組合せが有利に用いることが出来ないことを示すものではない。

取引は、取引を実施するために決定性有限オートマトン（Deterministic Finite Automaton：ＤＦＡ）を有して良い。決定性有限オートマトンは、コード化スキームを用いて定められて良い。決定性有限オートマトンは、
ｉ）望ましくはスクリプト言語を用いる、少なくとも１つのブロックチェーントランザクション、
ｉｉ）ブロックチェーンの状態を監視するよう構成された計算エージェント（これは、以下の「本発明と共に使用するための説明のための計算エージェント」と題される章に記載され得る）、及び／又は、
ｉｉｉ）デジタルウォレットに対する指示セット、を用いて実施されて良い。

＜取引モデル＞
取引モデルの基本要素は以下の通りである：
・コード化スキームは、任意の種類の取引の完全な記述を可能にする。スキームは、新しい構成であって良く、又はＸＢＲＬ、ＸＭＬ、ＪＳＯＮ（等）のような既存の設備を使用して良い。
・取引を実施するためのＤＦＡ（決定性有限オートマトン、Deterministic Finite Automaton）は、コード化スキームの中で完全に定義できる。これは、以下から構成される。
− パラメータのセット、これのパラメータを供給すべき場所、
− 状態定義のセット、
− 遷移のトリガ及び遷移中に従うルールを含む、状態間の遷移のセット、
− ルール定義テーブル。
・取引のこのインスタンスのための特定パラメータの定義。
・取引を安全に保管し保護するためのメカニズム。
・取引を、正式な法律の言語で人間に可読にする「ブラウザ」。
・コード化スキームをオラクルコード及び／又はビットコインスクリプトのようなスクリプトに変換する「コンパイラ」。

Claims (27)

1. 取引の可視性及び／又は実行を制御するコンピュータにより実施される方法であって、前記方法は、
   （ａ）コンピュータに基づくレポジトリ上に又はその中に取引を格納するステップと、
   （ｂ）ブロックチェーンにトランザクションをブロードキャストするステップであって、前記トランザクションは、
   ｉ）少なくとも１つの未使用アウトプット（ＵＴＸＯ）、及び、
   ｉｉ）前記取引の格納された場所を示す識別子を有するメタデータ、を有する、ステップと、
   （ｃ）前記取引を、
   前記取引に関連付けられた前のキーに関連するデータを用いて、新しいキーを生成し、
   前記新しいキー、前記取引の前記場所、前記取引のハッシュを有するスクリプトを生成し、
   前記スクリプトに通貨額を支払う、
   ことにより、更新する又はロールオンするステップと、
   を含む方法。
2. 前記トランザクションは、決定性ＲｅｄｅｅｍＳｃｒｉｐｔアドレスを更に有し、望ましくは、前記ＲｅｄｅｅｍＳｃｒｉｐｔアドレスはＰ２ＳＨ（pay−to−script−hash）アドレスである、請求項１に記載の方法。
3. 前記アウトプット（ＵＴＸＯ）を使用するために前記ブロックチェーンに更なるトランザクションをブロードキャストすることにより、前記取引を終了するステップ、を更に含む請求項２に記載の方法。
4. 前記更なるトランザクションは、
   前記アウトプット（ＵＴＸＯ）であるインプット、及び、
   署名と前記メタデータと公開鍵とを含むアンロックスクリプト、を有する、請求項１乃至３のいずれか一項に記載の方法。
5. 前記取引は、
   ｉ）少なくとも１つの条件、及び、
   ｉｉ）前記条件の評価に実行が依存する少なくとも１つのアクション、を定める、請求項１乃至４のいずれか一項に記載の方法。
6. 前記メタデータは、
   ｉ）前記取引が前記コンピュータに基づくレポジトリに格納された場所のアドレス又はアドレスの提示、及び／又は、
   ｉｉ）前記取引のハッシュ、を有する、請求項１乃至５のいずれか一項に記載の方法。
7. 前記未使用トランザクションＵＴＸＯが前記ブロックチェーンの未使用トランザクションアウトプットのリストの中にあるか否かを決定することにより、前記取引が終了しているか否かを調べるステップ、を含む請求項１乃至６のいずれか一項に記載の方法。
8. 前記取引は分散ハッシュテーブル（ＨＤＴ）に格納される、請求項１乃至７のいずれか一項に記載の方法。
9. 指定日及び／又は時間に前記アウトプットを使用する指示を有するトランザクションを前記ブロックチェーンにブロードキャストするステップであって、望ましくは前記指示はＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ指示である、ステップ、を含む請求項１乃至８のいずれか一項に記載の方法。
10. 前記取引の内容のうちの一部又は全部へのアクセスは、少なくとも１つの指定認定パーティに制限される、請求項１乃至９のいずれか一項に記載の方法。
11. 前記取引は、前記取引を実施する決定性有限オートマンを有する、請求項１乃至１０のいずれか一項に記載の方法。
12. 前記決定性有限オートマンは、コード化スキームを用いて定められる、請求項１１に記載の方法。
13. 前記決定性有限オートマンは、
    ｉ）望ましくはスクリプト言語を用いる少なくとも１つのブロックチェーントランザクション、
    ｉｉ）前記ブロックチェーンの状態を監視するよう構成された計算エージェント、及び／又は、
    ｉｉｉ）デジタルウォレットのための指示セット、
    を用いて実施される、請求項１１又は１２に記載の方法。
14. 取引の可視性及び／又は実行を制御するコンピュータにより実施される方法であって、前記方法は、
    （ａ）コンピュータに基づくレポジトリ上に又はその中に取引を格納するステップと、
    （ｂ）ブロックチェーンにトランザクションをブロードキャストするステップであって、前記トランザクションは、
    ｉ）少なくとも１つの未使用アウトプット（ＵＴＸＯ）、及び、
    ｉｉ）前記取引の格納された場所を示す識別子を有するメタデータ、を有する、ステップと、
    （ｃ）前記取引から導出されるサブ取引を生成するステップであって、前記サブ取引は、決定性アドレスに関連付けられ、
    ｉｉｉ）シードを用いて導出された新しい公開鍵を用いて、
    ｉｖ）前記取引への参照と共に前記レポジトリ上に又はその中に前記サブ取引を格納し、前記参照を含むスクリプトを有するトランザクションを前記ブロックチェーンにブロードキャストし、及び／又は、
    ｖ）既存の取引のメタデータに前記サブ取引への参照を追加する、
    ことにより生成される、ステップと、
    を含む方法。
15. 前記トランザクションは、決定性ＲｅｄｅｅｍＳｃｒｉｐｔアドレスを更に有し、望ましくは、前記ＲｅｄｅｅｍＳｃｒｉｐｔアドレスはＰ２ＳＨ（pay−to−script−hash）アドレスである、請求項１４に記載の方法。
16. 前記アウトプット（ＵＴＸＯ）を使用するために前記ブロックチェーンに更なるトランザクションをブロードキャストすることにより、前記取引を完了するステップ、を更に含む請求項１５に記載の方法。
17. 前記更なるトランザクションは、
    前記アウトプット（ＵＴＸＯ）であるインプット、及び、
    署名と前記メタデータと公開鍵とを含むアンロックスクリプト、を有する、請求項１４乃至１６のいずれか一項に記載の方法。
18. 前記取引は、
    ｉ）少なくとも１つの条件、及び、
    ｉｉ）前記条件の評価に実行が依存する少なくとも１つのアクション、を定める、請求項１４乃至１７のいずれか一項に記載の方法。
19. 前記メタデータは、
    ｉ）前記取引が前記コンピュータに基づくレポジトリに格納された場所のアドレス又はアドレスの提示、及び／又は、
    ｉｉ）前記取引のハッシュ、を有する、請求項１４乃至１８のいずれか一項に記載の方法。
20. 前記未使用アウトプットＵＴＸＯが前記ブロックチェーンの未使用トランザクションアウトプットのリストの中にあるか否かを決定することにより、前記取引が終了しているか否かを調べるステップ、を含む請求項１４乃至１９のいずれか一項に記載の方法。
21. 前記取引は分散ハッシュテーブル（ＨＤＴ）に格納される、請求項１４乃至２０のいずれか一項に記載の方法。
22. 指定日及び／又は時間に前記アウトプットを使用する指示を有するトランザクションを前記ブロックチェーンにブロードキャストするステップであって、望ましくは前記指示はＣｈｅｃｋＬｏｃｋＴｉｍｅＶｅｒｉｆｙ指示である、ステップ、を含む請求項１４乃至２１のいずれか一項に記載の方法。
23. 前記取引の内容のうちの一部又は全部へのアクセスは、少なくとも１つの指定認定パーティに制限される、請求項１４乃至２２のいずれか一項に記載の方法。
24. 前記取引は、前記取引を実施する決定性有限オートマンを有する、請求項１４乃至２３のいずれか一項に記載の方法。
25. 前記決定性有限オートマンは、コード化スキームを用いて定められる、請求項２４に記載の方法。
26. 前記決定性有限オートマンは、
    ｉ）望ましくはスクリプト言語を用いる少なくとも１つのブロックチェーントランザクション、
    ｉｉ）前記ブロックチェーンの状態を監視するよう構成された計算エージェント、及び／又は、
    ｉｉｉ）デジタルウォレットのための指示セット、
    を用いて実施される、請求項２４又は２５に記載の方法。
27. 請求項１乃至２６のいずれか一項に記載の方法を実行するよう構成されたシステム。

Images