CN112368733A

CN112368733A - Method and equipment for transaction matching based on blockchain system

Info

Publication number: CN112368733A
Application number: CN202080003663.2A
Authority: CN
Inventors: 曹圣皎; 袁园; 方晖
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Ant Chain Technology Co ltd
Priority date: 2019-08-01
Filing date: 2020-07-10
Publication date: 2021-02-12
Also published as: WO2020182234A3; WO2020182234A2; SG10201907110VA; PH12020000033A1

Abstract

Methods, apparatus, and devices, including computer programs stored on computer-readable media, for transaction matching are disclosed herein. One of the methods comprises: receiving one or more transactions; determining at least one of: a match between the one or more transactions and a stored data structure, or a match between one transaction of the one or more transactions and another transaction; sending a request for confirming the determination result to the blockchain system; and updating the stored data structure in response to the blockchain system confirming that the determination is valid.

Description

Method and equipment for transaction matching based on blockchain system

Technical Field

This document relates generally to computer technology and, more particularly, to methods and apparatus for transaction matching based on a blockchain system.

Background

The blockchain system, also known as a Distributed Ledger System (DLS) or consensus system, can enable participating entities to securely and tamperproof store data. Without reference to any particular use case, the blockchain system may include any DLS and may be used for public, private, and federated blockchain networks. The public blockchain network opens all entities to use the system and participate in consensus processing. A private blockchain network is provided for a specific entity that centrally controls read and write permissions (permission). A federated blockchain network is provided for a selected group of entities that controls the consensus process and includes an access control layer.

The blockchain system maintains one or more blockchains. Blockchains are data structures used to store data, such as transactions, that can prevent malicious parties from tampering with and manipulating the data.

An order book is a collection of purchase orders and sales orders showing the various price levels at which a large number of assets are bid and ask. In conventional digital asset trading infrastructure (exchange infrastructure), the order book is not visible to all traders, making the order book dependent on a profitability media (matchmaker) and therefore easily manipulated. It is desirable to ensure that the order matching process is not manipulated while keeping the trader's order information (e.g., the trader's identity, price, and quantity) private.

Disclosure of Invention

In one embodiment, a computer-implemented method for transaction matching is provided, the method comprising: receiving one or more transactions; determining at least one of: a match between the one or more transactions and a stored data structure, or a match between one transaction of the one or more transactions and another transaction; sending a request for confirming the determination result to the blockchain system; updating the stored data structure in response to the blockchain system confirming that the determination is valid.

In another embodiment, there is provided an apparatus for transaction matching, the apparatus comprising: one or more processors; one or more computer-readable memories coupled to the one or more processors and having stored thereon instructions executable by the one or more processors to: receiving one or more transactions; determining at least one of: a match between the one or more transactions and a stored data structure, or a match between one transaction of the one or more transactions and another transaction; sending a request for confirming the determination result to the blockchain system; updating the stored data structure in response to the blockchain system confirming that the determination is valid.

In another embodiment, a non-transitory computer-readable medium having instructions stored therein, which when executed by a processor of a device, cause the device to perform a method for transaction matching, the method comprising: receiving one or more transactions; determining at least one of: a match between the one or more transactions and a stored data structure, or a match between one transaction of the one or more transactions and another transaction; sending a request for confirming the determination result to the blockchain system; updating the stored data structure in response to the blockchain system confirming that the determination is valid.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description with reference to the drawings, the same reference numerals in different drawings denote the same or similar elements, unless otherwise indicated.

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment.

Fig. 2 is a schematic diagram of a system for order matching, according to an embodiment.

Fig. 3 is a schematic diagram of an apparatus for order matching, according to an embodiment.

Fig. 4 is a diagram illustrating an order book according to an embodiment.

Fig. 5A-5D are diagrams illustrating matching of a qualified price order according to an embodiment.

Fig. 6A to 6C are diagrams illustrating market price order matching according to an embodiment.

Fig. 7 is a schematic diagram illustrating a method for order matching according to an embodiment.

Fig. 8 is a flow diagram of a method for order matching according to an embodiment.

Fig. 9 is a schematic diagram of an apparatus for order matching according to an embodiment.

Detailed Description

Embodiments herein provide methods and apparatus for order matching and validation in a blockchain system. In these methods, the computer system may receive an order, determine a match between the order and an order listed in an order book of the computer system, send a request to the blockchain system to confirm the order match result, and update the order book in response to the blockchain system confirming that the order match result is valid.

The embodiments disclosed herein have one or more technical effects. In some embodiments, the methods and apparatus may verify the validity of the order matching results in the blockchain system, rather than by a central entity such as the exchange performing the order matching. This allows decentralization of the transaction, thereby improving the security and transparency of the transaction. In some embodiments, the methods and apparatus may use the user's private identification, a commitment to price (e.g., a peterson commitment), and a commitment to quantity, rather than the actual name, or the actual value of price and quantity, when submitting a transaction, such as an order. This allows the privacy of the transaction data to be preserved while maintaining the flexibility of processing the transaction data. In some embodiments, upon requesting the blockchain system to confirm (validation) the order matching results, the methods and apparatus may provide some proofs (e.g., zero knowledge range proofs, zero knowledge proofs of discrete logarithm knowledge) to the blockchain system so that nodes of the blockchain system can verify the validity of the order matching results without revealing actual values of price and quantity. This may enhance the security and efficiency of the transaction while preserving the privacy of the transaction data.

Blockchains are data structures that store data (e.g., transactions) in a manner that the transactions are not tamperproof and can subsequently be verified. A block chain includes one or more blocks. Each block is linked to the immediately preceding block in the chain of blocks by a cryptographic hash value (cryptographical hash) that contains the block immediately preceding the block. Each tile also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have typically been verified by nodes of a blockchain system may be hashed and programmed into a data structure such as a merkel (Merkle) tree. In a Merkle tree, data at leaf nodes is hashed, and all hash values in each branch of the tree may be concatenated (concatenate) at the root of the branch. This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. By determining whether the hash value purporting to be a transaction stored in the tree is consistent with the structure of the tree, the hash value can be quickly verified.

