JP2022508948A - プライバシーを守る検証およびコミットアーキテクチャ - Google Patents

プライバシーを守る検証およびコミットアーキテクチャ Download PDF

Info

Publication number
JP2022508948A
JP2022508948A JP2021547049A JP2021547049A JP2022508948A JP 2022508948 A JP2022508948 A JP 2022508948A JP 2021547049 A JP2021547049 A JP 2021547049A JP 2021547049 A JP2021547049 A JP 2021547049A JP 2022508948 A JP2022508948 A JP 2022508948A
Authority
JP
Japan
Prior art keywords
node
transaction
domain
nodes
confirmation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021547049A
Other languages
English (en)
Other versions
JPWO2020082078A5 (ja
Inventor
セレン・ゲアハート・ブライケルツ
ジェームズ・ベントン・リツィオス
アンドレアス・ロッホビーラー
オグニェン・マリック
マティアス・シュマルツ
ラトコ・ゴラン・ヴェプレク
シャウル・クフィル
ツェリン・シュレスタ
Original Assignee
デジタル・アセット・（スウィツァーランド）・ゲーエムベーハー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by デジタル・アセット・（スウィツァーランド）・ゲーエムベーハー filed Critical デジタル・アセット・（スウィツァーランド）・ゲーエムベーハー
Publication of JP2022508948A publication Critical patent/JP2022508948A/ja
Publication of JPWO2020082078A5 publication Critical patent/JPWO2020082078A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp

Abstract

参加者が複数いるプロセスをスケジューリングし、検証する方法(400)であって、参加者が複数いるプロセスの参加者に関連する提出ノード(210)によって、1つまたは複数の受信者ノード(120、122)に暗号によって保護されたメッセージ(140)を送信することによって、提案されるトランザクションを提出するステップ(420)であって、暗号によって保護されたメッセージ(140)が、少なくとも、外部ノード(130)によって読み取り可能な暗号化されていないサブメッセージ(142)、および少なくとも外部ノード(130)からプライバシーを守るための暗号によって保護されたサブメッセージ(144)を含む、ステップと、外部ノードによって、その他のトランザクションに対する提案されるトランザクションの順序を決定するステップ(410)と、受信者ノードの少なくとも一部によって、暗号によって保護されたメッセージを検証するステップと、受信者ノードの少なくとも一部から暗号によって保護されたメッセージの妥当性の確認を受信するステップ(440)と、確認条件を満たす受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、提案されるトランザクションを確認されたトランザクションとして確定するステップ(450)と、外部ノードによって決定された順序に従って、確認されたトランザクションを分散型台帳に書き込むステップ(460)とを含む、方法。

Description

本開示は、プライバシーを守る検証およびコミットアーキテクチャのための、複数のノードを含むコンピュータシステムに関する。本開示は、分散型台帳にトランザクションをコミットするために参加者が複数いるプロセスを検証する方法にも関する。
分散型コンピューティングにおいて、一貫性を保証する問題は、ステートマシンレプリケーション(state-machine replication)問題として知られている。ビザンチンフォールトトレラント性があるソリューションは、相互に信頼していない関係者(party)によってさえも、状態(すなわち、ワークフロー)の発展(evolution)の妥当性を保証しながら問題を解決し得る。
ビットコインおよびイーサリアムなどの暗号通貨システムは、(さらなる「許可不要(permissionless)」の要件がある)ステートマシンレプリケーション問題に対する少なくとも部分的なソリューションを有する可能性がある。しかし、そのような既存のソリューションは、多くの応用に適用不可能である。1つのそのような応用は、ワークフローの発展が、通常、影響を受ける参加者にのみ可視でなければならない、参加者が複数いるプロセスにおいてプライバシーを提供することである。この問題に対するソリューションは、トランザクションを検証し、同期し、分散型台帳にコミットする集中型のノードを利用することである。しかし、集中型のノードが信頼されていなければならず、それぞれのその他のノードがそれらのノードのワークフローの発展を集中型のノードに明らかにしなければならないので、この目的で集中型のノードを使用することは、一部の応用に適さない可能性がある。したがって、トランザクションを同期し、検証する目的で集中型のノードを使用することを避けるプライバシーを守るアーキテクチャのニーズが存在する。
本明細書に含められた文書、行為、材料、デバイス、物品などのいずれの検討も、添付の請求項の各々の優先日より前にそれが存在したのでこれらのもののいずれかまたはすべてが先行技術基準の一部を形成するかまたは本開示に関連する分野の技術常識であったと認めるものと解釈されるべきでない。
本明細書全体を通じて、語「含む(comprise)」、または「含む(comprises)」もしくは「含んでいる(comprising)」などの変化形は、記載の要素、完全体(integer)、もしくはステップ、または要素、完全体、もしくはステップのグループの包含を示唆するが、いかなるその他の要素、完全体、もしくはステップ、または要素、完全体、もしくはステップのグループの除外も示唆しないと理解されるものとする。
米国特許公開第2017/0316391号 WO 2017/189027 WO 2017/187394 米国特許出願第62/329,888号 オーストラリア特許第2019200933号 WO 2019/082142 AU 2017904367
参加者が複数いるプロセスをスケジューリングし、検証する方法が提供され、方法は、参加者が複数いるプロセスの参加者に関連する提出ノード(submitting node)によって、1つまたは複数の受信者ノードに暗号によって保護されたメッセージを送信することによって、提案されるトランザクションを提出するステップであって、暗号によって保護されたメッセージが、少なくとも、外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも外部ノードからプライバシーを守るための暗号によって保護されたサブメッセージを含む、ステップと、外部ノードによって、その他のトランザクションに対する提案されるトランザクションの順序を決定するステップと、受信者ノードの少なくとも一部によって、暗号によって保護されたメッセージを検証するステップと、受信者ノードの少なくとも一部から暗号によって保護されたメッセージの妥当性の確認(confirmation)を受信するステップと、確認条件を満たす受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、提案されるトランザクションを確認されたトランザクションとして確定するステップと、外部ノードによって決定された順序に従って、確認されたトランザクションを分散型台帳に書き込むステップとを含む。
一部の実施形態において、1つまたは複数の受信者ノードは、少なくとも第1の受信者ノードおよび第2の受信者ノードを含む可能性があり、暗号によって保護されたサブメッセージは、第1の受信者ノードによって読み取り可能であるが、第2の受信者ノードによって読み取り可能でない。
一部の実施形態において、第1の受信者ノードは、暗号によって保護されたサブメッセージを復号するための復号鍵にアクセスすることができる可能性があるが、第2の受信者ノードは、復号鍵にアクセスすることができない。
一部の実施形態において、暗号によって保護されたメッセージは、外部ノードに送信される可能性があり、外部ノードは、暗号によって保護されたメッセージを各受信者ノードに送信する。
一部の実施形態において、1つまたは複数の受信者ノードは、それらの1つまたは複数の受信者ノードのアイデンティティ(identity)をその他の受信者ノードから隠すために仮名性のある(pseudonymous)アドレスを使用する可能性がある。
一部の実施形態において、方法は、提出ノードと仮名性のあるアドレスとの間および受信者ノードと仮名性のあるアドレスとの間の関連付けを維持するアイデンティティマネージャをさらに使用する可能性がある。
一部の実施形態において、暗号によって保護されたメッセージの妥当性を決定することは、暗号化されていないサブメッセージに基づく可能性がある。
一部の実施形態において、暗号化されていないサブメッセージに基づいて、暗号によって保護されたメッセージの妥当性を決定することは、提案されるトランザクションのトランザクション時間が外部ノードによって与えられたタイムスタンプの期間内にあるかどうかを判定することを含む可能性がある。
一部の実施形態において、提案されるトランザクションのトランザクション時間は、タイムスタンプの範囲である可能性がある。
一部の実施形態において、暗号によって保護されたメッセージの妥当性を決定することは、暗号によって保護されたサブメッセージに基づく可能性がある。
一部の実施形態において、暗号によって保護されたサブメッセージに基づいて暗号によって保護されたメッセージの妥当性を決定することは、提案されるトランザクションが前のトランザクションと競合することを特定することを含む可能性がある。
一部の実施形態において、暗号によって保護されたサブメッセージに基づいて暗号によって保護されたメッセージの妥当性を決定することは、提案されるトランザクションが、形式が整っていると判定することを含む可能性がある。
一部の実施形態において、暗号によって保護されたサブメッセージに基づいて暗号によって保護されたメッセージの妥当性を決定することは、提案されるトランザクションが1組の準拠規則に準拠するかどうかを判定することを含む可能性がある。
一部の実施形態において、提案されるトランザクションが前のトランザクションと競合することを特定することは、提案されるトランザクションが分散型台帳に既に記録されたかどうかを検査することを含む可能性がある。
一部の実施形態において、暗号によって保護されたメッセージの妥当性を決定することは、暗号化されていないサブメッセージおよび暗号によって保護されたサブメッセージに基づく可能性がある。
一部の実施形態において、妥当性を決定することは、暗号化されていないサブメッセージが暗号によって保護されたサブメッセージと一貫性があるかどうかを判定することを含む可能性がある。
一部の実施形態において、確認条件は、以下、すなわち、参加者が複数いるプロセスの参加者に対応する各受信者ノードから確認を受信すること、割り当てられた時間期間内に指定された量の確認を受信すること、または受信者ノードの指定されたサブセットから確認を受信すること、または暗号学的証明器(cryptographic prover)またはトラステッドハードウェアなどの確かめることが可能なアテステーション(attestation)メカニズムから確認を受信することのうちの1つまたは複数である可能性がある。
一部の実施形態において、方法は、1つまたは複数の受信者ノードが受信者ノードに関する期待されるアクションに従って働かないかどうかを判定する裁定者ノード(referee node)をさらに使用する可能性がある。
一部の実施形態において、裁定者ノードは、以下、すなわち、提案されるトランザクションの形式が整っているかどうか、1つもしくは複数の受信者ノードによって提供された確認が1つもしくは複数のその他の確認と競合するかどうか、および提案されるトランザクションが容量の取り決めの枯渇を誤って示すかどうかのうちの1つまたは複数を判定する可能性がある。
一部の実施形態において、方法は、紛争(dispute)解決プロセスを実行するために裁定者ノードをさらに使用する可能性がある。
一部の実施形態において、提案されるトランザクションが形式が整っていると判定することは、以下、すなわち、提案されるトランザクションが準拠規則に準拠すること、提案されるトランザクションが1つもしくは複数の受信者ノードの必要とされるサブセットによって認可されること、および提案されるトランザクションがリソースの要件の正しい宣言を有することのうちの1つまたは複数を検査することを含む可能性がある。
一部の実施形態において、1つまたは複数の受信者ノードのうちの第1の受信者ノードは、紛争解決プロセスを開始するために裁定者ノードに提案されるトランザクションを転送する可能性がある。
一部の実施形態において、紛争解決プロセスは、提出ノードまたは1つもしくは複数の受信者ノードから決定された不正を働くノードに裁定者ノードが罰を科すことによって解決される可能性がある。
一部の実施形態において、罰は、以下、すなわち、不正を働くノードがトランザクションを提出する能力を取り除くこと、不正を働くノードに関連する提案されるトランザクションに、凍結されたものとしてフラグを立てること、裁定者ノードによって決定された、不正を働くノードに関するカスタムの罰、およびドメインの規則で定義された、不正を働くノードに関する罰のうちの1つまたは複数である可能性がある。
一部の実施形態において、裁定者ノードは、紛争解決プロセスの結果を提出ノードまたは受信者ノードのうちの1つもしくは複数に伝達する可能性がある。
一部の実施形態において、紛争解決プロセスは、ドメインの規則で定義される可能性がある。
一部の実施形態において、第1の受信者ノードに加えてその他の受信者ノードが、1つまたは複数のメッセージを紛争解決プロセスのための証拠として裁定者ノードに提供する可能性がある。
一部の実施形態において、プロセスを構成する複数のトランザクションに対応する複数のメッセージの順序を決定するステップは、暗号化されていないサブメッセージに基づく可能性がある。
一部の実施形態において、暗号化されていないサブメッセージは、暗号によって保護されたメッセージが外部ノードによって受信される時間に対応する物理的なタイムスタンプを含む可能性がある。
一部の実施形態において、その他のトランザクションに対する提案されるトランザクションの順序は、物理的なタイムスタンプに基づく可能性がある。
一部の実施形態において、提案されるトランザクションの順序は、提案されるトランザクションに割り振られた論理的なタイムスタンプに基づく可能性がある。
一部の実施形態において、論理的なタイムスタンプは、物理的なタイムスタンプの定義された時間期間内の時間に対応する可能性がある。
一部の実施形態において、暗号によって保護されたサブメッセージは、暗号化されたサブメッセージである可能性がある。
参加者が複数いるプロセスをスケジューリングし、検証する方法が提供され、方法は、参加者が複数いるプロセスの参加者に関連する提出ノードによって、1つまたは複数の受信者ノードに暗号によって保護されたメッセージを送信することによって、提案されるトランザクションを提出するステップであって、暗号によって保護されたメッセージが、少なくとも、外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも外部ノードからプライバシーを守るための暗号によって保護されたサブメッセージを含む、ステップと、外部ノードによって、その他のトランザクションに対する提案されるトランザクションの順序を決定するステップと、暗号化されていないサブメッセージに基づいて、参加者が複数いるプロセスの参加者に関連する1つまたは複数の受信者ノードを外部ノードによって決定するステップと、外部ノードによって少なくとも暗号によって保護されたサブメッセージを1つまたは複数の受信者ノードに送信するステップと、暗号によって保護されたサブメッセージの妥当性を1つまたは複数の受信者ノードによって決定するステップと、外部ノードによって1つまたは複数の受信者ノードから暗号によって保護されたサブメッセージの妥当性の確認を受信するステップと、確認を受信するべき1つまたは複数のノードを外部ノードによって決定するステップと、外部ノードによって確認を1つまたは複数のノードに送信するステップと、1つまたは複数の受信者ノードによって提供された確認が確認条件を満たすかどうかに基づいて、提出ノードによって提案されるトランザクションを確認されたトランザクションとして確定するステップと、外部ノードによって決定された順序に従って提出ノードによって確認されたトランザクションを分散型台帳に書き込むステップとを含む。
一部の実施形態において、方法は、1つまたは複数の受信者ノードによって提供された確認を仲介者ノード(mediator node)によって受信し、集約するステップをさらに含む可能性がある。
一部の実施形態において、方法は、以下、すなわち、1つまたは複数の確認の集約を記憶するステップ、1つまたは複数の確認の集約を別のノードに送信するステップ、および確認の集約に基づいて提案されるトランザクションを確認するステップのうちの1つまたは複数をさらに含む可能性がある。
実行されるときにノードまたは一連の関連するノードに上述の方法を実行させるプログラム命令を含む有形のコンピュータ可読記録媒体。
参加者が複数いるプロセスにおいてトランザクションまたは一連のトランザクションをスケジューリングし、検証する方法であって、少なくとも、参加者が複数いるプロセスの参加者に関連する1つまたは複数の受信者ノードに部分的に暗号化されたメッセージを送信することによって、提案されるトランザクションを提出するステップであって、部分的に暗号化されたメッセージが、少なくとも、外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも外部ノードからプライバシーを守るための暗号化されたサブメッセージを含む、ステップと、受信者ノードから部分的に暗号化されたメッセージの妥当性の確認を受信するステップと、確認条件を満たす受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、提案されるトランザクションを確認されたトランザクションとして確定するステップと、その他のトランザクションに対する確認されたトランザクションの順序を外部ノードから受信するステップと、外部ノードによって決定された順序に従って、確認されたトランザクションを台帳に書き込むステップとを含む、方法が提供される。
一部の実施形態において、1つまたは複数の受信者ノードは、少なくとも第1の受信者ノードおよび第2の受信者ノードを含む可能性があり、方法は、暗号化されたサブメッセージを第1の受信者ノードに送信するステップであって、暗号化されたサブメッセージが、第1の受信者ノードによって制御される復号鍵によって復号可能であるが、第2の受信者ノードによって制御される復号鍵によって復号可能でない、ステップをさらに含む可能性がある。
一部の実施形態において、暗号化されたサブメッセージは、第2の受信者ノードに送信されない可能性がある。
一部の実施形態において、方法は、各受信者ノードの仮名性のあるアドレスを決定するステップをさらに含む可能性があり、それぞれの仮名性のあるアドレスは、それぞれの受信者ノードのアイデンティティをその他の受信者ノードから隠すために使用される。
実行されるときに提出ノードに上述の方法を実行させるプログラム命令を含む有形のコンピュータ可読記録媒体が、提供される。
参加者が複数いるプロセスにおいて複数のトランザクションをスケジューリングし、検証する方法であって、
ノードまたは一連の関連するノードによって、
A. 参加者が複数いるプロセスを構成する複数のトランザクションに対応する複数のメッセージの順序を決定するステップと、
B. 参加者が複数いるプロセスの参加者に関連する提出ノードから、部分的に暗号化されたメッセージを含む提案されるトランザクションを受信するステップであって、部分的に暗号化されたメッセージが、少なくとも、ノードまたは一連の関連するノードによって読み取り可能な暗号化されていないサブメッセージを含む、ステップと、
C. 暗号化されていないサブメッセージに基づいて、参加者が複数いるプロセスの参加者に関連する受信者ノードを決定するステップと、
D. 部分的に暗号化されたメッセージを受信者ノードに送信するステップと、
E. 受信者ノードから部分的に暗号化されたメッセージの妥当性の確認を受信するステップと、
F. 確認を提出ノードに送信するステップとを含む、方法が提供される。
一部の実施形態において、方法は、受信者ノードの仮名性のあるアドレスを決定するステップをさらに含む可能性があり、仮名性のあるアドレスは、受信者ノードのアイデンティティをその他のノードから隠すために使用される。
方法の一部の実施形態において、分散型台帳は、提出ノード、外部ノード、および/または受信者ノードの間のメッセージを記録し、分散型台帳に書き込まれた確認されたトランザクションは、記録されたメッセージを含み、それによって、外部ノードによって決定された順序は、記録されたメッセージから立証されるかまたは導出され得る。
方法の一部の実施形態において、分散型台帳は、それぞれが台帳のそれぞれの部分的なコピーを保有する複数の異なる台帳を含み、分散型台帳は、複数の異なる台帳の部分的な記録から構築される。
一部の実施形態において、方法は、外部ノードに関連する第1のドメインから目標外部ノードに関連する目標ドメインへの参加者が複数いるプロセスの変更をさらに含む。方法は、第1のドメインの外部ノードによって開始者ノードから転送要求を受信するステップであって、転送要求が、目標ドメインおよび目標外部ノードを指定する、ステップと、第1のドメインの外部ノードによって、提案されるトランザクションをホストするための目標ドメインおよび目標外部ノードの妥当性を決定するステップと、目標ドメインが提案されるトランザクションを正当にホストし得ると決定することに基づいて、目標ノードにおいて提案されるトランザクションをスケジューリングし検証する認可を、開始者ノードに送信するステップとをさらに含み、提案されるトランザクションを順序付けるステップは、目標外部ノードによって実行される。
さらなる実施形態において、方法は、提出ノードおよび/または受信者ノードにおいて転送要求を受信するステップと、提出ノードおよび/または受信者ノードにおいて、提案されるトランザクションをホストするための目標ドメインおよび目標外部ノードの妥当性を決定するステップと、目標ドメインが提案されるトランザクションを正当にホストし得ると決定することに基づいて、目標ノードにおいて提案されるトランザクションをスケジューリングし検証する認可を、開始者ノードに送信するステップとを含む。
別の実施形態において、開始者ノードへの認可は、指定されたタイムアウト条件に関連付けられ、認可は、指定されたタイムアウト条件に基づいて有効および/または排他的である。
参加者が複数いるプロセスをスケジューリングし、検証する方法であって、参加者が複数いるプロセスが、第1の外部ノード、第1の受信者ノード、および参加者が複数いるプロセスの参加者に関連付けられる提出ノードに関連付けられる第1のドメイン、第2の外部ノード、第2の受信者ノード、および提出ノードまたは別個の中継ノードに関連付けられる第2のドメインを含み、提出ノードまたは中継ノードが、第1の外部ノードと第2のノードとの両方と通信し、方法が、提出ノードによって、第1のドメインのための第1の提案されるトランザクションおよび第2のドメインのための第2の提案されるトランザクションを決定し、第1の提案されるトランザクションおよび第2の提案されるトランザクションが、第1の受信者ノードおよび第2の受信者ノードを含む提案される参加者が複数いるトランザクションを共同で形成し、第1の提案されるトランザクションおよび第2の提案されるトランザクションの各々が、それぞれの受信者ノードへの暗号によって保護されたメッセージを含み、暗号によって保護されたメッセージが、少なくとも、それぞれのドメインの外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも外部ノードからプライバシーを守るための暗号によって保護されたサブメッセージを含む、ステップ、提出ノードおよび/または中継ノードによって、第1の提案されるトランザクションを第1の受信者ノードに提出し、第2の提案されるトランザクションを第2の受信者ノードに提出するステップ、第1の外部ノードによって第1の提案されるトランザクションに関する第1の順序を決定するステップを含む、方法も提供される。方法は、第2の外部ノードによって第2の提案されるトランザクションに関する第2の順序を決定するステップと、第1の受信者ノードおよび第2の受信者ノードによってそれぞれの暗号によって保護されたメッセージを検証するステップと、第1の受信者ノードおよび第2の受信者ノードから暗号によって保護されたメッセージの妥当性の確認を受信するステップと、確認条件を満たす第1の受信者ノードおよび第2の受信者ノードからの確認を受信することに基づいて、提案される参加者が複数いるトランザクションを確認された第1のトランザクションおよび確認された第2のトランザクションの組合せとして確定するステップと、第1の確認されたトランザクションを第1の順序に従って第1のドメインに関連する分散型台帳に書き込み、第2の確認されたトランザクションを第2の順序に従って第2のドメインに関連する分散型台帳に書き込むステップとをさらに含む。
方法のさらなる実施形態において、提出者ノードは、第1のドメインと第2のドメインとの間のメッセージを受信および送信するための中継者であり、方法は、提出ノードおよび/または中継ノードによって、暗号によって保護されたメッセージの妥当性の確認を第1の受信者ノードから第2のドメインの第2の外部ノードおよび/または第2の受信者ノードに送信するステップと、提出ノードおよび/または中継ノードによって、暗号によって保護されたメッセージの妥当性の確認を第2の受信者ノードから第1のドメインの第1の外部ノードおよび/または第1の受信者ノードに送信するステップとをさらに含む。
方法の別の実施形態において、提案される参加者が複数いるトランザクションを確定する認可は、指定されたタイミング条件に関連付けられ、認可は、指定されたタイミング条件に基づいて有効および/または排他的である。
方法の別の実施形態において、提案されるトランザクションは、複数のドメインにまたがる提案される参加者が複数いるトランザクションの一部であり、方法は、提案される参加者が複数いるトランザクションから、1つまたは複数の受信者ノードおよび外部ノードを含む第1のドメインに関する第1の提案されるトランザクション、ならびに少なくとも、1つまたは複数のその他の受信者ノードおよび別の外部ノードを含む別のドメインに関する別の提案されるトランザクションを決定するステップと、少なくとも、別のドメインの前記参加者が複数いるプロセスの参加者に関連する1つまたは複数のその他の受信者ノードに、別の部分的に暗号化されたメッセージを送信することによって別の提案されるトランザクションを提出するステップであって、別の部分的に暗号化されたメッセージが、少なくとも、別の外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも別の外部ノードからプライバシーを守るための暗号化されたサブメッセージを含む、ステップと、1つまたは複数のその他の受信者ノードから別の部分的に暗号化されたサブメッセージの妥当性の別の確認を受信するステップとをさらに含み、提案されるトランザクションを確定するステップは、確認条件を満たすその他の受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、別の提案されるトランザクションを別の確認されたトランザクションとして確定することをさらに含み、方法は、別のドメインにおけるその他のトランザクションに対する別の確認されたトランザクションの順序を別の外部ノードから受信するステップと、別の確認されたトランザクションを別の外部ノードによって決定された順序に従って台帳またはその他の台帳に書き込むステップとをさらに含む。
さらなる実施形態において、方法は、第1のドメインの受信者ノードから別のドメインのその他の受信者ノードに暗号によって保護されたメッセージの妥当性の確認を送信するステップと、別のドメインのその他の受信者ノードから第1のドメインの受信者ノードに暗号によって保護されたメッセージの妥当性の別の確認を送信するステップとをさらに含む。
さらなる実施形態において、提案されるトランザクションおよび別の提案されるトランザクションを確定する認可は、指定されたタイミング条件に関連付けられ、認可は、指定されたタイミング条件に基づいて有効および/または排他的である。
上述の方法のその他の実施形態において、暗号化されたサブメッセージは、提案されるトランザクションのすべての期待される確認を暗号学的に検証するための期待される確認データを含み、方法は、受信された1つまたは複数の確認の各々が期待される確認データと一致することを暗号学的に検証するための暗号関数を実行するステップをさらに含む。
方法のさらなる例において、期待される確認データは、公開鍵の形態であり、期待される確認は、公開鍵に対応する秘密鍵による電子署名を含む。
方法の一部の例において、提案されるトランザクションは、それぞれが少なくとも1つの受信者ノードを含む複数のサブトランザクションを含み、各サブトランザクションは、サブトランザクションの含まれる受信者ノードによって読み取り可能であるが、サブトランザクションに関与しない受信者ノードによって読み取り可能でない内密の情報を有する対応する暗号によって保護されたサブメッセージに関連付けられ、暗号によって保護されたサブメッセージは、提案されるトランザクションの少なくとも1つのその他のサブトランザクションの内密の情報を少なくとも部分的に表す確認を検証するための内密の情報検証データを含み、方法は、少なくとも1つのその他のサブトランザクションの確認が内密の情報検証データと一致することを検証するステップをさらに含む。
方法の一部のさらなる例において、サブトランザクションの確認は、少なくとも部分的に、サブトランザクションの内密の情報の暗号学的ハッシュを含む。
方法の一部の例において、提案されるトランザクションは、複数の部分木を有する木構造を有し、部分木は、複数のサブトランザクションのうちの1つまたは複数を含む。
方法の一部の例において、暗号によって保護されたサブメッセージは、提案されるトランザクションの複数のサブトランザクションの確認のうちのいずれか1つを暗号学的に検証するための内密の情報検証データを含む。
実行されるときにノードまたは一連の関連するノードに上述の方法を実行させるプログラム命令を含む有形のコンピュータ可読記録媒体が、提供される。
一部の実施形態において、台帳は、共有された台帳である可能性がある。
本開示の例が、下で図を参照して説明される。
複数のトランザクションを含む、参加者が複数いるプロセスをスケジューリングし、検証するための例示的なシステムの図である。 複数のトランザクションを含む、参加者が複数いるプロセスをスケジューリングし、検証するためのより複雑な例示的なシステムの図である。 仲介者ノードをともなう図2aの例の図である。 すべてのノードにサブメッセージを配信する例の図である。 一部のノードにサブメッセージを配信する例の図である。 例示的な提案されるトランザクションの図である。 参加者が複数いるプロセスをスケジューリングし、検証する例示的な方法の図である。 例示的なノードの図である。 移動元ドメインから移動先ドメインへのドメインの変更の例の概略図である。 移動元ドメインから移動先ドメインへのドメインの変更の別の例の図である。 2つのドメインにまたがるマルチドメイントランザクションの例の概略図である。 図8のマルチドメイントランザクションの様々な期限を示す図である。 単一のドメインにおいて実施され得る複数の参加者を含むトランザクションの別の例を示す図である。 図10の例示的なトランザクションの様々なエンティティのビュー(view)を示す図である。 図11aのビューのブラインディングされた(blinded)ビューを概念的に示す図である。 図10から図11bのトランザクションおよび方法の概略図である。 図10から図12のトランザクションおよび方法の状態遷移図である。 参加者A、参加者B、および銀行を含むトランザクションのビューを示す図である。 図14aのトランザクションにおいて銀行によって可視のビューを示す図である。 1人の参加者Pの詳細がない、仮想台帳に記録されるトランザクションに関するメッセージの図である。 参加者Aの詳細がない、仮想台帳に記録されるトランザクションに関するメッセージの図である。 参加者が複数いるプロセスの完全なトランザクションビューを示す図である。 図16aの第1のビューのコアを示す図である。 参加者が複数いるプロセスおよびトランザクションを表す完全なデータ構造を示す図である。 サブトランザクションのプライバシーを示す図17のトランザクションのサブビューの図である。 図17のトランザクションの完全な利害関係者ツリーの図である。 利害関係者の銀行に関してブラインディングされない利害関係者ツリーの図である。
本開示は、分散型システムにおいて同期を妥当性から分離することができるシステムに関する。同期は、分散型システムにおいて普通に見られる問題であり、通常、全順序(total-order)ブロードキャストまたはマルチキャストなどの何らかの形態の順序同意プリミティブによって解決される。妥当性の検査が受信者自体に移され得る、受信者ノードの概念に基づいて妥当性を保証する例示的なシステムが、本明細書において開示される。無数の利点のうちでもとりわけ、これは、すべてのデータを見て、処理する能力を有する集中型のコミッタノードの必要をなくす、またはすべてのデータを見て、処理する能力を一緒に有する多者コミッタノード(multi-party committer node)の必要をなくすことができ、それによって、システムにおける受信者ノードのプライバシーを向上させる。
システムにおいて、参加者は、トランザクションのそれらの参加者の部分的なビューに基づいてローカルの妥当性の検査を実行し、確認(たとえば、ピアツーピアの確認、またはシステムのコンポーネントもしくはノードを通じてルーティングされる確認)によってそれらの参加者のローカルの検査の結果をやりとりすることができる。一例において、関係者は、それらの関係者の部分的なビューに基づいてローカルの妥当性の検査を実行するタスクを参加者のユーザまたはその他のアクタ(actor)に委任することができる。一例において、参加者は、分散型台帳のワークフローの規則のそれらの参加者の制限されたビューに基づいてトランザクションレベルの妥当性の検査を実行するタスクを関係者のユーザまたはその他のアクタに委任することができる。
図1は、複数のトランザクションを含む、参加者が複数いるプロセスをスケジューリングし、検証するための例示的なシステム100を示す。この例においては、プロセス102、ノード間で通信するためのネットワーク104、提出ノード110、受信者ノード120、外部ノード130、および台帳160が存在する。任意で、(図1において破線によって示される)第2の受信者ノード122、およびアイデンティティマネージャ170が存在し得る。
この例において、プロセス102は、すべてのノードに共有され得る。プロセスは、複数の参加者を持つことが可能であり、参加者の各々は、ネットワーク内の少なくとも1つのノードに関連付けられ得る。最も単純な例においては、提出ノード110、受信者ノード120、および外部ノード130が存在し得る。外部ノード130は、複数の参加者を含むプロセス102を構成する1つまたは複数のトランザクションに対応する複数のメッセージの順序を決定する。外部ノード130は、外部ノードの論理的な順序付け機能を実装する複数の物理的なシステムから構成され得る。
提出ノード110は、提案されるトランザクション140を提出し得る。提案されるトランザクション140を提出することは、プロセスの参加者に関連する1つまたは複数の受信者ノードに暗号によって保護されたメッセージをネットワーク104を介して送信することを含むことが可能であり、暗号によって保護されたメッセージは、少なくとも、外部ノード130によって読み取り可能な暗号化されていないサブメッセージ142と、少なくとも外部ノード130からプライバシーを守るための暗号によって保護されたサブメッセージ144とを含み得る。一例において、暗号によって保護されたメッセージは、暗号化されていないサブメッセージ142および暗号化されたサブメッセージ144を含み得る部分的に暗号化されたメッセージであることが可能である。本明細書の残りの部分に関しては、単に便宜上、それぞれ、部分的に暗号化されメッセージおよび暗号化されたサブメッセージとして暗号によって保護されたメッセージおよびサブメッセージについて言及するが、暗号化以外のその他の暗号保護メカニズム(たとえば、データマスキング、意味的不明瞭化など)が、暗号によって保護されたメッセージまたはサブメッセージを符号化するかまたは認可されていないノードに分からないようにするために利用される可能性があることが理解される。この例における暗号化されたサブメッセージ144は、部分的に暗号化されたメッセージの提出されるペイロードと考えられ得る。一例においては、対称暗号化(たとえば、高度暗号化標準(AES))、非対称暗号化(たとえば、RSA、楕円曲線など)、または統合暗号化(integrated encryption)(たとえば、ECIES)が、部分的に暗号化されたメッセージを暗号化し、提案されるトランザクション140を提出する際に利用されることが可能であり、理解されるように、本明細書において開示されるすべてのトランザクションにおいて利用されることが可能である。
提出ノード110が提案されるトランザクション140を提出すると、受信者ノード120が、提案されるトランザクション140を受信し、部分的に暗号化されたメッセージの妥当性と、ひいては、提案されるトランザクション140の妥当性を判定し得る。一例において、そのような検証は、受信者ノード120が部分的に暗号化されたメッセージの暗号化されたサブメッセージ144を検証することを包含し得る。たとえば、特定の実施形態において、暗号化されたサブメッセージ144は、(たとえば、提出ノード110および受信者ノード120が復号鍵を含む一方、外部ノード130は復号鍵を持たないために)受信者ノード120および提出ノード110の内密の、外部ノード130によって読み取り可能でないデータ(たとえば、プログラム命令、情報など)を含み得る。
提案されるトランザクション140の妥当性が判定されると、受信者ノード120は、確認150と呼ばれるメッセージを送信することができ、確認150は、受信者ノード120からの部分的に暗号化されたメッセージの妥当性の確認であることが可能である。一例において、確認は、受信者ノード120が提案されるトランザクション140に即して暗号化されたサブメッセージ144を検証し、提案されるトランザクション140が正しく、妥当であると考えることを確認し得る。一部の例において、提案されるトランザクション140が検証される前に配列する(つまり、その他の提案されるトランザクションに対して提案されるトランザクション140を順序付ける)ステップが、有利であり得る。あらゆる参加者がトランザクションの同じシーケンス(またはシーケンスのスニペット)を受信し、検証し得るので、そのような参加者は、提案されるトランザクションの同じ順序または配列を暗黙的に検証することが可能であり、これは、不正を働くノードを特定することをより容易にすることができる。
この例において、提出ノード110は、受信者ノード120から確認を受信することに基づいて、提案されるトランザクション140を確認されたトランザクションとして受け付けることができ、そして、さらに、提案されるトランザクション140が確認条件を満たすと判定することができる。この例における確認条件は、確認150がプロセス102の参加者に対応するすべてのノードによって受信されることである可能性がある。この例においては1つの受信者120のみ存在するものとすると、1つの確認のみが、提案されるトランザクション140を確認するために提出ノード110によって受信される必要がある可能性がある。より複雑な例は、下で検討される。
この例において、提出ノード110および/または受信者ノード120は、外部ノード130によって決定された順序に従って台帳160に確認されたトランザクションを書き込むことができる。一例において、台帳は、すべてのノードに共有され得るデータストアであることが可能である。別の例において、台帳160は、各ノードが台帳の部分的なまたは完全なコピーを保有する分散型台帳であることが可能であり、提出ノード110および/または受信者ノード120は、台帳のそれらのノードのコピーを相応に更新することができる。さらにその他の例においては、台帳160は、概念的に存在するだけで、実際には存在しない分散型台帳であることが可能である。具体的には、台帳160は、ネットワークを介して提出され、「仮想」台帳に入力されるトランザクションに関してネットワークのノードの間で交換される複数のメッセージから構成される分散型「仮想」台帳であることが可能である。複数のメッセージに含まれるデータから、ネットワークのノードに関連する参加者は、任意の時点で「仮想」台帳の状態と、ひいては、その時点のネットワークのその他の参加者に対するそれらの参加者の義務および責任を計算することができるが、(たとえば、ビットコインまたはイーサリアムと同様の)ステートフルな分散型台帳は、実際には存在しない可能性がある。言い換えると、複数のメッセージのみがネットワークの様々なノードによって記憶される可能性があり、「仮想」台帳の状態は、それらのメッセージの内容に基づいて計算される可能性がある。
図2aおよび図2bは、より複雑な例示的システム200を示す。図1の例によく似て、プロセス202は、すべてのノードに共有され得る。プロセスは、複数の参加者を持つことが可能であり、参加者の各々は、ネットワーク内の1つまたは複数のノードに関連付けられ得る。しかし、図1の例と異なり、システムの参加者に関連する3つのノード、すなわち、提出ノード210と、2つの受信者ノード220、222が存在する。外部ノード230は、図1の例と同様に、複数の参加者を含むプロセス202を構成する複数のトランザクションに対応する複数のメッセージの順序を決定することができる。概して、プロセス202は、本開示のその他の例において説明されるように複数のトランザクションから構成されるが、プロセスは、単一のトランザクションを含む可能性があることを理解されたい。明瞭にするために、ネットワークが、図から削除されたが、ネットワークは、図1と同様に存在する可能性があることが留意される。
図1と同様に、提出ノード210は、提案されるトランザクション240を提出し得る。提案されるトランザクション240を提出することは、プロセス202の参加者に関連する2つの受信者ノード220、222に部分的に暗号化されたメッセージをネットワーク(図示せず)を介して送信することを含むことが可能であり、部分的に暗号化されたメッセージは、少なくとも、外部ノード230によって読み取り可能な暗号化されていないサブメッセージ242と、少なくとも外部ノード230からプライバシーを守るための暗号化されたサブメッセージ244とを含み得る。図2aの例においては、部分的に暗号化されたメッセージが、外部ノード230に送信されることが可能であり、外部ノードが、確認のために提案されるトランザクション240を受信する、受信者ノードのうちの1つまたは複数を決定することが可能である。そのとき、外部ノード230は、部分的に暗号化されたメッセージを適切な受信者ノード220、222に送信することができる。場合によっては、外部ノード230は、暗号化されたサブメッセージ244がそれぞれの受信者ノード220、222に関連するならば、提案されるトランザクション240全体の代わりに暗号化されたサブメッセージ244を受信者ノードに送信する可能性がある。別の例において、提案されるトランザクション240は、複数の部分的に暗号化されたメッセージ(それぞれの受信者のための対応する暗号化されていないサブメッセージ242および暗号化されたサブメッセージ244を有する)の組を含む可能性があり、それによって、サブメッセージ(たとえば、暗号化されたサブメッセージ244)が、分けられ、それぞれの受信者ノード220、222に配信され得る。これは、提案されるトランザクション240の一部分が認可された受信者ノードには可視であるが、別の認可されていない受信者ノードには可視でないことが可能であり、それによって、それらのそれぞれの部分に関して、認可されていない受信者ノードに可視であるべきでないトランザクションの部分のプライバシーを守る。
以上の例が、図2cに示され、図2cは、部分的に暗号化されたメッセージがサブメッセージ242から248に分けられ、暗号化されたサブメッセージ244、246、248がそれぞれの受信者ノード220、222、224にそれぞれ配信される、追加の受信者ノード224を用いる筋書きを示す。図2cの例において、暗号化されたサブメッセージ244は、第1の受信者ノード220によって読み取り可能であるが、第2の受信者ノード222によってまたは第3の受信者ノード224によって読み取り可能でなくてよい。つまり、たとえ各受信者ノード220、222、224がそれぞれの暗号化されたサブメッセージ244、246、248を受信するとしても、暗号化されたサブメッセージ244の内容は、第1の受信者ノード220によって読まれ、潜在的に検証され得るが、第2の受信者ノード222または第3の受信者ノード224によっては読み取り可能でなく、潜在的に検証され得ない。これは、一部のメッセージの内容が1つの受信者ノードの内密のものであり、したがって、別の受信者ノードと共有されるべきでない多くの例において起こる可能性がある。第1の、第2の、および第3の受信者ノード220、222、224以外のさらなるノードが、ネットワークの一部を形成する可能性があり、特定の暗号化されたサブメッセージ244は、送信され、暗号化されたサブメッセージ244を見る資格を与えられた受信者ノードの任意のサブセットによって読み取り可能であるが、暗号化されたサブメッセージ244を見る資格を与えられていない受信者ノードのいかなるサブセットにも送信されないかまたは読み取り可能でない場合がある。
図2cに示された例と同様の例が、図2dの例に示される。図2dの例において、暗号化されたサブメッセージ244は、第1の受信者ノード220によってのみ受信され、第2の受信者ノード222によってまたは第3の受信者ノード224によって受信されない可能性がある。つまり、この例において、外部ノード230は、暗号化されたサブメッセージ244が第2の受信者ノード222または第3の受信者ノード224に関連しないと判定する場合、暗号化されたサブメッセージ244を第2の受信者ノード222または第3の受信者ノード224に転送しない可能性がある。これは、たとえ第2の受信者ノード222がどうにかして復号鍵に不正にアクセスしたとしても、第2の受信者ノード222が外部ノード230から暗号化されたサブメッセージ244を受信しなかったであろうから、そのノードは、暗号化されたサブメッセージ244を復号することができない。同様に、第3の受信者ノード224は、外部ノード230から暗号化されたサブメッセージ244を受信しなかったであろうから、暗号化されたサブメッセージ244を復号することができない。同様に、たとえ外部ノード230が暗号化されたサブメッセージ244を第2の受信者ノード222または第3の受信者ノード224に誤って送信したとしても、第2の受信者ノード222または第3の受信者ノード224は、不正な行動をしない限り、通常、暗号化されたサブメッセージ244を復号するための復号鍵を持たない。したがって、本開示のシステムは、たとえ鍵または暗号アルゴリズムが破られた場合であっても、ノードの間でプライバシーを守って、提案されるトランザクションの一部を見る資格を与えられたノードのみがそのようにすることができることを保証し得る。
一例においては、暗号化されたサブメッセージを読むために、第1の受信者ノード220が、第1の受信者ノード220に与えられた暗号化されたサブメッセージ244を復号するための復号鍵にアクセスすることができる。この例において、第2の受信者ノード222は、図2cに示されたように暗号化されたサブメッセージ244を受信し得るが、その特定の暗号化されたサブメッセージ244のプライバシーを守るために第1の受信者ノード220にアドレス指定された暗号化されたサブメッセージ244を復号するための復号鍵にアクセスすることはできない。もちろん、暗号化されたサブメッセージ244を復号するための復号鍵へのアクセスは、特定の暗号化されたサブメッセージ244を読む資格を与えられるネットワーク内の任意の数の受信者ノードまたは受信者ノードの任意のサブセットにまで与えられ得る。
完全を期して、図2dの例においては、暗号化されたサブメッセージ246が第1のおよび第2の受信者ノード220および222に配信され、暗号化されたサブメッセージ248が第1の、第2の、および第3の受信者ノード220、222、および224に配信されることは注目に値する。そのとき、同様に、第1の受信者ノード220および第2の受信者ノード222は、暗号化されたサブメッセージ246を復号するための復号鍵にアクセスすることができる必要があり、第1の受信者ノード220、第2の受信者ノード224、および第3の受信者ノード226は、暗号化されたサブメッセージ246を復号するための復号鍵にアクセスすることができる必要がある。
提案されるトランザクション240の妥当性が各受信者ノード220、222によって判定されると、各受信者ノード220、222は、受信者ノード220、222からの部分的に暗号化されたメッセージの妥当性の確認であることが可能である、確認250、252と呼ばれるメッセージを送出することができる。この例においては、図1の例と異なり、各受信者ノード220、222からの確認が、外部ノード230に送信され得る。外部ノード230は、複数のノードのうちの1つである可能性がある提出ノード210を決定することができ、適切な提出ノード210に確認を送信することができる。図示されない一部の変更形態においては、確認が1つの受信者ノードから別のノードに直接送信されることが可能である。つまり、確認は、外部ノードまたは仲介者を介するのではなくピアツーピアで送信され得る。ピアツーピアの確認は、トランザクションを検証するための適切な規則を用いて外部または仲介者と併せて使用され得る。
一例において、提出ノード210は、複数の確認、すなわち、受信者ノード220からの第1の確認および受信者ノード222からの第2の確認を受信することに基づいて、提案されるトランザクション240を確認されたトランザクションとして受け付けることができる。この例における確認条件は、図1の例と同様に、全確認(full confirmation)であり、したがって、トランザクションが確認され得る。全確認の他のその他の代替的な確認条件は、本開示のその他の部分で検討される。
特に、この例において、システムの参加者に関連するノードの各々は、台帳260、262、264を有し、台帳のそのノードの部分的なまたは完全なコピーを相応に更新することができる。たとえば、提出ノード210は、台帳260を有することが可能であり、第1の受信者ノード220は、台帳262を有することが可能であり、第2の受信者ノード222は、台帳264を有することが可能である。そのとき、各ノードは、外部ノード230によって決定された順序に従ってそのノードのそれぞれの台帳260、262、264に確認されたトランザクションを書き込むことができる。一部の例において、台帳は、すべてのノードの間で共有され得るデータストアであり、その場合、たとえば、分離されたデータに基づくプライバシーモデルが、各参加者ノードに関連する各トランザクションのプライバシーを保つために必要とされる可能性がある。その他の例において、各台帳は、上述のように「仮想」台帳である。
任意で、図2aに示されたシステムの変更形態は、図2bに示されるように、仲介者280を使用することであることが可能である。この筋書きでは、受信者ノード220、222は、確認250、252を仲介者ノード280に送信することができ、仲介者ノード280は、確認を受信し、集約された結果を決定することができる。提出ノード210は、提案されるトランザクション240を仲介者280に提出する可能性もある。3つ以上の受信者ノードがある場合、仲介者ノード280を使用していくつの受信者ノードが提案されるトランザクション240を確認するかを数える方がより簡単である可能性がある。さらに、仲介者ノード280は、確認が特定の受信者ノード220、222によって送信されたかどうかについての信頼できる記録として働き得る。言い換えると、確認が仲介者ノード280を通じてルーティングされる可能性があるので、仲介者ノード280は、システムを使用して送信されたすべての確認の記録を持つことでき、受信者ノード220、222は、確認を送信したことまたはしなかったことを否定することができない。一部の例において、仲介者ノード280は、すべての確認を受信し、それらの確認を集約し、それらの確認を対応する参加者ノードに送信する(したがって、参加者ノードは、互いに直接インタラクションしない)。これは、参加者ノードが別のノードに影響を与えるトランザクションに関与するが、後の2つが直接的な関係を持たないときに少なくとも1つの参加者ノードが少なくともトランザクションの別のノードとのプライバシーを守る必要がある場合に有利である可能性がある。つまり、1つの参加者ノードが別の参加者ノードが同じトランザクションに関与することを知るべきでない場合。
アイデンティティマネージャ
アイデンティティマネージャノード170、270は、いくつかのサービス、たとえば、
a. メンバーシップ管理
b. 仮名(pseudonym)管理
を提供することができる。
メンバーシップ管理のために、アイデンティティマネージャノード170、270は、ノードが(図1、図2a、および図2bにおいて定義されたシステムなどの)システムに加わることおよびシステムを離れることを可能にし得る。図1および図2a～図2bに既に示されたシステムは、ドメインと呼ばれることも可能であり、単一のノードが、複数のドメインのメンバーである可能性がある。アイデンティティマネージャノード170、270は、ノードが公開鍵を登録し、取り消し、ローテーションすることを可能にし得る。アイデンティティマネージャノード170、270は、所与のノードによって表される参加者を知ることができる。アイデンティティマネージャノード170、270は、各ノードの信頼レベルを定義することもできる。たとえば、信頼レベルは、ドメイン(たとえば、決済システム)の運用者などに関して強く、または(たとえば、決済システムの参加者などに関して)弱い可能性がある。代替的に、信頼レベルは、各ノードに関して同じであるように選択される可能性がある。要するに、アイデンティティマネージャノード170、270は、ノードが特定のノードのアイデンティティに関連する公開鍵を登録し、取り消し、ローテーションすることを可能にすることができ、システムのその他のノードがドメイン内の特定のノードを特定することを可能にする。特定のノードのアイデンティティは、本開示の他の箇所で詳細に説明されるように、紛争解決などの場合に有用であり得る。
仮名管理のために、アイデンティティマネージャノード170、270は、ノードが仮名性のある鍵(たとえば、署名者のアイデンティティを明らかにすることなくメッセージに署名するための鍵)を生成することを可能にし得る。(外部ノードまたは裁定者ノードなどの)権限のある参加者がそれを要求する場合、アイデンティティマネージャノード170、270は、既に生成された仮名性のあるアイデンティティを明かすことができる。仮名性のあるアイデンティティは、ノードの真のアイデンティティを隠すが、同時に、その他のノードによって識別子として使用され得る仮名性のあるアドレスであることが可能である。
アイデンティティマネージャノード170、270を使用するとき、受信者ノード120、122、220、222は、提出ノード110、210のアイデンティティも、その他の受信者ノード120、122、220、222のアイデンティティも知る必要がない。一例において、受信者ノードは、その他の受信者ノードが同じプロセス202の参加者である場合にのみそれらのその他の受信者ノードのアイデンティティを知り、そうでない場合、受信者ノードは、その他の受信者ノード仮名のみを知る可能性がある。外部ノード130、230は、仮名性のあるアドレスを使用する受信者ノードへのメッセージ配信を許す可能性があり、アイデンティティマネージャノード170、270を使用して仮名の参加者のアイデンティティを解決することができる。
外部ノード
外部ノード130、230は、複数の参加者を含むプロセスを構成する複数のトランザクションに対応する複数のメッセージに順番を付けることができる。一例において、外部ノード130、230は、たとえば、外部ノード130、230によって与えられた一意のタイムスタンプによってメッセージが一意に配列される(ドメインに関する)大域的全順序マルチキャストを提供することができる。したがって、大域的順序付けは、タイムスタンプから導出され得る。しかし、一部の例において、複数のメッセージの順序は、タイムスタンプ以外の暗号化されていないサブメッセージの情報に少なくとも部分的に基づく可能性があることを理解されたい。その他の筋書きにおいては、別箇所で説明されるように、外部ノード130、230によって与えられるタイムスタンプは、物理的または論理的タイムスタンプであることが可能である。
一部の例においては、単一のトランザクションに順序を付けることが可能である。つまり、外部ノード130、230はメッセージが一意に配列される大域的全順序マルチキャストを提供することができるので、たとえその他のトランザクションがまだ存在しない場合でも順序が確立され得る。例として、第1の提案されるトランザクションは、外部ノードにまだ提出されていない任意のその他のトランザクションまたは提案されるトランザクションが後の時間のタイムスタンプを付けられる可能性があるようにタイムスタンプを付けられる可能性がある。したがって、この例において、第1の提案されるトランザクションは、プロセスのために存在する可能性があるすべてのトランザクションの大域的全順序の中で最初(つまり、時間的に最初)であり得る。
本明細書の例のうちの一部に示されるように、外部ノード130、230は、単一のメッセージを配信する代わりに、きめの細かいメッセージ配信を提供する可能性がある。つまり、サブメッセージ142、242、144、244のリストが、受信者ノード220、222に配信される可能性がある。すべてのサブメッセージは、それらのサブメッセージが含まれるメッセージ140、240と同じタイムスタンプを受信し得る。特に、各サブメッセージは、受信者ノードの異なる組を有する可能性があり、各受信者ノードは、元のメッセージ140、240から導出された順序でサブメッセージを受信することができる。
外部ノード130、230は、提出の証明も与える可能性がある。つまり、提出ノード110、210が、提案されるトランザクション140、240の提出または確認250、252のときに外部ノード130、230から証明を受信し得る。証明は、たとえば、確認が見つからない場合に使用される可能性がある、紛争の際の証拠として働き得る。提出の証明に対応して、ノードがトランザクションまたは確認を送信したことを否定することができないように、メッセージの否認防止のニーズがさらに存在する可能性がある。最後に、外部ノード130、230による配信の証明は、受信者ノードにメッセージの順序に関する証拠を与えることができる。
一部の例において、外部ノード130、230は、外部ノードが配信するあらゆるメッセージまたは一群のメッセージの真正性の暗号学的証明を提供し得る(問い合わせされた場合に提供することを求められ得る)。これらは、提出ノード(または仲介者ノード280などのその他のノード)に送信される暗号学的「レシート」として働き得る。
仲介者
仲介者ノード280は、図2bに示されるようにシステムの一部を形成し得る。仲介者ノード280を有するシステムにおいて、仲介者ノード280は、受信者ノードから確認を受信し、提案されるトランザクションの検証に関する合意があるかどうかを判定するために確認を集約する可能性がある。これは、場合によっては、仲介者ノード280がより広いネットワーク中で送信される確認の総量を減らすために使用され得ることを意味する。一例において、仲介者ノード280は、トランザクションが受け付けられた/確認されたと考えられるために仲介者ノード280が受信することを期待するべきすべての期待される確認を記載するメッセージを受信し得る。仲介者ノード280は、仲介者ノード280が受信する確認を、トランザクションが受け付けられる/確認されるべきであるかどうかを判定するために仲介者ノード280が期待する確認と比較することができる。
さらに、仲介者ノード280は、確認が送信されたかまたは受信されたかどうかについての紛争が存在する場合に使用されるノードであることができる。仲介者ノード280が受信者ノードからのすべての確認を集約し得るので、仲介者ノード280は、確認が特定のノードによって送信された、または確認が送信されるべきであったときに確認が送信されなかった、および確認がすべての関連する受信者ノードによって適切に受信されたという争う余地のない記録として働き得る。
確認を集約するとき、仲介者は、確認ポリシーを考慮に入れることができ、確認ポリシーは、提案されるトランザクションを検証し、確認することを求められるノードと、提案されるトランザクションを任意で検証し、確認し得るが、提案されるトランザクションが確認されるためにそのようにすることを求められない可能性があるノードとを決定し得る。つまり、一部の確認ポリシーにおいては、受信者ノードのサブセットが、確認によって応答することを求められる可能性がある。受信者ノードの残りのサブセットは、任意検証者から受信される確認が提案されるトランザクションの検証に関する合意を決定することの一部として集約され得るが、確認が提案されるトランザクションを確認し、その提案されるトランザクションを台帳に入力するために必要とされない可能性があるという点で任意検証者であり得る。また、仲介者ノードを使用して確認を集約することは、プロセスまたは提案されるトランザクションに関与するノードのアイデンティティを保護する効果を持ち得る。言い換えると、仲介者ノードは、特定の確認を提供するノードのアイデンティティまたは確認メッセージ自体さえも必ずしも共有せずに、確認を集約し、確認条件またはポリシーが満たされたかどうかを判定するプロキシとして働き得る。
より複雑な確認ポリシーが、存在する可能性もある。たとえば、少なくとも第1のノードから確認を受信することが必須であるが、両方のノードから確認を受信する必要はない複数のノードを有するシステムの確認ポリシーが存在する可能性がある。実施される可能性がある確認ポリシーの多くのさらなる変更形態が存在することを理解されたい。
一部の例において、確認ポリシーは、(たとえ残りの関係者の一部またはすべてがアクションを拒絶するとしても)トランザクションを承認する確認者の数(または組)に基づくアクションのための定足数を指定する可能性がある。その他の例においては、VIP確認ポリシーが、一部の参加者ノードに、それらの参加者ノードが1つもしくは複数のその他の利害関係者の代わりにアクションを検証することを可能にする、および/またはそれらの参加者ノードを必須の確認者にするVIPステータスを与える(VIPのさらなる詳細は別の見出しの下で検討される)。
確認ポリシーは、たとえば、暗号学的証明器(たとえば、zkSNARK、zkSTARK)またはトラステッド実行環境(たとえば、Intel SGX)によるアテステーションを通じた1つまたは複数のノードによるアテステーションに依拠する可能性がある。
場合によっては、提出ノードは、提案されるトランザクションを仲介者ノード280を介して提出する可能性があり、そのとき、仲介者ノード280は、受信者ノード220、222から確認を受信し、集約することができる。1つの仲介者ノードが存在するか、またはそれぞれが潜在的に異なる受信者ノードを有する複数の仲介者ノードが存在する可能性がある。さらに、必ずしもあらゆる受信者ノードが、仲介者ノードに関連付けられるとは限らない。場合によっては、たとえば、第1の受信者ノードが、通常通りに外部ノード、提出ノード、またはその他の受信者ノードに第1の受信者ノードの確認を伝達する可能性がある一方、受信者ノードのさらなるサブセットは、それらの受信者ノードの確認を仲介者ノードを介して伝達する可能性がある。その他の場合、ネットワーク全体がネットワーク内のノードによって送信または受信された確認に関して一貫性のあるビューを有することを保証するために、ネットワーク内のすべてのノードが仲介者ノードまたは複数の相互に接続された仲介者ノードを介して確認を提出することが必要とされ得る。
仲介者ノード280は、受信者ノードから受信された確認およびその他のメッセージを記憶する可能性がある。これは、監査を実行することを求められる場合に監査者が確認またはメッセージを取り出すことができるので監査能力をもたらす。ストレージAPIは、監査者が受信されたメッセージをストレージから取り出すことを可能にし得る。ストレージAPIは、特定のトランザクションまたは提案されるトランザクションに関して結果メッセージが送信されたかどうかを監査者に知らせることができる。
ドメインメッセージングAPIおよびプロパティ
ドメインメッセージングAPIは、そのドメイン内の各参加者ノードおよびシステムエンティティ(たとえば、提出ノード110、受信者ノード120など)に対して公開される。ドメインメッセージングAPIがメッセージを「Send」する単一のコマンドおよび3つのイベントタイプ、すなわち、「Receipt」、「Deliver」、および「Heartbeat」を有する非限定的な例が、以降で説明される。
・messageIdがメッセージ識別子であり、bがバッチ、つまり、0 <= i < nとしてmiがメッセージであり、recipientsiがmiの受信者のリストであるn個のタプル(mi , recipientsi)のリストであるコマンドSend(messageId, b, Sig(b, sksender ))。バッチbは、送信する参加者の秘密鍵sksenderによって署名されなければならない。sendコマンドは、(異なる受信者を有する)複数のメッセージが同じタイムスタンプの元で送信されることが可能であるようにメッセージをバッチで送信するために使用され得る。
・messageIdがメッセージ識別子であり、tsがタイムスタンプであり、senderがノードの識別子であり、bがバッチであるイベントReceipt(messageId, ts, proof(sender, messageId, ts, b))。receiptイベントは、受信者にそれらが提出したメッセージの暗号学的証拠を与える。proofは、署名を含む可能性がある。
・ctrが各受信者に関して単調に増加するカウンタであり、tsが順序を定義するタイムスタンプであり、b'がメッセージバッチであり、proofが受信者のアイデンティティを含む配信の暗号学的証明であるイベントDeliver(ctr, ts, b', proof(recipient, ctr, ts, b'))。直観的に、ノードは、そのノードにアドレス指定されたすべてのメッセージと、各メッセージのその他の受信者を知る(これはbがバッチであることにより可能である)。
・ctrが減少しないカウンタであり、tsがタイムスタンプであり、proofがハートビートの発信の暗号学的証明であるイベントHeartbeat(ctr, ts, proof(recipient, ctr, ts))。
一部の例においては、ノードのためのドメインメッセージングAPIが以下のプロパティのうちの1つもしくは複数または場合によってはすべてを有することが望ましい。
・確実な配信: すべてのメッセージが、最終的に、それらのメッセージのすべての受信者に配信される。Send(messageId, b, Sig(b, sksender ))が正しく機能するノードsenderによって呼び出される場合、Deliver(ctr, ts, b', proof(p, ctr, ts, b'))イベントが最終的に受信者の集合(つまり、recipientsiからのすべての要素の和)内の各ノードpにおいてトリガされるようなtsおよびctrが存在し、
b' = [ (m, recipients)∈b | p∈recipients ]
である。
・創作不可(no creation): ノードpにおいてトリガされるあらゆるDeliver(ctr, ts, b', proof(p, ctr, ts, b'))に関して、
b' = [ (m, recipients)∈b | p∈recipients ]
であるように、あるノードがあるmessageIdを用いてSend(messageId, b, Sig(b, sksender ))を既に呼び出した。
さらに、SubmitイベントへのDeliverイベントの誘発されるマッピングは、単射である(つまり、対応するSubmitイベントよりも多いDeliverイベントは存在しない)。このプロパティは、Sendコマンドのために必要とされる署名のおかげで検証され得ることに留意されたい。したがって、senderは、メッセージを送信したことを否定することができない。
・順序通りの配信: Deliver(ctr, ts,-,-)がノードにおいてトリガされる場合、以下のうちのちょうど1つだけが成り立つ。
○ctr = 0であり、このノードにおいてそれより前にDeliverまたはHeartbeatイベントがトリガされていない。
○ctrがctr' + 1に等しく、ctr'はすぐ前のDeliverまたはHeartbeatイベントのカウンタである。
さらに、tsは、いずれの以前のDeliverまたはHeartbeatイベントのtsよりも大きくなければならない。タイムスタンプの順序付けが、バッチ内の順序付けと一緒に大域的全順序を提供する。これは、メッセージがメッセージストリームに以前に遡って挿入され得ず、省略されたメッセージが受信者によって検出され得ることを暗号学的証明と一緒に保証する。
・同意: Deliver(ctr, ts, b, proof(p1, ctr, ts, b))およびDeliver(ctr', ts, b', proof(p2, ctr', ts, b'))がそれぞれノードp1およびp2においてトリガされる場合、
filter bothReceive b = filter bothReceive b'
であり、
bothReceive (m, recipients) = {p1, p2}⊆recipients
である。
・本物の配信証明: Deliver(ctr, ts, b, proof(p, ctr, ts, b))がノードpにおいて既にトリガされていない限り、何者もproof(p, ctr, ts, b)を生成し得ない。実際には、これは、証明のための署名を使用することによって実現される。
・提出の証明: Send(messageId, b, Sig(b, sksender ))がノードsenderによって呼び出され、senderがクラッシュしない場合、Receipt(messageId, ts, proof(sender, messageId, ts, b))が最終的にsenderにおいてトリガされるようなtsが存在する。タイムスタンプtsは、Sendに対応するDeliverイベントに関するものと同じタイムスタンプでなければならない。
・因果関係: Send(messageId, b,-)が正しく機能するノードsenderによって呼び出される場合、レシートReceipt(messageId, ts, _)のタイムスタンプtsが、senderノードにおいてトリガされたいずれの以前のDeliverまたはHeartbeatイベントのタイムスタンプよりも真に大きくなければならない。
・規則的ハートビート: 規則的な間隔で、DeliverイベントかまたはHeartbeatイベントかのどちらかが、各参加者110、120においてトリガされる。
・順序通りのハートビート: Heartbeat(ctr, ts, proof(ctr, ts))イベントが参加者においてトリガされるときにはいつも、以下のうちのちょうど1つだけが成り立つ。
○ctr = 0であり、この参加者においてそれより前にDeliverまたはHeartbeatイベントがトリガされていない。
○ctrがctr' + 1に等しく、ctr'はすぐ前のHeartbeatまたはDeliverイベントのカウンタである。
さらに、tsは、いずれの以前のDeliverまたはHeartbeatイベントのtsよりも大きくなければならない。ハートビートイベントにおいてカウンタを増やすことは、あらゆるカウンタがちょうど1つのタイムスタンプにマッピングされることを保証する。
提案されるトランザクション
提出ノード110は、提案されるトランザクションを提出することによってトランザクションを提出し得る。概して、トランザクションプロトコルは、提出ノードがアクション/トランザクションについて知らされる必要がある関係者(つまり、宣言された利害関係者)を指定することを必要とする。提案されるトランザクションは、その他の受信者ノードにアドレス指定され得る(提案されるトランザクションは、容量モニタ(capacity monitor)、手数料またはリソース会計ユニット(fee or resource accounting unit)、外部ノード、仲介者などのシステムのその他の部分をアドレス指定する可能性もある)。提案されるトランザクション内の情報は、暗号化されていないサブメッセージおよび暗号化されたサブメッセージを含み得る。暗号化されたサブメッセージは、トランザクションの利害関係者(たとえば、提案されるトランザクションによって影響を受ける受信者ノード)にトランザクションを示す実際のペイロードを暗号化された形態で含み得る。
一部の例において、トランザクションプロトコルは、提出ノード110が提出ノードの情報を明記することを要求する。これは、提出ノード110がトランザクションおよび/または提案されるトランザクションの一部に署名することを要求することを含む可能性がある。一部の例において、これは、トランザクションのあらゆる最上位のアクションのために提出ノードの署名を必要とする可能性がある。その他の例において、これは、提出ノード110が署名することおよび影響を受ける利害関係者に署名を転送することを含む。
図3は、提案されるトランザクション302の例300を示す。例においては、参加者A 330が、参加者P(ペンキ屋)340に参加者Aの家を塗装してもらいたく、銀行342からの参加者Aが保有するIOUを使用してこれの支払いをしたい。参加者Aは、PaintOfferプロセス302によって参加者Pに申し出をする。
この例の文脈で、システムは、いくつかのアクションを実行する。第1は、提案されるトランザクションを定義する契約を生成する(および定義を台帳に記録する)アクションである。第2の種類のアクションは、トランザクションに複数のアクションを含み得る契約に関するアクションを遂行することである。たとえば、参加者による契約の受け付けは、(それら自体でアクションと考えられ得る)いくつかのサブアクション310をもたらす最上位のアクションである。これは、たとえば、銀行との参加者AのIOUからの値の転送を遂行することを含むことが可能であり、別のアクションが、参加者Pの利益に関する新しいIOUを生成することを含む。システムの観点から見て、そのようなアクションは、(i)そのアクションに関するトランザクションプロトコルによって承認されなければならず、(ii)基礎となるシステムモデルに準拠する--したがって、アクションは、台帳に有効に記録され得る。
トランザクションのルート(root)において、参加者P 340は、塗装の申し出に関するその参加者Pの選択を遂行し、これが、今度は、参加者A 330にIOUに関するその参加者Aの転送の選択を遂行させる(310)ことができ、同じ銀行342によって裏付けられた、参加者Pの利益のために新しいIOU 312を生成する。同時に、同意が生成され、それによって、参加者Pが参加者Aの家を塗装することに同意する(320)。本開示の文脈で、選択を遂行することは、ノードが実行する資格を与えられるスマートコントラクトに関するコードセグメントをノードが実行することを意味し得る。したがって、たとえば、上記の例において、参加者P 340は、塗装の申し出の参加者Pの受け付けを記録するPaintOfferスマートコントラクト内のコードセグメントを実行することによって塗装の申し出を受け付けるその参加者Pの選択を遂行することができる。本開示のシステムによって使用可能であり得る選択および/またはスマートコントラクトの遂行に関するさらなる詳細は、米国特許公開第2017/0316391号、WO 2017/189027、WO 2017/187394(これらのすべては、米国特許出願第62/329,888号からの優先権を主張する)、およびオーストラリア特許第2019200933号、WO 2019/082142(これらの両方は、AU 2017904367からの優先権を主張する)に見つけることが可能であり、これらの各々は、参照によりその全体が本明細書に組み込まれる。
それぞれのノード330、340、342は、ノードが利害関係者である契約に影響を与えるトランザクションの部分のみを知る必要がある可能性がある。トランザクション全体がPaintOfferの遂行の結果得られるので、そのトランザクションの利害関係者(参加者Aおよび参加者P)は、トランザクション全体を知る必要がある可能性がある。逆に、銀行および参加者Aは、IOUの転送310についてのみ知る必要がある可能性があり、参加者Pは、生成されたIOU 312についてのみ知る必要がある可能性がある。これは、図3に示されるように、トランザクションの異なる部分の分解につながり得る。
完全性に関しては、提案されるトランザクションがそのトランザクションの利害関係者のすべてに送信されたならば十分である可能性がある。しかし、これは、プライバシーのためには不十分である。幸いなことに、必ずしもすべての利害関係者が、トランザクション全体の完全な可視性を必要とするとは限らず、それらの利害関係者のビューは、完全性および関係者の間の同期を保証するのに十分な情報を開示しさえすればよい。
図3のそれぞれの実線の長方形は、トランザクションのその部分に関するプライバシーの範囲を表す(関連する関係者がイタリックおよび下線で示される)。PaintAgree 320に関して別個の実線の長方形は存在せず、参加者AおよびPがPaintOfferの遂行について既に知っているとき、これは暗黙的に推定され得るので、参加者AおよびPは、PaintAgree 320の生成について知る必要がないことに留意されたい。
しかし、新たに生成されるIOU 312に関しては状況が異なり得る。銀行342は、長方形302の転送のコンテキストについて何も知るべきでない。特に、銀行342は、参加者P 340がトランザクションのその他の契約のいずれかの参加者であったと想定し得ず、知るべきでない。これが、たとえ銀行342と参加者P 340との両方が外側の長方形310を知ることによってその実線の長方形312の内容を少なくとも部分的に既に知っているとしても、銀行342と参加者P 340との間で共有される別個の実線の長方形312が存在する理由である。銀行342は、その他の長方形302または320が何であるか(つまり、Aが何の支払いをしているのか)またはその利害関係者が誰であるのかを知っているべきでない。
トランザクション
当業者は、本開示において使用されるとき、トランザクションがツリー状の構造を有する可能性があることを認めるであろう。トランザクションは、利害関係者および/またはオブザーバ(observer)を有する可能性があり、それに応じて、異なる利害関係者に可視であるこのツリー状の構造の一部(たとえば、部分木)が、変わる可能性がある。それらの物理的転送記憶形態の中で、これらのトランザクションの部分木は、サブビューと呼ばれる。一例において、各受信者ノード120、122、220、222は、その受信者ノードが見る資格を与えられるトランザクションの部分のみを、意味的にはトランザクションの部分木のサブセットとしておよび物理的には転送されたトランザクションメッセージのサブビューのサブセットとして取得する。
(トランザクション302として)図3に示されたようなトランザクションは、アトミック性を持ち得る。言い換えると、トランザクションは、1つのまとまりとして完了または失敗し得る。関係者が概してトランザクションの一部分のみの可視性を持ち得るので、参加者は、それ自身でトランザクションの妥当性または受け付けを判断することができない可能性がある。さらに、一例において、この判定は、トランザクションの妥当性が委譲される可能性があることが意図される方法が原因で、トランザクション全体を見る参加者によってさえ行われ得ない。たとえば、参加者P 340のノードは上のトランザクション全体を見ることができるが、参加者P 340のノードは銀行342が参加者A 330のノードに発行したIOU 310の参加者ではない。トランザクションの妥当性または受け付けを評価するために、参加者P 340のノードは、銀行342からの確認を必要とする可能性がある。
暗号化されていないサブメッセージ
図2aおよび図2bの240などの提案されるトランザクションは、暗号化されていないサブメッセージ242を含み得る。暗号化されていないサブメッセージは、公的に利用可能であるまたはトランザクションプロセスのすべての参加者が利用可能である提案されるトランザクション240についての情報を含むことが可能であり、概して、参加者のうちのいずれかの内密の情報を含まない可能性がある。たとえば、暗号化されていないサブメッセージは、トランザクション時間を含むことが可能であるか、または台帳の利害関係者の間で同意された(暗黙的なもしくは明示的な、おそらくは同時に存在する)物理的-時間的規則のブランチ(branch)バージョン(たとえば、どの容量もしくはシャーディングモデルが使用され得るか)の選択を含む可能性がある。概して、そのような情報は、トランザクションについての公的に利用可能な情報であることが可能である。
一部の例において、外部ノードは、タイムスタンプを提供することによって暗号化されていないサブメッセージ内のトランザクション時間を提供する。その他の例において、提出ノードは、提出ノードによって与えられたタイムスタンプに基づいてトランザクション時間を提案する可能性がある。トランザクション時間は、単に、外部ノード230が提案されるトランザクション240を受信した時間のタイムスタンプまたはデジタル記録である可能性がある。タイムスタンプは、トランザクションが外部ノードに同時に送信された場合でさえもトランザクションを順序付けるのを支援し得る日付および時刻、世界時(universal time)、または秒よりも細かい精度の時間の任意の尺度を与えることができる。
一例において、タイムスタンプは、外部ノード230が提案されるトランザクション240を受信したときを示す物理的なタイムスタンプではない可能性があり、論理的なタイムスタンプである可能性がある。論理的なタイムスタンプは、外部ノード230が提案されるトランザクション240を受信した物理的なタイムスタンプと何らかの論理的時間オフセットとの組合せであることが可能である。たとえば、論理的なタイムスタンプは、外部ノード230が提案されるトランザクション240を受信した時間を示す物理的なタイムスタンプと何らかの論理的時間オフセットとの組合せであることが可能であり、それによって、物理的なタイムスタンプよりも遅い論理的なタイムスタンプを作る。一例において、論理的時間オフセットは、提案されるトランザクション240を提出する提出ノード210によって与えられ得る。したがって、外部ノード230によって与えられた物理的なタイムスタンプと提出ノード210によって与えられた論理的時間オフセットとの連結が、場合によっては、論理的なタイムスタンプを形成し得る。その他の場合、外部ノード230またはネットワーク内の別のノードが、論理的時間オフセットを与え得る。
提出ノード210が論理的時間オフセットを提供することを可能にすることは、提出ノード210が、受信者ノード220、222が提案されるトランザクション240に関する確認を送信しなければならない確認応答期限を制御すること、および/またはその他のトランザクションに対する提案されるトランザクション240の順序付けをいくらか制御することをある程度可能にする可能性がある。たとえば、一例において、本開示のシステムは、提案されるトランザクション240が確認され、台帳に入力されるために関連する受信者ノード220、222が提案されるトランザクション240の確認を送信しなければならない確認応答期限を与え得る。確認応答期限は、論理的なタイムスタンプを参照して計算され得る。たとえば、確認応答期限は、提案されるトランザクション240の論理的なタイムスタンプに何らかの予め設定された時間期間を足すことによって計算される可能性がある。提出ノード210が論理的時間オフセットを与えることを許すことによって、システムは、提出ノード210が提案されるトランザクション240の論理的なタイムスタンプをある程度設定することを可能にすることができ、その論理的なタイムスタンプが、確認応答期限に影響を与え得る。単に例として、提出ノード210は、したがって、関連する受信者ノード220、222が確認応答期限を満たすことができ、適切な期限内に確認を送信することに失敗し得ないように論理的時間オフセットを変更することによってその確認応答期限を調整することができる。たとえば、受信者ノード220、222が特定の提案されるトランザクション240を確認するために大量の時間を必要とする可能性があると提出ノード210が判定する場合、提出ノード210は、外部ノード230によって与えられた物理的なタイムスタンプよりもいくらか後の提案されるトランザクション240の論理的なタイムスタンプを設定するためにたっぷりした論理的時間オフセットを与えることができる。逆の例もまたあり得る。
さらに、論理的なタイムスタンプは、一例において、その他のトランザクションに対する提案されるトランザクション240の順序付けに影響を与え得る提案されるトランザクション240に関する最終的なトランザクション時間として働き得る。言い換えると、提案されるトランザクション240を含むトランザクションの大域的全順序が、すべてのトランザクションの論理的なタイムスタンプを調べ、論理的なタイムスタンプを使用してそのようなトランザクションを時間的に順序付けることによって決定され得る。したがって、論理的時間オフセットを与えることによって、提出ノード210は、その他のトランザクションに対する提案されるトランザクション240の順序付けを、妥当な限界の範囲内である程度決定することがやはり可能である。特に、提出ノード210が提案されるトランザクション240の優先度に懸念を持っている場合、提出ノード210は、論理的時間オフセットを比較的短く設定することができ、それによって、提案されるトランザクション240が最良の論理的なタイムスタンプを受け取り、トランザクションの大域的全順序の中で優先される可能性を持つことを保証する。
場合によっては、提案されるトランザクション240を含むトランザクションの順序を変えるトランザクション時間が、与えられ得る。そのような並べ替えは、並べ替えがトランザクションの論理的なタイムスタンプに基づき得るので本明細書においては論理的な並べ替えと呼ばれることがある。論理的な並べ替えによって、提案されるトランザクション240は、特定の例においては、上で説明されたように、外部ノード230による物理的なタイムスタンプおよび論理的時間オフセットに基づく論理的なタイムスタンプを与えられる可能性がある。場合によっては、論理的時間オフセットは、物理的なタイムスタンプと論理的なタイムスタンプとの間の差とみなされ得る。論理的時間オフセットは、その論理的時間オフセットが以下の考慮事項に照らして大きすぎないまたは小さすぎないように選択され得る。論理的時間オフセットが大きい場合、提案されるトランザクション240は、先行する(front-running)傾向がある可能性がある。つまり、単に例として、トランザクションtx1が提出され、(たとえば、提出ノード210によってある程度決められた)論理的なタイムスタンプを受け取った後、ネットワークの別の参加者ノードが、(たとえば、そのような参加者ノードによって与えられた論理的時間オフセットが原因で)より前の論理的なタイムスタンプを受け取る競合する提案されるトランザクションtx2を後で提出する可能性がある。後で提案されるトランザクションtx2が確認され、台帳に入力される場合、tx1は、たとえtx1がその物理的なタイムスタンプに従って最初に来たとしても、tx2と競合するので拒否される可能性がある。したがって、実際、提出ノードは、別の競合するトランザクションが「列に割り込む」ことなく提出ノードの提案されるトランザクションが確認され、台帳に入力されるように、論理的時間オフセットを、その他のノードのリソースの限界およびトランザクションを検証するために必要とされる時間を考慮してできるだけ短く設定することがそれらの提出ノードにとって有利であることに気付く可能性がある。
代替的に、後で提案されるトランザクションtx2がより前のトランザクションtx1の確認応答期限の後に拒否される場合、tx1に関する確認応答期限が既に過ぎているのでtx1も拒否される可能性がある。この筋書きにおいては、結局、両方のトランザクションが拒否される。逆に、論理的時間オフセットが小さい場合、受信者ノードは、単に計算またはネットワークの制約が原因で確認応答期限までに確認を送信することができない可能性がある。その結果、トランザクションは、論理的時間オフセットがあまりにも小さく設定される場合、拒否される可能性がある。
さらに別の筋書きにおいては、提案されるトランザクションtx1が、提出ノードによって提出され、論理的なタイムスタンプを割り振られ、関連する受信者ノードによって確認され、台帳に入力される可能性がある。後続の提案されるトランザクションtx2が、同じかまたは別の提出ノードによって提出され、tx1の論理的なタイムスタンプよりも前の論理的なタイムスタンプを割り振られ、関連する受信者ノードによって確認され、台帳に入力される可能性がある。tx2のトランザクション時間(たとえば、論理的なタイムスタンプ)がtx1のトランザクション時間(たとえば、論理的なタイムスタンプ)よりも前であるので、たとえtx1が最初に提出されたとしても、トランザクションの大域的全順序内でtx1よりもtx2を優先する論理的な並べ替えが、行われ得る。
暗号化
暗号化されたサブメッセージは、対称暗号化、または非対称暗号化、またはそれら両方によって暗号化される可能性がある。非対称暗号化は、データを暗号化および復号するために複数の鍵、公開鍵および秘密鍵を利用する。任意の好適な暗号化方法が使用される可能性があり、たとえば、RSAまたは楕円曲線暗号が使用される可能性がある。
暗号化のために、以下の演算が利用可能である可能性がある。
・(たとえば、公開鍵暗号化と呼ばれる)任意のメッセージmを所与の公開鍵pkによって暗号化する決定性の非対称暗号化方式Epub(pk, m)。
・任意のメッセージmを所与の対称鍵symkによって暗号化する対称的な認証された暗号化方式Esym(symk, m)。認証は、外部ノード230による潜在的な修正から保護することができる(対称暗号化と呼ばれる)。
・所与のトークンを用いて所与の参加者の仮名を導出する仮名導出方式pseudonym(participant, token)。
暗号化されたサブメッセージ
暗号化されたサブメッセージ144、244を準備するために、提出ノード110、210は、まず、(一例においてはアイデンティティマネージャ170から)秘密のトークンtokaを取得し、各アクション「a」のために新しいナンスkeyaを準備することができる。stkhaは、アクションaの利害関係者を表すものとする。subsaは、aを順序通りにたどることによって得られる(a自体を含む)aのサブビューのリストである。
一例において、アクションaに関する暗号化されたサブメッセージは、そのとき以下のように導出され得る。
1. 暗号化されたアクションは、Esym (keya, (bound(a), desc(a)))であり、boundは、影響を受ける利害関係者が自身を縛る任意の予め指定された共有された物理的-時間的制約を表す関数である。たとえば、boundは、(リソースモデルによって与えられる)アクションaのリソース消費を推定することができ、desc(a)は、aを説明する何らかの完全な手段(たとえば、明かされた入力をともなうモデル表現またはeval trace)であることが可能である。
2. 鍵は、aのサブビューに関連付けられた鍵のリストであるものとする([ key a' | a' <- subsa]、「サブビューを復号する鍵のリスト」として読まれる)。そのとき、鍵は、トランザクションの利害関係者毎のエントリを有する鍵リストの公開暗号化のリストとしてラッピングされた鍵の形態で記憶および転送に関して保護される([Epub (pk(stkh), keys) | stkh <- stkha ])。言い換えると、暗号化されたサブメッセージのこの部分は、たとえば、トランザクションの各利害関係者に対応する公開鍵の暗号化されたリストであることが可能であり、対応する秘密鍵が関連する利害関係者に知られている(たとえば、利害関係者が暗号化されたサブメッセージを復号することを許す)。
3. アクションの期待される確認者の仮名を生成するために使用されるトークンは、[toka' | a' <- subsa]である。言い換えると、暗号化されたサブメッセージのこの部分は、たとえば、トークンのリストを含むことが可能であり、そのトークンのリストから、特定のアクションを確認する必要がある期待される確認者の各々の仮名(たとえば、16進アドレス)が導出され得る。そのような情報は、たとえば、ネットワーク内のノード(たとえば、外部ノード230)がネットワーク内のどのノードが特定のアクションを確認する必要があるかを決定することを可能にするために有用であり得る。
提案されるトランザクションのペイロードを含む暗号化されたサブメッセージは、したがって、(ここではHaskellで書かれるが、多くのその他の言語で実装可能な)データ型によって記述され得る。
type RequestPayload = {
metadata :: RequestMetadata
, stakeholders :: [Pseudonym]
, descriptions :: [(EncryptedActionDescription, [Participant])]
}
期待される確認
それぞれの提案されるトランザクション(たとえば、図2a～図2bの提案されるトランザクション240)に関して、提案されるトランザクションを受け付ける/確認するために必要とされる可能性がある確認が存在し、ノードがトランザクションに関して受信することを期待すべき確認の決定をそのノードが行うと仮定する。期待される確認は、提案されるトランザクションが受け付けられ/確認され、台帳に入力されるための、プロセスの参加者ノードからの必要な肯定的応答であることが可能である。一部の実施形態において、各ノードは、(たとえば、その特定のノードのトランザクションの範囲のビューによって)どのノードが確認を与えることを求められるのかを決定し得る。つまり、ノード210、220、222は、提案されるトランザクション240を受け付けるまたは確認するために受信者ノード220、222のうちのどれが確認を与えることを要求されるかを評価することができる。たとえば、全確認の確認条件を有する提案されるトランザクション240を提出する提出ノード210は、期待される確認がすべての参加者ノードからであり、すべての確認が受信されたと判定し得る。
一部の例においては、プロトコルが、確認ポリシーを指定し得る。その他の例においては、(別の見出しの下で説明される確認条件を含む可能性がある)確認ポリシーが、提出ノードによって提案されるトランザクション内で少なくとも部分的に指定される。
期待される確認は、全体または一部を決定され得る。つまり、場合によっては、ノードは、トランザクション全体ではなくノードが見る資格を与えられるトランザクションの可視部分のためにどの期待される確認が必要とされるのかについて決定を行い得る。この場合、ノードは、ノードが見る資格を与えられるトランザクションの部分に関してノードが受信した確認に基づいてトランザクションの一部が受け付けられる/確認されると決定する可能性がある。
一例において、提案されるトランザクション240は、すべての有効な期待される確認を説明する(期待される確認データなどの)情報を暗号化されたサブメッセージ244に含み得る。そのような情報は、受信された確認を検証するために使用されることが可能であり、これは、暗号関数を使用して期待される確認データによって受信された確認を検証することを含み得る。一部の例において、期待される確認は、公開鍵およびこれらの鍵が署名するために必要とされるトランザクションの部分のハッシュの形態であることが可能である。アイデンティティマネージャ270が使用されている場合、鍵は、知られている鍵の仮名である可能性があり、ハッシュは、参加者ノードのプライバシーを保護するためにソルトを付け加えられる可能性がある。したがって、トランザクション全体に関する期待される確認は、(Haskellで書かれた)次のデータ型によって与えられ得る。
type ExpectedConfirmations = [([Pseudonym] , SaltedHash ActionDescription)]
システムのさらなる特徴
一部の例においては、確認150、152、250、252が適時行われることを保証するために、タイムアウトの概念が使用される。たとえば、ドメインの規則(以下を参照)によって定義される可能性があるタイムアウトパラメータの後にトランザクションの妥当性が決定され得ない場合、トランザクションは拒否され得る。
さらに、一部の例において、ノードは、トランザクションの容量の取り決め(たとえば、必要とされる計算およびサイズ)または(たとえば、ストレージシャーディングモデルに合わせられた)構造的な使用法の取り決めなどの物理的または時間的なトランザクションの取り決めを行い、告知する。概して、これは、提案されるトランザクションを提出するときに提出ノードによって行われる可能性がある。取り決めは、プロセス毎であることが可能であり、プロセス毎および相手毎の保証を提供する。物理的または時間的なトランザクションの要件は、トランザクションのタイムアウトを延長する可能性がある。
無反応なノードが存在する場合、ノードはそのように印を付けられ得る。本開示は、紛争解決メカニズムを利用して、無反応なことおよび容量の取り決めを守らないことをやめさせ得る。
妥当性の判定
ノードは、トランザクションの妥当性を判定するためにいくつかの検査を実行することができる。トランザクションの妥当性の検査の例は、以下の通りである。
a. 競合
i. この検査は、プロセスの一部を形成する関連する契約(たとえば、DAMLの契約)または入力を既に消費したいずれかの以前のトランザクションが存在するかどうかを判定することを含む。
b. 認可
i. この検査は、認可規則に基づいて提出ノードがそのトランザクションを提出することを可能にされると判定することを含む。
c. 準拠
i. これは、準拠規則に従ってトランザクションの形式が整っているかどうかを判定することを含む。
d. 時間制約
i. これは、トランザクション時間が時間制約を満たすかどうかを判定することを含む。
e. 物理的-時間的制約
i. これは、物理的または時間的なトランザクションの取り決めが台帳の利害関係者の間で同意された物理的-時間的要件の規則のブランチバージョンの選択(たとえば、どの容量またはシャーディングモデルが使用され得るか)を満たすかどうかを判定することを含む。
f. リソース検査
i. これは、トランザクションのリソースの要件が正しく指定されたかどうかを検査することを含む。たとえば、ノードは、トランザクションの一部として指定されたトランザクションのリソースの要件を読むことができ、ノードは、ノードによって使用されるリソースが指定されたリソースの要件以内である場合にトランザクションを実行することができ、一例において、ノードは、トランザクションを実行するためにそのノードが使用するリソースが指定されたリソースの要件を超えている場合、トランザクションを行わないことが可能である。これは、ネットワーク内のノードがノードによって指定されたリソースの要件から外れているトランザクションを提出することを防止し、その結果、何も起こらないという有益な利点を持ち得る。
競合
ノード110、120、122、210、220、222が実行することができる検査のうちの1つは、提案されるトランザクション140、240が以前の提案されるトランザクションまたは以前の確認されたトランザクションと競合するかどうかを判定することである。そのような競合は、システムの同時性に内在しており、必ずしも意図的な不正な行動(悪意)または運用上の問題が原因で起こるとは限らない。競合は、プロセスの一部である契約(たとえば、DAMLの契約)または入力が1つまたは複数のトランザクションによって既に消費されたかどうかを含む可能性がある。
一部の例において、ノード110、120、122、210、220、222が実行することができる検査のうちの1つは、提案されるトランザクション140、240が現在のもしくはこれから起きる提案されるトランザクションまたは現在検証されているもしくは近い将来検証されるトランザクションと競合するかどうかを判定することである。そのような競合は、一様でない物理的な実装の選択(たとえば、シャーディング)がなされ得るか、または(たとえば、バッチのような活動などの大きなトランザクションのために)順不同のトランザクションの論理を用いるか、または概して(たとえば、最適化の目的でもしくはさらなる台帳の特徴をサポートするための)すべてのキャッシュもしくはロックのような台帳支援論理のためのシステムの同時性に内在しており、必ずしも意図的な不正な行動(悪意)または運用上の問題が原因で起こるとは限らない。競合は、契約(たとえば、DAMLの契約)が1つまたは複数のトランザクションによる消費のために既に開始されたかどうかを含む可能性がある。
認可
ノード110、120、122、210、220、222が実行することができる別の検査は、提案されるトランザクション140、240がきちんと認可されたかどうかを判定することである。これは、提出ノードが、トランザクションを提出することを台帳の状態および規則によって認可されるかどうかを判定することを含む。
準拠規則
ノード110、120、122、210、220、222が実行することができる別の検査は、提案されるトランザクション140、240が各ノードの台帳準拠規則に関して形式が整っていたかどうかを判定することである。提案されるトランザクションが形式が整っていたと判定することは、提案されるトランザクションがその提案されるトランザクションに関する1組の準拠規則に準拠するかどうかを判定することを含む可能性がある。これは、たとえば、提案されるトランザクションが指定されたフォーマットもしくは特定の台帳のワークフローを忠実に守ったかどうか、または提案されるトランザクションがすべての必要なデータを含んでいたかどうかを判定することを含む可能性がある。規則のうちの1つは、提案されるトランザクションが認可されたかどうかを含む可能性がある。これは、たとえば、提案されるトランザクションの(下でさらに詳細に検討される)物理的-時間的要件が既に定義されたかまたは利害関係者によって同意された規則を忠実に守るかどうかを判定することをやはり含む可能性がある。したがって、要求が準拠の基準を達成しない(たとえば、台帳のワークフローの選択もしくは物理的-時間的要件を不適切に実行した)かまたは認可の基準を達成しない(たとえば、ノードの台帳のワークフローが提案されるトランザクションの提出者がトランザクションを提出することを許さない)場合、要求は、何らかの形で不正な形式(整っていない形式としても知られる)であるとみなされる可能性がある。これは、概して、参加者におけるプラットフォームコンポーネントの悪意または正しさの問題(たとえば、ソフトウェアのバグ)が原因でしか起こらない。
準拠の特定の場合は、スマートコントラクト言語(たとえば、DAML)で定義されたプログラムまたはスクリプトに対する忠実さである可能性がある。
時間制約
ノードが実行する可能性があるさらなる検査は、トランザクション時間を判定し、そのトランザクション時間が時間制約内にあるかどうかを判定することである。たとえば、ノードは、提案されるトランザクションのトランザクション時間が提案されるトランザクションに関する外部ノードのタイムスタンプから離れすぎていないかどうかを判定する可能性がある。トランザクションの期待されるリソース消費が提案されるトランザクションに追加される場合、提出者がトランザクションを提出する前にトランザクションを処理する必要がある可能性があるので、ずれに関して許容される期間は、リソース消費に依存し得る。つまり、ずれに関して許容される期間は、規定された期待されるリソース消費についての因子としてドメインの規則内で定義され得る。
言い換えると、提案されるトランザクションの妥当性を判定することは、現在の時間が提案されるトランザクションのトランザクション時間のタイムアウト期間内にあるかどうか(たとえば、現在の時間が提案されるトランザクションのトランザクション時間に何らかの予め設定された時間の値を足した値を超えているかどうか)を判定することを含む可能性がある。一例において、トランザクション時間は、トランザクションの暗号化されていないサブメッセージによって与えられることが可能な論理的なタイムスタンプと考えられ得る。提案されるトランザクションを検証するノードは、現在の時間を提案されるトランザクションのトランザクション時間と比較し、現在の時間がタイムアウト期間内にあるかどうか(たとえば、現在の時間が確認応答期限よりも前であるかどうか)を判定することができる。そうである場合、ノードは、提案されるトランザクションの処理に進み、その他の妥当性の検査も通る場合、それに応じて確認応答を送信することができる。現在の時間がタイムアウト期間の後である場合、ノードは、トランザクションを行わないことが可能である。
物理的-時間的制約
ノードが実行する可能性があるさらなる検査は、物理的または時間的なトランザクションの取り決めがトランザクションまたはドメインの利害関係者の間で同意された物理的-時間的要件の規則のブランチバージョンを満たすかどうかを判定することである。たとえば、ノードは、トランザクションのコスト計算が指定された物理的-時間的要件の規則に適合しないと判定する可能性がある。たとえば、提出者ノードは、提案される論理的時間をトランザクションの規定されたリソース消費に結びつけるためにその提出者ノードが使用している規則を表明する可能性があり、提出者は、利用されるシャーディングモデルが外部ノードおよび仲介者ノードの複数のインスタンスの選択にどのようにして結びつけられるのかを表明する可能性がある。
確認条件
信頼と、完全性と、可用性との間のトレードオフを提供するため、システムは、異なる確認条件を認め得る。下でより詳細に説明されるように、確認条件は、トランザクションが受け付けられるかまたは確認され、台帳に入力され得ると判定するのに十分な確認の閾値であることが可能である。
確認条件は、提案されるトランザクションが受け付けられるかまたは確認され、台帳に適切に入力されるための制約または前提条件であることが可能である。確認条件は、受信者ノードから1つまたは複数の確認(たとえば、閾値の量の確認)を受信することに関連し得る。
多くの種類の確認条件が、存在することが可能であり、使用される適切な確認条件は、関与する関係者、プロセス、および潜在的に、ネットワークの状況などの考慮事項にさえ依存し得る。たとえば、ネットワークの状況が良好である場合、全確認条件が必要とされる可能性があるが、ネットワーク上にトラフィックの混雑がある場合、ネットワークが改善するまでは楽観的確認条件(optimistic confirmation condition)で十分である可能性がある。
全確認条件を使用すると、確認がプロセスの参加者に対応する各受信者ノードから受信されることが要件となり得る。
署名者確認条件を使用すると、確認がプロセスの署名者の参加者に対応する各受信者ノードから受信されることが要件となり得る。
楽観的確認条件を使用すると、確認の最近のストリームが指定された基準を満たすことが要件となり得る。たとえば、指定された量の確認が、割り当てられた時間期間内に関連するノードによって受信される。
「VIP」確認条件を使用すると、確認基準が、受信者ノードのプロパティに依存し得る。たとえば、VIP確認条件は、確認がプロセスの参加者に対応する(たとえば、VIPノードとして指定された)受信者ノードの指定されたサブセットから受信されることを指示する可能性がある。つまり、確認を与えなければならない一部のノードと、必ずしも確認を与えなくてよいその他のノードとが存在する可能性があり、それらが、確認条件に反映され得る。
「VIP」確認は、暗号学的証明器(たとえば、zkSNARK、zkSTARK)またはトラステッド実行環境(たとえば、Intel SGX)のアテステーションによって実装される可能性がある。言い換えると、一例においては、ネットワーク内のノードが、(たとえば、VIP確認ポリシーが使用されるとき)アテスタとして働くことができ、アテスタは、本明細書において説明される(たとえば、上の段落[0106]において説明された)ように、提案されるトランザクションがすべての妥当性の検査を満たすことを提案されるトランザクションの関係者であるその他のノードにアテステーションすることができる。一例において、アテスタノードは、提案されるトランザクションがすべての妥当性の検査を満たし、確認されたトランザクションとして受け付けられ得ることを暗号学的に証明する暗号学的証明(たとえば、zkSNARK、zkSTARK)を提案されるトランザクションの関係者に提供することができる。暗号学的証明は、上述のように、すべての関係者が提案されるトランザクションの妥当性を信頼し得るが、関連する関係者が通常はアクセスすることができない提案されるトランザクションについての内密の詳細にやはりアクセスすることができないように、提案されるトランザクションのすべての関係者に提供され得るゼロ知識型の証明であることが可能である。同様に、Intel SGXのようなトラステッド実行環境が、暗号学的証明器と一緒にまたは暗号学的証明器の代わりに使用され得る。
概して、ノードが悪意を持つこと(つまり、意図的な不正な行動)なしに動作すると信頼され得るドメインにおいては、トランザクションの受け付けを保証するために楽観的確認条件で十分である可能性がある。つまり、効率のために、ノードが悪意なく動作し、受信者ノードのいずれも悪意を持っていないと推定され得る。しかし、悪意を持っていることは、引き続き検出され、証明され得る。場合によっては、悪意のある行動の結果が、システムの外で処理される可能性がある。
一部の例において、確認条件は、(妥当性の要求の確認と考えられ得る)提案されるトランザクションに対する応答が適時提出ノードによって受信される(および/または受信者ノードによって送信される)ことも必要とし得る。これは、下のさらなる例において検討されるタイムアウトおよび期限を持つことを含む。
ドメインの規則
ドメインの規則は、ドメインのすべての参加者が同意した1組の規則である。ドメインの規則は、紛争解決プロセスまたは罰などの結果を律する可能性がある。
たとえば、ノード120、122、220、222が指定された時間枠内に確認を送信していない場合、そのノードは、ネットワークから一時的に除外されることによってまたは何らかのその他の罰を使用することによって罰せられる可能性がある。場合によっては、ネットワークへの完全なアクセスを再び許される前に、良い行動が確立される必要がある可能性がある。たとえば、ノード120、122、220、222が、ネットワークから一時的に除外され、トランザクションを提出することができず、それから、時間通りの確認のシーケンスが罰せられたノードによって受信されるまで「確認のみ」モードであることを許される可能性がある。
トランザクションの拒否
提案されるトランザクション140、240は、いくつかの理由で拒否され得る。拒否の1つの根拠は、提案されるトランザクション140、240がそのように表明することなく複数のドメインを有すること、つまり、提案されるトランザクション140、240がマルチドメイントランザクションであることを示すことなく提案されるトランザクション140、240が異なるドメインにあるプロセス102、202または契約(たとえば、DAMLの契約)を使用しようと試みたことである可能性がある。場合によっては、これは許される可能性があるが、通常の規則は提案されるトランザクション140、240が単一のドメインを有するべきであることであり得る。
一例において、ドメインの規則は、確認条件を確立する。この場合、トランザクションがドメインの規則に従って最終的に受け付けられると宣言するのに不十分な確認が、タイムアウト期間内に受信されることがあり得る。
提案されるトランザクション140、240を拒否する別の理由は、提案されるトランザクション140、240が1つまたは複数のその他のトランザクションと一貫性がないこと、つまり、提案されるトランザクション140、240がそれより前に受け付けられた/確認されたトランザクションと競合することであり得る。
一部の例において、トランザクションプロトコルは、トランザクションが承認されるかどうかと、逆にトランザクションが拒否されるかどうかとを、すべての利害関係者が知らされることを要求する。一部の例において、プロトコルは、トランザクションの宣言された利害関係者が判断の理由を知らされることを要求する。
任意のノードが、紛争を起こすことが可能であり、紛争は、問題となっているノードにオフラインとして印を付ける結果となる可能性がある。しかし、妥当でない紛争を起こすことは、ノードに罰を受けさせることにもなり得る。したがって、紛争が起こされると、提案されるトランザクションは、やはり拒否され得る。これは、受信者ノードが、提案されるトランザクションが形式が整っていないと判定する場合、または異なるノードが同じトランザクションの部分の妥当性に関して競合する応答を与える場合に起こる可能性がある。一例においては、これらの両方が、悪意またはソフトウェアのバグが原因で起こり得る。つまり、ほとんどの場合、ノードは、適切に動作すると期待され得る。
確認ハートビート
トランザクションを構成するアクティブな契約102、202(またはプロセス)を共有する参加者の各ペアは、ときどき、本明細書において確認ハートビートと呼ばれるそれらの契約についての署名されたステートメントを交換し、したがって、二者間で(または多者間で)参加者が契約/トランザクションの状態を確認することができる。ステートメントは、「タイムスタンプtsにおいて、これらはすべて最終的に確認されたアクティブな相互の契約である」という形態である。それらのステートメントは、紛争解決の際に使用され得る。たとえば、参加者Aは、契約cを含んでいたBからの最新のハートビートおよびタイムスタンプtsにおけるハートビート内の発言(say)を示し、tsとtとの間に発生したすべてのトランザクションを明らかにすることによって参加者Aが参加者Bと結んでいる契約cが何らかの時間tにおいてまだアクティブであることを裁定者に証明する可能性がある。アクションの記述の慎重な設計およびメッセージングレイヤの配信の証明によって、裁定者は、開示されたトランザクションから契約ID以外何も知る必要がない。
参加者のプライバシーを守るために、一部の例におけるステートメントは、アクティブな契約についてのマークル木の根だけを含み得る。参加者が互いのステートメントを検査することができることを保証するために、木の構造は、決定性であり、両方の参加者によって再現可能でなければならない。
プライバシー
開示されるシステムは、以下のプライバシーの特徴のうちの1つまたは複数を含む可能性がある。
要件(関連しない参加者への不開示)。トランザクションプロトコルは、(トランザクションの利害関係者および確認者を含む)提出されたトランザクションのアクションをアクションの利害関係者の参加者にのみ開示する可能性がある。この文脈で、アクションは、分散型台帳に記録される利害関係者の参加者に関連する権利の生成または遂行であり、そしてまた、その権利の生成または遂行は、そのアクションに関して利害関係者の参加者によって認識される(これは、本質的に、その権利の生成または遂行が(i)そのアクションに関してトランザクションプロトコルによって承認され、(ii)基礎となるシステムモデルに準拠することを意味する)。このプライバシーの側面は、図3に示されたトランザクションを反映する図14aおよび図14bに示される例を参照して説明される。
図14aを参照すると、Aをホストする参加者ノードは、Aがルートアクション(root action)の利害関係者であるのでトランザクション全体(第1のボックス1410)を見る可能性がある。同じ理由で、Pをホストする参加者ノードも、トランザクション全体(第1のボックス1410)を見る。Pをホストする参加者ノードは、その参加者ノードが厳密には利害関係者ではないが第2のアクション(第2のボックス1420)を見る可能性があることに留意されたい。Pをホストする参加者ノードは、第2のアクションが第1のアクション「Exe P (PaintOffer A P) "受け付け"」のサブアクションであるのでとにかく第2のアクションを見る。
銀行をホストする参加者ノードは、第2のアクション(第2のボックス1420)のみを見る。要件は、トランザクションプロトコルが第1のアクション1410の構造を銀行に開示することを可能にすることに留意されたい。これは、図14bのボックス1410'によって示される。
1410'の疑問符「???」は、銀行に配信されるメッセージがアクションのブラインディングされたハッシュを含むが、銀行がハッシュからアクションを導出することができないことを示す。
要件(提出者の不開示)。一部の例において、トランザクションプロトコルは、トランザクションの提出ノードまたは提出者をトランザクションの最上位のアクションの利害関係者の参加者にのみ開示する可能性がある。
フェンス塗装トランザクションにおいて、参加者AおよびPは、それらの参加者がアクション全体の可視性を有するので提出ノードを知る可能性がある。しかし、銀行の参加者ノードは、提出ノードも提出者のアイデンティティの知らない可能性がある(または必要とされる場合、知ってはならない)。
要件(メッセージブローカおよび仲介者への不開示)。トランザクションプロトコルは、提出されたトランザクションの内容(つまり、暗号化されたサブメッセージ144の内容)を外部ノード230または仲介者280に開示してはならない。
制限(利害関係者および確認者の開示)。トランザクションプロトコルは、提出されたトランザクションの利害関係者および確認者を外部ノード230または仲介者280に開示し得る。この情報は、暗号化されていないサブメッセージ142から導出される可能性がある。
制限(暗号化されたトランザクションの開示)。トランザクションプロトコルは、外部ノードに提出されトランザクションの暗号化されたバージョン、たとえば、外部ノードによって復号され得ない暗号化されたサブメッセージ144を開示し得る。
制限(不正な参加者による開示)。トランザクションプロトコルは、不正な参加者がトランザクションを第三者に開示することを防止しない。
制限(監査者への開示)。トランザクションプロトコルは、参加者がトランザクションを監査者に開示することを防止しない。
トランザクションビュー
システムのプライバシーは、下で説明される様々なノードの観点からのトランザクションビューによってさらに示され得る。
トランザクションプロトコルは、システムがトランザクションのあらゆるアクションに関して別々に確認応答を取得すべきであることを勧める可能性がある。より複雑な例において、これは、過剰な量のメッセージが送信されることにつながる。したがって、トランザクションビューの概念が、この負担を減らすために使用され得る。つまり、各ノードがそのノードが見る必要があるもののみを見るように、およびデータ構造のサイズを最小化するために、利害関係者が複数いるトランザクションが1組の最小限の異なるビューに分解される。
トランザクションビュー - トランザクションtxが与えられたとして、トランザクションtxのビューは、以下のプロパティのうちの1つを満たすトランザクションのサブアクションである。
1. サブアクションが、tx内に親アクションを持たない。
2. tx内のサブアクションの親アクションが、サブアクションと異なる利害関係者または異なる確認者を有する。
ビューのコアは、ビューから(ビュー自体を除く)すべてのサブビューを取り除くことによって得られる。
これは、図16aおよび図16bに最もよく示されている。全確認ポリシーが実施されており、したがって、あらゆる利害関係者が確認者でもあると仮定される。図16aに示されるように、PaintOfferの受け付けおよびPaintAgreementの生成は、これらの2つのアクションが同じ利害関係者(およびしたがってさらに同じ確認者)を有するので同じ第1のビュー1610に属する。IOUの転送は、銀行が第1のビュー1610の利害関係者ではないので別個の第2のビュー1620に属する。PのIOUの生成も、ペンキ屋Pが第2のビュー1620の利害関係者ではないので別個の第3のビュー1630に属する。
図16bは、第1のビューのコア1610'を示す。したがって、ビューのコアは、そのビューから無関係な情報を削除し、それは、メッセージのサイズと、(対応するサブメッセージの部分などの)そのような情報を記憶するためのデータの要件とを削減することができる。これは、トランザクションビューに関連するそのような情報を分散型台帳に記憶することを含み得る。第2のビュー1620および第3のビュー1630は、異なる利害関係者、確認者(およびそれぞれのノード)を含み得るそれぞれのコアを有することを理解されたい。これは、ビューを見る資格を与えられる者のみがそれぞれの情報を見ることができるので、トランザクションよりも細かいプライバシーを支援し得る。
データ構造が、上のトランザクションおよびビューを表すために構築され得ることを理解されたい。これは、トランザクション、トランザクションのあらゆるビューの利害関係者、台帳有効時間(ledger effective time)、および確認ポリシーを含む可能性がある、トランザクションを表すブラインディング可能なマークル木であるトランザクションツリーを含み得る。要件は、2つの異なる部分木が、たとえ内容が同じであっても異なるマークルルートハッシュ(Merkle root hash)を有することである可能性がある。
トランザクションツリー
図17は、フェンス塗装トランザクション1701を表す候補データ構造1700を示す。これは、以下のグループを含み得る。
(1) 1710および1711によって表されるPaintOfferの受け付け
(2) 1720および1721によって表されるIOUの転送
(3) 1730によって表される転送の一部としての新しいIOUの生成
この文脈におけるブラインディング可能なマークル木という用語は、以下を意味するかまたは以下の特徴を有する。
・あらゆる部分木がハッシュを有する。
・部分木がそのハッシュによって置き換えられる場合に、木全体のハッシュが変化しない。
・攻撃者が部分木のハッシュからその部分木の内容を導出することができることが、実質的にあり得ない。これを実現するために、ハッシュは、トランザクションツリーに含まれるブラインディングファクタ(blinding factor)に応じて決まらなければならない。
部分木のハッシュが部分木の一意識別子として使用されるので、部分木のハッシュの一意性が必要とされる。1つの部分木を見ることができる参加者が別の部分木が同じ内容を有するかどうかを推定し得ることを防止することも、必要とされる。部分木のハッシュの一意性は、一意のブラインディングファクタを適用することによって実現され得る。
定義(トランザクションおよびビューのハッシュ)。トランザクションツリーのトランザクションハッシュは、ツリーのマークルルートハッシュである。トランザクションビューのトランザクションビューハッシュは、トランザクションビューを表すトランザクションツリーの部分木のマークルルートハッシュである。
図18は、ペンキ屋によって所有されるIOUを生成するフェンス塗装トランザクションのサブビュー1730の候補表現1800を示す。PaintOfferの受け付け1710、1711およびIOUの転送1720、1721などのその他のビューに関する情報は、可視でない。これは、トランザクションよりも細かいプライバシーを提供するために使用され得る。
利害関係者ツリー - トランザクションの利害関係者ツリーは、以下のプロパティを有するトランザクションツリーの部分的にブラインディングされたバージョンである。
(1) トランザクションビューの内容がブラインディングされる。
(2) 台帳有効時間がブラインディングされる。
(3) 確認ポリシーはブラインディングされない。
(4) 選択されたトランザクションビューのハッシュはブラインディングされない。
(5) トランザクションビューのハッシュがブラインディングされない場合、ビューの利害関係者はブラインディングされない。
トランザクションの完全な利害関係者ツリーにおいて、トランザクションのすべてのビューのハッシュはブラインディングされない。図19は、フェンス塗装トランザクションの完全な利害関係者ツリーの候補表現1900である。利害関係者の情報1913、1923、1933は可視であり、その他の情報1950はブラインディングされる。
関係者p1、...、pnに関してブラインディングされない利害関係者ツリーにおいて、まさにp1、...、pnのうちの1つが利害関係者であるビューのハッシュは、ブラインディングされない。図20は、フェンス塗装トランザクションの銀行に関してブラインディングされない利害関係者ツリーの候補表現2000を示す。図19と異なり、利害関係者1913は、(銀行は参加者Aと参加者Pとの間のPaintの同意(申し出/受け付け)の利害関係者ではないので)ブラインディングされる(2013)。利害関係者の情報2023、2033は、それらが利害関係者であるので銀行に可視である。
上の例は、利害関係者がそれらが利害関係者である(またはそうでなければそのような情報を見る資格を与えられる)情報を見ることを可能にしながら、トランザクションの異なるレベルでプライバシーを保つためのメカニズムを示す。言い換えると、上述の例は、説明されたプライバシーモデルによって、トランザクションが同じトランザクションの異なる部分が関連する利害関係者に対してブラインディングされるようにして複数の利害関係者にどうやって送信され得るかを示す。そのように、複数の利害関係者は、同じトランザクションを受信し得るが、そのトランザクションの異なるプライバシーのビューを持ち得る。そのような構造は、ネットワーク内の様々なノードの間でプライバシーを保ちながら共有された台帳にトランザクションを提出し、記録することを可能にする。
仮想的な共有された台帳
一部の例において、トランザクションプロトコルは、仮想的な共有された台帳を暗黙的に生成する。仮想的な共有された台帳のプロパティは、トランザクションプロトコルによって強制される。仮想的な共有された台帳は、仮想的な概念である。概して、仮想的な共有された台帳全体を記憶する単一の参加者は存在しない。しかし、すべての参加者がトランザクションプロトコルによるインタラクションの結果として得られるメッセージを開示する場合、仮想的な共有された台帳は、これらのメッセージから導出され得る。
まず、仮想的な共有された台帳に関する1組のアクションが、定義される。理想的には、アクションは、プロトコルが基礎となるトランザクションを承認した場合およびその場合に限り仮想的な共有された台帳に属する。このプロパティは、トランザクションのすべての利害関係者の参加者が不正を働かない場合に実際に成り立つ。
しかし、一部の利害関係者の参加者が不正を働く場合、それらの利害関係者の参加者は、たとえアクションが検証アルゴリズムによって拒否されるべきであるとしてもそのアクションを承認する可能性がある。特に、不正な参加者は、基礎となるDAMLモデル(または代替的なシステムモデル)に準拠しないトランザクションをトランザクションプロトコルに承認させる可能性がある。この理由で、アクションがプロトコルが承認したトランザクションの一部である場合、アクションは、仮想的な共有された台帳の一部であるためにさらなるプロパティを満たさなければならない。
仮想的な共有された台帳に関するアクション - アクションは、以下のプロパティが成り立つ場合に仮想的な共有された台帳の一部である。
i. アクションが、トランザクションプロトコルによって承認されたトランザクションの一部である。
ii. アクションが、基礎となるシステムモデル(たとえば、DAMLシステムのためのDAMLモデル)に準拠する。
iii. (アクション自体を含む)アクションのあらゆるサブアクションAに関して、Aの宣言された利害関係者が、システムのセマンティクス(たとえば、DAMLのセマンティクス)によって正しくAの利害関係者である。
この例の定義が、フェンス塗装トランザクションの例に示される。基礎となるシステムモデル(この場合、DAMLモデル)が例において使用されるすべてのアクションを含み、したがって、トランザクションが基礎となるシステムモデルに準拠すると仮定される。さらに、トランザクションが全確認ポリシーを用いて提出されたと仮定される。まず、利害関係者がDAMLのセマンティクスに従って正しく宣言される場合を考える。トランザクション全体が承認された場合、トランザクションのあらゆるアクションは、仮想的な共有された台帳の一部である。そうでない場合、つまり、トランザクションが拒否された場合、トランザクションのアクションのいずれも、仮想的な共有された台帳の一部ではない。
図15aは、PではなくAがフェンス塗装トランザクションを提出し、AがPを第1のアクション1510の利害関係者として宣言しなかった場合を示す。また、プロトコルがトランザクションを承認したと仮定する。
第1のアクション1510は、Pが利害関係者として宣言されなかったので仮想的な共有された台帳の一部ではない。これは、Pが「受け付け」の選択の制御者であるが、アクションを見てさえいなかったので理にかなっている。
PaintAgreementの生成(1520)は、AとPとの両方が利害関係者として正しく宣言されたので仮想的な共有された台帳の一部である。AとPとの両方がそれらの参加者ノードを通じてアクションを承認したので、アクションを仮想的な共有された台帳に追加することは理にかなっている。
同じ理由で、AからPへのIOUの転送(アクション1530および1540)は、仮想的な共有された台帳の一部である。銀行がIOUの転送について知らされる必要があるので、仮想的な共有された台帳からIOUの転送を除外することは実行不可能である。
図15bは、AがPaintAgreementを生成するアクション(1520')の利害関係者として宣言されなかった場合を示す。やはり、プロトコルがトランザクションを承認したと仮定する。
PaintAgreementの生成(1520)は、Aが利害関係者として宣言されなかったので仮想的な共有された台帳の一部ではない。これは、アクションがAに知らせることなくPaintAgreementを生成するので理にかなっている。PaintOfferの受け付け(1510)も、仮想的な共有された台帳の一部ではない。DAMLモデルは有効なPaintAgreementを生成すること(1520)なしにPaintOfferを受け付けることを許さないので、PaintOfferの受け付け(1510)が仮想的な共有された台帳の一部であったならば、仮想的な共有された台帳はDAMLモデル(または代替的なシステムモデル)に準拠しない。
上述のように、IOUの転送(1530および1540)は、仮想的な共有された台帳の一部である。Aと銀行との両方がトランザクションを承認したので、それに反対する理由はない。
どの条件の下でアクションが仮想的な共有された台帳の一部であるのかを説明したので、以降、「いつ」トランザクションが仮想的な共有された台帳の一部であるのかという問題が、対処される。
仮想的な共有された台帳上のトランザクション。トランザクションtxは、以下のプロパティのうちの1つが成り立つ場合、仮想的な共有された台帳の一部である。
1. トランザクションtxが、トランザクションプロトコルによって提出され、txのすべてのアクションが、仮想的な共有された台帳の一部である。
2. トランザクションtxが、別のトランザクションptxの一部としてトランザクションプロトコルによって提出された。トランザクションtxは、仮想的な共有された台帳の一部ではないアクションをptxから削除した結果として得られる。
最後に、仮想的な共有された台帳の例が、以下のように定義される。
仮想的な共有された台帳。一部の例において、仮想的な共有された台帳は、以下のプロパティを含み得る。
i. 仮想的な共有された台帳が、トランザクションのシーケンスである。そのシーケンスが、上で検討されたように「仮想的な共有された台帳の一部」であるトランザクションを含む。
ii. 仮想的な共有された台帳上のトランザクションの順序が、提出の順序に対応する。代替的に、「論理的な並べ替え」として検討された順序などの、プロトコルに従った指定された順序において。
iii. 仮想的な共有された台帳上のあらゆる記録されたアクションが、そのアクションの確認者および確認者の署名(たとえば、受信ノードの署名)を付けられる。
iv. 仮想的な共有された台帳上のトランザクションが提出されたトランザクションと一致する場合、トランザクションは、その提出者および提出ノードの署名を付けられる。
上述のように、概して、仮想的な共有された台帳全体を記憶する単一の参加者は存在しない。しかし、すべての参加者がトランザクションプロトコルによって互いにインタラクションした結果として得られたメッセージを開示する場合、仮想的な共有された台帳は、これらのメッセージを組み合わせることにより導出され得る。
例示的な方法
図4は、システム200によって実行される例示的な方法を示す。方法は、システム100を使用して実行されることも可能であることを理解されたい。
この例において、外部ノード230は、複数の参加者を含むプロセスを構成する複数のトランザクションに対応する複数のメッセージの順序を決定することができる(410)。決定するステップ410は、下で説明されるステップの一部の前、間、または後に実行される可能性があることを理解されたい。
プロセスの参加者に関連付けられる提出ノード210は、(図2aの240などの)提案されるトランザクションを提出することができ(420)、提案されるトランザクションを提出することは、(暗号によって保護されたメッセージなどの)部分的に暗号化されたメッセージをプロセスの参加者に関連する(受信者ノード220などの)1つまたは複数の受信者ノードに送信することを含むことが可能であり、部分的に暗号化されたメッセージは、少なくとも、外部ノード230によって読み取り可能な暗号化されていないサブメッセージ242と、少なくとも外部ノード230からプライバシーを守るための(暗号によって保護されたサブメッセージなどの)暗号化されたサブメッセージ244とを含む。
それから、受信者ノード220は、部分的に暗号化されたメッセージの妥当性を判定することができる(430)。これは、提案されるトランザクション240に対して妥当性の検査を実行することと、それから、妥当性の検査が合格である場合、提出ノード、および受信者ノード220が確認を期待するまたは必要とすると判定する任意のその他のノードに確認を送信することとを含み得る。一例において、受信者ノード220は、仲介者ノード280を通じて確認を送信し得る。その他の例において、受信者ノード220は、ピアツーピアで確認を送信し得る。
そして、提出ノード210は、受信者ノード220から部分的に暗号化されたメッセージの妥当性の確認を受信することができる(440)。
それから、提出ノード210は、確認条件を満たす1つまたは複数の受信者ノードから1つまたは複数の確認を受信することに基づいて、提案されるトランザクションを受け付けられたまたは確認されたトランザクションとして確定することができる(450)。確認条件は、上で明示されたように、たとえば、全確認条件、VIP確認条件、またはシステムのパラメータとして設定された何らかのその他の確認条件であることが可能である。
そして、この場合は提出ノード210であるノードが、受け付けられた/確認されたトランザクションを外部ノード230によって決定された順序に従って台帳に書き込むことができる(460)。台帳は、分散型「仮想」台帳を含め、本明細書において詳細に説明されるように任意の台帳であることが可能である。一例において、トランザクションの一部である受信者ノード220(またはノード220、222)は、そのようなノードが確認条件を満たすのに十分な確認250、252を受信すると、台帳のそのノードのコピー260、262、264に受け付けられた/確認されたトランザクションを書き込むこともできる。ある意味で、トランザクションのノード210、220は、一例において、ノード210、222の間で起こる任意の数のトランザクションに固有のノード間の「仮想的な」共有された台帳を形成し得る。
各ノード110、120、122、130、210、220、222、230、330、340、342は、説明される方法の対応する部分を実行することが可能であることを理解されたい。
例示的なノード
図5は、本明細書において開示されるノード110、120、122、130、210、220、222、230、330、340、342のいずれかである可能性がある例示的なノードを示す。図5に示されるノード210は、プロセッサ502、メモリ503、ネットワークインターフェースデバイス508、510、台帳260とインターフェースを取る分散型台帳インターフェースデバイス509、およびユーザインターフェース512を含む。メモリ503は、命令504およびデータ506を記憶することができ、プロセッサ502は、図3に示されたようにプロセスを実施するためにメモリ503からの命令を実行することができる。
プロセッサ502は、参加者516などのユーザからユーザインターフェース512を通じて入力を受信することができる。プロセッサ502は、分散型台帳152に記録された実行の現在の状態に基づいて命令を決定することができる。命令は、実行する関数である可能性がある。プロセッサ502は、プログラムコード504に記憶された命令を実行して参加者516に任意の出力514または結果を示す可能性がある。
リソースモデル
提案されるトランザクション140、240は、各受信者がトランザクションを検証し、確認するための、予め指定された共有された物理的-時間的制約(処理時間、メモリ、ネットワーク、ストレージ)の選択を表すリソースユニットを単位とする1つまたは複数のリソースの要件、一例において、要求メッセージ毎に1つの確認可能なサブブロック(one per request message confirmable sub-block)を含む可能性がある。
あらゆるノード110、120、122、130、210、220、222、230、330、340、342は、指定された量のリソースを指定された時間の期間の間提供すると取り決め得る。そのような容量の取り決めは、プロセスまたはノードのグループに制限され得る。すべてのリソースの要件は、当てはまる最も特定的な容量の取り決めに対して課される。ノードは、リソースの要件がそのノードの未使用の容量の要件を超えるトランザクションを直ちに拒否し得る。ノードは、リソースの要件がそのノードのリソースの容量に関する割り当てから外れていることを示すために応答する可能性がある。裁定者ノードなどの容量モニタが、そのノードのリソースの容量に関する割り当てを超えていることに基づいてすべての拒否を確認し得る。それによって、容量モニタは、関連するノードによってなされた容量の取り決めに照らして検査し得る。
一部の例示的なシステムにおいて、ノードの容量の取り決めは、ノードおよびそれらの参加者を含む前のトランザクションまたは提案されるトランザクションおよび受け付けによって生成され、場合によっては更新された。そのような容量予約トランザクション(capacity reservation transaction)は、本開示において説明されるトランザクションを使用して実装され得る。一部の例示的なシステムにおいて、容量の取り決めは、特定のトランザクションの種類のサブセットに関して予約される。これは、一部の例示的なシステムがノードに容量生成および更新トランザクション(capacity creation and update transaction)を処理するための容量を取り決めさせることを可能にし得る。
リソースの要件は、トランザクション内で宣言されるが、トランザクション自体の内容ではないことが可能である。したがって、理論上、提出ノードは、トランザクションを処理し、検証することによって、消費される実際のリソースよりも低いリソースの要件を宣言し得る。受信者ノードは、そのような不一致を検出し、提出ノードがリソース消費をごまかしていることを根拠に紛争を起こすことが可能である。
リソース手当(resource allowance)
リソースモデルに関連して、場合によっては、提出手数料またはリソース手当が、提出ノード110、210によって支払われることを要求され(提出手数料)、トランザクションの契約(たとえば、DAMLの契約)に関する選択を遂行する適用可能な受信者ノード120、122、220、222によって支払われることを要求される(検証手数料)可能性がある。手数料は、ドメインを運営する運用者および/またはトランザクションの利害関係者に支払われ得る。手数料は、トランザクション、プロセス、およびドメインによって使用されるために必要とされるリソースの量によって決定されるトランザクションのコストに応じて決定され得る。これを簡単に行うために、各ノードは、手数料アカウントを持つことが可能であり、その手数料アカウントにおいて手数料が引き落とされ、手数料アカウントに支払われる。
会計コンポーネントが、各参加者に関するアカウントを維持することができる。トランザクションがメッセージブローカ(たとえば、外部ノード230)によってタイムスタンプを付けられるとき、提出手数料が、提出者のアカウントに請求され得る。トランザクションが確定するとき、検証手数料が、振り込まれ得る。参加者は、専用のワークフローを使用してそれらの参加者の手数料アカウントに入金することができる。
一部の例示的なシステムにおいて、手数料会計およびトランザクション論理が、本開示において説明されるトランザクションを使用して実装され得る。そのような場合、運用者または運用者の代表は、ドメイン内のノードを有する参加であることが可能である。そのとき、手数料会計規則および手数料支払い論理が、追加の会計コンポーネントを必要とすることなく台帳の論理内に実装され得る。さらに、手数料データまたはサポートデータが、追加のトランザクションの論理を必要とすることなく提案されるトランザクションおよび(暗号化されたまたはされていない)確認メッセージ内で転送される可能性がある。これは、参加者がトランザクションによって手数料計算のために使用される手数料の規則を生成し、更新することを可能にし、および/または手数料計算が参加者およびトランザクションの内容に固有であることを可能にする可能性がある。たとえば、参加者ノードは、台帳のプロセス内のそれらの参加者ノードの唯一の役割が検証することであるとき、検証手数料を取られない可能性がある。
紛争
紛争は、参加者が同意された期間内にトランザクションを確認しないか、検証に通らないトランザクションを組織的に要求するか、または不十分なリソースの要件を宣言するときなど、参加者が不正を働いているかまたは故障しているときに起こされ得る。
裁定者ノードは、システムの一部を形成することができ、紛争を審査するための証拠を記憶することができ、つまり、裁定者ノードは、送信されたトランザクションおよび確認を記憶する必要がある可能性がある。紛争に関与するノードは、紛争が解決され得るように、証拠、つまり、それらのノードのブラインディングされていないトランザクションを提供することを求められる可能性がある。プライバシーを保つために、ノードは、裁定者ノードのみがトランザクションを復号し得るような方法でそれらのトランザクションを再暗号化する可能性がある。
一部の例示的なシステムにおいて、紛争解決プロセスは、本開示において説明されるトランザクションを使用して実装される。そのような場合、裁定者は、ドメイン内のノードを有する参加者であることが可能である。そのとき、紛争解決プロセスは、追加の会計コンポーネントを必要とすることなく台帳の論理内に実装され得る。追加のトランザクションの論理を必要とすることなく、紛争が起こされることが可能であり、証拠が提供されることが可能であり、解決結果が決定されることが可能である。これは、トランザクションによって参加者が紛争を起こし、証拠を提供し、紛争を解決することを可能にする可能性がある。
タイムアウトの紛争
上述のように、一例において、確認条件は、参加者が提案されるトランザクションに適時応答することを求める。参加者が適時応答しない場合、そのトランザクションの参加者ノード(または代行者)は、裁定者ノードに対してタイムアウトの紛争を開始し得る。これは、違反を決定し、より重要なことに、違反を起こした特定の参加者ノードを決定するために使用され得る。そのようなタイムアウトの紛争を処理する例は、以下のうちの1つまたは複数を含み得る。
・影響を受けた確認要求のタイムスタンプを、メッセージングAPIによって配信された関連する証明および応答し損なった(責任を問われる参加者の)仮名と一緒に裁定者ノードに提出する。知られている場合、仮名の裏側のアイデンティティも送信される。
・アイデンティティが提供されなかった場合、裁定者ノードが、アイデンティティマネージャ170にアイデンティティを明かすように求める。責任を問われる参加者のアイデンティティを決定した後、裁定者ノードが、参加者に、参加者(特に参加者のそれぞれのノード)が応答した証拠の要求を送信する。証拠は、責任を問われる参加者かまたは容量モニタ(要求がOutOfQuota応答によって拒否された場合)かのどちらかからの確認応答を含む、メッセージングサービスからのタイムスタンプ付きのメッセージである。
・証拠が提供される場合、要求の開始者が永続的に「確認のみ」モードに移される、つまり、開始者は、システムにさらなる確認要求を送信することを禁じられるが、我々は、開始者がメッセージを受信し、確認応答を送信することを引き続き許す。
・責任を問われる参加者が応答しない場合、メッセージがブロードキャストされ、その参加者にオフラインとして印を付ける。オフラインの参加者は、確認のみモードに移され、それ以外の参加者は、それらのオフラインの参加者の確認要求を拒否することを許される。提出者は現在の方式において匿名であるので、拒否は、容量モニタまたは手当の会計担当者(allowance accountant)によって行われる可能性がある。責任を問われる参加者がオンラインに復帰した後、その参加者は、裁定者ノードによるなどして再び印を付けられる要求を発行することができる。要求は、利用可能でいるように参加者に奨励するために、特定の「冷却」期間の後にのみ承諾される可能性がある。
・責任を問われる参加者が無効な証拠によって応答する場合、その参加者は、永続的に(または指定されたペナルティ期間の間)確認のみモードに移される。
参加者の不正行為の検出および証明
参加者の不正行為は、悪意のあるアクションが原因で起こり得る。例は以下を含む。
・参加者が、基礎となるシステムモデル(たとえば、DAMLシステムのDAMLモデル)に準拠しないトランザクションを提出する。
・参加者が、参加者がホストしない提出者の代わりにトランザクションを提出する。
・参加者が、提出者以外の関係者によって認可される必要があるトランザクションを提出する。
・参加者が、形式が整っていないトランザクションを提出する。
・参加者が、宣言された利害関係者の参加者をDAML(またはその他の代替的システム)のセマンティクスによる利害関係者の参加者と異なるように定義する。したがって、誤った参加者が、アクションについて知らされる。
・トランザクションを確認する受信者ノードが、アクションを検証するためにプロトコルによって規定されたアルゴリズムを適用しない。たとえば、アクションがアーカイブされた契約を使用するが、トランザクションを確認する受信者ノードがアクションを承認する。または、トランザクションを確認する受信者ノードが、検証アルゴリズムによって承認されるべきアクションを拒否する。
・外部ノードが、受信者ノードの誤ったリストを用いてメッセージを配信するか、または受信者ノードにメッセージを配信することに失敗する。
不正行為およびそれがシステム内にどのようにして現れ得るかの例は、以下を含む。
1. 確認要求(たとえば、提出された提案されるトランザクション)が、不正な形式としてフラグを立てられる。
2. 確認要求に対して(受信者ノードから期待されるものへの)競合する応答が到着する。
3. トランザクションが、容量の取り決めの枯渇(たとえば、リソースの欠乏)を誤って主張することによって拒否される。
このことから、以下のことが判定され得る。
1. 2者が同じ確認要求に関して競合する確認を発行する場合、2者のうちの1者が悪意を持っている(またはその者の参加者ノードがクラッシュではない形で正常に機能していない)。
2. 不正を働かない関係者が、裁定者ノードの助けを借りて、誰がごまかしていたのかを正確に特定するのに十分なデータを得る。
確認要求は、以下の理由で不正な形式になり得る。
1. 上述のように準拠および認可の検査に通らない。
2. 提出ノード110による誤ったリソースの宣言。
不正な形式の確認要求を受信する不正を働かない参加者は、紛争を開始するためにその確認要求を裁定者ノードに転送する。そのとき、裁定者ノードは、紛争の開始者の参加者ノードが行った同じ検査を実行することができる。検査が失敗する(つまり、提出ノードの提案されるトランザクションが規則に合わない)場合、提出者のアイデンティティが明かされ、提出者は確認のみモードに永続的に移される。そうでない場合、紛争の開始者が、確認のみに設定される。
競合する応答は、ある関係者がトランザクションを拒否し(つまり、受信者ノードのうちの1つ)、別の関係者(つまり、別の受信者ノード)がトランザクションを確認する場合にのみ起こり得る。拒否する関係者は、まず、裁定者ノードに拒否の証拠を提供しなければならない。
1. 拒否する関係者が認可または準拠の問題のためにトランザクションを拒否した場合、確認要求自体で十分であり、または
2. 拒否する関係者が一貫性の検査のためにトランザクションを拒否した場合、拒否する関係者は、現在のトランザクションと競合する以前の最終的に確認されたトランザクションを提供すべきである。
紛争の敗者は、その者が悪意を持って行動したため、永続的に(またはペナルティ期間の間)確認のみモードに移される。
集中型メッセージングサービスの不正行為の検出および証明
我々が集中型メッセージングブローカ(たとえば、外部ノード230)を使用する場合、メッセージングブローカの不正行為が、必要とされるメッセージングレイヤのプロパティの違反を引き起こし得る。直観的に、ブローカのいかなる関連する不正行為も、参加者の状態の逸脱につながる。逸脱は、参加者が確認および/もしくはハートビートをやりとりするとき、または参加者が紛争を起こそうと試みるとき、参加者がブローカの不正行為を指し示す競合する証拠を持つので検出される。不正行為が影響を受ける関係者によって検出可能であるが、証明され得ない2つの場合が存在し、それらは、(i)ブローカが参加者からのすべてのメッセージを阻止するとき、および(ii)ブローカが参加者のメッセージを拒否するときである。
その他の例示的な方法
3つのその他の例示的な方法が、以降で説明される。第1は、単一のドメインにおける方法の例である。第2のおよび第3の例は、複数のドメインに関する。特に、第2は、ドメイン変更プロトコルに関する。第3は、マルチドメイントランザクションに関する。
単一ドメインにおけるさらなる例示的な方法
図10から図13は、単一のドメイン1000における引き渡し対支払い(DvP: delivery-versus-payment)の例1001を示す。アリス1010およびボブ1012は、銀行1014によってアリス1010に与えられたIOUをボブ1012が持ついくらかの株式と交換したい。我々は、4人の関係者、すなわち、アリス(別名A)1010、ボブ(別名B)1012、銀行、および株式登録簿(share registry)SR 1016を有する。以下の3種類の契約も存在する。
1. 常に銀行1014を支援者とするIOU契約1031
2. 常にSR 1016を登録簿とする株式契約1033
3. アリス1010とボブ1012との間のDvP契約1035
アリスは、自身の有するIOU 1031をボブが有する株式1033と交換するDvP契約1035のインスタンスに関する「スワップ」の選択をすることができると仮定する。我々は、IOUおよび株式契約のインスタンスがDvPにおいて既に割り当てられたと仮定する。アリスは、このスワップの選択を実行するトランザクションをコミットしたいと思っており、トランザクションは、図10に示される以下の構造を有する。
この例示的なトランザクションをコミットすることは、以下の2つのステップを含む。
第1のステップ - (提出ノードとしての)アリスの参加者ノード1010が、トランザクションの確認要求1041を準備する(1040)(図12参照)。要求1041は、トランザクションに関する異なるビューを提供し、参加者は、それらの関係者が利害関係者である契約を遂行するか、フェッチするか、または生成するサブトランザクション(より厳密に言えば、これらの関係者が情報の受取人(informee)であるサブトランザクション)のみを見る。DvPに関するビューおよびそれらの参加者が、図11aに(ボックスの右下に示されるように)示される。アリスの参加者ノード1010は、この単一のドメイン1000内のすべての確認要求を順序付けるシーケンサ1018(すなわち、外部ノード1018)に要求を提出し、2人の参加者が同じ2つの要求を見るときにはいつも、それらの参加者は、このシーケンサ(外部ノード1018)の順序に従ってそれらの要求を見る。この例において、シーケンサ(外部ノード1018)は、2つの機能、すなわち、メッセージを順序付ける機能、およびそれらのメッセージをそれらのメッセージの規定された受信者1012、1014、1016に配信する機能のみを有する。ペイロードメッセージの内容は、暗号化され、シーケンサ(外部ノード1018)には不可視である。
第2のステップ - 受信者ノード1012、1014、1016が、それから、それらの受信者ノード1012、1014、1016が受信するビューの妥当性を検査する。妥当性の検査1051、1053、1055、1057は、3つの点を包含し得る。
1. 台帳のモデル内で定義された妥当性、すなわち、一貫性(主に、二重支払いがないこと)、準拠(ビューが有効なDAMLの解釈の結果である)、ならびに認可(アクタおよび提出者がビューのアクションを実行することを可能にされることを保証する)
2. 真正性(アクタおよび提出者がそれらのアクタおよび提出者がそうであると主張する者であることを保証する)
3. 透明性(通知されるべき参加者が通知を受けることを保証する)
準拠、認可、真正性、および透明性の問題は、提出者1010の悪意に起因してのみ生じる。一貫性の問題は、悪意がなくても生じ得る。たとえば、ボブ1012に転送されるべきIOUが、単に、既に消費された可能性がある(我々はDAMLの「ロック」技術を使用しないと仮定する)。検査の結果に基づいて、確認者と呼ばれる受信者1014、1016のサブセットが、それから、各ビューに関する(肯定的または否定的)確認応答を別々に準備する。要求に関連する確認ポリシーは、トランザクションの情報の受取人が与えられた場合に、どの参加者が確認者であるのかを指定する。
確認者は、それらの確認者の応答1061、1062、1063、1064を仲介者1020、応答を確認要求全体に関する単一の判断に集約する別の特別なエンティティに送信する。仲介者1020は、互いに参加者のアイデンティティを隠すために働く(したがって、銀行1014およびSR 1016は、それらが同じトランザクションの一部であることを必ずしも知らない)。シーケンサ(外部ノード1018)と同様に、仲介者1020は、トランザクションの内容を知らない。その代わりに、アリスの参加者ノード1010は、要求1041を送信することに加えて、仲介者1020に各ビューの情報の受取人についても同時に通知する(1042)。仲介者は、図11bに概念的に視覚化されるようにビューの情報の受取人のみが可視であり、内容がブラインディングされる(1032、1034)トランザクションのバージョンを受信する。
これから、仲介者1020は、確認要求が承認されたと判断するためにどの(肯定的)確認応答1061、1062、1063、1064が必要であるかを導出する。
悪意のある参加者によって提出された要求1041は、偽のビューを含み得る。参加者は、(プライバシーの理由で)要求の一部のみを見ることができ、要求に関する承認を受信する、各参加者は、その参加者に可視である偽のビューをローカルでフィルタリングして取り除き、承認された確認要求のすべての残りの有効なビューを受け付ける。確認ポリシーの信頼の仮定の下で、プロトコルは、不正を働かない参加者のローカルの判断がそれらの参加者が合同で見るすべてのビューに関して一致することを保証する。したがって、プロトコルは、トランザクションがそのような有効なビューからなる、参加者の間の仮想的な共有された台帳を提供する。承認されると、受け付けられたビューは確定する、つまり、それらのビューは参加者の記録または仮想台帳から決して削除されない。
図12の例を再び参照すると、シーケンサ(すなわち、外部ノード1018)および仲介者1020が、アイデンティティ(図示されていないが他の箇所で説明される)と一緒に、単一のドメイン1000の例を形成する。ドメイン1000内のすべてのメッセージは、シーケンサ(外部ノード1018)を介してやりとりされ、これが、ドメイン1000内でやりとりされるすべてのメッセージの間の全順序を保証する。
全順序は、参加者が、すべての確認要求1041および応答を同じ順序で見ることを保証する。さらに、プロトコルは、たとえ不正を企む提出者がいたとしても、すべての不正を企んでいない(つまり、悪意のないまたは機能不全でない)参加者が(参加者である銀行とAとの間で共有されるIOUの転送の遂行などの)それらの参加者の共有されたビューを見ることを保証する。これは、以下の意味合いを持つ。
1. 各ビューに関する正しい確認応答は、DAMLモデルを使用する一部の例においてはその確認応答が決定性であるので常に一意に決定される。しかし、性能的な理由で、我々は、参加者が不正を企んでまたは争いの下で行動し始めるとき、時折起こる誤った否定的応答を許す。システムは、不正を働かない参加者に、それらの参加者の応答の正しさかまたは誤った拒否の理由かのどちらかの証拠を提供する。
2. 大域的順序付けは、シーケンサ(外部ノード1018)において測定されるドメイン内の(仮想的な)大域的時間(global time)を生成し、参加者1010、1012、1014、1016は、それらの参加者がシーケンサ1018からメッセージを受信するときにはいつも時間が進んだことを知る。この大域的時間は、競合を検出し、解決し、タイムアウトが発生するときを判定するために使用される。概念的に、我々は、したがって、この大域的時間に関して同時にいくつかの参加者において行われるステップについて語り得るが、各参加者1010、1012、1014、1016は、このステップを異なる物理的時間に実行する。たとえば、図12のメッセージシーケンス図において、アリス1010、ボブ1012、銀行1014、および株式登録簿1016の参加者は、異なる物理的時間に確認要求1071、1072、1073、1074を受信するが、概念的に、これは、大域的時間のタイムスタンプts1において起こり、同様に、結果メッセージ1081に関してタイムスタンプts6において起こる。
図10から図13の例は、単一のドメインを示す。しかし、これは、後の例において検討されるように複数のドメインをサポートするように修正され、適応され得る。
システムのいくつかの考慮事項は、参加者ノードが過負荷がかかっているか、オフラインであるか、または単純に応答を拒んでいる可能性があるものとして、確認に基づく設計の進展を保証しながら完全性およびプライバシーの問題の折り合いをつけることである。これらの考慮事項に対処する例示的な方法は、以下を含む。
・タイムアウトの使用: トランザクションの妥当性が(ドメイン中で一定である)タイムアウトの後に決定され得ない場合、トランザクションは拒否される。
・確認要求がタイムアウトする場合、システムは、参加者が確認応答を送信し損なった要求を提出する参加者1010に知らせる。これは、提出する参加者が不正行為に対して帯域外(out of band)アクションを行うことを可能にする。
・柔軟な確認ポリシー: 信頼と、完全性と、ライブネス(liveness)との間のトレードオフを提供するために、一部のドメインは、それらのドメインのそれぞれの確認ポリシーに合わせて調整される可能性がある。確認ポリシーは、どの参加者がどのビューを確認する必要があるかを指定する。これは、仲介者1020が要求が承認されたと宣言するのに十分な条件を決定することを可能にする。特に興味深いのは、あらゆるアクションに関して信頼された(VIP)関係者を情報の受取人として含むトランザクションに適用可能なVIP確認ポリシーである。VIP関係者の例は、市場運営者である。ポリシーは、VIP関係者の参加者が正しく行動すると仮定して台帳の妥当性を保証し、誤った行動は、この場合、引き続き検出され、証明されることが可能であるが、付随的結果(fallout)は、システム外で処理されなければならない。別の重要なポリシーは、すべての署名者およびアクタが確認することを求められる署名者確認ポリシーである。これは、署名者またはアクタをホストする参加者が無反応であるときにライブネスを犠牲にするVIP確認ポリシーと比べて低いレベルの信頼を必要とする。(軽視されている)別のポリシーは、すべての情報の受取人が確認することを求められる全確認ポリシーである。これは、最も低いレベルの信頼を必要とするが、含まれる参加者の一部が無反応であるとき、ライブネスを犠牲にする。
・アテステータ(attestator)ノード。アテステータノードは、オンデマンドのVIP参加者と考えられ得る。VIP関係者があらゆるアクションに関して情報の受取人であるようにDAMLモデルを構築する代わりに、アテステータノードは、オンデマンドでのみ使用される。トランザクションをコミットさせたい参加者は、アテステータノードにサブトランザクションの妥当性の明白な証拠を提供するのに十分な量の履歴を開示しなければならない。それから、アテステータのステートメントが、無反応の参加者の確認の代わりをする。
図13は、確認要求の状態遷移図1300を示し、「提出済み」以外のすべての状態は最終状態である。他の箇所で説明されるように、確認要求は、現在のドメイン1000の外のトランザクションの要求(それが別途説明される許容されるマルチドメイントランザクションの一部である場合を除く)、タイムアウト、不整合、および以前のまたはその他の要求との競合を含む様々な理由で拒否され得る。
ドメインの変更および構成可能性(composability)
一部の例において、システムは、システムが複数のドメインおよび異なるドメインにまたがるトランザクションをサポートするという点において構成可能性を有する。構成可能性は、(アプリケーションレイヤではなく)同期レイヤにおいてドメイン間トランザクションに関するアトミック性の保証を提供する。これは、アプリケーションレベルでいくつかのドメインを1つの概念的な台帳に構成することを可能にし得る。ドメイン間トランザクションの手法は、以下を含む。
1. ドメイン変更プロトコル。これは、契約をあるドメインから別のドメインに転送するためのプロトコルである。そのようなプロトコルは、多くの必要とされる契約を単一のドメインに移すことによってマルチドメイントランザクションをシングルドメイントランザクションに変えるために使用され得る。つまり、それは、すべての影響を受ける契約のすべての利害関係者がその1つの共通のドメインに接続されることを要求する。
2. マルチドメイントランザクションのためのプロトコル。この手法は、異なるドメインの間の中継者として働き得る参加者ノードの一部を含む。この手法は、すべての利害関係者が単一のドメインに接続されることを要求しない。しかし、そのようなシステムは、トランザクションがすべてのドメインにまたがってアトミックに実行されるように利害関係者によるアクティブな参加を有することが重要である。
2つの手法が、以降で詳細に検討される。
ドメイン変更プロトコル
ドメイン変更プロトコルは、個々の契約を移動元のあるドメインから移動先の別のドメインに移す。契約は、以下の異なる理由で移される可能性がある。
・後続のトランザクションが単一のドメインの契約に関して働き得ることを保証するための準備ステップとして。
・異なるドメイン間の負荷を分散させるため(利害関係者によって行われる)。
・より良い市場の規則、手当、またはサービス品質を利用するため(やはり利害関係者によって行われる)。
ドメイン変更プロトコルの例は、以下の特徴のうちの1つまたは複数を含み得る。
・契約は、1つのドメインにのみ存在するかまたは別のドメインに転送中である。契約は、最終的に、契約の常駐先(residence)であるドメインに存在しなければならない。契約のすべての利害関係者は、その常駐先のドメインに直接接続されなければならない(または中継者を介して間接的に接続されなければならない)。
・すべての利害関係者は、それらの利害関係者の契約のすべてがどこに存在するかを知らなければならず、この情報をそれらの利害関係者のそれぞれの契約ストアにメタデータとして保存することができる。
・契約IDは、常駐先が変わるときに変化しない。
ドメインの変更は、2つのステップ、すなわち、移動元ドメインにおける転出および移動先ドメインにおける転入で起こる。ドメインの変更は、転送中止を使用して中止される可能性がある。
今のところ、参加者は、ドメインの変更の開始者のアイデンティティを知り、メッセージブローカ(すなわち、外部ノード)は、転送される契約のIDおよび移動先ドメインを見る。より優れたプライバシーの保証が、将来の研究で調べられるべきである。
一部の例において、ドメイン変更プロトコルの手法は、その手法がすべてのドメインの間の協力を必ずしも必要とせず、その代わりに、その契約およびトランザクションに関連する参加者のみを必要とするので特に有利である可能性がある。ドメイン変更プロトコルは、開始者ノード614によって開始される。一部の例において、開始者ノード613は、提出ノード110であるかまたは提出ノード110に関連付けられる。その他の例において、開始者ノードは、受信者ノード120を含むその他のノードであることが可能である。
ドメインの変更の2つの例が、図6および図7を参照して以降で説明される。第1の例においては、利害関係者IおよびPを有する、ドメイン1に常駐するIDがcidの契約が存在する。開始者I 614が、図6に示されるようにドメイン2に契約を転送する。
1. 開始者I 614が、移動元ドメインのメッセージブローカ610(すなわち、外部ノード)に転出要求621を送信する。転出要求TOは、契約ID、提出者、移動先ドメイン、および移動先ドメインのタイムスタンプts0を含む。
2. 移動元メッセージブローカ610が、時間ts1において要求TOにタイムスタンプを付け、その要求TOを利害関係者612および開始者614に送信する(623、624)。それらは、契約cidが時間ts1以降転送中であるとみなす。
3. 開始者614が、タイムスタンプを付けられた転出要求を含む転入要求TI 625を移動先ドメインのメッセージブローカ616(すなわち、移動先ドメインの外部ノード)に送信する。
4. 移動先メッセージブローカ616が、時間ts2において転入要求にタイムスタンプを付け、その転入要求を利害関係者612(すなわち、受信者ノードおよび/または提出ノードに関連付けられた利害関係者)ならびに開始者614に送信する(627、629)。そのとき、利害関係者612は、時間ts2以降、契約が移動先ドメインにあるとみなす。
転出要求621は、移動先ドメインの排他性(exclusivity)タイムアウト630に関する基準を確立するために移動先ドメインからのタイムスタンプts0を含む。排他性タイムアウト630の前に、開始者ノード614のみが、ドメインの変更を完了するかたまはドメインの変更を中止するために移動先ドメインに転入要求または転送中止メッセージを送信する可能性がある。この排他性タイムアウト630は、場合によっては異なる移動元ドメインの異なる契約に関するいくつかのドメインの変更を開始し、それらを単一の転入メッセージで移動先ドメインにトランザクション(図示せず)と一緒に提出するための時間を開始者614に与える。
開始者614が排他性タイムアウト630の前にドメインの変更を完了または中止することができない場合、契約のその他の利害関係者612が、そのようにする可能性がある。これは、開始者ノード614が契約をいつまでの転送中のままにし、それによって、その他の利害関係者612からそれらに関する選択を遂行する利害関係者612の権利を奪うことができないことを保証する。
図7に示される第2の例は、前の例と同じ設定を有するが、ステップ2の後、開始者が、排他性タイムアウト630の前に転入要求を送信しない。その代わりに、ステップは、以下を含む。
3. 利害関係者P 612が、移動先ドメイン616に転送中止メッセージを送信する(731)。
4. 移動先ドメイン616が、時間ts2において転送中止にタイムスタンプを付け、その転送中止を利害関係者および開始者に転送する(733、735)。
したがって、開始者ノード614および利害関係者612は、移動先ドメインにおいてそれより前の転入メッセージがないことを知る。契約自体は、移動元ドメインにおいてタイムスタンプがまだ存在しないので引き続き転送中である。したがって、
5. 利害関係者P 612が、タイムスタンプを付けられた転送中止を転送中止通知として移動元ドメインのメッセージブローカ610に転送する(737)。
6. 移動元メッセージブローカ610は、時間ts1'においてこの通知にタイムスタンプを付け、この通知を利害関係者612および開始者ノード614に転送する(739、741)。それらは、やはりts1'以降、契約が移動元ドメインにあるとみなす。
7. ドメイン2から転送中止メッセージを受信する(735)とき、開始者ノード614は、利害関係者P 612がそれらの排他性時間期間に割り込まなかったことを保証するために、移動先ドメインのタイムスタンプが排他性タイムアウト630の後であることを検査する。
ドメインの変更を中止する代わりに、利害関係者Pは、転入メッセージを送信することによってドメインの変更を完了することもできた。そのとき、プロトコルは、利害関係者P'の転入メッセージが排他性タイムアウト630の後にタイムスタンプを付けられたことを開始者ノード614が検査することを除いて第1の例と同様に継続したであろう。逆に、第1の例において、開始者614は、その代わりに、転送中止メッセージを送信することによってドメインの転送を中止することができた。
以上はドメイン変更プロトコルの例であり、プロトコルのその他の種類および変化形がこの結果を実現する可能性があることを理解されたい。図6および図7に全体的に示されたプロトコルの一例のさらなる詳細が、以降で説明される。
誰もが、契約を別のドメインに転送することを許されるとは限らない。(提出ノード、受信者ノード、またはその他の影響を受けるノードに関連する利害関係者であることが可能である)あらゆる利害関係者は、その利害関係者の契約を常に転送可能であり、唯一の制約は、すべての利害関係者がそれらが新しいドメインを受け付ける(またはそうでなければ承諾する)ことを事前にシグナリングしなければならなかったことである。この基本設計において、我々は、あらゆる参加者がその参加者がどのドメインを承諾するかを時間の始めに宣言したこと、およびあらゆる参加者がこれらの宣言を知っていることを仮定する。
ドメインの変更を開始するために、開始者614は、(メッセージブローカドメイン1 610を介するなどして)契約の常駐先ドメインに転出要求621を送信する(621)。そのような要求は、転送される契約ID、開始者のアイデンティティおよび場合によっては代理を立てた開始者ノード(proxied initiator node)、移動先ドメイン、(たとえば、ブローカのハートビートからの)移動先ドメインの最近のタイムスタンプ、ならびにドメインを変更する権利を正当化する理由(justification)を含む。タイムスタンプは、開始者614がドメインの変更を中止するかまたは移動先ドメインに関する転入メッセージを提出するかのどちらかの排他的権利を有する時間の期間の基準を設定する。(開始者614が契約の移動元ドメインに接続されないとき、開始者614は、利害関係者612に開始者614に代わってドメインの転送を開始するように頼まなければならない。その場合、実際の開始者はproxiedInitiatorになり、利害関係者がinitiatorになる。)転出要求は、メッセージングレイヤにおいてすべての契約の利害関係者612にアドレス指定される。転出要求の例は、以下を含む。
data TransferOutRequest = TransferOutRequest
{ contractID :: ContractID
, initiator :: Party
, proxiedInitiator :: Maybe Party
, targetDomainID :: SiriusDomainID
, targetTimestamp :: Signature SiriusDomainID Timestamp
, justification :: (ProvenanceProof, Randomness) }
移動元のメッセージブローカ610は、要求にタイムスタンプを付け、提出確認を開始者614に送信し(623)、転出要求をタイムスタンプと一緒にすべての利害関係者612に転送する(624)。移動元ドメインの手当会計コンポーネントは、開始者のアカウントからドメイン変更手当を引き落とす。
利害関係者P 612は、以下のうちの1つまたは複数またはすべてを含む検査を転出要求に対して実行する。
i. 利害関係者612のリストが完全である。
ii. 提出者が、要求内で指定された開始者614である。
iii. 移動先ドメインが、すべての利害関係者に受け入れ可能である。
iv. 移動先のタイムスタンプが、移動先ドメインによって署名された。
v. 正当化する理由が、妥当である。
vi. 契約が、移動元ドメインに存在する。
vii. より小さな物理的なタイムスタンプを有する競合するドメインの変更またはトランザクションが存在せず、同じ転出要求に関して移動先ドメインに転送中止メッセージが存在しなかった。
検査(i)から(v)が失敗する場合、転出要求は、不正な形式であり、参加者612は、悪意のある行動を報告する(転送プロトコルの帯域外)。検査(vi)が失敗する場合、利害関係者612は、転出要求624を拒否する。拒否は、契約の現在の常駐先ドメインを含む。競争する(racing)ドメインの変更が原因で契約が現在転送中である場合、拒否は、そのように伝える。開始者614が利害関係者612でないとき、検査(vi)は、そのとき開始者614がドメインの変更について知らされないので、競争がなくてもやはり失敗する可能性がある。そのような場合、拒否は、開始者612に新しい常駐先について知らせる。検査(vii)が失敗する場合、利害関係者612は、転出要求624を拒否する。すべての検査が合格である場合、契約は、転出要求の移動先のタイムスタンプから始まる転送中になる。(一時的に)転送中の契約はいずれのドメインにも存在せず、それらの契約に関していかなる選択も実行され得ない。
利害関係者612は、ドメインの規則によって定義された転出確認のタイムアウト以内に開始者614に移動元ドメインのメッセージブローカ610を介して転出要求を確認する。すべての検査は、すべての利害関係者612が同意するデータにのみ依拠する。したがって、利害関係者612は、すべて同じ結果に至らなければならない。したがって、利害関係者612の間で確認を送信する必要はない。
転入ステップは、移動先ドメインにおいて契約を登録する。移動元メッセージブローカのタイムスタンプおよび署名のある転出要求を有する利害関係者612および(代理を立てた)開始者614は、移動先メッセージブローカ616に転入メッセージ625を提出することによってそのようにすることができる。この権利は、転出621と排他性タイムアウト630との間の時間期間の間、開始者614だけにある。単一の転入メッセージ625が、たとえ異なる移動元ドメインからであってもいくつかの契約を同時に登録し、任意でDAMLトランザクションを(要求のペイロードの形態で)含む可能性がある(リソース要求メッセージが事前に送信されなければならない)。転入要求の例は、以下を含む。
data TransferInMessage = TransferInMessage
{ inContracts :: [TransferInRequest]
, submitter :: Party
, transaction :: Maybe RequestPayload }
data TransferInRequest = TransferInRequest
{ out :: TransferOutRequest
, originTimestamp :: Timestamp
, originSignature :: Signature }
移動先メッセージブローカ616が転入メッセージ625を受信するとき、すべての転入要求は、移動先ドメインによって同じタイムスタンプを付けられ、転入確認要求としてそれぞれの利害関係者612に送信される(629)。転入メッセージがトランザクションを含む場合、それは、次のタイムスタンプを付けられる。
参加者612が転入確認要求を受信する(629)とき、参加者612は、参加者612が移動元ドメイン610から対応する転出要求を受信し(624)、処理するまで待つ。(通常、転出要求624は、転入メッセージ629の前に到着するが、これは、ネットワークレイテンシーが変わる場合、必ずしも当てはまらない。)それから、参加者612は、以下の検査を実行する。
(i) 参加者612が、転出ステップで説明されたように移動元ドメインにおいて転出要求を確認した。
(ii) 参加者612が、この転出要求に関してそれより前のタイムスタンプを有する転入確認要求または転送中止通知を見なかった。
(iii) 転出要求が、正しい移動先ドメインを指定する。
(iv) メッセージ内の転送の提出者が転出要求の開始者でない場合、少なくとも排他性タイムアウト630が、転出要求内のtargetTimestampと転入確認要求に対する移動先ブローカのタイムスタンプとの間に経過した。
(v) 開始者614が転送される契約の利害関係者でない場合、参加者が、メッセージブローカからの次のタイムスタンプが転送される契約に関する選択を遂行するトランザクションにあることを忘れずに検査する。
これらの検査のいずれかが失敗する場合、参加者612は、紛争解決の節で説明されるように不正行為を報告する。そうでない場合、参加者612は、契約が、転入確認要求に対する移動先メッセージブローカのタイムスタンプによって示される時点から移動先ドメインにあるとみなす。これによって、契約は、転送中でなくなる(つまり、契約は、移動先ドメインにある)。参加者612は、移動先メッセージブローカ616を介して開始者614および代理を立てた開始者に確認を送信する。そうでない場合、参加者612は、開始者およびすべての利害関係者に拒否を送信する。
(代理を立てた)開始者ノードが契約の利害関係者でない場合、参加者612は、次のタイムスタンプを有する移動先メッセージブローカ616からのメッセージが転送される契約に関する選択を遂行するトランザクションを含み、出所の証明(provenance proof)がアクタおよび選択を含むことを検査する。これが当てはまらない場合、不正行為が報告される。
いくつかの転出要求を単一の転入メッセージにまとめることは、すべての転送のアトミック性を保証しない。一部が成功する可能性があり、一部が失敗する可能性がある。まとめることは、すべての成功する転送が同じタイムスタンプを付けられることしか保証しない。このように、トランザクションのために必要とされる一束の契約は、それらの常駐先を同時に占める可能性がある。それらが個々の転入において行われる場合、すべての契約が同じドメインに存在する前により前の契約が転出される危険性があった。ドメインの変更のうちの1つが失敗する場合、契約がトランザクションのドメインにないことが原因で契約の利害関係者がトランザクションを拒否するので、トランザクションは、それが未転送の契約に関する選択を遂行しないのでない限り、やはり失敗する。(最も早い)排他性タイムアウトの前に、開始者は、すべてのドメインの変更が成功するかどうかを知るが、ただし、開始者が利害関係者でない各契約に関して1つの転出確認を開始者が受信したことが条件である。
各ドメインは、図7に示されるようにドメインの変更に関する排他性タイムアウト630を指定する。排他性タイムアウト630の間は、ドメインの変更の開始者614のみが、転入または転送中止メッセージを送信することを許される。タイムアウト630の基準は、転出要求621において開始者614が使用した移動先ドメインのタイムスタンプによって確立される。したがって、開始者614は、これがドメインの変更を勧める開始者614の排他的権利を引き延ばすので、最も最近のタイムスタンプを使用する動機を有する。
排他性時間期間の間、開始者614は、転出要求確認623を集め、いくつかの転出を単一の転入625にまとめることができる。したがって、開始者614は、トランザクションのために必要とされるすべての契約が同じドメインに移されることを保証し得るか、または一部が失敗した場合にドメインの変更を中止すると判断し得る。トランザクションを転入要求625に含めることによって、いずれの競合する転出も、契約の一部を転出し得ない。トランザクションに関するリソース要求メッセージは、排他性時間期間の間に(つまり、排他性タイムアウト630の前に)送信される。したがって、排他性期間は、開始者614が転入メッセージ625を提出する前に容量拒否のタイムアウトも待つことができるように十分に長いべきである。
排他性タイムアウト630の後、その他の利害関係者は、開始者が契約をいつまでも転送中のままにすることを防止し、リソースを解放するためにドメインの変更の中止を開始する可能性がある。
マルチドメイントランザクションのためのプロトコル
マルチドメイントランザクションは、複数のドメインからの契約にまたがり、明示的な契約のドメインの変更を必要としない。この節は、以下のプロパティおよび仮定を有するマルチドメイントランザクションのためのプロトコルを説明する。
・提出者が、トランザクションにおいて使用されるまたは生成される契約が存在するすべてのドメインに接続されなければならない。
・参加者がサブトランザクションの利害関係者であり、そのサブトランザクションの入力の契約が1つのドメインにあり、そのサブトランザクション自体が別のドメインにおいて発生するサブトランザクションを有する場合、参加者は中継者と呼ばれる。
・マルチドメイントランザクションの提出者が、常に中継者である。すべての中継者が、すべてのドメインに接続されなければならない。
・すべてのその他の利害関係者が、それらの利害関係者の契約があるドメインにのみ接続される必要がある。特に、すべての含まれる参加者が接続される単一のドメインが存在するとは限らない。
・複数のドメインに接続された参加者が、異なるドメインのアイデンティティの管理者に異なる鍵を登録した可能性がある。
・すべての中継者またはメッセージブローカのうちの1つが適時動作しないか、またはすべての中継者およびメッセージブローカのうちの1つの間の接続性の問題が起こるのでない限り、マルチドメイントランザクションが、すべてのドメインにまたがってアトミックに実行される。
・同じ台帳有効時間が、すべてのドメインで使用される。
・異なるドメインの間のクロックの差およびクロックドリフト(clock drift)に知られている限界が存在する。
・マルチドメイントランザクションが、確認要求の規則の悲観的拒否(pessimistic reject)および条件付き評決(conditional verdict)を用いて働く。
・すべての含まれるドメインが、同じ確定(finality)モデル(全確認または楽観的VIP確認)に従わなければならない。
・シングルドメイントランザクションは、マルチドメイントランザクションに先行し得る。
・あらゆる契約は、すべての利害関係者が接続される単一のドメインにあり、契約のすべての利害関係者は、その契約がどこにあるか常に知っている。
(提出ノード110に関連する)提出者は、その提出者が利害関係者であるトランザクションのすべての入力の契約の常駐先ドメインを知っている。ドメイン変更プロトコルと同様に、提出者が利害関係者でない入力の契約に関しては、提出者は、過去のどこかの時点で常駐先を知る。トランザクションにおいて生成される契約に関して、提出者は、これらの契約がどこで生成されることになるかも知っている。これは、トランザクション自体で(たとえば、DAMLトランザクションまたはDAML拡張(extension)で)指定され得るかまたは提出者が独自に決定し得るかのどちらかである。トランザクションに関与するドメインは、すべて、トランザクションの入力の契約があるかまたはトランザクションが契約を生成するドメインである。
図8を参照すると、マルチドメイントランザクションが、各ドメイン803、805につき1つの部分に分割される。各部分は、一部のビューのペイロード、つまり、その他のドメインの契約に影響を与えるビューのペイロードが確認要求内にない部分的なシングルドメイントランザクションのように実行される。それでもやはり、すべてのビューに関するすべての確認が、すべてのドメインに送信されなければならない。その目的で、中継者は、確認をあるドメインからその他のドメインに転送する。
図8は、2つの契約cid1およびcid2に関する選択を遂行する単純な2ドメイントランザクションのためのメッセージフローを示す。ドメインの割り振りは、下の表によって与えられる。
Figure 2022508948000002
したがって、トランザクションは、3人の参加者、すなわち、提出ノード815、参加者1 811、および参加者2 819、ならびに2つのドメインD1およびD2(ならびに外部ノードとして働くドメイン1(D1、803)およびドメイン2(D2、805)のそれぞれのメッセージブローカ813、817)を含む。トランザクションに関与するすべての参加者が接続されるドメインは存在しないが、提出者(提出ノード)815はすべてのドメインに接続され、中継者として働く。提出者815は、トランザクション全体の確認要求を、各ビューについて1つずつ、2つの部分的なシングルドメイントランザクションに分割する。そして、提出者815は、各部分を適切なメッセージブローカ813、817(すなわち、それぞれのドメインD1およびD2の2つの外部ノード)に同時に送信する。各部分は、2つのメッセージ、リソース要求831、835、および要求のペイロード833、837からなり、提出者815は、(たとえば、すべての容量拒否のタイムアウトが過ぎるまで待つことによって)いずれのドメイン803、805においても参加者がリソース要求831、835を拒否しなかったことを提出者815が確かめた後にのみ提出者815がペイロード833、837を送信することを保証しなければならない。それぞれの部分的なシングルドメイントランザクションは、以下の例外を除き、シングルドメインの場合と同様に処理される。
1. 期待される確認851、852が、その他のドメインの仮名性のある参加者も含む。そのとき、(この例においては提出者ノード815である)中継者が、その他のドメインのメッセージブローカ813、817を介して意図される受信者811、819に確認を転送する(853、854)責任を負う。
2. 参加者811、819がローカルのメッセージブローカ817、813にそれらの参加者の確認応答851、852を送り終えていなければならない時間を決定する確認期限845、846は、何らかの制約を受ける、提出者815が選択する確認期限のオフセットだけ(メッセージブローカのクロックに関してさえ)判断時間847、848よりも早い。リモートドメインからの確認851、852は、判断時間848、847までにドメインのメッセージブローカ(外部ノード)813、817に届いていなければならない。確認期限と判断時間との間のオフセットは、1つのドメインから確認を集め、もう1つのドメインにそれを転送するため、ならびにドメイン803、805の間のクロックスキュー(clock skew)および変化する確認応答のタイムアウトを隠すための時間を中継者に与える。
図9は、様々な期限がどのようにして決定され、一緒に働くかを示す。提出者(提出ノード)815が、以下を選択する。
・評価のための台帳有効時間(LET)909
・論理的時間オフセット911、913
・確認期限のオフセット915、917
LETは、マルチドメイントランザクション全体で同じでなければならない。オフセット911、913、915、917は、各ドメイン803、805に関して異なるように選択され得る。
部分的なトランザクションが個々のドメインに送信される(831、835)とき、それぞれの部分的なトランザクションは、以下のように特定のドメインにおけるすべての時点を決定する物理的なタイムスタンプを付けられる。
・論理的時間=物理的時間+論理的時間オフセット911, 913
・判断時間847, 848=論理的時間+確認応答のタイムアウト915, 917
・確認期限845, 846=判断時間848, 847 -確認期限のオフセット915, 917
各時点は、そのドメイン803、805に結びつけられる。したがって、これらの時点の絶対的時間は、ドメイン毎に変わる。図9において、提出者815は、(たとえば、提出者815がリソース要求の送信がドメイン2 805においてより長くかかると予想したために)ドメイン1 803のためにより長い論理的時間オフセット911を選択しており、ドメイン1 803における論理的時間921は、総経過時間(wall-clock time)に関して確かにドメイン2 805における論理的時間923の後に来る。
提出者815は、すべてのドメインが結局同様の論理的時間になるようにドメインのネットワークレイテンシーのその提出者815の経験に基づいて論理的時間オフセット911、913を選択すべきである。これは、ドメインの規則の許容範囲925、927によって決定されるように、すべてのドメインで同じである台帳有効時間909が各ドメインの論理的時間921、923に近くなければならないからである。
提出者(提出ノード)815は、(送信元ドメインと送信先ドメインとのすべての組合せに関して)送信元ドメインの確認期限845、846と転送の送信先ドメインの判断時間847、848との間の時間内に確認応答を転送する(853、854)のに十分な時間をあらゆる中継者が有するように確認期限のオフセット915、917を選択すべきである。しかし、オフセット915、917は、あらゆるドメインのあらゆる参加者が、その参加者がドメインからの論理的なタイムスタンプを観測するときと、確認応答が確認期限845、846の前にブローカ813、817に到着するようにその参加者が確認応答を送出しなければならないときとの間の競合を検査する(951)のに十分な時間を有するように十分に小さくなければならない。
提出者815がこれらの時間を選択するので、提出者815は、その他の中継者よりも有利である可能性がある。これを防ぐために、提出者815は、任意の2つのドメインにおいて確認期限845、846がどれだけ離れている可能性があるかを制限する確認許容範囲953を選択しなければならない。許容範囲が大きいほど、確認期限のオフセット915、917は長くなければならない。
マルチドメイントランザクションのユースケースの例:グローバルな担保(global collateral)
マルチドメイントランザクションの例が、以降で、マルチドメイントランザクションに関するグローバルな担保の文脈で説明される。グローバルな担保の鍵の同期およびプライバシーの要件は、一般的なアトミックスワップにおいて捉えられる。
グローバルな担保のユースケースにおいては、2人の関係者AおよびBが、それぞれAおよびBによって所有される2つの資産XおよびYをアトミックスワップしたい。簡単にするために、我々は、あらゆる関係者が自身の参加者ノードを実行すると仮定する。資産Xの所有権は、1つの取引所EX1に取引所の資産登録簿R1によって記録される。資産Yの所有権は、別の取引所EX2に別の取引所の資産登録簿R2によって記録される。各取引所EXiは、自身のドメインDiを実行し、取引所の資産登録簿は、対応する取引所のドメインにのみ接続される、つまり、Riは、Diにのみ接続される。関係者AおよびBは、両方のドメインに接続される。
アトミックスワップは、2人の関係者のうちの1人、たとえばAがスワップを実行する選択を遂行し得るDvD(引き渡し対引き渡し(delivery versus delivery))契約において捉えられる。この選択には、それぞれ、AがBにXを転送するおよびBがAにYを転送する2つのサブトランザクションをともなう。この契約は、AとBとの両方が利害関係者であるので両者が接続されなければならない別のドメインD3にある可能性がある。
このトランザクションは、マルチドメイントランザクションの要件を満たす、つまり、資産登録簿R1およびR2が、それらがそれぞれそれらの取引所のドメインの単一の転送のみを見るので中継者でなく、したがって、それらの資産登録簿R1およびR2が、その他のドメインに接続される必要がない。実際、資産登録簿R1およびR2は、トランザクションがすべてのドメインにまたがってアトミックに実行されるかどうかを気にかけない。対照的に、AおよびBは、中継者であり、AとBとの両方が、3つのドメインすべてに接続される。アトミック性は、両者にとって極めて重要である。AのBへのXの転送が成功するが、BのAへのYの転送が失敗する場合、Aは、何の資産もない状態になる。
Bの場合は、対称的である。したがって、AとBとの両方は、ドメインの間でメッセージを適時中継することに関心を持つ。
このトランザクションは、すべての利害関係者が接続されるドメインがないので(上で検討されたように)「ドメイン変更プロトコル」によって実行され得ない。
この節の残りは、マルチドメイントランザクションの詳細と、マルチドメイントランザクションがシングルドメイントランザクションとどのように異なるのかを説明する。
トランザクションの提出
マルチドメイントランザクションを提出することは、シングルドメイントランザクションとは以下の点で異なる。
ビューの形成が、契約の常駐先を考慮に入れる。トランザクションツリーの走査が最上位のトランザクションのサブトランザクションを訪れるとき、新しいボックスが、以下のときに生成される。
・サブトランザクションの契約(入力もしくは生成)が、親ノードの入力の契約と異なるドメインにある、または
・(シングルドメインの場合のように)利害関係者の集合が異なるあらゆるボックスは、そのボックスが関連付けられるドメインによってアノテーションされる。
図8を参照すると、提出者は、トランザクションに関与する各ドメインに関するリソース要求831、835およびペイロードメッセージ833、837からなる確認要求を準備する。ドメインDに関する各リソース要求およびペイロードメッセージは、以下の修正をされたシングルドメインの場合のように準備される。
・リソース要求内のリソースフィールドおよび手当フィールドが、Dを介して送信されるビューのリソースの要件および転送される手当のみを集約する。さらに、あらゆる中継者が、確認応答を中継するためのすべてのドメインにおけるリソースの限界を割り振られる。
・帯域幅が、Dを介して送信されるペイロードのサイズを指す。
・ペイロードデータが、Dを介して送信されるビューのアクションの記述のみを含む。
・リスト「allStakeholders」が、Dを介して送信されるボックスの利害関係者の仮名のみを含む。(提出者を含む)ある中継者Pがそれらの中にないが、それにもかかわらずDに接続される場合、提出者は、Pの仮名を人為的に生成し、その仮名を「allStakeholders」に追加する。
・期待される確認のリストが、すべてのドメインから必要とされる確認を含む。あらゆる確認に関して、たとえ確認がペイロードメッセージが送信されるドメインを介して送信されるとしてもドメインIDが設定される。
・「multiDomain」フィールドが、以下で説明されるようにリソース要求内で設定される。このフィールドは、特に、確認期限のオフセットおよび許容範囲を定義し、これは、下で説明される。
data MultiDomainData = MultiDomainData
{ confirmationDeadlineOffset :: TimeDistance
, confirmationTolerance :: TimeDistance
}
・logTimeOffsetが、確認期限のオフセットによって増やされる。
・要求のペイロードのメタデータ内の「multiDomain」フィールドは、その他のドメインのリソースIDのリストを用いて設定される。
data MultiDomainPayloadData = MultiDomainPayloadData
{ remoteRequestIds :: [(DomainID, RequestID)]
}
リソース要求内のマルチドメイントランザクションのメタデータは、以下の情報を含む。
・提出者が、各ドメインのために、確認期限に関するオフセットを選択する。所与のドメインの参加者が、それらの参加者の確認を
論理的時間+ crt
の代わりに
論理的時間+ crt = confirmationDeadLineOffset
の前に送信しなければならず、式中、crtは、シングルドメインの場合からの確認応答のタイムアウトである。確認期限のオフセットは、次の制約を満たさなければならない。
confirmationDeadLineOffset < crt - 2 *Δ
式中、Δは、ドメインのメッセージブローカとの通信に関する予測されるネットワーク遅延である。さらに、確認期限のオフセットは、
2 *Δmax + confirmationTolerance + skew≦confirmationDeadLineOffset
を満たさなければならず、Δmaxは、任意の含まれる参加者からその参加者が接続される任意の含まれるドメインまでの最大の予測されるネットワーク遅延であり、skewは、任意の2つのドメインの間のクロックスキューの上限である。
・確認期限のオフセットが、あるドメインから別のドメインに確認を転送するための中継者として働くための時間を提出者(およびその他の参加者)に与える。上限は、すべての参加者がそれらの参加者が論理的時間を観測した後に確認応答を送信するための十分な時間を有することを保証する。下限は、ドメイン間で確認応答を転送するための時間を中継者に与える。
・確認許容範囲が、異なるドメインの確認期限がどれだけ離れている可能性があるかを指定する。提出者が異なるドメインの物理的なタイムスタンプをより正しく予測し得るほど、実際の確認期限は近くなり、より狭い許容範囲をその提出者が選択し得る。
ペイロード要求の代わりに、提出者815は、トランザクションを中止し得る。中止は、以下の場合に必要とされる。
・リソース要求が、ドメインのうちの1つにおいて拒否される。したがって、トランザクション全体が、拒否されなければならない。
・確認許容範囲が超えられるように、物理的なタイムスタンプがあまりにも大きくずれた。
メッセージブローカがリソース要求または要求のペイロードを受信するとき、メッセージブローカは、シングルドメイントランザクションと同様にそれらを処理する。特に、提出者は、あらゆるドメインにおいて提出手当を支払わなければならない。
確認要求の処理
確認要求831、833、835、837は、以下の点を除いてシングルドメイントランザクションと同様に処理される。
・参加者が、「RemoteRequestIDs」フィールドが重複するドメインIDを含まず、期待される確認に記載されたあらゆるドメインに関してちょうど1つのエントリを含むことを検査する。あらゆる参加者が、ペイロード要求内で与えられた要求IDおよびリモート要求IDから新しい要求識別子を導出する。導出は、リモート要求IDの順序に依存してはならない。新しい要求識別子は、確認応答のために使用される。
・トランザクションに関する確認期限が、
phys_ts + logTimeOffset + crt - confirmationDeadlineOffset
によって決定される。
・容量モニタが、トランザクションが容量の取り決めに合うかどうかを判定するために修正された確認期限を使用する。
・参加者が、
2 *Δmax + confirmationTolerance + skew≦confirmationDeadlineOffset < crt - 2 *Δ- skew
であることを検査する。
要求のペイロード833、837に関して、参加者は、以下をさらに検査する。
・リソース要求831、835および要求のペイロード833、837が、同じドメイン803、805を介して送信された。遂行に関して、入力の契約が、確認要求が送信されたドメインに存在する。生成に関して、要求のペイロードのドメインが、すべての利害関係者にとって受け付け可能である。
・各アクションに関して、参加者が、その参加者が確認応答を送信するときまでにその参加者が利害関係者であるすべてのサブトランザクションに関するボックスをその参加者が受信し終えていることを検査する。
・ビューのサブアクションが異なるドメインにおいて働く場合、参加者は、自身を中継者とみなす。
・ビューのサブアクションが異なるドメインにおいて働く場合、参加者は、その参加者がその参加者の確認を送信する前に以下のすべてを検査する。
- 「remoteRequestIDs」内のすべてのリモート要求IDの物理的なタイムスタンプが、ビューの確認期限の少なくともconfirmationTolerance +Δmax + skew前にある。
- その参加者が、「remoteRequestIDs」に挙げられたすべてのドメインのリソース要求を受信した。
- すべてのそれらの要求の確認期限のあらゆるペアが、最大で「confirmationTolerance」離れている。
・正しいドメインIDが、参加者に送信されるアクションボックスに関する期待される確認に関して設定される。
・メタデータおよびアクションボックスを照合するとき、参加者が、同じドメインのすべてのサブアクションを検査する。参加者が中継者である場合、参加者が、対応するドメインを介して送信された「allStakeholders」リストを用いてその他のドメインのすべてのサブアクションに対してもこの照合を実行する。(期待される確認者のリストが、どんな場合もすべてのサブアクションに関して検査される。)
参加者は、リスト「allStakeholders」からの仮名に確認応答を送信する。それは、それらがすべてのドメインから期待される確認を受信することを検査する。マルチドメインデータmdは、確認応答を生成するとき、確認許容範囲を含む。
data MultiDomainConfirmationData = MultiDomainConfirmationData
{ confirmationTolerance :: TimeDistance
}
競争するトランザクションの場合、マルチドメイントランザクションは、たとえ条件付き評決がシングルドメイントランザクションのために使用されるとしても常に悲観的拒否規則に従って処理される。
その結果、マルチドメイントランザクションの論理的なタイムスタンプが別の(シングルまたはマルチドメイン)トランザクションに関する論理的時間と確認期限との間に入る場合、マルチドメイントランザクションは、即座に拒否される。これは、特にマルチドメイントランザクションが概してより長い論理的時間オフセットを有するので、マルチドメイントランザクションを二流市民(second-class citizen)にする。
確認応答の処理
あらゆる参加者が、確認内のマルチドメインデータがその参加者がリソース要求831、835で受信した同じ確認許容範囲を含むことをさらに検査することを除いて、(受信ノードとして動作する参加者のノード811、819などの)確認者は、シングルドメイントランザクションとまったく同様に確認応答を処理する。参加者は、すべての期待される確認が所与のドメイン803、805を介して到着した場合、トランザクションがこのドメインにおいて最終的に承認されるとみなす。特に、参加者が異なるドメインに異なる仮名で現れる場合、その参加者は、その参加者が2つの別々のエンティティであるかのように最終的な承認に関して働かなければならない。したがって、参加者は、トランザクションが1つのドメイン(たとえば、805)においてまだ保留中である一方で、別のドメイン(たとえば、803)においてそのトランザクションが最終的に承認されたとみなす可能性がある。特に、参加者は、その参加者がその他のドメインにおいてそのようにしてはならない一方で、後続の確認に関するその参加者の判断の根拠を1つのドメインにおける最終的な承認に置くことができる。それにもかかわらず、シングルドメイントランザクションのセマンティクスは、契約が1つのドメインにのみ存在し得るので、契約のすべての利害関係者がその状態について同意することを保証する。さらに、確定に関連する異なる状態は、タイムアウト、紛争、およびクラッシュが起きない限り、最も新しい判断時間が過ぎたときには収束している。
参加者ノードは、その参加者ノードが受信したビューのいずれかに関してその参加者ノード自体を中継者とみなした場合、その参加者ノード自体を中継者とみなす。中継者が1つのドメインから確認応答を受信するとき、その中継者は、シングルドメインの場合と同じ検査を実行する。加えて、その中継者は、以下を行う。
・その中継者は、すべてのドメインから確認応答を集める。
・(期待される確認のリストによって決定されるように)1つのドメインからの十分に多い確認応答が到着したとき、中継者は、その他のドメインのすべての参加者にすべての確認を送信する。複数のドメインに接続されたあらゆる参加者はその参加者が各ドメインにおいて別々のエンティティであるかのように働くので、中継者は、たとえそれらが契約利害関係者であるとしてもその他のドメインの仮名を有する参加者を省略してはならない。
提出者がすべてのドメインのすべての中継者に関して仮名を生成したので、すべての中継者は、すべての確認応答を受信し、したがって、それらの確認応答を転送することができる。中継者は、最初に確認応答を集め、それから、単一のバッチでそれらの確認応答を送信する代わりに、確認応答を直ちに転送することもできる。不必要なトラフィックを避けるために、中継者は、それがまだ確認応答を受信していないドメインにのみ確認応答を転送する。すべての転送が互いに競争するので、同じ確認応答が、異なるタイムスタンプを用いてドメイン上で何度か送信される可能性がある。誰もが、後のタイムスタンプを有する確認応答の転送を無視し得る。
ドメインをまたぐアトミック性
一部の例において、確認応答851、852は、ローカルの確認期限845、846までに送信されなければならない。その他のドメインからの応答は、判断時間847、848までに着きさえすればよい。これらの2つのタイムスタンプは、2フェーズコミットプロトコルの2つのフェーズの終わりを表し、つまり、すべての参加者は、確認期限までに提出者にコミットの準備を送信しなければならず、それらの参加者は、判断時間847、848までのコミットまたは中止を期待し得る。
古典的な2フェーズコミットプロトコルは、ハードタイムアウト(hard timeout)をアトミック性と組み合わせることができない。その結果、マルチドメイントランザクションは、ドメインに固有の判断時間847、848の前に一部の確認応答がすべてのドメイン803、805に転送(851、852)されない場合、非アトミックに実行される可能性がある。入門的な例においては、提出者815が、PL1の参加者1 811の確認および提出者の確認のドメイン805への転送854をドメイン805の判断時間847の後まで遅らせると仮定する。そのとき、参加者1 811および提出者815は、ドメインD1のトランザクションが承認されたとみなす。対照的に、参加者2 819は、ドメインD2の確認PL1 854がタイムアウトしたとみなし、提出者に対して紛争を起こし得る。第2のドメイン805の紛争の規則に応じて、トランザクションは、ドメイン805において拒否される可能性がある。したがって、トランザクションは、アトミックに実行されなかった。しかし、我々は、提出者815のみがそのような例においてアトミック性に注意を払い、アトミック性が破られるのは提出者の責任であったと主張する。したがって、トランザクションがアトミックに実行されなかったこといついて誰も不満を言うことはできない。
概して、特定の関係者だけがトランザクション(の一部)のアトミック性に注意を払い、システム全体としてはそうではない。より形式的に、tx = [a1, a2, ..., an]が、関心のあるトランザクションを表すものとする。あらゆるアクションai自体が、契約を生成するかまたは契約ciに関する選択chiを遂行する。あらゆる遂行ai自体が、さらなるサブトランザクションtxi,jをともなうさらなるアクションai,jのサブトランザクションtxiなどを含む。遂行aiの認可者は、遂行の入力の契約が生成されたときにそれらの認可者がアトミック性を約束されたのでサブトランザクションtxiがアトミックに実行されることに注意を払う可能性がある。同様に、ai,jの認可者は、txi,jのアトミック性に注意を払う。txi,jはtxiのサブトランザクションであるので、aiの認可者もtxi,jがアトミックに実行されることに(推移的に)注意を払う。最上位のトランザクションtxに関しては、提出者がそのアトミック性に注意を払う。まとめると、(サブ)トランザクションtx...に関して、提出者815およびルートからサブトランザクションまでの経路上のすべての認可者811、819は、その(サブ)トランザクションtxのアトミック性に注意を払う。その他の関係者は、tx...がアトミックに実行されるかどうかを気にかけるべきでない。特に、関係者がサブトランザクションtxi1の利害関係者であるが、サブトランザクションtxi2の利害関係者でない場合、その関係者は、DAMLのプライバシーモデルが原因でその関係者がtxi2について知ることさえできないので、txi2がアトミックに実行されるかどうかを気にかけない。提出者のみが、すべての最上位のアクションがアトミックに実行されることに注意を払う。
さらに、j≠kであるものとして関係者がai,jおよびai,kの認可者であるが、aiの認可者ではない場合、その関係者は、2つのサブアクションがアトミックに実行されるか否かを気にかけてはならない。特に、そのような関係者の参加者は、中継者である必要がない。
アトミック性のこの概念を前提として、あらゆる参加者は、以下の議論が示すように、その参加者が注意を払うサブトランザクションのアトミック性をそれ自体保証することができる。
・参加者が、txの1つのサブトランザクションtx1が何らかのドメイン(たとえば、第1のドメインD1)において承認され、txの別のサブトランザクションtx2が別のドメイン(たとえば、第2のドメインD2)において拒否される場合、マルチドメイン(サブ)トランザクションtxのアトミック性が破られたとみなす。
・シングルドメインサブプロトコルが1つのドメイン内の完全性およびアトミック性を保証するので、D1 = D2またはtx1 = tx2、つまり、単一のドメインまたは単一のサブトランザクションに関する競合を考える必要がない。特に、我々は、中継者ではない参加者を無視し得る。
・したがって、D1≠D2であり、結果として、tx1≠tx2である。アトミック性の違反は、トランザクションtx全体に関するすべての期待される確認がドメインD1に届いたが、D2には届かなかった場合にのみ起こり得る。時間内に確認応答を転送することによって参加者がこの状況を回避することを示せば十分である。
・txiが、確認応答がD1に届いたが、D2には届かなかったいずれかのサブトランザクションであるものとする。Diが、txiが送信されるドメインを表すものとする。中継者がトランザクションに関与するすべてのドメインに接続されるので、中継者は、特に、Diに接続される。中継者がDiを介してリソース要求およびペイロード要求を受信したので、中継者は、Diを介して送信された「allStakeholders」リストの一部である。txiに関する確認がD1に届いたので、それらの確認は、確認期限の前にドメインDi上で送信されたはずである。メッセージブローカがメッセージングAPIを正しく実施すると仮定すると、中継者は、これらの確認を時間内に受信した。中継者は、これらの応答をすべてのドメイン、特に、D2に転送する。したがって、応答は、ドメインD2に到着する。
・中継者が確認応答を時間内に転送し得ることを示すことが残っている。中継者は、(D2のメッセージブローカによって測定される)時間
confirmationDeadlinei +Δmax + skew
の前にドメインDiからそれらの確認応答を受信する。したがって、参加者がそれらの確認応答を直ちに転送する場合、それらの確認応答は、
confirmationDeadlinei + 2*Δmax + skew
の前にD2のメッセージブローカに届く。中継者は、確認応答を処理する間に、
confirmationDeadlinei≦confirmationDeadline2 + confirmationTolerance
2 *Δmax + confirmationTolerance + skew≦confirmationDeadlineOffset2
であることを検査した。decisionTime2 = confirmationDeadline2 + confirmationDeadlineOffset2であるので、我々は、所望の関係
confirmationDeadlinei + 2 *Δmax + skew≦decisionTime2
を有する。
マルチドメイントランザクションにおけるタイムアウト
様々なドメイン803、805におけるタイムアウトを選択するのは、パラメータを選択する提出者815である。したがって、提出者815が、それ自体のために提出者ノード815が設定するタイムアウト以内に提出者815が転送を実際に実現することができるようなパラメータを選択すべきであるので、提出者815が、ドメイン間で確認応答を転送する(853、854)責任を負う。トランザクションのすべてのその他の参加者811、819は、それらの参加者がそれらの参加者のそれぞれのタスクを時間内に行い、トランザクションへのそれらの参加者の関心を押し通すことができる可能性が高いようなタイミングパラメータを提出者815が選択したかどうかを検査するだけである。
それにもかかわらず、タイムアウトが起こる可能性がある。参加者811、819は、それらの参加者が確認のペイロード833、837を受信するときにのみトランザクションのマルチドメインの性質に気付くが、それは、これが期待される確認のリストおよび要求IDのリストが送信されるときだからである。したがって、この節は、確認応答851、852のタイムアウトのみに焦点を絞り、要求のペイロードのタイムアウトを無視する。
同じドメインの確認が確認期限845、846に参加者からないことに参加者811、819が気付く場合、参加者811、819は、シングルドメイントランザクションと同様に適切なドメインにおいて紛争を起こすことができる。確認応答が別のドメインからないことに参加者が気付く場合、参加者811、819は、ローカルのドメイン803、805において提出者815に対して紛争を起こすことができる。これは、提出者815を、ドメイン803、805をまたがって確認を転送する(853、854)主な責任のあるノードにする。逆に、すべてのその他の中継者は、それら自身の利益のためにそのようにする可能性があるが、そのようにする義務はない。たとえば、別のドメインの参加者がその参加者の確認を時間内に送信しなかったことが原因であり、たとえそれが提出者の責任でない場合も、紛争は提出者815を対象とする。
そのとき、提出者815自体が、その他のドメインにおいて紛争を起こすことができる。たとえ提出者が後者の紛争に勝ち、前者の紛争に負けるとしても、提出者は、2つの紛争の影響が打ち消さないリスクを負う。
タイムアウトが起こる場合、トランザクションは、アトミックに実行されない可能性がある。前の節で検討されたように、あらゆる参加者811、819は、その参加者が関心のあるアトミック性の度合いを保証することができる。しかし、参加者811、819は、マルチドメイントランザクションのいくつかのドメイン803、805に関与し、それでも、(たとえば、すべてのその参加者のビューが単一のドメインにおいて実行され、したがって、その参加者が中継者でないため)そのアトミック性に関心がない可能性がある。そのような場合、参加者811、819は、トランザクションがアトミックでないことを観測する可能性がある。
紛争の規則に応じて、参加者811、819は、成功したトランザクションと失敗したトランザクションとの両方を考えなければならない可能性がある。より正確に言えば、トランザクションのあらゆる影響(契約が生成または実現されること)は、常駐先ドメインに結びつけられる。影響は、その他のドメインの結果と無関係に、トランザクションが常駐先ドメインにおいて承認されるやいなや発生する。
しかし、タイムアウトは、二重支払いの機会を生じない、つまり、あらゆる契約が単一のドメイン803、805にのみあるとき、二重支払いに関与する2つのトランザクションは、同じドメインにおいて実行されなければならない。すべての利害関係者が契約の状態について常に同意するので、すべての利害関係者は、第2のトランザクションに関して未払いの契約について嘘をつかなければならない。
マルチドメイントランザクション内の不正行為の検出
シングルドメイントランザクションと同様に、参加者は、マルチドメイントランザクション内で不正を働き得る。この節は、マルチドメイントランザクションに固有の不正行為の場合を特定する。シングルドメイントランザクションで起こり得る不正行為に対する対策は、同じままである。
i. 一貫性がない情報
リソース要求831、835および要求のペイロード833、837のメッセージがドメイン803、805に分けられるので、メッセージングAPIは、すべての参加者が同じメッセージの部分を受信することをもはや保証することができない。詳細には、提出者815が、異なるドメイン803、805に一貫性がない情報を送信する可能性がある。参加者のノード811、819は、以下の不整合を検出し、それらのドメインにおいて適切な紛争を起こすことができる。紛争の規則は、すべてのこれらの場合に適用されるようにやはり拡張される必要がある。
・LET: あらゆる参加者は、ペイロード要求からのLETをその確認応答に含める。参加者が確認応答を処理するとき、その参加者は、LETがその参加者が見たLETと同じであることを検査する。提出者が異なるビューに関するLETを送信する場合、少なくともすべての中継者が違いに気付く。(中継者のいずれも検査しない場合、不正を働かない参加者は、アトミック性に、つまり、LETの一貫性に注意を払わない。)
・リモート要求ID: すべての参加者は、すべての要求IDからトランザクション識別子を導出し、それらの参加者は、そのトランザクション識別子をそれらの参加者の確認応答に使用する。参加者が要求IDの異なるリストを受信する場合、導出されるトランザクション識別子が異なる。したがって、その他の参加者は、これらの確認を承認せず、参加者(同じドメイン)または提出者(その他のドメイン)に対して(形式が整っていないことかまたは確認がないことかどちらかの理由で)紛争を起こす。同じドメインの場合は、メッセージブローカが指定されたようにメッセージングAPIを実装しない場合にのみ起こり得る。
・期待される確認: あらゆる確認応答は、期待される確認のハッシュを含む。期待される確認の異なるリストは、異なるハッシュを有し、したがって、整っていない形式の確認応答についての紛争を生じる。
・確認許容範囲: 確認許容範囲は、確認応答に含まれ、参加者は、確認内の値がそれらの参加者が受信したリソース要求と同じであることを検査する。異なる確認許容範囲は、したがって、整っていない形式の確認応答についての紛争を生じる。
ii. 整っていない形式のパラメータ
マルチドメイントランザクションにおいて、提出者は、シングルドメイントランザクションに関するパラメータに加えて以下のパラメータを指定する。
・タイミングパラメータ「confirmationDeadlineOffset」(ビュー毎)および「confirmationTolerance」
・期待される確認内のドメインID
・リモート要求ID
「confirmationDeadlineOffset」は、ドメイン毎に選択され、一方、その他のパラメータは、トランザクション全体のために選択される。これらのパラメータは、あらゆる参加者が確認要求を処理している間に検査する制約を受ける。制約が破られる場合、参加者は、整っていない形式のメッセージが送信されたドメインにおいて整っていない形式のメッセージが原因で提出者に対する紛争を起こす。
ほとんどの検査は、参加者のローカルの知識のみを含み、したがって、確実に実行され得る。唯一の例外は、異なるドメインのサブビューを有するビューに対して中継者が実行する検査である。中継者が確認期限までに検査のために必要とするその他のドメインからのメッセージをその中継者が受信しなかった場合、中継者は拒否を送信する。しかし、物理的なタイムスタンプが少なくともskew +「confirmationTolerance」+Δmaxだけすべての確認期限の前にあることの検査は、正常なネットワークの動作の下で、中継者が確認期限までにすべての必要なメッセージを受信し終えていることを保証する。そうでない場合、中継者は、提出者に対して要求のペイロードがないことについて紛争を起こし得る。検査は、ネットワーク遅延と無関係に、すべての不正を働かない中継者が同じ評決に達することも保証する。(リソース要求がメッセージブローカから中継者まで移動するのにskew +「confirmationTolerance」+Δmaxよりもかかる場合、中継者は、メッセージブローカまたはそのISPとのSLA紛争を起こすべきである。)
契約のあらゆる利害関係者は、ビューが正しいドメインを介して送信されることをさらに検査する。遂行に関して、入力の契約がドメインにないことが起こる可能性がある。これは、正常な動作の下で、つまり、悪意なしに起こる可能性がある。この検査が失敗する場合、紛争は起こされない。その代わりに、利害関係者は、ドメイン変更プロトコルと同様に、契約の現在の常駐先を含む拒否を送信する。
ドメインの変更との相互作用
アトミック性は、マルチドメイントランザクションの中継者が確認が時間内に転送されることを積極的に保証しなければならないのでそれらの中継者に負担をかける。したがって、参加者811、819は、いずれのマルチドメイントランザクションにおいても中継者として働くことを控えたい可能性がある。しかし、参加者が単一のドメインにのみ接続されるのでない限り、参加者は、これを保証し得ない。
アイデンティティマネージャおよび複数のドメイン
1つまたは複数のアイデンティティマネージャノード170、270が、提供されることが可能であり、一部の例においては、異なるドメインが、それぞれのアイデンティティマネージャ170、270を有する。アイデンティティマネージャノード(およびアイデンティティマネージャシステム全般)は、同期システムと同じ信頼およびトポロジーを持ち得る。システムは、ドメインが任意のノードによって生成されることが可能であり、参加者がドメインの運用者から認可を得る限り任意の参加者ノードが任意のドメインに接続することが可能であるように構成される可能性がある。つまり、システムは、単一の大域的なアイデンティティマネージャを持たないかまたは必要としない。
参加者ノード110、120、210、220、811、815、819、外部ノード130、230、813、817、および/または仲介者280の各々は、アイデンティティ提供サービスクライアント(IPSクライアント)と呼ばれるローカルコンポーネントを有する可能性がある。IPSクライアントは、ドメイン(および/または参加者)のアイデンティティ情報を読み、検証するためにアイデンティティマネージャ170、270との接続を確立した。IPSクライアントは、1つまたは複数のドメインのアイデンティティマネージャ170、270によって提供されるドメインのトポロジー情報および公開鍵への集約されたアクセスを提供する読み取りAPIを公開する。
アイデンティティマネージャ170、270は、何らかのプロセスを通じて鍵および証明書を受信し、参加者ノードまたはその他のドメインのエンティティのIPSクライアントに情報を提示する前に正当化する理由を評価する。IPSクライアントは、情報を確かめる。IPSクライアントの読み取りAPIのローカルの消費者(consumer)は、正当化する理由を確かめることなく提供された情報を信頼し、同期とアイデンティティ管理との分離につながる。
アイデンティティマネージャ170、270およびIPSクライアントは、以下の考慮事項のうちの1つまたは複数を用いて設計される可能性がある。
・参加者への関係者のマッピング。特定の時間に状態を問い合わせ、関係者の知られている識別子を1組の参加者に関連付け、ローカルの参加者を1組のホストされる関係者に関連付ける更新のストリームに申し込む。1組の参加者へのマッピングは、複数の参加者を使用する関係者に関する高レベルの要件を満たす。
・参加者の資格。特定の時間に状態を問い合わせ、信頼できない(信頼レベル0)かまたは信頼できる(信頼レベル1)かのどちらかを示す参加者の信頼レベルについて私に知らせる更新のストリームに申し込む。
・参加者の関係の資格。関係者と参加者の関係が、資格を与えられ、(確認を含む)提出、確認、および観察(読み取りのみ)に制限される。これは、読み取りのみの参加者に関する高レベルの要件をやはり満たす。
・鍵への参加者のドメインを意識したマッピング。特定の時間に状態を問い合わせ、同期ドメイン毎に1組の鍵に参加者をマッピングする更新のストリームに申し込む。
・ドメインのエンティティの鍵。現在の状態を問い合わせ、ドメインのエンティティの鍵に関する更新のストリームに申し込む。
・鍵のライフタイムおよび目的。受信された任意の鍵に関して、その鍵が何のために使用され得るか、その鍵がどの暗号プロトコルに関連するか、およびその鍵がいつ失効するかを知る。
・署名の検査。ブロブ、IPSから取得された鍵、および署名が与えられると、署名が、特定の時間にそれぞれの鍵によって署名された、与えられたブロブに関して有効な署名であることを確かめる。
・不変性。すべての鍵の履歴は、それが参加者またはドメインのエンティティのログを監査するために使用され得るように監査ログと同じ期限内は保存される。
・証拠。アイデンティティマネージャから受信された任意のデータに関して、法的紛争における主張を証明するための1組の関連する証拠を得る。関連する証拠は、そうでなければ不透明なブロブの定義に関する資料を読んで調べるために使用され得るディスクリプタを含む。
・競争条件なし。飛行中の鍵の変更(in-flight key change)が原因であるトランザクションの妥当性に関する不同意が存在し得ないようにトランザクションに関連して鍵の妥当性についての確実性を確認する。
・関係者に関する問い合わせ。不透明な問い合わせステートメントを使用して、関係者に関してアイデンティティマネージャに問い合わせ、特定の参加者ノード/IPSクライアントに知られていないプライバシーポリシーに基づいて結果を受信する。
・関係者メタデータ。表示する目的で関係者に関連するメタデータにアクセスする。
・同等の信頼の仮定。参照アイデンティティ管理サービスのフェデレーション(federation)プロトコルは、2者の能力の間の不一致が存在しないように相互運用プロトコルと同等の信頼の仮定に基づく必要がある。
アイデンティティマネージャシステムは、以下のさらなる考慮事項を用いて構築され得る。同期プロトコルが、アイデンティティプロトコルと分けられる。しかし、同期プロトコルの構成可能性のプロパティを利用するために、同等の手法が、アイデンティティに関して必要とされる。したがって、場合によっては、同期のために依拠され得る単一の大域的に信頼されるエンティティが存在しないとすれば、同様に、場合によっては、アイデンティティを確立するための単一の大域的に信頼されるエンティティを持つことができず、これは、我々を第1の原理に導く。
大域的な同期が実際に機能するために、単一のトラストアンカーは存在し得ない。
暗号鍵のペアは、公開鍵のフィンガープリントによって一意に特定され得る。関連する秘密鍵を所有することによって、エンティティは、エンティティが公開鍵の所有者であることを署名によって曖昧性を残さず常に証明することができる。この原理は、参加者の活動を確かめ、認可するためにシステムにおいて使用される。したがって、我々は、第2の原理を導入することができる。
参加者は、認可をすることができ、認可が(知られている鍵を用いて誰かによって)確かめられ得る誰かである。
つまり、参加者は、鍵またはグループをなすことが知られている1組の鍵を有するエンティティ/ノードである。しかし、これは、誰が鍵を所有しているかの知識と必ずしも同じではない。所有権は、現実の世界の抽象的な側面であり、同期自体にとって重要でない。現実の世界の所有権は、何らかの共有されたデータの意味の解釈にとってのみ重要であり、データ処理自体の意味の解釈にとっては重要でない。これは、第3の原理につながる。
システムのアイデンティティおよび法的アイデンティティ(legal identity)の別々の証明(または暗号学的アイデンティティ(cryptographic identity)およびメタデータの分離)
暗号鍵は、鍵に、別の鍵に関連付けられる何らかの所有権または何らかの事実を証明する証明書に署名させることによって信頼の連鎖を構築するために使用され得る。しかし、そのような連鎖のルートには、常にルート鍵がある。ルート鍵自体は、証明されず、法的所有権は確かめられ得ない、つまり、参加者は、ただそれを信じる必要がある。例として、エンティティがエンティティのデバイスのローカルの証明書ストアを見る場合、エンティティは、特定のルートが指名された認証局によって所有されることを信頼する必要がある。そのような信頼は、オペレーティングシステムのプロバイダが正当な鍵のみを含めたというオペレーティングシステムのプロバイダへの信頼に根ざす。
したがって、証明書による暗号鍵への法的アイデンティティの間のいずれのリンクも、ルート鍵を制御するエンティティが不正を働かないと信じることに基づいており、信頼のルートに結合されたあらゆる者が適切に入念に審査されたことを保証される。したがって、エンティティは、法的アイデンティティが適切に関連付けられることを信じる必要がある可能性があるが、絶対的な感覚でそれを確かめることは非常に難しく、特にオンラインでは不可能である。
別の関連する側面は、アイデンティティの要件が非対称なプロパティであることである。大きな会社はそれらの名前(BANK)によって知られることを望むが、個人は、より閉鎖的である傾向があり、それらのアイデンティティが本当に必要な場合(GDPR、HIPAA、機密情報、銀行の秘密)にのみ開かされることの方をより望む。また、たとえば、無記名債券を見ることによって、所有者は、債務者が所有者に対して持つよりもずっと高い関心を債務者のアイデンティティに対して持つ。債務者が悪人または詐欺師であると判明する場合、所有者は、所有者のお金および投資資金を失う可能性がある。対照的に、債務者は、一部の規制上の理由を除いて、債務者が債券を誰に返済しているのかあまり気にしない。したがって、我々は、第4の原理を得る。
台帳上のアイデンティティは、プライバシーおよび公表がケースバイケースで慎重に重み付けされる必要がある非対称的問題である。
大域的な構成可能なアイデンティティシステムを構築するために、アイデンティティの方式は、大域的に一意の識別子を生成する必要がある。これは、大域的システムがアイデンティティのプロバイダの間の協力またはすべての参加者の間の合意を必要とし、同期プロトコルとの統合が難しいフェデレーションを避けることを可能にする。
我々は、何らかの暗号方式の公開/秘密鍵のペアを指すために
Figure 2022508948000003
を使用し、上付き文字xは、鍵の使用のコンテキストを与え、下付き文字kは、鍵を区別するために使用される。
以降、我々は、鍵のペア(pk, sk)を指すために公開鍵のフィンガープリントIk = fingerprint(pk)を使用する。これに基づいて、我々は、Ik、それぞれ、(pk, sk)を、以下でアイデンティティのルート鍵のペアとして使用する。その複数が存在することが可能であり、我々は、そのような鍵の所有者が誰であるかに関していかなるステートメントも出さない。
ここで、我々は、大域的に一意の識別子としてタプル(X, Ik)を導入し、Ikは、アイデンティティのルート鍵の既に導入されたフィンガープリントを指し、Xは、原理的には、我々が等しいことを確かめることができるような何らかの抽象的な識別子である。したがって、X = YおよびIk = Ilである場合、(X, Ik) = (Y, Il)である。識別子は、定義により大域的に一意であり、つまり、我々は、2つの識別子が衝突する場合、それらの識別子が定義により等しいと定義したので、衝突は存在し得ない。したがって、アイデンティティの鍵Ikは、名前空間を張り、その名前空間内で定義による衝突がないことを保証する。
Scalaのコードの一例のプロジェクト(project)内の一意識別子は、以下のように定義される。
/**公開鍵のフィンガープリントによって張られる名前空間
*
*これは、フィンガープリントが公開鍵に対して一意であるという仮定に基づく*/
final case class Namespace(fingerprint: Fingerprint)
/**名前空間内の一意識別子*/
final case class UniqueIdentifier(id: Identifier, namespace: Namespace) {
我々は、大域的に一意の識別子を使用して参加者ノードN=(N, Ik)、関係者P=(P, Ik)、およびドメインのエンティティD=(D, Ik)を特定する(つまり、Xは(X, Ik)の省略形である)。関係者Pおよび参加者ノードNに関して、我々は、プライバシーの理由で、十分に長い乱数を使用すべきである。ドメインDに関して、我々は、読むことができる名前を使用する。
代替的なドメインの構築
上述の開示は、各ドメインがそのドメイン内またはそのドメイン中でトランザクションを行うための1組のコンポーネントを含み得ることを明記する。たとえば、ドメインは、ドメイン内の参加者ノード(たとえば、ノード110、120、210、220、811、815、819)によって提出されたトランザクションを順序付けるためのシーケンサまたは外部ノード(たとえば、ノード130、230、813、817、1018)と、ドメイン内の確認を集約し、確認の忠実さを保証するための仲介者ノード280とを含み得る。ドメインの代替的な構築も可能であり、本開示によって想定されることを理解されたい。
一部の例において、仲介者ノード280の機能は、上述のものの代替に実装され得る。一例において、仲介者ノードの機能は、(ビザンチンフォールトトレラント性のあるステートマシンレプリケーションを使用するなどして)レプリケーションサーバ上のフォールトトレラントサービスによってレプリケーションされる。別の例において、仲介者ノードの機能は、より強いプライバシーおよび機密性を提供するために1つまたは複数のノードのソフトウェアガードエクステンションズ(SGX)のエンクレーブ内で実行され得る。一部の例において、そのようなエンクレーブは、外部ノードに関連付けられる可能性がある。
本開示は、各ドメインまたはドメインのサブセットが独自の合意プロトコルを実行する分散型システム(たとえば、ブロックチェーン)を含む可能性があることを想定する。この場合、トランザクションを順序付けるためにシーケンサまたは外部ノード(たとえば、ノード130、230、813、817、1018)に頼る代わりに、ドメイン内の参加者ノード(たとえば、ノード110、120、210、220、811、815、819)は、そのドメイン内で提出されたトランザクションを順序付けるおよび/または検証するために分散型システム(たとえば、ブロックチェーン)のトランザクション順序付けプロトコルに依拠する可能性がある。さらに、上述のように、トランザクションは、異なるドメインにおいてまたはドメインにまたがって発生し得る(たとえば、マルチドメイントランザクション)。したがって、本明細書において開示された同期プロトコルは、異なる分散型システム(たとえば、ブロックチェーン)にまたがる仮想台帳を同期するために利用され得る。その意味で、本明細書において開示された同期プロトコルは、異なる分散型システムを同期するようにして構築されることが可能であり、それぞれが自身の合意および/またはトランザクション順序付けプロトコルを実行する異なる分散型システムのウェブを形成する。
特に、そのような例は、異なるドメインおよびシステム間の単なる相互運用性以上のものである。トランザクションプロトコルは、ドメインのドメインフラストラクチャがスワップまたは変更されることが可能であり、ドメインの異なる実装が接続されることが可能であるように仮想台帳を形成するために同じままであることができる。
一例において、上述の分散型システムの合意プロトコルは、ビザンチンフォールトトレラント性があるプロトコル(たとえば、BFT、PBFT、aBFTなど)である可能性があり、その合意プロトコルは、プルーフオブワーク(POW)またはプルーフオブステーク(POS)と同様にシビル耐性の特徴と一緒に使用される合意プロトコルであることが可能であり、またはその合意プロトコルは、当技術分野において認められた別の合意プロトコルであることが可能である。したがって、本明細書において開示された同期プロトコルは、異なる分散型システムの間でトランザクションを同期し、異なる分散型システムの仮想台帳を形成するためにその他の分散型システム(たとえば、ブロック)と連携して働くことができることが想定される。
100 システム
102 プロセス
104 ネットワーク
110 提出ノード
120 受信者ノード
122 第2の受信者ノード
130 外部ノード
140 提案されるトランザクション
142 暗号化されていないサブメッセージ
144 暗号によって保護されたサブメッセージ、暗号化されたサブメッセージ
150 確認
152 確認
160 台帳
170 アイデンティティマネージャ、アイデンティティマネージャノード
200 システム
210 提出ノード
220 受信者ノード
222 受信者ノード
224 受信者ノード
230 外部ノード
240 提案されるトランザクション
242 暗号化されていないサブメッセージ
244 暗号化されたサブメッセージ
246 暗号化されたサブメッセージ
250 確認
252 確認
260 台帳
262 台帳
264 台帳
270 アイデンティティマネージャ、アイデンティティマネージャノード
280 仲介者、仲介者ノード
300 例
302 提案されるトランザクション、PaintOfferプロセス
310 サブアクション、IOUの転送
312 IOU
320 PaintAgree
330 参加者A
340 参加者P
342 銀行
502 プロセッサ
503 メモリ
504 命令、プログラムコード
506 データ
508 ネットワークインターフェースデバイス
509 分散型台帳インターフェースデバイス
510 ネットワークインターフェースデバイス
512 ユーザインターフェース
514 出力
516 参加者
610 移動元ドメインのメッセージブローカ、メッセージブローカドメイン1
612 利害関係者
614 開始者ノード、開始者
616 移動先ドメインのメッセージブローカ
621 転出要求
623 転出要求確認
624 転出要求
625 転入要求TI、転入メッセージ
630 排他性タイムアウト
803 ドメイン1
805 ドメイン2
811 参加者1
813 メッセージブローカ
815 提出ノード、提出者
817 メッセージブローカ
819 参加者2
831 リソース要求
833 要求のペイロード
835 リソース要求
837 要求のペイロード
845 確認期限
846 確認期限
847 判断時間
848 判断時間
851 確認応答
852 確認応答
853 転送
854 転送
909 台帳有効時間(LET)
911 論理的時間オフセット
913 論理的時間オフセット
915 確認期限のオフセット
917 確認期限のオフセット
921 論理的時間
923 論理的時間
925 許容範囲
927 許容範囲
953 確認許容範囲
1000 単一のドメイン
1001 引き渡し対支払い(DvP)の例
1010 アリス
1012 ボブ
1014 銀行
1016 株式登録簿SR
1018 シーケンサ、外部ノード
1020 仲介者
1031 IOU契約
1033 株式契約
1035 DvP契約
1041 トランザクションの確認要求
1051 妥当性の検査
1053 妥当性の検査
1055 妥当性の検査
1057 妥当性の検査
1061 応答
1062 応答
1063 応答
1064 応答
1071 確認要求
1072 確認要求
1073 確認要求
1074 確認要求
1300 確認要求の状態遷移図
1410 第1のボックス
1410' ボックス
1420 第2のボックス
1510 第1のアクション、PaintOfferの受け付け
1520 PaintAgreementの生成
1530 アクション、IOUの転送
1540 アクション、IOUの転送
1610 第1のビュー
1610' 第1のビューのコア
1620 第2のビュー
1630 第3のビュー
1700 候補データ構造
1701 フェンス塗装トランザクション
1710 PaintOfferの受け付け
1711 PaintOfferの受け付け
1720 IOUの転送
1721 IOUの転送
1730 サブビュー
1800 候補表現
1900 候補表現
1913 利害関係者の情報
1923 利害関係者の情報
1933 利害関係者の情報
1950 その他の情報

Claims (62)

  1. 参加者が複数いるプロセスをスケジューリングし、検証する方法であって、
    前記参加者が複数いるプロセスの参加者に関連する提出ノードによって、暗号によって保護されたメッセージを1つまたは複数の受信者ノードに送信することによって、提案されるトランザクションを提出するステップであって、前記暗号によって保護されたメッセージが、少なくとも、外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも前記外部ノードからプライバシーを守るための暗号によって保護されたサブメッセージを含む、ステップと、
    前記外部ノードによって、その他のトランザクションに対する前記提案されるトランザクションの順序を決定するステップと、
    前記受信者ノードの少なくとも一部によって、前記暗号によって保護されたメッセージを検証するステップと、
    前記受信者ノードの少なくとも一部から前記暗号によって保護されたメッセージの妥当性の確認を受信するステップと、
    確認条件を満たす前記受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、前記提案されるトランザクションを確認されたトランザクションとして確定するステップと、
    前記外部ノードによって決定された前記順序に従って、前記確認されたトランザクションを分散型台帳に書き込むステップとを含む、方法。
  2. 前記1つまたは複数の受信者ノードが、少なくとも第1の受信者ノードおよび第2の受信者ノードを含み、前記暗号によって保護されたサブメッセージが、前記第1の受信者ノードによって読み取り可能であるが、前記第2の受信者ノードによって読み取り可能でない請求項1に記載の方法。
  3. 前記第1の受信者ノードが、前記暗号によって保護されたサブメッセージを復号するための復号鍵にアクセスすることができるが、前記第2の受信者ノードが、前記復号鍵にアクセスすることができない請求項2に記載の方法。
  4. 前記暗号によって保護されたメッセージが、前記外部ノードに送信され、前記外部ノードが、前記暗号によって保護されたメッセージを前記1つまたは複数の受信者ノードに送信する請求項1に記載の方法。
  5. 前記1つまたは複数の受信者ノードが、前記1つまたは複数の受信者ノードのアイデンティティをその他の受信者ノードから隠すために仮名性のあるアドレスを使用する請求項1から4のいずれか一項に記載の方法。
  6. 前記提出ノードと仮名性のあるアドレスとの間および前記1つまたは複数の受信者ノードと仮名性のあるアドレスとの間の関連付けを維持するアイデンティティマネージャをさらに含む請求項5に記載の方法。
  7. 前記暗号によって保護されたメッセージの妥当性を決定することが、前記暗号化されていないサブメッセージに基づく請求項1から6のいずれか一項に記載の方法。
  8. 前記暗号化されていないサブメッセージに基づいて、前記暗号によって保護されたメッセージの妥当性を決定することが、前記提案されるトランザクションのトランザクション時間が前記外部ノードによって与えられたタイムスタンプの期間内にあるかどうかを判定することを含む請求項7に記載の方法。
  9. 前記提案されるトランザクションの前記トランザクション時間が、タイムスタンプの範囲である請求項8に記載の方法。
  10. 前記暗号によって保護されたメッセージの妥当性を決定することが、前記暗号によって保護されたサブメッセージに基づく請求項1から9のいずれか一項に記載の方法。
  11. 前記暗号によって保護されたサブメッセージに基づいて前記暗号によって保護されたメッセージの妥当性を決定することが、前記提案されるトランザクションが前のトランザクションと競合するかどうかを特定することを含む請求項10に記載の方法。
  12. 暗号化されたサブメッセージに基づいて前記暗号によって保護されたメッセージの妥当性を決定することが、前記提案されるトランザクションの形式が整っているかどうかを判定することを含む請求項10または11に記載の方法。
  13. 前記暗号によって保護されたサブメッセージに基づいて前記暗号によって保護されたメッセージの妥当性を決定することが、前記提案されるトランザクションが1組の準拠規則に準拠するかどうかを判定することを含む請求項10から12のいずれか一項に記載の方法。
  14. 前記提案されるトランザクションが前記前のトランザクションと競合するかどうかを特定することが、前記前のトランザクションが前記分散型台帳に記録されたかどうかを検査することを含む請求項11に記載の方法。
  15. 前記暗号によって保護されたメッセージの妥当性を決定することが、前記暗号化されていないサブメッセージおよび前記暗号によって保護されたサブメッセージに基づく請求項1から14のいずれか一項に記載の方法。
  16. 妥当性を決定することが、前記暗号化されていないサブメッセージが前記暗号によって保護されたサブメッセージと一貫性があるかどうかを判定することを含む請求項15に記載の方法。
  17. 前記確認条件が、
    前記参加者が複数いるプロセスの参加者に対応する各受信者ノードから確認を受信すること、
    割り当てられた時間期間内に指定された量の確認を受信すること、
    前記1つもしくは複数の受信者ノードの指定されたサブセットから確認を受信すること、または
    暗号学的証明器またはトラステッドハードウェアなどの確かめることが可能なアテステーションメカニズムから確認を受信すること
    のうちの1つまたは複数である請求項1から16のいずれか一項に記載の方法。
  18. 前記1つまたは複数の受信者ノードがそれぞれの受信者ノードに関する期待されるアクションに従って働かないかどうかを判定する裁定者ノードをさらに含む請求項1から17のいずれか一項に記載の方法。
  19. 前記裁定者ノードが、
    前記提案されるトランザクションの形式が整っているかどうか、
    前記1つもしくは複数の受信者ノードによって提供された前記確認が1つもしくは複数のその他の確認と競合するかどうか、および
    前記提案されるトランザクションが容量の取り決めの枯渇を誤って示すかどうかのうちの1つまたは複数を判定する請求項18に記載の方法。
  20. 前記裁定者ノードが紛争解決プロセスを実行するステップをさらに含む請求項18に記載の方法。
  21. 前記提案されるトランザクションの形式が整っているかどうかを判定することが、
    前記提案されるトランザクションが前記準拠規則に準拠すること、
    前記提案されるトランザクションが前記1つもしくは複数の受信者ノードの必要とされるサブセットによって認可されること、および
    前記提案されるトランザクションがリソースの要件の正しい宣言を有することのうちの1つまたは複数を検査することを含む請求項19に記載の方法。
  22. 前記1つまたは複数の受信者ノードのうちの第1の受信者ノードが、前記紛争解決プロセスを開始するために前記裁定者ノードに前記提案されるトランザクションを転送する請求項18から21のいずれか一項に記載の方法。
  23. 前記紛争解決プロセスが、前記提出ノードまたは前記1つもしくは複数の受信者ノードから決定された不正を働くノードに前記裁定者ノードが罰を科すことによって解決される請求項22に記載の方法。
  24. 前記罰が、
    前記不正を働くノードがトランザクションを提出する能力を取り除くこと、
    前記不正を働くノードに関連する前記提案されるトランザクションに、凍結されたものとしてフラグを立てること、
    前記裁定者ノードによって決定された、前記不正を働くノードに関するカスタムの罰、および
    ドメインの規則で定義された、前記不正を働くノードに関する罰のうちの1つまたは複数である請求項23に記載の方法。
  25. 前記裁定者ノードが、前記紛争解決プロセスの結果を前記提出ノードおよび/または前記第1の受信者ノードに伝達する請求項22から24のいずれか一項に記載の方法。
  26. 前記紛争解決プロセスが、ドメインの規則で定義される請求項22から25のいずれか一項に記載の方法。
  27. 前記第1の受信者ノードに加えてその他の受信者ノードが、1つまたは複数のメッセージを前記紛争解決プロセスのための証拠として前記裁定者ノードに提供する請求項22から26のいずれか一項に記載の方法。
  28. 前記提案されるトランザクションの前記順序を決定するステップが、前記暗号化されていないサブメッセージに基づく請求項1から27のいずれか一項に記載の方法。
  29. 前記提案されるトランザクションが、前記暗号によって保護されたメッセージが前記外部ノードによって受信される時間に対応する物理的なタイムスタンプを与えられる請求項28に記載の方法。
  30. 前記その他のトランザクションに対する前記提案されるトランザクションの前記順序が、前記物理的なタイムスタンプに基づく請求項29に記載の方法。
  31. 前記提案されるトランザクションの前記順序が、前記提案されるトランザクションに割り振られた論理的なタイムスタンプに基づく請求項1から30のいずれか一項に記載の方法。
  32. 前記論理的なタイムスタンプが、前記物理的なタイムスタンプの定義された時間期間内の時間に対応する、請求項29または30の記載を引用する場合における請求項31に記載の方法。
  33. 前記暗号によって保護されたサブメッセージが暗号化されたサブメッセージである請求項1から32のいずれか一項に記載の方法。
  34. 参加者が複数いるプロセスをスケジューリングし、検証する方法であって、
    前記参加者が複数いるプロセスの参加者に関連する提出ノードによって、暗号によって保護されたメッセージを1つまたは複数の受信者ノードに送信することによって、提案されるトランザクションを提出するステップであって、前記暗号によって保護されたメッセージが、少なくとも、外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも前記外部ノードからプライバシーを守るための暗号によって保護されたサブメッセージを含む、ステップと、
    前記外部ノードによって、その他のトランザクションに対する前記提案されるトランザクションの順序を決定するステップと、
    前記暗号化されていないサブメッセージに基づいて、前記参加者が複数いるプロセスの参加者に関連する1つまたは複数の受信者ノードを前記外部ノードによって決定するステップと、
    前記外部ノードによって少なくとも前記暗号によって保護されたサブメッセージを前記1つまたは複数の受信者ノードに送信するステップと、
    前記暗号によって保護されたサブメッセージの妥当性を前記1つまたは複数の受信者ノードによって決定するステップと、
    前記外部ノードによって前記1つまたは複数の受信者ノードから前記暗号によって保護されたサブメッセージの妥当性の確認を受信するステップと、
    前記確認を受信するべき1つまたは複数のノードを前記外部ノードによって決定するステップと、
    前記外部ノードによって前記確認を前記1つまたは複数のノードに送信するステップと、
    前記1つまたは複数の受信者ノードによって提供された前記確認が確認条件を満たすかどうかに基づいて、前記提出ノードによって前記提案されるトランザクションを確認されたトランザクションとして確定するステップと、
    前記外部ノードによって決定された前記順序に従って前記提出ノードによって前記確認されたトランザクションを分散型台帳に書き込むステップとを含む、方法。
  35. 前記1つまたは複数の受信者ノードによって提供された前記確認を仲介者ノードによって受信し、集約するステップをさらに含む請求項1から34のいずれか一項に記載の方法。
  36. 前記確認の集約を記憶するステップ、
    前記確認の前記集約を別のノードに送信するステップ、および
    前記確認の前記集約に基づいて前記提案されるトランザクションを確認するステップ
    のうちの1つまたは複数をさらに含む請求項35に記載の方法。
  37. 実行されるときにノードまたは一連の関連するノードに請求項1から36のいずれか一項に記載の方法を実行させるプログラム命令を含む有形のコンピュータ可読記録媒体。
  38. 参加者が複数いるプロセスにおいてトランザクションまたは一連のトランザクションをスケジューリングし、検証する方法であって、
    少なくとも、前記参加者が複数いるプロセスの参加者に関連する1つまたは複数の受信者ノードに部分的に暗号化されたメッセージを送信することによって、提案されるトランザクションを提出するステップであって、前記部分的に暗号化されたメッセージが、少なくとも、外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも前記外部ノードからプライバシーを守るための暗号化されたサブメッセージを含む、ステップと、
    前記受信者ノードから前記部分的に暗号化されたメッセージの妥当性の確認を受信するステップと、
    確認条件を満たす前記受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、前記提案されるトランザクションを確認されたトランザクションとして確定するステップと、
    その他のトランザクションに対する前記確認されたトランザクションの順序を前記外部ノードから受信するステップと、
    前記外部ノードによって決定された前記順序に従って、前記確認されたトランザクションを台帳に書き込むステップとを含む、方法。
  39. 前記1つまたは複数の受信者ノードが、少なくとも第1の受信者ノードおよび第2の受信者ノードを含み、前記方法が、前記暗号化されたサブメッセージを前記第1の受信者ノードに送信するステップであって、前記暗号化されたサブメッセージが、前記第1の受信者ノードによって制御される復号鍵によって復号可能であるが、前記第2の受信者ノードによって制御される復号鍵によって復号可能でない、ステップをさらに含む請求項38に記載の方法。
  40. 前記暗号化されたサブメッセージが、前記第2の受信者ノードに送信されない請求項39に記載の方法。
  41. 各受信者ノードの仮名性のあるアドレスを決定するステップをさらに含み、それぞれの仮名性のあるアドレスが、それぞれの受信者ノードのアイデンティティをその他の受信者ノードから隠すために使用される請求項38から40のいずれか一項に記載の方法。
  42. 実行されるときに提出ノードに請求項38から41のいずれか一項に記載の方法を実行させるプログラム命令を含む有形のコンピュータ可読記録媒体。
  43. 参加者が複数いるプロセスにおいて複数のトランザクションをスケジューリングし、検証する方法であって、
    ノードまたは一連の関連するノードによって、
    A. 前記参加者が複数いるプロセスを構成する前記複数のトランザクションに対応する複数のメッセージの順序を決定するステップと、
    B. 前記参加者が複数いるプロセスの参加者に関連する提出ノードから、部分的に暗号化されたメッセージを含む提案されるトランザクションを受信するステップであって、前記部分的に暗号化されたメッセージが、少なくとも、前記ノードまたは前記一連の関連するノードによって読み取り可能な暗号化されていないサブメッセージを含む、ステップと、
    C. 前記暗号化されていないサブメッセージに基づいて、前記参加者が複数いるプロセスの参加者に関連する受信者ノードを決定するステップと、
    D. 前記部分的に暗号化されたメッセージを前記受信者ノードに送信するステップと、
    E. 前記受信者ノードから前記部分的に暗号化されたメッセージの妥当性の確認を受信するステップと、
    F. 前記確認を前記提出ノードに送信するステップとを含む、方法。
  44. 前記受信者ノードの仮名性のあるアドレスを決定するステップをさらに含み、前記仮名性のあるアドレスが、前記受信者ノードのアイデンティティをその他のノードから隠すために使用される請求項43に記載の方法。
  45. 実行されるときにノードまたは一連の関連するノードに請求項42から44のいずれか一項に記載の方法を実行させるプログラム命令を含む有形のコンピュータ可読記録媒体。
  46. 前記分散型台帳が、前記提出ノード、前記外部ノード、および/または前記受信者ノードの間のメッセージを記録し、前記分散型台帳に書き込まれた前記確認されたトランザクションが、前記記録されたメッセージを含み、それによって、前記外部ノードによって決定された前記順序が、前記記録されたメッセージから立証されるかまたは導出され得る請求項1から36のいずれか一項に記載の方法。
  47. 前記分散型台帳が、それぞれが前記分散台帳のそれぞれの部分的なコピーを保有する複数の異なる台帳を含み、前記分散型台帳が、前記複数の異なる台帳の部分的な記録から構築される請求項1から36および46のいずれか一項に記載の方法。
  48. 前記外部ノードに関連する第1のドメインから目標外部ノードに関連する目標ドメインへの前記参加者が複数いるプロセスの変更をさらに含み、
    前記第1のドメインの前記外部ノードによって開始者ノードから転送要求を受信するステップであって、前記転送要求が、前記目標ドメインおよび前記目標外部ノードを指定する、ステップと、
    前記第1のドメインの前記外部ノードによって、前記提案されるトランザクションをホストするための前記目標ドメインおよび前記目標外部ノードの妥当性を決定するステップと、
    前記目標ドメインが前記提案されるトランザクションを正当にホストし得ると決定することに基づいて、前記目標ノードにおいて前記提案されるトランザクションをスケジューリングし検証する認可を、前記開始者ノードに送信するステップとを含み、前記提案されるトランザクションを順序付けるステップが、前記目標外部ノードによって実行される請求項1から36のいずれか一項に記載の方法。
  49. 前記提出ノードおよび/または前記受信者ノードにおいて前記転送要求を受信するステップと、
    前記提出ノードおよび/または前記受信者ノードにおいて、前記提案されるトランザクションをホストするための前記目標ドメインおよび前記目標外部ノードの妥当性を決定するステップと、
    前記目標ドメインが前記提案されるトランザクションを正当にホストし得ると決定することに基づいて、前記目標ノードにおいて前記提案されるトランザクションをスケジューリングし検証する認可を、前記開始者ノードに送信するステップとをさらに含む請求項48に記載の方法。
  50. 前記開始者ノードへの前記認可が、指定されたタイムアウト条件に関連付けられ、前記認可が、前記指定されたタイムアウト条件に基づいて有効および/または排他的である請求項48または49に記載の方法。
  51. 参加者が複数いるプロセスをスケジューリングし、検証する方法であって、前記参加者が複数いるプロセスが、
    第1の外部ノード、第1の受信者ノード、および前記参加者が複数いるプロセスの参加者に関連付けられる提出ノードに関連付けられる第1のドメイン、
    第2の外部ノード、第2の受信者ノード、および前記提出ノードまたは別個の中継ノードに関連付けられる第2のドメインを含み、前記提出ノードまたは前記中継ノードが、前記第1の外部ノードと前記第2のノードとの両方と通信し、
    前記方法が、
    - 前記提出ノードによって、前記第1のドメインのための第1の提案されるトランザクションおよび前記第2のドメインのための第2の提案されるトランザクションを決定し、前記第1の提案されるトランザクションおよび前記第2の提案されるトランザクションが、前記第1の受信者ノードおよび前記第2の受信者ノードを含む提案される参加者が複数いるトランザクションを共同で形成し、
    前記第1の提案されるトランザクションおよび前記第2の提案されるトランザクションの各々が、それぞれの受信者ノードへの暗号によって保護されたメッセージを含み、前記暗号によって保護されたメッセージが、少なくとも、それぞれのドメインの外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも前記外部ノードからプライバシーを守るための暗号によって保護されたサブメッセージを含む、ステップと、
    - 前記提出ノードおよび/または前記中継ノードによって、前記第1の提案されるトランザクションを前記第1の受信者ノードに提出し、前記第2の提案されるトランザクションを前記第2の受信者ノードに提出するステップと、
    - 前記第1の外部ノードによって前記第1の提案されるトランザクションに関する第1の順序を決定するステップと、
    - 前記第2の外部ノードによって前記第2の提案されるトランザクションに関する第2の順序を決定するステップと、
    - 前記第1の受信者ノードおよび前記第2の受信者ノードによってそれぞれの暗号によって保護されたメッセージを検証するステップと、
    - 前記第1の受信者ノードおよび前記第2の受信者ノードから前記暗号によって保護されたメッセージの妥当性の確認を受信するステップと、
    - 確認条件を満たす前記第1の受信者ノードおよび前記第2の受信者ノードからの前記確認を受信することに基づいて、前記提案される参加者が複数いるトランザクションを確認された第1のトランザクションおよび確認された第2のトランザクションの組合せとして確定するステップと、
    - 前記第1の確認されたトランザクションを前記第1の順序に従って前記第1のドメインに関連する分散型台帳に書き込み、前記第2の確認されたトランザクションを前記第2の順序に従って前記第2のドメインに関連する分散型台帳に書き込むステップとを含む、方法。
  52. 提出者ノードが、前記第1のドメインと前記第2のドメインとの間のメッセージを受信および送信するための中継者であり、前記方法が、
    提出ノードおよび/または前記中継ノードによって、前記暗号によって保護されたメッセージの妥当性の前記確認を前記第1の受信者ノードから前記第2のドメインの前記第2の外部ノードおよび/または前記第2の受信者ノードに送信するステップと、
    前記提出ノードおよび/または前記中継ノードによって、前記暗号によって保護されたメッセージの妥当性の前記確認を前記第2の受信者ノードから前記第1のドメインの前記第1の外部ノードおよび/または前記第1の受信者ノードに送信するステップとをさらに含む請求項51に記載の方法。
  53. 前記提案される参加者が複数いるトランザクションを確定する認可が、指定されたタイミング条件に関連付けられ、前記認可が、前記指定されたタイミング条件に基づいて有効および/または排他的である請求項51または52に記載の方法。
  54. 前記提案されるトランザクションが、複数のドメインにまたがる提案される参加者が複数いるトランザクションの一部であり、前記方法が、
    提案される参加者が複数いるトランザクションから、前記1つまたは複数の受信者ノードおよび前記外部ノードを含む第1のドメインに関する第1の提案されるトランザクション、ならびに少なくとも、1つまたは複数のその他の受信者ノードおよび別の外部ノードを含む別のドメインに関する別の提案されるトランザクションを決定するステップと、
    少なくとも、前記別のドメインの前記参加者が複数いるプロセスの参加者に関連する前記1つまたは複数のその他の受信者ノードに、別の部分的に暗号化されたメッセージを送信することによって前記別の提案されるトランザクションを提出するステップであって、前記別の部分的に暗号化されたメッセージが、少なくとも、前記別の外部ノードによって読み取り可能な暗号化されていないサブメッセージ、および少なくとも前記別の外部ノードからプライバシーを守るための暗号化されたサブメッセージを含む、ステップと、
    前記1つまたは複数のその他の受信者ノードから別の部分的に暗号化されたサブメッセージの妥当性の別の確認を受信するステップとをさらに含み、
    前記提案されるトランザクションを確定する前記ステップが、前記確認条件を満たす前記その他の受信者ノードの少なくとも一部からの1つまたは複数の確認を受信することに基づいて、前記別の提案されるトランザクションを別の確認されたトランザクションとして確定することをさらに含み、前記方法が、
    前記別のドメインにおけるその他のトランザクションに対する前記別の確認されたトランザクションの順序を前記別の外部ノードから受信するステップと、
    前記別の確認されたトランザクションを前記別の外部ノードによって決定された前記順序に従って台帳またはその他の台帳に書き込むステップとをさらに含む請求項38から41のいずれか一項に記載の方法。
  55. 前記第1のドメインの前記受信者ノードから前記別のドメインの前記その他の受信者ノードに前記暗号によって保護されたメッセージの妥当性の前記確認を送信するステップと、
    前記別のドメインの前記その他の受信者ノードから前記第1のドメインの前記受信者ノードに前記暗号によって保護されたメッセージの妥当性の前記別の確認を送信するステップとをさらに含む請求項54に記載の方法。
  56. 前記提案されるトランザクションおよび前記別の提案されるトランザクションを確定する認可が、指定されたタイミング条件に関連付けられ、前記認可が、前記指定されたタイミング条件に基づいて有効および/または排他的である請求項54または55に記載の方法。
  57. 前記暗号化されたサブメッセージが、前記提案されるトランザクションのすべての期待される確認を暗号学的に検証するための期待される確認データを含み、前記方法が、
    受信された1つまたは複数の確認の各々が前記期待される確認データと一致することを暗号学的に検証するための暗号関数を実行するステップをさらに含む請求項1から36、38から41、43、44、および46から56のいずれか一項に記載の方法。
  58. 前記期待される確認データが、公開鍵の形態であり、前記期待される確認が、前記公開鍵に対応する秘密鍵による電子署名を含む請求項57に記載の方法。
  59. 前記提案されるトランザクションが、それぞれが少なくとも1つの受信者ノードを含む複数のサブトランザクションを含み、各サブトランザクションが、前記サブトランザクションの含まれる受信者ノードによって読み取り可能であるが、前記サブトランザクションに関与しない受信者ノードによって読み取り可能でない内密の情報を有する対応する暗号によって保護されたサブメッセージに関連付けられ、
    前記暗号によって保護されたサブメッセージが、前記提案されるトランザクションの少なくとも1つのその他のサブトランザクションの内密の情報を少なくとも部分的に表す確認を検証するための内密の情報検証データを含み、前記方法が、
    少なくとも1つのその他のサブトランザクションの前記確認が前記内密の情報検証データと一致することを検証するステップをさらに含む請求項1から36、38から41、43、44、46から56のいずれか一項に記載の方法。
  60. サブトランザクションの前記確認が、少なくとも部分的に、前記サブトランザクションの前記内密の情報の暗号学的ハッシュを含む請求項59に記載の方法。
  61. 前記提案されるトランザクションが、複数の部分木を有する木構造を有し、部分木が、前記複数のサブトランザクションのうちの1つまたは複数を含む請求項60に記載の方法。
  62. 前記暗号によって保護されたサブメッセージが、前記提案されるトランザクションの前記複数のサブトランザクションの前記確認のうちのいずれか1つを暗号学的に検証するための内密の情報検証データを含む請求項59から61のいずれか一項に記載の方法。
JP2021547049A 2018-10-19 2019-10-21 プライバシーを守る検証およびコミットアーキテクチャ Pending JP2022508948A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862748315P 2018-10-19 2018-10-19
US201862748327P 2018-10-19 2018-10-19
US62/748,315 2018-10-19
US62/748,327 2018-10-19
PCT/US2019/057248 WO2020082078A1 (en) 2018-10-19 2019-10-21 Privacy preserving validation and commit architecture

Publications (2)

Publication Number Publication Date
JP2022508948A true JP2022508948A (ja) 2022-01-19
JPWO2020082078A5 JPWO2020082078A5 (ja) 2022-10-31

Family

ID=70279889

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021547049A Pending JP2022508948A (ja) 2018-10-19 2019-10-21 プライバシーを守る検証およびコミットアーキテクチャ

Country Status (9)

Country Link
US (2) US11575683B2 (ja)
EP (1) EP3857422A4 (ja)
JP (1) JP2022508948A (ja)
KR (1) KR20210082194A (ja)
CN (1) CN113196270A (ja)
AU (1) AU2019362088A1 (ja)
CA (1) CA3116763C (ja)
SG (1) SG11202103877SA (ja)
WO (1) WO2020082078A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805352B2 (en) 2017-04-21 2020-10-13 Netskope, Inc. Reducing latency in security enforcement by a network security system (NSS)
CN110428055A (zh) 2018-04-27 2019-11-08 阿里巴巴集团控股有限公司 量子计算方法和设备
CN108876560B (zh) 2018-07-18 2020-10-02 阿里巴巴集团控股有限公司 一种基于区块链对作品发布者进行信用评价的方法及装置
WO2020096996A2 (en) * 2018-11-05 2020-05-14 Tunnel International Inc. Methods, systems, and devices for concealing account balances in ledgers
CN109598149B (zh) * 2018-11-20 2020-04-07 阿里巴巴集团控股有限公司 业务处理的方法和装置
US11087179B2 (en) 2018-12-19 2021-08-10 Netskope, Inc. Multi-label classification of text documents
CN110046156A (zh) * 2018-12-20 2019-07-23 阿里巴巴集团控股有限公司 基于区块链的内容管理系统及方法、装置、电子设备
CN110046482A (zh) 2018-12-25 2019-07-23 阿里巴巴集团控股有限公司 身份核实方法及其系统
US11374910B2 (en) * 2019-03-13 2022-06-28 Springcoin, Inc. Method and apparatus for effecting a data-based activity
US11405365B2 (en) 2019-03-13 2022-08-02 Springcoin, Inc. Method and apparatus for effecting a data-based activity
US11329968B2 (en) * 2019-03-18 2022-05-10 Microsoft Technology Licensing, Llc Authentication across decentralized and centralized identities
KR102260093B1 (ko) * 2019-08-30 2021-06-02 연세대학교 산학협력단 내결함성 블록체인 네트워크의 신뢰도 기반 샤드 분배 장치 및 방법
US11856022B2 (en) 2020-01-27 2023-12-26 Netskope, Inc. Metadata-based detection and prevention of phishing attacks
US11637817B2 (en) * 2020-03-12 2023-04-25 Springcoin, Inc. Method and apparatus for effecting a data-based activity
US20220100733A1 (en) * 2020-09-29 2022-03-31 International Business Machines Corporation Transaction reordering in blockchain
KR102462998B1 (ko) * 2020-12-30 2022-11-03 아주대학교산학협력단 Bft 합의 방식을 이용한 멀티 체인 간의 교차 인증 장치 및 방법
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment
CN114090376A (zh) * 2021-11-09 2022-02-25 中国银联股份有限公司 一种基于联盟链系统的业务处理方法及装置
CN114244788B (zh) * 2022-02-25 2022-06-03 广州锦行网络科技有限公司 数据的响应方法、装置以及系统
CN114553603B (zh) * 2022-04-25 2022-07-29 南湖实验室 一种基于隐私计算的新型数据可信解密的方法
CN115396087B (zh) * 2022-06-20 2024-04-30 中国联合网络通信集团有限公司 基于临时身份证书的身份认证方法、装置、设备及介质
CN115033908B (zh) * 2022-08-11 2022-10-21 西南石油大学 基于云存储的油气勘探细粒度密态数据的检索方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3120309A4 (en) * 2014-03-18 2017-10-11 Ntrust Technology Solutions Corp. Virtual currency system
CA2986164C (en) * 2015-05-26 2021-11-30 T0.Com, Inc. Obfuscation of intent in transactions using cryptographic techniques
US9992028B2 (en) 2015-11-26 2018-06-05 International Business Machines Corporation System, method, and computer program product for privacy-preserving transaction validation mechanisms for smart contracts that are included in a ledger
US10496976B2 (en) 2016-03-01 2019-12-03 Wipro Limited Method and device for validating transactions pertaining to sharing of services in ad hoc network
US10529042B2 (en) * 2016-04-18 2020-01-07 Rs Ltd. System and method for managing transactions in dynamic digital documents
WO2017189027A1 (en) 2016-04-29 2017-11-02 Digital Asset Holdings Digital asset modeling
US11663609B2 (en) * 2016-10-04 2023-05-30 International Business Machines Corporation Method and apparatus to enforce smart contract execution hierarchy on blockchain
US10708070B2 (en) * 2017-05-24 2020-07-07 Nxm Labs Canada Inc. System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner
AU2019200933B1 (en) 2017-10-27 2019-05-23 Digital Asset (Switzerland) GmbH Computer system and method for distributed privacy-preserving shared execution of one or more processes
EP3529732B1 (en) 2017-10-27 2020-02-19 Digital Asset (Switzerland) Gmbh Computer system and method for distributed privacy-preserving shared execution of one or more processes
US10333902B1 (en) * 2017-12-19 2019-06-25 International Business Machines Corporation Data sanitization system for public host platform

Also Published As

Publication number Publication date
US20200128022A1 (en) 2020-04-23
CN113196270A (zh) 2021-07-30
WO2020082078A1 (en) 2020-04-23
US11575683B2 (en) 2023-02-07
SG11202103877SA (en) 2021-05-28
AU2019362088A1 (en) 2021-06-10
CA3116763C (en) 2024-02-27
EP3857422A4 (en) 2022-06-08
US20230231855A1 (en) 2023-07-20
CA3116763A1 (en) 2020-04-23
EP3857422A1 (en) 2021-08-04
KR20210082194A (ko) 2021-07-02

Similar Documents

Publication Publication Date Title
JP2022508948A (ja) プライバシーを守る検証およびコミットアーキテクチャ
Zhang et al. Security and privacy on blockchain
US20200127813A1 (en) Method and system for creating a user identity
Pagnia et al. Fair exchange
US20200145373A1 (en) System for blockchain based domain name and ip number register
CN110769035B (zh) 一种区块链资产发行方法、平台、业务节点及存储介质
Ray et al. Fair exchange in e-commerce
JP2019511147A (ja) デジタルコンテンツの制御及び配信のためのブロックチェーンにより実施される方法
CN110998631A (zh) 分布式账本技术
Lycklama à Nijeholt et al. Decreg: A framework for preventing double-financing using blockchain technology
JP2002536732A (ja) 暗号化でサポートされるサービスのためのインフラストラクチャとアプリケーションを運用する方法
KR102569409B1 (ko) 가상 분산 원장 네트워크를 위한 시스템 및 방법
KR20220093198A (ko) 전용 및 개방형 블록체인을 이용한 거래의 수행
CN116250210A (zh) 用于网络化的数据交易的认证和授权的方法、装置和计算机可读介质
Payeras-Capella et al. Blockchain-based system for multiparty electronic registered delivery services
Ahmed et al. Turning trust around: smart contract-assisted public key infrastructure
Buldas et al. Blockchain Technology: Intrinsic Technological and Socio-Economic Barriers: FDSE’2020 Keynote
CN111915308A (zh) 一种区块链网络的交易处理方法及区块链网络
CN110502905B (zh) 一种隐私保护的分布式账本交易方法和系统
Mut-Puigserver et al. Blockchain-based contract signing protocol for confidential contracts
Amiri et al. Separ: A privacy-preserving blockchain-based system for regulating multi-platform crowdworking environments
WO2023002640A1 (ja) 違法な取引を防止しつつ匿名ユーザの参加も許容する暗号資産の取引のための完全分散型ブロックチェーンシステム及びコンピュータープログラム
CN112150157B (zh) 通过区块链发行应收凭证的方法及装置
JP2023106055A (ja) エビデンス管理方法、エビデンス管理システム及びノード
Ellervee A reference model for Blockchain-based distributed ledger technology

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221021

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221021

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231225

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240305

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240408