CN113922971B

CN113922971B - Cross-chain interaction method and device

Info

Publication number: CN113922971B
Application number: CN202111406526.6A
Authority: CN
Inventors: 陶友贤
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2023-10-27
Anticipated expiration: 2041-06-02
Also published as: CN113922971A; CN113259456A; CN113259456B

Abstract

One or more embodiments of the present disclosure provide a method and apparatus for cross-link interaction. The method comprises the following steps: each destination node in the destination block chain network respectively acquires a cross-chain message sent by at least one source node in the source block chain network to the destination block chain network, checks the cross-chain message acquired by the destination node, and broadcasts a reconstruction message in the destination block chain network under the condition of passing the check; each destination node adds a destination node signature generated by itself to the received reconstructed message and continues broadcasting in the destination blockchain network under the condition that the received reconstructed message passes verification; any destination node generates a blockchain transaction according to the received reconstruction message and submits the blockchain transaction to the destination blockchain network for consensus under the condition that the received reconstruction message passes the Bayesian fault-tolerant check; each destination node performs the same blockchain transaction of the plurality of blockchain transactions through the consensus.

Description

Cross-chain interaction method and device

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and apparatus for cross-chain interaction.

Background

Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Nodes in the blockchain network verify and store data using a chained data structure and employ a distributed node consensus algorithm to generate and update the data. In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their related data, so that a blockchain subnetwork can be further built on the blockchain subnetwork.

However, there may be a cross-chain interaction requirement between different blockchain networks so that nodes in the source blockchain network may initiate interaction requests to the destination blockchain network. However, because different nodes in the destination blockchain network may receive multiple cross-link messages generated by different nodes in the source blockchain sub-network, how to ensure that each node in the destination blockchain network obtains a consistent processing result after processing the cross-link message sent by the source blockchain network is a problem to be solved in the cross-link interaction process.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and apparatus for cross-chain interaction.

In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, a cross-chain interaction method is provided, including:

each destination node in the destination block chain network respectively acquires a cross-chain message sent by at least one source node in the source block chain network to the destination block chain network;

each destination node checks the acquired cross-link message and constructs a multi-signed reconstruction message aiming at the message content of the cross-link message in the destination blockchain network under the condition of passing the check;

under the condition that any destination node determines that the signature number of destination node signatures contained in any received reconfiguration message passes the Bayesian fault-tolerant check, generating a blockchain transaction according to any reconfiguration message and submitting the blockchain transaction to the destination blockchain network for consensus;

each destination node performs the same blockchain transaction of the plurality of blockchain transactions through the consensus.

According to a second aspect of one or more embodiments of the present specification, there is provided a cross-chain interaction device comprising:

the message receiving unit enables each destination node in the destination block chain network to respectively acquire a cross-chain message sent by at least one source node in the source block chain network to the destination block chain network;

The message construction unit enables each destination node to check the acquired cross-link message and constructs a multi-signed reconstruction message aiming at the message content of the cross-link message in the destination block chain network under the condition of passing the check;

the transaction generating unit is used for enabling any target node to generate a blockchain transaction according to any reconstruction message and submit the blockchain transaction to the target blockchain network for consensus under the condition that the number of signatures of the target node signatures contained in any received reconstruction message is determined to pass the Bayesian fault-tolerant verification;

and the transaction execution unit enables each destination node to respectively execute the same blockchain transaction in the commonly-recognized multiple blockchain transactions.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any of the first aspects by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as in any of the first aspects.

Drawings

FIG. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a call to a smart contract provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of creating and invoking a smart contract provided by an exemplary embodiment.

FIG. 4 is a schematic diagram of a blockchain sub-network based on a blockchain master network in accordance with an exemplary embodiment.

FIG. 5 is a schematic diagram of a cross-chain interaction method provided by an example embodiment.

FIG. 6 is a flowchart of a cross-chain interaction method provided by an exemplary embodiment.

Fig. 7 is a schematic diagram of an apparatus according to an exemplary embodiment.

FIG. 8 is a block diagram of a cross-chain interaction device provided by an example embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. The public chain is represented by bitcoin and ethernet, and participants joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or federation, it is possible to provide the functionality of a smart contract. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, support users create and invoke some complex logic in the ethernet network, which is the biggest challenge for ethernet to distinguish from the bitcoin blockchain technology. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, bob sends a transaction containing information to create a smart contract to the ethernet network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. "0x6f8ae93 …" in fig. 1 represents the address of this contract, the data field of the transaction may hold byte code and the to field of the transaction is empty. After agreement is reached between nodes through the consensus mechanism, this contract is successfully created and can be invoked in a subsequent process. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain, and the contract account is stored with a specific address. The behavior of the smart contract is controlled by the contract code. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage).

Still taking the ethernet as an example, as shown in fig. 2, bob sends a transaction for invoking a smart contract to the ethernet network, the EVM of a node may execute the transaction and generate the corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account of the transaction initiator (i.e., bob), the "0x6f8ae93 …" in the to field represents the address of the called smart contract, the value field is the value of the ethernet in the ethernet, and the data field of the transaction holds the method and parameters for calling the smart contract. The value of the policy may change after invoking the smart contract. Subsequently, a client may view the current value of the policy through a blockchain node (e.g., node 6 in FIG. 2). The intelligent contract is independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating a smart contract and invoking a smart contract is shown in fig. 3. To create an intelligent contract in the ethernet, the intelligent contract needs to be written, compiled into byte codes, deployed to a blockchain and the like. The intelligent contract is called in the Ethernet, a transaction pointing to the intelligent contract address is initiated, and intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet network.

It should be noted that, in addition to the smart contracts that can be created by the user, the smart contracts can also be set by the system in the creation block. Such contracts are commonly referred to as an opening contract. In general, some blockchain networks may be configured with data structures, parameters, attributes, and methods in the creating contracts. In addition, an account with system administrator rights may create a system level contract, or modify a system level contract (simply referred to as a system contract). In addition, different blockchain networks may employ various virtual machines in addition to the EVM in the ethernet, which is not limited herein.

After executing a transaction invoking the smart contract, a node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the smart contract. In this way, information about the result of contract execution can be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in a receipt. The messaging mechanism may implement messaging through events in the receipt to trigger the blockchain node to perform the corresponding process. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above examples, the number of events may be one or more; wherein each event includes fields such as a theme (topic) and data (data), respectively. The block link point may perform a preset process by listening to the topic of the event, in case of listening to the predefined topic, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism described above, the client having the monitoring function is located at the monitoring party (such as the user having the monitoring requirement), for example, the SDK for implementing the monitoring function is running on the client, and the client monitors the event generated by the blockchain node, and the blockchain node only needs to normally generate the receipt. In addition to the event mechanism described above, the transmission of transaction information may be accomplished in other ways. For example, the listening code may be embedded in the blockchain platform code running at the blockchain point such that the listening code may listen to one or more of the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc., and send the monitored data to the predefined listener. Since the snoop code is deployed in the blockchain platform code, rather than at the client of the snooper, such a snoop code-based implementation is relatively more proactive than an event mechanism. The above-mentioned monitoring code may be added into the blockchain platform code by a developer of the blockchain platform in the development process, or may be embedded by a monitoring party based on the own requirement, which is not limited in this specification.

Blockchain technology differs from one of the decentralized features of conventional technology in that accounting is performed on individual nodes, otherwise known as distributed accounting, rather than conventional centralized accounting. The blockchain system is to be a hard-to-break, public, untampered, decentralised, honest and trusted system for data records, and needs to be secure, clear and irreversible for distributed data records in as short a time as possible. In different types of blockchain networks, in order to keep account books consistent among the nodes of each record account book, a consensus algorithm is generally adopted to ensure that the above-mentioned consensus mechanism is adopted. For example, a block granularity consensus mechanism may be implemented between blockchain nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block. For another example, a transaction granularity consensus mechanism may be implemented between blockchain nodes, for example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is approved by other nodes, each node approving the blockchain transaction may respectively add the blockchain transaction to its own maintained latest block, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism that the blockchain node achieves the consensus of the whole network about the blockinformation (or blockdata), and can ensure that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm, honeybadgenbft algorithm, etc.

Because of the decentralization characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same block data, and the special requirements of part of nodes cannot be met. Taking a blockchain as an example, all the coalition members (i.e., node members in the coalition) can form a blockchain network, all the coalition members respectively have corresponding blockchain nodes in the blockchain network, and all transactions and related data occurring on the blockchain network can be obtained through the corresponding blockchain nodes. In some cases, however, there may be some coalition members desiring to complete transactions with security requirements, which may be desirable to both be able to document on the blockchain or to take advantage of other advantages of blockchain technology, and to avoid other coalition members from viewing such transactions and related data. Although the members of the federation may additionally build a new blockchain network in a manner similar to that described above that includes all of the members of the federation, building a new blockchain network from scratch requires significant resources and is time consuming, either in the process of building the blockchain network or in the process of post-build configuration. The requirements among the alliance members are often temporary or have certain timeliness, so that the new blockchain network quickly loses the meaning of existence due to the disappearance of the requirements, thereby further increasing the chain building cost of the blockchain network. The requirements between the members of the federation often vary, and the members of the federation corresponding to each requirement also often vary, so that a new blockchain network may need to be built whenever the members of the federation change, resulting in a great waste of resources and time.

To this end, the established blockchain network may be used as a blockchain master network, and the blockchain subnetwork may be established based on the blockchain master network. Then, in a federated chain scenario such as that described above, federated members may build the required blockchain subnetwork on the blockchain subnetwork's basis based on their own needs, already participating in the blockchain subnetwork. Because the blockchain subnetwork is built on the basis of the blockchain main network, compared with a completely independent blockchain network, the building process of the blockchain subnetwork has the advantages of greatly reduced consumed resources, time consumption and the like, and extremely high flexibility.

The process of quickly constructing the blockchain sub-network based on the blockchain main network is as follows: each main network node in the block chain main network respectively acquires a transaction for constructing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, and the configuration information comprises identity information of node members. Then, each main network node in the blockchain main network respectively executes the transaction; when the first main network node belongs to the node member indicated by the configuration information, node equipment for deploying the first main network node generates an creation block containing the configuration information based on the transaction and starts a first sub-network node belonging to the block chain sub-network.

The transaction for constructing the blockchain sub-network can be initiated by an administrator of the blockchain main network, namely, the administrator is only allowed to construct the blockchain sub-network on the basis of the blockchain main network, and the construction authority of the blockchain sub-network is prevented from being opened to the common users, so that the safety problem caused by the construction authority is prevented. In some cases, a common user of the blockchain main network can be allowed to initiate the transaction for constructing the blockchain sub-network, so that the networking requirement of the common user is met, and the common user can still quickly construct the blockchain sub-network under the condition that an administrator is inconvenient to initiate the transaction.

For example, as shown in fig. 4, the blockchain home network is subnet0, and the blockchain nodes included in the subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Suppose nodeA, nodeB, nodeC and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate transactions to build the blockchain subnetwork, then the above-described transactions to build the blockchain subnetwork may be initiated by nodeA to subnet 0; if the nodeE is an administrator and only the administrator is allowed to initiate the transaction for constructing the blockchain sub-network, then the nodeA-nodeD need to request the nodeE so that the nodeE initiates the transaction for constructing the blockchain sub-network to the subnet 0; if nodeE is an administrator but allows a common user to initiate transactions to build the blockchain subnetwork, then nodeA-nodeE may all initiate transactions to subnet0 to build the blockchain subnetwork. Of course, whether an administrator or an ordinary user, the blockchain node that initiates the transaction of building the blockchain subnetwork does not necessarily participate in the built blockchain subnetwork, such as, although the blockchain subnetwork is ultimately built up by nodeA, nodeB, nodeC and nodeD, the transaction of building the blockchain subnetwork may be initiated by nodeE to subnet0, and not necessarily by nodeA-nodeD.

When the blockchain subnetwork is built on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain subnetwork and the blockchain main network. For example, when the blockchain subnet1 is built on the subnet0 shown in fig. 4, the subnet0 may be considered to be in the first layer, the subnet1 is in the second layer, the subnet0 is a parent network of the subnet1, and the subnet1 is a subnet of the subnet 0. The blockchain subnetwork may also be a corresponding blockchain subnetwork, for example, another blockchain subnetwork 3 may be further constructed based on the subnetwork 1 in fig. 4, where the subnetwork 1 may be considered as a parent network corresponding to the subnetwork 3, the subnetwork 3 may be a child network of the subnetwork 1, and the subnetwork 3 may be a grandchild network of the subnetwork 0, and similarly, the subnetwork 3 may still be a new blockchain subnetwork based thereon, so that each blockchain network may form such a multi-level tree structure, and in this specification, any blockchain network is managed by its corresponding parent network, that is, by the blockchain network constructing any blockchain network, so that in the blockchain network system such as fig. 4, each blockchain subnetwork is a blockchain network corresponding to a node of another blockchain node, and any node is managed by its own blockchain network as a main network. The blockchain main network in the present specification may be an underlying blockchain network, where the underlying blockchain network refers to a blockchain sub-network that is not built on the basis of other blockchain networks, so that there is no blockchain network other than the blockchain main network that can manage the blockchain main network, for example, the subnet0 in fig. 4 may be considered as a blockchain main network belonging to the type of the underlying blockchain network, and the subnet0 manages the subnet0 itself, and of course, the blockchain main network may also be a sub-network of other blockchain networks, which is not limited in this specification. The blockchain network tree system realizes layer-by-layer management by managing the corresponding child nodes through the father node, reduces the management pressure of the blockchain main network, and simultaneously avoids exposing the child network information of the upper network to the lower network, thereby realizing the secret management of each level of network.

After the transaction for constructing the blockchain sub-network is sent to the blockchain main network, the nodes in the blockchain main network are subjected to consensus, and after the transaction passes through the consensus, the nodes in each main network execute the transaction so as to finish the construction of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, which is not limiting in this description.

