WO2019010392A1 - Systèmes, procédés et dispositifs pour réduire et/ou éliminer une fuite de données dans des technologies de registre électronique pour une mise en correspondance d'ordres sans fiducie - Google Patents

Systèmes, procédés et dispositifs pour réduire et/ou éliminer une fuite de données dans des technologies de registre électronique pour une mise en correspondance d'ordres sans fiducie Download PDF

Info

Publication number
WO2019010392A1
WO2019010392A1 PCT/US2018/041052 US2018041052W WO2019010392A1 WO 2019010392 A1 WO2019010392 A1 WO 2019010392A1 US 2018041052 W US2018041052 W US 2018041052W WO 2019010392 A1 WO2019010392 A1 WO 2019010392A1
Authority
WO
WIPO (PCT)
Prior art keywords
cryptographic
platform
commitment
order
trade
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.)
Ceased
Application number
PCT/US2018/041052
Other languages
English (en)
Inventor
Adam Krellenstein
Yiqun Yin
Rune Tevasvold AUNE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SymbiontIo Inc
Original Assignee
SymbiontIo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SymbiontIo Inc filed Critical SymbiontIo Inc
Publication of WO2019010392A1 publication Critical patent/WO2019010392A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present application generally relates to electronic ledger technologies, such as centralized asset exchanges, distributed ledger technologies and blockchain.
  • electronic ledger technologies such as centralized asset exchanges, distributed ledger technologies and blockchain.
  • systems, devices, and methods for using cryptographic commitments in conjunction with performing trade order postings and/or matching in connection with electronic ledger technologies are disclosed.
  • ledgers such as electronic ledgers
  • distributed ledger technology can refer to a consensus of shared and synchronized data that can be spread across multiple sites and/or systems without any centralized data storage.
  • DLT can be centralized or decentralized and can be used to, for example, handle a myriad of transaction types, such as handle stock trades, clear and settle leveraged loans, handle catastrophe reinsurance, track land titles and transactions, record ownership of intellectual property, facilitate peer-to-peer marketplaces, and/or the like.
  • a cryptographic hash commitment-based system for matching trade orders comprises: a cryptographic platform configured to access plaintext data, the plaintext data is inputted by a user into a dynamically generated user interface, wherein the plaintext data comprises trade order data for performing a trade order; the cryptographic platform further configured to generate a cryptographic hash commitment based on the plaintext data received from user input and based on an extended field, the cryptographic hash commitment corresponding to and without including the plaintext data comprising transaction information, wherein non-permitted third parties cannot determine the plaintext data from the cryptographic hash commitment; the cryptographic platform configured to transmit the cryptographic hash commitment to an electronic order matching platform, wherein the electronic order matching platform is configured to irrevocably publish the cryptographic hash commitment on a commitment board, wherein upon irrevocably publishing the cryptographic hash commitment on the commitment board, a time priority is assigned to the crypto
  • the cryptographic platform is configured to transmit the extended field with the plaintext data to the electronic order matching platform.
  • the cryptographic platform and the electronic order matching platform are operating a single computer system.
  • the cryptographic platform operates on first computer system, and the electronic order matching platform operates on a second computer system.
  • the cryptographic platform and the electronic order matching platform are operating across a distributed computer system.
  • the electronic order matching platform is configured to receive user input from the user authorizing the transmission of the plaintext data from the cryptographic platform to the electronic order matching platform.
  • the electronic order matching platform is configured to assess a penalty on the user based on failure to receive authorization from the user to transmit the plaintext data from the cryptographic platform to the order matching platform within a predetermined period of time.
  • the electronic distributed ledger technology is a blockchain.
  • the cryptographic hash commitment is assigned the time priority by a mining node.
  • the completion of the trade order matching is performed by a central processing entity system.
  • the completion of the trade order matching is performed by a plurality of users utilizing the cryptographic hash commitment- based system.
  • the cryptographic hash commitment is configured to be signed digitally by the user.
  • the cryptographic platform is configured to transmit the extended field with the plaintext data to the electronic order matching platform.
  • the cryptographic platform and the electronic order matching platform are operating a single computer system.
  • the cryptographic platform operates on first computer system, and the electronic order matching platform operates on a second computer system.
  • the cryptographic platform and the electronic order matching platform are operating across a distributed computer system.
  • the electronic order matching platform is configured to receive user input from the user authorizing the transmission of the plaintext data from the cryptographic platform to the electronic order matching platform.
  • the electronic order matching platform is configured to assess a penalty on the user based on failure to receive authorization from the user to transmit the plaintext data from the cryptographic platform to the order platform within a predetermined period of time.
  • the cryptographic commitment is generated based on a hash function.
  • the cryptographic commitment is configured to be signed digitally by the user.
  • the electronic distributed ledger technology is a blockchain.
  • the cryptographic commitment is assigned the time priority by a mining node.
  • the completion of the trade order matching is performed by a central processing entity system. In some embodiments, the completion of the trade order matching is performed by a plurality of users utilizing the cryptographic commitment-based system.
  • Figure 1 is a flowchart illustrating an overview of an example embodiment(s) of trustless centralized order matching
  • Figure 2 is a chart illustrating example embodiment(s) of publication boards and information that can be posted on the same;
  • Figure 3 is a flowchart illustrating an overview of an example embodiment(s) of trustless centralized order matching
  • Figure 4 is a schematic diagram illustrating an example embodiment(s) of a trustless centralized order matching system
  • Figure 5 is a flowchart illustrating an overview of an example embodiment(s) of trustless decentralized order matching
  • Figure 6 is a flowchart illustrating an overview of an example embodiment(s) of trustless decentralized order matching
  • Figures 7A-7C are schematic diagrams illustrating example embodiments of a trustless decentralized order matching system for a private ledger
  • Figures 8A-8C are schematic diagrams illustrating example embodiments of a trustless decentralized order matching system for a public ledger.
  • Figure 9 is a block diagram depicting an embodiment(s) of a computer hardware system configured to run software for implementing one or more embodiments of systems, devices, and methods for reducing and/or eliminating data leakage for trustless order matching.
  • DLT distributed ledger technology
  • blockchain-based platforms have and are being developed for a number of uses.
  • DLT-based platforms have and/or are being developed for cryptocurrencies, such as Bitcoin, as well as applications to financial back-office infrastructure, handle stock trades, clear and settle leveraged loans and/or a myriad of transaction types.
  • DLT-based applications can include handling catastrophe reinsurance, tracking land titles and transactions, recording ownership of intellectual property, facilitating peer-to-peer marketplaces, and/or the like, to name a few.
  • much of the appeal of blockchain and DLT-based platforms can lie in their use of a distributed ledger, either centralized or decentralized, in which an immutable global record can emerge of the various transactions performed on the network.
  • the ability to clear and settle assets in such a setting, along with the rise of new "smart contracts" that can automatically trigger additional steps such as recording ownership changes or authorizing payments can have far-reaching implications.
  • DLT-based platforms as well as ledger technologies and DLTs can inherently comprise certain drawbacks and problems. More specifically, as will be described in more detail below, in centralized ledgers, DLTs and other ledger technologies, certain technical problems can arise due to trust or lack thereof in the time priority assignment or other priority assignment, ordering and/or matching transactions among a plurality of users and computing systems communicating through an electronic network. Some embodiments described herein address such technical shortcomings in ledger technologies by using, in certain embodiments, a cryptographic commitment. In traditional market settings, a fundamental problem facing data exchanges, trading systems, and traders can relate to how to hide or mask their trades and/or trading intentions from other trading systems/traders.
  • the second order may be processed by a miner, leader, or other processor and assigned a time priority or other priority assignment ahead of the first order.
  • information or data leakage for example relating to trade orders or other messages being transmitted on such platform, can arise in the interim period between the publication of such a transaction or other message and its validation (for example, time priority assignment or other priority assignment) by miners or designated entities/participants, exposing other entities/participants in the ledger to potential front-running and manipulation.
  • time priority assignment can refer to the actual or other priority assignment based on time but can also include priority assignment based on other schema.
  • priority can be assigned in many ways to the commitments (based on when the board receives the messages, for example, based on time, or randomly, or based on a pattern, or based on a predetermined assignment table, or the like).
  • priority order can be based on any ordering of commitments, wherein the ordering is done fairly or or otherwise, as the commitments reveal insufficient information about the orders themselves.
  • the priority is for specifying how order matching is completed when a processor (for example, a miner, leader, order publication board or the like) identifies two different orders in a same trade pair.
  • the system configured to know which to match with the corresponding USD/GOOG trade first based on the priority assignment (whether based on time or other priority schema) assigned to each order.
  • priority assignment is not based on a global assignment, but rather only relative to other orders in the same pairing.
  • the system is configured to reveal the trade pair (e.g. GOOG/USD) and is configured to only specify the relative priority of GOOG/USD and does not specify the relative order of GOOG/USD trades with AAPL/USD trades.
  • the systems disclosed herein can utilize a trustless order matching system that employs a cryptographic commitment, for example, a cryptographic hash commitment, to address the issue of information leakage and/or front-running issues inherent in centralized trading platforms, decentralized trading platforms and/or DLT platforms.
  • a cryptographic commitment for example, a cryptographic hash commitment
  • some embodiments of systems, devices, and methods described herein provide specific and detailed solutions to address such technical problems relating to data leakage arising in the context of electronic ledger technologies, including centralized ledgers, distributed ledger technologies (DLT) and blockchain, to provide a trustless order matching system for an electronic ledger platform, centralized trading platform, or DLT-based platform.
  • DLT distributed ledger technologies
  • some embodiments described herein can also enable and facilitate trading in distributed ledgers themselves, opening the way to even greater applications of DLT.
  • proposed uses of distributed ledgers focus mainly on post-trade clearing and settlement where there is little ability to profit from any information leakage.
  • some embodiments described herein can be implemented in conjunction with distributed ledgers to operate decentralized markets that safeguard participants' information.
  • information or data leakage problems arising from the architecture of distributed ledger technologies can be solved, thereby greatly expanding the feasibility of certain distributed ledger applications.
  • some embodiments described herein can provide secure, auditable order matching and resolution on a distributed or non-distributed system, and more particularly, include techniques to establish global ordering of messages, trades, orders, or the like on the system independent of the content of the messages, trades, orders, or the like.
  • certain systems, devices, and methods described herein can provide or allow for implementation of a trustless order matching system for electronic ledger technologies, such as centralized ledger platforms, DLT-based platforms or blockchain-based platforms.
  • Some embodiments described herein can be configured to provide technical solutions to improve current ledger technologies, current exchange / order matching platforms, DLTs or other electronic order posting and/or matching platforms and address this problem in exchanges and/or order matching platforms based on electronic ledger technologies and distributed electronic ledger technologies, such as centralized ledger technologies, DLTs and blockchain, for example, by use of cryptographic commitments.
  • cryptographic commitments such as for example, cryptographic hash commitments
  • the cryptographic commitment can be generated from a trade order and/or other message that the user intends to place.
  • the cryptographic commitment can be realized or generated by a hash function and/or other cryptographic constructions or schemes.
  • the cryptographic commitment can be a cryptographic hash commitment or other cryptographic commitment.
  • the cryptographic commitment can be configured such that it is technically impossible to determine the corresponding, correlating, or underlying trade order or message data from the cryptographic commitment.
  • the cryptographic commitment initially published on the electronic ledger platform can be used to assign time priorities instead of the actual trade order or other message that was used to generate the cryptographic commitment.
  • a time priority or other priority assignment for each trade order or other message placed on the electronic ledger platform can be assigned while hiding or without actual knowledge of the corresponding, correlating, or underlying trade order or other message data.
  • the use of cryptographic commitments can prevent third parties, such as miners, leaders, processors, third-party traders, and/or other entities from knowing and/or determining the identity of the entity that placed the order and/or submitted the cryptographic commitment, thereby avoiding the opportunity for certain orders to receive preferential processing over other orders based on the entity that placed the order.
  • third parties such as miners, leaders, processors, third-party traders, and/or other entities from knowing and/or determining the identity of the entity that placed the order and/or submitted the cryptographic commitment, thereby avoiding the opportunity for certain orders to receive preferential processing over other orders based on the entity that placed the order.
  • such platforms can effectively prevent other entities from copying or front-running one's trades or messages and/or manipulating the priority of one or more trade orders.
  • time priorities for the trade orders or other messages have already been assigned and determined.
  • time priorities are already assigned and locked in, it can be substantially risk-free to disclose the underlying trade order or other message that corresponds or correlates to the previously revealed cryptographic commitment.
  • one or more problems arising from information or data leakage in electronic ledger technologies can be addressed/solved using cryptographic commitments, such as a cryptographic hash commitment, to reserve a transaction's time priority or other priority assignment.
  • cryptographic commitments such as a cryptographic hash commitment
  • a second message revealing the underlying trade order or other message can be subsequently published for matching the trade order or other message.
  • the cryptographic commitment can be thought of as an order's "fingerprint,” to hide its "footprint,” or the actual order details on the electronic ledger platform, such as a centralized ledger platform, DLT-based platform or blockchain-based platform.
  • some embodiments described herein can be applied to trading applications and/or other data exchanges on distributed or non-distributed ledgers, including but not limited to dark pools or DLT-based exchange platforms, and thereby solve information or data leakage problems that may arise on a such distributed or non-distributed ledger trading platform or other data platform.
  • a cryptographic commitment such as a hash commitment (which can be understood in some embodiments as a type of digital "fingerprint”) can be used to secure time -priority, which can then followed by a second communication revealing more features of the underlying market transaction other message.
  • the ability to front-run a trade or other message before it is stored in the distributed or non-distributed ledger can be eliminated.
  • using a "fingerprint" of a trade order or message to hide its "footprint” removes the ability to manipulate the order of transactions or messages and so restores time priority or other priority assignment to the validation process.
  • a global ordering of messages can be established in centralized and/or distributed systems independent of the content of the messages using cryptographic techniques, such as cryptographic commitments.
  • cryptographic techniques such as cryptographic commitments.
  • time priority or other priority assignment of a message (e.g., order message) in a network can be established separately without having to reveal the contents in the message to the network (e.g. the asset, the price, the quantity, etc.).
  • cryptographic commitments are generally constructed to have the same output length. In other words, independent of the input message length, the length of the commitment is the same in some embodiments. As such, one cannot distinguish different commitments from the output length in some embodiments.
  • the party that is ordering the messages and/or transactions would therefore not have an incentive to misreport the order in which the messages were received.
  • the contents of the message can be revealed to the network, and the actual order matching can take place. Once network participants view and/ or access the time priority or other priority assignment of the order messages, these participants can "trustlessly" verify that the orders are matched correctly, according to their time priority or other priority assignment.
  • some embodiments herein can allow any third-party or other network or platform participants to confirm, audit, or verify that a later revealed message or trade order does in fact correspond or correlate to the previously disclosed cryptographic commitment that was used to assign time priorities. More specifically, in some embodiments, third parties or other network or platform participants can regenerate the cryptographic commitment based on the later revealed trade order or other message. If the subsequently regenerated cryptographic commitment matches the previously revealed cryptographic commitment used to determine time priorities, then third parties can verify the correspondence or correlation. If not, the system or third-party authority can assess, impose, or cause to impose a penalty on the user that subsequently revealed a trade order or message that does not correspond or correlate to the previously disclosed cryptographic commitment.
  • Another problem in such trustless order matching system can be that one or more users may prevent or decide not to reveal the actual trade order or message after the time priority or other priority assignment is assigned. For example, for one reason or another, a user may determine that the time priority or other priority assignment assigned to that user's trade order or message is not beneficial or ideal, and therefore may decide not to subsequently reveal or disclose the correlating trade order or message, thereby preventing matching of the user's trade order or message.
  • the system can be configured to prevent such user decisions by automatically disclosing or revealing the trade order or message, for example after a predetermined period of time or after time priorities have been finally determined or confirmed for a predetermined number or size of trade orders or messages.
  • the system or third-party authority can assess, impose, or cause to impose a penalty on the user that subsequently prevented disclosure of a trade order or message after revealing a cryptographic commitment and/or after being assigned a time priority or other priority assignment for the user's cryptographic commitment.
  • Time priority or other priority assignment can be a crucial component in trade order matching systems, whether it is a distributed system or a non-distributed system.
  • Most distributed systems having multiple nodes (e.g., computers) connected together in a network do not have a global ordering of events.
  • a network event can occur when a message is published on the network.
  • a central party such as an exchange, is trusted to establish a global ordering of events based on when the central party accesses and/or views messages from the rest of the network. In some instances, such a system, however, may breakdown due to lack of trust.
  • Two such instances include: 1) instances when the exchange cannot be trusted to act honestly, for example for its own profit and 2) instances when there is no central authority, for example in a decentralized computer network (such as a distributed ledger) with a purely decentralized exchange and with no trusted network participants whatsoever.
  • a decentralized computer network such as a distributed ledger
  • dark pools may be engaging in manipulative practices. At present, however, mechanisms do not exist to verify that such manipulation does not occur.
  • the order matching process can be manipulated so that one or more network participants may profit from the ambiguity.
  • a dishonest centralized exchange can engage in electronic front-running, by inserting its own order messages, in the order queue in front of another order message that the centralized exchange has just seen on the computer network.
  • a similar situation can arise on decentralized networks, where a miner, order, or consensus leader can engage in a similar practice, also without detection by other network participants.
  • a miner, orderer, or consensus leader can refer to particular parties that are temporarily given the authority to establish or propose a global ordering (within a particular time frame and/or on a small or particular scale for example) of network events.
  • Other manipulative behavior by the party establishing the ordering of messages can include simple message censorship.
  • the miner can establish a message priority but may not necessarily perform the match itself. In such cases, the match can be performed by the network protocol in a smart contract.
  • the content of any transaction which can include events such as a trade, a quote, an indication of interest, and/or the like, that will be posted to the distributed ledger can be observable by all or parts of the network in this period. This visibility can allow other participants/entities to act upon the information carried in the transaction before it has been processed and received a guaranteed ordering relative to other transactions.
  • a public distributed ledger system such as the Bitcoin and Ethereum networks
  • transactions are processed by miners or high-powered computers that compile these transactions into chunks (known as blocks), and collect the fees associated with each transaction.
  • miners There can be numerous miners on the network, and which one writes any given block is generally unknown in advance, with the probability of doing so equal to their share of mining power relative to the total.
  • a transaction is broadcast, it is forwarded by the network and kept in a transaction pool known as a mempool.
  • a miner mines a new block, it can consist of transactions from this mempool. The miner can reorder or censor transactions as they see fit, to the point where empty blocks (with no transactions) are perfectly valid.
  • miners can be agnostic to the content or source of transactions, and they may seek to optimize their own returns by including as many transactions as possible in each block and thereby collecting transaction fees. Such miners may not have any incentive to manipulate the relative order of transactions, but neither will they have any interest in keeping transactions in any particular order. Thus, transactions containing conflicting orders may be shuffled arbitrarily for a time-period of multiple minutes.
  • miners may have motives beyond simply collecting transaction and block-fees. For example, they may decide to inspect the orders awaiting processing in the mempool, and then put in their own conflicting orders in front of the other orders. The fact that they can blame the resulting sequencing on network delays, which do occur in decentralized systems, makes this a difficult problem to address. Further, the fact that most miners are anonymous only contributes to the difficulty of knowing whether such data snooping and front-running has actually occurred. What is to be understood is that there should be no expectation of privacy for broadcast data in a public distributed ledger.
  • the elected leader/component can have the freedom to order transactions relative to each other, temporarily taking responsibility for providing a canonical ordering of transactions when there is no trusted party to do so. Indeed, the problem can be exacerbated by the fact that the leader/component in this kind of system can know ahead of time that it is the one responsible for writing transactions to the ledger, and can plan accordingly.
  • the rules of such systems only when a transaction is outright censored or delayed for a long period of time, such as several seconds, does a leader- election algorithm kick in and change the system over to a different leader.
  • any leader/component may have no obligation to order transactions in the order it received them, and network delays can make the perceived order different for different observers, making it impossible to prove suspected willful reordering.
  • distributed ledger systems are distributed by technical design; geographically disbursed nodes may receive transactions in a different order due to network delays.
  • distributed ledger systems are decentralized, there can be no central authority that can be trusted to resolve the differences in order.
  • lack of global time priority or other priority assignment can set the stage for data or information leakage and potential front-running in any distributed ledger system.
  • some embodiments described herein are configured to utilize one or more cryptographic techniques, schemes, or other mechanisms for generating commitments to establish time priority or other priority assignment of a message to be placed on an electronic ledger network independent of its content. As such, some embodiments can be said to employ a cryptographic commitment scheme.
  • a cryptographic commitment to a message can be a piece of data that is computed based on the message content and (optionally) an auxiliary value or a value that may or may not be related to the message content, and the cryptographic commitment can comprise one or more or all of the following three properties: (1)
  • the cryptographic commitment hides the message content, for example, hide, conceal, remove, eliminate all or substantially all or enough of the message content (in other words, allow for some data leakage) to prevent front-running and/or prevent the order matcher (for example, a miner or other processor) from favoring one entity over another, or allowing one or more actors from profiting from the message information of another actor, or otherwise cheat in the system.
  • any party Given a message content, an auxiliary value, and a commitment value, any party can verify whether the commitment value is the valid commitment for the message content. For these properties, it can be computationally infeasible or difficult to determine the message content from a cryptographic commitment. Hence, a cryptographic commitment can be used to commit to a value before the value itself is revealed.
  • a cryptographic commitment can be realized by the system or cryptographic platform thereof by a cryptographic hash function where the auxiliary value can be a random value or any other construction or scheme that satisfies the above three properties of a cryptographic commitment.
  • a cryptographic commitment is configured to use an encryption scheme where the auxiliary value can be the encryption key.
  • any party can verify the validity of the commitment given the message content and the encryption key by encrypting the message content with the key and checking whether the ciphertext is equal to the commitment.
  • a cryptographic commitment scheme can be used to prevent traders from changing their orders between the time when the time priority or other priority assignment of their order message is established and the time when the order message itself is broadcast.
  • the system can be configured to utilize a multistage protocol.
  • the multi-stage protocol can comprise a commitment stage, content publication stage, and an order matching stage.
  • the multi-stage protocol can comprise two separate publication stages: the commitment stage and the content publication stage.
  • each market participant in the commitment stage, can publish their respective order commitment to the network so that all participants within the network can view all the order commitments. This can be used to establish time priority or other priority assignment of their respective order message and to commit to the contents within the order message. Further, the exchange or network can be configured to timestamp the commitments that are published during a given time frame.
  • each market participant in the content publication stage, after timestamps are in place, each market participant can publish the contents of the order message that has been timestamped to the network.
  • the exchange or network in the order matching stage, can first verify that the order messages of network participants correspond or correlate to the commitments that the network participants have previously published, remove the order messages that are invalid, and finally matches valid timestamped orders.
  • each market participant can verify that order matching has occurred according to the time priority or other priority assignment of the message.
  • each market participant can also verify that the orders of the network participants correspond or correlate to the commitments they have published previously.
  • all traders are required to publish the contents of their orders corresponding or correlating to each of their commitments, within a desired time period (the length of which depends on market conditions). Every network participant can detect when this condition has not been met by any other network participant.
  • the system can be configured to penalize that market participant.
  • the technology disclosed herein can be stored as a program component that is executed by a processor such as a central processing unit (CPU), for example at every node within a distributed ledger.
  • a processor such as a central processing unit (CPU), for example at every node within a distributed ledger.
  • CPU central processing unit
  • the features and embodiments discussed herein enable implementation of cryptographic commitment schemes to enable global ordering of messages.
  • the cryptographic commitment schemes can be developed by employing standard development tools and languages such as, but not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI) (Objective-) C ( ++ ), C# and/or .NET, database adapters, CGI scripts, Golang, Java, JavaScript, mapping tools, procedural and object oriented development tools, Pascal, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, web development environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP); Representational State Transfer (REST); SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/or the like.
  • Apache components Assembly, ActiveX, binary executables, (ANSI) (Objective-) C ( ++ ),
  • some embodiments of systems, devices, and methods described herein are configured to utilize a two-stage publication protocol, in which cryptographic commitments are first published without disclosing an underlying message or order. Time priorities can be assigned based on the cryptographic commitments, without revealing the actual message or order. Only after the time priorities have been determined or finalized, the underlying message or order can be published, which can subsequently be matched based on its content.
  • the cryptographic commitment scheme can be configured to utilize one or more cryptographic hash functions or other cryptographic schemes.
  • a hash can be a code generated by a cryptographic hash function and tied to any arbitrary set of data.
  • a cryptographic hash function can be a mathematical algorithm that performs a one-way transformation on a message consisting of arbitrary data, producing a cryptographic hash value.
  • One-way can mean that reversing the algorithm and learning anything about the original data is infeasible.
  • any small change in the original data can result in an extensive change in the corresponding or correlating hash value, making it look uncorrected with the first hash value. This property can also make it infeasible to find two different messages that produce the same hash value.
  • Cryptographic hashes can be the mathematical equivalent of fingerprints.
  • a fingerprint is a unique identifier of a person
  • a cryptographic hash can be a unique identifier of some data, such as a text document, image, or offer to buy a stock.
  • One example use-case of hashing is a situation where someone wants you to be able to verify that your copy of a document is an exact replication of their copy. Once you have been given the hash, even if the document is sent over an unreliable or untrusted channel, the hash can allow you to verify that you received the correct and unchanged document. The analogy would be using the fingerprint of a person to identify them; you may know nothing else about the person, and the fingerprint does not let you deduce any information about them, but once the person shows up, you can verify that he or she is the one you expected.
  • a hash can be next to impossible to guess without having access to the corresponding, correlating, or underlying data, and it can be similarly hard to reverse the process to uncover the corresponding data. It can also be statistically impossible for two different sets of data to generate the same hash, even if the two sets of data are very similar. [0058] However, with a naive approach to hashing, data that is identical will produce the same hash, potentially leaking some information about the trader's intentions if that data is an offer to trade on a market. For instance, data that is identical can be a repeated order, either at a later time or to a different market, be recognized, and have its content leaked.
  • some embodiments herein address this technical issue, for example by extending the data input into the hash function with an additional field.
  • the additional field can be without any semantic meaning.
  • the field can be a timestamp or a random number.
  • this field can be stripped before parsing the data, but can have the effect that otherwise identical data will now produce different hashes if different values are put into this extra field.
  • a cryptographic hash function in certain embodiments can be a one-way function of an arbitrary input to a fixed-length string (the "hash" of the input).
  • it can be easy to calculate the hash from the input but impossible or excessively difficult and time consuming to calculate the input from the hash.
  • hash functions are SHA-2 and SHA-3.
  • a hash commitment can refer to the use of a hash to commit to a set of data without revealing the data. Simply put, the actor that knows the data can generate a hash from the data and publishes the hash to whomever is interested in the commitment. At a later stage, when the data becomes known to other parties, they can verify the relationship between the data and the hash, and thus verify that the data has not been changed since the commitment.
  • a hash can be verified by re-computing the hash from plaintext value once posted and by comparing it to the previous value. Verification can be done by network participants that are involved in achieving distributed consensus. Hashes can be extremely fast to calculate, so flooding the system with hashes can have no greater danger than flooding the system with any other kind of data, given the speed with which hashes are computed.
  • some embodiments of systems, devices, and methods described herein are configured to generate or realize cryptographic hash commitments based on a message or trade order that a user intends to place on an electronic ledger platform, whether distributed or not.
  • the following provides a general description of an example cryptographic hash commitment scheme. However, other cryptographic schemes or commitments can also be utilized.
  • H a cryptographic hash function
  • M a message that represents the contents of a market participant's order
  • T the time of the order.
  • C a commitment.
  • the extra data which can be called salt, can be a random value generated by the participant to prevent brute force search of the input M given the commitment C.
  • each market participant and the exchange possesses a public/private key pair.
  • the market participants can sign messages such as the commitment messages using the private key and each party within the network can verify the validity of the message using the corresponding public key.
  • each market participant can additionally sign the commitment C using the private key.
  • the exchange or network can timestamp all hash commitments C that are published during a given timeframe.
  • a timeframe can be a part of the protocol. In some instances, the timeframe can be one second.
  • the timestamp can be computed as a digital signature on the message that is the concatenation of all the hash commitments from every network participant within the given timeframe, using the exchange's private key.
  • each market participant can publish the contents of the order (M, T, salt) to the network.
  • the exchange or network can match the orders based on all the published pairs (M, T).
  • one or more embodiments herein can be applied to financial markets.
  • the ability of miners or leaders to unfairly profit from trading on the information in a market participant's transaction must be removed.
  • the problem can be largely ameliorated, but it is in the preceding processing stage when miners or leaders can inspect the transactions they are supposed to be ordering that information leakage can occur.
  • one starting point for a solution can be to consider changing how this initial processing takes place, with the aim of establishing strict time priority or other priority assignment for transactions.
  • the system can be configured to utilize cryptographic hash commitments in decentralized networks to hide information in any decentralized offer matching.
  • a trader or trading system wishing to publish an offer to the decentralized market, potentially intending to match against an offer already on the order book of the market, can craft an offer according to the trading protocol of the decentralized market but, crucially, postpone the publication of the offer.
  • the details of a trade order can be run through a cryptographic hash function first, producing an identifier or hash value or other value mathematically linked to the order, but not exposing any details of the order itself, other than the fact that some trade is desired. Broadcasting that hash value and waiting for it to be processed by the system can reserve an order's time priority or other priority assignment. Once the priority is secured, the order itself can be broadcasted. At this stage, the information or data leakage may not be of any concern as all involved in the market will recognize the relationship between the order and its corresponding hash value, thus executing them at the reserved time priority or other priority assignment.
  • the trader can publish a hash of the offer to the underlying ledger, the hash commitment. Once this commitment has been irrevocably written to the ledger and assigned time priority or other priority assignment, the full offer can be published to the same ledger.
  • the system is configured to use the hash of a financial order to lock in a time priority or other priority assignment for that order.
  • the user/user system can craft/generate the order they want to execute and keep it confidential, but publish the hash.
  • no one receiving the hash will be able to deduce any information about the order, but at a later time when the full order is published, it is straightforward to verify that this is the order used to generate the hash.
  • any modification to the order after publication of the hash, by the creator or others will be plainly visible. This can reduce, remove, and/or eliminate the incentive to reorder transactions.
  • the hashes are devoid of meaningful information, the incentive to delay orders, and more importantly, the ability to act on any information in other participants' orders may be removed.
  • the second stage of the process involves broadcasting the details of the transaction. This can occur once the hash has been processed and assigned an index and timestamp. With time priority or other priority assignment established, information leakage may not be a problem because all market participants will recognize the relationship between the transaction and its corresponding hash value, thus executing them at its reserved time priority or other priority assignment.
  • a decentralized market can be configured and/or extended to expect this two-stage offer publication.
  • the decentralized market can be configured to perform the offer matching after a delay, and with time priority or other priority assignment of the offers inherited from the matching hash commitments.
  • traders can be sufficiently dis-incentivized through fees and/or other inducements from publishing a hash for which they do not eventually reveal the plaintext value.
  • the process can entail a general delay in the execution of orders. More specifically, in a setting in which participants can set out offers to buy or sell an object, if a market receives a hash, then the sender has to be given time to broadcast their actual offer before any other offers can be executed. This can be accomplished with a timeout. For example, after a hash has been written to the ledger, the sender can be given a certain time interval to broadcast their offer, or their time priority or other priority assignment is forfeited. The network as a whole can verify that the offer matches the hash broadcast previously. To allow for normal delays, this timeout can be for a set time period.
  • the predetermined timeout period can be on the order of seconds in a private distributed ledger or minutes for a public distributed ledger, like Bitcoin.
  • the timeout period can be about 1 second, about 2 seconds, about 3 seconds, about 4 seconds, about 5 seconds, about 10 seconds, about 15 seconds, about 20 seconds, about 25 seconds, about 30 seconds, about 35 seconds, about 40 seconds, about 45 seconds, about 50 seconds, about 55 seconds, about 1 minute, about 2 minutes, about 3 minutes, about 4 minutes, about 5 minutes, about 10 minutes, about 15 minutes, about 20 minutes, about 25 minutes, about 30 minutes, and/or within a range defined by two of the aforementioned values.
  • a cryptographic hash commitment scheme applied to a financial trading platform is provided herein.
  • some embodiments of a cryptographic hash commitment platform as described herein can be applied to a trading platform that is running on top of a blockchain or other distributed ledger technology-based platform.
  • the underlying ledger can be decentralized and the platform can utilize on-ledger, decentralized matching of offers.
  • Alice wants to buy 100 shares or other units of AXAX, which is a financial asset. Alice can check the order book of the trading platform and see the following orders: (1) sell 50 AXAX at $89; and (2) sell 100 AXAX at $90.
  • Alice or Alice's system could instead first craft a valid offer (i.e. she wants to buy 100 AXAX at 90), run a cryptographic hash algorithm, and publish this encrypted offer to the ledger. Alongside the hidden information in the hash, some visible information (termed “in clear”) such as the market place name and the asset name can be published in some embodiments.
  • This information can be used to determine on what queue the offer should be added. Once the hash has been retained by the ledger, a place in the queue can be definitely attributed to Alice's offer. Now, Alice has the guarantee that Bob will not be able to insert a cancellation order in the queue before her offer. She can then publish to the ledger the offer in clear (i.e. not hashed and so with details visible to everyone). Once the offer details are retained by the ledger, the matching engine can execute the order at the blended price of $89.50 as expected by Alice. The transaction can then be posted to the ledger based on the time priority or other priority assignment established by the publication of the hash.
  • no information or data leakage occurs because the initial hash revealed no relevant information that could be exploited by Bob before the offer's place in the queue is guaranteed.
  • the market must delay for a short period while the actual order is sent to the market. This latency can be on the order of the confirmation time of the ledger in question. The only requirement can be that once the hash has been broadcast and included in the global transaction log, its position therein should or must be indisputable.
  • the system could potentially be abused by publishing hashes for multiple orders and only revealing the plaintext of the hashes of offers that followed profitable market movements within the timeout interval.
  • the disincentives for doing this can be configured to be sufficient that it would difficult or impossible to make money this way.
  • the faster the network, and the shorter the timeout the smaller the potential profit, suggesting that such market design features may alleviate this problem.
  • the timeout period can be sufficiently short in order to mitigate this risk.
  • FIG. 1 is a flowchart illustrating an overview of an example embodiment(s) of trustless centralized order matching.
  • actions or events generally occur on a timeline, in which actions or events towards the top of the figure occur sooner than actions or events towards the bottom of the figure.
  • the trustless centralized order matching system and/or process illustrated in Figure 1 refers to a User A and comprises a Cryptographic Platform, whose actions are identified in rounded boxes, and an Order Matching Platform, whose actions are identified in square boxes.
  • the trustless centralized order matching system and/or process illustrated in Figure 1 further comprises an Asset Ledger, which can be centralized or decentralized, whose actions are identified in box(es) with diagonal shading.
  • the trustless centralized order matching system and/or process illustrated in Figure 1 also comprises one or more Publication Boards, as will be discussed further herein.
  • the trustless centralized order matching system and/or process illustrated in Figure 1 also refers to a User B and comprises a User B platform, whose actions are identified in shapes with dotted backgrounds, such as 122 and 126. There are also actions that can be performed by third-parties, such as authorities or financial market auditors, or a centralized system, whose actions are identified in boxes with dotted boundaries, such as 124 and 130.
  • a User A 102 can input a plain text comprising trade order information into a Cryptographic Platform.
  • the Cryptographic Platform can be configured to generate a trade order commitment at block 104 based on the inputted trade order plain text from User A.
  • the trade order commitment can be a cryptographic commitment or a cryptographic hash commitment that does not disclose the actual corresponding trade order or trade order plaintext.
  • the generated trade order commitment can be posted or otherwise publicized on a Commitment Board 106.
  • the Commitment Board 106 can be a database comprising one or more commitments received from one or more cryptographic platforms of a network.
  • the Commitment Board 106 can be accessible or auditable by any users on the network or platform in some embodiments.
  • the one or more trade order commitments can be transmitted to or otherwise accessed by an Order Matching Platform.
  • the Order Matching Platform can be configured to generate one or more trade order priorities for the one or more trade order commitments at block 108.
  • the one or more generated trade order priorities can be posted or otherwise publicized on a Priority Board 110.
  • the Priority Board 110 can be a database comprising one or more data sets of trade order commitment and associated time priorities that were assigned to that trade order commitment by the Order Matching Platform.
  • the Priority Board 110 can be accessible or auditable by any users on the network or platform in some embodiments.
  • the trade order priority can be transmitted to or otherwise accessed by the Cryptographic Platform.
  • User A can be allowed to verify the time priority or other priority assignment assigned to the Trade Order Commitment that User A inputted.
  • the Cryptographic Platform can be further configured to reveal the corresponding trade order plaintext that was used to generate the trade order commitment at block 1 12, for example optionally if/when User A verifies the time priority or other priority assignment.
  • the trade order plaintext can be posted or otherwise publicized on a Trade Order Board 1 14.
  • the Trade Order Board 114 can be a database comprising one or more sets of data of trade order commitment, time priority or other priority assignment assigned to the trade order commitment, and the corresponding trade order plaintext.
  • the Trade Order Board 114 can be accessible or auditable by any users on the network or platform in some embodiments.
  • the one or more trade order plaintexts and one or more trade order priorities assigned to those trade order commitments corresponding to the one or more trade order plaintexts can be transmitted or otherwise accessed by the Order Matching Platform. Based on the one or more trade order plaintexts and one or more trade order priorities, the Order Matching Platform can be configured to match one or more trade order plaintexts at block 116. One or more trade orders can be matched with one or more other trade orders, depending on the trade order information.
  • one or more matched trades can be posted or otherwise publicized on a Trade Board 118.
  • the Trade Board 118 can be a database comprising one or more trades.
  • the Trade Board can be accessible or auditable by any users on the network or platform in some embodiments.
  • an Asset Ledger such as a Centralized Asset Ledger or Decentralized Asset Ledger, can be configured to move one or more assets at block 120 based on the one or more trades.
  • the system can effectively reduce or eliminate trade manipulation or data leakage that can arise.
  • a user for example User A, to not reveal the trade order plaintext or even reveal a different trade order plaintext than that was actually used to generate the trade order commitment to which a time priority or other priority assignment was assigned by the Order Matching Platform.
  • one or more other users on the network may be allowed to access one or more trade order commitments and one or more trade order plaintexts that allegedly correspond to the same and verify their correlation or correspondence at block 122.
  • one or more other users on the network or platform such as User B
  • the verification succeeds in the sense that the trade order plaintext was published and that it actually corresponds to the trade order commitment, then there is no issue and the process or platform can continue. However, if the verification fails in the sense that the trade order plaintext was not published or that it does not correspond to the trade order commitment that was previously revealed and used to assign the time priority or other priority assignment, then a penalty can be imposed on User A at block 124.
  • the order matching results and resulting trades can also be auditable or verified by one or more users on the network or platform, such as User B 128.
  • one or more other users on the network or platform such as User B
  • the verification succeeds in the sense that the one or more trades corresponds or correlates to the one or more trade order plaintexts and the one or more trade order priorities, then then there is no issue and the process or platform can continue.
  • User B can initiate some form of penalty on the Order Matching Platform. For example, User B may sue the Order Matching Platform at block 130.
  • Figure 2 is a chart illustrating example embodiment(s) of publication boards and information that can be posted on the same.
  • the system can comprise one or more publication boards and/or be configured to post or publicize information on one or more publication boards.
  • a Commitment Board 106 there can be one or more of a Commitment Board 106, a Priority Board 1 10, a Trade Order Board 114, or a Trade Board 118.
  • Each or some of the boards can be all on same or different computer systems or locations.
  • each or some of the boards can be on a system that is wholly separate from the Cryptographic Platform, Order Matching Platform, Centralized Ledger System, Decentralized Ledger System, or the like.
  • one or more boards can be on the same system as one or more of the Cryptographic Platform, Order Matching Platform, Centralized Ledger System, Decentralized Ledger System, or the like.
  • all or some of the publication boards are public, such as the New York Times, Twitter, a blockchain, blockchain-based platform, DLT platform, or the like.
  • all or some of the publication boards are not truly public; however, each or some of the publication boards can be visible at least to all users or network participants on the network that wish to confirm correct behavior of the system.
  • the network only comprises one of each publication board; however, it is to be understood that the different publication boards can be combined into a single or fewer publication boards.
  • one or more of the publication boards discussed herein can be split up into more publication boards.
  • the Commitment Board 106 can comprise a list of commitments or cryptographic commitments, such as cryptographic hash commitments, generated by one or more Cryptographic Platforms on one or more user computing systems.
  • the Priority Board 110 can comprise a list of commitment-priority pairs.
  • the Priority Board 1 10 can comprise data sets of commitments or cryptographic commitments, such as cryptographic hash commitments, and time priorities assigned to each of the commitments or cryptographic commitments.
  • the Trade Order Board 114 can comprise a list of commitment-priority-trade order plaintext triples.
  • the Trade Order Board 1 14 can comprise data sets of commitments or cryptographic commitments, time priorities assigned to each of the commitments or cryptographic commitments, and trade order plaintexts that were used or at least allegedly used to generate the commitments or cryptographic commitments.
  • the Trade Board 118 can comprise a list of trades.
  • the Trade Board 118 can comprise trade data generated from matching one or more trade order plaintexts with one or more other trade order plaintexts
  • FIG. 3 is a flowchart illustrating an overview of an example embodiment(s) of trustless centralized order matching.
  • a User Interface can be configured to receive plaintext data, such as trade order data from a user at block 302.
  • the trade order data can include information about a particular asset that the user intends to buy or sell and a particular price and volume for the same.
  • a Cryptographic Platform can be configured to generate a cryptographic commitment at block 304.
  • the cryptographic commitment can be a hash that is generated based on the plaintext data and optionally an extended field as discussed above.
  • the Cryptographic Platform can be software operating on one or more user computing systems that are part of the network or platform, such as a trading platform.
  • the Cryptographic Platform can be configured publish or store the cryptographic commitment on a Commitment Board 106 as discussed above.
  • the Cryptographic Platform can be configured to receive a digital signature from the user, for example via the User Interface, to generate a signed commitment.
  • the digital signature can be transmitted by the Cryptographic Platform together with the cryptographic commitment that is being transmitted to the Commitment Board 106.
  • the user's digital signature can be published on the Commitment Board such that everyone who can see the commitment can also see the digital signature.
  • the digital signature can be an extra field that is appended to the commitment.
  • one purpose of the digital signature can be to authenticate the commitment or any other digital message.
  • a Central Processing Entity System(s) or a Time Priority Assignment Platform can be configured to assign time priorities or other priority assignments to each or some cryptographic commitments that are posted on the Commitment Board 106 at block 308.
  • the Time Priority Assignment Platform (or Other Priority Assignment Platform) can be software operating on the Central Processing Entity System(s) or on a wholly separate computing system. As previously discussed, the time priorities can be assigned based solely on the cryptographic commitments and without knowledge of the actual underlying or corresponding plaintext data that was used to generate the cryptographic commitment by the Cryptographic Platform.
  • the Central Processing Entity System(s) or Time Priority Assignment Platform can be configured to publish or store the cryptographic commitment and time priority or other priority assignment assigned thereto on a Priority Board 110 as discussed above.
  • the Cryptographic Platform can be configured to access the Priority Board 1 10 or information posted thereon to confirm the time priority or other priority assignment assigned to the cryptographic commitment at block 312.
  • the user can, in some embodiments, review and verify the time priority or other priority assignment assigned to the cryptographic commitment.
  • the user may decide not to reveal the plaintext data corresponding to the cryptographic commitment. For example, the user may not be satisfied with the time priority or other priority assignment that was assigned to the user's cryptographic commitment for one reason or another.
  • the user may decide to prevent transmission of the corresponding plaintext data at block 314.
  • the system can be configured to assess and apply a penalty on the user.
  • the Central Processing Entity System(s) or a Penalty Platform can be configured to assess and apply a penalty on the user at block 316.
  • the Penalty Platform can be software operating on the Central Processing Entity System(s) or on a wholly separate computing system, such as one operated by a third-party authority.
  • the Cryptographic Platform in some embodiments, can be configured to publish or store the plaintext data and optionally the cryptographic commitment and/or time priority assigned to the same on a Trade Order Board 114 at block 318 as discussed above. Based on the information posted on the Trade Order Board 114, one or more other users on the network or platform may want to verify correspondence between the cryptographic commitment that was used to assign the time priorities and the later revealed plaintext data. For example, in some embodiments, one or more other Cryptographic Platforms on the network or platform used by one or more other users can regenerate the cryptographic commitment using the later published plaintext data at block 320. If the regenerated cryptographic commitment matches the previously published cryptographic commitment that was used for time priority assignment or other priority assignment purposes, then the verification is complete.
  • the Central Processing Entity System(s) or an Order Matching Platform can be configured to match one or more trade orders to generate trade data at block 322.
  • the Order Matching Platform can be software operating on the Central Processing Entity System(s) or on a wholly separate computing system.
  • the Order Matching Platform or an order matching algorithm thereof can be available on the computing system of every user on the network such that the user may audit the order matching process.
  • any or every user on the network can verify the correspondence or correlation between the initially published cryptographic commitment and the later revealed plaintext data and/or also verify that the matching of the one or more orders are correct.
  • the Central Processing Entity System(s) or Order Matching Platform can be further configured to publish or store the trade data on a Trade Board 118 as discussed above.
  • the generated trade data is recorded on a Centralized or Decentralized Ledger System at block 326, for example by transmission from an Electronic Ledger Interface.
  • the Electronic Ledger Interface can be part of the Cryptographic Platform or a separate software engine or platform operating on a computing system of the user.
  • the Electronic Ledger Interface can be operating on a Centralized Processing Entity System or other computer system wholly separate from the user computing system.
  • FIG. 4 is a schematic diagram illustrating an example embodiment(s) of a trustless centralized order matching system.
  • a trustless centralized order matching system comprises one or more User or Trading Systems 402, a Centralized Processing Entity System 404, one or more Publication Boards 406, and a Centralized Ledger System or Decentralized Ledger System 408 for performing one or more processed described above.
  • Each of the one or more User or Trading Systems 402, Centralized Processing Entity System 404, one or more Publication Boards 406, and Centralized Ledger System or Decentralized Ledger System 408 can be in communication with each other over a network.
  • the Publication Boards 406 can comprise one or more of a Commitment Board 106, Priority Board 110, Trade Order Board 114, and a Trade Board 118, as discussed above.
  • each of the one or more User or Trading Systems 402 can comprise a Cryptographic Platform 410.
  • the Cryptographic Platform 410 can be configured to generate a cryptographic commitment based on plaintext data inputted by a user and optionally an extended field, first publish the cryptographic commitment, and subsequently reveal the corresponding plaintext data, among other processes described herein.
  • the Centralized Processing Entity System 404 can comprise a Penalty Platform 412.
  • the Penalty Platform 412 can be configured assess and/or apply one or penalties to users as described herein, such as users who fail to disclose or prevent disclosure of plaintext data within some predetermined time period after a time priority or other priority assignment is assigned to a previously disclosed commitment or other situations.
  • the Centralized Processing Entity System 404 can comprise an Electronic Order Matching Platform 414.
  • the Electronic Order Matching Platform 414 can be configured to match one or more trade orders based on plaintext data as described herein.
  • the Centralized Processing Entity System 404 can comprise a Time Priority Assignment Platform (or Other Priority Assignment Platform) 416.
  • the Time Priority Assignment Platform (or Other Priority Assignment Platform) 416 can be configured to assign time priorities to one or more commitments, such as cryptographic commitments, without knowledge of the corresponding plaintext data.
  • Some embodiments of systems, methods, and devices for reducing and/or eliminating data leakage can be utilized to provide a trustless order matching system for an electronic ledger, such as a centralized ledger platform, distributed ledger technology (DLT) or blockchain-based platform.
  • the trustless order matching can be decentralized.
  • the system can be configured to utilize cryptographic commitments, such as cryptographic hash commitments, in decentralized networks to hide information in decentralized offer matching.
  • Figure 5 is a flowchart illustrating an overview of an example embodiment(s) of trustless decentralized order matching. In the embodiment illustrated in Figure 5, actions or events generally occur on a timeline, in which actions or events towards the top of the figure occur sooner than actions or events towards the bottom of the figure.
  • the trustless decentralized order matching system and/or process illustrated in Figure 5 refers to a User A 502 and comprises a Node A 504, whose actions are identified in rounded boxes, and Leader/Miner system 508, whose actions are identified in square boxes.
  • the trustless decentralized order matching system and/or process illustrated in Figure 5 further comprises a Decentralized Network 514, comprising one or more Nodes, whose actions are identified in shapes with dotted backgrounds.
  • the trustless decentralized order matching system and/or process illustrated in Figure 5 also comprises one or more Publication Boards 106, 110, 114.
  • a User A 502 can input trade order plain text comprising trade order information into a user computing system, or Node A 504.
  • the Decentralized Network 514 or Platform can comprise a plurality of user nodes, including but not limited to Node A 504.
  • Node A can be configured to generate a trade order commitment at block 506 based on the inputted trade order plain text from User A.
  • the trade order commitment can be a cryptographic commitment or a cryptographic hash commitment that does not disclose the actual corresponding trade order or trade order plaintext.
  • the generated trade order commitment can be posted or otherwise publicized on a Commitment Board 106 as described above.
  • the one or more trade order commitments can be transmitted to or otherwise accessed by a Leader System or a Miner System 508.
  • the Leader or Miner System 508 can be configured to generate one or more trade order priorities for the one or more trade order commitments at block 510.
  • the one or more generated trade order priorities can be posted or otherwise publicized on a Priority Board 110 as described above.
  • the trade order priority can be transmitted to or otherwise accessed by Node A 504 and any other node on the Decentralized Network 514 or platform.
  • User A can be allowed to verify the time priority or other priority assignment assigned to the Trade Order Commitment that User A inputted.
  • Node A 504 can be further configured to reveal the corresponding trade order plaintext 512 that was used to generate the trade order commitment at block 512, for example optionally if/when User A verifies the time priority or other priority assignment.
  • the trade order plaintext can be posted or otherwise publicized on a Trade Order Board 114 as described above.
  • the one or more trade order plaintexts and one or more trade order priorities assigned to those trade order commitments corresponding to the one or more trade order plaintexts can be transmitted or otherwise accessed by the Decentralized Network 514.
  • one or more nodes on the Decentralized Network 514, or every node on the Decentralized Network 514 can be configured to verify that the trade order plaintext was published and in fact corresponds to the trade order commitment that was previously revealed at block 516. In some embodiments, if the verification succeeds in the sense that the trade order plaintext was published and that it actually corresponds to the trade order commitment, then there is no issue and the process or platform can continue.
  • the Decentralized Network 514 can then be configured to match one or more trade order plaintexts at block 520 based on the one or more trade order plaintexts and one or more trade order priorities.
  • One or more trade orders can be matched with one or more other trade orders, depending on the trade order information.
  • the Decentralized Network 514 or Asset Ledger can be configured to move one or more assets at block 522 based on the one or more trades.
  • the Decentralized Network 514 or Platform can be configured to penalize User A at block 518.
  • FIG. 6 is a flowchart illustrating an overview of an example embodiment(s) of trustless decentralized order matching.
  • a User Interface can be configured to receive plaintext data, such as trade order data from a user at block 602.
  • the trade order data can include information about a particular asset that the user intends to buy or sell and a particular price and volume for the same.
  • a Cryptographic Platform can be configured to generate a cryptographic commitment at block 604.
  • the cryptographic commitment can be a hash that is generated based on the plaintext data and optionally an extended field as discussed above.
  • the Cryptographic Platform can be software operating on one or more user computing systems that are part of a Decentralized Network or Platform, such as a trading platform.
  • the Cryptographic Platform can be configured publish or store the cryptographic commitment on a Commitment Board 106 as discussed above.
  • the Cryptographic Platform can be configured to receive a digital signature from the user, for example via the User Interface, to generate a signed commitment.
  • the digital signature can be transmitted by the Cryptographic Platform together with the cryptographic commitment that is being transmitted to the Commitment Board 106.
  • the user's digital signature can be published on the Commitment Board such that everyone who can see the commitment can also see the digital signature.
  • the digital signature can be an extra field that is appended to the commitment.
  • one purpose of the digital signature can be to authenticate the commitment or any other digital message.
  • a Leader System or one or more Mining Nodes of the Decentralized Network or Platform or a Time Priority Assignment Platform can be configured to assign time priorities to each or some cryptographic commitments that are posted on the Commitment Board 106 at block 608.
  • Mining Nodes As used herein throughout this disclosure, the terms “Mining Nodes,” “Miners,” and the like are to be understood to include analogous terms and actors in the technical field, such as but not limited to Stakers in Proof-of-Stake systems, Bakers, Leaders in consensus protocols (including but not limited to PBFT-based protocols, Paxos-based protocols, Raft-based protocols or other Byzantine fault-tolerant or crash fault-tolerant consensus protocols), a distributed time/priority assignment system, Threshold Relay-based system, and any other party or parties that manages any time ordering, transaction validation, and/or double-spend protection in DLT platforms, blockchain platforms and blockchain-like platforms, such as any alternatives to traditional Proof-of-Work or other consensus systems.
  • consensus protocols including but not limited to PBFT-based protocols, Paxos-based protocols, Raft-based protocols or other Byzantine fault-tolerant or crash fault-tolerant consensus protocols
  • Threshold Relay-based system Threshold Relay-based system, and any other
  • the Time Priority Assignment Platform (or Other Priority Assignment Platform) can be software operating on the Leader System or one or more Mining Nodes of the Decentralized Network or Platform or on a wholly separate computing system. As previously discussed, the time priorities can be assigned based solely on the cryptographic commitments and without knowledge of the actual underlying or corresponding plaintext data that was used to generate the cryptographic commitment by the Cryptographic Platform. As such, there can be no incentive for the Leader system, one or more Mining Nodes, or the Time Priority Assignment Platform (or Other Priority Assignment Platform) to manipulate the time priorities assigned.
  • the Leader system, one or more Mining Nodes, or the Time Priority Assignment Platform can be configured to publish or store the cryptographic commitment and time priority or other priority assignment assigned thereto on a Priority Board 110 as discussed above.
  • the Cryptographic Platform can be configured to access the Priority Board 1 10 or information posted thereon to confirm the time priority or other priority assignment assigned to the cryptographic commitment at block 612.
  • the user can, in some embodiments, review and verify the time priority or other priority assignment assigned to the cryptographic commitment.
  • the user may decide not to reveal the plaintext data corresponding to the cryptographic commitment. For example, the user may not be satisfied with the time priority or other priority assignment that was assigned to the user's cryptographic commitment for one reason or another.
  • the user may decide to prevent transmission of the corresponding plaintext data at block 614.
  • the Decentralized Ledger System can be configured to assess and apply a penalty on the user.
  • the Decentralized Ledger System or a Penalty Platform can be configured to assess and apply a penalty on the user at block 616.
  • the Decentralized Ledger System can comprise every user system on the Decentralized Network or Platform.
  • the Decentralized Ledger System can also comprise the Leader System or the one or more Mining Nodes.
  • the Penalty Platform can be software operating on the can be software operating on Decentralized Ledger System, such as any one or more of the user systems, Leader System or one or more Mining Nodes, or on a wholly separate computing system, such as one operated by a third-praty authority.
  • the Cryptographic Platform in some embodiments, can be configured to publish or store the plaintext data and optionally the cryptographic commitment and/or time priority or other priority assignment assigned to the same on a Trade Order Board 114 at block 618 as discussed above. Based on the information posted on the Trade Order Board 114, one or more other users on the Decentralized Network or Platform may want to verify correspondence between the cryptographic commitment that was used to assign the time priorities and the later revealed plaintext data. For example, in some embodiments, one or more other Cryptographic Platforms on the Decentralized Network or Platform used by one or more other users can regenerate the cryptographic commitment using the later published plaintext data at block 620.
  • an Order Matching Platform can be configured to match one or more trade orders to generate trade data at block 622.
  • the Order Matching Platform can be software operating on each of the user systems, such that every user of the network may audit the order matching process. As such, in some embodiments, any or every user on the network can verify the correspondence or correlation between the initially published cryptographic commitment and the later revealed plaintext data and/or also verify that the matching of the one or more orders are correct.
  • the Order Matching Platform can be software operating on the Leader System or each of the Mining Nodes.
  • the Order Matching Platform can be software operating on every user system as well as the Leader System or each of the Mining Nodes of the Decentralized Ledger System.
  • the generated trade data is recorded on a Decentralized Ledger System at block 626, for example by transmission from an Electronic Ledger Interface.
  • every user system and Leader System or Mining Nodes can be configured to record the trade data generated from matching the one or more trade orders.
  • the Electronic Ledger Interface can be part of the Cryptographic Platform or a separate software engine or platform operating on a computing system of the user.
  • the Electronic Ledger Interface can be operating on a Leader System or Mining Node or other computer system wholly separate from the user computing system.
  • FIGS 7A-7C are schematic diagrams illustrating example embodiments of a trustless decentralized order matching system for a private ledger.
  • a trustless decentralized order matching system comprises one or more User or Trading Systems 402, a Leader System 704, one or more Publication Boards 406, and a Decentralized Ledger System 708 for performing one or more processed described above.
  • Each of the one or more User or Trading Systems 402, Leader System 704, one or more Publication Boards 406, and Decentralized Ledger System 708 can be in communication with each other over a network.
  • the Publication Boards 406 can comprise one or more of a Commitment Board 106, Priority Board 110, and a Trade Order Board 114, as discussed above.
  • each of the one or more User or Trading Systems 402 can comprise a Cryptographic Platform 410.
  • the Cryptographic Platform 410 can be configured to generate a cryptographic commitment based on plaintext data inputted by a user and optionally an extended field, first publish the cryptographic commitment, and subsequently reveal the corresponding plaintext data, among other processes described herein.
  • each of the one or more User or Trading Systems 402 can further comprise an Electronic Order Matching Platform 414.
  • the Electronic Order Matching Platform 414 can be configured to match one or more trade orders based on plaintext data as described herein.
  • the Leader System 704 can comprise a Time Priority Assignment Platform (or Other Priority Assignment Platform) 416.
  • the Time Priority Assignment Platform (or Other Priority Assignment Platform) 416 can be configured to assign time priorities to one or more commitments, such as cryptographic commitments, without knowledge of the corresponding plaintext data.
  • the Decentralized Ledger System 708 can comprise or refer to every User or Trading System 402 as well as the Leader System 704 on the Decentralized Network or Platform.
  • the Decentralized Ledger System 708 can further comprise a Penalty Platform 412.
  • the Penalty Platform 412 can be configured assess and/or apply one or penalties to users as described herein, such as users who prevent disclosure of plaintext data within some predetermined time period after a time priority or other priority assignment is assigned to a previously disclosed commitment or other situations.
  • the Leader System 704 can comprise the Electronic Order Matching Platform 414 instead of each of the User or Trading Systems 402.
  • the Electronic Order Matching Platform 414 can be located all across the Decentralized Ledger System.
  • each of the User or Trading Systems 402 as well as the Leader System 704 can comprise the Electronic Order Matching Platform 414.
  • FIGS 8A-8C are schematic diagrams illustrating example embodiments of a trustless decentralized order matching system for a public ledger.
  • a trustless decentralized order matching system comprises one or more User or Trading Systems 402, one or more Mining Nodes 710, one or more Publication Boards 406, and a Decentralized Ledger System 708 for performing one or more processed described above.
  • Each of the one or more User or Trading Systems 402, one or more Mining Nodes 710, one or more Publication Boards 406, and a Decentralized Ledger System 708 can be in communication with each other over a network.
  • the Publication Boards 406 can comprise one or more of a Commitment Board 106, Priority Board 110, and a Trade Order Board 114, as discussed above.
  • each of the one or more User or Trading Systems 402 can comprise a Cryptographic Platform 410.
  • the Cryptographic Platform 410 can be configured to generate a cryptographic commitment based on plaintext data inputted by a user and optionally an extended field, first publish the cryptographic commitment, and subsequently reveal the corresponding plaintext data, among other processes described herein.
  • each of the one or more User or Trading Systems 402 can further comprise an Electronic Order Matching Platform 414.
  • the Electronic Order Matching Platform 414 can be configured to match one or more trade orders based on plaintext data as described herein.
  • each of the one or more Mining Nodes 710 can comprise a Time Priority Assignment Platform (or Other Priority Assignment Platform) 416.
  • the Time Priority Assignment Platform (or Other Priority Assignment Platform) 416 can be configured to assign time priorities to one or more commitments, such as cryptographic commitments, without knowledge of the corresponding plaintext data.
  • the Decentralized Ledger System 708 can comprise or refer to every User or Trading System 402 as well as every Mining Node 710 on the Decentralized Network or Platform.
  • the Decentralized Ledger System 708 can further comprise a Penalty Platform 412.
  • the Penalty Platform 412 can be configured assess and/or apply one or penalties to users as described herein, such as users who prevent disclosure of plaintext data within some predetermined time period after a time priority or other priority assignment is assigned to a previously disclosed commitment or other situations.
  • each of the Mining Nodes 710 can comprise the Electronic Order Matching Platform 414 instead of each of the User or Trading Systems 402.
  • the Electronic Order Matching Platform 414 can be located all across the Decentralized Ledger System.
  • each of the User or Trading Systems 402 as well as each of the Mining Nodes 710 can comprise the Electronic Order Matching Platform 414.
  • the systems, processes, and methods described herein are implemented using one or more computing systems, such as the one illustrated in Figure 9.
  • the example computer system 902 is in communication with one or more computing systems 920 and/or one or more data sources 922 via one or more networks 918. While Figure 9 illustrates an embodiment of a computing system 902, it is recognized that the functionality provided for in the components and modules of computer system 902 may be combined into fewer components and modules, or further separated into additional components and modules.
  • the computer system 902 can comprise a cryptographic commitment- based system module 914 that carries out the functions, methods, acts, and/or processes described herein.
  • the cryptographic commitment-based system module 914 is executed on the computer system 902 by a central processing unit 906 discussed further below.
  • module refers to logic embodied in hardware or firmware or to a collection of software instructions, having entry and exit points. Modules are written in a program language, such as JAVA, C or C++, PYPHON or the like. Software modules may be compiled or linked into an executable program, installed in a dynamic link library, or may be written in an interpreted language such as BASIC, PERL, LUA, or Python.
  • Modules may be called from other modules or from themselves, and/or may be invoked in response to detected events or interruptions.
  • Modules implemented in hardware include connected logic units such as gates and flip-flops, and/or may include programmable units, such as programmable gate arrays or processors.
  • the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.
  • the modules are executed by one or more computing systems, and may be stored on or within any suitable computer readable medium, or implemented in-whole or in-part within special designed hardware or firmware. Not all calculations, analysis, and/or optimization require the use of computer systems, though any of the above-described methods, calculations, processes, or analyses may be facilitated through the use of computers. Further, in some embodiments, process blocks described herein may be altered, rearranged, combined, and/or omitted.
  • the computer system 902 includes one or more processing units (CPU) 906, which may comprise a microprocessor.
  • the computer system 902 further includes a physical memory 910, such as random access memory (RAM) for temporary storage of information, a read only memory (ROM) for permanent storage of information, and a mass storage device 904, such as a backing store, hard drive, rotating magnetic disks, solid state disks (SSD), flash memory, phase-change memory (PCM), 3D XPoint memory, diskette, or optical media storage device.
  • the mass storage device may be implemented in an array of servers.
  • the components of the computer system 902 are connected to the computer using a standards based bus system.
  • the bus system can be implemented using various protocols, such as Peripheral Component Interconnect (PCI), Micro Channel, SCSI, Industrial Standard Architecture (ISA) and Extended ISA (EISA) architectures.
  • PCI Peripheral Component Interconnect
  • ISA Industrial Standard Architecture
  • EISA Extended ISA
  • the computer system 902 includes one or more input/output (I/O) devices and interfaces 912, such as a keyboard, mouse, touch pad, and printer.
  • the I/O devices and interfaces 912 can include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs as application software data, and multi-media presentations, for example.
  • the I/O devices and interfaces 912 can also provide a communications interface to various external devices.
  • the computer system 902 may comprise one or more multi-media devices 908, such as speakers, video cards, graphics accelerators, and microphones, for example.
  • the computer system 902 may run on a variety of computing devices, such as a server, a Windows server, a Structure Query Language server, a Unix Server, a personal computer, a laptop computer, and so forth. In other embodiments, the computer system 902 may run on a cluster computer system, a mainframe computer system and/or other computing system suitable for controlling and/or communicating with large databases, performing high volume transaction processing, and generating reports from large databases.
  • the computing system 902 is generally controlled and coordinated by an operating system software, such as z/OS, Windows, Linux, UNIX, BSD, SunOS, Solaris, MacOS, or other compatible operating systems, including proprietary operating systems. Operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, and I/O services, and provide a user interface, such as a graphical user interface (GUI), among other things.
  • GUI graphical user interface
  • the computer system 902 illustrated in Figure 9 is coupled to a network 918, such as a LAN, WAN, or the Internet via a communication link 916 (wired, wireless, or a combination thereof).
  • Network 918 communicates with various computing devices and/or other electronic devices.
  • Network 918 is communicating with one or more computing systems 920 and one or more data sources 922.
  • the cryptographic commitment-based system module 914 may access or may be accessed by computing systems 920 and/or data sources 922 through a web-enabled user access point. Connections may be a direct physical connection, a virtual connection, and other connection type.
  • the web-enabled user access point may comprise a browser module that uses text, graphics, audio, video, and other media to present data and to allow interaction with data via the network 918.
  • Access to the cryptographic commitment-based system module 914 of the computer system 902 by computing systems 920 and/or by data sources 922 may be through a web-enabled user access point such as the computing systems' 920 or data source's 922 personal computer, cellular phone, smartphone, laptop, tablet computer, e-reader device, audio player, or other device capable of connecting to the network 918.
  • a web-enabled user access point such as the computing systems' 920 or data source's 922 personal computer, cellular phone, smartphone, laptop, tablet computer, e-reader device, audio player, or other device capable of connecting to the network 918.
  • Such a device may have a browser module that is implemented as a module that uses text, graphics, audio, video, and other media to present data and to allow interaction with data via the network 918.
  • the output module may be implemented as a combination of an all-points addressable display such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, or other types and/or combinations of displays.
  • the output module may be implemented to communicate with input devices 912 and they also include software with the appropriate interfaces which allow a user to access data through the use of stylized screen elements, such as menus, windows, dialogue boxes, tool bars, and controls (for example, radio buttons, check boxes, sliding scales, and so forth).
  • the output module may communicate with a set of input and output devices to receive signals from the user.
  • the input device(s) may comprise a keyboard, roller ball, pen and stylus, mouse, trackball, voice recognition system, or pre-designated switches or buttons.
  • the output device(s) may comprise a speaker, a display screen, a printer, or a voice synthesizer.
  • a touch screen may act as a hybrid input/output device.
  • a user may interact with the system more directly such as through a system terminal connected to the score generator without communications over the Internet, a WAN, or LAN, or similar network.
  • the system 902 may comprise a physical or logical connection established between a remote microprocessor and a mainframe host computer for the express purpose of uploading, downloading, or viewing interactive data and databases online in real time.
  • the remote microprocessor may be operated by an entity operating the computer system 902, including the client server systems or the main server system, and/or may be operated by one or more of the data sources 922 and/or one or more of the computing systems 920.
  • terminal emulation software may be used on the microprocessor for participating in the micro-mainframe link.
  • computing systems 920 who are internal to an entity operating the computer system 902 may access the cryptographic commitment-based system module 914 internally as an application or process run by the CPU 906.
  • the computing system 902 may include one or more internal and/or external data sources (for example, data sources 922).
  • data sources 922 may be implemented using a relational database, such as DB2, Sybase, Oracle, CodeBase, and Microsoft® SQL Server as well as other types of databases such as a flat-file database, an entity relationship database, and object-oriented database, and/or a record-based database.
  • relational database such as DB2, Sybase, Oracle, CodeBase, and Microsoft® SQL Server
  • other types of databases such as a flat-file database, an entity relationship database, and object-oriented database, and/or a record-based database.
  • the computer system 902 may also access one or more databases 922.
  • the databases 922 may be stored in a database or data repository.
  • the computer system 902 may access the one or more databases 922 through a network 918 or may directly access the database or data repository through I/O devices and interfaces 912.
  • the data repository storing the one or more databases 922 may reside within the computer system 902.
  • a Uniform Resource Locator can include a web address and/or a reference to a web resource that is stored on a database and/or a server.
  • the URL can specify the location of the resource on a computer and/or a computer network.
  • the URL can include a mechanism to retrieve the network resource.
  • the source of the network resource can receive a URL, identify the location of the web resource, and transmit the web resource back to the requestor.
  • a URL can be converted to an IP address, and a Domain Name System (DNS) can look up the URL and its corresponding IP address.
  • DNS Domain Name System
  • URLs can be references to web pages, file transfers, emails, database accesses, and other applications.
  • the URLs can include a sequence of characters that identify a path, domain name, a file extension, a host name, a query, a fragment, scheme, a protocol identifier, a port number, a username, a password, a flag, an object, a resource name and/or the like.
  • the systems disclosed herein can generate, receive, transmit, apply, parse, serialize, render, and/or perform an action on a URL.
  • a cookie also referred to as an HTTP cookie, a web cookie, an internet cookie, and a browser cookie, can include data sent from a website and/or stored on a user's computer. This data can be stored by a user's web browser while the user is browsing.
  • the cookies can include useful information for websites to remember prior browsing information, such as a shopping cart on an online store, clicking of buttons, login information, and/or records of web pages or network resources visited in the past. Cookies can also include information that the user enters, such as names, addresses, passwords, credit card information, etc. Cookies can also perform computer functions. For example, authentication cookies can be used by applications (for example, a web browser) to identify whether the user is already logged in (for example, to a web site).
  • the cookie data can be encrypted to provide security for the consumer.
  • Tracking cookies can be used to compile historical browsing histories of individuals.
  • Systems disclosed herein can generate and use cookies to access data of an individual.
  • Systems can also generate and use JSON web tokens to store authenticity information, HTTP authentication as authentication protocols, IP addresses to track session or identity information, URLs, and the like.
  • Conditional language such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that some embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.
  • the headings used herein are for the convenience of the reader only and are not meant to limit the scope of the inventions or claims.
  • the methods disclosed herein may include certain actions taken by a practitioner; however, the methods can also include any third-party instruction of those actions, either expressly or by implication.
  • the ranges disclosed herein also encompass any and all overlap, sub-ranges, and combinations thereof.
  • Language such as “up to,” “at least,” “greater than,” “less than,” “between,” and the like includes the number recited. Numbers preceded by a term such as “about” or “approximately” include the recited numbers and should be interpreted based on the circumstances (e.g., as accurate as reasonably possible under the circumstances, for example ⁇ 5%, ⁇ 10%, ⁇ 15%, etc.).
  • a phrase referring to "at least one of a list of items refers to any combination of those items, including single members.
  • "at least one of: A, B, or C” is intended to cover: A, B, C, A and B, A and C, B and C, and A, B, and C.
  • Conjunctive language such as the phrase "at least one of X, Y and Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to convey that an item, term, etc. may be at least one of X, Y or Z. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne des systèmes, des procédés et des dispositifs permettant de réduire et/ou d'éliminer une fuite de données dans des technologies de registre électronique, telles que des plateformes reposant sur une technologie de registre centralisé, de registre distribué (DLT) ou sur une chaîne de blocs, pour une mise en correspondance d'ordres sans fiducie. En particulier, dans certains modes de réalisation, les systèmes, procédés et dispositifs de l'invention utilisent des engagements cryptographiques pour attribuer des priorités à des ordres sans divulguer les contenus de l'ordre réel ou de données de texte en clair. Dans certains modes de réalisation, les données de texte en clair sont révélées uniquement après que les priorités sont attribuées aux engagements cryptographiques, ce qui permet de réduire et/ou d'éliminer une fuite de données potentielle qui peut se produire dans de tels plateformes ou réseaux de registre électronique. En outre, dans certains modes de réalisation, les données de texte en clair révélées par la suite peuvent être utilisées pour régénérer l'engagement cryptographique afin de vérifier sa corrélation. En tant que tels, certains systèmes, procédés et dispositifs de la présente invention peuvent fournir un système de correspondance d'ordres sans fiducie pour des technologies de registre électronique, telles que des plateformes orientées DLT ou à chaîne de blocs.
