WO2021023094A1 - Procédés et dispositifs permettant d'exécuter des contrats de verrouillage temporel hachés n fois - Google Patents

Procédés et dispositifs permettant d'exécuter des contrats de verrouillage temporel hachés n fois Download PDF

Info

Publication number
WO2021023094A1
WO2021023094A1 PCT/CN2020/105895 CN2020105895W WO2021023094A1 WO 2021023094 A1 WO2021023094 A1 WO 2021023094A1 CN 2020105895 W CN2020105895 W CN 2020105895W WO 2021023094 A1 WO2021023094 A1 WO 2021023094A1
Authority
WO
WIPO (PCT)
Prior art keywords
htlc
hash
blockchain
request
lock
Prior art date
Application number
PCT/CN2020/105895
Other languages
English (en)
Inventor
Shengjiao CAO
Yuan Yuan
Hui Fang
Original Assignee
Advanced New Technologies Co., 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 Advanced New Technologies Co., Ltd. filed Critical Advanced New Technologies Co., Ltd.
Publication of WO2021023094A1 publication Critical patent/WO2021023094A1/fr

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • 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/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/3297—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 involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the specification relates generally to computer technologies, and more particularly, to methods and devices for executing N-time hashed time lock contracts.
  • Blockchain systems also known as distributed ledger systems (DLSs) or consensus systems, may enable participating parties to store data securely and immutably.
  • Blockchain systems may include any DLSs, without referencing any particular use case, and may be used for public, private, and consortium blockchain networks.
  • a public blockchain network is open for all entities to use the system and participate in the consensus process.
  • a private blockchain network is provided for a particular entity, which centrally controls read and write permissions.
  • a consortium blockchain network is provided for a select group of entities, which control the consensus process, and includes an access control layer.
  • a blockchain system is implemented using a peer-to-peer (P2P) network, in which the nodes communicate directly with each other, e.g., without the need of a fixed, central server. Each node in the P2P network may initiate communication with another node in the P2P network.
  • P2P peer-to-peer
  • a blockchain system maintains one or more blockchains.
  • a blockchain is a data structure for storing data, such as transactions, that may prevent tampering and manipulation of the data by malicious parties.
  • Users of a blockchain system may utilize the blockchain system to carry out various types of transactions.
  • parties may both own assets recorded on a blockchain maintained in the blockchain system.
  • Parties A and B may enter into an agreement to exchange, or swap, their assets on the blockchain.
  • agreements are typically carried out using smart contracts, which are computer protocols implemented in the form of computer code that are incorporated into the blockchain, to facilitate, verify, or enforce the negotiation or performance of contracts.
  • Parties A and B may want to swap assets recorded on different blockchains.
  • Party A may want to transfer a first asset, e.g., bitcoins, recorded on a first blockchain to Party B in exchange for Party B transferring a second asset, e.g., ether, recorded on a second blockchain to Party A.
  • Such operations may be referred to as cross-chain swaps.
  • a hashed time lock contract is a type of smart contract that uses a hash lock and a time lock to require that the receiving party of a transferred asset, e.g., a payment, to either acknowledge the receipt of the transfer prior to a deadline by generating cryptographic proof of the transfer, or forfeit the ability to claim the asset transferred, thereby returning the asset to the transferring party.
  • HTLCs may be utilized to implement atomic swap protocols. However, current implementations of HTLC-based atomic swap protocols require substantial amount of setup time.
  • a computer-implemented method for executing an N-time hashed time lock contract includes: recording a plurality of parameters for the N-HTLC on a blockchain, the plurality of parameters including: a hash value as an initial value of a hash lock of the N-HTLC, at least one action to be performed on the blockchain when the N-HTLC is executed, and a maximum number of times the N-HTLC can be executed; receiving a first request to execute the N-HTLC and a first hash key for unlocking the hash lock of the N-HTLC; determining whether to process the first request to execute the N-HTLC based on the first hash key, and the maximum number of times the N-HTLC can be executed; and in response to a determination to process the first request to execute the N-HTLC, performing the at least one action on the blockchain, and updating the hash lock with the first hash key so that the first hash key will serve as the hash lock for a second request to execute the N-HTLC
  • a device for executing an N-HTLC includes: one or more processors; and one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to record a plurality of parameters for the N-HTLC on a blockchain, the plurality of parameters including: a hash value as an initial value of a hash lock of the N-HTLC, at least one action to be performed on the blockchain when the N-HTLC is executed, and a maximum number of times the N-HTLC can be executed; receive a first request to execute the N-HTLC and a first hash key for unlocking the hash lock of the N-HTLC; determine whether to process the first request to execute the N-HTLC based on the first hash key, and the maximum number of times the N-HTLC can be executed; and in response to a determination to process the first request to execute the N-HTLC, perform the at least one action on the blockchain, and updating the hash lock with the first hash key so that the
  • a non-transitory computer-readable medium has stored therein instructions that, when executed by a processor of a device, cause the device to perform a method for executing an N-HTLC.
  • the method includes: recording a plurality of parameters for the N-HTLC on a blockchain, the plurality of parameters including: a hash value as an initial value of a hash lock of the N-HTLC, at least one action to be performed on the blockchain when the N-HTLC is executed, and a maximum number of times the N-HTLC can be executed; receiving a first request to execute the N-HTLC and a first hash key for unlocking the hash lock of the N-HTLC; determining whether to process the first request to execute the N-HTLC based on the first hash key, and the maximum number of times the N-HTLC can be executed; and in response to a determination to process the first request to execute the N-HTLC, performing the at least one action on the blockchain, and updating the hash lock with the first hash key so that the first
  • FIG. 1 is a schematic diagram of a blockchain system, according to an embodiment.
  • FIG. 2 is a schematic diagram of a computing device for implementing a node in a blockchain system, according to an embodiment.
  • FIG. 3 is a flow chart of a method for setting an N-time hashed time lock contract, according an embodiment.
  • FIG. 4 is a flow chart of a method for executing an N-time hashed time lock contract, according an embodiment.
  • FIG. 5 is a flow chart of a method for executing an N-time hashed time lock contract, according an embodiment.
  • FIG. 6 is a block diagram of an apparatus for executing an N-time hashed time lock contract, according to an embodiment.
  • Embodiments of the specification provide methods and devices for setting and executing hashed time lock contracts (HTLCs) .
  • the methods and devices support a one-time off-chain negotiation process where two parties, or users, can negotiate terms of an HTLC to facilitate cross-chain swaps up to N times.
  • Such HTLCs may be referred to as N-time hashed time lock contracts, or N-HTLCs.
  • the methods and devices also support a one-time on-chain setup process to record the negotiated terms as parameters of the N-HTLC.
  • the on-chain setup process can record the parameters on blockchains involved in the cross-chain swaps.
  • the blockchains can rely on the N-HTLC to ensure that swaps can take place if all users conform to the N-HTLC and that all swaps are atomic and fair. If one user deviates from the N-HTLC, that user will automatically forfeit its ability to claim the asset transferred, thereby returning the asset to the transferring user.
  • the methods and devices support a one-time off-chain negotiation process for setting up an N-HTLC so that it can be executed up to N times. This allows the users to eliminate the need to re-negotiate the HTLC up to N-1 times.
  • the methods and devices also support a one-time on-chain setup process to record the negotiated terms as parameters on blockchains. This allows the blockchains to record the parameters concisely and efficiently and eliminates the need to repeat the on-chain setup process up to N-1 times.
  • the methods and devices utilize hash chains to implement hash locks for the N-HTLC.
  • the methods and devices can automatically invalidate the N-HTLC after N number of executions, or after the N-HTLC expires. This allows the blockchains to prevent the users from executing unauthorized swaps.
  • the methods and devices further support ordering of up to N number of swaps in the N-HTLC. This allows the users to specify not only the number of swaps they agreed to perform, but also the ordering of such swaps.
  • a blockchain is a data structure that stores data, e.g., transactions, in a way that may prevent tampering and manipulation of the data by malicious parties. The transactions stored in this manner may be immutable and subsequently verified.
  • a blockchain includes one or more blocks. Each block is linked to a previous block immediately before it in the blockchain by including a cryptographic hash of the previous block. Each block also may include a timestamp, its own cryptographic hash, and one or more transactions.
  • the transactions which generally have already been verified by the nodes of the blockchain system, may be hashed and encoded into a data structure, such as a Merkle tree.
  • a Merkle tree In a Merkle tree, data at leaf nodes of the tree is hashed, and all hashes in each branch of the tree may be concatenated at a root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all data in the tree. A hash purporting to be of a transaction stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.
  • a blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains.
  • the network may be a public blockchain network, a private blockchain network, or a consortium blockchain network.
  • numerous entities such as hundreds, thousands, or even millions of entities, can operate in a public blockchain network, and each of the entities operates at least one node in the public blockchain network.
  • the public blockchain network can be considered a public network with respect to the participating entities.
  • a majority of entities (nodes) must sign every block for the block to be valid and added to the blockchain of the blockchain network.
  • Examples of public blockchain networks include particular peer-to-peer payment networks that leverage a distributed ledger, referred to as blockchain.
  • a public blockchain network may support public transactions.
  • a public transaction is shared with all of the nodes in the public blockchain network, and is stored in a global blockchain.
  • a global blockchain is a blockchain replicated across all nodes, and all nodes are in perfect state consensus with respect to the global blockchain.
  • consensus protocols include proof-of-work (POW) (e.g., implemented in the some crypto-currency networks) , proof-of-stake (POS) , and proof-of-authority (POA) .
  • PW proof-of-work
  • POS proof-of-stake
  • POA proof-of-authority
  • a private blockchain network may be provided for a particular entity, which centrally controls read and write permissions.
  • the entity controls which nodes are able to participate in the blockchain network.
  • private blockchain networks are generally referred to as permissioned networks that place restrictions on who is allowed to participate in the network, and on their level of participation (e.g., only in certain transactions) .
  • Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, a regulatory authority can control admission) .
  • a consortium blockchain network may be private among the participating entities.
  • the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (e.g., a financial institution, insurance company) .
  • a consortium of ten (10) entities e.g., financial institutions, insurance companies
  • the consortium blockchain network can be considered a private network with respect to the participating entities.
  • each entity (node) must sign every block in order for the block to be valid, and added to the blockchain.
  • at least a sub-set of entities (nodes) e.g., at least 7 entities
  • FIG. 1 illustrates a schematic diagram of a blockchain system 100, according to an embodiment.
  • the blockchain system 100 may include a plurality of nodes, e.g., nodes 102-110, configured to operate on a blockchain 120.
  • the nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network.
  • P2P peer-to-peer
  • Each of the nodes 102-110 may be a computing device, such as a computer or a computer system, configured to store a copy of the blockchain 120, or may be software running on the computing device, such as a process or an application.
  • Each of the nodes 102-110 may have a unique identifier.
  • the blockchain 120 may include a growing list of records in the form of data blocks, such as blocks B1-B5 in FIG. 1.
  • Each of the blocks B1-B5 may include a timestamp, a cryptographic hash of a previous block, and data of the present block, which may be transactions such as monetary transactions.
  • block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data of block B5.
  • a hashing operation may be performed on the previous block to generate the cryptographic hash of the previous block.
  • the hashing operation may convert inputs of various lengths into cryptographic outputs of a fixed length through a hash algorithm, such as SHA-256.
  • the nodes 102-110 may be configured to perform an operation on the blockchain 120. For example, when a node, e.g., the node 102, wants to store new data onto the blockchain 120, that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112. Based on legitimacy of the new block, e.g., validity of its signature and transactions, the other nodes may determine to accept the new block, such that the node 102 and the other nodes may add the new block to their respective copies of the blockchain 120. As this process repeats, more and more blocks of data may be added to the blockchain 120.
  • a node e.g., the node 102
  • that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112.
  • the other nodes may determine to accept the new block, such that the
  • FIG. 2 illustrates a schematic diagram of a computing device 200 for implementing a node, e.g., the node 102 (FIG. 1) , in a blockchain system, according to an embodiment.
  • the computing device 200 may include a communication interface 202, a processor 204, and a memory 206.
  • the communication interface 202 may facilitate communications between the computing device 200 and devices implementing other nodes, e.g., nodes 104-110 (FIG. 1) , in the network.
  • the communication interface 202 is configured to support one or more communication standards, such as an Internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, etc.
  • the communication interface 202 may include one or more of a Local Area Network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP) based communication device, or other communication devices for wired and/or wireless communications.
  • the communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, hybrid public/private cloud infrastructure.
  • the processor 204 may include one or more dedicated processing units, application-specific integrated circuits (ASICs) , field-programmable gate arrays (FPGAs) , or various other types of processors or processing units.
  • the processor 204 is coupled with the memory 206 and is configured to execute instructions stored in the memory 206.
  • the memory 206 may store processor-executable instructions and data, such as a copy of the blockchain 120 (FIG. 1) .
  • the memory 206 may include any type of volatile or non-volatile memory devices, or a combination thereof, such as a static random-access memory (SRAM) , an electrically erasable programmable read-only memory (EEPROM) , an erasable programmable read-only memory (EPROM) , a programmable read-only memory (PROM) , a read-only memory (ROM) , a magnetic memory, a flash memory, or a magnetic or optical disk.
  • SRAM static random-access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • magnetic memory a magnetic memory
  • flash memory or a magnetic or optical disk.
  • FIG. 3 illustrates a flow chart of a method 300 for setting a hashed time lock contract (HTLC) according to an embodiment.
  • the HTLC set by the method 300 can be executed up to N times, and the HTLC may be referred to as an N-HTLC.
  • first and second users may have accounts on first and second separate blockchains, Blockchain A and Blockchain B, respectively.
  • Blockchains A and B may be implemented on one or more blockchain systems, e.g., the blockchain system 100 (FIG. 1) and the like, as described above.
  • Blockchains A and B may be implemented to support various types of users, or parties, including, e.g., individuals, businesses, banks, financial institutions, hospitals, as well as other types of companies, organizations, and the like.
  • Asset X may include one or more units of a certain type of asset, e.g., bitcoins, or a bundle of various types of assets, recorded on Blockchain A.
  • Asset Y may include one or more units of a certain type of asset, e.g., ether, or a bundle of various types of assets, recorded on Blockchain B.
  • User 1 is willing to swap with User 2 under the same terms for a number of times, or up to N times, in the future. User 1 may reach out to User 2 using a communication channel and start a negotiation process with User 2.
  • Users 1 and 2 may negotiate specific terms of the swap, including, e.g., an exchange rate between Asset X and Asset Y, a maximum number of swaps (or times the HTLC can be executed) , N, User 1 being allowed to invoke a swap operation, an expiration time T 1 when the agreement expires on Blockchain A, and an expiration time T 2 when the agreement expires on Blockchain B.
  • An N-HTLC may be set up after Users 1 and 2 reach an agreement.
  • User 1 may generate one or more parameters for the N-HTLC based on the agreement reached by Users 1 and 2.
  • the parameters may include the values of the maximum number N, the expiration time T 1 when the agreement expires on Blockchain A, and the expiration time T 2 when the agreement expires on Blockchain B.
  • the parameters may also include a hash value H N , which may serve as an initial hash lock of the N-HTLC.
  • the hash value H N may be calculated based on a hash chain, which is a successive application of a cryptographic hash function h () to a value, s.
  • the value s may be randomly sampled and used as the value of H 0 .
  • H 1 h (H 0 )
  • H 2 h (H 1 )
  • H N h (H N-1 )
  • User 1 may send the parameters, including, e.g., the hash value H N , the maximum number N, the expiration time T 1 when the agreement expires on Blockchain A, and the expiration time T 2 when the agreement expires on Blockchain B, to User 2.
  • User 2 may have the option to verify whether the values of N, T 1 , and T 2 conform to the terms of the agreement reached between Users 1 and 2. If the values of N, T 1 , and T 2 do not conform to the agreed terms, User 2 may send an error message to User 1 indicating the mismatch. Otherwise, if the values of N, T 1 , and T 2 conform to the agreed terms, User 2 may send a confirmation message to User 1.
  • steps 302 and 304 may be performed off-chain. For example, Users 1 and 2 do not need to utilize Blockchains A and B to facilitate their negotiations regarding the terms of the N-HTLC. In this manner, the terms of the N-HTLC may be recorded on Blockchains A and B, after Users 1 and 2 reach an agreement. In some embodiments, steps 302 and 304 may only need to be performed once for the N-HTLC.
  • the N-HTLC may be set up.
  • User 1 may setup the N-HTLC by requesting recordation on Blockchain A of parameters including, e.g., the hash value H N , the maximum number N, the expiration time T 1 when the agreement expires on Blockchain A, and the action User 1 agrees to perform, i.e., transfer of Asset X to User 2.
  • User 1 may request the recordation of the parameters on Blockchain A by invoking a function, e.g., setupNHTLC (Contract_ID, Object) , made available on Blockchain A through a smart contract interface.
  • setupNHTLC Contract_ID, Object
  • Blockchain A may carry out the instructions specified in setupNHTLC (Contract_ID, Object) and record the parameters specified by User 1 on Blockchain A.
  • setupNHTLC Contract_ID, Object
  • An object can be a variable, a data structure, a function, or a method in the field of computer technologies.
  • the value of Contract_ID specified in setupNHTLC may represent a unique identifier, e.g., a universally unique identifier, assigned or generated to identify the N-HTLC.
  • the value of the initial hash lock of the N-HTLC may also be used as the unique identifier.
  • the value of Object may represent an object that contains the parameters, including H N , N, T 1 , and the action User 1 agrees to perform, recorded on Blockchain A.
  • the object may be defined as follows:
  • User 1 can specify, using the object recorded on Blockchain A, that User 1 agrees to the action of transferring Asset X to User 2 on Blockchain A (as specified in Object. Action) if User 2 can unlock the hash lock (as specified in Object. H) before the N- HTLC expires on Blockchain A (as specified in Object. T) .
  • User 1 can further specify that User 1 agrees to allow this action to be performed up to N times (as specified in Object. N) .
  • User 2 may setup the N-HTLC on Blockchain B in a similar manner. For example, at step 310, User 2 may setup the N-HTLC by requesting recordation on Blockchain B of parameters including, e.g., the hash value H N , the maximum number N, the expiration time T 2 when the agreement expires on Blockchain B, and the action User 2 agrees to perform, i.e., transfer of Asset Y to User 1. In some embodiments, User 2 may perform step 310 after step 308. Because User 2 has an account on Blockchain A, User 2 is able to identify the N-HTLC parameters of User 1 recorded on Blockchain A, including the Contract_ID of User 1 used to identify the N-HTLC. Alternatively or additionally, User 1 may provide the Contract_ID to User 2 through another communication channel.
  • the hash value H N the maximum number N
  • the expiration time T 2 when the agreement expires on Blockchain B
  • User 2 may perform step 310 after step 308. Because User 2 has an account on Blockchain A, User 2 is able to identify the N-HT
  • User 2 may request the recordation of the parameters on Blockchain B by invoking a function, e.g., setupNHTLC (Contract_ID, Object) , made available on Blockchain B through a smart contract interface.
  • a function e.g., setupNHTLC (Contract_ID, Object)
  • Blockchain B may carry out the instructions specified in setupNHTLC (Contract_ID, Object) and record the parameters specified by User 2 on Blockchain B.
  • the value of Contract_ID specified in setupNHTLC may represent the Contract_ID User 1 used to identify the N-HTLC.
  • the value of Object may represent an object that contains the parameters, including H N , N, T 2 , and the action User 2 agrees to perform on Blockchain B.
  • the object may be defined as follows:
  • User 2 can specify, using the object recorded on Blockchain B, that User 2 agrees to the action of transferring Asset Y to User 1 on Blockchain B (as specified in Object. Action) if User 1 can unlock the hash lock (as specified in Object. H) before the N- HTLC expires on Blockchain B (as specified in Object. T) .
  • User 2 can further specify that User 2 agrees to allow this action to be performed up to N times (as specified in Object. N) .
  • Users 1 and 2 may only need to carry out steps 306 through 312 once to setup the N-HTLC. After the N-HTLC is set up, Users 1 and 2 may execute the N-HTLC to facilitate swap of Assets X and Y up to N times.
  • FIG. 4 illustrates a flow chart of a method 400 for executing an N-HTLC, e.g., the N-HTLC setup by Users 1 and 2, according to an embodiment.
  • User 1 may initiate a first swap by invoking a function on Blockchain B, e.g., callNHTLC (Contract_ID, Hashkey) , to request transfer of Asset Y from User 2 to User 1 on Blockchain B.
  • User 1 may use Contract_ID to identify the N-HTLC setup by Users 1 and 2, and use Hashkey to specify a key that can be used to unlock the hash lock imposed by the N-HTLC.
  • the hash lock imposed by the N-HTLC is set to H N initially, which can be unlocked using H N-1 .
  • Blockchain B may carry out the instructions specified in callNHTLC (Contract_ID, Hashkey) . These instructions can be illustrated using pseudo code defined below:
  • Blockchain B may then proceed to perform the recorded action (i.e., Object. Action, which is to transfer Asset Y from User 2 to User 1 on Blockchain B) , update the hash lock by setting Object. H to Hashkey (i.e., setting Object. H to H N-1 , which can be unlocked using the preceding value in the hash chain, H N-2 ) , and reduce the value of Object. N by one.
  • the recorded action i.e., Object. Action, which is to transfer Asset Y from User 2 to User 1 on Blockchain B
  • H to Hashkey i.e., setting Object. H to H N-1 , which can be unlocked using the preceding value in the hash chain, H N-2
  • User 2 may respond to the swap operation initiated by User 1 by invoking a function on Blockchain A, e.g., callNHTLC (Contract_ID, Hashkey) , to request transfer of Asset X from User 1 to User 2 on Blockchain A.
  • User 2 may use Contract_ID to identify the N-HTLC setup by Users 1 and 2, and use Hashkey to specify the key that can be used to unlock the hash lock imposed by the N-HTLC.
  • the hash lock imposed by the N-HTLC is set to H N initially, which can be unlocked using H N-1 .
  • Blockchain A may carry out the instructions specified in callNHTLC (Contract_ID, Hashkey) . These instructions can be illustrated using pseudo code defined below:
  • H to H N-1 which can be unlocked using H N-2 ) , and reduce the value of Object. N by one.
  • User 1 is in possession of Asset Y on Blockchain B and User 2 is in possession of Asset X on Blockchain A.
  • the first swap operation is considered complete.
  • the N-HTLC may be executed again to carry out additional swap operations.
  • User 1 may initiate a second swap by invoking the callNHTLC (Contract_ID, Hashkey) function at step 410, which may cause Blockchain B to carry out the instructions specified in callNHTLC (Contract_ID, Hashkey) at step 412.
  • CallNHTLC Contract_ID, Hashkey
  • User 1 may set Hashkey to H N-2 , which is known to User 1 (calculated by User 1 at step 302, FIG. 3) and can be used by User 1 to unlock the updated hash lock, Object. H, because Object. H has been set to H N-1 after the first swap.
  • User 2 may retrieve the record of User 1’s second invocation of callNHTLC (Contract_ID, Hashkey) performed at step 412 and obtain the value of Hashkey, which is set to H N-2 by User 1. In this manner, User 2 can obtain the key to unlock the N-HTLC on Blockchain A for the second time, allowing User 2 to respond by invoking the callNHTLC (Contract_ID, Hashkey) function at step 414, which may cause Blockchain A to carry out the instructions specified in callNHTLC (Contract_ID, Hashkey) at step 416.
  • Contract_ID, Hashkey the callNHTLC
  • Users 1 and 2 may invoke the callNHTLC (Contract_ID, Hashkey) function up to N times to perform up to N swaps. Users 1 and 2 may set Hashkey to H N-n every time they invoke callNHTLC (Contract_ID, Hashkey) , where n is the number of times callNHTLC (Contract_ID, Hashkey) is being invoked.
  • the first time User 1 invokes callNHTLC (Contract_ID, Hashkey) , User 1 may set Hashkey to H N-1
  • the second time User 1 invokes callNHTLC (Contract_ID, Hashkey)
  • User 1 may set Hashkey to H N-2
  • the third time User 1 invokes callNHTLC (Contract_ID, Hashkey)
  • User 1 may set Hashkey to H N-3 , and so on.
  • Blockchains A and B may keep track of the number of times Users 1 and 2 are allowed to execute the swap operation specified in the N-HTLC by reducing the value of N (which is recorded on the blockchains as Object. N) every time a swap operation is performed. In this manner, Blockchains A and B can prevent unauthorized execution of the swap operation once the value of N reaches 0. In some embodiments, Blockchains A and B may delete an object once its N value reaches 0.
  • Blockchain B may only allow User 1 to perform the swap operation before the N-HTLC expires on Blockchain B at time T 2 .
  • Blockchain A may only allow User 2 to perform the swap operation before the N-HTLC expires on Blockchain A at time T 1 .
  • Blockchains A and B can prevent unauthorized execution of swap operations after the N-HTLC is set to expire.
  • User 2 is the user who responds to the swap operation initiated by User 1
  • User 2 may request setting the N-HTLC to expire on Blockchain A at time T 1 after T 2 , i.e., T 2 ⁇ 1 .
  • User 2 may verify whether T 2 is indeed set to be less than T 1 when User 2 receives the parameters from User 1 (FIG. 3 at step 304) . If the T 2 is greater than or equal to T 1 , User 2 may send an error message to User 1.
  • Users 1 and 2 may further specify the ordering of up to N number of swaps in the N-HTLC.
  • Users 1 and 2 may specify not only the number of swaps they agreed to perform, but also the ordering of such swaps. For example, Users 1 and 2 may agree to swap Asset X1 with Asset Y1 first, followed by the swap of Asset X2 with Asset Y2, and so on.
  • the ordering may be specified as an ordered list in an object defined as follows:
  • the ordered list of actions may be executed in manners similar to that described above. However, instead of repeating executions of Object. Action up to N times, a blockchain that supports the execution of an ordered list of actions may utilize a smart contract to execute instructions similar to the pseudo code defined as follows:
  • the index to Object. ActionArray [N-Object. N] , may point to the first element of the array when callNHTLC (Contract_ID, Hashkey) is invoked for the first time, allowing the blockchain to perform the action specified in Object. ActionArray [0] . Subsequently, the index [N-Object. N] may increase as the value of Object. N decreases, allowing the blockchain to perform subsequent actions specified in Object. ActionArray in an ordered manner.
  • the objects defined above are presented as examples and are not meant to be limiting. It is to be understood that the parameters contained in these objects may be stored on the blockchains in various manners. For example, in some embodiments, the various parameters described above may be stored in formats such as key-value pairs or the like. In some embodiments, prefixes may also be utilized to help distinguish key-value pairs associated with different N-HTLCs. It is also to be understood that the declarations of the functions and the pseudo code described above are presented as examples and are not meant to be limiting.
  • Cryptographic hash functions are examples of one-way functions, which are functions that are practically infeasible to invert (in other words, it is difficult to compute a value of an independent variable of a one-way function from a value of a dependent variable of the one-way function and, thus, the function is called “one-way” ) . Therefore, it is to be understood that other types of one-way functions may be utilized to facilitate locking and unlocking of N-HTLCs in manners similar to that described above.
  • FIG. 5 illustrates a flow chart of a method 500 for executing an N-HTLC, according to an embodiment.
  • the method 500 may be performed by one or more nodes in a blockchain system, e.g., the nodes 102-110 in the blockchain system 100 (FIG. 1) .
  • the nodes 102-110 in the blockchain system 100 may perform operations on a blockchain, e.g., the blockchain 120 (FIG. 1) .
  • the blockchain 120 may be implemented as either Blockchain A or B in the examples described above.
  • a node e.g., the node 102
  • the node 102 may receive the parameters from a first user, e.g., User 1 (FIG. 3) .
  • the parameters may include a hash lock, an expiration time, at least one action to be performed on the blockchain 120 when the HTLC is executed, and a maximum number of times the HTLC can be executed, which is also the maximum number of agreed swaps, prior to the expiration time.
  • User 1 can specify, using the parameters recorded on the blockchain 120, that User 1 agrees to let the at least one action to be performed on the blockchain 120 if a second user can unlock the hash lock before the expiration time.
  • User 1 can also specify that User 1 agrees to allow the HTLC to be executed up to N times. This HTLC may be referred to as an N-HTLC.
  • the node 102 may receive, e.g., from the second user, User 2 (FIG. 4) , a first request to execute the HTLC and a first hash key for unlocking the hash lock of the HTLC.
  • User 2 may submit the first request through a function call.
  • User 2 may call the function callNHTLC (Contract_ID, Hashkey) described above (step 406 of FIG. 4) .
  • the node 102 may determine whether to process the first request based on one or more of the first hash key, the expiration time, and the maximum number of times the HTLC can be executed.
  • the node 102 may apply a hash function to the first hash key to obtain a first hash value and determine whether the first hash value matches the hash lock. If the first hash value does not match the hash lock, the node 102 may determine not to process the first request.
  • the node 102 may determine whether the HTLC has expired based on the expiration time. If the HTLC has expired, the node 102 may determine not to process the first request.
  • the node 102 may determine whether the HTLC has been executed the maximum number of times. If the HTLC has been executed the maximum number of times, the node 102 may determine not to process the first request. In some embodiments, the node 102 may determine to process the first request only when it is determined that the first hash value matches the hash lock, the HTLC has not expired, and the HTLC has not been executed the maximum number of times.
  • the node 102 may proceed to step 508.
  • the node 102 may execute the at least one action defined in the HTLC on the blockchain 120.
  • the node 102 may also update the hash lock of the HTLC with the first hash key so that the first hash key will serve as the hash lock for a second request to execute the HTLC.
  • the node 102 may repeat steps 504-508 again when the node 102 receives a second request from User 2.
  • the node 102 may repeat steps 504-508 up to the maximum number of times that the HTLC can be executed.
  • the at least one action to be performed on the blockchain 120 may include at least one action to transfer an asset recorded on the blockchain 120 from the first user, e.g., User 1, to the second user, e.g., User 2.
  • the at least one action to be performed on the blockchain may include an ordered list of actions to be performed on the blockchain 120.
  • the node 102 may execute a first action listed in the ordered list of actions on the blockchain 120 when the node 102 determines to process the first request to execute the HTLC.
  • the node 102 may execute a second action listed in the ordered list of actions on the blockchain 120 when the node 102 determines to process the second request to execute the HTLC.
  • the node 102 may allow the users to specify not only the maximum number of times the HTLC is allowed to be executed, but also the ordering of the actions to be executed.
  • FIG. 6 is a block diagram of an HTLC execution apparatus 600, according to an embodiment.
  • the apparatus 600 may be an implementation of a software process, and may correspond to the method 500 (FIG. 5) .
  • the apparatus 600 may include a receiving module 602, a recording module 604, a determination module 606, and an execution module 608.
  • the receiving module 602 may receive information from users of a blockchain.
  • the receiving module 602 may receive, from a first user, parameters for an HTLC.
  • the parameters may include a hash lock, an expiration time, at least one action to be performed on the blockchain when the HTLC is executed, and a maximum number of times the HTLC can be executed prior to the expiration time.
  • the receiving module 602 may provide the received parameters to the recording module 604.
  • the recording module 604 may record the received parameters on the blockchain.
  • the recording module 604 may record the received parameters in various formats. For example, the recording module 604 may create an object that contains the received parameters as properties of the object and record the object on the blockchain.
  • the recording module 604 may also record the received parameters in other formats, including key-values pairs and the like.
  • the receiving module 602 may also receive requests from users of the blockchain. In some embodiments, the receiving module 602 may receive, from the second user, a first request to execute the HTLC and a first hash key for unlocking the hash lock of the HTLC. The receiving module 602 may provide the received request to the determination module 606.
  • the determination module 606 may determine whether to process the first request based on the first hash key, the expiration time, and the maximum number of times the HTLC can be executed. In some embodiments, the determination module 606 may apply a hash function to the first hash key to obtain a first hash value and determine whether the first hash value matches the hash lock. If the first hash value does not match the hash lock, the determination module 606 may determine not to process the first request. In some embodiments, the determination module 606 may determine whether the HTLC has expired based on the expiration time. If the HTLC has expired, the determination module 606 may determine not to process the first request. In some embodiments, the determination module 606 may determine whether the HTLC has been executed the maximum number of times.
  • the determination module 606 may determine not to process the first request. In some embodiments, the determination module 606 may determine to process the first request only when it is determined that the first hash value matches the hash lock, the HTLC has not expired, and the HTLC has not been executed the maximum number of times. The determination module 606 may then provide the first request to the execution module 608.
  • the execution module 608 may execute the at least one action defined in the HTLC on the blockchain.
  • the execution module 608 may also update the hash lock of the HTLC with the first hash key so that the first hash key will serve as the hash lock for a second request to execute the HTLC. In this manner, if the second user submits a second request to the receiving module 602 to execute the HTLC again, the receiving module 602 may provide the second request to the determination module 606, which may determine whether to provide the second request to the execution module 608 for execution.
  • each of the above described modules may be implemented as software, or hardware, or a combination of software and hardware.
  • each of the above described modules may be implemented using a processor executing instructions stored in a memory.
  • each the above described modules may be implemented with one or more application specific integrated circuits (ASICs) , digital signal processors (DSPs) , digital signal processing devices (DSPDs) , programmable logic devices (PLDs) , field programmable gate arrays (FPGAs) , controllers, micro-controllers, microprocessors, or other electronic components, for performing the described methods.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • controllers micro-controllers, microprocessors, or other electronic components, for performing the described methods.
  • each of the above described modules may be implemented by using a computer chip or an entity, or implemented by using a product having
  • the apparatus 600 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device, or any combination of these devices.
  • a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to carry out the above-described methods.
  • the computer-readable storage medium may be a tangible device that can store instructions for use by an instruction execution device.
  • the computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.
  • a non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM) , a static random access memory (SRAM) , a portable compact disc read-only memory (CD-ROM) , a digital versatile disk (DVD) , a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.
  • RAM random access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • SRAM static random access memory
  • CD-ROM compact disc read-only memory
  • DVD digital versatile disk
  • memory stick a floppy disk
  • a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon
  • the computer-readable program instructions for carrying out the above-described methods may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages.
  • the computer-readable program instructions may execute entirely on a computing device as a stand-alone software package, or partly on a first computing device and partly on a second computing device remote from the first computing device. In the latter scenario, the second, remote computing device may be connected to the first computing device through any type of network, including a local area network (LAN) or a wide area network (WAN) .
  • LAN local area network
  • WAN wide area network
  • the computer-readable program instructions may be provided to a processor of a general-purpose or special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the above-described methods.
  • a block in the flow charts or diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing specific functions.
  • the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
  • each block of the diagrams and/or flow charts, and combinations of blocks in the diagrams and flow charts may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Retry When Errors Occur (AREA)