By including configuration information in the transactions for constructing the blockchain sub-network, the configuration information may be used to configure the constructed blockchain sub-network so that the constructed blockchain sub-network meets networking requirements. For example, by including node membership information in the configuration information, it may be specified which blockchain nodes are included in the established blockchain subnetwork.

The identity information of the node member may include a public key of the node, or other information capable of characterizing the identity of the node, such as a node ID, which is not limited in this specification. Taking the public key as an example, each blockchain node has one or more public and private key pairs, the private key is held by the blockchain node, and the public key is disclosed and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Thus, for blockchain nodes that are desired to be node members of a blockchain subnetwork, the public keys of those blockchain nodes can be added to the transactions that constitute the blockchain subnetwork as identity information for the node members.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When constructing a blockchain subnetwork, instead of the first main network node directly joining the blockchain subnetwork to become its node member, the first subnetwork node needs to be generated by the node device for deploying the first main network node and become the node member in the blockchain subnetwork by the first subnetwork node. The first main network node and the first sub network node correspond to the same blockchain member, for example, in a alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub network node belongs to a blockchain sub network, so that the blockchain member can participate in transactions of the blockchain main network and the blockchain sub network respectively; and because the block chain main network and the block chain sub network belong to two independent block chain networks, the block generated by the first main network node and the block generated by the first sub network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node equipment, so that the mutual isolation between the storages respectively used by the first main network node and the first sub network node is realized, the data generated by the block chain sub network can only be synchronized among the node members of the block chain sub network, the data generated by the block chain sub network can not be obtained by the block chain members only participating in the block chain main network, the data isolation between the block chain main network and the block chain sub network is realized, and the transaction requirement between partial block chain members (namely the block chain members participating in the block chain sub network) is met.

It can be seen that the first main network node and the first sub-network node are logically divided blockchain nodes, and from the aspect of the physical device, the node device where the first main network node and the first sub-network node are deployed is equivalent to the above-mentioned node device which participates in the blockchain main network and the blockchain sub-network at the same time. Because the blockchain main network and the blockchain sub-network are mutually independent, the identity systems of the two blockchain networks are mutually independent, and even if the first main network node and the first sub-network node can adopt identical public keys, the two blockchain main network node and the first sub-network node can still be regarded as different blockchain nodes. For example, in fig. 4, nodeA in subnet0 corresponds to the first main network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to the first sub network node. Therefore, the identity systems are independent, so that even if the public key adopted by the first subnet node is different from the public key adopted by the first main network node, implementation of the scheme of the specification is not affected.

Of course, the node members of the blockchain subnetwork are not necessarily only part of the node members of the blockchain main network. In some cases, node members of the blockchain subnetwork may be completely consistent with node members of the blockchain subnetwork, where all blockchain members may obtain data on the blockchain subnetwork and the blockchain subnetwork, but the data generated by the blockchain subnetwork and the blockchain subnetwork may still be isolated from each other, for example, one type of service may be implemented on the blockchain subnetwork, and another type of service may be implemented on the blockchain subnetwork, so that service data generated by the two types of services may be isolated from each other.

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identification of the blockchain subnetwork, identity information of an administrator of the blockchain subnetwork, attribute configuration for blockchain platform code, and the like, are not limiting in this description. The network identification is used to uniquely characterize the blockchain subnetwork, and thus the network identification of the blockchain subnetwork should be distinguished from the blockchain main network and other blockchain subnetworks built on the blockchain main network. The identity information of the administrator of the blockchain subnetwork, such as a public key that is a member of the node of the administrator; the administrators of the blockchain main network and the blockchain sub network may be the same or different.

One of the advantages of constructing the blockchain subnetwork through the blockchain main network is that the first main network node is already deployed on the node equipment generating the first subnetwork node, so that the blockchain platform code used by the first main network node can be multiplexed on the first subnetwork node, repeated deployment of the blockchain platform code is avoided, and the construction efficiency of the blockchain subnetwork is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may multiplex the attribute configuration employed on the first main network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may employ the attribute configuration, so that the attribute configuration employed by the first subnet node is not limited to the attribute configuration of the first main network node, and is independent of the first main network node. The attribute configuration for the blockchain platform code may include at least one of: code version number, whether consensus is required, consensus algorithm type, block size, etc., which is not limiting in this description.

The transactions that constitute the blockchain subnetwork include transactions that invoke contracts. The transaction may specify the address of the smart contract that was invoked, the method that was invoked, and the parameters that were entered. For example, the invoked contract may be the aforementioned creation contract or system contract, the invoked method may be a method of building a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

wherein the from field is information of the initiator of the transaction, such as an Administrator, indicating that the initiator is an Administrator; the to field is the address of the called smart contract, e.g., the smart contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method used to construct the blockchain subnetwork in the Subnet contract may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by generation, which is specifically the configuration information described above in the above example.

Taking nodes nodeA-nodeE on Subnet0 as an example, the transaction of calling the AddSubNet () method in the Subnet contract is executed. After the transaction passes the consensus, performing an AddSubNet () method by using the nodeA-nodeE respectively, and transmitting configuration information to obtain a corresponding execution result.

The execution result of the contract may include the configuration information, and the execution result may be in the receipt described above, and the receipt may include an event related to execution of the AddSubnet () method, that is, a networking event. Topic of networking events may contain predefined networking event identifications to distinguish from other events. For example, in an event related to execution of the AddSubnet () method, the content of the topic is a keyword subnet, and the keyword is distinguished from topic in an event generated by other methods. Then, the nodeA-nodeE can determine to monitor the event related to execution of the AddSubnet () method, i.e., networking event, by monitoring the topic contained in each event in the generated receipt. For example, the event in the receipt is as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the 1 st event is monitored, determining that the event is irrelevant to the AddSubnet () method because the content of the topic is other; and when the 2 nd event is monitored, determining that the event is related to an AddSubNet () method because the content of the topic is subnet, and further reading a data field corresponding to the event, wherein the data field contains the configuration information. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

A public key of nodeA, IP of nodeA, port number … of nodeA;

public key of nodeB, IP of nodeB, port number … of nodeB;

a public key of nodeC, IP of nodeC, port number … of nodeC;

a public key of nodeD, IP of nodeD, port number … of nodeD;

}

wherein, subnet1 is the network identification of the blockchain subnet that it is desired to create. Each blockchain node in the blockchain master network may record network identifications of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in a Subnet contract as described above, for example, and may specifically correspond to the value of one or more contract states contained in the Subnet contract. Then, nodeA-nodeE can determine whether the subnet1 exists according to the recorded network identifications of all the created blockchain subnets; if not, it is indicated that subnet1 is a new block chain subnet that currently needs to be created, and if so, it is indicated that subnet1 already exists.

In addition to employing network identifications of new blockchain subnets that are desired to be created, predefined new network identifications may also be employed that indicate corresponding networking events for building new blockchain subnets. For example, the subnet1 may be replaced by a newsubnet, where the newsubnet is a predefined newly created network identifier, and when it is identified that the data field contains the newsubnet, the nodes a to e may determine that the event containing the newsubnet is a networking event, and need to create a new blockchain subnet.

In addition to the network identifier subnet1, the data field also contains identity information of each node member and other contents. The node equipment for deploying the first main network node can monitor the generated receipt, and acquire the configuration information or the creation block contained in the networking event by the node equipment for deploying the first main network node under the condition that the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member. For example, when determining that subnet1 is a newly constructed blockchain subnet, nodeA to nodeE further identifies the identity information of the node members contained in the data field to determine the processing mode thereof. For example, nodeA to nodeD may find that the data field contains identity information such as its own public key, IP address and port number, and assume that nodeA to nodeD are respectively disposed on the node devices 1 to 4, taking nodeA and node device 1 as examples: the nodeA triggers the node device 1, so that the node device 1 obtains configuration information from the data field based on the message mechanism and generates an creation block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated creation block, thereby becoming a subnet node of the subnet 1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. And, the nodeE finds that the identity information contained in the data field does not match with the nodeE, and assuming that the nodeE is deployed on the node device 5, the node device 5 does not generate an creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first main network node and the first sub network node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may include the identity information generated for the nodeA1 to nodeD1 in advance, and is different from the identity information of the nodeA to nodeD. Taking nodeA as an example, if nodeA finds the identity information of nodeA1 in the data field, nodeA triggers the node device 1 to generate an created block, deploys nodeA1, and loads the created block by nodeA 1; the processing manners of nodeB to nodeD are similar and are not described in detail herein.

In addition to the configuration information, the execution result of the contract may include an creation block. In other words, besides the configuration information can be contained in the data field, the generation block containing the configuration information can be directly generated in the process of executing the contract call, so that the generation block is contained in the data field, and for the nodeA-nodeD, the corresponding node devices 1-4 can directly obtain the generation block from the data field through a message mechanism without self-generation, so that the deployment efficiency of the nodeA 1-nodeD 1 can be improved.

In the present specification, the transaction for constructing the blockchain subnetwork may not be a transaction for calling the intelligent contract, so that the blockchain network that does not support the intelligent contract may also implement the technical solution of the present specification, thereby quickly creating the blockchain subnetwork on the basis of the blockchain main network. For example, a set of networking transaction type identifiers may be predefined, and when a transaction includes the networking transaction type identifier, the transaction is indicated as being for building a new blockchain subnet, i.e., the transaction is a transaction that builds a blockchain subnet. The blockchain platform code may include associated processing logic for constructing a blockchain subnetwork, such that when executing a transaction, a first main network node running the blockchain platform code may trigger node devices deploying the first main network node to generate an creation block including configuration information and activate the first subnetwork node based on the processing logic if the transaction is found to include the networking transaction type identifier and the first main network node belongs to a node member indicated by the configuration information in the transaction, and the creation block is loaded by the first subnetwork node to form a blockchain node in the blockchain subnetwork.

The node device runs blockchain platform code by pulling up a process and creating an instance in the process, equivalent to deploying a blockchain node on the node device. For a first master network node, creating, by a node device, a first instance in the process and running blockchain platform code from the first instance. Similarly, for a first subnet node, a second instance is created by the node device in the process described above that is distinct from the first instance and formed by the second instance running blockchain platform code. When the first instance and the second instance are located in the same process, because cross-process interaction is not involved, the deployment difficulty of the first subnet node can be reduced, and the deployment efficiency can be improved; of course, the second instance may also be in a different process on the node device than the first instance, which is not limited by the present description. In fact, each blockchain node deployed on any node device involved in the embodiments of the present disclosure is a different blockchain instance running on the any node device, the blocks generated by each blockchain node deployed on any node device are respectively stored in different stores (such as databases) on the any node device, and the stores used by each blockchain node deployed on any node device are isolated from each other.

By the method, the blockchain sub-network can be created on the blockchain main network. Taking fig. 4 as an example, the subnet0 originally includes the nodes a to e, and the subnet1 may be constructed based on the subnet0, where the subnet1 includes the nodes a1 to d1, and the nodes a and a1, the nodes b and b1, the nodes c and c1, and the nodes d and d1 are respectively disposed on the same node device. Similarly, a subnet2 or more blockchain subnets may also be built on subnet0, where subnet2 contains nodeA2, nodeB2, nodeC2 and nodeE2, with nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 deployed on the same node device, respectively. And, subnet1, subnet2, etc. may be used as the blockchain main network, and a blockchain sub-network may be further constructed on the basis of the blockchain main network, for example, a blockchain sub-network subnet3 may be constructed on the basis of subnet1, the process is similar to that of the construction of subnet1 or subnet2, only the blockchain main network is replaced by blockchain sub-network subnet1, which is not described herein, and finally, the obtained subnet3 includes nodeA3, nodeB3 and nodeC3, so that nodeA and nodeA1, nodeA2, nodeA3, nodeB and nodeB1, nodeB2, nodeB3, nodeC and nodeC1, nodeC2, and nodeC3 are respectively deployed on the same node device.

There may be a need for cross-chain interactions, either between different blockchain main networks or between different blockchain subnets established in the manner described above. However, because there are typically multiple source blockchain nodes that send a cross-chain message (i.e., initiate a cross-chain request) and destination blockchain nodes that respond to the cross-chain message, it is a challenge to be solved in the cross-chain interaction process how to ensure consistency of the cross-chain message from the source blockchain network processed by each destination node in the destination blockchain network, as different destination nodes in the destination blockchain network may receive multiple cross-chain messages generated by different source nodes in the source blockchain subnetwork.

In order to solve the problem, the specification provides a cross-link interaction method, after destination nodes in a destination blockchain network respectively acquire cross-link messages generated by source nodes in a source blockchain network, a reconstructed message is constructed according to the cross-link messages passing verification and the signed reconstructed message is broadcast in the destination blockchain network, other destination nodes receiving the reconstructed message sign again and continue broadcasting after verification is passed until any source destination node passes the Bayesian fault-tolerant check of the reconstructed message according to the total quantity of the destination nodes and the signature quantity of the destination node signature contained in the reconstructed message (indicating that enough destination nodes already exist at the moment to approve the reconstructed message), block chain transactions are generated according to the reconstructed message and submitted to consensus, and then the same block chain transactions are respectively executed by all destination nodes. On the one hand, the repeated verification and signature of the reconstructed message by a plurality of destination nodes ensure that the reconstructed message used for generating the blockchain transaction is commonly accepted by enough destination nodes; on the other hand, the same blockchain transaction is respectively executed by each destination node, so that each destination node is ensured to respectively execute the blockchain transaction only once, and the consistency of the cross-chain message processed by each destination node is effectively ensured.

The cross-chain interaction scheme of the present specification will be briefly described with reference to fig. 5 corresponding to fig. 4. Referring to fig. 5, fig. 5 is a schematic diagram of a cross-link interaction method according to an exemplary embodiment. As shown in fig. 4, a blockchain subnet1 and a blockchain subnet2 are created on the basis of a blockchain main network subnet0, and fig. 5 is a schematic diagram of a process for realizing cross-chain interaction of the subnet1 and the subnet2 based on the subnet 0.