PCT/US2018/041052 2017-07-07 2018-07-06 Systèmes, procédés et dispositifs pour réduire et/ou éliminer une fuite de données dans des technologies de registre électronique pour une mise en correspondance d'ordres sans fiducie Ceased WO2019010392A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762529954P 2017-07-07 2017-07-07
US62/529,954 2017-07-07
US201862625117P 2018-02-01 2018-02-01
US62/625,117 2018-02-01

Publications (1)

Publication Number Publication Date
WO2019010392A1 true WO2019010392A1 (fr) 2019-01-10

Family

ID=64903296

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/041052 Ceased WO2019010392A1 (fr) 2017-07-07 2018-07-06 Systèmes, procédés et dispositifs pour réduire et/ou éliminer une fuite de données dans des technologies de registre électronique pour une mise en correspondance d'ordres sans fiducie

Country Status (2)

Country Link
US (1) US20190012662A1 (fr)
WO (1) WO2019010392A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020182234A3 (fr) * 2019-08-01 2020-11-12 Advanced New Technologies Co., Ltd. Procédés et dispositifs d'appariement de transactions basés sur un système de chaîne de blocs
US11546425B2 (en) 2020-04-23 2023-01-03 Oracle International Corporation Systems and methods of providing ledger as a service
US20240249358A1 (en) * 2021-10-01 2024-07-25 Magic Dimension Studio, Inc. Trade management program, information processing apparatus, and trade management system
US12457200B2 (en) 2017-12-08 2025-10-28 Platonic Holdings, Inc. Systems, methods, and devices for implementing a smart contract on a distributed ledger technology platform

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10817593B1 (en) 2015-12-29 2020-10-27 Wells Fargo Bank, N.A. User information gathering and distribution system
US20190066205A1 (en) * 2017-08-30 2019-02-28 StartEngine Crowdfunding, Inc. Peer-to-peer trading with blockchain technology
US10320843B1 (en) 2017-12-08 2019-06-11 Symbiont.Io, Inc. Methods, systems, and devices for encrypted electronic storage and confidential network transfer of private data through a trustless distributed ledger technology system
US10873625B2 (en) * 2018-02-26 2020-12-22 International Business Machines Corpora ! Ion Service management for the infrastructure of blockchain networks
US10579424B2 (en) 2018-05-15 2020-03-03 International Business Machines Corporation Prioritization in a permissioned blockchain
US10691648B2 (en) * 2018-07-03 2020-06-23 International Business Machines Corporation Controlling volatility via blockchain
US10956377B2 (en) * 2018-07-12 2021-03-23 EMC IP Holding Company LLC Decentralized data management via geographic location-based consensus protocol
CN109033403B (zh) * 2018-08-03 2020-05-12 上海点融信息科技有限责任公司 用于搜索区块链数据的方法、装置及存储介质
CN109033406B (zh) * 2018-08-03 2020-06-05 上海点融信息科技有限责任公司 用于搜索区块链数据的方法、装置及存储介质
US10841100B2 (en) 2018-08-07 2020-11-17 The Toronto-Dominion Bank Dynamically managing exchanges of data using a distributed ledger and homomorphic commitments
US10721069B2 (en) * 2018-08-18 2020-07-21 Eygs Llp Methods and systems for enhancing privacy and efficiency on distributed ledger-based networks
US20190050854A1 (en) * 2018-09-28 2019-02-14 Intel Corporation Blockchain-based digital data exchange
US11146399B2 (en) * 2018-10-19 2021-10-12 Eygs Llp Methods and systems for retrieving zero-knowledge proof-cloaked data on distributed ledger-based networks
JP6694048B1 (ja) * 2018-12-20 2020-05-13 ぷらっとホーム株式会社 データ取引システム
US10962965B2 (en) 2019-01-15 2021-03-30 Fisher-Rosemount Systems, Inc. Maintaining quality control, regulatory, and parameter measurement data using distributed ledgers in process control systems
US11115218B2 (en) * 2019-01-15 2021-09-07 Fisher-Rosemount Systems, Inc. System for secure metering from systems of untrusted data derived from common sources
CN110785966B (zh) 2019-03-18 2022-08-26 创新先进技术有限公司 用于结束视图更改协议的系统和方法
CN110800258B (zh) 2019-03-18 2022-04-22 创新先进技术有限公司 用于结束视图更改协议的系统和方法
US10911523B2 (en) 2019-03-18 2021-02-02 Microsoft Technology Licensing, Llc Broadcast intent signaling using a decentralized network
CN109933991A (zh) * 2019-03-20 2019-06-25 杭州拜思科技有限公司 一种智能合约漏洞检测的方法、装置
EP3953834B1 (fr) 2019-04-12 2025-11-12 Symbiont.io, Inc. Systèmes, dispositifs et procédés associés à des plateformes de gestion de données basées sur une dlt et à des produits de données
US11316691B2 (en) * 2019-04-15 2022-04-26 Eygs Llp Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
US11502838B2 (en) 2019-04-15 2022-11-15 Eygs Llp Methods and systems for tracking and recovering assets stolen on distributed ledger-based networks
US11943358B2 (en) 2019-04-15 2024-03-26 Eygs Llp Methods and systems for identifying anonymized participants of distributed ledger-based networks using zero-knowledge proofs
US11677563B2 (en) 2019-04-15 2023-06-13 Eygs Llp Systems, apparatus and methods for local state storage of distributed ledger data without cloning
US11206138B2 (en) 2019-05-02 2021-12-21 Ernst & Young U.S. Llp Biosignature-based tokenization of assets in a blockchain
US11269859B1 (en) * 2019-05-22 2022-03-08 Splunk Inc. Correlating different types of data of a distributed ledger system
EP3701701A4 (fr) 2019-06-05 2020-12-30 Alibaba Group Holding Limited Système et procédé de consensus
US11036872B2 (en) * 2019-07-25 2021-06-15 Sap Se Privacy-preserving sum-based consistency checks for blockchains
US11232439B2 (en) 2019-08-09 2022-01-25 Eygs Llp Methods and systems for preventing transaction tracing on distributed ledger-based networks
US11432149B1 (en) 2019-10-10 2022-08-30 Wells Fargo Bank, N.A. Self-sovereign identification via digital credentials for selected identity attributes
CN115004628B (zh) 2019-11-20 2024-12-06 艾格斯有限责任公司 用于基于同质化和非同质化通证在基于分布式分类账的网络内识别和安全存储分布式分类账中的区分特点的系统、装置和方法
US20220084042A1 (en) * 2019-12-23 2022-03-17 Cashierbook Sdn. Bhd. Method for ensuring the authenticity and validity of item ownership transfer
CN111126978B (zh) * 2019-12-28 2023-03-14 飞天诚信科技股份有限公司 一种区块链上快速处理事务的实现方法及装置
US11574308B2 (en) 2020-04-15 2023-02-07 Eygs Llp Intelligent assertion tokens for authenticating and controlling network communications using a distributed ledger
GB2610130A (en) * 2020-05-27 2023-02-22 Ing Bank N V Noninteractive multi agent key management
JP6965400B1 (ja) 2020-06-02 2021-11-10 ぷらっとホーム株式会社 データ取引システム
EP3965358A1 (fr) * 2020-09-04 2022-03-09 Thales DIS France SA Procédé pour transfert de monnaie numérique sécurisé, tracable et préservant la confidentialité avec révocation de l'anonymat sur une blockchain
US12278907B2 (en) * 2022-02-18 2025-04-15 Onai Inc. Apparatus for secure multiparty computations for machine-learning
US20230368275A1 (en) * 2022-05-10 2023-11-16 Volvo Car Corporation Method and system for preventing duplicate orders within a client-server architecture
KR102862022B1 (ko) * 2022-07-06 2025-09-18 세종대학교산학협력단 스마트 그리드 기반 정보 보호를 위한 전력 사용 관리 시스템 및 방법
WO2024089548A1 (fr) 2022-10-23 2024-05-02 Goldman Sachs & Co. LLC Jetons d'émission numérique hiérarchique et jetons de revendication

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140156534A1 (en) * 2012-12-05 2014-06-05 Sam Quigley Method for securely storing and forwarding payment transactions
EP2852121A2 (fr) * 2013-07-10 2015-03-25 CA, Inc. Pré-génération de clés de session pour transactions électroniques et dispositifs pour pré-générer des clés de session pour des transactions électroniques
US20160379013A1 (en) * 2015-06-29 2016-12-29 PeerNova, Inc. Cryptographic assurances of data integrity for data crossing trust boundaries
US20170085555A1 (en) * 2015-07-14 2017-03-23 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US20170161829A1 (en) * 2015-12-02 2017-06-08 Michael MAZIER Method and cryptographically secure peer-to-peer trading platform

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050038732A1 (en) * 2003-08-13 2005-02-17 Espeed, Inc. Systems and methods for bid/offer liquidity spread trading
US8571951B2 (en) * 2004-08-19 2013-10-29 Leadpoint, Inc. Automated attachment of segmentation data to hot contact leads for facilitating matching of leads to interested lead buyers
US20070129958A1 (en) * 2005-12-07 2007-06-07 Calyx Technology, Inc. D/B/A Calyx Software Data sharing system and method
WO2008048713A2 (fr) * 2006-05-05 2008-04-24 President And Fellows Of Harvard College Pratiques d'enchères confidentielles, dont l'exactitude et la fiabilité peuvent être verifiées
US10038675B2 (en) * 2015-10-13 2018-07-31 Google Llc Storing decrypted body of message and key used to encrypt and decrypt body of message
US10580100B2 (en) * 2016-06-06 2020-03-03 Chicago Mercantile Exchange Inc. Data payment and authentication via a shared data structure
US10565570B2 (en) * 2016-09-27 2020-02-18 The Toronto-Dominion Bank Processing network architecture with companion database

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140156534A1 (en) * 2012-12-05 2014-06-05 Sam Quigley Method for securely storing and forwarding payment transactions
EP2852121A2 (fr) * 2013-07-10 2015-03-25 CA, Inc. Pré-génération de clés de session pour transactions électroniques et dispositifs pour pré-générer des clés de session pour des transactions électroniques
US20160379013A1 (en) * 2015-06-29 2016-12-29 PeerNova, Inc. Cryptographic assurances of data integrity for data crossing trust boundaries
US20170085555A1 (en) * 2015-07-14 2017-03-23 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US20170161829A1 (en) * 2015-12-02 2017-06-08 Michael MAZIER Method and cryptographically secure peer-to-peer trading platform

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12457200B2 (en) 2017-12-08 2025-10-28 Platonic Holdings, Inc. Systems, methods, and devices for implementing a smart contract on a distributed ledger technology platform
WO2020182234A3 (fr) * 2019-08-01 2020-11-12 Advanced New Technologies Co., Ltd. Procédés et dispositifs d'appariement de transactions basés sur un système de chaîne de blocs
CN112368733A (zh) * 2019-08-01 2021-02-12 创新先进技术有限公司 基于区块链系统进行交易匹配的方法和设备
US11546425B2 (en) 2020-04-23 2023-01-03 Oracle International Corporation Systems and methods of providing ledger as a service
US20240249358A1 (en) * 2021-10-01 2024-07-25 Magic Dimension Studio, Inc. Trade management program, information processing apparatus, and trade management system

