WO2024078109A1 - 多区块链数据处理方法、装置、设备、系统以及介质 - Google Patents

多区块链数据处理方法、装置、设备、系统以及介质 Download PDF

Info

Publication number
WO2024078109A1
WO2024078109A1 PCT/CN2023/112033 CN2023112033W WO2024078109A1 WO 2024078109 A1 WO2024078109 A1 WO 2024078109A1 CN 2023112033 W CN2023112033 W CN 2023112033W WO 2024078109 A1 WO2024078109 A1 WO 2024078109A1
Authority
WO
WIPO (PCT)
Prior art keywords
business
chain
consensus node
contract
target
Prior art date
Application number
PCT/CN2023/112033
Other languages
English (en)
French (fr)
Inventor
朱耿良
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to EP23790529.4A priority Critical patent/EP4375850A1/en
Priority to US18/379,648 priority patent/US20240129143A1/en
Publication of WO2024078109A1 publication Critical patent/WO2024078109A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present application relates to the field of blockchain technology, and in particular to a multi-blockchain data processing method, device, equipment, system and medium.
  • the existing blockchain data processing system relies on a blockchain network built on a single chain structure when processing related businesses (for example, business A and its extended business B). In this way, for each business processing party that accesses the blockchain network through a terminal or server, it is necessary to process related businesses (for example, business A and extended business B) on the same blockchain corresponding to the blockchain network.
  • Embodiments of the present application provide a multi-blockchain data processing method, apparatus, device, system, and medium.
  • an embodiment of the present application provides a multi-blockchain data processing method, which is executed by a first consensus node in a first chain network, and the method includes:
  • the first business requested by the first business object call the first cross-chain read contract on the first chain based on the first business, and read the first business-related information associated with the first business from the target chain;
  • the first chain is a blockchain in the first chain network;
  • the target chain is a blockchain in the target chain network;
  • the target chain network is independent of the first chain network, and the first chain is different from the target chain;
  • the first business processing contract on the first chain is called to execute the first business, a first business execution result associated with the first business is obtained, and the first business execution result is written into the first chain; the first business execution result includes business data indicated by the first business;
  • the business data is read from the first chain based on the second business carried in the cross-chain read request, and the core data in the business data is returned to the second consensus node;
  • the second consensus node is used to write the second business execution result corresponding to the second business into the second chain after executing the second business based on the core data;
  • the second chain is a blockchain in the second chain network where the second consensus node is located, and the second chain network is independent of the first chain network and the target chain network.
  • an embodiment of the present application provides a multi-blockchain data processing method, which is executed by a second consensus node in a second chain network, and the method includes:
  • the second business requested by the second business object call the second cross-chain reading contract on the second chain based on the second business, and read the second business-related information associated with the second business from the target chain;
  • the second chain is a blockchain in the second chain network;
  • the target chain is a blockchain in the target chain network;
  • the target chain network is independent of the second chain network, and the second chain is different from the target chain;
  • the second cross-chain read contract When it is determined based on the second business association information that the second business object has the second business processing authority corresponding to the second business, the second cross-chain read contract is called to generate a cross-chain read request associated with the second business, and the cross-chain read request is sent to the first consensus node in the first chain network; the cross-chain read request is used to instruct the first consensus node to read the business data associated with the second business from the first chain corresponding to the first chain network; the first chain network is independent of the second chain network and the target chain network; the business data is determined by the first consensus node calling the first business processing contract on the first chain when it is determined based on the first business association information that the first business object has the first business processing authority corresponding to the first business; the first business association information is read from the target chain by the first consensus node calling the first cross-chain read contract on the first chain based on the first business;
  • an embodiment of the present application provides a multi-blockchain data processing method, which is executed by a target consensus node in a target chain network, and the method includes:
  • the first business authority query request is determined by the first consensus node calling a first cross-chain read contract on the first chain when acquiring the first business submitted by the first business object;
  • the first chain is a blockchain in the first chain network;
  • the first chain network is independent of the target chain network;
  • first business association information associated with the first business is read from the target chain corresponding to the target chain network, and the first business association information is returned to the first consensus node, so that when the first consensus node determines that the first business object has the first business processing authority corresponding to the first business based on the first business association information, the first business processing contract on the first chain is called to execute the first business, and the first business execution result for writing to the first chain is obtained; the first business execution result includes the business data indicated by the first business;
  • the second business authority query request is determined by the second consensus node calling the second cross-chain read contract on the second chain corresponding to the second chain network when obtaining the second business submitted by the second business object;
  • the second chain network is independent of the first chain network and the target chain network;
  • the second business association information associated with the second business is read from the target chain, and the second business association information is returned to the second consensus node, so that when the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business association information, the second cross-chain read contract is called to generate a cross-chain read request associated with the second business for sending to the first consensus node; the cross-chain read request is used to instruct the first consensus node to read business data from the first chain.
  • an embodiment of the present application provides a multi-blockchain data processing device, which runs on a first consensus node in a first chain network, and includes:
  • a first business acquisition module is used to acquire a first business requested by a first business object, call a first cross-chain read contract on a first chain based on the first business, and read first business-related information associated with the first business from a target chain;
  • the first chain is a blockchain in a first chain network;
  • the target chain is a blockchain in a target chain network;
  • the target chain network is independent of the first chain network, and the first chain is different from the target chain;
  • a first business execution module is used to call a first business processing contract on a first chain to execute the first business when it is determined based on the first business association information that the first business object has the first business processing authority corresponding to the first business, obtain a first business execution result associated with the first business, and write the first business execution result into the first chain; the first business execution result includes business data indicated by the first business;
  • the business data reading module is used to read the business data from the first chain based on the second business carried in the cross-chain read request when the cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain is obtained, and return the core data in the business data to the second consensus node;
  • the second consensus node is used to write the second business execution result corresponding to the second business to the second chain after executing the second business based on the core data;
  • the second chain is the blockchain in the second chain network where the second consensus node is located, and the second chain network is independent of the first chain network and the target chain network.
  • the chain entry corresponding to the first chain network is the first chain entry;
  • the first chain entry stores the registration data information of the authorized object synchronized from the target chain by the first consensus node through the first cross-chain reading contract at the first cross-chain reading timestamp;
  • an embodiment of the present application provides a multi-blockchain data processing device, which runs on a second consensus node in a second chain network, and includes:
  • a second business acquisition module is used to acquire a second business requested by a second business object, call a second cross-chain reading contract on a second chain based on the second business, and read second business association information associated with the second business from a target chain;
  • the second chain is a blockchain in a second chain network;
  • the target chain is a blockchain in a target chain network;
  • the target chain network is independent of the second chain network, and the second chain is different from the target chain;
  • the cross-chain read request sending module is used to call the second cross-chain read contract to generate a cross-chain read request associated with the second business when it is determined based on the second business association information that the second business object has the second business processing authority corresponding to the second business.
  • a cross-chain read request is sent to the first consensus node in the first chain network; the cross-chain read request is used to instruct the first consensus node to read the business data associated with the second business from the first chain corresponding to the first chain network; the first chain network is independent of the second chain network and the target chain network; the business data is determined by the first consensus node calling the first business processing contract on the first chain when it determines that the first business object has the first business processing authority corresponding to the first business based on the first business association information; the first business association information is read from the target chain by the first consensus node calling the first cross-chain read contract on the first chain based on the first business;
  • the second business execution module is used to receive the core data in the business data returned by the first consensus node based on the cross-chain read request, execute the second business based on the core data, and write the second business execution result corresponding to the second business into the second chain.
  • an embodiment of the present application provides a multi-blockchain data processing device, which runs on a target consensus node in a target chain network, and includes:
  • the first query request receiving module is used to receive a first business authority query request sent by a first consensus node in a first chain network; the first business authority query request is determined by the first consensus node calling a first cross-chain read contract on the first chain when acquiring the first business submitted by the first business object; the first chain is a blockchain in the first chain network; the first chain network is independent of the target chain network;
  • a first associated information return module is used to read the first business associated information associated with the first business from the target chain corresponding to the target chain network based on the first business query request, and return the first business associated information to the first consensus node, so that when the first consensus node determines that the first business object has the first business processing authority corresponding to the first business based on the first business associated information, it calls the first business processing contract on the first chain to execute the first business and obtains the first business execution result for writing into the first chain; the first business execution result includes the business data indicated by the first business;
  • the second query request receiving module is used to receive a second business authority query request sent by a second consensus node in the second chain network; the second business authority query request is determined by the second consensus node calling the second cross-chain read contract on the second chain corresponding to the second chain network when obtaining the second business submitted by the second business object; the second chain network is independent of the first chain network and the target chain network;
  • the second associated information returning module is used to read the second business associated information associated with the second business from the target chain based on the second business query request, and return the second business associated information to the second consensus node, so that when the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business associated information, it calls the second cross-chain read contract to generate a cross-chain read request associated with the second business for sending to the first consensus node; the cross-chain read request is used to instruct the first consensus node to read business data from the first chain.
  • an embodiment of the present application provides a multi-blockchain data processing system, the system comprising: a first consensus node in a first chain network, a target consensus node in a target chain network, and a second consensus node in a second chain network; the first chain network is independent of the target chain network and independent of the second chain network;
  • the first consensus node is used to obtain the first business requested by the first business object, call the first cross-chain reading contract on the first chain based on the first business, and generate a first business authority query request;
  • the target consensus node is used to read the first business association information associated with the first business from the target chain corresponding to the target chain network when obtaining the first business authority query request sent by the first consensus node, and return the first business association information to the first consensus node;
  • the first consensus node is further used to call the first business processing contract on the first chain to execute the first business when it is determined based on the first business association information that the first business object has the first business processing authority corresponding to the first business, obtain the first business execution result associated with the first business, and write the first business execution result into the first chain; the first business execution result includes the business data indicated by the first business;
  • the first consensus node is also used to read business data from the first chain based on the second business carried in the cross-chain read request when obtaining the cross-chain read request sent by the second consensus node, and return the core data in the business data to the second consensus node;
  • the cross-chain read request is generated by calling the second cross-chain read contract when the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business association information;
  • the second business association information is read from the target chain by the second consensus node calling the second cross-chain read contract based on the second business;
  • the second consensus node is used to write the second business execution result corresponding to the second business into the second chain after executing the second business based on the core data.
  • an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method provided in the above aspect of the embodiment of the present application.
  • an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored.
  • the computer program is suitable for being loaded and executed by a processor, so that a computer device with a processor executes the method provided in the above aspect of the embodiment of the present application.
  • a computer program product or a computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium.
  • a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in the above aspect.
  • the first consensus node in the first chain network when obtaining the first business requested by the first business object, can call the first cross-chain reading contract on the first chain based on the first business, and read the first business association information associated with the first business from the target chain;
  • the first chain is a blockchain in the first chain network;
  • the target chain is a blockchain in a target chain network independent of the first chain network;
  • the first chain is different from the target chain;
  • the first consensus node in the first chain network can call the first business processing contract on the first chain to execute the first business when determining that the first business object has the first business processing authority corresponding to the first business based on the first business association information, and obtain the first business execution result associated with the first business, and the first business execution result is read from the target chain.
  • the result of a business execution is written to the first chain;
  • the result of the first business execution includes the business data indicated by the first business;
  • the first consensus node in the first chain network can also read the business data from the first chain based on the second business carried in the cross-chain read request when obtaining the cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, and return the core data in the business data to the second consensus node;
  • the second consensus node here is used to write the second business execution result corresponding to the second business to the second chain after executing the second business based on the core data;
  • the second chain is the blockchain in the second chain network where the second consensus node is located, and the second chain network is independent of the first chain network and the target chain network.
  • the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize that the three chains of the first chain, the target chain and the second chain can collaborate with each other to ensure that the consensus node in the first chain network (i.e., the aforementioned first consensus node) can be used to independently process some real-time business flows composed of first businesses with a large amount of request data.
  • the first consensus node can participate in the maintenance of the first chain in the first chain network, and the first chain is mainly used to store the business data obtained by executing each first business in the real-time business flow.
  • the second consensus node can participate in the maintenance of the second chain in the second chain network, and the second chain is mainly used to store the second business execution result.
  • the second business execution result is determined by the second business carried out based on the core data in the business data (i.e., part of the authorized visible data in the business data) transferred from the aforementioned first chain across the chain to the second chain;
  • the target consensus node here can be used to centrally manage the permissions (such as identity permissions and business permissions) of the business objects in the access second chain network and the first chain network.
  • 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 multi-blockchain data processing method provided by an embodiment of the present application.
  • FIG4 is a schematic diagram of a scenario of identity authentication through a chain entry provided by an embodiment of the present application.
  • FIG5 is a schematic diagram of a scenario of cross-chain interaction among three chains adopted in an embodiment of the present application.
  • FIG6 is a multi-blockchain data processing method provided by an embodiment of the present application.
  • FIG7 is a multi-blockchain data processing method provided by an embodiment of the present application.
  • FIG8 is a multi-blockchain data processing method provided by an embodiment of the present application.
  • FIG9 is a schematic diagram of the structure of a multi-blockchain data processing device provided by the present application.
  • FIG10 is a schematic diagram of the structure of a multi-blockchain data processing device provided by the present application.
  • FIG11 is a schematic diagram of the structure of a multi-blockchain data processing device provided by the present application.
  • FIG12 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.
  • FIG13 is a schematic diagram of a multi-blockchain data processing system provided in an embodiment of the present application.
  • 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 node 110a, business node 110b, business node 110c, business node 110d, business node 110e, business node 110f, business node 110g, ..., business node 110n shown in FIG1 .
  • the multiple business nodes here may specifically include the business node 110a, business node 110b, business node 110c, business node 110d, business node 110e, business node 110f, business node 110g, ..., business node 110n shown in FIG1 .
  • the multiple business nodes here may specifically include the business node 110a, business node 110b, business node 110c, business node 110d, business node 110e, business node 110f, business node 110g, ..., business node 110n shown in FIG1 .
  • FIG1 for each business node running in the business network 400a, one or more of the above-mentioned multiple consensus networks can be accessed through network communication, and data can also be
  • the multiple consensus nodes here may specifically include the consensus node 10a, the consensus node 10b, the consensus node 10c, and the consensus node 10d shown in FIG1 .
  • the blockchain maintained together is specifically the blockchain 10e shown in FIG1 .
  • the consensus network 200a shown in FIG. 1 multiple consensus nodes are deployed.
  • the blockchain that is jointly maintained is specifically the blockchain 11e shown in FIG. 1 .
  • the consensus network 300a shown in FIG. 1 multiple consensus nodes are deployed.
  • the blockchain that is jointly maintained is specifically the blockchain 12e shown in FIG. 1 .
  • 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 200b and consensus network 300c participating in constituting 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 embodiment of the present application can be combined with the specific application scenario of the multi-business collaborative processing platform (for example, the core data flow scenario of electronic bills under the blockchain electronic bill platform), and the above-mentioned consensus network 100a is collectively referred to as the target chain network, and the blockchain 10e jointly maintained by each consensus node in the target chain network is collectively referred to as the target chain, and the consensus node selected in the target chain network for executing management services (for example, registration services and authorization services, etc.) can also be used as the target consensus node in the target chain network.
  • management services for example, registration services and authorization services, etc.
  • the embodiment of the present application can collectively refer to the above-mentioned consensus network 200a as the first chain network, and the blockchain 11e jointly maintained by each consensus node in the first chain network is collectively referred to as the first chain, and the consensus node selected in the first chain network for executing the first business (the first business can be specifically a bill business associated with electronic bills, for example, an electronic bill issuance business, etc.) can also be used as the first consensus node in the target chain network.
  • the above consensus network 300a may be collectively referred to as the second chain network
  • the blockchain 12e jointly maintained by each consensus node in the second chain network may be collectively referred to as the second chain.
  • the consensus node selected in the second chain network for executing the second business may also be used as the first consensus node in the target chain network. It should be understood that for each core consensus network, the management business, bill business, and derivative business here can all be regarded as the corresponding business to Transaction business of the transaction initiated by the image.
  • a secure and reliable blockchain electronic invoice three-chain network can be constructed based on the above-mentioned target chain, the first chain and the second chain.
  • the blockchain electronic invoice three-chain network when the above-mentioned businesses are independently executed in the above-mentioned three consensus networks, the business execution results obtained by independently executing the above-mentioned businesses can be respectively stored in the blockchain ledgers of the corresponding blockchains, thereby avoiding the confusion of data storage on each chain from the root.
  • the consensus network 100a is used as the target chain network
  • the target chain network is the target chain network in the aforementioned blockchain electronic bill three-chain network
  • the blockchain 10e stored on each node in the consensus network 100a (for example, core nodes such as consensus node 10a, consensus node 10b, consensus node 10c and consensus node 10d) is the above-mentioned target chain.
  • the target chain here can specifically be the management chain in the above-mentioned target chain network, and the above-mentioned management consensus nodes (or target core nodes) determined from the management chain network can be collectively referred to as target consensus nodes.
  • consensus network 200a when consensus network 200a is used as the first chain network, and the first chain network is the bill chain network in the aforementioned blockchain electronic bill three-chain network, the blockchain 11e stored on each node in consensus network 200a (for example, core nodes such as consensus node 11a, consensus node 11b, consensus node 11c and consensus node 11d) is the first chain, and the first chain here can specifically be the bill chain in the aforementioned blockchain system, and the bill consensus node (or the first core node) determined from the bill chain network can be collectively referred to as the first consensus node.
  • core nodes such as consensus node 11a, consensus node 11b, consensus node 11c and consensus node 11d
  • the embodiment of the present application can use the consensus mechanism in the bill chain network to select a certain consensus node (that is, the aforementioned bill consensus node) from the consensus nodes of the bill chain network as the first consensus node, and the remaining consensus nodes except the first consensus node in the consensus nodes of the bill chain network can be collectively referred to as verification consensus nodes (at this time, the verification consensus node is specifically a bill verification consensus node).
  • a certain consensus node that is, the aforementioned bill consensus node
  • the remaining consensus nodes except the first consensus node in the consensus nodes of the bill chain network can be collectively referred to as verification consensus nodes (at this time, the verification consensus node is specifically a bill verification consensus node).
  • the consensus network 300a is used as the second chain network
  • the second chain network is the application contract chain network in the aforementioned blockchain electronic bill three-chain network
  • the blockchain 12e stored on each node in the consensus network 300a (for example, core nodes such as consensus node 12a, consensus node 12b, consensus node 21c and consensus node 12d) is the second chain.
  • the second chain here can specifically be the application contract chain in the aforementioned blockchain system, and the application consensus nodes (or second core nodes) determined from the application contract chain network can be collectively referred to as second consensus nodes, that is, the embodiment of the present application can use the consensus mechanism in the second chain network to select a consensus node (that is, the aforementioned application consensus node) from the consensus nodes of the application contract chain as the second consensus node, and the remaining consensus nodes in the consensus nodes of the application contract chain network except the second consensus node can also be collectively referred to as verification consensus nodes (at this time, the verification consensus node is specifically an application verification consensus node).
  • a consensus node that is, the aforementioned application consensus node
  • verification consensus nodes is specifically an application verification consensus node
  • the core node can be responsible for the consensus in the core consensus network where the corresponding blockchain is located, that is, the core node can be the consensus node in the core consensus network where the corresponding blockchain is located.
  • the specific process of writing the transaction data in the core consensus network into the corresponding blockchain ledger can be that the user client sends the transaction data to a certain business node, and then the transaction data is passed between the business nodes in the business network in the above blockchain network in a relay manner until the consensus node in the corresponding core consensus network in the above blockchain network (for example, the consensus node 11b in the consensus network 200a) receives the transaction data.
  • the consensus node (for example, the consensus node 11b in the consensus network 200a) packs the transaction data into a block so that it can be subsequently reached by consensus with other consensus nodes, so that after the consensus is passed, the consensus-passed block can be written into the distributed database of the core consensus network (for example, the consensus network 200a) where it is located.
  • the core consensus network for example, the consensus network 200a
  • the embodiment of the present application can also write the block carrying the transaction data and other multiple blocks associated with the block in parallel into a distributed database through the storage layer of its own core consensus network (for example, consensus network 200a).
  • consensus network 200a for example, consensus network 200a
  • smart contracts can be deployed on the blockchain of the corresponding core consensus network.
  • a user can initiate a transaction service request through a user client to call a smart contract that has been deployed on the blockchain (e.g., the blockchain 11e) of the corresponding core consensus network (e.g., the consensus network 200a).
  • each consensus node will request to read data from the corresponding blockchain through the chain identifier specified by the cross-chain reading contract.
  • each consensus node will verify with each other whether the transaction execution results obtained after executing the transaction based on the information read across the chain are consistent (i.e., consensus is reached). If they are consistent, the transaction execution results can be stored in their respective local caches and local storages, and the transaction execution results of the above transaction business can be returned to the client.
  • the embodiment of the present application can configure a blockchain node for any role (for example, any individual user, any enterprise, any institution, etc.) that accesses the blockchain network through the target consensus node in the above-mentioned target chain network. Therefore, in the business network 400a shown in Figure 1, business nodes 110a, business nodes 110b, business nodes 110c, business nodes 110d, ..., business nodes 110n can have a one-to-one correspondence with the corresponding roles that need to access the blockchain network.
  • the consensus node located in the target chain network can provide registration services and authorization services for the corresponding roles (or corresponding objects) that access the target chain network through the target chain network entrance, and then the corresponding roles (i.e., corresponding objects) that need to access the blockchain network (for example, the target chain network, the first chain network, or the second chain network) can be managed in the target chain network.
  • the corresponding roles i.e., corresponding objects
  • the blockchain network for example, the target chain network, the first chain network, or the second chain network
  • the target consensus node located in the target chain network can also be used to manage the relevant metadata information in the blockchain system, for example, it can manage and update the contract template on the target chain (it should be understood that the contract template on the target chain can specifically include the management contract template of the smart contract deployed on the target chain and the application contract template of the smart contract deployed on the second chain), manage and update the bill template recorded on the target chain, manage and update the tax calculation rules associated with the bill template, etc., control the access flow at the chain entrance corresponding to the first chain, and control the number of consensus nodes participating in the consensus on each chain.
  • the consensus node located in the first chain network may be used to provide the first service.
  • the first service here may include but is not limited to the bill service associated with the electronic bill, and the bill service here may specifically include the electronic bill issuance service, the electronic bill circulation service, the electronic bill redemption service, the electronic bill archiving service and other services related to the electronic bill.
  • the consensus node located in the second chain network can be used to provide a second business associated with the aforementioned first business (for example, credit business, loss-making business, corporate qualification business, social business, credit purchase business and tax refund business, lottery business, etc.).
  • a second business associated with the aforementioned first business for example, credit business, loss-making business, corporate qualification business, social business, credit purchase business and tax refund business, lottery business, etc.
  • each entity object can correspond to a blockchain node
  • the embodiment of the present application can take the entity object as the above-mentioned enterprise user (i.e., the aforementioned enterprise) as an example.
  • the blockchain node associated with each enterprise user can be the same blockchain node (for example, the business node 110c shown in Figure 1 above can interact with user terminals corresponding to multiple enterprise users).
  • the first business requested by each enterprise user for example, electronic invoice issuance business, electronic invoice circulation business, electronic invoice redemption business, electronic invoice archiving business and other electronic invoice-related businesses
  • a transaction business for example, electronic invoice issuance business, electronic invoice circulation business, electronic invoice redemption business, electronic invoice archiving business and other electronic invoice-related businesses.
  • the above-mentioned enterprise user is an invoicing enterprise A that requests to issue an invoice through the first chain network (for example, the above-mentioned consensus network 200a)
  • data can be exchanged with the consensus node (for example, consensus node 11b) in the above-mentioned consensus network 200a through the business node 110c shown in Figure 1.
  • the invoicing company B can also interact with the consensus node in the above-mentioned consensus network 200a (for example, consensus node 11b) through the business node 110c shown in Figure 1 to request the completion of the corresponding transaction; and so on, the invoicing company C can also interact with the consensus node in the above-mentioned consensus network 200a (for example, consensus node 11b) through the business node 110c shown in Figure 1 to request the completion of the corresponding transaction.
  • the embodiment of the present application can collectively refer to the entity objects (for example, invoicing enterprise A, invoicing enterprise B, ..., invoicing enterprise C) that send transaction business requests to the first chain network for the above-mentioned electronic invoice business as first business objects, and in the business network (for example, the above-mentioned business network 400a), the blockchain nodes associated with the first business object (for example, invoicing enterprise A, invoicing enterprise B, ..., invoicing enterprise C) (for example, the above-mentioned business node 110c) are collectively referred to as first business nodes, and in the core consensus network (for example, the above-mentioned consensus network 200a as the first chain network), the blockchain nodes that obtain the electronic invoice issuance business indicated by the transaction business request are collectively referred to as the above-mentioned first consensus nodes.
  • the entity objects for example, invoicing enterprise A, invoicing enterprise B, ..., invoicing enterprise C
  • the blockchain nodes associated with the first business object for example, invoicing enterprise A, in
  • the transaction service request initiated by the first business object can be forwarded to the first consensus node, so that the first consensus node can verify the legitimacy of the transaction service request initiated by the first business object.
  • the first consensus node can add the transaction service (for example, the above-mentioned bill service) requested by the first business object to the transaction pool when the legitimacy verification passes, so that the transaction data associated with the transaction service (for example, the above-mentioned bill service) can be packaged into blocks later, so as to perform block consensus between the consensus nodes in the consensus network 200a, so that after the block consensus passes, the block data of the block can be written to the local cache and local storage, so that the parallel storage of block data of multiple blocks can be realized later based on the above-mentioned distributed storage.
  • the transaction service for example, the above-mentioned bill service
  • the transaction data associated with the transaction service for example, the above-mentioned bill service
  • FIG 2 is a scenario 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 the above-mentioned multi-business collaborative processing platform, that is, the blockchain electronic bill platform can be a specific business platform in the above-mentioned blockchain system.
  • the multi-chain system mainly involves the blockchain electronic bill three-chain network 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 target chain
  • the bill chain here can be the above-mentioned first chain
  • the application contract chain here can be the above-mentioned second chain.
  • 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 an example of a three-chain system. 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 different from the consensus node used to maintain the application contract chain.
  • the management chain deployed in the blockchain electronic bill three-chain network is independent of the bill chain and the application contract chain, that is, the three independently built blockchains are independent of each other, but the three independently built blockchains can exchange data through cross-chain means, that is, the three chains can interact cross-chain.
  • the consensus node participating in the maintenance of the bill chain i.e., the first consensus node mentioned above
  • the first consensus node mentioned above can confirm the business authority through the first cross-chain reading contract and the cross-chain reading of the business-related information on the management chain.
  • the consensus node participating in maintaining the application contract chain i.e., the second consensus node mentioned above
  • the consensus node participating in maintaining the application contract chain can confirm the business authority by cross-chain reading the business-related information on the management chain through the second cross-chain reading contract, and can also perform corresponding derivative business (i.e., the second business mentioned above, for example, the credit investigation business can be performed through the bill information read from the bill chain to obtain the corporate credit information of a certain enterprise) by cross-chain reading the core data on the bill chain through the second cross-chain reading contract.
  • the management chain here can be used to provide management functions and features for the entire blockchain electronic bill platform, and the bill chain here can provide bill services of different business authority types for the entire blockchain electronic bill platform (i.e., the first business mentioned above).
  • the embodiment of the present application proposes that a more standardized, flexible and fully functional derivative business (i.e., the second business mentioned above) can be provided through another blockchain independent of the management chain and the bill chain (i.e., the application contract chain shown in FIG. 2). That is, the application contract chain here can provide the entire blockchain electronic bill platform with the functional characteristics of carrying out derivative business based on the core data in the electronic bill.
  • the consensus network 100a shown in Figure 1 the consensus network 100a shown in Figure 1 as an example.
  • the consensus nodes participating in the maintenance of the management chain can be the above-mentioned management consensus nodes.
  • multiple smart contracts are deployed on the management chain, and these smart contracts can run on the management consensus nodes.
  • the multiple smart contracts here can specifically include the object authority management contract, object identity management contract, metadata management contract and internal management contract shown in Figure 2. It should be understood that these smart contracts deployed on the management chain are determined by the internal participants (i.e., the tax management department) shown in Figure 2 through the corresponding management contract templates deployed on their own chains (i.e., the management chain).
  • the aforementioned tax administration department can exercise management responsibilities through the management consensus node deployed in the management chain network.
  • the management responsibilities here can specifically include managing the information within the government department (for example, the information of the internal personnel of the tax administration department), managing the business logic rules of the overall business (for example, the derivative business contract for executing the business logic of the derivative business running on the application contract chain), managing the metadata information of the overall business (for example, the access traffic at the entrance of each chain under the three-chain system), and managing the identity and rights of the participants of the overall business (for example, individual users, corporate users, tax business participants and other business objects).
  • the management chain maintained by the management consensus node is a relatively more stable blockchain with the smallest data scale but the highest security.
  • the core consensus network i.e., the above-mentioned bill chain network
  • the consensus node participating in the maintenance of the bill chain can be the above-mentioned first consensus node.
  • multiple smart contracts are deployed on the bill chain, and these smart contracts can run on the first consensus node.
  • the multiple smart contracts here can specifically include the electronic bill issuance contract, the electronic bill circulation contract, the electronic bill red-chase contract, the electronic bill archiving contract and the first cross-chain reading contract shown in FIG. 2.
  • these smart contracts deployed on the bill chain are determined by the internal participants shown in FIG. 2 (for example, the tax department associated with the electronic bill data center) through the corresponding bill business contract template deployed on the management chain.
  • the first consensus node deployed in the bill chain network can maintain the business logic of the electronic bill throughout its life cycle through the bill chain.
  • the bill chain can manage the full life cycle of all issued electronic bills.
  • the full life cycle of the electronic bill here includes the issuance of electronic bills, the circulation of electronic bills, and the reimbursement of electronic bills.
  • the bill chain maintained by the first consensus node has the characteristics of high performance and low latency.
  • the core consensus network where the application contract chain is located i.e., the above-mentioned application contract chain network
  • the consensus node involved in maintaining the application contract chain can be the above-mentioned second consensus node.
  • multiple smart contracts are deployed on the application contract chain, and these smart contracts can specifically run on the second consensus node.
  • the multiple smart contracts here can specifically include the virtual machine compatible contract, open contract deployment contract, derivative business contract and second cross-chain reading contract shown in Figure 2.
  • the second consensus node deployed in the application contract chain network can carry the derivative business corresponding to the variable bill business through the application contract chain.
  • 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 departments and alliance chain partners shown in Figure 2 (i.e., the business-related departments shown in Figure 2), and indirectly call the second cross-chain reading contract through the tax application contract (open contract deployment contract) shown in Figure 2, so as to use the management application contract template read across the chain to develop smart contracts related to derivative businesses (for example, the derivative business contract shown in Figure 2), 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 implement smart contracts through virtual machine compatible contracts. Flexible upgrades and changes.
  • the second consensus node can realize cross-chain interaction through the second cross-chain reading contract on the application contract chain.
  • the above core data can be read from the bill chain through the second cross-chain reading contract to execute derivative business.
  • the application contract chain maintained by the first consensus node 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 the performance is relatively lower than the bill chain.
  • the consensus algorithm adopted by the management chain is different from the consensus algorithm adopted by the bill chain and the consensus algorithm adopted by the application contract chain.
  • the consensus algorithm associated with the management chain is an instant deterministic consensus algorithm, 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 consensus nodes in the management chain network (i.e., the above-mentioned management consensus nodes) can be managed by the tax management department shown in Figure 2.
  • the internal participant associated with the management chain can be the tax management department shown in FIG. 2.
  • the tax management department when the tax management department participates in the management chain as an internal participant, it can manage some internal states of the tax management department through the internal management contract on the management chain. For example, it can manage the various personnel in the tax management department. For example, it can configure specific tax management personnel, tax development personnel, tax audit personnel, etc. among these personnel in the tax management department.
  • the tax management department participates in the management chain as an internal participant, it can also manage some parameters in the three-chain system through the internal management contract on the management chain. For example, the access traffic parameters corresponding to the access traffic at the entrance of the bill chain shown in FIG. 2 can be restricted through the internal management contract.
  • the access traffic at the entrance of the bill chain in certain specific time periods can be controlled through the time-sharing access mechanism to be not greater than the access traffic threshold.
  • the tax management department participates in the management chain as an internal participant, it can also limit the node number 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 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.
  • the network security of the application contract chain network where the application contract chain is located can be maintained through the proof-of-stake consensus algorithm, and the status of a proposed block to be on the chain can be immediately determined through the proof-of-stake consensus algorithm.
  • the consensus nodes in the application contract chain network can be jointly managed by the tax management department and the 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 tax personnel in the tax management department can read the bill information of the electronic bill written on the aforementioned bill chain through the consensus node in the application contract chain network, so as to execute the derivative business associated with the aforementioned bill business through the bill information read across the chain.
  • the bill information read across the chain can be used to request invoicing.
  • the invoicing enterprise is identified for qualifications or credit to obtain the qualification data or credit data of the invoicing enterprise.
  • the management chain shown in FIG2 can support a specific language smart contract engine, and the above 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 and internal management contract shown in FIG2 can be deployed on the management chain. It should be understood that these smart contracts can be developed and managed by specific tax management personnel in the tax management department.
  • the bill chain has built-in smart contracts with specific bill business logic.
  • These smart contracts for example, the electronic bill issuance contract, the electronic bill circulation contract, the electronic bill red-charge contract, the electronic bill archiving contract and the first cross-chain reading 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 consensus node associated with the bill chain can read part of the management chain information from the management chain through the first cross-chain reading contract shown in Figure 2.
  • the registration data information of the authorization object stored at the entrance of the bill chain can be read from the management chain; for example, the first business-related information used to confirm the business authority of the first business object can be read from the management chain, and the key information of the bill used for issuing electronic bills (for example, electronic invoices) can also be read from the management chain.
  • the key information of the bill here refers to the authorized visible auxiliary metadata information read from the management chain based on the electronic bill business in the bill business when the business authority is determined to be the billing authority type (for example, the updated electronic bill template recorded in the management).
  • the consensus node associated with the application contract chain can read part of the management chain information from the management chain through the second cross-chain reading contract shown in Figure 2.
  • the business participation license certificate for the authorization object stored in the application contract chain entry shown in Figure 2 can be read from the management chain
  • the second business association information for business authentication of the business object requesting to execute the derivative business can also be read from the management chain.
  • Part of the bill can also be read from the bill chain Chain information (for example, reading part of the authorized visible bill information in the electronic bill associated with the derivative business from the bill chain). It should be understood that part of the management chain information and part of the bill chain information read by the second consensus node from the management chain can be used to carry out the above-mentioned derivative 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 data flow systems shown in FIG2.
  • the local electronic bill data 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 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 data 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-off 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.
  • the developer shown in Figure 2 can also deploy derivative business contracts corresponding to other derivative businesses (or exploratory businesses) on the application contract chain when accessing the application contract chain. There is no limit on the number of derivative business contracts deployed on the application contract chain.
  • 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 FIG. 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 (for example, the first business object, which can be the above-mentioned enterprise B) can be received.
  • the transaction business data also referred to as transaction data
  • a certain business object for example, the first business object, which can be the above-mentioned enterprise B
  • first consensus node when the above-mentioned first consensus node receives the transaction business data submitted by the above-mentioned enterprise B through the electronic bill business entry, it can also verify through the electronic bill business entry whether the access identity and access authority of the data sender of the transaction business data (that is, enterprise B as the first business object) meet the status requirements of the identity authority contract in the management chain, and then when the verification is passed, it can be determined that enterprise B as the first business object is the authorized object, and then the business authority of enterprise B as the authorized object can be determined by reading the above-mentioned first business association information from the management chain through the first cross-chain reading contract on the bill chain. It should be understood that the first business association information can be used to further determine whether the business authority of enterprise B as the authorized object meets the status requirements of the object authority management contract in the management chain.
  • the first consensus node can determine whether the access identity and access rights of the data sender (i.e., enterprise B) meet the contract status requirements of the object identity management contract and the internal management contract in the management chain through the electronic bill business entry, and then determine to complete the identity authentication of the data sender (i.e., the aforementioned enterprise B) who needs to access the bill chain when it is determined that the contract status requirements of the object identity management contract and the internal management contract in the management chain are met.
  • the bill chain entry shown in Figure 2 stores the registration data information of each authorized object synchronized from the management chain, and the registration data information here can include but is not limited to the object access identity registration information and the object access right registration information.
  • the object access identity information here can be used to identify whether the first business object (i.e., the aforementioned enterprise B) currently requesting access to the bill chain is an authorized object.
  • the object access right registration information here includes the request accumulation threshold (e.g., the maximum concurrent request accumulation) configured by the management consensus node for the electronic bill business entry of the bill chain through the internal management contract.
  • the first business association information can be used to characterize which bill business contracts on the bill chain the first business object (i.e., the aforementioned enterprise B) as the authorized object has the authority to access.
  • the application contract chain entry shown in FIG. 2 can be specifically a tax derivative business entry.
  • the tax derivative business entry can receive a derivative business associated with the bill business requested to be participated in by a certain business object (for example, a second business object, which can be a tax business participant shown in FIG2).
  • a second business object which can be a tax business participant shown in FIG2
  • the tax business participant and the developer shown in FIG2 can verify the business participation license certificate submitted by the second business object (for example, the tax business participant or the developer) through the application contract chain entry, and then allow the second business object to access the application contract chain when the verification is successful, so as to execute the derivative business associated with the aforementioned bill business on the application contract chain.
  • the internal participants involved in maintaining the management chain can be the tax management department shown in Figure 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 may be the electronic bill data center shown in FIG2 , where the electronic bill data center may specifically be an electronic invoice data center, which may be used for off-chain backup, statistics, data analysis and review of the massive amount of account book data recorded on the bill chain (e.g., the electronic bill flow generated based on the above-mentioned real-time bill business flow, etc.).
  • the electronic bill data center may count the number of invoices issued at different times, and then the risk bills (e.g., risk invoices) and risky enterprises may be judged based on the counted number of invoices issued at different times, and data analysis of relevant financial and economic data may also be performed.
  • the internal participants participating in the maintenance of the application contract chain 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, which can further execute corresponding derivative businesses through the derivative business contracts on the application contract chain when accessing the application contract chain.
  • 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, which can further execute corresponding derivative businesses through the derivative business contracts on the application contract chain when accessing the application contract chain.
  • the government cooperation departments and business-related departments shown in FIG2, as tax business participants, have the advantage of accessing the application contract chain in that they can flexibly run various scalable derivative businesses in the support of a complete smart contract declaration cycle to ensure the flexibility of business changes, and at the same time, do not need to directly contact the core data of the electronic invoice on the above-mentioned bill chain, thereby ensuring the data privacy and core data security on the bill chain.
  • the second consensus node involved in the embodiment of the present application can read the bill chain data that is partially authorized and visible for the current derivative business on the bill chain through the second cross-chain reading contract on the application contract chain (specifically, it can use the cross-chain reading method in the second cross-chain reading contract).
  • the core data related to the current derivative business can be read from the bill chain across the chain (the core data here can be the bill information in each electronic bill involved in the above-mentioned electronic bill flow.
  • the bill data here can specifically be the partially authorized and visible invoice data) to ensure that the derivative business requested by the above-mentioned second business object can be effectively carried out on the application contract chain through the read core data.
  • the second consensus node in order to increase the data privacy of the electronic bill located on the bill chain, can also request the first consensus node corresponding to the bill chain to read the electronic bill associated with the derivative business (for example, the electronic bill issued by Enterprise C) on the bill chain through the target chain identifier indicated by the cross-chain authorization method in the second cross-chain reading contract, and then return the bill information associated with the derivative business to the second consensus node as the aforementioned authorized visible core data in the bill information of the read electronic bill.
  • the derivative business for example, the electronic bill issued by Enterprise C
  • the object identity management contract built into the management chain can be specifically a user management contract, through which the identities of accessors (for example, public network participants) and participants (for example, internal participants) in the entire three-chain system can be managed. It should be understood that the access here is The specific participants and participants can include tax management personnel (administrators for short), government cooperation departments, local tax bureaus, invoicing service providers, reimbursement service providers, tax audit departments, etc.
  • the object authority management contract built into the management chain can be a corporate identity management contract, through which the business authority and tax status of certain enterprises can be managed.
  • the metadata management contract built into the management chain can be a tax metadata management contract, through which metadata information such as tax rules can be managed, such as centralized management of contract modules, tax calculation logic, and the latest policy rules under the three-chain system.
  • the internal management contract built into the management chain can be used to manage some internal states of the tax management department, and can manage some internal parameters of each chain under the three-chain system, such as the access flow parameters at the above-mentioned bill chain entrance (for example, the electronic invoice business entrance) can be restricted through the internal management contract, and the number of consensus nodes under the three-chain system can be restricted.
  • the smart contract built into the bill chain can include a cross-chain reading contract and a bill business contract associated with the electronic bill life cycle.
  • the cross-chain reading contract here can be the first cross-chain reading contract shown in Figure 2
  • the bill business contract here can specifically include the electronic bill issuance contract for providing electronic bill issuance business, the electronic bill circulation contract for providing electronic bill circulation business, the electronic bill red-reversal contract for providing electronic bill red-reversal business, and the electronic bill archiving contract for providing electronic bill archiving business.
  • the first cross-chain reading contract can be used to read the metadata information on the management chain across the chain to update some business parameters on the bill chain.
  • the template parameters of the electronic bill template on the bill chain can be updated. It can be seen that part of the management chain information on the management chain (for example, the metadata information on the management chain) is authorized to be visible to the first consensus node running the first cross-chain reading contract and the second consensus node running the second cross-chain reading contract.
  • the smart contract built into the bill chain can include another cross-chain reading contract (i.e., the second cross-chain reading contract), and can also include various contracts deployed by tax derivative business participants (i.e., derivative business objects, for example, the tax business participants shown in Figure 2) (for example, the virtual machine compatible contract, tax application contract, and derivative business contract shown in Figure 2, etc.).
  • the derivative business contract here can specifically be a credit investigation business contract based on electronic bills, through which the credit investigation business contract can be analyzed to obtain the credit investigation data of a certain enterprise.
  • the derivative business contract here can also specifically be an on-chain lottery business contract, a talent incentive contract, and a tax refund business contract deployed to encourage invoicing.
  • the second cross-chain reading contract here can be used to cross-chain read metadata information on the management chain (for example, the latest policy rules associated with the tax refund business) to update some business parameters of the application contract chain (for example, the contract parameters of the tax refund business contract deployed on the application contract chain can be updated).
  • the second cross-chain reading contract here can also be used to cross-chain read partially authorized and visible bill information on the bill chain, so as to execute the business logic of the derivative business on the application contract chain through the partially authorized and visible bill information read across the chain.
  • management chain shown in FIG. 2 it is mainly used to process management business flows with small data volume and relatively constant state.
  • the openness of the entire management chain is relatively low, and it can be used for internal management of some tax data.
  • bill chain shown in FIG. 2 above it can be used to process some real-time bill business flows with a long-term high-frequency request state.
  • the openness of the entire bill chain is relatively high, and relevant authoritative institutions in the life cycle of the electronic bill itself can be allowed to participate in the corresponding bill business.
  • the consensus node corresponding to the agent service provider can be allowed to issue an electronic bill for a user who currently requests invoicing.
  • the size of the data volume can be unlimited, and the frequency of business changes fluctuates relatively large. It is mainly possible to process various types of cooperative business, derivative business, exploratory business, etc. through the application contract chain.
  • the application contract chain has the highest openness, and can run participants authorized by the management chain to deploy smart contracts on the application contract chain, run exploratory derivative business, etc.
  • the smart contract built into the application contract chain can have more contract security restrictions when it is executed.
  • the number of contract execution steps can be limited (for example, for the derivative business contract shown in Figure 2 above, it can be limited which contract methods in the derivative business contract the current business object (i.e., the second business object) can access), and the storage resource data required to access the derivative business contract can be restricted (i.e., the call of the smart contract on the application contract needs to consume a certain amount of storage resources). storage resource data).
  • the consensus node under the three-chain system involved in the embodiment of the present application can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, and big data and artificial intelligence platforms.
  • the consensus node in the embodiment of the present application obtains the registration data information, business participation license certificate, ticket information in the electronic invoice and other data of the business object (for example, the above-mentioned individual user or corporate user) across the chain, it can display a prompt interface or pop-up window.
  • the prompt interface or pop-up window is used to prompt the business object that it is currently collecting registration data information, business participation license certificate, ticket information in the electronic invoice and other data. Only after the business object issues a confirmation operation on the prompt interface or pop-up window, the relevant steps of data acquisition are started, otherwise it ends.
  • business data of business objects such as users, enterprises, and institutions may be involved (for example, users' invoicing information, credit information, tax refund information, etc., and enterprises' income and expenditure, enterprise qualifications, etc.).
  • business objects such as users, enterprises, and institutions
  • the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.
  • Figure 3 is a multi-blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by the first consensus node in the first chain network, for example, the first consensus node can be any consensus node in the consensus network 200a shown in Figure 1.
  • the method can specifically include the following steps S101-S103.
  • Step S101 obtaining a first business requested by a first business object, calling a first cross-chain read contract on a first chain based on the first business, and reading first business-related information associated with the first business from a target chain;
  • the first chain is a blockchain in a first chain network;
  • the target chain is a blockchain in a target chain network;
  • the target chain network is independent of the first chain network, and the first chain is different from the target chain;
  • the first chain network involved in the embodiment of the present application is a consensus network in the above-mentioned blockchain electronic bill three-chain network.
  • the first chain network is deployed in a relatively secure private cloud, and each consensus node in the first chain network in the private cloud runs a blockchain consensus protocol based on the above-mentioned TBFT consensus algorithm. In this way, the access security between the consensus nodes in the first chain network can be ensured through the consensus mechanism corresponding to the aforementioned blockchain consensus protocol.
  • the public network participant requesting access to the first chain network may be collectively referred to as a first business object, and then the identity of the first business object may be authenticated through the aforementioned first chain entry.
  • the chain entry corresponding to the first chain network can be the above-mentioned first chain entry (the first chain entry here can also be specifically an electronic invoice business entry); the first chain entry stores the registration data information of the authorization object synchronized from the target chain by the first consensus node through the first cross-chain reading contract at the time of the first cross-chain reading timestamp;
  • the first consensus node can obtain, through the first chain entrance of the first chain network, a first business processing request sent by the first business node corresponding to the first business object based on the first business; the first business processing request carries the transaction business data submitted by the first business object for the first business, and the first signature information of the first business object; the first signature information is obtained by the first business node associated with the first business object signing the transaction business data through the first private key information of the first business object; the first private key information of the first business object is the first business object through the object identity in the target chain
  • the first consensus node can obtain the first signature information from the first business processing request, and perform signature verification on the first signature information based on the registration data information of the authorization object stored in the first chain entry to obtain the signature verification result of the first business object; further, the first consensus node can determine that the first business object is an authorization object when the signature verification result of the first business object indicates that the signature verification is successful, and determine the first business associated with the first business object based on the transaction business data; further, the first
  • the first business can include but is not limited to the bill business associated with electronic bills, the certificate business associated with electronic certificates, and the prescription business associated with electronic prescriptions, that is, the embodiment of the present application can be constructed according to different business application scenarios to obtain a three-chain system adapted to different business scenarios.
  • the first business is the bill business associated with electronic bills as an example to explain the specific process of executing the bill business in the first chain network.
  • Figure 4 is a schematic diagram of a scenario for identity authentication through a chain entry provided by an embodiment of the present application.
  • user 43b can be the above-mentioned first business object, that is, at this time, user 43b is the above-mentioned public network participant requesting access to the first chain network 40a.
  • the user terminal 43a used by the user 43b can be the first business node corresponding to the first business object.
  • the first business node here can be a business node in the business network 400a shown in Figure 1 above.
  • the first business node here can be used to execute a transaction (for example, a transfer transaction) to obtain the transaction business data corresponding to the transfer transaction, and then the transaction business data and the signature information of the user 43a (ie, the first business object) can be added to the first business processing request shown in Figure 4 to send the first business processing request to the chain entry 42a corresponding to the first chain network 40a shown in Figure 4.
  • a transaction for example, a transfer transaction
  • the transaction business data and the signature information of the user 43a ie, the first business object
  • the chain entry 42a here is the first chain entry.
  • the first chain entry can be used to store the registration data information of the authorization object shown in FIG4 , and the registration data information of the authorization object can specifically include the public key certificate A1 of the authorization object A, the public key certificate B1 of the authorization object B, ..., and the public key certificate N1 of the authorization object N shown in FIG4 .
  • the registration data information of the authorized object stored at the chain entry 42a is synchronized by the consensus node in the first chain network 40a from the target chain 42e shown in Figure 4. Since the above-mentioned TBFT consensus algorithm is run in the consensus node in the first chain network, in the TBFT consensus algorithm, the leader node is rotated. Assuming that the leader node used for continuous block generation in the previous round is the consensus node 41c shown in Figure 4, and the leader node used for continuous block generation in this round is the consensus node 41d shown in Figure 4, then the consensus node 41c can be used as the first consensus node in the previous round, and the consensus node 41d can be used as the new first consensus node in this round.
  • the registration data information of the authorization object stored at the chain entry 42a may specifically include the registration data information of the first type of authorization object (e.g., the public key certificate A1 of the authorization object A and the public key certificate B1 of the authorization object B) synchronized from the target chain (e.g., the target chain 42e shown in FIG4) by the consensus node 41c, which has historically been the first consensus node, through the first cross-chain reading contract shown in FIG4, and may also include the registration data information of the second type of authorization object (e.g., the public key certificate N1 of the authorization object N) synchronized from the target chain (e.g., the target chain 42e shown in FIG4) by the consensus node 41d, which is currently the first consensus node, through the first cross-chain reading contract shown in FIG4.
  • the first type of authorization object e.g., the public key certificate A1 of the authorization object A and the public key certificate B1 of the authorization object B
  • the consensus node 41c which has historically been the first consensus node, through the first cross
  • the registration data information of the first type of authorization object and the registration data information of the second type of authorization object are mainly used to distinguish which ones are synchronized by themselves as the first consensus node and which ones are synchronized by other nodes as the first consensus node.
  • the embodiments of the present application may collectively refer to the timestamps of historical calls to the first cross-chain read contract by the consensus nodes in the first chain network 40a (for example, the aforementioned consensus node 41c and consensus node 41d) as the first cross-chain read timestamp, and may collectively refer to the timestamps of current calls to the first cross-chain read contract by the consensus nodes in the first chain network 40a (for example, consensus node 41d) as the second cross-chain read timestamp, that is, the second cross-chain read timestamp here is the timestamp after the first cross-chain read timestamp, and the timestamp interval between the second cross-chain read timestamp and the first cross-chain read timestamp is not limited here.
  • consensus node 41d as the first consensus node as an example to explain the specific process of identity authentication for user 43b. That is, the first consensus node can specifically use the identity authentication method in the first cross-chain reading contract when reading the timestamp of the first cross-chain to synchronize the public key of the authorization object N from the target chain (for example, the target chain 42e).
  • the key certificate N1 is added to the registration data information of the authorization object shown in Figure 4, so that the identity of the first business object currently requesting to execute the first business can be quickly authenticated based on the registration data information of the authorization object stored locally in the chain entry 42a, thereby improving the processing efficiency of real-time business flows in the first chain network 40a.
  • the real-time business flow here can specifically be a real-time electronic bill flow, that is, the real-time electronic bill flow can specifically refer to the bill business flow composed of a large number of bill businesses in a high-frequency request state determined by the first consensus node through the aforementioned first chain entry (for example, chain entry 42a).
  • the first chain entry for example, chain entry 42a
  • the request accumulation threshold here is used to characterize the access traffic at the first chain entry, and it should be understood that the request accumulation threshold here includes but is not limited to the maximum concurrent request accumulation amount). It should be understood that the maximum concurrent request accumulation amount of the first business processing request obtained by the chain entry 42a is specifically determined by the internal management contract running on the management consensus node in the target chain network 40b.
  • the internal management contract running on the target consensus node (for example, the consensus node 42a shown in Figure 4) can be used to manage the maximum concurrent request accumulation amount obtained at each chain entry under the three-chain system. It should be understood that by controlling the concurrent access traffic at each chain entry (i.e., the aforementioned maximum concurrent request accumulation amount), the stable execution of the first business flow in the first chain network 40a can be effectively ensured, and then the first consensus node can be ensured to have sufficient storage resources to store the business data flow composed of a large amount of business data.
  • the embodiment of the present application can collectively refer to the signature information of the user 43a (i.e., the first business object) as the first signature information, and the first signature information is obtained after the user 43a (i.e., the first business object) signs the aforementioned transaction business data through his own private key information (i.e., the first private key information of the first business object).
  • the cumulative request amount corresponding to the first business processing request can be statistically obtained, and then when the cumulative request amount corresponding to the first business processing request does not reach the request cumulative threshold (for example, the above-mentioned maximum concurrent request cumulative amount), the access permission verification (also referred to as access permission verification) of the user 43b can be preliminarily completed.
  • the request cumulative threshold for example, the above-mentioned maximum concurrent request cumulative amount
  • the first consensus node can further obtain the first signature information of the first business object from the first business processing request, and then quickly obtain the public key certificate of the authorization object from the registration data information of the authorization object stored in the chain entry 42a (for example, the public key certificate A1 of the authorization object A, the public key certificate B1 of the authorization object B,..., the public key certificate N1 of the authorization object N shown in Figure 4), so as to authenticate the identity of the user 43b through these obtained public key certificates.
  • the public key certificate of the authorization object for example, the public key certificate A1 of the authorization object A, the public key certificate B1 of the authorization object B,..., the public key certificate N1 of the authorization object N shown in Figure 4
  • the embodiment of the present application can directly reject the first business processing request sent by the user 43b when the cumulative amount of requests corresponding to the first business processing request reaches the request cumulative threshold (for example, the above-mentioned maximum concurrent request cumulative amount), and generate a notification message to prompt the user 43b to wait for access.
  • the request cumulative threshold for example, the above-mentioned maximum concurrent request cumulative amount
  • the public key certificate of each authorized object here contains the public key information of the corresponding authorized object.
  • the first consensus node can further search for the public key certificate of these authorized objects to see whether the public key certificate of user 43b exists. 1) If it exists, the public key certificate of user 43b can be used as the first public key certificate of the first business object found, and then the public key information of user 43b recorded in the first public key certificate can be used as the first public key information, so as to perform signature verification on the aforementioned first signature information through the first public key certificate and the first public key information, so as to obtain the signature verification result of the first business object.
  • the first consensus node does not search for the public key certificate of user 43b in the public key certificates of these authorized objects to see whether there is the public key certificate of user 43b, then the user 43b (i.e., the first business object) is confirmed to be an illegal business object, and then the first business processing request sent by the user 43b as an illegal business object can be rejected.
  • the embodiment of the present application can further combine the certificate data information of the public key certificate stored at the chain entry 42a (for example, the version information of the certificate, the hash value of the certificate, and the root certificate hash value associated with the hash value of the certificate, etc.) to perform signature verification on the above-mentioned first signature information to ensure the reliability of the public key information (that is, the aforementioned first public key information) in the public key certificate (that is, the aforementioned first public key certificate) used for signature verification.
  • the certificate data information of the public key certificate stored at the chain entry 42a for example, the version information of the certificate, the hash value of the certificate, and the root certificate hash value associated with the hash value of the certificate, etc.
  • the first consensus node can use the certificate data information of the first public key certificate as the certificate information to be processed, and can call the certificate data reading method in the first cross-chain reading contract at the second cross-chain reading timestamp to read the public key certificate of the first business object from the target chain; the second cross-chain reading timestamp is the next cross-chain reading time of the first cross-chain reading timestamp. Stamp; further, the first consensus node can use the certificate data information in the public key certificate of the first business object read as the target certificate information, and then when the certificate information to be processed is consistent with the target certificate information, the first signature information can be verified based on the first public key information, and the verification result when the signature verification is successful can be used as the signature verification result of the first business object.
  • the certificate information to be processed is consistent with the target certificate information, it is necessary to use the public key certificate of the user 43b read from the target chain during the second cross-chain reading timestamp to update the aforementioned first public key certificate, and then the first signature information can be signed and verified through the public key information in the updated first public key certificate to ensure that the first business requested by the user 43b can be successfully executed in the first chain network.
  • the public key certificate of the authorized object involved in the embodiment of the present application is obtained by the target consensus node in the target chain network calling the object identity management contract in the target chain (that is, the object identity management contract in the embodiment corresponding to Figure 2 above) to register the object data information submitted by the business object requesting to register the corresponding transaction business (for example, the aforementioned first business)
  • the object data information here can specifically include the basic user data information of the above-mentioned user 43b, the transaction business that the above-mentioned user 43b needs to execute, and the business type of the transaction business, etc.
  • the target consensus node successfully registers the request
  • the business object requesting to register the corresponding transaction business for example, the aforementioned first business
  • the business object requesting to register the corresponding transaction business for example, the aforementioned first business
  • the target consensus node after the target consensus node writes the public key certificate configured for the authorization object (e.g., user 43b shown in FIG. 4) into the target chain (e.g., target chain 41e shown in FIG. 4), it can also return the private key information (i.e., the above-mentioned first private key information) synchronously configured for the authorization object (e.g., user 43b shown in FIG. 4) to the user 43b, so that the user 43b, when acting as the above-mentioned first business object, can sign the transaction business data submitted by itself through the first private key information to obtain the above-mentioned first signature information.
  • the private key information i.e., the above-mentioned first private key information
  • the first private key information of the first business object here is obtained after the first business object (e.g., user 43b shown in FIG. 4) registers its identity through the object identity management contract in the target chain.
  • the first signature information here is obtained by the first business node associated with the first business object (e.g., user 43b shown in FIG. 4) through the first private key information of the first business object (e.g., user 43b shown in FIG. 4) after signing the aforementioned transaction business data.
  • the first consensus node can authenticate the user 43b through the registration data information of the authorization object obtained from the chain entry 42a, and then determine that the user 43b is an authorization object when the identity authentication is successful, so as to allow the user 43b to access the first chain network 40a as an accessor.
  • the first consensus node can perform transaction assembly on the aforementioned transaction business data in the first chain network to obtain the first business associated with the first business object, and can broadcast the first business as a new transaction in the first chain network to perform transaction weight verification on the new transaction in the first chain network, and then can add the new transaction to the transaction pool corresponding to the aforementioned real-time first business flow when the transaction weight verification is successful (i.e., it is determined that there is no first business identical to the new transaction in the first chain network), and then can call the first cross-chain reading contract shown in FIG4 based on the first business in these real-time first business flows in the transaction pool, and read the first business association information associated with these first businesses on the target chain 42e across the chain, and then can further perform the following step S102 based on the first business association information read across the chain.
  • the first consensus node can call the permission contract reading method in the first cross-chain read contract based on the first business, and generate a permission contract access request for sending to the target consensus node (for example, consensus node 42a) in the target chain network (i.e., the target chain network 40b shown in Figure 4); the permission contract access request is used to instruct the target consensus node (for example, consensus node 42a) to call the object permission management contract on the target chain to obtain the first business association information associated with the first business; further, the first consensus node can receive the first business association information returned by the target consensus node based on the permission contract access request, so as to further execute the following step S102.
  • the target consensus node for example, consensus node 42a
  • the target chain network i.e., the target chain network 40b shown in Figure 4
  • the permission contract access request is used to instruct the target consensus node (for example, consensus node 42a) to call the object permission management contract on the target chain to obtain the first business association information associated with the first business
  • Step S102 when it is determined based on the first business association information that the first business object has the first business processing authority corresponding to the first business, the first business processing contract on the first chain is called to execute the first business, a first business execution result associated with the first business is obtained, and the first business execution result is written into the first chain; the first business execution result includes business data indicated by the first business;
  • the first business association information includes the business authority type configured for the first business object, the accumulated business volume of the first business object with the business authority type within the business duration, and the business accumulation threshold; specifically, the first consensus node can determine that the first business object has the first business processing authority corresponding to the first business when the business authority type of the first business object is the invoicing authority type based on the first business association information, and the accumulated business volume of the first business object with the invoicing authority type within the business duration does not reach the business accumulation threshold; further, the first consensus node can obtain the contract call address and contract call name associated with the invoicing authority type based on the first business processing authority, call the business data on the first chain through the contract call address and the contract call name, and convert the transaction business data corresponding to the first business and the invoicing authority in the first business into a contract.
  • the key information of bills associated with the business data issuance business is integrated, and an electronic bill is issued for the first business object based on the integrated key information of the bill, and the issued electronic bill is used as the business data indicated by the first business; further, the first consensus node can use the key information of the bill, the business data, and the business data issuance contract as the first business execution result of the business data issuance business in the first business, and send the first block containing the first business execution result to the verification consensus node on the first chain, so that the verification consensus node performs block verification on the first block to obtain the block verification result; the verification consensus node is the remaining consensus node in the first chain network except the first consensus node; it should be understood that the verification consensus node here (i.e.
  • the above-mentioned bill verification consensus node specifically refers to the remaining consensus node in the first chain network except the first consensus node. Further, the first consensus node can receive the block verification result returned by the target consensus node, and if the block verification result indicates that the block verification is successful, the first block is written into the first chain.
  • the key information of the bill may include auxiliary metadata information in the metadata information read from the target chain, and the auxiliary metadata information includes the first business data template and the target tax calculation rule associated with the first business data template;
  • the first business data template is the business data template after the target consensus node on the target chain calls the metadata management contract on the target chain to change the second business data template on the chain;
  • the second business data template is the previous business data template of the first business data template;
  • the metadata change information is submitted by the business management object associated with the target consensus node (the business-related object here can be the tax-related department in the embodiment corresponding to Figure 2 above).
  • the embodiment of the present application will not limit the specific business quantity and specific business type of the first business in the real-time business flow determined in the first chain network.
  • the embodiment of the present application takes the business type of the first business requested by the user 43a shown in Figure 4 as the electronic invoice issuance business in the above-mentioned bill business as an example to illustrate that by reading the business association information associated with the electronic invoice issuance business (i.e. the aforementioned first business association information) from the target chain 42e, the business authority of the user 43b is further determined to be the first business processing authority.
  • the first business processing authority here can be used to characterize that the user 43b has the authority to call the first business execution contract on the first chain 41e to execute the first business (for example, the aforementioned electronic invoice issuance business).
  • the first business association information here specifically includes the business authority type configured for the user 43b shown in Figure 4 above, the business cumulative amount of the user 43b with the business authority type within the business duration, and the business cumulative threshold; the business authority type here is configured by the target consensus node through the above-mentioned object authority management contract for the user 43b shown in Figure 4 requesting the first business (i.e., the above-mentioned first business object).
  • the business authority type here specifically includes the invoicing authority type, the transfer authority type, the red-chase authority type, and the archiving authority type.
  • the business authority type here can specifically include the certificate issuance authority type, the transfer authority type, and the archiving authority type. It should be understood that, optionally, when the first business is the aforementioned prescription business, the business authority type here can specifically include the prescription issuance authority type, the transfer authority type, and the archiving authority type. It should be understood that in different business scenarios, the specific contract in the first business execution contract deployed on the first chain can be adjusted in combination with the corresponding business authority type.
  • the target consensus node can configure the corresponding business authority for user 43b through the object authority management contract.
  • the type is the above-mentioned business authority type (for example, the invoicing authority type configured for calling the electronic invoice issuance contract on the first chain), and the business accumulation amount and business accumulation threshold of the user 43b with the business authority type (for example, the invoicing authority type) within the business duration (for example, 1 hour).
  • the business authority type for example, the invoicing authority type
  • the business accumulation amount and business accumulation threshold of the user 43b with the business authority type (for example, the invoicing authority type) within the business duration for example, 1 hour
  • the target chain for example, the target chain 42e shown in Figure 4
  • the first consensus node determines that the business authority type of the user 43b is the aforementioned invoicing authority type based on the first business-related information obtained from the target chain, it can further determine whether the business accumulation amount of the user 43b with the invoicing authority type within the aforementioned business duration has reached the business accumulation threshold (for example, when the user 43b is an invoicing enterprise, the business accumulation amount here specifically refers to whether the number of invoices issued by the invoicing enterprise within 1 hour has reached the maximum number of invoices, and whether the invoicing amount has reached the maximum invoicing amount).
  • the contract call address and contract call name associated with the invoicing authority type can be obtained based on the first business processing authority corresponding to the first business, so as to call the electronic invoice issuance contract on the first chain through the contract call address and contract call name, and obtain the invoice key information associated with the electronic invoice issuance business, and then the obtained invoice key information can be integrated to issue an electronic invoice for the user 43b through the integrated invoice key information (the electronic invoice here can specifically be an electronic invoice).
  • the embodiment of the present application may collectively refer to the issued electronic invoice as the business data indicated by the aforementioned first business.
  • the first consensus node determines that the business permission type of the user 43b is the aforementioned transfer permission type based on the first business association information obtained from the target chain, it can further determine whether the business accumulation amount of the user 43b with the transfer permission type within the aforementioned business duration has reached the business accumulation threshold (for example, when the user 43b is a reimbursement user, the business accumulation amount here specifically refers to whether the reimbursement amount of the reimbursement user within 1 month has reached the maximum reimbursement amount).
  • the contract call address and contract call name associated with the transfer permission type can be obtained based on the first business processing permission corresponding to the first business, so as to call the electronic bill transfer contract on the first chain through the contract call address and contract call name, and transfer the electronic bill issued for the above user 43b (the electronic bill here can be specifically an electronic invoice) to the second business object.
  • the second business object here can be other users associated with the first business object (for example, the local tax bureau user of the place where the user 43b is located).
  • the first consensus node determines that the business authority type of the user 43b is the aforementioned red-refund authority type based on the first business-related information obtained from the target chain, it can be further determined whether the business accumulation amount of the user 43b with the red-refund authority type within the aforementioned business duration has reached the business accumulation threshold (for example, when the user 43b is a red-refund user, the business accumulation amount here specifically refers to whether the number of red-refunds of the reimbursement user within 1 month has reached the maximum number of red-refunds).
  • the contract call address and contract call name associated with the red-refund authority type can be obtained based on the first business processing authority corresponding to the first business, so as to call the electronic bill red-refund contract on the first chain through the contract call address and contract call name, and issue a red-letter invoice for the electronic bill (the electronic bill here can be specifically an electronic invoice) issued for the above-mentioned user 43b for red-refund.
  • the red-letter invoice here can be used to correct the relevant bill information in the electronic invoice.
  • the first consensus node determines that the business permission type of the user 43b is the aforementioned archiving permission type based on the first business association information obtained from the target chain, it can further determine whether the business accumulation amount of the user 43b with the archiving permission type within the aforementioned business duration has reached the business accumulation threshold (for example, when the user 43b is an archiving user, the business accumulation amount here specifically refers to whether the number of archived bills of the archiving user within 1 month has reached the maximum number of archived bills).
  • the contract call address and contract call name associated with the archiving permission type can be obtained based on the first business processing permission corresponding to the first business, so as to call the electronic bill archiving contract on the first chain through the contract call address and contract call name, and perform cold storage processing on the electronic bill (the electronic bill here can specifically be an electronic invoice) issued for the above-mentioned user 43b.
  • the first consensus node here can call the electronic bill archiving contract to expire for a long time (that is, it can no longer be circulated)
  • the electronic bills with fewer cross-chain requests are cold stored to release the ledger storage resources of the blockchain ledger corresponding to the bill chain.
  • the first business here includes at least one of the following transaction businesses: electronic bill issuance business, electronic bill circulation business, electronic bill red-check business, and electronic bill archiving business;
  • the bill business processing contract includes at least: an electronic bill issuance contract for executing the electronic bill issuance business, an electronic bill circulation contract for executing the electronic bill circulation business, an electronic bill red-check contract for executing the electronic bill red-check business, and an electronic bill archiving contract for executing the electronic bill archiving business; wherein, the electronic bill issuance business is used to instruct the first consensus node to call the electronic bill issuance contract on the bill chain to issue an electronic invoice for the first business object; the electronic bill circulation business is used to instruct the first consensus node to call the electronic bill circulation contract on the bill chain to transfer the electronic invoice from the first business object to the second business object; the electronic bill red-check business is used to instruct the first consensus node to call the electronic bill red-check contract on the bill chain to issue a red-letter invoice corresponding to the electronic invoice, and the red-letter invoice is used
  • the above-mentioned real-time business flow can specifically be a real-time electronic prescription flow, that is, the real-time electronic prescription flow can specifically refer to a prescription business flow composed of a large number of prescription businesses in a high-frequency request state determined by the first consensus node through the aforementioned first chain entrance (for example, chain entrance 42a).
  • the first chain network corresponding to the first chain entrance can specifically be a prescription chain network.
  • the real-time business flow here can specifically be a real-time electronic certificate flow, that is, the real-time electronic certificate flow can specifically refer to a certificate business flow composed of a large number of certificate businesses in a high-frequency request state determined by the first consensus node through the aforementioned first chain entry (for example, chain entry 42a).
  • the first chain network corresponding to the first chain entry can specifically be a certificate chain network.
  • the specific implementation method of executing prescription business and certificate business in the first chain network can refer to the above-mentioned description of the specific process of executing bill business in the first chain network, and will not be further described here.
  • the first consensus node when the first consensus node writes the first business execution result into the first chain, it can also specify the processing terminal identifier of the business data processing terminal associated with the business data in the target transaction corresponding to the first business execution result; the processing terminal identifier is used to characterize that the business data processing terminal has the function of clearing business data from the first chain; it should be understood that the business data processing terminal here can be the terminal corresponding to the electronic bill data center in the embodiment corresponding to the above-mentioned Figure 2.
  • the first consensus node when it obtains the transaction clearing request sent by the business data processing terminal, it can obtain the target transaction from the first chain based on the processing terminal identifier carried in the transaction clearing request, and clear the business data from the first business execution result contained in the target transaction, and return the business data to the business data processing terminal, so that the business data processing terminal can perform data analysis on the business data (for example, bill analysis).
  • the invoice analysis here specifically refers to the fact that the above-mentioned electronic invoice data center can use the business data processing terminal to perform off-chain statistics on a large number of electronic invoices recorded on the first chain (for example, counting the number of invoices issued by the user 43a as the invoicing enterprise at different times), data analysis (for example, analyzing the invoice amount and invoice amount of the user 43a as the invoicing enterprise to make a risk assessment on the user 43a.
  • the above-mentioned tax management department is notified to call the object authority management contract on the first chain to freeze the invoicing qualification of the user 43a, or limit the invoicing amount of the user 43a), and tax review (reviewing the tax payment situation of the above-mentioned user 43a).
  • Step S103 when the cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain is obtained, the business data is read from the first chain based on the second business carried in the cross-chain read request, and the core data in the business data is returned to the second consensus node; the second consensus node is used to write the second business execution result corresponding to the second business into the second chain after executing the second business based on the core data; the second chain is the blockchain in the second chain network where the second consensus node is located, and the second chain network is independent of the first chain network and the target chain network.
  • the first consensus node when the first consensus node obtains the cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, it obtains the second business submitted by the second business object through the second business entry associated with the second chain from the cross-chain read request; wherein, the second business entry is used to allow the second business object to call the second cross-chain read contract through the second consensus node when it is determined that the second business object has the authority to process the second business on the second chain; further, the first consensus node can read the business data from the first chain based on the cross-chain request data information indicated by the second business, and use the core data in the read business data as the cross-chain request response information corresponding to the cross-chain read request, and return the cross-chain request response information to the second consensus node, so that the second consensus node calls the second business contract on the second chain based on the cross-chain request response information to execute the second business. It should be understood that in the embodiment of the present application, if the second business is a derivative business
  • the embodiment of the present application combines the first chain network 40a and the target chain network 40b shown in Figure 4 above to explain how to achieve mutual cooperation between the three chains in the blockchain system.
  • Figure 5 is a schematic diagram of a scenario of cross-chain interaction between the three chains through the embodiment of the present application.
  • the user 53a shown in Figure 5 can be a second business object requesting to execute the second business, and the user terminal 53a used by the user 53a can be a second business node.
  • the second business node here can be the same as the first business node mentioned above, or it can be different from the first business node mentioned above, and it will not be limited here.
  • the chain entry 52a shown in Figure 5 is the second chain entry, and the second chain entry here can be the tax-derived business entry in the embodiment corresponding to Figure 2 above.
  • the tax-derived object for example, the user 53b shown in Figure 5
  • the tax-derived object can access the second chain network 500a shown in Figure 5 through the business participation license certificate after obtaining the business participation license certificate issued by the tax administration department through the above-mentioned management consensus node.
  • the business participation license certificate of the authorization object synchronized from the target chain 42e is stored at the chain entry 52a shown in FIG5.
  • the business participation license certificate of the authorization object may include the license certificate A2 of the authorization object A, the license certificate B2 of the authorization object B, ..., the license certificate N2 of the authorization object N.
  • the target business participation license certificate can be added to the second business processing request shown in FIG5 to send the second business processing request to the second consensus node (for example, the consensus node 51d shown in FIG5), so that the second consensus node can judge whether the user 53b can access the second chain network 500a through the business participation license certificate of the authorization object stored at the chain entry 52a.
  • the second consensus node finds the same business participation license certificate as the aforementioned target business participation license certificate at the chain entrance 52a, the user 53b is allowed to access the second chain network 500a. Otherwise, the second business processing request sent by the user 53b (i.e., the aforementioned second business object) can be rejected.
  • the business participation license certificate (referred to as the license certificate) here may include but is not limited to the hash value of the public key certificate configured for the user 53b (i.e., the aforementioned second business object) and the access token or identity certificate configured for the user 53b (i.e., the aforementioned second business object), etc.
  • the specific content of the license certificate configured by the management consensus node for the user 53b will not be limited here.
  • the second chain network includes multiple consensus nodes, which may specifically include consensus nodes 51a, consensus nodes 51b, consensus nodes 51c and consensus nodes 51d.
  • consensus node 51d is taken as the second consensus node
  • the second cross-chain read contract is run on the second consensus node as an example to illustrate that the second consensus node calls the second cross-chain read contract to read the core data in the business data associated with the second business from the first chain 41e corresponding to the first chain network 40a.
  • the second business here can be the above-mentioned qualification identification business.
  • the first chain 41e is jointly maintained by these consensus nodes in the first chain network 40a (for example, consensus nodes 41a, consensus nodes 41b, consensus nodes 41c and consensus nodes 41d shown in Figure 5).
  • the first consensus node will write the business data obtained by executing the first business into the target chain 41e.
  • the second consensus node for example, the consensus node 51d shown in FIG. 5
  • it can call the second cross-chain read contract to generate a cross-chain read request associated with the second business, so as to send the cross-chain read request to the first consensus node (for example, the consensus node 41d shown in FIG. 5).
  • the first consensus node (for example, consensus node 41d shown in FIG5 ) can read the business data associated with the second business (for example, qualification identification business) from the first chain 41e corresponding to the first chain network 40a according to the received cross-chain read request, and then can return the core data in the read business data to the second consensus node (for example, consensus node 51d shown in FIG5 ).
  • the second consensus node for example, consensus node 51d shown in FIG5 . It should be understood that the embodiment of the present application does not limit the amount of business data read across chains.
  • the business data associated with the second business read by the first consensus node from the first chain 41e may specifically refer to one or more electronic bills obtained after executing the electronic bill issuance business in the bill business in the first chain network.
  • the core data of the read electronic bills may be returned to the second consensus node to execute the second business requested by the user 53b in the second chain network shown in FIG5 (for example, the corporate qualifications of the billing companies requesting the issuance of these electronic bills may be identified through the core data of the electronic bills obtained in batches).
  • the second consensus node when the second consensus node reads the core data in the aforementioned business data across the chain, it can further execute the second business based on these core data, and can write the second business execution result corresponding to the second business into the second chain (such as the second chain 51e in Figure 5).
  • the specific implementation method of the second consensus node calling the second cross-chain reading contract to read the second business-related information associated with the second business from the target chain 42e can refer to the above description of the specific process of the first consensus node calling the first cross-chain reading contract to read the first business-related information associated with the first business from the target chain 42e, and will not be further elaborated here.
  • the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize that mutual collaboration can be carried out between the first chain, the target chain and the second chain to ensure that the consensus node in the first chain network (i.e., the aforementioned first consensus node) can be used to independently process some real-time business flows with a large amount of request data (i.e., the aforementioned first business).
  • the first consensus node e.g., the above-mentioned bill consensus node
  • the first chain is mainly used to store the above-mentioned first business execution results.
  • the first chain can be used to store the business data obtained by executing each first business in the real-time business flow.
  • the second consensus node e.g., the above-mentioned application consensus node
  • the second chain is mainly used to store the second business execution results.
  • the second business execution results here are determined by the second business carried out based on the core data in the business data (i.e., partially authorized and visible data in the business data) that flows across chains from the aforementioned first chain to the second chain; furthermore, it should be noted that the target consensus node here (e.g., the management consensus node in the embodiment corresponding to Figure 2 above) can be used to centrally manage the permissions of business objects in the second chain network and the first chain network. Obviously, by deploying multiple blockchains to store data separately, the complexity of data storage on each blockchain can be effectively reduced. In addition, through the mutual cooperation between multiple blockchains, the security of data stored on each chain can also be improved.
  • the target consensus node e.g., the management consensus node in the embodiment corresponding to Figure 2 above
  • FIG. 6 is a multi-blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by the second consensus node in the second chain network, for example, the second consensus node can be any consensus node in the consensus network 300a shown in FIG. 1.
  • the method can specifically include the following steps S201-S203.
  • Step S201 obtaining the second business requested by the second business object, calling the second cross-chain reading contract on the second chain based on the second business, and reading the second business association information associated with the second business from the target chain;
  • the second chain is a blockchain in the second chain network;
  • the target chain is a blockchain in the target chain network;
  • the target chain network is independent of the second chain network, and the second chain is different from the target chain;
  • Step S202 when it is determined based on the second business association information that the second business object has the second business processing authority corresponding to the second business, the second cross-chain read contract is called to generate a cross-chain read request associated with the second business, and the cross-chain read request is sent to the first consensus node in the first chain network; the cross-chain read request is used to instruct the first consensus node to read the business data associated with the second business from the first chain corresponding to the first chain network; the first chain network is independent of the second chain network and the target chain network; the business data is determined by the first consensus node based on the first business association information that the first business object has the first business When the corresponding first business processing authority is obtained, the first business processing contract on the first chain is called to determine; the first business association information is read from the target chain by the first consensus node calling the first cross-chain reading contract on the first chain based on the first business;
  • Step S203 receiving the core data in the business data returned by the first consensus node based on the cross-chain read request, executing the second business based on the core data, and writing the second business execution result corresponding to the second business into the second chain.
  • steps S201 to S203 can refer to the description of the second consensus node in the embodiment corresponding to FIG. 3 above, and will not be further described here.
  • the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize that mutual collaboration can be carried out between the three chains of the first chain, the target chain and the second chain to ensure that the consensus node in the first chain network (that is, the aforementioned first consensus node) can be used to independently process some real-time business flows with a large amount of request data (for example, the bill business flow constituted by the aforementioned bill business, the prescription business flow constituted by the aforementioned prescription business, the certificate business flow constituted by the aforementioned certificate business, etc.).
  • the first consensus node can participate in maintaining the first chain in the first chain network, and the first chain is mainly used to store the business data in the real-time business data flow obtained after executing the aforementioned first business.
  • the second consensus node can participate in maintaining the second chain in the second chain network, and the second chain is mainly used to store the second business execution result.
  • the second business execution result here is determined by the core data (i.e., core data) in the business data that flows from the aforementioned first chain across chains to the second chain; furthermore, it should be noted that the target consensus node here can be used to centrally manage the permissions of the business objects in the second chain network and the first chain network.
  • core data i.e., core data
  • target consensus node can be used to centrally manage the permissions of the business objects in the second chain network and the first chain network.
  • FIG. 7 is a multi-blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by the target consensus node in the target chain network, for example, the target consensus node can be any consensus node in the consensus network 100a shown in FIG. 1.
  • the method can specifically include the following steps S301-S304.
  • Step S301 receiving a first business authority query request sent by a first consensus node in a first chain network; the first business authority query request is determined by the first consensus node calling a first cross-chain read contract on the first chain when acquiring a first business submitted by a first business object; the first chain is a blockchain in the first chain network; the first chain network is independent of the target chain network;
  • Step S302 based on the first business query request, read the first business association information associated with the first business from the target chain corresponding to the target chain network, and return the first business association information to the first consensus node, so that when the first consensus node determines that the first business object has the first business processing authority corresponding to the first business based on the first business association information, it calls the first business processing contract on the first chain to execute the first business and obtains the first business execution result for writing into the first chain; the first business execution result includes the business data indicated by the first business;
  • Step S303 receiving a second business authority query request sent by a second consensus node in the second chain network;
  • the second business authority query request is determined by the second consensus node calling a second cross-chain read contract on the second chain corresponding to the second chain network when acquiring the second business submitted by the second business object;
  • the second chain network is independent of the first chain network and the target chain network;
  • Step S304 based on the second business query request, read the second business association information associated with the second business from the target chain, and return the second business association information to the second consensus node, so that when the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business association information, it calls the second cross-chain read contract to generate a cross-chain read request associated with the second business to be sent to the first consensus node; the cross-chain read request is used to instruct the first consensus node to read business data from the first chain.
  • steps S301 to S304 can refer to the description of the target consensus node in the embodiment corresponding to FIG. 3 above, and will not be further described here.
  • the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize that the three chains of the first chain, the target chain and the second chain can collaborate with each other to ensure that the consensus node in the first chain network (i.e., the aforementioned first consensus node) can be used to independently process some real-time business flows with a large amount of request data (i.e., The aforementioned first business).
  • the first consensus node can participate in maintaining the first chain in the first chain network, and the first chain is mainly used to store the business data obtained after real-time processing of the first business flow.
  • the second consensus node can participate in maintaining the second chain in the second chain network, and the second chain is mainly used to store the second business execution result.
  • the second business execution result is determined by the second business carried out based on the core data in the business data that flows from the aforementioned first chain across chains to the second chain; furthermore, it should be noted that the target consensus node here can be used to centrally manage the permissions of the business objects in the second chain network and the first chain network.
  • the method can be jointly executed by the first consensus node in the above-mentioned first chain network, the second consensus node in the second chain network, and the target consensus node in the target chain network.
  • the first consensus node here can be any consensus node in the consensus network 200a shown in Figure 1 above
  • the second consensus node can be any consensus node in the consensus network 300a shown in Figure 1 above
  • the target consensus node can be any consensus node in the consensus network 100a shown in Figure 1 above.
  • the first chain network here is independent of the target chain network and independent of the second chain network; at this time, the method can specifically include the following steps S401-S410.
  • Step S401 the first consensus node is used to obtain the first business requested by the first business object, call the first cross-chain reading contract on the first chain based on the first business, and generate a first business permission query request;
  • Step S402 the first consensus node sends a first business authority query request to the target consensus node;
  • Step S403 when the target consensus node obtains the first business authority query request sent by the first consensus node, it is used to read the first business association information associated with the first business from the target chain corresponding to the target chain network, and return the first business association information to the first consensus node;
  • Step S404 when the first consensus node determines that the first business object has the first business processing authority corresponding to the first business based on the first business association information, it calls the first business processing contract on the first chain to execute the first business, obtains the first business execution result associated with the first business, and writes the first business execution result into the first chain;
  • the first service execution result includes service data indicated by the first service.
  • Step S405 the target consensus node receives a second business authority query request sent by the second consensus node in the second chain network;
  • the second business authority query request is determined by the second consensus node calling the second cross-chain read contract on the second chain corresponding to the second chain network when obtaining the second business submitted by the second business object;
  • the second chain network is independent of the first chain network and the target chain network;
  • Step S406 the target consensus node reads the second business association information associated with the second business from the target chain based on the second business query request, and returns the second business association information to the second consensus node;
  • Step S407 When the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business association information, the second consensus node calls the second cross-chain read contract to generate a cross-chain read request associated with the second business for sending to the first consensus node;
  • the cross-chain read request is used to instruct the first consensus node to read business data from the first chain.
  • Step S408 the second consensus node sends the cross-chain read request to the first consensus node
  • the cross-chain read request involved in step S408 is generated by calling the second cross-chain read contract when the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business association information; the second business association information is read from the target chain by the second consensus node calling the second cross-chain read contract based on the second business.
  • Step S409 When the first consensus node obtains the cross-chain read request sent by the second consensus node, it reads the business data from the first chain based on the second business carried in the cross-chain read request, and returns the core data in the business data to the second consensus node;
  • Step S410 After executing the second business based on the core data, the second consensus node writes the second business execution result corresponding to the second business into the second chain.
  • the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize that the three chains of the first chain, the target chain and the second chain can collaborate with each other to ensure that the consensus node in the first chain network (i.e., the aforementioned first consensus node) can be used to independently process some real-time business flows with a large amount of request data (i.e., the aforementioned first business).
  • the first consensus node can participate in maintaining the first chain in the first chain network, and the first chain is mainly used to store the business data obtained after executing the aforementioned real-time business flow.
  • the second consensus node can participate in maintaining the second chain in the second chain network, and the second chain is mainly used to store the second business execution result.
  • the second business execution result here is based on the core data in the business data that flows from the first chain across the chain to the second chain.
  • the second business is determined; furthermore, it should be noted that the target consensus node here can be used to centrally manage the permissions of the business objects in the access second chain network and the first chain network.
  • Figure 9 is a structural diagram of a multi-blockchain data processing device provided by the present application.
  • the multi-blockchain data processing device 1 can be applied to the first consensus node, and the first consensus node can be any blockchain node in the first chain network (for example, the above-mentioned consensus network 200a).
  • the first consensus node can be the consensus node 11c in the embodiment corresponding to Figure 1 above.
  • the multi-blockchain data processing device 1 can be a computer program (including program code) running in a blockchain node (for example, the aforementioned consensus node 10c).
  • the multi-blockchain data processing device 1 can be an application software; it can be understood that the multi-blockchain data processing device 1 can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the multi-blockchain data processing device 1 may include: a first business acquisition module 11, a first business execution module 12 and a business data reading module 13;
  • the first business acquisition module 11 is used to acquire the first business requested by the first business object, call the first cross-chain reading contract on the first chain based on the first business, and read the first business association information associated with the first business from the target chain;
  • the first chain is the blockchain in the first chain network;
  • the target chain is the blockchain in the target chain network;
  • the target chain network is independent of the first chain network, and the first chain is different from the target chain;
  • the first business execution module 12 is used to call the first business processing contract on the first chain to execute the first business when it is determined based on the first business association information that the first business object has the first business processing authority corresponding to the first business, obtain the first business execution result associated with the first business, and write the first business execution result into the first chain; the first business execution result includes the business data indicated by the first business;
  • the business data reading module 13 is used to read business data from the first chain based on the second business carried in the cross-chain read request when the cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain is obtained, and return the core data in the business data to the second consensus node;
  • the second consensus node is used to write the second business execution result corresponding to the second business into the second chain after executing the second business based on the core data;
  • the second chain is the blockchain in the second chain network where the second consensus node is located, and the second chain network is independent of the first chain network and the target chain network.
  • the chain entry corresponding to the first chain network is the first chain entry;
  • the first chain entry stores the registration data information of the authorized object synchronized from the target chain by the first consensus node through the first cross-chain reading contract at the first cross-chain reading timestamp;
  • the first service acquisition module 11 includes: a first service request unit 111, a signature verification unit 112, a first service determination unit 113 and a cross-chain reading unit 114;
  • the first business request form 111 is used to obtain, through the first chain entry of the first chain network, a first business processing request sent by the first business node corresponding to the first business object based on the first business;
  • the first business processing request carries the transaction business data submitted by the first business object for the first business, and the first signature information of the first business object;
  • the first signature information is obtained by the first business node associated with the first business object signing the transaction business data through the first private key information of the first business object;
  • the first private key information of the first business object is obtained after the first business object registers its identity through the object identity management contract in the target chain;
  • the signature verification unit 112 is used to obtain the first signature information from the first business processing request, perform signature verification on the first signature information based on the registration data information of the authorization object stored in the first chain entry, and obtain a signature verification result of the first business object;
  • a first business determination unit 113 configured to determine that the first business object is an authorized object when the signature verification result of the first business object indicates that the signature verification is successful, and determine a first business associated with the first business object based on the transaction business data;
  • the cross-chain reading unit 114 is used to call the first cross-chain reading contract based on the first business, and read the first business association information associated with the first business from the target chain.
  • the registration data information of the authorized object includes the public key certificate of the authorized object;
  • the public key certificate of the authorized object is obtained by the target consensus node in the target chain network calling the object identity management contract in the target chain to register the object data information submitted by the authorized object;
  • the specific implementation methods of the first business request unit 111, the signature verification unit 112, the first business determination unit 113 and the cross-chain reading unit 114 can refer to the description of step S101 in the embodiment corresponding to Figure 3 above, and will not be further described here.
  • the signature verification unit 112 includes: a certificate acquisition subunit 1121, a certificate search subunit 1122 and a signature verification subunit 1123;
  • the certificate acquisition subunit 1121 is used to obtain the first signature information from the first service processing request, and obtain the public key certificate of the authorization object from the registration data information of the authorization object stored in the first chain entry; the public key certificate of an authorization object contains the public key information of an authorization object;
  • the certificate search subunit 1122 is used to search for the public key certificate of the first business object in the public key certificate of the authorization object, and when the public key certificate of the first business object is found, use the found public key certificate of the first business object as the first public key certificate, and use the public key information in the first public key certificate as the first public key information of the first business object;
  • the signature verification subunit 1123 is used to perform signature verification on the first signature information based on the first public key certificate and the first public key information to obtain a signature verification result of the first business object.
  • the signature verification subunit 1123 is specifically used to use the certificate data information of the first public key certificate as the certificate information to be processed, and call the certificate data reading method in the first cross-chain reading contract at the second cross-chain reading timestamp to read the public key certificate of the first business object from the target chain; the second cross-chain reading timestamp is the next cross-chain reading timestamp of the first cross-chain reading timestamp;
  • the signature verification subunit 1123 is further specifically configured to use the certificate data information in the read public key certificate of the first business object as the target certificate information;
  • the signature verification subunit 1123 is further specifically used to perform signature verification on the first signature information based on the first public key information when the certificate information to be processed is consistent with the target certificate information, and use the verification result when the signature verification is successful as the signature verification result of the first business object.
  • the specific implementation methods of the certificate acquisition subunit 1121, the certificate search subunit 1122 and the signature verification subunit 1123 can refer to the description of the specific process of signature verification in the embodiment corresponding to Figure 3 above, and will not be further described here.
  • the signature verification unit 112 further includes: a request rejection subunit 1124;
  • the request rejection subunit 1124 is used to determine the first business object as an illegal business object and reject the first business processing request sent by the illegal business object when the public key certificate of the first business object is not found in the public key certificate of the authorization object.
  • the specific implementation method of the request rejection sub-unit 1124 can refer to the description of the specific process of signature verification in the embodiment corresponding to Figure 3 above, and will not be further described here.
  • the cross-chain reading unit 114 includes: an access request generating subunit 1141 and an associated information returning subunit 1142;
  • the access request generation subunit 1141 is used to call the permission contract reading method in the first cross-chain reading contract based on the first business, and generate a permission contract access request for sending to the target consensus node in the target chain network; the permission contract access request is used to instruct the target consensus node to call the object permission management contract on the target chain to obtain the first business association information associated with the first business;
  • the associated information returning subunit 1142 is used to receive the first business associated information returned by the target consensus node based on the permission contract access request.
  • the specific implementation method of the access request generation subunit 1141 and the associated information return subunit 1142 can refer to the description of the specific process of cross-chain reading of the first business associated information through the first cross-chain reading contract in the embodiment corresponding to Figure 3 above, and will not be further described here.
  • the first business association information includes the business authority type configured for the first business object, the business accumulation amount of the first business object with the business authority type within the business duration, and the business accumulation threshold;
  • the first business execution module 12 includes: a processing authority determination unit 121, a bill contract calling unit 122, a block verification unit 123 and a verification result receiving unit 124;
  • the processing authority determination unit 121 is used to determine that the business authority type of the first business object is an invoicing authority type based on the first business association information, and when the business accumulation amount of the first business object with the invoicing authority type within the business duration does not reach the business accumulation threshold, determine that the first business object has the first business processing authority corresponding to the first business;
  • the bill contract calling unit 122 is used to obtain a contract calling address and a contract calling name associated with the billing authority type based on the first business processing authority, call the electronic bill issuing contract on the first chain through the contract calling address and the contract calling name, integrate the transaction business data corresponding to the first business and the bill key information associated with the electronic bill issuing business in the first business, issue an electronic bill for the first business object based on the integrated bill key information, and use the issued electronic bill as the business data indicated by the first business;
  • the block verification unit 123 is used to use the bill key information, business data and the electronic bill issuance contract as the first business execution result of the electronic bill issuance business in the first business, and send the first block containing the first business execution result to the verification consensus node on the first chain, so that the verification consensus node performs block verification on the first block to obtain a block verification result;
  • the verification consensus node is the remaining consensus node in the first chain network except the first consensus node;
  • the verification result receiving unit 124 is used to receive the block verification result returned by the verification consensus node. If the block verification result indicates that the block verification is successful, the first block is written into the first chain.
  • the specific implementation methods of the processing authority determination unit 121, the bill contract calling unit 122, the block verification unit 123 and the verification result receiving unit 124 can refer to the description of step S102 in the embodiment corresponding to Figure 3 above, and will not be further described here.
  • the key information of the bill includes the auxiliary metadata information read from the target chain, and the auxiliary metadata information includes the first electronic bill template and the target tax calculation rule associated with the first electronic bill template;
  • the first electronic bill template is the electronic bill template after the target consensus node on the target chain calls the metadata management contract on the target chain to change the second electronic bill template on the chain;
  • the second electronic bill template is the previous electronic bill template of the first electronic bill template;
  • the metadata change information is submitted by the business management object associated with the target consensus node.
  • the first business includes at least one of the following transaction businesses: electronic bill issuance business, electronic bill circulation business, electronic bill red-offsetting business, and electronic bill archiving business;
  • the first business processing contract includes at least: an electronic bill issuance contract for executing the electronic bill issuance business, an electronic bill circulation contract for executing the electronic bill circulation business, an electronic bill red-offsetting contract for executing the electronic bill red-offsetting business, and an electronic bill archiving contract for executing the electronic bill archiving business;
  • the electronic invoice issuance business is used to instruct the first consensus node to call the electronic invoice issuance contract on the first chain to issue an electronic invoice for the first business object
  • the electronic invoice circulation business is used to instruct the first consensus node to call the electronic invoice circulation contract on the first chain to transfer the electronic invoice from the first business object to the second business object
  • the electronic invoice red-offset business is used to instruct the first consensus node to call the electronic invoice red-offset contract on the first chain to issue a red-letter invoice corresponding to the electronic invoice, and the red-letter invoice is used to correct the relevant invoice information in the electronic invoice
  • the electronic invoice archiving business is used to instruct the first consensus node to call the electronic invoice archiving contract on the first chain to perform cold storage processing on the first chain for electronic invoices that meet the invoice archiving conditions.
  • the business data reading module 13 includes: a bill reading request sending unit 131 and a bill reading response unit 132;
  • the ticket reading request sending unit 131 is used to obtain the cross-chain reading request sent by the second consensus node based on the second cross-chain reading contract on the second chain, and obtain the second business object from the cross-chain reading request through the first cross-chain reading contract associated with the second chain.
  • the second business submitted by the second business entry; the second business entry is used to allow the second business object to call the second cross-chain reading contract through the second consensus node when it is determined that the second business object has the authority to process the second business on the second chain;
  • the ticket reading response unit 132 is used to read business data from the first chain based on the cross-chain request data information indicated by the second business, use the core data in the read business data as the cross-chain request response information corresponding to the cross-chain read request, and return the cross-chain request response information to the second consensus node, so that the second consensus node calls the second business contract on the second chain to execute the second business based on the cross-chain request response information.
  • the specific implementation of the bill reading request sending unit 131 and the bill reading response unit 132 can refer to the description of step S103 in the corresponding time of FIG. 3 above, and will not be further described here.
  • the first business execution module 12 is further used to specify the processing terminal identifier of the business data processing terminal associated with the business data in the target transaction corresponding to the first business execution result when writing the first business execution result into the first chain; the processing terminal identifier is used to indicate that the business data processing terminal has the function of clearing the business data from the first chain;
  • the first business execution module 12 is further used to obtain the target transaction from the first chain based on the processing terminal identifier carried in the transaction clearing request when the transaction clearing request sent by the business data processing terminal is obtained, and clear the business data from the first business execution result included in the target transaction, and return the business data to the business data processing terminal, so that the business data processing terminal performs data analysis on the business data.
  • the specific implementation of the first service acquisition module 11, the first service execution module 12 and the service data reading module 13 can refer to the description of step S101 to step S103 in the embodiment corresponding to FIG3 above, and will not be further described here. It should be understood that the description of the beneficial effects obtained by adopting the same method will not be repeated.
  • Figure 10 is a structural diagram of a multi-blockchain data processing device provided by the present application.
  • the multi-blockchain data processing device 2 can be applied to the second consensus node, and the second consensus node can be any blockchain node in the second chain network (for example, the above-mentioned consensus network 300a).
  • the second consensus node can be the consensus node 12c in the embodiment corresponding to Figure 1 above.
  • the multi-blockchain data processing device 2 can be a computer program (including program code) running in a blockchain node (for example, the aforementioned consensus node 12c).
  • the multi-blockchain data processing device 2 can be an application software; it can be understood that the multi-blockchain data processing device 2 can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the multi-blockchain data processing device 2 may include: a second business acquisition module 21, a cross-chain read request sending module 22 and a second business execution module 23;
  • the second business acquisition module 21 is used to acquire the second business requested by the second business object, call the second cross-chain reading contract on the second chain based on the second business, and read the second business association information associated with the second business from the target chain;
  • the second chain is a blockchain in the second chain network;
  • the target chain is a blockchain in the target chain network;
  • the target chain network is independent of the second chain network, and the second chain is different from the target chain;
  • the cross-chain read request sending module 22 is used to call the second cross-chain read contract to generate a cross-chain read request associated with the second business when it is determined based on the second business association information that the second business object has the second business processing authority corresponding to the second business, and send the cross-chain read request to the first consensus node in the first chain network;
  • the cross-chain read request is used to instruct the first consensus node to read the business data associated with the second business from the first chain corresponding to the first chain network;
  • the first chain network is independent of the second chain network and the target chain network;
  • the business data is determined by the first consensus node calling the first business processing contract on the first chain when it is determined based on the first business association information that the first business object has the first business processing authority corresponding to the first business;
  • the first business association information is read from the target chain by the first consensus node calling the first cross-chain read contract on the first chain based on the first business;
  • the second business execution module 23 is used to receive the core data in the business data returned by the first consensus node based on the cross-chain read request, execute the second business based on the core data, and write the second business execution result corresponding to the second business into the second chain.
  • the specific implementation of the second service acquisition module 21, the cross-chain read request sending module 22 and the second service execution module 23 can refer to the description of steps S201 to S203 in the embodiment of FIG. 4 above, which will not be described in detail here.
  • the description of the beneficial effects obtained by using the same method will not be described in detail.
  • Figure 11 is a schematic diagram of the structure of a multi-blockchain data processing device provided by the present application.
  • the multi-blockchain data processing device 3 can be applied to the target consensus node, and the target consensus node can be any blockchain node in the target chain network (for example, the above-mentioned consensus network 100a).
  • the target consensus node can be the consensus node 10c in the embodiment corresponding to Figure 1 above.
  • the multi-blockchain data processing device 3 can be a computer program (including program code) running in a blockchain node (for example, the aforementioned consensus node 10c).
  • the multi-blockchain data processing device 3 can be an application software; it can be understood that the multi-blockchain data processing device 3 can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the multi-blockchain data processing device 3 may include: a first query request receiving module 31, a first associated information returning module 32, a second query request receiving module 33 and a second associated information returning module 34;
  • the first query request receiving module 31 is used to receive a first business authority query request sent by a first consensus node in the first chain network; the first business authority query request is determined by the first consensus node calling the first cross-chain read contract on the first chain when obtaining the first business submitted by the first business object; the first chain is a blockchain in the first chain network; the first chain network is independent of the target chain network;
  • the first associated information returning module 32 is used to read the first business associated information associated with the first business from the target chain corresponding to the target chain network based on the first business query request, and return the first business associated information to the first consensus node, so that when the first consensus node determines that the first business object has the first business processing authority corresponding to the first business based on the first business associated information, it calls the first business processing contract on the first chain to execute the first business and obtains the first business execution result for writing into the first chain; the first business execution result includes the business data indicated by the first business;
  • the second query request receiving module 33 is used to receive a second business authority query request sent by a second consensus node in the second chain network; the second business authority query request is determined by the second consensus node calling the second cross-chain read contract on the second chain corresponding to the second chain network when obtaining the second business submitted by the second business object; the second chain network is independent of the first chain network and the target chain network;
  • the second associated information returning module 34 is used to read the second business associated information associated with the second business from the target chain based on the second business query request, and return the second business associated information to the second consensus node, so that when the second consensus node determines that the second business object has the second business processing authority corresponding to the second business based on the second business associated information, it calls the second cross-chain read contract to generate a cross-chain read request associated with the second business for sending to the first consensus node; the cross-chain read request is used to instruct the first consensus node to read business data from the first chain.
  • first query request receiving module 31, the first associated information returning module 32, the second query request receiving module 33 and the second associated information returning module 34 can refer to the description of steps S301 to S304 in the embodiment corresponding to FIG5 above, which will not be described in detail here.
  • the description of the same beneficial effects obtained by using the same method will not be described in detail.
  • Figure 12 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. As shown in FIG. 12 , 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;
  • the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the description of the multi-blockchain data method in the embodiment corresponding to FIG3, FIG6, FIG7 or FIG8 above, and can also execute The description of the multi-blockchain data processing device (i.e., the multi-blockchain data processing device 1, the multi-blockchain data processing device 2, or the multi-blockchain data processing device 3) in the embodiments corresponding to FIG. 9, FIG. 10, or FIG. 11 above will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the multi-blockchain data processing device 1, multi-blockchain data processing device 2 or multi-blockchain data processing device 3 mentioned above, and the computer program includes computer instructions.
  • the processor executes the computer instructions, it can execute the description of the multi-blockchain data processing method in the embodiment corresponding to Figure 3, Figure 6, Figure 7 or Figure 8 above, so it will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • the computer instructions can be deployed on a computing device for execution, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network.
  • Multiple computing devices distributed at multiple locations and interconnected by a communication network can constitute a blockchain system.
  • the embodiment of the present application also provides a computer program product or a computer program, which may include computer instructions, which may be stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor may execute the computer instruction so that the computer device executes the description of the multi-blockchain data processing method in the embodiment corresponding to Figures 3, 6, 7 or 8 above, so it will not be repeated here.
  • the description of the beneficial effects of the same method will not be repeated.
  • the multi-blockchain data processing system 4 may include a consensus node 4a, a consensus node 4b and a consensus node 4c; wherein, the consensus node 4a may be the target consensus node in the target chain network described in the embodiment corresponding to Figure 7 above, and the target consensus node may be any blockchain node in the consensus network 100a shown in Figure 1 above, and will not be further described here.
  • the consensus node 4b may be the first consensus node in the first chain network described in the embodiment corresponding to Figure 3 above, and the first consensus node may be any blockchain node in the consensus network 200a shown in Figure 1 above, and will not be further described here.
  • the consensus node 4c may be the second consensus node in the second chain network described in the embodiment corresponding to Figure 6 above, and the second consensus node may be any blockchain node in the consensus network 300a shown in Figure 1 above, and will not be further described here. in addition, the description of the beneficial effects of using the same method will not be repeated.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Tourism & Hospitality (AREA)
  • General Engineering & Computer Science (AREA)
  • Technology Law (AREA)
  • Educational Administration (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种多区块链数据处理方法、装置、设备、系统以及介质，该方法包括：在第一共识节点获取到第一业务时，调用第一链上的第一跨链读取合约，从管理链上读取与第一业务相关联的第一业务关联信息（S101）；在第一共识节点基于第一业务关联信息确定第一业务对象具备第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到第一业务执行结果，且将第一业务执行结果写入第一链（S102）；在第一共识节点获取到第二共识节点发送的跨链读取请求时，从第一链上读取第一业务执行结果中的业务数据，且将业务数据中的核心数据返回给第二共识节点（S103）。

Description

多区块链数据处理方法、装置、设备、系统以及介质
本申请要求于2022年10月14日提交的、申请号为202211260878.X、发明名称为“多区块链数据处理方法、装置、设备、系统以及介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链技术领域，尤其涉及一种多区块链数据处理方法、装置、设备、系统以及介质。
背景技术
现有的区块链数据处理系统在处理相关业务(例如，业务A和该业务A的扩展业务B)时，依赖于架设在单链结构上的区块链网络。这样，对于通过终端或者服务器的形式接入该区块链网络中的各个业务处理方而言，均需要在该区块链网络对应的同一区块链上处理相关业务(例如，业务A和扩展业务B)。
发明内容
本申请实施例提供一种多区块链数据处理方法、装置、设备、系统以及介质。
本申请实施例一方面提供了一种多区块链数据处理方法，方法由第一链网络中的第一共识节点执行，方法包括：
获取第一业务对象请求的第一业务，基于第一业务调用第一链上的第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息；第一链为第一链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第一链网络，第一链不同于目标链；
在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；第一业务执行结果中包含第一业务所指示的业务数据；
在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；第二共识节点用于在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链；第二链为第二共识节点所在的第二链网络中的区块链，第二链网络独立于第一链网络和目标链网络。
本申请实施例一方面提供了一种多区块链数据处理方法，方法由第二链网络中的第二共识节点执行，方法包括：
获取第二业务对象请求的第二业务，基于第二业务调用第二链上的第二跨链读取合约，从目标链上读取与第二业务相关联的第二业务关联信息；第二链为第二链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第二链网络，第二链不同于目标链；
在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成与第二业务相关联的跨链读取请求，将跨链读取请求发送给第一链网络中的第一共识节点；跨链读取请求用于指示第一共识节点从第一链网络对应的第一链上读取与第二业务相关联的业务数据；第一链网络独立于第二链网络和目标链网络；业务数据是由第一共识节点在基于第一业务关联信息确定出第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约所确定的；第一业务关联信息是由第一共识节点基于第一业务调用第一链上的第一跨链读取合约从目标链上读取到的；
接收第一共识节点基于跨链读取请求返回的业务数据中的核心数据，基于核心数据执行第二业务，并将第二业务对应的第二业务执行结果写入第二链。
本申请实施例一方面提供了一种多区块链数据处理方法，方法由目标链网络中的目标共识节点执行，方法包括：
接收第一链网络中的第一共识节点发送的第一业务权限查询请求；第一业务权限查询请求是第一共识节点在获取到第一业务对象提交的第一业务时，调用第一链上的第一跨链读取合约所确定的；第一链为第一链网络中的区块链；第一链网络独立于目标链网络；
基于第一业务查询请求从目标链网络对应的目标链上，读取与第一业务相关联的第一业务关联信息，将第一业务关联信息返回给第一共识节点，以使第一共识节点在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到用于写入第一链的第一业务执行结果；第一业务执行结果中包含第一业务所指示的业务数据；
接收第二链网络中的第二共识节点发送的第二业务权限查询请求；第二业务权限查询请求是第二共识节点在获取到第二业务对象提交的第二业务时，调用第二链网络对应的第二链上的第二跨链读取合约所确定的；第二链网络独立于第一链网络和目标链网络；
基于第二业务查询请求从目标链上，读取与第二业务相关联的第二业务关联信息，将第二业务关联信息返回给第二共识节点，以使第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成用于发送给第一共识节点的与第二业务相关联的跨链读取请求；跨链读取请求用于指示第一共识节点从第一链上读取业务数据。
本申请实施例一方面提供了一种多区块链数据处理装置，装置运行在第一链网络中的第一共识节点上，装置包括：
第一业务获取模块，用于获取第一业务对象请求的第一业务，基于第一业务调用第一链上的第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息；第一链为第一链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第一链网络，第一链不同于目标链；
第一业务执行模块，用于在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；第一业务执行结果中包含第一业务所指示的业务数据；
业务数据读取模块，用于在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；第二共识节点用于在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链；第二链为第二共识节点所在的第二链网络中的区块链，第二链网络独立于第一链网络和目标链网络。
其中，与第一链网络对应的链入口为第一链入口；第一链入口存储有第一共识节点在第一跨链读取时间戳时通过第一跨链读取合约从目标链上所同步来的授权对象的注册数据信息；
本申请实施例一方面提供了一种多区块链数据处理装置，装置运行在第二链网络中的第二共识节点上，装置包括：
第二业务获取模块，用于获取第二业务对象请求的第二业务，基于第二业务调用第二链上的第二跨链读取合约，从目标链上读取与第二业务相关联的第二业务关联信息；第二链为第二链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第二链网络，第二链不同于目标链；
跨链读取请求发送模块，用于在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成与第二业务相关联的跨链读取请求， 将跨链读取请求发送给第一链网络中的第一共识节点；跨链读取请求用于指示第一共识节点从第一链网络对应的第一链上读取与第二业务相关联的业务数据；第一链网络独立于第二链网络和目标链网络；业务数据是由第一共识节点在基于第一业务关联信息确定出第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约所确定的；第一业务关联信息是由第一共识节点基于第一业务调用第一链上的第一跨链读取合约从目标链上读取到的；
第二业务执行模块，用于接收第一共识节点基于跨链读取请求返回的业务数据中的核心数据，基于核心数据执行第二业务，并将第二业务对应的第二业务执行结果写入第二链。
本申请实施例一方面提供了一种多区块链数据处理装置，装置运行在目标链网络中的目标共识节点上，装置包括：
第一查询请求接收模块，用于接收第一链网络中的第一共识节点发送的第一业务权限查询请求；第一业务权限查询请求是第一共识节点在获取到第一业务对象提交的第一业务时，调用第一链上的第一跨链读取合约所确定的；第一链为第一链网络中的区块链；第一链网络独立于目标链网络；
第一关联信息返回模块，用于基于第一业务查询请求从目标链网络对应的目标链上，读取与第一业务相关联的第一业务关联信息，将第一业务关联信息返回给第一共识节点，以使第一共识节点在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到用于写入第一链的第一业务执行结果；第一业务执行结果中包含第一业务所指示的业务数据；
第二查询请求接收模块，用于接收第二链网络中的第二共识节点发送的第二业务权限查询请求；第二业务权限查询请求是第二共识节点在获取到第二业务对象提交的第二业务时，调用第二链网络对应的第二链上的第二跨链读取合约所确定的；第二链网络独立于第一链网络和目标链网络；
第二关联信息返回模块，用于基于第二业务查询请求从目标链上，读取与第二业务相关联的第二业务关联信息，将第二业务关联信息返回给第二共识节点，以使第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成用于发送给第一共识节点的与第二业务相关联的跨链读取请求；跨链读取请求用于指示第一共识节点从第一链上读取业务数据。
本申请实施例一方面提供了一种多区块链数据处理系统，系统包括：第一链网络中的第一共识节点、目标链网络中的目标共识节点和第二链网络中的第二共识节点；第一链网络独立于目标链网络，且独立于第二链网络；
第一共识节点用于获取第一业务对象请求的第一业务，基于第一业务调用第一链上的第一跨链读取合约，生成第一业务权限查询请求；
目标共识节点用于在获取到第一共识节点发送的第一业务权限查询请求时，从目标链网络对应的目标链上读取与第一业务相关联的第一业务关联信息，将第一业务关联信息返回给第一共识节点；
第一共识节点还用于在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；第一业务执行结果中包含第一业务所指示的业务数据；
第一共识节点还用于在获取到第二共识节点发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；跨链读取请求是第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约所生成的；第二业务关联信息时第二共识节点基于第二业务调用第二跨链读取合约从目标链上读取到的；
第二共识节点用于在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链。
本申请实施例一方面提供了一种计算机设备，包括存储器和处理器，存储器与处理器相连，存储器用于存储计算机程序，处理器用于调用计算机程序，以使得该计算机设备执行本申请实施例中上述一方面提供的方法。
本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序适于由处理器加载并执行，以使得具有处理器的计算机设备执行本申请实施例中上述一方面提供的方法。
根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述一方面提供的方法。
在本申请实施例中，第一链网络中的第一共识节点可以在获取到第一业务对象请求的第一业务时，基于第一业务调用第一链上的第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息；第一链为第一链网络中的区块链；目标链是独立于第一链网络的目标链网络中的区块链；第一链不同于目标链；进一步的，该第一链网络中的第一共识节点可以在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；第一业务执行结果中包含第一业务所指示的业务数据；进一步的，该第一链网络中的第一共识节点还可以在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；应当理解，这里的第二共识节点用于在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链；第二链为第二共识节点所在的第二链网络中的区块链，第二链网络独立于第一链网络和目标链网络。由此可见，本申请实施例提供了一种全新的多区块链协作机制，该多区块链协作机制旨在强调可以在第一链、目标链和第二链这三链之间进行互相协作，以确保第一链网络中的共识节点(即前述第一共识节点)可以用于独立处理一些具有较大请求数据量的第一业务所构成的实时业务流。这样，在区块链的核心数据流转的业务场景下，第一共识节点可以参与维护该第一链网络中的第一链，且该第一链主要用于存储执行实时业务流中的各第一业务所得到的业务数据。此外，第二共识节点可以参与维护该第二链网络中的第二链，且该第二链主要用于存储第二业务执行结果，需要注意的是，这里的第二业务执行结果是基于从前述第一链上跨链流转至该第二链的业务数据中的核心数据(即业务数据中部分授权可见的数据)而开展的第二业务所确定的；此外，需要注意的是，这里的目标共识节点可以用于对接入第二链网络和第一链网络中的业务对象的权限(比如，身份权限和业务权限)进行集中管理。显然，通过部署的多区块链来分别进行数据存储，可以有效地降低各区块链上数据存储的混杂度，另外，通过多区块链之间的相互协作，还可以提升各链上所存储数据的安全性。
附图说明
图1是本申请实施例提供的一种区块链网络的分层结构示意图；
图2是本申请实施例提供的一种基于多区块链的区块链电子票据平台的场景示意图；
图3是本申请实施例提供的一种多区块链数据处理方法；
图4是本申请实施例提供的一种通过链入口进行身份鉴权的场景示意图；
图5是本申请实施例通过的一种在三链之间进行跨链交互的场景示意图；
图6是本申请实施例提供的一种多区块链数据处理方法；
图7是本申请实施例提供的一种多区块链数据处理方法；
图8是本申请实施例提供的一种多区块链数据处理方法；
图9是本申请提供的一种多区块链数据处理装置的结构示意图；
图10是本申请提供的一种多区块链数据处理装置的结构示意图；
图11是本申请提供的一种多区块链数据处理装置的结构示意图；
图12是本申请实施例提供的一种计算机设备的结构示意图；
图13是本申请实施例提供的一种多区块链数据处理系统的示意图。
具体实施方式
请参见图1，图1是本申请实施例提供的一种区块链网络的分层结构示意图。如图1所示的分层结构应用于多业务协作处理平台所对应的区块链系统，在该区块链系统所对应的区块链网络中，包含部署在公网中的业务网络、和部署在私有云中的多个共识网络。如图1所示，这里的业务网络可以为图1所示的业务网络400a，且这里的多个共识网络具体可以包含图1所示的共识网络100a、共识网络200a和共识网络300a。
在如图1所示的业务网络400a中，部署有多个业务节点，这里的多个业务节点具体可以包含图1所示的业务节点110a、业务节点110b、业务节点110c、业务节点110d、业务节点110e、业务节点110f、业务节点110g、…、业务节点110n。如图1所示，对于运行在该业务网络400a中的各个业务节点而言，均可以通过网络通信的形式访问上述多个共识网络中的一个或者多个，各个共识网络之间也可以通过网络通信的形式进行数据交互。
应当理解，在如图1所示的共识网络100a中，部署有多个共识节点，这里的多个共识节点具体可以包含图1所示的共识节点10a、共识节点10b、共识节点10c和共识节点10d。如图1所示，对于运行在该共识网络100a中的多个共识节点而言，共同维护的区块链具体为图1所示的区块链10e。
同理，在如图1所示的共识网络200a中，部署有多个共识节点，对于运行在该共识网络200a中的多个共识节点而言，共同维护的区块链具体为图1所示的区块链11e。
以此类推，在如图1所示的共识网络300a中，部署有多个共识节点，对于运行在该共识网络300a中的多个共识节点而言，共同维护的区块链具体为图1所示的区块链12e。
为便于理解，本申请实施例可以将位于上述区块链系统中的业务节点和共识节点统称为区块链节点(简称为节点)，并可以将参与构成上述区块链系统的共识网络100a、共识网络200b和共识网络300c统称为核心共识网络，并可以将上述核心共识网络中的各个节点统称为核心节点。
为便于对上述多业务协作处理平台所对应区块链系统中的各个核心共识网络进行区分，本申请实施例可以结合该多业务协作处理平台的具体应用场景(例如，区块链电子票据平台下的电子票据核心数据流转场景)，将上述共识网络100a统称为目标链网络，并将在该目标链网络中由各个共识节点所共同维护的区块链10e统称为目标链，还可以将在该目标链网络中所选取的用于执行管理业务(例如，注册业务和授权业务等)的共识节点作为该目标链网络中的目标共识节点。同理，可以理解的是，本申请实施例可以将上述共识网络200a统称为第一链网络，并将在该第一链网络中由各个共识节点所共同维护的区块链11e统称为第一链，还可以将在该第一链网络中所选取的用于执行第一业务(该第一业务具体可以为与电子票据相关联的票据业务，例如，电子票据开具业务等)的共识节点作为该目标链网络中的第一共识节点。以此类推，本申请实施例可以将上述共识网络300a统称为第二链网络，并将在该第二链网络中由各个共识节点所共同维护的区块链12e统称为第二链，还可以将在该第二链网络中所选取的用于执行第二业务(该第二业务具体可以为与电子票据相关联的衍生业务，例如，企业资质识别业务等)的共识节点作为该目标链网络中的第一共识节点。应当理解，对于各核心共识网络而言，这里的管理业务、票据业务以及衍生业务均可以视为由相应业务对 象所发起的交易的交易业务。
比如，在上述区块链系统应用于区块链电子票据平台中时，可以基于上述目标链、第一链和第二链构建得到一个安全可靠的区块链电子票据三链网络，在该区块链电子票据三链网络中，当在上述三个共识网络中独立执行上述业务的情况，可以将独立执行上述业务所得到的业务执行结果分别存入对应的区块链的区块链账本，进而可以从根源上避免各链上数据存储的混杂度。
具体的，比如，在共识网络100a被用作目标链网络，且该目标链网络为前述区块链电子票据三链网络中的目标链网络时，该共识网络100a中的每个节点(比如，共识节点10a、共识节点10b、共识节点10c和共识节点10d等核心节点)上所存储的区块链10e为上述目标链，这里的目标链具体可以为上述目标链网络中的管理链，且从该管理链网络中的所确定的上述管理共识节点(或者目标核心节点)可以统称为目标共识节点。又比如，在共识网络200a被用作第一链网络，且该第一链网络为前述区块链电子票据三链网络中的票据链网络时，共识网络200a中的每个节点(比如，共识节点11a、共识节点11b、共识节点11c和共识节点11d等核心节点)上所存储的区块链11e为第一链，这里的第一链具体可以为上述区块链系统中的票据链，且从该票据链网络中所确定的票据共识节点(或者第一核心节点)可以统称为第一共识节点。即本申请实施例可以利用该票据链网络中的共识机制将在该票据链网络的共识节点中所选取的某个共识节点(即前述票据共识节点)作为第一共识节点，并可以将在该票据链网络的共识节点中，将除第一共识节点之外所剩余的共识节点统称为校验共识节点(此时，该校验共识节点具体为票据校验共识节点)。又比如，在共识网络300a被用作第二链网络，且该第二链网络为前述区块链电子票据三链网络中的应用合约链网络时，共识网络300a中的每个节点(比如，共识节点12a、共识节点12b、共识节点21c和共识节点12d等核心节点)上所存储的区块链12e为第二链，这里的第二链具体可以为上述区块链系统中的应用合约链，且从该应用合约链网络中所确定的应用共识节点(或者第二核心节点)可以统称为第二共识节点，即本申请实施例可以利用该第二链网络中的共识机制将在该应用合约链的共识节点中所选取的某个共识节点(即前述应用共识节点)作为第二共识节点，并可以将在该应用合约链网络的共识节点中，将除第二共识节点之外所剩余的共识节点也统称为校验共识节点(此时，该校验共识节点具体为应用校验共识节点)。
在上述区块链系统中，核心节点可以负责对应区块链所在的核心共识网络中的共识，也就是说核心节点可以为对应区块链所在核心共识网络中的共识节点。对于上述三个核心共识网络中的任意一个核心共识网络而言，将核心共识网络中的交易数据写入对应区块链账本(例如，分布式数据库)的具体过程可以为，用户客户端发送交易数据至某个业务节点，随后该交易数据以接力棒的方式在上述区块链网络内的业务网络中的业务节点之间传递，直到上述区块链网络内的相应核心共识网络中的共识节点(例如，共识网络200a中的共识节点11b)收到该交易数据，此时，共识节点(例如，共识网络200a中的共识节点11b)再将该交易数据打包进区块，以便于后续可以与其他共识节点之间进行共识，从而可以在共识通过后，将共识通过的区块写入自己所在核心共识网络(例如，共识网络200a)的分布式数据库。
可选的，可以理解的是，本申请实施例还可以在共识通过后，通过自己所在核心共识网络(例如，共识网络200a)的存储层将携带该交易数据的区块和与该区块关联的其他多个区块并行写入分布式数据库，这样可以从根源上突破区块链的区块链结构的限制，进而可以有效地提升数据存储的存储效率。
其中，可以理解的是，在上述区块链系统中，可以在相应核心共识网络的区块链上部署智能合约。比如，用户可以通过用户客户端发起一个交易业务请求的方式，调用相应核心共识网络(例如，上述共识网络200a)的区块链(例如，上述区块链11e)上已经部署的智能合约。
应当理解，在上述核心共识网络(例如，上述共识网络200a)的区块链(例如，上述区 块链11e)上可以部署一个或多个智能合约。而在上述区块链系统中，若用户客户端所指定的智能合约为需要跨链读取数据的智能合约(即跨链读取合约)，则各个共识节点会通过该跨链读取合约所指定的链标识，请求从对应区块链上进行数据的读取，最后各个共识节点会互相验证基于跨链读取到的信息执行交易后所得到的各交易执行结果是否一致(也就是进行共识)，若一致则可以将交易执行结果存入各自的本地缓存和本地存储中，并可以将上述交易业务的交易执行结果返回至客户端。
其中，可以理解的是，本申请实施例可以通过上述目标链网络中的目标共识节点为接入该区块链网络的任意一个角色(例如，任意一个个人用户、任意一个企业、任意一个机构等实体对象)配置一个区块链节点。所以，在如图1所示的业务网络400a中，业务节点110a、业务节点110b、业务节点110c、业务节点110d、…、业务节点110n可以分别与需要接入该区块链网络中的相应角色之间存在一一对应关系。
可以理解的是，在上述共识网络100a被作为上述目标链网络时，位于该目标链网络中的共识节点(例如，上述目标共识节点，该目标共识节点可以为图1所示的共识节点10a)可以为通过目标链网络入口而接入该目标链网络中的相应角色(或者相应对象)提供注册业务和授权业务，进而可以在该目标链网络中对需要接入上述区块链网络(例如，上述目标链网络、第一链网络或者第二链网络)中的相应角色(即相应对象)进行身份管理和权限管理。除此之外，位于该目标链网络中的目标共识节点还可以用于对上述区块链系统中的相关元数据信息进行数据管理，比如，可以管理更新目标链上的合约模板(应当理解，目标链上的合约模板具体可以包含部署在目标链上的智能合约的管理合约模板和部署在第二链上的智能合约的应用合约模板)，管理更新记录在目标链上的票据模板，管理更新与该票据模板相关联的计税规则等、控制第一链所对应链入口处的访问流量、控制各链上参与共识的共识节点的数量等。
比如，当开发者和税务业务参与方需要在第二链上部署某个第二业务对应的智能合约时，可以在通过第二链对应的链入口(即第二链入口)接入该第二链网络的情况下，进一步通过第二链上的跨链读取合约中的合约模板读取方法，从该合约模板读取方法所指示的目标链上读取该第二业务对应的应用合约模板，以在该第二链上基于读取到的应用合约模板部署该第二业务对应的智能合约。这样，当后续税务业务参与方需要在该第二链上执行第二业务时，则可以利用已经部署好的第二业务对应的智能合约来执行相应第二业务。
应当理解，在上述共识网络200a被作为上述第一链网络时，位于第一链网络中的共识节点(例如，上述第一共识节点，该第一共识节点可以为图1所示的共识节点11b)可以用于提供第一业务。这里的第一业务可以包含但不限于与上述电子票据相关联的票据业务，这里的票据业务具体可以包含电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务等与电子票据相关的业务。
此外，还可以理解的是，在上述共识网络300a被作为上述第二链网络时，位于第二链网络中的共识节点(例如，上述第二共识节点，该第二共识节点可以为图1所示的共识节点12b)可以用于提供与前述第一业务相关联的第二业务(例如，信贷业务、进出亏业务、企业资质业务、社交业务、赊购业务和退税业务、抽奖业务等)。
其中，可以理解的是，由于每个实体对象均可以对应一个区块链节点，所以，本申请实施例可以以实体对象为上述企业用户(即前述企业)为例，此时，与每个企业用户相关联的区块链节点可以为同一区块链节点(例如，上述图1所示的业务节点110c可以与多个企业用户所对应的用户终端进行数据交互)。比如，在上述区块链系统中，可以将每个企业用户所请求的第一业务(比如，电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务等与电子票据相关的业务)统称为一笔交易业务。其中，在上述企业用户为请求通过第一链网络(例如，上述共识网络200a)进行开票的开票企业A时，可以通过图1所示的业务节点110c与上述共识网络200a中的共识节点(例如，共识节点11b)进行数据交 互，以请求完成相应的交易；同理，开票企业B也可以通过图1所示的业务节点110c与上述共识网络200a中的共识节点(例如，共识节点11b)进行数据交互，以请求完成相应的交易；以此类推，开票企业C也可以通过图1所示的业务节点110c与上述共识网络200a中的共识节点(例如，共识节点11b)进行数据交互，以请求完成相应的交易。
其中，可以理解的是，本申请实施例可以将针对上述电子票据业务向第一链网络发送交易业务请求的实体对象(例如，开票企业A、开票企业B、...、开票企业C)统称为第一业务对象，并可以在业务网络(例如，上述业务网络400a)中，将与该第一业务对象(例如，开票企业A、开票企业B、...、开票企业C)相关联的区块链节点(例如，上述业务节点110c)统称为第一业务节点，还可以在核心共识网络(例如，上述作为第一链网络的共识网络200a)中，将获取该交易业务请求所指示的电子票据开具业务的区块链节点统称为上述第一共识节点。
可以理解的是，当与上述第一业务对象相关联的第一共识节点接收到与票据业务相关联的交易业务请求时，可以将该第一业务对象所发起的交易业务请求转发给第一共识节点，以通过第一共识节点对该第一业务对象所发起的交易业务请求进行合法性验证。这样，第一共识节点可以在合法性验证通过时，将该第一业务对象所请求的交易业务(比如，上述票据业务)添加至交易池，以便于后续可以将与该交易业务(比如，上述票据业务)相关联的交易数据打包成区块，以在共识网络200a中的共识节点之间进行区块共识，从而可以在区块共识通过后，将该区块的块数据写入至本地缓存和本地存储，以便于后续可以基于上述分布式存储实现多个区块的块数据的并行存储。
为便于理解，进一步的，请参见图2，图2是本申请实施例提供的一种基于多区块链的区块链电子票据平台的场景示意图。该区块链电子票据平台可以为上述多业务协作处理平台，即该区块链电子票据平台可以为上述区块链系统中的具体业务平台。应当理解，在该区块链电子票据平台中，为降低在链上数据存储的混杂度，提出了一种全新的基于区块链电子票据的多链体系，且该多链体系主要涉及图2所示的区块链电子票据三链网络。如图2所示，该区块链电子票据三链网络中部署有管理链、票据链和应用合约链。这里的管理链可以为上述目标链，这里的票据链可以为上述第一链，且这里的应用合约链可以为上述第二链。
其中，可以理解的是，在以区块链作为区块链电子票据核心数据流转的业务场景中，可以通过管理链、票据链和应用合约链之间的相互协作，为整个区块链电子票据平台提供独立执行不同业务的功能特性，从而可以在三链相互协作的前提下，构造一个安全且高效的业务流系统。应当理解，这里以多链系统为三链体系为例，在该三链系统下，管理链、票据链和应用合约链均是独立搭建的，即用于维护该管理链的共识节点不同于用于维护该票据链的共识节点，且不同于用于维护该应用合约链的共识节点。
如图2所示，部署在区块链电子票据三链网络中的管理链独立于票据链和应用合约链，即这三条独立搭建的区块链之间是彼此相互独立的，但是这三条独立搭建的区块链之间可以通过跨链的方式进行数据交互，即这三链之间可以进行跨链交互。比如，在如图2所示的票据链上部署有第一跨链读取合约的情况下，参与维护该票据链的共识节点(即上述第一共识节点)则可以通过该第一跨链读取合约，跨链读取管理链上的业务关联信息来进行业务权限的确认。又比如，在如图2所示的应用合约链上部署有第二跨链读取合约的情况下，参与维护该应用合约链的共识节点(即上述第二共识节点)可以通过该第二跨链读取合约，跨链读取管理链上的业务关联信息来进行业务权限的确认，还可以通过该第二跨链读取合约，跨链读取票据链上的核心数据(比如，票据链上的电子票据中的票据信息)来执行相应的衍生业务(即上述第二业务，比如，可以通过从票据链上所读取到的票据信息来执行上述征信业务，以得到某个企业的企业征信信息)。
比如，这里的管理链可以用于为整个区块链电子票据平台提供管理功能特性，这里的票据链可以为整个区块链电子票据平台提供不同业务权限类型的票据业务(即上述第一业务) 的功能特性。应当理解，在本申请实施例中，为确保写入票据链中的电子票据的安全性和独立性，本申请实施例提出可以通过独立于管理链和票据链的另一区块链(即图2所示的应用合约链)来提供更加规范、灵活和功能完备的衍生业务(即上述第二业务)，即这里的应用合约链则可以为整个区块链电子票据平台提供基于电子票据中核心数据来开展衍生业务的功能特性。
为便于理解，这里以管理链所在的核心共识网络(即上述管理链网络)为上述图1所示的共识网络100a为例，此时，参与维护该管理链的共识节点可以为上述管理共识节点。如图2所示，该管理链上部署有多个智能合约，这些智能合约可以运行在管理共识节点上。具体的，可以理解的是，这里的多个智能合约具体可以包含图2所示的对象权限管理合约、对象身份管理合约、元数据管理合约和内部管理合约。应当理解，该管理链上所部署的这些智能合约是由图2所示的内部参与方(即税务管理部门)分别通过自己链(即管理链)上部署的相应管理合约模板所确定的。
可以理解的是，前述税务管理部门可以通过该部署在管理链网络中的管理共识节点行使管理职责。比如，这里的管理职责具体可以包含对政务部门内部的信息(比如，税务管理部门内部人员的信息)进行管理、对整体业务的业务逻辑规则(例如，应用合约链上所运行的用于执行衍生业务的业务逻辑的衍生业务合约)进行管理、对整体业务的元数据信息(例如，三链体系下的各链入口处的访问流量)进行管理、对整体业务的参与者(比如，个人用户、企业用户、税务业务参与方等业务对象)进行身份管理和权限管理等。应当理解，在整体业务所对应的区块链网络中，由该管理共识节点所维护的管理链是相对更稳定、数据规模最小、但安全性最高的区块链。
此外，为便于理解，这里以图2所示的票据链所在的核心共识网络(即上述票据链网络)为上述图1所示的共识网络200a为例，此时，参与维护该票据链的共识节点可以为上述第一共识节点。如图2所示，该票据链上部署有多个智能合约，这些智能合约可以运行在第一共识节点上。具体的，可以理解的是，这里的多个智能合约具体可以包含图2所示的电子票据开具合约、电子票据流转合约、电子票据红冲合约、电子票据归档合约和第一跨链读取合约。同理，应当理解，该票据链上所部署的这些智能合约是由图2所示的内部参与方(例如，与电子票据数据中心相关联的税务部门)通过管理链上部署的相应票据业务合约模板所确定的。
可以理解的是，该部署在票据链网络中的第一共识节点可以通过票据链维护电子票据在全生命周期内的业务逻辑，比如，可以通过该票据链管理所有开具的电子票据的全生命周期。比如，这里的电子票据的全生命周期包含电子票据的开具、电子票据的流转和电子票据的报销等。应当理解，在整体业务所对应的区块链网络中，由该第一共识节点所维护的票据链具有高性能、低延迟的特点。
同理，为便于理解，这里以应用合约链所在的核心共识网络(即上述应用合约链网络)为上述图1所示的共识网络300a为例，此时，参与维护该应用合约链的共识节点可以为上述第二共识节点。如图2所示，该应用合约链上部署有多个智能合约，这些智能合约具体可以运行在第二共识节点上。具体的，可以理解的是，这里的多个智能合约具体可以包含图2所示的虚拟机兼容合约、开放合约部署合约、衍生业务合约和第二跨链读取合约。
可以理解的是，该部署在应用合约链网络中的第二共识节点可以通过应用合约链承载可变化的票据业务所对应的衍生业务，比如，这里的衍生业务可以具体可以包含上述征信业务、上述资质识别业务等。应当理解，在整体业务所对应的区块链网络中，由该第二共识节点所维护的应用合约链，可以支持图2所示的政务协作部门和联盟链伙伴(即图2所示的业务关联部门)，通过图2所示的税务应用合约(开放合约部署合约)间接调用第二跨链读取合约，以利用跨链读取到的管理上的应用合约模板来开发与衍生业务相关的智能合约(例如，图2所示的衍生业务合约)，并可以经过税务管理部门审核后将该衍生业务合约部署在应用合约链上。应当理解，部署在应用合约链上的智能合约可以通过虚拟机兼容合约实现智能合约的 灵活升级和变化，应当理解，在整体业务所对应的区块链网络中，该第二共识节点可以通过应用合约链上的第二跨链读取合约实现跨链交互，比如，可以通过第二跨链读取合约从票据链上读取上述核心数据来执行衍生业务。这意味着由该第一共识节点所维护的应用合约链，相较于管理链和票据链而言，具有最高的开放度，且支持复杂的智能合约逻辑，参与方较多且不断动态变化，性能相对低于票据链。
其中，可以理解的是，在图2所示的区块链电子票据三链网络中，管理链所采用的共识算法，不同于票据链所采用的共识算法，也不同于应用合约链所采用的共识算法。
具体的，1.1)与管理链相关联的共识算法为一种即时确定性共识算法，比如，这里的即时确定性共识算法可以为PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错)共识算法，通过该PBFT共识算法可以立即确定某个待上链的提议区块的状态。应当理解，该管理链为上述管理链网络中的区块链，在该管理链网络中的共识节点(即上述管理共识节点)可以由图2所示的税务管理部门参与进行管理。
应当理解，与该管理链相关联的内部参与方可以为图2所示的税务管理部门，比如，该税务管理部门在作为内部参与方参接入该管理链时，可以通过管理链上的内部管理合约对该税务管理部门的一些内部状态进行管理，比如，可以对该税务管理部门中的各人员进行管理，比如，可以在税务管理部门的这些人员中配置特定的税务管理人员、税务开发人员、税务审计人员等。此外，该税务管理部门在作为内部参与方参接入该管理链时，还可以通过管理链上的内部管理合约对该三链体系中的一些参数进行管理，比如，通过该内部管理合约可以对图2所示的票据链入口处的访问流量所对应的访问流量参数进行限制，例如，可以通过分时访问机制控制票据链入口处的某些特定时间段内的访问流量不大于访问流量阈值。又比如，该税务管理部门在作为内部参与方参接入该管理链时，还可以通过管理链上的内部管理合约对参与共识的各链上的共识节点的数量所对应的节点数量参数进行限定。
1.2)与票据链相关联的共识算法为另一种即时确定性共识算法，比如，这里的即时确定性共识算法可以为TBFT(Tower Byzantine Fault Tolerance，塔式拜占庭容错)共识算法，该TBFT共识算法是一种拜占庭容错算法，可以在拜占庭节点数(即票据链网络中的作恶节点数)小于票据链网络的节点总数1/3的情况下，保证整个票据链网络系统的安全运行。应当理解，处于票据链网络中的共识节点可以由前述税务管理部门参与进行管理，比如，税务管理部门中的特定税务人员可以通过上述管理链中的内部管理合约控制该票据链网络中的共识节点的数量。又比如，税务管理部门中的特定税务人员所对应的税局终端可以参与构成该票据链网络。
应当理解，上述TBFT共识算法与PBFT共识算法的最大区别在于：PBFT共识算法有一个固定的leader节点(即主节点)用于打包交易池中的交易，当leader节点故障的时候会使用view-change子协议(即一种主节点切换子协议)更换leader节点；而在TBFT共识算法中，leader节点是基于轮换机制而轮换的，比如，在当前节点被作为leader节点时，每提交X个区块(X的值可以配置)，则会自动将该leader节点轮换成下一个节点。这意味着在该票据链对应的票据链网络中的共识节点可以用于连续出块。
1.3)与应用合约链相关联的共识算法为又一种即时确定性共识算法，比如，这里的即时确定性共识算法可以为PoS(Proof-of-Stake，权益证明)共识算法，通过该权益证明共识算法可以维护该应用合约链所在应用合约链网络的网络安全性，且通过该权益证明共识算法可以立即确定某个待上链的提议区块的状态。可以理解的是，在该应用合约链网络中的共识节点可以由图2所示的税务管理部门和政务协作部门以及大型参与机构(即前述联盟链中的大型企业，该大型企业即为前述图2所示的业务关联部门)等共同参与进行管理。比如，税务管理部门中的税务人员(比如，图2所示的税务业务参与方)可以通过应用合约链网络中的共识节点跨链读取前述票据链上所写入的电子票据的票据信息，以通过跨链读取到的票据信息执行与前述票据业务相关联的衍生业务。比如，可以通过跨链读取到的票据信息对请求开票 的开票企业进行资质识别或者征信识别，以得到该开票企业的资质数据或者征信数据。应当理解，如图2所示，这里的税务业务参与方在通过图2所示的应用合约链入口接入应用合约链网络时，可以调用该图2所示的应用合约链上的第二跨链读取合约，从图2所示的票据链上读取基于衍生业务所请求的电子票据中的核心数据，以利用读取到的核心数据在该应用合约链上开展相应的衍生业务。
应当理解，在本申请实施例中，无需将票据链上所产生的大量的电子票据直接跨链转移至应用合约链，而是将票据链上所产生的这些电子票据中的部分授权可见的票据信息(即前述核心数据)跨链转移至应用合约链，这样可以从根源上确保票据链上所记录的这些电子票据的隐私性和安全性。
由此可见，对于请求接入上述应用合约链中的税务业务参与方而言，可以根据所请求的衍生业务的不同，从票据链上跨链读取到不同的核心数据(即可以从上述电子票据中获取到不同数据内容的票据信息)。
应当理解，针对该区块链电子票据三链网络中的智能合约而言，存在以下区别：
2.1)应当理解，如图2所示的管理链上可支持特定语言智能合约引擎，上述管理共识节点通过该特定语言智能合约引擎可以在管理链上部署特定语言智能合约，比如，可以在管理链上部署上述图2所示的对象权限管理合约、对象身份管理合约、元数据管理合约和内部管理合约等。应当理解，这些智能合约可以由税务管理部门中的特定税务管理人员开发和管理。
2.2)如图2所示的票据链上内置有特定票据业务逻辑的智能合约，这些智能合约(例如，上述图2所示的电子票据开具合约、电子票据流转合约、电子票据红冲合约、电子票据归档合约和第一跨链读取合约)可以随着票据业务的更新而进行升级。比如，本申请实施例可以通过从管理链上所读取到的元数据信息更新电子票据开具合约中的票据业务逻辑，进而可以根据更新后的电子票据开具合约来更新处理上述票据业务。这意味着该票据链不支持独立的智能合约引擎，自然也就不支持在该票据链上部署与票据业务无关的其他合约。这样做的好处是让该票据链仅运行与电子票据相关的业务逻辑，且不受其他智能合约的影响，从而可以使该票据链的运行更加独立稳定，更抗攻击。
2.3)该应用合约链上支持多语言、图灵完备面向开发者的智能合约，比如，如图2所示，开发者在通过应用合约链入口接入该应用合约链时，可以通过虚拟机兼容合约兼容主流的EVM虚拟机，以便于可以在兼容的虚拟机上部署运行各种新的业务合约，比如，可以在应用合约链上部署与衍生业务(例如，上述抽奖业务)相关联的衍生业务合约。又比如，可以在应用合约链上部署与另一衍生业务(例如，上述退税业务)相关联的衍生应用合约。
应当理解，如上述图2所示，在区块链电子票据三链网络中，并未在管理链上部署跨链读取合约，故而此时，该管理链并不具备跨链能力。由于图2所示的票据链和应用合约链上均部署有跨链读取合约，故而具备跨链能力。
具体的，与票据链相关联的共识节点(例如，上述第一共识节点)可以通过图2所示的第一跨链读取合约从管理链读取部分管理链信息，比如，可以从管理链读取用于存入票据链入口处的授权对象的注册数据信息；又比如，可以从管理链上读取用于对第一业务对象的业务权限进行确认的第一业务关联信息，还可以从管理链上读取用于开具电子票据(例如，电子发票)时的票据关键信息。
其中，这里的票据关键信息是指在确定业务权限为开票权限类型时，基于该票据业务中的电子票据业务从管理链上所读取到的授权可见的辅助元数据信息(例如，管理上所记录的更新后的电子票据模板)。
此外，与应用合约链相关联的共识节点(例如，上述第二共识节点)可以通过图2所示的第二跨链读取合约从管理链读取部分管理链信息，比如，可以从管理链上读取用于存入图2所示的应用合约链入口的授权对象的业务参与许可凭证，也可以从管理链读取用于对请求执行衍生业务的业务对象进行业务鉴权的第二业务关联信息，还可以从票据链读取部分票据 链信息(例如，从票据链读取与衍生业务相关联的电子票据中的部分授权可见的票据信息)。应当理解，第二共识节点从管理链读取到的部分管理链信息和部分票据链信息均可以用于开展上述衍生业务。
应当理解，如图2所示，在区块链电子票据三链网络中，与管理链相关联的公开网络参与方可以为图2所示的个人用户和企业用户。同理，如图2所示，与票据链相关联的公开网络参与方可以为图2所示的各地电子票据数据流系统。这里的各地电子票据数据流系统具体包含各地方电子票据业务开具系统(例如，各地方税局系统)，电子票据开票服务商，大型企业财税相关系统等。同理，如图2所示，与应用合约链相关联的公开网络参与方可以为图2所示的税务业务参与方和开发者。
具体的，3.1)与管理链相关联的链入口可以为图2所示的管理链入口。当图2所示的个人用户(例如，用户A)和企业用户(例如，企业B)等作为公开网络参与方时，可以通过该管理链入口接入管理链，进而可以通过该管理链进行身份注册和身份授权等业务。3.2)与票据链相关联的链入口可以为图2所示的票据链入口。当图2所示的各地方电子票据数据流系统(例如，大型企业用户)等作为公开网络参与方时，可以通过该票据链入口接入票据链，进而可以通过该票据链执行电子票据开具业务、电子票据流转业务、电子票据红冲业务和电子票据归档业务。3.3)与应用合约链相关联的链入口可以为图2所示的应用合约链入口。当图2所示的税务业务参与方和开发者等作为公开网络参与方时，可以通过该应用合约链入口接入应用合约链，进而可以通过在应用合约链上部署衍生业务合约，以通过部署的衍生业务合约执行与电子票据相关的衍生业务。应当理解，图2所示的开发者还可以在接入应用合约链的情况下，在该应用合约链上部署其他衍生业务(或者探索业务)所对应的衍生业务合约，这里将不对部署在应用合约链上的衍生业务合约的合约数量进行限定。
其中，可以理解的是，图2所示的管理链入口具体可以为税务管理部门入口，通过该税务管理部门入口可以对需要接入管理链的个人、法人以及实体等进行身份识别和业务引导。
其中，可以理解的是，图2所示的票据链入口具体可以为电子票据业务入口，通过该电子票据业务入口可以接收某个业务对象(例如，第一业务对象，该第一业务对象可以为上述企业B)所请求开具的电子票据的交易业务数据(也可以称之为交易数据)。这样，在上述第一共识节点通过该电子票据业务入口接收到前述企业B提交的交易业务数据时，还可以通过该电子票据业务入口校验该交易业务数据的数据发送方(即作为第一业务对象的企业B)的接入身份和接入权限是否满足管理链中身份权限合约状态要求，进而可以在校验通过时，确定作为第一业务对象的企业B为授权对象，进而可以通过票据链上的第一跨链读取合约从管理链上读取前述第一业务关联信息确定该作为授权对象的企业B的业务权限。应当理解，通过第一业务关联信息可以进一步判断作为授权对象的企业B的业务权限是否满足管理链中对象权限管理合约的状态要求。
比如，上述第一共识节点通过该电子票据业务入口可以判断数据发送方(即企业B)的接入身份和接入权限是否满足管理链中的对象身份管理合约和内部管理合约的合约状态要求，进而可以在确定满足管理链中的对象身份管理合约和内部管理合约的合约状态要求时，确定完成对需要接入该票据链的数据发送方(即前述企业B)的身份鉴权。由此可见，上述图2所示的票据链入口处存储有从管理链同步来的各个授权对象的注册数据信息，这里的注册数据信息可以包含但不限于对象接入身份注册信息和对象接入权限注册信息。比如，这里的对象接入身份信息可以用于识别当前请求接入该票据链的第一业务对象(即前述企业B)是否为授权对象。这里的对象接入权限注册信息包含由管理共识节点通过内部管理合约为该票据链的电子票据业务入口所配置的请求累计阈值(例如，最大并发请求累积量)。上述第一业务关联信息则可以用于表征作为授权对象的该第一业务对象(即前述企业B)具体具备访问票据链上的哪些票据业务合约的权限。
其中，可以理解的是，图2所示的应用合约链入口具体可以为税务衍生业务入口，通过 该税务衍生业务入口可以接收某个业务对象(例如，第二业务对象，该第二业务对象可以为图2所示的税务业务参与方)所请求参与的与票据业务相关联的衍生业务。应当理解，在图2所示的税务业务参与方和开发者可以在获得税务管理部门发放的授权对象的业务参与许可凭证后，可以通过该应用合约链入口对第二业务对象(例如，税务业务参与方或者开发者)提交的业务参与许可凭证进行验证，进而可以在验证成功时允许该第二业务对象接入该应用合约链，以在该应用合约链上执行与前述票据业务相关联的衍生业务。
其中，如图2所示，参与维护管理链的内部参与方可以为图2所示的税务管理部门，这里的税务管理部门主要用于在管理链上进行内部状态参数的配置与管理，还可以用于对上述元数据信息(例如，税务元数据)进行变更上链(如可以更新电子票据模板，更新计税规则等)，以及可以对于该管理链上所维护的各类业务参与方的身份和权限进行管理(如冻结企业开票资质，限制企业开票额度等)。
其中，如图2所示，参与维护票据链的内部参与方可以为图2所示的电子票据数据中心，这里的电子票据数据中心具体可以为电子发票数据中心，该电子票据数据中心(比如，电子发票数据中心)可以用于对票据链上所记录的海量的账本数据(例如，基于上述实时票据业务流所产生的电子票据流等)进行链下备份、统计、数据分析和审查等工作。具体的，通过该电子票据数据中心可以统计分时开票数量，进而可以基于统计到的分时开票数量对风险票据(例如，风险发票)、风险企业进行判定，还可以对相关金融经济数据进行数据分析等。
其中，如图2所示，参与维护应用合约链的内部参与方可以为图2所示的政务协作部门和业务关联部门。应当理解，参与维护应用合约链的内部参与方除了税务管理部门之外，系统联盟链中的其他部门(即前述政务协作部门)和参与方(即前述业务关联部门)均可以在接入该应用合约链的情况下，进一步通过该应用合约链上的衍生业务合约执行相应的衍生业务。可以理解的是，图2所示的政务协作部门和业务关联部门等作为税务业务参与方，接入应用合约链的好处是可以在支持完备的智能合约声明周期中灵活运行各类可扩展的衍生业务，以确保业务变化的灵活性，同时不需要直接接触上述票据链上的电子票据的核心数据，从而保证了票据链上的数据隐私和核心数据安全。这意味着本申请实施例所涉及的第二共识节点可以在应用合约链上的第二跨链读取合约(具体的，可以通过第二跨链读取合约中的跨链读取方法)，对票据链上针对当前衍生业务所部分授权可见的票据链数据进行读取，比如，可以从票据链上跨链读取与当前衍生业务相关的核心数据(这里的核心数据可以为上述电子票据流所涉及的各电子票据中的票据信息，对于电子票据为电子发票而言，这里的票据数据具体可以为部分授权可见的发票数据)，以通过读取到的核心数据来确保上述第二业务对象所请求的衍生业务，可以在该应用合约链上进行有效的开展。
在一些可实现的其他实施例中，为增加位于票据链上的电子票据的数据隐私性，第二共识节点还可以通过第二跨链读取合约中的跨链授权方法所指示的目标链标识(比如，这里的目标链标识为票据链对应的链标识)，请求该票据链所对应的第一共识节点在该票据链上读取与该衍生业务相关联的电子票据(例如，C企业所开具的电子票据)，进而可以在读取到的电子票据的票据信息中，将与衍生业务相关联的票据信息作为前述授权可见的核心数据返回给第二共识节点。应当理解，此时，对于第二共识节点而言，无法得知该电子票据中与该衍生业务无关的其他票据信息，更无法触及到该票据链上与该衍生业务无关的其他电子票据(例如，D企业所开具的电子票据)，这样，可以确保存储在该票据链上的所存储票据数据的隐私安全性和可靠性。
其中，可以理解的是，在图2所示的区块链电子票据三链网络中，均可以内置相应的智能合约。
其中，4.1)对于管理链上内置的智能合约而言，如图2所示，内置在管理链上的对象身份管理合约具体可以为用户管理合约，通过该用户管理合约可以管理整个三链体系下的接入者(比如，公开网络参与方)和参与者(比如，内部参与方)的身份。应当理解，这里的接入 者和参与者具体可以包含税务管理人员(简称管理员)、政务协作部门、地方税局、开票服务商、报销服务商、税务审查部门等。此外，内置在管理链上的对象权限管理合约具体可以为企业身份管理合约，通过该企业身份管理合约可以对某些企业的业务权限和税务状态等进行管理。同理，内置在管理链上的元数据管理合约具体可以为税务元数据管理合约，通过该税务元数据管理合约可以对税务规则等元数据信息进行管理，如可以集中管理三链体系下的合约模块，计税逻辑，最新政策规则等。以此类推，内置在管理链上的内部管理合约则可以用于对税务管理部门的一些内部状态进行管理，并可以对三链体系下的各链上的一些内部参数进行管理，如，可以通过该内部管理合约对上述票据链入口(比如，电子发票业务入口)处的访问流量参数进行限制，以及对三链体系下的共识节点数量参数进行限制等。
其中，4.2)对于票据链上内置的智能合约而言，如图2所示，内置在票据链上的智能合约可以包含跨链读取合约和与电子票据生命周期相关联的票据业务合约。这里的跨链读取合约可以为图2所示的第一跨链读取合约，且这里的票据业务合约具体可以包含图2所示的用于提供电子票据开票业务的电子票据开具合约，用于提供电子票据流转业务的电子票据流转合约、用于提供电子票据红冲业务的电子票据红冲合约以及用于提供电子票据归档业务的电子票据归档合约。其中，第一跨链读取合约可以用于跨链读取管理链上的元数据信息，以更新该票据链上的一些业务参数。比如，具体可以在跨链读取到的元数据信息为更新后的电子票据模板的情况下，对该票据链上的电子票据模板的模板参数进行更新。由此可见，管理链上的部分管理链信息(比如，该管理链上的元数据信息)对运行有第一跨链读取合约的第一共识节点和运行有第二跨链读取合约的第二共识节点是授权可见的。
其中，4.3)对于应用合约链上内置的智能合约而言，如图2所示，内置在票据链上的智能合约可以包含另一跨链读取合约(即第二跨链读取合约)，还可以包含由税务衍生业务参与方(即衍生业务对象，例如，图2所示的税务业务参与方)参与部署的各类合约(例如，图2所示的虚拟机兼容合约、税务应用合约和衍生业务合约等)。比如，这里的衍生业务合约具体可以为基于电子票据的征信业务合约，通过该征信业务合约可以分析得到某个企业的征信数据。又比如，这里的衍生业务合约具体还可以是为鼓励开票所部署的链上抽奖业务合约和人才激励合约以及退税业务合约等。其中，可以理解的是，这里的第二跨链读取合约，可以用于跨链读取管理链上的元数据信息(例如，与退税业务相关联的最新政策规则)，以更新该应用合约链的一些业务参数(例如，可以更新该应用合约链上所部署的退税业务合约的合约参数)，此外，这里的第二跨链读取合约，还可以用于跨链读取票据链上部分授权可见的票据信息，以通过跨链读取到的部分授权可见的票据信息来执行该应用合约链上的衍生业务的业务逻辑等。
应当理解，对于上述图2所示的管理链而言，主要用于处理数据量较小、状态较恒定的管理性业务流，整个管理链的开放性相对较低，可以用于对一些税务数据进行内部管理。而对于上述图2所示的票据链而言，可以用于处理一些数据量长期处于高频请求状态的实时票据业务流，该整个票据链的开放性相对较高，可以允许与电子票据本身生命周期中的相关权威机构参与相应的票据业务，比如，可以允许与代理服务商对应的共识节点为当前请求开票的某个用户开具电子票据。此外，对于图2所示的应用合约链而言，数据量的大小可以无需限定、业务变化的频率波动相对较大，主要是可以通过该应用合约链处理各类合作业务、衍生业务、探索性业务等。应当理解，该应用合约链具有最高的开放性，可以运行由管理链授权的参与者在该应用合约链上部署智能合约、运行探索性的衍生业务等。应当理解，在本申请实施例中，考虑到应用合约链具有较高的开放性和业务变更的灵活性，所以，内置在应用合约链上智能合约在执行时可以有更多的合约安全限制。比如，可以对合约执行步数进行限制(例如，对于上述图2所示的衍生业务合约而言，可以限定当前业务对象(即上述第二业务对象)具体能够访问衍生业务合约中哪些合约方法)，并可以对访问该衍生业务合约所需要消耗的存储资源数据等进行限制(即应用合约上的智能合约的调用需要消耗一定数量的存 储资源数据)。
其中，可以理解的是，本申请实施例所涉及的三链体系下的共识节点可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、以及大数据和人工智能平台等基础云计算服务的云服务器。
需要说明的是，本申请实施例中的共识节点在跨链获取业务对象(例如，上述个人用户或者企业用户)的注册数据信息、业务参与许可凭证、电子票据中的票据信息等数据时，可以显示提示界面或者弹窗，该提示界面或者弹窗用于提示业务对象当前正在搜集注册数据信息、业务参与许可凭证、电子票据中的票据信息等数据，仅仅在获取到业务对象对该提示界面或者弹窗发出确认操作后，开始执行数据获取的相关的步骤，否则结束。
此外，可以理解的是，在本申请的具体实施方式中，可能涉及到用户、企业、机构等业务对象的业务数据(例如，用户的开票信息、征信信息、退税信息等，企业的进出亏、企业资质等信息)，当本申请以上实施例运用到具体产品或技术中时，需要获得用户、企业、机构等业务对象的许可或同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
其中，在票据链上执行票据业务的具体过程和在应用合约链上执行与票据业务相关联的衍生业务的具体过程，可以参见如下图3至图8所对应的实施例。
进一步的，请参见图3，图3是本申请实施例提供的一种多区块链数据处理方法，如图3所示，方法可以由上述第一链网络中的第一共识节点执行，比如，该第一共识节点可以为上述图1所示的共识网络200a中任意一个共识节点。方法具体可以包括以下步骤S101-步骤S103。
步骤S101，获取第一业务对象请求的第一业务，基于第一业务调用第一链上的第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息；第一链为第一链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第一链网络，第一链不同于目标链；
其中，可以理解的是，本申请实施例所涉及的第一链网络为上述区块链电子票据三链网络中的一个共识网络。此外，可以理解的是，在本申请实施例中，该第一链网络部署在相对安全的私有云中，且处于该私有云中的第一链网络内的各共识节点上均运行有基于上述TBFT共识算法的区块链共识协议，这样，通过前述区块链共识协议所对应的共识机制，可以确保在该第一链网络中的各共识节点之间的访问安全性。
然而，对于处于公网中的公开网络参与方(例如，上述图2所示的个人用户和企业用户等业务对象)而言，若需要接入该第一链网络，则需要先通过上述图2所示的第一链入口对请求接入该第一链网络的公开网络参与方进行身份校验和权限校验，以确保接入该第一链网络的公开网络参与方的访问安全性。
为便于理解，本申请实施例可以将该请求接入该第一链网络的公开网络参与方统称为第一业务对象，进而可以通过前述第一链入口对该第一业务对象进行身份鉴权。
其中，可以理解的是，在本申请实施例中，与第一链网络对应的链入口可以为上述第一链入口(这里的第一链入口具体还可以为电子发票业务入口)；该第一链入口存储有第一共识节点在第一跨链读取时间戳时通过第一跨链读取合约从目标链上所同步来的授权对象的注册数据信息；
具体的，第一共识节点可以通过第一链网络的第一链入口，获取第一业务对象对应的第一业务节点基于第一业务发送的第一业务处理请求；第一业务处理请求中携带第一业务对象针对第一业务提交的交易业务数据、以及第一业务对象的第一签名信息；第一签名信息是由与第一业务对象相关联的第一业务节点通过第一业务对象的第一私钥信息，对交易业务数据进行签名后所得到的；第一业务对象的第一私钥信息是第一业务对象通过目标链中的对象身 份管理合约进行身份注册后得到的；进一步的，第一共识节点可以从第一业务处理请求中获取第一签名信息，基于第一链入口中存储的授权对象的注册数据信息对第一签名信息进行签名验证，得到第一业务对象的签名验证结果；进一步的，第一共识节点可以在第一业务对象的签名验证结果指示签名验证成功时，确定第一业务对象为授权对象，且基于交易业务数据确定与第一业务对象相关联的第一业务；进一步的，第一共识节点可以基于第一业务调用第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息。其中，应当理解，这里的第一业务可以包含但不限于，与电子票据相关联的票据业务、与电子证书相关联的证书业务、与电子处方相关联的处方业务，即本申请实施例可以根据不同的业务应用场景，构建得到与不同业务场景相适配的三链体系。为便于理解，这里以第一业务为与电子票据相关联的票据业务为例，阐述在该第一链网络中执行该票据业务的具体过程。
为便于理解，进一步的，请参见图4，图4是本申请实施例提供的一种通过链入口进行身份鉴权的场景示意图。如图4的用户43b可以为上述第一业务对象，即此时，用户43b为上述请求接入第一链网络40a的公开网络参与方。应当理解，在本申请实施例中，该用户43b所使用的用户终端43a可以为该第一业务对象对应的第一业务节点。应当理解，这里的第一业务节点可以为上述图1所示业务网络400a中的业务节点，此时，这里的第一业务节点可以用于执行某个交易(例如，转账交易)，以得到这笔转账交易所对应的交易业务数据，进而可以将该交易业务数据，该用户43a(即第一业务对象)的签名信息一并添加到图4所示的第一业务处理请求中，以将该第一业务处理请求发送至与图4所示的第一链网络40a对应的链入口42a。
其中，应当理解，这里的链入口42a即为上述第一链入口。如图4所示，该第一链入口可以用于存储图4所示的授权对象的注册数据信息，该授权对象的注册数据信息中具体可以包含图4所示的授权对象A的公钥证书A1、授权对象B的公钥证书B1、…、授权对象N的公钥证书N1。
其中，应当理解，链入口42a处所存储的授权对象的注册数据信息是由第一链网络40a中的共识节点从图4所示的目标链42e上所同步来的。由于该第一链网络中的共识节点中运行有上述TBFT共识算法，所以，在TBFT共识算法中，leader节点是轮换的前提下，假设上一轮用于连续出块的leader节点为图4所示的共识节点41c，且本轮用于连续出块的leader节点为图4所示的共识节点41d，那么，共识节点41c则可以在上一轮被作为第一共识节点，且共识节点41d则可以在本轮被作为新的第一共识节点。基于此，链入口42a处所存储的授权对象的注册数据信息具体可以包含历史作为第一共识节点的共识节点41c通过图4所示的第一跨链读取合约从目标链(例如，图4所示的目标链42e)上所同步来的第一类授权对象的注册数据信息(例如，授权对象A的公钥证书A1和授权对象B的公钥证书B1)，还可以包含当前作为第一共识节点的共识节点41d通过图4所示的第一跨链读取合约从目标链(例如，图4所示的目标链42e)上所同步来的第二类授权对象的注册数据信息(例如，授权对象N的公钥证书N1)。应当理解，这里的第一类授权对象的注册数据信息和第二类授权对象的注册数据信息主要是用于区分哪些是由自己作为第一共识节点所同步的，哪些是由其他节点作为第一共识节点时所同步的。
应当理解，本申请实施例可以将第一链网络40a中的共识节点(例如，前述共识节点41c和共识节点41d)历史调用第一跨链读取合约的时间戳统称为第一跨链读取时间戳，并可以将第一链网络40a中的共识节点(例如，共识节点41d)当前调用第一跨链读取合约的时间戳统称为第二跨链读取时间戳，即这里的第二跨链读取时间戳为第一跨链读取时间戳之后的时间戳，这里将不对第二跨链读取时间戳和第一跨链读取时间戳之间的时间戳间隔进行限定。
为便于理解，这里以共识节点41d作为第一共识节点为例，阐述对该用户43b进行身份鉴权的具体过程。即该第一共识节点具体可以在前述第一跨链读取时间戳时通过第一跨链读取合约中的身份鉴权方法，将从目标链(例如，目标链42e)上所同步来的授权对象N的公 钥证书N1添加至图4所示的授权对象的注册数据信息中，以便于后续可以基于该链入口42a本地所存储的授权对象的注册数据信息快速对当前请求执行第一业务的第一业务对象进行身份鉴权，进而可以在该第一链网络40a中提升实时业务流的处理效率。
比如，在上述区块链系统应用于区块链电子票据场景下，当第一业务为上述票据业务时，这里的实时业务流具体可以为实时电子票据流，即该实时电子票据流具体可以是指由第一共识节点通过前述第一链入口(比如，链入口42a)所确定的处于高频请求状态的大量票据业务所构成的票据业务流。
应当理解，可选地，本申请实施例所涉及的第一链入口(比如，链入口42a)还存储有从目标链同步来的请求累计阈值(这里的请求累计阈值用于表征该第一链入口处的访问流量，应当理解，这里的请求累计阈值包含但不限于最大并发请求累计量)。应当理解，该链入口42a所获取到的第一业务处理请求的最大并发请求累计量，具体是由目标链网络40b中的管理共识节点上所运行的内部管理合约所确定的。应当理解，在本申请实施例中，该目标共识节点(例如，图4所示的共识节点42a)上所运行的内部管理合约可以用于对三链体系下的各链入口处所获取到的最大并发请求累计量进行管理。应当理解，通过控制各链入口处的并发访问流量(即前述最大并发请求累计量)，可以有效地确保在该第一链网络40a中的第一业务流的稳定执行，进而可以确保第一共识节点有足够的存储资源来存储由大量业务数据所构成的业务数据流。
其中，为便于理解，本申请实施例可以将该用户43a(即第一业务对象)的签名信息统称为第一签名信息，且该第一签名信息是该用户43a(即第一业务对象)通过自己的私钥信息(即第一业务对象的第一私钥信息)对前述交易业务数据进行签名后所得到的。这样，当图4所示的链入口42a获取到该第一业务处理请求时，可以统计得到该第一业务处理请求所对应的请求累积量，进而可以在该第一业务处理请求所对应的请求累积量未达到请求累计阈值(例如，上述最大并发请求累计量)时，初步完成对该用户43b的接入权限验证(也称之为访问权限验证)，此时，该第一共识节点可以进一步从该第一业务处理请求中获取到该第一业务对象的第一签名信息，进而可以从链入口42a中存储的授权对象的注册数据信息中快速获取到授权对象的公钥证书(例如，图4所示的授权对象A的公钥证书A1、授权对象B的公钥证书B1、…、授权对象N的公钥证书N1)，以通过这些获取到的公钥证书对该用户43b进行身份验证。应当理解，本申请实施例可以在该第一业务处理请求所对应的请求累积量达到请求累计阈值(例如，上述最大并发请求累计量)时，直接拒绝该用户43b发送的第一业务处理请求，并生成用于提示该用户43b进行接入等待的通知消息。
应当理解，这里的每个授权对象的公钥证书中均包含有对应授权对象的公钥信息。这样，该第一共识节点就可以进一步在这些授权对象的公钥证书中查找是否存在该用户43b的公钥证书。1)如果存在，则可以将该用户43b的公钥证书作为查找到的该第一业务对象的第一公钥证书，进而可以将该第一公钥证书中所记录的该用户43b的公钥信息作为第一公钥信息，以通过该第一公钥证书以及第一公钥信息对前述第一签名信息进行签名验证，从而可以得到第一业务对象的签名验证结果。2)如果不存在，即该第一共识节点并未在这些授权对象的公钥证书中查找是否存在该用户43b的公钥证书时，则确认该用户43b(即第一业务对象)为非法业务对象，进而可以拒绝该作为非法业务对象的用户43b所发送的第一业务处理请求。
其中，应当理解，本申请实施例还可以进一步结合链入口42a处所存储的公钥证书的证书数据信息(例如，证书的版本信息、证书的哈希值以及与该证书的哈希值相关联的根证书哈希值等)来对上述第一签名信息进行签名验证，以确保用于进行签名验证的公钥证书(即前述第一公钥证书)中的公钥信息(即前述第一公钥信息)的可靠性。
具体的，第一共识节点可以将第一公钥证书的证书数据信息作为待处理证书信息，且可以在第二跨链读取时间戳时调用第一跨链读取合约中的证书数据读取方法，从目标链上读取第一业务对象的公钥证书；第二跨链读取时间戳为第一跨链读取时间戳的下一跨链读取时间 戳；进一步的，该第一共识节点可以将读取到的第一业务对象的公钥证书中的证书数据信息作为目标证书信息，进而可以在待处理证书信息与目标证书信息保持一致时，基于第一公钥信息对第一签名信息进行签名验证，并将签名验证成功时的验证结果作为第一业务对象的签名验证结果。
可选地，可以理解的是，在待处理证书信息与目标证书信息保持一致时，则需要用在第二跨链读取时间戳时从目标链上所读取到的该用户43b的公钥证书对前述第一公钥证书进行更新处理，进而可以通过更新处理后的第一公钥证书中的公钥信息对第一签名信息进行签名验证，以确保该用户43b所请求第一业务能够在该第一链网络中的顺利执行。
其中，应当理解，本申请实施例所涉及的授权对象的公钥证书是由目标链网络中的目标共识节点调用目标链中的对象身份管理合约(即上述图2所对应实施例中的对象身份管理合约)，对请求注册相应交易业务(例如，前述第一业务)的业务对象所提交的对象数据信息(比如，这里的对象数据信息可以具体包含上述用户43b的基础用户数据信息、上述用户43b需要执行的交易业务、以及该交易业务的业务类型等)进行身份注册后所得到的；应当理解，在目标共识节点成功为该请求注册相应交易业务(例如，前述第一业务)的业务对象配置相应业务所对应的公钥证书的情况下，可以将该请求注册相应交易业务(例如，前述第一业务)的业务对象作为授权对象，并可以将为该授权对象所配置的公钥证书写入目标链(例如，图4所示的目标链41e)，以便于后续该业务对象在请求在第一链网络中执行该第一业务时，该第一共识节点可以进一步用跨链读取到的该目标链上的公钥证书，对链入口(即前述第一链入口)处的该业务对象的公钥证书进行证书更新处理。由此可见，本申请实施例可以基于前述跨链读取时间戳，按需更新从目标链上所同步来的授权对象的注册数据信息。
此外，应当理解，目标共识节点在将为该授权对象(例如，图4所示的用户43b)所配置的公钥证书写入目标链(例如，图4所示的目标链41e)之后，还可以将为该授权对象(例如，图4所示的用户43b)所同步配置的私钥信息(即上述第一私钥信息)返回给该用户43b，以使该用户43b在作为上述第一业务对象时，可以通过该第一私钥信息对自己所提交的交易业务数据进行签名，以得到上述第一签名信息。由此可见，这里的第一业务对象的第一私钥信息是第一业务对象(例如，图4所示的用户43b)通过目标链中的对象身份管理合约进行身份注册后得到的。基于此，这里的第一签名信息是由与该第一业务对象(例如，图4所示的用户43b)相关联的第一业务节点通过第一业务对象(例如，图4所示的用户43b)的第一私钥信息，对前述交易业务数据进行签名后所得到的。
如图4所示，该第一共识节点可以通过从链入口42a处获取到的授权对象的注册数据信息对该用户43b进行身份验证，进而可以在身份验证成功时，确定该用户43b为授权对象，以允许该用户43b作为接入者接入该第一链网络40a。应当理解，此时，第一共识节点可以在该第一链网络中，对前述交易业务数据进行交易组装，以得到与该第一业务对象相关联的第一业务，并可以将该第一业务作为一笔新的交易在该第一链网络中进行交易广播，以在该第一链网络中对这笔新的交易进行交易验重，进而可以在交易验重成功(即确定该第一链网络中不存与该笔新的交易相同的第一业务)的情况下，将这笔新的交易添加至前述实时第一业务流所对应的交易池，进而可以基于交易池中的这些实时第一业务流中的第一业务，调用图4所示的第一跨链读取合约，跨链读取目标链42e上与这些第一业务相关联的第一业务关联信息，进而可以基于跨链读取到的第一业务关联信息进一步执行下述步骤S102。
具体的，第一共识节点可以基于第一业务调用第一跨链读取合约中的权限合约读取方法，生成用于发送给目标链网络(即图4所示的目标链网络40b)中的目标共识节点(例如，共识节点42a)的权限合约访问请求；权限合约访问请求用于指示目标共识节点(例如，共识节点42a)调用目标链上的对象权限管理合约，获取与第一业务相关联的第一业务关联信息；进一步的，第一共识节点可以接收目标共识节点基于权限合约访问请求返回的第一业务关联信息，以进一步执行下述步骤S102。
步骤S102，在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；第一业务执行结果中包含第一业务所指示的业务数据；
其中，第一业务关联信息包含为第一业务对象配置的业务权限类型、具备业务权限类型的第一业务对象在业务时长内的业务累计量以及业务累计阈值；具体的，第一共识节点可以在基于第一业务关联信息确定第一业务对象的业务权限类型为开票权限类型，且具备开票权限类型的第一业务对象在业务时长内的业务累积量未达到业务累计阈值时，确定第一业务对象具备第一业务对应的第一业务处理权限；进一步的，第一共识节点可以基于第一业务处理权限获取与开票权限类型相关联的合约调用地址和合约调用名称，通过合约调用地址和合约调用名称调用第一链上的业务数据开具合约，将第一业务对应的交易业务数据和与第一业务中的业务数据开具业务相关联的票据关键信息进行整合，基于整合后的票据关键信息为第一业务对象开具电子票据，将开具的电子票据作为第一业务所指示的业务数据；进一步的，第一共识节点可以将票据关键信息、业务数据以及业务数据开具合约作为执行第一业务中的业务数据开具业务的第一业务执行结果，将包含第一业务执行结果的第一区块发送至第一链上的校验共识节点，以使校验共识节点对第一区块进行区块校验，得到区块校验结果；校验共识节点为第一链网络中除第一共识节点之外剩余的共识节点；应当理解，这里的校验共识节点(即上述票据校验共识节点)具体是指该第一链网络中除第一共识节点之外所剩余的共识节点。进一步的，第一共识节点可以接收目标共识节点返回的区块校验结果，若区块校验结果指示区块校验成功，则将第一区块写入第一链。
其中，可以理解的是，这里的票据关键信息可以包含从目标链上读取到的元数据信息中的辅助元数据信息，且辅助元数据信息包含第一业务数据模板以及与第一业务数据模板相关联的目标计税规则；第一业务数据模板为目标链上的目标共识节点调用目标链上的元数据管理合约对第二业务数据模板进行变更上链后的业务数据模板；第二业务数据模板为第一业务数据模板的上一业务数据模板；元数据变更信息是由与目标共识节点相关联的业务管理对象(这里的业务关联对象可以为上述图2所对应实施例中的税务关联部门)所提交的。
其中，应当理解，本申请实施例将不对在该第一链网络内所确定的实时业务流中的第一业务的具体业务数量和具体业务类型进行限定。为便于理解，本申请实施例以上述图4所示的用户43a所请求的第一业务的业务类型为上述票据业务内的电子票据开具业务为例，以阐述通过从目标链42e上读取到与该电子票据开具业务相关联的业务关联信息(即前述第一业务关联信息)，来进一步进行确定该用户43b的业务权限为第一业务处理权限。应当理解，这里的第一业务处理权限可以用于表征该用户43b具备调用该第一链41e上的第一业务执行合约执行该第一业务(例如，前述电子票据开具业务)的权限。
其中，可以理解的是，这里的第一业务关联信息具体包含为上述图4所示的用户43b配置的业务权限类型、具备业务权限类型的用户43b在业务时长内的业务累计量以及业务累计阈值；这里的业务权限类型是由目标共识节点通过上述对象权限管理合约为请求第一业务的图4所示的用户43b(即上述第一业务对象)所配置的。在第一业务为前述票据业务时，这里的业务权限类型具体包含开票权限类型、转移权限类型、红冲权限类型和归档权限类型。应当理解，可选地，在第一业务为前述证书业务时，这里的业务权限类型具体可以包含证书开具权限类型、转移权限类型、归档权限类型。应当理解，可选地，在第一业务为前述处方业务时，这里的业务权限类型具体可以包含处方开具权限类型、转移权限类型、归档权限类型。应当理解，在不同业务场景下，可以结合对应的业务权限类型调整该第一链上所部署的第一业务执行合约中的具体合约。
基于此，在该用户43b向目标链网络中的目标共识节点所请求注册的第一业务为电子票据开具业务时，该目标共识节点可以通过对象权限管理合约为该用户43b配置对应业务权限 的类型为上述业务权限类型(例如，配置用于调用第一链上的电子票据开具合约的开票权限类型)、以及配置具备该业务权限类型(例如，开票权限类型)的用户43b在业务时长(例如，1小时)内的业务累计量以及业务累计阈值，进而可以将为该用户43b所配置的业务权限类型(例如，开票权限类型)、具备该业务权限类型(例如，开票权限类型)的用户43b在业务时长(例如，1小时)内的业务累计量以及业务累计阈值等作为前述第一业务关联信息写入目标链(例如，图4所示的目标链42e)。
这样，在第一共识节点基于从目标链上所获取到的第一业务关联信息确定该用户43b的业务权限类型为前述开票权限类型时，可以进一步判断具备该开票权限类型的用户43b在前述业务时长内的业务累积量是否达到业务累计阈值(例如，该用户43b为开票企业时，则这里的业务累积量具体指该开票企业在1小时内的开票数量是否达到最大开票数量，且开票额度是否达到最大开票额度)，如果未达到，则可以确定前述用户43b具备第一业务对应的第一业务处理权限，进而可以基于该第一业务对应的第一业务处理权限获取与开票权限类型相关联的合约调用地址和合约调用名称，以通过合约调用地址和合约调用名称调用该第一链上的电子票据开具合约，获取与该电子票据开具业务相关联的票据关键信息，进而可以将获取到的票据关键信息进行整合，以通过整合后的票据关键信息为该用户43b开具电子票据(这里的电子票据具体可以为电子发票)。应当理解，本申请实施例可以将该开具的电子票据统称为前述第一业务所指示的业务数据。
同理，可选地，在第一共识节点基于从目标链上所获取到的第一业务关联信息确定该用户43b的业务权限类型为前述转移权限类型时，可以进一步判断具备该转移权限类型的用户43b在前述业务时长内的业务累积量是否达到业务累计阈值(例如，该用户43b为报销用户时，则这里的业务累积量具体指该报销用户在1个月内的报销额度是否达到最大报销额度)，如果未达到，则可以确定前述用户43b具备第一业务对应的第一业务处理权限，进而可以基于该第一业务对应的第一业务处理权限获取与转移权限类型相关联的合约调用地址和合约调用名称，以通过合约调用地址和合约调用名称调用该第一链上的电子票据转移合约，将为上述用户43b开具的电子票据(这里的电子票据具体可以为电子发票)转移给第二业务对象。应当理解，这里的第二业务对象可以为与该第一业务对象相关联的其他用户(例如，该用户43b所在归属地的地方税局用户)。
以此类推，可选地，在第一共识节点基于从目标链上所获取到的第一业务关联信息确定该用户43b的业务权限类型为前述红冲权限类型时，可以进一步判断具备该红冲权限类型的用户43b在前述业务时长内的业务累积量是否达到业务累计阈值(例如，该用户43b为红冲用户时，则这里的业务累积量具体指该报销用户在1个月内的红冲数量是否达到最大红冲数量)，如果未达到，则可以确定前述用户43b具备第一业务对应的第一业务处理权限，进而可以基于该第一业务对应的第一业务处理权限获取与红冲权限类型相关联的合约调用地址和合约调用名称，以通过合约调用地址和合约调用名称调用该第一链上的电子票据红冲合约，将为上述用户43b开具的电子票据(这里的电子票据具体可以为电子发票)开具用于进行红冲的红字发票。应当理解，这里的红字发票可以用于更正电子发票中的相关票据信息。
同理，可选地，在第一共识节点基于从目标链上所获取到的第一业务关联信息确定该用户43b的业务权限类型为前述归档权限类型时，可以进一步判断具备该归档权限类型的用户43b在前述业务时长内的业务累积量是否达到业务累计阈值(例如，该用户43b为归档用户时，则这里的业务累积量具体指该归档用户在1个月内的归档票据数量是否达到最大归档票据数量)，如果未达到，则可以确定前述用户43b具备第一业务对应的第一业务处理权限，进而可以基于该第一业务对应的第一业务处理权限获取与归档权限类型相关联的合约调用地址和合约调用名称，以通过合约调用地址和合约调用名称调用该第一链上的电子票据归档合约，将为上述用户43b开具的电子票据(这里的电子票据具体可以为电子发票)进行冷存储处理。应当理解，这里的第一共识节点可以调用电子票据归档合约将过期比较久(即不能再流转) 的电子票据或者被跨链请求较少的电子票据进行冷存储处理，以释放该票据链所对应的区块链账本的账本存储资源。
由此可见，这里的第一业务至少包含以下交易业务中的一种：电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务；票据业务处理合约至少包含：用于执行电子票据开具业务的电子票据开具合约、用于执行电子票据流转业务的电子票据流转合约、用于执行电子票据红冲业务的电子票据红冲合约以及用于执行电子票据归档业务的电子票据归档合约；其中，电子票据开具业务用于指示第一共识节点调用票据链上的电子票据开具合约，为第一业务对象开具电子发票；电子票据流转业务用于指示第一共识节点调用票据链上的电子票据流转合约，将电子发票由第一业务对象流转至第二业务对象；电子票据红冲业务用于指示第一共识节点调用票据链上的电子票据红冲合约，开具电子发票对应的红字发票，且红字发票用于更正电子发票中的相关票据信息；电子票据归档业务用于指示第一共识节点调用票据链上的电子票据归档合约，将票据链上满足票据归档条件的电子发票进行冷存储处理。
应当理解，可选地，在上述区块链系统应用于区块链电子处方场景下，当第一业务为与电子处方相关的处方业务(例如，在用户43b请求在该第一链网络中获取相应的电子处方等)时，上述实时业务流具体可以为实时电子处方流，即该实时电子处方流具体可以是指由第一共识节点通过前述第一链入口(比如，链入口42a)所确定的处于高频请求状态的大量处方业务所构成的处方业务流，此时，该第一链入口所对应的第一链网络具体可以为处方链网络。又比如，可选地，在上述区块链系统应用于区块链电子证书场景下，当第一业务为与电子证书相关的证书业务(例如，例如，用户43b请求在该第一链网络中获取相应的电子证书，这里的电子证书具体可以为电子技能证书等)时，这里的实时业务流具体可以为实时电子证书流，即该实时电子证书流具体可以是指由第一共识节点通过前述第一链入口(比如，链入口42a)所确定的处于高频请求状态的大量证书业务所构成的证书业务流，此时，该第一链入口所对应的第一链网络具体可以为证书链网络。其中，应当理解，在第一链网络中执行处方业务、证书业务的具体实现方式，可以参见上述对在该第一链网络中执行票据业务的具体过程的描述，这里将不再继续进行赘述。
可选地，第一共识节点在将第一业务执行结果写入第一链时，还可以在第一业务执行结果对应的目标交易中指定与业务数据相关联的业务数据处理终端的处理终端标识；处理终端标识用于表征业务数据处理终端具备从第一链上清分到业务数据的功能；其中，应当理解，这里的业务数据处理终端可以为上述图2所对应实施例中的电子票据数据中心所对应的终端。这样，该第一共识节点在获取到业务数据处理终端发送的交易清分请求时，可以基于交易清分请求中携带的处理终端标识从第一链上获取目标交易，且从目标交易所包含的第一业务执行结果中清分到业务数据，将业务数据返回给业务数据处理终端，以使业务数据处理终端对业务数据进行数据分析(例如，进行票据分析)。这里的票据分析具体是指上述电子票据数据中心可以通过业务数据处理终端对第一链上所记录的大量的电子票据进行链下统计(例如，统计上述作为开票企业的用户43a的分时开票数量)、数据分析(例如，分析上述作为开票企业的用户43a的开票额度、开票数量，以对该用户43a进行风险判定，比如，在确定该用户43a属于风险企业时，通知上述税务管理部门调用第一链上的对象权限管理合约冻结该用户43a的开票资质，或者限制该用户43a的开票额度)以及税务审查(审查上述用户43a的缴税情况)等。
步骤S103，在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；第二共识节点用于在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链；第二链为第二共识节点所在的第二链网络中的区块链，第二链网络独立于第一链网络和目标链网络。
具体的，第一共识节点在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，从跨链读取请求中获取第二业务对象通过与第二链相关联的第二业务入口提交的第二业务；其中，第二业务入口用于在确定第二业务对象具备在第二链上处理第二业务的权限时，允许第二业务对象通过第二共识节点调用第二跨链读取合约；进一步的，第一共识节点可以基于第二业务所指示的跨链请求数据信息，从第一链上读取业务数据，将读取到的业务数据中的核心数据作为跨链读取请求对应的跨链请求响应信息，将跨链请求响应信息返回给第二共识节点，以使第二共识节点基于跨链请求响应信息调用第二链上的第二业务合约执行第二业务。应当理解，在本申请实施例中，若第二业务为第一业务的衍生业务，则该跨链请求数据信息具体可以为该衍生业务的衍生业务数据信息。
为便于理解，本申请实施例结合上述图4所示的第一链网络40a和目标链网络40b，阐述在区块链系统中如何实现三链之间的相互协作。进一步的，请参见图5，图5是本申请实施例通过的一种在三链之间进行跨链交互的场景示意图。如图5所示的用户53a可以为请求执行第二业务的第二业务对象，该用户53a所使用的用户终端53a可以为第二业务节点。这里的第二业务节点可以与上述第一业务节点相同，也可以与上述第一业务节点不同，这里将不对其进行限定。此外，图5所示的链入口52a为第二链入口，这里的第二链入口可以为上述图2所对应实施例中的税务衍生业务入口。应当理解，在本申请实施例中，税务衍生对象(例如，图5所示的用户53b)可以在获得税务管理部门通过上述管理共识节点发放的业务参与许可凭证后，通过该业务参与许可凭证接入图5所示的第二链网络500a。
其中，如图5所示的链入口52a处存储有从目标链42e上所同步来的授权对象的业务参与许可凭证。具体的，如图5所示，该授权对象的业务参与许可凭证可以包含授权对象A的许可凭证A2、授权对象B的许可凭证B2、…、授权对象N的许可凭证N2。这样，当图5所示的用户53b基于前述税务管理部门通过上述目标共识节点所配置的目标业务参与许可凭证的情况下，可以将该目标业务参与许可凭证添加至图5所示的第二业务处理请求，以将该第二业务处理请求发送给第二共识节点(例如，图5所示的共识节点51d)，以使该第二共识节点可以通过链入口52a处所存储的授权对象的业务参与许可凭证判断该用户53b是否可以接入该第二链网络500a。比如，若该第二共识节点在该链入口52a处查找到与前述目标业务参与许可凭证相同的业务参与许可凭证，则允许该用户53b接入该第二链网络500a，反之，则可以拒绝该用户53b(即前述第二业务对象)发送的第二业务处理请求。
其中，可以理解的是，这里的业务参与许可凭证(简称为许可凭证)可以包含但不限于为该用户53b(即前述第二业务对象)配置的公钥证书的哈希值和为该用户53b(即前述第二业务对象)配置的访问令牌或者身份证书等，这里将不对管理共识节点为该用户53b所配置的许可凭证中的具体内容等进行限定。
如图5所示，该第二链网络中包含多个共识节点，这些共识节点具体可以包含共识节点51a、共识节点51b、共识节点51c和共识节点51d。应当理解，这里的这些共识节点上均运行有上述第二跨链读取合约。为便于理解，这里以共识节点51d作为第二共识节点，且该第二共识节点上运行有第二跨链读取合约为例，以阐述第二共识节点调用第二跨链读取合约从第一链网络40a所对应的第一链41e上读取与该第二业务相关联的业务数据中的核心数据。比如，这里的第二业务可以为上述资质识别业务。应当理解，该第一链41e是由第一链网络40a中这些共识节点(比如，图5所示的共识节点41a、共识节点41b、共识节点41c和共识节点41d)所共同维护的。
结合上述图4所描述的实施例可知，第一共识节点会将执行上述第一业务所得到的业务数据写入该目标链41e。这样，在第二共识节点(例如，图5所示的共识节点51d)在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，可以调用第二跨链读取合约生成与第二业务相关联的跨链读取请求，以将该跨链读取请求发送给第一共识节点(例如，图5所示的共识节点41d)。
此时，第一共识节点(例如，图5所示的共识节点41d)可以根据接收到的跨链读取请求从该第一链网络40a对应的第一链41e上读取与该第二业务(例如，资质识别业务)相关联的业务数据，进而可以将读取到的业务数据中的核心数据返回给第二共识节点(例如，图5所示的共识节点51d)。应当理解，本申请实施例并不对跨链读取到的业务数据的数量进行限定。
比如，在该第一业务为票据业务的情况下，该第一共识节点从第一链41e上所读取到与该第二业务相关联业务数据，具体可以指在第一链网络中执行该票据业务中电子票据开具业务后所得到的一张或者多张电子票据，进而可以将读取到的这些电子票据中的核心数据返回给第二共识节点，以在图5所示的第二链网络中执行该用户53b所请求的第二业务(例如，可以通过批量性获取到的电子票据中的核心数据，对请求开具这些电子票据的开票企业的企业资质进行识别)。
换言之，该第二共识节点可以在跨链读取到的前述业务数据中的核心数据时，进一步基于这些核心数据执行第二业务，并可以将第二业务对应的第二业务执行结果写入第二链(比如图5中的第二链51e)。
其中，应当理解，该第二共识节点调用第二跨链读取合约从目标链42e上读取与第二业务相关联的第二业务关联信息的具体实现方式，可以参见上述对第一共识节点调用第一跨链读取合约从目标链42e上读取与第一业务相关联的第一业务关联信息具体过程的描述，这里将不再继续进行赘述。
由此可见，本申请实施例提供了一种全新的多区块链协作机制，该多区块链协作机制旨在强调可以在第一链、目标链和第二链这三链之间进行互相协作，以确保第一链网络中的共识节点(即前述第一共识节点)可以用于独立处理一些具有较大请求数据量的实时业务流(即前述第一业务)。这样，在区块链电子票据的核心数据(即第一链上部分授权可见的票据信息)流转的业务场景下，第一共识节点(例如，上述票据共识节点)可以参与维护该第一链网络中的第一链，且该第一链主要用于存储上述第一业务执行结果，比如，该第一链可以用于存储执行实时业务流中各第一业务所分别得到的业务数据，此外，第二共识节点(例如，上述应用共识节点)可以参与维护该第二链网络中的第二链，且该第二链主要用于存储第二业务执行结果，需要注意的是，这里的第二业务执行结果是基于从前述第一链上跨链流转至该第二链的业务数据中的核心数据(即业务数据中部分授权可见的数据)而开展的第二业务所确定的；再者，需要注意的是，这里的目标共识节点(例如，上述图2所对应实施例中的管理共识节点)可以用于对接入第二链网络和第一链网络中的业务对象的权限进行集中管理。显然，通过部署的多区块链来分别进行数据存储，可以有效地降低各区块链上数据存储的混杂度，另外，通过多区块链之间的相互协作，还可以提升各链上所存储数据的安全性。
进一步的，请参见图6，图6是本申请实施例提供的一种多区块链数据处理方法，如图6所示，方法可以由上述第二链网络中的第二共识节点执行，比如，该第二共识节点可以为上述图1所示的共识网络300a中任意一个共识节点。方法具体可以包括以下步骤S201-步骤S203。
步骤S201，获取第二业务对象请求的第二业务，基于第二业务调用第二链上的第二跨链读取合约，从目标链上读取与第二业务相关联的第二业务关联信息；第二链为第二链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第二链网络，第二链不同于目标链；
步骤S202，在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成与第二业务相关联的跨链读取请求，将跨链读取请求发送给第一链网络中的第一共识节点；跨链读取请求用于指示第一共识节点从第一链网络对应的第一链上读取与第二业务相关联的业务数据；第一链网络独立于第二链网络和目标链网络；业务数据是由第一共识节点在基于第一业务关联信息确定出第一业务对象具备第一业务 对应的第一业务处理权限时，调用第一链上的第一业务处理合约所确定的；第一业务关联信息是由第一共识节点基于第一业务调用第一链上的第一跨链读取合约从目标链上读取到的；
步骤S203，接收第一共识节点基于跨链读取请求返回的业务数据中的核心数据，基于核心数据执行第二业务，并将第二业务对应的第二业务执行结果写入第二链。
其中，可以理解的是，步骤S201-步骤S203的具体实现方式，可以参见上述图3所对应实施例中对第二共识节点的描述，这里将不再继续进行赘述。
由此可见，本申请实施例提供了一种全新的多区块链协作机制，该多区块链协作机制旨在强调可以在第一链、目标链和第二链这三链之间进行互相协作，以确保第一链网络中的共识节点(即前述第一共识节点)可以用于独立处理一些具有较大请求数据量的实时业务流(比如，前述票据业务所构成的票据业务流、前述处方业务所构成的处方业务流、前述证书业务所构成的证书业务流等)。这样，在区块链上的核心数据(即第一链上所存储的业务数据中部分授权可见的核心数据)流转的业务场景下，第一共识节点可以参与维护该第一链网络中的第一链，且该第一链主要用于存储执行前述第一业务后所得到的实时业务数据流中的业务数据，此外，第二共识节点可以参与维护该第二链网络中的第二链，且该第二链主要用于存储第二业务执行结果，需要注意的是，这里的第二业务执行结果是基于从前述第一链上跨链流转至该第二链的业务数据中的核心数据(即核心数据)而开展的第二业务所确定的；再者，需要注意的是，这里的目标共识节点可以用于对接入第二链网络和第一链网络中的业务对象的权限进行集中管理。显然，通过部署的多区块链来分别进行数据存储，可以有效地降低各区块链上数据存储的混杂度，另外，通过多区块链之间的相互协作，还可以提升各链上所存储数据的安全性。
进一步的，请参见图7，图7是本申请实施例提供的一种多区块链数据处理方法，如图7所示，方法可以由上述目标链网络中的目标共识节点执行，比如，该目标共识节点可以为上述图1所示的共识网络100a中任意一个共识节点。方法具体可以包括以下步骤S301-步骤S304。
步骤S301，接收第一链网络中的第一共识节点发送的第一业务权限查询请求；第一业务权限查询请求是第一共识节点在获取到第一业务对象提交的第一业务时，调用第一链上的第一跨链读取合约所确定的；第一链为第一链网络中的区块链；第一链网络独立于目标链网络；
步骤S302，基于第一业务查询请求从目标链网络对应的目标链上，读取与第一业务相关联的第一业务关联信息，将第一业务关联信息返回给第一共识节点，以使第一共识节点在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到用于写入第一链的第一业务执行结果；第一业务执行结果中包含第一业务所指示的业务数据；
步骤S303，接收第二链网络中的第二共识节点发送的第二业务权限查询请求；第二业务权限查询请求是第二共识节点在获取到第二业务对象提交的第二业务时，调用第二链网络对应的第二链上的第二跨链读取合约所确定的；第二链网络独立于第一链网络和目标链网络；
步骤S304，基于第二业务查询请求从目标链上，读取与第二业务相关联的第二业务关联信息，将第二业务关联信息返回给第二共识节点，以使第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成用于发送给第一共识节点的与第二业务相关联的跨链读取请求；跨链读取请求用于指示第一共识节点从第一链上读取业务数据。
其中，可以理解的是，步骤S301-步骤S304的具体实现方式，可以参见上述图3所对应实施例中对目标共识节点的描述，这里将不再继续进行赘述。
由此可见，本申请实施例提供了一种全新的多区块链协作机制，该多区块链协作机制旨在强调可以在第一链、目标链和第二链这三链之间进行互相协作，以确保第一链网络中的共识节点(即前述第一共识节点)可以用于独立处理一些具有较大请求数据量的实时业务流(即 前述第一业务)。这样，在区块链的核心数据(即第一链上部分授权可见的核心数据)流转的业务场景下，第一共识节点可以参与维护该第一链网络中的第一链，且该第一链主要用于存储实时处理第一业务流后所得到的业务数据，此外，第二共识节点可以参与维护该第二链网络中的第二链，且该第二链主要用于存储第二业务执行结果，需要注意的是，这里的第二业务执行结果是基于从前述第一链上跨链流转至该第二链的业务数据中的核心数据而开展的第二业务所确定的；再者，需要注意的是，这里的目标共识节点可以用于对接入第二链网络和第一链网络中的业务对象的权限进行集中管理。显然，通过部署的多区块链来分别进行数据存储，可以有效地降低各区块链上数据存储的混杂度，另外，通过多区块链之间的相互协作，还可以提升各链上所存储数据的安全性。
进一步的，请参见图8，图8是本申请实施例提供的一种多区块链数据处理方法，如图8所示，方法可以由上述第一链网络中的第一共识节点、第二链网络中的第二共识节点、目标链网络中的目标共识节点共同执行。比如，这里的第一共识节点可以为上述图1所示的共识网络200a中任意一个共识节点，第二共识节点可以为上述图1所示的共识网络300a中任意一个共识节点，目标共识节点可以为上述图1所示的共识网络100a中任意一个共识节点。应当理解，这里的第一链网络独立于目标链网络，且独立于第二链网络；此时，该方法具体可以包括以下步骤S401-步骤S410。
步骤S401，第一共识节点用于获取第一业务对象请求的第一业务，基于第一业务调用第一链上的第一跨链读取合约，生成第一业务权限查询请求；
步骤S402，第一共识节点将第一业务权限查询请求发送给目标共识节点；
步骤S403，目标共识节点用于在获取到第一共识节点发送的第一业务权限查询请求时，从目标链网络对应的目标链上读取与第一业务相关联的第一业务关联信息，将第一业务关联信息返回给第一共识节点；
步骤S404，第一共识节点在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；
其中，第一业务执行结果中包含第一业务所指示的业务数据。
步骤S405，目标共识节点接收第二链网络中的第二共识节点发送的第二业务权限查询请求；
其中，第二业务权限查询请求是第二共识节点在获取到第二业务对象提交的第二业务时，调用第二链网络对应的第二链上的第二跨链读取合约所确定的；第二链网络独立于第一链网络和目标链网络；
步骤S406，目标共识节点基于第二业务查询请求从目标链上，读取与第二业务相关联的第二业务关联信息，将第二业务关联信息返回给第二共识节点；
步骤S407，第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成用于发送给第一共识节点的与第二业务相关联的跨链读取请求；
其中，跨链读取请求用于指示第一共识节点从第一链上读取业务数据。
步骤S408，第二共识节点将跨链读取请求发送给第一共识节点；
应当理解，在步骤S408中所涉及的跨链读取请求是第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约所生成的；第二业务关联信息时第二共识节点基于第二业务调用第二跨链读取合约从目标链上读取到的。
步骤S409，第一共识节点在获取到第二共识节点发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；
步骤S410，第二共识节点在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链。
由此可见，本申请实施例提供了一种全新的多区块链协作机制，该多区块链协作机制旨在强调可以在第一链、目标链和第二链这三链之间进行互相协作，以确保第一链网络中的共识节点(即前述第一共识节点)可以用于独立处理一些具有较大请求数据量的实时业务流(即前述第一业务)。这样，在区块链的核心数据(即第一链上部分授权可见的核心数据)流转的业务场景下，第一共识节点可以参与维护该第一链网络中的第一链，且该第一链主要用于存储执行前述实时业务流后所得到的业务数据，此外，第二共识节点可以参与维护该第二链网络中的第二链，且该第二链主要用于存储第二业务执行结果，需要注意的是，这里的第二业务执行结果是基于从前述第一链上跨链流转至该第二链的业务数据中的核心数据而开展的第二业务所确定的；再者，需要注意的是，这里的目标共识节点可以用于对接入第二链网络和第一链网络中的业务对象的权限进行集中管理。显然，通过部署的多区块链来分别进行数据存储，可以有效地降低各区块链上数据存储的混杂度，另外，通过多区块链之间的相互协作，还可以提升各链上所存储数据的安全性。
进一步的，请参见图9，图9是本申请提供的一种多区块链数据处理装置的结构示意图。如图9所示，多区块链数据处理装置1可应用于第一共识节点中，该第一共识节点可以为第一链网络(例如，上述共识网络200a)中任意一个区块链节点，例如，该第一共识节点可以为上述图1所对应实施例中的共识节点11c。应当理解，该多区块链数据处理装置1可以是运行于区块链节点(比如，前述共识节点10c)中的一个计算机程序(包括程序代码)，例如该多区块链数据处理装置1可以为一个应用软件；可以理解的是，该多区块链数据处理装置1可以用于执行本申请实施例提供的方法中的相应步骤。如图9所示，多区块链数据处理装置1可以包括：第一业务获取模块11、第一业务执行模块12和业务数据读取模块13；
第一业务获取模块11，用于获取第一业务对象请求的第一业务，基于第一业务调用第一链上的第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息；第一链为第一链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第一链网络，第一链不同于目标链；
第一业务执行模块12，用于在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到与第一业务相关联的第一业务执行结果，且将第一业务执行结果写入第一链；第一业务执行结果中包含第一业务所指示的业务数据；
业务数据读取模块13，用于在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于跨链读取请求中携带的第二业务从第一链上读取业务数据，且将业务数据中的核心数据返回给第二共识节点；第二共识节点用于在基于核心数据执行第二业务之后，将第二业务对应的第二业务执行结果写入第二链；第二链为第二共识节点所在的第二链网络中的区块链，第二链网络独立于第一链网络和目标链网络。
其中，与第一链网络对应的链入口为第一链入口；第一链入口存储有第一共识节点在第一跨链读取时间戳时通过第一跨链读取合约从目标链上所同步来的授权对象的注册数据信息；
第一业务获取模块11包括：第一业务请求单元111、签名验证单元112、第一业务确定单元113和跨链读取单元114；
第一业务请求单111，用于通过第一链网络的第一链入口，获取第一业务对象对应的第一业务节点基于第一业务发送的第一业务处理请求；第一业务处理请求中携带第一业务对象针对第一业务提交的交易业务数据、以及第一业务对象的第一签名信息；第一签名信息是由与第一业务对象相关联的第一业务节点通过第一业务对象的第一私钥信息，对交易业务数据进行签名后所得到的；第一业务对象的第一私钥信息是第一业务对象通过目标链中的对象身份管理合约进行身份注册后得到的；
签名验证单元112，用于从第一业务处理请求中获取第一签名信息，基于第一链入口中存储的授权对象的注册数据信息对第一签名信息进行签名验证，得到第一业务对象的签名验证结果；
第一业务确定单元113，用于在第一业务对象的签名验证结果指示签名验证成功时，确定第一业务对象为授权对象，且基于交易业务数据确定与第一业务对象相关联的第一业务；
跨链读取单元114，用于基于第一业务调用第一跨链读取合约，从目标链上读取与第一业务相关联的第一业务关联信息。
其中，授权对象的注册数据信息中包含授权对象的公钥证书；授权对象的公钥证书是由目标链网络中的目标共识节点调用目标链中的对象身份管理合约，对授权对象提交的对象数据信息进行身份注册后所得到的；
其中，第一业务请求单元111、签名验证单元112、第一业务确定单元113和跨链读取单元114的具体实现方式，可以参见上述图3所对应实施例中对步骤S101的描述，这里将不再继续进行赘述。
签名验证单元112包括：证书获取子单元1121，证书查找子单元1122和签名验证子单元1123；
证书获取子单元1121，用于从第一业务处理请求中获取第一签名信息，从第一链入口中存储的授权对象的注册数据信息中获取授权对象的公钥证书；一个授权对象的公钥证书中包含一个授权对象的公钥信息；
证书查找子单元1122，用于在授权对象的公钥证书中查找第一业务对象的公钥证书，且在查找到第一业务对象的公钥证书时，将查找到的第一业务对象的公钥证书作为第一公钥证书，且将第一公钥证书中的公钥信息作为第一业务对象的第一公钥信息；
签名验证子单元1123，用于基于第一公钥证书以及第一公钥信息对第一签名信息进行签名验证，得到第一业务对象的签名验证结果。
其中，签名验证子单元1123，具体用于将第一公钥证书的证书数据信息作为待处理证书信息，且在第二跨链读取时间戳时调用第一跨链读取合约中的证书数据读取方法，从目标链上读取第一业务对象的公钥证书；第二跨链读取时间戳为第一跨链读取时间戳的下一跨链读取时间戳；
签名验证子单元1123，还具体用于将读取到的第一业务对象的公钥证书中的证书数据信息作为目标证书信息；
签名验证子单元1123，还具体用于在待处理证书信息与目标证书信息保持一致时，基于第一公钥信息对第一签名信息进行签名验证，并将签名验证成功时的验证结果作为第一业务对象的签名验证结果。
其中，证书获取子单元1121，证书查找子单元1122和签名验证子单元1123的具体实现方式，可以参见上述图3所对应实施例中对签名验证的具体过程的描述，这里将不再继续进行赘述。
其中，签名验证单元112还包括：请求拒绝子单元1124；
请求拒绝子单元1124，用于在授权对象的公钥证书中未查找到第一业务对象的公钥证书时，将第一业务对象确定为非法业务对象，拒绝非法业务对象发送的第一业务处理请求。
其中，请求拒绝子单元1124的具体实现方式，可以参见上述图3所对应实施例中对对签名验证的具体过程的描述，这里将不再继续进行赘述。
其中，跨链读取单元114包括：访问请求生成子单元1141和关联信息返回子单元1142；
访问请求生成子单元1141，用于基于第一业务调用第一跨链读取合约中的权限合约读取方法，生成用于发送给目标链网络中的目标共识节点的权限合约访问请求；权限合约访问请求用于指示目标共识节点调用目标链上的对象权限管理合约，获取与第一业务相关联的第一业务关联信息；
关联信息返回子单元1142，用于接收目标共识节点基于权限合约访问请求返回的第一业务关联信息。
其中，访问请求生成子单元1141和关联信息返回子单元1142的具体实现方式，可以参见上述图3所对应实施例中对通过第一跨链读取合约跨链读取第一业务关联信息的具体过程的描述，这里将不再继续进行赘述。
其中，第一业务关联信息包含为第一业务对象配置的业务权限类型、具备业务权限类型的第一业务对象在业务时长内的业务累计量以及业务累计阈值；
第一业务执行模块12包括：处理权限确定单元121，票据合约调用单元122，区块校验单元123和校验结果接收单元124；
处理权限确定单元121，用于在基于第一业务关联信息确定第一业务对象的业务权限类型为开票权限类型，且具备开票权限类型的第一业务对象在业务时长内的业务累积量未达到业务累计阈值时，确定第一业务对象具备第一业务对应的第一业务处理权限；
票据合约调用单元122，用于基于第一业务处理权限获取与开票权限类型相关联的合约调用地址和合约调用名称，通过合约调用地址和合约调用名称调用第一链上的电子票据开具合约，将第一业务对应的交易业务数据和与第一业务中的电子票据开具业务相关联的票据关键信息进行整合，基于整合后的票据关键信息为第一业务对象开具电子票据，将开具的电子票据作为第一业务所指示的业务数据；
区块校验单元123，用于将票据关键信息、业务数据以及电子票据开具合约作为执行第一业务中的电子票据开具业务的第一业务执行结果，将包含第一业务执行结果的第一区块发送至第一链上的校验共识节点，以使校验共识节点对第一区块进行区块校验，得到区块校验结果；校验共识节点为第一链网络中除第一共识节点之外剩余的共识节点；
校验结果接收单元124，用于接收校验共识节点返回的区块校验结果，若区块校验结果指示区块校验成功，则将第一区块写入第一链。
其中，处理权限确定单元121，票据合约调用单元122，区块校验单元123和校验结果接收单元124的具体实现方式，可以参见上述图3所对应实施例中对步骤S102的描述，这里将不再继续进行赘述。
其中，票据关键信息包含从目标链上读取到的辅助元数据信息，且辅助元数据信息包含第一电子票据模板以及与第一电子票据模板相关联的目标计税规则；第一电子票据模板为目标链上的目标共识节点调用目标链上的元数据管理合约对第二电子票据模板进行变更上链后的电子票据模板；第二电子票据模板为第一电子票据模板的上一电子票据模板；元数据变更信息是由与目标共识节点相关联的业务管理对象所提交的。
其中，第一业务至少包含以下交易业务中的一种：电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务；第一业务处理合约至少包含：用于执行电子票据开具业务的电子票据开具合约、用于执行电子票据流转业务的电子票据流转合约、用于执行电子票据红冲业务的电子票据红冲合约以及用于执行电子票据归档业务的电子票据归档合约；
其中，电子票据开具业务用于指示第一共识节点调用第一链上的电子票据开具合约，为第一业务对象开具电子发票；电子票据流转业务用于指示第一共识节点调用第一链上的电子票据流转合约，将电子发票由第一业务对象流转至第二业务对象；电子票据红冲业务用于指示第一共识节点调用第一链上的电子票据红冲合约，开具电子发票对应的红字发票，且红字发票用于更正电子发票中的相关票据信息；电子票据归档业务用于指示第一共识节点调用第一链上的电子票据归档合约，将第一链上满足票据归档条件的电子发票进行冷存储处理。
其中，业务数据读取模块13包括：票据读取请求发送单元131和票据读取响应单元132；
票据读取请求发送单元131，用于在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，从跨链读取请求中获取第二业务对象通过与第二链相关联的第 二业务入口提交的第二业务；第二业务入口用于在确定第二业务对象具备在第二链上处理第二业务的权限时，允许第二业务对象通过第二共识节点调用第二跨链读取合约；
票据读取响应单元132，用于基于第二业务所指示的跨链请求数据信息，从第一链上读取业务数据，将读取到的业务数据中的核心数据作为跨链读取请求对应的跨链请求响应信息，将跨链请求响应信息返回给第二共识节点，以使第二共识节点基于跨链请求响应信息调用第二链上的第二业务合约执行第二业务。
其中，票据读取请求发送单元131和票据读取响应单元132的具体实现方式，可以参见上述图3所对应时候了中对步骤S103的描述，这里将不再继续进行赘述。
其中，第一业务执行模块12，还用于在将第一业务执行结果写入第一链时，在第一业务执行结果对应的目标交易中指定与业务数据相关联的业务数据处理终端的处理终端标识；处理终端标识用于表征业务数据处理终端具备从第一链上清分到业务数据的功能；
第一业务执行模块12，还用于在获取到业务数据处理终端发送的交易清分请求时，基于交易清分请求中携带的处理终端标识从第一链上获取目标交易，且从目标交易所包含的第一业务执行结果中清分到业务数据，将业务数据返回给业务数据处理终端，以使业务数据处理终端对业务数据进行数据分析。
其中，第一业务获取模块11、第一业务执行模块12和业务数据读取模块13的具体实现方式，可以参见上述图3所对应实施例中对步骤S101-步骤S103的描述，这里将不再继续进行赘述。应当理解，对采用相同方法所得到的有益效果描述，也不再进行赘述。
进一步的，请参见图10，图10是本申请提供的一种多区块链数据处理装置的结构示意图。如图10所示，多区块链数据处理装置2可应用于第二共识节点中，该第二共识节点可以为第二链网络(例如，上述共识网络300a)中任意一个区块链节点，例如，该第二共识节点可以为上述图1所对应实施例中的共识节点12c。应当理解，该多区块链数据处理装置2可以是运行于区块链节点(比如，前述共识节点12c)中的一个计算机程序(包括程序代码)，例如该多区块链数据处理装置2可以为一个应用软件；可以理解的是，该多区块链数据处理装置2可以用于执行本申请实施例提供的方法中的相应步骤。如图8所示，多区块链数据处理装置2可以包括：第二业务获取模块21，跨链读取请求发送模块22和第二业务执行模块23；
第二业务获取模块21，用于获取第二业务对象请求的第二业务，基于第二业务调用第二链上的第二跨链读取合约，从目标链上读取与第二业务相关联的第二业务关联信息；第二链为第二链网络中的区块链；目标链是目标链网络中的区块链；目标链网络独立于第二链网络，第二链不同于目标链；
跨链读取请求发送模块22，用于在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成与第二业务相关联的跨链读取请求，将跨链读取请求发送给第一链网络中的第一共识节点；跨链读取请求用于指示第一共识节点从第一链网络对应的第一链上读取与第二业务相关联的业务数据；第一链网络独立于第二链网络和目标链网络；业务数据是由第一共识节点在基于第一业务关联信息确定出第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约所确定的；第一业务关联信息是由第一共识节点基于第一业务调用第一链上的第一跨链读取合约从目标链上读取到的；
第二业务执行模块23，用于接收第一共识节点基于跨链读取请求返回的业务数据中的核心数据，基于核心数据执行第二业务，并将第二业务对应的第二业务执行结果写入第二链。
其中，第二业务获取模块21，跨链读取请求发送模块22和第二业务执行模块23的具体实现方式，可以参见上述图4所实施例中对步骤S201-步骤S203的描述，这里将不再继续进行赘述。另外，对采用相同方法所得到的有益效果描述，也不再进行赘述。
进一步的，请参见图11，图11是本申请提供的一种多区块链数据处理装置的结构示意 图。如图11所示，多区块链数据处理装置3可应用于目标共识节点中，该目标共识节点可以为目标链网络(例如，上述共识网络100a)中任意一个区块链节点，例如，该目标共识节点可以为上述图1所对应实施例中的共识节点10c。应当理解，该多区块链数据处理装置3可以是运行于区块链节点(比如，前述共识节点10c)中的一个计算机程序(包括程序代码)，例如该多区块链数据处理装置3可以为一个应用软件；可以理解的是，该多区块链数据处理装置3可以用于执行本申请实施例提供的方法中的相应步骤。如图9所示，多区块链数据处理装置3可以包括：第一查询请求接收模块31，第一关联信息返回模块32，第二查询请求接收模块33和第二关联信息返回模块34；
第一查询请求接收模块31，用于接收第一链网络中的第一共识节点发送的第一业务权限查询请求；第一业务权限查询请求是第一共识节点在获取到第一业务对象提交的第一业务时，调用第一链上的第一跨链读取合约所确定的；第一链为第一链网络中的区块链；第一链网络独立于目标链网络；
第一关联信息返回模块32，用于基于第一业务查询请求从目标链网络对应的目标链上，读取与第一业务相关联的第一业务关联信息，将第一业务关联信息返回给第一共识节点，以使第一共识节点在基于第一业务关联信息确定第一业务对象具备第一业务对应的第一业务处理权限时，调用第一链上的第一业务处理合约执行第一业务，得到用于写入第一链的第一业务执行结果；第一业务执行结果中包含第一业务所指示的业务数据；
第二查询请求接收模块33，用于接收第二链网络中的第二共识节点发送的第二业务权限查询请求；第二业务权限查询请求是第二共识节点在获取到第二业务对象提交的第二业务时，调用第二链网络对应的第二链上的第二跨链读取合约所确定的；第二链网络独立于第一链网络和目标链网络；
第二关联信息返回模块34，用于基于第二业务查询请求从目标链上，读取与第二业务相关联的第二业务关联信息，将第二业务关联信息返回给第二共识节点，以使第二共识节点在基于第二业务关联信息确定第二业务对象具备第二业务对应的第二业务处理权限时，调用第二跨链读取合约生成用于发送给第一共识节点的与第二业务相关联的跨链读取请求；跨链读取请求用于指示第一共识节点从第一链上读取业务数据。
其中，第一查询请求接收模块31，第一关联信息返回模块32，第二查询请求接收模块33和第二关联信息返回模块34的具体实现方式，可以参见上述图5所对应实施例中对步骤S301-步骤S304的描述，这里将不再继续进行赘述。另外，对于采用相同方法所得到的相同有益效果的描述，也不再进行赘述。
进一步地，请参见图12，图12是本申请实施例提供的一种计算机设备的结构示意图。如图12所示，该计算机设备1000可以为用户终端，还可以为服务器，这里将不对其进行限制。为便于理解，本申请以计算机设备为服务器为例，该计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，该计算机设备1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图12所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
其中，该计算机设备1000中的网络接口1004还可以提供网络通讯功能。在图12所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以执行上述图3、图6、图7或者图8所对应实施例中对多区块链数据方法的描述，还可以执行 前文图9、图10或者图11所对应实施例中对多区块链数据处理装置(即上述多区块链数据处理装置1、多区块链数据处理装置2或者多区块链数据处理装置3)的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有前文提及的多区块链数据处理装置1、多区块链数据处理装置2或者多区块链数据处理装置3所执行的计算机程序，且计算机程序包括计算机指令，当处理器执行计算机指令时，能够执行前文图3、图6、图7或者图8所对应实施例中对多区块链数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，计算机指令可被部署在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行，分布在多个地点且通过通信网络互连的多个计算设备可以组成区块链系统。
此外，需要说明的是：本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该计算机设备执行前文图3、图6、图7或者图8所对应实施例中对多区块链数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品或者计算机程序实施例中未披露的技术细节，请参照本申请方法实施例的描述。
进一步的，请参见图13，图13是本申请实施例提供的一种多区块链数据处理系统的示意图。该多区块链数据处理系统4可以包含共识节点4a、共识节点4b和共识节点4c；其中，共识节点4a可以为上述图7所对应实施例所描述的处于目标链网络中的目标共识节点，该目标共识节点可以为上述图1所示的共识网络100a中的任意一个区块链节点，这里将不再继续进行赘述。其中，共识节点4b可以为上述图3所对应实施例所描述的处于第一链网络中的第一共识节点，该第一共识节点可以为上述图1所示的共识网络200a中的任意一个区块链节点，这里将不再继续进行赘述。其中，共识节点4c可以为上述图6所对应实施例所描述的处于第二链网络中的第二共识节点，该第二共识节点可以为上述图1所示的共识网络300a中的任意一个区块链节点，这里将不再继续进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