Abstract

Des procédés, des dispositifs, et des appareils, comprenant des programmes informatiques stockés sur des supports lisibles par ordinateur, permettant d'exécuter un contrat de verrouillage temporel haché N fois (N-HTLC), sont divulgués ici. L'un des procédés comprend les étapes suivantes consistant à : enregistrer des paramètres pour le N-HTLC sur une chaîne de blocs, les paramètres comprenant : un verrou de hachage du N-HTLC, une action à effectuer sur la chaîne de blocs, et un nombre maximal de fois où le N-HTLC peut être exécuté ; recevoir une première demande d'exécution du N-HTLC et une première clé de hachage pour déverrouiller le verrou de hachage du N-HTLC ; déterminer s'il faut traiter la première demande d'exécution du N-HTLC ; et en réponse à une détermination de traitement de la première demande d'exécution du N-HTLC, effectuer l'action sur la chaîne de blocs, et mettre à jour le verrou de hachage avec la première clé de hachage de sorte que la première clé de hachage serve de verrou de hachage pour une seconde demande d'exécution du N-HTLC.
PCT/CN2020/105895 2019-08-08 2020-07-30 Procédés et dispositifs permettant d'exécuter des contrats de verrouillage temporel hachés n fois WO2021023094A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10201907330W 2019-08-08
SG10201907330WA SG10201907330WA (en) 2019-08-08 2019-08-08 Methods And Devices For Executing N-Time Hashed Time Lock Contracts

