A cross-chain interoperability method and multi-blockchain system

Abstract

The present invention provides a cross-chain interoperability method and a multi-blockchain system, wherein the multi-blockchain system includes an enabled blockchain and a non-enabled blockchain. The method is applied to a multi-blockchain system, including: the non-enabled blockchain of the source of the cross-chain transaction counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain. The enabled blockchain generates verification information for proving the credibility of the cross-chain transaction to the non-enabled blockchain of the execution party based on the block header of the latest block in the non-enabled blockchain of the source party that provides the statistical information. The non-enabled blockchain of the execution party performs a credible verification on the verification information generated by the enabled blockchain, and after the credible verification is successful, obtains and executes the cross-chain transaction from the non-enabled blockchain of the source party. The scheme of the present invention can reduce the resource consumption of the multi-blockchain system to realize the credible verification of cross-chain transactions.

Description

Technical Field

[0001] This document relates to the field of blockchain technology, and in particular to a cross-chain interoperability method and a multi-blockchain system. Background Art

[0002] With the development of blockchain technology, public chains, private chains, and alliance chains have begun to emerge in an endless stream, and there are more and more blockchains in the same production environment, resulting in more and more frequent interoperation between chains. For cross-chain transactions in multi-blockchain systems, the executor blockchain needs to perform trust verification on the source blockchain for cross-chain transactions, which involves the need to configure a trust verification execution mechanism between the two blockchains. If there are a large number of blockchains in the multi-blockchain system, each blockchain needs to configure a trust verification execution mechanism with other blockchains, which causes the multi-blockchain system to consume too many resources to achieve trust verification of cross-chain transactions.

[0003] To this end, reducing the resource consumption of multi-blockchain systems to achieve cross-chain transaction trust verification is a technical problem that urgently needs to be solved. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a cross-chain interoperability method and a multi-blockchain system, which can reduce the resource consumption of the multi-blockchain system to realize cross-chain transaction trust verification.

[0005] In order to achieve the above object, the embodiment of the present invention is implemented as follows:

[0006] In a first aspect, a cross-chain interoperability method is provided, which is applied to a multi-blockchain system, wherein the multi-blockchain system includes an enabled blockchain and a non-enabled blockchain, and the method includes:

[0007] The non-enabled blockchain, the source of the cross-chain transaction, counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain;

[0008] The enabled blockchain generates verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain based on the block header of the latest block in the non-enabled blockchain that is the source of the statistical information;

[0009] The non-enabled blockchain of the execution party performs a credible verification on the verification information generated by the enabled blockchain, and after the credible verification is successful, obtains the cross-chain transaction to be executed from the non-enabled blockchain of the source party to perform the cross-chain transaction operation.

[0010] In a second aspect, a multi-blockchain system is provided, including an enabled blockchain and a non-enabled blockchain; wherein:

[0011] The non-enabled blockchain, the source of the cross-chain transaction, counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain;

[0012] The enabled blockchain generates verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain based on the block header of the latest block in the non-enabled blockchain that is the source of the statistical information;

[0013] The non-enabled blockchain of the execution party performs a credible verification on the verification information generated by the enabled blockchain, and after the credible verification is successful, obtains the cross-chain transaction to be executed from the non-enabled blockchain of the source party to perform the cross-chain transaction operation.

[0014] Based on the scheme of the embodiment of the present invention, the enabling blockchain of the multi-blockchain system acts as a relay for each non-enabled blockchain, is responsible for collecting the statistical information of the cross-chain transactions to be executed reported by the non-enabled blockchain, and based on the block header of the latest block in the non-enabled blockchain of the source providing the statistical information, generates verification information for proving the credibility of the cross-chain transaction to the non-enabled blockchain of the executor. Correspondingly, the non-enabled blockchain of the executor can regard the verification information generated by the enabling blockchain as notification information that there is a cross-chain transaction to be executed, and perform a credible verification on the verification information. If the credible verification passes, the non-enabled blockchain of the executor determines the authenticity of the notification, and starts to obtain the cross-chain transaction to be executed from the non-enabled blockchain of the source to execute the cross-chain transaction operation. In the whole scheme, for the non-enabled blockchain, there is no need to configure the execution mechanism of the credible verification with other non-enabled blockchains; for the enabled blockchain, what is collected is the statistical information of the cross-chain transaction, and there is no need to pay attention to the specific content of the cross-chain transaction, so the resource occupation of realizing cross-chain interoperability is reduced, making the cross-chain interoperability more lightweight. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0016] Figure 1 A schematic diagram of a first flow chart of a cross-chain interoperability method provided in an embodiment of the present invention.

[0017] Figure 2 A second flow chart of the cross-chain interoperability method provided in an embodiment of the present invention.

