Managing transactions on blockchain networks

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for managing transactions on a blockchain network are disclosed herein. One of the methods includes a scheduling device on a blockchain network obtaining transaction data including a plurality of original pending transactions to be executed between a plurality of accounts on the blockchain network, the transaction data being stored on the blockchain network. The scheduling device performs a consolidation analysis of the plurality of original pending transactions to determine a plurality of modified pending transactions between the plurality of accounts, and a number of the plurality of modified pending transactions is less than a number of the plurality of original pending transactions. The scheduling device maintains the plurality of original pending transactions with the plurality of modified pending transactions without updating the transaction data stored on the blockchain network with the plurality of modified pending transactions.

Description

Technical Field

[0001] This article deals with managing transactions on a blockchain network. Background Technology

[0002] Distributed ledger systems (DLS), also known as consensus networks and / or blockchain networks, enable participating entities to store data securely and immutably. Without referencing any specific use case, DLS is generally referred to as a blockchain network. Examples of blockchain network types can include public blockchain networks, private blockchain networks, and consortium blockchain networks. Consortium blockchain networks are provided for a selected group of entities that control the consensus process, and these networks include an access control layer.

[0003] In a peer-to-peer distributed network, users transact with each other. Transactions are typically stored in the network's distributed ledger. In some cases, the number of transactions can accumulate to such a large extent that it impacts the overall network performance, and the required storage space grows exponentially.

[0004] Therefore, it is desirable to manage transactions between users effectively and securely on a blockchain network. Summary of the Invention

[0005] This article describes techniques for managing transactions on blockchain networks. These techniques typically involve managing transactions between users on a blockchain network through scheduler nodes. Scheduler nodes can perform merge analysis on the original pending transactions to generate a smaller number of modified pending transactions, and submit the modified pending transactions associated with a specific user to the Settlement Account Management (SAM) server for settlement (or execution). This technique can help reduce the number of actual settlement transactions, allowing the blockchain network to handle a large volume of transactions while using blockchain technology to provide trust for each user and integrity for each transaction.

[0006] This document also provides one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

[0007] This document also provides a system for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to and having instructions stored thereon on the one or more processors, the instructions, when executed by the one or more processors, causing the one or more processors to perform the operations described in the embodiments of the methods provided herein.

[0008] It should be understood that the methods described herein may include any combination of the aspects and features described herein. That is, the methods described herein are not limited to the combinations of the aspects and features specifically described herein, but also include any combination of the aspects and features provided.

[0009] Details of one or more embodiments herein will be set forth in the accompanying drawings and the following description. Other features and advantages of this document will become apparent from the description, the drawings, and the claims. Attached Figure Description

[0010] Figure 1 This is a diagram illustrating an example of an environment that can be used to perform the embodiments described herein.

[0011] Figure 2 This is a diagram illustrating an example of an architecture according to an embodiment of this document.

[0012] Figure 3 This is a diagram illustrating an example of a trading system according to embodiments of this document.

[0013] Figure 4 A diagram illustrating a merger transaction as described in an embodiment of this document is shown.

[0014] Figure 5 This is a transaction flow that illustrates an example of the processing that can be performed according to the embodiments described herein.

[0015] Figure 6 This is a flowchart illustrating a process that can be performed according to the embodiments described herein.

[0016] Figure 7 Examples of modules of an apparatus according to embodiments of this document are depicted.

[0017] In the various figures, the same reference numerals and names denote the same elements. Detailed Implementation

[0018] This article describes techniques for managing transactions in blockchain networks. These techniques typically involve managing transactions between users on a blockchain network through scheduler nodes. Scheduler nodes can perform merge analysis on the original pending transactions to generate a smaller number of modified pending transactions, and submit the modified pending transactions associated with a specific user to a Settlement Account Management (SAM) server for settlement (or execution). This technique can help reduce the number of actual settled transactions, allowing the blockchain network to handle a large volume of transactions while using blockchain technology to provide trust for each user and integrity for each transaction.

[0019] The technologies described herein produce several technical effects. In some embodiments, these technologies can be applied to blockchain payment networks or distributed payment networks, where the number of actual settlement transactions can be reduced, and lending relationships can be preserved and endorsed through blockchain technology. In some embodiments, these technologies can also be applied to cross-border remittances, inter-institutional remittances, personal digital wallets, and value-added services related to digital asset management.

[0020] In some embodiments, these technologies can reduce or minimize the total transaction flow in the network while achieving consensus among all users to maintain the correct balance and process each transaction with a consolidated amount. In some embodiments, these technologies can reduce or minimize the number of actual settled transactions while keeping the number of original pending transactions unchanged, which can provide better compatibility with other payment networks or digital asset management networks. In some embodiments, the scheduler node can be a non-consensus node of the blockchain network. The scheduler node does not submit modified pending transactions to the blockchain network and can avoid performing consensus processing on modified pending transactions in the blockchain network, thereby reducing operating costs and improving the efficiency of the blockchain network. Furthermore, since the number of modified pending transactions is less than the number of original pending transactions, the number of actual settled transactions is reduced, and the number of settlement entries to be stored in the blockchain network is also reduced. This also avoids increasing storage space in the blockchain network.

[0021] In some embodiments, these technologies allow the storage of settlement entries for original pending transactions and / or actual settled transactions within a blockchain on a blockchain network. Thus, the blockchain network can have a complete transaction graph for users (e.g., participants or accounts) within the blockchain network. In some embodiments, consensus nodes associated with users (e.g., customer bank nodes) can store a complete copy of the blockchain. The blockchain network includes scheduler nodes to perform merging of original pending transactions, and the blockchain network can achieve consensus among users to maintain correct balances and execute each transaction with the merged amount. The blockchain network can also provide verification services to users by using the stored settlement entries for original pending transactions and actual settled transactions. Therefore, these technologies can ensure correct balances in the distributed ledger and provide trusted and provable transactions.

[0022] In some embodiments, the scheduler node synchronizes with the blockchain network to receive transfer requests from client devices associated with users. Therefore, the scheduler node can perform real-time and dynamic merging of original pending transactions. The scheduler node can also synchronize with the blockchain network to receive settlement queries and / or settlement requests from specific users. The scheduler node can respond to settlement queries by providing merged settlement information to the specific user, or by sending a SAM settlement request to the SAM server to execute at least one modified transaction associated with that specific user. Thus, the blockchain network can dynamically process large volumes of transactions in a decentralized manner.

[0023] In some embodiments, a scheduling application programming interface (API) may be provided to client devices associated with a user. Client devices can use the scheduling API to send transfer requests, transfer queries, settlement queries, and / or settlement requests to nodes in the blockchain network. In some embodiments, the blockchain API may be provided to nodes for reading / writing transaction entries and / or reading blocks. In some embodiments, the settlement consolidation API may be provided to the SAM server to receive settlement requests and provide responses. These APIs can help reduce overall transaction costs.

[0024] To provide further background for the embodiments described herein, as mentioned above, a distributed ledger system (DLS), also known as a consensus network (e.g., composed of peer-to-peer nodes) and a blockchain network, enables participating entities to securely and immutably transact and store data. While the term blockchain is often associated with specific networks and / or use cases, in this document, blockchain generally refers to DLS without reference to any particular use case.

[0025] A blockchain is a data structure that stores transactions in an immutable manner. Therefore, transactions recorded on a blockchain are reliable and trustworthy. A blockchain consists of one or more blocks. Each block in the chain is linked to the preceding block by a cryptographic hash contained within it. Each block also includes a timestamp, its own cryptographic hash, and one or more transactions. Transactions verified by nodes in the blockchain network are hashed and encoded into a Merkle tree. A Merkle tree is a data structure where data at the leaf nodes of a tree is hashed, and all hashes in each branch of the tree are concatenated at the root of the branch. This process continues along the tree to the root, where hashes representing all data in the tree are stored. A hash can be quickly verified by determining whether the hash of a transaction claiming to be stored in the tree matches the tree's structure.

[0026] A blockchain is a decentralized or at least partially decentralized data structure used to store transactions, and a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains through broadcasting, verifying, and confirming transactions. As mentioned above, blockchain networks can be provided as public blockchain networks, private blockchain networks, or consortium blockchain networks. The embodiments described herein are further described in detail with reference to consortium blockchain networks. However, it is contemplated that the embodiments described herein can be implemented in any suitable type of blockchain network.

