WO2024082818A1 - 基于多区块链的跨链处理方法、装置、设备、系统及介质 - Google Patents

基于多区块链的跨链处理方法、装置、设备、系统及介质 Download PDF

Info

Publication number
WO2024082818A1
WO2024082818A1 PCT/CN2023/114959 CN2023114959W WO2024082818A1 WO 2024082818 A1 WO2024082818 A1 WO 2024082818A1 CN 2023114959 W CN2023114959 W CN 2023114959W WO 2024082818 A1 WO2024082818 A1 WO 2024082818A1
Authority
WO
WIPO (PCT)
Prior art keywords
chain
transaction
business
cross
configuration
Prior art date
Application number
PCT/CN2023/114959
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
Priority claimed from CN202211298596.9A external-priority patent/CN117951217A/zh
Priority claimed from CN202211303327.7A external-priority patent/CN117938867A/zh
Priority claimed from CN202211306695.7A external-priority patent/CN117992534A/zh
Application filed by 腾讯科技(深圳)有限公司 filed Critical 腾讯科技(深圳)有限公司
Priority to US18/388,502 priority Critical patent/US20240137231A1/en
Publication of WO2024082818A1 publication Critical patent/WO2024082818A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3263Cryptographic 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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265Cryptographic 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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model

Definitions

  • the present application relates to the field of blockchain technology, and in particular to a cross-chain processing method, device, equipment, system and medium based on multiple blockchains.
  • each blockchain in the multiple blockchains is independent.
  • the consensus nodes on each blockchain need to independently configure some basic data information of their own chains.
  • the consensus node on blockchain A can independently configure the block time, block size, and business logic rules of its own chain
  • the consensus node on blockchain B can also independently configure the block time, block size, and business logic rules of its own chain, and other configuration information.
  • the embodiments of the present application provide a cross-chain processing method, device, equipment, system and medium based on multiple blockchains, which realizes efficient management of multiple blockchains by performing cross-chain processing on at least two blockchains in the multiple blockchains.
  • an embodiment of the present application provides a cross-chain configuration method based on multiple blockchains, the method being executed by a management chain consensus node in a multiple blockchain system, the multiple blockchains comprising the management chain and at least one other blockchain, the management chain consensus node being located in the management chain, the method comprising:
  • cross-chain processing is performed on the at least two blockchains.
  • an embodiment of the present application provides a cross-chain processing method based on multiple blockchains, the method being executed by an off-chain processing device in a multi-blockchain system, the method comprising:
  • the multiple blockchains include the management chain and at least one other blockchain, and the management chain consensus node is located in the management chain.
  • an embodiment of the present application provides a cross-chain processing device based on multiple blockchains, the device comprising:
  • Blockchain acquisition module used to obtain multiple blockchains
  • a blockchain acquisition and determination module used to determine at least two blockchains to be cross-chain processed among the multiple blockchains
  • a processing module is used to perform cross-chain processing on the at least two blockchains based on the chain information of the at least two blockchains.
  • an embodiment of the present application provides a cross-chain processing device based on multiple blockchains, the device comprising:
  • a determination module configured to determine at least two blockchains to be cross-chain processed among the multiple blockchains
  • a processing module configured to collaborate with a management chain consensus node to perform cross-chain processing on the at least two blockchains
  • the multiple blockchains include the management chain and at least one other blockchain, and the management chain consensus node is located on the management chain.
  • 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.
  • 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 having a processor executes the method provided in the above aspect of an 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 performs the method provided in the above aspect.
  • multiple blockchains are obtained; at least two blockchains to be cross-chain processed are determined in the multiple blockchains; and based on the chain information of the at least two blockchains, the cross-chain processing is performed on the at least two blockchains.
  • the embodiment of the present application realizes the comprehensive management of multiple blockchains through cross-chain processing, and improves the processing efficiency of multiple blockchains.
  • FIG1 is a schematic diagram of a hierarchical structure of a blockchain network provided in an embodiment of the present application.
  • FIG2 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 schematic diagram of a cross-chain configuration based on multiple blockchains provided in an embodiment of the present application.
  • FIG4 is a schematic diagram of a flow chart of a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application;
  • FIG5 is a schematic diagram of a flow chart of a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application
  • FIG6 is a flow chart of a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • FIG7 is a flow chart of a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • FIG8 is a schematic diagram of a flow chart of a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • FIG9 is a flow chart of a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • FIG10 is a schematic diagram of a cross-chain data transmission method based on multiple blockchains provided by the present application.
  • FIG11 is a schematic diagram of a cross-chain data transmission process based on multiple blockchains provided by the present application.
  • FIG12 is a flow chart of a cross-chain data transmission method based on multiple blockchains provided by the present application.
  • FIG13 is a multi-blockchain cross-chain data transmission method provided by the present application.
  • FIG14 is a schematic diagram of a cross-chain data transmission process based on multiple blockchains provided by the present application.
  • FIG15 is a flow chart of a cross-chain data transmission method based on multiple blockchains provided by the present application.
  • FIG16 is a flow chart of a cross-chain data transmission method based on multiple blockchains provided by the present application.
  • FIG17 is a schematic diagram of a scenario for establishing a service sub-network provided by the present application.
  • FIG18 is a schematic diagram of a multi-blockchain data processing method provided by the present application.
  • FIG19 is a schematic diagram of a multi-blockchain data processing method provided by the present application.
  • FIG20 is a schematic diagram of a cross-chain data transmission scenario provided by the present application.
  • FIG21 is a schematic diagram of a cross-chain data transmission scenario provided by the present application.
  • FIG22 is a schematic diagram of an interaction in a blockchain electronic bill scenario provided by the present application.
  • FIG23 is a schematic diagram of an interactive process of a multi-blockchain data processing method provided by the present application.
  • FIG24 is a system architecture diagram for a blockchain electronic bill scenario provided by the present application.
  • FIG25 is a cross-chain processing device based on multiple blockchains provided by the present application.
  • FIG26 is a cross-chain processing device based on multiple blockchains provided by the present application.
  • FIG27 is a schematic diagram of the structure of a cross-chain configuration device based on multiple blockchains provided by the present application.
  • FIG28 is a schematic diagram of a cross-chain configuration system based on multiple blockchains provided by the present application.
  • FIG29 is a schematic diagram of the structure of a cross-chain data transmission device based on multiple blockchains provided by the present application.
  • FIG30 is a schematic diagram of the structure of a cross-chain data transmission device based on multiple blockchains provided by the present application.
  • FIG31 is a schematic diagram of a multi-blockchain cross-chain data transmission system provided by the present application.
  • FIG32 is a schematic diagram of the structure of a multi-blockchain data processing device provided by the present application.
  • FIG33 is a schematic diagram of the structure of a multi-blockchain data processing device provided by the present application.
  • FIG34 is a schematic diagram of the structure of a multi-blockchain data processing system provided by the present application.
  • FIG35 is a schematic diagram of the structure of a computer device provided in the present application.
  • the “management chain consensus node” in the cross-chain configuration refers to the consensus node in the management chain network, which may also be referred to as the “first consensus node”, i.e., the “first consensus node” in the Chinese patent application entitled “Cross-chain configuration method, device, equipment, system and medium based on multiple blockchains”.
  • the “other blockchain” in the cross-chain configuration refers to the blockchain for which cross-chain parameter configuration is to be performed, which may also be referred to as the “target chain” for which cross-chain configuration is to be performed, i.e., the “target chain” in the Chinese patent application entitled “Cross-chain Configuration Method, Device, Equipment, System and Medium Based on Multiple Blockchains”.
  • the “other consensus nodes” in the cross-chain configuration refer to the consensus nodes in other blockchains, which may also be referred to as “target consensus nodes”, i.e., the “target consensus nodes” in the corresponding Chinese patent application entitled “Cross-chain Configuration Method, Device, Equipment, System and Medium Based on Multiple Blockchains”.
  • the “management chain consensus node” in cross-chain data transmission refers to the consensus node in the target chain, which can also be called the “target consensus node”, that is, the “target consensus node” in the Chinese patent application with the invention name “Cross-chain data transmission method, related equipment, medium and product based on multiple blockchains”.
  • the “contract chain” in cross-chain data transmission refers to the blockchain containing data resources associated with the first business, which may also be referred to as the “first chain”, i.e., the “first chain” in the Chinese patent application with the corresponding invention title of “Data cross-chain method, related equipment, medium and product based on multiple blockchains”.
  • the “invoice chain” in cross-chain data transmission refers to the blockchain containing data resources associated with the second business, which may also be referred to as the “second chain”, i.e., the “second chain” in the Chinese patent application with the corresponding invention name “Data cross-chain method, related equipment, medium and product based on multiple blockchains”.
  • the “management chain consensus node” in cross-chain data processing refers to the consensus node in the management chain, which may also be called the “management chain consensus node”, that is, the “management chain consensus node” in the corresponding Chinese patent application with the invention name “Multi-blockchain data processing method, device, equipment, medium and product”.
  • the “management chain” in cross-chain data processing is used to store the registration service authorization certificate associated with the temporary service, which can also be called the “target chain”, that is, the “target chain” in the Chinese patent application with the corresponding invention name “Multi-blockchain data processing method, device, equipment, medium and product”.
  • the “management chain network” in cross-chain data processing refers to the network corresponding to the management chain, which may also be referred to as the “target chain network” corresponding to the “target chain”, that is, the “target chain network” in the Chinese patent application with the invention name “Multi-blockchain data processing method, device, equipment, medium and product”.
  • the “invoice chain” in cross-chain data processing refers to the blockchain that provides consensus nodes, which can also be called the “first chain”, that is, the “first chain” in the Chinese patent application with the corresponding invention name “Multi-blockchain data processing method, device, equipment, medium and product”.
  • the “contract chain” in cross-chain data processing refers to the blockchain that provides the consensus node, which can also be called the “second chain”, that is, the “second chain” in the Chinese patent application with the corresponding invention name “Multi-blockchain data processing method, device, equipment, medium and product”.
  • Figure 1 is a schematic diagram of a hierarchical structure of a blockchain network provided in an embodiment of the present application.
  • the hierarchical structure shown in Figure 1 is applied to a blockchain system corresponding to a multi-business collaborative processing platform.
  • a business network deployed in a public network and multiple consensus networks deployed in a private cloud are included.
  • the business network here can be the business network 400a shown in Figure 1
  • the multiple consensus networks here can specifically include the consensus network 100a, consensus network 200a, and consensus network 300a shown in Figure 1.
  • multiple business nodes are deployed, and the multiple business nodes here may specifically include the business nodes 110a, 110b, 110c, 110d, 110e, 110f, 110g, ..., 110n shown in FIG. 1 .
  • the number of business nodes deployed in the business network 400a will not be limited here.
  • 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, and the number of consensus networks accessed by each business object through the corresponding business node will not be limited here. It can be understood that data interaction can also be carried out between each consensus network in the form of network communication.
  • the consensus network 100a shown in FIG. 1 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 FIG. 1 . It should be noted that the number of consensus nodes deployed in the consensus network 100a is not limited here.
  • the blockchain maintained together is specifically the blockchain 10e shown in FIG. 1 .
  • the consensus network 200a shown in FIG1 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 . It should be noted that the number of consensus nodes deployed in the consensus network 200a is not limited here.
  • the blockchain maintained together is specifically the blockchain 11e shown in FIG1 .
  • the consensus network 300a shown in FIG1 multiple consensus nodes are deployed, and the multiple consensus nodes here may specifically include consensus node 12a, consensus node 12b, consensus node 12c, and consensus node 12d shown in FIG1 . It should be noted that the number of consensus nodes deployed in the consensus network 300a is not limited here.
  • 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 system as blockchain nodes (referred to as nodes for short), and may collectively refer to the consensus network 100a, consensus network 100b and consensus network 100c participating in the above-mentioned blockchain system as core consensus networks, and may collectively refer to the various nodes in the above-mentioned core consensus networks as core nodes.
  • the blockchain stored on each node in the consensus network 100a is blockchain 10e, where blockchain 10e can be the first chain, and the consensus network corresponding to the first chain (i.e., consensus network 100a) can be the first chain network, and the consensus nodes in the first chain network can be collectively referred to as first consensus nodes.
  • the blockchain stored on each node in the consensus network 200a is blockchain 11e, where blockchain 11e can be the second chain, and the consensus network corresponding to the second chain (i.e., consensus network 200a) can be the second chain network, and the consensus nodes in the second chain network can be collectively referred to as second consensus nodes.
  • the blockchain stored on each node in the consensus network 300a (for example, core nodes such as consensus node 12a, consensus node 12b, consensus node 12c and consensus node 12d) is blockchain 12e.
  • the blockchain 12e here can be a third chain, and the consensus network corresponding to the third chain (i.e., consensus network 300a) can be a third chain network.
  • the consensus nodes in the third chain network can be collectively referred to as third consensus nodes.
  • this application is implemented in the three-chain system involved in the aforementioned blockchain system (i.e., the first chain, the second chain, and the third chain).
  • the three-chain system constructed by the blockchain one or more sub-chain consensus networks based on the aforementioned temporary tasks can be temporarily created, and the blockchains corresponding to these constructed sub-chain consensus networks can be called business sub-chains.
  • the sub-chain consensus node in the sub-chain consensus network can come from the second consensus node in the second chain network and the third consensus node in the third chain network.
  • the sub-chain consensus network corresponding to the target business is jointly constructed by the management consensus node based on the consensus nodes voted from the second chain network (such as the consensus nodes 11a and 11b in Figure 1 above) and the consensus nodes voted from the third chain network (such as the consensus nodes 12a and 12b in Figure 1 above).
  • a business subchain corresponds to a temporary business.
  • the temporary business corresponding to the business subchain is to verify whether the bill template used by 100 bills is the latest bill template.
  • the subchain consensus node in the business subchain can verify whether the bill template used by these 100 bills is the latest bill template, and then return the verification result.
  • the temporary business corresponding to the business subchain is to verify whether the tax calculation rules in the electronic bill are correct.
  • the subchain consensus node in the business subchain can verify whether the tax calculation in the bill is correct based on the asset mapping relationship, and return the verification result.
  • the embodiment of the present application can collectively refer to the aforementioned temporary business as the target business. It should be understood that the number of business subchains in the embodiment of the present application is not limited. For example, 2 business subchains, 5 business subchains, 40 business subchains, etc. can be created according to the temporary business form, and the business subchain can be closed according to business needs.
  • the second chain and the third chain under the aforementioned three-chain system can be called the business main chain, the business main chain and the business sub-chain are independent of each other, and the above-mentioned first chain can interact with the business main chain and the business sub-chain through the corresponding cross-chain relay.
  • the cross-chain relay can be an independent service device that can detect data on the business main chain or the business sub-chain.
  • 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 so that it cannot be tampered with or forged, and can verify, store and update data.
  • Blockchain is essentially a decentralized database in which each node stores an identical blockchain.
  • 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 its own 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 can be understood as a code executed by each blockchain node (i.e., each consensus node) in the blockchain system, and any logic can be executed and the result can be obtained through the smart contract.
  • a user can call a smart contract that has been deployed on the blockchain (e.g., the above-mentioned blockchain 11e) of the corresponding core consensus network (e.g., the above-mentioned consensus network 200a) by initiating a transaction service request through a user client.
  • the business node in the business network can send the transaction business request to the consensus node in the corresponding core consensus network (for example, the consensus node 11a shown in Figure 1) to send the transaction through the chain entry of the corresponding core consensus network.
  • the user making the business request is authenticated, and when the identity authentication is successful, the transaction business request sent by the user is allowed to be sent to other consensus nodes in the corresponding core consensus network (for example, consensus node 11b shown in Figure 1) to call the smart contracts running in these consensus nodes (for example, consensus node 11a and consensus node 11b shown in Figure 1) to execute the transaction business requested by the user.
  • 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 (Identity document, ID) or the contract name, and the transaction service 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 smart contract to be run can be determined according to the configuration resources indicated by the configuration transaction.
  • a full-platform configuration contract can be deployed in the management chain, and the full-platform configuration contract can include a chain management configuration contract, and the chain management configuration contract includes a smart contract corresponding to a global configuration resource (global configuration resources can be for all blockchains in the blockchain system), and a smart contract corresponding to an independent configuration resource (an independent configuration resource is only for a certain blockchain in the blockchain system).
  • the smart contract corresponding to the global configuration resource or the smart contract corresponding to the independent configuration resource can be called to execute the configuration transaction corresponding to the configuration transaction, thereby obtaining the configuration transaction identifier corresponding to the configuration transaction, and then according to the configuration transaction identifier, the cross-chain configuration items for chain configuration of the blockchain are stored in the local cache and local storage of each node through mutual verification of each consensus node in the blockchain, and the execution result of the above-mentioned configuration transaction can be returned to the client.
  • the local cache here refers to the system memory created in the storage layer
  • the local storage here refers to the hard disk space created in the storage layer for data storage.
  • any two blockchain nodes in any consensus network can form a peer-to-peer network, and the peer-to-peer network can adopt the P2P protocol, wherein the peer-to-peer protocol is an application layer protocol running on the Transmission Control Protocol (TCP) protocol, and there is no need for a central node to maintain the network status between blockchain nodes, but each blockchain node maintains the node status of the entire network or the connection status of its adjacent blockchain nodes through broadcast interaction with adjacent blockchain nodes.
  • 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 specific application scenarios of the multi-business collaborative processing platform can be electronic bill circulation scenarios under the blockchain electronic bill platform, blockchain medical prescription circulation scenarios, etc.
  • the first chain can be the management chain in the blockchain electronic bill platform
  • the second chain can be the bill chain in the blockchain electronic bill platform
  • the third chain can be the application contract chain in the blockchain electronic bill platform; when the blockchain system is applied to the blockchain electronic bill platform, a safe and reliable blockchain electronic bill three-chain network can be constructed based on the first chain, the second chain and the third chain.
  • the blockchain electronic bill three-chain network when the business is independently executed in the three consensus networks, the business execution results obtained by the independent execution of the business can be stored in the blockchain account book of the corresponding blockchain.
  • the first chain can be the management chain in the blockchain medical prescription platform
  • the second chain can be the prescription chain in the blockchain electronic medical prescription platform
  • the third chain can be the prescription application contract chain in the blockchain medical prescription platform.
  • a safe and reliable blockchain electronic medical prescription three-chain network can be constructed based on the above-mentioned first chain, second chain and third chain.
  • the blockchain electronic medical prescription three-chain network when the business is executed independently in the above-mentioned three consensus networks, the business execution results obtained by the independent execution of the business can be stored in the blockchain account book of the corresponding blockchain respectively.
  • FIG 2 is a scene diagram of a blockchain electronic bill platform based on multiple blockchains provided in an embodiment of the present application.
  • the blockchain electronic bill platform can be a specific business platform in the above-mentioned blockchain system. It should be understood that in the blockchain electronic bill platform, in order to reduce the complexity of data storage on the chain, a multi-chain system based on blockchain electronic bills is proposed, and the multi-chain system mainly involves the blockchain electronic bill three-chain network shown in Figure 2. As shown in Figure 2, the blockchain electronic bill three-chain network is deployed with a management chain, a bill chain, and an application contract chain.
  • the management chain here can be the above-mentioned first chain
  • the management chain network corresponding to the management chain is the above-mentioned first chain network
  • the bill chain here can be the above-mentioned second chain
  • the bill chain network corresponding to the bill chain is the above-mentioned second chain network
  • the application contract chain here can be the above-mentioned third chain
  • the application contract chain network corresponding to the application contract chain is the above-mentioned third chain network.
  • the mutual cooperation between the management chain, the bill chain and the application contract chain can provide the entire blockchain electronic bill platform with the functional characteristics of independently executing different businesses, so that a safe and efficient business flow system can be constructed under the premise of mutual cooperation between the three chains.
  • the multi-chain system is taken as a three-chain system as an example. Under this three-chain system, the management chain, the bill chain and the application contract chain are all independently built, that is, the consensus node used to maintain the management chain is different from the consensus node used to maintain the bill chain, and is different from the consensus node used to maintain the application contract chain.
  • 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 consensus node deployed in the bill chain network can maintain the business logic of electronic bills throughout the life cycle through the bill chain.
  • the full life cycle of all issued electronic bills can be managed through the bill chain.
  • the full life cycle of electronic bills here includes the issuance of electronic bills, the circulation of electronic bills, and the reimbursement of electronic bills.
  • the bill chain maintained by the consensus nodes has the characteristics of high performance and low latency.
  • the embodiment of the present application proposes that a more standardized, flexible and fully functional derivative business can be provided by another blockchain independent of the management chain and the bill chain (i.e., the application contract chain shown in FIG2), that is, the application contract chain here can be the electronic bill provided by the entire blockchain electronic bill platform to carry out the functional characteristics of the derivative business.
  • the consensus node deployed in the application contract chain network can carry the derivative business corresponding to the bill business that can be changed through the application contract chain.
  • the derivative business here can specifically 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 government cooperation department and the alliance chain partner shown in FIG2 (i.e., the business-related department shown in FIG2), and obtain the application contract template on the management through the tax application contract (open contract deployment contract) shown in FIG2 to develop smart contracts related to derivative business (for example, the derivative business contract shown in FIG2), and the derivative business contract can be deployed on the application contract chain after review by the tax management department.
  • the smart contracts deployed on the application contract chain can realize flexible upgrades and changes of smart contracts through virtual machine compatible contracts.
  • the application contract chain has the highest degree of openness compared to the management chain and the bill chain, and supports complex smart contract logic, with more participants and constant dynamic changes, and its performance is relatively lower than that of the bill 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 through cross-chain relay, that is, the three chains can interact across chains.
  • 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, for example, 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.
  • the management chain is a blockchain in the above-mentioned management chain network, and the management consensus node in the management chain network (i.e., the above-mentioned first consensus node) can be managed by the tax management department shown in Figure 2.
  • the aforementioned tax administration department can exercise management responsibilities through the management consensus node deployed in the management chain network.
  • the management responsibilities here can specifically include the management of information within the government department (for example, information of internal personnel of the tax administration department), the management of 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), the management of the metadata information of the overall business (for example, the access traffic at the entrance of each chain under the three-chain system), and the identity management and permission management of the participants of the overall business (for example, business objects such as individual users, corporate users, and tax business participants).
  • 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 internal participant associated with the management chain can be the tax management department shown in Figure 2.
  • 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 when 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, when the tax management department participates in the management chain as an internal participant, it can also limit the node quantity parameter 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 bill chain network system when the number of Byzantine nodes (i.e., the number of malicious nodes in the bill chain network) is less than 1/3 of the total number of nodes in the bill chain network.
  • the TBFT consensus algorithm can immediately determine the status of a proposed block to be on the chain, with higher performance, fewer blockchain nodes, and blockchain nodes can continuously generate blocks.
  • the consensus nodes in the bill chain 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 bill chain network through the internal management contract in the above-mentioned management chain.
  • the tax bureau terminal corresponding to the specific tax personnel in the tax administration department can participate in the formation of the bill chain 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 bill chain 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) consensus algorithm, through which the network security of the application contract chain network where the application contract chain is located can be maintained, and the status of a proposed block to be put on the chain can be immediately determined through the proof-of-stake consensus algorithm.
  • PoS Proof-of-Stake
  • the consensus nodes in the application contract chain network can be jointly managed by the tax administration department and government cooperation department shown in Figure 2 and large participating institutions (i.e., the large enterprises in the aforementioned alliance chain, which are the business-related departments shown in Figure 2).
  • the management chain shown in Figure 2 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 authority management contract, object identity management contract, metadata management contract, internal management contract and full platform configuration contract shown in Figure 2 can be deployed on the management chain.
  • these smart contracts can be developed and managed by specific tax management personnel in the tax management department.
  • calling the object authority management contract can manage the management authority of the management object and the business access authority of the business object
  • calling the object identity management contract can manage the identity information or business of the management object.
  • the identity information of the object can be managed; the metadata management contract can be called to manage the metadata on the blockchain; the full platform configuration contract can be called to manage the cross-chain configuration.
  • the bill chain has built-in smart contracts with specific bill business logic.
  • These smart contracts for example, the electronic bill issuance contract, electronic bill circulation contract, electronic bill redemption contract, and electronic bill archiving contract shown in FIG2 above
  • the embodiment of the present application can update the bill business logic in the electronic bill issuance contract through the metadata information read 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 various new business contracts can be deployed and run on the compatible virtual machine.
  • a derivative business contract associated with a derivative business for example, the above-mentioned lottery business
  • a derivative application contract associated with another derivative business for example, the above-mentioned tax refund business
  • the public network participants associated with the management chain can be individual users and corporate users as shown in FIG2.
  • the public network participants associated with the bill chain can be the local electronic bill flow systems as shown in FIG2.
  • the local electronic bill flow systems here specifically include local electronic bill business issuance systems (for example, local tax bureau systems), electronic bill issuance 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 as shown in FIG2.
  • the chain entry associated with the management chain may be the management chain entry shown in FIG. 2.
  • the management chain may be accessed through the management chain entry, and then the 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 FIG. 2.
  • the local electronic bill flow systems e.g., large enterprise users
  • the bill chain may be accessed through the bill chain entry, and then the electronic bill issuance service, electronic bill circulation service, electronic bill red-check service and electronic bill archiving service 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 FIG. 2.
  • the application contract chain may be accessed through the application contract chain entry, and then the derivative business contracts may be deployed on the application contract chain to perform derivative business related to the electronic bill through the deployed derivative business contracts.
  • management chain entrance shown in FIG. 2 may specifically 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 2 can specifically 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 (such as enterprise B) can be received.
  • the above-mentioned bill consensus node receives the transaction data through the electronic bill business entry, it checks whether the access identity and access authority of the sender of the transaction data (i.e., the aforementioned enterprise B) meet the identity authority contract status requirements in the management chain, and then when the verification is passed, the corresponding electronic bill can be issued according to the transaction data.
  • the application contract chain entry shown in FIG2 can be specifically a tax derivative business entry, through which a derivative business associated with the bill business requested to be participated in by a certain business object (such as the tax business participant shown in FIG2) can be received. It should be understood that after the tax business participant and developer shown in FIG2 obtain the business participation license certificate of the authorized object issued by the tax administration department, they can verify the business participation license certificate submitted by the business object (such as the tax business participant or developer) through the application contract chain entry, and then When the verification is successful, the business object is allowed to access the application contract chain to execute 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 2.
  • the tax management department here is mainly used to configure and manage internal status 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, etc.).
  • the internal participants involved in maintaining the bill chain can be the electronic bill data center shown in Figure 2.
  • the electronic bill data center here can specifically be an electronic invoice data center.
  • the electronic bill data center (for example, the electronic invoice data center) can be used for off-chain backup, statistics, data analysis and review of the massive amount of ledger data recorded on the bill chain.
  • the internal participants participating in the maintenance of the application contract chain may be the government cooperation departments and business-related departments shown in FIG2. It should be understood that, in addition to the tax administration department, the internal participants participating in the maintenance of the application contract chain include other departments (i.e., the aforementioned government cooperation departments) and participants (i.e., the aforementioned business-related departments) in the system alliance chain.
  • the application contract chain is accessed, the corresponding derivative business can be further executed through the derivative business contract 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 (for example, public network participants) and participants (for example, internal participants) under the entire three-chain system can be managed. It should be understood that the accessors and participants here can specifically include tax management personnel, government cooperation departments, local tax bureaus, invoicing service providers, reimbursement service providers, tax review departments, etc.
  • the smart contracts built into the bill chain can include bill chain configuration contracts and bill business contracts associated with the life cycle of electronic bills.
  • the bill business contracts here can specifically include the electronic bill issuance contract for providing electronic bill invoicing services, the electronic bill circulation contract for providing electronic bill circulation services, the electronic bill red-check contract for providing electronic bill red-check services, and the electronic bill archiving contract for providing electronic bill archiving services.
  • the above-mentioned bill chain configuration contract is used to record the configuration items on this chain.
  • the smart contracts built into the bill chain may include the application chain configuration contract, and may also include various contracts (for example, the virtual machine compatibility contract, tax application contract and derivative business contract shown in Figure 2) deployed by the tax derivative business participants (i.e., derivative business objects, for example, the tax business participants shown in Figure 2).
  • 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 lottery business contract on the chain deployed to encourage invoicing, a talent incentive contract, and a tax refund business contract.
  • the above-mentioned application contract chain configuration contract is used to record the configuration items on this chain.
  • the management chain shown in Figure 2 above is mainly used to process management business flows with small data volumes and relatively constant states.
  • the openness of the entire management chain is relatively low, and it can be used for internal management of some tax data.
  • the bill chain shown in Figure 2 above it can be used to process real-time bill business flows with a high-frequency request state for a long time.
  • the openness of the entire bill chain is relatively high, and it can allow relevant authoritative agencies in the life cycle of the electronic bill itself to participate in the corresponding bill business.
  • the consensus node corresponding to the agency service provider can be allowed to issue an electronic invoice for a user who is currently requesting an invoice.
  • the application contract chain shown in Figure 2 the amount of data does not need to be limited, and the frequency of business changes fluctuates relatively greatly. It can mainly handle various types of cooperative businesses, derivatives, and other related businesses through the application contract chain. It should be understood that the application contract chain has the highest openness, and can allow participants authorized by the management chain to deploy smart contracts on the application contract chain, run exploratory derivative businesses, etc.
  • an embodiment of the present application provides a cross-chain processing method based on multiple blockchains, which is executed by a management chain consensus node in a multiple blockchain system, wherein the multiple blockchains include the management chain and at least one other blockchain, and the management chain consensus node is located on the management chain, and the method includes:
  • the management chain consensus node obtains multiple blockchains.
  • the management chain consensus node determines at least two blockchains to be cross-chain processed in the multiple blockchains; the management chain consensus node performs cross-chain processing on at least two blockchains based on the chain information of the at least two blockchains.
  • Cross-chain processing refers to processing multiple blockchains in a cross-chain manner.
  • Cross-chain processing includes at least one of cross-chain configuration, cross-chain data transmission and data processing.
  • Cross-chain configuration is used to configure the configuration items of one blockchain to other blockchains.
  • Cross-chain data transfer is used to transfer data between different blockchains.
  • Data processing refers to processing temporary business by reusing consensus nodes in at least two blockchains.
  • the management chain consensus node configures cross-chain configuration items to at least one other blockchain based on the management chain; or, the management chain consensus node transmits target transaction resources to at least one other blockchain based on the management chain; or, the management chain consensus node reuses consensus nodes in at least one other blockchain based on the management chain to process temporary business.
  • the cross-chain configuration item configuration value is cross-chain configured from the management chain to the at least one other blockchain, and the at least one other blockchain includes: at least one of a bill chain, a contract chain, and a business sub-chain.
  • the target transaction resources are transferred from the source blockchain to the target blockchain
  • the source blockchain includes at least one of the contract chain, the bill chain, and the business sub-chain
  • the target blockchain includes the management chain.
  • consensus nodes in at least one other blockchain are reused to jointly form a business subnetwork corresponding to the temporary business.
  • the at least one other blockchain includes at least one of the bill chain and the contract chain.
  • the business subnetwork is used to handle temporary business.
  • the embodiment of the present application provides a schematic diagram of cross-chain configuration for other blockchains.
  • the blockchain system may include a management chain, a bill chain, a contract chain, a business subchain 1, and a business subchain 2.
  • the bill chain to be configured, the contract chain to be configured, the business subchain 1 to be configured, and the business subchain 2 to be configured can be referred to as other blockchains, and the consensus nodes of chains related to other blockchains can be referred to as other consensus nodes.
  • the bill chain and the contract chain can also be referred to as business main chains; in the embodiment of the present application, a cross-chain relay can be used to isolate the management chain network corresponding to the management chain and other blockchain networks corresponding to other blockchains. It should be understood that the number of business subchains in the embodiment of the present application is not limited.
  • the core consensus network where the management chain is located i.e., the above-mentioned management chain network
  • the consensus node participating in the maintenance of the management chain can be the above-mentioned management chain consensus node.
  • multiple smart contracts for cross-chain configuration are deployed on the aforementioned management chain, and these smart contracts can run on the management chain consensus node.
  • a full-platform configuration contract is deployed in the management chain, and calling the full-platform configuration contract can realize the basic configuration of the business main chain and the business sub-chain.
  • the full-platform configuration contract can realize global configuration and separate configuration of the business main chain or business sub-chain.
  • the full-platform configuration contract includes a chain management configuration contract
  • the chain management configuration contract includes a platform configuration contract for global configuration and other blockchain management configuration contracts for configuring a chain separately.
  • other blockchain management configuration contracts can include the chain management configuration contract of the bill chain, the chain management configuration contract of the contract chain, or the sub-chain management configuration contract of the business sub-chain.
  • both the business main chain i.e., the bill chain and the contract chain
  • the business sub-chain can be globally configured. It should be understood that calling the platform configuration contract can perform cross-chain configuration on the metadata, basic information (such as the chain name of certain chains, the management objects of certain chains, the time of generating blocks, etc.) in the bill chain, contract chain, business sub-chain 1 and business sub-chain 2.
  • the management chain is used as the management chain in the blockchain electronic bill platform.
  • calling the platform configuration contract can perform cross-chain configuration on some tax metadata (such as changes in tax calculation rules, etc.), basic information (such as the chain name of the application contract chain, the chain name of the bill chain, the management objects of certain chains, the time of generating blocks, etc.).
  • tax metadata such as changes in tax calculation rules, etc.
  • basic information such as the chain name of the application contract chain, the chain name of the bill chain, the management objects of certain chains, the time of generating blocks, etc.
  • the separate configuration may include the generation of block size and some business rules on the chain.
  • calling the chain management configuration contract of the bill chain can upgrade the invoicing on the bill chain, change the invoice circulation on the bill chain, etc.
  • calling the chain management configuration contract of the prescription chain can configure the prescription template on the prescription chain, change the prescription circulation on the prescription chain, etc.
  • the core consensus network where the bill chain is located i.e. the above-mentioned bill chain network
  • the consensus network 200a shown in Figure 1 above A chain configuration contract is deployed on the bill chain, and the chain configuration contract on the bill chain can be run on the second consensus node participating in the maintenance of the bill chain.
  • the chain configuration contract of the bill chain records the configuration items of this chain (such as the size of the generated block, bill template, etc.).
  • sub-chain configuration contracts can also be deployed on business sub-chain 1 and business sub-chain 2, and the sub-chain configuration contract of the business sub-chain can specifically run on the sub-chain consensus node involved in maintaining the corresponding business sub-chain.
  • the chain configuration contract of the above-mentioned bill chain, the chain configuration contract of the contract chain, the subchain configuration contract in the business subchain 1, and the subchain configuration contract in the business subchain 2 all include two types of contract locks, namely, blocking chain configuration locks and non-blocking chain configuration locks.
  • the other blockchains can be one or more of the bill chain, the contract chain, and the business subchain; when the blocking chain configuration lock is obtained, the business of other blockchains can be locked through the blocking chain configuration lock, and other blockchains cannot perform normal business until the other blockchains are unlocked through the blocking chain configuration lock.
  • Other blockchains can only perform normal business.
  • a block buffer height (such as N) is provided.
  • N blocks can still be generated on other blockchains. After N blocks are generated, the other blockchain stops normal business and cannot generate new blocks until the other blockchains are unlocked through the non-blocking chain configuration lock. Only then can other blockchains perform normal business.
  • the management object can send a configuration transaction for cross-chain configuration of other blockchains to the management chain consensus node in the management chain based on the configuration transaction.
  • the management chain consensus node determines the transaction type of the configuration transaction, and when the transaction type is a blocking transaction type, the management chain consensus node can generate a first configuration transaction identifier corresponding to the configuration transaction based on the above chain management configuration contract.
  • the cross-chain relay detects the first configuration transaction identifier on the management chain, it can send a first lock acquisition transaction to other consensus nodes associated with other blockchains.
  • other blockchains can obtain the blocking chain configuration lock corresponding to the blocking transaction type of the above configuration transaction from the chain configuration contract on other blockchains according to the first lock acquisition transaction.
  • Other consensus nodes can configure the business status of other blockchains to the first business lock state through the above blocking chain configuration lock, and normal business on other blockchains is stopped at this time.
  • the configuration transaction involved in the embodiment of the present application refers to the cross-chain configuration of other blockchains
  • the configuration transaction may include at least one of the following: the chain identification of other blockchains to be cross-chain configured, and the cross-chain configuration items for configuring other blockchains.
  • other blockchains are invoice chains
  • the above-mentioned management object may be the administrator who manages the invoice chain.
  • the above-mentioned configuration transaction may include the chain identification of the invoice chain, updating the invoice template in the invoice chain, configuring the tax calculation rules, etc.
  • other blockchains are application contract chains
  • the above-mentioned management object may be the government cooperation department, business-related department, etc. that manages the application contract chain.
  • the above-mentioned configuration transaction may include the chain identification of the application contract chain, updating the application development rules in the application contract chain, etc. wait.
  • the cross-chain relay can send a first lock declaration transaction to the management chain consensus node, so that the management chain consensus node on the management chain determines that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction lock state based on the first lock declaration transaction.
  • Generate the first transaction lock information corresponding to the first lock declaration transaction and generate a block for the first transaction lock information, and write it into the management chain after other consensus nodes in the management chain network reach consensus on the block.
  • the management object sends a configuration modification transaction based on the first transaction lock information on the management chain.
  • the management chain consensus node in the management chain can obtain the first cross-chain configuration item in the configuration modification transaction, and cross-chain configure the first cross-chain configuration item to other blockchains through the cross-chain relay, so that other consensus nodes unlock other blockchains in the first business lock state through the blocking chain configuration lock.
  • the management chain consensus node can generate a second configuration transaction identifier corresponding to the configuration transaction based on the above-mentioned chain management configuration contract.
  • the cross-chain relay detects the second configuration transaction identifier on the management chain, it can send a second lock acquisition transaction to other consensus nodes associated with other blockchains.
  • Other blockchains obtain the non-blocking chain configuration lock and block buffer height corresponding to the above-mentioned non-blocking transaction type from the chain configuration contract on other blockchains according to the second lock acquisition transaction.
  • the interval height of the blocks generated on other blockchains reaches the block buffer height, other consensus nodes can configure the business status of other blockchains to the second business lock state through the non-blocking chain configuration lock, and normal business on other blockchains is stopped at this time.
  • the second lock declaration transaction sent by the cross-chain relay to the second consensus node enables the management chain consensus node on the management chain to determine that the state of the configuration transaction corresponding to the second configuration transaction identifier is the second transaction lock state based on the second lock declaration transaction.
  • Generate the second transaction lock information corresponding to the second lock declaration transaction generate a block with the second transaction lock information, and write it into the bill chain after consensus on the block.
  • the management object sends a configuration modification transaction based on the second transaction lock information on the management chain.
  • the management chain consensus node in the management chain can obtain the second cross-chain configuration item in the configuration modification transaction, and cross-chain configure the second cross-chain configuration item to other blockchains through the cross-chain relay, so that other consensus nodes unlock other blockchains in the second business lock state through non-blocking chain configuration locks.
  • the consensus node involved in the embodiments 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, content delivery networks (CDN), as well as big data and artificial intelligence platforms.
  • 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, content delivery networks (CDN), as well as big data and artificial intelligence platforms.
  • a prompt interface or pop-up window can be displayed when obtaining data such as the management permission certificate of the management object.
  • the prompt interface or pop-up window is used to prompt the management object that it is currently collecting management permission certificates. Only after the management object issues a confirmation operation on the prompt interface or pop-up window, the relevant steps for data acquisition are started, otherwise it ends.
  • Figure 4 is a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • the method can be executed by a management chain consensus node associated with the above management chain, for example, the management chain consensus node can be any consensus node in the consensus network 100a shown in Figure 1 above.
  • the method can specifically include the following steps.
  • Step S401 When receiving a configuration transaction, determine the transaction type of the configuration transaction.
  • the configuration transaction is used to configure other blockchains across chains.
  • the configuration transaction is sent by the management object based on the configuration transaction.
  • the management object involved in the embodiment of the present application may be a management user of other blockchains (such as other blockchains).
  • the application contract chain in the above blockchain electronic bill platform, the management object can be a government cooperation department, a business-related department, etc.), and the configuration transaction includes the chain identifier of other blockchains.
  • the above multi-blockchain can include a management chain, a business main chain managed by the management chain consensus node through the management chain, and a business sub-chain independent of the business main chain.
  • the above business main chain includes one or more of the bill chain and the contract chain independent of the management chain.
  • the bill chain network corresponding to the above-mentioned bill chain is independent of the contract chain network corresponding to the contract chain.
  • the management chain network corresponding to the management chain can be isolated from other blockchain networks corresponding to other blockchains through cross-chain relays, that is, the management chain network and other blockchain networks interact with each other through cross-chain relays.
  • the management chain network and the bill chain network corresponding to the bill chain can be isolated through cross-chain relays, and the management chain network and the bill chain network interact with each other through cross-chain relays;
  • the management chain network and the contract chain network corresponding to the contract chain can be isolated through cross-chain relays, and the management chain network and the contract chain network interact with each other through cross-chain relays.
  • the management chain network and the sub-chain consensus network corresponding to the business sub-chain can be isolated through cross-chain relays, and the management chain network and the sub-chain consensus network interact with each other through cross-chain relays.
  • the subchain consensus network corresponding to the business subchain is jointly established by the consensus nodes in the bill chain network corresponding to the bill chain and the consensus nodes in the contract chain network corresponding to the contract chain; the business subchain is created by the business object requesting to execute the target business through the management chain consensus node; one target business corresponds to one business subchain.
  • the business object such as enterprise A, individual user, etc.
  • the consensus node voted from the consensus node in the bill chain network and the consensus node voted from the consensus node in the contract chain network can jointly create a subchain consensus network for processing the target business.
  • the consensus node in the subchain consensus network can also be called a verification node.
  • the target business is to verify whether the format of 100 invoices is correct; at this time, the business object can request the management chain consensus node in the management chain network to execute the target business, and the management chain consensus node can perform authorization verification on the business object, and after the authorization verification, the consensus nodes voted by the bill consensus nodes in the bill chain network and the consensus nodes voted by the consensus nodes in the application contract chain network form a sub-chain consensus network for verifying the format of 100 invoices.
  • the consensus nodes in the sub-chain consensus network can verify whether the format of 100 invoices is correct and return the final execution result to the business object.
  • the number of other blockchains can be one or more, and the embodiments of the present application do not limit this.
  • the other blockchain can be a business subchain or a business main chain.
  • the above-mentioned blockchain electronic bill platform can include a management chain, a business main chain including a bill chain, an application contract chain, a business subchain 1, and a business subchain 2.
  • Other blockchains can be bill chains, application contract chains, or business subchains.
  • multiple other blockchains can include business subchains and business main chains.
  • the above-mentioned blockchain electronic bill platform can include a business main chain (i.e., a bill chain and an application contract chain independent of the management chain) and two business subchains independent of the business main chain (i.e., business subchain 1 and business subchain 2), and multiple other blockchains can include the above-mentioned bill chain, application contract chain, and business subchain 1; or multiple other blockchains can include the above-mentioned bill chain and business subchain 2.
  • a business main chain i.e., a bill chain and an application contract chain independent of the management chain
  • business subchain 1 and business subchain 2 two business subchains independent of the business main chain
  • multiple other blockchains can include the above-mentioned bill chain, application contract chain, and business subchain 1; or multiple other blockchains can include the above-mentioned bill chain and business subchain 2.
  • a business object when a business object wants to perform cross-chain configuration on a certain blockchain (i.e., other blockchains), it can send a configuration transaction for cross-chain configuration of other blockchains to the management chain consensus node in the management chain network based on the configuration transaction.
  • the management chain consensus node receives the configuration transaction for cross-chain configuration of other blockchains sent by the management object based on the configuration transaction, it can obtain the management permission certificate of the management object and verify the management permission certificate of the management object. If the verification is passed, the transaction type of the configuration transaction is determined. It can be understood that the transaction type of the configuration transaction can also be specified in the above configuration transaction, and the management chain consensus node can directly determine the transaction type of the configuration transaction in the configuration transaction.
  • the transaction types involved in the embodiments of the present application can be divided into blocking transaction types and non-blocking transaction types.
  • Different configuration transaction identifiers corresponding to the configuration transaction can be generated according to the differences between the blocking transaction type and the non-blocking transaction type.
  • step S402 can be executed to generate a first configuration transaction identifier.
  • Step S402 When the transaction type of the configured transaction is a blocking transaction type, call the chain management configuration on the management chain The contract executes the configuration transaction and generates a first configuration transaction identifier corresponding to the configuration transaction; the first configuration transaction identifier is used to instruct the cross-chain relay to send a first configuration lock acquisition transaction to other consensus nodes; the first configuration lock acquisition transaction is used to instruct other consensus nodes to obtain a blocking chain configuration lock corresponding to the blocking transaction type from the chain configuration contract on other blockchains, and configure the business status of other blockchains to the first business lock state through the blocking chain configuration lock.
  • the first configuration transaction identifier is used to represent the transaction identifier of the above configuration transaction, and the first configuration transaction identifier can be a number, a character, or a string consisting of data and characters.
  • calling the chain management configuration contract on the management chain to execute the configuration transaction corresponding to configuration transaction x can generate a configuration transaction identifier ID-x corresponding to configuration transaction x.
  • the management chain consensus node can call the chain management configuration contract on the management chain to execute the configuration transaction, and the generation of the first configuration transaction identifier corresponding to the configuration transaction may include the following two methods:
  • the above configuration transaction is for cross-chain configuration of multiple other blockchains.
  • the configuration resources indicated by the above configuration transaction belong to global configuration resources
  • the chain management configuration contract corresponding to the global configuration resources is the platform configuration contract on the management chain.
  • global configuration resources are resources configured for all blockchains, and global configuration resources may include cross-chain configuration items.
  • the cross-chain configuration items in the global configuration resources will be configured on multiple other blockchains.
  • the cross-chain configuration items can be for modifying the chain names on multiple other blockchains and modifying the block times on multiple other blockchains.
  • the platform configuration contract includes two configuration methods, a blocking transaction configuration method and a non-blocking transaction configuration method.
  • the above transaction type can be used to determine the configuration method to be called by the management chain consensus node when performing cross-chain configuration.
  • the management chain consensus node writes the configuration transaction into the platform configuration contract, and then determines that the configuration method to be executed is the blocking transaction configuration method in the platform configuration contract according to the blocking transaction type, and calls the blocking transaction configuration method to execute the configuration transaction, and obtains the chain identifiers of multiple other blockchains indicated by the configuration transaction. Then, based on the chain identifiers of multiple other blockchains, a first configuration transaction identifier corresponding to the configuration transaction can be generated.
  • Other blockchains may be bill chains, contract chains or business sub-chains.
  • the bill chains and contract chains may be managed by the management chain consensus node through the full platform configuration contract on the management chain, and the full platform configuration contract includes the chain management configuration contract.
  • the chain management configuration contract corresponding to the independent configuration resource is the other blockchain management configuration contract on the management chain;
  • the other blockchain management configuration contract may include a chain management configuration contract for configuring the bill chain, a chain management configuration contract for configuring the contract chain, or a sub-chain management configuration contract for configuring the business sub-chain.
  • the independent configuration resources here refer to resources that are configured separately for a certain blockchain, such as configuring the block size of other blockchains separately, upgrading the business on other blockchains, etc.
  • the other blockchain management configuration contract includes a chain management configuration contract for configuring the bill chain.
  • the transaction type of the configuration transaction is a blocking transaction type
  • the configuration transaction can be written into the chain management configuration contract of the bill chain, and then the blocking transaction configuration method in the chain management configuration contract of the bill chain is called to execute the configuration transaction, and the chain identifier of the bill chain indicated by the configuration transaction is obtained, and based on the chain identifier of the bill chain, the first configuration transaction identifier corresponding to the configuration transaction is generated.
  • the other blockchain management configuration contract includes a chain management configuration contract for configuring the contract chain.
  • the transaction type of the configuration transaction is a blocking transaction type
  • the configuration transaction can be written into the chain management configuration contract of the contract chain, and then the blocking transaction configuration method in the chain management configuration contract of the contract chain is called to execute the configuration transaction, and the chain identifier of the contract chain indicated by the configuration transaction is obtained, and based on the chain identifier of the contract chain, a first configuration transaction identifier corresponding to the configuration transaction is generated.
  • the other blockchain management configuration contract includes a subchain management configuration contract for configuring the business subchain.
  • the transaction type of the configuration transaction is a blocking transaction type
  • the configuration transaction can be written into the subchain management configuration contract, and then the blocking transaction configuration method in the subchain management configuration contract is called to execute the configuration transaction, and the chain identifier of the business subchain indicated by the configuration transaction is obtained, and based on the chain identifier of the business subchain, a first configuration transaction identifier corresponding to the configuration transaction is generated.
  • Step S403 receiving a first lock declaration transaction sent by the cross-chain relay; the first lock declaration transaction is determined by the cross-chain relay when it detects that other blockchains are in a first business lock state.
  • the cross-chain relay when the cross-chain relay detects that other blockchains are in the first business lock state, it can generate a first lock declaration transaction based on the first business lock state and send the first lock declaration transaction to the cross-chain relay.
  • the management chain consensus node can receive the first lock declaration transaction sent by the cross-chain relay.
  • the first lock declaration transaction can be used to declare that other blockchains have been successfully locked and normal business cannot be carried out on the other blockchains, or to declare that the first configuration transaction identifier is locked successfully, that is, to let the management chain consensus node associated with the management chain determine that the status of the configuration transaction corresponding to the first configuration transaction identifier is in the first transaction lock state.
  • Step S404 when it is determined that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction lock state, generate first transaction lock information corresponding to the first lock declaration transaction, write the first transaction lock information into the management chain, and the state of the configuration transaction is determined based on the first lock declaration transaction.
  • the management chain consensus node can determine that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction locked state based on the first lock declaration transaction, and when determining that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction locked state, generate the first transaction lock information corresponding to the first lock declaration transaction, and package the first transaction lock information into a block, and reach a consensus through other consensus nodes in the management chain network, and then write the block into the management chain after the consensus is passed.
  • the first transaction lock information can be used to indicate that the resources associated with the configuration transaction have been locked on other blockchains, and other blockchains are temporarily unable to conduct normal business.
  • the first cross-chain configuration item indicates the configuration resources that need to be configured for other blockchains.
  • the first cross-chain configuration item can indicate the update of the bill template resource for the bill chain; for example, the first cross-chain configuration item indicates the configuration of the block size resource for the bill chain.
  • Step S405 When the configuration modification transaction is obtained, the first cross-chain configuration item in the configuration modification transaction is obtained, and the first cross-chain configuration item is cross-chain configured to other blockchains through cross-chain relay, so that other consensus nodes unlock other blockchains in the first business locking state through blocking chain configuration locks; the configuration modification transaction is sent by the management object based on the first transaction locking information on the management chain.
  • the management object obtains the first transaction locking information from the management chain, and knows that the other blockchains have been locked successfully. It can send a configuration modification transaction for other blockchains to the associated management chain consensus node on the management chain, and the configuration modification transaction includes the first cross-chain configuration item; the management chain consensus node receives the above configuration modification transaction, and obtains the first cross-chain configuration item from the configuration modification transaction, and then cross-chain configures the first cross-chain configuration item to other blockchains through the cross-chain relay.
  • the management chain consensus node on the management chain can receive the configuration transaction for cross-chain configuration of other blockchains, and when the transaction type of the configuration transaction is a blocking transaction type, execute the above configuration transaction to generate the first configuration transaction identifier corresponding to the configuration transaction; then, the first configuration transaction identifier can be used to enable other consensus nodes to obtain the blocking chain configuration lock corresponding to the blocking transaction type, and lock the business status of other blockchains through the blocking chain configuration lock, and after locking the business status of other blockchains, the cross-chain configuration items configured for other blockchains on the management chain are configured to other blockchains through cross-chain relays.
  • the embodiment of the present application can uniformly manage the configuration information of other chains through the management chain consensus node (for example, 10a shown in Figure 1 above) on the management chain to ensure the consistency of the configuration information on the chain.
  • the management chain consensus node can generate corresponding transaction lock information and write it into the management chain, which can also effectively guarantee the auditability and traceability of the configuration of other blockchains; in addition, the introduction of a configuration mechanism such as a blocking chain configuration lock can realize the synchronous effectiveness of the configuration, ensure the strict execution of the business logic, and also ensure the consistency and reliability of the configuration information on each independent blockchain.
  • Figure 5 is a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application, which can be executed by a management chain consensus node associated with the above management chain
  • the management chain consensus node can be any consensus node in the consensus network 100a shown in Figure 1 above.
  • the method can specifically include the following steps.
  • Step S501 When receiving a configuration transaction, determine the transaction type of the configuration transaction.
  • the configuration transaction is used to configure other blockchains across chains.
  • the configuration transaction is sent by the management object based on the configuration transaction.
  • Step S502 When the transaction type of the configured transaction is a blocking transaction type, call the chain management configuration on the management chain The contract executes the configuration transaction and generates a first configuration transaction identifier corresponding to the configuration transaction; the first configuration transaction identifier is used to instruct the cross-chain relay to send a first configuration lock acquisition transaction to other consensus nodes associated with other blockchains; the first configuration lock acquisition transaction is used to instruct other consensus nodes to obtain a blocking chain configuration lock corresponding to a blocking transaction type from a chain configuration contract on other blockchains, and configure the business state of other blockchains to a first business lock state through the blocking chain configuration lock;
  • Step S503 receiving a first lock declaration transaction sent by the cross-chain relay; the first lock declaration transaction is determined by the cross-chain relay when detecting that other blockchains are in a first business lock state;
  • Step S504 when it is determined based on the first lock declaration transaction that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction lock state, generate first transaction lock information corresponding to the first lock declaration transaction, and write the first transaction lock information into the management chain;
  • Step S505 When the configuration modification transaction is obtained, the first cross-chain configuration item in the configuration modification transaction is obtained, and the first cross-chain configuration item is cross-chain configured to other blockchains through cross-chain relay, so that other consensus nodes unlock other blockchains in the first business lock state through blocking chain configuration locks.
  • the configuration modification transaction is sent by the management object based on the first transaction lock information on the management chain.
  • Step S506 When the transaction type of the configuration transaction is a non-blocking transaction type, the chain management configuration contract on the management chain is called to execute the configuration transaction, and a second configuration transaction identifier corresponding to the configuration transaction is generated; the second configuration transaction identifier is used to instruct the cross-chain relay to send a second configuration lock acquisition transaction to other consensus nodes associated with other blockchains; the second configuration lock acquisition transaction is used to instruct other consensus nodes to obtain a non-blocking chain configuration lock corresponding to the non-blocking transaction type from the chain configuration contract on other blockchains, and configure the business status of other blockchains to the second business lock state through the non-blocking chain configuration lock.
  • the configuration transaction includes the chain identifier of other blockchains and the second cross-chain configuration item associated with the configuration transaction.
  • the second configuration transaction identifier is used to represent the transaction identifier of the above configuration transaction.
  • the second configuration transaction identifier can be a number, a character, or a string consisting of data and characters. For example, for configuration transaction x, calling the chain management configuration contract on the management chain to execute the configuration transaction corresponding to configuration transaction x can generate a configuration transaction identifier ID-x corresponding to configuration transaction x.
  • the management chain consensus node can call the chain management configuration contract on the management chain to execute the configuration transaction, and the generation of the second configuration transaction identifier corresponding to the configuration transaction may include the following two methods:
  • the multi-blockchain involved in this application includes a business main chain managed by a management chain consensus node through a management chain and a business sub-chain independent of the business main chain;
  • the business main chain includes one or more of a bill chain and a contract chain independent of the management chain;
  • the sub-chain consensus network corresponding to the business sub-chain is jointly established by the consensus nodes in the bill chain network corresponding to the bill chain and the consensus nodes in the contract chain network corresponding to the contract chain; wherein the bill chain network is independent of the contract chain network;
  • the business sub-chain is created by the business object requesting to execute the target business through the management chain consensus node authorization; one target business corresponds to one business sub-chain.
  • the multiple other blockchains include business subchains and business main chains; the above configuration transaction is for cross-chain configuration of multiple other blockchains.
  • the configuration resources indicated by the above configuration transaction belong to global configuration resources, and the chain management configuration contract corresponding to the global configuration resources is the platform configuration contract on the management chain.
  • the platform configuration contract includes two configuration methods, namely, blocking transaction configuration method and non-blocking transaction configuration method.
  • the configuration method to be called by the management chain consensus node when performing cross-chain configuration can be determined by the above transaction type.
  • the management chain consensus node can write the configuration transaction into the platform configuration contract, and then determine that the configuration method to be executed is the non-blocking transaction configuration method in the platform configuration contract according to the non-blocking transaction type, and call the non-blocking transaction configuration method to execute the configuration transaction, and obtain the chain identifiers of multiple other blockchains indicated by the configuration transaction and the second cross-chain configuration item. Then, based on the chain identifiers of multiple other blockchains and the second cross-chain configuration item, the second configuration transaction identifier corresponding to the configuration transaction can be generated.
  • Other blockchains can be bill chains, contract chains or business sub-chains.
  • the above-mentioned bill chains and contract chains are managed by the management chain.
  • the consensus node can be managed by the full platform configuration contract on the management chain.
  • the full platform configuration contract includes the chain management configuration contract.
  • the chain management configuration contract corresponding to the independent configuration resource is the other blockchain management configuration contract on the management chain;
  • the other blockchain management configuration contract includes the chain management configuration contract for configuring the bill chain, the chain management configuration contract for configuring the contract chain, or the sub-chain management configuration contract for configuring the business sub-chain.
  • the independent configuration resources here refer to resources that are configured separately for a certain blockchain, such as configuring the block size of other blockchains separately, upgrading the business on other blockchains, etc.
  • the other blockchain management configuration contract includes a chain management configuration contract for configuring the bill chain.
  • the transaction type of the configuration transaction is a non-blocking transaction type
  • the configuration transaction can be written into the chain management configuration contract of the bill chain, and then the non-blocking transaction configuration method in the chain management configuration contract of the bill chain is called to execute the configuration transaction, and the chain identifier and the second cross-chain configuration item of the bill chain indicated by the configuration transaction are obtained, and based on the chain identifier of the bill chain and the second cross-chain configuration item, the second configuration transaction identifier corresponding to the configuration transaction is generated.
  • the other blockchain management configuration contract includes a chain management configuration contract for configuring the contract chain.
  • the transaction type of the configuration transaction is a non-blocking transaction type
  • the configuration transaction can be written into the chain management configuration contract of the contract chain, and then the non-blocking transaction configuration method in the chain management configuration contract of the contract chain is called to execute the configuration transaction, and the chain identifier and the second cross-chain configuration item of the contract chain indicated by the configuration transaction are obtained, and based on the chain identifier of the contract chain and the second cross-chain configuration item, the second configuration transaction identifier corresponding to the configuration transaction is generated.
  • the other blockchain management configuration contract includes a subchain management configuration contract for configuring the business subchain.
  • the transaction type of the configuration transaction is a non-blocking transaction type
  • the configuration transaction can be written into the subchain management configuration contract, and then the non-blocking transaction configuration method in the subchain management configuration contract is called to execute the configuration transaction, and the chain identifier of the business subchain indicated by the configuration transaction is obtained, and based on the chain identifier of the business subchain, a second configuration transaction identifier corresponding to the configuration transaction is generated.
  • Step S507 receiving the second lock declaration transaction sent by the cross-chain relay; the second lock declaration transaction is determined by the cross-chain relay when it detects that other blockchains are in the second business lock state.
  • the cross-chain relay when the cross-chain relay detects that other blockchains are in the second business lock state, it can generate a second lock declaration transaction based on the second business lock state and send the second lock declaration transaction to the cross-chain relay.
  • the management chain consensus node can receive the second lock declaration transaction sent by the cross-chain relay.
  • the second lock declaration transaction can be used to declare that other blockchains have been successfully locked and that the other blockchains cannot conduct normal business, or to declare that the second configuration transaction identifier is locked successfully, that is, to allow the management chain consensus node associated with the management chain to determine that the status of the configuration transaction corresponding to the second configuration transaction identifier is in the second transaction lock state.
  • Step S508 When the state of the configuration transaction is the second transaction lock state, generate second transaction lock information corresponding to the second lock declaration transaction, write the second transaction lock information into the management chain, the configuration transaction is corresponding to the second configuration transaction identifier, and the state of the configuration transaction is determined based on the second lock declaration transaction.
  • the management chain consensus node can determine that the state of the configuration transaction corresponding to the second configuration transaction identifier is the second transaction locked state based on the second lock declaration transaction, and when determining that the state of the configuration transaction corresponding to the second configuration transaction identifier is the second transaction locked state, generate the second transaction lock information corresponding to the second lock declaration transaction, and package the second transaction lock information into a block, and reach a consensus through other consensus nodes in the management chain network, and then write the block to the management chain after the consensus is passed.
  • the second transaction lock information can be used to indicate that the resources associated with the configuration transaction have been locked on other blockchains, and normal business cannot be carried out on other blockchains temporarily.
  • the second cross-chain configuration item indicates the configuration resources that need to be configured on other blockchains.
  • the management chain consensus node on the management chain can receive configuration transactions for cross-chain configuration of other blockchains, and generate a corresponding configuration transaction identifier according to the transaction type of the configuration transaction (such as generating a first configuration transaction identifier according to a blocking transaction type, and generating a second configuration transaction identifier according to a non-blocking transaction type). Then the cross-chain relay uses the corresponding configuration transaction identifier to allow other consensus nodes to obtain the corresponding configuration lock (blocking chain configuration lock or non-blocking chain configuration lock). The corresponding configuration lock can be used to lock the business status on other blockchains. After locking the business status of other blockchains, the cross-chain configuration items configured for other blockchains on the management chain are configured to other blockchains through the cross-chain relay.
  • the embodiment of the present application can manage the configuration information of other chains in a unified manner through the management chain consensus node (for example, 10a shown in the aforementioned FIG. 1) on the management chain to ensure the consistency of the configuration information on the chain.
  • the management chain consensus node can generate corresponding transaction lock information and write it into the management chain, which can also effectively ensure the auditability and traceability of the configuration of other blockchains; in addition, the introduction of a configuration mechanism such as a configuration lock can ensure the consistency and reliability of the configuration information on each independent blockchain.
  • the multi-blockchain system includes an off-chain processing device, which determines at least two blockchains to be cross-chain processed in the multiple blockchains; the off-chain processing device collaborates with the management chain consensus node to perform cross-chain processing on at least two blockchains.
  • the off-chain processing device includes a cross-chain relay, and the cross-chain relay cooperates with the management chain consensus node to configure the cross-chain configuration item to at least one other blockchain.
  • Figure 6 is a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application, where the multiple blockchains include the management chain and other blockchains; the method is executed by the cross-chain relay; the cross-chain relay is used to isolate the management chain network corresponding to the management chain and other blockchain networks corresponding to other blockchains.
  • the method may specifically include the following steps.
  • Step S601 when the first configuration transaction identifier is detected, a first configuration lock acquisition transaction is sent to other consensus nodes in other blockchain networks; the first configuration transaction identifier corresponds to the configuration transaction on the first chain, and the first configuration transaction identifier is generated by calling the management configuration contract on the management chain to execute the configuration transaction when the transaction type of the configuration transaction in the configuration transaction is a blocking transaction type in the management chain consensus node in the management chain network, and the configuration transaction is sent by the management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used to instruct other consensus nodes to obtain the blocking chain configuration lock corresponding to the blocking transaction type from the chain configuration contract on other blockchains, and configure the business status of other blockchains to the first business lock state through the blocking chain configuration lock.
  • the configuration transaction includes the chain identifier of other blockchains.
  • the number of cross-chain relays involved in the embodiment of the present application can be multiple, and one cross-chain relay can correspond to one or more configuration transaction identifiers, that is, one cross-chain relay can forward transactions associated with the corresponding configuration transaction.
  • the cross-chain relay can send the first configuration lock acquisition transaction to other blockchains based on the first configuration transaction identifier. Only the cross-chain relay corresponding to the first configuration transaction identifier can forward the transaction associated with the first configuration transaction identifier.
  • the cross-chain relay when the cross-chain relay detects the first configuration transaction identifier corresponding to the configuration transaction on the management chain, it can generate a first configuration lock acquisition transaction based on the first configuration transaction identifier, and send the first configuration lock acquisition transaction to other consensus nodes in other blockchain networks.
  • Other consensus nodes in other blockchain networks can obtain the blocking chain configuration lock corresponding to the blocking transaction type from the chain configuration contract on other blockchains based on the first configuration lock acquisition transaction, and then configure the business status of other blockchains to the first business lock state through the blocking chain configuration lock.
  • the chain configuration contract of other blockchains may include two types of contract locks, namely, blocking chain configuration locks and non-blocking chain configuration locks.
  • the blocking chain configuration lock can be used to configure the business status on other blockchains to the first business lock state, and other blockchains in the first business lock state cannot continue to conduct normal business and generate new blocks. Normal business can only be restored when the first cross-chain configuration item configured for other blockchains is configured to other blockchains. Therefore, when the first cross-chain configuration item is subsequently cross-chain configured to other blockchains, the blocking chain configuration lock can be used to achieve full synchronization of the first cross-chain configuration item to be configured to other blockchains.
  • a block buffer height can be provided.
  • the block buffer height can be used to characterize the maximum interval height of blocks obtained on other blockchains before the business status of other blockchains is configured to the second business lock state through the non-blocking chain configuration lock. That is to say, before the business status on other blockchains is configured to the second business lock state, normal business can be carried out on other blockchains and new blocks can be generated.
  • the interval height of blocks obtained on other blockchains reaches the block buffer height
  • the business status of other blockchains is configured to the second business lock state.
  • the block buffer height is 100.
  • the business status of other blockchains can be configured to the second business lock state.
  • other blockchains stop conducting normal business and are not allowed to generate new blocks. Only when the cross-chain configuration items configured by other blockchains are configured to other The blockchain can restore the business on the chain. Through the non-blocking chain configuration lock, seamless configuration modification can be achieved, which is imperceptible to users and provides a better user experience.
  • the above configuration of the business status on other blockchains to the business lock state refers to locking the resources or parameters associated with the configuration transaction on other blockchains.
  • other configuration transaction identifiers will not be able to obtain any configuration locks (i.e., they will not be able to obtain blocking chain configuration locks and non-blocking chain configuration locks). Only when the blocking chain configuration lock is released can other configuration transaction identifiers obtain the configuration lock.
  • a cumulative lock duration threshold is set for the blocking chain configuration lock, and the cumulative lock duration threshold can be set according to demand, such as the cumulative lock duration threshold can be 1 hour, 30 minutes, two days, etc.
  • the cumulative lock duration threshold can be 1 hour, 30 minutes, two days, etc.
  • the cross-chain relay can accumulate the chain lock duration of other blockchains detected to be in the first business lock state, and when the accumulated chain lock duration reaches the cumulative lock duration threshold of the blocking chain configuration lock, a timeout release lock transaction is sent to other consensus nodes, wherein the timeout release lock transaction can be used to instruct other consensus nodes to call the lock release method in the chain configuration contract to release the blocking chain configuration lock, and change the business status of other blockchains from the first business lock state to the business unlock state.
  • the cross-chain relay starts to accumulate the chain lock duration when it detects that other blockchains are in the first business lock state, until the accumulated chain lock duration reaches the cumulative lock duration threshold, then a timeout release lock transaction can be sent to other consensus nodes. It should be understood that the use of the above-mentioned other configuration transaction identifiers will not be able to obtain any configuration locks and timeout mechanisms. This can ensure the consistency of configuration modifications under multi-chain concurrency and ensure the security of on-chain metadata.
  • Step S602 When it is detected that other blockchains are in the first business lock state, a first lock declaration transaction is sent to the management chain consensus node; the first lock declaration transaction is used to instruct the management chain consensus node to generate the first transaction lock information corresponding to the first lock declaration transaction for writing into the management chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the first transaction lock state based on the first lock declaration transaction.
  • the cross-chain relay can continuously send transaction data to other consensus nodes. If other consensus nodes in other blockchains cannot package the transaction data into blocks and do not return the execution results of the transaction data to the cross-chain relay, the cross-chain relay can detect that the other blockchain is in the first business lock state. If other consensus nodes in other blockchains package the transaction data into blocks and write them to other blockchains after consensus of other consensus nodes on other blockchains, and also return the execution results of the transaction data to the cross-chain relay, the cross-chain relay can detect that the other blockchain is not in the first business lock state.
  • the cross-chain relay when it is detected that other blockchains are not in the first business lock state, can send a first lock failure transaction to the management chain consensus node, and the first lock failure transaction can be used to declare that the first configuration transaction identifier has failed to lock, so that the management chain consensus node in the management chain network generates the first transaction lock failure information corresponding to the first lock failure transaction written into the management chain when it determines based on the first lock failure transaction that the state of the configuration transaction corresponding to the first configuration transaction identifier is not the first transaction lock state.
  • the first transaction lock failure information is used to indicate that other blockchains have failed to lock, and the management object can obtain the first transaction lock failure information from the management chain, so as to know that the configuration modification transaction cannot be submitted to achieve synchronous configuration.
  • the cross-chain relay can send a first lock failure release lock transaction to other consensus nodes, wherein the first lock failure release lock transaction is used to instruct other consensus nodes to call the lock release method in the chain configuration contract on other blockchains to release the blocking chain configuration lock.
  • Step S603 When a configuration modification transaction on the management chain is detected, the first cross-chain configuration item in the configuration modification transaction is obtained; the above configuration modification transaction is sent by the management object based on the first transaction lock information on the management chain.
  • the management object can send a configuration modification transaction to the management chain consensus node in the management chain network based on the first transaction locking information, and the cross-chain relay can detect whether there is a configuration modification transaction on the management chain.
  • the cross-chain relay can detect whether there is a configuration modification transaction on the management chain.
  • Step S604 cross-chain configure the first cross-chain configuration item to other blockchains, so that other consensus nodes unlock other blockchains in the first business locked state through a blocking chain configuration lock.
  • cross-chain configuration of the first cross-chain configuration item to other blockchains means that the cross-chain relay relays the first cross-chain configuration item to other blockchains, and then other blockchains can write the first cross-chain configuration item into the chain configuration contract of other blockchains, and after writing into the chain configuration contract of other blockchains, unlock the other blockchains in the first business locked state through the blocking chain configuration lock, thereby restoring normal business on other blockchains.
  • cross-chain configuration of the first cross-chain configuration item to other blockchains may be cross-chain configuration to other blockchains in the form of a transaction.
  • the cross-chain relay may construct a first lock release transaction based on the first cross-chain configuration item, and the first lock release transaction (Commit & Unclock) includes the first cross-chain configuration item.
  • the first lock release transaction is used to instruct other consensus nodes to call the lock release method in the chain configuration contract to release the blocking chain configuration lock when writing the first cross-chain configuration item to the chain configuration contract, and change the business status of other blockchains from the first business locked state to the business unlocked state.
  • other blockchains in the business unlocked state can conduct normal business.
  • the cross-chain relay corresponding to the first configuration transaction identifier can unlock the blocking chain configuration lock in other blockchains, that is, when sending the first lock release transaction to other consensus nodes, the first configuration transaction identifier can be carried in the first lock release transaction, so that other consensus nodes can write the first lock release transaction based on the first configuration transaction identifier into the chain configuration contract in other blockchains, and call the lock release method in the chain configuration contract to release the blocking chain configuration lock.
  • the management chain consensus node on the management chain can receive a configuration transaction for cross-chain configuration of the other blockchains, and when the transaction type of the configuration transaction is a blocking transaction type, execute the above configuration transaction to generate a first configuration transaction identifier corresponding to the configuration transaction; then, the first configuration transaction identifier can be used to allow other consensus nodes to obtain the blocking chain configuration lock corresponding to the blocking transaction type, and lock the business status of other blockchains through the blocking chain configuration lock, and after locking the business status of other blockchains, the cross-chain configuration items configured for other blockchains on the management chain are configured to other blockchains through cross-chain relays.
  • the embodiment of the present application can uniformly manage the configuration information of other chains through the management chain consensus node on the management chain to ensure the consistency of the configuration information on the chain.
  • a configuration mechanism such as a blocking chain configuration lock can realize the synchronous effectiveness of the configuration, ensure the strict execution of the business logic, and also ensure the consistency and reliability of the configuration information on each independent blockchain.
  • the multi-blockchain system includes an off-chain processing device, which determines at least two blockchains to be cross-chain processed in the multi-blockchain; the off-chain processing device cooperates with the management chain consensus node to perform cross-chain processing on at least two blockchains.
  • Cross-chain processing includes cross-chain configuration
  • the off-chain processing device includes a cross-chain relay.
  • Figure 7 is a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application, where the multiple blockchains include a management chain and other blockchains; the method is executed by a cross-chain relay; the cross-chain relay is used to isolate the management chain network corresponding to the management chain and other blockchain networks corresponding to other blockchains.
  • the method may specifically include the following steps.
  • Step S701 when the second configuration transaction identifier is detected, a second configuration lock acquisition transaction is sent to other consensus nodes in other blockchain networks.
  • the second configuration transaction identifier corresponds to the configuration transaction on the management chain.
  • the second configuration transaction identifier is generated when the management chain consensus node in the management chain network calls the management configuration contract on the management chain to execute the configuration transaction when the transaction type of the configuration transaction in the configuration transaction is a non-blocking transaction type.
  • the configuration transaction is sent by the management object requesting the execution of the configuration transaction; the second configuration lock acquisition transaction is used to instruct other consensus nodes to obtain the non-blocking chain configuration lock corresponding to the non-blocking transaction type from the chain configuration contract on other blockchains, and configure the business status of other blockchains to the second business lock state through the non-blocking chain configuration lock.
  • the configuration transaction includes the chain identifier of other blockchains and the second cross-chain configuration item associated with the above configuration transaction.
  • the second cross-chain configuration item includes the content that needs to be configured for other blockchains, such as the second cross-chain configuration item can be the block size generated by the configuration of the management chain.
  • the cross-chain relay when it detects the second configuration transaction identifier corresponding to the configuration transaction on the management chain, it can generate a second configuration lock acquisition transaction based on the second configuration transaction identifier, and send the second configuration lock acquisition transaction to other consensus nodes in other blockchain networks.
  • Other consensus nodes in other blockchain networks can obtain the non-blocking chain configuration lock corresponding to the non-blocking transaction type from the chain configuration contract on other blockchains based on the second configuration lock acquisition transaction, and then use the non-blocking chain configuration lock to configure the business status of other blockchains to the second business lock state.
  • the chain configuration contracts of other blockchains can include blocking chain configuration locks and non-blocking chain configuration locks.
  • the blocking chain configuration lock can be used to configure the business status on other blockchains to the first business lock state, and other blockchains in the first business lock state cannot generate new blocks and stop normal business. Normal business can only be restored when the first cross-chain configuration item configured for other blockchains is configured to other blockchains.
  • non-blocking chain configuration locks can provide a block buffer height. That is, other consensus nodes in other blockchains need to obtain the block cache height while obtaining the non-blocking chain configuration.
  • the block buffer height can be used to characterize the maximum interval height of blocks obtained on other blockchains before the business status of other blockchains is configured to the second business lock state through the non-blocking chain configuration lock. In other words, before the business status on other blockchains is configured to the second business lock state, normal business can be carried out on other blockchains. When the interval height of blocks obtained on other blockchains reaches the block buffer height, the business status of other blockchains is configured to the second business lock state. Normal business can only be restored after waiting for the second cross-chain configuration item configured by other blockchains to be configured to other blockchains. Through the non-blocking chain configuration lock, seamless configuration modification can be achieved, providing a better user experience.
  • the above configuration of the business status on other blockchains to the business lock state refers to locking the resources or parameters associated with the configuration transaction on other blockchains.
  • other configuration transaction identifiers will not be able to obtain any configuration locks (i.e., they will not be able to obtain the blocking chain configuration lock and the non-blocking chain configuration lock). Only after the non-blocking chain configuration lock is released, other configuration transaction identifiers can obtain the configuration lock.
  • the cross-chain relay before configuring the business status of other blockchains to the second business status through the non-blocking chain configuration lock, can send transaction data to other consensus nodes in other blockchain networks, and other consensus nodes can package the received transaction data into blocks and reach consensus through other consensus nodes in other blockchains. After the consensus is passed, the block is written into the other blockchain and the execution result of the transaction data is returned to the cross-chain relay.
  • Other consensus nodes can continuously determine the interval height of the blocks obtained on other blockchains. When the interval height of the blocks obtained on other blockchains reaches the block buffer height, the business status of other blockchains can be configured to the second business lock state through the non-blocking chain configuration lock.
  • Step S702 When it is detected that other blockchains are in the second business lock state, a second lock declaration transaction is sent to the management chain consensus node; the second lock declaration transaction is used to instruct the management chain consensus node to generate the second transaction lock information corresponding to the second lock declaration transaction for writing into the management chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the second transaction lock state based on the second lock declaration transaction.
  • the cross-chain relay still sends transaction data to other consensus nodes. If other consensus nodes cannot package the received transaction data into blocks, and cannot return the execution results of the transaction data to the cross-chain relay, it can be detected that the other blockchain is in the second business lock state. If other consensus nodes in other blockchains can still execute the packaging of the transaction data into blocks and return the execution results of the transaction data to the cross-chain relay, it can be detected that the other blockchain is not in the second business lock state.
  • the cross-chain relay when it is detected that other blockchains are not in the second business lock state, can send a second lock failure transaction to the management chain consensus node, and the second lock failure transaction can be used to declare that the second configuration transaction identifier has failed to lock, so that the management chain consensus node in the management chain network generates a second transaction lock failure information corresponding to the second lock failure transaction written into the management chain when it determines based on the second lock failure transaction that the state of the configuration transaction corresponding to the second configuration transaction identifier is not the second transaction lock state.
  • the second transaction lock failure information is used to indicate that other blockchains have failed to lock, and the management object can obtain the second transaction lock failure information from the management chain, and determine based on the second transaction lock failure information that it is currently impossible to perform cross-chain configuration on other blockchains.
  • the cross-chain relay can send a second lock failure release lock transaction to other consensus nodes, wherein the second lock failure release lock transaction is used to instruct other consensus nodes to call the lock release method in the chain configuration contract on other blockchains to release the non-blocking chain configuration lock.
  • Step S703 Cross-chain configure the second cross-chain configuration item to other blockchains, so that other consensus nodes unlock other blockchains in the second business locking state through non-blocking chain configuration locks.
  • the cross-chain relay does not need to detect whether there is a configuration modification transaction on the management chain.
  • the second cross-chain configuration item associated with the configuration transaction is included in the configuration transaction, and the cross-chain relay can directly configure the second cross-chain configuration item to other blockchains.
  • the cross-chain relay can relay the second cross-chain configuration item to other blockchains, and other blockchains can write the second cross-chain configuration item into the chain configuration contract of other blockchains, and after writing the chain configuration contract of other blockchains, unlock the other blockchains in the second business lock state through a non-blocking chain configuration lock, thereby restoring normal business on other blockchains.
  • the main difference between the blocking chain configuration lock and the non-blocking chain configuration lock is that there are two stages in the cross-chain configuration of other blockchains through the blocking chain configuration lock (i.e., the first stage is to initiate a configuration transaction to configure the business status of other blockchains to the first business lock state, and the second stage is to initiate a modification configuration transaction when the other blockchain is in the first business lock state, and configure the first cross-chain configuration item in the modification configuration transaction to other blockchains through the cross-chain relay).
  • the first stage can correspond to steps S601-S602
  • the second stage is steps S603-S604.
  • the two stages of cross-chain configuration of other blockchains through the blocking chain configuration lock can achieve synchronous effectiveness of cross-chain configuration and provide better consistency, but it will cause other blockchains to be temporarily unavailable.
  • cross-chain configuration of other blockchains is performed through non-blocking chain configuration locks, only one stage is required, namely, initiating a configuration transaction to configure the business status of other blockchains to the second business lock state.
  • the cross-chain relay detects that other blockchains are in the second business lock state, it can directly configure the second cross-chain configuration item in the configuration transaction to other blockchains; there is no need to initiate a modification configuration transaction when other blockchains are in the second business lock state.
  • cross-chain configuration without affecting the business of other blockchains can be achieved. Such cross-chain configuration is not perceived by users, providing a more convenient and friendly user experience.
  • the management chain consensus node on the management chain can receive a configuration transaction for cross-chain configuration of other blockchains, and when determining that the transaction type of the configuration transaction is a non-blocking transaction type, execute the above configuration transaction and generate a second configuration transaction identifier corresponding to the configuration transaction; the cross-chain relay can enable other consensus nodes to obtain the non-blocking chain configuration lock corresponding to the non-blocking transaction type through the second configuration transaction identifier, and lock the business status of other blockchains through the non-blocking chain configuration lock; then after locking the business status of other blockchains, the second cross-chain configuration item configured for other blockchains on the management chain is configured to other blockchains through the cross-chain relay.
  • the embodiment of the present application can uniformly manage the configuration information of other chains through the management chain consensus node on the management chain to ensure the consistency of the configuration information on the chain.
  • a configuration mechanism such as a non-blocking chain configuration lock can achieve seamless configuration modification, provide a better user experience, and also ensure the consistency and reliability of the configuration information on each independent blockchain.
  • FIG 8 is a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • the multiple blockchains include a management chain and other blockchains.
  • the method can be jointly executed by the management chain consensus node in the management chain network corresponding to the management chain, the cross-chain relay, and other consensus nodes in other blockchain networks corresponding to other blockchains.
  • the cross-chain relay can be used to isolate the management chain network from other blockchain networks.
  • the method can specifically include the following steps.
  • Step S801 The management chain consensus node receives a configuration transaction sent by the management object based on the configuration transaction for cross-chain configuration of other blockchains.
  • Step S802 The management chain consensus node determines the transaction type of the configuration transaction.
  • Step S803 When the transaction type of the configuration transaction is a blocking transaction type, the management chain consensus node calls the chain management configuration contract on the management chain to execute the configuration transaction and generates a first configuration transaction identifier corresponding to the configuration transaction.
  • Step S804 The cross-chain relay detects the first configuration transaction identifier corresponding to the configuration transaction on the management chain.
  • Step S805 When a first configuration transaction identifier corresponding to a configuration transaction on the management chain is detected, the cross-chain relay sends a first configuration lock acquisition transaction to other consensus nodes in other blockchain networks.
  • Step S806 Other consensus nodes obtain the blocking chain configuration lock corresponding to the blocking transaction type from the chain configuration contract on other blockchains, and configure the business status of other blockchains to the first business lock state through the blocking chain configuration lock.
  • consensus nodes receive the first configuration lock acquisition transaction sent by the cross-chain relay, and then The configuration lock acquisition transaction obtains the blocking chain configuration lock corresponding to the blocking transaction type from the chain configuration contract on other blockchains.
  • Step S807 When the cross-chain relay detects that other blockchains are in the first business locking state, it sends a first locking declaration transaction to the management chain consensus node.
  • the cross-chain relay when the cross-chain relay detects that other blockchains are in the first business locking state, it can generate a first locking declaration transaction based on the first business locking state.
  • the first locking declaration transaction can be used to declare that other blockchains have been successfully locked, or to declare that the first configuration transaction identifier has been successfully locked.
  • Step S808 When the management chain consensus node determines that the state of the configuration transaction corresponding to the configuration transaction identifier is the first transaction locked state based on the first lock declaration transaction, it generates first transaction locking information corresponding to the first lock declaration transaction and writes the first transaction locking information into the management chain.
  • the management chain consensus node receives the first lock declaration transaction sent by the cross-chain relay, and then determines based on the first lock declaration transaction that the state of the configuration transaction corresponding to the configuration transaction identifier is the first transaction lock state, and when determining that the state of the configuration transaction corresponding to the configuration transaction identifier is the first transaction lock state, it can generate first transaction lock information based on the first lock declaration transaction, and then reach a consensus on the first transaction lock information through other consensus nodes in the management chain except other consensus nodes, and after the consensus is passed, a block is generated according to the first transaction lock information and written into the management chain.
  • Step S809 The management chain consensus node receives the configuration modification transaction sent by the management object based on the first transaction lock information on the management chain.
  • Step S810 When obtaining the configuration modification transaction sent by the management object based on the first transaction lock information on the management chain, the management chain consensus node obtains the first cross-chain configuration item in the configuration modification transaction.
  • Step S811 When the cross-chain relay detects a configuration modification transaction on the management chain, it obtains the first cross-chain configuration item in the configuration modification transaction.
  • Step S812 The cross-chain relay configures the first cross-chain configuration item to other blockchains.
  • Step S813 Other consensus nodes unlock other blockchains in the first business locking state through a blocking chain configuration lock.
  • a cumulative lock duration threshold can be set for the blocking chain configuration lock.
  • Such a cumulative lock duration threshold can prevent the blocking chain configuration lock from being occupied by other blockchains and being unable to be used for other configuration transactions.
  • Other consensus nodes can accumulate the chain lock duration of other blockchains in the first business lock state. When the accumulated chain lock duration reaches the cumulative lock duration threshold of the blocking chain configuration lock, the other consensus nodes call the lock release method to release the blocking chain configuration lock and change the business state of the other blockchain from the first business lock state to the business unlock state.
  • the cross-chain relay may accumulate the chain lock duration of other blockchains detected to be in the first business lock state, and when the accumulated chain lock duration reaches the accumulated lock duration threshold of the blocking chain configuration lock, send a timeout release lock transaction to other consensus nodes. After receiving the timeout release lock transaction, other consensus nodes call the lock release method to release the blocking chain configuration lock, and change the business state of other blockchains from the first business lock state to the business unlock state.
  • the management chain consensus node on the management chain can receive a configuration transaction for cross-chain configuration of other blockchains.
  • the transaction type of the configuration transaction is a blocking transaction type
  • the above configuration transaction is executed to generate a first configuration transaction identifier corresponding to the configuration transaction; then, the first configuration transaction identifier is used to enable other consensus nodes to obtain a blocking chain configuration lock corresponding to the blocking transaction type, and the business status of other blockchains is locked through the blocking chain configuration lock; after locking the business status of other blockchains, the cross-chain configuration items configured for other blockchains on the management chain are configured to other blockchains through cross-chain relays.
  • the embodiment of the present application can uniformly manage the configuration information of other chains through the management chain consensus node on the management chain to ensure the consistency of the configuration information on the chain.
  • the management chain can generate corresponding transaction lock information and write it into the management chain, which can also effectively guarantee the auditability and traceability of the configuration of other blockchains;
  • the introduction of a configuration mechanism such as a blocking chain configuration lock can realize the synchronous effectiveness of the configuration, ensure the strict execution of the business logic, and also ensure that each blockchain is independent of each other. The consistency and reliability of the configuration information.
  • FIG. 9 is a cross-chain configuration method based on multiple blockchains provided in an embodiment of the present application.
  • the multiple blockchains include management chains and other blockchains.
  • the method can be jointly executed by the management chain consensus node in the management chain network corresponding to the management chain, the cross-chain relay, and other consensus nodes in other blockchain networks corresponding to other blockchains.
  • the cross-chain relay can be used to isolate the management chain network from other blockchain networks.
  • the method can specifically include the following steps.
  • Step S901 The management chain consensus node receives a configuration transaction sent by the management object based on the configuration transaction for cross-chain configuration of other blockchains.
  • Step S902 The management chain consensus node determines the transaction type of the configuration transaction.
  • Step S903 When the transaction type of the configuration transaction is a non-blocking transaction type, the management chain consensus node calls the chain management configuration contract on the management chain to execute the configuration transaction and generates a second configuration transaction identifier corresponding to the configuration transaction.
  • Step S904 When a second configuration transaction identifier corresponding to the configuration transaction on the management chain is detected, a second configuration lock acquisition transaction is sent to other consensus nodes in other blockchain networks.
  • Step S905 When a second configuration transaction identifier corresponding to the configuration transaction on the management chain is detected, a second configuration lock acquisition transaction is sent to other consensus nodes in other blockchain networks.
  • Step S906 Other consensus nodes obtain a non-blocking chain configuration lock corresponding to the non-blocking transaction type from the chain configuration contract on other blockchains, and configure the business status of other blockchains to the second business lock state through the non-blocking chain configuration lock.
  • Other consensus nodes receive the second configuration lock acquisition transaction sent by the cross-chain relay, and then obtain the non-blocking chain configuration lock corresponding to the non-blocking transaction type from the chain configuration contract on other blockchains according to the second configuration lock acquisition transaction.
  • Step S907 When the cross-chain relay detects that other blockchains are in the second business locking state, it sends a second locking declaration transaction to the management chain consensus node.
  • Step S908 When the management chain consensus node determines that the state of the configuration transaction corresponding to the configuration transaction identifier is the second transaction locked state based on the second lock declaration transaction, it generates second transaction locking information corresponding to the second lock declaration transaction, and writes the second transaction locking information corresponding to the second lock declaration transaction into the management chain.
  • the management chain consensus node receives the second lock declaration transaction sent by the cross-chain relay, and then determines based on the second lock declaration transaction that the state of the configuration transaction corresponding to the configuration transaction identifier is the second transaction lock state, and when determining that the state of the configuration transaction corresponding to the configuration transaction identifier is the second transaction lock state, it can generate second transaction lock information based on the second lock declaration transaction, generate a block for the second transaction lock information, and write the block including the second transaction lock information into the management chain after passing the consensus of other consensus nodes on the management chain.
  • Step S909 The cross-chain relay configures the second cross-chain configuration item associated with the configuration transaction to other blockchains.
  • Step S910 Other consensus nodes unlock other blockchains in the second business locking state through a non-blocking chain configuration lock.
  • the management chain consensus node on the management chain can receive a configuration transaction for cross-chain configuration of other blockchains.
  • the transaction type of the configuration transaction is a non-blocking transaction type
  • the above configuration transaction is executed to generate a second configuration transaction identifier corresponding to the configuration transaction; then the cross-chain relay can enable other consensus nodes to obtain the non-blocking chain configuration lock corresponding to the non-blocking transaction type through the first configuration transaction identifier, and lock the business status of other blockchains through the non-blocking chain configuration lock; after locking the business status of other blockchains, the second cross-chain configuration item configured for other blockchains on the management chain can be configured to other blockchains through the cross-chain relay.
  • the embodiment of the present application can uniformly manage the configuration information of other chains through the management chain consensus node on the management chain to ensure the consistency of the configuration information on the chain.
  • the management chain consensus node can generate corresponding transaction lock information and write it into the management chain, which can also effectively ensure the auditability and traceability of the configuration process of other blockchains; in addition, the introduction of a configuration mechanism such as a non-blocking chain configuration lock realizes seamless configuration modification, improves user experience, and ensures the consistency and reliability of configuration information on each independent blockchain.
  • the embodiment of the present application also provides a cross-chain data transmission processing system based on multiple blockchains.
  • Figure 10 is a schematic diagram of a cross-chain data transmission method based on multiple blockchains provided in an embodiment of the present application.
  • the cross-chain data transmission processing system based on multiple blockchains may include a consensus node associated with a management chain 301, a consensus node associated with a bill chain (also called an invoice chain) 302, a consensus node associated with an application contract chain 303, a consensus node associated with a business subchain 304, a cross-chain service terminal 305, and a user terminal 306.
  • the consensus node associated with the management chain 301 (also called the target chain) can be used to maintain the data on the management chain.
  • the consensus node associated with the management chain can be deployed with a subnet creation management contract to manage the creation of the business subchain, which will not be repeated here.
  • the consensus node of the management chain can also be used to manage the startup of the trusted cross-chain program of the cross-chain service terminal.
  • a corresponding business subchain can be created for a business, and a trusted cross-chain program for realizing the data chain between the source blockchain (such as the smart contract chain and the bill chain) and the business subchain is started, so as to ensure the security of cross-chain data transmission between the blockchain in the three-chain system and the external blockchain (i.e., the business subchain).
  • the consensus node associated with the management chain can also be deployed with a management component management contract to manage multiple management components, so as to detect the source blockchain such as the application contract chain on the application contract chain through the management component, and after the management component generates transaction detection information, the consensus node associated with the management chain can send a cross-chain transaction event to the cross-chain service terminal.
  • the consensus node associated with the bill chain 302 (also called the second chain) can be used to maintain the data on the bill chain, such as the full life cycle and various attributes of the invoice data on the bill chain.
  • the bill chain can be deployed with a bill business contract, which will not be described here.
  • the bill chain can also be deployed with a bill chain general resource cross-chain bridge contract, which can be used to instruct the consensus node associated with the bill chain to interact with the trusted cross-chain program in the cross-chain service terminal, and complete the cross-chain data transmission between the bill chain data and the business sub-chain.
  • the consensus node associated with the application contract chain 303 (also called the first chain) can be used to maintain data on the application contract chain, such as deploying business-related smart contracts. Smart contracts deployed on the application contract chain may include derivative business contracts, which are not described here.
  • a general resource cross-chain bridge contract can also be deployed on the application contract chain. The general resource cross-chain bridge contract can be used to instruct the consensus node associated with the application contract chain to interact with the trusted cross-chain program in the cross-chain service terminal to complete cross-chain data transmission between the data on the application contract chain and the business sub-chain.
  • the consensus node associated with the business subchain 304 can be used to maintain data on the business subchain.
  • the business subchain can be created by the consensus node associated with the management chain, that is, the creation of the business subchain needs to be authorized by the consensus node associated with the management chain, and then the consensus node associated with the management chain can create a business subchain based on the business subchain creation service.
  • the consensus nodes in the consensus network of the created business subchain can reuse the nodes in the consensus network associated with the bill chain or the application contract chain.
  • the business subchain shown in 304 in Figure 10 can be formed by determining the multiple bill chain verifiers and application contract chain verifiers to form the consensus network of the business subchain.
  • the consensus nodes associated with the business subchain can be determined according to the idleness of the consensus nodes in the consensus network of the bill chain and the application contract chain. For example, a relatively idle node can be selected as the consensus node of the business subchain, thereby reducing the data processing pressure of the busier nodes, thereby helping to improve the efficiency of business processing.
  • a subchain universal cross-chain bridge contract can be deployed on the business subchain. The subchain universal resource cross-chain bridge contract can be used to instruct the consensus node associated with the business subchain to interact with the trusted cross-chain program in the cross-chain service terminal to complete the cross-chain data transmission between the business subchain and the bill chain or application contract chain.
  • the business subchain is a subchain constructed in real time due to the needs of dedicated or special businesses. After the business is executed, data can also be extracted and destroyed. By constructing a business subchain to process the business, compared with directly processing the business based on the source blockchain, the space occupied on the source blockchain during business processing can be reduced.
  • the cross-chain service terminal 305 can be deployed with a trusted cross-chain program, which is in a trusted execution environment, so as to ensure the security of cross-chain data transmission operations.
  • the cross-chain service terminal is used to isolate the source blockchain and business sub-chain in multiple blockchains, and can be used to execute the above-mentioned cross-chain data transmission scheme based on multiple blockchains to realize cross-chain data transmission between the source blockchain and the business sub-chain.
  • the cross-chain service terminal can provide application contract chain cross-chain services to realize cross-chain data transmission between the application contract chain and the business sub-chain, and can also provide bill chain cross-chain services to realize cross-chain data transmission between the bill chain and the business sub-chain.
  • the core technology of the cross-chain service terminal to provide cross-chain services is Intel SGX (software guard extensions, a processor technology), which aims to use hardware security as a mandatory guarantee and does not rely on
  • the security status of firmware and software provides a trusted execution environment for user space.
  • SGX's trusted computing base TLB
  • SGX can ensure a trusted execution environment at runtime, and malicious code cannot access and tamper with the protection content of other programs at runtime, further enhancing the security of the system.
  • the user terminal 306 can be used to interact with the consensus nodes of the multi-blockchain in the above-mentioned multi-blockchain-based cross-chain data transmission processing system.
  • the user terminal can request the consensus node of the management chain to create a business sub-chain, as shown in steps S31 and S32, so that the management chain can create a business sub-chain based on the subnet management creation contract; for example, a cross-chain data transmission transfer request can be initiated to the consensus node of the bill chain or the application contract chain, and related business contract calls can be made to realize cross-chain transfer of resources to the business sub-chain, as shown in steps S33 and S34; for example, business interaction can be carried out with the consensus node of the business sub-chain, as shown in step S35, etc., which are not limited here.
  • the data processing process in the cross-chain data transmission processing system based on multiple blockchains is introduced in combination with the diagram.
  • the source blockchain is the contract chain (i.e., the above-mentioned application contract chain)
  • the business sub-processing sub-chain is the first business sub-chain.
  • the process of cross-chain data transmission between the application contract chain and the first business sub-chain is described.
  • Figure 11 is a schematic diagram of a cross-chain data transmission processing process based on multiple blockchains provided by an embodiment of the present application.
  • the management component 402 in the consensus node of the management chain 401 can detect the application contract chain 403 and the first business sub-chain 404, and specifically can detect the first address in the application contract chain and the second address in the first business sub-chain 404.
  • the first address is the aforementioned application contract chain transit address
  • the second address is also equivalent to the transit address on the first business sub-chain for transferring resources with the consensus node of the application contract chain.
  • the consensus node of the management chain 401 may also be deployed with a management component management contract to manage the management component, such as the blockchain address that can be used to configure the management component for detection; the consensus node of the management chain 401 may also be deployed with a trusted cross-chain program management contract to interact with the cross-chain service terminal for data, such as notifying the cross-chain service terminal 405 to start the first cross-chain program for realizing the data between the first business sub-chain and the application contract chain when receiving the first business object request to create the first business sub-chain 404.
  • a management component management contract to manage the management component, such as the blockchain address that can be used to configure the management component for detection
  • the consensus node of the management chain 401 may also be deployed with a trusted cross-chain program management contract to interact with the cross-chain service terminal for data, such as notifying the cross-chain service terminal 405 to start the first cross-chain program for realizing the data between the first business sub-chain and the application contract chain when receiving the first business object request to create the first business sub-
  • the management consensus node of the management chain 401 can send a cross-chain transaction event to the cross-chain service terminal 405, and then the cross-chain service terminal 405 can transfer the transaction resources in the first address in a locked state to the first business sub-chain 404 through the first cross-chain program.
  • the management consensus node of the management chain 401 can send a cross-chain transaction event to the cross-chain service terminal 405, and then the cross-chain service terminal 405 can transfer the transaction mapping resources in the second address in a destroyed state back to the application contract chain 403 through the first cross-chain program.
  • the specific process of cross-chain transactions based on the cross-chain service terminal 405 can refer to the embodiments corresponding to the following Figures 12 to 16.
  • this application can display a prompt interface, pop-up window or output voice prompt information, and the prompt interface, pop-up window or voice prompt information is used to prompt the user that its relevant data is currently being collected, so that this application only starts to execute the relevant steps of obtaining relevant data of users after obtaining the confirmation operation issued by the user to the prompt interface or pop-up window, otherwise (that is, when the confirmation operation issued by the user to the prompt interface or pop-up window is not obtained), the relevant steps of obtaining relevant data of users are terminated, that is, the relevant data of users are not obtained.
  • all user data collected by this application are collected with the consent and authorization of the user, and the collection, use and processing of relevant user data need to comply with the relevant laws, regulations and standards of relevant countries and regions.
  • the technical solution of the present application can be used in electronic devices, such as the cross-chain service terminal mentioned above.
  • the electronic device can be a terminal, a server, or other devices for data processing, which is not limited in the present application.
  • the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a 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, and big data and artificial intelligence platforms.
  • Cloud servers. Terminals include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, smart speakers, smart home appliances, etc.
  • the multi-blockchain system includes an off-chain processing device, which determines at least two blockchains to be cross-chain processed in multiple blockchains; the off-chain processing device collaborates with the management chain consensus node to perform cross-chain processing on at least two blockchains.
  • the off-chain processing device includes a cross-chain service terminal deployed with a trusted cross-chain program, and the cross-chain service terminal cooperates with the management chain consensus node to transmit the target transaction resources to the at least one other blockchain.
  • Figure 12 is a flow chart of a cross-chain data transmission method based on multiple blockchains provided in an embodiment of the present application.
  • the cross-chain data transmission method based on multiple blockchains can be executed by a cross-chain service terminal, and the trusted cross-chain program deployed by the cross-chain service terminal can be a first cross-chain program.
  • the source blockchain is a contract chain (also called an application contract chain) and the business sub-processing sub-chain is a first business sub-chain. For example, the process of transferring resources from the source blockchain to the business sub-chain is explained.
  • the cross-chain data transmission method based on multiple blockchains can include the following steps.
  • the first cross-chain program can be a trusted cross-chain program for realizing cross-chain data transmission between the contract chain (also called the application contract chain) and the first business sub-chain, and the first cross-chain program is in a trusted execution environment.
  • the management chain consensus node can be a consensus node associated with the above-mentioned target chain (i.e., the management chain), which will not be described here.
  • the first cross-chain transaction event is used to indicate that the management consensus node detects a cross-chain transaction that transfers transaction resources from the application contract chain to the first business subchain based on the first address, so that after receiving the first cross-chain transaction event through the first cross-chain program, the cross-chain transaction indicated by the first cross-chain transaction event (i.e., the first cross-chain transaction) can be executed.
  • the first address is determined by the first private key in the first cross-chain program, that is, the first cross-chain program can determine a corresponding first address on the application contract chain through the first private key.
  • the first private key is generated in a trusted execution environment.
  • the management consensus node can then determine whether it is necessary to send a cross-chain transaction event to the first cross-chain program by detecting the transaction resources in the first address and the status of the transaction resources.
  • the management consensus node when the management consensus node detects that there are transaction resources that need to be cross-chain in the first address on the application contract chain, it generates first cross-chain transaction detection information, and the transaction resources that need to be cross-chain are the target transaction resources transferred to the first address, and the target transaction resources are in a locked state. Further, the management consensus node can determine the first cross-chain transaction event to be sent to the first cross-chain program based on the first cross-chain transaction detection information, and send the first cross-chain transaction event to the first cross-chain program, so that the first cross-chain program in the cross-chain service terminal can perform cross-chain data transmission on the target transaction resource based on the indication of the first cross-chain transaction event.
  • the management consensus node includes N management components associated with the first address, where N is a positive integer; one management component is used to generate a transaction detection information in the first cross-chain transaction detection information when detecting that there is a target transaction resource in a locked state in the first address; and one transaction detection information in the first cross-chain transaction detection information corresponds to a transaction event in the first cross-chain transaction event.
  • the management consensus node detects the transaction resources and the status of the transaction resources in the first address through N management components, and the management component generates a transaction detection information in the first cross-chain transaction detection information when detecting that there is a target transaction resource in a locked state in the first address, so that the management consensus node can manage the transaction resources based on the management.
  • the first cross-chain transaction detection information detected by the processing component sends the first cross-chain transaction event to the cross-chain service terminal.
  • the first business subchain is created by the management consensus node associated with the management chain in the multi-blockchain according to the first business associated with the first business object.
  • the first business object can be an object that requests to execute the first business.
  • the first business needs to build a first business subchain to process the first business to obtain the corresponding business processing result and realize the processing of the first business.
  • the management consensus node receives the business subchain creation request of the first business object, and verifies the business authority of the first business object, and when the verification is passed, the management consensus node can create a first business subchain for processing the first business.
  • the first business subchain is established when the first business is to be processed, so that the data required for processing the first business is transferred from the application contract connection to the first business subchain, and the business processing is performed based on the first business subchain, reducing the space occupied by the business processing process on the first business subchain, and can improve the processing efficiency of the first business.
  • the target transaction resource may be a resource that needs to be transferred to the first business subchain.
  • the target transaction resource may be business data on the application contract chain.
  • the first business may be used to process the credit data of the first business object within a certain period of time to obtain the credit of the first business object. Then, the target transaction resource may be the credit data of the first business object within the certain period of time.
  • the first business object when the first business object needs to transfer the target transaction resources on the application contract chain to the first business sub-chain for processing, the first business object can initiate a first cross-chain transaction to the first consensus node associated with the application contract chain, and then the first consensus node transfers the target transaction resources of the first business object from the contract chain user address on the application contract chain to the first address, and adjusts the target transaction resources to a locked state.
  • the first consensus node can transfer the target transaction resources that the first business object needs to transfer to the first business sub-chain from the contract chain user address on the application contract chain to the first address by calling the first general resource cross-chain bridge contract deployed on the application contract chain, and determine the target transaction resources transferred to the first address as a locked state, so that the first cross-chain program in the subsequent cross-chain service terminal can transfer the target transaction resources from the first address to the first business sub-chain.
  • Target transaction resources in a locked state cannot be used to construct other transactions.
  • the present application is equivalent to using the first address as a transit address for resources, so that the first cross-chain program in the cross-chain service terminal can quickly detect cross-chain transactions based on the transaction detection information of the management consensus node for the first address, thereby realizing the cross-chain transfer of the target transaction mapping resources from the application contract chain to the first business sub-chain.
  • S1202 Use the target transaction resource in a locked state as the first transfer transaction resource, verify the first transfer transaction resource based on the first cross-chain transaction event, and when the verification is successful, construct a first cross-chain constructed transaction corresponding to the first cross-chain transaction based on the first transfer transaction resource.
  • the first cross-chain construction transaction is used to indicate the transfer of the first transfer transaction resource from the first address on the contract chain (also called the application contract chain) to the first business subchain. It can be understood that by verifying the first transfer transaction resource and constructing the cross-chain construction transaction only when the verification is successful, it helps to ensure the accuracy and security of transaction resources during the cross-chain data transmission process.
  • verifying the first transferred transaction resource based on the first cross-chain transaction event may include comparing and verifying the transaction resources associated with the transaction detection information corresponding to each transaction event in the first cross-chain transaction event, and may also include verifying the dependent data information associated with the first transferred transaction resource, which is not limited here.
  • the first cross-chain program can determine the first event number of transaction events associated with N management components from the received first cross-chain transaction event; the first event number is determined by the information number of transaction detection information in the first cross-chain transaction detection information associated with the N management components; the first event number is less than or equal to N; further, when the first event number reaches the event number threshold in N, the transaction detection information corresponding to the information number equal to the first event number is obtained; further, the transaction resource associated with each transaction detection information in the obtained first cross-chain transaction detection information is used as the first detection resource, and each first detection resource is compared to obtain a first transaction comparison result; further, if the first transaction comparison result indicates that the comparison is successful, then generate verification success indication information for determining that each first detection resource is a first transfer transaction resource, and when the verification is determined to be successful based on the verification success indication information, construct a first cross-chain construction transaction corresponding to the first cross-chain transaction based on the first transfer transaction resource.
  • the event quantity threshold may be a preset threshold.
  • the event quantity threshold may be greater than half of N, thereby ensuring the accuracy of the first cross-chain transaction event received by the cross-chain service terminal. For example, if only one management component performs detection, if the transaction detection information corresponding to the management component is tampered with, the cross-chain transaction event received by the cross-chain service terminal will be erroneous, resulting in the failure or error of the cross-chain transaction. However, by performing detection and sending corresponding transaction events through multiple management components, the difficulty of transaction events being tampered with is increased, and the accuracy of cross-chain events is ensured.
  • the transaction event received in the cross-chain transaction event exceeds the event quantity threshold and indicates the transfer of the same transaction resource
  • the event quantity threshold indicates the transfer of the same transaction resource
  • the first transaction comparison result can be used to indicate a successful comparison or a failed comparison. If the first detection resources are the same transaction resources, the first transaction comparison result indicates a successful comparison. Conversely, if the first detection resources are not the same transaction resources, the first transaction comparison result indicates a failed comparison. Therefore, by comparing and verifying each detection resource, it can be determined that the transaction detection information-associated transaction resources corresponding to the transaction events in the received cross-chain transaction events that are greater than or equal to the event quantity threshold are all the same, and are all the first transfer transaction resources, and then the first cross-chain construction transaction is constructed, which helps to improve the accuracy of the first cross-chain program's detection of the first cross-chain transaction, thereby better ensuring the security of cross-chain data transmission.
  • the management consensus node may include four management components, and the event quantity threshold is 3. Then, when it is detected that the first event quantity of the transaction event in the first cross-chain transaction event reaches 3, the transaction resources associated with the transaction detection information corresponding to the three transaction events may be compared and verified. When it is verified that the transaction resources associated with the transaction detection information corresponding to the three transaction events are the same, the same transaction resource is the first transfer transaction resource, and then the first cross-chain construction transaction may be constructed based on the first transfer transaction resource.
  • the cross-chain service terminal can also obtain the dependent data information corresponding to the first transfer transaction resource from the contract chain; further, verify the dependent data information, and when the information verification is successful, construct the first cross-chain construction transaction corresponding to the first cross-chain transaction based on the dependent data information and the first transfer transaction resource.
  • the dependent data information may include the resource usage of the first transfer transaction resource that the first transfer transaction resource may include.
  • the first business may be used to process the credit investigation data of the first business object within a certain period of time to obtain the credit of the first business object, and the resource usage of the first transfer transaction resource may be to calculate the credit, thereby verifying the information of the dependent data information, such as verifying whether the first transfer transaction resource includes the data required for the resource usage of the first transfer transaction resource, to ensure the integrity of the first transfer transaction resource.
  • the dependent data information may also include associated data of the first transfer transaction.
  • the first transfer transaction resource is the credit data of the first business object within a certain period of time.
  • the credit data may include the loan time, repayment time and other information of each loan transaction.
  • the dependent data information of the credit data may include the purpose of the loan funds of each loan transaction and the transaction serial number involved, etc., thereby verifying the validity and integrity of the credit data through the dependent data information.
  • a first general resource cross-chain bridge contract for data interaction with the first cross-chain program is deployed on the application contract chain; the first general resource cross-chain bridge contract is used to instruct the first consensus node to specify the resource usage of the target transaction resources corresponding to the first cross-chain exchange when transferring the target transaction resources to the first address; the dependent data information includes resource usage.
  • the cross-chain service terminal can use the resource usage and the first transferred transaction resource as transaction parameters, and construct the first cross-chain construction transaction corresponding to the first cross-chain transaction based on the transaction parameters.
  • the second consensus node can determine the resource usage through the transaction parameters of the first cross-chain construction transaction, and then the second consensus node can determine the business processing method for the first transfer transaction resource based on the resource usage.
  • the first general resource cross-chain bridge contract can be called by the first consensus node when the first business object submits the first cross-chain transaction, thereby transferring the target transaction resources that need to be transferred across the chain to the first business sub-chain to the first address, and specifying the resource usage of the target transaction resources.
  • S1203. Determine the second address on the first business subchain through the first cross-chain program, and send the first cross-chain construction transaction to the second consensus node associated with the first business subchain based on the second address, so that the second consensus node casts the target transaction mapping resource corresponding to the first cross-chain construction transaction on the first business subchain through the second address; the target transaction mapping resource has the same resource data content as the target transaction resource.
  • the second address is determined by the second private key in the first cross-chain program; the second private key is generated by the master key in the first cross-chain program; the master key is determined by the trusted execution environment in which the first cross-chain program is located.
  • the master key can be a key at the highest level in the hierarchy of keys, and the first private key and the second private key can be generated based on the master key.
  • the master key is determined by the trusted execution environment in which the first cross-chain program is located, the security of the master key and the security and privacy of the first private key and the second private key generated based on the master key can be guaranteed, thereby ensuring the security of the entire cross-chain data transmission process to a certain extent.
  • the cross-chain service terminal can sign the first cross-chain constructed transaction through the second private key in the first cross-chain program to obtain the transaction signature information of the first cross-chain constructed transaction; further, when the first cross-chain constructed transaction is sent to the second consensus node associated with the first business sub-chain, the transaction signature information of the first cross-chain constructed transaction is synchronously sent to the second consensus node, so that the second consensus node verifies the transaction signature information based on the second public key corresponding to the second private key, and when the transaction verification is successful, the first cross-chain constructed transaction is obtained.
  • the cross-chain service terminal sends the first cross-chain construction transaction to the second consensus node
  • the transaction is signed by the second private key
  • the second consensus node can verify the transaction signature information, thereby verifying whether the cross-chain construction transaction is sent by an authorized cross-chain service terminal, and whether it is tampered with during the transmission of the first cross-chain construction transaction.
  • the second consensus node succeeds in verifying the transaction signature, it means that the cross-chain construction transaction is sent by an authorized cross-chain service terminal, and it has not been tampered with during the transmission of the first cross-chain construction transaction, and then the first cross-chain construction transaction can be obtained to realize the cross-chain transfer of the first transfer transaction resource.
  • the second consensus node fails to verify the transaction signature, it means that the cross-chain construction transaction is not sent by an authorized cross-chain service terminal, or it is tampered with during the transmission of the first cross-chain construction transaction, and then the first cross-chain construction transaction cannot be obtained to realize the cross-chain transfer of the first transfer transaction resource.
  • the second consensus node may also return a prompt message for transaction verification failure to the cross-chain service terminal to prompt the cross-chain service terminal that the first cross-chain constructed transaction verification failed. In this way, the transaction signature can be signed by the second private key of the cross-chain service terminal to ensure the security and legitimacy of the first cross-chain constructed transaction.
  • the second address is deployed with the contract name and contract address for calling the resource mapping contract on the first business sub-chain; the second consensus node is used to call the resource mapping contract through the contract name and contract address in the second address when obtaining the first cross-chain construction transaction, and cast the target transaction mapping resource corresponding to the first cross-chain construction transaction on the first business sub-chain.
  • the resource mapping contract (specifically the resource casting method therein) can be used to cast the transaction mapping resources corresponding to the transfer transaction resources indicated by the cross-chain construction exchange, such as the first transfer transaction resources indicated by the first cross-chain construction exchange can be used to cast the corresponding target transaction mapping resources.
  • the first cross-chain construction transaction is sent to the second consensus node through the second address, that is, the first cross-chain construction transaction is sent to the second consensus node through the contract name and contract address of the resource mapping contract deployed in the second address.
  • the second consensus node may cast a target transaction mapping resource corresponding to the first cross-chain constructed transaction on the first business subchain through the second address, and may cast a target transaction mapping resource corresponding to the first cross-chain constructed transaction on the first business subchain, and write the target transaction mapping resource into the second address.
  • the first private key and the second private key are both generated by the master key in the first cross-chain program; the first private key is different from the second private key.
  • the cross-chain service terminal can also split the master key to obtain N key fragments corresponding to N management components; one management component corresponds to one key fragment; the N key fragments are sent to the management chain consensus node, so that the management chain consensus node configures a key fragment for each of the N management components; one management component is used to perform key backup for one key fragment.
  • the cross-chain service terminal can send the master key to the management consensus node for backup.
  • the master key can be split into 4 key fragments: ⁇ x1, x2, x3, x4 ⁇ .
  • the management consensus node can configure a key fragment for each management component, such as management component a is assigned to key fragment x1, management component b is assigned to key fragment x2, management component c is assigned to key fragment x3, and management component d is assigned to key fragment x4.
  • M key fragments sent by the management chain consensus node are received; one of the M key fragments comes from one of the N management components; M is a positive integer less than or equal to N; when M reaches the key quantity threshold corresponding to N, the master key is constructed based on the M key fragments.
  • the key quantity threshold can be determined based on N.
  • the key quantity threshold can be a target proportion of N.
  • the key quantity threshold can be 3/4 of N, then when N is 4, the key quantity threshold can be 3, and when N is 8, the key quantity threshold can be 6.
  • the key quantity threshold can be used to indicate the minimum key fragments required to recover the master key.
  • the key quantity threshold can be determined when the key is split.
  • the cross-chain service terminal obtains a key fragment greater than or equal to the key quantity threshold, it can restore the master key based on the obtained multiple key fragments. This method of backing up the master key can also be called the Shamir (a key sharing method) method.
  • the second consensus node can perform corresponding business processing based on the target transaction resource.
  • the second consensus node can transfer the target transaction mapping resource in the second address to the subchain user address corresponding to the first business object on the first business subchain, and then the second consensus node can process based on the target transaction mapping resource in the subchain user address of the first business object.
  • How the second consensus node performs business processing on the target transaction mapping resource can be indicated by the resource usage in the first cross-chain construction transaction; the second consensus node may also not transfer the target transaction mapping resource to the subchain user address, but directly process based on the target transaction mapping resource in the second address, which is not limited here.
  • the second consensus node after the second consensus node performs business processing based on the target transaction mapping resources, it can extract and destroy the resources on the first business subchain, and return the target transaction mapping resources to the application contract chain.
  • the business processing result corresponding to the first business can be obtained, and the business processing result can be written to the first business subchain.
  • the obtained business processing result can also be sent to the first consensus node, so that the first consensus node can respond accordingly based on the business processing result.
  • the business processing result is sent to the user terminal of the first business object, so that the first business object can clarify the processing result of the first business.
  • the first business is used to indicate the credit of the first business object within a certain period of time, and the loan authority of the first business object can be adjusted according to the credit indicated by the business processing result.
  • the multi-blockchain may include the source blockchain (i.e., the application contract chain and the bill chain) and the management chain under the three-chain system, and may also include a business sub-chain temporarily generated based on the business for business processing.
  • the business sub-chain is an external blockchain relative to the three-chain system.
  • the scheme can realize cross-chain data transmission between the source blockchain (such as the application contract chain) and the chain outside (i.e., the business sub-chain) through a cross-chain service terminal deployed with a trusted cross-chain program.
  • the cross-chain service terminal can receive the first cross-chain transaction event sent by the management consensus node associated with the management chain through the trusted cross-chain program, and use the target transaction resource in the first address of the source blockchain such as the application contract chain in a locked state as the transfer transaction resource, thereby constructing a corresponding cross-chain construction transaction based on the transfer transaction resource, and then determine the second address on the business sub-chain such as the first business sub-chain through the trusted cross-chain program, and send the cross-chain construction transaction to the consensus node associated with the business sub-chain based on the second address to realize cross-chain data transmission of the target transaction resource.
  • the cross-chain data transmission of business data in general business scenarios can be realized outside the chain through the trusted cross-chain program in the cross-chain service terminal.
  • the trusted cross-chain program is in a trusted execution environment and can verify cross-chain transactions, thereby ensuring the correctness of cross-chain data and helping to ensure the security of data cross-chain during the cross-chain data transmission and transfer process outside the chain.
  • Figure 13 is a multi-blockchain cross-chain data transmission method provided by an embodiment of the present application. As shown in Figure 13, the method can be executed by the above-mentioned cross-chain service terminal. The method can specifically include the following steps S1301-S1306.
  • S1302 Use the target transaction resource in a locked state as the first transfer transaction resource, verify the first transfer transaction resource based on the first cross-chain transaction event, and when the verification is successful, construct a first cross-chain constructed transaction corresponding to the first cross-chain transaction based on the first transfer transaction resource.
  • S1303. Determine the second address on the first business subchain through the first cross-chain program, and send the first cross-chain construction transaction to the second consensus node associated with the first business subchain based on the second address, so that the second consensus node casts the target transaction mapping resource corresponding to the first cross-chain construction transaction on the first business subchain through the second address; the target transaction mapping resource has the same resource data content as the target transaction resource.
  • the second cross-chain transaction event is used to indicate that the management consensus node detects a cross-chain transaction that transfers transaction resources from the first business subchain to the application contract chain based on the second address, so that after receiving the second cross-chain transaction event through the first cross-chain program, the cross-chain transaction indicated by the second cross-chain transaction event (i.e., the second cross-chain transaction) can be executed.
  • the second address is determined by the second private key in the first cross-chain program, that is, the first cross-chain program can determine a corresponding second address on the first business subchain through the second private key.
  • the management consensus node can then determine whether it is necessary to send a cross-chain transaction event to the first cross-chain program by detecting the transaction mapping resources in the second address and the status of the transaction mapping resources.
  • the management consensus node when the management consensus node detects that there is a transaction mapping resource that needs to be cross-chain in the second address on the first business subchain, it generates a second cross-chain transaction detection information, and the transaction mapping resource that needs to be cross-chain is the target transaction mapping resource transferred to the second address, and the target transaction mapping resource is in a destroyed state. Further, the management consensus node can determine the second cross-chain transaction event to be sent to the first cross-chain program based on the second cross-chain transaction detection information, and send the second cross-chain transaction event to the first cross-chain program, so that the first cross-chain program in the cross-chain service terminal can perform cross-chain data transmission on the target transaction mapping resource based on the indication of the second cross-chain transaction event.
  • the management consensus node includes N management components associated with the second address, N is a positive integer; a management component is used to generate a transaction detection information in the second cross-chain transaction detection information when detecting that there is a target transaction mapping resource in the destruction state in the second address; a transaction detection information in the first cross-chain transaction detection information corresponds to a transaction event in the first cross-chain transaction event.
  • the management consensus node detects the transaction resources and the status of the transaction resources in the second address through N management components, and the management component generates a transaction detection information in the second cross-chain transaction detection information when detecting that there is a target transaction mapping resource in the destruction state in the second address, so that the management consensus node sends the second cross-chain transaction event to the cross-chain service terminal based on the second cross-chain transaction detection information detected by the management component.
  • the target transaction mapping resource can be a transaction mapping resource cast by the second consensus node based on the target transaction resource associated with the first cross-chain transaction.
  • the target transaction mapping resource has the same resource data content as the target transaction resource.
  • the first business object when the first business object needs to return the target transaction mapping resource on the first business processing chain to the application contract chain, the first business object can initiate a second cross-chain transaction to the second consensus node, and then the second consensus node adjusts the target transaction mapping resource existing in the second address to a destroyed state.
  • the second consensus node can transfer the target transaction mapping resource in the subchain user address to the second address and adjust the target transaction mapping resource to a destroyed state; if the target transaction mapping resource is not transferred to the subchain user address of the first business object on the first business subchain during business processing, then when the first business object initiates the second cross-chain transaction to the second consensus node, the second consensus node directly adjusts the target transaction mapping resource in the second address to a destroyed state.
  • the second consensus node can transfer the target transaction mapping resource that the first business object needs to return to the application contract chain from the subchain user address on the first business subchain to the second address by calling the second general resource cross-chain bridge contract deployed on the first business subchain, and determine the target transaction mapping resource transferred to the second address as a destroyed state, so that the first cross-chain program in the subsequent cross-chain service terminal can transfer the target transaction mapping resource from the second address to the application contract chain.
  • the target transaction mapping resource in the second address is in a destroyed state, but the destruction has not been completed, so the management consensus node can detect the resource information of the target transaction mapping resource in the destroyed state.
  • the second consensus node can indirectly call the resource mapping contract (specifically the resource destruction method therein) by calling the second general resource cross-chain to destroy the target transaction mapping resource transferred to the second address, so that the target transaction mapping resource in the second address is in a destroyed state.
  • the present application is equivalent to using the second address as the transit address of the mapping resource, which facilitates the first cross-chain program in the cross-chain service terminal to quickly detect the cross-chain transaction based on the transaction detection information of the management consensus node for the second address, thereby realizing the cross-chain transfer of the target transaction mapping resource from the first business subchain to the application contract chain.
  • the second consensus node after the second consensus node performs business processing based on the target transaction mapping resources, it can obtain the business processing results corresponding to the first business, and the second cross-chain transaction can also indicate that the business processing results are transferred from the first business sub-chain to the application contract chain. Furthermore, after the first business object submits the second cross-chain transaction to the second consensus node, the second consensus node can also write the business processing results to the second address, and determine the business processing results in the second address as a destroyed state, so that the first cross-chain program in the subsequent cross-chain service terminal can transfer the business processing results from the second address to the application contract chain, so that the subsequent first consensus node can respond accordingly based on the business processing results.
  • S1305 Mapping the target transaction resource in the destroyed state as the second transfer transaction resource, verifying the second transfer transaction resource based on the second cross-chain transaction event, and when the verification succeeds, constructing a second cross-chain construction transaction corresponding to the second cross-chain transaction based on the second transfer transaction resource.
  • the verification of the second transfer transaction resource based on the second cross-chain transaction event can include comparing and verifying the transaction resources associated with the transaction detection information corresponding to each transaction event in the second cross-chain transaction event.
  • the management consensus node includes N management components associated with the second address, N is a positive integer; a management component is used to generate a transaction detection information in the second cross-chain transaction detection information when the second transfer transaction resource is detected in the second address; a transaction detection information in the second cross-chain transaction detection information corresponds to a transaction event in the second cross-chain transaction event.
  • the N management components associated with the second address can be the same as the N management components associated with the first address, or they can be different, and there is no limitation here.
  • the cross-chain service terminal determines the second event number of the transaction event associated with N management components from the received second cross-chain transaction event; the second event number is determined by the number of transaction detection information in the second cross-chain transaction detection information associated with the N management components; the second event number is less than or equal to N; further, when the second event number reaches the event number threshold in N, the transaction detection information corresponding to the number of information equal to the second event number is obtained; further, the transaction resource associated with each transaction detection information in the obtained second cross-chain transaction detection information is used as the second detection resource, and each second detection resource is compared to obtain a second transaction comparison result; further, if the second transaction comparison result indicates that the comparison is successful, a verification success indication information is generated to determine that each second detection resource is a second transfer transaction resource.
  • a second cross-chain constructed transaction corresponding to the second cross-chain transaction is constructed based on the second transfer transaction resource.
  • the cross-chain service terminal can use the second transfer transaction resource as a transaction parameter, and then construct a second cross-chain construction transaction corresponding to the second cross-chain transaction based on the transaction parameter.
  • the cross-chain service terminal can also be used to transfer the business processing results to the application contract chain, that is, the cross-chain service terminal can use the second transfer transaction resource (i.e., the target transaction mapping resource in the destroyed state) and the business processing result as transaction parameters, and then construct a second cross-chain construction transaction corresponding to the second cross-chain transaction based on the transaction parameters.
  • the cross-chain service terminal can use the first private key in the first cross-chain program to sign the second cross-chain constructed transaction and obtain the transaction signature information of the second cross-chain constructed transaction; further, when the second cross-chain constructed transaction is sent to the first consensus node associated with the application contract chain, the transaction signature information of the second cross-chain constructed transaction is synchronously sent to the first consensus node, so that the first consensus node verifies the transaction signature information based on the first public key corresponding to the first private key, and when the transaction verification is successful, the second cross-chain constructed transaction is obtained.
  • S1306 Determine the first address through the first cross-chain program, and send the second cross-chain constructed transaction to the first consensus node based on the first address, so that the first consensus node unlocks the first transfer transaction resource on the contract chain through the first address to obtain the target transaction resource.
  • the first cross-chain construction transaction instructs to transfer the target transaction mapping resources back to the contract chain (i.e., the application contract chain), that is, when the first consensus node receives the second cross-chain construction transaction sent by the first cross-chain program of the cross-chain service terminal, it unlocks the target transaction resources in the first address that are in a locked state, thereby obtaining the target transaction resources.
  • the contract chain i.e., the application contract chain
  • the first consensus node can transfer the target transaction resources in the first address back to the contract user address on the application contract chain.
  • This is equivalent to simply transferring the target transaction resources (such as business data) that need to be processed to the first business subchain for data processing.
  • the target transaction resources transferred to the first business subchain can be transferred back to the original contract user address, thereby reducing the occupation of the on-chain space of the application contract chain by the business processing process and improving the efficiency of the business processing process.
  • the first consensus node when the first consensus node receives the second cross-chain construction transaction, it can also cast the business processing result indicated by the second cross-chain construction transaction on the application contract chain through the first address, so that the first consensus node can obtain the processing result of the first business associated with the first business object, thereby achieving the purpose of business processing, and by transferring business data to the additional business sub-chain added on the basis of the three-chain system, it can improve the business processing efficiency to a certain extent and reduce the on-chain space on the application contract chain.
  • the embodiments of the present application can also be used to implement cross-chain data transmission between the bill chain and the business subchain included in the source blockchain.
  • the management consensus node creates a second business subchain based on the second business associated with the second business object.
  • the second business subchain can be used to process the second business (such as electronic bill issuance business, electronic bill circulation business, electronic bill red-check business, electronic bill archiving business and other electronic bill-related businesses).
  • the bill chain can include bill data, such as invoice data of some electronic invoices.
  • the bill data to be processed can be transferred to the second business subchain for processing, thereby reducing the waste of space on the bill chain and improving the efficiency of business processing.
  • the data processing process in the cross-chain data transmission processing system based on multiple blockchains is introduced in combination with the diagram.
  • the source blockchain is the bill chain
  • the business sub-processing sub-chain is the second business sub-chain as an example, and the process of cross-chain data transmission between the bill chain and the second business sub-chain is explained.
  • Figure 14 is a schematic diagram of a cross-chain data transmission processing process based on multiple blockchains provided by an embodiment of the present application.
  • the management component 702 in the consensus node of the management chain 701 can detect the bill chain 703 and the second business sub-chain 704, and specifically can detect the third address in the bill chain and the fourth address in the second business sub-chain 704.
  • the third address is the aforementioned bill chain transit address
  • the fourth address is also equivalent to the transit address on the second business sub-chain for transferring resources with the consensus node of the bill chain.
  • the consensus node of the management chain 701 may also be deployed with a management component management contract to manage the management component, such as the blockchain address that can be used to configure the management component for detection; the consensus node of the management chain 701 may also be deployed with a trusted cross-chain program management contract to interact with the cross-chain service terminal 705 for data, such as creating a second business object request for the second business object.
  • the management consensus node of the management chain 701 can send a cross-chain transaction event to the cross-chain service terminal 705, and then the cross-chain service terminal 705 can transfer the bill resource in the locked state in the third address to the second business subchain 704 through the second cross-chain program.
  • the management consensus node of the management chain 701 can send a cross-chain transaction event to the cross-chain service terminal 705, and then the cross-chain service terminal 705 can transfer the bill mapping resource in the destroyed state in the fourth address back to the bill chain 703 through the second cross-chain program.
  • the cross-chain service terminal can receive the third cross-chain transaction event sent by the management chain consensus node based on the third cross-chain transaction detection information through the second cross-chain program;
  • the third cross-chain transaction detection information is generated by the management chain consensus node when detecting that the target bill resource of the third cross-chain transaction associated with the second business exists in the third address on the bill chain, and the target bill resource is in a locked state;
  • the third cross-chain transaction is determined by the third consensus node associated with the bill chain based on the target bill resource submitted by the second business object, and the third cross-chain transaction is used to indicate that the target bill resource is transferred from the bill chain to the second business subchain;
  • the target bill resource in the locked state is used as the first transfer bill resource, and the first transfer bill resource is verified based on the third cross-chain transaction event, and when the verification is successful, the third cross-chain construction transaction corresponding to the third cross-chain transaction is constructed based on the first transfer bill resource;
  • the fourth address on the second business subchain is determined through the
  • the cross-chain service terminal can receive the fourth cross-chain transaction event sent by the management chain consensus node based on the fourth cross-chain transaction detection information through the second cross-chain program; the fourth cross-chain transaction detection information is generated by the management chain consensus node when detecting that there is a target bill mapping resource of the fourth cross-chain transaction associated with the second business in the fourth address on the second business subchain, and the target bill mapping resource is in a destroyed state; the fourth cross-chain transaction is determined by the fourth consensus node based on the target bill mapping resource submitted by the second business object, and the fourth cross-chain transaction is used to indicate that the target bill mapping resource is transferred from the second business subchain back to the bill chain; further, the target bill mapping resource in the destroyed state is used as the second transfer bill resource, and the second transfer bill resource is verified based on the fourth cross-chain transaction event, and when
  • the cross-chain data transmission process between the bill chain and the second business sub-chain can refer to the relevant description of the cross-chain data transmission process between the application contract chain and the first business sub-chain
  • the relevant description of the second business sub-chain can refer to the first business sub-chain
  • the relevant description of the fourth address on the second business sub-chain can refer to the second address on the first business sub-chain
  • the bill chain corresponds to the application contract chain
  • the relevant description of the third address on the bill chain can refer to the first address on the application contract chain.
  • the difference is that the first business and the second business can be different, and the content of the resource data to be transferred can also be different.
  • the resources that need to be transferred by the application contract chain are some general resources on the application contract chain (such as credit data, tax information, etc.), and the resources that need to be transferred by the bill chain are bill resources on the bill chain (such as the invoice code, invoice time, invoice amount and other data of the electronic invoice).
  • the multi-blockchain may include the source blockchain (i.e., the application contract chain and the bill chain) and the management chain under the three-chain system, and may also include a business sub-chain temporarily generated based on the business for business processing.
  • the business sub-chain is an external blockchain relative to the three-chain system.
  • the cross-chain service terminal can receive the first cross-chain transaction event sent by the management consensus node associated with the management chain through the trusted cross-chain program, and use the target transaction resource in the first address on the source blockchain such as the application contract chain as the transfer transaction resource.
  • Source thereby constructing a corresponding cross-chain construction transaction based on the transferred transaction resource, and then determining the second address on the business subchain such as the first business subchain through the trusted cross-chain program, and sending the cross-chain construction transaction to the consensus node associated with the business subchain based on the second address to realize cross-chain data transmission of the target transaction resource.
  • the cross-chain data transmission outside the chain can be realized for business data in general business scenarios through the trusted cross-chain program in the cross-chain service terminal, and the trusted cross-chain program is in a trusted execution environment and can verify cross-chain transactions, thereby ensuring the correctness of cross-chain data transmission and helping to ensure the security of cross-chain data transmission during the cross-chain data transmission transfer process outside the chain.
  • the embodiment of the present application proposes a cross-chain data transmission method based on multiple blockchains.
  • the source blockchain is a contract chain (i.e., an application contract chain)
  • the business sub-processing sub-chain is a first business sub-chain as an example, and the process of transferring resources from the source blockchain to the business sub-chain is described.
  • Figure 15 is a flow chart of a cross-chain data transmission method based on multiple blockchains provided by an embodiment of the present application.
  • the multiple blockchains include a source blockchain, a business sub-chain, and a target chain, and the source blockchain and the business sub-chain interact with data through a trusted cross-chain program;
  • the source blockchain includes a contract chain, and the trusted cross-chain program for data interaction with the contract chain is a first cross-chain program;
  • the business sub-chain includes a first business sub-chain, and the first business sub-chain is created by the management chain consensus node associated with the target chain according to the first business associated with the first business object;
  • the cross-chain data transmission method based on multiple blockchains can be executed by the second consensus node associated with the first business sub-chain, and the cross-chain data transmission method based on multiple blockchains can include the following steps.
  • S1502. Determine the resource mapping contract for resource mapping through the second address, call the resource mapping contract to cast the target transaction mapping resource corresponding to the first cross-chain construction transaction on the first business subchain, and write the target transaction mapping resource into the second address; the target transaction mapping resource has the same resource data content as the target transaction resource.
  • step S1501-step S1502 can refer to the description of the second consensus node in the above embodiment, that is, it will not be further described here.
  • the multi-blockchain may include the source blockchain (i.e., the application contract chain and the bill chain) and the management chain under the three-chain system, and may also include a business sub-chain temporarily generated based on the business for business processing.
  • the business sub-chain is an external blockchain relative to the three-chain system.
  • the scheme can realize cross-chain data transmission between the source blockchain (such as the application contract chain) and the chain outside (i.e., the business sub-chain) through a cross-chain service terminal deployed with a trusted cross-chain program.
  • the cross-chain service terminal can receive the first cross-chain transaction event sent by the management consensus node associated with the management chain through the trusted cross-chain program, and use the target transaction resource in the first address of the source blockchain such as the application contract chain in a locked state as the transfer transaction resource, thereby constructing a corresponding cross-chain construction transaction based on the transfer transaction resource, and then determine the second address on the business sub-chain such as the first business sub-chain through the trusted cross-chain program, and send the cross-chain construction transaction to the consensus node associated with the business sub-chain based on the second address to realize cross-chain data transmission of the target transaction resource.
  • the cross-chain data transmission outside the chain can be realized for business data in general business scenarios through the trusted cross-chain program in the cross-chain service terminal.
  • the trusted cross-chain program is in a trusted execution environment and can verify cross-chain transactions, thereby ensuring the correctness of the cross-chain data and helping to ensure the security of cross-chain data transmission during the cross-chain data transmission transfer process outside the chain.
  • cross-chain processing includes cross-chain data transmission, which is performed by the management chain consensus node.
  • Figure 16 is a flow chart of a cross-chain data transmission method based on multiple blockchains provided in an embodiment of the present application.
  • the multiple blockchains include a source blockchain, a business subchain, and a target chain.
  • the source blockchain and the business subchain interact with each other through a trusted cross-chain program;
  • the source blockchain includes a contract chain, and the trusted cross-chain program that interacts with the contract chain is a first cross-chain program;
  • the business subchain includes a first business subchain, and the first business subchain is associated with the target chain.
  • the management chain consensus node is based on The cross-chain data transmission method based on multiple blockchains can be executed by the management chain consensus node associated with the target chain, which is created by the first business associated with the first business object.
  • the source blockchain is the contract chain (i.e., the application contract chain)
  • the business sub-processing sub-chain is the first business sub-chain as an example to explain the process of transferring resources from the source blockchain to the business sub-chain.
  • the cross-chain data transmission method based on multiple blockchains may include the following steps.
  • S1601 First cross-chain transaction detection information generated when it is detected that a target transaction resource of a first cross-chain transaction exists in a first address and the target transaction resource is in a locked state, the first cross-chain transaction is associated with a first business, and the first address is on a contract chain;
  • S1602. Determine a first cross-chain transaction event to be sent to the first cross-chain program based on the first cross-chain transaction detection information, send the first cross-chain transaction event to the first cross-chain program, so that the first cross-chain program verifies the transfer transaction resource based on the first cross-chain transaction event, and constructs a first cross-chain construction transaction corresponding to the first cross-chain transaction of the business subchain based on the transfer transaction resource when the verification is successful, and the first cross-chain transaction corresponds to the second consensus node associated with the first business subchain;
  • the transfer transaction resource is a target transaction resource in a locked state;
  • the second consensus node is used to cast a target transaction mapping resource corresponding to the first cross-chain construction transaction on the first business subchain through the second address when the first cross-chain construction transaction sent by the first cross-chain program based on the second address on the first business subchain is obtained;
  • the target transaction mapping resource has the same resource data content as the target transaction resource.
  • the multi-blockchain may include the source blockchain (i.e., the application contract chain and the bill chain) and the management chain under the three-chain system, and may also include a business sub-chain temporarily generated based on the business for business processing.
  • the business sub-chain is an external blockchain relative to the three-chain system.
  • the scheme can realize cross-chain data transmission between the source blockchain (such as the application contract chain) and the chain outside (i.e., the business sub-chain) through a cross-chain service terminal deployed with a trusted cross-chain program.
  • the cross-chain service terminal can receive the first cross-chain transaction event sent by the management consensus node associated with the management chain through the trusted cross-chain program, and use the target transaction resource in the first address of the source blockchain such as the application contract chain in a locked state as the transfer transaction resource, thereby constructing a corresponding cross-chain construction transaction based on the transfer transaction resource, and then determine the second address on the business sub-chain such as the first business sub-chain through the trusted cross-chain program, and send the cross-chain construction transaction to the consensus node associated with the business sub-chain based on the second address to realize cross-chain data transmission of the target transaction resource. Therefore, the business data in the general business scenario can be cross-chained outside the chain through the trusted cross-chain program in the cross-chain service terminal.
  • the trusted cross-chain program is in a trusted execution environment and can verify cross-chain transactions, thereby ensuring the correctness of cross-chain data transmission and helping to ensure the security of cross-chain data transmission during the cross-chain data transmission transfer process outside the chain.
  • FIG 17 is a schematic diagram of a scenario for forming a business subnetwork provided by an embodiment of the present application.
  • the user 30A shown in Figure 17 can be the above-mentioned business object, that is, at this time, the user 30A is an entity object with a subnet creation requirement.
  • the business terminal 30B of the user 30A can be a business node corresponding to the business object (for example, a business node in the business network 400a shown in Figure 1 above), or it can be a terminal device associated with the business node, which is not limited here.
  • the subnet creation server 30C can be the above-mentioned subnet creation server, and the subnet creation server 30C is associated with the multi-blockchain shown in Figure 3.
  • the multi-blockchain involved in the embodiment of the present application specifically includes a management chain 31e corresponding to the management chain network 31, a bill chain 32e corresponding to the bill chain network 32, and a contract chain 33e corresponding to the contract chain network 33, wherein the management chain network 31, the bill chain network 32 and the contract chain network 33 are independent of each other.
  • multiple consensus nodes can be deployed in the management chain network 31.
  • the multiple consensus nodes here can specifically include consensus node 31a, consensus node 31b, consensus node 31c and consensus node 31d, and these multiple consensus nodes are used to jointly maintain the management chain 31e.
  • multiple consensus nodes can be deployed in the bill chain network 32.
  • the multiple consensus nodes here can specifically include consensus node 32a, consensus node 32b, consensus node 32c and consensus node 32d, and these multiple consensus nodes are used to jointly maintain the bill chain 32e.
  • multiple consensus nodes can be deployed in the contract chain network 33.
  • the multiple consensus nodes here can specifically include consensus node 33a, consensus node 33b, consensus node 33c and consensus node 33d, and these multiple consensus nodes are used to jointly maintain the contract chain 33e.
  • the temporary service A can be When a temporary business A1 associated with a bill business or a temporary business A2 associated with a file business is requested, the authority to create a business subnetwork can be applied to the management chain 31e based on the temporary business A to execute the authority of the temporary business A. Only after obtaining authorization can the corresponding business subnetwork be applied for.
  • the consensus node in the management chain network 31 can configure the corresponding business authorization credential (for example, authorization code) for the temporary business A, and then the consensus node in the management chain network 31 can write the business authorization credential as a registration business authorization credential (for example, registration business authorization credential 301c) into the management chain 31e.
  • the business authorization credential can also be returned to the business terminal 30B of the user 30A, and the business terminal 30B can use the received business authorization credential as a subnet creation request credential (for example, subnet creation request credential 301b).
  • the service terminal 30B can generate a subnet creation request (e.g., subnet creation request 301a) based on the subnet creation request credential 301b, and can send the subnet creation request 301a to the subnet creation server 30C. Subsequently, the subnet creation server 30C can perform authorization verification of the above-mentioned service subnet to the management chain 31e.
  • a subnet creation request e.g., subnet creation request 301a
  • the subnet creation server 30C can perform authorization verification of the above-mentioned service subnet to the management chain 31e.
  • the subnet creation server 30C can obtain the subnet creation request credential 301b carried in the subnet creation request 301a, and can obtain the registration service authorization credential 301c associated with the above-mentioned temporary service A from the management chain 31e, and then can verify the subnet creation request credential 301b through the registration service authorization credential 301c to obtain the corresponding credential verification result (e.g., credential verification result 301d).
  • the subnet creation server 30C can obtain the subnet creation request credential 301b carried in the subnet creation request 301a, and can obtain the registration service authorization credential 301c associated with the above-mentioned temporary service A from the management chain 31e, and then can verify the subnet creation request credential 301b through the registration service authorization credential 301c to obtain the corresponding credential verification result (e.g., credential verification result 301d).
  • the subnet creation server 30C can obtain a certain number of consensus nodes from the above-mentioned bill chain network 32 as the first verification node, and can obtain a certain number of consensus nodes from the above-mentioned contract chain network 33 as the second verification node.
  • the embodiment of the present application does not limit the number of first verification nodes and second verification nodes obtained.
  • user 30A can specify the number of verification nodes required to form a business subnet when applying for subnet creation authority from the management chain 31e.
  • the total number of verification nodes required can be specified as M (M is a positive integer greater than 1), or the number of first verification nodes required can be specified as M1 (M1 is a positive integer) and the number of second verification nodes required can be specified as M2 (M2 is a positive integer).
  • M M1+M2, which is not limited in the embodiment of the present application.
  • the subnet creation server 30C can randomly obtain two consensus nodes (e.g., consensus node 32a and consensus node 32b) from the bill chain network 32 as the first verification node, and can randomly obtain two consensus nodes (e.g., consensus node 33a and consensus node 33b) from the contract chain network 33 as the second verification node, and then the business subnet (e.g., business subnet 34) corresponding to the above-mentioned temporary business A can be formed through the obtained first verification node and second verification node.
  • the business subnet 34 is independent of the above-mentioned management chain network 31, bill chain network 32 and contract chain network 33.
  • the verification nodes in the business subnet 34 (including consensus node 32a, consensus node 32b, consensus node 33a and consensus node 33b) can be used to jointly maintain the business subchain 34e.
  • each verification node in the business subnetwork 34 will still process its original business in parallel while executing temporary business A.
  • the consensus node 32a can execute the temporary business A and the business corresponding to the bill chain 32e (for example, the bill business) in parallel; for another example, the consensus node 33a can execute the temporary business A and the business corresponding to the contract chain 33e (for example, the bill derivative business) in parallel.
  • the business sub-chain 34e stores the genesis block information associated with the business sub-network 34 (i.e., the information included in the genesis block of the business sub-chain 34e, such as the relevant registration information submitted by the user 30A when applying for the sub-network creation permission to the management chain 31e).
  • the verification node in the business sub-network 34 can read the resources associated with the temporary business A (e.g., the electronic bill associated with the temporary business A or the bill information in the electronic bill) from the bill chain 32e and the contract chain 33e across the chain, and can execute the temporary business A based on the obtained resources to obtain the temporary business execution result of the temporary business A, and then write the temporary business execution result into the above-mentioned business sub-chain 34e.
  • the resources associated with the temporary business A e.g., the electronic bill associated with the temporary business A or the bill information in the electronic bill
  • a new service sub-network can be created through a similar process to handle temporary service B, which will not be described in detail here.
  • one service sub-network can be created to handle one temporary service, or multiple service sub-networks can be created to handle one temporary service. This embodiment does not limit the number of service subnetworks.
  • the subnet creation server 30C can build a business subnet 34 in real time according to business needs on the basis of the three-chain architecture, so as to independently process temporary business A, thereby reducing the waste of main chain space and providing data independence and privacy for user 30A.
  • the subnet creation server 30C can quickly build a business subnet by reusing the existing consensus nodes in the bill chain network 32 and the contract chain network 33, without requiring user 30A to provide the verification node of the business subnet by itself, thereby saving additional verification node resource overhead and improving the creation efficiency and security of the business subnet.
  • an embodiment of the present application provides a multi-blockchain data processing method, which can be executed by a management chain consensus node.
  • the management chain consensus node receives a business authorization request, which is sent by the business object through the business terminal; based on the business authorization request, the management chain consensus node calls the subnet management contract deployed on the management chain to configure the business object with a business authorization credential associated with the temporary business; the management chain consensus node writes the business authorization credential into the management chain as a registered business authorization credential, and returns the business authorization credential to the business terminal; the business authorization credential is used to generate a subnet creation request sent to a subnet creation server associated with the multiple blockchains; the subnet creation request is used to instruct the subnet creation server to verify the subnet creation request credential when obtaining the registered business authorization credential on the management chain, and when the verification is successful, the consensus node obtained from the bill chain network is used as the first verification node, and the consensus node obtained from the contract chain network is used as the second verification node, the first verification node and the second verification node are used to jointly establish a business subnet corresponding to the temporary business; the business subnet is independent of
  • the service authorization request includes subnet registration configuration information, object signature information, and public key information corresponding to the private key information.
  • the subnet registration configuration information is generated by the service terminal based on the temporary service, and the object signature information is obtained by signing the subnet registration configuration information using the private key information of the service object.
  • the management chain consensus node determines that the object signature information is successfully verified through the public key information in the business authorization request, it calls the subnet management contract deployed on the management chain to configure the business object with a business authorization credential associated with the temporary business.
  • the management chain consensus node when the business subnetwork is formed, receives the subnet startup transaction; the management chain consensus node calls the subnet management contract on the management chain based on the subnet startup transaction, and obtains the genesis block information associated with the business subnetwork from the management chain; the genesis block information includes the subnet registration configuration information submitted by the business object to the management chain consensus node through the business terminal; the management chain consensus node sends the genesis block information to the verification node in the business subnetwork, so that the verification node writes the genesis block information to the business subchain corresponding to the business subnetwork.
  • the multi-blockchain system includes an off-chain processing device, which determines at least two blockchains to be cross-chain processed in the multi-blockchain; the off-chain processing device cooperates with the management chain consensus node to perform cross-chain processing on the at least two blockchains.
  • Cross-chain processing includes data processing
  • the off-chain processing device includes a subnet creation server associated with the multi-blockchain.
  • the method can be executed by a subnet creation server, for example, the subnet creation server can be the subnet creation server 30C shown in Figure 17 above. The method can specifically include the following steps:
  • Step S1801 when a subnet creation request is obtained, a subnet creation request credential carried in the subnet creation request is obtained; the subnet creation request is sent by a business object through a business terminal, and the subnet creation request credential is determined by a management chain consensus node in the management chain network receiving a temporary business sent by the business object through the business terminal;
  • the multiple blockchains in the embodiments of the present application include a management chain, a bill chain and a contract chain.
  • the management chain network corresponding to the management chain is independent of the bill chain network corresponding to the bill chain, and is independent of the contract chain network corresponding to the contract chain.
  • it can correspond to three blockchains with different functions.
  • the above-mentioned management chain can be a management chain (also referred to as the first management chain) applied to the blockchain electronic bill system, and the corresponding management chain network can be the management chain network (also referred to as the first management chain network) in the blockchain electronic bill system;
  • the above-mentioned bill chain can be a bill chain applied to the blockchain electronic bill system, and the corresponding bill chain network can be the bill chain network in the blockchain electronic bill system;
  • the above-mentioned contract chain can be an application chain applied to the blockchain electronic bill system
  • the contract chain (also referred to as the first application contract chain), the corresponding contract chain network may be the application contract chain network (also referred to as the first application contract chain network) in the blockchain electronic bill system.
  • the management chain may be the management chain (also referred to as the second management chain) applied to the blockchain electronic file system, and the corresponding management chain network may be the management chain network (also referred to as the second management chain network) in the blockchain electronic file system;
  • the bill chain may be the file chain applied to the blockchain electronic file system, and the corresponding bill chain network may be the file chain network in the blockchain electronic file system;
  • the contract chain may be the application contract chain (also referred to as the second application contract chain) applied to the blockchain electronic file system, and the corresponding contract chain network may be the application contract chain network (also referred to as the second application contract chain network) in the blockchain electronic file system.
  • the embodiments of the present application do not limit specific business scenarios.
  • the business terminal can send a business authorization request to the management chain consensus node in the management chain network (which can be any consensus node in the management chain network, such as the consensus node 11a in the consensus network 200a shown in Figure 1 above) based on the temporary business requested by the business object, so that the management chain consensus node, based on the business authorization request, calls the sub-network management contract deployed on the management chain to configure the business object with the business authorization certificate associated with the temporary business.
  • the management chain consensus node in the management chain network which can be any consensus node in the management chain network, such as the consensus node 11a in the consensus network 200a shown in Figure 1 above
  • the management chain consensus node can write the business authorization certificate into the management chain as a registered business authorization certificate, and can return the business authorization certificate to the business terminal.
  • the business authorization certificate here can specifically be an exclusive authorization code configured by the management chain consensus node for the business object.
  • the authorization code can be used to indicate that the business object has obtained the sub-network creation authority granted by the management chain consensus node.
  • the authorization code can be a symbol sequence composed of a string of numbers and/or letters. The specific form of the authorization code is not limited here.
  • the service authorization request may carry subnet registration configuration information determined based on the temporary service, and the subnet registration configuration information may include basic information and permission information related to the service subnet applied for creation.
  • the business terminal can use the received business authorization certificate as the subnet creation request certificate, that is, the subnet creation request certificate is determined by the temporary business sent by the business object through the business terminal received by the above-mentioned management chain consensus node.
  • the business terminal can then generate a subnet creation request for sending to the subnet creation server based on the subnet creation request certificate. Accordingly, when the subnet creation server obtains the subnet creation request sent by the business object through the business terminal, it can obtain the subnet creation request certificate carried by it from the subnet creation request, and then perform corresponding authorization verification on the management chain through the subnet creation request certificate. After the verification is successful, the subnet creation server will form a business subnet according to the subnet business needs.
  • the subnet creation server may be operated by a tax administration department.
  • the subnet creation server may be operated by a document administration department (eg, an authority or organization that issues electronic certificates).
  • the above subnet management contract is determined by the internal participants corresponding to the management chain (such as the tax management department or the document management department) through the management contract template deployed on the management chain.
  • the subnet creation authority or business authority
  • subnet operation status
  • subnet registration data
  • cross-chain authority of entity objects such as individual users/enterprises/institutions
  • the contract modules associated with the business subchains in the multi-blockchain system and the business subchain block rules can be centrally managed.
  • Step S1802 verifying the subnet creation request credential by managing the registration service authorization credential associated with the temporary service on the chain, and obtaining a credential verification result;
  • the subnet creation server will perform authorization verification of the business subnetwork to the management chain.
  • the subnet creation server can send a credential verification transaction to the management chain consensus node based on the above-mentioned subnet creation request. For example, based on the subnet creation request credential carried in the subnet creation request, a credential verification transaction for requesting to obtain the registration business authorization credential corresponding to the subnet creation request credential from the management chain is generated, and the credential verification transaction is sent to the management chain consensus node.
  • the management chain consensus node when it receives the credential verification transaction, it can call the subnet management contract on the management chain and read the registration business authorization credential associated with the temporary business from the management chain.
  • the credential verification transaction can include the contract call address and contract call name corresponding to the subnet management contract, and write the credential verification transaction into the contract call address and contract call name indicated by the contract call address and contract call name.
  • the subnet management contract on the management chain can obtain the registration business authorization certificate stored on the management chain by calling the certificate reading method in the subnet management contract.
  • the registration service authorization credential may include the subnet registration authorization code (for example, authorization code D1) configured by the management chain consensus node for the business object.
  • the above-mentioned subnet creation request credential may include the subnet construction request code (for example, authorization code D2) configured by the management chain consensus node for the business object.
  • the process of verifying the subnet creation request credential through the registration service authorization credential may be: comparing the subnet registration authorization code with the subnet construction request code to obtain a comparison result.
  • the comparison result indicates that the subnet registration authorization code is consistent with the subnet construction request code (for example, the authorization code D1 is the same as the authorization code D2), it can be determined that the subnet creation request credential verification is successful, and then the subnet creation request credential when the verification is successful can be used as the credential verification result. Conversely, when the comparison result indicates that the subnet registration authorization code is inconsistent with the subnet construction request code (for example, the authorization code D1 is different from the authorization code D2), it can be determined that the subnet creation request credential verification has failed.
  • the subnet creation request credential can also be verified on the management chain.
  • the subnet creation server can send a credential verification transaction to the management chain consensus node based on the subnet creation request.
  • the credential verification transaction can include the subnet construction request code (for example, authorization code D2) in the subnet creation request credential.
  • the management chain consensus node When the management chain consensus node receives the credential verification transaction, it can call the subnet management contract on the management chain (such as the credential verification method in the subnet management contract), read the registration service authorization credential associated with the temporary service from the management chain, and then compare the above subnet construction request code with the subnet registration authorization code (for example, authorization code D1) in the registration service authorization credential to obtain a comparison result, and the comparison result can be returned to the subnet creation server.
  • the subnet management contract on the management chain such as the credential verification method in the subnet management contract
  • the subnet creation server can determine that the subnet creation request credential verification is successful, and then the subnet creation request credential when the verification is successful can be used as the credential verification result.
  • Step S1803 when the voucher verification result indicates that the verification is successful, the consensus node obtained from the bill chain network is used as the first verification node, and the consensus node obtained from the contract chain network is used as the second verification node, and a business sub-network corresponding to the temporary business is established through the first verification node and the second verification node; the business sub-network is independent of the management chain network, the bill chain network and the contract chain network.
  • the subnet creation server can determine that the current business object has the subnet creation permission.
  • the business subnet corresponding to the temporary business can be established by reusing the consensus nodes in the bill chain network and the consensus nodes in the contract chain network.
  • the above-mentioned registration service authorization certificate may include the subnet registration configuration information submitted by the business object to the management chain consensus node through the business terminal;
  • the subnet registration configuration information includes the information specified by the business object for the business subnet, which may specifically include the network identifier of the business subnet corresponding to the temporary business (such as network name, network ID, etc.), the number of nodes of the verification nodes included in the business subnet, and the cross-chain permissions applied for by the business object.
  • the number of nodes of the verification nodes included in the business subnet is M, and M is a positive integer greater than 1.
  • the cross-chain permissions here may include a first cross-chain transfer permission for cross-chain data transfer between the bill chain and the business subchain corresponding to the business subnet, and a second cross-chain transfer permission for cross-chain data transfer between the contract chain and the business subchain.
  • the subnet registration configuration information may also include other information related to the business subnet, such as the subchain block rules (for example, transaction packaging time, transaction packaging quantity, subchain block time).
  • the first cross-chain transfer authority can transfer the first resource associated with the temporary business from the bill chain to the business sub-chain, and the temporary business execution result obtained by executing the temporary business based on the first resource on the business sub-chain can also be returned to the bill chain for storage; similarly, the second cross-chain transfer authority can transfer the second resource associated with the temporary business from the contract chain to the business sub-chain, and the temporary business execution result obtained by executing the temporary business based on the second resource on the business sub-chain can also be returned to the contract chain for storage.
  • the cross-chain authority applied for by the above-mentioned business object can also include the first cross-chain read authority and the second cross-chain read authority.
  • the first cross-chain read authority can transfer the first resource associated with the temporary business from the bill chain to the business sub-chain, but the subsequent temporary business execution result cannot be written into the bill chain; similarly, the second cross-chain read authority can transfer the second resource associated with the temporary business from the contract chain to the business sub-chain, but the subsequent temporary business execution result cannot be written into the contract chain, so that the data on the business sub-chain can be prevented from interfering with the bill chain and the contract chain.
  • the subnet creation server uses the M1 consensus nodes (i.e., the first consensus nodes) associated with the first cross-chain transfer authority obtained from the bill chain network as the first verification node, and uses the M2 consensus nodes (i.e., the second consensus nodes) associated with the second cross-chain transfer authority obtained from the contract chain network as the second verification node, and then can form a business subnet with a network identifier through the obtained M1 first verification nodes and M2 second verification nodes.
  • the subnet creation server can obtain the first verification node and the second verification node by random selection.
  • the business object may also directly specify the number of first verification nodes (e.g., M1) and the number of second verification nodes (e.g., M2) included in the business subnet in the subnet registration configuration information, which is not limited in the embodiments of the present application.
  • FIG. 17 For ease of understanding, please refer to Figure 17 again.
  • the subnet creation server 30C randomly selects two consensus nodes (for example, consensus node 32a and consensus node 32b) in the bill chain network 32 (for example, the bill chain network) as the first verification nodes based
  • the above-mentioned subnet registration configuration information can also be information independent of the registration service authorization certificate. Then, when the management chain consensus node receives the certificate verification transaction, it can return the registration service authorization certificate and subnet registration configuration information read on the management chain to the subnet creation server.
  • the business subnet can be started so that the verification nodes in the business subnet start the subnet consensus and execute the above-mentioned temporary business.
  • the subnet creation server can return a subnet creation success response message to the business object, and the subnet creation success response message is used to indicate that the business subnet is successfully established.
  • the business terminal corresponding to the business object receives the subnet creation success response message, it can generate a subnet startup instruction for indicating the startup of the above-mentioned business subnet based on the subnet creation success response message, and send the subnet startup instruction to the subnet creation server.
  • the subnet creation server When the subnet creation server receives the subnet startup instruction, it can send a subnet startup transaction to the management chain consensus node based on the subnet startup instruction, so that the management chain consensus node calls the subnet management contract on the management chain based on the subnet startup transaction (specifically, it can be the creation information reading method in the subnet management contract) to obtain the creation block information associated with the business subnet from the management chain.
  • the genesis block information here refers to the information included in the genesis block (i.e., the first block) of the business subchain, wherein the genesis block information may specifically include the subnet registration configuration information submitted by the business object to the management chain consensus node through the business terminal, and optionally, the genesis block information may also include a registration business authorization certificate, through which the business object can interact with the business subnetwork for data.
  • the subnet creation server may send the genesis block information returned by the management chain consensus node to the verification node in the business subnetwork, so that the verification node writes the genesis block information into the business subchain corresponding to the business subnetwork.
  • the business subchain 33e corresponding to the business subnetwork 34 will store the corresponding genesis block information (for example, genesis block information 301f), and the genesis block information 301f may include the above-mentioned subnetwork registration configuration information 301e.
  • the verification node in the business subnetwork 34 can perform the above-mentioned bill statistics business.
  • the first verification node in the business subnetwork 34 (for example, consensus node 32a) can transfer the first cross-chain permission from the bill chain 32e to the first cross-chain permission configured.
  • the electronic invoice issued by the invoicing company A is read, and the number of invoices issued by the invoicing company A within a certain time period can be counted.
  • the final statistical result can then be returned to the invoice chain 32e.
  • the consensus node in the invoice chain network 32 detects that the statistical result is greater than the invoice quantity threshold, the subsequent invoicing behavior of the invoicing company A can be restricted.
  • the business management object associated with the subnet creation server can trigger the subnet creation server to send a business termination transaction to the verification node in the business subnet.
  • the subnet creation server can send a business termination transaction to the verification node in the business subnet based on the sub-gateway stop instruction, so that the verification node stops executing the above-mentioned temporary business when the business termination transaction is successfully verified, and sends the business subchain to the subnet creation server.
  • the above-mentioned sub-gateway stop instruction can include a business termination instruction for indicating that the temporary business has ended and a business change instruction for indicating that the temporary business has changed (for example, from the number of invoices issued by the statistical invoicing enterprise A to the number of invoices issued by the statistical enterprise B). Subsequently, the subnet creation server can back up the received business subchain.
  • the business management object associated with the subnet creation server 30C in FIG. 3 (for example, user 30D) will send a sub-gateway stop instruction (sub-gateway stop instruction 301g) to the subnet creation server 30C, and then the subnet creation server 30C can sign the sub-gateway stop instruction 301g through the configured service private key information, thereby obtaining the service signature information 301h, and generate a business termination transaction (for example, business termination transaction 301i) based on the sub-gateway stop instruction 301g and the service signature information 301h.
  • a sub-gateway stop instruction sub-gateway stop instruction 301g
  • the subnet creation server 30C can sign the sub-gateway stop instruction 301g through the configured service private key information, thereby obtaining the service signature information 301h, and generate a business termination transaction (for example, business termination transaction 301i) based on the sub-gateway stop instruction 301g and the service signature information 301h.
  • the business termination transaction 301i can be sent It is sent to a verification node in the business subnetwork 34 (for example, consensus node 32a).
  • the consensus node 32a will verify the service signature information 301h in the business termination transaction 301i through the service public key information corresponding to the service private key information.
  • the business termination transaction 301i can also be broadcast to other verification nodes in the business subnetwork 34 (for example, consensus node 32a, consensus node 32b, consensus node 33a, consensus node 33b) for verification. That is, all verification nodes participate in the consensus on the business termination transaction 301i, and finally the transaction verification result of the business termination transaction 301i can be obtained based on the verification results of all verification nodes.
  • the above-mentioned service private key information and service public key information can be obtained by the subnet creation server 30C after identity registration through the object identity management contract on the management chain 31e, and the subnet creation server 30C can apply for the corresponding public key certificate (which can be called the first public key certificate) for the service public key information, and can submit the first public key certificate to the management chain 31e.
  • the verification node in the business subnet 34 can read the first public key certificate from the management chain 31e, and can obtain the service public key information in the first public key certificate to verify the above-mentioned service signature information 301h.
  • the business termination transaction 301i when the number of successful signature verification results obtained is greater than the first quantity threshold, it can be determined that the business termination transaction 301i is successfully verified.
  • the value of the first quantity threshold is not limited here. For example, it can be taken as 2/3 of the number of nodes of all verification nodes.
  • all verification nodes in the business subnetwork 34 stop executing the above-mentioned bill statistics business, and can send the current latest business subchain 34e to the subnet creation server 30C for backup, wherein the business subchain 34e can store the number of invoices issued by the above-mentioned invoicing company A within multiple specified time periods, so that when it is necessary to obtain bill statistics data related to the invoicing company A later, it can be obtained from the subnet creation server 30C.
  • the public key certificate in the embodiment of the present application may refer to a public key certificate system (PKI, Public Key Infrastructure).
  • PKI public key certificate system
  • a certificate is an identity certificate of a public key owner and is issued by an authority (CA, Certificate Authority).
  • CA Certificate Authority
  • Asymmetric encryption and digital signatures for information can be implemented based on the public key certificate system.
  • the public key certificate system here may include public and private key cryptography, x509 certificates, CA certificate issuing centers, and the like.
  • the embodiment of the present application can build a business sub-network in real time based on the multi-blockchain architecture according to business needs, so as to independently process some temporary businesses that will generate a large amount of data or have a specified purpose.
  • the corresponding temporary business execution results are determined by the business sub-network corresponding to the business.
  • the sub-chain is used for storage and destruction, thus reducing the waste of main chain space and providing business objects with higher independent performance, independent data isolation and higher privacy of business sub-chains.
  • the sub-network creation server can quickly build the business sub-network by reusing the existing consensus nodes in the bill chain network and the contract chain network, without the need for the business object to provide the verification node of the business sub-network by itself, thereby providing the business object with an efficient sub-chain creation method, saving additional verification node resource overhead, and improving the utilization rate of consensus nodes in the multi-blockchain system, while improving the creation efficiency and security of the business sub-network.
  • the multi-blockchain system includes an off-chain processing device, which determines at least two blockchains to be cross-chain processed in the multiple blockchains; the off-chain processing device collaborates with the management chain consensus node to perform cross-chain processing on at least two blockchains.
  • Cross-chain processing includes data processing, and the off-chain processing device includes a business terminal.
  • the business terminal and the management chain consensus node cooperate to reuse the consensus node in at least one other blockchain to jointly establish a business sub-network corresponding to the temporary business.
  • the at least one other blockchain includes at least one of the bill chain and the contract chain.
  • the method can be executed by a business terminal associated with multiple blockchains.
  • the business terminal can be the business terminal 30B shown in Figure 17 above.
  • the method can specifically include the following steps:
  • Step S1901 receiving a temporary service requested by a service object, and sending a service authorization request to a management chain consensus node in the management chain network based on the temporary service; the service authorization request is used to instruct the management chain consensus node to write the service authorization credential into the management chain as a registered service authorization credential when the service authorization credential associated with the temporary service is configured;
  • the business terminal may receive the temporary business requested by the business object, and then generate subnet registration configuration information based on the temporary business.
  • the subnet registration configuration information may include information specified by the business object for the business subnet when applying to create the business subnet corresponding to the temporary business, including but not limited to the network identifier of the business subnet (e.g., network name, network ID, etc.), the number of verification nodes included in the business subnet, the cross-chain authority applied by the business object, the subchain block rules (e.g., transaction packaging time, transaction packaging quantity, subchain block time), etc.
  • the network identifier of the business subnet e.g., network name, network ID, etc.
  • the number of verification nodes included in the business subnet e.g., the number of verification nodes included in the business subnet
  • the cross-chain authority applied by the business object e.g., transaction packaging time, transaction packaging quantity, subchain block time
  • the business object may specify the network identifier of the business subnet corresponding to the tax audit business as X2 in the corresponding subnet registration configuration information, and may specify the number of verification nodes required for the business subnet X2 as 10 (e.g., specifically including 5 first verification nodes and 5 second verification nodes), and apply to the management chain for the first cross-chain transfer authority (e.g., for obtaining the bill information associated with user B from the bill chain) and the second cross-chain transfer authority (e.g., for obtaining the tax refund information associated with user B from the contract chain).
  • the first cross-chain transfer authority e.g., for obtaining the bill information associated with user B from the bill chain
  • the second cross-chain transfer authority e.g., for obtaining the tax refund information associated with user B from the contract chain.
  • the verification node in the business subnetwork X2 can review the tax refund information associated with user B based on the acquired bill information associated with user B, that is, verify whether the tax refund of user B is correct.
  • the business terminal can sign the above-generated subnet registration configuration information through the private key information of the business object to obtain the object signature information, and then determine the business authorization request based on the subnet registration configuration information, the object signature information and the public key information corresponding to the above private key information.
  • the above subnet registration configuration information, the object signature information and the public key information can be encapsulated into a business authorization request with the encapsulation format according to the specified encapsulation format.
  • the business terminal can send the business authorization request to the management chain consensus node in the management chain network, so that when the management chain consensus node determines that the object signature information verification is successful through the public key information in the business authorization request, it can call the subnet management contract on the management chain based on the subnet registration configuration information obtained from the business authorization request, and configure the business authorization certificate associated with the temporary business for the business object.
  • each management chain consensus node in the management chain network can verify the above object signature information through the public key information in the business authorization request, and can determine the signature verification result of the object signature information based on the verification results of all management chain consensus nodes.
  • the number of successful signature verification results obtained is greater than a second quantity threshold, it can be determined that the above-mentioned object signature information is successfully verified.
  • the value of the second quantity threshold here.
  • the value can be 2/3 of the number of nodes of all management chain consensus nodes.
  • the management chain consensus node can write the subnet registration configuration information obtained from the business authorization request into the subnet management contract on the management chain, and can call the business authorization method in the subnet management contract to configure the business object with a business authorization credential associated with the temporary business, and then write the business authorization credential into the management chain as a registered business authorization credential.
  • the private key information and public key information of the business object can be obtained by the business object after pre-registering its identity through the object identity management contract on the management chain.
  • the management chain consensus node can write the public key information into the management chain. In this way, the above-mentioned business authorization request does not need to carry the public key information. Instead, when the management chain consensus node obtains the business authorization request, it calls the object identity management contract to read the public key information from the management chain, and can verify the object signature information in the business authorization request based on the read public key information.
  • Step S1902 using the business authorization credential as the subnet creation request credential, and generating a subnet creation request based on the subnet creation request credential.
  • the business authorization credential is returned by the management chain consensus node, and the subnet creation request is used to send to the subnet creation server associated with multiple blockchains.
  • the business authorization certificate can be used as the subnet creation request certificate, and then the subnet creation request for sending to the above-mentioned subnet creation server can be generated based on the subnet creation request certificate.
  • the business terminal can also sign the subnet creation request certificate through the private key information configured by the business object to obtain the certificate signature information, and then the subnet creation request can be determined by the subnet creation request certificate, the certificate signature information and the public key information corresponding to the private key information.
  • the subsequent subnet creation server receives the subnet creation request, it can first verify the certificate signature information through the public key information in the subnet creation request.
  • the subnet creation request certificate carried by it can be obtained from the subnet creation request.
  • the subsequent subnet creation server can verify the subnet creation request certificate when obtaining the registration business authorization certificate on the management chain, and when the verification is successful, the consensus node obtained from the bill chain network can be used as the first verification node, and the consensus node obtained from the contract chain network can be used as the second verification node.
  • the first verification node and the second verification node here can be used to jointly establish a business subnet corresponding to the temporary business.
  • the business subnetwork is independent of the management chain network, the bill chain network, and the contract chain network.
  • the specific process of the subnetwork creation server verifying the subnetwork creation request credential and obtaining the first verification node and the second verification node can be referred to the above embodiment, which will not be repeated here.
  • the business terminal can receive the subnet creation success response information returned by the subnet creation server, and send a subnet start instruction to the subnet creation server based on the subnet creation success response information, so that the subnet creation server sends a subnet start transaction to the management chain consensus node based on the subnet start instruction.
  • the subnet start transaction is used to instruct the management chain consensus node to call the subnet management contract on the management chain, and obtain the genesis block information associated with the business subnetwork from the management chain.
  • the genesis block information here may include the subnet registration configuration information submitted by the business object to the management chain consensus node through the business terminal; the genesis block information is used to write the business subchain corresponding to the business subnetwork.
  • the specific process can be referred to step S1803 in the embodiment corresponding to Figure 18 above, which will not be repeated here.
  • the business terminal can send a data extraction request for extracting the latest data on the business subchain to the verification node in the business subnetwork, wherein, upon receiving the backup success message returned by the subnet creation server (optional condition), the verification node can first perform a request verification on the data extraction request, and when the verification is successful, the block data in the block with the maximum block height on the business subchain can be used as the target extraction data associated with the business object based on the data extraction request, and the target extraction data is returned to the business terminal.
  • the target extraction data here refers to the block data of the latest block on the business subchain (for example, in the real-time bill statistics business, it can be the final bill statistics result). Accordingly, the business terminal can receive the target extraction data returned by the above verification node based on the data extraction request.
  • the backup success message is determined by the subnet creation server when the business subchain is successfully backed up.
  • each verification node can delete its own stored copy of the business subchain and shut down each node offline, thereby avoiding long-term storage of large amounts of data generated by executing temporary business and saving on-chain space for related consensus nodes.
  • each verification node in the business sub-network can read the resources associated with the temporary business from the bill chain and the contract chain to execute the temporary business.
  • the cross-chain interaction between the business sub-chain and the bill chain and the cross-chain interaction between the business sub-chain and the contract chain will be explained below.
  • the bill chain network and the business sub-network are isolated by a first cross-chain relay associated with multiple blockchains.
  • the first cross-chain relay can be an independent relay server, or a relay server cluster or distributed system composed of multiple relay servers, or a relay server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, networks, etc.
  • Cloud servers that provide basic cloud computing services such as services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.
  • the business terminal can send a first cross-chain resource transfer request to the first consensus node in the bill chain network based on the temporary business, wherein the first cross-chain resource transfer request is used to instruct the first consensus node to transfer the first resource associated with the temporary business from the bill chain to the business sub-chain corresponding to the business sub-network.
  • the first resource can be an electronic bill associated with the temporary business or partially authorized visible bill information in the electronic bill, or an electronic file associated with the temporary business or partially authorized visible file information in the electronic file (for example, certificate information in an electronic certificate), which is not limited here.
  • the business terminal can obtain the first resource transfer success response information obtained from the business sub-chain for the first cross-chain resource transfer request; the first resource transfer success response information is used to indicate that the first resource is successfully transferred from the bill chain to the business sub-chain, and there is a first mapping resource corresponding to the first resource on the business sub-chain; the first mapping resource is a resource with the same resource content as the first resource that is minted by the first resource mapping contract on the business sub-chain when the first resource is locked on the bill chain.
  • the business terminal can send a first business execution request for executing a temporary business to the verification node in the business subnetwork based on the above-mentioned first resource transfer success response information, so that the verification node can call the first temporary business contract on the business subchain based on the first business execution request to obtain the first mapping resource in the first resource mapping contract, and then execute the temporary business based on the first mapping resource.
  • Figure 20 is a schematic diagram of a cross-chain data transmission scenario provided by an embodiment of the present application.
  • the business object before performing cross-chain data transmission, can apply to the management chain for permission to transfer the first resource across the chain to obtain the corresponding business authorization certificate, and can use the obtained business authorization certificate as a subnet creation request certificate (for example, authorization code X).
  • the specific implementation process can refer to the above step S1901, which will not be repeated here.
  • the management chain consensus node will also write the business authorization certificate into the management chain as a registered business authorization certificate (for example, authorization code X').
  • the business terminal can determine the first cross-chain transfer transaction based on the temporary business, and then generate a first cross-chain resource transfer request based on the first cross-chain transfer transaction and the above-mentioned sub-network creation request credential (for example, authorization code X), and send the first cross-chain resource transfer request to the first consensus node.
  • the first cross-chain resource transfer request is used to instruct the first consensus node to transfer the first resource P (for example, bill asset P) associated with the temporary business from the bill chain (for example, bill chain) to the business sub-chain.
  • the business object can also specify the purpose of the first resource P across the chain in the first cross-chain resource transfer request (for example, only the resource content of the first resource P can be read, can only be used for redemption, can be used for transfer, etc.).
  • the first consensus node may write the first cross-chain transfer transaction carried in the first cross-chain resource transfer request into the first resource cross-chain bridge contract (e.g., the first bill cross-chain bridge contract) on the bill chain.
  • the first resource cross-chain bridge contract e.g., the first bill cross-chain bridge contract
  • the first resource cross-chain bridge contract may send a first transfer-out permission verification request for verifying the subnet creation request credential in the first cross-chain resource transfer request to the management chain consensus node based on the first cross-chain transfer transaction, so that the management chain consensus node, based on the first transfer-out permission verification request, calls the subnet management contract on the management chain to obtain the registration service authorization credential (e.g., authorization code X') from the management chain. Further, the first consensus node may compare the registration service authorization credential (e.g., authorization code X') with the subnet creation request credential (e.g., authorization code X) in the first cross-chain resource transfer request by calling the first resource cross-chain bridge contract to obtain a first comparison result.
  • the registration service authorization credential e.g., authorization code X'
  • subnet creation request credential e.g., authorization code X
  • the first consensus node can call the first resource contract (e.g., the bill asset contract) on the bill chain to lock the first resource P on the bill chain.
  • the first resource P cannot be operated or changed on the bill chain.
  • the first resource cross-chain bridge contract can also generate a first cross-chain event corresponding to the first cross-chain transfer transaction, which can be detected by the first cross-chain relay.
  • the first cross-chain relay When the first cross-chain relay reads the first cross-chain event, it can verify the first cross-chain event and the first cross-chain transfer-out transaction, and when the verification is successful, it constructs the first cross-chain transfer-in transaction corresponding to the first cross-chain transfer-out transaction, and sends the first cross-chain transfer-in transaction to the verification node associated with the first cross-chain transfer authority in the business subnetwork (i.e., the verification node in the business subnetwork). Any first verification node).
  • parameters such as the first resource P and the first cross-chain transfer authority can be filled into the first cross-chain transfer-in transaction.
  • the first verification node can write the first cross-chain transfer-in transaction into the second resource cross-chain bridge contract (for example, the second bill cross-chain bridge contract) on the business subchain, that is, the second resource cross-chain bridge contract on the business subchain can be called based on the source of the received first cross-chain transfer-in transaction (that is, the bill chain), and then when the first cross-chain transfer-in transaction is successfully verified (that is, the source of the first cross-chain transfer-in transaction is verified to be the bill chain), based on the transaction parameters in the first cross-chain transfer-in transaction (for example, the first resource P, the first cross-chain transfer authority, etc.), the first resource mapping contract indicated by the second resource cross-chain bridge contract (for example, the bill asset mapping contract) is called, and the first mapping resource WP (for example, the bill mapping asset WP) with the same resource content as the first resource P is cast on the business subchain, and the first mapping resource WP can be given relevant permission restrictions or business use scope (for example, only part
  • the first verification node can generate a first resource transfer success response message for the above-mentioned first cross-chain resource transfer request, and can write the first resource transfer success response message into the business subchain. Therefore, when the business terminal detects the first resource transfer success response message on the business subchain, it can be confirmed that the cross-chain transfer of the first resource P is completed.
  • the business terminal can send a first business execution request (which can carry the contract name and contract address of the first temporary business contract) for executing a temporary business to the verification node in the business subnetwork based on the first resource transfer success response message, and then the verification node can call the first temporary business contract (for example, the tax audit contract) on the business subchain based on the first business execution request to obtain the first mapping resource WP in the first resource mapping contract, and can execute the temporary business (for example, the tax audit business) based on the first mapping resource WP.
  • the first mapping resource WP can be used in the temporary business to perform different businesses such as red rebate, tax refund, and credit investigation.
  • the contract chain network and the business subnetwork are isolated by a second cross-chain relay associated with multiple blockchains.
  • the second cross-chain relay can be an independent relay server, or a relay server cluster or distributed system composed of multiple relay 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, and big data and artificial intelligence platforms.
  • the business terminal can send a second cross-chain resource transfer request to the second consensus node in the contract chain network based on the temporary business, wherein the second cross-chain resource transfer request is used to instruct the second consensus node to transfer the second resource associated with the temporary business from the contract chain to the business sub-chain corresponding to the business sub-network.
  • the second resource can be a general asset associated with the temporary business, for example, it can be a general bill-related asset associated with the temporary business (for example, credit information, tax information, etc.) or partially authorized visible asset-related information in the general bill-related asset, or it can be a general file-related asset associated with the temporary business (for example, qualification information, prescription statistics, etc.) or partially authorized visible file-related information in the general file-related asset, which is not limited here.
  • the business terminal can obtain the second resource transfer success response information obtained from the business sub-chain for the second cross-chain resource transfer request; the second resource transfer success response information is used to indicate that the second resource is successfully transferred from the contract chain to the business sub-chain, and there is a second mapping resource corresponding to the second resource on the business sub-chain; the second mapping resource is a resource with the same resource content as the second resource that is minted by the second resource mapping contract on the business sub-chain when the second resource is locked on the contract chain.
  • the business terminal can send a second business execution request for executing a temporary business to the verification node in the business subnetwork based on the second resource transfer success response information, so that the verification node calls the second temporary business contract on the business subchain to obtain the second mapping resource in the second resource mapping contract based on the second business execution request, and then executes the temporary business based on the second mapping resource.
  • Figure 21 is a schematic diagram of a cross-chain data transmission scenario provided by an embodiment of the present application.
  • the business object before performing cross-chain data transmission, can apply to the management chain for permission to transfer the second resource across the chain to obtain the corresponding business authorization certificate, and can use the obtained business authorization certificate as a subnet creation request certificate.
  • the specific implementation process can refer to the above step S1901, which will not be repeated here.
  • the management chain consensus node will also write the business authorization certificate as the registration business authorization certificate (for example, authorization code X') into the management chain.
  • the business terminal can determine the second cross-chain transfer transaction based on the temporary business, and then generate a second cross-chain resource transfer request based on the second cross-chain transfer transaction and the above-mentioned sub-network creation request credential (for example, authorization code X), and send the second cross-chain resource transfer request to the second consensus node.
  • the second cross-chain resource transfer request is used to instruct the second consensus node to transfer the second resource Q (for example, credit information Q) associated with the temporary business from the contract chain (for example, the application contract chain) to the business sub-chain.
  • the business object can also specify the purpose of the second resource Q cross-chain in the second cross-chain resource transfer request (for example, the resource content of the second resource Q can only be read, can only be used for review, can be used for transfer, etc.).
  • the second consensus node can write the second cross-chain transfer transaction carried in the second cross-chain resource transfer request into the third resource cross-chain bridge contract (e.g., the first general cross-chain bridge contract) on the contract chain.
  • the third resource cross-chain bridge contract can send a second transfer-out permission verification request for verifying the subnet creation request credential in the second cross-chain resource transfer request to the management chain consensus node based on the second cross-chain transfer transaction, so that the management chain consensus node can call the subnet management contract on the management chain to obtain the registration service authorization credential (e.g., authorization code X') from the management chain based on the second transfer-out permission verification request.
  • the second consensus node can compare the registration service authorization credential (e.g., authorization code X') with the subnet creation request credential (e.g., authorization code X) in the second cross-chain resource transfer request by calling the third resource cross-chain bridge contract to obtain a second comparison result.
  • the second consensus node can call the second resource contract (for example, the derivative business contract) on the contract chain to lock the second resource Q on the contract chain.
  • the second resource Q cannot be operated or changed on the contract chain.
  • the third resource cross-chain bridge contract can also generate a second cross-chain event corresponding to the second cross-chain transfer transaction, which can be detected by the second cross-chain relay.
  • the second cross-chain relay reads the second cross-chain event
  • the second cross-chain event and the second cross-chain transfer-out transaction can be verified, and when the verification is successful, the second cross-chain transfer-in transaction corresponding to the second cross-chain transfer-out transaction is constructed, and the second cross-chain transfer-in transaction can be sent to the verification node associated with the second cross-chain transfer authority in the business subnetwork (i.e., any second verification node in the business subnetwork).
  • the second cross-chain transfer-in transaction can be sent to the verification node associated with the second cross-chain transfer authority in the business subnetwork (i.e., any second verification node in the business subnetwork).
  • parameters such as the second resource Q and the second cross-chain transfer authority can be filled into the second cross-chain transfer-in transaction.
  • the second verification node can write the second cross-chain transfer transaction into the fourth resource cross-chain bridge contract (e.g., the second general cross-chain bridge contract) on the business subchain, that is, the fourth resource cross-chain bridge contract on the business subchain can be called based on the source of the received second cross-chain transfer transaction (i.e., the contract chain), and then when the second cross-chain transfer transaction is successfully verified (i.e., the source of the second cross-chain transfer transaction is verified to be the contract chain), based on the transaction parameters in the second cross-chain transfer transaction (e.g., the second resource Q, the second cross-chain transfer authority, etc.), the second resource mapping contract indicated by the fourth resource cross-chain bridge contract (e.g., the general asset mapping contract) is called, and the second mapping resource WQ (e.g., the general mapping asset WQ) having the same resource content as the second resource Q is cast on the business subchain, and the second mapping resource WQ can be given relevant permission restrictions or business use scope (e.g., the fourth resource
  • the second verification node can generate a second resource transfer success response message for the above-mentioned second cross-chain resource transfer request, and can write the second resource transfer success response message into the business subchain. Therefore, when the business terminal detects the second resource transfer success response message on the business subchain, it can be confirmed that the cross-chain transfer of the second resource Q is complete.
  • the business terminal can send a second business execution request (which can carry the contract name and contract address of the second temporary business contract) for executing a temporary business to the verification node in the business subnetwork based on the second resource transfer success response message, and then the verification node can call the second temporary business contract (for example, a tax audit contract) on the business subchain based on the second business execution request to obtain the second mapping resource WQ in the second resource mapping contract, and can execute the temporary business (for example, a tax audit business) based on the second mapping resource WQ.
  • the second mapping resource WQ can be used in the temporary business.
  • the second mapping resource WQ is used to carry out different businesses such as redemption, tax refund, credit investigation, etc.
  • first mapping resource WP corresponding to the first resource P
  • second mapping resource WQ corresponding to the second resource Q
  • the business terminal can send a third business execution request (which can carry the contract name and contract address of the third temporary business contract) for executing a temporary business to the verification node in the business subnetwork based on the first resource transfer success response information and the second resource transfer success response information, and then the verification node can call the third temporary business contract (for example, the tax refund review contract) on the business subchain based on the third business execution request to respectively call the above-mentioned first temporary business contract and the second temporary business contract to obtain the first mapping resource WP in the first resource mapping contract and the second mapping resource WQ in the second resource mapping contract, and can execute the temporary business (for example, the tax refund review business) based on the first mapping resource WP and the second mapping resource WQ.
  • a third business execution request (which can carry the contract name and contract address of the third temporary business contract) for executing a temporary business to the verification node in the business subnetwork based on the first resource transfer success response information and the second resource transfer success response information
  • the verification node can call the third temporary
  • the embodiments of the present application can also support the transfer of temporary business execution results obtained by executing temporary business (for example, the number of invoices obtained by counting electronic invoices, the drug information obtained by counting electronic prescriptions, etc.) back to the corresponding bill chain or contract chain.
  • the transfer process is similar to the above-mentioned process of transferring relevant resources from the bill chain or contract chain to the business sub-chain, and will not be repeated here.
  • the verification node can return the final result corresponding to the temporary business to other related chains.
  • the audit result based on the electronic bill can be returned to the management chain, so that the management consensus node can find the problematic electronic bill based on the audit result, and extract it and send it to the bill chain, so as to perform red-check and other services (that is, reverse interaction between different blockchains can be achieved).
  • the embodiment of the present application can construct a business sub-network in real time according to business needs on the basis of a multi-blockchain architecture, so as to independently process some temporary businesses that will generate a large amount of data or for designated purposes.
  • these temporary businesses are not running on the bill chain or contract chain, the corresponding temporary business execution results are stored and destroyed by the business sub-chain corresponding to the business sub-network, thereby reducing the waste of main chain space.
  • the subnet creation server can quickly build a business sub-network by reusing the existing consensus nodes in the bill chain network and the contract chain network, without the need for the business object to provide the verification node of the business sub-network by itself, thereby saving additional verification node resource overhead and improving the utilization rate of consensus nodes in the multi-blockchain system, while improving the creation efficiency and security of the business sub-network.
  • Figure 22 is an interactive schematic diagram of a blockchain electronic bill scenario provided by an embodiment of the present application.
  • the embodiment of the present application can quickly build nodes by managing chain authorization and reusing the verifiers (i.e., consensus nodes) of the bill chain and the application contract chain, and can also provide cross-chain capabilities for the asset status of the business subchain, the bill chain, and the application contract chain.
  • the main participants in creating and running a business subchain for example, the business subchain corresponding to subnet X
  • the interaction process of each participant in the blockchain electronic document scenario is similar to this, so it will not be repeated.
  • Management chain A subnet management contract is deployed on this chain.
  • users i.e., business objects
  • a business subnet for example, a business subnet with a network identifier of subnetX, referred to as subnet X
  • subnet X a business subnet with a network identifier of subnetX
  • Subnet creation server (also called subnet creation service): After obtaining authorization from the management chain, users can request to create subnet X from the subnet creation server.
  • the subnet creation server is operated by the tax management department and can verify the authorization of subnet X from the management chain. After successful verification, the subnet creation server will conditionally and randomly select bill chain validators (i.e. bill consensus nodes), application contract chain validators (i.e. application consensus nodes) and general validators (i.e. general consensus nodes, usually composed of users or external organizations) from the validator node network (including the bill chain network and the application contract chain network) according to the subnet business needs to form the network of the validator subnet (i.e. business subnet, such as subnet X).
  • bill chain validators i.e. bill consensus nodes
  • application contract chain validators i.e. application consensus nodes
  • general validators i.e. general consensus nodes, usually composed of users or external organizations
  • Bill Chain manages the entire life cycle and status of bill assets, deploys bill asset contracts and the first bill cross-border
  • the chain bridge contract can interact with the bill asset cross-chain service (also known as the bill cross-chain data transmission service) for cross-chain bill assets.
  • bill asset cross-chain service also known as the bill cross-chain data transmission service
  • Application contract chain manages data related to electronic invoices and tax derivative business contracts (i.e., general assets, such as credit information, tax refund information, etc.), deploys the first general cross-chain bridge contract (also called the application chain asset general cross-chain bridge contract), and can conduct cross-chain interaction of general assets related to derivative business with the general asset cross-chain service (also called the application chain cross-chain data transmission service).
  • general assets such as credit information, tax refund information, etc.
  • the first general cross-chain bridge contract also called the application chain asset general cross-chain bridge contract
  • general asset cross-chain service also called the application chain cross-chain data transmission service
  • Bill asset cross-chain service i.e. the first cross-chain relay mentioned above: used for the cross-chain transfer of bill assets between the bill chain and the business sub-chain. Only the bill chain verifier has the authority to access the bill asset cross-chain service. Therefore, if the corresponding business sub-chain needs to carry out related business after the bill asset cross-chain, it is necessary to specify the participation of the bill chain verifier when creating the business sub-network.
  • General asset cross-chain service i.e. the second cross-chain relay mentioned above: used to transfer some general data and status in the application contract chain to the business sub-chain. Only the application contract chain verifier can access the general asset cross-chain service. Therefore, if the corresponding business sub-chain needs to carry out related business after the relevant general assets and status on the application contract chain cross-chain, it is necessary to specify the participation of the application contract chain verifier when creating the business sub-network.
  • the subnet creation server of the system will select the validator nodes currently existing in the bill chain network and the application contract chain network according to the user's needs (i.e., the subnet registration configuration information submitted by the user) to form a business subnet for the user.
  • the validator nodes related to the bill chain and the application contract chain are reused, these validator nodes themselves also have real-time synchronization of the on-chain ledger data of the bill chain and the application contract chain. Therefore, through the cross-chain data transmission service, the cross-chain data transmission between the bill chain and the application contract chain to the business sub-chain can be completed very conveniently.
  • the embodiment of the present application can provide users with a convenient way to use the sub-chain, and also saves additional validator node resource overhead.
  • the cross-chain data transmission service in Figure 22 completes the cross-chain transfer of relevant assets and status data in the bill chain and the application contract chain to the business sub-chain.
  • the cross-chain permission will also be written into the genesis block information of the business sub-chain. It should be noted that the cross-chain permission cannot be changed during the life cycle of the entire business sub-chain. It can be understood that the cross-chain data transmission service will only provide cross-chain services for the business sub-chain after verifying the permission.
  • the cross-chain data transmission service when executing cross-chain data transmission and transfer, needs to interact with the asset cross-chain bridge contract (including the second bill cross-chain bridge contract and the second general cross-chain bridge contract) that has been deployed in the genesis block of the business sub-chain, as well as the first bill cross-chain bridge contract on the bill chain, and the first general cross-chain bridge contract on the application contract chain.
  • the second bill cross-chain bridge contract and the second general cross-chain bridge contract cannot be updated autonomously in the business sub-chain.
  • the business subchain runs as an independent blockchain after it starts running.
  • the management department (such as the tax management department) can trigger the subnet creation server to send a business termination transaction to subnet X.
  • subnet X will no longer create a new block.
  • the user can extract the final data on his business subchain (that is, the target extraction data, such as the final data status of the temporary business contract), and after the reading period ends, each validator node in subnet X (that is, each verification node in subnet X) will be offline and shut down.
  • the ledger data of subnet X can be backed up once by the subnet creation server, and each validator node in subnet X will no longer retain its copy of the ledger data.
  • the business subchain in the embodiment of the present application is: first, it can simplify its startup process. After the user registers, the consensus nodes corresponding to the bill chain and the application contract chain can be directly reused, eliminating the difficulty of users providing verification nodes by themselves and avoiding insecurity. Secondly, it provides effective cross-chain services and cross-chain protocols.
  • the business subchain can interact with the business data on the bill chain and the application contract chain under security authorization, allowing users to easily run temporary businesses (for example, invoice tax derivative businesses) in the business subchain.
  • the business sub-network allows users to have their own independent business sub-chains outside the application contract chain.
  • Independent business sub-chains can provide users with higher independent performance, independent data isolation and higher privacy services.
  • the business sub-chain can be used as a temporary business chain. The large amount of ledger data it runs will not occupy the main chain space of the application contract chain, and it can also save a lot of costs for users and management systems.
  • Figure 23 is a schematic diagram of the interactive process of a multi-blockchain data processing method provided by an embodiment of the present application.
  • the method can be jointly executed by a business terminal associated with multiple blockchains, a management chain consensus node in a management chain network, and a subnet creation server associated with multiple blockchains, wherein the business terminal can be the business terminal 30B shown in Figure 17 above, the management chain consensus node can be any consensus node in the management chain network 31 shown in Figure 17 above, for example, consensus node 31a, and the subnet creation server can be the subnet creation server 30C shown in Figure 17 above.
  • the method can at least include the following steps:
  • Step S2301 the business terminal sends a business authorization request to the management chain consensus node in the management chain network based on the temporary business requested by the business object;
  • Step S2302 The management chain consensus node configures the business authorization credential associated with the temporary business based on the business authorization request, writes the business authorization credential into the management chain as the registered business authorization credential, and returns the business authorization credential to the business terminal;
  • Step S2303 The business terminal uses the business authorization certificate returned by the management chain consensus node as the subnet creation request certificate, generates a subnet creation request based on the subnet creation request certificate, and sends the subnet creation request to the subnet creation server;
  • Step S2304 when the subnet creation server obtains the subnet creation request sent by the service terminal, it obtains the subnet creation request credential carried in the subnet creation request;
  • Step S2305 the subnet creation server verifies the subnet creation request credential by managing the registration service authorization credential associated with the temporary service on the chain, and obtains a credential verification result;
  • Step S2306 when the voucher verification result indicates that the verification is successful, the subnet creation server will use the consensus node obtained from the bill chain network as the first verification node, and the consensus node obtained from the contract chain network as the second verification node, and establish a business subnet corresponding to the temporary business through the first verification node and the second verification node.
  • Figure 24 is a system architecture diagram of a blockchain electronic bill scenario provided by an embodiment of the present application.
  • the business layer, routing proxy layer and core consensus network layer in the embodiment of the present application constitute the entire complete blockchain business system.
  • the core chain 1, core chain 2, ... and core chain N shown in Figure 24 are the target blockchains maintained by tax bureaus in different regions.
  • the business layer is in the witness network (i.e., the business network), and the business nodes in the business layer may include terminal devices corresponding to the electronic tax bureau, terminal devices corresponding to corporate users, and terminal devices corresponding to consumer users.
  • the electronic tax bureau may refer to the local tax bureau in the tax bureau's private network
  • corporate users may be invoicing service providers, reimbursement service providers, or retail enterprises in the public cloud (for example, KA enterprises, i.e., large retail customers and key retail customer enterprises), etc.
  • consumer users may be payment service providers, circulation service providers, or retail enterprises in the private cloud, etc.
  • the business nodes in the business network are mainly used to execute transaction services and do not participate in accounting consensus. It can be understood that the business nodes can generate transaction data for sending to relay nodes when executing temporary services.
  • the N relay nodes (i.e., routing nodes) in the routing proxy layer can be used to isolate the business layer and the core consensus network layer.
  • each relay node can have peer-to-peer service (i.e., P2P service), routing service, certificate cache, and authentication service.
  • P2P service peer-to-peer service
  • routing service refers to the service in the P2P network.
  • the network nodes in the P2P network do not need a central node to maintain the network status, but each node The node maintains the node status of the entire network or the connection status of its adjacent nodes through broadcast interaction with adjacent nodes.
  • Routing service is a basic function of a node and can be used for communication between nodes.
  • the certificate associated with the certificate cache may refer to a public key certificate system (PKI, Public Key Infrastructure).
  • PKI Public Key Infrastructure
  • a certificate is an identity certificate of a public key owner and is issued by an authority (CA, Certificate Authority).
  • CA Certificate Authority
  • the authentication service can be used to verify the data format of the received data, the legitimacy of the node, etc. It can be understood that in an embodiment of the present application, the relay node can forward the transaction data generated by the business node to the consensus node.
  • the consensus nodes (i.e., accounting nodes) in the core consensus network layer can be trusted nodes in the tax-specific network. It is understandable that each consensus node has the ability to package and block, that is, it can package and block the transaction data sent by the relay node to successfully write it into the target blockchain in the core consensus network layer.
  • the above-mentioned core consensus network layer may include a management chain network, a bill chain network, and an application contract chain network.
  • each of the above-mentioned target blockchains can be a multi-blockchain including a management chain, a bill chain, and an application contract chain.
  • the business object can send a business authorization request (for example, business authorization request A) determined based on a temporary business associated with an electronic bill to the management chain consensus node in the core consensus network layer through a business node associated with a business terminal, so as to obtain the corresponding business authorization certificate, wherein the management chain consensus node is a consensus node in the management chain network included in the core consensus network layer.
  • the business object can apply to the management chain in a certain target blockchain to create a business subnetwork (for example, business subnetwork B) in the above-mentioned core consensus network layer, and the business subnetwork is composed of a first verification node in the bill chain network and a second verification node in the application contract chain network.
  • a business subnetwork for example, business subnetwork B
  • the business subnetwork is composed of a first verification node in the bill chain network and a second verification node in the application contract chain network.
  • the resources associated with the above-mentioned temporary business can be obtained to execute the temporary business.
  • the embodiment of the present application forms a business sub-network for executing temporary business on the basis of a multi-blockchain architecture, which can reduce the waste of main chain space.
  • the efficiency of creating the business sub-network can be improved.
  • Figure 25 is a structural diagram of a cross-chain processing device based on multiple blockchains provided in this application.
  • a blockchain acquisition module 2501 is used to acquire multiple blockchains
  • a blockchain determination module 2502 configured to determine at least two blockchains to be cross-chain processed among the multiple blockchains;
  • the processing module 2503 is used to perform cross-chain processing on the at least two blockchains based on the chain information of the at least two blockchains.
  • processing module 2503 is used to configure the cross-chain configuration item to the at least one other blockchain based on the management chain; and/or, transmit the target transaction resources to the at least one other blockchain based on the management chain; and/or, reuse the consensus nodes in the at least one other blockchain based on the management chain to process temporary business.
  • processing module 2503 is used to configure the cross-chain configuration item to the at least one other blockchain based on the management chain; and/or, transmit the target transaction resources to the at least one other blockchain based on the management chain; and/or, reuse the consensus nodes in the at least one other blockchain based on the management chain to process temporary business.
  • the cross-chain processing device based on multiple blockchains includes a cross-chain configuration device based on multiple blockchains, a cross-chain data transmission device based on multiple blockchains, and a multi-blockchain data processing device.
  • cross-chain processing includes cross-chain configuration, which is used to indicate configuring a configuration item of one blockchain to other blockchains.
  • the cross-chain configuration device 1 based on multiple blockchains in Figure 25 can run on the management chain consensus node.
  • the cross-chain configuration device 1 based on multiple blockchains may include: a determination module 11, a calling module 12, a receiving module 13, a generation module 14, a first acquisition module 15 and a first configuration module 16;
  • the determination module 11 is used to execute step S401 in the embodiment of FIG. 4 .
  • the calling module 12 is used to execute step S402 in the embodiment of FIG. 4 .
  • the receiving module 13 is used to execute step S403 in the embodiment of FIG. 4 .
  • the generating module 14 is used to execute step S404 in the embodiment of FIG. 4 .
  • the first acquisition module 15 is used to execute step S405 in the embodiment of FIG. 4 .
  • the first configuration module 16 is used to execute step S405 in the embodiment of FIG. 4 .
  • the calling module 12 includes:
  • the calling subunit 121 is used to execute step S402 in the embodiment of FIG. 4 .
  • the generating subunit 122 is used to execute step S402 in the embodiment of FIG. 4 .
  • the calling module 12 is also used to execute step S506 in the embodiment of FIG. 5 .
  • the receiving module 13 is further configured to execute step S507 in the embodiment of FIG. 5 .
  • the generating module 14 is also used to execute step S508 in the embodiment of FIG. 5 .
  • the calling module 12 includes:
  • the calling submodule 121 is used to execute step S506 in the embodiment of FIG. 5 .
  • the generating submodule 122 is used to execute step S506 in the embodiment of FIG. 5 .
  • the multi-blockchain cross-chain data transmission device 2 in FIG. 25 can be applied to a cross-chain service terminal.
  • the multi-blockchain cross-chain data transmission device 2 may include: an event receiving module 21, a data processing module 22, and a data sending module 23;
  • the event receiving module 21 is used to execute step S1201 in the embodiment of FIG. 12 .
  • the data processing module 22 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the data sending module 23 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the data processing module 22 includes: an event quantity determination unit 221, a transaction detection information acquisition unit 222, a transaction comparison unit 223, and a transaction verification unit 224;
  • the event quantity determination unit 221 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the transaction detection information acquisition unit 222 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the transaction comparison unit 223 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the transaction verification unit 224 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the transaction verification unit 224 includes: a dependent data acquisition unit 2241 and an information verification unit 2242;
  • the dependency data acquisition unit 2241 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the information verification unit 2242 is used to execute step S1202 in the embodiment of FIG. 12 .
  • the information verification unit 2242 is also used to execute step S1202 in the embodiment of FIG. 12 .
  • the data sending module 23 includes: a transaction signature unit 231 and a signature sending unit 232 .
  • the transaction signature unit 231 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the signature sending unit 232 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the event receiving module 21 is also used to execute step S1304 in the embodiment of FIG. 13 .
  • the data processing module 22 is also used to execute step S1302 in the embodiment of FIG. 13 .
  • the data sending module 23 is also used to execute step S1306 in the embodiment of FIG. 13 .
  • the data processing module 22 includes: an event quantity determination unit 221, a transaction detection information acquisition unit 222, a transaction comparison unit 223, and a transaction verification unit 224;
  • the event quantity determination unit 221 is also used to execute step S1305 in the embodiment of FIG. 13 .
  • the transaction detection information acquisition unit 222 is also used to execute step S1305 in the embodiment of FIG. 13 .
  • the transaction comparison unit 223 is also used to execute step S1305 in the embodiment of FIG. 13 .
  • the transaction verification unit 224 is also used to execute step S1305 in the embodiment of FIG. 13 .
  • the receiving module 21 is also used to execute step S1306 in the embodiment of FIG. 13 .
  • the data processing module 22 is also used to execute the steps in the embodiment of FIG. 14 above.
  • the data processing module 23 is also used to execute the steps in the embodiment of FIG. 14 above.
  • the event receiving module 21 is also used to execute the steps in the embodiment of Figure 14.
  • the data processing module 22 includes: a key splitting unit 225 and a key sending unit 226;
  • the key splitting unit 225 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the key sending unit 226 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the data processing module 22 includes: a key receiving unit 227 and a key building unit 228;
  • the key receiving unit 227 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the key building unit 228 is used to execute step S1203 in the embodiment of FIG. 12 .
  • the multi-blockchain data processing device 3 in Figure 25 can be applied to manage chain consensus nodes.
  • the multi-blockchain data processing device 3 includes: a receiving module 31, a calling module 32, a writing module 33, an acquisition module 34, and a sending module 35.
  • a receiving module 31 configured to receive a service authorization request for a temporary service sent by a service object via a service terminal;
  • a calling module 32 configured to call the subnet management contract deployed on the management chain to configure a business authorization credential associated with the temporary business for the business object based on the business authorization request;
  • a writing module 33 is used to write the business authorization certificate into the management chain as a registration business authorization certificate, and return the business authorization certificate to the business terminal;
  • the business authorization certificate is used to generate a subnet creation request sent to a subnet creation server associated with the multiple blockchains;
  • the subnet creation request is used to instruct the subnet creation server to verify the subnet creation request certificate when obtaining the registration business authorization certificate on the management chain, and when the verification is successful, the consensus node obtained from the bill chain network is used as the first verification node, and the consensus node obtained from the contract chain network is used as the second verification node, the first verification node and the second verification node are used to jointly establish a business subnet corresponding to the temporary business;
  • the business subnet is independent of the management chain network, the bill chain network and the contract chain network.
  • the calling module 32 is used to call the subnet management contract deployed on the management chain to configure the business authorization certificate associated with the temporary business for the business object when it is determined that the object signature information verification is successful through the public key information in the business authorization request.
  • the receiving module 31 is used to receive a subnet-initiated transaction when the service subnet is formed.
  • the acquisition module 34 is used to call the subnet management contract on the management chain based on the subnet startup transaction, and obtain the genesis block information associated with the business subnet from the management chain;
  • the genesis block information includes the subnet registration configuration information submitted by the business object to the management chain consensus node through the business terminal;
  • the sending module 35 is used to send the genesis block information to the verification node in the business subnetwork, so that the verification node writes the genesis block information into the business subchain corresponding to the business subnetwork.
  • FIG26 is a schematic diagram of the structure of a cross-chain processing device based on multiple blockchains provided by the present application.
  • the device includes:
  • a determination module 2601 is used to determine at least two blockchains to be cross-chain processed in the multiple blockchains;
  • the processing module 2602 is used to collaborate with the management chain consensus node to perform cross-chain processing on the at least two blockchains.
  • the cross-chain processing device based on multiple blockchains includes at least one of a cross-chain configuration device based on multiple blockchains, a cross-chain data transmission device based on multiple blockchains, and a multi-blockchain data processing device.
  • FIG. 27 is a schematic diagram of the structure of a cross-chain configuration device based on multiple blockchains provided by the present application.
  • the cross-chain configuration device 2 based on multiple blockchains can run on a cross-chain relay, and the multiple blockchains include a management chain associated with a management chain consensus node and other blockchains to be cross-chain configured; the cross-chain relay is used to isolate the management chain network corresponding to the management chain and other blockchain networks corresponding to other blockchains.
  • the cross-chain configuration device 2 based on multiple blockchains can be a computer program (including program code) running in the cross-chain relay, for example, the cross-chain configuration device 2 based on multiple blockchains can be an application software; the cross-chain configuration device 2 based on multiple blockchains can include: a sending module 21, a second acquisition module 22 and a second configuration module 23;
  • the sending module 21 is used to execute step S601 in the embodiment of FIG. 6 .
  • the sending module 21 is also used to execute step S602 in the embodiment of FIG. 6 .
  • the second acquisition module 22 is used to execute step S603 in the embodiment of FIG. 6 .
  • the second configuration module 23 is used to execute step S604 in the embodiment of FIG. 6 .
  • the second configuration module 23 includes: a construction subunit 231, which is used to execute step S604 in the embodiment of FIG. 6 above.
  • the sending subunit 232 is used to execute step S604 in the embodiment of FIG. 6 .
  • the sending module 21 is also used to execute step S601 in the embodiment of FIG. 6 .
  • the sending module 21 is also used to execute step S701 in the embodiment of FIG. 7 .
  • the sending module 21 is also used to execute step S702 in the embodiment of FIG. 7 .
  • the second configuration module 23 is also used to execute step S703 in the embodiment of FIG. 7 .
  • the second configuration module 23 includes:
  • the construction subunit 231 is used to execute the steps in the embodiment of FIG. 7 above.
  • the sending subunit 232 is used to execute the steps in the embodiment of FIG. 7 .
  • the sending module 21 is also used to execute step S702 in the embodiment of FIG. 7 .
  • the cross-chain configuration system 3 based on multiple blockchains may include a management chain consensus node 3a, a cross-chain relay 3b, and other consensus nodes 3c; wherein, the management chain consensus node 3a and other consensus nodes 3c may interact through a cross-chain relay, and the management chain consensus node 3a may be a management chain consensus node in the management chain network described in the above embodiment, and the management chain consensus node may be any blockchain node in the consensus network 100a shown in Figure 1 above; wherein, other consensus nodes 3c may be other consensus nodes in other blockchain networks described in the above embodiment, and the other consensus nodes may be any blockchain node in the consensus network 200a or consensus network 300 shown in Figure 1 above, which will not be further described here; the cross-chain relay 3b may be the cross-chain relay described in the above embodiment.
  • FIG. 29 is a structural diagram of a cross-chain data transmission device based on multiple blockchains provided in the present application.
  • the multi-blockchain cross-chain data transmission device 2 can be applied to the second consensus node associated with the first business sub-chain.
  • the multiple blockchains include a source blockchain, a business sub-chain and a target chain.
  • the source blockchain and the business sub-chain interact with each other through a trusted cross-chain program;
  • the source blockchain includes a contract chain, and the trusted cross-chain program that interacts with the contract chain is a first cross-chain program;
  • the business sub-chain includes a first business sub-chain, and the first business sub-chain is created by the target consensus node associated with the target chain according to the first business associated with the first business object.
  • the multi-blockchain data processing device 2 can be a computer program (including program code) running in a cross-chain service terminal.
  • the multi-blockchain data processing device 2 can be an application software.
  • the multi-blockchain data processing device 2 may include: a cross-chain construction transaction acquisition module 21, a resource casting module 22;
  • the cross-chain construction transaction acquisition module 21 is used to execute step S1501 in the embodiment of Figure 15 above.
  • the resource casting module 22 is used to execute step S1502 in the embodiment of FIG. 15 above.
  • FIG. 30 is a structural diagram of a cross-chain data transmission device based on multiple blockchains provided by the present application.
  • the multi-blockchain data processing device 3 can be applied to the target consensus node.
  • the multi-blockchain includes a source blockchain, a business sub-chain and a target chain.
  • the source blockchain and the business sub-chain interact with each other through a trusted cross-chain program;
  • the source blockchain includes a contract chain, and the trusted cross-chain program that interacts with the contract chain is a first cross-chain program;
  • the business sub-chain includes a first business sub-chain, and the first business sub-chain is created by the target consensus node associated with the target chain according to the first business associated with the first business object.
  • the multi-blockchain data processing device 3 can be a computer program (including program code) running in a cross-chain service terminal.
  • the multi-blockchain data processing device 3 can be an application software.
  • the multi-blockchain data processing device 3 may include: a transaction detection module 31, an event sending module 32;
  • the transaction detection module 31 is used to execute step S1601 in the embodiment of FIG. 16 .
  • the event sending module 32 is used to execute step S1602 in the embodiment of FIG. 16 .
  • the multi-blockchain data processing system 4 may include a management chain consensus node 4a, a contract chain consensus node 4b, a bill chain consensus node 4c and a cross-chain service terminal 4d; wherein the consensus node 4a may be the management chain consensus node in the target chain network described in the above embodiment, and the management chain consensus node may be the consensus network 100a shown in Figure 1 above. Any blockchain node, will not be further described here.
  • the consensus node 4b can be the contract chain consensus node in the contract chain network described in the embodiment corresponding to Figure 2 above, and the contract chain consensus node can be any blockchain node in the consensus network 300a shown in Figure 1 above, and will not be further described here.
  • the consensus node 4c can be the bill chain consensus node in the first business subchain described in the embodiment corresponding to Figure 2 above, and the cross-chain service terminal 4d can realize cross-chain data transmission through a trusted cross-chain program, which will not be repeated here.
  • the modules in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.
  • the multi-blockchain data processing device 3 may include: a credential acquisition module 31, a credential verification module 32, a subnet formation module 33, a creation response module 34, a subnet startup module 35, a genesis block generation module 36, a subnet gateway shutdown module 37, and a data backup module 38;
  • the credential acquisition module 31 is used to execute step S1801 in the embodiment of FIG. 18 above.
  • the credential verification module 32 is used to execute step S1802 in the embodiment of FIG. 18 above.
  • the voucher verification module 32 may include: a transaction sending unit 321, a voucher comparison unit 322;
  • the transaction sending unit 321 is used to execute step S1802 in the embodiment of FIG. 18 above.
  • the voucher comparison unit 322 is used to execute step S1802 in the embodiment of FIG. 18 above.
  • the subnet building module 33 is used to execute step S1803 in the embodiment of FIG. 18 above.
  • a response module 34 is created to execute the steps in the embodiment of FIG. 17 .
  • the subnet startup module 35 is used to execute the steps in the embodiment of FIG. 17 above.
  • the genesis block generation module 36 is used to execute the steps in the embodiment of FIG. 17 above.
  • the sub-gateway stop module 37 is used to execute the steps in the embodiment of Figure 17 above.
  • the data backup module 38 is used to execute the steps in the embodiment of FIG. 17 .
  • the multi-blockchain data processing device 2 may include: a business authorization module 21, a request generation module 22, an instruction sending module 23, a data extraction module 24, a first request module 25, a first response module 26, a first execution module 27, a second request module 28, a second response module 29, and a second execution module 30;
  • the request generation module 22 is used to execute step S1901 in the embodiment of FIG. 19 above.
  • the request generating module 22 may include: a request determining unit 211 and a request sending unit 212;
  • the request determination unit 211 is used to execute step S1901 in the embodiment of FIG. 19 above.
  • the request sending unit 212 is used to execute step S1901 in the embodiment of Fig. 19.
  • the request generating module 22 is used to execute step S1902 in the embodiment of Fig. 19.
  • the instruction sending module 23 is used to execute step S1902 in the embodiment of FIG. 19 above.
  • the data extraction module 24 is used to execute step S1902 in the embodiment of FIG. 19 above.
  • the first request module 25 is used to execute step S1902 in the embodiment of FIG. 19 above.
  • the first response module 26 is used to execute step S1902 in the embodiment of FIG. 19 .
  • the first execution module 27 is used to execute step S1902 in the embodiment of FIG. 19 .
  • the second request module 28 is used to execute step S1902 in the embodiment of FIG. 19 above.
  • the second response module 29 is used to execute step S1902 in the embodiment of FIG. 19 .
  • the second execution module 30 is used to execute step S1902 in the embodiment of FIG. 19 above.
  • the multi-blockchain data processing system 3 may include a data processing device 1a and a data processing device 2a.
  • the data processing device 1a can be the multi-blockchain data processing device 1 in the above-mentioned embodiment. It can be understood that the multi-blockchain data processing device 1a can be integrated in the subnet creation server 30C in the above-mentioned embodiment, so it will not be repeated here.
  • the data processing device 2a can be the multi-blockchain data processing device 2 in the above-mentioned embodiment. It can be understood that the data processing device 2a can be integrated in the business terminal 30B in the above-mentioned embodiment, so it will not be repeated here.
  • FIG. 35 is a structural diagram of a computer device provided in an embodiment of the present application.
  • the computer device 1000 can be a user terminal or a server, which will not be limited here.
  • the present application takes the computer device as a server as an example, and the computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005.
  • the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002.
  • the communication bus 1002 is used to realize the connection and communication between these components.
  • the user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory.
  • the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001.
  • the memory 1005 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 1004 in the computer device 1000 can also provide a network communication function.
  • the network interface 1004 can provide a network communication function;
  • the user interface 1003 is mainly used to provide an input interface for the user; and
  • the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the description of the cross-chain processing method based on multiple blockchains in the above embodiment, which will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • An embodiment of the present application provides a computer device, wherein the computer device includes a memory and a processor; 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 cross-chain processing method based on multiple blockchains as described above.
  • An embodiment of the present application provides a computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and the computer program is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the cross-chain processing method based on multiple blockchains as described above.
  • An embodiment of the present application provides a computer program product, which includes a computer program/instruction, and the computer program/instruction is executed by a processor to implement the cross-chain processing method based on multiple blockchains as described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请公开了一种基于多区块链的跨链处理方法、装置、设备、系统及介质,属于区块链技术领域。该方法包括:获取多区块链;在所述多区块链中确定待进行跨链处理的至少两个区块链;基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理。本申请通过跨链处理的方式,实现了对多区块链的综合性管理,提高了多区块链的处理效率。

Description

基于多区块链的跨链处理方法、装置、设备、系统及介质
本申请同时要求于2022年10月20日提交的申请号为202211298596.9、发明名称为“基于多区块链的跨链配置方法、装置、设备、系统及介质”的中国专利申请的优先权、2022年10月24日提交的申请号为202211303327.7、发明名称为“一种多区块链数据处理方法、装置、设备、介质及产品”的中国专利申请的优先权、2022年10月24日提交的申请号为202211306695.7、发明名称为“基于多区块链的数据跨链方法、相关设备、介质及产品”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链技术领域,特别涉及一种基于多区块链的跨链处理方法、装置、设备、系统及介质。
背景技术
在多区块链的应用场景下,该多区块链中的各区块链均具有独立性。
在对多区块链进行处理时,需要单独在某个区块链上进行处理。例如,对多区块链进行配置时需要各区块链上的共识节点,独立配置自己所在链的一些基础数据信息。比如,对于彼此相互独立的区块链A和区块链B而言,可以通过区块链A上的共识节点单独配置自己所在链的出块时间、区块大小以及该区块链A上的业务逻辑规则等配置信息,而区块链B上的共识节点也可以单独配置自己所在链的出块时间、区块大小以及该区块链B上的业务逻辑规则等配置信息。
显然,对于这两条链(即区块链A和区块链B)上的共识节点而言,会因为各链所需执行的业务不同而导致配置信息之间存在差异,以至于难以确保彼此相互独立的各链上的配置信息的一致性,此外,多区块链中位于不同链中的数据难以进行跨链处理且性能扩展不足,使得多区块链的处理较为困难。
发明内容
本申请实施例提供了一种基于多区块链的跨链处理方法、装置、设备、系统及介质,通过对多区块链中的至少两个区块链进行跨链处理,实现了对多区块链的高效管理。
本申请实施例一方面,提供了一种基于多区块链的跨链配置方法,所述方法由多区块链系统中的管理链共识节点执行,所述多区块链包括所述管理链和至少一个其他区块链,所述管理链共识节点位于管理链中,所述方法包括:
获取多区块链;
在所述多区块链中确定待进行跨链处理的至少两个区块链;
基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理。
本申请实施例一方面,提供了一种基于多区块链的跨链处理方法,所述方法由多区块链系统中的链外处理设备执行,所述方法包括:
在所述多区块链中确定待进行跨链处理的至少两个区块链;
与管理链共识节点协同对所述至少两个区块链进行跨链处理;
其中,所述多区块链包括所述管理链和至少一个其他区块链,所述管理链共识节点位于管理链中。
本申请实施例一方面,提供了一种基于多区块链的跨链处理装置,所述装置包括:
区块链获取模块,用于获取多区块链;
区块链获取确定模块,用于在所述多区块链中确定待进行跨链处理的至少两个区块链;
处理模块,用于基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理。
本申请实施例一方面,提供了一种基于多区块链的跨链处理装置,所述装置包括:
确定模块,用于在所述多区块链中确定待进行跨链处理的至少两个区块链;
处理模块,用于与管理链共识节点协同对所述至少两个区块链进行跨链处理;
其中,所述多区块链包括所述管理链和至少一个其他区块链,所述管理链共识节点位于管理链上。
本申请实施例一方面,提供了一种计算机设备,包括存储器和处理器,存储器与处理器相连,存储器用于存储计算机程序,处理器用于调用计算机程序,以使得该计算机设备执行本申请实施例中上述一方面提供的方法。
本申请实施例一方面,提供了一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,计算机程序适于由处理器加载并执行,以使得具有处理器的计算机设备执行本申请实施例中上述一方面提供的方法。
根据本申请一个方面,提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述一方面提供的方法。
本申请提供的技术方案带来的有益效果至少包括:
在本申请实施例中,获取多区块链;在多区块链中确定待进行跨链处理的至少两个区块链;基于至少两个区块链的链信息,对至少两个区块链进行跨链处理。本申请实施例通过跨链处理的方式,实现了对多区块链的综合性管理,提高了多区块链的处理效率。
附图说明
图1是本申请实施例提供的一种区块链网络的分层结构示意图;
图2是本申请实施例提供的一种基于多区块链的区块链电子票据平台的场景示意图;
图3是本申请实施例提供的一种基于多区块链的跨链配置的示意图;
图4是本申请实施例提供的一种基于多区块链的跨链配置方法的流程示意图;
图5是本申请实施例提供的一种基于多区块链的跨链配置方法的流程示意图;
图6是本申请实施例提供的一种基于多区块链的跨链配置方法的流程示意图;
图7是本申请实施例提供的一种基于多区块链的跨链配置方法的流程示意图;
图8是本申请实施例提供的一种基于多区块链的跨链配置方法的流程示意图;
图9是本申请实施例提供的一种基于多区块链的跨链配置方法的流程示意图;
图10是本申请提供的一种基于多区块链的跨链数据传输方法的示意图;
图11是本申请提供的一种基于多区块链的跨链数据传输过程的示意图;
图12是本申请提供的一种基于多区块链的跨链数据传输方法的流程示意图;
图13是本申请提供的一种多区块链跨链数据传输方法;
图14是本申请提供的一种基于多区块链的跨链数据传输过程的示意图;
图15是本申请提供的一种基于多区块链的跨链数据传输方法的流程示意图;
图16是本申请提供的一种基于多区块链的跨链数据传输方法的流程示意图;
图17是本申请提供的一种组建业务子网络的场景示意图;
图18是本申请提供的一种多区块链数据处理方法示意图;
图19是本申请提供的一种多区块链数据处理方法示意图;
图20是本申请提供的一种跨链数据传输的场景示意图;
图21是本申请提供的一种跨链数据传输的场景示意图;
图22是本申请提供的一种区块链电子票据场景下的交互示意图;
图23是本申请提供的一种多区块链数据处理方法的交互流程示意图;
图24是本申请提供的一种区块链电子票据场景下的系统架构图;
图25是本申请提供的一种基于多区块链的跨链处理装置;
图26是本申请提供的一种基于多区块链的跨链处理装置;
图27是本申请提供的一种基于多区块链的跨链配置装置的结构示意图;
图28是本申请提供的一种基于多区块链的跨链配置系统的示意图;
图29是本申请提供的一种基于多区块链的跨链数据传输装置的结构示意图;
图30是本申请提供的一种基于多区块链的跨链数据传输装置的结构示意图;
图31是本申请提供的一种多区块链跨链数据传输系统的示意图;
图32是本申请提供的一种多区块链数据处理装置的结构示意图;
图33是本申请提供的一种多区块链数据处理装置的结构示意图;
图34是本申请提供的一种多区块链数据处理系统的结构示意图;
图35是本申请提供的一种计算机设备的结构示意图。
具体实施方式
首先,对本申请实施例涉及的名词进行简单地介绍:
(1)跨链配置中的“管理链共识节点”是指管理链网络中的共识节点,也可称为“第一共识节点”,也即对应发明名称为“基于多区块链的跨链配置方法、装置、设备、系统及介质”的中国专利申请中的“第一共识节点”。
(2)跨链配置中的“其他区块链”是指待进行跨链参数配置的区块链,也可称为待进行跨链配置的“目标链”,也即对应发明名称为“基于多区块链的跨链配置方法、装置、设备、系统及介质”的中国专利申请中的“目标链”。
(3)跨链配置中的“其他共识节点”是指其他区块链中的共识节点,也可称为“目标共识节点”,也即对应发明名称为“基于多区块链的跨链配置方法、装置、设备、系统及介质”的中国专利申请中的“目标共识节点”。
(4)跨链数据传输中的“管理链共识节点”是指目标链中的共识节点,也可称为“目标共识节点”,也即对应发明名称为“基于多区块链的数据跨链方法、相关设备、介质及产品”的中国专利申请中的“目标共识节点”。
(5)跨链数据传输中的“合约链”是指存在与第一业务相关联的数据资源的区块链,也可称为“第一链”,也即对应发明名称为“基于多区块链的数据跨链方法、相关设备、介质及产品”的中国专利申请中的“第一链”。
(6)跨链数据传输中的“票据链”是指存在与第二业务相关联的数据资源的区块链,也可称为“第二链”,也即对应发明名称为“基于多区块链的数据跨链方法、相关设备、介质及产品”的中国专利申请中的“第二链”。
(7)跨链数据处理(简称数据处理)中的“管理链共识节点”是指管理链中的共识节点,也可称为“管理链共识节点”,也即对应发明名称为“多区块链数据处理方法、装置、设备、介质及产品”的中国专利申请中的“管理链共识节点”。
(8)跨链数据处理中的“管理链”用于存放与临时业务相关联的注册业务授权凭证,也可称为“目标链”,也即对应发明名称为“多区块链数据处理方法、装置、设备、介质及产品”的中国专利申请中的“目标链”。
(9)跨链数据处理中的“管理链网络”是指管理链对应的网络,也可称为“目标链”对应的“目标链网络”,也即对应发明名称为“多区块链数据处理方法、装置、设备、介质及产品”的中国专利申请中的“目标链网络”。
(10)跨链数据处理中的“票据链”是指提供共识节点的区块链,也可称为“第一链”,也即对应发明名称为“多区块链数据处理方法、装置、设备、介质及产品”的中国专利申请中的“第一链”。
(11)跨链数据处理中的“合约链”是指提供共识节点的区块链,也可称为“第二链”,也即对应发明名称为“多区块链数据处理方法、装置、设备、介质及产品”的中国专利申请中的“第二链”。
请参见图1,图1是本申请实施例提供的一种区块链网络的分层结构示意图。如图1所示的分层结构应用于多业务协作处理平台所对应的区块链系统,在该区块链系统所对应的区块链网络中,包括部署在公网中的业务网络、和部署在私有云中的多个共识网络。如图1所示,这里的业务网络可以为图1所示的业务网络400a,且这里的多个共识网络具体可以包括图1所示的共识网络100a、共识网络200a、共识网络300a。
在如图1所示的业务网络400a中,部署有多个业务节点,这里的多个业务节点具体可以包括图1所示的业务节点110a、业务节点110b、业务节点110c、业务节点110d、业务节点110e、业务节点110f、业务节点110g、…、业务节点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、共识网络100b和共识网络100c统称为核心共识网络,并可以将上述核心共识网络中的各个节点统称为核心节点。
其中,应当理解的是,在上述区块链系统中,共识网络100a中的每个节点(比如,共识节点10a、共识节点10b、共识节点10c和共识节点10d等核心节点)上所存储的区块链均为区块链10e,这里的区块链10e可以为第一链,且第一链所对应的共识网络(即共识网络100a)可以为第一链网络,该第一链网络中的共识节点可以统称为第一共识节点。共识网络200a中的每个节点(比如,共识节点11a、共识节点11b、共识节点11c和共识节点11d等核心节点)上所存储的区块链均为区块链11e,这里的区块链11e可以为第二链,且第二链所对应的共识网络(即共识网络200a)可以为第二链网络,该第二链网络中的共识节点可以统称为第二共识节点。共识网络300a中的每个节点(比如,共识节点12a、共识节点12b、共识节点12c和共识节点12d等核心节点)上所存储的区块链均为区块链12e,这里的区块链12e可以为第三链,且第三链所对应的共识网络(即共识网络300a)可以为第三链网络,该第三链网络中的共识节点可以统称为第三共识节点。
应理解的是,为了应对一些特殊场景下(如,一些需要实时处理较大数据量的临时业务等场景),本申请实施在前述区块链系统所涉及的三链体系(即由第一链、第二链和第三链 构建的三链体系)下,可以临时创建以前述临时任务为维度的一个或者多个子链共识网络,并可以将这些构建得到的子链共识网络所对应的区块链称之为业务子链。
其中,可以理解的是,子链共识网络中的子链共识节点可以来自于第二链网络中的第二共识节点以及第三链网络中的第三共识节点。也就是说,目标业务所对应的子链共识网络是管理共识节点根据从第二链网络中所票选出的共识节点(如上述图1中的共识节点11a、共识节点11b)以及从第三链网络中所票选出的共识节点(如上述图1中的共识节点12a、共识节点12b)共同构建的。
其中,应理解的是,一个业务子链对应一个临时业务,比如,以区块链系统为区块链电子票据系统为例,在区块链电子票据系统中,业务子链对应的临时业务为验证100张票据所使用的票据模板是否为最新票据模板,此时,该业务子链中的子链共识节点可以验证这100张票据所使用的票据模板是否为最新票据模板,然后返回验证结果。又比如,在区块链电子票据系统中,业务子链对应的临时业务为校验电子票据中的计税规则是否正确,该业务子链中的子链共识节点可以根据资产映射关系从而验证票据中的计税否正确,并返回验证结果。为便于理解,本申请实施例可以将前述临时业务统称为目标业务。应当理解的是,本申请实施例中对业务子链的数量不作限定,例如,可以根据临时业务形态创建2个业务子链、5个业务子链、40个业务子链等,且业务子链可以根据业务需求进行关闭。
可以理解的是,在前述三链体系下的第二链和第三链可以称为业务主链,业务主链和业务子链相互独立,且上述第一链可以通过相应的跨链中继与业务主链、业务子链进行数据交互。跨链中继可以是一个独立的服务设备,能够对业务主链或者业务子链上的数据进行探测。
应当理解,本申请实施例所涉及的区块链是一种分布式数据存储、点对点传输、共识机制以及加密算法等计算机技术的新型应用模式,主要用于对数据按时间顺序进行整理,并加密成账本,使其不可以被篡改和伪造,同时可以进行数据的验证、存储和更新。区块链本质上是一个去中心化的数据库,该数据库中的每个节点均存储一条相同的区块链。
在上述区块链系统中,核心节点可以负责对应区块链所在的核心共识网络中的共识,也就是说核心节点可以为对应区块链所在核心共识网络中的共识节点。对于上述三个核心共识网络中的任意一个核心共识网络而言,将核心共识网络中的交易数据写入对应区块链账本(例如,分布式数据库)的具体过程可以为,用户客户端发送交易数据至某个业务节点,随后该交易数据以接力棒的方式在上述区块链网络内的业务网络中的业务节点之间传递,直到上述区块链网络内的相应核心共识网络中的共识节点(例如,共识网络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协议,其中,该点对点协议是一个运行在传输控制协议(TCP,Transmission Control Protocol)协议之上的应用层协议,区块链节点之间不需要一个中心节点来维护网络状态,而是每个区块链节点通过和相邻区块链节点的广播交互来维护全网的节点状态或者是其相邻的区块链节点连接状态。在分布式系统中,任何设备如服务器、终端等都可以加入而成为区块链节点,其中,每个区块链节点均可以包括硬件层、中间层、操作系统层和应用层。
其中,应当理解是,上述多业务协作处理平台的具体应用场景可以是区块链电子票据平台下的电子票据流转场景、区块链医学处方流转场景等等。其中,在区块链电子票据平台下的电子票据流转场景下,上述第一链可以为区块链电子票据平台中的管理链,第二链可以为区块链电子票据平台中的票据链以及第三链可以为区块链电子票据平台中的应用合约链;在上述区块链系统应用于区块链电子票据平台中时,可以基于上述第一链、第二链和第三链构建得到一个安全可靠的区块链电子票据三链网络,在该区块链电子票据三链网络中,当在上述三个共识网络中独立执行业务的情况,可以将独立执行业务所得到的业务执行结果分别存入对应的区块链的区块链账本。又例如,在区块链医学处方流转场景,上述第一链可以为区块链医学处方平台中的管理链、第二链可以为区块链电子医学处方平台中的处方链以及第三链可以为区块链医学处方平台中的处方应用合约链。在上述区块链系统应用于区块链医学处方平台中时,可以基于上述第一链、第二链和第三链构建得到一个安全可靠的区块链电子医学处方三链网络,在区块链电子医学处方三链网络中,当在上述三个共识网络中独立执行业务的情况,可以将独立执行业务所得到的业务执行结果分别存入对应的区块链的区块链账本。
为便于理解,接下来以区块链电子票据平台下的电子票据流转场景阐述,请参见图2,图2是本申请实施例提供的一种基于多区块链的区块链电子票据平台的场景示意图。该区块链电子票据平台可以为上述区块链系统中的具体业务平台,应当理解,在该区块链电子票据平台中,为降低在链上数据存储的混杂度,提出了一种基于区块链电子票据的多链体系,且该多链体系主要涉及图2所示的区块链电子票据三链网络。如图2所示,该区块链电子票据三链网络中部署有管理链、票据链和应用合约链。其中,这里的管理链可以为上述第一链,管理链所对应的管理链网络为上述第一链网络,这里的票据链可以为上述第二链,票据链所对应的票据链网络为上述第二链网络且这里的应用合约链可以为上述第三链,应用合约链所对应的应用合约链网络为上述第三链网络。
其中,可以理解的是,在以区块链作为区块链电子票据流转的业务场景中,可以通过管理链、票据链和应用合约链之间的相互协作,为整个区块链电子票据平台提供独立执行不同业务的功能特性,从而可以在三链相互协作的前提下,构造一个安全且高效的业务流系统。应当理解,这里以多链系统为三链体系为例,在该三链系统下,管理链、票据链和应用合约链均是独立搭建的,即用于维护该管理链的共识节点不同于用于维护该票据链的共识节点,且不同于用于维护该应用合约链的共识节点。这里的管理链可以用于为整个区块链电子票据平台提供管理功能特性,这里的票据链可以为整个区块链电子票据平台提供不同业务权限类型的票据业务的功能特性。可以理解的是,部署在票据链网络中的共识节点可以通过票据链维护电子票据在全生命周期内的业务逻辑,比如,可以通过该票据链管理所有开具的电子票据的全生命周期。比如,这里的电子票据的全生命周期包括电子票据的开具、电子票据的流转和电子票据的报销等。应当理解,在整体业务所对应的区块链网络中,由共识节点所维护的票据链具有高性能、低延迟的特点。
应当理解,在本申请实施例中,为确保写入票据链中的电子票据的安全性和独立性,本申请实施例提出可以通过独立于管理链和票据链的另一区块链(即图2所示的应用合约链)来提供更加规范、灵活和功能完备的衍生业务,即这里的应用合约链则可以为整个区块链电子票据平台提供的电子票据来开展衍生业务的功能特性。可以理解的是,该部署在应用合约链网络中的共识节点可以通过应用合约链承载可以变化的票据业务所对应的衍生业务,比如,这里的衍生业务可以具体包括上述征信业务、上述资质识别业务等。应当理解,在整体业务所对应的区块链网络中,由该第二共识节点所维护的应用合约链,可以支持图2所示的政务协作部门和联盟链伙伴(即图2所示的业务关联部门),通过图2所示的税务应用合约(开放合约部署合约)跨链获取管理上的应用合约模板来开发与衍生业务相关的智能合约(例如,图2所示的衍生业务合约),并可以经过税务管理部门审核后将该衍生业务合约部署在应用合约链上。应当理解,部署在应用合约链上的智能合约可以通过虚拟机兼容合约实现智能合约的灵活升级和变化,应当理解,应用合约链相较于管理链和票据链而言,具有最高的开放度,且支持复杂的智能合约逻辑,参与方较多且不断动态变化,性能相对低于票据链。
如图2所示,部署在区块链电子票据三链网络中的管理链独立于票据链和应用合约链,即这三条独立搭建的区块链之间是彼此相互独立的,但是这三条独立搭建的区块链之间可以通过跨链中继的方式进行数据交互,即这三链之间可以进行跨链交互。
其中,应当理解的是,管理链所采用的共识算法,不同于票据链所采用的共识算法,也不同于应用合约链所采用的共识算法。
具体的,1.1)与管理链相关联的共识算法为一种即时确定性共识算法,比如,这里的即时确定性共识算法可以为PBFT(Practical Byzantine Fault Tolerance,实用拜占庭容错)共识算法,通过该PBFT共识算法可以立即确定某个待上链的提议区块的状态。应当理解,该管理链为上述管理链网络中的区块链,在该管理链网络中的管理共识节点(即上述第一共识节点)可以由图2所示的税务管理部门参与进行管理。
可以理解的是,前述税务管理部门可以通过该部署在管理链网络中的管理共识节点行使管理职责。比如,这里的管理职责具体可以包括对政务部门内部的信息(比如,税务管理部门内部人员的信息)进行管理、对整体业务的业务逻辑规则(例如,应用合约链上所运行的用于执行衍生业务的业务逻辑的衍生业务合约)进行管理、对整体业务的元数据信息(例如,三链体系下的各链入口处的访问流量)进行管理、对整体业务的参与者(比如,个人用户、企业用户、税务业务参与方等业务对象)进行身份管理和权限管理等。应当理解,在整体业务所对应的区块链网络中,由该管理共识节点所维护的管理链是相对更稳定、数据规模最小、但安全性最高的区块链。
应当理解,与该管理链相关联的内部参与方可以为图2所示的税务管理部门,比如,该税务管理部门在作为内部参与方参接入该管理链时,可以通过管理链上的内部管理合约对该税务管理部门的一些内部状态进行管理,比如,可以对该税务管理部门中的各人员进行管理,比如,可以在税务管理部门的这些人员中配置特定的税务管理人员、税务开发人员、税务审计人员等。此外,该税务管理部门在作为内部参与方参接入该管理链时,还可以通过管理链上的内部管理合约对该三链体系中的一些参数进行管理;比如,该税务管理部门在作为内部参与方参接入该管理链时,还可以通过管理链上的内部管理合约对参与共识的各链上的共识节点的数量所对应的节点数量参数进行限定。
1.2)与票据链相关联的共识算法为另一种即时确定性共识算法,比如,这里的即时确定性共识算法可以为TBFT(Tower Byzantine Fault Tolerance,塔式拜占庭容错)共识算法,该TBFT共识算法是一种拜占庭容错算法,可以在拜占庭节点数(即票据链网络中的作恶节点数)小于票据链网络的节点总数1/3的情况下,保证整个票据链网络系统的安全运行。通过该TBFT共识算法可以立即确定某个待上链的提议区块的状态,性能更高、区块链节点数量更少、区块链节点可以连续产生区块。应当理解,处于票据链网络中的共识节点可以由前述税务管理部门参与进行管理,比如,税务管理部门中的特定税务人员可以通过上述管理链中的内部管理合约控制该票据链网络中的共识节点的数量。又比如,税务管理部门中的特定税务人员所对应的税局终端可以参与构成该票据链网络。
应当理解,上述TBFT共识算法与PBFT共识算法的最大区别在于:PBFT共识算法有一个固定的leader节点(即主节点)用于打包交易池中的交易,当leader节点故障的时候会使用view-change子协议(即一种主节点切换子协议)更换leader节点;而在TBFT共识算法中,leader节点是基于轮换机制而轮换的,比如,在当前节点被作为leader节点时,每提交X个区块(X的值可以配置),则会自动将该leader节点轮换成下一个节点。这意味着在该票据链对应的票据链网络中的共识节点可以用于连续出块。
1.3)与应用合约链相关联的共识算法为又一种即时确定性共识算法,比如,这里的即时确定性共识算法可以为PoS(Proof-of-Stake,权益证明)共识算法,通过该权益证明共识算法可以维护该应用合约链所在应用合约链网络的网络安全性,且通过该权益证明共识算法可以立即确定某个待上链的提议区块的状态。可以理解的是,在该应用合约链网络中的共识节点可以由图2所示的税务管理部门和政务协作部门以及大型参与机构(即前述联盟链中的大型企业,该大型企业即为前述图2所示的业务关联部门)等共同参与进行管理。
应当理解,针对该区块链电子票据三链网络中的智能合约而言,存在以下区别:
2.1)应当理解,如图2所示的管理链上可以支持特定语言智能合约引擎,上述管理共识节点通过该特定语言智能合约引擎可以在管理链上部署特定语言智能合约,比如,可以在管理链上部署上述图2所示的对象权限管理合约、对象身份管理合约、元数据管理合约和内部管理合约以及全平台配置合约。应当理解,这些智能合约可以由税务管理部门中的特定税务管理人员开发和管理。其中,调用对象权限管理合约可以对管理对象的管理权限以及业务对象的业务接入权限进行管理;调用对象身份管理合约可以对管理对象的身份信息或者业务 对象的身份信息进行管理;调用元数据管理合约可以管理区块链上的元数据;调用全平台配置合约可以对跨链配置进行管理。
2.2)如图2所示的票据链上内置有特定票据业务逻辑的智能合约,这些智能合约(例如,上述图2所示的电子票据开具合约、电子票据流转合约、电子票据红冲合约、电子票据归档合约)可以随着票据业务的更新而进行升级。比如,本申请实施例可以通过从管理链上所读取到的元数据信息更新电子票据开具合约中的票据业务逻辑,进而可以根据更新后的电子票据开具合约来更新处理上述票据业务。这意味着该票据链不支持独立的智能合约引擎,自然也就不支持在该票据链上部署与票据业务无关的其他合约。这样做的好处是让该票据链仅运行与电子票据相关的业务逻辑,且不受其他智能合约的影响,从而可以使该票据链的运行更加独立稳定,更抗攻击。
2.3)该应用合约链上支持多语言、图灵完备面向开发者的智能合约,比如,如图2所示,开发者在通过应用合约链入口接入该应用合约链时,可以通过虚拟机兼容合约兼容主流的EVM虚拟机,以便于可以在兼容的虚拟机上部署运行各种新的业务合约,比如,可以在应用合约链上部署与衍生业务(例如,上述抽奖业务)相关联的衍生业务合约。又比如,可以在应用合约链上部署与另一衍生业务(例如,上述退税业务)相关联的衍生应用合约。
应当理解,如图2所示,在区块链电子票据三链网络中,与管理链相关联的公开网络参与方可以为图2所示的个人用户和企业用户。同理,如图2所示,与票据链相关联的公开网络参与方可以为图2所示的各地电子票据流系统。这里的各地电子票据流系统具体包括各地方电子票据业务开具系统(例如,各地方税局系统),电子票据开票服务商,大型企业财税相关系统等。同理,如图2所示,与应用合约链相关联的公开网络参与方可以为图2所示的税务业务参与方和开发者。
具体的,3.1)与管理链相关联的链入口可以为图2所示的管理链入口。当图2所示的个人用户(例如,用户A)和企业用户(例如,企业B)等作为公开网络参与方时,可以通过该管理链入口接入管理链,进而可以通过该管理链进行身份注册和身份授权等业务。3.2)与票据链相关联的链入口可以为图2所示的票据链入口。当图2所示的各地方电子票据流系统(例如,大型企业用户)等作为公开网络参与方时,可以通过该票据链入口接入票据链,进而可以通过该票据链执行电子票据开具业务、电子票据流转业务、电子票据红冲业务和电子票据归档业务。3.3)与应用合约链相关联的链入口可以为图2所示的应用合约链入口。当图2所示的税务业务参与方和开发者等作为公开网络参与方时,可以通过该应用合约链入口接入应用合约链,进而可以通过在应用合约链上部署衍生业务合约,以通过部署的衍生业务合约执行与电子票据相关的衍生业务。
其中,可以理解的是,图2所示的管理链入口具体可以为税务管理部门入口,通过该税务管理部门入口可以对需要接入管理链的个人、法人以及实体等进行身份识别和业务引导。
其中,可以理解的是,图2所示的票据链入口具体可以为电子票据业务入口,通过该电子票据业务入口可以接收某个业务对象(如企业B)所请求开具的电子票据的交易业务数据(也可以称之为交易数据)。这样,在上述票据共识节点通过该电子票据业务入口接收到该交易数据时,并对交易数据发送方(即前述企业B)的接入身份和接入权限是否满足管理链中身份权限合约状态要求,进而可以在校验通过时,可以根据交易数据开具相应的电子票据。
其中,可以理解的是,图2所示的应用合约链入口具体可以为税务衍生业务入口,通过该税务衍生业务入口可以接收某个业务对象(例如图2所示的税务业务参与方)所请求参与的与票据业务相关联的衍生业务。应当理解,在图2所示的税务业务参与方和开发者可以在获得税务管理部门发放的授权对象的业务参与许可凭证后,可以通过该应用合约链入口对该业务对象(例如,税务业务参与方或者开发者)提交的业务参与许可凭证进行验证,进而可 以在验证成功时允许该业务对象接入该应用合约链,以在该应用合约链上执行与前述票据业务相关联的衍生业务。
其中,如图2所示,参与维护管理链的内部参与方可以为图2所示的税务管理部门,这里的税务管理部门主要用于在管理链上进行内部状态参数的配置与管理,还可以用于对上述元数据信息(例如,税务元数据)进行变更上链(如可以更新电子票据模板,更新计税规则等),以及可以对于该管理链上所维护的各类业务参与方的身份和权限进行管理(如冻结企业开票资质,限制企业开票额度等)。
其中,如图2所示,参与维护票据链的内部参与方可以为图2所示的电子票据数据中心,这里的电子票据数据中心具体可以为电子发票数据中心,该电子票据数据中心(比如,电子发票数据中心)可以用于对票据链上所记录的海量的账本数据进行链下备份、统计、数据分析和审查等工作。
其中,如图2所示,参与维护应用合约链的内部参与方可以为图2所示的政务协作部门和业务关联部门。应当理解,参与维护应用合约链的内部参与方除了税务管理部门之外,系统联盟链中的其他部门(即前述政务协作部门)和参与方(即前述业务关联部门)均可以在接入该应用合约链的情况下,进一步通过该应用合约链上的衍生业务合约执行相应的衍生业务。可以理解的是,图2所示的政务协作部门和业务关联部门等作为税务业务参与方,接入应用合约链的好处是可以在支持完备的智能合约声明周期中灵活运行各类可以扩展的衍生业务,以确保业务变化的灵活性。
其中,可以理解的是,在图2所示的区块链电子票据三链网络中,均可以内置相应的智能合约。
其中,4.1)对于管理链上内置的智能合约而言,如图2所示,内置在管理链上的对象身份管理合约具体可以为用户管理合约,通过该用户管理合约可以管理整个三链体系下的接入者(比如,公开网络参与方)和参与者(比如,内部参与方)的身份。应当理解,这里的接入者和参与者具体可以包括税务管理人员、政务协作部门、地方税局、开票服务商、报销服务商、税务审查部门等。其中,4.2)对于票据链上内置的智能合约而言,如图2所示,内置在票据链上的智能合约可以包括票据链配置合约和与电子票据生命周期相关联的票据业务合约。这里的票据业务合约具体可以包括图2所示的用于提供电子票据开票业务的电子票据开具合约,用于提供电子票据流转业务的电子票据流转合约、用于提供电子票据红冲业务的电子票据红冲合约以及用于提供电子票据归档业务的电子票据归档合约。上述票据链配置合约用于记录本链上的配置项。
其中,4.3)对于应用合约链上内置的智能合约而言,如图2所示,内置在票据链上的智能合约可以包括应用链配置合约,还可以包括由税务衍生业务参与方(即衍生业务对象,例如,图2所示的税务业务参与方)参与部署的各类合约(例如,图2所示的虚拟机兼容合约、税务应用合约和衍生业务合约等)。比如,这里的衍生业务合约具体可以为基于电子票据的征信业务合约,通过该征信业务合约可以分析得到某个企业的征信数据。又比如,这里的衍生业务合约具体还可以是为鼓励开票所部署的链上抽奖业务合约和人才激励合约以及退税业务合约等。上述应用合约链配置合约用于记录本链上的配置项。
应当理解,对于上述图2所示的管理链而言,主要用于处理数据量较小、状态较恒定的管理性业务流,整个管理链的开放性相对较低,可以用于对一些税务数据进行内部管理。而对于上述图2所示的票据链而言,可以用于处理一些数据量长期处于高频请求状态的实时票据业务流,该整个票据链的开放性相对较高,可以允许与电子票据本身生命周期中的相关权威机构参与相应的票据业务,比如,可以允许与代理服务商对应的共识节点为当前请求开票的某个用户开具电子票据。此外,对于图2所示的应用合约链而言,数据量的大小可以无需限定、业务变化的频率波动相对较大,主要是可以通过该应用合约链处理各类合作业务、衍 生业务、探索性业务等。应当理解,该应用合约链具有最高的开放性,可以运行由管理链授权的参与者在该应用合约链上部署智能合约、运行探索性的衍生业务等。
示例性地,本申请实施例提供了一种基于多区块链的跨链处理方法,该方法由多区块链系统中的管理链共识节点执行,多区块链包括所述管理链和至少一个其他区块链,管理链共识节点位于管理链上,该方法包括:
管理链共识节点获取多区块链。管理链共识节点在多区块链中确定待进行跨链处理的至少两个区块链;管理链共识节点基于至少两个区块链的链信息,对至少两个区块链进行跨链处理。跨链处理是指通过跨链的方式处理多区块链。
跨链处理包括跨链配置、跨链数据传输和数据处理中的至少一种。
跨链配置用于表示将一个区块链的配置项配置至其他的区块链。
跨链数据传输用于表示将数据在不同的区块链之间进行转移。
数据处理是指通过复用至少两个区块链中的共识节点来处理临时业务。
在一些实施例中,管理链共识节点基于管理链将跨链配置项配置至至少一个其他区块链;或,管理链共识节点基于管理链将目标交易资源传输至至少一个其他区块链;或,管理链共识节点基于管理链复用至少一个其他区块链中的共识节点来处理临时业务。
在一些实施例中,基于管理链,将跨链配置项配置值从管理链跨链配置至所述至少一个其它区块链,至少一个其它区块链包括:票据链、合约链、业务子链中的至少一个。
在一些实施例中,基于管理链,将目标交易资源从源区块链传输至目标区块链,源区块链包括合约链、票据链、业务子链中的至少一个,目标区块链包括所述管理链。
在一些实施例中,基于管理链,复用至少一个其他区块链中的共识节点共同组建临时业务对应的业务子网络,至少一个其他区块链包括票据链、合约链中的至少一个,业务子网络用于处理临时业务。
接下来就基于多区块链的跨链处理方法进行具体描述。
基于多区块链的跨链配置。
请参见图3,本申请实施例提供一种针对其他区块链进行跨链配置的示意图。如图3所示,区块链系统中可以包括管理链、票据链、合约链、业务子链1和业务子链2。应理解的是,可以将待配置的票据链、待配置的合约链、待配置的业务子链1、待配置的业务子链2称为其他区块链,而与其他区块链相关链的共识节点可以称为其他共识节点,此外,票据链和合约链也可以称为业务主链;本申请实施例中可以采用跨链中继可以起到隔离管理链所对应的管理链网络以及其他区块链对应的其他区块链网络。应理解的是,本申请实施例中的业务子链数量不作限定。
为便于理解,这里以管理链所在的核心共识网络(即上述管理链网络)为上述图1所示的共识网络100a为例,此时,参与维护该管理链的共识节点可以为上述管理链共识节点。如图3所示,前述管理链上部署有针对跨链配置的多个智能合约,这些智能合约可以运行在管理链共识节点上。管理链中部署有全平台配置合约,调用该全平台配置合约可以实现对业务主链和业务子链的基础配置。该全平台配置合约可以实现全局配置以及对业务主链或者业务子链进行单独配置。全平台配置合约包括链管理配置合约,链管理配置合约包括用于全局配置的平台配置合约以及用于单独对某个链进行配置的其他区块链管理配置合约。其中,其他区块链管理配置合约可以包括票据链的链管理配置合约、合约链的链管理配置合约或者业务子链的子链管理配置合约。
其中,可以理解的是,当调用上述平台配置合约时可以对业务主链(即票据链和合约链)和业务子链均进行全局配置。应理解的是,调用平台配置合约可以对票据链、合约链、业务子链1和业务子链2中的元数据、基础信息(如某些链的链名称、管理某些链的管理对象、产生区块的时间等)等进行跨链配置。比如,以管理链为区块链电子票据平台中的管理 链为例,调用平台配置合约可以对一些税务元数据(如计税规则变更等)、基础信息(如应用合约链的链名称、票据链的链名称、管理某些链的管理对象、产生区块的时间等)等进行跨链配置。
其中,应理解的是,当分别调用票据链的链管理配置合约、合约链的链管理配置合约、业务子链的子链管理配置合约时,则是分别对管理链进行单独配置、对票据链进行单独配置、对业务子链进行单独配置。此时单独配置可以包括产生区块大小、链上的一些业务规则。例如,以管理链为区块链电子票据平台中的管理链,其他区块链为票据链为例,调用票据链的链管理配置合约可以对票据链上的开票进行升级、对票据链上发票流转更改等等。又例如,以管理链为区块链医疗处方平台中的管理链,其他区块链为处方链为例,调用处方链的链管理配置合约可以对处方链上的处方模板进行配置、对处方链上处方流转更改等。
为便于理解,这里以票据链所在的核心共识网络(即上述票据链网络)为上述图1所示的共识网络200a为例,票据链上部署有链配置合约,票据链上的链配置合约可以运行在参与维护票据链的第二共识节点上。票据链的链配置合约中记录本链的配置项(如产生块的大小、票据模板等等)。
同理,为便于理解,这里以合约链所在的核心共识网络(即上述合约链网络)为上述图1所示的共识网络300a为例,在该合约链上部署有链配置合约,合约链上的链配置合约具体可以运行在参与维护该合约链的共识节点上。应当理解的是,合约链的链配置合约中记录本链的配置项(如产生块的大小、票据模板等等)。其中,还可以理解的是,在图3中,业务子链1和业务子链2上同样可以部署有子链配置合约,业务子链的子链配置合约具体可以运行在参与维护相应业务子链的子链共识节点上。
其中,可以理解是,在图3中,上述票据链的链配置合约、合约链的的链配置合约、业务子链1中的子链配置合约、业务子链2中的子链配置合约均包括阻塞式链配置锁和非阻塞式链配置锁两种合约锁。以待跨链配置的区块链为其他区块链为例,其他区块链可以为票据链、合约链、业务子链中的一种或多种;当获取到阻塞式链配置锁时,通过该阻塞式链配置锁可以对其他区块链进行业务锁定,其他区块链无法进行正常业务,直到通过阻塞式链配置锁对其他区块链进行解锁后,其他区块链才进行正常业务。而当获取到非阻塞式链配置锁的同时,提供一个块缓冲高度(如N),在将其他区块链的业务状态配置为第二业务锁定状态之前,其他区块链上可以仍然可以产生N个区块,当产生了N个区块之后,该其他区块链则停止正常业务,无法产生新的区块,直到通过非阻塞式链配置锁对其他区块链进行解锁后,其他区块链才进行正常业务。
比如,管理对象可以基于配置事务向管理链中的管理链共识节点发送用于对其他区块链进行跨链配置的配置交易,管理链共识节点确定配置事务的事务类型,并在事务类型为阻塞式事务类型时,管理链共识节点可以基于上述链管理配置合约生成配置交易对应的第一配置事务标识,跨链中继在探测到管理链上的第一配置事务标识时,可以向其他区块链相关联的其他共识节点发送第一锁获取交易。然后,其他区块链可以根据第一锁获取交易从其他区块链上的链配置合约中获取上述配置事务的阻塞式事务类型对应的阻塞式链配置锁,其他共识节点可以通过上述阻塞式链配置锁将其他区块链的业务状态配置为第一业务锁定状态,此时其他区块链上停止正常业务。
其中,应理解的是,本申请实施例所涉及到的配置事务是指对其他区块链进行跨链配置,该配置事务中可以包括以下至少一种:待跨链配置的其他区块链的链标识、对其他区块链进行配置的跨链配置项。比如,在区块链电子票据平台中,其他区块链为票据链,上述管理对象可以是管理票据链的管理员,上述配置事务可以包括票据链的链标识、对票据链中的发票模板进行更新、对计税规则进行配置等等。又比如,在区块链电子票据平台中,其他区块链为应用合约链,上述管理对象可以是管理应用合约链的政务协作部门、业务关联部门等等,上述配置事务可以包括应用合约链的链标识、对应用合约链中的应用开发规则更新等 等。
进一步地,可以理解的是,当探测到其他区块链处于第一业务锁定状态时,跨链中继可以向管理链共识节点发送的第一锁定声明交易,使得管理链上的管理链共识节点在基于第一锁定声明交易确定第一配置事务标识所对应的配置事务的状态为第一事务锁定状态时,生成第一锁定声明交易对应的第一事务锁定信息,并将第一事务锁定信息生成区块,并在管理链网络中的其他共识节点对区块共识之后写入管理链,然后管理对象基于管理链上的第一事务锁定信息发送配置修改交易,管理链中的管理链共识节点可以获取配置修改交易中的第一跨链配置项,并通过跨链中继将第一跨链配置项跨链配置至其他区块链,从而其他共识节点通过阻塞式链配置锁解锁处于第一业务锁定状态的其他区块链。
应当理解的是,在事务类型为非阻塞式事务类型时,管理链共识节点可以基于上述链管理配置合约生成配置交易对应的第二配置事务标识,跨链中继在探测到管理链上的第二配置事务标识时,可以向其他区块链相关联的其他共识节点发送第二锁获取交易,其他区块链根据第二锁获取交易从其他区块链上的链配置合约中获取上述非阻塞式事务类型对应的非阻塞式链配置锁以及块缓冲高度,当其他区块链上所生成的区块的间隔高度达到块缓冲高度时,其他共识节点可以通过该非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态,此时其他区块链上停止正常业务。
进一步地,可以理解的是,当探测到其他区块链处于第二业务锁定状态时,跨链中继向第二共识节点发送的第二锁定声明交易,使得管理链上的管理链共识节点在基于第二锁定声明交易确定第二配置事务标识所对应的配置事务的状态为第二事务锁定状态时,生成第二锁定声明交易对应的第二事务锁定信息,并将第二事务锁定信息生成区块,并在对区块共识之后写入所票据链,然后管理对象基于管理链上的第二事务锁定信息发送配置修改交易,管理链中的管理链共识节点可以获取配置修改交易中的第二跨链配置项,通过跨链中继将第二跨链配置项跨链配置至其他区块链,从而其他共识节点通过非阻塞式链配置锁解锁处于第二业务锁定状态的其他区块链。
其中,可以理解的是,本申请实施例所涉及的共识节点可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network,CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。
需要说明的是,当管理对象对其他区块链进行跨链配置时,在获取管理对象的管理许可凭证等数据时,可以显示提示界面或者弹窗,该提示界面或者弹窗用于提示管理对象当前正在搜集管理许可凭证,仅仅在获取到管理对象对该提示界面或者弹窗发出确认操作后,开始执行数据获取的相关的步骤,否则结束。
此外,可以理解的是,在本申请的具体实施方式中,可能涉及到用户、企业、机构等管理对象的身份信息,当本申请以上实施例运用到具体产品或技术中时,需要获得用户、企业、机构等业务对象的许可或同意,且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
其中,在管理链上对其他区块链进行跨链配置的具体过程,可以参见如下图4至图9所对应的实施例。
进一步的,请参见图4,图4是本申请实施例提供的一种基于多区块链的跨链配置方法,方法可以由与上述管理链相关联的管理链共识节点执行,比如,该管理链共识节点可以为上述图1所示的共识网络100a中任意一个共识节点。该方法具体可以包括以下步骤。
步骤S401、在接收到配置交易时,确定配置事务的事务类型,配置交易用于跨链配置其他区块链,配置交易是管理对象基于配置事务发送的。
其中,本申请实施例所涉及的管理对象可以是其他区块链的管理用户(如其他区块链为 上述区块链电子票据平台中的应用合约链,管理对象可以为政务协作部门、业务关联部门等),配置事务中包括其他区块链的链标识。可以理解的是,上述多区块链可以包括管理链、由管理链共识节点通过管理链所管理的业务主链和独立于业务主链的业务子链,上述业务主链包括独立于管理链的票据链和合约链中的一个或多个。
应理解的是,上述票据链对应的的票据链网络独立于合约链所对应的合约链网络。管理链所对应的管理链网络与其他区块链所对应的其他区块链网络可以通过跨链中继进行隔离,即管理链网络和其他区块链网络通过跨链中继进行数据交互。比如,在上述区块链电子票据平台中,当其他区块链为票据链时,管理链网络与票据链所对应的票据链网络可以通过跨链中继进行隔离,管理链网络与票据链网络通过跨链中继进行数据交互;又例如,当其他区块链为合约链时,管理链网络与合约链所对应的合约链网络可以通过跨链中继进行隔离,管理链网络与合约链网络通过跨链中继进行数据交互。再例如,当其他区块链为业务子链时,管理链网络与业务子链所对应的子链共识网络可以通过跨链中继进行隔离,管理链网络与子链共识网络通过跨链中继进行数据交互。
其中,业务子链所对应的子链共识网络是由票据链对应的票据链网络中的共识节点和合约链对应的合约链网络中的共识节点所共同组建的;业务子链是由请求执行目标业务的业务对象通过管理链共识节点所授权创建的;一个目标业务对应一个业务子链。也就是说,在出现临时业务(即目标业务)时,业务对象(如企业A、个人用户等)可以在管理链所对应的管理链网络中请求执行目标业务,在管理链网络中的管理链共识节点对业务对象进行授权验证通过后,可以根据从票据链网络中的共识节点中所票选的共识节点以及从合约链网络中的共识节点所票选的共识节点共同创建用于处理目标业务的子链共识网络。此时,在该子链共识网络中的共识节点也可以称为验证节点。
比如,在区块链电子票据平台中,目标业务为验证100张发票的格式是否正确;此时,业务对象可以向管理链网络中的管理链共识节点请求执行目标业务,管理链共识节点可以对业务对象进行授权验证,并在授权验证之后,通过票据链网络中的票据共识节点所票选的共识节点以及通过应用合约链网络中的共识节点所票选的共识节点组建用于验证100张发票的格式的子链共识网络。在该子链共识网络中的共识节点可以验证100张发票的格式是否正确并向业务对象返回最终的执行结果。
可以理解的是,其他区块链的数量可以是一个或多个,本申请实施例对此不作限定。当其他区块链的数量为一个时,其他区块链可以是业务子链或者业务主链,例如,上述区块链电子票据平台可以包括管理链、业务主链包括票据链、应用合约链、业务子链1和业务子链2。其他区块链可以为票据链、应用合约链或者业务子链。当其他区块链的数量为多个时,多个其他区块链可以包括业务子链和业务主链,例如,上述区块链电子票据平台中可以包括业务主链(即包括独立于管理链的票据链和应用合约链)以及独立于业务主链的2个业务子链(即业务子链1和业务子链2),多个其他区块链则可以包括上述票据链、应用合约链和业务子链1;或者多个其他区块链可以包括上述票据链和业务子链2。
其中,可以理解的是,业务对象在想要对某个区块链(即其他区块链)进行跨链配置时,可以基于配置事务向管理链网络中的管理链共识节点发送用于跨链配置其他区块链的配置交易,管理链共识节点在接收到管理对象基于配置事务发送的用于跨链配置其他区块链的配置交易时,可以获取管理对象的管理许可凭证,并对管理对象的管理许可凭证进行验证,若验证通过则确定该配置事务的事务类型。可以理解的是,上述配置事务中还可以指明配置事务的事务类型,管理链共识节点可以直接确定配置交易中的配置事务的事务类型。
其中,本申请实施例中所涉及的事务类型可以分为阻塞式事务类型和非阻塞式事务类型。根据阻塞式事务类型和非阻塞式事务类型的不同可以生成配置交易对应的不同配置事务标识。当上述事务类型为阻塞式事务类型时,可以执行步骤S402生成第一配置事务标识。
步骤S402、在配置事务的事务类型为阻塞式事务类型时,调用管理链上的链管理配置 合约执行配置交易,生成配置交易对应的第一配置事务标识;第一配置事务标识用于指示跨链中继向与其他共识节点发送第一配置锁获取交易;第一配置锁获取交易用于指示其他共识节点从其他区块链上的链配置合约中获取阻塞式事务类型对应的阻塞式链配置锁,且通过阻塞式链配置锁将其他区块链的业务状态配置为第一业务锁定状态。
其中,可以理解是,第一配置事务标识用于表征上述配置事务的事务标识,第一配置事务标识可以是数字、字符、或者数据和字符所构成的字符串。例如,针对配置事务x,调用管理链上的链管理配置合约执行配置事务x对应的配置交易,可以生成配置事务x对应的配置事务标识ID-x。
在配置事务的事务类型为阻塞式事务类型时,管理链共识节点可以调用管理链上的链管理配置合约执行配置交易,生成配置交易对应的第一配置事务标识可以包括以下两种方式:
(1)当其他区块链的数量为多个时,上述配置事务则是针对多个其他区块链进行跨链配置,此时,上述配置事务所指示的配置资源属于全局配置资源,而与全局配置资源对应的链管理配置合约为管理链上的平台配置合约。其中,应当理解的是,全局配置资源为所有区块链配置的资源,全局配置资源可以包括跨链配置项。全局配置资源中的跨链配置项均会被配置到多个其他区块链上,例如,跨链配置项可以为对多个其他区块链上的链名称进行修改、对多个其他区块链上的出块时间进行修改。
应理解的是,在平台配置合约中包括阻塞式事务配置方法和非阻塞式事务配置方法两种配置方法,通过上述事务类型可以确定进行跨链配置时管理链共识节点所要调用的配置方法。当配置事务的事务类型为阻塞式事务类型时,管理链共识节点将配置交易写入平台配置合约,然后根据阻塞式事务类型确定需要执行的配置方法为平台配置合约中的阻塞式事务配置方法,并调用该阻塞式事务配置方法执行该配置交易,得到配置交易所指示的多个其他区块链的链标识,接着可以基于多个其他区块链的链标识,生成配置交易对应的第一配置事务标识。
(2)其他区块链可以为票据链、合约链或者业务子链。票据链和合约链由管理链共识节点可以通过管理链上的全平台配置合约所管理,该全平台配置合约中包括链管理配置合约。在配置事务所指示的配置资源属于独立配置资源时,与独立配置资源对应的链管理配置合约为管理链上的其他区块链管理配置合约;该其他区块链管理配置合约可以包括用于配置票据链的链管理配置合约、用于配置合约链的链管理配置合约或者用于配置业务子链的子链管理配置合约。此处的独立配置资源是指为某个区块链单独配置的资源,如对其他区块链单独配置区块的大小、对其他区块链上的业务进行升级等等。
应理解的是,当其他区块链为票据链时,其他区块链管理配置合约包括用于配置票据链的链管理配置合约,在配置事务的事务类型为阻塞式事务类型时,可以将配置交易写入票据链的链管理配置合约,然后调用票据链的链管理配置合约中的阻塞式事务配置方法执行该配置交易,得到配置交易所指示的票据链的链标识,并基于票据链的链标识,生成配置交易对应的第一配置事务标识。
当其他区块链为合约链时,其他区块链管理配置合约包括用于配置合约链的链管理配置合约,在配置事务的事务类型为阻塞式事务类型时,可以将配置交易写入合约链的链管理配置合约,然后调用合约链的链管理配置合约中的阻塞式事务配置方法执行该配置交易,得到配置交易所指示的合约链的链标识,并基于合约链的链标识,生成配置交易对应的第一配置事务标识。
当其他区块链为业务子链时,其他区块链管理配置合约包括用于配置业务子链的子链管理配置合约,在配置事务的事务类型为阻塞式事务类型时,可以将配置交易写入子链管理配置合约,然后调用该子链管理配置合约中的阻塞式事务配置方法执行该配置交易,得到配置交易所指示的业务子链的链标识,并基于业务子链的链标识,生成配置交易对应的第一配置事务标识。
步骤S403、接收跨链中继发送的第一锁定声明交易;第一锁定声明交易是跨链中继在探测到其他区块链处于第一业务锁定状态时所确定的。
其中,当跨链中继在探测到其他区块链处于第一业务锁定状态时,可以基于该第一业务锁定状态生成第一锁定声明交易,并向跨链中继发送第一锁定声明交易。相应的,管理链共识节点可以接收跨链中继发送的第一锁定声明交易。第一锁定声明交易可以用于声明其他区块链已被成功锁定,该其他区块链上无法在进行正常业务,或者用于声明第一配置事务标识锁定成功,也即让管理链相关联的管理链共识节点确定第一配置事务标识对应的配置事务的状态处于第一事务锁定状态。
步骤S404、在确定第一配置事务标识所对应的配置事务的状态为第一事务锁定状态时,生成第一锁定声明交易对应的第一事务锁定信息,将第一事务锁定信息写入管理链,配置事务的状态是基于第一锁定声明交易确定的。
其中,管理链共识节点可以基于第一锁定声明交易确定第一配置事务标识所对应的配置事务的状态为第一事务锁定状态,并在确定第一配置事务标识所对应的配置事务的状态为第一事务锁定状态时,生成第一锁定声明交易对应的第一事务锁定信息,并将第一事务锁定信息打包成区块,并通过管理链网络中的其他共识节点进行共识,然后在共识通过后将该区块写入管理链。第一事务锁定信息可以用于指示已在其他区块链上将与该配置事务相关联的资源锁定,其他区块链暂时无法进行正常业务。其中,第一跨链配置项中指示需要对其他区块链进行配置的配置资源,如其他区块链为票据链,第一跨链配置项可以指示对票据链更新票据模板资源;又如第一跨链配置项指示对票据链配置区块大小资源。
步骤S405、在获取到配置修改交易时,获取配置修改交易中的第一跨链配置项,通过跨链中继将第一跨链配置项跨链配置至其他区块链,以使其他共识节点通过阻塞式链配置锁解锁处于第一业务锁定状态的其他区块链;配置修改交易是所述管理对象基于管理链上的所述第一事务锁定信息发送的。
管理对象从管理链上获取到第一事务锁定信息,知道当前其他区块链已经锁定成功,可以向管理链上相关联的管理链共识节点发送针对其他区块链的配置修改交易,该配置修改交易中包括第一跨链配置项;管理链共识节点接收上述配置修改交易,并从配置修改交易获取第一跨链配置项,然后通过跨链中继将第一跨链配置项跨链配置至其他区块链。
管理链上的管理链共识节点可以接收用于跨链配置其他区块链的配置交易,并在配置事务的事务类型为阻塞式事务类型时,执行上述配置交易,生成配置交易对应的第一配置事务标识;随后通过该第一配置事务标识可以使其他共识节点获取阻塞式事务类型对应的阻塞式链配置锁,并通过该阻塞式链配置锁对其他区块链的业务状态进行锁定,并在锁定其他区块链的业务状态之后,将管理链上为其他区块链所配置的跨链配置项通过跨链中继配置到其他区块链。由此可见,本申请实施例通过管理链上的管理链共识节点(例如,前述图1中所示的10a)可以对其他链的配置信息进行统一管理,以确保链上配置信息的一致性。同时,在其他区块链的业务状态被锁定时,管理链共识节点可以生成相应的事务锁定信息,写入管理链中,这样也可以有效保障其他区块链的配置的可审查性和可追溯性;另外,引入阻塞式链配置锁这样的配置机制,可以实现配置的同步生效,保证了业务逻辑的严格执行,同时也可以确保彼此相互独立的各区块链上配置信息的一致性和可靠性。
进一步的,请参见图5,图5是本申请实施例提供的一种基于多区块链的跨链配置方法,该方法可以由与上述管理链相关联的管理链共识节点执行,比如,该管理链共识节点可以为上述图1所示的共识网络100a中任意一个共识节点。该方法具体可以包括以下步骤。
步骤S501、在接收到配置交易时,确定配置事务的事务类型,配置交易用于跨链配置其他区块链,配置交易是管理对象基于配置事务发送的。
步骤S502、在配置事务的事务类型为阻塞式事务类型时,调用管理链上的链管理配置 合约执行配置交易,生成配置交易对应的第一配置事务标识;第一配置事务标识用于指示跨链中继向与其他区块链相关联的其他共识节点发送第一配置锁获取交易;第一配置锁获取交易用于指示其他共识节点从其他区块链上的链配置合约中获取阻塞式事务类型对应的阻塞式链配置锁,且通过阻塞式链配置锁将其他区块链的业务状态配置为第一业务锁定状态;
步骤S503、接收跨链中继发送的第一锁定声明交易;第一锁定声明交易是跨链中继在探测到其他区块链处于第一业务锁定状态时所确定的;
步骤S504、在基于第一锁定声明交易确定第一配置事务标识所对应的配置事务的状态为第一事务锁定状态时,生成第一锁定声明交易对应的第一事务锁定信息,将第一事务锁定信息写入管理链;
步骤S505、在获取到配置修改交易时,获取配置修改交易中的第一跨链配置项,通过跨链中继将第一跨链配置项跨链配置至其他区块链,以使其他共识节点通过阻塞式链配置锁解锁处于第一业务锁定状态的其他区块链,配置修改交易是管理对象基于管理链上的第一事务锁定信息发送的。
其中,上述步骤S501-S505的具体实现方式可以参见上述步骤S401-S405的具体实现方式,在此不再赘述。
步骤S506、在配置事务的事务类型为非阻塞式事务类型时,调用管理链上的链管理配置合约执行配置交易,生成配置交易对应的第二配置事务标识;第二配置事务标识用于指示跨链中继向与其他区块链相关联的其他共识节点发送第二配置锁获取交易;第二配置锁获取交易用于指示其他共识节点从其他区块链上的链配置合约中获取非阻塞式事务类型对应的非阻塞式链配置锁,且通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态。
其中,配置交易中包括其他区块链的链标识、与配置事务相关联的第二跨链配置项,第二配置事务标识用于表征上述配置事务的事务标识,第二配置事务标识可以数字、字符、或者数据和字符所构成的字符串。例如,针对配置事务x,调用管理链上的链管理配置合约执行配置事务X对应的配置交易,可以生成配置事务x对应的配置事务标识ID-x。
其中,在配置事务的事务类型为非阻塞式事务类型时,管理链共识节点可以调用管理链上的链管理配置合约执行配置交易,生成配置交易对应的第二配置事务标识可以包括以下两种方式:
(1)本申请所涉及的多区块链包括由管理链共识节点通过管理链所管理的业务主链和独立于业务主链的业务子链;业务主链包括独立于管理链的票据链和合约链中的一个或者多个;业务子链所对应的子链共识网络是由票据链对应的票据链网络中的共识节点和合约链对应的合约链网络中的共识节点所共同组建的;其中,票据链网络独立于合约链网络;业务子链是由请求执行目标业务的业务对象通过管理链共识节点所授权创建的;一个目标业务对应一个业务子链。
当其他区块链的数量为多个时,多个其他区块链包括业务子链和业务主链;上述配置事务则是针对多个其他区块链进行跨链配置,此时,上述配置事务所指示的配置资源属于全局配置资源,而与全局配置资源对应的链管理配置合约为管理链上的平台配置合约。应理解的是,在平台配置合约中包括阻塞式事务配置方法和非阻塞式事务配置方法两种配置方法,通过上述事务类型可以确定进行跨链配置时管理链共识节点所要调用的配置方法。当配置事务的事务类型为非阻塞式事务类型时,管理链共识节点可以将配置交易写入平台配置合约,然后根据非阻塞式事务类型确定需要执行的配置方法为平台配置合约中的非阻塞式事务配置方法,并调用该非阻塞式事务配置方法执行该配置交易,得到配置交易所指示的多个其他区块链的链标识以及第二跨链配置项,接着,可以基于多个其他区块链的链标识和第二跨链配置项,生成配置交易对应的第二配置事务标识。
(2)其他区块链可以为票据链、合约链或者业务子链。上述票据链和合约链由管理链 共识节点可以通过管理链上的全平台配置合约所管理。该全平台配置合约中包括链管理配置合约。在配置事务所指示的配置资源属于独立配置资源时,与独立配置资源对应的链管理配置合约为管理链上的其他区块链管理配置合约;该其他区块链管理配置合约包括用于配置票据链的链管理配置合约、用于配置合约链的链管理配置合约或者用于配置业务子链的子链管理配置合约。此处的独立配置资源是指为某个区块链单独配置的资源,如对其他区块链单独配置区块的大小、对其他区块链上的业务进行升级等等。
当其他区块链为票据链时,其他区块链管理配置合约包括用于配置票据链的链管理配置合约,在配置事务的事务类型为非阻塞式事务类型时,可以将配置交易写入票据链的链管理配置合约,然后调用票据链的链管理配置合约中的非阻塞式事务配置方法执行该配置交易,得到配置交易所指示的票据链的链标识和第二跨链配置项,并基于票据链的链标识和第二跨链配置项,生成配置交易对应的第二配置事务标识。
当其他区块链为合约链时,其他区块链管理配置合约包括用于配置合约链的链管理配置合约,在配置事务的事务类型为非阻塞式事务类型时,可以将配置交易写入合约链的链管理配置合约,然后调用合约链的链管理配置合约中的非阻塞式事务配置方法执行该配置交易,得到配置交易所指示合约链的链标识和第二跨链配置项,并基于合约链的链标识和第二跨链配置项,生成配置交易对应的第二配置事务标识。
当其他区块链为业务子链时,其他区块链管理配置合约包括用于配置业务子链的子链管理配置合约,在配置事务的事务类型为非阻塞式事务类型时,可以将配置交易写入子链管理配置合约,然后调用该子链管理配置合约中的非阻塞式事务配置方法执行该配置交易,得到配置交易所指示的业务子链的链标识,并基于业务子链的链标识,生成配置交易对应的第二配置事务标识。
步骤S507、接收跨链中继发送的第二锁定声明交易;第二锁定声明交易是跨链中继在探测到其他区块链处于第二业务锁定状态时所确定的。
其中,当跨链中继在探测到其他区块链处于第二业务锁定状态时,可以基于该第二业务锁定状态生成第二锁定声明交易,并向跨链中继发送第二锁定声明交易。相应的,管理链共识节点可以接收跨链中继发送的第二锁定声明交易。第二锁定声明交易可以用于声明其他区块链已被成功锁定,该其他区块链无法在进行正常业务,或者用于声明第二配置事务标识锁定成功,也即让管理链相关联的管理链共识节点确定第二配置事务标识对应的配置事务的状态处于第二事务锁定状态。
步骤S508、在配置事务的状态为第二事务锁定状态时,生成第二锁定声明交易对应的第二事务锁定信息,将第二事务锁定信息写入管理链,配置事务是第二配置事务标识所对应的,配置事务的状态是基于第二锁定声明交易确定的。
其中,管理链共识节点可以基于第二锁定声明交易确定第二配置事务标识所对应的配置事务的状态为第二事务锁定状态,并在确定第二配置事务标识所对应的配置事务的状态为第二事务锁定状态时,生成第二锁定声明交易对应的第二事务锁定信息,并将第二事务锁定信息打包成区块,并通过管理链网络中的其他共识节点进行共识,然后在共识通过后将该区块写入管理链。第二事务锁定信息可以用于指示已在其他区块链上将与该配置事务相关联的资源锁定,其他区块链上暂时无法进行正常业务。其中,应理解的是,第二跨链配置项中指示需要对其他区块链进行配置的配置资源。
管理链上的管理链共识节点可以接收用于跨链配置其他区块链的配置交易,并根据配置事务的事务类型生成相应的配置事务标识(如根据阻塞式事务类型对应生成第一配置事务标识,根据非阻塞式事务类型对应生成第二配置事务标识),随后跨链中继通过相应的配置事务标识让其他共识节点获取相应的配置锁(阻塞式链配置锁或者非阻塞式链配置锁),通过相应的配置锁可以将其他区块链上的业务状态进行锁定,并在锁定其他区块链的业务状态之后,将管理链上为其他区块链所配置的跨链配置项通过跨链中继配置到其他区块链。由此可 见,本申请实施例通过管理链上的管理链共识节点(例如,前述图1中所示的10a)可以对其他链的配置信息进行统一管理,以确保链上配置信息的一致性。同时,在其他区块链的业务状态被锁定时,管理链共识节点可以生成相应的事务锁定信息,写入管理链中,这样也可以有效保障其他区块链的配置的可审查性和可追溯性;另外,引入配置锁这样的配置机制,可以确保彼此相互独立的各区块链上配置信息的一致性和可靠性。
进一步的,多区块链系统包括链外处理设备,链外处理设备在多区块链中确定待进行跨链处理的至少两个区块链;链外处理设备与管理链共识节点协同对至少两个区块链进行跨链处理。
链外处理设备包括跨链中继,跨链中继与管理链共识节点协同将跨链配置项配置至至少一个其他区块链。请参见图6,图6是本申请实施例提供的一种基于多区块链的跨链配置方法,多区块链包括管理链和其他区块链;该方法由跨链中继执行;跨链中继用于隔离管理链对应的管理链网络和其他区块链对应的其他区块链网络。该方法具体可以包括以下步骤。
步骤S601、在探测到第一配置事务标识时,向其他区块链网络中的其他共识节点发送第一配置锁获取交易;第一配置事务标识是第一链上的配置交易对应的,第一配置事务标识是管理链网络中的管理链共识节点在配置交易中的配置事务的事务类型为阻塞式事务类型时,调用管理链上的管理配置合约执行配置交易所生成的,配置交易是由请求执行配置事务的管理对象发送的;第一配置锁获取交易用于指示其他共识节点从其他区块链上的链配置合约中获取阻塞式事务类型对应的阻塞式链配置锁,且通过阻塞式链配置锁将其他区块链的业务状态配置为第一业务锁定状态。
其中,配置交易中包括其他区块链的链标识,本申请实施例所涉及的跨链中继的数量可以为多个,一个跨链中继可以对应一个或多个配置事务标识,即一个跨链中继可以转发相应配置事务相关联的交易,如本申请实施例中,跨链中继可以基于第一配置事务标识,将第一配置锁获取交易发送给其他区块链。只有第一配置事务标识所对应的跨链中继才可以转发第一配置事务标识相关联的交易。
具体的,跨链中继在探测到管理链上的配置交易对应的第一配置事务标识时,可以基于第一配置事务标识生成第一配置锁获取交易,并向其他区块链网络中的其他共识节点发送第一配置锁获取交易,其他区块链网络中的其他共识节点可以根据第一配置锁获取交易,从其他区块链上的链配置合约中获取阻塞式事务类型对应的阻塞式链配置锁,然后通过该阻塞式链配置锁将其他区块链的业务状态配置为第一业务锁定状态。
其中,在其他区块链的链配置合约中可以包括阻塞式链配置锁和非阻塞式链配置锁这两种合约锁,采用阻塞式链配置锁可以将其他区块链上的业务状态配置为第一业务锁定状态,而处于第一业务锁定状态的其他区块链上无法继续进行正常业务,产生新区块,只有在将为其他区块链所配置的第一跨链配置项配置至其他区块链时,才能恢复正常业务。因此后续将第一跨链配置项跨链配置至其他区块链时,通过阻塞式链配置锁,可以实现将所要配置的第一跨链配置项完全同步配置到其他区块链上。
采用非阻塞式链配置锁,可以提供一个块缓冲高度,该块缓冲高度可以用于表征在通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态之前,其他区块链上所得到的区块的最大间隔高度。也就是说,在将其他区块链上的业务状态配置为第二业务锁定状态之前,可以允许其他区块链上进行正常业务,产生新区块。当其他区块链上所得到的区块的间隔高度达到块缓冲高度时,才将其他区块链的业务状态配置为第二业务锁定状态。例如,块缓冲高度为100,当其他区块链上产生的新的区块的间隔高度(例如,其他区块链上产生依次产生了区块1、区块2、区块3,间隔高度是指区块1到区块3之间的高度)达到100时,可以将其他区块链的业务状态配置为第二业务锁定状态,此时,其他区块链停止进行正常业务,不允许产生新的区块。只有等待将其他区块链所配置的跨链配置项配置至其他 区块链,才能恢复链上业务。通过非阻塞式链配置锁,可以实现无缝的配置修改,对于用户来说无感知,提供了更好地用户体验。
上述将其他区块链上的业务状态配置为业务锁定状态(如上述第一业务锁定状态),是指将其他区块链上与配置事务相关联的资源或者参数进行锁定。当其他区块链网络基于第一配置锁获取交易获取到阻塞式链配置锁时,其他配置事务标识将无法获取到任何配置锁(即无法在获取到阻塞式链配置锁和非阻塞式链配置锁),只有阻塞式链配置锁被释放,其他配置事务标识才能获取到配置锁。
可选地,为阻塞式链配置锁设置一个累计锁定时长阈值,累计锁定时长阈值可以根据需求设置,如累计锁定时长阈值可以为1小时、30分钟、两天等等。通过这样一个累计锁定时长阈值可以避免阻塞式链配置锁一直被其他区块链被占用,无法用于其他的配置交易。具体的,跨链中继可以对探测到处于第一业务锁定状态的其他区块链的链锁定时长进行累计,在累计到链锁定时长达到阻塞式链配置锁的累计锁定时长阈值时,则向其他共识节点发送超时释放锁交易,其中,超时释放锁交易可以用于指示其他共识节点调用链配置合约中的锁释放方法对阻塞式链配置锁进行释放,且将其他区块链的业务状态由第一业务锁定状态更改为业务解锁状态。可以理解的是,跨链中继从开始探测到其他区块链处于第一业务锁定状态时就开始累计链锁定时长,直到累计到的链锁定时长达到累计锁定时长阈值时,就可以向其他共识节点发送超时释放锁交易。应理解的是,采用上述其他配置事务标识将无法获取到任何配置锁以及超时机制这样可以保障多链并发下的配置修改一致性,保证链上元数据的安全性。
步骤S602、在探测到其他区块链处于第一业务锁定状态时,向管理链共识节点发送第一锁定声明交易;第一锁定声明交易用于指示管理链共识节点在基于第一锁定声明交易确定配置事务标识所对应的配置事务的状态为第一事务锁定状态时,生成用于写入管理链的第一锁定声明交易对应的第一事务锁定信息。
其中,处于第一业务锁定状态的其他区块链无法进行正常业务,而未处于第一业务锁定状态的其他区块链则可以进行正常业务。在这种情况下,跨链中继可以不断向其他共识节点发送交易数据,若其他区块链中的其他共识节点无法对交易数据打包成区块,也并未向跨链中继返回针对该交易数据的执行结果,则跨链中继可以探测到其他区块链处于第一业务锁定状态。若其他区块链中的其他共识节点对交易数据打包成区块,并经过其他区块链上的其他共识节点的共识之后写入其他区块链上,同时也向跨链中继返回针对该交易数据的执行结果,则跨链中继可以探测到其他区块链未处于第一业务锁定状态。
其中,在探测到其他区块链未处于第一业务锁定状态时,跨链中继可以向管理链共识节点发送第一锁定失败交易,第一锁定失败交易可以用于声明第一配置事务标识锁定失败,以使管理链网络中的管理链共识节点在基于第一锁定失败交易确定第一配置事务标识所对应的配置事务的状态不为第一事务锁定状态时,生成写入管理链的第一锁定失败交易对应的第一事务锁定失败信息。第一事务锁定失败信息用于指示其他区块链锁定失败,管理对象可以从管理链上获取第一事务锁定失败信息,以此知道当前无法提交配置修改交易实现同步配置。
可选地,在探测到其他区块链未处于第一业务锁定状态时,跨链中继可以向其他共识节点发送第一锁定失败释放锁交易,其中,第一锁定失败释放锁交易用于指示其他共识节点调用其他区块链上的链配置合约中的锁释放方法释放阻塞式链配置锁。
步骤S603、在探测到管理链上的配置修改交易时,获取配置修改交易中的第一跨链配置项;上述配置修改交易是由管理对象基于管理链上的第一事务锁定信息所发送的。
其中,管理对象基于第一事务锁定信息可以向管理链网络中的管理链共识节点发送配置修改交易,而跨链中继可以探测是否存在管理链上的配置修改交易,当探测到管理链上的配置修改交易时,可以获取配置修改交易中的第一跨链配置项。
步骤S604、将第一跨链配置项跨链配置至其他区块链,以使其他共识节点通过阻塞式链配置锁解锁处于第一业务锁定状态的其他区块链。
其中,将第一跨链配置项跨链配置至其他区块链是指跨链中继将第一跨链配置项跨链中继给其他区块链,然后其他区块链可以将该第一跨链配置项写入其他区块链的链配置合约中,并在写入其他区块链的链配置合约之后,通过阻塞式链配置锁解锁处于第一业务锁定状态的其他区块链,从而恢复其他区块链上的正常业务。
可选地,将第一跨链配置项跨链配置至其他区块链可以是以一笔交易的形式跨链配置至其他区块链。具体的,跨链中继可以基于第一跨链配置项构建第一释放锁交易,第一锁释放交易(Commit&Unclock)中包括第一跨链配置项,第一释放锁交易用于指示其他共识节点在将第一跨链配置项写入链配置合约时,调用链配置合约中的锁释放方法对阻塞式链配置锁进行释放,且将其他区块链的业务状态由所述第一业务锁定状态更改为业务解锁状态。其中,处于业务解锁状态的其他区块链可以进行正常业务。
其中,只有对应第一配置事务标识的跨链中继才可以解锁其他区块链中的阻塞式链配置锁,即在向其他共识节点发送第一释放锁交易时,在该第一锁释放交易中可以携带有第一配置事务标识,这样其他共识节点可以将在基于第一配置事务标识将第一释放锁交易写入其他区块链中的链配置合约,并调用链配置合约中的锁释放方法对阻塞式链配置锁进行释放。
在本申请实施例中,管理链上的管理链共识节点可以接收到用于跨链配置所述其他区块链的配置交易,并在配置事务的事务类型为阻塞式事务类型时,执行上述配置交易,生成配置交易对应的第一配置事务标识;随后通过该第一配置事务标识可以让其他共识节点获取阻塞式事务类型对应的阻塞式链配置锁,并通过该阻塞式链配置锁对其他区块链的业务状态进行锁定,并在锁定其他区块链的业务状态之后,将管理链上为其他区块链所配置的跨链配置项通过跨链中继配置到其他区块链。由此可见,本申请实施例通过管理链上的管理链共识节点可以对其他链的配置信息进行统一管理,以确保链上配置信息的一致性。另外,引入阻塞式链配置锁这样的配置机制,可以实现配置的同步生效,保证了业务逻辑的严格执行,同时也可以确保彼此相互独立的各区块链上配置信息的一致性和可靠性。
进一步的,多区块链系统包括链外处理设备,链外处理设备在多区块链中确定待进行跨链处理的至少两个区块链;链外处理设备与管理链共识节点协同对至少两个区块链进行跨链处理。跨链处理包括跨链配置,链外处理设备包括跨链中继。请参见图7,图7是本申请实施例提供的一种基于多区块链的跨链配置方法,多区块链包括管理链和其他区块链;方法由跨链中继执行;跨链中继用于隔离管理链对应的管理链网络和其他区块链对应的其他区块链网络。该方法具体可以包括以下步骤。
步骤S701、在探测到第二配置事务标识时,向其他区块链网络中的其他共识节点发送第二配置锁获取交易,第二配置事务标识是管理链上的配置交易对应的,第二配置事务标识是管理链网络中的管理链共识节点在配置交易中的配置事务的事务类型为非阻塞式事务类型时,调用管理链上的管理配置合约执行配置交易所生成的,配置交易是由请求执行配置事务的管理对象发送的;第二配置锁获取交易用于指示其他共识节点从其他区块链上的链配置合约中获取非阻塞式事务类型对应的非阻塞式链配置锁,且通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态。配置交易中包括其他区块链的链标识以及与上述配置事务相关联的第二跨链配置项。第二跨链配项中包括对其他区块链需要配置的内容,如第二跨链配置项可以是配置对管理链所产生的区块大小。
具体的,跨链中继在探测到管理链上的配置交易对应的第二配置事务标识时,可以基于第二配置事务标识生成第二配置锁获取交易,并向其他区块链网络中的其他共识节点发送第二配置锁获取交易,其他区块链网络中的其他共识节点可以根据第二配置锁获取交易,从其他区块链上的链配置合约中获取非阻塞式事务类型对应的非阻塞式链配置锁,然后通过该非阻塞式链配置锁可以将其他区块链的业务状态配置为第二业务锁定状态。
其中,在其他区块链的链配置合约中可以包括阻塞式链配置锁和非阻塞式链配置锁这两 种合约锁,采用阻塞式链配置锁可以将其他区块链上的业务状态配置为第一业务锁定状态,而处于第一业务锁定状态的其他区块链无法产生新区块,停止正常业务,只有在将为其他区块链所配置的第一跨链配置项配置至其他区块链时,才能恢复正常业务。
采用非阻塞式链配置锁,可以提供一个块缓冲高度。即其他区块链中的其他共识节点在获取非阻塞式链配置的同时,还需要获取块缓存高度。该块缓冲高度可以用于表征在通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态之前,其他区块链上所得到的区块的最大间隔高度。也就是说,在将其他区块链上的业务状态配置为第二业务锁定状态之前,其他区块链上可以进行正常业务,当其他区块链上所得到的区块的间隔高度达到块缓冲高度时,才将其他区块链的业务状态配置为第二业务锁定状态。只有等待将其他区块链所配置的第二跨链配置项配置至其他区块链,才能恢复正常业务。通过非阻塞式链配置锁,可以实现无缝的配置修改,提供更好地用户体验。
上述将其他区块链上的业务状态配置为业务锁定状态(如上述第二业务锁定状态),是指将其他区块链上与配置事务相关联的资源或者参数进行锁定。当其他区块链网络基于第二配置锁获取交易获取到非阻塞式链配置锁时,其他配置事务标识将无法获取到任何配置锁(即无法在获取到阻塞式链配置锁和非阻塞式链配置锁),只有非阻塞式链配置锁被释放之后,其他配置事务标识才能获取到配置锁。
其中,在通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务状态之前,跨链中继可以向其他区块链网络中的其他共识节点发送交易数据,其他共识节点可以将接收到的交易数据打包成区块并通过其他区块链中的其他共识节点进行共识,在共识通过之后将该区块写入到其他区块链中,并向跨链中继返回交易数据的执行结果,其他共识节点可以不断确定其他区块链上所得到的区块的间隔高度,当其他区块链上所得到的区块的间隔高度达到块缓冲高度时,可以通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态。
步骤S702、在探测到其他区块链处于第二业务锁定状态时,向管理链共识节点发送第二锁定声明交易;第二锁定声明交易用于指示管理链共识节点在基于第二锁定声明交易确定配置事务标识所对应的配置事务的状态为第二事务锁定状态时,生成用于写入管理链的第二锁定声明交易对应的第二事务锁定信息。
其中,处于第二业务锁定状态的其他区块链暂时无法进行正常业务,而未处于第二业务锁定状态的其他区块链上可以进行正常业务。在这种情况下,跨链中继仍然向其他共识节点发送交易数据,若其他共识节点无法对接收到的交易数据打包成区块,也无法向跨链中继返回交易数据的执行结果,则可以探测到其他区块链处于第二业务锁定状态。若其他区块链中的其他共识节点还可以执行对该交易数据打包成区块,并向跨链中继返回针对该交易数据的执行结果,则可以探测到其他区块链未处于第二业务锁定状态。
其中,在探测到其他区块链未处于第二业务锁定状态时,跨链中继可以向管理链共识节点发送第二锁定失败交易,该第二锁定失败交易可以用于声明第二配置事务标识锁定失败,以使管理链网络中的管理链共识节点在基于第二锁定失败交易确定第二配置事务标识所对应的配置事务的状态不为第二事务锁定状态时,生成写入管理链的第二锁定失败交易对应的第二事务锁定失败信息。应理解是,第二事务锁定失败信息用于指示其他区块链锁定失败,管理对象可以从管理链上获取第二事务锁定失败信息,基于该第二事务锁定失败信息确定当前无法对其他区块链进行跨链配置。
可选地,在探测到其他区块链未处于第二业务锁定状态时,跨链中继可以向其他共识节点发送第二锁定失败释放锁交易,其中,第二锁定失败释放锁交易用于指示其他共识节点调用其他区块链上的链配置合约中的锁释放方法释放非阻塞式链配置锁。
步骤S703、将第二跨链配置项跨链配置至其他区块链,以使其他共识节点通过非阻塞式链配置锁解锁处于第二业务锁定状态的其他区块链。
其中,跨链中继无需探测管理链上是否存在配置修改交易,当探测到其他区块链处于第二业务锁定状态时,在配置交易中包括与配置事务相关联的第二跨链配置向,跨链中继可以直接将二跨链配置项跨链配置至其他区块链。具体的,跨链中继可以将第二跨链配置项跨链中继给其他区块链,其他区块链可以将该第二跨链配置项写入其他区块链的链配置合约中,并在写入其他区块链的链配置合约之后,通过非阻塞式链配置锁解锁处于第二业务锁定状态的其他区块链,从而恢复其他区块链上的正常业务。
通过阻塞式链配置锁或者非阻塞式链配置锁对其他区块链进行跨链配置,两者主要区别在于通过阻塞式链配置锁对其他区块链进行跨链配置存在两个阶段(即第一阶段为发起配置交易将其他区块链的业务状态配置为第一业务锁定状态,第二阶段为在其他区块链处于第一业务锁定状态时,发起修改配置交易,并通过跨链中继将修改配置交易中的第一跨链配置项配置至其他区块链)。如在上述图6中,第一阶段可以对应步骤S601-S602,第二阶段为步骤S603-S604。通过阻塞式链配置锁对其他区块链进行跨链配的两个阶段,可以做到跨链配置的同步生效,提供更好的一致性,但会导致其他区块链短暂不可以用。而通过非阻塞式链配置锁对其他区块链进行跨链配置时,只需要一个阶段,即发起配置交易将其他区块链的业务状态配置为第二业务锁定状态,跨链中继可以在探测到其他区块链处于第二业务锁定状态时,直接将配置交易中的第二跨链配置项配置至其他区块链;无需在其他区块链处于第二业务锁定状态时,再发起修改配置交易,通过非阻塞式链配置锁对其他区块链进行跨链配置的这一个阶段,实现对其他区块链进行业务无影响地跨链配置,这样的跨链配置用户无感知,提供了更便捷友好的用户体验。
在本申请实施例中,管理链上的管理链共识节点可以在接收到用于跨链配置其他区块链的配置交易,并在确定配置事务的事务类型为非阻塞式事务类型时,执行上述配置交易,生成配置交易对应的第二配置事务标识;跨链中继可以通过该第二配置事务标识可以使其他共识节点获取非阻塞式事务类型对应的非阻塞式链配置锁,并通过该非阻塞式链配置锁对其他区块链的业务状态进行锁定;然后在锁定其他区块链的业务状态之后,将管理链上为其他区块链所配置的第二跨链配置项通过跨链中继配置到其他区块链。由此可见,本申请实施例通过管理链上的管理链共识节点可以对其他链的配置信息进行统一管理,以确保链上配置信息的一致性。另外,引入非阻塞式链配置锁这样的配置机制,可以实现无缝的配置修改,提供更好地用户体验,同时也可以确保彼此相互独立的各区块链上配置信息的一致性和可靠性。
进一步的,请参见图8,图8是本申请实施例提供的一种基于多区块链的跨链配置方法,多区块链包括管理链和其他区块链,方法可以由与管理链所对应的管理链网络中的管理链共识节点、跨链中继以及其他区块链所对应的其他区块链网络中的其他共识节点共同执行,跨链中继可以用于隔离管理链网络和其他区块链网络。该方法具体可以包括以下步骤。
步骤S801、管理链共识节点接收管理对象基于配置事务发送的用于跨链配置其他区块链的配置交易。
步骤S802、管理链共识节点确定配置事务的事务类型。
步骤S803、管理链共识节点在配置事务的事务类型为阻塞式事务类型时,调用管理链上的链管理配置合约执行配置交易,生成配置交易对应的第一配置事务标识。
步骤S804、跨链中继探测管理链上的配置交易对应的第一配置事务标识。
步骤S805、在探测到管理链上的配置交易对应的第一配置事务标识时,跨链中继向其他区块链网络中的其他共识节点发送第一配置锁获取交易。
步骤S806、其他共识节点从其他区块链上的链配置合约中获取阻塞式事务类型对应的阻塞式链配置锁,且通过阻塞式链配置锁将其他区块链的业务状态配置为第一业务锁定状态。
应理解的是,其他共识节点接收跨链中继发送的第一配置锁获取交易,然后根据该第一 配置锁获取交易从其他区块链上的链配置合约中获取阻塞式事务类型对应的阻塞式链配置锁。
步骤S807、跨链中继在探测到其他区块链处于第一业务锁定状态时,向管理链共识节点发送第一锁定声明交易。
其中,跨链中继在探测到其他区块链处于第一业务锁定状态时,可以基于第一业务锁定状态生成第一锁定声明交易,第一锁定声明交易可以用于声明其他区块链已被成功锁定,或者用于声明第一配置事务标识锁定成功。
步骤S808、管理链共识节点在基于第一锁定声明交易确定配置事务标识所对应的配置事务的状态为第一事务锁定状态时,生成第一锁定声明交易对应的第一事务锁定信息,将第一事务锁定信息写入管理链。
其中,管理链共识节点在接收到跨链中继发送的第一锁定声明交易,然后基于第一锁定声明交易确定配置事务标识所对应的配置事务的状态为第一事务锁定状态,并在确定配置事务标识所对应的配置事务的状态为第一事务锁定状态时,可以基于第一锁定声明交易生成第一事务锁定信息,然后通过管理链中除其他共识节点之外的其他共识节点对第一事务锁定信息进行共识,并在共识通过之后根据第一事务锁定信息生成区块写入管理链。
步骤S809、管理链共识节点接收管理对象基于管理链上的第一事务锁定信息发送的配置修改交易。
步骤S810、在获取到管理对象基于管理链上的第一事务锁定信息发送的配置修改交易时,管理链共识节点获取配置修改交易中的第一跨链配置项。
步骤S811、跨链中继在探测到管理链上的配置修改交易时,获取配置修改交易中的第一跨链配置项。
步骤S812、跨链中继将第一跨链配置项跨链配置至其他区块链。
步骤S813、其他共识节点通过阻塞式链配置锁解锁处于第一业务锁定状态的其他区块链。
可选地,应理解的是,可以为阻塞式链配置锁设置一个累计锁定时长阈值,通过这样一个累计锁定时长阈值可以避免阻塞式链配置锁一直被其他区块链被占用,无法用于其他的配置交易。其他共识节点可以对处于第一业务锁定状态的其他区块链的链锁定时长进行累计,在累计到链锁定时长达到阻塞式链配置锁的累计锁定时长阈值时,则其他共识节点调用锁释放方法对阻塞式链配置锁进行释放,并将其他区块链的业务状态由第一业务锁定状态更改为业务解锁状态。
可选地,跨链中继可以对探测到处于第一业务锁定状态的其他区块链的链锁定时长进行累计,在累计到链锁定时长达到阻塞式链配置锁的累计锁定时长阈值时,则向其他共识节点发送超时释放锁交易。其他共识节点在接收到该超时释放锁交易之后,其他共识节点调用锁释放方法对阻塞式链配置锁进行释放,并将其他区块链的业务状态由第一业务锁定状态更改为业务解锁状态。
在本申请实施例中,管理链上的管理链共识节点可以接收用于跨链配置其他区块链的配置交易,在配置事务的事务类型为阻塞式事务类型时,执行上述配置交易,生成配置交易对应的第一配置事务标识;随后通过该第一配置事务标识使其他共识节点获取阻塞式事务类型对应的阻塞式链配置锁,并通过该阻塞式链配置锁对其他区块链的业务状态进行锁定;在锁定其他区块链的业务状态之后,将管理链上为其他区块链所配置的跨链配置项通过跨链中继配置到其他区块链。由此可见,本申请实施例通过管理链上的管理链共识节点可以对其他链的配置信息进行统一管理,以确保链上配置信息的一致性。同时,在其他区块链的业务状态被锁定时,管理链可以生成相应的事务锁定信息,写入管理链中,这样也可以有效保障其他区块链的配置的可审查性和可追溯性;另外,引入阻塞式链配置锁这样的配置机制,可以实现配置的同步生效,保证了业务逻辑的严格执行,同时也可以确保彼此相互独立的各区块链 上配置信息的一致性和可靠性。
进一步的,请参见图9,图9是本申请实施例提供的一种基于多区块链的跨链配置方法,多区块链包括管理链和其他区块链,方法可以由与管理链所对应的管理链网络中的管理链共识节点、跨链中继以及其他区块链所对应的其他区块链网络中的其他共识节点共同执行,跨链中继可以用于隔离管理链网络和其他区块链网络。该方法具体可以包括以下步骤。
步骤S901、管理链共识节点接收管理对象基于配置事务发送的用于跨链配置其他区块链的配置交易。
步骤S902、管理链共识节点确定配置事务的事务类型。
步骤S903、管理链共识节点在配置事务的事务类型为非阻塞式事务类型时,调用管理链上的链管理配置合约执行配置交易,生成配置交易对应的第二配置事务标识。
步骤S904、在探测到管理链上的配置交易对应的第二配置事务标识时,向其他区块链网络中的其他共识节点发送第二配置锁获取交易。
步骤S905、在探测到管理链上的配置交易对应的第二配置事务标识时,向其他区块链网络中的其他共识节点发送第二配置锁获取交易。
步骤S906、其他共识节点从其他区块链上的链配置合约中获取非阻塞式事务类型对应的非阻塞式链配置锁,且通过非阻塞式链配置锁将其他区块链的业务状态配置为第二业务锁定状态。
其他共识节点接收跨链中继发送的二配置锁获取交易,然后根据该第二配置锁获取交易从其他区块链上的链配置合约中获取非阻塞式事务类型对应的非阻塞式链配置锁。
步骤S907、跨链中继在探测到其他区块链处于第二业务锁定状态时,向管理链共识节点发送第二锁定声明交易。
步骤S908、管理链共识节点在基于第二锁定声明交易确定配置事务标识所对应的配置事务的状态为第二事务锁定状态时,生成第二锁定声明交易对应的第二事务锁定信息,将第二锁定声明交易对应的第二事务锁定信息写入管理链。
其中,管理链共识节点在接收到跨链中继发送的第二锁定声明交易,然后基于第二锁定声明交易确定配置事务标识所对应的配置事务的状态为第二事务锁定状态,并在确定配置事务标识所对应的配置事务的状态为第二事务锁定状态时,可以基于第二锁定声明交易生成第二事务锁定信息,并将第二事务锁定信息生成区块,并在通过第管理链上其他共识节点的共识之后将包括跌事务锁定信息的区块写入管理链。
步骤S909、跨链中继将与配置事务相关联的第二跨链配置项跨链配置至其他区块链。
步骤S910、其他共识节点通过非阻塞式链配置锁解锁处于第二业务锁定状态的其他区块链。
在本申请实施例中,管理链上的管理链共识节点可以接收用于跨链配置其他区块链的配置交易,在配置事务的事务类型为非阻塞式事务类型时,执行上述配置交易,生成配置交易对应的第二配置事务标识;随后跨链中继通过该第一配置事务标识可以使其他共识节点获取非阻塞式事务类型对应的非阻塞式链配置锁,并通过非阻塞式链配置锁对其他区块链的业务状态进行锁定;在锁定其他区块链的业务状态之后,可以将管理链上为其他区块链所配置的第二跨链配置项通过跨链中继配置到其他区块链。由此可见,本申请实施例通过管理链上的管理链共识节点可以对其他链的配置信息进行统一管理,以确保链上配置信息的一致性。同时,在其他区块链的业务状态被锁定时,管理链共识节点可以生成相应的事务锁定信息,写入管理链中,这样也可以有效保障其他区块链的配置过程的可审查性和可追溯性;另外,引入非阻塞式链配置锁这样的配置机制,实现了无缝的配置修改,提升了用户体验,同时可以确保彼此相互独立的各区块链上配置信息的一致性和可靠性。
基于多区块链的跨链数据传输。
本申请实施例还提供一种基于多区块链的跨链数据传输处理系统。请参见图10,图10是本申请实施例提供的一种基于多区块链的跨链数据传输方法的示意图。该基于多区块链的跨链数据传输处理系统可以包括管理链301关联的共识节点,票据链(也称发票链)302关联的共识节点,应用合约链303关联的共识节点,业务子链304关联的共识节点、跨链服务终端305以及用户终端306。
其中,该管理链301(也称目标链)关联的共识节点可以用于维护管理链上的数据。管理链关联的共识节点可以部署有子网创建管理合约,以用于管理业务子链的创建,此处不做赘述。管理链的共识节点还可以用于管理跨链服务终端的可信跨链程序的启动,可以理解的是,针对一个业务可以创建一个对应的业务子链,并启动一个用于实现源区块链(如智能合约链与票据链)与该业务子链进行数据链的可信跨链程序,以此保障三链体系内的区块链与外部区块链(即业务子链)之间的跨链数据传输的安全性。管理链关联的共识节点还可以部署有管理组件管理合约,以用于管理多个管理组件,以便于通过管理组件对源区块链如应用合约链上的应用合约链中转地址进行探测,并在管理组件生成交易探测信息后,管理链关联的共识节点可以向跨链服务终端发送跨链交易事件。
该票据链302(也称第二链)关联的共识节点可以用于维护票据链上的数据,如可以用于维护票据链上的发票数据的全生命周期和各项属性。该票据链上可以部署有票据业务合约,此处不做赘述。该票据链上还可以部署有票据链通用资源跨链桥合约,该票据链通用资源跨链桥合约可以用于指示票据链关联的共识节点与跨链服务终端中的可信跨链程序进行数据交互,完成票据链上数据与业务子链之间进行跨链数据传输。
该应用合约链303(也称第一链)关联的共识节点可以用于维护应用合约链上的数据,如部署业务相关的智能合约。应用合约链上部署的智能合约可以包括衍生业务合约,此处不做赘述。该应用合约链上还可以部署有通用资源跨链桥合约,该通用资源跨链桥合约可以用于指示应用合约链关联的共识节点与跨链服务终端中的可信跨链程序进行数据交互,完成应用合约链上数据与业务子链之间进行跨链数据传输。
该业务子链304关联的共识节点可以用于维护业务子链上的数据。业务子链可以由管理链关联的共识节点进行创建,即业务子链的创建需要通过管理链相关联的共识节点进行授权,进而管理关联的共识节点可以基于业务子链创建服务创建业务子链,所创建的业务子链的共识网络中的共识节点可以复用票据链或应用合约链关联的的共识网络中的节点,如图10中304所示的业务子链,可以通过确定该多个票据链验证者和应用合约链验证者来构成业务子链的共识网络,可以理解的是,在确定业务子链的共识网络时,可以根据票据链和应用合约链的共识网络中共识节点的空闲程度来确定业务子链关联的共识节点,如可以选择比较空闲的节点来作为业务子链的共识节点,从而可以减少较繁忙的节点的数据处理压力,进而有助于提升业务处理的效率。并且该业务子链上还可以部署有子链通用跨链桥合约,该子链通用资源跨链桥合约可以用于指示业务子链关联的共识节点与跨链服务终端中的可信跨链程序进行数据交互,完成业务子链与票据链或应用合约链之间进行跨链数据传输。该业务子链是由于专用型业务或者特殊业务的需要,即时构建出的一个子链,业务执行完成后也可以进行数据提取和销毁,通过构建业务子链去进行业务的处理,相较于直接基于源区块链进行业务处理,可以减少业务处理时,对源区块链上的空间的占用。
该跨链服务终端305可以部署有可信跨链程序,该可信跨链程序处于可信执行环境,从而可以保障跨链数据传输操作的安全性。该跨链服务终端用于隔离多区块链中的源区块链和业务子链,可以用于执行上述的基于多区块链的跨链数据传输方案以实现源区块链和业务子链之间的跨链数据传输。该跨链服务终端可以提供应用合约链跨链服务,以用于实现应用合约链与业务子链之间的跨链数据传输,还可以提供票据链跨链服务,以用于实现票据链与业务子链之间的跨链数据传输。该跨链服务终端提供跨链服务的核心技术为Intel SGX(software guard extensions,一种处理器技术),旨在以硬件安全为强制性保障,不依赖于 固件和软件的安全状态,提供用户空间的可信执行环境,通过一组新的指令集扩展与访问控制机制,实现不同程序间的隔离运行,保障用户关键代码和数据的机密性与完整性不受恶意软件的破坏。不同于其他安全技术,SGX的可信计算基(trusted computing base,TCB)仅包括硬件,避免了基于软件的TCB自身存在软件安全漏洞与威胁的缺陷,极大地提升了系统安全保障;此外,SGX可保障运行时的可信执行环境,恶意代码无法访问与篡改其他程序运行时的保护内容,进一步增强了系统的安全性。
该用户终端306可以用于与上述基于多区块链的跨链数据传输处理系统中的多区块链的共识节点进行交互。例如,用户终端可以向管理链的共识节点请求创建业务子链,如步骤S31、S32所示,以便于管理链可以基于子网管理创建合约创建业务子链;又如,可以向票据链或应用合约链的共识节点发起跨链数据传输转移请求,进行相关的业务合约调用,实现跨链转移资源至业务子链,如步骤S33、S34所示;又如可以与业务子链的共识节点进行业务交互,如步骤S35所示,等等,此处不做限制。
此处结合图示对基于多区块链的跨链数据传输处理系统中的数据处理过程进行介绍,此处以源区块链为合约链(即上述应用合约链),业务子处理子链为第一业务子链为例,对应用合约链与第一业务子链之间的跨链数据传输的过程进行阐述,请参见图11,图11是本申请实施例提供的一种基于多区块链的跨链数据传输处理过程的示意图。首先,管理链401(也称目标链)的共识节点中的管理组件402可以对应用合约链403和第一业务子链404进行探测,具体可探测应用合约链中的第一地址以及第一业务子链404的中的第二地址,该第一地址即为前述的一个应用合约链中转地址,该第二地址也相当于第一业务子链上用于与应用合约链的共识节点进行资源转移的中转地址。该管理链401的共识节点还可以部署有管理组件管理合约,以用于对管理组件进行管理,如可以用于配置管理组件用于探测的区块链地址;该管理链401的共识节点还可以部署有可信跨链程序管理合约,以用于与跨链服务终端进行数据交互,如可以在接收到第一业务对象请求创建对第一业务子链404时,通知跨链服务终端405启动用于实现第一业务子链与应用合约链之间的数据的第一跨链程序。当管理组件402探测到应用合约链中的第一地址中存在交易资源,且交易资源处于锁定状态,则管理链401的管理共识节点可以向跨链服务终端405发送跨链交易事件,进而跨链服务终端405可以通过第一跨链程序将第一地址中处于锁定状态的交易资源转移至第一业务子链404。当管理组件402中的探测到第一业务子链404中的第二地址中存在交易映射资源,且交易资源处于销毁状态,则管理链401的管理共识节点可以向跨链服务终端405发送跨链交易事件,进而跨链服务终端405可以通过第一跨链程序将第二地址中处于销毁状态的交易映射资源转回至应用合约链403。其中,基于跨链服务终端405进行跨链交易的具体过程,可以参见如下图12至图16所对应的实施例。
需要进行说明的是,本申请在收集用户的相关数据之前以及在收集用户的相关数据的过程中,都可以显示提示界面、弹窗或输出语音提示信息,该提示界面、弹窗或语音提示信息用于提示用户当前正在搜集其相关数据,使得本申请仅仅在获取到用户对该提示界面或者弹窗发出的确认操作后,才开始执行获取用户相关数据的相关步骤,否则(即未获取到用户对该提示界面或者弹窗发出的确认操作时),结束获取用户相关数据的相关步骤,即不获取用户的相关数据。换句话说,本申请所采集的所有用户数据都是在用户同意并授权的情况下进行采集的,且相关用户数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
本申请的技术方案可运用在电子设备中,如上述的跨链服务终端。该电子设备可以是终端,也可以是服务器,或者也可以是用于进行数据处理的其他设备,本申请不做限定。可选的。服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的 云服务器。终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器、智能音箱、智能家电等。
可以理解,上述场景仅是作为示例,并不构成对于本申请实施例提供的技术方案的应用场景的限定,本申请的技术方案还可应用于其他场景。例如,本领域普通技术人员可知,随着系统架构的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
在一些实施例中,多区块链系统包括链外处理设备,链外处理设备在多区块链中确定待进行跨链处理的至少两个区块链;链外处理设备与管理链共识节点协同对至少两个区块链进行跨链处理。
链外处理设备包括部署有可信跨链程序的跨链服务终端,跨链服务终端与管理链共识节点协同将目标交易资源传输至所述至少一个其他区块链。请参见图12,图12是本申请实施例提供的一种基于多区块链的跨链数据传输法的流程示意图,该基于多区块链的跨链数据传输方法可以由跨链服务终端执行,该跨链服务终端部署的可信跨链程序可以为第一跨链程序。此处以源区块链为合约链(也称应用合约链),业务子处理子链为第一业务子链为例,对将资源从源区块链转移至业务子链的过程进行阐述。该基于多区块链的跨链数据传输方法可以包括以下步骤。
S1201、通过第一跨链程序接收管理链共识节点基于第一跨链交易探测信息发送的第一跨链交易事件;第一跨链交易探测信息是由管理链共识节点在探测到合约链上的第一地址中存在与第一业务相关联的第一跨链交易的目标交易资源,且目标交易资源处于锁定状态时所生成的;第一跨链交易是与合约链相关联的第一共识节点基于第一业务对象提交的目标交易资源所确定的,且第一跨链交易用于指示将目标交易资源由合约链转移至第一业务子链。
其中,该第一跨链程序可以为用于实现合约链(也称应用合约链)与第一业务子链之间的跨链数据传输的可信跨链程序,该第一跨链程序处于可信执行环境中。该管理链共识节点可以为上述目标链(即管理链)相关联的共识节点,此处不做赘述。
其中,该第一跨链交易事件用于指示管理共识节点基于第一地址探测到将交易资源由应用合约链转移至第一业务子链的跨链交易,从而可以在通过第一跨链程序接收到该第一跨链交易事件后,执行该第一跨链交易事件所指示的跨链交易(即第一跨链交易)。该第一地址是通过第一跨链程序中的第一私钥所确定,即第一跨链程序可以通过第一私钥在应用合约链上确定一个对应的第一地址,该第一私钥是在可信执行环境中生成的,通过该第一地址作为跨链交易过程中的一个中转地址,降低了链上资源的跨链的需要满足的条件,使得一些通用的业务数据也能进行跨链转移,并且能够保障资源的跨链转移的安全性。其中,进而管理共识节点可以通过探测第一地址中的交易资源以及交易资源的状态,确定是否需要向第一跨链程序发送跨链交易事件。
其中,管理共识节点在探测到应用合约链上的第一地址中存在需要进行跨链的交易资源时,生成第一跨链交易探测信息,该需要进行跨链的交易资源即为被转移至第一地址的目标交易资源,并且该目标交易资源处于锁定状态。进一步的,管理共识节点可以基于第一跨链交易探测信息确定用于发送给第一跨链程序的第一跨链交易事件,并将第一跨链交易事件发送给第一跨链程序,以便于跨链服务终端中的第一跨链程序可以基于该第一跨链交易事件的指示对目标交易资源进行跨链数据传输。
其中,管理共识节点包括与第一地址相关联的N个管理组件,N为正整数;一个管理组件用于在探测到第一地址中存在处于锁定状态的目标交易资源时生成第一跨链交易探测信息中的一个交易探测信息;第一跨链交易探测信息中的一个交易探测信息对应于第一跨链交易事件中的一个交易事件。也就是说,管理共识节点通过N个管理组件对第一地址中的交易资源以及交易资源的状态进行探测,管理组件在探测到第一地址中存在处于锁定状态的目标交易资源时生成第一跨链交易探测信息中的一个交易探测信息,以便于管理共识节点基于管 理组件探测到的第一跨链交易探测信息向跨链服务终端发送第一跨链交易事件。
其中,该第一业务子链是与多区块链中的管理链相关联的管理共识节点根据与第一业务对象相关联的第一业务创建的。该第一业务对象可以为请求执行第一业务的对象,该第一业务需要构建第一业务子链去进行第一业务的处理,以得到对应的业务处理结果,实现对第一业务的处理。在一个实施例中,管理共识节点接收到第一业务对象的业务子链创建请求,并对第一业务对象的业务权限进行验证,且在验证通过时,管理共识节点可以创建用于处理第一业务的第一业务子链。可以理解的是,该第一业务子链在要进行第一业务的处理时进行建立,从而将处理第一业务所需的数据从应用合约连上转移至第一业务子链,并基于第一业务子链进行业务处理,减少业务处理过程对第一业务子链上的空间占用,并且可以提升对第一业务的处理效率。
其中,该目标交易资源可以为需要转移至第一业务子链的资源。该目标交易资源可以为应用合约链上的业务数据。比如,在一些场景中,该第一业务可以用于对该第一业务对象在一定时间内的征信数据进行处理以得到该第一业务对象的信用度,则该目标交易资源可以为第一业务对象在该一定时间内的征信数据。
其中,当第一业务对象需要将应用合约链上的目标交易资源转移至第一业务子链进行处理时,第一业务对象可以向应用合约链关联的第一共识节点发起第一跨链交易,进而第一共识节点将第一业务对象的目标交易资源从应用合约链上的合约链用户地址转移至第一地址,并将目标交易资源调整为锁定状态。
可选的,第一共识节点可以通过调用应用合约链上部署的第一通用资源跨链桥合约,将第一业务对象需要转移至第一业务子链的目标交易资源从应用合约链上的合约链用户地址转移至第一地址,并将转移至第一地址的目标交易资源确定为锁定状态,以便于后续跨链服务终端中的第一跨链程序可以将目标交易资源从第一地址转移至第一业务子链。处于锁定状态的目标交易资源不能用于构建其他交易。可以理解的是,本申请相当于通过第一地址作为资源的中转地址,便于跨链服务终端中的第一跨链程序基于管理共识节点针对该第一地址的交易探测信息快速检测到跨链交易,从而实现将目标交易映射资源从应用合约链跨链转移至第一业务子链。
S1202、将处于锁定状态的目标交易资源作为第一转移交易资源,基于第一跨链交易事件对第一转移交易资源进行验证,且在验证成功时,基于第一转移交易资源构建第一跨链交易对应的第一跨链构造交易。
其中,该第一跨链构造交易用于指示将第一转移交易资源从合约链(也称应用合约链)上的第一地址转移至第一业务子链。可以理解的是,通过对第一转移交易资源进行验证,且仅在验证成功时才构建跨链构造交易,有助于保障跨链数据传输过程中交易资源的准确性和安全性。
其中,基于第一跨链交易事件对第一转移交易资源进行验证,可以包括对第一跨链交易事件中的各个交易事件对应的交易探测信息相关联的交易资源进行对比验证,还可以包括对第一转移交易资源相关联的依赖数据信息进行验证,此处不做限制。
具体的,第一跨链程序可以从接收到的第一跨链交易事件中确定与N个管理组件相关联的交易事件的第一事件数量;第一事件数量是由与N个管理组件相关联的第一跨链交易探测信息中的交易探测信息的信息数量所确定的;第一事件数量小于或者等于N;进一步的,当第一事件数量达到N中的事件数量阈值时,获取与第一事件数量相等的信息数量对应的交易探测信息;进一步的,将获取到的第一跨链交易探测信息中的每个交易探测信息所关联的交易资源作为第一探测资源,将各个第一探测资源进行交易对比,得到第一交易比对结果;进一步的,若第一交易对比结果指示比对成功,则生成用于确定各个第一探测资源均为第一转移交易资源的验证成功指示信息,在基于验证成功指示信息确定验证成功时,基于第一转移交易资源构建第一跨链交易对应的第一跨链构造交易。
其中,事件数量阈值可以为预设的一个阈值,通常来说,事件数量阈值可以大于N的一半,从而保障跨链服务终端接收到的第一跨链交易事件中的准确性。比如,若仅有一个管理组件进行探测,若该管理组件对应的交易探测信息被篡改,则跨链服务终端接收到的跨链交易事件就会出现错误,从而导致跨链交易失败或出现错误,然而,通过多个管理组件进行探测并发送对应的交易事件,提升了交易事件被篡改的难度,保障跨链事件的准确性,比如,当确定接收到跨链交易事件中的超过事件数量阈值的交易事件指示对同一交易资源进行转移时,即使可能存在一个管理组件探测到的交易探测信息所对应的交易事件在传输过程中被篡改,仍能通过其余交易事件的指示确定需要对目标交易资源进行跨链数据传输,并且对每个管理组件探测到的交易探测信息所对应的交易事件在传输过程中均进行篡改的难度较大,由此保障了跨链服务终端能够准确地检测到跨链交易,提升跨链数据传输的准确定和安全性。
该第一交易对比结果可以用于指示对比成功或者对比失败。若各个第一探测资源为相同交易资源,则第一交易对比结果指示对比成功,反之,若各个第一探测资源不为相同交易资源,则第一交易对比结果指示对比失败。由此可以通过对各个探测资源进行对比验证,确定所接收到的跨链交易事件中的存在大于或等于事件数量阈值的交易事件对应的交易探测信息关联交易资源均相同,且均为该第一转移交易资源,进而构建第一跨链构造交易,有助于提升第一跨链程序对第一跨链交易的检测的准确性,从而更能保障跨链数据传输的安全性。
例如,管理共识节点可以包括4个管理组件,事件数量阈值为3,则当检测到第一跨链交易事件中的交易事件的第一事件数量达到3时,可以对该3个交易事件对应的交易探测信息关联的交易资源进行对比验证,当验证到该3个交易事件对应的交易探测信息关联的交易资源相同,该相同的交易资源即为第一转移交易资源,进而可以基于该第一转移交易资源构造第一跨链构造交易。
具体的,跨链服务终端还可以从合约链上获取第一转移交易资源对应的依赖数据信息;进一步的,对依赖数据信息进行信息验证,且在信息验证成功时,基于依赖数据信息和第一转移交易资源构建第一跨链交易对应的第一跨链构造交易。
其中,可以理解的是,该依赖数据信息可以包括第一转移交易资源可以包括的第一转移交易资源的资源用途。例如,该第一业务可以用于对该第一业务对象在一定时间内的征信数据进行处理以得到该第一业务对象的信用度,则该第一转移交易资源的资源用途可以为计算信用度,由此可以通过对依赖数据信息的信息验证,如验证第一转移交易资源是否包括了第一转移交易资源的资源用途所需要的数据,以确保第一转移交易资源的完整性。
可选的,可以理解的是,该依赖数据信息还可以包括第一转移交易的关联数据,例如,第一转移交易资源为第一业务对象在一定时间内的征信数据,该征信数据可以包括每笔贷款事务的贷款时间、还款时间等信息,则该征信数据的依赖数据信息可以包括每笔贷款事务的贷款资金用途以及所涉及的交易流水号等等信息,由此可以通过依赖数据信息验证征信数据的有效性和完整性。
其中,可以理解的是,应用合约链上部署有用于与第一跨链程序进行数据交互的第一通用资源跨链桥合约;第一通用资源跨链桥合约用于指示第一共识节点在将目标交易资源转入第一地址时,指定第一跨链交易所对应的目标交易资源的资源用途;依赖数据信息包括资源用途。具体的,跨链服务终端可以将资源用途和第一转移交易资源作为交易参数,基于交易参数构建得到第一跨链交易对应的第一跨链构造交易。由此可以使得第二共识节点在接收到该第一跨链构造交易进行解析后,通过第一跨链构造交易的交易参数确定资源用途,进而第二共识节点可以基于该资源用途确定对第一转移交易资源的业务处理方法。
其中,第一通用资源跨链桥合约可以在第一业务对象提交第一跨链交易时被第一共识节点所调用,由此可以将需要跨链转移至第一业务子链的目标交易资源转移至第一地址,并且可以指定目标交易资源的资源用途。
S1203、通过第一跨链程序确定第一业务子链上的第二地址,基于第二地址将第一跨链构造交易发送至与第一业务子链相关联的第二共识节点,以使第二共识节点通过第二地址在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源;目标交易映射资源与目标交易资源具有相同的资源数据内容。
其中,可以理解的是,第二地址是由第一跨链程序中的第二私钥所确定的;第二私钥是由第一跨链程序中的主密钥所生成的;主密钥是由第一跨链程序所处的可信执行环境所确定的。该主密钥可以为在密钥的层次结构中,处于最高层的密钥,基于该主密钥可以生成第一私钥和第二私钥。并且,由于该主密钥是由第一跨链程序所处的可信执行环境所确定的,由此可以保证主密钥的安全性以及基于主密钥生成的第一私钥和第二私钥的安全性和隐私性,进而在一程度上保障整个跨链数据传输过程的安全性。
具体的,跨链服务终端可以通过第一跨链程序中的第二私钥对第一跨链构造交易进行交易签名,得到第一跨链构造交易的交易签名信息;进一步的,在将第一跨链构造交易发送至与第一业务子链相关联的第二共识节点时,将第一跨链构造交易的交易签名信息同步发送至第二共识节点,以使第二共识节点基于第二私钥对应的第二公钥对交易签名信息进行交易验签,且在交易验签成功时,得到第一跨链构造交易。
其中,跨链服务终端向第二共识节点发送第一跨链构造交易时,通过第二私钥进行对交易签名,进而第二共识节点可以对交易签名信息进行交易验证,由此可以验证该跨链构造交易是否为具有授权的跨链服务终端进行发送,并且可以验证到在该第一跨链构造交易的传输过程中是否被篡改。第二共识节点在基于对交易签名验签成功时,则表示该跨链构造交易为具有授权的跨链服务终端进行发送,并且在该第一跨链构造交易的传输过程中没有被篡改,进而才能够得到第一跨链构造交易,以实现对第一转移交易资源进行跨链转移。进一步可以理解的是,若第二共识节点在基于对交易签名验签失败时,则表示该跨链构造交易不为具有授权的跨链服务终端进行发送,或者在该第一跨链构造交易的传输过程中被篡改,进而不能得到第一跨链构造交易,以实现对第一转移交易资源进行跨链转移。可选的,若第二共识节点在基于对交易签名验签失败时,第二共识节点还可以向跨链服务终端返回用于交易验签失败的提示信息,以提示跨链服务终端该第一跨链构造交易验签失败。由此可以通过跨链服务终端的第二私钥进行交易签名,保障对第一跨链构造交易的安全性和合法性。
其中,第二地址中部署有用于调用第一业务子链上的资源映射合约的合约名称和合约地址;第二共识节点用于在获取到第一跨链构造交易时,通过第二地址中的合约名称和合约地址调用资源映射合约,在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源。
其中,可以理解的是,该资源映射合约(具体为其中的资源铸造方法)可以用于铸造基于跨链构造交易所指示的转移交易资源对应的交易映射资源,如可以基于第一跨链构造交易所指示的第一转移交易资源铸造对应的目标交易映射资源。可以理解的是,通过第二地址将第一跨链构造交易发送至与第二共识节点,也就是通过第二地址中部署的资源映射合约的合约名称和合约地址将第一跨链构造交易发送至与第二共识节点。
进一步,第二共识节点通过第二地址在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源,可以为在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源,并将目标交易映射资源写入第二地址。
可选的,第一私钥和第二私钥均是由第一跨链程序中的主密钥所生成的;第一私钥不同于第二私钥。具体的,跨链服务终端还可以对主密钥进行密钥拆分,得到N个管理组件对应的N个的密钥片段;一个管理组件对应一个密钥片段;将N个的密钥片段发送至管理链共识节点,以使管理链共识节点为N个管理组件中的每个管理组件分别配置一个密钥片段;一个管理组件用于对一个密钥片段进行密钥备份。
其中,通过将主密钥拆分为N个密钥片段,进而通过每个管理组件分别备份一个密钥片段,可以保障第一跨链程序在重启后能够基于管理组件备份的密钥片段恢复主密钥,从而 得到第一私钥和第二私钥,避免了第一跨链程序在掉电后密钥的丢失,从而提升跨链服务终端所提供的跨链服务的可靠性。可以理解的是,在基于第一业务启动该第一跨链程序时,该跨链服务终端即可以将主密钥发送至管理共识节点进行备份。比如,管理组件有4个,则可以将主密钥拆分为4个密钥片段:{x1、x2、x3、x4},在将该4个密钥片段发送至管理共识节点后,管理共识节点可以为每个管理组件配置一个密钥片段,如管理组件a被分配到密钥片段x1,如管理组件b被分配到密钥片段x2,如管理组件c被分配到密钥片段x3,如管理组件d被分配到密钥片段x4。
可选的,当可信跨链程序重启时,接收管理链共识节点发送的M个密钥片段;M个密钥片段中的一个密钥片段来自于N个管理组件中的一个管理组件;M为小于或者等于N的正整数;当M达到N对应的密钥数量阈值时,根据M个密钥片段构建得到主密钥。
其中,该密钥数量阈值可以基于N进行确定。比如,该密钥数量阈值可以为N的目标占比。例如,该密钥数量阈值可以为N的3/4,则当N为4时,密钥数量阈值可以为3,当N为8时,密钥数量阈值可以为6。可以理解的是,该密钥数量阈值可以用于指示能够对主密钥进行恢复所需要的最少的密钥片段,该密钥数量阈值在进行密钥拆分时即可以确定,跨链服务终端在获取到大于或等于该密钥数量阈值的密钥片段时,才能够基于获取到的多个密钥片段恢复主密钥,此种对主密钥进行备份的方法也可以称为Shamir(一种密钥共享方法)方法。
其中,第二共识节点在第一业务子链铸造了目标交易映射资源后,第二共识节点可以基于该目标交易资源进行对应的业务处理。可选的,第二共识节点可以将第二地址中的目标交易映射资源转移至第一业务对象在第一业务子链上对应的子链用户地址,进而第二共识节点可以基于第一业务对象的子链用户地址中的目标交易映射资源进行处理,第二共识节点如何对目标交易映射资源进行业务处理可以通过第一跨链构造交易中的资源用途进行指示;第二共识节点也可以不将目标交易映射资源转移至子链用户地址,而是直接基于第二地址中的目标交易映射资源进行处理,此处不做限制。
其中,如上述,第二共识节点在基于目标交易映射资源进行业务处理后,可以对第一业务子链上的资源进行提取和销毁,并将目标交易映射资源返回应用合约链上。可选的,基于第一业务子链上的目标交易映射资源进行业务处理,可以得到第一业务对应的业务处理结果,并且可以将该业务处理结果写入第一业务子链,进一步的,在将第一业务子链上的资源返回至应用合约链时,还可以将得到业务处理结果发送至第一共识节点,以便于第一共识节点可以基于业务处理结果进行相应地响应。例如将业务处理结果发送至第一业务对象的用户终端,以便于第一业务对象明确第一业务的处理结果。又如,第一业务用于指示确定第一业务对象在一定时间内的信用度,则可以根据业务处理结果所指示的信用度对第一业务对象的贷款权限进行调整。
在本申请实施例中,多区块链中可以包括三链体系下的源区块链(即应用合约链和票据链)和管理链,还可以包括基于业务临时生成的用于进行业务处理的业务子链,该业务子链相对于该三链体系为外部区块链,本方案可以通过部署有可信跨链程序的跨链服务终端来实现源区块链(如应用合约链)与链外部(即业务子链)之间的跨链数据传输。也就是,该跨链服务终端可以通过可信跨链程序接收管理链相关联的管理共识节点发送的第一跨链交易事件,将源区块链如应用合约链上的第一地址中处于锁定状态的目标交易资源作为转移交易资源,从而基于该转移交易资源构建对应的跨链构造交易,然后通过可信跨链程序确定业务子链如第一业务子链上的第二地址,并基于第二地址将跨链构造交易发送至与业务子链相关联的共识节点,以实现对目标交易资源的跨链数据传输。由此可以通过跨链服务终端中的可信跨链程序实现对通用业务场景下的业务数据进行链外部的跨链数据传输,并且可信跨链程序处于可信执行环境中,且可以对跨链交易进行验证,由此保障了跨链数据的正确性,有助于在链外部的跨链数据传输转移过程中确保数据跨链的安全性。
进一步的,请参见图13,图13是本申请实施例提供的一种多区块链跨链数据传输方法,如图13所示,方法可以由上述跨链服务终端执行。方法具体可以包括以下步骤S1301-步骤S1306。
S1301、通过第一跨链程序接收管理链共识节点基于第一跨链交易探测信息发送的第一跨链交易事件;第一跨链交易探测信息是由管理链共识节点在探测到合约链上的第一地址中存在与第一业务相关联的第一跨链交易的目标交易资源,且目标交易资源处于锁定状态时所生成的;第一跨链交易是与合约链相关联的第一共识节点基于第一业务对象提交的目标交易资源所确定的,且第一跨链交易用于指示将目标交易资源由合约链转移至第一业务子链。
S1302、将处于锁定状态的目标交易资源作为第一转移交易资源,基于第一跨链交易事件对第一转移交易资源进行验证,且在验证成功时,基于第一转移交易资源构建第一跨链交易对应的第一跨链构造交易。
S1303、通过第一跨链程序确定第一业务子链上的第二地址,基于第二地址将第一跨链构造交易发送至与第一业务子链相关联的第二共识节点,以使第二共识节点通过第二地址在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源;目标交易映射资源与目标交易资源具有相同的资源数据内容。
S1304、通过第一跨链程序接收管理链共识节点基于第二跨链交易探测信息发送的第二跨链交易事件;第二跨链交易探测信息是由管理链共识节点在探测到第一业务子链上的第二地址中存在与第一业务相关联的第二跨链交易的目标交易映射资源,且目标交易映射资源处于销毁状态时所生成的;第二跨链交易是第二共识节点基于第一业务对象提交的目标交易映射资源所确定的,且第二跨链交易用于指示将目标交易映射资源由第一业务子链转回至合约链。
其中,可以理解的是,该第二跨链交易事件用于指示管理共识节点基于第二地址探测到将交易资源由第一业务子链转移至应用合约链的跨链交易,从而可以在通过第一跨链程序接收到该第二跨链交易事件后,执行该第二跨链交易事件所指示的跨链交易(即第二跨链交易)。该第二地址是通过第一跨链程序中的第二私钥所确定,即第一跨链程序可以通过第二私钥在第一业务子链上确定一个对应的第二地址。其中,进而管理共识节点可以通过探测第二地址中的交易映射资源以及交易映射资源的状态,确定是否需要向第一跨链程序发送跨链交易事件。
其中,可以理解的是,管理共识节点在探测到第一业务子链上的第二地址中存在需要进行跨链的交易映射资源时,生成第二跨链交易探测信息,该需要进行跨链的交易映射资源即为被转移至第二地址的目标交易映射资源,并且该目标交易映射资源处于销毁状态。进一步的,管理共识节点可以基于第二跨链交易探测信息确定用于发送给第一跨链程序的第二跨链交易事件,并将第二跨链交易事件发送给第一跨链程序,以便于跨链服务终端中的第一跨链程序可以基于该第二跨链交易事件的指示对目标交易映射资源进行跨链数据传输。
其中,可以理解的是,管理共识节点包括与第二地址相关联的N个管理组件,N为正整数;一个管理组件用于在探测到第二地址中存在处于销毁状态的目标交易映射资源时生成第二跨链交易探测信息中的一个交易探测信息;第一跨链交易探测信息中的一个交易探测信息对应于第一跨链交易事件中的一个交易事件。也就是说,管理共识节点通过N个管理组件对第二地址中的交易资源以及交易资源的状态进行探测,管理组件在探测到第二地址中存在处于销毁状态的目标交易映射资源时生成第二跨链交易探测信息中的一个交易探测信息,以便于管理共识节点基于管理组件探测到的第二跨链交易探测信息向跨链服务终端发送第二跨链交易事件。
其中,可以理解的是,该目标交易映射资源可以为第二共识节点基于上述第一跨链交易所关联的目标交易资源铸造得到的交易映射资源。目标交易映射资源与目标交易资源具有相同的资源数据内容。
其中,应当理解,当第一业务对象需要将第一业务处理链上的目标交易映射资源返回至应用合约链时,第一业务对象可以向第二共识节点发起第二跨链交易,进而第二共识节点将存在于第二地址中的目标交易映射资源调整为销毁状态。可选的,若目标交易映射资源在进行业务处理时,被转移至第一业务对象在第一业务子链上的子链用户地址时,则第一业务对象在向第二共识节点发起第二跨链交易时,第二共识节点可以将子链用户地址中的目标交易映射资源转移至第二地址中,并将目标交易映射资源调整为销毁状态;若目标交易映射资源在进行业务处理时,没有被转移至第一业务对象在第一业务子链上的子链用户地址时,则第一业务对象在向第二共识节点发起第二跨链交易时,第二共识节点直接将第二地址中的目标交易映射资源调整为销毁状态。
可选的,可以理解的是,第二共识节点可以通过调用第一业务子链上部署的第二通用资源跨链桥合约,将第一业务对象需要返回至应用合约链的目标交易映射资源从第一业务子链上的子链用户地址转移至第二地址,并将转移至第二地址的目标交易映射资源确定为销毁状态,以便于后续跨链服务终端中的第一跨链程序可以将目标交易映射资源从第二地址转移至应用合约链。第二地址中的目标交易映射资源处于销毁状态,但是还没有完成销毁,所以管理共识节点可以探测到该处于销毁状态的目标交易映射资源的资源信息。可选的,第二共识节点可以通过调用第二通用资源跨链间接调用资源映射合约(具体为其中的资源销毁方法)将转移至第二地址的目标交易映射资源进行销毁,以使得第二地址中的目标交易映射资源为销毁状态。可以理解的是,本申请相当于通过第二地址作为映射资源的中转地址,便于跨链服务终端中的第一跨链程序基于管理共识节点针对该第二地址的交易探测信息快速检测到跨链交易,从而实现将目标交易映射资源从第一业务子链跨链转移至应用合约链。
其中,可以理解的是,第二共识节点在基于目标交易映射资源进行业务处理后,可以得到第一业务对应的业务处理结果,第二跨链交易还可以指示将业务处理结果由第一业务子链转移至应用合约链。进一步的,第一业务对象在向第二共识节点提交第二跨链交易后,第二共识节点还可以将业务处理结果写入第二地址,并将第二地址中的业务处理结果确定为销毁状态,以便于后续跨链服务终端中的第一跨链程序可以将业务处理结果从第二地址转移至应用合约链,以便于后续第一共识节点可以基于该业务处理结果进行相应的响应。
S1305、将处于销毁状态的目标交易映射资源作为第二转移交易资源,基于第二跨链交易事件对第二转移交易资源进行验证,且在验证成功时,基于第二转移交易资源构建第二跨链交易对应的第二跨链构造交易。
其中,可以理解的是,基于第二跨链交易事件对第二转移交易资源进行验证,可以包括对第二跨链交易事件中的各个交易事件对应的交易探测信息相关联的交易资源进行对比验证。其中,管理共识节点包括与第二地址相关联的N个管理组件,N为正整数;一个管理组件用于在探测到第二地址中存在第二转移交易资源时生成第二跨链交易探测信息中的一个交易探测信息;第二跨链交易探测信息中的一个交易探测信息对应于第二跨链交易事件中的一个交易事件。与第二地址相关联的N个管理组件可以与第一地址相关联的N的管理组件相同,也可以不同,此处不做限制。
具体的,跨链服务终端从接收到的第二跨链交易事件中确定与N个管理组件相关联的交易事件的第二事件数量;第二事件数量是由与N个管理组件相关联的第二跨链交易探测信息中的交易探测信息的信息数量所确定的;第二事件数量小于或者等于N;进一步的,当第二事件数量达到N中的事件数量阈值时,获取与第二事件数量相等的信息数量对应的交易探测信息;进一步的,将获取到的第二跨链交易探测信息中的每个交易探测信息所关联的交易资源作为第二探测资源,将各个第二探测资源进行交易对比,得到第二交易比对结果;进一步的,若第二交易对比结果指示比对成功,则生成用于确定各个第二探测资源均为第二转移交易资源的验证成功指示信息,在基于验证成功指示信息确定验证成功时,基于第二转移交易资源构建第二跨链交易对应的第二跨链构造交易。此处可以参考基于第一跨链交易事 件对第一转移交易资源进行验证的过程,此处不做赘述。
其中,可以理解的是,跨链服务终端可以将第二转移交易资源作为交易参数,进而基于交易参数构建得到第二跨链交易对应的第二跨链构造交易。可选的,跨链服务终端还可以用于将业务处理结果转移至应用合约链上,也就是说,跨链服务终端可以将第二转移交易资源(即处于销毁状态的目标交易映射资源)以及业务处理结果作为交易参数,进而基于交易参数构建得到第二跨链交易对应的第二跨链构造交易。
其中,可以理解的是,跨链服务终端可以通过第一跨链程序中的第一私钥对第二跨链构造交易进行交易签名,得到第二跨链构造交易的交易签名信息;进一步的,在将第二跨链构造交易发送至与应用合约链相关联的第一共识节点时,将第二跨链构造交易的交易签名信息同步发送至第一共识节点,以使第一共识节点基于第一私钥对应的第一公钥对交易签名信息进行交易验签,且在交易验签成功时,得到第二跨链构造交易。
S1306、通过第一跨链程序确定第一地址,基于第一地址将第二跨链构造交易发送至第一共识节点,以使第一共识节点通过第一地址在合约链上对第一转移交易资源进行解锁,得到目标交易资源。
其中,可以理解的是,第一跨链构造交易所指示的将目标交易映射资源转回至合约链(即应用合约链),也就是,第一共识节点在接收到跨链服务终端的第一跨链程序发送的第二跨链构造交易时,对第一地址中处于锁定状态的目标交易资源进行解锁,因此就得到目标交易资源。
其中,可以理解的是,当第一地址中处于锁定状态的目标交易资源解锁后,第一共识节点可以将第一地址中的目标交易资源转回至应用合约链上的合约用户地址。相当于,只是通过将需要进行业务处理的目标交易资源(如业务数据)转移至第一业务子链进行数据处理,在业务处理结束后,转职第一业务子链的目标交易资源可以转回至原本的合约用户地址,由此可以减少对业务处理过程对应用合约链的链上空间的占用,提升业务处理过程的效率。
其中,可以理解的是,第一共识节点在接收到第二跨链构造交易时,还可以通过第一地址在应用合约链上铸造第二跨链构造交易所指示的业务处理结果,由此可以使得第一共识节点可以得到对第一业务对象关联的第一业务的处理结果,达到业务处理的目的,且通过将业务数据转移至三链体系的基础上额外增加的业务子链,能够在一定程度上提升业务处理效率,减少应用合约链上的链上空间。
可选的,可以理解的是,本申请实施例还可以用于实现源区块链所包括的票据链与业务子链之间的跨链数据传输。管理共识节点根据与第二业务对象相关联的第二业务创建的第二业务子链,该第二业务子链可以用于处理第二业务(如电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务等与电子票据相关的业务)。通常来说,票据链上可以包括票据数据,如一些电子发票的发票数据,第二业务对象需要对票据数据进行处理时,可以将需要进行处理的票据数据转移至第二业务子链上进行处理,以此减少对票据链上的空间的浪费,提升业务处理的效率。
此处结合图示对基于多区块链的跨链数据传输处理系统中的数据处理过程进行介绍,此处以源区块链为票据链,业务子处理子链为第二业务子链为例,对票据链与第二业务子链之间的跨链数据传输的过程进行阐述,请参见图14,图14是本申请实施例提供的一种基于多区块链的跨链数据传输处理过程的示意图。首先,管理链701的共识节点中的管理组件702可以对票据链703和第二业务子链704进行探测,具体可探测票据链中的第三地址以及第二业务子链704的中的第四地址,该第三地址即为前述的一个票据链中转地址,该第四地址也相当于第二业务子链上用于与票据链的共识节点进行资源转移的中转地址。该管理链701的共识节点还可以部署有管理组件管理合约,以用于对管理组件进行管理,如可以用于配置管理组件用于探测的区块链地址;该管理链701的共识节点还可以部署有可信跨链程序管理合约,以用于与跨链服务终端705进行数据交互,如可以在第二业务对象请求创建对第二业务 子链704时,通知跨链服务终端705启动用于实现第二业务子链与票据链之间的数据的第二跨链程序。当管理组件702探测到票据链中的第三地址中存在票据资源,且票据资源处于锁定状态,则管理链701的管理共识节点可以向跨链服务终端705发送跨链交易事件,进而跨链服务终端705可以通过第二跨链程序将第三地址中处于锁定状态的票据资源转移至第二业务子链704。当管理组件702探测到第二业务子链704中的第四地址中存在票据映射资源,且票据资源处于销毁状态,则管理链701的管理共识节点可以向跨链服务终端705发送跨链交易事件,进而跨链服务终端705可以通过第二跨链程序将第四地址中处于销毁状态的票据映射资源转回至票据链703。
具体的,可以理解的是,跨链服务终端可以通过第二跨链程序接收管理链共识节点基于第三跨链交易探测信息发送的第三跨链交易事件;第三跨链交易探测信息是由管理链共识节点在探测到票据链上的第三地址中存在与第二业务相关联的第三跨链交易的目标票据资源,且目标票据资源处于锁定状态时所生成的;第三跨链交易是与票据链相关联的第三共识节点基于第二业务对象提交的目标票据资源所确定的,且第三跨链交易用于指示将目标票据资源由票据链转移至第二业务子链;将处于锁定状态的目标票据资源作为第一转移票据资源,基于第三跨链交易事件对第一转移票据资源进行验证,且在验证成功时,基于第一转移票据资源构建第三跨链交易对应的第三跨链构造交易;通过第二跨链程序确定第二业务子链上的第四地址,基于第四地址将第三跨链构造交易发送至与第二业务子链相关联的第四共识节点,以使第四共识节点通过第四地址在第二业务子链上铸造第三跨链构造交易对应的目标票据映射资源;目标票据映射资源与目标票据资源具有相同的资源数据内容。
其中,可以理解的是,在第四共识节点基于目标票据映射资源进行相应地业务处理后,可以将目标票据映射资源转回至票据链中。具体的,跨链服务终端可以通过第二跨链程序接收管理链共识节点基于第四跨链交易探测信息发送的第四跨链交易事件;第四跨链交易探测信息是由管理链共识节点在探测到第二业务子链上的第四地址中存在与第二业务相关联的第四跨链交易的目标票据映射资源,且目标票据映射资源处于销毁状态时所生成的;第四跨链交易是第四共识节点基于第二业务对象提交的目标票据映射资源所确定的,且第四跨链交易用于指示将目标票据映射资源由第二业务子链转回至票据链;进一步的,将处于销毁状态的目标票据映射资源作为第二转移票据资源,基于第四跨链交易事件对第二转移票据资源进行验证,且在验证成功时,基于第二转移票据资源构建第四跨链交易对应的第四跨链构造交易;进一步的,通过第二跨链程序确定第三地址,基于第三地址将第四跨链构造交易发送至第三共识节点,以使第三共识节点通过第三地址在票据链上对第一转移票据资源进行解锁,得到目标票据资源。
可以理解的是,针对票据链与第二业务子链之间的跨链数据传输过程可以参考上述应用合约链与第一业务子链之间的跨链数据传输过程的相关描述,第二业务子链的相关描述可以参考第一业务子链,第二业务子链上的第四地址的相关描述可以参考对应于第一业务子链上的第二地址;票据链对应于应用合约链,票据链上的第三地址的相关描述可以参考应用合约链上的第一地址。区别在于,第一业务与第二业务可以不同,所需转移的资源数据内容也可以不同,应用合约链需要转移的资源为应用合约链上的一些通用资源(如征信数据、税务信息等等),票据链需要转移的资源为票据链上的票据资源(如电子发票的发票编码、开票时间、开票金额等数据)。
在本申请实施例中,多区块链中可以包括三链体系下的源区块链(即应用合约链和票据链)和管理链,还可以包括基于业务临时生成的用于进行业务处理的业务子链,该业务子链相对于该三链体系为外部区块链,本方案可以通过部署有可信跨链程序的跨链服务终端来实现源区块链(如应用合约链)与链外部(即业务子链)之间的跨链数据传输。也就是,该跨链服务终端可以通过可信跨链程序接收管理链相关联的管理共识节点发送的第一跨链交易事件,将源区块链如应用合约链上的第一地址中处于锁定状态的目标交易资源作为转移交易资 源,从而基于该转移交易资源构建对应的跨链构造交易,然后通过可信跨链程序确定业务子链如第一业务子链上的第二地址,并基于第二地址将跨链构造交易发送至与业务子链相关联的共识节点,以实现对目标交易资源的跨链数据传输。由此可以通过跨链服务终端中的可信跨链程序实现对通用业务场景下的业务数据进行链外部的跨链数据传输,并且可信跨链程序处于可信执行环境中,且可以对跨链交易进行验证,由此保障了跨链数据传输的正确性,有助于在链外部的跨链数据传输转移过程中确保跨链数据传输的安全性。
基于上述的描述,本申请实施例提出一种基于多区块链的跨链数据传输方法。此处以源区块链为合约链(即应用合约链),业务子处理子链为第一业务子链为例,对将资源从源区块链转移至业务子链的过程进行阐述。请参见图15,图15是本申请实施例提供的一种基于多区块链的跨链数据传输方法的流程示意图。该多区块链中包括源区块链、业务子链和目标链,源区块链和业务子链之间通过可信跨链程序进行数据交互;源区块链包括合约链,与合约链进行数据交互的可信跨链程序为第一跨链程序;业务子链包括第一业务子链,第一业务子链是与目标链相关联的管理链共识节点根据与第一业务对象相关联的第一业务创建的;该基于多区块链的跨链数据传输方法可以由第一业务子链相关联的第二共识节点执行,该基于多区块链的跨链数据传输方法可以包括以下步骤。
S1501、获取第一跨链程序基于第一业务子链上的第二地址发送的第一跨链构造交易;第一跨链构造交易是第一跨链程序在基于管理链共识节点所发送的第一跨链交易事件对转移交易资源进行验证,且在验证成功时所构建的;转移交易资源为处于锁定状态的目标交易资源;第一跨链交易事件为管理链共识节点基于第一跨链交易探测信息所发送的;第一跨链交易探测信息是由管理链共识节点在探测到合约链上的第一地址中存在与第一业务相关联的第一跨链交易的目标交易资源,且目标交易资源处于锁定状态时所生成的;第一跨链交易是与合约链相关联的第一共识节点基于第一业务对象提交的目标交易资源所确定的,且第一跨链交易用于指示将目标交易资源由合约链转移至第一业务子链。
S1502、通过第二地址确定用于进行资源映射的资源映射合约,调用资源映射合约在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源,将目标交易映射资源写入第二地址;目标交易映射资源与目标交易资源具有相同的资源数据内容。
其中,可以理解的是,步骤S1501-步骤S1502的具体实现方式,可以参见上述实施例中对第二共识节点的描述,即这里将不再继续进行赘述。
在本申请实施例中,多区块链中可以包括三链体系下的源区块链(即应用合约链和票据链)和管理链,还可以包括基于业务临时生成的用于进行业务处理的业务子链,该业务子链相对于该三链体系为外部区块链,本方案可以通过部署有可信跨链程序的跨链服务终端来实现源区块链(如应用合约链)与链外部(即业务子链)之间的跨链数据传输。也就是,该跨链服务终端可以通过可信跨链程序接收管理链相关联的管理共识节点发送的第一跨链交易事件,将源区块链如应用合约链上的第一地址中处于锁定状态的目标交易资源作为转移交易资源,从而基于该转移交易资源构建对应的跨链构造交易,然后通过可信跨链程序确定业务子链如第一业务子链上的第二地址,并基于第二地址将跨链构造交易发送至与业务子链相关联的共识节点,以实现对目标交易资源的跨链数据传输。由此可以通过跨链服务终端中的可信跨链程序实现对通用业务场景下的业务数据进行链外部的跨链数据传输,并且可信跨链程序处于可信执行环境中,且可以对跨链交易进行验证,由此保障了跨链数据的正确性,有助于在链外部的跨链数据传输转移过程中确保跨链数据传输的安全性。
在一些实施例中,跨链处理包括跨链数据传输,该方法由管理链共识节点执行。请参见图16,图16是本申请实施例提供的一种基于多区块链的跨链数据传输方法的流程示意图。该多区块链中包括源区块链、业务子链和目标链,源区块链和业务子链之间通过可信跨链程序进行数据交互;源区块链包括合约链,与合约链进行数据交互的可信跨链程序为第一跨链程序;业务子链包括第一业务子链,第一业务子链是与目标链相关联的管理链共识节点根据 与第一业务对象相关联的第一业务创建的,该基于多区块链的跨链数据传输方法可以由目标链相关联的管理链共识节点执行。此处以源区块链为合约链(即应用合约链),业务子处理子链为第一业务子链为例,对将资源从源区块链转移至业务子链的过程进行阐述。该基于多区块链的跨链数据传输方法可以包括以下步骤。
S1601、在探测到第一地址中存在第一跨链交易的目标交易资源,且目标交易资源处于锁定状态时所生成第一跨链交易探测信息,第一跨链交易与第一业务相关联,第一地址是合约链上的;
S1602、基于第一跨链交易探测信息确定用于发送给第一跨链程序的第一跨链交易事件,将第一跨链交易事件发送给第一跨链程序,以使第一跨链程序基于第一跨链交易事件对转移交易资源进行验证,且在验证成功时,基于转移交易资源构建用于发送业务子链第一跨链交易对应的第一跨链构造交易,第一跨链交易与第一业务子链相关联的第二共识节点相对应;转移交易资源为处于锁定状态的目标交易资源;第二共识节点用于在获取到第一跨链程序基于第一业务子链上的第二地址发送的第一跨链构造交易时,通过第二地址在第一业务子链上铸造第一跨链构造交易对应的目标交易映射资源;目标交易映射资源与目标交易资源具有相同的资源数据内容。
在本申请实施例中,多区块链中可以包括三链体系下的源区块链(即应用合约链和票据链)和管理链,还可以包括基于业务临时生成的用于进行业务处理的业务子链,该业务子链相对于该三链体系为外部区块链,本方案可以通过部署有可信跨链程序的跨链服务终端来实现源区块链(如应用合约链)与链外部(即业务子链)之间的跨链数据传输。也就是,该跨链服务终端可以通过可信跨链程序接收管理链相关联的管理共识节点发送的第一跨链交易事件,将源区块链如应用合约链上的第一地址中处于锁定状态的目标交易资源作为转移交易资源,从而基于该转移交易资源构建对应的跨链构造交易,然后通过可信跨链程序确定业务子链如第一业务子链上的第二地址,并基于第二地址将跨链构造交易发送至与业务子链相关联的共识节点,以实现对目标交易资源的跨链数据传输。由此可以通过跨链服务终端中的可信跨链程序实现对通用业务场景下的业务数据进行链外部的数据跨链,并且可信跨链程序处于可信执行环境中,且可以对跨链交易进行验证,由此保障了跨链数据传输的正确性,有助于在链外部的跨链数据传输转移过程中确保跨链数据传输的安全性。
基于多区块链的数据处理。
请参见图17,图17是本申请实施例提供的一种组建业务子网络的场景示意图。如图17所示的用户30A可以为上述业务对象,即此时,用户30A为具有子网创建需求的实体对象。该用户30A的业务终端30B可以为该业务对象对应的业务节点(例如,上述图1所示的业务网络400a中的业务节点),也可以为与该业务节点相关联的终端设备,这里不做限定。此外,子网创建服务器30C可以为上述子网创建服务器,该子网创建服务器30C与如图3所示的多区块链相关联,本申请实施例涉及的多区块链具体包括管理链网络31对应的管理链31e、票据链网络32对应的票据链32e以及合约链网络33对应的合约链33e,其中,管理链网络31、票据链网络32以及合约链网络33之间彼此独立。可以理解,在管理链网络31中可以部署多个共识节点,例如,这里的多个共识节点具体可以包括共识节点31a、共识节点31b、共识节点31c和共识节点31d,这多个共识节点用于共同维护管理链31e。类似的,在票据链网络32中可以部署多个共识节点,例如,这里的多个共识节点具体可以包括共识节点32a、共识节点32b、共识节点32c和共识节点32d,这多个共识节点用于共同维护票据链32e。类似的,在合约链网络33中可以部署多个共识节点,例如,这里的多个共识节点具体可以包括共识节点33a、共识节点33b、共识节点33c和共识节点33d,这多个共识节点用于共同维护合约链33e。
可以理解,当用户30A希望创建业务子网络来执行临时业务A(该临时业务A可以为 与票据业务相关联的临时业务A1或者与文件业务相关联的临时业务A2)时,可以先基于该临时业务A向管理链31e申请创建业务子网络来执行临时业务A的权限,在获得授权后才可申请创建相应的业务子网络。其中,管理链网络31中的共识节点(即上述管理链共识节点,例如,共识节点31a)可以为该临时业务A配置相应的业务授权凭证(例如,授权码),随后管理链网络31中的共识节点可以将该业务授权凭证作为注册业务授权凭证(例如,注册业务授权凭证301c)写入管理链31e,此外,还可以将该业务授权凭证返回给用户30A的业务终端30B,业务终端30B可以将接收到的业务授权凭证作为子网创建请求凭证(例如,子网创建请求凭证301b)。
进一步,业务终端30B可以基于该子网创建请求凭证301b生成子网创建请求(例如,子网创建请求301a),并可以将该子网创建请求301a发送至子网创建服务器30C。随后,子网创建服务器30C可以向管理链31e进行上述业务子网络的授权验证,具体来说,子网创建服务器30C可以获取该子网创建请求301a中携带的子网创建请求凭证301b,且可以从管理链31e上获取与上述临时业务A相关联的注册业务授权凭证301c,进而可以通过注册业务授权凭证301c对子网创建请求凭证301b进行校验,以得到对应的凭证校验结果(例如,凭证校验结果301d)。
可以理解,在上述凭证校验结果301d指示校验成功时,表示用户30A具备创建业务子网络的权限(可称为子网创建权限),此时,子网创建服务器30C可以从上述票据链网络32中获取一定数量的共识节点作为第一验证节点,且可以从上述合约链网络33中获取一定数量的共识节点作为第二验证节点,本申请实施例对获取的第一验证节点和第二验证节点的数量均不做限定。其中,用户30A可以在向管理链31e申请子网创建权限时,指定组建业务子网络所需的验证节点的节点数量,例如,可以指定需要的验证节点的总数为M(M为大于1的正整数),或者,可以分别指定需要的第一验证节点的数量为M1(M1为正整数)以及需要的第二验证节点的数量为M2(M2为正整数),这里的M=M1+M2,本申请实施例对此不做限定。
如图17所示,假设用户30A指定M1=2,且M2=2,则子网创建服务器30C可以从票据链网络32中随机获取2个共识节点(例如,共识节点32a和共识节点32b)作为第一验证节点,且可以从合约链网络33中随机获取2个共识节点(例如,共识节点33a和共识节点33b)作为第二验证节点,进而可以通过获取到的第一验证节点和第二验证节点组建上述临时业务A对应的业务子网络(例如,业务子网络34),可以理解,该业务子网络34独立于上述管理链网络31、票据链网络32和合约链网络33。此时,该业务子网络34中的验证节点(包括共识节点32a、共识节点32b、共识节点33a和共识节点33b)可用于共同维护业务子链34e。
可以理解,业务子网络34中的每个验证节点在执行临时业务A的同时,仍然会并行处理其原来的业务,例如,共识节点32a可以并行执行临时业务A和票据链32e对应的业务(例如,票据业务);又例如,共识节点33a可以并行执行临时业务A和合约链33e对应的业务(例如,票据衍生业务)。
可以理解,该业务子链34e上存储有与业务子网络34相关联的创世区块信息(即业务子链34e的创世区块所包括的信息,例如包括用户30A在向管理链31e申请子网创建权限时所提交的相关注册信息)。此外,业务子网络34中的验证节点可以从票据链32e和合约链33e上跨链读取与临时业务A相关联的资源(例如,与临时业务A相关联的电子票据或者该电子票据中的票据信息),并可基于得到的资源执行临时业务A,得到临时业务A的临时业务执行结果,随后可以将该临时业务执行结果写入上述业务子链34e。
可以理解,当用户30A发起其他临时业务(例如,临时业务B)时,可以通过类似过程创建新的业务子网络来处理临时业务B,这里不再进行赘述。其中,可以创建一个业务子网络来处理一个临时业务,或者,也可以创建多个业务子网络来处理一个临时业务,本申请实 施例对业务子网络的数量不进行限定。
上述可知,子网创建服务器30C可以在三链架构的基础上,根据业务需要即时构建出业务子网络34,以便独立处理临时业务A,从而可以减少主链空间的浪费,且为用户30A提供数据独立隔离和隐私性。此外,在用户30A获得管理链31e授权的前提下,子网创建服务器30C可以通过复用票据链网络32和合约链网络33中已有的共识节点进行业务子网络的快速搭建,而不需要用户30A自行提供业务子网络的验证节点,从而可以节省额外的验证节点资源开销,同时可以提高业务子网络的创建效率以及安全性。
其中,组建临时业务对应的业务子网络的具体过程和在该业务子网络对应的业务子链上执行临时业务的具体过程,可以参见如下图18-图24所对应的实施例。
进一步的,本申请实施例提供的一种多区块链数据处理方法,该方法可以由管理链共识节点执行。
管理链共识节点接收业务授权请求,业务授权请求是业务对象通过业务终端发送的;管理链共识节点基于业务授权请求,调用管理链上部署的子网管理合约为业务对象配置与临时业务相关联的业务授权凭证;管理链共识节点将业务授权凭证作为注册业务授权凭证写入管理链,且将该业务授权凭证返回至业务终端;业务授权凭证用于生成发送给与所述多区块链相关联的子网创建服务器的子网创建请求;子网创建请求用于指示所述子网创建服务器在获取到管理链上的注册业务授权凭证时,对子网创建请求凭证进行校验,且在校验成功时,将从票据链网络中所获取到的共识节点作为第一验证节点,且将从合约链网络中所获取到的共识节点作为第二验证节点,第一验证节点和所述第二验证节点用于共同组建所述临时业务对应的业务子网络;业务子网络独立于所述管理链网络、票据链网络和合约链网络。
在一些实施例中,业务授权请求包括子网注册配置信息、对象签名信息以及私钥信息对应的公钥信息,子网注册配置信息是业务终端基于所述临时业务生成的,对象签名信息是通过业务对象的私钥信息对子网注册配置信息进行签名得到的。
管理链共识节点在通过业务授权请求中的公钥信息确定所述对象签名信息验签成功时,调用管理链上部署的子网管理合约为业务对象配置与所述临时业务相关联的业务授权凭证。
在一些实施例中,在业务子网络组建完成时,管理链共识节点接收子网启动交易;管理链共识节点基于子网启动交易调用管理链上的子网管理合约,从管理链上获取与业务子网络相关联的创世区块信息;创世区块信息包括业务对象通过业务终端向管理链共识节点提交的子网注册配置信息;管理链共识节点将创世区块信息发送至业务子网络中的验证节点,以使验证节点将创世区块信息写入业务子网络对应的业务子链。
进一步的,多区块链系统包括链外处理设备,链外处理设备在多区块链中确定待进行跨链处理的至少两个区块链;链外处理设备与管理链共识节点协同对所述至少两个区块链进行跨链处理。跨链处理包括数据处理,链外处理设备包括与多区块链相关联的子网创建服务器。如图18所示,该方法可以由子网创建服务器执行,比如,该子网创建服务器可以为上述图17所示的子网创建服务器30C。该方法具体可以包括以下步骤:
步骤S1801,在获取到子网创建请求时,获取子网创建请求中携带的子网创建请求凭证;子网创建请求是业务对象通过业务终端发送的,子网创建请求凭证是由管理链网络中的管理链共识节点接收到业务对象通过业务终端发送的临时业务所确定的;
可以理解的是,本申请实施例中的多区块链包括管理链、票据链和合约链,管理链对应的管理链网络独立于票据链对应的票据链网络,且独立于合约链对应的合约链网络。其中,在不同的业务场景下,可以对应于功能不同的三条区块链,例如,在电子票据相关的业务场景下,上述管理链可以为应用于区块链电子票据系统的管理链(也可称为第一管理链),对应的管理链网络可以为该区块链电子票据系统中的管理链网络(也可称为第一管理链网络);上述票据链可以为应用于区块链电子票据系统的票据链,对应的票据链网络可以为该区块链电子票据系统中的票据链网络;上述合约链可以为应用于区块链电子票据系统的应用 合约链(也可称为第一应用合约链),对应的合约链网络可以为该区块链电子票据系统中的应用合约链网络(也可称为第一应用合约链网络)。又例如,在电子文件相关的业务场景下,上述管理链可以为应用于区块链电子文件系统的管理链(也可称为第二管理链),对应的管理链网络可以为该区块链电子文件系统中的管理链网络(也可称为第二管理链网络);上述票据链可以为应用于区块链电子文件系统的文件链,对应的票据链网络可以为该区块链电子文件系统中的文件链网络;上述合约链可以为应用于区块链电子文件系统的应用合约链(也可称为第二应用合约链),对应的合约链网络可以为该区块链电子文件系统中的应用合约链网络(也可称为第二应用合约链网络)。本申请实施例对具体的业务场景不进行限定。
可以理解的是,当业务对象希望创建新的业务子网络来处理临时业务时,可以先向管理链申请子网创建权限,具体来说,可以由业务终端基于业务对象所请求的临时业务向管理链网络中的管理链共识节点(可以为管理链网络中的任意一个共识节点,例如上述图1所示的共识网络200a中的共识节点11a)发送业务授权请求,以使该管理链共识节点基于该业务授权请求,调用管理链上部署的子网管理合约为业务对象配置与该临时业务相关联的业务授权凭证,进一步,管理链共识节点可以将该业务授权凭证作为注册业务授权凭证写入管理链,且可以将该业务授权凭证返回给业务终端。这里的业务授权凭证具体可以为管理链共识节点为业务对象配置的专属授权码,该授权码可用于指示业务对象获得了管理链共识节点授予的子网创建权限,该授权码可以为由一串数字和/或字母所组成的符号序列,这里对授权码的具体形式不进行限定。其中,上述业务授权请求可以携带有基于临时业务所确定的子网注册配置信息,该子网注册配置信息可以包括与申请创建的业务子网络相关的基本信息、权限信息等。
进一步地,业务终端可以将接收到的业务授权凭证作为子网创建请求凭证,也就是说,该子网创建请求凭证是由上述管理链共识节点接收到业务对象通过业务终端发送的临时业务所确定的。随后业务终端可以基于该子网创建请求凭证生成用于发送给子网创建服务器的子网创建请求。相应的,子网创建服务器在获取到业务对象通过业务终端发送的子网创建请求时,可以从该子网创建请求中获取其携带的子网创建请求凭证,后续可以通过该子网创建请求凭证向管理链进行相应的授权验证,验证成功后,子网创建服务器才会根据子网业务需求来组建业务子网络。
其中,在电子票据相关的业务场景下,上述子网创建服务器可以由税务管理部门运营。可选的,在电子文件相关的业务场景下,上述子网创建服务器可以由文件管理部门(例如,颁发电子证书的权威机构或组织)运营。
可以理解,上述子网管理合约是由管理链对应的内部参与方(如税务管理部门或文件管理部门)通过该管理链上部署的管理合约模板所确定的。通过该子网管理合约可以对个人用户/企业/机构等实体对象的子网创建权限(或业务权限)、子网运行状态、子网注册数据和跨链权限等进行管理,例如可以集中管理多区块链体系下与业务子链相关联的合约模块、业务子链出块规则等。
步骤S1802,通过管理链上的与临时业务相关联的注册业务授权凭证,对子网创建请求凭证进行校验,得到凭证校验结果;
可以理解,在构建一个新的业务子网络(例如,业务子网络C)之前,子网创建服务器会向管理链进行该业务子网络的授权验证,具体的,子网创建服务器可以基于上述子网创建请求向管理链共识节点发送凭证校验交易,例如,可以基于该子网创建请求中携带的子网创建请求凭证,生成用于请求从管理链上获取与该子网创建请求凭证相对应的注册业务授权凭证的凭证校验交易,并将该凭证校验交易发送给管理链共识节点。相应的,管理链共识节点在接收到该凭证校验交易时,可以调用管理链上的子网管理合约,从该管理链上读取与临时业务相关联的注册业务授权凭证。其中,该凭证校验交易可以包括子网管理合约对应的合约调用地址和合约调用名称,将该凭证校验交易写入该合约调用地址和合约调用名称所指示的 管理链上的子网管理合约,通过调用该子网管理合约中的凭证读取方法,可以获取到管理链上存储的注册业务授权凭证。
其中,该注册业务授权凭证可以包括管理链共识节点为业务对象配置的子网注册授权码(例如,授权码D1),类似的,上述子网创建请求凭证可以包括管理链共识节点为业务对象配置的子网构建请求码(例如,授权码D2),通过注册业务授权凭证对子网创建请求凭证进行校验的过程可以为:将子网注册授权码与子网构建请求码进行比对,得到比对结果。可以理解,当该比对结果指示子网注册授权码与子网构建请求码一致时(例如,授权码D1与授权码D2相同),可以确定子网创建请求凭证校验成功,进而可以将校验成功时的子网创建请求凭证作为凭证校验结果。反之,当该比对结果指示子网注册授权码与子网构建请求码不一致时(例如,授权码D1与授权码D2不相同),可以确定子网创建请求凭证校验失败。
可选的,还可以在管理链上对子网创建请求凭证进行校验,具体的,子网创建服务器可以基于子网创建请求向管理链共识节点发送凭证校验交易,该凭证校验交易可以包括子网创建请求凭证中的子网构建请求码(例如,授权码D2)。在管理链共识节点接收到该凭证校验交易时,可以调用管理链上的子网管理合约(如具体可以为子网管理合约中的凭证校验方法),从管理链上读取与临时业务相关联的注册业务授权凭证,进而可以将上述子网构建请求码与注册业务授权凭证中的子网注册授权码(例如,授权码D1)进行比对,得到比对结果,并可以将该得到比对结果返回给子网创建服务器。当该比对结果指示子网注册授权码与子网构建请求码一致时(例如,授权码D1与授权码D2相同),子网创建服务器可以确定子网创建请求凭证校验成功,进而可以将校验成功时的子网创建请求凭证作为凭证校验结果。
步骤S1803,在凭证校验结果指示校验成功时,将从票据链网络中所获取到的共识节点作为第一验证节点,且将从合约链网络中所获取到的共识节点作为第二验证节点,通过第一验证节点和第二验证节点组建临时业务对应的业务子网络;业务子网络独立于管理链网络、票据链网络和合约链网络。
可以理解,在对子网创建请求凭证校验成功后,子网创建服务器可以确定当前的业务对象具备子网创建权限,此时可以通过复用票据链网络中的共识节点和合约链网络中的共识节点来组建临时业务对应的业务子网络。
可以理解的是,上述注册业务授权凭证可以包括业务对象通过业务终端向管理链共识节点提交的子网注册配置信息;该子网注册配置信息包括业务对象针对业务子网络所指定的信息,具体可以包括临时业务对应的业务子网络的网络标识(例如网络名称、网络ID等)、业务子网络所包括的验证节点的节点数量以及业务对象申请的跨链权限。其中,该业务子网络所包括的验证节点的节点数量为M,M为大于1的正整数。这里的跨链权限可以包括用于在票据链与业务子网络对应的业务子链之间进行数据跨链转移的第一跨链转移权限,以及用于在合约链与业务子链之间进行数据跨链转移的第二跨链转移权限。此外,子网注册配置信息还可以包括子链出块规则(例如,交易打包时间、交易打包数量、子链出块时间)等其他与业务子网络相关的信息。
可以理解,通过第一跨链转移权限可以将与临时业务相关联的第一资源由票据链转移至业务子链,且在业务子链上基于该第一资源执行临时业务所得到的临时业务执行结果也可以原路返回至票据链进行存储;同理,通过第二跨链转移权限可以将与临时业务相关联的第二资源由合约链转移至业务子链,且在业务子链上基于该第二资源执行临时业务所得到的临时业务执行结果也可以原路返回至合约链进行存储。可选的,上述业务对象申请的跨链权限也可以包括第一跨链读取权限和第二跨链读取权限,通过第一跨链读取权限可以将与临时业务相关联的第一资源由票据链转移至业务子链,但是后续得到的临时业务执行结果不能写入票据链;类似的,通过第二跨链读取权限可以将与临时业务相关联的第二资源由合约链转移至业务子链,但是后续得到的临时业务执行结果不能写入合约链,这样,可以避免业务子链上的数据对票据链和合约链产生干扰。
具体的,子网创建服务器将从票据链网络中获取到的与第一跨链转移权限相关联的M1个共识节点(即第一共识节点)均作为第一验证节点,且将从合约链网络中所获取到的与第二跨链转移权限相关联的M2个共识节点(即第二共识节点)均作为第二验证节点,进而可以通过获取到的M1个第一验证节点和M2个第二验证节点组建具有网络标识的业务子网络。其中,M1和M2均为正整数,且M=M1+M2。其中,子网创建服务器可以采用随机选取的方式获取第一验证节点和第二验证节点,可选的,这里对获取到的第一验证节点的节点数量和第二验证节点的节点数量均不进行限制,只要满足M=M1+M2即可,此外,第一验证节点的节点数量小于或等于票据链网络所含的共识节点的数量,且第二验证节点的节点数量小于或等于合约链网络所含的共识节点的数量。又或者,可选的,业务对象也可以直接在子网注册配置信息中指定业务子网络所包括的第一验证节点的节点数量(例如,M1个)和第二验证节点的节点数量(例如,M2个),本申请实施例对此不做限定。
为便于理解,请再次参见图17,假设用户30A希望创建一个业务子网络来执行票据统计业务(例如,实时统计开票企业A的开票数量),并向管理链网络31中的管理链共识节点(例如,共识节点31a)提交了相关的子网注册配置信息301e,且在该子网注册配置信息301e中指定了该业务子网络的网络标识(例如,网络标识为X1),且指定了该业务子网络X1所包括的第一验证节点的节点数量为M1=2,该业务子网络X1所包括的第二验证节点的节点数量为M2=2,同时还指定了用户30A申请的跨链权限,则子网创建服务器30C基于子网注册配置信息301e,在票据链网络32(例如票据链网络)中随机选取2个共识节点(例如,共识节点32a、共识节点32b)作为第一验证节点,同时可以在合约链网络33(例如应用合约链网络)中随机选取2个共识节点(例如,共识节点33a、共识节点33b)作为第二验证节点,进而可以通过共识节点32a、共识节点32b、共识节点33a和共识节点33b组建得到业务子网络X1(即业务子网络34)。
可选的,上述子网注册配置信息也可以为独立于注册业务授权凭证的信息,则管理链共识节点可以在接收到凭证校验交易时,将管理链上读取到的注册业务授权凭证和子网注册配置信息一并返回给子网创建服务器。
可以理解,在业务子网络组建成功后,可以对该业务子网络进行启动,以使该业务子网络中的验证节点开始子网共识,并执行上述临时业务。具体的,在业务子网络组建完成时,子网创建服务器可以向业务对象返回子网创建成功响应信息,该子网创建成功响应信息用于指示业务子网络组建成功。进一步,业务对象对应的业务终端接收到该子网创建成功响应信息时,可以基于该子网创建成功响应信息生成用于指示启动上述业务子网络的子网启动指令,并将该子网启动指令发送给子网创建服务器。在子网创建服务器接收到该子网启动指令时,可以基于该子网启动指令向管理链共识节点发送子网启动交易,以使管理链共识节点基于该子网启动交易调用管理链上的子网管理合约(具体可以为子网管理合约中的创世信息读取方法),以便从管理链上获取与业务子网络相关联的创世区块信息。这里的创世区块信息是指业务子链的创世区块(即第一个区块)所包括的信息,其中,该创世区块信息具体可以包括业务对象通过业务终端向管理链共识节点提交的子网注册配置信息,可选的,该创世区块信息还可以包括注册业务授权凭证,业务对象可以通过该注册业务授权凭证与业务子网络进行数据交互。进一步地,子网创建服务器可以将管理链共识节点返回的创世区块信息发送至业务子网络中的验证节点,以使验证节点将创世区块信息写入业务子网络对应的业务子链。
为便于理解,请再次参见图17,在通过上述描述的子网启动过程对图17中的业务子网络34进行启动后,业务子网络34对应的业务子链33e上会存储有对应的创世区块信息(例如,创世区块信息301f),该创世区块信息301f中可包括上述子网注册配置信息301e。可以理解,业务子网络34中的验证节点可以执行上述票据统计业务,例如,业务子网络34中的第一验证节点(例如,共识节点32a)可以基于配置的第一跨链转移权限,从票据链32e上 读取开票企业A所开具的电子票据,并可对开票企业A在某个时间段内的开票数量进行统计,随后可以将最终的统计结果返回给票据链32e,当票据链网络32中的共识节点(例如,共识节点32d)检测到该统计结果大于开票数量阈值时,可以限制开票企业A后续的开票行为。
可以理解的是,在临时业务结束或者发生变更时,与子网创建服务器相关联的业务管理对象(例如,上述税务管理部门或文件管理部门)可以触发子网创建服务器,向业务子网络中的验证节点发送业务终止交易。具体的,在接收到业务管理对象发送的子网关停指令时,子网创建服务器可以基于该子网关停指令向业务子网络中的验证节点发送业务终止交易,以使验证节点在对业务终止交易验证成功时,停止执行上述临时业务,且将业务子链发送至子网创建服务器。其中,上述子网关停指令可以包括用于指示临时业务已经结束的业务结束指令以及用于指示临时业务发生变更(例如,从统计开票企业A的开票数量变更为统计企业B的开票数量)的业务变更指令。随后,子网创建服务器可以对接收到的业务子链进行备份。可以理解,后续在对业务子链的数据提取也结束之后,上述业务子网络中的验证节点各自下线关停(即不再执行上述临时业务,也不再保留业务子链副本),但这些共识节点仍会执行原来在各自的区块链上所执行的业务(例如票据业务或者票据衍生业务)。
为便于理解,请再次参见图17,在上述票据统计业务执行完毕后,与图3中的子网创建服务器30C相关联的业务管理对象(例如,用户30D)会向子网创建服务器30C发送子网关停指令(子网关停指令301g),进而子网创建服务器30C可以通过配置的服务私钥信息对该子网关停指令301g进行签名,从而得到服务签名信息301h,基于该子网关停指令301g和服务签名信息301h生成业务终止交易(例如,业务终止交易301i),随后,可以将该业务终止交易301i发送至业务子网络34中的某个验证节点(例如,共识节点32a),该共识节点32a会通过服务私钥信息对应的服务公钥信息对该业务终止交易301i中的服务签名信息301h进行验签,还可以将该业务终止交易301i广播至业务子网络34中的其他验证节点(例如,共识节点32a、共识节点32b、共识节点33a、共识节点33b)进行验签,即所有验证节点参与对业务终止交易301i进行共识,最终可以基于所有验证节点的验签结果得到业务终止交易301i的交易验证结果。其中,上述服务私钥信息和服务公钥信息可以为子网创建服务器30C通过管理链31e上的对象身份管理合约进行身份注册后得到的,且子网创建服务器30C可以为该服务公钥信息申请对应的公钥证书(可称为第一公钥证书),并可以将该第一公钥证书提交到管理链31e上,这样,业务子网络34中的验证节点就可以从管理链31e上读取到该第一公钥证书,并可以获取该第一公钥证书中的服务公钥信息对上述服务签名信息301h进行验签。
可选的,当得到的验签成功结果的数量大于第一数量阈值时,可以确定业务终止交易301i验证成功。这里对第一数量阈值的取值不做限定,例如,可以取值为所有验证节点的节点数量的2/3。进一步地,在业务终止交易301i验证成功时,业务子网络34中的所有验证节点均停止执行上述票据统计业务,并可以将当前最新的业务子链34e发送给子网创建服务器30C进行备份,其中,业务子链34e上可以存储上述开票企业A在多个指定时间段内的开票数量,这样,后续需要获取与开票企业A相关的票据统计数据的时候,可以从子网创建服务器30C上获取。
可以理解,本申请实施例中的公钥证书,可以指公钥证书体系(PKI,Public Key Infrastructure),在证书体系中,证书是一个公钥拥有者的身份证明,由权威机构进行颁发(CA,Certificate Authority)。基于公钥证书体系可以实现非对称加密和对于信息的数字签名。这里的公钥证书体系可以包括公私钥密码、x509证书、CA证书签发中心等等。
上述可知,本申请实施例可以在多区块链架构的基础上,根据业务需要即时构建出业务子网络,以用于独立处理一些会产生较大数据量或者指定用途的临时业务,这样,由于这些临时业务不在票据链或合约链上运行,其对应的临时业务执行结果由业务子网络对应的业务 子链进行存储和销毁,因此可以减少主链空间的浪费,且可为业务对象提供更高独立性能、数据独立隔离和隐私性更高的业务子链。此外,在业务对象获得管理链授权的前提下,子网创建服务器可以通过复用票据链网络和合约链网络中已有的共识节点进行业务子网络的快速搭建,而不需要业务对象自行提供业务子网络的验证节点,从而可以为业务对象提供高效的子链创建方式,也可节省额外的验证节点资源开销,并提升多区块链系统中共识节点的利用率,同时可以提高业务子网络的创建效率以及安全性。
进一步的,多区块链系统包括链外处理设备,链外处理设备在多区块链中确定待进行跨链处理的至少两个区块链;链外处理设备与管理链共识节点协同对至少两个区块链进行跨链处理。
跨链处理包括数据处理,链外处理设备包括业务终端,业务终端与管理链共识节点协同复用至少一个其他区块链中的共识节点共同组建临时业务对应的业务子网络,至少一个其他区块链包括票据链、合约链中的至少一个。请参见图19,该方法可以由与多区块链相关联的业务终端执行,比如,该业务终端可以为上述图17所示的业务终端30B。该方法具体可以包括以下步骤:
步骤S1901,接收业务对象所请求的临时业务,基于临时业务向管理链网络中的管理链共识节点发送业务授权请求;业务授权请求用于指示管理链共识节点在配置得到与临时业务相关联的业务授权凭证时,将业务授权凭证作为注册业务授权凭证写入管理链;
具体的,业务终端可以接收业务对象所请求的临时业务,进而可以基于该临时业务生成子网注册配置信息,该子网注册配置信息可以包括业务对象在申请创建该临时业务对应的业务子网络时,针对该业务子网络所指定的信息,包括但不限于业务子网络的网络标识(例如网络名称、网络ID等)、业务子网络所包括的验证节点的节点数量、业务对象申请的跨链权限、子链出块规则(例如,交易打包时间、交易打包数量、子链出块时间)等。例如,在上述临时业务为税务审计业务时,业务对象可以在对应的子网注册配置信息中指定该税务审计业务对应的业务子网络的网络标识为X2,且可以指定业务子网络X2需要的验证节点的节点数量为10个(例如,具体包括5个第一验证节点和5个第二验证节点),且向管理链申请第一跨链转移权限(例如,用于从票据链上获取与用户B相关联的票据信息)和第二跨链转移权限(例如,用于从合约链上获取与用户B相关联的退税信息)。这样,后续在成功组建业务子网络X2后,业务子网络X2中的验证节点可以基于获取到的与用户B相关联的票据信息,对与该用户B相关联的退税信息进行审查,即核实用户B是否退税正确。
进一步地,业务终端可以通过业务对象的私钥信息对上述生成的子网注册配置信息进行签名,以得到对象签名信息,进而可以基于子网注册配置信息、对象签名信息以及上述私钥信息对应的公钥信息确定业务授权请求,例如,可以按照指定的封装格式,将上述子网注册配置信息、对象签名信息以及公钥信息封装为具有该封装格式的业务授权请求。随后,业务终端可以将该业务授权请求发送至管理链网络中的管理链共识节点,以使管理链共识节点在通过业务授权请求中的公钥信息确定对象签名信息验签成功时,可以基于从业务授权请求中获取到的子网注册配置信息调用管理链上的子网管理合约,为业务对象配置与临时业务相关联的业务授权凭证。其中,管理链网络中的每个管理链共识节点均可以通过业务授权请求中的公钥信息对上述对象签名信息进行验签,并可以基于所有管理链共识节点的验签结果确定对象签名信息的签名验证结果。可选的,当得到的验签成功结果的数量大于第二数量阈值时,可以确定上述对象签名信息验签成功,这里对第二数量阈值的取值不做限定,例如,可以取值为所有管理链共识节点的节点数量的2/3。
其中,可以理解的是,管理链共识节点可以在上述对象签名信息验签成功时,将从业务授权请求中获取到的子网注册配置信息写入管理链上的子网管理合约,并可以调用该子网管理合约中的业务授权方法,为业务对象配置与临时业务相关联的业务授权凭证,进而可以将该业务授权凭证作为注册业务授权凭证写入管理链。
其中,业务对象的私钥信息和公钥信息可以为业务对象预先通过管理链上的对象身份管理合约进行身份注册后得到的。可选的,管理链共识节点在生成该私钥信息和公钥信息后,可以将该公钥信息写入管理链,这样,上述业务授权请求可以不需要携带该公钥信息,而是在管理链共识节点获取到该业务授权请求时,调用对象身份管理合约从管理链上读取该公钥信息,并可以基于读取到的该公钥信息对该业务授权请求中的对象签名信息进行验签。
步骤S1902,将业务授权凭证作为子网创建请求凭证,基于子网创建请求凭证生成子网创建请求,业务授权凭证是管理链共识节点返回的,子网创建请求用于发送给与多区块链相关联的子网创建服务器。
可以理解,业务终端在接收到上述管理链共识节点返回的业务授权凭证时,可以将该业务授权凭证作为子网创建请求凭证,进而可以基于该子网创建请求凭证生成用于发送给上述子网创建服务器的子网创建请求。其中,可选的,业务终端也可以通过业务对象配置的私钥信息对该子网创建请求凭证进行签名,得到凭证签名信息,进而可以将子网创建请求凭证、凭证签名信息以及该私钥信息对应的公钥信息确定子网创建请求。后续子网创建服务器在接收到该子网创建请求时,可以先通过该子网创建请求中的公钥信息对该凭证签名信息进行验签,在凭证签名信息验签成功时,可以从该子网创建请求中获取其携带的子网创建请求凭证,后续子网创建服务器可以在获取到管理链上的注册业务授权凭证时,对该子网创建请求凭证进行校验,并可以在校验成功时,将从票据链网络中所获取到的共识节点作为第一验证节点,且将从合约链网络中所获取到的共识节点作为第二验证节点,这里的第一验证节点和第二验证节点可用于共同组建临时业务对应的业务子网络。其中,业务子网络独立于管理链网络、票据链网络和合约链网络。子网创建服务器对子网创建请求凭证进行校验以及获取第一验证节点和第二验证节点的具体过程,可以参见上述实施例,这里不再进行赘述。
可以理解的是,在上述业务子网络组建完成时,业务终端可以接收子网创建服务器返回的子网创建成功响应信息,并基于该子网创建成功响应信息向子网创建服务器发送子网启动指令,以使子网创建服务器基于子网启动指令向管理链共识节点发送子网启动交易。其中,该子网启动交易用于指示管理链共识节点调用管理链上的子网管理合约,从管理链上获取与业务子网络相关联的创世区块信息。这里的创世区块信息可以包括业务对象通过业务终端向管理链共识节点提交的子网注册配置信息;该创世区块信息用于写入业务子网络对应的业务子链。其具体过程可以参见上述图18所对应实施例中的步骤S1803,这里不再进行赘述。
可以理解的是,业务终端可以向业务子网络中的验证节点发送用于提取业务子链上最新数据的数据提取请求,其中,在接收到子网创建服务器返回的备份成功消息时(可选条件),验证节点可以先对该数据提取请求进行请求校验,在校验成功时,可以基于该数据提取请求将业务子链上具有最大区块高度的区块中的区块数据作为与业务对象相关联的目标提取数据,并将该目标提取数据返回给业务终端。可以理解,这里的目标提取数据是指业务子链上最新区块的区块数据(例如,在实时票据统计业务中,可以为最终的票据统计结果)。相应的,业务终端可以接收上述验证节点基于数据提取请求返回的目标提取数据。其中,备份成功消息是子网创建服务器在对业务子链备份成功时所确定的。
可以理解,在子网创建服务器成功备份业务子链,且业务终端获取到上述目标提取数据时,表示数据读取期结束,则各验证节点可以删除自身存储的业务子链副本,并各自下线关停,从而避免长期存储执行临时业务所产生的大量数据,且为相关共识节点节省链上空间。
可以理解的是,在业务子网络组建启动后,业务子网络中的各验证节点可以从票据链和合约链上读取与临时业务相关联的资源来执行临时业务。为便于理解,下面将分别对业务子链与票据链之间的跨链交互以及业务子链与合约链之间的跨链交互进行阐述。
在一种实施方式中,票据链网络和业务子网络是由与多区块链相关联的第一跨链中继隔离的,该第一跨链中继可以为独立的中继服务器,也可以为多个中继服务器构成的中继服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络 服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。
可以理解,在业务子网络启动后,业务终端可以基于临时业务向票据链网络中的第一共识节点发送第一跨链资源转出请求,其中,该第一跨链资源转出请求用于指示第一共识节点将与临时业务相关联的第一资源由票据链转移至业务子网络对应的业务子链。在本申请实施例中,第一资源可以为与临时业务相关联的电子票据或该电子票据中部分授权可见的票据信息,也可以为与临时业务相关联的电子文件或该电子文件中部分授权可见的文件信息(例如,电子证书中的证书信息),这里不做限定。
进一步,业务终端可以获取从业务子链上探测到的针对第一跨链资源转出请求所得到的第一资源转移成功响应信息;该第一资源转移成功响应信息用于表征成功将第一资源由票据链转移至业务子链,且业务子链上存在第一资源对应的第一映射资源;该第一映射资源为在票据链上锁定第一资源时,由业务子链上的第一资源映射合约所铸造得到的与第一资源具有相同资源内容的资源。
进一步地,业务终端可以基于上述第一资源转移成功响应信息向业务子网络中的验证节点发送用于执行临时业务的第一业务执行请求,以使验证节点可以基于第一业务执行请求,调用业务子链上的第一临时业务合约获取第一资源映射合约中的第一映射资源,随后基于第一映射资源执行临时业务。
为便于理解,请一并参见图20,图20是本申请实施例提供的一种跨链数据传输的场景示意图。如图20所示,在进行跨链数据传输前,业务对象可以向管理链申请跨链转移第一资源的权限,以获得相应的业务授权凭证,并可将获得的业务授权凭证作为子网创建请求凭证(例如,授权码X),具体实现过程可以参加上述步骤S1901,这里不再赘述。其中,管理链共识节点也会将该业务授权凭证作为注册业务授权凭证(例如,授权码X’)写入管理链。
在上述业务子网络启动后,业务终端可以基于临时业务确定第一跨链转出交易,进而可以基于该第一跨链转出交易和上述子网创建请求凭证(例如,授权码X)生成第一跨链资源转出请求,将该第一跨链资源转出请求发送至第一共识节点。该第一跨链资源转出请求用于指示第一共识节点将与临时业务相关联的第一资源P(例如,票据资产P)由票据链(例如,票据链)转移至业务子链。其中,业务对象还可以在该第一跨链资源转出请求中指定第一资源P跨链的用途(例如,只能读取第一资源P的资源内容,只能用于红冲,可用于转移等)。第一共识节点可以将第一跨链资源转出请求中携带的第一跨链转出交易写入票据链上的第一资源跨链桥合约(例如,第一票据跨链桥合约),第一资源跨链桥合约可以基于第一跨链转出交易向管理链共识节点发送用于校验第一跨链资源转出请求中的子网创建请求凭证的第一转出权限验证请求,以使管理链共识节点基于该第一转出权限验证请求,调用管理链上的子网管理合约从管理链上获取注册业务授权凭证(例如,授权码X’)。进一步,第一共识节点可以通过调用第一资源跨链桥合约来对注册业务授权凭证(例如,授权码X’)和第一跨链资源转出请求中的子网创建请求凭证(例如,授权码X)进行比对,得到第一比对结果。
在第一比对结果指示凭证校验成功(即授权码X’与授权码X一致)时,第一共识节点可以调用票据链上的第一资源合约(例如,票据资产合约),在票据链上锁定第一资源P,此时第一资源P不能在票据链上被操作和改变。此外,在第一跨链转出交易执行完成后,第一资源跨链桥合约还可以生成第一跨链转出交易对应的第一跨链事件,该第一跨链事件可被第一跨链中继所探测到。
在第一跨链中继读取到第一跨链事件时,可以对第一跨链事件和第一跨链转出交易进行验证,并在验证成功时,构建第一跨链转出交易对应的第一跨链转入交易,并可将该第一跨链转入交易发送至业务子网络中与第一跨链转移权限相关联的验证节点(即业务子网络中的 任意第一验证节点)。其中,在构建交易时,可以将第一资源P、第一跨链转移权限等参数填入第一跨链转入交易。随后,第一验证节点可以将该第一跨链转入交易写入业务子链上的第二资源跨链桥合约(例如,第二票据跨链桥合约),即可以基于接收到的第一跨链转入交易的来源(即票据链)调用业务子链上的第二资源跨链桥合约,进而可以在对第一跨链转入交易验证成功(即验证该第一跨链转入交易的来源为票据链)时,基于第一跨链转入交易中的交易参数(例如第一资源P、第一跨链转移权限等),调用第二资源跨链桥合约所指示的第一资源映射合约(例如,票据资产映射合约),在业务子链上铸造与第一资源P具有相同资源内容的第一映射资源WP(例如,票据映射资产WP),并可以为第一映射资源WP赋予相关权限限制或业务使用范围(例如,只能读取第一映射资源WP的部分资源内容,只能用于红冲,只可用于征信等)。可以理解,第一验证节点在接收到第一跨链转入交易时,也可以将该第一跨链转入交易广播至其他验证节点(例如,第二验证节点)进行类似的处理。
进一步地,在成功将第一资源P由票据链转移至业务子链,且业务子链上存在第一资源P对应的第一映射资源WP时,第一验证节点可以生成针对上述第一跨链资源转出请求的第一资源转移成功响应信息,并可将第一资源转移成功响应信息写入业务子链。因此,在业务终端在业务子链上探测到第一资源转移成功响应信息时,可确认第一资源P跨链转移完成。随后,业务终端可以基于第一资源转移成功响应信息向业务子网络中的验证节点发送用于执行临时业务的第一业务执行请求(可携带第一临时业务合约的合约名称和合约地址),进而验证节点可以基于该第一业务执行请求,调用业务子链上的第一临时业务合约(例如,税务审计合约)来获取第一资源映射合约中的第一映射资源WP,且可以基于第一映射资源WP执行该临时业务(例如,税务审计业务),例如,可以在该临时业务中使用第一映射资源WP来进行类似红冲、退税、征信等不同的业务。
类似的,在一种实施方式中,合约链网络和业务子网络是由与多区块链相关联的第二跨链中继隔离的,该第二跨链中继可以为独立的中继服务器,也可以为多个中继服务器构成的中继服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。
可以理解,在业务子网络启动后,业务终端可以基于临时业务向合约链网络中的第二共识节点发送第二跨链资源转出请求,其中,第二跨链资源转出请求用于指示第二共识节点将与临时业务相关联的第二资源由合约链转移至业务子网络对应的业务子链。在本申请实施例中,第二资源可以为与临时业务相关联的通用资产,例如,可以为与临时业务相关联的通用票据关联资产(例如,征信信息、税务信息等)或该通用票据关联资产中部分授权可见的资产关联信息,也可以为与临时业务相关联的通用文件关联资产(例如,资质信息、处方统计结果等)或该通用文件关联资产中部分授权可见的文件关联信息,这里不做限定。
进一步,业务终端可以获取从业务子链上探测到的针对第二跨链资源转出请求所得到的第二资源转移成功响应信息;该第二资源转移成功响应信息用于表征成功将第二资源由合约链转移至业务子链,且业务子链上存在第二资源对应的第二映射资源;该第二映射资源为在合约链上锁定第二资源时,由业务子链上的第二资源映射合约所铸造得到的与第二资源具有相同资源内容的资源。
进一步地,业务终端可以基于第二资源转移成功响应信息向业务子网络中的验证节点发送用于执行临时业务的第二业务执行请求,以使验证节点基于第二业务执行请求,调用业务子链上的第二临时业务合约获取第二资源映射合约中的第二映射资源,随后基于第二映射资源执行临时业务。
为便于理解,请一并参见图21,图21是本申请实施例提供的一种跨链数据传输的场景示意图。如图21所示,在进行跨链数据传输前,业务对象可以向管理链申请跨链转移第二资源的权限,以获得相应的业务授权凭证,并可将获得的业务授权凭证作为子网创建请求凭 证(例如,授权码X),具体实现过程可以参加上述步骤S1901,这里不再赘述。其中,管理链共识节点也会将该业务授权凭证作为注册业务授权凭证(例如,授权码X’)写入管理链。
在上述业务子网络启动后,业务终端可以基于临时业务确定第二跨链转出交易,进而可以基于该第二跨链转出交易和上述子网创建请求凭证(例如,授权码X)生成第二跨链资源转出请求,将该第二跨链资源转出请求发送至第二共识节点。该第二跨链资源转出请求用于指示第二共识节点将与临时业务相关联的第二资源Q(例如,征信信息Q)由合约链(例如,应用合约链)转移至业务子链。其中,业务对象还可以在该第二跨链资源转出请求中指定第二资源Q跨链的用途(例如,只能读取第二资源Q的资源内容,只能用于审查,可用于转移等)。第二共识节点可以将第二跨链资源转出请求中携带的第二跨链转出交易写入合约链上的第三资源跨链桥合约(例如,第一通用跨链桥合约),第三资源跨链桥合约可以基于第二跨链转出交易向管理链共识节点发送用于校验第二跨链资源转出请求中的子网创建请求凭证的第二转出权限验证请求,以使管理链共识节点基于该第二转出权限验证请求,调用管理链上的子网管理合约从管理链上获取注册业务授权凭证(例如,授权码X’)。进一步,第二共识节点可以通过调用第三资源跨链桥合约来对注册业务授权凭证(例如,授权码X’)和第二跨链资源转出请求中的子网创建请求凭证(例如,授权码X)进行比对,得到第二比对结果。
在第二比对结果指示凭证校验成功(即授权码X’与授权码X一致)时,第二共识节点可以调用合约链上的第二资源合约(例如,衍生业务合约),在合约链上锁定第二资源Q,此时第二资源Q不能在合约链上被操作和改变。此外,在第二跨链转出交易执行完成后,第三资源跨链桥合约还可以生成第二跨链转出交易对应的第二跨链事件,该第二跨链事件可被第二跨链中继所探测到。
在第二跨链中继读取到第二跨链事件时,可以对第二跨链事件和第二跨链转出交易进行验证,并在验证成功时,构建第二跨链转出交易对应的第二跨链转入交易,并可将该第二跨链转入交易发送至业务子网络中与第二跨链转移权限相关联的验证节点(即业务子网络中的任意第二验证节点)。其中,在构建交易时,可以将第二资源Q、第二跨链转移权限等参数填入第二跨链转入交易。随后,第二验证节点可以将该第二跨链转入交易写入业务子链上的第四资源跨链桥合约(例如,第二通用跨链桥合约),即可以基于接收到的第二跨链转入交易的来源(即合约链)调用业务子链上的第四资源跨链桥合约,进而可以在对第二跨链转入交易验证成功(即验证该第二跨链转入交易的来源为合约链)时,基于第二跨链转入交易中的交易参数(例如第二资源Q、第二跨链转移权限等),调用第四资源跨链桥合约所指示的第二资源映射合约(例如,通用资产映射合约),在业务子链上铸造与第二资源Q具有相同资源内容的第二映射资源WQ(例如,通用映射资产WQ),并可以为第二映射资源WQ赋予相关权限限制或业务使用范围(例如,只能读取第二映射资源WQ的部分资源内容,只能用于红冲,只可用于征信等)。可以理解,第二验证节点在接收到第二跨链转入交易时,也可以将该第二跨链转入交易广播至其他验证节点(例如,第一验证节点)进行类似的处理。
进一步地,在成功将第二资源Q由合约链转移至业务子链,且业务子链上存在第二资源Q对应的第二映射资源WQ时,第二验证节点可以生成针对上述第二跨链资源转出请求的第二资源转移成功响应信息,并可将第二资源转移成功响应信息写入业务子链。因此,在业务终端在业务子链上探测到第二资源转移成功响应信息时,可确认第二资源Q跨链转移完成。随后,业务终端可以基于第二资源转移成功响应信息向业务子网络中的验证节点发送用于执行临时业务的第二业务执行请求(可携带第二临时业务合约的合约名称和合约地址),进而验证节点可以基于该第二业务执行请求,调用业务子链上的第二临时业务合约(例如,税务审计合约)来获取第二资源映射合约中的第二映射资源WQ,且可以基于第二映射资源WQ执行该临时业务(例如,税务审计业务),例如,可以在该临时业务中使用第 二映射资源WQ来进行类似红冲、退税、征信等不同的业务。
可以理解的是,当上述第一资源P以及第二资源Q均跨链转移完成时,业务子链上存在第一资源P对应的第一映射资源WP以及第二资源Q对应的第二映射资源WQ,则业务终端可以在业务子链上探测到第一资源转移成功响应信息和第二资源转移成功响应信息。业务终端可以基于第一资源转移成功响应信息以及第二资源转移成功响应信息向业务子网络中的验证节点发送用于执行临时业务的第三业务执行请求(可携带第三临时业务合约的合约名称和合约地址),进而验证节点可以基于该第三业务执行请求,调用业务子链上的第三临时业务合约(例如,退税复核合约)来分别调用上述第一临时业务合约和第二临时业务合约,以获取第一资源映射合约中的第一映射资源WP以及第二资源映射合约中的第二映射资源WQ,且可以基于第一映射资源WP以及第二映射资源WQ执行该临时业务(例如,退税复核业务)。
可以理解,本申请实施例还可以支持将执行临时业务所得到的临时业务执行结果(例如,统计电子票据所得到的开票数量、统计电子处方所得到的药品信息等)原路转移回对应的票据链或合约链,其转移过程与上述将相关资源从票据链或合约链转移至业务子链的过程类似,这里不再进行赘述。例如,验证节点可以将临时业务对应的最终结果返回给其它相关链,例如,可以将基于电子票据的审计结果返回给管理链,以使管理共识节点基于该审计结果找到有问题的电子票据,并将其提取出来发送给票据链,以便进行红冲之类的业务(即可以实现不同区块链之间的反向交互)。
由此可见,本申请实施例可以在多区块链架构的基础上,根据业务需要即时构建出业务子网络,以用于独立处理一些会产生较大数据量或者指定用途的临时业务,这样,由于这些临时业务不在票据链或合约链上运行,其对应的临时业务执行结果由业务子网络对应的业务子链进行存储和销毁,因此可以减少主链空间的浪费。此外,在业务对象获得管理链授权的前提下,子网创建服务器可以通过复用票据链网络和合约链网络中已有的共识节点进行业务子网络的快速搭建,而不需要业务对象自行提供业务子网络的验证节点,从而可以节省额外的验证节点资源开销,并提升多区块链系统中共识节点的利用率,同时可以提高业务子网络的创建效率以及安全性。
为便于理解,进一步地,请参见图22,图22是本申请实施例提供的一种区块链电子票据场景下的交互示意图。如图22所示,在区块链电子票据场景下,本申请实施例可以通过管理链授权,通过复用票据链和应用合约链的验证者(即共识节点)进行快速节点搭建,还可以提供业务子链与票据链和应用合约链的资产状态跨链能力。下面将对创建和运行业务子链(例如,子网X对应的业务子链)的主要参与方和它们各自对应的功能进行说明。可以理解,在区块链电子文件场景下的各参与方的交互过程与此类似,因此不再进行赘述。
(1)管理链:该链上部署有子网管理合约,用户(即业务对象)在启动一个新的业务子网络之前,需要从税务管理部门获得授权后,才可以向管理链申请创建业务子网络(例如,网络标识为subnetX的业务子网络,可简称子网X),且可以将相关创世区块信息写入子网X对应的业务子链中。
(2)子网创建服务器(也可称为subnet创建服务):在向管理链获得授权后,用户可以向子网创建服务器请求创建子网X,子网创建服务器由税务管理部门运营,且可以向管理链进行子网X的授权验证,验证成功后,子网创建服务器会根据子网业务需求,在验证者节点网络(包括票据链网络和应用合约链网络)中有条件地随机选择票据链验证者(即票据共识节点)、应用合约链验证者(即应用共识节点)以及通用验证者(即通用共识节点,通常由用户或者外部机构加入构成),组成验证者子网的网络(即业务子网络,例如子网X)。当业务子网络中的验证节点启动后,业务子网络中的验证节点即开始子网共识,例如执行与票据业务相关联的临时业务(比如,统计电子票据的数量)。
(3)票据链:管理票据资产的全生命周期和状态,部署有票据资产合约和第一票据跨 链桥合约,可以和票据资产跨链服务(也可称为票据跨链数据传输服务)进行票据资产的跨链交互。
(4)应用合约链:管理电子票据和税务衍生业务合约相关的数据(即通用资产,例如征信信息、退税信息等),部署有第一通用跨链桥合约(也可称为应用链资产通用跨链桥合约),可以和通用资产跨链服务(也可称为应用链跨链数据传输服务)进行衍生业务相关的通用资产的跨链交互。
(5)票据资产跨链服务(即上述第一跨链中继):用于票据链和业务子链之间的票据资产跨链转移,只有票据链验证者有权限可以访问票据资产跨链服务。因此如果对应的业务子链需要进行票据票资产跨链后进行相关联的业务,则需要在创建业务子网络时指定需要有票据链验证者参与。
(6)通用资产跨链服务(即上述第二跨链中继):用于应用合约链中的一些通用数据和状态与业务子链之间进行跨链转移。只有应用合约链验证者可以访问通用资产跨链服务。因此,如果对应的业务子链需要进行应用合约链上的相关通用资产和状态跨链后进行相关联的业务,则需要在创建业务子网络时指定需要有应用合约链验证者参与。
可以理解,在本申请实施例中,用户需要创建一个业务子链时,只需要向管理链注册子网的基本信息和相关权限信息(如是否需要票据跨链等),而不需要自行提供业务子网络的验证者节点(可简称验证者,即共识节点)。系统的子网创建服务器会根据用户需要(即用户提交的子网注册配置信息),选择当前在票据链网络以及应用合约链网络中存在的验证者节点,为该用户组成业务子网络。
上述可知,由于复用了票据链和应用合约链相关的验证者节点,这些验证者节点本身也有实时同步票据链和应用合约链的链上账本数据,因此通过跨链数据传输服务,可以很便捷地完成票据链和应用合约链到业务子链之间的跨链数据传输。另外,本申请实施例可以为用户提供便捷的子链使用方式,也省去了额外的验证者节点资源开销。
图22中的跨链数据传输服务(包括票据资产跨链服务和通用资产跨链服务)完成了票据链和应用合约链中的相关资产和状态数据到业务子链之间的跨链转移。其中,使用跨链数据传输功能前,首先需要在创建业务子链时将相关的跨链权限申请提交到管理链中,此外,跨链权限也会写入到业务子链的创世区块信息中,需要注意的是,该跨链权限在整个业务子链的生命周期中是不可更改的。可以理解,跨链数据传输服务只有在验证了权限之后才会为业务子链提供跨链服务。
其中,在执行跨链数据传输转移时,跨链数据传输服务需要与业务子链的创世区块中已经部署好的资产跨链桥合约(包括第二票据跨链桥合约和第二通用跨链桥合约),以及票据链上的第一票据跨链桥合约,应用合约链上的第一通用跨链桥合约进行交互。需要注意的是,第二票据跨链桥合约和第二通用跨链桥合约在业务子链中无法自主更新。
可以理解,业务子链在开始运行后作为一个独立的区块链来运行。在临时业务结束或者发生变更情况时,可以由管理部门(例如税务管理部门)触发子网创建服务器,向子网X中发送业务终止交易。该业务终止交易被确认后,子网X不再创建新的区块。此时用户可以提取其业务子链上的最终数据(即目标提取数据,例如临时业务合约的最终数据状态),读取期结束后子网X中的各验证者节点(即子网X中的各验证节点)各自下线关停。此外,子网X的账本数据可以由子网创建服务器进行一次备份,子网X中的各验证者节点不再保留其账本数据副本。
可以理解,本申请实施例中的业务子链的优势点在于:首先,可以简化其启动流程,用户注册后可直接复用票据链和应用合约链对应的共识节点,省去了用户自行提供验证节点的困难以及避免了不安全性。其次,提供了有效的跨链服务和跨链协议,业务子链可以在安全授权下,与票据链和应用合约链上的业务数据进行跨链交互,使用户可以便捷地在业务子链中运行临时业务(例如,发票税务衍生业务)。
由此可见,业务子网络可以让用户在应用合约链之外更加独立的拥有自己的独立业务子链,独立的业务子链可以为用户提供更高独立性能、数据独立隔离和隐私性更高的服务。同时,对于会产生大量临时数据、不重要数据的临时业务,业务子链可以作为临时业务链,其运行的大量账本数据不会侵占应用合约链的主链空间,也能够为用户和管理系统节省了大量成本。
进一步地,请参见图23,图23是本申请实施例提供的一种多区块链数据处理方法的交互流程示意图。如图23所示,该方法可以由与多区块链相关联的业务终端、管理链网络中的管理链共识节点以及与多区块链相关联的子网创建服务器共同执行,其中,该业务终端可以为上述图17所示的业务终端30B,该管理链共识节点可以为上述图17所示的管理链网络31中的任意一个共识节点,例如,共识节点31a,子网创建服务器可以为上述图17所示的子网创建服务器30C。该方法至少可以包括以下步骤:
步骤S2301,业务终端基于业务对象所请求的临时业务向管理链网络中的管理链共识节点发送业务授权请求;
步骤S2302,管理链共识节点基于业务授权请求配置与临时业务相关联的业务授权凭证,将业务授权凭证作为注册业务授权凭证写入管理链,且将业务授权凭证返回给业务终端;
步骤S2303,业务终端将管理链共识节点返回的业务授权凭证作为子网创建请求凭证,基于子网创建请求凭证生成子网创建请求,将子网创建请求发送给子网创建服务器;
步骤S2304,子网创建服务器在获取到业务终端发送的子网创建请求时,获取子网创建请求中携带的子网创建请求凭证;
步骤S2305,子网创建服务器通过管理链上的与临时业务相关联的注册业务授权凭证,对子网创建请求凭证进行校验,得到凭证校验结果;
步骤S2306,在凭证校验结果指示校验成功时,子网创建服务器将从票据链网络中所获取到的共识节点作为第一验证节点,且将从合约链网络中所获取到的共识节点作为第二验证节点,通过第一验证节点和第二验证节点组建临时业务对应的业务子网络。
上述步骤的具体实现过程可以参见上述图4所对应的实施例以及上述图5所对应的实施例,这里不再进行赘述。此外,对采用相同方法的有益效果描述,也不再进行赘述。
为便于理解,进一步地,请参见图24,图24是本申请实施例提供的一种区块链电子票据场景下的系统架构图。如图24所示,本申请实施例中的业务层、路由代理层以及核心共识网络层组成了整个完整区块链业务体系。图24所示的核心链1、核心链2、…以及核心链N分别为不同区域的税局所维护的目标区块链。
可以理解的是,当区块链被用于政务机构(例如,税务系统)或者商业机构的一些场景中,为了提高数据的保密性和安全性,可以采用本申请实施例中的“业务网络—核心共识网络”这一分层区块链结构。
其中,业务层处于见证网络(即业务网络)中,该业务层中的业务节点可以包括电子税局对应的终端设备、企业用户对应的终端设备以及消费用户对应的终端设备。其中,电子税局可以是指税局专网中的地方税局,企业用户可以为公有云中的开票服务商、报销服务商或者零售企业(例如,KA企业,即大型零售客户和重点零售客户企业)等,消费用户可以为私有云中的支付服务商、流转服务商或者零售企业等。其中,该业务网络中的业务节点主要用于执行交易业务,不参与记账共识。可以理解的是,业务节点能够在执行临时业务时,生成用于向中继节点发送的交易数据。
其中,路由代理层中的N个中继节点(即路由节点)可以用于对业务层和核心共识网络层进行网络隔离。其中,每个中继节点可以具有点对点服务(即P2P服务)、路由服务、证书缓存、认证服务。可以理解的是,点对点服务是指在P2P网络中的服务,基于一类特定的网络协议,P2P网络中的网络节点之间不需要一个中心节点来维护网络状态,而是每个节 点通过和相邻节点的广播交互来维护全网的节点状态或者是其相邻节点连接状态。路由服务是节点具有的基本功能,可以用于节点之间的通信。与证书缓存相关联的证书,可以指公钥证书体系(PKI,Public Key Infrastructure),在证书体系中,证书是一个公钥拥有者的身份证明,由权威机构进行颁发(CA,Certificate Authority)。认证服务可以用于验证接收到的数据的数据格式、节点合法性等。可以理解的是,在本申请实施例中,中继节点可以将业务节点生成的交易数据转发至共识节点。
其中,核心共识网络层中的共识节点(即记账节点)可以为税务专网中的可信节点。可以理解的是,每个共识节点均具有打包出块的能力,即可以对中继节点发送的交易数据进行打包出块,以成功写入核心共识网络层中的目标区块链中。
其中,上述核心共识网络层可以包括管理链网络、票据链网络、应用合约链网络,基于此,上述每个目标区块链均可以为包括管理链、票据链以及应用合约链的多区块链。可以理解的是,业务对象可以将通过与业务终端相关联的业务节点,将基于与电子票据相关联的临时业务所确定的业务授权请求(例如,业务授权请求A)发送至核心共识网络层中的管理链共识节点,以便获得相应的业务授权凭证,其中,该管理链共识节点为核心共识网络层包括的管理链网络中的共识节点。进一步,在业务对象获得授权后,可以向某个目标区块链中的管理链申请在上述核心共识网络层中创建业务子网络(例如,业务子网络B),且该业务子网络由票据链网络中的第一验证节点和应用合约链网络中的第二验证节点组成。通过该业务子网络与票据链网络、应用合约链网络之间的跨链交互,可以获取与上述临时业务相关联的资源来执行该临时业务。由此可见,本申请实施例在多区块链架构的基础上组建用于执行临时业务的业务子网络,可以减少主链空间的浪费,此外,通过复用多区块链系统中已有的共识节点来组建业务子网络,可以提高业务子网络的创建效率。
图25是本申请提供的一种基于多区块链的跨链处理装置的结构示意图。
区块链获取模块2501,用于获取多区块链;
区块链确定模块2502,用于在所述多区块链中确定待进行跨链处理的至少两个区块链;
处理模块2503,用于基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理。
在一些实施例中,处理模块2503,用于基于所述管理链将跨链配置项配置至所述至少一个其他区块链;和/或,基于所述管理链将目标交易资源传输至所述至少一个其他区块链;和/或,基于所述管理链复用所述至少一个其他区块链中的共识节点来处理临时业务。
在一些实施例中,处理模块2503,用于基于所述管理链将跨链配置项配置至所述至少一个其他区块链;和/或,基于所述管理链将目标交易资源传输至所述至少一个其他区块链;和/或,基于所述管理链复用所述至少一个其他区块链中的共识节点来处理临时业务。
基于多区块链的跨链处理装置包括基于多区块链的跨链配置装置、基于多区块链的跨链数据传输装置和多区块链数据处理装置。
在一些实施例中,跨链处理包括跨链配置,所述跨链配置用于表示将一个区块链的配置项配置至其他的区块链,图25中的基于多区块链的跨链配置装置1可运行在管理链共识节点上。
基于多区块链的跨链配置装置1可以包括:确定模块11、调用模块12、接收模块13、生成模块14、第一获取模块15和第一配置模块16;
确定模块11,用于执行上述图4实施例中的步骤S401。
调用模块12,用于执行上述图4实施例中的步骤S402。
接收模块13,用于执行上述图4实施例中的步骤S403。
生成模块14,用于执行上述图4实施例中的步骤S404。
第一获取模块15,用于执行上述图4实施例中的步骤S405。
第一配置模块16,用于执行上述图4实施例中的步骤S405。
调用模块12包括:
调用子单元121,用于执行上述图4实施例中的步骤S402。
生成子单元122,用于执行上述图4实施例中的步骤S402。
调用模块12,还用于执行上述图5实施例中的步骤S506。
接收模块13,还用于执行上述图5实施例中的步骤S507。
生成模块14,还用于执行上述图5实施例中的步骤S508。
其中,调用模块12包括:
调用子模块121,用于执行上述图5实施例中的步骤S506。
生成子模块122,用于执行上述图5实施例中的步骤S506。
在一些实施例中,图25中的多区块链跨链数据传输装置2可应用于跨链服务终端中,多区块链跨链数据传输装置2可以包括:事件接收模块21、数据处理模块22和数据发送模块23;
事件接收模块21,用于执行上述图12实施例中的步骤S1201。
数据处理模块22,用于执行上述图12实施例中的步骤S1202。
数据发送模块23,用于执行上述图12实施例中的步骤S1203。
数据处理模块22包括:事件数量确定单元221、交易探测信息获取单元222、交易对比单元223、交易验证单元224;
事件数量确定单元221,用于执行上述图12实施例中的步骤S1202。
交易探测信息获取单元222,用于执行上述图12实施例中的步骤S1202。
交易对比单元223,用于执行上述图12实施例中的步骤S1202。
交易验证单元224,用于执行上述图12实施例中的步骤S1202。
其中,交易验证单元224包括:依赖数据获取单元2241、信息验证单元2242;
依赖数据获取单元2241,用于执行上述图12实施例中的步骤S1202。
信息验证单元2242,用于执行上述图12实施例中的步骤S1202。
信息验证单元2242,还用于执行上述图12实施例中的步骤S1202。
其中,数据发送模块23包括:交易签名单元231、签名发送单元232。
交易签名单元231,用于执行上述图12实施例中的步骤S1203。
签名发送单元232,用于执行上述图12实施例中的步骤S1203。
其中,事件接收模块21,还用于执行上述图13实施例中的步骤S1304。
数据处理模块22,还用于执行上述图13实施例中的步骤S1302。
数据发送模块23,还用于执行上述图13实施例中的步骤S1306。
其中,数据处理模块22包括:事件数量确定单元221、交易探测信息获取单元222、交易对比单元223、交易验证单元224;
事件数量确定单元221,还用于执行上述图13实施例中的步骤S1305。
交易探测信息获取单元222,还用于执行上述图13实施例中的步骤S1305。
交易对比单元223,还用于执行上述图13实施例中的步骤S1305。
交易验证单元224,还用于执行上述图13实施例中的步骤S1305。
接收模块21,还用于执行上述图13实施例中的步骤S1306。
数据处理模块22,还用于执行上述图14实施例中的步骤。
数据处理模块23,还用于执行上述图14实施例中的步骤。
其中,事件接收模块21,还用于执行上述图14实施例中的步骤。其中,数据处理模块22包括:密钥拆分单元225、密钥发送单元226;
密钥拆分单元225,用于执行上述图12实施例中的步骤S1203。
密钥发送单元226,用于执行上述图12实施例中的步骤S1203。
其中,数据处理模块22包括:密钥接收单元227、密钥构建单元228;
密钥接收单元227,用于执行上述图12实施例中的步骤S1203。
密钥构建单元228,用于执行上述图12实施例中的步骤S1203。
图25中的多区块链数据处理装置3可应用于管理链共识节点。多区块链数据处理装置3包括:接收模块31、调用模块32、写入模块33、获取模块34、发送模块35。
接收模块31,用于接收业务对象通过业务终端发送的临时业务的业务授权请求;
调用模块32,用于基于所述业务授权请求,调用所述管理链上部署的子网管理合约为所述业务对象配置与所述临时业务相关联的业务授权凭证;
写入模块33,用于将所述业务授权凭证作为注册业务授权凭证写入所述管理链,且将该业务授权凭证返回至所述业务终端;所述业务授权凭证用于生成发送给与所述多区块链相关联的子网创建服务器的子网创建请求;所述子网创建请求用于指示所述子网创建服务器在获取到所述管理链上的所述注册业务授权凭证时,对所述子网创建请求凭证进行校验,且在校验成功时,将从所述票据链网络中所获取到的共识节点作为第一验证节点,且将从所述合约链网络中所获取到的共识节点作为第二验证节点,所述第一验证节点和所述第二验证节点用于共同组建所述临时业务对应的业务子网络;所述业务子网络独立于所述管理链网络、所述票据链网络和所述合约链网络。
在一些实施例中,调用模块32,用于在通过所述业务授权请求中的所述公钥信息确定所述对象签名信息验签成功时,调用所述管理链上部署的所述子网管理合约为所述业务对象配置与所述临时业务相关联的所述业务授权凭证。
在一些实施例中,接收模块31,用于在所述业务子网络组建完成时,接收子网启动交易。
在一些实施例中,获取模块34,用于基于所述子网启动交易调用所述管理链上的子网管理合约,从所述管理链上获取与所述业务子网络相关联的创世区块信息;所述创世区块信息包括所述业务对象通过所述业务终端向所述管理链共识节点提交的子网注册配置信息;
在一些实施例中,发送模块35,用于将所述创世区块信息发送至所述业务子网络中的验证节点,以使所述验证节点将所述创世区块信息写入所述业务子网络对应的业务子链。
图26是本申请提供的一种基于多区块链的跨链处理装置的结构示意图。所述装置包括:
确定模块2601,用于在所述多区块链中确定待进行跨链处理的至少两个区块链;
处理模块2602,用于与管理链共识节点协同对所述至少两个区块链进行跨链处理。
进一步的,基于多区块链的跨链处理装置包括基于多区块链的跨链配置装置、基于多区块链的跨链数据传输装置和多区块链数据处理装置中的至少一种。
进一步的,请参见图27,图27是本申请提供的一种基于多区块链的跨链配置装置的结构示意图。基于多区块链的跨链配置装置2可运行在跨链中继上,多区块链包括与管理链共识节点相关联的管理链和待进行跨链配置的其他区块链;跨链中继用于隔离管理链对应的管理链网络和其他区块链对应的其他区块链网络,应当理解,基于多区块链的跨链配置装置2可以是运行于跨链中继中的一个计算机程序(包括程序代码),例如该基于多区块链的跨链配置装置2可以为一个应用软件;基于多区块链的跨链配置装置2可以包括:发送模块21、第二获取模块22和第二配置模块23;
发送模块21,用于执行上述图6实施例中的步骤S601。
发送模块21,还用于执行上述图6实施例中的步骤S602。
第二获取模块22,用于执行上述图6实施例中的步骤S603。
第二配置模块23,用于执行上述图6实施例中的步骤S604。
其中,第二配置模块23包括:构建子单元231,用于执行上述图6实施例中的步骤S604。
发送子单元232,用于执行上述图6实施例中的步骤S604。
其中,发送模块21,还用于执行上述图6实施例中的步骤S601。
发送模块21,还用于执行上述图7实施例中的步骤S701。
发送模块21,还用于执行上述图7实施例中的步骤S702。
第二配置模块23,还用于执行上述图7实施例中的步骤S703。
其中,第二配置模块23包括:
构建子单元231,用于执行上述图7实施例中的步骤。
发送子单元232,用于执行上述图7实施例中的步骤。
其中,发送模块21,还用于执行上述图7实施例中的步骤S702。
进一步的,请参见图28,图28是本申请实施例提供的一种基于多区块链的跨链配置系统的示意图。该基于多区块链的跨链配置系统3可以包括管理链共识节点3a、跨链中继3b以及其他共识节点3c;其中,管理链共识节点3a和其他共识节点3c可通过跨链中继进行交互,管理链共识节点3a可以为上述实施例所描述的处于管理链网络中的管理链共识节点,该管理链共识节点可以为上述图1所示的共识网络100a中的任意一个区块链节点;其中,其他共识节点3c可以为上述实施例所描述的处于其他区块链网络中的其他共识节点,该其他共识节点可以为上述图1所示的共识网络200a或者共识网络300中的任意一个区块链节点,这里将不再继续进行赘述;跨链中继3b可以为上述实施例所描述的跨链中继。
进一步的,请参见图29,图29是本申请提供的一种基于多区块链的跨链数据传输装置的结构示意图。多区块链跨链数据传输装置2可应用于与第一业务子链相关联的第二共识节点中,多区块链中包括源区块链、业务子链和目标链,源区块链和业务子链之间通过可信跨链程序进行数据交互;源区块链包括合约链,与合约链进行数据交互的可信跨链程序为第一跨链程序;业务子链包括第一业务子链,第一业务子链是与目标链相关联的目标共识节点根据与第一业务对象相关联的第一业务创建的。应当理解,该多区块链数据处理装置2可以是运行于跨链服务终端中的一个计算机程序(包括程序代码),例如该多区块链数据处理装置2可以为一个应用软件。多区块链数据处理装置2可以包括:跨链构造交易获取模块21、资源铸造模块22;
跨链构造交易获取模块21,用于执行上述图15实施例中的步骤S1501。
资源铸造模块22,用于执行上述图15实施例中的步骤S1502。
进一步的,请参见图30,图30是本申请提供的一种基于多区块链的跨链数据传输装置的结构示意图。多区块链数据处理装置3可应用于目标共识节点上,多区块链中包括源区块链、业务子链和目标链,源区块链和业务子链之间通过可信跨链程序进行数据交互;源区块链包括合约链,与合约链进行数据交互的可信跨链程序为第一跨链程序;业务子链包括第一业务子链,第一业务子链是与目标链相关联的目标共识节点根据与第一业务对象相关联的第一业务创建的。应当理解,该多区块链数据处理装置3可以是运行于跨链服务终端中的一个计算机程序(包括程序代码),例如该多区块链数据处理装置3可以为一个应用软件。多区块链数据处理装置3可以包括:交易探测模块31、事件发送模块32;
交易探测模块31,用于执行上述图16实施例中的步骤S1601。
事件发送模块32,用于执行上述图16实施例中的步骤S1602。
进一步的,请参见图31,图31是本申请实施例提供的一种多区块链数据跨链系统的示意图。该多区块链数据处理系统4可以包括管理链共识节点4a、合约链共识节点4b和票据链共识节点4c和跨链服务终端4d;其中,共识节点4a可以为上述实施例所描述的处于目标链网络中的管理链共识节点,该管理链共识节点可以为上述图1所示的共识网络100a中的 任意一个区块链节点,这里将不再继续进行赘述。其中,共识节点4b可以为上述图2所对应实施例所描述的处于合约链网络中的合约链共识节点,该合约链共识节点可以为上述图1所示的共识网络300a中的任意一个区块链节点,这里将不再继续进行赘述。其中,共识节点4c可以为上述图2所对应实施例所描述的处于第一业务子链中的票据链共识节点,跨链服务终端4d,可以通过可信跨链程序实现跨链数据传输,此处不再赘述。
需要说明的是,对于前述的各个方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某一些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。
请参见图32,是本申请实施例提供的一种多区块链数据处理装置的结构示意图。多区块链数据处理装置3可以包括:凭证获取模块31、凭证校验模块32、子网组建模块33、创建响应模块34、子网启动模块35、创世块生成模块36、子网关停模块37、数据备份模块38;
凭证获取模块31,用于执行上述图18实施例中的步骤S1801。
凭证校验模块32,用于执行上述图18实施例中的步骤S1802。
其中,该凭证校验模块32可以包括:交易发送单元321、凭证比对单元322;
交易发送单元321,用于执行上述图18实施例中的步骤S1802。
凭证比对单元322,用于执行上述图18实施例中的步骤S1802。
子网组建模块33,用于执行上述图18实施例中的步骤S1803。
创建响应模块34,用于执行上述图17实施例中的步骤。
子网启动模块35,用于执行上述图17实施例中的步骤。
创世块生成模块36,用于执行上述图17实施例中的步骤。
子网关停模块37,用于执行上述图17实施例中的步骤。
数据备份模块38,用于执行上述图17实施例中的步骤。
请参见图33,是本申请实施例提供的一种多区块链数据处理装置的结构示意图。多区块链数据处理装置2可以包括:业务授权模块21、请求生成模块22、指令发送模块23、数据提取模块24、第一请求模块25、第一响应模块26、第一执行模块27、第二请求模块28、第二响应模块29、第二执行模块30;
请求生成模块22,用于执行上述图19实施例中的步骤S1901。
其中,该请求生成模块22可以包括:请求确定单元211、请求发送单元212;
请求确定单元211,用于执行上述图19实施例中的步骤S1901。
请求发送单元212,用于执行上述图19实施例中的步骤S1901。请求生成模块22,用于执行上述图19实施例中的步骤S1902。
指令发送模块23,用于执行上述图19实施例中的步骤S1902。
数据提取模块24,用于执行上述图19实施例中的步骤S1902。
第一请求模块25,用于执行上述图19实施例中的步骤S1902。
第一响应模块26,用于执行上述图19实施例中的步骤S1902。
第一执行模块27,用于执行上述图19实施例中的步骤S1902。
第二请求模块28,用于执行上述图19实施例中的步骤S1902。
第二响应模块29,用于执行上述图19实施例中的步骤S1902。
第二执行模块30,用于执行上述图19实施例中的步骤S1902。
进一步的,请参见图34,图34是本申请实施例提供的一种多区块链数据处理系统的结构示意图。该多区块链数据处理系统3可以包括数据处理装置1a和数据处理装置2a。其中,数据处理装置1a可以为上述实施例中的多区块链数据处理装置1,可以理解的是,该多区块链数据处理装置1a可以集成在上述实施例中的子网创建服务器30C,因此,这里将不再进行赘述。其中,数据处理装置2a可以为上述实施例中的多区块链数据处理装置2,可以理解的是,该数据处理装置2a可以集成在上述实施例中的业务终端30B,因此,这里将不再进行赘述。
进一步地,请参见图35,图35是本申请实施例提供的一种计算机设备的结构示意图。该计算机设备1000可以为用户终端,还可以为服务器,这里将不对其进行限制。为便于理解,本申请以计算机设备为服务器为例,该计算机设备1000可以包括:处理器1001,网络接口1004和存储器1005,此外,该计算机设备1000还可以包括:用户接口1003,和至少一个通信总线1002。其中,通信总线1002用于实现这些组件之间的连接通信。其中,用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器,也可以是非不稳定的存储器(non-volatile memory),例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
其中,该计算机设备1000中的网络接口1004还可以提供网络通讯功能。在图12所示的计算机设备1000中,网络接口1004可提供网络通讯功能;而用户接口1003主要用于为用户提供输入的接口;而处理器1001可以用于调用存储器1005中存储的设备控制应用程序,以执行上述实施例中对基于多区块链的跨链处理方法的描述,在此不再赘述。另外,对采用相同方法的有益效果描述,也不再进行赘述。
本申请实施例提供了一种计算机设备,其中,计算机设备包括存储器和处理器;所述存储器与所述处理器相连,所述存储器用于存储计算机程序,所述处理器用于调用所述计算机程序,以使得所述计算机设备执行如上所述的基于多区块链的跨链处理方法。
本申请实施例提供了一种计算机可读存储介质,其中,所述计算机可读存储介质中存储有计算机程序,所述计算机程序适于由处理器加载并执行,以使得具有所述处理器的计算机设备执行如上所述的基于多区块链的跨链处理方法。
本申请实施例提供了一种计算机程序产品,其中,包括计算机程序/指令,所述计算机程序/指令被处理器执行如上所述的基于多区块链的跨链处理方法。

Claims (56)

  1. 一种基于多区块链的跨链处理方法,所述方法由多区块链系统中的管理链共识节点执行,所述多区块链包括所述管理链和至少一个其他区块链,所述管理链共识节点位于管理链中,所述方法包括:
    获取所述多区块链;
    在所述多区块链中确定待进行跨链处理的至少两个区块链;
    基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理。
  2. 根据权利要求1所述的方法,所述基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理,包括以下步骤中的至少一种:
    基于所述管理链将跨链配置项配置至所述至少一个其他区块链;
    基于所述管理链将目标交易资源传输至所述至少一个其他区块链;
    基于所述管理链复用所述至少一个其他区块链中的共识节点来处理临时业务。
  3. 根据权利要求2所述的方法,所述基于所述管理链将跨链配置项配置至所述至少一个其他区块链,包括:
    基于所述管理链,将所述跨链配置项配置值从所述管理链跨链配置至所述至少一个其它区块链,所述至少一个其它区块链包括:票据链、合约链、业务子链中的至少一个。
  4. 根据权利要求3所述的方法,其中,所述管理链对应的管理链网络和其他区块链对应的其他区块链网络通过跨链中继进行隔离;
    所述基于所述管理链,将所述跨链配置项配置值从所述管理链跨链配置至所述至少一个其它区块链,包括:
    在接收到配置交易时,确定配置事务的事务类型,所述配置交易用于跨链配置其他区块链,所述配置交易是管理对象基于所述配置事务发送的;
    在所述配置事务的事务类型为阻塞式事务类型时,调用所述管理链上的链管理配置合约执行所述配置交易,生成所述配置交易对应的第一配置事务标识;所述第一配置事务标识用于指示所述跨链中继与其他共识节点发送第一配置锁获取交易;所述第一配置锁获取交易用于指示所述其他共识节点从所述其他区块链的链配置合约中获取所述阻塞式事务类型对应的阻塞式链配置锁,且通过所述阻塞式链配置锁将所述其他区块链的业务状态配置为第一业务锁定状态;
    接收所述跨链中继发送的第一锁定声明交易;所述第一锁定声明交易是所述跨链中继在探测到所述其他区块链处于所述第一业务锁定状态时所确定的;
    在确定所述第一配置事务标识所对应的所述配置事务的状态为第一事务锁定状态时,生成所述第一锁定声明交易对应的第一事务锁定信息,将所述第一事务锁定信息写入所述管理链,所述配置事务的状态是基于所述第一锁定声明交易确定的;
    在获取到配置修改交易时,获取所述配置修改交易中的第一跨链配置项,通过所述跨链中继将所述第一跨链配置项跨链配置至所述其他区块链,以使所述其他共识节点通过所述阻塞式链配置锁解锁处于所述第一业务锁定状态的其他区块链;所述配置修改交易是所述管理对象基于所述管理链上的所述第一事务锁定信息发送的。
  5. 根据权利要求4所述的方法,其中,在所述其他区块链的数量为多个,且所述配置事务所指示的配置资源属于全局配置资源时,与所述全局配置资源对应的链管理配置合约为所述管理链上的平台配置合约;
    所述调用所述管理链上的链管理配置合约执行所述配置交易,生成所述配置交易对应的第一配置事务标识,包括:
    将所述配置交易写入所述平台配置合约,调用所述平台配置合约中的阻塞式事务配置方法,执行所述配置交易,得到所述配置交易所指示的多个所述其他区块链的链标识;
    基于多个所述其他区块链的标识,生成所述配置交易对应的第一配置事务标识。
  6. 根据权利要求5所述的方法,其中,所述其他区块链包括由所述管理链共识节点通过所述管理链所管理的业务主链和独立于所述业务主链的业务子链;所述业务主链包括独立于所述管理链的票据链和合约链中的一个或者多个;所述业务子链所对应的子链共识网络是由所述票据链对应的票据链网络中的共识节点和所述合约链对应的合约链网络中的共识节点所共同组建的;其中,所述票据链网络独立于所述合约链网络;所述业务子链是由请求执行目标业务的业务对象通过所述管理链共识节点所授权创建的;一个目标业务对应一个业务子链;所述其他区块链包括所述业务子链和所述业务主链。
  7. 根据权利要求4所述的方法,其中,所述其他区块链包括业务子链和由所述管理链共识节点通过所述管理链上的全平台配置合约所管理的票据链和合约链;所述业务子链所对应的子链共识网络是由所述票据链对应的票据链网络中的共识节点和所述合约链对应的合约链网络中的共识节点所共同组建的;其中,所述票据链网络独立于所述合约链网络;所述业务子链是由请求执行目标业务的业务对象通过所述管理链共识节点所授权创建的;一个目标业务对应一个业务子链;在所述其他区块链为所述业务子链、所述票据链或者所述合约链,且所述配置事务所指示的配置资源属于独立配置资源时,与所述独立配置资源对应的链管理配置合约为所述管理链上的其他区块链管理配置合约;所述其他区块链管理配置合约包括用于配置所述票据链的链管理配置合约、用于配置所述合约链的链管理配置合约或者用于配置所述业务子链的子链管理配置合约。
  8. 根据权利要求4所述的方法,其中,在所述其他区块链的数量为多个,且所述配置事务所指示的配置资源属于全局配置资源时,与所述全局配置资源对应的链管理配置合约为所述管理链上的平台配置合约;所述配置交易中包括与所述配置事务相关联的第二跨链配置项;所述方法还包括:
    在所述配置事务的事务类型为非阻塞式事务类型时,调用所述管理链上的所述平台配置合约执行所述配置交易,生成所述配置交易对应的第二配置事务标识;所述第二配置事务标识用于指示所述跨链中继向与所述其他区块链相关联的其他共识节点发送第二配置锁获取交易;所述第二配置锁获取交易用于指示所述其他共识节点从所述其他区块链上的链配置合约中获取所述非阻塞式事务类型对应的非阻塞式链配置锁,且通过所述非阻塞式链配置锁将所述其他区块链的业务状态配置为第二业务锁定状态;
    接收所述跨链中继发送的第二锁定声明交易;所述第二锁定声明交易是所述跨链中继在探测到所述其他区块链处于所述第二业务锁定状态时所确定的;
    在所述配置事务的状态为第二事务锁定状态时,生成所述第二锁定声明交易对应的第二事务锁定信息,将所述第二事务锁定信息写入所述管理链;所述配置事务是所述第二配置事务标识所对应的,所述配置事务的状态是基于所述第二锁定声明交易确定的。
  9. 根据权利要求8所述的方法,其中,所述调用所述管理链上的所述平台配置合约执行所述配置交易,生成所述配置交易对应的第二配置事务标识,包括:
    将带有所述第二跨链配置项的所述配置交易写入所述平台配置合约,调用所述管理链上的平台配置合约中的非阻塞式事务配置方法,执行所述配置交易,得到所述配置交易中所指示的所述其他区块链的链标识和所述第二跨链配置项;
    基于所述其他区块链的链标识以及所述第二跨链配置项,生成所述配置交易对应的第二配置事务标识。
  10. 根据权利要求3所述的方法,所述基于所述管理链将目标交易资源传输至所述至少一个其他区块链,包括:
    基于所述管理链,将所述目标交易资源从源区块链传输至目标区块链,所述源区块链包括合约链、票据链、业务子链中的至少一个,所述目标区块链包括所述管理链。
  11. 根据权利要求10所述的方法,其中,所述源区块链和业务子链之间通过可信跨链程 序进行数据交互;与所述合约链进行数据交互的可信跨链程序为第一跨链程序;所述业务子链包括第一业务子链,所述第一业务子链是与所述管理链共识节点根据与第一业务对象相关联的第一业务创建的;
    所述基于所述管理链将目标交易资源传输至所述至少一个其他区块链,包括:
    在探测到第一地址中存在第一跨链交易的目标交易资源,且所述目标交易资源处于锁定状态时,生成第一跨链交易探测信息,所述第一跨链交易与所述第一业务相关联,所述第一地址是所述票据链上的;
    基于所述第一跨链交易探测信息确定第一跨链交易事件,将所述第一跨链交易事件发送给所述第一跨链程序,以使所述第一跨链程序基于所述第一跨链交易事件对转移交易资源进行验证,且在验证成功时,基于所述转移交易资源构建用于发送所述第一跨链交易对应的第一跨链构造交易,所述第一跨链交易与所述第一业务子链相关联的第二共识节点相对应;所述转移交易资源为处于锁定状态的目标交易资源;所述第二共识节点用于在获取到第一跨链构造交易时,通过所第二地址在所述第一业务子链上铸造目标交易映射资源,所述第一跨链构造交易是所述第一跨链程序基于所述第一业务子链上的第二地址发送的,所述目标交易映射资源是所述第一跨链构造交易对应的;所述目标交易映射资源与所述目标交易资源具有相同的资源数据内容。
  12. 根据权利要求3所述的方法,所述基于所述管理链复用所述至少一个其他区块链中的共识节点来处理临时业务,包括:
    基于所述管理链,复用所述至少一个其他区块链中的共识节点共同组建所述临时业务对应的业务子网络,所述至少一个其他区块链包括票据链、合约链中的至少一个,所述业务子网络用于处理所述临时业务。
  13. 根据权利要求12所述的方法,其中,所述管理链对应的管理链网络独立于所述票据链对应的票据链网络,且独立于所述合约链对应的合约链网络;
    所述基于所述管理链,复用所述至少一个其他区块链中的共识节点共同组建所述临时业务对应的业务子网络,包括:
    接收临时业务对应的业务授权请求,所述业务授权请求是业务对象通过业务终端发送的;
    基于所述业务授权请求,调用所述管理链上部署的子网管理合约为所述业务对象配置业务授权凭证,所述业务授权凭证是所述临时业务相关联的凭证;
    将所述业务授权凭证作为注册业务授权凭证写入所述管理链,且将该业务授权凭证返回至所述业务终端;所述业务授权凭证用于生成发送给与所述多区块链相关联的子网创建服务器的子网创建请求;所述子网创建请求用于指示所述子网创建服务器在获取到所述管理链上的所述注册业务授权凭证时,对所述子网创建请求凭证进行校验,且在校验成功时,将从所述票据链网络中所获取到的共识节点作为第一验证节点,且将从所述合约链网络中所获取到的共识节点作为第二验证节点,所述第一验证节点和所述第二验证节点用于共同组建所述临时业务对应的业务子网络;所述业务子网络独立于所述管理链网络、所述票据链网络和所述合约链网络。
  14. 根据权利要求13所述的方法,其特征在于,所述业务授权请求包括子网注册配置信息、对象签名信息以及私钥信息对应的公钥信息,所述子网注册配置信息是所述业务终端基于所述临时业务生成的,所述对象签名信息是通过所述业务对象的私钥信息对所述子网注册配置信息进行签名得到的;
    所述基于所述业务授权请求,调用所述管理链上部署的子网管理合约为所述业务对象配置业务授权凭证,包括:
    在通过所述业务授权请求中的所述公钥信息确定所述对象签名信息验签成功时,调用所述子网管理合约为所述业务对象配置所述业务授权凭证。
  15. 根据权利要求14所述的方法,其特征在于,还包括:
    在所述业务子网络组建完成时,接收子网启动交易;
    基于所述子网启动交易调用所述管理链上的子网管理合约,从所述管理链上获取与所述业务子网络相关联的创世区块信息;所述创世区块信息包括所述业务对象通过所述业务终端向所述管理链共识节点提交的子网注册配置信息;
    将所述创世区块信息发送至所述业务子网络中的验证节点,以使所述验证节点将所述创世区块信息写入所述业务子网络对应的业务子链。
  16. 一种基于多区块链的跨链处理方法,所述方法由多区块链系统中的链外处理设备执行,所述方法包括:
    在多区块链中确定待进行跨链处理的至少两个区块链;
    与管理链共识节点协同对所述至少两个区块链进行跨链处理;
    其中,所述多区块链包括所述管理链和至少一个其他区块链,所述管理链共识节点位于管理链中。
  17. 根据权利要求16所述的方法,所述与管理链共识节点协同对所述至少两个区块链进行跨链处理,包括以下步骤中的至少一种:
    与所述管理链共识节点协同将跨链配置项配置至所述至少一个其他区块链;
    与所述管理链共识节点协同将目标交易资源传输至所述至少一个其他区块链;
    与所述管理链共识节点协同复用所述至少一个其他区块链中的共识节点来处理临时业务。
  18. 根据权利要求17所述的方法,所述与所述管理链共识节点协同将跨链配置项配置至所述至少一个其他区块链,包括:
    与所述管理链共识节点协同将所述跨链配置项配置值从所述管理链跨链配置至所述至少一个其它区块链,所述至少一个其它区块链包括:票据链、合约链、业务子链中的至少一个。
  19. 根据权利要求18所述的方法,其中,所述链外处理设备包括跨链中继;
    所述与所述管理链共识节点协同将所述跨链配置项配置值从所述管理链跨链配置至所述至少一个其它区块链,包括:
    在探测到第一配置事务标识时,向所述其他区块链网络中的其他共识节点发送第一配置锁获取交易;所述第一配置事务标识是所述管理链上的配置交易对应的,所述第一配置事务标识是所述管理链网络中的管理链共识节点在所述配置交易中的配置事务的事务类型为阻塞式事务类型时,调用所述管理链上的链管理配置合约执行所述配置交易所生成的,所述配置交易是由请求执行所述配置事务的管理对象发送的;所述第一配置锁获取交易用于指示所述其他共识节点从所述其他区块链上的链配置合约中获取所述阻塞式事务类型对应的阻塞式链配置锁,且通过所述阻塞式链配置锁将所述其他区块链的业务状态配置为第一业务锁定状态;
    在探测到所述其他区块链处于所述第一业务锁定状态时,向所述管理链共识节点发送第一锁定声明交易;所述第一锁定声明交易用于指示所述管理链共识节点在基于所述第一锁定声明交易确定所述配置事务标识所对应的所述配置事务的状态为第一事务锁定状态时,生成用于写入所述管理链的所述第一锁定声明交易对应的第一事务锁定信息;
    在探测到所述管理链上的配置修改交易时,获取所述配置修改交易中的第一跨链配置项;所述配置修改交易是由所述管理对象基于所述管理链上的所述第一事务锁定信息所发送的;
    将所述第一跨链配置项跨链配置至所述其他区块链,以使所述其他共识节点通过所述阻塞式链配置锁解锁处于所述第一业务锁定状态的其他区块链。
  20. 根据权利要求19所述的方法,其中,所述将所述第一跨链配置项跨链配置至所述其 他区块链,包括:
    基于所述第一跨链配置项构建第一释放锁交易;所述第一释放锁交易用于指示所述其他共识节点在将所述第一跨链配置项写入链配置合约时,调用所述链配置合约中的锁释放方法对所述阻塞式链配置锁进行释放,且将所述其他区块链的业务状态由所述第一业务锁定状态更改为业务解锁状态;
    将所述第一释放锁交易发送至所述其他共识节点。
  21. 根据权利要求19所述的方法,其中,所述方法还包括:
    对探测到处于所述第一业务锁定状态的所述其他区块链的链锁定时长进行累计,在累计到所述链锁定时长达到累计锁定时长阈值时,则向所述其他共识节点发送超时释放锁交易,所述累计锁定时长阈值是所述阻塞式链配置锁对应的,所述超时释放锁交易用于指示所述目标共识节点调用所述其他区块链上的所述链配置合约中的锁释放方法对所述阻塞式链配置锁进行释放,且将所述其他区块链的业务状态由所述第一业务锁定状态更改为业务解锁状态。
  22. 根据权利要求19所述的方法,其中,所述方法还包括:
    在探测到所述其他区块链未处于所述第一业务锁定状态时,向所述管理链共识节点发送第一锁定失败交易,并向所述其他共识节点发送第一锁定失败释放锁交易,所述第一锁定失败释放锁交易用于指示所述其他共识节点调用所述其他区块链上的所述链配置合约中的锁释放方法释放所述阻塞式链配置锁。
  23. 根据权利要求19所述的方法,其中,所述配置交易中包括与所述配置事务相关联的第二跨链配置项;所述方法还包括:
    在探测到管理链上的配置交易对应的第二配置事务标识时,向所述其他区块链网络中的其他共识节点发送第二配置锁获取交易,所述第二配置事务标识是所述第一链网络中的管理链共识节点在所述配置交易中的配置事务的事务类型为非阻塞式事务类型时,调用所述第一链上的管理配置合约执行所述配置交易所生成的,所述配置交易是由请求执行所述配置事务的管理对象发送的;所述第二配置锁获取交易用于指示所述其他共识节点从所述其他区块链上的链配置合约中获取所述非阻塞式事务类型对应的非阻塞式链配置锁,且通过所述非阻塞式链配置锁将所述其他区块链的业务状态配置为第二业务锁定状态;
    在探测到所述其他区块链处于所述第二业务锁定状态时,向所述管理链共识节点发送第二锁定声明交易;所述第二锁定声明交易用于指示所述管理链共识节点在基于所述第二锁定声明交易确定所述配置事务标识所对应的所述配置事务的状态为第二事务锁定状态时,生成用于写入所述管理链的所述第二锁定声明交易对应的第二事务锁定信息;
    将所述第二跨链配置项跨链配置至所述其他区块链,以使所述其他共识节点通过所述非阻塞式链配置锁解锁处于所述第二业务锁定状态的其他区块链。
  24. 根据权利要求23所述的方法,其中,所述将所述第二跨链配置项跨链配置至所述其他区块链,包括:
    基于所述第二跨链配置项构建第二释放锁交易,将所述第二释放锁交易发送至其他共识节点;所述第二释放锁交易用于指示所述其他区块链中的其他共识节点在将所述第二跨链配置项写入链配置合约时,调用所述其他区块链上的所述链配置合约中的锁释放方法对所述非阻塞式链配置锁进行释放,且将所述其他区块链的业务状态由所述第二业务锁定状态更改为业务解锁状态。
  25. 根据权利要求23所述的方法,其中,所述第二配置锁获取交易还用于指示所述其他共识节点从所述其他区块链上的链配置合约中获取块缓冲高度,所述块缓冲高度用于表征在通过所述非阻塞式链配置锁将所述其他区块链的业务状态配置为第二业务锁定状态之前,所述其他区块链上所得到的区块的最大间隔高度。
  26. 根据权利要求23所述的方法,其中,所述方法还包括:
    在探测到所述其他区块链未处于所述第二业务锁定状态时,向所述管理链共识节点发送 第二锁定失败交易,并向所述其他共识节点发送第二锁定失败释放锁交易,所述第二锁定失败释放锁交易用于指示所述其他共识节点调用所述其他区块链上的所述链配置合约中的锁释放方法对所述非阻塞式链配置锁进行释放。
  27. 根据权利要求17所述的方法,所述与所述管理链共识节点协同将目标交易资源传输至所述至少一个其他区块链,包括:
    与所述管理链共识节点协同将目标交易资源从源区块链传输至目标区块链,所述源区块链包括合约链、票据链、业务子链中的至少一个,所述目标区块链包括管理链。
  28. 根据权利要求27所述的方法,其中,所述链外处理设备包括部署有可信跨链程序的跨链服务终端,所述跨链服务终端用于隔离所述多区块链中的源区块链和业务子链;
    所述与所述管理链共识节点协同将目标交易资源从源区块链传输至目标区块链,包括:
    通过第一跨链程序接收第一跨链交易事件;所述第一跨链交易事件是管理链共识节点基于第一跨链交易探测信息发送的,所述第一跨链交易探测信息是由所述管理链共识节点在探测到合约链上的第一地址中存在与第一业务相关联的第一跨链交易的目标交易资源,且所述目标交易资源处于锁定状态时所生成的;所述第一跨链交易是与所述合约链相关联的第一共识节点基于所述第一业务对象提交的所述目标交易资源所确定的,且所述第一跨链交易用于指示将所述目标交易资源由所述合约链转移至所述第一业务子链;
    将处于锁定状态的目标交易资源作为第一转移交易资源,基于所述第一跨链交易事件对所述第一转移交易资源进行验证,且在验证成功时,基于所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易;
    通过所述第一跨链程序确定所述第一业务子链上的第二地址,基于所述第二地址将所述第一跨链构造交易发送至与所述第一业务子链相关联的第二共识节点,以使所述第二共识节点通过所述第二地址在所述第一业务子链上铸造所述第一跨链构造交易对应的目标交易映射资源;所述目标交易映射资源与所述目标交易资源具有相同的资源数据内容。
  29. 根据权利要求28所述方法,其中,所述管理链共识节点包括与所述第一地址相关联的N个管理组件,N为正整数;一个管理组件用于在探测到所述第一地址中存在所述第一转移交易资源时生成所述第一跨链交易探测信息中的一个交易探测信息;所述第一跨链交易探测信息中的一个交易探测信息对应于所述第一跨链交易事件中的一个交易事件;
    所述基于所述第一跨链交易事件对所述第一转移交易资源进行验证,且在验证成功时,基于所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易,包括:
    从接收到的所述第一跨链交易事件中确定与第一事件数量;所述第一事件数量是由与N个管理组件相关联的所述第一跨链交易探测信息中的交易探测信息的信息数量所确定的;所述第一事件数量小于或者等于N;
    当所述第一事件数量达到N中的事件数量阈值时,获取与所述第一事件数量相等的信息数量对应的交易探测信息;
    将获取到的所述第一跨链交易探测信息中的每个交易探测信息所关联的交易资源作为第一探测资源,将各个第一探测资源进行交易对比,得到第一交易比对结果;
    若所述第一交易对比结果指示比对成功,则生成用于确定所述各个第一探测资源均为所述第一转移交易资源的验证成功指示信息,在基于所述验证成功指示信息确定验证成功时,基于所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易。
  30. 根据权利要求29所述的方法,其中,所述基于所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易,包括:
    从所述合约链上获取所述第一转移交易资源对应的依赖数据信息;
    对所述依赖数据信息进行信息验证,且在信息验证成功时,基于所述依赖数据信息和所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易。
  31. 根据权利要求30所述方法,其中,所述合约链上部署有用于与所述第一跨链程序进 行数据交互的第一通用资源跨链桥合约;所述第一通用资源跨链桥合约用于指示所述第一共识节点在将所述目标交易资源转入所述第一地址时,指定所述第一跨链交易所对应的目标交易资源的资源用途;所述依赖数据信息包括所述资源用途;
    所述基于所述依赖数据信息和所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易,包括:
    将所述资源用途和所述第一转移交易资源作为交易参数,基于所述交易参数构建得到所述第一跨链交易对应的第一跨链构造交易。
  32. 根据权利要求28所述方法,其中,所述第二地址中部署有用于调用所述第一业务子链上的资源映射合约的合约名称和合约地址;所述第二共识节点用于在获取到所述第一跨链构造交易时,通过所述第二地址中的所述合约名称和所述合约地址调用所述资源映射合约,在所述第一业务子链上铸造所述第一跨链构造交易对应的所述目标交易映射资源。
  33. 根据权利要求28所述的方法,其中,所述第二地址是由所述第一跨链程序中的第二私钥所确定的;所述第二私钥是由所述第一跨链程序中的主密钥所生成的;所述主密钥是由所述第一跨链程序所处的可信执行环境所确定的;所述方法还包括:
    通过所述第二私钥对所述第一跨链构造交易进行交易签名,得到所述第一跨链构造交易的交易签名信息,所述第二私钥是所述第一跨链程序中的;
    在将所述第一跨链构造交易发送至与所述第一业务子链相关联的第二共识节点时,将所述第一跨链构造交易的交易签名信息同步发送至所述第二共识节点,以使所述第二共识节点基于所述第二私钥对应的第二公钥对所述交易签名信息进行交易验签,且在交易验签成功时,得到所述第一跨链构造交易。
  34. 根据权利要求28所述方法,其中,所述方法还包括:
    通过所述第一跨链程序接收第二跨链交易事件,所述第二跨链交易事件是所述管理链共识节点基于第二跨链交易探测信息发送的;所述第二跨链交易探测信息是由所述管理链共识节点在探测到所述第一业务子链上的第二地址中存在与所述第一业务相关联的第二跨链交易的目标交易映射资源,且所述目标交易映射资源处于销毁状态时所生成的;所述第二跨链交易是所述第二共识节点基于所述第一业务对象提交的所述目标交易映射资源所确定的,且所述第二跨链交易用于指示将所述目标交易映射资源由所述第一业务子链转回至所述合约链;
    将处于销毁状态的目标交易映射资源作为第二转移交易资源,基于所述第二跨链交易事件对所述第二转移交易资源进行验证,且在验证成功时,基于所述第二转移交易资源构建所述第二跨链交易对应的第二跨链构造交易;
    通过所述第一跨链程序确定所述第一地址,基于所述第一地址将所述第二跨链构造交易发送至所述第一共识节点,以使所述第一共识节点通过所述第一地址在所述合约链上对所述第一转移交易资源进行解锁,得到所述目标交易资源。
  35. 根据权利要求28所述方法,其中,所述管理链共识节点包括与所述第二地址相关联的N个管理组件,N为正整数;一个管理组件用于在探测到所述第二地址中存在所述第二转移交易资源时生成所述第二跨链交易探测信息中的一个交易探测信息;所述第二跨链交易探测信息中的一个交易探测信息对应于所述第二跨链交易事件中的一个交易事件;
    所述基于所述第一跨链交易事件对所述第一转移交易资源进行验证,且在验证成功时,基于所述第一转移交易资源构建所述第一跨链交易对应的第一跨链构造交易,包括:
    从接收到的所述第二跨链交易事件中确定与所述N个管理组件相关联的交易事件的第二事件数量;所述第二事件数量是由与N个管理组件相关联的所述第二跨链交易探测信息中的交易探测信息的信息数量所确定的;所述第二事件数量小于或者等于所述N;
    当所述第二事件数量达到所述N中的所述事件数量阈值时,获取与所述第二事件数量相等的信息数量对应的交易探测信息;
    将获取到的所述第二跨链交易探测信息中的每个交易探测信息所关联的交易资源作为第 二探测资源,将各个第二探测资源进行交易对比,得到第二交易比对结果;
    若所述第二交易对比结果指示比对成功,则生成用于确定所述各个第二探测资源均为所述第二转移交易资源的验证成功指示信息,在基于所述验证成功指示信息确定验证成功时,基于所述第二转移交易资源构建所述第二跨链交易对应的第二跨链构造交易。
  36. 根据权利要求28所述的方法,其中,所述源区块链包括票据链;与所述票据链进行数据交互的可信跨链程序为第二跨链程序;所述业务子链包括第二业务子链,所述第二业务子链是所述管理链共识节点根据与第二业务对象相关联的第二业务创建的;所述方法还包括:
    通过所述第二跨链程序接收第三跨链交易事件,所述第三跨链交易事件是所述管理链共识节点基于第三跨链交易探测信息发送的;所述第三跨链交易探测信息是由所述管理链共识节点在探测到所述票据链上的第三地址中存在与所述第二业务相关联的第三跨链交易的目标票据资源,且所述目标票据资源处于锁定状态时所生成的;所述第三跨链交易是与所述票据链相关联的第三共识节点基于所述第二业务对象提交的所述目标票据资源所确定的,且所述第三跨链交易用于指示将所述目标票据资源由所述票据链转移至所述第二业务子链;
    将处于锁定状态的目标票据资源作为第一转移票据资源,基于所述第三跨链交易事件对所述第一转移票据资源进行验证,且在验证成功时,基于所述第一转移票据资源构建所述第三跨链交易对应的第三跨链构造交易;
    通过所述第二跨链程序确定所述第二业务子链上的第四地址,基于所述第四地址将所述第三跨链构造交易发送至与所述第二业务子链相关联的第四共识节点,以使所述第四共识节点通过所述第四地址在所述第二业务子链上铸造所述第三跨链构造交易对应的目标票据映射资源;所述目标票据映射资源与所述目标票据资源具有相同的资源数据内容。
  37. 根据权利要求36所述方法,其中,所述方法还包括:
    通过所述第二跨链程序接收第四跨链交易事件,所述第四跨链交易事件是所述管理链共识节点基于第四跨链交易探测信息发送的;所述第四跨链交易探测信息是由所述管理链共识节点在探测到所述第二业务子链上的第四地址中存在与所述第二业务相关联的第四跨链交易的目标票据映射资源,且所述目标票据映射资源处于销毁状态时所生成的;所述第四跨链交易是所述第四共识节点基于所述第二业务对象提交的所述目标票据映射资源所确定的,且所述第四跨链交易用于指示将所述目标票据映射资源由所述第二业务子链转回至所述票据链;
    将处于销毁状态的目标票据映射资源作为第二转移票据资源,基于所述第四跨链交易事件对所述第二转移票据资源进行验证,且在验证成功时,基于所述第二转移票据资源构建所述第四跨链交易对应的第四跨链构造交易;
    通过所述第二跨链程序确定所述第三地址,基于所述第三地址将所述第四跨链构造交易发送至所述第三共识节点,以使所述第三共识节点通过所述第三地址在所述票据链上对所述第一转移票据资源进行解锁,得到所述目标票据资源。
  38. 根据权利要求28所述方法,其中,所述第一地址是通过所述第一跨链程序中的第一私钥所确定的;所述第二地址是通过所述第一跨链程序中的第二私钥所确定的;所述第一私钥和所述第二私钥均是由所述第一跨链程序中的主密钥所生成的;所述第一私钥不同于第二私钥;所述管理链共识节点包括N个管理组件;所述N为正整数;
    所述方法还包括:
    对所述主密钥进行密钥拆分,得到所述N个管理组件对应的N个的密钥片段;一个管理组件对应一个密钥片段;
    将所述N个的密钥片段发送至所述管理链共识节点,以使所述管理链共识节点为所述N个管理组件中的每个管理组件分别配置一个密钥片段;一个管理组件用于对一个密钥片段进行密钥备份。
  39. 根据权利要求37所述方法,其中,所述方法还包括:
    当所述可信跨链程序重启时,接收所述管理链共识节点发送的M个密钥片段;所述M个密钥片段中的一个密钥片段来自于所述N个管理组件中的一个管理组件;M为小于或者等于N的正整数;
    当M达到N对应的密钥数量阈值时,根据所述M个密钥片段构建得到所述主密钥。
  40. 根据权利要求17所述的方法,所述与所述管理链共识节点协同复用所述至少一个其他区块链中的共识节点来处理临时业务,包括:
    与所述管理链共识节点协同复用所述至少一个其他区块链中的共识节点共同组建所述临时业务对应的业务子网络,所述至少一个其他区块链包括票据链、合约链中的至少一个。
  41. 根据权利要求40所述的方法,其中,所述链外处理设备包括与所述多区块链相关联的子网创建服务器;
    所述与所述管理链共识节点协同复用所述至少一个其他区块链中的共识节点共同组建所述临时业务对应的业务子网络,包括:
    在获取到子网创建请求时,获取所述子网创建请求中携带的子网创建请求凭证;所述子网创建请求是业务对象通过业务终端发送的,所述子网创建请求凭证是由所述管理链网络中的管理链共识节点接收到所述业务对象通过所述业务终端发送的临时业务所确定的;
    通过所述管理链上的与所述临时业务相关联的注册业务授权凭证,对所述子网创建请求凭证进行校验,得到凭证校验结果;
    在所述凭证校验结果指示校验成功时,将从所述票据链网络中所获取到的共识节点作为第一验证节点,且将从所述合约链网络中所获取到的共识节点作为第二验证节点,通过所述第一验证节点和所述第二验证节点组建所述临时业务对应的业务子网络;所述业务子网络独立于所述管理链网络、所述票据链网络和所述合约链网络。
  42. 根据权利要求41所述的方法,其中,所述通过所述管理链上的与所述临时业务相关联的注册业务授权凭证,对所述子网创建请求凭证进行校验,得到凭证校验结果,包括:
    基于所述子网创建请求向所述管理链共识节点发送凭证校验交易,以使所述管理链共识节点基于所述凭证校验交易调用所述管理链上的子网管理合约,从所述管理链上读取与所述临时业务相关联的注册业务授权凭证;所述注册业务授权凭证包括所述管理链共识节点为所述业务对象配置的子网注册授权码;
    将所述子网注册授权码与所述子网创建请求凭证中的子网构建请求码进行比对,得到比对结果;
    当所述比对结果指示所述子网注册授权码与所述子网构建请求码一致时,确定所述子网创建请求凭证校验成功,将校验成功时的所述子网创建请求凭证作为凭证校验结果。
  43. 根据权利要求41所述的方法,其中,所述注册业务授权凭证包括所述业务对象通过所述业务终端向所述管理链共识节点提交的子网注册配置信息;所述子网注册配置信息包括所述临时业务对应的业务子网络的网络标识、所述业务子网络所包括的验证节点的节点数量以及所述业务对象申请的跨链权限;所述业务子网络所包括的验证节点的节点数量为M,M为大于1的正整数;所述跨链权限包括用于在所述票据链与所述业务子网络对应的业务子链之间进行数据跨链转移的第一跨链转移权限,以及用于在所述合约链与所述业务子链之间进行数据跨链转移的第二跨链转移权限;
    所述将从所述票据链网络中所获取到的共识节点作为第一验证节点,且将从所述合约链网络中所获取到的共识节点作为第二验证节点,通过所述第一验证节点和所述第二验证节点组建所述临时业务对应的业务子网络,包括:
    将从所述票据链网络中获取到的与所述第一跨链转移权限相关联的M1个共识节点均作为第一验证节点,且将从所述合约链网络中所获取到的与所述第二跨链转移权限相关联的M2个共识节点均作为第二验证节点,通过获取到的M1个第一验证节点和M2个第二验证节点组建具有所述网络标识的所述业务子网络;M1和M2均为正整数,且M=M1+M2。
  44. 根据权利要求41所述的方法,其中,还包括:
    在所述业务子网络组建完成时,向所述业务对象返回子网创建成功响应信息;
    在接收到子网启动指令时,基于所述子网启动指令向所述管理链共识节点发送子网启动交易,以使所述管理链共识节点基于所述子网启动交易调用所述管理链上的子网管理合约,从所述管理链上获取与所述业务子网络相关联的创世区块信息;所述子网启动指令是所述业务对象对应的所述业务终端基于所述子网创建成功响应信息发送的,所述创世区块信息包括所述业务对象通过所述业务终端向所述管理链共识节点提交的子网注册配置信息;
    将所述管理链共识节点返回的所述创世区块信息发送至所述业务子网络中的验证节点,以使所述验证节点将所述创世区块信息写入所述业务子网络对应的业务子链。
  45. 根据权利要求41所述的方法,其中,还包括:
    在接收到子网关停指令时,基于所述子网关停指令向所述业务子网络中的验证节点发送业务终止交易,以使所述验证节点在对所述业务终止交易验证成功时,停止执行所述临时业务,且将所述业务子链发送至所述子网创建服务器;所述子网关停指令包括业务结束指令和业务变更指令,所述子网关停指令是与所述子网创建服务器相关联的业务管理对象发送的;
    对接收到的所述业务子链进行备份。
  46. 根据权利要求40所述的方法,其中,所述链外处理设备包括业务终端;
    所述与所述管理链共识节点协同复用所述至少一个其他区块链中的共识节点共同组建所述临时业务对应的业务子网络,包括:
    接收业务对象所请求的临时业务,基于所述临时业务向所述管理链网络中的管理链共识节点发送业务授权请求;所述业务授权请求用于指示所述管理链共识节点在配置得到与所述临时业务相关联的业务授权凭证时,将所述业务授权凭证作为注册业务授权凭证写入所述管理链;
    将所述业务授权凭证作为子网创建请求凭证,基于所述子网创建请求凭证生成子网创建请求;所述业务授权凭证是所述管理链共识节点返回的,所述子网创建请求用于发送给与所述多区块链相关联的子网创建服务器,所述子网创建请求用于指示所述子网创建服务器在获取到所述管理链上的所述注册业务授权凭证时,对所述子网创建请求凭证进行校验,且在校验成功时,将从所述票据链网络中所获取到的共识节点作为第一验证节点,且将从所述合约链网络中所获取到的共识节点作为第二验证节点,所述第一验证节点和所述第二验证节点用于共同组建所述临时业务对应的业务子网络;所述业务子网络独立于所述管理链网络、所述票据链网络和所述合约链网络。
  47. 根据权利要求46所述的方法,其中,所述基于所述临时业务向所述管理链网络中的管理链共识节点发送业务授权请求,包括:
    基于所述临时业务生成子网注册配置信息,通过所述业务对象的私钥信息对所述子网注册配置信息进行签名,得到对象签名信息,基于所述子网注册配置信息、所述对象签名信息以及所述私钥信息对应的公钥信息确定业务授权请求;
    将所述业务授权请求发送至所述管理链网络中的管理链共识节点,以使所述管理链共识节点在通过所述业务授权请求中的所述公钥信息确定所述对象签名信息验签成功时,基于从所述业务授权请求中获取到的所述子网注册配置信息调用所述管理链上的子网管理合约,为所述业务对象配置与所述临时业务相关联的业务授权凭证。
  48. 根据权利要求46所述的方法,其中,还包括:
    在所述业务子网络组建完成时,接收子网创建成功响应信息,基于所述子网创建成功响应信息向所述子网创建服务器发送子网启动指令,以使所述子网创建服务器基于所述子网启动指令向所述管理链共识节点发送子网启动交易;所述子网创建成功响应信息是所述子网创建服务器返回的,所述子网启动交易用于指示所述管理链共识节点调用所述管理链上的子网管理合约,从所述管理链上获取与所述业务子网络相关联的创世区块信息;所述创世区块信 息包括所述业务对象通过所述业务终端向所述管理链共识节点提交的子网注册配置信息;所述创世区块信息用于写入所述业务子网络对应的业务子链。
  49. 根据权利要求46所述的方法,其中,还包括:
    向所述业务子网络中的验证节点发送数据提取请求;所述数据提取请求用于指示所述验证节点在接收到所述子网创建服务器返回的备份成功消息时,将所述业务子网络对应的业务子链上具有最大区块高度的区块中的区块数据作为与所述业务对象相关联的目标提取数据;
    接收所述验证节点基于所述数据提取请求返回的所述目标提取数据。
  50. 根据权利要求46所述的方法,其中,所述票据链网络和所述业务子网络是由与所述多区块链相关联的第一跨链中继隔离的;所述方法还包括:
    在所述业务子网络启动后,基于所述临时业务向所述票据链网络中的第一共识节点发送第一跨链资源转出请求;所述第一跨链资源转出请求用于指示所述第一共识节点将与所述临时业务相关联的第一资源由所述票据链转移至所述业务子网络对应的业务子链;
    获取从所述业务子链上探测到的第一资源转移成功响应信息;所述第一资源转移成功响应信息是针对所述第一跨链资源转出请求所得到的,所述第一资源转移成功响应信息用于表征成功将所述第一资源由所述票据链转移至所述业务子链,且所述业务子链上存在所述第一资源对应的第一映射资源;所述第一映射资源为在所述票据链上锁定所述第一资源时,由所述业务子链上的第一资源映射合约所铸造得到的与所述第一资源具有相同资源内容的资源;
    基于所述第一资源转移成功响应信息向所述业务子网络中的验证节点发送用于执行所述临时业务的第一业务执行请求,以使所述验证节点基于所述第一业务执行请求,调用所述业务子链上的第一临时业务合约获取所述第一资源映射合约中的所述第一映射资源,基于所述第一映射资源执行所述临时业务。
  51. 根据权利要求46所述的方法,其中,所述合约链网络和所述业务子网络是由与所述多区块链相关联的第二跨链中继隔离的;所述方法还包括:
    在所述业务子网络启动后,基于所述临时业务向所述合约链网络中的第二共识节点发送第二跨链资源转出请求;所述第二跨链资源转出请求用于指示所述第二共识节点将与所述临时业务相关联的第二资源由所述合约链转移至所述业务子网络对应的业务子链;
    获取从所述业务子链上探测到的第二资源转移成功响应信息;所述第二资源转移成功响应信息是针对所述第二跨链资源转出请求所得到的,所述第二资源转移成功响应信息用于表征成功将所述第二资源由所述合约链转移至所述业务子链,且所述业务子链上存在所述第二资源对应的第二映射资源;所述第二映射资源为在所述合约链上锁定所述第二资源时,由所述业务子链上的第二资源映射合约所铸造得到的与所述第二资源具有相同资源内容的资源;
    基于所述第二资源转移成功响应信息向所述业务子网络中的验证节点发送用于执行所述临时业务的第二业务执行请求,以使所述验证节点基于所述第二业务执行请求,调用所述业务子链上的第二临时业务合约获取所述第二资源映射合约中的所述第二映射资源,基于所述第二映射资源执行所述临时业务。
  52. 一种基于多区块链的跨链处理装置,所述装置包括:
    区块链获取模块,用于获取多区块链;
    区块链确定模块,用于在所述多区块链中确定待进行跨链处理的至少两个区块链;
    处理模块,用于基于所述至少两个区块链的链信息,对所述至少两个区块链进行跨链处理。
  53. 一种基于多区块链的跨链处理装置,所述装置包括:
    确定模块,用于在所述多区块链中确定待进行跨链处理的至少两个区块链;
    处理模块,用于与管理链共识节点协同对所述至少两个区块链进行跨链处理。
  54. 一种计算机设备,其中,包括存储器和处理器;
    所述存储器与所述处理器相连,所述存储器用于存储计算机程序,所述处理器用于调用 所述计算机程序,以使得所述计算机设备执行权利要求1-45任一项所述的方法。
  55. 一种计算机可读存储介质,其中,所述计算机可读存储介质中存储有计算机程序,所述计算机程序适于由处理器加载并执行,以使得具有所述处理器的计算机设备执行权利要求1-51任一项所述的方法。
  56. 一种计算机程序产品,其中,包括计算机程序/指令,所述计算机程序/指令被处理器执行时实现权利要求1-51任一项所述的方法。
PCT/CN2023/114959 2022-10-19 2023-08-25 基于多区块链的跨链处理方法、装置、设备、系统及介质 WO2024082818A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/388,502 US20240137231A1 (en) 2022-10-19 2023-11-09 Multi-blockchain-based cross-chain processing method and apparatus, device, system, and medium

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
CN202211298596.9 2022-10-20
CN202211298596.9A CN117951217A (zh) 2022-10-20 2022-10-20 基于多区块链的跨链配置方法、装置、设备、系统及介质
CN202211303327.7A CN117938867A (zh) 2022-10-24 2022-10-24 一种多区块链数据处理方法、装置、设备、介质及产品
CN202211306695.7A CN117992534A (zh) 2022-10-24 2022-10-24 基于多区块链的数据跨链方法、相关设备、介质及产品
CN202211303327.7 2022-10-24
CN202211306695.7 2022-10-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/388,502 Continuation US20240137231A1 (en) 2022-10-19 2023-11-09 Multi-blockchain-based cross-chain processing method and apparatus, device, system, and medium

Publications (1)

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

Family

ID=90738746

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/114959 WO2024082818A1 (zh) 2022-10-19 2023-08-25 基于多区块链的跨链处理方法、装置、设备、系统及介质

Country Status (2)

Country Link
US (1) US20240137231A1 (zh)
WO (1) WO2024082818A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190244306A1 (en) * 2018-02-05 2019-08-08 Bank Of America Corporation System and method for decentralized regulation and hierarchical control of blockchain architecture
CN110471984A (zh) * 2019-07-15 2019-11-19 阿里巴巴集团控股有限公司 基于区块链的业务处理方法及装置、电子设备
CN111158703A (zh) * 2019-12-25 2020-05-15 江苏众享金联科技有限公司 一种基于智能合约的以链治链方法
CN111294339A (zh) * 2020-01-16 2020-06-16 北京航空航天大学 基于Fabric架构的同构联盟链跨链方法及装置
CN112994892A (zh) * 2020-12-17 2021-06-18 中国工商银行股份有限公司 跨链交互方法、装置、系统和电子设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190244306A1 (en) * 2018-02-05 2019-08-08 Bank Of America Corporation System and method for decentralized regulation and hierarchical control of blockchain architecture
CN110471984A (zh) * 2019-07-15 2019-11-19 阿里巴巴集团控股有限公司 基于区块链的业务处理方法及装置、电子设备
CN111158703A (zh) * 2019-12-25 2020-05-15 江苏众享金联科技有限公司 一种基于智能合约的以链治链方法
CN111294339A (zh) * 2020-01-16 2020-06-16 北京航空航天大学 基于Fabric架构的同构联盟链跨链方法及装置
CN112994892A (zh) * 2020-12-17 2021-06-18 中国工商银行股份有限公司 跨链交互方法、装置、系统和电子设备

Also Published As

Publication number Publication date
US20240137231A1 (en) 2024-04-25

Similar Documents

Publication Publication Date Title
CN110192380B (zh) 用于管理区块链云服务的系统和方法
US20220239470A1 (en) Cross-blockchain data processing method and apparatus, device, and computer storage medium
US11762842B2 (en) Systems and methods for asynchronous delayed updates in virtual distributed ledger networks
CN111598566A (zh) 基于混合跨链的网络支付系统
CN112514319A (zh) 在超级账本架构区块链中支持基于sql的丰富查询的系统和方法
US11765225B2 (en) Systems and methods for microservice execution load balancing in virtual distributed ledger networks
US11627122B2 (en) Inter-system linking method and node
US11568064B2 (en) Systems and methods for virtual distributed ledger networks
CN113255014B (zh) 一种基于区块链的数据处理方法以及相关设备
Abraham et al. Qualified eID derivation into a distributed ledger based IdM system
US11838406B2 (en) Systems and methods for control-data plane partitioning in virtual distributed ledger networks
US20200342456A1 (en) Systems and methods for hybrid synchronization in virtual distributed ledger networks
KR102294569B1 (ko) 블록체인 네트워크를 구축할 수 있는 블록체인 관리시스템
KR102139551B1 (ko) 유언장을 관리하는 서버 및 방법
WO2024082818A1 (zh) 基于多区块链的跨链处理方法、装置、设备、系统及介质
Zhang et al. FutureText: A blockchain-based contract signing prototype with security and convenience
CN114202415A (zh) 基于异构链的数据处理方法及装置
WO2024082807A1 (zh) 基于多区块链的资产转移方法、装置、设备、介质及产品
WO2024099023A1 (zh) 多区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品
WO2024078109A1 (zh) 多区块链数据处理方法、装置、设备、系统以及介质
WO2024093593A1 (zh) 基于多区块链的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品
CN117938867A (zh) 一种多区块链数据处理方法、装置、设备、介质及产品
CN116708463B (zh) 基于多区块链的信息处理方法、装置、设备以及介质
EP4375850A1 (en) Multi-blockchain data processing method and apparatus, and device, system and medium
CN117951217A (zh) 基于多区块链的跨链配置方法、装置、设备、系统及介质