[0018] Figure 3 The structural intention of the multi-blockchain system provided by the embodiment of the present invention.

[0019] Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0021] As mentioned above, for the cross-chain transactions in the current multi-blockchain system, the executor blockchain needs to perform a trusted verification of the source blockchain for the cross-chain transaction, which involves the need to configure a trusted verification execution mechanism between the two blockchains. If there are a large number of blockchains in the multi-blockchain system, each blockchain needs to configure a trusted verification execution mechanism with other blockchains, which causes the multi-blockchain system to consume too many resources to achieve trusted verification of cross-chain transactions. In response to this problem, this application aims to propose a technical solution that can reduce the resource consumption of a multi-blockchain system to achieve trusted verification of cross-chain transactions.

[0022] On the one hand, an embodiment of the present invention provides a cross-chain interoperability method using a multi-blockchain system, wherein the multi-blockchain system includes an enabled blockchain and a non-enabled blockchain. Figure 1 : is a flow chart of the cross-chain interoperability method according to an embodiment of the present invention, which specifically includes the following steps:

[0023] S102, the non-enabled blockchain, the source of the cross-chain transaction, counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain.

[0024] It should be understood that the statistical information described in the embodiments of the present application does not include specific transaction data for cross-chain transactions. For ease of understanding, it can be assumed that the statistical information of the target non-enabled blockchain is: [{chain_id1,2},{chain_id2,1}], where {chain_id1,2} indicates that the non-enabled blockchain of chain_id1 is the executor non-enabled blockchain, and the corresponding number of transactions that need to execute cross-chain transactions is 2. Similarly, {chain_id2,1} indicates that the non-enabled blockchain of chain_id2 is the executor non-enabled blockchain, and the corresponding number of transactions that need to execute cross-chain transactions is 1. Based on the statistical information of the above example, it can be seen that the target non-enabled blockchain now has 3 cross-chain transactions that are initiated locally but need to be executed by other non-enabled blockchains.

[0025] In practical applications, the enabled blockchain of the embodiment of the present invention acts as a light client of each non-enabled blockchain, that is, the enabled blockchain synchronously records the block headers of each block in the non-enabled blockchain. Correspondingly, the non-enabled blockchain can record the statistical information in the block header of the latest local block after counting the cross-chain transactions initiated locally and to be executed. For example, if there is a cross-chain transaction initiated locally and needs to be executed by other enabled blockchains, a dedicated field can be extended in the block header of the current latest block based on the rules of the multi-blockchain system to store statistical information.

[0026] Based on the light client mechanism, the enabled blockchain can obtain the corresponding statistical information of the non-enabled blockchain by using the block header of the latest block of the non-enabled blockchain recorded by the light client synchronization technology. For example, when the target non-enabled blockchain provides the block header of the latest local block to the enabled blockchain for synchronization, the enabled blockchain checks whether there is statistical information in the block header of the latest local block of the target non-enabled blockchain. If so, the statistical information of the target non-enabled blockchain is extracted.

[0027] It should be understood that based on the design of the light client, the enabled blockchain can prove the credibility of the cross-chain transactions initiated locally by the non-enabled blockchain based on the block headers of the non-enabled blockchain that are synchronously recorded. If the cross-chain transactions are credible, the corresponding statistical information can also be proven to be credible.

[0028] S104, the enabling blockchain generates verification information for proving the credibility of the cross-chain transaction to the executing non-enabling blockchain based on the statistical information provided by at least one source non-enabling blockchain.

[0029] Among them, the method of trusted verification is not unique, and this article does not make specific limitations here. As an exemplary introduction, the enabled blockchain of an embodiment of the present invention can implement trusted verification of cross-chain transactions to the executor non-enabled blockchain based on the Merkle tree. That is, in this step, the enabled blockchain can provide the block header (block hash) of the latest block in the non-enabled blockchain of the source of statistical information, perform multi-level hash calculations, generate the corresponding Merkle tree, and use the root hash of the Merkle tree corresponding to the executor non-enabled blockchain as the verification information for proving the trustworthiness of cross-chain transactions to the executor non-enabled blockchain.

[0030] S106, the executor non-enabled blockchain performs a credible verification on the verification information generated by the enabled blockchain, and after the credible verification is successful, obtains the cross-chain transaction to be executed from the source non-enabled blockchain to execute the cross-chain transaction operation.

[0031] Specifically, taking the Merkle tree-based trust verification as an example, the executor non-enabled blockchain can calculate whether it matches the Merkle tree based on its corresponding root hash. The match proves that the cross-chain transaction it needs to execute is credible, and obtain the cross-chain transaction it needs to execute from the corresponding source non-enabled blockchain.