[0027] Typically, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, which may be referred to as consensus nodes, and one or more consensus nodes are operated by the respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node in the consortium blockchain network.

[0028] In some examples, in consortium blockchain networks, a global blockchain is provided as a blockchain replicated across all nodes. That is, all consensus nodes are in a state of complete consensus relative to the global blockchain. To reach consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented within the consortium blockchain network. For example, a consortium blockchain network can implement Practical Byzantine Fault Tolerance (PBFT) consensus, which will be described in further detail below.

[0029] Figure 1 This is a diagram illustrating an example of an environment 100 that can be used to perform embodiments of this document. In some examples, environment 100 enables entities to participate in a consortium blockchain network 102. Environment 100 includes computing devices 106, 108 and network 110. In some examples, network 120 includes a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 120 can be accessed via wired and / or wireless communication links. In some examples, network 110 enables communication with and within the consortium blockchain network 102. Typically, network 110 represents one or more communication networks. In some cases, computing systems 106, 108 may be nodes of a cloud computing system (not shown), or each computing system 106, 108 may be a separate cloud computing system comprising multiple computers interconnected via a network and used as a distributed processing system.

[0030] In the depicted examples, computing systems 106 and 108 may each include any suitable computing device capable of participating as a node in the consortium blockchain network 102. Example computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smartphones. In some examples, computing devices 106 and 108 carry one or more computer-implemented services for interacting with the consortium blockchain network 102. For example, computing device 106 may carry a service implemented by a first entity's (e.g., user A), such as a transaction management system, which the first entity uses to manage its transactions with one or more other entities (e.g., other users). Computing device 108 may carry a service implemented by a second entity's (e.g., user B), such as a transaction management system, which the second entity uses to manage its transactions with one or more other entities (e.g., other users). Figure 1 In the example, the consortium blockchain network 102 is represented as a peer-to-peer network of nodes, and computing systems 106 and 108 provide nodes for the first and second entities participating in the consortium blockchain network 102, respectively.

[0031] Figure 2 This is a diagram illustrating an example of architecture 200 according to embodiments of this document. The exemplary conceptual architecture 200 includes participant systems 202, 204, and 206, respectively corresponding to participant A, participant B, and participant C. Each participant (e.g., a user, enterprise) participates in a blockchain network 212 provided as a peer-to-peer network, which includes multiple nodes 214, at least some of which immutably record information in a blockchain 216. As further detailed herein, although a single blockchain 216 is schematically depicted in blockchain network 212, multiple copies of blockchain 216 are provided and maintained on blockchain network 212.

[0032] In the depicted example, each participant system 202, 204, and 206 is provided by or represents participants A, B, and C, respectively, and functions as their respective nodes 214 in the blockchain network. As used herein, a node typically refers to an individual system (e.g., a computer, a server) connected to the blockchain network 212 and enabling the corresponding participant to participate in the blockchain network. Figure 2In the example, a participant corresponds to each node 214. However, it is expected that a participant can operate multiple nodes 214 within the blockchain network 212, and / or multiple participants can share a single node 214. In some examples, participant systems 202, 204, 206 communicate with or through the blockchain network 212 using protocols (e.g., Hypertext Transfer Protocol Security (HTTPS)) and / or using Remote Procedure Calls (RPC).

[0033] Node 214 can have different levels of participation within the blockchain network 212. For example, some nodes 214 may participate in consensus processing (e.g., as mining nodes adding blocks to blockchain 216), while other nodes 214 may not participate in this consensus processing. As another example, some nodes 214 may store a complete copy of blockchain 216, while other nodes 214 may store only a partial copy of blockchain 216. For example, data access privileges can restrict the amount of blockchain data that a given participant can store within their respective system. Figure 2 In the example, participant systems 202, 204, and 206 store corresponding complete copies 216', 216”, and 216”' of blockchain 216.

[0034] Blockchain (e.g., Figure 2 A blockchain (216) consists of a series of blocks, each storing data. Examples of data include transaction data representing a transaction between two or more participants. Although this document uses the term "transaction" by way of non-limiting example, it is expected that any suitable data (e.g., documents, images, videos, audio) can be stored in the blockchain. Examples of transactions can include, but are not limited to, the exchange of goods of value (e.g., assets, products, services, currencies). Transaction data is stored immutably in the blockchain. That is, transaction data cannot be changed.

[0035] Before transaction data is stored in a block, it is hashed. Hashing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to dehash the hash value to obtain the transaction data. Hashing ensures that even slight changes to the transaction data will result in a completely different hash value. Furthermore, as mentioned above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. Hashing involves processing the transaction data using a hash function to generate a hash value. Examples of hash functions include, but are not limited to, the Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

[0036] Transaction data from multiple transactions is hashed and stored in a block. For example, two transactions are provided with hashes, and then they themselves are hashed to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in a block. This hash is called the Merkle root hash and is stored in the block header. Any change in a transaction will cause its hash to change, and ultimately, the Merkle root hash will change.

[0037] Blocks are added to the blockchain via a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and perform work to add blocks to the blockchain. Such nodes are called consensus nodes. PBFT, as described above, serves as a non-restricted example of a consensus protocol. Consensus nodes execute the consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

[0038] In more detail, consensus nodes generate a block header, hash all transactions within the block, and combine these hashes in pairs to generate further hashes until a single hash (the Merkle root hash) is provided for all transactions in the block. This hash is then added to the block header. Consensus nodes also determine the hash of the most recent block in the blockchain (i.e., the last block added to the blockchain). Consensus nodes also add a nonce value and a timestamp to the block header.

[0039] Typically, PBFT provides a practical Byzantine state machine replication that tolerates Byzantine errors (e.g., faulty nodes, malicious nodes). This is achieved by assuming failures will occur in PBFT (e.g., assuming independent node failures and / or manipulated messages sent by consensus nodes). In PBFT, consensus nodes are provided in a sequence including a primary consensus node and backup consensus nodes. The primary consensus node is changed periodically. Transactions are added to the blockchain by reaching consensus on the global state of the blockchain network among all consensus nodes within the blockchain network. In this process, messages are transmitted between consensus nodes, and each consensus node proves that the message was received from a designated peer node and verifies that the message has not been modified during transmission.

[0040] In PBFT, the consensus protocol is provided in multiple phases, assuming all consensus nodes start in the same state. First, the client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). In response to the received request, the primary consensus node multicasts the request to backup consensus nodes. The backup consensus nodes execute the request, and each node sends a reply to the client. The client waits until it receives a threshold number of replies. In some examples, the client waits until it receives f+1 replies, where f is the maximum number of faulty consensus nodes that the blockchain network can tolerate. The end result is that a sufficient number of consensus nodes agree on the order in which records are added to the blockchain, and the record is either accepted or rejected.

[0041] In some blockchain networks, cryptography is used to maintain transaction privacy. For example, if two nodes want to keep transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction, these two nodes can encrypt the transaction data. Examples of encryption include, but are not limited to, symmetric and asymmetric encryption. Symmetric encryption refers to the encryption process that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key can be used by multiple nodes, so each node can encrypt / decrypt the transaction data.

[0042] Asymmetric encryption uses key pairs, each consisting of a private key and a public key. The private key is known only to the corresponding node, while the public key is known to any or all other nodes in the blockchain network. A node can encrypt data using another node's public key, and that encrypted data can be decrypted using another node's private key. For example, refer again... Figure 2 Participant A can use Participant B's public key to encrypt data and send the encrypted data to Participant B. Participant B can use their private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using that node's private key.

[0043] Asymmetric encryption is used to provide digital signatures, which allows participants in a transaction to verify the other participants and the validity of the transaction. For example, a node can digitally sign a message, and another node can verify that the message was sent by participant A based on that digital signature. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, see again... Figure 2Participant A will send a message to Participant B. Participant A generates a hash value for the message and then encrypts the hash value using its private key to provide a digital signature as the encrypted hash. Participant A appends this digital signature to the message and sends the digitally signed message to Participant B. Participant B decrypts the digital signature using Participant A's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values ​​are the same, Participant B can confirm that the message did indeed originate from Participant A and has not been tampered with.