Publications (1)

Publication Number Publication Date
WO2021023094A1 true WO2021023094A1 (fr) 2021-02-11

Family

ID=70286901

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/105895 WO2021023094A1 (fr) 2019-08-08 2020-07-30 Procédés et dispositifs permettant d'exécuter des contrats de verrouillage temporel hachés n fois

Country Status (3)

Country Link
PH (1) PH12020000036A1 (fr)
SG (1) SG10201907330WA (fr)
WO (1) WO2021023094A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11323269B2 (en) * 2020-01-20 2022-05-03 International Business Machines Corporation Preserving privacy of linked cross-network transactions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107292621A (zh) * 2017-06-22 2017-10-24 丁江 海量数据确权存证方法和节点
US20170338957A1 (en) * 2016-05-23 2017-11-23 Accenture Global Solutions Limited Rewritable blockchain
CN109409877A (zh) * 2018-10-09 2019-03-01 北京网录科技有限公司 一种基于htlc技术的区块链跨链价值交互方法
CN109447634A (zh) * 2018-10-09 2019-03-08 北京网录科技有限公司 一种锁定账户秘钥更新方法及采用该方法的区块链账户管理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170338957A1 (en) * 2016-05-23 2017-11-23 Accenture Global Solutions Limited Rewritable blockchain
CN107292621A (zh) * 2017-06-22 2017-10-24 丁江 海量数据确权存证方法和节点
CN109409877A (zh) * 2018-10-09 2019-03-01 北京网录科技有限公司 一种基于htlc技术的区块链跨链价值交互方法
CN109447634A (zh) * 2018-10-09 2019-03-08 北京网录科技有限公司 一种锁定账户秘钥更新方法及采用该方法的区块链账户管理方法

