Multi-blockchain data processing method, apparatus, device, system, and medium

Abstract

The application provides a multi-blockchain data processing method, device, equipment, system and medium. The method comprises the following steps: when a first consensus node obtains a first service, a first cross-chain reading contract on a first chain is called to read first service association information associated with the first service from a management chain; when the first consensus node determines that a first service object has a first service processing right based on the first service association information, a first service processing contract on the first chain is called to execute the first service to obtain a first service execution result; when the first consensus node obtains a cross-chain reading request sent by a second consensus node, service data in the first service execution result is read from the first chain, and core data in the service data is returned to the second consensus node, so that the second consensus node writes a second service execution result obtained based on the core data into a second chain. The application can reduce the complexity of chain data storage.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a multi-blockchain data processing method, device, equipment, system and medium. BACKGROUND

[0002] 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 an extended business B of business A). Thus, each business processor accessing the blockchain network in the form of a terminal or a server needs to process the related businesses (for example, business A and extended business B) on the same blockchain corresponding to the blockchain network.

[0003] The inventor has found in practice that, based on a single blockchain, the business execution results corresponding to each related business (for example, business A and extended business B) processed by each business processor need to be written into the same blockchain without distinction, for example, the consensus node in the blockchain network may package the business execution result 1 obtained by executing business A and the business execution result obtained by executing extended business B as two transaction execution results into the same block and chain to the same blockchain. Obviously, by mixing the transaction execution results corresponding to different businesses and submitting them to the same blockchain, the complexity of the blockchain data stored on the single blockchain will inevitably be increased, and the security of the data stored on the single blockchain is difficult to ensure. SUMMARY

[0004] The embodiments of the present application provide a multi-blockchain data processing method, device, equipment and medium, which can reduce the complexity of data storage on each blockchain by deploying multiple blockchains for data storage, and can also improve the security of the data stored on each chain by mutual cooperation between the multiple blockchains.

[0005] The embodiments of the present application provide a multi-blockchain data processing method, device, equipment and medium, which can reduce the complexity of data storage on each blockchain by deploying multiple blockchains for data storage, and can also improve the security of the data stored on each chain by mutual cooperation between the multiple blockchains.

[0006] The first business object request is obtained, a first cross-chain reading contract on the first chain is called based on the first business, and first business association information associated with the first business is read from a 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; and the first chain is different from the target chain.

[0007] 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 to the first chain; the first business execution result includes the business data indicated by the first business;

[0008] Upon receiving a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, the second consensus node reads 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; 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.

[0009] 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 authorization object synchronized from the target chain by the first consensus node through the first cross-chain read contract at the time of the first cross-chain read timestamp;

[0010] Obtaining the first business requested by the first business object, calling the first cross-chain read contract on the first chain based on the first business, and reading the first business association information associated with the first business from the target chain, including:

[0011] Obtaining, 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 transaction business data submitted by the first business object for the first business, and 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 using the first private key information of the first business object; the first private key information of the first business object is obtained by the first business object registering its identity through the object identity management contract in the target chain;

[0012] Obtaining first signature information from the first business processing request, performing signature verification on the first signature information based on the registration data information of the authorization object stored in the first chain entry, and obtaining a signature verification result of the first business object;

[0013] When the signature verification result of the first business object indicates that the signature verification is successful, determining the first business object as an authorized object, and determining a first business associated with the first business object based on the transaction business data;

[0014] The first cross-chain reading contract is called based on the first business to read the first business association information associated with the first business from the target chain.

[0015] 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;

[0016] Obtaining first signature information from the first business processing request, performing signature verification on the first signature information based on the registration data information of the authorization object stored in the first chain entry, and obtaining a signature verification result of the first business object, including:

[0017] Obtaining first signature information from the first service processing request, and obtaining a public key certificate of the authorization object from the registration data information of the authorization object stored in the first chain entry; a public key certificate of an authorization object contains public key information of an authorization object;

[0018] Searching 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, using the found public key certificate of the first business object as the first public key certificate, and using the public key information in the first public key certificate as the first public key information of the first business object;

[0019] The first signature information is signature verified based on the first public key certificate and the first public key information to obtain a signature verification result of the first business object.

[0020] The first signature information is signature verified based on the first public key certificate and the first public key information to obtain a signature verification result of the first business object, including:

[0021] The certificate data information of the first public key certificate is used as the certificate information to be processed, and the certificate data reading method in the first cross-chain read contract is called at the second cross-chain read timestamp to read the public key certificate of the first business object from the target chain; the second cross-chain read timestamp is the next cross-chain read timestamp after the first cross-chain read timestamp;

[0022] Using the certificate data information in the read public key certificate of the first business object as the target certificate information;

[0023] When the certificate information to be processed is consistent with the target certificate information, signature verification is performed on the first signature information based on the first public key information, and the verification result when the signature verification is successful is used as the signature verification result of the first business object.

[0024] The method further includes:

[0025] When the public key certificate of the first business object is not found in the public key certificate of the authorization object, the first business object is determined to be an illegal business object, and the first business processing request sent by the illegal business object is rejected.

[0026] The first cross-chain reading contract is called based on the first business, and the first business-related information associated with the first business is read from the target chain, including:

[0027] Based on the first business, the permission contract reading method in the first cross-chain read contract is called to 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 first business association information associated with the first business;

[0028] Receive the first business association information returned by the target consensus node based on the permission contract access request.

[0029] 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;

[0030] 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, calling the first business processing contract on the first chain to execute the first business, obtaining a first business execution result associated with the first business, and writing the first business execution result to the first chain, including:

[0031] When it is determined based on the first business association information that the business permission type of the first business object is an invoicing permission type, and the business accumulation amount of the first business object with the invoicing permission type within the business duration does not reach the business accumulation threshold, it is determined that the first business object has the first business processing permission corresponding to the first business;

[0032] Based on the first business processing authority, the contract call address and contract call name associated with the invoicing authority type are obtained, and the electronic invoice issuance contract on the first chain is called through the contract call address and contract call name. The transaction business data corresponding to the first business and the key invoice information associated with the electronic invoice issuance business in the first business are integrated. Based on the integrated key invoice information, an electronic invoice is issued for the first business object, and the issued electronic invoice is used as the business data indicated by the first business.

[0033] Using the key bill information, business data, and the electronic bill issuance contract as a first business execution result of the electronic bill issuance business in the first business, and sending a first block containing the first business execution result to a 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 consensus node remaining in the first chain network except the first consensus node;

[0034] Receive the block verification result returned by the verification consensus node, and if the block verification result indicates that the block verification is successful, write the first block to the first chain.

[0035] Among them, 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 rules 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.

[0036] The first business includes at least one of the following transaction businesses: electronic bill issuance business, electronic bill circulation business, electronic bill redemption 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 redemption contract for executing the electronic bill redemption business, and an electronic bill archiving contract for executing the electronic bill archiving business;

[0037] Among them, 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-ink invoice corresponding to the electronic invoice, and the red-ink 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 cold store the electronic invoices on the first chain that meet the invoice archiving conditions.

[0038] When a cross-chain read request is received from the second consensus node based on the second cross-chain read contract on the second chain, 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, including:

[0039] Upon obtaining a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, obtaining 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; 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;

[0040] Based on the cross-chain request data information indicated by the second business, the business data is read from the first chain, the core data in the read business data is used as the cross-chain request response information corresponding to the cross-chain read request, and the cross-chain request response information is returned 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.

[0041] The method further includes:

[0042] When writing the first business execution result to the first chain, the processing terminal identifier of the business data processing terminal associated with the business data is specified in the target transaction corresponding to the first business execution result; the processing terminal identifier is used to indicate that the business data processing terminal has the function of clearing business data from the first chain;

[0043] When a transaction clearing request is received from the business data processing terminal, the target transaction is obtained from the first chain based on the processing terminal identifier carried in the transaction clearing request, and the business data is cleared from the first business execution result included in the target transaction, and the business data is returned to the business data processing terminal so that the business data processing terminal performs data analysis on the business data.

[0044] On the one hand, 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 includes:

[0045] Obtaining a second business requested by a second business object, invoking a second cross-chain read contract on a second chain based on the second business, and reading second business-related 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 independent of the second chain network; the second chain is different from the target chain;

[0046] 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 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;

[0047] Receive 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.

[0048] On the one hand, 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 includes:

[0049] Receiving a first business permission query request sent by a first consensus node in a first chain network; the first business permission query request is determined by the first consensus node invoking a 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 independent of the target chain network;

[0050] Based on the first business query request, 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, it calls the first business processing contract on the first chain to execute the first business and obtain a first business execution result for writing to the first chain; the first business execution result includes business data indicated by the first business;

[0051] Receive a second business permission query request sent by a second consensus node in the second chain network; the second business permission 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;

[0052] Based on the second business query request, 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.

[0053] On the one hand, 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:

[0054] A first business acquisition module is configured to acquire a first business requested by a first business object, invoke 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 independent of the first chain network; the first chain is different from the target chain;

[0055] A first business execution module is configured to, upon determining based on the first business association information that the first business object has the first business processing authority corresponding to the first business, invoke the first business processing contract on the first chain to execute the first business, obtain a first business execution result associated with the first business, and write the first business execution result to the first chain; the first business execution result includes business data indicated by the first business;

[0056] The business data reading module is 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 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 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.

[0057] 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 authorization object synchronized from the target chain by the first consensus node through the first cross-chain read contract at the time of the first cross-chain read timestamp;

[0058] The first business acquisition module includes:

[0059] A first business request unit is configured to obtain, through a first chain entry of a first chain network, a first business processing request sent by a first business node corresponding to a first business object based on a first business; the first business processing request carries transaction business data submitted by the first business object for the first business, and 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 using the first private key information of the first business object; the first private key information of the first business object is obtained by the first business object registering its identity through an object identity management contract in a target chain;

[0060] a signature verification unit, configured to obtain 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;

[0061] a first business determining unit, configured to determine, when a signature verification result of the first business object indicates that the signature verification is successful, that the first business object is an authorized object, and determine, based on the transaction business data, a first business associated with the first business object;

[0062] The cross-chain reading unit 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.

[0063] 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;

[0064] The signature verification unit includes:

[0065] The certificate acquisition subunit is configured 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 the authorization object;

[0066] a certificate search subunit, configured to search 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;

[0067] The signature verification subunit 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.

[0068] The signature verification subunit is specifically configured to use the certificate data information of the first public key certificate as the certificate information to be processed, and to call the certificate data reading method in the first cross-chain read contract at the second cross-chain read timestamp to read the public key certificate of the first business object from the target chain; the second cross-chain read timestamp is the next cross-chain read timestamp of the first cross-chain read timestamp;

[0069] The signature verification subunit 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;

[0070] The signature verification subunit 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.

[0071] The signature verification unit also includes:

[0072] The request rejection subunit is configured 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.

[0073] Among them, the cross-chain reading unit includes:

[0074] An access request generation subunit is configured to call a permission contract reading method in a first cross-chain read contract based on a first business, and generate a permission contract access request for sending to a target consensus node in a target chain network; the permission contract access request is configured to instruct the target consensus node to call an object permission management contract on the target chain to obtain first business association information associated with the first business;

[0075] The association information returning subunit is used to receive the first business association information returned by the target consensus node based on the permission contract access request.

[0076] 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;

[0077] The first business execution module includes:

[0078] a processing authority determining unit, configured to determine that the first business object has the first business processing authority corresponding to the first business if, based on the first business association information, it is determined that the business authority type of the first business object is the invoicing authority type and the accumulated business volume of the first business object having the invoicing authority type within the business duration does not reach a business accumulation threshold;

[0079] The bill contract calling unit is configured to obtain a contract calling address and a contract calling name associated with the bill opening permission type based on the first business processing permission, call an electronic bill opening contract on the first chain through the contract calling address and the contract calling name, integrate transaction business data corresponding to the first business and bill key information associated with the electronic bill opening business in the first business, open an electronic bill for the first business object based on the integrated bill key information, and take the opened electronic bill as business data indicated by the first business.

[0080] The block checking unit is configured to take the bill key information, the business data, and the electronic bill opening contract as a first business execution result of executing the electronic bill opening business in the first business, send a first block containing the first business execution result to a checking consensus node on the first chain, and make the checking consensus node perform block checking on the first block to obtain a block checking result. The checking consensus node is a consensus node remaining in the first chain network except the first consensus node.

[0081] The checking result receiving unit is configured to receive the block checking result returned by the checking consensus node, and write the first block into the first chain if the block checking result indicates that the block checking is successful.

[0082] The bill key information contains auxiliary metadata information read from the target chain, and the auxiliary metadata information contains a first electronic bill template and a target tax calculation rule associated with the first electronic bill template. The first electronic bill template is an electronic bill template after a second electronic bill template is changed and chained by a target consensus node on the target chain calling a metadata management contract on the target chain. The second electronic bill template is a previous electronic bill template of the first electronic bill template. The metadata change information is submitted by a business management object associated with the target consensus node.

[0083] The first business at least contains one of the following transaction businesses: an electronic bill opening business, an electronic bill circulation business, an electronic bill red stamping business, and an electronic bill archiving business. The first business processing contract at least contains an electronic bill opening contract for executing the electronic bill opening business, an electronic bill circulation contract for executing the electronic bill circulation business, an electronic bill red stamping contract for executing the electronic bill red stamping business, and an electronic bill archiving contract for executing the electronic bill archiving business.

[0084] The electronic bill issuing service is used to instruct the first consensus node to call an electronic bill issuing contract on the first chain to issue an electronic invoice for the first business object; the electronic bill circulation service is used to instruct the first consensus node to call an electronic bill circulation contract on the first chain to circulate the electronic invoice from the first business object to a second business object; the electronic bill red-ink service is used to instruct the first consensus node to call an electronic bill red-ink contract on the first chain to issue a red-ink invoice corresponding to the electronic invoice, and the red-ink invoice is used to correct related bill information in the electronic invoice; and the electronic bill archiving service is used to instruct the first consensus node to call an electronic bill archiving contract on the first chain to perform cold storage processing on the electronic invoice meeting a bill archiving condition on the first chain.