[0044] In some examples, transactions include the transfer, payment, management, or other types of operations on digital assets. A transaction can involve one or more participants (also referred to as entities or users). A blockchain can store transaction data that includes multiple transactions between multiple participants. In some embodiments, the status of a transaction (pending, authorized, or committed / executed) can also be recorded in the blockchain of the blockchain network. Because the number of transactions can accumulate to such a large extent that it affects the performance of the entire network, the required storage space grows exponentially. However, from a participant's perspective, he / she may only be concerned with the total amount debited or credited over a period of time, and not necessarily with, for example, where the money came from or went. In some cases, merging transactions related to a specific participant can address that participant's concerns.

[0045] Figure 3 This is a diagram illustrating an example of a system 300 according to embodiments of this document. The exemplary system 300 manages transactions in a blockchain network through dynamic transaction merging, which can minimize or otherwise reduce the total transaction flow in the blockchain network while achieving consensus among participants to maintain correct balances and execute each transaction with merged settlement.

[0046] In some embodiments, a transaction can be a joint or multi-party transaction between multiple users (or participants), and each user can be associated with a client device and / or a network node of the blockchain network (e.g., a client device executing client service logic and a blockchain network node executing smart contracts). As an example, system 300 includes a blockchain network 310 having: one or more blockchain network nodes (e.g., client bank nodes 312, 314, 316, 318 and transaction scheduler node 320), one or more client devices (e.g., client device 302 associated with user A, client device 304 associated with user B, client device 306 associated with user C, and client device 308 associated with user D), and a Settlement Account Management (SAM) server. Scheduler node 320 can be configured to manage transactions between users in blockchain network 310 and communicate with SAM server 330 for transaction settlement.

[0047] In some embodiments, blockchain network 310 is a consortium blockchain network that stores user-related transaction data in the blockchain. Client bank nodes 312, 314, 316, and 318 may be consensus nodes capable of storing a complete copy of the blockchain. Client devices 302, 304, 306, or 308 may include, for example, any suitable computer, module, server, or computing element programmed to perform the methods described herein. In some embodiments, client devices may include user devices such as personal computers, smartphones, tablets, or other handheld devices.

[0048] In some embodiments, each user is associated with a corresponding client device and a corresponding client bank node, and executes transactions with one or more other users through the corresponding client device and corresponding client bank node in the blockchain network. For example, users A, B, C, or D can use client devices 302, 304, 306, or 308 to communicate with corresponding client bank nodes 312, 314, 316, or 318 through a scheduling application programming interface (API) 305, while nodes 312, 314, 316, or 318 can communicate with the blockchain network 310 or other network nodes through the blockchain API 315.

[0049] In some embodiments, an API may include a set of subroutine definitions, communication protocols, and tools for building software, and may define the functionality provided by a program (module, library) and allow abstraction from the exact implementation of that functionality. Software components interact with each other via the API. As discussed in further detail below, the scheduling API 305 can implement functions for transferring transaction data, including transfer requests, transfer queries, settlement requests, or settlement queries. Users A, B, C, or D can use client devices 302, 304, 306, or 308 to send transaction data to the corresponding client bank nodes 312, 314, 316, or 318 via the scheduling API 305. Similarly, the blockchain API 315 can implement functions for reading or writing transaction data. Client bank nodes 312, 314, 316, or 318 can write transaction data to the blockchain through consensus processing, or can read transaction data or other transaction data from the blockchain via the blockchain API 315.

[0050] For example, user A might have an original pending transaction to transfer a certain number of units (e.g., 5 units) to user C. These units can be any transferable item, including currencies, stocks, bonds, derivatives, treasury bills, collateral, or any other item that is transferable. For illustrative purposes only, the US dollar ($) is used as an example unit herein. User A can send a transfer request to customer bank node 312 using client device 302, for example, A->C: $5. This transfer request corresponds to the original pending transaction and includes the amount or value associated with the original pending transaction, such as $5, and the identifier of one party, such as user A, and the identifier of the other party to the original pending transaction, such as user B. In some embodiments, after consensus processing has been performed among all consensus nodes of blockchain network 310, customer bank node 312 can, for example, write the original pending transaction corresponding to the transfer request to the blockchain via blockchain API 315. Similarly, user A can send a second transfer request, such as A->D: $15, to customer bank node 312 using client device 302. This customer bank node can then write the second original pending transaction corresponding to the second transfer request into the blockchain. User B can send a third and fourth transfer request associated with user B to customer bank node 314 using client device 304, such as B->C: $20 and B->D: $5. This customer bank node can write the third and fourth original pending transactions corresponding to the third and fourth transfer requests into the same blockchain. The original pending transactions can be represented or shown in the transaction graph, for example, as shown in... Figure 4 As shown in Figure (i).

[0051] In some embodiments, the blockchain network 310 sends a settlement request to the SAM server 330 to execute original pending transactions. The SAM server 330 may be a computing system comprising, for example, multiple computers interconnected via a network or locally, and serves as a processing system. The SAM server 330 is a centralized system that can be configured to execute multiple transactions from multiple entities, such as those comprising the blockchain network 310 or various banks. After executing a transaction, the SAM server 330 may send a confirmation message to the corresponding entity. The SAM server 330 may be located outside the blockchain network 310 and may be accessed via, for example... Figure 1 Network 110 communicates securely with blockchain network 310.

[0052] In one example, after receiving a client request from user A to authorize the settlement of an original pending transaction (e.g., A->C: $5), customer bank node 312 can send a settlement request to SAM server 330 to execute the original pending transaction. SAM server 330 can then execute the original pending transaction by transferring $5 from user A's bank account to user C's bank account. After SAM server 330 sends back a confirmation message confirming that the original pending transaction has been executed, customer bank node 302 can store the settlement entry along with the original pending transaction in the blockchain. The settlement entry indicates that the original pending transaction has been executed. If SAM server 330 has executed... Figure 4 All four original pending transactions shown in Figure (i) can generate four settlement entries and store them in the blockchain. That is, the number of settlement entries is the same as the number of original pending transactions.

[0053] In some embodiments, the blockchain network 310 includes a transaction scheduler node. The scheduler node 320 is configured to manage transactions in the blockchain network 310 and communicates with the SAM server 330, for example, via a settlement integration API 325. The settlement integration API 325 allows the SAM server 330 to receive settlement requests sent from the scheduler node 320 and send settlement responses, such as confirmation messages, to the scheduler node 320. The scheduler node 320 may be a computing system including one or more computers, for example... Figure 1 The computing device 106 or 108. The scheduler node 320 may differ from other client bank nodes 312, 314, 316, and 318. For example, the scheduler node 320 may be a non-consensus node and does not automatically store a complete copy of the blockchain storing transaction data. In some embodiments, unlike consensus nodes, non-consensus nodes in the blockchain network are network nodes that do not participate in the consensus protocol used to perform consensus processing with other network nodes in the blockchain network. In some embodiments, non-consensus nodes are not required to store a complete copy of the blockchain of the blockchain network.

[0054] In some embodiments, scheduler node 320 is configured to synchronize with blockchain network 310, such as with blockchain API 315, to obtain each of a plurality of transfer requests from a corresponding client device associated with a corresponding user. For example, after customer bank node 312 submits a transfer request (e.g., A->C: $5) from client device 302 associated with user A to blockchain network 310 via blockchain API 315, scheduler node 320 can obtain the transfer request from blockchain network 310 or blockchain API 315. In some embodiments, scheduler node 320 can accumulate transfer requests from different users and store them as original pending transactions associated with different users. Therefore, the original pending transactions stored in scheduler node 320 can be the same as the original pending transactions stored in the blockchain on blockchain network 310.

[0055] Scheduler node 320 is configured to perform a merge analysis on multiple original pending transactions to generate multiple modified pending transactions, with the number of modified pending transactions being less than the number of original pending transactions. Therefore, scheduler node 320 can perform the merge analysis to reduce the number of pending transactions while maintaining equivalence between the multiple original pending transactions and the multiple modified pending transactions. Since scheduler node 320 can send the modified pending transactions to SAM server 330 for execution, the number of transactions to be executed by SAM server 330 can be reduced. Scheduler node 320 sends settlement entries instructing transaction execution to blockchain network 310 for storage in the blockchain along with the original pending transactions. Therefore, with a reduced number of executed transactions, blockchain network 310 can store fewer settlement entries in the blockchain.

