WO2021223492A1 - Procédé et système de résolution d'obstruction basée sur une chaîne de blocs - Google Patents

Procédé et système de résolution d'obstruction basée sur une chaîne de blocs Download PDF

Info

Publication number
WO2021223492A1
WO2021223492A1 PCT/CN2021/077289 CN2021077289W WO2021223492A1 WO 2021223492 A1 WO2021223492 A1 WO 2021223492A1 CN 2021077289 W CN2021077289 W CN 2021077289W WO 2021223492 A1 WO2021223492 A1 WO 2021223492A1
Authority
WO
WIPO (PCT)
Prior art keywords
blockchain
transactions
transaction
subset
blockchain transactions
Prior art date
Application number
PCT/CN2021/077289
Other languages
English (en)
Inventor
Shengjiao CAO
Yuan Yuan
Hui Fang
Weitao YANG
Original Assignee
Alipay Labs (singapore) Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Labs (singapore) Pte. Ltd. filed Critical Alipay Labs (singapore) Pte. Ltd.
Priority to CN202180030787.4A priority Critical patent/CN115485687A/zh
Publication of WO2021223492A1 publication Critical patent/WO2021223492A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Definitions

  • the disclosure relates generally to systems and methods for blockchain-based gridlock resolution.
  • inter-bank payments were settled via netting systems (e.g., by settling the nettable payments on a net basis) , but as the volume and the value of transactions kept increasing, central banks became wary of the risks involved in deferred net settlement systems.
  • central banks favor real-time gross settlement (RTGS) systems.
  • RTGS real-time gross settlement
  • payment instructions e.g., payment transactions
  • RTGS payment instructions
  • the liquidity demands in RTGS systems are enormous; in fact, the daily transfer volume in typical inter-bank payment systems could be as large as a substantial fraction of a country’s annual GDP.
  • central bank often combines RTGS with liquidity saving mechanisms (LSM) , of which intra-network gridlock resolution is the most effective one.
  • LSM liquidity saving mechanisms
  • cross-network gridlocks poses challenges as financial institutions are building different blockchain-based infrastructures to offer their services.
  • Different blockchain networks may be built with different blockchain technologies (e.g., such as different encryption schemes) , and due to privacy-preserving concerns, transaction information (e.g., payments, balance) of one blockchain network may be invisible to another blockchain network.
  • transaction information e.g., payments, balance
  • how to resolve cross-network gridlocks for blockchain-based payment systems has become an intriguing challenge.
  • Various embodiments of the present specification may include systems, methods, and non-transitory computer readable media for blockchain-based gridlock resolution.
  • the method for blockchain-based gridlock resolution may comprise, for each blockchain of a plurality of blockchains: obtaining, by a computing system associated with an entity from the blockchain, one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the entity and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the entity; conducting, by the computing system associated with the entity, one or more iterations of a transaction-selection process, wherein each of the one or more iterations of the transaction-selection process comprises: determining a subset of the one or more first blockchain transactions; selecting a subset of the one or more second blockchain transactions based on the determined subset of the one or more first blockchain transactions and a balance of a blockchain account of the entity on the blockchain; determining a delta value associated with the blockchain based on the subset of the one or more first blockchain transactions, the subset of the one or more second blockchain transactions, and the balance of the blockchain account on the blockchain, wherein the delta value corresponds to a value
  • the method may further comprise, prior to conducting the one or more iterations of the transaction-selection process: obtaining, by the computing system, a blockchain transaction in each of the blockchains indicating a beginning of the transaction-selection process.
  • the adding to the blockchain a third blockchain transaction comprises: sending the third blockchain transaction to one or more blockchain nodes associated with blockchain to add to the blockchain, wherein the third blockchain transaction invokes a blockchain contract on the blockchain, and wherein the blockchain contract is executable to aggregate the one or more identifiers in the third blockchain transaction with a plurality of other identifiers in a plurality of other blockchain transactions.
  • the determining a subset of the one or more first blockchain transactions comprises: for a first iteration among the one or more iterations of the transaction-selection process: determining the subset of the one or more first blockchain transactions as including each of the one or more first blockchain transactions; and for each of one or more iterations, other than the first iteration, among the one or more iterations of the transaction-selection process: obtaining, by the computing system from the blockchain, one or more blockchain transactions generated by the blockchain contract, the one or more blockchain transactions comprising a plurality of identifiers; and determining the subset of the one or more first blockchain transactions based on the plurality of identifiers.
  • the selecting a subset of the one or more second blockchain transactions comprises: determining a first total amount by aggregating a plurality of values associated with a global set of first blockchain transactions, wherein the global set of first blockchain transactions comprises the one or more first blockchain transactions for each of the plurality of blockchains; determining a second total amount by aggregating a global set of balances, wherein the global set of balances comprises the balance of the blockchain account of the entity on each of the plurality of blockchains; and selecting one or more second blockchain transactions from a global set of second blockchain transactions such that a sum of one or more values associated with the selected one or more second blockchain transactions is no greater than a sum of the first total amount and the second total amount, wherein the global set of second blockchain transactions comprises the obtained one or more second blockchain transactions for each of the plurality of blockchains.
  • the global set of second blockchain transactions are respectively associated with priority rankings; and the selecting the one or more second blockchain transactions from the global set of second blockchain transactions comprises selecting the one or more second blockchain transactions based on the priority rankings.
  • the priority rankings of the global set of second blockchain transactions are determined chronologically.
  • the determining a delta value associated with the blockchain comprises: obtaining a first total amount associated with the subset of the one or more first blockchain transactions and a second total amount associated with the subset of the one or more second blockchain transactions; determining the delta value by subtracting a sum of the first total amount and the balance of the blockchain account from the second total amount.
  • the encrypted version of the delta value is generated based on a homomorphic commitment scheme or a homomorphic encryption scheme.
  • each blockchain transaction of the one or more first blockchain transactions and the one or more second blockchain transactions comprises: an index corresponding to the blockchain transaction, a homomorphically encrypted version of an amount of corresponding value transfer, and an identifier associated with a recipient of the corresponding value transfer, wherein the homomorphically encrypted version of the value transfer amount based on a homomorphic commitment scheme or a homomorphic encryption scheme.
  • the third blockchain transaction further comprises a zero-knowledge range proof that a first sum is not less than a second sum, the first sum comprising the balance of the blockchain account on the blockchain and a first total amount associated with the subset of the one or more first blockchain transactions, the second sum comprising a second total amount associated with the subset of the one or more second blockchain transactions and the delta value.
  • the method may further comprise, for each blockchain of the plurality of blockchains: obtaining, from the blockchain, a proof that a sum of a global set of delta values associated with the entity equals zero, wherein the global set of delta values comprises the delta value associated with each of the plurality of blockchains.
  • a non-transitory computer-readable storage medium is configured with instructions executable by one or more processors to cause the one or more processors to perform the method of any of the preceding embodiments.
  • an apparatus for blockchain-based gridlock resolution comprises a plurality of modules for performing the method of any of the preceding embodiments.
  • a system for blockchain-based gridlock resolution may comprise a plurality of sensors and a computer system that comprises a first computing device and a second computing device, the computer system comprising a processor and a non-transitory computer-readable storage medium storing instructions executable by the processor to cause the system to perform operations comprising, for each blockchain of a plurality of blockchains: obtaining, by a computing system associated with an entity from the blockchain, one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the entity and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the entity; conducting, by the computing system associated with the entity, one or more iterations of a transaction-selection process, wherein each of the one or more iterations of the transaction-selection process comprises: determining a subset of the one or more first blockchain transactions; selecting a subset of the one or more second blockchain transactions based on the determined subset of the one or more first blockchain transactions and a balance of a blockchain account of the
  • a non-transitory computer-readable storage medium for blockchain-based gridlock resolution may be configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising, for each blockchain of a plurality of blockchains: obtaining, by a computing system associated with an entity from the blockchain, one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the entity and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the entity; conducting, by the computing system associated with the entity, one or more iterations of a transaction-selection process, wherein each of the one or more iterations of the transaction-selection process comprises: determining a subset of the one or more first blockchain transactions; selecting a subset of the one or more second blockchain transactions based on the determined subset of the one or more first blockchain transactions and a balance of a blockchain account of the entity on the blockchain; determining a delta value associated with the blockchain based on the subset of the one or more first blockchain transactions
  • an apparatus for executing a blockchain-based gridlock resolution may comprise an obtaining module, a transaction selection module, and a termination module.
  • the obtaining module may, for each blockchain of a plurality of blockchains obtain one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the entity and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the entity.
  • the transaction selection module may conduct one or more iterations of a transaction-selection process, wherein each of the one or more iterations of the transaction-selection process comprises: determining a subset of the one or more first blockchain transactions; selecting a subset of the one or more second blockchain transactions based on the determined subset of the one or more first blockchain transactions and a balance of a blockchain account of the entity on the blockchain; determining a delta value associated with the blockchain based on the subset of the one or more first blockchain transactions, the subset of the one or more second blockchain transactions, and the balance of the blockchain account on the blockchain, wherein the delta value corresponds to a value transfer between the blockchain account on the blockchain and one or more different blockchain accounts of the entity on one or more different blockchains of the plurality of blockchains; and adding to the blockchain a third blockchain transaction comprising one or more identifiers corresponding to the selected subset of the one or more second blockchain transactions and an encrypted version of the delta value.
  • the termination module may terminate the one or
  • a blockchain-based method collects information of incoming and outgoing transactions for a plurality of entities, identifies a subset of the transactions that can be settled, and settles the identified transactions via a decentralized multi-step mechanism, in which all of the entities participate.
  • the mechanism is enabled by automated operation of blockchain contracts. This provides effective, fair, reliable, and transparent resolution of the transactions and any gridlock that may occur.
  • the method arranges records of multiple entities’ assets and liabilities across multiple blockchain networks and facilitates dynamic movement of each entity’s assets across blockchain networks to satisfy the entity’s transaction needs. This allows trusted exchange of information among different blockchain networks with different characteristics such as consensus protocols, access rules, and participating nodes.
  • the transaction information within a blockchain network is kept only visible to related parties, and confidential information such as payment amounts are protected by commitments and proved by zero-knowledge range proofs. This protects confidential information of the participating entities.
  • the transactions to be settled are proposed based on a first-in-first-out protocol at a global scale across multiple participants and multiple networks and all participants participate in each step of the gridlock resolution process. This ensures the fairness of the final resolution for all participants.
  • FIG. 1 illustrates a network environment associated with a blockchain in accordance with some embodiments.
  • FIG. 2 illustrates a framework for implementing blockchain transactions in accordance with some embodiments.
  • FIG. 3 illustrates an example network environment for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 4 illustrates an example diagram of a computing system for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 5 illustrates an example blockchain contract for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 6 illustrates an example diagram of a timing service for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 7 illustrates an example workflow for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 8 illustrates an example application of blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 9 illustrates an example method for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 10 illustrates an example block diagram of a computing system for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • FIG. 11 illustrates an example block diagram of a computer system in which any of the embodiments described herein may be implemented.
  • Embodiments described herein provide methods, systems, and apparatus associated with a framework for blockchain-based gridlock resolution.
  • Gridlocks may occur when entities exchanging assets are unable to settle their outgoing transactions or liabilities individually due to insufficient liquidity.
  • the platform integrates various components, such as blockchain networks, off-chain communication channels, cloud applications, client applications, application programming interfaces, and other suitable components to enable various functionalities related to resolving cross-network gridlocks.
  • Various parties such as asset owners or service providers (e.g., banks) , regulatory agencies, information service providers, resolution coordinators, may participate in the gridlock resolution framework. The parties may participate in the gridlock resolution process by interacting with one or more blockchain networks for recording transactions that are to be settled.
  • a party may interact with a blockchain network by controlling a node associated with the blockchain network, participating in a consensus protocol associated with the blockchain network via the node, and performing operations associated with gridlock resolution using the node.
  • a party may alternatively interact with the blockchain network through one or more blockchain nodes associated with one or more other entities.
  • a party may also interact with the blockchain network using one or more interfaces provided by a platform offering various blockchain-related services.
  • FIG. 1 For example, Bank 1, Bank 2, and Bank 3 in a same network (e.g., a blockchain network) are involved in a three-way asset-transfer scenario: Bank 1 needs to transfer $120K to Bank 2, Bank 2 needs to transfer $150K to Bank 3, and Bank 3 needs to transfer $80K to Bank 1. Assuming Bank 1, Bank 2, and Bank 3 each has a current balance of $50K, none of them can directly settle its outgoing transaction due to insufficient current balance. However, the banks may settle the payments on a net basis.
  • the assets transfer transactions may be aggregated by a central computing system within the network to determine whether a gridlock resolution is available.
  • Bank 1 may take into account the incoming transaction $80K from Bank 3 when settling its outgoing transaction $120K to Bank 2;
  • Bank 2 may take into account the incoming transaction $120K from Bank 1 when settling its outgoing transaction $150K to Bank 3; and
  • Bank 3 may take into account the incoming transaction $150K from Bank 2 when settling its outgoing transaction $80K to Bank 1.
  • Bank 1 only needs to transfer $40K to Bank 3, and Bank 2 only needs to transfer $30K to Bank 3.
  • Bank 1’s new balance will be $10K
  • Bank 2’s new balance will be $20K
  • Bank 3’s new balance will be $120K.
  • Gridlock resolution based on direct-netting may be impractical when transactions are distributed across a plurality of blockchain networks.
  • the transactions in one network may be invisible to another network and/or encrypted in a different way than that in other networks, and there may not be a central computing system that is able to aggregate all asset-transfer transactions across the networks.
  • a resolution coordinator e.g., a computing system associated with a timing service provider
  • the resolution may comprise one or more iterations of transaction-selection processes on each of a plurality of blockchain networks.
  • each participant e.g., a computing system associated with a bank or an asset exchange institution
  • the resolution coordinator may monitor the proposals submitted by each participant across the plurality of blockchain networks. When the proposals are converged at a global scale (e.g., implying that all participants have agreed the proposals) , the resolution coordinator may determine a gridlock solution has been found (e.g., a list of outgoing transactions may be settled among the participants across the plurality of blockchain networks) . Subsequently, an information service provider (such as a global notary service or an oracle) offering cross-network interoperability may sign on the gridlock solution and notify the assets exchange institutions to settle the corresponding transactions.
  • an information service provider such as a global notary service or an oracle
  • FIG. 1 illustrates a network environment associated with a blockchain in accordance with some embodiments.
  • a client 111 may couple to a server end 118, and the server end 118 and a Node B may couple to a blockchain system 112 through various communication networks.
  • the server end 118 may optionally couple to additional blockchain systems similar to the blockchain system 112 such as blockchain system 113, blockchain system 114, etc.
  • Each blockchain system may maintain one or more blockchains.
  • the client 111 may comprise one or more servers (e.g., Node C) and one or more other computing devices (e.g., Node A1, Node A2, Node A3) .
  • Node A1, Node A2, and Node A3 may couple to Node C.
  • Node C may be implemented by an entity (e.g., website, mobile phone Application, organization, company, enterprise) , which has various local accounts (e.g., local accounts accessed from Node A1, Node A2, Node A3) .
  • a mobile phone application may have millions of end-users accessing the application’s server from respective user accounts.
  • the application’s server may correspondingly store millions of user accounts.
  • the components of the client 111 and their arrangement may have many other configurations.
  • Node B may include a lightweight node.
  • a lightweight node may not download the complete blockchain but may instead just download the block headers to validate the authenticity of the blockchain transactions.
  • Lightweight nodes may be served by and effectively dependent on full nodes (e.g., blockchain nodes in the blockchain system 112) to access more functions of the blockchain.
  • the lightweight nodes may be implemented in electronic devices such as laptops, mobile phones, and the like by installing an appropriate software.
  • the server end 118 may provide Blockchain-as-a-Service (BaaS) and be referred to as a BaaS cloud.
  • BaaS is a cloud service model in which clients or developers outsource behind-the-scenes aspects of a web or mobile application.
  • BaaS may provide pre-written software for activities that take place on blockchains, such as user authentication, database management, and remote updating.
  • the BaaS cloud may be implemented in a server, server cluster, or other devices.
  • the BaaS cloud provides an enterprise-level platform service based on blockchain technologies.
  • This service may help clients to build a secure and stable blockchain environment as well as manage the deployment, operation, maintenance, and development of blockchain easily.
  • the BaaS cloud can provide advanced security protection using chip encryption technologies.
  • this service may provide end-to-end and highly available services that can scale up quickly without interruption.
  • the BaaS cloud can provide native support for standard blockchain applications and data.
  • the blockchain system 112 may comprise a plurality of blockchain nodes (e.g., Blockchain Node 1, Blockchain Node 2, Blockchain Node 3, Blockchain Node 4, Blockchain Node i, etc. ) that maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain) .
  • Other blockchain systems e.g., blockchain system 113, blockchain system 114) may comprise similar arrangements of blockchain nodes maintaining other blockchains.
  • Each blockchain node may be found in one or more blockchain systems.
  • the blockchain nodes of each blockchain system may maintain one or more blockchains.
  • the blockchain nodes may include full nodes. Full nodes may download every block and blockchain transaction and check them against the blockchain’s consensus rules.
  • the blockchain nodes may form a network (e.g., peer-to-peer network) with one blockchain node communicating with another.
  • the order and the number of the blockchain nodes as shown are merely examples for illustration.
  • the blockchain nodes may be implemented in servers, computers, etc.
  • each blockchain node may be implemented in a server or a cluster of servers.
  • the cluster of servers may employ load balancing.
  • Each blockchain node may correspond to one or more physical hardware devices or virtual devices coupled together via various types of communication methods such as TCP/IP.
  • the blockchain nodes may also be referred to as full nodes, Geth nodes, consensus nodes, etc.
  • each of the nodes and devices may be installed with appropriate software (e.g., application programming interface) and/or hardware (e.g., wires, wireless connections) to access other devices of the environment 100.
  • the nodes and devices may be able to communicate with one another through one or more wired or wireless networks (e.g., the Internet) through which data can be communicated.
  • Each of the nodes and devices may include one or more processors and one or more memories coupled to the one or more processors.
  • the memories may be non-transitory and computer-readable and configured with instructions executable by one or more processors to cause the one or more processors to perform operations described herein.
  • the instructions may be stored in the memories or downloaded over a communications network without necessarily being stored in the memories.
  • the devices such as Node A1, Node A2, Node A3, Node B, and Node C may be installed with an appropriate blockchain software to create blockchain accounts, and initiate, forward, or access blockchain transactions.
  • the term “blockchain transaction” may refer to a unit of task executed in a blockchain system and recorded in the blockchain.
  • Node A1 may access the blockchain through communications with Node C, the server end 118, and Blockchain Node 1, and Node B may access the blockchain through communications with Blockchain Node 2.
  • Node A1 may submit a blockchain account creation request to Node C.
  • Node C may forward the request and other similar requests to the server end 118.
  • the server end 118 may accordingly create blockchain accounts.
  • a recipient blockchain node may perform some preliminary verification of the blockchain transaction.
  • Blockchain Node 1 may perform the preliminary verification after receiving a blockchain transaction from Node C.
  • the blockchain transaction may be stored in a database of the recipient blockchain node (e.g., Blockchain Node 1) , which may also forward the blockchain transaction to one or more other blockchain nodes (e.g., Blockchain Node 3, Blockchain Node 4) .
  • the database may be respectively stored in the memories of the blockchain nodes.
  • the database may store a pool of blockchain transactions submitted by the one or more client devices.
  • the one or more other blockchain nodes may repeat the process done by the recipient blockchain node.
  • Each blockchain node may select some of the blockchain transactions from the pool according to its preference and form them into a proposed new block for the blockchain.
  • the blockchain node may perform “mining” of the proposed new block by devoting computing power to solve complex mathematical problems.
  • the blockchain transaction involves a blockchain contract
  • the blockchain nodes may execute the blockchain contract locally in respective virtual machines (VMs) .
  • the blockchain contract may comprise instructions, code, or programs that are automatically executable by a blockchain system when one or more preset triggering conditions are met.
  • each blockchain node of the blockchain network may run a corresponding VM and executes the same instructions in the blockchain contract.
  • a VM is a software emulation of a computer system based on computer architectures and provides functionality of a physical computer.
  • VM in the blockchain context can be understood as a system designed to operate as a runtime environment for blockchain contracts.
  • a certain blockchain node that successfully mines the proposed new block of blockchain transactions in accordance with consensus rules may pack the new block into its local copy of the blockchain and multicast the results to other blockchain nodes.
  • the certain blockchain node may be a blockchain node that has first successfully completed the verification, that has obtained a verification privilege, or that has been chosen based on another consensus rule, etc. Then, the other blockchain nodes may follow the same order of execution performed by the certain blockchain node to locally execute the blockchain transactions in the new block, verify the execution results with one another (e.g., by performing hash calculations) , and synchronize their copies of the blockchain with that of the certain blockchain node.
  • the other blockchain nodes may similarly write such information in the blockchain transaction into respective local memories. As such, the blockchain contract can be deployed on the blockchain. If the verification fails at some point, the blockchain transaction is rejected.
  • the deployed blockchain contract may have an address, according to which the deployed contract can be accessed.
  • a blockchain node may invoke the deployed blockchain contract by inputting certain parameters to the blockchain contract.
  • Node C or Node B may request to invoke the deployed blockchain contract to perform various operations.
  • data stored in the deployed blockchain contract may be retrieved.
  • data may be added to the deployed blockchain contract.
  • a financial transaction specified in the deployed blockchain contract may be executed.
  • FIG. 2 illustrates a framework for implementing blockchain transactions in accordance with some embodiments.
  • the client 111 may transmit information (e.g., a request with relevant information for creating a blockchain account) to the server end 118 for the server end 118 to create a blockchain account.
  • the server end 118 may generate cryptographic keys, compile the request with other account creation requests, and/or perform other operations.
  • the server end 118 may transmit a blockchain transaction (e.g., blockchain transaction A) including the compiled account creation requests to one or more of blockchain nodes for execution.
  • a blockchain transaction e.g., blockchain transaction A
  • Node B may construct a signed blockchain transaction and transmit it to one or more blockchain nodes for execution.
  • Node B may construct a blockchain transaction B.
  • the blockchain transaction B may comprise a blockchain contract B for deployment or invoke a deployed blockchain contract.
  • the blockchain transaction B may comprise a blockchain contract that creates a blockchain account or invokes a deployed blockchain contract A.
  • the blockchain contract B may be programmed in source code at a user-end application 221.
  • a user or machine may program the blockchain contract B.
  • Node B may compile the source code using a corresponding compiler, which converts the source code into bytecode.
  • the blockchain transaction B may comprise information such as nonce (e.g., transaction serial number) , from (e.g., a blockchain address of Node B or another blockchain address) , to (e.g., empty if deploying a blockchain contract) , transaction fee, value (e.g., transaction amount) , signature (e.g., signature of Node B) , data (e.g., message to a contract account) , etc.
  • the Node B may send the blockchain transaction B to one or more blockchain nodes through a remote procedure call (RPC) interface 223 for execution.
  • RPC remote procedure call
  • RPC is a protocol that a first program (e.g., user-end application) can use to request a service from a second program located in another computer on a network (e.g., blockchain node) without having to understand the network’s details.
  • a first program e.g., user-end application
  • a network e.g., blockchain node
  • the first program causes a procedure to execute in a different address space, it is as if a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.
  • the recipient blockchain may verify if the blockchain transaction is valid. For example, the signature and other formats may be verified. If the verification succeeds, the recipient blockchain node may broadcast the received blockchain transaction (e.g., blockchain transaction A or B) to the blockchain network including various other blockchain nodes. Some blockchain nodes may participate in the mining process of the blockchain transactions. The blockchain transaction may be picked by a certain blockchain node for consensus verification to pack into a new block. If the blockchain transaction involves a blockchain contract, the certain blockchain node may create a contract account for a blockchain contract in association with a contract account address.
  • the received blockchain transaction e.g., blockchain transaction A or B
  • Some blockchain nodes may participate in the mining process of the blockchain transactions.
  • the blockchain transaction may be picked by a certain blockchain node for consensus verification to pack into a new block. If the blockchain transaction involves a blockchain contract, the certain blockchain node may create a contract account for a blockchain contract in association with a contract account address.
  • the certain blockchain node may trigger its local VM to execute the received blockchain transaction, thereby invoking the deployed blockchain contract from its local copy of the blockchain and updating the account states in the blockchain. If the certain blockchain node succeeds in mining a new block, the certain blockchain node may broadcast the new block to other blockchain nodes. The other blockchain nodes may verify the new block as mined by the certain blockchain node. If consensus is reached, the blockchain transaction B is respectively packed to the local copies of the blockchain maintained by the blockchain nodes. The blockchain nodes may similarly trigger their local VMs to execute the blockchain transaction B, thus invoking the blockchain contract A deployed on the local copies of the blockchain and making corresponding updates.
  • the other blockchain nodes may perform verifications. If a consensus is reached that the new block is valid, the new block is respectively packed to the local copies of the blockchain maintained by the blockchain nodes.
  • the blockchain nodes may similarly trigger their local VMs (e.g., local VM 1, local VM i, local VM 2) to execute the blockchain transactions in the new block, thus invoking local copies of the blockchain (e.g., local blockchain copy 1, local blockchain copy i, local blockchain copy 2) and making corresponding updates.
  • the hardware machine of each blockchain node may have access to one or more virtual machines, which may be a part of or couple to the corresponding blockchain node. Each time, a corresponding local VM may be triggered to execute the blockchain transaction. Likewise, all other blockchain transactions in the new block will be executed.
  • Lightweight nodes may also synchronize to the updated blockchain.
  • FIG. 3 illustrates an example network environment for implementing a blockchain-base gridlock resolution in accordance with some embodiments.
  • Each of the letters A, B, C, D, E in FIG. 3 represents a participant involved in asset or other transactions (e.g., an assets transfer institution such as a bank) .
  • A participates in three blockchain networks 310, 320, and 330; B participates in two blockchain networks 310 and 320; C participates in two blockchain networks 310 and 330; D and E participate in blockchain network 320 and 330 respectively.
  • Each of the blockchain networks 310, 320, 330 may be implemented as one or more of the blockchain systems 112-114 in FIGs. 1 and 2 or components thereof.
  • a participant may participate in a blockchain network by providing a blockchain node (e.g., in the form of a computing device, or a virtual machine) to the blockchain network.
  • a participant may participate in multiple blockchain networks through multiple separate computing devices, or multiple virtual machines provided by one or more physical computing devices.
  • a participant may participate in a blockchain network via one or more blockchain nodes associated with one or more other entities or via one or more interfaces provided by a platform offering various blockchain based services.
  • the platform may be implemented as the server end 118 in FIGs. 1-2 or components thereof.
  • Computing systems associated with the participants may each be implemented as the client 111 in FIGs. 1-2 or components thereof.
  • a blockchain account may be created and associated with the participant.
  • the blockchain account may comprise an account balance indicating a current balance that the participant possesses in the corresponding blockchain network.
  • the blockchain networks may support creation and transaction of blockchain based assets (e.g., tokens, cryptocurrencies) .
  • One or more participants of a common blockchain network may execute one or more asset transactions to each other by adding one or more blockchain transactions to a blockchain associated with the blockchain network.
  • blockchain-based assets may be transferred among blockchain accounts of the participants.
  • the blockchain networks may be used to record off-blockchain asset ownership and transactions.
  • One or more participants may engage in asset transactions independent of a blockchain network and record the details of the asset transactions on the blockchain associated with the blockchain network.
  • one or more participants may commit to asset transactions by adding one or more blockchain transactions representing the asset transactions to the blockchain.
  • the one or more participants may later clear the committed asset transactions via one or more off-blockchain channels.
  • a participant may have access to all its blockchain accounts on all the blockchain networks that it is engaged in. That is, the participant may transfer a certain amount of balance from one blockchain account in one blockchain network to another blockchain account on another blockchain network (e.g., redistributing its cross-network assets) . This may be achieved by internal record updates or transactions via off-blockchain channels.
  • the participant can add one or more blockchain transactions to each blockchain to update the respective account balances.
  • the blockchain-base gridlock resolution may require a resolution coordinator to coordinate the operations among the multiple blockchain networks.
  • a resolution coordinator may be implemented as a timing service 360 that notifies the participants (e.g., assets transfer institutions) the commencement of a gridlock resolution process, notifies each blockchain network that a certain phase of the resolution process (e.g., one of a plurality of iterations in the gridlock resolution process) is finished, monitors each blockchain network to detect convergences, performing another suitable task, or any combination thereof.
  • the timing service 360 may comprise a blockchain node associated with each of the blockchain networks (e.g., 310, 320, and 330) in order to interact with the other blockchain nodes in the each blockchain network, including the nodes associated with the participants.
  • the timing service 360 may submit a blockchain transaction to the blockchain networks 310, 320 and 330 to kick off a gridlock resolution process (e.g., each participant may start proposing outgoing transactions to settle once it observes the blockchain transaction) or to notify the participants that a resolution process will start at a specific time.
  • the timing service 360 may, through the blockchain nodes associated with the timing service 360, monitor the blockchain networks 310, 320 and 330 to detect blockchain transactions indicating a solution to the gridlock has been found. An embodiment of the timing service 360 is described in detail in FIG. 6.
  • FIG. 4 illustrates an example diagram of a computing system for implementing blockchain-based gridlock resolution in accordance with some embodiments.
  • the computing system 400 in FIG. 4 may refer to a computing device, a virtual machine, or another suitable terminal device that is associated with a participant (e.g., an assets transfer institution) involved in a gridlock resolution process.
  • the computing system 400 may be implemented as one or more of the components in FIGs. 1-3, such as the client 111, the server end 118, the user-end application 221.
  • the computing system 400 may enable the participant to participate in a blockchain network 440.
  • the blockchain network 440 may be implemented as one or more of the blockchain systems 112-114 in FIGs. 1 and 2 or components thereof, or one or more of the blockchain systems 310-330 in FIG. 3.
  • a participant may be associated with a plurality of such computing systems 400 to participate in a plurality of blockchain networks, respectively.
  • the computing system 400 may include a plurality of modules providing various functionalities.
  • the modules shown in FIG. 4 are exemplary. Depending on the implementation, the computing system 400 may have more, fewer, alternative modules. Some of the modules may be merged or split.
  • the computing system 400 comprises a transaction collection module 421, a transaction selection module 422, a delta determination module 423, and a blockchain interaction module 425.
  • the transaction collection module 421 of the computing device 400 may collect all outgoing transactions (e.g., outgoing payments) and all incoming transactions (e.g., incoming payments) associated with the participant from the blockchain in the blockchain network 440. These transactions may be blockchain transactions retrieved from a blockchain associated with the blockchain network 440.
  • An outgoing transaction may comprise or represent a transfer of value from a blockchain account associated with the participant (e.g., transferor) to a blockchain account associated with another participant (e.g., transferee) .
  • the transferor and transferee in the outgoing transaction may be represented by their respective unique identifiers, such as blockchain account addresses.
  • the outgoing transaction may also comprise the amount to be transferred out.
  • the amount may be represented as a ciphertext or a commitment before sending to the blockchain network 440.
  • the amounts may be homomorphically encrypted (e.g., by applying a homomorphic encryption or a homomorphic commitment scheme) .
  • the transaction selection module 422 of the computing device 400 may select a subset of the outgoing transactions collected by the transaction collection module 421 to settle.
  • the selected outgoing transactions may be determined based on various factors, such as the current balance of the participant in the current blockchain network 440, the total amount of incoming transactions that the participant presumes it may receive (e.g., based on outgoing transactions proposed by other participants in the blockchain network 440) , and/or an amount that the participant may transfer in (e.g., assets reallocation) from its other blockchain accounts in other blockchain networks.
  • the transaction selection module 422 may remove one or more outgoing transactions with a lowest priority from the subset.
  • each outgoing transaction may be associated with a certain priority ranking determined chronologically (e.g., an outgoing transaction with an older timestamp has a higher priority) .
  • the outgoing transaction’s priority ranking may be determined by other factors, such as the recipient’s priority (e.g., if the outgoing payment is being paid to a preferred client/receiver, it may have a higher priority) , a deadline of the outgoing transaction (e.g., different recipients may set different payment deadlines) , another suitable factors, or any combination thereof.
  • the delta determination module 423 of the computing device 400 may determine a delta value corresponding to the participant’s blockchain account in the blockchain network 440, where the delta value may be a variable indicating an amount to be transferred into or out of the participant’s blockchain account in the blockchain network 440.
  • the delta value may be determined based on the participant’s current balance in the blockchain account in the blockchain network 440, all the incoming transactions in the blockchain network 440 that are to be received by the participant, and the outgoing transactions selected by the transaction selection module 422 (e.g., the outgoing transactions that are proposed to settle) .
  • a total amount of the outgoing transactions is greater than a sum of the current balance and a total amount of the incoming transactions, the participant may need to transfer in some assets from its other blockchain accounts, which may be represented by a positive delta value. If the total amount of the outgoing transactions is smaller than the sum of the current balance and the total amount of the incoming transactions, the participant may be able to transfer out a certain amount to help out its other blockchain accounts to settle outgoing transactions where the certain amount may be represented by a negative delta value) .
  • each of the computing systems 400 may determine (e.g., through its delta determination module 423) a delta value such that the total sum of the plurality of delta values is 0. That is, during this internal redistribution of assets (e.g., assets redistribution among the participant’s plurality of blockchain accounts) , no liquidity may be created or diminished.
  • the participant’s plurality of computing systems 400 may communicate and determine their delta values collectively, or one of the computing systems 400 may aggregate information from others and determine the plurality of delta values for the computing systems 400.
  • the blockchain interaction module 425 of the computing device 400 may submit blockchain transactions (including blockchain contracts) to the blockchain network 440, monitor the blockchain associated with the blockchain network 440. For example, when the sum of all the delta values (e.g., respectively corresponding to the computing systems 400 of the participant) is 0, the blockchain interaction module 425 may submit a blockchain transaction comprising the outgoing transactions selected by the transactions selection module 422 and the delta value (e.g., in an encrypted format) determined by delta determination module 423 to the blockchain network 440.
  • the blockchain transaction may represent a proposal from the computing system 400 that the included outgoing transactions of the participant that may be settled.
  • the blockchain transaction may also comprise a range proof that a post-balance of the participant’s current blockchain account is non-negative after the proposed outgoing transactions are settled and the balance redistribution (e.g., with an amount to be transferred in or out represented by the delta value) is performed.
  • FIG. 5 illustrates an example blockchain contract for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • the blockchain contract 520 may be created in a blockchain associated with a blockchain network 440 that comprises a plurality of blockchain nodes.
  • the blockchain nodes may comprise computing systems such as 420A, 420B, 420C that are associated with a plurality of participants.
  • each of the computing systems may submit a blockchain transaction comprising selected outgoing transactions that are proposed to be settled by each participant.
  • These blockchain transactions (e.g., proposals) may be aggregated by the blockchain contract 520 (e.g., a smart contract) .
  • the blockchain transactions may specify the blockchain contract 520’s address and trigger certain methods of the blockchain contract 520 when submitting the corresponding proposals.
  • the blockchain contract 520 may comprise a plurality of modules, such as an aggregation module 522, a verification module 523, and a reporting module 524. Each module may comprise computer-readable code representing programs, algorithms, software methods, other suitable functional components, or any combination thereof. Depending on the implementation, the blockchain contract 520 may comprise fewer, more, or alternative modules.
  • the aggregation module 522 may be configured to receive and aggregate the proposals submitted from the computing systems such as 420A, 420B, and 420C. In some embodiments, the aggregation module 522 may be implemented as a method in the blockchain contract 520 that extracts the proposed outgoing transactions from the submitted blockchain transactions.
  • the verification module 523 may be configured to verify that a post-balance of a participant is non-negative after the participant’s proposed outgoing transactions are settled and the balance redistribution according to the delta value is performed.
  • the transaction amounts in the blockchain transactions and the delta value in the proposal may be homomorphically encrypted (e.g., in the form of a ciphertext or a commitment) , and the calculation of the post-balance may be adjusted according to the used homomorphic encryption or commitment scheme.
  • the submitted blockchain transaction may already comprise a range proof provided by the corresponding participant. In this case, the verification module 523 may need to verify the provided proof.
  • the blockchain contract may notify the corresponding blockchain node/computing system (e.g., by submitting another blockchain transaction) to re-submit another proposal, or exclude the blockchain node (e.g., the corresponding participant) from participating in the current gridlock resolution process.
  • the reporting module 524 may be configured to submit to the blockchain network 440 a blockchain transaction comprising the verified outgoing transactions that the plurality of participants in the blockchain network 440 propose to settle.
  • This blockchain transaction may be monitored by the computing systems such as 420A, 420B, 420C as an indication that the next iteration may start. Since one participant’s outgoing transactions may be another participant’s incoming transactions, for a specific participant, these verified outgoing transactions may reveal all the incoming transactions that it may receive from other participants in the blockchain network 440.
  • the blockchain transaction submitted by the reporting module 524 may be the basis for each participant to identify all incoming transactions that it may receive and adjust its proposal during the next iteration.
  • FIG. 6 illustrates an example diagram of a timing service for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • the timing service 360 may be configured to coordinate the gridlock resolution process among a plurality of blockchain networks. For example, the timing service 360 may notify each of the plurality of blockchain networks the commencement of the gridlock resolution process, notify each blockchain network that a certain iteration of the process (e.g., one of a plurality of iterations in the resolution process) is finished, monitors each blockchain network to detect convergences (e.g., a local convergence on a blockchain network, and a global convergence across all blockchain networks) , performing another suitable task, or any combination thereof.
  • the timing service 360 may comprise a plurality of blockchain nodes for the blockchain networks. The timing service 360 may perform the aforementioned operations by submitting one or more blockchain transactions to each of the blockchain networks.
  • the exemplary timing service 360 illustrated in FIG. 6 comprises a plurality of modules, including a triggering module 362, a timeout module 364, and a monitoring module 366. Depending on the implementation, the timing service 360 may have more, fewer, alternative modules. Some of the modules may be merged or split.
  • the triggering module 362 may be configured to periodically (e.g., every hour, every 6 hours, every day, every 10 minutes) submit blockchain transactions to the blockchain networks to kick off an iteration (e.g., a gridlock resolution process may comprise a plurality of iterations) by notifying the participants therein to make proposals (e.g., notifying each participant to submit a blockchain transaction comprising a list of outgoing transactions that the participant proposes to settle) .
  • the “notifying” may be understood as submitting blockchain transactions by the timing service 360 to the blockchain networks, such that participants that monitor the blockchains associated with the blockchain networks obtain the blockchain transactions.
  • the timeout module 364 may be configured to periodically submit timeout blockchain transactions to the blockchain networks to terminate a current iteration during which the participants are allowed to submit their proposals. In some embodiments, if one or more participants fail to submit proposals before timeout, they may be excluded from participating in the current gridlock resolution process. In other embodiments, these participants may be allowed to participate in the next iteration of the same gridlock resolution process.
  • the monitoring module 366 may be configured to monitor the gridlock resolution process, and determine whether a valid solution has been found, or whether no valid solution was found within a predetermined time window. For example, a valid solution to a gridlock may be found when a global convergence occurs. The global convergence occurs when each of the blockchain networks reaches a local convergence. A local convergence occurs when all proposals in the corresponding blockchain network remain the same for two or more iterations. In order to observe the convergences, the monitoring module 366 in some embodiments may monitor the blockchain transactions submitted by the blockchain contracts 520 shown in FIG. 5 (through the reporting modules 524) during a current iteration and from a last iteration, and compare the outgoing transactions included therein.
  • the timing service 360 may submit a blockchain transaction to each of the blockchain networks to announce the termination of the gridlock resolution process.
  • each blockchain contract may first determine whether a local convergence is reached, and if so, submit a corresponding blockchain transaction to notify the monitoring module 366 (e.g., when the corresponding blockchain transaction is observed by the monitoring module 366) .
  • the global convergence may be reached when the monitoring module 366 observes the local convergences on all of the plurality of blockchain networks simultaneously.
  • FIG. 7 illustrates an example workflow for implementing blockchain-base gridlock resolution in accordance with some embodiments.
  • the example workflow in FIG. 7 involves a timing service 710, a plurality of blockchain networks (e.g., 720A, 720B) , a plurality of computing systems (e.g., 730A, 730B) associated with a plurality of participants (e.g., the computing systems may refer to blockchain nodes that enable the participants to interact with the corresponding blockchain networks) , and an information service provider 770 (e.g., an oracle or notary service for importing external information, fact verification, or other suitable information into a blockchain network) .
  • an information service provider 770 e.g., an oracle or notary service for importing external information, fact verification, or other suitable information into a blockchain network
  • the timing service 710 may first notify the participants of the plurality of blockchain networks a commencement of the gridlock resolution process by submitting blockchain transactions to the plurality of blockchains (such as 720A and 720B) at steps 712A and 712B.
  • the participants may observe (e.g., through corresponding computing systems 730A and 730B) such blockchain transactions and start the process of proposing settleable outgoing transactions.
  • the process may start with each participant first performing an initialization step to obtain, by a computing system associated with the participant from the blockchain, one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the participant and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the participant.
  • the initialization step may include steps 722AA and 722AB.
  • the computing system 730A may look up the blockchain 720A hosted by the corresponding blockchain network and retrieve the corresponding participant’s all incoming transactions (e.g., transactions listing the corresponding participant’s blockchain account address as the payment recipient) and all outgoing transactions (e.g., transactions listing the participant’s blockchain account address as the payment transferor) on the blockchain 720A at step 722AA.
  • the computing system 730B may also look up the blockchain 720A to collect its corresponding incoming transactions and outgoing transactions at step 722AB.
  • each of the participants such as 730A and 730B may perform the “look up” operations on all the blockchain networks (such as blockchain 720B) that host its blockchain accounts to obtain the participant’s all incoming transactions and outgoing transactions on each of the blockchain networks.
  • participant i e.g., through participant i’s computing system
  • iteration 0 represents an initialization step (e.g., including 722AA and 722AB in FIG. 7) .
  • the of participant i may be formulated as a list of blockchain transactions, each comprising an index corresponding to the blockchain transaction, a homomorphically encrypted version of an amount of a corresponding value transfer, and an identifier associated with a recipient of the corresponding value transfer, where the homomorphically encrypted version of the transaction (e.g., payment) amount may be generated with a homomorphic commitment scheme or a homomorphic encryption scheme.
  • the list of transactions may be represented as following:
  • each Amt i, k in the may be protected by a homomorphic encryption or a homomorphic commitment scheme that supports computation on ciphertexts.
  • each Amt i, k may be protected by Pedersen Commitment.
  • each of the participants may perform an iterative method comprising the following steps during each iteration.
  • Step 1 proposing, by each computing system associated with the corresponding blockchain network (e.g., 730A and 730B associated with blockchain 720A) , a list of outgoing transactions to settle during a current iteration t to the corresponding blockchain network.
  • the proposal may be submitted as a blockchain transaction.
  • computing systems 730A and 730B may each submit to blockchain 720A a blockchain transaction at step 732A and 732B.
  • Step 1 involves a selecting step to determine the list of outgoing transactions to propose to the blockchain, which may be a subset of all the participant’s outgoing transactions.
  • this selecting step may include following sub-steps. Each of the sub-steps may be performed by each participant on each of the blockchain networks that host the participant’s blockchain accounts.
  • Sub-step 1 for participant i on blockchain network l during iteration t, calculating a minimum transfer amount ⁇ i (l) that participant i needs to settle all outgoing transactions in by taking into account all incoming transactions in and the current balance of participant i’s blockchain account in the blockchain network l.
  • the ⁇ i (l) may be calculated by obtaining a first total amount associated with the subset of the one or more first blockchain transactions (e.g., a total amount of incoming transactions in and a second total amount associated with the subset of the one or more second blockchain transactions (e.g., a total amount of outgoing transactions in determining the delta value ⁇ i (l) by subtracting a sum of the first total amount and the balance of the blockchain account from the second total amount.
  • a first total amount associated with the subset of the one or more first blockchain transactions e.g., a total amount of incoming transactions in
  • a second total amount associated with the subset of the one or more second blockchain transactions e.g., a total amount of outgoing transactions in determining the delta value ⁇ i (l) by subtracting a sum of the first total amount and the balance of the blockchain account from the second total amount.
  • participant i needs transfer-in from its other blockchain accounts on other blockchain networks in order to settle the proposed outgoing transactions in ⁇ i (l) may have a positive value representing the amount to be transferred in; if participant i may transfer out a certain amount (e.g., surplus) after settling all proposed outgoing transactions in ⁇ i (l) may have a negative value representing the amount offered to transfer out.
  • This exemplary configuration may be reversed or changed depending on the implementation.
  • Sub-step 2 for participant i on blockchain network l during iteration t, assigning where may be updated by the following sub-steps.
  • the transaction with the lowest priority may refer to the transaction with the newest submission time.
  • the “removing the lowest priority transaction from ” may be understood as the transaction with the lowest priority will not be considered again during the current gridlock resolution process (even though it may be considered in the future processes) .
  • This removed transaction may be associated with one of the blockchain networks that the participant engaged in, thus the “removing the lowest priority transaction from ” may update (e.g., by removing a transaction from) one of the lists.
  • Sub-step 4 for the participant i on the blockchain network l during iteration t, recalculating ⁇ i (l) based on and for all blockchain networks, and looping back to sub-step 3.
  • Sub-step 6 for the participant i on the blockchain network l during iteration t, adding to the blockchain a third blockchain transaction comprising one or more identifiers corresponding to the proposed subset of the one or more second blockchain transactions and an encrypted version of the delta value.
  • the third blockchain transaction may refer to a proposal from participant i, the proposal including a list of outgoing transactions to each of the blockchain networks comprising where is the proposed subset of the one or more second blockchain transactions (e.g., after skipping low priority transactions) , COM ( ⁇ i (l) ) is ⁇ i (l) protected by the Pedersen Commitment (e.g., for simplicity, the random number required by the Pedersen Commitment is omitted) , and ⁇ l is a zero-knowledge range proof of a post-balance of participant i’s blockchain account on that network is not negative.
  • the post-balance may be determined based on a difference between a first sum and a second sum, the first sum comprising the balance of the blockchain account on the blockchain and a first total amount associated with the subset of the one or more first blockchain transactions, the second sum comprising a second total amount associated with the subset of the one or more second blockchain transactions and the delta value.
  • the post-balance may be determined by the following formula: the current balance participant i’s blockchain account on that network minus the total outgoing amount in plus the total incoming amount in RecIn i (l ) and ⁇ i (l) .
  • ⁇ l may be optional.
  • Step 1 the purpose of Step 1 is to propose a list of outgoing transactions of participant i across all the blockchain networks to settle during the current iteration.
  • the proposal on blockchain network l may be based on a presumption that the incoming transactions in the RecIn i (l ) are all available to participant i (e.g., participant i presumes it will receive all of the incoming transactions in RecIn i (l ) ) .
  • RecIn i (l ) may change after all participants submit their proposals. For example, participant i may realize some of its incoming transactions are unavailable if the corresponding transferors (e.g., other participants) do not propose the corresponding outgoing transactions (e.g., the transactions with participant i as the recipient) to settle.
  • participant i in Step 1 may directly determine a global set of outgoing transactions that participant i may settle by considering its global current balance and a global set of incoming transactions (e.g., ⁇ l RecIn i (l) ) .
  • the determination may skip a minimum number of outgoing transactions with lower priorities so that a total sum of the global current balance and the global set of incoming transactions is no less than a total sum of the remaining outgoing transactions.
  • the remaining outgoing transactions may be referred to as the global set of outgoing transactions.
  • participant i may submit to each of the blockchain networks a blockchain transaction (e.g., making a proposal) comprising a subset of the global set of outgoing transactions that are associated with the each blockchain network.
  • the selection of the global set of outgoing transactions may be performed by one of participant i’s computing systems by exchanging information (e.g., current balances, incoming and outgoing transactions) with participant i’s other computing systems.
  • the Step 1 may be formulated as: determining a first total amount by aggregating a plurality of values associated with a global set of first blockchain transactions available to the participant or entity (the available first blockchain transactions may be determined based on one or more blockchain transactions (e.g., third blockchain transactions as described under sub-step 6 above) sent by the transferors of the first blockchain transactions identifying proposed outgoing transactions of the transferors) , wherein the global set of first blockchain transactions comprises the one or more first blockchain transactions for each of the plurality of blockchains; determining a second total amount by aggregating a global set of balances, wherein the global set of balances comprises the balance of the blockchain account of the entity on each of the plurality of blockchains selecting one or more second blockchain transactions from a global set of second blockchain transactions such that a sum of one or more values associated with the selected one or more second blockchain transactions is no greater than a sum of the first total amount and the second total amount, wherein the global set of second blockchain transactions comprises the obtained one or more second blockchain transactions for each of the
  • Step 2 on each of the blockchain networks, aggregating, through a blockchain contract, the proposals submitted from all the participants in the blockchain network.
  • the blockchain contract may submit a blockchain transaction to the blockchain network comprising a list of aggregated outgoing transactions that the participants proposed to settle at 724A.
  • the list of aggregated outgoing transactions may be represented as a list of the transaction indexes of the aggregated outgoing transactions.
  • the list of aggregated outgoing transactions received during the current iteration may be compared against the list of aggregated outgoing transactions received during the previous iteration in order to detect convergence (e.g., convergence occurs when the two lists are the same) .
  • the solution/result of the gridlock resolution process is reached when the blockchain networks are all converged. In some embodiments, this comparison may be performed by the timing service 710.
  • Step 3 obtaining, by the computing system from each of the blockchain networks, one or more blockchain transactions generated by the blockchain contract, the one or more blockchain transactions comprising a plurality of identifiers; and determining the subset of the one or more first blockchain transactions (e.g., incoming transactions) based on the plurality of identifiers, repeating Steps 1-3 until a global convergence is observed.
  • the one or more blockchain transactions may refer to the blockchain transaction submitted by the blockchain contract after aggregating the outgoing transactions proposed during the most recent iteration by the participants in the blockchain.
  • these aggregated outgoing transactions may allow each participant to determine whether the incoming transactions in the (for the participant i on the blockchain network l during iteration t) from the previous iteration t are available, and adjust for the next iteration t+1 by skipping the unavailable incoming transactions (e.g., the transactions that are not proposed to settle by the transferor) . With being adjusted, participant i may accordingly adjust its proposal.
  • the computing system 730A and the computing system 730B may observe and retrieve the blockchain transaction submitted by the blockchain contract at 726AA and 726AB, respectively, where the blockchain transaction comprises the outgoing transactions proposed by all the participants of the blockchain 720A during the previous iteration.
  • Step 4 once a global convergence is observed, terminating the gridlock resolution process.
  • the blockchain contract on each of the blockchains may determine whether there is a local convergence (e.g., whether the proposals received from the participant in the corresponding blockchain remain the same in the previous two or more consecutive iterations) . It may be noted that, a blockchain that reaches a local convergence at one iteration may diverge in the next iteration. Therefore, the global convergence may be observed when each of the blockchains reaches its local convergence during the same iteration.
  • each local convergence may result in a blockchain event being logged.
  • the event is a dispatched signal that a blockchain contract may fire, and may be listened or monitored by a party connected to the blockchain network (e.g., decentralized applications connected to Ethereum JSON-RPC API) .
  • the timing service 710 may monitor each of the blockchains to observe the blockchain events indicating local convergences during the same iteration (e.g., at steps 714A and 714B in FIG. 7) .
  • the timing service 710 may submit, through its blockchain nodes, a blockchain transaction to each of the blockchains (e.g., 720A and 720B) to announce a result of the gridlock resolution has been reached.
  • the blockchain transaction submitted to a blockchain may comprise the locally converged proposals received from the participants of the blockchain.
  • Each proposal may include a participant’s list of outgoing transactions to be settled, and a delta value indicating an amount to be transferred into or out of the participant’s blockchain account on the blockchain.
  • the delta value in the each proposal may be represented as a homomorphic commitment, or a homomorphically encrypted value based on a public key shared by the participants (e.g., a regulator’s public key) .
  • Step 5 settling, by each participant on each blockchain network, the proposed outgoing transactions.
  • This step may be triggered in various ways.
  • each participant may monitor (e.g., through its computing systems) the blockchains for the global convergence blockchain transaction submitted by the timing service 710. Once such blockchain transaction is observed, the participant may proceed to settle the outgoing transactions it proposed during the last iteration. Since each proposal comprises the delta value indicating assets redistribution among the participant’s blockchain accounts, the participant may perform the redistribution first, followed by settling the proposed outgoing transactions.
  • These operations e.g., assets redistribution and settling outgoing transactions
  • the blockchain networks may support creation and transaction of blockchain based assets (e.g., tokens, cryptocurrencies) .
  • blockchain based assets e.g., tokens, cryptocurrencies
  • One or more participants of a common blockchain network may execute one or more asset transactions to each other by adding one or more blockchain transactions to a blockchain associated with the blockchain network.
  • blockchain-based assets may be transferred among blockchain accounts of the participants and the balances of the blockchain accounts are updated accordingly.
  • the blockchain networks may be used to record off-blockchain asset ownership and transactions.
  • One or more participants may engage in asset transactions independent of a blockchain network and record the details of the asset transactions on the blockchain associated with the blockchain network.
  • one or more participants may commit to asset transactions by adding one or more blockchain transactions representing the asset transactions to the blockchain. The one or more participants may later clear the committed asset transactions via one or more off-blockchain channels.
  • an information service provider such as a notary service provider or an oracle 770 may be adopted to observe the global convergence, verify that each participant does not create or destroy any asset or liquidity, sign on the gridlock result, and submit blockchain transactions with its signature to the blockchains (e.g., at steps 772A and 772B) to enable each participant to perform the assets redistribution and outgoing transaction settlement.
  • the final proposals e.g., the proposals shown in the (b) Cross-Network Gridlock Resolution section of FIG.
  • each participant on each blockchain network not only include the transaction identifiers, but also the amount to be transferred in or out of the participant’s blockchain account on the blockchain network (i.e., ⁇ i (l) for participant i’s blockchain account on blockchain j)
  • the information service provider e.g., the oracle 770
  • may verify that for each participant i, its aggregated transferring amount should be equal to 0, i.e., ⁇ l ⁇ i (l) 0, where l ⁇ ⁇ all the blockchain networks ⁇ .
  • the ⁇ i (l) in some embodiments may be protected by Peterson Commitment (or another suitable homographic encryption/commitment scheme) as COM ( ⁇ (l) ) .
  • the information service provider may sign the proposals with its privacy key and submit the signatures back to the corresponding blockchain networks in the form of blockchain transactions.
  • the smart contract on each blockchain network may verify the received signatures based on the information service provider’s public key. Once the verifications are successful, the smart contract may settle all the payment messages in the aggregated set and update each participant’s account balance according to the corresponding delta value and aggregation results.
  • FIG. 8 illustrates an example application of blockchain-base gridlock resolution in accordance with some embodiments.
  • the (a) Before Netting section of FIG. 8 illustrates an initial setup including two blockchain networks X and Y and four participants A, B, C, and D (e.g., banks) . As shown, A, B, C participate in network X and A, B, D participate in network Y. A’s blockchain account in network X has one outgoing transaction obligation represented as:
  • Ind (2) is a unique identifier of this outgoing transaction within the network X
  • Amt(Com (12, *) ) is a Peterson Commitment protected transaction amount (in this case, 12)
  • Rec(C) specifies the recipient of the transaction (in this case, C) .
  • the transaction amount may be protected by another suitable homomorphic encryption scheme or homomorphic commitment scheme, which is not limited in this specification.
  • the required random number for a Peterson Commitment representation is represented as *.
  • C’s blockchain account in network X has one outgoing transaction obligation (Ind (1) , Amt (Com (5, *) ) , Rec (B) ) , representing a payment from C to B in network X for an amount of 5.
  • B’s blockchain account in network Y has one outgoing transaction (Ind (1) , Amt (Com (20, *) ) , Rec (D) ) , representing a payment from B to D in network Y for an amount of 20.
  • D’s blockchain account in network Y has one outgoing transaction (Ind (2) , Amt (Com (25, *) ) , Rec (A) ) , representing a payment from D to A in network Y for an amount of 25.
  • A’s blockchain account in network X has a current balance 5, which is also protected by Peterson Commitment in the form of Com (5, *) as shown in FIG. 8.
  • B and C each has a current balance of Com (5, *) in network X
  • A, B, and D each has a current balance of Com (5, *) in network Y.
  • a gridlock resolution process may start when the participants receive a signal (e.g., by observing a blockchain transaction submitted by a timing service 360 in FIG. 6, or by following a pre-negotiated schedule) .
  • the gridlock resolution process may comprise a plurality of iterations. During each iteration, each participant proposes a list of its outgoing transactions to settle.
  • A first collects all its incoming transactions, all its outgoing transactions, and all its current balances.
  • A has one incoming transaction from D in network Y: (Ind (2) , Amt (Com (25, *) ) , Rec (A) ) , and one outgoing transactions: (Ind (2) , Amt (Com (12, *) ) , Rec (C) ) on network X.
  • A has two current balances corresponding to its two blockchain accounts: 5 for each.
  • the total incoming transactions to A may yield an amount of 25 (from D)
  • the total current balance of A is 10 (5 from network X and 5 from network Y) , therefore A’s total assets available is 35. Since A only has one outgoing transaction of 12 to C, it has sufficient assets to settle (Ind (2) , Amt (Com (12, *) ) , Rec (C) ) . However, A’s current balance in network X is only 5, and there is no incoming transaction to A in network X.
  • A may determine a delta value (e.g., ⁇ A (X) ) as the amount to be transferred from A’s another blockchain account.
  • A e.g., through A’s computing system associated with network X
  • Payout refers to a list of A’s outgoing transactions to settle in network X
  • Delta specifies an amount to be transferred into or out of A’s blockchain account in network X (e.g., a positive 7 means A needs to transfer in 7)
  • ⁇ A refers to a range proof that A’s post-balance after settling the outgoing transactions in Payout is not negative.
  • ⁇ A may be optional.
  • Payout has the outgoing transaction index Ind (2) (referring to the outgoing transaction from A to C in network X) .
  • A may also submit a blockchain transaction to network Y comprising the following proposal:
  • Payout here is empty because A does not have outgoing transaction to settle in network Y
  • Delta has a negative 7 indicating that A proposes to transfer out 7 from its blockchain account in network Y
  • ⁇ A is the optional range proof.
  • participants B, C, D may also make their proposals during the first iteration as shown in FIG. 8.
  • their Delta are 0 (indicating they will not transfer in or out any amount) .
  • These proposals may be submitted to a blockchain contract in each of the networks.
  • This blockchain contract may aggregate all the outgoing transactions proposed by all the participants in the corresponding network.
  • the blockchain contract in network X may aggregate a list of proposed outgoing transactions, including ⁇ Ind (2) , Ind (1) ⁇ , where Ind (2) is proposed by A, and Ind (1) is proposed by C.
  • the blockchain contract in network Y may aggregate a list including ⁇ Ind (1) , Ind (2) ⁇ , where Ind (1) is proposed by B, and Ind (2) is proposed by D.
  • This aggregated lists of outgoing transactions may be used by each of the participants in the next iteration to determine whether its presumed incoming transactions are actually available. For example, in iteration 1, A presumes that its incoming transaction from D in network Y: (Ind (2) , Amt (Com (25, *) ) , Rec (A) ) is available. After iteration 1, the aggregated lists show that the transaction Ind (1) in network Y is proposed by D, which means this incoming transaction is still available during the next iteration. As a result, A may again make the same proposal as it did last iteration (as the incoming transactions, current balances, and outgoing transactions have not changed) in both network X and network Y.
  • each of the blockchain contracts on the networks may determine whether the proposals received are converged (e.g., whether the proposals received during this iteration are the same as the ones received during the last iteration) . If convergence is observed, the each blockchain contract may log a blockchain event to announce a local convergence corresponding to the network. The timing service or another suitable cross-network coordinator may observe such local convergences events and determine whether a global convergence has been reached. In this case, both networks have observed convergences, and thus the global convergence has been reached, and a result of the gridlock resolution has been found.
  • a netting process may be triggered by a signature from the notary to settle all the participant’s proposals and updates their post-balance simultaneously within each network.
  • A may transfer an amount of 7 from its blockchain account in network Y to its blockchain account on network X;
  • B may transfer an amount of 15 from its blockchain account in network X to its blockchain account on network Y.
  • the netting may be required to actually settle (e.g., pay) the proposed outgoing transactions.
  • FIG. 9 illustrates an example method for implementing a blockchain-base gridlock resolution in accordance with some embodiments.
  • the method 900 may be performed by a device, apparatus, or system for optimizing resource allocation.
  • the method 900 may be performed by one or more modules/components of the environment or system illustrated by FIGs. 1-8, such as the computing system 400 in FIG. 4.
  • the operations of the method 900 presented below are intended to be illustrative. Depending on the implementation, the method 900 may include additional, fewer, or alternative steps performed in various orders or in parallel.
  • Block 910 includes for each blockchain of a plurality of blockchains: obtaining, by a computing system associated with an entity from the blockchain, one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the entity and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the entity.
  • Block 920 includes conducting, by the computing system associated with the entity, one or more iterations of a transaction-selection process.
  • each of the one or more iterations of the transaction-selection process comprises: determining a subset of the one or more first blockchain transactions; selecting a subset of the one or more second blockchain transactions based on the determined subset of the one or more first blockchain transactions and a balance of a blockchain account of the entity on the blockchain; determining a delta value associated with the blockchain based on the subset of the one or more first blockchain transactions, the subset of the one or more second blockchain transactions, and the balance of the blockchain account on the blockchain, wherein the delta value corresponds to a value transfer between the blockchain account on the blockchain and one or more different blockchain accounts of the entity on one or more different blockchains of the plurality of blockchains; and adding to the blockchain a third blockchain transaction comprising one or more identifiers corresponding to the selected subset of the one or more second blockchain transactions and an encrypted version of the delta value.
  • the adding to the blockchain a third blockchain transaction comprises: sending the third blockchain transaction to one or more blockchain nodes associated with blockchain to add to the blockchain, wherein the third blockchain transaction invokes a blockchain contract on the blockchain, and wherein the blockchain contract is executable to aggregate the one or more identifiers in the third blockchain transaction with a plurality of other identifiers in a plurality of other blockchain transactions.
  • the determining a subset of the one or more first blockchain transactions comprises: for a first iteration among the one or more iterations of the transaction-selection process: determining the subset of the one or more first blockchain transactions as including each of the one or more first blockchain transactions; and for each of one or more iterations, other than the first iteration, among the one or more iterations of the transaction-selection process: obtaining, by the computing system from the blockchain, one or more blockchain transactions generated by the blockchain contract, the one or more blockchain transactions comprising a plurality of identifiers; and determining the subset of the one or more first blockchain transactions based on the plurality of identifiers.
  • the selecting a subset of the one or more second blockchain transactions comprises: determining a first total amount by aggregating a plurality of values associated with a global set of first blockchain transactions, wherein the global set of first blockchain transactions comprises the one or more first blockchain transactions for each of the plurality of blockchains; determining a second total amount by aggregating a global set of balances, wherein the global set of balances comprises the balance of the blockchain account of the entity on each of the plurality of blockchains; and selecting one or more second blockchain transactions from a global set of second blockchain transactions such that a sum of one or more values associated with the selected one or more second blockchain transactions is no greater than a sum of the first total amount and the second total amount, wherein the global set of second blockchain transactions comprises the obtained one or more second blockchain transactions for each of the plurality of blockchains.
  • the global set of second blockchain transactions are respectively associated with priority rankings; and the selecting the one or more second blockchain transactions from the global set of second blockchain transactions comprises selecting the one or more second blockchain transactions based on the priority rankings.
  • the priority rankings of the global set of second blockchain transactions are determined chronologically.
  • the determining a delta value associated with the blockchain comprises: obtaining a first total amount associated with the subset of the one or more first blockchain transactions and a second total amount associated with the subset of the one or more second blockchain transactions; determining the delta value by subtracting a sum of the first total amount and the balance of the blockchain account from the second total amount.
  • the encrypted version of the delta value is generated based on a homomorphic commitment scheme or a homomorphic encryption scheme.
  • each blockchain transaction of the one or more first blockchain transactions and the one or more second blockchain transactions comprises: an index corresponding to the blockchain transaction, a homomorphically encrypted version of an amount of corresponding value transfer, and an identifier associated with a recipient of the corresponding value transfer, wherein the homomorphically encrypted version of the value transfer amount based on a homomorphic commitment scheme or a homomorphic encryption scheme.
  • the third blockchain transaction further comprises a zero-knowledge range proof that a first sum is not less than a second sum, the first sum comprising the balance of the blockchain account on the blockchain and a first total amount associated with the subset of the one or more first blockchain transactions, the second sum comprising a second total amount associated with the subset of the one or more second blockchain transactions and the delta value.
  • Block 930 includes terminating the one or more iterations of the transaction-selection process in response to obtaining a fourth blockchain transaction from the blockchain, the fourth blockchain transaction indicating convergence of transaction selection on each of the plurality of blockchains.
  • the method 900 may further comprise, prior to conducting the one or more iterations of the transaction-selection process: obtaining, by the computing system, a blockchain transaction in each of the blockchains indicating a beginning of the transaction-selection process.
  • the method 900 may further comprise, for each blockchain of the plurality of blockchains: obtaining, from the blockchain, a fifth blockchain transaction comprising a proof that a sum of a global set of delta values associated with the entity equals zero, wherein the global set of delta values comprises the delta value associated with each of the plurality of blockchains.
  • FIG. 10 illustrates an example block diagram of a computing system for implementing a blockchain-base gridlock resolution in accordance with some embodiments.
  • the components of the computer system 1000 presented below are intended to be illustrative. Depending on the implementation, the computer system 1000 may include additional, fewer, or alternative components.
  • the computer system 1000 may be an example of an implementation of one or more components of the computing system 400.
  • the flows and methods illustrated in FIGs. 1-9 may be implemented by the computer system 1000.
  • the computer system 1000 may comprise one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processor) to perform the above-described method, e.g., the method 900.
  • the computer system 1000 may comprise various units/modules corresponding to the instructions (e.g., software instructions) .
  • the computer system 1000 may be referred to as an apparatus for executing a blockchain-based gridlock resolution.
  • the apparatus may comprise an obtaining module 1010, a transaction selection module 1020, and a termination module 1030.
  • the obtaining module 1010 may, for each blockchain of a plurality of blockchains obtain one or more first blockchain transactions respectively corresponding to one or more incoming value transfers associated with the entity and one or more second blockchain transactions respectively corresponding to one or more outgoing value transfers associated with the entity.
  • the transaction selection module 1020 may conduct one or more iterations of a transaction-selection process, wherein each of the one or more iterations of the transaction-selection process comprises: determining a subset of the one or more first blockchain transactions; selecting a subset of the one or more second blockchain transactions based on the determined subset of the one or more first blockchain transactions and a balance of a blockchain account of the entity on the blockchain; determining a delta value associated with the blockchain based on the subset of the one or more first blockchain transactions, the subset of the one or more second blockchain transactions, and the balance of the blockchain account on the blockchain, wherein the delta value corresponds to a value transfer between the blockchain account on the blockchain and one or more different blockchain accounts of the entity on one or more different blockchains of the plurality of blockchains; and adding to the blockchain a third blockchain transaction comprising one or more identifiers corresponding to the selected subset of the one or more second blockchain transactions and an encrypted version of the delta value.
  • the termination module 1030 may terminate the one or more iterations of the transaction-selection process in response to obtaining a fourth blockchain transaction from the blockchain, the fourth blockchain transaction indicating convergence of transaction selection on each of the plurality of blockchains.
  • the techniques described herein may be implemented by one or more special-purpose computing devices.
  • the special-purpose computing devices may be desktop computer systems, server computer systems, portable computer systems, handheld devices, networking devices or any other device or combination of devices that incorporate hard-wired and/or program logic to implement the techniques.
  • the special-purpose computing devices may be implemented as personal computers, laptops, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or a combination thereof.
  • Computing device (s) may be generally controlled and coordinated by operating system software.
  • GUI graphical user interface
  • the various systems, apparatuses, storage media, modules, and units described herein may be implemented in the special-purpose computing devices, or one or more computing chips of the one or more special-purpose computing devices.
  • the instructions described herein may be implemented in a virtual machine on the special-purpose computing device. When executed, the instructions may cause the special-purpose computing device to perform various methods described herein.
  • the virtual machine may include a software, hardware, or a combination thereof.
  • FIG. 11 illustrates an example block diagram of a computer system in which any of the embodiments described herein may be implemented.
  • the computing device may be used to implement one or more components of the systems and the methods shown in FIGs. 1-10
  • the computing device 1100 may comprise a bus 1102 or other communication mechanism for communicating information and one or more hardware processors 1104 coupled with bus 1102 for processing information.
  • Hardware processor (s) 1104 may be, for example, one or more general purpose microprocessors.
  • the computing device 1100 may also include a main memory 1107, such as a random-access memory (RAM) , cache and/or other dynamic storage devices, coupled to bus 1102 for storing information and instructions to be executed by processor (s) 1104.
  • Main memory 1107 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor (s) 1104.
  • Such instructions when stored in storage media accessible to processor (s) 1104, may render computing device 1100 into a special-purpose machine that is customized to perform the operations specified in the instructions.
  • Main memory 1107 may include non-volatile media and/or volatile media. Non-volatile media may include, for example, optical or magnetic disks. Volatile media may include dynamic memory.
  • Common forms of media may include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a DRAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, or networked versions of the same.
  • the computing device 1100 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computing device may cause or program computing device 1100 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computing device 1100 in response to processor (s) 1104 executing one or more sequences of one or more instructions contained in main memory 1107. Such instructions may be read into main memory 1107 from another storage medium, such as storage device 1109. Execution of the sequences of instructions contained in main memory 1107may cause processor (s) 1104 to perform the process steps described herein. For example, the processes/methods disclosed herein may be implemented by computer program instructions stored in main memory 1107. When these instructions are executed by processor (s) 1104, they may perform the steps as shown in corresponding figures and described above. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.
  • the computing device 1100 also includes a communication interface 1110 coupled to bus 1102.
  • Communication interface 1110 may provide a two-way data communication coupling to one or more network links that are connected to one or more networks.
  • communication interface 1110 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicate with a WAN) .
  • LAN local area network
  • Wireless links may also be implemented.
  • processors or processor-implemented engines may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm) . In other example embodiments, the processors or processor-implemented engines may be distributed across a number of geographic locations.
  • the software product may be stored in a storage medium, comprising a number of instructions to cause a computing device (which may be a personal computer, a server, a network device, and the like) to execute all or some steps of the methods of the embodiments of the present application.
  • the storage medium may comprise a flash drive, a portable hard drive, ROM, RAM, a magnetic disk, an optical disc, another medium operable to store program code, or any combination thereof.
  • Particular embodiments further provide a system comprising a processor and a non-transitory computer-readable storage medium storing instructions executable by the processor to cause the system to perform operations corresponding to steps in any method of the embodiments disclosed above.
  • Particular embodiments further provide a non-transitory computer-readable storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform operations corresponding to steps in any method of the embodiments disclosed above.
  • Embodiments disclosed herein may be implemented through a cloud platform, a server or a server group (hereinafter collectively the “service system” ) that interacts with a client.
  • the client may be a terminal device, or a client registered by a user at a platform, wherein the terminal device may be a mobile terminal, a personal computer (PC) , and any device that may be installed with a platform application program.
  • PC personal computer
  • the various operations of exemplary methods described herein may be performed, at least partially, by an algorithm.
  • the algorithm may be comprised in program codes or instructions stored in a memory (e.g., a non-transitory computer-readable storage medium described above) .
  • Such algorithm may comprise a machine learning algorithm.
  • a machine learning algorithm may not explicitly program computers to perform a function but can learn from training data to make a prediction model that performs the function.
  • processors may be temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented engines that operate to perform one or more operations or functions described herein.
  • the methods described herein may be at least partially processor-implemented, with a particular processor or processors being an example of hardware.
  • a particular processor or processors being an example of hardware.
  • the operations of a method may be performed by one or more processors or processor-implemented engines.
  • the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS) .
  • SaaS software as a service
  • at least some of the operations may be performed by a group of computers (as examples of machines including processors) , with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an Application Program Interface (API) ) .
  • API Application Program Interface
  • processors or processor-implemented engines may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm) . In other example embodiments, the processors or processor-implemented engines may be distributed across a number of geographic locations.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Procédés, systèmes, et appareil, comprenant des programmes informatiques codés sur des supports de stockage informatiques, permettant la résolution d'obstruction basée sur une chaîne de blocs. Le procédé peut consister, pour chaque chaîne de blocs d'une pluralité de chaînes de blocs : à obtenir, par un système informatique associé à une entité à partir de la chaîne de blocs, une ou plusieurs premières transactions de chaîne de blocs correspondant respectivement à un ou plusieurs transferts de valeurs entrants associés à l'entité et une ou plusieurs deuxièmes transactions de chaîne de blocs correspondant respectivement à un ou plusieurs transferts de valeurs sortants associés à l'entité ; à effectuer, par le système informatique associé à l'entité, une ou plusieurs itérations d'un processus de sélection de transaction ; et à terminer la ou les itérations du processus de sélection de transaction en réponse à l'obtention d'une quatrième transaction de chaîne de blocs à partir de la chaîne de blocs, la quatrième transaction de chaîne de blocs indiquant la convergence de la sélection de transaction sur chaque chaîne de blocs de la pluralité de chaînes de blocs.
PCT/CN2021/077289 2020-05-04 2021-02-22 Procédé et système de résolution d'obstruction basée sur une chaîne de blocs WO2021223492A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202180030787.4A CN115485687A (zh) 2020-05-04 2021-02-22 确定基于区块链的死锁解决的方法和系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10202004063TA SG10202004063TA (en) 2020-05-04 2020-05-04 Method and system for determining blockchain-based gridlock resolution
SG10202004063T 2020-05-04

Publications (1)

Publication Number Publication Date
WO2021223492A1 true WO2021223492A1 (fr) 2021-11-11

Family

ID=74218981

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/077289 WO2021223492A1 (fr) 2020-05-04 2021-02-22 Procédé et système de résolution d'obstruction basée sur une chaîne de blocs

Country Status (3)

Country Link
CN (1) CN115485687A (fr)
SG (1) SG10202004063TA (fr)
WO (1) WO2021223492A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118012721B (zh) * 2024-04-09 2024-08-06 深圳市纷享互联科技有限责任公司 数据同步检测方法、系统及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180232803A1 (en) * 2017-02-14 2018-08-16 MonetaGo Inc. Contract management system and method
US20180300476A1 (en) * 2016-11-14 2018-10-18 The Quantum Group Inc. Dynamic episodic networks
US20180373776A1 (en) * 2017-04-12 2018-12-27 Vijay K. Madisetti Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing
US20190385157A1 (en) * 2018-06-18 2019-12-19 Jpmorgan Chase Bank, N.A. Systems and methods for distributed-ledger based intercompany netting

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180300476A1 (en) * 2016-11-14 2018-10-18 The Quantum Group Inc. Dynamic episodic networks
US20180232803A1 (en) * 2017-02-14 2018-08-16 MonetaGo Inc. Contract management system and method
US20180373776A1 (en) * 2017-04-12 2018-12-27 Vijay K. Madisetti Method and System for Tuning Blockchain Scalability for Fast and Low-Cost Payment and Transaction Processing
US20190385157A1 (en) * 2018-06-18 2019-12-19 Jpmorgan Chase Bank, N.A. Systems and methods for distributed-ledger based intercompany netting

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WANG XIN; XU XIAOMIN; FEAGAN LANCE; HUANG SHENG; JIAO LIMEI; ZHAO WEI: "Inter-Bank Payment System on Enterprise Blockchain Platform", 2018 IEEE 11TH INTERNATIONAL CONFERENCE ON CLOUD COMPUTING (CLOUD), IEEE, 2 July 2018 (2018-07-02), pages 614 - 621, XP033399890, DOI: 10.1109/CLOUD.2018.00085 *