[0085] The business data reading module includes:

[0086] The bill reading request sending unit is configured to, when the cross-chain reading request sent by the second consensus node based on the second cross-chain reading contract on the second chain is acquired, acquire, from the cross-chain reading request, a second business submitted by a second business object through a second business portal associated with the second chain; and the second business portal is configured to, when it is determined that the second business object has the right to process the second business on the second chain, allow the second business object to call the second cross-chain reading contract through the second consensus node.

[0087] The bill reading response unit is configured to, based on cross-chain request data information indicated by the second business, read the business data from the first chain, take core data in the read business data as cross-chain request response information corresponding to the cross-chain reading request, and return the cross-chain request response information to the second consensus node, so that the second consensus node calls a second business contract on the second chain to execute the second business based on the cross-chain request response information.

[0088] The first business execution module is further configured to, when the first business execution result is written into the first chain, specify a processing terminal identifier of a business data processing terminal associated with the business data in a target transaction corresponding to the first business execution result; and the processing terminal identifier is used to indicate that the business data processing terminal has the function of clearing the first chain to the business data.

[0089] The first business execution module is further configured to, when a transaction clearing request sent by the business data processing terminal is acquired, acquire the target transaction from the first chain based on the processing terminal identifier carried in the transaction clearing request, 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.

[0090] The 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 the device includes:

[0091] A second business acquisition module is configured to acquire a second business requested by a second business object, invoke a second cross-chain read 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 independent of the second chain network; and the second chain is different from the target chain.

[0092] A 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, 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 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;

[0093] 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.

[0094] In one aspect, 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:

[0095] A first query request receiving module is configured to receive a first business permission query request sent by a first consensus node in a first chain network; the first business permission query request is determined by the first consensus node invoking a first cross-chain read contract on the first chain when obtaining a first business submitted by a first business object; the first chain is a blockchain in the first chain network independent of the target chain network;

[0096] A first associated information return module is configured to read 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 based on the first business associated information that the first business object has the first business processing authority corresponding to the first business, it calls the first business processing contract on the first chain to execute the first business and obtain a first business execution result for writing to the first chain; the first business execution result includes business data indicated by the first business;

[0097] A second query request receiving module is configured to receive a second business permission query request sent by a second consensus node in a second chain network; the second business permission query request is determined by the second consensus node invoking a second cross-chain read contract on a 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;

[0098] The second associated information return 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.

[0099] In one aspect, an embodiment of the present application provides a multi-blockchain data processing 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;

[0100] The first consensus node is used to obtain 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 generate a first business permission query request;

[0101] The target consensus node is configured to, upon receiving the first business authority query request sent by the first consensus node, 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;

[0102] The first consensus node is further configured to, upon determining based on the first business association information that the first business object has the first business processing authority corresponding to the first business, call the first business processing contract on the first chain to execute 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;

[0103] The first consensus node is further configured to, upon receiving a cross-chain read request sent by the second consensus node, read business data from the first chain based on the second business carried in the cross-chain read request, and return the core data in the business data to the second consensus node; the cross-chain read request is generated by the second consensus node calling the second cross-chain read contract when determining, 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 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;

[0104] 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.

[0105] In one aspect, 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.

[0106] On one hand, 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.

[0107] According to one aspect of the present application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the above aspect.

[0108] In an embodiment of the present application, the first consensus node in the first chain network can, when obtaining 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 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; further, the first consensus node in the first chain network can, 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, call the first business processing contract on the first chain to execute the first business, obtain the first business execution result associated with the first business, and 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; further, 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; it should be understood that 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. It can be seen that 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. Thus, in a business scenario involving the transfer of core blockchain data, the first consensus node can participate in maintaining the first chain within the first chain network, with the first chain primarily used to store the business data generated by executing each first business in the real-time business flow. Furthermore, the second consensus node can participate in maintaining the second chain within the second chain network, with the second chain primarily used to store the results of executing the second business. It should be noted that the second business results here are determined based on the core data (i.e., the portion of the business data that is authorized to be visible) within the business data transferred from the first chain to the second chain across chains. Furthermore, it should be noted that the target consensus node can be used to centrally manage the permissions (e.g., identity permissions and business permissions) for business objects accessing the second chain network and the first chain network. Clearly, deploying multiple blockchains to store data separately can effectively reduce the complexity of data storage on each blockchain. Furthermore, through the mutual collaboration between multiple blockchains, the security of the data stored on each chain can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0109] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0110] Figure 1 This is a schematic diagram of a hierarchical structure of a blockchain network provided in an embodiment of the present application;

[0111] Figure 2 This is a schematic diagram of a scenario of a blockchain electronic bill platform based on multiple blockchains provided in an embodiment of the present application;

[0112] Figure 3 This is a multi-blockchain data processing method provided by an embodiment of the present application;

[0113] Figure 4 This is a schematic diagram of a scenario in which identity authentication is performed through a chain entry, provided in an embodiment of the present application;

[0114] Figure 5 This is a schematic diagram of a scenario of cross-chain interaction between three chains adopted in an embodiment of the present application;

[0115] Figure 6 This is a multi-blockchain data processing method provided by an embodiment of the present application;

[0116] Figure 7 This is a multi-blockchain data processing method provided by an embodiment of the present application;

[0117] Figure 8 This is a multi-blockchain data processing method provided by an embodiment of the present application;

[0118] Figure 9 This is a schematic diagram of the structure of a multi-blockchain data processing device provided by this application;

[0119] Figure 10 This is a schematic diagram of the structure of a multi-blockchain data processing device provided by this application;

[0120] Figure 11 This is a schematic diagram of the structure of a multi-blockchain data processing device provided by this application;

[0121] Figure 12 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0122] Figure 13 This is a schematic diagram of a multi-blockchain data processing system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0123] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0124] See Figure 1 , Figure 1 This is a schematic diagram of the hierarchical structure of a blockchain network provided by an embodiment of the present application. Figure 1 The hierarchical structure shown is applied to the blockchain system corresponding to the multi-business collaborative processing platform. The blockchain network corresponding to the blockchain system includes a business network deployed in the public network and multiple consensus networks deployed in the private cloud. Figure 1 As shown, the business network here can be Figure 1 The business network 100a shown, and the multiple consensus networks here can specifically include Figure 1 Consensus network 100a, consensus network 200a, and consensus network 300a are shown.

[0125] In such Figure 1 In the service network 400a shown, multiple service nodes are deployed. The multiple service nodes here may specifically include Figure 1 The service nodes shown are 110a, 110b, 110c, 110d, 110e, 110f, 110g, ..., 110n. It should be noted that the number of service nodes deployed in the service network 400a is not limited. It should be understood that the service nodes in the service network 400a do not need to participate in accounting. In addition, Figure 1 As shown, each business node running in the business network 400a can access one or more of the aforementioned consensus networks through network communication. There is no limit on the number of consensus networks that each business object can access through a corresponding business node. It is understood that data can also be exchanged between consensus networks through network communication.

[0126] It should be understood that in Figure 1 In the consensus network 100a shown, multiple consensus nodes are deployed. The multiple consensus nodes here can specifically include Figure 1The consensus nodes 10a, 10b, 10c and 10d are shown. It should be noted that the number of consensus nodes deployed in the consensus network 100a is not limited. Figure 1 As shown, for multiple consensus nodes running in the consensus network 100a, the blockchain they jointly maintain is specifically Figure 1 Blockchain 10e is shown.

[0127] Similarly, in Figure 1 In the consensus network 200a shown, multiple consensus nodes are deployed. The multiple consensus nodes here can specifically include Figure 1 The consensus nodes 11a, 11b, 11c and 11d are shown. It should be noted that the number of consensus nodes deployed in the consensus network 200a is not limited here. Figure 1 As shown, for multiple consensus nodes running in the consensus network 200a, the blockchain maintained together is specifically Figure 1 Blockchain 11e is shown.

[0128] By analogy, in Figure 1 In the consensus network 300a shown, multiple consensus nodes are deployed. The multiple consensus nodes here can specifically include Figure 1 The consensus nodes 12a, 12b, 12c and 12d are shown. It should be noted that the number of consensus nodes deployed in the consensus network 300a is not limited here. Figure 1 As shown, for multiple consensus nodes running in the consensus network 300a, the blockchain maintained together is specifically Figure 1 Blockchain 12e is shown.

[0129] For ease of understanding, the embodiments of the present application may collectively refer to the business nodes and consensus nodes located in the above-mentioned blockchain system as blockchain nodes (referred to as nodes for short), and may collectively refer to the consensus network 100a, consensus network 100b and consensus network 100c participating in the above-mentioned blockchain system as the core consensus network, and may collectively refer to the various nodes in the above-mentioned core consensus network as core nodes.

[0130] It should be understood that the blockchain involved in the embodiments of this application is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data in chronological order and encrypt it into a ledger to make it tamper-proof and forge-proof, while also enabling data verification, storage, and updates. Blockchain is essentially a decentralized database in which each node stores an identical blockchain.

[0131] To facilitate the distinction of each core consensus network in the blockchain system corresponding to the multi-service collaboration processing platform, the embodiments of the present application can combine the specific application scenarios of the multi-service collaboration processing platform (for example, the electronic ticket core data flow scenario under the blockchain electronic ticket platform), collectively refer to the consensus network 100a as the target chain network, collectively refer to the blockchain 10e commonly maintained by each consensus node in the target chain network as the target chain, and can also select the consensus node in the target chain network for executing the management service (for example, the registration service and the authorization service, etc.) as the target consensus node in the target chain network. Similarly, it can be understood that the embodiments of the present application can collectively refer to the consensus network 200a as the first chain network, and collectively refer to the blockchain 11e commonly maintained by each consensus node in the first chain network as the first chain. It can also select the consensus node in the first chain network for executing the first service (the first service can be a ticket service associated with an electronic ticket, for example, an electronic ticket issuing service, etc.) as the first consensus node in the target chain network. By analogy, the embodiments of the present application can collectively refer to the consensus network 300a as the second chain network, and collectively refer to the blockchain 12e commonly maintained by each consensus node in the second chain network as the second chain. It can also select the consensus node in the second chain network for executing the second service (the second service can be a derivative service associated with an electronic ticket, for example, an enterprise qualification identification service, etc.) as the first consensus node in the target chain network. It should be understood that for each core consensus network, the management service, the ticket service and the derivative service can be regarded as the transaction service of the transaction initiated by the corresponding business object.

[0132] For example, when the blockchain system is applied to a blockchain electronic ticket platform, a secure and reliable blockchain electronic ticket three-chain network can be constructed based on the target chain, the first chain and the second chain. In the blockchain electronic ticket three-chain network, when the above services are independently executed in the above three consensus networks, the service execution results obtained by independently executing the above services can be respectively stored in the blockchain ledger of the corresponding blockchain, thereby avoiding the complexity of data storage on each chain from the root.

[0133] Specifically, for example, when the consensus network 100a is used as the target chain network, and 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. For another example, when the 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 the 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. The first chain here can specifically be the bill chain in the aforementioned blockchain system, and the bill consensus nodes (or first core nodes) determined from the bill chain network can be collectively referred to as first consensus nodes. That is, the embodiment of the present application can utilize the consensus mechanism in the bill chain network to select a consensus node (that is, the aforementioned bill consensus node) from the consensus nodes of the bill chain network as the first consensus node, and can collectively refer to the remaining consensus nodes in the consensus nodes of the bill chain network except the first consensus node as verification consensus nodes (in this case, the verification consensus node is specifically a bill verification consensus node). For another example, when the consensus network 300a is used as the second chain network, and 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 node (or second core node) determined from the application contract chain network can be collectively referred to as the second consensus node, 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 (in this case, the verification consensus node is specifically an application verification consensus node).

[0134] In the above-mentioned blockchain system, 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. For any of the three core consensus networks mentioned above, the specific process of writing transaction data in the core consensus network into the corresponding blockchain ledger (e.g., a distributed database) 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 within the above-mentioned blockchain network in a relay manner until the consensus node in the corresponding core consensus network within the above-mentioned blockchain network (e.g., consensus node 11b in consensus network 200a) receives the transaction data. At this time, the consensus node (e.g., consensus node 11b in consensus network 200a) then packages the transaction data into a block so that it can subsequently reach consensus with other consensus nodes, so that after the consensus is passed, the consensus-passed block can be written into the distributed database of its own core consensus network (e.g., consensus network 200a).

[0135] Optionally, it is understandable that, after consensus is passed, the embodiment of the present application can also write the block carrying the transaction data and multiple other blocks associated with the block into a distributed database in parallel through the storage layer of its own core consensus network (for example, consensus network 200a). This can fundamentally break through the limitations of the blockchain structure of the blockchain, and thus effectively improve the storage efficiency of data storage.

[0136] It is understood that in the aforementioned blockchain system, smart contracts can be deployed on the blockchain of the corresponding core consensus network. In the blockchain system, such smart contracts can be understood as a code executed by each blockchain node (i.e., each consensus node). Through such smart contracts, arbitrary logic can be executed and results can be obtained. For example, a user can initiate a transaction request through a user client to call a smart contract that has been deployed on the blockchain (e.g., the aforementioned blockchain 11e) of the corresponding core consensus network (e.g., the aforementioned consensus network 200a).

