CN111640017A - Transaction correctness verification method and device applied to alliance chain cross-chain transfer - Google Patents

Transaction correctness verification method and device applied to alliance chain cross-chain transfer Download PDF

Info

Publication number
CN111640017A
CN111640017A CN202010374241.8A CN202010374241A CN111640017A CN 111640017 A CN111640017 A CN 111640017A CN 202010374241 A CN202010374241 A CN 202010374241A CN 111640017 A CN111640017 A CN 111640017A
Authority
CN
China
Prior art keywords
transaction
cross
asset
link
contract
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010374241.8A
Other languages
Chinese (zh)
Other versions
CN111640017B (en
Inventor
莫楠
贺双洪
石翔
王�章
李辉忠
张开翔
范瑞彬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WeBank Co Ltd
Original Assignee
WeBank 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 WeBank Co Ltd filed Critical WeBank Co Ltd
Priority to CN202010374241.8A priority Critical patent/CN111640017B/en
Publication of CN111640017A publication Critical patent/CN111640017A/en
Application granted granted Critical
Publication of CN111640017B publication Critical patent/CN111640017B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2255Hash tables
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2315Optimistic concurrency control
    • G06F16/2322Optimistic concurrency control using timestamps
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Databases & Information Systems (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The invention discloses a transaction correctness verification method and device applied to alliance chain cross-chain transfer, wherein the method comprises the following steps: the first cross-link route sending a first locked asset request to the second cross-link route; the first cross-link router acquires a first transaction receipt sent by the second cross-link router; generating first transaction snapshot information corresponding to the first transaction receipt by the first cross-link according to a preset format; the first cross-link route generates second transaction snapshot information according to the preset format based on the fourth transaction asset, the agreed contract number and the second agreed contract address; determining that the second cross-link routing locks the fourth transaction asset if the first cross-link routing determines that the first transaction snapshot information is consistent with the second transaction snapshot information. When the method is applied to financial technology (Fintech), the transaction correctness of the alliance chain can be supported.

Description

Transaction correctness verification method and device applied to alliance chain cross-chain transfer
Technical Field
The invention relates to the field of computer software in the field of financial technology (Fintech), in particular to a transaction correctness verification method and device applied to alliance chain cross-chain transfer.
Background
With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually changing to financial technology (Fintech), but due to the requirements of the financial industry on safety and real-time performance, higher requirements are also put forward on the technologies. In the field of financial technology, the security requirement for financial transactions is very high, and therefore financial transactions are often realized through block chains (blockchains).
Public chain cross-chain transfer of the current blockchain is generally realized based on a classic hash time locking contract, and the classic hash time locking contract needs to publicly verify the locking condition of transaction assets, namely the correctness of the transaction. However, the contract and transaction information of the federation chain is not fully disclosed, so the classic hash time-lock contract model cannot be used directly for federation chain cross-chain transfers. Therefore, the current alliance chain cannot perform the correctness verification of the transaction, which is a problem to be solved urgently.
Disclosure of Invention
The invention provides a transaction correctness verification method and device applied to alliance chain cross-chain transfer, and solves the problem that in the prior art, an alliance chain cannot perform transaction correctness verification at present.
In a first aspect, the invention provides a transaction correctness verification method applied to alliance chain cross-chain transfer, which comprises the following steps: the first cross-link route sending a first locked asset request to the second cross-link route; the first locked asset request is to indicate that a fourth transaction asset of a second account of a second user on a second blockchain is locked based on a transaction request of a first account of the first user on the first blockchain; the first cross-link router acquires a first transaction receipt sent by the second cross-link router; the first transaction receipt is the second cross-link claim of descriptive information that the fourth transaction asset has been locked; the first transaction receipt is generated based on a fourth declared asset of the fourth transaction asset, a second execution contract number, and a second execution contract address; generating first transaction snapshot information corresponding to the first transaction receipt by the first cross-link according to a preset format; the first cross-link route generates second transaction snapshot information according to the preset format based on the fourth transaction asset, the agreed contract number and the second agreed contract address; the contract number is a contract number corresponding to contract data agreed by the first user and the second user; the second contracted contract address is a contract address where the first user and the second user store the contract data in the second blockchain; determining that the second cross-link routing locks the fourth transaction asset if the first cross-link routing determines that the first transaction snapshot information is consistent with the second transaction snapshot information.
In the above method, since the first locked asset request is used to indicate that the fourth transaction asset of the second account of the second user in the second blockchain is locked based on the transaction request of the first account of the first user in the first blockchain, after the first cross-link route acquires the first transaction receipt sent by the second cross-link route, first transaction snapshot information corresponding to the first transaction receipt can be generated according to a preset format, and generating second trading snapshot information according to the preset format based on the fourth trading asset, the contracted contract number and the second contracted contract address, so that when the first transaction snapshot actually received is consistent with the expected second transaction snapshot information, then a determination is made that the second cross-link is locked for the fourth transaction asset, thereby providing a method for validation correctness of transactions applicable to the federation chain.
Optionally, after determining that the second cross-link is locked by the fourth transaction asset, the method further includes: the first cross-link route locking a first transaction asset of a first account of the first user; the first cross-link generating a second trade response piece based on a first declared asset of the first trade asset, a first execution contract number, and a first execution contract address of the first user; the second transaction receipt is used for the first cross-link by declaring that the first transaction asset has been locked; the first cross-link route sending the second transaction receipt, the first unlock asset request, and the hash pre-image to the second cross-link route; the hash pre-image is a pre-image of the contract number, and the hash pre-image is used for unlocking the fourth transaction asset after the second cross-link passes the verification of the second transaction receipt.
In the above method, the first cross-link generates a second trade receipt by a first declaration asset based on the first trade asset, a first execution contract number, and a first execution contract address of the first user; the second transaction receipt is used for the first cross-link by declaring that the first transaction asset has been locked; the first cross-link route sends the second transaction receipt, the first unlock asset request and the hash pre-image to the second cross-link route for verification of the second cross-link route and unlocking the fourth transaction asset, thereby providing a way to verify through the second cross-link route.
Optionally, after the first cross-link route sends the second transaction receipt, the first unlock asset request, and the hashed primitive to the second cross-link route, the method further includes: the first cross-link router receiving a second locked asset request sent by the second cross-link router; the first cross-link route locks a second transactional asset of a second account of the first user on the first blockchain; the first cross-link route generating a third transaction receipt based on a second express asset of the second transaction asset, a third execution contract number, and a third execution contract address; the third transaction receipt is used for the first cross-link by declaring that the second transaction asset has been locked; the first cross-link route sends the third transaction receipt to the second cross-link route for the second cross-link route to verify whether the first cross-link route locks the second transaction asset.
In the above method, after receiving a second locking asset request sent by the second cross-link route, the first cross-link route locks a second transaction asset of a second account of the first user on the first blockchain, generates a third transaction receipt, and sends the third transaction receipt to the second cross-link route, thereby providing a way of verifying whether the first cross-link route locks the second transaction asset through the second cross-link route.
Optionally, after the first cross-link route sends the third transaction receipt to the second cross-link route, the method further includes: the first cross-link router receives a fourth transaction receipt, a second unlocking asset request and the hash pre-image sent by the second cross-link router; the fourth transaction receipt is descriptive information of the second cross-link that is declared to have locked a third transaction asset of a first account of the second user on the second blockchain; the fourth trade receipt is generated based on a third declared asset, a fourth execution contract number, and a fourth execution contract address for the third trade asset; the first cross-link router generates seventh transaction snapshot information according to the fourth transaction receipt and the preset format; generating eighth trading snapshot information by the first cross-link according to the preset format based on the third trading asset, the agreed contract number and the second agreed contract address; and if the first cross-link route verifies that the seventh transaction snapshot information is consistent with the eighth transaction snapshot information, unlocking the second transaction asset according to the Hash primitive.
In the above manner, after the first cross-link router receives the fourth transaction receipt, the second asset unlocking request and the hash primitive sent by the second cross-link router, the first cross-link router generates seventh transaction snapshot information according to the preset format and the fourth transaction receipt; generating eighth trading snapshot information by the first cross-link according to the preset format based on the third trading asset, the agreed contract number and the second agreed contract address; a method of verifying that the second cross-link route locks the third transactional asset is thereby provided.
Optionally, the contract data includes a first timestamp; the first timestamp is used to trigger the first blockchain to rollback the first transaction asset to a first account of the first user when the first timestamp arrives but the first transaction asset is not unlocked.
In the above manner, the first transaction asset is timely rolled back to the first account of the first user through the first timestamp, so that the security of transaction verification is ensured.
Optionally, the contract data includes a hash primitive image, an agreed contract number and a transaction attribute; first contract data stored in the first blockchain by the first user, wherein the hash primitive, the contract number and the transaction attribute are recorded in the first contract data; and second contract data stored in the second blockchain by the second user, wherein the agreed contract number and the transaction attribute are recorded in the second contract data.
In the above manner, the first contract data and the second contract data are stored in advance in the blockchain, so that the transaction attribute can be known in advance by the first user and the second user.
Optionally, the transaction snapshot information includes the following contents: the name of the function for which the transaction was performed; input parameters for the transaction; an output result of the transaction; a contract address where the transaction is executed.
In the above manner, the transaction snapshot information can record the transaction outline through the above contents, so as to verify whether the transaction is correct or not with a small data volume.
In a second aspect, the present invention provides a transaction correctness verification device applied to alliance chain cross-chain transfer, including: a transmission module for sending a first locked asset request to a second cross-link router; the first locked asset request is to indicate that a fourth transaction asset of a second account of a second user on a second blockchain is locked based on a transaction request of a first account of the first user on the first blockchain; and for obtaining a first transaction receipt sent by the second cross-link; the first transaction receipt is the second cross-link claim of descriptive information that the fourth transaction asset has been locked; the first transaction receipt is generated based on a fourth declared asset of the fourth transaction asset, a second execution contract number, and a second execution contract address; the processing module is used for generating first transaction snapshot information corresponding to the first transaction receipt according to a preset format; and the second transaction snapshot information is generated according to the preset format based on the fourth transaction asset, the contract number and the second contract address; the contract number is a contract number corresponding to contract data agreed by the first user and the second user; the second contracted contract address is a contract address where the first user and the second user store the contract data in the second blockchain; a determining module, configured to determine that the fourth transaction asset is locked by the second cross-link route if the first transaction snapshot information is consistent with the second transaction snapshot information.
Optionally, the processing module is further configured to: locking a first transaction asset of a first account of the first user; generating a second trading response piece based on a first statement asset of the first trading asset, a first execution contract number, and a first execution contract address of the first user; the second transaction receipt is used for the first cross-link by declaring that the first transaction asset has been locked; the transmission module is further configured to: sending the second transaction receipt, the first unlock asset request, and the hash pre-image to the second cross-link server; the hash pre-image is a pre-image of the contract number, and the hash pre-image is used for unlocking the fourth transaction asset after the second cross-link passes the verification of the second transaction receipt.
Optionally, the transmission module is further configured to: receiving a second locked asset request sent by the second cross-link; the processing module is further configured to: locking a second transactional asset for a second account of the first user on the first blockchain; generating a third trading response piece based on a second distinct asset of the second trading asset, a third execution contract number, and a third execution contract address; the third transaction receipt is used for the first cross-link by declaring that the second transaction asset has been locked; the transmission module is further configured to: sending the third transaction receipt to the second cross-link route for the second cross-link route to verify whether the first cross-link route locks the second transaction asset.
Optionally, the transmission module is further configured to: receiving a fourth transaction receipt, a second unlock asset request and the hash pre-image sent by the second cross-link router; the fourth transaction receipt is descriptive information of the second cross-link that is declared to have locked a third transaction asset of a first account of the second user on the second blockchain; the fourth trade receipt is generated based on a third declared asset, a fourth execution contract number, and a fourth execution contract address for the third trade asset; the processing module is further configured to: generating seventh transaction snapshot information according to the fourth transaction receipt and the preset format; generating eighth transaction snapshot information according to the preset format and based on the agreed contract number and the second agreed contract address; and if the seventh transaction snapshot information is verified to be consistent with the eighth transaction snapshot information, unlocking the second transaction asset according to the Hash primitive.
Optionally, the contract data includes a first timestamp; the first timestamp is used to trigger the first blockchain to rollback the first transaction asset to a first account of the first user when the first timestamp arrives but the first transaction asset is not unlocked.
Optionally, the contract data includes a hash primitive image, an agreed contract number and a transaction attribute; first contract data stored in the first blockchain by the first user, wherein the hash primitive, the contract number and the transaction attribute are recorded in the first contract data; and second contract data stored in the second blockchain by the second user, wherein the agreed contract number and the transaction attribute are recorded in the second contract data.
Optionally, the transaction snapshot information includes the following contents: the name of the function for which the transaction was performed; input parameters for the transaction; an output result of the transaction; a contract address where the transaction is executed.
The advantageous effects of the second aspect and the various optional apparatuses of the second aspect may refer to the advantageous effects of the first aspect and the various optional methods of the first aspect, and are not described herein again.
In a third aspect, the present invention provides a computer device comprising a program or instructions for performing the method of the first aspect and the alternatives of the first aspect when the program or instructions are executed.
In a fourth aspect, the present invention provides a storage medium comprising a program or instructions which, when executed, is adapted to perform the method of the first aspect and the alternatives of the first aspect.
Drawings
FIG. 1 is a schematic diagram of a blockchain;
FIG. 2 is a schematic flowchart illustrating steps of a transaction correctness verification method applied to league chain cross-chain transfer according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a transaction correctness verification apparatus applied to league chain cross-chain transfer according to an embodiment of the present application.
Detailed Description
In order to better understand the technical solutions, the technical solutions will be described in detail below with reference to the drawings and the specific embodiments of the specification, and it should be understood that the specific features in the embodiments and examples of the present application are detailed descriptions of the technical solutions of the present application, but not limitations of the technical solutions of the present application, and the technical features in the embodiments and examples of the present application may be combined with each other without conflict.
The terms appearing in the embodiments of the present application are explained first below.
Block chains: as shown in fig. 1, a block chain is a chain consisting of a series of blocks, and each block records a Hash value of the block in addition to the data of the block, so that a chain is formed. The block chain has two core ideas, one is a cryptography technology, the other is a decentralization idea, and based on the two ideas, historical information on the block chain cannot be tampered.
Intelligent contract: an intelligent contract is a computer protocol intended to propagate, validate or execute contracts in an informational manner. Smart contracts allow trusted transactions to be conducted without third parties, which transactions are traceable and irreversible. The specific form of the intelligent contract is a code which is deployed on a block chain and completes a specific function.
And (3) node: each participant in the network is a node that participates in network set-up and data exchange. In a blockchain network, a node refers to a participant with a unique identity, and the node has a complete copy of the ledger and has the capability of participating in the consensus and ledger maintenance of the blockchain network.
Trading: a transaction is a user request for an operation of an intelligent contract interface deployed on a blockchain. The transaction is initiated by the user, sent from the client of the user to the block chain node, and after receiving the transaction, the block chain node calls the corresponding intelligent contract according to the contract address and the interface specified by the transaction.
And (3) chain crossing: there are various types of blockchains currently in existence. In some service scenarios, data interworking between different types of block chains is required. Such a business scenario is referred to as a cross-chain scenario. For the user, the user needs to operate on different types of blockchains at the same time, and send transactions to different types of blockchains.
Transaction presence verification: under a chain crossing scene, different chains need to mutually judge whether the transaction of the other side is uplink. For example, two block chains are respectively established by a party a and a party B, a transaction t is sent to the chain of a, and after the transaction t is executed and linked on the chain of a, B needs to verify that the transaction t is linked on the chain of a, and then can send another transaction on the chain of B to perform corresponding operation. And B, verifying the uplink behavior of the transaction on the chain of A, and becoming transaction existence verification.
Hash time lock contract:
a technology for ensuring the atomicity of multi-chain asset exchange is essentially an intelligent contract. The hash time lock approximately comprises three interfaces, namely lock, unlock and rollback, and respectively realizes the locking and unlocking of the assets and the rollback after the timeout. The lock needs to establish an asset unlocking condition, generally a hash, and the unlock transmits a hash pre-image, and if the hash is matched with the hash of the lock, the asset can be successfully unlocked.
Across the link is composed of:
a service component independent of a block chain can adapt to the block chain, has related functions of account management, transaction signature, transaction verification and the like, can synchronize block header information and transaction information among cross-link groups, and can mutually call contracts on the other link, which are also commonly called as cross-link relays and Peer.
In the operation process of financial institutions (banking institutions, insurance institutions or security institutions) in carrying out businesses (such as loan businesses, deposit businesses and the like of banks), public chain cross-chain transfer of a current block chain is generally realized based on a classic hash time locking contract, and the classic hash time locking contract needs to publicly verify the locking condition of transaction assets, namely the correctness verification of transactions. However, the contract and transaction information of the federation chain is not fully disclosed, so the classic hash time-lock contract model cannot be used directly for federation chain cross-chain transfers. This situation does not meet the requirements of financial institutions such as banks, and the efficient operation of various services of the financial institutions cannot be ensured.
To this end, as shown in fig. 2, the present application provides a transaction correctness verification method applied to league chain cross-chain transfer.
Step 201: the first cross-link route sends a first locked asset request to the second cross-link route.
Step 202: the first cross-link route acquires a first transaction receipt sent by the second cross-link route.
Step 203: and the first cross-link generates first transaction snapshot information corresponding to the first transaction receipt according to a preset format.
Step 204: and the first cross-link route generates second transaction snapshot information according to the preset format based on the fourth transaction asset, the agreed contract number and the second agreed contract address.
Step 205: determining that the second cross-link routing locks the fourth transaction asset if the first cross-link routing determines that the first transaction snapshot information is consistent with the second transaction snapshot information.
In steps 201 to 205, the first cross-link route is a cross-link route of the first blockchain, the second cross-link route is a cross-link route of the second blockchain, and the first locking asset request is used for indicating a fourth transaction asset of the second account of the second user on the second blockchain based on a transaction request of the first account of the first user on the first blockchain; the first transaction receipt is the second cross-link claim of descriptive information that the fourth transaction asset has been locked; the first transaction receipt is generated based on a fourth declared asset of the fourth transaction asset, a second execution contract number, and a second execution contract address; the contract number is a contract number corresponding to contract data agreed by the first user and the second user; the second contracted contract address is a contract address where the first user and the second user store the contract data in the second blockchain. In the present application, the expression XXX is stated to be XXX only, and is not necessarily true XXX, and it is confirmed that the XXX is true XXX after the verification is passed. In the application, the locking of the transaction assets can be realized through agreement contract numbers, and the unlocking of the transaction assets can be realized through Hash pre-images.
It should be noted that the first user has a first account of the first user on the first blockchain, the second user has a first account of the second user on the first blockchain, the first user has a second account of the first user on the second blockchain, and the second user has a second account of the second user on the second blockchain. The first blockchain also has a first intermediate account for registering the transaction asset locked on the first blockchain, and the second blockchain also has a second intermediate account for registering the transaction asset locked on the second blockchain.
In an optional embodiment, the contract data includes a first timestamp; the first timestamp is used to trigger the first blockchain to rollback the first transaction asset to a first account of the first user when the first timestamp arrives but the first transaction asset is not unlocked. Correspondingly, a second time stamp is also included in the contract data; the second timestamp is used to trigger the second blockchain to rollback the fourth transaction asset to the first account of the first user when the second timestamp arrives but the fourth transaction asset is not unlocked.
In an optional embodiment, the contract data includes a hash pre-image, a contract number and transaction attributes; first contract data stored in the first blockchain by the first user, wherein the hash primitive, the contract number and the transaction attribute are recorded in the first contract data; and second contract data stored in the second blockchain by the second user, wherein the agreed contract number and the transaction attribute are recorded in the second contract data.
After step 205, further verification of the correctness of the transaction may be performed, specifically:
step 206: the first cross-link route locks a first transaction asset of a first account of the first user.
Step 207: the first cross-link generates a second trade response piece from a first declared asset based on the first trade asset, a first execution contract number, and a first execution contract address of the first user.
Step 208: the second transaction receipt is used for the first cross-link by declaring that the first transaction asset has been locked.
Step 209: the first cross-link route sends the second transaction receipt, the first unlock asset request, and the hashed pre-image to the second cross-link route.
The hash pre-image is a pre-image of the contract number, and the hash pre-image is used for unlocking the fourth transaction asset after the second cross-link passes the verification of the second transaction receipt.
It should be noted that after step 209, the second cross-link route also has a hash primitive, so that the second cross-link route may be executed again according to step 201 to step 209, and specific details may refer to the first cross-link route, which is not described herein again. The corresponding first cross link is shown by steps 210-216. After step 209, after the second cross-link receives the second transaction receipt, the first unlock asset request and the hash pre-image, the following steps may be further performed:
generating third transaction snapshot information by the second cross-link according to the second transaction receipt and the preset format; generating fourth trading snapshot information by the second cross-link according to the preset format based on the first trading asset, the agreed contract number and the second agreed contract address; and if the second cross-link route verifies that the third transaction snapshot information is consistent with the fourth transaction snapshot information, unlocking the fourth transaction asset according to the Hash primitive.
After step 209, the first cross link may further perform the following steps:
step 210: the first cross-link route receives a second locked asset request sent by the second cross-link route.
Step 211: the first cross-link route locks a second transactional asset of a second account of the first user on the first blockchain.
Step 212: the first cross-link route generates a third transaction receipt based on a second distinct asset of the second transaction asset, a third execution contract number, and a third execution contract address.
The third transaction receipt is used for the first cross-link statement that the second transaction asset has been locked.
Step 213: the first cross-link route sends the third transaction receipt to the second cross-link route for the second cross-link route to verify whether the first cross-link route locks the second transaction asset.
After step 213, after the second cross-link receives the third transaction receipt, the following steps may be further performed:
the second cross-link computer generates fifth transaction snapshot information according to the third transaction receipt and the preset format; generating, by the second cross-link, sixth trading snapshot information according to the preset format based on the second trading asset, the agreed contract number, and the third agreed contract address; and if the first cross-link route verifies that the fifth transaction snapshot information is consistent with the sixth transaction snapshot information, unlocking the third transaction asset according to the Hash primitive.
After step 213, the first cross link may further perform the following steps:
step 214: the first cross-link route receives a fourth transaction receipt, a second unlock asset request and the hash pre-image sent by the second cross-link route.
Step 215: the first cross-link router generates seventh transaction snapshot information according to the fourth transaction receipt and the preset format; and generating eighth trading snapshot information by the first cross-link according to the preset format based on the third trading asset, the agreed contract number and the second agreed contract address.
Step 216: and if the first cross-link route verifies that the seventh transaction snapshot information is consistent with the eighth transaction snapshot information, unlocking the second transaction asset according to the Hash primitive.
The fourth transaction receipt is descriptive information of the second cross-link that is declared to have locked a third transaction asset of a first account of the second user on the second blockchain; the fourth trade receipt is generated based on a third declared asset, a fourth execution contract number, and a fourth execution contract address of the third trade asset.
In an alternative embodiment, the transaction snapshot information (the first transaction snapshot information to the eighth transaction snapshot information) appearing in the present application may include the following: the name of the function for which the transaction was performed; input parameters for the transaction; an output result of the transaction; a contract address where the transaction is executed.
The transaction correctness verification method of the present application is described in detail below in conjunction with a specific implementation process.
The main body involved: the system comprises two users (a first user _1 and a second user _2), two blockchains (a first blockchain _ a and a second blockchain _ b), two cross-link routes (the first cross-link is connected with the first blockchain _ a through a router _ a, the second cross-link is connected with the second cross-link through a router _ b), and two Hash time locking contracts (the Hash time locking contract address of the blockchain _ a is address _ a, and the Hash time locking contract address of the blockchain _ b is address _ b). The user1 owns the account _ a1 in the block chain _ a, the account _ b1 in the block chain _ b, the user2 owns the account _ a2 in the block chain _ a, and the account _ b2 in the block chain _ b.
Block chain cross-chain transfer: i.e., to effect an atomic exchange of assets on both chains. When account _ a1 on blockchain chain _ a transfers the first transaction asset to account _ a2, account _ b2 on blockchain chain _ b is guaranteed to also transfer the fourth transaction asset to account _ b 1. Such asset transfers either all succeed or all fail.
Suppose user1 is the initiator, i.e., has Secret, and user2 is the participants, who are the opponents.
Modifying the hash time lock contract: a. adding a contract state variable of an opposite party, wherein the variable supports a set and get method, the set stores a contract address of the opposite party in a k-v mode, an agreed contract number k is a character string constant 'counteraddress', v is a contract address of the opposite party, such as '0 x 1', and get returns the contract address of the opposite party according to k; b. newly added transfer contract status variables (contract data), contract fields include: the method comprises the steps of Hash, Secret, Sender0, Receiver0, Amount0, time 0, Sender0, Receiver0, Amount0 and time 0, wherein Secret is only held by a transfer initiator, namely Secret is initially held in first contract data but is not initially held in second contract data, the variable supports set and get methods, set stores contract information in a k-v mode, k is a contract number namely Hash, v is a contract structure, and get returns the contract structure according to the Hash.
The contract field is explained as follows:
Figure BDA0002479290380000131
the user _1 deploys a hash time lock contract on the blockchain _ a to obtain a first contract address _ a, the user _2 deploys a hash time lock contract on the blockchain _ b to obtain a second contract address _ b, and then the two users can tell the contract addresses of the users to the other side based on any communication mode.
Initializing a hash time lock contract: the contract address of the counterparty is saved in a k-v data structure by the set method of the counterparty contract state variables in the contract, for example:
user _1 executes set (counteratyaddress, address _ b),
user _2 executes set (countryaddress, address _ a).
The two parties save contract data through a k-v data structure by using a set method for transferring contract state variables in a contract, taking a contract number Hash as k and a contract structure body as v, and the method comprises the following steps:
the user _1 performs:
set(Hash,[Hash,Secret,Sender0,Receiver0,Amount0,Timelock0,Sender1,Recei ver1,Amount1,Timelock1]),
the user _2 performs:
set(Hash,[Hash,null,Sender0,Receiver0,Amount0,Timelock0,Sender1,Receiver1,Amount1,Timelock1])。
user _1 initiates a cross-chain transfer request to cross-link by router _ a, the requested field is the contract number Hash, user _2 initiates a cross-chain transfer request to cross-link by router _ b, and the requested field is the contract number Hash (how users and cross-link are mutually not the subject of the patent discussion).
The cross-link of the two parties is inquired about contract data according to the Hash, namely a get method get (Hash) for executing transfer contract state variables, if the route _ a can obtain the Secret from the contract data, if the route _ b can find the Secret in the contract data to be empty, the inquiry is continued until a result is obtained (when the property of the user is unlocked by the initiator).
router _ a requests router _ b to perform a lock _ b (hash) transaction of a hash time lock contract on blockchain chain _ b (how the cross-link routes interact does not belong to the patent discussion).
Router _ b executes lock _ b (hash) transaction locking the fourth transaction asset on chain _ b, i.e., account _ b2 transfers the fourth transaction asset to the intermediate account _ b, and then Router _ b returns the receipt of lock transaction lock _ b _ receive to Router _ a.
Router _ a does not trust router _ b and therefore verifies the correctness of the transaction as follows: a. constructing a real transaction snapshot real _ lock _ b _ snapshot according to a Method name, input, output and contract Address of a transaction receipt;
and (3) transaction snapshot: the outline of the execution of the transaction on the blockchain is recorded, and the data structure is as follows:
Struct Snapshot{
string Method,// Method name for transaction execution
String [ ] Inputs,// input parameter list for transactions
String [ ] Outputs,// output list of transactions
String Address// contract Address to execute the transaction
}
b. Get method get (hash) of transfer contract state variable of hash time lock contract on executing chain _ a obtains contract data, get method get (countertyaddress) of executing contract state variable of opponent party obtains contract address of opponent party, constructs expected snapshot according to contract data and contract address of opponent party, excepted _ lock _ b _ snapshot:
{ lock, [ Hash lock ], [ "success" ], address _ b };
and verifying whether real _ lock _ b _ snapshot and exposed _ lock _ b _ snapshot are equal, and if not, waiting for rolling back after timeout.
router _ a executes lock _ a (hash) transaction to lock the first transaction asset on chain _ a, that is, account _ a1 transfers the first transaction asset to the intermediate account _ a, and obtains transaction receipt lock _ a _ receive.
Router _ a requests Router _ b to unlock the fourth transaction asset on chain _ b according to the Hash and Secret, executes unlock _ b (Hash, Secret) transaction, and requests transaction receipt lock _ a _ receive with the chain of lock assets attached.
Router _ b does not trust router _ a, and therefore verifies the correctness of the lock _ a (hash) transaction on chain _ a:
a. and constructing an actual transaction snapshot according to lock _ a _ receive:
real_lock_a_snapshot:{Method,Inputes,Outputs,Address};
b. executing get method get (Hash) of transfer contract state variable of Hash time lock contract on chain _ b to obtain contract data, executing get method get (countenantyAddress) of contract state variable of opponent to obtain contract address of opponent, constructing expected snapshot according to contract data and contract address of opponent, excepted _ lock _ a _ snapshot: { lock, [ Hash ], [ "success" ], address _ a }; and verifying whether real _ lock _ a _ snapshot and exposed _ lock _ a _ snapshot are relative or not, and if not, waiting for rolling back after timeout.
If the verification is successful, router _ b executes unlock _ b transaction, completing the unlocking of the asset on the blockchain chain _ b, i.e. accout _ b transfers the fourth transaction asset to accout _ b 1.
At this time, router _ b obtains Secret, and then executes router _ a in (6-13), so as to complete the unlocking of the asset on the blockchain chain _ a, i.e. accout _ a transfers the asset to accout _ a 2.
In the process, a timer is set by the cross-link according to the time stamp field in the contract data in the Hash time locking contract, and the assets of the cross-link are rolled back when the time is overtime at any moment.
As shown in fig. 3, the present invention provides a transaction correctness verification device applied to league chain cross-chain transfer, including: a transmission module 301 for sending a first locked asset request to a second cross-link router; the first locked asset request is to indicate that a fourth transaction asset of a second account of a second user on a second blockchain is locked based on a transaction request of a first account of the first user on the first blockchain; and for obtaining a first transaction receipt sent by the second cross-link; the first transaction receipt is the second cross-link claim of descriptive information that the fourth transaction asset has been locked; the first transaction receipt is generated based on a fourth declared asset of the fourth transaction asset, a second execution contract number, and a second execution contract address; the processing module 302 is configured to generate first transaction snapshot information corresponding to the first transaction receipt according to a preset format; and the second transaction snapshot information is generated according to the preset format based on the fourth transaction asset, the contract number and the second contract address; the contract number is a contract number corresponding to contract data agreed by the first user and the second user; the second contracted contract address is a contract address where the first user and the second user store the contract data in the second blockchain; a determining module 303, configured to determine that the fourth transaction asset is locked by the second cross-link if it is determined that the first transaction snapshot information is consistent with the second transaction snapshot information.
Optionally, the processing module 302 is further configured to: locking a first transaction asset of a first account of the first user; generating a second trading response piece based on a first statement asset of the first trading asset, a first execution contract number, and a first execution contract address of the first user; the second transaction receipt is used for the first cross-link by declaring that the first transaction asset has been locked; the transmission module 301 is further configured to: sending the second transaction receipt, the first unlock asset request, and the hash pre-image to the second cross-link server; the hash pre-image is a pre-image of the contract number, and the hash pre-image is used for unlocking the fourth transaction asset after the second cross-link passes the verification of the second transaction receipt.
Optionally, the transmission module 301 is further configured to: receiving a second locked asset request sent by the second cross-link; the processing module 302 is further configured to: locking a second transactional asset for a second account of the first user on the first blockchain; generating a third trading response piece based on a second distinct asset of the second trading asset, a third execution contract number, and a third execution contract address; the third transaction receipt is used for the first cross-link by declaring that the second transaction asset has been locked; the transmission module 301 is further configured to: sending the third transaction receipt to the second cross-link route for the second cross-link route to verify whether the first cross-link route locks the second transaction asset.
Optionally, the transmission module 301 is further configured to: receiving a fourth transaction receipt, a second unlock asset request and the hash pre-image sent by the second cross-link router; the fourth transaction receipt is descriptive information of the second cross-link that is declared to have locked a third transaction asset of a first account of the second user on the second blockchain; the fourth trade receipt is generated based on a third declared asset, a fourth execution contract number, and a fourth execution contract address for the third trade asset; the processing module 302 is further configured to: generating seventh transaction snapshot information according to the fourth transaction receipt and the preset format; generating eighth transaction snapshot information according to the preset format and based on the agreed contract number and the second agreed contract address; and if the seventh transaction snapshot information is verified to be consistent with the eighth transaction snapshot information, unlocking the second transaction asset according to the Hash primitive.
Optionally, the contract data includes a first timestamp; the first timestamp is used to trigger the first blockchain to rollback the first transaction asset to a first account of the first user when the first timestamp arrives but the first transaction asset is not unlocked.
Optionally, the contract data includes a hash primitive image, an agreed contract number and a transaction attribute; first contract data stored in the first blockchain by the first user, wherein the hash primitive, the contract number and the transaction attribute are recorded in the first contract data; and second contract data stored in the second blockchain by the second user, wherein the agreed contract number and the transaction attribute are recorded in the second contract data.
Optionally, the transaction snapshot information includes the following contents: the name of the function for which the transaction was performed; input parameters for the transaction; an output result of the transaction; a contract address where the transaction is executed.
The embodiment of the application provides computer equipment, which comprises a program or instructions, and when the program or instructions are executed, the program or instructions are used for executing the transaction correctness verification method applied to the alliance chain cross-chain transfer and any optional method provided by the embodiment of the application.
The embodiment of the application provides a storage medium which comprises a program or an instruction, and the program or the instruction is used for executing a transaction correctness verification method applied to alliance chain cross-chain transfer and any optional method provided by the embodiment of the application.
Finally, it should be noted that: as will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, 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 functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (10)

1. A transaction correctness verification method applied to alliance chain cross-chain transfer is characterized by comprising the following steps:
the first cross-link route sending a first locked asset request to the second cross-link route; the first locked asset request is to indicate that a fourth transaction asset of a second account of a second user on a second blockchain is locked based on a transaction request of a first account of the first user on the first blockchain;
the first cross-link router acquires a first transaction receipt sent by the second cross-link router; the first transaction receipt is the second cross-link claim of descriptive information that the fourth transaction asset has been locked; the first transaction receipt is generated based on a fourth declared asset of the fourth transaction asset, a second execution contract number, and a second execution contract address;
generating first transaction snapshot information corresponding to the first transaction receipt by the first cross-link according to a preset format;
the first cross-link route generates second transaction snapshot information according to the preset format based on the fourth transaction asset, the agreed contract number and the second agreed contract address; the contract number is a contract number corresponding to contract data agreed by the first user and the second user; the second contracted contract address is a contract address where the first user and the second user store the contract data in the second blockchain;
determining that the second cross-link routing locks the fourth transaction asset if the first cross-link routing determines that the first transaction snapshot information is consistent with the second transaction snapshot information.
2. The method of claim 1, wherein after the determining that the second cross-link is locked by the fourth transaction asset, further comprising:
the first cross-link route locking a first transaction asset of a first account of the first user;
the first cross-link generating a second trade response piece based on a first declared asset of the first trade asset, a first execution contract number, and a first execution contract address of the first user; the second transaction receipt is used for the first cross-link by declaring that the first transaction asset has been locked;
the first cross-link route sending the second transaction receipt, the first unlock asset request, and the hash pre-image to the second cross-link route; the hash pre-image is a pre-image of the contract number, and the hash pre-image is used for unlocking the fourth transaction asset after the second cross-link passes the verification of the second transaction receipt.
3. The method of claim 2, wherein the first cross-link routing to the second cross-link routing subsequent to sending the second transaction receipt, the first unlock asset request, and the hashed pre-image, further comprising:
the first cross-link router receiving a second locked asset request sent by the second cross-link router;
the first cross-link route locks a second transactional asset of a second account of the first user on the first blockchain;
the first cross-link route generating a third transaction receipt based on a second express asset of the second transaction asset, a third execution contract number, and a third execution contract address; the third transaction receipt is used for the first cross-link by declaring that the second transaction asset has been locked;
the first cross-link route sends the third transaction receipt to the second cross-link route for the second cross-link route to verify whether the first cross-link route locks the second transaction asset.
4. The method of claim 3, wherein after the first cross-link route sending the third transaction receipt to the second cross-link route, further comprising:
the first cross-link router receives a fourth transaction receipt, a second unlocking asset request and the hash pre-image sent by the second cross-link router; the fourth transaction receipt is descriptive information of the second cross-link that is declared to have locked a third transaction asset of a first account of the second user on the second blockchain; the fourth trade receipt is generated based on a third declared asset, a fourth execution contract number, and a fourth execution contract address for the third trade asset;
the first cross-link router generates seventh transaction snapshot information according to the fourth transaction receipt and the preset format; generating eighth trading snapshot information by the first cross-link according to the preset format based on the third trading asset, the agreed contract number and the second agreed contract address;
and if the first cross-link route verifies that the seventh transaction snapshot information is consistent with the eighth transaction snapshot information, unlocking the second transaction asset according to the Hash primitive.
5. The method of any of claims 1 to 4, wherein a first timestamp is included in the contract data; the first timestamp is used to trigger the first blockchain to rollback the first transaction asset to a first account of the first user when the first timestamp arrives but the first transaction asset is not unlocked.
6. The method of any one of claims 1 to 4, wherein the contract data includes a hash pre-image, an agreement contract number, and transaction attributes; first contract data stored in the first blockchain by the first user, wherein the hash primitive, the contract number and the transaction attribute are recorded in the first contract data; and second contract data stored in the second blockchain by the second user, wherein the agreed contract number and the transaction attribute are recorded in the second contract data.
7. The method of any of claims 1 to 4, wherein the transaction snapshot information comprises the following: the name of the function for which the transaction was performed; input parameters for the transaction; an output result of the transaction; a contract address where the transaction is executed.
8. A transaction correctness verification device applied to league chain cross-chain transfers, comprising:
a transmission module for sending a first locked asset request to a second cross-link router; the first locked asset request is to indicate that a fourth transaction asset of a second account of a second user on a second blockchain is locked based on a transaction request of a first account of the first user on the first blockchain; and for obtaining a first transaction receipt sent by the second cross-link; the first transaction receipt is the second cross-link claim of descriptive information that the fourth transaction asset has been locked; the first transaction receipt is generated based on a fourth declared asset of the fourth transaction asset, a second execution contract number, and a second execution contract address;
the processing module is used for generating first transaction snapshot information corresponding to the first transaction receipt according to a preset format; and the second transaction snapshot information is generated according to the preset format based on the fourth transaction asset, the contract number and the second contract address; the contract number is a contract number corresponding to contract data agreed by the first user and the second user; the second contracted contract address is a contract address where the first user and the second user store the contract data in the second blockchain;
a determining module, configured to determine that the fourth transaction asset is locked by the second cross-link route if the first transaction snapshot information is consistent with the second transaction snapshot information.
9. A computer device comprising a program or instructions that, when executed, perform the method of any of claims 1 to 7.
10. A storage medium comprising a program or instructions which, when executed, perform the method of any one of claims 1 to 7.
CN202010374241.8A 2020-05-06 2020-05-06 Transaction correctness verification method and device applied to alliance chain cross-chain transfer Active CN111640017B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010374241.8A CN111640017B (en) 2020-05-06 2020-05-06 Transaction correctness verification method and device applied to alliance chain cross-chain transfer

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010374241.8A CN111640017B (en) 2020-05-06 2020-05-06 Transaction correctness verification method and device applied to alliance chain cross-chain transfer

Publications (2)

Publication Number Publication Date
CN111640017A true CN111640017A (en) 2020-09-08
CN111640017B CN111640017B (en) 2024-05-28

Family

ID=72330943

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010374241.8A Active CN111640017B (en) 2020-05-06 2020-05-06 Transaction correctness verification method and device applied to alliance chain cross-chain transfer

Country Status (1)

Country Link
CN (1) CN111640017B (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111970129A (en) * 2020-10-21 2020-11-20 腾讯科技(深圳)有限公司 Data processing method and device based on block chain and readable storage medium
CN112148796A (en) * 2020-09-28 2020-12-29 中钞***产业发展有限公司杭州区块链技术研究院 Electronic trade document sharing method, device, equipment and medium
CN112787999A (en) * 2020-12-25 2021-05-11 深圳前海微众银行股份有限公司 Cross-chain calling method, device, system and computer readable storage medium
CN112804262A (en) * 2021-03-19 2021-05-14 北京万物智链科技有限公司 Safety guarantee method and system in block chain cross-chain communication
CN113079081A (en) * 2020-09-25 2021-07-06 支付宝(杭州)信息技术有限公司 Message transmission method and device
CN113191756A (en) * 2021-06-04 2021-07-30 杭州复杂美科技有限公司 Cross-chain asset security management method, computer device and storage medium
CN113259478A (en) * 2021-06-17 2021-08-13 支付宝(杭州)信息技术有限公司 Method and device for executing transaction in blockchain system and blockchain system
CN113269545A (en) * 2021-05-26 2021-08-17 杭州云象网络技术有限公司 Hash time locking method and system based on cloud cross-chain transfer protocol
CN113706148A (en) * 2021-08-27 2021-11-26 杭州云象网络技术有限公司 Channel authority control-based chain crossing method, system, storage medium and device
WO2023019903A1 (en) * 2021-08-20 2023-02-23 华为云计算技术有限公司 Cross-chain transaction system and method, and device and storage medium

Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018120057A1 (en) * 2016-12-30 2018-07-05 深圳前海达闼云端智能科技有限公司 Currency management method and system based on block chain
CN108492105A (en) * 2018-03-07 2018-09-04 物数(上海)信息科技有限公司 Transaction in assets monitoring and managing method, system, equipment and storage medium based on block chain
CN108492108A (en) * 2018-03-29 2018-09-04 深圳前海微众银行股份有限公司 Across the chain communication means of block chain, system and computer readable storage medium
CN108647965A (en) * 2018-05-07 2018-10-12 北京柏链基石科技有限公司 Across chain method of commerce, device, storage medium and electronic equipment
CN108876369A (en) * 2018-06-05 2018-11-23 上海和数软件有限公司 Data communications method, device and computer readable storage medium based on block chain
CN109146448A (en) * 2018-07-13 2019-01-04 杭州复杂美科技有限公司 Across chain assets transfer method, equipment and storage medium
CN109359959A (en) * 2018-09-29 2019-02-19 衢州学院 Across chain assets transfer method, equipment and storage medium
CN109493027A (en) * 2018-11-19 2019-03-19 众安信息技术服务有限公司 A kind of method and device realized across chain transactional operation
CN109685489A (en) * 2018-12-28 2019-04-26 杭州云象网络技术有限公司 A kind of assets across chain method of commerce between block chain
CN110033243A (en) * 2019-03-06 2019-07-19 华南师范大学 Main chain based on block chain intelligence contract deposits card method, system and storage medium
CN110223178A (en) * 2019-06-06 2019-09-10 杭州趣链科技有限公司 It is a kind of for alliance's chain across catenary system and across chain method
WO2019174430A1 (en) * 2018-03-14 2019-09-19 郑杰骞 Block chain data processing method, management terminal, user terminal, conversion device, and medium
CN110471931A (en) * 2019-08-13 2019-11-19 山大地纬软件股份有限公司 A kind of digital asset trade identity maintaining method based on transaction in assets chain
WO2020042934A1 (en) * 2018-08-28 2020-03-05 白杰 Non-repudiation cross-chain transaction method and blockchain system
CN110868439A (en) * 2018-08-28 2020-03-06 傲为信息技术(江苏)有限公司 Block chain system
CN111080449A (en) * 2019-12-03 2020-04-28 深圳前海微众银行股份有限公司 Block chain cross-chain transaction method, management node and block chain network

Patent Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018120057A1 (en) * 2016-12-30 2018-07-05 深圳前海达闼云端智能科技有限公司 Currency management method and system based on block chain
CN108492105A (en) * 2018-03-07 2018-09-04 物数(上海)信息科技有限公司 Transaction in assets monitoring and managing method, system, equipment and storage medium based on block chain
WO2019174430A1 (en) * 2018-03-14 2019-09-19 郑杰骞 Block chain data processing method, management terminal, user terminal, conversion device, and medium
CN108492108A (en) * 2018-03-29 2018-09-04 深圳前海微众银行股份有限公司 Across the chain communication means of block chain, system and computer readable storage medium
CN108647965A (en) * 2018-05-07 2018-10-12 北京柏链基石科技有限公司 Across chain method of commerce, device, storage medium and electronic equipment
CN108876369A (en) * 2018-06-05 2018-11-23 上海和数软件有限公司 Data communications method, device and computer readable storage medium based on block chain
CN109146448A (en) * 2018-07-13 2019-01-04 杭州复杂美科技有限公司 Across chain assets transfer method, equipment and storage medium
CN110868439A (en) * 2018-08-28 2020-03-06 傲为信息技术(江苏)有限公司 Block chain system
WO2020042934A1 (en) * 2018-08-28 2020-03-05 白杰 Non-repudiation cross-chain transaction method and blockchain system
CN109359959A (en) * 2018-09-29 2019-02-19 衢州学院 Across chain assets transfer method, equipment and storage medium
CN109493027A (en) * 2018-11-19 2019-03-19 众安信息技术服务有限公司 A kind of method and device realized across chain transactional operation
CN109685489A (en) * 2018-12-28 2019-04-26 杭州云象网络技术有限公司 A kind of assets across chain method of commerce between block chain
CN110033243A (en) * 2019-03-06 2019-07-19 华南师范大学 Main chain based on block chain intelligence contract deposits card method, system and storage medium
CN110223178A (en) * 2019-06-06 2019-09-10 杭州趣链科技有限公司 It is a kind of for alliance's chain across catenary system and across chain method
CN110471931A (en) * 2019-08-13 2019-11-19 山大地纬软件股份有限公司 A kind of digital asset trade identity maintaining method based on transaction in assets chain
CN111080449A (en) * 2019-12-03 2020-04-28 深圳前海微众银行股份有限公司 Block chain cross-chain transaction method, management node and block chain network

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113079081A (en) * 2020-09-25 2021-07-06 支付宝(杭州)信息技术有限公司 Message transmission method and device
US11924276B2 (en) 2020-09-25 2024-03-05 Alipay (Hangzhou) Information Technology Co., Ltd. Methods and apparatuses for transmitting messages
CN112148796A (en) * 2020-09-28 2020-12-29 中钞***产业发展有限公司杭州区块链技术研究院 Electronic trade document sharing method, device, equipment and medium
CN112148796B (en) * 2020-09-28 2024-05-31 中钞***产业发展有限公司杭州区块链技术研究院 Electronic trade bill sharing method, device, equipment and medium
CN111970129A (en) * 2020-10-21 2020-11-20 腾讯科技(深圳)有限公司 Data processing method and device based on block chain and readable storage medium
CN112787999B (en) * 2020-12-25 2023-02-17 深圳前海微众银行股份有限公司 Cross-chain calling method, device, system and computer readable storage medium
CN112787999A (en) * 2020-12-25 2021-05-11 深圳前海微众银行股份有限公司 Cross-chain calling method, device, system and computer readable storage medium
CN112804262A (en) * 2021-03-19 2021-05-14 北京万物智链科技有限公司 Safety guarantee method and system in block chain cross-chain communication
CN112804262B (en) * 2021-03-19 2021-07-27 北京万物智链科技有限公司 Safety guarantee method and system in block chain cross-chain communication
CN113269545A (en) * 2021-05-26 2021-08-17 杭州云象网络技术有限公司 Hash time locking method and system based on cloud cross-chain transfer protocol
CN113191756B (en) * 2021-06-04 2022-07-19 杭州复杂美科技有限公司 Cross-chain asset security management method, computer device and storage medium
CN113191756A (en) * 2021-06-04 2021-07-30 杭州复杂美科技有限公司 Cross-chain asset security management method, computer device and storage medium
CN113259478A (en) * 2021-06-17 2021-08-13 支付宝(杭州)信息技术有限公司 Method and device for executing transaction in blockchain system and blockchain system
WO2023019903A1 (en) * 2021-08-20 2023-02-23 华为云计算技术有限公司 Cross-chain transaction system and method, and device and storage medium
CN113706148A (en) * 2021-08-27 2021-11-26 杭州云象网络技术有限公司 Channel authority control-based chain crossing method, system, storage medium and device
CN113706148B (en) * 2021-08-27 2023-09-29 杭州云象网络技术有限公司 Cross-link method, system, storage medium and device based on channel authority control

Also Published As

Publication number Publication date
CN111640017B (en) 2024-05-28

Similar Documents

Publication Publication Date Title
CN111640017B (en) Transaction correctness verification method and device applied to alliance chain cross-chain transfer
CN107301600B (en) Core construction method of block chain Internet model for cross-chain transaction
WO2020258848A1 (en) Method and apparatus for cross-chain transmission of resources
CN112330326B (en) Business processing method and device applied to bank transaction blockchain system
JP7021747B2 (en) Payment system, payment method, user device, payment program
Kiayias et al. A composable security treatment of the lightning network
Robinson et al. Atomic crosschain transactions for ethereum private sidechains
CN110266655A (en) A kind of across chain interconnected method, equipment and system based on block chain
WO2018232493A1 (en) A network of doubly-chained blockchains capable of cross-chain transactions
CN111598566A (en) Network payment system based on mixed cross-chain
TW201943250A (en) Cross-blockchain authentication method and apparatus, and electronic device
CN109741068B (en) Online banking cross-row signing method, device and system
CN113746858B (en) Cross-chain communication method based on verifiable random function
CN108154439A (en) Asset data processing unit and method
CN112488682B (en) Three-party transfer method and device for block chain
CN112579700B (en) Cross-chain transaction processing method and device
CN111294339B (en) Homogeneous alliance chain cross-chain method and device based on Fabric architecture
CN112581130B (en) Cross-chain transaction method based on multi-chain interconnection
WO2022206433A1 (en) Method and apparatus for pre-executing chaincode in fabric blockchain
CN111915308A (en) Transaction processing method of blockchain network and blockchain network
CN112488683B (en) Under-chain transaction method and device of blockchain
KR20220045025A (en) Method and system for communication protocol of decentralized transaction
Decker On the scalability and security of bitcoin
Fujimoto et al. Secure blockchain interworking using extended smart contract
CN115526629A (en) Receipt transaction method and device based on block chain network and identity authentication device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant