WO2024082807A1 - 基于多区块链的资产转移方法、装置、设备、介质及产品 - Google Patents

基于多区块链的资产转移方法、装置、设备、介质及产品 Download PDF

Info

Publication number
WO2024082807A1
WO2024082807A1 PCT/CN2023/114368 CN2023114368W WO2024082807A1 WO 2024082807 A1 WO2024082807 A1 WO 2024082807A1 CN 2023114368 W CN2023114368 W CN 2023114368W WO 2024082807 A1 WO2024082807 A1 WO 2024082807A1
Authority
WO
WIPO (PCT)
Prior art keywords
chain
cross
asset
transaction
contract
Prior art date
Application number
PCT/CN2023/114368
Other languages
English (en)
French (fr)
Inventor
朱耿良
Original Assignee
腾讯科技（深圳）有限公司
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 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to US18/387,336 priority Critical patent/US20240235817A9/en
Publication of WO2024082807A1 publication Critical patent/WO2024082807A1/zh

Links

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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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/08—Payment architectures
    • 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
    • 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
    • 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
    • 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
    • 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/3247—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 digital signatures

Definitions

  • the present application relates to the field of blockchain technology, and in particular to a method, device, equipment, medium and product for asset transfer based on multiple blockchains.
  • the blockchain electronic bill system is usually built based on a single chain structure, that is, the blockchain electronic bill system has the phenomenon of executing different businesses through the same blockchain, so that these blocks on the single chain may store different assets corresponding to different transaction businesses.
  • the single chain may store bill assets related to the bill business and business assets of other businesses unrelated to the bill business (for example, digital assets related to the transfer business, etc.), which will cause serious confusion in the data stored on the entire chain.
  • the transfer service when a user initiates a transfer service for the aforementioned bill assets on the blockchain, the transfer service will be executed on the same chain used to execute the aforementioned transfer service. Then, when there are a large number of other services requested by other users in the service processing queue corresponding to the single chain, the blockchain electronic bill system needs to execute a large number of other services in advance before executing the transfer service in the service processing queue, which will inevitably consume a certain amount of service waiting time, and thus affect the transfer efficiency of the bill assets on the blockchain.
  • the blockchain electronic bill system when used to process the aforementioned large number of different services, it will consume a large amount of computing resources and storage resources on the single chain, and thus it is difficult to ensure the business stability of the services that need to be executed on the single chain (for example, the aforementioned transfer services).
  • the embodiments of the present application provide a method, device, equipment, medium and product for asset transfer based on multiple blockchains.
  • an embodiment of the present application provides an asset transfer method based on multiple blockchains, wherein the multiple blockchains include a first chain, a second chain, and a target chain; the method is executed by a first consensus node in a first chain network corresponding to the first chain, and the method includes:
  • the first cross-chain asset transfer request carries business data information configured for the business object, and the business data information is configured by the target consensus node in the target chain network;
  • the first cross-chain asset transfer request is used to instruct the first consensus node to transfer the first asset belonging to the business object from the first chain to the second chain associated with the second consensus node through the cross-chain relay;
  • the second consensus node is a consensus node in the second chain network corresponding to the second chain;
  • the cross-chain relay is used to isolate the second chain network from the first chain network, and the second chain network is independent of the target chain network and the first chain network;
  • the first asset contract on the first chain is called to lock the first asset, and a first cross-chain event corresponding to the first cross-chain transfer-out transaction is generated;
  • the first cross-chain event is used to instruct the cross-chain relay to send the first cross-chain transfer-in transaction to the second consensus node when constructing the first cross-chain transfer-in transaction corresponding to the first cross-chain transfer-out transaction;
  • the second consensus node is used to call the second asset contract indicated by the second cross-chain bridge contract when writing the transaction data of the first cross-chain transfer-in transaction to the second cross-chain bridge contract on the second chain, and cast a second asset with the same asset content as the first asset on the second chain.
  • an embodiment of the present application provides an asset transfer method based on multiple blockchains, wherein the multiple blockchains include a first chain, a second chain, and a target chain; the method is executed by a second consensus node in a second chain network corresponding to the second chain, and the method includes:
  • the first cross-chain transfer-in transaction is constructed when the cross-chain relay reads the first cross-chain event corresponding to the first cross-chain transfer-out transaction from the first consensus node; the first cross-chain event is generated when the first consensus node calls the first asset contract on the first chain to lock the first asset when it determines that the business object has the cross-chain asset transfer-out permission based on the first cross-chain bridge contract and business data information written with the first cross-chain transfer-out transaction; the business data information is configured for the business object by the target consensus node in the target chain network; the first consensus node The recognition node is the consensus node in the first chain network corresponding to the first chain; the cross-chain relay is used to isolate the first chain network and the second chain network, and the first chain network is independent of the target chain network and the second chain network;
  • the second asset contract indicated by the second cross-chain bridge contract is called to mint a second asset with the same asset content as the first asset on the second chain.
  • an embodiment of the present application provides an asset transfer device based on multiple blockchains, wherein the multiple blockchains include a first chain, a second chain, and a target chain; the device runs on a first consensus node in a first chain network corresponding to the first chain; the device includes:
  • An acquisition module is used to acquire a first cross-chain asset transfer request sent by a business object for a first cross-chain transfer transaction;
  • the first cross-chain asset transfer request carries business data information configured for the business object, and the business data information is configured by a target consensus node in a target chain network;
  • the first cross-chain asset transfer request is used to instruct the first consensus node to transfer a first asset belonging to the business object from the first chain to a second chain associated with a second consensus node through a cross-chain relay;
  • the second consensus node is a consensus node in a second chain network corresponding to the second chain;
  • the cross-chain relay is used to isolate the second chain network from the first chain network, and the second chain network is independent of the target chain network and the first chain network;
  • a writing module used to write the transaction data of the first cross-chain outgoing transaction into the first cross-chain bridge contract on the first chain
  • a calling module is used to call the first asset contract on the first chain to lock the first asset and generate a first cross-chain event corresponding to the first cross-chain transfer-out transaction when determining that the business object has the cross-chain asset transfer-out permission based on the first cross-chain bridge contract and the business data information;
  • the first cross-chain event is used to instruct the cross-chain relay to send the first cross-chain transfer-in transaction to the second consensus node when constructing the first cross-chain transfer-in transaction corresponding to the first cross-chain transfer-out transaction;
  • the second consensus node is used to call the second asset contract indicated by the second cross-chain bridge contract when writing the transaction data of the first cross-chain transfer-in transaction to the second cross-chain bridge contract on the second chain, and cast a second asset with the same asset content as the first asset on the second chain.
  • the embodiment of the present application provides an asset transfer device based on multiple blockchains, wherein the multiple blockchains include a first chain, a second chain, and a target chain; the device runs on a second consensus node in a second chain network corresponding to the second chain; the device includes:
  • a processing module is used to obtain a first cross-chain transfer-in transaction sent by a cross-chain relay for a first asset; the first cross-chain transfer-in transaction is constructed when the cross-chain relay reads a first cross-chain event corresponding to a first cross-chain transfer-out transaction from a first consensus node; the first cross-chain event is generated when the first consensus node calls the first asset contract on the first chain to lock the first asset when it determines that the business object has the cross-chain asset transfer-out authority based on the first cross-chain bridge contract and business data information written with the first cross-chain transfer-out transaction; the business data information is configured for the business object by a target consensus node in a target chain network; the first consensus node is a consensus node in a first chain network corresponding to the first chain; the cross-chain relay is used to isolate the first chain network from the second chain network, and the first chain network is independent of the target chain network and the second chain network;
  • the processing module is further used to write the transaction data of the first cross-chain incoming transaction into the second cross-chain bridge contract on the second chain;
  • the asset casting module is used to call the second asset contract indicated by the second cross-chain bridge contract to cast a second asset with the same asset content as the first asset on the second chain.
  • an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method provided in the above aspect of the embodiment of the present application.
  • an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored.
  • the computer program is suitable for being loaded and executed by a processor, so that a computer device with a processor executes the method provided in the above aspect of the embodiment of the present application.
  • a computer program product or a computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium.
  • a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in the above aspect.
  • the first cross-chain asset transfer request sent by the business object for the first cross-chain transfer transaction can be obtained; wherein the first cross-chain asset transfer request carries the business data information configured by the target consensus node associated with the target chain.
  • the business data information can be used to verify the authority of the business object that initiated the first cross-chain asset transfer request to ensure the security of the cross-chain transferred assets (that is, when the cross-chain asset transfer is performed, the cross-chain
  • the first cross-chain asset transfer request involved in the embodiment of the present application can be used to transfer the first asset from the first chain associated with the first consensus node to the second chain associated with the second consensus node.
  • the first chain, the second chain and the target chain mentioned above are multi-blockchains for cross-chain asset transfer built based on the multi-chain architecture, and the three chains are in independent consensus networks.
  • the transaction data of the first cross-chain transfer transaction carried in the first cross-chain asset transfer request is written into the first cross-chain bridge contract on the first chain.
  • the first asset contract on the first chain is called to lock the first asset, and a first cross-chain event corresponding to the first cross-chain transfer transaction is generated.
  • the first cross-chain event can be used to instruct the cross-chain relay to construct a first cross-chain transfer-in transaction, so that the second consensus node casts a second asset with the same asset content as the first asset, thereby realizing the asset transfer of the first asset.
  • the embodiment of the present application provides an asset transfer mechanism based on multiple blockchains, which aims to emphasize that the cross-chain transfer of the first asset can be achieved through the mutual cooperation of the three chains. For example, when the target chain is authorized by the user (i.e., the aforementioned business object) to configure the above-mentioned business data information, the user can initiate a transfer business for transferring the first asset from the first chain to the second chain.
  • the transfer business here is the above-mentioned first cross-chain transfer transaction. It should be understood that since the first chain, the second chain and the target chain involved in the embodiment of the present application are independent of each other, they can be used to execute different businesses respectively (for example, the business related to the first asset itself (such as the bill business related to the bill asset) can be executed on the first chain, and the derivative business associated with the bill business can be executed on the second chain), thereby reducing the degree of confusion of the data stored on each chain.
  • the synchronous cross-chain execution of the transfer business can also be achieved when other businesses are normally executed on each chain, that is, without affecting the request of other businesses, thereby improving the transfer efficiency of the cross-chain transfer of the first asset.
  • the transfer business for the first asset is collaboratively executed through contracts deployed on the chain (such as the first cross-chain bridge contract, the first asset contract, etc. on the first chain), which can ensure that the business executed on the chain (i.e., the transfer business of transferring the first asset across chains) is not affected by other businesses, thereby ensuring the business stability of the transfer business.
  • contracts deployed on the chain such as the first cross-chain bridge contract, the first asset contract, etc. on the first chain
  • FIG1 is a schematic diagram of a hierarchical structure of a blockchain network provided in an embodiment of the present application.
  • FIG2a is a schematic diagram of an application architecture provided in an embodiment of the present application.
  • FIG2b is a schematic diagram of a scenario of a blockchain electronic invoice platform based on multiple blockchains provided in an embodiment of the present application
  • FIG3 is a flow chart of a method for transferring assets based on multiple blockchains provided in an embodiment of the present application
  • FIG4 is a schematic diagram of a cross-chain asset transfer scenario provided by an embodiment of the present application.
  • FIG5 is a flow chart of a method for transferring assets based on multiple blockchains provided in an embodiment of the present application
  • FIG6 is a schematic diagram of a cross-chain asset transfer scenario provided by an embodiment of the present application.
  • FIG7 is a flow chart of a method for transferring assets based on multiple blockchains provided in an embodiment of the present application.
  • FIG8 is a schematic diagram of a scenario of cross-chain asset transfer provided by an embodiment of the present application.
  • FIG9 is a flow chart of a method for transferring assets based on multiple blockchains provided in an embodiment of the present application.
  • FIG10 is a schematic diagram of a scenario of cross-chain asset transfer provided in an embodiment of the present application.
  • FIG11 is a flow chart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application.
  • FIG12 is a flow chart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application.
  • FIG13 is a schematic diagram of the structure of an asset transfer device based on multiple blockchains provided in an embodiment of the present application.
  • FIG14 is a schematic diagram of the structure of an asset transfer device based on multiple blockchains provided in an embodiment of the present application.
  • FIG15 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.
  • Figure 16 is a schematic diagram of an asset transfer system based on multiple blockchains provided in an embodiment of the present application.
  • FIG 1 is a schematic diagram of a hierarchical structure of a blockchain network provided by an embodiment of the present application.
  • the hierarchical structure shown in Figure 1 is applied to a blockchain data system, such as a blockchain electronic bill system, and in the blockchain electronic bill system,
  • the blockchain network corresponding to the bill system includes a business network and multiple consensus networks.
  • the business network is in the public network, and the consensus network is in the private network (for example, deployed in a private cloud).
  • the business network can be represented as the business network 400a shown in FIG1
  • the multiple consensus networks can be specifically represented as the consensus network 100a, the consensus network 200a, and the consensus network 300a shown in FIG1 .
  • the multiple business nodes are deployed, and the multiple business nodes may specifically include the business node 110a, business node 110b, ..., business node 110n shown in FIG. 1 .
  • the number of business nodes deployed in the business network 400a is not limited here. As business needs change, the number of business nodes can change continuously. It should be understood that the business nodes in the business network 400a do not need to participate in bookkeeping.
  • one or more of the above-mentioned multiple consensus networks can be accessed through network communication.
  • the number of consensus networks accessed by each business object through the corresponding business node is not limited here. It is understandable that data interaction can also be carried out between each consensus network in the form of network communication.
  • the multiple consensus nodes are deployed, and the multiple consensus nodes here may specifically include the consensus node 10a, consensus node 10b, consensus node 10c, and consensus node 10d shown in FIG1 .
  • the number of consensus nodes deployed in the consensus network 100a is not limited here, and the number of consensus nodes here can change continuously as business needs change.
  • the blockchain maintained together is specifically the blockchain 10e shown in FIG1 .
  • the multiple consensus nodes are deployed, and the multiple consensus nodes here may specifically include consensus node 11a, consensus node 11b, consensus node 11c, and consensus node 11d shown in FIG1 .
  • the number of consensus nodes deployed in the consensus network 200a is not limited here, and the number of consensus nodes here can change continuously as business needs change.
  • the blockchain maintained together is specifically the blockchain 11e shown in FIG1 .
  • a plurality of consensus nodes are deployed, and the plurality of consensus nodes here may specifically include the consensus node 12a, the consensus node 12b, the consensus node 12c, and the consensus node 12d shown in FIG1 .
  • the number of consensus nodes deployed in the consensus network 300a is not limited here, and the number of consensus nodes here may change continuously as business needs change.
  • the blockchain maintained together is specifically the blockchain 12e shown in FIG1 .
  • the embodiments of the present application may collectively refer to the business nodes and consensus nodes located in the above-mentioned blockchain electronic invoice system as blockchain nodes (referred to as nodes for short), and may collectively refer to the consensus network 100a, consensus network 200a and consensus network 300a participating in the above-mentioned blockchain electronic invoice system as core consensus networks, and may collectively refer to the various nodes in the above-mentioned core consensus networks as core nodes.
  • Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm, which is mainly used to organize data in chronological order and encrypt it into a ledger to make it impossible to be tampered with or forged, and to verify, store and update data.
  • Blockchain is essentially a decentralized database in which each node stores an identical blockchain.
  • the blockchain stored on each node in the consensus network 100a (for example, core nodes such as consensus node 10a, consensus node 10b, consensus node 10c and consensus node 10d) is blockchain 10e.
  • the blockchain 10e here can be the target chain (for example, it can be called a management chain) in the above-mentioned blockchain electronic invoice system, and the core consensus network corresponding to the management chain (that is, consensus network 100a) can be the target chain network (for example, it can be called a management chain network), and the consensus nodes (or core nodes) in the management chain network can be collectively referred to as target consensus nodes (for example, they can be called management consensus nodes).
  • the blockchain stored on each node in the consensus network 200a is blockchain 11e.
  • the blockchain 11e here can be the first chain in the above-mentioned blockchain electronic bill system (for example, it can be called a bill chain), and the core consensus network corresponding to the bill chain (that is, consensus network 200a) can be the first chain network (for example, it can be called an electronic bill network, or a bill chain network).
  • the consensus nodes (or core nodes) in the electronic bill network can be collectively referred to as bill consensus nodes, and the consensus mechanism in the electronic bill network can be used to select a bill consensus node from among these bill consensus nodes.
  • the node is used as the first consensus node.
  • the blockchain stored on each node in the consensus network 300a is blockchain 12e, where blockchain 12e can be the second chain in the above-mentioned blockchain electronic bill system (for example, it can be called an application contract chain), and the core consensus network corresponding to the application contract chain (i.e., consensus network 300a) can be the second chain network (for example, it can be called an application contract chain network), and the consensus nodes (or core nodes) in the application contract chain network can be collectively referred to as application consensus nodes, and the consensus mechanism in the application contract chain network can be used to select an application consensus node from these application consensus nodes as the second consensus node.
  • the core node can be responsible for the consensus in the core consensus network where the corresponding blockchain is located, that is, the core node can be the consensus node in the core consensus network where the corresponding blockchain is located.
  • the specific process of writing the transaction data in the core consensus network into the corresponding blockchain ledger can be that the user client sends the transaction data to a certain business node, and then the transaction data is passed between the business nodes in the business network in the above blockchain network in a relay manner until the consensus node in the corresponding core consensus network in the above blockchain network (for example, the consensus node 11b in the consensus network 200a) receives the transaction data.
  • the consensus node (for example, the consensus node 11b in the consensus network 200a) packs the transaction data into a block so that it can be subsequently reached by consensus with other consensus nodes, so that after the consensus is passed, the consensus-passed block can be written into the distributed database of the core consensus network (for example, the consensus network 200a) where it is located.
  • the core consensus network for example, the consensus network 200a
  • the embodiment of the present application can also write the block carrying the transaction data and other multiple blocks associated with the block in parallel into a distributed database through the storage layer of the core consensus network (for example, consensus network 200a).
  • consensus network 200a for example, consensus network 200a
  • a smart contract can be deployed on the blockchain of the corresponding core consensus network.
  • the smart contract in the blockchain electronic bill system can be understood as a code executed by each blockchain node (i.e., each consensus node), and any logic can be executed and the result can be obtained through the smart contract.
  • a user can initiate a business request (such as a first cross-chain asset transfer request) through a user client to call a smart contract (such as the first cross-chain bridge contract) that has been deployed on the blockchain (such as the above-mentioned blockchain 11e) of the corresponding core consensus network (such as the above-mentioned consensus network 200a) to realize the cross-chain transfer of bill assets.
  • the business node in the business network can send the first cross-chain asset transfer request to the consensus node in the corresponding core consensus network (for example, the consensus node 11a shown in Figure 1) to authenticate the user of the first cross-chain asset transfer request through the chain entry of the corresponding core consensus network, and when the identity authentication is successful, allow the first cross-chain asset transfer request sent by the user to be sent to other consensus nodes in the corresponding core consensus network (for example, the consensus node 11b shown in Figure 1) to call the smart contracts running in these consensus nodes (for example, the consensus nodes 11a and the consensus nodes 11b shown in Figure 1) to execute the transaction business requested by the user (such as the asset transfer business indicated by the first cross-chain asset transfer request).
  • the consensus node in the corresponding core consensus network for example, the consensus node 11a shown in Figure 1
  • the consensus node 11b shown in Figure 1 to call the smart contracts running in these consensus nodes (for example, the consensus nodes 11a and the consensus nodes 11b shown in Figure 1) to execute the transaction business
  • one or more smart contracts can be deployed on the blockchain (e.g., the blockchain 11e) of the core consensus network (e.g., the consensus network 200a), and these smart contracts can be distinguished by the contract call address, the contract identification number (ID) or the contract name, and the first cross-chain asset transfer request initiated by the user client can also carry the contract call address or the contract identification number or the contract name of the smart contract to specify the smart contract to be run.
  • the blockchain e.g., the blockchain 11e
  • ID contract identification number
  • the first cross-chain asset transfer request initiated by the user client can also carry the contract call address or the contract identification number or the contract name of the smart contract to specify the smart contract to be run.
  • each consensus node will request to read relevant data (e.g., source configuration data information) from the corresponding blockchain (e.g., the management chain) through the chain identifier specified by the first cross-chain bridge contract.
  • relevant data e.g., source configuration data information
  • each consensus node will verify whether the obtained business execution results are consistent (that is, consensus is reached). If they are consistent, the business execution results can be stored in their respective local caches and local storages.
  • the local cache here is the system memory created in the storage layer
  • the local storage here is the hard disk space created in the storage layer for data storage.
  • Consensus nodes can also read data through local storage created in this storage layer.
  • any two blockchain nodes in any consensus network can form a peer-to-peer (P2P) network, and the peer-to-peer network can adopt the P2P protocol, wherein the P2P protocol is an application layer protocol running on the Transmission Control Protocol (TCP) protocol.
  • P2P protocol is an application layer protocol running on the Transmission Control Protocol (TCP) protocol.
  • TCP Transmission Control Protocol
  • any device such as a server, a terminal, etc. can join and become a blockchain node, wherein each blockchain node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer.
  • the consensus node located in the management chain network can provide registration services and authorization services for the corresponding business objects that access the management chain network through the management chain network entrance, and then can perform identity management and authority management on the business objects that need to access the blockchain network (for example, the management chain network, the electronic bill network, or the application contract chain network) in the management chain network.
  • the management consensus node configures business data information for the business object through the management chain, and the business data information can be used to verify the authority of the business object to request the cross-chain transfer of bill assets.
  • the management consensus node located in the management chain network can also be used to perform data management on the relevant metadata information in the above-mentioned blockchain electronic invoice system.
  • it can manage and update the contract templates on the management chain (it should be understood that the contract templates on the management chain can specifically include the management contract templates of the smart contracts deployed on the management chain and the application contract templates of the smart contracts deployed on the application contract chain), manage and update the invoice templates recorded on the management chain, manage and update the tax calculation rules associated with the invoice template, control the access traffic at the chain entrance corresponding to the invoice chain, control the number of consensus nodes participating in the consensus on each chain, etc.
  • the consensus node located in the electronic bill network can be used to provide bill services.
  • the bill services can include but are not limited to bill asset transfer services, electronic bill issuance services, electronic bill circulation services, electronic bill redemption services, electronic bill archiving services and other electronic bill-related services.
  • the consensus node located in the application contract chain network can be used to provide derivative businesses associated with the aforementioned bill business (for example, credit business, loss-making business, corporate qualification business, etc.).
  • each entity object can correspond to a blockchain node
  • the embodiment of the present application can take the entity object as the above-mentioned enterprise object (i.e., the above-mentioned enterprise) as an example.
  • the blockchain node associated with each enterprise object can be the same blockchain node (for example, the business node 110c shown in Figure 1 can interact with user terminals corresponding to multiple enterprise objects).
  • the bill business requested by each enterprise object for example, bill asset transfer business, electronic bill issuance business, electronic bill circulation business, electronic bill red-off business, electronic bill archiving business, etc., which are related to electronic bills
  • a transaction business for example, bill asset transfer business, electronic bill issuance business, electronic bill circulation business, electronic bill red-off business, electronic bill archiving business, etc., which are related to electronic bills.
  • the business node 110c shown in Figure 1 can interact with the consensus nodes in the above-mentioned consensus network 100a (for example, consensus node 10b), the consensus nodes in the consensus network 200a (for example, consensus node 11b) and the consensus nodes in the consensus network 300a (for example, consensus node 12b) to request to complete the corresponding bill business (such as bill asset transfer business).
  • the consensus nodes in the above-mentioned consensus network 100a for example, consensus node 10b
  • the consensus nodes in the consensus network 200a for example, consensus node 11b
  • consensus nodes in the consensus network 300a for example, consensus node 12b
  • the embodiment of the present application can collectively refer to the entity objects (for example, enterprise object A, enterprise object B, ..., enterprise object C) that send the first cross-chain asset transfer request to the electronic bill network for the above-mentioned bill asset transfer business as business objects, and in the business network (for example, the above-mentioned business network 400a), the blockchain nodes associated with the business object (for example, the above-mentioned business node 110c) can be collectively referred to as business nodes, and in the core consensus network (for example, the above-mentioned consensus network 200a as the electronic bill network), the blockchain nodes that obtain the bill asset transfer business indicated by the first cross-chain asset transfer request can be collectively referred to as the above-mentioned first consensus nodes.
  • the entity objects for example, enterprise object A, enterprise object B, ..., enterprise object C
  • the blockchain nodes associated with the business object for example, the above-mentioned business node 110c
  • the core consensus network for example, the above-mentione
  • Figure 2a is a schematic diagram of an application architecture provided by an embodiment of the present application, through which the asset transfer method based on multiple blockchains proposed in the present application can be executed.
  • it can include a first consensus node (i.e., a consensus node in the first chain network corresponding to the first chain in Figure 1 above), a second consensus node (i.e., a consensus node in the second chain network corresponding to the second chain in Figure 1 above), a target consensus node (i.e., a consensus node in the target chain network corresponding to the target chain in Figure 1 above), a cross-chain relay between the first consensus node and the second consensus node, and a business node corresponding to the business object.
  • a first consensus node i.e., a consensus node in the first chain network corresponding to the first chain in Figure 1 above
  • a second consensus node i.e., a consensus node in the second chain network corresponding to the second chain in Figure 1 above
  • a target consensus node
  • the business object generates a first cross-chain asset transfer request for the first cross-chain transfer transaction through the business node;
  • the aforementioned first cross-chain asset transfer request carries the business data information configured by the target consensus node for the business object, and the target consensus node stores the source configuration data information for the business object;
  • the first consensus node writes the transaction data of the first cross-chain transfer transaction carried in the first cross-chain asset transfer request into the first cross-chain bridge contract on the first chain (when the first asset is a bill asset, the first cross-chain bridge contract can be called the first bill cross-chain bridge contract, for example), and determines whether the business object has the cross-chain asset transfer authority based on the first cross-chain bridge contract and the business data information, that is, queries the cross-chain asset transfer authority through the target consensus node; for example, it can be based on the first cross-chain bridge contract, the business data information and the cross-chain authorization management contract on the target chain, obtain the source configuration data information from the target chain, and determine the cross-chain asset transfer authority of
  • the first asset contract on the first chain (when the first asset is a bill asset, the first asset contract can be called a bill asset contract, for example) is called to lock the first asset (for example, a bill asset), and the first cross-chain event corresponding to the first cross-chain transfer transaction is generated to instruct the cross-chain relay (used to isolate the second chain network and the first chain network) to send the constructed first cross-chain transfer transaction to the second consensus node.
  • the cross-chain relay used to isolate the second chain network and the first chain network
  • the second consensus node can call the second asset contract (when the first asset is a bill asset, the second asset contract can be called a bill asset mapping contract, for example) on the second chain when writing the transaction data of the first cross-chain transfer transaction to the second cross-chain bridge contract (when the first asset is a bill asset, the second cross-chain bridge contract can be called a second bill cross-chain bridge contract, for example) on the second chain to cast a second asset with the same asset content as the first asset (when the first asset is a bill asset, the second asset can be called a bill mapping asset, for example), so that the first consensus node can transfer the first asset belonging to the business object from the first chain to the second chain.
  • the security and reliability of cross-chain transfer of on-chain assets can be improved through the mutual cooperation of multiple blockchains.
  • FIG. 2a is only an exemplary representation of the possible application architecture of the technical solution of the present application, and does not limit the specific architecture of the technical solution of the present application, that is, the technical solution of the present application can also provide other forms of application architecture.
  • the electronic device can execute the multi-blockchain-based asset transfer method to improve the business stability of the business executed on the chain according to actual business needs.
  • the technical solution of the present application can be applied to any on-chain asset transfer scenario, and the on-chain asset can be various types of bill assets, such as tax bills, such as ordinary electronic invoices, value-added tax invoices, etc.; or medical bills, such as electronic prescriptions, electronic bills, etc. This is not limited here.
  • FIG. 2b is a scenario diagram of a blockchain electronic invoice platform based on multiple blockchains provided in an embodiment of the present application.
  • the blockchain electronic invoice platform can be a specific business platform in the above-mentioned blockchain electronic invoice system. It should be understood that in the blockchain electronic invoice platform, in order to reduce the complexity of the business executed on the chain and the data storage on the chain, a new multi-chain system based on blockchain electronic invoices is proposed, and the multi-chain system mainly involves the blockchain electronic invoice three-chain network shown in Figure 2b. As shown in Figure 2b, the management chain, invoice chain and application contract chain mentioned above can be deployed in the blockchain electronic invoice three-chain network.
  • the mutual cooperation between the management chain, the invoice chain and the application contract chain can provide the entire blockchain electronic invoice platform with the functional characteristics of independently executing different businesses.
  • Each blockchain executes different businesses respectively and can cooperate with each other for the same business, so that under the premise of mutual cooperation between the three chains, a system can be constructed.
  • the multi-chain system is taken as a three-chain system as an example.
  • the management chain, the bill chain and the application contract chain are all built independently, that is, the consensus node used to maintain the management chain is different from the consensus node used to maintain the bill chain, and different from the consensus node used to maintain the application contract chain.
  • the management chain deployed in the blockchain electronic bill three-chain network is independent of the bill chain and the application contract chain, that is, the three independently built blockchains are independent of each other, but the three independently built blockchains can exchange data in a cross-chain manner, that is, the three chains can interact cross-chain.
  • the first bill cross-chain bridge contract (the first cross-chain bridge contract mentioned above) is deployed on the bill chain as shown in Figure 2b
  • the consensus node participating in the maintenance of the bill chain (the first consensus node mentioned above) can read the business data information on the management chain through the first bill cross-chain bridge contract to confirm the authority of the business object (such as the cross-chain asset transfer authority).
  • the consensus node participating in maintaining the application contract chain i.e., the second consensus node mentioned above
  • the consensus node participating in maintaining the application contract chain can confirm the authority of the business object (such as the cross-chain asset transfer back authority) by cross-chain reading the business data information on the management chain through the second bill cross-chain bridge contract, and can also perform corresponding derivative business by cross-chain reading the on-chain data on the bill chain (for example, the bill assets belonging to the business object on the bill chain) through the second bill cross-chain bridge contract (for example, the above-mentioned credit investigation business can be performed through the bill assets transferred from the bill chain to obtain the corporate credit information of a certain enterprise).
  • the management chain here can be used to provide management functional characteristics for the entire blockchain electronic bill platform, and the bill chain here can provide the functional characteristics of bill business of different business authority types for the entire blockchain electronic bill platform.
  • the embodiment of the present application proposes that a more standardized, flexible and fully functional derivative business can be provided through another blockchain independent of the management chain and the bill chain (i.e., the application contract chain shown in FIG2b), that is, the application contract chain here can provide the entire blockchain electronic bill platform with the functional characteristics of carrying out derivative business based on the on-chain data in the electronic bill.
  • the consensus network 100a shown in Figure 1 the consensus network 100a shown in Figure 1 as an example.
  • the consensus node participating in the maintenance of the management chain can be the above-mentioned management consensus node.
  • multiple smart contracts are deployed on the management chain, and these smart contracts can run on the management consensus node.
  • the multiple smart contracts here can specifically include the object authority management contract, object identity management contract, metadata management contract, internal management contract and cross-chain authorization management contract shown in Figure 2b.
  • these smart contracts deployed on the management chain are determined by the internal participants (i.e., the tax management department) shown in Figure 2b through the corresponding management contract templates deployed on their own chains (i.e., the management chain).
  • the aforementioned tax administration department can exercise management responsibilities through the management consensus node deployed in the management chain network.
  • the management responsibilities here may include managing the information within the business department (for example, the information of the internal personnel of the tax administration department), managing the business logic rules of the overall business (for example, the derivative business contract for executing the business logic of the derivative business running on the application contract chain), managing the metadata information of the overall business (for example, the access traffic at the entrance of each chain under the three-chain system), and managing the identity and rights of the participants of the overall business (for example, personal objects, corporate objects, tax business participants and other business objects).
  • the management chain maintained by the management consensus node is a relatively more stable blockchain with the smallest data scale but the highest security.
  • the core consensus network i.e., the above-mentioned electronic bill network
  • the consensus node participating in the maintenance of the bill chain can be the above-mentioned first consensus node.
  • multiple smart contracts are deployed on the bill chain, and these smart contracts can run on the first consensus node.
  • the multiple smart contracts here can specifically include the electronic bill issuance contract, electronic bill circulation contract, electronic bill red-chase contract, electronic bill archiving contract and the first bill cross-chain bridge contract (which can be used to execute bill asset transfer business) shown in FIG. 2b.
  • these smart contracts deployed on the bill chain are determined by the internal participants shown in FIG. 2b (for example, the tax department associated with the electronic bill data center) through the corresponding bill business contract template deployed on the management chain.
  • the first consensus node deployed in the electronic bill network can maintain the business logic of the electronic bill throughout its life cycle through the bill chain.
  • the bill chain can manage the entire life cycle of all issued electronic bills.
  • the full life cycle of the electronic bill here includes the issuance of the electronic bill, the circulation of the electronic bill, and the reimbursement of the electronic bill.
  • the bill chain maintained by the first consensus node has the characteristics of high performance and low latency.
  • the core consensus network where the application contract chain is located i.e., the above-mentioned application contract chain network
  • the consensus node involved in maintaining the application contract chain can be the above-mentioned second consensus node.
  • multiple smart contracts are deployed on the application contract chain, and these smart contracts can specifically run on the second consensus node.
  • the multiple smart contracts here can specifically include the virtual machine compatible contract, open contract deployment contract, derivative business contract and second bill cross-chain bridge contract shown in Figure 2b (which can be used to execute bill mapping asset transfer business).
  • the second consensus node deployed in the application contract chain network can carry the derivative business corresponding to the variable bill business through the application contract chain, for example, the derivative business here can include the above-mentioned credit investigation business, the above-mentioned qualification identification business, etc.
  • the application contract chain maintained by the second consensus node can support the business collaboration department and alliance chain partner shown in Figure 2b (i.e., the business-related department shown in Figure 2b), and indirectly call the second bill cross-chain bridge contract through the tax application contract (open contract deployment contract) shown in Figure 2b, so as to use the management application contract template read across the chain to develop smart contracts related to derivative business (for example, the derivative business contract shown in Figure 2b), and the derivative business contract can be deployed on the application contract chain after review by the tax management department.
  • the smart contract deployed on the application contract chain can realize the flexible upgrade and change of the smart contract through the virtual machine compatible contract.
  • the second consensus node can realize cross-chain interaction through the second bill cross-chain bridge contract on the application contract chain, for example, the above-mentioned chain data can be read from the bill chain through the second bill cross-chain bridge contract to execute the derivative business.
  • the application contract chain maintained by the second consensus node has the highest openness compared to the management chain and the bill chain, and supports complex smart contract logic, has more participants and is constantly changing dynamically, and its performance is relatively lower than that of the bill chain.
  • the consensus algorithm adopted by the management chain is different from the consensus algorithm adopted by the bill chain and the consensus algorithm adopted by the application contract chain.
  • the consensus algorithm associated with the management chain is an instant deterministic consensus algorithm.
  • the instant deterministic consensus algorithm here can be a PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, through which the status of a proposed block to be put on the chain can be immediately determined.
  • PBFT Manufacturing Byzantine Fault Tolerance
  • the management chain is a blockchain in the above-mentioned management chain network, and the consensus nodes in the management chain network (i.e., the above-mentioned management consensus nodes) can be managed by the tax management department shown in Figure 2b.
  • the internal participant associated with the management chain can be the tax management department shown in FIG. 2b.
  • the tax management department when the tax management department participates in the management chain as an internal participant, it can manage some internal states of the tax management department through the internal management contract on the management chain. For example, it can manage the various personnel in the tax management department. For example, it can configure specific tax management personnel, tax development personnel, tax audit personnel, etc. among these personnel in the tax management department.
  • the tax management department participates in the management chain as an internal participant, it can also manage some parameters in the three-chain system through the internal management contract on the management chain. For example, the access flow parameters corresponding to the access flow at the entrance of the bill chain shown in FIG. 2b can be restricted through the internal management contract.
  • the access flow in certain specific time periods at the entrance of the bill chain can be controlled to be not greater than the access flow threshold through the time-sharing access mechanism.
  • the tax management department participates in the management chain as an internal participant, it can also limit the node quantity parameters corresponding to the number of consensus nodes on each chain participating in the consensus through the internal management contract on the management chain.
  • the consensus algorithm associated with the bill chain is another instant deterministic consensus algorithm.
  • the instant deterministic consensus algorithm here can be a TBFT (Tower Byzantine Fault Tolerance) consensus algorithm.
  • the TBFT consensus algorithm is a Byzantine fault-tolerant algorithm that can ensure the safe operation of the entire electronic bill network system when the number of Byzantine nodes (i.e., the number of malicious nodes in the electronic bill network) is less than 1/3 of the total number of nodes in the electronic bill network.
  • the consensus nodes in the electronic bill network can be managed by the aforementioned tax administration department.
  • specific tax personnel in the tax administration department can control the number of consensus nodes in the electronic bill network through the internal management contract in the above-mentioned management chain.
  • the tax bureau terminal corresponding to a specific tax personnel in the tax administration department can be Participate in the formation of this electronic ticket network.
  • the PBFT consensus algorithm has a fixed leader node (i.e., the master node) for packaging transactions in the transaction pool.
  • the view-change sub-protocol i.e., a master node switching sub-protocol
  • the leader node is rotated based on a rotation mechanism. For example, when the current node is used as the leader node, every time X blocks are submitted (the value of X can be configured), the leader node will be automatically rotated to the next node. This means that the consensus node in the electronic bill network corresponding to the bill chain can be used for continuous block generation.
  • the consensus algorithm associated with the application contract chain is another instant deterministic consensus algorithm.
  • the instant deterministic consensus algorithm here can be a PoS (Proof-of-Stake, Proof of Stake) consensus algorithm.
  • the network security of the application contract chain network where the application contract chain is located can be maintained through the Proof of Stake consensus algorithm, and the status of a proposed block to be on the chain can be immediately determined through the Proof of Stake consensus algorithm.
  • the consensus nodes in the application contract chain network can be jointly managed by the tax management department and business collaboration department shown in Figure 2b and large participating institutions (i.e., the large enterprises in the aforementioned alliance chain, which are the business-related departments shown in Figure 2b).
  • the tax personnel in the tax management department can read the bill information of the electronic bill written on the aforementioned bill chain through the consensus node in the application contract chain network, so as to execute the derivative business associated with the aforementioned bill business through the bill information read across the chain.
  • the bill information read across the chain can be used to identify the qualifications or credit of the billing enterprise requesting the billing, so as to obtain the qualification data or credit data of the billing enterprise.
  • the management chain shown in Figure 2b can support a specific language smart contract engine, and the above-mentioned management consensus node can deploy a specific language smart contract on the management chain through the specific language smart contract engine.
  • the object permission management contract, object identity management contract, metadata management contract, internal management contract, cross-chain authorization management contract, etc. shown in Figure 2b above can be deployed on the management chain. It should be understood that these smart contracts can be developed and managed by specific tax management personnel in the tax management department.
  • the bill chain has built-in smart contracts with specific bill business logic.
  • These smart contracts for example, the electronic bill issuance contract, the electronic bill circulation contract, the electronic bill red-charge contract, the electronic bill archiving contract and the first bill cross-chain bridge contract shown in FIG. 2b above
  • the embodiment of the present application can update the electronic bill template in the electronic bill issuance contract by reading the latest version of the electronic bill template from the management chain, and then update and process the above-mentioned bill business according to the updated electronic bill issuance contract.
  • the bill chain does not support an independent smart contract engine, and naturally does not support the deployment of other contracts unrelated to the bill business on the bill chain.
  • the advantage of this is that the bill chain only runs the business logic related to the electronic bill, and is not affected by other smart contracts, so that the operation of the bill chain can be more independent, stable, and more resistant to attacks.
  • the application contract chain supports multi-language, Turing-complete smart contracts for developers.
  • developers access the application contract chain through the application contract chain entrance, they can use the virtual machine compatible contract to be compatible with the mainstream EVM virtual machine, so that they can deploy and run various new business contracts on the compatible virtual machine.
  • derivative business contracts associated with derivative businesses such as the above-mentioned lottery business
  • a derivative application contract associated with another derivative business eg, the above-mentioned tax refund business
  • the consensus node associated with the bill chain can read part of the management chain information from the management chain through the first bill cross-chain bridge contract shown in Figure 2b, for example, the source configuration data information used to confirm the business rights of the business object (such as the cross-chain asset transfer right) can be read from the management chain.
  • the latest electronic bill template can also be read from the management chain.
  • the consensus node associated with the application contract chain can read part of the management chain information from the management chain through the second bill cross-chain bridge contract shown in Figure 2b.
  • the source configuration data information used to confirm the business rights of the business object can be read from the management chain.
  • the latest application contract template can also be read from the management chain.
  • the second consensus node can also read part of the bill chain information from the bill chain across the chain (for example, reading the bill assets used to execute derivative business from the bill chain).
  • the public network participants associated with the management chain can be the individual objects and corporate objects shown in FIG2b.
  • the public network participants associated with the invoice chain can be the local electronic invoice data flow systems shown in FIG2b.
  • the local electronic invoice data flow systems here specifically include local electronic invoice business issuance systems (for example, local tax bureau systems), electronic invoice invoicing service providers, large enterprise finance and taxation related systems, etc.
  • the public network participants associated with the application contract chain can be the tax business participants and developers shown in FIG2b.
  • the chain entry associated with the management chain may be the management chain entry shown in FIG2b.
  • the management chain may be accessed through the management chain entry, and then identity registration and identity authorization services may be performed through the management chain.
  • the chain entry associated with the bill chain may be the bill chain entry shown in FIG2b.
  • the bill chain may be accessed through the bill chain entry, and the bill asset cross-chain transfer business, electronic bill issuance business, electronic bill circulation business, electronic bill redemption business, and electronic bill archiving business may be performed through the bill chain.
  • the chain entry associated with the application contract chain may be the application contract chain entry shown in FIG2b.
  • the tax business participants and developers shown in FIG2b act as public network participants, they may access the application contract chain through the application contract chain entry, and then deploy derivative business contracts on the application contract chain to execute derivative business related to electronic invoices through the deployed derivative business contracts.
  • the developer shown in FIG2b may also deploy derivative business contracts corresponding to other derivative businesses (or exploratory businesses) on the application contract chain when accessing the application contract chain, and the number of derivative business contracts deployed on the application contract chain will not be limited here.
  • management chain entrance shown in FIG. 2b may be a tax management department entrance, through which the individuals, legal persons and entities that need to access the management chain can be identified and business guided.
  • the bill chain entry shown in Figure 2b can be an electronic bill business entry, through which the transaction business data (also referred to as transaction data) of the electronic bill requested to be issued by a certain business object (for example, a business object with bill assets on the chain, such as the above-mentioned enterprise B) can be received.
  • a certain business object for example, a business object with bill assets on the chain, such as the above-mentioned enterprise B
  • the above-mentioned first consensus node when the above-mentioned first consensus node receives the transaction business data submitted by the above-mentioned enterprise B through the electronic bill business entry (such as the first cross-chain transfer transaction corresponding to the transfer business), it can also verify the access identity and access rights of the data sender of the transaction business data (that is, enterprise B as the business object) through the electronic bill business entry to see whether they meet the status requirements of the identity authority contract in the management chain. For example, when the first consensus node passes the verification, it can determine that enterprise B as the business object is the authorized object, and then read the source configuration data information of the business object from the management chain through the first bill cross-chain bridge contract on the bill chain to determine the business rights (such as cross-chain asset transfer rights) of enterprise B as the authorized object. It should be understood that the source configuration data information can be further used to determine whether the business rights of enterprise B as the authorized object meet the status requirements of the cross-chain authorization management contract in the management chain.
  • the first consensus node can determine the data sender (i.e., enterprise B) through the electronic bill business entry. Whether the access identity and access authority meet the contract status requirements of the object identity management contract and the internal management contract in the management chain, and then when it is determined that the contract status requirements of the object identity management contract and the internal management contract in the management chain are met, it can be determined that the identity authentication of the data sender (i.e., the aforementioned enterprise B) who needs to access the bill chain is completed.
  • the bill chain entrance shown in Figure 2b above stores the registration data information of each authorized object synchronized from the management chain.
  • the registration data information here may include but is not limited to object access identity registration information and object access authority registration information.
  • the object access identity information here can be used to identify whether the business object (i.e., the aforementioned enterprise B) currently requesting access to the bill chain is an authorized object.
  • the object access authority registration information here includes the request accumulation threshold (for example, the maximum concurrent request accumulation) configured by the management consensus node for the electronic bill business entrance of the bill chain through the internal management contract.
  • the request accumulation threshold for example, the maximum concurrent request accumulation
  • the first consensus node successfully authenticates the data sender, it can read the source configuration data of the business object from the management chain, and then determine whether the authorized object (i.e., the aforementioned enterprise B) meets the contract status requirements of the cross-chain authorization management contract in the management chain.
  • the application contract chain entry shown in FIG2b can be a tax derivative business entry, through which a certain business object (for example, a second business object, which can be a tax business participant shown in FIG2b) can be received to participate in a derivative business associated with the bill business.
  • a certain business object for example, a second business object, which can be a tax business participant shown in FIG2b
  • the tax business participant and the developer shown in FIG2b can verify the business participation license certificate submitted by the second business object (for example, the tax business participant or the developer) through the application contract chain entry, and then the second business object can be allowed to access the application contract chain when the verification is successful, so as to execute the derivative business associated with the aforementioned bill business on the application contract chain.
  • the internal participants involved in maintaining the management chain can be the tax management department shown in Figure 2b.
  • the tax management department here is mainly used to configure and manage internal state parameters on the management chain, and can also be used to change the above metadata information (for example, tax metadata) on the chain (such as updating electronic invoice templates, updating tax calculation rules, etc.), and can manage the identities and permissions of various business participants maintained on the management chain (such as freezing the company's invoicing qualifications, limiting the company's invoicing quota, and the authority to transfer invoice assets across chains, etc.).
  • the internal participants involved in maintaining the bill chain may be the electronic bill data center shown in FIG2b, where the electronic bill data center may specifically be an electronic invoice data center, which may be used for off-chain backup, statistics, data analysis and review of the massive amount of account book data recorded on the bill chain (e.g., the electronic bill flow generated based on the above-mentioned real-time bill business flow, etc.).
  • the electronic bill data center may count the number of invoices issued at different times, and then the risk bills (e.g., risk invoices) and risky enterprises may be judged based on the counted number of invoices issued at different times, and data analysis of relevant financial and economic data may also be performed.
  • the internal participants participating in the maintenance of the application contract chain can be the business collaboration department and the business association department shown in FIG2b. It should be understood that, in addition to the tax management department, the internal participants participating in the maintenance of the application contract chain, other departments (i.e., the aforementioned business collaboration departments) and participants (i.e., the aforementioned business association departments) in the system alliance chain can further execute the corresponding derivative business through the derivative business contract on the application contract chain when accessing the application contract chain.
  • the business collaboration department and the business association department shown in FIG2b have the advantage of accessing the application contract chain in that they can flexibly run various types of scalable derivative businesses in the support of a complete smart contract declaration cycle to ensure the flexibility of business changes, and at the same time, do not need to directly contact the on-chain data of the electronic bills on the above-mentioned bill chain, thereby ensuring the data privacy and on-chain data security on the bill chain.
  • the bill assets that need to carry out derivative business can be transferred from the bill chain to the application contract chain, where the application contract chain can only access the transferred bill assets, and cannot access the on-chain data other than the bill assets (such as other on-chain data on the block where the bill assets are located).
  • this part of the transferred bill assets is authorized to be visible to the application contract chain on the bill chain, so that the derivative business requested by the business object based on the bill assets can be effectively carried out on the application contract chain.
  • the object identity management contract built into the management chain can be specifically a user management contract, through which the identities of the accessors (e.g., public network participants) and participants (e.g., internal participants) under the entire three-chain system can be managed.
  • the accessors and participants here can specifically include tax management personnel (referred to as administrators), business collaboration departments, local tax bureaus, invoicing service providers, reimbursement service providers, tax review departments, etc.
  • the object authority management contract built into the management chain can be specifically an enterprise identity management contract, through which the business authority and tax status of certain enterprises can be managed.
  • the metadata management contract built into the management chain can be specifically a tax metadata management contract, through which metadata information such as tax rules can be managed, such as the contract modules, tax calculation logic, and the latest policy rules under the three-chain system can be centrally managed.
  • the internal management contract built into the management chain can be used to manage some internal states of the tax management department, and can manage some internal parameters on each chain under the three-chain system.
  • the internal management contract can be used to limit the access traffic parameters at the above-mentioned bill chain entrance (for example, the electronic invoice business entrance), as well as the number of consensus nodes under the three-chain system.
  • the present application relates to a cross-chain authorization management contract in the management chain.
  • the cross-chain authorization management contract can be used to configure business data information for permission verification for business objects that request to perform cross-chain transfer of bill assets.
  • the management consensus node configures the corresponding business data information for the business object
  • the configured corresponding business data information can be uploaded to the management chain as the source configuration data information, and the configured corresponding business data information can also be returned to the business object to further execute the transfer business corresponding to the bill asset on the bill chain that requests the cross-chain transfer of bill assets.
  • the business object can store the business data information locally.
  • the smart contract built into the bill chain can include the first bill cross-chain bridge contract and the bill business contract associated with the electronic bill life cycle.
  • the bill business contract here can specifically include the electronic bill issuance contract for providing electronic bill issuance services, the electronic bill circulation contract for providing electronic bill circulation services, the electronic bill red-back contract for providing electronic bill red-back services, and the electronic bill archiving contract for providing electronic bill archiving services.
  • the first bill cross-chain bridge contract can be used for cross-chain transfer of bill assets (for example, the bill assets can be transferred from the bill chain to the application contract chain), and the business data information configured for the business object on the cross-chain reading management chain to query the permissions of the business object currently requesting the cross-chain transfer of bill assets, such as querying the cross-chain asset transfer permissions of the business object.
  • the smart contracts built into the application contract chain can include the second bill cross-chain bridge contract, and can also include various contracts deployed by tax derivative business participants (i.e. derivative business objects, for example, tax business participants shown in Figure 2b) (for example, virtual machine compatibility contracts, tax application contracts, and derivative business contracts shown in Figure 2b, etc.).
  • the derivative business contract here can specifically be a credit investigation business contract based on electronic bills, through which the credit investigation business contract can be analyzed to obtain the credit investigation data of a certain enterprise.
  • the derivative business contract here can also be a chain lottery business contract, a talent incentive contract, and a tax refund business contract deployed to encourage invoicing.
  • the second bill cross-chain bridge contract here can be used to cross-chain read metadata information on the management chain (for example, the latest policy rules associated with the tax refund business) to update some business parameters of the application contract chain (for example, the contract parameters of the tax refund business contract deployed on the application contract chain can be updated).
  • the second bill cross-chain bridge contract here can also be used for cross-chain transfer of bill assets (for example, the bill assets can be transferred from the bill chain to the application contract chain to execute the business logic of the derivative business on the application contract chain through this part of the cross-chain transferred electronic bill, that is, it can be used for cross-chain reading of the electronic bill on the bill chain that is authorized to be visible for the requested derivative business), as well as cross-chain reading of business data information configured for business objects on the management chain to query the permissions of the business object that currently requests the cross-chain transfer of bill mapping assets, such as querying the cross-chain asset transfer back permissions of the business object.
  • the bill assets can be transferred from the bill chain to the application contract chain to execute the business logic of the derivative business on the application contract chain through this part of the cross-chain transferred electronic bill, that is, it can be used for cross-chain reading of the electronic bill on the bill chain that is authorized to be visible for the requested derivative business
  • cross-chain reading of business data information configured for business objects on the management chain to query the permissions
  • the management chain shown in FIG. 2b is mainly used to process data with a small amount of data and a relatively constant state.
  • the management business flow of the entire management chain is relatively low in openness, and can be used for internal management of some tax data.
  • the bill chain shown in Figure 2b above it can be used to process some real-time bill business flows with a long-term high-frequency request state of data volume.
  • the openness of the entire bill chain is relatively high, and the relevant authoritative institutions in the life cycle of the electronic bill itself can be allowed to participate in the corresponding bill business.
  • the consensus node corresponding to the agent service provider can be allowed to issue an electronic bill for a user who currently requests invoicing.
  • the size of the data volume can be unlimited, and the frequency of business changes fluctuates relatively large. It is mainly possible to process various types of cooperative business, derivative business, exploratory business, etc. through the application contract chain.
  • the application contract chain has the highest openness, and can run participants authorized by the management chain to deploy smart contracts on the application contract chain, run exploratory derivative business, etc.
  • the smart contract built into the application contract chain can have more contract security restrictions when it is executed.
  • the number of contract execution steps can be limited (for example, for the derivative business contract shown in Figure 2b above, it can be limited which contract methods in the derivative business contract the current business object (i.e., the second business object mentioned above) can access), and the storage resource data required to access the derivative business contract can be restricted (i.e., the call of the smart contract on the application contract requires a certain amount of storage resource data).
  • the consensus node under the three-chain system involved in the embodiment of the present application can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.
  • basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.
  • the consensus node in the embodiment of the present application obtains on-chain assets (such as bill assets, such as electronic bills, etc.) and other data of a business object (for example, the above-mentioned personal object or corporate object) across the chain, it can display a prompt interface or pop-up window.
  • the prompt interface or pop-up window is used to prompt the business object that it is currently collecting data such as bill assets. Only after the business object issues a confirmation operation on the prompt interface or pop-up window, the relevant steps of data acquisition are started, otherwise it ends.
  • business data of business objects such as users, enterprises, and institutions may be involved (for example, users' invoicing information, credit information, tax refund information, etc., and enterprises' income and expenditure, enterprise qualifications, etc.).
  • business objects such as users, enterprises, and institutions
  • the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.
  • the specific process of executing the bill business on the bill chain and the specific process of executing the derivative business associated with the bill business on the application contract chain can be referred to the embodiments shown in Figures 3 to 11 below.
  • the bill chain mentioned below is the first chain
  • the application contract chain mentioned is the second chain
  • the management chain mentioned is the target chain
  • the electronic bill network mentioned is the first chain network
  • the application contract network mentioned is the second chain network
  • the management chain network mentioned is the target chain network
  • the management consensus node mentioned is the target consensus node.
  • FIG3 is a flowchart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application.
  • the method can be executed by the first consensus node in the first chain network (such as an electronic bill network) corresponding to the first chain (such as a bill chain) mentioned above.
  • the first consensus node can be any consensus node in the consensus network 200a shown in FIG1 above.
  • the method can include the following steps S301-S303:
  • Step S301 obtaining a first cross-chain asset transfer request sent by a business object for a first cross-chain transfer transaction.
  • the first cross-chain asset transfer request carries business data information configured for a business object by a target consensus node (such as a management consensus node) in a target chain network (such as a management chain network).
  • the business data information is information configured by the target consensus node for the business object and is used for permission verification.
  • the business data information is used for cross-chain permission verification.
  • the target consensus node stores source configuration data information configured for each business object, and the source configuration data information is also used for permission verification.
  • the business object After the target consensus node sends the source configuration data information to each business object, the business object stores the source configuration data information as business data information.
  • the source configuration data information at the location and the business data information at the business object can be used together to implement permission verification for the business object.
  • the business object can interact on the chain through the business node where it is located and any blockchain in the multiple blockchains, and call the relevant business contracts on the chain.
  • the business object can apply to the management consensus node corresponding to the management chain in advance for business data information used for cross-chain permission verification.
  • the business object When the business object generates the first cross-chain asset transfer request through the business node, it can obtain the business data information from the management chain, and generate the first cross-chain asset transfer request for the first cross-chain transfer transaction based on the obtained business data information.
  • the business object can store the business data information locally in advance through the business node, and when generating the first cross-chain asset transfer request, it can obtain the business data information from the local to generate the first cross-chain asset transfer request.
  • a cross-chain authorization management contract can be deployed on the management chain. Therefore, the business node where the business object is located can send a cross-chain permission application to the relevant bill department through the bill management entrance. After the relevant bill department has reviewed and approved the business object based on the cross-chain permission application, it calls the cross-chain permission application method in the cross-chain authorization management contract on the management chain to apply for cross-chain permissions for the business object and configure the business data information used to verify the cross-chain permissions for the business object. After the application is successful, the business data information is returned to the business object.
  • the management consensus node can store the business data information of the business object, such as in the management chain. At this time, the business data information stored on the management consensus node side can be called the source configuration data information of the business object. Business data information can be, for example, a dedicated authorization code configured for the business object, identity information of the business object, etc.
  • the first cross-chain transfer transaction in the first cross-chain asset transfer request is used to instruct the first consensus node to transfer the specified first asset (such as a bill asset) belonging to the business object from the bill chain to the second chain (such as an application contract chain) associated with the second consensus node through a cross-chain relay.
  • the second consensus node is a consensus node in the second chain network (such as an application contract chain network) corresponding to the application contract chain.
  • the first cross-chain transfer transaction in the first cross-chain asset transfer request is used to indicate that the electronic invoices of the business object within 3 months are transferred from the bill chain to the application contract chain.
  • the application contract chain network corresponding to the application contract chain is independent of the management chain network corresponding to the management chain and the electronic bill network corresponding to the bill chain.
  • the business object when the business object generates the first cross-chain asset transfer request through the business node, it can also specify the asset usage permission for the bill asset to be transferred, and write the executed asset usage permission into the first cross-chain transfer transaction.
  • the asset usage permission can be used only for bill redemption business, bill transfer business, etc.
  • Step S302 write the transaction data of the first cross-chain transfer-out transaction into the first cross-chain bridge contract on the first chain.
  • the first consensus node can write the transaction data of the first cross-chain transfer transaction obtained from the first cross-chain asset transfer request into the first cross-chain bridge contract (for example, the first bill cross-chain bridge contract).
  • the first bill cross-chain bridge contract can be used to verify the authority of the first cross-chain transfer transaction, and perform the bill asset transfer process after the authority verification is passed.
  • the asset usage permission of the bill asset corresponding to the first cross-chain transfer transaction can be specified. For example, specify that the bill asset can only be used for bill redemption business after transfer.
  • Step S303 When it is determined based on the first cross-chain bridge contract and the business data information that the business object has the cross-chain asset transfer authority, the first asset contract on the first chain is called to lock the first asset, and a first cross-chain event corresponding to the first cross-chain transfer transaction is generated.
  • the first bill cross-chain bridge contract can be used to verify the authority of the first cross-chain transfer transaction, and when the verification is passed and it is determined that the business object has the cross-chain asset transfer authority, the bill asset transfer process is executed.
  • the cross-chain asset transfer authority is determined by the target consensus node in the target chain network, or is jointly determined by the target consensus node and the first consensus node. In some embodiments, the cross-chain resource transfer authority is determined based on the source configuration data information and business data information obtained by querying the target consensus node.
  • the permission verification based on the first bill cross-chain bridge contract to determine whether the business object has the cross-chain asset transfer authority can be to call the cross-chain permission query method in the first bill cross-chain bridge contract to generate a transfer authority verification request; the transfer authority verification request is used to instruct the management consensus node to call the cross-chain permission management contract on the management chain to query the source configuration data information of the business object, such as calling the cross-chain permission query method in the cross-chain permission management contract.
  • the first consensus node receives the source configuration data information returned by the management consensus node based on the transfer authority verification request, and compares the source configuration data information with the business data information carried in the first cross-chain transfer request to obtain the information comparison result, and then determines whether the business object has the cross-chain asset transfer authority based on the information comparison result. For example, the business data information and the source configuration data information can be compared through the information comparison method in the first bill cross-chain bridge contract.
  • permission verification is performed based on the first bill cross-chain bridge contract to determine whether the business object has the cross-chain asset transfer authority.
  • the first bill cross-chain bridge contract is called to generate a transfer authority verification request carrying business data information; the transfer authority verification request is used to instruct the management consensus node to call the cross-chain authorization management contract on the management chain to query the source configuration data information of the business object, and compare the source configuration data information with the business data information in the transfer authority verification request to obtain an information comparison result;
  • the management consensus node may call the cross-chain permission query method in the cross-chain permission management contract on the management chain to query whether the business object has the source configuration data information, and call the information comparison method in the cross-chain permission management contract to compare the business data information with the source configuration data information; the first consensus node receives the information comparison result returned by the management consensus node based on the transfer authority verification request, and determines whether the business object has the cross-chain asset transfer authority based on the information comparison result.
  • determining whether a business object has the authority to transfer cross-chain assets can be that if the information comparison result indicates that the comparison is successful, that is, the business data information is the same as the source configuration data information, then it is determined that the business object has the authority to transfer cross-chain assets, that is, it is determined that the transfer of bill assets at this time is legal; if the information comparison result indicates that the comparison is unsuccessful, that is, the business data information is different from the source configuration data information, then it is determined that the business object does not have the authority to transfer cross-chain assets.
  • the method of locking the bill asset may be to call a first asset contract (such as a bill asset contract) to switch the asset state of the bill asset from the first state to the second state.
  • the bill asset contract is used to manage the entire life cycle of the bill asset on the chain and various bill attributes (such as the asset state of the bill asset, the asset attribute state, etc.).
  • the transferred bill asset can be locked and the transferred back bill asset can be unlocked.
  • calling the bill asset contract to switch the asset status can be through the asset contract calling method in the first bill cross-chain bridge contract, calling the bill asset contract to switch the asset status of the bill asset on the bill chain.
  • the first state can refer to the normal state, that is, indicating that the bill asset is in an unlocked state; the second state can refer to the locked state, that is, indicating that the bill asset is in a locked state.
  • the locked bill assets on the bill chain cannot be operated and modified.
  • the contract deployed on the bill chain (such as the first bill cross-chain bridge contract) has the ability to call contracts (such as bill asset contracts) across chains.
  • the first consensus node when it detects that the asset status of the bill asset is the second status, it can call the first bill cross-chain bridge contract to generate the first cross-chain event corresponding to the first cross-chain transfer transaction, which means that the first cross-chain transfer transaction is completed on the first consensus node.
  • the event generation method in the first bill cross-chain bridge contract can be called to generate the first cross-chain event according to the first cross-chain transfer transaction.
  • the event generation method on the first bill cross-chain bridge contract may be called, and the private key information on the bill chain may be used to sign information such as the bill assets, the asset attribute status of the bill assets, and the first cross-chain transfer transaction, to obtain the first event signature information, and generate the first cross-chain event based on the first event signature information and the aforementioned information.
  • the first bill cross-chain bridge contract is called to determine the authority parameter corresponding to the asset usage authority, and the authority parameter is signed together when generating the first event signature information, and the first cross-chain event is constructed together with the obtained first event signature information and the authority parameter, that is, the generated first cross-chain event carries the authority parameter corresponding to the transferred bill asset.
  • the authority parameter is used to characterize the asset usage specified for the bill asset after the transfer.
  • the first cross-chain event is used to instruct the cross-chain relay to send the first cross-chain transfer-in transaction to the second consensus node when constructing the first cross-chain transfer-out transaction corresponding to the first cross-chain transfer-in transaction.
  • the first cross-chain transfer-in transaction is used to instruct the second consensus node to transfer the bill asset to the application contract chain, that is, the second consensus node can be used to write the transaction data of the first cross-chain transfer-in transaction to the second cross-chain bridge contract (such as the second bill cross-chain bridge contract) on the application contract chain, and call the bill asset mapping contract indicated by the second bill cross-chain bridge contract to cast a second asset (such as a bill mapping asset) with the same asset content as the bill asset on the application contract chain.
  • the second cross-chain bridge contract such as the second bill cross-chain bridge contract
  • the first cross-chain transfer-in transaction and the first cross-chain transfer-out transaction are used to indicate the transfer of bill assets from the bill chain to the application contract chain.
  • the execution process of the first cross-chain transfer-in transaction by the second consensus node can refer to the relevant description of the embodiment shown in Figure 7 below.
  • the cross-chain relay can be used to isolate the application contract chain network and the electronic bill network.
  • the cross-chain relay can be operated by the relevant bill department and can be used to continuously capture cross-chain events between the bill chain and the application contract chain to generate corresponding cross-chain transactions to submit to another chain. Therefore, the cross-chain relay can detect the events generated by the first bill cross-chain bridge contract of the bill chain, and when the first cross-chain event is detected, the first cross-chain event is obtained from the bill chain of the first consensus node, and the first cross-chain transfer-out transaction, bill assets, asset attribute status, permission parameters and other information in the first cross-chain event are generated.
  • the corresponding first cross-chain transfer-in transaction is generated to realize the transfer of bill assets.
  • the first cross-chain transfer-in transaction contains bill assets and transaction parameters (such as asset attribute status, permission parameters and other information).
  • the cross-chain relay when the cross-chain relay reads the first cross-chain event, it needs to perform event verification on the first cross-chain event, and after the event verification is successful, generate the corresponding first cross-chain transfer-in transaction.
  • the first cross-chain event includes the first event signature information and the carried first event parameters (such as the first cross-chain transfer-out transaction, bill assets, asset attribute status, permission parameters and other information).
  • the aforementioned event verification process involved can be that the cross-chain relay performs signature verification on the first event signature information in the first cross-chain event through the public key information corresponding to the private key information of the bill chain, and obtains the first event parameters to be verified corresponding to the first event signature information after the signature verification is successful, and performs event comparison on the carried first event parameters and the first event parameters to be verified to obtain the event comparison result to determine the event verification result.
  • the event comparison result indicates that the event verification is successful; if the carried first event parameter and the first event parameter to be verified are different, the event comparison result indicates that the event verification is unsuccessful.
  • the three blockchains collaborate with each other to realize the transfer of bill assets, which can make the process of on-chain transfer business execution more concise and clear, and make the transfer efficiency of on-chain transfer business higher while other on-chain businesses can be executed normally, thereby improving the business stability of the transfer business, and further improving the security and reliability of cross-chain transfer of bill assets on the blockchain.
  • Figure 4 is a schematic diagram of a scenario of cross-chain asset transfer provided in an embodiment of the present application; wherein, business object A applies for cross-chain permissions to the management consensus node in advance through the business node, and the management consensus node configures business data information X for business object A by calling the cross-chain authorization management contract on the management chain, and stores the configured business data information.
  • the business data information stored by the management consensus node is the source configuration data information X'.
  • Business object A sends a first cross-chain asset transfer request for the first cross-chain transfer transaction to the first consensus node; the first cross-chain asset transfer request carries business data information X, and the first cross-chain asset transfer request is used to indicate the transfer of the bill asset P belonging to business object A; in addition, business object A can also specify the asset usage authority of P after the transfer (for example, it can only be used for redemption, etc.); for example, business object A can configure the first cross-chain transfer transaction and specify the asset usage authority through the transaction configuration interface displayed by the business node, and the business node generates the corresponding first cross-chain asset transfer request based on the operation of business object A in the transaction configuration interface.
  • the first consensus node writes the transaction data of the first cross-chain transfer transaction into the first bill cross-chain bridge contract, specifies the asset usage authority of the bill asset, and verifies the cross-chain asset transfer authority of the business object based on the first bill cross-chain bridge contract and the business data information X.
  • the aforementioned verification of the cross-chain asset transfer authority can be to generate a transfer authority verification request through the first bill cross-chain bridge contract and send it to the management consensus node.
  • the management consensus node queries the source configuration data information X' stored in the business object A based on the transfer authority verification request and the cross-chain authority management contract.
  • the first consensus node compares the business data information X and the source configuration data information X' to determine whether the business object has the cross-chain asset transfer authority (if X and X' are consistent, it is considered to have the authority). If it is determined that the business object has the cross-chain asset transfer authority, the first consensus node passes the first consensus node to verify the business object's cross-chain asset transfer authority.
  • a bill cross-chain bridge contract calls the bill asset contract to lock the bill asset P and generates a corresponding first cross-chain event; the cross-chain relay can detect and read the first cross-chain event, perform event verification on the first cross-chain event, and generate a corresponding first cross-chain transfer-in transaction when the event verification is successful; the first cross-chain transfer-in transaction carries P and transaction parameters (such as permission parameters determined based on asset usage permissions, etc.); the cross-chain relay sends a second cross-chain transaction request carrying the first cross-chain transfer-in transaction to the second consensus node, and the second consensus node performs the transfer process of P based on the first cross-chain transfer-in transaction and the second bill cross-chain bridge contract and bill asset mapping contract on the second consensus node.
  • P and transaction parameters such as permission parameters determined based on asset usage permissions, etc.
  • the embodiment of the present application provides an asset transfer mechanism based on multiple blockchains, which aims to emphasize that the cross-chain transfer of bill assets can be achieved through the mutual cooperation of the three chains.
  • the management chain is authorized to configure the above-mentioned business data information for the user (i.e., the aforementioned business object)
  • the user can initiate a transfer business for transferring bill assets from the bill chain to the application contract chain.
  • the transfer business is the above-mentioned first cross-chain transfer transaction.
  • the bill chain, management chain, and application contract chain involved in the embodiment of the present application are independent of each other, they can be used to execute different businesses respectively (for example, the bill business related to the bill asset itself can be executed on the bill chain, and the derivative business associated with the bill business can be executed on the application contract chain), thereby reducing the degree of confusion of the data stored on each chain.
  • the synchronous cross-chain execution of the transfer business can also be achieved when other businesses are normally executed on each chain, that is, without affecting the request of other businesses, thereby improving the transfer efficiency of cross-chain transfer of bill assets.
  • the transfer business for the bill assets is collaboratively executed through contracts deployed on the chain (such as the first bill cross-chain bridge contract, the bill asset contract, etc. on the bill chain), which can ensure that the business executed on the chain (i.e., the transfer business of transferring bill assets across chains) is not affected by other businesses, thereby ensuring the business stability of the transfer business.
  • contracts deployed on the chain such as the first bill cross-chain bridge contract, the bill asset contract, etc. on the bill chain
  • the bill asset needs to be transferred back to the bill chain from the application contract chain.
  • the process of the first consensus node receiving the transferred asset is described below.
  • FIG5 is a flowchart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application, which can be executed by a first consensus node in a first chain network (such as an electronic bill network) corresponding to the first chain (such as a bill chain) mentioned above, for example, the first consensus node can be any consensus node in the consensus network 200a shown in FIG1 above.
  • the method can include the following steps S501-S503 (which can be executed after step S303).
  • Step S501 receiving a second cross-chain transfer-in transaction sent by the cross-chain relay for the second asset.
  • the second cross-chain transfer-in transaction can be constructed when the cross-chain relay reads the second cross-chain event corresponding to the second cross-chain transfer-out transaction from the second consensus node.
  • the second cross-chain event can be generated by the second consensus node obtaining the second cross-chain transfer-out transaction submitted by the business object for the second asset (such as the bill mapping asset).
  • the cross-chain relay can detect the cross-chain event on the second cross-chain bridge contract (such as the second bill cross-chain bridge contract) of the second consensus node, and obtain the second cross-chain event from the second consensus node when the second cross-chain event is detected.
  • the cross-chain relay can construct a second cross-chain transfer-in transaction corresponding to the second cross-chain transfer-out transaction based on the second cross-chain event.
  • the second cross-chain transfer-in transaction and the second cross-chain transfer-out transaction are used to indicate that the bill mapping asset is transferred from the application contract chain to the bill chain, that is, the bill asset is transferred from the application contract chain back to the bill chain.
  • the way in which the second consensus node obtains the second cross-chain transfer-out transaction and generates the corresponding second cross-chain event can refer to the relevant description of the embodiment shown in Figure 9 below, and will not be further described here.
  • the cross-chain relay needs to perform event verification on the second cross-chain event when reading the second cross-chain event, and generate the corresponding second cross-chain transfer transaction when the event verification succeeds.
  • the event verification principle for the second cross-chain event is the same as the event verification principle for the first cross-chain event.
  • the second cross-chain event contains the second event signature information and the second event parameters (such as the second cross-chain transfer transaction, the bill mapping asset, the mapping asset attribute status and other information).
  • the second event signature information is obtained by the second consensus node using the private key information on the application contract chain to sign the second event parameters.
  • the cross-chain relay can use the public key information corresponding to the private key information of the application contract chain to perform signature verification on the second event signature information, obtain the event parameters to be verified corresponding to the second event signature information after the signature verification succeeds, and compare the event parameters to be verified with the second event parameters in the second cross-chain event. If the event parameters to be verified and the second event parameters are the same, it means that the event verification is successful.
  • Step S502 write the transaction data of the second cross-chain incoming transaction into the first cross-chain bridge contract, perform transaction verification on the second cross-chain incoming transaction based on the first cross-chain bridge contract, and obtain a first transaction verification result.
  • the second cross-chain transfer-in transaction when the first consensus node writes the transaction data of the second cross-chain transfer-in transaction into the first cross-chain bridge contract (such as the first bill cross-chain bridge contract), the second cross-chain transfer-in transaction can be verified to verify the correctness of the transaction source.
  • the first bill cross-chain bridge contract can be used to verify the transaction of the second cross-chain transfer-in transaction, and transfer the first asset (such as a bill asset) after the transaction verification is passed.
  • the second cross-chain transfer-in transaction can be a transaction in the first cross-chain transaction request sent by the cross-chain relay, that is, when the cross-chain relay sends the second cross-chain transfer-in transaction to the first consensus node, it is achieved by generating a first cross-chain transaction request for the second cross-chain transfer-in transaction and sending the first cross-chain transaction request to the first consensus node.
  • the first cross-chain transaction request carries the first transaction signature information obtained by the cross-chain relay signing the second cross-chain transfer-in transaction. For example, it can be the first transaction signature information obtained by the cross-chain relay signing the second cross-chain transfer-in transaction through private key information.
  • the first consensus node writes the transaction data of the second cross-chain incoming transaction into the first bill cross-chain bridge contract, and performs transaction verification on the second cross-chain incoming transaction based on the first bill cross-chain bridge contract, which may be to use the second cross-chain incoming transaction obtained from the first cross-chain transaction request as a pending transaction, and write the transaction data of the pending transaction into the first bill cross-chain bridge contract, call the first bill cross-chain bridge contract to obtain the public key information corresponding to the private key information of the cross-chain relay, such as calling the signature verification method in the first bill cross-chain bridge contract to obtain the public key information, which may be to obtain the public key information pre-stored on the bill chain, or to obtain the public key information from the cross-chain relay; perform signature verification on the first transaction signature information according to the public key information, and if the signature verification is successful, use the second cross-chain incoming transaction corresponding to the first transaction signature information as a pending transaction, perform a transaction comparison between the pending transaction and the pending
  • the first transaction signature information is obtained by encrypting the second cross-chain incoming transaction through the private key information of the cross-chain relay, and the first transaction signature information is signed and verified according to the public key information corresponding to the private key information of the cross-chain relay, that is, the first transaction signature information is decrypted by the public key information, and if the decryption is successful, it means that the signature verification is successful.
  • the aforementioned transaction to be verified is the second cross-chain incoming transaction obtained by decrypting the first transaction signature information through the public key information.
  • Step S503 when the first transaction verification result indicates that the transaction verification is successful, the first asset contract is called through the asset contract calling method in the first cross-chain bridge contract to unlock the locked first asset on the bill chain.
  • the first transaction verification result obtained indicates that the transaction verification is successful, that is, the transaction source is correct. If the transaction to be verified is determined to be different from the transaction to be processed based on the transaction comparison, the first transaction verification result obtained indicates that the transaction verification is unsuccessful, that is, the transaction source is incorrect, and a verification failure notification message for the second cross-chain transfer transaction can be returned to the cross-chain relay to enable the cross-chain relay to resend the first cross-chain transaction request.
  • the first asset contract (such as the bill asset contract) can be called through the first bill cross-chain bridge contract to unlock the locked bill assets on the bill chain.
  • the bill assets can be unlocked by directly calling the bill asset contract through the first bill cross-chain bridge contract.
  • the bill chain can also include a bill asset mapping contract, and the asset mapping contract on the bill chain (such as the bill asset mapping contract) can be called through the first bill cross-chain bridge contract, and the bill asset mapping contract calls the bill asset contract to unlock the bill assets.
  • the locked bill asset can be unlocked by calling the bill asset contract to switch the asset state of the bill asset from the second state to the first state.
  • the bill mapping asset on the application contract chain is in the second state.
  • the first state is used for the bill asset to be in a normal state at this time, and the bill asset can be modified and operated on the bill chain. For example, it can be a standard business logic specified for the bill asset.
  • the business execution request sent by the business object for the bill asset can be obtained.
  • the business object is allowed to call the bill business contract to execute the specified business corresponding to the bill asset.
  • the aforementioned business execution request is used to instruct the execution of the specified business on the specified bill asset.
  • the specified business can be, for example, the electronic bill redemption business, the electronic bill archiving business, etc.
  • the bill business processing contract on the bill chain contains at least: the electronic bill used to execute the electronic bill redemption business
  • the electronic bill archiving contract and the electronic bill archiving contract used to execute the electronic bill archiving business are used to instruct the first consensus node to call the electronic bill red-check contract on the bill chain to issue a red-letter invoice corresponding to the electronic invoice, and the red-letter invoice is used to correct the relevant bill information in the electronic invoice.
  • determining whether the business object has the authority to call the bill business contract may be to detect the asset status of the bill asset indicated by the business execution request, and if the asset status is detected to be in a first state, it indicates that the business object has the authority to call the bill business contract. If the asset status is in a second state, it indicates that the business object does not have the authority to call the bill business contract.
  • the first cross-chain transaction request carries the event identifier of the second cross-chain event.
  • the event generation method in the first bill cross-chain bridge contract can be called to obtain the event identifier of the second cross-chain event from the first cross-chain transaction request sent by the cross-chain relay based on the second cross-chain transfer exchange, and generate a cross-chain transaction completion event associated with the event identifier.
  • the cross-chain transaction completion event is used to indicate the successful transfer of the bill asset from the application contract chain back to the bill chain.
  • the business object can determine whether the transfer of the bill mapping asset is completed based on the cross-chain transaction completion event on the bill chain.
  • the business object can generate an event query request for the second cross-chain event through the business node; the event query request carries the event identifier of the second cross-chain event, and the event identifier of the second cross-chain event can be obtained by the business object from the second bill cross-chain bridge contract on the application contract chain; if the first consensus node receives the event query request, it queries the cross-chain transaction completion event associated with the event identifier of the second cross-chain event through the event query method in the first bill cross-chain bridge contract, and returns the event completion notification message for the second cross-chain event to the business object. It can be understood that when the business object receives the event completion notification message, it means that the business object determines that the cross-chain transaction for the bill mapping asset is completed, and can send a business execution request for the corresponding bill asset to the first consensus node.
  • the asset attribute state of the bill asset on the bill chain is the first attribute state
  • the mapped asset attribute state of the bill mapping asset cast on the application contract chain is the same as the asset attribute state of the bill asset.
  • the first consensus node may also perform the following steps: when calling the bill asset contract to unlock the locked bill asset on the bill chain, the asset attribute state of the bill asset is changed from the first attribute state to the second attribute state.
  • the second event parameter of the second cross-chain event can carry the asset attribute status of the bill mapping asset, so the transaction parameter carried by the second cross-chain transfer-in transaction generated based on the second cross-chain event includes the asset attribute status of the bill mapping asset.
  • the first consensus node can determine whether the asset attribute status of the bill mapping asset has changed based on the carried asset attribute status, and then determine whether the bill asset corresponding to the bill mapping asset needs to change its asset attribute status. If a change is required, when the bill asset is unlocked, the asset attribute status of the bill asset is changed to the same mapped asset attribute status as the bill mapping asset.
  • the asset attribute state may refer to the state of the object that characterizes the bill asset, for example, the first attribute state may be the state that the bill asset's object is the current business object.
  • the second attribute state may refer to the state that the bill asset's object is a derived business object.
  • the current business object of the bill asset may be an enterprise object
  • the derived business object may be an individual object under the enterprise object.
  • the bill asset is an invoice asset
  • the business object of the invoice asset is enterprise A.
  • the derivative business performed on the invoice mapping asset on the application contract chain may be an abnormal return business for the invoice asset.
  • the exit process may be performed on the abnormal bill asset, that is, the object to which the abnormal bill asset belongs may be returned from enterprise A to individual object A who issued the bill asset, that is, the mapping asset attribute state of the corresponding bill mapping asset is determined to be changed from the first attribute state to the second attribute state.
  • the first attribute state refers to the state that the bill asset's object is enterprise A
  • the second attribute state refers to the state that the bill asset's object is individual object A.
  • the asset attribute state of the invoice asset on the bill chain should also have a corresponding change, that is, the object to which it belongs is changed.
  • the asset attribute status may refer to the bill status of the bill asset.
  • the first attribute status may refer to the current invoice status of the invoice asset being correct
  • the second attribute status may refer to the invoice status of the invoice asset being in a red-reversal status.
  • the derivative business executed on the invoice mapping asset on the application contract chain may be a red-reversal business executed on the bill asset.
  • the incorrect bill assets need to be red-reversed, that is, the invoice status of the bill asset needs to be changed from the correct status to the red-reversed status, that is, the mapping asset attribute status of the corresponding bill mapping asset needs to be changed from the first attribute status to the second attribute status.
  • the asset attribute status of the invoice asset on the bill chain should also be changed accordingly, that is, the bill status is changed.
  • FIG6 is a schematic diagram of a cross-chain asset transfer scenario provided by an embodiment of the present application; wherein, the cross-chain relay detects and reads the second cross-chain event from the second consensus node, and generates a corresponding second cross-chain transfer-in transaction when the event verification of the first cross-chain event is successful; the first cross-chain transfer-in transaction carries the bill mapping asset WP and transaction parameters; the cross-chain relay generates a first cross-chain transaction request carrying the first transaction signature information and the second cross-chain transfer-in transaction, and sends the first cross-chain transaction request to the first consensus node.
  • the first consensus node receives the first cross-chain transaction request and performs a process of transferring the bill asset back to the bill chain.
  • the first consensus node writes the transaction data of the second cross-chain transfer-in transaction into the first bill cross-chain bridge contract, and performs transaction verification on the second cross-chain transfer-in transaction based on the first transaction signature information, and when the transaction verification is successful, the first bill cross-chain bridge contract calls the bill asset contract to unlock the locked bill asset P.
  • the first consensus node determines whether the mapping asset attribute state of WP has changed according to the transaction parameters carried in the first cross-chain transfer-in transaction; if the mapping asset attribute state of WP has changed, the corresponding asset attribute state of P will change accordingly.
  • the first consensus node can obtain the event identifier of the second cross-chain event from the first cross-chain transaction request, and generate a cross-chain transaction completion event associated with the event identifier, through which the business object can determine that the WP transfer is completed. Subsequently, the business object can send a business execution request to execute a specified business on P on the bill chain.
  • FIG7 is a flowchart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application, which can be executed by a second consensus node in a second chain network (such as an application contract chain network) corresponding to the second chain (such as an application contract chain) mentioned above, for example, the second consensus node can be any consensus node in the consensus network 300a shown in FIG1 above.
  • the method can include the following steps S701-S703.
  • Step S701 obtaining a first cross-chain transfer-in transaction sent by the cross-chain relay for the first asset.
  • the first cross-chain transfer-in transaction is the first cross-chain event corresponding to the first cross-chain transfer-out transaction read by the cross-chain relay from the first consensus node, and is constructed when the event verification of the first cross-chain event is successful.
  • the first cross-chain event is generated when the first consensus node calls the first asset contract (such as the bill asset contract) on the bill chain to lock the first asset (such as the bill asset) based on the first cross-chain bridge contract (such as the first bill cross-chain bridge contract) written with the first cross-chain transfer-out transaction and the business data information to determine that the business object has the cross-chain asset transfer authority.
  • the aforementioned business data information is configured by the management consensus node in the management chain network for the business object.
  • the aforementioned first consensus node is the consensus node in the electronic bill network corresponding to the bill chain.
  • the first consensus node may generate a corresponding first cross-chain event when receiving the first cross-chain asset transfer request sent by the business object for the first cross-chain transfer transaction and determining that the business object has the cross-chain asset transfer authority based on the first bill cross-chain bridge contract and business data information.
  • the specific method of the aforementioned process can be referred to the relevant description of the embodiment shown in FIG3 above.
  • the cross-chain relay can detect the bill event on the first bill cross-chain bridge contract of the bill chain, and when the first cross-chain event is detected, the first cross-chain event is obtained from the first consensus node, and then the first cross-chain transfer-in transaction corresponding to the first cross-chain event can be generated, and the cross-chain relay can send the first cross-chain transfer-in transaction to the second consensus node.
  • the cross-chain relay is used to isolate the electronic bill network and the application contract chain network corresponding to the bill chain, and the electronic bill network is independent of the management chain network and the application contract chain network.
  • Step S702 write the transaction data of the first cross-chain incoming transaction into the second bill cross-chain bridge contract on the application contract chain.
  • the first cross-chain transfer-in transaction can be a transaction in the second cross-chain transaction request sent by the cross-chain relay, that is, when the cross-chain relay sends the first cross-chain transfer-in transaction to the second consensus node, it is achieved by generating a second cross-chain asset transfer-out request for the first cross-chain transfer-in transaction and sending the second cross-chain asset transfer-out request to the second consensus node.
  • the second consensus node can write the transaction data of the first cross-chain transfer-in transaction obtained from the second cross-chain asset transfer-out request into the second bill cross-chain bridge contract.
  • Step S703 calling the second asset contract indicated by the second cross-chain bridge contract, and minting a second asset with the same asset content as the first asset on the second chain.
  • the asset minting process here refers to creating a block on the second chain for storing asset content, and the asset content stored in the block is consistent with the asset content of the first asset, that is, minting the second asset on the second chain can also mean creating the second asset on the second chain.
  • calling the second asset contract (for example, the bill asset mapping contract) to cast the second asset (for example, the bill mapping asset) can be, when calling the second cross-chain bridge contract (for example, the second bill cross-chain bridge contract) to execute the first cross-chain transfer-in transaction, the first cross-chain transfer-in transaction is verified to obtain the second transaction verification result.
  • the bill asset mapping contract indicated by the second bill cross-chain bridge contract is called to cast the bill mapping asset with the same asset content as the bill asset on the application contract chain.
  • the bill asset mapping contract can be called through the asset mapping contract calling method in the second bill cross-chain bridge contract to cast the bill mapping asset.
  • the calling of the second bill cross-chain bridge contract to execute the first cross-chain transfer-in transaction can refer to writing the transaction data of the first cross-chain transfer-in transaction into the second bill cross-chain bridge contract.
  • the second bill cross-chain bridge contract can be used to verify the second cross-chain transfer transaction when writing the first cross-chain transfer transaction, and transfer the bill assets after the transaction verification is passed.
  • the bill asset mapping contract can be used to mint the bill mapping assets corresponding to the bill assets.
  • the minted bill mapping assets are the same as the bill assets and can be operated on the application contract chain.
  • the contracts deployed on the application contract chain (such as the second bill cross-chain bridge contract) have the ability to call contracts (such as bill mapping asset contracts) across chains.
  • the second cross-chain transaction request may carry the second transaction signature information obtained by signing the first cross-chain transfer-in transaction.
  • it may be the second transaction signature information corresponding to the encryption of the first cross-chain transfer-in transaction by the cross-chain relay through the private key information.
  • the process of transaction verification of the first cross-chain transfer-in transaction may be to use the first cross-chain transfer-in transaction obtained from the second cross-chain transaction request as a reference transaction, call the signature verification method in the second bill cross-chain bridge contract to obtain the public key information corresponding to the private key information of the cross-chain relay, for example, it may be to call the signature verification method in the second bill cross-chain bridge contract to obtain the public key information; perform signature verification on the second transaction signature information according to the public key information, and when the signature verification is successful, use the first cross-chain transfer-in transaction corresponding to the second transaction signature information as a transaction to be matched, and compare the reference transaction and the transaction to be matched through the second bill cross-chain bridge contract to obtain the second transaction comparison result, and use the second transaction comparison result as the second transaction verification result. For example, it may be to compare the reference transaction and the transaction to be matched through the transaction comparison method in the second bill cross-chain bridge contract.
  • the signature verification of the second transaction signature information is performed according to the public key information, that is, the second transaction signature information is decrypted by the public key information. If the decryption is successful, it means that the signature verification is successful.
  • the above-mentioned transaction to be matched is the second cross-chain transfer transaction obtained by decrypting the second transaction signature information by the public key information.
  • the obtained second transaction verification result indicates that the transaction verification is successful, that is, the transaction source is correct. If the reference transaction and the transaction to be matched are different based on the transaction comparison, the obtained second transaction verification result indicates that the transaction verification is unsuccessful, that is, the transaction source is incorrect, and a verification failure notification message for the first cross-chain transfer transaction can be returned to the cross-chain relay to enable the cross-chain relay to resend the second cross-chain transaction request.
  • the bill asset mapping contract can be called through the second bill cross-chain bridge contract to cast the bill mapping asset corresponding to the bill asset.
  • the state of the bill mapping asset is configured based on the first cross-chain transfer transaction.
  • the asset state of the bill mapping asset is configured to the first state, indicating that the bill mapping asset is currently in a normal state.
  • the same mapping asset attribute state can be configured for the bill mapping asset according to the asset attribute state carried by the first cross-chain transfer transaction.
  • derivative business logic such as credit identification, red rush, etc., can be executed on the casted bill mapping asset on the application contract chain.
  • the second cross-chain transaction request carries the event identifier of the first cross-chain event.
  • the second consensus node can call the event generation method in the second bill cross-chain bridge contract, obtain the event identifier of the first cross-chain event from the second cross-chain transaction request sent by the cross-chain relay based on the first cross-chain transfer exchange, and generate a cross-chain transaction completion event associated with the event identifier when the bill mapping asset casting is completed.
  • the cross-chain transaction completion event is used to represent the successful transfer of the bill asset from the bill chain to the application contract chain.
  • the business object can determine whether the transfer of the bill assets is completed based on the cross-chain transaction completion event.
  • the event query request sent by the business object through the business node for the first cross-chain event is obtained.
  • the event query request carries the event identifier of the first cross-chain event, which can be obtained by the business object from the first bill cross-chain bridge contract on the application contract chain; if the cross-chain transaction completion event associated with the event identifier is queried through the event query method in the second bill cross-chain bridge contract, the event completion notification message for the first cross-chain event is returned to the business object. Therefore, when the business object receives the event completion notification message, it indicates that the cross-chain transaction for the bill asset has been detected to be completed, and a business execution request for the bill mapping asset can be sent to the second consensus node later.
  • the first cross-chain transfer transaction generated by the cross-chain relay carries the permission parameters determined based on the asset usage permission of the corresponding bill asset.
  • the permission parameters are used to restrict the corresponding asset usage permission for the bill-mapped asset, that is, to specify the same asset usage permission for the bill-mapped asset based on the permission parameters.
  • the bill-mapped asset on the application contract chain can only execute the asset usage indicated by the permission parameters. For example, if the derivative business to be executed based on the permission parameters is to change the object to which the bill-mapped asset belongs, then only the derivative business can be executed on the bill-mapped asset on the application contract chain.
  • the second consensus node can obtain the derivative business execution request sent by the business object based on the event completion notification message, and based on the derivative business in the derivative business execution request, call the second bill cross-chain bridge contract to obtain the transaction parameters in the first cross-chain transfer-in transaction; when it is determined based on the aforementioned transaction parameters that the business object has the authority to call the derivative business contract on the application contract chain, the business object is allowed to call the derivative business contract to execute the derivative business corresponding to the bill mapping asset.
  • determining whether the business object has the authority to call the derivative business contract on the application contract chain can be by detecting whether the derivative business indicated by the derivative business execution request is the derivative business indicated by the authority parameter. If the derivative business indicated by the derivative business execution request is the derivative business indicated by the authority parameter, it means that it has the authority to call the derivative business contract.
  • the permission parameter in the transaction parameter may include an asset transfer parameter.
  • the asset transfer parameter is used to indicate that the bill mapping asset is transferred from the business object to the derivative business object corresponding to the derivative business associated with the business object. If it is determined that the business object has the authority to call the derivative business contract on the application contract chain, the derivative business contract can be called to execute the derivative business corresponding to the bill mapping asset; when executing the derivative business, if it is determined based on the asset transfer parameter that the bill mapping asset is transferred from the business object to the derivative business object, the mapping asset attribute state of the bill mapping asset is changed from the first attribute state to the second attribute state on the application contract chain.
  • the mapping asset attribute state may refer to the state of the object to which the bill mapping asset belongs.
  • the first attribute state may be a state that represents that the object to which the bill asset belongs is the current business object
  • the second attribute state may be a state that represents that the object to which the bill asset belongs is a derivative business object.
  • derivative business can be performed on the bill mapping asset, and whether to transfer the bill asset from the business object to the derivative business object can be determined based on the asset transfer parameter, that is, the asset transfer parameter indicates the business change for the object to which the bill mapping asset belongs.
  • the mapping asset attribute state of the bill mapping asset is changed.
  • the above-mentioned second attribute state is determined based on the derivative business object indicated by the asset transfer parameter.
  • the bill asset is an invoice asset
  • the derivative business is an abnormal return business for the invoice asset.
  • the asset transfer parameter is used to indicate the derivative business and to indicate that the derivative business can be used to change the business object to which the bill mapping asset belongs to to the derivative business object corresponding to the derivative business, such as indicating a change from an enterprise object to an individual object.
  • the permission parameters in the transaction parameters may include a bill status transfer parameter.
  • the bill status transfer parameter is used to indicate that the bill status of the bill-mapped asset is changed from an error-free state to a red-check state corresponding to a derivative business (such as a red-check business). If it is determined that the business object has the authority to call the derivative business contract on the application contract chain, the derivative business contract can be called to execute the derivative business corresponding to the bill-mapped asset; when executing the derivative business, if it is determined based on the bill status transfer parameter that the bill status of the bill-mapped asset is changed to a red-check state, the mapped asset attribute state of the bill-mapped asset is changed from a first attribute state to a second attribute state on the application contract chain.
  • the mapped asset attribute state may refer to the bill status of the bill-mapped asset
  • the first attribute state may refer to the bill asset being in an error-free state
  • the second attribute state may refer to the bill asset being in a red-check state.
  • derivative business can be performed on the bill mapping asset, and whether to change the bill status of the bill asset can be determined based on the bill status transfer parameter, and when it is determined that the bill status needs to be changed, the mapping asset attribute of the bill mapping asset can be changed.
  • the second attribute state is determined based on the red-check state indicated by the asset transfer parameter.
  • the bill asset is an invoice asset
  • the derivative business is a red-check business for the invoice asset.
  • the bill state transfer parameter is used to indicate the derivative business and to indicate that the derivative business can be used to change the bill state of the bill mapping asset to the corresponding red-check state.
  • Figure 8 is a schematic diagram of a cross-chain asset transfer scenario provided by an embodiment of the present application; wherein, the cross-chain relay detects and reads the first cross-chain event from the first consensus node, and generates a corresponding first cross-chain transfer-in transaction when the event verification of the first cross-chain event is successful; the first cross-chain transfer-in transaction carries the bill asset P and transaction parameters; the cross-chain relay generates a second cross-chain transaction request carrying the second transaction signature information and the first cross-chain transfer-in transaction, and sends the second cross-chain transaction request to the second consensus node; the second consensus node writes the transaction data of the first cross-chain transfer-in transaction into the second bill cross-chain bridge contract, and performs transaction verification on the first cross-chain transfer-in transaction based on the second transaction signature information; when the transaction verification is successful, the bill asset mapping contract is called through the second bill cross-chain bridge contract to cast the same bill mapping asset WP as P on the application contract chain for P, and obtain the transaction parameters in the first cross-chain
  • the derivative business indicated by the derivative business execution request is a red-check business
  • the bill asset needs to be transferred back to the bill chain from the application contract chain.
  • the following is an explanation of the process of the second consensus node transferring the asset back.
  • FIG9 is a flowchart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application.
  • the method can be executed by a second consensus node in a second chain network (such as an application contract chain network) corresponding to the second chain (such as an application contract chain) mentioned above.
  • the second consensus node can be any consensus node in the consensus network 300a shown in FIG1 above.
  • the method can include the following steps S901-S903.
  • Step S901 obtaining a second cross-chain asset transfer request sent by the business object for the second cross-chain transfer transaction.
  • the second cross-chain asset transfer request carries business data information.
  • the business data information is used to verify the cross-chain asset transfer back authority of the business object to ensure the legality of the transfer of the second asset of the business object (such as the bill mapping asset).
  • the above-mentioned second cross-chain asset transfer request is used to instruct the second consensus node to transfer the bill mapping asset from the application contract chain back to the bill chain through the cross-chain relay. It can be understood that when the business object needs to perform derivative business on the bill mapping asset, a second cross-chain asset transfer request can be generated to transfer the specified bill mapping asset from the application contract chain to the bill chain.
  • the business object when the business object generates the second cross-chain asset transfer request through the business node, it can obtain business data information from the management chain, and generate the second cross-chain asset transfer request for the second cross-chain transfer transaction based on the obtained business data information.
  • the business object may store the business data information locally in advance through the business node, and when generating the second cross-chain asset transfer request, it can obtain the business data information from the local to generate the second cross-chain asset transfer request.
  • Step S902 write the transaction data of the second cross-chain transfer transaction carried in the second cross-chain asset transfer request into the second cross-chain bridge contract on the application contract chain.
  • Step S903 When it is determined based on the second cross-chain bridge contract and the business data information that the business object has the cross-chain asset transfer back authority, the second asset contract is called to lock the second asset, and a second cross-chain event corresponding to the second cross-chain transfer out transaction is generated.
  • the second bill cross-chain bridge contract can be used to verify the cross-chain asset transfer back authority of the business object for the second cross-chain asset transfer request. After the authority verification is successful, it is determined that the business object has the cross-chain asset transfer back authority, and the transfer back process of the bill mapping asset continues to be executed.
  • the cross-chain asset transfer back authority is determined by the target consensus node in the target chain network, or by the target consensus node and the second consensus node. In some embodiments, the cross-chain resource transfer back authority is determined based on the source configuration data information and business data information (carried in the second cross-chain asset transfer request) obtained by querying the target consensus node.
  • the permission verification of the cross-chain asset transfer back permission based on the second cross-chain bridge contract can be to call the cross-chain permission query method in the second bill cross-chain bridge contract to generate a transfer back permission verification request;
  • the transfer back permission verification request is used to instruct the management consensus node to call the cross-chain permission management contract on the management chain to query the source configuration data information of the business object, for example, it can be to call the cross-chain permission query method in the cross-chain permission management contract to query whether the business object has the source configuration data information; receive the source configuration data information returned by the management consensus node based on the transfer-out permission verification request, compare the source configuration data information with the business data information carried in the second cross-chain asset transfer-out request, obtain the information comparison result, and determine whether the business object has the cross-chain asset transfer back permission according to the information comparison result.
  • the business data information and the source configuration data information can be compared by the information comparison method in the second bill cross-chain bridge contract.
  • the authority verification is performed based on the second bill cross-chain bridge contract to determine whether the business object has the cross-chain asset transfer authority. It can be that the second bill cross-chain bridge contract is called to generate a transfer back authority verification request carrying business data information.
  • the transfer back authority verification request is used to instruct the management consensus node to call the cross-chain authorization management contract on the management chain to query the source configuration data information of the business object, and compare the source configuration data information with the business data information in the transfer back authority verification request to obtain the information comparison result.
  • the management consensus node calls the information comparison method in the cross-chain authority management contract to compare the business data information with the source configuration data information;
  • the second consensus node can receive the information comparison result returned by the management consensus node based on the transfer back authority verification request, and determine whether the business object has the cross-chain asset transfer back authority based on the information comparison result.
  • determining whether a business object has the authority to transfer back cross-chain assets can be that if the information comparison result indicates that the comparison is successful, that is, the business data information is the same as the source configuration data information, then it is determined that the business object has the authority to transfer back cross-chain assets; that is, it is determined that the transfer of the bill-mapped assets is legal at this time; if the information comparison result indicates that the comparison is unsuccessful, that is, the business data information is different from the source configuration data information, then it is determined that the business object does not have the authority to transfer back cross-chain assets.
  • the specific method of locking the bill mapping assets can be to call the bill asset mapping contract to switch the asset state of the bill mapping assets from the first state to the second state.
  • the bill asset mapping contract is used to manage the asset state of the bill assets on the chain. For example, the transferred bill mapping assets can be locked.
  • calling the second asset contract (such as the bill asset mapping contract) to switch the asset state can be through the asset contract calling method in the second bill cross-chain bridge contract, calling the bill asset mapping contract to switch the asset state of the bill mapping asset on the application contract chain.
  • the first state can refer to the normal state, indicating that the bill mapping asset is not locked; the second state can refer to the locked state, indicating that the bill mapping asset has been locked. At this time, the locked bill mapping asset on the application contract chain cannot be operated or modified.
  • the second consensus node when it detects that the asset state of the bill mapping asset is in the second state, it can call and generate the second cross-chain event corresponding to the second cross-chain transfer transaction, which means that the second cross-chain transfer transaction is completed on the second consensus node.
  • the event generation method in the second bill cross-chain bridge contract can be called to generate the second cross-chain event.
  • the second cross-chain event can carry information such as the bill mapping asset and the current asset attribute status of the bill mapping asset.
  • the second cross-chain event is used to instruct the cross-chain relay to send the second cross-chain transfer-in transaction to the first consensus node when constructing the second cross-chain transfer-in transaction corresponding to the second cross-chain transfer-out transaction.
  • the second cross-chain transfer-in transaction is used to instruct the first consensus node to transfer the bill mapping assets to the bill chain, that is, the first consensus node can be used to call the bill asset contract indicated by the first bill cross-chain bridge contract when writing the transaction data of the second cross-chain transfer-in transaction to the first bill cross-chain bridge contract on the bill chain, and unlock the locked bill assets on the bill chain. That is, the asset state of the bill asset is changed from the second state to the first state.
  • the second cross-chain transfer-in transaction and the second cross-chain transfer-out transaction are used to indicate the transfer of the bill mapping assets from the application contract chain to the bill chain.
  • the execution process of the second cross-chain transfer-in transaction by the first consensus node can be seen in the above figure. 5 is a description of the embodiment shown in FIG.
  • the cross-chain relay can detect the bill event generated by the second bill cross-chain bridge contract of the application contract chain, and when the second cross-chain event is detected, obtain the second cross-chain event from the application contract chain of the second consensus node; when the event verification of the second cross-chain event is successful, a second cross-chain transfer-in transaction is generated based on the bill mapping assets, asset attribute status and other information in the second cross-chain event to realize the transfer of the bill mapping assets.
  • the second consensus node can call the bill asset mapping contract to destroy the locked bill mapping assets when detecting the generation of the second cross-chain event.
  • the cross-chain relay can send a cross-chain completion notification message to the second consensus node when detecting the cross-chain transaction completion event associated with the second cross-chain event on the first bill cross-chain bridge contract of the first consensus node.
  • the second consensus node receives the cross-chain completion notification message, it calls the bill asset mapping contract to destroy the locked bill mapping assets.
  • the locked bill mapping assets are destroyed by calling the asset mapping contract method in the second bill cross-chain bridge contract.
  • Figure 10 is a schematic diagram of a cross-chain asset transfer scenario provided by an embodiment of the present application; wherein, business object A sends a second cross-chain asset transfer request for a second cross-chain transfer transaction to the second consensus node, and the second cross-chain asset transfer request carries business data information X; the second consensus node verifies the cross-chain asset transfer-in authority of the business object based on the second bill cross-chain bridge contract and X, which can be specifically generated through the second bill cross-chain bridge contract.
  • the transfer back authority verification request is sent to the management consensus node, and the management consensus node queries the source configuration data information X' stored by the business object A based on the transfer back authority verification request and the cross-chain authority management contract; the second consensus node compares X and X' to determine that the business object has the cross-chain asset transfer back authority; the second consensus node calls the bill asset mapping through the second bill cross-chain bridge contract
  • the contract locks the bill mapping asset WP and generates a corresponding second cross-chain event;
  • the cross-chain relay can detect and read the second cross-chain event, and generate a corresponding second cross-chain transfer-in transaction, which carries WP and transaction parameters (such as mapping asset attribute status, etc.); the cross-chain relay sends the first cross-chain transaction request carrying the second cross-chain transfer-in transaction to the first consensus node, and the first consensus node performs the WP transfer process based on the second cross-chain transfer-in transaction and the first bill cross-chain bridge contract and bill asset contract on the bill chain; subsequently
  • FIG11 is a flowchart of a multi-blockchain-based asset transfer method provided in an embodiment of the present application.
  • the method can be executed by the first consensus node in the first chain network, the second consensus node in the second chain network, and the cross-chain relay.
  • the first consensus node here can be any consensus node in the consensus network 200a shown in FIG1 above
  • the second consensus node can be any consensus node in the consensus network 300a shown in FIG1 above.
  • the first chain network, the second chain network, and the target chain network are independent of each other, and the cross-chain relay is used to isolate the first chain network and the second chain network; at this time, the method can include the following steps S1101-step S1107.
  • Step S1101 The first consensus node obtains a first cross-chain asset transfer request sent by a business object for a first cross-chain transfer transaction.
  • the business object can apply to the management consensus node in the management chain network in advance for business data information for permission verification, such as the management consensus node calling the cross-chain permission management contract on the management chain to configure a dedicated authorization code for the business object as business data information.
  • the first cross-chain asset transfer request carrying business data information can be made. The first cross-chain asset transfer request is used to instruct the transfer of the bill assets of the business object from the bill chain to the application contract chain.
  • Step S1102 The first consensus node writes the transaction data of the first cross-chain transfer transaction carried in the first cross-chain asset transfer request into the first cross-chain bridge contract on the first chain.
  • Step S1103 When the first consensus node determines that the business object has the cross-chain asset transfer authority based on the first cross-chain bridge contract and the business data information, it calls the first asset contract on the first chain to lock the first asset and generates a first cross-chain event corresponding to the first cross-chain transfer transaction.
  • the first consensus node can determine whether the business object has the cross-chain asset transfer authority based on the first cross-chain bridge contract (such as the first bill cross-chain bridge contract) and business data information when writing the first cross-chain transfer transaction. For example, it can be to call the first bill cross-chain bridge contract to generate a transfer authority verification request for the business object, and send the transfer authority verification request to the management consensus node, and the management consensus node calls the cross-chain authorization management contract on the management chain to query the source configuration of the business object.
  • the first consensus node receives the source configuration data information returned by the management consensus node, and compares the source configuration data information with the business data information in the first asset transfer request. If the information comparison result indicates that the comparison is successful, it is determined that the business object has the cross-chain asset transfer authority.
  • the first asset contract (such as a bill asset contract) on the bill chain can be called through the first bill cross-chain bridge contract to lock the first asset (such as a bill asset), and the first bill cross-chain bridge contract can be called to generate a first cross-chain event corresponding to the first cross-chain transfer transaction.
  • the event parameters carried by the first cross-chain event may include information such as the locked bill asset, asset attribute status, and permission parameters determined based on the specified asset usage permission.
  • Step S1104 The cross-chain relay obtains the first cross-chain event.
  • Step S1105 The cross-chain relay constructs a first cross-chain incoming transaction corresponding to the first cross-chain outgoing transaction based on the first cross-chain event.
  • the cross-chain relay can detect and obtain the first cross-chain event on the first bill cross-chain bridge contract on the first consensus node, and construct the first cross-chain transfer-in transaction based on the information carried in the first cross-chain event.
  • the first cross-chain transfer-in transaction carries the locked bill assets and transaction parameters.
  • the transaction parameters may include information such as asset attribute status and permission parameters.
  • Step S1106 The cross-chain relay sends the first cross-chain incoming transaction to the second consensus node.
  • the cross-chain relay can generate a second cross-chain transaction request carrying the first cross-chain transfer-in transaction, and send the second cross-chain transaction request to the second consensus node to send the first cross-chain transfer-in transaction to the second consensus node.
  • the second cross-chain transaction request can carry the second transaction signature information obtained by the cross-chain relay signing the first cross-chain transfer-in transaction through the private key information.
  • Step S1107 when the second consensus node writes the transaction data of the first cross-chain incoming transaction into the second cross-chain bridge contract on the second chain, it calls the second asset contract indicated by the second cross-chain bridge contract to mint a second asset with the same asset content as the first asset on the second chain.
  • the second consensus node when the second consensus node obtains the first cross-chain transfer-in transaction from the second cross-chain transaction request and writes the second cross-chain bridge contract (such as the second bill cross-chain bridge contract) on the application contract chain, it can verify the first cross-chain transfer-in transaction based on the second transaction signature information, and when the transaction verification is successful, call the second asset contract (such as the bill asset mapping contract) to cast the second asset (such as the bill mapping asset).
  • the corresponding asset mapping status, mapped asset attribute status, and asset usage authority can be set for the bill mapping asset based on the transaction parameters in the first cross-chain transfer-in transaction.
  • the specific method of conducting transaction verification can refer to the relevant description of the above embodiment.
  • Figure 12 is a flow chart of an asset transfer method based on multiple blockchains provided in an embodiment of the present application;
  • Figure 12 can represent the execution process of transferring the second asset from the second chain back to the first chain.
  • the process can be: S1.
  • the second consensus node obtains the second cross-chain asset transfer request sent by the business object for the second cross-chain transfer transaction; the second cross-chain asset transfer request carries business data information; S2.
  • the second consensus node writes the transaction data of the second cross-chain transfer transaction carried in the second cross-chain asset transfer request into the second cross-chain bridge contract on the second chain; S3.
  • the second consensus node determines that the business object has the cross-chain asset transfer back authority based on the second cross-chain bridge contract and the business data information, it calls the second asset contract on the second chain to lock the second asset, and generates a second cross-chain event corresponding to the second cross-chain transfer transaction; the second consensus node determines the cross
  • the specific principle of the cross-chain asset transfer back authority can be the same as the principle of the first consensus node determining the cross-chain asset transfer out authority of the business object; S4, the cross-chain relay obtains the second cross-chain event; S5, the cross-chain relay constructs a second cross-chain transfer-in transaction corresponding to the second cross-chain transfer-out transaction based on the second cross-chain event; the second cross-chain transfer-in transaction can carry the locked second asset and transaction parameters, and the transaction parameters can include information such as asset attribute status; S6, the cross-chain relay sends the second cross-chain transfer-in transaction to the first consensus node; for example, the cross-chain relay generates a first cross-chain
  • the first consensus node When the first consensus node writes the transaction data of the second cross-chain incoming transaction into the first cross-chain bridge contract on the first chain, it calls the first asset contract indicated by the first cross-chain bridge contract to unlock the locked first asset on the first chain; the first consensus node can verify the second cross-chain incoming transaction based on the first transaction signature information, and unlock the locked first asset when the transaction verification is successful; in addition, it can further determine whether the mapped asset attribute state of the second asset needs to be changed based on the transaction parameters in the second cross-chain incoming transaction, such as determining that the second asset has changed based on the mapped asset attribute state in the transaction parameters, and then make corresponding changes to the asset attribute state of the unlocked first asset.
  • the first cross-chain transaction request also carries the event identifier of the second cross-chain event.
  • the first cross-chain bridge contract can be called to generate a cross-chain transaction completion event associated with the event identifier to indicate that the second asset has been successfully transferred from the second chain to the first chain.
  • the second consensus node can destroy the locked second asset when receiving the cross-chain completion notification message generated by the cross-chain relay based on the cross-chain transaction completion event.
  • the business object can determine whether the transfer of the second asset is completed through the cross-chain transaction completion event, and after determining that the transfer is completed, send a business execution request for the first asset to the first consensus node to execute the specified business on the first asset on the first chain.
  • the electronic bill blockchain system is improved into three consensus networks, which respectively maintain the management chain, bill chain and application contract chain.
  • the three chains have different functional characteristics, and they are combined to form a blockchain system with simpler management of on-chain data, clearer and more efficient processes, and better business scalability.
  • the cross-chain asset protocol on the chain proposed in the technical solution of this application can make the bill assets better transferred and used between the three chains, and create more business value.
  • the bill asset cross-chain protocol locks the transferred bill assets (or bill mapping assets) to achieve the consistency of bill assets when they are transferred between chains, and ensures the correctness of the data content and data status of the on-chain data under the multi-chain architecture.
  • the derivative business when the derivative business is executed on the bill assets through the derivative business contract on the application contract chain, the business stability on the bill chain is not affected, and the on-chain data on the bill chain that is not related to the derivative business cannot be accessed when the derivative business is executed, thereby achieving good data isolation and business security.
  • FIG 13 is a schematic diagram of the structure of an asset transfer device based on multiple blockchains provided in an embodiment of the present application.
  • the asset transfer device 1 based on multiple blockchains can be applied to the first consensus node, and the first consensus node can be any blockchain node in the first chain network (for example, the above-mentioned consensus network 300a).
  • the first consensus node can be the consensus node 11c in the embodiment corresponding to Figure 1 above.
  • the asset transfer device 1 based on multiple blockchains can be a computer program (including program code) running in a blockchain node (for example, the aforementioned consensus node 10c).
  • the asset transfer device 1 based on multiple blockchains can be an application software; it can be understood that the asset transfer device 1 based on multiple blockchains can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the asset transfer device 1 based on multiple blockchains can include: an acquisition module 11, a writing module 12 and a calling module 13;
  • An acquisition module 11 is used to acquire a first cross-chain asset transfer request sent by a business object for a first cross-chain transfer transaction;
  • the first cross-chain asset transfer request carries business data information configured for the business object, and the business data information is configured by a target consensus node in a target chain network;
  • the first cross-chain asset transfer request is used to instruct the first consensus node to transfer a first asset belonging to the business object from the first chain to a second chain associated with a second consensus node through a cross-chain relay;
  • the second consensus node is a consensus node in a second chain network corresponding to the second chain;
  • the cross-chain relay is used to isolate the second chain network from the first chain network, and the second chain network is independent of the target chain network and the first chain network;
  • a writing module 12 used to write the transaction data of the first cross-chain transfer-out transaction into the first cross-chain bridge contract on the first chain;
  • the calling module 13 is used to call the first asset contract on the first chain to lock the first asset and generate a first cross-chain event corresponding to the first cross-chain transfer-out transaction when determining that the business object has the cross-chain asset transfer-out permission based on the first cross-chain bridge contract and the business data information;
  • the first cross-chain event is used to instruct the cross-chain relay to send the first cross-chain transfer-in transaction to the second consensus node when constructing the first cross-chain transfer-in transaction corresponding to the first cross-chain transfer-out transaction;
  • the second consensus node is used to call the second asset contract indicated by the second cross-chain bridge contract when writing the transaction data of the first cross-chain transfer-in transaction to the second cross-chain bridge contract on the second chain, and cast a second asset with the same asset content as the first asset on the second chain.
  • the calling module 13 includes:
  • the transfer-out authority verification unit 131 is used to call the cross-chain authority query method in the first cross-chain bridge contract to generate a transfer-out authority. Limited verification request; the transfer-out permission verification request is used to instruct the management consensus node to call the cross-chain authorization management contract on the target chain to query the source configuration data information of the business object;
  • the information receiving unit 132 is used to receive the source configuration data information returned by the management consensus node, compare the source configuration data information with the business data information, and obtain an information comparison result;
  • the information comparison unit 133 is used to determine that the business object has the cross-chain asset transfer authority if the information comparison result indicates that the comparison is successful;
  • the cross-chain event generating unit 134 is used to call the first asset contract to switch the asset state of the first asset from the first state to the second state, and generate a first cross-chain event corresponding to the first cross-chain transfer transaction when the asset state of the first asset is the second state.
  • the acquisition module 11 includes:
  • the receiving unit 111 is used to receive a second cross-chain transfer-in transaction sent by the cross-chain relay for the second asset; the second cross-chain transfer-in transaction is constructed when the cross-chain relay reads the second cross-chain event corresponding to the second cross-chain transfer-out transaction from the second consensus node, and the second cross-chain event is generated by the second consensus node obtaining the second cross-chain transfer-out transaction submitted by the business object for the second asset;
  • the writing module 12 is further used to write the transaction data of the second cross-chain incoming transaction into the first cross-chain bridge contract, and perform transaction verification on the second cross-chain incoming transaction based on the first cross-chain bridge contract to obtain a first transaction verification result;
  • the calling module 13 is also used to call the first asset contract to unlock the locked first asset on the first chain through the asset contract calling method in the first cross-chain bridge contract when the first transaction verification result indicates that the transaction verification is successful.
  • the second cross-chain incoming transaction is the transaction in the first cross-chain transaction request sent by the cross-chain relay;
  • the first cross-chain transaction request carries the first transaction signature information obtained by the cross-chain relay signing the second cross-chain incoming transaction through the private key information;
  • the writing module 12 includes:
  • the transaction data writing unit 121 is used to take the second cross-chain incoming transaction obtained from the first cross-chain transaction request as a pending transaction, and write the transaction data of the pending transaction into the first cross-chain bridge contract;
  • the signature verification unit 122 is used to call the signature verification method in the first cross-chain bridge contract to obtain the public key information corresponding to the private key information of the cross-chain relay, and perform signature verification on the first transaction signature information according to the public key information; if the signature verification is successful, the second cross-chain incoming transaction corresponding to the first transaction signature information is used as a transaction to be verified;
  • the transaction comparison unit 123 is used to compare the transaction to be processed and the transaction to be verified by using the transaction comparison method in the first cross-chain bridge contract, obtain a first transaction comparison result, and use the first transaction comparison result as the first transaction verification result.
  • the asset attribute state of the first asset is the first attribute state; when the mapped asset attribute state of the second asset is changed from the first attribute state to the second attribute state, the calling module 13 includes:
  • the attribute state changing unit 135 is used to change the asset attribute state of the first asset from the first attribute state to the second attribute state when the first asset contract is called to unlock the locked first asset on the first chain.
  • the writing module 12 is also used to specify the asset usage authority of the first asset corresponding to the first cross-chain transfer-out exchange when writing the transaction data of the first cross-chain transfer-out transaction into the first cross-chain bridge contract.
  • FIG 14 is a schematic diagram of the structure of an asset transfer device based on multiple blockchains provided in an embodiment of the present application.
  • the asset transfer device 2 based on multiple blockchains can be applied to the second consensus node, and the second consensus node can be any blockchain node in the second chain network (for example, the above-mentioned consensus network 300a).
  • the second consensus node can be the consensus node 12c in the embodiment corresponding to Figure 1 above.
  • the asset transfer device 2 based on multiple blockchains can be a computer program (including program code) running in a blockchain node (for example, the aforementioned consensus node 12c).
  • the asset transfer device 2 based on multiple blockchains can be an application software; it can be understood that the asset transfer device 2 based on multiple blockchains can be used to execute the corresponding steps in the method provided in an embodiment of the present application.
  • the asset transfer device 2 based on multiple blockchains may include: a processing module 21, an asset casting module 22;
  • Processing module 21 is used to obtain a first cross-chain transfer-in transaction sent by a cross-chain relay for a first asset; the first cross-chain transfer-in transaction is constructed when the cross-chain relay reads a first cross-chain event corresponding to a first cross-chain transfer-out transaction from a first consensus node; the first cross-chain event is generated when the first consensus node calls the first asset contract on the first chain to lock the first asset when it determines that the business object has the cross-chain asset transfer-out authority based on the first cross-chain bridge contract and business data information written with the first cross-chain transfer-out transaction; the business data information is configured for the business object by the management consensus node in the target chain network; the first consensus node is a consensus node in the first chain network corresponding to the first chain; the cross-chain relay is used to isolate the first chain network and the second chain network, and the first chain network is independent of the target chain network and the second chain network;
  • the processing module 21 is further used to write the transaction data of the first cross-chain incoming transaction into the second cross-chain bridge contract on the second chain;
  • the asset casting module 22 is used to call the second asset contract indicated by the second cross-chain bridge contract to cast a second asset having the same asset content as the first asset on the second chain.
  • the asset casting module 22 includes:
  • the transaction verification unit 221 is used to verify the first cross-chain incoming transaction when calling the second cross-chain bridge contract to execute the first cross-chain incoming transaction, and obtain a second transaction verification result;
  • the asset casting unit 222 is used to call the second asset contract indicated by the second cross-chain bridge contract to cast a second asset with the same asset content as the first asset on the second chain when the second transaction verification result indicates that the transaction verification is successful.
  • the first cross-chain incoming transaction is a transaction in a second cross-chain transaction request sent by the cross-chain relay;
  • the second cross-chain transaction request carries second transaction signature information obtained by the cross-chain relay signing the first cross-chain incoming transaction through private key information;
  • the transaction verification unit 221 includes:
  • the transaction acquisition subunit 2211 is used to use the first cross-chain incoming transaction obtained from the second cross-chain transaction request as a reference transaction;
  • the signature verification subunit 2212 is used to call the signature verification method in the second cross-chain bridge contract to obtain the public key information corresponding to the private key information of the cross-chain relay, and perform signature verification on the second transaction signature information according to the public key information; if the signature verification is successful, the first cross-chain incoming transaction corresponding to the second transaction signature information is used as a transaction to be matched;
  • the transaction comparison subunit 2213 is used to compare the reference transaction and the transaction to be matched by using the transaction comparison method in the second cross-chain bridge contract to obtain a second transaction comparison result, and use the second transaction comparison result as the second transaction verification result.
  • the asset casting module 22 is also used to call the event generation method in the second cross-chain bridge contract when casting a second asset with the same asset content as the first asset on the second chain, obtain the event identifier of the first cross-chain event from the second cross-chain transaction request sent by the cross-chain relay based on the first cross-chain transfer exchange, and generate a cross-chain transaction completion event associated with the event identifier; the cross-chain transaction completion event is used to characterize the successful transfer of the first asset from the first chain to the second chain.
  • the asset casting module 22 includes:
  • the query request acquisition unit 223 is used to acquire the event query request sent by the business object for the first cross-chain event; the event query request carries the event identifier of the first cross-chain event;
  • the completion event query unit 224 is used to return an event completion notification message for the first cross-chain event to the business object if a cross-chain transaction completion event associated with the event identifier is queried through the event query method in the second cross-chain bridge contract.
  • the asset casting module 22 includes:
  • An execution request acquisition unit 225 used to acquire a derivative business execution request sent by the business object based on the event completion notification message;
  • the transaction parameter acquisition unit 226 is used to call the second cross-chain bridge contract to acquire the transaction parameters in the first cross-chain incoming transaction based on the derivative business in the derivative business execution request; the transaction parameters are determined by the asset use authority of the first asset corresponding to the first cross-chain incoming exchange;
  • the contract calling unit 227 is used to allow the business object to call the derivative business contract to execute the derivative business corresponding to the second asset when it is determined based on the transaction parameters that the business object has the authority to call the derivative business contract on the second chain.
  • the transaction parameters include asset transfer parameters; the asset transfer parameters are used to indicate that the second asset is transferred from the business object to the derivative business object corresponding to the derivative business associated with the business object; the contract calling unit is also used to call the derivative business object.
  • the service contract executes the derivative business corresponding to the second asset, if it is determined based on the asset transfer parameter that the second asset is transferred from the business object to the derivative business object, the mapped asset attribute state of the second asset is changed from the first attribute state to the second attribute state on the second chain.
  • processing module 21 includes:
  • the transfer request acquisition unit 211 is used to acquire the second cross-chain asset transfer request sent by the business object for the second cross-chain transfer transaction; the second cross-chain asset transfer request carries business data information; the second cross-chain asset transfer request is used to instruct the second consensus node to transfer the second asset from the second chain back to the first chain through the cross-chain relay;
  • the transaction data writing unit 212 is used to write the transaction data of the second cross-chain transfer transaction carried in the second cross-chain asset transfer request into the second cross-chain bridge contract on the second chain;
  • the cross-chain event generating unit 213 is used to call the second asset contract to lock the second asset when it is determined based on the second cross-chain bridge contract and the business data information that the business object has the cross-chain asset transfer back authority, and generate a second cross-chain event corresponding to the second cross-chain transfer-out transaction;
  • the second cross-chain event is used to instruct the cross-chain relay to send the second cross-chain transfer-in transaction to the first consensus node when constructing the second cross-chain transfer-in transaction corresponding to the second cross-chain transfer-out transaction;
  • the first consensus node is used to call the first asset contract indicated by the first cross-chain bridge contract when writing the transaction data of the second cross-chain transfer-in transaction to the first cross-chain bridge contract on the first chain, and unlock the locked first asset on the first chain.
  • the cross-chain event generation unit 213 includes:
  • the verification request generation subunit 2131 is used to call the cross-chain permission query method in the second cross-chain bridge contract to generate a return permission verification request; the return permission verification request is used to instruct the management consensus node to call the cross-chain authorization management contract on the target chain to query the source configuration data information of the business object;
  • the receiving subunit 2132 is used to receive the source configuration data information returned by the management consensus node based on the transfer back authority verification request, compare the source configuration data information with the business data information, and obtain an information comparison result;
  • the authority determination subunit 2133 is used to determine that the business object has the authority to transfer back cross-chain assets if the information comparison result indicates that the comparison is successful;
  • the event generation subunit 2134 is used to call the second asset contract to switch the asset state of the second asset from the first state to the second state, and generate a second cross-chain event corresponding to the second cross-chain transfer transaction when the asset state of the second asset is the second state.
  • processing module 21 and the asset casting module 22 can be found in the description of the above embodiment, which will not be described in detail here. In addition, the description of the same beneficial effects obtained by using the same method will not be described in detail.
  • FIG15 is a schematic diagram of the structure of a computer device provided by an embodiment of the present application.
  • the computer device 1500 can be a user terminal or a server, which will not be limited here. It is understandable that the computer device can be the first consensus node and the second consensus node mentioned above.
  • the present application takes the computer device as a server as an example.
  • the computer device 1500 may include: a processor 1501, a network interface 1504 and a memory 1505.
  • the computer device 1500 may also include: a user interface 1503, and at least one communication bus 1502.
  • the communication bus 1502 is used to realize the connection and communication between these components.
  • the user interface 1503 may also include a standard wired interface and a wireless interface.
  • the network interface 1504 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1505 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory.
  • the memory 1505 may also be at least one storage device located away from the aforementioned processor 1501. As shown in FIG. 12 , the memory 1505 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
  • the network interface 1504 in the computer device 1500 can also provide a network communication function.
  • the network interface 1504 can provide a network communication function;
  • the user interface 1503 is mainly used to provide an input interface for the user;
  • the processor 1501 can be used to call the device control application stored in the memory 1505 to execute the description of the asset transfer method based on multiple blockchains in the embodiments corresponding to the above-mentioned FIG3, FIG5, FIG7, FIG9 or FIG11, and can also execute the description of the asset transfer device based on multiple blockchains (i.e., the asset transfer device 1 based on multiple blockchains or the asset transfer device 2 based on multiple blockchains) in the embodiments corresponding to the above-mentioned FIG13 or FIG14.
  • the description of the beneficial effects of the same method will not be repeated here.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer program executed by the asset transfer device 1 based on multiple blockchains mentioned above, or the asset transfer device 2 based on multiple blockchains, and the computer program includes computer instructions.
  • the processor executes the computer instructions, it can execute the description of the asset transfer method based on multiple blockchains in the corresponding embodiments of Figures 3, 5, 7, 9 or 11 above, so it will not be repeated here.
  • the description of the beneficial effects of the same method will not be repeated.
  • the computer instructions can be deployed on a computing device for execution, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network.
  • Multiple computing devices distributed at multiple locations and interconnected by a communication network can constitute a blockchain system.
  • the embodiment of the present application also provides a computer program product or a computer program, which may include computer instructions, which may be stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor may execute the computer instruction so that the computer device executes the description of the asset transfer method based on multiple blockchains in the embodiments corresponding to Figures 3, 5, 7, 9 or 11 above, so it will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • FIG16 is a schematic diagram of an asset transfer system based on multiple blockchains provided in an embodiment of the present application.
  • the asset transfer system 3 based on multiple blockchains may include consensus nodes 3a, consensus nodes 3b, and consensus nodes 3c; wherein, consensus node 3a may be a management consensus node in the target chain network described in the embodiment corresponding to FIG3 above, and the management consensus node may be any blockchain node in the consensus network 100a shown in FIG1 above, which will not be described in detail here.
  • consensus node 3b may be a first consensus node in the first chain network described in the embodiment corresponding to FIG3 above, and the first consensus node may be any blockchain node in the consensus network 300a shown in FIG1 above, which will not be described in detail here.
  • consensus node 3c may be a second consensus node in the second chain network described in the embodiment corresponding to FIG3 above, and the second consensus node may be any blockchain node in the consensus network 300a shown in FIG1 above, which will not be described in detail here. in addition, the description of the beneficial effects of using the same method will not be repeated.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供了一种基于多区块链的资产转移方法、装置、设备、介质及产品，该方法包括：获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求(S301)，将第一跨链资产转出请求中携带的第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约(S302)，在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产，并生成第一跨链转出交易对应的第一跨链事件(S303)。采用本申请可以基于多区块链架构确保链上所执行业务的业务稳定性。

