JP2022512324A - 外部システムに対してのセキュアな相互運用性を伴う高性能分散型記録システム - Google Patents

外部システムに対してのセキュアな相互運用性を伴う高性能分散型記録システム Download PDF

Info

Publication number
JP2022512324A
JP2022512324A JP2021532118A JP2021532118A JP2022512324A JP 2022512324 A JP2022512324 A JP 2022512324A JP 2021532118 A JP2021532118 A JP 2021532118A JP 2021532118 A JP2021532118 A JP 2021532118A JP 2022512324 A JP2022512324 A JP 2022512324A
Authority
JP
Japan
Prior art keywords
transaction
network
block
node
handler
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
JP2021532118A
Other languages
English (en)
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 JP2022512324A publication Critical patent/JP2022512324A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • 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
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • 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
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Abstract

（情報または値の変形、変換または転送を含む）多数のトランザクションがスケーラブルで信頼性があり、安全且つ効率的な方法で同時に処理される高性能分散型台帳およびトランザクション・コンピューティング・ネットワーク・ファブリックである。一実施形態では、コンピューティング・ネットワーク・ファブリックまたは「コア」は、チェーンのブロックの通信、処理および記憶が、トランザクション自体が遠く離れたソースから発生している場合であっても、ほとんど同期せずに、非常に高い性能および低いレイテンシで、同時に実行されることを可能にするように、データを編成する分散型ブロックチェーンネットワークをサポートするように構成される。このデータ編成は、処理メッシュとして構成された自律的で協調的なコンピューティングノード内のトランザクション空間のセグメント化に依存している。各コンピューティングノードは、通常、コア内の他の全てのノードと機能的に同等である。ノードは、全体としてブロックチェーンの一貫した論理的に完全なビューを維持しながら、互いに独立してブロックを操作する。

Description