[0137] Specifically, the business node in the business network can send the transaction business request to the consensus node in the corresponding core consensus network (for example, Figure 1 The consensus node 11a shown in the figure authenticates the user who sent the transaction request through the chain entrance of the corresponding core consensus network, and allows the transaction request sent by the user to be sent to other consensus nodes in the corresponding core consensus network (for example, Figure 1 Consensus nodes 11b shown) to call these consensus nodes (e.g., Figure 2The smart contracts running in the consensus nodes 11a and 11b shown execute the transaction business requested by the user.

[0138] It should be understood that one or more smart contracts can be deployed on the blockchain (e.g., the blockchain 11e) of the core consensus network (e.g., the consensus network 200a). These smart contracts can be distinguished by the contract call address, contract identification number (ID) or contract name, and the transaction service request initiated by the user client can also carry the contract call address or contract identification number or contract name of the smart contract to specify the smart contract to be run. In the above blockchain system, if the smart contract specified by the user client is a smart contract that requires cross-chain data reading (i.e., cross-chain reading contract), each consensus node will request to read data from the corresponding blockchain through the chain identifier specified by the cross-chain reading contract. Finally, 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., reach a consensus). If 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. Note that the local cache here is the system memory created in the storage layer, and the local storage here is the hard disk space created in the storage layer for data storage. In this way, when a consensus node in the core consensus network crashes (i.e., is down) or the system fails, the data in the system memory will not disappear and the data will not be unable to be read. That is, the consensus node can still read the data through the local storage created in the storage layer.

[0139] It should be understood that in the above-mentioned blockchain system, any two blockchain nodes in any consensus network (e.g., consensus network 100a, consensus network 200a, or consensus network 300a) can form a peer-to-peer (P2P) network. This peer-to-peer network can use the P2P protocol, which is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any device, such as a server or terminal, can join and become a blockchain node. Each blockchain node can include a hardware layer, a middle layer, an operating system layer, and an application layer.

[0140] It is understood that the embodiment of the present application can configure a blockchain node for any role (for example, any individual user, any enterprise, any organization, etc.) that accesses the blockchain network through the target consensus node in the target chain network.Figure 2 In the business network 400a shown, business node 110a, business node 110b, business node 110c, business node 110d, ..., business node 110n can have a one-to-one correspondence with the corresponding roles that need to access the blockchain network.

[0141] It is understandable that when the consensus network 100a is used as the target chain network, the consensus nodes in the target chain network (for example, the target consensus node, which can be Figure 2 The consensus node 10a shown can provide registration and authorization services for the corresponding roles (or corresponding objects) that access the target chain network through the target chain network entrance, and can then perform identity management and permission management on the corresponding roles (i.e., corresponding objects) that need to access the above-mentioned blockchain network (for example, the above-mentioned target chain network, the first chain network, or the second chain network) in the target chain network. In addition, the target consensus node located in the target chain network can also be used to manage the relevant metadata information in the above-mentioned 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 traffic at the chain entrance corresponding to the first chain, control the number of consensus nodes participating in the consensus on each chain, etc.

[0142] For example, when developers and tax business participants need to deploy a smart contract corresponding to a second business on the second chain, they can access the second chain network through the chain entry corresponding to the second chain (i.e., the second chain entry), and further use the contract template reading method in the cross-chain reading contract on the second chain to read the application contract template corresponding to the second business from the target chain indicated by the contract template reading method, so as to deploy the smart contract corresponding to the second business on the second chain based on the read application contract template. In this way, when subsequent tax business participants need to execute the second business on the second chain, they can use the smart contract corresponding to the second business that has been deployed to execute the corresponding second business.

[0143] It should be understood that when the consensus network 200a is used as the first chain network, the consensus nodes in the first chain network (for example, the first consensus node, which can be Figure 2The consensus node 11b shown can be used to provide first services. The first services here can include, but are not limited to, ticket services associated with the above-mentioned electronic tickets, which can specifically include electronic ticket issuing services, electronic ticket circulation services, electronic ticket red stamping services, electronic ticket archiving services, and other services related to electronic tickets.

[0144] In addition, it can also be understood that when the above-mentioned consensus network 300a is used as the above-mentioned second chain network, the consensus nodes (for example, the above-mentioned second consensus nodes, which can be Figure 2 The consensus node 12b shown can be used to provide second services (for example, credit services, in-out loss services, enterprise qualification services, social services, credit purchase services and tax refund services, and lottery services) associated with the above-mentioned first services.

[0145] It can be understood that since each entity object can correspond to a blockchain node, the embodiments of the present application can take the entity object as an example for the above-mentioned enterprise user (i.e., the above-mentioned enterprise), and at this time, the blockchain node associated with each enterprise user can be the same blockchain node (for example, the above-mentioned consensus node 11b). Figure 2 The business node 110c shown can interact with the user terminals corresponding to a plurality of enterprise users. For example, in the above-mentioned blockchain system, the first services (such as electronic ticket issuing services, electronic ticket circulation services, electronic ticket red stamping services, and other services related to electronic tickets) requested by each enterprise user can be collectively referred to as a transaction service. Among them, when the above-mentioned enterprise user is an issuing enterprise A requesting to issue a ticket through the first chain network (for example, the above-mentioned consensus network 200a), the business node 110c can interact with the consensus node (for example, the consensus node 11b) in the consensus network 200a to request to complete the corresponding transaction. Figure 2 The business node 110c shown interacts with the consensus nodes (for example, the consensus node 11b) in the consensus network 200a to request to complete the corresponding transaction; similarly, the issuing enterprise B can also interact with the consensus nodes (for example, the consensus node 11b) in the consensus network 200a through the business node 110c to request to complete the corresponding transaction. Figure 2 The business node 110c shown interacts with the consensus nodes (for example, the consensus node 11b) in the consensus network 200a to request to complete the corresponding transaction; similarly, the issuing enterprise B can also interact with the consensus nodes (for example, the consensus node 11b) in the consensus network 200a through the business node 110c to request to complete the corresponding transaction. Figure 1 The business node 110c shown interacts with the consensus nodes (for example, the consensus node 11b) in the consensus network 200a to request to complete the corresponding transaction.

[0146] It can be understood that the embodiment of the present application can collectively refer to the entity objects (for example, billing enterprise A, billing enterprise B, ..., billing enterprise C) that send transaction business requests to the first chain network for the above-mentioned electronic invoice business as first business objects, and can refer to the blockchain nodes (for example, the above-mentioned business node 110c) associated with the first business objects (for example, billing enterprise A, billing enterprise B, ..., billing enterprise C) in the business network (for example, the above-mentioned business network 400a) as first business nodes, and can also refer to the blockchain nodes that obtain the electronic invoice issuance business indicated by the transaction business request in the core consensus network (for example, the above-mentioned consensus network 200a as the first chain network) as the above-mentioned first consensus nodes.

[0147] It is understandable that when the first consensus node associated with the above-mentioned first business object receives a transaction business request associated with the bill business, the transaction business request initiated by the first business object can be forwarded to the first consensus node, so that the first consensus node can perform legitimacy verification on the transaction business request initiated by the first business object. In this way, the first consensus node can add the transaction business requested by the first business object (for example, the above-mentioned bill business) to the transaction pool when the legitimacy verification is passed, so that the transaction data associated with the transaction business (for example, the above-mentioned bill business) can be packaged into blocks in the future, so as to perform block consensus between the consensus nodes in the consensus network 200a, so that after the block consensus is passed, 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 based on the above-mentioned distributed storage.

[0148] For further understanding, please see Figure 2 , Figure 2 This is a scenario diagram of a blockchain electronic bill platform based on multiple blockchains provided by 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. It should be understood that in the blockchain electronic bill platform, in order to reduce the complexity of on-chain data storage, a new multi-chain system based on blockchain electronic bills is proposed, and the multi-chain system mainly involves Figure 2 The blockchain electronic bill three-chain network shown. Figure 2 As shown, the blockchain electronic bill triple-chain network deploys a management chain, a bill chain, and an application contract chain. The management chain can be the target chain, the bill chain can be the first chain, and the application contract chain can be the second chain.

[0149] It is understood that in business scenarios where blockchain is used as the core data flow for blockchain electronic invoices, the mutual collaboration between the management chain, the invoice chain, and the application contract chain can provide the entire blockchain electronic invoice platform with the functional characteristics of independently executing different businesses, thereby constructing a secure and efficient business flow system under the premise of the mutual collaboration of the three chains. It should be understood that here, taking the multi-chain system as a three-chain system as an example, under this three-chain system, the management chain, the invoice 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 invoice chain, and different from the consensus node used to maintain the application contract chain.

[0150] like Figure 1 As shown in the figure, 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. Figure 2 In the case where the first cross-chain reading contract is deployed on the bill chain shown, the consensus node participating in maintaining the bill chain (i.e. 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 association information on the management chain. Figure 2 When a second cross-chain reading contract is deployed on the application contract chain shown, the consensus node participating in maintaining the application contract chain (i.e., the above-mentioned second consensus node) can confirm the business authority by cross-chain reading the business-related information on the management chain through the second cross-chain reading contract. It can also perform corresponding derivative business (i.e., the above-mentioned second business, for example, the above-mentioned 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.

[0151] For example, the management chain here can be used to provide management functional characteristics for the entire blockchain electronic bill platform, and the bill chain here can provide the functional characteristics of bill business (i.e., the first business) of different business authority types for the entire blockchain electronic bill platform. It should be understood that in the embodiment of the present application, in order to ensure the security and independence of the electronic bill written into the bill chain, the embodiment of the present application proposes that another blockchain (i.e., Figure 2 The application contract chain shown in the figure can provide a more standardized, flexible and fully functional derivative business (i.e. the second business mentioned above). That is, the application contract chain here can provide the entire blockchain electronic bill platform with the functional characteristics of conducting derivative business based on the core data in the electronic bill.

[0152] For ease of understanding, the core consensus network where the management chain is located (i.e. the above management chain network) is used as the above Figure 1 Taking the consensus network 100a shown as an example, the consensus nodes participating in maintaining the management chain can be the above-mentioned management consensus nodes. Figure 2 As shown, there are multiple smart contracts deployed on the management chain, and these smart contracts can run on the management consensus node. Specifically, it can be understood that the multiple smart contracts here can specifically include Figure 2 The object rights management contract, object identity management contract, metadata management contract and internal management contract shown in the figure should be understood as the smart contracts deployed on the management chain are Figure 2 The internal participants shown (i.e., tax management departments) are determined by the corresponding management contract templates deployed on their own chains (i.e., management chains).

[0153] It is understood that the aforementioned tax administration department can exercise management responsibilities through the management consensus node deployed in the management chain network. For example, these management responsibilities may include managing internal government information (e.g., information on tax administration personnel), managing the business logic rules of the overall business (e.g., the derivative business contracts running on the application contract chain that execute the business logic of the derivative business), managing the metadata information of the overall business (e.g., access traffic at the entrances of each chain in the three-chain system), and managing the identities and permissions of participants in the overall business (e.g., individual users, corporate users, tax business participants, and other business objects). It should be understood that within the blockchain network corresponding to the overall business, the management chain maintained by the management consensus node is a relatively stable blockchain with the smallest data size and the highest security.

[0154] In addition, for ease of understanding, Figure 2 The core consensus network where the bill chain shown is located (i.e. the above bill chain network) is the above Figure 2 Taking the consensus network 200a shown as an example, the consensus node participating in maintaining the bill chain can be the first consensus node mentioned above. Figure 2 As shown, there are multiple smart contracts deployed on the bill chain, and these smart contracts can run on the first consensus node. Specifically, it can be understood that the multiple smart contracts here can specifically include Figure 2 The electronic bill issuance contract, electronic bill circulation contract, electronic bill redemption contract, electronic bill archiving contract and the first cross-chain reading contract are shown. Similarly, it should be understood that these smart contracts deployed on the bill chain are Figure 2 The internal participants shown (eg, the tax department associated with the electronic invoice data center) are determined by the corresponding invoice business contract template deployed on the management chain.

[0155] It is understood that the first consensus node deployed in the bill chain network can maintain the business logic of the electronic bill throughout its entire lifecycle through the bill chain. For example, the bill chain can manage the entire lifecycle of all issued electronic bills. For example, the entire lifecycle of an electronic bill here includes the issuance, circulation, and reimbursement of electronic bills. It should be understood that within the blockchain network corresponding to the overall business, the bill chain maintained by this first consensus node has the characteristics of high performance and low latency.

[0156] Similarly, for ease of understanding, the core consensus network where the application contract chain is located (that is, the above-mentioned application contract chain network) is used as the above Figure 2 Taking the consensus network 300a shown as an example, the consensus node participating in maintaining the application contract chain can be the second consensus node mentioned above. Figure 2 As shown, there are multiple smart contracts deployed on the application contract chain, and these smart contracts can be run on the second consensus node. Specifically, it can be understood that the multiple smart contracts here can specifically include Figure 2 The virtual machine compatible contract, open contract deployment contract, derivative business contract and second cross-chain reading contract are shown.

[0157] It is understandable that the second consensus node deployed in the application contract chain network can carry the derivative business corresponding to the variable bill business through the application contract chain. For example, the derivative business here can specifically include the above-mentioned credit investigation business, the above-mentioned qualification identification business, etc. It should be understood that in the blockchain network corresponding to the overall business, the application contract chain maintained by the second consensus node can support Figure 2 The government cooperation departments and alliance chain partners shown (i.e. Figure 2 business related departments shown), through Figure 2 The tax application contract (open contract deployment contract) shown indirectly calls the second cross-chain reading contract to use the management application contract template read across the chain to develop smart contracts related to derivative business (for example, Figure 2) and can be deployed on the application contract chain after review by the tax administration department. It should be understood that smart contracts deployed on the application contract chain can achieve flexible upgrades and changes through virtual machine compatible contracts. It should be understood that within the blockchain network corresponding to the overall business, the second consensus node can achieve cross-chain interaction through the second cross-chain read contract on the application contract chain. For example, the second cross-chain read contract can read the aforementioned core data from the bill chain to execute derivative business. This means that the application contract chain maintained by the first consensus node has the highest degree of openness compared to the management chain and bill chain, supports complex smart contract logic, has a large number of participants and is constantly changing, and has relatively lower performance than the bill chain.

[0158] Among them, it is understandable that Figure 2 In the three-chain network of blockchain electronic bills shown, the consensus algorithm used by the management chain is different from the consensus algorithm used by the bill chain and the consensus algorithm used by the application contract chain.

[0159] Specifically, 1.1) the consensus algorithm associated with the management chain is an immediate deterministic consensus algorithm, for example, the immediate 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. It should be understood that the management chain is the 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 Figure 2 The tax administration departments shown are involved in management.

[0160] It should be understood that the internal parties associated with this management chain can be Figure 2 For example, when the tax management department participates in the management chain as an internal participant, it can manage some of its internal states 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 auditors, etc. among these personnel in the tax management department. In addition, when the tax management department participates in the management chain as an internal participant, it can also manage some parameters in the three-chain system through the internal management contract on the management chain. For example, it can manage Figure 2The access traffic parameters corresponding to the access traffic at the bill chain entrance shown can be restricted. For example, a time-sharing access mechanism can be used to control the access traffic at the bill chain entrance within certain time periods to no more than the access traffic threshold. For another example, when the tax administration department participates in the management chain as an internal participant, it can also use the internal management contract on the management chain to limit the node quantity parameters corresponding to the number of consensus nodes on each chain participating in the consensus.

[0161] 1.2) The consensus algorithm associated with the bill chain is another instant deterministic consensus algorithm. For example, the instant deterministic consensus algorithm here can be the 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. It should be understood that the consensus nodes in the bill chain network can be managed by the aforementioned tax administration department. For example, 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 aforementioned management chain. For another example, the tax bureau terminal corresponding to a specific tax personnel in the tax administration department can participate in the formation of the bill chain network.

[0162] It should be understood that the biggest difference between the TBFT consensus algorithm and the PBFT consensus algorithm is that the PBFT consensus algorithm has a fixed leader node (i.e., the master node) for packaging transactions in the transaction pool. When the leader node fails, the view-change subprotocol (i.e., a master node switching subprotocol) is used to replace the leader node. In the TBFT consensus algorithm, the leader node is rotated based on a rotation mechanism. For example, when the current node is the leader node, it will automatically rotate to the next node after submitting X blocks (the value of X is configurable). This means that the consensus nodes in the bill chain network corresponding to the bill chain can be used to continuously produce blocks.

[0163] 1.3) The consensus algorithm associated with the application contract chain is another instant deterministic consensus algorithm. For example, the instant deterministic consensus algorithm here can be a PoS (proof-of-stake) consensus algorithm. Through this proof-of-stake consensus algorithm, the network security of the application contract chain network where the application contract chain is located can be maintained, and the status of a proposed block to be put on the chain can be immediately determined through this proof-of-stake consensus algorithm. It is understandable that the consensus nodes in the application contract chain network can be composed of Figure 2The tax administration departments and government cooperation departments and large participating institutions (i.e. the large enterprises in the aforementioned alliance chain, which are the aforementioned Figure 2 For example, the tax personnel in the tax administration department (for example, Figure 2 The tax business participants shown in the figure can read the bill information of the electronic bill written on the bill chain through the consensus node in the application contract chain network, so as to perform derivative business related to the bill business through the bill information read across the chain. For example, the bill information read across the chain can be used to identify the qualifications or credit of the billing company requesting the bill, so as to obtain the qualification data or credit data of the billing company. It should be understood that Figure 2 As shown, the tax business participants here are Figure 2 When the application contract chain entrance shown is connected to the application contract chain network, the Figure 2 The second cross-chain reading contract on the application contract chain shown is from Figure 2 The bill chain shown reads the core data in the electronic bill requested based on the derivative business, so as to use the read core data to carry out the corresponding derivative business on the application contract chain.

[0164] It should be understood that in the embodiment of the present application, there is no need to directly transfer a large number of electronic bills generated on the bill chain across the chain to the application contract chain. Instead, some of the authorized and visible bill information (i.e., the aforementioned core data) of these electronic bills generated on the bill chain are transferred across the chain to the application contract chain. This can fundamentally ensure the privacy and security of these electronic bills recorded on the bill chain.

[0165] It can be seen from this that for tax business participants requesting access to the above-mentioned application contract chain, different core data can be read across the bill chain according to the different derivative businesses requested (that is, bill information with different data content can be obtained from the above-mentioned electronic bills).

[0166] It should be understood that the following differences exist with respect to smart contracts in the blockchain electronic bill triple-chain network:

[0167] 2.1) It should be understood that Figure 2 The management chain shown can support a specific language smart contract engine. The above management consensus node can deploy a specific language smart contract on the management chain through the specific language smart contract engine. For example, the above Figure 2 The object rights management contract, object identity management contract, metadata management contract, and internal management contract shown are shown. It should be understood that these smart contracts can be developed and managed by specific tax management personnel in the tax management department.

[0168] 2.2) If Figure 2 The bill chain shown has built-in smart contracts for specific bill business logic. These smart contracts (for example, Figure 2 The electronic bill issuance contract, electronic bill circulation contract, electronic bill redemption contract, electronic bill archiving contract and first cross-chain reading contract shown in the figure can be upgraded as the bill business is updated. For example, 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. This means that 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 doing 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.

[0169] 2.3) The application contract chain supports multi-language, Turing-complete smart contracts for developers, such as Figure 2 As shown, when developers access the application contract chain through the application contract chain entrance, they can use the virtual machine compatibility contract to be compatible with mainstream EVM virtual machines, so that they can deploy and run various new business contracts on compatible virtual machines. For example, a derivative business contract associated with a derivative business (for example, the above-mentioned lottery business) can be deployed on the application contract chain. For another example, a derivative application contract associated with another derivative business (for example, the above-mentioned tax refund business) can be deployed on the application contract chain.

[0170] It should be understood that, as mentioned above Figure 2 As shown in the figure, in the blockchain electronic bill three-chain network, no cross-chain reading contract is deployed on the management chain, so at this time, the management chain does not have cross-chain capabilities. Figure 2 The bill chain and application contract chain shown are both deployed with cross-chain reading contracts, so they have cross-chain capabilities.

[0171] Specifically, the consensus node associated with the bill chain (for example, the first consensus node mentioned above) can be Figure 2 The first cross-chain reading contract shown reads part of the management chain information from the management chain. For example, 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 association information used to confirm the business authority of the first business object can be read from the management chain, and the key bill information used for issuing electronic bills (for example, electronic invoices) can also be read from the management chain.

[0172] Among them, 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 determining that the business authority is the billing authority type (for example, the updated electronic bill template recorded in the management).

[0173] In addition, the consensus node associated with the application contract chain (e.g., the second consensus node mentioned above) can be Figure 2 The second cross-chain reading contract shown reads part of the management chain information from the management chain, for example, it can read the data used for depositing from the management chain. Figure 2 The business participation permission certificate of the authorization object at the application contract chain entry shown can also read the second business association information used to authenticate the business object requesting to execute the derivative business from the management chain, and can also read partial bill chain information from the bill chain (for example, reading the partial authorized visible bill information in the electronic bill associated with the derivative business from the bill chain). It should be understood that both the partial management chain information and the partial bill chain information read by the second consensus node from the management chain can be used to carry out the above-mentioned derivative business.

[0174] It should be understood that Figure 2 As shown, in the blockchain electronic bill three-chain network, the public network participants associated with the management chain can be Figure 2 Individual users and corporate users as shown. Figure 2 As shown, the public network participants associated with the bill chain can be Figure 2 The local electronic invoice data flow system shown here specifically includes local electronic invoice business issuance systems (for example, local tax bureau systems), electronic invoice issuance service providers, large enterprise finance and taxation related systems, etc. Figure 2 As shown, the public network participants associated with the application contract chain can be Figure 2 Tax business participants and developers shown.

[0175] Specifically, 3.1) the chain entry associated with the management chain can be Figure 2 The management chain entry is shown. Figure 2 When individual users (e.g., user A) and corporate users (e.g., corporate B) are participants in the public network, they can access the management chain through the management chain entrance, and then perform identity registration and identity authorization services through the management chain. 3.2) The chain entrance associated with the bill chain can be Figure 2 The bill chain entry shown. Figure 2When the local electronic bill data flow systems (e.g., large enterprise users) shown in the figure act as public network participants, they can access the bill chain through the bill chain entry, and then perform electronic bill issuance, electronic bill circulation, electronic bill redemption, and electronic bill archiving services through the bill chain. 3.3) The chain entry associated with the application contract chain can be Figure 2 The application contract chain entry shown. Figure 2 When the tax business participants and developers shown as public network participants can access the application contract chain through the application contract chain entrance, and then can deploy derivative business contracts on the application contract chain to execute derivative business related to electronic invoices through the deployed derivative business contracts. It should be understood that Figure 3 to Figure 8 The developer shown 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.

[0176] Among them, it is understandable that Figure 3 The management chain entrance shown may specifically be a tax administration department entrance, through which the identity identification and business guidance of individuals, legal persons, and entities that need to access the management chain can be performed.

[0177] Among them, it is understandable that Figure 3 The bill chain entry shown 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 by a certain business object (for example, the first business object, which can be the above-mentioned enterprise B) can be received. In this way, 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 permissions 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 permission contract in the management chain. Then, when the verification is passed, enterprise B as the first business object can be determined as the authorized object, and then the business permissions 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 permissions of enterprise B as the authorized object meet the status requirements of the object permission management contract in the management chain.

[0178] For example, the first consensus node can determine whether the access identity and access authority 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 entrance, and then determine that the identity authentication of the data sender (i.e., Enterprise B) who needs to access the bill chain is completed 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. Figure 3 The entry of the bill chain shown stores the registration data information of each authorized object synchronized from the management chain. The registration data information here may include but is not limited to object access identity registration information and object access permission registration information. For example, 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 permission registration information here includes the request accumulation threshold (for example, the maximum concurrent request accumulation) configured by the management consensus node for the electronic bill business entry of the bill chain through the internal management contract. The above-mentioned 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.

[0179] Among them, it is understandable that Figure 1 The application contract chain entry shown may specifically be a tax derivative business entry, through which a business object (for example, a second business object, which may be Figure 2 The derivative business associated with the bill business requested by the tax business participant shown in the figure. Figure 2 The tax business participants and developers shown can, after obtaining the business participation license certificate of the authorized object issued by the tax management department, verify the business participation license certificate submitted by the second business object (for example, the tax business participant or developer) through the application contract chain entrance, and then allow the second business object to access the application contract chain when the verification is successful, so as to execute derivative business related to the aforementioned bill business on the application contract chain.

[0180] Among them, such as Figure 4 As shown, the internal participants in the maintenance management chain can be Figure 4 The tax management department shown here is mainly used to configure and manage internal status parameters on the management chain. It 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 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.).

[0181] Among them, such as Figure 4 As shown, the internal participants involved in maintaining the bill chain can be Figure 1 The electronic bill data center shown here can specifically be an electronic invoice data center. This electronic bill data center (e.g., an electronic invoice data center) can be used to perform off-chain backup, statistics, data analysis, and review of the massive amount of ledger data recorded on the bill chain (e.g., the electronic bill flow generated by the above-mentioned real-time bill business flow). Specifically, the electronic bill data center can be used to count the number of invoices issued by time, and then, based on the counted number of invoices issued by time, risky bills (e.g., risky invoices) and risky enterprises can be identified. It can also perform data analysis on relevant financial and economic data.

[0182] Among them, such as Figure 4 As shown, the internal participants involved in maintaining the application contract chain can be Figure 4 It should be understood that, in addition to the tax administration department, other internal participants in maintaining the application contract chain, including other departments (i.e., the aforementioned government cooperation departments) and participants (i.e., the aforementioned business-related departments) in the system alliance chain, can further execute corresponding derivative businesses through the derivative business contracts on the application contract chain when accessing the application contract chain. It is understandable that Figure 4 The government cooperation departments and business-related departments shown as tax business participants have the advantage of accessing the application contract chain in that they can flexibly run various scalable derivative businesses in a complete smart contract declaration cycle to ensure the flexibility of business changes, while not needing to directly contact the core data of the electronic bills on the above-mentioned bill chain, thereby ensuring the data privacy and core data security on the bill chain. This means that 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 read the cross-chain reading method in the second cross-chain reading contract). For example, 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. For electronic bills that are electronic invoices, the bill data here can specifically be 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.