Description

基于多区块链的资产转移方法、装置、设备、介质及产品
本申请要求于2022年10月20日提交，申请号为202211291310.4、发明名称为“基于多区块链的资产转移方法、装置、设备、介质及产品”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链技术领域，尤其涉及一种基于多区块链的资产转移方法、装置、设备、介质及产品。
背景技术
目前，区块链电子票据系统通常是基于单链结构构建的，即区块链电子票据系统存在通过同一区块链来执行不同业务的现象，以至于该单链上的这些区块中可能存储不同交易业务所对应的不同资产的现象。比如，该单链上可以存储有与票据业务相关联的票据资产以及与票据业务无关的其他业务的业务资产(例如，与转账业务相关的数字资产等)，这样将会使得整个链上所存储的数据混杂严重。
基于此，当用户在该区块链上发起针对前述票据资产的转移业务时，将会在用于执行前述转账业务的同一链上执行该转移业务。那么，当该单链所对应的业务处理队列中存在大量其他用户所请求的其他业务时，则该区块链电子票据系统在执行该业务处理队列中的这笔转移业务之前，需要预先执行大量的其他业务，这势必将会消耗一定的业务等待时长，进而会影响在该区块链上对该票据资产进行转移的转移效率。此外，在该区块链电子票据系统用于处理前述大量的不同业务时，将会消耗该单链上大量的计算资源和存储资源，进而难以确保该单链上所需要执行的业务(例如，上述转移业务)的业务稳定性。
发明内容
本申请实施例提供了一种基于多区块链的资产转移方法、装置、设备、介质及产品。
本申请实施例一方面提供了一种基于多区块链的资产转移方法，多区块链包含第一链、第二链和目标链；方法由第一链对应的第一链网络中的第一共识节点执行，方法包括：
获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求；该第一跨链资产转出请求中携带为业务对象配置的业务数据信息，业务数据信息由目标链网络中的目标共识节点配置；该第一跨链资产转出请求用于指示第一共识节点通过跨链中继将属于业务对象的第一资产从第一链转移至与第二共识节点相关联的第二链；该第二共识节点为第二链对应的第二链网络中的共识节点；跨链中继用于隔离第二链网络和第一链网络，且第二链网络独立于目标链网络和第一链网络；
将第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约；
在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产，并生成第一跨链转出交易对应的第一跨链事件；该第一跨链事件用于指示跨链中继在构建得到第一跨链转出交易对应的第一跨链转入交易时，将第一跨链转入交易发送至第二共识节点；该第二共识节点用于在将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约时，调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
本申请实施例一方面提供了一种基于多区块链的资产转移方法，多区块链包含第一链、第二链和目标链；方法由第二链对应的第二链网络中的第二共识节点执行，方法包括：
获取跨链中继针对第一资产发送的第一跨链转入交易；该第一跨链转入交易是由跨链中继从第一共识节点读取到第一跨链转出交易对应的第一跨链事件时所构建的；该第一跨链事件是由第一共识节点在基于写入有第一跨链转出交易的第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产时所生成的；该业务数据信息为目标链网络中的目标共识节点为业务对象所配置的；该第一共 识节点为第一链对应的第一链网络中的共识节点；跨链中继用于隔离第一链网络和第二链网络，且第一链网络独立于目标链网络和第二链网络；
将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约；
调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
本申请实施例一方面提供了一种基于多区块链的资产转移装置，多区块链包含第一链、第二链和目标链；装置运行在第一链对应的第一链网络中的第一共识节点上；装置包括：
获取模块，用于获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求；该第一跨链资产转出请求中携带有为业务对象配置的业务数据信息，该业务数据信息由目标链网络中的目标共识节点配置；该第一跨链资产转出请求用于指示第一共识节点通过跨链中继将属于业务对象的第一资产从第一链转移至与第二共识节点相关联的第二链；该第二共识节点为第二链对应的第二链网络中的共识节点；跨链中继用于隔离第二链网络和第一链网络，且第二链网络独立于目标链网络和第一链网络；
写入模块，用于将第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约；
调用模块，用于在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产，并生成第一跨链转出交易对应的第一跨链事件；第一跨链事件用于指示跨链中继在构建得到第一跨链转出交易对应的第一跨链转入交易时，将第一跨链转入交易发送至第二共识节点；该第二共识节点用于在将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约时，调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
本申请实施例提供了一种基于多区块链的资产转移装置，多区块链包含第一链、第二链和目标链；装置运行在第二链对应的第二链网络中的第二共识节点上；装置包括：
处理模块，用于获取跨链中继针对第一资产发送的第一跨链转入交易；该第一跨链转入交易是由跨链中继从第一共识节点读取到第一跨链转出交易对应的第一跨链事件时所构建的；该第一跨链事件是由第一共识节点在基于写入有第一跨链转出交易的第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产时所生成的；该业务数据信息为目标链网络中的目标共识节点为业务对象所配置的；该第一共识节点为第一链对应的第一链网络中的共识节点；跨链中继用于隔离第一链网络和第二链网络，且第一链网络独立于目标链网络和第二链网络；
处理模块，还用于将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约；
资产铸造模块，用于调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
本申请实施例一方面提供了一种计算机设备，包括存储器和处理器，存储器与处理器相连，存储器用于存储计算机程序，处理器用于调用计算机程序，以使得该计算机设备执行本申请实施例中上述一方面提供的方法。
本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序适于由处理器加载并执行，以使得具有处理器的计算机设备执行本申请实施例中上述一方面提供的方法。
根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述一方面提供的方法。
本申请实施例中，可以获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求；其中，该第一跨链资产转出请求携带有目标链所关联的目标共识节点所配置的业务数据信息，在本申请实施例中，该业务数据信息可以用于对该发起第一跨链资产转出请求的业务对象进行权限验证，以确保跨链转移资产的安全性(即可以在跨链进行资产转移时，确保跨 链转移的合法性)。其中，本申请实施例所涉及的第一跨链资产转出请求可以用于将第一资产从第一共识节点相关联的第一链转移至第二共识节点相关联的第二链，前述提及的第一链、第二链和目标链为基于多链架构所构建的用于跨链转移资产的多区块链，且三条链分别处于相互独立的共识网络中；将第一跨链资产转出请求中携带的第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约，在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限时，调用第一链上的第一资产合约锁定第一资产，且生成第一跨链转出交易对应的第一跨链事件；该第一跨链事件可以用于指示跨链中继构建第一跨链转入交易，以使第二共识节点铸造与第一资产具有相同资产内容的第二资产，从而实现第一资产的资产转移。由此可见，本申请实施例提供了一种基于多区块链的资产转移机制，该基于多区块链的资产转移机制旨在强调可以通过三链的相互协作，实现第一资产的跨链转移，比如，可以在目标链为用户(即前述业务对象)授权配置有上述业务数据信息的情况下，允许用户发起用于将第一资产从第一链转移至第二链的转移业务，这里的转移业务即为上述第一跨链转出交易。应当理解，由于本申请实施例所涉及的第一链、第二链和目标链彼此相互独立，故而可以分别用于执行不同的业务(比如，可以在第一链上执行与第一资产本身相关的业务(比如与票据资产相关的票据业务)，而在第二链上执行与该票据业务相关联的衍生业务)，从而降低各链上所存储数据的混杂程度。另外，通过多区块链之间的相互协作，还可以在各链上正常执行其他业务时，即不影响其他业务的请求下，实现该转移业务的同步跨链执行，进而可以提升对第一资产进行跨链转移的转移效率。应当理解，本申请实施例在基于多区块链的资产转移过程中，通过链上部署的合约(比如第一链上的第一跨链桥合约、第一资产合约等)来协作执行针对该第一资产的转移业务，可以确保链上所执行业务(即跨链转移第一资产的转移业务)不受其他业务的影响，进而可以确保该转移业务的业务稳定性。
附图说明
图1是本申请实施例提供的一种区块链网络的分层结构示意图；
图2a是本申请实施例提供的一种应用架构示意图；
图2b是本申请实施例提供的一种基于多区块链的区块链电子票据平台的场景示意图；
图3是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；
图4是本申请实施例提供的一种跨链资产转出的场景示意图；
图5是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；
图6是本申请实施例提供的一种跨链资产转入的场景示意图；
图7是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；
图8是本申请实施例提供的一种跨链资产转入的场景示意图；
图9是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；
图10是本申请实施例提供的一种跨链资产转出的场景示意图；
图11是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；
图12是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；
图13是本申请实施例提供的一种基于多区块链的资产转移装置的结构示意图；
图14是本申请实施例提供的一种基于多区块链的资产转移装置的结构示意图；
图15是本申请实施例提供的一种计算机设备的结构示意图；
图16是本申请实施例提供的一种基于多区块链的资产转移系统的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参见图1，图1是本申请实施例提供的一种区块链网络的分层结构示意图。如图1所示的分层结构应用于区块链数据系统，比如可以为区块链电子票据系统，且在该区块链电子 票据系统所对应的区块链网络中，包括业务网络和多个共识网络，该业务网络处于公网中，共识网络处于私网中(比如部署在私有云中)。如图1所示，业务网络可以表示为图1所示的业务网络400a，且多个共识网络具体可以表示为图1所示的共识网络100a、共识网络200a和共识网络300a。
在如图1所示的业务网络400a中，部署有多个业务节点，多个业务节点具体可以包含图1所示的业务节点110a、业务节点110b、…、业务节点110n。其中，可以理解的是，这里并不对部署在该业务网络400a中的业务节点的数量进行限定。随着业务需求的变化，业务节点的数量可以不断变化。应当理解，处于业务网络400a中的业务节点不需要参与记账。此外，如图1所示，对于运行在该业务网络400a中的各个业务节点而言，均可以通过网络通信的形式访问上述多个共识网络中的一个或者多个，这里并不对各业务对象通过相应业务节点访问到的共识网络的数量进行限定。可以理解的是，各个共识网络之间也可以通过网络通信的形式进行数据交互。
应当理解，在如图1所示的共识网络100a中，部署有多个共识节点，这里的多个共识节点具体可以包含图1所示的共识节点10a、共识节点10b、共识节点10c和共识节点10d。需要注意的是，这里并不对部署在该共识网络100a中的共识节点的数量进行限定，随着业务需求的变化，这里的共识节点的数量可以不断变化。此外，如图1所示，对于运行在该共识网络100a中的多个共识节点而言，共同维护的区块链具体为图1所示的区块链10e。
同理，在如图1所示的共识网络200a中，部署有多个共识节点，这里的多个共识节点具体可以包含图1所示的共识节点11a、共识节点11b、共识节点11c和共识节点11d。需要注意的是，这里将不对部署在该共识网络200a中的共识节点的数量进行限定，随着业务需求的变化，这里的共识节点的数量可以不断变化。此外，如图1所示，对于运行在该共识网络200a中的多个共识节点而言，共同维护的区块链具体为图1所示的区块链11e。
相应地，在如图1所示的共识网络300a中，部署有多个共识节点，这里的多个共识节点具体可以包含图1所示的共识节点12a、共识节点12b、共识节点12c和共识节点12d。需要注意的是，这里并不对部署在该共识网络300a中的共识节点的数量进行限定，随着业务需求的变化，这里的共识节点的数量可以不断变化。此外，如图1所示，对于运行在该共识网络300a中的多个共识节点而言，共同维护的区块链具体为图1所示的区块链12e。
为便于理解，本申请实施例可以将位于上述区块链电子票据系统中的业务节点和共识节点统称为区块链节点(简称为节点)，并可以将参与构成上述区块链电子票据系统的共识网络100a、共识网络200a和共识网络300a统称为核心共识网络，并可以将上述核心共识网络中的各个节点统称为核心节点。
应当理解，本申请实施例所涉及的区块链是一种分布式数据存储、点对点传输、共识机制以及加密算法等计算机技术的新型应用模式，主要用于对数据按时间顺序进行整理，并加密成账本，使其不可被篡改和伪造，同时可进行数据的验证、存储和更新。区块链本质上是一个去中心化的数据库，该数据库中的每个节点均存储一条相同的区块链。
基于具体场景，共识网络100a中的每个节点(比如，共识节点10a、共识节点10b、共识节点10c和共识节点10d等核心节点)上所存储的区块链均为区块链10e，这里的区块链10e可以为上述区块链电子票据系统中的目标链(比如可以称为管理链)，且该管理链所对应的核心共识网络(即共识网络100a)可以为目标链网络(比如可以称为管理链网络)，该管理链网络中的共识节点(或者核心节点)可以统称为目标共识节点(比如可以称为管理共识节点)。又比如，共识网络200a中的每个节点(比如，共识节点11a、共识节点11b、共识节点11c和共识节点11d等核心节点)上所存储的区块链均为区块链11e，这里的区块链11e可以为上述区块链电子票据系统中的第一链(比如可以称为票据链)，且该票据链所对应的核心共识网络(即共识网络200a)可以为第一链网络(比如可以称为电子票据网络、或票据链网络)，该电子票据网络中的共识节点(或者核心节点)可以统称为票据共识节点，并可以利用该电子票据网络中的共识机制将在这些票据共识节点中所选取的某个票据共识 节点作为第一共识节点。又比如，共识网络300a中的每个节点(比如，共识节点12a、共识节点12b、共识节点12c和共识节点12d等核心节点)上所存储的区块链均为区块链12e，这里的区块链12e可以为上述区块链电子票据系统中的第二链(比如可以称为应用合约链)，且该应用合约链所对应的核心共识网络(即共识网络300a)可以为第二链网络(比如可以称为应用合约链网络)，该应用合约链网络中的共识节点(或者核心节点)可以统称为应用共识节点，并可以利用该应用合约链网络中的共识机制将在这些应用共识节点中所选取的某个应用共识节点作为第二共识节点。
在上述区块链电子票据系统中，核心节点可以负责对应区块链所在的核心共识网络中的共识，也就是说核心节点可以为对应区块链所在核心共识网络中的共识节点。对于上述三个核心共识网络中的任意一个核心共识网络而言，将核心共识网络中的交易数据写入对应区块链账本(例如，分布式数据库)的具体过程可以为，用户客户端发送交易数据至某个业务节点，随后该交易数据以接力棒的方式在上述区块链网络内的业务网络中的业务节点之间传递，直到上述区块链网络内的相应核心共识网络中的共识节点(例如，共识网络200a中的共识节点11b)收到该交易数据，此时，共识节点(例如，共识网络200a中的共识节点11b)再将该交易数据打包进区块，以便于后续可以与其他共识节点之间进行共识，从而可以在共识通过后，将共识通过的区块写入自己所在核心共识网络(例如，共识网络200a)的分布式数据库。
可选的，可以理解的是，本申请实施例还可以在共识通过后，通过所在核心共识网络(例如，共识网络200a)的存储层将携带该交易数据的区块和与该区块关联的其他多个区块并行写入分布式数据库，这样可以从根源上突破区块链的区块链结构的限制，进而可以有效地提升数据存储的存储效率。
其中，可以理解的是，在上述区块链电子票据系统中，可以在相应核心共识网络的区块链上部署智能合约，该智能合约在区块链电子票据系统中可以理解为是一种由各区块链节点(即各共识节点)执行的代码，通过该智能合约可以执行任意逻辑并得到结果。比如，用户可以通过用户客户端发起一个业务请求(比如第一跨链资产转出请求)的方式，调用相应核心共识网络(例如，上述共识网络200a)的区块链(例如，上述区块链11e)上已经部署的智能合约(比如第一跨链桥合约)，以实现票据资产的跨链转移。
具体的，业务网络中的业务节点可以将该第一跨链资产转出请求发送至相应核心共识网络中的共识节点(例如，图1所示的共识节点11a)，以通过相应核心共识网络的链入口对该第一跨链资产转出请求的用户进行身份鉴权，且在身份鉴权成功时允许将该用户所发送的第一跨链资产转出请求发送至相应核心共识网络中的其他共识节点(例如，图1所示的共识节点11b)，以调用这些共识节点(例如，图1所示的共识节点11a和共识节点11b)中运行的智能合约执行该用户所请求的交易业务(比如第一跨链资产转出请求所指示的资产转移业务)。
应当理解，在上述核心共识网络(例如，上述共识网络200a)的区块链(例如，上述区块链11e)上可以部署一个或多个智能合约，这些智能合约可以通过合约调用地址、合约标识号(Identity document，ID)或合约名称来进行区分，而用户客户端发起的第一跨链资产转出请求中，也可以携带智能合约的合约调用地址或者合约标识号或合约名称，以此指定需要运行的智能合约。而在上述区块链电子票据系统中，若用户客户端所指定的智能合约为需要跨链读取相关数据的智能合约(比如为第一跨链桥合约)，则各个共识节点会通过该第一跨链桥合约所指定的链标识，请求从对应区块链(比如管理链)上进行相关数据(比如源配置数据信息)的读取，最后各个共识节点会互相验证所得到的各业务执行结果是否一致(也就是进行共识)，若一致则可以将业务执行结果存入各自的本地缓存和本地存储中。注意，这里的本地缓存为在存储层中创建的系统内存，这里的本地存储为在存储层中所创建的用于进行数据存储的硬盘空间。这样，当核心共识网络中的某个共识节点出现宕机(即down机)或者系统故障时，并不会因为系统内存中的数据消失而造成无法进行数据读取的现象，即该 共识节点还可以通过在该存储层中创建的本地存储来进行数据的读取。
应当理解，在上述区块链电子票据系统中，任意一个共识网络(例如，共识网络100a、共识网络200a或者共识网络300a)中的任意两个区块链节点之间可以形成点对点(P2P，Peer To Peer)网络，该点对点网络可以采用P2P协议，其中，该P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。在分布式系统中，任何设备如服务器、终端等都可以加入而成为区块链节点，其中，每个区块链节点均可以包括硬件层、中间层、操作系统层和应用层。
可以理解的是，在上述共识网络100a被作为上述管理链网络时，位于该管理链网络中的共识节点(例如，上述管理共识节点，该管理共识节点可以为图1所示的共识节点10a)可以为通过管理链网络入口而接入该管理链网络中的相应业务对象提供注册业务和授权业务，进而可以在该管理链网络中对需要接入上述区块链网络(例如，上述管理链网络、电子票据网络或者应用合约链网络)中的业务对象进行身份管理和权限管理。比如，由管理共识节点通过管理链为业务对象配置业务数据信息，该业务数据信息可以用于对业务对象请求跨链转移票据资产的权限进行权限验证。
除此之外，位于该管理链网络中的管理共识节点还可以用于对上述区块链电子票据系统中的相关元数据信息进行数据管理，比如，可以管理更新管理链上的合约模板(应当理解，管理链上的合约模板具体可以包含部署在管理链上的智能合约的管理合约模板和部署在应用合约链上的智能合约的应用合约模板)，管理更新记录在管理链上的票据模板，管理更新与该票据模板相关联的计税规则等、控制票据链所对应链入口处的访问流量、控制各链上参与共识的共识节点的数量等。
比如，当开发者和税务业务参与方需要在应用合约链上部署某个衍生业务对应的智能合约时，可以在通过应用合约链对应的链入口(即应用合约链入口)接入该应用合约链网络的情况下，进一步通过应用合约链上的第二跨链桥合约中的合约模板读取方法，从该合约模板读取方法所指示的管理链上读取该衍生业务对应的应用合约模板，以在该应用合约链上基于读取到的应用合约模板部署该衍生业务对应的智能合约。这样，当后续税务业务参与方需要在该应用合约链上执行衍生业务时，则可以利用已经部署好的衍生业务对应的智能合约来执行相应衍生业务。
应当理解，在上述共识网络200a被作为上述电子票据网络时，位于电子票据网络中的共识节点(例如，上述第一共识节点，该第一共识节点可以为图1所示的共识节点11b)可以用于提供票据业务，这里的票据业务可以包含但不限于票据资产转移业务、电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务等与电子票据相关的业务。
此外，还可以理解的是，在上述共识网络300a被作为上述应用合约链网络时，位于应用合约链网络中的共识节点(例如，上述第二共识节点，该第二共识节点可以为图1所示的共识节点12b)可以用于提供与前述票据业务相关联的衍生业务(例如，信贷业务、进出亏业务、企业资质业务等)。
其中，可以理解的是，由于每个实体对象均可以对应一个区块链节点，所以，本申请实施例可以以实体对象为上述企业对象(即前述企业)为例，此时，与每个企业对象相关联的区块链节点可以为同一区块链节点(例如，上述图1所示的业务节点110c可以与多个企业对象所对应的用户终端进行数据交互)。比如，在上述区块链电子票据系统中，可以将每个企业对象所请求的票据业务(比如，票据资产转移业务、电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务等与电子票据相关的业务)统称为一笔交易业务。其中，在上述企业对象为请求通过电子票据网络(例如，上述共识网络200a)将票据资产从票据链转移至应用合约链时，可以通过图1所示的业务节点110c与上述共识网络100a中的共识节点(例如，共识节点10b)、共识网络200a中的共识节点(例如，共识节点11b)和共识网络300a中的共识节点(例如，共识节点12b)进行数据交互，以请求完成相应的票据业务(比如票据资产转移业务)。
其中，可以理解的是，本申请实施例可以将针对上述票据资产转移业务向电子票据网络发送第一跨链资产转出请求的实体对象(例如，企业对象A、企业对象B、...、企业对象C)统称为业务对象，并可以在业务网络(例如，上述业务网络400a)中，将与该业务对象相关联的区块链节点(例如，上述业务节点110c)统称为业务节点，还可以在核心共识网络(例如，上述作为电子票据网络的共识网络200a)中，将获取该第一跨链资产转出请求所指示的票据资产转移业务的区块链节点统称为上述第一共识节点。
为便于理解，进一步的，请参见图2a，图2a是本申请实施例提供的一种应用架构示意图，可以通过该应用架构执行本申请所提出的基于多区块链的资产转移方法。如图2a所示，可以包括第一共识节点(即上述图1中第一链对应的第一链网络中的共识节点)、第二共识节点(即上述图1中第二链对应的第二链网络中的共识节点)、目标共识节点(即上述图1中目标链对应的目标链网络中的共识节点)、第一共识节点与第二共识节点之间的跨链中继、和业务对象对应的业务节点。其中，业务对象通过业务节点生成针对第一跨链转出交易的第一跨链资产转出请求；前述第一跨链资产转出请求中携带了目标共识节点为业务对象配置的业务数据信息，目标共识节点中存储有针对业务对象的源配置数据信息；第一共识节点将第一跨链资产转出请求中携带的第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约(当第一资产为票据资产时，第一跨链桥合约比如可以称为第一票据跨链桥合约)，并基于第一跨链桥合约和业务数据信息确定业务对象是否具有跨链资产转出权限，即通过目标共识节点进行跨链资产转出权限的查询；比如具体可以是基于第一跨链桥合约、业务数据信息以及目标链上的跨链授权管理合约，从目标链上获取源配置数据信息，通过第一跨链资产转出请求中的业务数据信息和源配置数据信息确定业务对象的跨链资产转出权限；在确定具有该跨链资产转出权限时，调用第一链上的第一资产合约(当第一资产为票据资产时，第一资产合约比如可以称为票据资产合约)锁定第一资产(比如为票据资产)，并生成第一跨链转出交易对应的第一跨链事件，以指示跨链中继(用于隔离第二链网络和第一链网络)将构建的第一跨链转入交易发送给第二共识节点，该第二共识节点可以在将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约(当第一资产为票据资产时，第二跨链桥合约比如可以称为第二票据跨链桥合约)时，调用第二资产合约(当第一资产为票据资产时，第二资产合约比如可以称为票据资产映射合约)在第二链上铸造与第一资产具有相同资产内容的第二资产(当第一资产为票据资产时，第二资产比如可以称为票据映射资产)，从而可以实现第一共识节点将属于业务对象的第一资产从第一链转移至第二链。可以通过多个区块链的相互协作，提升跨链转移链上资产的安全性和可靠性。
可以理解的是，图2a只是示例性地表征本申请技术方案的可能存在的应用架构，并不对本申请技术方案的具体架构进行限定，即本申请技术方案还可以提供其他形式的应用架构。
可选的，在一些实施例中，电子设备可根据实际的业务需求，执行该基于多区块链的资产转移方法以提高链上所执行业务的业务稳定性。本申请技术方案可以应用于任意链上资产的链上转移场景中，该链上资产可以是各种类型的票据资产，比如税务类票据，如普通电子发票、增值税发票等；或者比如医疗类票据，如电子处方、电子收费单等等。在此不做限定。
为便于理解，进一步的，请参见图2b，图2b是本申请实施例提供的一种基于多区块链的区块链电子票据平台的场景示意图。该区块链电子票据平台可以为上述区块链电子票据系统中的具体业务平台，应当理解，在该区块链电子票据平台中，为降低在链上所执行业务和链上数据存储的混杂度，提出了一种全新的基于区块链电子票据的多链体系，且该多链体系主要涉及图2b所示的区块链电子票据三链网络。如图2b所示，该区块链电子票据三链网络中可以部署有上述提及的管理链、票据链和应用合约链。其中，可以理解的是，在以区块链作为区块链电子票据链上数据流转的业务场景中，可以通过管理链、票据链和应用合约链之间的相互协作，为整个区块链电子票据平台提供独立执行不同业务的功能特性，各个区块链分别执行不同的业务且对于同一业务可以相互协作，从而可以在三链相互协作的前提下，构 造一个安全且高效的业务流系统。应当理解，这里以多链系统为三链体系为例，在该三链系统下，管理链、票据链和应用合约链均是独立搭建的，即用于维护该管理链的共识节点不同于用于维护该票据链的共识节点，且不同于用于维护该应用合约链的共识节点。
如图2b所示，部署在区块链电子票据三链网络中的管理链独立于票据链和应用合约链，即这三条独立搭建的区块链之间是彼此相互独立的，但是这三条独立搭建的区块链之间可以通过跨链的方式进行数据交互，即这三链之间可以进行跨链交互。比如，在如图2b所示的票据链上部署有第一票据跨链桥合约(即上述提及的第一跨链桥合约)的情况下，参与维护该票据链的共识节点(即上述第一共识节点)则可以通过该第一票据跨链桥合约，跨链读取管理链上的业务数据信息来进行业务对象的权限(比如跨链资产转出权限)的确认。又比如，在如图2b所示的应用合约链上部署有第二票据跨链桥合约(即上述提及的第二跨链桥合约)的情况下，参与维护该应用合约链的共识节点(即上述第二共识节点)可以通过该第二票据跨链桥合约，跨链读取管理链上的业务数据信息来进行业务对象的权限(比如跨链资产转回权限)的确认，还可以通过该第二票据跨链桥合约，跨链读取票据链上的链上数据(比如，票据链上属于业务对象的票据资产)来执行相应的衍生业务(比如，可以通过从票据链上所转移到的票据资产来执行上述征信业务，以得到某个企业的企业征信信息)。
比如，这里的管理链可以用于为整个区块链电子票据平台提供管理功能特性，这里的票据链可以为整个区块链电子票据平台提供不同业务权限类型的票据业务的功能特性。应当理解，在本申请实施例中，为确保写入票据链中的票据资产的安全性和独立性，本申请实施例提出可以通过独立于管理链和票据链的另一区块链(即图2b所示的应用合约链)来提供更加规范、灵活和功能完备的衍生业务，即这里的应用合约链则可以为整个区块链电子票据平台提供基于电子票据中链上数据来开展衍生业务的功能特性。
为便于理解，这里以管理链所在的核心共识网络(即上述管理链网络)为上述图1所示的共识网络100a为例，此时，参与维护该管理链的共识节点可以为上述管理共识节点。如图2b所示，该管理链上部署有多个智能合约，这些智能合约可以运行在管理共识节点上。可以理解的是，这里的多个智能合约具体可以包含图2b所示的对象权限管理合约、对象身份管理合约、元数据管理合约、内部管理合约和跨链授权管理合约。应当理解，该管理链上所部署的这些智能合约是由图2b所示的内部参与方(即税务管理部门)分别通过自己链(即管理链)上部署的相应管理合约模板所确定的。
可以理解的是，前述税务管理部门可以通过该部署在管理链网络中的管理共识节点行使管理职责。比如，这里的管理职责可以包含对业务部门内部的信息(比如，税务管理部门内部人员的信息)进行管理、对整体业务的业务逻辑规则(例如，应用合约链上所运行的用于执行衍生业务的业务逻辑的衍生业务合约)进行管理、对整体业务的元数据信息(例如，三链体系下的各链入口处的访问流量)进行管理、对整体业务的参与者(比如，个人对象、企业对象、税务业务参与方等业务对象)进行身份管理和权限管理等。应当理解，在整体业务所对应的区块链网络中，由该管理共识节点所维护的管理链是相对更稳定、数据规模最小、但安全性最高的区块链。
此外，为便于理解，这里以图2b所示的票据链所在的核心共识网络(即上述电子票据网络)为上述图1所示的共识网络200a为例，此时，参与维护该票据链的共识节点可以为上述第一共识节点。如图2b所示，该票据链上部署有多个智能合约，这些智能合约可以运行在第一共识节点上。具体的，可以理解的是，这里的多个智能合约具体可以包含图2b所示的电子票据开具合约、电子票据流转合约、电子票据红冲合约、电子票据归档合约和第一票据跨链桥合约(可以用于执行票据资产转移业务)。同理，应当理解，该票据链上所部署的这些智能合约是由图2b所示的内部参与方(例如，与电子票据数据中心相关联的税务部门)通过管理链上部署的相应票据业务合约模板所确定的。
可以理解的是，该部署在电子票据网络中的第一共识节点可以通过票据链维护电子票据在全生命周期内的业务逻辑，比如，可以通过该票据链管理所有开具的电子票据的全生命周 期。比如，这里的电子票据的全生命周期包含电子票据的开具、电子票据的流转和电子票据的报销等。应当理解，在整体业务所对应的区块链网络中，由该第一共识节点所维护的票据链具有高性能、低延迟的特点。
同理，为便于理解，这里以应用合约链所在的核心共识网络(即上述应用合约链网络)为上述图1所示的共识网络300a为例，此时，参与维护该应用合约链的共识节点可以为上述第二共识节点。如图2b所示，该应用合约链上部署有多个智能合约，这些智能合约具体可以运行在第二共识节点上。可以理解的是，这里的多个智能合约具体可以包含图2b所示的虚拟机兼容合约、开放合约部署合约、衍生业务合约和第二票据跨链桥合约(可以用于执行票据映射资产转移业务)。
可以理解的是，该部署在应用合约链网络中的第二共识节点可以通过应用合约链承载可变化的票据业务所对应的衍生业务，比如，这里的衍生业务可以包含上述征信业务、上述资质识别业务等。应当理解，在整体业务所对应的区块链网络中，由该第二共识节点所维护的应用合约链，可以支持图2b所示的业务协作部门和联盟链伙伴(即图2b所示的业务关联部门)，通过图2b所示的税务应用合约(开放合约部署合约)间接调用第二票据跨链桥合约，以利用跨链读取到的管理上的应用合约模板来开发与衍生业务相关的智能合约(例如，图2b所示的衍生业务合约)，并可以经过税务管理部门审核后将该衍生业务合约部署在应用合约链上。应当理解，部署在应用合约链上的智能合约可以通过虚拟机兼容合约实现智能合约的灵活升级和变化，应当理解，在整体业务所对应的区块链网络中，该第二共识节点可以通过应用合约链上的第二票据跨链桥合约实现跨链交互，比如，可以通过第二票据跨链桥合约从票据链上读取上述链上数据来执行衍生业务。这意味着由该第二共识节点所维护的应用合约链，相较于管理链和票据链而言，具有最高的开放度，且支持复杂的智能合约逻辑，参与方较多且不断动态变化，性能相对低于票据链。
其中，可以理解的是，在图2b所示的区块链电子票据三链网络中，管理链所采用的共识算法，不同于票据链所采用的共识算法，也不同于应用合约链所采用的共识算法。
1.1)与管理链相关联的共识算法为一种即时确定性共识算法，比如，这里的即时确定性共识算法可以为PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错)共识算法，通过该PBFT共识算法可以立即确定某个待上链的提议区块的状态。应当理解，该管理链为上述管理链网络中的区块链，在该管理链网络中的共识节点(即上述管理共识节点)可以由图2b所示的税务管理部门参与进行管理。
应当理解，与该管理链相关联的内部参与方可以为图2b所示的税务管理部门，比如，该税务管理部门在作为内部参与方参接入该管理链时，可以通过管理链上的内部管理合约对该税务管理部门的一些内部状态进行管理，比如，可以对该税务管理部门中的各人员进行管理，比如，可以在税务管理部门的这些人员中配置特定的税务管理人员、税务开发人员、税务审计人员等。此外，该税务管理部门在作为内部参与方参接入该管理链时，还可以通过管理链上的内部管理合约对该三链体系中的一些参数进行管理，比如，通过该内部管理合约可以对图2b所示的票据链入口处的访问流量所对应的访问流量参数进行限制，例如，可以通过分时访问机制控制票据链入口处的某些特定时间段内的访问流量不大于访问流量阈值。又比如，该税务管理部门在作为内部参与方参接入该管理链时，还可以通过管理链上的内部管理合约对参与共识的各链上的共识节点的数量所对应的节点数量参数进行限定。
1.2)与票据链相关联的共识算法为另一种即时确定性共识算法，比如，这里的即时确定性共识算法可以为TBFT(Tower Byzantine Fault Tolerance，塔式拜占庭容错)共识算法，该TBFT共识算法是一种拜占庭容错算法，可以在拜占庭节点数(即电子票据网络中的作恶节点数)小于电子票据网络的节点总数1/3的情况下，保证整个电子票据网络系统的安全运行。应当理解，处于电子票据网络中的共识节点可以由前述税务管理部门参与进行管理，比如，税务管理部门中的特定税务人员可以通过上述管理链中的内部管理合约控制该电子票据网络中的共识节点的数量。又比如，税务管理部门中的特定税务人员所对应的税局终端可以 参与构成该电子票据网络。
应当理解，上述TBFT共识算法与PBFT共识算法的最大区别在于：PBFT共识算法有一个固定的leader节点(即主节点)用于打包交易池中的交易，当leader节点故障的时候会使用view-change子协议(即一种主节点切换子协议)更换leader节点；而在TBFT共识算法中，leader节点是基于轮换机制而轮换的，比如，在当前节点被作为leader节点时，每提交X个区块(X的值可以配置)，则会自动将该leader节点轮换成下一个节点。这意味着在该票据链对应的电子票据网络中的共识节点可以用于连续出块。
1.3)与应用合约链相关联的共识算法为又一种即时确定性共识算法，比如，这里的即时确定性共识算法可以为PoS(Proof-of-Stake，权益证明)共识算法，通过该权益证明共识算法可以维护该应用合约链所在应用合约链网络的网络安全性，且通过该权益证明共识算法可以立即确定某个待上链的提议区块的状态。可以理解的是，在该应用合约链网络中的共识节点可以由图2b所示的税务管理部门和业务协作部门以及大型参与机构(即前述联盟链中的大型企业，该大型企业即为前述图2b所示的业务关联部门)等共同参与进行管理。比如，税务管理部门中的税务人员(比如，图2b所示的税务业务参与方)可以通过应用合约链网络中的共识节点跨链读取前述票据链上所写入的电子票据的票据信息，以通过跨链读取到的票据信息执行与前述票据业务相关联的衍生业务。比如，可以通过跨链读取到的票据信息对请求开票的开票企业进行资质识别或者征信识别，以得到该开票企业的资质数据或者征信数据。应当理解，如图2b所示，这里的税务业务参与方在通过图2b所示的应用合约链入口接入应用合约链网络时，可以调用该图2b所示的应用合约链上的第二票据跨链桥合约，从图2b所示的票据链上读取基于衍生业务所请求的电子票据中的链上数据，以利用读取到的链上数据在该应用合约链上开展相应的衍生业务。
应当理解，在本申请实施例中，无需将票据链上所产生的大量的电子票据直接跨链转移至应用合约链，而是将票据链上所产生的这些电子票据中的部分授权可见的票据信息(即前述链上数据)跨链转移至应用合约链，这样可以从根源上确保票据链上所记录的这些票据资产的隐私性和安全性。
由此可见，对于请求接入上述应用合约链中的税务业务参与方而言，可以根据所请求的衍生业务的不同，从票据链上跨链读取到不同的链上数据(即可以从上述电子票据中获取到不同数据内容的票据信息)。
应当理解，针对该区块链电子票据三链网络中的智能合约而言，存在以下区别：
2.1)应当理解，如图2b所示的管理链上可支持特定语言智能合约引擎，上述管理共识节点通过该特定语言智能合约引擎可以在管理链上部署特定语言智能合约，比如，可以在管理链上部署上述图2b所示的对象权限管理合约、对象身份管理合约、元数据管理合约和内部管理合约、跨链授权管理合约等。应当理解，这些智能合约可以由税务管理部门中的特定税务管理人员开发和管理。
2.2)如图2b所示的票据链上内置有特定票据业务逻辑的智能合约，这些智能合约(例如，上述图2b所示的电子票据开具合约、电子票据流转合约、电子票据红冲合约、电子票据归档合约和第一票据跨链桥合约)可以随着票据业务的更新而进行升级。比如，本申请实施例可以通过从管理链上所读取到的最新版本的电子票据模板来更新电子票据开具合约中的电子票据模板，进而可以根据更新后的电子票据开具合约来更新处理上述票据业务。这意味着该票据链不支持独立的智能合约引擎，自然也就不支持在该票据链上部署与票据业务无关的其他合约。这样做的好处是让该票据链仅运行与电子票据相关的业务逻辑，且不受其他智能合约的影响，从而可以使该票据链的运行更加独立稳定，更抗攻击。
2.3)该应用合约链上支持多语言、图灵完备面向开发者的智能合约，比如，如图2b所示，开发者在通过应用合约链入口接入该应用合约链时，可以通过虚拟机兼容合约兼容主流的EVM虚拟机，以便于可以在兼容的虚拟机上部署运行各种新的业务合约，比如，可以在应用合约链上部署与衍生业务(例如，上述抽奖业务)相关联的衍生业务合约。又比如，可 以在应用合约链上部署与另一衍生业务(例如，上述退税业务)相关联的衍生应用合约。
应当理解，如上述图2b所示，在区块链电子票据三链网络中，并未在管理链上部署相应的票据跨链桥合约，故而此时，该管理链并不具备跨链能力。由于图2b所示的票据链和应用合约链上均部署有各自对应的票据跨链桥合约，故而具备跨链能力。
可选的，与票据链相关联的共识节点(例如，上述第一共识节点)可以通过图2b所示的第一票据跨链桥合约从管理链读取部分管理链信息，比如，可以从管理链上读取用于对业务对象的业务权限(比如跨链资产转出权限)进行确认的源配置数据信息。比如，还可以从管理链上读取最新的电子票据模板。
此外，与应用合约链相关联的共识节点(例如，上述第二共识节点)可以通过图2b所示的第二票据跨链桥合约从管理链读取部分管理链信息，比如，可以从管理链上读取用于对业务对象的业务权限(比如跨链资产转回权限)进行确认的源配置数据信息。比如，还可以从管理链上读取最新的应用合约模板。此外，第二共识节点还可以跨链从票据链读取部分票据链信息(例如，从票据链读取用于执行衍生业务的票据资产)。
应当理解，如图2b所示，在区块链电子票据三链网络中，与管理链相关联的公开网络参与方可以为图2b所示的个人对象和企业对象。同理，如图2b所示，与票据链相关联的公开网络参与方可以为图2b所示的各地电子票据数据流系统。这里的各地电子票据数据流系统具体包含各地方电子票据业务开具系统(例如，各地方税局系统)，电子票据开票服务商，大型企业财税相关系统等。同理，如图2b所示，与应用合约链相关联的公开网络参与方可以为图2b所示的税务业务参与方和开发者。
3.1)与管理链相关联的链入口可以为图2b所示的管理链入口。当图2b所示的个人对象(例如，用户A)和企业对象(例如，企业B)等作为公开网络参与方时，可以通过该管理链入口接入管理链，进而可以通过该管理链进行身份注册和身份授权等业务。
3.2)与票据链相关联的链入口可以为图2b所示的票据链入口。当图2b所示的各地方电子票据数据流系统(例如，大型企业对象)等作为公开网络参与方时，可以通过该票据链入口接入票据链，进而可以通过该票据链执行票据资产跨链转移业务、电子票据开具业务、电子票据流转业务、电子票据红冲业务和电子票据归档业务。
3.3)与应用合约链相关联的链入口可以为图2b所示的应用合约链入口。当图2b所示的税务业务参与方和开发者等作为公开网络参与方时，可以通过该应用合约链入口接入应用合约链，进而可以通过在应用合约链上部署衍生业务合约，以通过部署的衍生业务合约执行与电子票据相关的衍生业务。应当理解，图2b所示的开发者还可以在接入应用合约链的情况下，在该应用合约链上部署其他衍生业务(或者探索业务)所对应的衍生业务合约，这里将不对部署在应用合约链上的衍生业务合约的合约数量进行限定。
其中，可以理解的是，图2b所示的管理链入口可以为税务管理部门入口，通过该税务管理部门入口可以对需要接入管理链的个人、法人以及实体等进行身份识别和业务引导。
其中，可以理解的是，图2b所示的票据链入口可以为电子票据业务入口，通过该电子票据业务入口可以接收某个业务对象(例如，具有链上票据资产的业务对象，如可以为上述企业B)所请求开具的电子票据的交易业务数据(也可以称之为交易数据)。这样，在上述第一共识节点通过该电子票据业务入口接收到前述企业B提交的交易业务数据(比如转移业务对应的第一跨链转出交易)时，还可以通过该电子票据业务入口校验该交易业务数据的数据发送方(即作为业务对象的企业B)的接入身份和接入权限是否满足管理链中身份权限合约的状态要求。比如，第一共识节点可以在校验通过时，确定作为业务对象的企业B为授权对象，进而可以通过票据链上的第一票据跨链桥合约从管理链上读取业务对象的源配置数据信息以确定该作为授权对象的企业B的业务权限(比如跨链资产转出权限)。应当理解，通过源配置数据信息可以进一步判断作为授权对象的企业B的业务权限是否满足管理链中跨链授权管理合约的状态要求。
比如，上述第一共识节点通过该电子票据业务入口可以判断数据发送方(即企业B)的 接入身份和接入权限是否满足管理链中的对象身份管理合约和内部管理合约的合约状态要求，进而可以在确定满足管理链中的对象身份管理合约和内部管理合约的合约状态要求时，确定完成对需要接入该票据链的数据发送方(即前述企业B)的身份鉴权。由此可见，上述图2b所示的票据链入口处存储有从管理链同步来的各个授权对象的注册数据信息，这里的注册数据信息可以包含但不限于对象接入身份注册信息和对象接入权限注册信息。比如，这里的对象接入身份信息可以用于识别当前请求接入该票据链的业务对象(即前述企业B)是否为授权对象。这里的对象接入权限注册信息包含由管理共识节点通过内部管理合约为该票据链的电子票据业务入口所配置的请求累计阈值(例如，最大并发请求累积量)。又如，上述第一共识节点在对数据发送方进行身份鉴权成功时，可以从管理链上读取业务对象的源配置数据，进而可以确定授权对象(即前述企业B)是否满足管理链中的跨链授权管理合约的合约状态要求，进而可以在确定满足管理链中的跨链授权管理合约的合约状态要求时，确定完成对需要在票据链上进行票据资产跨链转移的数据发送方(即前述企业B)的跨链权限验证。
其中，可以理解的是，图2b所示的应用合约链入口可以为税务衍生业务入口，通过该税务衍生业务入口可以接收某个业务对象(例如，第二业务对象，该第二业务对象可以为图2b所示的税务业务参与方)所请求参与的与票据业务相关联的衍生业务。应当理解，在图2b所示的税务业务参与方和开发者可以在获得税务管理部门发放的授权对象的业务参与许可凭证后，可以通过该应用合约链入口对第二业务对象(例如，税务业务参与方或者开发者)提交的业务参与许可凭证进行验证，进而可以在验证成功时允许该第二业务对象接入该应用合约链，以在该应用合约链上执行与前述票据业务相关联的衍生业务。
其中，如图2b所示，参与维护管理链的内部参与方可以为图2b所示的税务管理部门，这里的税务管理部门主要用于在管理链上进行内部状态参数的配置与管理，还可以用于对上述元数据信息(例如，税务元数据)进行变更上链(如可以更新电子票据模板，更新计税规则等)，以及可以对于该管理链上所维护的各类业务参与方的身份和权限进行管理(如冻结企业开票资质，限制企业开票额度，跨链转移票据资产的权限等)。
其中，如图2b所示，参与维护票据链的内部参与方可以为图2b所示的电子票据数据中心，这里的电子票据数据中心具体可以为电子发票数据中心，该电子票据数据中心(比如，电子发票数据中心)可以用于对票据链上所记录的海量的账本数据(例如，基于上述实时票据业务流所产生的电子票据流等)进行链下备份、统计、数据分析和审查等工作。可选的，通过该电子票据数据中心可以统计分时开票数量，进而可以基于统计到的分时开票数量对风险票据(例如，风险发票)、风险企业进行判定，还可以对相关金融经济数据进行数据分析等。
其中，如图2b所示，参与维护应用合约链的内部参与方可以为图2b所示的业务协作部门和业务关联部门。应当理解，参与维护应用合约链的内部参与方除了税务管理部门之外，系统联盟链中的其他部门(即前述业务协作部门)和参与方(即前述业务关联部门)均可以在接入该应用合约链的情况下，进一步通过该应用合约链上的衍生业务合约执行相应的衍生业务。可以理解的是，图2b所示的业务协作部门和业务关联部门等作为税务业务参与方，接入应用合约链的好处是可以在支持完备的智能合约声明周期中灵活运行各类可扩展的衍生业务，以确保业务变化的灵活性，同时不需要直接接触上述票据链上的电子票据的链上数据，从而保证了票据链上的数据隐私和链上数据安全。比如，可以将需要进行衍生业务的票据资产从票据链转移至应用合约链，此处应用合约链仅能接触到该转移的票据资产，而无法接触除该票据资产以外的链上数据(比如票据资产所在区块上的其他链上数据)。这意味着在本申请实施例中，这部分所转移的票据资产在票据链上对应用合约链是授权可见的。可以使得业务对象基于票据资产所请求的衍生业务，可以在该应用合约链上进行有效的开展。
应当理解，此时，对于第二共识节点而言，无法得知该电子票据(即票据资产)中与该衍生业务无关的其他票据信息，更无法触及到该票据链上与该衍生业务无关的其他电子票据 (例如，D企业所开具的电子票据)，这样，可以确保存储在该票据链上的所存储票据数据的隐私安全性和可靠性。
其中，可以理解的是，在图2b所示的区块链电子票据三链网络中，均可以内置相应的智能合约。
其中，4.1)对于管理链上内置的智能合约而言，如图2b所示，内置在管理链上的对象身份管理合约具体可以为用户管理合约，通过该用户管理合约可以管理整个三链体系下的接入者(比如，公开网络参与方)和参与者(比如，内部参与方)的身份。应当理解，这里的接入者和参与者具体可以包含税务管理人员(简称管理员)、业务协作部门、地方税局、开票服务商、报销服务商、税务审查部门等。此外，内置在管理链上的对象权限管理合约具体可以为企业身份管理合约，通过该企业身份管理合约可以对某些企业的业务权限和税务状态等进行管理。同理，内置在管理链上的元数据管理合约具体可以为税务元数据管理合约，通过该税务元数据管理合约可以对税务规则等元数据信息进行管理，如可以集中管理三链体系下的合约模块，计税逻辑，最新政策规则等。以此类推，内置在管理链上的内部管理合约则可以用于对税务管理部门的一些内部状态进行管理，并可以对三链体系下的各链上的一些内部参数进行管理，如，可以通过该内部管理合约对上述票据链入口(比如，电子发票业务入口)处的访问流量参数进行限制，以及对三链体系下的共识节点数量参数进行限制等。
需要说明的是，本申请涉及管理链中的跨链授权管理合约。该跨链授权管理合约可以用于为请求执行跨链转移票据资产的业务对象配置用于进行权限验证的业务数据信息。比如，当管理共识节点为该业务对象配置好相应的业务数据信息的情况下，可以将该配置好相应的业务数据信息作为源配置数据信息上链至管理链，且还可以将配置好相应的业务数据信息返回给业务对象，以进一步在请求跨链转移票据资产的票据链上执行该票据资产所对应的转移业务。此外，业务对象可以将业务数据信息存储在本地。
其中，4.2)对于票据链上内置的智能合约而言，如图2b所示，内置在票据链上的智能合约可以包含第一票据跨链桥合约和与电子票据生命周期相关联的票据业务合约。这里的票据业务合约具体可以包含图2b所示的用于提供电子票据开票业务的电子票据开具合约，用于提供电子票据流转业务的电子票据流转合约、用于提供电子票据红冲业务的电子票据红冲合约以及用于提供电子票据归档业务的电子票据归档合约。其中，第一票据跨链桥合约可以用于进行票据资产的跨链转移(比如，具体可以将票据资产从票据链转移至应用合约链)，以及跨链读取管理链上为业务对象配置的业务数据信息，来对当前请求跨链转移票据资产的业务对象进行权限查询，比如对业务对象的跨链资产转出权限进行查询。
其中，4.3)对于应用合约链上内置的智能合约而言，如图2b所示，内置在应用合约链上的智能合约可以包含第二票据跨链桥合约，还可以包含由税务衍生业务参与方(即衍生业务对象，例如，图2b所示的税务业务参与方)参与部署的各类合约(例如，图2b所示的虚拟机兼容合约、税务应用合约和衍生业务合约等)。比如，这里的衍生业务合约具体可以为基于电子票据的征信业务合约，通过该征信业务合约可以分析得到某个企业的征信数据。又比如，这里的衍生业务合约具体还可以是为鼓励开票所部署的链上抽奖业务合约和人才激励合约以及退税业务合约等。其中，可以理解的是，这里的第二票据跨链桥合约，可以用于跨链读取管理链上的元数据信息(例如，与退税业务相关联的最新政策规则)，以更新该应用合约链的一些业务参数(例如，可以更新该应用合约链上所部署的退税业务合约的合约参数)，此外，这里的第二票据跨链桥合约，还可以用于进行票据资产的跨链转移(比如，可以将票据资产从票据链转移至应用合约链，以通过这部分跨链转移的电子票据来执行该应用合约链上的衍生业务的业务逻辑，即可以用于跨链读取票据链上针对所请求的衍生业务而授权可见的电子票据)，以及跨链读取管理链上为业务对象配置的业务数据信息，来对当前请求跨链转移票据映射资产的业务对象进行权限查询，比如对业务对象的跨链资产转回权限进行查询。
应当理解，对于上述图2b所示的管理链而言，主要用于处理数据量较小、状态较恒定 的管理性业务流，整个管理链的开放性相对较低，可以用于对一些税务数据进行内部管理。而对于上述图2b所示的票据链而言，可以用于处理一些数据量长期处于高频请求状态的实时票据业务流，该整个票据链的开放性相对较高，可以允许与电子票据本身生命周期中的相关权威机构参与相应的票据业务，比如，可以允许与代理服务商对应的共识节点为当前请求开票的某个用户开具电子票据。此外，对于图2b所示的应用合约链而言，数据量的大小可以无需限定、业务变化的频率波动相对较大，主要是可以通过该应用合约链处理各类合作业务、衍生业务、探索性业务等。应当理解，该应用合约链具有最高的开放性，可以运行由管理链授权的参与者在该应用合约链上部署智能合约、运行探索性的衍生业务等。应当理解，在本申请实施例中，考虑到应用合约链具有较高的开放性和业务变更的灵活性，所以，内置在应用合约链上智能合约在执行时可以有更多的合约安全限制。比如，可以对合约执行步数进行限制(例如，对于上述图2b所示的衍生业务合约而言，可以限定当前业务对象(即上述第二业务对象)具体能够访问衍生业务合约中哪些合约方法)，并可以对访问该衍生业务合约所需要消耗的存储资源数据等进行限制(即应用合约上的智能合约的调用需要消耗一定数量的存储资源数据)。
其中，可以理解的是，本申请实施例所涉及的三链体系下的共识节点可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。
需要说明的是，本申请实施例中的共识节点在跨链获取业务对象(例如，上述个人对象或者企业对象)的链上资产(比如票据资产，具体如电子票据等)等数据时，可以显示提示界面或者弹窗，该提示界面或者弹窗用于提示业务对象当前正在搜集票据资产等数据，仅仅在获取到业务对象对该提示界面或者弹窗发出确认操作后，开始执行数据获取的相关的步骤，否则结束。
此外，可以理解的是，在本申请的具体实施方式中，可能涉及到用户、企业、机构等业务对象的业务数据(例如，用户的开票信息、征信信息、退税信息等，企业的进出亏、企业资质等信息)，当本申请以上实施例运用到具体产品或技术中时，需要获得用户、企业、机构等业务对象的许可或同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
其中，在票据链上执行票据业务的具体过程和在应用合约链上执行与票据业务相关联的衍生业务的具体过程，可以参见如下图3至图11中所示的实施例。此外，为了便于阐述，下述以本申请实施例应用在区块链电子票据系统中为例进行说明，且下述提及的票据链即为第一链、提及的应用合约链即为第二链、提及的管理链即为目标链、提及的电子票据网络即为第一链网络、提及的应用合约网络即为第二链网络、提及的管理链网络即为目标链网络、提及的管理共识节点即为目标共识节点。
图3是本申请实施例提供的一种基于多区块链的资产转移方法的流程图，该方法可以由上述提及的第一链(比如为票据链)对应的第一链网络(比如为电子票据网络)中的第一共识节点来执行，比如，该第一共识节点可以为上述图1所示的共识网络200a中任意一个共识节点。该方法可以包括以下步骤S301-步骤S303：
步骤S301，获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求。
在一些实施例中，第一跨链资产转出请求中携带目标链网络(比如为管理链网络)中的目标共识节点(比如为管理共识节点)为业务对象配置的业务数据信息。其中，业务数据信息是由目标共识节点为业务对象配置的，用于进行权限验证的信息。可选的，该业务数据信息用于进行跨链权限验证。
在一种可能的实施方式中，目标共识节点处存储有为各个业务对象配置的源配置数据信息，该源配置数据信息同样用于进行权限验证。目标共识节点将源配置数据信息发送至各个业务对象后，业务对象将源配置数据信息存储为业务数据信息。后续过程中，目标共识节点 处的源配置数据信息和业务对象处的业务数据信息即可配合实现对业务对象的权限验证。
其中，业务对象可以通过所在的业务节点和多区块链中的任一条区块链进行链上交互，以及进行链上相关业务合约的调用。例如，业务对象可以预先向管理链对应的管理共识节点申请用于进行跨链权限验证的业务数据信息。业务对象在通过业务节点生成第一跨链资产转出请求时，可以从管理链获取业务数据信息，基于获取的业务数据信息生成该针对第一跨链转出交易的第一跨链资产转出请求。或者，也可以是业务对象通过业务节点预先将业务数据信息存储在本地，在生成第一跨链资产转出请求时，可以从本地获取该业务数据信息，以生成该第一跨链资产转出请求。
此外，管理链上可以部署有跨链授权管理合约，因此可以是由业务对象所在的业务节点通过票据管理入口向相关票据部门发送跨链权限申请，由相关票据部门在基于跨链权限申请对业务对象审核通过后，调用管理链上的跨链授权管理合约中的跨链权限申请方法，为业务对象申请跨链权限并为业务对象配置用于验证跨链权限的业务数据信息，在申请成功后将业务数据信息返回给业务对象。另外，管理共识节点可以将业务对象的业务数据信息进行存储，比如存储在管理链中，此时存储在管理共识节点侧的业务数据信息可称为该业务对象的源配置数据信息。业务数据信息比如可以是为业务对象配置的专属授权码、业务对象的身份信息等。
可选的，第一跨链资产转出请求中的第一跨链转出交易用于指示第一共识节点通过跨链中继将指定的属于业务对象的第一资产(比如为票据资产)从票据链转移至与第二共识节点相关联的第二链(比如为应用合约链)。第二共识节点为应用合约链对应的第二链网络(比如为应用合约链网络)中的共识节点。当业务对象需要对指定票据资产执行衍生业务时，可以生成第一跨链资产转出请求以使得指定的票据资产从票据链转移到应用合约链上。例如，第一跨链资产转出请求中的第一跨链转出交易用于指示将业务对象在3个月内的电子发票从票据链转移至应用合约链。该应用合约链对应的应用合约链网络独立于管理链对应的管理链网络和票据链对应的电子票据网络。
在一些实施例中，业务对象在通过业务节点生成第一跨链资产转出请求时，还可以为待转移的票据资产指定资产用途权限，并将该执行的资产用途权限写入第一跨链转出交易中。比如，该资产用途权限可以是只能用于票据红冲业务、可用于票据转移业务等等。
步骤S302，将第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约。
其中，第一共识节点可以将从第一跨链资产转出请求中获取到的第一跨链转出交易的交易数据写入第一跨链桥合约(比如为第一票据跨链桥合约)。该第一票据跨链桥合约可以用于对第一跨链转出交易进行权限验证，并在权限验证通过后进行票据资产的转移流程。
此外，若第一跨链资产转出请求的第一跨链转出交易携带了资产用途权限，则可以在将第一跨链转出交易的交易数据写入第一票据跨链桥合约时，指定该第一跨链转出交易所对应的票据资产的资产用途权限。比如，指定该票据资产在转移后只能用于票据红冲业务。
步骤S303，在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产，并生成第一跨链转出交易对应的第一跨链事件。
其中，第一票据跨链桥合约可以用于对第一跨链转出交易进行权限验证，并在验证通过，确定业务对象具有跨链资产转出权限时，执行票据资产的转移流程。
其中，跨链资产转出权限由目标链网络中的目标共识节点确定，或者，由目标共识节点和第一共识节点共同确定。在一些实施例中，该跨链资源转出权限基于目标共识节点查询得到源配置数据信息和业务数据信息确定得到。
在一种可能的实施方式中，基于第一票据跨链桥合约进行权限验证以确定业务对象是否具有跨链资产转出权限可以是，调用第一票据跨链桥合约中的跨链权限查询方法，生成转出权限验证请求；该转出权限验证请求用于指示管理共识节点调用管理链上的跨链权限管理合约查询业务对象的源配置数据信息，比如可以是调用跨链权限管理合约中的跨链权限查询方 法查询该业务对象是否具有源配置数据信息；进一步，管理共识节点还可以为源配置数据信息设置有效期，若业务对象具有源配置数据信息且处于有效期，则表示查询到源配置数据信息，即可以将该源配置数据信息进行返回；第一共识节点接收管理共识节点基于转出权限验证请求返回的源配置数据信息，并将源配置数据信息和第一跨链转出请求中携带的业务数据信息进行信息比对，得到信息比对结果，进而根据信息比对结果确定业务对象是否具有跨链资产转出权限。比如，可以是通过第一票据跨链桥合约中的信息对比方法对业务数据信息和源配置数据信息进行信息比对。
或者，在另一种可能的实施方式中，基于第一票据跨链桥合约进行权限验证以确定业务对象是否具有跨链资产转出权限，还可以是，调用第一票据跨链桥合约生成携带业务数据信息的转出权限验证请求；该转出权限验证请求用于指示管理共识节点调用管理链上的跨链授权管理合约查询业务对象的源配置数据信息，并对源配置数据信息和转出权限验证请求中的业务数据信息进行信息比对，得到信息对比结果；比如可以是管理共识节点调用管理链上跨链权限管理合约中的跨链权限查询方法查询该业务对象是否具有源配置数据信息，以及调用跨链权限管理合约中的信息对比方法对业务数据信息和源配置数据信息进行信息比对；第一共识节点接收管理共识节点基于转出权限验证请求返回的信息对比结果，并根据信息比对结果确定业务对象是否具有跨链资产转出权限。
可以理解的是，确定业务对象是否具有跨链资产转出权限可以是，若信息比对结果指示对比成功，即表示业务数据信息与源配置数据信息相同，则确定业务对象具备跨链资产转出权限，即确定此时针对票据资产的转移合法；若信息比对结果指示对比不成功，即表示业务数据信息与源配置数据信息不同，则确定业务对象不具备跨链资产转出权限。
其中，应当理解，在确定业务对象具备跨链转出权限时，需要根据第一跨链转出交易对指定的票据资产进行锁定，以确保转移至应用合约链上的票据资产和票据链上的票据资产的一致性，并可以使得该转移的票据资产不受票据链上的其他业务的影响，从而确定第一跨链转出交易对应的转移业务的业务稳定性。
在一些实施例中，对票据资产进行锁定的方式可以是，调用第一资产合约(比如票据资产合约)将票据资产的资产状态由第一状态切换为第二状态。票据资产合约用于管理链上票据资产的全生命周期以及各项票据属性(比如票据资产的资产状态、资产属性状态等)。比如可以是对转移出的票据资产进行锁定以及转移回的票据资产进行解锁。
其中，调用票据资产合约进行资产状态切换可以是通过第一票据跨链桥合约中的资产合约调用方法，调用票据资产合约在票据链上进行票据资产的资产状态切换。该第一状态可以是指正常状态，即指示票据资产处于未被锁定的状态；第二状态可以是指锁定状态，即指示处于票据资产已被锁定的状态。此时，票据链上被锁定的票据资产不能被操作和修改。由此，票据链上所部署的合约(比如第一票据跨链桥合约)具备跨链调用合约(如票据资产合约)的能力。
因此，第一共识节点可以在检测到票据资产的资产状态为第二状态时，调用第一票据跨链桥合约生成第一跨链转出交易对应的第一跨链事件，此时表示第一跨链转出交易在第一共识节点上执行完成。比如可以是调用第一票据跨链桥合约中的事件生成方法，根据第一跨链转出交易生成第一跨链事件。
比如，可以是调用第一票据跨链桥合约上的事件生成方法，利用票据链上的私钥信息对票据资产、票据资产的资产属性状态、以及第一跨链转出交易等信息进行签名，得到第一事件签名信息，并根据第一事件签名信息和前述信息生成第一跨链事件。
此外，若第一共识节点指定了第一跨链转出交易所对应的票据资产的资产用途权限，则调用第一票据跨链桥合约确定资产用途权限对应的权限参数，并在生成第一事件签名信息时，将该权限参数一并进行签名，以及根据该得到的第一事件签名信息和权限参数一齐构建第一跨链事件，即该生成的第一跨链事件中携带该所转移的票据资产对应的权限参数。该权限参数用于表征为票据资产指定的在转移后的资产用途。
应当理解，第一跨链事件用于指示跨链中继在构建得到第一跨链转出交易对应的第一跨链转入交易时，将第一跨链转入交易发送至第二共识节点。该第一跨链转入交易用于指示第二共识节点将票据资产转移到应用合约链上，即该第二共识节点可以用于在将第一跨链转入交易的交易数据写入应用合约链上的第二跨链桥合约(比如为第二票据跨链桥合约)时，调用第二票据跨链桥合约所指示的票据资产映射合约，在应用合约链上铸造与票据资产具有相同资产内容的第二资产(比如为票据映射资产)。因此第一跨链转入交易和第一跨链转出交易用于指示将票据资产从票据链转移至应用合约链。其中，第二共识节点对第一跨链转入交易的执行过程可以参见下述图7所示实施例的相关描述。
此外，跨链中继可以用于隔离应用合约链网络和电子票据网络。跨链中继可以由相关票据部门运营，可以用于持续捕捉票据链与应用合约链之间的跨链事件，以生成对应的跨链交易以提交给另外一条链。因此，跨链中继可以检测票据链的第一票据跨链桥合约所产生的事件，并在检测到第一跨链事件时，从第一共识节点的票据链上获取该第一跨链事件，并基于该第一跨链事件中的第一跨链转出交易、票据资产、资产属性状态、权限参数等信息生成对应的第一跨链转入交易，以实现票据资产的转移。该第一跨链转入交易包含票据资产和交易参数(比如资产属性状态、权限参数等信息)。
应当理解，跨链中继在读取到第一跨链事件时，需要对该第一跨链事件进行事件验证，并在事件验证成功后，生成对应的第一跨链转入交易。比如，第一跨链事件包括第一事件签名信息以及携带的第一事件参数(如第一跨链转出交易、票据资产、资产属性状态、权限参数等信息)。其中，前述涉及的事件验证过程可以是，跨链中继通过票据链的私钥信息对应的公钥信息对第一跨链事件中的第一事件签名信息进行签名验证，并在签名验证成功后得到第一事件签名信息对应的待验证第一事件参数，对携带的第一事件参数和待验证第一事件参数进行事件比对，得到事件对比结果，以确定事件验证结果。
其中，可以理解的是，若携带的第一事件参数和待验证第一事件参数相同，则事件对比结果指示事件验证成功；若携带的第一事件参数和待验证第一事件参数不相同，则事件对比结果指示事件验证不成功。
因此，在执行业务时通过三条区块链相互协作，实现票据资产的转移，可以实现链上转移业务执行的流程更简洁清晰，并可以在链上其他业务可以正常执行下，使得链上转移业务的转移效率更高，从而可以提升转移业务的业务稳定性，进而可以提升在区块链上进行跨链转移票据资产的安全性和可靠性。
例如，图4是本申请实施例提供的一种跨链资产转出的场景示意图；其中，业务对象A通过业务节点预先向管理共识节点申请跨链权限，管理共识节点通过调用管理链上的跨链授权管理合约为业务对象A配置业务数据信息X，并对所配置的业务数据信息进行存储，此时管理共识节点所存储的业务数据信息为源配置数据信息X’。
业务对象A向第一共识节点发送针对第一跨链转出交易的第一跨链资产转出请求；该第一跨链资产转出请求携带业务数据信息X，第一跨链资产转出请求用于指示转移属于业务对象A的票据资产P；此外，还可以由业务对象A指定P在转移后的资产用途权限(比如只能用于红冲等)；比如可以是业务对象A通过业务节点显示的交易配置界面进行第一跨链转出交易的配置以及资产用途权限的指定，业务节点基于业务对象A在交易配置界面的操作生成对应的第一跨链资产转出请求。
第一共识节点将第一跨链转出交易的交易数据写入第一票据跨链桥合约、指定票据资产的资产用途权限，并基于第一票据跨链桥合约和业务数据信息X对业务对象的跨链资产转出权限进行验证，前述对跨链资产转出权限进行验证可以是，通过第一票据跨链桥合约生成转出权限验证请求并发送给管理共识节点，管理共识节点基于转出权限验证请求和跨链权限管理合约查询业务对象A所存储的源配置数据信息X’，第一共识节点对业务数据信息X和源配置数据信息X’进行信息比对，以确定出业务对象是否具有跨链资产转出权限(若X与X’一致则认为具有权限)。若确定业务对象具有跨链资产转出权限，则第一共识节点通过第 一票据跨链桥合约调用票据资产合约锁定票据资产P，并生成对应的第一跨链事件；跨链中继可以检测并读取第一跨链事件，对该第一跨链事件进行事件验证，并在事件验证成功时，生成对应的第一跨链转入交易；该第一跨链转入交易中携带有P、交易参数(比如基于资产用途权限确定的权限参数等)；跨链中继将携带有第一跨链转入交易的第二跨链交易请求发送给第二共识节点，由第二共识节点基于第一跨链转入交易以及第二共识节点上的第二票据跨链桥合约和票据资产映射合约进行P的转移流程。
由此可见，本申请实施例提供了一种基于多区块链的资产转移机制，该基于多区块链的资产转移机制旨在强调可以通过三链的相互协作，实现票据资产的跨链转移，比如，可以在管理链为用户(即前述业务对象)授权配置有上述业务数据信息的情况下，允许用户发起用于将票据资产从票据链转移至应用合约链的转移业务，这里的转移业务即为上述第一跨链转出交易。应当理解，由于本申请实施例所涉及的票据链、管理链和应用合约链彼此相互独立，故而可以分别用于执行不同的业务(比如，可以在票据链上执行与票据资产本身相关的票据业务，而在应用合约链上执行与该票据业务相关联的衍生业务)，从而降低各链上所存储数据的混杂程度。另外，通过多区块链之间的相互协作，还可以在各链上正常执行其他业务时，即不影响其他业务的请求下，实现该转移业务的同步跨链执行，进而可以提升对票据资产进行跨链转移的转移效率。应当理解，本申请实施例在基于多区块链的资产转移过程中，通过链上部署的合约(比如票据链上的第一票据跨链桥合约、票据资产合约等)来协作执行针对该票据资产的转移业务，可以确保链上所执行业务(即跨链转移票据资产的转移业务)不受其他业务的影响，进而可以确保该转移业务的业务稳定性。
在一种可能的实施方式中，票据资产使用完毕后，该票据资产需要由应用合约链重新转移回票据链。下面第一共识节点接收转回资产的过程进行说明。
图5是本申请实施例提供的一种基于多区块链的资产转移方法的流程图，该方法可以由上述提及的第一链(比如为票据链)对应的第一链网络(比如为电子票据网络)中的第一共识节点来执行，比如，该第一共识节点可以为上述图1所示的共识网络200a中任意一个共识节点。该方法可以包括以下步骤S501-步骤S503(可以在步骤S303之后执行)。
步骤S501，接收跨链中继针对第二资产发送的第二跨链转入交易。
其中，可以理解的是，第二跨链转入交易可以是由跨链中继从第二共识节点读取到第二跨链转出交易对应的第二跨链事件时所构建的。第二跨链事件可以是由第二共识节点获取到业务对象针对第二资产(比如为票据映射资产)所提交的第二跨链转出交易生成的。跨链中继可以检测第二共识节点的第二跨链桥合约(比如为第二票据跨链桥合约)上的跨链事件，并在检测到第二跨链事件时从第二共识节点获取该第二跨链事件。跨链中继可以基于第二跨链事件构建第二跨链转出交易对应的第二跨链转入交易。该第二跨链转入交易和第二跨链转出交易用于指示将票据映射资产从应用合约链转移至票据链，也即将票据资产从应用合约链转移回票据链。其中，第二共识节点获取到第二跨链转出交易并生成对应的第二跨链事件的方式可以参见下述图9所示实施例的相关描述，这里将不再继续进行赘述。
可以理解的是，跨链中继在读取第二跨链事件时需要对该第二跨链事件进行事件验证，并在事件验证成功时，生成对应的第二跨链转出交易。其中，对第二跨链事件的事件验证原理和对第一跨链事件的事件验证原理相同。比如，该第二跨链事件包含第二事件签名信息和第二事件参数(比如包括第二跨链转出交易、票据映射资产、映射资产属性状态等信息)，该第二事件签名信息时第二共识节点利用应用合约链上的私钥信息对第二事件参数进行签名所得到的，跨链中继可以利用应用合约链的私钥信息对应的公钥信息对第二事件签名信息进行签名验证，在签名验证成功后获取第二事件签名信息对应的待验证事件参数，并对待验证事件参数和第二跨链事件中的第二事件参数进行事件比对，若待验证事件参数和第二事件参数相同，则表示事件验证成功。
步骤S502，将第二跨链转入交易的交易数据写入第一跨链桥合约，基于第一跨链桥合约对第二跨链转入交易进行交易验证，得到第一交易验证结果。
在一些实施例中，第一共识节点在将第二跨链转入交易的交易数据写入第一跨链桥合约(比如为第一票据跨链桥合约)时，可以对第二跨链转入交易进行交易验证，以验证交易来源正确性。该第一票据跨链桥合约可以用于对第二跨链转入交易进行交易验证，并在交易验证通过后进行第一资产(比如为票据资产)的转移。该第二跨链转入交易可以是跨链中继所发送的第一跨链交易请求中的交易，即跨链中继在将第二跨链转入交易发送至第一共识节点时，是通过生成针对第二跨链转入交易的第一跨链交易请求，并将第一跨链交易请求发送给第一共识节点而实现的。该第一跨链交易请求中携带跨链中继对第二跨链转入交易进行签名所得到的第一交易签名信息。比如可以是由跨链中继通过私钥信息对第二跨链转入交易进行签名得到的第一交易签名信息。
在一些实施例中，第一共识节点将第二跨链转入交易的交易数据写入第一票据跨链桥合约，并基于第一票据跨链桥合约对第二跨链转入交易进行交易验证的方式可以是，将从第一跨链交易请求中获取到的第二跨链转入交易作为待处理交易，并将待处理交易的交易数据写入第一票据跨链桥合约，调用第一票据跨链桥合约获取跨链中继的私钥信息所对应的公钥信息，比如可以是调用第一票据跨链桥合约中的签名验证方法获取公钥信息，可以是获取票据链上预先存储的公钥信息，也可以是从跨链中继上获取公钥信息；根据公钥信息对第一交易签名信息进行签名验证，且在签名验证成功的情况下，将第一交易签名信息对应的第二跨链转入交易作为待验证交易，通过第一票据跨链桥合约对待处理交易和待验证交易进行交易比对，得到第一交易对比结果，将第一交易对比结果作为第一交易验证结果。比如，可以是通过第一票据跨链桥合约中的交易对比方法对待处理交易和待验证交易进行交易比对。
可以理解的是，第一交易签名信息为通过跨链中继的私钥信息对第二跨链转入交易进行加密所得到的，根据跨链中继的私钥信息对应的公钥信息对第一交易签名信息进行签名验证，即通过公钥信息对第一交易签名信息进行解密，若解密成功即表示签名验证成功。其中，前述待验证交易即为通过公钥信息对第一交易签名信息进行解密后所对应得到的第二跨链转入交易。
步骤S503，在第一交易验证结果指示交易验证成功时，通过第一跨链桥合约中的资产合约调用方法，调用第一资产合约在票据链上对锁定的第一资产进行解锁。
应当理解，若基于交易比对确定待验证交易与待处理交易相同，则得到的第一交易验证结果指示交易验证成功，即交易来源正确。若基于交易比对确定待验证交易与待处理交易不同，则得到的第一交易验证结果指示交易验证不成功，即交易来源不正确，可以向跨链中继返回针对第二跨链转入交易的验证失败通知消息，以使跨链中继重新发送第一跨链交易请求。
其中，在确定交易验证成功的情况下，可以通过第一票据跨链桥合约，调用第一资产合约(比如为票据资产合约)在票据链上对锁定的票据资产进行解锁。可以是通过第一票据跨链桥合约直接调用票据资产合约对票据资产进行解锁。或者，票据链上还可以包括票据资产映射合约，可以通过第一票据跨链桥合约调用票据链上的资产映射合约(比如为票据资产映射合约)，并由该票据资产映射合约调用票据资产合约对票据资产进行解锁。
相应的，对锁定的票据资产进行解锁的方式可以是，调用票据资产合约将票据资产的资产状态由第二状态切换为第一状态，此时，应用合约链上的票据映射资产处于第二状态。第一状态用于票据资产此时处于正常状态，可以在票据链上修改和操作该票据资产。比如，可以是对该票据资产进行指定的标准业务逻辑。
此外，可以获取业务对象针对票据资产发送的业务执行请求，在基于业务执行请求确定业务对象具备调用票据链上的票据业务合约的权限时，允许业务对象调用票据业务合约执行票据资产对应的指定业务。其中，前述提及的业务执行请求用于指示对指定的票据资产执行指定业务。当票据资产为电子发票时，指定业务比如可以是电子票据红冲业务、电子票据归档业务等。
相应的，票据链上的票据业务处理合约至少包含：用于执行电子票据红冲业务的电子票 据红冲合约以及用于执行电子票据归档业务的电子票据归档合约等。其中，以电子票据红冲业务为例，电子票据红冲业务用于指示第一共识节点调用票据链上的电子票据红冲合约，开具电子发票对应的红字发票，且红字发票用于更正电子发票中的相关票据信息。
在一些实施例中，确定业务对象具备调用票据业务合约的权限可以是，检测业务执行请求所指示的票据资产的资产状态，若检测到资产状态处于第一状态时，则表示具备调用票据业务合约的权限。若资产状态处于第二状态时，则表示不具备调用票据业务合约的权限。
可选地，第一跨链交易请求中携带有第二跨链事件的事件标识。在对锁定的票据资产进行解锁时，可以调用第一票据跨链桥合约中的事件生成方法，从跨链中继基于第二跨链转入交易所发送的第一跨链交易请求中获取第二跨链事件的事件标识，并生成与事件标识关联的跨链交易完成事件。该跨链交易完成事件用于表征成功将票据资产由应用合约链转移回票据链。
此外，业务对象可以根据票据链上的跨链交易完成事件确定票据映射资产是否转移完成。在一种可能的实施方式中，业务对象可以通过业务节点生成针对第二跨链事件的事件查询请求；该事件查询请求中携带第二跨链事件的事件标识，该第二跨链事件的事件标识可以是业务对象从应用合约链上的第二票据跨链桥合约中获取的；若第一共识节点在接收到事件查询请求时，通过第一票据跨链桥合约中的事件查询方法，查询到第二跨链事件的事件标识关联的跨链交易完成事件，则向业务对象返回针对第二跨链事件的事件完成通知消息。可以理解的是，业务对象接收到该事件完成通知消息时，表示业务对象确定针对票据映射资产的跨链交易完成，可以向第一共识节点发送针对对应票据资产的业务执行请求。
可以理解的是，票据链上的票据资产的资产属性状态为第一属性状态，在应用合约链上所铸造的票据映射资产的映射资产属性状态与票据资产的资产属性状态相同。在确定票据映射资产的映射资产属性状态由第一属性状态变更为第二属性状态时，比如在应用合约链上对票据映射资产执行衍生业务后确定票据映射资产的资产属性状态发生变更，第一共识节点还可以执行如下步骤：在调用票据资产合约在票据链上对锁定的票据资产进行解锁时，将票据资产的资产属性状态由第一属性状态变更为第二属性状态。
其中，第二跨链事件的第二事件参数可以携带有票据映射资产的资产属性状态，因此基于第二跨链事件所生成的第二跨链转入交易携带的交易参数包含票据映射资产的资产属性状态。第一共识节点可以在接收到第二跨链转入交易时根据携带的资产属性状态确定票据映射资产是否发生资产属性状态变更，进而确定票据映射资产对应的票据资产是否需要进行资产属性状态变更。若需要进行变更，则在票据资产进行解锁时，将票据资产的资产属性状态变更为与票据映射资产相同的映射资产属性状态。
此外，资产属性状态可以是指表征票据资产的所属对象的状态，比如第一属性状态可以是票据资产的所属对象为当前的业务对象的状态。第二属性状态可以是指票据资产的所属对象为衍生业务对象的状态。比如，票据资产当前的业务对象可以是企业对象，衍生业务对象可以是企业对象属下的个人对象。例如，票据资产为发票资产，发票资产的业务对象为企业A，在应用合约链上对发票映射资产执行的衍生业务可以是针对发票资产的异常退回业务，若基于前述业务和发票映射资产确定有票据资产存在异常，则可以对该异常的票据资产执行退出流程，即可以是将该异常的票据资产的所属对象从企业A退回至开具该票据资产的个人对象A，也即确定对应的票据映射资产的映射资产属性状态由第一属性状态变更为第二属性状态。也就是说，第一属性状态是指票据资产的所属对象为企业A的状态，第二属性状态是指票据资产的所属对象为个人对象A的状态。此时，处于票据链上的发票资产的资产属性状态也应该存在相应变更，即所属对象进行变更。
或者，资产属性状态可以是指票据资产的票据状态，比如票据资产为发票资产，第一属性状态可以是指发票资产当前的发票状态处于无误状态，第二属性状态可以是指发票资产的发票状态处于红冲状态。例如，票据资产为发票资产，发票资产当前的发票状态为无误状态，在应用合约链上对发票映射资产执行的衍生业务可以是对票据资产执行红冲业务，若基于红 冲业务和发票映射资产确定存在有误的票据资产，则需对该有误的票据资产进行红冲处理，即需要将该票据资产的发票状态从无误状态变更为红冲状态，也即确定对应的票据映射资产的映射资产属性状态由第一属性状态变更为第二属性状态。此时，处于票据链上的发票资产的资产属性状态也应存在相应变更，即票据状态进行变更。
例如，图6是本申请实施例提供的一种跨链资产转入的场景示意图；其中，跨链中继从第二共识节点检测并读取第二跨链事件，在对第一跨链事件进行事件验证成功时，生成对应的第二跨链转入交易；该第一跨链转入交易携带票据映射资产WP和交易参数；跨链中继生成携带第一交易签名信息和第二跨链转入交易的第一跨链交易请求，并将该第一跨链交易请求发送给第一共识节点。第一共识节点接收第一跨链交易请求，进行将票据资产转移回票据链的流程。第一共识节点将第二跨链转入交易的交易数据写入第一票据跨链桥合约，并基于第一交易签名信息对第二跨链转入交易进行交易验证，并在交易验证成功时，通过第一票据跨链桥合约调用票据资产合约对锁定的票据资产P进行解锁。第一共识节点按照第一跨链转入交易中携带的交易参数确定WP的映射资产属性状态是否改变；若WP的映射资产属性状态改变，则对应P的资产属性状态发生相应变更。第一共识节点可以从第一跨链交易请求获取第二跨链事件的事件标识，并生成与该事件标识关联的跨链交易完成事件，通过该跨链交易完成事件可以使得业务对象确定WP转移完成。后续，业务对象可以发送业务执行请求以在票据链上对P执行指定业务。
图7是本申请实施例提供的一种基于多区块链的资产转移方法的流程图，该方法可以由上述提及的第二链(比如为应用合约链)对应的第二链网络(比如为应用合约链网络)中的第二共识节点执行，比如，该第二共识节点可以为上述图1所示的共识网络300a中任意一个共识节点。该方法可以包括以下步骤S701-步骤S703。
步骤S701，获取跨链中继针对第一资产发送的第一跨链转入交易。
其中，第一跨链转入交易是由跨链中继从第一共识节点读取到的第一跨链转出交易对应的第一跨链事件，且对该第一跨链事件进行事件验证成功时所构建的。第一跨链事件是由第一共识节点在基于写入有第一跨链转出交易的第一跨链桥合约(比如为第一票据跨链桥合约)和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用票据链上的第一资产合约(比如为票据资产合约)锁定第一资产(比如为票据资产)时所生成的。前述业务数据信息为管理链网络中的管理共识节点为业务对象所配置的。前述第一共识节点为票据链对应的电子票据网络中的共识节点。
应当理解，第一共识节点可以是在接收到业务对象针对第一跨链转出交易发送的第一跨链资产转出请求，并基于第一票据跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限时，生成对应的第一跨链事件。前述过程的具体方式可以参见上述图3所示实施例的相关描述。
此外，跨链中继可以检测票据链的第一票据跨链桥合约上的票据事件，在检测到第一跨链事件时，从第一共识节点获取该第一跨链事件，进而可以生成该第一跨链事件对应的第一跨链转入交易，以及跨链中继可以将该第一跨链转入交易发送至第二共识节点。其中，跨链中继用于隔离票据链对应的电子票据网络和应用合约链网络，且电子票据网络独立于管理链网络和应用合约链网络。
步骤S702，将第一跨链转入交易的交易数据写入应用合约链上的第二票据跨链桥合约。
其中，第一跨链转入交易可以是跨链中继所发送的第二跨链交易请求中的交易，即跨链中继在将第一跨链转入交易发送至第二共识节点时，是通过生成针对第一跨链转入交易的第二跨链资产转出请求，并将第二跨链资产转出请求发送给第二共识节点而实现的。第二共识节点可以将从第二跨链资产转出请求中获取到的第一跨链转入交易的交易数据写入第二票据跨链桥合约。
步骤S703，调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
其中，此处的铸造资产过程指在第二链上创建一个用于存储资产内容的区块，且该区块中存储的资产内容与第一资产的资产内容一致，即在第二链上铸造第二资产也可以表示在在第二链上创建第二资产。
其中，调用第二资产合约(比如为票据资产映射合约)铸造第二资产(比如为票据映射资产)可以是，在调用第二跨链桥合约(比如为第二票据跨链桥合约)执行第一跨链转入交易时，对第一跨链转入交易进行交易验证，得到第二交易验证结果。在第二交易验证结果指示交易验证成功时，调用第二票据跨链桥合约所指示的票据资产映射合约，在应用合约链上铸造与票据资产具有相同资产内容的票据映射资产。比如可以是通过第二票据跨链桥合约中的资产映射合约调用方法，调用票据资产映射合约进行票据映射资产的铸造。该调用第二票据跨链桥合约执行第一跨链转入交易可以是指将第一跨链转入交易的交易数据写入第二票据跨链桥合约。
因此，第二票据跨链桥合约可以用于在写入第一跨链转入交易时，对第二跨链转入交易进行交易验证，并在交易验证通过后进行票据资产的转移。票据资产映射合约可以用于进行票据资产对应的票据映射资产的铸造。铸造的票据映射资产与票据资产相同，可以在应用合约链上被操作。由此，应用合约链链上所部署的合约(比如第二票据跨链桥合约)具备跨链调用合约(如票据映射资产合约)的能力。
应当理解，第二跨链交易请求中可以携带对第一跨链转入交易进行签名所得到的第二交易签名信息。比如可以是由跨链中继通过私钥信息对第一跨链转入交易进行加密所对应得到的第二交易签名信息。对第一跨链转入交易进行交易验证的过程可以是，将从第二跨链交易请求中获取到的第一跨链转入交易作为参考交易，调用第二票据跨链桥合约中的签名验证方法获取跨链中继的私钥信息所对应的公钥信息，比如可以是调用第二票据跨链桥合约中的签名验证方法获取公钥信息；根据公钥信息对第二交易签名信息进行签名验证，且在签名验证成功时，将第二交易签名信息对应的第一跨链转入交易作为待匹配交易，通过第二票据跨链桥合约对参考交易和待匹配交易进行交易比对，得到第二交易对比结果，并将第二交易对比结果作为第二交易验证结果。比如，可以是通过第二票据跨链桥合约中的交易对比方法对参考交易和待匹配交易进行交易比对。
其中，根据公钥信息对第二交易签名信息进行签名验证，即通过公钥信息对第二交易签名信息进行解密，若解密成功即表示签名验证成功。上述待匹配交易即为通过公钥信息对第二交易签名信息进行解密后所对应得到的第二跨链转入交易。
因此，若基于交易比对确定参考交易和待匹配交易相同，则得到的第二交易验证结果指示交易验证成功，即交易来源正确。若基于交易比对确定参考交易和待匹配交易不同，则得到的第二交易验证结果指示交易验证不成功，即交易来源不正确，可以向跨链中继返回针对第一跨链转入交易的验证失败通知消息，以使跨链中继重新发送第二跨链交易请求。
应当理解，在确定交易验证成功时，可以通过第二票据跨链桥合约，调用票据资产映射合约，铸造票据资产对应的票据映射资产。在铸造票据映射资产时，基于第一跨链转入交易配置票据映射资产的状态。比如将票据映射资产的资产状态配置为第一状态，表示票据映射资产当前处于正常状态。又如，可以根据第一跨链转入交易携带的资产属性状态为票据映射资产配置相同的映射资产属性状态。此时，可以在应用合约链上对铸造完成的票据映射资产执行衍生业务逻辑，比如征信识别、红冲等。
此外，第二跨链交易请求中携带有第一跨链事件的事件标识。在应用合约链上铸造与票据资产具有相同资产内容的票据映射资产时，第二共识节点可以调用第二票据跨链桥合约中的事件生成方法，从跨链中继基于第一跨链转入交易所发送的第二跨链交易请求中获取第一跨链事件的事件标识，并可以在票据映射资产铸造完成时，生成与事件标识关联的跨链交易完成事件。跨链交易完成事件用于表征成功将票据资产由票据链转移至应用合约链。
可以理解的是，业务对象可以根据该跨链交易完成事件确定票据资产是否转移完成。在一种可能的实施方式中，获取业务对象通过业务节点针对第一跨链事件发送的事件查询请 求，事件查询请求中携带第一跨链事件的事件标识，该第一跨链事件的事件标识可以是业务对象从应用合约链上的第一票据跨链桥合约中获取的；若通过第二票据跨链桥合约中的事件查询方法，查询到事件标识关联的跨链交易完成事件，则向业务对象返回针对第一跨链事件的事件完成通知消息。因此，业务对象接收到该事件完成通知消息时，表示检测到针对票据资产的跨链交易完成，后续可以向第二共识节点发送针对票据映射资产的业务执行请求。
此外，若第一共识节点为票据资产指定了资产用途权限，则跨链中继所生成的第一跨链转入交易携带有基于对应的票据资产的资产用途权限所确定的权限参数。权限参数用于为票据映射资产进行对应资产用途权限的限制，即基于权限参数为票据映射资产指定相同的资产用途权限。应用合约链上的票据映射资产仅能执行该权限参数所指示的资产用途。比如，基于权限参数确定执行的衍生业务为进行票据映射资产的所属对象变更业务，则在应用合约链上仅能对该票据映射资产执行该衍生业务。
因此，第二共识节点可以获取业务对象基于事件完成通知消息发送的衍生业务执行请求，基于衍生业务执行请求中的衍生业务，调用第二票据跨链桥合约获取第一跨链转入交易中的交易参数；在基于前述交易参数确定业务对象具备调用应用合约链上的衍生业务合约的权限的情况下，允许业务对象调用衍生业务合约执行所述票据映射资产所对应的衍生业务。其中，第一跨链转入交易中的交易参数可以包括权限参数、资产映射状态等。基于交易参数确定业务对象是否具备调用衍生业务合约的权限可以是基于交易参数中的权限参数确定业务对象是否具备调用衍生业务合约的权限。
其中，确定业务对象具备调用应用合约链上的衍生业务合约的权限可以是，检测衍生业务执行请求所指示的衍生业务是否为权限参数所指示的衍生业务，若衍生业务执行请求所指示的衍生业务为权限参数所指示的衍生业务，则表示具备调用衍生业务合约的权限。
示例性地，交易参数中的权限参数可以包含资产转移参数。该资产转移参数用于指示将票据映射资产由业务对象转移至与业务对象相关联的衍生业务对应的衍生业务对象。若确定业务对象具备调用应用合约链上的衍生业务合约的权限，可以调用衍生业务合约执行票据映射资产对应的衍生业务；在执行衍生业务时，若基于资产转移参数确定将票据映射资产由业务对象转移至衍生业务对象，则在应用合约链上将票据映射资产的映射资产属性状态由第一属性状态变更为第二属性状态。其中，映射资产属性状态可以是指票据映射资产的所属对象的状态。比如，第一属性状态可以是表征票据资产的所属对象为当前的业务对象的一种状态，第二属性状态可以是表征票据资产的所属对象为衍生业务对象的一种状态。
因此，可以对票据映射资产执行衍生业务，以及基于资产转移参数确定是否将票据资产从业务对象转移至衍生业务对象，即资产转移参数指示针对票据映射资产的所属对象变更业务。在确定要进行对象转移时，对票据映射资产的映射资产属性状态进行变更。上述第二属性状态是基于资产转移参数所指示的衍生业务对象确定的。例如，票据资产为发票资产，衍生业务为针对发票资产的异常退回业务，该资产转移参数用于指示该衍生业务以及指示该衍生业务可以用于将票据映射资产的所属业务对象变更至衍生业务对应的衍生业务对象，比如指示从企业对象变更为个人对象。
示例性地，交易参数中的权限参数可以包含票据状态转移参数。该票据状态转移参数用于指示将票据映射资产的票据状态由无误状态变更至衍生业务(比如红冲业务)对应的红冲状态。若确定业务对象具备调用应用合约链上的衍生业务合约的权限，可以调用衍生业务合约执行票据映射资产对应的衍生业务；在执行衍生业务时，若基于票据状态转移参数确定将票据映射资产的票据状态变更至红冲状态，则在应用合约链上将票据映射资产的映射资产属性状态由第一属性状态变更为第二属性状态。其中，映射资产属性状态可以是指票据映射资产的票据状态，第一属性状态可以是指票据资产处于无误状态，第二属性状态可以是指票据资产处于红冲状态。
因此，可以对票据映射资产执行衍生业务，以及基于票据状态转移参数确定是否对票据资产的票据状态进行变更，并在确定要进行票据状态变更时，对票据映射资产的映射资产属 性状态进行变更。该第二属性状态是基于资产转移参数所指示的红冲状态确定。例如，票据资产为发票资产，衍生业务为针对发票资产的红冲业务，该票据状态转移参数用于指示该衍生业务以及指示该衍生业务可以用于将票据映射资产的票据状态变更至对应的红冲状态。
例如，图8是本申请实施例提供的一种跨链资产转入的场景示意图；其中，跨链中继从第一共识节点检测并读取第一跨链事件，并在对第一跨链事件进行事件验证成功时，生成对应的第一跨链转入交易；该第一跨链转入交易携带票据资产P和交易参数；跨链中继生成携带第二交易签名信息和第一跨链转入交易的第二跨链交易请求，并将该第二跨链交易请求发送给第二共识节点；第二共识节点将第一跨链转入交易的交易数据写入第二票据跨链桥合约，并基于第二交易签名信息对第一跨链转入交易进行交易验证；在交易验证成功时，通过第二票据跨链桥合约调用票据资产映射合约，为P在应用合约链上铸造与P相同的票据映射资产WP，并获取第一跨链转入交易中的交易参数，以用于为票据映射资产赋予交易参数所指示的资产用途权限，即指定WP的资产用途权限，比如将交易参数中的权限参数写入票据映射资产合约，或者将权限参数对应的资产用途权限写入票据映射资产合约；第二共识节点可以从第二跨链交易请求获取第一跨链事件的事件标识，并生成与该事件标识关联的跨链交易完成事件，通过该跨链交易完成事件可以使得业务对象确定P转移完成；业务对象可以在应用合约链上对WP执行指定的衍生业务，比如可以是业务对象通过业务节点生成针对WP的衍生业务执行请求，并发送给第二共识节点，第二共识节点基于衍生业务执行请求所指示的衍生业务和交易参数确定业务对象是否具备调用应用合约链上的衍生业务合约的权限，并在确定具备该权限时，对WP执行该所指示的衍生业务。例如，衍生业务执行请求所指示的衍生业务为红冲业务，若基于交易参数确定WP的资产用途权限为红冲业务，则表示具备调用该红冲业务相关联的衍生业务合约的权限；若基于交易参数确定WP的资产用途权限不包括红冲业务，则表示不具备调用该红冲业务相关联的衍生业务合约的权限。
在一种可能的实施方式中，票据资产使用完毕后，该票据资产需要由应用合约链重新转移回票据链。下面对第二共识节点进行资产转回的过程进行说明。
图9是本申请实施例提供的一种基于多区块链的资产转移方法的流程图，如图9所示，该方法可以由上述提及的第二链(比如为应用合约链)对应的第二链网络(比如为应用合约链网络)中的第二共识节点执行，比如，该第二共识节点可以为上述图1所示的共识网络300a中任意一个共识节点。该方法可以包括以下步骤S901-步骤S903。
步骤S901，获取业务对象针对第二跨链转出交易发送的第二跨链资产转出请求。
其中，第二跨链资产转出请求中携带业务数据信息。该业务数据信息用于对业务对象的跨链资产转回权限进行权限验证，确保业务对象的第二资产(比如为票据映射资产)转移合法性。上述第二跨链资产转出请求用于指示第二共识节点通过跨链中继将票据映射资产从应用合约链转移回票据链。可以理解的是，当业务对象需要在对票据映射资产执行完衍生业务后，可以生成第二跨链资产转出请求以使得指定的票据映射资产从应用合约链转移到票据链上。
应当理解，业务对象在通过业务节点生成第二跨链资产转出请求时，可以从管理链获取业务数据信息，基于获取的业务数据信息生成该针对第二跨链转出交易的第二跨链资产转出请求。或者，也可以是业务对象通过业务节点预先将业务数据信息存储在本地，在生成第二跨链资产转出请求时，可以从本地获取该业务数据信息，以生成该第二跨链资产转出请求。
步骤S902，将第二跨链资产转出请求中携带的第二跨链转出交易的交易数据写入应用合约链上的第二跨链桥合约。
步骤S903，在基于第二跨链桥合约和业务数据信息确定业务对象具备跨链资产转回权限时，调用第二资产合约锁定第二资产，且生成第二跨链转出交易对应的第二跨链事件。
其中，第二票据跨链桥合约可以用于对第二跨链资产转出请求进行业务对象的跨链资产转回权限的权限验证，在权限验证成功后确定业务对象具有跨链资产转回权限，并继续执行票据映射资产的转回流程。
其中，跨链资产转回权限由目标链网络中的目标共识节点确定，或者，由目标共识节点和第二共识节点共同确定。在一些实施例中，该跨链资源转回权限基于目标共识节点查询得到源配置数据信息和业务数据信息(携带在第二跨链资产转出请求中)确定得到。
因此，基于第二跨链桥合约(比如为第二票据跨链桥合约)进行跨链资产转回权限的权限验证可以是，调用第二票据跨链桥合约中的跨链权限查询方法，生成转回权限验证请求；该转回权限验证请求用于指示管理共识节点调用管理链上的跨链权限管理合约查询业务对象的源配置数据信息，比如可以是调用跨链权限管理合约中的跨链权限查询方法查询该业务对象是否具有源配置数据信息；接收管理共识节点基于转出权限验证请求返回的源配置数据信息，将源配置数据信息和第二跨链资产转出请求中携带的业务数据信息进行信息比对，得到信息比对结果，根据信息比对结果确定业务对象是否具有跨链资产转回权限。比如，可以是通过第二票据跨链桥合约中的信息对比方法对业务数据信息和源配置数据信息进行信息比对。
或者，基于第二票据跨链桥合约进行权限验证以确定业务对象是否具有跨链资产转出权限，可以是，调用第二票据跨链桥合约生成携带业务数据信息的转回权限验证请求，该转回权限验证请求用于指示管理共识节点调用管理链上的跨链授权管理合约查询业务对象的源配置数据信息，并对源配置数据信息和转回权限验证请求中的业务数据信息进行信息比对，得到信息对比结果。比如可以是调用跨链权限管理合约中的跨链权限查询方法查询该业务对象是否具有源配置数据信息；由管理共识节点调用跨链权限管理合约中的信息对比方法对业务数据信息和源配置数据信息进行信息比对；第二共识节点可以接收管理共识节点基于转回权限验证请求返回的信息对比结果，并根据信息比对结果确定业务对象是否具有跨链资产转回权限。
应当理解，确定业务对象是否具有跨链资产转回权限可以是，若信息比对结果指示对比成功，即业务数据信息与源配置数据信息相同，则确定业务对象具备跨链资产转回权限；即确定此时针对票据映射资产的转移合法；若信息比对结果指示对比不成功，即业务数据信息与源配置数据信息不同，则确定业务对象不具备跨链资产转回权限。
在一些实施例中，在确定业务对象具备跨链转出权限时，需要根据第二跨链转出交易对票据映射资产进行锁定，以确保转移至票据链上的票据映射资产和应用合约链上的票据映射资产的一致性。对票据映射资产进行锁定的具体方式可以是，调用票据资产映射合约将票据映射资产的资产状态由第一状态切换为第二状态。票据资产映射合约用于管理链上票据资产的资产状态。比如可以是对转移出的票据映射资产进行锁定。
其中，调用第二资产合约(比如为票据资产映射合约)进行资产状态切换可以是通过第二票据跨链桥合约中的资产合约调用方法，调用票据资产映射合约在应用合约链上进行票据映射资产的资产状态切换。该第一状态可以是指正常状态，即指示票据映射资产未被锁定；第二状态可以是指锁定状态，即指示票据映射资产已被锁定。此时，应用合约链上被锁定的票据映射资产不能被操作和修改。
因此，第二共识节点可以在检测到票据映射资产的资产状态为第二状态时，调用生成第二跨链转出交易对应的第二跨链事件，此时表示第二跨链转出交易在第二共识节点上执行完成。比如可以是调用第二票据跨链桥合约中的事件生成方法生成第二跨链事件。该第二跨链事件可以携带有票据映射资产、票据映射资产当前的资产属性状态等信息。
其中，第二跨链事件用于指示跨链中继在构建得到第二跨链转出交易对应的第二跨链转入交易时，将第二跨链转入交易发送至第一共识节点。该第二跨链转入交易用于指示第一共识节点将票据映射资产转移到票据链上，即该第一共识节点可以用于在将第二跨链转入交易的交易数据写入票据链上的第一票据跨链桥合约时，调用第一票据跨链桥合约所指示的票据资产合约，在票据链上对锁定的票据资产进行解锁。即将票据资产的资产状态从第二状态变更为第一状态。因此第二跨链转入交易和第二跨链转出交易用于指示将票据映射资产从应用合约链转移至票据链。其中，第一共识节点对第二跨链转入交易的执行过程可以参见上述图 5所示实施例的相关描述。
此外，跨链中继可以检测应用合约链的第二票据跨链桥合约所产生的票据事件，并在检测到第二跨链事件时，从第二共识节点的应用合约链上获取该第二跨链事件；在对第二跨链事件进行事件验证成功时，基于该第二跨链事件中的票据映射资产、资产属性状态等信息生成第二跨链转入交易，以实现票据映射资产的转移。
因此，第二共识节点可以在检测到第二跨链事件生成时，调用票据资产映射合约将锁定的票据映射资产进行销毁。或者，也可以是跨链中继在第一共识节点的第一票据跨链桥合约上检测到与第二跨链事件关联的跨链交易完成事件时，向第二共识节点发送跨链完成通知消息。由第二共识节点在接收到跨链完成通知消息时，调用票据资产映射合约将锁定的票据映射资产进行销毁。比如，是通过第二票据跨链桥合约中的资产映射合约调用方法对锁定的票据映射资产进行销毁。
例如，图10是本申请实施例提供的一种跨链资产转出的场景示意图；其中，业务对象A向第二共识节点发送针对第二跨链转出交易的第二跨链资产转出请求，该第二跨链资产转出请求携带业务数据信息X；第二共识节点基于第二票据跨链桥合约和X对业务对象的跨链资产转入权限进行验证，其具体可以是，通过第二票据跨链桥合约生成转回权限验证请求并发送给管理共识节点，管理共识节点基于转回权限验证请求和跨链权限管理合约查询业务对象A所存储的源配置数据信息X’；第二共识节点对X和X’进行信息比对，以确定出业务对象具有跨链资产转回权限；第二共识节点通过第二票据跨链桥合约调用票据资产映射合约锁定票据映射资产WP，并生成对应的第二跨链事件；跨链中继可以检测并读取第二跨链事件，并生成对应的第二跨链转入交易，该第二跨链转入交易中携带有WP、交易参数(比如映射资产属性状态等)；跨链中继将携带有第二跨链转入交易的第一跨链交易请求发送给第一共识节点，由第一共识节点基于第二跨链转入交易以及票据链上的第一票据跨链桥合约和票据资产合约进行WP的转移流程；后续，跨链中继可以从第一共识节点的票据链上的第一票据跨链桥合约中检测并读取到第二跨链事件的事件标识关联的跨链交易完成事件，并向第二共识节点返回跨链完成通知消息，由第二共识节点对锁定的WP进行销毁。
图11是本申请实施例提供的一种基于多区块链的资产转移方法的流程图，如图11所示，该方法可以由上述第一链网络中的第一共识节点、第二链网络中的第二共识节点、跨链中继执行。比如，这里的第一共识节点可以为上述图1所示的共识网络200a中任意一个共识节点，第二共识节点可以为上述图1所示的共识网络300a中任意一个共识节点。应当理解，第一链网络、第二链网络、目标链网络各自独立，且跨链中继用于隔离第一链网络和第二链网络；此时，该方法可以包括以下步骤S1101-步骤S1107。
步骤S1101，第一共识节点获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求。
其中，业务对象可以预先向管理链网络中的管理共识节点申请用于进行权限验证的业务数据信息，比如由管理共识节点调用管理链上的跨链权限管理合约为业务对象配置专属的授权码，以作为业务数据信息。以及可以针对携带业务数据信息的第一跨链资产转出请求。该第一跨链资产转出请求用于指示将业务对象的票据资产从票据链转移至应用合约链。
步骤S1102，第一共识节点将第一跨链资产转出请求中携带的第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约。
步骤S1103，第一共识节点在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限时，调用第一链上的第一资产合约锁定第一资产，并生成第一跨链转出交易对应的第一跨链事件。
其中，第一共识节点可以在写入第一跨链转出交易时，基于第一跨链桥合约(比如为第一票据跨链桥合约)和业务数据信息确定业务对象是否具备跨链资产转出权限。比如可以是，调用第一票据跨链桥合约生成针对业务对象的转出权限验证请求，并将转出权限验证请求发送给管理共识节点，由管理共识节点调用管理链上的跨链授权管理合约查询业务对象的源配 置数据信息；第一共识节点接收管理共识节点返回的源配置数据信息，并对源配置数据信息和第一资产转出请求中的业务数据信息进行信息比对，若信息比对结果指示对比成功，则确定业务对象具备跨链资产转出权限。
因此，可以通过第一票据跨链桥合约，调用票据链上的第一资产合约(比如为票据资产合约)锁定第一资产(比如为票据资产)，并调用第一票据跨链桥合约生成第一跨链转出交易对应的第一跨链事件。该第一跨链事件携带的事件参数比如可以包括锁定的票据资产、资产属性状态、基于指定的资产用途权限所确定的权限参数等信息。
步骤S1104，跨链中继获取第一跨链事件。
步骤S1105，跨链中继基于第一跨链事件构建第一跨链转出交易对应的第一跨链转入交易。
其中，跨链中继可以检测并获取第一共识节点上的第一票据跨链桥合约上的第一跨链事件，并基于第一跨链事件中的携带的信息构建第一跨链转入交易。该第一跨链转入交易携带锁定的票据资产和交易参数。该交易参数可以包括资产属性状态、权限参数等信息。
步骤S1106，跨链中继将第一跨链转入交易发送至第二共识节点。
其中，跨链中继可以生成携带第一跨链转入交易的第二跨链交易请求，并将该第二跨链交易请求发送至第二共识节点，以实现将第一跨链转入交易发送至第二共识节点。该第二跨链交易请求中可以携带跨链中继通过私钥信息对第一跨链转入交易进行签名所得到的第二交易签名信息。
步骤S1107，第二共识节点在将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约时，调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
其中，第二共识节点在从第二跨链交易请求中获取第一跨链转入交易，并写入应用合约链上的第二跨链桥合约(比如为第二票据跨链桥合约)时，可以基于第二交易签名信息对第一跨链转入交易进行交易验证，并在交易验证成功时，调用第二资产合约(比如为票据资产映射合约)，铸造第二资产(比如为票据映射资产)。此外，还可以基于第一跨链转入交易中的交易参数为票据映射资产设置相应的资产映射状态、映射资产属性状态、以及资产用途权限等。其中，进行交易验证的具体方式可以参见上述实施例的相关描述。
此外，第二跨链交易请求还携带了第一跨链事件的事件标识，在铸造票据映射资产完成时，可以调用第二票据跨链桥合约生成该事件标识关联的跨链交易完成事件，以表征成功将票据资产由票据链转移至应用合约链。业务对象可以通过该跨链交易完成事件确定票据资产是否转移完成，并在确定转移完成后发送针对票据映射资产的衍生业务执行请求，以在应用合约链上对票据映射资产执行指定衍生业务。
例如，图12是本申请实施例提供的一种基于多区块链的资产转移方法的流程图；图12可以表征将第二资产从第二链转移回第一链的执行过程该过程可以是：S1、第二共识节点获取业务对象针对第二跨链转出交易发送的第二跨链资产转出请求；该第二跨链资产转出请求携带有业务数据信息；S2、第二共识节点将第二跨链资产转出请求中携带的第二跨链转出交易的交易数据写入第二链上的第二跨链桥合约；S3、第二共识节点在基于第二跨链桥合约和业务数据信息确定业务对象具备跨链资产转回权限时，调用第二链上的第二资产合约锁定第二资产，且生成第二跨链转出交易对应的第二跨链事件；该第二共识节点确定业务对象的跨链资产转回权限的具体原理可以同第一共识节点确定业务对象的跨链资产转出权限的原理；S4、跨链中继获取第二跨链事件；S5、跨链中继基于第二跨链事件构建第二跨链转出交易对应的第二跨链转入交易；第二跨链转入交易可以携带锁定的第二资产和交易参数，该交易参数可以包括资产属性状态等信息；S6、跨链中继将第二跨链转入交易发送至第一共识节点；比如可以是，跨链中继生成携带第二跨链转入交易的第一跨链交易请求，并将该第一跨链交易请求发送至第一共识节点，以实现将第二跨链转入交易发送至第一共识节点；前述第一跨链交易请求中可以携带跨链中继通过私钥信息对第二跨链转入交易进行签名所得到的第一 交易签名信息；S7、第一共识节点在将第二跨链转入交易的交易数据写入第一链上的第一跨链桥合约时，调用第一跨链桥合约所指示的第一资产合约，在第一链上对锁定的第一资产进行解锁；第一共识节点可以基于第一交易签名信息对第二跨链转入交易进行交易验证，并在交易验证成功时对锁定的第一资产进行解锁；此外，可以进一步基于第二跨链转入交易中的交易参数确定第二资产的映射资产属性状态是否需要变更，比如基于交易参数中的映射资产属性状态确定第二资产发生了变更，便对解锁的第一资产的资产属性状态进行相应变更。此外，第一跨链交易请求还携带了第二跨链事件的事件标识，在解锁第一资产完成时，可以调用第一跨链桥合约生成该事件标识关联的跨链交易完成事件，以表征成功将第二资产由第二链转移至第一链。第二共识节点可以在接收到由跨链中继基于该跨链交易完成事件生成的跨链完成通知消息时对锁定的第二资产进行销毁。后续，业务对象可以通过该跨链交易完成事件确定第二资产是否转移完成，并在确定转移完成后向第一共识节点发送针对第一资产的业务执行请求，以在第一链上对第一资产执行指定业务。
其中，图11所示实施例的具体实现方式，可以参见上述图3、图5、图7、图9所对应实施例中的具体描述，这里将不再继续进行赘述。
基于上述描述，将电子票据区块链系统改进为三个共识网络，由三个共识网络分别维护管理链、票据链和应用合约链。该三条链具备的功能特性不同，互相结合，形成了一个针对链上数据的管理更简洁、流程更清晰高效、业务扩展性更好的区块链系统。本申请技术方案提出的链上资产跨链协议可以使得票据资产在三条链间进行更好的传递和使用，并创造更多的业务价值。该票据资产跨链协议通过对转移出的票据资产(或票据映射资产)进行锁定，实现票据资产在链间传递时的一致性，保证了在多链架构下，链上数据的数据内容和数据状态的正确性。此外，可以使得在应用合约链上通过衍生业务合约对票据资产执行衍生业务时，不影响票据链上的业务稳定性，且使得在执行衍生业务时无法访问票据链上与衍生业务不相关的链上数据，从而实现了很好的数据隔离性和业务安全性。
图13是本申请实施例提供的一种基于多区块链的资产转移装置的结构示意图。如图13所示，基于多区块链的资产转移装置1可应用于第一共识节点中，该第一共识节点可以为第一链网络(例如，上述共识网络300a)中任意一个区块链节点，例如，该第一共识节点可以为上述图1所对应实施例中的共识节点11c。应当理解，该基于多区块链的资产转移装置1可以是运行于区块链节点(比如，前述共识节点10c)中的一个计算机程序(包括程序代码)，例如该基于多区块链的资产转移装置1可以为一个应用软件；可以理解的是，该基于多区块链的资产转移装置1可以用于执行本申请实施例提供的方法中的相应步骤。如图13所示，基于多区块链的资产转移装置1可以包括：获取模块11、写入模块12和调用模块13；
获取模块11，用于获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求；该第一跨链资产转出请求中携带有为业务对象配置的业务数据信息，业务数据信息由目标链网络中的目标共识节点配置；该第一跨链资产转出请求用于指示第一共识节点通过跨链中继将属于业务对象的第一资产从第一链转移至与第二共识节点相关联的第二链；该第二共识节点为第二链对应的第二链网络中的共识节点；跨链中继用于隔离第二链网络和第一链网络，且第二链网络独立于目标链网络和第一链网络；
写入模块12，用于将第一跨链转出交易的交易数据写入第一链上的第一跨链桥合约；
调用模块13，用于在基于第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产，并生成第一跨链转出交易对应的第一跨链事件；第一跨链事件用于指示跨链中继在构建得到第一跨链转出交易对应的第一跨链转入交易时，将第一跨链转入交易发送至第二共识节点；该第二共识节点用于在将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约时，调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
其中，调用模块13包括：
转出权限验证单元131，用于调用第一跨链桥合约中的跨链权限查询方法，生成转出权 限验证请求；转出权限验证请求用于指示管理共识节点调用目标链上的跨链授权管理合约查询业务对象的源配置数据信息；
信息接收单元132，用于接收管理共识节点返回的源配置数据信息，将源配置数据信息和业务数据信息进行信息比对，得到信息对比结果；
信息比对单元133，用于若信息比对结果指示对比成功，则确定业务对象具备跨链资产转出权限；
跨链事件生成单元134，用于调用第一资产合约将第一资产的资产状态由第一状态切换为第二状态，并在第一资产的资产状态为第二状态时生成第一跨链转出交易对应的第一跨链事件。
其中，获取模块11包括：
接收单元111，用于接收跨链中继针对第二资产发送的第二跨链转入交易；第二跨链转入交易是由跨链中继从第二共识节点读取到第二跨链转出交易对应的第二跨链事件时所构建的，第二跨链事件由第二共识节点获取到业务对象针对第二资产所提交的第二跨链转出交易生成的；
写入模块12，还用于将第二跨链转入交易的交易数据写入第一跨链桥合约，基于第一跨链桥合约对第二跨链转入交易进行交易验证，得到第一交易验证结果；
调用模块13，还用于在第一交易验证结果指示交易验证成功的情况下，通过第一跨链桥合约中的资产合约调用方法，调用第一资产合约在第一链上对锁定的第一资产进行解锁。
其中，第二跨链转入交易为跨链中继所发送的第一跨链交易请求中的交易；第一跨链交易请求中携带跨链中继通过私钥信息对第二跨链转入交易进行签名所得到的第一交易签名信息；
写入模块12包括：
交易的交易数据写入单元121，用于将从第一跨链交易请求中获取到的第二跨链转入交易作为待处理交易，将待处理交易的交易数据写入第一跨链桥合约；
签名验证单元122，用于调用第一跨链桥合约中的签名验证方法获取跨链中继的私钥信息所对应的公钥信息，根据公钥信息对第一交易签名信息进行签名验证；在签名验证成功的情况下，将第一交易签名信息对应的第二跨链转入交易作为待验证交易；
交易比对单元123，用于通过第一跨链桥合约中的交易对比方法对待处理交易和待验证交易进行交易比对，得到第一交易对比结果，将第一交易对比结果作为第一交易验证结果。
其中，第一资产的资产属性状态为第一属性状态；在第二资产的映射资产属性状态由第一属性状态变更为第二属性状态时，调用模块13包括：
属性状态变更单元135，用于在调用第一资产合约在第一链上对锁定的第一资产进行解锁时，将第一资产的资产属性状态由第一属性状态变更为第二属性状态。
其中，写入模块12，还用于在将第一跨链转出交易的交易数据写入第一跨链桥合约时，指定第一跨链转出交易所对应的第一资产的资产用途权限。
其中，获取模块11、写入模块12和调用模块13的具体实现方式，可以参见上述实施例的描述，这里将不再继续进行赘述。应当理解，对采用相同方法所得到的有益效果描述，也不再进行赘述。
图14是本申请实施例提供的一种基于多区块链的资产转移装置的结构示意图。如图14所示，多区块链的资产转移装置2可应用于第二共识节点中，该第二共识节点可以为第二链网络(例如，上述共识网络300a)中任意一个区块链节点，例如，该第二共识节点可以为上述图1所对应实施例中的共识节点12c。应当理解，该基于多区块链的资产转移装置2可以是运行于区块链节点(比如，前述共识节点12c)中的一个计算机程序(包括程序代码)，例如该基于多区块链的资产转移装置2可以为一个应用软件；可以理解的是，该基于多区块链的资产转移装置2可以用于执行本申请实施例提供的方法中的相应步骤。如图14所示，基于多区块链的资产转移装置2可以包括：处理模块21，资产铸造模块22；
处理模块21，用于获取跨链中继针对第一资产发送的第一跨链转入交易；该第一跨链转入交易是由跨链中继从第一共识节点读取到第一跨链转出交易对应的第一跨链事件时所构建的；该第一跨链事件是由第一共识节点在基于写入有第一跨链转出交易的第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用第一链上的第一资产合约锁定第一资产时所生成的；该业务数据信息为目标链网络中的管理共识节点为业务对象所配置的；该第一共识节点为第一链对应的第一链网络中的共识节点；跨链中继用于隔离第一链网络和第二链网络，且第一链网络独立于目标链网络和第二链网络；
处理模块21，还用于将第一跨链转入交易的交易数据写入第二链上的第二跨链桥合约；
资产铸造模块22，用于调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
其中，资产铸造模块22包括：
交易验证单元221，用于在调用第二跨链桥合约执行第一跨链转入交易时，对第一跨链转入交易进行交易验证，得到第二交易验证结果；
资产铸造单元222，用于在第二交易验证结果指示交易验证成功的情况下，调用第二跨链桥合约所指示的第二资产合约，在第二链上铸造与第一资产具有相同资产内容的第二资产。
其中，第一跨链转入交易为跨链中继所发送的第二跨链交易请求中的交易；第二跨链交易请求中携带跨链中继通过私钥信息对第一跨链转入交易进行签名所得到的第二交易签名信息；
交易验证单元221包括：
交易获取子单元2211，用于将从第二跨链交易请求中获取到的第一跨链转入交易作为参考交易；
签名验证子单元2212，用于调用第二跨链桥合约中的签名验证方法获取跨链中继的私钥信息所对应的公钥信息，根据公钥信息对第二交易签名信息进行签名验证；在签名验证成功的情况下，将第二交易签名信息对应的第一跨链转入交易作为待匹配交易；
交易比对子单元2213，用于通过第二跨链桥合约中的交易对比方法对参考交易和待匹配交易进行交易比对，得到第二交易对比结果，将第二交易对比结果作为第二交易验证结果。
其中，资产铸造模块22，还用于在第二链上铸造与第一资产具有相同资产内容的第二资产时，调用第二跨链桥合约中的事件生成方法，从跨链中继基于第一跨链转入交易所发送的第二跨链交易请求中获取第一跨链事件的事件标识，并生成与事件标识关联的跨链交易完成事件；跨链交易完成事件用于表征成功将第一资产由第一链转移至第二链。
其中，资产铸造模块22包括：
查询请求获取单元223，用于获取业务对象针对第一跨链事件发送的事件查询请求；事件查询请求中携带第一跨链事件的事件标识；
完成事件查询单元224，用于若通过第二跨链桥合约中的事件查询方法，查询到事件标识关联的跨链交易完成事件，则向业务对象返回针对第一跨链事件的事件完成通知消息。
其中，资产铸造模块22包括：
执行请求获取单元225，用于获取业务对象基于事件完成通知消息发送的衍生业务执行请求；
交易参数获取单元226，用于基于衍生业务执行请求中的衍生业务，调用第二跨链桥合约获取第一跨链转入交易中的交易参数；交易参数是由第一跨链转入交易所对应的第一资产的资产用途权限所确定的；
合约调用单元227，用于在基于交易参数确定业务对象具备调用第二链上的衍生业务合约的权限的情况下，允许业务对象调用衍生业务合约执行第二资产对应的衍生业务。
其中，交易参数包含资产转移参数；资产转移参数用于指示将第二资产由业务对象转移至与业务对象相关联的衍生业务对应的衍生业务对象；合约调用单元，还用于在调用衍生业 务合约执行第二资产对应的衍生业务时，若基于资产转移参数确定将第二资产由业务对象转移至衍生业务对象，则在第二链上将第二资产的映射资产属性状态由第一属性状态变更为第二属性状态。
其中，处理模块21包括：
转出请求获取单元211，用于获取业务对象针对第二跨链转出交易发送的第二跨链资产转出请求；第二跨链资产转出请求中携带业务数据信息；第二跨链资产转出请求用于指示第二共识节点通过跨链中继将第二资产从第二链转移回第一链；
交易的交易数据写入单元212，用于将第二跨链资产转出请求中携带的第二跨链转出交易的交易数据写入第二链上的第二跨链桥合约；
跨链事件生成单元213，用于在基于第二跨链桥合约和业务数据信息确定业务对象具备跨链资产转回权限时，调用第二资产合约锁定第二资产，且生成第二跨链转出交易对应的第二跨链事件；第二跨链事件用于指示跨链中继在构建得到第二跨链转出交易对应的第二跨链转入交易时，将第二跨链转入交易发送至第一共识节点；第一共识节点用于在将第二跨链转入交易的交易数据写入第一链上的第一跨链桥合约时，调用第一跨链桥合约所指示的第一资产合约，在第一链上对锁定的第一资产进行解锁。
其中，跨链事件生成单元213包括：
验证请求生成子单元2131，用于调用第二跨链桥合约中的跨链权限查询方法，生成转回权限验证请求；转回权限验证请求用于指示管理共识节点调用目标链上的跨链授权管理合约查询业务对象的源配置数据信息；
接收子单元2132，用于接收管理共识节点基于转回权限验证请求返回的源配置数据信息，将源配置数据信息和业务数据信息进行信息比对，得到信息对比结果；
权限确定子单元2133，用于若信息比对结果指示对比成功，则确定业务对象具备跨链资产转回权限；
事件生成子单元2134，用于调用第二资产合约将第二资产的资产状态由第一状态切换为第二状态，且在第二资产的资产状态为第二状态时生成第二跨链转出交易对应的第二跨链事件。
其中，处理模块21，资产铸造模块22的具体实现方式，可以参见上述实施例中的描述，这里将不再继续进行赘述。另外，对于采用相同方法所得到的相同有益效果的描述，也不再进行赘述。
图15是本申请实施例提供的一种计算机设备的结构示意图。如图15所示，该计算机设备1500可以为用户终端，还可以为服务器，这里将不对其进行限制。可以理解的是，计算机设备可以为上述第一共识节点以及第二共识节点。为便于理解，本申请以计算机设备为服务器为例，该计算机设备1500可以包括：处理器1501，网络接口1504和存储器1505，此外，该计算机设备1500还可以包括：用户接口1503，和至少一个通信总线1502。其中，通信总线1502用于实现这些组件之间的连接通信。其中，用户接口1503还可以包括标准的有线接口、无线接口。网络接口1504可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1505可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1505可选的还可以是至少一个位于远离前述处理器1501的存储装置。如图12所示，作为一种计算机可读存储介质的存储器1505中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
其中，该计算机设备1500中的网络接口1504还可以提供网络通讯功能。在图12所示的计算机设备1500中，网络接口1504可提供网络通讯功能；而用户接口1503主要用于为用户提供输入的接口；而处理器1501可以用于调用存储器1505中存储的设备控制应用程序，以执行上述图3、图5、图7、图9或者图11所对应实施例中对基于多区块链的资产转移方法的描述，还可以执行前文图13、或者图14所对应实施例中对基于多区块链的资产转移装置(即上述基于多区块链的资产转移装置1、或者基于多区块链的资产转移装置2)的描述， 在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有前文提及的基于多区块链的资产转移装置1、或者基于多区块链的资产转移装置2所执行的计算机程序，且计算机程序包括计算机指令，当处理器执行计算机指令时，能够执行前文图3、图5、图7、图9或者图11所对应实施例中对基于多区块链的资产转移方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，计算机指令可被部署在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行，分布在多个地点且通过通信网络互连的多个计算设备可以组成区块链系统。
此外，需要说明的是：本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该计算机设备执行前文图3、图5、图7、图9或者图11所对应实施例中对基于多区块链的资产转移方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品或者计算机程序实施例中未披露的技术细节，请参照本申请方法实施例的描述。
图16是本申请实施例提供的一种基于多区块链的资产转移系统的示意图。该基于多区块链的资产转移系统3可以包含共识节点3a、共识节点3b和共识节点3c；其中，共识节点3a可以为上述图3所对应实施例所描述的处于目标链网络中的管理共识节点，该管理共识节点可以为上述图1所示的共识网络100a中的任意一个区块链节点，这里将不再继续进行赘述。其中，共识节点3b可以为上述图3所对应实施例所描述的处于第一链网络中的第一共识节点，该第一共识节点可以为上述图1所示的共识网络300a中的任意一个区块链节点，这里将不再继续进行赘述。其中，共识节点3c可以为上述图3所对应实施例所描述的处于第二链网络中的第二共识节点，该第二共识节点可以为上述图1所示的共识网络300a中的任意一个区块链节点，这里将不再继续进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (20)

  1. 一种基于多区块链的资产转移方法，所述多区块链包含第一链、第二链和目标链；所述方法由所述第一链对应的第一链网络中的第一共识节点执行，所述方法包括：
    获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求；所述第一跨链资产转出请求中携带有为所述业务对象配置的业务数据信息，所述业务数据信息由目标链网络中的目标共识节点配置；所述第一跨链资产转出请求用于指示所述第一共识节点通过跨链中继将属于所述业务对象的第一资产从所述第一链转移至与第二共识节点相关联的所述第二链；所述第二共识节点为所述第二链对应的第二链网络中的共识节点；所述跨链中继用于隔离所述第二链网络和所述第一链网络，且所述第二链网络独立于所述目标链网络和所述第一链网络；
    将所述第一跨链转出交易的交易数据写入所述第一链上的第一跨链桥合约；
    在基于所述第一跨链桥合约和所述业务数据信息确定所述业务对象具备跨链资产转出权限的情况下，调用所述第一链上的第一资产合约锁定所述第一资产，并生成所述第一跨链转出交易对应的第一跨链事件；所述第一跨链事件用于指示所述跨链中继在构建得到所述第一跨链转出交易对应的第一跨链转入交易时，将所述第一跨链转入交易发送至所述第二共识节点；所述第二共识节点用于在将所述第一跨链转入交易的交易数据写入所述第二链上的第二跨链桥合约时，调用所述第二跨链桥合约所指示的第二资产合约，在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产。
  2. 根据权利要求1所述的方法，其中，所述在基于所述第一跨链桥合约和所述业务数据信息确定所述业务对象具备跨链资产转出权限的情况下，调用所述第一链上的第一资产合约锁定所述第一资产，并生成所述第一跨链转出交易对应的第一跨链事件，包括：
    调用所述第一跨链桥合约中的跨链权限查询方法，生成转出权限验证请求；所述转出权限验证请求用于指示所述目标共识节点调用所述目标链上的跨链授权管理合约查询所述业务对象的源配置数据信息；
    接收所述目标共识节点返回的所述源配置数据信息，将所述源配置数据信息和所述业务数据信息进行信息比对，得到信息对比结果；
    若所述信息比对结果指示对比成功，则确定所述业务对象具备所述跨链资产转出权限；
    调用所述第一资产合约将所述第一资产的资产状态由第一状态切换为第二状态，并在所述第一资产的资产状态为所述第二状态时生成所述第一跨链转出交易对应的第一跨链事件。
  3. 根据权利要求1或2所述的方法，其中，所述方法还包括：
    接收所述跨链中继针对所述第二资产发送的第二跨链转入交易；所述第二跨链转入交易是由所述跨链中继从所述第二共识节点读取到第二跨链转出交易对应的第二跨链事件时所构建的，所述第二跨链事件由所述第二共识节点获取到所述业务对象针对所述第二资产所提交的所述第二跨链转出交易生成的；
    将所述第二跨链转入交易的交易数据写入所述第一跨链桥合约，基于所述第一跨链桥合约对所述第二跨链转入交易进行交易验证，得到第一交易验证结果；
    在所述第一交易验证结果指示交易验证成功的情况下，通过所述第一跨链桥合约中的资产合约调用方法，调用所述第一资产合约在所述第一链上对锁定的所述第一资产进行解锁。
  4. 根据权利要求3所述的方法，其中，所述第二跨链转入交易为所述跨链中继所发送的第一跨链交易请求中的交易；所述第一跨链交易请求中携带所述跨链中继通过私钥信息对所述第二跨链转入交易进行签名所得到的第一交易签名信息；
    所述将所述第二跨链转入交易的交易数据写入所述第一跨链桥合约，基于所述第一跨链桥合约对所述第二跨链转入交易进行交易验证，得到第一交易验证结果，包括：
    将从所述第一跨链交易请求中获取到的所述第二跨链转入交易作为待处理交易，将所述待处理交易的交易数据写入所述第一跨链桥合约；
    调用所述第一跨链桥合约中的签名验证方法获取所述跨链中继的私钥信息所对应的公钥信息，根据所述公钥信息对所述第一交易签名信息进行签名验证；在签名验证成功的情况下，将所述第一交易签名信息对应的第二跨链转入交易作为待验证交易；
    通过所述第一跨链桥合约中的交易对比方法对所述待处理交易和所述待验证交易进行交易比对，得到第一交易对比结果，将所述第一交易对比结果作为所述第一交易验证结果。
  5. 根据权利要求3所述的方法，其中，所述第一资产的资产属性状态为所述第一属性状态；在所述第二资产的映射资产属性状态由第一属性状态变更为第二属性状态时，所述方法还包括：
    在调用所述第一资产合约在所述第一链上对锁定的所述第一资产进行解锁时，将所述第一资产的资产属性状态由所述第一属性状态变更为所述第二属性状态。
  6. 根据权利要求1至5任一所述的方法，其中，所述方法还包括：
    在将所述第一跨链转出交易的交易数据写入所述第一跨链桥合约时，指定所述第一跨链转出交易所对应的第一资产的资产用途权限。
  7. 一种基于多区块链的资产转移方法，所述多区块链包含第一链、第二链和目标链；所述方法由所述第二链对应的第二链网络中的第二共识节点执行，所述方法包括：
    获取跨链中继针对第一资产发送的第一跨链转入交易；所述第一跨链转入交易是由所述跨链中继从第一共识节点读取到第一跨链转出交易对应的第一跨链事件时所构建的；所述第一跨链事件是由所述第一共识节点在基于写入有第一跨链转出交易的第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用所述第一链上的第一资产合约锁定所述第一资产时所生成的；所述业务数据信息为目标链网络中的目标共识节点为所述业务对象所配置的；所述第一共识节点为所述第一链对应的第一链网络中的共识节点；所述跨链中继用于隔离所述第一链网络和所述第二链网络，且所述第一链网络独立于所述目标链网络和所述第二链网络；
    将所述第一跨链转入交易的交易数据写入所述第二链上的第二跨链桥合约；
    调用所述第二跨链桥合约所指示的第二资产合约，在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产。
  8. 根据权利要求7所述的方法，其中所述调用所述第二跨链桥合约所指示的第二资产合约，在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产，包括：
    在调用所述第二跨链桥合约执行所述第一跨链转入交易时，对所述第一跨链转入交易进行交易验证，得到第二交易验证结果；
    在所述第二交易验证结果指示交易验证成功的情况下，调用所述第二跨链桥合约所指示的第二资产合约，在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产。
  9. 根据权利要求8所述的方法，其中，所述第一跨链转入交易为所述跨链中继所发送的第二跨链交易请求中的交易；所述第二跨链交易请求中携带所述跨链中继通过私钥信息对所述第一跨链转入交易进行签名所得到的第二交易签名信息；
    所述对所述第一跨链转入交易进行交易验证，得到第二交易验证结果，包括：
    将从所述第二跨链交易请求中获取到的所述第一跨链转入交易作为参考交易；
    调用所述第二跨链桥合约中的签名验证方法获取所述跨链中继的私钥信息所对应的公钥信息，根据所述公钥信息对所述第二交易签名信息进行签名验证；在签名验证成功的情况下，将所述第二交易签名信息对应的第一跨链转入交易作为待匹配交易；
    通过所述第二跨链桥合约中的交易对比方法对所述参考交易和所述待匹配交易进行交易比对，得到第二交易对比结果，将所述第二交易对比结果作为所述第二交易验证结果。
  10. 根据权利要求7至9任一所述的方法，其中，所述方法还包括：
    在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产时，调用所述第二跨链桥合约中的事件生成方法，从所述跨链中继基于所述第一跨链转入交易所发送的第二跨链交易请求中获取所述第一跨链事件的事件标识，并生成与所述事件标识关联的跨链交易完成 事件；所述跨链交易完成事件用于表征成功将所述第一资产由所述第一链转移至所述第二链。
  11. 根据权利要求10所述的方法，其中，所述方法还包括：
    获取所述业务对象针对所述第一跨链事件发送的事件查询请求；所述事件查询请求中携带所述第一跨链事件的事件标识；
    若通过所述第二跨链桥合约中的事件查询方法，查询到所述事件标识关联的跨链交易完成事件，则向所述业务对象返回针对所述第一跨链事件的事件完成通知消息。
  12. 根据权利要求11所述的方法，其中，所述方法还包括：
    获取所述业务对象基于所述事件完成通知消息发送的衍生业务执行请求；
    基于所述衍生业务执行请求中的衍生业务，调用所述第二跨链桥合约获取所述第一跨链转入交易中的交易参数；所述交易参数是由所述第一跨链转入交易所对应的第一资产的资产用途权限所确定的；
    在基于所述交易参数确定所述业务对象具备调用所述第二链上的衍生业务合约的权限的情况下，允许所述业务对象调用所述衍生业务合约执行所述第二资产对应的衍生业务。
  13. 根据权利要求12所述的方法，其中，所述交易参数包含资产转移参数；所述资产转移参数用于指示将所述第二资产由所述业务对象转移至与所述业务对象相关联的衍生业务对应的衍生业务对象；所述方法还包括：
    在调用所述衍生业务合约执行所述第二资产对应的衍生业务时，若基于所述资产转移参数确定将所述第二资产由所述业务对象转移至所述衍生业务对象，则在所述第二链上将所述第二资产的映射资产属性状态由第一属性状态变更为第二属性状态。
  14. 根据权利要求7至12任一所述的方法，其中，所述方法还包括：
    获取业务对象针对第二跨链转出交易发送的第二跨链资产转出请求；所述第二跨链资产转出请求中携带所述业务数据信息；所述第二跨链资产转出请求用于指示所述第二共识节点通过所述跨链中继将所述第二资产从所述第二链转移回所述第一链；
    将所述第二跨链资产转出请求中携带的所述第二跨链转出交易的交易数据写入所述第二链上的第二跨链桥合约；
    在基于所述第二跨链桥合约和所述业务数据信息确定所述业务对象具备跨链资产转回权限时，调用所述第二资产合约锁定所述第二资产，并生成所述第二跨链转出交易对应的第二跨链事件；所述第二跨链事件用于指示所述跨链中继在构建得到所述第二跨链转出交易对应的第二跨链转入交易时，将所述第二跨链转入交易发送至所述第一共识节点；所述第一共识节点用于在将所述第二跨链转入交易的交易数据写入所述第一链上的第一跨链桥合约时，调用所述第一跨链桥合约所指示的第一资产合约，在所述第一链上对锁定的所述第一资产进行解锁。
  15. 根据权利要求14所述的方法，其中，所述在基于所述第二跨链桥合约和所述业务数据信息确定所述业务对象具备跨链资产转回权限时，调用所述第二资产合约锁定所述第二资产，并生成所述第二跨链转出交易对应的第二跨链事件，包括：
    调用所述第二跨链桥合约中的跨链权限查询方法，生成转回权限验证请求；所述转回权限验证请求用于指示所述目标共识节点调用所述目标链上的跨链授权管理合约查询所述业务对象的源配置数据信息；
    接收所述目标共识节点基于所述转回权限验证请求返回的所述源配置数据信息，将所述源配置数据信息和所述业务数据信息进行信息比对，得到信息对比结果；
    若所述信息比对结果指示对比成功，则确定所述业务对象具备所述跨链资产转回权限；
    调用所述第二资产合约将所述第二资产的资产状态由第一状态切换为第二状态，且在所述第二资产的资产状态为所述第二状态时生成所述第二跨链转出交易对应的第二跨链事件。
  16. 一种基于多区块链的资产转移装置，所述多区块链包含第一链、第二链和目标链，所述装置包括：
    获取模块，用于获取业务对象针对第一跨链转出交易发送的第一跨链资产转出请求；所 述第一跨链资产转出请求中携带有所述业务对象配置的业务数据信息，所述业务数据信息由目标链网络中的目标共识节点配置；所述第一跨链资产转出请求用于指示第一共识节点通过跨链中继将属于所述业务对象的第一资产从所述第一链转移至与第二共识节点相关联的所述第二链；所述第二共识节点为所述第二链对应的第二链网络中的共识节点；所述跨链中继用于隔离所述第二链网络和第一链网络，且所述第二链网络独立于所述目标链网络和所述第一链网络；
    写入模块，用于将所述第一跨链转出交易的交易数据写入所述第一链上的第一跨链桥合约；
    调用模块，用于在基于所述第一跨链桥合约和所述业务数据信息确定所述业务对象具备跨链资产转出权限的情况下，调用所述第一链上的第一资产合约锁定所述第一资产，并生成所述第一跨链转出交易对应的第一跨链事件；所述第一跨链事件用于指示所述跨链中继在构建得到所述第一跨链转出交易对应的第一跨链转入交易时，将所述第一跨链转入交易发送至所述第二共识节点；所述第二共识节点用于在将所述第一跨链转入交易的交易数据写入所述第二链上的第二跨链桥合约时，调用所述第二跨链桥合约所指示的第二资产合约，在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产。
  17. 一种基于多区块链的资产转移装置，所述多区块链包含第一链、第二链和目标链，所述装置包括：
    处理模块，用于获取跨链中继针对第一资产发送的第一跨链转入交易；所述第一跨链转入交易是由所述跨链中继从第一共识节点读取到第一跨链转出交易对应的第一跨链事件时所构建的；所述第一跨链事件是由所述第一共识节点在基于写入有第一跨链转出交易的第一跨链桥合约和业务数据信息确定业务对象具备跨链资产转出权限的情况下，调用所述第一链上的第一资产合约锁定所述第一资产时所生成的；所述业务数据信息为目标链网络中的目标共识节点为所述业务对象所配置的；所述第一共识节点为所述第一链对应的第一链网络中的共识节点；所述跨链中继用于隔离所述第一链网络和第二链网络，且所述第一链网络独立于所述目标链网络和所述第二链网络；
    所述处理模块，还用于将所述第一跨链转入交易的交易数据写入所述第二链上的第二跨链桥合约；
    资产铸造模块，用于调用所述第二跨链桥合约所指示的第二资产合约，在所述第二链上铸造与所述第一资产具有相同资产内容的第二资产。
  18. 一种计算机设备，包括存储器和处理器；
    所述存储器与所述处理器相连，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1-15任一项所述的方法。
  19. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1-15任一项所述的方法。
  20. 一种计算机程序产品，包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现权利要求1-15任一项所述的方法。