As shown in fig. 5, the node device to which any node in the subnet1 and the subnet2 belongs may be deployed with a corresponding database and a virtual machine, taking fig. 5 as an example, the nodeD1 in the subnet1 is specifically a blockchain node instance (hereinafter referred to as a blockchain node) formed by running a pre-deployed blockchain platform code in the locally deployed virtual machine by the node device 4 to which the node device belongs, and the nodeD1 is stored as related data of the blockchain node in the running process in the database corresponding to the nodeD 1. The blockchain network to which the blockchain node deployed in the node device belongs may be a blockchain main network or a blockchain sub-network established in the foregoing manner, and of course, the present solution may also be applied to an independent blockchain network (i.e., the blockchain network is not established based on other blockchain networks, and no other blockchain network is established based on the blockchain network). In other words, the cross-chain interaction method described in the present specification can be applied to any two blockchain networks, and the present specification does not limit the interrelation between the blockchain networks and other blockchain networks. In addition, a blockchain consensus code may be deployed in the node device, which may be run by the node device to locally form a consensus plug-in instance; and, P2P plug-in code managed in plug-in form may be deployed in the node device, and the node device may run the P2P plug-in code to form a P2P plug-in instance locally, that is, a P2P plug-in. The node device is further configured with a blockchain service code, and the node device can run the blockchain service code to form service instances locally, wherein at least one service instance can be implemented in any node device, such as a storage instance for implementing a data read/write function, a calculation instance for implementing a calculation function such as privacy calculation, an encryption instance for implementing a data encryption function, and the like, which are not described again.

In particular, in the case that the cross-link interaction method described in the present specification is applied to two blockchain subnets under the blockchain main network management, the main network node in the blockchain main network is deployed on the node device to which the source node in the source blockchain network or the destination node in the destination blockchain network belongs, in combination with fig. 4 and fig. 5, the main network node nodeD is also deployed on the node device 4 to which the nodeD1 in the subnet1 belongs, the main network node nodeD is also deployed on the node device 5 to which the nodeD 2 in the subnet2 belongs, and since the P2P plug-in on the node device can be shared by each blockchain node on the node device, although no direct network connection link exists between the source node 1 and the subnet2, the nodeD deployed on the node device 4 and the nodeD device 5 have been previously established by the network connection link based on the P2P plug-in when the subnet0 is formed, the nodeD device in the subnet1 can be called by the network connection link in advance, and thus the communication link between the node device and the network 2 in the network can be further established by the network link between the node device and the network device 2 in the network device and the network device in the network can be further established by the network link (for example, the communication link between the node device and the network 2 in the network can be established by the network link between the node device and the network device in the network device and the network device 2).

The data stored by each node in the subnet1 may need to be used in the process of implementing the service function, so that the subnet1 may request to obtain the data from the subnet2, and in the process of obtaining the data through the cross-link interaction scheme described in the specification, the subnet1 is the source blockchain network, and the subnet2 is the destination blockchain network. For example, subnet1 may send a cross-link request to subnet2 in order to obtain the contract status of a particular field in a particular contract stored in the node database of subnet 2. It can be understood that "the subnet1 sends the cross-link request to the subnet 2" is that "the subnet node (i.e. the source node) in the subnet1 sends the cross-link request to the subnet node (i.e. the destination node) in the subnet 2".

Specifically, in the case where the cross-link interaction method described in the present specification is applied to two blockchain subnets under the blockchain master management, any node in the subnet1 may encapsulate the network identifier of the target blockchain network subnet2 in the cross-link request, and broadcast the cross-link request to the P2P plugins running on each node device where the master node is deployed by invoking the P2P plugins that are locally deployed by the node device and are shared with the master node in the subnet0 through the network connection link of the subnet 0. In an embodiment, if the node a1 in the subnet1 sends a cross-link request through the P2P plugin on the node device 1, all the other node devices 2 to 5 deployed with the main network node will receive the cross-link request, for example, after receiving the cross-link request, the P2P plugin on the node device 5 will determine, according to the network identifier carried by the cross-link request, whether the node device 5 is locally deployed with a blockchain node in the blockchain network corresponding to the network identifier, and obviously, the node device 5 is deployed with a node e2 in the subnet2, so the P2P plugin on the node device 5 will further forward the cross-link request to the node e2 based on the network identifier, and after receiving the cross-link request, the P2P plugin on the node device 4 will also forward based on the network identifier carried by the node device 4, but since the node device 4 is not locally deployed with a blockchain node in the subnet2, the node device 4 will not keep the cross-link request, but will further forward the cross-link request to other nodes deployed with the main network node. In addition, any node in the subnet1 can encapsulate the network identifier in the cross-link request, and can encapsulate the identity information of any node in the target blockchain network, such as the node ID and the node public key, in the cross-link request, so that the cross-link request can be transmitted to the node device to which each main network node belongs in a broadcast manner in the process of invoking the P2P plug-in, but directly make the P2P plug-in send to the node device specified by the node identity information carried in the cross-link request in a point-to-point communication manner, for example, the nodeD1 in the subnet1 can encapsulate the identity information of the node2 in the cross-link request and invoke the P2P plug-in locally operated by the node device 4, so that the P2P plug-in can send the cross-link request to the node device 5 on which the node2 in the subnet2 and the node2 in the sub-network node simultaneously belong in a unicast manner according to the identity information of the node2, and can also forward the request to the cross-link 2 through the node device carried by the node device to the cross-link 2.

The above process describes a process that the source blockchain network sends a message request to the destination blockchain network through a network connection link established by the blockchain main network, and similarly, the destination blockchain network can also realize message transmission to the source blockchain network by calling a local P2P plug-in, for example, the cross-chain data corresponding to the block request sent by the source blockchain network is returned to the source blockchain network, thereby realizing network communication between a source node in the source blockchain network and a destination node in the destination blockchain network through a formed bidirectional communication channel between the source blockchain network and the destination blockchain network.

The data acquisition request may be sent to the main network node in the subnet0, and the main network node forwards the request to the corresponding subnet2, where the destination node in the subnet2 may verify the received data acquisition request to ensure validity of the responded data acquisition request, and respond if the verification passes. The process of the destination node responding to the data acquisition request is that the data (namely, the data required by the subnet 1) executed by the received data acquisition request is determined, and the cross-link message is generated based on the data and returned to the subnet1 through the main network node in the subnet 0. Similarly, the source node in the subnet1 can perform validity verification on the received cross-link message, and continue to implement related service functions by using the data contained in the cross-link message under the condition that the verification is passed.

Fig. 5 is merely an exemplary illustration of blockchain subnets subnet1 and subnet2 as examples in connection with fig. 4. In fact, cross-chain interactions may be implemented between each of the blockchain networks in fig. 4, and the present description is not limited to the relationship between the blockchain networks of cross-chain interactions. For example, the above-mentioned blockchain main network subnet0 and the blockchain sub network subnet1, the blockchain main network subnet0 and the blockchain sub network subnet3 (i.e. the grandchild network of the subnet 0), the blockchain sub network subnet2 and the subnet3, etc. can all implement cross-chain interaction, and specific processes are not repeated.

The cross-chain interaction scheme of the present specification is described in detail below in conjunction with fig. 6. Referring to fig. 6, fig. 6 is a schematic diagram of a cross-link interaction method according to an exemplary embodiment. As shown in fig. 6, the method is applied to a blockchain system including a source blockchain network and a destination blockchain network, and may include the steps of:

step 602, each destination node in the destination blockchain network obtains a cross-chain message sent by at least one source node in the source blockchain network to the destination blockchain network.

Step 604, each destination node checks the obtained cross-link message, and constructs a multi-signed reconstruction message for the message content of the cross-link message in the destination blockchain network under the condition of passing the check.

In this embodiment, at least one source node in the source blockchain network may send a cross-link message to the destination blockchain network, so that each destination node in the destination blockchain network may check the received cross-link message, and construct a reconstructed message including the message content of the cross-link message and the destination node signature of itself (i.e., the reconstructed message includes the destination node signature of the destination node constructing the reconstructed message) according to the cross-link message that passes the check, and may further broadcast the reconstructed message to other destination nodes in the destination blockchain network. Any destination node in the destination block chain network can verify the reconstruction message received by itself, and adds the destination node signature generated by itself to the reconstruction message under the condition that the verification is passed, and continues to broadcast the reconstruction message in the destination block chain network. It can be understood that each destination node in the destination blockchain network performs the above operation, so that after any destination node receives the reconfiguration message broadcast by each other destination node, each reconfiguration message can be processed respectively. Thus, the reconstructed message is appended with multiple signatures by each destination node that received the message, i.e., the reconstructed message contains multiple signatures.

The cross-link interaction process between blockchain subnets subnet1 and subnet2 in the network architecture shown in fig. 4 is illustrated as an example. At least one source node (source nodes nodeA1, nodeB1, nodeC1 and/or nodeD 1) in the subnet1 can send a cross-link message to the subnet2 through the blockchain main network subnet0 in the unicast, multicast or broadcast mode, and after each destination node (destination nodes nodeA2, nodeB2, nodeC2 and node2) in the subnet2 respectively acquires the cross-link message, the corresponding processing can be performed in response to the received cross-link message. Taking the destination node nodeA2 as an example, after receiving the cross-link messages sent by each source node, the nodeA2 can respectively verify each cross-link message, and then generate and broadcast a reconstruction message in the destination blockchain network according to each cross-link message under the condition that verification is passed. It can be appreciated that, because each of the cross-link messages received by the nodeA2 is generated by each of the source nodes according to the same service event, the message content of each of the cross-link messages is the same, and each of the cross-link messages includes the source node signature generated by the source node of the sender. Thus, nodeA2 can sign the (same) message content contained in each received cross-chain message and construct a reconstructed message from the message content and its own target node signature. Further, the nodeA2 may broadcast the constructed reconfiguration message to other destination nodes, so that the other destination nodes perform corresponding processing respectively, and specific processing steps are described in the following embodiments, which are not repeated herein. The following describes in detail, in connection with a plurality of embodiments, a specific process for a destination node to obtain the message content included in the received cross-link message and verify each cross-link message.

In an embodiment, to ensure the privacy of the sent cross-link message and avoid disclosure of the content of the request, the source node may encrypt the cross-link message to be transmitted by adopting a digital envelope technology, where the request corresponds to a specific service that needs to be completed by the source node, and may be used to invoke an intelligent contract, and the message content may include related parameters, contract information of the invoked contract, function information in the invoked contract, and so on. Specifically, the source node may sign the message content by using its own node private key, encrypt the message content and its signature by using a symmetric key, then encrypt the symmetric keys by using the node public keys of the destination nodes, and add the message content and its signature encrypted by the symmetric keys and the digital envelope formed by the symmetric keys encrypted by the node public keys of the destination nodes to the cross-link message. Correspondingly, any destination node which receives the cross-link message can decrypt the encrypted symmetric key contained in the request through the private key of the node, further decrypt the symmetric key obtained by decryption to obtain the message content and the signature, and then verify the signature through the public key of the node of the source node. If the signature passes, the received message content is indicated to be actually sent by the corresponding source node (not tampered), so that the message content can be subjected to subsequent processing so as to return the corresponding cross-chain message to the source blockchain network. On the one hand, the message content with relatively large data volume is encrypted by adopting the symmetric key, and the symmetric key with relatively small data volume is encrypted by adopting the asymmetric key, so that the method is beneficial to ensuring the relatively high encryption speed, and the encrypted message content can realize more strict data privacy. On the other hand, because the source node encrypts the symmetric key by using the node public key of each destination node in the destination blockchain network, each destination node can decrypt the symmetric key by using the own node private key after receiving the cross-link message, and then decrypt the message content by using the symmetric key obtained by decryption, thereby realizing the effect of broadcasting the cross-link message in the destination blockchain network.

Taking fig. 4 as an example, in the scenario where subnet1 sends a cross-link message to subnet2, subnet1 is the source blockchain network and subnet2 is the destination blockchain network. Any subnet node nodeA1 in subnet1 can encrypt the message content using the symmetric key, encrypt the symmetric key using the node public keys of each subnet node nodeA2, nodeB2, nodeC2 and nodeE2 in subnet2, and send the encrypted symmetric key and message content to subnet2 through subnet0 contained in the cross-link message. After any subnet node (such as nodeA 2) in the subnet2 receives the cross-link message, under the condition that the private key of the subnet node can decrypt the symmetric key encrypted in the cross-link message, namely the subnet node is determined to be a legal receiver of the cross-link message, and further the symmetric key obtained by decryption can be used for decrypting to obtain the message content.

It can be understood that by using the digital envelope technology, the symmetric key can be encrypted by using the node public keys of a plurality of destination nodes, so that any source node can encrypt the blockchain message by using the public keys of all destination nodes in the destination blockchain network and include the blockchain message in the blockchain message, and further each destination node can decrypt the blockchain message in the blockchain message according to the private key of the destination node, thereby realizing the message cross-chain transmission effect of broadcasting the blockchain message to the destination node by the source node. Of course, in the case of adopting the digital envelope mode, any source node may encrypt the symmetric key in the cross-link message by using only the node public key of one (or more) destination nodes, so as to realize the message cross-link transmission effect of the source node unicasting (or multicasting) the cross-link message to the destination nodes, and the specific process is not repeated. In fact, the specific sending modes of the cross-link message and the cross-link message are not limited in the present specification, for example, the node public key is directly used to encrypt the message content in the cross-link message without adopting a digital envelope, and the details are not repeated.