Claims (20)

  1. 一种多区块链数据处理方法，所述方法由第一链网络中的第一共识节点执行，所述方法包括：
    获取第一业务对象请求的第一业务，基于所述第一业务调用第一链上的第一跨链读取合约，从目标链上读取与所述第一业务相关联的第一业务关联信息；所述第一链为所述第一链网络中的区块链；所述目标链是目标链网络中的区块链；所述目标链网络独立于所述第一链网络，所述第一链不同于所述目标链；
    在基于所述第一业务关联信息确定所述第一业务对象具备所述第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约执行所述第一业务，得到与所述第一业务相关联的第一业务执行结果，且将所述第一业务执行结果写入所述第一链；所述第一业务执行结果中包含所述第一业务所指示的业务数据；
    在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于所述跨链读取请求中携带的第二业务从所述第一链上读取所述业务数据，且将所述业务数据中的核心数据返回给所述第二共识节点；所述第二共识节点用于在基于所述核心数据执行所述第二业务之后，将所述第二业务对应的第二业务执行结果写入所述第二链；所述第二链为所述第二共识节点所在的第二链网络中的区块链，所述第二链网络独立于所述第一链网络和所述目标链网络。
  2. 根据权利要求1所述的方法，与所述第一链网络对应的链入口为第一链入口；所述第一链入口存储有所述第一共识节点在第一跨链读取时间戳时通过所述第一跨链读取合约从所述目标链上所同步来的授权对象的注册数据信息；
    所述获取第一业务对象请求的第一业务，基于所述第一业务调用第一链上的第一跨链读取合约，从目标链上读取与所述第一业务相关联的第一业务关联信息，包括：
    通过所述第一链网络的第一链入口，获取第一业务对象对应的第一业务节点基于第一业务发送的第一业务处理请求；所述第一业务处理请求中携带所述第一业务对象针对所述第一业务提交的交易业务数据、以及所述第一业务对象的第一签名信息；所述第一签名信息是由与所述第一业务对象相关联的第一业务节点通过所述第一业务对象的第一私钥信息，对所述交易业务数据进行签名后所得到的；所述第一业务对象的第一私钥信息是所述第一业务对象通过所述目标链中的对象身份管理合约进行身份注册后得到的；
    从所述第一业务处理请求中获取所述第一签名信息，基于所述第一链入口中存储的所述授权对象的注册数据信息对所述第一签名信息进行签名验证，得到所述第一业务对象的签名验证结果；
    在所述第一业务对象的签名验证结果指示签名验证成功时，确定所述第一业务对象为所述授权对象，且基于所述交易业务数据确定与所述第一业务对象相关联的第一业务；
    基于所述第一业务调用所述第一跨链读取合约，从所述目标链上读取与所述第一业务相关联的第一业务关联信息。
  3. 根据权利要求2所述的方法，所述授权对象的注册数据信息中包含所述授权对象的公钥证书；所述授权对象的公钥证书是由所述目标链网络中的目标共识节点调用所述目标链中的对象身份管理合约，对所述授权对象提交的对象数据信息进行身份注册后所得到的；
    所述从所述第一业务处理请求中获取所述第一签名信息，基于所述第一链入口中存储的所述授权对象的注册数据信息对所述第一签名信息进行签名验证，得到所述第一业务对象的签名验证结果，包括：
    从所述第一业务处理请求中获取所述第一签名信息，从所述第一链入口中存储的所述授 权对象的注册数据信息中获取所述授权对象的公钥证书；一个授权对象的公钥证书中包含一个授权对象的公钥信息；
    在所述授权对象的公钥证书中查找所述第一业务对象的公钥证书，且在查找到所述第一业务对象的公钥证书时，将查找到的所述第一业务对象的公钥证书作为第一公钥证书，且将所述第一公钥证书中的公钥信息作为所述第一业务对象的第一公钥信息；
    基于所述第一公钥证书以及所述第一公钥信息对所述第一签名信息进行签名验证，得到所述第一业务对象的签名验证结果。
  4. 根据权利要求3所述的方法，所述基于所述第一公钥证书以及所述第一公钥信息对所述第一签名信息进行签名验证，得到所述第一业务对象的签名验证结果，包括：
    将所述第一公钥证书的证书数据信息作为待处理证书信息，且在第二跨链读取时间戳时调用所述第一跨链读取合约中的证书数据读取方法，从所述目标链上读取所述第一业务对象的公钥证书；所述第二跨链读取时间戳为所述第一跨链读取时间戳的下一跨链读取时间戳；
    将读取到的所述第一业务对象的公钥证书中的证书数据信息作为目标证书信息；
    在所述待处理证书信息与所述目标证书信息保持一致时，基于所述第一公钥信息对所述第一签名信息进行签名验证，并将签名验证成功时的验证结果作为所述第一业务对象的签名验证结果。
  5. 根据权利要求3所述的方法，所述方法还包括：
    在所述授权对象的公钥证书中未查找到所述第一业务对象的公钥证书时，将所述第一业务对象确定为非法业务对象，拒绝所述非法业务对象发送的所述第一业务处理请求。
  6. 根据权利要求2所述的方法，所述基于所述第一业务调用所述第一跨链读取合约，从目标链上读取与所述第一业务相关联的第一业务关联信息，包括：
    基于所述第一业务调用所述第一跨链读取合约中的权限合约读取方法，生成用于发送给所述目标链网络中的目标共识节点的权限合约访问请求；所述权限合约访问请求用于指示所述目标共识节点调用所述目标链上的对象权限管理合约，获取与所述第一业务相关联的第一业务关联信息；
    接收所述目标共识节点基于所述权限合约访问请求返回的所述第一业务关联信息。
  7. 根据权利要求1所述的方法，所述第一业务关联信息包含为所述第一业务对象配置的业务权限类型、具备所述业务权限类型的所述第一业务对象在业务时长内的业务累计量以及业务累计阈值；
    所述在基于所述第一业务关联信息确定所述第一业务对象具备所述第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约执行所述第一业务，得到与所述第一业务相关联的第一业务执行结果，且将所述第一业务执行结果写入所述第一链，包括：
    在基于所述第一业务关联信息确定所述第一业务对象的业务权限类型为开票权限类型，且所述第一业务对象在所述业务时长内的业务累积量未达到所述业务累计阈值时，确定所述第一业务对象具备所述第一业务对应的第一业务处理权限；
    基于所述第一业务处理权限获取与所述开票权限类型相关联的合约调用地址和合约调用名称，通过所述合约调用地址和所述合约调用名称调用所述第一链上的电子票据开具合约，将所述第一业务对应的交易业务数据和与所述第一业务中的电子票据开具业务相关联的票据关键信息进行整合，基于整合后的票据关键信息为所述第一业务对象开具电子票据，将开具的所述电子票据作为所述第一业务所指示的业务数据；
    将所述票据关键信息、所述业务数据以及所述电子票据开具合约作为执行所述第一业务中的电子票据开具业务的第一业务执行结果，将包含所述第一业务执行结果的第一区块发送 至所述第一链上的校验共识节点，以使所述校验共识节点对所述第一区块进行区块校验，得到区块校验结果；所述校验共识节点为所述第一链网络中除所述第一共识节点之外剩余的共识节点；
    接收所述校验共识节点返回的所述区块校验结果，若所述区块校验结果指示区块校验成功，则将所述第一区块写入所述第一链。
  8. 根据权利要求7所述的方法，所述票据关键信息包含从所述目标链上读取到的辅助元数据信息，且所述辅助元数据信息包含第一电子票据模板以及与所述第一电子票据模板相关联的目标计税规则；所述第一电子票据模板为所述目标链上的目标共识节点调用所述目标链上的元数据管理合约对第二电子票据模板进行变更上链后的电子票据模板；所述第二电子票据模板为所述第一电子票据模板的上一电子票据模板；所述元数据变更信息是由与所述目标共识节点相关联的业务管理对象所提交的。
  9. 根据权利要求1所述的方法，所述第一业务至少包含以下交易业务中的一种：电子票据开具业务、电子票据流转业务、电子票据红冲业务、电子票据归档业务；所述第一业务处理合约至少包含：用于执行所述电子票据开具业务的电子票据开具合约、用于执行所述电子票据流转业务的电子票据流转合约、用于执行所述电子票据红冲业务的电子票据红冲合约以及用于执行所述电子票据归档业务的电子票据归档合约；
    其中，所述电子票据开具业务用于指示所述第一共识节点调用所述第一链上的所述电子票据开具合约，为所述第一业务对象开具电子发票；所述电子票据流转业务用于指示所述第一共识节点调用所述第一链上的所述电子票据流转合约，将所述电子发票由所述第一业务对象流转至第二业务对象；所述电子票据红冲业务用于指示所述第一共识节点调用所述第一链上的所述电子票据红冲合约，开具所述电子发票对应的红字发票，且所述红字发票用于更正所述电子发票中的相关票据信息；所述电子票据归档业务用于指示所述第一共识节点调用所述第一链上的所述电子票据归档合约，将所述第一链上满足票据归档条件的电子发票进行冷存储处理。
  10. 根据权利要求1所述的方法，所述在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于所述跨链读取请求中携带的第二业务从所述第一链上读取所述业务数据，且将所述业务数据中的核心数据返回给所述第二共识节点，包括：
    在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，从所述跨链读取请求中获取第二业务对象通过与所述第二链相关联的第二业务入口提交的第二业务；所述第二业务入口用于在确定所述第二业务对象具备在所述第二链上处理所述第二业务的权限时，允许所述第二业务对象通过所述第二共识节点调用所述第二跨链读取合约；
    基于所述第二业务所指示的跨链请求数据信息，从所述第一链上读取所述业务数据，将读取到的所述业务数据中的核心数据作为所述跨链读取请求对应的跨链请求响应信息，将所述跨链请求响应信息返回给所述第二共识节点，以使所述第二共识节点基于所述跨链请求响应信息调用所述第二链上的第二业务合约执行所述第二业务。
  11. 根据权利要求1所述的方法，所述方法还包括：
    在将所述第一业务执行结果写入所述第一链时，在所述第一业务执行结果对应的目标交易中指定与所述业务数据相关联的业务数据处理终端的处理终端标识；所述处理终端标识用于表征所述业务数据处理终端具备从所述第一链上清分到所述业务数据的功能；
    在获取到所述业务数据处理终端发送的交易清分请求时，基于所述交易清分请求中携带的所述处理终端标识从所述第一链上获取所述目标交易，且从所述目标交易所包含的所述第一业务执行结果中清分到所述业务数据，将所述业务数据返回给所述业务数据处理终端，以 使所述业务数据处理终端对所述业务数据进行数据分析。
  12. 一种多区块链数据处理方法，所述方法由第二链网络中的第二共识节点执行，所述方法包括：
    获取第二业务对象请求的第二业务，基于所述第二业务调用第二链上的第二跨链读取合约，从目标链上读取与所述第二业务相关联的第二业务关联信息；所述第二链为所述第二链网络中的区块链；所述目标链是目标链网络中的区块链；所述目标链网络独立于所述第二链网络，所述第二链不同于所述目标链；
    在基于所述第二业务关联信息确定所述第二业务对象具备所述第二业务对应的第二业务处理权限时，调用所述第二跨链读取合约生成与所述第二业务相关联的跨链读取请求，将所述跨链读取请求发送给第一链网络中的第一共识节点；所述跨链读取请求用于指示所述第一共识节点从所述第一链网络对应的第一链上读取与所述第二业务相关联的业务数据；所述第一链网络独立于所述第二链网络和所述目标链网络；所述业务数据是由所述第一共识节点在基于第一业务关联信息确定出第一业务对象具备第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约所确定的；所述第一业务关联信息是由所述第一共识节点基于所述第一业务调用所述第一链上的第一跨链读取合约从所述目标链上读取到的；
    接收所述第一共识节点基于所述跨链读取请求返回的所述业务数据中的核心数据，基于所述核心数据执行所述第二业务，并将所述第二业务对应的第二业务执行结果写入所述第二链。
  13. 一种多区块链数据处理方法，所述方法由目标链网络中的目标共识节点执行，所述方法包括：
    接收第一链网络中的第一共识节点发送的第一业务权限查询请求；所述第一业务权限查询请求是所述第一共识节点在获取到第一业务对象提交的第一业务时，调用第一链上的第一跨链读取合约所确定的；所述第一链为所述第一链网络中的区块链；所述第一链网络独立于所述目标链网络；
    基于所述第一业务查询请求从所述目标链网络对应的目标链上，读取与所述第一业务相关联的第一业务关联信息，将所述第一业务关联信息返回给所述第一共识节点，以使所述第一共识节点在基于所述第一业务关联信息确定所述第一业务对象具备所述第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约执行所述第一业务，得到用于写入所述第一链的第一业务执行结果；所述第一业务执行结果中包含所述第一业务所指示的业务数据；
    接收第二链网络中的第二共识节点发送的第二业务权限查询请求；所述第二业务权限查询请求是所述第二共识节点在获取到第二业务对象提交的第二业务时，调用所述第二链网络对应的第二链上的第二跨链读取合约所确定的；所述第二链网络独立于所述第一链网络和目标链网络；
    基于所述第二业务查询请求从所述目标链上，读取与所述第二业务相关联的第二业务关联信息，将所述第二业务关联信息返回给所述第二共识节点，以使所述第二共识节点在基于所述第二业务关联信息确定所述第二业务对象具备所述第二业务对应的第二业务处理权限时，调用所述第二跨链读取合约生成用于发送给所述第一共识节点的与所述第二业务相关联的跨链读取请求；所述跨链读取请求用于指示所述第一共识节点从所述第一链上读取所述业务数据。
  14. 一种多区块链数据处理装置，所述装置运行在第一链网络中的第一共识节点上，所述装置包括：
    第一业务获取模块，用于获取第一业务对象请求的第一业务，基于所述第一业务调用第 一链上的第一跨链读取合约，从目标链上读取与所述第一业务相关联的第一业务关联信息；所述第一链为所述第一链网络中的区块链；所述目标链是目标链网络中的区块链；所述目标链网络独立于所述第一链网络，所述第一链不同于所述目标链；
    第一业务执行模块，用于在基于所述第一业务关联信息确定所述第一业务对象具备所述第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约执行所述第一业务，得到与所述第一业务相关联的第一业务执行结果，且将所述第一业务执行结果写入所述第一链；所述第一业务执行结果中包含所述第一业务所指示的业务数据；
    业务数据读取模块，用于在获取到第二共识节点基于第二链上的第二跨链读取合约发送的跨链读取请求时，基于所述跨链读取请求中携带的第二业务从所述第一链上读取所述业务数据，且将所述业务数据中的核心数据返回给所述第二共识节点；所述第二共识节点用于在基于所述核心数据执行所述第二业务之后，将所述第二业务对应的第二业务执行结果写入所述第二链；所述第二链为所述第二共识节点所在的第二链网络中的区块链，所述第二链网络独立于所述第一链网络和所述目标链网络。
  15. 一种多区块链数据处理装置，所述装置运行在第二链网络中的第二共识节点上，所述装置包括：
    第二业务获取模块，用于获取第二业务对象请求的第二业务，基于所述第二业务调用第二链上的第二跨链读取合约，从目标链上读取与所述第二业务相关联的第二业务关联信息；所述第二链为所述第二链网络中的区块链；所述目标链是目标链网络中的区块链；所述目标链网络独立于所述第二链网络，所述第二链不同于所述目标链；
    跨链读取请求发送模块，用于在基于所述第二业务关联信息确定所述第二业务对象具备所述第二业务对应的第二业务处理权限时，调用所述第二跨链读取合约生成与所述第二业务相关联的跨链读取请求，将所述跨链读取请求发送给第一链网络中的第一共识节点；所述跨链读取请求用于指示所述第一共识节点从所述第一链网络对应的第一链上读取与所述第二业务相关联的业务数据；所述第一链网络独立于所述第二链网络和所述目标链网络；所述业务数据是由所述第一共识节点在基于第一业务关联信息确定出第一业务对象具备第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约所确定的；所述第一业务关联信息是由所述第一共识节点基于所述第一业务调用所述第一链上的第一跨链读取合约从所述目标链上读取到的；
    第二业务执行模块，用于接收所述第一共识节点基于所述跨链读取请求返回的所述业务数据中的核心数据，基于所述核心数据执行所述第二业务，并将所述第二业务对应的第二业务执行结果写入所述第二链。
  16. 一种多区块链数据处理装置，所述装置运行在目标链网络中的目标共识节点上，所述装置包括：
    第一查询请求接收模块，用于接收第一链网络中的第一共识节点发送的第一业务权限查询请求；所述第一业务权限查询请求是所述第一共识节点在获取到第一业务对象提交的第一业务时，调用第一链上的第一跨链读取合约所确定的；所述第一链为所述第一链网络中的区块链；所述第一链网络独立于所述目标链网络；
    第一关联信息返回模块，用于基于所述第一业务查询请求从所述目标链网络对应的目标链上，读取与所述第一业务相关联的第一业务关联信息，将所述第一业务关联信息返回给所述第一共识节点，以使所述第一共识节点在基于所述第一业务关联信息确定所述第一业务对象具备所述第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约执行所述第一业务，得到用于写入所述第一链的第一业务执行结果；所述第一业务执行结果中包含所述第一业务所指示的业务数据；
    第二查询请求接收模块，用于接收第二链网络中的第二共识节点发送的第二业务权限查 询请求；所述第二业务权限查询请求是所述第二共识节点在获取到第二业务对象提交的第二业务时，调用所述第二链网络对应的第二链上的第二跨链读取合约所确定的；所述第二链网络独立于所述第一链网络和目标链网络；
    第二关联信息返回模块，用于基于所述第二业务查询请求从所述目标链上，读取与所述第二业务相关联的第二业务关联信息，将所述第二业务关联信息返回给所述第二共识节点，以使所述第二共识节点在基于所述第二业务关联信息确定所述第二业务对象具备所述第二业务对应的第二业务处理权限时，调用所述第二跨链读取合约生成用于发送给所述第一共识节点的与所述第二业务相关联的跨链读取请求；所述跨链读取请求用于指示所述第一共识节点从所述第一链上读取所述业务数据。
  17. 一种多区块链数据处理系统，所述系统包括：第一链网络中的第一共识节点、目标链网络中的目标共识节点和第二链网络中的第二共识节点；所述第一链网络独立于所述目标链网络，且独立于所述第二链网络；
    所述第一共识节点用于获取第一业务对象请求的第一业务，基于所述第一业务调用第一链上的第一跨链读取合约，生成第一业务权限查询请求；
    所述目标共识节点用于在获取到所述第一共识节点发送的所述第一业务权限查询请求时，从所述目标链网络对应的目标链上读取与所述第一业务相关联的第一业务关联信息，将所述第一业务关联信息返回给所述第一共识节点；
    所述第一共识节点还用于在基于所述第一业务关联信息确定所述第一业务对象具备所述第一业务对应的第一业务处理权限时，调用所述第一链上的第一业务处理合约执行所述第一业务，得到与所述第一业务相关联的第一业务执行结果，且将所述第一业务执行结果写入所述第一链；所述第一业务执行结果中包含所述第一业务所指示的业务数据；
    所述第一共识节点还用于在获取到所述第二共识节点发送的跨链读取请求时，基于所述跨链读取请求中携带的第二业务从所述第一链上读取所述业务数据，且将所述业务数据中的核心数据返回给所述第二共识节点；所述跨链读取请求是所述第二共识节点在基于第二业务关联信息确定所述第二业务对象具备所述第二业务对应的第二业务处理权限时，调用所述第二跨链读取合约所生成的；所述第二业务关联信息是所述第二共识节点基于所述第二业务调用所述第二跨链读取合约从目标链上读取到的；
    所述第二共识节点用于在基于所述核心数据执行所述第二业务之后，将所述第二业务对应的第二业务执行结果写入所述第二链。
  18. 一种计算机设备，包括存储器和处理器；
    所述存储器与所述处理器相连，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1-13任一项所述的方法。
  19. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1-13任一项所述的方法。
  20. 一种计算机程序产品，包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现权利要求1-13任一项所述的方法。