[0183] In some other feasible embodiments, in order to increase the data privacy of the electronic bills located on the bill chain, the second consensus node can also request the first consensus node corresponding to the bill chain to read the electronic bills associated with the derivative business (for example, the electronic bills 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 (for example, the target chain identifier here is the chain identifier corresponding to the bill chain), and then the bill information associated with the derivative business can be returned to the second consensus node as the aforementioned authorized visible core data in the bill information of the read electronic bill. It should be understood that at this time, for the second consensus node, it is impossible to know other bill information in the electronic bill that is not related to the derivative business, and it is even more impossible to touch other electronic bills on the bill chain that are not related to the derivative business (for example, the electronic bills issued by Enterprise D). In this way, the privacy security and reliability of the bill data stored on the bill chain can be ensured.

[0184] Among them, it is understandable that Figure 4 The three blockchain electronic bill networks shown can all have built-in corresponding smart contracts.

[0185] Among them, 4.1) for the smart contract built into the management chain, such as Figure 4 As shown, the object identity management contract embedded in the management chain can specifically be a user management contract, which manages the identities of accessors (e.g., public network participants) and participants (e.g., internal participants) across the entire three-chain system. It should be understood that accessors and participants here can specifically include tax management personnel (referred to as administrators), government collaboration departments, local tax bureaus, invoicing service providers, reimbursement service providers, tax audit departments, and so on. Furthermore, the object permission management contract embedded in the management chain can specifically be an enterprise identity management contract, which manages the business permissions and tax status of certain enterprises. Similarly, the metadata management contract embedded in the management chain can specifically be a tax metadata management contract, which manages metadata information such as tax rules. For example, it can centrally manage contract modules, tax calculation logic, and the latest policy rules across the three-chain system. By analogy, the internal management contract built into the management chain can be used to manage some internal states of the tax administration department, and can manage some internal parameters of each chain under the three-chain system. For example, the internal management contract can be used to limit the access traffic parameters at the above-mentioned bill chain entrance (for example, the electronic invoice business entrance), as well as the number of consensus nodes in the three-chain system.