[0032] In practical applications, the non-enabled blockchain can be used as a light client of the enabled blockchain to synchronously record the block headers of each block in the enabled blockchain. After the enabled blockchain generates verification information for proving the trustworthiness of the cross-chain transaction to the executor non-enabled blockchain, the verification information of the executor non-enabled blockchain is recorded in the block header of the local latest block, and the executor non-enabled blockchain can obtain the verification information that needs to be verified by trustworthiness by using the block header of the latest block of the enabled blockchain recorded by the light client synchronization technology. For example, when the enabled blockchain provides the block header of the latest local block to the target non-enabled blockchain for synchronization, the target non-enabled blockchain checks whether the block header of the latest local block of the target non-enabled blockchain contains verification information for the target non-enabled blockchain. If so, it means that the target non-enabled blockchain has a cross-chain transaction that needs to be processed, and a trustworthiness verification needs to be performed based on the verification information. It should be understood that if the trustworthiness verification passes, it means that the target non-enabled blockchain notifies that there is a trustworthiness of the cross-chain transaction that needs to be processed, and starts to obtain cross-chain transactions from other target non-enabled blockchains.

[0033] Here, in order to increase the speed at which the executor's non-enabled blockchain obtains cross-chain transactions, the enabled blockchain in the embodiment of the present application can generate cross-chain guidance information for the executor's non-enabled blockchain to inform the executor's non-enabled blockchain which non-enabled blockchain the cross-chain transaction to be executed comes from.

[0034] As an exemplary introduction, the statistical information can record the non-enabled blockchain of the executor of the cross-chain transaction and the number of transactions that the non-enabled blockchain of the executor needs to execute the cross-chain transaction. The enabled blockchain of the embodiment of the present application can generate cross-chain guidance information for the non-enabled blockchain of the executor based on the statistical information provided by at least one non-enabled blockchain of the source, wherein the cross-chain guidance information records the non-enabled blockchain of the source of the cross-chain transaction that needs to be executed, and the non-enabled blockchain of the executor can determine the non-enabled blockchain of the source of the cross-chain transaction that needs to be executed through the cross-chain guidance information generated by the enabled blockchain. As an example, the cross-chain guidance information generated by the enabled blockchain for the non-enabled blockchain of chain_id1 is: [{chain_id2,2},{chain_id3,3}], which means that the non-enabled blockchain of chain_id1, as the executor non-enabled blockchain, needs to process 2 cross-chain transactions from the non-enabled blockchain of chain_id2, and 3 cross-chain transactions from the non-enabled blockchain of chain_id2. At this time, the non-enabled blockchain of chain_id2 can obtain the corresponding cross-chain transactions from the non-enabled blockchains of chain_id2 and chain_id3 based on the cross-chain guidance information.

[0035] Of course, if the enabled blockchain acts as a light client of the non-enabled blockchain, due to the synchronously recorded block headers of the non-enabled blockchain, the enabled blockchain can determine the block height of the cross-chain transactions corresponding to each source non-enabled blockchain, that is, the cross-chain transaction belongs to the data of the latest block of the source non-enabled blockchain. Therefore, the cross-chain guidance information generated by the enabled blockchain can also record the block height corresponding to the cross-chain transaction that needs to be executed in the source non-enabled blockchain, so as to assist the executor non-enabled blockchain to directly locate the block of the source non-enabled blockchain storing the cross-chain transaction. As an exemplary introduction, the cross-chain guidance information generated by the enabled blockchain for the non-enabled blockchain of chain_id1 can be further expanded to: [{chain_id2,2,No23},{chain_id3,No 34}], where "No23" means that the non-enabled blockchain of chain_id1 needs to process the cross-chain transactions from the non-enabled blockchain of chain_id2 stored in the 23rd block of the non-enabled blockchain of chain_id2; "No34" means that the non-enabled blockchain of chain_id1 needs to process the cross-chain transactions from the non-enabled blockchain of chain_id3 stored in the 34th block of the non-enabled blockchain of chain_id3.

[0036] Correspondingly, the non-enabled blockchain of the executor queries the information of the block containing the cross-chain transaction in the non-enabled blockchain of the source party according to the cross-chain guidance information, and performs a credible verification on the information of the block containing the cross-chain transaction in the non-enabled blockchain of the source party based on the verification information generated by the enabled blockchain (that is, the root hash corresponding to the block in the Merkle tree above). If the credible verification passes, it means that the block containing the cross-chain transaction in the non-enabled blockchain of the source party is authentic and valid. Subsequently, the specific cross-chain transactions in the block can be further verified based on the existing cross-chain transaction technology, and after the cross-chain transaction passes the verification, the relevant cross-chain transaction operations can be performed on it.