PCT/CN2023/114368 2022-10-20 2023-08-23 基于多区块链的资产转移方法、装置、设备、介质及产品 WO2024082807A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/387,336 US20240235817A9 (en) 2022-10-20 2023-11-06 Asset transferring method and apparatus based on multiple blockchains, device, medium, and product

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211291310.4 2022-10-20
CN202211291310.4A CN117917681A (zh) 2022-10-20 2022-10-20 基于多区块链的资产转移方法、装置、设备、介质及产品

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/387,336 Continuation US20240235817A9 (en) 2022-10-20 2023-11-06 Asset transferring method and apparatus based on multiple blockchains, device, medium, and product

Publications (1)

Publication Number Publication Date
WO2024082807A1 true WO2024082807A1 (zh) 2024-04-25

Family

ID=90729656

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/114368 WO2024082807A1 (zh) 2022-10-20 2023-08-23 基于多区块链的资产转移方法、装置、设备、介质及产品

Country Status (3)

Country Link
US (1) US20240235817A9 (zh)
CN (1) CN117917681A (zh)
WO (1) WO2024082807A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111311209A (zh) * 2020-02-03 2020-06-19 腾讯科技（深圳）有限公司 跨区块链的数据处理方法、装置、设备及计算机存储介质
CN113407977A (zh) * 2021-07-21 2021-09-17 杭州链网科技有限公司 基于聚合签名的跨链扩展方法及系统
CN114154996A (zh) * 2021-10-20 2022-03-08 海南火链科技有限公司 一种跨区块链的数据流转方法及系统、存储介质、终端
CN114615095A (zh) * 2022-05-12 2022-06-10 北京邮电大学 区块链跨链数据处理方法、中继链、应用链及跨链网络

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111311209A (zh) * 2020-02-03 2020-06-19 腾讯科技（深圳）有限公司 跨区块链的数据处理方法、装置、设备及计算机存储介质
CN112837048A (zh) * 2020-02-03 2021-05-25 腾讯科技（深圳）有限公司 跨区块链的数据处理方法、装置、设备及计算机存储介质
CN113407977A (zh) * 2021-07-21 2021-09-17 杭州链网科技有限公司 基于聚合签名的跨链扩展方法及系统
CN114154996A (zh) * 2021-10-20 2022-03-08 海南火链科技有限公司 一种跨区块链的数据流转方法及系统、存储介质、终端
CN114615095A (zh) * 2022-05-12 2022-06-10 北京邮电大学 区块链跨链数据处理方法、中继链、应用链及跨链网络