PCT/CN2023/112033 2022-10-14 2023-08-09 多区块链数据处理方法、装置、设备、系统以及介质 WO2024078109A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP23790529.4A EP4375850A1 (en) 2022-10-14 2023-08-09 Multi-blockchain data processing method and apparatus, and device, system and medium
US18/379,648 US20240129143A1 (en) 2022-10-14 2023-10-12 Dividing data storage and service operations among plural blockchains

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211260878.XA CN117931933A (zh) 2022-10-14 2022-10-14 多区块链数据处理方法、装置、设备、系统以及介质
CN202211260878.X 2022-10-14

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/379,648 Continuation US20240129143A1 (en) 2022-10-14 2023-10-12 Dividing data storage and service operations among plural blockchains

Publications (1)

Publication Number Publication Date
WO2024078109A1 true WO2024078109A1 (zh) 2024-04-18

Family

ID=88511234

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/112033 WO2024078109A1 (zh) 2022-10-14 2023-08-09 多区块链数据处理方法、装置、设备、系统以及介质

Country Status (2)

Country Link
CN (1) CN117931933A (zh)
WO (1) WO2024078109A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110266655A (zh) * 2019-05-30 2019-09-20 中国工商银行股份有限公司 一种基于区块链的跨链互联方法、设备以及系统
US20190340267A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN112348672A (zh) * 2019-08-07 2021-02-09 阿里巴巴集团控股有限公司 跨链交易方法、装置、多区块链系统及计算设备
CN113988845A (zh) * 2021-08-12 2022-01-28 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190340267A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN110266655A (zh) * 2019-05-30 2019-09-20 中国工商银行股份有限公司 一种基于区块链的跨链互联方法、设备以及系统
CN112348672A (zh) * 2019-08-07 2021-02-09 阿里巴巴集团控股有限公司 跨链交易方法、装置、多区块链系统及计算设备
CN113988845A (zh) * 2021-08-12 2022-01-28 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质