[0056] In some cases, scheduler node 320 may perform consolidation analysis on original pending transactions associated with a subgroup of users transacting in the blockchain network 310. For example, a subgroup of users may be associated with one or more specific customer bank nodes. In some cases, scheduler node 320 may perform consolidation analysis on original pending transactions that occurred over a period of time (e.g., one day, one week, or one month). In some cases, scheduler node 320 may dynamically perform consolidation analysis on original pending transactions when one or more new transfer requests are received. In some cases, scheduler node 320 may perform consolidation analysis on original pending transactions in response to a query received from a user requesting information on consolidated debts (or credits) that the user owns (or has).

[0057] In some embodiments, the scheduler node 320 performs a merge analysis using an optimization algorithm or any other algorithm on a debit-credit graph to reduce the total number of edges in the graph while maintaining the equivalence of the original and modified graphs. The optimization algorithm can be an algorithm for solving the Minimum Cost Flow Problem (MCFP) or a variant thereof. In some embodiments, such an algorithm may be referred to as a minimum cost flow algorithm. In an exemplary processing of the optimization algorithm, firstly, multiple original pending transactions are presented on the directed transaction graph. For example... Figure 4 As shown in Figure (i), transactions between users A, B, C, and D are displayed on the directed transaction graph, including four transfers: A->C: $5, A->D: $10, B->C: $20, and B->D: $5. Next, multiple modified pending transactions are identified by modifying the directed transaction graph using an optimization algorithm, and then represented on the modified transaction graph. For example... Figure 4 As shown in Figure (ii), the modified pending transactions consist of only two transfers: A->D: $15, B->C: $25, which, along with... Figure 4 The four transfers shown in Figure (i) are equivalent because A's combined borrowing is equal to D's combined loan, which is $15, and B's combined borrowing is equal to C's combined loan, which is $25.

[0058] The optimization algorithm can be described in detail here. First, the transfers on the directed transaction graph can be weighted using the borrowing of transactions. For example, the optimization function can be expressed as:

[0059] V = {v1, v2, ..., v} n} where v i This represents user i (participant or account);

[0060] E = { <v i v j >|v i v j in V}, where E represents a transfer or transaction between V;

[0061] W = {w ij >0| <v i v j >in E}, where w ij Indicates transaction <v i v j > Weight (or loan amount);

[0062] G =<V,E,W> Where G is a function of V, E, and W, and

[0063] The metric (G) = |E| = the number of edges in the graph, used to measure the number of transfers. Scheduler node 320 can perform a merge analysis by minimizing the metric (G). For example, Figure 4 The metric (G) of graph (i) in the graph is 4. After merging, Figure 4 The metric (G) of graph (ii) becomes 2.

[0064] Second, calculate the corresponding combined loan for each user across multiple users based on the following expression:

[0065] Debt(v i )=∑ x w ix -∑ y w yi .

[0066] Therefore, it is possible to calculate them separately. Figure 4 Figure (i) shows the combined loan of users A, B, C, and D in four transactions:

[0067] Debt(A) = 5 + 10 = 15

[0068] Debt(B) = 20 + 5 = 25

[0069] Debt(C) = -5 - 20 = 25

[0070] Debt(A) = -10 - 5 = -15

[0071] Third, multiple users can be divided into two groups: debits and creditors.

[0072] Debtors={A:15,B:25},

[0073] Creditors={C:-25, D:-15}

[0074] Then, the two groups can be sorted according to the loan amount:

[0075] Debtors={B:25,A:15},

[0076] Creditors={C:-25, D:-15}.

[0077] Fourth, these two groups of users can be matched based on their respective combined loans. For example, debits and credits with the same borrowing and lending amounts can be matched together as modified pending transactions, such as B->C: $25. The optimization algorithm can continue matching until no more matches are found between the two groups. The matching results can be collected to become modified pending transactions, such as B->C: $25 and A->D: $15. As mentioned above, modified pending transactions can be presented in a modified transaction graph, for example, as shown below. Figure 4 As shown in Figure (ii).

[0078] Scheduler node 320 is configured to utilize (or use) modified pending transactions to store and maintain original pending transactions. In some cases, scheduler node 320 is a non-consensus node and is configured not to provide modified pending transactions to blockchain network 310 via blockchain API 315 to update the blockchain storing transaction data including the original pending transactions. That is, transaction data in the blockchain is not updated using modified pending transactions, and there is no consensus processing among the various consensus nodes (e.g., client bank nodes 312, 314, 316, 318).

[0079] Scheduler node 320 can dynamically update modified pending transactions. Scheduler node 320 can receive new transfer requests corresponding to new original pending transactions. In some cases, scheduler node 320 does not store generated modified pending transactions, but instead stores settlement entries for original pending transactions and executed transactions. Scheduler node 320 can perform a new consolidation analysis on the stored original pending transactions and settlement entries, as well as the new original pending transaction, to generate a new modified pending transaction. In some cases, scheduler node 320 can use a new original pending transaction to modify one or more modified pending transactions to update the modified pending transaction. In some cases, scheduler node 320 can perform a new consolidation analysis on the stored modified pending transactions and the new original pending transaction to generate a new modified pending transaction.

[0080] As described above, scheduler node 320 can send modified pending transactions to the SAM server for execution. Once one of the modified pending transactions has been executed, for example, A->D:$15, scheduler node 320 can update the modified pending transaction by removing the executed modified pending transaction. Figure 4As shown in Figure (iii), the transfer A->D: $15 has been removed from the transaction graph, leaving only the remaining modified pending transactions, such as B->C: $25. Therefore, scheduler node 320 can store settlement entries indicating executed modified pending transactions along with the original pending transactions and other unexecuted modified pending transactions. Scheduler node 320 can also send settlement entries to blockchain network 310, which can store the settlement entries in the blockchain along with the original pending transactions.

[0081] Once all modified pending transactions have been executed, all transfers are removed from the transaction graph, such as... Figure 4 As shown in Figure (iv), the scheduler node 320 can store the corresponding settlement entry indicating the executed transaction along with the original pending transactions. The scheduler node 320 can then send the corresponding settlement entry to the blockchain network 310 for storage along with the original pending transactions. Since the number of modified pending transactions is less than the number of original pending transactions, the number of transactions executed by the SAM server 330 is reduced. Therefore, the blockchain network 310 can store fewer settlement entries in the blockchain compared to storing settlement entries for executing the original pending transactions.

[0082] In one example, as described above, for Figure 4 Figure (i) shows four original pending transactions. When these four original pending transactions are executed, four settlement entries are stored in the blockchain, resulting in a total of eight entries in the blockchain. In contrast, if the four original pending transactions are merged to generate two modified pending transactions, only two settlement entries will be stored in the blockchain when these two modified pending transactions are executed, resulting in a total of six entries in the blockchain, which is less than the eight entries required for executing the original pending transactions.

[0083] Blockchain network 310 can provide verification services to users. For example, user A can send a query to customer bank node 312 to check user A's settlement information, such as whether all loans associated with user A have been repaid. Blockchain network 310, such as customer bank node 312, can verify settlement information by analyzing settlement entries of original pending transactions and executed transactions stored in the blockchain. In some cases, blockchain network 310 can generate a loan transaction graph by analyzing original pending transactions and settlement entries. Blockchain network 310 can determine settlement information associated with user A by determining whether there are any remaining transfers associated with user A and presented in the transaction graph. For example, Figure (ii) shows that user A's consolidated loan is $15, while Figure (iii) or Figure (iv) shows that user A has no loan after executing the modified pending transactions associated with user A.

[0084] Figure 5 This is an example transaction flow illustrating a process 500 that can be performed according to embodiments of this document. Process 500 can be performed by... Figure 3 The system will execute a 300 error. For example... Figure 4 As shown in Figure (i), assume there are four original pending transactions: A->C: $5, A->D: $10, B->C: $20, and B->D: $5. For illustrative purposes only, process 500 is performed from user A's perspective.