本特許出願は、一般に、分散型ネットワークにおけるコンピューティングリソースのセットにわたる分散型記録システムを管理することに関する。
分散型コンピュータシステムは、従来技術においてよく知られている。そのような分散型コンピュータシステムの１つは、サービスプロバイダによって運用および管理される「コンテンツ配信ネットワーク」（ＣＤＮ）または「オーバーレイネットワーク」である。サービスプロバイダは、通常、サービスプロバイダの共有インフラストラクチャを使用するサードパーティ（顧客）に代わってコンテンツ配信サービスを提供する。この種の分散型システムは、通常、コンテンツ配信、ウェブ・アプリケーション・アクセラレーション、または外部委託元サイトのインフラストラクチャの他のサポートなどの様々なサービスを容易にするように設計されたソフトウェア、システム、プロトコルおよび技術とともに、ネットワークまたは複数のネットワークによってリンクされた自律型コンピュータの集まりを指す。ＣＤＮサービスプロバイダは、通常、顧客ポータルに用意された後にネットワークに展開されるデジタルプロパティ（ウェブサイトなど）を介してサービス配信を提供する。
ブロックチェーンは、暗号化を使用してリンクおよび保護されるブロックと呼ばれる継続的に増加するレコードのリストである。各ブロックは、通常、前のブロックにそれをリンクする暗号化ハッシュとトランザクションデータとを含む。分散型台帳として使用する場合、ブロックチェーンは、通常、新たなブロックを有効化するためのプロトコルに集合的に準拠するピアツーピアネットワークによって管理される。記録されると、任意の所与のブロックのデータは、ネットワークの大多数の結託を必要とする後続の全てのブロックを変更せずに遡及的に変更されることはできない。ブロックチェーンは、イベントの記録、様々なレコード管理アクティビティ（識別子管理、トランザクション処理、出所の文書化など）およびその他に適している。一般化すると、ブロックチェーンは、後続の全てのブロックの変更およびネットワークの結託なしにはレコードを遡及的に変更することができないように、多くのコンピュータにわたるトランザクションを記録するために使用される非中央集権化された分散型デジタル台帳である。典型的なブロックチェーンでは、ブロックは、ハッシュされてデータ構造に符号化される有効なトランザクションのバッチを保持する。この構造では、前述のように、各ブロックは、ブロックチェーン内の前のブロックにそれをリンクする暗号化ハッシュを含む。リンクされたブロックは、チェーンを形成する。この反復プロセスは、元の起源（または最初の）ブロックに遡って、前のブロックの整合性を確認する。
ブロックチェーンの実装を用いて、様々な応用分野をサポートすることができ、その一部はセキュリティ要件を高めてきた。ビットコイン、イーサリウム、および他の派生物などの既知のシステムでは、ウォレットにより使用される秘密鍵（すなわち、ウォレットに関連付けられる値を使用すること）をセキュアにすることに、主に注目している。さらに、ウォレットのセキュリティは、このようなシステムの設計および実装において引き続き重要な考慮事項であり、また、例えば、ホスト型またはサーバベースのウォレット、サーバベースの連署または複数署名ベースのトランザクション、ならびに口座の運用管理および関連付けられた値などの拡張した使用例のセットがあり、これらはさらなるセキュリティ上の課題を提示する。特に、これらの機能は著しい利点を提供するが、攻撃表面、すなわち、潜在的なセキュリティ侵害の数および経路をさらに大きくする可能性がある。
本開示は、（情報または値の変形、変換または転送を含む）多数のトランザクションがスケーラブルで信頼性があり、安全且つ効率的な方法で同時に処理される高性能分散型台帳およびトランザクション・コンピューティング・ネットワーク・ファブリックを提供する。一実施形態では、コンピューティング・ネットワーク・ファブリックまたは「コア」は、チェーンのブロックの通信、処理および記憶が、トランザクション自体がリモートソースから発生している場合であっても、ほとんど同期せずに、非常に高い性能および低いレイテンシで、同時に実行されることを可能にするように、ブロックチェーンのデータを編成する分散型ブロックチェーンネットワークをサポートするように構成される。このデータ編成は、処理メッシュとして構成された自律的で協調的なコンピューティングノード内のトランザクション空間のセグメント化に依存している。各コンピューティングノードは、通常、コア内の他の全てのノードと機能的に同等であり、各ノードは、システムの全負荷を負担できることが好ましい。コンピューティングノードは、通常、コンピューティング、通信および記憶要素のクラスタを備える。より一般的には、コアネットワークを構成する全てのコンピューティングノードは、互いに等しいと見なされることが好ましく、スタンドアロンの個々のノードは、信頼できると見なされない。さらに、互いに関して、ノードは、自律的に動作し、好ましくは、いずれのノードも他のノードを制御することができない。ノードは、全体としてブロックチェーンの一貫した論理的に完全なビューを維持しながら、互いに独立してブロックを操作する。
一実施形態では、処理コアは、例えば、ＣＤＮなどのオーバーレイネットワークのエッジサーバなどのエッジネットワークを介してアクセス可能である。この実施形態では、ＣＤＮエッジネットワークは、メッセージ処理サービスを提供するグローバルベースの分散型システムをサポートし、メッセージは、トランザクションに関連付けられている。エンドユーザのマシンおよびサービスは、トランザクション要求と、分散型記録システムをサポートするコアに対する応答とをその後にルーティングする、ＣＤＮエッジネットワークと最初に相互作用する。別の特徴によると、上述の分散型記録システムアーキテクチャは、ホストされたオリジンサービスと、レガシー決済ネットワークのオペレータに対してブロックチェーンベースの決済システムへの高度にセキュアで回復力のあるアクセスを提供する関連セキュリティ技術とを含む。
上記は、主題のより適切な特徴のいくつかを概説している。これらの特徴は、単なる例示であると解釈されるべきである。開示された主題を異なる方法で適用することによって、または説明されるように主題を変更することによって、多くの他の有益な結果を得ることができる。
主題およびその利点をより完全に理解するために、ここで添付の図面と併せて以下の説明を参照する。
本開示にかかる、トランザクションがブロックチェーンに編成された分散型記録システムを提供するネットワーキングアーキテクチャを示すブロック図である。 本明細書の技術にかかるブロックセグメンテーションを示している。 セグメント化されたブロックチェーンを示している。 セグメントの移行および再割り当てプロセスを示している。 本開示のノード間セグメント処理プロセスを示している。 トランザクション有効化を実行しているときの代表的なコンピューティングノードのブロック図およびその動作を示している。 ブロックマイニングおよび検証を実行しているときの図６Ａのコンピューティングノードおよびその動作を示している。 本開示の同時処理技術の高レベル描写である。 本開示にかかるストリーミングブロックの生成、送信および有効化を提供するために様々なノードおよびノード要素の間で実行される動作の詳細な描写である。 コンピューティング・ネットワーク・ファブリックに関連付けられることができるコンテンツ配信ネットワーク（ＣＤＮ）アーキテクチャを示している。 代表的なマシン構成を示している。 オーバーレイネットワークエッジのネットワークによって囲まれた決済ネットワークコアのブロック図を示している。 マーチャントコネクタと、エッジサーバのネットワークと、ブロックチェーンベースの分散型記録システムのコア要素との間の、エンドツーエンドの接続性を示している。 本開示による鍵管理インフラストラクチャのコンポーネントとともに、マーチャントコネクタとインターフェースして、オーバーレイネットワークエッジの仲介を介して決済ネットワークと相互運用する、マーチャントの販売時点管理（ＰＯＳ：Ｐｏｉｎｔ－ｏｆ－Ｓａｌｅ）システムを示している。 オーバーレイネットワーク基盤を使用してアクワイアラ／オペレータのオリジンサービスをホストすることにより、アクワイアラ／オペレータのトランザクション処理システムの決済ネットワークへの統合を容易にする方法を示している。 さらなる局面により、エッジネットワークが、レガシー外部システムとブロックチェーンベースの決済ネットワークコアとの間のセキュアな相互運用性をどのように促進するかを表す。
全体的な高レベル設計
図１は、トランザクションがブロックチェーンに編成された分散型記録システムを実装するためのスケーラブルな高性能アーキテクチャを示している。高レベルでは、システムは、示されているように複数の機能領域、すなわち、周辺１００ａ、エッジ１００ｂ、およびコア１００ｃに分割されている。システムは、配信、管理、運用、管理、構成、分析などを容易にするために他の機能領域を備えることができるが、簡単にするために、これらの領域は示されていない。本明細書において使用される場合、周辺１００ａは、一般に、境界１０１に関連付けられた要素を指す。これらの要素は、通常、クライアントサーバベースの電子ウォレットまたはウォレットデバイス、端末および販売時点管理デバイス、レガシー金融ネットワーク要素および関連するアダプタを含む。一般に、本明細書において使用される場合、限定されるものではないが、金融トランザクションを含む、トランザクションの作成および消費に関与する任意の要素は、周辺１０１内の要素とすることができる。周辺は、グローバルに広がることができる。エッジ１００ｂは、通常、境界１０２に関連付けられたオーバーレイネットワークの要素を指す。代表的な要素は、これらに限定されるものではないが、オーバーレイ・エッジ・ネットワーク（例えば、Ａｋａｍａｉ（登録商標）などのＣＤＮ）で実行される処理、通信および記憶要素（エッジサーバ、スイッチ／ルータ、ディスク／ＳＳＤ）を含む。上述したようなＣＤＮは、有利には、要求されたトランザクションおよびそれらに関連する結果を集約し、（周辺機器における要素との間で）後述するように効率的にルーティングする、（エンドユーザ／デバイスと比べて）低レイテンシのプレゼンスポイントを提供する。ウォレットサービスは、エッジ内に配置されることができる。エッジ要素はまた、個別に、集合的に、および他のサービスと連携して、攻撃および他の敵対的な活動からコア１００ｃを保護するセキュリティ境界として機能する。ＣＤＮ固有の実装が好ましいが、本明細書のシステムにおける典型的なエッジネットワークは、ＣＤＮエッジネットワークに限定される必要はない。これに限定されるものではないが、クラウドベースのシステムを含む新規なまたは既存の任意の適切なネットワークが使用されることができる。
コア１００ｃは、境界１０３に関連付けられた要素を指す。後述するように、コア１００ｃは、これらに限定されるものではないが、スループット、応答時間、セキュリティおよびデータの整合性を含む特定の性能要件を満たすトランザクションブロックチェーンの処理および記憶をともにサポートするノードの高性能ネットワークであることが好ましい。この文脈におけるノード（「コンピューティングノード」と呼ばれることもある）は、通常、コンピューティング、通信および記憶要素のクラスタである。より一般的には、本明細書において使用されるクラスタは、１つ以上の、そしておそらく多くのコンピューティング、通信および記憶要素を指す。一実施形態では、コア１００ｃは、オーバーレイネットワークノードを備えるが、コア１００ｃは、ＣＤＮとは異なり且つ（説明されるように）コア動作専用のノードのセットを備えることができるため、これは要件ではない。通常、コンピューティングノードは、ネットワークトランジットによって相互接続され、トポロジ的なボトルネックを軽減または排除する高度な相互接続性を有する。
高性能を促進するために、好ましくは、コアネットワークは、高品質、大容量、および多様な相互接続を使用して構築される。コアネットワークの特定の構成は、通常、ブロックチェーンに実装されているコンセンサスプロトコルの性質に少なくとも部分的に基づく実装に依存している。使用されるコンセンサスプロトコルに応じて、コアネットワーク全体のレイテンシが十分に低いネットワーク通信を確保するために、必要に応じて、コアネットワークのサイズ（および／またはその中の様々なコンピューティングノードの分布）が制限されることもできる。
非限定的な一実装では、ＣＤＮエッジ１００ｂは、（例えば、所与の地理における複数のネットワーク化されたデータセンタにわたって配置される）コアネットワーク１００ｃに関連付けられたグローバルベースのサービスをサポートする。
再び図１を参照すると、メッセージ１０４は、トランザクション要求をエッジサーバ（例えば、ＣＤＮエッジサーバなど）に送信するデバイス（例えば、エンドユーザデバイス、電子ウォレットなど）の例である。多数のそのようなメッセージ（そして本明細書で説明するようにコアネットワークに送信されてコアネットワークによって処理されるものである）は、世界中のサーバ、デバイス、およびウォレットから発信されると予想されることを理解されたい。メッセージは、永続的な接続または一時的な接続を介して送信されるだけでなく、それらのネットワークが本明細書で説明するシステム機能をネイティブにサポートするために構築されたレガシーまたはネットワークインフラストラクチャの目的の一部とすることができる新たなまたは既存のネットワークを介して送信されることができる。さらに、メッセージは、システムへの任意の単一の進入ポイントへの依存を減らすために１つ以上のエッジサーバに送信されることができる。
メッセージ１０５は、トランザクション（おそらくメッセージ１０４に含まれるものを含む）をコアノード１１０（ノード１１０のセットが描かれている）の適切な要素にルーティングするエッジ要素の例である。所与のトランザクションの場合、同じトランザクションまたは同じトランザクションのハッシュ（または他のダイジェスト）を他のコアノードの適切な要素にルーティングする複数のメッセージ１０５が存在することができる。全てのメッセージ１０５がトランザクションの完全な表現を含む必要はない。トランザクションのダイジェストが送信され、（１）コア要素にトランザクションの存在を認識させ、（２）完全なトランザクションを含むメッセージの整合性をチェックする堅牢な方法を提供することができる。これは、全てのコアノードの適切な要素に対する到来トランザクションメッセージの完全な、さらに効率的な伝播を可能にする。また、従来のゴシッププロトコルに関連するネットワーク負荷を大幅に削減し、さらに、例えばセキュリティを侵害されたエッジエレメントのトランザクションの検閲や破損からの保護を提供する。
メッセージ１０６は、トランザクションを他のコアノードの適切な要素にルーティングするコアノード要素の例である。コアノード要素がシステムのコアノードにわたるトランザクションまたはトランザクションダイジェストの伝播に参加するように、複数のメッセージ１０６が存在することができる。メッセージ１０６を受信するコアノードは、次に、他のメッセージ１０６を生成し、システムのコアノード全体にメッセージをさらに伝播することができる。
トポロジ認識データ伝播
任意のデータ伝播プロトコルが使用されることができるが、本明細書の１つの好ましいアプローチは、基盤となるネットワークトポロジへの伝播を形成することにより、従来のランダム化ピアツーピアゴシッププロトコルのコストとレイテンシを改善することである。協調して、メッセージ１０４、１０５、および１０６は、トポロジ的に最も近い要素から始まり、トポロジ的に少ないまたは最も近くない要素に到達する伝播の経路を含む。他のエッジ要素にメッセージ１０４を送信するデバイスは、通常、ネットワーク全体の様々な伝播経路をたどる。これは、異なる方向に伝播するメッセージ１０７、１０８、および１０９によって示されている。さらに、所与のデバイスから始まる伝播の経路は、一般に、適切な負荷バランシングとセキュリティを実現するために時間とともに変化することがある。
サービス発見および高性能マッピング
再び図１を参照すると、メッセージが送信される前に、メッセージを発信する各要素は、通常、受信要素のアドレスを発見しなければならない。アドレスは、インターネットプロトコル（ＩＰ）アドレス、またはいくつかの種類のネットワーク（例えば、ピアツーピアネットワークまたはオーバーレイネットワーク）のアドレス空間における他の名称もしくは番号とすることができる。他の要素のアドレスの発見は、様々な方法で実現されることができるが、一般に、一連の要素属性を発見サービスに送信することと、返信としてアドレス情報を受信することとを含む。好ましい一実施形態では、発見されるシステム要素の属性は、ドメイン名として符号化され、それにより、システムがＣＤＮの高性能ドメイン名ルックアップサービスを使用して必要なアドレス情報を返信することを可能にする。オーバーレイネットワークのマッピング技術を使用することは、いくつかの利点を提供する。それは、最大規模の展開さえも可能とするように大規模なドメイン名空間をサポートする。これは、例えば、エッジ要素が、トランザクションをコアノードだけでなく、トランザクションの識別子空間の関連部分を処理するコアノード内の特定の要素にさえもルーティングすることを可能にする。これと同じ種類の細粒度ルーティングは、コアノード要素間の通信のために行うことができ、特に、ＣＤＮ ＤＮＳサービスを使用すると、セグメントのセット、パーティション、またはトランザクション情報の他のグループを処理する１つのノードの要素は、同じセグメント、パーティション、またはトランザクション情報の他のグループを処理する他のコアノードの要素にメッセージを直接送信することができる。トラフィックは、低レベルのネットワークルータ／スイッチの一般的なセットを通過することができるが、コアノードは、各トランザクションを個別に検査してルーティングする必要がないことから、これは有利である。この方法でＣＤＮネームサービスを使用すると、再構成もサポートする。特に、ノードの構成が変化した場合、例えば、トランザクション空間の一部の責任が１つのサーバから他のサーバに移行されることから、変化は、ネームサービスのマッピングシステムを介して迅速に且つ効率的に伝達される。ＣＤＮネームサービスを使用する他の利点は、一時停止の概念をサポートすることである。したがって、エッジ要素またはコアノード要素が正常に機能しなくなったり、動作不能になったりした場合、マッピングシステムは、問題から遠ざけるようにトラフィックをマッピングすることができる。ＣＤＮネームサービスを使用するさらなる利点は、高解像度の容量消費測定に基づいてトラフィックの負荷バランシングをサポートするためのそのようなシステムの能力である。このアプローチはまた、周辺のデバイスが最小限の基盤となるサービスおよびネットワークコンポーネントを共有するエッジ要素のアドレス情報を受信することができるように、ルートと領域の多様性もサポートする。ＣＤＮ ＤＮＳサービスはまた、レイテンシの最適化もサポートする。例えば、コアノード要素は、いくつかの近接基準を満たす他のコアノード要素のアドレスを受信することができる。
代替の実施形態は、位置または方向認識マッピングを利用する。したがって、例えば、コアノード要素は、所望の位置もしくは方向にあるまたは方向性グラフを構成するノード要素に応答がアドレスを提供するように、位置または方向情報（地理的またはトポロジ方向のいずれか）によって符号化されたドメイン名を使用することができる。この機能は、マッピングシステムに固有とすることができるかまたはマッピングシステムに付属することができる。この方法でのトポロジ的マッピングは、低レイテンシのトポロジ認識データ伝播機構を提供する。
一般化
本明細書において使用される場合、ブロックは、一般に、トランザクションデータの任意の集約または関連付けを指す。特定のフォーマットは必要ない。ブロックチェーンは、暗号化を使用してリンクおよび保護されるブロックと呼ばれる継続的に拡大するレコードのリストである。ブロックチェーンの各ブロックは、通常、前のブロックにリンクする暗号化ハッシュとトランザクションデータとを含む。分散型台帳として使用する場合、ブロックチェーンは、通常、ノード間通信と新たなブロックの有効化のためのプロトコルに集合的に準拠するピアツーピアネットワークによって管理される。記録されると、任意の所与のブロックのデータは、ネットワークの大多数の結託を必要とする後続の全てのブロックを変更せずに遡及的に変更されることはできない。
本明細書の技術は、ブロックチェーンを使用してトランザクションデータを記録することができるが、本開示のシステムのアーキテクチャおよび関連するトランスポート機構は、トランザクションデータの他の編成にも適用することができるため、これは限定されるものではない。さらに、ブロックのチェーンまたはシーケンスにおけるようなブロックチェーンの概念は、これらに限定されるものではないが、ブロックツリー、ブロックグラフなどを含むブロックの任意の編成とすることができる。
マイニングは、ブロックチェーンにおける前のブロックを参照するヘッダを有する順序付けられたトランザクションのブロックを生成する行為である。公の（無許可の）ブロックチェーンコンセンサスシステムでは、マイニングは、一般に、競争として構成され、生成されたブロック（およびその祖先）がマイニング競争およびその後のコンセンサスプロセスに耐えた場合、それは確定され、永続的な記録の一部と見なされる。理想的なシステムでは、あるラウンドから次のラウンドへの（すなわち、あるブロックから次のブロックへの）マイニング責任は、参加者間でランダムに分散される。正式には、理想的なシステムでは、マイニングの決定は、予測可能ではなく、影響を与えることができず、検証可能である。しかしながら、現実世界の用途では、分散は、完全にランダムである必要はない。例えば、作業証明システムでは、マイニング能力が高いエンティティほど競争に勝つ確率が高いため、分散は、実際にはランダムではない。
セグメンテーション
従来のブロックチェーンの実装では、ブロックチェーンを単純なブロックのシーケンスとして扱う。そのようなアプローチは、通常、処理のボトルネックを形成し、ブロックチェーンをその集約形式で通信および記憶することによって、ブロックチェーン実装の達成可能な性能を厳しく制限する。
対照的に、本明細書で説明するアプローチは、その通信、処理および記憶が非常に高い性能でほとんど同期せずに同時に実行されることを可能にするように単一チェーンのデータを編成することにより、公知の技術から逸脱している。理解されるように、このデータ編成は、ブロックチェーンの一貫した論理的に完全なビューを維持しながら、各ノード内のトランザクション空間のセグメント化に依存することが好ましい。このアプローチはまた、連合またはシャーディングされたブロックチェーンのセットを構成する複数のチェーンのそれぞれにも適用されることができ、ブロックチェーン操作の性能を改善し、それにより、作業を減らし、オフチェーン（いわゆる「レイヤ２」）システムの性能を向上させる。
このアプローチでは、ネットワークにまたがるコンセンサスアルゴリズムが使用され、システムが正しい最終結果を生成することを確実にする。使用できる特定のコンセンサスアルゴリズムは、限定されるものではない。しかしながら、各ノード内の操作では、ノードの要素が正しく信頼できると想定している。ノードに障害が発生したり、攻撃者によって破壊された場合、システムは、ネットワークの残りの部分に依存して、サービスの整合性と可用性を維持するとともに、障害および侵入検出機能をサポートする。見てわかるように、この設計アーキテクチャは、システム要素がブロックチェーンデータ編成と整合するように、ノードの内部が、高性能、低レイテンシの通信ファブリックで実行される疎結合分散型システムとして編成されることを可能にする。結果として得られるアーキテクチャは、公知の技術と比較してはるかに高い性能の実装を提供する。
ブロックセグメンテーション
図２を参照すると、ブロック２００は、トランザクションｉｄ（Ｔｘｉ）によって、いくつかのセグメント２０２ａ－ｎ（ここで、ｎ＝１０００）と、ヘッダ（Ｈｄｒ）２０４とにセグメント化される。セグメント２０２およびヘッダ２０４は、ブロックチェーンのブロックを表すが、それらは、（多くの場合）個別に処理、送信および記憶されることができる。図２に１０００として示されるセグメント２０２の数は、数がより多くても少なくてもよく、時間とともにまたは動的に変化してもよい。好ましくは、十分な数のセグメントが選択されて、データのセグメンテーション（編成）を変更する必要なしに、基礎となるリソースの実質的な将来の成長を可能にするのに十分な大きさの空間を形成する。
この実施形態では、ブロックセグメンテーションは、通常、ネットワークの全てのノードによって共有される外部から見える属性である。見てわかるように、セグメントによってブロックデータを編成することにより、ブロック情報を交換するノードの性能と効率を大幅に向上させる。特に、本明細書のアプローチは、所与のセグメントの処理を担当するノードのコンポーネントが、所与のセグメントの処理を担当する他のノードのコンポーネントと直接通信することを可能にする。さらに、コンポーネントへのセグメントのマッピングは、ノード間で異なることができ、それにより、例えば、トランザクションデータの総量を処理する際にノードが異なる数のリソースを使用することを可能にすることによるなど、スケールアップ（またはスケールダウン）展開を可能にする。
代替の実施形態では、セグメンテーションの詳細は、厳密にノードの内部属性のままであってもよい。そのような実施形態では、ノードのコンポーネントへのセグメントのマッピングは、任意とすることができる。この代替手段は、ノードの構成の独立性を高めることができるが、一般に、ノード内のトランザクションレイヤルーティングのいくつかの形式を含む、ノード間のより詳細な（例えば、トランザクションごとの）データ交換を必要とする。
本明細書で使用される場合、セグメンテーションという用語は、暗黙的であれ明示的であれ、１つのノードの要素が他のノードの要素と相互作用して一度に複数のトランザクションのデータを交換することができるように、トランザクションデータの任意のグループ化、パーティション化、シャーディングなどを意味するために使用される。
ヘッダ２０４は、いくつかの必須要素、すなわち、前のブロックヘッダのハッシュ２１０、ブロックのコンテンツのマークルルート２０８、およびブロックのマイナーが実際に正当なマイナーであったことを示す証明２０６を含む。他の情報が含まれてもよい。
ブロックチェーンセグメンテーション
図３を参照すると、セグメント化されたブロックは、一時的に、セグメント化されたブロックチェーンを形成し、そのいくつかのブロックは保留されている（すなわち、まだ確定されていない）が、その他のブロックは確定されている（すなわち、ブロックチェーンに追加されている）。この例では、図示されている各マシン３００は、保留中のブロックと確定されたブロックとの双方をサポートするが、これは要件ではない。この分散型の編成は、このアプローチがブロックツリーまたはブロックグラフ構造などに関して、他のシナリオにも適用可能とすることができるため、ブロック「チェーン」に限定されるものではない。ブロックはまだ全体であるが、そのセグメントは、ブロックをモノリシックに処理するよりも効率的に処理されることから、このアプローチは有利である。図３に示されるように、様々な数のセグメントが異なるマシンリソースに割り当てられ、組み合わせられることができる。この種の編成は、仮想化およびコンテナ化された環境に特に適用可能であるが、いずれも恩恵を達成するために必要ではない。
図４を参照すると、システムリソースへのセグメントの割り当ては、例えば、アップグレード、メンテナンスおよび障害回復をサポートするために、時間とともに変化することができる。この場合、１つのマシン４０２が故障したかまたはオフラインになり、それが処理していたセグメントが他のマシンに移行される。このアプローチは、日常的および緊急の理由の双方で、仮想またはコンテナ化されたコンピューティング要素を移行するという確立された概念によく適合する。
セグメンテーションおよびノード間通信
図５を参照すると、セグメンテーションをノードの公開された属性にすることにより、ノード内の要素は、他のノードの要素と直接通信して、セグメントの細分性に関する情報を交換することができる。ノードへのセグメントのマッピングは、全てのノードにわたって同じである必要はない。
後述するように、好ましい実施形態では、システムのコンピューティングノードは、それぞれ、トランザクション有効化、ならびにブロックマイニングおよび検証などの複数の別個の機能またはモード（動作役割）を実行することができる（多くの場合に実行する）。実際、所与のコンピューティングノードは、多くの場合、同時に複数のそのようなモードで動作する。典型的な動作シナリオでは、特定のノードは、マイニングに使用されることができるが、通常、全てのコンピューティングノードは、何がマイニングされるかを検証する。
図５は、ブロックマイニングおよびブロック検証の編成が好ましくはセグメンテーションの存在下で達成される方法を示している。この例では、他のコンピューティングノード５００ｂ、５００ｃおよび５００ｄがブロックを検証する（本明細書では「検証」と呼ぶ）マシンを備える一方で、コンピューティングノード５００ａにおけるブロックの生成／マイニングのために使用される多数のマシンが存在すると想定している。図示のように、ブロック・マイニング・イベントは、ブロックのマイニングまたは生成を開始しようとしていることを通知する、マイニングノード５００ａによって（一般に、生成および有効化ブロックヘッダを処理する要素によって）ネットワークの他のノード（この例では、ノード５００ｂ、５００ｃおよび５００ｄ）に送信されるメッセージ５０２によって開始される。ノード５００ｂ、５００ｃおよび５００ｄの対応する要素は、このメッセージを受信し、マイニングノードの要素からのマイニングされたブロックデータを予期するようにそれらのノードの処理要素に通知する。同時に、５０３などの複数のメッセージシーケンスが、生成されたセグメントごとに、それらのセグメントを処理するマイニングノードの要素によって、リモート検証ノードの各セグメントを処理する要素に（それぞれ）送信される。
マイニングされたセグメントが終了すると、そのセグメントを担当する要素からブロックヘッダを担当する要素にメッセージ５０４が送信される。メッセージは、とりわけ、生成されたセグメントのマークルルートを含む。全てのメッセージ５０４が送受信されると、ブロックヘッダを担当する要素は、ブロック・マークル・ツリーの上部を作成し、ヘッダにマークルルートを保存する。そして、ヘッダの生成および検証の処理を担当する他のノードの要素にメッセージ５０５を送信する。有効化を実行する際、セグメントのメッセージ５０３を受信すると、セグメントを処理する受信ノード要素は、受信したトランザクションを有効化し、セグメントのマークルツリーを計算し、完了すると、ヘッダを処理するノードの要素にメッセージ５０６を送信する。その要素は、全てのセグメントのメッセージ５０６からブロックヘッダを再構築し、それをメッセージ５０５内のマイニングノードから受信したヘッダと比較する。ヘッダがマッチする場合、ブロックは受け入れられ、そのノードの事前に確定されたブロックのセットに追加される。
一実施形態では、トランザクションが検証に失敗するかまたは再構築されたヘッダがマイニングノードから送信されたヘッダとマッチしない場合、ブロックは拒否され、全ての変更が逆行されてノードから消去される。
他の実施形態では、有効化ノードは、同じセグメントについてメッセージ５０６の異なる値にマイニングするマシンにフラグを立てることができ、それにより、１つ以上の故障または悪意のあるマシンからシステムを保護する。
上述した処理を以下により詳細に説明する。
セグメンテーションおよびノード編成
図６Ａおよび図６Ｂは、システムのコンピューティングノードの動作を示し、図６Ａは、初期トランザクション有効化に関与するノード要素の動作を示し、図６Ｂは、ブロックマイニングおよび検証に関与するノード要素の動作を示している。
図６Ａおよび図６Ｂに示されるように、ノードは、トランザクション有効化ならびにブロックマイニングおよび検証に関連する個別にスケーラブルなタスクを実行するためにともに機能するいくつかの要素またはコンポーネントを含む。これらのコンポーネントは、ノードコーディネータ６０１、１組のセグメントハンドラ６０４、１組のトランザクションハンドラ６０９、１組のＵＴＸＯ（未使用トランザクション出力、Ｕｎｓｐｅｎｔ Ｔｒａｎｓａｃｔｉｏｎ Ｏｕｔｐｕｔ）ハンドラ６１４、および１組の署名検証部６１７を含む。セグメントハンドラおよびトランザクションハンドラは、別個のものとして示されているが（これが好ましい）、これらの機能は、後述するように双方の機能を実行する複合ハンドラに組み合わせられることができる。さらに、通常、各ハンドラには複数のインスタンスがあるが、その処理能力に応じて１つで十分な場合もある。
背景として、そして上記のように、好ましくは、各ノードは、システムにおける他の全てのノードと機能的に同等であり、各ノードは、システムの全負荷を担う。より一般的には、システムにおける全てのノードは、互いに等しいと見なされ、スタンドアロンの個々のノードは、信頼できると見なされない。さらに、互いに関して、ノードは、自律的に動作し、いずれのノードも、別のノードを制御することができない。
ノードは、一般に、以下のように動作する。トランザクション有効化においては、図６Ａを参照すると、通常、未処理のトランザクションがエッジマシン（または他のノード）から転送されるときに、６１２においてそれら未処理のトランザクションがノードにおいて継続的に受信され、最初にトランザクションハンドラ６０９によって処理される。トランザクションは、通常、（例えば、それに関連付けられたまたはそこで実行されているウォレットサービスによって）ウォレットまたはウォレットのセットに作成され、ウォレットは、通常、エッジマシンと相互作用し、周辺からトランザクション要求を受信するか、または６１２において受信されてトランザクションハンドラ６０９によって処理される場合、ブロックチェーントランザクションをコアに転送する。一般に、トランザクションハンドラによる未処理のトランザクションの処理が「有効化」であり、未処理のトランザクションがトランザクションハンドラによって「有効化」されると、トランザクションは、トランザクションハンドラのメモリプール（または「ｍｅｍプール」）に配置される。トランザクションハンドラによって有効であると見出されなかった未処理のトランザクションは拒否され、ハンドラのメモリプールに配置されない。
この目的のために、受信（すなわち、未処理のトランザクションがノードへ進入）すると、トランザクションハンドラ６０９は、通常、２つの基本的なアクションを実行する。図６Ａに示されるように、トランザクションハンドラ６０９は、（６１５において）ＵＴＸＯハンドラ６１４にクエリを出し、トランザクションへの入力が存在するかどうかを判定し、存在する場合、（６１６において）ＵＴＸＯハンドラ６１４によって管理されているＵＴＸＯ空間からそれらの入力を取得する。入力が存在しない場合、クエリを受信したＵＴＸＯハンドラは、トランザクションハンドラに通知し、トランザクションハンドラは、未処理のトランザクションを拒否する。ＵＴＸＯハンドラ６１４から入力を受信すると、トランザクションハンドラ６０９は、（６１８において）署名検証部６１７を参照して、各入力に関連付けられたロック解除スクリプト（デジタル署名）が有効かどうかを判定する。通常、各入力は、トランザクションのロック解除スクリプト（デジタル署名）を含むため、署名検証部によって実行される署名検証は、トランザクションによって使用される各ＵＴＸＯに関連付けられたロックスクリプト（公開鍵）と署名がマッチするかを確認する署名検証を含む。この動作の詳細については、以下に説明する。したがって、この確認は、暗号化動作を含み、計算集約的であり、したがって、署名検証部は、ＵＴＸＯハンドラから受信した有効な入力についてのみトランザクションハンドラによって参照されることが好ましい。署名検証部６１７は、６１９において入力（特に、入力署名）の有効性を確認する。トランザクションハンドラは、入力がトランザクションハンドラによって受信されると、ＵＴＸＯハンドラおよび署名検証部と同時に相互作用することができる。全ての入力署名が署名検証部６１７によって検証されると、未処理のトランザクションは、トランザクションハンドラによって「有効」または「有効化済み」と見なされ、６１５において、トランザクションハンドラ６０９は、新たなトランザクションに関連付けられたＵＴＸＯを担当するＵＴＸＯハンドラ６１４において新たなトランザクション出力（ＵＴＸＯ）を作成する。この動作では、作成要求は、１つのＵＴＸＯハンドラ、すなわち、トランザクションに関連付けられたトランザクションｉｄ空間の部分においてＵＴＸＯを処理する１つのハンドラにのみ送信される。また、図示されているように、（６１５において）作成呼び出しが送信され（クエリおよび署名検証が成功した後）、新たなトランザクション出力（ＵＴＸＯ）を開始する。
この方法で全ての入力が検証されると、未処理のトランザクションがトランザクションハンドラのメモリプールに配置される。そして、（有効化された）未処理のトランザクションは、６１３を介して全ての他のノードに出力（すなわち、伝播）され、未処理のトランザクションを受信する他の各ノードは、ここで説明したのと同様の一連の動作を実行する。これで未処理のトランザクションのローカル有効化動作を完了し、これは、結果としてトランザクションハンドラのメモリプールに入れられる。上述したプロセスは、未処理のトランザクションがノードにおいて（再度、エッジマシンまたは他のノードのいずれかから）受信されると継続する。
したがって、未処理のトランザクションを受信するトランザクションハンドラは、トランザクションへの入力が存在するかどうかを（ＵＴＸＯハンドラのクエリから）判定し、存在する場合は、それらの値とロックスクリプト（アドレスまたはウォレットアドレスと呼ばれることもある公開鍵を含む）が何であるかを判定する。それは、各入力のロック解除スクリプト（デジタル署名）を確認し、全ての署名が有効である場合、トランザクションハンドラは、未処理のトランザクションをその関連するメモリプールに収容（保存）する。このようにして、有効化済みの未処理のトランザクションは、各ハンドラのメモリプールに蓄積される。したがって、各トランザクションハンドラのメモリプールには、ブロックチェーンにおけるブロックセグメント（したがってブロック）に対してマイニングされる（すなわち、割り当てられる）ことを実質的に「待機している」トランザクションの集合（セット）が存在する。好ましくは、システムは、最小待機時間を強制して、新たなトランザクションが伝播してシステムの他のノードによって有効化されることを可能にする。
ここで、ノードコーディネータ６０１がブロックをブロックチェーンにマイニングするときだと判定したと想定する。ブロックをマイニングするという概念は、ブロックがシステムの所定のコンセンサスアルゴリズムにしたがって確定的であるとノードコーディネータが判断したときに生じる（以下により詳細に説明する）ものであり、実際にブロックをブロックチェーンに追加するという概念とは異なる。通常、「マイナー」として機能するノードのサブセットが常に存在する。本明細書の技術によれば、説明したように、ブロックをコンポジットとしてマイニングする代わりに、ブロックは、「セグメント」単位でマイニングされる。すなわち、ブロックの個々のセグメントは（同時か並列式であるかにかかわらず）別個に、具体的にはセグメントハンドラ６０４によってマイニングされる。
このために、ここで図６Ｂを参照すると、ノードコーディネータ６０１は、６０５を介してそれらのセグメントのマイニングを開始するように、その関連するセグメントハンドラ６０４に指示する。このコマンドは、通常、開始時刻、期間、および終了時刻を含む。ノードコーディネータはまた、マイニングされたブロックセグメントデータがマイニングノードのセグメントハンドラからシステムの他のノードのセグメントハンドラに直接（６０７を介して）送信されることを予期するように、（６０２を介して）システム内の他のノードコーディネータに通知する。セグメントハンドラのジョブは、トランザクションハンドラのメモリプールから有効化済みの未処理のトランザクションを取得および受信し、ブロックが確定されてブロックチェーンに追加される場合に、それらの有効化済みトランザクションをブロックセグメント（したがって、ブロック）で最終的に永続化するためにステージング（ｓｔａｇｅ）することである。代替の実施形態では、セグメントハンドラは、有効化済みのトランザクションのダイジェスト（ハッシュ）を取得および受信することができ、その場合、将来の永続化のためにトランザクションをステージングするジョブは、トランザクションハンドラにシフトする。
後述するように、好ましくは、ブロック内の各セグメントの実際の永続性（およびブロックチェーン自体でのブロックの永続性）は、セグメントハンドラがノードコーディネータによってブロックを確定するように指示されるまで発生しない。通常、これは限定されるものではないが、セグメントハンドラ６０４とトランザクションハンドラ６０９との間に１：１の関係がある。上記のように、これらの機能は、実装において組み合わせることができ、１：１の関係が示されているが、ノードは、任意数のいずれかの種類のハンドラによって構成されることができる。
マイニングを開始するコマンドを受信すると、６１０において、セグメントハンドラ６０４は、それぞれのメモリプール内のトランザクションをブロックに割り当て、未処理の各トランザクション（またはそのハッシュ）を返すように、（セグメントハンドラのためにセグメントを処理する）トランザクションハンドラに対して要求する。しかしながら、トランザクションハンドラは、そのメモリプールから要求元のセグメントハンドラに未処理のトランザクションを返す前に、マイニングされるブロックに関してトランザクション入力を最初に「使用する（ｓｐｅｎｄ）」（すなわち、実際のトランザクション値を入力に適用する）必要があり、それは（６２０を介して）使用要求をＵＴＸＯハンドラに送信することによって行われる。示されているように、ＵＴＸＯハンドラは、使用要求を適用し、それらのローカルデータを更新して、（６２１を介して）その結果（成功または失敗）をトランザクションハンドラに返す。
失敗の応答が発生した場合、トランザクションハンドラは、６２０を介してＵＴＸＯハンドラにトランザクションの全ての成功した使用動作を取り消すように指示する必要がある。この衝突検出およびロールバックは、ＵＴＸＯハンドラにおいてロック（または複数のＵＴＸＯハンドラを有するノードの場合には分散型ロック）を取得することを未然に防ぎ、したがって高コストを回避する楽観的同時並行処理制御機構を構成する。これは、ＵＴＸＯ使用動作の効率的な高スループットの低レイテンシ処理を可能にする。
全てのトランザクション入力の使用に成功すると、トランザクションハンドラは、６２０を介してＵＴＸＯハンドラにトランザクション出力（トランザクションのＵＴＸＯ）をブロックに割り当てるように指示し、６１１を介して未処理のトランザクション（および／またはそのダイジェスト）を要求元のセグメントハンドラに転送して戻す。
ここで説明したセグメントハンドラとトランザクションハンドラとの相互作用は、トランザクションハンドラが図６Ａに示され且つ上述したように未処理のトランザクションを受信して処理し続けるときに実行される。図６Ｂを再び参照すると、セグメントハンドラ６０４は、互いに対して並列に動作し、各セグメントハンドラは、関連するトランザクションハンドラに同様の要求を行う。したがって、通常、マイニングされるブロックの特定のセグメントに関連付けられたセグメントハンドラとトランザクションハンドラとのペアがある。トランザクションハンドラ６０９は、要求元のセグメントハンドラ６０４に、そのメモリプールからの未処理の各トランザクションを、未処理のトランザクションについて計算されたダイジェストとともに提供することによって応答する。セグメントハンドラ６０４は、各トランザクション（およびそのダイジェスト）を受信し、トランザクションを当該セグメントの論理シーケンスにシーケンス化する。各セグメントハンドラは、その関連付けられているトランザクションハンドラから受信する未処理のトランザクションに対しても同様に動作するため、ブロックのセグメントは、同時に（セグメントハンドラによって）マイニングされる。セグメントハンドラが未処理のトランザクションをシーケンス処理するときに、それは、（６０７を介して）トランザクションのダイジェストを取得し、それらを（好ましくはダイジェストのみ）他の全てのノードに出力する。ネットワークの他のノードは、セグメントハンドラから伝播されたダイジェストを使用して、ローカルにマイニングされているセグメントを有効化する。セグメントハンドラはまた、６０８を介して（他のノードの）他のセグメントハンドラからダイジェストを受信する。
セグメントハンドラ６０４は、セグメントが有効であると判定すると、その処理の結果、すなわち、セグメントに対して計算されたマークルツリーのルートを、６０６を介してノードコーディネータに返す。マイニング中、ノードコーディネータは、セグメントが有効であると信頼する。（同時に動作する）他のセグメントハンドラ６０４は、同様に機能し、それらのセグメントが同様に完了したことを示すそれらのマイニング結果を返す。
（全てのセグメントのマークルルートを使用して）全てのセグメントハンドラがノードコーディネータに応答すると、ノードコーディネータは、（全てのセグメントマークルルートから）全体的なブロック・マークル・ツリーを計算し、全体的なブロック・マークル・ルートおよびその他の情報を組み込んだブロックヘッダを生成する。次に、ノードコーディネータは、６０２を介してブロックヘッダを含むマイニング完了メッセージをネットワーク内の他のノードコーディネータに送信／伝播した後、それらの他のノードコーディネータは、ブロック・マークル・ルートを使用して、次に説明するようにそれらのブロック検証プロセスを完了する。
特に、ここで、ノードコーディネータ６０１が、６０３を介して、それ自体のブロックマイニング動作を開始する他のノードのノードコーディネータから送信されたマイニング開始メッセージを受信すると仮定する。これは、他のノードからマイニングおよび送信されたブロックデータのブロック検証プロセスを開始する。ブロック検証プロセスは、ブロックマイニングプロセスのバリエーションであるが、２つは異なり、多くの場合、ノードは、双方のプロセスに同時に関与する。実際、ノードは、通常、一度に１つのブロックのみをマイニングするが、同時に複数の到来ブロックを検証することもできる。マイニングと同様に、本明細書で説明する技術にしたがって、説明したように、ブロックをコンポジットとして検証する代わりに、好ましくは、ブロックは「セグメント」単位で検証される。すなわち、ブロックの個々のセグメントは（同時か並列式であるかにかかわらず）別個に、具体的にはセグメントハンドラ６０４によって検証される。
このために、６０５を介して、ノードコーディネータ６０１は、それらがマイニングプロセスにおいてブロックにトランザクションをマイニング／割り当てるため、６０８において他のノードからトランザクションハッシュを受信し、それに応答して、マイニングノードのセグメントハンドラによって行われた関連するトランザクションブロックの割り当てを検証するようにその関連するセグメントハンドラ６０４に指示する。好ましくは、セグメントデータの検証は、（データが受信されるのにともない）漸進的に、およびマイニングノード内のブロックセグメントへの追加のトランザクションのマイニング／割り当てと同時に実行される。
６０８を介して、トランザクションハッシュを受信すると、セグメントハンドラ６０４は、６１０を介してトランザクションハッシュをセグメントのトランザクションの処理を担当するトランザクションハンドラ６０９に転送する。セグメントハンドラからトランザクションハッシュを受信すると、トランザクションハンドラ６０９は、そのメモリプール内の関連するトランザクションレコードを調べる。
トランザクションがメモリプールから欠落している場合、トランザクションハンドラ６０９は、（６２２を介して）要求を送信し、（６２３を介して）好ましくはトランザクションのマイニングを担当するマイニングノードにおけるトランザクションハンドラから欠落した未処理のトランザクションを受信する。この要求／応答アクションは、優先度の高い方法で迅速に処理されることが好ましい。欠落した未処理のトランザクションを受信すると、トランザクションのブロック割り当ての検証を再開する前に、トランザクションハンドラ６０９は、トランザクションをメモリプールに追加する前に、上述したようにトランザクションを有効化する必要がある。
そのメモリプールからトランザクションを正常に取得すると、トランザクションハンドラは、上述したようにローカルにマイニングされているブロックにトランザクションを割り当てるのと同じように、検証されているブロックセグメントへのトランザクションの割り当てを実行する。しかしながら、割り当てが失敗した場合、セグメントおよびそれがその一部であるブロックの検証は失敗する（すなわち、ブロックは拒否される）。
その後、ノードコーディネータは、所定のコンセンサスアルゴリズムを適用して、ブロックを確定することを決定する。このため、ノードコーディネータは、ブロックヘッダを永続化し、ノードのセグメントハンドラにブロックを確定するように指示する。そうすることで、ノードコーディネータは、ブロック・マークル・ツリー全体を各セグメントハンドラに提供する。次に、各セグメントハンドラは、ブロックに関連付けられたセグメントのセットを永続化し、関連するトランザクションハンドラにブロックを確定するように指示する。そうすることで、セグメントハンドラは、各トランザクションハンドラがそのセグメントのセットに必要とするブロック全体のマークルツリーの一部を生成してトランザクションハンドラに提供する。次に、各トランザクションハンドラは、そのアクティブなメモリプールから確定されたトランザクションを削除し、特に、トランザクションハンドラがセグメントハンドラから受信したブロックの全体的なマークルツリーの一部から派生したマークル証明を使用して、確定されたトランザクションについてエッジ（またはウォレット）から受信した任意の未処理のトランザクション要求に応答する。そして、トランザクションハンドラは、トランザクションの処理に関してトランザクションハンドラが受信することができる後続のクエリをサポートするために使用されることができる場合、確定されたトランザクションをメモリに保存する。次に、トランザクションハンドラは、ブロックを確定するように全てのＵＴＸＯハンドラに指示する。それに応じて、ＵＴＸＯハンドラは、確定されたブロックにおいて使用されたＵＴＸＯを永続的に使用済みとしてマークし、確定されたブロックに割り当てられたＵＴＸＯを永続的に作成済みとしてマークする。したがって、このようにブロックヘッダおよびセグメントをディスクに永続化することは、ブロックチェーンにブロックを追加する。実装に応じて、ブロックチェーンにそのように書き込まれたブロックは、最終的なものと見なされることができる（したがって、実質的に不変である）。
要約すると、上述したノード処理では、トランザクションハンドラは、通常はエッジマシンから未処理のトランザクションを受信する。トランザクションハンドラが未処理のトランザクションを有効化（およびローカルメモリプールに配置）した後、トランザクションハンドラは、未処理のトランザクションを、その未処理のトランザクションの有効化も担当する他のノードの適切なトランザクションハンドラに伝播する。その後、ブロックセグメントのマイニングを開始するというノードコーディネータの決定に応じて、トランザクションハンドラは、そのメモリプールからブロックセグメントに未処理のトランザクションのセットをマイニングし（割り当て）、各セグメントを処理している要求元のセグメントハンドラにそれらの未処理のトランザクション（およびそれらの関連するダイジェスト）を送信する。セグメントハンドラは、受信したトランザクションをセグメントにシーケンス化し、その際、セグメントハンドラは、セグメントを構成するトランザクションのダイジェストのリストを、他のマイナーノードにおいてそれらのセグメントの処理を担当する他のセグメントハンドラに転送する。したがって、未処理のトランザクションは、全てのノードのトランザクションハンドラ全体に伝播するが、セグメントハンドラは、検証されることになるセグメントのトランザクションダイジェストのみを送信するのが好ましい。ブロックセグメントのマイニングおよび検証中に、トランザクションハンドラは、上述したように他のノードのセグメントハンドラと通信する、それらのローカルセグメントハンドラを参照する。したがって、異なるノードのトランザクションハンドラは、互いに通信して、（ＵＴＸＯおよび署名検証機能を使用して）それらの各メモリプールに有効化されたトランザクションを投入する。セグメントハンドラ（したがって、マイニングを処理するノードコーディネータ）は、互いに通信して、ブロックチェーンにセグメントを含むブロックを投入する。前述のように、トランザクションハンドラおよびセグメントハンドラは、別個のサービスである必要はない。
上述したように、ブロック検証は、ブロックマイニングと同様である。ただし、検証の場合は、セグメントハンドラがトランザクションハッシュをそのトランザクションハンドラに供給しており、そのトランザクションハンドラは「有効」（未処理のトランザクションに関して）または「無効」（受信したブロック全体に関して）の応答を示すが、後者の応答は、マイナーが誤ってまたは敵対的に行動している場合を除き発生してはならないことを除く。マークルツリーおよびルートを生成および処理する上述した技術は、トランザクションをそれらのブロックに結び付ける好ましい暗号化機構である。検証中、および完了時に、ノードコーディネータが全てのセグメントハンドラから結果を取得すると、コーディネータは、ブロック全体のマークルルートを再度計算するが、今回は、そのルートを、マイニングブロックコーディネータによって送信されたブロックヘッダに提供されるルートと比較する。それらがマッチしない場合、ブロックは、無効として破棄される。
本明細書で使用される用語は、限定を意図するものではない。本明細書において使用される場合、「有効化」という用語は、そのメモリプールに入れられる未処理のトランザクションを受信したときにトランザクションハンドラが実行する動作のために使用される。上記のように、トランザクションを有効化するために、トランザクションハンドラは、ＵＴＸＯハンドラにクエリを出して、参照されているＵＴＸＯの利用可能性を確認し、（入力の）署名を確認するために署名検証部と会話する。対照的に、「検証」という用語は、ノードコーディネータによって開始されたコンセンサスを同様に実行している他のノードから受信したブロックセグメントのコンテンツを検証する行為のために使用される。トランザクション有効化はまた、「ブロックセグメント検証」（コーディネータおよびセグメントハンドラが他のノードから受信したブロックセグメントデータに対して行う処理）との対比で、コーディネータが（ブロックセグメントを含む）ブロックに対してマイニング動作を開始したことに応答する、「初期トランザクション検証」と見なすこともできる。また、「マイニング」という用語は、「割り当て」と呼ばれることもあり、これは、トランザクションをブロックセグメントに割り当てまたは関連付けるようにセグメントハンドラによって指示されたときにトランザクションハンドラが実行すること、すなわち、セグメントハンドラによるブロックセグメントへのその組み込みに関するトランザクションのトランザクションハンドラによる検証を意味する。上記のように、これを達成するために、トランザクションハンドラは、そのＵＴＸＯハンドラと通信して、既存のＵＴＸＯを「使用」し、新たなＵＴＸＯをブロックセグメントに「割り当てる」。
また、「ハンドラ」の概念は、限定を意図するものではない。ハンドラは、本明細書では「コーディネータ」と呼ばれることがあり、ハンドラの基本的な動作または機能は、プロセス、プログラム、インスタンス、実行スレッド、プログラム命令セットなどとして実装することができる。
上記は好ましい動作を説明しているが、ハンドラがそのタスクを単数で処理する必要はない。したがって、セグメントハンドラは、ブロックを構成するセグメントの一部または全てを処理することができる。トランザクションハンドラは、特定の、または複数の（さらには全ての）セグメントに属するトランザクションを処理することができる。ＵＴＸＯハンドラは、ＵＴＸＯ空間内の一部または全てのパーティションを処理することができる。ここでの「パーティション」という用語は、セグメントから区別するために便宜上使用されているが、いずれの用語も限定とみなれるべきではない。
以下は、好ましい実装における上述したノードコンポーネントに関する追加の詳細を提供する。
ノードの調整（コーディネーション）
ノードコーディネータ６０１は、ネットワーク・コンセンサス・アルゴリズムに参加して、ノードがブロックをマイニングするかどうか、および他のどのノードからマイニングされたブロックデータを受信することを予期すべきかを決定する。ノードがブロックをマイニングする場合、ノードコーディネータ６０１は、メッセージを（６０２を介して）ネットワーク内の他のノードコーディネータに送信する。ノードコーディネータ６０１はまた、ブロックをマイニングしているノード内の他のノードコーディネータから（６０３を介して）メッセージを受信する。説明したように、ノードコーディネータ６０１は、（６０５を介して）ノードのセグメントハンドラ６０４に対してメッセージの形で、ブロックセグメントのマイニングを開始することと、他のいずれかのノードからマイニングされたブロックセグメントを受信して有効化するかを通知する。ノードのセグメントハンドラ６０４は、各ブロックセグメントを構成するトランザクションのマークルルートを（６０６を介して）メッセージの形でノードコーディネータ６０１に返す。
ノード調整の他の態様は、任意の所与の時点でネットワークにおいてアクティブになっている可能性がある１つ以上のチェーンブランチに対応するノードローカル表現を管理することである。通常、ブロックチェーンは、確定の時点までの単一のブロックシーケンスから構成される。確定は、多くの場合、チェーン内のいくつかの深いブロックに設定されるが、確定する内容とタイミングの決定は、ネットワーク全体のコンセンサスを管理するルールにしたがう。予め確定されるブロックチェーンの部分は、確定前に解決される可能性のある複数のブランチチェーンから構成される。上記のように、例えば、複数のノードが同時にマイニングする場合、それらは、いくつかの共通の祖先ブロックを有する複数のブランチにブロックチェーンをフォークする。ノードコーディネータ６０１は、アクティブなブランチを追跡し、ノードがマイニングしている場合、それらがマイニングしているブランチ、および各リモートマイナーがマイニングしているブランチを、セグメントハンドラ６０４に通知する責を担う。
セグメント処理
また説明されるように、セグメントハンドラ６０４は、ブロックセグメンテーション空間の一部を表すいくつかのブロックセグメントの生成および／または有効化を処理する。具体的には、セグメントハンドラは、（６０５を介して）メッセージの形でノードコーディネータ６０１によって指示されたようにブロックセグメントの生成を開始する。マイニングするとき、セグメントハンドラ６０４は、６０７を介して、マイニングされたブロックセグメントデータを、検証される他のノードのセグメントハンドラに送信する。セグメントハンドラ６０４は、（６０８を介して）メッセージの形でマイニングノードのセグメントハンドラからブロックセグメントデータを受信する。トランザクションのマイニングおよび有効化を実行するために、セグメントハンドラ６０４は、また前述したように、関連するトランザクションハンドラのセット６０９と相互作用する。
トランザクション処理
トランザクションハンドラ６０９は、メモリプールに追加されてネットワークに伝播されるトランザクションの有効化、マイニングされたブロックに含まれるトランザクションの生成、およびマイニングノードから受信したブロックの一部として含まれるトランザクションの検証を処理する。上記のように、トランザクションセグメンテーション空間の分布は、トランザクションハンドラ６０９とセグメントハンドラ６０４とで同じであってもよく、または異なっていてもよい。例えば、セグメントハンドラ機能によって必要とされる計算リソースは、ごく少数のそのようなハンドラが全てのブロックセグメントを処理するために使用される程度に十分に少なくてもよいのに対して、トランザクションハンドラ機能によって必要とされる計算リソースは、そのような各ハンドラが関連するセグメントハンドラ６０４よりも少ない数のセグメントのトランザクションを管理することが必要となる程度に十分多くなる可能性がある。
トランザクションハンドラ機能は、また前述したように、システムにおける他の重要な役割、すなわち、トランザクションアドミッション（「有効化」とも呼ばれる）および伝播を果たす。トランザクションハンドラ６０９は、エッジから直接的にまたはネットワーク内の他のトランザクションハンドラを介して間接的に（６１２を介して）メッセージの形でトランザクションを受信する。トランザクションハンドラ６０９は、受信した全てのトランザクションを有効化し、有効な場合、トランザクションを未処理のトランザクションのプール（そのメモリプール）に保存し、随意にトランザクションをメッセージの形でネットワーク内の他のノードに伝播する（６１３を介して）。このように、トランザクションハンドラ機能は、全てのノードが全ての到来トランザクションおよび関連する到来トランザクションダイジェストを適時に且つ効率的な方法で受信するように、トランザクションデータの伝播を編成する。
ＵＴＸＯの処理
好ましくは、ＵＴＸＯは、発信トランザクションのハッシュまたはダイジェストである識別子（ｔｘｉｄ）、および発信トランザクションにおける出力のインデックスによって識別される。ＵＴＸＯはまた、２つの他の情報部分（その識別には使用されない）、すなわち、値および「ロックスクリプト」を有する。一般に、ロックスクリプトは、指示のセットまたは単に出力に関連付けられた公開鍵である。公開鍵は、アドレスまたはウォレットアドレスと呼ばれることもある。ロックスクリプト（例えば、公開鍵）は、値とともにトランザクションの出力において伝達され、通常、ＵＴＸＯ識別情報およびその値とともにＵＴＸＯデータベースに記憶される。したがって、初期トランザクション有効化時にＵＴＸＯハンドラにクエリを出すと、値およびロックスクリプト（公開鍵）の双方を返す。ＵＴＸＯを新たなトランザクションへの入力として使用するために、新たなトランザクション（基本的にはその出力）は、使用されるＵＴＸＯの公開鍵と暗号的にマッチする秘密鍵によって署名される必要がある。この署名は、各トランザクション入力で提供され、一般に「ロック解除スクリプト」と呼ばれる。ロック解除スクリプトは、指示のセットまたは単にデジタル署名とすることができる。したがって、デジタル署名は、トランザクションの出力値を、値の受信者がおそらく対応する秘密鍵（後でロック解除スクリプトの作成に使用される）を有するロックスクリプト（公開鍵）にバインドする。署名検証部は、（ウォレットまたはその暗号化要素のみが秘密鍵を有するため）秘密鍵を有しない。署名検証部は、（ロックスクリプトからの）公開鍵および（ロック解除スクリプトからの）署名を受信し、署名検証部は、公開鍵に対して署名を検証し、それにより、マッチする秘密鍵によって署名が作成されたことを証明する。要約すると、所与のインデックスにおけるトランザクション出力は、ロックスクリプト（公開鍵）および値を有する。トランザクション入力は、発信元のｔｘｉｄ、インデックス、およびロック解除スクリプト（署名）を有する。
トランザクションを処理するために、上記のように、トランザクションハンドラは、（６１５および６２０を介して）メッセージによってＵＴＸＯハンドラ６１４のセットと相互作用し、各トランザクションに関連付けられた未使用のトランザクション出力（ＵＴＸＯ）を作成し、クエリを出し、使用し、および割り当てる。各ＵＴＸＯ動作はまた、（６２０を介して）メッセージの形の取り消し要求を用いて逆行することもできる。この可逆性は、トランザクションが全体として完了できなかった場合に、トランザクションハンドラ６０９が首尾よく完了することができたトランザクションの部分を取り消すことを可能にすることから、価値がある。同時並行性を可能にし且つ競合を防止するためにＵＴＸＯデータベースをロックする代わりに、ここでシステムは、競合の検出および部分的に完了したトランザクションのＵＴＸＯ動作の逆行に頼ることが好ましい。この文脈における競合は、これらに限定されるものではないが、（ポリシーが規定するところに応じて）それが存在するかまたは確定される前にＵＴＸＯを使用する試み、他のトランザクションによって既に使用されているＵＴＸＯの使用、またはトランザクションを不完全な状態にする任意の他のＵＴＸＯ動作の失敗を含む。
上記のように、各ＵＴＸＯは、有効化するためにトランザクションについて正常に実行される必要がある値およびロックスクリプトを有する。スクリプトは、他のトランザクションへの入力としてＵＴＸＯの使用をロックするために実行される必要がある指示のセットである。通常、スクリプトは、ＵＴＸＯを入力として使用するトランザクションに署名するために使用される必要がある秘密鍵に対応する公開鍵素材を含む。
累積するＵＴＸＯの数は大きくなる可能性があることから、ＵＴＸＯ空間はまた、ブロックがトランザクション識別子によってセグメント化されるのと同様の方法でトランザクション識別子によってパーティション化されることが好ましいが、パーティション化空間およびセグメンテーション空間は、独立してそれぞれのニーズに応じて分割されることが好ましい。ＵＴＸＯ処理は、ＵＴＸＯを生成するトランザクションハンドラによって実行されることができるが、ＵＴＸＯの処理は、以下の２つの理由のためにトランザクション処理から分離されることが好ましい：（１）リソース要求が異なるため、および（２）トランザクションハンドラ機能を分離することが、トランザクションおよびＵＴＸＯハンドラがより効率的に実行することを可能にするため。好ましくは、ＵＴＸＯ空間はまた、ノードの集約メモリおよび記憶リソースをより効率的に使用するためにパーティション化される。このセグメンテーションを適用することにより（すなわち、トランザクションセグメンテーション空間を介して）、高度にスケーラブルでタイミングが制約されたソリューションが提供される。
署名検証
図６Ａのブロック図の最後の要素は、署名検証部６１７のセットによって提供される署名検証機能である。上記のように、トランザクションは、トランザクションの入力に関連付けられた秘密鍵のセットによって署名されることが好ましい。ノードにおいて最も計算量の多いタスクは、トランザクションの署名を検証することである。そのため、重要な計算リソースは、好ましくは署名検証専用である。各署名検証部６１７は、署名検証負荷の一部をサポートするのに必要な計算リソースを利用することが好ましく、トランザクションハンドラ機能は、（６１８を介して）メッセージを使用して利用可能な署名検証部６１７のセット全体に署名検証負荷を分散させ、有効化されることになるデータを送信し、（６１９を介して）返信としてメッセージの形で肯定応答または否定応答を受信する。一実施形態では、これらの動作は、署名検証をいくつかの他の処理（例えば、トランザクション処理）と組み合わせることによって実行される。他の実施形態では、図示および説明されるように、より高いスケーラビリティを可能にするために、他の要素から分離した署名検証部６１７を有効にすることにより、処理要求に対応する。
ブロックの生成、送信、および検証のパイプライン化
図７を参照すると、従来のブロックチェーンベースのシステムは、ブロックの生成（マイニング）、送信、および検証をシリアル化する。そのようなシステムでは、マイナーによってブロックが生成され（７０１）、ブロックの生成が完了すると、ブロックは検証のために他のノードに送信され（７０２）、ノードがブロックの受信を完了すると、それらはブロックの検証を開始する（７０３）。そのようなシリアルベースの処理は、特に前述の動作文脈、すなわち、潜在的にグローバルベースのネットワークにわたってトランザクションメッセージが生成されている場合、非効率的であり、スケーリングしない。
例えば、１秒あたり数百万のリアルタイムトランザクションを処理することができるなど、高い性能要件を有するシステムを構築しようとする場合、そのような現在の実装アプローチは、完全に不十分である。このため、本明細書のアプローチでは（および上述したように）、これらの処理ステージは、同時並行性のためにパイプライン化される。したがって、本明細書の技術によれば、マイナーがブロックデータを生成する（７０４）一方で、以前に生成されたブロックデータは、検証のためにノードに送信される（７０５）。検証ノードは、完全なブロックを受信する前に、且つおそらくはマイナーがブロックのマイニングを完了するずっと前に、マイニングされたブロックデータを受信し、ブロックのトランザクションの検証を開始する（７０６）。
図５によれば、ブロックの生成、送信、および検証のパイプラインもまた、ブロックの各セグメント毎にインスタンス化され、したがって、ブロックセグメントが並列に動作されることを理解されたい。その結果、並列処理およびパイプライン処理を組み合わせることにより、同時並行性が向上する。
ブロック生成、送信、および有効化のストリーミング
図８を参照すると、パイプライン化されたブロックの生成、送信、および検証をサポートするために、ストリーミングされたブロックセグメントの生成、送信、および検証プロセスが、２つのノード、すなわち、マイナーノード８０１と検証ノード８０５との間で示されている。１つの検証ノード８０５が示されているが、上述したように、通常、ネットワーク内の全てのノードは、マイニングされたブロックを検証する。また説明したように、このプロセスはまた、通常、マイナーノード８０１によってマイニングされる他のブロックセグメントの同じプロセスと同時に実行される。上記のように、ネットワーク内で同時に動作する、複数のマイナーノード８０１と、複数のストリーミングされた生成、送信、および有効化プロセスが存在することができる。この例では、永続化のためにセグメントをステージングする責任は、前述のように、セグメントハンドラではなくトランザクションハンドラに関連付けられることに留意されたい。
生成
図８に示すように、プロセスは、マイニングノードコーディネータ８０２がネットワーク上のブロックをマイニングするための基準を満たしたときに開始される。一実施形態では、この基準は、それが満たすことをマイナーが証明することができる確率条件（例えば、ある閾値を下回る信頼できるあるいは検証可能な乱数）とすることができる。マイナー選択（リーダー選出）の任意の基準が適用可能である。ノードコーディネータ８０２は、メッセージ８０９を送信して、マイニングノードセグメントハンドラ８０３がブロックセグメントの生成を開始することを要求する。ノードコーディネータ８０２はまた、マイナーノードのセグメントハンドラ８０３からのマイニングされたブロックセグメントを予期するように有効化ノードのコーディネータ８０６に指示するメッセージ８１０を送信する。各マイニングセグメントハンドラ８０３は、トランザクションハンドラ８０４が各々に関連付けられて収集された未処理のトランザクションのプールからブロックへのトランザクションの割り当てを開始することを指示するメッセージ８１１を、関連するトランザクションハンドラ８０４に送信する。トランザクションハンドラ８０４は、（直接的にまたは他のノードのトランザクションハンドラを介して）エッジから受信した未処理のトランザクション（ブロックまたはその任意の祖先に対して以前に割り当てられていなかったトランザクション）を繰り返し検査する。トランザクション検証（上述したトランザクション有効化）のいくつかの態様は、トランザクションが最初に受信されたときに事前に実行されることができることを理解されたい。検証済みのトランザクション割り当てごとに、トランザクションハンドラ８０４は、（１）完全なトランザクションレコード８１３をブロックセグメント８３１に追加し、（２）ダイジェスト（例えば、ハッシュ）を含むメッセージ８１４をストリームの形でセグメントハンドラ８０３に送信する。
送信
セグメントハンドラ８０３は、メッセージのストリーム８１４から１つ以上のトランザクションダイジェストを収集し、メッセージのストリーム８１５の形でトランザクションダイジェストを、生成されたセグメントデータの有効化を担当する各有効化ノード８０５におけるセグメントハンドラ８０７に送信する。示されるように、メッセージのストリーム８１４におけるメッセージの数は、メッセージのストリーム８１５におけるメッセージの数とは異なることができるが、双方のストリームにおいて送信されるトランザクションダイジェストの総数は、通常同じである。
ノード８０５を有効化する際に、セグメントハンドラ８０７は、メッセージのストリーム８１５を受信し、トランザクションダイジェストを抽出し、１つ以上のメッセージ８１６をトランザクションハンドラ８０８に送信する。メッセージのストリーム８１５および８１６を構成するメッセージの数は、異なることができる。この実施形態では、送信されたメッセージ８１０、メッセージ８３３で終わるメッセージのストリーム８１５、およびメッセージ８２３は、ノード要素からノード要素に直接的にユニキャストまたはマルチキャストで送信され、他のノードの要素を介して間接的に伝播され、またはネットワーク要素を介してルーティングもしくは転送されることができる。データは、集約または分離されて移動することができる。
検証
検証トランザクションハンドラ８０８は、トランザクションダイジェストを受信し、（他のノードのトランザクションコーディネータを介して直接）エッジから受信した未処理のトランザクションを検索する。検索が成功すると、それは、トランザクションの割り当てを検証する。検証が成功すると、トランザクションハンドラ８０８は、（１）メッセージ８１８において検証確認をセグメントハンドラ８０７に送信し、（２）完全なトランザクションレコード８１７をブロックセグメント８３２に追加する。
ストリーム処理の終了
一実施形態では、ストリーミング生成、送信、および検証プロセスは、マイニングノードコーディネータ８０２が生成停止メッセージ８１９を全てのマイニングセグメントハンドラ８０３に送信すると終了する。このシナリオでは、ノードは、非同期で動作し、実行ラウンド間に明示的な時間境界がないものと仮定される。他の実施形態では、ノードは、同期して動作することができ、プロセスは、特定の時間に到達したときに終了する。
プロセスが終了すると、各セグメントハンドラ８０３は、生成停止メッセージ８２０をその関連するトランザクションハンドラ８０４に送信する。各トランザクションハンドラ８０４はまだ進行中の任意のトランザクション割り当てを終了または中止し、セグメントハンドラ８０３に対するメッセージ８２１の形で、ブロックセグメントに含まれる任意の残りの割り当てられたトランザクションとともにマイニングを停止したことを認める。
セグメントハンドラ８０３は、任意の未送信のトランザクションハッシュとストリームの終わりの指示とをメッセージ８３３の形で有効化ノードのセグメントハンドラ８０７に送信する。各セグメントハンドラ８０３は、各セグメントのトランザクションハッシュからマークルツリーを計算し、メッセージ８２２においてノードコーディネータ８０２にマークルツリールート（マークルルートまたはＭＲ）を送信する。ノードコーディネータ８０２は、ブロックの全てのセグメントのマークルルートを受信すると、セグメントのマークルルートからブロック全体のマークルツリーの上部を計算し、前のブロックヘッダのハッシュ、そのマイニング証明、およびブロック全体のマークルルート、ならびにその他のデータから構成されるブロックヘッダを生成する。失敗すると、ノードコーディネータ８０２はパージメッセージ８２７を各セグメントハンドラ８０３に送信し、次に、各セグメントハンドラがパージメッセージ８２８をその関連するトランザクションハンドラ８０４に送信し、次いでトランザクションハンドラがブロックセグメントを破棄する。成功すると、ノードコーディネータ８０２は、メッセージ８２３の形でブロックヘッダを全ての有効化ノードコーディネータ８０６に送信する。
各検証ノードのセグメントハンドラ８０７がメッセージ８３３の形でストリームの終わりの指示を受信すると、それらは、次に、それらの関連するトランザクションハンドラ８０８に、ストリームの終わりの検証を指示するメッセージ８３４を送信する。各セグメントハンドラ８０７は、その関連するトランザクションコーディネータ８０８から全ての未処理のトランザクション割り当て検証の確認を受信すると、そのセグメントのマークルツリーを計算し、メッセージ８２４における各セグメントのマークルルートを検証ノードコーディネータ８０６に送信する。検証ノードコーディネータが各セグメントのマークルルートを受信すると、ブロックヘッダを生成し、生成されたブロックヘッダがメッセージ８２３の形で受信したブロックヘッダとマッチすることを検証する。ブロックヘッダがマッチしない場合には、パージメッセージ８２５を各有効化セグメントハンドラ８０７に送信し、次に、各検証セグメントハンドラがパージメッセージ８２６をその関連するトランザクションハンドラ８０８に送信し、次いでトランザクションハンドラがブロックセグメントを破棄する。
ブロックの確定
上述のように、上述したシステムでは、ブロックは、それが確定されるまで永続化されていない。好ましくは、ブロックは、ノードコーディネータが規定されたコンセンサスアルゴリズムに準拠して確定されるべきだと結論付けるまでは、確定されない。対照的に、好ましくはマイニングの終わりでは、ブロックは永続化されていない。むしろ、マイニング後、ブロックは、（コンセンサスアルゴリズムにしたがって）確定されるまで、またはコンセンサスアルゴリズムの適用に耐えられなかったことから破棄（パージ）されるまで、追跡されるだけである。
したがって、上述したように、このアプローチは、ブロックセグメンテーションおよび他の上述した特徴（例えば、トポロジ認識データ伝播、非ブロッキングアーキテクチャ、楽観的同時並行制御、パーティション化、マルチキャストおよびその他の特徴）と組み合わせて、高品質、低レイテンシ、高度に相互接続されたコアネットワーク（メッシュ）を活用することにより、中央のいかなるトランザクションのルーティングまたはスイッチング（例えば、大量のトランザクションのルートを占める必要があるレイヤ７スイッチ）も用いることなく、計算効率の高いトランザクション処理システムを提供する。好ましくは、アーキテクチャは、グローバルＣＤＮネットワークと組み合わせて使用され、グローバルな範囲を提供し、このアプローチは、コアネットワークにおけるコンピューティング要素を発見して相互作用するために、ＣＤＮマッピング技術が（例えば、クライアントおよび他のトランザクションサービスにより）便利に活用されることを有利に可能にする。
暗号化サーバのサポート
説明してきたような分散型記録システムの別の態様には、商業用途における使用に必要な、高性能ならびに高レベルな安全性、セキュリティ、および信頼性を可能にする、許可されたネットワーク環境を構築することを伴う。無許可のオープンなインターネットとは異なり、システムの様々な要素は、例えば、公開鍵基盤（ＰＫＩ）に依拠して信頼の鎖（ｃｈａｉｎ ｏｆ ｔｒｕｓｔ）、信頼境界（ｔｒｕｓｔ ｂｏｕｎｄａｒｙ）、セキュアな運用管理フィーチャーを確立し、コンセンサス、リーダ選出、フォーク防止および抑止などの特定の局面を推し進めることが好ましい。
上述のように、上述のオーバーレイネットワークベースの設計では、周辺機器、エッジ、およびコア要素は、相互認証済の暗号化接続を介して互いに通信することが好ましい。この環境では、このような接続を確立するために使用される鍵の流出および悪用を防ぐことが望ましい。さらには、やはり上述したように、コアネットワーク内のコンピューティングノードは、通常ブロックを生成する（マイニングする）ノードの真正性を有効化するために用いられる１つ以上の公開鍵／秘密鍵の対を有する。さらには、生成されたブロックを有効化するノードは、通常それらの鍵を使用して、ブロックに署名することによりあるブロックの有効性をエンドースする。通常の動作環境では、公開鍵／秘密鍵の対は乱数シーケンスを作製するためにも使用され、乱数シーケンスは次いでマイナーを選択するために、および／または潜在的にマイナーのサブセットを選択して複数の予め確定されるチェーンを剪定するために使用される。これらの事例の全てにおいて、秘密鍵のあらゆるセキュリティ侵害は、潜在的なセキュリティ上の懸念を生じさせる。その上、（上述してきたような）コンセンサスベースのコアネットワークに関して、最大何らかの数までのセキュリティを侵害されたノードで正確性が保証される。したがって、秘密鍵を保護すること、およびそれらの使用を可能にするデータを検証することは、広範なネットワークセキュリティ侵害に対する多層防御（ｄｅｆｅｎｓｅ－ｉｎ－ｄｅｐｔｈ）および軽減策をもたらす。実際、ウォレットが関与する信頼できるコンピューティング環境では、それらの使用を可能にする秘密鍵を保護すること、およびデータを検証することは（以下で説明するように）、物理的セキュリティ侵害およびネットワークベースのセキュリティ侵害の両方に対する防御の第一線を提供する。鍵のセキュリティ侵害のリスクを軽減するために、セキュアなサーバベースの技術（本明細書では時に「暗号化サーバ（ＣＳ：ｃｒｙｐｔｏｓｅｒｖｅｒ）」と称される）を使用して、分散型記録システムの様々な部分に１つ以上の暗号化サポートサービス（すなわち「暗号化サービス」）を備えることにより、その使用を可能にする秘密鍵およびロジックが周辺、エッジ、およびコアサービス実行環境から切り離されることが好ましい。暗号化サービスは特に秘密鍵を秘匿し、悪用されないよう安全にしておくために用いられる高度なセキュリティプロファイルを提供するように設計される。
したがって、一態様では、説明したような暗号化サービスを使用してウォレットの秘密鍵を保護することができる。例えば、トランザクションは、受取人ウォレットが公開鍵とともに金額を支払人ウォレットに提供することで開始する場合がある。支払人ウォレットは秘密鍵を所有していない。代わりに、受取人ウォレットは、暗号化サービスにより維持される秘密鍵に関連付けられる情報を所有することが好ましい。それに応じて、支払人ウォレットは暗号化サービスに、好ましくはセキュア且つ相互認証済の通信を使用して、要求を送信する。要求は、秘密鍵に関連付けられた情報を含むデータを、署名されるトランザクションデータ（または、トランザクションデータのダイジェスト、またはハッシュ）とともに含むことが好ましい。暗号化サービスはトランザクションデータおよび関連付けられた秘密鍵情報を検証し、提供されたデータ（またはその一部）に対して署名を行い、応答として署名を返す。署名されたトランザクションは、記録システムに追加される。代表的な使用例では、受取人ウォレットから支払人ウォレットに送信されたデータは、限定なく、レガシーＩＳＯ－８５８３メッセージ、新しいまたは既存の他の決済またはトランザクションＡＰＩメッセージ、パスコード、ＰＩＮなどを含む任意のデータであることができる。このアプローチの利点は、支払人ウォレットへのインターフェースが公開であり、且つ進化することができる一方で、支払人ウォレットと暗号化サービスとの間のインターフェースは秘密であり、且つ安定的なままであり、これにより攻撃表面としての脆弱性を大幅に低減できることである。暗号化サービスを使用することのさらなる利点は、これにより支払人ウォレットに与えられるデータを使用して台帳にポストされるトランザクションを構築することが可能になることである。その上、元々のデータおよび暗号化サービスに送信される構築されたトランザクションの両方を用いて、本アプローチは元々のデータの検証、ならびに構築されたトランザクションがその正しい表現であることの検証を（暗号化サービスにより）可能にする。
上述の構成には多くの変形例がある。例えば、暗号化サービスは、ネットワークを介してアクセス可能である場合があるが、同一のマシンまたはデバイス上で、セキュアエンクレーブなどの、切り離されて保護された（おそらくは暗号化されて）メモリ空間に存在していてもよい。さらには、単一の暗号化サービスが、または暗号化サービスの小型のセットとして、複数の（おそらくは多数の）ウォレットの鍵を保護するために使用することができる。
暗号化サービスは、ブロック生成（マイニング）および有効化のために使用される秘密鍵を保護するためにも使用される場合がある。この態様では、ブロック生成および有効化アクティビティは、公開鍵基盤（ＰＫＩ）で強化され、それによりブロックは、その内容により単に有効化されるだけではなく、マイニングノードの真正性によっても有効化される。したがって、説明してきたように、例えばマイナーがブロック（またはその一部）を生成していると想定する。述べたように、通常ブロックのヘッダは、ブロックが依存する先行ブロックのハッシュなどの様々な情報を含む。ブロックのヘッダに含まれる通常の情報に加え、システムはブロックをマイニングするノードがそのブロックに署名することを要求することができる。そのような文脈では、そのような目的に用いられる１つ以上の秘密鍵がセキュアなままであることが重要である。この目的のために、暗号化サービスは、秘密鍵の流出および悪用のリスクを、このような鍵をアプリケーションおよびサービスロジックから切り離しておくことにより、軽減する。この文脈では、マイナーによって検証され署名されるものは、ブロック属性、ブロックに含まれるあらゆる他のデータ、生成時点のシステムの状態、以前マイニングされたブロックに含まれる署名など、これらに限定されるものではないが、任意のものであり得る。
好ましくは、信頼できるコンピューティング環境を用いて暗号化サービスを提供する。一実装の実施形態では、暗号化サービス（または暗号化サーバ）は、通常、トランザクションネットワークに関連付けられる鍵管理システムとシームレスに相互運用する、各トランザクションネットワークサーバ（例えばウォレットサービス多ウォレットプロセッサ）に付属する、ネットワーク化セキュリティ機器を備える。
代表的な暗号化サービスは、米国特許第９，６４７，８３５号明細書に記載されているようなものであり、その開示は、参照により本明細書に組み込まれる。そこで説明されるように、代表的なサーバ側（暗号化サーバ（ＣＳ））プロセスは、物理的なセキュリティを有しオーバーレイネットワークエッジサーバの実行環境とは異なる実行環境で実行される。暗号化サーバデーモンは、負荷をレポートするネットワークからの入来要求を管理すること、ならびにログおよび関連情報を生成する役目を果たす。この信頼できるコンピューティング環境により保護されるシークレット（例えば、秘密鍵）は、例えばデーモンだけがアクセス可能な信頼できるハードウェアに記憶されることにより、セキュアに維持される。このタイプの信頼できるコンピューティング環境は、Ｉｎｔｅｌ（Ｒ）ＳＧＸ（Ｓｏｆｔｗａｒｅ Ｇｕａｒｄ Ｅｘｔｅｎｓｉｏｎｓ）によりサポートされるもの、または付属の好ましくはプログラム可能なハードウェアセキュリティモジュール（「ＨＳＭ」または、エンクレーブ）などのＨＳＭを活用することができる。代表的な実施形態では、暗号化サービスはケージ化されたネットワークセットアップ内で、エンクレーブにより保護された秘密鍵（または他のシークレット）を用いて実行する。エンクレーブは、通常、静的にコンパイルされ、ＢＩＯＳおよびカーネルのサポートを必要とし、エンクレーブは同じ場所に配置されていない（ダイ上にない）いかなるハードウェアまたはソフトウェアとも対話しない、および対話できないことが好ましい。上述のコンポーネントが好ましいが、あらゆるメモリ暗号化の信頼できるコンピューティング要素を、これらの目的に使用することができる。
暗号化サービスは、それぞれが多数のトランザクションを扱う数百または数千に至る暗号化サーバを含むネットワークベースのサービスを含む場合がある。システムのコンピューティングノードは、説明したような信頼できるコンピューティング環境に関連付けられていることが好ましい。より一般的には、コンポーネント自身のいずれもが信頼されない、または信頼できるコンポーネントのセットが少ない（説明したような）動作シナリオにおいても、セキュアな（信頼できる）サービスが、コンポーネント上に構築される。特に、説明したように、ブロックチェーンネットワークのコンピューティングノードは、互いを信頼する必要はなく、一般にウォレットは、台帳が有効であること、およびトランザクションがその台帳上にあることの暗号法的証明を必要とする限りは、台帳を信頼しない。台帳上のトランザクションは、トランザクション入力ごとに個々に署名され、したがって自己検証可能であることが好ましい。換言すると、台帳サービスを提供するコンピューティングノードを必ずしも信頼することなく、台帳を信頼することができる。
コンセンサス
ブロックチェーンコンセンサスプロセスはマイニングに依存しており、上記のように、マイニングは通常ブロックチェーンにおける前のブロックを参照するヘッダを有する順序付けられたトランザクションのブロックを生成する行為である。やはり上述のように、トランザクションおよび金融処理システムでは、サブコミティ選出、リーダ選出、またはマイナー選択に乱数が用いられることが多い。ランダムオラクルを使用して乱数を生成することができ、これらの数字は予見可能（すなわち、予測可能）、操作可能（すなわち、影響を受ける可能性がある）、そして偽造可能（すなわち、それらが検証可能である）であってはならない。やはり上述のように、ランダムオラクルはアルゴリズム的、検証可能、および／または決定論的な疑似乱数に基づくこともできる。
追加的なバックグラウンドとして、リーダ選出およびマイナー選択は、所定の時間に行われる活動である。ブロックチェーンシステムでは、例示のシナリオとして、定期的な間隔、システム初期化、システムまたはコンポーネントのエラーおよび障害回復、ならびにブロック生成事象の開始／停止が挙げられるが、これらに限定されない。
本明細書において説明される分散型記録システムは、コンピューティングノードのセットを含む、許可された、高度にセキュアなコンピューティング環境を提供する。マイニングに関して、マイニング証明は、ノードがブロックまたはその一部の正当なマイナーであることを数学的に証明する、コンピューティングノードによって提示されるデータである。データは、ブロックチェーンが適切に構築されていること（すなわち、信頼）が自己検証可能であるように、ブロックヘッダに記録されることが好ましい。本開示によれば、何らかの利用可能な信頼できる乱数源を用いてマイニング証明が与えられることが好ましい。このアプローチでは、ノードは、真の乱数を生成して所望の性質を発揮するマイニング証明の作製を容易にするために、メモリが暗号化された信頼できるコンピューティング要素を使用することが好ましい。
鍵の管理
以下は本明細書で使用される用語の用語解説である。
ブロックチェーンは、追加される一方の、不変なデータブロックのチェーンであり、トランザクションがブロック内に記録されて存在すること、およびブロックがチェーン内に存在することは、暗号化ハッシュにより検証可能である。ブロックは、トランザクションの集合である。ブロックは、自身を前のブロックにリンさせる暗号化ハッシュを含み、チェーンを形成する。複数のブロックが前のブロックにリンクされる可能性があるが、前のブロックにリンクすることができる確定されたブロックは１つだけである。
マーチャント（ｍｅｒｃｈａｎｔ）は、決済のために商品またはサービスの取引を実行するエンティティである。マーチャントは、加盟店銀行により管理される銀行口座を有し、通常有効な決済要求を生成する役割を果たす販売時点管理端末（または他のレガシー基盤）を維持している。より一般的には、販売時点管理端末は、決済要求を生成するマーチャントコネクタ（ＭＥＲ）のタイプのものである。
ウォレットは、秘密鍵－公開鍵の対、および未使用のトランザクション出力への参照の集合であり、それらは「記憶された値」であって、トランザクションを生成するために使用される。「ウォレットサービス」は、通常、ウォレットの集合をセキュアに維持するソフトウェアエンティティであり、外部エンティティと、ブロックチェーンをサポートして対応する応答を処理するコンピューティングノードのコアネットワークとの間で要求をプロキシする。
ウォレットサービスは、多ウォレットプロセッサ（ＷＰ）または等価な処理機能を利用することができる。
上述のように、未使用のトランザクション出力（ＵＴＸＯ）は、いくつかの値を含みアドレスに関連付けられた、確定されたトランザクションからの出力である。ＵＸＴＯは、入力（使用済）として、関連付けられた秘密鍵を保持するウォレットにより作製されたトランザクションに渡すことができる。ＵＸＴＯを使用することができるのは、一回だけである。
アクワイアラ（ａｃｑｕｉｒｅｒ）は、銀行口座が保持される機関である。アクワイアラは、通常、決済要求を認可する役目を果たすレガシー基盤を運用する。この基盤は、時にアクワイアラまたはオペレータのためのコネクタと称される。
管理サーバは、クリアリング、オペレータおよびマーチャント銀行処理、企業コンプライアンスなど、１つ以上のサービスを提供する、決済ネットワークの外部のサービスである。
台帳サービス（時に「１つ以上の台帳サービス（ｌｅｄｇｅｒ ｓｅｒｖｉｃｅｓ）」とも称される）は、トランザクションを処理し、コア台帳を維持する分散型システムである。コア台帳は、本明細書において説明されるブロックチェーン技術を利用して台帳サービスにより維持される記録システムである。コア台帳は、トランザクションを処理してブロックチェーンを作製する分散型システムである。
決済ネットワークは、ウォレットサービスとブロックチェーンコア台帳（台帳サービス）を組み合わせたネットワークである。ウォレットサービスは、クライアントトランザクションを受信し、トランザクションをウォレットプロセッサ（例えば、ＷＰ）にルーティングし、必要な決済ロジックを適用し、次いで有効なトランザクションを台帳サービスに転送する。すると、台帳サービスがウォレットサービスからトランザクションを受信し、それらを有効化、処理し、ブロックチェーンベースの台帳に記録する。元々のレガシートランザクションおよびそれに対応する台帳サービス由来のブロックチェーントランザクションから成る、処理済みのトランザクションは、長期的な存続性のためにストレージサービスに記憶することができる。ストレージシステムは、履歴的なクエリに応答すること、および災害時復旧用のバックアップを提供することのために使用することができる。決済ネットワークは、管理トラフィックを扱うためのインターフェースを提供するために、データ連携サービスを含む場合もある。顧客のトランザクションは、ウォレットサービスを介してシステムに入るが、管理上の要求（ウォレット更新、データセンタ更新、履歴的クエリなど）は、それらを正しいサービスに転送する前に要求を有効化するデータ連携サービスを介してシステムに入る。データ連携サービスは、ＲＥＳＴｆｕｌなアプリケーションプログラミングインターフェース（ＡＰＩ）エンドポイントのセットを公開し、結果として、ＴＬＳ相互認証済のＲＥＳＴベースのＨＴＴＰ要求を作製し、ＪＳＯＮにより表現されるデータを送信することができる任意のクライアントをサポートすることが好ましい。
上述の用語を参照して、図１１は、オーバーレイネットワークエッジサーバ１１００が、マーチャントコネクタ（ＭＥＲ）１１０４、または管理サーバ１１０６のいずれかから、決済ネットワークコア１１０２に入る要求のためのエントリポイントとして機能する代表的なシステムの別の図である。随意的に、エッジは、決済ネットワークコア１１０２からアクワイアラ／オペレータベースのコネクタ（ＯＰＲ）１１０８に送信される要求のためのエントリポイントとして機能する。前述のように、性能上の利点の中でもとりわけ、オーバーレイネットワークは、ルーティングの最適化、攻撃に対するレジリエンス、レート制限、および要求が決済ネットワークコアノードに転送される前にクライアント認証を提供することを行う。このようにコアノードを隔離することによって、オーバーレイネットワークは様々な攻撃に対するレジリエンス、ならびに様々なタイプのローカル化されたインターネットの問題に対する軽減策をもたらす。描かれているように、オーバーレイネットワークエッジは決済ネットワークコアを実質的に取り囲んでおり、他のコンポーネント（マーチャントコネクタＭＥＲなど）はそこを通って接続されて決済ネットワークコアサービスに達するようになっている。エッジネットワークのスケールが大きいため、決済ネットワークはエッジを使用して適当な決済ネットワークコアノード同士のトラフィックをバランスさせ、作業負荷に応じて線形にスケーリングすることが可能である。
エッジは、インターネットスケールの攻撃からの保護を与え、非認証済みの要求が決済ネットワークコアに到達するのをブロックし、相互認証要求を満足することに失敗した接続をブロックする。エッジは、ＳＹＮフラッドおよびＵＤＰフラッドなどの非ＨＴＴＰベースのＤＤｏＳトラフィックに対する保護も行う。加えて、エッジはパフォーマンスおよび信頼性を向上させる。ＴＬＳおよびＴＣＰ接続は、パフォーマンスを向上するためにマーチャントコネクタＭＥＲの近くで終了することが好ましい。エッジから決済ネットワークコアへの接続プールは、ＴＬＳネゴシエーションのオーバヘッドを低減する。各エッジノードは任意の決済ネットワークコアノードと通信することができ、場所固有の要求を適当な場所にルーティングすることが好ましい。この最適化されたルーティングは、密集しているかメンテナンスを受けている決済ネットワークコアの場所を回避することが好ましい。管理サーバおよびマーチャントコネクタＭＥＲは、アクワイアラＯＰＲと同様、同一のプロトコルおよび方法を使用してエッジに接続することが好ましい。決済ネットワークコアサービスは、エッジにクライアントとして接続し、アクワイアラＯＰＲサーバにルーティングされる場合もある。
決済ネットワークコアへの全てのＨＴＴＰＳ要求は、まず、ＴＬＳが終了しクライアントの識別情報が検証されているエッジに送信されることが好ましい。マーチャントコネクタおよび管理サーバのクライアントは、設定されたドメイン名を使用して決済ネットワークコアに接続することが好ましい。
以下のセクションでは、クライアントと、エッジと、決済ネットワークコアとの間の代表的な接続フローを詳細に説明する。
マーチャントコネクタＭＥＲおよびその下流コンポーネント（例えば、ＰＯＳ端末およびカード）が物理的且つ電子的にセキュアであることが好ましい。図１２に描かれているように、マーチャントコネクタＭＥＲ１２００は、（管理されたホスト名に対する）ＤＮＳルックアップの解決によりオーバーレイネットワークエッジ１２０２に結合し、それにより、エッジサーバに対応する１つ以上のエッジＩＰアドレスが得られる。これらのサーバは、インターネットトポロジの観点からマーチャントコネクタ１２００に近いことが好ましく、インターネット上でポート４４３を用いる標準の相互認証済のＴＬＳ暗号化ＨＴＴＰコールを使用する。エッジ１２０２から決済ネットワークコア１２０４まで、オーバーレイネットワークは接続フローを制御し、それらのプライバシおよび真正性に責任を負うことが好ましい。エッジ１２０２は、複数のＩＳＰおよび地理的場所にわたって非常に多岐に展開されることが好ましいが、通常決済ネットワークコア１２０４は、小規模な地理的スケールで（例えば、インターネットを介してエッジ１２０２と通信する高度にセキュアな場所に）展開される。エッジとコアとの間のトラフィックは、暗号化され、認証され、認可されることが好ましい。特に、トランジットでは全てのメッセージがＴＬＳベースの相互認証済の接続を使用して暗号化されることが好ましい。描かれているように、メッセージ認証ドメインは、あらゆるセキュリティ侵害された中間者（ＭＩＴＭ：ｍａｎ－ｉｎ－ｔｈｅ－ｍｉｄｄｌｅ）要素に対してメッセージを偽造から保護するべく、エンドツーエンドであることが好ましい。これは、決済ネットワークコアが受信するあらゆるメッセージが、いかなる決済ネットワークコアシステムまたは人物によっても署名されたことがない鍵によって署名されているものとして検証可能であることを保証する。対応するアサーションが、やはりマーチャントコネクタが決済ネットワークコアから受信する全てのメッセージのために行われることが好ましい。
オーバーレイネットワークエッジは、決済ネットワークコア（クライアントとして機能している）をアクワイアラ／オペレータＯＰＲ１１０８（図１１）に結合するために、または管理サーバ１１０６を決済ネットワークコアに結合するために使用されることが好ましい。
図１３は代表的なシステム実装の一部、特に鍵管理スキームを示している。描かれているように、ＰＯＳ端末１３０２、販売時点管理端末アグリゲータ１３０３、および１つ以上のマーチャントコネクタ（ＭＥＲ）１３０４などのレガシーアーキテクチャを備えるマーチャントサイト１３００がある。システムは、エッジネットワーク１３０６、マーチャントコネクタ（ＭＥＲ）鍵管理コンポーネント１３０８、および決済ネットワーク（ＰＮ）鍵管理コンポーネント１３１０をさらに備え、後者は通常決済ネットワークを運用するサービスプロバイダのプレミスに関連付けられて配置される。描かれているように、さらにマーチャントコネクタ（ＭＥＲ）の信頼の基点１３１２、および決済ネットワークの信頼の基点１３１４があることが好ましい。エッジネットワークは、それぞれが暗号化サーバ（ＣＳ）１３２０に関連付けられる多ウォレットプロセッサ１３１８のセットを含む決済ネットワークウォレットサービス領域１３１６をさらに備える。本明細書において使用される際、「領域」は、通常同じ場所に配置されたサーバのセットである。
以下で、図１３に描かれている例示の実施形態において、決済ネットワーク－マーチャント間のセキュアな相互運用をサポートするために必要な暗号化鍵素材の管理を説明する。しかしながら、このアーキテクチャは限定を意図していない。
オーバーレイネットワークのサービスプロバイダの観点から、マーチャントコネクタとの通信は、（１）いかなるシステムまたはプロバイダ側の人物も、別の状況ではマーチャントコネクタトランザクション要求を偽造するために必要とされ得る鍵素材へのアクセスを有していないこと、（２）マーチャントコネクタと決済ネットワーク要素との間に存在するいかなるシステムも、決済ネットワークトランザクション応答を偽造することができないこと、となっていることが好ましい。
この分散型システムにおけるセキュリティは、非対称暗号法を用いて実現されることが好ましい。より一般的には、図１３に示されるシステムに関して以下の設計原理を用いてセキュリティが強化される：
１．トラストレスな要素 － コンポーネント自身のいずれもが信頼できない、または信頼できるコンポーネントのセットが少ない場合の、コンポーネント上でのセキュアな（信頼できる）サービスの構築。一例として、ブロックチェーンネットワークのノードは、互いを信頼しておらず、一般にウォレットは、台帳が有効であること、およびトランザクションがその台帳上にあることの暗号法的証明を必要とする限りは、台帳を信頼しない。決済ネットワーク台帳上のトランザクションは、トランザクション入力ごとに個々に署名され、したがって自己検証可能である。その結果、台帳サービスのノードを信頼することなしに、台帳を信頼することができる。このため、マーチャント（ＭＥＲ）から生じるトランザクションが信頼できること、さらには信頼の鎖が２つ（または２つ以上）のメッセージングレジームの間で維持されることが必要とされる。
２．信頼の基点および信頼の鎖 － 信頼が確立されなければならない場合、最も強固なセキュリティ対策が講じられている信頼の基点（一般的には、鍵の対）から開始するレイヤにおいて、信頼を確立する。そのような強固な対策は、アクセスがまれであり、不便であり、時間がかかり、高額であることを含意する。システムにおけるあらゆるデータの信頼性は、鎖内の各リンクを先行するリンクと照合することが基点まで遡って可能である信頼の鎖の形で、信頼の基点から伝わることが好ましい。しかしながら、鎖内の各リンクは、本質的に、関連付けられたセキュリティ制御および制限を伴うより頻繁で自動化されたアクセスを優先することで、信頼が弛緩することを表している。
３．切り離し － 異なるサービスに対する鍵管理および信頼の基点は、切り離されることが好ましい。したがって、１つのサービスでのセキュリティ侵害は、他のサービスの整合性に脅威を与えない。サービスの相互運用のためには、それぞれの信頼の基点の交換（例えば、信頼できる人物または実体同士が会って、それぞれの信頼の基点を成す秘密鍵素材に関連付けられる公開鍵素材の真正性を証明すること）を必要とする。この交換により、後続の導出鍵素材の対話的または電子的な交換を、最終的には導出鍵素材の真正性が信頼の基点と照合可能となるように行うことができる。
４．多層防御 － サービスのレイヤ内にも、切り離しが適用される。例えば、相互認証済の接続を確立するために必要な鍵素材は、個々の認証済メッセージを確立するために必要な鍵素材とは異なることが好ましい。例えば、ブロックチェーンに記録されるトランザクションがセキュアなリンク（すなわち、接続レベルの認証）上で伝わるにしても、各トランザクションは、なお、個々に署名されること（すなわち、メッセージレベルの認証）が好ましい。このように、接続レベルの認証におけるセキュリティ侵害は、秘匿性の完全な喪失を含意するものではなく（一過性のセッションキーの使用を想定して）、トランザクションの偽造または変更を可能ならしめるものでははい。
５．役割の分割および役割ベースでの制限 － あるシステム内の様々な信頼境界の両側で要素の役割を特定し、各役割の目的および権限と一致するようにポリシーおよび制限を定義して、セキュリティ侵害に関連付けられるリスクを抑えることが重要である。
６．ローテーション － 信頼の鎖内のリンク毎に秘密素材へのアクセスの保護は弛緩するものであるから、鍵は日常的および緊急時に変更される（すなわち、ローテーションされる）ことが好ましい。一実施形態では、アクティブなサービスの鍵空間は、時間およびドメインの両方において切り離されている。例えば、各デバイスはそれ自身の鍵を持ち、その鍵は日常的にローテーションされることが好ましい。
７．証明および取り消し － 証明は、信頼の鎖を介してデータ（例えば、鍵）の真正性を証明する行為である。取り消しはその逆であるが、信頼の鎖も伴うことで、サービスの可用性を脅かす偽の取り消しが軽減される。
図１３は、説明したやり方で、マーチャントコネクタとインターフェースして、エッジの仲介を介して決済ネットワークと相互運用する、マーチャントの販売時点管理（ＰＯＳ）システムを示している。述べたように、これは単なる例示の実施形態であり、本明細書の鍵管理技法がサポートする様々なマーチャントコネクタ展開シナリオがある。
一実施形態では、マーチャントコネクタ鍵管理コンポーネント１３０８は、管理サーバのサブ機能であり、決済ネットワーク鍵管理１３１０は、データ連携サービスのサブ機能である。しかしながら、これは必須ではない。
決済ネットワーク－マーチャントＭＥＲ間のセキュアな通信
鍵管理システムは、決済ネットワーク－マーチャントＭＥＲ間の相互運用のセキュアな通信要件をエンドツーエンドにサポートする。以下の設計では、様々なレベルで鍵素材を使用して多層防御のセキュリティを確立することが好ましい。
トランザクションの要求および応答を扱うために、マーチャントコネクタは以下の方法で鍵素材を使用することが好ましい：
１．オーバーレイネットワークエッジとのＴＬＳ接続を確立する際、マーチャントコネクタサーバの真正性を証明するための、ＴＬＳクライアント認証秘密鍵。
２．マーチャントコネクタが接続するオーバーレイネットワークエッジサーバの真正性を検証するための、ＴＬＳサーバ認証の認証局（ＣＡ）証明書。
３．各要求および応答のＨＴＴＰヘッダ内の、ＡＰＩキー。オーバーレイネットワークエッジで実行されるオーバーレイネットワークＡＰＩゲートウェイサービスは、各要求内のＡＰＩキーヘッダをチェックして、エンドポイント（すなわち、マーチャントコネクタ）が、依然としてサービスを使用するよう認可されていることを検証する。このキーは、オーバーレイネットワークのポータルを介して管理され、万一マーチャントコネクタのセキュリティ侵害が疑われる場合には、最も容易且つ迅速に取り消し可能であることが好ましい。
４．トランザクションを送信するマーチャントコネクタサーバの真正性を証明するためのクライアントＪＷＴ（ＪＳＯＮウェブトークン）秘密鍵。
５．応答を送信する決済ネットワークサーバの真正性を検証するためのサーバＪＷＴ公開鍵。
決済ネットワークの鍵の使用は、以上のことを反映するものであることが好ましい。すなわち：
６．ＴＬＳセッションを開始するマーチャントコネクタサーバの真正性を検証するためのＴＬＳクライアント認証ＣＡ証明書。
７．マーチャントコネクタからＴＬＳ接続を受け入れる際、オーバーレイネットワークエッジサーバの真正性を証明するための、ＴＬＳサーバ認証秘密鍵。
８．各要求および応答のＨＴＴＰヘッダ内の、ＡＰＩキー。
９．トランザクションを送信するマーチャントコネクタサーバの真正性を検証するためのクライアントＪＷＴ秘密鍵。
１０．応答を送信する決済ネットワークサーバの真正性を証明するためのサーバＪＷＴ秘密鍵。
これらの保護レイヤ（接続認証、ＡＰＩ使用認可、およびトランザクション認証）のそれぞれが重要な目的を果たす一方で、クライアントとサーバのＪＷＴ鍵の対が重要な利点を与える。ＪＷＴ鍵の対は、トランザクションの整合性を保護し、マーチャントコネクタ要求とその決済ネットワーク応答との間の信頼の鎖を維持しており、この鍵の対は、負荷バランシングおよびフェイルオーバによる高スループット、低レイテンシのトランザクション処理のサポートを可能にする方法でこれを行う。
識別情報
意味のあるものにするべく、システムで使用される鍵は、鍵管理システムが証明および取り消しの目的に使用する、またエンドポイントがそのメッセージングに使用する、何らかの識別情報に結び付けられることが好ましい。
以下に、本設計の代表的な識別情報要素を挙げる：ドメイン名、ＴＬＳサーバ名表示（ＳＮＩ）、ＨＴＴＰホスト名、フォワーディングセンター識別子（ＩＤ）、および決済センター識別子（ＩＤ）。
各マーチャントコネクタサーバは、接続するオーバーレイネットワークエッジサーバのアドレスをルックアップする際、１つ以上のドメイン名のセットを使用するように構成されることが好ましい。ドメイン名の、オーバーレイネットワークエッジサーバに対するマッピングは、負荷、ネットワーク遅延の増大、メンテナンスの計画、マシンまたは領域の停電など、任意の数の要因によって変わる可能性がある。
マーチャントコネクタサーバは、決済ネットワークのドメイン名でＴｉｍｅ－Ｔｏ－Ｌｉｖｅ（ＴＴＬ）のセットを受け入れることが好ましい。このセットは、１つのドメイン名だけを含み得るが、マーチャントコネクタが生成すると予想される負荷に応じて、セットは複数のドメイン名を含み、マーチャントコネクタは何らかの規定に基づいて（例えば、ラウンドロビン、またはランダムに）、ここから選択することができる。さらには、各ドメイン名は、所定のバックアップ用ドメイン名を有することが好ましい。バックアップ用接続は、プライマリサーバ接続が壊れているか、または応答しない場合に、使用される。
各マーチャントコネクタは、オーバーレイネットワークエッジへの接続を確立する際、ＴＬＳサーバ名表示（ＳＮＩ）を使用することが好ましい。ＴＬＳ ＳＮＩは、ＨＴＴＰホストヘッダに与えられるホスト名と一致することが好ましい。ＳＮＩおよびＨＴＴＰホスト名は、いつもではないが、一般的に、ドメイン名に基づいていることが好ましい。ＴＬＳおよびＡＰＩ資格証明は、通常ホスト名に結び付けられる。その結果的として、セキュリティ上および安全上の理由から、各マーチャントコネクタサーバ（または、ＰＯＳ端末の同一のセットにサービスする、同じ場所に配置されたマーチャントコネクタサーバのセット）は一意なホスト名を使用することが好ましい。
フォワーディングセンター識別子は、マーチャントコネクタサーバがトランザクション要求に署名するために使用するメッセージ認証キーを示すためにＩＳＯ８５８３メッセージで使用される。セキュリティ上および安全上の理由から、各マーチャントコネクタサーバ（または、ＰＯＳ端末の同一のセットにサービスする、同じ場所に配置されたマーチャントコネクタサーバのセット）は一意なフォワーディングセンターＩＤを使用することが好ましい。
決済センター識別子ＩＤは、決済ネットワークサーバがトランザクション応答に署名するために使用したメッセージ認証キーを示すためにＩＳＯ８５８３メッセージで使用される。セキュリティ上および安全上の理由から、各決済ネットワークサーバは、一意な決済センターＩＤを使用することが好ましい。
鍵管理の切り離し
マーチャントコネクタサーバネットワークと決済ネットワークサーバネットワークとは、通常異なるサービスドメインに相当する。上述のように、２つのサービスが相互運用する場合、２つのシステムのセキュリティを切り離して、一方のセキュリティ侵害がもう一方のセキュリティ侵害に至らないようにすることが重要である。異なるセキュリティシステムは、互いに別個に進化する能力を有していることも重要である。図１３のブロック図では、マーチャントコネクタ鍵管理と決済ネットワーク鍵管理との間隔を示すことにより、この切り離しが強調されている。鍵管理の技術が異なっている必要はないが、物理的なシステム、場所、および人物は切り離されていることが望ましい。
信頼の基点
各鍵管理システムは、それ自身の信頼の基点を有することが好ましい。これは、一般的に、秘密鍵がオフラインで保持され、堅牢なセキュリティ対策で保護される強固な非対称な鍵の対として具体化される。そして、信頼の基点ごとの公開鍵は、他の鍵管理システムで共有される。公開鍵の真正性は検証されることが好ましく、一般的に、これは各オーソリティの信頼できる代表が公開鍵を交換することにより行われる。信頼の基点の公開鍵が交換されると、各当事者は、関連付けられた信頼の基点の秘密鍵により署名されたオンラインメッセージの真正性を検証することが可能になる。信頼の基点の秘密鍵は、（ｋ－ｏｆ－ｎによる）オニオン暗号化により安全且つ保護されて保持され、その鍵は別の信頼できる人物が保管することが好ましい（すなわち、シークレット共有プロトコルによる）。結果的に、信頼の基点の鍵は、その使用が一般的に次に説明する証明鍵の対などの他の鍵の交換に限定されるように、まれにしか使用されない。
証明鍵の対
証明鍵の対は、実際の決済ネットワークとマーチャントコネクタ通信に使用されるＴＬＳ認証キー（ＴＬＳキー）、アプリケーション（Ａｐｐ）ゲートウェイＡＰＩキー（ＡＰＩキー）、およびクライアント／サーバＪＷＴキー（ＪＷＴキー）のセキュアな電子的交換のために用いられることが好ましい。各鍵管理システム用の証明公開鍵は、その個々の信頼の基点の秘密鍵によって署名され、電子的に他の鍵管理システムに送信され、その真正性が元々のシステムの信頼の基点の公開鍵と照合して検証される。証明公開鍵は、信頼の基点を再度使用して取り消すこともできる。証明公開鍵の真正性が検証されると、個々の鍵管理システムは、ＴＬＳキー、ＡＰＩキー、およびＪＷＴキーの証明または取り消しのために、対応する証明秘密鍵を使用することができる。
ＴＬＳキー
ＴＬＳキーの取り扱いにおける、好ましいベストプラクティスを以下にまとめる。
ＴＬＳセッション相互認証に使用されるサーバ（決済ネットワーク）およびクライアント（マーチャントコネクタ）証明書は、通常外部システムによって生成され、認証局（ＣＡ）によって署名され、鍵管理システムにセキュアにインポートされ、ここで、これらの証明書は、ＴＬＳセッションの確立に使用するために、クライアントおよびサーバにセキュアに通信される。
決済ネットワーク用には、サーバ証明書は、オーバーレイネットワークのＴＬＳ証明書管理システム、例えば、証明書をオーバーレイネットワークエッジサーバにセキュアに通信するシステムを用いて生成されることが好ましい。オーバーレイネットワークのＴＬＳ証明書管理システムは、ＴＬＳキーを緊急に取り消すために使用される場合もあり、このシステムはオンライン証明書状態プロトコル（ＯＣＳＰ：Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）をサポートしてクライアントが証明書の取り消し状態をチェックすることを支援することが好ましい。
決済ネットワークは、マーチャントコネクタ鍵管理システムに対して、決済ネットワークＴＬＳ ＣＡの証明および取り消しを行う鍵管理システムを有することが好ましい。
マーチャントコネクタは、オーバーレイネットワークエッジを介して決済ネットワークへの接続を確立する際、マーチャントコネクタによってＴＬＳ ＳＮＩに示されるドメイン名に一致する、有効な（失効しておらず、取り消されていない）クライアント証明書を使用することが好ましい。
マーチャントコネクタは、サーバ証明書状態をチェックして、オーバーレイネットワークエッジを介して決済ネットワークへの接続を確立する際、マーチャントコネクタによってＴＬＳ ＳＮＩに示されるドメイン名に一致する、有効な（失効しておらず、取り消されていない）サーバ証明書が提示された場合のみ接続を確立することが好ましい。
マーチャントコネクタについては、類似のＴＬＳ証明書取り扱いシステムが存在することが想定される。したがって、マーチャントコネクタ鍵管理システムは、決済ネットワーク鍵管理システムに対して、マーチャントコネクタＴＬＳ ＣＡの証明を行うことが好ましい。
オーバーレイネットワークエッジサーバは、オーバーレイネットワークエッジを介して決済ネットワークへの接続を確立する際、マーチャントコネクタによってＴＬＳ ＳＮＩに示されるドメイン名に一致する、有効な（失効しておらず、取り消されていない）サーバ証明書を使用することが好ましい。
オーバーレイネットワークエッジは、クライアント証明書状態をチェックして、有効な（失効しておらず、取り消されていない）証明書が使用されている接続のみを受け入れることが好ましい。
ＴＬＳ証明書を取り消すことは、以前にその証明書を用いて確立したＴＬＳ接続を壊す訳ではないことに留意されたい。したがって、ＴＬＳ接続の寿命を有限とし、その結果、新しい接続、および取り消された証明書の最終的な検出を強制することが好ましい。
システムのセキュリティおよびシステムの安全性の両方を確実にするために、証明書の取り消しはマーチャントコネクタサーバごと（または、マーチャント端末の同一の基本セットにサービスする同じ場所に配置されたサーバのセットごと）に可能であることが好ましい。この目的のため、マーチャントコネクタは、異なるドメイン名（または、ドメイン名のセット）および一致するクライアントＴＬＳ証明書を使用するように構成される。
ＡＰＩキー
オーバーレイネットワークＡＰＩゲートウェイキーは、ＡＰＩゲートウェイサービスによって運用管理される対称鍵であることが好ましい。オーバーレイネットワークのポータルを用いてＡＰＩキーを運用管理することができる。
マーチャントコネクタサーバは、オーバーレイネットワークエッジＡＰＩゲートウェイに送信する各メッセージ内にＡＰＩキーヘッダを含むことが好ましい。
オーバーレイネットワークエッジシステムは、受信した各メッセージが現在有効なＡＰＩキーを含んでいるかをチェックすることが好ましい。
ＴＬＳキーと同様、ＡＰＩキーは、例えば、取り消しが自動的にオーバーレイネットワークエッジに通信されるオーバーレイネットワークのポータルにおいて、取り消し可能であることが好ましい。
ＡＰＩキーの割り当ては、他のキー割り当てを反映することが好ましい。すなわち、セキュリティ侵害されたマーチャントコネクタを、他のマーチャントコネクタに影響を及ぼすことなくオーバーレイネットワークエッジへの通信から迅速に遮断できるようにするべく、各マーチャントコネクタ（または、同じ場所に配置されたマーチャントコネクタのセット）は、それ自身のＡＰＩキーを割り当てられる。
ＪＷＴキー
ＪＷＴキーは、好ましくは非対称メッセージ認証キーであり、各メッセージに署名して、その真正性を検証するために使用される。クライアントＪＷＴ秘密鍵は、トランザクション要求に署名するためにマーチャントコネクタによって使用され、クライアントの公開鍵は、入来トランザクション要求の真正性を検証するために決済ネットワークによって使用される。同様に、サーバＪＷＴ秘密鍵は、トランザクション応答に署名するために決済ネットワークによって使用され、サーバＪＷＴ公開鍵は、トランザクション応答の真正性を検証するためにマーチャントＣＮによって使用される。
クライアント鍵の要件
マーチャントコネクタ鍵管理システムは、決済ネットワーク鍵管理システムに対して、クライアントＪＷＴ公開鍵の証明および取り消しを行うことが好ましい。マーチャントコネクタサーバごとに（より具体的には、フォワーディングセンターＩＤ１つあたり）、同時に証明されるこのような鍵は、せいぜい２つであることが好ましい。これは、サービスを中断することなく、クライアントＪＷＴ秘密鍵ローテーションをサポートするためである。鍵のローテーションが完了すると、役目を終えたクライアントＪＷＴ公開鍵は取り消される。
マーチャントコネクタサーバは、ＩＳＯ８５８３トランザクションメッセージ内で示されるフォワーディングセンターＩＤについて現在証明されている公開鍵に対応する秘密鍵を使用して、全てのトランザクション要求メッセージに署名することが好ましい。
決済ネットワークは、ＩＳＯ８５８３トランザクションメッセージ内で示されるフォワーディングセンターＩＤについて現在証明されている公開鍵を使用して、マーチャントコネクタから生じる全てのメッセージのクライアント署名を検証することが好ましい。
サーバ鍵の要件
決済ネットワーク鍵管理システムは、マーチャントコネクタ鍵管理システムに対して、サーバＪＴＷ公開鍵の証明および取り消しを行うことが好ましい。決済ネットワークサーバごとに（より具体的には、決済センターＩＤ１つあたり）、同時に証明されるこのような鍵は、せいぜい２つであることが好ましい。これは、サービスを中断することなく、サーバＪＷＴの秘密鍵ローテーションを可能にするためである。鍵のローテーションが完了すると、役目を終えたサーバＪＷＴ公開鍵は取り消される。
決済ネットワークサーバは、ＩＳＯ８５８３トランザクション応答メッセージ内で示される決済センターＩＤについて現在証明されている公開鍵に対応する秘密鍵を使用して、全てのトランザクション応答メッセージに署名することが好ましい。
マーチャントコネクタは、ＩＳＯ８５８３トランザクション応答メッセージ内で示される決済センターＩＤについて現在証明されている公開鍵を使用して、全ての決済ネットワークトランザクション応答メッセージのサーバ署名を検証することが好ましい。
ＩＳＯ８５８３メッセージのサポート
トランザクション応答を検証するために必要なサーバＪＷＴ公開鍵を識別するために、決済センターＩＤがＩＳＯ８５８３トランザクション応答の形で通信される。一実施形態では、この情報は、共通ヘッダに追加することにより、（ＩＳＯ８５８３メッセージ内に）含められる。
この目的のために、クリアリング目的で決済ネットワークと端末とによってそれぞれ記録される応答データが同一となるよう、決済センターＩＤフィールドは、決済ネットワークによってポピュレートされることが好ましい。
カーディナリティ期待値
決済ネットワークおよびマーチャントコネクタネットワークのカーディナリティは、それぞれによりサポートされる鍵記憶のサイズを範囲決めするために重要である。説明したように、マーチャントコネクタサーバが、サーバＪＷＴ公開鍵を（決済センターＩＤごとに１つ）所有しており、決済ネットワークサーバが、クライアントＪＷＴ公開鍵を（フォワーディングセンターＩＤごとに１つ）所有していることが好ましい。
決済ネットワーク鍵管理
このセクションでは、決済ネットワークの内部での好ましい鍵管理法の一実施形態を与える。
上述のように、暗号化サーバ信頼のコンピューティング環境を使用して、秘密鍵素材の流出および悪用を軽減すること、より一般的には、ＩＳＯ８５８３トランザクション要求から、決済ネットワークトランザクションおよびその対応するブロックチェーンの受け取り、そしてＩＳＯ８５８３トランザクション応答に至る信頼の鎖の構築をサポートすることが好ましい。上述のように（また、図１３で示したように）、暗号化サーバは、通常、例えば、決済ネットワーク鍵管理システムとシームレスに相互運用される各決済ネットワークサーバ（ウォレットサービス多ウォレットプロセッサ）に付加される、ネットワーク化されたセキュリティ機器として実装される。
鍵の生成
従来の中央集権型の鍵管理システムとは異なり、サーバＪＷＴ鍵の管理は、暗号化サーバ信頼のコンピューティング環境によって鍵の対が生成され、秘密鍵がこれらの環境の外部に決して漏れないように、非中央集権化されることが好ましい。したがって、シークレットが明らかとなるのがこれらの信頼できる環境内部だけとなるように、鍵は暗号化サーバの外部で転送または記憶されるときでさえ、暗号化サーバの公開鍵を使用して暗号化される。サーバＪＷＴ公開鍵は、暗号化サーバからエクスポートされ、決済ネットワーク鍵管理システムに送信され、そこでマーチャントコネクタがトランザクション応答を検証する際に使用するために、マーチャントコネクタ鍵管理システムに対して証明されることが好ましい。
システム全体にわたって信頼の鎖をより良好に保つために、いくつかの暗号化サーバが決済ネットワーク鍵管理システムで使用されることが好ましい。
メッセージ認証の信頼の鎖
暗号化サーバ信頼のコンピューティング環境は、マーチャントコネクタからのＪＷＴメッセージで受信したＩＳＯ８５８３トランザクションの真正性を検証するためにも使用されることが好ましい。その結果的として、マーチャントコネクタ鍵管理システムから受信したクライアントＪＷＴ公開鍵の証明は、暗号化サーバ内部で検証され記録されることが好ましい。決済ネットワークトランザクションが完了すると、ＩＳＯ８５８３トランザクション応答を含むＪＷＴ応答は、暗号化サーバによってサーバＪＷＴ秘密鍵を使用して署名される。その際、途切れることのない信頼の鎖が、トランザクションが決済ネットワークに入る前から、決済ネットワークから離れた後まで、確立される。
ホストされたオリジンサービスを介するアクワイアラ（オペレータ）の統合
通常、アクワイアラ／オペレータはプライベートなネットワークベースのコンピューティング環境を有し、この環境上で決済ネットワークへの外向きの接続がオペレータベースのコネクタ（ＯＰＲ）から作成されるが、その環境の特定の実装形態の詳細はプライベートである必要がある。しかしながら、オーバーレイネットワークのプロバイダの観点からは、これらの詳細は、（１）ウォレットサービス（ＷＳ）とかかるＯＰＲの間にあるシステムが要求を偽造することができず、且つ（２）システムまたはオーバーレイネットワークサービスのいかなる要員も、アクワイアラＯＰＲ応答を偽造するのに必要となる鍵素材へのアクセスを有していない場合には、知られている必要はない。したがって、エンドツーエンドの観点から、ウォレットサービスからオペレータＯＰＲへの通信は、攻撃不能であるべきである。この目的のため、本開示のこの局面では、レガシーアクワイアラ環境を決済ネットワークのネイティブな環境に適合させるサービスが提供される。このサービスは、１つ以上のＯＰＲオリジンサーバを含む「オペレータ（アクワイアラ）コネクタオリジン」と総称される一組のサーバから構築されることが好ましく、これはＯＰＲオリジンセンターに配置されることが好ましい。この文脈では、「オリジン」という用語は、かかるサーバがオーバーレイネットワークベースのシステムに関して有する従来のアーキテクチャ上の役割を意味する。特に、オリジンは、要求をローカル（エッジサーバ、またはエッジサーバを含むエッジ領域）で遂行できない場合に、オーバーレイネットワーク（通常、エッジ）が接触する１つ以上のサーバであり、この時オリジンにより返される結果は、将来的な使用のためにローカルに記憶される。この概念は、ローカル管理のバリュートランザクションを使用するトランザクションを満たすことができず、代わりにアクワイアラとの金融メッセージトランザクションを実行するためにフォールバックし、その結果を台帳に記録するという、決済ネットワークの概念に直感的に対応する。この目的のため、（本明細書において説明されるように）決済ネットワークは、必要に応じてＯＰＲオリジンサーバへの接続を開始するように構成される。そして、標準的なオリジンのパフォーマンス、レジリエンス、およびセキュリティプラクティスが、オーバーレイネットワーキング技術を介して適用される。
オペレータベースのコネクタ（ＯＰＲ）は、セキュアなコンピューティング環境から構築され、管理される機器として展開されることが好ましい。このアプローチにより、エンクレーブからエンクレーブ（決済ネットワークからオペレータコネクタ）へのメッセージレベルのセキュリティが可能となる。
一実施形態では、ＯＰＲはアクワイアラのプレミスに配置され、ＣＤＮオリジンサーバとほぼ同じやり方で入来接続を処理する。特に、ＯＰＲは決済ネットワークからの入来接続を受け入れる。そのような場合、ＯＰＲは決済ネットワークオペレータから鍵素材を受け取り、その素材を使用して決済ネットワークから受信した要求の真正性を検証し、決済ネットワークが応答の真正性を検証することができるように、応答に署名する。この例では、オーバーレイネットワーク（仲介として機能する）は、検証可能なＯＰＲ応答を作成するのに必要となる鍵素材を所有していない。この構成の利点は、レガシーな内部接続およびサーバがアクワイアラのプレミスに限定されることであり、これは非常に高度な物理的およびネットワークのセキュリティプロファイルを有している可能性がある。また、（アクワイアラ基盤における）レガシーなソフトウェアに必要となるのは最低限の変更である。しかしながら、不利な点は、このアプローチでは、アクワイアラが入来接続を処理するＯＰＲをホストするよう必要があることである。そしてこれは、アクセスを提供するネットワークのリンクおよびインターフェースへの攻撃に対するファイアウォールまたは何らかの形態の強固な保護を必要とする。
第２の実施形態は、先ほどの実施形態に対する変形を伴うが、プロトコルおよびデータフローは同様である。このアプローチでは、オペレータは、自身のプレミス／施設の外でホストされるが、オーバーレイネットワーク自身の一部としてはホストされない１つ以上のＯＰＲへの、セキュアな／プライベートなリンクを確立する。このアプローチは、ＯＰＲをアクワイアラのプレミス内部でホストすることに付随するリスクを低減するが、さらに良好なアプローチが第３の実施形態により提供され、それを次に説明する。
好ましいアプローチであり、図１４に描かれるこの実施形態では、ＯＰＲの役割は分割されて切り離される。特に、ＯＰＲ１４０２は好ましくはアクワイアラのプレミス１４００に配置されるが、それは決済ネットワークへの外向きの接続を行うためだけであることが好ましい。この目的のため、ＯＰＲのこの部分は１つ以上のセキュアなコンピューティング環境を含み、鍵素材１４０４を決済ネットワークのプロバイダ（オーバーレイネットワークのプロバイダではない）から受け取るものであることが好ましい。アクワイアラ基盤内で、いずれのレガシーコンピューティング環境も従来のやり方でＯＰＲに接続する。しかしながら、内部では、オンプレミスのＯＰＲが決済ネットワークから受信した要求について全ての署名を検証し、且つ決済ネットワークに送信する全ての応答に署名することが好ましい。
オーバーレイネットワーク、または他の何らかのエンティティ（決済ネットワークのプロバイダ以外）は、ＯＰＲオリジンサーバのセットをホストし、それにより接続性のラインを逆転可能にする。限定することを意図されていないこの例では、オーバーレイネットワークは、ホストされたＯＰＲオリジンとして機能する、決済ネットワークウォレットサービス領域（すなわち、同じ場所に配置されたサーバのセット）１４０６を含む。特に、オーバーレイネットワークホストのＯＰＲオリジンサーバは、ＴＬＳ相互認証の証明書を有するが、それらは検証可能なＯＰＲ要求を作成するのに必要となる鍵素材を有していない。むしろ、ウォレットサービス内のセキュアなモジュールだけが、この鍵素材を有することが好ましい。同様に、またＯＰＲ通信要件をさらに簡略化するために、決済ネットワークは自身の要求を、オーバーレイネットワークホストのＯＰＲオリジンを通じてルーティングすることが好ましいが、ここでもオリジンは検証可能なＯＰＲ管理要求を作成するのに必要となる鍵素材を有していないことが好ましい。むしろ、決済ネットワークのプロバイダだけがこの素材を有することが好ましい。
オーバーレイネットワークベースのＯＰＲオリジンサーバは入来接続を処理しているため、これらのサーバは複数の場所においてホストされ、その少なくとも１つの場所がオーバーレイネットワークのスクラブ（洗浄）センターによって保護されていることが好ましい。スクラブセンターのリンク容量およびフィルタリングロジックによって、サービス拒否、または分散型サービス拒否（ＤｏＳ／ｄＤｏＳ）攻撃に対して効果的な保護が与えられるので、いずれかの側の設定済みエンドポイントからの接続のみを許可するファイアウォールとして機能する。
好ましくは、またＯＰＲのセキュリティ侵害に対する保護を与えるために、ＯＰＲは、上述のような暗号化サービス技術により構築され、それによって、ＯＰＲトランザクション要求／応答プロトコル、および鍵管理プロトコルが、セキュアな実行環境内で処理される。このアプローチによって、ＯＰＲは実質的に、遠隔で運用管理される機器となる。鍵管理は、後でＯＰＲがアクワイアラのプレミスに置かれる際、鍵素材がセキュアに管理できるように、ＯＰＲ製造プロセスの際に信頼の基点でブートストラップされることが好ましい。信頼の基点により、ＯＰＲは暗号鍵対を生成し、対応する鍵管理システムに対して公開鍵を認証することが可能になる。
上述の技術は、重要な利点を提供する。それにより、ホストされたオリジンサービスを含む分散型記録システムアーキテクチャと、レガシー決済ネットワークのオペレータに対してブロックチェーンベースの決済システムへの高度にセキュアで回復力のあるアクセスを提供する関連セキュリティ技術とが提供される。本アプローチは、外部決済オペレータに対してと、ブロックチェーン決済ネットワークからとの両方のインバウンド接続性を提供し、それによりレガシーなシステムは従来型の決済システム内にあるが如く新型の決済システムに接続するが、新型の決済ネットワークはウェブオリジンサーバにあるが如くレガシーなオペレータシステムにインターフェースすることができる。
オペレータＯＰＲ接続
以下では、図１３に示されるシステムに関するさらなる詳細が示される。
決済ネットワークがイニシエータである接続では、決済ネットワーク内部の多ウォレットプロセッサは、クライアントとして接続を確立する。通常、これらのプロセッサは、このような接続を、アクワイアラウォレットの分布および他の要件に従って、確立する。通常、接続は、オーバーレイネットワーク内部のより少数の上流サーバに集中、または多重化さる。その際、アクワイアラへの接続は、この少数で、より限定的なサーバのセットから作成されることが好ましい。
接続は、好ましくはＴＬＳベースの相互認証済接続を使用して、オーバーレイネットワークからアクワイアラへ外向きに作成され、これらの接続は、オーバーレイネットワーク内部の上流サーバによって、アクワイアラに対して永続化されることが好ましい。上流サーバを保護するために、オーバーレイネットワークは、相互認証に加え、オリジン隠し技法およびアクセス制限を実装することができる。その際、オリジンファイアウォール規則がアクワイアラにおいて適用されることにより、指定された上流サーバからのアクセス以外のアクセスを制限する。オーバーレイネットワーク内部の接続は、それぞれの多ウォレットプロセッサから上流サーバに向けて、ＴＬＳ相互認証を用いて作成されることが好ましく、内部トポロジは外部ネットワークからは到達できないことが好ましい。個々の要求が受信され、フレーミングされ、アクワイアラに送信され、応答がそれぞれの多ウォレットプロセッサに返されることが好ましい。このプロセスでは、標準的なクライアント接続セマンティックス、および元々の要求を作成する多ウォレットプロセッサから発するＨＴＴＰ要求／応答セマンティックスが採用されることが好ましい。
アクワイアラがイニシエータである接続では、アクワイアラサーバは、最初クライアントとして機能し、オーバーレイネットワークエッジを有するサーバのセットに対してＴＬＳ相互認証済接続を確立する。相互認証に加えて、ソースＩＰアドレスが、適切なＡＣＬ（アクセス制御リスト）と照合されることが好ましい。さらなる「上流」接続は、オーバーレイネットワークエッジによって、オーバーレイネットワーク内部の個々の多ウォレットプロセッサに対して作成されることが好ましい。上記と同様に、好ましくはオーバーレイネットワーク内部の接続はエッジから多ウォレットプロセッサに向けてＴＬＳ相互認証を使用して作成され、内部トポロジは外部ネットワークからは到達できない（すなわち、隠されている）。順方向の接続が確立すると、通常、役割が逆転する。多ウォレットプロセッサがクライアントの役割を引き受け、アクワイアラがサーバの役割を引き受ける。これらの相互作用を容易にするのに、ＨＴＴＰ／２（例えば、サーバプッシュ、ｃｏｎｎｅｃｔ）、ＷｅｂＳｏｃｋｅｔなどを使用する場合がある。個々の要求がオーバーレイネットワークエッジにおいて受信され、再フレーミングされ、アクワイアラに送信され、応答がそれぞれの多ウォレットプロセッサに返されることが好ましい。さらに、アクワイアラには、諸接続およびオーバーレイネットワークエッジ全体の接続トラフィックに対するＤＮＳベースのロードバランシングおよびフェイルオーバを実装することができる。
ウォレットサービス
以下では、マーチャントＭＥＲセキュアな接続、およびオペレータＯＰＲセキュアな接続を確立して維持することを容易にするための、アプリケーションプログラミングインターフェース（ＡＰＩ）について説明する。
ウォレットサービスとのセキュアなマーチャントＭＥＲ接続のために、アプリケーションプログラミングインターフェース（ＡＰＩ）ゲートウェイが使用されて、入来トランザクション要求の広範な制御およびスケーリングを可能にする。
オーバーレイネットワークエッジへの要求は、ＲＦＣ７５１９準拠のＪＷＴ ＥＳ２５６要求であることが好ましい。ヘッダ認証のために、好ましくはオーバーレイネットワークへの各要求にＡＰＩキーヘッダが含まれる。各ＪＷＴ要求には、シーケンスハンドシェイクプロトコルにより合意されたシーケンス番号が含まれることが好ましい。エッジに対する全ての接続は、相互認証済ＴＬＳ接続を介するものであることが好ましい。さらに、エッジに対する接続は永続的であり、ＤＮＳルックアップおよび再接続（リフレッシュ）プロトコルを以下のように実行することが好ましい。すなわち、接続喪失時と、与えられたＤＮＳホスト名についてのＤＮＳのＴＴＬにおいて、ＴＴＬ値がＤＮＳレコードで返される。
有効な要求を送信して有効化するために、ＭＥＲコネクタが用いる４つの鍵があることが好ましい。すなわち、エッジサーバ認証（Ａｕｔｈ）の認証局（ＣＡ）、ＴＬＳクライアント認証鍵、ＪＷＴ ＥＳ２５６署名鍵、およびＡＰＩヘッダ分散シークレットである。エッジサーバ認証のＣＡは、オーバーレイネットワークエッジプロバイダによって供給されるＥＣＤＳＡ Ｐ－２５６（ｐｒｉｍｅ２５６ｖ１）ＳＨＡ－２５６ハッシュであることが好ましく、公開部分がデータ連携サービスを介してマーチャントＭＥＲ接続に供給されることが好ましい。これは、各要求における有効化に使用される。ＴＬＳクライアント認証鍵は、ネットワーク動作により提供され、マスターマーチャントＭＥＲクライアント認証ＣＡにより署名される、ＥＣＤＳＡ Ｐ－２５６（ｐｒｉｍｅ２５６ｖ１）ＳＨＡ－２５６ハッシュであることが好ましく、鍵はエンドポイントごとに一意であることが好ましい。ＪＷＴ ＥＳ２５６署名鍵は、ネットワークオペレータによって提供されるＥＣＤＳＡ Ｐ－２５６（ｐｒｉｍｅ２５６ｖ１）鍵であることが好ましく、公開部分はデータ連携サービスを介して供給される。この鍵は、エンドポイントごとに一意であることが好ましい。ＡＰＩヘッダ分散シークレットは、例えば、ランダムな６４文字であってもよく、オーバーレイネットワークエッジプロバイダによって、データ連携サービスを介して供給される。この鍵も、エンドポイントごとに一意であることが好ましい。
全ての要求が、ＲＦＣ７５１９ＪＷＴ ＥＳ２５６要求を含むＨＴＴＰフォーマットの要求であることが好ましく、要求にはＡＰＩキーヘッダが含まれる。全ての応答が、ＲＦＣ７５１９ＪＷＴ ＥＳ２５６でフォーマットされることが好ましい。応答は、要求と同一の鍵を使用して署名される。この署名は検証されなければならない。
以下のリストには、代表的なＡＰＩエンドポイントが含まれる。１つのエンドポイントは、／ａｐｉ／…／ｉｓｏ８５８３タイプであり、これはＩＳＯ－８５８３トランザクションをサブミットするために使用されるＡＰＩエンドポイントである。そのシーケンス番号は、要求ごとに増分される。別のエンドポイントは、／ａｐｉ／…／ｓｅｑｕｅｎｃｅタイプであり、これは以下で説明するシーケンス番号確立プロトコルで使用されるエンドポイントである。このタイプのエンドポイントについての要求ナンスは、一意且つランダムなｕｉｎｔ６４値である。
以下のリストには、ＡＰＩ要求に対して期待される応答が含まれる。応答は、同一の鍵を使用してエンコードされたＪＷＴ ＥＳ２５６であることが好ましく、これは検証されなければならない。／ａｐｉ／…／ｉｓｏ８５８３タイプでは、応答シーケンス番号が要求シーケンス番号と一致するか、検証されるべきである。非エラー時のエラー文字列（ｓｔｒｉｎｇ）は、ブランクであるべきである。／ａｐｉ／…／ｓｅｑｕｅｎｃｅでは、応答ナンスが要求ナンスと一致するか、検証されるべきである。与えられるシーケンス番号は、将来の要求に使用される初期値である。
／ａｐｉ／…／ｓｅｑｕｅｎｃｅエンドポイントを使用して、初期シーケンス番号を確立する。／ａｐｉ／…／ｉｓｏ８５８３応答が、「無効なシーケンス番号」に関連するエラー状態をアラートする場合、このエンドポイントが新しいシーケンス番号を確立するのに使用される。このメカニズムを用いることによって、決済ネットワークに対するトランザクションリプレイ攻撃が阻止される。
オーバーレイネットワークエッジに対する全ての接続は、相互認証済ＴＬＳ接続上にあることが好ましい。好ましくは、ＴＬＳ接続は以下のことをしなければならない。すなわち、オーバーレイネットワークエッジによって提供された証明書が信頼できるＣＡに対して発行されたことを検証しなければならない（信頼できるＣＡのリストは、定期的または緊急に変更される場合がある）。そして、オーバーレイネットワークエッジが検証しなければならない、信頼できるＣＡによって発行されたクライアント証明書を提供しなければならない（通常、ネットワークオペレータがこのＣＡを制御しており、オーバーレイネットワークプロバイダに信頼できるＣＡリストを提供して、クライアント認証を実施する）。発行および取り消しを含め、厳格なＣＡおよび証明書管理の実施方法および手順を確立することは、外部システム、特にレガシーシステムとのセキュアな相互運用性を確保するのに重要である。セキュリティ侵害事象においてより容易に移行できるよう、複数の信頼できるＣＡがオーバーレイネットワークおよびネットワークオペレータの両方によって交換されることが好ましい。適当な計画によるＣＡローテーションも行われるべきである。
上述のように、エッジネットワークサーバへの接続は永続的であるが、接続喪失時、および与えられたホスト名についてＤＮＳのＴｉｍｅ Ｔｏ Ｌｉｖｅ（ＴＴＬ）満了時に、新しくＤＮＳルックアップを実行し、再接続することが好ましい。ＤＮＳルックアップが同一の結果を返す場合には、古い接続の継続使用が可能である。各ＤＮＳルックアップへの応答の一部として最新のＴＴＬが返されることが好ましい。
図１５は、本開示による（ＭＥＲを介する）レガシーシステム１５００の、エッジネットワークの仲介１５０４を介してブロックチェーンベースの決済ネットワークコア１５０２に対するセキュアな相互運用性の例を示している。エンコードされたＪＷＴ要求も例示されている。
このようにして全ての接続が相互認証され、暗号化されており、関連付けられるＴＬＳ鍵および証明書が上述のように管理されることが好ましい。接続ベースの相互認証および暗号化により、オーバーレイネットワークエッジによってエンフォースされるセキュリティの１レイヤが提供される。追加的な保護としてメッセージ認証を使用し、別個の深いセキュリティのレイヤを提供することにより、エッジおよび他の潜在的な中間オーバーレイネットワーク要素を通過するメッセージのエンドツーエンドの真正性をセキュアにすることもできる。次に、この保護レイヤを提供する代表的なメッセージ認証フレームワークを説明する。
メッセージ認証仕様に従って、ＨＴＴＰメッセージ（要求および応答）に対する全ての署名が生成され、送信され、検証されることが好ましい。この仕様では、認証済みメッセージは、所与のシンタックス、例えば｛ａｕｔｈ－ｌｉｎｅ、ａｕｔｈ－ｓｃｈｅｍｅ、ａｕｔｈ－ｓｐｅｃ、ｋｅｙ－ｉｄ、ｅｃｄｓａ－ｐｕｂｌｉｃ ｋｅｙ、ｓｉｇｎｅｄ－ｈｅａｄｅｒｓ、ｌｏｗｅｒｃａｓｅ－ｈｅａｄｅｒ－ｎａｍｅ、ｒｅｑｕｅｓｔ－ｓｉｇ－ｓｔｒｉｎｇ、およびｓｉｇ｝を持つＨＴＴＰ認可ヘッダを含まなければならないと定められている。仕様に準拠するために、好ましくは全てのＨＴＴＰ要求メッセージに適切な要求署名導出関数に従う署名が施される。特に、ＨＴＴＰ要求については、認可ヘッダ署名に対するｈａｓｈ－ｔｏ－ｓｉｇｎ入力が、その関数で定められる規則によって導出される。仕様によればさらに、２ＸＸまたは３ＸＸステータスコードを持つ応答をするのに、全てのＨＴＴＰ応答メッセージに署名を施すことが必要とされる。ＨＴＴＰ応答については、認可ヘッダ署名に対するｈａｓｈ－ｔｏ－ｓｉｇｎ入力が応答署名導出関数により指定される通りに導出される。
メッセージ認証（ＨＴＴＰ）キーは、非対称メッセージ認証キーであり、これらを用いて各メッセージへの署名と真正性の検証を行う（エンドツーエンド）。クライアントＨＴＴＰ秘密鍵は、決済ネットワーク宛のメッセージに署名するためにマーチャントＭＥＲ（および管理サーバコンポーネント）によって使用され、クライアント公開鍵は、入来メッセージの真正性を検証するために決済ネットワークによって使用される。同様に、サーバＨＴＴＰ秘密鍵は、応答に署名するために決済ネットワークによって使用され、サーバＨＴＴＰ公開鍵は、応答の真正性を検証するためにマーチャントＭＥＲ（および管理サーバ）によって使用される。オペレータＯＰＲ通信では役割が逆転し、決済ネットワークが要求に署名し、オペレータＯＰＲサーバがその応答に署名する。
本明細書で使用される際、「展開済」の鍵は、発信元のシステムにより証明され、受信側システムによって展開済と確認された公開鍵である。
以下は、代表的なクライアントＨＴＴＰ鍵の要件である。
管理サーバシステムは、データ連携サービスＡＰＩを介して、決済ネットワークに対するクライアントＨＴＴＰ公開鍵の証明および取り消しを実施することが好ましい。
管理サーバは、コア決済ネットワークへの全ての要求メッセージに、現在展開済の管理者公開鍵に対応する秘密鍵を使用して署名することが好ましい。
決済ネットワークは、全ての管理サーバ発信メッセージのクライアント署名を、現在展開済の管理者公開鍵を使用して検証することが好ましい。
各マーチャントＭＥＲサーバは、決済ネットワークＩＳＯ８５８３トランザクションメッセージで示されるフォワーディングセンターＩＤについての現在展開済の公開鍵に対応する一意な秘密鍵を使用して、全てのトランザクション要求メッセージに署名することが好ましい。
決済ネットワークは、決済ネットワークＩＳＯ８５８３トランザクションメッセージで示されるフォワーディングセンターＩＤについての現在展開済の公開鍵を使用して、全てのマーチャントＭＥＲ発信メッセージのクライアント署名を検証することが好ましい。
以下は、代表的なサーバＨＴＴＰ鍵の要件である。
決済ネットワークシステムは好ましくは、管理サーバに対する決済ネットワークサーバＨＴＴＰ公開鍵の証明および取り消しを行わなければならない。
決済ネットワークは、管理サーバへの全ての応答メッセージに、現在展開済の決済ネットワーク公開鍵に対応する秘密鍵を使用して署名することが好ましい。
管理サーバおよびマーチャントＭＥＲサーバは、全てのＨＴＴＰ応答メッセージの署名を、現在展開済の決済ネットワーク公開鍵を使用して検証することが好ましい。
決済ネットワークは好ましくは、オペレータＭＥＲサーバへのＨＴＴＰ要求メッセージに、現在展開済の決済ネットワーク公開鍵に対応する秘密鍵を使用して署名しなければならない。
オペレータＯＰＲサーバは好ましくは、現在展開済の決済ネットワーク公開鍵を使用して、全てのＨＴＴＰ要求メッセージの署名を検証しなければならない。
マーチャントＭＥＲサーバは、マーチャントＭＥＲエンドポイントを使用して、決済ネットワークへのトランザクション要求を送信する。メッセージの本体は、ｂａｓｅ６４エンコードのＩＳＯ８５８３メッセージを含む文字列値の「ｒｅｑ」キーを含むＪＳＯＮオブジェクトであることが好ましい。成功すると、応答はステータスコード２００（ＯＫ）を持ち、応答本体は、Ｂａｓｅ６４エンコードのＩＳＯ８５８３応答メッセージを含む文字列値の「ｒｓｐ」キーを含むＪＳＯＮオブジェクトを含む。
決済ネットワークは、オペレータＯＰＲエンドポイントを使用して、宛先センターオペレータＯＰＲサーバのオペレータＯＰＲへ、トランザクション要求を送信する。メッセージの本体は、ｂａｓｅ６４エンコードのＩＳＯ８５８３メッセージを含む文字列値の「ｒｅｑ」キーを含むＪＳＯＮオブジェクトであることが好ましい。成功すると、応答はステータスコード２００（ＯＫ）を持ち、応答本体は、Ｂａｓｅ６４エンコードのＩＳＯ８５８３応答メッセージを含む文字列値の「ｒｓｐ」キーを含むＪＳＯＮオブジェクトを含む。
代表的な実施形態では、上述のＡＰＩは、エッジネットワークに配置されたＡＰＩゲートウェイに実装される。ＡＰＩゲートウェイは、オペレータがそのＡＰＩを、登録、管理、および配信できるようにするメカニズムを与える。とりわけ、ＡＰＩゲートウェイは、アクセス制御、トラフィック管理、レポーティング、ポリシー定義、および他のクラウドとの統合を実現する。アクセス制御では、ゲートウェイはＪＳＯＮウェブトークン（ＪＷＴ）およびＡＰＩキーを有効化し、それによりアイデンティティプロバイダ（ＩｄＰ）サービスのオフローディングを可能にする。ゲートウェイは、ＡＰＩキーの作成および管理を、そのライフサイクルにわたって容易にする。ゲートウェイは、トラフィックがオリジンサーバに達する前にトラフィックを認証するので、望ましくないＡＰＩコールを拒否するのに有用である。トラフィック管理では、ゲートウェイは、ユーザによる単位時間当たりの、およびＡＰＩ消費者当たりの、入来ＡＰＩ要求に対する限度のセットおよび強制を可能にする。内部チーム、戦略的パートナ、および開発者向けに、ＡＰＩアクセスの内部レベルをセットし、管理することができる。レポーティングは、ユーザがＡＰＩ消費者によるＡＰＩ使用の態様を知り、且つエラーパターンに対処することを可能にすることによって、ユーザによるＡＰＩ配信の最適化を可能にする。代表的なＡＰＩゲートウェイは、マサチューセッツ州ケンブリッジ、Ａｋａｍａｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．により提供される。
使用例
上記は、例えば（これに限定されるものではないが）決済ネットワークにおいて使用するための高性能コア分散型台帳およびトランザクションファブリックについて説明している。トランザクションは、ソースの値を宛先に移動するプリミティブに限定されず、むしろ、値または情報の変形、変換または転送を伴う任意の処理に限定される。性能コアは、限定されるものではないが、金融システムへの高性能トランザクション処理を含む無数の使用例をサポートするための基盤を提供する。
本明細書において使用される場合、処理時間は、動作要求（例えば、金融動作要求）が受信されてから応答が利用可能になるまでの経過時間として定義される。特定の動作は、台帳において複数のトランザクションを必要とすることができる。必要な全てのトランザクションが台帳に安全に記憶され、関連する全てのビジネスロジックが実行された場合、動作は完全に処理されたと見なされる。好ましくは、処理時間は、それよりも短くない場合（例えば、サブ秒）、数秒程度である。この方法で処理時間を維持することに加えて、コアネットワークは、大量の動作をサポートする。動作スループットは、コアネットワークによって動作が処理される速度として定義される。これは限定されるものではないが、望ましいスループットは、１秒あたり最大１０６（以上）の動作とすることができる。
一実施形態では、上述したアーキテクチャは、分散型台帳、すなわち、金融メッセージ台帳を提供する。台帳は、前述のブロックチェーン技術によって保護されたトランザクションの不滅のログを提供する。この文脈において使用される場合、ネットワークは、取得者（ＡＣＱ）および／または発行者（ＩＳＳ）への要求およびそれらからの応答を転送する既存の金融取引システムとインターフェース接続する機能を含む。代替の使用例は、管理値台帳であり、これは、管理された信用枠（または借方）に対するトランザクションの処理を可能にする。この使用例は、ＡＣＱ／ＩＳＳが、ＡＣＱ／ＩＳＳに連絡することなく後で貸方に記入／借方に記入されるネットワーク上のアカウント残高をプロビジョニングすることを可能にする。管理されたクレジットラインを超えるトランザクションは、ＡＣＱ／ＩＳＳにクエリを送信して承認を要求するためのフォールバックをトリガすることができる。典型的な使用では、トランザクションフローは、以下のとおりである。メッセージは、サイズが約１ＫＢと仮定される。そのメッセージは、エッジによって受信され、コアブロックチェーンネットワークにわたって（そこから）配信される。トランザクションが確定した後（およびブロックチェーン受信が受信されると）、エッジから応答が送信される。全体として、最大往復時間は、好ましくは２秒以下のオーダーである。さらに、決済ネットワークは、処理された全てのトランザクションについて追加の１ＫＢメッセージが決済のために決済ネットワークから送信される１日の終わりのバッチ決済プロセスを処理することができる。これらのバッチ処理されたトランザクションは、数時間以内に処理されてログに記録されることが予期される。
トランザクションを高速且つ低レイテンシで処理する必要がある任意の他の使用例は、このアーキテクチャから恩恵を受けることができる。ロイヤルティポイントの管理は、非金銭的用途の１つの非限定的な例である。
本明細書のアーキテクチャもまた非常に安全である。暗号化、認証、デジタル署名およびその他の技術が使用され、顧客のプライバシおよびデータの整合性を保証する。
本明細書の技術は、データセキュリティを全て犠牲にすることなく、（処理されたトランザクションの数に関して）高性能および非常に低いレイテンシを示すグローバルな記録システムを提供する。
本明細書の管理対象ネットワークは、非常に安全な許可ネットワークである。したがって、トランザクションの収集およびブロックの構築時間は、ネットワーク全体にブロックを伝播するのにかかる時間近くまで低減される。本明細書のアプローチは、ネットワークのレイテンシがインターネット上の任意のリモート位置間で一般に１秒未満であるという事実を利用しており、さらに、これらのレイテンシは、前述した方法で高度に分散されたエッジ周辺および分散性の低いコアを使用することによってさらに短縮される。
説明されているアーキテクチャは、高性能であり、既知のブロックチェーンネットワーク環境に存在する多くの問題、すなわち、ネットワークレイテンシ、ネットワーク使用率、確認深度、クロックスキュー、トポロジ的ボトルネックおよびその他の要因を解消する。ソリューションを容易にするために、上記のように、コアネットワーク自体は、良好な地理的およびトポロジ的近接性を有することが好ましい。コンセンサスプロトコル（ブロックチェーンネットワークにおいて使用されるプロトコルなど）は、大容量のメッセージングに依存することが多いため、これは望ましいことである。これは、ブロックの伝播時間がシステムの応答時間要件に対して適時に留まることを保証するため、好ましくは、使用されるコンセンサスプロトコルに応じて、コアネットワークは、低いネットワークレイテンシおよび高い相互接続性を有する。オーバーレイの安全なエッジネットワークを活用して、非常に安全で高性能な完全にグローバルな決済ネットワークを確保します。
ブロックチェーンシステムは、確認の概念を含む。トランザクションが確認され、ブロックチェーンのブロックに追加されると、１つの確認があると見なされる。ブロックチェーンに追加される後続の各ブロックは、そのトランザクションの確認レベルを上げる。トランザクションの確認が多いほど、トランザクションをブロックチェーンから削除することが困難になる。ほとんどのブロックチェーンシステムは、トランザクションが確定されて永続的であると見なされるまで、特定の数の確認を待機する規則を採用しており、これは、「確認深度」と呼ばれる。好ましくは、本明細書のソリューションは、構成可能または可変の確認深度を利用して、トランザクションの回復力要件をサポートする。
コア内のコンピューティングノードは、好ましくはタイムサーバを使用して時間同期される。
コアネットワークは、非ブロッキングフルメッシュ相互接続トポロジとして構成されることができる。１つの好ましいアプローチは、コアネットワークを高回復力の部分メッシュ相互接続トポロジとして実装する。しかしながら、（ネットワークの停止および攻撃に対する）回復力とブロック伝播時間のバランスをとるために、前述したように、効率的なトポロジ認識データ伝播プロトコルが実装されることが好ましい。プロトコルは、編成がネットワークレイヤにおいて行われるマルチキャストプロトコルに基づいて構築されることが好ましい。
本明細書において使用される場合、ノードは、ネットワーク上のコンピューティングの高（上位）レベルユニットである。通常、ノードは、ノードの作業負荷を処理する１つ以上の物理マシン（サーバ）から構成される。好ましくは、ノードの実装は、他のノードから抽象化され、そのような他のノードに対して、各ピアノードは、ネットワーク上で単一のエンティティとして見える。トランザクションレート（例えば、１秒あたり１００万トランザクション）をサポートするために、ノードは、複数の物理マシンに構成されることが好ましい。上記のように、好ましくは、ノードはまた、ミリ秒未満の正確なタイムスタンプを生成するために使用されるタイムサーバも有する。さらに、ノードは、コンセンサスに必要な署名およびエントロピを生成するために使用される暗号化エンジンおよび乱数ジェネレータ（ＲＮＧ）サーバを含む。最後に、ノードは、到来トランザクションを処理し且つ上述した方法でブロックチェーンにそれらを追加するトランザクション処理サーバを含む。
本明細書で説明した許可ベースのアプローチでは、ノードは、マイニング証明を提供することにより、それ自体がマイナーであることを証明する。マイニング証明は、ノードがブロック（またはそのセグメント）の正当なマイナーであることを数学的に証明するノードによって提示されるデータである。証明は、適切なブロックチェーンの構築（すなわち、信頼）が自己検証可能であるように、ブロックヘッダに記録される。限定を意図するものではないが、分散型検証可能ランダム機能（ＤＶＲＦ）が使用され、マイニング証明を容易にすることができる。代替のアプローチは、ハードウェアで生成された信頼できる乱数の使用を含む。
実現技術
上記のように、本開示の技術は、コンテンツ配信ネットワーク（ＣＤＮ）などのオーバーレイネットワークの文脈内で実装されることができるが、これは限定ではない。図９に示すようなこの種の既知のシステムでは、分散型コンピュータシステム１００は、コンテンツ配信ネットワーク（ＣＤＮ）として構成され、インターネットの周りに分散された１組のマシン１０２ａ－ｎを有すると仮定される。通常、ほとんどのマシンは、インターネットのエッジの近く、すなわち、エンドユーザアクセスネットワークまたはその近くにあるサーバである。ネットワーク動作コマンドセンタ（ＮＯＣＣ）１０４は、システム内の様々なマシンの動作を管理する。ウェブサイト１０６などのサードパーティサイトは、コンテンツ（例えば、ＨＴＭＬ、埋め込みページオブジェクト、ストリーミングメディア、ソフトウェアダウンロードなど）の配信を、分散型コンピュータシステム１００、特に「エッジ」サーバにオフロードする。通常、コンテンツプロバイダは、コンテンツプロバイダのドメインまたはサブドメインをサービスプロバイダの権限のあるドメイン名サービスによって管理されるドメインに指定すると、エイリアスによって（例えば、ＤＮＳ ＣＮＡＭＥによって）それらのコンテンツ配信をオフロードする。コンテンツを希望するエンドユーザは、そのコンテンツをより確実に且つ効率的に取得するために分散型コンピュータシステムに誘導される。詳細は示していないが、分散型コンピュータシステムはまた、エッジサーバから使用状況やその他のデータを収集し、そのデータを領域または領域セットにわたって集約し、監視、ロギング、アラート、請求、管理およびその他の運用および管理機能を容易にするために他のバックエンドシステム１１０、１１２、１１４および１１６にそのデータを渡す分散型データ収集システム１０８などの他のインフラストラクチャを含むこともできる。分散型ネットワークエージェント１１８は、ネットワークならびにサーバの負荷を監視し、ネットワーク、トラフィックおよび負荷データを、ＣＤＮによって管理されるコンテンツドメインについて信頼できるＤＮＳクエリ処理機構１１５に提供する。分散型データ伝送機構１２０が使用され、制御情報（例えば、負荷バランシングを容易にするためにコンテンツを管理するためのメタデータなど）をエッジサーバに配信することができる。
図１０に示すように、所与のマシン２００は、１つ以上のアプリケーション２０６ａ－ｎをサポートするオペレーティングシステムカーネル（Ｌｉｎｕｘまたはバリアントなど）２０４を実行するコモディティハードウェア（例えば、インテルペンティアムプロセッサ）２０２を備える。例えば、コンテンツ配信サービスを容易にするために、所与のマシンは、通常、ＨＴＴＰプロキシ２０７（「グローバルホスト」プロセスと呼ばれることもある）、ネームサーバ２０８、ローカル監視プロセス２１０、分散型データ収集プロセス２１２などのアプリケーションのセットを実行する。ストリーミングメディアの場合、マシンは、通常、サポートされるメディア形式によって要求される１つ以上のメディアサーバを含む。
ＣＤＮエッジサーバは、好ましくは構成システムを使用してエッジサーバに配信される構成ファイルを使用して、好ましくはドメイン固有で顧客固有ベースで、１つ以上の拡張コンテンツ配信特徴を提供するように構成される。所与の構成ファイルは、好ましくはＸＭＬベースであり、１つ以上の高度なコンテンツ処理特徴を容易にするコンテンツ処理ルールおよびディレクティブのセットを含む。構成ファイルは、データ転送機構を介してＣＤＮエッジサーバに配信されることができる。米国特許第７，１１１，０５７号明細書は、エッジサーバのコンテンツ制御情報を配信および管理するための有用なインフラストラクチャを示しており、このおよび他のエッジサーバ制御情報は、ＣＤＮサービスプロバイダ自体、または（エクストラネットなどを介して）発信元サーバを動作させるコンテンツプロバイダの顧客によってプロビジョニングされることができる。
ＣＤＮは、米国特許第７，４７２，１７８号明細書に記載されているような記憶サブシステムを含むことができ、その開示は、参照により本明細書に組み込まれる。
ＣＤＮは、サーバキャッシュ階層を動作させて、顧客コンテンツの中間キャッシングを提供し、そのようなキャッシュ階層サブシステムの１つは、米国特許第７，３７６，７１６号明細書に記載されており、その開示は、参照により本明細書に組み込まれる。
ＣＤＮは、米国特許出願公開第２００４００９３４１９号明細書に記載されている方法で、クライアントブラウザ、エッジサーバおよび顧客発信元サーバ間で安全なコンテンツ配信を提供することができる。そこで説明されているアプローチは、ＳＳＬで保護されたエッジネットワークと呼ばれることもある。一般的な運用シナリオでは、安全なコンテンツ配信は、一方ではクライアントとエッジサーバプロセスとの間、他方ではエッジサーバプロセスと発信元サーバプロセスとの間でＳＳＬベースのリンクを行使する。これは、ＳＳＬで保護されたウェブページおよび／またはそのコンポーネントを、エッジサーバを介して配信されることを可能にする。セキュリティを強化するために、サービスプロバイダは、エッジサーバに関連する追加のセキュリティを提供することができる。これは、セキュリティカメラによって監視されるロックされたケージに配置されたエッジサーバを備える安全なエッジ領域の動作と、鍵管理サービスの提供などを含むことができる。ここでの一実施形態では、ウォレットサービスは、ＳＳＬで保護されたエッジネットワークの前または後に配置されることができる。
一般的な動作では、コンテンツプロバイダは、ＣＤＮによって提供したいコンテンツプロバイダのドメインまたはサブドメインを識別する。ＣＤＮサービスプロバイダは、コンテンツプロバイダドメインをエッジネットワーク（ＣＤＮ）ホスト名に（例えば、正規名またはＣＮＡＭＥを介して）関連付け、そして、ＣＤＮプロバイダは、そのエッジネットワークホスト名をコンテンツプロバイダに提供する。コンテンツプロバイダのドメインまたはサブドメインへのＤＮＳクエリがコンテンツプロバイダのドメイン名サーバにおいて受信されると、それらのサーバは、エッジネットワークのホスト名を返すことによって応答する。エッジネットワークのホスト名は、ＣＤＮを指し、そのエッジネットワークのホスト名は、その後にＣＤＮネームサービスを介して解決される。そのために、ＣＤＮネームサービスは、１つ以上のＩＰアドレスを返す。次に、要求元のクライアントブラウザは、ＩＰアドレスに関連付けられたエッジサーバに対して（例えば、ＨＴＴＰまたはＨＴＴＰＳを介して）コンテンツ要求を行う。要求は、発信元のコンテンツプロバイダのドメインまたはサブドメインを含むホストヘッダを含む。ホストヘッダを有する要求を受信すると、エッジサーバは、その構成ファイルを確認して、要求されたコンテンツドメインまたはサブドメインが実際にＣＤＮによって処理されているかどうかを判定する。その場合、エッジサーバは、構成において指定されるように、そのドメインまたはサブドメインのコンテンツ処理ルールおよびディレクティブを適用する。これらのコンテンツ処理ルールおよびディレクティブは、ＸＭＬベースの「メタデータ」構成ファイル内に配置されることができる。
上述したクライアントからエッジサーバへのマッピング技術は、ウォレットまたはウォレットサービス（「クライアント」）をエッジサーバに関連付けるために使用されることができる。典型的な使用例では、そのウォレットまたはウォレットサービスから開始された、またはそれに関連付けられたトランザクションは、その後、本明細書で説明するようなさらなる処理のためにエッジサーバを通過してコアに進む。上記のように、ウォレットまたはウォレットサービス（またはその一部）はまた、ウォレット要求がエッジを介してウォレットまたはウォレットサービスに渡り、コアに進むように、エッジの内側に存在することもある。トランザクション処理の一部は、エッジサーバにおいて実行されることができる。
上述した各プロセスは、好ましくは、専用マシンとして、１つ以上のプロセッサにおいて実行可能なプログラム命令のセットとしてコンピュータソフトウェアに実装される。
本明細書の主題が提供される代表的なマシンは、ＬｉｎｕｘまたはＬｉｎｕｘバリアントオペレーティングシステムを実行するインテルハードウェアプロセッサベースのコンピュータと、説明した機能を実行するための１つ以上のアプリケーションである。上述したプロセスの１つ以上は、説明された機能を実行するためのコンピュータプログラムとして、すなわち、コンピュータ命令のセットとして実装される。
上記は、本発明の特定の実施形態によって実行される特定の動作の順序を説明しているが、代替の実施形態は、異なる順序で動作を実行し、特定の動作を組み合わせ、特定の動作を重複することができるなどのため、そのような順序は例示であることを理解されたい。本明細書における所与の実施形態への言及は、記載された実施形態が特定の特徴、構造、または特性を含むことができることを示すが、全ての実施形態は、必ずしも特定の特徴、構造、または特性を含まなくてもよい。
開示された主題は、方法またはプロセスの文脈において説明されてきたが、主題はまた、本明細書の動作を実行するための装置にも関する。この装置は、必要な目的のために特別に構築された特定のマシンであってもよく、またはコンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ化または再構成されるコンピュータを備えてもよい。そのようなコンピュータプログラムは、これらに限定されるものではないが、光ディスク、ＣＤ－ＲＯＭ、および光磁気ディスクを含む任意の種類のディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気もしくは光カード、または電子命令を記憶するのに適した任意の種類の媒体などの、それぞれがコンピュータシステムバスに接続されているコンピュータ可読記憶媒体に記憶されることができる。本発明の所与の実装は、Ｌｉｎｕｘなどのオペレーティングシステムを実行する標準のインテルハードウェアプラットフォーム上のＤＮＳ準拠ネームサーバ（例えば、ＢＩＮＤ）と連動して実行される所与のプログラミング言語で書かれたソフトウェアである。機能は、ネームサーバコードに組み込まれてもよく、またはそのコードの補助として実行されてもよい。本明細書における技術を実装するマシンは、プロセッサ、上述した方法を実行するためにプロセッサによって実行される命令を保持するコンピュータメモリを備える。
システムの所与のコンポーネントは別個に説明されているが、当業者は、機能のいくつかが所与の命令、プログラムシーケンス、コード部分などにおいて組み合わされるまたは共有されることができることを理解するであろう。
システムの所与のコンポーネントは別個に説明されているが、当業者は、機能のいくつかが所与の命令、プログラムシーケンス、コード部分などにおいて組み合わされるまたは共有されることができることを理解するであろう。本明細書で説明するアプリケーションまたは機能は、他のアプリケーションへのフックの提供、プラグインとしての機構の使用の促進、機構へのリンクなどによって、ネイティブコードとして実装されることができる。
本明細書の技術は、一般に、技術または技術分野に対する上述した改善、ならびに様々な分野に対する特定の技術改善を提供する。
上述した各プロセスは、好ましくは、専用マシンとして、１つ以上のプロセッサにおいて実行可能なプログラム命令のセットとしてコンピュータソフトウェアに実装される。
エッジネットワークは、様々な技術を使用してコアと通信することができる。利用されることができる代表的なオーバーレイネットワーク技術は、米国特許出願公開第２０１５／０１８８９４３号明細書および同２０１７／０１９５１６１号明細書に記載されているものを含み、それらの開示は、参照により本明細書に組み入れられる。とりわけ、これらの公開は、一般にオーバーレイを介した、ならびに（非公開で管理されることができる）企業データセンタとサードパーティのソフトウェア・アズ・ア・サービス（ＳａａＳ）プロバイダとの間の広域ネットワーク（ＷＡＮ）アクセラレーションサービスを促進するために使用されるＣＤＮリソースを説明している。１つの典型的なシナリオでは、いわゆるルーティングオーバーレイは、既存のコンテンツ配信ネットワーク（ＣＤＮ）インフラストラクチャを活用して、ダウンリンクを迂回するかまたは最小レイテンシを有する経路を見つけることにより、トランスポートプロトコルとしてインターネットプロトコル（ＩＰ）を使用する任意のアプリケーションの大幅な性能向上を提供する。他のアプローチは、マルチキャスト、ユニキャスト、ブロードキャストまたはその他のパケット転送技術を使用して、エッジからコアにメッセージを提供することである。
本明細書の技術は、一般に、技術または技術分野に対する上述した改善、ならびに全て上述したように、分散型ネットワーキング、分散型トランザクション処理、広域ネットワークにアクセス可能なトランザクション処理システム、高性能、低レイテンシのトランザクション処理システム、非ブロッキングフルメッシュ相互接続システムなどを含む様々な分野に対する特定の技術改善を提供する。
本明細書において提供されるＯＰＲホストのサービスは、オーバーレイネットワーク基盤が上述のようなオーバーレイネットワーク－決済ネットワークの統合および相互運用性をサポートするのに如何に有用であるかを示す、単なる一例である。オーバーレイネットワークを用いて、決済ネットワークに関連付けられる操作を容易にする他のサービス（典型的には、サーバ）をホストすることができる。
我々の発明を説明してきたが、主張されているのは以下のとおりである。