As previously described, each source node in the source blockchain network may send (i.e., broadcast) a cross-chain message to each destination node in the destination blockchain network, respectively; alternatively, each source node may also send (i.e., unicast or multicast) a cross-chain message to any one (or more) of the destination blockchain networks, respectively, and each destination node synchronizes the received cross-chain message itself to other ones of the destination blockchain networks. It can be seen that the cross-link message is sent by broadcast; and the method also adopts a unicast or multicast mode to send the cross-link message and the receiver synchronizes in the network to which the receiver belongs, so that each destination node in the destination block chain network can be ensured to respectively receive the cross-link message sent by at least one source node in the source block chain network.

In an embodiment, the source blockchain network may be a blockchain sub-network managed by a blockchain main network, the blockchain main network may maintain node identity information of each source node in the active blockchain network, the cross-chain message may include identification information for characterizing node identities of source nodes sending the cross-chain message, at this time, each destination node receiving the cross-chain message may query the blockchain main network for node identity information of the source node sending the cross-chain message, so as to check the identification information, and respond to the cross-chain message if the check passes.

Taking fig. 4 as an example, the blockchain main network subnet0 may maintain node identity information of each subnet node in the blockchain subnet1 and the subnet 2. It can be understood that the cross-link message sent by the source node nodeA1 received by the destination node nodeA2 may include identification information of nodeA1, so that the nodeA2 can determine that the source node corresponding to the request (i.e. the sender of the request) is nodeA1 according to the identification information, so that the nodeA2 can query the blockchain main network subnet0 for the node identification information of nodeA1, and determine whether nodeA1 is a legal source node according to the node identification information returned by the subnet 0. The node identity information stored in the subnet0 may include a network address, a port, a public key of the node, and/or a node identifier of the node. Taking the node public key as an example, the nodeA2 may send a query request containing the node public key of the nodeA1 carried in the cross-link message to the main network node nodeA in the subnet0, where the nodeA may query whether the node public key of the nodeA1 exists in the locally maintained node public keys of the subnet nodes (which are contained in each block-chain subnet built based on the subnet 0), and return a corresponding query result to the nodeA2, so that the nodeA2 may implement verification of the node public key of the nodeA1 according to the query result. If the node public key of the nodeA1 is inquired, checking is passed, namely, the nodeA1 is a trusted sender of the cross-link message received by the nodeA2, so that the nodeA2 can further respond to the cross-link message; otherwise, if the node public key of the nodeA1 is not queried, checking is not passed, namely the nodeA1 is not trusted, and at the moment, the nodeA2 can directly discard the cross-link message sent by the nodeA 1. In addition, in the case that the verification is not passed, the nodeA2 may record the nodeA1 as an illegal source node, so that in the case that the cross-link message sent by the nodeA1 is received again later, the request may be directly discarded, avoiding invalid processing and accelerating response speed. Of course, nodeA2 can also synchronize illegal recordings of nodeA1 to other destination nodes in subnet 2.

In the foregoing embodiment in which the source blockchain network is a blockchain sub-network, the destination blockchain network may also be a blockchain sub-network, and further, the main network node in the blockchain main network and the sub-network node in the blockchain sub-network managed by the blockchain main network may be disposed in the same node device, the main network node and the sub-network node on the node device may share the blockchain plugin running on the node device, and at this time, after each destination node receives the cross-chain message, the node identity information of the source node may be queried through the blockchain plugin, for example, through the blockchain plugin shared with the main network node disposed on the node device to which the destination node belongs, and the identity information of the source node (i.e. the sender of the cross-chain message) corresponding to the cross-chain message maintained by the main network node is read. Taking fig. 4 as an example, if the main network node nodeA and the subnet node nodeA2 are both deployed in the same node device (hereinafter referred to as node device a), they may share the blockchain plugin running on the node device a. At this time, the nodeA2 may query the node identity information of the nodeA1 through the blockchain plugin (of course, if the subnet node nodeA1 is also disposed in the node device a, the nodeA1 may query the node identity information of the nodeA2 through the blockchain plugin). The blockchain plugin may be a plugin deployed in a blockchain main network and used for invoking a subnet management contract, and any blockchain node may query node identity information of a subnet node by sending a transaction for invoking the subnet management contract (e.g. reading subnet node information maintained by the subnet management contract) in the subnet0 through a corresponding main network node. Of course, to ensure query speed, the transactions may be transactions that do not require consensus. Obviously, under the condition that network nodes belonging to different blockchain networks are deployed in the same node equipment, the blockchain plugins of the node equipment are shared by all the nodes, so that the efficient multiplexing of the blockchain plugins can be realized, the number of the blockchain plugins required to be deployed in the node equipment is effectively reduced, the configuration of the node equipment and the deployment flow of the blockchain nodes are simplified, and the deployment efficiency of the blockchain nodes and the management efficiency of the node equipment are improved. In fact, different block chain nodes deployed in the same node device may also share other functional plugins, such as the foregoing P2P plugin instance, the consensus plugin instance, and/or the service instance, which are not described herein.

In the foregoing embodiment in which the source blockchain network is a blockchain subnet, a subnet management contract may be deployed on the blockchain master network, where the subnet management contract is configured to maintain node identity information of subnet nodes in each blockchain subnet constructed based on the blockchain master network; at this time, any destination node may read node identity information of any source node maintained by the subnet management contract, for example, may read identity information of a source node corresponding to the cross-link message (i.e., a sender of the cross-link message) after receiving the cross-link message. Taking fig. 4 as an example, because the subnet1 to which the subnet node nodeA1 belongs and the subnet2 to which the subnet node nodeA2 belongs are both established on the basis of the subnet0, the subnet management contract deployed in the subnet0 can be used for managing the node identity information of each subnet node in the subnet1 and the subnet2, and further, any destination node can also read the node identity information of any source node maintained by the subnet management contract, for example, the node identity information of the nodeA1 can be read by the nodeA 2. By maintaining node identity information of the subnet nodes by a subnet management contract deployed in the blockchain main network, efficient management of the node identity information can be ensured. The subnet nodes in the blockchain subnet directly read the node identity information maintained by the subnet management contract, so that the process of acquiring the node identity information does not need the consensus process of the main network nodes in the blockchain main network, and the acquisition efficiency of the node identity information is improved.

In the foregoing embodiment in which the source blockchain network is a blockchain subnet, the identification information of any subnet node may include a node identifier declared by the subnet node and a subnet identifier of a blockchain subnet to which the subnet node belongs; at this time, each destination node may query the blockchain main network for whether the node identifier and the subnet identifier of the source node declaration that sent the cross-chain message match, respectively. Taking fig. 4 as an example, the node identity information included in the cross-link message sent by the subnet node nodeA1 to nodeA2 may include the node identifier of nodeA1 and the subnet identifier of subnet 1. Therefore, after receiving the cross-link message sent by the nodeA1, the nodeA2 may query the subnet0 whether the node identifier declared by the nodeA1 is matched with the subnet identifier, for example, the nodeA2 may query the main network node a whether all the subnet identifiers maintained by the nodeA2 include the subnet identifier of the subnet1, and further query whether all the node identifiers corresponding to the subnet identifiers of the subnet1 include the node identifier of the nodeA1 if so: if the node identifier of the node nodeA1 is included, the node identifier stated by the nodeA1 is indicated to be matched with the subnet identifier, and further, it is indicated that the cross-link message received by the nodeA2 is really sent by the nodeA1, so that the nodeA2 can further respond to the message; otherwise, if the node identifier of the nodeA1 is not included, it indicates that the node identifier declared by the nodeA1 and the subnet identifier are not matched, and further indicates that the cross-link message received by the nodeA2 may be a false request sent by other nodes, so that the response to the message may be terminated, such as directly discarding the message. By the method, the node identity information of each subnet node maintained in the blockchain main network can be fully utilized to verify the cross-link message sent by the source node, so that the legality of the cross-link message actually processed by the destination node is ensured.

In the foregoing embodiment in which the source blockchain network is a blockchain subnet, the identification information of any subnet node may also include a signature generated by the subnet node based on its own node private key; therefore, each destination node can respectively inquire the node public key of the source node sending the cross-chain message from the blockchain main network, and the signature is checked by adopting the node public key. Taking fig. 4 as an example, the subnet node nodeA1 may generate a signature for the message content included in the cross-link message (or for the cross-link message) based on its own node private key, and include the signature in the cross-link message (or send the signature in association with the cross-link message) to the subnet node nodeA2, so that the nodeA2 may query the subnet0 for the node identity information of the nodeA1 to verify the signature, such as checking the signature according to the node public key of the nodeA1 queried from the subnet 0. Correspondingly, under the condition that the verification sign passes, the cross-link message can be further responded; in the case of failed signature verification, the response to the cross-link message may be terminated, e.g., the cross-link message may be directly discarded or even nodeA1 may be recorded as an illegitimate node.

As described above, since the plurality of cross-link messages received by any destination node are all sent by the same source node, in the case that no illegal node exists in the source blockchain network and the destination blockchain network, the plurality of cross-link messages acquired by any destination node should contain the same message content. Therefore, for a plurality of cross-link messages received by any destination node, the destination node may compare the message content included in each cross-link message first, and verify the cross-link message including the same message content by using the verification method described in the foregoing embodiments. Or, the destination node may also use various fault-tolerant algorithms such as PBFT algorithm, honeybadges bft algorithm, etc. to verify multiple cross-link messages containing the same message content, and in the scenario shown in fig. 4, using the PBFT fault-tolerant algorithm as an example for nodeA2 is only described below. As can be seen from fig. 4, the subnet1, which is the source blockchain network, contains four subnet nodes, namely nodeA1, nodeB1, nodeC1 and nodeD1 (the total of the nodes is 3f+1=4, that is, f=1), so if the nodeA2 receives that the legal cross-link messages sent by at least f+1 (that is, 2) source nodes contain the same message content, it can be determined that these cross-link messages pass the fault tolerance check. Of course, in the scheme practice, the total number of the nodes and the number of the received cross-link messages may also be other values, which is not limited in this specification. Wherein the cross-link message (containing the same message content) that passed the above-mentioned verification is used to construct the reconstructed message.

Further, in all the cross-link messages received by each destination node, if all or part of the cross-link messages pass the above verification of each destination node, each destination node may construct a reconstructed message by using the cross-link messages passing the verification. For example, any destination blockchain network may extract the message content contained in the cross-chain messages that it receives through the verification (the message content of each cross-chain message is the same), and generate a destination node signature for the message content using its own node private key, and then generate a reconstructed message that contains the message content and the destination node signature. After generating the reconfiguration message, the destination blockchain network may broadcast the reconfiguration message in the destination blockchain network so that other destination nodes may obtain the reconfiguration message. It can be understood that each reconstructed message in the destination blockchain network generates a corresponding reconstructed message by using the received cross-chain message passing through the verification and broadcasts the corresponding reconstructed message, so that each destination node can receive the reconstructed messages generated by other destination nodes.

Step 606, when determining that the number of signatures of the destination node signatures contained in any received reconfiguration message passes the bayer fault-tolerant check, any destination node generates a blockchain transaction according to any reconfiguration message and submits the blockchain transaction to the destination blockchain network for consensus.

After the reconstruction information broadcast by other nodes is acquired by each destination node in the destination block chain network, the acquired reconstruction information can be respectively verified, a destination node signature generated by the destination node is added for the reconstruction information (using the private key of the destination node) after the verification is passed, and the reconstruction information is continuously broadcast to other destination nodes in the destination block chain network. As described above, the reconstructed message includes the message content of the cross-link message used for constructing the reconstructed message and the destination node signature generated by the destination node (i.e., the constructor of the reconstructed message) for constructing the reconstructed message, so the verification process for any reconstructed message may include the verification process for the destination node signature included in the reconstructed message; of course, if the reconstructed message further includes a source node signature performed by the source node on a cross-link message where the message content in the reconstructed message is located, the verification process of the destination node on any reconstructed message may further include a verification process of the source node signature included in the reconstructed message, and the specific verification process may be referred to the following embodiments, which are not described herein in detail. It can be understood that, for any reconstructed message, the processing procedure of receiving the reconstructed message broadcast by other nodes, adding the self-generated destination node signature after verification of the reconstructed message, and continuing to broadcast the reconstructed message added with the self-generated destination node signature can be sequentially performed by a plurality of destination nodes in the source blockchain network; and under the condition that any destination node finds that any received reconstruction message contains the destination node signature generated by the destination node, the destination node indicates that the reconstruction message is processed by the destination node, so that the reconstruction message can be directly discarded, and repeated processing is avoided.

Therefore, each time any reconstructed message is broadcast in the target blockchain network, a new target node signature is added, so each target node receiving the reconstructed message can perform Bayesian fault-tolerant verification on the reconstructed message, for example, the reconstructed message can be subjected to Bayesian fault-tolerant verification according to the number of signatures of the target node signatures contained in the received reconstructed message and the total number of the target nodes contained in the target blockchain network, and any target node can generate blockchain transactions according to the reconstructed message and submit the blockchain transactions to the target blockchain network for consensus under the condition that the verification of any reconstructed message is passed. Still taking fig. 4 as an example, the destination node nodeC2 may determine the total node amount of the subnet2 (i.e. 3f+1), further verify the reconstructed message after receiving any reconstructed message broadcast by other destination nodes, and add the destination node signature generated by itself to the reconstructed message after the verification is passed, further determine whether the number of signatures of the destination node signatures included in the current reconstructed message meets (is not less than) the first threshold value f+1 corresponding to the total node amount, and generate a blockchain transaction based on the reconstructed message if the number of signatures of the destination node signatures meets (is not less than) the first threshold value f+1 corresponding to the total node amount, i.e. the reconstructed message has been approved by f+1 destination nodes. Or, to further increase the processing speed, the destination node nodeC2 may determine the number of signatures of the destination node signature included in the reconstructed message after receiving any reconstructed message broadcast by other destination nodes, and determine whether the number of signatures meets (is not less than) the second threshold value f corresponding to the total number of the nodes, if yes (i.e., the reconstructed message is already approved by f destination nodes), the destination node may generate a blockchain transaction based on the reconstructed message when the reconstructed message is validated to pass (when the number of destination nodes validated to pass the reconstructed message meets f+1). In this way, when the nodeC2 determines that the reconstructed message meets the preset condition, it is unnecessary to add a destination node signature generated by itself to the reconstructed message, which is helpful to further increase the processing speed.