Also Published As

Publication number Publication date
US20190012662A1 (en) 2019-01-10

Similar Documents

Publication Publication Date Title
US20190012662A1 (en) Systems, methods, and devices for reducing and/or eliminating data leakage in electronic ledger technologies for trustless order matching
JP7569602B2 (ja) 分散協調を用いるスマートコントラクトの実行
US11757643B2 (en) System and method for authenticating user identity
US12457200B2 (en) Systems, methods, and devices for implementing a smart contract on a distributed ledger technology platform
US11818265B2 (en) Methods and systems for creating and recovering accounts using dynamic passwords
AU2020219946B2 (en) Distributed ledger computing platforms and associated methods, systems and devices
US20240281796A1 (en) Systems and Methods for Facilitating Digital Wallet-Based Transactions
US10846416B2 (en) Method for managing document on basis of blockchain by using UTXO-based protocol, and document management server using same
US20200250747A1 (en) Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (dlt)
Benchoufi et al. Blockchain protocols in clinical trials: Transparency and traceability of consent
US20210152536A1 (en) Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment
Aune et al. Footprints on a blockchain: Trading and information leakage in distributed ledgers
US10673620B2 (en) Blockchain validation system
US12047507B2 (en) Creating non-fungible token shards
US20230245117A1 (en) Distributed Ledger Computing Platforms and Associated Methods, Systems and Devices
EP4163856A1 (fr) Génération d'un score de réputation segmenté
Enable Personal Data Privacy and Support Cybersecurity
Oladejo Blockchain technology: Disruptor or enhancer to the accounting and auditing profession
WO2023245199A1 (fr) Système de commande d'application de nft
Saja et al. Blockchain-based certification: enhancing transparency and trust in higher education
Alia et al. IHSAN: A Secure and Transparent Crowdfunding Platform Leveraging Comprehensive Decentralized Technologies
US20240257116A1 (en) Interchain Management of Digital Assets
CN118568771A (zh) 用于进行资产隐私证明的方法、装置、介质和程序产品
WO2024145513A1 (fr) Actifs numériques composables
Saveh A Permissioned Blockchain-Based Model for Digital Forensics

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18828715

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18828715

Country of ref document: EP

Kind code of ref document: A1