The blockchain system includes a network of computing nodes for managing, updating, and maintaining one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. In a public blockchain network, the consensus process is controlled by nodes of the consensus network. For example, many entities, such as hundreds, thousands, or even millions of entities, may operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities. Sometimes, most entities (nodes) must sign each chunk in order for the chunk to be verified and added to the blockchain of the blockchain network. Examples of public blockchain networks include point-to-point payment networks that utilize a distributed ledger (also referred to as a blockchain).

Typically, public blockchain networks may support open transactions. The public transaction is shared by all nodes in the public blockchain network and is stored in the global blockchain. A global blockchain is a blockchain that is replicated across all nodes, and all nodes agree with the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented in a public blockchain network. Examples of consensus protocols include proof of work (POW) (e.g., implemented in some cryptocurrency networks), proof of rights (POS), and proof of authority (POA).

Typically, a private blockchain network may be provided for a particular entity that centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as authority networks, which limit who is allowed to participate in the network, as well as their level of participation (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants vote to add a new entity, regulatory agencies may control permissions).

In general, a federated blockchain network may be private between participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network related to the participating entities. In some examples, each tile must be signed by each entity (node) before it can be verified and added to the chain of tiles. In some examples, each tile must be signed by at least a subset of the entities (nodes) (e.g., at least 7 entities) before it can be verified and added to the tile chain.

Fig. 1 shows a schematic diagram of a blockchain system 100 according to an embodiment. Referring to fig. 1, a blockchain system 100 may include a plurality of nodes, such as node 102 through node 110, configured to operate on a blockchain 120. Nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each of nodes 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of block chain 120, or may be software, such as a process or application, running on the computing device. Each of nodes 102-110 may have a unique identification. The nodes 102 to 110 may communicate with each other through wired communication or wireless communication. Such communication may employ a reliable protocol such as transmission control protocol/internet protocol (TCP/IP).

Block chain 120 may include a growing list of records in the form of data chunks, such as chunks B1 through B5 in FIG. 1. Each tile of tiles B1-B5 may include a timestamp, a cryptographic hash value of a previous tile, and data of the current tile, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, chunk B5 may include a timestamp, a cryptographic hash value of chunk B4, and transaction data of chunk B5. Further, for example, a hash operation may be performed on a previous chunk to generate a cryptographic hash value for the previous chunk. The hash operation may convert inputs of various lengths into fixed-length encrypted outputs by a hash algorithm such as SHA-256.

Nodes 102-110 may be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto blockchain 120, the node may generate a new block to be added to blockchain 120 and broadcast the new block to other nodes (e.g., nodes 104-110) in network 112. Based on the validity of the new tile, e.g., its signature and transaction validity, other nodes may determine to accept the new tile so that node 102 and other nodes may add the new tile to their respective copies of blockchain 120. As this process repeats, more and more data blocks may be added to blockchain 120.

In one embodiment, the blockchain system 100 may operate according to one or more intelligent contracts. Each intelligent contract may be a computer protocol in the form of computer code that is incorporated into blockchain 120 to assist, validate, or force negotiation or execution of contracts. For example, a user of the blockchain system 100 may program the terms of the contract into a smart contract using a programming language such as C + +, Java, Solidity, Python, etc., and when the terms are satisfied, the smart contract may be automatically executed by the blockchain system 100 to, for example, execute a transaction. As another example, a smart contract may include a plurality of subroutines or functions, each of which may be a series of program instructions to perform a specified task. An intelligent contract may be an operation code that executes in whole or in part without human interaction.

Fig. 2 is a schematic diagram illustrating a system 200 for order matching, according to an embodiment. Referring to FIG. 2, the system 200 may include a transaction device 250, a user interface system 220 operated by a user 210, and a user interface system 240 operated by a user 230. Exchange device 250 may be a computer system of an exchange that is a place to exchange a thing or service (e.g., a market or center for stock or commodity trading) and may interact with blockchain system 100 (fig. 1) and user interface systems 220, 240. It will be understood that this is for illustrative purposes only, and that the number of user interface systems and the number of users in each system is not limited thereto. For example, multiple user interface systems may interact with the transaction device 250, or multiple users may share a single user interface system. In one embodiment, each user interface system may be a computer system including one or more users' transaction data systems. In some embodiments, each user interface system may operate as a node of the blockchain system 100. In other embodiments, each user interface system may not operate as a node of the blockchain system 100.

In some embodiments, the user 210 is a buyer and the user interface system 220 may submit a transaction, for example, by placing a purchase order, the user 230 is a seller, and the user interface system 240 may submit another transaction, for example, by placing a sale order. In these embodiments, each of user interface system 220 and user interface system 240 may also include an accounting system that obtains and records purchase orders for user 210 and sales orders for user 230, respectively.

In one embodiment, the user interface system 220 may be a third party transaction data system that manages transaction data for a plurality of users, including the user 210. Similarly, user interface system 240 may be a third party transaction data system that manages transaction data for multiple users, including user 230. The user 210 may create an account in the user interface system 220 using a password selected by the user. Similarly, the user 210 may create an account in the user interface system 220 using a password selected by the user.

Each of user 210 and user 230 may be any entity involved in a transaction, such as an individual, a company, a representative of a company, a financial institution, a research institution, or a governmental entity. User interface system 220 and user interface system 240 may obtain, aggregate (assign), transmit, and maintain purchase orders and/or sales orders for user 210 and user 230, respectively. In one embodiment, each of user 210 and user 230 may place multiple orders. The plurality of orders may be a plurality of purchase orders, a plurality of sales orders, or a mixture of purchase orders and sales orders.