[0037] It should be noted that the processing flow of blockchain executing cross-chain transactions belongs to the existing technology of cross-chain interoperability. This article will not elaborate on the execution flow of cross-chain transactions and the subsequent corresponding execution feedback flow.

[0038] Based on the method of the embodiment of the present invention, the enabling blockchain of the multi-blockchain system acts as a relay for each non-enabled blockchain, is responsible for collecting the statistical information of the cross-chain transactions to be executed reported by the non-enabled blockchain, and based on the block header of the latest block in the non-enabled blockchain of the source providing the statistical information, generates verification information for proving the trustworthiness of the cross-chain transaction to the non-enabled blockchain of the executor. Correspondingly, the non-enabled blockchain of the executor can regard the verification information generated by the enabling blockchain as notification information that a cross-chain transaction needs to be executed, and perform a trustworthy verification on the verification information. If the trustworthy verification passes, the non-enabled blockchain of the executor determines the authenticity of the notification, and starts to obtain the cross-chain transaction to be executed from the non-enabled blockchain of the source to execute the cross-chain transaction operation. In the whole scheme, for the non-enabled blockchain, there is no need to configure the execution mechanism of the trustworthy verification with other non-enabled blockchains; for the enabled blockchain, what is collected is the statistical information of the cross-chain transaction, and there is no need to pay attention to the specific content of the cross-chain transaction, so the resource occupation of realizing cross-chain interoperability is reduced, making the cross-chain interoperability more lightweight.

[0039] In addition, on the basis of the above, after the non-enabled blockchain has completed all the corresponding cross-chain transactions, the enabled blockchain can delete the cross-chain guidance information generated for the executor non-enabled blockchain cross-chain to release cache space. As one of the feasible solutions, the enabled blockchain acts as a light client of the non-enabled blockchain. After completing the cross-chain transaction, the executor non-enabled blockchain records the execution result information of the cross-chain transaction in the block header of the latest local block, where the execution result information records the source non-enabled blockchain corresponding to the completed cross-chain transaction and the number of transactions of the cross-chain transaction completed under the source non-enabled blockchain. Correspondingly, the enabled blockchain uses the block header of the latest block of the executor non-enabled blockchain recorded by the light client synchronization technology to determine that the executor non-enabled blockchain has completed all the corresponding cross-chain transactions. For example, an enabled blockchain determines through the collected statistical information that a certain executor non-enabled blockchain has 6 cross-chain transactions that need to be executed. If it is later monitored through the light client mechanism that the execution result information recorded in the block header of the latest blockchain of the executor non-enabled blockchain indicates that 6 cross-chain transactions have been completed, it can be determined that the executor non-enabled blockchain has completed all cross-chain transactions that need to be executed. At this time, the cross-chain guidance information generated for the executor non-enabled blockchain can be deleted.

[0040] The method of the embodiment of the present invention is exemplarily introduced below in combination with actual application scenarios.

[0041] In the multi-blockchain system of this application scenario, the enabling blockchain and each non-enabling blockchain are light clients of each other, and no light client relationship is established between non-enabling blockchains. In other words, the enabling blockchain synchronously records the block headers of all non-enabling blockchains, and the non-enabling blockchain also synchronously records the block headers of the enabling blockchain. In two blockchains with light client mechanisms, the transaction summary of one blockchain is transparent and reliable to the other. That is to say, the cross-chain transaction initiated locally by the non-enabling blockchain in this application scenario is reliable relative to the enabling blockchain, but it is unreliable for other non-enabling blockchains and needs to be relayed by the enabling blockchain. Among them, the block headers of the enabling blockchain and the non-enabling blockchain in the multi-blockchain system can expand the fields to flexibly store incremental information when necessary.

[0042] Correspondingly, the specific plan is as follows:

[0043] First, the concept of cross-chain channels is introduced, and the management interface of cross-chain channels between side chains is provided in the enabling blockchain. Some additional information can be set for cross-chain channels: for example, the maximum number of transactions on the channel in a block and the effective time of cross-chain transactions on the channel, etc., which will not be elaborated in detail here.

[0044] At the same time, a new system interface register_xc_trx(chain_id) is added to the smart contract framework to register cross-chain transactions. The parameter chain_id indicates the non-enabled blockchain from which the cross-chain transaction originated. When executing a cross-chain transaction, check whether the cross-chain channel is open, whether the number of transactions on the channel has reached the threshold, etc. A field is added to the transaction structure for cross-chain transactions to indicate the corresponding non-enabled blockchain that executes the transaction.

[0045] Before the light client mechanism synchronizes the block header of the latest block to the enabled blockchain, the source non-enabled blockchain counts the cross-chain information in the current block, and then writes the statistical information into the extended field of the block header. Because it is only statistical information, such as [{chain_id1,2},{chain_id2,1}] shown above, the number of bytes added to the block header is very small, and statistical information is only added to the block header where there is a cross-chain transaction.