[0186] Among them, 4.2) for the smart contract built into the bill chain, such as Figure 4As shown, the smart contract built into the bill chain can include a cross-chain reading contract and a bill business contract associated with the life cycle of the electronic bill. The cross-chain reading contract here can be Figure 4 The first cross-chain reading contract shown, and the bill business contract here can specifically include Figure 4 The electronic bill issuance contract for providing electronic bill issuance services, the electronic bill circulation contract for providing electronic bill circulation services, the electronic bill red-offset contract for providing electronic bill red-offset services, and the electronic bill archiving contract for providing electronic bill archiving services are shown. Among them, the first cross-chain reading contract can be used to read metadata information on the management chain across the chain to update some business parameters on the bill chain. For example, when the metadata information read across the chain is an updated electronic bill template, 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.

[0187] Among them, 4.3) for the smart contract built into the application contract chain, such as Figure 4 As shown, 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 a tax derivative business participant (i.e., a derivative business object, for example, Figure 4 The tax business participants shown in the figure) participate in the deployment of various contracts (for example, Figure 4 The virtual machine compatible contract, tax application contract and derivative business contract shown in the figure). For example, the derivative business contract here can specifically be a credit investigation business contract based on electronic invoices, through which the credit investigation business contract can be analyzed to obtain the credit investigation data of a certain enterprise. For another example, the derivative business contract here can also specifically be an on-chain lottery business contract and talent incentive contract and tax refund business contract deployed to encourage invoicing. Among them, it can be understood that 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). In addition, 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 cross-chain.

[0188] It should be understood that for the above Figure 4As for the management chain shown, it is mainly used to process management business flows with small data volume and relatively constant status. The openness of the entire management chain is relatively low and can be used for internal management of some tax data. Figure 4 As for the bill chain shown, it can be used to process some real-time bill business flows with a high-frequency request state for a long time. The entire bill chain is relatively open and can allow relevant authoritative institutions in the life cycle of the electronic bill to participate in the corresponding bill business. For example, the consensus node corresponding to the agent service provider can be allowed to issue an electronic bill for a user who is currently requesting an invoice. In addition, for Figure 4 As for the application contract chain shown, the amount of data can be unlimited, and the frequency of business changes fluctuates relatively greatly. It is mainly possible to process various types of cooperative businesses, derivative businesses, exploratory businesses, etc. through the application contract chain. It should be understood that 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 businesses, etc. It should be understood that in the embodiment of the present application, considering that the application contract chain has a high degree of openness and flexibility in business changes, the smart contract built into the application contract chain can have more contract security restrictions when executed. For example, the number of contract execution steps can be limited (for example, for the above Figure 4 For the derivative business contract shown, it is possible to limit which contract methods in the derivative business contract the current business object (i.e., the second business object mentioned above) can access, and to restrict the storage resource data required to access the derivative business contract (i.e., the call of the smart contract on the application contract requires a certain amount of storage resource data).

[0189] It can be understood that the consensus node under the three-chain system involved in the embodiment of the present application can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.

[0190] It should be noted that when the consensus node in the embodiment of the present application obtains the registration data information, business participation license certificate, bill information in the electronic bill 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, bill information in the electronic bill 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.

[0191] In addition, it can be understood that in the specific implementation of this application, 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.). When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the permission or consent of business objects such as users, enterprises, and institutions, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0192] The specific process of executing bill business on the bill chain and the specific process of executing derivative business related to the bill business on the application contract chain can be found below. Figure 4 The corresponding embodiment.

[0193] For further information, see Figure 4 , Figure 2 This is a multi-blockchain data processing method provided by the embodiment of the present application, such as Figure 4 As shown, the method can be executed by the first consensus node in the first chain network. For example, the first consensus node can be the Figure 4 Any consensus node in the consensus network 200a shown. The method may specifically include the following steps S101-S103.

[0194] 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 independent of the first chain network; the first chain is different from the target chain;

[0195] It is understood that the first chain network involved in the embodiments of the present application is a consensus network in the aforementioned three-chain network of blockchain electronic invoices. Furthermore, it is understood that in the embodiments of the present application, the first chain network is deployed in a relatively secure private cloud, and each consensus node within the first chain network in the private cloud runs a blockchain consensus protocol based on the aforementioned TBFT consensus algorithm. Thus, through the consensus mechanism corresponding to the aforementioned blockchain consensus protocol, access security between the consensus nodes in the first chain network can be ensured.