In one embodiment, user interface system 220 can upload the purchase orders placed by user 210 to blockchain system 100. The purchase order may include an identification of the user 210, the type of transaction (in this case, "purchase"), the quantity of the item that the user 210 wishes to purchase, and the unit price of the item that the user 210 may accept. The identification of the user 210 may be a nickname or a private ID number or any other secret number known only to the user 210. In one embodiment, an encrypted commitment scheme, such as a Pedersen (Pedersen) commitment, may be used in the order data. For example, the user interface system 220 may send a purchase order having a data structure of { "type": purchase, "price": PC (p, r), "quantity": PC (q, r ') }, where PC represents a Peterson commitment, p represents a price, q represents a quantity, r is a random number used to generate the Peterson commitment for the price, and r' is a random number used to generate the Peterson commitment for the quantity.

Similarly, the user interface system 240 may upload the sales order to the blockchain system 100. The sales order may include an identification of the user 230, the type of transaction (in this case, "sales"), the quantity of the item that the user 230 wishes to sell, and the unit price of the item. The identification of the user 230 may be a nickname or a private ID number or any other secret number known only to the user 230. In one embodiment, the user interface system 240 may send a sales order having a data structure of { "type": sales, "price": PC (p, r), "quantity": PC (q, r ') }, where PC represents a Peterson commitment, p represents a price, q represents a quantity, r is a random number used to generate the Peterson commitment for the price, and r' is a random number used to generate the Peterson commitment for the quantity.

The peterson promise retains additional attributes while maintaining data privacy. For example, one party may generate a commitment value PC (p, r) g based on a random number r by transmitting the commitment value^ph^r(where p represents price, r is a random number, and g and h are generator values) to commit a price value of p. The actual price value p is hidden in the peterson commitment, and one can only open the commitment by knowing both the price value p and the random number r. Similarly, one party may generate a commitment value PC (q, r ') g ' based on a random number r ' by transmitting it^qh^r' to commit a quantity value q. The other party can only open commitments by knowing both the magnitude q and the random number r'.

In one embodiment, in addition to the commitment values for the purchase order (e.g., the peterson commitment for price and the peterson commitment for quantity), the user interface system 220 may encrypt the parameters p, q, r, and r 'of the purchase order with the public key of the exchange 250 or exchange and upload the encrypted parameters p, q, r, and r' to the blockchain system 100. Similarly, the user interface system 240 may encrypt the parameters p, q, r, and r' of the sales order using the public key of the trading device 250 or exchange and upload the encrypted parameters to the blockchain system 100 along with the commitment values for price and quantity.

Upon receiving the uploaded purchase order and sales order, the blockchain system 100 can broadcast the purchase order and sales order. The trading device 250 may receive the broadcasted purchase orders and sales orders and decrypt p, q, r, and r' of each purchase order and sales order using the private key of the trading device 250 or exchange. The transaction device 250 may further use the decrypted p, q, r, and r' values to verify p>0，q>Whether 0 holds and the correctness of the values of PC (p, r) and PC (q, r'). If p is verified>0，q>0, received PC (p, r) equals calculated g^ph^rValue, and received PC (q, r') is equal to calculated g^qh^r' value, then the correctness of the received order data is confirmed and the transaction device 250 can perform order matching.

By using a data structure of type { "type { (buy or sell)," price ": PC (p, r)," quantity ": PC (q, r') } the order submission is published to the blockchain system without revealing the actual values of price and quantity. Thus, privacy of transaction data is ensured while flexibility of the transaction is maintained. In addition, by using the private ID of the user, the privacy of the user is protected. In addition, by encrypting the parameters p, q, r, and r' using the public key of the transaction device or exchange, only the transaction device can decrypt the parameters using the corresponding private key, thereby ensuring security of the transaction.

The exchange may be any entity such as, but not limited to, a financial institution, a corporation, a government entity, a research institution or an individual authorized to match orders placed by the user. The transactional device 250 may maintain an order book to keep a record of orders placed by users and the history of order matches. In one embodiment, the order book may be a data structure stored in a storage device. In another embodiment, the order book may be a logical structure corresponding to data stored in the storage device. Whenever a new order is received, the transactional device 250 may identify a match between the new order and one or more orders listed in the order book. The transactional device 250 can also upload the order matching results and corresponding data to the blockchain system 100. In one embodiment, order matching may refer to parties in a transaction identifying matches between a new order (purchase or sale) and one or more orders (sale or purchase) at acceptable prices and quantities.

The blockchain system 100 may perform order match confirmation (valid) based on data uploaded by the transactional device 250. The confirmation may be performed by one or more parties authorized to confirm the order match performed by the transaction device 250. The one or more parties may use one or more nodes of the blockchain system 100 to verify the validity of the order matching results by comparing the order matching results to corresponding data provided by the trading device 250. If the blockchain system 100 determines that the order match performed by the trading device 250 is valid, the blockchain system 100 may broadcast a confirmation result.

After receiving the broadcasted confirmation result, the trading device 250 may update the order book to reflect the changes caused by the order match. In some embodiments, the transaction device 250 may operate as a node of the blockchain system 100. In other embodiments, the transaction device 250 may not operate as a node of the blockchain system 100.

By verifying the validity of the order matching results in the blockchain system, rather than by a central entity (e.g., the exchange performing the order matching), decentralization of the transaction is achieved, thereby enhancing security, transparency, and fairness of the transaction.

In one embodiment, each of the

users

210 and 230 may create accounts in the user interface system 220 and the user interface system 240, respectively, and the user interface system may interface with the blockchain system 100 or the transaction device 250 for placing orders. This allows

users

210 and 230 to conveniently manage their accounts using only passwords without maintaining encryption keys for transaction data.

In one embodiment, the transaction device 250 may include instructions stored in a computer system. The computer system may execute instructions to perform the functions of the transaction device 250. User interface system 220 and user interface system 240 may or may not be implemented in the computer system.

In one embodiment, the transaction device 250 may be stand-alone hardware comprising an integrated circuit and a memory device that may be compatible with any user interface system. For example, the transaction device 250 may interface with any other user interface system.

In one embodiment, the user interface system 220 and the user interface system 240 can send the encrypted order directly to the trading device 250 without uploading the order to the blockchain system. To ensure security of the transmission, the order may be encrypted with the public key of the transaction device 250 or exchange prior to transmission so that the transaction device 250 may decrypt the order using the corresponding private key.

Fig. 3 is a block diagram of an apparatus 300 for order matching according to an embodiment. For example, the device 300 may be a transaction device 250 (fig. 2). Device 300 may take any form, including but not limited to a desktop computer, laptop computer, server computer, tablet computer, smart phone or smart watch, or any other form. Device 300 may include a processor 310, a memory 320, a user interface 330, and a communication interface 340 in communication with each other via a bus 350.

Processor 310 may include one or more special-purpose processing units, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or various other types of processors or processing units. The processor 310 is coupled to the memory 320 and may execute instructions stored in the memory 320.

Communication interface 340 may facilitate communication between device 300 and user interface systems, such as user interface system 220 (fig. 2), and blockchain systems, such as blockchain system 100 (fig. 2). The communication interface 340 may receive sales orders and/or purchase orders from the blockchain system or from the user interface system. The communication interface 340 can also upload the order matching result and related data to the blockchain system or another blockchain system and receive confirmation results from the blockchain system or another blockchain system.

In one embodiment, communication interface 340 may support one or more communication standards, such as the internet standard or protocols including: TCP/IP and TLS/SSL protocols, Integrated Services Digital Network (ISDN) standards, and the like. In one embodiment, the communication interface may include one or more of the following: a Local Area Network (LAN) card, cable modem, satellite modem, data bus, cable, wireless communication channel, radio-based communication channel, cellular communication channel, Internet Protocol (IP) based communication device, or other communication device for wired and/or wireless communication. In one embodiment, communication interface 340 may be based on a public cloud infrastructure, a private cloud infrastructure, and a hybrid public/private cloud infrastructure.

Memory 320 may include a storage device that stores an order book 322, member account data 324, and a key manager 326. Order book 322 includes records of purchase orders and sales orders and results of order matching. After each order match, the order book may be updated after confirmation by the blockchain system. The member account 324 may include information of the user placing the purchase order and the sales order, such as the user's identification, their ordering history, and the results of the order matching. Key manager 326 may maintain private and public keys for device 300.

In one embodiment, the device 300 may be shared by multiple exchanges, and the member account data 324 may include information for multiple exchanges. Each of the multiple exchanges may have its own member account data and order book(s) in the device 300.

The memory 320 may also store processor-executable instructions and data. The processor-executable instructions and data may include an order matching manager 328. When the processor-executable instructions are executed by the processor 310, the order matching manager 328 allows the apparatus 300 to extract and analyze parameters included in an order received from a user interface system or a blockchain system and perform order matching based on the analysis.

The memory 320 may be any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disk.

The user interface 330 may include a display, an input device for sending user commands to the processor 310, and the like. The display may display transaction data, order matching processing, and confirmation results obtained from the blockchain system, etc. The display may include, but is not limited to, a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), a Light Emitting Diode (LED), a gas plasma, a touch screen, or other image projection device for displaying information to a user. The input devices may be any type of computer hardware device for providing data and control signals from a user to the processor 310. Input devices may include, but are not limited to, a keyboard, mouse, scanner, digital camera, joystick, trackball, cursor direction keys, touch screen monitor or audio/video manager, and the like.

In one embodiment, the device 300 may include a user interface system for a user to place a purchase order or a sales order, such as the user interface system 220 and the user interface system 240 of FIG. 2, such that the processor 310 and the user interface 330 are part of the user interface system.

FIG. 4 is a diagram illustrating an order book 400, according to an embodiment. Referring to FIG. 4, an order book 400 may be a collection of purchase orders and sales orders that have been submitted to an exchange. Each order in the order book 400 will be matched against another order so that an asset transfer may be made. In one embodiment, the order book 400 may store two separate order lists, which correspond to purchase orders and sales orders, respectively. The leftmost column of the order book 400 lists the identification number (ID) of the order. The ID may be represented as a natural number, and the natural number may be assigned to each order by the trading device 250 according to the time of receipt of the order. For example, the #1 order is received earlier than or simultaneously with the #4 order, but no later than the #4 order. The IDs may be in ascending or descending order, depending on the time the order was placed. The purchase order may be listed in order of side, time, quantity, and price, starting from the second leftmost column of the order book 400 to the right. The side indicates whether the order is a purchase order or a sales order. The time indicates the time the order was received. The quantities in the purchase order may be listed in two ways: (1) a number of peterson commitments PC (q, r'); (2) the actual value of the quantity. Similarly, the price of a purchase order may be listed in two ways: (1) peterson commitment for price PC (p, r); (2) the actual value of the price. For example, order book 400 shows two purchase orders, namely the #4 order and the #3 order. Order #4 was received at 09:08, with a quantity of 200 items and a unit price of $ 20.20. In addition to the actual values of quantity and price, the order book 400 also containsComprising a number of Pedelson commitments PC (q)₄,r'₄) Peterson commitment to price PC (p)₄,r₄). Order #3 was received at 09:06, with a quantity of 100 items and a unit price of $ 20.15. In addition to the actual values of quantity and price, the order book 400 also includes the Pedeleson commitment PC (q) for quantity₃,r'₃) Peterson commitment to price PC (p)₃,r₃)。

Similarly, sales orders may be listed in order of side, time, quantity, and price, starting with the rightmost column of the order book 400. The quantities in the sales order may be listed in two ways: (1) a number of peterson commitments PC (q, r'); (2) the actual value of the quantity. Similarly, the price of a sales order may be listed in two ways: (1) peterson commitment for price PC (p, r); (2) the actual value of the price. For example, order book 400 shows two sales orders, namely #1 order and #2 order. Order #1 was received at 09:01, with a quantity of 100 items and a unit price of $ 20.30. In addition to the actual values of quantity and price, the order book 400 also includes the Pedeleson commitment PC (q) for quantity₁,r'₁) Peterson commitment to price PC (p)₁,r₁). Order #2 was received at 09:03 with a quantity of 100 items and a unit price of $ 20.25. In addition to the actual values of quantity and price, the order book 400 also includes the Pedeleson commitment PC (q) for quantity₂,r'₂) Peterson commitment to price PC (p)₂,r₂). The actual values of the quantities and prices in the orders in the order book 400 may be kept secret from the public blockchain system. By way of example only, order book 400 shows only two purchase orders and two sales orders. However, the number in the purchase order and the number in the sales order are not limited thereto, and may be any number.

Referring back to FIG. 2, after receiving the new order, the transactional device 250 may perform order matching by comparing the new order to one or more orders currently listed in the order book 400. The orders currently listed in the order book 400 may be orders that did not match in the previous order match. For example, for a new purchase order, the trading device 250 may compare the price and quantity in the new purchase order to the price and quantity in the currently listed sales order in the order book 400 to see if the price and quantity match. Similarly, for a new sales order, the trading device 250 may compare the price and quantity in the new sales order to the price and quantity in the purchase order currently listed in the order book 400. After performing order matching, the transactional device 250 can upload the order matching results and corresponding data to the blockchain system so that the blockchain system can verify the validity of the order matching results.

In one embodiment, the transaction device 250 may provide the blockchain system 100 with a price range without revealing the actual value of the price using a zero knowledge range proof (e.g., as shown in fig. 5A-5D below). The range attestation can be generated by various schemes including, but not limited to, a bulletproof scheme and a bormomean (Borromean) ring signature scheme. For example, to prove that the price of one order is greater than the price of another order, the following points need to be proved: { w ═ (p)₁,r₁,p₂,r₂)，x＝(P₁,P₂)，R:P₁＝g^p1h^r1&P₂＝g^p2h^r2&p₁>p₂}. It can be converted (translate) into an equivalent formula: { w ═ P (Δ P ═ P)₁-p₂,Δr＝r₁-r₂)，x＝(ΔP＝P₁/P₂)，R:ΔP＝g^△ph^△r&ΔP>0, which corresponds to a zero knowledge range proof. Similarly, the transaction device 250 may also use the zero knowledge range proof to provide a range of quantities (e.g., as shown in fig. 5D and 6C below) without revealing the actual value of the quantity.

In one embodiment, the trading device 250 may use a zero knowledge proof of discrete logarithm knowledge to prove that the quantity in one order is the same as the quantity in another order (e.g., as shown in FIG. 6A below). This is because, in order to prove that the quantity in one order is the same as the quantity in another order, the following needs to be proved: { w ═ q, r₁,r₂),x＝(P₁,P₂),R:P₁＝g^qh^r1&P₂＝g^qh^r2}. Can convert it intoTo the equivalent formula: { w ═ Δ r ═ r₁-r₂,x＝ΔP＝P₁/P₂,R:ΔP＝h^ΔrIt corresponds to zero knowledge proof of discrete logarithm knowledge.

In one embodiment, the transaction device 250 may use a zero knowledge proof of discrete logarithm knowledge to demonstrate a linear relationship between the quantities (e.g., as shown in fig. 5C and 6B below). This is because, in order to prove a plurality of numbers of linear relationships, the following needs to be proved: { w ═ (q)₁,r₁,q₂,r₂,q₃,r₃),x＝(P₁,P₂,P₃),R:P₁＝g^q1h^r1&P₂g^q2h^r2&P₃＝g^q3h^r3,q₃＝q₁+q₂}. This can be converted into: { w ═ Δ r ═ r₁+r₂-r₃,x＝ΔP＝P₁*P₂/P₃,R:h^△rΔ P, which corresponds to a zero knowledge proof of discrete logarithm knowledge.

In one embodiment, the user may indicate a desired price (or price range) in the order and order matching may be performed at the price (or price range) indicated by the user, which may be referred to as limiting price order matching. The user may indicate the desired price in a purchase order or a sales order. Alternatively, the user may not indicate a desired price in a purchase order or a sales order, and order matching may be performed at a market price, and this may be referred to as market price order matching. In one embodiment, for a purchase order, the market price may be the lowest price listed in the sales order in the order book when the order matches. In one embodiment, for a sales order, the market price may be the highest price listed in the purchase order in the order book when the order matches.

Fig. 5A-5D are diagrams illustrating matching of a qualified price order according to an embodiment. Referring to FIG. 5A, in one embodiment, a new purchase order (ID #5) is received by the trading device 250 with the order book 400 at 09: 10. The new order includes a price of $20.19 and a quantity of 100. In addition to the quantity andactual value of price, the new purchase order further comprising a quantity of Pedeleson commitments PC (q)₅,r'₅) Peterson commitment to price PC (p)₅,r₅). For order matching purposes, the new order may be temporarily inserted between the #4 purchase order and the #3 purchase order in descending order of price and represented as #5 order ID in the updated order book 510. In this embodiment, the price of the new purchase order does not match any sales orders in the order book because the prices of both the #1 sales order and the #2 sales order are above $ 20.19. The result of the order match is "no match". The transaction device 250 may verify by uploading a zero knowledge range: (1) p is a radical of₅-p₃>0; and (2) p₄-p₅The ≧ 0 request blockchain system 100 confirms the order match result ("no match"). Once the blockchain system 100 confirms that the order match result is valid, the trading device 250 may update the order book 400 by inserting the #5 purchase order into the order book 400, as shown in fig. 5A.

Referring to FIG. 5B, in another embodiment, a transaction device 250 having an order book 400 receives a new purchase order in which a buyer wishes to purchase 100 quantities of merchandise at a price rate of $ 20.25. This new order may exactly match the #2 sales order in the order book 400 (FIG. 4) as compared to the sales order in the order book 400. The result of the order match is a "perfect match with a sales order". The transaction device 250 may request the blockchain system 100 to confirm the order match and upload a zero knowledge range certificate: p is a radical of₅-p₂Zero knowledge proof of > 0 and discrete logarithm knowledge: q. q.s₅＝q₂. Once the blockchain system 100 confirms that the order match result is valid, the trading device 250 may update the order book 400 by removing the #2 sales order from the order book 400, as shown by the updated order book 520 in FIG. 5B. In one embodiment, after confirming that the order match result is valid, the blockchain system may further perform settlement so that assets may be transferred.

Referring to FIG. 5C, in another embodiment, a new purchase order is received by the transaction device 250 having an order book 400, wherein the buyer wishes to purchase at a $20.30 unit priceA quantity of 200 items is purchased. The new purchase order may exactly match the combination of #1 and #2 sales orders in the order book 400, as compared to the sales orders of the order book 400 (FIG. 4). The result of the order match is a "perfect match with multiple sales orders". The transaction device 250 may request the blockchain system 100 to confirm the order match and upload a zero knowledge range certificate: p is a radical of₅-p₁Is ≧ 0 (which also means p₅-P₂≧ 0) and zero knowledge proof of discrete logarithm knowledge: q. q.s₅＝q₂+q₁. Once the blockchain system 100 confirms that the order match result is valid, the trading device 250 may update the order book 400 by removing both the #1 sales order and the #2 sales order from the order book 400, as shown by the updated order book 530 in FIG. 5C. In one embodiment, after confirming that the order match is valid, the blockchain system may further perform settlement so that assets may be transferred.

Referring to FIG. 5D, in another embodiment, the transaction device 250 with the order book 400 receives a new purchase order in which the buyer wishes to purchase 50 quantities of merchandise at a price rate of $ 20.26. The new purchase order may be partially matched to the #2 sales order in the order book 400 (FIG. 4) as compared to the sales order in the order book 400. The result of the order match is a "partial match to a sales order". The transaction device 250 may request the blockchain system 100 to confirm the order match and upload a zero knowledge range certificate: p is a radical of₅-p₂Not less than 0 and q₂-q₅>0. Once blockchain system 100 confirms that the order match result is valid, the trading device 250 may update the order book 400 by changing the quantity in the #2 sales order in the order book 400 from 100 to 50, as shown by the updated order book 540 in FIG. 5D.

For simplicity, fig. 5A-5D only show examples of qualifying price order matches, where only a purchase order is newly received. However, a similar matching method may be applied to the case where a new sales order, multiple purchase orders, or multiple sales orders are newly received by the trading device 250. In one embodiment, the transactional device 250 may receive a mix of one or more purchase orders and one or more sales orders. The trading device 250 may process one or more new purchase orders and one or more new sales orders based on the price-time priority of the new orders. In one embodiment, the trading device 250 may process new orders one by one based on the arrival time of the new orders. In another embodiment, new orders may arrive at the same time. In this case, the transactional device 250 may compare the new order with any other new orders, and may also compare the new order with orders listed in the order book 400. For example, if the transactional device 250 receives a new purchase order and a new sales order at the same time, the transactional device 250 may compare the new purchase order to the new sales order and may also compare the new purchase order to the sales orders listed in the order book 400.

In the above description of fig. 5A-5D, upon requesting the blockchain system 100 to confirm the order matching result, the trading device 250 may upload at least one of the following to the blockchain system 100: (1) a range of prices warrant; (2) range of amounts justification; (3) equality between the two numbers; or (4) a linear relationship between the plurality of quantities. In this manner, one or more nodes of the blockchain system 100 can verify the validity of the order matching results without knowing or revealing the actual values of the price and quantity, thereby enhancing the security and fairness of the transaction.

Fig. 6A to 6C are diagrams illustrating market price order matching according to an embodiment. Market price order matching may be performed based on the best market price at which the orders match. For new purchase orders, the best market price may be the lowest price among the sales orders listed in order book 400 at the time the order match was made. For new sales orders, the optimal market price may be the highest price among the purchase orders listed in the order book 400 when the orders match. In one embodiment, for a new purchase order, if the quantity in the lowest price sales order is less than the quantity in the new purchase order, the second lowest price sales order may be considered. Since market price order matching is performed based on the prices listed in the order book 400, there is no need to upload zero knowledge range proofs about price information to the blockchain system 100 to confirm order matching. The transaction device 250 may upload only zero knowledge range credentials for the quantity information to the blockchain system 100.

Referring to FIG. 6A, in one embodiment, a new purchase order is received by the trading device 250 having an order book 400, wherein a buyer wishes to purchase 100 quantities of a good at a market price. This new purchase order may exactly match the #2 sales order in the order book 400 (FIG. 4) as compared to the sales order in the order book 400. The result of the order match is a "perfect match with a sales order". The transaction device 250 may request the blockchain system 100 to confirm the order match and upload a zero-knowledge proof of discrete logarithm knowledge: q. q.s₅＝q₂. Once the blockchain system 100 confirms that the order match is valid, the transactional device 250 may update the order book 400 by removing the #2 sales order from the order book 400, as shown by the updated order book 610 in FIG. 6A. In one embodiment, after confirming that the order match is valid, the blockchain system may further perform settlement so that assets may be transferred.

Referring to FIG. 6B, in another embodiment, a new purchase order is received by the trading device 250 having an order book 400, wherein a buyer wishes to purchase 200 quantities of a good at a market price. The new purchase order may exactly match the combination of the #2 sales order and the #1 sales order in the order book 400 as compared to the sales orders in the order book 400 (FIG. 4). The result of the order match is a "perfect match with multiple sales orders". The transaction device 250 may request the blockchain system 100 to confirm the order match and upload a zero-knowledge proof of discrete logarithm knowledge: q. q.s₅＝q₂+q₁. Once the blockchain system 100 confirms that the order match is valid, the trading device 250 may update the order book 400 by removing both the #2 sales order and the #1 sales order from the order book 400, as shown by the updated order book 620 in FIG. 6B. In one embodiment, after confirming that the order match is valid, the blockchain system may further perform settlement so that assets may be transferred.

Referring to FIG. 6C, in another embodiment, there is an order book 400 receives a new purchase order in which the buyer wishes to purchase 50 quantities of the good at the market price. The new purchase order may be partially matched to the #2 sales order in the order book 400 (FIG. 4) as compared to the sales order in the order book 400. The result of the order match is a "partial match to a sales order". The transaction device 250 may request the blockchain system 100 to confirm the order match and upload a zero knowledge range certificate: q. q.s₂-q₅>0. Once the blockchain system 100 confirms that the order match is valid, the transactional device 250 may update the order book 400 by changing the quantity in the #2 sales order in the order book 400 from 100 to 50, as shown by the updated order book 630 in FIG. 6C. In one embodiment, after confirming that the order match is valid, the blockchain system may further perform settlement so that assets may be transferred.

For simplicity, fig. 6A-6C only show examples of market price order matching, where only a purchase order is newly received. However, a similar matching method may be applied to the case where the trading device 250 receives a new sales order, multiple purchase orders, or multiple sales orders. In one embodiment, the transactional device 250 may receive a mix of one or more purchase orders and one or more sales orders. The trading device 250 may process one or more new purchase orders and one or more new sales orders based on the price-time priority of the new orders. In one embodiment, the trading device 250 may process new orders one by one based on the arrival time of the new orders. In another embodiment, new orders may arrive at the same time. In this case, the transactional device 250 may compare the new order with any other new orders and orders in the order book 400. For example, if the transactional device 250 receives a new purchase order and a new sales order at the same time, the transactional device 250 may compare the new purchase order to the sales orders listed in the new sales order and order book 400.

In the above description of fig. 6A-6C, upon requesting the blockchain system 100 to confirm the order matching result, the trading device 250 may upload at least one of the following to the blockchain system 100: (1) range of amounts justification; (2) equality between the two numbers; or (3) a linear relationship between the plurality of quantities. In this manner, one or more nodes of the blockchain system 100 can verify the validity of the order matching results without knowing or revealing the actual values of the price and quantity, thereby enhancing the security and fairness of the transaction.

In one embodiment, the trading device may upload commitments for prices and quantities in the orders (e.g., the peterson commitment) to the blockchain system along with a request to confirm the results of the order match. In one embodiment, a user placing an order may identify the order from a commitment and verify the validity of the order matching results on the client of the blockchain system.

In one embodiment, the order matching results and transaction data used in order matching may be investigated by the regulatory body. The regulatory body may request that the trading device provide the parameters (p, q, r, r') used in order matching. The regulatory authority may determine g calculated using the provided parameters^ph^rWhether the value is equal to the PC (p, r) value uploaded to the blockchain system, and determining g calculated using the provided parameters^qh^rWhether the 'value is equal to the PC (q, r') value uploaded to the blockchain system to ensure correctness of the original transaction data. The regulatory authority may further verify the validity of the order match using the methods described in fig. 5A-5D and fig. 6A-6C.

Fig. 7 is a schematic diagram illustrating a method 700 for order matching, according to an embodiment. A user 210 (e.g., buyer) can create an account in the blockchain system 100 and upload a purchase order to the blockchain system 100 (step 702). For example, the user 210 may upload a purchase order having a data structure of { "type": purchase, "price": PC (p, r), "quantity": PC (q, r') }, where PC is a Peterson promise. In one embodiment, the user 210 may encrypt p, q, r' of the purchase order using the public key of the exchange 250 or exchange and attach it as a payload to the order submission transaction and upload it to the blockchain system (step 702). Alternatively, in another embodiment (not shown), the user 210 may send the purchase order directly to the trading device 250 without uploading it to the blockchain system 100.

Similarly, a user 230 (e.g., a seller) may create an account in the blockchain system 100 and upload a sales order to the blockchain system (step 704). For example, the user 230 may upload a sales order having a data structure of { "type": sales, "price": PC (p, r), "quantity": PC (q, r') }, where PC is a Peterson commitment. In one embodiment, the user 230 may encrypt p, q, r' of the sales order using the public key of the trading device 250 or exchange and attach it as a payload to the order submission transaction and upload to the blockchain system (step 704). Alternatively, in another embodiment (not shown), the user 230 may send the sales order directly to the trading device 250.

The blockchain system 100 may broadcast the uploaded order (step 706). The transaction device 250 may receive the broadcasted order, decrypt the encrypted p, q, r, and r' using the private key, and confirm the correctness of the order data (step 708). The transaction device 250 may further perform order matching (step 710). For example, the trading device 250 may perform a qualified price order match (as shown in fig. 5A-5D) or a market price order match (as shown in fig. 6A-6C) depending on whether the user indicates a desired price. To request confirmation of a qualified price order match, the trading device 250 may upload at least one of the following to the blockchain system 100: a proof of a range of prices, a proof of a range of quantities, an equality between two quantities or a linear relationship between a plurality of quantities. For example, the transaction device 250 uploads a zero knowledge range proof of the price p and a zero knowledge range proof of the quantity q (step 712). To request confirmation of a market price match, the trading device 250 may upload at least one of the following to the blockchain system 100: a range of numbers demonstrates, an equality relationship between two numbers, or a linear relationship between multiple numbers. For example, the transaction device 250 uploads a zero knowledge range proof of quantity q (step 714). After receiving the uploaded information from the transactional device 250, the blockchain system 100 may perform a confirmation of the order match by comparing the results of the order match to the uploaded data (step 716). Once the order match is confirmed to be valid, the blockchain system 100 may broadcast the confirmation result (step 718), and the transactional device 250 may receive the broadcasted confirmation result (step 720). The transactional device 250 may further update the order book used in order matching (step 722) to reflect the changes that occurred as a result of the order matching. The user 210 may also receive the broadcasted confirmation results to let the user know the status of the placed purchase order (step 724). Similarly, the user 230 may also receive the broadcasted confirmation result so that the user knows the status of the placed sales order (step 726).

In one embodiment, the blockchain system in which the user uploads the order may be the same or different than the blockchain system in which the order being executed by the trading device 250 is confirmed to match.

Fig. 8 is a flow diagram of a method 800 for order matching according to an embodiment. The method 800 may be performed by a transaction device in an exchange, such as the transaction device 250 (fig. 2). Referring to FIG. 8, a trading device may receive a purchase order and a sales order (step 802). In one embodiment, the transaction facility may receive purchase orders and sales orders directly from buyers and sellers. In another embodiment, the trading device may receive purchase orders and sales orders from broadcasts from a blockchain system, such as blockchain system 100 (fig. 1).

Upon receiving the purchase order and the sales order, the trading device may perform order matching (step 804). In one embodiment, the trading device may perform order matching based on the price and quantity indicated in the purchase order or sales order, and this may be referred to as qualified price order matching (fig. 5A-5D). In another embodiment, the purchase order or the sales order may not indicate the desired price, and the transactional device may perform order matching based on the best market price when order matching is made, and this may be referred to as market price order matching (fig. 6A-6C).

After order matching is performed, the transactional device may upload the results and proofs to a blockchain system, such as blockchain system 100 (fig. 1), to request that the blockchain system confirm the order matching results. The transaction device may upload some proofs (e.g., zero knowledge range proofs, zero knowledge proofs of discrete logarithm knowledge) so that the nodes of the blockchain system can verify the validity of the order match without knowing the actual values of the price and quantity (step 806). For example, with respect to qualifying price order matching, the trading device may provide at least one of: a proof of a range of prices, a proof of a range of quantities, an equality between two quantities or a linear relationship between a plurality of quantities. With respect to market price order matching, the trading device may only provide at least one of: a range of numbers demonstrates, an equality relationship between two numbers, or a linear relationship between multiple numbers.

The order match result may be confirmed by one or more nodes in the blockchain system, and the transaction device may receive the confirmation result directly from the blockchain system or through a broadcast of the blockchain system (step 808). If the order match result is validated by the blockchain system, the transactional device may further update the order book used in the order match to reflect the changes that occurred due to the order match (step 810).

Fig. 9 is a schematic diagram of an apparatus 900 for order matching according to an embodiment. Apparatus 900 may be an implementation of a software process and may correspond to method 800 (fig. 8). As shown in fig. 9, apparatus 900 may include a receiving module 810, a matching module 920, a requesting module 930, and an updating module 940.

The receiving module 910 receives a purchase order from a buyer and a sales order from a seller. The matching module 920 analyzes the purchase order and the sales order and performs order matching. The request module 930 requests the blockchain system to confirm the order matching result and uploads the relevant data to the blockchain system. Once the apparatus 900 receives the confirmation result from the blockchain system, the update module 940 updates the order book used in the order matching to reflect the changes due to the order matching.

Each of the above modules may be implemented as software or hardware, or a combination of software and hardware. For example, each of the above modules may be implemented using a processor executing instructions stored in a memory. Further, for example, each of the above-described modules may be implemented using one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic components to perform the described methods. Further, each of the above-described modules may be implemented by using a computer chip or an entity, or by using a product having a specific function, for example. In one embodiment, the apparatus 900 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email messaging device, a game console, a tablet, a wearable device, or any combination of these devices.

For the implementation process of the functions and roles of the respective modules in the apparatus 900, reference may be made to the corresponding steps in the previous method. Details are omitted here for simplicity.

In some embodiments, a computer program product is also provided. The computer program product may include a non-transitory computer readable storage medium having computer readable program instructions thereon for causing a processor to perform the above-described method.

The computer readable storage medium may be a tangible device that may store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device such as a punch card or a raised pattern in a recess having instructions recorded thereon, and any suitable combination of the foregoing.

The computer-readable program instructions for performing the methods described above may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language and a conventional procedural programming language. The computer-readable program instructions may execute entirely on the computing device as a stand-alone software package, or may execute partially on a first computing device and partially on a second computing device remote from the first computing device. In the latter case, the second remote computing device may be connected to the first computing device over any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer-readable program instructions may be provided to a processor of a general purpose or special purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the methods described above.

The flowcharts and diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments herein. In this regard, a block in the flowchart or diagram may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing the specified function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the diagrams and/or flowchart illustration, and combinations of blocks in the diagrams and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features which are, for clarity, described herein in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination, or as suitable in any other described embodiment herein. Unless otherwise specified, certain features described in the context of various embodiments are not essential features of those embodiments.

While the present disclosure has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the following claims are intended to embrace all such alternatives, modifications and variances which fall within the scope of the claims.

Claims

1. A computer-implemented method for transaction matching, the method comprising:

receiving one or more transactions;

determining at least one of: a match between the one or more transactions and a stored data structure, or a match between one transaction of the one or more transactions and another transaction;

sending a request for confirming the determination result to the blockchain system; and

updating the stored data structure in response to the blockchain system confirming that the determination is valid.

2. The method of claim 1, wherein the one or more transactions are received from a broadcast of the blockchain system or from a broadcast of another blockchain system different from the blockchain system.

3. The method of claim 1, wherein the one or more transactions are received from one or more user interface devices.

4. The method of any preceding claim, wherein the one or more transactions comprise at least one of:

one or more purchase orders;

one or more sales orders; or

One or more purchase orders and one or more sales orders.

5. The method of any preceding claim, wherein each of the received one or more transactions comprises at least one of:

the type of transaction,

Promise of price,

A commitment of a quantity,

The price encrypted by the encryption key,

The number of encryptions by the encryption key,

A random number for generating a commitment of said price and encrypted by said encryption key, or

A random number for generating the commitment of the number and encrypted by the encryption key.

6. The method of claim 5, wherein the commitment to the price is a Pedessen commitment to the price, and the commitment to the quantity is a Pedessen commitment to the quantity.

7. The method of any preceding claim, wherein at least one of: a match between the one or more transactions and the stored data structure, or a match between one transaction of the one or more transactions and another transaction, is performed based on at least one price included in the one or more transactions.

8. The method of any of claims 1 to 6, wherein at least one of: a match between the one or more transactions and the stored data structure, or a match between one transaction of the one or more transactions and another transaction, is performed based on:

one or more lowest prices of one or more sales orders included in the stored data structure; or

One or more highest prices in one or more purchase orders included in the stored data structure.

9. The method of claim 7 or 8, wherein sending the request to the blockchain system for confirmation of the determination further comprises:

uploading to the blockchain system at least one of:

range certification of prices in the matching transaction;

a range attestation of a quantity in the matching transaction;

an equality between two quantities in the matching transaction; or

A linear relationship between the plurality of quantities in the matching transaction.

10. The method of claim 9, wherein:

the proof of extent of the price in the matching transaction and the proof of extent of the quantity in the matching transaction are both based on a zero knowledge extent proof, an

The equality relationship between two of the numbers in the matching transaction and the linear relationship between the numbers in the matching transaction are both based on zero knowledge proof of discrete logarithm knowledge.

11. The method of any preceding claim, further comprising:

verifying validity of the determination on one or more nodes of the blockchain system based on the request to confirm the determination.

12. An apparatus for matching one or more transactions, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-11.

13. An apparatus for matching one or more transactions, the apparatus comprising a plurality of modules for performing the method of any one of claims 1 to 11.

14. A non-transitory computer readable medium having stored thereon instructions that, when executed by a processor of a device, cause the device to perform the method of any one of claims 1-11.