Also Published As

Publication number Publication date
US20240137208A1 (en) 2024-04-25
US20240235817A9 (en) 2024-07-11
CN117917681A (zh) 2024-04-23

Similar Documents

Publication Publication Date Title
EP3688650B1 (en) System and method for providing a representational state transfer proxy service for a blockchain cloud service
Shalaby et al. Performance evaluation of hyperledger fabric
CN111598566A (zh) 基于混合跨链的网络支付系统
CN111431903B (zh) 一种跨链中继方法、装置以及计算机可读存储介质
US11822538B2 (en) Systems and methods of transaction identification generation for transaction-based environment
EP3726774A1 (en) Transparent blockchain sidechains to support blockchain processing heterogeneity
WO2024082818A1 (zh) 基于多区块链的跨链处理方法、装置、设备、系统及介质
CN111429191A (zh) 基于区块链的电子发票流转管理方法、装置及系统
CN112269838A (zh) 基于区块链的监管方法、装置、电子设备及存储介质
KR102376783B1 (ko) 블록체인 기반의 거래내역 확인 시스템
AU2017296038A1 (en) Digital asset architecture
CN117951217A (zh) 基于多区块链的跨链配置方法、装置、设备、系统及介质
CN117938867A (zh) 一种多区块链数据处理方法、装置、设备、介质及产品
WO2024082807A1 (zh) 基于多区块链的资产转移方法、装置、设备、介质及产品
US20230412402A1 (en) Endorsement policy consolidation in blockchain networks
US20220399988A1 (en) Linking blockchain operations
WO2024099023A1 (zh) 多区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品
Sidhu et al. Trust development for blockchain interoperability using self-sovereign identity integration
WO2024078109A1 (zh) 多区块链数据处理方法、装置、设备、系统以及介质
WO2024093593A1 (zh) 基于多区块链的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品
CN112163917A (zh) 基于区块链的票据处理方法、装置、介质及电子设备
Sadath et al. Scalability in Blockchain-Hyperledger Fabric and Hierarchical Model
EP4375850A1 (en) Multi-blockchain data processing method and apparatus, and device, system and medium
US12081670B1 (en) Validation of electronic document using distributed ledgers
CN116708463B (zh) 基于多区块链的信息处理方法、装置、设备以及介质

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

Country of ref document: EP

Kind code of ref document: A1