[0085] First, user A sends a transfer request, A->C: $5, to the associated customer bank node 312 using the associated client device 302. Customer bank node 312 writes request entry 503, corresponding to transfer request 501, to the blockchain on blockchain network 310 via blockchain API 315. Scheduler node 320 synchronizes with blockchain network 310 and obtains request entry 503 from blockchain API 315. Both transfer request 501 and request entry 503 correspond to the original pending transaction, A->C: $5. Similarly, other transfer requests, A->D: $10, B->C: $20, and B->D: $5, can be received and written to the blockchain, and scheduler node 320 can be synchronized to receive other transfer requests.

[0086] Second, user A uses client device 302 to send settlement query 505 to client bank node 312. User A is associated with one or more original pending transactions, such as A->C: $5 and A->D: $10. The settlement query can request settlement information associated with user A, such as how much user A owes the blockchain network. An example of a settlement query can be represented as {A->Network: $?}. Scheduler node 320 can obtain settlement query 505 from blockchain network 310. For example, client bank node 312 can send settlement query 505 to blockchain API 315, which forwards settlement query 505 to scheduler node 320, or scheduler node 320 can be synchronized to receive and respond to settlement query 505. In some cases, client device 302 sends settlement query 505 directly to scheduler node 320 via scheduling API 305.

[0087] Third, scheduler node 320 determines the consolidated settlement associated with user A through borrowing determination process 504. Scheduler node 320 maintains real-time transaction data, which includes all original pending transactions associated with users including user A, as well as settlement entries for executed transactions. In some cases, in response to receiving a settlement query 505, scheduler node 320 can perform a consolidation analysis on the original pending transactions and settlement entries to generate modified pending transactions, such as B->C: $25 and A->D: $15. Scheduler node 320 can then obtain the consolidated settlement associated with user A from at least one modified pending transaction associated with user A (e.g., A->D: $15). In some cases, real-time transaction data includes modified pending transactions updated in real-time. Scheduler node 320 can identify at least one modified pending transaction associated with user A from the real-time updated modified pending transactions and determine the consolidated settlement for user A. In some cases, scheduler node 320 can identify at least one original pending transaction and / or at least one settlement entry associated with user A from the stored original pending transactions, and calculate the consolidated settlement based on the original pending transactions and settlement entries associated with user A.

[0088] Fourth, scheduler node 320 sends query response 507 to client device 302 associated with user A. Query response 507 may include a consolidated settlement associated with user A, such as $15. Query response 507 may include an optimized transfer, which can be represented as: {A->Network:$15}. That is, the optimized transfer may only show that A owes the blockchain network $15, without disclosing the modified pending transactions associated with user A, for example, A->D:$15. In some cases, scheduler node 320 sends query response 507 directly to client device 302. In other cases, scheduler node 320 sends query response 507 to client bank node 312 or blockchain network 310, which then provides query response 507 to client device 302.

[0089] Fifth, the client device 302 associated with user A sends a settlement request 509 to the scheduler node 320, for example, through the client bank node 312 or the blockchain network 310. The settlement request 509 instructs user A to authorize the execution of a settlement for user A. The settlement request 509 can be represented as an optimized transfer: {A->Network:$15}. That is, user A authorizes a consolidated settlement payment of $15 to the blockchain network 310.

[0090] Sixth, in response to receiving settlement request 509, scheduler node 520 sends SAM settlement request 511 to SAM server 330. SAM settlement request 511 includes modified pending transactions associated with user A sent to SAM server 330, such as A->D: $15, but no original pending transactions associated with user A, such as A->C: $5 and A->D: $10. SAM settlement request 511 requests SAM server 330 to execute the modified pending transactions associated with user A, thereby enabling the processing of consolidated settlement associated with user A.

[0091] Seventh, SAM server 330 executes a modified pending transaction associated with user A by transferring, for example, a consolidated settlement of $15 from the account associated with user A to the account associated with user D.

[0092] Eighth, after execution, SAM server 330 sends settlement confirmation 513 to scheduler node 320. Settlement confirmation 513 can indicate that the modified pending transaction associated with user A has been executed.

[0093] Ninth, in response to receiving settlement confirmation 513, scheduler node 520 can send settlement entry 515 to blockchain network 310 via blockchain API 315, for example, a $15 A->D settlement. As described above, blockchain network 310 can store settlement entry 515 in the blockchain, which stores transaction data including the original pending transactions. Consensus nodes, such as client bank nodes 312, 314, 316, and 318, can update the blockchain using settlement entry 515 through consensus processing.

[0094] In some cases, in response to receiving settlement confirmation 513, scheduler node 520 may send settlement notification 517, for example, directly or through customer bank node 312, to client device 302 associated with user A. Settlement notification 517 may indicate that a consolidated settlement associated with user A has been performed, or that the total loan owed by user A to other users in blockchain network 310 has been paid.

[0095] In some cases, in response to receiving settlement confirmation 513, the scheduler node 520 can store the settlement entry along with the original pending transactions, update the stored modified pending transactions by removing executed modified pending transactions, or update the transaction graph by removing the transfer corresponding to the executed modified pending transactions, such as... Figure 4 As shown in Figures (ii) and (iii) in the figure.

[0096] Figure 6This is a flowchart illustrating an example of a process 600 for implementing transaction management that can be executed according to embodiments herein. For convenience, process 600 will be described as being executed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, such as Figure 3 A properly programmed distributed system of 300 can perform 600 processes. This system may include a blockchain network, for example... Figure 3 The blockchain network 310, and the settlement server, for example Figure 3 The SAM server 330. A blockchain network can include transaction scheduler nodes, such as... Figure 3 The scheduler node 320, and one or more consensus nodes, such as Figure 3 Customer bank nodes 312, 314, 316, and 318.

[0097] At 602, transaction data is obtained at the scheduler node. The transaction data includes multiple original pending transactions to be executed on the blockchain network. These multiple original pending transactions may involve multiple accounts associated with a user. The user can use a corresponding client device to send multiple transfer requests corresponding to the multiple original pending transactions to the blockchain network (e.g., to consensus nodes or non-consensus nodes of the blockchain network). For example, a user can send a transfer request to a consensus node associated with that user. The consensus node can then write the transfer request to the blockchain via the blockchain API.

[0098] In some embodiments, the scheduler node can be a non-consensus node in the blockchain network. For example, when the blockchain network receives a transfer request, the scheduler node can synchronize with the blockchain network by subscribing to receive transfer requests from the blockchain network. The scheduler node can accumulate received transfer requests to obtain transaction data. The blockchain network can store the corresponding transaction data, including original pending transactions associated with users.

[0099] At 604, a merge analysis is performed at the scheduler node to identify multiple modified pending transactions. This is in response to receiving one or more transfer requests, for example, Figure 5 A 501 transfer request, or a settlement query from a user, for example... Figure 5 For settlement query 505, the scheduler node can perform consolidation analysis. The scheduler node can also perform consolidation analysis periodically (e.g., daily, weekly, or monthly). The scheduler node can perform consolidation analysis based on the original pending transactions associated with all users or the original pending transactions associated with subgroups of users.

[0100] Scheduler nodes can perform merge analysis using optimization algorithms (such as the minimum cost flow algorithm). The optimization algorithm is configured to reduce or minimize the number of transactions such that the number of modified pending transactions is less than the number of original pending transactions, while maintaining equivalence between multiple modified pending transactions and multiple original pending transactions.

[0101] In some cases, the scheduler node performs consolidation analysis by calculating a consolidation settlement for each of multiple accounts based on multiple original pending transactions. Then, based on the individual consolidation settlements of the multiple accounts, the accounts are divided into a first group (e.g., a debit group) and a second group (e.g., a credit group). The first and second groups can be sorted based on their respective consolidation settlements. The scheduler node can then match accounts in the first group with accounts in the second group, where the consolidation settlement for borrowing accounts equals the consolidation settlement for lending accounts. The scheduler node can then generate multiple modified pending transactions based on the matching results.

[0102] The scheduler node can, for example, Figure 4 The original pending transactions are presented on the directed transaction graph in Figure (i), and multiple modified pending transactions are identified by modifying the transaction graph. Multiple modified pending transactions can be represented in the modified transaction graph, for example, Figure 4 Figure (ii) in the diagram.