In one embodiment, each destination node in the destination blockchain network may verify the received reconstructed message using the node public key of the other destination nodes. For example, each destination node may verify the destination node signature included in the received reconstructed message by using the node public key of the other destination node maintained by itself. Taking fig. 4 as an example, it can be understood that any destination node in the subnet2 locally maintains the node public key of other destination nodes, and correspondingly, each destination node locally maintains the node public key of the destination node. After adding the destination node signature generated by using the node public key of the node a2 to the reconstructed message and broadcasting the reconstructed message, other destination nodes (node b2, node c2 and node e 2) receiving the reconstructed message can verify (i.e. verify the signature) of the destination node added by the node a2 contained in the reconstructed message by using the node public key of the node a2 maintained locally, respectively. Similarly, when the node b2 verifies the reconstructed message, a destination node signature generated by using its own node public key may be added to the reconstructed message, if it is determined that the current number of signatures cannot pass the bayer fault tolerance check, broadcasting is continued, so that after receiving the reconstructed message, the node c2 and the node e2 may perform signature verification on the destination node signatures added by the node a2 and the node b2 according to the node public keys of the node a2 and the node db2 maintained locally, and if the signature verification passes, the destination node signature generated by itself is added, and it is further determined whether the current reconstructed message can pass the bayer fault tolerance check: if so, generating a blockchain transaction according to the reconfiguration message; otherwise, if not, the reconfiguration message may continue to be broadcast. Of course, if the nodeA2 receives the above reconstructed message broadcast by nodeA2 again, it finds that the reconstructed message includes the destination node signature added by itself, so that the reconstructed message can be directly discarded, and the repeated addition of the destination node signature of nodeA2 is avoided.

In another embodiment, the source blockchain network may be a blockchain sub-network managed by a blockchain main network, where the blockchain main network may maintain a node public key of each destination node in the destination blockchain network, and the reconstructed message may further include, in addition to the message content and the destination node signature, a source node signature carried in each cross-chain message received by the destination node that constructs the reconstructed message (i.e., a source node signature carried in each cross-chain message corresponding to the message content included in the reconstructed message), so that each destination node may further verify the reconstructed message received by itself. For example, each destination node may query the blockchain main network for the node public key of the source node indicated by the received reconfiguration message, and verify the source node signature included in the received reconfiguration message by using the queried node public key. The specific obtaining manner and verification manner of the node public key may be referred to the detailed description of the foregoing embodiments, and will not be repeated herein. In this embodiment, after any destination node receives the reconstructed message, in addition to verifying the destination node signature added to the destination node included in the reconstructed message, the source node signature included in the reconstructed message is verified through the node public key of the corresponding source node in the source blockchain network acquired from the blockchain main network, so that dual verification of the reconstructed message is realized, reliability of the reconstructed message for generating a blockchain transaction is further ensured, and inconsistent processing results of the reconstructed message content and even signature falsification may be caused by illegal nodes (bayer node) inside the destination blockchain network are avoided.

In an embodiment, the blockchain transaction may include data to be processed (for example, the data to be processed may be the message content or included in the message content), and at this time, each destination node may verify the blockchain transaction submitted by the other destination node according to the first data to be processed included in the cross-chain message acquired by itself and the second data to be processed included in the blockchain transaction submitted by the other destination node, and perform consensus on the blockchain transaction that passes the verification. For example, each destination node in the destination blockchain network may use the data to be processed carried in the cross-link message received by itself (i.e. the message content in the cross-link message) as the first data to be processed (as described above, the cross-link message received by the same destination node or the cross-link message passing the fault tolerance check carries the same data to be processed). Because each destination node submits its own generated blockchain transaction to other destination nodes in the destination blockchain network, the data to be processed extracted from the received blockchain messages submitted by other destination nodes can be used as second data to be processed. And further, the verification of the blockchain transaction submitted by other destination nodes can be realized by comparing whether the first data to be processed and the second data to be processed are the same or not: under the condition that the first data to be processed is the same as the second data to be processed, determining that the blockchain transaction passes verification; otherwise, if the first data to be processed is different from the second data to be processed, determining that the blockchain transaction is not verified.

Or, in order to improve the verification efficiency of the blockchain transaction generated by other destination nodes, the blockchain transaction generated by any destination node may further include a hash of the data to be processed, so that the other destination nodes may use the hash as the second hash, and use the hash of the data to be processed included in the cross-chain message received by the other destination nodes as the first hash. And further, the verification of the blockchain transaction submitted by other destination nodes can be realized by comparing whether the first hash and the second hash are the same or not: if the first hash is the same as the second hash, determining that the blockchain transaction passes verification; otherwise, if the first hash is not the same as the second hash, it may be determined that the blockchain transaction is not verified. In general, the data size of the data to be processed is far larger than that of the hash, so that the verification efficiency can be effectively improved by comparing the hash.

It will be appreciated that for each reconstructed message reconstructed for each destination node, only reconstructed messages that pass the aforementioned bayer fault tolerance check will be used by the corresponding destination node (i.e., the destination node that performs the bayer fault tolerance check on the reconstructed message) to generate the blockchain transaction. For any generated blockchain transaction, each destination node can adopt the workload certification, the stock right certification, the commission right certification, the practical Bayesian fault-tolerant algorithm, the HoneyBadgerBFT algorithm and the like to carry out consensus, and the specific process is not repeated.

At step 608, each destination node performs the same blockchain transaction among the plurality of blockchain transactions through the consensus.

Because each destination node in the destination blockchain network constructs a reconstruction message according to the verified cross-chain message acquired by the destination node and generates blockchain transactions according to the reconstruction message under the condition that the reconstruction message passes the Bayesian fault-tolerant verification, a plurality of blockchain transactions corresponding to the cross-chain message may exist in the destination blockchain network through consensus, but in order to ensure the consistency of the execution result of the blockchain transactions, each destination node is required to execute the same blockchain transaction through the consensus, so that the same business effect is realized. In order to ensure that each destination node in the destination blockchain network respectively executes the same blockchain transaction through the consensus, each destination node can respectively execute the first blockchain transaction through the consensus in the destination blockchain network. Alternatively, the first generated blockchain transaction in the commonly known blockchain transactions may be executed separately, e.g., each destination node may guarantee that the executed blockchain transaction is the first generated blockchain transaction according to the timestamp carried by the blockchain transaction. Any destination node may terminate processing for other blockchain transactions after executing the blockchain transaction. For example, if any blockchain transaction carries a request identifier, then the destination node may not execute the new blockchain transaction (i.e., not execute a contract code associated with a particular transaction) if it receives a new blockchain transaction that carries the same request identifier as the already executed blockchain transaction. Of course, the destination node may also receive a plurality of blockchain transactions carrying the same request identifier in a short time, and sequentially perform verification, execution, and other processes on each transaction according to the time sequence of receiving each transaction, so that the processing progress of each blockchain transaction may be different, and further after the execution of the first blockchain transaction is completed, the destination node may immediately terminate the execution process of other blockchain transactions, so as to ensure that only the first blockchain transaction is successfully executed, thereby maintaining a consistent transaction execution result with other destination nodes, and reducing the calculation power loss caused by invalid processing.

Because the source blockchain network may be involved in the processing of multiple cross-chain requests simultaneously (e.g., each source node generates multiple cross-chain messages in a short time, respectively), and the destination blockchain network may be responsive to multiple cross-chain messages simultaneously (e.g., when the response to a first cross-chain message has not yet ended, a second cross-chain message is received), to avoid confusion between different cross-chain messages or different reconfiguration messages, association between the cross-chain messages and the reconfiguration messages may be achieved by request identification. For example, in the case where the above-described cross-link message is generated by the source node executing the smart contract, the source node may use the contract identification of the smart contract as the request identification of the cross-link message; or under the condition that the above-mentioned cross-link message is generated by executing a certain contract task defined in the intelligent contract by the source node, the source node can take the task identifier of the contract task as the request identifier of the cross-link message, and further, the destination node responds to the received request identifier of the request contained in the reconstruction message generated by each cross-link message, thereby ensuring that the cross-link message sent by each source node and the reconstruction message generated by each destination node contain the request identifier. Each source node is related to each cross-link message sent by the same intelligent contract (or contract task) through the request identifier, and each reconstruction message generated by each destination node responding to each cross-link message corresponding to the request identifier is related through the request identifier, so that the association of all cross-link messages and all reconstruction messages corresponding to the same intelligent contract (or contract task) is realized, and the effective distinction between different cross-link messages or different reconstruction messages is facilitated.

Of course, the target node may also include a request identifier carried by any reconfiguration message in the blockchain transaction generated based on any reconfiguration message, so that the association among the cross-chain message, the reconfiguration message and the blockchain transaction is realized through the same request identifier. It should be noted that, the cross-chain message, the reconfiguration message and the blockchain transaction described in the foregoing embodiments of the present disclosure are all corresponding cross-chain messages, reconfiguration messages and blockchain transactions with the same request identifier. Accordingly, the destination blockchain network may maintain a set of request identifiers that are used to record the request identifiers carried in blockchain transactions that have been performed in the destination blockchain network at the current time. Thus, any destination node may perform a blockchain transaction through consensus by: after determining that a certain blockchain transaction passes the consensus, the destination node may extract a target request identifier contained in the message, then query the target request identifier in a locally maintained request identifier set, and execute the blockchain transaction if the query result indicates that the target request identifier is not recorded in the request identifier set. It can be understood that, when the request identifier set includes the target request identifier, it indicates that none of the blockchain transactions (generated by the destination nodes respectively) corresponding to the target request identifier is executed, so that the destination node can respond to the cross-chain message only by executing the blockchain transaction. Of course, after any destination node performs the blockchain transaction, the target request identifier may be added to the request identifier set, so as to ensure that other blockchain transactions corresponding to the target request identifier are not repeatedly performed.

In one embodiment, the message content may include data to be processed, and the cross-chain message may be created by the destination node invoking an intelligent contract deployed on the destination blockchain network; accordingly, the destination node may invoke the intelligent contract task callback method in response to the above-described cross-link message to return the data to be processed to the above-described intelligent contract. The embodiment of the present invention is assumed that the destination node executes an intelligent contract for implementing user account login, but the destination node does not locally store the user account and the login password, so that the destination node may generate a cross-link message for obtaining the user account and the login password, and further after the source node in the source blockchain network returns the cross-link message in response to the request, the destination node may implement automatic login to the user account according to the user account and the login password included in the cross-link message. At this time, the user account and the login password are data to be processed, and the destination node returns the user account and the login password to the intelligent contract for realizing the service function.

Further, because the request identifier set records the request identifier contained in the already executed blockchain transaction, in order to avoid invalid response to the acquired cross-link message and invalid processing to the acquired reconfiguration message, any target node may query whether the request identifier set records the request identifier contained in the cross-link message or the reconfiguration message after acquiring any cross-link message or any reconfiguration message. Further, the response process for any cross-link message may be terminated when it is determined that the request identifier included in the cross-link message is recorded in the request identifier set; alternatively, when it is determined that the request identifier included in any one of the reconfiguration messages is recorded in the request identifier set, the processing for the reconfiguration message may be terminated.

In an embodiment, the same intelligent contract can be deployed in the source blockchain network and the destination blockchain network, the cross-chain message can contain the data to be processed, and the cross-chain message can be created by calling the intelligent contract deployed in the source blockchain network by the source node; accordingly, the source node may invoke the smart contract task callback method in response to the above-described cross-chain message to return the pending data to the locally deployed smart contract. For example, the smart contracts described above may be used to update local data using pending data, or may also be used to implement other business functions, such as participating in privacy calculations, etc., using pending data obtained by callback methods.

Through the above embodiment, after the destination node in the destination blockchain network obtains the cross-link message generated by the source node in the source blockchain network respectively, a reconstructed message is constructed according to the cross-link message passing verification and the signed reconstructed message is broadcast in the destination blockchain network, and after the other destination nodes receiving the reconstructed message pass verification, the signature is performed again and the broadcast continues until any source destination node passes the Bayesian fault tolerance check on the reconstructed message according to the total quantity of the destination nodes and the signature quantity of the destination node signature contained in the reconstructed message (indicating that enough destination nodes already exist at the moment to approve the reconstructed message), the blockchain transaction is generated according to the reconstructed message and the consensus is submitted, and then the same blockchain transaction is executed by each destination node respectively. On the one hand, the repeated verification and signature of the reconstructed message by a plurality of destination nodes ensure that the reconstructed message used for generating the blockchain transaction is commonly accepted by enough destination nodes; on the other hand, the consistency of the cross-link information processed by each destination node and the processing result is effectively ensured by each destination node to execute the same blockchain transaction, and the problems are solved.

Thus, a complete description of the processing of a cross-chain message sent by a destination node in a destination blockchain network in response to a source blockchain network is completed. In fact, each destination node may also return a response message to the source blockchain network in response to the cross-chain message (i.e., the destination blockchain network uses the cross-chain message sent by the source blockchain network as a cross-chain request initiated by the source blockchain network), or return a response message to the source blockchain network after executing the blockchain transaction, where the response information included in the response message may be a response result of the destination node to the cross-chain message or an execution result to the blockchain transaction, and then the source node may perform a corresponding operation according to the response information. The following describes the process of acquiring, verifying and subsequent processing of the response message by the source node.

