JP2022535497A - Method, apparatus, and computer readable medium for transaction management across multiple heterogeneous computing networks - Google Patents
Method, apparatus, and computer readable medium for transaction management across multiple heterogeneous computing networks Download PDFInfo
- Publication number
- JP2022535497A JP2022535497A JP2021563612A JP2021563612A JP2022535497A JP 2022535497 A JP2022535497 A JP 2022535497A JP 2021563612 A JP2021563612 A JP 2021563612A JP 2021563612 A JP2021563612 A JP 2021563612A JP 2022535497 A JP2022535497 A JP 2022535497A
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- transactions
- network
- networks
- nodes
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 238000012546 transfer Methods 0.000 claims description 178
- 230000009466 transformation Effects 0.000 claims description 16
- 230000009193 crawling Effects 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 9
- 238000012163 sequencing technique Methods 0.000 claims 2
- 238000004891 communication Methods 0.000 abstract description 10
- 238000013439 planning Methods 0.000 description 24
- 238000012384 transportation and delivery Methods 0.000 description 24
- 230000006870 function Effects 0.000 description 21
- 238000010586 diagram Methods 0.000 description 18
- 230000007246 mechanism Effects 0.000 description 10
- 230000008569 process Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 7
- 230000035772 mutation Effects 0.000 description 7
- 235000019892 Stellar Nutrition 0.000 description 6
- 230000000977 initiatory effect Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 239000008186 active pharmaceutical agent Substances 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- RTZKZFJDLAIYFH-UHFFFAOYSA-N Diethyl ether Chemical compound CCOCC RTZKZFJDLAIYFH-UHFFFAOYSA-N 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 239000013589 supplement Substances 0.000 description 2
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 239000002253 acid Substances 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000013178 mathematical model Methods 0.000 description 1
- 230000000116 mitigating effect Effects 0.000 description 1
- 230000000869 mutational effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- 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/08—Payment architectures
- G06Q20/16—Payments settled via telecommunication systems
-
- 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/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- 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/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
-
- 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/305—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wired telephone networks
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- 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/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
-
- 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/3218—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
分散台帳ネットワークなどの異種のコンピューティング・ネットワーク間に通信を提供するための方法及び装置。台帳不可知なオーバレイ・ネットワーク及びコンピューティング・アーキテクチャは、ビットコインのＤＬＴのような取引のみのＤＬＴネットワーク、イーサリアムのようなスマート・コントラクトベースのＤＬＴ、及び従来的な中央集権化されたシステムを含む、様々なデジタル通信ネットワークにまたがる。実装形態は、異質な管轄域境界、支払いネットワーク、バンキング・システム、パブリック及びプライベートな分散台帳、内部コーポレート会計システム、並びに取引所全体に対して取引情報を通信する。A method and apparatus for providing communication between heterogeneous computing networks, such as distributed ledger networks. Ledger-agnostic overlay networks and computing architectures include transaction-only DLT networks like Bitcoin's DLT, smart contract-based DLTs like Ethereum, and traditional centralized systems. , across various digital communication networks. Implementations communicate transaction information across heterogeneous jurisdictional boundaries, payment networks, banking systems, public and private distributed ledgers, internal corporate accounting systems, and exchanges.
Description
本出願は、２０１９年４月２９日に出願された米国仮特許出願第６２／８３９，９７１号の優先権を主張するものであり、その開示全体は参照により本明細書に組み込まれる。 This application claims priority to U.S. Provisional Patent Application No. 62/839,971, filed April 29, 2019, the entire disclosure of which is incorporated herein by reference.
本発明は、複数の異質なコンピューティング・ネットワークにまたがる価値移転の取引管理に関する。 The present invention relates to transaction management of value transfers across multiple heterogeneous computing networks.
著作権の注意
本特許文書の開示の一部には、著作権保護の対象となる内容が含まれる。特許商標庁の特許ファイル又は記録に現れる限りにおいては、著作権の所有者は、誰でも当該特許文書又は特許開示を複製することについて異議を唱えないが、それ以外の場合、如何なる場合でもすべての著作権を留保する。
COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise, in all cases, all rights reserved. Copyright reserved.
ほとんどの金融取引には、２つの異なる金融機関の台帳など、複数の専有システム台帳同士の協調を必要とする価値の移転が伴う。全世界の金融機関は、ＭＴ１０３又はＩＳＯ２００２２などの、標準化されたメッセージング・フォーマットで、国際銀行間通信協会（ＳＷＩＦＴ（登録商標）：Ｓｏｃｉｅｔｙ ｆｏｒ Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｂａｎｋ Ｆｉｎａｎｃｉａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）ネットワークに対する金融取引について情報を送り、受け取ることができる。ＳＷＩＦＴ（登録商標）のメッセージングにより、支払い注文を、金融機関同士で送信することが可能である。ＳＷＩＦＴ（登録商標）は、ファンドの移転は容易にしない。支払い注文は、機関が従来のバンキング・システムに互いに有しているコルレス口座によって決済されなければならない。それぞれの金融機関は、銀行であるか、又は銀行と提携するかのいずれかでなければならない。決済は、取引に関わるそれぞれの銀行の異種システム同士の台帳を比較する複雑な処理である。この処理は、確実であるが、比較的遅く、非効率的である。 Most financial transactions involve the transfer of value that requires coordination between multiple proprietary system ledgers, such as the ledgers of two different financial institutions. Financial institutions worldwide send and receive information about financial transactions to the Society for Worldwide Interbank Financial Telecommunications (SWIFT®) network in standardized messaging formats such as MT103 or ISO20022. be able to. SWIFT® messaging allows payment orders to be sent between financial institutions. SWIFT® does not facilitate fund transfers. Payment orders must be settled by correspondent accounts that institutions have with each other in traditional banking systems. Each financial institution must either be a bank or be affiliated with a bank. Settlement is a complex process that compares the ledgers of the disparate systems of each bank involved in the transaction. This process is robust, but relatively slow and inefficient.
支払い及び両替などの単純な取引でさえ、しばしば２つ以上の専有システムが関与する。より複雑な取引（購入、ローンなど）は、ほぼ常に２つ以上の台帳が関与する。複数の台帳及び／又は口座残高が関与する一般的な取引の実例としては、以下が挙げられる：
・安全性維持及び／又は利便性のために、価値がエージェント又はネットワークに移転される、保管業務（預入／引き出し）。
・支払いネットワーク同士で価値を移転する、送金（国境を越える支払い）。
・銀行及び支払いプロバイダが預入側の価値を内部台帳に記憶する、プロバイダをクロスする取引（例えば、ＰａｙＰａｌからＡｌｉＰａｙ）。
・価値の単位が、様々なＤＬＴプロバイダ上のウォレットの所有者によって移転される、又は売買される、分散台帳をクロスする取引（例えば、ビットコインからイーサリアム）。
・政府及び多国籍企業が、しばしば断片化した会計システムを有し、複数通貨を取引し、複雑なガバナンス構造を有する場合がある、エンタープライズ・ファイナンス（内部簿記＜－＞外部ファイナンス）。
・トレーダが、最大の流動性を得るために様々な取引所に複数の口座を有することがある、取引所をクロスする運用。取引所口座同士の移転は、コスト、又は時間がかかり、台帳をクロスする取引を伴う可能性がある。
・資産が１つのタイプから別のタイプに変形され、権利のバンドル／アンバンドルを伴う可能性がある（有益な所有権からの投票権の分離など）、資産の変形。
Even simple transactions such as payments and exchanges often involve two or more proprietary systems. More complex transactions (purchases, loans, etc.) almost always involve more than one ledger. Examples of common transactions involving multiple ledgers and/or account balances include:
• Custody operations (deposits/withdrawals) where value is transferred to agents or networks for security and/or convenience.
• Remittances (cross-border payments) that transfer value between payment networks.
• Cross-provider transactions (e.g. PayPal to AliPay) where the bank and payment provider store the value of the depositing party in an internal ledger.
• Cross-ledger transactions (eg Bitcoin to Ethereum) where units of value are transferred or bought and sold by wallet holders on various DLT providers.
• Enterprise finance (internal bookkeeping <->external finance) where governments and multinational corporations often have fragmented accounting systems, trade in multiple currencies and may have complex governance structures.
• Cross-exchange operations, where traders may have multiple accounts on various exchanges for maximum liquidity. Transfers between exchange accounts can be costly or time consuming and involve cross-ledger transactions.
• Transformation of assets, where assets are transformed from one type to another, possibly involving bundling/unbundling of rights (such as separation of voting rights from beneficial ownership).
ブロックチェーンなどの分散台帳技術（ＤＬＴ）は、デジタル・トークンによって表現され、またそこにカプセル化される代替性資産及び非代替性資産を用いて、非中央集権化されたネットワークを介して価値を移転するように実装されている。ＤＬＴネットワークのプロバイダ、つまり分散台帳プロトコルを開発して保守するパーティは、拡大と革新を続け、結果として、それぞれが自身の強みと弱みを持つ広範なＤＬＴオファリングをもたらしている。ＤＬＴオファリングごとに、取引は、合意メカニズムを通じて達成される確認に基づいて、台帳に記録される。ＤＬＴは、レガシーなバンキング・システムを仲介せず、あらゆるパーティが別のパーティに直接価値を移転できる可能性を有する。ＤＬＴは、仲介的なパーティを除去する目的を有する一方で、ＤＬＴネットワークの使われ方に対する制約は、一般的にデジタル・トークンが、ネイティブであり、自身が作成された基礎となるＤＬＴにロックされることである。それぞれのＤＬＴネットワークは、具体的な目的を達成するように設計することができるため、それ自身のトークン、プロトコル、合意メカニズム、及びオントロジを有することができる。したがって、ＤＬＴシステム同士の取引、つまり「クロス台帳」取引は、レガシーのデータ・システム同士に必要な協調と実質的には違わないやり方で調停を必要とする。軽減がない場合、スケーラビリティ及び拡張性を制限する「ウォールド・ガーデン」に参加者を限定するため、この制約によりＤＬＴのメリットが制限される。 Distributed ledger technologies (DLTs), such as blockchain, use fungible and non-fungible assets represented by and encapsulated in digital tokens to deliver value through decentralized networks. Implemented to move. DLT network providers, the parties that develop and maintain distributed ledger protocols, continue to expand and innovate, resulting in a wide range of DLT offerings, each with its own strengths and weaknesses. For each DLT offering, transactions are recorded in the ledger based on confirmations achieved through the consensus mechanism. DLT has the potential for any party to transfer value directly to another party without the intermediary of legacy banking systems. While DLT has the purpose of removing intermediary parties, a constraint on how DLT networks are used is that digital tokens are generally native and locked to the underlying DLT from which they were created. Is Rukoto. Each DLT network can have its own tokens, protocols, consensus mechanisms, and ontologies, as it can be designed to achieve specific goals. Transactions between DLT systems, or "cross-ledger" transactions, therefore require reconciliation in a manner that is not substantially different from the coordination required between legacy data systems. Without mitigation, this constraint limits the benefits of DLT as it limits participants to a "walled garden" that limits scalability and extensibility.
さらには、ほとんどの商業サービス及び金融サービスは、従来的な中央集権化された台帳（リレーショナル・データベース又はＮＯＳＱＬデータベース）技術上に構築される。これらのレガシーな移転プロバイダは、今日の取引の大多数に対して責任がある。参加者に排他的に「オンチェーン」（ＤＬＴのみ）又は従来的なものだけである取引方法を選ぶよう強制することなく、将来を見据えた意味のあるコマースを主導するために、取引システムは、従来の中央集権化された台帳システムと分散台帳システムとの両方に効率的にまたがるようにしなければならない。中央集権化された台帳プロバイダ及び分散台帳プロバイダの内部、及びそれら全体でシームレスな価値の移転を提供するためのフレームワークは、増大するブロックチェーン・オファリングのセットに対して、顕著な有用性を提供する。 Moreover, most commercial and financial services are built on traditional centralized ledger (relational or NOSQL database) technology. These legacy transfer providers are responsible for the majority of today's transactions. In order to drive forward-looking and meaningful commerce without forcing participants to opt for trading methods that are exclusively “on-chain” (DLT only) or conventional only, trading systems should: It must be able to efficiently span both traditional centralized ledger systems and distributed ledger systems. A framework for providing seamless transfer of value within and across centralized and distributed ledger providers would provide significant utility for the growing set of blockchain offerings. do.
２０１４年に、分散台帳のリーディング・カンパニーであるリップル及びステラの２社は、既知の「Ｎｏｓｔｒｏ Ｖｏｓｔｒｏ」技法を反映した国境を越えた価値のデリバリー向けの方法を導入した。これらの技法は、価値を移動する効率的なモデルを提供するが、方法は、個々のリップル及び／又はステラネットワークから独立した統合フレームワークをサポートしていない。したがって、すべての取引、レガシーなプロバイダ又はサード・パーティのプロバイダ同士の取引でさえも、これらのネットワークを横断することに依存している。加えて、方法は、サード・パーティの中央集権化された又は非中央集権化された取引所からの取引を価格決定するための統合されたモデルを含まず、ネットワーク上で流動性が限定されると著しい制限である。 In 2014, two leading distributed ledger companies, Ripple and Stellar, introduced methods for cross-border delivery of value that mirrored the well-known “Nostro Vostro” technique. While these techniques provide efficient models for moving value, the methods do not support an integrated framework independent of individual Ripple and/or Stellar networks. Therefore, all transactions, even those between legacy providers or third party providers, rely on traversing these networks. In addition, the method does not include an integrated model for pricing trades from third-party centralized or decentralized exchanges, with limited liquidity on the network. is a significant limitation.
２０１９年に、アクセンチュア及びＪＰモルガンは、「Ｅｎａｂｌｉｎｇ Ｃｒｏｓｓ－Ｂｏｒｄｅｒ Ｈｉｇｈ Ｖａｌｕｅ Ｔｒａｎｓｆｅｒ Ｕｓｉｎｇ Ｄｉｓｔｒｉｂｕｔｅｄ Ｌｅｄｇｅｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ」と題する文書を公表し、クロス台帳の価値移転を促進するための手法の結果を詳細にした。この手法のセンターピースは、台帳同士をブリッジするためにハッシュ時間ロック・コントラクト（ＨＴＬＣ：Ｈａｓｈ Ｔｉｍｅ Ｌｏｃｋｅｄ Ｃｏｎｔｒａｃｔ）を使用することである。本手法は任意の単一台帳への依存性を破壊するが、いくつかの制限がある。第１に、ＨＴＬＣの使用には、送り側と受け取り側との間に直接的な通信及び協調が必要である（ハッシュ化鍵の交換）。第２に、ＨＴＬＣメカニズムは、スマート・コントラクトをサポートする台帳を必要とするため、ビットコイン、リップル、ステラ又はレガシーな中央集権化されたシステムなど、スマート・コントラクトをサポートしていないＤＬＴと使用することができない。これらの制限のため、方法が多くのタイプの価値移転方法を容易にするには不適切となる。 In 2019, Accenture and JP Morgan published a document titled “Enabling Cross-Border High Value Transfer Using Distributed Ledger Technologies” detailing the results of approaches to facilitate cross-ledger value transfer. The centerpiece of this approach is the use of Hash Time Locked Contracts (HTLC) to bridge ledgers. Although our approach breaks the dependency on any single ledger, it has some limitations. First, the use of HTLC requires direct communication and cooperation between sender and receiver (exchange of hashing keys). Second, the HTLC mechanism requires a ledger that supports smart contracts, so it should be used with DLTs that do not support smart contracts, such as Bitcoin, Ripple, Stellar or legacy centralized systems. I can't. These limitations make the method unsuitable for facilitating many types of value transfer methods.
複数の台帳又は他の通信ネットワークをクロスする取引を効率的にサポートすることに失敗することに加え、既知のシステムは以下の取引を効率的にサポートすることに失敗する：通貨、トークン、又は資産をコンバートする取引；複数の管轄域又はポリシーを含む取引；オブジェクトの形態の変化を必要とする取引（資産を分解する／組み替える）；複数のバンキング・ネットワーク、支払いプロバイダ、又は移転サービス・プロバイダをクロスする取引。 In addition to failing to efficiently support transactions that cross multiple ledgers or other communication networks, known systems fail to efficiently support transactions of: currencies, tokens, or assets. transactions that involve multiple jurisdictions or policies; transactions that require changes in the form of objects (decomposing/recombining assets); crossing multiple banking networks, payment providers, or transfer service providers; transactions to do.
開示されるサポート実装形態は、クロス・ネットワーク移転に関して上述の制限のすべてを克服する。単純のために、本明細書において使用される場合、用語「移転」又は「ネットワーク移転」には、あらゆるタイプの取引又は変形が含まれる。分散台帳技術（ＤＬＴ）は、ネットワーク内での価値の送信を単純化するが、ほとんどの取引には、２つ以上の台帳が関与する。つまり、２つ以上の台帳に影響を及ぼす取引を記録するために、スケーラブルで、繰返し可能なフレームワークを要求する。開示される実装形態は、クロス台帳取引を編成し、担保契約及び価値の送信を合理化し、異質なシステム全体で資産及び債務を追跡し、規制監視を単純化して、基礎となるエコシステム全体で必要な流動性を維持する。 The disclosed supporting implementation overcomes all of the above limitations with respect to cross-network transfers. For simplicity, the term "transfer" or "network transfer" as used herein includes any type of transaction or transformation. Distributed ledger technology (DLT) simplifies the transmission of value within the network, but most transactions involve more than one ledger. This calls for a scalable, repeatable framework for recording transactions that affect more than one ledger. The disclosed implementation orchestrates cross-ledger transactions, streamlines the transfer of collateral agreements and value, tracks assets and liabilities across heterogeneous systems, simplifies regulatory oversight, and enables Maintain necessary liquidity.
開示される実装形態は、ビットコインのＤＬＴのような取引のみのＤＬＴネットワーク、イーサリアムのようなスマート・コントラクトベースのＤＬＴ、及び従来的な中央集権化されたコンピューティング・システムを含む様々なデジタル移転ネットワークにまたがるよう設計された台帳不可知なオーバレイ・ネットワークを含み、それによって、価値の移転がこのようなシステム内及びシステム全体に対して行われ、異質な管轄域境界、支払いネットワーク、バンキング・システム、パブリック及びプライベートな分散台帳、内部コーポレート会計システム、並びに取引所などを横断することが可能である。 The disclosed implementations can be used for a variety of digital transfers, including transaction-only DLT networks such as Bitcoin's DLT, smart contract-based DLTs such as Ethereum, and traditional centralized computing systems. Including ledger agnostic overlay networks designed to span networks whereby value transfers occur within and across such systems, heterogeneous jurisdictional boundaries, payment networks, banking systems. , public and private distributed ledgers, internal corporate accounting systems, and exchanges.
開示される実装形態は、価値移転、移転メッセージング規約と関連項目のカタログ、及び異質な実装形態を申し込み側の文法独立的なモデルにコンバートするための変換スキーマを含む金融取引の文法独立的なモデルである、金融オントロジを含む。 The disclosed implementation is a grammar-independent model of financial transactions that includes value transfer, a catalog of transfer messaging conventions and related items, and a conversion schema for converting heterogeneous implementations to an offer-side grammar-independent model. , which contains a financial ontology.
開示される実装形態はまた、価値の移動（及び他の金融取引）用にグローバルなインターフェースを提供することによって、個々の価値移転システム（例えば、ＤＬＴ、支払いネットワーク、バンキング・システム）の詳細を切り離す取引サービス・バス・モジュールを含む。 The disclosed implementations also decouple the details of individual value transfer systems (e.g., DLTs, payment networks, banking systems) by providing a global interface for value transfers (and other financial transactions). Contains a trading services bus module.
クロス・ネットワークの取引が提案されると、取引サービス・バス・モジュールは、提案された取引を検査して、ルート計画サービスを利用して、移転プロバイダ同士及び移転プロバイダ全体に対して一連のチェーン化されたサブ取引を使用してソースから最終的な受け取り側への潜在的な価値移転経路を発見する。次いで、送り側（又は人工知能エンジンであってもよい、送り側の代表）は、スピード、コスト、又は信頼性の選好に基づいて好ましいルートを選択することができる。 When a cross-network transaction is proposed, the transaction service bus module examines the proposed transaction and utilizes the route planning service to serially chain the transfer providers to each other and across transfer providers. Discover potential value transfer paths from sources to ultimate receivers using delivered subtransactions. The sender (or representative of the sender, which may be an artificial intelligence engine) can then select a preferred route based on speed, cost, or reliability preferences.
次いで、送り側は、好ましい選択を認可し、チェーン化移転ハンドラ・モジュールを利用して任意のラップされた移転システムと連携し、それによって異種ネットワークを通じた価値の送信を管理する。代替的には、取引は、外部ソースによって開始し、デリバリー命令を用いてインバウンドのソース・ウォレットに価値を送ることができる。ルート計画サービス・モジュールは、複数のサブ取引のチェーンを含む最適化された移転経路を決定するよう実行され、チェーン化移転ハンドラは、制御されたやり方で取引を実行する。 The sender then authorizes its preferred selections and utilizes a chained transfer handler module to interface with any wrapped transfer system, thereby managing the transfer of value across heterogeneous networks. Alternatively, a transaction can be initiated by an external source and send value to an inbound source wallet using delivery instructions. A route planning service module is executed to determine an optimized transfer path comprising a chain of multiple sub-transactions, and a chained transfer handler executes the transactions in a controlled manner.
本発明の一態様は、異質なコンピューティング・ネットワークをインターフェースし、移転プロバイダが変形取引を達成するための方法である。本明細書において使用される場合、言い回し「変形取引」とは、クロス台帳又はクロス・ネットワークで移動する価値、通貨／資産の変形を必要とする価値、複数の管轄域を有する価値、或いはオブジェクトの分解及び／又は組み替えを必要とする価値を含む取引を称する。方法は、少なくとも２つのネットワーク、プロバイダ、台帳、資産クラス若しくは形態、又は価値タイプにまたがる必要がある取引である、クロス・ネットワーク移転のための情報を受け取ることと、ソースと宛先との間の存在可能な経路を見つけるためにグラフ構造を巡回することであって、グラフ構造は、ネットワーク及び隣接するブリッジをクロールしてネットワーク・トポロジを作成して維持し、ノードのグラフ構造として記憶する複数エージェントのシステムによって形成され、グラフ構造内の各ノードは、関連付けられた属性変数のセットを有し、属性変数はブリッジ特性及び別のネットワーク内の少なくとも１つのノードへの論理ネットワーク・インターフェースを指定する、巡回することと、グラフ構造に基づいて、取引を実行するために取引ルート情報を生成することと、取引ルート情報に基づいて移転経路を決定することであって、移転経路はクロス台帳取引の適正な実行を保証するサブ取引のセットを含み、決定することは、移転メッセージング規約のカタログ、及び異質なネットワーク・プロバイダの実装形態を文法独立的なモデルを介して最適化された移転経路にコンバートするための変換スキーマを検査すること、並びに文法独立的なモデルに従ってサブ取引をモデリングすることを含む、決定することと、ネットワークにまたがるデリバリー・モデルを介して複雑な移転を開始することと、独立的な台帳を介する複雑な移転を、不変性及びプライバシーのためにゼロ知識証明を使用して記録することと、少なくとも２つのネットワーク内及び少なくとも２つのネットワーク同士で価値を移転するために論理インターフェースを適用することによってサブ取引を実行して、それによってクロス・ネットワーク取引を実現することと、を含む。 One aspect of the present invention is a method for interfacing heterogeneous computing networks to accomplish transformational transactions for transfer providers. As used herein, the phrase “transformation transaction” refers to value that moves cross-ledger or cross-network, value that requires currency/asset transformation, value that has multiple jurisdictions, or Refers to transactions involving value that require disassembly and/or reclassification. The method includes receiving information for cross-network transfers, transactions that need to span at least two networks, providers, ledgers, asset classes or forms, or value types, and existence between source and destination. Crawling a graph structure to find possible paths, the graph structure crawling the network and neighboring bridges to create and maintain a network topology, stored as a graph structure of nodes. Each node in the graph structure formed by the system has an associated set of attribute variables, the attribute variables specifying bridge characteristics and a logical network interface to at least one node in another network, a cyclic generating transaction route information for executing transactions based on the graph structure; and determining a transfer route based on the transaction route information, wherein the transfer route is an appropriate cross-ledger transaction. Include and determine a set of sub-transactions that warrant execution for converting catalogs of transfer messaging conventions and heterogeneous network provider implementations into optimized transfer paths via grammar-independent models. as well as modeling sub-transactions according to grammar-independent models and initiating complex transfers through delivery models across networks; Record complex transfers through the ledger using zero-knowledge proofs for immutability and privacy, and apply logical interfaces to transfer value within and between at least two networks. and executing sub-transactions by , thereby realizing cross-network transactions.
グラフ構造内のノードのペア及び対応する属性変数のセットは、ノードのペアのノード間の手続き的なリンクを提供するブリッジ・データ構造を定義することができ、ノードのペアのうち少なくとも一部は、異なるネットワーク内の口座に対応する。 Pairs of nodes and corresponding sets of attribute variables in the graph structure can define a bridge data structure that provides procedural links between the nodes of the pairs of nodes, at least some of the pairs of nodes , corresponding to accounts in different networks.
ブリッジ・データ構造は、少なくとも１つのソース・ウォレット、少なくとも１つの宛先ウォレット、サポートされる価値の単位、及びノードのペアのノード間でフローする取引通信のための取引価格決定モデルを指定することができる。ブリッジ・データ構造は、論理インターフェースに付加される変形ロジックを指定することができる。 The bridge data structure may specify at least one source wallet, at least one destination wallet, units of value supported, and a transaction pricing model for transaction communication flowing between nodes of a pair of nodes. can. A bridge data structure can specify transformation logic that is attached to a logical interface.
取引ルート情報の生成は、ノード巡回アルゴリズムに従ってグラフ構造を巡回すること、及び属性変数を解析することを含むことができる。各サブ取引へのリンクを伴う包括的なチェーン移転用の移転詳細は、巡回される移転ネットワークとは別個であってもよい分散台帳上で公表することができる。 Generating trading route information can include crawling the graph structure according to a node crawling algorithm and parsing attribute variables. Transfer details for a global chain transfer with links to each sub-transaction can be published on a distributed ledger that can be separate from the patrolled transfer network.
図１は、開示される実装形態による、変形取引を行うための異質なＤＬＴシステムをインターフェースする方法を図示している。１００２において、２つの異なるＤＬＴネットワークなど、少なくとも２つの異種ネットワークにまたがる、所望の／リクエストされるクロス台帳取引を説明する情報が受信される。１００４において、マルチネットワークのグラフ構造が読み取られる。グラフ構造は、ネットワークにまたがるブリッジに対応するノードをクロールすることによって作成することが可能である。グラフ構造の各ノードは、関連付けられた属性変数のセットをノード・メタデータとして有することができる。属性変数は、対応するネットワークにネイティブな価値の単位（トークン）、トークンを実装するスマート・コントラクトの識別情報、ブリッジに使用されるウォレット又は口座、ユーザに利用可能な価値ソース、並びにＡＰＩ及び他のネットワークへのネットワーク・インターフェースを含むことができる。１００６において、ノード巡回アルゴリズムに従ってグラフ構造を巡回して、所望の取引を容易にするブリッジ・ノードを検出することによって取引を成し遂げるために、取引ルーティング情報が生成される。１００８において、取引ルーティング情報を使用して選好に基づいてソースによって移転経路が選択され、移転が開始される。所望の移転経路は、リクエストされたクロス台帳取引の適正な実行を確実にする、サブ取引のチェーン化されたセットを含むことができる。１０１０において、クロス・ネットワーク取引を達成するために、指定されたインターフェースを使用してサブ取引が実行される。サブ取引は、異質なネットワーク上で、文法独立的な実行命令を基礎となる移転ネットワークによって認識される具体的な命令にコンバートするオントロジ・マッピングを使用して実行される。包括的な取引、及びすべてのサブ取引は、サブ取引に関与する台帳とは別個であってもよい台帳に記録することができる。独立的な台帳は、ゼロ知識証明を利用して不変性を実現しつつ取引プライバシーを維持することができる。サブ取引のチェーンは、ソース・ネットワーク、宛先ネットワーク、及びソース・ネットワークと宛先ネットワークとの間の接続として機能する他のネットワークにおける取引を含むことができることに留意されたい。 FIG. 1 illustrates a method of interfacing heterogeneous DLT systems for conducting variant transactions, according to disclosed implementations. At 1002, information is received that describes desired/requested cross-ledger transactions across at least two disparate networks, such as two different DLT networks. At 1004, the multi-network graph structure is read. A graph structure can be created by crawling nodes corresponding to bridges across the network. Each node of the graph structure can have an associated set of attribute variables as node metadata. Attribute variables are the unit of value native to the corresponding network (the token), the identity of the smart contract implementing the token, the wallet or account used for bridging, the value sources available to the user, and API and other A network interface to a network may be included. At 1006, trade routing information is generated for accomplishing trades by crawling the graph structure according to a node crawling algorithm to find bridge nodes that facilitate the desired trades. At 1008, a transfer path is selected by the source based on preferences using the transaction routing information and the transfer is initiated. A desired transfer path may include a chained set of sub-transactions that ensure proper execution of the requested cross-ledger transaction. At 1010, sub-transactions are executed using the specified interface to accomplish the cross-network transaction. Subtransactions are executed on heterogeneous networks using ontology mappings that convert grammar-independent execution instructions into concrete instructions recognized by the underlying transfer network. A global transaction, and all sub-transactions, can be recorded in a ledger that may be separate from the ledgers involved in the sub-transactions. Independent ledgers can leverage zero-knowledge proofs to achieve immutability while maintaining transactional privacy. Note that a chain of subtransactions can include transactions in the source network, the destination network, and other networks that act as connections between the source and destination networks.
図２は、図１の方法及び他の変形移転を達成するための、開示される実装形態によるコンピュータ・アーキテクチャを概略的に図示している。アーキテクチャ２０００は、取引サービス・バス・モジュール２００２、チェーン化移転ハンドラ・モジュール２００４、計画サービス・モジュール２００６、ブリッジ・サービス・モジュール２００８、価格決定及び流動性モジュール２０１０、独立取引台帳モジュール２０１２、及びアウト・オブ・バンド移転／補充モジュール２０１４から成る。アーキテクチャ２０００の各モジュールは、必要であればネットワーク化されたコンピューティング環境を通じて他と通信することができる。
FIG. 2 schematically illustrates a computer architecture according to the disclosed implementations for accomplishing the method of FIG. 1 and other transformation transfers.
本明細書において説明されるモジュールは、単一のコンピュータ処理装置又は複数のコンピュータ処理装置内でコンピュータ実行可能コードとして実装することができる。モジュールのうちの１つ又は複数は、分散アーキテクチャとして他のモジュールから遠隔に実装されてもよい。別のモジュールによって提供される機能性の以下の説明は、説明を目的としたものであり、限定的であることを意図されていないが、モジュールのいずれも説明されるものより多い機能性、又は少ない機能性を提供してもよいからである。例えば、モジュールのうちの１つ又は複数は、取り除いてもよく、その機能性の一部又はすべては、モジュールのうちの他のものによって提供されてもよい。 The modules described herein can be implemented as computer-executable code within a single computing device or within multiple computing devices. One or more of the modules may be implemented remotely from other modules in a distributed architecture. The following description of functionality provided by separate modules is for illustrative purposes and is not intended to be limiting, although any of the modules may have more functionality than described, or Because it may provide less functionality. For example, one or more of the modules may be removed and some or all of its functionality may be provided by others of the modules.
上述のように、ネットワーク間（クロス台帳）取引などの変形取引の自動化された実行は、価値の移転など、提示されるクロス台帳取引の詳細を指定する取引データ構造を受信したことに応じて、達成される。データ構造は、取引詳細を含むことができ（例えば、ソース、宛先、金額、通貨）、移転を開始する権限を持つパーティにより作成することができる。例えば、取引データ構造は、（ＴｒａｎｓａｃｔｉｏｎＴｙｐｅ＝Ｔｒａｎｓｆｅｒ，ＴｒａｎｓａｃｔｉｏｎＣｕｒｒｅｎｃｙ＝Ｅｔｈｅｒ，Ｓｏｕｒｃｅ＝［ｗａｌｌｅｔ １ ａｄｄｒｅｓｓ］，Ｄｅｓｔｉｎａｔｉｏｎ＝［ｗａｌｌｅｔ ２ ａｄｄｒｅｓｓ］）であってもよい。
As noted above, automated execution of a variant transaction, such as a network-to-network (cross-ledger) transaction, responds to receiving a transaction data structure that specifies details of the cross-ledger transaction to be presented, such as the transfer of value. achieved. The data structure can contain transaction details (eg, source, destination, amount, currency) and can be created by the party authorized to initiate the transfer. For example, a transaction data structure may be (TransactionType=Transfer, TransactionCurrency=Ether, Source=[
取引サービス・バス・モジュール２００２は、取引データ構造を解析して、グラフに基づいて、指定された取引を実行するために複数のネットワークを巡回するための１つ又は複数の存在可能な経路（予想される価格、手数料、及び取引回数を含む）を決定する。経路決定は、ルート計画サービス・モジュール２００６によって決定されたネットワークのモデルに基づいて行われ（以下で詳細に説明されるやり方で）、複数のサブ取引から構成される取引チェーンを含み、各サブ取引はソース及び宛先を有する。経路上で資産変形が必要とされる場合、価格決定及び流動性モジュール２０１０は、ブリッジ・メタデータに基づいてブリッジ巡回に必要とされるソース資産と宛先資産との比率を指定する（以下で説明する）。チェーン化移転ハンドラ・モジュール２００４は、ネットワーク移転、確認、及びブリッジ巡回（以下で説明されるブリッジ・サービス・モジュール２００８によって指定される通り）のシーケンスとしてサブ取引（プライバシーを保護するよう所望される場合、ゼロ知識証明を用いて）を実行し、最終的に指定された変形取引の価値移転に作用する。アウト・オブ・バンド移転モジュール２０１４を使用して、非ネットワーク（手作業の、又は非金融商品の）移転を含むことができる。アウト・オブ・バンド移転モジュール２０１４を使用して、必要であれば、サブ取引における流動性の消費に基づいて口座リソースをリバランスすることができる。取引記録は、独立取引台帳モジュール２０１２によって記録することができる。開示される実装形態は、米国特許出願公開第２０１９０１６４１５１（Ａ１）号に記載されるコンプライアンス・フレームワークを活用して、クロス台帳取引をセーフガードし、異種ネットワーク上でコンプライアンス検証を行うことができる。
The transaction
上述のネットワークのモデルは、ソースと宛先との間で価値の移転のために存在可能な経路を識別するよう、様々なネットワーク（クロス台帳取引に参加することを期待され得る）及びブリッジ・ノードをクロールするマルチエージェント・システムを利用してルート計画サービス・モジュール２００６によって作成される。ネットワーク間トポロジは、ノードのグラフ構造として記憶することができる。ノード属性変数は、以下でさらに詳細に説明するが、特定のネットワークにネイティブな価値単位（トークン）の説明、巡回方法、ブリッジに使用される口座、手数料及び価格決定方法、並びに関連ＡＰＩ及び外部ソースとの通信を目的としたネットワーク・インターフェースを含むことができる。
The network model described above uses various networks (which may be expected to participate in cross-ledger transactions) and bridge nodes to identify possible paths for the transfer of value between sources and destinations. Created by route
図３Ａは、実装形態による、ルート計画サービス・モジュール２００６によって巡回される、ネットワーク間トポロジの単純なグラフ構造３０００の抽象化の概略図である。例えば、ネットワーク３００２はビットコインのブロックチェーンであり得、ネットワーク３００４はイーサリアム・プロトコルのブロックチェーンであり得、及びネットワーク３００６はステラ・プロトコルのブロックチェーンであり得る。図３Ａには、３つの異種ネットワーク（３００２、３００４、及び３００６）が図示されているが、実装形態には、あらゆる数の、又はあらゆるタイプの異種ネットワークを含むことができる。図３Ａでは、各ネットワークが図示されるブリッジ・ノードを有し、各ノードはネットワーク同士の通信を提供するブリッジの一面を表現している。ノードＢは、ＤＬＴネットワーク３００２内のブリッジ・ノードであり、ノードＭは、ＤＬＴネットワーク３００６内のブリッジ・ノードであり、ノードＹは、ＤＬＴネットワーク３００４内のブリッジ・ノードである。各ブリッジ・ノードは、対応するＤＬＴネットワーク内の口座／ウォレットに対応する。ブリッジ・ノードのペアはブリッジである。例えば、ノードＢ及びノードＭは、ＤＬＴネットワーク３００２とＤＬＴネットワーク３００６との間のブリッジを定義する。各ブリッジ・ノードは、上述の属性変数のセットを示す対応するメタデータ・レコードを有する。さらには、ブリッジ特性データは、ブリッジ・メタデータとして記憶される。図３Ａ中、線で結ばれるブリッジ・ノードの各ペア、及び関連するメタデータ（ノード・メタデータ及びブリッジ特性メタデータ）が、ブリッジを定義する。もちろん、グラフ内にはあらゆる数のノード及びブリッジ・ノードがあってもよく（通常、数千）、図３Ａは例示目的のため単純なグラフである。
FIG. 3A is a schematic diagram of an abstraction of a
実例として、メタデータ・レコード３０１０は、ノードＢに関連して記憶され、メタデータ・レコード３０１２は、ノードＭに関連して記憶され、ブリッジ特性メタデータ・レコード３０１４はノードＢとノードＭとの接続を定義するよう記憶される。したがって、ブリッジは、グラフ構造３０００のメタデータ・レコード３０１０、３０１２、及び３０１４（まとめて「ブリッジ・メタデータ」）によって定義される。ブリッジ・メタデータのさらに詳細なスキーマ３１００を、実装形態に従って、図３Ｂに示す。スキーマ３１００は、ウォレット属性３１０２（ノード・メタデータとしてグラフに記憶することができる）、トークン属性３１０４（ノード・メタデータとしてグラフに記憶することができる）、データ型属性３１０６（ブリッジ特性メタデータとしてグラフに記憶することができる）、及びインターフェース３１０８（価格決定モデル及び他のロジックを含み、ブリッジ特性メタデータとしてグラフに記憶することができる）を含む。図３Ａのメタデータ・レコード３０１０、３０１２、及び３０１４は、３つの別個のレコードとして図示されているが、その中のデータは単一のブリッジ・メタデータのレコードに組み合わされてもよく、又はグラフ３０００のアーキテクチャに基づいて追加的なレコードに分けられてもよい。開示される実装形態は、メタデータを指定するために標準的なスキーマを使用する。ブリッジは、異種ネットワーク間の接続経路として機能する。グラフは、取引経路が、クロス台帳取引チェーンにおいて（又は、特定の場合では、以下で議論するように台帳内取引において）ブリッジを配置して使用できるようにする。メタデータ・レコード３０１０、３０１２、及び３０１４は、ブリッジ・ファンクションと関連して以下でさらに詳細に議論する。
Illustratively,
グラフ３０００のデータは、ブリッジ・サービス・モジュール２００８によって記憶され、ルート計画サービス・モジュール２００６によって巡回される。取引サービス・バス・モジュール２００２は、変形取引を成し遂げるために必要とされるサブ取引を含む、最適化された取引ルーティング情報を提供する。ルートを提示されると、ソース口座は、グラフ、並びに取引回数、コンバージョン・レート、及び手数料ロードのうちの１つ又は複数などのユーザ選好に基づいて、チェーン化された取引を開始することができる。チェーン化移転ハンドラ・モジュール２００４は、提案されたサブ取引を含む取引実行を管理して、最終的なデリバリーを通じて適正な移転の実行（又はロールバック）を確実にする。ルート計画及び経路最適化を、以下でより詳細に説明する。
The data for
取引サービス・バス・モジュール２００２は、価値移転の文法独立的なモデル、移転メッセージング規約と関連項目のカタログ、及び様々なネットワークの異質な実装形態を文法独立的なモデルにコンバートするための変換スキーマとして機能する、金融オントロジを実装する。チェーン化移転ハンドラ・モジュール２００４は、提示されたサブ取引を文法独立的な命令からネットワーク特有実装形態に変換する取引サービス・バス・モジュール２００２を介して異質なネットワーク上でサブ取引を実行する。
The transaction
金融オントロジは、金融取引に共通の言語を提供する抽象レイヤである。オントロジは、金融システムで遭遇する、サービス、ファンクション、及びオブジェクト向けのインターフェースを定義する。オントロジは、個々のサービス・プロバイダの実装形態同士の様々な違いを分離する相互運用性レイヤを提供し、個々のコンポーネントが緩く連結される柔軟なモジュール型システムを用意する。オントロジにより、個々の金融サービスが共に機能するように設計されていなくても、個々のサービスをより複雑な金融システムにコンポーズすることが可能となる。支払いのチェーン化は、あらゆる移転ネットワークをあらゆる他の移転ネットワークに接続するように設計されているため、共通のサービス定義は、相互接続しているＮシステムの複雑性をＮ階乗（Ｎ！）からＮに減ずる。したがって、オントロジは、大きな集積物を扱いやすくするように設計される。本技術の標準的なファンクション及びインターフェースを、以下で議論する。 A financial ontology is an abstraction layer that provides a common language for financial transactions. Ontologies define interfaces for services, functions, and objects encountered in financial systems. Ontologies provide an interoperability layer that separates the various differences between individual service provider implementations, providing a flexible, modular system in which individual components are loosely coupled. Ontologies allow individual financial services to be composed into more complex financial systems, even though they were not designed to work together. Since payment chaining is designed to connect any transfer network to any other transfer network, a common service definition reduces the complexity of interconnecting N systems to N factorial (N!) to N. Ontologies are therefore designed to make large collections manageable. The standard functions and interfaces of this technology are discussed below.
しかしながら、扱いやすさのために基礎となるプロバイダごとに共通の抽象化を開発することは、個々のプロバイダの表現度（つまり、一意のプロバイダによって公開され得る特殊な特徴）を低減させる可能性がある。開示されるフレームワークは、表現度が扱いやすさのために失われないことを保証する２つのメカニズムを有する。まず、「ラッパー」は、具体的なプロバイダ／ネットワークに一意な、又はプロバイダ／ネットワークのサブクラスに一意な特徴を公開することができる。この場合、依存的なクライアントは、実装形態に特有なラッパーで直接的にインターフェースして、これらの一意な特徴を活用してもよい。しかしながら、このことは、クライアントとサービス実装形態との間に直接的な依存性を作り、この依存性はクライアントをサービス実装形態に密に連結してモジュール性及びスケーラビリティを限定する。実装者は、一意な機能性を得るためのトレードオフが、具体的なプロバイダ／ネットワークへの依存度を高める価値があるかどうかを判断することができる。追加的に、オントロジは、ローカルで定義された仕様の追加的なデータを汎用インターフェースで搬送できるようにするデータ構造を含む。中心部のデータ構造は、パーサーがデータを検査し、フォーマットが認識された場合はそれを解析できるようにする、型及びデータ情報を含む仕様を有するＯｔｈｅｒＤａｔａフィールドを含む。この構造は、システムのすべての部分で使用される構造において追加的なデータを搬送できるよう要求される場合がある、システム同士のポイント・ツー・ポイントの通信を可能にする。結果として、チェーン化移転ハンドラに見られるようなファンクションを協調させることは、具体的な移転プロバイダの一意な特徴を犠牲にすることなく、ファンクションをグローバル範囲で実施することができる。 However, developing a common abstraction for each underlying provider for ease of use can reduce the expressivity of individual providers (i.e., the special features that can be exposed by unique providers). be. The disclosed framework has two mechanisms to ensure that expressivity is not lost for manageability. First, a "wrapper" can expose features that are unique to a particular provider/network, or to subclasses of providers/networks. In this case, dependent clients may interface directly with implementation-specific wrappers to take advantage of these unique features. However, this creates a direct dependency between the client and the service implementation, which tightly couples the client to the service implementation and limits modularity and scalability. Implementors can decide if the trade-offs for unique functionality are worth more dependence on a particular provider/network. Additionally, the ontology contains data structures that allow additional data for locally defined specifications to be carried in the generic interface. The central data structure contains an OtherData field with a specification containing type and data information that allows the parser to inspect the data and parse it if the format is recognized. This structure enables point-to-point communication between systems that may be required to carry additional data in structures used by all parts of the system. As a result, coordinating functions such as found in chained transfer handlers allows the functions to be implemented with global scope without sacrificing the unique characteristics of a specific transfer provider.
上述のように、ブリッジ・サーバ・モジュール２００８は、論理インターフェースであるブリッジを様々なＤＬＴネットワーク間に設け、それらの間で取引と価値を中継する。ブリッジは、異種の資産及び価値の単位を表現するトークンのタイプを受け入れることができる。ブリッジ・サーバ・モジュール２００８は、ブリッジを実装して、モデル及びノード・メタデータに基づいて論理的なクロス台帳接続を作成する。本質的に、ブリッジは、移転挙動を定義するデータ構造である。ブリッジ・サーバ・モジュール２００８は、メタデータ・レコード３０１０、３０１２、及び３０１４を読み取り（図３Ａ）、ブリッジ型を判定し、Ｖｏｓｔｒｏウォレットを割り振り、Ｎｏｓｔｒｏウォレットを割り振り、手数料を識別し、価格決定モデルを決定し、必要であればｏｕｔ－ｏｆ－ｂａｎｄ補充を割り振り、以下で説明するやり方で、変形ロジックを識別して付加する。ブリッジ・オペレータ、つまりブリッジでまたがっているネットワーク両方を介して動作する適当なパーミッションを有するエンティティ又はシステム処理は、メタデータ・レコード３０１４で示されることが可能である。ブリッジ口座は、ソース・ネットワークと宛先ネットワークとをリンクするよう作成されるか、又は割り振られる。ブリッジ内のソース口座は保管口座であることが多く、２ｗａｙのブリッジ・サポート用にアクティブであるべきであり、また宛先はアクティブであるべきであり、特定のタイプの移転用にリンクされた発行者を必要とする場合がある。
As described above, the
ブリッジ・サービス・モジュール２００８によって、価格発見（ペッグ、フロート、為替）、会計（変換、証書）及び移転（イン・バンド、アウト・オブ・バンド）において、ある範囲のオプションを伴って、様々なクラスのブリッジを作成して記憶することができる。これらのクラスは、共通の相互接続パターンを提供して、ネットワーク間での価値の移動を実行及び記録するための、繰返し可能な処理を容易にする。含まれるブリッジ・クラスは、メタデータ・モデルによって指定される通りに、価格発見、会計及び移転などの分野のオプションからコンポーズされる（例えば、イン・バンドとアウト・オブ・バンドの組み合わせ）。異種ネットワークは、ブリッジを使用して一緒に接続されるため、ブリッジは、ネットワーク間での価値のフローを容易にしており、メタデータによって指定されるように、サービスのための料金を抽出することができる。ブリッジは、ネットワーク間又は価値の単位間に接続を作成し、これは以下を制御することによって異なる送信ネットワーク全体で価値移転を受け取って中継する：
・送信モード：担保契約（参照による）、決済（価値による）、リンケージ、又は売買－変形（資産の変更、分割）
・価格決定：為替、アルゴリズム的、ペッギング
・シンクロニシティ：同期又は非同期（ヘッジ＆リスク管理を伴う）
・手数料、資本供給ロジスティックス、及び流動性管理
The
Mode of transmission: collateral agreement (by reference), settlement (by value), linkage, or trading-transformation (asset modification, division)
Pricing: currency, algorithmic, pegging Synchronicity: synchronous or asynchronous (with hedging & risk management)
・Commissions, capital supply logistics, and liquidity management
各ブリッジは、インバウンド口座及びアウトバウンド口座を含む（例えば、図３ＡのノードＢ及びノードＭに、それぞれ関連付けられる）。口座は、取引チェーンの一部として運用される「システム」パーミッションを有するブリッジ・オペレータによって所有される可能性がある。これらの口座は、ブリッジの作成の間に、ブリッジ・メタデータ中の設定パラメータとして提供される。インバウンド口座及びアウトバウンド口座によってサポートされる価値単位は、ブリッジによってサポートされる接続を定義する。サポートされる接続は、移転ルーティングに必要である。取引がビットコイン台帳（ＤＬＴネットワーク３００２）から始まり、ステラ・ネットワーク（ＤＬＴネットワーク３００６）にクロスする図３Ａの実例を使用して、ブリッジのインバウンド（Ｖｏｓｔｒｏ）口座（例えば、図３ＡのＢ）は、取引チェーンにおける最初のサブ支払いの宛先口座となる。この口座は、「Ａｃｔｉｖｅ」な口座、つまり「ロールバック」機能が必要とされない限り、動作するのに権限を含む口座である必要はない。ブリッジのアウトバウンド（Ｎｏｓｔｒｏ）口座（例えば、図３ＡのＭ）は、価値をチェーン又は最終宛先に送るために使用される。Ｎｏｓｔｒｏ口座は、Ａｃｔｉｖｅであるべきで、このことは処理スレッドが口座から取引を開始する権限を有するべきであることを意味している。ダーク・プール取引、つまり事前位置付けされた価値での取引では、チェーン化取引を開始することに先立って、インバウンドのブリッジ口座に十分な価値が存在しなければならない。ブリッジは、ブリッジ・サーバ・モジュール２００８から、ルート計画及び支払い実行のためにチェーン化移転ハンドラ・モジュールによって使用されるリストにロードすることができる。ブリッジを実行するために使用されるクラスは、設定によって決定される。
Each bridge includes an inbound account and an outbound account (eg, associated with Node B and Node M in FIG. 3A, respectively). An account may be owned by a bridge operator with "system" permission to operate as part of the trading chain. These accounts are provided as configuration parameters in the bridge metadata during bridge creation. The units of value supported by the inbound and outbound accounts define the connections supported by the bridge. A supported connection is required for transfer routing. Using the illustration of FIG. 3A where the transaction originates from the Bitcoin ledger (DLT network 3002) and crosses to the Stellar network (DLT network 3006), the bridge's inbound (Vostro) account (e.g., B in FIG. 3A) is It will be the destination account for the first sub-payment in the transaction chain. This account does not need to be an "Active" account, ie an account containing permissions to operate, unless the "Rollback" feature is required. The bridge's outbound (Nostro) account (eg, M in FIG. 3A) is used to send value to the chain or final destination. The Nostro account should be Active, which means that the processing thread should have permission to initiate transactions from the account. Dark pool trading, or trading at pre-positioned value, requires that sufficient value exists in the inbound bridge account prior to initiating the chained trade. Bridges can be loaded from the
所望の宛先価値単位の場合、１つのウォレット型から別のウォレットへの可能なルートのリストは、利用可能なブリッジによって使用されるインバウンド及びアウトバウンドのウォレットについて、ブリッジ・メタデータで示される、サポートされるトークンを評価することによって決定することができる。ルート計画サービス・モジュール２００６は、ソースから宛先への経路をマッピングする際、このリストを使用する。例えば、図３のグラフ３０００は、ＤＬＴネットワーク３００２とＤＬＴネットワーク３００６との間の２つの可能なルートを示している。第１のルートは２で示され、第２のルートは１と３との組み合わせで示されている。
For the desired destination unit of value, a list of possible routes from one wallet type to another is supported, indicated in the bridge metadata for inbound and outbound wallets used by the available bridges. can be determined by evaluating the token The route
ブリッジ設定の詳細に加え、ブリッジ・クラスの動作可能な属性は、依存性投入の詳細により決定され、ブリッジ・メタデータとして記憶することができる。開示される実装形態におけるブリッジ動作のバリエーションは、メタデータで定義される６つの属性に分けることができる：送信モデル、価格決定モデル、補充モデル、シーケンス、方向、及び手数料。送信モデルは、ブリッジ・ウォレットを介して、どのように台帳を一緒にリンクするかを定義している。５つのタイプの送信モデルを実装することができる：担保契約（Ｄｅｐｏｓｉｔ）、決済（Ｗｉｔｈｄｒａｗａｌ）、及び移転（ＮｏｓｔｒｏＶｏｓｔｒｏ）、Ｔｒａｎｓｍｕｔｅ（台帳変化）、及び変形。使用されるモデルは、所望の移転モード、発行／買戻し動作を実施するブリッジ・オペレータの能力、保管ウォレットの利用可能性、及び他のビジネス要件に基づいて決定することができる。 In addition to bridge configuration details, the operational attributes of a bridge class are determined by dependency injection details and can be stored as bridge metadata. The variations of bridging operations in the disclosed implementation can be divided into six attributes defined in metadata: transmission model, pricing model, replenishment model, sequence, direction, and fee. The transmission model defines how ledgers are linked together via bridge wallets. Five types of transmission models can be implemented: Collateral Contract (Deposit), Withdrawal and Transfer (NostroVostro), Transmute (ledger change), and Transformation. The model used can be determined based on the desired transfer mode, the bridge operator's ability to perform issue/repurchase operations, custodial wallet availability, and other business requirements.
価格決定モデルは、ブリッジによって受け取られるソース・トークンごとに送られる宛先台帳トークンの数の比率を定義している。価格決定モデル実装形態は、Ｌｉｎｋ（１：１）、Ｐｅｇ（固定比率）、Ａｌｇｏｒｉｔｈｍｉｃ（依存性投入のプラグイン）、又はＥｘｔｅｒｎａｌ（取引所などのサード・パーティのソースから得る）を含む。補充モデルは、過剰な不均衡フローが起こりリソースを再配置しなければならなくなった時に、アウトバウンドのウォレットを再補給するために使用されるメカニズムを定義する。補充モデルの実装形態は、次を含む：Ｎｏｎｅ、Ｍａｎｕａｌ、Ｔｒａｎｓｆｅｒ、及びＥｘｃｈａｎｇｅ。ブリッジは、シーケンス（Ｓｅｒｉｅｓ／Ｐａｒａｌｌｅｌ）及び方向（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ／Ｂｉｄｉｒｅｃｔｉｏｎａｌ）を有し、それらがどのように実行することができるかを示している。 The pricing model defines the ratio of the number of destination ledger tokens sent per source token received by the bridge. Pricing model implementations include Link (1:1), Peg (fixed ratio), Algorithmic (plugins for dependency injection), or External (obtained from third party sources such as exchanges). The replenishment model defines the mechanism used to replenish outbound wallets when excessive imbalanced flows occur and resources must be reallocated. Replenishment model implementations include: None, Manual, Transfer, and Exchange. Bridges have sequences (Series/Parallel) and directions (Unidirectional/Bidirectional) to show how they can be implemented.
マルチ台帳の発行の場合では、ブリッジは、クロス台帳変異を実装することができる。これは、所有権の公的な記録が移転用に使用されている１つの台帳ではなく別個の台帳にある場合、又は公的な記録が影響を受ける台帳の所有権の記録の合計である場合に使用することができる。変異により、トークンが複数の台帳上で発行できるようになる、及び／又は１つの台帳上で発行されたトークンが別の台帳に「フロー」することができる手段を提供する。トークンが台帳から台帳へ移動すると、流通におけるトークンの総数は一定なままであるが、所有権の記録は台帳から台帳へと移動する。 In the case of multi-ledger issuance, the bridge can implement cross-ledger mutation. This may be the case if the public record of ownership is in a separate ledger rather than the one used for the transfer, or if the public record is the sum of the ownership records of the affected ledgers. can be used for Mutations allow tokens to be issued on multiple ledgers and/or provide a means by which tokens issued on one ledger can "flow" to another ledger. As tokens move from ledger to ledger, the total number of tokens in circulation remains constant, but the ownership record moves from ledger to ledger.
例えば、台帳から出て行くファンドは、ソース台帳ベース・ウォレットに送られる。この移転はまた、トークンを移動させずにトークンを保留するエスクロー取引であってもよい。等価な数のトークンが、発行者（ウォレット、口座、又はスマート・コントラクト）から宛先台帳上の流通に、又はＣｏｌｄウォレットからプロバイダＢ上のアウトバウンド・ウォレットに、宛先へのデリバリー用に発行される。デリバリーに成功すると、ソース台帳で呼び出されたＩＩｓｓｕｅｒ．Ｄｅｓｔｒｏｙファンクションが流通からトークンを除去する。 For example, funds leaving the ledger are sent to the source ledger-based wallet. This transfer may also be an escrow transaction that holds tokens without moving them. An equivalent number of tokens are issued from the issuer (wallet, account, or smart contract) to circulation on the destination ledger, or from the Cold wallet to an outbound wallet on provider B, for delivery to the destination. IIssuer.Called on the source ledger upon successful delivery. A Destroy function removes a token from circulation.
クロス台帳変異を達成するためのサブ取引のチェーンの実例、つまり別の破壊に対応する１つの価値の単位の作成を、図４のフロー・チャートに図示する。変異取引の実例は、有益な所有権を表現する株式の、１つの台帳から別の台帳への移動である。４００２において、プロバイダＡを使用して価値がソース・ウォレットからベース（エスクロー）ウォレットに送られる。このウォレットは、ブリッジ・インバウンド・ウォレットである。４００４において、トークンは、プロバイダＢ発行者ウォレットから発行され、プロバイダＢのベース・ウォレットに送られる（ブリッジ属性に基づくブリッジ・アウトバウンド・ウォレット）。４００６において、プロバイダＢのベース・ウォレットは価値をプロバイダＢの宛先ウォレットに送る。４００８において、取引が完了すると、プロバイダＡのベース・ウォレットから等価な数のトークンが破壊される。この処理は、チェーン化移転ハンドラ・モジュール２００４が、ソース台帳及び宛先台帳上の取引を検出して属性付けるメカニズム、並びにプロバイダＢ上でトークンを作成して、プロバイダＡ上のベース・ウォレットからトークンをバーン（破壊）するメカニズムを有していると仮定していることに留意されたい。これらの権限へのアクセスは、ブリッジ・メタデータによって示すことができる。また、発行者ウォレットを通じて直接トークンを発行してバーンすることによって、ステップ４００４から４００８をスキップすることが可能である。
An example of a chain of sub-transactions to achieve cross-ledger mutation, the creation of one unit of value corresponding to another disruption, is illustrated in the flow chart of FIG. An example of a mutational transaction is the transfer of shares representing beneficial ownership from one ledger to another. At 4002, value is transferred from the source wallet to the base (escrow) wallet using Provider A. This wallet is a bridge inbound wallet. At 4004, a token is issued from the Provider B issuer wallet and sent to Provider B's base wallet (bridge outbound wallet based on bridge attributes). At 4006, Provider B's base wallet sends value to Provider B's destination wallet. At 4008, an equivalent number of tokens are destroyed from Provider A's base wallet upon completion of the transaction. This process involves the chained
場合によっては、トークンに表現される権利をある形式から別の形式にコンバートすることが望ましい場合がある。例えば、コンバーチブル・ノートで表現されるローン権利をエクイティ・ポジションにコンバートすることが望ましい場合がある。この場合、前の変異ファンクションを使用して、固定比率変形（例えば、１株負債＝１株出資、又は１０株負債＝１株出資）を使用することができる。しかしながら、共通の株式における権利を、様々に作用する別個のトークンに分割することが有用な場合があり、一方は投票権利を表現し、他方は収入又はエクイティ売り上げの有益な所有権を表現する。この場合、カスタムの取引変形ブリッジが要求される。インバウンドのウォレットに運ばれるトークンのそれぞれのタイプに対して、２つ以上のタイプの株式が生成され、宛先に運ばれてもよい。Ｔｒａｎｓｆｏｒｍ取引の基本的なシーケンスは、Ｔｒａｎｓｍｕｔｅ取引と同じであるが、ブリッジは、アウトバウンド取引に対して２つ以上のタイプの金融商品を発行するための命令を実行しなければならず、各金融商品を所望の宛先ウォレットに運ばなければならない。反対取引は、権利を新しい複合権利に組み合わせるために行われてもよい（例えば、投票と有益な所有権とを共通株式に組み合わせる）。変形ブリッジは、台帳内ブリッジであることができる。つまり、複数のネットワークにまたがっている必要がない。 In some cases, it may be desirable to convert the rights expressed in tokens from one form to another. For example, it may be desirable to convert loan rights represented in convertible notes into an equity position. In this case, the previous mutation function can be used to use fixed ratio transformations (eg, 1 Debt = 1 Contribution, or 10 Debt = 1 Contribution). However, it may be useful to divide rights in a common stock into separate tokens that act differently, one representing voting rights and the other representing beneficial ownership of income or equity sales. In this case, a custom transaction transformation bridge is required. For each type of token delivered to the inbound wallet, more than one type of equity may be created and delivered to the destination. The basic sequence of a Transform transaction is the same as a Transmute transaction, but the bridge must execute instructions to issue two or more types of financial instruments for outbound transactions, each instrument must be carried to the desired destination wallet. A counter-deal may be made to combine rights into a new composite right (eg, combine voting and beneficial ownership into common stock). The transformation bridge can be an intra-ledger bridge. In other words, there is no need to span multiple networks.
交換ブリッジは、Ｐｒｉｃｅ Ｄｉｓｃｏｖｅｒｙ又はファンドのＭｏｖｅｍｅｎｔが、インライン又はアウト・オブ・バンド（ＯＯＢ：Ｏｕｔ Ｏｆ Ｂａｎｄ）で交換を伴う特殊な種類のブリッジである。この場合、ソース取引に要求されるファンド額は、ある交換に対する等価な売買の現在のＴｏｔａｌ Ｖｏｌｕｍｅ Ｐｒｉｃｅ（オーダー・ブックの全体）に依存する。次いで、ファンドは、バッチでインライン補充又はアウト・オブ・バンド補充される。場合によっては、インバウンド移転は、インライン取引用の取引所口座向けであってもよい。この場合、Ｎｏｓｔｒｏ口座は、やはり取引所にある。Ｎｏｓｔｒｏ口座は、取引所がプロバイダ・ネットワークを介して利用可能ではないが異なる通貨がサポートされている場合、Ｖｏｓｔｒｏ口座と同一のプロバイダを使用してもよい。図１０及び図１１に関して、他のタイプのブリッジを以下で議論する。 An exchange bridge is a special kind of bridge where Price Discovery or Fund Movement involves an exchange either inline or out of band (OOB). In this case, the fund amount required for the source trade depends on the current Total Volume Price (entire order book) of equivalent trades on an exchange. The funds are then replenished in-line or out-of-band in batches. In some cases, inbound transfers may be for exchange accounts for inline trading. In this case, the Nostro account is still on the exchange. A Nostro account may use the same provider as a Vostro account if the exchange is not available through the provider network but supports different currencies. Other types of bridges are discussed below with respect to FIGS.
開示される実装形態は、「ＩｎｆｉｎＸｃｈａｎｇｅ（商標）」としても知られる、インターフェースとＤＬＴのデータ構造取引サービス・バスとをマッピングしてサービングするライブラリを含むインターフェース・アーキテクチャ、取引サービス・バス・モジュール２００２、及び従来的な価値移転ネットワーク（例えば、イーサリアム、ＰａｙＰａｌ、ＳＷＩＦＴ（登録商標））、及び価値移転モデルを含む。上述のように、ブリッジによって要求されるインターフェースは、ブリッジ・メタデータにおいて特定される可能性がある。これらのインターフェースは、変換取引に使用される手順を実行するために必要なファンクションを公開する。ＩｎｆｉｎＸｃｈａｎｇｅラッパーは、統合のためにハブ・アンド・スポーク・モデルを実装し、それを通じて、チェーン化移転ハンドラ・モジュール２００４などの依存的なサービスは、ラップされた移転ネットワーク全体で取引を編成するために必要なインターフェースを一度だけ統合する必要がある。
The disclosed implementation includes an interface architecture including a library that maps and serves interfaces to the DLT data structure trading service bus, also known as "InfinXchange™", trading
取引サービス・バス・モジュール２００２は、台帳内取引用の共通インターフェースを提供する抽象レイヤとして実装することができる。ソース台帳又は宛先台帳のいずれかとしてクロス台帳取引に参加するために、取引プロバイダを、ＩｎｆｉｎＸｃｈａｎｇｅラッパー内にラップすることができる。ラッパーは、取引を実行してネットワークのアクティビティに反応するために、基礎となる移転プロバイダと一体化する実行ファイルである。ラッパーは、金融オントロジで定義された通りに共通インターフェースを公開する。これらのインターフェースは、ビジネスと取引プロバイダの具体的な実装形態の詳細からのチェーン化に関連付けられる取引ロジックとを切り離し、取引パターンの広範な再使用を可能にする。
The trading
取引プロバイダ／ネットワークは、実装形態及び統合パターンが広範に変化する。例えば、ブロックチェーン・ネットワークは、ノードと対話するクライアントを必要とする一方で、多くの支払いネットワークはＡＰＩを公開する。ＡＰＩは、ＲＥＳＴ、ＳＯＡＰ、ＲＰＣ、及び他のパターンを使用して実装される。企業会計システムは、統合に特定のパターンを持たないリレーショナル・データベースで実行されることが多い。取引サービス・バス・モジュールのライブラリは、基礎となるサービスと対話するために共通パターンを提供するために、これらのスタイルのうちいずれかで実装される取引プロバイダと統合するよう開発することができる。 Trading providers/networks vary widely in implementation and integration patterns. For example, blockchain networks require clients to interact with nodes, while many payment networks expose APIs. APIs are implemented using REST, SOAP, RPC, and other patterns. Business accounting systems often run on relational databases with no particular pattern of integration. A library of commerce service bus modules can be developed to integrate with commerce providers implemented in any of these styles to provide a common pattern for interacting with the underlying services.
各プロバイダに接続する取引サービス・バス・モジュールのライブラリが、抽象ファクトリ・パターンを使用してチェーン化移転ハンドラ・モジュール２００４に投入されてもよい。抽象ファクトリ・パターンは、共通のテーマを持つ個々のファクトリのグループを、その具象クラスを指定することなくカプセル化するための既知のメカニズムである。例えば、クライアント・ソフトウェアは、抽象ファクトリの具象的な実装形態を作成し、次いでファクトリの一般的なインターフェースを使用してテーマの一部である具象オブジェクトを作成することができる。ファクトリ・パターンは、オブジェクトのセットの実装形態の詳細を、その一般的な使われ方から別個にする。
A library of transaction service bus modules that connect to each provider may be injected into the chained
やはり、接続を定義するインターフェースは金融オントロジにある。プロバイダは初期化されると、サービス・インターフェース用のそのサポート及び呼び出しサービスへのファンクションを公表する。このことは、呼び出しサービスがサービス及び取引プロバイダによってサポートされるメソッドを識別できるようにする。この情報を使用して、呼び出しサービスは、取引タイプをサポートするプロバイダの資格を判断することができる。チェーン化された取引に参加しているあらゆるプロバイダは、ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ抽象化をサポートすべきである。Ｆｉｎａｎｃｅ Ｏｎｔｏｌｏｇｙから頻繁に使用されるサービスの短いリストを、以下で説明する。
・ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ：すべての価値の移転を実行する。ファンクションには以下が含まれる：取引にかかるコストを推定すること、支払いを実行すること、その完了を検証すること、及びソースから支払いのリストを取得すること
・ＩＷａｌｌｅｔＲｅａｄｅｒＳｅｒｖｉｃｅ：口座残高（特定のウォレット・アドレスにおける利用可能な価値の額）を識別し、ウォレットについての詳細を取得するために使用される（例えば、サポート通貨、作成日）
・ＩＷａｌｌｅｔＶａｌｉｄａｔｏｒＳｅｒｖｉｃｅ：所有権を主張するエンティティによる所有権を含め、ウォレットが取引に対して資格があるかどうかを判定する。
ＩＰａｙｍｅｎｔサービス及びＩＩｓｓｕｅｒサービスは、あらゆる支払いシステムの上のレイヤとなり、そのプロバイダを介する移転を実行することができる。すぐ下に見られるのは、インターフェース用の例示的な疑似コード及び関連データ構造である。
• IPaymentService: Performs all value transfers. Functions include: estimating the cost of a transaction, making a payment, verifying its completion, and retrieving a list of payments from a source amount of value available at the address) and used to retrieve details about the wallet (e.g. supported currencies, creation date)
• IWalletValidatorService: Determines whether a wallet is eligible for a transaction, including ownership by the claiming entity.
The IPayment and IIssuer services are layered on top of any payment system and can perform transfers through their providers. Seen immediately below is exemplary pseudo-code for the interface and associated data structures.
複雑なクロス台帳移転に対する取引サービス・バス・モジュール２００２の用途を理解するためには、まず、単純な支払いシステムが取引サービス・バス・モジュール２００２のコンテキストにおいて、どのような働きをするかを探ることが助けとなる。図５は、単純な移転の実例５０００を概略的に図示している。ＵｓｅｒＸ（送る側）が、同一台帳上で、ＵｓｅｒＹ（受け取り側）に価値を送りたがっている（例えば、ＰａｙＰａｌ移転）。まず、送る側は、ファンクション（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｐｒｅｐａｒｅ）、受け取り側（アドレスによって）、及び送られる通貨／金額（通常、受け取り側が受け取ると期待される金額で表される）を指定することによって移転を提案する。システムは、提案された支払いの妥当性をチェックし（手数料／ガス代、ポリシー、受け取り側は有効か、ファンドは十分か、を評価する）、所望のデリバリーを実現するために送らなければならない金額に関する１つ又は複数の選択肢によって応答する（多くのシステムでは、利用可能な選択肢は１つだけである）。ある選択肢について移転約定が受け入れ可能であれば、送り側は、署名された取引（ログイン、シークレット、など）の移転を開始する（ステップ１、ＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔ）。システムは、移転を有効化し（ステップ２、イベントＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）、口座残高を調節する（ソース残高を減少させ、宛先残高を増加させる）ことによって価値を移動しつつ、移転手数料を抽出する（ステップ３）。取引が完了すると、通知が送られる（イベントＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）。新しい残高が、ソース・ウォレットと宛先ウォレットに反映される。
To understand the use of the Transaction
開示される実装形態によるチェーン化された取引は、これらの同じファンクションを使用して、開示される実装形態の新規な要素と組み合わせて開始されてもよい。図６は、開示される実装形態によるチェーン化された取引の実例６０００（指定された順に達成される複数のサブ取引を含む）を概略的に図示している。図６での実例は、図２のアーキテクチャ２０００を使用して取引を達成することができる。チェーン内の個々の台帳移転は、図２のチェーン化移転ハンドラ・モジュール２００４によって管理されるアクティビティを協調することを伴う単純な支払いと一貫性のある方法を使用する。
Chained transactions according to the disclosed implementation may be initiated using these same functions in combination with the novel elements of the disclosed implementation. FIG. 6 schematically illustrates an example chained transaction 6000 (including multiple sub-transactions completed in a specified order) according to the disclosed implementations. The example in FIG. 6 can use the
図６に示されるように、送り側は、ＩｎｆｉｎＸｃｈａｎｇｅインターフェースを使用して移転を提案する（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｐｒｅｐａｒｅ）。この実例では、ユーザＸは、価値をプロバイダＡの口座（例えば、第１のＤＬＴネットワーク）から、プロバイダＢにあるユーザＹの口座（例えば、第２のＤＬＴネットワーク）に移転したいと思っている。ステップ１において、図２のルート計画サービス・モジュール２００６は、ノード・グラフ（図３Ａのノード・グラフ３０００など）を巡回することによって利用可能な経路を探して、ブリッジ・メタデータに基づいて、ソース・ネットワークと宛先ネットワークとの間の存在可能な経路を提供するブリッジを識別し、移転のレッグごとの手数料を取得する。移転を容易にするために利用可能な０から多くの経路があってもよい。（人工知能を含む）様々な技法を使用して、利用可能な選択肢のリストを狭めることができる、又は可能な経路を優先度付けすることができる。経路は、すべての必要なＩｎｆｉｎＸｃｈａｎｇｅインターフェース及びブリッジ・メタデータから導出したビジネス・ロジックを含むことができる。
As shown in Figure 6, the sender proposes a transfer using the InfinXchange interface (IPaymentService.Prepare). In this example, user X wishes to transfer value from provider A's account (eg, the first DLT network) to user Y's account at provider B (eg, the second DLT network). In
送り側、又は自動化されたアルゴリズムは、所望の経路を選択して、所望の移転を開始することができる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔ）。チェーン化移転ハンドラ・モジュール２００４は、取引をシステム取引台帳２０１３（図２）の台帳に書き込み、監査可能性及びシステム障害の結果として回復可能性を保証する。この記録は、ゼロ知識証明技法を使用して不明瞭にして、取引のプライバシーを損なうことなく不変性を実現することができる。チェーン化移転ハンドラ・モジュール２００４はまた、イベント（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）を公表して移転をシグナリングする。チェーン化移転ハンドラ・モジュール２００４は、ユーザの署名権限を伝達して、ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔファンクション（ステップ２）により計画されたルートを使ってソース台帳で子転送を実行し、これには１つ又は複数のブリッジを介する異種ネットワークの巡回を含む。サブ移転の開始の際、この移転は、外部取引台帳内の親取引にリンクされているため、イベントがスローされる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）。ソース・ブリッジ口座への移転が完了すると（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）、イベントがスローされて、移転の完了をマークして、ハンドラが取引の次の部分を開始するようシグナリングする。移転は、ブリッジを介して開始される（ＩＢｒｉｄｇｅＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔ）。ブリッジ移転が完了すると（ＩＢｒｉｄｇｅＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）、チェーン化移転ハンドラ・モジュール２００４は、ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｓｕｂｍｉｔを使用してアウトバウンド台帳上で移転を開始して（ステップ４）、価値を宛先口座又はルートに応じてチェーン内の別のレッグに運ぶ。この取引が開始されると、イベントがスローされる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｉｎｉｔｉａｔｅｄ）。この取引は、独立取引台帳モジュール２０１２の外部取引台帳内の親取引にリンクされている。価値は、宛先口座に運ばれ、ステップ５においてイベントがスローされる（ＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ）。チェーン化シーケンスにおける最後のステップとして、すべての取引の完了をシグナリングするイベントがスローされる。すべてのサブ取引が、システム取引台帳２０１２の台帳に記録される。
The sender, or an automated algorithm, can select the desired route and initiate the desired transfer (IPaymentService.Submit). Chained
代替的には、チェーン化移転は、宛先向けのデリバリー用の命令でブリッジ・ソース口座に価値を運ぶことによって、図６のステップ１及びステップ２をスキップして、外部のシステムから開始することができる。受け取ると、ブリッジ口座はＩＰａｙｍｅｎｔＳｅｒｖｉｃｅ．Ｃｏｍｐｌｅｔｅｄ移転を発行する。チェーン化移転ハンドラ・モジュール２００４は、このイベントを読み取り、正当な支払いルートがあるかどうかを判定する。あるルートが利用可能な場合、ブリッジ・ソース口座においてファンドがエスクローに保有された状態でチェーンが開始される。移転が成功すると、これらのファンドは解放される。移転に失敗すると、ファンドはソースに戻されてもよい。ソース台帳がスマート・コントラクトをサポートしている場合、取引を開始することは、オンチェーンのエスクロー方法を活用して、取引の原子性を保証することができる。
Alternatively, a chained transfer can be initiated from an external system, skipping
図７、図７Ａ及び図７Ｂは、開示される実装形態による、実例の取引チェーン構築処理の概略図である。図示される処理は、図２のアーキテクチャによって達成することができる。取引が取引データ構造内で指定されると、ＩｎｆｉｎＸｃｈａｎｇｅ（商標）ラッパーと組み合わせたルート計画サービス・モジュール２００６は、ネットワーク・ノード全体での最適な送信経路を識別する。この実例では、指定される取引は「ＡＢＣトークンを、ステラＤＬＴシステム上のＵｓｅｒＡノードから、リップルＤＬＴシステム上のユーザＢノードに移転する」である。価格、及び期待されるデリバリー時間などの、すべての利用可能な選択肢のセットは、取引データ構造によって指定することができる。ステップ１において、ルート計画サービス・モジュール２００６は、すべての可能なルート及び利用可能なブリッジを評価して、すべてのノードのグラフ及びブリッジを巡回することによって移転を実行する。可能な取引経路が、関連ネットワークについてのブリッジ・メタデータを読み取ることによって分析され、ソース台帳（この実例ではステラ）と宛先台帳（この実例ではリップル）のプロバイダとトークンとの間のすべての接続を表現するブリッジ・グラフを構築する。ブリッジ・グラフは、識別された接続のブリッジのすべての関連ブリッジ・メタデータを含むことができる。
7, 7A, and 7B are schematic diagrams of an example transaction chain building process, according to disclosed implementations. The illustrated processing can be accomplished by the architecture of FIG. When a transaction is specified in the transaction data structure, the route
ルート計画サービス・モジュール２００６は、幅優先探索（ＢＦＳ：Ｂｒｅａｄｔｈ Ｆｉｒｓｔ Ｓｅａｒｃｈ）アルゴリズム（選択されたノードからレイヤ方向にグラフを巡回する、既知のグラフ巡回アルゴリズム）を適用してすべての経路を見つけ、ＢｒｉｄｇｅＮｏｄｅＣｈａｉｎのリスト、つまり取引を達成するための可能な経路のリストを返すことができる。この実例では、２つの可能な経路が識別されている（ＴｒａｎｓａｃｔｉｏｎＣｈａｉｎ１、及びＴｒａｎｓａｃｔｉｏｎＣｈａｉｎ２）。ステップ２において、ルート計画サービス・モジュール２００６は、取引要件及び条件のリストに基づいて、最終的な取引経路を構築する。例えば、チェーンが、１ＡＢＣトークンを宛先ウォレットに運ばなければならない場合、且つ関連する送信手数料の合計が０．１ＡＢＣトークンである場合、ソースは１．１ＡＢＣトークンを移転しなければならない。最終的な取引経路は、取引手数料、取引確認時間などの、様々な選好及び属性を考慮するように構築することができる。
The Route
図３Ａを使用して、経路の選択及び取引チェーンをより良好に図示することができる。図３Ａでは、Ｇｒａｐｈ３０００は、３つのＤＬＴネットワークを有しており、それぞれが少なくとも１つのノードを有していることを思い出されたい。取引は、あるネットワーク内で発生することができる（例えば、Ａ－＞Ｂ、Ｙ－＞Ｚ）。しかしながら、ネットワーク間をクロスするため、例えば異なるＤＬＴネットワークにあるノード間で取引をするためには、ブリッジを使用しなければならない。ブリッジがないと、例えばノードＡとノードＺとの間での移転用の経路は存在しない。ネットワーク同士をリンクするために、ブリッジ口座Ｂ、Ｍ、及びＹが作成される。次いでブリッジは、これらの口座をリンクするためにセットアップされる。ブリッジ１を使用して、例えばＡとＺとの間のルートが存在する（Ａ－＞Ｂ～１～Ｙ－＞Ｚ）。第２のルートは、サード・パーティのネットワーク（Ａ－＞Ｂ～２～Ｍ～３～Ｙ－＞Ｚ）を通じてリンクすることによって存在する。ルート計画サービス・モジュール２００６のルート・プランナは、ネットワーク・グラフを巡回して、潜在的なルートとして、これらのルートを生成する。ユーザ（又は自動化されたサービス）は、選好及び他の属性に基づいて、識別された選択肢の中から最良の移転経路を決定することができる。
FIG. 3A can be used to better illustrate path selection and transaction chains. Recall that in FIG. 3A,
図７、図７Ａ及び図７Ｂに戻ると、１つのネットワーク又は台帳から別のネットワーク又は台帳に価値を移動するための能力には、多くの潜在的な経路及びメカニズムが伴う場合がある、又は存在可能な経路がまったくない場合がある。ユーザが支払いデリバリーをリクエストすると、すべての利用可能な選択肢のセット、それらの価格、及び期待されるデリバリー時間が、実質的にリアルタイムに生成されなければならない。図７Ａのステップ２において、ルート計画サービス・モジュール２００４は、ソース・ノードから宛先ノードへの経路を提供することができるすべての利用可能なブリッジを評価することによって、すべての可能なルートを集める。
Returning to Figures 7, 7A and 7B, the ability to move value from one network or ledger to another may involve or exist many potential paths and mechanisms. There may be no possible routes at all. When a user requests payment delivery, the set of all available options, their prices, and expected delivery times should be generated substantially in real time. In
取引サービス・バス
すべての抽象経路が計算されてしまうと、ルート計画サービス・モジュール２００６は、抽象経路に基づいて１つ又は複数の取引チェーンを構築する。チェーンを構築するためには、宛先から構築を開始する（デフォルト）、又はソースから構築するという、少なくとも２つの方法がある。宛先からソースに向けて開始する場合、ルート計画サービス・モジュール２００６は、宛先条件を固定ポイントとして始める。ソース・ノードを固定パラメータとして開始する場合、ルート計画サービス・モジュール２００６は、移転が１ＡＢＣで始まった場合に宛先ノードが受け取ることになる価値を決定する。ルート計画サービス・モジュール２００６は、ソースから取引リンクを構築し始め、経路を通じてすべての手数料及び交換を累積する。例えば、すべての手数料が０．１ＡＢＣトークンである場合、受け取り側は最終的に０．９ＡＢＣトークンを得ることになる。次いで、ルート計画サービス・モジュール２００６は、例えば以下の規則に基づいて、現実のチェーンへの抽象経路を構築する：
次いで、ルート計画サービス・モジュール２００６は、すべての経路チェーンを選択して、重複リンクを取り除くことによって、これらを単一の最終取引チェーンにマージする。図７、図７Ａ及び図７Ｂに示されるように、取引チェーンは、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ１、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ２、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ３、ＴｒａｎｓａｃｔｉｏｎＬｉｎｋ４、及びＴｒａｎｓａｃｔｉｏｎＬｉｎｋ５を含む。図７のステップ３において、ＴｒａｎｓａｃｔｉｏｎＶａｌｉｄａｔｉｏｎＳｅｒｖｉｃｅは、例えば経路中の各リンクのソース・ウォレットが取引をサブミットするのに十分な残高を有しているかどうかをチェックすることによって、及び／又は自己参照チェーン、つまり同一ノードが１つのチェーン内で２回以上発生するチェーンをチェックすることによって、取引経路を実行することができることを検証する。（ポリシー・エンジンは、それぞれの移転ノードにおいて、企業コンプライアンスを検証することができる。例えば、米国特許出願公開第２０１９０１６４１５１（Ａ１）号で説明されるシステム及び方法は、企業コンプライアンスを検証するために使用することができる。）それぞれ存在可能な取引チェーンは、手数料及び交換が関与する可能性があり、推定デリバリー時間を有する。提案される移転の価格及びデリバリー時間は、ユーザに提示するために、移転アクションのユーザ承認に先立って計算することができる。
Route
サブ取引のチェーンにおける移転の間、ネットワーク障害が発生する可能性がある、又は移転が完了する前にキャンセルされる（許可されていれば）可能性がある。この場合、ロールバックが必要となる。中間的な手数料がチャージされる、又は交換が行われる事例では、価値の損失なく取引を反対にすることができない場合がある。このような事例では、ユーザは、移転を完了、ロールバックに進めるために移転チェーンを再開始する選択を行使すること、又はその現在の状態の価値を請求することにより取引を見捨てることができる。図８の８００２に、（所望の移転取引を達成するための）４つのサブ取引の正常なチェーンが図示されている。４つすべてのサブ取引（８００２ａ、８００２ｂ、８００２ｃ、及び８００２ｄ）が正常である。 During transfers in the chain of sub-transactions, network failures may occur, or transfers may be canceled (if permitted) before completion. In this case a rollback is required. In cases where intermediate fees are charged or exchanges are made, it may not be possible to reverse the transaction without loss of value. In such cases, the user can forsake the transaction by exercising the option to restart the transfer chain to proceed with the transfer complete, rollback, or by claiming the value of its current state. A successful chain of four sub-transactions (to achieve the desired transfer transaction) is illustrated at 8002 in FIG. All four subtransactions (8002a, 8002b, 8002c, and 8002d) are successful.
しかしながら、ブリッジの構成によっては、取引が失敗すると、システムは、価値を運ぶよう自動的に再開始を行ってもよいか、又は停止してユーザ入力を待機してもよい。図８の８００４は、サブ取引８００４ｄが失敗したチェーン化された取引を図示している。設定によっては、失敗すると、チェーンは自動的にロールバック取引を開始する場合がある。ロールバック取引は、ルート内で使用される各ブリッジが、両方向への取引をサポート可能な２ｗａｙブリッジである場合にのみ可能である。図８の８００６は、ロールバック取引を図示している。８００６において、サブ取引８００６ｄは失敗しており、このすべてのサブ取引８００６ａ、８００６ｂ、及び８００６ｃは、これらのサブ取引のそれぞれで反対サブ取引を達成することによって「リバース」される。さらには、８００８及び８０１０において示されるように、取引は途中でキャンセルされる可能性がある。取引８００８では、サブ取引８００８ｂは実行の前にキャンセルされており、そのためサブ取引８００８ａがリバースされている。代替的に、８０１０において、サブ取引８０１０ｂが実行の後にキャンセルされており、サブ取引９０１０ａ及び８０１０ｂの両方がリバースされる。代替的に、取引イニシエータが中間的な台帳を介して価値を受け取る手段を有している場合、８０１２において示されるように、価値は停止した取引から直接請求されてもよい。反対取引を含め、すべてのサブ取引は、システム取引台帳モジュール２０１２に記録される。図９Ａ、図９Ｂ及び図９Ｃは、組み合わせて、チェーン化移転の状態図９０００の実例を図示している。
However, depending on the bridge's configuration, if a transaction fails, the system may automatically restart to deliver value or stop and wait for user input. FIG. 8 8004 illustrates a chained transaction in which
それぞれ存在可能なルートは、手数料及び交換が関与する可能性があり、推定デリバリー時間を有する。提案される移転の価格は、移転アクションをサポートするためにユーザに提示するよう計算されなければならない。チェーン化移転ハンドラ２００４は、Ａｔｏｍｉｃｉｔｙ（原子性）（Ａ）に対する管理可能な代替を提供し、Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）（Ｃ）、Ｉｓｏｌａｔｉｏｎ（分離性）（Ｉ）、Ｄｕｒａｂｉｌｉｔｙ（耐久性）（Ｄ）をＡＣＩＤ（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＡＣＩＤ＿（ｃｏｍｐｕｔｅｒ＿ｓｃｉｅｎｃｅ） ｐａｙｍｅｎｔ ｄｅｌｉｖｅｒｙ参照）に一貫して実現するように設計される。チェーン化移転ハンドラ・モジュール２００４は、以下のファンクションを提供することによってクロス台帳支払いを編成する：台帳相互運用性、ルート計画、価格及び手数料発見、取引管理、取引状態、並びにロギング。チェーン化移転ハンドラ・モジュール２００４は、ネットワークに対して、以下によって高信頼エンドツーエンド移転を保証する：
・トレーサビリティ及び信頼のために実行される時、提案されるエンドツーエンドの取引及びすべてのサブ取引を、ゼロ知識証明と共に台帳（システム取引台帳２０１２など）に公表する；
・取引が巡回するそれぞれのネットワークにおいて、移転機能を活用する相互運用性フレームワークを使用して移転をシーケンス化する；
・各取引が正常に実行され（又はロールバックされ）、価値が正常に運ばれることを保証する。
Each possible route may involve fees and exchanges and has an estimated delivery time. A proposed transfer price must be calculated to present to the user in support of the transfer action. The chained
Publish the proposed end-to-end transaction and all sub-transactions with zero-knowledge proofs to a ledger (such as System Transaction Ledger 2012) when executed for traceability and trust;
- Sequence transfers using an interoperability framework that leverages transfer functions in each network the transaction circulates;
• Ensuring that each transaction is successfully executed (or rolled back) and that value is successfully transferred.
Ｉｓｏｌａｔｉｏｎ（Ｉ）は、それぞれ個々の台帳取引をより大きなフローのコンポーネントとして分離する共通のＩＰａｙｍｅｎｔＳｅｒｖｉｃｅプラグインを介して実現される。このプラグイン・フレームワークは、異種の台帳にわたって取引を処理するための共通モデルを提供する。取引管理：取引管理は、チェーン化支払いのＤｕｒａｂｉｌｉｔｙ（Ｄ）を用意する。ＣＴＨは、複雑な支払いシーケンスの各ステップを管理して、故障停止又は支払いネットワークの障害に直面しても、それが実行されることを保証する。このコンポーネントは、並列又は直列の取引を取り扱い、支払い及びブリッジ取引を実行する。 Isolation (I) is accomplished through a common IPaymentService plugin that isolates each individual ledger transaction as a component of a larger flow. This plugin framework provides a common model for processing transactions across heterogeneous ledgers. Transaction Management: Transaction Management provides Durability (D) for chained payments. CTH manages each step of the complex payment sequence to ensure that it is carried out in the face of outages or payment network failures. This component handles parallel or serial transactions and performs payment and bridging transactions.
特定の取引の不可逆性（手数料のため）、特定のチェーン化支払いを特徴付ける長期のデリバリー時間フレーム、及び頻繁に変化する市場状況により、Ａｔｏｍｉｃｉｔｙ（Ａ）は、保証することができない。スリッページ（取引の開始とその完了までの、為替レート又は手数料の変化）に備えるために、ＣＴＨは、著しい変化があった場合、取引を凍結することができ、ユーザが継続する意思に関して検討できるようにする。この点で、取引はロールバックすることができ（手数料は犠牲になる）、価値は、その既存の形式で請求されることができるか、又は（ユーザが変更された約定を受け入れると）取引は完了に進むよう再開始されてもよい。 Due to the irreversibility of certain transactions (due to fees), the long delivery timeframes that characterize certain chained payments, and frequently changing market conditions, Atomicity(A) cannot be guaranteed. To prepare for slippage (changes in exchange rates or fees between the initiation of a transaction and its completion), CTH may freeze the transaction if there is a significant change, allowing the user to consider their intention to continue. to At this point, the transaction can be rolled back (fees are sacrificed) and value can be charged in its existing form, or (once the user accepts the modified contract) the transaction can be It may be restarted to proceed to completion.
チェーン化された取引は２つ以上の台帳に関与する可能性があるため、関与する個々の台帳のいずれも、取引のエンドツーエンドのトレーサビリティを含まない。Ｃｏｎｓｉｓｔｅｎｃｙ（Ｃ）を保証するために、独立取引台帳モジュール２０１２によって包括的な台帳が維持され、全体的な取引並びにサブ取引のそれぞれへのリンクが追跡される。チェーン化移転は、ブリッジ構成に依存して直列又は並列に生ずる場合がある。並列な支払いは、高速であるが、インバウンドのデリバリーの時間レイテンシにおけるリスクのため、ロールバックのロック又はヘッジを必要とする場合がある。直列なデリバリーは、スリッページ管理の著しい使用を必要とすることがあり、インバウンドの取引における遅延をサポートするために、アウトバウンドのファンドのロックを必要とする場合がある。
Since a chained transaction may involve more than one ledger, none of the individual ledgers involved contain end-to-end traceability of the transaction. To ensure Consistency (C), a comprehensive ledger is maintained by the independent
直列で運用される場合、ブリッジは、チェーン化された取引（アウトバウンド）を開始するのに先立って、開始取引（インバウンド）の完了（ＩＰａｙｍｅｎｔ．Ｃｏｍｐｌｅｔｅイベント）の検証を待機する。並列で運用される場合、アウトバウンド取引は、インバウンド取引の開始の検証（ＩＰａｙｍｅｎｔ．Ｉｎｉｔｉａｔｅｄイベント）直後に開始することができる。並列の運用では、ブリッジ・オペレータは、インバウンド（及びすべての中間）取引がキャンセル又はロールバックされた場合、デリバリー・リスクを取る。しばしば、ブリッジ・オペレータは、インバウンドのネットワークがキャンセル及びロールバックを許可しない場合に、並列運用だけを許可する。代替的に、ブリッジ・オペレータは、デリバリー・リスクを補償するために高額な手数料の担保又はチャージを必要とする場合がある。直列の運用では、イニシエータは、スリッページ・リスク、つまり、デリバリーの価格の、取引の最初に提示された最初の約定からの変化を経験する可能性がある。例えば、下流のネットワーク手数料又は為替レートは、取引が開始された時から変わっている可能性がある。ブリッジ・オペレータは、価格保証（スリッページがないこと）を提供することができるが、しばしば市場変化又はヘッジ戦略を補償するために手数料を組み入れる。 When operated in series, the bridge waits for verification of completion (IPayment.Complete event) of the initiating transaction (inbound) before starting a chained transaction (outbound). When operated in parallel, the outbound transaction can start immediately after verifying the initiation of the inbound transaction (IPayment.Initiated event). In parallel operation, the bridge operator takes delivery risk if the inbound (and all intermediate) transactions are canceled or rolled back. Often bridge operators only allow parallel operation when the inbound network does not allow cancellation and rollback. Alternatively, bridge operators may require high fee collateral or charges to compensate for delivery risk. In series operations, the initiator may experience slippage risk, ie, a change in the price of delivery from the initial contract offered at the beginning of the transaction. For example, downstream network fees or exchange rates may have changed since the transaction was initiated. Bridge operators can offer price protection (no slippage), but often incorporate fees to compensate for market changes or hedging strategies.
上述のことから明らかなように、異種ネットワークに対する取引の経路を提供することに加えて、ブリッジは様々な論理的なファンクションを有することができる。預け入れは、ブリッジ・ファンクションの特殊な実例である。これには、預け入れられたファンドを、ユーザの内部口座に運ばれる等価額のトークン（Ｈｙｐｏｔｈｅｃａｔｅｄ 資産又はＩＯＵ）にリンクするＰｅｇを伴う。ＩＯＵは、他のユーザに移転すること、又は中央集権化された又は非中央集権化された取引所を介して資産と売買することができる。これらのトークンは、反対のフロー、つまり引き出しを使用して、カウンターパーティ口座における価値で償還（決済）することができる。 As is clear from the above, in addition to providing a path for transactions to heterogeneous networks, bridges can have various logical functions. A deposit is a special case of a bridge function. This involves a Peg that links the deposited funds to an equivalent amount of tokens (Hypothecated Assets or IOUs) that are carried to the user's internal account. IOUs can be transferred to other users or traded for assets through centralized or decentralized exchanges. These tokens can be redeemed (settled) for value in the counterparty account using the opposite flow, withdrawal.
Ｃｏｕｎｔｅｒｐａｒｔｙプールにおける口座残高は、流通における内部トークンの総数と厳密に一致していなければならない。両方の残高は、ユーザに公表されるべきである。一部のネットワークは、トークンの作成と破壊をサポートしているが、他のネットワークは、コールド・ウォレットを介して流通に出入りする動きを必要とする。 The account balance in the Counterparty pool must exactly match the total number of internal tokens in circulation. Both balances should be published to the user. Some networks support the creation and destruction of tokens, while others require movement in and out of circulation via cold wallets.
図１０は、担保契約移転を達成するブリッジ用の運用の実例を概略的に図示している。ステップ１において、価値は外部プロバイダ（例えば、ＯＯＢ、Ｃａｓｃａｄｅ、ＰａｙＰａｌ、イーサリアム）を使用してソース・ウォレットから保管ウォレット（ブリッジ・インバウンド）に送られる。ステップ２において、発行者ウォレットから等価な数のＩＯＵ（預け入れ額のデジタル・バージョン）が発行され、ベース・ウォレットに送られる。ステップ３において、ベース・ウォレット（ブリッジ・アウトバウンド）は、ＩＰａｙｍｅｎｔ．Ｔｒａｎｓｆｅｒを定め、価値をインターネット・プロバイダの宛先ウォレットに送る。このパターンは、チェーン化移転ハンドラ・モジュール２００４が、ソース台帳上で取引を検出して属性付け、発行者ウォレット及びベース・ウォレットからの取引を実行するための手段を有することを必要とする。この権限へのアクセスは、ブリッジのセットアップ時にグラントすることができる。ステップ２をスキップして、発行者ウォレットから宛先ウォレットに直接送ることができることに留意されたい。
FIG. 10 schematically illustrates an example operation for a bridge effecting collateral contract transfer. In
決済は、担保契約移転の逆である。ユーザが価値を台帳から除去し、価値をその元の形態に戻したいと思う場合、決済ブリッジを巡回する移転が開始される。図１１は、決済移転を達成するブリッジ用のいくつかの運用のうちの１つ運用の実例を概略的に図示している。ステップ１において、価値はＥｘｔｅｒｎａｌプロバイダ（例えば、ＯＯＢ、Ｃａｓｃａｄｅ、ＰａｙＰａｌ）を使用してソース・ウォレットからベース口座（ブリッジ・インバウンド）に送られる。ステップ２において、保管ウォレット（ブリッジ・アウトバウンド）は、ＩＧａｔｅｗａｙ Ｐａｙｍｅｎｔを定めて価値を宛先ウォレットに送る。ステップ３において、先行ステップの完了に応答して、等価な数のＩＯＵ（決済額のデジタル・バージョン）がベース（エスクロー）ウォレットからバーンされる（つまり、破壊される）。このパターンは、チェーン化移転ハンドラ・モジュール２００４が、ソース台帳上で取引を検出して属性付け、保管ウォレットからの取引を実行するための手段を有し、ベース・ウォレットからのトークンをバーンすることを必要とする。この権限へのアクセスは、ブリッジのセットアップの一部としてグラントすることができる。また、取引が失敗した場合にバーンをリバースするための権限が存在すれば、ステップ３をスキップして、ソース・ウォレットから発行者ウォレットに直接受け取ることが可能である。
Settlement is the reverse of collateral contract transfer. When a user wants to remove value from the ledger and return it to its original form, a transfer is initiated around the payment bridge. FIG. 11 schematically illustrates an example of one of several operations for a bridge to effect settlement transfer. In
マルチ台帳発行のために、クロス台帳変異を使用することが可能である。これは、例えば、所有権の公的な記録が移転用に使用されている台帳とは別個である場合、又は公的な記録が影響を受ける台帳の所有権の記録の合計である場合に使用される。上述の具体的な台帳に存在するＩｎｆｉｎＸｃｈａｎｇｅ（商標）の合計メカニズムを用いて、変異により、トークンが複数の台帳上で発行できるようになる、及び／又は１つの台帳上で発行されたトークンが別の台帳に「フロー」できるようにする手段を提供する。トークンが台帳から台帳へ移動すると、流通におけるトークンの総数は一定なままであるが、所有権の記録は台帳から台帳へと移動する。このタイプのブリッジは、引き出しファンクションと預け入れファンクションを連結する。トークンを１つの台帳から同時に除去することによって、トークンは別の台帳の流通に導入され、トークンの総数は一定なままである。台帳から出て行くファンドは、ソース台帳ベース・ウォレットに送られる。この移転はまた、トークンを移動させずにトークンを保留するエスクロー取引であってもよい。等価な数のトークンが、発行者（ウォレット、口座、又はスマート・コントラクト）から宛先台帳上の流通に、又はＣｏｌｄウォレットからプロバイダＢ上のアウトバウンド・ウォレットに、宛先へのデリバリー用に発行される。デリバリーに成功すると、ＩＩｓｓｕｅｒ．Ｄｅｓｔｒｏｙファンクションは、流通からトークンを除去するソース台帳で呼び出される。 Cross-ledger mutation can be used for multi-ledger issuance. This can be used, for example, when the public record of ownership is separate from the ledger used for the transfer, or when the public record is the sum of the ownership records of the affected ledgers. be done. Using the InfiniXchange™ aggregation mechanism present in the specific ledgers described above, mutation allows tokens to be issued on multiple ledgers and/or tokens issued on one ledger to be provide a means to allow it to “flow” into the ledger of As tokens move from ledger to ledger, the total number of tokens in circulation remains constant, but the ownership record moves from ledger to ledger. This type of bridge links the withdrawal and deposit functions. By simultaneously removing tokens from one ledger, tokens are introduced into circulation in another ledger, while the total number of tokens remains constant. Funds leaving the ledger are sent to the source ledger-based wallet. This transfer may also be an escrow transaction that holds tokens without moving them. An equivalent number of tokens are issued from the issuer (wallet, account, or smart contract) to circulation on the destination ledger, or from the Cold wallet to an outbound wallet on provider B, for delivery to the destination. Upon successful delivery, IIssuer. The Destroy function is called on the source ledger to remove the token from circulation.
アウト・オブ・バンド移転モジュール２１０４は、価値移転経路レッグがシステム内で完全に自動化されない場合に、アウト・オブ・バンド（ＯＯＢ）処理を提供する。サード・パーティがシグナリングしてデータを申し込み側のシステムに提供し、処理の実行を容易にできるように、インターフェースが設けられる。例えば、ブリッジがネットワーク間でファンドの１ｗａｙフローのみをサポートすることができる事例では、ファンドの不均衡が累積し、バランスを回復させるためにＯＯＢ取引が必要とされる場合がある。ＯＯＢのタイム・ラグ、及びアウトバウンド口座における適正なファンドの事前位置付けを管理することは、制御用にしっかり確立された数学的モデルを伴うロジスティックスの問題である。価格発見は、価格及び流動性モジュール２０１０（図２）の運用によって容易になる。このモデルは、市場ファンクションを通じて価格を調節し、インバウンドとアウトバウンドとの口座レベルのバランスを維持することが可能である。流動性を補充するために、外部の市場を使用することができる。ダーク・プールの所有者（資産をプールへ寄付する人）は、プールの使用にリンクした手数料から収入を受け取る。価格及び流動性モジュール２０１０は、エコシステム、通貨、資産取引所間の流動性を管理するように設計される。価格及び流動性モジュール２０１０は、マーケット・メイキングのアルゴリズムを適用して流動性を管理する。価格及び流動性モジュール２０１０は、ダーク・プールの両側のリソースの残高に基づいて、移転のコストを管理してもよい。これは資本のフローにおける持続的な不一致のコストを押し上げる。ＡとＢとの間のリソース・フローにおける持続する不均衡は、Ａ－＞Ｂに動くと価格が上昇し、Ｂ－＞Ａでは減少する。不一致が大きいと、モデルの収益が大きくなる。ユーザは、必要なところに流動性をもたらすよう、不一致に「投資」することができる。
Out-of-band transfer module 2104 provides out-of-band (OOB) processing when the value transfer path leg is not fully automated within the system. Interfaces are provided to allow third parties to signal and provide data to the subscribing system to facilitate the execution of transactions. For example, in cases where a bridge can only support one-way flow of funds between networks, fund imbalances may accumulate and OOB transactions may be required to restore balance. Managing the OOB time lag and pre-positioning of the correct funds in outbound accounts is a logistical problem with well-established mathematical models for control. Price discovery is facilitated by operation of the price and liquidity module 2010 (FIG. 2). This model is able to adjust prices through market functions and maintain an account-level balance between inbound and outbound. External markets can be used to supplement liquidity. Dark pool owners (those who donate their assets to the pool) receive income from fees linked to the use of the pool. The price and
通貨の交換が伴う場合、流動性ダーク・プールを使用して、エコシステム同士、又はエコシステム内の移転を容易にすることもできる。チェーン化されたフローは、価値のあらゆるフローのための経路を提供し、外部の流動性を使用するために、利用可能な通貨の交換を含み、多くのプロバイダに対して繰り返されてもよい。通貨の交換は、価格及び流動性モジュール２０１０を介して発生することができる。処理は、繰り返され、カウンターパーティの交換口座を使用して流動性を最大化することができる。
When currency exchanges are involved, liquidity dark pools can also be used to facilitate transfers between or within ecosystems. A chained flow may be repeated for many providers, including the exchange of available currencies, to provide a path for any flow of value and to use external liquidity. Currency exchanges can occur via the price and
クロス台帳の移転を行うために、追加的な代替構造及び機能上の設計が実装されてもよい。したがって、実装形態及び実例が図示され、説明されたが、発明は本明細書に開示された正確な構築及びコンポーネントに限定されないことを理解されたい。添付の特許請求の範囲で定義される本発明の思想及び範囲を逸脱することなく、配置構成、運用、並びに本明細書において開示される方法及び装置の詳細において、様々な修正形態、変更、及び変形形態が成され得る。 Additional alternative structural and functional designs may be implemented to perform cross-ledger transfers. Thus, while implementations and examples have been shown and described, it is to be understood that the invention is not limited to the precise construction and components disclosed herein. Various modifications, alterations, and modifications in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope of the invention as defined in the appended claims. Variations can be made.
Claims (20)
少なくとも２つのネットワークにまたがり、１つのソース・ノード及び１つの宛先ノードを有する取引を提案する情報を受け取ることと、
グラフ構造を巡回することであって、前記グラフ構造は、移転ネットワーク内の取引ノード及びネットワークにまたがるブリッジを含み、前記ネットワークをクロールしてノード及びブリッジを使用して前記ソース・ノードと前記宛先ノードとの間の経路を識別する複数エージェントのシステムによって作成され、前記グラフ構造内の各ノードは１つのネットワーク上に存在し、関連付けられた属性変数のセットをそれぞれ有し、前記属性変数はサポートされるトークン、及び２つの論理ネットワークにまたがる２つのノードによって定義されるブリッジを指定し、前記ブリッジは送信特性を表現する属性変数を有する、巡回することと、
前記グラフ構造に基づいて、前記取引を実行するために、サブ取引のセットを指定する取引ルート情報を生成することであって、前記情報は、前記ルートが使用された場合、前記取引の予期されるコスト及び時間を含む、生成することと、
異質なネットワーク全体に対して前記サブ取引の実行のシーケンス化を実行して制御し、完全なチェーンの正常な実行を保証して記録し、前記取引が失敗した場合はロールバックを実行するマネージャを使用して、前記サブ取引のセットの実行を制御することと
を含む、方法。 A method for interfacing heterogeneous computing networks to achieve cross-network transactions in a multi-network system, the method comprising:
receiving information proposing a transaction across at least two networks and having one source node and one destination node;
traversing a graph structure, said graph structure comprising transaction nodes in a transfer network and bridges across networks, crawling said network to access said source nodes and said destination nodes using nodes and bridges; created by a system of multiple agents identifying paths between and each node in said graph structure residing on a network and each having a set of associated attribute variables, said attribute variables supported and a bridge defined by two nodes spanning two logical networks, said bridge having attribute variables representing transmission characteristics;
generating trade route information that specifies a set of sub-transactions for executing the trade, based on the graph structure, the information being an expected result of the trade if the route is used; generating, including the cost and time to
A manager that executes and controls the sequencing of the execution of said sub-transactions across a heterogeneous network, guarantees and records the successful execution of the complete chain, and performs rollbacks if said transactions fail. using to control execution of said set of sub-transactions.
少なくとも１つのコンピュータ・プロセッサと、
前記少なくとも１つのコンピュータ・プロセッサによって実行されると、前記少なくとも１つのコンピュータ・プロセッサに、
少なくとも２つのネットワークにまたがり、１つのソース・ノード及び１つの宛先ノードを有する取引を提案する情報を受け取ることと、
グラフ構造を巡回することであって、前記グラフ構造は、移転ネットワーク内の取引ノード及びネットワークにまたがるブリッジを含み、前記ネットワークをクロールしてノード及びブリッジを使用して前記ソース・ノードと前記宛先ノードとの間の経路を識別する複数エージェントのシステムによって作成され、前記グラフ構造内の各ノードは１つのネットワーク上に存在し、関連付けられた属性変数のセットをそれぞれ有し、前記属性変数はサポートされるトークン、及び２つの論理ネットワークにまたがる２つのノードによって定義されるブリッジを指定し、前記ブリッジは送信特性を表現する属性変数を有する、巡回することと、
前記グラフ構造に基づいて、前記取引を実行するために、サブ取引のセットを指定する取引ルート情報を生成することであって、前記情報は、前記ルートが使用された場合、前記取引の予期されるコスト及び時間を含む、生成することと、
異質なネットワーク全体に対して前記サブ取引の実行のシーケンス化を実行して制御し、完全なチェーンの正常な実行を保証して記録し、前記取引が失敗した場合はロールバックを実行するマネージャを使用して、前記サブ取引のセットの実行を制御することと
を行わせる、コンピュータ可読命令を記憶する少なくとも１つのメモリと
を備える、コンピュータ・アーキテクチャ。 A computer architecture for interfacing heterogeneous computing networks to achieve cross-network transactions in a multiple network system, said architecture comprising:
at least one computer processor;
When executed by the at least one computer processor, to the at least one computer processor:
receiving information proposing a transaction across at least two networks and having one source node and one destination node;
traversing a graph structure, said graph structure comprising transaction nodes in a transfer network and bridges across networks, crawling said network to access said source nodes and said destination nodes using nodes and bridges; created by a system of multiple agents identifying paths between and each node in said graph structure residing on a network and each having a set of associated attribute variables, said attribute variables supported and a bridge defined by two nodes spanning two logical networks, said bridge having attribute variables representing transmission characteristics;
generating trade route information that specifies a set of sub-transactions for executing the trade, based on the graph structure, the information being an expected result of the trade if the route is used; generating, including the cost and time to
A manager that executes and controls the sequencing of the execution of said sub-transactions across a heterogeneous network, guarantees and records the successful execution of the complete chain, and performs rollbacks if said transactions fail. and at least one memory storing computer readable instructions for use to control execution of said set of sub-transactions.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201962839971P | 2019-04-29 | 2019-04-29 | |
| US62/839,971 | 2019-04-29 | ||
| PCT/US2020/030350 WO2020223272A1 (en) | 2019-04-29 | 2020-04-29 | Method, apparatus, and computer-readable medium for transaction management spanning multiple heterogeneous computing networks |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2022535497A true JP2022535497A (en) | 2022-08-09 |
Family
ID=73028737
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2021563612A Pending JP2022535497A (en) | 2019-04-29 | 2020-04-29 | Method, apparatus, and computer readable medium for transaction management across multiple heterogeneous computing networks |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP3963531A4 (en) |
| JP (1) | JP2022535497A (en) |
| KR (1) | KR20220027827A (en) |
| CN (1) | CN114270385A (en) |
| CA (1) | CA3137743A1 (en) |
| LU (1) | LU102336B1 (en) |
| WO (1) | WO2020223272A1 (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012517060A (en) * | 2009-02-03 | 2012-07-26 | イーサーブグローバル ユーケー リミテッド | Transaction processing system and method |
| US20160307170A1 (en) * | 2015-04-14 | 2016-10-20 | Bank Of America Corporation | Apparatus and method for conducting and managing transactions between different networks |
| US20180205552A1 (en) * | 2015-06-02 | 2018-07-19 | ALTR Solutions, Inc. | Utilizing a tree-structure to segment and distribute files across a series of blockchains |
| US20180343114A1 (en) * | 2015-11-24 | 2018-11-29 | Adi BEN-ARI | A system and method for blockchain smart contract data privacy |
| WO2019072271A2 (en) * | 2018-11-16 | 2019-04-18 | Alibaba Group Holding Limited | A domain name scheme for cross-chain interactions in blockchain systems |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160162897A1 (en) * | 2014-12-03 | 2016-06-09 | The Filing Cabinet, LLC | System and method for user authentication using crypto-currency transactions as access tokens |
| US11159318B2 (en) * | 2015-01-30 | 2021-10-26 | Enrico Maim | Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions |
| EP3292505A4 (en) * | 2015-05-07 | 2018-06-13 | Zerodb, Inc. | Zero-knowledge databases |
| CN108701276B (en) * | 2015-10-14 | 2022-04-12 | 剑桥区块链有限责任公司 | System and method for managing digital identities |
| US20170213289A1 (en) * | 2016-01-27 | 2017-07-27 | George Daniel Doney | Dividend Yielding Digital Currency through Elastic Securitization, High Frequency Cross Exchange Trading, and Smart Contracts |
-
2020
- 2020-04-29 JP JP2021563612A patent/JP2022535497A/en active Pending
- 2020-04-29 LU LU102336A patent/LU102336B1/en active IP Right Grant
- 2020-04-29 CA CA3137743A patent/CA3137743A1/en active Pending
- 2020-04-29 CN CN202080043513.4A patent/CN114270385A/en active Pending
- 2020-04-29 EP EP20798847.8A patent/EP3963531A4/en not_active Withdrawn
- 2020-04-29 KR KR1020217038687A patent/KR20220027827A/en unknown
- 2020-04-29 WO PCT/US2020/030350 patent/WO2020223272A1/en active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012517060A (en) * | 2009-02-03 | 2012-07-26 | イーサーブグローバル ユーケー リミテッド | Transaction processing system and method |
| US20160307170A1 (en) * | 2015-04-14 | 2016-10-20 | Bank Of America Corporation | Apparatus and method for conducting and managing transactions between different networks |
| US20180205552A1 (en) * | 2015-06-02 | 2018-07-19 | ALTR Solutions, Inc. | Utilizing a tree-structure to segment and distribute files across a series of blockchains |
| US20180343114A1 (en) * | 2015-11-24 | 2018-11-29 | Adi BEN-ARI | A system and method for blockchain smart contract data privacy |
| WO2019072271A2 (en) * | 2018-11-16 | 2019-04-18 | Alibaba Group Holding Limited | A domain name scheme for cross-chain interactions in blockchain systems |
Also Published As
| Publication number | Publication date |
|---|---|
| LU102336B1 (en) | 2021-04-29 |
| KR20220027827A (en) | 2022-03-08 |
| LU102336A1 (en) | 2021-01-05 |
| EP3963531A1 (en) | 2022-03-09 |
| EP3963531A4 (en) | 2023-01-18 |
| CA3137743A1 (en) | 2020-11-05 |
| CN114270385A (en) | 2022-04-01 |
| WO2020223272A1 (en) | 2020-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11430066B2 (en) | Systems, methods, and storage media for managing digital liquidity tokens in a distributed ledger platform | |
| US11038718B2 (en) | Method, apparatus, and computer-readable medium for transaction management spanning multiple heterogeneous computing networks | |
| LU102335B1 (en) | Systems, methods, and storage media for managing digital liquidity tokens in a distribution ledger platform | |
| EP3776441B1 (en) | Digital asset exchange | |
| US11386493B2 (en) | System and method for cryptocurrency trading | |
| JP2022547130A (en) | Systems and methods for providing a blockchain-based process of record | |
| Subramanian | Security tokens: architecture, smart contract applications and illustrations using SAFE | |
| US20220385499A1 (en) | Method, apparatus, and computer-readable medium for transaction management spanning multiple heterogeneous computing networks | |
| CN111445327A (en) | Data resource processing method and device, computer storage medium and electronic equipment | |
| US20240005409A1 (en) | Systems, methods, and storage media for managing digital liquidity tokens in a distributed ledger platform | |
| Shamili et al. | Blockchain based Application: Decentralized Financial Technologies for Exchanging Crypto Currency | |
| JP2022535497A (en) | Method, apparatus, and computer readable medium for transaction management across multiple heterogeneous computing networks | |
| US20240007329A1 (en) | Method, apparatus, and computer-readable medium for transaction management spanning multiple heterogeneous computing networks | |
| Alm et al. | Toward a framework for assessing meaningful differences between blockchain platforms | |
| WO2023014572A1 (en) | Method, apparatus, and computer-readable medium for transaction management spanning multiple heterogeneous computing networks | |
| US20240153009A1 (en) | Universal securities wrapper | |
| Pocha et al. | Decentralized one stop solution for real estate | |
| Santos | Smart E-Tickets: buying authentic and trustworthy tickets with blockchain | |
| França et al. | Katal: A standard framework for finance | |
| Carneciu et al. | Optimising post-trade processing using Distributed Ledger Technology | |
| Mitzelos | Implementation of credit default swaps as smart contracts on the ethereum blockchain using decentralized prediction markets | |
| Arya et al. | Developing an Effective Consensus Mechanism for a Secure Blockchain-Based Cross-Border Fund Transfer System | |
| KR20210047679A (en) | Method and system for servicing blockchain-based property trade | |
| Donin | ATLANT Platform | |
| Elliott et al. | Filed: July 17, 2018 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20211228 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20220407 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20230530 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230629 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20240206 |