[0103] In 606, the scheduler node maintains multiple original pending transactions using multiple modified pending transactions without updating transaction data in the blockchain stored on the blockchain network. In some embodiments, in response to the scheduler node receiving a new transfer request, the scheduler node can update the stored original pending transactions with new original pending transactions corresponding to the new transfer request. The scheduler node can also update the stored modified pending transactions by performing a new merge analysis based on the new original pending transactions. When the scheduler node receives a settlement entry indicating that a particular modified pending transaction has been executed, the scheduler node can remove the particular modified pending transaction from the stored modified pending transactions and / or store the settlement entry together with the original pending transactions and / or other modified pending transactions.

[0104] At 608, the scheduler node sends a request to the SAM server to execute at least one modified pending transaction associated with a specific account. In some cases, the scheduler node obtains a settlement query from a client device associated with a specific account. The settlement query requests settlement information for the specific account associated with one or more original pending transactions. In response to obtaining the settlement query from the client device, the scheduler node can identify at least one modified pending transaction associated with the specific account and send a settlement request to the SAM server. The scheduler node can also periodically send requests for specific accounts.

[0105] At 610, the scheduler node receives an acknowledgment from the SAM server indicating that at least one modified pending transaction associated with that particular account has been executed. The SAM server can execute the modified pending transaction, for example, by transferring the consolidated settlement indicated in the modified pending transaction from the particular account to the other party indicated in the modified pending transaction. After execution, the SAM server can send an acknowledgment message to the scheduler node.

[0106] In step 612, the scheduler node sends a settlement entry to the blockchain network, specifying that a modified pending transaction associated with a particular account has been executed. The blockchain network can store the settlement entry along with multiple original pending transactions. Consensus nodes can then use the settlement entry to update the blockchain through consensus processing.

[0107] In some cases, in response to receiving settlement confirmation from the SAM server, the scheduler node can send a settlement notification to the client device associated with a specific account. The settlement notification may indicate that a consolidated settlement associated with a specific account has been executed, or that the total loan owed by that specific account to other users in the blockchain network has been paid.

[0108] In some cases, in response to receiving a settlement confirmation from the SAM server, the scheduler node can store the settlement entry along with the original pending transactions. The stored modified pending transactions can be updated by removing executed modified pending transactions, or by removing the transfer corresponding to an executed modified pending transaction.

[0109] Figure 7 Examples of modules of apparatus 700 according to embodiments herein are depicted. Apparatus 700 may be an example of an embodiment of a node of a blockchain network configured to manage transactions on a blockchain network. Apparatus 700 may correspond to the embodiments described above, and apparatus 700 includes: an acquisition module 702 for acquiring transaction data including multiple original pending transactions to be executed between multiple accounts on the blockchain network, the transaction data being stored on the blockchain network; an execution module 704 for performing a merge analysis on the multiple original pending transactions to determine multiple modified pending transactions between the multiple accounts, the number of modified pending transactions being less than the number of original pending transactions; and a maintenance module 706 for maintaining the multiple original pending transactions and the multiple modified pending transactions without updating the transaction data stored on the blockchain network using the multiple modified pending transactions.

[0110] In an alternative embodiment, the apparatus 700 may further include a transmission module 708 for transmitting a request to a Settlement Account Management (SAM) server to execute at least one of a plurality of modified pending transactions associated with a particular account among a plurality of accounts; a receiving module 710 for receiving a confirmation from the SAM server indicating that at least one of the plurality of modified pending transactions associated with the particular account has been executed; and a sending module 712 for sending a settlement entry to the blockchain network specifying that at least one of the plurality of modified pending transactions associated with the particular account has been executed.

[0111] In an alternative embodiment, settlement entries are stored on the blockchain network along with multiple original pending transactions. Settlement information associated with a specific account can be verified on the blockchain network based on the settlement entries and the multiple original pending transactions.

[0112] In an optional embodiment, apparatus 700 further includes an obtaining module for obtaining a query from a client device, the query requesting settlement information for a specific account associated with one or more of a plurality of original pending transactions. Apparatus 700 may further include a sending module for sending, in response to the obtained query, a consolidated settlement for the specific account among the plurality of accounts to the client device associated with the specific account, the consolidated settlement being associated with at least one of the plurality of modified pending transactions associated with the specific account.

[0113] In an optional embodiment, the apparatus 700 further includes an acquisition module for acquiring a client request from a client device associated with a specific account, the client request authorizing settlement for that specific account, wherein the request is sent to SAM in response to acquiring the client request from the client device.

[0114] In an optional embodiment, the apparatus 700 further includes an update module for updating a plurality of modified pending transactions based on a settlement entry in response to receiving an acknowledgment from the SAM server. The settlement entry specifies that at least one of the plurality of modified pending transactions associated with a particular account has been executed.

[0115] In an optional embodiment, the apparatus 700 further includes a sending module for sending a message to a client device associated with a specific account in response to receiving an acknowledgment from the SAM server, the message confirming that the settlement associated with the specific account has been executed.

[0116] In an alternative embodiment, the obtaining module 702 obtains transaction data by synchronizing with the blockchain network to receive each of a plurality of original pending transactions from the respective client devices associated with each of the multiple accounts.

[0117] In an optional embodiment, the execution module 704 performs a merged analysis on the multiple original pending transactions by calculating the corresponding consolidated settlement for each of the multiple accounts based on the multiple original pending transactions to determine multiple modified pending transactions. Based on the consolidated settlement of each of the multiple accounts, the multiple accounts are divided into a first group and a second group. The first account in the first group is matched with the second account in the second group according to the consolidated settlement of the first account and the second account, and multiple modified pending transactions are generated based on the matching results.

[0118] In an optional embodiment, the execution module 704 presents multiple original pending transactions on a transaction graph and determines multiple modified pending transactions by modifying the transaction graph. It then performs a merged analysis on the multiple original pending transactions to determine the multiple modified pending transactions, wherein the multiple modified pending transactions are presented on the modified transaction graph.

[0119] In an alternative embodiment, in response to determining that a particular one of a plurality of modified pending transactions has been executed, maintenance module 706 reduces the modified transaction graph by removing said particular one of the plurality of modified pending transactions from the modified transaction graph.

[0120] The systems, devices, modules, or units shown in the foregoing embodiments can be implemented using computer chips or entities, or can be implemented using products with specific functions. Typical embodiment devices are computers (which may be personal computers), laptop computers, cellular phones, camera phones, smartphones, personal digital assistants, media players, navigation devices, email sending and receiving devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0121] For the implementation process of the function and role of each module in the device, please refer to the implementation process of the corresponding steps in the aforementioned method. For simplicity, details are omitted here.

[0122] Since the apparatus embodiments largely correspond to the method embodiments, the relevant descriptions in the method embodiments can be referred to for related components. The apparatus implementation described above is merely an example. Modules described as individual components may or may not be physically separate, and components shown as modules may or may not be physical modules, may be located in one location, or may be distributed across multiple network modules. Some or all modules can be selected based on actual needs to achieve the objectives of the present invention. Those skilled in the art can understand and implement the embodiments of this application without inventive effort.

[0123] See you again Figure 7This can be interpreted as illustrating the internal functional modules and structure of a blockchain-based transaction management implementation device. The blockchain-based transaction management implementation device can be an example of a blockchain network node configured to manage transactions in a blockchain network. Essentially, the execution entity can be an electronic device comprising: one or more processors; and one or more computer-readable storage devices configured to store executable instructions of the one or more processors. In some embodiments, the one or more computer-readable storage devices are coupled to the one or more processors and have programming instructions stored thereon, which can be executed by the one or more processors to perform the algorithms, methods, functions, processes, flows, and programs described herein.

[0124] The techniques described herein produce several technical effects. In some embodiments, the scheduler node can perform a merge analysis on the original pending transactions to generate a smaller number of modified pending transactions, and submit the modified pending transactions associated with a specific user to the Settlement Account Management (SAM) server for settlement (or execution). This technique can help reduce the number of actual settlement transactions, enabling the blockchain network to handle a large number of transactions while using blockchain technology to provide trust for each user and integrity for each transaction.