In an embodiment, to ensure the privacy of the sent response message and avoid disclosure of the response message, any destination node may encrypt the response message to be transmitted by using a digital envelope technology. The specific transmission manner may be referred to the description of the foregoing embodiments, and will not be repeated here.

The destination nodes in the destination blockchain network may send (i.e., broadcast) the response messages to each source node in the source blockchain network, respectively, or each destination node may send (i.e., unicast or multicast) the response messages to any source node(s) in the source blockchain network, respectively, and each source node synchronizes the response messages received by itself to other source blockchain nodes in the source blockchain network. It can be seen that whether the response message is sent in a broadcast manner or in a unicast or multicast manner and synchronized by the receiver in the network to which the receiver belongs, each source node in the source blockchain network can be guaranteed to receive the response message sent by at least one destination node in the destination blockchain network. Any destination node can use the broadcasting mode (the digital envelope uses the node public key of each subnet node in the source block chain network to encrypt the symmetric key) described in the previous embodiment, and can also determine the sender of the cross-link message according to the received cross-link message, so as to return the corresponding response message to the sender only. After receiving the cross-link message sent by the source node nodeA1 in the subnet1 in the unicast mode, the destination node nodeA2 in the subnet2 may only return a corresponding response message to the nodeA1, and after receiving the response message, the nodeA1 synchronizes the response message to other source nodes such as nodeB1, nodeC1, nodeD1 and the like in the source blockchain network. Obviously, both the above two modes can ensure that each source node in the source blockchain network receives the response message returned by each destination node in the destination blockchain network.

In one embodiment, the destination blockchain network may be a blockchain subnetwork managed by a blockchain main network, the blockchain main network maintains node identity information of each destination node in the destination blockchain network, the response message includes identification information for characterizing a node identity of the destination node returning the response message, and correspondingly, each source node may respectively query the blockchain main network for the node identity information of the destination node included in the response message to verify the identification information, and generate the blockchain transaction according to the response message passing the verification.

Still taking fig. 4 as an example, after receiving the response message returned by the nodeA2, the nodeA1 may also query the node identity information of the nodeA2 to the a in the subnet0 according to the identity information of the nodeA2 carried in the response message, so as to verify the identity information of the nodeA 2. If the verification passes, it indicates that nodeA2 is indeed the trusted sender of the response message received by nodeA1, so that nodeA1 may further perform subsequent processing, such as generating a blockchain transaction, according to the received response message (see the embodiments described below for specific generating procedures, which are not repeated here). Otherwise, if the check fails, it indicates that nodeA2 is not authentic, and nodeA1 may discard the response message directly. Of course, in the case that the verification is not passed, the nodeA1 may record the nodeA2 as an illegal destination node, so that in the case that the response message returned by the nodeA2 is received again later, the information may be directly discarded, avoiding the invalidation process and accelerating the response speed. Of course, in the case of sending the cross-link message in unicast, if nodeA1 records nodeA2 as an illegitimate destination node, nodeA1 may refuse to send the cross-link message to nodeA2, and may even synchronize the illegitimate records of nodeA2 to other source nodes in the subnet 1.

In the foregoing embodiment in which the destination blockchain network is a blockchain subnetwork, when a main network node in the blockchain main network and a subnetwork node in the blockchain subnetwork managed by the blockchain main network are deployed on the same node device, the main network node and the subnetwork node on the node device may share a blockchain plugin running on the node device, at this time, the source node may query, through the blockchain plugin, node identity information of the destination node, for example, may read, through the blockchain plugin shared with the main network node deployed on the node device to which the source node belongs, node identity information of the destination node maintained by the main network node. Specific reading modes can be referred to in the related description of the foregoing embodiments. Obviously, under the condition that network nodes belonging to different blockchain networks are deployed in the same node equipment, the blockchain plugins of the node equipment are shared by all the nodes, so that the efficient multiplexing of the blockchain plugins can be realized, the number of the blockchain plugins required to be deployed in the node equipment is effectively reduced, the configuration of the node equipment and the deployment flow of the blockchain nodes are simplified, and the deployment efficiency of the blockchain nodes and the management efficiency of the node equipment are improved. In fact, different block chain nodes deployed in the same node device may also share other functional plugins, such as the foregoing P2P plugin instance, the consensus plugin instance, and/or the service instance, which are not described herein.

In the foregoing embodiment in which the target blockchain network is a blockchain subnet, a subnet management contract may be deployed on the blockchain main network, where the subnet management contract is configured to maintain node identity information of subnet nodes in each blockchain subnet constructed based on the blockchain main network; at this time, the source node may read node identity information of the destination node maintained by the subnet management contract. Taking fig. 4 as an example, because the subnet1 to which the subnet node nodeA1 belongs and the subnet2 to which the subnet node nodeA2 belongs are both established on the basis of the subnet0, the subnet management contract deployed in the subnet0 can be used for managing the node identity information of each subnet node in the subnet1 and the subnet2, and further the nodeA1 can read the node identity information of the nodeA2 maintained by the subnet management contract. By maintaining node identity information of the subnet nodes by a subnet management contract deployed in the blockchain main network, efficient management of the node identity information can be ensured. The source node directly reads the node identity information of the destination node maintained by the subnet management contract, so that the process of acquiring the node identity information does not need the processes of the consensus of the main network nodes in the blockchain main network and the like, and the acquisition efficiency of the node identity information is improved.

In the foregoing embodiment in which the destination blockchain network is a blockchain subnet, the identification information of any subnet node may include a node identifier declared by the subnet node and a subnet identifier of a blockchain subnet to which the subnet node belongs; at this time, the source node may query the blockchain main network whether the node identifier declared by the destination node and the subnet identifier match. Taking fig. 4 as an example, after receiving the response message returned by the nodeA2, the nodeA1 may query the subnet0 whether the node identifier declared by the nodeA2 is matched with the subnet identifier, and further perform corresponding processing according to the query result, for example, if the node identifier and the subnet identifier are matched, a blockchain transaction is generated according to the received response message; or if the two messages are not matched, the direct discarding of the response message is terminated, and the like, and the details are not repeated. By the method, the node identity information of each subnet node maintained in the blockchain main network can be fully utilized to verify the response message sent by the subnet node, so that the legality of the message processed later is ensured.

In the foregoing embodiment in which the destination blockchain network is a blockchain subnet, the identification information of any subnet node may also include a signature generated by the subnet node based on its own node private key; at this time, querying the blockchain main network for node identity information of the destination node to verify the identity information carried in the response message may include: the source node receiving the response message can query the blockchain main network for the node public key of the destination node sending the response message, and adopts the node public key to check the signature of the destination node contained in the response message. Taking fig. 4 as an example, after receiving the response message returned by the nodeA2 and the signature of the corresponding destination node, the nodeA1 may request to the subnet0 to obtain the node public key of the nodeA2 and perform signature verification on the signature, and further perform corresponding processing according to the signature verification result: in the case that the verification passes, subsequent processing, such as generating blockchain transactions and the like, can be performed according to the response message; in the case of failed signature verification, the response to the response message may be terminated, e.g., the response message may be directly discarded or even nodeA2 may be recorded as an illegal node. Of course, in the case where nodeA2 is recorded as an illegitimate node, nodeA1 may not send the cross-chain message to nodeA2 after subsequent regeneration of the cross-chain message (e.g., node public key encryption symmetric key of nodeA2 is not used in the aforementioned digital envelope), thereby avoiding invalid transmission.

As described above, since the plurality of response messages received by any source node are generated by the destination node in response to the cross-chain message transmitted by the source node, the plurality of response messages received by any source node should contain the same response information in the case where there is no illegal node in the source blockchain network and the destination blockchain network. Thus, for a plurality of response messages received by any source node, the source node may compare the response information contained in each response message and verify the response messages containing the same response information. Or, the source node may also use various fault-tolerant algorithms such as PBFT algorithm, honeybaddgerbft algorithm, etc. to verify multiple response messages containing the same response information, and the specific process is not repeated. Of course, in the scheme practice, the total number of the nodes and the number of the received cross-link messages may also be other values, which is not limited in this specification. Wherein the response message (containing the same message content) that passed the verification is used for subsequent processing, such as generating a blockchain transaction.

As described above, each destination node in the destination blockchain network returns a response message containing the same request identifier to the source blockchain network, so that each source node obtains the response message respectively. Because each destination node generates a response message according to the cross-chain message containing the same message content, or generates a response message after executing the blockchain transaction containing the same message content, each response message received by each source node contains the same response information, and each destination node needs to respond to any response message respectively.

The process of responding to the response message will be described with respect to the generation and execution of a blockchain transaction based on the response message (obviously, the blockchain transaction generated by the source node is different from the blockchain transaction generated by the source node described in the foregoing embodiments). In order to ensure the reliability of blockchain transactions executed by each source node, response messages returned by the destination node may be processed in a variety of ways. One way is 'decentralized verification and separate proposal', namely each source node performs Bayesian fault-tolerant verification on each response message received by itself, and generates blockchain transactions according to the verified response messages; the other way is 'decentralized verification and centralized proposal', namely each source node respectively verifies any received response message and adds a source node signature generated by itself, and then any source node generates a blockchain transaction according to the response message under the condition that the number of the source node signatures of any response message is determined to pass the Bayesian fault tolerance verification. Two ways are described below:

(1) Scatter verification and scatter proposal

It should be noted that, in this embodiment, the plurality of response messages acquired by any source node includes the same request identifier. In this embodiment, after any response message is obtained, the source node may verify whether the response message is legal, further determine the number of response messages that verify the legal response message and include the same response message, and under the condition that the number of the messages and the total number of nodes of the destination node in the destination blockchain network enable the response message to pass through the bayer fault-tolerant check, use the part of the response message passing through the bayer fault-tolerant check to generate a blockchain transaction and submit the blockchain transaction to the source blockchain network for consensus.

In one embodiment, D1 may first verify whether each response message acquired by it is legal. For example, for any response message, in the case that the signature of the destination node that generates the response message (i.e., the generator of the response message) is included in the response message, the source node may obtain the node public key of the destination node, and use the node public key to sign the above-mentioned signature: if the verification sign passes, the response message is legal; otherwise, the response message is not legal, and the response message can be directly discarded. In the case that the target blockchain network is a blockchain subnet managed by the blockchain main network, the blockchain main network may maintain information such as IP addresses, ports, node public keys, node identifiers and the like of subnet nodes of each blockchain subnet created based on the blockchain main network, so that the source node may query the blockchain main network for the node public key of the target node, and the specific process may be referred to the description of the foregoing embodiments and will not be repeated herein. Or, in the case that the response message includes the subnet identifier of the destination blockchain network and the node identifier of the destination node, the source node may query the blockchain main network for whether the node identifier exists under the subnet identifier: if yes, indicating that the response message and the destination node are legal; otherwise, the response message or the destination node is not legal, and the response message can be directly discarded.

As described above, in a normal case where no dislike node exists in the source blockchain network and the destination blockchain network, all response messages containing the same request identifier should contain the same response information, so that any source node can compare whether the response information contained in the plurality of legal response messages acquired by the source node is the same. Obviously, if the response information contained in the legal response messages is the same, the response information in each response message is not tampered; otherwise, a response message indicating that it is different from the response information in other response messages (typically the majority of the others) may be tampered with, at which point the response message may be discarded directly.

Under the condition that the verification is passed, the source node can further perform Bayesian fault-tolerant verification on legal response messages containing the same response information. For example, fault tolerance verification can be performed on legal response messages containing the same response information, which are acquired by the device, according to the number of messages of the cross-link messages acquired by the device and the total number of nodes of the destination nodes in the destination blockchain network. In the case that the destination blockchain network is a blockchain sub-network managed by the blockchain main network, the blockchain main network may maintain a node total amount of the destination nodes in the destination blockchain network, so the source node may query the blockchain main network for the node total amount of the destination nodes in the destination blockchain network. At this time, the subnet information of the blockchain subnet maintained by the blockchain main network can be fully utilized, which is helpful for improving the interaction efficiency. In addition, after the source node inquires the related information of the destination node from the blockchain main network, the related information can be stored locally, so that repeated inquiry in the subsequent processing process is avoided, and the interaction efficiency is further improved. Of course, in order to ensure timeliness of the related information, an effective duration may be set for the related information stored locally, and the related information may be updated in time.

The above process will be described with reference to fig. 4. Assuming that the source node nodeA1 receives the response messages respectively returned by the destination nodes nodeA2, nodeB2, nodeC2 and nodeE2, the nodeA1 can verify each response message according to the destination node signature and other information carried by each response message, so as to determine whether each response message is legal or not; secondly, whether the response information contained in each legal response message is the same or not can be further compared so as to find out the legal response message containing the same response information; then, the Bayesian fault tolerance check can be performed on the legal response messages containing the same response information according to the message number of the legal response messages and the total amount of the nodes of the destination blockchain network inquired from the main network node. Wherein, because the destination blockchain network includes destination nodes nodeA2, nodeB2, nodeC2, and node2, the total number of nodes 3f+1=4 (i.e., f=1), and thus the critical number f+1=2—indicating that if nodeA1 receives 2 legal response messages containing the same response information, these 2 legal response messages pass the bayer fault tolerance check.

In the case that the bayer fault-tolerant check is passed, the source node may generate a blockchain transaction using the response message that is passed. For example, assuming that the number of nodes of the legal response message containing the same response information is 3, the source node may generate a blockchain transaction containing the response information and submit the blockchain transaction to the destination blockchain network for consensus, because the 3 response messages contain the same response information. It can be seen that a response message (containing the same data to be processed) that passes the bayer fault-tolerance check will be used to generate a blockchain transaction.

Obviously, the blockchain transaction generated by any source node needs to be broadcast to other source nodes, and the blockchain transaction generated by other source nodes can also be broadcast to the source node, so that any source node can use response information or hash of the response information to verify the blockchain transaction generated by other source nodes received by the source node.