[0046] When the enabled blockchain receives the block header of the non-enabled blockchain, if it finds cross-chain statistical information in the block header, it will add the statistical information to the cross-chain list xc_headers. After that, the enabled blockchain link generates the statistical information in xc_headers into verification information used to prove the credibility of the cross-chain transaction to the non-enabled blockchain of the executor, and Figure 2 As shown, in the block header extension field xc_header_mroot of the local latest block, the executor non-enabled blockchain and the corresponding verification information are associated and stored. In the embodiment of the present invention, the block header of each non-enabled blockchain latest block can be recorded in xc_header_mroot ( Figure 2 Furthermore, the transaction list trx_mroot of the block header of the latest block of the non-enabled blockchain in xc_header_mroot records the transaction information of the latest block of the non-enabled blockchain (including cross-chain transactions, such as Figure 2 As shown in trx3), based on the information in the xc_header_mroot of the enabled blockchain, the information containing the latest block of the cross-chain transaction in the source non-enabled blockchain can be trusted and verified.

[0047] At the same time, the enabled blockchain generates the ingress information (cross-chain guidance information) corresponding to each executor's non-enabled blockchain based on the statistical information. The ingress information includes the ID of the source non-enabled blockchain to be executed, the number of cross-chain transactions corresponding to the source non-enabled blockchain, and the block height corresponding to the cross-chain transaction in the source non-enabled blockchain.

[0048] If the non-enabled blockchain of the execution party detects that the block header xc_header_mroot field of the latest block of the enabled blockchain records its own corresponding verification information, it can determine that there is a cross-chain transaction that needs to be processed. After that, based on the ingress information, it determines which non-enabled blockchain block the cross-chain transaction to be executed comes from, and queries the non-enabled blockchain for information about the block to perform a trusted verification based on its own corresponding verification information. If this block passes the trusted verification, SPV verification is initiated for the transactions in the block, and after the SPV verification passes, the cross-chain transaction operation corresponding to the cross-chain transaction is executed.

[0049] Afterwards, the non-enabled blockchain of the executor can count the completed cross-chain transactions in the block header of the latest local block. After detection, the enabled blockchain determines the completion progress of the cross-chain transaction by the non-enabled blockchain of the executor. If all are completed, the locally cached ingress information can be deleted.

[0050] Among them, if the cross-chain transaction is a two-way transaction, the subsequent transaction can also be executed across blockchains in the same way as the previous exchange, which is not elaborated in this article.

[0051] To sum up, the enabled blockchain in this application scenario only plays a transit role and is completely separated from the specific business of the non-enabled blockchain. In other words, any type of cross-chain transaction between non-enabled blockchains is implemented using the smart contracts of the original non-enabled blockchain. Cross-chain interoperability between non-enabled blockchains can be achieved with only lightweight improvements, so it has high practicality.

[0052] On the other hand, for Figure 1 The cross-chain interoperability method shown, the embodiment of this specification also provides a multi-blockchain system. Figure 3 2 is a structural diagram of a multi-blockchain system 300 according to an embodiment of the present invention, including an enabled blockchain 210 and a non-enabled blockchain 320; wherein:

[0053] The non-enabled blockchain 320, the source of the cross-chain transaction, counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain 210;

[0054] The enabled blockchain 210 generates verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain 320 based on the block header of the latest block in the source non-enabled blockchain 320 providing the statistical information.

[0055] The executor non-enabled blockchain 320 performs a trustworthy verification on the verification information generated by the enabled blockchain 210, and after the trustworthy verification succeeds, obtains the cross-chain transaction to be executed from the source non-enabled blockchain 320 to perform the cross-chain transaction operation.

[0056] The enabling blockchain of the multi-blockchain system of the embodiment of the present invention acts as a relay for each non-enabled blockchain, is responsible for collecting the statistical information of the cross-chain transactions to be executed reported by the non-enabled blockchain, and based on the block header of the latest block in the non-enabled blockchain of the source party providing the statistical information, generates verification information for proving the credibility of the cross-chain transaction to the non-enabled blockchain of the executor. Correspondingly, the non-enabled blockchain of the executor can regard the verification information generated by the enabling blockchain for it as notification information that there is a cross-chain transaction to be executed, and performs a credible verification on the verification information. If the credible verification passes, the non-enabled blockchain of the executor determines the authenticity of the notification, and starts to obtain the cross-chain transaction to be executed from the non-enabled blockchain of the source party to execute the cross-chain transaction operation. In the whole scheme, for the non-enabled blockchain, there is no need to configure the execution mechanism of the credible verification with other non-enabled blockchains; for the enabled blockchain, what is collected is the statistical information of the cross-chain transaction, and there is no need to pay attention to the specific content of the cross-chain transaction, so the resource occupation of realizing cross-chain interoperability is reduced, making the cross-chain interoperability more lightweight.

[0057] Optionally, the statistical information of the source non-enabled block records the executor non-enabled blockchain of the cross-chain transactions initiated locally and to be executed and the number of transactions required by the executor non-enabled blockchain to execute the cross-chain transactions. The enabled blockchain generates cross-chain guidance information for the executor non-enabled blockchain based on the statistical information provided by at least one source non-enabled blockchain, wherein the cross-chain guidance information records the source non-enabled blockchain of the cross-chain transactions that need to be executed, and the executor non-enabled blockchain determines the source non-enabled blockchain of the cross-chain transactions that need to be executed through the cross-chain guidance information generated by the enabled blockchain.

[0058] Optionally, the enabled blockchain acts as a light client of the non-enabled blockchain, and synchronously records the block headers of each block in the non-enabled blockchain; the cross-chain guidance information also records the block height corresponding to the cross-chain transaction that needs to be executed in the source non-enabled blockchain, wherein the block height corresponding to the cross-chain transaction that needs to be executed in the source non-enabled blockchain is the block height of the latest block of the source non-enabled blockchain currently recorded by the enabled blockchain.

[0059] Optionally, after the source non-enabled blockchain performs statistics on the cross-chain transactions initiated locally and to be executed, the statistical information is recorded in the block header of the latest local block, wherein the enabled blockchain synchronizes the block header of the latest block of the non-enabled blockchain recorded by the light client technology to obtain the statistical information corresponding to the non-enabled blockchain.

[0060] Optionally, after the non-enabled blockchain completes all corresponding cross-chain transactions, the enabled blockchain deletes the cross-chain guidance information generated for the executor non-enabled blockchain cross-chain.

[0061] Optionally, after completing the cross-chain transaction, the executor's non-enabled blockchain records the execution result information of the cross-chain transaction in the block header of the local latest block, wherein the execution result information records the source sender's non-enabled blockchain corresponding to the completed cross-chain transaction and the transaction quantity of the cross-chain transaction completed under the source sender's non-enabled blockchain. The enabled blockchain uses the light client synchronization technology to record the block header of the latest block of the executor's non-enabled blockchain to determine that the executor's non-enabled blockchain has completed all corresponding cross-chain transactions.

[0062] Optionally, the non-enabled blockchain acts as a light client of the enabled blockchain, and synchronously records the block headers of each block in the enabled blockchain; after the enabled blockchain generates verification information for proving the credibility of the cross-chain transaction to the executor's non-enabled blockchain, the verification information of the executor's non-enabled blockchain is recorded in the block header of the latest local block, wherein the executor's non-enabled blockchain uses the light client synchronization technology to synchronize the block header of the latest block of the enabled blockchain to obtain the verification information that needs to be verified for credibility.

[0063] Optionally, after the executor non-enabled blockchain obtains the cross-chain transaction to be executed from the source non-enabled blockchain, it initiates a simple payment verification for the obtained cross-chain transaction, wherein the executor non-enabled blockchain executes relevant cross-chain transaction operations on the cross-chain transaction that passes the simple payment verification.

[0064] Optionally, the executor's non-enabled blockchain performs a credible verification on the verification information generated in relation to the enabled blockchain, including: the executor's non-enabled blockchain queries the source party's non-enabled blockchain for information on blocks containing cross-chain transactions based on the cross-chain guidance information, and performs a credible verification on the source party's non-enabled blockchain for information on blocks containing cross-chain transactions based on the verification information generated in relation to the enabled blockchain.

[0065] It should be understood that the multi-blockchain system of the embodiment of this specification can be used as Figure 1 The execution subject of the method shown can thus realize Figure 1 The steps and functions in the method shown in the figure are not repeated in this article because the principles are the same.

[0066] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 4At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0067] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0068] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0069] Among them, the processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a non-enabled blockchain at the logical level. Correspondingly, the processor executes the program stored in the memory and is specifically used to perform the following operations:

[0070] If the source of the cross-chain transaction is a non-enabled blockchain, statistics will be collected on the cross-chain transactions initiated locally and to be executed, and the statistical information will be sent to the enabled blockchain. The enabled blockchain will generate verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain based on the block header of the latest block in the source non-enabled blockchain that provides the statistical information.

[0071] If the executor of the cross-chain transaction is a non-enabled blockchain, a trustworthy verification is performed on the verification information generated by the enabled blockchain. After the trustworthy verification is successful, the cross-chain transaction to be executed is obtained from the source non-enabled blockchain to execute the cross-chain transaction operation.

[0072] Alternatively, the processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming an enabling blockchain at the logical level. Correspondingly, the processor executes the program stored in the memory and is specifically used to perform the following operations:

[0073] Obtain statistical information provided by at least one non-enabled blockchain as the source, where the statistical information is obtained by counting the cross-chain transactions initiated locally and to be executed by the non-enabled blockchain as the source of the cross-chain transaction;

[0074] Based on the block header of the latest block in the non-enabled blockchain of the source party providing the statistical information, verification information is generated to prove the credibility of the cross-chain transaction to the non-enabled blockchain of the executor party, so that the non-enabled blockchain of the executor party performs a credible verification on the verification information generated by the enabled blockchain, and after the credible verification is successful, obtains the cross-chain transaction to be executed from the non-enabled blockchain of the source party to execute the cross-chain transaction operation.