[0196] However, for public network participants in the public network (for example, Figure 4 For individual users and corporate users (as shown in the figure), if you need to access the FirstChain network, you must first pass the above Figure 4The first chain entrance shown performs identity verification and permission verification on a public network participant requesting to access the first chain network, to ensure the access security of the public network participant accessing the first chain network.

[0197] For ease of understanding, the embodiments of the present application can collectively refer to the public network participant requesting to access the first chain network as a first business object, and then the first business object can be authenticated by the first chain entrance.

[0198] It can be understood that in the embodiments of the present application, the chain entrance corresponding to the first chain network can be the first chain entrance described above (here, the first chain entrance can also be an electronic invoice business entrance); the first chain entrance stores registration data information of an authorized object synchronized from the target chain by the first cross-chain reading contract at the first cross-chain reading timestamp by the first consensus node;

[0199] Specifically, the first consensus node can obtain a first business processing request sent by a first business node corresponding to the first business object based on the first business through the first chain entrance of the first chain network; the first business processing request carries transaction business data submitted by the first business object for the first business, and first signature information of the first business object; the first signature information is obtained by signing the transaction business data by the first business node associated with the first business object using the first private key information of the first business object; the first private key information of the first business object is obtained by the first business object after identity registration through an object identity management contract in the target chain; further, 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 authorized object stored in the first chain entrance, to obtain a signature verification result of the first business object; further, the first consensus node can 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 the first business associated with the first business object based on the transaction business data; further, the first consensus node can call the first cross-chain reading contract based on the first business to read first business association information associated with the first business from the target chain. It should be understood that the first business here can include but is not limited to a ticket business associated with an electronic ticket, a certificate business associated with an electronic certificate, and a prescription business associated with an electronic prescription, i.e., the embodiments of the present application can construct a three-chain system adapted to different business scenarios according to different business application scenarios. For ease of understanding, the first business is taken as a ticket business associated with an electronic ticket as an example to describe the specific process of executing the ticket business in the first chain network.

[0200] For ease of understanding, further, Figure 4 , Figure 4This is a schematic diagram of a scenario in which identity authentication is performed through a chain entry, as provided in an embodiment of the present application. Figure 4 The user 43b can be the first business object mentioned above, that is, at this time, the user 43b is the public network participant who requests to access the first chain network 400a. It should be understood that in the embodiment of the present application, the user terminal 43a used by the user 43b can be the first business node corresponding to the first business object. It should be understood that the first business node here can be the above Figure 4 The business node in the business network 400a shown in the figure, at this time, 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 (i.e., the first business object) can be added to Figure 4 In the first business processing request shown, the first business processing request is sent to Figure 4 The first chain network 400a is shown corresponding to the chain entry 42a.

[0201] It should be understood that the chain entrance 42a here is the first chain entrance. Figure 2 As shown, the first chain entry can be used to store Figure 4 The registration data information of the authorization object shown in the figure may include Figure 4 Shown are the public key certificate A1 of the authorized object A, the public key certificate B1 of the authorized object B, ..., and the public key certificate N1 of the authorized object N.

[0202] It should be understood that the registration data information of the authorized object stored at the chain entrance 42a is obtained by the consensus node in the first chain network 400a from Figure 4 Since the consensus nodes in the first chain network run the TBFT consensus algorithm, under the premise that the leader node is rotated in the TBFT consensus algorithm, it is assumed that the leader node used for continuous block generation in the previous round is Figure 4 The consensus node 41c shown, and the leader node for continuous block generation in this round is Figure 2 If the consensus node 41d is shown, 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. Based on this, the registration data information of the authorization object stored at the chain entry 42a can specifically include the consensus node 41c that was historically used as the first consensus node through Figure 4 The first cross-chain read contract shown reads from the target chain (e.g. Figure 5The registration data information of the first type of authorization object synchronized on the target chain 42e shown in FIG. 4 (for example, the public key certificate A1 of the authorization object A and the public key certificate B1 of the authorization object B) may also include the consensus node 41d currently serving as the first consensus node through Figure 5 The first cross-chain read contract shown reads from the target chain (e.g. Figure 5 The registration data information of the second type of authorization object (for example, the public key certificate N1 of the authorization object N) synchronized on the target chain 42e shown in FIG. It should be understood that the registration data information of the first type of authorization object and the registration data information of the second type of authorization object here are mainly used to distinguish which ones are synchronized by the node as the first consensus node and which ones are synchronized by other nodes as the first consensus node.

[0203] It should be understood that in the embodiment of the present application, the timestamps of historical calls to the first cross-chain read contract by the consensus nodes in the first chain network 400a (for example, the aforementioned consensus node 41c and consensus node 41d) may be collectively referred to as the first cross-chain read timestamp, and the timestamps of current calls to the first cross-chain read contract by the consensus nodes in the first chain network 400a (for example, the consensus node 41d) may be collectively referred to 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 will not be limited here.

[0204] For ease of understanding, here we take 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 add the public key certificate N1 of the authorized object N synchronized from the target chain (for example, target chain 42e) to the first cross-chain reading timestamp through the identity authentication method in the first cross-chain reading contract. Figure 5 In the registration data information of the authorization object shown, it is possible to quickly authenticate the identity of the first business object currently requesting to execute the first business 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 400a.

[0205] For example, when the above-mentioned blockchain system is applied to the blockchain electronic bill scenario, when the first business is the above-mentioned bill business, 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).

[0206] It should be understood that, alternatively, the first chain entrance (such as the chain entrance 42a) involved in the embodiments of the present application also stores a request accumulation threshold synchronized from the target chain. The request accumulation threshold here is used to represent the access flow at the first chain entrance. It should be understood that the request accumulation threshold here includes but is not limited to the maximum concurrent request accumulation. It should be understood that the maximum concurrent request accumulation of the first service processing request obtained by the chain entrance 42a is specifically determined by the internal management contract running on the management consensus node in the target chain network 400b. It should be understood that in the embodiments of the present application, the internal management contract running on the target consensus node (for example, Figure 2 The internal management contract running on the target consensus node (for example,

[0207] For ease of understanding, the signature information of the user 43a (i.e., the first business object) can be collectively referred to as the first signature information in the embodiments of the present application, and the first signature information is obtained by the user 43a (i.e., the first business object) signing the foregoing transaction business data by using the private key information (i.e., the first private key information of the first business object) of the user 43a (i.e., the first business object). In this way, when Figure 5 When the chain entrance 42a shown in the figure obtains the first service processing request, the request accumulation corresponding to the first service processing request can be counted, and then the access permission verification (also referred to as the access permission verification) of the user 43b can be preliminarily completed when the request accumulation corresponding to the first service processing request does not reach the request accumulation threshold (for example, the maximum concurrent request accumulation). At this time, the first consensus node can further obtain the first signature information of the first business object from the first service processing request, and then quickly obtain the public key certificate of the authorized object (for example, Figure 5 The public key certificate A1 of the authorized object A, the public key certificate B1 of the authorized object B, …, and the public key certificate N1 of the authorized object N) from the registration data information of the authorized object stored in the chain entrance 42a, so as to verify the identity of the user 43b by using the obtained public key certificate. It should be understood that the embodiments of the present application can directly reject the first service processing request sent by the user 43b when the request accumulation corresponding to the first service processing request reaches the request accumulation threshold (for example, the maximum concurrent request accumulation), and generate a notification message for prompting the user 43b to wait for access.

[0208] It should be understood that the public key certificate of each authorization object here contains the public key information of the corresponding authorization object. In this way, the first consensus node can further search for the public key certificate of these authorization 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 to perform signature verification on the aforementioned first signature information through the first public key certificate and the first public key information, so that the signature verification result of the first business object can be obtained. 2) If it does not exist, that is, the first consensus node does not search for the public key certificate of user 43b in the public key certificates of these authorization objects to see whether the public key certificate of user 43b exists, 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.

[0209] It should be understood that 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.

[0210] Specifically, the first consensus node may use the certificate data information of the first public key certificate as the certificate information to be processed, and may 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; further, the first consensus node may use the certificate data information in the read public key certificate of the first business object as the target certificate information, and then may 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.

[0211] Optionally, it is understandable that when 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 using 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.

[0212] It should be understood that 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 (i.e. the above Figure 5 The object identity management contract in the corresponding embodiment) is obtained after the identity registration of the object data information (for example, the object data information here may specifically include the basic user data information of the above-mentioned user 43b, the transaction business that the above-mentioned user 43b needs to perform, and the business type of the transaction business, etc.) submitted by the business object requesting to register the corresponding transaction business (for example, the aforementioned first business); it should be understood that when the target consensus node successfully configures the public key certificate corresponding to the corresponding business for 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) can be used as the authorization object, and the public key certificate configured for the authorization object can be written into the target chain (for example, Figure 5 The target chain 41e shown is used to update the public key certificate of the business object at the chain entry (i.e., the aforementioned first chain entry) when the business object subsequently requests to execute the first business in the first chain network. As can be seen, the embodiment of the present application can update the registration data information of the authorization object synchronized from the target chain on demand based on the aforementioned cross-chain reading timestamp.

[0213] Furthermore, it should be understood that the target consensus node will be the authorized object (e.g. Figure 5 The public key certificate configured by the user 43b) shown is written into the target chain (for example, Figure 5 After the target chain 41e shown in FIG. 4 , the authorization object (eg, Figure 5 The private key information (i.e., the first private key information) configured by the user 43b shown in the figure is returned to the user 43b, so that the user 43b, when acting as the first business object, can use the first private key information to sign the transaction business data submitted by himself to obtain the first signature information. It can be seen that the first private key information of the first business object here is the first business object (for example, Figure 5 The user 43b shown in the figure is obtained after registering the identity through the object identity management contract in the target chain. Based on this, the first signature information here is obtained by the first business object (for example, Figure 5 The first business node associated with the user 43b) is connected to the first business object (eg, Figure 4 The first private key information of user 43b) shown is obtained by signing the aforementioned transaction data.

[0214] like Figure 5As shown, the first consensus node can authenticate the user 43b through the registration data information of the authorization object obtained from the chain entrance 42a, and then, when the identity authentication is successful, it can determine that the user 43b is the authorization object, so as to allow the user 43b to access the first chain network 400a as an accessor. It should be understood that at this time, 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, when the transaction weight verification is successful (that is, it is determined that there is no first business identical to the new transaction in the first chain network), the new transaction can be added to the transaction pool corresponding to the aforementioned real-time first business flow, and then, based on the first business in these real-time first business flows in the transaction pool, the call can be made. Figure 5 The first cross-chain reading contract shown reads the first business association information associated with these first businesses on the target chain 42e across the chain, and then the following step S102 can be further executed based on the first business association information read across the chain.

[0215] Specifically, the first consensus node can call the permission contract reading method in the first cross-chain reading contract based on the first business, and generate a contract to be sent to the target chain network (i.e. Figure 5 The target consensus node (e.g., consensus node 42a) in the target chain network 400b shown in FIG. 4 is a permission contract access request; the permission contract access request is used to instruct the target consensus node (e.g., consensus node 42a) to call the object permission management contract on the target chain to obtain 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 to further execute the following step S102.

[0216] 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 to the first chain; the first business execution result includes the business data indicated by the first business;

[0217] The first business association information includes a business permission type configured for the first business object, a business cumulative amount of the first business object with the business permission type within a business duration, and a business cumulative threshold. Specifically, the first consensus node can determine that the first business object has the first business processing permission when the first business association information determines that the business permission type of the first business object is an invoicing permission type and the business cumulative amount of the first business object with the invoicing permission type within the business duration does not reach the business cumulative threshold. Further, the first consensus node can obtain a contract call address and a contract call name associated with the invoicing permission type based on the first business processing permission, call a business data invoicing contract on the first chain through the contract call address and the contract call name, integrate transaction business data corresponding to the first business and ticket key information associated with the business data invoicing business in the first business, and issue an electronic ticket for the first business object based on the integrated ticket key information. The issued electronic ticket is used as the business data indicated by the first business. Further, the first consensus node can use the ticket key information, the business data, and the business data invoicing contract as a first business execution result of the business data invoicing business in the first business, and send a first block containing the first business execution result to a verification consensus node on the first chain to make the verification consensus node perform block verification on the first block to obtain a block verification result. The verification consensus node is a consensus node remaining in the first chain network except the first consensus node. It should be understood that the verification consensus node (i.e., the above-mentioned ticket verification consensus node) specifically refers to the consensus node remaining 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.

[0218] It should be understood that the ticket key information can include auxiliary metadata information in the metadata information read from the target chain, and the auxiliary metadata information includes a first business data template and a target tax calculation rule associated with the first business data template. The first business data template is a business data template after the second business data template is changed and chained by the target consensus node on the target chain calling the metadata management contract on the target 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 a business management object (here, the business association object can be the tax association department in the corresponding embodiment) associated with the target consensus node. Figure 5

[0219] It should be understood that the embodiments of the present application do not limit the specific number and type of the first business in the real-time business flow determined in the first chain network. For ease of understanding, the embodiments of the present application are described above​Figure 5 In the example shown, the first service requested by user 43a is the electronic invoice issuance service within the aforementioned invoice service. This illustrates how the business association information associated with the electronic invoice issuance service (i.e., the aforementioned first business association information) is retrieved from target chain 42e to further determine that user 43b's business permission is the first business processing permission. It should be understood that the first business processing permission here indicates that user 43b has the permission to invoke the first business execution contract on first chain 41e to execute the first business (e.g., the aforementioned electronic invoice issuance service).

[0220] It is understood that the first business related information here specifically includes the above Figure 2 The business authority type configured by user 43b shown in the figure, the business accumulation amount of user 43b with business authority type within the business duration, and the business accumulation threshold; the business authority type here is determined by the target consensus node through the above object authority management contract for requesting the first business Figure 6 It is configured by the user 43b shown (i.e., the above-mentioned first business object). When the first business is the aforementioned bill business, the business authority types here specifically include invoicing authority type, transfer authority type, red-off authority type, and archiving authority type. It should be understood that, optionally, when the first business is the aforementioned certificate business, the business authority types here specifically may include certificate issuance authority type, transfer authority type, and archiving authority type. It should be understood that, optionally, when the first business is the aforementioned prescription business, the business authority types here specifically may include prescription issuance authority type, transfer authority type, and 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.

[0221] Based on this, when the first business requested by user 43b to register with the target consensus node in the target chain network is the electronic invoice issuance business, the target consensus node can configure the type of corresponding business authority for user 43b as the above-mentioned business authority type (for example, configuring the invoicing authority type for calling the electronic invoice issuance contract on the first chain) through the object authority management contract, and configure the business accumulation amount and business accumulation threshold of user 43b with the business authority type (for example, invoicing authority type) within the business duration (for example, 1 hour), and then write the business authority type (for example, invoicing authority type) configured for user 43b, the business accumulation amount and business accumulation threshold of user 43b with the business authority type (for example, invoicing authority type) within the business duration (for example, 1 hour) as the aforementioned first business association information into the target chain (for example, Figure 6 Target chain 42e shown).

[0222] In this way, when 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 association 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). If not, it can be determined that the aforementioned user 43b has the first business processing authority corresponding to the first business, and then 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). It should be understood that in the embodiment of the present application, the issued electronic invoice may be collectively referred to as the business data indicated by the aforementioned first business.

[0223] Similarly, optionally, when the first consensus node determines that the business permission type of 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 user 43b with the transfer permission type within the aforementioned business duration has reached the business accumulation threshold (for example, when 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). If not, it can be determined that the aforementioned user 43b has the first business processing permission corresponding to the first business, and then 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 aforementioned user 43b (the electronic bill here can specifically be an electronic invoice) to the second business object. It should be understood that 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 user 43b is located).

[0224] By analogy, optionally, when the first consensus node determines that the business permission type of user 43b is the aforementioned red rebate permission type based on the first business association information obtained from the target chain, it can further determine whether the business accumulation amount of user 43b with the red rebate permission type within the aforementioned business duration has reached the business accumulation threshold (for example, when user 43b is a red rebate user, the business accumulation amount here specifically refers to whether the number of red rebates of the reimbursement user within 1 month has reached the maximum red rebate amount). If not, it can be determined that the aforementioned user 43b has the first business processing permission corresponding to the first business, and then the contract call address and contract call name associated with the red rebate permission type can be obtained based on the first business processing permission corresponding to the first business, so as to call the electronic bill red rebate contract on the first chain through the contract call address and contract call name, and issue a red invoice for the red rebate of the electronic bill issued to the aforementioned user 43b (the electronic bill here can specifically be an electronic invoice). It should be understood that the red invoice here can be used to correct the relevant bill information in the electronic invoice.

[0225] Similarly, optionally, when the first consensus node determines that the business authority type of the user 43b is the aforementioned archiving authority 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 authority 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). If not, it can be determined that the aforementioned user 43b has the first business processing authority corresponding to the first business, and then based on the first business processing authority corresponding to the first business, the contract call address and contract call name associated with the archiving authority type can be obtained, 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 issued to the above-mentioned user 43b (the electronic bill here can specifically be an electronic invoice). It should be understood that the first consensus node here can call the electronic bill archiving contract to cold store electronic bills that have expired for a long time (i.e., can no longer be circulated) or electronic bills that are less requested across chains, so as to release the ledger storage resources of the blockchain ledger corresponding to the bill chain.

[0226] It can be seen that the first business here includes at least one of the following transaction businesses: electronic bill issuance business, electronic bill circulation business, electronic bill red-offset 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-offset contract for executing the electronic bill red-offset 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-offset business is used to instruct the first consensus node to call the electronic bill red-offset contract on the bill chain to issue a red-ink invoice corresponding to the electronic invoice, and the red-ink invoice is used to correct the relevant bill information in the electronic invoice; the electronic bill archiving business is used to instruct the first consensus node to call the electronic bill archiving contract on the bill chain to cold store the electronic invoices on the bill chain that meet the bill archiving conditions.

[0227] It should be understood that, optionally, when the above-mentioned blockchain system is applied to the blockchain electronic prescription scenario, when the first business is a prescription business related to electronic prescriptions (for example, when user 43b requests to obtain the corresponding electronic prescription in the first chain network, etc.), 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). At this time, the first chain network corresponding to the first chain entrance can specifically be a prescription chain network. For another example, optionally, in the case where the above-mentioned blockchain system is applied to a blockchain electronic certificate scenario, when the first business is a certificate business related to an electronic certificate (for example, user 43b requests to obtain a corresponding electronic certificate in the first chain network, where the electronic certificate can specifically be an electronic skill certificate, etc.), 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). At this time, the first chain network corresponding to the first chain entry can specifically be a certificate chain network. It should be understood that the specific implementation method of executing the prescription business and the certificate business in the first chain network can refer to the above-mentioned description of the specific process of executing the bill business in the first chain network, and will not be further elaborated here.

[0228] Optionally, when writing the first business execution result into the first chain, the first consensus node may 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 indicate that the business data processing terminal has the function of clearing the business data from the first chain; it should be understood that the business data processing terminal here can be the above-mentioned Figure 6 The terminal corresponding to the electronic bill data center in the corresponding embodiment. In this way, when the first consensus node 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 bill analysis here specifically refers to the fact that the above-mentioned electronic bill data center can use the business data processing terminal to conduct off-chain statistics on a large number of electronic bills recorded on the first chain (for example, counting the number of time-sharing invoices issued by the above-mentioned user 43a as the invoicing enterprise), data analysis (for example, analyzing the invoice amount and invoice amount of the above-mentioned user 43a as the invoicing enterprise to make a risk assessment on the user 43a. For example, when it is determined that the user 43a belongs to a risky enterprise, 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), etc.

[0229] Step S103: upon obtaining a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, 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.

[0230] Specifically, when the first consensus node obtains a 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, 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 this embodiment of the present application, if the second business is a derivative business of the first business, then the cross-chain request data information can specifically be the derivative business data information of the derivative business.

[0231] For ease of understanding, the present application embodiment is combined with the above Figure 1 The first chain network 400a and the target chain network 400b are shown to illustrate how to achieve mutual cooperation between the three chains in the blockchain system. For further information, please refer to Figure 3 , Figure 7 This is a schematic diagram of a scenario of cross-chain interaction between three chains adopted in the embodiment of this application. Figure 7 The user 53a shown may be a second service object requesting to execute a second service, and the user terminal 53a used by the user 53a may be a second service node. The second service node here may be the same as the first service node or may be different from the first service node, which is not limited here. Figure 7 The chain inlet 52a shown is the second chain inlet, which can be the above-mentioned Figure 1 The tax derivative business entry in the corresponding embodiment. It should be understood that in the embodiment of this application, the tax derivative object (for example, Figure 3 The user 53b) shown in the figure can access the business participation license certificate issued by the tax administration department through the above management consensus node through the business participation license certificate Figure 8 A second chain network 500a is shown.

[0232] Among them, such as Figure 8 The chain entry 52a shown stores the business participation permission certificate of the authorization object synchronized from the target chain 42e. Figure 8 As shown, 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.Figure 1 The user 53b shown in FIG. 5 can add the target business participation license certificate to the target business participation license certificate configured by the aforementioned tax administration department through the target consensus node. Figure 1 The second business processing request shown is sent to the second consensus node (for example, Figure 1 The second consensus node 51d is shown in FIG. 5 , so that the second consensus node can determine whether the user 53b can access the second chain network 500a based on the business participation permission certificate of the authorization object stored at the chain entry 52a. For example, if the second consensus node finds a business participation permission certificate that is the same as the target business participation permission certificate at the chain entry 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 second business object) can be rejected.

[0233] Among them, it can be understood that the business participation permission certificate (referred to as the permission 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 permission certificate configured by the management consensus node for the user 53b will not be limited here.

[0234] like Figure 9 As shown, the second chain network includes multiple consensus nodes, which may specifically include consensus node 51a, consensus node 51b, consensus node 51c and consensus node 51d. It should be understood that the above-mentioned second cross-chain reading contract is running on all of these consensus nodes here. For ease of understanding, consensus node 51d is taken as the second consensus node, and the second cross-chain reading contract is running on the second consensus node as an example to illustrate that the second consensus node calls the second cross-chain reading 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 400a. For example, the second business here can be the above-mentioned qualification identification business. It should be understood that the first chain 41e is composed of these consensus nodes (for example, Figure 9 It is jointly maintained by consensus node 41a, consensus node 41b, consensus node 41c and consensus node 41d) shown.

[0235] Combined with the above Figure 9 As can be seen from the described embodiment, the first consensus node will write the business data obtained by executing the above-mentioned first business into the target chain 41e. In this way, at the second consensus node (for example, Figure 1When the consensus node 51d shown 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 can call the second cross-chain read contract to generate a cross-chain read request associated with the second business, and send the cross-chain read request to the first consensus node (for example, Figure 9 Consensus node 41d shown).

[0236] At this point, the first consensus node (e.g. Figure 3 The consensus node 41d shown in FIG4 can read the business data associated with the second business (for example, the qualification identification business) from the first chain 41e corresponding to the first chain network 400a according to the received cross-chain read request, and then return the core data in the read business data to the second consensus node (for example, Figure 3 It should be understood that the embodiment of the present application does not limit the amount of business data read across the chain.

[0237] For example, when the first business is a bill business, the first consensus node reads the business data associated with the second business from the first chain 41e, which 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 these read electronic bills can then be returned to the second consensus node for use in Figure 3 The second business requested by the user 53b is executed in the second chain network shown (for example, the corporate qualifications of the issuing company requesting the issuance of these electronic invoices can be identified through the core data of the electronic invoices obtained in batches).

[0238] In other words, the second consensus node can further execute the second business based on the core data in the aforementioned business data read across the chain, and can write the second business execution result corresponding to the second business into the second chain.

[0239] It should be understood that 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 be referred 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.

[0240] It can be seen that 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). In this way, in the business scenario where the core data of blockchain electronic bills (i.e., partially authorized and visible bill information on the first chain) flows, the first consensus node (e.g., the above-mentioned bill consensus node) can participate in maintaining the first chain in the first chain network, and the first chain is mainly used to store the above-mentioned first business execution results. For example, the first chain can be used to store the business data obtained by executing each first business in the real-time business flow. In addition, the second consensus node (e.g., the above-mentioned application 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 results. It should be noted that the second business execution result here is determined based on the core data in the business data (i.e., partially authorized and visible data in the business data) that flows cross-chain from the above-mentioned first chain to the second chain; furthermore, it should be noted that the target consensus node here (e.g., the above-mentioned Figure 3 The management consensus node in the corresponding embodiment can be used to centrally manage the permissions for business objects accessing 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 the data stored on each chain can be improved.

[0241] For further information, see Figure 3 , Figure 3 This is a multi-blockchain data processing method provided by the embodiment of the present application, such as Figure 3 As shown, the method can be executed by the second consensus node in the second chain network. For example, the second consensus node can be the Figure 10 Any consensus node in the consensus network 300a shown. The method may specifically include the following steps S201-S203.

[0242] Step S201: obtaining a second business requested by a second business object, calling a second cross-chain read contract on a second chain based on the second business, and reading second business-related 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 independent of the second chain network; and the second chain is different from the target chain.

[0243] 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 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;

[0244] Step S203: 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.

[0245] It is understood that the specific implementation of steps S201 to S203 can be found in the above Figure 10 The description of the second consensus node in the corresponding embodiment will not be repeated here.

[0246] It can be seen that 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 (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.). In this way, in a business scenario where core data (i.e., the partially authorized visible core data of the business data stored on the first chain) is transferred across blockchains, the first consensus node can participate in maintaining the first chain within the first chain network, and the first chain is primarily used to store the business data in the real-time business data stream obtained after executing the aforementioned first business. In addition, the second consensus node can participate in maintaining the second chain within the second chain network, and the second chain is primarily used to store the results of the second business execution. It should be noted that the second business execution results here are determined based on the core data (i.e., core data) in the business data transferred across chains from the aforementioned first chain to the second chain; furthermore, it should be noted that the target consensus node here can be used to centrally manage the permissions for business objects accessing 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 the data stored on each chain can also be improved.

[0247] For further information, see Figure 10 , Figure 1 This is a multi-blockchain data processing method provided by the embodiment of the present application, such as Figure 8 As shown, the method can be executed by the target consensus node in the target chain network. For example, the target consensus node can be the target consensus node. Figure 4 Any consensus node in the consensus network 100a shown. The method may specifically include the following steps S301-S304.

[0248] Step S301: Receive a first business permission query request sent by a first consensus node in a first chain network; the first business permission query request is determined by the first consensus node invoking a first cross-chain read contract on the first chain when obtaining a first business submitted by a first business object; the first chain is a blockchain in the first chain network independent of the target chain network;

[0249] Step S302: Based on the first business query request, 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, it calls the first business processing contract on the first chain to execute the first business and obtain a first business execution result for writing to the first chain; the first business execution result includes business data indicated by the first business;

[0250] Step S303: Receive a second business permission query request sent by a second consensus node in the second chain network; the second business permission 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 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;

[0251] Step S304: Based on the second business query request, 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, 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.

[0252] It is understood that the specific implementation of steps S301 to S304 can be found in the above Figure 11 The description of the target consensus node in the corresponding embodiment will not be repeated here.

[0253] Thus, the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize the mutual collaboration between the first chain, the target chain and the second chain, so as 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). In this way, in the business scenario where the core data of the blockchain (i.e., the core data that is partially authorized and visible on the first chain) flows, 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. In addition, 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. It should be noted that the second business execution result here is determined based on the core data in the business data that flows cross-chain from the aforementioned first chain 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. 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.

[0254] For further information, see Figure 11 , Figure 11 This is a multi-blockchain data processing method provided by the embodiment of the present application, such as Figure 1 As shown, the method can be jointly executed by the first consensus node in the first chain network, the second consensus node in the second chain network, and the target consensus node in the target chain network. For example, the first consensus node here can be the above Figure 9 Any consensus node in the consensus network 200a shown, the second consensus node can be the above Figure 5 Any consensus node in the consensus network 300a shown, the target consensus node can be the above Figure 12 Any consensus node in the consensus network 100a shown. It should be understood that the first chain network here is independent of the target chain network and independent of the second chain network; in this case, the method may specifically include the following steps S401-S410.

[0255] Step S401: The first consensus node is used to obtain 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 generate a first business permission query request;

[0256] Step S402: The first consensus node sends a first business authority query request to the target consensus node;

[0257] Step S403: When the target consensus node receives the first business authority query request sent by the first consensus node, it reads the first business association information associated with the first business from the target chain corresponding to the target chain network, and returns the first business association information to the first consensus node;

[0258] 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 to the first chain;

[0259] The first service execution result includes service data indicated by the first service;

[0260] Step S405: The target consensus node receives a second business authority query request sent by the second consensus node in the second chain network;

[0261] The second business permission 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;

[0262] 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;

[0263] 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, 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;

[0264] The cross-chain read request is used to instruct the first consensus node to read business data from the first chain.

[0265] Step S408: The second consensus node sends a cross-chain read request to the first consensus node.

[0266] It should be understood that 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.

[0267] Step S409: When the first consensus node receives 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;

[0268] In 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.

[0269] Thus, the embodiment of the present application provides a new multi-blockchain collaboration mechanism, which aims to emphasize the mutual collaboration between the first chain, the target chain and the second chain, so as 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). In this way, in the business scenario where the core data of the blockchain (i.e., the core data that is partially authorized and visible on the first chain) flows, 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. In addition, 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. It should be noted that the second business execution result here is determined based on the core data in the business data that flows cross-chain from the aforementioned first chain 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. 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.

[0270] For further information, see Figure 12 , Figure 12 This is a schematic diagram of the structure of a multi-blockchain data processing device provided by this application. Figure 12 As shown, the multi-blockchain data processing device 1 can be applied to the first consensus node, which can be any blockchain node in the first chain network (for example, the above-mentioned consensus network 200a). For example, the first consensus node can be the above-mentioned Figure 12 The consensus node 11c in the corresponding embodiment. It should be understood that 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). For example, 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. Figure 3As shown, 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;

[0271] A first business acquisition module 11 is configured to acquire a first business requested by a first business object, invoke 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 independent of the first chain network; and the first chain is different from the target chain.

[0272] The first business execution module 12 is configured to, upon determining based on the first business association information that the first business object has the first business processing authority corresponding to the first business, invoke the first business processing contract on the first chain to execute 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;

[0273] 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 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 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.

[0274] 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 authorization object synchronized from the target chain by the first consensus node through the first cross-chain read contract at the time of the first cross-chain read timestamp;

[0275] 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;

[0276] A 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 a first business node corresponding to a first business object based on the first business; the first business processing request carries transaction business data submitted by the first business object for the first business, and 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 using the first private key information of the first business object; the first private key information of the first business object is obtained by the first business object registering its identity through the object identity management contract in the target chain;

[0277] The signature verification unit 112 is configured to obtain 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;

[0278] A first service determination unit 113 is configured to determine, when the signature verification result of the first service object indicates that the signature verification is successful, that the first service object is an authorized object, and determine, based on the transaction service data, a first service associated with the first service object;

[0279] 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.

[0280] 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;

[0281] The specific implementation 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 be found in the above Figure 6 The description of step S101 in the corresponding embodiment will not be repeated here.

[0282] The signature verification unit 112 includes: a certificate acquisition subunit 1121, a certificate search subunit 1122 and a signature verification subunit 1123;

[0283] The certificate acquisition subunit 1121 is configured 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; a public key certificate of an authorization object contains the public key information of the authorization object;

[0284] The certificate searching sub-unit 1122 is configured to search the public key certificate of the first service object in the public key certificate of the authorized object, and when the public key certificate of the first service object is searched, take the searched public key certificate of the first service object as the first public key certificate, and take the public key information in the first public key certificate as the first public key information of the first service object.

[0285] The signature verification sub-unit 1123 is configured to perform signature verification on the first signature information based on the first public key certificate and the first public key information, to obtain the signature verification result of the first service object.

[0286] The signature verification sub-unit 1123 is specifically configured to take the certificate data information of the first public key certificate as the to-be-processed certificate information, and call the certificate data reading method in the first cross-chain reading contract to read the public key certificate of the first service object from the target chain at the second cross-chain reading time stamp; the second cross-chain reading time stamp is the next cross-chain reading time stamp of the first cross-chain reading time stamp.

[0287] The signature verification sub-unit 1123 is further specifically configured to take the certificate data information in the read public key certificate of the first service object as the target certificate information.

[0288] The signature verification sub-unit 1123 is further specifically configured to, when the to-be-processed certificate information and the target certificate information are consistent, perform signature verification on the first signature information based on the first public key information, and take the verification result when the signature verification is successful as the signature verification result of the first service object.

[0289] The specific implementation of the certificate obtaining sub-unit 1121, the certificate searching sub-unit 1122 and the signature verification sub-unit 1123 can be referred to the description of the specific process of signature verification in the above Figure 7 corresponding embodiments, and will not be repeated here.

[0290] The signature verification unit 112 further includes a request rejection sub-unit 1124.

[0291] The request rejection sub-unit 1124 is configured to, when the public key certificate of the first service object is not searched in the public key certificate of the authorized object, determine the first service object as an illegal service object, and reject the first service processing request sent by the illegal service object.

[0292] The specific implementation of the request rejection sub-unit 1124 can be referred to the description of the specific process of signature verification in the above Figure 8 corresponding embodiments, and will not be repeated here.

[0293] The cross-chain reading unit 114 includes an access request generation sub-unit 1141 and an association information returning sub-unit 1142.

[0294] The access request generation subunit 1141 is configured to 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 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 first business association information associated with the first business;

[0295] The association information returning subunit 1142 is used to receive the first business association information returned by the target consensus node based on the permission contract access request.

[0296] The specific implementation of the access request generating subunit 1141 and the associated information returning subunit 1142 can be found in the above Figure 9 The description of the specific process of cross-chain reading of the first business-related information through the first cross-chain reading contract in the corresponding embodiment will not be repeated here.

[0297] 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;

[0298] 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;

[0299] The processing authority determining unit 121 is configured to determine that the first business object has the first business processing authority corresponding to the first business if, based on the first business association information, the business authority type of the first business object is determined to be the invoicing authority type, and the accumulated business volume of the first business object having the invoicing authority type within the business duration does not reach the business accumulation threshold;

[0300] The bill contract calling unit 122 is configured 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 issuance contract on the first chain using the contract calling address and the contract calling name, integrate the transaction business data corresponding to the first business with the bill key information associated with the electronic bill issuance 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;

[0301] The block verification unit 123 is configured to use the key bill information, business data, and the electronic bill issuance contract as a 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 a 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 consensus node remaining in the first chain network except the first consensus node;

[0302] 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.

[0303] The specific implementation 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 be found in the above Figure 10 The description of step S102 in the corresponding embodiment will not be repeated here.

[0304] Among them, 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 rules 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.

[0305] The first business includes at least one of the following transaction businesses: electronic bill issuance business, electronic bill circulation business, electronic bill redemption 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 redemption contract for executing the electronic bill redemption business, and an electronic bill archiving contract for executing the electronic bill archiving business;

[0306] Among them, 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-ink invoice corresponding to the electronic invoice, and the red-ink 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 cold store the electronic invoices on the first chain that meet the invoice archiving conditions.

[0307] The business data reading module 13 includes: a bill reading request sending unit 131 and a bill reading response unit 132;

[0308] The bill read request sending unit 131 is used to obtain 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 when the cross-chain read request is received from the second consensus node based on the second cross-chain read contract on the second chain; 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;

[0309] The bill 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.

[0310] The specific implementation of the bill reading request sending unit 131 and the bill reading response unit 132 can be found in the above Figure 11 The description of step S103 in the corresponding time will not be repeated here.

[0311] The first business execution module 12 is further configured to specify, in a target transaction corresponding to the first business execution result, a processing terminal identifier of a business data processing terminal associated with the business data when writing the first business execution result to the first chain; the processing terminal identifier is used to indicate that the business data processing terminal has the function of clearing business data from the first chain;

[0312] The first business execution module 12 is further configured to, upon receiving a transaction clearing request sent by the business data processing terminal, obtain a target transaction from the first chain based on the processing terminal identifier carried in the transaction clearing request, clear 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 can perform data analysis on the business data.

[0313] The specific implementation of the first service acquisition module 11, the first service execution module 12 and the service data reading module 13 can be found in the above Figure 3 The description of steps S101 to S103 in the corresponding embodiment will not be repeated here. It should be understood that the description of the beneficial effects obtained by adopting the same method will not be repeated here either.

[0314] For further information, see Figure 6 , Figure 7 This is a schematic diagram of the structure of a multi-blockchain data processing device provided by this application. Figure 8 As shown, the multi-blockchain data processing device 2 can be applied to the second consensus node, which can be any blockchain node in the second chain network (for example, the above-mentioned consensus network 300a). For example, the second consensus node can be the above-mentioned Figure 3 The consensus node 12c in the corresponding embodiment. It should be understood that 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). For example, 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. Figure 6 As shown, 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;

[0315] The second business acquisition module 21 is used to obtain the second business requested by the second business object, call the second cross-chain read 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 independent of the second chain network; the second chain is different from the target chain;

[0316] 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 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;

[0317] 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.

[0318] 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 be found in the above Figure 7 The description of steps S201 to S203 in the embodiment will not be repeated here. In addition, the description of the beneficial effects obtained by adopting the same method will not be repeated here either.

[0319] For further information, see Figure 8 , Figure 13 This is a schematic diagram of the structure of a multi-blockchain data processing device provided by this application. Figure 13 As shown, the multi-blockchain data processing device 3 can be applied to the target consensus node, which can be any blockchain node in the target chain network (for example, the consensus network 100a above). For example, the target consensus node can be the Figure 7 The consensus node 10c in the corresponding embodiment. It should be understood that 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). For example, 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. Figure 1 As shown, 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;

[0320] A first query request receiving module 31 is configured 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 invoking a first cross-chain read contract on the first chain when obtaining a first business submitted by a first business object; the first chain is a blockchain in a first chain network independent of the target chain network;

[0321] The first associated information returning module 32 is configured to read 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 based on the first business associated information that the first business object has the first business processing authority corresponding to the first business, it calls the first business processing contract on the first chain to execute the first business and obtain a first business execution result for writing to the first chain; the first business execution result includes business data indicated by the first business;

[0322] The second query request receiving module 33 is used to receive a second business permission query request sent by a second consensus node in the second chain network; the second business permission 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;

[0323] The second associated information return 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.

[0324] The specific implementation of the 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 be found in the above Figure 3 The description of steps S301 to S304 in the corresponding embodiment will not be repeated here. In addition, the description of the same beneficial effects obtained by adopting the same method will not be repeated here either.

[0325] Further, see Figure 1 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 1As shown, the computer device 1000 can be a user terminal or a server, and will not be limited here. For ease of understanding, this application takes the computer device as an example of a server. The computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, 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 optionally also be at least one storage device located away from the aforementioned processor 1001. As ​ As shown, 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.

[0326] The network interface 1004 in the computer device 1000 can also provide network communication functions. ​ In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the above ​ 、 ​ 、 ​ or ​ The description of the multi-blockchain data method in the corresponding embodiment can also be performed as described above. ​ 、 ​ or ​ 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 corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0327] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer program executed by the multi-blockchain data processing device 1, the multi-blockchain data processing device 2 or the multi-blockchain data processing device 3 mentioned above, and the computer program includes computer instructions. When the processor executes the computer instructions, it can execute the above-mentioned ​ 、 ​ 、 ​or ​ The description of the multi-blockchain data processing method in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, computer instructions can be deployed and executed on a computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed in multiple locations and interconnected by a communication network. Multiple computing devices distributed in multiple locations and interconnected by a communication network can constitute a blockchain system.