[0125] In some embodiments, the scheduler node is a non-consensus node configured not to update transaction data stored in the blockchain on the blockchain network that includes the original pending transactions. This avoids performing consensus processing on the blockchain network, thereby reducing operating costs and improving the efficiency of the blockchain network. Furthermore, since the number of modified pending transactions is less than the number of original pending transactions, the number of actual settlement transactions is reduced, and the number of settlement entries to be stored in the blockchain network is also reduced. This also avoids increasing storage space in the blockchain network.

[0126] This technology enables the storage of settlement entries for original pending transactions and / or actual settled transactions within a blockchain network. Therefore, the blockchain network can possess a complete transaction graph of users (participants or accounts) within the network. Consensus nodes associated with users, such as customer bank nodes, can store a complete copy of the blockchain. The blockchain network includes scheduler nodes to perform merging of original pending transactions, and the network can obtain consensus from users to maintain correct balances and execute each transaction with the merged amount. The blockchain network can also provide verification services for users using the stored settlement entries of original pending transactions and actual settled transactions. Thus, this technology ensures the correctness of balances in the distributed ledger and provides trustworthy and provable transactions.

[0127] In some embodiments, the scheduler node synchronizes with the blockchain network to receive transfer requests from client devices associated with users. Therefore, the scheduler node can perform real-time and dynamic merging of original pending transactions. The scheduler node can also synchronize with the blockchain network to receive settlement queries and / or settlement requests from specific users. The scheduler node can respond to settlement queries by providing merged settlement information to the specific user, or by sending a SAM settlement request to the SAM server to execute at least one modified transaction associated with that specific user. Thus, the blockchain network can dynamically process large volumes of transactions in a decentralized manner.

[0128] In some embodiments, a scheduling application programming interface (API) may be provided to client devices associated with a user. Client devices can use the scheduling API to send transfer requests, transfer queries, settlement queries, and / or settlement requests to nodes in the blockchain network. In some embodiments, the blockchain API may be provided to nodes for reading / writing transaction entries and / or reading blocks. In some embodiments, the settlement consolidation API may be provided to the SAM server to receive settlement requests and provide responses. These APIs can help reduce overall transaction costs.

[0129] This technology can be applied to blockchain payment networks or distributed payment networks, where the number of actual settlement transactions can be reduced, and the lending-borrowing relationship can be preserved and endorsed through blockchain technology. It can also be applied to cross-border remittances, inter-institutional remittances, personal digital wallets, and value-added services related to digital asset management.

[0130] Implementations of the described subject matter may include one or more features, individually or in combination. For example, in a first embodiment, a method for managing transactions in a blockchain network includes: a scheduling device on the blockchain network obtaining transaction data comprising a plurality of original pending transactions to be executed among multiple accounts on the blockchain network, the transaction data being stored on the blockchain network; the scheduling device performing a merge analysis on the plurality of original pending transactions to determine a plurality of modified pending transactions among the multiple accounts, wherein the number of the plurality of modified pending transactions is less than the number of the plurality of original pending transactions; and the scheduling device maintaining the plurality of original pending transactions using the plurality of modified pending transactions without updating the transaction data stored on the blockchain network using the plurality of modified pending transactions.

[0131] The embodiments described above and in other ways may optionally include one or more of the following features.

[0132] A first feature, which can be combined with any of the following features, specifies that the method further includes: the scheduling device sending a consolidated settlement for the specific account to a client device associated with a specific account among the plurality of accounts, the consolidated settlement being associated with at least one of a plurality of modified pending transactions associated with the specific account.

[0133] The second feature, which can be combined with any of the preceding or following features, specifies that the method further includes: the scheduling device obtaining a query from the client device, the query request being for settlement information of a specific account associated with one or more of the plurality of original pending transactions, wherein the consolidated settlement for the specific account is sent by the scheduling device in response to obtaining the query from the client device.

[0134] A third feature, which may be combined with any of the preceding or following features, specifies that the method further includes: the scheduling device sending a request to a Settlement Account Management (SAM) server to execute at least one of a plurality of modified pending transactions associated with a specific account among the plurality of accounts.

[0135] A fourth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: the scheduling device obtaining a client request from a client device associated with the specific account, the client request authorizing settlement for the specific account, wherein the request is sent to the SAM server in response to obtaining the client request from the client device.

[0136] A fifth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: the scheduling device receiving an acknowledgment from the SAM server indicating that at least one of the plurality of modified pending transactions associated with the particular account has been executed.

[0137] A sixth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: in response to receiving the confirmation from the SAM server, the scheduling device sends a settlement entry to the blockchain network, the settlement entry specifying that at least one of the plurality of modified pending transactions associated with the particular account has been executed.

[0138] The seventh feature, which can be combined with any of the preceding or following features, specifies that the method further includes: storing the settlement entry together with the plurality of original pending transactions on the blockchain network.

[0139] The eighth feature, which can be combined with any of the preceding or following features, specifies that the method further includes: verifying settlement information associated with the specific account on the blockchain network based on the settlement entry and the plurality of original pending transactions.

[0140] The ninth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: in response to receiving the confirmation from the SAM server, the scheduling device updates the plurality of modified pending transactions based on a settlement entry that has been executed for at least one of the plurality of modified pending transactions associated with the particular account.

[0141] The tenth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: in response to receiving the confirmation from the SAM server, the scheduling device sends a message to a client device associated with the specific account, the message confirming that the settlement associated with the specific account has been executed.

[0142] The eleventh feature, which can be combined with any of the preceding or following features, specifies that performing a merged analysis on the plurality of original pending transactions to determine a plurality of modified pending transactions includes: calculating a corresponding merged settlement for each of the plurality of accounts based on the plurality of original pending transactions; dividing the plurality of accounts into a first group and a second group based on their respective merged settlements; matching the first account with the second account according to the corresponding merged settlements of the first account in the first group and the second account in the second group; and generating the plurality of modified pending transactions based on the matching results.

[0143] The twelfth feature, which can be combined with any of the preceding or following features, specifies that performing a combined analysis of the plurality of original pending transactions to determine a plurality of modified pending transactions includes: presenting the plurality of original pending transactions on a transaction graph; and determining the plurality of modified pending transactions by modifying the transaction graph, wherein the plurality of modified pending transactions are presented on a modified transaction graph.

[0144] The thirteenth feature, which may be combined with any of the preceding or following features, specifies that maintaining the plurality of original pending transactions and the plurality of modified pending transactions includes: in response to determining that a particular one of the plurality of modified pending transactions has been executed, reducing the modified transaction graph by removing the particular one of the plurality of modified pending transactions from the modified transaction graph.

[0145] The fourteenth feature, which may be combined with any of the preceding or following features, specifies that obtaining transaction data comprising a plurality of original pending transactions includes: synchronizing with the blockchain network to receive each of the plurality of original pending transactions from a corresponding client device associated with each of the plurality of accounts.

[0146] Embodiments of the subject matter, actions, and operations described herein can be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware, or combinations thereof, including the structures disclosed herein and their structural equivalents. Embodiments of the subject matter described herein can be implemented as one or more computer programs, such as one or more computer program instruction modules encoded on a computer program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. For example, the computer program carrier may include one or more computer-readable storage media on which instructions are encoded or stored. The carrier may be a tangible, non-transitory computer-readable medium, such as a magnetic disk, magneto-optical disk or optical disk, a solid-state drive, random access memory (RAM), read-only memory (ROM), or other media types. Optionally or additionally, the carrier may be an artificially generated propagation signal, such as a machine-generated electrical signal, optical signal, or electromagnetic signal, generated to encode information for transmission to a suitable receiver device for execution by a data processing apparatus. The computer storage medium may be, or in part, a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination thereof. The computer storage medium is not a propagation signal.

[0147] A computer program may also be called or described as a program, software, software application, app, module, software module, engine, script, or code, and may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; it may be deployed in any form, including as a standalone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers interconnected by a data communication network in one or more locations.

[0148] A computer program may, but is not required to, correspond to a file in a file system. A computer program may be stored as: a portion of a file that holds other programs or data, such as one or more scripts stored in a markup language document; a single file dedicated to the program in question; or multiple coordination files, such as multiple files storing one or more modules, subroutines, or code sections.