[0075] The above is as in this manual Figure 1 The method disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present invention can be directly embodied as a hardware decoding processor for execution, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0076] It should be understood that the electronic device of the embodiment of the present invention can enable the consensus master node to implement the corresponding Figure 1 The steps and functions in the method shown, or the consensus backup node implements the corresponding Figure 1 The steps and functions in the method shown in the figure are not repeated in this article because the principles are the same.

[0077] Of course, in addition to software implementation, the electronic device of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0078] In addition, an embodiment of the present invention further provides a computer-readable storage medium, which stores one or more programs, and the one or more programs include instructions.

[0079] When the above instructions are executed by a portable electronic device including multiple application programs, the portable electronic device can execute Figure 1 The steps of the non-enabled blockchain in the method include:

[0080] If the source of the cross-chain transaction is a non-enabled blockchain, statistics will be collected on the cross-chain transactions initiated locally and to be executed, and the statistical information will be sent to the enabled blockchain. The enabled blockchain will generate verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain based on the block header of the latest block in the source non-enabled blockchain that provides the statistical information.

[0081] If the executor of the cross-chain transaction is a non-enabled blockchain, a trustworthy verification is performed on the verification information generated by the enabled blockchain. After the trustworthy verification is successful, the cross-chain transaction to be executed is obtained from the source non-enabled blockchain to execute the cross-chain transaction operation.

[0082] Alternatively, when the above instructions are executed by a portable electronic device including a plurality of application programs, the portable electronic device can execute Figure 1 The steps performed by the enabling blockchain in the method shown include:

[0083] Obtain statistical information provided by at least one non-enabled blockchain as the source, where the statistical information is obtained by counting the cross-chain transactions initiated locally and to be executed by the non-enabled blockchain as the source of the cross-chain transaction;

[0084] Based on the block header of the latest block in the non-enabled blockchain of the source party providing the statistical information, verification information is generated to prove the credibility of the cross-chain transaction to the non-enabled blockchain of the executor party, so that the non-enabled blockchain of the executor party performs a credible verification on the verification information generated by the enabled blockchain, and after the credible verification is successful, obtains the cross-chain transaction to be executed from the non-enabled blockchain of the source party to execute the cross-chain transaction operation.

[0085] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0087] The above are only embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification may be subject to various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims of this specification. In addition, all other embodiments obtained by ordinary technicians in this field without creative work shall fall within the scope of protection of this document.

Claims

1. A cross-chain interoperability method, applied to a multi-blockchain system, wherein the multi-blockchain system includes an enabled blockchain and a non-enabled blockchain, characterized in that: include: The non-enabled blockchain, the source of the cross-chain transaction, counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain; The enabled blockchain generates verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain based on the block header of the latest block in the non-enabled blockchain that is the source of the statistical information; The non-enabled blockchain of the execution party performs a trustworthy verification on the verification information generated by the enabled blockchain, and after the trustworthy verification succeeds, obtains the cross-chain transaction to be executed from the non-enabled blockchain of the source party to execute the cross-chain transaction operation; Among them, the statistical information of the source non-enabled block records the number of transactions of the executor non-enabled blockchain of the cross-chain transaction initiated locally and to be executed and the number of transactions required by the executor non-enabled blockchain to execute the cross-chain transaction; The method further comprises: The enabling blockchain generates cross-chain guidance information for the executor non-enabled blockchain based on statistical information provided by at least one source non-enabled blockchain, wherein the cross-chain guidance information records the source non-enabled blockchain of the cross-chain transaction to be executed, and the executor non-enabled blockchain determines the source non-enabled blockchain of the cross-chain transaction to be executed through the cross-chain guidance information generated by the enabling blockchain; The enabled blockchain acts as a light client of the non-enabled blockchain and synchronously records the block headers of each block in the non-enabled blockchain; The cross-chain guidance information also records the block height corresponding to the cross-chain transaction that needs to be executed in the source party's non-enabled blockchain, wherein the block height corresponding to the cross-chain transaction that needs to be executed in the source party's non-enabled blockchain is the block height of the latest block of the source party's non-enabled blockchain currently recorded by the enabled blockchain.