Claims (9)

  1. トランザクション要求を受信して、追加される一方の不変なデータブロックのチェーンに加工する、ネットワークコアを構成するトランザクション処理コンピューティング要素のセットに関連して運用する方法であって、データブロックはトランザクションの集合であり、トランザクションがデータブロック内に記録されて存在することは暗号化ハッシュにより検証可能であり、前記トランザクション要求は、サードパーティに関連付けられるレガシーコンピューティング基盤から生じるものであり、
    前記レガシーコンピューティング基盤と前記ネットワークコアとの間において、前記トランザクション要求が前記ネットワークコアに入るエントリポイントとして機能する複数のエッジサーバを含むオーバーレイネットワークを構成することと、
    前記複数のエッジサーバと前記レガシーコンピューティング基盤との間で永続化される、トランスポートレイヤーセキュリティ（ＴＬＳ）ベースの相互認証済の永続的な接続を構成することと、
    前記レガシーコンピューティング基盤から前記オーバーレイネットワーク内の上流エッジサーバへのアクセスを制限することと
    を含む、方法。
  2. 前記オーバーレイネットワーク内の前記上流エッジサーバが、鍵素材を記憶するウォレットサービスをサポートするものである、請求項１に記載の方法。
  3. 前記ウォレットサービスにおいて個々のトランザクション要求を受信し、前記個々の要求をフレーミングし、それらを前記レガシーコンピューティング基盤に転送することと、
    前記レガシーコンピューティング基盤からの応答を受信し、前記応答を前記ウォレットサービスに転送し戻すことと
    をさらに含む、請求項２に記載の方法。
  4. 前記複数のエッジサーバに関連して、アプリケーションプログラミングインターフェース（ＡＰＩ）ゲートウェイを構成することをさらに含み、前記ＡＰＩゲートウェイが、前記レガシーコンピューティング基盤に関連付けられた１つ以上のＡＰＩをサポートするものである、請求項１に記載の方法。
  5. 前記ネットワークコアのコンピューティング要素が、ブロックチェーンベースのシステムをホストする、請求項１に記載の方法。
  6. 前記追加される一方の不変なデータブロックのチェーンが、ブロックチェーンである、請求項１に記載の方法。
  7. 前記ブロックチェーン内の所与のトランザクションはデジタル署名が施され、自己検証可能である、請求項６に記載の方法。
  8. 前記ネットワークコアのコンピューティング要素から前記レガシーコンピューティング基盤へのインバウンド接続性、および前記レガシーコンピューティング基盤から前記ネットワークコアのコンピューティング要素へのアウトバウンド接続性が、前記レガシーコンピューティング基盤に関連付けられた１つ以上のトランザクションプロトコルを変更せずに実装される、請求項１に記載の方法。
  9. 前記ＴＬＳベースの相互認証済の永続的な接続が、前記レガシーコンピューティング基盤に対して、前記オーバーレイネットワークエッジサーバを介する前記ネットワークコアのコンピューティング要素へのセキュアで回復力のあるアクセスを提供する、請求項１に記載の方法。