Also Published As

Publication number Publication date
SG10201907330WA (en) 2020-01-30
PH12020000036A1 (en) 2021-03-22

Similar Documents

Publication Publication Date Title
US11341493B2 (en) Methods and devices for providing transaction data to blockchain system for processing
US11354657B2 (en) Managing transactions in multiple blockchain networks
US20210064585A1 (en) Methods and devices for providing traversable key-value data storage on blockchain
US11917088B2 (en) Integrating device identity into a permissioning framework of a blockchain
US11157897B2 (en) Methods and devices for managing access to account in blockchain system
EP3665595B1 (fr) Procédé et dispositif pour traversée de données
US10880383B2 (en) Methods and devices for establishing communication between nodes in blockchain system
US11403632B2 (en) Managing transactions in multiple blockchain networks
US11044104B2 (en) Data certification as a service powered by permissioned blockchain network
WO2020182233A2 (fr) Procédés et dispositifs d'exécution de contrats à swaps multiples anonymes à chaînes croisées
WO2021023094A1 (fr) Procédés et dispositifs permettant d'exécuter des contrats de verrouillage temporel hachés n fois
WO2021139391A1 (fr) Procédés et dispositifs pour réduire la fraude de financement de facture
CN110276693B (zh) 保险理赔方法及系统
WO2021223653A1 (fr) Procédés et dispositifs de protection et de vérification de transition d'état d'enregistrement
WO2021139605A1 (fr) Procédés et dispositifs de fourniture de vérification d'identité décentralisée
WO2021139545A1 (fr) Procédés et dispositifs destiné à faciliter le financement scindé de factures
WO2021139543A1 (fr) Procédés et dispositifs de gestion de lettre de crédit de soutien
US20220399988A1 (en) Linking blockchain operations
WO2021139392A1 (fr) Procédés et dispositifs de fourniture de transaction atomique sur une chaîne de blocs
WO2021139542A1 (fr) Procédés et dispositifs de fourniture de transaction atomique sur une chaîne de blocs
WO2021223661A1 (fr) Procédés et dispositifs de protection et de vérification d'informations d'état d'enregistrement
US20220036355A1 (en) Methods and devices for privacy-preserving verification of profit-sharing between users
WO2023167636A1 (fr) Procédés et dispositifs pour fournir un registre vérifiable préservant la confidentialité pour gérer des jetons

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: 20850285

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: 20850285

Country of ref document: EP

Kind code of ref document: A1