[0328] In addition, it should be noted that: the embodiment of the present application also provides a computer program product or 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 instructions from the computer-readable storage medium, and the processor may execute the computer instructions, so that the computer device performs the above ​ 、 ​ 、 ​ or ​ The description of the multi-blockchain data processing method in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program product or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0329] For further information, see ​ , ​ This is a schematic diagram of a multi-blockchain data processing system provided by an embodiment of the present application. The multi-blockchain data processing system 4 may include consensus nodes 4a, consensus nodes 4b, and consensus nodes 4c; wherein, consensus node 4a may be the above-mentioned ​ The target consensus node in the target chain network described in the corresponding embodiment can be the target consensus node ​ Any blockchain node in the consensus network 100a shown in FIG. 1 will not be further described here. Among them, the consensus node 4b can be the above ​ The first consensus node in the first chain network described in the corresponding embodiment can be the above ​ Any blockchain node in the consensus network 200a shown in FIG. 2 will not be further described here. Among them, the consensus node 4c can be the above ​ The second consensus node in the second chain network described in the corresponding embodiment can be the above ​The description of any blockchain node in the consensus network 300a will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0330] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0331] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A multi-blockchain data processing method, characterized in that: The method is performed by a first consensus node in a first chain network, and the method includes: Obtaining a first business requested by a first business object, invoking a first cross-chain read contract on a first chain based on the first business, and reading first business association information associated with the first business from a 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; 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 to the first chain; the first business execution result includes the business data indicated by the first business; Upon obtaining a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, 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 configured 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 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.