JP2021532118A 2018-12-05 2019-12-05 外部システムに対してのセキュアな相互運用性を伴う高性能分散型記録システム Pending JP2022512324A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862775684P 2018-12-05 2018-12-05
US62/775,684 2018-12-05
US16/695,521 US11483347B2 (en) 2018-12-05 2019-11-26 High performance distributed system of record with secure interoperability to external systems
US16/695,521 2019-11-26
PCT/US2019/064596 WO2020118007A1 (en) 2018-12-05 2019-12-05 High performance distributed system of record with secure interoperability to external systems

Publications (1)

Publication Number Publication Date
JP2022512324A true JP2022512324A (ja) 2022-02-03

Family

ID=70972582

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021532118A Pending JP2022512324A (ja) 2018-12-05 2019-12-05 外部システムに対してのセキュアな相互運用性を伴う高性能分散型記録システム

Country Status (4)

Country Link
US (1) US11483347B2 (ja)
EP (1) EP3891965A4 (ja)
JP (1) JP2022512324A (ja)
WO (1) WO2020118007A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020081727A1 (en) 2018-10-16 2020-04-23 Eluvio, Inc. Decentralized content fabric
CN111383022B (zh) * 2018-12-29 2020-12-08 广州市百果园信息技术有限公司 聚合支付的后台架构方法、系统、计算机设备及存储介质
US20200396787A1 (en) 2019-06-13 2020-12-17 Toyota Motor North America, Inc. Managing transport network data access
US11310135B2 (en) * 2019-06-13 2022-04-19 Toyota Motor North America, Inc. Managing transport network data access
US11544252B2 (en) 2019-12-17 2023-01-03 Akamai Technologies, Inc. High performance distributed system of record with extended transaction processing capability
US20210397655A1 (en) * 2020-03-11 2021-12-23 Cleveland State University Secure hierarchical processing using a secure ledger
US20210398093A1 (en) * 2020-06-19 2021-12-23 Mastercard International Incorporated Method and system for payment integration with provenance supply chain events
CN115777193A (zh) * 2020-08-04 2023-03-10 英特尔公司 用于边缘使能器服务器装载的边缘安全程序
CN112187866B (zh) * 2020-09-03 2021-10-15 山东大学 一种基于共享存储的新型区块链共识方法
US20220237594A1 (en) * 2021-01-26 2022-07-28 Akamai Technologies, Inc. High performance distributed system of record with wallet services resiliency
US11954656B1 (en) 2021-01-27 2024-04-09 Wells Fargo Bank, N.A. Management of requests to provider systems for performing functions within a distributed computing system
US11582294B2 (en) * 2021-06-04 2023-02-14 Zscaler, Inc. Highly scalable RESTful framework
US20230070039A1 (en) * 2021-09-08 2023-03-09 Mastercard International Incorporated Merchant universal payment identifier system
US11949583B2 (en) 2022-04-28 2024-04-02 Hewlett Packard Enterprise Development Lp Enforcing reference operating state compliance for cloud computing-based compute appliances

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7111057B1 (en) 2000-10-31 2006-09-19 Akamai Technologies, Inc. Method and system for purging content from a content delivery network
US7340505B2 (en) 2001-04-02 2008-03-04 Akamai Technologies, Inc. Content storage and replication in a managed internet content storage environment
US7133905B2 (en) 2002-04-09 2006-11-07 Akamai Technologies, Inc. Method and system for tiered distribution in a content delivery network
US20040093419A1 (en) 2002-10-23 2004-05-13 Weihl William E. Method and system for secure content delivery
US8769257B2 (en) 2008-12-23 2014-07-01 Intel Corporation Method and apparatus for extending transport layer security protocol for power-efficient wireless security processing
US9647835B2 (en) 2011-12-16 2017-05-09 Akamai Technologies, Inc. Terminating SSL connections without locally-accessible private keys
US10270809B2 (en) 2013-12-02 2019-04-23 Akamai Technologies, Inc. Virtual private network (VPN)-as-a-service with delivery optimizations while maintaining end-to-end data security
US9813343B2 (en) * 2013-12-03 2017-11-07 Akamai Technologies, Inc. Virtual private network (VPN)-as-a-service with load-balanced tunnel endpoints
US20180191503A1 (en) 2015-07-14 2018-07-05 Fmr Llc Asynchronous Crypto Asset Transfer and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US11025477B2 (en) 2015-12-31 2021-06-01 Akamai Technologies, Inc. Overlay network ingress edge region selection
US10346406B2 (en) 2016-03-28 2019-07-09 International Business Machines Corporation Decentralized autonomous edge compute coordinated by smart contract on a blockchain
JP6571609B2 (ja) 2016-07-28 2019-09-04 Kddi株式会社 ブロックチェーンを作成するシステム及びプログラム
CN110050474A (zh) * 2016-12-30 2019-07-23 英特尔公司 用于物联网网络中的复合对象的子对象的类型命名和区块链
WO2018231255A1 (en) * 2017-06-16 2018-12-20 Visa International Service Association Blockchain network interaction controller
US10361859B2 (en) * 2017-10-06 2019-07-23 Stealthpath, Inc. Methods for internet communication security
US10764031B2 (en) * 2017-12-07 2020-09-01 International Business Machines Corporation Blockchain system for pattern recognition
US20190347651A1 (en) * 2018-05-12 2019-11-14 Mauricio Octavio Moreno Computer-implemented system and method for transferring money from a sender to a recipient
US11462120B2 (en) * 2018-10-19 2022-10-04 Mastercard International Incorporated Method and system for conducting examinations over blockchain