For example, any source node may compare the first response information included in the response message acquired by itself with the second response information included in the blockchain transaction received by itself, and verify the blockchain transaction: in the case that the first response information is the same as the second response information, determining that the blockchain transaction is verified; otherwise, if the first response information is different from the second response information, determining that the blockchain transaction is not verified. Or, in order to improve the verification efficiency of the blockchain transactions generated by other source nodes, the blockchain transactions generated by any source node can also carry the hash of the response information, so that the source node can take the hash as a second hash and take the hash of the response information carried in the response message received by the source node as a first hash. And further, the verification of the blockchain transaction broadcasted by other source nodes can be realized by comparing whether the first hash and the second hash are the same or not: in the case that the first hash is the same as the second hash, it may be determined that the blockchain transaction is verified; otherwise, if the first hash is different from the second hash, determining that the blockchain transaction is not verified. In general, the data volume of the response information is far larger than that of the hash, so that the verification efficiency can be effectively improved by comparing the hash.

It can be seen that if the process of generating a blockchain transaction and initiating a consensus is considered to be a "proposal" process for response messages, in this embodiment, each source node in the source blockchain network separately validates (i.e., decentralized validates) the response messages acquired by itself, and each source node that is validated separately uses the validated response messages to generate a blockchain transaction and initiate a consensus (i.e., decentralized proposal). Obviously, the method can initiate blockchain transactions corresponding to the same request identifier by as many source nodes as possible, and fully ensures that each source node can execute the blockchain transactions, thereby completing the response closed loop of the self-sent cross-chain message (namely the self-initiated cross-chain request).

(2) Decentralized verification and centralized proposal

It should be noted that, in this embodiment, the plurality of response messages acquired by any source node includes the same request identifier. After any source node obtains the response messages respectively returned by each destination node, the response messages obtained by the source node can be checked, and under the condition of passing the check, the reconstruction message comprising the message content of the response message and the self-generated source node signature is constructed according to the response messages obtained by the source node (obviously, the reconstruction message in the scheme is different from the reconstruction message generated by the destination node according to the cross-chain message in the previous embodiment), so that the reconstruction message can be broadcasted to other source nodes in the source blockchain network. It can be understood that each source node in the source blockchain network performs the above operation respectively, so that any source node can verify any reconstructed message broadcast by other source nodes after receiving the reconstructed message, and if the verification is passed, add a source node signature generated by itself to the reconstructed message, and continue broadcasting the reconstructed message to other source nodes in the source blockchain network. And under the condition that any source node determines that the received reconstruction message passes the Bayesian fault-tolerant verification according to the number of signatures of the destination node signatures contained in the received reconstruction message and the total amount of source nodes contained in the source blockchain network, the source node generates a blockchain transaction according to the received reconstruction message and submits the blockchain transaction to the source blockchain network for consensus.

The reconstructed message includes response information included in a response message used for constructing the reconstructed message and a source node signature generated by a source node constructing the reconstructed message (i.e., a constructor of the reconstructed message). It can be understood that, for any reconstructed message, the processing procedure of receiving the reconstructed message broadcast by other nodes, adding the self-generated source node signature after the verification of the reconstructed message, and continuing to broadcast the reconstructed message added with the self-generated source node signature can be sequentially performed by a plurality of source nodes in the source blockchain network; in the case that any source node finds that any reconstructed message received by the source node already contains the source node signature generated by the source node, the source node indicates that the reconstructed message has been processed by the source node, so that the reconstructed message can be directly discarded.

The verification process of any source node on any reconstructed message may include a verification process of a source node signature included in the reconstructed message; of course, if the reconstructed message further includes a destination node signature performed by the destination node on the response message corresponding to the response information in the reconstructed message, the verification process of any reconstructed message may further include a verification process of the destination node signature, which will be described below.

In one embodiment, each source node in the source blockchain network may verify the reconstructed message it receives using the node public key of the other source nodes. For example, each source node may verify the source node signature included in the received reconstructed message by using the node public key of the other source node maintained by itself. Taking fig. 4 as an example, it can be understood that any source node in the source blockchain network maintains the node public key of other source nodes locally, and correspondingly, other source nodes also maintain the node public key of the source node locally. After adding the source node signature generated by using the node public key of the node a1 to the reconstructed message and broadcasting the reconstructed message, other source nodes (node b1, node c1 and node d 1) receiving the reconstructed message can verify (i.e. verify the signature) of the source node added by the node a1 contained in the reconstructed message by using the node public key of the node a1 maintained locally, respectively. Similarly, when the node b1 verifies the reconstructed message, a source node signature generated by using its own node public key may be added to the reconstructed message, if it is determined that the current number of signatures cannot pass the bayer fault tolerance check, broadcasting may be continued, so that after receiving the reconstructed message, the node c1 and the node d1 may perform signature verification on the source node signatures added by the node a1 and the node b1 according to the locally maintained node public keys of the node a1 and the node b1, and if the signature verification passes, the source node signature generated by itself is added, and it is further determined whether the current reconstructed message can pass the bayer fault tolerance check or not: if so, generating a blockchain transaction according to the reconfiguration message; otherwise, if not, the reconfiguration message may continue to be broadcast. Of course, after the nodeA1 receives the reconstructed message broadcasted by nodeB1, the source node signature added by itself can be determined, and thus the reconstructed message can be directly discarded.

In another embodiment, the destination blockchain network may be a blockchain subnet managed by a blockchain main network, where the blockchain main network may maintain a node public key of each destination node in the destination blockchain network, and the reconfiguration message includes, in addition to the response information and the source node signature, a destination node signature carried in each response message received by the source node that constructs the reconfiguration message (i.e., a destination node signature carried in each response message corresponding to the response information included in the reconfiguration message), so that each source node may further verify the reconfiguration message received by itself. For example, each source node may query the blockchain main network for the node public key of the destination node indicated by the received reconfiguration message, and verify the destination node signature included in the received reconfiguration message by using the queried node public key. The specific obtaining manner and verification manner of the node public key may be referred to the detailed description of the foregoing embodiments, and will not be repeated herein. In the embodiment, after receiving the reconfiguration message, the source node verifies the signature of the destination node contained in the reconfiguration message through the node public key of the corresponding destination node acquired from the blockchain main network in addition to the source node signature added by the reconfiguration message, so that double verification of the reconfiguration message is realized, reliability of the reconfiguration message for generating blockchain transactions is further ensured, and inconsistent transaction execution results possibly caused by illegal nodes in the source blockchain network due to reconfiguration response information and even signature counterfeits are avoided.

Therefore, each time any reconstructed message is broadcast in the source blockchain network, a new source node signature is added, so each source node receiving the reconstructed message can perform Bayesian fault-tolerant verification on the reconstructed message, for example, the reconstructed message can be subjected to Bayesian fault-tolerant verification according to the number of signatures of the source node signatures contained in the received reconstructed message and the total number of the source nodes contained in the source blockchain network, and any source node can generate blockchain transactions according to the reconstructed message and submit the blockchain transactions to the source blockchain network for consensus under the condition that the verification of any reconstructed message is passed. For example, taking fig. 4 as an example, the source node nodeC1 may determine the total node amount (3f+1) of the subnet1 where the source node nodeC1 is located, further verify any reconstructed message broadcast by other source nodes after receiving the reconstructed message, and add a source node signature generated by itself to the reconstructed message after the verification is passed, further determine whether the number of signatures of the source node signatures included in the current reconstructed message meets (is not less than) the first threshold value f+1 corresponding to the total node amount, and generate a blockchain transaction based on the reconstructed message if the number of signatures of the source node signatures meets (is not less than) the first threshold value f+1 corresponding to the total node amount (i.e., the reconstructed message has been approved by f+1 destination nodes). Or, to further increase the processing speed, the source node nodeC1 may determine the number of signatures of the source node signature included in the reconstructed message after receiving any reconstructed message broadcast by another source node, and determine whether the number of signatures meets (is not smaller than) the second threshold value f corresponding to the total number of the nodes, if so, the source node may generate a blockchain transaction based on the reconstructed message when the reconstructed message is verified to pass (when the number of source nodes verified to pass to the reconstructed message meets f+1). In this way, when the nodeC1 determines that the reconstructed message meets the preset condition, it is unnecessary to add a source node signature generated by itself to the reconstructed message, which is helpful to further increase the processing speed.

In the case that the target blockchain network is a blockchain sub-network managed by the blockchain main network, the blockchain main network can maintain the node total amount of the target nodes in the target blockchain network, so that each source node can respectively inquire the node total amount of the target nodes in the target blockchain network from the blockchain main network, and the obtained node total amount is used for performing the Bayesian fault tolerance verification. In addition, in the embodiments of the blockchain main network and the blockchain sub-network mentioned in the present specification, after the blockchain sub-network queries the blockchain main network for corresponding information, the information may be stored locally, so as to avoid repeated queries in the subsequent processing process, and further improve the interaction efficiency. Of course, in order to ensure timeliness of the information, an effective duration may be set for the locally stored information, and the information may be updated in time. It will be appreciated that only reconstructed messages that are subject to the bayer fault-tolerance check by a certain source node in the source blockchain network will be used to generate blockchain transactions.

Thus, the two modes of processing the response message returned by the destination node are introduced. For any generated blockchain transaction, workload certification, stock right certification, commission right certification, practical Bayesian fault-tolerant algorithm, honeyy badgerBFT algorithm and the like can be adopted for consensus, and specific processes are not repeated.

Because each source node generates a blockchain transaction according to the response message acquired by itself or constructs a reconstruction message according to the response message acquired by itself and passing verification, and generates a blockchain transaction according to the reconstruction message under the condition that the reconstruction message passes the Bayesian fault-tolerant verification, a plurality of blockchain transactions corresponding to the same cross-chain request may exist in the source blockchain network through consensus, but in order to ensure the consistency of the execution results of the blockchain transactions, each source node is required to execute the same blockchain transaction through the consensus, so that the same business effect is realized. To ensure that each source node in the source blockchain network performs the same blockchain transaction through the consensus, each source node may perform the first blockchain transaction through the consensus in the source blockchain network. Alternatively, the first generated blockchain transaction in the commonly known blockchain transactions may be performed, e.g., each source node may guarantee that the performed blockchain transaction is the first generated blockchain transaction according to a timestamp carried by the blockchain transaction. Any source node may terminate processing for other blockchain transactions after executing the blockchain transaction. For example, if a request identifier is carried in any blockchain transaction, then the source node may not execute the new blockchain transaction (i.e., not execute a contract code associated with a particular service) if it receives a new blockchain transaction carrying the same request identifier as the already executed blockchain transaction. Of course, the source node may also receive a plurality of blockchain transactions carrying the same request identifier in a short time, and sequentially perform verification, execution, and other processes on each transaction according to the time sequence of receiving each transaction, so that the processing progress of each blockchain transaction may be different, and further after the execution of the first blockchain transaction is completed, the source node may immediately terminate the execution process of other blockchain transactions, so as to ensure that only the first blockchain transaction is successfully executed, thereby maintaining a consistent transaction execution result with other source nodes, and reducing the calculation power loss caused by invalid processing.

As previously described, the blockchain transaction generated by the source node in response to the response message may include the request identifier carried by the response message, thereby implementing the correlation among the cross-chain message, the response message, and the blockchain transaction. The source blockchain network may maintain a set of request identifiers (obviously, the set of request identifiers maintained by the source node is different from the set of request identifiers maintained by the destination node in the foregoing embodiment), where the set is used to record the request identifiers carried in the cross-chain message that has not been responded to in the source blockchain network at the present time (i.e., the cross-chain message that has not been performed by the corresponding blockchain transaction). Thus, after determining that a certain blockchain transaction passes the consensus, any source node may extract a target request identifier contained in the message, query the target request identifier in a locally maintained request identifier set, and execute the blockchain transaction if the query result indicates that the target request identifier is recorded in the request identifier set. It can be understood that, when the request identifier set includes the target request identifier, it indicates that none of the blockchain transactions (generated by the source nodes respectively) corresponding to the target request identifier is executed, so that the source node can respond to the cross-chain message only by executing the blockchain transaction. Of course, after any source node performs the above blockchain transaction, the target request identifier may be deleted from the request identifier set, so as to ensure that other blockchain transactions corresponding to the target request identifier will not be repeatedly performed.

In an embodiment, the cross-chain message may be created by the source node invoking an intelligent contract deployed on the source blockchain network; accordingly, the source node may invoke the smart contract task callback method in response to the response message to return the response message to the smart contract. Further, because the request identifier set records the request identifier contained in the blockchain transaction which is not yet executed, in order to avoid invalid response to the acquired cross-link message and invalid processing to the acquired reconfiguration message, any target node may query whether the request identifier set records the request identifier contained in the cross-link message or the reconfiguration message after acquiring any cross-link message or any reconfiguration message. Further, the response process for any response message may be terminated when it is determined that the request identifier included in the response message is not recorded in the request identifier set; alternatively, if it is determined that the request id included in any one of the reconfiguration messages is not recorded in the request id set, the processing for the reconfiguration message may be terminated.

Through the above embodiment, on one hand, multiple verifications and signatures of the response messages (or the reconfiguration messages) by the multiple source nodes ensure that the response messages (or the reconfiguration messages) for generating the blockchain transaction are commonly approved by enough source nodes; on the other hand, the same blockchain transaction is respectively executed by each source node, so that each source node is ensured to respectively execute the blockchain transaction only once, and the consistency of the response result of each source node to the self-generated cross-chain message is effectively ensured.

Fig. 7 is a schematic diagram of an apparatus according to an exemplary embodiment. Referring to fig. 7, at the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile storage 710, although other hardware required by the service is possible. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 702 reading a corresponding computer program from the non-volatile storage 710 into the memory 708 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

FIG. 8 is a block diagram of a cross-chain interaction device provided by an example embodiment. Referring to fig. 8, the apparatus may be applied to the device shown in fig. 7 to implement the technical solution of the present specification. The cross-chain interaction device may include:

a message receiving unit 801, configured to enable each destination node in the destination blockchain network to respectively obtain a cross-chain message sent by at least one source node in the source blockchain network to the destination blockchain network;

A message construction unit 802, configured to enable each destination node to verify the acquired cross-link message, and construct a multi-signed reconstructed message for the message content of the cross-link message in the destination blockchain network under the condition that the verification is passed;

a transaction generating unit 803, configured to enable any destination node to generate a blockchain transaction according to any reconfiguration message and submit the blockchain transaction to the destination blockchain network for consensus under the condition that the number of signatures of source node signatures included in any reconfiguration message received is determined to pass the bayer fault tolerance check;

the transaction execution unit 804 causes each destination node to execute the same blockchain transaction among the plurality of blockchain transactions through the consensus.

Optionally, the method further comprises:

a message encrypting unit 805, configured to enable the source node to sign a blockchain message to be transmitted by using a private key of the source node, encrypt a message content to be transmitted and a signature of the blockchain message by using a symmetric key, encrypt the symmetric keys by using node public keys of the destination nodes, and add the encrypted signature, the encrypted message content and the encrypted symmetric keys to the cross-chain message;

The message decrypting unit 806 decrypts the symmetric key encrypted by the public key of the node of the destination node in the cross-link message through the private key of the destination node, decrypts the encrypted message content and the signature through the symmetric key obtained by decryption, and obtains the message content for generating the blockchain transaction when the signature verification passes through the public key of the node of the source node.

Optionally, the source blockchain network is a blockchain sub-network managed by a blockchain main network, the blockchain main network maintains node identity information of each source node in the source blockchain network, and the cross-chain message includes identity information for representing node identities of source nodes sending the cross-chain message; the apparatus further comprises:

and a source node verification unit 807, configured to enable each destination node to query the blockchain main network for node identity information of the source node that sends the cross-link message, so as to verify the identity information, and respond to the cross-link message if verification passes.

Optionally, the target blockchain network is a blockchain sub-network managed by a blockchain main network, and when a main network node in the blockchain main network and a sub-network node in the blockchain sub-network managed by the blockchain main network are deployed in the same node equipment, the main network node and the sub-network node on the node equipment share a blockchain plug-in running on the node equipment; the source node verification unit 807 is further configured to:

And each destination node reads the node identity information of the source node which is maintained by the main network node and transmits the cross-link message through the block chain plug-in shared with the main network node deployed on the node equipment of the destination node.

Optionally, a subnet management contract is deployed on the blockchain main network, and the subnet management contract is used for maintaining node identity information of subnet nodes in each blockchain subnet constructed based on the blockchain main network; the source node verification unit 807 is further configured to:

and enabling each destination node to respectively read the node identity information of the source node which is maintained by the subnet management contract and transmits the cross-link message.

Optionally, the identification information of any subnet node includes a node identifier declared by the any subnet node and a subnet identifier of a blockchain subnet to which the any subnet node belongs; the source node verification unit 807 is further configured to:

and each destination node respectively inquires whether the node identifier and the subnet identifier of the source node statement for sending the cross-link message are matched with each other or not from the blockchain main network.

Optionally, the identification information of any subnet node includes a signature generated by the any subnet node based on a node private key of the subnet node; the source node verification unit 807 is further configured to:

And each destination node respectively inquires a node public key of the source node for sending the cross-link message from the block chain main network, and adopts the node public key to check the signature.

Optionally, the method further comprises:

the destination signature verification unit 808 verifies the destination node signatures included in the received reconstructed message by the destination nodes through the node public keys of the other destination nodes maintained by the destination nodes.

Optionally, the source blockchain network is a blockchain sub-network managed by a blockchain main network, the blockchain main network maintains node public keys of all source nodes in the source blockchain network, and the reconfiguration message further includes source node signatures carried in all cross-chain messages received by destination nodes constructing the reconfiguration message; the apparatus further comprises:

the source signature verification unit 809 makes each destination node query the blockchain main network for the node public key of the source node indicated by the reconstruction message received by itself, and verifies the source node signature included in the reconstruction message received by itself through the queried node public key.

Optionally, the blockchain transaction includes data to be processed, and the apparatus further includes:

The transaction verification unit 810 makes each destination node verify the blockchain transaction submitted by other source nodes according to the first to-be-processed data included in the acquired cross-chain message and the second to-be-processed data included in the blockchain transaction submitted by other destination nodes, or according to the first hash calculated by itself according to the first to-be-processed data included in the acquired cross-chain message and the second hash of the second to-be-processed data included in the blockchain transaction submitted by other source nodes, and performs consensus on the blockchain transaction passing verification.

Optionally, the destination blockchain network maintains a request identifier set, the cross-chain message received by any destination node, the reconstructed message constructed by any destination node according to the cross-chain message received by the destination node, and the blockchain transaction generated according to the reconstructed message contain the same request identifier,

the transaction execution unit 804 is further configured to: enabling any destination node to execute the blockchain transaction under the condition that the target request identifier contained in the blockchain transaction is not recorded in the request identifier set;

the apparatus further includes an identification adding unit 811: and enabling the destination node to add the target request identifier to the request identifier set after the successful execution of any blockchain transaction.

Optionally, the apparatus further includes:

a response termination unit 812, configured to cause each destination node to terminate a response procedure for any cross-link message when determining that a request identifier included in the cross-link message is recorded in the request identifier set; or alternatively, the process may be performed,

the process termination unit 813 causes each destination node to terminate the process for any one of the reconfiguration messages when it is determined that the request identifier included in the one of the reconfiguration messages is recorded in the request identifier set.

Optionally, the source blockchain network and the destination blockchain network are deployed with the same intelligent contract, the message content includes data to be processed, and the apparatus further includes:

a message creation unit 814 that causes the source node to call the smart contract deployed locally to create the cross-link message;

and a contract callback unit 815, for enabling the destination node to call the intelligent contract task callback device in response to the reconfiguration message so as to return the data to be processed to the intelligent contract deployed locally.

Optionally, the smart contract is configured to update local data using the pending data.

Optionally, the blockchain transactions respectively executed by each source node are:

A first blockchain transaction through consensus; or alternatively, the process may be performed,

the blockchain transaction that was first generated from among the commonly recognized blockchain transactions.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A cross-chain interaction method, comprising:

each destination node in the destination block chain network respectively acquires a cross-chain message sent by at least one source node in the source block chain network to the destination block chain network; the source blockchain network and the destination blockchain network are respectively blockchain subnets which are created based on and managed by a blockchain main network, and any one of the blockchain main network nodes and corresponding subnets in any one of the blockchain subnets managed by the blockchain main network are deployed in the same node equipment;

2. The method of claim 1, further comprising:

the source node adopts a private key of the source node to sign a blockchain message to be transmitted, adopts a symmetric key to encrypt the message content to be transmitted and the signature of the blockchain message, adopts a node public key of each destination node to encrypt the symmetric key respectively, and adds the encrypted signature, the encrypted message content and the encrypted symmetric keys into the cross-chain message;

each destination node decrypts the symmetric key encrypted by the public key of the node of the destination node in the cross-chain message through the private key of the destination node, decrypts the encrypted message content and the signature through the symmetric key obtained through decryption, and obtains the message content to be used for generating the blockchain transaction under the condition that the signature verification passes through the public key of the node of the source node.

3. The method of claim 1, the blockchain master network maintaining node identity information for each source node in the source blockchain network, the cross-chain message including identification information characterizing the node identity of the source node sending the cross-chain message; the method further comprises the steps of:

and each destination node respectively inquires node identity information of the source node sending the cross-link message to the blockchain main network so as to check the identity information, and responds to the cross-link message under the condition that the verification is passed.

4. The method of claim 3, wherein the destination blockchain network is a blockchain subnetwork managed by the blockchain main network, and when a main network node in the blockchain main network and a subnetwork node in the blockchain subnetwork managed by the blockchain main network are deployed in the same node device, the main network node and the subnetwork node on the node device share a blockchain plugin running on the node device; each destination node queries the blockchain main network for node identity information of a source node sending the cross-chain message, including:

5. The method of claim 4, wherein the blockchain plugin includes a P2P plugin, a network connection link is established between main network nodes deployed in different node devices through the corresponding P2P plugin, and a source node in any node device sends the cross-chain message to a destination node in another node device, including:

and the source node in any node equipment sends the cross-link message to the destination node in the other node equipment through the network connection link between the any node equipment and the other node equipment.

6. The method of claim 1, the blockchain main network having deployed thereon a subnet management contract for maintaining node identity information for subnet nodes in each blockchain subnet built based on the blockchain main network; each destination node queries the blockchain main network for node identity information of a source node sending the cross-chain message, including:

and each destination node respectively reads the node identity information of the source node which is maintained by the subnet management contract and transmits the cross-link message.

7. The method of claim 1, wherein the identification information of any source node includes a node identifier declared by the any source node and a subnet identifier of a blockchain subnet to which the any source node belongs; each destination node queries the blockchain main network for node identity information of a source node sending the cross-chain message, including:

8. The method of claim 1, the identification information of any source node comprising a signature generated by the any source node based on its own node private key; each destination node respectively queries the blockchain main network for node identity information of a source node sending the cross-chain message so as to verify the identity information, and the method comprises the following steps:

and each destination node respectively inquires the node public key of the source node sending the cross-chain message from the blockchain main network, and adopts the node public key to check the signature.

9. The method of claim 1, further comprising:

and each destination node verifies the destination node signature contained in the received reconstruction message through the node public keys of other destination nodes maintained by the destination node.

10. The method of claim 1, the source blockchain network being a blockchain subnetwork managed by a blockchain main network, the blockchain main network maintaining node public keys of source nodes in the source blockchain network, the reconfiguration message further comprising source node signatures carried in respective cross-chain messages received by destination nodes constructing the reconfiguration message; the method further comprises the steps of:

Each destination node queries the block chain main network for the node public key of the source node indicated by the reconstruction message received by the destination node, and verifies the source node signature contained in the reconstruction message received by the destination node through the queried node public key.

11. The method of claim 1, the blockchain transaction including data to be processed therein, the method further comprising:

and each destination node checks the blockchain transactions submitted by other source nodes according to the first hash obtained by the destination node according to the first to-be-processed data contained in the acquired cross-chain message and the second to-be-processed data contained in the blockchain transactions submitted by other destination nodes, or according to the first hash obtained by the destination node according to the first to-be-processed data contained in the acquired cross-chain message and the second hash of the second to-be-processed data contained in the blockchain transactions submitted by other source nodes, and performs consensus on the blockchain transactions passing the checking.

12. The method of claim 1, wherein the destination blockchain network maintains a set of request identifications, the cross-chain message received by any destination node, the reconstructed message constructed by any destination node according to the cross-chain message received by the destination node, and the blockchain transaction generated according to the reconstructed message contain the same request identification,

Any destination node performs the blockchain transaction, including: any destination node executes the blockchain transaction under the condition that the target request identifier contained in the blockchain transaction is not recorded in the request identifier set;

the method further comprises the steps of: and after the blockchain transaction is successfully executed, the target request identifier is added to the request identifier set by any destination node.

13. The method of claim 12, the method further comprising:

under the condition that each destination node determines that any request identifier contained in the cross-link message is recorded in the request identifier set, terminating a response process for any cross-link message; or alternatively, the process may be performed,

and each destination node terminates the processing procedure for any reconstruction message under the condition that the request identifier contained in any reconstruction message is recorded in the request identifier set.

14. The method of claim 1, the source blockchain network and the destination blockchain network having the same smart contract deployed therein, the message content including data to be processed, the method further comprising:

the source node invoking the locally deployed smart contract to create the cross-link message;

And the destination node calls the intelligent contract task callback method in response to the reconfiguration message so as to return the data to be processed to the intelligent contract deployed locally.

15. The method of claim 14, the smart contract to update local data using the pending data.

16. The method of claim 1, the blockchain transactions respectively performed by the source nodes are:

17. The method of claim 1, the destination blockchain network being a blockchain subnet managed by the blockchain master network, the method further comprising:

and each destination node respectively returns a response message to at least one source node in the source blockchain network, wherein the response message comprises an execution result of the blockchain transaction.

18. The method of claim 17, the blockchain master network maintaining node identity information for each destination node in the destination blockchain network, the response message including identification information characterizing the node identity of the destination node that sent the response message; the method further comprises the steps of:

And each source node respectively inquires node identity information of a destination node sending the response message to the blockchain main network so as to verify the identity information, and processes the response message under the condition that the verification is passed.

19. The method of claim 18, wherein the main network node and the sub-network node on any node device share a blockchain plugin running on the node device; each source node respectively inquires node identity information of a destination node sending the response message to the blockchain main network, and the method comprises the following steps:

and each source node reads the node identity information of the destination node which is maintained by the main network node and transmits the response message through the block chain plug-in shared with the main network node which is deployed on the node equipment which the source node belongs to.

20. The method of claim 17, the blockchain master network having deployed thereon a subnet management contract for maintaining node identity information for subnet nodes in each blockchain subnet built based on the blockchain master network; each source node respectively inquires the block chain main network about node identity information of a destination node for sending the response message, and the method comprises the following steps:

And each source node respectively reads the node identity information of the destination node which is maintained by the subnet management contract and transmits the response message.

21. A cross-chain interaction device, comprising:

the message receiving unit enables each destination node in the destination block chain network to respectively acquire a cross-chain message sent by at least one source node in the source block chain network to the destination block chain network; the source blockchain network and the destination blockchain network are respectively blockchain subnets which are created based on and managed by a blockchain main network, and any one of the blockchain main network nodes and corresponding subnets in any one of the blockchain subnets managed by the blockchain main network are deployed in the same node equipment;

22. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any one of claims 1-20 by executing the executable instructions.

23. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-20.