2. The method according to claim 1, characterized in that Also includes: After the source non-enabled blockchain has counted the cross-chain transactions initiated locally and to be executed, it records the statistical information in the block header of the latest local block, wherein the enabled blockchain uses the light client synchronization technology to synchronize the block header of the latest block of the non-enabled blockchain to obtain the statistical information corresponding to the non-enabled blockchain.

3. The method according to claim 1, characterized in that Also includes: The enabled blockchain deletes the cross-chain guidance information generated for the executor's non-enabled blockchain cross-chain after the non-enabled blockchain completes all corresponding cross-chain transactions.

4. The method according to claim 3, characterized in that Also includes: After completing the cross-chain transaction, the executor's non-enabled blockchain records the execution result information of the cross-chain transaction in the block header of the local latest block, where the execution result information records the source non-enabled blockchain corresponding to the completed cross-chain transaction and the transaction quantity of the cross-chain transaction completed under the source non-enabled blockchain. The enabled blockchain uses the light client synchronization technology to record the block header of the latest block of the executor's non-enabled blockchain to determine that the executor's non-enabled blockchain has completed all corresponding cross-chain transactions.

5. The method according to claim 1, characterized in that The non-enabled blockchain acts as a light client of the enabled blockchain and synchronously records the block headers of each block in the enabled blockchain; The method further comprises: After generating verification information for proving the credibility of the cross-chain transaction to the executor's non-enabled blockchain, the enabled blockchain records the verification information of the executor's non-enabled blockchain in the block header of the latest local block, wherein the executor's non-enabled blockchain uses the light client synchronization technology to synchronize the block header of the latest block of the enabled blockchain to obtain the verification information that needs to be trusted.

6. The method according to claim 1, characterized in that Also includes: The enabling blockchain generates verification information for proving the credibility of the cross-chain transaction to the executing non-enabling blockchain based on the statistical information provided by at least one source non-enabling blockchain, including: The enabled blockchain creates a Merkle tree based on statistical information provided by at least one non-enabled blockchain, and uses the root hash of the Merkle tree corresponding to the executor's non-enabled blockchain as verification information for proving to the executor's non-enabled blockchain that the cross-chain transaction is credible, wherein the executor's non-enabled blockchain performs a credible verification based on the Merkle tree algorithm on the verification information generated related to the enabled blockchain.

7. The method according to claim 1, characterized in that Also includes: The non-enabled blockchain of the execution party performs a credible verification on the verification information generated by the enabled blockchain, including: The executor's non-enabled blockchain queries the source party's non-enabled blockchain for information about blocks containing cross-chain transactions based on the cross-chain guidance information, and performs credible verification on the source party's non-enabled blockchain for information about blocks containing cross-chain transactions based on the verification information generated by the enabled blockchain.

8. A multi-blockchain system, characterized in that: The multi-blockchain system includes enabled blockchains and non-enabled blockchains; wherein: The non-enabled blockchain, the source of the cross-chain transaction, counts the cross-chain transactions initiated locally and to be executed, and sends the statistical information to the enabled blockchain; The enabled blockchain generates verification information for proving the credibility of the cross-chain transaction to the executor non-enabled blockchain based on the block header of the latest block in the non-enabled blockchain that is the source of the statistical information; The non-enabled blockchain of the execution party performs a trustworthy verification on the verification information generated by the enabled blockchain, and after the trustworthy verification succeeds, obtains the cross-chain transaction to be executed from the non-enabled blockchain of the source party to execute the cross-chain transaction operation; Among them, the statistical information of the source non-enabled block records the number of transactions of the executor non-enabled blockchain of the cross-chain transaction initiated locally and to be executed and the number of transactions required by the executor non-enabled blockchain to execute the cross-chain transaction; The enabling blockchain generates cross-chain guidance information for the executor non-enabled blockchain based on statistical information provided by at least one source non-enabled blockchain, wherein the cross-chain guidance information records the source non-enabled blockchain of the cross-chain transaction to be executed, and the executor non-enabled blockchain determines the source non-enabled blockchain of the cross-chain transaction to be executed through the cross-chain guidance information generated by the enabling blockchain; The enabled blockchain acts as a light client of the non-enabled blockchain and synchronously records the block headers of each block in the non-enabled blockchain; The cross-chain guidance information also records the block height corresponding to the cross-chain transaction that needs to be executed in the source party's non-enabled blockchain, wherein the block height corresponding to the cross-chain transaction that needs to be executed in the source party's non-enabled blockchain is the block height of the latest block of the source party's non-enabled blockchain currently recorded by the enabled blockchain.

Images