2. The method according to claim 1, characterized in that 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 authorization object synchronized from the target chain by the first consensus node through the first cross-chain read contract at the first cross-chain read timestamp; The obtaining of the first business requested by the first business object, calling the first cross-chain read contract on the first chain based on the first business, and reading first business association information associated with the first business from the target chain, includes: Obtaining, through the first chain entry of the first chain network, a first business processing request sent by a first business node corresponding to a first business object based on a first business; the first business processing request carries transaction business data submitted by the first business object for the first business, and 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 using the first private key information of the first business object; the first private key information of the first business object is obtained by the first business object registering its identity through the object identity management contract in the target chain; Obtaining the first signature information from the first business processing request, performing signature verification on the first signature information based on the registration data information of the authorization object stored in the first chain entry, and obtaining a signature verification result of the first business object; When the signature verification result of the first business object indicates that the signature verification is successful, determining that the first business object is the authorized object, and determining a first business associated with the first business object based on the transaction business data; The first cross-chain reading contract is called based on the first business to read first business association information associated with the first business from the target chain.

3. The method according to claim 2, characterized in that 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 acquiring the first signature information from the first business processing request, performing signature verification on the first signature information based on the registration data information of the authorization object stored in the first chain entry, and obtaining a signature verification result of the first business object includes: Obtaining the first signature information from the first service processing request, and obtaining the public key certificate of the authorization object from the registration data information of the authorization object stored in the first chain entry; a public key certificate of an authorization object contains the public key information of an authorization object; Searching 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, using the found public key certificate of the first business object as the first public key certificate, and using the public key information in the first public key certificate as the first public key information of the first business object; The first signature information is signature verified based on the first public key certificate and the first public key information to obtain a signature verification result of the first business object.

4. The method according to claim 3, characterized in that The performing 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 includes: The certificate data information of the first public key certificate is used as the certificate information to be processed, and the certificate data reading method in the first cross-chain read contract is called at the second cross-chain read timestamp to read the public key certificate of the first business object from the target chain; the second cross-chain read timestamp is the next cross-chain read timestamp after the first cross-chain read timestamp; Using the certificate data information in the read public key certificate of the first business object as target certificate information; When the certificate information to be processed is consistent with the target certificate information, signature verification is performed on the first signature information based on the first public key information, and a verification result when the signature verification is successful is used as the signature verification result of the first business object.

5. The method according to claim 3, characterized in that The method further comprises: When the public key certificate of the first business object is not found in the public key certificate of the authorization object, the first business object is determined to be an illegal business object, and the first business processing request sent by the illegal business object is rejected.

6. The method according to claim 2, characterized in that The calling the first cross-chain reading contract based on the first business and reading first business association information associated with the first business from the target chain includes: Based on the first business, the permission contract reading method in the first cross-chain reading contract is called to 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 first business association information associated with the first business; Receive the first business association information returned by the target consensus node based on the permission contract access request.

7. The method according to claim 1, characterized in that The first service association information includes a service authority type configured for the first service object, a service accumulation amount of the first service object having the service authority type within a service duration, and a service accumulation threshold; 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, calling the first business processing contract on the first chain to execute the first business, obtaining a first business execution result associated with the first business, and writing the first business execution result to the first chain, includes: When it is determined based on the first business association information that the business permission type of the first business object is an invoicing permission type, and the accumulated business volume of the first business object with the invoicing permission type within the business duration does not reach the business accumulation threshold, it is determined that the first business object has the first business processing permission corresponding to the first business; Acquire a contract call address and a contract call name associated with the invoicing authority type based on the first business processing authority, call the electronic invoice issuance contract on the first chain through the contract call address and the contract call name, integrate the transaction business data corresponding to the first business and the key invoice information associated with the electronic invoice issuance business in the first business, issue an electronic invoice for the first business object based on the integrated key invoice information, and use the issued electronic invoice as the business data indicated by the first business; using the key bill information, the business data, and the electronic bill issuance contract as a first business execution result of the electronic bill issuance business in the first business, and sending a first block containing the first business execution result to a 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; Receive the block verification result returned by the verification consensus node, and if the block verification result indicates that the block verification is successful, write the first block into the first chain.

8. The method according to claim 7, characterized in that The key bill information includes auxiliary metadata information read from the target chain, and the auxiliary metadata information includes a first electronic bill template and a target tax calculation rule associated with the first electronic bill template; the first electronic bill template is an electronic bill template obtained by the target consensus node on the target chain calling the metadata management contract on the target chain to change the second electronic bill template and upload it to 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.

9. The method according to claim 1, characterized in that The first business includes at least one of the following transaction businesses: electronic bill issuance business, electronic bill circulation business, electronic bill redemption 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 redemption contract for executing the electronic bill redemption business, and an electronic bill archiving contract for executing the electronic bill archiving business; Among them, the electronic bill issuance business is used to instruct the first consensus node to call the electronic bill issuance contract on the first 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 first chain to transfer the electronic invoice from the first business object to the second business object; the electronic bill red-offset business is used to instruct the first consensus node to call the electronic bill red-offset contract on the first chain to issue a red-ink invoice corresponding to the electronic invoice, and the red-ink invoice is used to correct the relevant bill information in the electronic invoice; the electronic bill archiving business is used to instruct the first consensus node to call the electronic bill archiving contract on the first chain to cold store the electronic invoices on the first chain that meet the bill archiving conditions.

10. The method according to claim 1, characterized in that The method of, upon obtaining a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, reading the business data from the first chain based on the second business carried in the cross-chain read request, and returning core data in the business data to the second consensus node, includes: Upon obtaining a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, obtaining, from the cross-chain read request, a second business submitted by the second business object through a second business entry associated with the second chain; 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 permission to process the second business on the second chain; Based on the cross-chain request data information indicated by the second business, the business data is read from the first chain, the core data in the read business data is used as the cross-chain request response information corresponding to the cross-chain read request, and the cross-chain request response information is returned 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.

11. The method according to claim 1, wherein The method further comprises: When writing the first business execution result to the first chain, specifying a processing terminal identifier of a 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 indicate that the business data processing terminal has the function of clearing the business data from the first chain; Upon receiving a transaction clearing request sent by the business data processing terminal, the target transaction is obtained from the first chain based on the processing terminal identifier carried in the transaction clearing request, and the business data is cleared from the first business execution result included in the target transaction, and the business data is returned to the business data processing terminal so that the business data processing terminal performs data analysis on the business data.

12. A multi-blockchain data processing method, characterized in that: The method is performed by a second consensus node in a second chain network, and the method includes: Obtain a second business requested by a second business object, invoke a second cross-chain read 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 the second chain network; the target chain is a blockchain in a target chain network independent of the second chain network; the second chain is different from the target chain; 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 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; Receive 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.

13. A multi-blockchain data processing method, characterized in that: The method is executed by a target consensus node in a target chain network, and the method includes: receiving a first business permission query request sent by a first consensus node in a first chain network; the first business permission query request is determined by the first consensus node invoking a first cross-chain read contract on the first chain when obtaining a first business submitted by a first business object; the first chain is a blockchain in the first chain network that is independent of the target chain network; Based on the first business query request, 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, it calls the first business processing contract on the first chain to execute the first business, and obtains a first business execution result for writing to the first chain; the first business execution result includes business data indicated by the first business; Receive a second business permission query request sent by a second consensus node in a second chain network; the second business permission query request is determined by the second consensus node invoking a 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; Based on the second business query request, 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 the business data from the first chain.

14. A multi-blockchain data processing device, characterized in that: The device runs on a first consensus node in a first chain network, and includes: A first business acquisition module, configured to acquire a first business requested by a first business object, invoke a first cross-chain read contract on a first chain based on the first business, and read first business association information associated with the first business from a 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; and the first chain is different from the target chain; A first business execution module, configured to, upon determining, based on the first business association information, that the first business object has the first business processing authority corresponding to the first business, invoke a first business processing contract on the first chain to execute the first business, obtain a first business execution result associated with the first business, and write the first business execution result to the first chain; the first business execution result includes business data indicated by the first business; The business data reading module is used to, upon obtaining a cross-chain read request sent by the second consensus node based on the second cross-chain read contract on the second chain, read the business data from the first chain based on the second business carried in the cross-chain read request, 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.

15. A multi-blockchain data processing device, characterized in that: The device runs on a second consensus node in the second chain network, and includes: A second business acquisition module is configured to acquire a second business requested by a second business object, invoke a second cross-chain read 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 the second chain network; the target chain is a blockchain in a target chain network independent of the second chain network; and the second chain is different from the target chain; A 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, 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 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 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.

16. A multi-blockchain data processing device, characterized in that: The device runs on a target consensus node in a target chain network, and includes: A first query request receiving module, configured to receive a first business permission query request sent by a first consensus node in a first chain network; the first business permission query request is determined by the first consensus node invoking a first cross-chain read contract on the first chain when obtaining a first business submitted by a first business object; the first chain is a blockchain in the first chain network independent of the target chain network; A first association information returning module is configured to read first business association 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 association information to the first consensus node, so that when the first consensus node determines, based on the first business association information, that the first business object has the first business processing authority corresponding to the first business, it calls the first business processing contract on the first chain to execute the first business and obtain a first business execution result for writing to the first chain; the first business execution result includes business data indicated by the first business; A second query request receiving module is configured to receive a second business permission query request sent by a second consensus node in a second chain network; the second business permission query request is determined by the second consensus node invoking a second cross-chain read contract on a 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 configured 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 the business data from the first chain.

17. A multi-blockchain data processing system, characterized in that: The system includes: 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 a first business requested by a first business object, call a first cross-chain read contract on the first chain based on the first business, and generate a first business permission query request; The target consensus node is configured to, upon receiving the first business authority query request sent by the first consensus node, 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; The first consensus node is further configured to, upon determining based on the first business association information that the first business object has the first business processing authority corresponding to the first business, call the first business processing contract on the first chain to execute 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 first consensus node is further configured to, upon receiving a cross-chain read request sent by the second consensus node, read the business data from the first chain based on the second business carried in the cross-chain read request, and return core data in the business data to the second consensus node; the cross-chain read request is generated by the second consensus node invoking the second cross-chain read contract when determining, 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 business association information is read from the target chain by the second consensus node invoking the second cross-chain read contract based on the second business; The second consensus node is used to write a second business execution result corresponding to the second business into the second chain after executing the second business based on the core data.

18. A computer device, characterized in that: including memory and processor; The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1 to 13.

19. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 13.

20. A computer program product, characterized in that The method comprises a computer program / instruction, which implements the method according to any one of claims 1 to 13 when executed by a processor.

Images