Also Published As

Publication number Publication date
EP3891965A4 (en) 2022-08-10
US11483347B2 (en) 2022-10-25
EP3891965A1 (en) 2021-10-13
WO2020118007A1 (en) 2020-06-11
US20200186568A1 (en) 2020-06-11

Similar Documents

Publication Publication Date Title
US11483347B2 (en) High performance distributed system of record with secure interoperability to external systems
US11522676B2 (en) High performance distributed system of record with key management
US20230239135A1 (en) High performance distributed system of record with cryptographic service support
US11977924B2 (en) High performance distributed system of record with distributed random oracle
US11791982B2 (en) Concurrent transaction processing in a high performance distributed system of record
US10972568B2 (en) High performance distributed system of record
JP2022508247A (ja) 信頼度ベースのコンセンサスを伴う高性能分散型記録システム
Alizadeh et al. A survey of secure internet of things in relation to blockchain
US11829351B2 (en) High performance distributed system of record with hosted origin services
US20210182837A1 (en) High performance distributed system of record with delegated transaction signing
Baldi et al. Certificate Validation Through Public Ledgers and Blockchains.
He et al. A novel cryptocurrency wallet management scheme based on decentralized multi-constrained derangement
da Costa et al. Securing light clients in blockchain with DLCP
da Costa et al. DLCP: A protocol for securing light client operation in blockchains
US11985223B2 (en) High performance distributed system of record with key management
US20230185794A1 (en) High performance distributed system of record with ledger configuration system
Adams et al. Receipt-mode trust negotiation: efficient authorization through outsourced interactions
Yang et al. PADP: A parallel data possession audit model for cloud storage