Also Published As

Publication number Publication date
SG10202004063TA (en) 2021-01-28
CN115485687A (zh) 2022-12-16

Similar Documents

Publication Publication Date Title
US11544254B2 (en) System and method for managing a blockchain cloud service
US10986177B2 (en) Systems and methods of self-forking blockchain protocol
US10579424B2 (en) Prioritization in a permissioned blockchain
US20190026821A1 (en) Intermediate blockchain system for managing transactions
US11126659B2 (en) System and method for providing a graph protocol for forming a decentralized and distributed graph database
US20200065300A1 (en) Dag based methods and systems of transaction processing in a distributed ledger
CN110431577B (zh) 用于检测重放攻击的系统和方法
US20170278100A1 (en) Cryptographically assured zero-knowledge cloud service for composable atomic transactions
US10908974B2 (en) System and method for blockchain-based notification
US10708280B2 (en) System and method for registering subscribable states in blockchain
US11367068B2 (en) Decentralized blockchain for artificial intelligence-enabled skills exchanges over a network
EP3688702B1 (fr) Système et procédé pour notification à base de chaîne de blocs
US11281489B2 (en) System and method for registering subscribable sub-states in blockchain
WO2021223493A1 (fr) Procédé et système de gestion de prêt basée sur chaîne de blocs
CN112513914A (zh) 基于区块链的隐私交易中提供隐私和安全保护的系统和方法
US11487736B2 (en) Blockchain transaction processing systems and methods
WO2021223492A1 (fr) Procédé et système de résolution d'obstruction basée sur une chaîne de blocs
Yewale Study of blockchain-as-a-service systems with a case study of hyperledger fabric implementation on Kubernetes
CN111162970B (zh) 在区块链系统中测试去中心化应用服务器的方法及装置
Xiang et al. Research on Trusted Service Assurance for IoT: A Blockchain Smart Contract-Based Method

Legal Events

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

Ref document number: 21800260

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21800260

Country of ref document: EP

Kind code of ref document: A1