Also Published As

Publication number Publication date
CN117931933A (zh) 2024-04-26

Similar Documents

Publication Publication Date Title
US20190139037A1 (en) System and method for scaling blockchain networks with secure off-chain payment hubs
EP4318362A1 (en) Blockchain-based data processing method, apparatus and device, and storage medium
CN109544982B (zh) 停车信息共享方法及共享系统
US20220156837A1 (en) Distributed ledger implementation for entity formation and monitoring system
US20140089156A1 (en) Addresses in financial systems
CN111292174A (zh) 一种纳税信息处理方法、装置及计算机可读存储介质
CN112468537A (zh) 基于局域网环境的区块链网络搭建结构及数据处理方法
US20200314078A1 (en) Inter-system linking method and node
CN115705571A (zh) 保护可审计的帐户的隐私
CN107742085A (zh) 一种数据保全系统
WO2021233109A1 (zh) 基于区块链的消息处理方法、装置、设备以及存储介质
Podgorelec et al. State channel as a service based on a distributed and decentralized web
CN113491085A (zh) 具有非图灵完备系统守卫的区块链
KR102139551B1 (ko) 유언장을 관리하는 서버 및 방법
WO2024078109A1 (zh) 多区块链数据处理方法、装置、设备、系统以及介质
US20220311595A1 (en) Reducing transaction aborts in execute-order-validate blockchain models
WO2024099023A1 (zh) 多区块链数据处理方法、装置、设备、计算机可读存储介质及计算机程序产品
WO2024093593A1 (zh) 基于多区块链的数据处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品
WO2024082807A1 (zh) 基于多区块链的资产转移方法、装置、设备、介质及产品
EP4375850A1 (en) Multi-blockchain data processing method and apparatus, and device, system and medium
WO2024082818A1 (zh) 基于多区块链的跨链处理方法、装置、设备、系统及介质
US11818267B1 (en) Multi-level access distributed ledger system
CN117938867A (zh) 一种多区块链数据处理方法、装置、设备、介质及产品
CN118057797A (zh) 基于多区块链的数据处理方法、相关设备、介质及产品
CN117951217A (zh) 基于多区块链的跨链配置方法、装置、设备、系统及介质

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2023790529

Country of ref document: EP

Effective date: 20231027