[0149] Processors used to execute computer programs include, for example, general-purpose and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives data and instructions for the computer program to be executed from a non-transitory computer-readable medium coupled to the processor.

[0150] The term "data processing apparatus" encompasses all types of devices, apparatuses, and machines used for processing data, including programmable processors, computers, or multiple processors or computers. Data processing apparatuses may include specialized logic circuitry such as FPGAs (Field-Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), or GPUs (Graphics Processing Units). In addition to hardware, the apparatus may also include code that creates an execution environment for computer programs, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, or combinations thereof.

[0151] The processes and logical flows described herein can be executed by one or more computers or processors executing one or more computer programs to perform operations by manipulating input data and generating outputs. These processes and logical flows can also be executed by dedicated logic circuitry, such as FPGAs, ASICs, or GPUs, or by a combination of dedicated logic circuitry and one or more programmed computers.

[0152] A computer suitable for executing computer programs can be based on a general-purpose and / or special-purpose microprocessor, or any other type of central processing unit (CPU). Typically, the CPU receives instructions and data from read-only memory and / or random access memory. The components of a computer may include a CPU for executing instructions and one or more storage devices for storing instructions and data. The CPU and memory may be supplemented with or integrated into special-purpose logic circuitry.

[0153] Typically, a computer also includes, or is operatively coupled to, one or more storage devices to receive data or transfer data to one or more storage devices. Storage devices can be, for example, disks, magneto-optical or optical disks, solid-state drives, or any other type of non-transitory computer-readable media. However, a computer does not necessarily have to have such devices. Thus, a computer can be coupled to one or more storage devices, such as one or more memories located locally and / or remotely. For example, a computer may include one or more local memories as an integrated component of the computer, or the computer may be coupled to one or more remote memories located in a cloud network. Furthermore, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name just a few.

[0154] Components can be "coupled" to each other by communicating directly or via one or more intermediate components, such as electrical or optical connections. These components can also be "coupled" to each other if one component is integrated into another. For example, a storage component integrated into a processor, such as an L2 cache component, can be "coupled" to the processor.

[0155] To interact with a user, embodiments of the subject matter described herein can be implemented on or configured to communicate with a computer having a display device and input devices, such as an LCD (liquid crystal display) monitor for displaying information to the user, and input devices such as a keyboard and positioning devices through which the user can provide input to the computer, and positioning devices such as a mouse, trackball, or touchpad. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and any form of input from the user can be received, including sound, speech, or tactile input. Furthermore, a computer can interact with a user by sending and receiving documents from the device used by the user; for example, by sending a web page to a web browser on the user's device in response to a request received from the web browser, or by interacting with an application (app) running on the user's device, such as a smartphone or tablet. A computer can also interact with a user by sending text messages or other forms of messages to a personal device, such as a smartphone running a messaging program, and receiving response messages from the user.

[0156] This document uses the term "configured as" in relation to systems, devices, and computer program components. For a system of one or more computers configured to perform a specific operation or action, this means that the system has software, firmware, hardware, or a combination thereof installed thereon that causes the system to perform said operation or action during operation. For one or more computer programs configured to perform a specific operation or action, this means that the one or more programs include instructions that, when executed by a data processing device, cause that device to perform said operation or action. For a dedicated logic circuit configured to perform a specific operation or action, this means that the circuit has electronic logic for performing said operation or action.

[0157] While this document contains many specific implementation details, these should not be construed as limiting the scope of the claims, but rather as descriptions of features specific to particular embodiments, the scope of which is defined by the claims themselves. Some features described herein in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Moreover, although the features described above may function in certain combinations, and even were initially claimed, in some cases one or more features may be removed from the claimed combination, and the claims may also be directed to sub-combinations or variations thereof.

[0158] Similarly, although the operations are depicted in the accompanying drawings in a specific order and are described in the claims, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or requiring the execution of all shown operations, in order to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0159] Specific embodiments of this subject matter have been described. Other embodiments also fall within the scope of the following claims. For example, the actions recited in the claims can be performed in different orders and still achieve the desired result. As an example, the processes depicted in the drawings do not require a specific order or sequence to achieve the desired result. In some cases, multitasking in parallel may be advantageous.

Claims

1. A computer-implemented method for managing transactions on a blockchain network, the computer-implemented method comprising: A scheduling device on a blockchain network acquires transaction data including multiple original pending transactions to be executed among multiple accounts on the blockchain network, the transaction data being stored on the blockchain network; The scheduling device performs a combined analysis on the plurality of original pending transactions to determine a plurality of modified pending transactions among the plurality of accounts, wherein the number of the plurality of modified pending transactions is less than the number of the plurality of original pending transactions; and The scheduling device maintains the original pending transactions using the multiple modified pending transactions without updating the transaction data stored on the blockchain network using the multiple modified pending transactions; Specifically, a combined analysis of the multiple original pending transactions is performed to determine the multiple modified pending transactions, including: Based on the multiple original pending transactions, calculate the corresponding consolidated settlement for each of the multiple accounts; Based on the respective consolidated settlements of the multiple accounts, the multiple accounts are divided into a first group and a second group; Based on the corresponding consolidated settlement of the first account in the first group and the second account in the second group, the first account is matched with the second account; and The multiple modified pending transactions are generated based on the matching results.

2. The computer-implemented method as described in claim 1, further comprising: The scheduling device sends a consolidated settlement for a specific account to a client device associated with a particular account among the plurality of accounts. The consolidated settlement is associated with at least one of a plurality of modified pending transactions associated with the particular account.

3. The computer-implemented method as described in claim 2, further comprising: The scheduling device obtains a query from the client device, the query request being for settlement information of a specific account associated with one or more of the plurality of original pending transactions. The consolidated settlement for the specific account is sent by the scheduling device in response to the query obtained from the client device.

4. The computer-implemented method as described in any of the preceding claims, further comprising: The scheduling device sends a request to the Settlement Account Management (SAM) server to execute at least one of a plurality of modified pending transactions associated with a specific account among the plurality of accounts.

5. The computer-implemented method as described in claim 4, further comprising: The scheduling device receives a client request from a client device associated with the specific account, the client requesting authorization for settlement for the specific account. The request is sent to the settlement account management server in response to obtaining the client request from the client device.

6. The computer-implemented method as described in claim 4 or 5, further comprising: The scheduling device receives a confirmation from the settlement account management server, the confirmation indicating that at least one of the plurality of modified pending transactions associated with the specific account has been executed.

7. The computer-implemented method as described in claim 6, further comprising: In response to receiving the confirmation from the settlement account management server, the scheduling device sends a settlement entry to the blockchain network, the settlement entry specifying that at least one of the plurality of modified pending transactions associated with the particular account has been executed.

8. The computer-implemented method of claim 7, further comprising: The settlement entry is stored on the blockchain network along with the plurality of original pending transactions.

9. The computer-implemented method as described in claim 8, further comprising: Based on the settlement entries and the multiple original pending transactions, settlement information associated with the specific account is verified on the blockchain network.

10. The computer-implemented method as described in any one of claims 6 to 9, further comprising: In response to receiving the confirmation from the settlement account management server, the scheduling device updates the plurality of modified pending transactions based on a settlement entry that has been executed among the plurality of modified pending transactions associated with the specific account.

11. The computer-implemented method as described in any of the preceding claims, wherein, A combined analysis of the original pending transactions was performed to determine that the modified pending transactions included: Present the aforementioned multiple original pending transactions on a transaction graph; and The plurality of modified pending transactions are determined by modifying the transaction graph, wherein the plurality of modified pending transactions are presented on the modified transaction graph.

12. The computer-implemented method as described in any of the preceding claims, wherein, Obtaining transaction data including multiple original pending transactions includes: Synchronize with the blockchain network to receive each of the plurality of original pending transactions from the respective client devices associated with each of the plurality of accounts.

13. An apparatus for implementing a blockchain-based workflow, the apparatus comprising a plurality of modules for performing a computer-implemented method as claimed in any one of claims 1 to 12.

14. A system for implementing blockchain-based workflows, comprising: One or more processors; as well as One or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon, the instructions being executable by the one or more processors to perform a computer-implemented method as claimed in any one of claims 1 to 12.

Images